From xen-devel-bounces@lists.xenproject.org Fri Mar 01 01:56:29 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2024 01:56:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687482.1071014 (Exim 4.92) (envelope-from ) id 1rfs8G-0007o7-GN; Fri, 01 Mar 2024 01:56:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687482.1071014; Fri, 01 Mar 2024 01:56:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rfs8G-0007o0-CF; Fri, 01 Mar 2024 01:56:16 +0000 Received: by outflank-mailman (input) for mailman id 687482; Fri, 01 Mar 2024 01:56:14 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rfs8E-0007nu-Oz for xen-devel@lists.xenproject.org; Fri, 01 Mar 2024 01:56:14 +0000 Received: from dfw.source.kernel.org (dfw.source.kernel.org [2604:1380:4641:c500::1]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id df0fa8f3-d76e-11ee-a1ee-f123f15fe8a2; Fri, 01 Mar 2024 02:56:10 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id D1E146164D; Fri, 1 Mar 2024 01:56:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1BA63C433F1; Fri, 1 Mar 2024 01:56:05 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: df0fa8f3-d76e-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1709258167; bh=gbJ8Iv/7xTt/XUfyMnMXrC66ed30tdQaG4+PFSMncqk=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=DaY5G3CS3sdH8A3HE+6CrZ9f0SGF+c7lQMKSYUFzQPlhRpx3iZVI1Iq0o18I2jmv6 183ciPBEriZ2o/encAXsOKXINWmqgVhV4Tu06GfqVgRLedUO+ZWSipfk7ly2Jy0Ywy nr1+RsF0z2QI8KT6jOnd77YidFkxoM4eMfflOtU4r8m6jMP6kQPSl9Qe8yYfPAruno ERSacnRE/mp53WbDzKuaXBw2XPij9xb85LEANPdIvhJbLc8oK8bNW80hMHeDIqjzu0 fWrjGMIWVtHyXaRZUIVyrjKT00X1dhJHqsKBPYhSNNmtpegoJFTmSdeWhSKWNRW5CT 8Zqj0Mpg3XIzQ== Date: Thu, 29 Feb 2024 17:56:04 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Stefano Stabellini cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com, jbeulich@suse.com, george.dunlap@citrix.com, julien@xen.org, bertrannd.marquis@arm.com, roger.pau@citrix.com, roberto.bagnara@bugseng.com, federico.serafini@bugseng.com, Luca.Fancellu@arm.com, michal.orzel@amd.com Subject: Re: [PATCH v2 1/3] docs/misra/rules.rst: add rule 16.6 and 20.12 In-Reply-To: <20240213223334.3693410-1-stefano.stabellini@amd.com> Message-ID: References: <20240213223334.3693410-1-stefano.stabellini@amd.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Hi all, This patch broke gitlab-ci. The jobs failing are the cppcheck jobs. xen/scripts/xen-analysis.py --run-cppcheck --cppcheck-misra -- -j80 No summary for rule 20.12 WARNING: Can't open /builds/xen-project/hardware/xen/xen/drivers/video/font_8x14.c: 'utf-8' codec can't decode byte 0x9f in position 7228: invalid start byte WARNING: Can't open /builds/xen-project/hardware/xen/xen/drivers/video/font_8x16.c: 'utf-8' codec can't decode byte 0x80 in position 5436: invalid start byte WARNING: Can't open /builds/xen-project/hardware/xen/xen/drivers/video/font_8x8.c: 'utf-8' codec can't decode byte 0x80 in position 4410: invalid start byte ERROR: An error occured when running: /builds/xen-project/hardware/xen/xen/tools/convert_misra_doc.py -i /builds/xen-project/hardware/xen/docs/misra/rules.rst -o /builds/xen-project/hardware/xen/xen/cppcheck-misra.txt -j /builds/xen-project/hardware/xen/xen/cppcheck-misra.json I'll look into it as soon as possible. On Tue, 13 Feb 2024, Stefano Stabellini wrote: > Signed-off-by: Stefano Stabellini > --- > docs/misra/rules.rst | 13 +++++++++++++ > 1 file changed, 13 insertions(+) > > diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst > index 182331089d..c185366966 100644 > --- a/docs/misra/rules.rst > +++ b/docs/misra/rules.rst > @@ -478,6 +478,12 @@ maintainers if you want to suggest a change. > adhere to Rule 16.2 would result in increased complexity and > maintenance difficulty, and could potentially introduce bugs. > > + * - `Rule 16.6 `_ > + - Required > + - Every switch statement shall have at least two switch-clauses > + - Single-clause switches are allowed when they do not involve a > + default label. > + > * - `Rule 16.7 `_ > - Required > - A switch-expression shall not have essentially Boolean type > @@ -554,6 +560,13 @@ maintainers if you want to suggest a change. > evaluation > - > > + * - `Rule 20.12 `_ > + - A macro parameter used as an operand to the # or ## operators, > + which is itself subject to further macro replacement, shall only > + be used as an operand to these operators > + - Required > + - Variadic macros are allowed to violate the rule. > + > * - `Rule 20.13 `_ > - Required > - A line whose first token is # shall be a valid preprocessing > -- > 2.25.1 > > From xen-devel-bounces@lists.xenproject.org Fri Mar 01 02:52:12 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2024 02:52:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687485.1071025 (Exim 4.92) (envelope-from ) id 1rft0H-0007ST-Ag; Fri, 01 Mar 2024 02:52:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687485.1071025; Fri, 01 Mar 2024 02:52:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rft0H-0007SM-5l; Fri, 01 Mar 2024 02:52:05 +0000 Received: by outflank-mailman (input) for mailman id 687485; Fri, 01 Mar 2024 02:52:03 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rft0F-0007SG-8r for xen-devel@lists.xenproject.org; Fri, 01 Mar 2024 02:52:03 +0000 Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [2a00:1450:4864:20::535]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id ada90dc9-d776-11ee-afd8-a90da7624cb6; Fri, 01 Mar 2024 03:52:01 +0100 (CET) Received: by mail-ed1-x535.google.com with SMTP id 4fb4d7f45d1cf-563c403719cso2431501a12.2 for ; Thu, 29 Feb 2024 18:52:01 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ada90dc9-d776-11ee-afd8-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709261521; x=1709866321; darn=lists.xenproject.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=V8c7DzusyVw+Znt9CrR5f39iJoZ0yzhRReE6XVLz+Is=; b=GHv56Rsmd2Fk6YyxcE8aRFMZg4Ar52sYAIGO7cQLCFbu2/8jGTbIbcs305OCkxa48X ONIozZHRR7BAxNmwX6npBOV6HTccE+HfFWAZYWUL2xQHNcE9Mbq/HErq9L45s5+LczOF RkgkyaC8mxxjV+DkEBnH31QtYuCjwilVS+0hMVbnAznU8dClJP6+zqcVm6oIW0hpcOTe ZwQ2qZd4LnOjw2O3auoaJSYBamhsYuTbRxhs+VqFJjsrq3FTzNukUc5MseMmO76PNiQH gq1ab3YfWEyzy3WUMn12+4HxeK9sSH1IbW32aDuAM4WzzmXp9ORCIOtf31YYlrUmqD9f 9maw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709261521; x=1709866321; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=V8c7DzusyVw+Znt9CrR5f39iJoZ0yzhRReE6XVLz+Is=; b=nnmOQGDyGlm2sROmeEv25TfGINb/Gjy/V5TLzxvo/6upUH+mdho08DYsLsWrTQ8UaJ 6GpqG1G8l7wWdwk2XTpfq0bX+ZMMw7PNZu67MuzfTLXN+yuQ+KkCBhOb4uaRYpN7HZwD yjQA0Qb6CVzA2uWtiDBBHGvnyl8uIRC+d858CC5lRL47M3tY60buVSPlTYClm4DWDD4R tQJKP/RTOvx52e6en074qSGuBZbqf8e3Ckg6b/KamdP45umuU2ktfwCF0Niwmc0bXgg4 74C5EEZj6sU0wx6P1h+fI7Op9KHS7Jj7t9H6syunmSYfnkro2qBej0o2MKy/5cxZ47cb h6bQ== X-Gm-Message-State: AOJu0Yzyoir0erdLxaz+XDQqrvaK/d4S2SS45eP1bAP9YkY/lZKwKWEd OJyQfC4YIbSWrLfFmF+k2xDpt9GNH8x8GuQPVI7Vh/H4XxPJ1XiAhpVFYfO4LcQ7QTLyGMC5LmM 01tm+ImMizl7PuF2JmOhP5Jgbcuw= X-Google-Smtp-Source: AGHT+IHg+77c+rgwdZnPxqMc4Q/2a/ydQNP00ZLb0dA9Tee3YY2BVCWupf/QAHQ9rb7K34esVTUArhvwWhoaqrCJp/4= X-Received: by 2002:a05:6402:d73:b0:566:1683:6370 with SMTP id ec51-20020a0564020d7300b0056616836370mr285242edb.19.1709261520829; Thu, 29 Feb 2024 18:52:00 -0800 (PST) MIME-Version: 1.0 References: <20240109170540.38239-1-jandryuk@gmail.com> <20240109170540.38239-3-jandryuk@gmail.com> <3d849b15-cfad-4d85-b2b8-11cd19027720@perard> In-Reply-To: <3d849b15-cfad-4d85-b2b8-11cd19027720@perard> From: Jason Andryuk Date: Thu, 29 Feb 2024 21:51:49 -0500 Message-ID: Subject: Re: [PATCH 2/2] libxl: devd: Spawn QEMU for 9pfs To: Anthony PERARD Cc: xen-devel@lists.xenproject.org, Wei Liu , Juergen Gross Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Feb 28, 2024 at 11:01=E2=80=AFAM Anthony PERARD wrote: > > On Tue, Jan 09, 2024 at 12:05:40PM -0500, Jason Andryuk wrote: > > @@ -3430,7 +3431,7 @@ void libxl__spawn_qdisk_backend(libxl__egc *egc, = libxl__dm_spawn_state *dmss) > > * because we will call this from unprivileged driver domains, > > * so save it in the current domain libxl private dir. > > */ > > - dmss->spawn.pidpath =3D GCSPRINTF("libxl/%u/qdisk-backend-pid", do= mid); > > + dmss->spawn.pidpath =3D GCSPRINTF("libxl/%u/qemu-xenpv-backend-pid= ", domid); > > This path is documented in "docs/misc/xenstore-paths.pandoc", I'm not > sure it's such a good idea to change it. > > But maybe it's ok to change the path because xl devd is expected add > then remove this path? And that pid isn't going to be useful to anything > else? > > I'd rather not change the path, but if you still think it's ok, we can > go for it. Thought? I changed the path to keep it consistent with the internal libxl names. The node is for libxl's internal use, so it seemed okay to change. But it is externally visible, so there could be other software looking at it. I'm fine with leaving the xenstore name unchanged. (I didn't want to rename all the qdisk stuff, but it seemed like it should be renamed since it would also handle 9pfs.) Thanks, Jason From xen-devel-bounces@lists.xenproject.org Fri Mar 01 03:01:41 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2024 03:01:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687489.1071034 (Exim 4.92) (envelope-from ) id 1rft9N-00014K-8S; Fri, 01 Mar 2024 03:01:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687489.1071034; Fri, 01 Mar 2024 03:01:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rft9N-00014D-5I; Fri, 01 Mar 2024 03:01:29 +0000 Received: by outflank-mailman (input) for mailman id 687489; Fri, 01 Mar 2024 03:01:27 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rft9L-000143-TA; Fri, 01 Mar 2024 03:01:27 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rft9L-0008Fo-R1; Fri, 01 Mar 2024 03:01:27 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rft9L-00082p-BK; Fri, 01 Mar 2024 03:01:27 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rft9L-0000IV-An; Fri, 01 Mar 2024 03:01:27 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=hPjgsmxZ+AFcb7QQmmCeUgBN0ILfxjtCQXFQrT3PgOU=; b=ApSkr4z9B8XWJBnpFx3sOBC+fx N79YBwjI5rmuNod+du8YFw9808k7RHvwxZ7eHnzToWXlwRpGxeSPUcgYts67biFLbz73ps7W5VtZI nY7hGZ1dL0ETh4HWYVC8Kusc6zPpt9CV4H7Zn5B0voUcoBiRoU6jzxGkhg7ttx216Uvs=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 184826: tolerable all pass - PUSHED X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=4cac80e22600d5a38d77c65e9a6507c752efc155 X-Osstest-Versions-That: xen=635dd1120a01961a39dce6ad3f09692681379378 From: osstest service owner Date: Fri, 01 Mar 2024 03:01:27 +0000 flight 184826 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/184826/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-check fail never pass version targeted for testing: xen 4cac80e22600d5a38d77c65e9a6507c752efc155 baseline version: xen 635dd1120a01961a39dce6ad3f09692681379378 Last test of basis 184823 2024-02-29 17:00:27 Z 0 days Testing same since 184826 2024-03-01 00:00:25 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Federico Serafini Julien Grall Stefano Stabellini Stefano Stabellini jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass 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 635dd1120a..4cac80e226 4cac80e22600d5a38d77c65e9a6507c752efc155 -> smoke From xen-devel-bounces@lists.xenproject.org Fri Mar 01 03:03:48 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2024 03:03:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687493.1071044 (Exim 4.92) (envelope-from ) id 1rftBa-0001er-LD; Fri, 01 Mar 2024 03:03:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687493.1071044; Fri, 01 Mar 2024 03:03:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rftBa-0001ek-IU; Fri, 01 Mar 2024 03:03:46 +0000 Received: by outflank-mailman (input) for mailman id 687493; Fri, 01 Mar 2024 03:03:45 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rftBZ-0001ea-Bi for xen-devel@lists.xenproject.org; Fri, 01 Mar 2024 03:03:45 +0000 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on20601.outbound.protection.outlook.com [2a01:111:f403:2418::601]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 4fb5345b-d778-11ee-afd8-a90da7624cb6; Fri, 01 Mar 2024 04:03:44 +0100 (CET) Received: from DS7PR06CA0040.namprd06.prod.outlook.com (2603:10b6:8:54::28) by SJ0PR12MB6783.namprd12.prod.outlook.com (2603:10b6:a03:44e::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7316.34; Fri, 1 Mar 2024 03:03:35 +0000 Received: from CY4PEPF0000E9CD.namprd03.prod.outlook.com (2603:10b6:8:54:cafe::c8) by DS7PR06CA0040.outlook.office365.com (2603:10b6:8:54::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7339.32 via Frontend Transport; Fri, 1 Mar 2024 03:03:35 +0000 Received: from SATLEXMB03.amd.com (165.204.84.17) by CY4PEPF0000E9CD.mail.protection.outlook.com (10.167.241.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7292.25 via Frontend Transport; Fri, 1 Mar 2024 03:03:34 +0000 Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 29 Feb 2024 21:03:32 -0600 Received: from [10.65.148.173] (10.180.168.240) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.35 via Frontend Transport; Thu, 29 Feb 2024 21:03:29 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 4fb5345b-d778-11ee-afd8-a90da7624cb6 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=h3+/Uh3/C+XXmed4L7itoOmcVsETRkDVPpSLOayMA5ZYTX6OQGQBlhSk7zvSLHFMGT9O45CDGqG8MLLtZGJsW9+26z8lwS/LdQeuKaTwRvsqJ0Rfrn3iWvaCnONqlFeei27/1ovb84P7pVaF0AixpSjhFes49Rk4ZB6vhdirblJKdHm9y3koCmjvavCO1QnAO8TySGid7RcWMA2EJqcA5EuUbNn59to3x93f2E1Cxk2BH1ENQHuCSXy9OOLg3SvgAazvVhHrwX2M91aVcSjHJgKbqAwXmOlbykZSnvOkebqR3bQ0Rm7YRCOsd+K8479H7p4v/VLapkIlARcTQ6pHJA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=fl7c7ZbvEY3wLxBTxbEFibIk1rfU3lpPxk7kipL++hk=; b=XcmotvbzHy1dktR7JrXZcIfOoEFXjNuYO0eeb6qu80zne5fxZtbU1PVXR/0uaAy6GqeeL1euJ4VjGffbRKrmAM5TrRxZq5Ij3RlPqbCvQRGHM+4/trZFjM7y+ARPwMWYAmRNLn1lwy/MZApBF/9g9zgfPUNfMN9DSHftalF9v5a2e3hXA4qNXgZVe+qs9R3FXPGNchL/pwWZiMuP2N3oqAxhsW3VVYJrnGdWN9fxZlD/V3+11OmayP92HigecBZqJps3WsSOfwIvOOwgk3AnL+aY0x38ImIqjvXeKLhdl98okifNrm9ckFoB5nAeEkFf/eWn+J3sY2JSxeYB5sooyQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=xen.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fl7c7ZbvEY3wLxBTxbEFibIk1rfU3lpPxk7kipL++hk=; b=JVTXgrutKS7KP8AwukrnJkf+tict8fH4/HJ9viS0SPdVEguhZWXBCoto88zBXshbS6orPRlUiKMbRCn1nDr0UmSXnJ22fmtPJ1EYSIyARznMM34APyyQ2hKzdDOB1Myj1Okazf9M7ah8aD+7Bm3wnbnMDo9iMlkFVIIkIHxUyag= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C Message-ID: Date: Fri, 1 Mar 2024 11:03:24 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/common: Do not allocate magic pages 1:1 for direct mapped domains To: Julien Grall , CC: Anthony PERARD , Juergen Gross , Andrew Cooper , George Dunlap , Jan Beulich , "Stefano Stabellini" , Bertrand Marquis , Michal Orzel , "Volodymyr Babchuk" , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Alec Kwapis References: <20240226011935.169462-1-xin.wang2@amd.com> <3982ba47-6709-47e3-a9c2-e2d3b4a2d8e3@xen.org> <8e56b75d-10a2-4764-8244-3e596f9fc695@amd.com> <98739f8d-dc00-4db8-a0b2-07f054107acf@xen.org> Content-Language: en-US From: Henry Wang In-Reply-To: <98739f8d-dc00-4db8-a0b2-07f054107acf@xen.org> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: None (SATLEXMB03.amd.com: xin.wang2@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CY4PEPF0000E9CD:EE_|SJ0PR12MB6783:EE_ X-MS-Office365-Filtering-Correlation-Id: a4c4084c-6835-431f-79f9-08dc399c2efb X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: qH+L37WvuPqoNgYM5DLG8uEcSsSshrRcOTQwTsveMnaj32j9KGkjT04toHzGNhKV2owFK8gPuyHAaMYzGMzIv8WeNDIrj0+VKZ9Rr+TKCfpemT+YhZfq37t/rdko9qdprHclnP72U22BqNqSdqN8uFfFa/QZi552YddUhPs/49XvprrSu36kPQiWjZNoFlhnrfzklmMQaqbrD58nWoI65hQHZFsVZRGzSyhknsApu5AP9diCEbADDCvK99oO4PjUWxAdhNYgq4mTSPCYKZ4iPJA9U0a6xcgV2peGYObf9/53gcCGLpJmMIyq3bnsbE19gBEv451uTF4oGUxMdJBFJrUpDXo08/Drj57gvutl2Dc0PYHMrSnHIsSyV3Zujr7dfrjH7ShKpHfjKMO3oFn8HnGmWJB28vW16outWGsmllaJATRG2C8EsAvDhHzJBFPQaz4+lpS3mIERxeSqJ6OY2/lCMuV2APoaeTsINZbx705M2vJ4RArMJJng/Y5+AI/6+cf5/A+LRxVTXA9+9dq5sd6x5tIrqQY2nyq0gWKlQcuZ+uP7V/Y/RXjQajSAs5uCJBhxeZ7n9wu0iMI72nFXSzXRgbuOHewuk8PNSqWIgEpF2RnzPnnOrLyjn3My0T+2xlxnc9oRjtMY4eptOemjabQsZAJsrb2B7mFruldObMHWdfdg3Xl3G4Vz/Pcfa4HO7Qe+3l26UnkMm9hsoRLLy0pxxPO4P1+JjdsEKc6LOrW0Fvib1OLuFvqPA9aCmRKn X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(82310400014)(36860700004);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Mar 2024 03:03:34.4588 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: a4c4084c-6835-431f-79f9-08dc399c2efb X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CY4PEPF0000E9CD.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR12MB6783 Hi Julien, On 2/28/2024 8:27 PM, Julien Grall wrote: > Hi Henry, >> ...here basically means we want to do the finding of the unused >> region in toolstack. Since currently what we care about is only a >> couple of pages instead of the whole memory map, could it be possible >> that we do the opposite: in alloc_xs_page(), we issue a domctl >> hypercall to Xen and do the finding work in Xen and return with the >> found gfn? Then the page can be mapped by populate_physmap() from >> alloc_xs_page() and used for XenStore. > > I know that DOMCTL hypercalls are not stable. But I am not overly > happy with creating an hypercall which is just "fetch the magic > regions". I think it need to be a more general one that would expose > all the regions. > > Also, you can't really find the magic regions when the hypercall is > done as we don't have the guest memory layout. This will need to be > done in advance. > > Overall, I think it would be better if we provide an hypercall listing > the regions currently occupied (similar to e820). One will have the > type "magic pages". Would below design make sense to you: (1) Similarly as the e820, we can firstly introduce some data structures in struct arch_domain: #define MEM_REGIONS_MAX 4 // For now we only care the magic regions, but in the future this can be easily extended with other types such as RAM, MMIO etc. enum mem_region_type {     MEM_REGION_MAGIC, }; struct mem_region {     paddr_t start;     paddr_t size;     enum mem_region_type type; }; struct domain_mem_map {     unsigned int nr_mem_regions;     struct mem_region region[MEM_REGIONS_MAX]; }; struct arch_domain { ...     struct domain_mem_map mem_map; }; (2) Then in domain creation time, for normal and static non-directmapped Dom0less DomU, set d->arch.mem_map.region[0].start = GUEST_MAGIC_BASE and the size to 4 pages. For static and directmapped Dom0less DomU, find a free region of 4 pages for magic pages. The finding of a free region can reuse the approach for extended region and be called before make_hypervisor_node(), and when make_hypervisor_node() is called. We carve the magic pages out from the actual extended region. (3) Add a new hypercall XENMEM_memory_map_domid (or a domctl). Input will be domid and output will be the memory map of the domain recorded in struct arch_domain. (4) In alloc_xs_page() and alloc_magic_pages, replace the hardcoded base address with the new address found by the hypercall. Kind regards, Henry From xen-devel-bounces@lists.xenproject.org Fri Mar 01 04:20:34 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2024 04:20:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687503.1071053 (Exim 4.92) (envelope-from ) id 1rfuNg-00038n-Na; Fri, 01 Mar 2024 04:20:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687503.1071053; Fri, 01 Mar 2024 04:20:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rfuNg-00038g-Ke; Fri, 01 Mar 2024 04:20:20 +0000 Received: by outflank-mailman (input) for mailman id 687503; Fri, 01 Mar 2024 04:20:19 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rfuNf-00038W-5i; Fri, 01 Mar 2024 04:20:19 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rfuNf-0001GD-0M; Fri, 01 Mar 2024 04:20:19 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rfuNe-0001Vu-KL; Fri, 01 Mar 2024 04:20:18 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rfuNe-0006i5-K0; Fri, 01 Mar 2024 04:20:18 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=GPdKGgQTy/UfxEF27Azypp0XPJwQ6rhXBoxRuUeH3kA=; b=qtbky97pjXjsu4UaZrvfWBJJ+1 YZ2ZoSwZdIT7dZDcA8f36AYFAwhA647MF6CAvlB7SbnpXkmS4xegipAM0vyJlQrnyz2k/xRsyez7g JJnxQfuC+giSIdK9uUHq0EWrftf2Wdk02QT0lsbH0k72i5XcUFm2FMWgSSbj/F2y7O5c=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable test] 184820: tolerable FAIL - PUSHED X-Osstest-Failures: xen-unstable:test-armhf-armhf-xl-vhd:guest-start:fail:heisenbug xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: xen=c20850540ad6a32f4fc17bde9b01c92b0df18bf0 X-Osstest-Versions-That: xen=195e75371b13c4f7ecdf7b5c50aed0d02f2d7ce8 From: osstest service owner Date: Fri, 01 Mar 2024 04:20:18 +0000 flight 184820 xen-unstable real [real] flight 184827 xen-unstable real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/184820/ http://logs.test-lab.xenproject.org/osstest/logs/184827/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-vhd 13 guest-start fail pass in 184827-retest Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-vhd 14 migrate-support-check fail in 184827 never pass test-armhf-armhf-xl-vhd 15 saverestore-support-check fail in 184827 never pass test-armhf-armhf-libvirt 16 saverestore-support-check fail like 184811 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop fail like 184811 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 184811 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop fail like 184811 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 184811 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 184811 test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail like 184811 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 184811 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop fail like 184811 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184811 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 184811 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop fail like 184811 test-amd64-i386-xl-pvshim 14 guest-start fail never pass test-amd64-i386-libvirt 15 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-check fail never pass test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-arm64-arm64-xl 15 migrate-support-check fail never pass test-arm64-arm64-xl 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 15 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 15 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-check fail never pass test-armhf-armhf-libvirt 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-check fail never pass test-amd64-i386-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-check fail never pass test-arm64-arm64-xl-vhd 14 migrate-support-check fail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-check fail never pass version targeted for testing: xen c20850540ad6a32f4fc17bde9b01c92b0df18bf0 baseline version: xen 195e75371b13c4f7ecdf7b5c50aed0d02f2d7ce8 Last test of basis 184811 2024-02-28 19:28:00 Z 1 days Testing same since 184820 2024-02-29 13:28:17 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Anthony PERARD Jan Beulich Jason Andryuk Roger Pau Monné Simone Ballarin Tamas K Lengyel jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-dom0pvh-xl-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-qemuu-freebsd11-amd64 pass test-amd64-amd64-qemuu-freebsd12-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-examine-bios pass test-amd64-i386-examine-bios pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-dom0pvh-xl-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-armhf-armhf-libvirt-qcow2 pass test-amd64-amd64-xl-qcow2 pass test-arm64-arm64-libvirt-raw pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-libvirt-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-examine-uefi pass test-amd64-i386-examine-uefi pass test-amd64-amd64-libvirt-vhd pass test-arm64-arm64-xl-vhd pass test-armhf-armhf-xl-vhd fail test-amd64-i386-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these 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 195e75371b..c20850540a c20850540ad6a32f4fc17bde9b01c92b0df18bf0 -> master From xen-devel-bounces@lists.xenproject.org Fri Mar 01 06:26:28 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2024 06:26:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687519.1071104 (Exim 4.92) (envelope-from ) id 1rfwLW-0000u4-NU; Fri, 01 Mar 2024 06:26:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687519.1071104; Fri, 01 Mar 2024 06:26:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rfwLW-0000tx-Kf; Fri, 01 Mar 2024 06:26:14 +0000 Received: by outflank-mailman (input) for mailman id 687519; Fri, 01 Mar 2024 06:26:13 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rfwLV-0000tn-8s; Fri, 01 Mar 2024 06:26:13 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rfwLV-0003xR-4h; Fri, 01 Mar 2024 06:26:13 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rfwLU-0005rY-Pg; Fri, 01 Mar 2024 06:26:12 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rfwLU-0006TQ-PM; Fri, 01 Mar 2024 06:26:12 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=Bv/RI0eGX73JtaU2nXwidKQgU6QmkSvmsOTfsiCILXQ=; b=2SXfSOEtTUqz4m8wgJy3mggp8e mJuXR5cPSSoqtlrZctJIUrVLUhWpMGmjxfHFfGSaLzbVGIFATe6IDWb3jC/RlyQZ3ImuzmjmHQDfv jqePwwz8yP3b5XMszxgphSk01DIJWQ2gORkue++zRy81NAHsdf3DPXM1P52JEL46XeDs=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-linus test] 184825: regressions - FAIL X-Osstest-Failures: linux-linus:test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm:xen-boot:fail:regression linux-linus:test-amd64-amd64-xl-qemuu-debianhvm-amd64:xen-boot:fail:regression linux-linus:test-amd64-amd64-xl:xen-boot:fail:regression linux-linus:test-amd64-amd64-xl-qemut-debianhvm-i386-xsm:xen-boot:fail:regression linux-linus:test-amd64-amd64-freebsd11-amd64:xen-boot:fail:regression linux-linus:test-amd64-amd64-pygrub:xen-boot:fail:regression linux-linus:test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow:xen-boot:fail:regression linux-linus:test-amd64-amd64-xl-qemuu-ovmf-amd64:xen-boot:fail:regression linux-linus:build-arm64-xsm:xen-build:fail:regression linux-linus:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking linux-linus:test-arm64-arm64-xl-xsm:build-check(1):blocked:nonblocking linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: linux=87adedeba51a822533649b143232418b9e26d08b X-Osstest-Versions-That: linux=805d849d7c3cc1f38efefd48b2480d62b7b5dcb7 From: osstest service owner Date: Fri, 01 Mar 2024 06:26:12 +0000 flight 184825 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/184825/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 8 xen-boot fail REGR. vs. 184816 test-amd64-amd64-xl-qemuu-debianhvm-amd64 8 xen-boot fail REGR. vs. 184816 test-amd64-amd64-xl 8 xen-boot fail REGR. vs. 184816 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 8 xen-boot fail REGR. vs. 184816 test-amd64-amd64-freebsd11-amd64 8 xen-boot fail REGR. vs. 184816 test-amd64-amd64-pygrub 8 xen-boot fail REGR. vs. 184816 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 8 xen-boot fail REGR. vs. 184816 test-amd64-amd64-xl-qemuu-ovmf-amd64 8 xen-boot fail REGR. vs. 184816 build-arm64-xsm 6 xen-build fail REGR. vs. 184816 Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop fail like 184816 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop fail like 184816 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop fail like 184816 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 184816 test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail like 184816 test-armhf-armhf-libvirt 16 saverestore-support-check fail like 184816 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop fail like 184816 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184816 test-amd64-amd64-libvirt-xsm 15 migrate-support-check fail never pass test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-arm64-arm64-xl 15 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-check fail never pass test-arm64-arm64-xl 16 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qcow2 14 migrate-support-check fail never pass test-amd64-amd64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-check fail never pass test-arm64-arm64-xl-vhd 14 migrate-support-check fail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 15 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-check fail never pass test-armhf-armhf-libvirt 15 migrate-support-check fail never pass version targeted for testing: linux 87adedeba51a822533649b143232418b9e26d08b baseline version: linux 805d849d7c3cc1f38efefd48b2480d62b7b5dcb7 Last test of basis 184816 2024-02-29 05:22:18 Z 1 days Testing same since 184825 2024-02-29 21:14:29 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Alexander Ofitserov Amritha Nambiar Andre Werner Arkadiusz Kubalewski Benjamin Berg Charlie Jenkins Christophe Leroy Clancy Shang David S. Miller Davide Caratti Emmanuel Grumbach Eric Dumazet Felix Fietkau Florian Westphal Frédéric Danis Geliang Tang Geoff Levand Guenter Roeck Haiyue Wang Ignat Korchagin Jakub Kicinski Jakub Raczynski Janaki Ramaiah Thota Javier Carrasco Jeff Johnson Jeremy Kerr Johan Hovold Johannes Berg Jonas Dreßler Justin Iurman Kai-Heng Feng Kalle Valo Kurt Kanzenbach Lin Ma Linus Torvalds Luiz Augusto von Dentz Lukasz Majewski Madalin Bucur Matthieu Baerts (NGI0) Michal Kubecek Mickaël Salaün Miri Korenblit Nicolas Dichtel Nikolay Aleksandrov Oleksij Rempel Pablo Neira Ayuso Palmer Dabbelt Paolo Abeni Pucha Himasekhar Reddy (A Contingent worker at Intel) Randy Dunlap Ryosuke Yasuoka Sabrina Dubroca Serge Semin Shannon Nelson Stanislav Fomichev Sunitha Mekala (A Contingent worker at Intel) Tony Nguyen Vladimir Oltean Ying Hsu Yochai Hagvi Yunjian Wang Yuxuan Hu <20373622@buaa.edu.cn> Zijun Hu jobs: build-amd64-xsm pass build-arm64-xsm fail build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl fail test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm fail test-amd64-amd64-xl-qemut-debianhvm-i386-xsm fail test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm blocked test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm blocked test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-amd64-dom0pvh-xl-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 fail test-amd64-amd64-freebsd11-amd64 fail test-amd64-amd64-freebsd12-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-examine-bios pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-amd64-dom0pvh-xl-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-amd64-xl-pvshim pass test-amd64-amd64-pygrub fail test-amd64-amd64-libvirt-qcow2 pass test-armhf-armhf-libvirt-qcow2 pass test-amd64-amd64-libvirt-raw pass test-arm64-arm64-libvirt-raw pass test-armhf-armhf-libvirt-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow fail test-amd64-amd64-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-examine-uefi pass test-amd64-amd64-xl-vhd pass test-arm64-arm64-xl-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these 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 2602 lines long.) From xen-devel-bounces@lists.xenproject.org Fri Mar 01 07:48:56 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2024 07:48:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687529.1071114 (Exim 4.92) (envelope-from ) id 1rfxdH-00012l-Ad; Fri, 01 Mar 2024 07:48:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687529.1071114; Fri, 01 Mar 2024 07:48:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rfxdH-00012e-7N; Fri, 01 Mar 2024 07:48:39 +0000 Received: by outflank-mailman (input) for mailman id 687529; Fri, 01 Mar 2024 07:48:37 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rfxdF-00012Y-Ms for xen-devel@lists.xenproject.org; Fri, 01 Mar 2024 07:48:37 +0000 Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on20600.outbound.protection.outlook.com [2a01:111:f403:2613::600]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 1b738bf3-d7a0-11ee-a1ee-f123f15fe8a2; Fri, 01 Mar 2024 08:48:35 +0100 (CET) Received: from DBBPR09CA0028.eurprd09.prod.outlook.com (2603:10a6:10:d4::16) by DB8PR08MB5465.eurprd08.prod.outlook.com (2603:10a6:10:118::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7316.41; Fri, 1 Mar 2024 07:48:32 +0000 Received: from DB1PEPF000509ED.eurprd03.prod.outlook.com (2603:10a6:10:d4:cafe::3f) by DBBPR09CA0028.outlook.office365.com (2603:10a6:10:d4::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7339.28 via Frontend Transport; Fri, 1 Mar 2024 07:48:32 +0000 Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB1PEPF000509ED.mail.protection.outlook.com (10.167.242.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.11 via Frontend Transport; Fri, 1 Mar 2024 07:48:31 +0000 Received: ("Tessian outbound e358842a0ad8:v228"); Fri, 01 Mar 2024 07:48:31 +0000 Received: from b3f34127e0da.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id C0FF78F7-B105-4ACC-9AEC-2BADC112E5B3.1; Fri, 01 Mar 2024 07:48:24 +0000 Received: from EUR01-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id b3f34127e0da.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 01 Mar 2024 07:48:24 +0000 Received: from DB9PR08MB6588.eurprd08.prod.outlook.com (2603:10a6:10:25a::24) by GV1PR08MB8284.eurprd08.prod.outlook.com (2603:10a6:150:a5::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7339.32; Fri, 1 Mar 2024 07:48:19 +0000 Received: from DB9PR08MB6588.eurprd08.prod.outlook.com ([fe80::7fb0:6621:56b:22d5]) by DB9PR08MB6588.eurprd08.prod.outlook.com ([fe80::7fb0:6621:56b:22d5%3]) with mapi id 15.20.7339.031; Fri, 1 Mar 2024 07:48:19 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1b738bf3-d7a0-11ee-a1ee-f123f15fe8a2 ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=QpwoAUZX9xkFoXaADkMDPt244tGK5hZAHt91+DQOwpQx3THP1BHemyOXAisQErqP1K32aJBiu/XDTC1H0Zzz4t8KEa8Fp3SaS50mA+/Xa8JHZ2DWW930SR6OFA7d8S5IuYAqwLpiyxheu1/804qNKmCTxP1NnNXtjToL5V7cT5yIkynb8XOU6PDT9VQpxTG7wCISl+f8kdhGvgWRW0jPT2ftKjWz+6RK5Alds4O1HlNo0x+uG2IbRJKPnQ2gLIB4nOVJrHyKNWCmWFaw+tu7emYrjnBER2KgH9AyhfYsVtp9+jWQJDX7c1IEY3S7cI6WJJbwXNZihMTspBgHrfVObA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=jO7Ulch6vbq9W6ykEXoGuWqFYt6mmQFNdCPTJI9K870=; b=Ltt9toyqUH8sSqGo5fw6HGlbj2g3tgozhKIS+koQfZ4ttC8A5UMfuCXFsIiMbq4J2imyes46aoWRK93+8YAQnXU5KRTTgXt8h4DfPPTPvsUreB5wgroStHLbKp27WWsTqxdSXTFCS1JgEEJguoVS4W9dRXRc6TUiFffW0vY91zBLRWajJiyC/KArV1GZeh0PY5wepSbIncr58Y8ewixpXGJlQ3YPci6TuXsGrzQtgVqp/kz3737w92L7pkkcFhaaDznqsTwjzJ7n8+DADvwmSe7VhD3IZmiQ4z1YzhfL8zstPQh3HG+ceQlzIttNhrNFQbZpku7dKoKj8ROPh0ZYvQ== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 63.35.35.123) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jO7Ulch6vbq9W6ykEXoGuWqFYt6mmQFNdCPTJI9K870=; b=B6zzEDEozNDUOCB7ycocwsDenTepaU2WdLYiYttyZmEEbjr/Jt3nS1RvPhYgYuqYZMXoRLy6bK7QYgDfK78r8eY6pe3TD7G/EfxtBQpzlOyjKpqVHNhWwkBu9nu5QxGw92GhFTdFOuCW3kew6/ep2JtCIcRYcA2h8xq1z94lHRk= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; pr=C X-CheckRecipientChecked: true X-CR-MTA-CID: 5e4f0efa866089f8 X-CR-MTA-TID: 64aa7808 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QCH5pzsegz406LLhJCVHVlS2rqMxmPQqyxKR6qpHim1oj1e/RQHhBH2DOffnO8BZ+eK3l5nFHpELcrTU7Jypbwi3WFqjXcYnKZBHQUq6EzMSIAqQhAJUbdMPCvmWtTVAAWv7wwI8XpUAK432YclJGTL1lV6KtHu+6k95SOVPDnGRmZyma1c+IRgVTaHYkqnPy1FXqMq/prQnUZFR2ejLNzyZOZV5Se90FO8e9jwLLmGGVnQ/1aJNryBxu/ZopYVqXEjEtTkD4R+VZBY9xTaxEujr8nIOGYZiw/KRbsrh1VUSApCUbAhS4w6+/5j2qJZ5BJ9VAc24cP9Z1z3eMCGt1g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=jO7Ulch6vbq9W6ykEXoGuWqFYt6mmQFNdCPTJI9K870=; b=dEVn5fzbjY3uMfxDvn925+osUPUeDgdhJWLAK2Flh4nRdXAd7f9z4gZbLbNrVYomNk+KDPZBV7aRHeZV0IoV+d1MnT2VgpvQQEol4orzq2Vdz5lfy1p4YTl7DrlEz0+HmwFk6ac8oZnOaWOl9F2Pid5p/r3vUpTLOLfcEqx4RsdpdaX0ZokrTwLBLv8qKZN0FC8llV3bXhZ9MAzBwBdaRQwP454lugw3H3kvBRlamRQ+O4gNJqEyAtoTkawmq63MiFGMSn1XV1FOu87+c7Jr+pN23jskgBJxEOYJhIGNieTkhg3YuhXIn0HkLZ7Wj3YjqBEq6apBmWliUf7YJNEHgQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jO7Ulch6vbq9W6ykEXoGuWqFYt6mmQFNdCPTJI9K870=; b=B6zzEDEozNDUOCB7ycocwsDenTepaU2WdLYiYttyZmEEbjr/Jt3nS1RvPhYgYuqYZMXoRLy6bK7QYgDfK78r8eY6pe3TD7G/EfxtBQpzlOyjKpqVHNhWwkBu9nu5QxGw92GhFTdFOuCW3kew6/ep2JtCIcRYcA2h8xq1z94lHRk= From: Bertrand Marquis To: Stefano Stabellini CC: Xen-devel , Andrew Cooper , Jan Beulich , George Dunlap , Julien Grall , "bertrannd.marquis@arm.com" , "roger.pau@citrix.com" , "roberto.bagnara@bugseng.com" , "federico.serafini@bugseng.com" Subject: Re: [PATCH v2 3/3] docs/misra/rules.rst: add rule 14.4 Thread-Topic: [PATCH v2 3/3] docs/misra/rules.rst: add rule 14.4 Thread-Index: AQHaXszFR6HRU5T+rUafoY3rmsbNMbEinAGA Date: Fri, 1 Mar 2024 07:48:19 +0000 Message-ID: <271ACCC1-0B26-4E8D-931D-8CED52E5E78A@arm.com> References: <20240213223334.3693410-3-stefano.stabellini@amd.com> In-Reply-To: <20240213223334.3693410-3-stefano.stabellini@amd.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3774.200.91.1.1) Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-traffictypediagnostic: DB9PR08MB6588:EE_|GV1PR08MB8284:EE_|DB1PEPF000509ED:EE_|DB8PR08MB5465:EE_ X-MS-Office365-Filtering-Correlation-Id: dadd9ab9-e718-45b2-aa22-08dc39c3fd94 x-checkrecipientrouted: true nodisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: c5bAkXB88mvupxQ2vAh9UylOtKYnwKqtyOSpFHJ9nscRre0fsKke3ODMFYWem2e/ylAlJTohAcC/TM/YJDWM5lfJ3OQfAUcAV20F7w8k94HbXXjjlcpzt4DLUfry8eWPCD2UFVVDZ73AVQ4FCYPr1TrQRnvzWYueE0hWydjPODyNvfNHcnA15YHyMniQh3MmfBJy8iouZHkedYUnOr2jCbcs3wgx3HKskg332yXaRApZawvvoJGGTdSBA57I1pv/32V4/8LdP/EzzteFoHObceyK69n9oRkfdEkgl78pmuHbDXX/tg+J6Cr7+u8kGboosQBwiDxPbvLCmgVZTnyJI52SohU3ZoteiduBv53TRqw7WwKaT8IPs5xjb5Ukq3ZD6XzR4wKgEeZQSujfZ8X1em732j3Lz6jjh27/UXCBjeTmNRyBbu1FdzEq2EtLgPJ1EQVt2T9dx4C5hGDqmkw5eaj6j6CtUTgVIiVyD9nT7IosIJVsbxIlMcPRYqwd/mIlyRGaZkS8NSn9SxD5L3oYZYh7HYGdWTXmNr2W8gUSfD888lKZRNfkVOhBiXNAHyeFtDobg+Q5yKQPQBxtBj7DPQS/rkwLfPqVXMK+wla7M0mw14FCLHa+uc45xg3nY9aRtjcfpvKUEv9Mg0SbVp3lcyVty0U2NVGVLE2CQT+T7+gZZuWLNI24nqAkOQvL7ukr X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB9PR08MB6588.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(38070700009);DIR:OUT;SFP:1101; Content-Type: text/plain; charset="us-ascii" Content-ID: <290C546531FCAB46AF6164B0BE7DF633@eurprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV1PR08MB8284 Original-Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB1PEPF000509ED.eurprd03.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 95706637-bd81-4f4a-6785-08dc39c3f672 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Ho5KhQS7Hrzb0DeJdbfq1ZrhDtrZDy1XFjUroZDnl9QLMcfc9+bFRURqutNUXjUcQmlW+yvuMJkSzSQpNapiVq/B6zRsCxPxjFRldXLLWSGirANavuz/QtWyPM0BNvecxLvTb+YPjSSpGjO2xLvAxGPGT2hS9Rw8dUfjLxwvOmnyIFQVCpR4aw6fn0QczQu7dXSBchnyvEdCvG+jIX+MPVboD/XIwr+FBc3tZxjw5+s/A34l0p9Zb7Idwzm0Z9SwP+xYat+eP9HO+lzNWqCUcsWaFshPNcFgHZC/RSKOs/ZQII2UR2FVfcFibTf+dBVmZM6XuE5fBy16ykqjVNDLL6BXeF003Fci3oT3FzfO6RlMHBaAt3OqUWUpXu5LQ9tdbh+tjT8tMXFFSPi/iOrw385cehLvQDhGlem1v8ttFusDy7K1XpP7ULvGpBuCwv8Y7R4sltT0Jg3FvQDgyRLwwFh9L5I4Z1kyWKQijn9icCGD9UabxfVm8bTXniURiQdzG/J6PVq9y2kqoiVSCCPCRt80DD06GhlVklEa5zpfOa3TMeOunvyKUtX4uV3+E4TV35m4gmhtiJxLT18AGZCWfGoOJYpZQP4A/c1wOOatwXevSLbEnnkEOMBmY5Ywzr5bs3RD/FtoVhSDFuYlT5O6rPZXgFBqqvKPaxvvML13bEk2c5wofMFRLPx00MLdswbZdmazIfkrtK6wffisRBEk3g== X-Forefront-Antispam-Report: CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com;CAT:NONE;SFS:(13230031)(36860700004)(82310400014);DIR:OUT;SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Mar 2024 07:48:31.5552 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: dadd9ab9-e718-45b2-aa22-08dc39c3fd94 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: DB1PEPF000509ED.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR08MB5465 Hi Stefano, > On 13 Feb 2024, at 23:33, Stefano Stabellini = wrote: >=20 > Signed-off-by: Stefano Stabellini Coherent with what was discussed during the Misra meeting so: Acked-by: Bertrand Marquis Cheers Bertrand > --- > docs/misra/rules.rst | 9 +++++++++ > 1 file changed, 9 insertions(+) >=20 > diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst > index 931158b354..3e6f94d7bd 100644 > --- a/docs/misra/rules.rst > +++ b/docs/misra/rules.rst > @@ -468,6 +468,15 @@ maintainers if you want to suggest a change. >=20 > while(0) and while(1) and alike are allowed. >=20 > + * - `Rule 14.4 `_ > + - Required > + - The controlling expression of an if-statement and the controlling > + expression of an iteration-statement shall have essentially > + Boolean type > + - Automatic conversions of integer types to bool are permitted. > + Automatic conversions of pointer types to bool are permitted. > + This rule still applies to enum types. > + > * - `Rule 16.3 `_ > - Required > - An unconditional break statement shall terminate every > --=20 > 2.25.1 >=20 >=20 From xen-devel-bounces@lists.xenproject.org Fri Mar 01 07:55:05 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2024 07:55:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687533.1071123 (Exim 4.92) (envelope-from ) id 1rfxjQ-0002b1-3c; Fri, 01 Mar 2024 07:55:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687533.1071123; Fri, 01 Mar 2024 07:55:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rfxjQ-0002au-0r; Fri, 01 Mar 2024 07:55:00 +0000 Received: by outflank-mailman (input) for mailman id 687533; Fri, 01 Mar 2024 07:54:59 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rfxjP-0002ao-Cb for xen-devel@lists.xenproject.org; Fri, 01 Mar 2024 07:54:59 +0000 Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [2a00:1450:4864:20::62a]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id ff67f1f8-d7a0-11ee-afd8-a90da7624cb6; Fri, 01 Mar 2024 08:54:58 +0100 (CET) Received: by mail-ej1-x62a.google.com with SMTP id a640c23a62f3a-a3e85a76fa8so255499966b.1 for ; Thu, 29 Feb 2024 23:54:58 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ps7-20020a170906bf4700b00a3e53eb1dcasm1452980ejb.107.2024.02.29.23.54.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Feb 2024 23:54:56 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ff67f1f8-d7a0-11ee-afd8-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709279697; x=1709884497; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=mpWpo1TlcJ9WH96OHYamwi3lHe6uk74EdSkVgHIpH+Q=; b=IwQ51CSULBddrLUedMDHSJtEOm+pQAbmigLI7lw+DIRnTLBjiJjH1RHX5//+T3Fz2X hDAQL4858FIJjc+9vL2xlqAnmOAYDpeMak08meXJ9CbFDbCl5tq00kJkn/9RQiqyBij9 15JZOitPIUr//uGq0JUh1WyxD6vMt1B2X1sSjHxbtU/ppn7nLfKWSgwmfqhlzu0vLOAN rE693d+z5D2kBXMkST7Nwbcz+q4aHV9uqXCjaaQT04p5S7fbeDTcktF96OarQEt3qpln uadXo8sba9L/fVDlsaN8zsmmy+P/va9K3umfT+APPtEpzZbLYgOIBbJFnvaX8UzK4Ni7 iFYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709279697; x=1709884497; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=mpWpo1TlcJ9WH96OHYamwi3lHe6uk74EdSkVgHIpH+Q=; b=s6E3ChD1fdoFs92bhHvT2zDpqEjrvqLyh8P5pPxSLHqgykobzFeICbvuY+80WqtBso XuyZqe7xCjJ1ntvpdweLm/0mlS+GorElCSoPevG0wRUNQTYKD5J8gYyUFpCw8lHTalSN DQU1YkaEikEVSyh/Qt0Kxq0IPBpV6vB6cCeHCRdRBZ4vV4tTN1dLh29190N5qCeW8fid L2EE80X5A6nelyYHGyJe8hYaBbBIk/4gu907vAIEMVPaF3Ffu7S/yk6rjfMDDEUsMZiq Vw0YDIxo43EqWqKR2El+APZ1/RYpdTiSafba37+U903XxtUrRS/usPYoRG2dIc5nRI4r qaEA== X-Forwarded-Encrypted: i=1; AJvYcCUf8Xieu1RaZA3EU60ZGdC3r6A1wyX5J1nIZq9aJXa+DmHp510KkbFlClFiBnETchB4nFFRKblFtmX6QhkbqDtwXbnKsT0/Fst9hoLokTQ= X-Gm-Message-State: AOJu0Yxi0+Hw++SXvvQ6Z3n3K/nndhI+fO/6yB+vAz4gBjmWR0Dx9lZN qClufp2bVgivVdjWEQGzwpr0qzVoFlH9ZucX6+bmgjVrrbP3CuvcuGkfF00DNA== X-Google-Smtp-Source: AGHT+IFt22qXCM/U892YNnIsIY7ehVU++ZkbWlnv0191Or5xNIGcoWpzBYdFESrOEpssH419yuQ94w== X-Received: by 2002:a17:906:f812:b0:a44:81f0:6c7f with SMTP id kh18-20020a170906f81200b00a4481f06c7fmr769774ejb.22.1709279697148; Thu, 29 Feb 2024 23:54:57 -0800 (PST) Message-ID: <513e3eb1-d192-4317-afc1-55cb44e4c7c7@suse.com> Date: Fri, 1 Mar 2024 08:54:55 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH 04/10] xen/public: address violations of MISRA C Rule 20.7 Content-Language: en-US To: Nicola Vetrini Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, consulting@bugseng.com, andrew.cooper3@citrix.com, roger.pau@citrix.com, bertrand.marquis@arm.com, julien@xen.org, George Dunlap , Wei Liu , xen-devel@lists.xenproject.org References: <0cdc4dc2fcad699a2274277b32de3ee0207d5a2d.1709219010.git.nicola.vetrini@bugseng.com> <82940f688e5a5eee274fa579991ebd15@bugseng.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <82940f688e5a5eee274fa579991ebd15@bugseng.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 29.02.2024 17:49, Nicola Vetrini wrote: > On 2024-02-29 17:40, Jan Beulich wrote: >> On 29.02.2024 16:27, Nicola Vetrini wrote: >>> --- a/xen/include/public/xen.h >>> +++ b/xen/include/public/xen.h >>> @@ -988,7 +988,7 @@ typedef struct { >>> ((b) >> 8) & 0xFF, ((b) >> 0) & 0xFF, >>> \ >>> ((c) >> 8) & 0xFF, ((c) >> 0) & 0xFF, >>> \ >>> ((d) >> 8) & 0xFF, ((d) >> 0) & 0xFF, >>> \ >>> - e1, e2, e3, e4, e5, e6}} >>> + (e1), (e2), (e3), (e4), (e5), (e6)}} >> >> Why? Wasn't it agreed already that long macro arguments passed on >> (no matter whether to a function, a macro, or like used here) don't >> need parenthesizing? >> > > That applies to all outermost macro invocations, but not to the > innermost one. If you want also aggregate initalizers to be deviated, > that could be done (provided that the macro arg is not included in some > expression, such as "{..., e1 + 1, ...}" Sure, this obviously needs to be "{..., (e1) + 1, ...}" then. But yes, the full scope of the underlying pattern ought to be excluded from needing (pointless) parentheses added. Even in a plain comma expression you don't need them - to pass in a comma expression the invocation site of such a macro would then need to parenthesize the respective operand (or else it would be two separate operands). The one case we're leaving aside here anyway is use of odd things like #define M a, b and then passing M into another macro. Jan From xen-devel-bounces@lists.xenproject.org Fri Mar 01 07:57:15 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2024 07:57:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687535.1071133 (Exim 4.92) (envelope-from ) id 1rfxla-00037W-F5; Fri, 01 Mar 2024 07:57:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687535.1071133; Fri, 01 Mar 2024 07:57:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rfxla-00037P-Bi; Fri, 01 Mar 2024 07:57:14 +0000 Received: by outflank-mailman (input) for mailman id 687535; Fri, 01 Mar 2024 07:57:12 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rfxlY-00037J-KK for xen-devel@lists.xenproject.org; Fri, 01 Mar 2024 07:57:12 +0000 Received: from NAM02-BN1-obe.outbound.protection.outlook.com (mail-bn1nam02on20601.outbound.protection.outlook.com [2a01:111:f403:2407::601]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 4db455f2-d7a1-11ee-a1ee-f123f15fe8a2; Fri, 01 Mar 2024 08:57:10 +0100 (CET) Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18) by MW4PR12MB7310.namprd12.prod.outlook.com (2603:10b6:303:22c::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7339.32; Fri, 1 Mar 2024 07:57:05 +0000 Received: from BL1PR12MB5849.namprd12.prod.outlook.com ([fe80::debf:178c:f5df:5efa]) by BL1PR12MB5849.namprd12.prod.outlook.com ([fe80::debf:178c:f5df:5efa%5]) with mapi id 15.20.7316.037; Fri, 1 Mar 2024 07:57:05 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 4db455f2-d7a1-11ee-a1ee-f123f15fe8a2 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aa99U4KW51WlpvtYsWbhu85L79ykG6MMQsX5gdPQfqezShx8VvqmDzvD7zlv4O/9/iHF6dROj+3X8y33xrDiRJOzLG2R9VgPDUVc6XtUPJq4DSLQE+UggThpWo70ngxEqoqZuHO25Aj6aX7ezpsrXqp3JOOgFakp5jYEhlRhgBW7ad2Syo0lqZzo6cMyeJUAD7w3mMk5ZX3K5Wn0un/XLuIf6fYddWxU3QQbrjlfXPZhds8wHxk2hnWFqL/0U6tX+EKYguaiEgkyFkVIhCkrEMKdRNa0Q0zPCkk+5HJyMsVWz9YSFjL8RbD/6Zi3vftSZOWVzMqDnG5YiGIyN3vwqw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=M7fIs2L+73nk4IzuloKkcWwVd5SRX1Wtu54FX+9pUBo=; b=NMECgJ1F87IF2EsSWLXBhkDNpFV9qu9rvuOlQjcENFC8lHPUfPfxkxgtdeaeOU9owVwqFfjHSw38IqyafDmCdrch5wtsnhjchN0RW6Mr29tuZ99UlI3ACaTKi6cfsVsf/vrg6iuCAn8fjk9UWmC2jz/AKVMXsCqVFEKbQ2ppcFXwUZ2CRnlGSVly92bqjRo9xxBE2Y2E0+YOJheJnR4AIbmzQEaDWOODvvILttZTODTSsjBPPTi+EX+Hcd4XelFLzsZzRdj9P4JtNEsEbcWFt27hN/034ZLB4P8aDD0y6fsBN2emZLSkuo9Oca8c5tnqKTgQi0XRgCmpv9x2zm1JxQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=M7fIs2L+73nk4IzuloKkcWwVd5SRX1Wtu54FX+9pUBo=; b=IKV1jl16XbADwe+BzRWAXIJ1bf9O5PPGLUUifh6s+JL0lvD6M13Wtq5BKUgur9SVPI4wQZ/vCgWBCKWkTBEBLrSNbOBl1CPlCJIxOj2ZPwHfcfczxnofUazKqKybP3vE0zKyTBO9MdloTYN2LATes9RJLXJJMcxxhGlNa+y/u/Y= From: "Chen, Jiqian" To: Bjorn Helgaas , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= CC: "Chen, Jiqian" , "Rafael J . Wysocki" , Len Brown , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Boris Ostrovsky , Bjorn Helgaas , "xen-devel@lists.xenproject.org" , "linux-pci@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-acpi@vger.kernel.org" , "Hildebrand, Stewart" , "Huang, Ray" , "Ragiadakou, Xenia" Subject: Re: [RFC KERNEL PATCH v4 3/3] PCI/sysfs: Add gsi sysfs for pci_dev Thread-Topic: [RFC KERNEL PATCH v4 3/3] PCI/sysfs: Add gsi sysfs for pci_dev Thread-Index: AQHaP5+doYjSbLzTtkiUcLxinuNXV7DmmK+AgAEHcQCAAAvdAIABnLmAgAg1Y4CAALowAIAAwpaAgADNJ4CAAKgsAIAA5P2AgA1jFYCAA+/3AIAAqS0AgAQDqwCAF+s/gA== Date: Fri, 1 Mar 2024 07:57:05 +0000 Message-ID: References: <20240212191858.GA1137351@bhelgaas> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-imapappendstamp: BL3PR12MB6548.namprd12.prod.outlook.com (15.20.7292.000) authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; x-ms-exchange-messagesentrepresentingtype: 1 x-ms-publictraffictype: Email x-ms-traffictypediagnostic: BL1PR12MB5849:EE_|MW4PR12MB7310:EE_ x-ms-office365-filtering-correlation-id: d1cf0698-0991-41c7-0ea8-08dc39c52fb1 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ESEkGR9tDC2o/cfIoIErfeMOWVhAxQELcmN8mqznYCnwbDEw/gJ49xmrNjK55rCKCdLOV1qeyV13j4MYqbLhMZ+DhG5uasCg7rY+qGG7sXpXEmJD9tQaZob/cB83VEf/7S/jbkNsR64KzfxDsm93Peditz0nPg/dDGuS3g/HWlyHhGho2S5k7vm0DYOBqPJJpiYQg+p6N4Uz82AfGJoLo1sEEBQ3zs8Dpy0ubeNqgi5AOr1OhhyaMRJ7caq+DAiVMYLnNCyMj4cnZWRLchFlJL4hhK7c9L2qAHrbG8e26NmqIK9VHLOAOaMoIMClfpnu7Zc6JXf0lXg/nPBMKV81Nh3SLFFm9vO5/aFoB5F24QY+RuJu7MR9Cjh1QgsP582s3g4/KGbSP/aYQfcQ3QfA1qiZehvxBUt1H8lYrpzQ67cd2LUm0Qku8jSbzt+mF6iz561Xq7Pq9LxEXp9bS+S4ufvkkgBn7JMcgbDKvzVSLf5Evnj/oFqUu7Ypq1sSwjTukbSEQpQPm7xH4USrT5cvPgDf5/CFNkZD/pZ27I3/GQ1JKi3OSeBA1vjxUes48GVNN1d1uZHOIgH6nPsOOA8XeTF63zNd7yNldqbmJLDpqXmI8x8sA+iETprSXohbjavoMvfJA57cZBTm2P+FINSE+5+BaroZyiam/NUEyfB0+fmkc8pHoTPO2cJHjJyEmR7y4Yjx6yH3vWONlHbNhqo9Ij7BF7M+eP4wxgOX6XAM18g= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BL1PR12MB5849.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(38070700009);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?MHBBVnpQdUJwdzVTK2VyNVBZbklKZ2lwMUIrT0xGd1JyNlovUXBINHg3TjNr?= =?utf-8?B?dDJjZXFNQk9xbUtoQU5YVEVkbmJxaUsvZ050OTRpTUI0Ynp0R2tZZGs2NEIx?= =?utf-8?B?MENyZHRHQzhLdjdkaXpVVldnVHoxSjlXOGhPNkpUZE9lRGNIVXNUTC9Fb0d0?= =?utf-8?B?OEZqWWh4dEc1S1picVdINit5c0NnS1pEbEticzg4ZEFqVFdQcWdLMThBVmFD?= =?utf-8?B?Rzc5Z1Z6Z2ZUUkczckdRK1lDb2Q2ejAxMnBUd0hqZFZWcEcxMVRiL1pTL1ZS?= =?utf-8?B?RzNhbTRvOFdLcUNzUEp0RG5pRzgzNVJTeUo4WWtPTzJGbUN1WnRKWnlBVXlx?= =?utf-8?B?dEdkbUtuR1VPdmpuUnVSeGhJZ084aXBvZndoVUdSNUlOL1VmYUZqVFBpWmtE?= =?utf-8?B?YlNXQnhKd0NacWNEZDNDQ1dQMzVVNWtsdU5mWktGS2UzU1hqMjRwYzhZTTZ0?= =?utf-8?B?ZGVkODJXQjdGVmRyQTYycUNCSk9qMGJRQVJPRjdTeFBkNlJqSFdZa3lySWFM?= =?utf-8?B?VGw0d1o0VUxwcHJ6TjRPYjU0WTJRRVVRcDZIeVNjNnVOdXI3RlBPVEZ6SXBS?= =?utf-8?B?akZtTXdmbjUrZlBPbVp4SnIzaDkzZmxxQmxybmNNZVZXa3VMY1JZTzNESGUx?= =?utf-8?B?TmdET3YvM1RHbUdVRzRFSTh5Skp0bVVaWEhCRHNUTnltNFRTRWgxUFo0NUVj?= =?utf-8?B?VUJnazcrQmRjVGhXUVZrOXJ3ckJhR0Z6N2liUnVpNlRjVUwvT21qZngvTVB6?= =?utf-8?B?V1ZSb0o5N0lkYzd0SldNYk5qQ1dlZ3J0K3luWFhvSVBhZVcwUU8ySDlqZ1Ax?= =?utf-8?B?TEhEMmF3eDVNYnkwaFBwOFJBWlRXOXlqdXZXempQYjJwc0lDUE9IdC9YbjMz?= =?utf-8?B?MFVYTlErWlB2djAvRmtTaHY3VmRicDR2NFVIeG9VY1dWMnF0c1k5YVVaNGM0?= =?utf-8?B?akVDLzhERjBZOFliKzRKRXE1cXFCUmlZMDdTQW40L3BvKzlDN3QxK1BLM0R1?= =?utf-8?B?LzZCcFg1MHpkakVJcklpUVR2UCtkSlVhSkpjbzZ6V2RtSmpzbkRUTzVCajc5?= =?utf-8?B?eEdRcGVJOXRDZTJ1OElsMlF5bm8zSGk3c0tFcU1NbVh6THdJWDRuM2xlaVFr?= =?utf-8?B?Z201N1lUaVFFK3dmS2trSDE0TXludzRyaEptcXplN1lVK0tEYXMxeFlRVS94?= =?utf-8?B?TnRZeWE0Wmg2NVBTcUNPR0IzaldJL2I4RWI4OXFFdHV2VjJrcTQrQzE0YU9U?= =?utf-8?B?ZkhWQXJVQk1NdFZuTUVibk1UUWVUYVBhWUJjMGpyWFdZN3hxelhLMHVacms1?= =?utf-8?B?OW5XY1NqVUtVdFJ2bzYrM0ZVdmZKbzNkVkcxRDJwWXArcFdqZkpoS3pYV0sw?= =?utf-8?B?ejZOSjN0ZkhtUlM3Q01oOUNES2tqVENtSzVaZ1pLRnByNXRsUEV1RHV6K2ll?= =?utf-8?B?Y0VGU1hMQnNFRkRIL0lnSkc3RHZnakxYa1FMdmFveG9oWUlwamRlM0Q2ZGJX?= =?utf-8?B?OVFkR3dvU0VLSHBQVGpLS3JUWHFDSlZEOTRoVVVPczB5bmc4OGYzbThRYXlO?= =?utf-8?B?dFBLTSt2YmdMUjU0TUJ0ZXpyRGFGNDNBdGwrNmMvLzk5dThVRUtUeXJiU2Ft?= =?utf-8?B?Q0duOTlsSDhMdzJ0SitiWlZXUzIvdE5SZDVwSTFaeWFlUnZITWo0YVdoeUwx?= =?utf-8?B?Ly9zRndRa1l1VVFZOGxYWHZUdjkvbFBqeHViNVVENnhZSDRFcEJvQnE0ZHVT?= =?utf-8?B?YWZKYS9tT0xjVHpHcmEzQllaTGU2NEdsWHlBam0xM1N3R3pFdkE2cjhLY0NY?= =?utf-8?B?b1ZkWDR5akxVblNFd3J5TXRnc1BmQW1qaEJTTFJKcDBxQ0pybzNGNkFqSzZj?= =?utf-8?B?cHdPWWdnNTJRajY0UmhZOWtDRFhBK3g1RUZkOHE1WFpqdFRaa2tVYXpVQXRK?= =?utf-8?B?alA2M2JXdzl4RTRHa1ZTVnNkS0gyMStkNUlqNjJmd1hhck1WUHBxZmViQ29t?= =?utf-8?B?a3h2Mk8rUHJBaDdFMWt5L0RRMWhrNTdiQUdSZ2JDMjFhVEZYdjk5c1F1V2dD?= =?utf-8?B?d0JXTXM0Qys4czFrY1BLdzk4TmcxYW1iTEFQZ1VqZXM3c1RIUjZVTnpoOE45?= =?utf-8?Q?VlK0=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <1323876CA143694D9BB4B42E950B541D@amdcloud.onmicrosoft.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL1PR12MB5849.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d1cf0698-0991-41c7-0ea8-08dc39c52fb1 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Mar 2024 07:57:05.0687 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: OFVL9LNPdZ0PptxNOcz6nqjOjBnxu2hak21NHa1Yly7DhUxGdODjBGJbJJDJfd3wb6R1XgETpGd5byy6EqOmiw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR12MB7310 SGkgQmpvcm4sDQpMb29raW5nIGZvcndhcmQgdG8gZ2V0dGluZyB5b3VyIG1vcmUgaW5wdXRzIGFu ZCBzdWdnZXN0aW9ucy4NCkl0IHNlZW1zIC9zeXMvYnVzL2FjcGkvZGV2aWNlcy9QTlAwQTAzOjAw LyBpcyBub3QgYSBnb29kIHBsYWNlIHRvIGNyZWF0ZSBnc2kgc3lzZnMuDQoNCk9uIDIwMjQvMi8x NSAxNjozNywgUm9nZXIgUGF1IE1vbm7DqSB3cm90ZToNCj4gT24gTW9uLCBGZWIgMTIsIDIwMjQg YXQgMDE6MTg6NThQTSAtMDYwMCwgQmpvcm4gSGVsZ2FhcyB3cm90ZToNCj4+IE9uIE1vbiwgRmVi IDEyLCAyMDI0IGF0IDEwOjEzOjI4QU0gKzAxMDAsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6DQo+ Pj4gT24gRnJpLCBGZWIgMDksIDIwMjQgYXQgMDM6MDU6NDlQTSAtMDYwMCwgQmpvcm4gSGVsZ2Fh cyB3cm90ZToNCj4+Pj4gT24gVGh1LCBGZWIgMDEsIDIwMjQgYXQgMDk6Mzk6NDlBTSArMDEwMCwg Um9nZXIgUGF1IE1vbm7DqSB3cm90ZToNCj4+Pj4+IE9uIFdlZCwgSmFuIDMxLCAyMDI0IGF0IDAx OjAwOjE0UE0gLTA2MDAsIEJqb3JuIEhlbGdhYXMgd3JvdGU6DQo+Pj4+Pj4gT24gV2VkLCBKYW4g MzEsIDIwMjQgYXQgMDk6NTg6MTlBTSArMDEwMCwgUm9nZXIgUGF1IE1vbm7DqSB3cm90ZToNCj4+ Pj4+Pj4gT24gVHVlLCBKYW4gMzAsIDIwMjQgYXQgMDI6NDQ6MDNQTSAtMDYwMCwgQmpvcm4gSGVs Z2FhcyB3cm90ZToNCj4+Pj4+Pj4+IE9uIFR1ZSwgSmFuIDMwLCAyMDI0IGF0IDEwOjA3OjM2QU0g KzAxMDAsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6DQo+Pj4+Pj4+Pj4gT24gTW9uLCBKYW4gMjks IDIwMjQgYXQgMDQ6MDE6MTNQTSAtMDYwMCwgQmpvcm4gSGVsZ2FhcyB3cm90ZToNCj4+Pj4+Pj4+ Pj4gT24gVGh1LCBKYW4gMjUsIDIwMjQgYXQgMDc6MTc6MjRBTSArMDAwMCwgQ2hlbiwgSmlxaWFu IHdyb3RlOg0KPj4+Pj4+Pj4+Pj4gT24gMjAyNC8xLzI0IDAwOjAyLCBCam9ybiBIZWxnYWFzIHdy b3RlOg0KPj4+Pj4+Pj4+Pj4+IE9uIFR1ZSwgSmFuIDIzLCAyMDI0IGF0IDEwOjEzOjUyQU0gKzAw MDAsIENoZW4sIEppcWlhbiB3cm90ZToNCj4+Pj4+Pj4+Pj4+Pj4gT24gMjAyNC8xLzIzIDA3OjM3 LCBCam9ybiBIZWxnYWFzIHdyb3RlOg0KPj4+Pj4+Pj4+Pj4+Pj4gT24gRnJpLCBKYW4gMDUsIDIw MjQgYXQgMDI6MjI6MTdQTSArMDgwMCwgSmlxaWFuIENoZW4gd3JvdGU6DQo+Pj4+Pj4+Pj4+Pj4+ Pj4gVGhlcmUgaXMgYSBuZWVkIGZvciBzb21lIHNjZW5hcmlvcyB0byB1c2UgZ3NpIHN5c2ZzLg0K Pj4+Pj4+Pj4+Pj4+Pj4+IEZvciBleGFtcGxlLCB3aGVuIHhlbiBwYXNzdGhyb3VnaCBhIGRldmlj ZSB0byBkdW1VLCBpdCB3aWxsDQo+Pj4+Pj4+Pj4+Pj4+Pj4gdXNlIGdzaSB0byBtYXAgcGlycSwg YnV0IGN1cnJlbnRseSB1c2Vyc3BhY2UgY2FuJ3QgZ2V0IGdzaQ0KPj4+Pj4+Pj4+Pj4+Pj4+IG51 bWJlci4NCj4+Pj4+Pj4+Pj4+Pj4+PiBTbywgYWRkIGdzaSBzeXNmcyBmb3IgdGhhdCBhbmQgZm9y IG90aGVyIHBvdGVudGlhbCBzY2VuYXJpb3MuDQo+Pj4+Pj4+Pj4+Pj4+IC4uLg0KPj4+Pj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pj4+Pj4+PiBJIGRvbid0IGtub3cgZW5vdWdoIGFib3V0IFhlbiB0byBrbm93 IHdoeSBpdCBuZWVkcyB0aGUgR1NJIGluDQo+Pj4+Pj4+Pj4+Pj4+PiB1c2Vyc3BhY2UuICBJcyB0 aGlzIHBhc3N0aHJvdWdoIGJyYW5kIG5ldyBmdW5jdGlvbmFsaXR5IHRoYXQgY2FuJ3QgYmUNCj4+ Pj4+Pj4+Pj4+Pj4+IGRvbmUgdG9kYXkgYmVjYXVzZSB3ZSBkb24ndCBleHBvc2UgdGhlIEdTSSB5 ZXQ/DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IEkgYXNzdW1lIHRoaXMgbXVzdCBiZSBuZXcgZnVu Y3Rpb25hbGl0eSwgaS5lLiwgdGhpcyBraW5kIG9mDQo+Pj4+Pj4+Pj4+IHBhc3N0aHJvdWdoIGRv ZXMgbm90IHdvcmsgdG9kYXksIHJpZ2h0Pw0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+PiBoYXMg QUNQSSBzdXBwb3J0IGFuZCBpcyByZXNwb25zaWJsZSBmb3IgZGV0ZWN0aW5nIGFuZCBjb250cm9s bGluZw0KPj4+Pj4+Pj4+Pj4+PiB0aGUgaGFyZHdhcmUsIGFsc28gaXQgcGVyZm9ybXMgcHJpdmls ZWdlZCBvcGVyYXRpb25zIHN1Y2ggYXMgdGhlDQo+Pj4+Pj4+Pj4+Pj4+IGNyZWF0aW9uIG9mIG5v cm1hbCAodW5wcml2aWxlZ2VkKSBkb21haW5zIERvbVVzLiBXaGVuIHdlIGdpdmUgdG8gYQ0KPj4+ Pj4+Pj4+Pj4+PiBEb21VIGRpcmVjdCBhY2Nlc3MgdG8gYSBkZXZpY2UsIHdlIG5lZWQgYWxzbyB0 byByb3V0ZSB0aGUgcGh5c2ljYWwNCj4+Pj4+Pj4+Pj4+Pj4gaW50ZXJydXB0cyB0byB0aGUgRG9t VS4gSW4gb3JkZXIgdG8gZG8gc28gWGVuIG5lZWRzIHRvIHNldHVwIGFuZCBtYXANCj4+Pj4+Pj4+ Pj4+Pj4gdGhlIGludGVycnVwdHMgYXBwcm9wcmlhdGVseS4NCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+Pj4+IFdoYXQga2VybmVsIGludGVyZmFjZXMgYXJlIHVzZWQgZm9yIHRoaXMgc2V0dXAgYW5k IG1hcHBpbmc/DQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4gRm9yIHBhc3N0aHJvdWdoIGRldmlj ZXMsIHRoZSBzZXR1cCBhbmQgbWFwcGluZyBvZiByb3V0aW5nIHBoeXNpY2FsDQo+Pj4+Pj4+Pj4+ PiBpbnRlcnJ1cHRzIHRvIERvbVUgYXJlIGRvbmUgb24gWGVuIGh5cGVydmlzb3Igc2lkZSwgaHlw ZXJ2aXNvciBvbmx5DQo+Pj4+Pj4+Pj4+PiBuZWVkIHVzZXJzcGFjZSB0byBwcm92aWRlIHRoZSBH U0kgaW5mbywgc2VlIFhlbiBjb2RlOg0KPj4+Pj4+Pj4+Pj4geGNfcGh5c2Rldl9tYXBfcGlycSBy ZXF1aXJlIEdTSSBhbmQgdGhlbiB3aWxsIGNhbGwgaHlwZXJjYWxsIHRvIHBhc3MNCj4+Pj4+Pj4+ Pj4+IEdTSSBpbnRvIGh5cGVydmlzb3IgYW5kIHRoZW4gaHlwZXJ2aXNvciB3aWxsIGRvIHRoZSBt YXBwaW5nIGFuZA0KPj4+Pj4+Pj4+Pj4gcm91dGluZywga2VybmVsIGRvZXNuJ3QgZG8gdGhlIHNl dHVwIGFuZCBtYXBwaW5nLg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBTbyB3ZSBoYXZlIHRvIGV4 cG9zZSB0aGUgR1NJIHRvIHVzZXJzcGFjZSBub3QgYmVjYXVzZSB1c2Vyc3BhY2UgaXRzZWxmDQo+ Pj4+Pj4+Pj4+IHVzZXMgaXQsIGJ1dCBzbyB1c2Vyc3BhY2UgY2FuIHR1cm4gYXJvdW5kIGFuZCBw YXNzIGl0IGJhY2sgaW50byB0aGUNCj4+Pj4+Pj4+Pj4ga2VybmVsPw0KPj4+Pj4+Pj4+DQo+Pj4+ Pj4+Pj4gTm8sIHRoZSBwb2ludCBpcyB0byBwYXNzIGl0IGJhY2sgdG8gWGVuLCB3aGljaCBkb2Vz bid0IGtub3cgdGhlDQo+Pj4+Pj4+Pj4gbWFwcGluZyBiZXR3ZWVuIEdTSXMgYW5kIFBDSSBkZXZp Y2VzIGJlY2F1c2UgaXQgY2FuJ3QgZXhlY3V0ZSB0aGUgQUNQSQ0KPj4+Pj4+Pj4+IEFNTCByZXNv dXJjZSBtZXRob2RzIHRoYXQgcHJvdmlkZSBzdWNoIGluZm9ybWF0aW9uLg0KPj4+Pj4+Pj4+DQo+ Pj4+Pj4+Pj4gVGhlIChMaW51eCkga2VybmVsIGlzIGp1c3QgYSBwcm94eSB0aGF0IGZvcndhcmRz IHRoZSBoeXBlcmNhbGxzIGZyb20NCj4+Pj4+Pj4+PiB1c2VyLXNwYWNlIHRvb2xzIGludG8gWGVu Lg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IEJ1dCBJIGd1ZXNzIFhlbiBrbm93cyBob3cgdG8gaW50ZXJw cmV0IGEgR1NJIGV2ZW4gdGhvdWdoIGl0IGRvZXNuJ3QNCj4+Pj4+Pj4+IGhhdmUgYWNjZXNzIHRv IEFNTD8NCj4+Pj4+Pj4NCj4+Pj4+Pj4gT24geDg2IFhlbiBkb2VzIGtub3cgaG93IHRvIG1hcCBh IEdTSSBpbnRvIGFuIElPLUFQSUMgcGluLCBpbiBvcmRlcg0KPj4+Pj4+PiBjb25maWd1cmUgdGhl IFJURSBhcyByZXF1ZXN0ZWQuDQo+Pj4+Pj4NCj4+Pj4+PiBJSVVDLCBtYXBwaW5nIGEgR1NJIHRv IGFuIElPLUFQSUMgcGluIHJlcXVpcmVzIGluZm9ybWF0aW9uIGZyb20gdGhlDQo+Pj4+Pj4gTUFE VC4gIFNvIEkgZ3Vlc3MgWGVuIGRvZXMgdXNlIHRoZSBzdGF0aWMgQUNQSSB0YWJsZXMsIGJ1dCBu b3QgdGhlIEFNTA0KPj4+Pj4+IF9QUlQgbWV0aG9kcyB0aGF0IHdvdWxkIGNvbm5lY3QgYSBHU0kg d2l0aCBhIFBDSSBkZXZpY2U/DQo+Pj4+Pg0KPj4+Pj4gWWVzLCBYZW4gY2FuIHBhcnNlIHRoZSBz dGF0aWMgdGFibGVzLCBhbmQga25vd3MgdGhlIGJhc2UgR1NJIG9mDQo+Pj4+PiBJTy1BUElDcyBm cm9tIHRoZSBNQURULg0KPj4+Pj4NCj4+Pj4+PiBJIGd1ZXNzIHRoaXMgbWVhbnMgWGVuIHdvdWxk IG5vdCBiZSBhYmxlIHRvIGRlYWwgd2l0aCBfTUFUIG1ldGhvZHMsDQo+Pj4+Pj4gd2hpY2ggYWxz byBjb250YWlucyBNQURUIGVudHJpZXM/ICBJIGRvbid0IGtub3cgdGhlIGltcGxpY2F0aW9ucyBv Zg0KPj4+Pj4+IHRoaXMgLS0gbWF5YmUgaXQgbWVhbnMgWGVuIG1pZ2h0IG5vdCBiZSBhYmxlIHRv IHVzZSB3aXRoIGhvdC1hZGRlZA0KPj4+Pj4+IGRldmljZXM/DQo+Pj4+Pg0KPj4+Pj4gSXQncyBt eSB1bmRlcnN0YW5kaW5nIF9NQVQgd2lsbCBvbmx5IGJlIHByZXNlbnQgb24gc29tZSB2ZXJ5IHNw ZWNpZmljDQo+Pj4+PiBkZXZpY2VzIChJTy1BUElDIG9yIENQVSBvYmplY3RzKS4gIFhlbiBkb2Vz bid0IHN1cHBvcnQgaG90cGx1ZyBvZg0KPj4+Pj4gSU8tQVBJQ3MsIGJ1dCBob3RwbHVnIG9mIENQ VXMgc2hvdWxkIGluIHByaW5jaXBsZSBiZSBzdXBwb3J0ZWQgd2l0aA0KPj4+Pj4gY29vcGVyYXRp b24gZnJvbSB0aGUgY29udHJvbCBkb21haW4gT1MgKGFsYmVpdCBpdCdzIG5vdCBzb21ldGhpbmcg dGhhdA0KPj4+Pj4gd2UgdGVzdHMgb24gb3VyIENJKS4gIEkgZG9uJ3QgZXhwZWN0IGhvd2V2ZXIg dGhhdCBhIENQVSBvYmplY3QgX01BVA0KPj4+Pj4gbWV0aG9kIHdpbGwgcmV0dXJuIElPIEFQSUMg ZW50cmllcy4NCj4+Pj4+DQo+Pj4+Pj4gVGhlIHRhYmxlcyAoaW5jbHVkaW5nIERTRFQgYW5kIFNT RFRTIHRoYXQgY29udGFpbiB0aGUgQU1MKSBhcmUgZXhwb3NlZA0KPj4+Pj4+IHRvIHVzZXJzcGFj ZSB2aWEgL3N5cy9maXJtd2FyZS9hY3BpL3RhYmxlcy8sIGJ1dCBvZiBjb3Vyc2UgdGhhdA0KPj4+ Pj4+IGRvZXNuJ3QgbWVhbiBYZW4ga25vd3MgaG93IHRvIGludGVycHJldCB0aGUgQU1MLCBhbmQg ZXZlbiBpZiBpdCBkaWQsDQo+Pj4+Pj4gWGVuIHByb2JhYmx5IHdvdWxkbid0IGJlIGFibGUgdG8g KmV2YWx1YXRlKiBpdCBzaW5jZSB0aGF0IGNvdWxkDQo+Pj4+Pj4gY29uZmxpY3Qgd2l0aCB0aGUg aG9zdCBrZXJuZWwncyB1c2Ugb2YgQU1MLg0KPj4+Pj4NCj4+Pj4+IEluZGVlZCwgdGhlcmUgY2Fu IG9ubHkgYmUgYSBzaW5nbGUgT1NQTSwgYW5kIHRoYXQncyB0aGUgZG9tMCBPUyAoTGludXgNCj4+ Pj4+IGluIG91ciBjb250ZXh0KS4NCj4+Pj4+DQo+Pj4+PiBHZXR0aW5nIGJhY2sgdG8gb3VyIGNv bnRleHQgdGhvdWdoLCB3aGF0IHdvdWxkIGJlIGEgc3VpdGFibGUgcGxhY2UgZm9yDQo+Pj4+PiBl eHBvc2luZyB0aGUgR1NJIGFzc2lnbmVkIHRvIGVhY2ggZGV2aWNlPw0KPj4+Pg0KPj4+PiBJSVVD LCB0aGUgWGVuIGh5cGVydmlzb3I6DQo+Pj4+DQo+Pj4+ICAgLSBJbnRlcnByZXRzIC9zeXMvZmly bXdhcmUvYWNwaS90YWJsZXMvQVBJQyAob3IgZ2V0cyB0aGlzIHZpYQ0KPj4+PiAgICAgc29tZXRo aW5nIHJ1bm5pbmcgb24gdGhlIERvbTAga2VybmVsKSB0byBmaW5kIHRoZSBwaHlzaWNhbCBiYXNl DQo+Pj4+ICAgICBhZGRyZXNzIGFuZCBHU0kgYmFzZSwgZS5nLiwgZnJvbSBJL08gQVBJQywgSS9P IFNBUElDLg0KPj4+DQo+Pj4gTm8sIFhlbiBwYXJzZXMgdGhlIE1BRFQgZGlyZWN0bHkgZnJvbSBt ZW1vcnksIGJlZm9yZSBzdGF0aW5nIGRvbTAuDQo+Pj4gVGhhdCdzIGEgc3RhdGljIHRhYmxlIHNv IGl0J3MgZmluZSBmb3IgWGVuIHRvIHBhcnNlIGl0IGFuZCBvYnRhaW4gdGhlDQo+Pj4gSS9PIEFQ SUMgR1NJIGJhc2UuDQo+Pg0KPj4gSXQncyBhbiBpbnRlcmVzdGluZyBzcGxpdCB0byBjb25zdW1l IEFDUEkgc3RhdGljIHRhYmxlcyBkaXJlY3RseSBidXQNCj4+IHB1dCB0aGUgQU1MIGludGVycHJl dGVyIGVsc2V3aGVyZS4NCj4gDQo+IFdlbGwsIHN0YXRpYyB0YWJsZXMgY2FuIGJlIGNvbnN1bWVk IGJ5IFhlbiwgYmVjYXVzZSB0aHllIGRvbid0IHJlcXVpcmUNCj4gYW4gQU1MIHBhcnNlciAob2J2 aW91c2x5KSwgYW5kIHBhcnNpbmcgdGhlbSBkb2Vzbid0IGhhdmUgYW55DQo+IHNpZGUtZWZmZWN0 cyB0aGF0IHdvdWxkIHByZXZlbnQgZG9tMCBmcm9tIGJlaW5nIHRoZSBPU1BNIChubyBtZXRob2Rz DQo+IG9yIHNpbWlsYXIgYXJlIGV2YWx1YXRlZCkuDQo+IA0KPj4gSSBkb3VidCB0aGUgQUNQSSBz cGVjIGVudmlzaW9uZWQNCj4+IHRoYXQsIHdoaWNoIG1ha2VzIG1lIHdvbmRlciB3aGF0IG90aGVy IHRoaW5ncyB3ZSBjb3VsZCB0cmlwIG92ZXIsIGJ1dA0KPj4gdGhhdCdzIGp1c3QgYSB0YW5nZW50 Lg0KPiANCj4gSW5kZWVkLCBBQ1BJIGlzIG5vdCBiZSBiZXN0IGludGVyZmFjZSBmb3IgdGhlIFhl bi9kb20wIHNwbGl0IG1vZGVsLg0KPiANCj4+Pj4gICAtIE5lZWRzIHRoZSBHU0kgdG8gbG9jYXRl IHRoZSBBUElDIGFuZCBwaW4gd2l0aGluIHRoZSBBUElDLiAgVGhlDQo+Pj4+ICAgICBEb20wIGtl cm5lbCBpcyB0aGUgT1NQTSwgc28gb25seSBpdCBjYW4gZXZhbHVhdGUgdGhlIEFNTCBfUFJUIHRv DQo+Pj4+ICAgICBsZWFybiB0aGUgUENJIGRldmljZSAtPiBHU0kgbWFwcGluZy4NCj4+Pg0KPj4+ IFllcywgWGVuIGRvZXNuJ3Qga25vdyB0aGUgUENJIGRldmljZSAtPiBHU0kgbWFwcGluZy4gIERv bTAgbmVlZHMgdG8NCj4+PiBwYXJzZSB0aGUgQUNQSSBtZXRob2RzIGFuZCBzaWduYWwgWGVuIHRv IGNvbmZpZ3VyZSBhIEdTSSB3aXRoIGENCj4+PiBnaXZlbiB0cmlnZ2VyIGFuZCBwb2xhcml0eS4N Cj4+Pg0KPj4+PiAgIC0gSGFzIGRpcmVjdCBhY2Nlc3MgdG8gdGhlIEFQSUMgcGh5c2ljYWwgYmFz ZSBhZGRyZXNzIHRvIHByb2dyYW0gdGhlDQo+Pj4+ICAgICBSZWRpcmVjdGlvbiBUYWJsZS4NCj4+ Pg0KPj4+IFllcywgdGhlIGhhcmR3YXJlIChuYXRpdmUpIEkvTyBBUElDIGlzIG93bmVkIGJ5IFhl biwgYW5kIG5vdCBkaXJlY3RseQ0KPj4+IGFjY2Vzc2libGUgYnkgZG9tMC4NCj4+Pg0KPj4+PiBU aGUgcGF0Y2ggc2VlbXMgYSBsaXR0bGUgbWVzc3kgdG8gbWUgYmVjYXVzZSB0aGUgUENJIGNvcmUg aGFzIHRvIGtlZXANCj4+Pj4gdHJhY2sgb2YgdGhlIEdTSSBldmVuIHRob3VnaCBpdCBkb2Vzbid0 IG5lZWQgaXQgaXRzZWxmLiAgQW5kIHRoZQ0KPj4+PiBjdXJyZW50IHBhdGNoIGV4cG9zZXMgaXQg b24gYWxsIGFyY2hlcywgZXZlbiBub24tQUNQSSBvbmVzIG9yIHdoZW4NCj4+Pj4gQUNQSSBpcyBk aXNhYmxlZCAoZWFzaWx5IGZpeGFibGUpLg0KPj4+Pg0KPj4+PiBXZSBvbmx5IGNhbGwgYWNwaV9w Y2lfaXJxX2VuYWJsZSgpIGluIHRoZSBwY2lfZW5hYmxlX2RldmljZSgpIHBhdGgsIHNvDQo+Pj4+ IHdlIGRvbid0IGtub3cgdGhlIEdTSSB1bmxlc3MgYSBEb20wIGRyaXZlciBoYXMgY2xhaW1lZCB0 aGUgZGV2aWNlIGFuZA0KPj4+PiBjYWxsZWQgcGNpX2VuYWJsZV9kZXZpY2UoKSBmb3IgaXQsIHdo aWNoIHNlZW1zIGxpa2UgaXQgbWlnaHQgbm90IGJlDQo+Pj4+IGRlc2lyYWJsZS4NCj4+Pg0KPj4+ IEkgdGhpbmsgdGhhdCdzIGFsd2F5cyB0aGUgY2FzZSwgYXMgb24gZG9tMCBkZXZpY2VzIHRvIGJl IHBhc3NlZA0KPj4+IHRocm91Z2ggYXJlIGhhbmRsZWQgYnkgcGNpYmFjayB3aGljaCBkb2VzIGVu YWJsZSB0aGVtLg0KPj4NCj4+IHBjaXN0dWJfaW5pdF9kZXZpY2UoKSBsYWJlbHMgdGhlIHBjaV9l bmFibGVfZGV2aWNlKCkgYXMgYSAiSEFDSyINCj4+IHJlbGF0ZWQgdG8gZGV0ZXJtaW5pbmcgdGhl IElSUSwgd2hpY2ggbWFrZXMgbWUgdGhpbmsgdGhlcmUncyBub3QNCj4+IHJlYWxseSBhIHJlcXVp cmVtZW50IGZvciB0aGUgZGV2aWNlIHRvIGJlICplbmFibGVkKiAoQkFSIGRlY29kaW5nDQo+PiBl bmFibGVkKSBieSBkb20wLg0KPiANCj4gTm8sIHRoZXJlJ3Mgbm8gbmVlZCBmb3IgbWVtb3J5IGRl Y29kaW5nIHRvIGJlIGVuYWJsZWQgZm9yIGdldHRpbmcgdGhlDQo+IEdTSSBmcm9tIHRoZSBBQ1BJ IG1ldGhvZCBJIHdvdWxkIGFzc3VtZS4gIEknbSBjb25mdXNlZCBieSB0aGF0DQo+IHBjaV9lbmFi bGVfZGV2aWNlKCkgY2FsbC4gIElzIG1heWJlIHRoZSBwdXJwb3NlIHRvIG1ha2Ugc3VyZSB0aGUN Cj4gZGV2aWNlIGlzIHBvd2VyZWQgdXAgc28gdGhhdCByZWFkaW5nIHRoZSBQQ0kgaGVhZGVyIElu dGVycnVwdCBMaW5lIGFuZA0KPiBQaW4gZmllbGRzIHJldHVybnMgdmFsaWQgdmFsdWVzPyAgTm8g aWRlYSB3aGV0aGVyIHJlYWRpbmcgdGhvc2UgZmllbGRzDQo+IHJlcXVpcmVzIHRoZSBkZXZpY2Ug dG8gYmUgaW4gY2VydGFpbiAoYWN0aXZlKSBwb3dlciBzdGF0ZXMuDQo+IA0KPj4+IEkgYWdyZWUg aXQgbWlnaHQgYmUgYmVzdCB0byBub3QgdGllIGV4cG9zaW5nIHRoZSBub2RlIHRvDQo+Pj4gcGNp X2VuYWJsZV9kZXZpY2UoKSBoYXZpbmcgYmVlbiBjYWxsZWQuICBJcyBfUFJUIG9ubHkgZXZhbHVh dGVkIGFzDQo+Pj4gcGFydCBvZiBhY3BpX3BjaV9pcnFfZW5hYmxlKCk/IChvciBwY2lfZW5hYmxl X2RldmljZSgpKS4NCj4+DQo+PiBZZXMuICBBRkFJQ1QsIGFjcGlfcGNpX2lycV9lbmFibGUoKSBp cyB0aGUgb25seSBwYXRoIHRoYXQgZXZhbHVhdGVzDQo+PiBfUFJUIChleGNlcHQgZm9yIGEgZGVi dWdnZXIgaW50ZXJmYWNlKS4gIEkgZG9uJ3QgdGhpbmsgaXQgKm5lZWRzKiB0bw0KPj4gYmUgdGhh dCB3YXksIGFuZCB0aGUgZmFjdCB0aGF0IHdlIGRvIGl0IHBlci1kZXZpY2UgbGlrZSB0aGF0IG1l YW5zIHdlDQo+PiBldmFsdWF0ZSBfUFJUIG1hbnkgdGltZXMgZXZlbiB0aG91Z2ggSSB0aGluayB0 aGUgcmVzdWx0cyBuZXZlciBjaGFuZ2UuDQo+Pg0KPj4gSSBjb3VsZCBpbWFnaW5lIGV2YWx1YXRp bmcgX1BSVCBvbmNlIGFzIHBhcnQgb2YgZW51bWVyYXRpbmcgYSBQQ0kgaG9zdA0KPj4gYnJpZGdl IChhbmQgbWF5YmUgUENJLVBDSSBicmlkZ2UsIHBlciBhY3BpX3BjaV9pcnFfZmluZF9wcnRfZW50 cnkoKQ0KPj4gY29tbWVudCksIGJ1dCB0aGF0IGxvb2tzIGxpa2UgYSBmYWlyIGJpdCBvZiB3b3Jr IHRvIGltcGxlbWVudC4gIEFuZCBvZg0KPj4gY291cnNlIGl0IGRvZXNuJ3QgcmVhbGx5IGFmZmVj dCB0aGUgcXVlc3Rpb24gb2YgaG93IHRvIGV4cG9zZSB0aGUNCj4+IHJlc3VsdCwgYWx0aG91Z2gg aXQgZG9lcyBzdWdnZXN0IC9zeXMvYnVzL2FjcGkvZGV2aWNlcy9QTlAwQTAzOjAwLyBhcw0KPj4g YSBwb3NzaWJsZSBsb2NhdGlvbi4NCj4gDQo+IFNvIHlvdSBzdWdnZXN0IGV4cG9zaW5nIHRoZSBH U0kgYXMgcGFydCBvZiB0aGUgUENJIGhvc3QgYnJpZGdlPyAgSSdtDQo+IGFmcmFpZCBJJ20gbm90 IGZvbGxvd2luZyBob3cgd2UgY291bGQgdGhlbiBtYXAgUENJIFNCREZzIGZyb20gZGV2aWNlcw0K PiB0byB0aGVpciBhc3NpZ25lZCBHU0kuDQo+IA0KPiBUaGFua3MsIFJvZ2VyLg0KDQotLSANCkJl c3QgcmVnYXJkcywNCkppcWlhbiBDaGVuLg0K From xen-devel-bounces@lists.xenproject.org Fri Mar 01 08:00:38 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2024 08:00:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687544.1071144 (Exim 4.92) (envelope-from ) id 1rfxom-0005Qo-EO; Fri, 01 Mar 2024 08:00:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687544.1071144; Fri, 01 Mar 2024 08:00:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rfxom-0005Qh-Ai; Fri, 01 Mar 2024 08:00:32 +0000 Received: by outflank-mailman (input) for mailman id 687544; Fri, 01 Mar 2024 08:00:31 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rfxol-0005QY-HE for xen-devel@lists.xenproject.org; Fri, 01 Mar 2024 08:00:31 +0000 Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [2a00:1450:4864:20::535]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id c54e944e-d7a1-11ee-a1ee-f123f15fe8a2; Fri, 01 Mar 2024 09:00:29 +0100 (CET) Received: by mail-ed1-x535.google.com with SMTP id 4fb4d7f45d1cf-563c595f968so2937219a12.0 for ; Fri, 01 Mar 2024 00:00:29 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id c6-20020a056402100600b0056536eed484sm1333175edu.35.2024.03.01.00.00.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 01 Mar 2024 00:00:28 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c54e944e-d7a1-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709280029; x=1709884829; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=TgP3Bhg8MMx/SPRD+mpmnqumdjzFozPtIfe1ED0gCMU=; b=aJm8vcSDo31jko9qP8sKR52kDMLc2eJvurdGDGJfgPGGCzTsU8auQ8sMWOb8eITOUf qA1nElt3o7uDfWtA8q/1TcS9ezLeSC9/AIU0nZh2RKhDBOrh9eoMPlib/bKnxV5zYfve L9O0N6fBx+3empMN/4zku0v12qO3NOOcpxS3y5ktbrQKhSAehEpWNrtxdGGUVfXGU0T6 SNiZwflW42KizDjaF3MUNADvM1rd0+XOLnk7ZJ8ug0NtyuAFDRxLrrw06bBLoiBshVid B0ocB0Dd4eevx/0Vx21SsrDjpvnqXOcWHGZd4MlyrOOS6rOVjpccxMfB0ZgStb+g/uoT RuFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709280029; x=1709884829; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=TgP3Bhg8MMx/SPRD+mpmnqumdjzFozPtIfe1ED0gCMU=; b=uclrvQeKNt3F0fgWSskiyVWjiokdKOLdpCPy19i28zS++Hb16eLbfJZD2jgTWxzERX 4YQkZ0ldVioT4xKAj/vLLMOvz934ArPzc44F6LoqVwcThct9HqZm2tJZU1QzhnBF1u5X ONI00TTQ5WUBT0bPRBBBipXMg05sfA6gTD+TyRUMAFg0IQXZlWfscqkKrHULs0C3C+pP p0pS23mqFh8mt1xNyYbqKjyLUW/EshuLvlgJduB5eJjdVXlE8f0tdAK9TOAofwZiVZWv 7JjaI4keyQ+qmLQWr85fkFcLPaY9NdkPv4svZonZgNDAqvVou2cYgqaRfY/fdCk5Myw9 SxQw== X-Gm-Message-State: AOJu0YyobpkwbtPpHqBPaaoHA41AQegVVqz+n9oIVI7PIww/N8Z+Je3Z UFzTN7oinpXk/6z/69/hpn+lOKT2ktiuzVKNldZnKDFG3aZ53E2+/rxyO/zB6w== X-Google-Smtp-Source: AGHT+IHoOuykpgluUCNlE3V/XHH5yIETsXFGtpYR0+G6yWhmGlXHMKeCB9Ly8OuKrvCvArVKoCi4RQ== X-Received: by 2002:a05:6402:31ae:b0:566:1725:1c86 with SMTP id dj14-20020a05640231ae00b0056617251c86mr635537edb.12.1709280029112; Fri, 01 Mar 2024 00:00:29 -0800 (PST) Message-ID: <1afd8805-7365-40ec-8e8e-468a83e20c40@suse.com> Date: Fri, 1 Mar 2024 09:00:27 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH 10/10] xen/keyhandler: address violations of MISRA C Rule 20.7 Content-Language: en-US To: Stefano Stabellini Cc: xen-devel@lists.xenproject.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, consulting@bugseng.com, andrew.cooper3@citrix.com, roger.pau@citrix.com, bertrand.marquis@arm.com, julien@xen.org, George Dunlap , Wei Liu , Nicola Vetrini References: <2bc4a964f0f2f47488e72237678e944dbdbd7bb7.1709219010.git.nicola.vetrini@bugseng.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 29.02.2024 23:57, Stefano Stabellini wrote: > On Thu, 29 Feb 2024, Nicola Vetrini wrote: >> MISRA C Rule 20.7 states: "Expressions resulting from the expansion >> of macro parameters shall be enclosed in parentheses". Therefore, some >> macro definitions should gain additional parentheses to ensure that all >> current and future users will be safe with respect to expansions that >> can possibly alter the semantics of the passed-in macro parameter. >> >> No functional change. >> >> Signed-off-by: Nicola Vetrini > > Reviewed-by: Stefano Stabellini You did see the discussion on earlier patches, though? I don't think any of the parentheses here are needed or wanted. Jan From xen-devel-bounces@lists.xenproject.org Fri Mar 01 08:00:59 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2024 08:00:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687546.1071153 (Exim 4.92) (envelope-from ) id 1rfxpD-0005sy-LA; Fri, 01 Mar 2024 08:00:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687546.1071153; Fri, 01 Mar 2024 08:00:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rfxpD-0005sr-IT; Fri, 01 Mar 2024 08:00:59 +0000 Received: by outflank-mailman (input) for mailman id 687546; Fri, 01 Mar 2024 08:00:58 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rfxpC-0005QY-4s for xen-devel@lists.xenproject.org; Fri, 01 Mar 2024 08:00:58 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id d530558e-d7a1-11ee-a1ee-f123f15fe8a2; Fri, 01 Mar 2024 09:00:56 +0100 (CET) Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) by support.bugseng.com (Postfix) with ESMTPA id ADA174EE0737; Fri, 1 Mar 2024 09:00:55 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d530558e-d7a1-11ee-a1ee-f123f15fe8a2 MIME-Version: 1.0 Date: Fri, 01 Mar 2024 09:00:55 +0100 From: Nicola Vetrini To: Stefano Stabellini Cc: Stefano Stabellini , xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com, jbeulich@suse.com, george.dunlap@citrix.com, julien@xen.org, bertrannd.marquis@arm.com, roger.pau@citrix.com, roberto.bagnara@bugseng.com, federico.serafini@bugseng.com, Luca.Fancellu@arm.com, michal.orzel@amd.com Subject: Re: [PATCH v2 1/3] docs/misra/rules.rst: add rule 16.6 and 20.12 In-Reply-To: References: <20240213223334.3693410-1-stefano.stabellini@amd.com> Message-ID: <0dbad2c350e1f6a9af081dc6d4589ae5@bugseng.com> X-Sender: nicola.vetrini@bugseng.com Organization: BUGSENG s.r.l. Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 2024-03-01 02:56, Stefano Stabellini wrote: > Hi all, > > This patch broke gitlab-ci. The jobs failing are the cppcheck jobs. > > xen/scripts/xen-analysis.py --run-cppcheck --cppcheck-misra -- -j80 > No summary for rule 20.12 > WARNING: Can't open > /builds/xen-project/hardware/xen/xen/drivers/video/font_8x14.c: 'utf-8' > codec can't decode byte 0x9f in position 7228: invalid start byte > WARNING: Can't open > /builds/xen-project/hardware/xen/xen/drivers/video/font_8x16.c: 'utf-8' > codec can't decode byte 0x80 in position 5436: invalid start byte > WARNING: Can't open > /builds/xen-project/hardware/xen/xen/drivers/video/font_8x8.c: 'utf-8' > codec can't decode byte 0x80 in position 4410: invalid start byte > ERROR: An error occured when running: > /builds/xen-project/hardware/xen/xen/tools/convert_misra_doc.py -i > /builds/xen-project/hardware/xen/docs/misra/rules.rst -o > /builds/xen-project/hardware/xen/xen/cppcheck-misra.txt -j > /builds/xen-project/hardware/xen/xen/cppcheck-misra.json > > I'll look into it as soon as possible. > > > On Tue, 13 Feb 2024, Stefano Stabellini wrote: >> Signed-off-by: Stefano Stabellini >> --- >> docs/misra/rules.rst | 13 +++++++++++++ >> 1 file changed, 13 insertions(+) >> >> diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst >> index 182331089d..c185366966 100644 >> --- a/docs/misra/rules.rst >> +++ b/docs/misra/rules.rst >> @@ -478,6 +478,12 @@ maintainers if you want to suggest a change. >> adhere to Rule 16.2 would result in increased complexity and >> maintenance difficulty, and could potentially introduce bugs. >> >> + * - `Rule 16.6 >> `_ >> + - Required >> + - Every switch statement shall have at least two switch-clauses >> + - Single-clause switches are allowed when they do not involve a >> + default label. >> + >> * - `Rule 16.7 >> `_ >> - Required >> - A switch-expression shall not have essentially Boolean type >> @@ -554,6 +560,13 @@ maintainers if you want to suggest a change. >> evaluation >> - >> >> + * - `Rule 20.12 >> `_ >> + - A macro parameter used as an operand to the # or ## operators, >> + which is itself subject to further macro replacement, shall >> only >> + be used as an operand to these operators >> + - Required >> + - Variadic macros are allowed to violate the rule. >> + I think here it wants the strictness "Required" first, and then the headline second "A macro parameter..." >> * - `Rule 20.13 >> `_ >> - Required >> - A line whose first token is # shall be a valid preprocessing >> -- >> 2.25.1 >> >> -- Nicola Vetrini, BSc Software Engineer, BUGSENG srl (https://bugseng.com) From xen-devel-bounces@lists.xenproject.org Fri Mar 01 08:06:26 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2024 08:06:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687551.1071164 (Exim 4.92) (envelope-from ) id 1rfxuQ-0006XS-5u; Fri, 01 Mar 2024 08:06:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687551.1071164; Fri, 01 Mar 2024 08:06:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rfxuQ-0006XL-37; Fri, 01 Mar 2024 08:06:22 +0000 Received: by outflank-mailman (input) for mailman id 687551; Fri, 01 Mar 2024 08:06:21 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rfxuP-0006XF-5r for xen-devel@lists.xenproject.org; Fri, 01 Mar 2024 08:06:21 +0000 Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [2a00:1450:4864:20::635]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 95909928-d7a2-11ee-afd8-a90da7624cb6; Fri, 01 Mar 2024 09:06:19 +0100 (CET) Received: by mail-ej1-x635.google.com with SMTP id a640c23a62f3a-a43f922b2c5so223395266b.3 for ; Fri, 01 Mar 2024 00:06:19 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id cu5-20020a170906ba8500b00a440ec600e3sm1445287ejd.121.2024.03.01.00.06.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 01 Mar 2024 00:06:18 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 95909928-d7a2-11ee-afd8-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709280378; x=1709885178; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=Vu98p8LnTxmb+1I39q3SzcyfjUa4FkllL1OT0SWSmtw=; b=MYmjL/Cs/oWFMrL1N3dOa1nqZ6lE3xAZpDUfgc7eqE2yDmNSeRpiHmeBGaD6m6W3Cv 84JwxzN3fx26zZksVM1PlNlkJO6Bhk9AjYmw2wPWXDkqtZsikUE8Hk8D8VIOs3PVTYtE Sg6kqNO76E6lsIniWtvIcWw3mRPNrmMC3HyoWzPPDirg9i7/plvJEyRnJuDJtg1x4zwT +vRJJY/KN9jIlCt8Z+qtqHJ4qgJbw06A58Ie02cqKMP5kePytvL9g2z2qMDSZ5oiqbUz 07hqhGWfedxaYPQi+8kxsOjBQPerD7UlcEt7xjqKEjpop4TPwFl5ZC4kzCSuBtSLiHqX orlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709280378; x=1709885178; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Vu98p8LnTxmb+1I39q3SzcyfjUa4FkllL1OT0SWSmtw=; b=dFXpU++O4HAhJUbMvSEp8UTF7lF9FVt/8cmS3QXJEpiWkykg3jpeJcIJBBJPS/c6Tj TfX2r+Nv/eW+0vxo1DHOBNnc1+0AE+XFZwDDNbA4hgYOd+WKjZpicQZgp6OeLqs6dOFu B6c++g41cngWytmrt1u1Q0VDLXzM7cOM/LiBV7zxaVl9T+HnI6YNI8GJcr8XJYAv2nU5 5bvtaiyYDFuUNhhs1fFNDyJST0Ge7COTlYvp6MLgPe1k3gr/ze6SSmB4TUzw9RNG/4lz o9hIfMbOX5+T9PmqX3UtlCfaAjf+w3fAJlyE8JU5769OE/kh7jgb75wvP+1xndwwf3R0 K59w== X-Forwarded-Encrypted: i=1; AJvYcCXQ/WA6/yUeSTK9ICUGb0RdQwoe785km3PpU1/ZVrHpsJiL6j+S588/vDvW9qdd4q54zfOKhq38Wzs0XDqeyXUPp4Um/XX0NRpDQvtX8sk= X-Gm-Message-State: AOJu0Yy3SDahnODX+1bqRadU/2ryPdlIVK7y3XUUd9y/YlUPy6q0KVaI h94atzqVmh5d9b7E+gvJWvcjTrH2m8YxVH3EULAMRf1FAhHjioQWRtxHMTb8nQ== X-Google-Smtp-Source: AGHT+IF84/UStCCiSLAbR1Go0njvKa2HICQ7eRYzVP+6TOrTGka5O/04+X8wb7KC/aCw/6Cuwlu3Mw== X-Received: by 2002:a17:906:ca55:b0:a44:7a25:736e with SMTP id jx21-20020a170906ca5500b00a447a25736emr703911ejb.27.1709280378482; Fri, 01 Mar 2024 00:06:18 -0800 (PST) Message-ID: Date: Fri, 1 Mar 2024 09:06:16 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/3] docs/misra/rules.rst: add rule 5.5 Content-Language: en-US To: Stefano Stabellini , Federico Serafini Cc: andrew.cooper3@citrix.com, george.dunlap@citrix.com, julien@xen.org, bertrand.marquis@arm.com, roger.pau@citrix.com, xen-devel@lists.xenproject.org, Stefano Stabellini , roberto.bagnara@bugseng.com References: <20240213223334.3693410-2-stefano.stabellini@amd.com> <50719397-b053-43e1-9cf7-cc9eae9098ed@suse.com> <40b7465f-4966-43c7-8db3-e28a6cc48445@bugseng.com> <2da73259-a86e-4a13-9fd4-4217372f4b76@suse.com> <3632611e-61ff-455a-9cc1-990a1f663d83@bugseng.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 01.03.2024 00:28, Stefano Stabellini wrote: > On Wed, 14 Feb 2024, Federico Serafini wrote: >> On 14/02/24 14:15, Jan Beulich wrote: >>> On 14.02.2024 12:27, Federico Serafini wrote: >>>> On 14/02/24 09:28, Jan Beulich wrote: >>>>> On 13.02.2024 23:33, Stefano Stabellini wrote: >>>>>> Signed-off-by: Stefano Stabellini >>>>>> --- >>>>>> docs/misra/rules.rst | 6 ++++++ >>>>>> 1 file changed, 6 insertions(+) >>>>>> >>>>>> diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst >>>>>> index c185366966..931158b354 100644 >>>>>> --- a/docs/misra/rules.rst >>>>>> +++ b/docs/misra/rules.rst >>>>>> @@ -181,6 +181,12 @@ maintainers if you want to suggest a change. >>>>>> headers (xen/include/public/) are allowed to retain longer >>>>>> identifiers for backward compatibility. >>>>>> + * - `Rule 5.5 >>>>>> `_ >>>>>> + - Required >>>>>> + - Identifiers shall be distinct from macro names >>>>>> + - Clashes between function-like macros and non-callable entities >>>>>> + are allowed. The pattern #define x x is also allowed. >>>>> >>>>> Just for me to know what exactly is covered (hence also a question >>>>> to Roberto as to [to be] implemented Eclair behavior): Even when >>>>> the above would be sufficient (and imo better) people frequently >>>>> write >>>>> >>>>> #define a(x, y) b(x, y) >>>>> >>>>> which, transformed to the specific case here, would then be >>>>> >>>>> #define a(x, y) a(x, y) >>>>> >>>>> I'd assume such ought to also be covered, but that's not clear >>>>> from the spelling above. >>>> >>>> I list what happens in some different situations, >>>> then we can find the right words for the documentation and/or >>>> refine the configuration: >>>> >>>> If you >>>> #define x x >>>> and then use `x' as identifier, >>>> the resulting violation is deviated (allowed pattern). >>>> >>>> If you >>>> #define a(x, y) a(x, y) >>>> and then use `a' as identifier for a non-callable entity, >>>> the resulting violation is deviated (no clash with non-callable >>>> entities). >>>> If you use identifier `a' for a callable entity, the resulting violation >>>> is reported: the allowed pattern covers only macros expanding to their >>>> own name, in this case the macro name is considered to be >>>> `a' only, not a(x, y). >>>> >>>> If you >>>> #define a(x, y) b(x, y) >>>> and then use `a' as identifier for a non-callable entity, >>>> the resulting violation is deviated (no clash with non-callable >>>> entities). >>> >>> I'm afraid I don't see what violation there is in this case, to >>> deviate. As a result I'm also not sure I correctly understand the >>> rest of your reply. >> >> #define a(x, y) b(x, y) >> >> int a; // Violation of Rule 5.5. >> >> The macro name `a' that exist before the preprocessing phase, >> still exists after the preprocessing phase as identifier for the integer >> variable and this is a violation. >> >>>> If you use `a' as identifier for a callable entity, >>>> this is not a violation because after the preprocessing phase, >>>> identifier `a' no longer exists. >> I correct myself: >> if you use `a' as identifier for a *function*, >> it is not a violation because after the preprocessing phase >> the identifier `a' no longer exists, for example: >> >> #define a(x, y) b(x, y) >> >> void a(int x, int y); // Ok. > > Federico, do you have a better wording suggestion for this rule? > > Jan, any further requests here? What would you like to see as next step? A more concise wording proposal would probably help. Jan From xen-devel-bounces@lists.xenproject.org Fri Mar 01 08:10:22 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2024 08:10:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687554.1071174 (Exim 4.92) (envelope-from ) id 1rfxyH-0008Az-Ky; Fri, 01 Mar 2024 08:10:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687554.1071174; Fri, 01 Mar 2024 08:10:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rfxyH-0008As-IG; Fri, 01 Mar 2024 08:10:21 +0000 Received: by outflank-mailman (input) for mailman id 687554; Fri, 01 Mar 2024 08:10:20 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rfxyG-0008Am-17 for xen-devel@lists.xenproject.org; Fri, 01 Mar 2024 08:10:20 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 240a96a4-d7a3-11ee-a1ee-f123f15fe8a2; Fri, 01 Mar 2024 09:10:18 +0100 (CET) Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) by support.bugseng.com (Postfix) with ESMTPA id 8F5904EE0737; Fri, 1 Mar 2024 09:10:17 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 240a96a4-d7a3-11ee-a1ee-f123f15fe8a2 MIME-Version: 1.0 Date: Fri, 01 Mar 2024 09:10:17 +0100 From: Nicola Vetrini To: Stefano Stabellini Cc: xen-devel@lists.xenproject.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, consulting@bugseng.com, jbeulich@suse.com, andrew.cooper3@citrix.com, roger.pau@citrix.com, bertrand.marquis@arm.com, julien@xen.org, George Dunlap , Wei Liu Subject: Re: [XEN PATCH 08/10] xen/errno: address violations of MISRA C Rule 20.7 In-Reply-To: References: <92dbcd9e5aa2ab45c50f3f567ddece59108568ad.1709219010.git.nicola.vetrini@bugseng.com> Message-ID: <726934748a14fa5173438a3529411678@bugseng.com> X-Sender: nicola.vetrini@bugseng.com Organization: BUGSENG s.r.l. Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 2024-02-29 23:55, Stefano Stabellini wrote: > On Thu, 29 Feb 2024, Nicola Vetrini wrote: >> MISRA C Rule 20.7 states: "Expressions resulting from the expansion >> of macro parameters shall be enclosed in parentheses". Therefore, some >> macro definitions should gain additional parentheses to ensure that >> all >> current and future users will be safe with respect to expansions that >> can possibly alter the semantics of the passed-in macro parameter. >> >> No functional change. >> >> Signed-off-by: Nicola Vetrini >> --- >> xen/include/xen/errno.h | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/xen/include/xen/errno.h b/xen/include/xen/errno.h >> index 69b28dd3c6c5..506674701fae 100644 >> --- a/xen/include/xen/errno.h >> +++ b/xen/include/xen/errno.h >> @@ -3,7 +3,7 @@ >> >> #ifndef __ASSEMBLY__ >> >> -#define XEN_ERRNO(name, value) name = value, >> +#define XEN_ERRNO(name, value) name = (value), > > I see this and the fact that "name" was not parenthesized and it would > deliberate right? So I guess the left side of an assignment doesn't > need > parenthesis? Exactly. Quoting from rules.rst: Extra parentheses are not required when macro parameters are used as function arguments, as macro arguments, array indices, lhs in assignments so, as noted in earlier discussions in this series, it could either be said that the rhs consisting of a single expression is similarly ok, or have (name) = (value) for consistency. Do note that a considerable percentage of violations are caused by these definitions (PERFCOUNTER, XEN_ERRNO and probably others in x86). -- Nicola Vetrini, BSc Software Engineer, BUGSENG srl (https://bugseng.com) From xen-devel-bounces@lists.xenproject.org Fri Mar 01 08:13:25 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2024 08:13:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687559.1071184 (Exim 4.92) (envelope-from ) id 1rfy1B-0000U1-2b; Fri, 01 Mar 2024 08:13:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687559.1071184; Fri, 01 Mar 2024 08:13:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rfy1A-0000Tu-Uv; Fri, 01 Mar 2024 08:13:20 +0000 Received: by outflank-mailman (input) for mailman id 687559; Fri, 01 Mar 2024 08:13:19 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rfy19-0000To-Gp for xen-devel@lists.xenproject.org; Fri, 01 Mar 2024 08:13:19 +0000 Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [2a00:1450:4864:20::530]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 8ef67c4c-d7a3-11ee-a1ee-f123f15fe8a2; Fri, 01 Mar 2024 09:13:17 +0100 (CET) Received: by mail-ed1-x530.google.com with SMTP id 4fb4d7f45d1cf-56533e30887so3228405a12.1 for ; Fri, 01 Mar 2024 00:13:17 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id k23-20020a1709063e1700b00a42f6d48c72sm1482682eji.145.2024.03.01.00.13.16 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 01 Mar 2024 00:13:16 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8ef67c4c-d7a3-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709280797; x=1709885597; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=qj2TOtP0QaYk201sneMG79nt/9riutl94IDNtJJc4nQ=; b=ZNOb5Ya/5ax2Hl1xrsYslcbfdbOSi8OW638ZJYDCWddZLzfRhKRyAbdr2eCEt+OMNN nuYk0cOwYWGxFXDHmHaUv1CXP1LxStEyoHOcA2MzWV1UqsZInUIl8CRTcmIBhoBugSPt u+Svqxn3h2S+k0+XJiz6UvCktURqIHa4m1+x0LMYUedkMne2cWyRGkB4CPpmqRzEvS9i JaRExPFKP00hs51wzV+HtXeIcZdM13J/nGdhQqdFT20fele8M1C545fMTbTuJddWqZpP hGsHf4o0QxrIIusAmEHi0a41u7lri13qGmNMQHMakDpHZl//bW+9eY8nmz+wj8cxEUpI 7EhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709280797; x=1709885597; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=qj2TOtP0QaYk201sneMG79nt/9riutl94IDNtJJc4nQ=; b=SATha1n1l490zZFtalMQhZg+30ly0+AKnkXRwxb5zV8TNFqJoaBKpm+aaMNMqbFRxI Nj8IjJL2OTbSCewbLw24gz6QhPIFwMQ5qCK3FVzlLwU3zRxfqiBsoUjxLIn7hNflfm43 5NIHvLA/lmKEQtojcmcf6k7lTe/0CM+09WvjKvctPaeWfC6KUkIkUQ7JI74YelHaaF4Y eiLmaRzzFkg+Hj0DDVi3F6ok3erXaCIeW9KU/w0KmaoAPhpbHc8aswinBppEyZ+W/MSo OD5aq9zTkt/nJuO092aj+G8iVxGEEdNlntT+JGVYyBIElDDp+jQjFOWWREKhiaAwfJ/C 1W1w== X-Gm-Message-State: AOJu0YzHXCTIjTPNAt8gI2u4euB9162edYq2VT19X+0jzCqBPdeTDBAs WIWK0G3oy68RLiLot2XSfAUPey2MdL426plVYKPjQkfKU5osD9KFHGLb6+9Cr8A1x+fhAf17zlo = X-Google-Smtp-Source: AGHT+IGRxsuXTZGLZcW43DrY/+D4D8AM/yfIPrQq8SeOINeKQz2+ZIbnPyBtPblM7xGP172VQke7rQ== X-Received: by 2002:a17:906:f2cc:b0:a43:e1aa:5f99 with SMTP id gz12-20020a170906f2cc00b00a43e1aa5f99mr739627ejb.52.1709280796887; Fri, 01 Mar 2024 00:13:16 -0800 (PST) Message-ID: Date: Fri, 1 Mar 2024 09:13:15 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: xen | Failed pipeline for staging | 4cac80e2 Content-Language: en-US To: "xen-devel@lists.xenproject.org" References: <65e12b62687a2_2c2cb9e3423456e@gitlab-sidekiq-catchall-v2-55cc6d75b7-k4whf.mail> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <65e12b62687a2_2c2cb9e3423456e@gitlab-sidekiq-catchall-v2-55cc6d75b7-k4whf.mail> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 01.03.2024 02:12, GitLab wrote: > > > Pipeline #1196428827 has failed! > > Project: xen ( https://gitlab.com/xen-project/xen ) > Branch: staging ( https://gitlab.com/xen-project/xen/-/commits/staging ) > > Commit: 4cac80e2 ( https://gitlab.com/xen-project/xen/-/commit/4cac80e22600d5a38d77c65e9a6507c752efc155 ) > Commit Message: docs/misra/rules.rst: add rule 16.6 and 20.12 > > ... > Commit Author: Stefano Stabellini > > > Pipeline #1196428827 ( https://gitlab.com/xen-project/xen/-/pipelines/1196428827 ) triggered by Ganis ( https://gitlab.com/ganis ) > had 4 failed jobs. > > Job #6293018467 ( https://gitlab.com/xen-project/xen/-/jobs/6293018467/raw ) > > Stage: test > Name: zen3p-pci-hvm-x86-64-gcc-debug Considering (domU) + fgrep 'MSI-X: Enable+' (domU) + lspci -vs 0000:00:04.0 (domU) Capabilities: [70] MSI-X: Enable+ Count=5 Masked- (domU) + echo 'pci test passed' (domU) pci test passed (domU) [ ok ] (domU) [ ok ] I don't understand the subsequent section_start:1709252523:upload_artifacts_on_failure Uploading artifacts for failed job ... ERROR: Job failed: exit code 1 Any clarification towards what's going on here appreciated. Jan From xen-devel-bounces@lists.xenproject.org Fri Mar 01 08:34:52 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2024 08:34:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687564.1071194 (Exim 4.92) (envelope-from ) id 1rfyLr-0003lZ-Sw; Fri, 01 Mar 2024 08:34:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687564.1071194; Fri, 01 Mar 2024 08:34:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rfyLr-0003lS-PY; Fri, 01 Mar 2024 08:34:43 +0000 Received: by outflank-mailman (input) for mailman id 687564; Fri, 01 Mar 2024 08:34:42 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rfyLq-0003lM-HG for xen-devel@lists.xenproject.org; Fri, 01 Mar 2024 08:34:42 +0000 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on20601.outbound.protection.outlook.com [2a01:111:f403:2418::601]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 8adf6125-d7a6-11ee-a1ee-f123f15fe8a2; Fri, 01 Mar 2024 09:34:39 +0100 (CET) Received: from DS7PR03CA0140.namprd03.prod.outlook.com (2603:10b6:5:3b4::25) by PH7PR12MB6491.namprd12.prod.outlook.com (2603:10b6:510:1f4::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7316.31; Fri, 1 Mar 2024 08:34:35 +0000 Received: from DS2PEPF0000343A.namprd02.prod.outlook.com (2603:10b6:5:3b4:cafe::97) by DS7PR03CA0140.outlook.office365.com (2603:10b6:5:3b4::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7339.32 via Frontend Transport; Fri, 1 Mar 2024 08:34:35 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by DS2PEPF0000343A.mail.protection.outlook.com (10.167.18.37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7292.25 via Frontend Transport; Fri, 1 Mar 2024 08:34:35 +0000 Received: from SATLEXMB08.amd.com (10.181.40.132) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Fri, 1 Mar 2024 02:34:34 -0600 Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB08.amd.com (10.181.40.132) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Fri, 1 Mar 2024 00:34:33 -0800 Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend Transport; Fri, 1 Mar 2024 02:34:31 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8adf6125-d7a6-11ee-a1ee-f123f15fe8a2 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=C8jsPoEZcEzrwoJd0LArjAFA/M0ECPbiBIsYc3u1+dCGgt/0KtQvzwXnPuovB1wCtyPxCeMEPd3aONaLgqKpaA8RLd6e3BrXML3fgu8+I2RBP1E2fwCnxyuxajyaAJFE5K4rHiPzVaHyRIK0n1ytngNFQYGQEeJVY5bUmeS00x8EcxsbpDNhhvlExdcgYQKilQ0gh7pj0bq8tkF8YY27VXJvz9zEVwkthcaa3QlPPkCNmPvA7qQHi8HondJag0uSD9D7cuyLyKgBdDj4TqNBOFixwhKty/cizlq5l5coinMZulKGygbdhL6z4Fm8OSszbNmvp3SaYthfLQH+MDxUbQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=1jiFRjrnYN/0aS7YHHpCPHuCNGWCHKKaUsltcPDVniU=; b=YDiZlwAHge4ymwBkmOGdWYV3RfOS3J6WPIy0kuyLlQACF0SWk+Q9iOrPxUDAE6pm/6s7rAXXwNt39vYfXXygIzurUh2ZAHoapff8se8I+CSmZj9CXWd5lXfSw1wp+LAkNyESbEFCzd3LNX5+jn1Fp29/FTSSfEYE/v+f0CU7wvZBkq3CxVmlioaPcOK3eif2WBFiaa0nByCLEv5DRJcQi92hvoZiTKwZGlm2Xi9KCzKoz6Qas/C0QimpJ1NOYN9BdLCOzI37+HxbJD6Qg6YSQomyq0cQHwposgDC1eCGCV37fabb2ZPl4HfKSI1sSj1gS6BHwLRCVrw1DRV9p7xWgg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=kernel.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1jiFRjrnYN/0aS7YHHpCPHuCNGWCHKKaUsltcPDVniU=; b=Q3JnSLbGwO55LSKE/bHJ4fYCfHPqMIsljNihgvAYyvnjT1O03bOnpN1EJ4XAf/nH34Fnhk90tITJj7BQq8jR+IY8Im6VsCfKBUS8UGDe8/8infeADHY0saUdDXZDdyU/wMl8/cN1AU41WYJHupDw96ZO/E4OvbncW2HNFw7a9x8= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C Message-ID: <36cfcc27-f432-49fa-a949-63b0400d9af7@amd.com> Date: Fri, 1 Mar 2024 09:34:31 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/3] docs/misra/rules.rst: add rule 16.6 and 20.12 Content-Language: en-US To: Stefano Stabellini , Stefano Stabellini CC: , , , , , , , , , References: <20240213223334.3693410-1-stefano.stabellini@amd.com> From: Michal Orzel In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS2PEPF0000343A:EE_|PH7PR12MB6491:EE_ X-MS-Office365-Filtering-Correlation-Id: 55d5288f-072e-48b5-1b0e-08dc39ca6ceb X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: JiTBkfTQ8VVLul0JActz3XRlhPQxxX2IUcCtOYQKq5yMePV6ZB3MXQSlibVvz6FARguR2htxv8/dLKSh0P/JvFjSilguma0w/83+YDXOx+XnzCcC/8CsT++WZPcu4kyh49CIZUMF6ettW1qo6fRnMsxR4tn9wLMGrAQL6EVJAVebzREtJqFfGSyD63/DTOQ2ewVw6nLy2nQW1ydMQoJoZziO/dclTfMeIX18NgATp/O1vIj21LsiMbTfiOdMqGaaoYLL5f2LgnI3eIL+5McD/MjXRjOc0q9u9sKJb0usPPphDtB9TrBE3yg9TRXX7rabLTJB8yDGNL6xK3QVzCZlHMKGftSARKGANWP29A1Bvnn2M1Uuizw+9X8OnSSnSM3x1BAEW/Bhje+4sYz6oag8dhybb7Fh7SN9BYR/yuPV7/n5kew2/rI1/yYY24f0OSnwPa8himVOEPxCIf9zph4Y9pIXcdFCGorCaKxHeqD+zoJjxwkO9tV7Z/SKmznv6WWBRJBqsXmRTKcBFMM0iMTK+A5zUtVvCxZWO43HJF/kpNXGsKp/gJWUZw7YAnzERsR05w6fqZodFn5/UpLc6MXBzxl8pFpOu8qcPkbjaivOBWBgYrRv3RUZlK7mQQpl3hnwp3mZqKeTyBc+jGY5Ubtg3bXePemV3p6IUaoNnW7a5cqNuYoM7QSwGXr477kXzu1l/LgCt7BmCs0BqP2b8Ss9ZHl2x4K5GHwEvm5uJbjwfaXS974vA9L9NAEp/G416X/r X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(82310400014)(36860700004);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Mar 2024 08:34:35.0948 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 55d5288f-072e-48b5-1b0e-08dc39ca6ceb X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: DS2PEPF0000343A.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB6491 On 01/03/2024 02:56, Stefano Stabellini wrote: > > > Hi all, > > This patch broke gitlab-ci. The jobs failing are the cppcheck jobs. > > xen/scripts/xen-analysis.py --run-cppcheck --cppcheck-misra -- -j80 > No summary for rule 20.12 This is the error message. For rule 20.12, the summary and severity are in reverse order. I'll send a patch shortly. ~Michal From xen-devel-bounces@lists.xenproject.org Fri Mar 01 08:44:46 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2024 08:44:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687568.1071203 (Exim 4.92) (envelope-from ) id 1rfyVU-0005el-QU; Fri, 01 Mar 2024 08:44:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687568.1071203; Fri, 01 Mar 2024 08:44:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rfyVU-0005ee-Nl; Fri, 01 Mar 2024 08:44:40 +0000 Received: by outflank-mailman (input) for mailman id 687568; Fri, 01 Mar 2024 08:44:39 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rfyVT-0005eY-7F for xen-devel@lists.xenproject.org; Fri, 01 Mar 2024 08:44:39 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id ef1a45b3-d7a7-11ee-a1ee-f123f15fe8a2; Fri, 01 Mar 2024 09:44:36 +0100 (CET) Received: from [10.253.4.78] (unknown [160.78.253.161]) by support.bugseng.com (Postfix) with ESMTPSA id CEAC74EE0737; Fri, 1 Mar 2024 09:44:35 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ef1a45b3-d7a7-11ee-a1ee-f123f15fe8a2 Message-ID: Date: Fri, 1 Mar 2024 09:44:35 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH] automation/eclair: extend deviations of MISRA C:2012 Rule 16.3 To: Stefano Stabellini , Jan Beulich Cc: consulting@bugseng.com, Simone Ballarin , Doug Goldstein , Andrew Cooper , George Dunlap , Julien Grall , Wei Liu , xen-devel@lists.xenproject.org References: <6c96f889ae3fbdf516f0edfe4a5fb207540b6862.1709109662.git.federico.serafini@bugseng.com> <1a00c221-ce1c-45be-9ab3-e8f1a0e5678d@suse.com> <98d82c40-a81a-4c75-8cdf-aaef640382b6@bugseng.com> <0e2f5394-6322-4845-954f-ff080626523f@suse.com> Content-Language: en-US, it From: Federico Serafini Organization: BUGSENG srl In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 01/03/24 00:00, Stefano Stabellini wrote: > On Thu, 29 Feb 2024, Jan Beulich wrote: >> On 29.02.2024 09:01, Federico Serafini wrote: >>> On 28/02/24 10:06, Jan Beulich wrote: >>>> On 28.02.2024 09:53, Federico Serafini wrote: >>>>> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl >>>>> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl >>>> >>>> Comments below apply similarly to text added to this file. >>>> >>>>> --- a/docs/misra/deviations.rst >>>>> +++ b/docs/misra/deviations.rst >>>>> @@ -291,7 +291,14 @@ Deviations related to MISRA C:2012 Rules: >>>>> - Project-wide deviation; tagged as `deliberate` for ECLAIR. >>>>> >>>>> * - R16.3 >>>>> - - Switch clauses ending with continue, goto, return statements are safe. >>>>> + - Switch clauses ending with an unconditional flow control statement >>>>> + (i.e., continue, goto, or return) are safe. >>>>> + - Tagged as `safe` for ECLAIR. >>>> >>>> With this edit (unmentioned in the description, btw) ... >>>> >>>>> + * - R16.3 >>>>> + - Switch clauses ending with an if-else statement are safe if both >>>>> + branches consist of a flow control statement (i.e., continue, break, >>>>> + goto, return). >>>> >>>> ... why is it not also "ending with" here? >>> >>> Because the allowed pattern is: >>> >>> if ( cond ) >>> return; /* Or continue / break / goto */ >>> else >>> break; /* Or continue / goto / return */ >>> >>> See below for more information. >>> >>>> >>>> Also what about either situation ending with a call to a noreturn function? >>> >>> This can be added. >>> >>>> >>>>> @@ -307,6 +314,16 @@ Deviations related to MISRA C:2012 Rules: >>>>> - Switch clauses ending with failure method \"BUG()\" are safe. >>>>> - Tagged as `safe` for ECLAIR. >>>>> >>>>> + * - R16.3 >>>>> + - On X86, switch clauses ending generating an exception through >>>>> + \"generate_exception()\" are safe. >>>>> + - Tagged as `safe` for ECLAIR. >>>> >>>> This macro is limited to the emulator, so shouldn't be deviated globally. >>> >>> Noted. >>> >>>> Furthermore - why does the special case need mentioning here? Shouldn't >>>> it be the underlying pattern which is deviated (along the lines of the >>>> earlier ones): >>>> >>>> if ( true ) >>>> { >>>> ... >>>> goto ...; /* Or break / continue / return */ >>>> } >>> >>> This pattern that involves a compound statement for the true branch >>> is not deviated by this configuration. >>> >>> See below for more information. >>> >>>> >>>>> + * - R16.3 >>>>> + - Switch clauses ending generating a parse error through >>>>> + \"PARSE_ERR_RET()\" are safe. >>>>> + - Tagged as `safe` for ECLAIR. >>>> >>>> Again this isn't a global scope macro, so shouldn't be deviated globally. >>> >>> Noted. >>> >>>> Plus it ends in "return", so ought to be covered by the earlier clause. >>>> The fact that the return is in a body of do {} while(0) shouldn't matter >>>> at all - that's purely syntactic sugar. >>> >>> I gather from your comments/questions that you would like to deviate >>> *all* the patterns where an unintentional fall through can not happen. >>> >>> Rule 16.3 is a purely syntactic rule, and, as a consequence, >>> in the current version of ECLAIR additional "allowed pattern" (aka >>> deviations) for that rule need to be described through AST nodes, >>> meaning that all what you consider as syntactic sugar cannot be ignored. >>> >>> A deviation that covers all the pattern you are asking for could be >>> done, but it will result in a complex and quite long expression >>> (not easy to read and justify in front of an assessor). >>> >>> Hence, what I am proposing is to deviate only the the simplest and >>> most readable cases, such as: >>> >>> if ( cond ) >>> return x; >>> else >>> return y; >>> >>> without involving compound statements, fake do-wile and fake if >>> statements but rather deviating the macro inside of which are used >>> (as I did). >> >> I see. Problem is that this isn't sufficient for the code we have, and >> the seemingly random deviation of certain constructs by name looks to >> me as pretty undesirable. > > Yeah, I also think it is not ideal. At the same time among all options, > it is probably the best way forward (better than in-code comments or > better than leaving the violations outstanding). > > I think we should go for it. > I'll propose a v2 with an ECLAIR configurations that covers all the patterns you are asking for, so that we can discuss it and understand what the best solution is. -- Federico Serafini, M.Sc. Software Engineer, BUGSENG (http://bugseng.com) From xen-devel-bounces@lists.xenproject.org Fri Mar 01 08:50:15 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2024 08:50:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687570.1071214 (Exim 4.92) (envelope-from ) id 1rfyaf-0006cO-Df; Fri, 01 Mar 2024 08:50:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687570.1071214; Fri, 01 Mar 2024 08:50:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rfyaf-0006cH-9X; Fri, 01 Mar 2024 08:50:01 +0000 Received: by outflank-mailman (input) for mailman id 687570; Fri, 01 Mar 2024 08:50:00 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rfyad-0006cB-Vh for xen-devel@lists.xenproject.org; Fri, 01 Mar 2024 08:49:59 +0000 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on20600.outbound.protection.outlook.com [2a01:111:f403:200a::600]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id ae42b111-d7a8-11ee-afd8-a90da7624cb6; Fri, 01 Mar 2024 09:49:58 +0100 (CET) Received: from BLAPR05CA0030.namprd05.prod.outlook.com (2603:10b6:208:335::11) by PH7PR12MB8014.namprd12.prod.outlook.com (2603:10b6:510:27c::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7316.41; Fri, 1 Mar 2024 08:49:54 +0000 Received: from BL02EPF0001A106.namprd05.prod.outlook.com (2603:10b6:208:335:cafe::58) by BLAPR05CA0030.outlook.office365.com (2603:10b6:208:335::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.16 via Frontend Transport; Fri, 1 Mar 2024 08:49:53 +0000 Received: from SATLEXMB03.amd.com (165.204.84.17) by BL02EPF0001A106.mail.protection.outlook.com (10.167.241.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7362.11 via Frontend Transport; Fri, 1 Mar 2024 08:49:53 +0000 Received: from SATLEXMB08.amd.com (10.181.40.132) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Fri, 1 Mar 2024 02:49:51 -0600 Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB08.amd.com (10.181.40.132) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Fri, 1 Mar 2024 00:49:51 -0800 Received: from XIR-MICHALO-L1.xilinx.com (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend Transport; Fri, 1 Mar 2024 02:49:50 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ae42b111-d7a8-11ee-afd8-a90da7624cb6 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QMoLGM6eSxSq0Be+3WYV2TTYH7/lZfSuqSfLi+j3wDd1FsMPMi+K9vlvSttE697Ldsqxy7lqVAfRG9TgN8j5lGYkjwPk57vph+w7AH/iObvbCSgdFPTw+z9LCXJCa3mGTsSPBQosQXrWlTjk5w9c/66ZCNnEs0wDuig1Qj9OjrjB0ioi16xmDuuQXD9Qwa6suJj374Ew9/zvIT8LnKzEFh64tAzvTykho+BkyRA/TNSIDwjeVZ6S48XuFYvsdcERqMNM5ch6eAFuS1PSEPUT1Ky4ZcHOiEH8K6ViztEL1d831HRDMsEVokr9CH8d6zXC3M3TxagzZEqBSIUnd842DQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=9mqY6PXoqHTV48+lmvGVft603ncwA2ceDN0myBvjPAI=; b=K1hIt33QKlLK2PhOaBUD+SRZtaNrJoDr/CsxmmOKBD/jougnHDdVzt8ZC0HuKTGfIsVffer9WyTb2UOeVJexu0oXi0hln1PDzwjZVdDuSYP/2NEDyH/bEw1HV0PNynKD2GIYuR72l8cseH8UBKP9fk3a0pYhORYkpUXD2DQz2OnyESJ+tamA3ammpflsMJZbM2l/sy+w5j6QosHUGOlSmWilojRX2qWOEs2faY26ME7kqGiij5GTp4MJNKXjxR9cVvw/lpuAmzPzT6DuiqVxsPvUogAXcYIafEGeDN18XJbsgMyacc3Dfr/YMf3DR5VY3RVISH/EQj8LZltXnUIipg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9mqY6PXoqHTV48+lmvGVft603ncwA2ceDN0myBvjPAI=; b=rN5IFiCTcuSrYgvp3Hi8Yt7RSd3cs9Ik0epP6SNaF/fqDJ3sH8rGB/8dOlwbApdNOBtAuL91uKcXAlUlC2pg/nN0eP05LMTqhH+1Psvy1BbTfHGctbtx62ArGYw2iWyynoPHS7IAWp+PuPEA2j76iBgVQdUS9X/aNEFCC9uyRaQ= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C From: Michal Orzel To: CC: Michal Orzel , Andrew Cooper , George Dunlap , "Jan Beulich" , Julien Grall , "Stefano Stabellini" , Wei Liu Subject: [PATCH] docs/misra/rules.rst: Fix entry for 20.12 rule Date: Fri, 1 Mar 2024 09:49:47 +0100 Message-ID: <20240301084947.19241-1-michal.orzel@amd.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BL02EPF0001A106:EE_|PH7PR12MB8014:EE_ X-MS-Office365-Filtering-Correlation-Id: 666acea2-804f-44e4-7126-08dc39cc903d X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 5AvjZEtrQz919PqWaJQTrZKJM5cb7ItibPmA6HxB/3bXl2M+8XPYK7IXboqJxn1E0LXAnitSqtpNUveEJOROI18Ok7x4oeB0ByAr7++vlfQBUB2lEOE1e2MENi9d2Vp7vXOZc47eonuewrVU2SGjJk4tbCwHmdfZ+VDrAy7Zb1zcpKDqRjAIpNwklbLXtUahwcye7lbCNf0TsOIvDTLbNEa03dFlQy2qGS3YrosCmypXorKpOlUt+eIkY4IiFFwlVHh0EhfYLlOjlCwOjeYzgg74QIaU3gISnlOv70B1u5xDikTHuJPUNvEx82Rl8b1Dw2rbTtVHxr5mvxfUTb+xIzWWvTuNxUS/IMYTLyEZkbHKrJaTEXz6EcmW8xO1VJuL6jO3vX8rQnHzA90RHkWOlE/bCzn6fKpd6V0/U25NrFEGm1lzOaLgrGpaZiNnOVpyNZFVzEqaGD2H2k/Fpbu6+I84aQkQIcXSwVYJDRblgZ8iqIZOVDU+W7PX6iU9info3K8MLXX4ZnVmQZHbnuNu1dvP2KeBnAT3AhjcIPZT3gyiWSz2dfOwc9a1PLgC1csrBi1eaIXhc/9nKdYCBbNQwnryqK4YPrBwvxPKJ5X1gIcLQPN0G7YAM9V7Q23lGAiScXqfKrMVEzFyI3x39OGaIdkpif2Qq7Y1FhWnkX8AL/QEUy55EhJywdaEriqrCChp2E7/mBZdACwhElqb8DnOkQ== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(36860700004)(82310400014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Mar 2024 08:49:53.4262 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 666acea2-804f-44e4-7126-08dc39cc903d X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BL02EPF0001A106.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB8014 Commit 4cac80e22600 broke the CI cppcheck jobs by adding an entry for a rule 20.12 with "Severity" and "Summary" fields placed in reverse order. This leads to an error as reported by convert_misra_doc.py: No summary for rule 20.12 Fixes: 4cac80e22600 ("docs/misra/rules.rst: add rule 16.6 and 20.12") Signed-off-by: Michal Orzel --- Failed pipeline: https://gitlab.com/xen-project/xen/-/pipelines/1196428827 --- docs/misra/rules.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst index c1853669669d..efea063ab941 100644 --- a/docs/misra/rules.rst +++ b/docs/misra/rules.rst @@ -561,10 +561,10 @@ maintainers if you want to suggest a change. - * - `Rule 20.12 `_ + - Required - A macro parameter used as an operand to the # or ## operators, which is itself subject to further macro replacement, shall only be used as an operand to these operators - - Required - Variadic macros are allowed to violate the rule. * - `Rule 20.13 `_ -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Fri Mar 01 08:53:04 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2024 08:53:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687574.1071224 (Exim 4.92) (envelope-from ) id 1rfydb-00080N-Qy; Fri, 01 Mar 2024 08:53:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687574.1071224; Fri, 01 Mar 2024 08:53:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rfydb-00080G-O4; Fri, 01 Mar 2024 08:53:03 +0000 Received: by outflank-mailman (input) for mailman id 687574; Fri, 01 Mar 2024 08:53:01 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rfydZ-000808-Rp for xen-devel@lists.xenproject.org; Fri, 01 Mar 2024 08:53:01 +0000 Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on20601.outbound.protection.outlook.com [2a01:111:f403:2612::601]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 1af50940-d7a9-11ee-a1ee-f123f15fe8a2; Fri, 01 Mar 2024 09:53:00 +0100 (CET) Received: from DU2PR04CA0326.eurprd04.prod.outlook.com (2603:10a6:10:2b5::31) by AS4PR08MB7878.eurprd08.prod.outlook.com (2603:10a6:20b:51d::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7316.41; Fri, 1 Mar 2024 08:52:55 +0000 Received: from DU6PEPF00009528.eurprd02.prod.outlook.com (2603:10a6:10:2b5:cafe::dd) by DU2PR04CA0326.outlook.office365.com (2603:10a6:10:2b5::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7339.33 via Frontend Transport; Fri, 1 Mar 2024 08:52:55 +0000 Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DU6PEPF00009528.mail.protection.outlook.com (10.167.8.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.11 via Frontend Transport; Fri, 1 Mar 2024 08:52:54 +0000 Received: ("Tessian outbound c926391f1b75:v228"); Fri, 01 Mar 2024 08:52:54 +0000 Received: from 276963e644b8.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 42E86B3F-65D3-4FEA-8F48-BF740A84BE56.1; Fri, 01 Mar 2024 08:52:48 +0000 Received: from EUR01-VE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 276963e644b8.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 01 Mar 2024 08:52:48 +0000 Received: from AM6PR08MB3749.eurprd08.prod.outlook.com (2603:10a6:20b:8f::22) by AS8PR08MB9265.eurprd08.prod.outlook.com (2603:10a6:20b:5a1::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7339.32; Fri, 1 Mar 2024 08:52:46 +0000 Received: from AM6PR08MB3749.eurprd08.prod.outlook.com ([fe80::99ee:f28d:84bc:97cb]) by AM6PR08MB3749.eurprd08.prod.outlook.com ([fe80::99ee:f28d:84bc:97cb%7]) with mapi id 15.20.7316.039; Fri, 1 Mar 2024 08:52:45 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1af50940-d7a9-11ee-a1ee-f123f15fe8a2 ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=LVp3bR+m2xDVFDlA020wGOJeDHiWnwar0jylsEVB2TbacG9RG5bucP9urWSBETzIFtGh4QwotXy7bSBLGjaHrT3m2m2Mj2Kfl1NAOs159S4iM2n21xmrO1DYCUKS0iYJSEstpXjUUKDgPFq9iFC5XbRUs1BIZzsTnNNRHzbOE0FZ4oaBZT1Oh4yLg6sHZ7KNkWs4f6X1J5S3sryfpbAc0Gf2VYsdokqA5ebjM/H7iivLsWMQsHguOj5uf/HTluAOYep42MAGQckHPi0HPLKE0vUkN7dw5Dw/hwx+ciKd+2rDOFFP826Sl6yo1FJ9j45MV4TFquItVGkkIZ+54UKObw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=2WPzIwlAKDARI4yUW/gbtgl3v5eZeyLtCscQ/GDqGIA=; b=RRQsWn4wN1r/Mw5TvO8u406+PlyFMMpb3iaKDn8c5it4wrHpJjBdzcpeRjAocPi4VQVL6LgJ2Oi33AmpMEeFh3lJX29MZd+t6Lf/piOpXoMH3ttKB58QEgtLUhuYY5a6m6l3fk32HKhcj4sMyz9TQe5/fGEoRfUjCTAXA+dBj4MH+XZN94ikdQe4TWQRq4+ytj7huPKOLm3gtwA8z0TXju9WxwhwwvSx8hOr8sk0IQYZpE7v/ZpK+5M+9K1y7g31N0B/mYjEQqYj195AF3jGydPMf4VQAEp5RqXsRbja7EtlpghGul8zar8eHpR2cWZ3OZUxe0OoPX+M+n925mREBw== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 63.35.35.123) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2WPzIwlAKDARI4yUW/gbtgl3v5eZeyLtCscQ/GDqGIA=; b=d388tLmhVlXeSmB3Mb3NX5S0UGU9No0diD2J22fpi3hQZ5F/tg6pnCPgLHrWE7tiCDM6O3UqQua1jt7td8HgWg98+5MdUqIARb43y+jerPP84wDLxfxHbDEJ5U2ig0BhCZlm7+LagAOa0J8/gpsRntd9fqA0/6NJQPoyFZUZpcI= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; pr=C X-CheckRecipientChecked: true X-CR-MTA-CID: 0f9d1645a7bb768f X-CR-MTA-TID: 64aa7808 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oCqd9ZnbEVMHWZaFjj8Jx+rCweYDufjusuA/JqlOu9dMdaiEepU2ulerjAu5ZD3u+Sh0/JpAyL0jPQ/2MCuEYPtS035HsUDFTYITQLDB5zuZHYxkY4JnMhB+POlnuF+6B88caZYEg3wSla9bQ6jpxpQx0hXqAZx2KY9hc73YLHS6s/d52vNMT1zQCWnn4g4z63co42DsBytjpWaopWAtyw5gTage/4ksHWX0FD5bnBZp2Xh9jIHAPglhu6ywbeVevY5MPuegxaP5LX241+iFCowVPQbQSBdtwUgHiU5yzqGASmEfj0f+DePa6IHJ5kF0VAxnkU8ou+H4h4oQUA5cRg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=2WPzIwlAKDARI4yUW/gbtgl3v5eZeyLtCscQ/GDqGIA=; b=eIyLd0PhXko0PjpSVwciNv6KUXbPDbxfJulU8oa+4vvJdBBYgu/qDlnnOGMFXtLzPwahgcskug9UcXEyrv5rocR5Skrc3rtswuciTejEe2qmVdXPOD8sU2VDxoUXEdJmdSERx1NQZXhpRnttyqxvZK60SrX1orh553r/xf09DyhNzYATzyqBGnuXqcEAN81ZOtG/hWVPMoP21rGBtl+MWElx3aPk4zLbeTpozhOIPP5IMVhzobewmxwaoX/AwV0/8RRAD14Cw9a/Ej3GEefpJdMRM7LV76efBmvIyt6Q1XfEXtl7tySdrtzeVUSQVXW94X4AT1B293iD7weFycp+EQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2WPzIwlAKDARI4yUW/gbtgl3v5eZeyLtCscQ/GDqGIA=; b=d388tLmhVlXeSmB3Mb3NX5S0UGU9No0diD2J22fpi3hQZ5F/tg6pnCPgLHrWE7tiCDM6O3UqQua1jt7td8HgWg98+5MdUqIARb43y+jerPP84wDLxfxHbDEJ5U2ig0BhCZlm7+LagAOa0J8/gpsRntd9fqA0/6NJQPoyFZUZpcI= From: Luca Fancellu To: Michal Orzel CC: Xen-devel , Andrew Cooper , George Dunlap , Jan Beulich , Julien Grall , Stefano Stabellini , Wei Liu Subject: Re: [PATCH] docs/misra/rules.rst: Fix entry for 20.12 rule Thread-Topic: [PATCH] docs/misra/rules.rst: Fix entry for 20.12 rule Thread-Index: AQHaa7V9eauMXGRhXU2XopY0JFvmgLEilDCA Date: Fri, 1 Mar 2024 08:52:45 +0000 Message-ID: References: <20240301084947.19241-1-michal.orzel@amd.com> In-Reply-To: <20240301084947.19241-1-michal.orzel@amd.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3774.400.31) Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-traffictypediagnostic: AM6PR08MB3749:EE_|AS8PR08MB9265:EE_|DU6PEPF00009528:EE_|AS4PR08MB7878:EE_ X-MS-Office365-Filtering-Correlation-Id: 21e6dd82-dedc-4744-0a9a-08dc39ccfc4a x-checkrecipientrouted: true nodisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: xWM7S0qT+T9oBTbvuLsVhL9AChQBFzsXhhO1JUJ4yzT2sX3kFp+p8dNeL6++gPLbkLoDAwKWOxdyNIPoRJ8ZmmUgW7iRUyYUu1pxKUQpLtY50S8zlJMkUUvuTMhuwaEJmPIm6Mw0mgsUqMKWwMzw0o6tfXYsA4BAR1GimnVkeUaEAJ0ICWsQZYoBU/w4cZ8HnhLrCTc3SzxqlwIB0mHC8j/SfJcQ/63PoyqO4krnVqVD2q2/bJJPfzMPnD9a1k1GzGVSsrtrCIgUkk8yMfLCi+N0YTGwncWtqPpaRyeMiPhn/IK/Mn3sA56q9W0GUf+MG1PuEXKNRMabjSV2JcW47l1J34v0EM1xVqLttB6klHJwU/4IfCEpayWdJ/yB759IRky9sJ9F5CH+e/YHovZ5jyEfHsIbUVqojxZMu4AkgVjoSF42L7TPoKY3xp0ugPYakauEVBW/4BrJ+wrWbn+ly2oBTki35COUWjwP2UwXsTZOAz3Y0YBz45DwvLmu9BSSBXWaVZROR/qpbCid5/1QX6oAl/74dnDWidjt5QVXXMHL3ahJfOuvtFIPPtKxJZzRAy5dS80+2oEfZa/XCckj+NlshMUljdPVqlMZkx7Jv2Y946sIumBuw8/zsc1gySo5SGbgZ084rJm3p3WFb/frCahFznEioGln2dGXNVXXivA= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM6PR08MB3749.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(38070700009);DIR:OUT;SFP:1101; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB9265 Original-Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DU6PEPF00009528.eurprd02.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: d784b01a-8158-4243-7af1-08dc39ccf6f0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 6S1mhdCGAY9AswqKVNoJEzzwG4f31Q53JgntoMd1+m1XR7FCObhqS7I+5wtDgMnov0VT9OjGfRbwWh+xFl08MCgFSIHsLaqUNm5R9izTQBjaXLjwuvvdhcv+2Lpenh9CjAjTrP+865j6U5V1JYCBozMz5OsegWXnf6nVHF27+lucUlj0acDedGgzhOrvAPQh1IqV8cKUEvbRpF+qB/clDLuo4reUDwDQbK7WwWwtf128GonLrEn0BY+VWbjjwUoBot8Qtnzpzc0H2SX/d99AAOjBg5I/ZQjb4hPHRduThr782e536a96wvLbDCCjUeeL9s1F1JNxX364f4JYcbORavQ1du+egajlwDar+wpc9dRoNoxugSLN4RzjHh1v+Pzxhccx4ZB2Lp3ZeEc+V793bcm7W5seWGXq88dCBTTxAH8sR/S/awGzhzzuI4ncFyhOBxe0TdlJYWUu4lca2rA3nyCT8LyrHq7Br/sUsI8Qzeo0oQroLbzJ9gaDnUnEXPj7fogibQCptGrcM3auOC8J8LUM0AIbcOHWDs/1olbYqGL18XS7bv/v9abaBt9dKCD5Kxebcs8TMntUySyGsHxZpE/uFku5iIWzjZgHIDMoy5oj1/kB6HyUUPD+KKGN2NWR30YRCvUht5l8HOTdKVG+ZuFLzjYSRmwibq/QRDbHs6fFWCTR4vkrtUHRWaxqanWD8ONJLl5T2OwhhnyuNXvMxA== X-Forefront-Antispam-Report: CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com;CAT:NONE;SFS:(13230031)(36860700004)(82310400014);DIR:OUT;SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Mar 2024 08:52:54.8433 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 21e6dd82-dedc-4744-0a9a-08dc39ccfc4a X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: DU6PEPF00009528.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS4PR08MB7878 > On 1 Mar 2024, at 08:49, Michal Orzel wrote: >=20 > Commit 4cac80e22600 broke the CI cppcheck jobs by adding an entry for > a rule 20.12 with "Severity" and "Summary" fields placed in reverse order= . > This leads to an error as reported by convert_misra_doc.py: > No summary for rule 20.12 >=20 > Fixes: 4cac80e22600 ("docs/misra/rules.rst: add rule 16.6 and 20.12") > Signed-off-by: Michal Orzel > --- > Failed pipeline: > https://gitlab.com/xen-project/xen/-/pipelines/1196428827 > --- Reviewed-by: Luca Fancellu From xen-devel-bounces@lists.xenproject.org Fri Mar 01 09:15:18 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2024 09:15:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687587.1071233 (Exim 4.92) (envelope-from ) id 1rfyz1-0003AA-5y; Fri, 01 Mar 2024 09:15:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687587.1071233; Fri, 01 Mar 2024 09:15:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rfyz1-0003A3-3R; Fri, 01 Mar 2024 09:15:11 +0000 Received: by outflank-mailman (input) for mailman id 687587; Fri, 01 Mar 2024 09:15:10 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rfyz0-00039x-2b for xen-devel@lists.xenproject.org; Fri, 01 Mar 2024 09:15:10 +0000 Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [2a00:1450:4864:20::632]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 32e253fc-d7ac-11ee-afd8-a90da7624cb6; Fri, 01 Mar 2024 10:15:09 +0100 (CET) Received: by mail-ej1-x632.google.com with SMTP id a640c23a62f3a-a3f3d0d2787so276308266b.3 for ; Fri, 01 Mar 2024 01:15:08 -0800 (PST) Received: from [192.168.206.239] ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id w11-20020a17090652cb00b00a44879da0f3sm468161ejn.143.2024.03.01.01.15.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 Mar 2024 01:15:07 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 32e253fc-d7ac-11ee-afd8-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709284508; x=1709889308; darn=lists.xenproject.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=LQ7c+pMWAjkhAfGsmL8GcAuh/D5rJKD28a9NdMhn97c=; b=noRS2UjVm2Z55AX/pKQPUwzgjRjngpLYJc7GN+fff9VIYFWCXfu3NA0jWFJFureHbq dlw2HunTQAGaZKZ7AUfwgWIdPj3RzTihA555BgGNu/pnr9+3ZfhdMXOgIOpUkR3kgW0A 2u+fnagLlHRE0cwtx66B+1jCR8Gh2YE306lYxjFur3MeRgS3vjQFgsCf+ms+2tLIiS9h N8gF/VtRm2eh8Qswjn5XQ2XXq9hV9UgPcL4Y/+rltoGT3N1UPu7MV5fgqBr71gJq9isL ROpIuC0u9XVeLkWZxadfnLVGWSikKcCH6nprb5Gb4ANvDl+yv7QLOPdb326FSGnv1d8P /4UQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709284508; x=1709889308; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=LQ7c+pMWAjkhAfGsmL8GcAuh/D5rJKD28a9NdMhn97c=; b=hO/eRhgjHJnWmMkniZy56oWUpPUUoRBP+A5JGy5MQCrOfoDx1E6zFHNKp5fzUmmED1 L8X0g2ELVL9J8sSS433emDlKG5Xfg8Rnl+4w/Wxt60Q99FvKrXiBc7nWXoFfwlHNRlkc SV8pxnJPEgXKKzA454sI1XXRbXnd+tVkOX+Zf9Ju3y7azK13WCZMnjUrLeqx1nS40dNj 8qzu8HzdbO0hYMPoiwYnkZHbBOO8a2bd8FIor3+qZvWu1iPOctPmhoVIQdUURuC3jprI DGMkoHot7NzhkrTFTdqVj5nBe7CajIxRhJMNTRWmU7HkWxKW4JA3PEVy3i18/SnsEp00 gCjQ== X-Forwarded-Encrypted: i=1; AJvYcCXjaqwQOup5uIV74kV3+cEnsqYNpYHQm9yi6NP8MLgKaTcm9yH8JcyPmSNYhiGjkyGAwTviHxOkv4VqtiL2eNvGstyZmeltAqLBihCuHtg= X-Gm-Message-State: AOJu0YyZJDTDnD2BVBtm5QbVekXr5w7o7cXOxpYgrd1zLir4+pn39BNB bi8r8ZawdwbqniFRTZJ9u/E/8mKmeoaajnN4b+LWnenpGvailAup X-Google-Smtp-Source: AGHT+IHQWLtXJG6nRUrvyR4wNEBXUq27yXOicC2LxMMpe6hRaOOxXDcAnyFSsCrHHmC2QpqAMF8SRA== X-Received: by 2002:a17:906:470a:b0:a44:1f24:d982 with SMTP id y10-20020a170906470a00b00a441f24d982mr883921ejq.50.1709284507555; Fri, 01 Mar 2024 01:15:07 -0800 (PST) Message-ID: <1d9b7966eb94ab424cfb8db3f913cc5e50e7707a.camel@gmail.com> Subject: Re: [PATCH v5 04/23] xen/asm-generic: introduce generic fls() and flsl() functions From: Oleksii To: Andrew Cooper , xen-devel@lists.xenproject.org Cc: George Dunlap , Jan Beulich , Julien Grall , Stefano Stabellini , Wei Liu Date: Fri, 01 Mar 2024 10:15:06 +0100 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.50.2 (3.50.2-1.fc39) MIME-Version: 1.0 On Thu, 2024-02-29 at 16:25 +0000, Andrew Cooper wrote: > On 26/02/2024 5:38 pm, Oleksii Kurochko wrote: > > These functions can be useful for architectures that don't > > have corresponding arch-specific instructions. > >=20 > > Signed-off-by: Oleksii Kurochko > > --- > > =C2=A0Changes in V5: > > =C2=A0=C2=A0 - new patch > > --- > > =C2=A0xen/include/asm-generic/bitops/fls.h=C2=A0 | 18 +++++++++++++++++= + > > =C2=A0xen/include/asm-generic/bitops/flsl.h | 10 ++++++++++ > > =C2=A02 files changed, 28 insertions(+) > > =C2=A0create mode 100644 xen/include/asm-generic/bitops/fls.h > > =C2=A0create mode 100644 xen/include/asm-generic/bitops/flsl.h > >=20 > > diff --git a/xen/include/asm-generic/bitops/fls.h > > b/xen/include/asm-generic/bitops/fls.h > > new file mode 100644 > > index 0000000000..369a4c790c > > --- /dev/null > > +++ b/xen/include/asm-generic/bitops/fls.h > > @@ -0,0 +1,18 @@ > > +/* SPDX-License-Identifier: GPL-2.0 */ > > +#ifndef _ASM_GENERIC_BITOPS_FLS_H_ > > +#define _ASM_GENERIC_BITOPS_FLS_H_ > > + > > +/** > > + * fls - find last (most-significant) bit set > > + * @x: the word to search > > + * > > + * This is defined the same way as ffs. > > + * Note fls(0) =3D 0, fls(1) =3D 1, fls(0x80000000) =3D 32. > > + */ > > + > > +static inline int fls(unsigned int x) > > +{ > > +=C2=A0=C2=A0=C2=A0 return generic_fls(x); > > +} > > + > > +#endif /* _ASM_GENERIC_BITOPS_FLS_H_ */ > > diff --git a/xen/include/asm-generic/bitops/flsl.h > > b/xen/include/asm-generic/bitops/flsl.h > > new file mode 100644 > > index 0000000000..d0a2e9c729 > > --- /dev/null > > +++ b/xen/include/asm-generic/bitops/flsl.h > > @@ -0,0 +1,10 @@ > > +/* SPDX-License-Identifier: GPL-2.0 */ > > +#ifndef _ASM_GENERIC_BITOPS_FLSL_H_ > > +#define _ASM_GENERIC_BITOPS_FLSL_H_ > > + > > +static inline int flsl(unsigned long x) > > +{ > > +=C2=A0=C2=A0=C2=A0 return generic_flsl(x); > > +} > > + > > +#endif /* _ASM_GENERIC_BITOPS_FLSL_H_ */ >=20 > Please don't do this.=C2=A0 It's compounding existing problems we have > with > bitops, and there's a way to simplify things instead. >=20 > If you can wait a couple of days, I'll see about finishing and > posting > my prototype demonstrating a simplification across all architectures, > and a reduction of code overall. Please add me in CC. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Fri Mar 01 09:16:42 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2024 09:16:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687589.1071244 (Exim 4.92) (envelope-from ) id 1rfz0T-0003ek-G1; Fri, 01 Mar 2024 09:16:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687589.1071244; Fri, 01 Mar 2024 09:16:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rfz0T-0003ed-D9; Fri, 01 Mar 2024 09:16:41 +0000 Received: by outflank-mailman (input) for mailman id 687589; Fri, 01 Mar 2024 09:16:40 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rfz0S-0003eX-6l for xen-devel@lists.xenproject.org; Fri, 01 Mar 2024 09:16:40 +0000 Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [2a00:1450:4864:20::233]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 691a7b71-d7ac-11ee-afd8-a90da7624cb6; Fri, 01 Mar 2024 10:16:39 +0100 (CET) Received: by mail-lj1-x233.google.com with SMTP id 38308e7fff4ca-2d24a727f78so21179911fa.0 for ; Fri, 01 Mar 2024 01:16:39 -0800 (PST) Received: from [192.168.1.10] (host-92-3-248-192.as13285.net. [92.3.248.192]) by smtp.gmail.com with ESMTPSA id m17-20020a056000009100b0033e17341ebesm2522113wrx.117.2024.03.01.01.16.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 01 Mar 2024 01:16:37 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 691a7b71-d7ac-11ee-afd8-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709284599; x=1709889399; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=4KAm7XliOdsaghbbgy3LsDm15LulpQtoKQtUPngD2eo=; b=Vp0KNepoWAP8U5odW1NA+3DQfdNSEABTOKqr+hjTfUBinzdBpXgtHlVYAMqqnePIDa ns2jpxq59cT3vWwbb0WCGjJ4KwDCoj5ch3quoOvfBvLvp04D2z0TtL3BecJq4dx9FMDh TxwD9y0KTYoW7aHTbA43MMUoKKAOCh8Yaqzhc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709284599; x=1709889399; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=4KAm7XliOdsaghbbgy3LsDm15LulpQtoKQtUPngD2eo=; b=tUtp/n3h6gpQDn1CrK+vdO18nHANNe2Hxg0AfHFbv6eiJMtaPjKRzzMeECIHQFL81b 9zkLcujTAtR+31xvVzIhjrVhTs/nWZQm/42EF7ja+RVvFCQL9O09IJ4oTIDIdi4KXt+U KT/CZSrNBsJ05OJG1krlnf+5mXZWGjqViVP0UPV/L1KaGIzc4YXK6SWIMtPziyPU+PN8 Pkk0Gh2dXOQbti3uEUk+tTaAUqiktqKs/KNYDLX1LDhrPE08JTdqXtL/F20SgUjQDMdf oLf1zXL0nQNqJ75MKwFqIO2SejnWISw3LK4FtxIVtnb5HyADNTjx/jAJlcNDTPcyVeo0 Arlw== X-Gm-Message-State: AOJu0YwnbPno5BluwpvrRsDg7zBNw4F9skutkjG4BGd2qZJ4Gqx7YtNV u/EPKWbQ8rKdHoMvbxEwB7qdanrqnelwOthqxQeYG7EZpCTdy5W013Ex1iIBmp4= X-Google-Smtp-Source: AGHT+IEjPHdnAu8Svo6JbmnEEfd6Q/HurxXT95x8cipSigt5/NnWvB5kpvUh51/pj+geXIu1d3bWHA== X-Received: by 2002:a05:6512:51a:b0:513:114c:5b3 with SMTP id o26-20020a056512051a00b00513114c05b3mr806312lfb.21.1709284598828; Fri, 01 Mar 2024 01:16:38 -0800 (PST) Message-ID: <74617e79-5b5c-4cd7-86da-92dd8239b8b2@citrix.com> Date: Fri, 1 Mar 2024 09:16:36 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] docs/misra/rules.rst: Fix entry for 20.12 rule Content-Language: en-GB To: Luca Fancellu , Michal Orzel Cc: Xen-devel , George Dunlap , Jan Beulich , Julien Grall , Stefano Stabellini , Wei Liu References: <20240301084947.19241-1-michal.orzel@amd.com> From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 01/03/2024 8:52 am, Luca Fancellu wrote: >> On 1 Mar 2024, at 08:49, Michal Orzel wrote: >> >> Commit 4cac80e22600 broke the CI cppcheck jobs by adding an entry for >> a rule 20.12 with "Severity" and "Summary" fields placed in reverse order. >> This leads to an error as reported by convert_misra_doc.py: >> No summary for rule 20.12 >> >> Fixes: 4cac80e22600 ("docs/misra/rules.rst: add rule 16.6 and 20.12") >> Signed-off-by: Michal Orzel >> --- >> Failed pipeline: >> https://gitlab.com/xen-project/xen/-/pipelines/1196428827 >> --- > Reviewed-by: Luca Fancellu Thanks for the fast turnaround.  Lets hope the next run on staging fairs better. ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Mar 01 09:56:47 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2024 09:56:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687597.1071258 (Exim 4.92) (envelope-from ) id 1rfzd2-0001Lt-En; Fri, 01 Mar 2024 09:56:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687597.1071258; Fri, 01 Mar 2024 09:56:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rfzd2-0001Lm-Bb; Fri, 01 Mar 2024 09:56:32 +0000 Received: by outflank-mailman (input) for mailman id 687597; Fri, 01 Mar 2024 09:56:30 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rfzd0-0001Lg-LY for xen-devel@lists.xenproject.org; Fri, 01 Mar 2024 09:56:30 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rfzcz-0008Vy-JE; Fri, 01 Mar 2024 09:56:29 +0000 Received: from gw1.octic.net ([88.97.20.152] helo=[10.0.1.240]) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1rfzcz-000153-4S; Fri, 01 Mar 2024 09:56:29 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID; bh=rbTrwl3BY9ZyXkcvo/le8kgvFrsWpOqK/cak/CaBn64=; b=Zksstf9rRio+GHP8QpHqh3CrQI 2n5SisEkLFQHiz64tpHnN4eH5UHQX0AYAt+w5qy1vAXmHCRmySqf3+kFBXwvJHEe4LlyVn29gb0xA oZbI/7JyFD1zuhmxUqoSzO/iUhy8FodzMyRUcr/DQ5mL9P4bdT44csZuET4Yiqc6yibA=; Message-ID: <4bd44ce1-87ee-4426-a693-c82e6a25edb5@xen.org> Date: Fri, 1 Mar 2024 09:56:27 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] arch: move array_index_mask_nospec() Content-Language: en-GB To: Jan Beulich , "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , George Dunlap , Stefano Stabellini , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk References: <239f2a0a-f1da-4c25-af43-dfac51bb1bd8@suse.com> From: Julien Grall In-Reply-To: <239f2a0a-f1da-4c25-af43-dfac51bb1bd8@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Jan, On 26/02/2024 10:34, Jan Beulich wrote: > At the time they were introduced, there were no asm/nospec.h yet, so > they were placed in system.h. Move them to nospec.h and drop > xen/nospec.h's including of asm/system.h; there's one unrelated #include > that needs adding in exchange, on x86. > > Signed-off-by: Jan Beulich Acked-by: Julien Grall Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Fri Mar 01 11:08:45 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2024 11:08:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687608.1071270 (Exim 4.92) (envelope-from ) id 1rg0ki-0002E4-9X; Fri, 01 Mar 2024 11:08:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687608.1071270; Fri, 01 Mar 2024 11:08:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg0ki-0002Dx-6N; Fri, 01 Mar 2024 11:08:32 +0000 Received: by outflank-mailman (input) for mailman id 687608; Fri, 01 Mar 2024 11:08:31 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg0kh-0002Dr-9d for xen-devel@lists.xenproject.org; Fri, 01 Mar 2024 11:08:31 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg0kd-0001dY-Kb; Fri, 01 Mar 2024 11:08:27 +0000 Received: from gw1.octic.net ([88.97.20.152] helo=[10.0.1.240]) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1rg0kd-00057f-8A; Fri, 01 Mar 2024 11:08:27 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID; bh=GRAgjK5TgjtLOPiI+Ga1BztGBXU/zSnBXDU/85DUmME=; b=KsTLfLtsOTbly7k4wE4DAarbg0 QxI33RVVYlDO5wtcaWyYVGa4TJgBe/8lrwwdhh2qPPkXJbIVHrjXzW41jQS2SwY9mJnI/C+en3FCo 0FdQGWPKUhFKoIlm96rZ/BkcrXj3ggN2IT+7QVvzvsB4PONaKdc2IxE15KVDoIQTgulU=; Message-ID: Date: Fri, 1 Mar 2024 11:08:25 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: preparations for 4.18.1 Content-Language: en-GB To: Stefano Stabellini , Jan Beulich Cc: Wei Liu , Anthony Perard , Kelly Choi , "xen-devel@lists.xenproject.org" , michal.orzel@amd.com References: <7dc621a0-924c-499c-86c1-c35ec1f34ec2@suse.com> <1f251f2e-91de-4f81-a93c-dcb95746d2e5@xen.org> <5a4e8583-7747-4f24-94f0-d040dabb5b04@suse.com> <521a4d3b-8ef1-4449-97bd-1a3d3e0e35ec@xen.org> <00881c6e-22a5-4283-b071-a9b92fbaf89a@suse.com> From: Julien Grall In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Stefano, On 29/02/2024 17:47, Stefano Stabellini wrote: > On Thu, 29 Feb 2024, Jan Beulich wrote: >> On 28.02.2024 23:45, Stefano Stabellini wrote: >>> On Wed, 28 Feb 2024, Julien Grall wrote: >>>> On 28/02/2024 12:58, Jan Beulich wrote: >>>>> On 28.02.2024 12:50, Julien Grall wrote: >>>>>> On 27/02/2024 13:19, Jan Beulich wrote: >>>>>>> the release is due in two to three weeks. Please point out backports you >>>>>>> find >>>>>>> missing from the respective staging branch, but which you consider >>>>>>> relevant. >>>>>> >>>>>> For Arm: >>>>>> >>>>>> e11f576650 ("xen/arm: Fix UBSAN failure in start_xen()") >>>>> >>>>> Which I assume you or Stefano will take care of? >>>> >>>> I was expecting Stefano would do it as he did the backports in the past. >> >> Was it deliberate that you did not also put it on the 4.17 branch? > > Yes, I wasn't sure how far back we want to backport so I thought it > would be better to check with Julien and Michal. I think this wants to be backported to xen 4.17 as well. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Fri Mar 01 11:28:43 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2024 11:28:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687614.1071280 (Exim 4.92) (envelope-from ) id 1rg149-00051U-Po; Fri, 01 Mar 2024 11:28:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687614.1071280; Fri, 01 Mar 2024 11:28:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg149-00051N-NE; Fri, 01 Mar 2024 11:28:37 +0000 Received: by outflank-mailman (input) for mailman id 687614; Fri, 01 Mar 2024 11:28:36 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg148-00051H-DC for xen-devel@lists.xenproject.org; Fri, 01 Mar 2024 11:28:36 +0000 Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [2a00:1450:4864:20::530]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id d69a8de7-d7be-11ee-a1ee-f123f15fe8a2; Fri, 01 Mar 2024 12:28:34 +0100 (CET) Received: by mail-ed1-x530.google.com with SMTP id 4fb4d7f45d1cf-566adfeced4so1992665a12.1 for ; Fri, 01 Mar 2024 03:28:34 -0800 (PST) Received: from andrewcoop.citrite.net (default-46-102-197-194.interdsl.co.uk. [46.102.197.194]) by smtp.gmail.com with ESMTPSA id n3-20020aa7db43000000b005656bbb5b3fsm1467468edt.63.2024.03.01.03.28.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 Mar 2024 03:28:31 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d69a8de7-d7be-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709292512; x=1709897312; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=o0zq5bFjmGngwRsCaHJlRgEEJBypuQP/Dgz8GKDt0Ao=; b=A7TPEVioUo91aISvm8rMiD6lJlhUhhG/9KwnnfTnsq9b/k3HAGsWIg5QUG+DIJTa7h 7MjGmFYfn7ngugqA41LyjXWojqYO7bGPihwFDk8c/FCokcIy84wWOlW5/FoVkd6yT/JL iyxcR6bn/KmjILziOC3PQskiIO4Grq+l7PqsE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709292512; x=1709897312; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=o0zq5bFjmGngwRsCaHJlRgEEJBypuQP/Dgz8GKDt0Ao=; b=gpcOgCqGaLTcoSgh6W3dhUtT9PR4/xA6OWxTs5oSG5/j3FPclcTMrZjQ4c6MstSbpz WTiEhJD9fEJe32yzpWq0vITITdvcR0Dj0HYglgj9YYDyf1cOoCWayXj6jJJWutK5hf1S K/ZOpGnoMTAGfBtN/jS5kThvCOmbvfLVeT+83gd70Nxq9Z+0iZbIhfQbZ/ohaIAqM0l6 ot+IObbm5POV4KSvAGqU0N0Od/yQY1633NzI9Dc6zi8JDikjh1Obzwf8A2kYNyJQ0Gzp T6jb3qBbRc/86JebSzdKE+JCMEYEY+VBYGpuM/jSRgZL/HtfqRO+dVKdWemWwyYVaoI1 dR5g== X-Gm-Message-State: AOJu0YzrM0knUoN3bVo4wb1lcKUqiDZSHA7mJk3U5MDuJLYCSbLFj5vF OvtaaqfQrIS7P0pyfABUcrnVE6mvPOvheCBt9kL0i9B/L/CdMw3cvVqpBrkyxnuD2uzff9we/Ct p X-Google-Smtp-Source: AGHT+IEtlqU/3Pk3hq+elEbuNqrfkEqwQ7NPMcDsW/tKhCr4Th3y3tMG67y+rZg8r0Wpw8SBS6zwmQ== X-Received: by 2002:a05:6402:1053:b0:564:d715:1d67 with SMTP id e19-20020a056402105300b00564d7151d67mr1045812edu.17.1709292512450; Fri, 01 Mar 2024 03:28:32 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Wei Liu Subject: [PATCH] x86/cpu-policy: Fix visibility of HTT/CMP_LEGACY in max policies Date: Fri, 1 Mar 2024 11:28:29 +0000 Message-Id: <20240301112829.2657865-1-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The block in recalculate_cpuid_policy() predates the proper split between default and max policies, and was a "slightly max for a toolstack which knows about it" capability. It didn't get transformed properly in Xen 4.14. Because Xen will accept a VM with HTT/CMP_LEGACY seen, they should be visible in the max polices. Keep the default policy matching host settings. This manifested as an incorrectly-rejected migration across XenServer's Xen 4.13 -> 4.17 upgrade, as Xapi is slowly growing the logic to check a VM against the target max policy. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Wei Liu --- xen/arch/x86/cpu-policy.c | 29 ++++++++++++++++++++++------- 1 file changed, 22 insertions(+), 7 deletions(-) diff --git a/xen/arch/x86/cpu-policy.c b/xen/arch/x86/cpu-policy.c index c9b32bc17849..4f558e502e01 100644 --- a/xen/arch/x86/cpu-policy.c +++ b/xen/arch/x86/cpu-policy.c @@ -464,6 +464,16 @@ static void __init guest_common_max_feature_adjustments(uint32_t *fs) raw_cpu_policy.feat.clwb ) __set_bit(X86_FEATURE_CLWB, fs); } + + /* + * Topology information inside the guest is entirely at the toolstack's + * disgression, and bears no relationship to the host we're running on. + * + * HTT identifies p->basic.lppp as valid + * CMP_LEGACY identifies p->extd.nc as valid + */ + __set_bit(X86_FEATURE_HTT, fs); + __set_bit(X86_FEATURE_CMP_LEGACY, fs); } static void __init guest_common_default_feature_adjustments(uint32_t *fs) @@ -514,6 +524,18 @@ static void __init guest_common_default_feature_adjustments(uint32_t *fs) __clear_bit(X86_FEATURE_CLWB, fs); } + /* + * Topology information is at the toolstack's discretion so these are + * unconditionally set in max, but pick a default which matches the host. + */ + __clear_bit(X86_FEATURE_HTT, fs); + if ( cpu_has_htt ) + __set_bit(X86_FEATURE_HTT, fs); + + __clear_bit(X86_FEATURE_CMP_LEGACY, fs); + if ( cpu_has_cmp_legacy ) + __set_bit(X86_FEATURE_CMP_LEGACY, fs); + /* * On certain hardware, speculative or errata workarounds can result in * TSX being placed in "force-abort" mode, where it doesn't actually @@ -861,13 +883,6 @@ void recalculate_cpuid_policy(struct domain *d) } } - /* - * Allow the toolstack to set HTT and CMP_LEGACY. These bits - * affect how to interpret topology information in other cpuid leaves. - */ - __set_bit(X86_FEATURE_HTT, max_fs); - __set_bit(X86_FEATURE_CMP_LEGACY, max_fs); - /* * 32bit PV domains can't use any Long Mode features, and cannot use * SYSCALL on non-AMD hardware. -- 2.30.2 From xen-devel-bounces@lists.xenproject.org Fri Mar 01 11:43:34 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2024 11:43:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687617.1071291 (Exim 4.92) (envelope-from ) id 1rg1IX-0007fJ-2G; Fri, 01 Mar 2024 11:43:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687617.1071291; Fri, 01 Mar 2024 11:43:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg1IW-0007fC-VE; Fri, 01 Mar 2024 11:43:28 +0000 Received: by outflank-mailman (input) for mailman id 687617; Fri, 01 Mar 2024 11:43:27 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg1IV-0007f6-7r for xen-devel@lists.xenproject.org; Fri, 01 Mar 2024 11:43:27 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id ea135df9-d7c0-11ee-afd8-a90da7624cb6; Fri, 01 Mar 2024 12:43:25 +0100 (CET) Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) by support.bugseng.com (Postfix) with ESMTPA id 5FD894EE0737; Fri, 1 Mar 2024 12:43:25 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ea135df9-d7c0-11ee-afd8-a90da7624cb6 MIME-Version: 1.0 Date: Fri, 01 Mar 2024 12:43:25 +0100 From: Nicola Vetrini To: Xen Devel Cc: Andrew Cooper3 , George Dunlap , Stefano Stabellini , Jbeulich , Julien Grall , Wei Liu , Roger Pau , Consulting Subject: Violations of MISRA C Rule 20.7 in xen/arch/x86/include/asm/hvm/trace.h Message-ID: X-Sender: nicola.vetrini@bugseng.com Organization: BUGSENG s.r.l. Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Reporting the discussion that took place on Matrix on the matter, so that it can carry on here with all interested parties: > Hi everyone. I was looking at MISRA violations for Rule 20.7 > ("Expressions resulting from the expansion of macro parameters shall be > enclosed in parentheses") generated by > > #define TRC_PAR_LONG(par) ((uint32_t)(par)), ((par) >> 32) > > The thing here is this: the simplest fix is > > -#define TRC_PAR_LONG(par) ((uint32_t)(par)), ((par) >> 32) > +#define TRC_PAR_LO(par) ((uint32_t)(par)) > +#define TRC_PAR_HI(par) ((par) >> 32) > > and then replace all call sites accordingly. However, in certain places > (e.g., svm.c:1445), this causes a build error: > > arch/x86/hvm/svm/svm.c: In function ‘svm_inject_event’: > arch/x86/hvm/svm/svm.c:1445:1: error: macro "HVMTRACE_3D" requires > 4 arguments, but only 3 given > 1445 | TRC_PAR_LO(_event.cr2), TRC_PAR_HI(_event.cr2)); > | ^ > In file included from arch/x86/hvm/svm/svm.c:31: > > this is due to the somewhat strange definition of HVMTRACE_3D which > works with the previous form of the macro, but not the current one, as > the macro argument in HVMTRACE_LONG_2D is now split (_LO is d2 and _HI > is variadic), and therefore it's not passed to HVMTRACE_3D anymore as > two arguments. > I have a proposal: introduce a d3 argument to HVMTRACE_LONG_2D to > supply the additional argument and/or make HVMTRACE_LONG_2D > non-variadic. This would of course apply to the similarly named macros > in xen/arch/x86/include/asm/hvm/trace.h Andrew Cooper: > sigh - I'm half way through deleting all of that > guess I ought to finish Andrew Cooper: > @Nicola Vetrini: > https://xenbits.xen.org/gitweb/?p=people/andrewcoop/xen.git;a=shortlog;h=refs/heads/xen-trace > On second thoughts I'm not sure it fixes the problem > just changes it. The problem is the use of macros to split a 64bit > quantity across two 32bit fields Nicola Vetrini: > It seems so, yes. But afaict this can be fixed by splitting the macro > definition in two, as done above, which wouldn't incur in the > compilation error on the new API Andrew Cooper: > given the users of TRACE_PARAM64() by the end, I'd prefer to do that > with real structs rather than perpetuating the macro mess George Dunlap: > It's been a long time since I looked at all this, but FWIW I inherited > all the weird macro stuff, never liked it, and myself used structs for > all new traces. So without having looked at the code at all, I'm > predisposed to agree w/ Andy's assessment that we should just rip out > the offending macros and replace them with structs. @gwd: I believe the file that I was concerned about does not fall under the XENTRACE entry in MAINTAINERS; you may want to rectify that. -- Nicola Vetrini, BSc Software Engineer, BUGSENG srl (https://bugseng.com) From xen-devel-bounces@lists.xenproject.org Fri Mar 01 11:49:56 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2024 11:49:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687620.1071300 (Exim 4.92) (envelope-from ) id 1rg1Oh-00008J-Pj; Fri, 01 Mar 2024 11:49:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687620.1071300; Fri, 01 Mar 2024 11:49:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg1Oh-00008B-N3; Fri, 01 Mar 2024 11:49:51 +0000 Received: by outflank-mailman (input) for mailman id 687620; Fri, 01 Mar 2024 11:49:50 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg1Og-000085-So for xen-devel@lists.xenproject.org; Fri, 01 Mar 2024 11:49:50 +0000 Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [2607:f8b0:4864:20::f2b]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id ceca50c1-d7c1-11ee-afd8-a90da7624cb6; Fri, 01 Mar 2024 12:49:49 +0100 (CET) Received: by mail-qv1-xf2b.google.com with SMTP id 6a1803df08f44-68fe8e20259so10041526d6.2 for ; Fri, 01 Mar 2024 03:49:49 -0800 (PST) Received: from localhost ([213.195.118.74]) by smtp.gmail.com with ESMTPSA id em19-20020ad44f93000000b0068fdb03a3a3sm1781231qvb.95.2024.03.01.03.49.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 Mar 2024 03:49:48 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ceca50c1-d7c1-11ee-afd8-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709293789; x=1709898589; darn=lists.xenproject.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=FNBpkR65MTOl8/GCeLBTKCHJTdEnwJffWZmpG66n6cc=; b=VF19pbGCv6tpHngxxst0x/dkiNEVt3zUVx5Q6o9gfT5/kwEG+oxxrdlfksP5ctBNB9 3v0kvd1JnMVcwe1n1XX1icGXSsmhPnVVwUHzaF0e8OFUarOklXorX5SE7uAQ2IG+z/Z5 xaBBmuFWGdeeO2g44a+/NF/4rXHAWetpWPGJk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709293789; x=1709898589; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=FNBpkR65MTOl8/GCeLBTKCHJTdEnwJffWZmpG66n6cc=; b=aaBmc4vtLNfxRE1QZbupr9JOI+YA30Nf9pZBfiEZcv5fmtViKP9B1b298HZgONQddx js42K85bjsHgC0Pu3xFAs0ipLq7/1ZP4KcBFy9Uh4r9j6/xhFO36bOMnWlDgDdnc8YMI Owh7QulasE39k1I4x5w5RfMQMMdivJ0P0gYW5qirEluT8LUZPUbX1eQYrVKaE3pXuZsc l0o2kZPmX1gvo2sa6CUOpxAXN1oTdXnvTMYZFIN7+Hcybh/yGfCwPKNP6zVaO4TxeYBT vwXFqFe4en6nnU/IX3CYCnE5LSX961B/Pwr1/jpiFr8HESasR6gKwxneOpfzPs/eN7zm D+9Q== X-Gm-Message-State: AOJu0YzzZnX62sh/CuRgCU//U73tG1tyeA7tqohyHYk4UBL9D4mZsQpB QMAZPsSZF+FWAb+L25bkoC2DxBa1L6sB22WT4Bt2UnprQtJxg/YUlKq8OsFqr+Q= X-Google-Smtp-Source: AGHT+IGbx7vWnNS/Isdsv654Vl3DbaT+eJ6GtoTm9x/oJ+T4BcOQVOTFEEVhx+w02sXY22HkKFyRHA== X-Received: by 2002:a0c:f892:0:b0:68f:b5b3:c417 with SMTP id u18-20020a0cf892000000b0068fb5b3c417mr1439989qvn.11.1709293788882; Fri, 01 Mar 2024 03:49:48 -0800 (PST) Date: Fri, 1 Mar 2024 12:49:46 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Andrew Cooper Cc: Xen-devel , Jan Beulich , Wei Liu Subject: Re: [PATCH] tests/resource: Fix HVM guest in !SHADOW builds Message-ID: References: <20240229205354.2574207-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20240229205354.2574207-1-andrew.cooper3@citrix.com> On Thu, Feb 29, 2024 at 08:53:54PM +0000, Andrew Cooper wrote: > Right now, test-resource always creates HVM Shadow guests. But if Xen has > SHADOW compiled out, running the test yields: > > $./test-resource > XENMEM_acquire_resource tests > Test x86 PV > Created d1 > Test grant table > Test x86 PVH > Skip: 95 - Operation not supported > > and doesn't really test HVM guests, but doesn't fail either. > > There's nothing paging-mode-specific about this test, so default to HAP if > possible and provide a more specific message if neither HAP or Shadow are > available. > > Signed-off-by: Andrew Cooper Acked-by: Roger Pau Monné One comment below. > --- > CC: Jan Beulich > CC: Roger Pau Monné > CC: Wei Liu > --- > tools/tests/resource/test-resource.c | 25 +++++++++++++++++++++++++ > 1 file changed, 25 insertions(+) > > diff --git a/tools/tests/resource/test-resource.c b/tools/tests/resource/test-resource.c > index 7ae88ea34807..2796053588d3 100644 > --- a/tools/tests/resource/test-resource.c > +++ b/tools/tests/resource/test-resource.c > @@ -20,6 +20,8 @@ static xc_interface *xch; > static xenforeignmemory_handle *fh; > static xengnttab_handle *gh; > > +static xc_physinfo_t physinfo; > + > static void test_gnttab(uint32_t domid, unsigned int nr_frames, > unsigned long gfn) > { > @@ -172,6 +174,23 @@ static void test_domain_configurations(void) > > printf("Test %s\n", t->name); > > +#if defined(__x86_64__) || defined(__i386__) > + /* > + * On x86, use HAP guests if possible, but skip if neither HAP nor > + * SHADOW is available. > + */ > + if ( t->create.flags & XEN_DOMCTL_CDF_hvm ) > + { > + if ( physinfo.capabilities & XEN_SYSCTL_PHYSCAP_hap ) > + t->create.flags |= XEN_DOMCTL_CDF_hap; > + else if ( !(physinfo.capabilities & XEN_SYSCTL_PHYSCAP_shadow) ) > + { > + printf(" Skip: Neither HAP or SHADOW available\n"); > + continue; > + } > + } Provided that you are already checking, might also be worth to keep in mind that at some point we might want to also check for XEN_SYSCTL_PHYSCAP_{hvm,pv} and skip those tests if the requested domain type is not available. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Fri Mar 01 11:58:58 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2024 11:58:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687625.1071310 (Exim 4.92) (envelope-from ) id 1rg1XM-0001fO-KG; Fri, 01 Mar 2024 11:58:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687625.1071310; Fri, 01 Mar 2024 11:58:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg1XM-0001fH-HZ; Fri, 01 Mar 2024 11:58:48 +0000 Received: by outflank-mailman (input) for mailman id 687625; Fri, 01 Mar 2024 11:58:47 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg1XK-0001es-UD for xen-devel@lists.xenproject.org; Fri, 01 Mar 2024 11:58:46 +0000 Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [2607:f8b0:4864:20::72e]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 0df2a087-d7c3-11ee-afd8-a90da7624cb6; Fri, 01 Mar 2024 12:58:45 +0100 (CET) Received: by mail-qk1-x72e.google.com with SMTP id af79cd13be357-787c900af02so150582285a.1 for ; Fri, 01 Mar 2024 03:58:45 -0800 (PST) Received: from [10.80.67.149] (default-46-102-197-194.interdsl.co.uk. [46.102.197.194]) by smtp.gmail.com with ESMTPSA id po10-20020a05620a384a00b00787bb956e07sm1568460qkn.76.2024.03.01.03.58.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 01 Mar 2024 03:58:43 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 0df2a087-d7c3-11ee-afd8-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709294324; x=1709899124; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=Q0uBECgOumcLo4ycKlv0F8SbxteGojvvBk2nW0PcJlI=; b=JP9pyxz09QfRQZQjspyq83y5naTA18C7bAutnSnwE0cENTVEadL85/M/aiLuW50Ac/ mMKmTWadCIOZscjFaoUhxv8PCGCLtcujZWK/Ih5ljPMRPJepZMzwwQwQXA7givpbsJSg KSDg1gbUcGv2V5zddhtz0LI2FazkT5DasvRvc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709294324; x=1709899124; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Q0uBECgOumcLo4ycKlv0F8SbxteGojvvBk2nW0PcJlI=; b=WuU8IB6iV4ZLEIYOfi02alOXmAVHorxd9NY+TKZBsTF30Yaiex3lawobj1HiAI3lEG QGbPzP1pqAg2bpZiE7y2An02y56+y4oQyEBSLebEiHndVrPjIgrck/8rEEfAC33u6nVS wxwF46Oet6Coh7g3NW7HM7QZrpTsZtUWjyTBV9BRj2YLwMNDJ9hOjeiI9OoWPTIM0JXb eRRZaFsjAq+OonJ8NvTMnSrHf/rfmQRHvI1y2zrm1E+Okpt8c7EaY8U/Vm3hjYslAPpC cjP0ejKgBCymE7D3zwww/7zOMa1GZLokaFornQYluXDC4dmJfU50Ym+de+SBDUyWHCji RIzA== X-Forwarded-Encrypted: i=1; AJvYcCUk4MOEHltYDywcwc0j+SYI3rF+kV/klF6JaRbsjhqW3hoy49k0q+hnJrGQxBU6Nuz/7fjBmLtSCRtNykkObRb8oWm2CinsRU8t1xMGN7o= X-Gm-Message-State: AOJu0Yyhjd7mVLn7TYMNmxMV8INbc7Y4C1NfBzwaUAyNlcRT+I4tvVOu O4WNPcHOdYn2Eg/gRFa3rEUa6n8LJ077YWasi+hrYfmrMStWBaXxP3RGYuZMeGU= X-Google-Smtp-Source: AGHT+IGQlTqkV8d/1sludf0XM1jEEUksJottcjFTVBoK6NqUQATzkDovRkBDALMBL+kpglSMgBu5MQ== X-Received: by 2002:a05:620a:45a0:b0:788:2d3:8c9c with SMTP id bp32-20020a05620a45a000b0078802d38c9cmr5467858qkb.27.1709294324292; Fri, 01 Mar 2024 03:58:44 -0800 (PST) Message-ID: <24db0ffc-fdab-4368-8a97-5c8fb8c2b779@citrix.com> Date: Fri, 1 Mar 2024 11:58:41 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Violations of MISRA C Rule 20.7 in xen/arch/x86/include/asm/hvm/trace.h Content-Language: en-GB To: Nicola Vetrini , Xen Devel Cc: George Dunlap , Stefano Stabellini , Jbeulich , Julien Grall , Wei Liu , Roger Pau , Consulting References: From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 01/03/2024 11:43 am, Nicola Vetrini wrote: > Reporting the discussion that took place on Matrix on the matter, so > that it can carry on here with all interested parties: > >> Hi everyone. I was looking at MISRA violations for Rule 20.7 >> ("Expressions resulting from the expansion of macro parameters shall >> be enclosed in parentheses") generated by >> >>     #define TRC_PAR_LONG(par) ((uint32_t)(par)), ((par) >> 32) >> >> The thing here is this: the simplest fix is >> >>     -#define TRC_PAR_LONG(par) ((uint32_t)(par)), ((par) >> 32) >>     +#define TRC_PAR_LO(par) ((uint32_t)(par)) >>     +#define TRC_PAR_HI(par) ((par) >> 32) >> >> and then replace all call sites accordingly. However, in certain >> places (e.g., svm.c:1445), this causes a build error: >> >>     arch/x86/hvm/svm/svm.c: In function ‘svm_inject_event’: >>     arch/x86/hvm/svm/svm.c:1445:1: error: macro "HVMTRACE_3D" >> requires 4 arguments, but only 3 given >>     1445 | TRC_PAR_LO(_event.cr2), TRC_PAR_HI(_event.cr2)); >>     | ^ >>     In file included from arch/x86/hvm/svm/svm.c:31: >> >> this is due to the somewhat strange definition of HVMTRACE_3D which >> works with the previous form of the macro, but not the current one, >> as the macro argument in HVMTRACE_LONG_2D is now split (_LO is d2 and >> _HI is variadic), and therefore it's not passed to HVMTRACE_3D >> anymore as two arguments. >> I have a proposal: introduce a d3 argument to HVMTRACE_LONG_2D to >> supply the additional argument and/or make HVMTRACE_LONG_2D >> non-variadic. This would of course apply to the similarly named >> macros in xen/arch/x86/include/asm/hvm/trace.h > > Andrew Cooper: >> sigh - I'm half way through deleting all of that >> guess I ought to finish > > Andrew Cooper: >> @Nicola Vetrini: >> https://xenbits.xen.org/gitweb/?p=people/andrewcoop/xen.git;a=shortlog;h=refs/heads/xen-trace >> On second thoughts I'm not sure it fixes the problem >> just changes it.  The problem is the use of macros to split a 64bit >> quantity across two 32bit fields > > Nicola Vetrini: >> It seems so, yes. But afaict this can be fixed by splitting the macro >> definition in two, as done above, which wouldn't incur in the >> compilation error on the new API > > Andrew Cooper: >> given the users of TRACE_PARAM64() by the end, I'd prefer to do that >> with real structs rather than perpetuating the macro mess > > George Dunlap: >> It's been a long time since I looked at all this, but FWIW I >> inherited all the weird macro stuff, never liked it, and myself used >> structs for all new traces. So without having looked at the code at >> all, I'm predisposed to agree w/ Andy's assessment that we should >> just rip out the offending macros and replace them with structs. > > @gwd: I believe the file that I was concerned about does not fall > under the XENTRACE entry in MAINTAINERS; you may want to rectify that. > My vague plan to fix this is to still take https://xenbits.xen.org/gitweb/?p=people/andrewcoop/xen.git;a=commitdiff;h=8636f0eaa0f163f8a433eb17b9e0d2e87db284b6 but not introduce TRACE_PARAM64 The users are as follows: xen.git/xen$ git grep TRACE_PARAM64 arch/x86/hvm/emulate.c:2183:        TRACE(TRC_HVM_CR_READ64, reg, TRACE_PARAM64(*val)); arch/x86/hvm/emulate.c:2199:    TRACE(TRC_HVM_CR_WRITE64, reg, TRACE_PARAM64(val)); arch/x86/hvm/emulate.c:2244:        TRACE(TRC_HVM_XCR_READ64, reg, TRACE_PARAM64(*val)); arch/x86/hvm/emulate.c:2254:    TRACE(TRC_HVM_XCR_WRITE64, reg, TRACE_PARAM64(val)); arch/x86/hvm/hpet.c:308:               TRACE_PARAM64(diff_ns), TRACE_PARAM64(period_ns)); arch/x86/hvm/hvm.c:2155:    TRACE(TRC_HVM_CR_WRITE64, cr, TRACE_PARAM64(val)); arch/x86/hvm/hvm.c:2220:    TRACE(TRC_HVM_CR_READ64, cr, TRACE_PARAM64(val)); arch/x86/hvm/hvm.c:3631:    TRACE(TRC_HVM_MSR_READ, msr, TRACE_PARAM64(*msr_content)); arch/x86/hvm/hvm.c:3647:    TRACE(TRC_HVM_MSR_WRITE, msr, TRACE_PARAM64(msr_content)); arch/x86/hvm/svm/svm.c:1442:              TRACE_PARAM64(_event.cr2)); arch/x86/hvm/svm/svm.c:2402:    TRACE(TRC_HVM_INVLPG64, 0, TRACE_PARAM64(linear)); arch/x86/hvm/svm/svm.c:2630:                   exit_reason, TRACE_PARAM64(regs->rip)); arch/x86/hvm/svm/svm.c:2826:                TRACE(TRC_HVM_PF_XEN64, regs->error_code, TRACE_PARAM64(va)); arch/x86/hvm/vlapic.c:738:        TRACE_TIME(TRC_HVM_EMUL_LAPIC_START_TIMER, TRACE_PARAM64(delta), arch/x86/hvm/vlapic.c:739:                   TRACE_PARAM64(is_periodic ? period : 0), vlapic->pt.irq); arch/x86/hvm/vlapic.c:1209:        TRACE_TIME(TRC_HVM_EMUL_LAPIC_START_TIMER, TRACE_PARAM64(delta), arch/x86/hvm/vlapic.c:1210:                   TRACE_PARAM64(0LL), vlapic->pt.irq); arch/x86/hvm/vlapic.c:1223:            TRACE_TIME(TRC_HVM_EMUL_LAPIC_START_TIMER, TRACE_PARAM64(0LL), arch/x86/hvm/vlapic.c:1224:                       TRACE_PARAM64(0LL), vlapic->pt.irq); arch/x86/hvm/vlapic.c:1477:    TRACE_TIME(TRC_HVM_EMUL_LAPIC_START_TIMER, TRACE_PARAM64(period), arch/x86/hvm/vlapic.c:1478:               TRACE_PARAM64(is_periodic ? period : 0LL), s->pt.irq); arch/x86/hvm/vmx/vmx.c:2093:              TRACE_PARAM64(curr->arch.hvm.guest_cr[2])); arch/x86/hvm/vmx/vmx.c:3099:    TRACE(TRC_HVM_INVLPG64, /*invlpga=*/ 0, TRACE_PARAM64(linear)); arch/x86/hvm/vmx/vmx.c:3160:        TRACE(TRC_HVM_LMSW64, TRACE_PARAM64(value)); arch/x86/hvm/vmx/vmx.c:4064:        TRACE_TIME(TRC_HVM_VMEXIT64, exit_reason, TRACE_PARAM64(regs->rip)); arch/x86/hvm/vmx/vmx.c:4346:                          TRACE_PARAM64(exit_qualification)); include/xen/trace.h:87:#define TRACE_PARAM64(p)    (uint32_t)(p), ((p) >> 32) and there are probably enough examples of "reg32, val64" to justify making a helper.  We're touching every site anyway, so adjudging for the next version of the series is easy. I might repost the first few patches right now.  All the fixes in the scheduler have been reviewed and ready to go for 3 release of Xen already... ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Mar 01 12:07:56 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2024 12:07:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687633.1071321 (Exim 4.92) (envelope-from ) id 1rg1g8-0003Y7-Km; Fri, 01 Mar 2024 12:07:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687633.1071321; Fri, 01 Mar 2024 12:07:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg1g8-0003Y0-HR; Fri, 01 Mar 2024 12:07:52 +0000 Received: by outflank-mailman (input) for mailman id 687633; Fri, 01 Mar 2024 12:07:50 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg1g6-0003Xu-IJ for xen-devel@lists.xenproject.org; Fri, 01 Mar 2024 12:07:50 +0000 Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [2a00:1450:4864:20::336]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 52a579a5-d7c4-11ee-afd8-a90da7624cb6; Fri, 01 Mar 2024 13:07:49 +0100 (CET) Received: by mail-wm1-x336.google.com with SMTP id 5b1f17b1804b1-412c34e84a5so8123625e9.3 for ; Fri, 01 Mar 2024 04:07:49 -0800 (PST) Received: from [10.80.67.149] (default-46-102-197-194.interdsl.co.uk. [46.102.197.194]) by smtp.gmail.com with ESMTPSA id c21-20020a05600c0a5500b00412cb0961fasm549799wmq.6.2024.03.01.04.07.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 01 Mar 2024 04:07:47 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 52a579a5-d7c4-11ee-afd8-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709294869; x=1709899669; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=yXxfSimnoRmoFAT1TH4Kc2IG3WcGZKA2IB43QW1qH2s=; b=oXlfsH7hESbU9dhoBQe92H8h5jPDwDlXKKKlKGUczS6K6sN4N0znbCwniyj7Wum4T8 pUb1hxTBbJ7iqm4y2TeRngYjQf83rnJUEqln5swmG0DzuQvP/mD58ZFaJswL6gqBYhAb EoWVQqU68caLcpI1bWcJ68btAddNqDFtM3rIk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709294869; x=1709899669; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=yXxfSimnoRmoFAT1TH4Kc2IG3WcGZKA2IB43QW1qH2s=; b=D+2p1pGVaDzdT0EIiPo0oALM54ldr4E22r7sES+oofq7jgTGmGkt9szYbu2pfb0g7Q HgfmdKBhnBT0zYBdj2XGi7SAX8XftplQp4x5ioMD0/0vkxfW2YmaOpRUjFEbdZ+bm/h8 07pnRJ9Bso8iRjKzqp7ynnAkgt+HSCvJC3bW9GNH+GueHoYzmtqEI+HAgZRlalhTl3j+ RMsqppDFFM4kMJzsEt4pWU3O6bmBwIasuwPadOGENa6I5DQkrsjjg30WMGXB9/ahnbEp FuUUOhilgX7SmY4VDFQRdT+Xx0g7r4yFkSuzCoudx/JWbbEKzmcps1vrzSwEJ3NDlH5W bsKg== X-Gm-Message-State: AOJu0YzB8TAkK44H8odiZSEas1vv0hp8e9YnW+BgtYLM1wZbP1vgJzt4 TmGcEg6XXuI3froXxA2+rvhQ38F+qoHQnpQPNpQpsMxYVddLXGwaqu/lWcOSpO8rb5rsPK4RV9W j X-Google-Smtp-Source: AGHT+IEpnXp7em0Y6tiDHUiXWmuvVfBLt7QU+qQoGfrUVkpPAsoRyAe2XYUejDT6tViEetrrRTGvOg== X-Received: by 2002:a7b:c7d9:0:b0:412:9ed4:290 with SMTP id z25-20020a7bc7d9000000b004129ed40290mr1315637wmk.25.1709294869114; Fri, 01 Mar 2024 04:07:49 -0800 (PST) Message-ID: Date: Fri, 1 Mar 2024 12:07:46 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] tests/resource: Fix HVM guest in !SHADOW builds Content-Language: en-GB To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: Xen-devel , Jan Beulich , Wei Liu References: <20240229205354.2574207-1-andrew.cooper3@citrix.com> From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 01/03/2024 11:49 am, Roger Pau Monné wrote: > On Thu, Feb 29, 2024 at 08:53:54PM +0000, Andrew Cooper wrote: >> Right now, test-resource always creates HVM Shadow guests. But if Xen has >> SHADOW compiled out, running the test yields: >> >> $./test-resource >> XENMEM_acquire_resource tests >> Test x86 PV >> Created d1 >> Test grant table >> Test x86 PVH >> Skip: 95 - Operation not supported >> >> and doesn't really test HVM guests, but doesn't fail either. >> >> There's nothing paging-mode-specific about this test, so default to HAP if >> possible and provide a more specific message if neither HAP or Shadow are >> available. >> >> Signed-off-by: Andrew Cooper > Acked-by: Roger Pau Monné > > One comment below. > >> --- >> CC: Jan Beulich >> CC: Roger Pau Monné >> CC: Wei Liu >> --- >> tools/tests/resource/test-resource.c | 25 +++++++++++++++++++++++++ >> 1 file changed, 25 insertions(+) >> >> diff --git a/tools/tests/resource/test-resource.c b/tools/tests/resource/test-resource.c >> index 7ae88ea34807..2796053588d3 100644 >> --- a/tools/tests/resource/test-resource.c >> +++ b/tools/tests/resource/test-resource.c >> @@ -20,6 +20,8 @@ static xc_interface *xch; >> static xenforeignmemory_handle *fh; >> static xengnttab_handle *gh; >> >> +static xc_physinfo_t physinfo; >> + >> static void test_gnttab(uint32_t domid, unsigned int nr_frames, >> unsigned long gfn) >> { >> @@ -172,6 +174,23 @@ static void test_domain_configurations(void) >> >> printf("Test %s\n", t->name); >> >> +#if defined(__x86_64__) || defined(__i386__) >> + /* >> + * On x86, use HAP guests if possible, but skip if neither HAP nor >> + * SHADOW is available. >> + */ >> + if ( t->create.flags & XEN_DOMCTL_CDF_hvm ) >> + { >> + if ( physinfo.capabilities & XEN_SYSCTL_PHYSCAP_hap ) >> + t->create.flags |= XEN_DOMCTL_CDF_hap; >> + else if ( !(physinfo.capabilities & XEN_SYSCTL_PHYSCAP_shadow) ) >> + { >> + printf(" Skip: Neither HAP or SHADOW available\n"); >> + continue; >> + } >> + } > Provided that you are already checking, might also be worth to keep in > mind that at some point we might want to also check for > XEN_SYSCTL_PHYSCAP_{hvm,pv} and skip those tests if the requested domain > type is not available. Fair point.  Lemme do a v2. ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Mar 01 12:11:58 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2024 12:11:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687636.1071330 (Exim 4.92) (envelope-from ) id 1rg1jy-0005N0-35; Fri, 01 Mar 2024 12:11:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687636.1071330; Fri, 01 Mar 2024 12:11:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg1jy-0005Mt-0S; Fri, 01 Mar 2024 12:11:50 +0000 Received: by outflank-mailman (input) for mailman id 687636; Fri, 01 Mar 2024 12:11:49 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg1jx-0005Mn-7g for xen-devel@lists.xenproject.org; Fri, 01 Mar 2024 12:11:49 +0000 Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [2a00:1450:4864:20::32c]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id dfc25c0e-d7c4-11ee-a1ee-f123f15fe8a2; Fri, 01 Mar 2024 13:11:46 +0100 (CET) Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-412bc3350d0so13712365e9.1 for ; Fri, 01 Mar 2024 04:11:46 -0800 (PST) Received: from localhost ([213.195.118.74]) by smtp.gmail.com with ESMTPSA id y16-20020a05600c365000b00412656ba919sm8127677wmq.20.2024.03.01.04.11.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 Mar 2024 04:11:45 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: dfc25c0e-d7c4-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709295106; x=1709899906; darn=lists.xenproject.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=KeCaJ4Swm1z+vkdsFd9E3WHBmp4+Reh3cJdm1Yf8fXU=; b=NBTpFk3PTlB1/HOAuQGxu5eblzudvB6gCrRl0cAYgIvM74y5BXBQ/AYvWwbAtEIIRP +FTAevGg5oXTne/e6s85CIZvQ4C5hx63DpaITRkjHV5Jiif+uzJNKTfwYVrnWqBPxlqY YqOKyIe+IN8i0X0ViDnlZqz2S28thJW33RbV4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709295106; x=1709899906; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=KeCaJ4Swm1z+vkdsFd9E3WHBmp4+Reh3cJdm1Yf8fXU=; b=AjbMPREcr+FZv5GXR4aO788EuBf/uDWLPf/fwGIgesHhOX7XRaOI2xsC8YmYu3Mnz5 tBUjmN0n/gdl5Rv5CFuH1olCW1IfkVgA8gkl4UPT860z6hyvarxyMaV5QaByN+imbhhJ BtnLCXmpeefnvLuvt7bbs60kzcNob4xe/1oxF4385F6S23swsvZbRxTyFktCozPhqfK8 bnmhTtRbxehjmSuXMlWVlogapWqYvREgpWUcyfUcw8tk+hpaEbYD619zx9MNbZRPj0Gt ITjRQ4Fort80cpsmZjX56GHbRrwlsHVResGQj6xtVBYfbJi5v/iZUKzI4COpyjTBOf/h vnhg== X-Gm-Message-State: AOJu0YyVgeSmQWW+lp08lcR7iSKSyDoy5F3yPnJnccAJC9Ckdnv7Na9l g0UO2T11xbCnnuP/LohWk1Ajb+79EQU8aDshaCVWMd4jZMa8C8nplMGfN6AsFDU= X-Google-Smtp-Source: AGHT+IEghepjG29HVHqguR7pQ4KZUTRY3OdRCKv1tJX/d7dOiQ9gL/POk0uGR8+PUWwsb9jct3c9IQ== X-Received: by 2002:a05:600c:154b:b0:412:a2c7:9d13 with SMTP id f11-20020a05600c154b00b00412a2c79d13mr1322308wmg.6.1709295105883; Fri, 01 Mar 2024 04:11:45 -0800 (PST) Date: Fri, 1 Mar 2024 13:11:44 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Andrew Cooper Cc: Xen-devel , Jan Beulich , Wei Liu Subject: Re: [PATCH] x86/cpu-policy: Hide x2APIC from PV guests Message-ID: References: <20240229221448.2593171-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20240229221448.2593171-1-andrew.cooper3@citrix.com> On Thu, Feb 29, 2024 at 10:14:48PM +0000, Andrew Cooper wrote: > PV guests can't write to MSR_APIC_BASE (in order to set EXTD), nor can they > access any of the x2APIC MSR range. Therefore they mustn't see the x2APIC > CPUID bit saying that they can. > > Right now, the host x2APIC flag filters into PV guests, meaning that PV guests > generally see x2APIC except on Zen1-and-older AMD systems. > > Linux works around this by explicitly hiding the bit itself, and filtering > EXTD out of MSR_APIC_BASE reads. NetBSD behaves more in the spirit of PV > guests, and entirely ignores the APIC when built as a PV guest. > > Change the annotation from !A to !S. This has a consequence of stripping it > out of both PV featuremasks. However, as existing guests may have seen the > bit, set it back into the PV Max policy; a VM which saw the bit and is alive > enough to migrate will have ignored it one way or another. > > Hiding x2APIC does also change the contents of leaf 0xb, but as the > information is nonsense to begin with, this is likely an improvement on the > status quo. The blind reporting of APIC_ID = vCPU_ID * 2 isn't interlinked > with the host's topology structure, and the APIC_IDs are useless without an > MADT to start with. AFAICT the APIC ID in CPUID leaf 0x1 %ebx is only reported to HVM guests, not PV ones (see the dynamic section of guest_cpuid()). This paragraph might need adjusting then, as it reads to me as if PV guests could also expect APIC_ID == vCPU_ID * 2. With this change no x{,2}APIC ID gets exposed in CPUID for PV guests unless it's for compat reasons for guests that already saw the x2APIC feature. > Dom0 is the only PV VM to get an MADT but it's the host > one, meaning the two sets of APIC_IDs are from different address spaces. > > Signed-off-by: Andrew Cooper Reviewed-by: Roger Pau Monné Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Fri Mar 01 12:13:15 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2024 12:13:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687638.1071340 (Exim 4.92) (envelope-from ) id 1rg1lH-0005rr-CT; Fri, 01 Mar 2024 12:13:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687638.1071340; Fri, 01 Mar 2024 12:13:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg1lH-0005rk-9p; Fri, 01 Mar 2024 12:13:11 +0000 Received: by outflank-mailman (input) for mailman id 687638; Fri, 01 Mar 2024 12:13:10 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg1lG-0005rc-7z for xen-devel@lists.xenproject.org; Fri, 01 Mar 2024 12:13:10 +0000 Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [2a00:1450:4864:20::535]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 1136c420-d7c5-11ee-afd8-a90da7624cb6; Fri, 01 Mar 2024 13:13:09 +0100 (CET) Received: by mail-ed1-x535.google.com with SMTP id 4fb4d7f45d1cf-566e869f631so251541a12.0 for ; Fri, 01 Mar 2024 04:13:09 -0800 (PST) Received: from andrewcoop.citrite.net (default-46-102-197-194.interdsl.co.uk. [46.102.197.194]) by smtp.gmail.com with ESMTPSA id s23-20020a170906a19700b00a44899a44ddsm576876ejy.11.2024.03.01.04.13.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 Mar 2024 04:13:06 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1136c420-d7c5-11ee-afd8-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709295187; x=1709899987; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=bCG8qbxo0n9jYqxMu9sKHaRmzAkZKyYUQZHqWoBMWN4=; b=tRMJ7u6g1d3YRUY2y20bfn5l4D8/AD+Fq1VTYfrAPbRyeX5OfDoFW/VWgR533SCIQ6 tam4B6z5uijA8ZeqXur/GGb6jmkEEMgxZQ1p+jF7UOqVliBS4YoNUhAkM1gBiFxpdm0u M7CIHbxXqfSYUNnZg1ZcnIRPZ8qbFTOIhFPfQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709295187; x=1709899987; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=bCG8qbxo0n9jYqxMu9sKHaRmzAkZKyYUQZHqWoBMWN4=; b=he5nvk0uVRjngyZS9tpYW3jd0TszS80z2SGwrCcmbqaeXe4xoC1Ggth/lBofiCM/GD jbt0p7OcvMzmBHcysbUZnTTbeYHvtY7/sIu8MhhrvETe6QiXL6r6a9UMBkgOR090JS01 6E6HN7ty8hNZSWHod+khhDYAIEQlOS7TPFwW3NaZ3duFa9YebiGRHDVlPBWKKA/NZABq eOA2HAwtyUnqscQs6+eT357UsDGSkQ0CvXE8xO9Myjw2B2S8nCbEW9o7mTSFYTrIDz4b lMQG0bl1SgHStCNENYGHQV7SgkeCGrrSMvxkMMx85hb8/C38qvVaOlS//HK/Q5xrVpTh au5w== X-Gm-Message-State: AOJu0YxhSDbAESjTkjlpACKbfLd1JvB18aYDYPVLWUELcY+2GPhAYW73 Tn8huE6MhoHavaKaiDHWtKtPXBlI0G0DKnc3Nwel1WSWVFYlOqSbiBtu0zfz+c+ywwsO2Ol5Xxc L X-Google-Smtp-Source: AGHT+IFd3YQWAm7qoo5X1tJlATEebI+ePrJbrqQHhZWfvEg/6/kEVDSXa+AcdX+MxZjW1Ba8X1OPyw== X-Received: by 2002:a17:906:7d6:b0:a43:88c0:7729 with SMTP id m22-20020a17090607d600b00a4388c07729mr1193092ejc.56.1709295187311; Fri, 01 Mar 2024 04:13:07 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jan Beulich , Wei Liu Subject: [PATCH v2] tests/resource: Fix HVM guest in !SHADOW builds Date: Fri, 1 Mar 2024 12:13:04 +0000 Message-Id: <20240301121304.2661077-1-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Right now, test-resource always creates HVM Shadow guests. But if Xen has SHADOW compiled out, running the test yields: $./test-resource XENMEM_acquire_resource tests Test x86 PV Created d1 Test grant table Test x86 PVH Skip: 95 - Operation not supported and doesn't really test HVM guests, but doesn't fail either. There's nothing paging-mode-specific about this test, so default to HAP if possible and provide a more specific message if neither HAP or Shadow are available. As we've got physinfo to hand, also provide more specific message about the absence of PV or HVM support. Signed-off-by: Andrew Cooper Acked-by: Roger Pau Monné --- CC: Jan Beulich CC: Roger Pau Monné CC: Wei Liu v2: * Also check XEN_SYSCTL_PHYSCAP_{hvm,pv} --- tools/tests/resource/test-resource.c | 39 ++++++++++++++++++++++++++++ 1 file changed, 39 insertions(+) diff --git a/tools/tests/resource/test-resource.c b/tools/tests/resource/test-resource.c index 7ae88ea34807..1b10be16a6b4 100644 --- a/tools/tests/resource/test-resource.c +++ b/tools/tests/resource/test-resource.c @@ -20,6 +20,8 @@ static xc_interface *xch; static xenforeignmemory_handle *fh; static xengnttab_handle *gh; +static xc_physinfo_t physinfo; + static void test_gnttab(uint32_t domid, unsigned int nr_frames, unsigned long gfn) { @@ -172,6 +174,37 @@ static void test_domain_configurations(void) printf("Test %s\n", t->name); +#if defined(__x86_64__) || defined(__i386__) + if ( t->create.flags & XEN_DOMCTL_CDF_hvm ) + { + if ( !(physinfo.capabilities & XEN_SYSCTL_PHYSCAP_hvm) ) + { + printf(" Skip: HVM not available\n"); + continue; + } + + /* + * On x86, use HAP guests if possible, but skip if neither HAP nor + * SHADOW is available. + */ + if ( physinfo.capabilities & XEN_SYSCTL_PHYSCAP_hap ) + t->create.flags |= XEN_DOMCTL_CDF_hap; + else if ( !(physinfo.capabilities & XEN_SYSCTL_PHYSCAP_shadow) ) + { + printf(" Skip: Neither HAP or SHADOW available\n"); + continue; + } + } + else + { + if ( !(physinfo.capabilities & XEN_SYSCTL_PHYSCAP_pv) ) + { + printf(" Skip: PV not available\n"); + continue; + } + } +#endif + rc = xc_domain_create(xch, &domid, &t->create); if ( rc ) { @@ -214,6 +247,8 @@ static void test_domain_configurations(void) int main(int argc, char **argv) { + int rc; + printf("XENMEM_acquire_resource tests\n"); xch = xc_interface_open(NULL, NULL, 0); @@ -227,6 +262,10 @@ int main(int argc, char **argv) if ( !gh ) err(1, "xengnttab_open"); + rc = xc_physinfo(xch, &physinfo); + if ( rc ) + err(1, "Failed to obtain physinfo"); + test_domain_configurations(); return !!nr_failures; -- 2.30.2 From xen-devel-bounces@lists.xenproject.org Fri Mar 01 12:30:34 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2024 12:30:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687643.1071351 (Exim 4.92) (envelope-from ) id 1rg21w-0000p8-OU; Fri, 01 Mar 2024 12:30:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687643.1071351; Fri, 01 Mar 2024 12:30:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg21w-0000p1-LZ; Fri, 01 Mar 2024 12:30:24 +0000 Received: by outflank-mailman (input) for mailman id 687643; Fri, 01 Mar 2024 12:30:22 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg21u-0000nY-Qb for xen-devel@lists.xenproject.org; Fri, 01 Mar 2024 12:30:22 +0000 Received: from mail-oa1-x35.google.com (mail-oa1-x35.google.com [2001:4860:4864:20::35]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 78324372-d7c7-11ee-afd8-a90da7624cb6; Fri, 01 Mar 2024 13:30:21 +0100 (CET) Received: by mail-oa1-x35.google.com with SMTP id 586e51a60fabf-21fb368b468so1098001fac.0 for ; Fri, 01 Mar 2024 04:30:21 -0800 (PST) Received: from localhost ([213.195.118.74]) by smtp.gmail.com with ESMTPSA id u24-20020ae9c018000000b00787f695c487sm1585815qkk.98.2024.03.01.04.30.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 Mar 2024 04:30:20 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 78324372-d7c7-11ee-afd8-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709296220; x=1709901020; darn=lists.xenproject.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=tZVfWNlAzvtMlMR2wkPKMnV6YlIBnJz6r+E+seKQxfY=; b=rZvHDExp2YEP9syCPEbt0Zaq/7iFTgqvrhcXfUoSwtw/MLov7wF2dd2qgoWkFHvbvl IYZ2JQ16y/pxwXEPg17meKhuR8Z8Wui1Nrpcxy53paDCTt1CNqGSlM1m72GlaG1MfvXR 38B36CH4tDg5XqJFIJsehmtjyrTqjSJsZod30= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709296220; x=1709901020; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=tZVfWNlAzvtMlMR2wkPKMnV6YlIBnJz6r+E+seKQxfY=; b=p964xsmLQcYRsLnbS6RyvcVDGxQAHzhjhKE6G1yAAHEvt2lAeVl6S2UVCkJQJt+c2i TGfdgWE5ZuEyv0vYGNhA+YYynnb58WJryCFYwGsiWRnWbYTem/llCavNziRXOVXAvwBc GhVIkPQYuzKG21I7Eq51b6ADEluHh4+J4R3jKGznAuvW7dGckpLvTlfB021xPRXxeyIw +fs5R9G1fChGSlzcgdj4a9lmeDspOu7YWDsU5Gm6mgUi3k+w4K9oY3rWZZBdOKFdBnwU vtS0iwaOW8xNk2/dfkyHeuRvSeWbz762ANaJbIsWLAjW/OB/rjbEa4a1dm0VS8I8vOUJ kA4w== X-Gm-Message-State: AOJu0YwzNdse9kb7LSHHebvnoHliIL9Q0ZIn/I2NDU/lmWmjRE59Md5i A/dSbVVJ9NQTsRNRM2ZwCIlbpbTd1UDsL94G82cnUxWA90/U1N/kHFX2DMj9wp4= X-Google-Smtp-Source: AGHT+IHk3GK72xn0yqiIm6Gw3CUJbIFzEMbKbcbYnEfJwTeTnOSGGJA+3p5HmyJP/1ISem5RyT5DGQ== X-Received: by 2002:a05:6870:9d05:b0:21f:412a:87a8 with SMTP id pp5-20020a0568709d0500b0021f412a87a8mr1448430oab.41.1709296220532; Fri, 01 Mar 2024 04:30:20 -0800 (PST) Date: Fri, 1 Mar 2024 13:30:18 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Andrew Cooper Cc: Xen-devel , Jan Beulich , Wei Liu Subject: Re: [PATCH] x86/cpu-policy: Fix visibility of HTT/CMP_LEGACY in max policies Message-ID: References: <20240301112829.2657865-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20240301112829.2657865-1-andrew.cooper3@citrix.com> On Fri, Mar 01, 2024 at 11:28:29AM +0000, Andrew Cooper wrote: > The block in recalculate_cpuid_policy() predates the proper split between > default and max policies, and was a "slightly max for a toolstack which knows > about it" capability. It didn't get transformed properly in Xen 4.14. > > Because Xen will accept a VM with HTT/CMP_LEGACY seen, they should be visible > in the max polices. Keep the default policy matching host settings. > > This manifested as an incorrectly-rejected migration across XenServer's Xen > 4.13 -> 4.17 upgrade, as Xapi is slowly growing the logic to check a VM > against the target max policy. > > Signed-off-by: Andrew Cooper Reviewed-by: Roger Pau Monné I have one question below. > --- > CC: Jan Beulich > CC: Roger Pau Monné > CC: Wei Liu > --- > xen/arch/x86/cpu-policy.c | 29 ++++++++++++++++++++++------- > 1 file changed, 22 insertions(+), 7 deletions(-) > > diff --git a/xen/arch/x86/cpu-policy.c b/xen/arch/x86/cpu-policy.c > index c9b32bc17849..4f558e502e01 100644 > --- a/xen/arch/x86/cpu-policy.c > +++ b/xen/arch/x86/cpu-policy.c > @@ -464,6 +464,16 @@ static void __init guest_common_max_feature_adjustments(uint32_t *fs) > raw_cpu_policy.feat.clwb ) > __set_bit(X86_FEATURE_CLWB, fs); > } > + > + /* > + * Topology information inside the guest is entirely at the toolstack's > + * disgression, and bears no relationship to the host we're running on. > + * > + * HTT identifies p->basic.lppp as valid > + * CMP_LEGACY identifies p->extd.nc as valid > + */ > + __set_bit(X86_FEATURE_HTT, fs); > + __set_bit(X86_FEATURE_CMP_LEGACY, fs); > } > > static void __init guest_common_default_feature_adjustments(uint32_t *fs) > @@ -514,6 +524,18 @@ static void __init guest_common_default_feature_adjustments(uint32_t *fs) > __clear_bit(X86_FEATURE_CLWB, fs); > } > > + /* > + * Topology information is at the toolstack's discretion so these are > + * unconditionally set in max, but pick a default which matches the host. > + */ > + __clear_bit(X86_FEATURE_HTT, fs); > + if ( cpu_has_htt ) > + __set_bit(X86_FEATURE_HTT, fs); > + > + __clear_bit(X86_FEATURE_CMP_LEGACY, fs); > + if ( cpu_has_cmp_legacy ) > + __set_bit(X86_FEATURE_CMP_LEGACY, fs); Not that I oppose to it, but does it make sense to expose this options to PV guests by default? Those guests don't really have an APIC ID, and I think we don't expect any of the topology information to be usable by them in the first place. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Fri Mar 01 12:43:00 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2024 12:43:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687648.1071361 (Exim 4.92) (envelope-from ) id 1rg2E2-0002pt-Qc; Fri, 01 Mar 2024 12:42:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687648.1071361; Fri, 01 Mar 2024 12:42:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg2E2-0002pm-Ma; Fri, 01 Mar 2024 12:42:54 +0000 Received: by outflank-mailman (input) for mailman id 687648; Fri, 01 Mar 2024 12:42:53 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg2E1-0002pg-G4 for xen-devel@lists.xenproject.org; Fri, 01 Mar 2024 12:42:53 +0000 Received: from mail-oa1-x33.google.com (mail-oa1-x33.google.com [2001:4860:4864:20::33]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 37025410-d7c9-11ee-a1ee-f123f15fe8a2; Fri, 01 Mar 2024 13:42:51 +0100 (CET) Received: by mail-oa1-x33.google.com with SMTP id 586e51a60fabf-21edca2a89dso1007918fac.3 for ; Fri, 01 Mar 2024 04:42:51 -0800 (PST) Received: from localhost ([213.195.118.74]) by smtp.gmail.com with ESMTPSA id w1-20020a05620a0e8100b007853f736893sm1608490qkm.5.2024.03.01.04.42.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 Mar 2024 04:42:48 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 37025410-d7c9-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709296969; x=1709901769; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=/yrDSPpcrVwedi2F9gehZixolrotrnrXDhAVNv+q5K8=; b=CiCl0A4YeR8sEJ9WxWF5tmtjG/2JKVjvFIqPwrJvspQKDNn4hY4RtifFS6uyTwDhUV eftjN4CSW6bUK2PHxKYFdCiBVcRooir+cilPrzUAtDecJmLESM7d32Aia+gZ3H9H2g7M ncOG6O5dUVZ2XS7F7G6tgnDs0IaeOZY8Ej6pg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709296969; x=1709901769; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=/yrDSPpcrVwedi2F9gehZixolrotrnrXDhAVNv+q5K8=; b=mvQqlLBHJTwVpZz4jd5QsepZ8c/2VjolBN/7psc/PLpahylnyvqOZ0cUZI1od+gzwJ gGWY6WsORruMS6Zqw3dNsHL0zgM2AorTBs9vAq4mkJyMWtPIK1lsxgEYpDqrM+kiCWad L8OjkM9qZeauMSGL+obXwVSf9qHXkTehPYXRxUCKPxzSxFDwWYs/jRczcuH4qkvHL6Ew kehLr4Xq+WYNxg2x8IXa0d59gpXuoQAARFiZdoREfU0jhEa/EWwZaEHZM+7W/vvAp5CZ HxZ1L7ViOMuaxOhNhp6ZZ9wToeL7x3dIWGdSS/vAWUWGUlfpDp2kQRC9ofwf52eeqXCs or9Q== X-Gm-Message-State: AOJu0YwhHSF/mLo6tGFq0Yjyf8a2kuaYjMjNrSXtB4a2h07AfGK1hM6+ H/9lPWa77dpO7ng2W73LlygzlNlVQVKjPQYcNnza7WOvEL7kktcYAP3Z2cqEjhB3a0NhEWnwCLW x X-Google-Smtp-Source: AGHT+IFdz+nfx5bajN0waBAIBb91rv9mlMdNQKfvkPLeyZAeD3briXViiPraIye9heLYeSUlV7o9lQ== X-Received: by 2002:a05:6870:ab0b:b0:21f:cb22:86b1 with SMTP id gu11-20020a056870ab0b00b0021fcb2286b1mr1504835oab.11.1709296969252; Fri, 01 Mar 2024 04:42:49 -0800 (PST) From: Roger Pau Monne To: xen-devel@lists.xenproject.org Cc: Roger Pau Monne , Jan Beulich , Andrew Cooper , Wei Liu Subject: [PATCH] x86/mm: re-implement get_page_light() using an atomic increment Date: Fri, 1 Mar 2024 13:42:27 +0100 Message-ID: <20240301124228.56123-1-roger.pau@citrix.com> X-Mailer: git-send-email 2.44.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The current usage of a cmpxchg loop to increase the value of page count is not optimal on amd64, as there's already an instruction to do an atomic add to a 64bit integer. Switch the code in get_page_light() to use an atomic increment, as that avoids a loop construct. This slightly changes the order of the checks, as current code will crash before modifying the page count_info if the conditions are not correct, while with the proposed change the crash will happen immediately after having carried the counter increase. Since we are crashing anyway, I don't believe the re-ordering to have any meaningful impact. Note that the page must already have a non-zero reference count which prevents the flags from changing, and the previous usage of the cmpxchg loop didn't guarantee that the rest of the fields in count_info didn't change while updating the reference count. Signed-off-by: Roger Pau Monné --- xen/arch/x86/mm.c | 12 +++--------- 1 file changed, 3 insertions(+), 9 deletions(-) diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index 4d6d7bfe4f89..2aff6d4b5338 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -2580,16 +2580,10 @@ bool get_page(struct page_info *page, const struct domain *domain) */ static void get_page_light(struct page_info *page) { - unsigned long x, nx, y = page->count_info; + unsigned long old_pgc = arch_fetch_and_add(&page->count_info, 1); - do { - x = y; - nx = x + 1; - BUG_ON(!(x & PGC_count_mask)); /* Not allocated? */ - BUG_ON(!(nx & PGC_count_mask)); /* Overflow? */ - y = cmpxchg(&page->count_info, x, nx); - } - while ( unlikely(y != x) ); + BUG_ON(!(old_pgc & PGC_count_mask)); /* Not allocated? */ + BUG_ON(!((old_pgc + 1) & PGC_count_mask)); /* Overflow? */ } static int validate_page(struct page_info *page, unsigned long type, -- 2.44.0 From xen-devel-bounces@lists.xenproject.org Fri Mar 01 12:45:53 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2024 12:45:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687651.1071371 (Exim 4.92) (envelope-from ) id 1rg2Gr-0003SW-Bd; Fri, 01 Mar 2024 12:45:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687651.1071371; Fri, 01 Mar 2024 12:45:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg2Gr-0003SP-8t; Fri, 01 Mar 2024 12:45:49 +0000 Received: by outflank-mailman (input) for mailman id 687651; Fri, 01 Mar 2024 12:45:47 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg2Gp-0003SD-TG; Fri, 01 Mar 2024 12:45:47 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg2Gp-0003go-R4; Fri, 01 Mar 2024 12:45:47 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg2Gp-0007hA-FJ; Fri, 01 Mar 2024 12:45:47 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rg2Gp-00058i-Ev; Fri, 01 Mar 2024 12:45:47 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=21G6XMKxV7O+Yoy0dKZfcKmS0ynt7RsTtYbAmZELmLg=; b=dFZlbl6W+7wxupr+nqfuVuODhB yyjouppI3O0EHiIBm9bH2ZEFKOROw8hh86/FvOYT/EOeLTAy1P14XNpMkaZGy0uo+rhXSDaL10+7e +5FcOXIh2Jp27GWwWfurReXRLITVqymS8b3t3bYyq6QqL1kWMdHrpHsaYNVKl5q3cIl4=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 184830: tolerable all pass - PUSHED X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=efad36f1ba18946acecc030166b1a6bebeb88ea2 X-Osstest-Versions-That: xen=4cac80e22600d5a38d77c65e9a6507c752efc155 From: osstest service owner Date: Fri, 01 Mar 2024 12:45:47 +0000 flight 184830 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/184830/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-check fail never pass version targeted for testing: xen efad36f1ba18946acecc030166b1a6bebeb88ea2 baseline version: xen 4cac80e22600d5a38d77c65e9a6507c752efc155 Last test of basis 184826 2024-03-01 00:00:25 Z 0 days Testing same since 184830 2024-03-01 10:02:09 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Michal Orzel 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-amd64 pass 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 4cac80e226..efad36f1ba efad36f1ba18946acecc030166b1a6bebeb88ea2 -> smoke From xen-devel-bounces@lists.xenproject.org Fri Mar 01 13:29:08 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2024 13:29:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687678.1071380 (Exim 4.92) (envelope-from ) id 1rg2wU-0001LP-If; Fri, 01 Mar 2024 13:28:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687678.1071380; Fri, 01 Mar 2024 13:28:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg2wU-0001LI-Fw; Fri, 01 Mar 2024 13:28:50 +0000 Received: by outflank-mailman (input) for mailman id 687678; Fri, 01 Mar 2024 13:28:49 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg2wT-0001L9-Jy for xen-devel@lists.xenproject.org; Fri, 01 Mar 2024 13:28:49 +0000 Received: from mail-oo1-xc2f.google.com (mail-oo1-xc2f.google.com [2607:f8b0:4864:20::c2f]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id a1c407c4-d7cf-11ee-a1ee-f123f15fe8a2; Fri, 01 Mar 2024 14:28:47 +0100 (CET) Received: by mail-oo1-xc2f.google.com with SMTP id 006d021491bc7-5a034c12090so921844eaf.2 for ; Fri, 01 Mar 2024 05:28:47 -0800 (PST) Received: from localhost ([213.195.118.74]) by smtp.gmail.com with ESMTPSA id mv1-20020a056214338100b0068f75622543sm1877943qvb.1.2024.03.01.05.28.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 Mar 2024 05:28:45 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a1c407c4-d7cf-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709299726; x=1709904526; darn=lists.xenproject.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=A03dm6nNY7eguplmpwqBpNN2ulIpbycVGOPdL5ZF9uU=; b=Z+I6nQBN9AqSmsTvNbsuFeEHdXxc3bYlJWSkFm0Rye07taIImOjK8pWSzU9RUHDWuU Y9YZm3pvsl8fcjW1n+e2p4eyxwkxQKdpfclrj5Nlmd1xlrDSZQKkzStyOnBmMbk1v6W9 qg5Wqy5Hu+5ZPn4xBni8b+6MG0u+ZU9o1Q1Oo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709299726; x=1709904526; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=A03dm6nNY7eguplmpwqBpNN2ulIpbycVGOPdL5ZF9uU=; b=r9mROtrgrVJdMzW/JTT6b4XfBy/yTIXOTLKBCfCk8G3h+OokZj7oVKHp7+DjmFGmqZ y4vCwEWhfkO/E0zozPlrGItKxrBa6SbGvoKmtce5VCLZIp66kP75p0GWLuz63rEVMrS6 SVUbd0AH+kq4wKzC1lYzMTfvA/P9fD2+FgcTYH6zlHuMZPtQ2qBqhUjNn6UR9nh4zyqr RHBm5Kez9d1UnlYMdstSxZ2nqAFxlf6s4IKmpM1/hWjJlI3+xfdCZzFls3U0wV579ycf 0cpUi0Aca0dkPz3j+N2przSVqvBCcUHDN8CvLgs12Xo/EW7yBkdsKWXptQ1fqxWe6sEv ItgQ== X-Gm-Message-State: AOJu0YzYatCI499Tor4Pl6Br3JzlCnYC81HAV1AjqnJqbRtdSuUeka82 wFgJhuRfIpS6Blzdd0PKjKLbrfsTdOgg6m2qWhTiadL7HaUbWwUP23I9M/tHNpY= X-Google-Smtp-Source: AGHT+IFzbaVo0LGe3+msSomjCXjzIecARtGfCHKana3I4648ugUQ8gyUELuu8onfODMiF2ID38NrUQ== X-Received: by 2002:a05:6358:c88:b0:178:99cc:e52e with SMTP id o8-20020a0563580c8800b0017899cce52emr1583286rwj.20.1709299725767; Fri, 01 Mar 2024 05:28:45 -0800 (PST) Date: Fri, 1 Mar 2024 14:28:43 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Andrew Cooper Cc: Xen-devel , Jan Beulich , Wei Liu Subject: Re: [PATCH] x86/cpu-policy: Allow for levelling of VERW side effects Message-ID: References: <20240229181354.2560819-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20240229181354.2560819-1-andrew.cooper3@citrix.com> On Thu, Feb 29, 2024 at 06:13:54PM +0000, Andrew Cooper wrote: > MD_CLEAR and FB_CLEAR need OR-ing across a migrate pool. Allow this, by > having them unconditinally set in max, with the host values reflected in > default. Annotate the bits as having special properies. > > Signed-off-by: Andrew Cooper > --- > CC: Jan Beulich > CC: Roger Pau Monné > CC: Wei Liu > --- > xen/arch/x86/cpu-policy.c | 24 +++++++++++++++++++++ > xen/include/public/arch-x86/cpufeatureset.h | 4 ++-- > 2 files changed, 26 insertions(+), 2 deletions(-) > > diff --git a/xen/arch/x86/cpu-policy.c b/xen/arch/x86/cpu-policy.c > index f3ed2d3a3227..41123e6cf778 100644 > --- a/xen/arch/x86/cpu-policy.c > +++ b/xen/arch/x86/cpu-policy.c > @@ -442,6 +442,16 @@ static void __init guest_common_max_feature_adjustments(uint32_t *fs) > __set_bit(X86_FEATURE_RSBA, fs); > __set_bit(X86_FEATURE_RRSBA, fs); > > + /* > + * These bits indicate that the VERW instruction may have gained > + * scrubbing side effects. With pooling, they mean "you might migrate > + * somewhere where scrubbing is necessary", and may need exposing on > + * unaffected hardware. This is fine, because the VERW instruction > + * has been around since the 286. > + */ > + __set_bit(X86_FEATURE_MD_CLEAR, fs); > + __set_bit(X86_FEATURE_FB_CLEAR, fs); > + > /* > * The Gather Data Sampling microcode mitigation (August 2023) has an > * adverse performance impact on the CLWB instruction on SKX/CLX/CPX. > @@ -476,6 +486,20 @@ static void __init guest_common_default_feature_adjustments(uint32_t *fs) > cpu_has_rdrand && !is_forced_cpu_cap(X86_FEATURE_RDRAND) ) > __clear_bit(X86_FEATURE_RDRAND, fs); > > + /* > + * These bits indicate that the VERW instruction may have gained > + * scrubbing side effects. The max policy has them set for migration > + * reasons, so reset the default policy back to the host values in > + * case we're unaffected. > + */ > + fs[FEATURESET_7d0] &= ~cpufeat_mask(X86_FEATURE_MD_CLEAR); > + fs[FEATURESET_m10Al] &= ~cpufeat_mask(X86_FEATURE_FB_CLEAR); > + > + fs[FEATURESET_7d0] |= (boot_cpu_data.x86_capability[FEATURESET_7d0] & > + cpufeat_mask(X86_FEATURE_MD_CLEAR)); > + fs[FEATURESET_m10Al] |= (boot_cpu_data.x86_capability[FEATURESET_m10Al] & > + cpufeat_mask(X86_FEATURE_FB_CLEAR)); This seems quite convoluted, why not use: __clear_bit(X86_FEATURE_MD_CLEAR, fs); if ( boot_cpu_has(X86_FEATURE_MD_CLEAR) ) __set_bit(X86_FEATURE_MD_CLEAR, fs); And the same for FB_CLEAR. I think that's quite easier to read. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Fri Mar 01 13:51:30 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2024 13:51:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687686.1071391 (Exim 4.92) (envelope-from ) id 1rg3IK-0005cX-4R; Fri, 01 Mar 2024 13:51:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687686.1071391; Fri, 01 Mar 2024 13:51:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg3IK-0005cQ-12; Fri, 01 Mar 2024 13:51:24 +0000 Received: by outflank-mailman (input) for mailman id 687686; Fri, 01 Mar 2024 13:51:22 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg3II-0005cG-Cw; Fri, 01 Mar 2024 13:51:22 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg3II-0005Gj-9B; Fri, 01 Mar 2024 13:51:22 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg3IH-0000uA-MA; Fri, 01 Mar 2024 13:51:21 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rg3IH-0001CZ-Ll; Fri, 01 Mar 2024 13:51:21 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=5HluQz9S0DVbJiiCbxNspBUdCwXpYsUgwe216LJLmHQ=; b=rzOhfGb7DVcw8JDvCVpeXuRtUM jxqUYUTMwpCft3gnitRbJiOvot4WETOx3b27X8usfROsLJg8k6ghVp+wVatz+TdOfO/df5pxo6yRO hp7LABrl1gIN4bxadkbfp3eXxV8V4jhOXjkCPD5iLRU/RYvgUYDP+N8RvhpWqOywLxSE=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable test] 184828: tolerable FAIL - PUSHED X-Osstest-Failures: xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=4cac80e22600d5a38d77c65e9a6507c752efc155 X-Osstest-Versions-That: xen=c20850540ad6a32f4fc17bde9b01c92b0df18bf0 From: osstest service owner Date: Fri, 01 Mar 2024 13:51:21 +0000 flight 184828 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/184828/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 16 saverestore-support-check fail like 184820 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop fail like 184820 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 184820 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop fail like 184820 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 184820 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 184820 test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail like 184820 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 184820 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop fail like 184820 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184820 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 184820 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop fail like 184820 test-amd64-i386-xl-pvshim 14 guest-start fail never pass test-amd64-i386-libvirt 15 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-check fail never pass test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-arm64-arm64-xl 15 migrate-support-check fail never pass test-arm64-arm64-xl 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 15 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 15 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-check fail never pass test-armhf-armhf-libvirt 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-check fail never pass test-amd64-i386-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-check fail never pass test-arm64-arm64-xl-vhd 14 migrate-support-check fail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-check fail never pass version targeted for testing: xen 4cac80e22600d5a38d77c65e9a6507c752efc155 baseline version: xen c20850540ad6a32f4fc17bde9b01c92b0df18bf0 Last test of basis 184820 2024-02-29 13:28:17 Z 1 days Testing same since 184828 2024-03-01 04:24:17 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Anthony PERARD Federico Serafini Jan Beulich Juergen Gross Julien Grall Oleksii Kurochko Roger Pau Monné Samuel Thibault Stefano Stabellini Stefano Stabellini jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-dom0pvh-xl-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-qemuu-freebsd11-amd64 pass test-amd64-amd64-qemuu-freebsd12-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-examine-bios pass test-amd64-i386-examine-bios pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-dom0pvh-xl-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-armhf-armhf-libvirt-qcow2 pass test-amd64-amd64-xl-qcow2 pass test-arm64-arm64-libvirt-raw pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-libvirt-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-examine-uefi pass test-amd64-i386-examine-uefi pass test-amd64-amd64-libvirt-vhd pass test-arm64-arm64-xl-vhd pass test-armhf-armhf-xl-vhd pass test-amd64-i386-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these 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 c20850540a..4cac80e226 4cac80e22600d5a38d77c65e9a6507c752efc155 -> master From xen-devel-bounces@lists.xenproject.org Fri Mar 01 14:05:52 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2024 14:05:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687707.1071444 (Exim 4.92) (envelope-from ) id 1rg3WF-0007uw-Th; Fri, 01 Mar 2024 14:05:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687707.1071444; Fri, 01 Mar 2024 14:05:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg3WF-0007up-R1; Fri, 01 Mar 2024 14:05:47 +0000 Received: by outflank-mailman (input) for mailman id 687707; Fri, 01 Mar 2024 14:05:46 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg3WE-0007uj-76 for xen-devel@lists.xenproject.org; Fri, 01 Mar 2024 14:05:46 +0000 Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [2a00:1450:4864:20::430]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id cb4ccb8a-d7d4-11ee-a1ee-f123f15fe8a2; Fri, 01 Mar 2024 15:05:44 +0100 (CET) Received: by mail-wr1-x430.google.com with SMTP id ffacd0b85a97d-33d6f26ff33so1283189f8f.0 for ; Fri, 01 Mar 2024 06:05:44 -0800 (PST) Received: from draig.lan ([85.9.250.243]) by smtp.gmail.com with ESMTPSA id bh3-20020a05600005c300b0033df1dc39f0sm4918552wrb.4.2024.03.01.06.05.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 Mar 2024 06:05:43 -0800 (PST) Received: from draig (localhost [IPv6:::1]) by draig.lan (Postfix) with ESMTP id B4D2F5F796; Fri, 1 Mar 2024 14:05:42 +0000 (GMT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: cb4ccb8a-d7d4-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1709301943; x=1709906743; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:message-id:date:user-agent :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=EvRcj/lRDxwSKa/nT/9N7/Vu7IjmpxIlQF47Bc5vUnk=; b=q8kEQ2D4EaULcDu4kK2dy8Gw/uUnBSwPzOa1qgc4XeulMTddrZHG4aerJYBnqZGfQ7 W+dHtb8EiqWBcZEL6Wcmz6iBFoJi9k+RoF6XDeDHvOcu95SCOpmsQ84F6NNqHgCFfah0 tcXsz8mM6krAueh+2w17qwPyPyjrLEgMOGgqpgelbHeV6jh/j6ISIpw6q94BCDzuJkmv M8Och6ulrE3b6Yi+GO+tDl0utMUwPYfGNS7SMHqVOqEv9RAiTzH9PAQ1v1Mg2WrccitU re+qBXPxm5TSP6RvF/3UI933ywQuletBUK2DXRT4mqlLyZG9B6wa8Ol4gSsnrvVj9wrx aHkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709301943; x=1709906743; h=content-transfer-encoding:mime-version:message-id:date:user-agent :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=EvRcj/lRDxwSKa/nT/9N7/Vu7IjmpxIlQF47Bc5vUnk=; b=LLimDEhRGDB22ghkVfYEtkFmHimCfBSNl8k3IFrFbvRj2yMLeRW85UDs+edxTP47+h 98OFKJTjjifgph9XZ0iX1qi/slFhxHunQLO2M6gu2zdEhYB0zk/mazN1ZxWh+24r9OBF T2c9an/0lzSJ3RjYET0XpC2kAN44ByH0v2Y0JOV06eelnQD5l0ChjWIQAZKrtQc8zAtb x3dqrbZxMGgd/7+5xldnihEfMI3+JWLg+wSNctH8e+sMMsnarnl7+Nt6WaAu1xJZ3Z0z s2HALOGdt8m3loJJ/TUDMIr+S0vUr6frAtRZVKW0TQO/1WFVp5vMvWPDXc73RNV7pqFj sCYw== X-Forwarded-Encrypted: i=1; AJvYcCUdyizfAUYdshmxhjnd6f4V7I0kWLblwfuLGa2p+oBYxoD0KSMcSCfwRZus9RunTVhbX9HJKRuQoJZ5vaDWkMhdKQu7wPDPqzEvo2OjKLI= X-Gm-Message-State: AOJu0Yyu5DNHcq78sihHPJ8a6qAW1kplqkK7NO3tXyk1lyZs+WCtUv4n UVhLFCJkzGFJcZ5+fWvDpIMNz5Ieq0mBC2yPMyBEceGvEksRGxPfPUK7InyqRds= X-Google-Smtp-Source: AGHT+IH0vRBDHW2rDFP3hgccyW/FGrjbFZjzIJZDaHlWCZN9wENhqaERMhpoLlTDZp91yXJWbVVJEg== X-Received: by 2002:adf:f28d:0:b0:33d:38cf:aa73 with SMTP id k13-20020adff28d000000b0033d38cfaa73mr1336560wro.47.1709301943499; Fri, 01 Mar 2024 06:05:43 -0800 (PST) From: =?utf-8?Q?Alex_Benn=C3=A9e?= To: Vikram Garhwal Cc: , , , Anthony Perard , Paul Durrant , Paolo Bonzini , Richard Henderson , Eduardo Habkost , "Michael S. Tsirkin" , Marcel Apfelbaum , "open list:X86 Xen CPUs" Subject: Re: [QEMU][PATCH v3 2/7] xen: add pseudo RAM region for grant mappings In-Reply-To: <20240227223501.28475-3-vikram.garhwal@amd.com> (Vikram Garhwal's message of "Tue, 27 Feb 2024 14:34:56 -0800") References: <20240227223501.28475-1-vikram.garhwal@amd.com> <20240227223501.28475-3-vikram.garhwal@amd.com> User-Agent: mu4e 1.12.0; emacs 29.1 Date: Fri, 01 Mar 2024 14:05:42 +0000 Message-ID: <875xy659op.fsf@draig.linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Vikram Garhwal writes: > From: Juergen Gross > > Add a memory region which can be used to automatically map granted > memory. It is starting at 0x8000000000000000ULL in order to be able to > distinguish it from normal RAM. Is the Xen memory map for HVM guests documented anywhere? I couldn't find anything googling or on the Xen wiki. I'm guessing this is going to be shared across all 64 bit HVM arches in Xen? Anyway: Reviewed-by: Alex Benn=C3=A9e --=20 Alex Benn=C3=A9e Virtualisation Tech Lead @ Linaro From xen-devel-bounces@lists.xenproject.org Fri Mar 01 14:37:47 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2024 14:37:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687714.1071455 (Exim 4.92) (envelope-from ) id 1rg40x-0003Yt-9y; Fri, 01 Mar 2024 14:37:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687714.1071455; Fri, 01 Mar 2024 14:37:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg40x-0003Ym-77; Fri, 01 Mar 2024 14:37:31 +0000 Received: by outflank-mailman (input) for mailman id 687714; Fri, 01 Mar 2024 14:37:30 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg40w-0003Ye-9W for xen-devel@lists.xenproject.org; Fri, 01 Mar 2024 14:37:30 +0000 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 39c13791-d7d9-11ee-a1ee-f123f15fe8a2; Fri, 01 Mar 2024 15:37:27 +0100 (CET) Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 90DD3205B2; Fri, 1 Mar 2024 14:37:26 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 49F0C13A59; Fri, 1 Mar 2024 14:37:26 +0000 (UTC) Received: from dovecot-director2.suse.de ([10.150.64.162]) by imap1.dmz-prg2.suse.org with ESMTPSA id tbt0ECbo4WWMbwAAD6G6ig (envelope-from ); Fri, 01 Mar 2024 14:37:26 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 39c13791-d7d9-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1709303846; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=Spo8l3HF4hamQliM8b6kQHYtyWorvjvrW4sZAh5t/0E=; b=BaeSEeCvrqGMnxpfeXCFAjmF3i+Ki6L47a3bcafg5TEbWcIgPHXEKCWIpTRn1u1WVGiE/a bZ13VvBIGpohHWlnEhGI4adbV0ux227mb1YTNV1yNagl5RNr2T2KnYFPfYrGrkfGX/g0Mv w9A8dhEfNBW/XRTg3Tjc5ZfDucDbVhs= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1709303846; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=Spo8l3HF4hamQliM8b6kQHYtyWorvjvrW4sZAh5t/0E=; b=BaeSEeCvrqGMnxpfeXCFAjmF3i+Ki6L47a3bcafg5TEbWcIgPHXEKCWIpTRn1u1WVGiE/a bZ13VvBIGpohHWlnEhGI4adbV0ux227mb1YTNV1yNagl5RNr2T2KnYFPfYrGrkfGX/g0Mv w9A8dhEfNBW/XRTg3Tjc5ZfDucDbVhs= Message-ID: Date: Fri, 1 Mar 2024 15:37:25 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 10/12] xen/spinlock: split recursive spinlocks from normal ones Content-Language: en-US To: Jan Beulich Cc: Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu , xen-devel@lists.xenproject.org References: <20231212094725.22184-1-jgross@suse.com> <20231212094725.22184-11-jgross@suse.com> From: Juergen Gross Autocrypt: addr=jgross@suse.com; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw== In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------rj51OeEkCJ64OCdzfk6zWKmT" X-Spam-Level: Authentication-Results: smtp-out2.suse.de; dkim=pass header.d=suse.com header.s=susede1 header.b=BaeSEeCv X-Rspamd-Server: rspamd2.dmz-prg2.suse.org X-Spamd-Result: default: False [-5.26 / 50.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; XM_UA_NO_VERSION(0.01)[]; TO_DN_SOME(0.00)[]; HAS_ATTACHMENT(0.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[suse.com:+]; MIME_BASE64_TEXT(0.10)[]; RCPT_COUNT_SEVEN(0.00)[7]; MX_GOOD(-0.01)[]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_SHORT(-0.20)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~]; BAYES_HAM(-2.86)[99.39%]; MID_RHS_MATCH_FROM(0.00)[]; MIME_UNKNOWN(0.10)[application/pgp-keys]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[suse.com:s=susede1]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:dkim]; FUZZY_BLOCKED(0.00)[rspamd.com]; RCVD_TLS_ALL(0.00)[] X-Spam-Score: -5.26 X-Rspamd-Queue-Id: 90DD3205B2 X-Spam-Flag: NO This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------rj51OeEkCJ64OCdzfk6zWKmT Content-Type: multipart/mixed; boundary="------------7pPn5tP1pNo3epmAujYKOLwK"; protected-headers="v1" From: Juergen Gross To: Jan Beulich Cc: Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu , xen-devel@lists.xenproject.org Message-ID: Subject: Re: [PATCH v4 10/12] xen/spinlock: split recursive spinlocks from normal ones References: <20231212094725.22184-1-jgross@suse.com> <20231212094725.22184-11-jgross@suse.com> In-Reply-To: Autocrypt-Gossip: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs= --------------7pPn5tP1pNo3epmAujYKOLwK Content-Type: multipart/mixed; boundary="------------uc0FIiZi8df3GgijfMJupWKw" --------------uc0FIiZi8df3GgijfMJupWKw Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMjkuMDIuMjQgMTY6MzIsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAxMi4xMi4yMDIz IDEwOjQ3LCBKdWVyZ2VuIEdyb3NzIHdyb3RlOg0KPj4gKyNkZWZpbmUgbnJzcGluX2xvY2tf aXJxc2F2ZShsLCBmKSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcDQo+PiArICAg ICh7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFwNCj4+ICsgICAgICAgIEJVSUxEX0JVR19PTihzaXplb2YoZikgIT0gc2l6ZW9m KHVuc2lnbmVkIGxvbmcpKTsgICAgICAgXA0KPj4gKyAgICAgICAgKChmKSA9IF9fbnJzcGlu X2xvY2tfaXJxc2F2ZShsKSk7ICAgICAgICAgICAgICAgICAgICAgICBcDQo+IA0KPiBJIGRv bid0IHRoaW5rIHRoZSBvdXRlciBwYWlyIG9mIHBhcmVudGhlc2VzIGlzIG5lZWRlZCBoZXJl Lg0KDQpUdXJucyBvdXQgaXQgaXMgbmVlZGVkLiBPdGhlcndpc2Ugc29tZXRoaW5nIGxpa2U6 DQoNCg0KaWYgKCBhICkNCiAgICAgbnJzcGluX2xvY2tfaXJxc2F2ZShsLCBmKTsNCmVsc2UN CiAgICAgLi4uDQoNCndpbGwgZmFpbCB3aXRoICJlbHNlIHdpdGhvdXQgYSBwcmV2aW91cyBp ZiIuDQoNCg0KSnVlcmdlbg0KDQo= --------------uc0FIiZi8df3GgijfMJupWKw Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2 kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i 1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u +6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4 RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7 8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK 7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/ Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK /1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1 c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4 k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu 5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6 AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr 0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD 534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422 bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay 7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib 4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX kt+z4drzFUyEjLM1vVvIMjkUoJs=3D =3DeeAB -----END PGP PUBLIC KEY BLOCK----- --------------uc0FIiZi8df3GgijfMJupWKw-- --------------7pPn5tP1pNo3epmAujYKOLwK-- --------------rj51OeEkCJ64OCdzfk6zWKmT Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmXh6CUFAwAAAAAACgkQsN6d1ii/Ey/z rgf/aWO1E74nO9Cl/mfnbkxCUWV3X64K80WVPozCk/kNi81L7DnldGRlnqq70jylilVLy5Zc35F2 rfxSGQ1zrkXbF+YP+BBgVRo+8cBHsTNDyzrPgpykQA2MCnnf3MbmUU8BQpHaFJ2tAr30PHGWoVZ4 WHRe2oMN4c/ozL2TPL08Gnh+0DgF/3hrs78XaPbD/+MA00Py/gWFDXGjaBulTtOtyMs5C1o9ilFN t2kLFmZS81w+GG2fKgGGU+vAONCKbYfm4fjCM38yZHMlOZ0hyOZmeYTf+gAtfLvQuSQm7IWonOHk no2+sVJ1ASGTyDuMFHh7UGeYKGy+bFJXwOm9suRxNA== =uqeG -----END PGP SIGNATURE----- --------------rj51OeEkCJ64OCdzfk6zWKmT-- From xen-devel-bounces@lists.xenproject.org Fri Mar 01 15:01:49 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2024 15:01:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687717.1071465 (Exim 4.92) (envelope-from ) id 1rg4OO-0007bq-6j; Fri, 01 Mar 2024 15:01:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687717.1071465; Fri, 01 Mar 2024 15:01:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg4OO-0007bj-2i; Fri, 01 Mar 2024 15:01:44 +0000 Received: by outflank-mailman (input) for mailman id 687717; Fri, 01 Mar 2024 15:01:43 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg4ON-0007bd-Jl for xen-devel@lists.xenproject.org; Fri, 01 Mar 2024 15:01:43 +0000 Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [2607:f8b0:4864:20::72e]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 9c073811-d7dc-11ee-a1ee-f123f15fe8a2; Fri, 01 Mar 2024 16:01:41 +0100 (CET) Received: by mail-qk1-x72e.google.com with SMTP id af79cd13be357-787bc61cb69so119779385a.1 for ; Fri, 01 Mar 2024 07:01:41 -0800 (PST) Received: from [10.80.67.149] (default-46-102-197-194.interdsl.co.uk. [46.102.197.194]) by smtp.gmail.com with ESMTPSA id g27-20020a05620a109b00b00787f7d5a727sm1706952qkk.44.2024.03.01.07.01.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 01 Mar 2024 07:01:38 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 9c073811-d7dc-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709305300; x=1709910100; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=6O/BnUHEkmpftStm/JOiF+Sc8ZH4TCkcvsv6gP4CTZo=; b=SIDqA+BiVCSxhH51h7ZwTRPrCEkqMMKS4LI3q+ILqv07I/HSC4sWd4oeDveQyx4otV ZPBy6S6UDEsdoCUJsSIHmLvMaBinTa0CDZhzCsyfAeeg/dW37YPt02N808pdxZdIeEgb mdaMINqci2o+rxRJ+iwYjOcF3VzOOQvFRqOv0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709305300; x=1709910100; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=6O/BnUHEkmpftStm/JOiF+Sc8ZH4TCkcvsv6gP4CTZo=; b=ol/jaJpP+lOSC6Owevdg60Iguh/QpSY9vochrTtQM6yXAoAeE4vf5I8Kb8nVeEh53W cXX86SsJ+MHkAF8Ixm6GSzgLNJjhUidGzrgYK3/xbsT1rodrVrfHaa7S4HIp1sQQKN1j C9UgMBp7BL+CNI75HoXUUKxpdmaj+4PpuLeKbTyTv6vi6vGw3amL3Fy7EFuQY49hMkDD SPCtaeeTMBycbDCUiCcKrUwMhoXwNklQm7JvdTlPpS0QzVUbOf+im8c5cazICDKk+vwy oQEeEHZFheomN6Kb565OzBPQJ2GoteZhp6mIs4RkRFGPDoLZG81z3m+xtzqnW52sWffk HypQ== X-Gm-Message-State: AOJu0YwawNkidBd1WKztiUgwINkbNlYKX7Yv42TVBRUJg0N7UetPtXjc RhAxt6jONJlSziVkomzXu77GO2Zc0j5GuJB0Rjq1CWdz7wntoHT5Mbl/04pt48nOz/DY14OUz+c C X-Google-Smtp-Source: AGHT+IHpn0UHD1FGk/Id8iGoHuGGciOjNXcYCDNpsEyFaK4ohapvxCcjKsJuhGE/989jydZ03G+MGw== X-Received: by 2002:a05:620a:4ad9:b0:787:80bb:c2e7 with SMTP id sq25-20020a05620a4ad900b0078780bbc2e7mr1534441qkn.51.1709305299692; Fri, 01 Mar 2024 07:01:39 -0800 (PST) Message-ID: <4fedcd61-94e1-4869-b620-27c48e8dafef@citrix.com> Date: Fri, 1 Mar 2024 15:01:36 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/cpu-policy: Allow for levelling of VERW side effects Content-Language: en-GB To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: Xen-devel , Jan Beulich , Wei Liu References: <20240229181354.2560819-1-andrew.cooper3@citrix.com> From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 01/03/2024 1:28 pm, Roger Pau Monné wrote: > On Thu, Feb 29, 2024 at 06:13:54PM +0000, Andrew Cooper wrote: >> MD_CLEAR and FB_CLEAR need OR-ing across a migrate pool. Allow this, by >> having them unconditinally set in max, with the host values reflected in >> default. Annotate the bits as having special properies. >> >> Signed-off-by: Andrew Cooper >> --- >> CC: Jan Beulich >> CC: Roger Pau Monné >> CC: Wei Liu >> --- >> xen/arch/x86/cpu-policy.c | 24 +++++++++++++++++++++ >> xen/include/public/arch-x86/cpufeatureset.h | 4 ++-- >> 2 files changed, 26 insertions(+), 2 deletions(-) >> >> diff --git a/xen/arch/x86/cpu-policy.c b/xen/arch/x86/cpu-policy.c >> index f3ed2d3a3227..41123e6cf778 100644 >> --- a/xen/arch/x86/cpu-policy.c >> +++ b/xen/arch/x86/cpu-policy.c >> @@ -442,6 +442,16 @@ static void __init guest_common_max_feature_adjustments(uint32_t *fs) >> __set_bit(X86_FEATURE_RSBA, fs); >> __set_bit(X86_FEATURE_RRSBA, fs); >> >> + /* >> + * These bits indicate that the VERW instruction may have gained >> + * scrubbing side effects. With pooling, they mean "you might migrate >> + * somewhere where scrubbing is necessary", and may need exposing on >> + * unaffected hardware. This is fine, because the VERW instruction >> + * has been around since the 286. >> + */ >> + __set_bit(X86_FEATURE_MD_CLEAR, fs); >> + __set_bit(X86_FEATURE_FB_CLEAR, fs); >> + >> /* >> * The Gather Data Sampling microcode mitigation (August 2023) has an >> * adverse performance impact on the CLWB instruction on SKX/CLX/CPX. >> @@ -476,6 +486,20 @@ static void __init guest_common_default_feature_adjustments(uint32_t *fs) >> cpu_has_rdrand && !is_forced_cpu_cap(X86_FEATURE_RDRAND) ) >> __clear_bit(X86_FEATURE_RDRAND, fs); >> >> + /* >> + * These bits indicate that the VERW instruction may have gained >> + * scrubbing side effects. The max policy has them set for migration >> + * reasons, so reset the default policy back to the host values in >> + * case we're unaffected. >> + */ >> + fs[FEATURESET_7d0] &= ~cpufeat_mask(X86_FEATURE_MD_CLEAR); >> + fs[FEATURESET_m10Al] &= ~cpufeat_mask(X86_FEATURE_FB_CLEAR); >> + >> + fs[FEATURESET_7d0] |= (boot_cpu_data.x86_capability[FEATURESET_7d0] & >> + cpufeat_mask(X86_FEATURE_MD_CLEAR)); >> + fs[FEATURESET_m10Al] |= (boot_cpu_data.x86_capability[FEATURESET_m10Al] & >> + cpufeat_mask(X86_FEATURE_FB_CLEAR)); > This seems quite convoluted, why not use: > > __clear_bit(X86_FEATURE_MD_CLEAR, fs); > if ( boot_cpu_has(X86_FEATURE_MD_CLEAR) ) > __set_bit(X86_FEATURE_MD_CLEAR, fs); > > And the same for FB_CLEAR. I think that's quite easier to read. This better? +        /* +         * These bits indicate that the VERW instruction may have gained +         * scrubbing side effects.  The max policy has them set for migration +         * reasons, so reset the default policy back to the host values in +         * case we're unaffected. +         */ +        __clear_bit(X86_FEATURE_MD_CLEAR); +        if ( cpu_has_md_clear ) +            __set_bit(X86_FEATURE_MD_CLEAR); + +        __clear_bit(X86_FEATURE_FB_CLEAR); +        if ( cpu_has_fb_clear ) +            __set_bit(X86_FEATURE_FB_CLEAR); ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Mar 01 15:04:26 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2024 15:04:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687720.1071475 (Exim 4.92) (envelope-from ) id 1rg4Qy-0008EX-Kh; Fri, 01 Mar 2024 15:04:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687720.1071475; Fri, 01 Mar 2024 15:04:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg4Qy-0008EQ-Hm; Fri, 01 Mar 2024 15:04:24 +0000 Received: by outflank-mailman (input) for mailman id 687720; Fri, 01 Mar 2024 15:04:23 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg4Qx-0008EK-OS for xen-devel@lists.xenproject.org; Fri, 01 Mar 2024 15:04:23 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id fbe8bbf0-d7dc-11ee-a1ee-f123f15fe8a2; Fri, 01 Mar 2024 16:04:21 +0100 (CET) Received: from Dell.bugseng.com (unknown [78.208.221.10]) by support.bugseng.com (Postfix) with ESMTPSA id 153D14EE0737; Fri, 1 Mar 2024 16:04:20 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fbe8bbf0-d7dc-11ee-a1ee-f123f15fe8a2 From: Federico Serafini To: xen-devel@lists.xenproject.org Cc: consulting@bugseng.com, Federico Serafini , Simone Ballarin , Doug Goldstein , Stefano Stabellini , Andrew Cooper , George Dunlap , Jan Beulich , Julien Grall , Wei Liu Subject: [XEN PATCH] automation/eclair: add deviation for MISRA C:2012 Rule 16.6 Date: Fri, 1 Mar 2024 16:04:12 +0100 Message-Id: X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Update ECLAIR configuration to take into account the deviations agreed during MISRA meetings. Signed-off-by: Federico Serafini --- automation/eclair_analysis/ECLAIR/deviations.ecl | 4 ++++ docs/misra/deviations.rst | 6 ++++++ 2 files changed, 10 insertions(+) diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl index 02eae39786..0e62a7029f 100644 --- a/automation/eclair_analysis/ECLAIR/deviations.ecl +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl @@ -378,6 +378,10 @@ explicit comment indicating the fallthrough intention is present." -config=MC3R1.R16.3,reports+={safe, "any_area(end_loc(any_exp(text(^(?s).*/\\* [fF]all ?through.? \\*/.*$,0..1))))"} -doc_end +-doc_begin="A switch statement with a single switch clause and no default label is deliberate and improves readability with respect to an equivalent if statement." +-config=MC3R1.R16.6,switch_clauses+={deliberate, "default(0)"} +-doc_end + # # Series 18. # diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst index 123c78e20a..041f8db4ee 100644 --- a/docs/misra/deviations.rst +++ b/docs/misra/deviations.rst @@ -322,6 +322,12 @@ Deviations related to MISRA C:2012 Rules: - /\* Fallthrough \*/ - /\* Fallthrough. \*/ + * - R16.6 + - A switch statement with a single switch clause and no default label is + deliberate and improves readability with respect to an equivalent if + statement. + - Tagged as `deliberate` for ECLAIR. + * - R20.7 - Code violating Rule 20.7 is safe when macro parameters are used: (1) as function arguments; -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Mar 01 15:06:37 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2024 15:06:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687722.1071484 (Exim 4.92) (envelope-from ) id 1rg4T6-0000Ma-17; Fri, 01 Mar 2024 15:06:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687722.1071484; Fri, 01 Mar 2024 15:06:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg4T5-0000MT-UQ; Fri, 01 Mar 2024 15:06:35 +0000 Received: by outflank-mailman (input) for mailman id 687722; Fri, 01 Mar 2024 15:06:34 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg4T4-0000ML-Qw for xen-devel@lists.xenproject.org; Fri, 01 Mar 2024 15:06:34 +0000 Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com [2607:f8b0:4864:20::f35]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 49e972d0-d7dd-11ee-a1ee-f123f15fe8a2; Fri, 01 Mar 2024 16:06:32 +0100 (CET) Received: by mail-qv1-xf35.google.com with SMTP id 6a1803df08f44-68f74fb38a8so8666706d6.3 for ; Fri, 01 Mar 2024 07:06:32 -0800 (PST) Received: from [10.80.67.149] (default-46-102-197-194.interdsl.co.uk. [46.102.197.194]) by smtp.gmail.com with ESMTPSA id pi15-20020a0562144a8f00b0068cdc0a0d42sm1945282qvb.25.2024.03.01.07.06.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 01 Mar 2024 07:06:29 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 49e972d0-d7dd-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709305592; x=1709910392; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=1el60fLWujeZRgWlegJoklNFhck1SGlKHHb6PqlYDgM=; b=sYKXb3PJGILPkhq/pg3Mhr+Rcp/Jbt3sF3s1jnjPNgBUjtqTpaOCH/ESw/4bPVog1K eS86WW6JLzNNBp9QpgFOzhXhB5bTXK1B2+jb+/23EuUFhmHc9zS3t9TxgQ2NLQfwZPpz GnZ6JWbNG47tM1XJUhm7H+5ILOHHTgNiC5qxs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709305592; x=1709910392; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=1el60fLWujeZRgWlegJoklNFhck1SGlKHHb6PqlYDgM=; b=Bm/L5D7lH/mUun6Yf1P7YYVTscS3fCZqobBd6BXAX1Pyr2Q1lMbPqoiVfRn528Nxms kOpG//6d+AVX2Guw9sLkDqbXiChHE4PgTUN5txPisdhsWAXQ+smJ8ulJeVUxKyVVK0cU YMFQzssEIn2BlREPRxhmsissiUWmckoCCoaAsAI1HRb0E/S24AXESz9s8ZdY0jRSJ/FZ IaxpRNB1KkX6pC8PtqK48M5sfHq8CgqGFP0y3Kj1hjJbaI3PIMMp7Acg49NcQ4Ev8DKl J2nBAS1+tQ9UZgxHrjQ859LQtfO9zWxmj5ffSB7DZpvylr2wh+hJXKenY6H1B/oqp/zB 3y5g== X-Forwarded-Encrypted: i=1; AJvYcCXioc77I0r1X2iZxCvW5D+8FYJQRUPnCJWiA8vgq3zoW8MXhDdOdQfvMiYpDBUz9rjC6s4j7wu6cjEuAr0g2o6IAib9ydfvwoLB+m62x20= X-Gm-Message-State: AOJu0YyS7ENvq1HDhW7q32BCBrW6MCJ5kJvwZQKRrqKLuG3NkY0/en7v +Ht9pE7dZvRI1UB3hpna2Z1pr9Y16xeWgNibQfxQ9KX+Wj31YrtBC+HvcEnxUUk= X-Google-Smtp-Source: AGHT+IEfNQYlTblogER2FQDNT8br9Hz5yYe6DV7T7hEG9On+cqSjETAMT9aCWnmat8nJeK812hrxpw== X-Received: by 2002:a05:6214:18d3:b0:690:4e5e:c01e with SMTP id cy19-20020a05621418d300b006904e5ec01emr1113193qvb.0.1709305591845; Fri, 01 Mar 2024 07:06:31 -0800 (PST) Message-ID: <2af9519b-b468-4ec9-8d76-2fface1c877a@citrix.com> Date: Fri, 1 Mar 2024 15:06:27 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/mm: re-implement get_page_light() using an atomic increment Content-Language: en-GB To: Roger Pau Monne , xen-devel@lists.xenproject.org Cc: Jan Beulich , Wei Liu References: <20240301124228.56123-1-roger.pau@citrix.com> From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <20240301124228.56123-1-roger.pau@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 01/03/2024 12:42 pm, Roger Pau Monne wrote: > The current usage of a cmpxchg loop to increase the value of page count is not > optimal on amd64, as there's already an instruction to do an atomic add to a > 64bit integer. > > Switch the code in get_page_light() to use an atomic increment, as that avoids > a loop construct. This slightly changes the order of the checks, as current > code will crash before modifying the page count_info if the conditions are not > correct, while with the proposed change the crash will happen immediately > after having carried the counter increase. Since we are crashing anyway, I > don't believe the re-ordering to have any meaningful impact. > > Note that the page must already have a non-zero reference count which prevents > the flags from changing, and the previous usage of the cmpxchg loop didn't > guarantee that the rest of the fields in count_info didn't change while > updating the reference count. > > Signed-off-by: Roger Pau Monné Reviewed-by: Andrew Cooper I think the minor new corner case is well worth the simplification this change provides. From xen-devel-bounces@lists.xenproject.org Fri Mar 01 15:24:58 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2024 15:24:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687727.1071495 (Exim 4.92) (envelope-from ) id 1rg4km-0003Rl-FG; Fri, 01 Mar 2024 15:24:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687727.1071495; Fri, 01 Mar 2024 15:24:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg4km-0003Re-CV; Fri, 01 Mar 2024 15:24:52 +0000 Received: by outflank-mailman (input) for mailman id 687727; Fri, 01 Mar 2024 15:24:50 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg4kk-0003RY-J6 for xen-devel@lists.xenproject.org; Fri, 01 Mar 2024 15:24:50 +0000 Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [2a00:1450:4864:20::630]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id d7c4b322-d7df-11ee-afd8-a90da7624cb6; Fri, 01 Mar 2024 16:24:49 +0100 (CET) Received: by mail-ej1-x630.google.com with SMTP id a640c23a62f3a-a3e552eff09so309928366b.3 for ; Fri, 01 Mar 2024 07:24:49 -0800 (PST) Received: from [10.80.67.149] (default-46-102-197-194.interdsl.co.uk. [46.102.197.194]) by smtp.gmail.com with ESMTPSA id bq5-20020a170906d0c500b00a43bf243342sm1794350ejb.24.2024.03.01.07.24.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 01 Mar 2024 07:24:47 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d7c4b322-d7df-11ee-afd8-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709306689; x=1709911489; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=0040ipsv4HL0h/S5Bl+ETToBshF56Om1ClMWwAp3WTc=; b=ViI3fIdpnpJw93Zz9ZajUUl8lPR3ZgWglsfKzZxunjcSpW3Ez9bVF+4PK1aG86+Djs liCNMn6D2mykHmU5KGI6+KLcA1MzntrZUS6cmTihudTxLzC2uFJE6DjJ349yPsdw5yIP Ikj5p22+0jOUZrvdG8qTrlR2cSQi8jKV4sxYw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709306689; x=1709911489; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=0040ipsv4HL0h/S5Bl+ETToBshF56Om1ClMWwAp3WTc=; b=Gv1JUDnPpWkpSCqdj25wyeCxQ3RLRcLLCW5/SD69iIQyuKbaHvw+NkgZlMVHbIhq6u XK6FoNMZMlCuWluzShSgcLRqOMf574a+y1Hj+C6kgdFbSjOB45BkuKKmi/4BNsD0Fa1O QklgCB4+Ie1zRRVol28Gb2+HEGIzWu0W+2inkkuNZ+JfzmmkGGxrpxK9bzGY6msI9UAF B/4kpPgWE6pijJi4BQBs5LdQXm/FJVzK2U1bW7GDsj2/QONt5Hdfde0Yb+OMBP0nMJYb XGw5Atc2Fia1nmMYsXKjjxyLQzy0LSnTWp2Ronmbih8KUj6EVcExImNJpsCy4kj1m05n 9p6g== X-Gm-Message-State: AOJu0YwY1IjsXSJhSYf90ZDNyON3QMv68OtuOlrGCnj0F0sPF2NKCsEK kyW/ghNs5yY4HDulIZ5QrtGYIARlxGFVi34qUL79tmKemesj+CH/eLeD2QuM7/c= X-Google-Smtp-Source: AGHT+IFuejmRGKbsFrc0ktfT1ac6SZwkkffvcmCcAIUu0Mq6RjHfU9U/9402tgSSLweTtQn2sRzQ4Q== X-Received: by 2002:a17:907:20b9:b0:a43:eb29:a293 with SMTP id pw25-20020a17090720b900b00a43eb29a293mr1393956ejb.5.1709306688796; Fri, 01 Mar 2024 07:24:48 -0800 (PST) Message-ID: Date: Fri, 1 Mar 2024 15:24:47 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/cpu-policy: Fix visibility of HTT/CMP_LEGACY in max policies Content-Language: en-GB To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: Xen-devel , Jan Beulich , Wei Liu References: <20240301112829.2657865-1-andrew.cooper3@citrix.com> From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 01/03/2024 12:30 pm, Roger Pau Monné wrote: > On Fri, Mar 01, 2024 at 11:28:29AM +0000, Andrew Cooper wrote: >> The block in recalculate_cpuid_policy() predates the proper split between >> default and max policies, and was a "slightly max for a toolstack which knows >> about it" capability. It didn't get transformed properly in Xen 4.14. >> >> Because Xen will accept a VM with HTT/CMP_LEGACY seen, they should be visible >> in the max polices. Keep the default policy matching host settings. >> >> This manifested as an incorrectly-rejected migration across XenServer's Xen >> 4.13 -> 4.17 upgrade, as Xapi is slowly growing the logic to check a VM >> against the target max policy. >> >> Signed-off-by: Andrew Cooper > Reviewed-by: Roger Pau Monné Thanks. > > I have one question below. > >> --- >> CC: Jan Beulich >> CC: Roger Pau Monné >> CC: Wei Liu >> --- >> xen/arch/x86/cpu-policy.c | 29 ++++++++++++++++++++++------- >> 1 file changed, 22 insertions(+), 7 deletions(-) >> >> diff --git a/xen/arch/x86/cpu-policy.c b/xen/arch/x86/cpu-policy.c >> index c9b32bc17849..4f558e502e01 100644 >> --- a/xen/arch/x86/cpu-policy.c >> +++ b/xen/arch/x86/cpu-policy.c >> @@ -464,6 +464,16 @@ static void __init guest_common_max_feature_adjustments(uint32_t *fs) >> raw_cpu_policy.feat.clwb ) >> __set_bit(X86_FEATURE_CLWB, fs); >> } >> + >> + /* >> + * Topology information inside the guest is entirely at the toolstack's >> + * disgression, and bears no relationship to the host we're running on. >> + * >> + * HTT identifies p->basic.lppp as valid >> + * CMP_LEGACY identifies p->extd.nc as valid >> + */ >> + __set_bit(X86_FEATURE_HTT, fs); >> + __set_bit(X86_FEATURE_CMP_LEGACY, fs); >> } >> >> static void __init guest_common_default_feature_adjustments(uint32_t *fs) >> @@ -514,6 +524,18 @@ static void __init guest_common_default_feature_adjustments(uint32_t *fs) >> __clear_bit(X86_FEATURE_CLWB, fs); >> } >> >> + /* >> + * Topology information is at the toolstack's discretion so these are >> + * unconditionally set in max, but pick a default which matches the host. >> + */ >> + __clear_bit(X86_FEATURE_HTT, fs); >> + if ( cpu_has_htt ) >> + __set_bit(X86_FEATURE_HTT, fs); >> + >> + __clear_bit(X86_FEATURE_CMP_LEGACY, fs); >> + if ( cpu_has_cmp_legacy ) >> + __set_bit(X86_FEATURE_CMP_LEGACY, fs); > Not that I oppose to it, but does it make sense to expose this options > to PV guests by default? Those guests don't really have an APIC ID, > and I think we don't expect any of the topology information to be > usable by them in the first place. This patch doesn't alter what PV or HVM guests see by default.  This hunk only counteracts the prior hunk forcing visibility of the two bits in the max policy. Whether it is sensible for PV to see this is a different matter, and it's actually very complicated. On systems without CPUID Faulting, we have to contend with PV guests seeing mostly host data, whatever Xen would prefer. With CPUID Masking, we can hide (Intel) or hide/set (AMD) these bits in the feature leaves, but we can never stop the host value leaking into lppp/nc/etc. For better or worse, when the toolstack is divining a policy for PV guests, it also chooses the host HTT/CMP_LEGACY values. We should reconsider all of this when we've got topology working sensibly for HVM guests. ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Mar 01 15:29:15 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2024 15:29:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687730.1071505 (Exim 4.92) (envelope-from ) id 1rg4oy-00043v-Uq; Fri, 01 Mar 2024 15:29:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687730.1071505; Fri, 01 Mar 2024 15:29:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg4oy-00043o-SD; Fri, 01 Mar 2024 15:29:12 +0000 Received: by outflank-mailman (input) for mailman id 687730; Fri, 01 Mar 2024 15:29:12 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg4oy-00042U-AO for xen-devel@lists.xenproject.org; Fri, 01 Mar 2024 15:29:12 +0000 Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [2a00:1450:4864:20::52f]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 74040eac-d7e0-11ee-afd8-a90da7624cb6; Fri, 01 Mar 2024 16:29:11 +0100 (CET) Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-56533e30887so4110613a12.1 for ; Fri, 01 Mar 2024 07:29:11 -0800 (PST) Received: from [10.80.67.149] (default-46-102-197-194.interdsl.co.uk. [46.102.197.194]) by smtp.gmail.com with ESMTPSA id q12-20020a056402518c00b00563ec73bbafsm1649234edd.46.2024.03.01.07.29.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 01 Mar 2024 07:29:09 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 74040eac-d7e0-11ee-afd8-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709306951; x=1709911751; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=kkF6Nzs3alqJskCA0a76NE9opSG5DMrPOK53HFJFRpc=; b=Bcd7bzA9CzcbAVU8i48QMZi68xnt8uHRduHMu314wkDYRP+/P9+nkKcd8Yr6u/DMkG fadIU0lP/wp934vHcwMYPn6/c95517h+bGpZgOW8oF8BrXWQdWNwGrH3brdNNZwdYFS8 gIFecblB4LJtN/C3fdF5p9dhN4Ey6DXQTauqc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709306951; x=1709911751; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=kkF6Nzs3alqJskCA0a76NE9opSG5DMrPOK53HFJFRpc=; b=bJugbwu8B8TwvMCHvF/OxD8lDqUdH0HvzRtCzyYY+tdbBa9zFzDIMWF9sr9MN98KJr eexb6Sx0nWkiW0Bka6kWnaItJs0C1kIqPkcCUw5ij5aV/w9DLOZhXHjwWGyrUi9w0X/R OOwyfXt8gPUyEGQqgqL7EYms5ZWKzuJbw1r9QMCaAWwmL4gjwzuLoTJTXc2VliTtrN3d epW1w4aSKFgl4U7nvcr7jO2zlGO+VYKRrujeXDeoAG22bmhiQbhbGXNRsKWH5VJYFfQA GlffCfUl0t44Q7LcJSuTcEFddQUeVD6QKqeQPWpRnH25MtpF2dqZToamvVzfbwwNkbJn unNg== X-Gm-Message-State: AOJu0YyB8l/Eja0Mc+Dw0Zbwnlxd1vXXrChwewgrSDAipl7sakurAphH gwDEhjAmMx5kKWixKTWytiLS7PA7veN2DJFfpolXYUUM5LPMvRRJwVxLJfV3zZ/B+RFLJlhbVQM 1 X-Google-Smtp-Source: AGHT+IEvfGZTG5r4zJYTe8OZ3zbexguf8MHnRmi6BSktSY/hjcmECaXyNtZFb8nCBiwrxKgdlzF2Xg== X-Received: by 2002:a05:6402:40d0:b0:566:d6b6:f905 with SMTP id z16-20020a05640240d000b00566d6b6f905mr1728723edb.13.1709306951049; Fri, 01 Mar 2024 07:29:11 -0800 (PST) Message-ID: Date: Fri, 1 Mar 2024 15:29:08 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/cpu-policy: Hide x2APIC from PV guests Content-Language: en-GB To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: Xen-devel , Jan Beulich , Wei Liu References: <20240229221448.2593171-1-andrew.cooper3@citrix.com> From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 01/03/2024 12:11 pm, Roger Pau Monné wrote: > On Thu, Feb 29, 2024 at 10:14:48PM +0000, Andrew Cooper wrote: >> PV guests can't write to MSR_APIC_BASE (in order to set EXTD), nor can they >> access any of the x2APIC MSR range. Therefore they mustn't see the x2APIC >> CPUID bit saying that they can. >> >> Right now, the host x2APIC flag filters into PV guests, meaning that PV guests >> generally see x2APIC except on Zen1-and-older AMD systems. >> >> Linux works around this by explicitly hiding the bit itself, and filtering >> EXTD out of MSR_APIC_BASE reads. NetBSD behaves more in the spirit of PV >> guests, and entirely ignores the APIC when built as a PV guest. >> >> Change the annotation from !A to !S. This has a consequence of stripping it >> out of both PV featuremasks. However, as existing guests may have seen the >> bit, set it back into the PV Max policy; a VM which saw the bit and is alive >> enough to migrate will have ignored it one way or another. >> >> Hiding x2APIC does also change the contents of leaf 0xb, but as the >> information is nonsense to begin with, this is likely an improvement on the >> status quo. The blind reporting of APIC_ID = vCPU_ID * 2 isn't interlinked >> with the host's topology structure, and the APIC_IDs are useless without an >> MADT to start with. > AFAICT the APIC ID in CPUID leaf 0x1 %ebx is only reported to HVM > guests, not PV ones (see the dynamic section of guest_cpuid()). "reported to" is complicated for PV with CPUID Masking, because host details will leak in for both the xAPIC and x2APIC IDs. > This paragraph might need adjusting then, as it reads to me as if PV > guests could also expect APIC_ID == vCPU_ID * 2. > > With this change no x{,2}APIC ID gets exposed in CPUID for PV guests > unless it's for compat reasons for guests that already saw the x2APIC > feature. I'll see if I can find some better wording. >> Dom0 is the only PV VM to get an MADT but it's the host >> one, meaning the two sets of APIC_IDs are from different address spaces. >> >> Signed-off-by: Andrew Cooper > Reviewed-by: Roger Pau Monné Thanks. ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Mar 01 15:30:48 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2024 15:30:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687738.1071514 (Exim 4.92) (envelope-from ) id 1rg4qR-0005j6-B4; Fri, 01 Mar 2024 15:30:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687738.1071514; Fri, 01 Mar 2024 15:30:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg4qR-0005iz-8W; Fri, 01 Mar 2024 15:30:43 +0000 Received: by outflank-mailman (input) for mailman id 687738; Fri, 01 Mar 2024 15:30:42 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg4qQ-0005it-Be for xen-devel@lists.xenproject.org; Fri, 01 Mar 2024 15:30:42 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id a96e23fe-d7e0-11ee-afd8-a90da7624cb6; Fri, 01 Mar 2024 16:30:41 +0100 (CET) Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) by support.bugseng.com (Postfix) with ESMTPA id A5CFB4EE0737; Fri, 1 Mar 2024 16:30:40 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a96e23fe-d7e0-11ee-afd8-a90da7624cb6 MIME-Version: 1.0 Date: Fri, 01 Mar 2024 16:30:40 +0100 From: Nicola Vetrini To: Jan Beulich Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, consulting@bugseng.com, andrew.cooper3@citrix.com, roger.pau@citrix.com, bertrand.marquis@arm.com, julien@xen.org, Volodymyr Babchuk , xen-devel@lists.xenproject.org Subject: Re: [XEN PATCH 02/10] xen/arm: address some violations of MISRA C Rule 20.7 In-Reply-To: <905119be-8731-4669-ac7f-c21aed6845dc@suse.com> References: <905119be-8731-4669-ac7f-c21aed6845dc@suse.com> Message-ID: <7c54b08875406e5b3a61325af124ae7f@bugseng.com> X-Sender: nicola.vetrini@bugseng.com Organization: BUGSENG s.r.l. Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 2024-02-29 17:34, Jan Beulich wrote: > On 29.02.2024 16:27, Nicola Vetrini wrote: >> --- a/xen/arch/arm/cpuerrata.c >> +++ b/xen/arch/arm/cpuerrata.c >> @@ -462,8 +462,8 @@ static bool has_ssbd_mitigation(const struct >> arm_cpu_capabilities *entry) >> #define MIDR_RANGE(model, min, max) \ >> .matches = is_affected_midr_range, \ >> .midr_model = model, \ >> - .midr_range_min = min, \ >> - .midr_range_max = max >> + .midr_range_min = (min), \ >> + .midr_range_max = (max) > > Why min and max, but not model? > All the constants in the full expansions are parenthesized via MIDR_CPU_MODEL, so it doesn't trigger any violation right now, but for consistency I'd better put parentheses there as well. >> --- a/xen/arch/arm/include/asm/smccc.h >> +++ b/xen/arch/arm/include/asm/smccc.h >> @@ -122,7 +122,7 @@ struct arm_smccc_res { >> #define __constraint_read_7 __constraint_read_6, "r" (r7) >> >> #define __declare_arg_0(a0, res) \ >> - struct arm_smccc_res *___res = res; \ >> + struct arm_smccc_res *___res = (res); \ >> register unsigned long r0 ASM_REG(0) = (uint32_t)a0; \ > > Why res but not a0? > Seems like it's never used in a non-compliant way, but you do have a point. Here and also below, to keep it consistent. I didn't look at all the violations yet, so I may have missed some. I did want to show a few patches also to gather opinions on what may/may not be accepted. >> --- a/xen/arch/arm/include/asm/vgic-emul.h >> +++ b/xen/arch/arm/include/asm/vgic-emul.h >> @@ -6,11 +6,11 @@ >> * a range of registers >> */ >> >> -#define VREG32(reg) reg ... reg + 3 >> -#define VREG64(reg) reg ... reg + 7 >> +#define VREG32(reg) (reg) ... (reg) + 3 >> +#define VREG64(reg) (reg) ... (reg) + 7 > > #define VREG32(reg) (reg) ... ((reg) + 3) > #define VREG64(reg) (reg) ... ((reg) + 7) > > ? > The outer parentheses are not required, but I can add them if the maintainers share your view. -- Nicola Vetrini, BSc Software Engineer, BUGSENG srl (https://bugseng.com) From xen-devel-bounces@lists.xenproject.org Fri Mar 01 16:02:03 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2024 16:02:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687748.1071524 (Exim 4.92) (envelope-from ) id 1rg5KW-0002JH-B1; Fri, 01 Mar 2024 16:01:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687748.1071524; Fri, 01 Mar 2024 16:01:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg5KW-0002JA-8P; Fri, 01 Mar 2024 16:01:48 +0000 Received: by outflank-mailman (input) for mailman id 687748; Fri, 01 Mar 2024 16:01:46 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg5KU-0002J4-P1 for xen-devel@lists.xenproject.org; Fri, 01 Mar 2024 16:01:46 +0000 Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [2a00:1450:4864:20::52e]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 00971bdd-d7e5-11ee-afd8-a90da7624cb6; Fri, 01 Mar 2024 17:01:45 +0100 (CET) Received: by mail-ed1-x52e.google.com with SMTP id 4fb4d7f45d1cf-563c595f968so3736716a12.0 for ; Fri, 01 Mar 2024 08:01:45 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 00971bdd-d7e5-11ee-afd8-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1709308905; x=1709913705; darn=lists.xenproject.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=22goiwUKXnXos+NblU9baP8d3PaG2JHeNrBuLSf288Q=; b=LOfKiRUnvISDGAjaWzyfeonBxvC7eZZXAbjvYDe1J8o5IRxz71RzNSFWGG8j2u5WQo 7A10VLjqFMdODKXIE+cp08i0yR4G7rHGa2fSOCkjZGMmT5iA9I/YIqr0bZoVciHYwuWt uixROJoBW8IvoD6kgFkDpm98NOYncKHZ4+WlzIK6HdB26JFj+hwM7kTFtj4bno20tvy+ 9mKHQyN7VBiLAhycNULY0l4u0HyhwBWfeJxYRZgrpxH3JuxrFXHXB7cGqffvW4JKizBD Af/8L6Q1JNMwM9EwSAiJtWjUB2bJxD+NIbyVXmG03Xtvsgpv5J6MSpUkxJrpJptEgdUx i58A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709308905; x=1709913705; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=22goiwUKXnXos+NblU9baP8d3PaG2JHeNrBuLSf288Q=; b=lzw/gITt20Gws7QFIc4Bprc3fUcASS+1OIhxbwJmemV3urqD36ZE0iSKmQwqUeRNUw duJmMe1n4s/6cgoGUbR5FhJfI7EfzwIcovuGdWOo4OFc23olUjQqOdbj6xcSYdCg3+8g f9/aniPZf4Tn4nr3VXfyfXvedadMV1OANAgokBwhcr/Obbk3j6PMLPEq81OgmjNxUvO1 fKcTsd8FP4E2WwyUWCajr7TblWH5Ym1EfyWXxk54ODpmEILWp5AE1W/8MplwpaMBCTld 2CdZ6x6dbh2S9UqkgugoZGpNANq8edof2ZQ0Xi7lWrrYlJHYKScXhN5Aj3nRaUXUKSms xISg== X-Gm-Message-State: AOJu0Ywb6BHzQrI2M+EDxQAJ75z9Njh/uDs5IPclY6f59GciZjSQjVix j04jNq8ew+8KJHNpG8YGRz0dcQFfBiu4S5xcxg37VG85WM0GYAf/24bt/zmDTIj/3UqJA4q2XlV 2J4p8VHRA8aVcCBfOIHmqpHl2JCCN/7CkbRovdQ== X-Google-Smtp-Source: AGHT+IFZv0TSRLlipx3wNfelK/3PPDrzStQj9BbIJIgGxnjbLEcEcQubqJmyREr9tW8AV2Au0fU7oTdlfFSRJZJIf2Y= X-Received: by 2002:a17:906:dce:b0:a3f:adcf:7f58 with SMTP id p14-20020a1709060dce00b00a3fadcf7f58mr1851607eji.21.1709308904552; Fri, 01 Mar 2024 08:01:44 -0800 (PST) MIME-Version: 1.0 References: <20240129171811.21382-1-carlo.nonato@minervasys.tech> <20240129171811.21382-7-carlo.nonato@minervasys.tech> In-Reply-To: From: Carlo Nonato Date: Fri, 1 Mar 2024 17:01:33 +0100 Message-ID: Subject: Re: [PATCH v6 06/15] tools: add support for cache coloring configuration To: Anthony PERARD Cc: xen-devel@lists.xenproject.org, andrea.bastoni@minervasys.tech, Wei Liu , Juergen Gross , Marco Solieri Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Anthony, On Wed, Feb 28, 2024 at 7:05=E2=80=AFPM Anthony PERARD wrote: > > On Mon, Jan 29, 2024 at 06:18:02PM +0100, Carlo Nonato wrote: > > diff --git a/tools/include/xenctrl.h b/tools/include/xenctrl.h > > index 2ef8b4e054..4b541fffd2 100644 > > --- a/tools/include/xenctrl.h > > +++ b/tools/include/xenctrl.h > > @@ -2653,6 +2653,15 @@ int xc_livepatch_replace(xc_interface *xch, char= *name, uint32_t timeout, uint32 > > int xc_domain_cacheflush(xc_interface *xch, uint32_t domid, > > xen_pfn_t start_pfn, xen_pfn_t nr_pfns); > > > > +/* > > + * Set LLC colors for a domain. > > + * This is an internal hypercall. It can only be used directly after d= omain > > What is an "internal hypercall"? Can those even exist? Bad naming from my side. I'll remove that piece from the comment. > > + * creation. An attempt to use it afterwards will result in an error. > > + */ > > +int xc_domain_set_llc_colors(xc_interface *xch, uint32_t domid, > > + const unsigned int *llc_colors, > > + unsigned int num_llc_colors); > > + > > #if defined(__arm__) || defined(__aarch64__) > > int xc_dt_overlay(xc_interface *xch, void *overlay_fdt, > > uint32_t overlay_fdt_size, uint8_t overlay_op); > > diff --git a/tools/libs/ctrl/xc_domain.c b/tools/libs/ctrl/xc_domain.c > > index f2d9d14b4d..ad02288659 100644 > > --- a/tools/libs/ctrl/xc_domain.c > > +++ b/tools/libs/ctrl/xc_domain.c > > @@ -2180,6 +2180,40 @@ int xc_domain_soft_reset(xc_interface *xch, > > domctl.domain =3D domid; > > return do_domctl(xch, &domctl); > > } > > + > > +int xc_domain_set_llc_colors(xc_interface *xch, uint32_t domid, > > + const unsigned int *llc_colors, > > + unsigned int num_llc_colors) > > +{ > > + struct xen_domctl domctl =3D {}; > > + DECLARE_HYPERCALL_BUFFER(uint32_t, local); > > + int ret =3D -1; > > + > > + if ( num_llc_colors ) > > + { > > + size_t bytes =3D sizeof(uint32_t) * num_llc_colors; > > Isn't there a risk of overflow, maybe only on 32bit platform? Or maybe > that doesn't matter because the hypervisor should be able to find out if > the buffer is too short, right? I'm not aware of a way to find out the actual buffer size in the hypervisor= , so to answer your question, yes there's a risk of overflow, but that would require a huge number of colors, which would probably fail the allocation or would fail the check on the platform supported number of color in the hypervisor. If you prefer I can add the check here anyway. > > + local =3D xc_hypercall_buffer_alloc(xch, local, bytes); > > + if ( local =3D=3D NULL ) > > + { > > + PERROR("Could not allocate LLC colors for set_llc_colors")= ; > > + return -ENOMEM; > > + } > > + memcpy(local, llc_colors, bytes); > > + set_xen_guest_handle(domctl.u.set_llc_colors.llc_colors, local= ); > > + } > > + > > + domctl.cmd =3D XEN_DOMCTL_set_llc_colors; > > + domctl.domain =3D domid; > > + domctl.u.set_llc_colors.num_llc_colors =3D num_llc_colors; > > + > > + ret =3D do_domctl(xch, &domctl); > > + > > + if ( local ) > > + xc_hypercall_buffer_free(xch, local); > > It doesn't looks like you need to check if "local !=3D NULL" before > calling xc_hypercall_buffer_free(), it should work even with > local=3D=3DNULL. This is even used multiple time in xc_kexec. Ok, thanks. > > + > > + return ret; > > +} > > Thanks, > > -- > Anthony PERARD From xen-devel-bounces@lists.xenproject.org Fri Mar 01 17:08:42 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2024 17:08:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687760.1071535 (Exim 4.92) (envelope-from ) id 1rg6N4-00022C-3T; Fri, 01 Mar 2024 17:08:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687760.1071535; Fri, 01 Mar 2024 17:08:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg6N4-000225-0T; Fri, 01 Mar 2024 17:08:30 +0000 Received: by outflank-mailman (input) for mailman id 687760; Fri, 01 Mar 2024 17:08:28 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg6N2-00021z-3M for xen-devel@lists.xenproject.org; Fri, 01 Mar 2024 17:08:28 +0000 Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [2a00:1450:4864:20::335]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 50fc2be7-d7ee-11ee-a1ee-f123f15fe8a2; Fri, 01 Mar 2024 18:08:25 +0100 (CET) Received: by mail-wm1-x335.google.com with SMTP id 5b1f17b1804b1-412cd58dd71so2267885e9.1 for ; Fri, 01 Mar 2024 09:08:25 -0800 (PST) Received: from draig.lan ([85.9.250.243]) by smtp.gmail.com with ESMTPSA id jn3-20020a05600c6b0300b004128e903b2csm8910607wmb.39.2024.03.01.09.08.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 Mar 2024 09:08:24 -0800 (PST) Received: from draig (localhost [IPv6:::1]) by draig.lan (Postfix) with ESMTP id 9A47B5F7B4; Fri, 1 Mar 2024 17:08:24 +0000 (GMT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 50fc2be7-d7ee-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1709312905; x=1709917705; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:message-id:date:user-agent :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=yIsxd3I49dEeoEihY92y12I5QN6KFVksMBQbYfAFd0k=; b=MbSBKRy0Z8cpQv5rU7fvaPkGkBjAtk9LSeKmelqJT9d+yKxiQHyVH7FKvRgFCGbuYH CfvqjDlgoF7Y3xYvnNhFLNBHVt5JeZurhb9X8YFqgt3EMB+9r+gPF4KKRih+j1tSrm7e hmKeWTD0TmxGyhC3UTxczVZMvfXiLyzDemVx7xKGtUQGoGoraVUnTn/oJ9oLK6490x7L jemEv5dI0wzEDQEtDkXZc6k+GmBF92ag3UWE2n3AQyqCfU9G7j753GP+cd8DmH/8jrMu ljfNvKaIUJNoqndEeWjaMDo5hr9MRCA8VI5PgJT83uqqpEwS7svxembGHm/FG1YCtk2f FiiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709312905; x=1709917705; h=content-transfer-encoding:mime-version:message-id:date:user-agent :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=yIsxd3I49dEeoEihY92y12I5QN6KFVksMBQbYfAFd0k=; b=aQOcpgf8/ri9YQukuq6EroXysnhF1gs0Z7HknwZvQtd7FUBJCxy7bozLwn/FQwaIuk px5X6xSfQnVneEzKMaqVqZFvPWUZD0V2DEd6ndJzpxFpUNl7PtaHeWh6yNgeQ6e8zAUQ 0XPb+mlKP8IUFWrjQhUWxi988b47EaQGu3Xcd2UA+5S2+lNcrD1eLzZFeZxIluyhYNYK 3+7jxbRc93nzn8oKu0B+DmBk2lLaa7T1n5sHKWhzinJnuI3rpq74WhgnCwFWi9cJ/0d3 TMZH7zldmkIbHP7etn6drBemFV5jGOotPjT/xjU3rI8ayLSQxGSmuAMbUl+CdLmBaRcl CnWQ== X-Forwarded-Encrypted: i=1; AJvYcCW4W5v9fWcuH2IXreqg6FWcOVhEXdtmO2KGQN1fxFs7l3chqNkH9YtwoYSU3kyB0vgCv6/nQuQmh+2Y+HTHnr3PF/1QE5dvITjI1bczj8w= X-Gm-Message-State: AOJu0YzInL+8Pav4AwQ7sYRB7t1KUMmrPw4dh9SkfWsvMbExukq8NFGm 5i7HmWiYU87tbDXWpn7cnosmuaLpzjj/1ueI2hhmxYMn/5aPdL5ZwOCOIdZuS/E= X-Google-Smtp-Source: AGHT+IF/04gw/RkqLIbw8xez/beiUpqog3Zmj88Frgy30DgiLIcrkJ88jnJeBOUjtNlvcLKherqjQg== X-Received: by 2002:a05:600c:45cf:b0:412:ca55:10ec with SMTP id s15-20020a05600c45cf00b00412ca5510ecmr1148930wmo.19.1709312905208; Fri, 01 Mar 2024 09:08:25 -0800 (PST) From: =?utf-8?Q?Alex_Benn=C3=A9e?= To: Vikram Garhwal Cc: , , , Anthony Perard , Paul Durrant , "open list:X86 Xen CPUs" Subject: Re: [QEMU][PATCH v3 4/7] xen: let xen_ram_addr_from_mapcache() return -1 in case of not found entry In-Reply-To: <20240227223501.28475-5-vikram.garhwal@amd.com> (Vikram Garhwal's message of "Tue, 27 Feb 2024 14:34:58 -0800") References: <20240227223501.28475-1-vikram.garhwal@amd.com> <20240227223501.28475-5-vikram.garhwal@amd.com> User-Agent: mu4e 1.12.0; emacs 29.1 Date: Fri, 01 Mar 2024 17:08:24 +0000 Message-ID: <87o7bx5187.fsf@draig.linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Vikram Garhwal writes: > From: Juergen Gross > > Today xen_ram_addr_from_mapcache() will either abort() or return 0 in > case it can't find a matching entry for a pointer value. Both cases > are bad, so change that to return an invalid address instead. > > Signed-off-by: Juergen Gross > Reviewed-by: Stefano Stabellini > --- > hw/xen/xen-mapcache.c | 11 +++-------- > 1 file changed, 3 insertions(+), 8 deletions(-) > > diff --git a/hw/xen/xen-mapcache.c b/hw/xen/xen-mapcache.c > index dfc412d138..179b7e95b2 100644 > --- a/hw/xen/xen-mapcache.c > +++ b/hw/xen/xen-mapcache.c > @@ -396,13 +396,8 @@ ram_addr_t xen_ram_addr_from_mapcache(void *ptr) > } > } > if (!found) { > - trace_xen_ram_addr_from_mapcache_not_found(ptr); > - QTAILQ_FOREACH(reventry, &mapcache->locked_entries, next) { > - trace_xen_ram_addr_from_mapcache_found(reventry->paddr_index, > - reventry->vaddr_req); > - } If these tracepoints aren't useful they need removing from trace-events. However I suspect it would be better to keep them in as they are fairly cheap. Otherwise: Reviewed-by: Alex Benn=C3=A9e --=20 Alex Benn=C3=A9e Virtualisation Tech Lead @ Linaro From xen-devel-bounces@lists.xenproject.org Fri Mar 01 17:21:50 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2024 17:21:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687763.1071544 (Exim 4.92) (envelope-from ) id 1rg6Zu-0004b4-5d; Fri, 01 Mar 2024 17:21:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687763.1071544; Fri, 01 Mar 2024 17:21:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg6Zu-0004ax-2c; Fri, 01 Mar 2024 17:21:46 +0000 Received: by outflank-mailman (input) for mailman id 687763; Fri, 01 Mar 2024 17:21:45 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg6Zt-0004ar-G2 for xen-devel@lists.xenproject.org; Fri, 01 Mar 2024 17:21:45 +0000 Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [2a00:1450:4864:20::136]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 2c7d45e1-d7f0-11ee-a1ee-f123f15fe8a2; Fri, 01 Mar 2024 18:21:43 +0100 (CET) Received: by mail-lf1-x136.google.com with SMTP id 2adb3069b0e04-512f892500cso1865724e87.3 for ; Fri, 01 Mar 2024 09:21:43 -0800 (PST) Received: from [192.168.206.239] ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id v16-20020a056512349000b0051330fe6604sm294477lfr.51.2024.03.01.09.21.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 Mar 2024 09:21:41 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 2c7d45e1-d7f0-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709313702; x=1709918502; darn=lists.xenproject.org; h=mime-version:user-agent:content-transfer-encoding:date:cc:to:from :subject:message-id:from:to:cc:subject:date:message-id:reply-to; bh=wn8a3OeiJELe0XVOp6Fr9h++++WquncjbVpxs2mnou8=; b=C+bYQB2MjQ1s2aqNQiZyG10gXb3WoX8x+9MdKzDimsO6JaunPCt95F6Ikfiruy4ORD Z/VL6V1Gm7djEa+2VEPtK/HO9lFQoLg45OfT5qLLVkq52M7UKNJEP9D1ODlDrPniBAe9 vzU7iJTSVG+3nYDNDEXx7hB4eu+KsDd8DcbhXiVHxGkqukjcEN7aS7wjiTHpRPIUhcok oWYTfCNLZwcOeTwUv/IWtvwdMbRriBZeOUCZ4KYYQoAWisqbKM+HAiJ15D9f4kbxVosW geznKZBq2D3K3ZAmw42f8lhoB37o+301y+Ce+c9v6+PzQ38+BpGOx0vODoBM9YLK2fiR yOIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709313702; x=1709918502; h=mime-version:user-agent:content-transfer-encoding:date:cc:to:from :subject:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=wn8a3OeiJELe0XVOp6Fr9h++++WquncjbVpxs2mnou8=; b=rsF8RqmdI7yPiXlUT6A5cA1hRgVs/lM6R+OMU93xgAUkgfitOc3md39lxe5CO71Eaw rn+sGOoE3IUh3+rJOIsTQi+dqvoCYLDiQBUouwf6TSuh6ly+DO993ho+3b58C50/ORvi 1mn7J6AYJwurGk27DJgP2CzNT7hFY3+e04HYt8ttaMQ24HIXrGaL0wOVno0+Z3XeRrPr KEmTdgz+90MyB/qY0c33x37hAMSdvxN1LYW7H4IionamoNbbMJWGTJPkhFGRg1N/wF6o eP7eLRkIkJUugLqUnZjsRNIaug3CiRJ4Xfeie3FGH2FPmbEPuQ9X0zxiQO7ZtiR/psBa okqA== X-Gm-Message-State: AOJu0Yw58VvMb3OiHRghZyn2PGGLZpTwgqbfhcOZ8ECsy5jFrxR89Yxu N5/kLFJryLLhvYuNN2t1y6cci/t9tjJR7rZbB5sIv1Y/hrEYfLfvfvBE/77N X-Google-Smtp-Source: AGHT+IE0bNBAG6kNbs0JSkj/7ReuZ/4n73Xsa9qZSerYXDv7I+w+tQz9N3bv5igDv2ECCFiLp+Blkg== X-Received: by 2002:a05:6512:39d0:b0:513:177f:ef57 with SMTP id k16-20020a05651239d000b00513177fef57mr2119764lfu.10.1709313701822; Fri, 01 Mar 2024 09:21:41 -0800 (PST) Message-ID: <91cc3f76029357f34bd5ca21966c42f0acb73720.camel@gmail.com> Subject: Xen 4.19 release status tracking list [ March ] From: Oleksii To: xen-devel@lists.xenproject.org Cc: committers@xenproject.org, community.manager@xenproject.org, Kelly Choi Date: Fri, 01 Mar 2024 18:21:40 +0100 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.50.2 (3.50.2-1.fc39) MIME-Version: 1.0 Hello everyone, I would like to share with you a list for status tracking based on Xen ML and community members comments: Arm: * [PATCH v6 00/15] Arm cache coloring [ https://lore.kernel.org/xen-devel/20240129171811.21382-1-carlo.nonato@miner= vasys.tech/ ]: new patch series version [v6] was sent * [PATCH v13 00/14] PCI devices passthrough on Arm, part 3 [ https://lore.kernel.org/xen-devel/20240202213321.1920347-1-stewart.hildebra= nd@amd.com/ ] PPC: * [PATCH v2 0/7] Early Boot Allocation on Power [ https://lore.kernel.org/xen-devel/cover.1702607884.git.sanastasio@raptoreng= ineering.com/ ] RISC-V: * [PATCH v4 05/23] Enable build of full Xen for RISC-V [ https://lore.kernel.org/xen-devel/cover.1708962629.git.oleksii.kurochko@gma= il.com/ ]: a bulk of patch have been merged already and a new version was sent to ML x86: * [PATCH 0/4] iommu/x86: fixes/improvements for unity range checks [ https://lore.kernel.org/xen-devel/20240201170159.66330-1-roger.pau@citrix.c= om/ ]:=20 * almost patch series have been merged already except the patch: [PATCH 4/4] iommu/x86: make unity range checking more strict * [PATCH 0/8] x86: support AVX10.1 [ https://lore.kernel.org/xen-devel/298db76f-d0ee-4d47-931f-1baa1a7546cf@suse= .com/ ] =20 * APX support? * [PATCH v4 0/8] x86emul: misc additions [ https://lore.kernel.org/xen-devel/9dd23064-c79e-4a50-9c71-c0e73b189944@suse= .com/ ]: * [PATCH v4 3/8] VMX: tertiary execution control infrastructure - was merged =20 * [PATCH 0/7] VT-d: SATC handling and ATS tidying [ https://lore.kernel.org/xen-devel/25506838-b818-4686-8c16-3a198338af44@suse= .com/ ] * [XEN PATCH 0/9] x86: parallelize AP bring-up during boot [ https://lore.kernel.org/xen-devel/cover.1699982111.git.krystian.hebel@3mdeb= .com/ ] * [PATCH v2 00/12] x86: memcpy() / memset() (non-)ERMS flavors plus fallout [ https://lore.kernel.org/xen-devel/8f56a8f4-0482-932f-96a9-c791bebb4610@suse= .com/ ] * [PATCH v2 01/12] x86: introduce ioremap_wc() - were merged common: * annotate entry points with type and size" series: The bulk of this has gone in, but there'll want to be follow-ups. * limit passing around of cpu_user_regs [ https://lore.kernel.org/xen-devel/ebc330a9-eafa-4858-b5cf-5694c4da911d@suse= .com/ ]: new patch series version was sent. * [PATCH v2 (resend) 00/27] Remove the directmap [ https://lore.kernel.org/xen-devel/20240116192611.41112-1-eliasely@amazon.co= m/ ] * [PATCH v9 0/7] Introduce generic headers [ https://lore.kernel.org/all/cover.1708086091.git.oleksii.kurochko@gmail.com= / ]: Almost fully patch series were merged except several patches: * [PATCH v9 1/7] automation: introduce fixed randconfig for RISC-V * [PATCH v9 2/7] xen/asm-generic: introduce stub header monitor.h * [PATCH v9 6/7] xen/ppc: switch PPC to use asm-generic/device.h =20 * [PATCH] move __read_mostly to xen/cache.h [ https://lore.kernel.org/xen-devel/f25eb5c9-7c14-6e23-8535-2c66772b333e@suse= .com/ ] * [XEN PATCH v2 1/3] xen: introduce STATIC_ASSERT_UNREACHABLE() [ https://lore.kernel.org/xen-devel/42fc6ae8d3eb802429d29c774502ff232340dc84.= 1706259490.git.federico.serafini@bugseng.com/ ] * MISRA rules updates: [PATCH v2] docs/misra/rules.rst update [ https://lore.kernel.org/xen-devel/alpine.DEB.2.22.394.2402131431070.1925432= @ubuntu-linux-20-04-desktop/T/#maded3df1bebe68d0fe53c73e89f996ec395a39e5 ] * [XEN PATCH 00/10] address some violations of MISRA C Rule 20.7 [ https://lore.kernel.org/xen-devel/cover.1709219010.git.nicola.vetrini@bugse= ng.com/T/#t ] =20 * [PATCH v4 00/12] xen/spinlock: make recursive spinlocks a dedicated type [ https://lore.kernel.org/xen-devel/20231212094725.22184-1-jgross@suse.com/T/= #t ] * [PATCH v2 0/5] xen/livepatch: fixes for the pre-apply / post-revert hooks [ https://lore.kernel.org/xen-devel/20240227112528.4540-1-roger.pau@citrix.co= m/T/#m620c827bd097522d9d87b7f6511bc1599f6a8c84 ] Completed: Arm: * [PATCH v1 repost 0/4] xen/arm64: Rework the MMU-off code (idmap) so it is self-contained [ https://lore.kernel.org/xen-devel/20240116143709.86584-1-julien@xen.org/ ] =20 x86: * [PATCH v9 0/6] tools: enable xenstore-stubdom to use 9pfs [ https://lore.kernel.org/xen-devel/20240229124830.13680-1-jgross@suse.com/ ]=20 common: * [PATCH v2] NUMA: no need for asm/numa.h when !NUMA [ https://lore.kernel.org/xen-devel/94cffa48-5e31-4557-827d-c6dec6031d05@suse= .com/ ] * [PATCH] xen: move BUG_ON(), WARN_ON(), ASSERT(), ASSERT_UNREACHABLE() to xen/bug.h [ https://lore.kernel.org/xen-devel/4887b2d91a4bf2e8b4b66f03964259651981403b.= 1706897023.git.oleksii.kurochko@gmail.com/ ] * [PATCH] xen/lib: introduce generic find next bit operations [ https://lore.kernel.org/xen-devel/52730e6314210ba4164a9934a720c4fda201447b.= 1706266854.git.oleksii.kurochko@gmail.com/ ] Please reply with items you would like to see in 4.19 so that people know what is happening and prioritize accordingly. You're welcome to provide a description and use cases of the feature you're working on. Have a nice week! Best regards, Oleksii From xen-devel-bounces@lists.xenproject.org Fri Mar 01 17:35:41 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2024 17:35:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687768.1071555 (Exim 4.92) (envelope-from ) id 1rg6nI-0006Of-BE; Fri, 01 Mar 2024 17:35:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687768.1071555; Fri, 01 Mar 2024 17:35:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg6nI-0006OY-81; Fri, 01 Mar 2024 17:35:36 +0000 Received: by outflank-mailman (input) for mailman id 687768; Fri, 01 Mar 2024 17:35:35 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg6nH-0006ON-N3; Fri, 01 Mar 2024 17:35:35 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg6nH-0002b1-GK; Fri, 01 Mar 2024 17:35:35 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg6nH-0005Zh-7J; Fri, 01 Mar 2024 17:35:35 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rg6nG-0008J7-Vl; Fri, 01 Mar 2024 17:35:34 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=/JinV6jlD2Y+XOYmCtbxlEnx3lfMwhjY/0lU1cQszto=; b=b1gtZqLiYyo1jmYhfx3xA5Uz4A dCy10zYUWeWGrjFWy6JSFQfFPDk6ubo28pR9Xda191gZxSNPnTBLsOAGtbamIus4or68OpdcRIc8R SjB+roau8uWnGhdDwED0hYpoAYvPso1/47aAqgNnKASmskzOrwCici63NqMWwYyk+7Wc=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-linus test] 184829: regressions - trouble: broken/fail/pass X-Osstest-Failures: linux-linus:test-amd64-amd64-qemuu-nested-intel::broken:regression linux-linus:test-amd64-amd64-pygrub::broken:regression linux-linus:test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm:xen-boot:fail:regression linux-linus:test-amd64-amd64-xl:xen-boot:fail:regression linux-linus:test-amd64-amd64-xl-qemuu-debianhvm-amd64:xen-boot:fail:regression linux-linus:test-amd64-amd64-xl-qemut-debianhvm-i386-xsm:xen-boot:fail:regression linux-linus:test-amd64-amd64-freebsd11-amd64:xen-boot:fail:regression linux-linus:test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow:xen-boot:fail:regression linux-linus:test-amd64-amd64-xl-qemuu-ovmf-amd64:xen-boot:fail:regression linux-linus:test-amd64-amd64-pygrub:xen-boot:fail:regression linux-linus:build-arm64-xsm:xen-build:fail:regression linux-linus:test-amd64-amd64-pygrub:host-install(5):broken:heisenbug linux-linus:test-amd64-amd64-qemuu-nested-intel:host-install(5):broken:heisenbug linux-linus:test-amd64-amd64-xl-vhd:xen-boot:fail:heisenbug linux-linus:test-amd64-amd64-xl-multivcpu:xen-boot:fail:heisenbug linux-linus:test-amd64-amd64-examine:reboot:fail:heisenbug linux-linus:test-armhf-armhf-libvirt-qcow2:leak-check/check:fail:heisenbug linux-linus:test-arm64-arm64-xl-xsm:build-check(1):blocked:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: linux=87adedeba51a822533649b143232418b9e26d08b X-Osstest-Versions-That: linux=805d849d7c3cc1f38efefd48b2480d62b7b5dcb7 From: osstest service owner Date: Fri, 01 Mar 2024 17:35:34 +0000 flight 184829 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/184829/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-qemuu-nested-intel broken test-amd64-amd64-pygrub broken test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 8 xen-boot fail REGR. vs. 184816 test-amd64-amd64-xl 8 xen-boot fail REGR. vs. 184816 test-amd64-amd64-xl-qemuu-debianhvm-amd64 8 xen-boot fail REGR. vs. 184816 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 8 xen-boot fail REGR. vs. 184816 test-amd64-amd64-freebsd11-amd64 8 xen-boot fail REGR. vs. 184816 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 8 xen-boot fail REGR. vs. 184816 test-amd64-amd64-xl-qemuu-ovmf-amd64 8 xen-boot fail REGR. vs. 184816 test-amd64-amd64-pygrub 8 xen-boot fail in 184825 REGR. vs. 184816 build-arm64-xsm 6 xen-build fail in 184825 REGR. vs. 184816 Tests which are failing intermittently (not blocking): test-amd64-amd64-pygrub 5 host-install(5) broken pass in 184825 test-amd64-amd64-qemuu-nested-intel 5 host-install(5) broken pass in 184825 test-amd64-amd64-xl-vhd 8 xen-boot fail pass in 184825 test-amd64-amd64-xl-multivcpu 8 xen-boot fail pass in 184825 test-amd64-amd64-examine 8 reboot fail pass in 184825 test-armhf-armhf-libvirt-qcow2 20 leak-check/check fail pass in 184825 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked in 184825 n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked in 184825 n/a test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop fail like 184816 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop fail like 184816 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop fail like 184816 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 184816 test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail like 184816 test-armhf-armhf-libvirt 16 saverestore-support-check fail like 184816 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop fail like 184816 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184816 test-amd64-amd64-libvirt-xsm 15 migrate-support-check fail never pass test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-arm64-arm64-xl 15 migrate-support-check fail never pass test-arm64-arm64-xl 16 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qcow2 14 migrate-support-check fail never pass test-amd64-amd64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-check fail never pass test-arm64-arm64-xl-vhd 14 migrate-support-check fail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 15 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-check fail never pass test-armhf-armhf-libvirt 15 migrate-support-check fail never pass version targeted for testing: linux 87adedeba51a822533649b143232418b9e26d08b baseline version: linux 805d849d7c3cc1f38efefd48b2480d62b7b5dcb7 Last test of basis 184816 2024-02-29 05:22:18 Z 1 days Testing same since 184825 2024-02-29 21:14:29 Z 0 days 2 attempts ------------------------------------------------------------ People who touched revisions under test: Alexander Ofitserov Amritha Nambiar Andre Werner Arkadiusz Kubalewski Benjamin Berg Charlie Jenkins Christophe Leroy Clancy Shang David S. Miller Davide Caratti Emmanuel Grumbach Eric Dumazet Felix Fietkau Florian Westphal Frédéric Danis Geliang Tang Geoff Levand Guenter Roeck Haiyue Wang Ignat Korchagin Jakub Kicinski Jakub Raczynski Janaki Ramaiah Thota Javier Carrasco Jeff Johnson Jeremy Kerr Johan Hovold Johannes Berg Jonas Dreßler Justin Iurman Kai-Heng Feng Kalle Valo Kurt Kanzenbach Lin Ma Linus Torvalds Luiz Augusto von Dentz Lukasz Majewski Madalin Bucur Matthieu Baerts (NGI0) Michal Kubecek Mickaël Salaün Miri Korenblit Nicolas Dichtel Nikolay Aleksandrov Oleksij Rempel Pablo Neira Ayuso Palmer Dabbelt Paolo Abeni Pucha Himasekhar Reddy (A Contingent worker at Intel) Randy Dunlap Ryosuke Yasuoka Sabrina Dubroca Serge Semin Shannon Nelson Stanislav Fomichev Sunitha Mekala (A Contingent worker at Intel) Tony Nguyen Vladimir Oltean Ying Hsu Yochai Hagvi Yunjian Wang Yuxuan Hu <20373622@buaa.edu.cn> Zijun Hu jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl fail test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm fail test-amd64-amd64-xl-qemut-debianhvm-i386-xsm fail test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-amd64-dom0pvh-xl-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 fail test-amd64-amd64-freebsd11-amd64 fail test-amd64-amd64-freebsd12-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-examine-bios pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine fail test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-amd64-qemuu-nested-intel broken test-amd64-amd64-xl-pvhv2-intel pass test-amd64-amd64-dom0pvh-xl-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-amd64-xl-multivcpu fail test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-amd64-xl-pvshim pass test-amd64-amd64-pygrub broken test-amd64-amd64-libvirt-qcow2 pass test-armhf-armhf-libvirt-qcow2 fail test-amd64-amd64-libvirt-raw pass test-arm64-arm64-libvirt-raw pass test-armhf-armhf-libvirt-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow fail test-amd64-amd64-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-examine-uefi pass test-amd64-amd64-xl-vhd fail test-arm64-arm64-xl-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these 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 broken-job test-amd64-amd64-qemuu-nested-intel broken broken-job test-amd64-amd64-pygrub broken broken-step test-amd64-amd64-pygrub host-install(5) broken-step test-amd64-amd64-qemuu-nested-intel host-install(5) Not pushing. (No revision log; it would be 2602 lines long.) From xen-devel-bounces@lists.xenproject.org Fri Mar 01 19:34:54 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2024 19:34:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687781.1071565 (Exim 4.92) (envelope-from ) id 1rg8eV-0003bh-K7; Fri, 01 Mar 2024 19:34:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687781.1071565; Fri, 01 Mar 2024 19:34:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg8eV-0003ba-Gl; Fri, 01 Mar 2024 19:34:39 +0000 Received: by outflank-mailman (input) for mailman id 687781; Fri, 01 Mar 2024 19:34:39 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg8eU-0003bU-Vh for xen-devel@lists.xenproject.org; Fri, 01 Mar 2024 19:34:38 +0000 Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [2607:f8b0:4864:20::733]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id bd3a91dd-d802-11ee-afd8-a90da7624cb6; Fri, 01 Mar 2024 20:34:37 +0100 (CET) Received: by mail-qk1-x733.google.com with SMTP id af79cd13be357-787be5d999aso142997685a.1 for ; Fri, 01 Mar 2024 11:34:37 -0800 (PST) Received: from localhost ([213.195.118.74]) by smtp.gmail.com with ESMTPSA id pi36-20020a05620a37a400b00787c0e4ac78sm1906898qkn.106.2024.03.01.11.34.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 Mar 2024 11:34:36 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: bd3a91dd-d802-11ee-afd8-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709321676; x=1709926476; darn=lists.xenproject.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=fMQdHcvbxGC2jwRGC5Iz1SyyBLW84FARfW5oDCxczfY=; b=gjFxvRAmelwi4OrpzxUeCnRAnAnIkStMJPRukf+SfAQGk+6udO9D7QEtJfrnk65285 sJBnsfwOT3cFObsHygS9MdvUAi9eIMHJeAz6hIFQC1Q4ZglqyrKSISgRdKENzB8LEYO+ OKgqA7DVJU1I+JqJMTartI/pWlArkha4yTbrs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709321676; x=1709926476; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=fMQdHcvbxGC2jwRGC5Iz1SyyBLW84FARfW5oDCxczfY=; b=dpwwErM5DTxbSF9parp+ZIU/7L+gYYYHagKSVwD9Fqbjjio5jnKWeTmdrcPMT704xD LpqSuZI2FYXfO3FQailtVKIqYaoK87LgxRHvO6zflMj62gOqV5MMFLSufnYmtEkRWhp9 ePDSC8vnNYP9UQo2wVXzC3Y6l1orTEk+9YXIQHtADjVcm1YzzkD2dWQERgh6qR+vMCYA Otdkx2QAlWoXQINK5AjiZA6nQ9kfEIncQ7w937QzsPKF/tanU+HUCTfavGDyTew8ET88 IFEpGgRJtvDMOwrUGUkAJ1VYEJSXR6L9J63Zpe8HNKMPRvVbQB5an68/3uRYN1c4jYOY 9knQ== X-Gm-Message-State: AOJu0YxYs4ud5Yn7ouZX80NzOTnP/m+CeTYkzzveEibsn7lDNW4/p00S yGDUcRduZBxhZ0sGkiLxHzN3cTs47BNiYQJINuDrnW4l8KnP9skGUdZGvPYev5ugNiOWDtX6tlN l X-Google-Smtp-Source: AGHT+IE/h938XBq/f2KOxuRU75sgc+1ZZkRcni6fmcTP3VLnSd81CRRLViD8FTmYf6Y5yPFWiv4ypQ== X-Received: by 2002:a05:620a:190f:b0:788:4ef:1182 with SMTP id bj15-20020a05620a190f00b0078804ef1182mr3778150qkb.50.1709321676682; Fri, 01 Mar 2024 11:34:36 -0800 (PST) Date: Fri, 1 Mar 2024 20:34:34 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Andrew Cooper Cc: Xen-devel , Jan Beulich , Wei Liu Subject: Re: [PATCH] x86/cpu-policy: Allow for levelling of VERW side effects Message-ID: References: <20240229181354.2560819-1-andrew.cooper3@citrix.com> <4fedcd61-94e1-4869-b620-27c48e8dafef@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4fedcd61-94e1-4869-b620-27c48e8dafef@citrix.com> On Fri, Mar 01, 2024 at 03:01:36PM +0000, Andrew Cooper wrote: > On 01/03/2024 1:28 pm, Roger Pau Monné wrote: > > On Thu, Feb 29, 2024 at 06:13:54PM +0000, Andrew Cooper wrote: > >> MD_CLEAR and FB_CLEAR need OR-ing across a migrate pool. Allow this, by > >> having them unconditinally set in max, with the host values reflected in > >> default. Annotate the bits as having special properies. > >> > >> Signed-off-by: Andrew Cooper > >> --- > >> CC: Jan Beulich > >> CC: Roger Pau Monné > >> CC: Wei Liu > >> --- > >> xen/arch/x86/cpu-policy.c | 24 +++++++++++++++++++++ > >> xen/include/public/arch-x86/cpufeatureset.h | 4 ++-- > >> 2 files changed, 26 insertions(+), 2 deletions(-) > >> > >> diff --git a/xen/arch/x86/cpu-policy.c b/xen/arch/x86/cpu-policy.c > >> index f3ed2d3a3227..41123e6cf778 100644 > >> --- a/xen/arch/x86/cpu-policy.c > >> +++ b/xen/arch/x86/cpu-policy.c > >> @@ -442,6 +442,16 @@ static void __init guest_common_max_feature_adjustments(uint32_t *fs) > >> __set_bit(X86_FEATURE_RSBA, fs); > >> __set_bit(X86_FEATURE_RRSBA, fs); > >> > >> + /* > >> + * These bits indicate that the VERW instruction may have gained > >> + * scrubbing side effects. With pooling, they mean "you might migrate > >> + * somewhere where scrubbing is necessary", and may need exposing on > >> + * unaffected hardware. This is fine, because the VERW instruction > >> + * has been around since the 286. > >> + */ > >> + __set_bit(X86_FEATURE_MD_CLEAR, fs); > >> + __set_bit(X86_FEATURE_FB_CLEAR, fs); > >> + > >> /* > >> * The Gather Data Sampling microcode mitigation (August 2023) has an > >> * adverse performance impact on the CLWB instruction on SKX/CLX/CPX. > >> @@ -476,6 +486,20 @@ static void __init guest_common_default_feature_adjustments(uint32_t *fs) > >> cpu_has_rdrand && !is_forced_cpu_cap(X86_FEATURE_RDRAND) ) > >> __clear_bit(X86_FEATURE_RDRAND, fs); > >> > >> + /* > >> + * These bits indicate that the VERW instruction may have gained > >> + * scrubbing side effects. The max policy has them set for migration > >> + * reasons, so reset the default policy back to the host values in > >> + * case we're unaffected. > >> + */ > >> + fs[FEATURESET_7d0] &= ~cpufeat_mask(X86_FEATURE_MD_CLEAR); > >> + fs[FEATURESET_m10Al] &= ~cpufeat_mask(X86_FEATURE_FB_CLEAR); > >> + > >> + fs[FEATURESET_7d0] |= (boot_cpu_data.x86_capability[FEATURESET_7d0] & > >> + cpufeat_mask(X86_FEATURE_MD_CLEAR)); > >> + fs[FEATURESET_m10Al] |= (boot_cpu_data.x86_capability[FEATURESET_m10Al] & > >> + cpufeat_mask(X86_FEATURE_FB_CLEAR)); > > This seems quite convoluted, why not use: > > > > __clear_bit(X86_FEATURE_MD_CLEAR, fs); > > if ( boot_cpu_has(X86_FEATURE_MD_CLEAR) ) > > __set_bit(X86_FEATURE_MD_CLEAR, fs); > > > > And the same for FB_CLEAR. I think that's quite easier to read. > > This better? > > +        /* > +         * These bits indicate that the VERW instruction may have gained > +         * scrubbing side effects.  The max policy has them set for > migration > +         * reasons, so reset the default policy back to the host values in > +         * case we're unaffected. > +         */ > +        __clear_bit(X86_FEATURE_MD_CLEAR); > +        if ( cpu_has_md_clear ) > +            __set_bit(X86_FEATURE_MD_CLEAR); > + > +        __clear_bit(X86_FEATURE_FB_CLEAR); > +        if ( cpu_has_fb_clear ) > +            __set_bit(X86_FEATURE_FB_CLEAR); Sure, with that please add my: Reviewed-by: Roger Pau Monné Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Fri Mar 01 19:37:40 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2024 19:37:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687783.1071575 (Exim 4.92) (envelope-from ) id 1rg8hP-00048L-1T; Fri, 01 Mar 2024 19:37:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687783.1071575; Fri, 01 Mar 2024 19:37:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg8hO-00048E-UN; Fri, 01 Mar 2024 19:37:38 +0000 Received: by outflank-mailman (input) for mailman id 687783; Fri, 01 Mar 2024 19:37:38 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg8hN-000488-UL for xen-devel@lists.xenproject.org; Fri, 01 Mar 2024 19:37:38 +0000 Received: from mo4-p01-ob.smtp.rzone.de (mo4-p01-ob.smtp.rzone.de [85.215.255.50]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 2792e4ea-d803-11ee-afd8-a90da7624cb6; Fri, 01 Mar 2024 20:37:35 +0100 (CET) Received: from mail.onlineschubla.de by smtp.strato.de (RZmta 50.2.0 DYNA|AUTH) with ESMTPSA id Q6d30f021JbUCIo (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Fri, 1 Mar 2024 20:37:30 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.onlineschubla.de (Postfix) with ESMTP id C0159212DF; Fri, 1 Mar 2024 20:37:29 +0100 (CET) Received: from mail.onlineschubla.de ([127.0.0.1]) by localhost (mail.onlineschubla.de [127.0.0.1]) (amavis, port 10024) with ESMTP id ix7kuN1XG4ag; Fri, 1 Mar 2024 20:37:28 +0100 (CET) Received: from [10.0.0.105] (unknown [10.0.0.105]) by mail.onlineschubla.de (Postfix) with ESMTPA id 8A54820020; Fri, 1 Mar 2024 20:37:28 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 2792e4ea-d803-11ee-afd8-a90da7624cb6 ARC-Seal: i=1; a=rsa-sha256; t=1709321852; cv=none; d=strato.com; s=strato-dkim-0002; b=ePxYMhOXB4gAjpfsYfIQhpL1wqwQ+ICzN1g/yf7eQtAFC/SggsIQMHm9NHGhDQJhcR 9y8jNmql00h0qYGLl0Rt9VhteFJ7v9naRMip2VG7O0dS0nCsx1O06JXASNhlrHrbkHJM yfPZkG7gysOgOj7IgM6kith2U7Wjk7CKfnyPt8a5m3vCoTdm1O4BUlq5VA9CN2420Mbc xeKmZ5yiF4B0WWmNuknc6DcXO9dMqRpYMbNB5WHqliAuhCLRyt2gfuQyUsVqpWCFSFSg OWccoB9utSIi3OUfl5H0f3d+tNezEuRagBzOllgbO2OWADUsVQ4g2HOxrzaoNXOgs5Hp advA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1709321852; s=strato-dkim-0002; d=strato.com; h=In-Reply-To:From:References:Cc:To:Subject:Date:Message-ID:Cc:Date: From:Subject:Sender; bh=IWlELYAiXQ3U7oDeD4QaXNJ3t+jMzhfgNyOJvwZwup4=; b=fjq8TEdvUICIDuR9rR9Se/D6wVEi1prxHVvedPvDSB6JzLtp3R1FGNkR8RFQE3a4O1 deP7VZMJv7gpvY3sukiS1bRWIEPQU21oFiyw6upysABUkeLzG9GT7/5h0UfLmjXayZF+ 8Ty6LprlDMWk3Qqm25NClxpn8IUWvU06GSxWsBSOY6BMXARUSM6E+gwxsPlesEkqTUtE fjLe5zfklVRU6OriH2DZcvPDxiURHCX165bge2r7+hMpLd2Jw1/LwgFFvzlb+reFTRWh guQP2Gy1RjDrV5K5Xd5rS6IsXs++lAqCqe6CwWsxpRsZqZsrjgukNRxAX+7MCVSLbhKD wSnw== ARC-Authentication-Results: i=1; strato.com; arc=none; dkim=none X-RZG-CLASS-ID: mo01 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1709321852; s=strato-dkim-0002; d=onlineschubla.de; h=In-Reply-To:From:References:Cc:To:Subject:Date:Message-ID:Cc:Date: From:Subject:Sender; bh=IWlELYAiXQ3U7oDeD4QaXNJ3t+jMzhfgNyOJvwZwup4=; b=jeDUrLs+dnjs9Jwih4MsOdMIJrs7IqOic9OjvRUbx0pusPuSd3CQppQUPzFuHDDain YN37M2BrcjGJ1Bnv0rEDSFguG5dCHwoiFSf/Tg/IzCEk12E52/Zo6uo39NL1mvTWKzzq xL3OsLNPFYU9iSRMRbgpAKE8r3Na0d1sdtS4abz8qIoWleCZjWEzJm73GX/S6YtscrTp RfxhwISBYshyMM5nCgnY5a5xbL1S/g17wlzECwvoa4Nqcpz5rizJy1cXfTZ+Y9G3K8xr uVYS8UdyY4yFi+A+0SAQt1Pe6ix4Ih3uB9CJDzxoYSU8iOESnZqIvQgxc9kOoPdg1zIb BIww== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; t=1709321852; s=strato-dkim-0003; d=onlineschubla.de; h=In-Reply-To:From:References:Cc:To:Subject:Date:Message-ID:Cc:Date: From:Subject:Sender; bh=IWlELYAiXQ3U7oDeD4QaXNJ3t+jMzhfgNyOJvwZwup4=; b=m4mF3aJevvL7GZpZUoXOa9xq1UtSKxRTabznJxhqlQnTbcn8UKWln4Em0VTNrs40Vs NO0+qI7G1StoxZa/UXDg== X-RZG-AUTH: ":PG0ReWCndfO3rCSML4AvNaDxJ7WJyilEI/NMX3IPsStZLbcZC9mNZx0oO96cCwacwToyD+C58ign1Q==" X-Virus-Scanned: Debian amavis at onlineschubla.de Message-ID: Date: Fri, 1 Mar 2024 20:37:28 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Xen 4.18rc/ARM64 on Raspberry Pi 4B: Traffic in DomU crashing Dom0 when using VLANs Content-Language: en-US To: Julien Grall , Xen-devel Cc: Stefano Stabellini , george.dunlap@cloud.com, Michal Orzel , Bertrand Marquis References: <838ff75f-1352-4d3c-9bc1-c7a57c828231@onlineschubla.de> <4cddfd89-f195-4a50-a14d-b86121414e56@onlineschubla.de> <4d7dbce9-ef20-4702-8056-9d5ab8152721@onlineschubla.de> From: Paul Leiber In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi, Am 18.02.2024 um 18:49 schrieb Julien Grall: > Hi, > > On 17/02/2024 21:46, Paul Leiber wrote: >> Am 22.01.2024 um 11:46 schrieb George Dunlap: >>> On Fri, Jan 19, 2024 at 8:32 PM Elliott Mitchell >>> wrote: >>>> >>>> On Sun, Jan 14, 2024 at 10:54:24PM +0100, Paul Leiber wrote: >>>>> >>>>> Am 22.10.2023 um 07:42 schrieb Paul Leiber: >>>>>> Am 13.10.2023 um 20:56 schrieb Paul Leiber: >>>>>>> Hi Xen developers list, >>>>>>> >>>>>>> TL;DR: >>>>>>> ------ >>>>>>> >>>>>>> Causing certain web server traffic on a secondary VLAN on >>>>>>> Raspberry Pi >>>>>>> under vanilla Debian/UEFI in combination with Xen leads to complete >>>>>>> system reboot (watchdog triggering for Dom0). Other strange >>>>>>> things are >>>>>>> happening. >>>>>>> >>>>>>> Description: >>>>>>> ---------- >>>>>>> >>>>>>> I recently set up Xen (self compiled, Version 4.18-rc) on a >>>>>>> Raspberry >>>>>>> Pi 4B (on vanilla Debian Bookworm, UEFI boot mode). Until some time >>>>>>> ago, everything worked well with Dom0, one DomU and one bridge. >>>>>>> >>>>>>> Then I wanted to actually make use of the virtualization and started >>>>>>> to set up a second Debian Bookworm DomU (using xen-create-image) for >>>>>>> monitoring my systems with zabbix (a webserver based system >>>>>>> monitoring >>>>>>> solution). The bridge used for this setup was the device bridging >>>>>>> the >>>>>>> hardware NIC. I installed zabbix, set it up, and everything went >>>>>>> well, >>>>>>> I could access the web interface without any problem. >>>>>>> >>>>>>> Then I set up VLANs (initally using VLAN numbers 1 and 2) to >>>>>>> separate >>>>>>> network traffic between the DomUs. I made the existing device bridge >>>>>>> VLAN 1 (bridge 1) and created a secondary device for bridging VLAN 2 >>>>>>> (bridge 2). Using only bridge 1 / VLAN 1 everything works well, I >>>>>>> can >>>>>>> access the zabbix web interface without any noticeable issue. After >>>>>>> switching the zabbix DomU to VLAN 2 / bridge 2, everything seemingly >>>>>>> keeps on working well, I can ping different devices in my network >>>>>>> from >>>>>>> the zabbix DomU and vice versa, I can ssh into the machine. >>>>>>> >>>>>>> However, as soon as I remotely access the zabbix web interface, the >>>>>>> complete system (DomUs and Dom0) becomes unresponsive and reboots >>>>>>> after some time (usually seconds, sometimes 1-2 minutes). The reboot >>>>>>> is reliably reproducable. >>>>>>> >>>>>>> I didn't see any error message in any log (zabbix, DomU syslog, Dom0 >>>>>>> syslog) except for the following lines immediately before the system >>>>>>> reboots on the Xen serial console: >>>>>>> >>>>>>> (XEN) Watchdog timer fired for domain 0 >>>>>>> (XEN) Hardware Dom0 shutdown: watchdog rebooting machine >>>>>>> >>>>>>> As soon as I change the bridge to bridge 1 (with or without VLAN >>>>>>> setup), the web interface is accessible again after booting the >>>>>>> zabbix >>>>>>> DomU, no reboots. >>>>>>> >>>>>>> So I assume that causing specific traffic on the virtual NIC when >>>>>>> using a VLAN setup with more than one VLAN under Xen makes the Dom0 >>>>>>> system hard crash. Of course, there might be other causes that >>>>>>> I'm not >>>>>>> aware of, but to me, this seems to be the most likely explanation >>>>>>> right now. >>>>>>> >>>>>>> What I tried: >>>>>>> ------------- >>>>>>> >>>>>>> 1. I changed the VLAN numbers. First to 101, 102, 103 etc. This was >>>>>>> when I noticed another strange thing: VLANs with numbers >99 simply >>>>>>> don't work on my Raspberry Pi under Debian, with or without Xen. >>>>>>> VLAN >>>>>>> 99 works, VLAN 100 (or everything else >99 that I tried) doesn't >>>>>>> work. >>>>>>> If I choose a number >99, the VLAN is not configured, "ip a" doesn't >>>>>>> list it. Other Debian systems on x64 architecture don't show this >>>>>>> behavior, there, it was no problem to set up VLANs > 99. Therefore, >>>>>>> I've changed the VLANs to 10, 20, 30 etc., which worked. But it >>>>>>> didn't >>>>>>> solve the initial problem of the crashing Dom0 and DomUs. >>>>>>> >>>>>>> 2. Different bridge options, without noticable effect: >>>>>>> bridge_stp off      # dont use STP (spanning tree proto) >>>>>>> bridge_waitport 0   # dont wait for port to be available >>>>>>> bridge_fd 0         # no forward delay >>>>>>> >>>>>>> 3. Removing IPv6: No noticable effect. >>>>>>> >>>>>>> 4. Network traffic analysis: Now, here it becomes _really_ >>>>>>> strange. I >>>>>>> started tcpdumps on Dom0, and depending on on which interface/bridge >>>>>>> traffic was logged, the problem went away, meaning, the DomU was >>>>>>> running smoothly for hours, even when accessing the zabbix web >>>>>>> interface. Stopping the log makes the system crash (as above, after >>>>>>> seconds up to 1-2 minutes) reproducably if I access the zabbix web >>>>>>> interface. >>>>>>> >>>>>>> Logging enabcm6e4ei0 (NIC): no crashes >>>>>>> Logging enabcm6e4ei0.10 (VLAN 10): instant crash >>>>>>> Logging enabcm6e4ei0.20 (VLAN 20): no crashes >>>>>>> Logging xenbr0 (on VLAN 10): instant crash >>>>>>> Logging xenbr1 (on VLAN 20): no crashes >>>>>>> >>>>>>> I am clinging to the thought that there must be a rational >>>>>>> explanation >>>>>>> for why logging the traffic on certain interfaces/bridges should >>>>>>> avoid >>>>>>> the crash of the complete system, while logging other >>>>>>> interfaces/bridges doesn't. I myself can't think of one. >>>>>>> >>>>>>> I checked the dumps of enabcm6e4ei0.10 and xenbr0 (where the system >>>>>>> crashes) with wireshark, nothing sticks out to me (but I am >>>>>>> really no >>>>>>> expert in analyzing network traffic). Dumps can be provided. >>>>>>> >>>>>>> 5. Watchdog: I tried to dig deeper into the cause for the watchdog >>>>>>> triggering. However, I didn't find any useful documentation on >>>>>>> the web >>>>>>> on how the watchdog works or how to enable logging. >>>>>>> >>>>>>> 6. Eliminating Xen as cause: I booted the Debian system (which in >>>>>>> Xen >>>>>>> setup would be Dom0) without Xen and set it up to use the VLAN 20 >>>>>>> bridge (the same that leads to a reboot when using it in the >>>>>>> DomU) as >>>>>>> primary network interface. Everything seemed to be working, I could >>>>>>> download large files from the internet without any problem. >>>>>>> Setting up >>>>>>> Zabbix on the base Debian system showed that the same setup >>>>>>> (VLANs 10 >>>>>>> and 20, bridges 1 and 2, using bridge 2 as interface for Zabbix) >>>>>>> without Xen is working reliably, no reboots. This points to some Xen >>>>>>> related component being the root cause, I think. >>>>>>> >>>>>>> 7. Eliminating Apache as root cause: Reloading the Apache starting >>>>>>> page hosted on DomU several times per second didn't lead to a >>>>>>> reboot. >>>>>>> >>>>>>> 8. Recompiling Xen: Independent of which Xen master branch version I >>>>>>> was using (all 4.18), the behavior was the same. I didn't get Xen >>>>>>> working on ARM64/UEFI in version 4.17. >>>>>>> >>>>>>> Current situation:(XEN) d3v0 Unhandled SMC/HVC: 0x84000050 >>>>> (XEN) d3v0 Unhandled SMC/HVC: 0x8600ff01 >>>>> (XEN) d3v0: vGICD: unhandled word write 0x000000ffffffff to ICACTIVER0 >>>>> (XEN) common/grant_table.c:1909:d3v0 Expanding d3 grant table from >>>>> 1 to >>>>> 2 frames >>>>> (XEN) common/grant_table.c:1909:d3v0 Expanding d3 grant table from >>>>> 2 to >>>>> 3 frames >>>>> (XEN) common/grant_table.c:1909:d3v0 Expanding d3 grant table from >>>>> 3 to >>>>> 4 frames >>>>>>> ------------------ >>>>>>> >>>>>>> I am out of ideas what to do next. Everything that was >>>>>>> recommended to >>>>>>> me on xen-users didn't lead to significant insight or solve the >>>>>>> problem. >>>>>>> >>>>>>> I'd appreciate any hints how to troubleshoot this and/or how to >>>>>>> proceed otherwise. >>>>>> >>>>>> O.k., let's try to break that issue down. >>>>>> >>>>>> Firstly, how can I get more information on why the Xen watchdog >>>>>> triggers? Is there documentation? Are there any logs? I couldn't find >>>>>> anything useful with my search skills. >>>>>> >>>>> >>>>> After some delay, I have picked up the Raspberry Pi again, built Xen >>>>> 4.19-unstable, with the same result: Reboot of the complete system >>>>> after >>>>> the Dom0 watchdog triggering when accessing the Zabbix content on a >>>>> webserver on DomU. >>>>> >>>>> I still would like to find out what's going wrong here, but I have no >>>>> idea what to do. I'd appreciate any hint. >>>>> >>>>> Not knowing if it helps, I added Xen logs from boot until Dom0 >>>>> crash/reboot below. >>>>> >>>>> Loading Xen xen ... >>>>> Loading Linux 6.1.0-17-arm64 ... >>>>> Loading initial ramdisk ... >>>>> Using modules provided by bootloader in FDT >>>>> Xen 4.19-unstable (c/s Fri Jan 12 11:54:31 2024 +0000 >>>>> git:1ec3fe1f66-dirty) EFI >>>>> loader >>>>>    Xen 4.19-unstable >>>>> (XEN) Xen version 4.19-unstable (root@lan.onlineschubla.de) (gcc >>>>> (Debian >>>>> 12.2.0- >>>>> >>>>> >>>>>                              14) 12.2.0) debug=y Sun Jan 14 >>>>> 21:46:34 CET 2024 >>>>> (XEN) Latest ChangeSet: Fri Jan 12 11:54:31 2024 +0000 >>>>> git:1ec3fe1f66-dirty >>>>> (XEN) build-id: babb03cb6107fc46f7d8969142ccd6772a1133c3 >>>>> (XEN) Console output is synchronous. >>>>> (XEN) Processor: 00000000410fd083: "ARM Limited", variant: 0x0, part >>>>> 0xd08,rev 0 >>>>> >>>>> >>>>>                                  x3 >>>>> (XEN) 64-bit Execution: >>>>> (XEN)   Processor Features: 0000000000002222 0000000000000000 >>>>> (XEN)     Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32 >>>>> (XEN)     Extensions: FloatingPoint AdvancedSIMD >>>>> (XEN)   Debug Features: 0000000010305106 0000000000000000 >>>>> (XEN)   Auxiliary Features: 0000000000000000 0000000000000000 >>>>> (XEN)   Memory Model Features: 0000000000001124 0000000000000000 >>>>> (XEN)   ISA Features:  0000000000010000 0000000000000000 >>>>> (XEN) 32-bit Execution: >>>>> (XEN)   Processor Features: 0000000000000131:0000000000011011 >>>>> (XEN)     Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle >>>>> (XEN)     Extensions: GenericTimer Security >>>>> (XEN)   Debug Features: 0000000003010066 >>>>> (XEN)   Auxiliary Features: 0000000000000000 >>>>> (XEN)   Memory Model Features: 0000000010201105 0000000040000000 >>>>> (XEN)                          0000000001260000 0000000002102211 >>>>> (XEN)   ISA Features: 0000000002101110 0000000013112111 >>>>> 0000000021232042 >>>>> (XEN)                 0000000001112131 0000000000011142 >>>>> 0000000000010001 >>>>> (XEN) Using SMC Calling Convention v1.2 >>>>> (XEN) Using PSCI v1.1 >>>>> (XEN) ACPI: GICC (acpi_id[0x0000] address[0xff842000] MPIDR[0x0] >>>>> enabled) >>>>> (XEN) ACPI: GICC (acpi_id[0x0001] address[0xff842000] MPIDR[0x1] >>>>> enabled) >>>>> (XEN) ACPI: GICC (acpi_id[0x0002] address[0xff842000] MPIDR[0x2] >>>>> enabled) >>>>> (XEN) ACPI: GICC (acpi_id[0x0003] address[0xff842000] MPIDR[0x3] >>>>> enabled) >>>>> (XEN) 4 CPUs enabled, 4 CPUs total >>>>> (XEN) SMP: Allowing 4 CPUs >>>>> (XEN) enabled workaround for: ARM erratum 1319537 >>>>> (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 54000 KHz >>>>> (XEN) GICv2 initialization: >>>>> (XEN)         gic_dist_addr=00000000ff841000 >>>>> (XEN)         gic_cpu_addr=00000000ff842000 >>>>> (XEN)         gic_hyp_addr=00000000ff844000 >>>>> (XEN)         gic_vcpu_addr=00000000ff846000 >>>>> (XEN)         gic_maintenance_irq=25 >>>>> (XEN) GICv2: 256 lines, 4 cpus, secure (IID 0200143b). >>>>> (XEN) XSM Framework v1.0.1 initialized >>>>> (XEN) Initialising XSM SILO mode >>>>> (XEN) Using scheduler: SMP Credit Scheduler rev2 (credit2) >>>>> (XEN) Initializing Credit2 scheduler >>>>> (XEN)  load_precision_shift: 18 >>>>> (XEN)  load_window_shift: 30 >>>>> (XEN)  underload_balance_tolerance: 0 >>>>> (XEN)  overload_balance_tolerance: -3 >>>>> (XEN)  runqueues arrangement: socket >>>>> (XEN)  cap enforcement granularity: 10ms >>>>> (XEN) load tracking window length 1073741824 ns >>>>> (XEN) Allocated console ring of 32 KiB. >>>>> (XEN) CPU0: Guest atomics will try 16 times before pausing the domain >>>>> (XEN) Bringing up CPU1 >>>>> (XEN) CPU1: Guest atomics will try 16 times before pausing the domain >>>>> (XEN) CPU 1 booted. >>>>> (XEN) Bringing up CPU2 >>>>> (XEN) CPU2: Guest atomics will try 13 times before pausing the domain >>>>> (XEN) CPU 2 booted. >>>>> (XEN) Bringing up CPU3 >>>>> (XEN) CPU3: Guest atomics will try 16 times before pausing the domain >>>>> (XEN) Brought up 4 CPUs >>>>> (XEN) CPU 3 booted. >>>>> (XEN) I/O virtualisation disabled >>>>> (XEN) P2M: 44-bit IPA with 44-bit PA and 8-bit VMID >>>>> (XEN) P2M: 4 levels with order-0 root, VTCR 0x0000000080043594 >>>>> (XEN) Scheduling granularity: cpu, 1 CPU per sched-resource >>>>> (XEN) Initializing Credit2 scheduler >>>>> (XEN)  load_precision_shift: 18 >>>>> (XEN)  load_window_shift: 30 >>>>> (XEN)  underload_balance_tolerance: 0 >>>>> (XEN)  overload_balance_tolerance: -3 >>>>> (XEN)  runqueues arrangement: socket >>>>> (XEN)  cap enforcement granularity: 10ms >>>>> (XEN) load tracking window length 1073741824 ns >>>>> (XEN) Adding cpu 0 to runqueue 0 >>>>> (XEN)  First cpu on runqueue, activating >>>>> (XEN) Adding cpu 1 to runqueue 0 >>>>> (XEN) Adding cpu 2 to runqueue 0 >>>>> (XEN) Adding cpu 3 to runqueue 0 >>>>> (XEN) alternatives: Patching with alt table 00000a00002ee0b0 -> >>>>> 00000a00002ef250 >>>>> (XEN) CPU2 will call ARM_SMCCC_ARCH_WORKAROUND_1 on exception entry >>>>> (XEN) CPU1 will call ARM_SMCCC_ARCH_WORKAROUND_1 on exception entry >>>>> (XEN) CPU3 will call ARM_SMCCC_ARCH_WORKAROUND_1 on exception entry >>>>> (XEN) CPU0 will call ARM_SMCCC_ARCH_WORKAROUND_1 on exception entry >>>>> (XEN) *** LOADING DOMAIN 0 *** >>>>> (XEN) Loading d0 kernel from boot module @ 0000000030ef7000 >>>>> (XEN) Loading ramdisk from boot module @ 000000002ee6d000 >>>>> (XEN) Allocating 1:1 mappings totalling 1024MB for dom0: >>>>> (XEN) BANK[0] 0x00000040000000-0x00000080000000 (1024MB) >>>>> (XEN) Grant table range: 0x0000002eceb000-0x0000002ed2b000 >>>>> (XEN) Allocating PPI 16 for event channel interrupt >>>>> (XEN) Loading zImage from 0000000030ef7000 to >>>>> 0000000040000000-0000000041f1c7c0 >>>>> (XEN) Loading d0 initrd from 000000002ee6d000 to >>>>> 0x0000000048200000-0x000000004a >>>>> >>>>> >>>>>                                                      288c22 >>>>> (XEN) Loading d0 DTB to 0x0000000048000000-0x00000000480002c3 >>>>> (XEN) Initial low memory virq threshold set at 0x4000 pages. >>>>> (XEN) Scrubbing Free RAM in background >>>>> (XEN) Std. Loglevel: All >>>>> (XEN) Guest Loglevel: All >>>>> (XEN) *************************************************** >>>>> (XEN) WARNING: CONSOLE OUTPUT IS SYNCHRONOUS >>>>> (XEN) This option is intended to aid debugging of Xen by ensuring >>>>> (XEN) that all output is synchronously delivered on the serial line. >>>>> (XEN) However it can introduce SIGNIFICANT latencies and affect >>>>> (XEN) timekeeping. It is NOT recommended for production use! >>>>> (XEN) *************************************************** >>>>> (XEN) 3... 2... 1... >>>>> (XEN) *** Serial input to DOM0 (type 'CTRL-a' three times to switch >>>>> input) >>>>> (XEN) Freed 376kB init memory. >>>>> (XEN) d0v0 Unhandled SMC/HVC: 0x84000050 >>>>> (XEN) d0v0 Unhandled SMC/HVC: 0x8600ff01 >>>>> (XEN) d0v0: vGICD: unhandled word write 0x000000ffffffff to ICACTIVER4 >>>>> (XEN) d0v0: vGICD: unhandled word write 0x000000ffffffff to ICACTIVER8 >>>>> (XEN) d0v0: vGICD: unhandled word write 0x000000ffffffff to >>>>> ICACTIVER12 >>>>> (XEN) d0v0: vGICD: unhandled word write 0x000000ffffffff to >>>>> ICACTIVER16 >>>>> (XEN) d0v0: vGICD: unhandled word write 0x000000ffffffff to >>>>> ICACTIVER20 >>>>> (XEN) d0v0: vGICD: unhandled word write 0x000000ffffffff to >>>>> ICACTIVER24 >>>>> (XEN) d0v0: vGICD: unhandled word write 0x000000ffffffff to >>>>> ICACTIVER28 >>>>> (XEN) d0v0: vGICD: unhandled word write 0x000000ffffffff to ICACTIVER0 >>>>> (XEN) d0v1: vGICD: unhandled word write 0x000000ffffffff to ICACTIVER0 >>>>> (XEN) d0v2: vGICD: unhandled word write 0x000000ffffffff to ICACTIVER0 >>>>> (XEN) d0v3: vGICD: unhandled word write 0x000000ffffffff to ICACTIVER0 >>>>> (XEN) d1v0 Unhandled SMC/HVC: 0x84000050 >>>>> (XEN) d1v0 Unhandled SMC/HVC: 0x8600ff01 >>>>> (XEN) d1v0: vGICD: unhandled word write 0x000000ffffffff to ICACTIVER0 >>>>> (XEN) common/grant_table.c:1909:d1v0 Expanding d1 grant table from >>>>> 1 to >>>>> 2 frames >>>>> (XEN) gnttab_mark_dirty not implemented yet >>>>> (XEN) d2v0 Unhandled SMC/HVC: 0x84000050 >>>>> (XEN) d2v0 Unhandled SMC/HVC: 0x8600ff01 >>>>> (XEN) d2v0: vGICD: unhandled word write 0x000000ffffffff to ICACTIVER0 >>>>> (XEN) common/grant_table.c:1909:d2v0 Expanding d2 grant table from >>>>> 1 to >>>>> 2 frames >>>>> (XEN) common/grant_table.c:1909:d2v0 Expanding d2 grant table from >>>>> 2 to >>>>> 3 frames >>>>> (XEN) common/grant_table.c:1909:d2v0 Expanding d2 grant table from >>>>> 3 to >>>>> 4 frames >>>>> (XEN) Watchdog timer fired for domain 0 >>>>> (XEN) Hardware Dom0 shutdown: watchdog rebooting machine >>>> >>>> I'm unsure whose attention to draw to this report. >>>> >>>> This might be a scheduler issue since the watchdog timer is triggering. >>>> >>>> This might be an ACPI issue as ACPI is in use here. >>>> >>>> This might be an ARM Linux kernel issue. >>>> >>>> In the end this is someone running into trouble with Xen on an ARM >>>> device.  Yet despite bringing up the issue hasn't gotten any help... >>> >>> Hey Elliot, >>> >>> Thanks for raising the visibility of this.  I'm not familiar with ARM, >>> but if I were investigating this I'd try to figure out what the >>> "unhandled" error messages are.  "gnttab_mark_dirty not implemented >>> yet" looks pretty sus too, and also sounds like it might be something >>> ARM-specific. >>> >>> I don't see anything suspicious WRT the scheduler, but a simple way to >>> test that would be to set the scheduler to credit1 and see if that >>> changes things. >> >> Just to rule out all possibilities, I did a test with credit(1) >> scheduler, which didn't change anything noticable. The watchdog >> triggered after traffic has been created on the VLAN. > > Thanks for trying. Looking at the watchdog code, sadly, it doesn't seem > to do much logging or even dump some information (e.g. stack trace) when > it get triggers. > > To answer your previous question about the watchdog, it is a daemon that > is running in the domain (in your case dom0). The only thing it will do > is every N secs (default 15 seconds), it will tell Xen that it is still > alive. If the domain has answered after M (default 30 seconds), then the > domain will be considered as unresponsive and Xen will shutdown it down. > > If this is dom0, then the whole system will shutdown. As the others > hinted, this is likely a sign that your domain deadlock or is overloaded. > > Have you tried to disable the watchdog and check the liveness of dom0? I > don't expect to solve your issue, but it could help to get some further > information out of the system before rebooting. The service is called > xen-watchdog. > > If dom0 is partially stuck, then I would expect the kernel to start > printing some RCU stall after a few seconds. > > If you have access to the console you can press CTRL + A three times. > This will switch to Xen console where you can ask to print more > information. 'h' will give you the list of all the keys supported. > > I think, the keys '0' and 'q' would print useful information in your case. > > Cheers, > Stopping xen-watchdog prevents the reboot. However, when triggering traffic on the VLAN, Dom0 and DomU become completely unresponsive. No error or kernel message is printed in the serial console. Switching to Xen console works. Pressing '0' produces the following output: (XEN) '0' pressed -> dumping Dom0's registers (XEN) *** Dumping Dom0 vcpu#0 state: *** (XEN) ----[ Xen-4.19-unstable arm64 debug=y Tainted: C ]---- (XEN) CPU: 0 (XEN) PC: ffff800008027e50 (XEN) LR: ffff800008027e44 (XEN) SP_EL0: ffff800009c78f80 (XEN) SP_EL1: ffff800008003b60 (XEN) CPSR: 00000000000003c5 MODE:64-bit EL1h (Guest Kernel, handler) (XEN) X0: 0000000000000001 X1: 0000000000000003 X2: 0000000000000000 (XEN) X3: ffff800009c6eb08 X4: ffff800009c6ea88 X5: 0000000000000000 (XEN) X6: 000000000001964d X7: 0000000070000000 X8: 00000000000178a7 (XEN) X9: ffff800008027e44 X10: 00000000000005ee X11: 0000000000000001 (XEN) X12: ffff800009c6ebb0 X13: 0000000000000000 X14: 0000000000000000 (XEN) X15: 0000000000000000 X16: ffff800008000000 X17: ffff800076596000 (XEN) X18: 0000000000000000 X19: ffff8000097c2008 X20: ffff000042126c80 (XEN) X21: ffff8000097c2008 X22: 0000000000000000 X23: 0000000000000005 (XEN) X24: ffff8000097c2008 X25: ffff0000483309f8 X26: ffff800076596000 (XEN) X27: ffff800009c67000 X28: ffff800009c78f80 FP: ffff800008003b60 (XEN) (XEN) ELR_EL1: ffff800008cad668 (XEN) ESR_EL1: 56000000 (XEN) FAR_EL1: 0000ffffa8ff7e48 (XEN) (XEN) SCTLR_EL1: 0000000034d4d91d (XEN) TCR_EL1: 00000074b5503510 (XEN) TTBR0_EL1: 0000000046cd1000 (XEN) TTBR1_EL1: 0a34000041612000 (XEN) (XEN) VTCR_EL2: 0000000080043594 (XEN) VTTBR_EL2: 00010001fffac000 (XEN) (XEN) SCTLR_EL2: 0000000030cd183d (XEN) HCR_EL2: 00000000807c663f (XEN) TTBR0_EL2: 000000002ee24000 (XEN) (XEN) ESR_EL2: 0000000007e00000 (XEN) HPFAR_EL2: 0000000000ff8410 (XEN) FAR_EL2: ffff800008005f00 (XEN) (XEN) Guest stack trace from sp=ffff800008003b60: (XEN) Failed to convert stack to physical address (XEN) *** Dumping Dom0 vcpu#1 state: *** (XEN) ----[ Xen-4.19-unstable arm64 debug=y Tainted: C ]---- (XEN) CPU: 0 (XEN) PC: ffff800008c5dc80 (XEN) LR: ffff800008c5dc88 (XEN) SP_EL0: ffff000042272080 (XEN) SP_EL1: ffff80000800b0e0 (XEN) CPSR: 0000000080000305 MODE:64-bit EL1h (Guest Kernel, handler) (XEN) X0: 0000000000001c7a X1: ffff80000800b0e0 X2: 0000000000000001 (XEN) X3: 0000000000000000 X4: 0000000000000000 X5: ffff00007fd78ad0 (XEN) X6: 0000000000000001 X7: c0000000ffffefff X8: 0000000000017fe8 (XEN) X9: ffff800008c5dc4c X10: ffff800009cf0a78 X11: 00000000ffffefff (XEN) X12: 0720072007200720 X13: 0720072007200720 X14: 0720072007200720 (XEN) X15: 0720072007200720 X16: 65206c6174614620 X17: 6e6f697470656378 (XEN) X18: 0000000000000006 X19: 000000000000d2f0 X20: ffff8000090ebf50 (XEN) X21: 000000060197033e X22: fffffff9fe6911da X23: 0000000000000023 (XEN) X24: 0000000000418958 X25: 0000000000000001 X26: 0000000000000000 (XEN) X27: 0000000000000000 X28: ffff000042272080 FP: ffff80000800b0e0 (XEN) (XEN) ELR_EL1: ffff800008c5dc80 (XEN) ESR_EL1: f2000800 (XEN) FAR_EL1: 0000aaaaf011c000 (XEN) (XEN) SCTLR_EL1: 0000000034d4d91d (XEN) TCR_EL1: 00000074b5503510 (XEN) TTBR0_EL1: 0000000046cd1000 (XEN) TTBR1_EL1: 0a34000041612000 (XEN) (XEN) VTCR_EL2: 0000000080043594 (XEN) VTTBR_EL2: 00010001fffac000 (XEN) (XEN) SCTLR_EL2: 0000000030cd183d (XEN) HCR_EL2: 00000000807c663f (XEN) TTBR0_EL2: 000000002ee24000 (XEN) (XEN) ESR_EL2: 0000000007e00001 (XEN) HPFAR_EL2: 0000000000ff8410 (XEN) FAR_EL2: ffff800008005f00 (XEN) (XEN) Guest stack trace from sp=ffff80000800b0e0: (XEN) Failed to convert stack to physical address (XEN) *** Dumping Dom0 vcpu#2 state: *** (XEN) ----[ Xen-4.19-unstable arm64 debug=y Tainted: C ]---- (XEN) CPU: 0 (XEN) PC: ffff800008027e50 (XEN) LR: ffff800008027e44 (XEN) SP_EL0: ffff000042271040 (XEN) SP_EL1: ffff800009fcbf20 (XEN) CPSR: 00000000000003c5 MODE:64-bit EL1h (Guest Kernel, handler) (XEN) X0: 0000000000000001 X1: 0000000000000002 X2: 0000000000000000 (XEN) X3: ffff800009c6eb08 X4: ffff800009c6ea88 X5: 0000000000000000 (XEN) X6: 0000000000009c40 X7: 00003d08ffff63c0 X8: 003d090ce9e9e665 (XEN) X9: ffff800008027e44 X10: 0000000000000008 X11: 0000000000000000 (XEN) X12: 003d090ce9e9e665 X13: fffffffff7ed551f X14: 0000000000034bc0 (XEN) X15: 00003d090ce92d00 X16: ffff800009fc8000 X17: ffff8000765d2000 (XEN) X18: 0000000000000000 X19: ffff8000097c2008 X20: ffff000042126c80 (XEN) X21: ffff8000097c2008 X22: 0000000000000002 X23: 0000000040000005 (XEN) X24: 0000000000000000 X25: 0000000000000000 X26: ffff000042271040 (XEN) X27: 0000000000000000 X28: ffff000042271040 FP: ffff800009fcbf20 (XEN) (XEN) ELR_EL1: ffff800008c9df8c (XEN) ESR_EL1: 56000000 (XEN) FAR_EL1: 0000ffff280c2020 (XEN) (XEN) SCTLR_EL1: 0000000034d4d91d (XEN) TCR_EL1: 00000074b5503510 (XEN) TTBR0_EL1: 000000004613e000 (XEN) TTBR1_EL1: 0d88000041612000 (XEN) (XEN) VTCR_EL2: 0000000080043594 (XEN) VTTBR_EL2: 00010001fffac000 (XEN) (XEN) SCTLR_EL2: 0000000030cd183d (XEN) HCR_EL2: 00000000807c663f (XEN) TTBR0_EL2: 000000002ee24000 (XEN) (XEN) ESR_EL2: 0000000007e00000 (XEN) HPFAR_EL2: 0000000000ff8410 (XEN) FAR_EL2: ffff800008005f00 (XEN) (XEN) Guest stack trace from sp=ffff800009fcbf20: (XEN) Failed to convert stack to physical address (XEN) *** Dumping Dom0 vcpu#3 state: *** (XEN) ----[ Xen-4.19-unstable arm64 debug=y Tainted: C ]---- (XEN) CPU: 0 (XEN) PC: ffff800008027e50 (XEN) LR: ffff800008027e44 (XEN) SP_EL0: ffff0000422730c0 (XEN) SP_EL1: ffff800009fd3f20 (XEN) CPSR: 00000000000003c5 MODE:64-bit EL1h (Guest Kernel, handler) (XEN) X0: 0000000000000001 X1: 0000000000000001 X2: 0000000000000000 (XEN) X3: ffff800009c6eb08 X4: ffff800009c6ea88 X5: 0000000000000000 (XEN) X6: 0000000157ebd3d8 X7: 0000000000000000 X8: ffff000042273cd0 (XEN) X9: ffff800008027e44 X10: 0000000000000bb0 X11: 0000000000000001 (XEN) X12: ffff800009c6ebb0 X13: 0000000000000030 X14: ffffffffffffffff (XEN) X15: ffff80000b809000 X16: ffff800009fd0000 X17: ffff8000765f0000 (XEN) X18: ffff8000090e2000 X19: ffff8000097c2008 X20: ffff000042126c80 (XEN) X21: ffff8000097c2008 X22: 0000000000000003 X23: 0000000040000005 (XEN) X24: 0000000000000000 X25: 0000000000000000 X26: ffff0000422730c0 (XEN) X27: 0000000000000000 X28: ffff0000422730c0 FP: ffff800009fd3f20 (XEN) (XEN) ELR_EL1: ffff800008c9df8c (XEN) ESR_EL1: 56000000 (XEN) FAR_EL1: 0000aaaaf011c000 (XEN) (XEN) SCTLR_EL1: 0000000034d4d91d (XEN) TCR_EL1: 00000074b5503510 (XEN) TTBR0_EL1: 00000000463ad000 (XEN) TTBR1_EL1: 0d8a000041612000 (XEN) (XEN) VTCR_EL2: 0000000080043594 (XEN) VTTBR_EL2: 00010001fffac000 (XEN) (XEN) SCTLR_EL2: 0000000030cd183d (XEN) HCR_EL2: 00000000807c663f (XEN) TTBR0_EL2: 000000002ee24000 (XEN) (XEN) ESR_EL2: 0000000007e00000 (XEN) HPFAR_EL2: 0000000000ff8410 (XEN) FAR_EL2: ffff800008005f00 (XEN) (XEN) Guest stack trace from sp=ffff800009fd3f20: (XEN) Failed to convert stack to physical address Pressing 'q' produces the following output: (XEN) 'q' pressed -> dumping domain info (now = 727929105981) (XEN) General information for domain 0: (XEN) refcnt=3 dying=0 pause_count=0 (XEN) nr_pages=262144 xenheap_pages=2 dirty_cpus={} max_pages=262144 (XEN) handle=00000000-0000-0000-0000-000000000000 vm_assist=00000020 (XEN) p2m mappings for domain 0 (vmid 1): (XEN) 1G mappings: 0 (shattered 1) (XEN) 2M mappings: 422 (shattered 90) (XEN) 4K mappings: 45372 (XEN) Rangesets belonging to domain 0: (XEN) Interrupts { 32-152, 154-255 } (XEN) I/O Memory { 0-fe200, fe203-ff841, ff849-ffffffffffffffff } (XEN) NODE affinity for domain 0: [0] (XEN) VCPU information and callbacks for domain 0: (XEN) UNIT0 affinities: hard={0-3} soft={0-3} (XEN) VCPU0: CPU3 [has=F] poll=0 upcall_pend=01 upcall_mask=01 (XEN) pause_count=0 pause_flags=1 (XEN) GICH_LRs (vcpu 0) mask=f (XEN) VCPU_LR[0]=2a000002 (XEN) VCPU_LR[1]=1a00001b (XEN) VCPU_LR[2]=1a000001 (XEN) VCPU_LR[3]=1a000010 (XEN) Inflight irq=2 lr=0 (XEN) Inflight irq=27 lr=1 (XEN) Inflight irq=1 lr=2 (XEN) Inflight irq=16 lr=3 (XEN) No periodic timer (XEN) UNIT1 affinities: hard={0-3} soft={0-3} (XEN) VCPU1: CPU1 [has=T] poll=0 upcall_pend=00 upcall_mask=00 (XEN) pause_count=0 pause_flags=0 (XEN) GICH_LRs (vcpu 1) mask=0 (XEN) VCPU_LR[0]=0 (XEN) VCPU_LR[1]=0 (XEN) VCPU_LR[2]=0 (XEN) VCPU_LR[3]=0 (XEN) No periodic timer (XEN) UNIT2 affinities: hard={0-3} soft={0-3} (XEN) VCPU2: CPU1 [has=F] poll=0 upcall_pend=01 upcall_mask=01 (XEN) pause_count=0 pause_flags=1 (XEN) GICH_LRs (vcpu 2) mask=f (XEN) VCPU_LR[0]=2a000002 (XEN) VCPU_LR[1]=1a000001 (XEN) VCPU_LR[2]=1a00001b (XEN) VCPU_LR[3]=1a000010 (XEN) Inflight irq=2 lr=0 (XEN) Inflight irq=1 lr=1 (XEN) Inflight irq=27 lr=2 (XEN) Inflight irq=16 lr=3 (XEN) No periodic timer (XEN) UNIT3 affinities: hard={0-3} soft={0-3} (XEN) VCPU3: CPU3 [has=F] poll=0 upcall_pend=00 upcall_mask=01 (XEN) pause_count=0 pause_flags=1 (XEN) GICH_LRs (vcpu 3) mask=7 (XEN) VCPU_LR[0]=2a000002 (XEN) VCPU_LR[1]=1a00001b (XEN) VCPU_LR[2]=1a000001 (XEN) VCPU_LR[3]=0 (XEN) Inflight irq=2 lr=0 (XEN) Inflight irq=27 lr=1 (XEN) Inflight irq=1 lr=2 (XEN) No periodic timer (XEN) General information for domain 1: (XEN) refcnt=3 dying=0 pause_count=0 (XEN) nr_pages=262148 xenheap_pages=3 dirty_cpus={} max_pages=262400 (XEN) handle=f79da05c-9594-4085-9dd3-08a1197ae443 vm_assist=00000020 (XEN) p2m mappings for domain 1 (vmid 2): (XEN) 1G mappings: 0 (shattered 1) (XEN) 2M mappings: 511 (shattered 1) (XEN) 4K mappings: 519 (XEN) Rangesets belonging to domain 1: (XEN) Interrupts { } (XEN) I/O Memory { } (XEN) NODE affinity for domain 1: [0] (XEN) VCPU information and callbacks for domain 1: (XEN) UNIT0 affinities: hard={0-3} soft={0-3} (XEN) VCPU0: CPU3 [has=T] poll=0 upcall_pend=00 upcall_mask=01 (XEN) pause_count=0 pause_flags=0 (XEN) GICH_LRs (vcpu 0) mask=0 (XEN) VCPU_LR[0]=0 (XEN) VCPU_LR[1]=0 (XEN) VCPU_LR[2]=0 (XEN) VCPU_LR[3]=0 (XEN) Inflight irq=27 lr=0 (XEN) No periodic timer (XEN) General information for domain 2: (XEN) refcnt=3 dying=0 pause_count=0 (XEN) nr_pages=262148 xenheap_pages=5 dirty_cpus={} max_pages=262400 (XEN) handle=8a518bb5-a0f8-47d7-8220-62cc4035c5ed vm_assist=00000020 (XEN) p2m mappings for domain 2 (vmid 3): (XEN) 1G mappings: 0 (shattered 1) (XEN) 2M mappings: 511 (shattered 1) (XEN) 4K mappings: 521 (XEN) Rangesets belonging to domain 2: (XEN) Interrupts { } (XEN) I/O Memory { } (XEN) NODE affinity for domain 2: [0] (XEN) VCPU information and callbacks for domain 2: (XEN) UNIT0 affinities: hard={0-3} soft={0-3} (XEN) VCPU0: CPU2 [has=T] poll=0 upcall_pend=00 upcall_mask=01 (XEN) pause_count=0 pause_flags=0 (XEN) GICH_LRs (vcpu 0) mask=0 (XEN) VCPU_LR[0]=0 (XEN) VCPU_LR[1]=0 (XEN) VCPU_LR[2]=0 (XEN) VCPU_LR[3]=0 (XEN) Inflight irq=27 lr=0 (XEN) No periodic timer (XEN) Notifying guest 0:0 (virq 1, port 0) (XEN) Notifying guest 0:1 (virq 1, port 0) (XEN) Notifying guest 0:2 (virq 1, port 0) (XEN) Notifying guest 0:3 (virq 1, port 0) (XEN) Notifying guest 1:0 (virq 1, port 0) (XEN) Notifying guest 2:0 (virq 1, port 0) Anything specific I should pay attention to? Thanks, Paul From xen-devel-bounces@lists.xenproject.org Fri Mar 01 20:25:12 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2024 20:25:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687793.1071606 (Exim 4.92) (envelope-from ) id 1rg9RK-00026F-LP; Fri, 01 Mar 2024 20:25:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687793.1071606; Fri, 01 Mar 2024 20:25:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg9RK-000268-H6; Fri, 01 Mar 2024 20:25:06 +0000 Received: by outflank-mailman (input) for mailman id 687793; Fri, 01 Mar 2024 20:25:05 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rg9RI-000261-Mn for xen-devel@lists.xenproject.org; Fri, 01 Mar 2024 20:25:05 +0000 Received: from neowutran.ovh (core.neowutran.ovh [51.83.40.211]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id c8a64ffd-d809-11ee-afd8-a90da7624cb6; Fri, 01 Mar 2024 21:25:03 +0100 (CET) Received: from neowutran.ovh (maisonhome.neowutran.ovh [82.65.3.49]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by neowutran.ovh (Postfix) with ESMTPSA id 0E3EB61294; Fri, 1 Mar 2024 20:25:01 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c8a64ffd-d809-11ee-afd8-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=neowutran.ovh; s=mail; t=1709324701; bh=aBzntxj8KXmquB5SuuEJ6uhNlrgNKsqUvjbkWtV3rM4=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=XfW7SoC/6OeafIOUwfDzDrpOpwlMPPNsPEB0jrrxu73vYk8wC2Z3K38FJCzw0zOkS W8ePslNKV+0xbr51WZJMfkPAREKtWN1Mzs15A0K3BxFNAvRJ9IJawraS9scAnc2Imr Q+fCeZ+bthuxaAo4f+vJ3BOo4jYvJhoThzhxfnGIVKUXZg4XYM8a7I5zvoviCmO1A3 3bfoGvq13Eqpr9rwYQRzn0cSJ32ZscVu/w4Y72Lsw6vfdKaIMU/HKAt1366GxThh0k tmfnd8atfye4GTw9aBpAMiAPbi6kXWkLkpXJIAb27kR+9YdY5ZU2ZVFiI6ItqyyF00 J24/pcpiC2qvxjLtXbzvE1WbbIfXT3KTr4JF8mLGdOiZfAo0k9+UHkQ/JrDwBhJcux q3+/1xoXMscl/Ja9/LYYbsnRPzKeu06ZChxp11IW20CMtYz1RMtYMH/z9xCZxDlWBR ptqifV90rP5eqSB8xFVUw5ATd33I/MBiLnkB880g5K4+3IWD7NhxD5edUJDA0buNmI tlrKkFdKfOXtrrXthTabBvm/4xoxoMMyOv4H1BTc1NQ802XA989TCu3Ts7bqwcmrsP OMz8z08nDoiFCFSmeAaCoSk1hABiJecaq97/tIhGkgDx5TQiICxqPthKHwVYGkOSRF CLNlz7rTxq//ljH1h056DvX4= Date: Fri, 1 Mar 2024 21:24:48 +0100 From: Neowutran To: Jan Beulich Cc: Neowutran , xen-devel@lists.xenproject.org, Anthony Perard , George Dunlap Subject: Re: hvmloader - allow_memory_relocate overlaps Message-ID: References: <7oe275z3eap7rhdwmrm4mvqnjnhrpag5cjwnfvwsf7rchhkyjv@pd3abzwdhg6v> <217649a9-8399-48d3-ba49-ae22cacf0d4b@suse.com> <1c857c96-9f2d-4787-8804-799a63a00480@suse.com> <7lhrvh2ad46gjke5kvy4pbvrhstv7ihwm64suqrkle4v43tos6@oktohrjfupkc> <6db70696-4b40-46d2-b19c-881820338ba4@suse.com> <56c24b5b-42a0-4022-bb14-f90a3881fdc1@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <56c24b5b-42a0-4022-bb14-f90a3881fdc1@suse.com> On 2024-02-07 16:02, Jan Beulich wrote: > On 04.01.2024 14:16, Jan Beulich wrote: > > On 22.12.2023 16:49, Neowutran wrote: > >> Full logs without my patch to set allow-memory-relocate (https://github.com/neowutran/qubes-vmm-xen/blob/allowmemoryrelocate/ALLOWMEMORYRELOCATE.patch) > >> https://pastebin.com/g > >> QGg55WZ > >> (GPU passthrough doesn't work, hvmloader overlaps with guest memory) > > > > So there are oddities, but I can't spot any overlaps. What's odd is that > > the two blocks already above 4Gb are accounted for (and later relocated) > > when calculating total MMIO size. BARs of size 2Gb and more shouldn't be > > accounted for at all when deciding whether low RAM needs relocating, as > > those can't live below 4Gb anyway. I vaguely recall pointing this out > > years ago, but it was thought we'd get away for a fair while. What's > > further odd is where the two blocks are moved to: F800000 moves (down) > > to C00000, while the smaller FC00000 moves further up to FC80000. > > > > I'll try to get to addressing at least the first oddity; if I can figure > > out why the second one occurs, I may try to address that as well. > > Could you give the patch below a try? I don't have a device with large > enough a BAR that I could sensibly pass through to a guest, so I was > only able to build-test the change. Hi and thanks, I just tested it, it indeed work well when the GPU have bar > 1Go. ------------ Setup: I removed my patch ( --- a/tools/libs/light/libxl_dm.c +++ b/tools/libs/light/libxl_dm.c @@ -2431,6 +2431,10 @@ void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state *sdss) libxl__xs_get_dompath(gc, guest_domid)), "%s", libxl_bios_type_to_string(guest_config->b_info.u.hvm.bios)); + libxl__xs_printf(gc, XBT_NULL, + libxl__sprintf(gc, "%s/hvmloader/allow-memory-relocate", libxl__xs_get_dompath(gc, guest_domid)), + "%d", + 0); } ret = xc_domain_set_target(ctx->xch, dm_domid, guest_domid); if (ret<0) { ) and applied your suggested "skip huge BARs" patch. My GPU: nvidia 4080 ------------- When the option "Resizable BAR support" is activated in my bios, the BAR1 size of my gpu is reported to be 16GB. With this patch, gpu passthrough work. When the option "Resizable BAR support" is desactivated in my bios, the BAR1 size of my gpu is reported to be 256MB. With this patch, gpu passthrough doesn't work (same crash as before) ( note: the option "Resizable BAR support" may or may not exist depending on the motherboard model, on some it is 'hardcoded' to activated, on some it is 'hardcoded' to desactivated) > Jan > > hvmloader/PCI: skip huge BARs in certain calculations > > BARs of size 2Gb and up can't possibly fit below 4Gb: Both the bottom of > the lower 2Gb range and the top of the higher 2Gb range have special > purpose. Don't even have them influence whether to (perhaps) relocate > low RAM. > > Reported-by: Neowutran > Signed-off-by: Jan Beulich > --- > If we wanted to fit e.g. multiple 1Gb BARs, it would likely be prudent > to similarly avoid low RAM relocation in the first place. Yet accounting > for things differently depending on many large BARs there are would > require more intrusive code changes. > > That said, I'm open to further lowering of the threshold. That'll > require different justification then, though. > > --- a/tools/firmware/hvmloader/pci.c > +++ b/tools/firmware/hvmloader/pci.c > @@ -33,6 +33,13 @@ uint32_t pci_mem_start = HVM_BELOW_4G_MM > const uint32_t pci_mem_end = RESERVED_MEMBASE; > uint64_t pci_hi_mem_start = 0, pci_hi_mem_end = 0; > > +/* > + * BARs larger than this value are put in 64-bit space unconditionally. That > + * is, such BARs also don't play into the determination of how big the lowmem > + * MMIO hole needs to be. > + */ > +#define HUGE_BAR_THRESH GB(1) > + > enum virtual_vga virtual_vga = VGA_none; > unsigned long igd_opregion_pgbase = 0; > > @@ -286,9 +293,11 @@ void pci_setup(void) > bars[i].bar_reg = bar_reg; > bars[i].bar_sz = bar_sz; > > - if ( ((bar_data & PCI_BASE_ADDRESS_SPACE) == > - PCI_BASE_ADDRESS_SPACE_MEMORY) || > - (bar_reg == PCI_ROM_ADDRESS) ) > + if ( is_64bar && bar_sz > HUGE_BAR_THRESH ) > + bar64_relocate = 1; > + else if ( ((bar_data & PCI_BASE_ADDRESS_SPACE) == > + PCI_BASE_ADDRESS_SPACE_MEMORY) || > + (bar_reg == PCI_ROM_ADDRESS) ) > mmio_total += bar_sz; > > nr_bars++; > @@ -367,7 +376,7 @@ void pci_setup(void) > pci_mem_start = hvm_info->low_mem_pgend << PAGE_SHIFT; > } > > - if ( mmio_total > (pci_mem_end - pci_mem_start) ) > + if ( mmio_total > (pci_mem_end - pci_mem_start) || bar64_relocate ) > { > printf("Low MMIO hole not large enough for all devices," > " relocating some BARs to 64-bit\n"); > @@ -446,8 +455,9 @@ void pci_setup(void) > * the code here assumes it to be.) > * Should either of those two conditions change, this code will break. > */ > - using_64bar = bars[i].is_64bar && bar64_relocate > - && (mmio_total > (mem_resource.max - mem_resource.base)); > + using_64bar = bars[i].is_64bar && bar64_relocate && > + (mmio_total > (mem_resource.max - mem_resource.base) || > + bar_sz > HUGE_BAR_THRESH); > bar_data = pci_readl(devfn, bar_reg); > > if ( (bar_data & PCI_BASE_ADDRESS_SPACE) == > @@ -467,7 +477,8 @@ void pci_setup(void) > resource = &mem_resource; > bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK; > } > - mmio_total -= bar_sz; > + if ( bar_sz <= HUGE_BAR_THRESH ) > + mmio_total -= bar_sz; > } > else > { > From xen-devel-bounces@lists.xenproject.org Sat Mar 02 00:28:51 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 02 Mar 2024 00:28:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687817.1071614 (Exim 4.92) (envelope-from ) id 1rgDEu-0002qs-Iu; Sat, 02 Mar 2024 00:28:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687817.1071614; Sat, 02 Mar 2024 00:28:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgDEu-0002ql-FK; Sat, 02 Mar 2024 00:28:32 +0000 Received: by outflank-mailman (input) for mailman id 687817; Sat, 02 Mar 2024 00:28:31 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgDEt-0002qb-5k; Sat, 02 Mar 2024 00:28:31 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgDEt-0003kK-3T; Sat, 02 Mar 2024 00:28:31 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgDEs-0005Ci-OA; Sat, 02 Mar 2024 00:28:30 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rgDEs-0001sO-Ni; Sat, 02 Mar 2024 00:28:30 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=8UZC4vWDZDSFUIsDyGVQkhU9LnO1ZTnw1xpvhIauiFw=; b=FwGmw1vjdiUTiQr2H1u78YwP5L teTakS1zHi1eZgQd9mLHC1OoKrTJrzz9Ir7LneEZQpL2UM6N4Nt2Z+8ESm7gs8BZ/O5XRDG5tC4Fz pxm9kGtpnF8H2zcsg88VbzjSRvZ6/pYQ/PuRWNPILMEWswT37pcV8Vmvv91UR7m5kEts=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 184837: tolerable all pass - PUSHED X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=c40bc0576dcc5acd4d7e22ef628eb4642f568533 X-Osstest-Versions-That: xen=efad36f1ba18946acecc030166b1a6bebeb88ea2 From: osstest service owner Date: Sat, 02 Mar 2024 00:28:30 +0000 flight 184837 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/184837/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-check fail never pass version targeted for testing: xen c40bc0576dcc5acd4d7e22ef628eb4642f568533 baseline version: xen efad36f1ba18946acecc030166b1a6bebeb88ea2 Last test of basis 184830 2024-03-01 10:02:09 Z 0 days Testing same since 184837 2024-03-01 21:02:21 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Roger Pau Monné 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-amd64 pass 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 efad36f1ba..c40bc0576d c40bc0576dcc5acd4d7e22ef628eb4642f568533 -> smoke From xen-devel-bounces@lists.xenproject.org Sat Mar 02 00:47:25 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 02 Mar 2024 00:47:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687822.1071625 (Exim 4.92) (envelope-from ) id 1rgDWw-0005Kx-2T; Sat, 02 Mar 2024 00:47:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687822.1071625; Sat, 02 Mar 2024 00:47:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgDWv-0005Kq-Vb; Sat, 02 Mar 2024 00:47:09 +0000 Received: by outflank-mailman (input) for mailman id 687822; Sat, 02 Mar 2024 00:47:08 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgDWu-0005Ki-0d for xen-devel@lists.xenproject.org; Sat, 02 Mar 2024 00:47:08 +0000 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 63c28f2f-d82e-11ee-a1ee-f123f15fe8a2; Sat, 02 Mar 2024 01:47:05 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 79FB161356; Sat, 2 Mar 2024 00:47:04 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AFFD7C433F1; Sat, 2 Mar 2024 00:47:02 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 63c28f2f-d82e-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1709340424; bh=rzZ/TZ2+muN0dErzsGl4tGXmgSd+omvFE56oIy2cGI0=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=pYPlezXl5tvnAIjQLeewYIGxAcu5BjL3ERac1zMPrTE3XN9DpWT46e7P1ZAIUi98i NxrIPXArn9rlJkthtVkfHPr0pl/KVFmzzd7LGIAFPC3KBWj6XZXiU++/ESvXFo9SVm 9fCa9VZUM5Bs64MffZE6aWZ4Z+NO2f6CfEiStiPqUV8GCmEZrkElK1zbXC806lvuaD b5VFYrLA2ZaYwuN56yVWYpMKhOmt5oo3Jc8nDZouJFlTjywzxxwduiHW8MxF7/JID/ dVTq4z0JuaF8DMj2+0CXL6jR7qp/PaOL/Obbg8aMv2PZQ2vqJLnuG/ouaEoJxq5R3Q XxxSRmcjWBTnQ== Date: Fri, 1 Mar 2024 16:47:01 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Federico Serafini cc: xen-devel@lists.xenproject.org, consulting@bugseng.com, Simone Ballarin , Doug Goldstein , Stefano Stabellini , Andrew Cooper , George Dunlap , Jan Beulich , Julien Grall , Wei Liu Subject: Re: [XEN PATCH] automation/eclair: add deviation for MISRA C:2012 Rule 16.6 In-Reply-To: Message-ID: References: User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Fri, 1 Mar 2024, Federico Serafini wrote: > Update ECLAIR configuration to take into account the deviations > agreed during MISRA meetings. > > Signed-off-by: Federico Serafini Acked-by: Stefano Stabellini > --- > automation/eclair_analysis/ECLAIR/deviations.ecl | 4 ++++ > docs/misra/deviations.rst | 6 ++++++ > 2 files changed, 10 insertions(+) > > diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl > index 02eae39786..0e62a7029f 100644 > --- a/automation/eclair_analysis/ECLAIR/deviations.ecl > +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl > @@ -378,6 +378,10 @@ explicit comment indicating the fallthrough intention is present." > -config=MC3R1.R16.3,reports+={safe, "any_area(end_loc(any_exp(text(^(?s).*/\\* [fF]all ?through.? \\*/.*$,0..1))))"} > -doc_end > > +-doc_begin="A switch statement with a single switch clause and no default label is deliberate and improves readability with respect to an equivalent if statement." > +-config=MC3R1.R16.6,switch_clauses+={deliberate, "default(0)"} > +-doc_end > + > # > # Series 18. > # > diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst > index 123c78e20a..041f8db4ee 100644 > --- a/docs/misra/deviations.rst > +++ b/docs/misra/deviations.rst > @@ -322,6 +322,12 @@ Deviations related to MISRA C:2012 Rules: > - /\* Fallthrough \*/ > - /\* Fallthrough. \*/ > > + * - R16.6 > + - A switch statement with a single switch clause and no default label is > + deliberate and improves readability with respect to an equivalent if > + statement. > + - Tagged as `deliberate` for ECLAIR. > + > * - R20.7 > - Code violating Rule 20.7 is safe when macro parameters are used: > (1) as function arguments; > -- > 2.34.1 > From xen-devel-bounces@lists.xenproject.org Sat Mar 02 01:38:02 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 02 Mar 2024 01:38:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687825.1071634 (Exim 4.92) (envelope-from ) id 1rgEJx-0003LF-LG; Sat, 02 Mar 2024 01:37:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687825.1071634; Sat, 02 Mar 2024 01:37:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgEJx-0003L8-Ia; Sat, 02 Mar 2024 01:37:49 +0000 Received: by outflank-mailman (input) for mailman id 687825; Sat, 02 Mar 2024 01:37:49 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgEJx-0003L2-1L for xen-devel@lists.xenproject.org; Sat, 02 Mar 2024 01:37:49 +0000 Received: from dfw.source.kernel.org (dfw.source.kernel.org [2604:1380:4641:c500::1]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 77a97774-d835-11ee-a1ee-f123f15fe8a2; Sat, 02 Mar 2024 02:37:46 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 22D176166F; Sat, 2 Mar 2024 01:37:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 294F3C433F1; Sat, 2 Mar 2024 01:37:42 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 77a97774-d835-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1709343463; bh=lJvnf0pQcy0ymoylRx3ZZX5D0qQlqk0flX5dDYoiFMo=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=nf+OhHP2cVdjH3D/+8jOysDr/70AXpdpAukO5T0Qnzm8US0KqjEQvQ9Q9eDtaVxlQ tBIjA+MDHp/Qn7avVgBen/uyn7JfDO/ciW/AhAa5gtfJf+pPKL4NR0UC0dWba6N5qh AMLbTW5EulWN8CfNVYmtM4TT+sQU+Tl0u2CqnwQqwkj2dxa1DA//5Um1fUpJfvZV+2 H/zFWUpuKmAT+ckn0LnSbWHGOiqIi8lFyfsJmx6s9ZcuEJB1u3NXka5kKUbu/MtSrm dr62tk5zp/1QLY+FVNmRv19pD5YOfP+cXc8UsSo/8+zOz8xb4D0B2wjbrsFjXnifRU 44bunly2ERkTQ== Date: Fri, 1 Mar 2024 17:37:40 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Jan Beulich cc: Stefano Stabellini , xen-devel@lists.xenproject.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, consulting@bugseng.com, andrew.cooper3@citrix.com, roger.pau@citrix.com, bertrand.marquis@arm.com, julien@xen.org, George Dunlap , Wei Liu , Nicola Vetrini Subject: Re: [XEN PATCH 10/10] xen/keyhandler: address violations of MISRA C Rule 20.7 In-Reply-To: <1afd8805-7365-40ec-8e8e-468a83e20c40@suse.com> Message-ID: References: <2bc4a964f0f2f47488e72237678e944dbdbd7bb7.1709219010.git.nicola.vetrini@bugseng.com> <1afd8805-7365-40ec-8e8e-468a83e20c40@suse.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Fri, 1 Mar 2024, Jan Beulich wrote: > On 29.02.2024 23:57, Stefano Stabellini wrote: > > On Thu, 29 Feb 2024, Nicola Vetrini wrote: > >> MISRA C Rule 20.7 states: "Expressions resulting from the expansion > >> of macro parameters shall be enclosed in parentheses". Therefore, some > >> macro definitions should gain additional parentheses to ensure that all > >> current and future users will be safe with respect to expansions that > >> can possibly alter the semantics of the passed-in macro parameter. > >> > >> No functional change. > >> > >> Signed-off-by: Nicola Vetrini > > > > Reviewed-by: Stefano Stabellini > > You did see the discussion on earlier patches, though? I don't think > any of the parentheses here are needed or wanted. We need to align on this. Currently if we go by what's written in docs/misra/deviations.rst, then rhs should have parentheses. Can we safely claim that rhs parentheses are never needed? If so, then great, let's add it to deviations.rst and skip them here and other places in this patch series (e.g. patch #8). When I say "never" I am taking for granted that the caller is not doing something completely unacceptably broken such as: WRITE_SYSREG64(var +, TTBR0_EL1) If we cannot generically claim that rhs parentheses are never needed, then I don't think we should make any exceptions. We should add them here and everywhere else. It should be easy to write a macro or review a patch with a macro from someone else, and making special exception makes it more difficult for everyone. From xen-devel-bounces@lists.xenproject.org Sat Mar 02 02:25:54 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 02 Mar 2024 02:25:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687836.1071653 (Exim 4.92) (envelope-from ) id 1rgF4M-0001BM-6Z; Sat, 02 Mar 2024 02:25:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687836.1071653; Sat, 02 Mar 2024 02:25:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgF4M-0001BF-3p; Sat, 02 Mar 2024 02:25:46 +0000 Received: by outflank-mailman (input) for mailman id 687836; Sat, 02 Mar 2024 02:25:45 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgF4L-0001B5-EX; Sat, 02 Mar 2024 02:25:45 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgF4L-00076s-Ai; Sat, 02 Mar 2024 02:25:45 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgF4L-0002W8-1F; Sat, 02 Mar 2024 02:25:45 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rgF4L-0006Bk-0u; Sat, 02 Mar 2024 02:25:45 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=lC9D1ywRGYTodlCZWIooFx7MwXDa0cCsKXbp6Paooq4=; b=yq4JplIeknsvi+by4WzmngmMpy YxcMI6nmRvu3+bJmtfmfVVo9/cDABQdN64AV/pX0cnmt8GB3NfNPlFV6D44UFL36WohS1TC0687o0 6v33CIdV4jXT44WXd+ZB0KGQHf90w1xTpDTFJTwlmEGrWAEbMmsayunfZWo9dvU/WuYs=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [ovmf test] 184836: all pass - PUSHED X-Osstest-Versions-This: ovmf=275d0a39c42ad73a6e4929822f56f5d8c16ede96 X-Osstest-Versions-That: ovmf=dc7cfa9bab7487aa0cec02d13aa8c34ff24b37a8 From: osstest service owner Date: Sat, 02 Mar 2024 02:25:45 +0000 flight 184836 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/184836/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 275d0a39c42ad73a6e4929822f56f5d8c16ede96 baseline version: ovmf dc7cfa9bab7487aa0cec02d13aa8c34ff24b37a8 Last test of basis 184818 2024-02-29 10:11:15 Z 1 days Testing same since 184836 2024-03-01 19:13:07 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Gerd Hoffmann Li, Zhihao Zhiguang Liu Zhihao Li Zhou Jianfeng 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-pvops pass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git dc7cfa9bab..275d0a39c4 275d0a39c42ad73a6e4929822f56f5d8c16ede96 -> xen-tested-master From xen-devel-bounces@lists.xenproject.org Sat Mar 02 05:55:13 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 02 Mar 2024 05:55:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687852.1071662 (Exim 4.92) (envelope-from ) id 1rgIKp-0006xS-6r; Sat, 02 Mar 2024 05:54:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687852.1071662; Sat, 02 Mar 2024 05:54:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgIKp-0006xL-40; Sat, 02 Mar 2024 05:54:59 +0000 Received: by outflank-mailman (input) for mailman id 687852; Sat, 02 Mar 2024 05:54:57 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgIKn-0006wv-Ox; Sat, 02 Mar 2024 05:54:57 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgIKn-0003VP-KR; Sat, 02 Mar 2024 05:54:57 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgIKn-00046M-CO; Sat, 02 Mar 2024 05:54:57 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rgIKn-0002AY-Bu; Sat, 02 Mar 2024 05:54:57 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=Y6dIAOYw0sedwsSb/i264miSNQsRssnMiW21BQvLKFQ=; b=LMgpFuO31noBQs83ZHteqquOHH mG2EUR9sZpHXk1AhVtVXJxNvzMvhx2txk0p3cTpcNpbp+WPiH9FFNPMtcJJmdCCzBTutOWKug6BWq RNorPwE0jrTXrbrJtrrZPOO5KOTaordxsviBxh6unUkpZXjBcR+3XbnEyo9KlbH/8dWM=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 184839: tolerable all pass - PUSHED X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=856664f774bd5b66301c5f9022126b61b8cb492d X-Osstest-Versions-That: xen=c40bc0576dcc5acd4d7e22ef628eb4642f568533 From: osstest service owner Date: Sat, 02 Mar 2024 05:54:57 +0000 flight 184839 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/184839/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-check fail never pass version targeted for testing: xen 856664f774bd5b66301c5f9022126b61b8cb492d baseline version: xen c40bc0576dcc5acd4d7e22ef628eb4642f568533 Last test of basis 184837 2024-03-01 21:02:21 Z 0 days Testing same since 184839 2024-03-02 02:00:28 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Bertrand Marquis Stefano Stabellini jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass 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 c40bc0576d..856664f774 856664f774bd5b66301c5f9022126b61b8cb492d -> smoke From xen-devel-bounces@lists.xenproject.org Sat Mar 02 08:07:37 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 02 Mar 2024 08:07:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687870.1071672 (Exim 4.92) (envelope-from ) id 1rgKOx-0004M4-V1; Sat, 02 Mar 2024 08:07:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687870.1071672; Sat, 02 Mar 2024 08:07:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgKOx-0004Lx-RS; Sat, 02 Mar 2024 08:07:23 +0000 Received: by outflank-mailman (input) for mailman id 687870; Sat, 02 Mar 2024 08:07:23 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgKOw-0004Ln-Uc; Sat, 02 Mar 2024 08:07:22 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgKOw-0006hn-QI; Sat, 02 Mar 2024 08:07:22 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgKOw-0000lx-HT; Sat, 02 Mar 2024 08:07:22 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rgKOw-0006QM-Gv; Sat, 02 Mar 2024 08:07:22 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=x5ZCwfuJAG9z0AQWF3zPqb8+UlHrpuxXPeeK4DrYTUk=; b=UnsSl+kwXQjSX76a6xKwQPe8GH wE7RdgYPNphewCkpcOOjS8MPlANOZajZlsp83nFpVu9EXajeC+alDf2NCKciqfWRPcbEMpr51k0LD Gf0pkIOHPc2AXVpdAow+BCO0eLcJBg0hxj7+9JEWOepGAC4l9Yeb8vGBB57w2hzX/m8Y=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-6.1 test] 184831: regressions - FAIL X-Osstest-Failures: linux-6.1:test-amd64-amd64-libvirt-xsm:xen-boot:fail:regression linux-6.1:test-amd64-amd64-xl-qemut-debianhvm-amd64:xen-boot:fail:regression linux-6.1:test-amd64-amd64-xl-credit2:xen-boot:fail:regression linux-6.1:test-amd64-coresched-amd64-xl:xen-boot:fail:regression linux-6.1:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-6.1:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-6.1:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-6.1:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking linux-6.1:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-6.1:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-6.1:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-6.1:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking linux-6.1:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-6.1:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-6.1:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking linux-6.1:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-6.1:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-6.1:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-6.1:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-6.1:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-6.1:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-6.1:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-6.1:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-6.1:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-6.1:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-6.1:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-6.1:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-6.1:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-6.1:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking linux-6.1:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-6.1:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-6.1:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-6.1:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-6.1:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-6.1:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-6.1:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-6.1:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-6.1:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-6.1:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking linux-6.1:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking linux-6.1:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking linux-6.1:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking linux-6.1:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking linux-6.1:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking linux-6.1:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-6.1:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-6.1:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-6.1:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-6.1:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: linux=a3eb3a74aa8c94e6c8130b55f3b031f29162868c X-Osstest-Versions-That: linux=81e1dc2f70014b9523dd02ca763788e4f81e5bac From: osstest service owner Date: Sat, 02 Mar 2024 08:07:22 +0000 flight 184831 linux-6.1 real [real] flight 184840 linux-6.1 real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/184831/ http://logs.test-lab.xenproject.org/osstest/logs/184840/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt-xsm 8 xen-boot fail REGR. vs. 184734 test-amd64-amd64-xl-qemut-debianhvm-amd64 8 xen-boot fail REGR. vs. 184734 test-amd64-amd64-xl-credit2 8 xen-boot fail REGR. vs. 184734 test-amd64-coresched-amd64-xl 8 xen-boot fail REGR. vs. 184734 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 16 saverestore-support-check fail like 184734 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop fail like 184734 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop fail like 184734 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 184734 test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail like 184734 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop fail like 184734 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop fail like 184734 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184734 test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qcow2 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-check fail never pass test-arm64-arm64-xl 15 migrate-support-check fail never pass test-arm64-arm64-xl 16 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 15 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-check fail never pass test-armhf-armhf-libvirt 15 migrate-support-check fail never pass test-amd64-amd64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-check fail never pass test-arm64-arm64-xl-vhd 14 migrate-support-check fail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-check fail never pass version targeted for testing: linux a3eb3a74aa8c94e6c8130b55f3b031f29162868c baseline version: linux 81e1dc2f70014b9523dd02ca763788e4f81e5bac Last test of basis 184734 2024-02-23 08:41:05 Z 7 days Testing same since 184831 2024-03-01 12:45:09 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: "Christian A. Ehrhardt" Adam Goldman Alex Deucher Alexander Kobel Alexander Sverdlin Alexander Tsoy Alison Schofield Allen Pais Andi Shyti Andrew Bresticker Andrew Manley Andrew Morton Ard Biesheuvel Armin Wolf Arnd Bergmann Aurabindo Pillai Avihai Horon Baokun Li Bart Van Assche Bjorn Helgaas Borislav Petkov (AMD) Brenton Simpson Chen-Yu Tsai Chris Li Christian A. Ehrhardt Christian Brauner Colin Ian King Conor Dooley Conrad Kostecki Corey Minyard Cyril Hrubis Damien Le Moal Dan Carpenter Dan Williams Daniel Borkmann Daniel Vacek Daniel Wagner Daniel Wheeler Daniil Dulov Danilo Krummrich Dave Hansen David Hildenbrand David Howells David S. Miller Dennis Dalessandro Devyn Liu Dmitry Bogdanov Dmitry Torokhov Don Brace Edward Adam Davis Edward Lo Eric Dumazet Erik Kurzinger Eugen Hristev Felix Fietkau Florian Fainelli Florian Westphal Frank Li Fullway Wang Gao Xiang Geert Uytterhoeven Geliang Tang Geliang Tang Gianmarco Lusvardi Greg Kroah-Hartman Guenter Roeck Guixin Liu Hannes Reinecke Hans de Goede Hector Martin Heikki Krogerus Heiko Carstens Heiko Stuebner Heiko Stuebner Helge Deller Herbert Xu Horatiu Vultur Hou Tao Huacai Chen Huang Pei Ingo Molnar Ism Hong Jakub Kicinski Jamal Hadi Salim Jan Kiszka Jason Gunthorpe Jason Wang Jens Axboe Jeremy Kerr Jiri Pirko Joao Martins Johannes Berg Johannes Weiner John Fastabend Jon Hunter Julian Sikorski Justin Iurman Kairui Song Kalesh AP Kamal Heib Kees Cook Keith Busch Kelsey Steele kernelci.org bot Konstantin Komarov Krishna Kurapati Kuniyuki Iwashima Kunwu Chan Lennert Buytenhek Leon Romanovsky Lino Sanfilippo Linux Kernel Functional Testing Maarten van der Schrieck Maksim Kiselev Marc Zyngier Marek Szyprowski Mario Limonciello Mark Brown Martin Blumenstingl Martin K. Petersen Martin KaFai Lau Martin Povišer Masahiro Yamada Mat Martineau Mats Kronberg Matthieu Baerts (NGI0) Matthieu Baerts Mel Gorman Michael S. Tsirkin Michal Hocko Michal Kazior Mike Marciniszyn Mike Rapoport (IBM) Mike Snitzer Mikulas Patocka Mustafa Ismail Nam Cao Naohiro Aota Nathan Chancellor # build Nicolas Dichtel Nikita Shubin Niklas Cassel Niklas Schnelle Oliver Upton Pablo Neira Ayuso Paolo Abeni Paulo Alcantara Pavel Machek (CIP) Pavel Sakharov Pawel Laszczak Peter Chen Peter Oberparleiter Peter Zijlstra (Intel) Peter Zijlstra Petr Vorel Phoenix Chen Prike Liang Radhey Shyam Pandey Randy Dunlap Richard Fitzgerald Robert Richter Ron Economos Rémi Denis-Courmont Sabrina Dubroca Salvatore Bonaccorso Sandeep Dhavale Sasha Levin Selvin Xavier SEO HOYOUNG SeongJae Park Shakeel Butt Shanker Donthineni Shigeru Yoshida Shiraz Saleem Shuah Khan Shyam Prasad N Siddharth Vadapalli Simon Ser Sindhu Devale Sindhu Devale Sohaib Nadeem Song Liu Steve French Subbaraya Sundeep syzbot+fd7b34375c1c8ce29c93@syzkaller.appspotmail.com Szilard Fabian Szuying Chen Szuying Chen Takashi Iwai Takashi Sakamoto Theodore Ts'o Thinh Nguyen Thomas Bogendoerfer Thomas Gleixner Thomas Hellström Thorsten Winkler Tobias Waldekranz Tom Chung Tom Parkin Ulf Hansson Vasiliy Kovalev Vidya Sagar Vinod Koul Will Deacon Wolfram Sang Xin Long Xu Yang Yann Sionneau Yi Sun Yogesh Chandra Pandey Yosry Ahmed Yu Kuai Yu Zhao Yue Hu Zhang Rui Zhang Yi zhenwei pi Zhipeng Lu jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl fail test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm fail test-arm64-arm64-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-amd64-dom0pvh-xl-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 fail test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-freebsd11-amd64 pass test-amd64-amd64-freebsd12-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-examine-bios pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 fail test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-amd64-dom0pvh-xl-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-amd64-xl-pvshim pass test-amd64-amd64-pygrub pass test-amd64-amd64-libvirt-qcow2 pass test-armhf-armhf-libvirt-qcow2 pass test-amd64-amd64-libvirt-raw pass test-arm64-arm64-libvirt-raw pass test-armhf-armhf-libvirt-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-examine-uefi pass test-amd64-amd64-xl-vhd pass test-arm64-arm64-xl-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these 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 5814 lines long.) From xen-devel-bounces@lists.xenproject.org Sat Mar 02 13:24:48 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 02 Mar 2024 13:24:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687915.1071703 (Exim 4.92) (envelope-from ) id 1rgPLq-0003Fk-Uz; Sat, 02 Mar 2024 13:24:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687915.1071703; Sat, 02 Mar 2024 13:24:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgPLq-0003Fd-S5; Sat, 02 Mar 2024 13:24:30 +0000 Received: by outflank-mailman (input) for mailman id 687915; Sat, 02 Mar 2024 13:24:29 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgPLp-0003FT-HA; Sat, 02 Mar 2024 13:24:29 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgPLp-0003nu-C3; Sat, 02 Mar 2024 13:24:29 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgPLo-0005VA-W6; Sat, 02 Mar 2024 13:24:29 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rgPLo-0000C1-Vb; Sat, 02 Mar 2024 13:24:28 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=rfAAG2KMUfReNHPYJ8vxQzn1LxB2Usw7+zsZrfKZ2WU=; b=NgTa1k8p3ZGFSFrRTwAw+Asl2i 2AENTCE3p+nkf7LiDtI9OudhN70qbXhYLYftIL3W2FI4MGYl9s3/kPF+P23i4gVxQsS55zqCIRKRL Z9yUd3e1PqZxsU93MUEVIVOk9F8lU8Y/9iiu6sHXYoKoBlCrfyUiwbmRJkI1hk60sNy0=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-5.4 test] 184832: tolerable FAIL - PUSHED X-Osstest-Failures: linux-5.4:test-amd64-i386-qemuu-rhel6hvm-amd:guest-start/redhat.repeat:fail:heisenbug linux-5.4:test-amd64-amd64-xl-qcow2:guest-start/debian.repeat:fail:heisenbug linux-5.4:test-armhf-armhf-xl-arndale:guest-start/debian.repeat:fail:heisenbug linux-5.4:test-armhf-armhf-xl-multivcpu:guest-start/debian.repeat:fail:heisenbug linux-5.4:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-5.4:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-5.4:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-5.4:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-5.4:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-5.4:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-5.4:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking linux-5.4:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-5.4:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-5.4:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking linux-5.4:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking linux-5.4:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-i386-libvirt-raw:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: linux=e133c1ee6d7271007fdba3dbe78818afd88943f9 X-Osstest-Versions-That: linux=6e1f54a4985b63bc1b55a09e5e75a974c5d6719b From: osstest service owner Date: Sat, 02 Mar 2024 13:24:28 +0000 flight 184832 linux-5.4 real [real] flight 184844 linux-5.4 real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/184832/ http://logs.test-lab.xenproject.org/osstest/logs/184844/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-i386-qemuu-rhel6hvm-amd 14 guest-start/redhat.repeat fail pass in 184844-retest test-amd64-amd64-xl-qcow2 21 guest-start/debian.repeat fail pass in 184844-retest test-armhf-armhf-xl-arndale 18 guest-start/debian.repeat fail pass in 184844-retest test-armhf-armhf-xl-multivcpu 18 guest-start/debian.repeat fail pass in 184844-retest Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 16 saverestore-support-check fail like 184733 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop fail like 184733 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 184733 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 184733 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop fail like 184733 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop fail like 184733 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop fail like 184733 test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail like 184733 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 184733 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 184733 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 184733 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184733 test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-check fail never pass test-amd64-i386-xl-pvshim 14 guest-start fail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-check fail never pass test-amd64-i386-libvirt 15 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-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl 15 migrate-support-check fail never pass test-arm64-arm64-xl 16 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 15 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-check fail never pass test-armhf-armhf-libvirt 15 migrate-support-check fail never pass test-amd64-i386-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-check fail never pass test-arm64-arm64-xl-vhd 14 migrate-support-check fail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-check fail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-check fail never pass version targeted for testing: linux e133c1ee6d7271007fdba3dbe78818afd88943f9 baseline version: linux 6e1f54a4985b63bc1b55a09e5e75a974c5d6719b Last test of basis 184733 2024-02-23 07:45:41 Z 8 days Testing same since 184832 2024-03-01 12:45:59 Z 1 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Adam Goldman Alex Deucher Alexander Sverdlin Alexandra Winter Alexei Starovoitov Andrew Morton Andrii Nakryiko Andrii Nakryiko Arnd Bergmann Baokun Li Bart Van Assche Bjorn Andersson Björn Töpel Chen-Yu Tsai Christian Brauner Christian König Christophe JAILLET Conrad Kostecki Cyril Hrubis Daniel Borkmann Daniel Vacek Daniel Wagner Daniil Dulov Danilo Krummrich Darrick J. Wong David Howells David S. Miller Dennis Dalessandro Dmitry Bogdanov Eric Dumazet Erik Kurzinger Felix Fietkau Florian Fainelli Florian Westphal Frank Li Fullway Wang Geert Uytterhoeven Gianmarco Lusvardi GONG, Ruiqi Greg Kroah-Hartman Guenter Roeck Guixin Liu Hannes Reinecke Harshit Mogalapalli Heikki Krogerus Heiko Carstens Helge Deller Icenowy Zheng Ingo Molnar Jakub Kicinski Jamal Hadi Salim Jason Gunthorpe Jason Gunthorpe Jens Axboe Jiri Pirko Johannes Berg Jon Hunter Kai-Heng Feng Kalesh AP Keith Busch kernelci.org bot Kirill A. Shutemov Krishna Kurapati Lee Jones Lennert Buytenhek Leon Romanovsky Linus Walleij Linux Kernel Functional Testing Lokesh Gidra Lorenzo Pieralisi Luke Nelson Marc Zyngier Mark Brown Martin Blumenstingl Martin K. Petersen Mats Kronberg Matthew Wilcox (Oracle) Maxime Ripard Mel Gorman Miaoqian Lin Michal Hocko Michal Kazior Mike Rapoport (IBM) Mike Snitzer Mikulas Patocka Nathan Chancellor Nicolas Dichtel Nikita Shubin Niklas Cassel Niklas Schnelle Nikolay Aleksandrov Oliver Upton Pablo Neira Ayuso Pali Rohár Paolo Abeni Peter Chen Peter Zijlstra (Intel) Petr Vorel Randy Dunlap Rob Herring Ryusuke Konishi Sabrina Dubroca Sasha Levin Selvin Xavier Shanker Donthineni Shuah Khan Simon Ser Sireesh Kodali Soheil Hassas Yeganeh Takashi Iwai Takashi Sakamoto Theodore Ts'o Thierry Reding Thomas Gleixner Tom Parkin Trek Ulf Hansson Vasiliy Kovalev Vidya Sagar Vinod Koul Wolfram Sang Xin Long Xu Yang Yi Sun Zhang Rui Zhipeng Lu jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-dom0pvh-xl-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-qemuu-freebsd11-amd64 pass test-amd64-amd64-qemuu-freebsd12-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale fail test-amd64-amd64-examine-bios pass test-amd64-i386-examine-bios pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-dom0pvh-xl-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu fail test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-armhf-armhf-libvirt-qcow2 pass test-amd64-amd64-xl-qcow2 fail test-arm64-arm64-libvirt-raw pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-libvirt-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-examine-uefi pass test-amd64-i386-examine-uefi pass test-amd64-amd64-libvirt-vhd pass test-arm64-arm64-xl-vhd pass test-armhf-armhf-xl-vhd pass test-amd64-i386-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these 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 : hint: The 'hooks/update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-receive' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. To xenbits.xen.org:/home/xen/git/linux-pvops.git 6e1f54a4985b6..e133c1ee6d727 e133c1ee6d7271007fdba3dbe78818afd88943f9 -> tested/linux-5.4 From xen-devel-bounces@lists.xenproject.org Sat Mar 02 16:04:31 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 02 Mar 2024 16:04:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687938.1071731 (Exim 4.92) (envelope-from ) id 1rgRqN-0003gk-Bc; Sat, 02 Mar 2024 16:04:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687938.1071731; Sat, 02 Mar 2024 16:04:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgRqN-0003gd-8g; Sat, 02 Mar 2024 16:04:11 +0000 Received: by outflank-mailman (input) for mailman id 687938; Sat, 02 Mar 2024 16:04:10 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgRqM-0003gX-2H for xen-devel@lists.xenproject.org; Sat, 02 Mar 2024 16:04:10 +0000 Received: from smtp-fw-6002.amazon.com (smtp-fw-6002.amazon.com [52.95.49.90]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 7f7911cc-d8ae-11ee-afd9-a90da7624cb6; Sat, 02 Mar 2024 17:04:08 +0100 (CET) Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO smtpout.prod.us-east-1.prod.farcaster.email.amazon.dev) ([10.43.8.6]) by smtp-border-fw-6002.iad6.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Mar 2024 16:04:06 +0000 Received: from EX19MTAEUA001.ant.amazon.com [10.0.17.79:9101] by smtpin.naws.eu-west-1.prod.farcaster.email.amazon.dev [10.0.23.38:2525] with esmtp (Farcaster) id 85a662c0-eb29-49e0-86cf-fb7cf493641c; Sat, 2 Mar 2024 16:04:04 +0000 (UTC) Received: from EX19D026EUB004.ant.amazon.com (10.252.61.64) by EX19MTAEUA001.ant.amazon.com (10.252.50.223) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.28; Sat, 2 Mar 2024 16:04:03 +0000 Received: from uc3ecf78c6baf56.ant.amazon.com (10.187.170.62) by EX19D026EUB004.ant.amazon.com (10.252.61.64) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.28; Sat, 2 Mar 2024 16:04:00 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 7f7911cc-d8ae-11ee-afd9-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1709395448; x=1740931448; h=date:from:to:cc:subject:message-id:mime-version; bh=mKU44kf1szj1NAugNFe0lwWcoXGVyPwTuTIS+BKG33o=; b=LAI2ESLhMMbWJLwGg3HWDgUm1iFnEgBd9D+18YkhEF7tUuQ7SCXvo86h LrAalFFxhDk9vyn65CKiHCkb34nuAobd35fxVJL8+MlmWT9UV/0LrG0v2 4d8U++ZTjL/MPuJODiFldj/7eGxwzXuSRQJX6fA4DTN3IWk/lzGFJHtxP A=; X-IronPort-AV: E=Sophos;i="6.06,199,1705363200"; d="scan'208";a="390492001" X-Farcaster-Flow-ID: 85a662c0-eb29-49e0-86cf-fb7cf493641c Date: Sat, 2 Mar 2024 08:03:57 -0800 From: Andrew Panyakin To: CC: , , , , , , , , , , , , , Subject: [PATCH 5.10] xen/events: close evtchn after mapping cleanup Message-ID: <20240302160357.GA2232656@uc3ecf78c6baf56.ant.amazon.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline X-Originating-IP: [10.187.170.62] X-ClientProxiedBy: EX19D045UWA003.ant.amazon.com (10.13.139.46) To EX19D026EUB004.ant.amazon.com (10.252.61.64) From: Maximilian Heyne Commit fa765c4b4aed2d64266b694520ecb025c862c5a9 upstream shutdown_pirq and startup_pirq are not taking the irq_mapping_update_lock because they can't due to lock inversion. Both are called with the irq_desc->lock being taking. The lock order, however, is first irq_mapping_update_lock and then irq_desc->lock. This opens multiple races: - shutdown_pirq can be interrupted by a function that allocates an event channel: CPU0 CPU1 shutdown_pirq { xen_evtchn_close(e) __startup_pirq { EVTCHNOP_bind_pirq -> returns just freed evtchn e set_evtchn_to_irq(e, irq) } xen_irq_info_cleanup() { set_evtchn_to_irq(e, -1) } } Assume here event channel e refers here to the same event channel number. After this race the evtchn_to_irq mapping for e is invalid (-1). - __startup_pirq races with __unbind_from_irq in a similar way. Because __startup_pirq doesn't take irq_mapping_update_lock it can grab the evtchn that __unbind_from_irq is currently freeing and cleaning up. In this case even though the event channel is allocated, its mapping can be unset in evtchn_to_irq. The fix is to first cleanup the mappings and then close the event channel. In this way, when an event channel gets allocated it's potential previous evtchn_to_irq mappings are guaranteed to be unset already. This is also the reverse order of the allocation where first the event channel is allocated and then the mappings are setup. On a 5.10 kernel prior to commit 3fcdaf3d7634 ("xen/events: modify internal [un]bind interfaces"), we hit a BUG like the following during probing of NVMe devices. The issue is that during nvme_setup_io_queues, pci_free_irq is called for every device which results in a call to shutdown_pirq. With many nvme devices it's therefore likely to hit this race during boot because there will be multiple calls to shutdown_pirq and startup_pirq are running potentially in parallel. ------------[ cut here ]------------ blkfront: xvda: barrier or flush: disabled; persistent grants: enabled; indirect descriptors: enabled; bounce buffer: enabled kernel BUG at drivers/xen/events/events_base.c:499! invalid opcode: 0000 [#1] SMP PTI CPU: 44 PID: 375 Comm: kworker/u257:23 Not tainted 5.10.201-191.748.amzn2.x86_64 #1 Hardware name: Xen HVM domU, BIOS 4.11.amazon 08/24/2006 Workqueue: nvme-reset-wq nvme_reset_work RIP: 0010:bind_evtchn_to_cpu+0xdf/0xf0 Code: 5d 41 5e c3 cc cc cc cc 44 89 f7 e8 2b 55 ad ff 49 89 c5 48 85 c0 0f 84 64 ff ff ff 4c 8b 68 30 41 83 fe ff 0f 85 60 ff ff ff <0f> 0b 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 0f 1f 44 00 00 RSP: 0000:ffffc9000d533b08 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006 RDX: 0000000000000028 RSI: 00000000ffffffff RDI: 00000000ffffffff RBP: ffff888107419680 R08: 0000000000000000 R09: ffffffff82d72b00 R10: 0000000000000000 R11: 0000000000000000 R12: 00000000000001ed R13: 0000000000000000 R14: 00000000ffffffff R15: 0000000000000002 FS: 0000000000000000(0000) GS:ffff88bc8b500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000002610001 CR4: 00000000001706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? show_trace_log_lvl+0x1c1/0x2d9 ? show_trace_log_lvl+0x1c1/0x2d9 ? set_affinity_irq+0xdc/0x1c0 ? __die_body.cold+0x8/0xd ? die+0x2b/0x50 ? do_trap+0x90/0x110 ? bind_evtchn_to_cpu+0xdf/0xf0 ? do_error_trap+0x65/0x80 ? bind_evtchn_to_cpu+0xdf/0xf0 ? exc_invalid_op+0x4e/0x70 ? bind_evtchn_to_cpu+0xdf/0xf0 ? asm_exc_invalid_op+0x12/0x20 ? bind_evtchn_to_cpu+0xdf/0xf0 ? bind_evtchn_to_cpu+0xc5/0xf0 set_affinity_irq+0xdc/0x1c0 irq_do_set_affinity+0x1d7/0x1f0 irq_setup_affinity+0xd6/0x1a0 irq_startup+0x8a/0xf0 __setup_irq+0x639/0x6d0 ? nvme_suspend+0x150/0x150 request_threaded_irq+0x10c/0x180 ? nvme_suspend+0x150/0x150 pci_request_irq+0xa8/0xf0 ? __blk_mq_free_request+0x74/0xa0 queue_request_irq+0x6f/0x80 nvme_create_queue+0x1af/0x200 nvme_create_io_queues+0xbd/0xf0 nvme_setup_io_queues+0x246/0x320 ? nvme_irq_check+0x30/0x30 nvme_reset_work+0x1c8/0x400 process_one_work+0x1b0/0x350 worker_thread+0x49/0x310 ? process_one_work+0x350/0x350 kthread+0x11b/0x140 ? __kthread_bind_mask+0x60/0x60 ret_from_fork+0x22/0x30 Modules linked in: ---[ end trace a11715de1eee1873 ]--- Fixes: d46a78b05c0e ("xen: implement pirq type event channels") Cc: stable@vger.kernel.org Co-debugged-by: Andrew Panyakin Signed-off-by: Maximilian Heyne [apanyaki: backport to v5.10-stable] Signed-off-by: Andrew Paniakin --- Compare to upstream patch this one does not have close_evtchn flag because there is no need to handle static event channels. This feature was added only in 58f6259b7a08f ("xen/evtchn: Introduce new IOCTL to bind static evtchn") drivers/xen/events/events_base.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c index 24e39984914f..f608663bdfd5 100644 --- a/drivers/xen/events/events_base.c +++ b/drivers/xen/events/events_base.c @@ -885,8 +885,8 @@ static void shutdown_pirq(struct irq_data *data) return; do_mask(info, EVT_MASK_REASON_EXPLICIT); - xen_evtchn_close(evtchn); xen_irq_info_cleanup(info); + xen_evtchn_close(evtchn); } static void enable_pirq(struct irq_data *data) @@ -929,8 +929,6 @@ static void __unbind_from_irq(unsigned int irq) if (VALID_EVTCHN(evtchn)) { unsigned int cpu = cpu_from_irq(irq); - xen_evtchn_close(evtchn); - switch (type_from_irq(irq)) { case IRQT_VIRQ: per_cpu(virq_to_irq, cpu)[virq_from_irq(irq)] = -1; @@ -943,6 +941,7 @@ static void __unbind_from_irq(unsigned int irq) } xen_irq_info_cleanup(info); + xen_evtchn_close(evtchn); } xen_free_irq(irq); -- 2.40.1 From xen-devel-bounces@lists.xenproject.org Sat Mar 02 16:33:47 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 02 Mar 2024 16:33:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687944.1071745 (Exim 4.92) (envelope-from ) id 1rgSIv-0007bY-K9; Sat, 02 Mar 2024 16:33:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687944.1071745; Sat, 02 Mar 2024 16:33:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgSIv-0007bR-HT; Sat, 02 Mar 2024 16:33:41 +0000 Received: by outflank-mailman (input) for mailman id 687944; Sat, 02 Mar 2024 16:33:40 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgSIu-0007bF-6b; Sat, 02 Mar 2024 16:33:40 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgSIu-0007ZT-2a; Sat, 02 Mar 2024 16:33:40 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgSIt-0001gy-Q2; Sat, 02 Mar 2024 16:33:39 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rgSIt-0000a5-Pb; Sat, 02 Mar 2024 16:33:39 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=eu3/52/i1DU+kMUtwCjVDhZv4ZhBOo41swKEOzEIquo=; b=m/gL3+xwECSz7I6MIb5p/bOPIf u7TYcY4poy/TRj/0Xls0MTMOpmRgHiMLcMGQ2QAXBbLg2J43P9U/Gv+xRprskjUuiKviGVdi7WFyp MNg9qa/FPtqD2S4tcTFV9HR2VZLt0VV0VuSQu6h/HZKgLTbCIJw3Axay9f2tknyZfKuU=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable test] 184833: tolerable FAIL - PUSHED X-Osstest-Failures: xen-unstable:test-armhf-armhf-libvirt-raw:guest-start:fail:heisenbug xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: xen=efad36f1ba18946acecc030166b1a6bebeb88ea2 X-Osstest-Versions-That: xen=4cac80e22600d5a38d77c65e9a6507c752efc155 From: osstest service owner Date: Sat, 02 Mar 2024 16:33:39 +0000 flight 184833 xen-unstable real [real] flight 184848 xen-unstable real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/184833/ http://logs.test-lab.xenproject.org/osstest/logs/184848/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-libvirt-raw 13 guest-start fail pass in 184848-retest Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail in 184848 like 184828 test-armhf-armhf-libvirt-raw 14 migrate-support-check fail in 184848 never pass test-armhf-armhf-libvirt 16 saverestore-support-check fail like 184828 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop fail like 184828 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 184828 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop fail like 184828 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 184828 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 184828 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop fail like 184828 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 184828 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184828 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 184828 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop fail like 184828 test-amd64-i386-xl-pvshim 14 guest-start fail never pass test-amd64-i386-libvirt 15 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-check fail never pass test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-arm64-arm64-xl 15 migrate-support-check fail never pass test-arm64-arm64-xl 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 15 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 15 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-check fail never pass test-armhf-armhf-libvirt 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-check fail never pass test-amd64-i386-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-check fail never pass test-arm64-arm64-xl-vhd 14 migrate-support-check fail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-check fail never pass version targeted for testing: xen efad36f1ba18946acecc030166b1a6bebeb88ea2 baseline version: xen 4cac80e22600d5a38d77c65e9a6507c752efc155 Last test of basis 184828 2024-03-01 04:24:17 Z 1 days Testing same since 184833 2024-03-01 14:11:30 Z 1 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Michal Orzel jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-dom0pvh-xl-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-qemuu-freebsd11-amd64 pass test-amd64-amd64-qemuu-freebsd12-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-examine-bios pass test-amd64-i386-examine-bios pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-dom0pvh-xl-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-armhf-armhf-libvirt-qcow2 pass test-amd64-amd64-xl-qcow2 pass test-arm64-arm64-libvirt-raw pass test-armhf-armhf-libvirt-raw fail test-amd64-i386-libvirt-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-examine-uefi pass test-amd64-i386-examine-uefi pass test-amd64-amd64-libvirt-vhd pass test-arm64-arm64-xl-vhd pass test-armhf-armhf-xl-vhd pass test-amd64-i386-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these 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 4cac80e226..efad36f1ba efad36f1ba18946acecc030166b1a6bebeb88ea2 -> master From xen-devel-bounces@lists.xenproject.org Sat Mar 02 22:41:23 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 02 Mar 2024 22:41:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687975.1071779 (Exim 4.92) (envelope-from ) id 1rgY2W-0003sW-Lm; Sat, 02 Mar 2024 22:41:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687975.1071779; Sat, 02 Mar 2024 22:41:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgY2W-0003sP-Ix; Sat, 02 Mar 2024 22:41:08 +0000 Received: by outflank-mailman (input) for mailman id 687975; Sat, 02 Mar 2024 22:41:07 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgY2V-0003sF-Ko; Sat, 02 Mar 2024 22:41:07 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgY2V-0006eD-Hn; Sat, 02 Mar 2024 22:41:07 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgY2V-0003B7-7Z; Sat, 02 Mar 2024 22:41:07 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rgY2V-00065X-71; Sat, 02 Mar 2024 22:41:07 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=m1rKnanHGhTkkKf3r2+pjBTNZLCeAHsgDVvmnB5uOA4=; b=3Ksl2/uJkuccmc/6yhk8xDs9id sgxaXvXQAh39p4usCKP8Htv0m3LpROMDvoSvGao+vOyrwqL8m7K5Ub4Y+nU8IbkbGM09BeLZywfA2 YDX8CMvrUGXFWNgxMR099RyB2SEnE21nCfrQ8SYZOijLjfgqmfGubIwp/Z91Rg1QpfzE=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.17-testing test] 184838: tolerable trouble: fail/pass/starved - PUSHED X-Osstest-Failures: xen-4.17-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.17-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-4.17-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.17-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.17-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.17-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-4.17-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.17-testing:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking xen-4.17-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.17-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.17-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.17-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking xen-4.17-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.17-testing:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-4.17-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-4.17-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-4.17-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.17-testing:test-amd64-i386-libvirt-raw:migrate-support-check:fail:nonblocking xen-4.17-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-4.17-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-4.17-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.17-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-4.17-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.17-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-4.17-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-4.17-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-4.17-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-4.17-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-4.17-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-4.17-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-4.17-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-4.17-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-4.17-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-4.17-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.17-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.17-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-4.17-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-4.17-testing:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking xen-4.17-testing:test-arm64-arm64-libvirt-raw:hosts-allocate:starved:nonblocking xen-4.17-testing:test-arm64-arm64-libvirt-xsm:hosts-allocate:starved:nonblocking xen-4.17-testing:test-arm64-arm64-xl-credit2:hosts-allocate:starved:nonblocking xen-4.17-testing:test-arm64-arm64-xl-thunderx:hosts-allocate:starved:nonblocking xen-4.17-testing:test-arm64-arm64-xl-vhd:hosts-allocate:starved:nonblocking xen-4.17-testing:test-arm64-arm64-xl-xsm:hosts-allocate:starved:nonblocking xen-4.17-testing:test-arm64-arm64-xl:hosts-allocate:starved:nonblocking xen-4.17-testing:test-arm64-arm64-xl-credit1:hosts-allocate:starved:nonblocking X-Osstest-Versions-This: xen=6cbccc4071ef49a8c591ecaddfdcb1cc26d28411 X-Osstest-Versions-That: xen=49f77602373b58b7bbdb40cea2b49d2f88d4003d From: osstest service owner Date: Sat, 02 Mar 2024 22:41:07 +0000 flight 184838 xen-4.17-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/184838/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 184786 test-armhf-armhf-libvirt 16 saverestore-support-check fail like 184786 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 184786 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop fail like 184786 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop fail like 184786 test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail like 184786 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 184786 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 184786 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop fail like 184786 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 184786 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop fail like 184786 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184786 test-amd64-i386-libvirt-xsm 15 migrate-support-check fail never pass test-amd64-i386-xl-pvshim 14 guest-start fail never pass test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-amd64-i386-libvirt 15 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-check fail never pass test-amd64-i386-libvirt-raw 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 15 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 15 migrate-support-check fail never pass test-armhf-armhf-libvirt 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 16 saverestore-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-check fail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-check fail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 3 hosts-allocate starved n/a test-arm64-arm64-libvirt-xsm 3 hosts-allocate starved n/a test-arm64-arm64-xl-credit2 3 hosts-allocate starved n/a test-arm64-arm64-xl-thunderx 3 hosts-allocate starved n/a test-arm64-arm64-xl-vhd 3 hosts-allocate starved n/a test-arm64-arm64-xl-xsm 3 hosts-allocate starved n/a test-arm64-arm64-xl 3 hosts-allocate starved n/a test-arm64-arm64-xl-credit1 3 hosts-allocate starved n/a version targeted for testing: xen 6cbccc4071ef49a8c591ecaddfdcb1cc26d28411 baseline version: xen 49f77602373b58b7bbdb40cea2b49d2f88d4003d Last test of basis 184786 2024-02-27 13:37:10 Z 4 days Testing same since 184838 2024-03-02 01:55:37 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Julien Grall Luca Fancellu Michal Orzel jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl starved test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm starved test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm starved test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-dom0pvh-xl-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-qemuu-freebsd11-amd64 pass test-amd64-amd64-qemuu-freebsd12-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 starved test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 starved test-armhf-armhf-xl-credit2 pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-dom0pvh-xl-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-armhf-armhf-libvirt-qcow2 pass test-amd64-amd64-xl-qcow2 pass test-arm64-arm64-libvirt-raw starved test-armhf-armhf-libvirt-raw pass test-amd64-i386-libvirt-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx starved test-amd64-amd64-libvirt-vhd pass test-arm64-arm64-xl-vhd starved test-armhf-armhf-xl-vhd pass test-amd64-i386-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these 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 49f7760237..6cbccc4071 6cbccc4071ef49a8c591ecaddfdcb1cc26d28411 -> stable-4.17 From xen-devel-bounces@lists.xenproject.org Sun Mar 03 00:25:42 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 03 Mar 2024 00:25:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687986.1071802 (Exim 4.92) (envelope-from ) id 1rgZfV-00077a-6l; Sun, 03 Mar 2024 00:25:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687986.1071802; Sun, 03 Mar 2024 00:25:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgZfV-00077T-3j; Sun, 03 Mar 2024 00:25:29 +0000 Received: by outflank-mailman (input) for mailman id 687986; Sun, 03 Mar 2024 00:25:27 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgZfT-00077J-TM; Sun, 03 Mar 2024 00:25:27 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgZfT-0000rO-QS; Sun, 03 Mar 2024 00:25:27 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgZfT-0001AE-Fi; Sun, 03 Mar 2024 00:25:27 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rgZfT-0004cc-FI; Sun, 03 Mar 2024 00:25:27 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=vCvzdlZ0L/D3yEG446dJCNVg1UH06iyQ9pOegS2ojNE=; b=qhNI1zOHPdXEtX3sSKJl+H/XiY r5LZZ0tUmuWb6UnSo8V1iViSPsvkyjOWSwkXJyWVwr08GReR3Gpz01w8gcuNTdu8qenvFRkKfE3OV 4nwZOuUEFAuBAeIklNslRuzxT/iHKhEVakU+VNBMxwuY7o8gtnX9YI/WRXPyqJh/4zto=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-linus test] 184835: tolerable FAIL - PUSHED X-Osstest-Failures: linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: linux=87adedeba51a822533649b143232418b9e26d08b X-Osstest-Versions-That: linux=805d849d7c3cc1f38efefd48b2480d62b7b5dcb7 From: osstest service owner Date: Sun, 03 Mar 2024 00:25:27 +0000 flight 184835 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/184835/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop fail like 184816 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop fail like 184816 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop fail like 184816 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 184816 test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail like 184816 test-armhf-armhf-libvirt 16 saverestore-support-check fail like 184816 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop fail like 184816 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184816 test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl 15 migrate-support-check fail never pass test-arm64-arm64-xl 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 15 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 15 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qcow2 14 migrate-support-check fail never pass test-amd64-amd64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-check fail never pass test-arm64-arm64-xl-vhd 14 migrate-support-check fail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-check fail never pass test-armhf-armhf-libvirt 15 migrate-support-check fail never pass version targeted for testing: linux 87adedeba51a822533649b143232418b9e26d08b baseline version: linux 805d849d7c3cc1f38efefd48b2480d62b7b5dcb7 Last test of basis 184816 2024-02-29 05:22:18 Z 2 days Testing same since 184825 2024-02-29 21:14:29 Z 2 days 3 attempts ------------------------------------------------------------ People who touched revisions under test: Alexander Ofitserov Amritha Nambiar Andre Werner Arkadiusz Kubalewski Benjamin Berg Charlie Jenkins Christophe Leroy Clancy Shang David S. Miller Davide Caratti Emmanuel Grumbach Eric Dumazet Felix Fietkau Florian Westphal Frédéric Danis Geliang Tang Geoff Levand Guenter Roeck Haiyue Wang Ignat Korchagin Jakub Kicinski Jakub Raczynski Janaki Ramaiah Thota Javier Carrasco Jeff Johnson Jeremy Kerr Johan Hovold Johannes Berg Jonas Dreßler Justin Iurman Kai-Heng Feng Kalle Valo Kurt Kanzenbach Lin Ma Linus Torvalds Luiz Augusto von Dentz Lukasz Majewski Madalin Bucur Matthieu Baerts (NGI0) Michal Kubecek Mickaël Salaün Miri Korenblit Nicolas Dichtel Nikolay Aleksandrov Oleksij Rempel Pablo Neira Ayuso Palmer Dabbelt Paolo Abeni Pucha Himasekhar Reddy (A Contingent worker at Intel) Randy Dunlap Ryosuke Yasuoka Sabrina Dubroca Serge Semin Shannon Nelson Stanislav Fomichev Sunitha Mekala (A Contingent worker at Intel) Tony Nguyen Vladimir Oltean Ying Hsu Yochai Hagvi Yunjian Wang Yuxuan Hu <20373622@buaa.edu.cn> Zijun Hu jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-amd64-dom0pvh-xl-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-freebsd11-amd64 pass test-amd64-amd64-freebsd12-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-examine-bios pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-amd64-dom0pvh-xl-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-amd64-xl-pvshim pass test-amd64-amd64-pygrub pass test-amd64-amd64-libvirt-qcow2 pass test-armhf-armhf-libvirt-qcow2 pass test-amd64-amd64-libvirt-raw pass test-arm64-arm64-libvirt-raw pass test-armhf-armhf-libvirt-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-examine-uefi pass test-amd64-amd64-xl-vhd pass test-arm64-arm64-xl-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these 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 : hint: The 'hooks/update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-receive' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. To xenbits.xen.org:/home/xen/git/linux-pvops.git 805d849d7c3cc..87adedeba51a8 87adedeba51a822533649b143232418b9e26d08b -> tested/linux-linus From xen-devel-bounces@lists.xenproject.org Sun Mar 03 01:59:33 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 03 Mar 2024 01:59:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.687996.1071822 (Exim 4.92) (envelope-from ) id 1rgb8K-0006iD-07; Sun, 03 Mar 2024 01:59:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687996.1071822; Sun, 03 Mar 2024 01:59:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgb8J-0006i6-RW; Sun, 03 Mar 2024 01:59:19 +0000 Received: by outflank-mailman (input) for mailman id 687996; Sun, 03 Mar 2024 01:59:18 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgb8I-0006hw-MW; Sun, 03 Mar 2024 01:59:18 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgb8I-0000tY-Kp; Sun, 03 Mar 2024 01:59:18 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgb8H-0005PR-I3; Sun, 03 Mar 2024 01:59:17 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rgb8H-0000CE-Hb; Sun, 03 Mar 2024 01:59:17 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=BdXf7k/Dg12qiUwUEfe6f7ocqI9tD+5JH3h4+5zDQow=; b=NO/Yla+Q+YjRoEJR+NU27VhGh7 qfnFU3H0PiHKyTBsRDg1MjU6mtlgg4tpmxFKAUOUY5H11E0b7tIdzqi0DO/AThUOCf5igC+eGmzQs Py8wn2I8zr69Bd4ErJKM1YyOma/nT53aZSwbkDc4hhVZ1uyPHu2Rht4y3GfsdZ2ij1ms=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xtf test] 184862: all pass - PUSHED X-Osstest-Versions-This: xtf=3955325292f49257797f339cfdcb84748550e069 X-Osstest-Versions-That: xtf=5c37e0b719c925207db50e89a5b11d7ce78cf1fb From: osstest service owner Date: Sun, 03 Mar 2024 01:59:17 +0000 flight 184862 xtf real [real] http://logs.test-lab.xenproject.org/osstest/logs/184862/ Perfect :-) All tests in this flight passed as required version targeted for testing: xtf 3955325292f49257797f339cfdcb84748550e069 baseline version: xtf 5c37e0b719c925207db50e89a5b11d7ce78cf1fb Last test of basis 184812 2024-02-28 20:13:14 Z 3 days Testing same since 184862 2024-03-03 00:41:25 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper jobs: build-amd64-xtf pass build-amd64 pass build-amd64-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 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/xtf.git 5c37e0b..3955325 3955325292f49257797f339cfdcb84748550e069 -> xen-tested-master From xen-devel-bounces@lists.xenproject.org Sun Mar 03 03:01:35 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 03 Mar 2024 03:01:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688004.1071841 (Exim 4.92) (envelope-from ) id 1rgc6K-0006Jg-DV; Sun, 03 Mar 2024 03:01:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688004.1071841; Sun, 03 Mar 2024 03:01:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgc6K-0006JZ-9t; Sun, 03 Mar 2024 03:01:20 +0000 Received: by outflank-mailman (input) for mailman id 688004; Sun, 03 Mar 2024 03:01:18 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgc6I-0006JB-D8 for xen-devel@lists.xenproject.org; Sun, 03 Mar 2024 03:01:18 +0000 Received: from wfout5-smtp.messagingengine.com (wfout5-smtp.messagingengine.com [64.147.123.148]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 456c68c3-d90a-11ee-a1ee-f123f15fe8a2; Sun, 03 Mar 2024 04:01:04 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailfout.west.internal (Postfix) with ESMTP id C4A2E1C000A2; Sat, 2 Mar 2024 22:01:01 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Sat, 02 Mar 2024 22:01:02 -0500 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 2 Mar 2024 22:01:00 -0500 (EST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 456c68c3-d90a-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= invisiblethingslab.com; h=cc:cc:content-type:content-type:date :date:from:from:in-reply-to:message-id:mime-version:reply-to :subject:subject:to:to; s=fm1; t=1709434861; x=1709521261; bh=OX E5jTMpWnLk34Uici2HjXn8DLeyTAtcf0EXQsY1RfI=; b=jGwqQuMtRMN3lyMxi0 K1tyueIxG3Bo2haODWgzA4/JkmwE+80xIug+uXsD6dU25CpXeJKG1t+ex0mp6P4h EaCfChZERlrYJ6Ps8GcUcBo/1E36/qhrptkBcoTZ2TxEY7CpLKFFbPf3OOIzGVHe KOaTX3g+eK/VU0YOywngb6CxSo8Nvy+QH1OXwKjHjjCO0yioDlg8C+YF4BBhp8LL 1QM4/qUP/dH0RIIHr1b1Jw6//g2s81qASTCqmfae3HvUK9OOEEO5ohSbznVl2UKd jwYtlzDSVZPSK9evJmPKLUHtqNODk8OmE3F9rETW2X/RRSn5+cCzQYunuNGDjtnO 6T1A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:message-id :mime-version:reply-to:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1709434861; x=1709521261; bh=OXE5jTMpWnLk34Uici2HjXn8DLeyTAtcf0E XQsY1RfI=; b=rSdb6cTI/AAben2xGuz4LjYWQXgxz0VPWGbYkyQcKh5FSrPtva1 dE1e+tR3d3gKVhNKbjeO3Cqqxww6rIg889F7JLs9zt5TF3u3H7zxkqWYa4+hC5iy lPGZRX7vcfUA0Z7qPRzd5Jho+K+09F18L7c7hsnW1FEl4fO4EQuSC4KeryNMcJmq 07eBykMOABuyhjqSMDNodyKofKUfmUu93H9cqNeIW+znSkdGvmxw2xkKwSseN4pJ ovrKHNLLwvbktlJCbix0lFSNkAksNpWiuREhCrhbGe9Xq3SwaXhQav5w9mCqXxxg jT8rQVQNlg/q/RJZ/kXaMbz9rCr2LOBO3HA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrheeggdehfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvvefukfggtggusehgtderredttdejnecuhfhrohhmpeforghrvghkucfo rghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvhhish hisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpeeiffevkeeg gffguddviedufeduiedukeekffevieehvdevgfeivedvgefftddvueenucffohhmrghinh eplhhinhhugihfohhunhgurghtihhonhdrohhrghenucevlhhushhtvghrufhiiigvpedt necurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhesihhnvhhishhisghlvg hthhhinhhgshhlrggsrdgtohhm X-ME-Proxy: Feedback-ID: i1568416f:Fastmail Date: Sun, 3 Mar 2024 04:00:54 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: xen-devel Cc: Kelly Choi Subject: Link to the 2023 xen summit schedule is broken Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ukwSF5SVVZjSBj8X" Content-Disposition: inline --ukwSF5SVVZjSBj8X Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Sun, 3 Mar 2024 04:00:54 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: xen-devel Cc: Kelly Choi Subject: Link to the 2023 xen summit schedule is broken Hi, The link to the last year schedule at https://events.linuxfoundation.org/archive/2023/xen-project-summit/ is broken, it opens a page for upcoming "ONE summit" event that doesn't look to be related to Xen Summit. --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab --ukwSF5SVVZjSBj8X Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmXj5+cACgkQ24/THMrX 1yw7uQf+O9iRAB2QO9QRgxZo+m+2f9bqpAJSfaEjN/kcCZ2+8pw+hVsnOvCySuVG DtVqBloY7KN8ahz9bH1+IfguS8jYJFtPgen7qeIm7hOWu5yTQwDN0+5P3Amwy2Zi WRQlAKZ5vq/ZSrdHAB4P/0g/m0SnMrUVcHPPKh3QCekmyMkBwXBgLDVONYrFncPB +dbcnBEo7mmM1uyMIYsd2FRntHgym1L/ueCOlSsULzaFlmJHr/PMdqfJ98OvgGws Q4v2iaO52TzFrwM6cvc4+wCWcea8MsfWwTF4UxN0C2kqeaMdcUC52HWn+ZI6tX0a Xld0ztDBW0qkOxpsgTIfEY+dM/zpqw== =HxFV -----END PGP SIGNATURE----- --ukwSF5SVVZjSBj8X-- From xen-devel-bounces@lists.xenproject.org Sun Mar 03 04:49:46 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 03 Mar 2024 04:49:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688012.1071863 (Exim 4.92) (envelope-from ) id 1rgdn2-0000mO-2C; Sun, 03 Mar 2024 04:49:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688012.1071863; Sun, 03 Mar 2024 04:49:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgdn1-0000mH-VJ; Sun, 03 Mar 2024 04:49:31 +0000 Received: by outflank-mailman (input) for mailman id 688012; Sun, 03 Mar 2024 04:49:30 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgdn0-0000mB-DF for xen-devel@lists.xenproject.org; Sun, 03 Mar 2024 04:49:30 +0000 Received: from smtp-fw-52005.amazon.com (smtp-fw-52005.amazon.com [52.119.213.156]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 6905c17e-d919-11ee-a1ee-f123f15fe8a2; Sun, 03 Mar 2024 05:49:26 +0100 (CET) Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO smtpout.prod.us-west-2.prod.farcaster.email.amazon.dev) ([10.43.8.6]) by smtp-border-fw-52005.iad7.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Mar 2024 04:49:23 +0000 Received: from EX19MTAEUB002.ant.amazon.com [10.0.43.254:33619] by smtpin.naws.eu-west-1.prod.farcaster.email.amazon.dev [10.0.9.254:2525] with esmtp (Farcaster) id 0f94f4e3-8c8b-42ed-9481-e718686ab622; Sun, 3 Mar 2024 04:49:21 +0000 (UTC) Received: from EX19D026EUB004.ant.amazon.com (10.252.61.64) by EX19MTAEUB002.ant.amazon.com (10.252.51.59) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.28; Sun, 3 Mar 2024 04:49:21 +0000 Received: from uc3ecf78c6baf56.ant.amazon.com (10.187.170.45) by EX19D026EUB004.ant.amazon.com (10.252.61.64) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.28; Sun, 3 Mar 2024 04:49:18 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6905c17e-d919-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1709441366; x=1740977366; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=EcAkR74T37oaMFgDuTvxPlS3yLJ8+qDqwNv46qMyVV4=; b=vJvCPUowcs9mjlz38yg5SeXnN9n2yrVsQ2PWvYwE1JC3irXJ7UFzDF58 bwN80YFRBad1u5MDlHwy4uKyILPE0/UcCVcuMNUKADS5EiqnDdDsGAJrx auyeJGGx7DTWSRZTG+/u9vT63BACf57TqVD5dK0GOBinGxICpufgExClZ k=; X-IronPort-AV: E=Sophos;i="6.06,200,1705363200"; d="scan'208";a="638173303" X-Farcaster-Flow-ID: 0f94f4e3-8c8b-42ed-9481-e718686ab622 From: Andrew Paniakin To: CC: Benjamin Herrenschmidt , Andrew Panyakin , Maximilian Heyne , Boris Ostrovsky , Juergen Gross , "Stefano Stabellini" , Sasha Levin , "Greg Kroah-Hartman" , Julien Grall , , Subject: [PATCH 5.4] xen/events: close evtchn after mapping cleanup Date: Sat, 2 Mar 2024 20:45:39 -0800 Message-ID: <20240303044539.2673085-1-apanyaki@amazon.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.187.170.45] X-ClientProxiedBy: EX19D035UWA004.ant.amazon.com (10.13.139.109) To EX19D026EUB004.ant.amazon.com (10.252.61.64) From: Andrew Panyakin From: Maximilian Heyne Commit fa765c4b4aed2d64266b694520ecb025c862c5a9 upstream shutdown_pirq and startup_pirq are not taking the irq_mapping_update_lock because they can't due to lock inversion. Both are called with the irq_desc->lock being taking. The lock order, however, is first irq_mapping_update_lock and then irq_desc->lock. This opens multiple races: - shutdown_pirq can be interrupted by a function that allocates an event channel: CPU0 CPU1 shutdown_pirq { xen_evtchn_close(e) __startup_pirq { EVTCHNOP_bind_pirq -> returns just freed evtchn e set_evtchn_to_irq(e, irq) } xen_irq_info_cleanup() { set_evtchn_to_irq(e, -1) } } Assume here event channel e refers here to the same event channel number. After this race the evtchn_to_irq mapping for e is invalid (-1). - __startup_pirq races with __unbind_from_irq in a similar way. Because __startup_pirq doesn't take irq_mapping_update_lock it can grab the evtchn that __unbind_from_irq is currently freeing and cleaning up. In this case even though the event channel is allocated, its mapping can be unset in evtchn_to_irq. The fix is to first cleanup the mappings and then close the event channel. In this way, when an event channel gets allocated it's potential previous evtchn_to_irq mappings are guaranteed to be unset already. This is also the reverse order of the allocation where first the event channel is allocated and then the mappings are setup. On a 5.10 kernel prior to commit 3fcdaf3d7634 ("xen/events: modify internal [un]bind interfaces"), we hit a BUG like the following during probing of NVMe devices. The issue is that during nvme_setup_io_queues, pci_free_irq is called for every device which results in a call to shutdown_pirq. With many nvme devices it's therefore likely to hit this race during boot because there will be multiple calls to shutdown_pirq and startup_pirq are running potentially in parallel. ------------[ cut here ]------------ blkfront: xvda: barrier or flush: disabled; persistent grants: enabled; indirect descriptors: enabled; bounce buffer: enabled kernel BUG at drivers/xen/events/events_base.c:499! invalid opcode: 0000 [#1] SMP PTI CPU: 44 PID: 375 Comm: kworker/u257:23 Not tainted 5.10.201-191.748.amzn2.x86_64 #1 Hardware name: Xen HVM domU, BIOS 4.11.amazon 08/24/2006 Workqueue: nvme-reset-wq nvme_reset_work RIP: 0010:bind_evtchn_to_cpu+0xdf/0xf0 Code: 5d 41 5e c3 cc cc cc cc 44 89 f7 e8 2b 55 ad ff 49 89 c5 48 85 c0 0f 84 64 ff ff ff 4c 8b 68 30 41 83 fe ff 0f 85 60 ff ff ff <0f> 0b 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 0f 1f 44 00 00 RSP: 0000:ffffc9000d533b08 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006 RDX: 0000000000000028 RSI: 00000000ffffffff RDI: 00000000ffffffff RBP: ffff888107419680 R08: 0000000000000000 R09: ffffffff82d72b00 R10: 0000000000000000 R11: 0000000000000000 R12: 00000000000001ed R13: 0000000000000000 R14: 00000000ffffffff R15: 0000000000000002 FS: 0000000000000000(0000) GS:ffff88bc8b500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000002610001 CR4: 00000000001706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? show_trace_log_lvl+0x1c1/0x2d9 ? show_trace_log_lvl+0x1c1/0x2d9 ? set_affinity_irq+0xdc/0x1c0 ? __die_body.cold+0x8/0xd ? die+0x2b/0x50 ? do_trap+0x90/0x110 ? bind_evtchn_to_cpu+0xdf/0xf0 ? do_error_trap+0x65/0x80 ? bind_evtchn_to_cpu+0xdf/0xf0 ? exc_invalid_op+0x4e/0x70 ? bind_evtchn_to_cpu+0xdf/0xf0 ? asm_exc_invalid_op+0x12/0x20 ? bind_evtchn_to_cpu+0xdf/0xf0 ? bind_evtchn_to_cpu+0xc5/0xf0 set_affinity_irq+0xdc/0x1c0 irq_do_set_affinity+0x1d7/0x1f0 irq_setup_affinity+0xd6/0x1a0 irq_startup+0x8a/0xf0 __setup_irq+0x639/0x6d0 ? nvme_suspend+0x150/0x150 request_threaded_irq+0x10c/0x180 ? nvme_suspend+0x150/0x150 pci_request_irq+0xa8/0xf0 ? __blk_mq_free_request+0x74/0xa0 queue_request_irq+0x6f/0x80 nvme_create_queue+0x1af/0x200 nvme_create_io_queues+0xbd/0xf0 nvme_setup_io_queues+0x246/0x320 ? nvme_irq_check+0x30/0x30 nvme_reset_work+0x1c8/0x400 process_one_work+0x1b0/0x350 worker_thread+0x49/0x310 ? process_one_work+0x350/0x350 kthread+0x11b/0x140 ? __kthread_bind_mask+0x60/0x60 ret_from_fork+0x22/0x30 Modules linked in: ---[ end trace a11715de1eee1873 ]--- Fixes: d46a78b05c0e ("xen: implement pirq type event channels") Co-debugged-by: Andrew Panyakin Signed-off-by: Maximilian Heyne [apanyaki: backport to v5.4-stable] Signed-off-by: Andrew Paniakin --- Compare to upstream patch this one does not have close_evtchn flag because there is no need to handle static event channels. This feature was added only in 58f6259b7a08f ("xen/evtchn: Introduce new IOCTL to bind static evtchn") drivers/xen/events/events_base.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c index 91806dc1236d..f8554d9a9f28 100644 --- a/drivers/xen/events/events_base.c +++ b/drivers/xen/events/events_base.c @@ -825,8 +825,8 @@ static void shutdown_pirq(struct irq_data *data) return; do_mask(info, EVT_MASK_REASON_EXPLICIT); - xen_evtchn_close(evtchn); xen_irq_info_cleanup(info); + xen_evtchn_close(evtchn); } static void enable_pirq(struct irq_data *data) @@ -869,8 +869,6 @@ static void __unbind_from_irq(unsigned int irq) if (VALID_EVTCHN(evtchn)) { unsigned int cpu = cpu_from_irq(irq); - xen_evtchn_close(evtchn); - switch (type_from_irq(irq)) { case IRQT_VIRQ: per_cpu(virq_to_irq, cpu)[virq_from_irq(irq)] = -1; @@ -883,6 +881,7 @@ static void __unbind_from_irq(unsigned int irq) } xen_irq_info_cleanup(info); + xen_evtchn_close(evtchn); } xen_free_irq(irq); -- 2.40.1 From xen-devel-bounces@lists.xenproject.org Sun Mar 03 08:54:01 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 03 Mar 2024 08:54:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688034.1071900 (Exim 4.92) (envelope-from ) id 1rghbO-0002w8-0V; Sun, 03 Mar 2024 08:53:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688034.1071900; Sun, 03 Mar 2024 08:53:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rghbN-0002w1-UB; Sun, 03 Mar 2024 08:53:45 +0000 Received: by outflank-mailman (input) for mailman id 688034; Sun, 03 Mar 2024 08:53:44 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rghbM-0002vr-Be; Sun, 03 Mar 2024 08:53:44 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rghbM-0001ic-4y; Sun, 03 Mar 2024 08:53:44 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rghbL-0001PS-Sr; Sun, 03 Mar 2024 08:53:43 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rghbL-0004zx-S1; Sun, 03 Mar 2024 08:53:43 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=4tayHFMW4qQ05ZyMJoOFy+6NqHWiEUqFAKBj6l9/R64=; b=Xqy1nwAWuti4VnUFmo8tinUNfe phTwqqbIMQqDdM10/R7nOgHOfsA+nyK2JP6q+LQoZEDveOzOqGIXr2nRoNzIIJOkw6fv664cGi4Yv lGM/jqaZaWdskIwJ/grpXUks83/eE+0saw0LEgdG336zUXf0miPx3L2CgBlCHb3qSke0=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-6.1 test] 184841: tolerable FAIL - PUSHED X-Osstest-Failures: linux-6.1:test-amd64-amd64-libvirt-xsm:xen-boot:fail:heisenbug linux-6.1:test-amd64-amd64-xl-qemut-debianhvm-amd64:xen-boot:fail:heisenbug linux-6.1:test-amd64-amd64-xl-credit2:xen-boot:fail:heisenbug linux-6.1:test-amd64-coresched-amd64-xl:xen-boot:fail:heisenbug linux-6.1:test-armhf-armhf-libvirt-raw:xen-boot:fail:heisenbug linux-6.1:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-6.1:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-6.1:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-6.1:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-6.1:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking linux-6.1:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-6.1:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-6.1:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-6.1:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking linux-6.1:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-6.1:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-6.1:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-6.1:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-6.1:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-6.1:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-6.1:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-6.1:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-6.1:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-6.1:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-6.1:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-6.1:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-6.1:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-6.1:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-6.1:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-6.1:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-6.1:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-6.1:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-6.1:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-6.1:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-6.1:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-6.1:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-6.1:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking linux-6.1:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-6.1:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-6.1:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-6.1:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking linux-6.1:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking linux-6.1:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking linux-6.1:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking linux-6.1:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking linux-6.1:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking linux-6.1:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking linux-6.1:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-6.1:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-6.1:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-6.1:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: linux=a3eb3a74aa8c94e6c8130b55f3b031f29162868c X-Osstest-Versions-That: linux=81e1dc2f70014b9523dd02ca763788e4f81e5bac From: osstest service owner Date: Sun, 03 Mar 2024 08:53:43 +0000 flight 184841 linux-6.1 real [real] http://logs.test-lab.xenproject.org/osstest/logs/184841/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-libvirt-xsm 8 xen-boot fail in 184831 pass in 184841 test-amd64-amd64-xl-qemut-debianhvm-amd64 8 xen-boot fail in 184831 pass in 184841 test-amd64-amd64-xl-credit2 8 xen-boot fail in 184831 pass in 184841 test-amd64-coresched-amd64-xl 8 xen-boot fail in 184831 pass in 184841 test-armhf-armhf-libvirt-raw 8 xen-boot fail pass in 184831 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail in 184831 like 184734 test-armhf-armhf-libvirt-raw 14 migrate-support-check fail in 184831 never pass test-armhf-armhf-libvirt 16 saverestore-support-check fail like 184734 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop fail like 184734 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 184734 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop fail like 184734 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop fail like 184734 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop fail like 184734 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184734 test-amd64-amd64-libvirt-xsm 15 migrate-support-check fail never pass test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-check fail never pass test-arm64-arm64-xl 15 migrate-support-check fail never pass test-arm64-arm64-xl 16 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 15 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-check fail never pass test-armhf-armhf-libvirt 15 migrate-support-check fail never pass test-amd64-amd64-libvirt-qcow2 14 migrate-support-check fail never pass test-amd64-amd64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-check fail never pass test-arm64-arm64-xl-vhd 14 migrate-support-check fail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-check fail never pass version targeted for testing: linux a3eb3a74aa8c94e6c8130b55f3b031f29162868c baseline version: linux 81e1dc2f70014b9523dd02ca763788e4f81e5bac Last test of basis 184734 2024-02-23 08:41:05 Z 9 days Testing same since 184831 2024-03-01 12:45:09 Z 1 days 2 attempts ------------------------------------------------------------ People who touched revisions under test: "Christian A. Ehrhardt" Adam Goldman Alex Deucher Alexander Kobel Alexander Sverdlin Alexander Tsoy Alison Schofield Allen Pais Andi Shyti Andrew Bresticker Andrew Manley Andrew Morton Ard Biesheuvel Armin Wolf Arnd Bergmann Aurabindo Pillai Avihai Horon Baokun Li Bart Van Assche Bjorn Helgaas Borislav Petkov (AMD) Brenton Simpson Chen-Yu Tsai Chris Li Christian A. Ehrhardt Christian Brauner Colin Ian King Conor Dooley Conrad Kostecki Corey Minyard Cyril Hrubis Damien Le Moal Dan Carpenter Dan Williams Daniel Borkmann Daniel Vacek Daniel Wagner Daniel Wheeler Daniil Dulov Danilo Krummrich Dave Hansen David Hildenbrand David Howells David S. Miller Dennis Dalessandro Devyn Liu Dmitry Bogdanov Dmitry Torokhov Don Brace Edward Adam Davis Edward Lo Eric Dumazet Erik Kurzinger Eugen Hristev Felix Fietkau Florian Fainelli Florian Westphal Frank Li Fullway Wang Gao Xiang Geert Uytterhoeven Geliang Tang Geliang Tang Gianmarco Lusvardi Greg Kroah-Hartman Guenter Roeck Guixin Liu Hannes Reinecke Hans de Goede Hector Martin Heikki Krogerus Heiko Carstens Heiko Stuebner Heiko Stuebner Helge Deller Herbert Xu Horatiu Vultur Hou Tao Huacai Chen Huang Pei Ingo Molnar Ism Hong Jakub Kicinski Jamal Hadi Salim Jan Kiszka Jason Gunthorpe Jason Wang Jens Axboe Jeremy Kerr Jiri Pirko Joao Martins Johannes Berg Johannes Weiner John Fastabend Jon Hunter Julian Sikorski Justin Iurman Kairui Song Kalesh AP Kamal Heib Kees Cook Keith Busch Kelsey Steele kernelci.org bot Konstantin Komarov Krishna Kurapati Kuniyuki Iwashima Kunwu Chan Lennert Buytenhek Leon Romanovsky Lino Sanfilippo Linux Kernel Functional Testing Maarten van der Schrieck Maksim Kiselev Marc Zyngier Marek Szyprowski Mario Limonciello Mark Brown Martin Blumenstingl Martin K. Petersen Martin KaFai Lau Martin Povišer Masahiro Yamada Mat Martineau Mats Kronberg Matthieu Baerts (NGI0) Matthieu Baerts Mel Gorman Michael S. Tsirkin Michal Hocko Michal Kazior Mike Marciniszyn Mike Rapoport (IBM) Mike Snitzer Mikulas Patocka Mustafa Ismail Nam Cao Naohiro Aota Nathan Chancellor # build Nicolas Dichtel Nikita Shubin Niklas Cassel Niklas Schnelle Oliver Upton Pablo Neira Ayuso Paolo Abeni Paulo Alcantara Pavel Machek (CIP) Pavel Sakharov Pawel Laszczak Peter Chen Peter Oberparleiter Peter Zijlstra (Intel) Peter Zijlstra Petr Vorel Phoenix Chen Prike Liang Radhey Shyam Pandey Randy Dunlap Richard Fitzgerald Robert Richter Ron Economos Rémi Denis-Courmont Sabrina Dubroca Salvatore Bonaccorso Sandeep Dhavale Sasha Levin Selvin Xavier SEO HOYOUNG SeongJae Park Shakeel Butt Shanker Donthineni Shigeru Yoshida Shiraz Saleem Shuah Khan Shyam Prasad N Siddharth Vadapalli Simon Ser Sindhu Devale Sindhu Devale Sohaib Nadeem Song Liu Steve French Subbaraya Sundeep syzbot+fd7b34375c1c8ce29c93@syzkaller.appspotmail.com Szilard Fabian Szuying Chen Szuying Chen Takashi Iwai Takashi Sakamoto Theodore Ts'o Thinh Nguyen Thomas Bogendoerfer Thomas Gleixner Thomas Hellström Thorsten Winkler Tobias Waldekranz Tom Chung Tom Parkin Ulf Hansson Vasiliy Kovalev Vidya Sagar Vinod Koul Will Deacon Wolfram Sang Xin Long Xu Yang Yann Sionneau Yi Sun Yogesh Chandra Pandey Yosry Ahmed Yu Kuai Yu Zhao Yue Hu Zhang Rui Zhang Yi zhenwei pi Zhipeng Lu jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-amd64-dom0pvh-xl-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-freebsd11-amd64 pass test-amd64-amd64-freebsd12-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-examine-bios pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-amd64-dom0pvh-xl-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-amd64-xl-pvshim pass test-amd64-amd64-pygrub pass test-amd64-amd64-libvirt-qcow2 pass test-armhf-armhf-libvirt-qcow2 pass test-amd64-amd64-libvirt-raw pass test-arm64-arm64-libvirt-raw pass test-armhf-armhf-libvirt-raw fail test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-examine-uefi pass test-amd64-amd64-xl-vhd pass test-arm64-arm64-xl-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these 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 : hint: The 'hooks/update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-receive' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. To xenbits.xen.org:/home/xen/git/linux-pvops.git 81e1dc2f70014..a3eb3a74aa8c9 a3eb3a74aa8c94e6c8130b55f3b031f29162868c -> tested/linux-6.1 From xen-devel-bounces@lists.xenproject.org Sun Mar 03 11:41:14 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 03 Mar 2024 11:41:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688049.1071916 (Exim 4.92) (envelope-from ) id 1rgkDC-0003tO-Vh; Sun, 03 Mar 2024 11:40:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688049.1071916; Sun, 03 Mar 2024 11:40:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgkDC-0003tH-SN; Sun, 03 Mar 2024 11:40:58 +0000 Received: by outflank-mailman (input) for mailman id 688049; Sun, 03 Mar 2024 11:40:58 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgkDC-0003t7-0g; Sun, 03 Mar 2024 11:40:58 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgkDB-0004kj-UB; Sun, 03 Mar 2024 11:40:57 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgkDB-0005NR-IQ; Sun, 03 Mar 2024 11:40:57 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rgkDB-0003wS-I5; Sun, 03 Mar 2024 11:40:57 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=VcMPgJsG9NPgwChbb+XjD6VyjL0YDwvmvjq5MvRgQRY=; b=Z7hnhpmIC6u2Dt7RcH/zxrPgVW 4mLki9APJd75BnaUIeG34Z6sM4KxLjeJwpGRmNFdvKMm/Pir5mRAh7nzJsWu8nZxL8fc2HbCn+8mR lqy0c+uFeWHocvg+gOCdPiXLs4ZEO5JuzHs877X5ub9Z7ggHxpeAfRbw83g2u+7EwfNg=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable test] 184852: regressions - FAIL X-Osstest-Failures: xen-unstable:build-arm64-xsm:xen-build:fail:regression xen-unstable:test-amd64-amd64-xl-qemut-debianhvm-i386-xsm:debian-hvm-install:fail:regression xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:windows-install:fail:regression xen-unstable:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:build-check(1):blocked:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: xen=856664f774bd5b66301c5f9022126b61b8cb492d X-Osstest-Versions-That: xen=efad36f1ba18946acecc030166b1a6bebeb88ea2 From: osstest service owner Date: Sun, 03 Mar 2024 11:40:57 +0000 flight 184852 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/184852/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 6 xen-build fail REGR. vs. 184833 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail REGR. vs. 184833 test-amd64-amd64-xl-qemuu-win7-amd64 12 windows-install fail REGR. vs. 184833 Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail blocked in 184833 test-armhf-armhf-libvirt 16 saverestore-support-check fail like 184833 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop fail like 184833 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 184833 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop fail like 184833 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 184833 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 184833 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop fail like 184833 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 184833 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184833 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 184833 test-amd64-amd64-libvirt-xsm 15 migrate-support-check fail never pass test-amd64-i386-xl-pvshim 14 guest-start fail never pass test-amd64-i386-libvirt 15 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-check fail never pass test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-arm64-arm64-xl 15 migrate-support-check fail never pass test-arm64-arm64-xl 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 15 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 15 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-check fail never pass test-armhf-armhf-libvirt 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-check fail never pass test-amd64-i386-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-check fail never pass test-arm64-arm64-xl-vhd 14 migrate-support-check fail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-check fail never pass version targeted for testing: xen 856664f774bd5b66301c5f9022126b61b8cb492d baseline version: xen efad36f1ba18946acecc030166b1a6bebeb88ea2 Last test of basis 184833 2024-03-01 14:11:30 Z 1 days Testing same since 184852 2024-03-02 16:36:22 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Bertrand Marquis Roger Pau Monné Stefano Stabellini jobs: build-amd64-xsm pass build-arm64-xsm fail build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm fail test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm blocked test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm blocked test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-dom0pvh-xl-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-qemuu-freebsd11-amd64 pass test-amd64-amd64-qemuu-freebsd12-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-examine-bios pass test-amd64-i386-examine-bios pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-dom0pvh-xl-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-armhf-armhf-libvirt-qcow2 pass test-amd64-amd64-xl-qcow2 pass test-arm64-arm64-libvirt-raw pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-libvirt-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-examine-uefi pass test-amd64-i386-examine-uefi pass test-amd64-amd64-libvirt-vhd pass test-arm64-arm64-xl-vhd pass test-armhf-armhf-xl-vhd pass test-amd64-i386-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these 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 856664f774bd5b66301c5f9022126b61b8cb492d Author: Stefano Stabellini Date: Tue Feb 13 14:33:34 2024 -0800 docs/misra/rules.rst: add rule 14.4 Signed-off-by: Stefano Stabellini Acked-by: Bertrand Marquis commit c40bc0576dcc5acd4d7e22ef628eb4642f568533 Author: Roger Pau Monné Date: Fri Mar 1 13:42:27 2024 +0100 x86/mm: re-implement get_page_light() using an atomic increment The current usage of a cmpxchg loop to increase the value of page count is not optimal on amd64, as there's already an instruction to do an atomic add to a 64bit integer. Switch the code in get_page_light() to use an atomic increment, as that avoids a loop construct. This slightly changes the order of the checks, as current code will crash before modifying the page count_info if the conditions are not correct, while with the proposed change the crash will happen immediately after having carried the counter increase. Since we are crashing anyway, I don't believe the re-ordering to have any meaningful impact. Note that the page must already have a non-zero reference count which prevents the flags from changing, and the previous usage of the cmpxchg loop didn't guarantee that the rest of the fields in count_info didn't change while updating the reference count. Signed-off-by: Roger Pau Monné Reviewed-by: Andrew Cooper commit de17162cafd27f2865a3102a2ec0f386a02ed03d Author: Andrew Cooper Date: Thu Feb 29 11:26:40 2024 +0000 x86/cpu-policy: Allow for levelling of VERW side effects MD_CLEAR and FB_CLEAR need OR-ing across a migrate pool. Allow this, by having them unconditinally set in max, with the host values reflected in default. Annotate the bits as having special properies. Signed-off-by: Andrew Cooper Reviewed-by: Roger Pau Monné commit 0263dc9069ddb66335c72a159e09050b1600e56a Author: Andrew Cooper Date: Thu Feb 29 20:46:13 2024 +0000 tests/resource: Fix HVM guest in !SHADOW builds Right now, test-resource always creates HVM Shadow guests. But if Xen has SHADOW compiled out, running the test yields: $./test-resource XENMEM_acquire_resource tests Test x86 PV Created d1 Test grant table Test x86 PVH Skip: 95 - Operation not supported and doesn't really test HVM guests, but doesn't fail either. There's nothing paging-mode-specific about this test, so default to HAP if possible and provide a more specific message if neither HAP or Shadow are available. As we've got physinfo to hand, also provide more specific message about the absence of PV or HVM support. Signed-off-by: Andrew Cooper Acked-by: Roger Pau Monné commit e2d8a652251660c3252d92b442e1a9c5d6e6a1e9 Author: Andrew Cooper Date: Wed Feb 28 20:22:24 2024 +0000 x86/cpu-policy: Fix visibility of HTT/CMP_LEGACY in max policies The block in recalculate_cpuid_policy() predates the proper split between default and max policies, and was a "slightly max for a toolstack which knows about it" capability. It didn't get transformed properly in Xen 4.14. Because Xen will accept a VM with HTT/CMP_LEGACY seen, they should be visible in the max polices. Keep the default policy matching host settings. This manifested as an incorrectly-rejected migration across XenServer's Xen 4.13 -> 4.17 upgrade, as Xapi is slowly growing the logic to check a VM against the target max policy. Signed-off-by: Andrew Cooper Reviewed-by: Roger Pau Monné commit 5420aa165dfa5fe95dd84bb71cb96c15459935b1 Author: Andrew Cooper Date: Wed Feb 28 20:21:58 2024 +0000 x86/cpu-policy: Hide x2APIC from PV guests PV guests can't write to MSR_APIC_BASE (in order to set EXTD), nor can they access any of the x2APIC MSR range. Therefore they mustn't see the x2APIC CPUID bit saying that they can. Right now, the host x2APIC flag filters into PV guests, meaning that PV guests generally see x2APIC except on Zen1-and-older AMD systems. Linux works around this by explicitly hiding the bit itself, and filtering EXTD out of MSR_APIC_BASE reads. NetBSD behaves more in the spirit of PV guests, and entirely ignores the APIC when built as a PV guest. Change the annotation from !A to !S. This has a consequence of stripping it out of both PV featuremasks. However, as existing guests may have seen the bit, set it back into the PV Max policy; a VM which saw the bit and is alive enough to migrate will have ignored it one way or another. Hiding x2APIC does change the contents of leaf 0xb, but as the information is nonsense to begin with, this is likely an improvement on the status quo. Xen's blind assumption that APIC_ID = vCPU_ID * 2 isn't interlinked with the host's topology structure, where a PV guest may see real host values, and the APIC_IDs are useless without an MADT to start with. Dom0 is the only PV VM to get an MADT but it's the host one, meaning the two sets of APIC_IDs are from different address spaces. Signed-off-by: Andrew Cooper Reviewed-by: Roger Pau Monné (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Sun Mar 03 16:59:33 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 03 Mar 2024 16:59:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688098.1071939 (Exim 4.92) (envelope-from ) id 1rgpB7-0002ma-33; Sun, 03 Mar 2024 16:59:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688098.1071939; Sun, 03 Mar 2024 16:59:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgpB6-0002mT-UQ; Sun, 03 Mar 2024 16:59:08 +0000 Received: by outflank-mailman (input) for mailman id 688098; Sun, 03 Mar 2024 16:59:08 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgpB6-0002mJ-3Y; Sun, 03 Mar 2024 16:59:08 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgpB5-0002K7-QR; Sun, 03 Mar 2024 16:59:07 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgpB5-0003by-KC; Sun, 03 Mar 2024 16:59:07 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rgpB5-0006qj-JX; Sun, 03 Mar 2024 16:59:07 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=xV4wX6E0RA+ivw4P+d9xZ9RG5jAdkF3HP/FKyc26QeY=; b=H/5X5NVCKYF0nP8WRSwrDQBT+M qHieZ9E6Xr+pk25hZINuyMILY7vMADKAXRsuKsFzadhdKtq0YjU/Pi2WqtOpBlyqHKrP+HL7cVch6 oZ1kyjTemFmxPKN1YnMeNmMCwt21CL0CKaX4xXO8ZdteJg1VQrEu49zUahDWr1xmkypY=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-linus test] 184861: tolerable FAIL - PUSHED X-Osstest-Failures: linux-linus:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:heisenbug linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: linux=04b8076df2534f08bb4190f90a24e0f7f8930aca X-Osstest-Versions-That: linux=87adedeba51a822533649b143232418b9e26d08b From: osstest service owner Date: Sun, 03 Mar 2024 16:59:07 +0000 flight 184861 linux-linus real [real] flight 184877 linux-linus real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/184861/ http://logs.test-lab.xenproject.org/osstest/logs/184877/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 12 debian-hvm-install fail pass in 184877-retest Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop fail like 184835 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop fail like 184835 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop fail like 184835 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 184835 test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail like 184835 test-armhf-armhf-libvirt 16 saverestore-support-check fail like 184835 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop fail like 184835 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184835 test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl 15 migrate-support-check fail never pass test-arm64-arm64-xl 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 15 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 15 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qcow2 14 migrate-support-check fail never pass test-amd64-amd64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-check fail never pass test-arm64-arm64-xl-vhd 14 migrate-support-check fail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-check fail never pass test-armhf-armhf-libvirt 15 migrate-support-check fail never pass version targeted for testing: linux 04b8076df2534f08bb4190f90a24e0f7f8930aca baseline version: linux 87adedeba51a822533649b143232418b9e26d08b Last test of basis 184835 2024-03-01 17:44:20 Z 1 days Testing same since 184861 2024-03-03 00:29:43 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Adam Goldman Adrian Hunter Alex Deucher Alex Hung Alexandre Ghiti Alexandru Gagniuc Andy Chiu Andy Shevchenko Ard Biesheuvel Arnd Bergmann Arturas Moskvinas Bart Van Assche Bartosz Golaszewski Bjorn Andersson Chandan Babu R Christian Brauner Christian König Christophe Kerello Colin Ian King Conor Dooley Conor Dooley Cristian Marussi Dan Williams Daniel Vetter Dave Airlie David Howells David Sterba Dimitris Vlachos Dmitry Baryshkov Elad Nachman Eniac Zhang Eric Biggers Fei Wu Filipe Manana Francois Dugast Gergo Koteles Guo Ren Hans de Goede Hans Peter Ilya Dryomov Ivan Semenov Jaroslav Kysela Jason Gunthorpe Jay Ajit Mate Jiawei Wang Jiri Olsa Jiri Slaby (SUSE) Jisheng Zhang Joerg Roedel Johan Hovold John Garry #build only Johnny Hsieh Jon Hunter José Roberto de Souza Kailang Yang Linus Torvalds Luca Ceresoli Lucas De Marchi Ma Jun Maarten Lankhorst Mark Brown Martin K. Petersen Masahiro Yamada Masami Hiramatsu (Google) Matthew Auld Matthew Brost Maxime Ripard Maxime Ripard Mika Kuoppala Mikko Perttunen Ming Lei Namjae Jeon Nathan Chancellor Neil Armstrong Neil Armstrong # on SM8650-HDK Nicolin Chen Palmer Dabbelt Paloma Arellano Paul Walmsley Paulo Zanoni Prike Liang Priyanka Dandamudi Ranjan Kumar Richard Fitzgerald Rob Clark Rob Clark Rob Herring Robert Foss Rodrigo Vivi Ryan Lin Samuel Holland Saravana Kannan Sebastian Reichel Shiyang Ruan Sid Pranjale Srinivasan Shanmugam Takashi Iwai Takashi Sakamoto Tetsuo Handa Thierry Reding Thomas Hellstrom Thomas Hellström Thomas Weißschuh Tim Schumacher Ulf Hansson Vadim Shakirov Willian Wang Xiubo Li Yangyu Chen Yuezhang Mo Zhangfei Gao Zong Li jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm fail test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-amd64-dom0pvh-xl-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-freebsd11-amd64 pass test-amd64-amd64-freebsd12-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-examine-bios pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-amd64-dom0pvh-xl-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-amd64-xl-pvshim pass test-amd64-amd64-pygrub pass test-amd64-amd64-libvirt-qcow2 pass test-armhf-armhf-libvirt-qcow2 pass test-amd64-amd64-libvirt-raw pass test-arm64-arm64-libvirt-raw pass test-armhf-armhf-libvirt-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-examine-uefi pass test-amd64-amd64-xl-vhd pass test-arm64-arm64-xl-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these 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 : hint: The 'hooks/update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-receive' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. To xenbits.xen.org:/home/xen/git/linux-pvops.git 87adedeba51a8..04b8076df2534 04b8076df2534f08bb4190f90a24e0f7f8930aca -> tested/linux-linus From xen-devel-bounces@lists.xenproject.org Sun Mar 03 19:49:42 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 03 Mar 2024 19:49:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688110.1071955 (Exim 4.92) (envelope-from ) id 1rgrpx-0003W3-2S; Sun, 03 Mar 2024 19:49:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688110.1071955; Sun, 03 Mar 2024 19:49:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgrpw-0003Vw-UI; Sun, 03 Mar 2024 19:49:28 +0000 Received: by outflank-mailman (input) for mailman id 688110; Sun, 03 Mar 2024 19:49:27 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgrpv-0003Vm-D4; Sun, 03 Mar 2024 19:49:27 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgrpv-0005DW-9j; Sun, 03 Mar 2024 19:49:27 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgrpu-000699-Vd; Sun, 03 Mar 2024 19:49:27 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rgrpu-0006gT-V9; Sun, 03 Mar 2024 19:49:26 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=ROkRM07gJfBS8gD4nCazNDWBlSt4kygb58sVaC5vqV8=; b=BGHPIGTMdI1SAkVEZgNnIBxG93 QOt0KP2JUcUTek7usgTr2CcIH0vdMFgzt0Weq+qlAzfkWsNGFvEO1EFWUc4K6BvFO8RKanNaRpcQE pZHbskbtFwOLqGOAftwy1WBlpilPgvSsuhIXbnCBMO7aJJWK0v23wvkCZt3cqtjptN/w=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable test] 184875: regressions - FAIL X-Osstest-Failures: xen-unstable:test-amd64-amd64-xl-qemut-debianhvm-i386-xsm:guest-localmigrate/x10:fail:regression xen-unstable:build-arm64-pvops:kernel-build:fail:regression xen-unstable:build-arm64-xsm:xen-build:fail:regression xen-unstable:test-amd64-amd64-xl-qemut-debianhvm-i386-xsm:debian-hvm-install:fail:heisenbug xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:windows-install:fail:heisenbug xen-unstable:test-armhf-armhf-libvirt-qcow2:guest-start:fail:heisenbug xen-unstable:test-arm64-arm64-examine:build-check(1):blocked:nonblocking xen-unstable:test-arm64-arm64-libvirt-raw:build-check(1):blocked:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking xen-unstable:test-arm64-arm64-xl:build-check(1):blocked:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:build-check(1):blocked:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:build-check(1):blocked:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:build-check(1):blocked:nonblocking xen-unstable:test-arm64-arm64-xl-vhd:build-check(1):blocked:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:build-check(1):blocked:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=856664f774bd5b66301c5f9022126b61b8cb492d X-Osstest-Versions-That: xen=efad36f1ba18946acecc030166b1a6bebeb88ea2 From: osstest service owner Date: Sun, 03 Mar 2024 19:49:26 +0000 flight 184875 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/184875/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 18 guest-localmigrate/x10 fail REGR. vs. 184833 build-arm64-pvops 6 kernel-build fail REGR. vs. 184833 build-arm64-xsm 6 xen-build fail in 184852 REGR. vs. 184833 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail in 184852 pass in 184875 test-amd64-amd64-xl-qemuu-win7-amd64 12 windows-install fail in 184852 pass in 184875 test-armhf-armhf-libvirt-qcow2 13 guest-start fail pass in 184852 Tests which did not succeed, but are not blocking: test-arm64-arm64-examine 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-raw 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit1 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-thunderx 1 build-check(1) blocked n/a test-arm64-arm64-xl-vhd 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail blocked in 184833 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail in 184852 like 184833 test-arm64-arm64-xl 15 migrate-support-check fail in 184852 never pass test-arm64-arm64-xl 16 saverestore-support-check fail in 184852 never pass test-arm64-arm64-xl-credit2 15 migrate-support-check fail in 184852 never pass test-arm64-arm64-xl-thunderx 15 migrate-support-check fail in 184852 never pass test-arm64-arm64-xl-credit2 16 saverestore-support-check fail in 184852 never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-check fail in 184852 never pass test-arm64-arm64-xl-credit1 15 migrate-support-check fail in 184852 never pass test-arm64-arm64-xl-credit1 16 saverestore-support-check fail in 184852 never pass test-arm64-arm64-libvirt-raw 14 migrate-support-check fail in 184852 never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-check fail in 184852 never pass test-arm64-arm64-xl-vhd 14 migrate-support-check fail in 184852 never pass test-arm64-arm64-xl-vhd 15 saverestore-support-check fail in 184852 never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-check fail in 184852 never pass test-armhf-armhf-libvirt 16 saverestore-support-check fail like 184833 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop fail like 184833 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 184833 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop fail like 184833 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 184833 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 184833 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop fail like 184833 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184833 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 184833 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop fail like 184833 test-amd64-amd64-libvirt-xsm 15 migrate-support-check fail never pass test-amd64-i386-xl-pvshim 14 guest-start fail never pass test-amd64-i386-libvirt 15 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-check fail never pass test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 15 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-check fail never pass test-armhf-armhf-libvirt 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-check fail never pass test-amd64-i386-libvirt-raw 14 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass version targeted for testing: xen 856664f774bd5b66301c5f9022126b61b8cb492d baseline version: xen efad36f1ba18946acecc030166b1a6bebeb88ea2 Last test of basis 184833 2024-03-01 14:11:30 Z 2 days Testing same since 184852 2024-03-02 16:36:22 Z 1 days 2 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Bertrand Marquis Roger Pau Monné Stefano Stabellini jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops fail build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl blocked test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm fail test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm blocked test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm blocked test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-dom0pvh-xl-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-qemuu-freebsd11-amd64 pass test-amd64-amd64-qemuu-freebsd12-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-examine-bios pass test-amd64-i386-examine-bios pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 blocked test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 blocked test-armhf-armhf-xl-credit2 pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine blocked test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-dom0pvh-xl-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-armhf-armhf-libvirt-qcow2 fail test-amd64-amd64-xl-qcow2 pass test-arm64-arm64-libvirt-raw blocked test-armhf-armhf-libvirt-raw pass test-amd64-i386-libvirt-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx blocked test-amd64-amd64-examine-uefi pass test-amd64-i386-examine-uefi pass test-amd64-amd64-libvirt-vhd pass test-arm64-arm64-xl-vhd blocked test-armhf-armhf-xl-vhd pass test-amd64-i386-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these 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 856664f774bd5b66301c5f9022126b61b8cb492d Author: Stefano Stabellini Date: Tue Feb 13 14:33:34 2024 -0800 docs/misra/rules.rst: add rule 14.4 Signed-off-by: Stefano Stabellini Acked-by: Bertrand Marquis commit c40bc0576dcc5acd4d7e22ef628eb4642f568533 Author: Roger Pau Monné Date: Fri Mar 1 13:42:27 2024 +0100 x86/mm: re-implement get_page_light() using an atomic increment The current usage of a cmpxchg loop to increase the value of page count is not optimal on amd64, as there's already an instruction to do an atomic add to a 64bit integer. Switch the code in get_page_light() to use an atomic increment, as that avoids a loop construct. This slightly changes the order of the checks, as current code will crash before modifying the page count_info if the conditions are not correct, while with the proposed change the crash will happen immediately after having carried the counter increase. Since we are crashing anyway, I don't believe the re-ordering to have any meaningful impact. Note that the page must already have a non-zero reference count which prevents the flags from changing, and the previous usage of the cmpxchg loop didn't guarantee that the rest of the fields in count_info didn't change while updating the reference count. Signed-off-by: Roger Pau Monné Reviewed-by: Andrew Cooper commit de17162cafd27f2865a3102a2ec0f386a02ed03d Author: Andrew Cooper Date: Thu Feb 29 11:26:40 2024 +0000 x86/cpu-policy: Allow for levelling of VERW side effects MD_CLEAR and FB_CLEAR need OR-ing across a migrate pool. Allow this, by having them unconditinally set in max, with the host values reflected in default. Annotate the bits as having special properies. Signed-off-by: Andrew Cooper Reviewed-by: Roger Pau Monné commit 0263dc9069ddb66335c72a159e09050b1600e56a Author: Andrew Cooper Date: Thu Feb 29 20:46:13 2024 +0000 tests/resource: Fix HVM guest in !SHADOW builds Right now, test-resource always creates HVM Shadow guests. But if Xen has SHADOW compiled out, running the test yields: $./test-resource XENMEM_acquire_resource tests Test x86 PV Created d1 Test grant table Test x86 PVH Skip: 95 - Operation not supported and doesn't really test HVM guests, but doesn't fail either. There's nothing paging-mode-specific about this test, so default to HAP if possible and provide a more specific message if neither HAP or Shadow are available. As we've got physinfo to hand, also provide more specific message about the absence of PV or HVM support. Signed-off-by: Andrew Cooper Acked-by: Roger Pau Monné commit e2d8a652251660c3252d92b442e1a9c5d6e6a1e9 Author: Andrew Cooper Date: Wed Feb 28 20:22:24 2024 +0000 x86/cpu-policy: Fix visibility of HTT/CMP_LEGACY in max policies The block in recalculate_cpuid_policy() predates the proper split between default and max policies, and was a "slightly max for a toolstack which knows about it" capability. It didn't get transformed properly in Xen 4.14. Because Xen will accept a VM with HTT/CMP_LEGACY seen, they should be visible in the max polices. Keep the default policy matching host settings. This manifested as an incorrectly-rejected migration across XenServer's Xen 4.13 -> 4.17 upgrade, as Xapi is slowly growing the logic to check a VM against the target max policy. Signed-off-by: Andrew Cooper Reviewed-by: Roger Pau Monné commit 5420aa165dfa5fe95dd84bb71cb96c15459935b1 Author: Andrew Cooper Date: Wed Feb 28 20:21:58 2024 +0000 x86/cpu-policy: Hide x2APIC from PV guests PV guests can't write to MSR_APIC_BASE (in order to set EXTD), nor can they access any of the x2APIC MSR range. Therefore they mustn't see the x2APIC CPUID bit saying that they can. Right now, the host x2APIC flag filters into PV guests, meaning that PV guests generally see x2APIC except on Zen1-and-older AMD systems. Linux works around this by explicitly hiding the bit itself, and filtering EXTD out of MSR_APIC_BASE reads. NetBSD behaves more in the spirit of PV guests, and entirely ignores the APIC when built as a PV guest. Change the annotation from !A to !S. This has a consequence of stripping it out of both PV featuremasks. However, as existing guests may have seen the bit, set it back into the PV Max policy; a VM which saw the bit and is alive enough to migrate will have ignored it one way or another. Hiding x2APIC does change the contents of leaf 0xb, but as the information is nonsense to begin with, this is likely an improvement on the status quo. Xen's blind assumption that APIC_ID = vCPU_ID * 2 isn't interlinked with the host's topology structure, where a PV guest may see real host values, and the APIC_IDs are useless without an MADT to start with. Dom0 is the only PV VM to get an MADT but it's the host one, meaning the two sets of APIC_IDs are from different address spaces. Signed-off-by: Andrew Cooper Reviewed-by: Roger Pau Monné (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Mon Mar 04 04:24:21 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 04:24:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688132.1071985 (Exim 4.92) (envelope-from ) id 1rgzry-0007L7-O9; Mon, 04 Mar 2024 04:24:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688132.1071985; Mon, 04 Mar 2024 04:24:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgzry-0007L0-LI; Mon, 04 Mar 2024 04:24:06 +0000 Received: by outflank-mailman (input) for mailman id 688132; Mon, 04 Mar 2024 04:24:05 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgzrx-0007Kq-E6; Mon, 04 Mar 2024 04:24:05 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgzrx-0005WE-B4; Mon, 04 Mar 2024 04:24:05 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rgzrx-00060H-00; Mon, 04 Mar 2024 04:24:05 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rgzrw-00058v-Vo; Mon, 04 Mar 2024 04:24:04 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=r3HIKTt1G+q3pjnoOEb5DRnwnXbqR+y4zZCamM1XQsc=; b=51V+VckPW2jq+qSVI3nM0y8JOw QBIcPzP3zS5TQA+vMCcnFIiU/nHISO8IczMlJqsFfzzbusx4pY/rEl/pFPg0bmfeDwclN4+Bh+Ru6 iK300AtuDtWjMeKP1bc3GTJb2zv+lcshEQHSCSCrimS1yEFqd/uFEH/41KFTekwPrO3A=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-linus test] 184880: tolerable FAIL - PUSHED X-Osstest-Failures: linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: linux=58c806d867bf265c6fd16fc3bc62e2d3c156b5c9 X-Osstest-Versions-That: linux=04b8076df2534f08bb4190f90a24e0f7f8930aca From: osstest service owner Date: Mon, 04 Mar 2024 04:24:04 +0000 flight 184880 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/184880/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop fail like 184861 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop fail like 184861 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop fail like 184861 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 184861 test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail like 184861 test-armhf-armhf-libvirt 16 saverestore-support-check fail like 184861 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop fail like 184861 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184861 test-amd64-amd64-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl 15 migrate-support-check fail never pass test-arm64-arm64-xl 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 15 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 15 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qcow2 14 migrate-support-check fail never pass test-amd64-amd64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-check fail never pass test-arm64-arm64-xl-vhd 14 migrate-support-check fail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-check fail never pass test-armhf-armhf-libvirt 15 migrate-support-check fail never pass version targeted for testing: linux 58c806d867bf265c6fd16fc3bc62e2d3c156b5c9 baseline version: linux 04b8076df2534f08bb4190f90a24e0f7f8930aca Last test of basis 184861 2024-03-03 00:29:43 Z 1 days Testing same since 184880 2024-03-03 18:14:43 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Abel Vesa Alexander Stein Borislav Petkov (AMD) Curtis Klein Dave Hansen Dmitry Baryshkov Elliot Berman # sm8650-qrd Fenghua Yu Frank Li Gaurav Batra Jiri Bohac Joy Zou Kory Maincent Linus Torvalds Manivannan Sadhasivam Michael Ellerman Nathan Lynch Paolo Bonzini Peng Ma Tadeusz Struk Tony Zhu Vinod Koul Yang Yingliang Yi Zhao jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-amd64-dom0pvh-xl-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-freebsd11-amd64 pass test-amd64-amd64-freebsd12-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-examine-bios pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-amd64-dom0pvh-xl-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-amd64-xl-pvshim pass test-amd64-amd64-pygrub pass test-amd64-amd64-libvirt-qcow2 pass test-armhf-armhf-libvirt-qcow2 pass test-amd64-amd64-libvirt-raw pass test-arm64-arm64-libvirt-raw pass test-armhf-armhf-libvirt-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-examine-uefi pass test-amd64-amd64-xl-vhd pass test-arm64-arm64-xl-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these 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 : hint: The 'hooks/update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-receive' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. To xenbits.xen.org:/home/xen/git/linux-pvops.git 04b8076df2534..58c806d867bf2 58c806d867bf265c6fd16fc3bc62e2d3c156b5c9 -> tested/linux-linus From xen-devel-bounces@lists.xenproject.org Mon Mar 04 07:25:40 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 07:25:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688157.1072007 (Exim 4.92) (envelope-from ) id 1rh2hT-0001q8-JZ; Mon, 04 Mar 2024 07:25:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688157.1072007; Mon, 04 Mar 2024 07:25:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh2hT-0001q1-H2; Mon, 04 Mar 2024 07:25:27 +0000 Received: by outflank-mailman (input) for mailman id 688157; Mon, 04 Mar 2024 07:25:26 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh2hS-0001pv-7h for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 07:25:26 +0000 Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [2a00:1450:4864:20::52d]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 5db9fd73-d9f8-11ee-afda-a90da7624cb6; Mon, 04 Mar 2024 08:25:24 +0100 (CET) Received: by mail-ed1-x52d.google.com with SMTP id 4fb4d7f45d1cf-565d1656c12so7216180a12.1 for ; Sun, 03 Mar 2024 23:25:24 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id u17-20020a056402111100b0056729e902f7sm1507882edv.56.2024.03.03.23.25.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 03 Mar 2024 23:25:23 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 5db9fd73-d9f8-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709537124; x=1710141924; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=+Q3KZ2WtVF7i6fMn4u4hmT38MdFFnvKR0PgAtrFTw9g=; b=W6VK2cE5Z3+95miykXugOTmDZIQiHFLEctFxlMsxmHy1CE9Q/SRuA4dKoBxJvgNvWN Ej9ckywxE18yYtbLsGFLdM8/s8uSX7Y7Mk7bMnczq0KuUOV9hFwnuQ/IQExqntgGF814 86eqXXMmwMbyqK/seEdlnwDWZrOk2y2tn8E+J4/oHFwowAPcw/ql61fVTTVMfL7cZd/e 8FjVDWAlmDlqJzlr0PswCLE+YclnUn8vthabfHtJ2GmlSBAzdQDqtJOTwUkx3c//AK9K t/XFkLx+frC/yl/OwZn9CBN0EJPEqvAftPgoZteTbG2YIZxwOeMYJgjgMwHXqbz7BURu oU/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709537124; x=1710141924; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=+Q3KZ2WtVF7i6fMn4u4hmT38MdFFnvKR0PgAtrFTw9g=; b=vCIryn/sD3EhCtE9sUZEV5u/J4wYAVdaHod2wfBtogX33j+RL9s6AaT9kXFg9Xk1dV 9ec54i/wkmSTT1weSur2fPfbFwCwu6tOOCpRGHNUIcneX3WwZ08Dt9r6YcC8RNFuxLJl 5DafHDggFW7CT46IFDJ0b7iDtgML1pqADRnLHVJgE5kV6PfhHleIAtLqBapIbmZTHP/b S4TeqOvfs0SR3NmQplbfF0CqrnCU26IzDjT7mN4SDyAY61UxPfMQsNqi+NgE8dnJTC6C QWJ5ApF8JthVI2oltIjKCyens+qmKmB6npEmZ/nYBq1USDguQnOeD88gtJHceF2K3txk GxIg== X-Forwarded-Encrypted: i=1; AJvYcCXfqYDMjAoC3Lw6jHds1M7+dViEoJI1H/X+OEigQmKnNp3j8IQXb1uY9/1bbF2vQcW8INdA40hU15CSqJL4Tdu62P2D5g+kCnPhzCl3TwI= X-Gm-Message-State: AOJu0Ywu4ztLMWela+6Ch2RQBFR2cjc8WjgFd+yIk9ftLBSa85i/vfM4 9C3SYJzF/9my/iYp1SGukhgAgyBsoAckKqn3PPNWZcHIiY4RxaL+j0LleoFdHg== X-Google-Smtp-Source: AGHT+IF41mcKJifwGSYi3e/xmyfEQm/pYR/KYz///8Ow4Rs2itbPF76c/FPlPmQx+y/J76iuWOESYg== X-Received: by 2002:aa7:dbcb:0:b0:567:683:11bb with SMTP id v11-20020aa7dbcb000000b00567068311bbmr4121505edt.20.1709537124194; Sun, 03 Mar 2024 23:25:24 -0800 (PST) Message-ID: Date: Mon, 4 Mar 2024 08:25:23 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 10/12] xen/spinlock: split recursive spinlocks from normal ones To: Juergen Gross Cc: Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu , xen-devel@lists.xenproject.org References: <20231212094725.22184-1-jgross@suse.com> <20231212094725.22184-11-jgross@suse.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 01.03.2024 15:37, Juergen Gross wrote: > On 29.02.24 16:32, Jan Beulich wrote: >> On 12.12.2023 10:47, Juergen Gross wrote: >>> +#define nrspin_lock_irqsave(l, f) \ >>> + ({ \ >>> + BUILD_BUG_ON(sizeof(f) != sizeof(unsigned long)); \ >>> + ((f) = __nrspin_lock_irqsave(l)); \ >> >> I don't think the outer pair of parentheses is needed here. > > Turns out it is needed. Otherwise something like: > > > if ( a ) > nrspin_lock_irqsave(l, f); > else > ... > > will fail with "else without a previous if". That's for "outer" in the whole #define I suppose, when I commented on just a specific line inside the construct. The ({ ... }) may better be avoided here too, for there being no reason to use a compiler extension when do { ... } while ( false ) would also do. Things would be different in the construct "returned" the flags value, in a more function-like manner. But that would be inconsistent with related similar functions. Jan From xen-devel-bounces@lists.xenproject.org Mon Mar 04 07:29:39 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 07:29:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688160.1072021 (Exim 4.92) (envelope-from ) id 1rh2lW-0002RN-5w; Mon, 04 Mar 2024 07:29:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688160.1072021; Mon, 04 Mar 2024 07:29:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh2lW-0002RG-3F; Mon, 04 Mar 2024 07:29:38 +0000 Received: by outflank-mailman (input) for mailman id 688160; Mon, 04 Mar 2024 07:29:37 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh2lV-0002R5-36 for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 07:29:37 +0000 Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [2a00:1450:4864:20::62e]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id f31aa2e4-d9f8-11ee-a1ee-f123f15fe8a2; Mon, 04 Mar 2024 08:29:35 +0100 (CET) Received: by mail-ej1-x62e.google.com with SMTP id a640c23a62f3a-a44cf608a39so162494966b.0 for ; Sun, 03 Mar 2024 23:29:35 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id gt25-20020a170906f21900b00a3ec216ec6csm4390230ejb.45.2024.03.03.23.29.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 03 Mar 2024 23:29:34 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f31aa2e4-d9f8-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709537374; x=1710142174; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=L1okNdYKKWc+5ObUqf2slTpzoSiSxY3lpzPn4YnJEsk=; b=UMHUDJIFLhwbpyvYG2TsxxZd6iIG0ayVehrP2YMOQqjsviJ02Tx8p19KQrOM+N3VzN zYx9ebzWnsU7fSRoZrM71N5oPUl2swuOQs6PbF7xzNkU6jllUc81/xD9Co3E3yYqffUC 5/polJ6OoqR0V+GExayGALqiDB7IM5vGvpYo+7/1PsgV1NOfkw8kKdZ7h67+mSlVvAXJ tFElsXDK8XFg/r2Jze75ODf3jRnXvLq7I6UPRgN8uYuWEfRZ0IZCx/K+anlsitbJ+4Wu r4JJ3nJySev6IQmqH2tsRz/fClkEKWHG7UQGWmtzOWA5i+YgoezSNGZjZUDYqVlqY7US CF1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709537374; x=1710142174; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=L1okNdYKKWc+5ObUqf2slTpzoSiSxY3lpzPn4YnJEsk=; b=cJrw4mIyYtaWeJdMb6CbLkak/fSnDklgpKqkZhuPIAanFcYIpkr9kQpi9gFiq4toJf CcjvPTQbDz6C/3DJA/0yDYtwuUjXJbVI+NBm7i9eXeXbAjZAl1bn/ZZvA238gTTkL/et lCeD20uDW+43ZKeoZDBmIcVrDcqBNs4lTK4ZY4lCw0eR5/kvevrM9B2XJjoYQ1V7F3nh lV4AYns4HFCYvsNTrqqWHDiY/jlD/IHUtsEk2s2I4Sy8wDOdBU4llMxw7jOJWiqnN02/ 8mzKHlKeF3GVKMl6ing7kIRBjCZdfOyL1OrKzmVw8ubHVYx9pwGKj7PUDpi6jWN3rr1g TxTw== X-Gm-Message-State: AOJu0YyZrQD1lKLONP33IuoIQ4G7leYN1hNFzOf+tA8OUgODTpV1tx1m oTvVqy1VLNST8xl/17iImtxqZHazE0hEjOKcot+T3M/IqrxSDnrGiEawxKqrHQ== X-Google-Smtp-Source: AGHT+IFhmrSbg+iWaY6sIHRO5JN1W+QkZZ/aiYTZNMJ/kmhQ/2xzfhobcu0k5o41iC40VaPdbqjVTA== X-Received: by 2002:a17:906:e285:b0:a45:2d35:39b2 with SMTP id gg5-20020a170906e28500b00a452d3539b2mr1601919ejb.22.1709537374477; Sun, 03 Mar 2024 23:29:34 -0800 (PST) Message-ID: Date: Mon, 4 Mar 2024 08:29:35 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: hvmloader - allow_memory_relocate overlaps Content-Language: en-US To: Neowutran Cc: xen-devel@lists.xenproject.org, Anthony Perard , George Dunlap References: <7oe275z3eap7rhdwmrm4mvqnjnhrpag5cjwnfvwsf7rchhkyjv@pd3abzwdhg6v> <217649a9-8399-48d3-ba49-ae22cacf0d4b@suse.com> <1c857c96-9f2d-4787-8804-799a63a00480@suse.com> <7lhrvh2ad46gjke5kvy4pbvrhstv7ihwm64suqrkle4v43tos6@oktohrjfupkc> <6db70696-4b40-46d2-b19c-881820338ba4@suse.com> <56c24b5b-42a0-4022-bb14-f90a3881fdc1@suse.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 01.03.2024 21:24, Neowutran wrote: > On 2024-02-07 16:02, Jan Beulich wrote: >> Could you give the patch below a try? I don't have a device with large >> enough a BAR that I could sensibly pass through to a guest, so I was >> only able to build-test the change. > > Hi and thanks, > I just tested it, it indeed work well when the GPU have bar > 1Go. > > ------------ > Setup: > I removed my patch > ( > > > --- a/tools/libs/light/libxl_dm.c > +++ b/tools/libs/light/libxl_dm.c > @@ -2431,6 +2431,10 @@ void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state *sdss) > libxl__xs_get_dompath(gc, guest_domid)), > "%s", > libxl_bios_type_to_string(guest_config->b_info.u.hvm.bios)); > + libxl__xs_printf(gc, XBT_NULL, > + libxl__sprintf(gc, "%s/hvmloader/allow-memory-relocate", libxl__xs_get_dompath(gc, guest_domid)), > + "%d", > + 0); > } > ret = xc_domain_set_target(ctx->xch, dm_domid, guest_domid); > if (ret<0) { > > > ) > and applied your suggested "skip huge BARs" patch. > My GPU: nvidia 4080 > ------------- > > When the option "Resizable BAR support" is activated in my bios, > the BAR1 size of my gpu is reported to be 16GB. With this patch, gpu > passthrough work. Good. I guess I should properly post that patch then, no matter that ... > When the option "Resizable BAR support" is desactivated in my bios, > the BAR1 size of my gpu is reported to be 256MB. With this patch, > gpu passthrough doesn't work (same crash as before) ... this clearly requires further work then. 256Mb isn't all that large; could you post a log file (fragment) for this very case? > ( note: the option "Resizable BAR support" may or may not exist > depending on the motherboard model, on some it is 'hardcoded' to > activated, on some it is 'hardcoded' to desactivated) Resizable BARs is yet another thing on my (and maybe also Roger's) todo list. I'm a little uncomfortable doing any work there without having a system where I could actually test it ... Jan From xen-devel-bounces@lists.xenproject.org Mon Mar 04 07:32:28 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 07:32:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688165.1072031 (Exim 4.92) (envelope-from ) id 1rh2oC-0003wQ-Ng; Mon, 04 Mar 2024 07:32:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688165.1072031; Mon, 04 Mar 2024 07:32:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh2oC-0003wJ-Jk; Mon, 04 Mar 2024 07:32:24 +0000 Received: by outflank-mailman (input) for mailman id 688165; Mon, 04 Mar 2024 07:32:23 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh2oB-0003w7-KK for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 07:32:23 +0000 Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [2a00:1450:4864:20::62a]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 56793c90-d9f9-11ee-a1ee-f123f15fe8a2; Mon, 04 Mar 2024 08:32:21 +0100 (CET) Received: by mail-ej1-x62a.google.com with SMTP id a640c23a62f3a-a450615d1c4so171334466b.0 for ; Sun, 03 Mar 2024 23:32:21 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id an19-20020a17090656d300b00a4536b32ae0sm991546ejc.30.2024.03.03.23.32.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 03 Mar 2024 23:32:20 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 56793c90-d9f9-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709537541; x=1710142341; darn=lists.xenproject.org; h=content-transfer-encoding:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to; bh=Uao8jMabORIAFaIx1lr7Z9jLmX4PfQvpemPZ1siutL4=; b=gj4u38Usfr5QoCfRFzMzRypEyGHjaBM3ZGDTFbFq/QjLtRpmh4W65l4edRSbysh5Lm wk3PkiqDPrHCOeuAUpG0Jw1PrAYaxrF+ZoX+xE2fugdPfS78xVmJiWW9HR8UF0SnL28p VemCns2z/zrx6Q+Z7P0ykxwI4d7l7u4wvdLxayrZHyxFb2okirgJzLzKl7bT+aJ3bXS8 CGONQqS9FDCPLYssnWiswCt6CCHdNsT8JE78LWiGoU7F3nR2M2Fnshyg2s7NFXxlqZU6 SrVis4UspjDBI08B2E+lArpU+u4P43mXHPTny2kHLW8Kzobf3xVzT/uunP6rEEPJl3oT tHmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709537541; x=1710142341; h=content-transfer-encoding:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Uao8jMabORIAFaIx1lr7Z9jLmX4PfQvpemPZ1siutL4=; b=QmIB/y05emzh3PZ/4FxP1DZPDZKTgYptQ4x2uoso259Va5TvheygMO3+Nk3O6FlTPe eHBGw5gijCAxrArK2d8dwRC4HsYxbaPyQ/U6V0OBKXo5VTRikS8m0XmKlpUwXmZT4Z+V VYRaQRcGHEVZygBZQG1j0DR3K6gK6RJ7u7KxdvYPR8ALGaHAklye5PzEin10YZWCdgFp yoW4bFN2alNRE3iiwJ1q7d0s3AvccFC4FM6NWRqXAfzCvN7nv7EVTMewVqxVvU/0gfcN Xmb/2n0WHtql2Plw3mz1flUALtkX/Yzq405IiTZAdpIh/KQXiQd8P1b2nao5knkw/hSr gssg== X-Gm-Message-State: AOJu0YxzENKQpdj6hDAMtONo/9vFIS9uwTtEFW5Of14oRDeJyq7Fes2B QXAA7Y0aDkyIivVVpxFPEDmvs1Q/LBF7rVKQfJ17scovXF+UGgoMESVuSQrCxXPBuQW5pEMWWC0 = X-Google-Smtp-Source: AGHT+IEcoARgmc5G5koCbat15gls+rTX1vPZP20RYOP87AnJ7G901KGg5EPH4WqN1CPAPDAEQ1Y7nA== X-Received: by 2002:a17:906:cd01:b0:a44:3056:1ec1 with SMTP id oz1-20020a170906cd0100b00a4430561ec1mr6543060ejb.6.1709537541189; Sun, 03 Mar 2024 23:32:21 -0800 (PST) Message-ID: <090d572c-5196-46b2-9d6b-741b7cb66d97@suse.com> Date: Mon, 4 Mar 2024 08:32:22 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Neowutran From: Jan Beulich Subject: [PATCH] hvmloader/PCI: skip huge BARs in certain calculations Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit BARs of size 2Gb and up can't possibly fit below 4Gb: Both the bottom of the lower 2Gb range and the top of the higher 2Gb range have special purpose. Don't even have them influence whether to (perhaps) relocate low RAM. Reported-by: Neowutran Signed-off-by: Jan Beulich --- If we wanted to fit e.g. multiple 1Gb BARs, it would likely be prudent to similarly avoid low RAM relocation in the first place. Yet accounting for things differently depending on how many large BARs there are would require more intrusive code changes. That said, I'm open to further lowering of the threshold. That'll require different justification then, though. --- a/tools/firmware/hvmloader/pci.c +++ b/tools/firmware/hvmloader/pci.c @@ -33,6 +33,13 @@ uint32_t pci_mem_start = HVM_BELOW_4G_MM const uint32_t pci_mem_end = RESERVED_MEMBASE; uint64_t pci_hi_mem_start = 0, pci_hi_mem_end = 0; +/* + * BARs larger than this value are put in 64-bit space unconditionally. That + * is, such BARs also don't play into the determination of how big the lowmem + * MMIO hole needs to be. + */ +#define HUGE_BAR_THRESH GB(1) + enum virtual_vga virtual_vga = VGA_none; unsigned long igd_opregion_pgbase = 0; @@ -286,9 +293,11 @@ void pci_setup(void) bars[i].bar_reg = bar_reg; bars[i].bar_sz = bar_sz; - if ( ((bar_data & PCI_BASE_ADDRESS_SPACE) == - PCI_BASE_ADDRESS_SPACE_MEMORY) || - (bar_reg == PCI_ROM_ADDRESS) ) + if ( is_64bar && bar_sz > HUGE_BAR_THRESH ) + bar64_relocate = 1; + else if ( ((bar_data & PCI_BASE_ADDRESS_SPACE) == + PCI_BASE_ADDRESS_SPACE_MEMORY) || + (bar_reg == PCI_ROM_ADDRESS) ) mmio_total += bar_sz; nr_bars++; @@ -367,7 +376,7 @@ void pci_setup(void) pci_mem_start = hvm_info->low_mem_pgend << PAGE_SHIFT; } - if ( mmio_total > (pci_mem_end - pci_mem_start) ) + if ( mmio_total > (pci_mem_end - pci_mem_start) || bar64_relocate ) { printf("Low MMIO hole not large enough for all devices," " relocating some BARs to 64-bit\n"); @@ -446,8 +455,9 @@ void pci_setup(void) * the code here assumes it to be.) * Should either of those two conditions change, this code will break. */ - using_64bar = bars[i].is_64bar && bar64_relocate - && (mmio_total > (mem_resource.max - mem_resource.base)); + using_64bar = bars[i].is_64bar && bar64_relocate && + (mmio_total > (mem_resource.max - mem_resource.base) || + bar_sz > HUGE_BAR_THRESH); bar_data = pci_readl(devfn, bar_reg); if ( (bar_data & PCI_BASE_ADDRESS_SPACE) == @@ -467,7 +477,8 @@ void pci_setup(void) resource = &mem_resource; bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK; } - mmio_total -= bar_sz; + if ( bar_sz <= HUGE_BAR_THRESH ) + mmio_total -= bar_sz; } else { From xen-devel-bounces@lists.xenproject.org Mon Mar 04 07:43:31 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 07:43:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688168.1072040 (Exim 4.92) (envelope-from ) id 1rh2yr-0005kK-Kt; Mon, 04 Mar 2024 07:43:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688168.1072040; Mon, 04 Mar 2024 07:43:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh2yr-0005kD-IM; Mon, 04 Mar 2024 07:43:25 +0000 Received: by outflank-mailman (input) for mailman id 688168; Mon, 04 Mar 2024 07:43:24 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh2yq-0005k7-Rn for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 07:43:24 +0000 Received: from smtp-out1.suse.de (smtp-out1.suse.de [2a07:de40:b251:101:10:150:64:1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id e0c8fb30-d9fa-11ee-afda-a90da7624cb6; Mon, 04 Mar 2024 08:43:23 +0100 (CET) Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 12CF8349E8; Mon, 4 Mar 2024 07:43:23 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id C6EA813A58; Mon, 4 Mar 2024 07:43:22 +0000 (UTC) Received: from dovecot-director2.suse.de ([10.150.64.162]) by imap1.dmz-prg2.suse.org with ESMTPSA id bwfZLpp75WVJYAAAD6G6ig (envelope-from ); Mon, 04 Mar 2024 07:43:22 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e0c8fb30-d9fa-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1709538203; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=GkiNMnTbTAHGINJWDQ3poLt+ddrjyXf+lv6FOqblIO0=; b=GExr2xoMh2Vyg989TZQyWPeOxLdQ5LNCSgD64WtobCJIgWKyxcuE8kHb+lcRFUJ1L6YZq1 u7wv5ligUTZz/7V3pth03Q2jQ6vzwiVdysdverVB3PwIfzOj/Jreb+LtD2fwbssoiGqYm3 2PM9U8fAZKcJKfC6yw42o/782MJ6u44= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1709538203; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=GkiNMnTbTAHGINJWDQ3poLt+ddrjyXf+lv6FOqblIO0=; b=GExr2xoMh2Vyg989TZQyWPeOxLdQ5LNCSgD64WtobCJIgWKyxcuE8kHb+lcRFUJ1L6YZq1 u7wv5ligUTZz/7V3pth03Q2jQ6vzwiVdysdverVB3PwIfzOj/Jreb+LtD2fwbssoiGqYm3 2PM9U8fAZKcJKfC6yw42o/782MJ6u44= Message-ID: <4848c844-60b7-411d-982b-7057803dd296@suse.com> Date: Mon, 4 Mar 2024 08:43:22 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 10/12] xen/spinlock: split recursive spinlocks from normal ones Content-Language: en-US To: Jan Beulich Cc: Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu , xen-devel@lists.xenproject.org References: <20231212094725.22184-1-jgross@suse.com> <20231212094725.22184-11-jgross@suse.com> From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: smtp-out1.suse.de; none X-Spamd-Result: default: False [0.28 / 50.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; XM_UA_NO_VERSION(0.01)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; BAYES_HAM(-0.30)[74.86%]; MIME_GOOD(-0.10)[text/plain]; RCVD_COUNT_THREE(0.00)[3]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; RCPT_COUNT_SEVEN(0.00)[7]; FUZZY_BLOCKED(0.00)[rspamd.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; R_MIXED_CHARSET(0.67)[subject]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Spam-Level: X-Spam-Flag: NO X-Spam-Score: 0.28 On 04.03.24 08:25, Jan Beulich wrote: > On 01.03.2024 15:37, Juergen Gross wrote: >> On 29.02.24 16:32, Jan Beulich wrote: >>> On 12.12.2023 10:47, Juergen Gross wrote: >>>> +#define nrspin_lock_irqsave(l, f) \ >>>> + ({ \ >>>> + BUILD_BUG_ON(sizeof(f) != sizeof(unsigned long)); \ >>>> + ((f) = __nrspin_lock_irqsave(l)); \ >>> >>> I don't think the outer pair of parentheses is needed here. >> >> Turns out it is needed. Otherwise something like: >> >> >> if ( a ) >> nrspin_lock_irqsave(l, f); >> else >> ... >> >> will fail with "else without a previous if". > > That's for "outer" in the whole #define I suppose, when I commented on > just a specific line inside the construct. Sorry, I applied your remark to the wrong context. Yes, one level of parentheses can be removed from this line. Juergen From xen-devel-bounces@lists.xenproject.org Mon Mar 04 07:53:55 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 07:53:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688171.1072051 (Exim 4.92) (envelope-from ) id 1rh38x-0007UP-Iv; Mon, 04 Mar 2024 07:53:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688171.1072051; Mon, 04 Mar 2024 07:53:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh38x-0007UI-GE; Mon, 04 Mar 2024 07:53:51 +0000 Received: by outflank-mailman (input) for mailman id 688171; Mon, 04 Mar 2024 07:53:50 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh38w-0007U8-Dd; Mon, 04 Mar 2024 07:53:50 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh38w-0001F9-9s; Mon, 04 Mar 2024 07:53:50 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh38w-0005ug-0G; Mon, 04 Mar 2024 07:53:50 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rh38v-0003O5-W2; Mon, 04 Mar 2024 07:53:49 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=EQz8kIJZMgTjOK9LP3ZnFAD2f6/zKyAmPIhtqjQ1crs=; b=xBcWMwXP/dlbuTc8Q4DqDsh33d Pm41BjdbU7k8N9cbCROeH5RXfIhslC5/bW75gCEd5Ny6MKs7/EV+o//nwy8Vd811Fa5GlCllz45T8 YM0KKgTk9hRHOw1c5ZWs1X1+zHbvWoLDjUIVbNZQwLtDm2qXG3gwshQHQMIxv/WRAhs0=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable test] 184882: regressions - FAIL X-Osstest-Failures: xen-unstable:test-amd64-amd64-xl-qemut-debianhvm-i386-xsm:guest-localmigrate/x10:fail:regression xen-unstable:build-arm64-pvops:kernel-build:fail:regression xen-unstable:test-armhf-armhf-libvirt-qcow2:guest-start:fail:heisenbug xen-unstable:test-amd64-amd64-xl-qemut-debianhvm-i386-xsm:debian-hvm-install:fail:heisenbug xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:windows-install:fail:heisenbug xen-unstable:test-arm64-arm64-xl-thunderx:build-check(1):blocked:nonblocking xen-unstable:test-arm64-arm64-libvirt-raw:build-check(1):blocked:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:build-check(1):blocked:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:build-check(1):blocked:nonblocking xen-unstable:test-arm64-arm64-xl-vhd:build-check(1):blocked:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:build-check(1):blocked:nonblocking xen-unstable:test-arm64-arm64-examine:build-check(1):blocked:nonblocking xen-unstable:test-arm64-arm64-xl:build-check(1):blocked:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: xen=856664f774bd5b66301c5f9022126b61b8cb492d X-Osstest-Versions-That: xen=efad36f1ba18946acecc030166b1a6bebeb88ea2 From: osstest service owner Date: Mon, 04 Mar 2024 07:53:49 +0000 flight 184882 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/184882/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 18 guest-localmigrate/x10 fail in 184875 REGR. vs. 184833 build-arm64-pvops 6 kernel-build fail in 184875 REGR. vs. 184833 Tests which are failing intermittently (not blocking): test-armhf-armhf-libvirt-qcow2 13 guest-start fail in 184875 pass in 184882 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail pass in 184875 test-amd64-amd64-xl-qemuu-win7-amd64 12 windows-install fail pass in 184875 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-thunderx 1 build-check(1) blocked in 184875 n/a test-arm64-arm64-libvirt-raw 1 build-check(1) blocked in 184875 n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked in 184875 n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked in 184875 n/a test-arm64-arm64-xl-vhd 1 build-check(1) blocked in 184875 n/a test-arm64-arm64-xl-credit1 1 build-check(1) blocked in 184875 n/a test-arm64-arm64-examine 1 build-check(1) blocked in 184875 n/a test-arm64-arm64-xl 1 build-check(1) blocked in 184875 n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked in 184875 n/a test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail blocked in 184833 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop fail in 184875 like 184833 test-armhf-armhf-libvirt 16 saverestore-support-check fail like 184833 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop fail like 184833 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 184833 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop fail like 184833 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 184833 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 184833 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop fail like 184833 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 184833 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184833 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 184833 test-amd64-amd64-libvirt-xsm 15 migrate-support-check fail never pass test-amd64-i386-xl-pvshim 14 guest-start fail never pass test-amd64-i386-libvirt 15 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-check fail never pass test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-check fail never pass test-arm64-arm64-xl 15 migrate-support-check fail never pass test-arm64-arm64-xl 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 15 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-check fail never pass test-armhf-armhf-libvirt 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-check fail never pass test-amd64-i386-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-check fail never pass test-arm64-arm64-xl-vhd 14 migrate-support-check fail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-check fail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-check fail never pass version targeted for testing: xen 856664f774bd5b66301c5f9022126b61b8cb492d baseline version: xen efad36f1ba18946acecc030166b1a6bebeb88ea2 Last test of basis 184833 2024-03-01 14:11:30 Z 2 days Testing same since 184852 2024-03-02 16:36:22 Z 1 days 3 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Bertrand Marquis Roger Pau Monné Stefano Stabellini jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm fail test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-dom0pvh-xl-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-qemuu-freebsd11-amd64 pass test-amd64-amd64-qemuu-freebsd12-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-examine-bios pass test-amd64-i386-examine-bios pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-dom0pvh-xl-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-armhf-armhf-libvirt-qcow2 pass test-amd64-amd64-xl-qcow2 pass test-arm64-arm64-libvirt-raw pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-libvirt-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-examine-uefi pass test-amd64-i386-examine-uefi pass test-amd64-amd64-libvirt-vhd pass test-arm64-arm64-xl-vhd pass test-armhf-armhf-xl-vhd pass test-amd64-i386-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these 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 856664f774bd5b66301c5f9022126b61b8cb492d Author: Stefano Stabellini Date: Tue Feb 13 14:33:34 2024 -0800 docs/misra/rules.rst: add rule 14.4 Signed-off-by: Stefano Stabellini Acked-by: Bertrand Marquis commit c40bc0576dcc5acd4d7e22ef628eb4642f568533 Author: Roger Pau Monné Date: Fri Mar 1 13:42:27 2024 +0100 x86/mm: re-implement get_page_light() using an atomic increment The current usage of a cmpxchg loop to increase the value of page count is not optimal on amd64, as there's already an instruction to do an atomic add to a 64bit integer. Switch the code in get_page_light() to use an atomic increment, as that avoids a loop construct. This slightly changes the order of the checks, as current code will crash before modifying the page count_info if the conditions are not correct, while with the proposed change the crash will happen immediately after having carried the counter increase. Since we are crashing anyway, I don't believe the re-ordering to have any meaningful impact. Note that the page must already have a non-zero reference count which prevents the flags from changing, and the previous usage of the cmpxchg loop didn't guarantee that the rest of the fields in count_info didn't change while updating the reference count. Signed-off-by: Roger Pau Monné Reviewed-by: Andrew Cooper commit de17162cafd27f2865a3102a2ec0f386a02ed03d Author: Andrew Cooper Date: Thu Feb 29 11:26:40 2024 +0000 x86/cpu-policy: Allow for levelling of VERW side effects MD_CLEAR and FB_CLEAR need OR-ing across a migrate pool. Allow this, by having them unconditinally set in max, with the host values reflected in default. Annotate the bits as having special properies. Signed-off-by: Andrew Cooper Reviewed-by: Roger Pau Monné commit 0263dc9069ddb66335c72a159e09050b1600e56a Author: Andrew Cooper Date: Thu Feb 29 20:46:13 2024 +0000 tests/resource: Fix HVM guest in !SHADOW builds Right now, test-resource always creates HVM Shadow guests. But if Xen has SHADOW compiled out, running the test yields: $./test-resource XENMEM_acquire_resource tests Test x86 PV Created d1 Test grant table Test x86 PVH Skip: 95 - Operation not supported and doesn't really test HVM guests, but doesn't fail either. There's nothing paging-mode-specific about this test, so default to HAP if possible and provide a more specific message if neither HAP or Shadow are available. As we've got physinfo to hand, also provide more specific message about the absence of PV or HVM support. Signed-off-by: Andrew Cooper Acked-by: Roger Pau Monné commit e2d8a652251660c3252d92b442e1a9c5d6e6a1e9 Author: Andrew Cooper Date: Wed Feb 28 20:22:24 2024 +0000 x86/cpu-policy: Fix visibility of HTT/CMP_LEGACY in max policies The block in recalculate_cpuid_policy() predates the proper split between default and max policies, and was a "slightly max for a toolstack which knows about it" capability. It didn't get transformed properly in Xen 4.14. Because Xen will accept a VM with HTT/CMP_LEGACY seen, they should be visible in the max polices. Keep the default policy matching host settings. This manifested as an incorrectly-rejected migration across XenServer's Xen 4.13 -> 4.17 upgrade, as Xapi is slowly growing the logic to check a VM against the target max policy. Signed-off-by: Andrew Cooper Reviewed-by: Roger Pau Monné commit 5420aa165dfa5fe95dd84bb71cb96c15459935b1 Author: Andrew Cooper Date: Wed Feb 28 20:21:58 2024 +0000 x86/cpu-policy: Hide x2APIC from PV guests PV guests can't write to MSR_APIC_BASE (in order to set EXTD), nor can they access any of the x2APIC MSR range. Therefore they mustn't see the x2APIC CPUID bit saying that they can. Right now, the host x2APIC flag filters into PV guests, meaning that PV guests generally see x2APIC except on Zen1-and-older AMD systems. Linux works around this by explicitly hiding the bit itself, and filtering EXTD out of MSR_APIC_BASE reads. NetBSD behaves more in the spirit of PV guests, and entirely ignores the APIC when built as a PV guest. Change the annotation from !A to !S. This has a consequence of stripping it out of both PV featuremasks. However, as existing guests may have seen the bit, set it back into the PV Max policy; a VM which saw the bit and is alive enough to migrate will have ignored it one way or another. Hiding x2APIC does change the contents of leaf 0xb, but as the information is nonsense to begin with, this is likely an improvement on the status quo. Xen's blind assumption that APIC_ID = vCPU_ID * 2 isn't interlinked with the host's topology structure, where a PV guest may see real host values, and the APIC_IDs are useless without an MADT to start with. Dom0 is the only PV VM to get an MADT but it's the host one, meaning the two sets of APIC_IDs are from different address spaces. Signed-off-by: Andrew Cooper Reviewed-by: Roger Pau Monné (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Mon Mar 04 07:54:36 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 07:54:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688176.1072060 (Exim 4.92) (envelope-from ) id 1rh39f-00082E-V0; Mon, 04 Mar 2024 07:54:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688176.1072060; Mon, 04 Mar 2024 07:54:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh39f-000825-SW; Mon, 04 Mar 2024 07:54:35 +0000 Received: by outflank-mailman (input) for mailman id 688176; Mon, 04 Mar 2024 07:54:35 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh39f-0007wA-43 for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 07:54:35 +0000 Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [2a00:1450:4864:20::533]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 70d03263-d9fc-11ee-afda-a90da7624cb6; Mon, 04 Mar 2024 08:54:34 +0100 (CET) Received: by mail-ed1-x533.google.com with SMTP id 4fb4d7f45d1cf-564372fb762so5441846a12.0 for ; Sun, 03 Mar 2024 23:54:34 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id tk2-20020a170907c28200b00a43ab3e38d6sm4435519ejc.114.2024.03.03.23.54.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 03 Mar 2024 23:54:33 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 70d03263-d9fc-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709538874; x=1710143674; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=n6Xe6TSFwCM/FbYS0Pn+JdVLdIVUR0H4ODheVTgzqo0=; b=J+qpvfbwggut4yMGZ9qpOT+VjUWnY3Nv1phcpRsNgtrGMO4G1/GGX5FmeLRIZlnJ+D WLnG1+6lFhRWOd9cpNHvaKCgkQreNgsjVN6t4Cbb0IRzRbzoX3gD1x115i8g4TfQlulK KfEgY1FBpu1hJmXS9Kww0/7DphJNdNDgFOLd2L+A85Z3v0N9JP8o0XxfjfvRgGwaZo7/ 2GQKuUhtH6aE516Ecdqz73acdXw7sglEbY8nY1wqxatVUqfQJtjj6puHGOxdUvY4PJ11 X8I20WrhVCd8Ackfn4v8jczqRmjnmMIXNDtamZ+EayPpajiYDnWUN4+t4BwevyOnJvKI 2Zdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709538874; x=1710143674; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=n6Xe6TSFwCM/FbYS0Pn+JdVLdIVUR0H4ODheVTgzqo0=; b=WcfVwaO6pUeFtr+vOpY4KcFWKiOHSIC1ojKGQMx+z1GP8S+/MXO/aQeWSFoqOn3qid b1Z+YEF4ZbjnKyOOdqptW0DmlOMfup99x2HZ8SmensjWCZBkCbQRjOzDZWYoRxXPtSvQ f7MqvsqTYqjiHc74nCioZN2fzoQT9xQcKnq1K/58jrPcYQ5OkRU7xnnvqPTEFXD/DUO+ zCtgQbmK5lqGfABNBNJNbeQZlKO7CptdfmUVAYfkY+6nOXkNNcdxxd/T+XNHnao/5/vg lxzqZGiy84euITj02F+J6M/sHcDxi9AmGJKPKw7r1+7ZGVQMuOXqW9IVwe+ec2Jgv26i isYA== X-Forwarded-Encrypted: i=1; AJvYcCV0YcN4MOhX07SJBUHN8exWv5m0IfzC7AyyFZ9PufuBOykz2esF6BbzGHIdT3pUeAdvptd0AqIMVmtU8sQgX3GO7v96GMWbMXax59+oM3A= X-Gm-Message-State: AOJu0YwIjGnXMikwThuRvO1SCFUgAoA2nwF6Zs7YU18Lo1lGmAS/CPrH XMIpt/X3fgDqgEnV7hUFwTyQs4RTA8LaI6D3cVd2zea6wHgVptCbEUQ3rPtK+rSGXOah59q85xE = X-Google-Smtp-Source: AGHT+IGiWOnaglXIDuGoAPVaXOU8F+IpL/UBdUY5zRzd3zs2ZFOGmXpDCyu8B0HcZOiv023N/foclg== X-Received: by 2002:a17:906:d9c7:b0:a44:5a3d:7884 with SMTP id qk7-20020a170906d9c700b00a445a3d7884mr5351178ejb.3.1709538873870; Sun, 03 Mar 2024 23:54:33 -0800 (PST) Message-ID: <6796aeba-52a2-426b-94e5-1852946dce98@suse.com> Date: Mon, 4 Mar 2024 08:54:34 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/mm: re-implement get_page_light() using an atomic increment Content-Language: en-US To: Roger Pau Monne Cc: Andrew Cooper , Wei Liu , xen-devel@lists.xenproject.org References: <20240301124228.56123-1-roger.pau@citrix.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20240301124228.56123-1-roger.pau@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 01.03.2024 13:42, Roger Pau Monne wrote: > The current usage of a cmpxchg loop to increase the value of page count is not > optimal on amd64, as there's already an instruction to do an atomic add to a > 64bit integer. > > Switch the code in get_page_light() to use an atomic increment, as that avoids > a loop construct. This slightly changes the order of the checks, as current > code will crash before modifying the page count_info if the conditions are not > correct, while with the proposed change the crash will happen immediately > after having carried the counter increase. Since we are crashing anyway, I > don't believe the re-ordering to have any meaningful impact. While I consider this argument fine for ... > --- a/xen/arch/x86/mm.c > +++ b/xen/arch/x86/mm.c > @@ -2580,16 +2580,10 @@ bool get_page(struct page_info *page, const struct domain *domain) > */ > static void get_page_light(struct page_info *page) > { > - unsigned long x, nx, y = page->count_info; > + unsigned long old_pgc = arch_fetch_and_add(&page->count_info, 1); > > - do { > - x = y; > - nx = x + 1; > - BUG_ON(!(x & PGC_count_mask)); /* Not allocated? */ ... this check, I'm afraid ... > - BUG_ON(!(nx & PGC_count_mask)); /* Overflow? */ ... this is a problem unless we discount the possibility of an overflow happening in practice: If an overflow was detected only after the fact, there would be a window in time where privilege escalation was still possible from another CPU. IOW at the very least the description will need extending further. Personally I wouldn't chance it and leave this as a loop. Jan From xen-devel-bounces@lists.xenproject.org Mon Mar 04 07:55:12 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 07:55:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688178.1072071 (Exim 4.92) (envelope-from ) id 1rh3AF-000065-7I; Mon, 04 Mar 2024 07:55:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688178.1072071; Mon, 04 Mar 2024 07:55:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh3AF-00005y-4Q; Mon, 04 Mar 2024 07:55:11 +0000 Received: by outflank-mailman (input) for mailman id 688178; Mon, 04 Mar 2024 07:55:09 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh3AD-00005e-HW for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 07:55:09 +0000 Received: from sin.source.kernel.org (sin.source.kernel.org [2604:1380:40e1:4800::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 83e7ea96-d9fc-11ee-afda-a90da7624cb6; Mon, 04 Mar 2024 08:55:08 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id F0C11CE09CC; Mon, 4 Mar 2024 07:55:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D8DCDC433C7; Mon, 4 Mar 2024 07:54:55 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 83e7ea96-d9fc-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1709538901; bh=p6Urnz+2Ta3f7kOkPM5DbFuLip3NAfCMXzcs08p4wBo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ahcrYj1dyiqeI3FybO9o3aXX0MLEyrxXvIg4Hq/LjLd/8bn5nhNwjUoq8uYLe0Ml7 NxC0ub4AubKaEjlt054LymegP0FHpoZStH80tU0a4A9ScXeQaUWHHXAgxHoLhCkMvL Bu2BAHGQ7bqf5hL2B6L8oVg3E8otol7ZUbWn+JAWyUncSvpeq/oY5CR1JqVbPoHMJg nZC0lhtkuq5rgdsQ3/3ZKHAzdFJ+YjLfDbjA9rTgRRX4h0gqWIJsqQ+dI+40IIdbqZ cCX6EN1NiDFXsxM1L/qOAsSFM2iWNfoSeHnvaeyVtw+UOJBZU3FWPizOY1HNOE+V7Q shceRKWhU9xIg== Date: Mon, 4 Mar 2024 09:54:08 +0200 From: Mike Rapoport To: Alexei Starovoitov Cc: bpf@vger.kernel.org, daniel@iogearbox.net, andrii@kernel.org, torvalds@linux-foundation.org, brho@google.com, hannes@cmpxchg.org, lstoakes@gmail.com, akpm@linux-foundation.org, urezki@gmail.com, hch@infradead.org, boris.ostrovsky@oracle.com, sstabellini@kernel.org, jgross@suse.com, linux-mm@kvack.org, xen-devel@lists.xenproject.org, kernel-team@fb.com Subject: Re: [PATCH v2 bpf-next 2/3] mm, xen: Separate xen use cases from ioremap. Message-ID: References: <20240223235728.13981-1-alexei.starovoitov@gmail.com> <20240223235728.13981-3-alexei.starovoitov@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240223235728.13981-3-alexei.starovoitov@gmail.com> On Fri, Feb 23, 2024 at 03:57:27PM -0800, Alexei Starovoitov wrote: > From: Alexei Starovoitov > > xen grant table and xenbus ring are not ioremap the way arch specific code is using it, > so let's add VM_XEN flag to separate them from VM_IOREMAP users. > xen will not and should not be calling ioremap_page_range() on that range. > /proc/vmallocinfo will print such region as "xen" instead of "ioremap" as well. > > Signed-off-by: Alexei Starovoitov > --- > arch/x86/xen/grant-table.c | 2 +- > drivers/xen/xenbus/xenbus_client.c | 2 +- > include/linux/vmalloc.h | 1 + > mm/vmalloc.c | 7 +++++-- > 4 files changed, 8 insertions(+), 4 deletions(-) > > diff --git a/arch/x86/xen/grant-table.c b/arch/x86/xen/grant-table.c > index 1e681bf62561..b816db0349c4 100644 > --- a/arch/x86/xen/grant-table.c > +++ b/arch/x86/xen/grant-table.c > @@ -104,7 +104,7 @@ static int arch_gnttab_valloc(struct gnttab_vm_area *area, unsigned nr_frames) > area->ptes = kmalloc_array(nr_frames, sizeof(*area->ptes), GFP_KERNEL); > if (area->ptes == NULL) > return -ENOMEM; > - area->area = get_vm_area(PAGE_SIZE * nr_frames, VM_IOREMAP); > + area->area = get_vm_area(PAGE_SIZE * nr_frames, VM_XEN); > if (!area->area) > goto out_free_ptes; > if (apply_to_page_range(&init_mm, (unsigned long)area->area->addr, > diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c > index 32835b4b9bc5..b9c81a2d578b 100644 > --- a/drivers/xen/xenbus/xenbus_client.c > +++ b/drivers/xen/xenbus/xenbus_client.c > @@ -758,7 +758,7 @@ static int xenbus_map_ring_pv(struct xenbus_device *dev, > bool leaked = false; > int err = -ENOMEM; > > - area = get_vm_area(XEN_PAGE_SIZE * nr_grefs, VM_IOREMAP); > + area = get_vm_area(XEN_PAGE_SIZE * nr_grefs, VM_XEN); > if (!area) > return -ENOMEM; > if (apply_to_page_range(&init_mm, (unsigned long)area->addr, > diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h > index c720be70c8dd..223e51c243bc 100644 > --- a/include/linux/vmalloc.h > +++ b/include/linux/vmalloc.h > @@ -28,6 +28,7 @@ struct iov_iter; /* in uio.h */ > #define VM_FLUSH_RESET_PERMS 0x00000100 /* reset direct map and flush TLB on unmap, can't be freed in atomic context */ > #define VM_MAP_PUT_PAGES 0x00000200 /* put pages and free array in vfree */ > #define VM_ALLOW_HUGE_VMAP 0x00000400 /* Allow for huge pages on archs with HAVE_ARCH_HUGE_VMALLOC */ > +#define VM_XEN 0x00000800 /* xen use cases */ > > #if (defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)) && \ > !defined(CONFIG_KASAN_VMALLOC) There's also VM_DEFER_KMEMLEAK a line below: #if (defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)) && \ !defined(CONFIG_KASAN_VMALLOC) #define VM_DEFER_KMEMLEAK 0x00000801 /* defer kmemleak object creation */ #else #define VM_DEFER_KMEMLEAK 0 #endif It should be adjusted as well. I think it makes sense to use an enumeration for vm_flags, just like as Suren did for GFP (https://lore.kernel.org/linux-mm/20240224015800.2569851-1-surenb@google.com/) -- Sincerely yours, Mike. From xen-devel-bounces@lists.xenproject.org Mon Mar 04 08:00:28 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 08:00:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688185.1072082 (Exim 4.92) (envelope-from ) id 1rh3FH-0002Zg-5E; Mon, 04 Mar 2024 08:00:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688185.1072082; Mon, 04 Mar 2024 08:00:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh3FH-0002ZZ-1F; Mon, 04 Mar 2024 08:00:23 +0000 Received: by outflank-mailman (input) for mailman id 688185; Mon, 04 Mar 2024 08:00:21 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh3FE-0002ZT-Vl for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 08:00:20 +0000 Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [2a00:1450:4864:20::636]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 3e3507f7-d9fd-11ee-a1ee-f123f15fe8a2; Mon, 04 Mar 2024 09:00:19 +0100 (CET) Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-a446b5a08f0so502788666b.1 for ; Mon, 04 Mar 2024 00:00:19 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id a23-20020a170906671700b00a45128cec31sm1481337ejp.25.2024.03.04.00.00.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Mar 2024 00:00:18 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3e3507f7-d9fd-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709539218; x=1710144018; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=2+QnWhi9L12Yu/+D3/ARwU6sLmXV5ABIWzzkDpGCfTg=; b=dtg+B2TiSlpNTW1Tn+60mFmQl3xQHm6jq6munkU/+ajmtmPwynG1NkYPOfeEaXRpBz jth4wnz3CTj2/5GOcpLo5/1npFGvJt53lDaW/eFzhLJY2BsRRHotmKZh7nDEsatumT3d Or+hCstAshAQ+nv362ZvqFuulhUJMcO9er4L0cDlP9vNIogtnMerxVSGJIg2B7lc1WUU 5epEm1L1p5OMBOLS9ylMbqikRXQuTst6Ea77tTKJKPxCoX5yuTf7kRT/nOEpSfu2kH/f 1Pj4HgW45CoVA+s9cT2Whp4f6imoKX5n4kqnKxzNN+HlIsK7Xafz6fowvhDhy5v9b7sI V5PA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709539218; x=1710144018; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=2+QnWhi9L12Yu/+D3/ARwU6sLmXV5ABIWzzkDpGCfTg=; b=QeDQy+Pw7Ho+CQmJSAi2UPKJ+AYC+M+lXNnGecaSiuvHmMyKNl73s4IE0L5jzRcBhm 8+jut5OOazJc/egMuMAuGLH7R3CP97AL+b12Bs34RLdf9SgBcvwyuSQ3pHi7p4QwPfsY 27LJbmhBqJvw9GLYSbGpB5KrmeU9S8q/3THmEmNNd+75hXdOX4qPoORIXByqaak4xsEI Qyxk8kGw7FaqiVzGfdEFJhGM65c4eeb7W2Q8d+o04CCsjRafzgt7yplE5/DnFOdF2N2Q IDCN6NQD1sjUri6tII/EiRz4us6cRGufOUtkWMJenAXSlhp8ykpbPD083JvcEuKW3kPs zsfw== X-Gm-Message-State: AOJu0YxL6HAwX2knuNhGpK+v0wndr1TbYTk1rDAqKD5xt74IyHQa0El1 zcUPvYztdYJRwKrf2w+iYs8qKG/4C0+02OGE/MlWlJuqeYkz8ciO08Vc9Eu+yA== X-Google-Smtp-Source: AGHT+IG1avjWE/WrIeA+pYvrXrvY7Rr2GPB0bwRhxZwO6mpKVcURJVeG1uY4J6ZMrkG8sacH2HeeaA== X-Received: by 2002:a17:906:57da:b0:a45:163b:6a3e with SMTP id u26-20020a17090657da00b00a45163b6a3emr2810034ejr.10.1709539218373; Mon, 04 Mar 2024 00:00:18 -0800 (PST) Message-ID: Date: Mon, 4 Mar 2024 09:00:18 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH 10/10] xen/keyhandler: address violations of MISRA C Rule 20.7 Content-Language: en-US To: Stefano Stabellini Cc: xen-devel@lists.xenproject.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, consulting@bugseng.com, andrew.cooper3@citrix.com, roger.pau@citrix.com, bertrand.marquis@arm.com, julien@xen.org, George Dunlap , Wei Liu , Nicola Vetrini References: <2bc4a964f0f2f47488e72237678e944dbdbd7bb7.1709219010.git.nicola.vetrini@bugseng.com> <1afd8805-7365-40ec-8e8e-468a83e20c40@suse.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 02.03.2024 02:37, Stefano Stabellini wrote: > On Fri, 1 Mar 2024, Jan Beulich wrote: >> On 29.02.2024 23:57, Stefano Stabellini wrote: >>> On Thu, 29 Feb 2024, Nicola Vetrini wrote: >>>> MISRA C Rule 20.7 states: "Expressions resulting from the expansion >>>> of macro parameters shall be enclosed in parentheses". Therefore, some >>>> macro definitions should gain additional parentheses to ensure that all >>>> current and future users will be safe with respect to expansions that >>>> can possibly alter the semantics of the passed-in macro parameter. >>>> >>>> No functional change. >>>> >>>> Signed-off-by: Nicola Vetrini >>> >>> Reviewed-by: Stefano Stabellini >> >> You did see the discussion on earlier patches, though? I don't think >> any of the parentheses here are needed or wanted. > > We need to align on this. Currently if we go by what's written in > docs/misra/deviations.rst, then rhs should have parentheses. Quoting the actual patch again: --- a/xen/common/keyhandler.c +++ b/xen/common/keyhandler.c @@ -42,10 +42,10 @@ static struct keyhandler { } key_table[128] __read_mostly = { #define KEYHANDLER(k, f, desc, diag) \ - [k] = { { .fn = (f) }, desc, 0, diag } + [k] = { { .fn = (f) }, (desc), 0, (diag) } #define IRQ_KEYHANDLER(k, f, desc, diag) \ - [k] = { { .irq_fn = (f) }, desc, 1, diag } + [k] = { { .irq_fn = (f) }, (desc), 1, (diag) } What rhs are you talking about in light of this change? The only rhs I can spot here is already parenthesized. > Can we safely claim that rhs parentheses are never needed? If so, then > great, let's add it to deviations.rst and skip them here and other > places in this patch series (e.g. patch #8). When I say "never" I am > taking for granted that the caller is not doing something completely > unacceptably broken such as: > > WRITE_SYSREG64(var +, TTBR0_EL1) I'm afraid I can't associate this with the patch here either. Instead in the context here a (respective) construct as you mention above would simply fail to build. Jan > If we cannot generically claim that rhs parentheses are never needed, > then I don't think we should make any exceptions. We should add them here > and everywhere else. It should be easy to write a macro or review a > patch with a macro from someone else, and making special exception makes > it more difficult for everyone. From xen-devel-bounces@lists.xenproject.org Mon Mar 04 08:04:44 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 08:04:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688192.1072091 (Exim 4.92) (envelope-from ) id 1rh3JR-0003AS-Lm; Mon, 04 Mar 2024 08:04:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688192.1072091; Mon, 04 Mar 2024 08:04:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh3JR-0003AL-Hy; Mon, 04 Mar 2024 08:04:41 +0000 Received: by outflank-mailman (input) for mailman id 688192; Mon, 04 Mar 2024 08:04:40 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh3JQ-0003AF-IT for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 08:04:40 +0000 Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [2a00:1450:4864:20::536]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id d9852d7d-d9fd-11ee-afda-a90da7624cb6; Mon, 04 Mar 2024 09:04:39 +0100 (CET) Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-565a2c4cc1aso5782328a12.2 for ; Mon, 04 Mar 2024 00:04:39 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id q11-20020a056402040b00b005675882c8fdsm559012edv.39.2024.03.04.00.04.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Mar 2024 00:04:38 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d9852d7d-d9fd-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709539479; x=1710144279; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=yBntkL9TU/I1fhOpRSPNRqKxvzokK49+QSrv+8S5s4g=; b=GAqkKX6Ya8cDZAc6D9WZF+G89DWI+I3LE0OrLbbLiQZ+p1TLkKSM9PKA4wOf4pZn0w i9ziVJiOdq4PkOWMrm2ygu29HvHR10vz0URNANwmzQAw1M/0RlhjVu9K/4fxxY3VyYPT lPJAzimL3PoXQ9pRXeztyFboAjRqpeRgYCL8blyUqKQlaqRL+RTrH0GOW0AQ339zp77S mtowYtUIzXLD2Mj8WA1gUDlenZqxbACViGW/zfpqsqL2Ykl7XxSvIvwwBrAjKYQADfI3 /tMDQnyIFnlLSyVTVhGIylOltTsnLG4tGwSBjgBxmY2GeBRhFgaOay5cpjQFeURu/fOd YPqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709539479; x=1710144279; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=yBntkL9TU/I1fhOpRSPNRqKxvzokK49+QSrv+8S5s4g=; b=a1auZzP3wwJxDgVlBAT8gnv1qndJ8+lVJ6+rNAdm4WcFYRpUnMLU0t9ObG9DEJhKif RSRTbQ/M/ynrE7dUF1qGIypIm6Xp7rJ7aHYam6i+MtxdnGM/qZ8RGBerbvlTvbeaQX1P D9W8R3VFC27KN6h58a6k7FCY3lRA2NUgqm+P4TOTI00Md+MlNXQc/7gEnrXxf8rX+wsd G0GpjMh2yzLSqmWfI5fcQT3HVFD3VHqY8dOTVCiA9RPDMS2liEhocVocJ++Nj2lFIOlP t0ekxkivKisGtLE9YS+1ypvxnWmwgOcq18QBAe5BtovQOdkKAJ1G7boAS33E6Grgu7VM FCrQ== X-Forwarded-Encrypted: i=1; AJvYcCVqgbX309+4/u+4aye2r2BOOmJ/0SM0rcCCi/uzvUYNzUxyN8Vc//vP4dz0kt0z0cRJTipyyEvswzKCuS/nnHVhjHSUkg9TFE77pmxlki8= X-Gm-Message-State: AOJu0YxwPffg9XNH0cZR66oruEIUGY5NxFJiNldW2IrsunI31D/ZfdJH oUFRU9+QKhgr5z0+sh8QFMKOwhQmeofWSG0IaJYNE7fiRkmCLUUUsM0/GzN3ag== X-Google-Smtp-Source: AGHT+IFUk19Qf/Sqqly5WoHZXXG9fY7zFmxrMNLkLeh0DkxUzZ1P5GDiJj7YsiMRbYVExDdlklOkoQ== X-Received: by 2002:a50:cdd0:0:b0:565:7b61:4c86 with SMTP id h16-20020a50cdd0000000b005657b614c86mr6301654edj.6.1709539479049; Mon, 04 Mar 2024 00:04:39 -0800 (PST) Message-ID: <87326c7b-b7d8-4072-bced-d902e23134ed@suse.com> Date: Mon, 4 Mar 2024 09:04:39 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH] automation/eclair: add deviation for MISRA C:2012 Rule 16.6 Content-Language: en-US To: Federico Serafini Cc: consulting@bugseng.com, Simone Ballarin , Doug Goldstein , Stefano Stabellini , Andrew Cooper , George Dunlap , Julien Grall , Wei Liu , xen-devel@lists.xenproject.org References: From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 01.03.2024 16:04, Federico Serafini wrote: > --- a/docs/misra/deviations.rst > +++ b/docs/misra/deviations.rst > @@ -322,6 +322,12 @@ Deviations related to MISRA C:2012 Rules: > - /\* Fallthrough \*/ > - /\* Fallthrough. \*/ > > + * - R16.6 > + - A switch statement with a single switch clause and no default label is > + deliberate and improves readability with respect to an equivalent if > + statement. > + - Tagged as `deliberate` for ECLAIR. Imo this is another example of wording a deviation in too wide a manner. It shouldn't be "is", but "may". Whether what is said here applies is entirely down to every specific instance; otherwise I'm inclined to read this as a suggestion to replace all if() by switch(), for that always improving readability. FTAOD things would be different if this was explanatory text to a SAF comment - there the specific context is always given (by where the comment actually appears). Jan From xen-devel-bounces@lists.xenproject.org Mon Mar 04 08:11:00 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 08:11:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688194.1072102 (Exim 4.92) (envelope-from ) id 1rh3PT-0004to-BE; Mon, 04 Mar 2024 08:10:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688194.1072102; Mon, 04 Mar 2024 08:10:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh3PT-0004th-6i; Mon, 04 Mar 2024 08:10:55 +0000 Received: by outflank-mailman (input) for mailman id 688194; Mon, 04 Mar 2024 08:10:53 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh3PR-0004tb-Ny for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 08:10:53 +0000 Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [2a00:1450:4864:20::52e]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id b7639295-d9fe-11ee-a1ee-f123f15fe8a2; Mon, 04 Mar 2024 09:10:51 +0100 (CET) Received: by mail-ed1-x52e.google.com with SMTP id 4fb4d7f45d1cf-55a179f5fa1so6226968a12.0 for ; Mon, 04 Mar 2024 00:10:51 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id tk3-20020a170907c28300b00a3f20a8d2f6sm4474836ejc.112.2024.03.04.00.10.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Mar 2024 00:10:51 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b7639295-d9fe-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709539851; x=1710144651; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=X6WKhzC0sAZwLswUBzI6C0o1JuG1W1Ipgq1JvFRQZ8s=; b=cf8evjn9QFtlkGt7V55GmOaw/GWWe+kJyhN+LNvoeqZ+8COyc7pxuuYWK0PLWrpxae RFr4zPcK/ScTbyNzr2Gu3A0HEnjbs5AXiMxItcaJ1tXpqax9b2cw28WHAYgNRxtUX7dU JAR0KvAuzaVU8u3HzKekvJezU/ltN0og/8XHao95GTQtm+k2ElrSSWWz7J4z9mR/9wKj fJqk39H00irTzmb3YizcZ50F2xDfGlXC79lXpLZPyfwvqOJxDUlT3ABw1COzsBsjgAay +fFHHHaueDmjgD/0uUWEnoN+L2NpDnRqb+VLUSmOIMu0oQR5f+7bZTIOLlwhApnex0c+ 5Gxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709539851; x=1710144651; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=X6WKhzC0sAZwLswUBzI6C0o1JuG1W1Ipgq1JvFRQZ8s=; b=QfngDzQtGg47FjJtYliIJadmW8BmneqTWhcnbKAsC7oWIL4Ftj8oaD9Wi4BmR1PRhe tJoBu30ZKDwrG5Zts5TIfvkfEtEvMjBzwGAwTXJyH/6QPffLoB287S6Sn/+TCZDaKS/N xt7jNqcmfM4PmpB+iTjS8H6cBskQuD8ar0K1Eg1pqqTBBOosC7wjBp+p6NeT3biVhjHE ZvV4QZBsTsuNdWQwJ1W7LikdHupaa+a6hVKR1mk3QBsOEmr2QVhJMoiBfueyJoeDOnrG Xvl1G8FjVSnh/jw4Zb6wRMBusqnVxf9O1Ps0D5gbzvrg85rOLqd1t/N163lrRITvE3jD RCXQ== X-Forwarded-Encrypted: i=1; AJvYcCWbDDI0Mo0qo1dVL/eryOuyPq2CPzAIah8LFthcawkYCCmXE6ty4Xq7SeSVITuYxexvTdkoM71hISI9oLYquNZEm6MAAHFM+W9AoG1Ml7c= X-Gm-Message-State: AOJu0YwYZVWJmL3ybo1itPxuaDOE2uZFThbptlKsQ46ZpBgNsi4BxnVQ +0+Oc7Z1gvQKIt3VUzzV435RV+Le2iiTQD4sz+YseDDrWJ8O//68QpHG9osu9Q== X-Google-Smtp-Source: AGHT+IESWFnrQBOjraZIeYzr/ic+NauLuU9cFr9kLvOoe9ETzLBScq6wKfDu9+SNgMzt+BjObz/69A== X-Received: by 2002:a17:906:eb0b:b0:a45:740:250a with SMTP id mb11-20020a170906eb0b00b00a450740250amr2278170ejb.68.1709539851227; Mon, 04 Mar 2024 00:10:51 -0800 (PST) Message-ID: Date: Mon, 4 Mar 2024 09:10:52 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Xen 4.19 release status tracking list [ March ] Content-Language: en-US To: Oleksii Cc: committers@xenproject.org, community.manager@xenproject.org, Kelly Choi , xen-devel@lists.xenproject.org References: <91cc3f76029357f34bd5ca21966c42f0acb73720.camel@gmail.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <91cc3f76029357f34bd5ca21966c42f0acb73720.camel@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 01.03.2024 18:21, Oleksii wrote: > * limit passing around of cpu_user_regs [ > https://lore.kernel.org/xen-devel/ebc330a9-eafa-4858-b5cf-5694c4da911d@suse.com/ > ]: > new patch series version was sent. This was committed already a while ago. > * [PATCH v2 0/5] xen/livepatch: fixes for the pre-apply / post-revert > hooks [ > https://lore.kernel.org/xen-devel/20240227112528.4540-1-roger.pau@citrix.com/T/#m620c827bd097522d9d87b7f6511bc1599f6a8c84 > ] This went in last week, I think? > Please reply with items you would like to see in 4.19 so that people > know what is happening and prioritize accordingly. > You're welcome to provide a description and use cases of the feature > you're working on. "x86/spec-ctrl: IBPB improvements" Jan From xen-devel-bounces@lists.xenproject.org Mon Mar 04 08:19:53 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 08:19:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688201.1072111 (Exim 4.92) (envelope-from ) id 1rh3Y2-0005yb-7G; Mon, 04 Mar 2024 08:19:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688201.1072111; Mon, 04 Mar 2024 08:19:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh3Y2-0005yU-4g; Mon, 04 Mar 2024 08:19:46 +0000 Received: by outflank-mailman (input) for mailman id 688201; Mon, 04 Mar 2024 08:19:45 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh3Y1-0005yO-AN for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 08:19:45 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id f4a136f4-d9ff-11ee-afda-a90da7624cb6; Mon, 04 Mar 2024 09:19:44 +0100 (CET) Received: from [192.168.1.113] (93-36-220-117.ip62.fastwebnet.it [93.36.220.117]) by support.bugseng.com (Postfix) with ESMTPSA id 4020F4EE0737; Mon, 4 Mar 2024 09:19:43 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f4a136f4-d9ff-11ee-afda-a90da7624cb6 Message-ID: Date: Mon, 4 Mar 2024 09:19:42 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH] automation/eclair: add deviation for MISRA C:2012 Rule 16.6 Content-Language: en-US, it To: Jan Beulich Cc: consulting@bugseng.com, Simone Ballarin , Doug Goldstein , Stefano Stabellini , Andrew Cooper , George Dunlap , Julien Grall , Wei Liu , xen-devel@lists.xenproject.org References: <87326c7b-b7d8-4072-bced-d902e23134ed@suse.com> From: Federico Serafini Organization: BUGSENG srl In-Reply-To: <87326c7b-b7d8-4072-bced-d902e23134ed@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 04/03/24 09:04, Jan Beulich wrote: > On 01.03.2024 16:04, Federico Serafini wrote: >> --- a/docs/misra/deviations.rst >> +++ b/docs/misra/deviations.rst >> @@ -322,6 +322,12 @@ Deviations related to MISRA C:2012 Rules: >> - /\* Fallthrough \*/ >> - /\* Fallthrough. \*/ >> >> + * - R16.6 >> + - A switch statement with a single switch clause and no default label is >> + deliberate and improves readability with respect to an equivalent if >> + statement. >> + - Tagged as `deliberate` for ECLAIR. > > Imo this is another example of wording a deviation in too wide a manner. > It shouldn't be "is", but "may". Whether what is said here applies is > entirely down to every specific instance; otherwise I'm inclined to read > this as a suggestion to replace all if() by switch(), for that always > improving readability. FTAOD things would be different if this was > explanatory text to a SAF comment - there the specific context is always > given (by where the comment actually appears). Ok, I'll rephrase a v2. -- Federico Serafini, M.Sc. Software Engineer, BUGSENG (http://bugseng.com) From xen-devel-bounces@lists.xenproject.org Mon Mar 04 08:33:28 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 08:33:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688205.1072121 (Exim 4.92) (envelope-from ) id 1rh3l4-0000rE-8R; Mon, 04 Mar 2024 08:33:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688205.1072121; Mon, 04 Mar 2024 08:33:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh3l4-0000r7-5X; Mon, 04 Mar 2024 08:33:14 +0000 Received: by outflank-mailman (input) for mailman id 688205; Mon, 04 Mar 2024 08:33:13 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh3l3-0000r1-6f for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 08:33:13 +0000 Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [2a00:1450:4864:20::52a]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id d5ade12d-da01-11ee-a1ee-f123f15fe8a2; Mon, 04 Mar 2024 09:33:11 +0100 (CET) Received: by mail-ed1-x52a.google.com with SMTP id 4fb4d7f45d1cf-5658082d2c4so5686677a12.1 for ; Mon, 04 Mar 2024 00:33:11 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id u11-20020aa7d54b000000b005676dc74568sm22766edr.92.2024.03.04.00.33.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Mar 2024 00:33:10 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d5ade12d-da01-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709541190; x=1710145990; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=Ut64ZgYtVOtqepmTe4ahlByQcsflnD3AE8O5tiYr2uM=; b=P6xjlcv4OnXIJRWyUZG1VXDG3YJ6cZrpkya+3gVkt26M+BZ7sEhEEAxlth5eKMWFcy y3E0isxwxFB2nOT68k0nE0iGBzT4Jbwx+j3SG+OqoX9sqs44txKI0Rhg90ZzGPlrSJ5K iAHUXFuxFk+zbKZumbRyE9V54xH3PBbZByZguebJF81UnVzzodjK9E1SZHjaz2UxgoUv iJ1TRuCmIVMmLDfsVBODn621N+jwl7wWDvfDhurlsQ6w3GBrEJv4fbGlIafEr4vtdSx4 xs4AbAsYcAQGz1twkpiD6VwRqeIYQoJchbuDJ63ibNPa3rHZsSMbXeDcxFWmDtxyj3x8 BVpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709541190; x=1710145990; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Ut64ZgYtVOtqepmTe4ahlByQcsflnD3AE8O5tiYr2uM=; b=dPVUfe3xIB58XytqLDwPpvmMCIDGrHwo/7qnxo+/+0bmROBbQAWkDd4p1XwfuEjtOL v9o/G352CCOq12m14kv998MG44nnqAZtKS6ML0WTww/DHL5kRToPFiCvo9jIdrxundku Vkuz4dJZ4585D/QFXg4OTRvnKQFk93H1c0M45FT+vvDDf0RJvn/xc6uGX3JeCDD7zD6v yZa8FYmlycCKcv1kOzknrdSdQKUyWJKWqzKLYIo+iGGJyobZGLN7T7t4QLMP2x6Cnpcx WETfmefs8eUMBEfF5cGEyFYfBeTD6dA7jyUHtPCsgblI+Edm6O7d/SVEQ/OAlL/PS5WY IewQ== X-Forwarded-Encrypted: i=1; AJvYcCVPW4FAgjD9/RDBF8H2fy26thIaHXBnwNacoH/DIUkhR+29RKRZp0bttLmXeFW0djNp0zjkEPvf7x4zZmC9gucj75mtW4x7yMIYqzMiZYc= X-Gm-Message-State: AOJu0Yy+DRTeSL9YovxuwZJSyIy6pPR+JYc9BBc27vgLiMdg4nih1d1D IQlS3PuNFnlDIhAVp8PVkUUGUNDSc3B1bxKX68FgYDD5ITEaETHeW3R8UthASw== X-Google-Smtp-Source: AGHT+IE5pkF2L5/EFj3QzEpp2TA7uLEF/c3/IsKsebGorzXzi1O0vADGmo+fTiEiD9Yav40TLLx2GQ== X-Received: by 2002:a50:8dc7:0:b0:566:131a:26ee with SMTP id s7-20020a508dc7000000b00566131a26eemr5275332edh.35.1709541190462; Mon, 04 Mar 2024 00:33:10 -0800 (PST) Message-ID: Date: Mon, 4 Mar 2024 09:33:11 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/cpu-policy: Hide x2APIC from PV guests Content-Language: en-US To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu , Xen-devel References: <20240229221448.2593171-1-andrew.cooper3@citrix.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20240229221448.2593171-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 29.02.2024 23:14, Andrew Cooper wrote: > PV guests can't write to MSR_APIC_BASE (in order to set EXTD), nor can they > access any of the x2APIC MSR range. Therefore they mustn't see the x2APIC > CPUID bit saying that they can. This argumentation could then be used equally for the APIC bit. Why is it correct to hide x2APIC, but not APIC? > Right now, the host x2APIC flag filters into PV guests, meaning that PV guests > generally see x2APIC except on Zen1-and-older AMD systems. > > Linux works around this by explicitly hiding the bit itself, and filtering > EXTD out of MSR_APIC_BASE reads. NetBSD behaves more in the spirit of PV > guests, and entirely ignores the APIC when built as a PV guest. > > Change the annotation from !A to !S. This has a consequence of stripping it > out of both PV featuremasks. However, as existing guests may have seen the > bit, set it back into the PV Max policy; a VM which saw the bit and is alive > enough to migrate will have ignored it one way or another. > > Hiding x2APIC does also change the contents of leaf 0xb, but as the > information is nonsense to begin with, this is likely an improvement on the > status quo. The blind reporting of APIC_ID = vCPU_ID * 2 isn't interlinked > with the host's topology structure, and the APIC_IDs are useless without an > MADT to start with. Dom0 is the only PV VM to get an MADT but it's the host > one, meaning the two sets of APIC_IDs are from different address spaces. Aiui the field will now be seen as zero on all CPUs. Is all CPUs having the same APIC ID there really better than them all having different ones? Also while I agree that logically CPUID leaf 0xb EDX is tied to x2APIC being available as a feature, nothing is said in this regard in the documentation of that leaf. This in particular leaves open whether on a system with x2APIC disabled in/by firmware the value would actually be zero. Yet that case could be considered somewhat similar to the PV case here. Jan From xen-devel-bounces@lists.xenproject.org Mon Mar 04 08:42:10 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 08:42:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688211.1072131 (Exim 4.92) (envelope-from ) id 1rh3tc-0002tD-4a; Mon, 04 Mar 2024 08:42:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688211.1072131; Mon, 04 Mar 2024 08:42:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh3tc-0002t6-1H; Mon, 04 Mar 2024 08:42:04 +0000 Received: by outflank-mailman (input) for mailman id 688211; Mon, 04 Mar 2024 08:42:02 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh3ta-0002t0-No for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 08:42:02 +0000 Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [2a00:1450:4864:20::62e]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 11713a14-da03-11ee-a1ee-f123f15fe8a2; Mon, 04 Mar 2024 09:42:00 +0100 (CET) Received: by mail-ej1-x62e.google.com with SMTP id a640c23a62f3a-a4532f84144so90948966b.3 for ; Mon, 04 Mar 2024 00:42:00 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id lf12-20020a170906ae4c00b00a3f27031d7bsm4478192ejb.104.2024.03.04.00.41.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Mar 2024 00:42:00 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 11713a14-da03-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709541720; x=1710146520; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=dH71Eg9TYrklzTXB5rbvvDpAAx3jxhgWpBFzwoM4zGc=; b=T6NgJeIeM7ANxykKTKzINTRIVZlRPTQhRD+BhT1rAilWSr11PaBEXAe3mSTJb04N7e pXwP6I9StBmm896MCv0MvaUTbopYR/xgwC9Xbp6DRo2AL/FsGT/E8N1wOm6QvZe7v2SE qx1uUZPmdRqttBs6nuJQho3cVvB0OVPyTqwMyA5fZIKTJovUZAc/Q40rd6KUhIc8vHGP imjvslYUqwBE/7VJu3twT1VwF12cSq3M9t74AUUED5Y9EvmXWyxUfsnQQzYhO0qJliqU 2SaVpQOTlb73oDSiGhLZUCUDt7ULWGCwvk2mLs2HmTFwaNiSEe1+3GN9gA7xbME6fKUo ThKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709541720; x=1710146520; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=dH71Eg9TYrklzTXB5rbvvDpAAx3jxhgWpBFzwoM4zGc=; b=nNsC06rlQVfgl1SYg3wXgQP9LYnPs7HN63NU/MYN0mF/F9SR3rMHHSYYZLx9yAAkkh 7o3UBsDeWoraUJErjNVHbld61FM8wAHq/SHYRqPUmrzCYJDrHRQnG0dDUxXoE+D0ciTx ZtX9Ng2oc6RuAJhHvvPcBRb4DkianVibThWFOLanShS2npybV6FRBanSg/2gOMLKHlwc //6BA3mkYS5d+vhZ89rmcn6F8TB8J90ujNuC2SYc9NtCxWWYyfT0/0+hF5oDHD+WsD90 N0uXlQFMWrfgprA0UEZaDQfKLWlWGwLnnF5yQ4+/SmB20lBniArdAU9lX/JbeM1MxOY7 r/NQ== X-Forwarded-Encrypted: i=1; AJvYcCV3YeFuC/2AeQmd39BaGujFLDEuDua+xHVCXLIcBsPO4FDjX4CWtkjtQulZ65KaYKcWn6GMF0Ub7wlnYxIaYWuldQ7M/S+jjDunfJNms8E= X-Gm-Message-State: AOJu0Yw+BrwbQAuF+fPIK1DDLzuH25FxcZxN0AMCrAL5ral2++k+ULDY 8CJmrGxuVJsqSfwCPhnXSaTLa3cC775B7zwsCctm+IbvMQksP1ydOq2PEcHbdg== X-Google-Smtp-Source: AGHT+IHDajJxFhYTX+wXFxFGtArV2QmMXH/5WGT41ipjk4FCcWoihqod32doUjFn0hyZUzSl8GT/xg== X-Received: by 2002:a17:906:fa92:b0:a3e:d5ac:9995 with SMTP id lt18-20020a170906fa9200b00a3ed5ac9995mr5715611ejb.59.1709541720390; Mon, 04 Mar 2024 00:42:00 -0800 (PST) Message-ID: <0751a4ac-4e3b-47e4-8727-f3dd4610d446@suse.com> Date: Mon, 4 Mar 2024 09:42:01 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/cpu-policy: Fix visibility of HTT/CMP_LEGACY in max policies Content-Language: en-US To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu , Xen-devel References: <20240301112829.2657865-1-andrew.cooper3@citrix.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20240301112829.2657865-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 01.03.2024 12:28, Andrew Cooper wrote: > --- a/xen/arch/x86/cpu-policy.c > +++ b/xen/arch/x86/cpu-policy.c > @@ -464,6 +464,16 @@ static void __init guest_common_max_feature_adjustments(uint32_t *fs) > raw_cpu_policy.feat.clwb ) > __set_bit(X86_FEATURE_CLWB, fs); > } > + > + /* > + * Topology information inside the guest is entirely at the toolstack's > + * disgression, and bears no relationship to the host we're running on. > + * > + * HTT identifies p->basic.lppp as valid > + * CMP_LEGACY identifies p->extd.nc as valid > + */ > + __set_bit(X86_FEATURE_HTT, fs); > + __set_bit(X86_FEATURE_CMP_LEGACY, fs); > } > > static void __init guest_common_default_feature_adjustments(uint32_t *fs) > @@ -514,6 +524,18 @@ static void __init guest_common_default_feature_adjustments(uint32_t *fs) > __clear_bit(X86_FEATURE_CLWB, fs); > } > > + /* > + * Topology information is at the toolstack's discretion so these are > + * unconditionally set in max, but pick a default which matches the host. > + */ > + __clear_bit(X86_FEATURE_HTT, fs); > + if ( cpu_has_htt ) > + __set_bit(X86_FEATURE_HTT, fs); > + > + __clear_bit(X86_FEATURE_CMP_LEGACY, fs); > + if ( cpu_has_cmp_legacy ) > + __set_bit(X86_FEATURE_CMP_LEGACY, fs); When running on a host with the respective bit clear, won't this break (at least older) Linux'es logic? Iirc the unconditional setting of at least HTT was tied to the unconditional multiplying by 2 of the vCPU ID to derive the (fake) APIC ID. Jan From xen-devel-bounces@lists.xenproject.org Mon Mar 04 08:50:18 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 08:50:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688214.1072141 (Exim 4.92) (envelope-from ) id 1rh41V-0004Wv-Si; Mon, 04 Mar 2024 08:50:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688214.1072141; Mon, 04 Mar 2024 08:50:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh41V-0004Wo-PX; Mon, 04 Mar 2024 08:50:13 +0000 Received: by outflank-mailman (input) for mailman id 688214; Mon, 04 Mar 2024 08:50:12 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh41U-0004VW-Hc for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 08:50:12 +0000 Received: from mail-qv1-xf2d.google.com (mail-qv1-xf2d.google.com [2607:f8b0:4864:20::f2d]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 34ebb249-da04-11ee-a1ee-f123f15fe8a2; Mon, 04 Mar 2024 09:50:10 +0100 (CET) Received: by mail-qv1-xf2d.google.com with SMTP id 6a1803df08f44-68f9e399c91so37368076d6.2 for ; Mon, 04 Mar 2024 00:50:10 -0800 (PST) Received: from localhost ([213.195.118.74]) by smtp.gmail.com with ESMTPSA id oq19-20020a056214461300b0068fda0c74b6sm4850742qvb.27.2024.03.04.00.50.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Mar 2024 00:50:08 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 34ebb249-da04-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709542209; x=1710147009; darn=lists.xenproject.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=H2iQsYgpcJeewpHyRp27DEUfjuH004zf8nf+BLQvLE8=; b=I5WYCr7URdUyboS2cfTOUfnQ5mM9otKubei9qr49iUzGVntlV5tmCfQAwCl2qPRO9i 54DZ09pPhX61dr39PpAH9+23+Cc4me+YGv3dIsnlQEKSuwv7MirORIsazHfP+XxOIChD GSdkA7tmHqugJ+rX5VuSQkUsKxSoPDEnIh/KI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709542209; x=1710147009; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=H2iQsYgpcJeewpHyRp27DEUfjuH004zf8nf+BLQvLE8=; b=oDM5aGBh9E4AWVli5DuQFRnwLcBkmODc5h1P2tKhSWucXa/PaQLfsHn1DGxt9Y8ctb z0IrfA4L8JbGoboMDB19lwRmD4vfoI/EXDN1K+0X5kasNXtT4+muwPdBRdLTDU3kJYa+ JXpbaU5l3DwLqisvm1/KhMkgVQHkO+KRXIxs/GdcTWJhZLHwVyp5D0ZKs3MjUZF8W1Wl dvHHyrQGqmm2SZb+lRlfIvGH6USk/XDpjbfY4KGcua88OXmNFlGx3F00PO/W5IyZTH2H Ed6bZgllhoXTX6LgQYy9g+A8/rzNoxVvcE9GoHNBOAQ5hQpP6cxa99FJzKp0cfzRj1D5 yKrQ== X-Forwarded-Encrypted: i=1; AJvYcCVF6Nph8F0X8RD5uP+2U8hWeAy8ruRO9aQaA1U6unYBUiCiKLXG56AprmRRZF2rAgTVCDsnmGuZ051Uo6Z8qu7M/YRjUvJ/QqQuhROUERI= X-Gm-Message-State: AOJu0YymazprKlsLYJ0t7mVByou8gqGgXboRKDD0RrL3ar7/KthPcBpO t774z/hQsCJq/lPx3JPfWhJ2foi2GCUYJ8y2ttmaxCtzS/IFmM12VauXatq5rnrue0pBEOstV4R 1 X-Google-Smtp-Source: AGHT+IEN3+i0FuQtKQ8ctFnLdqGRAZmQjs+Yx+ked9HHTuYCbBj2/G4IO55WntlJkXDgmw+d5gMwgA== X-Received: by 2002:ad4:5599:0:b0:690:1705:5135 with SMTP id f25-20020ad45599000000b0069017055135mr8487288qvx.30.1709542209298; Mon, 04 Mar 2024 00:50:09 -0800 (PST) Date: Mon, 4 Mar 2024 09:50:07 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: Andrew Cooper , Wei Liu , xen-devel@lists.xenproject.org Subject: Re: [PATCH] x86/mm: re-implement get_page_light() using an atomic increment Message-ID: References: <20240301124228.56123-1-roger.pau@citrix.com> <6796aeba-52a2-426b-94e5-1852946dce98@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <6796aeba-52a2-426b-94e5-1852946dce98@suse.com> On Mon, Mar 04, 2024 at 08:54:34AM +0100, Jan Beulich wrote: > On 01.03.2024 13:42, Roger Pau Monne wrote: > > The current usage of a cmpxchg loop to increase the value of page count is not > > optimal on amd64, as there's already an instruction to do an atomic add to a > > 64bit integer. > > > > Switch the code in get_page_light() to use an atomic increment, as that avoids > > a loop construct. This slightly changes the order of the checks, as current > > code will crash before modifying the page count_info if the conditions are not > > correct, while with the proposed change the crash will happen immediately > > after having carried the counter increase. Since we are crashing anyway, I > > don't believe the re-ordering to have any meaningful impact. > > While I consider this argument fine for ... > > > --- a/xen/arch/x86/mm.c > > +++ b/xen/arch/x86/mm.c > > @@ -2580,16 +2580,10 @@ bool get_page(struct page_info *page, const struct domain *domain) > > */ > > static void get_page_light(struct page_info *page) > > { > > - unsigned long x, nx, y = page->count_info; > > + unsigned long old_pgc = arch_fetch_and_add(&page->count_info, 1); > > > > - do { > > - x = y; > > - nx = x + 1; > > - BUG_ON(!(x & PGC_count_mask)); /* Not allocated? */ > > ... this check, I'm afraid ... > > > - BUG_ON(!(nx & PGC_count_mask)); /* Overflow? */ > > ... this is a problem unless we discount the possibility of an overflow > happening in practice: If an overflow was detected only after the fact, > there would be a window in time where privilege escalation was still > possible from another CPU. IOW at the very least the description will > need extending further. Personally I wouldn't chance it and leave this > as a loop. So you are worried because this could potentially turn a DoS into an information leak during the brief period of time where the page counter has overflowed into the PGC state. My understating is the BUG_ON() was a mere protection against bad code that could mess with the counter, but that the counter overflowing is not a real issue during normal operation. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Mon Mar 04 08:54:51 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 08:54:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688219.1072151 (Exim 4.92) (envelope-from ) id 1rh45y-0005Uk-DU; Mon, 04 Mar 2024 08:54:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688219.1072151; Mon, 04 Mar 2024 08:54:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh45y-0005Ud-Ab; Mon, 04 Mar 2024 08:54:50 +0000 Received: by outflank-mailman (input) for mailman id 688219; Mon, 04 Mar 2024 08:54:49 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh45x-0005UX-I2 for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 08:54:49 +0000 Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [2a00:1450:4864:20::631]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id d9e5a1d6-da04-11ee-a1ee-f123f15fe8a2; Mon, 04 Mar 2024 09:54:46 +0100 (CET) Received: by mail-ej1-x631.google.com with SMTP id a640c23a62f3a-a2f22bfb4e6so687951266b.0 for ; Mon, 04 Mar 2024 00:54:47 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id yk1-20020a17090770c100b00a42f4678c95sm4533959ejb.59.2024.03.04.00.54.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Mar 2024 00:54:46 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d9e5a1d6-da04-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709542487; x=1710147287; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=XCnjEmRHlvJKM6m8BW7+Bp/9cjUdD9Md5fggTNmIsXc=; b=BgO6/glgt1n5ol8GmSChdlrif0y+Y0Dt58DRAVaPduQjHca7g685MX+WmLM8gJYCNO QyiklUn/6PRS/81ZX3ITfulTrgwU74GoWJEmXRmYvtk/LhziMWE9INXyC7m7evDUtTNP mcj5uauhFbOM0d8k4Q7te9SY/7Y+PFNcKlBduYskoisFPHPbkUXsGWm20PiPb4wCFlIz TLfpPZzXUfR/aPndLMT0SqxmzY3hGVZUNS/HreF9Pi5CBC9mo591zsL1feMCwoRo8qMP 1bU6qRneGg5yBO6l3a2pmrw5zA2Z5cAtU4Jz+KXEkckIjEneSz2dSXFVasWH3Uvr8CxG zzfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709542487; x=1710147287; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=XCnjEmRHlvJKM6m8BW7+Bp/9cjUdD9Md5fggTNmIsXc=; b=uQlLiDFj2cMN935cK4rgXlgbCCiin34E0a931OFOc4I7jnNSvyx9lNAsUnJ8pV8lwS TwNTDM2sO4jXq2UdCTpqu8FOS3qM/RUK7Jp7Z4ieb/a9yuVy7cwa06pJZC4yeMmGedrR 8ReSNLosQA4O5GQVPHgjIqozXWq7/Q84mx7Nqc67VhJlBujzzGV9FagvndZzL0NyUS4I BjlGEk07B7phVmNVm1G952INhqiT3mppQtCgN9D/+255mVhZldsn4+2dg8OmunFjLrZ+ 58+k1DL0cTAtBa5iVO7WvWMUYWWY+M5C+xjj8EQYlF3XEjiaIO3z5KdRWQ/NtRqSTn7Q uF4Q== X-Forwarded-Encrypted: i=1; AJvYcCX4A79crIgzRj3SE3gd1qZTlv19ITtiAdiy4klWttx0hyYUGbvnIGLQZ1LUecgkzjV9aOKfrRQiO5Ine1eO5lJS/PiY+XT232zEJnchdb8= X-Gm-Message-State: AOJu0Yxdxw/usx+43z8LHPna7t+88sa4BgUWOKu2Scowy87ZZEZnT8jL jhRuZvrzoe8FZDGWYWl4ok3yGzNPi7gI7ZlCDewhJzSa+I2VwYjJUDs1vXQaZg== X-Google-Smtp-Source: AGHT+IG5IsFDgYWyNh0dTQfQGQgwf3/GyANL/rmEeGlMLX8ERFc2rQIdBeLkXYsjQaoXmjmbUfh/Fg== X-Received: by 2002:a17:907:20b9:b0:a3e:7dbe:298b with SMTP id pw25-20020a17090720b900b00a3e7dbe298bmr5080947ejb.24.1709542486949; Mon, 04 Mar 2024 00:54:46 -0800 (PST) Message-ID: Date: Mon, 4 Mar 2024 09:54:47 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/mm: re-implement get_page_light() using an atomic increment Content-Language: en-US To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: Andrew Cooper , Wei Liu , xen-devel@lists.xenproject.org References: <20240301124228.56123-1-roger.pau@citrix.com> <6796aeba-52a2-426b-94e5-1852946dce98@suse.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 04.03.2024 09:50, Roger Pau Monné wrote: > On Mon, Mar 04, 2024 at 08:54:34AM +0100, Jan Beulich wrote: >> On 01.03.2024 13:42, Roger Pau Monne wrote: >>> The current usage of a cmpxchg loop to increase the value of page count is not >>> optimal on amd64, as there's already an instruction to do an atomic add to a >>> 64bit integer. >>> >>> Switch the code in get_page_light() to use an atomic increment, as that avoids >>> a loop construct. This slightly changes the order of the checks, as current >>> code will crash before modifying the page count_info if the conditions are not >>> correct, while with the proposed change the crash will happen immediately >>> after having carried the counter increase. Since we are crashing anyway, I >>> don't believe the re-ordering to have any meaningful impact. >> >> While I consider this argument fine for ... >> >>> --- a/xen/arch/x86/mm.c >>> +++ b/xen/arch/x86/mm.c >>> @@ -2580,16 +2580,10 @@ bool get_page(struct page_info *page, const struct domain *domain) >>> */ >>> static void get_page_light(struct page_info *page) >>> { >>> - unsigned long x, nx, y = page->count_info; >>> + unsigned long old_pgc = arch_fetch_and_add(&page->count_info, 1); >>> >>> - do { >>> - x = y; >>> - nx = x + 1; >>> - BUG_ON(!(x & PGC_count_mask)); /* Not allocated? */ >> >> ... this check, I'm afraid ... >> >>> - BUG_ON(!(nx & PGC_count_mask)); /* Overflow? */ >> >> ... this is a problem unless we discount the possibility of an overflow >> happening in practice: If an overflow was detected only after the fact, >> there would be a window in time where privilege escalation was still >> possible from another CPU. IOW at the very least the description will >> need extending further. Personally I wouldn't chance it and leave this >> as a loop. > > So you are worried because this could potentially turn a DoS into an > information leak during the brief period of time where the page > counter has overflowed into the PGC state. > > My understating is the BUG_ON() was a mere protection against bad code > that could mess with the counter, but that the counter overflowing is > not a real issue during normal operation. With the present counter width it should be a merely theoretical concern. I didn't do the older calculation again though taking LA57 into account, so I'm not sure we're not moving onto thinner and thinner ice as hardware (and our support for it) advances. As to "mere protection" - see how the less wide counter was an active issue on 32-bit Xen, back at the time. Jan From xen-devel-bounces@lists.xenproject.org Mon Mar 04 08:56:23 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 08:56:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688207.1072161 (Exim 4.92) (envelope-from ) id 1rh47O-00064K-RO; Mon, 04 Mar 2024 08:56:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688207.1072161; Mon, 04 Mar 2024 08:56:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh47O-00064D-NN; Mon, 04 Mar 2024 08:56:18 +0000 Received: by outflank-mailman (input) for mailman id 688207; Mon, 04 Mar 2024 08:34:21 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh3m9-0001MP-4j for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 08:34:21 +0000 Received: from mail.zytor.com (unknown [2607:7c80:54:3::138]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id fd437f97-da01-11ee-afda-a90da7624cb6; Mon, 04 Mar 2024 09:34:19 +0100 (CET) Received: from terminus.zytor.com (terminus.zytor.com [IPv6:2607:7c80:54:3:0:0:0:136]) (authenticated bits=0) by mail.zytor.com (8.17.2/8.17.1) with ESMTPSA id 4248XYnT449332 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 4 Mar 2024 00:33:39 -0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fd437f97-da01-11ee-afda-a90da7624cb6 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 4248XYnT449332 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2024021201; t=1709541220; bh=u5MzfYslbwvnWZsLlHhoH6dB+B9y4C5n+dg6pZDkb0I=; h=From:To:Cc:Subject:Date:From; b=GQPd+y3kbiU0y6OU0+1fgS8TmyqqCK9SoA0aHp/ONyWTSNTS57BZlHRyDAAf3oYLQ T0lsWLgRxjGhJTHbub4LbGBOB5h/iO4bQsiSkvZNtv2p2ZLoUEy5tv2rR420WMuNt5 lpNJSNyKv0k0omAspzGNdUtfI3m3TTeupmMR0sdZHTdAi/LE8DYEuqKqVkRwN8mFSZ alr3QYRNa97Y0Xe7VJtSagpcQY5AB7q/fEW8qSC9bDf0wN/TmYjm9iLAQpxL/m5j8t ZulPzFa+/DoNshIxNLC/T8YcgdI9dW+gvk2zSVFuDahyArrpuJGXNRve+v/jDinVPy L7/wpF0XQjujw== From: "Xin Li (Intel)" To: linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, jgross@suse.com, boris.ostrovsky@oracle.com, arnd@arndb.de, andrew.cooper3@citrix.com, brgerst@gmail.com Subject: [PATCH v2 1/1] x86/fred: Fix init_task thread stack pointer initialization Date: Mon, 4 Mar 2024 00:33:33 -0800 Message-ID: <20240304083333.449322-1-xin@zytor.com> X-Mailer: git-send-email 2.44.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit As TOP_OF_KERNEL_STACK_PADDING is defined as 0 on x86_64, no one noticed it's missing in the calculation of the .sp field in INIT_THREAD until it is defined to 16 with CONFIG_X86_FRED=y. Subtract TOP_OF_KERNEL_STACK_PADDING from the .sp field of INIT_THREAD. Fixes: 65c9cc9e2c14 ("x86/fred: Reserve space for the FRED stack frame") Fixes: 3adee777ad0d ("x86/smpboot: Remove initial_stack on 64-bit") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-lkp/202402262159.183c2a37-lkp@intel.com Signed-off-by: Xin Li (Intel) --- Change Since v1: * Apply offset TOP_OF_KERNEL_STACK_PADDING to all uses of __end_init_task (Brian Gerst). --- arch/x86/include/asm/processor.h | 6 ++++-- arch/x86/kernel/head_64.S | 3 ++- arch/x86/xen/xen-head.S | 2 +- 3 files changed, 7 insertions(+), 4 deletions(-) diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h index 26620d7642a9..17fe81998ce4 100644 --- a/arch/x86/include/asm/processor.h +++ b/arch/x86/include/asm/processor.h @@ -664,8 +664,10 @@ static __always_inline void prefetchw(const void *x) #else extern unsigned long __end_init_task[]; -#define INIT_THREAD { \ - .sp = (unsigned long)&__end_init_task - sizeof(struct pt_regs), \ +#define INIT_THREAD { \ + .sp = (unsigned long)&__end_init_task - \ + TOP_OF_KERNEL_STACK_PADDING - \ + sizeof(struct pt_regs), \ } extern unsigned long KSTK_ESP(struct task_struct *task); diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S index d4918d03efb4..c38e43589046 100644 --- a/arch/x86/kernel/head_64.S +++ b/arch/x86/kernel/head_64.S @@ -26,6 +26,7 @@ #include #include #include +#include /* * We are not able to switch in one step to the final KERNEL ADDRESS SPACE @@ -66,7 +67,7 @@ SYM_CODE_START_NOALIGN(startup_64) mov %rsi, %r15 /* Set up the stack for verify_cpu() */ - leaq (__end_init_task - PTREGS_SIZE)(%rip), %rsp + leaq (__end_init_task - TOP_OF_KERNEL_STACK_PADDING - PTREGS_SIZE)(%rip), %rsp leaq _text(%rip), %rdi diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S index a0ea285878db..04101b984f24 100644 --- a/arch/x86/xen/xen-head.S +++ b/arch/x86/xen/xen-head.S @@ -49,7 +49,7 @@ SYM_CODE_START(startup_xen) ANNOTATE_NOENDBR cld - leaq (__end_init_task - PTREGS_SIZE)(%rip), %rsp + leaq (__end_init_task - TOP_OF_KERNEL_STACK_PADDING - PTREGS_SIZE)(%rip), %rsp /* Set up %gs. * base-commit: e13841907b8fda0ae0ce1ec03684665f578416a8 -- 2.44.0 From xen-devel-bounces@lists.xenproject.org Mon Mar 04 09:23:17 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 09:23:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688229.1072200 (Exim 4.92) (envelope-from ) id 1rh4XU-0003X8-Ne; Mon, 04 Mar 2024 09:23:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688229.1072200; Mon, 04 Mar 2024 09:23:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh4XU-0003Wg-Id; Mon, 04 Mar 2024 09:23:16 +0000 Received: by outflank-mailman (input) for mailman id 688229; Mon, 04 Mar 2024 09:23:15 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh4XS-0002pf-QV for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 09:23:15 +0000 Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [2a00:1450:4864:20::630]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id d2e682e4-da08-11ee-afda-a90da7624cb6; Mon, 04 Mar 2024 10:23:12 +0100 (CET) Received: by mail-ej1-x630.google.com with SMTP id a640c23a62f3a-a45784702bbso26782766b.2 for ; Mon, 04 Mar 2024 01:23:12 -0800 (PST) Received: from fhilly.citrite.net (default-46-102-197-194.interdsl.co.uk. [46.102.197.194]) by smtp.gmail.com with ESMTPSA id tj10-20020a170907c24a00b00a444526962asm4485529ejc.128.2024.03.04.01.23.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Mar 2024 01:23:11 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d2e682e4-da08-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1709544191; x=1710148991; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=nduCErVJMqVVQtvPr6lEcDydzA3X7giYTe88D2YcYv0=; b=jWXs4Wq/0Q8nTI3KHNSs2GQZboZlQT1DeaBUwSzTIAVDZ/OvLlKn6w+Qi6JeInkZD1 5enoGvL18mqaFYtogjy+i29R4W0wImDfUpFZgobRJSN1zEkCmm7GARis12Q9krdg+8F0 aaJ/DmUz8brwgWPGIbRqTKgRWwqUyE5MR5Q60= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709544191; x=1710148991; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=nduCErVJMqVVQtvPr6lEcDydzA3X7giYTe88D2YcYv0=; b=Sc+XHgNuZK4BCwUaZa4xtJsx2F7AcnMbt5Fd7brKMMVP8CadvOom6OxtPYj3L6LcyJ 1pQRKNmW8yNEFSAXgUXWzLXdMzR4JjWl0wsjQ77wb3kxBw4NYeLSa+hfY3TzHG9NXcQm R5lUaCgOtbKX8+m1teoK8mSkI3GZn2CwlfNsEjHArMjRpn9PmAbcb/cpGx6wOZTxF8iN ifftt/W4iFeySHbsZ0vrSI6vfWm54HiOmvvzuvzwd1lMTV6BY5GKRfpXVxaPKPWwvyDo QZORX7SLqQuKLAlrNzpf4XnKtMbqI8HOlfGPntVK9HsQ1E6SPxtxiWUEBd+MrYHMJGSl 49sg== X-Gm-Message-State: AOJu0Ywb+5rC4g1t//Lmrhs9UOsOnuFzKpc2yAeQJ+aV8nrpDSfnfNvC ULZ1bVrjRAs57DznPicNkx3d4peQq/JfryS5JV+VOB3J4uPOZWnzStOKvapKLTplHoM7Et+tyE1 gFvo= X-Google-Smtp-Source: AGHT+IElbNVt8gtwOTgBUsCkmG6ilrMzz1ASszsJ4oxaKXL7Z8uxM2khjZSpQU/lSOaUzk6BKSWL1w== X-Received: by 2002:a17:906:7185:b0:a45:2091:8193 with SMTP id h5-20020a170906718500b00a4520918193mr2169268ejk.68.1709544191482; Mon, 04 Mar 2024 01:23:11 -0800 (PST) From: Fouad Hilly To: Xen-devel Cc: Wei Liu , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Fouad Hilly , Jan Beulich , Andrew Cooper , Wei Liu , George Dunlap , Julien Grall , Stefano Stabellini , Paul Durrant , Jun Nakajima , Kevin Tian Subject: [PATCH 3/3] x86: switch to eager fpu save / restore Date: Mon, 4 Mar 2024 09:13:07 +0000 Message-ID: <20240304091307.2295344-4-fouad.hilly@cloud.com> X-Mailer: git-send-email 2.42.0 In-Reply-To: <20240304091307.2295344-1-fouad.hilly@cloud.com> References: <20240304091307.2295344-1-fouad.hilly@cloud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Wei Liu Previously FPU is lazily switched. Due to the fact that a malicious guest can speculatively read the not yet switched out register states, we need to eagerly switch FPU states when a domain is scheduled to run. In the new world, Xen will eagerly switch FPU context in the scheduler. Xen itself won't set CR0.TS other than for the purpose of servicing a PV guest. The following things are done: 1. Xen will only set and clear CR0.TS on behalf of a PV guest. Any #NM received in Xen should only be delivered to the running PV guest. 2. Xen no longer causes vmexit for #NM for HVM guests when nested HVM is not in use. 3. When nested HVM is in use, Xen needs to trap #NM if specified by the L1 hypervisor, but all #NM handling is left to L1 hypervisor to deal with. 4. Xen saves and restores FPU states wherever it needs to. The following places are modified: 1. Scheduling in and out a guest; 2. Calling EFI runtime service; 3. ACPI reset; 4. x86 insn emulator fpu insn emulation. 5. Treat FPU as always initialised. Adjust following components: 1. HVM vcpu context save / load code; 2. arch_{get,set}_info_guest; 3. VLAPIC code. 6. Delete lazy FPU handling code. Strip XCR0 and IA32_XSS manipulation from __context_switch. We need to be able to zero out previously used state components. Push everything into fpu_xrstor as that's the most suitable place. Tested on AMD with PKU disabled and Intel, no performance degradation. Signed-off-by: Wei Liu Signed-off-by: Roger Pau Monné Signed-off-by: Fouad Hilly --- CC: Jan Beulich CC: Andrew Cooper CC: "Roger Pau Monné" CC: Wei Liu CC: George Dunlap CC: Julien Grall CC: Stefano Stabellini CC: Paul Durrant CC: Jun Nakajima CC: Kevin Tian --- xen/arch/x86/cpu/common.c | 3 - xen/arch/x86/domain.c | 10 +- xen/arch/x86/domctl.c | 4 +- xen/arch/x86/hvm/emulate.c | 38 +---- xen/arch/x86/hvm/hvm.c | 8 +- xen/arch/x86/hvm/svm/nestedsvm.c | 62 +------ xen/arch/x86/hvm/svm/svm.c | 81 +-------- xen/arch/x86/hvm/svm/vmcb.c | 4 +- xen/arch/x86/hvm/vlapic.c | 4 - xen/arch/x86/hvm/vmx/vmcs.c | 8 +- xen/arch/x86/hvm/vmx/vmx.c | 70 +------- xen/arch/x86/hvm/vmx/vvmx.c | 15 +- xen/arch/x86/i387.c | 164 ++++--------------- xen/arch/x86/include/asm/domain.h | 3 - xen/arch/x86/include/asm/hvm/svm/nestedsvm.h | 3 - xen/arch/x86/include/asm/hvm/vmx/vmcs.h | 2 - xen/arch/x86/include/asm/i387.h | 3 +- xen/arch/x86/include/asm/xstate.h | 17 +- xen/arch/x86/pv/misc-hypercalls.c | 3 +- xen/arch/x86/traps.c | 18 +- xen/arch/x86/xstate.c | 26 --- xen/common/domain.c | 2 - xen/common/efi/runtime.c | 9 +- xen/include/xen/sched.h | 4 - 24 files changed, 72 insertions(+), 489 deletions(-) diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c index 28d7f34c4dbe..9ea748f959af 100644 --- a/xen/arch/x86/cpu/common.c +++ b/xen/arch/x86/cpu/common.c @@ -967,9 +967,6 @@ void cpu_init(void) /* Install correct page table. */ write_ptbase(current); - /* Ensure FPU gets initialised for each domain. */ - stts(); - /* Reset debug registers: */ write_debugreg(0, 0); write_debugreg(1, 0); diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c index bda853e3c92b..742d69dd93bb 100644 --- a/xen/arch/x86/domain.c +++ b/xen/arch/x86/domain.c @@ -1996,15 +1996,7 @@ static void __context_switch(void) if ( !is_idle_domain(nd) ) { memcpy(stack_regs, &n->arch.user_regs, CTXT_SWITCH_STACK_BYTES); - if ( cpu_has_xsave ) - { - if ( !set_xcr0(n->arch.xcr0 ?: XSTATE_FP_SSE) ) - BUG(); - - if ( cpu_has_xsaves && is_hvm_vcpu(n) ) - set_msr_xss(n->arch.msrs->xss.raw); - } - vcpu_restore_fpu_nonlazy(n, false); + vcpu_restore_fpu(n); nd->arch.ctxt_switch->to(n); } diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c index 9a72d57333e9..d838427feb52 100644 --- a/xen/arch/x86/domctl.c +++ b/xen/arch/x86/domctl.c @@ -967,7 +967,6 @@ long arch_do_domctl( v->arch.xcr0 = _xcr0; v->arch.xcr0_accum = _xcr0_accum; - v->arch.nonlazy_xstate_used = _xcr0_accum & XSTATE_NONLAZY; compress_xsave_states(v, _xsave_area, evc->size - PV_XSAVE_HDR_SIZE); @@ -1347,8 +1346,7 @@ void arch_get_info_guest(struct vcpu *v, vcpu_guest_context_u c) c(flags = v->arch.pv.vgc_flags & ~(VGCF_i387_valid|VGCF_in_kernel)); else c(flags = 0); - if ( v->fpu_initialised ) - c(flags |= VGCF_i387_valid); + c(flags |= VGCF_i387_valid); if ( !(v->pause_flags & VPF_down) ) c(flags |= VGCF_online); if ( !compat ) diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c index ab1bc516839a..8a1720008454 100644 --- a/xen/arch/x86/hvm/emulate.c +++ b/xen/arch/x86/hvm/emulate.c @@ -2361,9 +2361,7 @@ static int cf_check hvmemul_get_fpu( { struct vcpu *curr = current; - if ( !curr->fpu_dirtied ) - alternative_vcall(hvm_funcs.fpu_dirty_intercept); - else if ( type == X86EMUL_FPU_fpu ) + if ( type == X86EMUL_FPU_fpu ) { const typeof(curr->arch.xsave_area->fpu_sse) *fpu_ctxt = curr->arch.fpu_ctxt; @@ -2372,16 +2370,8 @@ static int cf_check hvmemul_get_fpu( * Latch current register state so that we can back out changes * if needed (namely when a memory write fails after register state * has already been updated). - * NB: We don't really need the "enable" part of the called function - * (->fpu_dirtied set implies CR0.TS clear), but the additional - * overhead should be low enough to not warrant introduction of yet - * another slightly different function. However, we need to undo the - * ->fpu_dirtied clearing the function does as well as the possible - * masking of all exceptions by FNSTENV.) */ - save_fpu_enable(); - curr->fpu_initialised = true; - curr->fpu_dirtied = true; + vcpu_save_fpu(curr); if ( (fpu_ctxt->fcw & 0x3f) != 0x3f ) { uint16_t fcw; @@ -2415,12 +2405,8 @@ static void cf_check hvmemul_put_fpu( * Latch current register state so that we can replace FIP/FDP/FOP * (which have values resulting from our own invocation of the FPU * instruction during emulation). - * NB: See also the comment in hvmemul_get_fpu(); we don't need to - * set ->fpu_dirtied here as it is going to be cleared below, and - * we also don't need to reload FCW as we're forcing full state to - * be reloaded anyway. */ - save_fpu_enable(); + vcpu_save_fpu(curr); if ( boot_cpu_has(X86_FEATURE_FDP_EXCP_ONLY) && !(fpu_ctxt->fsw & ~fpu_ctxt->fcw & 0x003f) ) @@ -2465,23 +2451,7 @@ static void cf_check hvmemul_put_fpu( } if ( backout == X86EMUL_FPU_fpu ) - { - /* - * To back out changes to the register file - * - in fully eager mode, restore original state immediately, - * - in lazy mode, simply adjust state such that upon next FPU insn - * use by the guest we'll reload the state saved (or freshly loaded) - * by hvmemul_get_fpu(). - */ - if ( curr->arch.fully_eager_fpu ) - vcpu_restore_fpu_nonlazy(curr, false); - else - { - curr->fpu_dirtied = false; - stts(); - alternative_vcall(hvm_funcs.fpu_leave, curr); - } - } + vcpu_restore_fpu(curr); } static int cf_check hvmemul_tlb_op( diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index c75959588c0e..e532e2a2d6a0 100644 --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -899,11 +899,8 @@ static int cf_check hvm_save_cpu_ctxt(struct vcpu *v, hvm_domain_context_t *h) ctxt.ldtr_base = seg.base; ctxt.ldtr_arbytes = seg.attr; - if ( v->fpu_initialised ) - { - memcpy(ctxt.fpu_regs, v->arch.fpu_ctxt, sizeof(ctxt.fpu_regs)); - ctxt.flags = XEN_X86_FPU_INITIALISED; - } + memcpy(ctxt.fpu_regs, v->arch.fpu_ctxt, sizeof(ctxt.fpu_regs)); + ctxt.flags = XEN_X86_FPU_INITIALISED; return hvm_save_entry(CPU, v->vcpu_id, h, &ctxt); } @@ -1342,7 +1339,6 @@ static int cf_check hvm_load_cpu_xsave_states( v->arch.xcr0 = ctxt->xcr0; v->arch.xcr0_accum = ctxt->xcr0_accum; - v->arch.nonlazy_xstate_used = ctxt->xcr0_accum & XSTATE_NONLAZY; compress_xsave_states(v, &ctxt->save_area, size - offsetof(struct hvm_hw_cpu_xsave, save_area)); diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c index e4e01add8c5b..9f7595ec34f6 100644 --- a/xen/arch/x86/hvm/svm/nestedsvm.c +++ b/xen/arch/x86/hvm/svm/nestedsvm.c @@ -168,58 +168,6 @@ int cf_check nsvm_vcpu_reset(struct vcpu *v) return 0; } -static uint64_t nestedsvm_fpu_vmentry(uint64_t n1cr0, - struct vmcb_struct *vvmcb, - struct vmcb_struct *n1vmcb, struct vmcb_struct *n2vmcb) -{ - uint64_t vcr0; - - vcr0 = vvmcb->_cr0; - if ( !(n1cr0 & X86_CR0_TS) && (n1vmcb->_cr0 & X86_CR0_TS) ) - { - /* - * svm_fpu_leave() run while l1 guest was running. - * Sync FPU state with l2 guest. - */ - vcr0 |= X86_CR0_TS; - n2vmcb->_exception_intercepts |= (1U << X86_EXC_NM); - } - else if ( !(vcr0 & X86_CR0_TS) && (n2vmcb->_cr0 & X86_CR0_TS) ) - { - /* - * svm_fpu_enter() run while l1 guest was running. - * Sync FPU state with l2 guest. - */ - vcr0 &= ~X86_CR0_TS; - n2vmcb->_exception_intercepts &= ~(1U << X86_EXC_NM); - } - - return vcr0; -} - -static void nestedsvm_fpu_vmexit(struct vmcb_struct *n1vmcb, - struct vmcb_struct *n2vmcb, uint64_t n1cr0, uint64_t guest_cr0) -{ - if ( !(guest_cr0 & X86_CR0_TS) && (n2vmcb->_cr0 & X86_CR0_TS) ) - { - /* - * svm_fpu_leave() run while l2 guest was running. - * Sync FPU state with l1 guest. - */ - n1vmcb->_cr0 |= X86_CR0_TS; - n1vmcb->_exception_intercepts |= (1U << X86_EXC_NM); - } - else if ( !(n1cr0 & X86_CR0_TS) && (n1vmcb->_cr0 & X86_CR0_TS) ) - { - /* - * svm_fpu_enter() run while l2 guest was running. - * Sync FPU state with l1 guest. - */ - n1vmcb->_cr0 &= ~X86_CR0_TS; - n1vmcb->_exception_intercepts &= ~(1U << X86_EXC_NM); - } -} - static int nsvm_vcpu_hostsave(struct vcpu *v, unsigned int inst_len) { struct nestedsvm *svm = &vcpu_nestedsvm(v); @@ -249,7 +197,6 @@ static int nsvm_vcpu_hostsave(struct vcpu *v, unsigned int inst_len) static int nsvm_vcpu_hostrestore(struct vcpu *v, struct cpu_user_regs *regs) { struct nestedvcpu *nv = &vcpu_nestedhvm(v); - struct nestedsvm *svm = &vcpu_nestedsvm(v); struct vmcb_struct *n1vmcb, *n2vmcb; int rc; @@ -284,8 +231,6 @@ static int nsvm_vcpu_hostrestore(struct vcpu *v, struct cpu_user_regs *regs) gdprintk(XENLOG_ERR, "hvm_set_cr4 failed, rc: %u\n", rc); /* CR0 */ - nestedsvm_fpu_vmexit(n1vmcb, n2vmcb, - svm->ns_cr0, v->arch.hvm.guest_cr[0]); v->arch.hvm.guest_cr[0] = n1vmcb->_cr0 | X86_CR0_PE; n1vmcb->rflags &= ~X86_EFLAGS_VM; rc = hvm_set_cr0(n1vmcb->_cr0 | X86_CR0_PE, true); @@ -293,7 +238,6 @@ static int nsvm_vcpu_hostrestore(struct vcpu *v, struct cpu_user_regs *regs) hvm_inject_hw_exception(X86_EXC_GP, 0); if ( rc != X86EMUL_OKAY ) gdprintk(XENLOG_ERR, "hvm_set_cr0 failed, rc: %u\n", rc); - svm->ns_cr0 = v->arch.hvm.guest_cr[0]; /* CR2 */ v->arch.hvm.guest_cr[2] = n1vmcb->_cr2; @@ -421,7 +365,6 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct cpu_user_regs *regs) struct vmcb_struct *ns_vmcb, *n1vmcb, *n2vmcb; vmcbcleanbits_t clean = {}; int rc; - uint64_t cr0; ns_vmcb = nv->nv_vvmcx; n1vmcb = nv->nv_n1vmcx; @@ -455,7 +398,6 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct cpu_user_regs *regs) * safed here. * The overhead comes from (ordered from highest to lowest): * - svm_ctxt_switch_to (CPU context switching) - * - svm_fpu_enter, svm_fpu_leave (lazy FPU switching) * - emulated CLGI (clears VINTR intercept) * - host clears VINTR intercept * Test results show that the overhead is high enough that the @@ -554,10 +496,8 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct cpu_user_regs *regs) gdprintk(XENLOG_ERR, "hvm_set_cr4 failed, rc: %u\n", rc); /* CR0 */ - svm->ns_cr0 = v->arch.hvm.guest_cr[0]; - cr0 = nestedsvm_fpu_vmentry(svm->ns_cr0, ns_vmcb, n1vmcb, n2vmcb); v->arch.hvm.guest_cr[0] = ns_vmcb->_cr0; - rc = hvm_set_cr0(cr0, true); + rc = hvm_set_cr0(ns_vmcb->_cr0, true); if ( rc == X86EMUL_EXCEPTION ) hvm_inject_hw_exception(X86_EXC_GP, 0); if ( rc != X86EMUL_OKAY ) diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c index b551eac8078d..7a92b432e788 100644 --- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c @@ -104,38 +104,6 @@ static void cf_check svm_cpu_down(void) write_efer(read_efer() & ~EFER_SVME); } -static void svm_fpu_enter(struct vcpu *v) -{ - struct vmcb_struct *n1vmcb = vcpu_nestedhvm(v).nv_n1vmcx; - - vcpu_restore_fpu_lazy(v); - vmcb_set_exception_intercepts( - n1vmcb, - vmcb_get_exception_intercepts(n1vmcb) & ~(1U << X86_EXC_NM)); -} - -static void cf_check svm_fpu_leave(struct vcpu *v) -{ - struct vmcb_struct *n1vmcb = vcpu_nestedhvm(v).nv_n1vmcx; - - ASSERT(!v->fpu_dirtied); - ASSERT(read_cr0() & X86_CR0_TS); - - /* - * If the guest does not have TS enabled then we must cause and handle an - * exception on first use of the FPU. If the guest *does* have TS enabled - * then this is not necessary: no FPU activity can occur until the guest - * clears CR0.TS, and we will initialise the FPU when that happens. - */ - if ( !(v->arch.hvm.guest_cr[0] & X86_CR0_TS) ) - { - vmcb_set_exception_intercepts( - n1vmcb, - vmcb_get_exception_intercepts(n1vmcb) | (1U << X86_EXC_NM)); - vmcb_set_cr0(n1vmcb, vmcb_get_cr0(n1vmcb) | X86_CR0_TS); - } -} - static void cf_check svm_update_guest_cr( struct vcpu *v, unsigned int cr, unsigned int flags) { @@ -145,20 +113,6 @@ static void cf_check svm_update_guest_cr( switch ( cr ) { case 0: - { - unsigned long hw_cr0_mask = 0; - - if ( !(v->arch.hvm.guest_cr[0] & X86_CR0_TS) ) - { - if ( v != current ) - { - if ( !v->arch.fully_eager_fpu ) - hw_cr0_mask |= X86_CR0_TS; - } - else if ( vmcb_get_cr0(vmcb) & X86_CR0_TS ) - svm_fpu_enter(v); - } - if ( paging_mode_hap(v->domain) ) { uint32_t intercepts = vmcb_get_cr_intercepts(vmcb); @@ -169,12 +123,12 @@ static void cf_check svm_update_guest_cr( vmcb_set_cr_intercepts(vmcb, intercepts | CR_INTERCEPT_CR3_WRITE); } - value = v->arch.hvm.guest_cr[0] | hw_cr0_mask; + value = v->arch.hvm.guest_cr[0]; if ( !paging_mode_hap(v->domain) ) value |= X86_CR0_PG | X86_CR0_WP; vmcb_set_cr0(vmcb, value); break; - } + case 2: vmcb_set_cr2(vmcb, v->arch.hvm.guest_cr[2]); break; @@ -950,9 +904,6 @@ static void cf_check svm_ctxt_switch_from(struct vcpu *v) if ( unlikely((read_efer() & EFER_SVME) == 0) ) return; - if ( !v->arch.fully_eager_fpu ) - svm_fpu_leave(v); - svm_save_dr(v); svm_tsc_ratio_save(v); @@ -1709,28 +1660,6 @@ static void svm_do_nested_pgfault(struct vcpu *v, domain_crash(v->domain); } -static void cf_check svm_fpu_dirty_intercept(void) -{ - struct vcpu *v = current; - struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; - struct vmcb_struct *n1vmcb = vcpu_nestedhvm(v).nv_n1vmcx; - - svm_fpu_enter(v); - - if ( vmcb != n1vmcb ) - { - /* Check if l1 guest must make FPU ready for the l2 guest */ - if ( v->arch.hvm.guest_cr[0] & X86_CR0_TS ) - hvm_inject_hw_exception(X86_EXC_NM, X86_EVENT_NO_EC); - else - vmcb_set_cr0(n1vmcb, vmcb_get_cr0(n1vmcb) & ~X86_CR0_TS); - return; - } - - if ( !(v->arch.hvm.guest_cr[0] & X86_CR0_TS) ) - vmcb_set_cr0(vmcb, vmcb_get_cr0(vmcb) & ~X86_CR0_TS); -} - static void svm_vmexit_do_cr_access( struct vmcb_struct *vmcb, struct cpu_user_regs *regs) { @@ -2499,7 +2428,6 @@ static struct hvm_function_table __initdata_cf_clobber svm_function_table = { .update_guest_cr = svm_update_guest_cr, .update_guest_efer = svm_update_guest_efer, .cpuid_policy_changed = svm_cpuid_policy_changed, - .fpu_leave = svm_fpu_leave, .set_guest_pat = svm_set_guest_pat, .get_guest_pat = svm_get_guest_pat, .set_tsc_offset = svm_set_tsc_offset, @@ -2509,7 +2437,6 @@ static struct hvm_function_table __initdata_cf_clobber svm_function_table = { .get_pending_event = svm_get_pending_event, .invlpg = svm_invlpg, .wbinvd_intercept = svm_wbinvd_intercept, - .fpu_dirty_intercept = svm_fpu_dirty_intercept, .msr_read_intercept = svm_msr_read_intercept, .msr_write_intercept = svm_msr_write_intercept, .enable_msr_interception = svm_enable_msr_interception, @@ -2802,10 +2729,6 @@ void asmlinkage svm_vmexit_handler(void) } break; - case VMEXIT_EXCEPTION_NM: - svm_fpu_dirty_intercept(); - break; - case VMEXIT_EXCEPTION_PF: { unsigned long va = vmcb->ei.exc.cr2; diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c index 282fe7cdbe39..bf568d256f5e 100644 --- a/xen/arch/x86/hvm/svm/vmcb.c +++ b/xen/arch/x86/hvm/svm/vmcb.c @@ -127,9 +127,7 @@ static int construct_vmcb(struct vcpu *v) paging_update_paging_modes(v); - vmcb->_exception_intercepts = - HVM_TRAP_MASK | - (v->arch.fully_eager_fpu ? 0 : (1U << X86_EXC_NM)); + vmcb->_exception_intercepts = HVM_TRAP_MASK; if ( paging_mode_hap(v->domain) ) { diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c index dcbcf4a1feb5..2551260acd4d 100644 --- a/xen/arch/x86/hvm/vlapic.c +++ b/xen/arch/x86/hvm/vlapic.c @@ -263,7 +263,6 @@ static void vlapic_init_sipi_one(struct vcpu *target, uint32_t icr) switch ( icr & APIC_DM_MASK ) { case APIC_DM_INIT: { - bool fpu_initialised; int rc; /* No work on INIT de-assert for P4-type APIC. */ @@ -275,11 +274,8 @@ static void vlapic_init_sipi_one(struct vcpu *target, uint32_t icr) break; hvm_vcpu_down(target); domain_lock(target->domain); - /* Reset necessary VCPU state. This does not include FPU state. */ - fpu_initialised = target->fpu_initialised; rc = vcpu_reset(target); ASSERT(!rc); - target->fpu_initialised = fpu_initialised; vlapic_do_init(vcpu_vlapic(target)); domain_unlock(target->domain); break; diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c index 6b4f004a3d21..25bee5e5c404 100644 --- a/xen/arch/x86/hvm/vmx/vmcs.c +++ b/xen/arch/x86/hvm/vmx/vmcs.c @@ -1242,10 +1242,7 @@ static int construct_vmcs(struct vcpu *v) __vmwrite(HOST_TR_SELECTOR, TSS_SELECTOR); /* Host control registers. */ - v->arch.hvm.vmx.host_cr0 = read_cr0() & ~X86_CR0_TS; - if ( !v->arch.fully_eager_fpu ) - v->arch.hvm.vmx.host_cr0 |= X86_CR0_TS; - __vmwrite(HOST_CR0, v->arch.hvm.vmx.host_cr0); + __vmwrite(HOST_CR0, read_cr0()); __vmwrite(HOST_CR4, mmu_cr4_features); if ( cpu_has_vmx_efer ) __vmwrite(HOST_EFER, read_efer()); @@ -1325,8 +1322,7 @@ static int construct_vmcs(struct vcpu *v) __vmwrite(VMCS_LINK_POINTER, ~0UL); v->arch.hvm.vmx.exception_bitmap = HVM_TRAP_MASK - | (paging_mode_hap(d) ? 0 : (1U << X86_EXC_PF)) - | (v->arch.fully_eager_fpu ? 0 : (1U << X86_EXC_NM)); + | (paging_mode_hap(d) ? 0 : (1U << X86_EXC_PF)); if ( cpu_has_vmx_notify_vm_exiting ) __vmwrite(NOTIFY_WINDOW, vm_notify_window); diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c index 23bdf0d1957f..6e21e8b9d396 100644 --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -63,7 +63,6 @@ static void cf_check vmx_update_guest_cr( struct vcpu *v, unsigned int cr, unsigned int flags); static void cf_check vmx_update_guest_efer(struct vcpu *v); static void cf_check vmx_wbinvd_intercept(void); -static void cf_check vmx_fpu_dirty_intercept(void); static int cf_check vmx_msr_read_intercept( unsigned int msr, uint64_t *msr_content); static int cf_check vmx_msr_write_intercept( @@ -1087,41 +1086,6 @@ static int cf_check vmx_load_vmcs_ctxt(struct vcpu *v, struct hvm_hw_cpu *ctxt) return 0; } -static void vmx_fpu_enter(struct vcpu *v) -{ - vcpu_restore_fpu_lazy(v); - v->arch.hvm.vmx.exception_bitmap &= ~(1u << X86_EXC_NM); - vmx_update_exception_bitmap(v); - v->arch.hvm.vmx.host_cr0 &= ~X86_CR0_TS; - __vmwrite(HOST_CR0, v->arch.hvm.vmx.host_cr0); -} - -static void cf_check vmx_fpu_leave(struct vcpu *v) -{ - ASSERT(!v->fpu_dirtied); - ASSERT(read_cr0() & X86_CR0_TS); - - if ( !(v->arch.hvm.vmx.host_cr0 & X86_CR0_TS) ) - { - v->arch.hvm.vmx.host_cr0 |= X86_CR0_TS; - __vmwrite(HOST_CR0, v->arch.hvm.vmx.host_cr0); - } - - /* - * If the guest does not have TS enabled then we must cause and handle an - * exception on first use of the FPU. If the guest *does* have TS enabled - * then this is not necessary: no FPU activity can occur until the guest - * clears CR0.TS, and we will initialise the FPU when that happens. - */ - if ( !(v->arch.hvm.guest_cr[0] & X86_CR0_TS) ) - { - v->arch.hvm.hw_cr[0] |= X86_CR0_TS; - __vmwrite(GUEST_CR0, v->arch.hvm.hw_cr[0]); - v->arch.hvm.vmx.exception_bitmap |= (1u << X86_EXC_NM); - vmx_update_exception_bitmap(v); - } -} - static void cf_check vmx_ctxt_switch_from(struct vcpu *v) { /* @@ -1144,8 +1108,6 @@ static void cf_check vmx_ctxt_switch_from(struct vcpu *v) vmx_vmcs_reload(v); } - if ( !v->arch.fully_eager_fpu ) - vmx_fpu_leave(v); vmx_save_guest_msrs(v); vmx_restore_host_msrs(); vmx_save_dr(v); @@ -1666,17 +1628,6 @@ static void cf_check vmx_update_guest_cr( else nvmx_set_cr_read_shadow(v, 0); - if ( !(v->arch.hvm.guest_cr[0] & X86_CR0_TS) ) - { - if ( v != current ) - { - if ( !v->arch.fully_eager_fpu ) - hw_cr0_mask |= X86_CR0_TS; - } - else if ( v->arch.hvm.hw_cr[0] & X86_CR0_TS ) - vmx_fpu_enter(v); - } - realmode = !(v->arch.hvm.guest_cr[0] & X86_CR0_PE); if ( !vmx_unrestricted_guest(v) && @@ -2733,7 +2684,6 @@ static struct hvm_function_table __initdata_cf_clobber vmx_function_table = { .update_guest_cr = vmx_update_guest_cr, .update_guest_efer = vmx_update_guest_efer, .cpuid_policy_changed = vmx_cpuid_policy_changed, - .fpu_leave = vmx_fpu_leave, .set_guest_pat = vmx_set_guest_pat, .get_guest_pat = vmx_get_guest_pat, .set_tsc_offset = vmx_set_tsc_offset, @@ -2745,7 +2695,6 @@ static struct hvm_function_table __initdata_cf_clobber vmx_function_table = { .cpu_up = vmx_cpu_up, .cpu_down = vmx_cpu_down, .wbinvd_intercept = vmx_wbinvd_intercept, - .fpu_dirty_intercept = vmx_fpu_dirty_intercept, .msr_read_intercept = vmx_msr_read_intercept, .msr_write_intercept = vmx_msr_write_intercept, .handle_cd = vmx_handle_cd, @@ -3066,20 +3015,6 @@ void update_guest_eip(void) hvm_inject_hw_exception(X86_EXC_DB, X86_EVENT_NO_EC); } -static void cf_check vmx_fpu_dirty_intercept(void) -{ - struct vcpu *curr = current; - - vmx_fpu_enter(curr); - - /* Disable TS in guest CR0 unless the guest wants the exception too. */ - if ( !(curr->arch.hvm.guest_cr[0] & X86_CR0_TS) ) - { - curr->arch.hvm.hw_cr[0] &= ~X86_CR0_TS; - __vmwrite(GUEST_CR0, curr->arch.hvm.hw_cr[0]); - } -} - static void vmx_dr_access(unsigned long exit_qualification, struct cpu_user_regs *regs) { @@ -4325,10 +4260,7 @@ void asmlinkage vmx_vmexit_handler(struct cpu_user_regs *regs) domain_pause_for_debugger(); } break; - case X86_EXC_NM: - HVMTRACE_1D(TRAP, vector); - vmx_fpu_dirty_intercept(); - break; + case X86_EXC_PF: __vmread(EXIT_QUALIFICATION, &exit_qualification); __vmread(VM_EXIT_INTR_ERROR_CODE, &ecode); diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c index ece0aa243a73..497592969dfc 100644 --- a/xen/arch/x86/hvm/vmx/vvmx.c +++ b/xen/arch/x86/hvm/vmx/vvmx.c @@ -1236,9 +1236,6 @@ static void virtual_vmentry(struct cpu_user_regs *regs) regs->rsp = get_vvmcs(v, GUEST_RSP); regs->rflags = get_vvmcs(v, GUEST_RFLAGS); - /* updating host cr0 to sync TS bit */ - __vmwrite(HOST_CR0, v->arch.hvm.vmx.host_cr0); - /* Setup virtual ETP for L2 guest*/ if ( nestedhvm_paging_mode_hap(v) ) /* This will setup the initial np2m for the nested vCPU */ @@ -1466,9 +1463,6 @@ static void virtual_vmexit(struct cpu_user_regs *regs) /* VM exit clears all bits except bit 1 */ regs->rflags = X86_EFLAGS_MBS; - /* updating host cr0 to sync TS bit */ - __vmwrite(HOST_CR0, v->arch.hvm.vmx.host_cr0); - if ( cpu_has_vmx_virtual_intr_delivery ) nvmx_update_apicv(v); @@ -2454,19 +2448,14 @@ int nvmx_n2_vmexit_handler(struct cpu_user_regs *regs, __vmread(VM_EXIT_INTR_INFO, &intr_info); vector = intr_info & INTR_INFO_VECTOR_MASK; /* - * decided by L0 and L1 exception bitmap, if the vetor is set by - * both, L0 has priority on #PF and #NM, L1 has priority on others + * decided by L0 and L1 exception bitmap, if the vector is set by + * both, L0 has priority on #PF, L1 has priority on others */ if ( vector == X86_EXC_PF ) { if ( paging_mode_hap(v->domain) ) nvcpu->nv_vmexit_pending = 1; } - else if ( vector == X86_EXC_NM ) - { - if ( v->fpu_dirtied ) - nvcpu->nv_vmexit_pending = 1; - } else if ( (intr_info & valid_mask) == valid_mask ) { exec_bitmap = get_vvmcs(v, EXCEPTION_BITMAP); diff --git a/xen/arch/x86/i387.c b/xen/arch/x86/i387.c index 7a4297cc921e..09df2c962c9a 100644 --- a/xen/arch/x86/i387.c +++ b/xen/arch/x86/i387.c @@ -20,7 +20,7 @@ /* FPU Restore Functions */ /*******************************/ /* Restore x87 extended state */ -static inline void fpu_xrstor(struct vcpu *v, uint64_t mask) +static inline void fpu_xrstor(struct vcpu *v) { bool ok; @@ -28,10 +28,14 @@ static inline void fpu_xrstor(struct vcpu *v, uint64_t mask) /* * XCR0 normally represents what guest OS set. In case of Xen itself, * we set the accumulated feature mask before doing save/restore. + * + * Combine the outgoing and incoming XCR0 before calling xrstor to make + * sure any state component used by outgoing vcpu is cleared. Rewrite XCR0 + * to be the ones used by incoming vcpu afterwards. */ - ok = set_xcr0(v->arch.xcr0_accum | XSTATE_FP_SSE); + ok = set_xcr0(v->arch.xcr0_accum | get_xcr0() | XSTATE_FP_SSE); ASSERT(ok); - xrstor(v, mask); + xrstor(v, XSTATE_ALL); ok = set_xcr0(v->arch.xcr0 ?: XSTATE_FP_SSE); ASSERT(ok); } @@ -110,33 +114,11 @@ static inline void fpu_fxrstor(struct vcpu *v) /* FPU Save Functions */ /*******************************/ -static inline uint64_t vcpu_xsave_mask(const struct vcpu *v) -{ - if ( v->fpu_dirtied ) - return v->arch.nonlazy_xstate_used ? XSTATE_ALL : XSTATE_LAZY; - - ASSERT(v->arch.nonlazy_xstate_used); - - /* - * The offsets of components which live in the extended region of - * compact xsave area are not fixed. Xsave area may be overwritten - * when a xsave with v->fpu_dirtied set is followed by one with - * v->fpu_dirtied clear. - * In such case, if hypervisor uses compact xsave area and guest - * has ever used lazy states (checking xcr0_accum excluding - * XSTATE_FP_SSE), vcpu_xsave_mask will return XSTATE_ALL. Otherwise - * return XSTATE_NONLAZY. - */ - return xstate_all(v) ? XSTATE_ALL : XSTATE_NONLAZY; -} - /* Save x87 extended state */ static inline void fpu_xsave(struct vcpu *v) { bool ok; - uint64_t mask = vcpu_xsave_mask(v); - ASSERT(mask); ASSERT(v->arch.xsave_area); /* * XCR0 normally represents what guest OS set. In case of Xen itself, @@ -144,7 +126,7 @@ static inline void fpu_xsave(struct vcpu *v) */ ok = set_xcr0(v->arch.xcr0_accum | XSTATE_FP_SSE); ASSERT(ok); - xsave(v, mask); + xsave(v, XSTATE_ALL); ok = set_xcr0(v->arch.xcr0 ?: XSTATE_FP_SSE); ASSERT(ok); } @@ -202,107 +184,6 @@ static inline void fpu_fxsave(struct vcpu *v) /*******************************/ /* VCPU FPU Functions */ /*******************************/ -/* Restore FPU state whenever VCPU is schduled in. */ -void vcpu_restore_fpu_nonlazy(struct vcpu *v, bool need_stts) -{ - /* Restore nonlazy extended state (i.e. parts not tracked by CR0.TS). */ - if ( !v->arch.fully_eager_fpu && !v->arch.nonlazy_xstate_used ) - goto maybe_stts; - - ASSERT(!is_idle_vcpu(v)); - - /* Avoid recursion */ - clts(); - - /* - * When saving full state even with !v->fpu_dirtied (see vcpu_xsave_mask() - * above) we also need to restore full state, to prevent subsequently - * saving state belonging to another vCPU. - */ - if ( v->arch.fully_eager_fpu || (v->arch.xsave_area && xstate_all(v)) ) - { - if ( cpu_has_xsave ) - fpu_xrstor(v, XSTATE_ALL); - else - fpu_fxrstor(v); - - v->fpu_initialised = 1; - v->fpu_dirtied = 1; - - /* Xen doesn't need TS set, but the guest might. */ - need_stts = is_pv_vcpu(v) && (v->arch.pv.ctrlreg[0] & X86_CR0_TS); - } - else - { - fpu_xrstor(v, XSTATE_NONLAZY); - need_stts = true; - } - - maybe_stts: - if ( need_stts ) - stts(); -} - -/* - * Restore FPU state when #NM is triggered. - */ -void vcpu_restore_fpu_lazy(struct vcpu *v) -{ - ASSERT(!is_idle_vcpu(v)); - - /* Avoid recursion. */ - clts(); - - if ( v->fpu_dirtied ) - return; - - ASSERT(!v->arch.fully_eager_fpu); - - if ( cpu_has_xsave ) - fpu_xrstor(v, XSTATE_LAZY); - else - fpu_fxrstor(v); - - v->fpu_initialised = 1; - v->fpu_dirtied = 1; -} - -/* - * On each context switch, save the necessary FPU info of VCPU being switch - * out. It dispatches saving operation based on CPU's capability. - */ -static bool _vcpu_save_fpu(struct vcpu *v) -{ - if ( !v->fpu_dirtied && !v->arch.nonlazy_xstate_used ) - return false; - - ASSERT(!is_idle_vcpu(v)); - - /* This can happen, if a paravirtualised guest OS has set its CR0.TS. */ - clts(); - - if ( cpu_has_xsave ) - fpu_xsave(v); - else - fpu_fxsave(v); - - v->fpu_dirtied = 0; - - return true; -} - -void vcpu_save_fpu(struct vcpu *v) -{ - _vcpu_save_fpu(v); - stts(); -} - -void save_fpu_enable(void) -{ - if ( !_vcpu_save_fpu(current) ) - clts(); -} - /* Initialize FPU's context save area */ int vcpu_init_fpu(struct vcpu *v) { @@ -347,8 +228,6 @@ void vcpu_setup_fpu(struct vcpu *v, struct xsave_struct *xsave_area, ASSERT(!xsave_area || xsave_area == v->arch.xsave_area); - v->fpu_initialised = !!data; - if ( data ) { memcpy(fpu_sse, data, sizeof(*fpu_sse)); @@ -386,6 +265,33 @@ void vcpu_destroy_fpu(struct vcpu *v) xfree(v->arch.fpu_ctxt); } +void vcpu_save_fpu(struct vcpu *v) +{ + ASSERT(!is_idle_vcpu(v)); + + /* This can happen, if a paravirtualised guest OS has set its CR0.TS. */ + clts(); + + if ( cpu_has_xsave ) + fpu_xsave(v); + else + fpu_fxsave(v); +} + +void vcpu_restore_fpu(struct vcpu *v) +{ + ASSERT(!is_idle_vcpu(v)); + ASSERT(!(read_cr0() & X86_CR0_TS)); + + if ( cpu_has_xsave ) + fpu_xrstor(v); + else + fpu_fxrstor(v); + + if ( is_pv_vcpu(v) && (v->arch.pv.ctrlreg[0] & X86_CR0_TS) ) + stts(); +} + /* * Local variables: * mode: C diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h index 622d22bef255..396e9998d04f 100644 --- a/xen/arch/x86/include/asm/domain.h +++ b/xen/arch/x86/include/asm/domain.h @@ -654,9 +654,6 @@ struct arch_vcpu * it explicitly enables it via xcr0. */ uint64_t xcr0_accum; - /* This variable determines whether nonlazy extended state has been used, - * and thus should be saved/restored. */ - bool nonlazy_xstate_used; /* Restore all FPU state (lazy and non-lazy state) on context switch? */ bool fully_eager_fpu; diff --git a/xen/arch/x86/include/asm/hvm/svm/nestedsvm.h b/xen/arch/x86/include/asm/hvm/svm/nestedsvm.h index 406fc082b107..2f84546d6b3d 100644 --- a/xen/arch/x86/include/asm/hvm/svm/nestedsvm.h +++ b/xen/arch/x86/include/asm/hvm/svm/nestedsvm.h @@ -40,9 +40,6 @@ struct nestedsvm { /* Shadow io permission map */ unsigned long *ns_iomap; - uint64_t ns_cr0; /* Cached guest_cr[0] of l1 guest while l2 guest runs. - * Needed to handle FPU context switching */ - /* Cache guest cr3/host cr3 the guest sets up for the l2 guest. * Used by Shadow-on-Shadow and Nested-on-Nested. * ns_vmcb_guestcr3: in l2 guest physical address space and points to diff --git a/xen/arch/x86/include/asm/hvm/vmx/vmcs.h b/xen/arch/x86/include/asm/hvm/vmx/vmcs.h index a7dd2eeffcad..d84195c0426f 100644 --- a/xen/arch/x86/include/asm/hvm/vmx/vmcs.h +++ b/xen/arch/x86/include/asm/hvm/vmx/vmcs.h @@ -141,8 +141,6 @@ struct vmx_vcpu { DECLARE_BITMAP(eoi_exit_bitmap, X86_NR_VECTORS); struct pi_desc pi_desc; - unsigned long host_cr0; - /* Do we need to tolerate a spurious EPT_MISCONFIG VM exit? */ bool ept_spurious_misconfig; diff --git a/xen/arch/x86/include/asm/i387.h b/xen/arch/x86/include/asm/i387.h index a783549db991..bba5dfe3951a 100644 --- a/xen/arch/x86/include/asm/i387.h +++ b/xen/arch/x86/include/asm/i387.h @@ -27,8 +27,7 @@ struct ix87_env { uint16_t fds, _res6; }; -void vcpu_restore_fpu_nonlazy(struct vcpu *v, bool need_stts); -void vcpu_restore_fpu_lazy(struct vcpu *v); +void vcpu_restore_fpu(struct vcpu *v); void vcpu_save_fpu(struct vcpu *v); void save_fpu_enable(void); diff --git a/xen/arch/x86/include/asm/xstate.h b/xen/arch/x86/include/asm/xstate.h index bd767d9cd714..eed40c94efea 100644 --- a/xen/arch/x86/include/asm/xstate.h +++ b/xen/arch/x86/include/asm/xstate.h @@ -32,11 +32,10 @@ extern uint32_t mxcsr_mask; #define XSTATE_FP_SSE (X86_XCR0_FP | X86_XCR0_SSE) #define XCNTXT_MASK (X86_XCR0_FP | X86_XCR0_SSE | X86_XCR0_YMM | \ X86_XCR0_OPMASK | X86_XCR0_ZMM | X86_XCR0_HI_ZMM | \ - XSTATE_NONLAZY) + X86_XCR0_LWP | X86_XCR0_BNDREGS | X86_XCR0_BNDCSR | \ + X86_XCR0_PKRU) #define XSTATE_ALL (~(1ULL << 63)) -#define XSTATE_NONLAZY (X86_XCR0_BNDREGS | X86_XCR0_BNDCSR | X86_XCR0_PKRU) -#define XSTATE_LAZY (XSTATE_ALL & ~XSTATE_NONLAZY) #define XSTATE_XSAVES_ONLY 0 #define XSTATE_COMPACTION_ENABLED (1ULL << 63) @@ -121,18 +120,6 @@ static inline uint64_t xgetbv(unsigned int index) return lo | ((uint64_t)hi << 32); } -static inline bool xstate_all(const struct vcpu *v) -{ - /* - * XSTATE_FP_SSE may be excluded, because the offsets of XSTATE_FP_SSE - * (in the legacy region of xsave area) are fixed, so saving - * XSTATE_FP_SSE will not cause overwriting problem with XSAVES/XSAVEC. - */ - return (v->arch.xsave_area->xsave_hdr.xcomp_bv & - XSTATE_COMPACTION_ENABLED) && - (v->arch.xcr0_accum & XSTATE_LAZY & ~XSTATE_FP_SSE); -} - static inline bool __nonnull(1) xsave_area_compressed(const struct xsave_struct *xsave_area) { diff --git a/xen/arch/x86/pv/misc-hypercalls.c b/xen/arch/x86/pv/misc-hypercalls.c index b529f00ea127..dd783e34b117 100644 --- a/xen/arch/x86/pv/misc-hypercalls.c +++ b/xen/arch/x86/pv/misc-hypercalls.c @@ -40,8 +40,7 @@ long do_fpu_taskswitch(int set) else { v->arch.pv.ctrlreg[0] &= ~X86_CR0_TS; - if ( v->fpu_dirtied ) - clts(); + clts(); } return 0; diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c index d554c9d41edd..448a4073f589 100644 --- a/xen/arch/x86/traps.c +++ b/xen/arch/x86/traps.c @@ -1891,15 +1891,17 @@ void asmlinkage do_device_not_available(struct cpu_user_regs *regs) } #ifdef CONFIG_PV - vcpu_restore_fpu_lazy(curr); + BUG_ON(!(curr->arch.pv.ctrlreg[0] & X86_CR0_TS)); - if ( curr->arch.pv.ctrlreg[0] & X86_CR0_TS ) - { - pv_inject_hw_exception(X86_EXC_NM, X86_EVENT_NO_EC); - curr->arch.pv.ctrlreg[0] &= ~X86_CR0_TS; - } - else - TRACE_0D(TRC_PV_MATH_STATE_RESTORE); + /* + * PV ABI QUIRK: Classic Xen kernels (2.6.18 and SLES 11 SP4's + * 3.0) rely on Xen to clear TS. PVOPS kernels (3.0, 3.16 and 4.15 + * are checked) always clear TS themselves. + */ + clts(); + + pv_inject_hw_exception(X86_EXC_NM, X86_EVENT_NO_EC); + curr->arch.pv.ctrlreg[0] &= ~X86_CR0_TS; #else ASSERT_UNREACHABLE(); #endif diff --git a/xen/arch/x86/xstate.c b/xen/arch/x86/xstate.c index 92a65bd8d52c..19de2d570220 100644 --- a/xen/arch/x86/xstate.c +++ b/xen/arch/x86/xstate.c @@ -731,7 +731,6 @@ int handle_xsetbv(u32 index, u64 new_bv) { struct vcpu *curr = current; uint64_t xcr0_max = cpu_policy_xcr0_max(curr->domain->arch.cpuid); - u64 mask; if ( index != XCR_XFEATURE_ENABLED_MASK ) return -EOPNOTSUPP; @@ -766,34 +765,9 @@ int handle_xsetbv(u32 index, u64 new_bv) return -EFAULT; } - mask = new_bv & ~curr->arch.xcr0_accum; curr->arch.xcr0 = new_bv; curr->arch.xcr0_accum |= new_bv; - if ( new_bv & XSTATE_NONLAZY ) - curr->arch.nonlazy_xstate_used = 1; - - mask &= curr->fpu_dirtied ? ~XSTATE_FP_SSE : XSTATE_NONLAZY; - if ( mask ) - { - unsigned long cr0 = read_cr0(); - - clts(); - if ( curr->fpu_dirtied ) - asm ( "stmxcsr %0" : "=m" (curr->arch.xsave_area->fpu_sse.mxcsr) ); - else if ( xstate_all(curr) ) - { - /* See the comment in i387.c:vcpu_restore_fpu_eager(). */ - mask |= XSTATE_LAZY; - curr->fpu_initialised = 1; - curr->fpu_dirtied = 1; - cr0 &= ~X86_CR0_TS; - } - xrstor(curr, mask); - if ( cr0 & X86_CR0_TS ) - write_cr0(cr0); - } - return 0; } diff --git a/xen/common/domain.c b/xen/common/domain.c index f6f557499660..450a7cf1814a 100644 --- a/xen/common/domain.c +++ b/xen/common/domain.c @@ -1488,8 +1488,6 @@ int vcpu_reset(struct vcpu *v) clear_bit(v->vcpu_id, d->poll_mask); v->poll_evtchn = 0; - v->fpu_initialised = 0; - v->fpu_dirtied = 0; v->is_initialised = 0; if ( v->affinity_broken & VCPU_AFFINITY_OVERRIDE ) vcpu_temporary_affinity(v, NR_CPUS, VCPU_AFFINITY_OVERRIDE); diff --git a/xen/common/efi/runtime.c b/xen/common/efi/runtime.c index d952c3ba785e..273c03d676f8 100644 --- a/xen/common/efi/runtime.c +++ b/xen/common/efi/runtime.c @@ -85,12 +85,14 @@ struct efi_rs_state efi_rs_enter(void) static const u16 fcw = FCW_DEFAULT; static const u32 mxcsr = MXCSR_DEFAULT; struct efi_rs_state state = { .cr3 = 0 }; + struct vcpu *curr = current; if ( mfn_eq(efi_l4_mfn, INVALID_MFN) ) return state; state.cr3 = read_cr3(); - save_fpu_enable(); + if ( !is_idle_vcpu(curr) ) + vcpu_save_fpu(curr); asm volatile ( "fnclex; fldcw %0" :: "m" (fcw) ); asm volatile ( "ldmxcsr %0" :: "m" (mxcsr) ); @@ -101,7 +103,7 @@ struct efi_rs_state efi_rs_enter(void) /* prevent fixup_page_fault() from doing anything */ irq_enter(); - if ( is_pv_vcpu(current) && !is_idle_vcpu(current) ) + if ( is_pv_vcpu(curr) && !is_idle_vcpu(curr) ) { struct desc_ptr gdt_desc = { .limit = LAST_RESERVED_GDT_BYTE, @@ -153,7 +155,8 @@ void efi_rs_leave(struct efi_rs_state *state) irq_exit(); efi_rs_on_cpu = NR_CPUS; spin_unlock(&efi_rs_lock); - vcpu_restore_fpu_nonlazy(curr, true); + if ( !is_idle_vcpu(curr) ) + vcpu_restore_fpu(curr); } bool efi_rs_using_pgtables(void) diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h index 37f5922f3206..1da52e77dcdf 100644 --- a/xen/include/xen/sched.h +++ b/xen/include/xen/sched.h @@ -206,10 +206,6 @@ struct vcpu struct guest_area runstate_guest_area; unsigned int new_state; - /* Has the FPU been initialised? */ - bool fpu_initialised; - /* Has the FPU been used since it was last saved? */ - bool fpu_dirtied; /* Initialization completed for this VCPU? */ bool is_initialised; /* Currently running on a CPU? */ -- 2.42.0 From xen-devel-bounces@lists.xenproject.org Mon Mar 04 09:23:17 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 09:23:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688228.1072186 (Exim 4.92) (envelope-from ) id 1rh4XT-00037D-D7; Mon, 04 Mar 2024 09:23:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688228.1072186; Mon, 04 Mar 2024 09:23:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh4XT-00035g-8E; Mon, 04 Mar 2024 09:23:15 +0000 Received: by outflank-mailman (input) for mailman id 688228; Mon, 04 Mar 2024 09:23:13 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh4XR-0002pl-CR for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 09:23:13 +0000 Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [2a00:1450:4864:20::632]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id d177b03e-da08-11ee-a1ee-f123f15fe8a2; Mon, 04 Mar 2024 10:23:10 +0100 (CET) Received: by mail-ej1-x632.google.com with SMTP id a640c23a62f3a-a44d084bfe1so214999166b.1 for ; Mon, 04 Mar 2024 01:23:11 -0800 (PST) Received: from fhilly.citrite.net (default-46-102-197-194.interdsl.co.uk. [46.102.197.194]) by smtp.gmail.com with ESMTPSA id tj10-20020a170907c24a00b00a444526962asm4485529ejc.128.2024.03.04.01.23.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Mar 2024 01:23:09 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d177b03e-da08-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1709544190; x=1710148990; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=t8576Vz0UPo+rS38MVUiaswDJj20EFHOADQjBzvq4J4=; b=CPUwA8qQ93q1gT7CmMkdRFM4uQiNAY8URrf7QA8i0/6TYzLESo0DmPGaLIaEVKr8pc yousL2+uV866bx9YNR7kxzOQ95QpalI0gKu434mGS3RI6O6fiMYkt12Tzh7ovKkAN9jW M0lDPybxKeA43jyBZChsJaF6KiKacPiO4XlDA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709544190; x=1710148990; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=t8576Vz0UPo+rS38MVUiaswDJj20EFHOADQjBzvq4J4=; b=lvYm2TPhIOnHHfWS+7U/2avHgwxB9NekWSlHHqPh3xCDlGjht3zU5tqdB6zLVYXO8e krQyieaWebfeOPxoZwh08DpiMiMqTOm1EuGsA4Fr6aWqGOI19r904as0806+hQ3opxch iOzaY10nKg0y/PCVDoGQHJUISJm4J4A6a4eZ090eQRzLKqXMzXNrd/WXc5s1Bad7H3p/ snBeF14Dp5r5fzgD6xTf3Z8WI5Bm8U/LI14POpe5RKVbxCZCKWgebL9dtEB2uVCHOk+v shkfKxQG2M+M95ewcf4rysUKcaDuRsLn099vXAOnaNc0CsS7Fk9mjXS4bLtfqJjSHtqn 4c3A== X-Gm-Message-State: AOJu0YwCpZmaPPznIcW3gVDRNNNd4PzqEXUx1a4CzsNFvMHSXw/1L2N1 RIQ7bq2IynLriNp5kHdcnZLxzu1UR29rXF7F6m2O4uj28iSP2aIjL8NanounCpshZyKZvB2E5rf 5hZQ= X-Google-Smtp-Source: AGHT+IE42eCZ6CjhAvzdETjVqdy8/jVPKO6w3yWfhfb1zLFXH9r02iHSEC9lZXhHAto+j08lEc2Dhg== X-Received: by 2002:a17:906:685:b0:a44:fe70:1b82 with SMTP id u5-20020a170906068500b00a44fe701b82mr2645062ejb.8.1709544190552; Mon, 04 Mar 2024 01:23:10 -0800 (PST) From: Fouad Hilly To: Xen-devel Cc: Wei Liu , Fouad Hilly , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Wei Liu Subject: [PATCH 2/3] x86: introduce xstate_zero Date: Mon, 4 Mar 2024 09:13:06 +0000 Message-ID: <20240304091307.2295344-3-fouad.hilly@cloud.com> X-Mailer: git-send-email 2.42.0 In-Reply-To: <20240304091307.2295344-1-fouad.hilly@cloud.com> References: <20240304091307.2295344-1-fouad.hilly@cloud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Wei Liu Factor out xrstor__ and introduce xstate_zero, which zeros all the state components specified in the mask. Signed-off-by: Wei Liu Signed-off-by: Fouad Hilly --- CC: Jan Beulich CC: Andrew Cooper CC: "Roger Pau Monné" CC: Wei Liu --- xen/arch/x86/include/asm/xstate.h | 1 + xen/arch/x86/xstate.c | 39 +++++++++++++++++++++++++------ 2 files changed, 33 insertions(+), 7 deletions(-) diff --git a/xen/arch/x86/include/asm/xstate.h b/xen/arch/x86/include/asm/xstate.h index c08c267884f0..bd767d9cd714 100644 --- a/xen/arch/x86/include/asm/xstate.h +++ b/xen/arch/x86/include/asm/xstate.h @@ -94,6 +94,7 @@ uint64_t get_msr_xss(void); uint64_t read_bndcfgu(void); void xsave(struct vcpu *v, uint64_t mask); void xrstor(struct vcpu *v, uint64_t mask); +void xstate_zero(uint64_t mask); void xstate_set_init(uint64_t mask); bool xsave_enabled(const struct vcpu *v); int __must_check validate_xstate(const struct domain *d, diff --git a/xen/arch/x86/xstate.c b/xen/arch/x86/xstate.c index cf94761d0542..92a65bd8d52c 100644 --- a/xen/arch/x86/xstate.c +++ b/xen/arch/x86/xstate.c @@ -368,11 +368,12 @@ void xsave(struct vcpu *v, uint64_t mask) ptr->fpu_sse.x[FPU_WORD_SIZE_OFFSET] = fip_width; } -void xrstor(struct vcpu *v, uint64_t mask) +/* True -> no error, false -> failed */ +static bool xrstor__(struct xsave_struct *ptr, uint64_t xcr0_accum, + uint64_t mask) { uint32_t hmask = mask >> 32; uint32_t lmask = mask; - struct xsave_struct *ptr = v->arch.xsave_area; unsigned int faults, prev_faults; /* @@ -412,7 +413,7 @@ void xrstor(struct vcpu *v, uint64_t mask) [ptr] "D" (ptr) ) #define XRSTOR(pfx) \ - if ( v->arch.xcr0_accum & XSTATE_XSAVES_ONLY ) \ + if ( xcr0_accum & XSTATE_XSAVES_ONLY ) \ { \ if ( unlikely(!(ptr->xsave_hdr.xcomp_bv & \ XSTATE_COMPACTION_ENABLED)) ) \ @@ -461,7 +462,7 @@ void xrstor(struct vcpu *v, uint64_t mask) ((mask & X86_XCR0_YMM) && !(ptr->xsave_hdr.xcomp_bv & XSTATE_COMPACTION_ENABLED))) ) ptr->fpu_sse.mxcsr &= mxcsr_mask; - if ( v->arch.xcr0_accum & XSTATE_XSAVES_ONLY ) + if ( xcr0_accum & XSTATE_XSAVES_ONLY ) { ptr->xsave_hdr.xcomp_bv &= this_cpu(xcr0) | this_cpu(xss); ptr->xsave_hdr.xstate_bv &= ptr->xsave_hdr.xcomp_bv; @@ -478,14 +479,35 @@ void xrstor(struct vcpu *v, uint64_t mask) case 2: /* Stage 2: Reset all state. */ ptr->fpu_sse.mxcsr = MXCSR_DEFAULT; ptr->xsave_hdr.xstate_bv = 0; - ptr->xsave_hdr.xcomp_bv = v->arch.xcr0_accum & XSTATE_XSAVES_ONLY + ptr->xsave_hdr.xcomp_bv = xcr0_accum & XSTATE_XSAVES_ONLY ? XSTATE_COMPACTION_ENABLED : 0; continue; } - domain_crash(current->domain); - return; + return false; } + + return true; +} + +void xrstor(struct vcpu *v, uint64_t mask) +{ + if ( !xrstor__(v->arch.xsave_area, v->arch.xcr0_accum, mask) ) + domain_crash(current->domain); +} + +void xstate_zero(uint64_t mask) +{ + bool ok; + struct xsave_struct tmp; + + tmp.fpu_sse.mxcsr = MXCSR_DEFAULT; + tmp.xsave_hdr.xstate_bv = 0; + tmp.xsave_hdr.xcomp_bv = 0; + memset(tmp.xsave_hdr.reserved, 0, sizeof(tmp.xsave_hdr.reserved)); + + ok = xrstor__(&tmp, mask, mask); + ASSERT(ok); } bool xsave_enabled(const struct vcpu *v) @@ -731,6 +753,9 @@ int handle_xsetbv(u32 index, u64 new_bv) if ( (new_bv & ~xcr0_max) || !valid_xcr0(new_bv) ) return -EINVAL; + /* Zero state components before writing new XCR0 */ + xstate_zero(get_xcr0()); + /* By this point, new_bv really should be accepted by hardware. */ if ( unlikely(!set_xcr0(new_bv)) ) { -- 2.42.0 From xen-devel-bounces@lists.xenproject.org Mon Mar 04 09:23:17 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 09:23:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688227.1072181 (Exim 4.92) (envelope-from ) id 1rh4XT-00034I-4Y; Mon, 04 Mar 2024 09:23:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688227.1072181; Mon, 04 Mar 2024 09:23:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh4XT-00034A-0p; Mon, 04 Mar 2024 09:23:15 +0000 Received: by outflank-mailman (input) for mailman id 688227; Mon, 04 Mar 2024 09:23:13 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh4XR-0002pl-5e for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 09:23:13 +0000 Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [2a00:1450:4864:20::62e]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id d0de529d-da08-11ee-a1ee-f123f15fe8a2; Mon, 04 Mar 2024 10:23:09 +0100 (CET) Received: by mail-ej1-x62e.google.com with SMTP id a640c23a62f3a-a44f2d894b7so159549266b.1 for ; Mon, 04 Mar 2024 01:23:10 -0800 (PST) Received: from fhilly.citrite.net (default-46-102-197-194.interdsl.co.uk. [46.102.197.194]) by smtp.gmail.com with ESMTPSA id tj10-20020a170907c24a00b00a444526962asm4485529ejc.128.2024.03.04.01.23.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Mar 2024 01:23:08 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d0de529d-da08-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1709544189; x=1710148989; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=ccAwOwOdhjjKU5vrkhjFv38qxkICvc3DaQURqNSfmho=; b=I5HAVRVbMOTNceOHmkEz6iBdl5UcJ+ywLU8ekcKVFjVwfasZqXA4BIJZzQdgl3tqAv 4AbDg0eqMGbNsyMpSkwudeugNpJvQnkV2Do9lFsEPTYu/d+92CaFqQWzsSfE1tZl+XZQ JZ8OKqc3SRfMxXcZ4BzypRH0T2+fNHeRKxyeY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709544189; x=1710148989; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ccAwOwOdhjjKU5vrkhjFv38qxkICvc3DaQURqNSfmho=; b=sn/T6/KlKIRsWmzf2sTF6bcK3hEgygAG8mDj7LVnG6qiN3iqBsgNM9qGM09hDuqQDI pZIG3xRgOtL/2CkMgMu1n+A7T6SK/w7sWtP1WKz2ZQvlq11hkGAwpARQnFP9QYQFWVg3 Uiy0tOLQzc4OtYtuvpWqGefyRcO2FDNOzqs9NR3cYMO81d0WNBU4ekLP6TjtJfhp7efB Lro1c6nMnS2Cny/zpsYf0zjzd9ycymlieQWKrd0V2yAWd6so6bhVLaHIBD8LAZl3DEYx JlctpKSOwabKzbTdaGIYXo7Xhs3DEZ4lhmW379YbOP1Z5UTU3qbCj9cHdtcTI3NJ3boJ xxig== X-Gm-Message-State: AOJu0YzUu9y2JhXT8sfvqEzuGCwBrFs7FGVQWxBk/9lCxR5dBkMndYQH ZVnN5Bzpa2TQLHamT/9m74Y9GUaiSFhpc0LrkcC2/5bVPcfJ+UnmzlOpabPsMNcCMKTy9B2md2Q EXYM= X-Google-Smtp-Source: AGHT+IFpVknCnBeGMT58GJNWesqTQw1OSRo9PDozkmsZZ3Qk9gRuJnRSh1A0qB4Ng6ODltK6luEauw== X-Received: by 2002:a17:906:cd03:b0:a44:511d:630b with SMTP id oz3-20020a170906cd0300b00a44511d630bmr5560629ejb.24.1709544188840; Mon, 04 Mar 2024 01:23:08 -0800 (PST) From: Fouad Hilly To: Xen-devel Cc: Wei Liu , Fouad Hilly , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Wei Liu Subject: [PATCH 1/3] x86: i387.c cleanup Date: Mon, 4 Mar 2024 09:13:05 +0000 Message-ID: <20240304091307.2295344-2-fouad.hilly@cloud.com> X-Mailer: git-send-email 2.42.0 In-Reply-To: <20240304091307.2295344-1-fouad.hilly@cloud.com> References: <20240304091307.2295344-1-fouad.hilly@cloud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Wei Liu No functional change Signed-off-by: Wei Liu Signed-off-by: Fouad Hilly --- CC: Jan Beulich CC: Andrew Cooper CC: "Roger Pau Monné" CC: Wei Liu --- xen/arch/x86/i387.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/xen/arch/x86/i387.c b/xen/arch/x86/i387.c index d824f2bb5294..7a4297cc921e 100644 --- a/xen/arch/x86/i387.c +++ b/xen/arch/x86/i387.c @@ -26,7 +26,7 @@ static inline void fpu_xrstor(struct vcpu *v, uint64_t mask) ASSERT(v->arch.xsave_area); /* - * XCR0 normally represents what guest OS set. In case of Xen itself, + * XCR0 normally represents what guest OS set. In case of Xen itself, * we set the accumulated feature mask before doing save/restore. */ ok = set_xcr0(v->arch.xcr0_accum | XSTATE_FP_SSE); @@ -36,7 +36,7 @@ static inline void fpu_xrstor(struct vcpu *v, uint64_t mask) ASSERT(ok); } -/* Restor x87 FPU, MMX, SSE and SSE2 state */ +/* Restore x87 FPU, MMX, SSE and SSE2 state */ static inline void fpu_fxrstor(struct vcpu *v) { const typeof(v->arch.xsave_area->fpu_sse) *fpu_ctxt = v->arch.fpu_ctxt; @@ -307,7 +307,7 @@ void save_fpu_enable(void) int vcpu_init_fpu(struct vcpu *v) { int rc; - + v->arch.fully_eager_fpu = opt_eager_fpu; if ( (rc = xstate_alloc_save_area(v)) != 0 ) -- 2.42.0 From xen-devel-bounces@lists.xenproject.org Mon Mar 04 09:23:17 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 09:23:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688226.1072171 (Exim 4.92) (envelope-from ) id 1rh4XQ-0002pv-T3; Mon, 04 Mar 2024 09:23:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688226.1072171; Mon, 04 Mar 2024 09:23:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh4XQ-0002po-Pu; Mon, 04 Mar 2024 09:23:12 +0000 Received: by outflank-mailman (input) for mailman id 688226; Mon, 04 Mar 2024 09:23:11 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh4XP-0002pf-2v for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 09:23:11 +0000 Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [2a00:1450:4864:20::635]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id d1020d8f-da08-11ee-afda-a90da7624cb6; Mon, 04 Mar 2024 10:23:09 +0100 (CET) Received: by mail-ej1-x635.google.com with SMTP id a640c23a62f3a-a44665605f3so442841566b.2 for ; Mon, 04 Mar 2024 01:23:09 -0800 (PST) Received: from fhilly.citrite.net (default-46-102-197-194.interdsl.co.uk. [46.102.197.194]) by smtp.gmail.com with ESMTPSA id tj10-20020a170907c24a00b00a444526962asm4485529ejc.128.2024.03.04.01.23.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Mar 2024 01:23:08 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d1020d8f-da08-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1709544188; x=1710148988; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=o0ewBdo6BsfAu1040fP9UTBBK6xWae8Y+hi5LU8havE=; b=Gnrh8cAEUAUwwTWE7ZbwZ8fVcA6YMVBWavMVqOOG1k8YbSR8XM/DZbAHwJn3+BpPQu 57B8yJnlFQslINOJyR7zob8ctfNzowLitAubZy+c/j9vSY2V21iRpgB0JkBcaRmp9abj zhdJlqTOlgUspwNbgN0F7ANVccmvfYDpUPrBw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709544188; x=1710148988; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=o0ewBdo6BsfAu1040fP9UTBBK6xWae8Y+hi5LU8havE=; b=w1Ol6R709t8z7tyLDyvOq91dR0iwslxJMoivnVZiIPXRtBVpzhfWKjoRmkdLUo7kJ5 Fz+yUHi0ghu4rgqUPBwsNTo6hfs3cGD1I95BS+e2kSHhFPLlr4MEfZi+a0Ondp3xCUV9 CeWIs28lmN4SQY8Wen3Gb3THd2qQHJ1fvDZq1ohSBC4tn2YQjVS7hjqHGesVhzzt0TaH 0QuCsy5utSgDZ5cDG1Jk7v75J8FWA7ANfVrjPENhOQ0TkSzcQDpapne7iYiVfI7xEdzU Jcz/92NOkXQ1YTCTU6D8c96ZEQ6VsMGhPQXsy9SWvQir9iyxPQl+sbnLDdk7py2YHSFY ODiA== X-Gm-Message-State: AOJu0Yz6+Wg+GUVOfDm+dqs24oZAVxvwHwPgTsTB1VoBnut/VrA42hUX yUJjggNDr4zjtx/Ocoafjz4K0fAzBLDxJTyhi+GpXqM4R1cs3IwvuddZiajZzDAXS+IH76Vm6Ai /Jdg= X-Google-Smtp-Source: AGHT+IFPfluwiGoetkbsjHf5zwBeO9ZF6E4qDYdlBdWZFuWv+0qr71+F0BkI6MfGY9QS1Jc54mkuEg== X-Received: by 2002:a17:907:11c1:b0:a44:790d:6a with SMTP id va1-20020a17090711c100b00a44790d006amr5716989ejb.4.1709544188293; Mon, 04 Mar 2024 01:23:08 -0800 (PST) From: Fouad Hilly To: Xen-devel Cc: Fouad Hilly , Wei Liu , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jan Beulich , Andrew Cooper , Wei Liu , George Dunlap , Julien Grall , Stefano Stabellini , Paul Durrant , Jun Nakajima , Kevin Tian Subject: [PATCH 0/3] X86/eager-fpu: Switch to eager fpu save/restore Date: Mon, 4 Mar 2024 09:13:04 +0000 Message-ID: <20240304091307.2295344-1-fouad.hilly@cloud.com> X-Mailer: git-send-email 2.42.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X86 Xen will only eagerly switch FPU context in the scheduler. Xen itslef won't set CR0.TS other than for the purpose of servicing a PV guset. Signed-off-by: Wei Liu Signed-off-by: Roger Pau Monné Signed-off-by: Fouad Hilly --- CC: Jan Beulich CC: Andrew Cooper CC: "Roger Pau Monné" CC: Wei Liu CC: George Dunlap CC: Julien Grall CC: Stefano Stabellini CC: Paul Durrant CC: Jun Nakajima CC: Kevin Tian Wei Liu (3): x86: i387.c cleanup x86: introduce xstate_zero x86: switch to eager fpu save / restore xen/arch/x86/cpu/common.c | 3 - xen/arch/x86/domain.c | 10 +- xen/arch/x86/domctl.c | 4 +- xen/arch/x86/hvm/emulate.c | 38 +---- xen/arch/x86/hvm/hvm.c | 8 +- xen/arch/x86/hvm/svm/nestedsvm.c | 62 +------ xen/arch/x86/hvm/svm/svm.c | 81 +-------- xen/arch/x86/hvm/svm/vmcb.c | 4 +- xen/arch/x86/hvm/vlapic.c | 4 - xen/arch/x86/hvm/vmx/vmcs.c | 8 +- xen/arch/x86/hvm/vmx/vmx.c | 70 +------- xen/arch/x86/hvm/vmx/vvmx.c | 15 +- xen/arch/x86/i387.c | 170 +++++-------------- xen/arch/x86/include/asm/domain.h | 3 - xen/arch/x86/include/asm/hvm/svm/nestedsvm.h | 3 - xen/arch/x86/include/asm/hvm/vmx/vmcs.h | 2 - xen/arch/x86/include/asm/i387.h | 3 +- xen/arch/x86/include/asm/xstate.h | 18 +- xen/arch/x86/pv/misc-hypercalls.c | 3 +- xen/arch/x86/traps.c | 18 +- xen/arch/x86/xstate.c | 65 ++++--- xen/common/domain.c | 2 - xen/common/efi/runtime.c | 9 +- xen/include/xen/sched.h | 4 - 24 files changed, 108 insertions(+), 499 deletions(-) -- 2.42.0 From xen-devel-bounces@lists.xenproject.org Mon Mar 04 09:27:49 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 09:27:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688235.1072210 (Exim 4.92) (envelope-from ) id 1rh4bq-00052S-HC; Mon, 04 Mar 2024 09:27:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688235.1072210; Mon, 04 Mar 2024 09:27:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh4bq-00052L-Ei; Mon, 04 Mar 2024 09:27:46 +0000 Received: by outflank-mailman (input) for mailman id 688235; Mon, 04 Mar 2024 09:27:45 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh4bp-00052F-ND for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 09:27:45 +0000 Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [2a00:1450:4864:20::62b]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 74ea1c0c-da09-11ee-afda-a90da7624cb6; Mon, 04 Mar 2024 10:27:44 +0100 (CET) Received: by mail-ej1-x62b.google.com with SMTP id a640c23a62f3a-a293f2280c7so748424866b.1 for ; Mon, 04 Mar 2024 01:27:44 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ty24-20020a170907c71800b00a42eb84c7c2sm4614928ejc.142.2024.03.04.01.27.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Mar 2024 01:27:43 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 74ea1c0c-da09-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709544464; x=1710149264; darn=lists.xenproject.org; h=content-transfer-encoding:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to; bh=9d6dkSNgHqXCPZ0f9CEpi9l3GKkSecj76fgrhfhUdqs=; b=dbCN7b2K8vMEpp/4hB6TB4IGTooh8b+xeuNS24qyd/ZTgMLLoqTHziiPBf4mVZSJ09 yz7prK9zva45VFiIuEysGa08GzBkvfDo8o0zKXJt0pYZmFvIIhQyt8biQm+DwtSvYLtF RN7p5VG+Mams0yhWCFqBYS7EMauXbQu2vD61j0dMqw6fH+Ns4erQQnaunXfqm7l9X4+J 8ecA/fwAM3xxj4QA+O4kQKqRAiL5N3WX7vB0MbyS8N6gLF8FyynBgmtFXMxhd8rE2cck n2PTMjUdP/ymy8HZ0vBpAwj4MxUvyT+Nb80Uad0k9NHQcbSCXYebjiIqXx3kf+hfqs3Y JsVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709544464; x=1710149264; h=content-transfer-encoding:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=9d6dkSNgHqXCPZ0f9CEpi9l3GKkSecj76fgrhfhUdqs=; b=lWGDH2ObWECb+BINo57rh2FOeWX4Od0gzRH7cN9xi8w92OXCKj9yGd9YnWMaopA+Xw lpQIPjqMgFPgJYDOcRuq6QbvpnYuDl8RKOXCyqrmOS1NQM3m8vngQr8q4gj4saVzeAv6 IXvJ8dQCnp/KLkiIiCPv1WbPXI2KbAB167qM5zmDjGvuBCggB/ZJrDDff27tXK9oCcn4 9M2EcM2iJ43xi2n61JaZa22JvXk87Ghn4acjOOtqm8eoqbBx8xGdsxxKRA+6MPSyBDgt iGjVpb5aY4urUotDujTXV5JHG0i7Xjetu2YlFJ10dOulH8xNahFDrFvEQYwqlk1CseVS 09Ig== X-Gm-Message-State: AOJu0YwNdCYcja7+mgzjMSTmF3KHpmymjFdqR9LdU3v8F/8x0uc4eQHX kcr19FI3cqBRxfUu4FTOA0T/wI5hHg9PGjiX1+GcbylCckXJ7kAWdgASL5sFZbFgjqSSZOuGRb0 = X-Google-Smtp-Source: AGHT+IEzfpawoAp3uAPLdCNBoMkSqkzjl6xbjWhog9MhQRqkvxZ4C2Z08Tx/GVBx7/cxRXJrRK8mQA== X-Received: by 2002:a17:906:3606:b0:a45:6d18:a80d with SMTP id q6-20020a170906360600b00a456d18a80dmr636686ejb.62.1709544464103; Mon, 04 Mar 2024 01:27:44 -0800 (PST) Message-ID: Date: Mon, 4 Mar 2024 10:27:44 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Kevin Tian , Jun Nakajima From: Jan Beulich Subject: [PATCH] MAINTAINERS: drop AMD SVM and Intel VT-x sections Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit We'd like to thank the VT-x maintainers for their past contributions, while at the same time we'd like to reflect reality as it has been for quite some time. Have VT-x maintainership (and for symmetry also AMD SVM's) fall back to general x86. Signed-off-by: Jan Beulich --- a/MAINTAINERS +++ b/MAINTAINERS @@ -220,13 +220,6 @@ M: Andrew Cooper -M: Andrew Cooper -S: Supported -F: xen/arch/x86/hvm/svm/ -F: xen/arch/x86/cpu/vpmu_amd.c - ARGO M: Christopher Clark S: Maintained @@ -357,15 +350,6 @@ M: Kevin Tian S: Supported F: xen/drivers/passthrough/vtd/ -INTEL(R) VT FOR X86 (VT-X) -M: Jun Nakajima -M: Kevin Tian -S: Supported -F: xen/arch/x86/cpu/vpmu_intel.c -F: xen/arch/x86/hvm/vmx/ -F: xen/arch/x86/include/asm/hvm/vmx/ -F: xen/arch/x86/mm/p2m-ept.c - IOMMU VENDOR INDEPENDENT CODE M: Jan Beulich M: Paul Durrant From xen-devel-bounces@lists.xenproject.org Mon Mar 04 09:39:21 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 09:39:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688242.1072222 (Exim 4.92) (envelope-from ) id 1rh4mo-0007Ns-Ii; Mon, 04 Mar 2024 09:39:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688242.1072222; Mon, 04 Mar 2024 09:39:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh4mo-0007Ni-EI; Mon, 04 Mar 2024 09:39:06 +0000 Received: by outflank-mailman (input) for mailman id 688242; Mon, 04 Mar 2024 09:39:06 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh4mo-0007Nb-0B for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 09:39:06 +0000 Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [2a00:1450:4864:20::630]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 09a4b81d-da0b-11ee-a1ee-f123f15fe8a2; Mon, 04 Mar 2024 10:39:03 +0100 (CET) Received: by mail-ej1-x630.google.com with SMTP id a640c23a62f3a-a293f2280c7so750319866b.1 for ; Mon, 04 Mar 2024 01:39:03 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id gq13-20020a170906e24d00b00a45621ded4bsm565362ejb.146.2024.03.04.01.39.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Mar 2024 01:39:03 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 09a4b81d-da0b-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709545143; x=1710149943; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=BYefA596srdPM8s5itzd8N/YwFI3FPSMmRtIyZ5Bl9w=; b=Ac7FNUTw/7//3xHqOO78H7d4WeJ47lFNU0jbNpRQ5+lVM5WV3yjoPuGI8UzUB6/G8M qrB7p1mdakdXEhB/Y83ckOjskh6oZM05AcbAEg/hdIG/3sRTkYrsz5z3OvW0kVsls7CE ATDnU9yPxNVIaXaF3emOInJowBcRIciib523VabCT14hxaIFmVyiv9jXf/c/PQhY/QDk HrXbqxxJUQ8Xge/qJ4cucLlv+ExeVaJkSecMUFjZojIl2z5RjKbCNrDhzpd3VsoagX21 kZi+sLL7wH/SXWyPR63EcopSXJS9V6Lm9R/vWYTiO/KLJTMobu0R4dqfGETX6AaSNThX Sp/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709545143; x=1710149943; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=BYefA596srdPM8s5itzd8N/YwFI3FPSMmRtIyZ5Bl9w=; b=b5hcXPz2IJnjsDYBqacOs/EW5pJnRpR7K/+lqqMHj3EwdU6TSB6wysQuNxpQMleakA fO2K/ZfVJc7Onajxw8J/ZUB+TgfIk4XS/0Yl9MjpvQBOsf57XLUnXqcxuH7pu44L2K10 jW83xJBlnGmfSB3xtyxMw6hpxb4Fgzm+u/Gw3HNNUQW3xwGdFbdF2WFWftTJTt4yi9Cg 2cxehsRd8Og65mCJhT+GYEc2VFlv1zDY0mHQ355XXrqf99nE3aOFaEisVRtd3Z9/dI9o DwYDgbaZ7L8Arj/cUPqQogWObpAnXj6TiyhI3QWEjJbZW3rU/OyXxtg23WYgPNxbAljR tmew== X-Forwarded-Encrypted: i=1; AJvYcCUlaikwGoAnxg22+J7z8BPUNK5cRQAG5G1/NpmNwI2UeaFuUPG4+1W/e5ewqzzVUqPeIvB0b6ftQRkMD7pXWye7fFe8kmIcqabUiG9XRAY= X-Gm-Message-State: AOJu0Yx2LBf4BiMJIAK3uEIz9mhdOWIjNkHioZm8TwGxr+gPNfyNv6yh QN74Sb1tj/6ojUIyJ3gy5E8+G4VrxIU9B3f0bBo+gZUZDMSMCnCD0LF5qcrN2w== X-Google-Smtp-Source: AGHT+IE+FP3KXfK9AwYeTUsq3uLVEidZc1AjJq+YVerYjwe5ZHJnSnmQDEFejGL9qpcONRE9BCydAg== X-Received: by 2002:a17:906:af42:b0:a44:4c8e:f167 with SMTP id ly2-20020a170906af4200b00a444c8ef167mr4856378ejb.69.1709545143246; Mon, 04 Mar 2024 01:39:03 -0800 (PST) Message-ID: Date: Mon, 4 Mar 2024 10:39:03 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH 08/10] xen/errno: address violations of MISRA C Rule 20.7 Content-Language: en-US To: Nicola Vetrini , xen-devel@lists.xenproject.org Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, consulting@bugseng.com, andrew.cooper3@citrix.com, roger.pau@citrix.com, bertrand.marquis@arm.com, julien@xen.org, George Dunlap , Wei Liu References: <92dbcd9e5aa2ab45c50f3f567ddece59108568ad.1709219010.git.nicola.vetrini@bugseng.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <92dbcd9e5aa2ab45c50f3f567ddece59108568ad.1709219010.git.nicola.vetrini@bugseng.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 29.02.2024 16:28, Nicola Vetrini wrote: > MISRA C Rule 20.7 states: "Expressions resulting from the expansion > of macro parameters shall be enclosed in parentheses". Therefore, some > macro definitions should gain additional parentheses to ensure that all > current and future users will be safe with respect to expansions that > can possibly alter the semantics of the passed-in macro parameter. > > No functional change. > > Signed-off-by: Nicola Vetrini Acked-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Mon Mar 04 09:50:48 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 09:50:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688245.1072231 (Exim 4.92) (envelope-from ) id 1rh4y3-0002D1-H6; Mon, 04 Mar 2024 09:50:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688245.1072231; Mon, 04 Mar 2024 09:50:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh4y3-0002Cu-EC; Mon, 04 Mar 2024 09:50:43 +0000 Received: by outflank-mailman (input) for mailman id 688245; Mon, 04 Mar 2024 09:50:42 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh4y2-0002Co-NI for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 09:50:42 +0000 Received: from mail-oi1-x230.google.com (mail-oi1-x230.google.com [2607:f8b0:4864:20::230]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id a89af9e7-da0c-11ee-a1ee-f123f15fe8a2; Mon, 04 Mar 2024 10:50:40 +0100 (CET) Received: by mail-oi1-x230.google.com with SMTP id 5614622812f47-3bbbc6e51d0so3249456b6e.3 for ; Mon, 04 Mar 2024 01:50:40 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a89af9e7-da0c-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1709545839; x=1710150639; darn=lists.xenproject.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=xoCcnB+gmyD3hwUM672Y7W5xCmiCuFgtmu6gmGhOhTA=; b=Td7CuKPHMhcCNNOPlz3FFPLaEe7eFzelXI8q9IAbCoidvDjfyP5HnpoVBIH+04n8QR pbzosGlK1uRgk17/+ys1X439dCZOSlCN4X+GjCxgntk9EubQ3cGj1zUuW4Lx0tlQ+MIx 9ygAoqrBwSAJInkrzXEF6p+h9KO/YnfK1TO4E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709545839; x=1710150639; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=xoCcnB+gmyD3hwUM672Y7W5xCmiCuFgtmu6gmGhOhTA=; b=I3HBLXjcRpU93vT4oOuNMoPZdTlnWFNDjGtIXt/e2Ia+x8i4khoSHdN4E8BJmieKJz D3eNGX6Dim8HOZNFpqdRABxdIcsPKQvv2ECUAMS8tXtI2Loaf1HdQP51NcNy4A7wOWt/ BV79bmpXJUpTMeblmCky2YsuhpjgESq1nzS1EQpmimE5L+NKnafkGE/2DBmlk5wOcMHq Z2BmfwiQB8IXxErAV9qqVH0EHgPknQ02g48aaoPtrIYt5+ZkxXUz0owvnV2OvjyL3kUW PM3uMG8BmnvQl32pLNNftUdV2MuteqfKD6/mCSjK/zHxz5Kgg4EHWk0mvBSLBXceK4dy IGww== X-Gm-Message-State: AOJu0YyEhW3lAkpugw6gK2S6uUmtChy0bp1DbuyuJ8pFsFz5hevRxFem U9/TMwnlx5gVQfe8IqHa/KqEypPPGQYmV8MAYjQRCGFW5WgIHEBsuMr0RLEDq+xRw88utZtSeyc lxIms6CUaFjePcB0Z75Dzl4Vqv1TwpaD5NzH9Rw== X-Google-Smtp-Source: AGHT+IFdbm1pMRxTI/HkbkS3IwdAs1NkcByz0qE4XuiZyzUF1+DgdSTKKQoKJyNGKyLTghLl9wZpSKqlzirGHDf3Qfk= X-Received: by 2002:a05:6870:ef86:b0:21e:be10:f39d with SMTP id qr6-20020a056870ef8600b0021ebe10f39dmr8723221oab.46.1709545839266; Mon, 04 Mar 2024 01:50:39 -0800 (PST) MIME-Version: 1.0 References: <20240206012051.3564035-1-george.dunlap@cloud.com> <20240206012051.3564035-6-george.dunlap@cloud.com> <03677752-2a39-4090-8d8b-12a82d82030d@citrix.com> In-Reply-To: <03677752-2a39-4090-8d8b-12a82d82030d@citrix.com> From: George Dunlap Date: Mon, 4 Mar 2024 17:50:28 +0800 Message-ID: Subject: Re: [PATCH 5/6] nestedsvm: Remove bogus debug message from nestedsvm_check_intercepts To: Andrew Cooper Cc: xen-devel@lists.xenproject.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Feb 27, 2024 at 12:47=E2=80=AFAM Andrew Cooper wrote: > > On 06/02/2024 1:20 am, George Dunlap wrote: > > Changeset ef3e8db8068 ("x86/hvm: Corrections and improvements to > > unhandled vmexit logging") introduced a printk to the default path of > > the switch statement in nestedsvm_check_intercepts(), complaining of > > an unknown exit reason. > > > > Unfortunately, the "core" switch statement which is meant to handle > > all vmexit reasons is in nsvm_vmcb_guest_intercepts_exitcode(); the > > switch statement in nestedsvm_check_intercepts() is only meant to > > superimpose on top of that some special-casing for how to interaction > > between L1 and L0 vmexits. > > > > Remove the printk, and add a comment to prevent future confusion. > > > > Signed-off-by: George Dunlap > > Erm... The addition of this printk was very deliberate, to point out > where security fixes are needed. > > It's not bogus in the slightest. It is an error for exit reasons to not > be inspected for safety in this path. I'm a bit at a loss how to respond to this. As I wrote above, exit reasons are inspected for safety in this path -- in nsvm_vmcb_guest_intercepts_exitcode(). If you want the patch reverted, you'll have to explain why that's not sufficient. -George From xen-devel-bounces@lists.xenproject.org Mon Mar 04 09:52:44 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 09:52:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688248.1072240 (Exim 4.92) (envelope-from ) id 1rh4zz-00031j-TS; Mon, 04 Mar 2024 09:52:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688248.1072240; Mon, 04 Mar 2024 09:52:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh4zz-00031c-Qj; Mon, 04 Mar 2024 09:52:43 +0000 Received: by outflank-mailman (input) for mailman id 688248; Mon, 04 Mar 2024 09:52:42 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh4zy-00031W-31 for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 09:52:42 +0000 Received: from mail-yw1-x1129.google.com (mail-yw1-x1129.google.com [2607:f8b0:4864:20::1129]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id efe647d3-da0c-11ee-a1ee-f123f15fe8a2; Mon, 04 Mar 2024 10:52:40 +0100 (CET) Received: by mail-yw1-x1129.google.com with SMTP id 00721157ae682-609acac53d0so6061117b3.1 for ; Mon, 04 Mar 2024 01:52:40 -0800 (PST) Received: from [192.168.1.10] (host-92-3-248-192.as13285.net. [92.3.248.192]) by smtp.gmail.com with ESMTPSA id wi9-20020a05620a570900b00787f02dd9bfsm4203337qkn.26.2024.03.04.01.52.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Mar 2024 01:52:37 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: efe647d3-da0c-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709545959; x=1710150759; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=rxmX3b++6Lr9XkFWUsjEXaUSvwWXP5VNxqnrW8adft8=; b=YGhsnlQQ0B83lFlrEgxjnjCLX0iukvCx9u/Ag1EuEsr8bc1L6vfCKSlyitDHrEQFr/ y91RGVv/Gn1eaJBp7wNq/o0eWIUJJqppR1eZ1wJQU2+/q/40UyK97d1w5HPvL4Uo06jU f8pvuTOS2A1sOX258lSJFXUuV5RdejFWIrzas= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709545959; x=1710150759; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=rxmX3b++6Lr9XkFWUsjEXaUSvwWXP5VNxqnrW8adft8=; b=BSz6gsbROi6TlEcrXfDyuAewGBSuMot1CgZpCYhkdkvzEJi+rYMDBPOEwvtKpJ9Itb 1PSh8Z1jl//CJM2UnFGX+Rs8ZROzwGrjVAw6cB4BxHDp+FbvqPp/v9cmw2maYLiEZtul U3Yu5y7A0yS5B/bd/NaKpq3eLWa3BXtQMbJ98CgA6X1SexTz+QfwQWTrLRtOK+wkioN9 L2dKTCn/rVetwdI7+GhP0zg0Q4+xb9dqh9m1TjpGQM/ILeq9DfeDvA4srA08fbQ8ff17 cZxbOSjwpZDOToOW4tMaOkn9nl9EJKaLwLjE6XOHXNVDBbayFUNmQYw4E0itPHDsuoo1 mklw== X-Forwarded-Encrypted: i=1; AJvYcCX32XhZVNWyc3Dcg2Of8c0jHTMRRs8S8AT5SpTUaZfv5XWb6e3XhkivOu70/qEYNlWVIn0gXVHxsCUM0FACQ2tqJavxEP/WnEoPtXNKgdM= X-Gm-Message-State: AOJu0YwmX5s1HGou/p8Pda3c30jjBoVEMP9KQ0d1s74R0c5b0qG16akI lfuc9eb/7bNWGDUuKXgKKIaiA1+Ms1iYbZ2lgvwCZIOVBdHSvj98Y160/rplF80= X-Google-Smtp-Source: AGHT+IHFCCBtcwwPHs6T+tKOUZ/qMs7yqDU1emh8Aji3TmonT04BHB0YpJq1QtTN1oOf4SPwLi/QFA== X-Received: by 2002:a0d:cb81:0:b0:607:e374:762e with SMTP id n123-20020a0dcb81000000b00607e374762emr9368554ywd.16.1709545958988; Mon, 04 Mar 2024 01:52:38 -0800 (PST) Message-ID: Date: Mon, 4 Mar 2024 09:52:35 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] MAINTAINERS: drop AMD SVM and Intel VT-x sections Content-Language: en-GB To: Jan Beulich , "xen-devel@lists.xenproject.org" Cc: Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Kevin Tian , Jun Nakajima References: From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 04/03/2024 9:27 am, Jan Beulich wrote: > We'd like to thank the VT-x maintainers for their past contributions, > while at the same time we'd like to reflect reality as it has been for > quite some time. Have VT-x maintainership (and for symmetry also AMD > SVM's) fall back to general x86. > > Signed-off-by: Jan Beulich Acked-by: Andrew Cooper From xen-devel-bounces@lists.xenproject.org Mon Mar 04 10:00:34 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 10:00:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688255.1072270 (Exim 4.92) (envelope-from ) id 1rh57S-0005gi-Oq; Mon, 04 Mar 2024 10:00:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688255.1072270; Mon, 04 Mar 2024 10:00:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh57S-0005gb-MB; Mon, 04 Mar 2024 10:00:26 +0000 Received: by outflank-mailman (input) for mailman id 688255; Mon, 04 Mar 2024 10:00:24 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh57Q-0005gN-Hm; Mon, 04 Mar 2024 10:00:24 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh57Q-00048G-Fs; Mon, 04 Mar 2024 10:00:24 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh57Q-0001cc-9A; Mon, 04 Mar 2024 10:00:24 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rh57Q-0003hV-8j; Mon, 04 Mar 2024 10:00:24 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=KhTB0Q8s157eefQfIAlgdO0QZNKRb5vaRtvKMRVMBEk=; b=xWGz73xtchp/PdSJeEIiF8Q/df dAz8gSvCjE++jttswZitbndgQadQeuuDkQrV4sfxjhC7uJVdTIMOhiuN4qoGtjzvuXdcVad4JjMTR oK2HNdlnnbiXKwEyZKSXI7w3Jh6KIho4QGRA24476nSuun2g29k0rdjm3GnsyBhKH8NE=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [ovmf test] 184889: all pass - PUSHED X-Osstest-Versions-This: ovmf=3775122ede395d934198ffdb0c173875a5e94c00 X-Osstest-Versions-That: ovmf=275d0a39c42ad73a6e4929822f56f5d8c16ede96 From: osstest service owner Date: Mon, 04 Mar 2024 10:00:24 +0000 flight 184889 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/184889/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 3775122ede395d934198ffdb0c173875a5e94c00 baseline version: ovmf 275d0a39c42ad73a6e4929822f56f5d8c16ede96 Last test of basis 184836 2024-03-01 19:13:07 Z 2 days Testing same since 184889 2024-03-04 07:41:17 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Jason Lou 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-pvops pass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git 275d0a39c4..3775122ede 3775122ede395d934198ffdb0c173875a5e94c00 -> xen-tested-master From xen-devel-bounces@lists.xenproject.org Mon Mar 04 10:02:58 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 10:02:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688262.1072281 (Exim 4.92) (envelope-from ) id 1rh59s-0006Mu-CB; Mon, 04 Mar 2024 10:02:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688262.1072281; Mon, 04 Mar 2024 10:02:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh59s-0006Mn-8A; Mon, 04 Mar 2024 10:02:56 +0000 Received: by outflank-mailman (input) for mailman id 688262; Mon, 04 Mar 2024 10:02:54 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh59q-0006Mf-Fr for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 10:02:54 +0000 Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [2607:f8b0:4864:20::82d]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 50b4a666-da0e-11ee-afda-a90da7624cb6; Mon, 04 Mar 2024 11:02:32 +0100 (CET) Received: by mail-qt1-x82d.google.com with SMTP id d75a77b69052e-42e89610ed8so25571851cf.3 for ; Mon, 04 Mar 2024 02:02:31 -0800 (PST) Received: from localhost ([213.195.118.74]) by smtp.gmail.com with ESMTPSA id r13-20020ac8794d000000b0042ef2aec595sm726086qtt.67.2024.03.04.02.02.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Mar 2024 02:02:30 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 50b4a666-da0e-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709546551; x=1710151351; darn=lists.xenproject.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=s/G6blyqMTssk1cXnyPmi1uDTIHsC/KVDdHuUdT+F6I=; b=AaRsEwcTLzWLfGHmTPMjD97vKgVtCcnbE5SM12cp4qaBLEbiQNg0BCiHuy3RIMqvcv xxu1ZXCB3WhpBYg3U86AbX8hdP+mZPxlCHBipRpJjR97syGXqDR9NkZq8agjuS2hN2an ktj2XzHLIVFVUrKETumXmERB6KXR9hzmw0ooc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709546551; x=1710151351; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=s/G6blyqMTssk1cXnyPmi1uDTIHsC/KVDdHuUdT+F6I=; b=F9sq1nZ1olWhqXEPQboMmkVexRbnYwhOBUr8nOVoHIT4Mi4Yh+uFyp6rmO+pavxUpA EUNl/0G4/QUa8ZhpAKZ2mVn7AehE+/tLs4bRec57t1syRLmXf0hRNhE4vD2LxNL1svaT T3V+kC/GMqn1q1pXCAeD9VK3XRLzDGPDa0L3qhbHwOQx4HZGCx9vw7o/sfn2/2lPmjda ZRj6t+6nUzfy5IwKqtUulg8ZB3bzdQ2h6rXtslL8XA881K/fEpbcn+IaRegIGBtpTSvu lbbKegyHBzPVIy3XA7lDNFAGmnK8x4JfIsrMr3I694G4i2SrqFskgthTXgivCAm7EIec je/g== X-Gm-Message-State: AOJu0YzPTAVJCA8ZghhFQ9eKO55pPGaBsSVfOQsShWesks9De7LJ5Y/F GJqD52/JuQWIwwdAA9o6a+3GJc27dmUqmgdYTRUcPuUquayaWkWb//m3ojxxd1Y= X-Google-Smtp-Source: AGHT+IFZ9mk7e0sQ+CQ51MjCdAUkEwC2OBX5jF8SNuzKRcTxl1o6HPYh/XJo75hsJZxYHrVL2hKlaw== X-Received: by 2002:a05:622a:11ca:b0:42e:9146:a0bd with SMTP id n10-20020a05622a11ca00b0042e9146a0bdmr12425331qtk.49.1709546550747; Mon, 04 Mar 2024 02:02:30 -0800 (PST) Date: Mon, 4 Mar 2024 11:02:28 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Wei Liu , Neowutran Subject: Re: [PATCH] hvmloader/PCI: skip huge BARs in certain calculations Message-ID: References: <090d572c-5196-46b2-9d6b-741b7cb66d97@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <090d572c-5196-46b2-9d6b-741b7cb66d97@suse.com> On Mon, Mar 04, 2024 at 08:32:22AM +0100, Jan Beulich wrote: > BARs of size 2Gb and up can't possibly fit below 4Gb: Both the bottom of > the lower 2Gb range and the top of the higher 2Gb range have special > purpose. Don't even have them influence whether to (perhaps) relocate > low RAM. Here you mention 2Gb BARs, yet the code below sets the maximum BAR size supported below 4Gb to 1Gb. > Reported-by: Neowutran > Signed-off-by: Jan Beulich > --- > If we wanted to fit e.g. multiple 1Gb BARs, it would likely be prudent > to similarly avoid low RAM relocation in the first place. Yet accounting > for things differently depending on how many large BARs there are would > require more intrusive code changes. > > That said, I'm open to further lowering of the threshold. That'll > require different justification then, though. > > --- a/tools/firmware/hvmloader/pci.c > +++ b/tools/firmware/hvmloader/pci.c > @@ -33,6 +33,13 @@ uint32_t pci_mem_start = HVM_BELOW_4G_MM > const uint32_t pci_mem_end = RESERVED_MEMBASE; > uint64_t pci_hi_mem_start = 0, pci_hi_mem_end = 0; > > +/* > + * BARs larger than this value are put in 64-bit space unconditionally. That > + * is, such BARs also don't play into the determination of how big the lowmem > + * MMIO hole needs to be. > + */ > +#define HUGE_BAR_THRESH GB(1) I would be fine with defining this to an even lower number, like 256Mb, as to avoid as much as possible memory relocation in order to make the MMIO hole bigger. > + > enum virtual_vga virtual_vga = VGA_none; > unsigned long igd_opregion_pgbase = 0; > > @@ -286,9 +293,11 @@ void pci_setup(void) > bars[i].bar_reg = bar_reg; > bars[i].bar_sz = bar_sz; > > - if ( ((bar_data & PCI_BASE_ADDRESS_SPACE) == > - PCI_BASE_ADDRESS_SPACE_MEMORY) || > - (bar_reg == PCI_ROM_ADDRESS) ) > + if ( is_64bar && bar_sz > HUGE_BAR_THRESH ) > + bar64_relocate = 1; > + else if ( ((bar_data & PCI_BASE_ADDRESS_SPACE) == > + PCI_BASE_ADDRESS_SPACE_MEMORY) || > + (bar_reg == PCI_ROM_ADDRESS) ) > mmio_total += bar_sz; > > nr_bars++; > @@ -367,7 +376,7 @@ void pci_setup(void) > pci_mem_start = hvm_info->low_mem_pgend << PAGE_SHIFT; > } > > - if ( mmio_total > (pci_mem_end - pci_mem_start) ) > + if ( mmio_total > (pci_mem_end - pci_mem_start) || bar64_relocate ) > { > printf("Low MMIO hole not large enough for all devices," > " relocating some BARs to 64-bit\n"); Is the above message now accurate? Given the current code the low MMIO could be expanded up to 2Gb, yet BAR relocation will happen unconditionally once a 1Gb BAR is found. > @@ -446,8 +455,9 @@ void pci_setup(void) > * the code here assumes it to be.) > * Should either of those two conditions change, this code will break. > */ > - using_64bar = bars[i].is_64bar && bar64_relocate > - && (mmio_total > (mem_resource.max - mem_resource.base)); > + using_64bar = bars[i].is_64bar && bar64_relocate && > + (mmio_total > (mem_resource.max - mem_resource.base) || > + bar_sz > HUGE_BAR_THRESH); > bar_data = pci_readl(devfn, bar_reg); > > if ( (bar_data & PCI_BASE_ADDRESS_SPACE) == > @@ -467,7 +477,8 @@ void pci_setup(void) > resource = &mem_resource; > bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK; > } > - mmio_total -= bar_sz; > + if ( bar_sz <= HUGE_BAR_THRESH ) > + mmio_total -= bar_sz; I'm missing the part where hvmloader notifies QEMU of the possibly expanded base and size memory PCI MMIO regions, so that those are reflected in the PCI root complex registers? Overall I think we could simplify the code by having a hardcoded 1Gb PCI MMIO hole below 4Gb, fill it with all the 32bit BARs and (re)locate all 64bit BARs above 4Gb (not that I'm requesting you to do it here). Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Mon Mar 04 10:28:56 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 10:28:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688265.1072290 (Exim 4.92) (envelope-from ) id 1rh5Yu-0001iS-9p; Mon, 04 Mar 2024 10:28:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688265.1072290; Mon, 04 Mar 2024 10:28:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh5Yu-0001iL-74; Mon, 04 Mar 2024 10:28:48 +0000 Received: by outflank-mailman (input) for mailman id 688265; Mon, 04 Mar 2024 10:28:47 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh5Yt-0001iC-Dx for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 10:28:47 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id fb0faab7-da11-11ee-afda-a90da7624cb6; Mon, 04 Mar 2024 11:28:46 +0100 (CET) Received: from truciolo.bugseng.com (unknown [37.161.114.33]) by support.bugseng.com (Postfix) with ESMTPSA id 168124EE0737; Mon, 4 Mar 2024 11:28:44 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fb0faab7-da11-11ee-afda-a90da7624cb6 From: Federico Serafini To: xen-devel@lists.xenproject.org Cc: consulting@bugseng.com, Federico Serafini , Simone Ballarin , Doug Goldstein , Stefano Stabellini , Andrew Cooper , George Dunlap , Jan Beulich , Julien Grall , Wei Liu Subject: [XEN PATCH] automation/eclair: add deviation for MISRA C:2012 Rule 16.6 Date: Mon, 4 Mar 2024 11:28:37 +0100 Message-Id: X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Update ECLAIR configuration to take into account the deviations agreed during MISRA meetings. Signed-off-by: Federico Serafini --- Changes in v2: - rephrased to make sure the deviation is not interpreted as a suggestion. --- automation/eclair_analysis/ECLAIR/deviations.ecl | 4 ++++ docs/misra/deviations.rst | 6 ++++++ 2 files changed, 10 insertions(+) diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl index 02eae39786..9ac3ee4dfd 100644 --- a/automation/eclair_analysis/ECLAIR/deviations.ecl +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl @@ -378,6 +378,10 @@ explicit comment indicating the fallthrough intention is present." -config=MC3R1.R16.3,reports+={safe, "any_area(end_loc(any_exp(text(^(?s).*/\\* [fF]all ?through.? \\*/.*$,0..1))))"} -doc_end +-doc_begin="A switch statement with a single switch clause and no default label may be used in place of an equivalent if statement if it is considered to improve readability." +-config=MC3R1.R16.6,switch_clauses+={deliberate, "default(0)"} +-doc_end + # # Series 18. # diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst index 123c78e20a..ce855ddae6 100644 --- a/docs/misra/deviations.rst +++ b/docs/misra/deviations.rst @@ -322,6 +322,12 @@ Deviations related to MISRA C:2012 Rules: - /\* Fallthrough \*/ - /\* Fallthrough. \*/ + * - R16.6 + - A switch statement with a single switch clause and no default label may + be used in place of an equivalent if statement if it is considered to + improve readability. + - Tagged as `deliberate` for ECLAIR. + * - R20.7 - Code violating Rule 20.7 is safe when macro parameters are used: (1) as function arguments; -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Mon Mar 04 10:32:42 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 10:32:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688268.1072302 (Exim 4.92) (envelope-from ) id 1rh5cd-0003Yp-Rv; Mon, 04 Mar 2024 10:32:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688268.1072302; Mon, 04 Mar 2024 10:32:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh5cd-0003Yi-NX; Mon, 04 Mar 2024 10:32:39 +0000 Received: by outflank-mailman (input) for mailman id 688268; Mon, 04 Mar 2024 10:32:39 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh5cd-0003Yc-6G for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 10:32:39 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 85aec628-da12-11ee-afda-a90da7624cb6; Mon, 04 Mar 2024 11:32:38 +0100 (CET) Received: from [172.20.10.8] (unknown [37.161.114.33]) by support.bugseng.com (Postfix) with ESMTPSA id 5D1114EE0737; Mon, 4 Mar 2024 11:32:37 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 85aec628-da12-11ee-afda-a90da7624cb6 Message-ID: <97fcacd7-c359-4e10-837c-29a31c86d331@bugseng.com> Date: Mon, 4 Mar 2024 11:32:36 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH] automation/eclair: add deviation for MISRA C:2012 Rule 16.6 Content-Language: en-US, it To: xen-devel@lists.xenproject.org Cc: consulting@bugseng.com, Simone Ballarin , Doug Goldstein , Stefano Stabellini , Andrew Cooper , George Dunlap , Jan Beulich , Julien Grall , Wei Liu References: From: Federico Serafini Organization: BUGSENG srl In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 04/03/24 11:28, Federico Serafini wrote: > Update ECLAIR configuration to take into account the deviations > agreed during MISRA meetings. > > Signed-off-by: Federico Serafini > --- > Changes in v2: > - rephrased to make sure the deviation is not interpreted as a suggestion. > --- > automation/eclair_analysis/ECLAIR/deviations.ecl | 4 ++++ > docs/misra/deviations.rst | 6 ++++++ > 2 files changed, 10 insertions(+) > > diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl > index 02eae39786..9ac3ee4dfd 100644 > --- a/automation/eclair_analysis/ECLAIR/deviations.ecl > +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl > @@ -378,6 +378,10 @@ explicit comment indicating the fallthrough intention is present." > -config=MC3R1.R16.3,reports+={safe, "any_area(end_loc(any_exp(text(^(?s).*/\\* [fF]all ?through.? \\*/.*$,0..1))))"} > -doc_end > > +-doc_begin="A switch statement with a single switch clause and no default label may be used in place of an equivalent if statement if it is considered to improve readability." > +-config=MC3R1.R16.6,switch_clauses+={deliberate, "default(0)"} > +-doc_end > + > # > # Series 18. > # > diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst > index 123c78e20a..ce855ddae6 100644 > --- a/docs/misra/deviations.rst > +++ b/docs/misra/deviations.rst > @@ -322,6 +322,12 @@ Deviations related to MISRA C:2012 Rules: > - /\* Fallthrough \*/ > - /\* Fallthrough. \*/ > > + * - R16.6 > + - A switch statement with a single switch clause and no default label may > + be used in place of an equivalent if statement if it is considered to > + improve readability. > + - Tagged as `deliberate` for ECLAIR. > + > * - R20.7 > - Code violating Rule 20.7 is safe when macro parameters are used: > (1) as function arguments; I forgot the "--reroll-count", I'm sorry. -- Federico Serafini, M.Sc. Software Engineer, BUGSENG (http://bugseng.com) From xen-devel-bounces@lists.xenproject.org Mon Mar 04 11:00:35 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 11:00:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688273.1072314 (Exim 4.92) (envelope-from ) id 1rh63S-0007xj-19; Mon, 04 Mar 2024 11:00:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688273.1072314; Mon, 04 Mar 2024 11:00:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh63R-0007xc-Ub; Mon, 04 Mar 2024 11:00:21 +0000 Received: by outflank-mailman (input) for mailman id 688273; Mon, 04 Mar 2024 11:00:20 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh63Q-0007xW-AE for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 11:00:20 +0000 Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [2a00:1450:4864:20::236]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 62fd1fb1-da16-11ee-a1ee-f123f15fe8a2; Mon, 04 Mar 2024 12:00:18 +0100 (CET) Received: by mail-lj1-x236.google.com with SMTP id 38308e7fff4ca-2d28387db09so49699151fa.0 for ; Mon, 04 Mar 2024 03:00:18 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 62fd1fb1-da16-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1709550017; x=1710154817; darn=lists.xenproject.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=pW8f1ig8LJ5KhgDQRBWPrrIsz8lm95H9Qtwv8BedyZw=; b=er3janwkj9KW9hROGLZrcxD+HuxVdcWB9Dbu2+mQ+SQj97S+sflAKW/oC4DN7fin2z f/uTanpUJMOHqCpo1g79skqUdCHMZvoJzS5QDLxRAjuT3VwBmV/KMBLFui4CV5amFnNo j4BRZhse/SWKC3tLVOhmSk8srMJhZJka91/RY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709550017; x=1710154817; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=pW8f1ig8LJ5KhgDQRBWPrrIsz8lm95H9Qtwv8BedyZw=; b=qkb7aGrM2mxYObT1jADPY12wZrxbyYDWilkLuVf9eUDNLV/ss4RgO3Xlxg8NQqigPo 1+4GiX5m+ZfqNiFEyq5O65tIK17blCWg8YB3eHEMmLTshXwAqQi6UnJ+myAgUsKafIdF ewZEuIUcMBCYIZeLhBmUaO/AB/By6n642qKYxjW+1i+nOam18EVBUbgDXhVJ0rX3c6LI sP37291/YSXOVpjfMhi3Mme/MIpsUd2/IfVC65ksdfMG9oloBGzkXw4cP/REDt8ONfl1 B2AZPsamTFCE6wuFfUeHVCguecrSdSNW00Il84+8a4HudP4jU4olMI+SXyfbHuZEqK5p iQPA== X-Gm-Message-State: AOJu0YxziOlkS43tXjcE8shx2noz2qEzpfKRXXnT5n1ardOAIlJMSYY4 li3l4WK3h4bfjQ4KiFjKnH23X+cWQXOQ6lGG/kMeZUdlZU5nMIDtpNKCNiXKi23lPvzidXke8rx zt6+XN1tlQ8l6LrZGR5VB5fLXy1j0zLjVVidrxQ60XYy2RThBNos= X-Google-Smtp-Source: AGHT+IFOfwcbiN6B2Rgc6sybM38TESFTjevAUbsVia3F69hOBgO8Jbh5y7I+6AlHo7lApJZZKmgQXLiV1tTS6iLjBfY= X-Received: by 2002:a2e:8788:0:b0:2d3:1964:73d7 with SMTP id n8-20020a2e8788000000b002d3196473d7mr6037839lji.8.1709550017445; Mon, 04 Mar 2024 03:00:17 -0800 (PST) MIME-Version: 1.0 References: <20240227132628.2157031-1-fouad.hilly@cloud.com> In-Reply-To: From: Fouad Hilly Date: Mon, 4 Mar 2024 11:00:06 +0000 Message-ID: Subject: Re: [PATCH v2] tools/xentop: Add VBD3 support to xentop To: Anthony PERARD Cc: Xen-devel , Wei Liu , Juergen Gross Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Feb 27, 2024 at 6:32=E2=80=AFPM Anthony PERARD wrote: > > On Tue, Feb 27, 2024 at 01:26:28PM +0000, Fouad Hilly wrote: > > diff --git a/tools/libs/stat/xenstat_linux.c b/tools/libs/stat/xenstat_= linux.c > > index cbba54aa83ee..6d82e204aad4 100644 > > --- a/tools/libs/stat/xenstat_linux.c > > +++ b/tools/libs/stat/xenstat_linux.c > > @@ -390,6 +390,38 @@ void xenstat_uninit_networks(xenstat_handle * hand= le) > > fclose(priv->procnetdev); > > } > > > > +static int read_attributes_vbd3(char *vbd3_path, xenstat_vbd *vbd) > > "const char *vbd3_path"? > > > > static int read_attributes_vbd(const char *vbd_directory, const char *= what, char *ret, int cap) > > { > > static char file_name[80]; > > @@ -438,7 +470,7 @@ int xenstat_collect_vbds(xenstat_node * node) > > int ret; > > char buf[256]; > > > > - ret =3D sscanf(dp->d_name, "%3s-%u-%u", buf, &domid, &vbd= .dev); > > + ret =3D sscanf(dp->d_name, "%255[^-]-%u-%u", buf, &domid,= &vbd.dev); > > 255 is overly ambitious, but it match the size of buf, so I guess it's > kind of ok, even if unnecessary. > > > if (ret !=3D 3) > > continue; > > if (!(strstr(buf, "vbd")) && !(strstr(buf, "tap"))) > > @@ -448,6 +480,8 @@ int xenstat_collect_vbds(xenstat_node * node) > > vbd.back_type =3D 1; > > else if (strcmp(buf,"tap") =3D=3D 0) > > vbd.back_type =3D 2; > > + else if (strcmp(buf,"vbd3") =3D=3D 0) > > + vbd.back_type =3D 3; > > Yay for magic number... Do you think you could introduce an enum or > define to replace this "3" by a meaningful? Maybe something like > XENSTAT_VBD_TYPE_VBD3, (name derived from the existing function > xenstat_vbd_type()). > > I'd like at least to replace the "3". But if you feel like having > another patch to replace the "2" and "1", that would be a plus. > > > else > > vbd.back_type =3D 0; > > > > @@ -479,6 +513,35 @@ int xenstat_collect_vbds(xenstat_node * node) > > vbd.error =3D 1; > > } > > } > > + else if (vbd.back_type =3D=3D 3) > > + { > > + char *td3_pid; > > + char *path; > > + > > + vbd.back_type =3D 3; > > `back_type` should already be 3 ;-). > > > + vbd.error =3D 0; > > + > > + if (asprintf(&path, "/local/domain/0/backend/vbd3= /%u/%u/kthread-pid", domid, vbd.dev) < 0) > > + continue; > > + > > + td3_pid =3D xs_read(node->handle->xshandle, XBT_N= ULL, path, NULL); > > + > > + free(path); > > + > > + if (td3_pid =3D=3D NULL) > > + continue; > > + > > + if (asprintf(&path, "/dev/shm/td3-%s/vbd-%u-%u", = td3_pid, domid, vbd.dev) < 0) { > > + free(td3_pid); > > + continue; > > + } > > + > > + if (read_attributes_vbd3(path, &vbd) < 0) > > + vbd.error =3D 1; > > Why sometime we do "continue" and sometime we do "vbd.error=3D1"? continue is used when path to domain statistics is checked, which is "dynamic"; However, if the path existed but failed to read statistics, that is when we set the error. > > > + > > + free(td3_pid); > > + free(path); > > + } > > else > > { > > vbd.error =3D 1; > > diff --git a/tools/libs/stat/xenstat_priv.h b/tools/libs/stat/xenstat_p= riv.h > > index 4eb44a8ebb84..c3a9635240e9 100644 > > --- a/tools/libs/stat/xenstat_priv.h > > +++ b/tools/libs/stat/xenstat_priv.h > > @@ -98,6 +98,22 @@ struct xenstat_vbd { > > unsigned long long wr_sects; > > }; > > > > +struct vbd3_stats { > > + uint32_t version; > > + uint32_t __pad; > > + uint64_t oo_reqs; > > + uint64_t read_reqs_submitted; > > + uint64_t read_reqs_completed; > > + uint64_t read_sectors; > > + uint64_t read_total_ticks; > > + uint64_t write_reqs_submitted; > > + uint64_t write_reqs_completed; > > + uint64_t write_sectors; > > + uint64_t write_total_ticks; > > + uint64_t io_errors; > > + uint64_t flags; > > +}; > > Is that a binary interface for an external project? I'm asking because > `__pad` would seems useless otherwise. > If it is part of an interface, please add a comment about it, add a link > to the project/source where this interface is described, and where is > the canonical location? Also, is there an header we could maybe just > use if it's in the system or an header we could import into the > repository? > > Thanks, > > -- > Anthony PERARD From xen-devel-bounces@lists.xenproject.org Mon Mar 04 11:06:41 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 11:06:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688276.1072323 (Exim 4.92) (envelope-from ) id 1rh69T-00006d-Kz; Mon, 04 Mar 2024 11:06:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688276.1072323; Mon, 04 Mar 2024 11:06:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh69T-00006W-IR; Mon, 04 Mar 2024 11:06:35 +0000 Received: by outflank-mailman (input) for mailman id 688276; Mon, 04 Mar 2024 11:06:34 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh69S-00006Q-Bv for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 11:06:34 +0000 Received: from mail-qv1-xf2d.google.com (mail-qv1-xf2d.google.com [2607:f8b0:4864:20::f2d]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 422e8280-da17-11ee-afda-a90da7624cb6; Mon, 04 Mar 2024 12:06:33 +0100 (CET) Received: by mail-qv1-xf2d.google.com with SMTP id 6a1803df08f44-68f5cdca7a3so39414906d6.1 for ; Mon, 04 Mar 2024 03:06:33 -0800 (PST) Received: from localhost ([213.195.118.74]) by smtp.gmail.com with ESMTPSA id kv9-20020a056214534900b006905c8b37bbsm3293451qvb.133.2024.03.04.03.06.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Mar 2024 03:06:31 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 422e8280-da17-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709550392; x=1710155192; darn=lists.xenproject.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=nj7TaiKNdx+UofWlTcISG1cNyrM42a4yAPgq52ev2dQ=; b=JNQYPZN0xTjcnOt1v6TcBAfTOa+o3MN/6rdgop6l0D1CeklJPJIVz27hUI7KfBtUfH 3vDVgu023G6LN5pCyZeY+DjofHmozW7p665AZWL8dszYQNEcKGYRsxIC8RL0Bp0qtQyR io7XJXAn9ztuhrEmERxWwb3nTPn5FLklBqwsM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709550392; x=1710155192; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=nj7TaiKNdx+UofWlTcISG1cNyrM42a4yAPgq52ev2dQ=; b=ddTWHcvCU9bjuyIbi8ztdmHpfbPqeLzsubqtxfPuvl5AFfNc+XP9zndXB0BeSFiOh3 rpJDNKgKTN8f19/rHAg77kfYRo7GF3pme+dGO2CugmgTjy+PEulb1BX9qklmlo8caTCo 7fJGj5MMS1uo/WO+Z7d5WxCyMmDu7cCizBcYOPQIca/GUDONCSbBnJW4z83GLpifIvyu 4bp/3t+YDoYeWUha+6sFi1q7TT1vdX7SW05qt4UlavIaGFkXDiRdKHmIpgS0egGkwC+A YPN4r3Ao17389sp4EYXsLst8tIXa/8fUVi4s7lUXw8eSaVpmphsIcml8LSttKbdHznfF cn7Q== X-Gm-Message-State: AOJu0YxuO08DiG9iYYNGfUvZbOk3BxzcKrBgZHz9Bmiw6Cfn9QizWLtL 2EJGuLPLVkhJ2SLkiMnju6vplcX7Ys8vH6DerRpXWd/X2G/GrodMdoAQtuf5HMI= X-Google-Smtp-Source: AGHT+IGt0iG0ipjqmYbgvFr3A9xhv5F2lA+o0LsZT58nTNBzusESgX+5ByyAgcNvYcUBnIT/Gh50ng== X-Received: by 2002:a0c:da84:0:b0:690:5ff8:cc0 with SMTP id z4-20020a0cda84000000b006905ff80cc0mr8354428qvj.11.1709550392004; Mon, 04 Mar 2024 03:06:32 -0800 (PST) Date: Mon, 4 Mar 2024 12:06:29 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Wei Liu , Kevin Tian , Jun Nakajima Subject: Re: [PATCH] MAINTAINERS: drop AMD SVM and Intel VT-x sections Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Mon, Mar 04, 2024 at 10:27:44AM +0100, Jan Beulich wrote: > We'd like to thank the VT-x maintainers for their past contributions, > while at the same time we'd like to reflect reality as it has been for > quite some time. Have VT-x maintainership (and for symmetry also AMD > SVM's) fall back to general x86. > > Signed-off-by: Jan Beulich Acked-by: Roger Pau Monné Thanks. From xen-devel-bounces@lists.xenproject.org Mon Mar 04 11:07:35 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 11:07:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688278.1072334 (Exim 4.92) (envelope-from ) id 1rh6AQ-0000ck-UY; Mon, 04 Mar 2024 11:07:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688278.1072334; Mon, 04 Mar 2024 11:07:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh6AQ-0000cd-RY; Mon, 04 Mar 2024 11:07:34 +0000 Received: by outflank-mailman (input) for mailman id 688278; Mon, 04 Mar 2024 11:07:33 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh6AP-0000bp-07 for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 11:07:33 +0000 Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [2a00:1450:4864:20::530]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 650a675d-da17-11ee-a1ee-f123f15fe8a2; Mon, 04 Mar 2024 12:07:31 +0100 (CET) Received: by mail-ed1-x530.google.com with SMTP id 4fb4d7f45d1cf-56454c695e6so7144951a12.0 for ; Mon, 04 Mar 2024 03:07:31 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 650a675d-da17-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1709550450; x=1710155250; darn=lists.xenproject.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=ngYdvlWyfWzO1QUcZvif0PwpVR1L5y8LDTfKl/i6E/A=; b=cTrXFQHhffM1Bpy32YqGab4jRH9t6ae6ZGbIGwZwMk/OhqnNvxTPynZB2GQ6oyrQbQ WbvWvap+Grl1OW7ZbrB/w/bNyfMiUxt5/Q99ORloD5MCVTLUuQ9GAxSVYEjW/ITTyIdA GU4Jmu3NL3PoVnZK8EyiBi4CeorqN6DzKMNoU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709550450; x=1710155250; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ngYdvlWyfWzO1QUcZvif0PwpVR1L5y8LDTfKl/i6E/A=; b=jkHRElXo1eqBfPnGoz/as79DMM/gxgzuh9Kr1p/2qGBPlCuTXher6uLJUrfgH2w01C CrNkhqCm/LPtNLsQUZIs3i89rw5DBsOfKYNERGvsKC6PNp3mvc6KgUbjPNr9hhLLlq7f o1jfSlf5xUNWWhB7dIac0Ny3ncKOfMRzgppOUtmIgVVZFUXscgCqoAg7M/xkO9Q0x2oU zi18Q4/o43SMQG8uMdNeyHjekftEUZ5kAyKd9pqjyLZz40DcTSfjUWSMAj8KPfcVLgUH ZWFtcsJYLYMVe0Xez4Gof9mkMH7mx1EOemVnCoqN3MsigSzRNd1N0vAXZM5J0KDU++6O fXmw== X-Gm-Message-State: AOJu0Yx0KpteHktVTrzNIZ0Gi4LX8Wwjw3L4WZ8+HPosQns/yO81hDU6 vihYaXlT3KjM3mRTb4Ixr54fIcrvhNy9sse/Ouhqc4NURDcVk9ahIFqYBoa4ge/95HrkOwqawHy NNCnSr7b/PxCQYn5wNxLwIEnNuOubSd4QT7FmMYhd9aZEDf4TPIc= X-Google-Smtp-Source: AGHT+IEWv6w3/q8sAraSB7FqtnNsI3jd1QwtOUuaIJzm3oXS2DMLoT+WHaTN2b6uNrmFqLyxG4Z82tCet8OW94GMCHc= X-Received: by 2002:a05:6402:4312:b0:567:e0e:dda5 with SMTP id m18-20020a056402431200b005670e0edda5mr6024953edc.17.1709550450107; Mon, 04 Mar 2024 03:07:30 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Kelly Choi Date: Mon, 4 Mar 2024 11:06:54 +0000 Message-ID: Subject: XEN SUMMIT CFP DEADLINE EXTENDED BY 1 WEEK! To: xen-devel@lists.xenproject.org, xen-users@lists.xenproject.org, xen-announce@lists.xenproject.org Content-Type: multipart/alternative; boundary="0000000000004e005d0612d3bb18" --0000000000004e005d0612d3bb18 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi everyone, Good news, our CFP deadline for Xen Summit has been extended by one week to Sunday 10th March 2024. Please submit your talks before then! Many thanks, Kelly Choi Community Manager Xen Project On Tue, Feb 27, 2024 at 10:22=E2=80=AFAM Kelly Choi = wrote: > Hi everyone, > > *Just a reminder that our CFP for Xen Summit 2024 is at the end of this > week! * > > Please submit your talks before then: > https://events.linuxfoundation.org/xen-project-summit/program/cfp/ > > We look forward to seeing you. > > Many thanks, > Kelly Choi > > Community Manager > Xen Project > --0000000000004e005d0612d3bb18 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi everyone,

Good news, our CFP deadline for Xen Summit has been ex= tended by one week to Sunday 10th March 2024.

Please submit your talks before then!=C2=A0

Many thanks,
Kelly Choi

Community Manager
Xen Project=C2=A0


On Tue, Feb 27, 2024 at 10:22=E2=80=AFAM Kelly Choi <kelly.choi@cloud.com> wrote:
Hi ev= eryone,

Just a reminder that = our CFP for Xen Summit 2024 is at the end of this week!=C2=A0

Please submit = your talks before then:

We look=C2=A0forward to seeing you.

Many thanks,<= /div>
Kelly Choi

Community Manager
Xen P= roject=C2=A0
--0000000000004e005d0612d3bb18-- From xen-devel-bounces@lists.xenproject.org Mon Mar 04 11:25:37 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 11:25:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688333.1072373 (Exim 4.92) (envelope-from ) id 1rh6Ri-0006AM-Ef; Mon, 04 Mar 2024 11:25:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688333.1072373; Mon, 04 Mar 2024 11:25:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh6Ri-0006AF-9j; Mon, 04 Mar 2024 11:25:26 +0000 Received: by outflank-mailman (input) for mailman id 688333; Mon, 04 Mar 2024 11:25:24 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh6Rg-0006A6-CV for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 11:25:24 +0000 Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [2a00:1450:4864:20::536]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id e36d1993-da19-11ee-a1ee-f123f15fe8a2; Mon, 04 Mar 2024 12:25:22 +0100 (CET) Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-563cb3ba9daso5414586a12.3 for ; Mon, 04 Mar 2024 03:25:22 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e36d1993-da19-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1709551521; x=1710156321; darn=lists.xenproject.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=MVI2Rq4LFUTalI0QvuKjB0kSKNn+gR7USDXgz7zXuJQ=; b=T0XgpiusnFQCgb/OBLmzn4tw7RBxzByrVgVUrx5y56W6hBU5vrYl0MwRwwbt/IBgJy 7FW11i1VbDwWUTqiGRRtC+xsjbOSeOly7Fb04xT4JL0y5owJ/Vk5C2L/ov6dR78OFKMs LWu1zqWIR6tRgQwK0Kp5KfxgAnb5V01FTiF/c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709551521; x=1710156321; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=MVI2Rq4LFUTalI0QvuKjB0kSKNn+gR7USDXgz7zXuJQ=; b=V+Jsev1dZ/6lrEujfpQoAllsEWs2mc9zA2Fn77COiokg/Vn4Ejr+gYKyGmFT7bz/sj V0Yd3m+0md2UaXVpOPMK0Moj0C9doE8QdPfK/vrK3mz1JDQmnpc/s2GUn5UjBnt4wXcX g4tbWv9SA40lZwAC8icl1vwGTrQ179cwNrMKjZwKAc2ELRhJs6df0Bh7W5ec7zBR6pw5 kzYkG/9NtB62wswe4V1IhMRbz50h0dUmjNWxbGbXf0noGldnPvapnL2Q/wwqgPx7NAjw 3P9qZ8e+FqFo9/QYbQgHP8mDg3YviuF1jshbaIE2rdXhyU9h1uw4WY+31aWSITFrk8Fy CXbg== X-Gm-Message-State: AOJu0YxnR8NPul6EFGdm+Q7jE3lTDXFU7Yykh68Vm+p1PZ33udxkeqtc okp5+huFdRa23Oo/F7iVtP76m1YcLh6htEFKWEeltUF5ZSbpwXXKZOHcqXPkEBOE7vVxppidm1D BysttduBnmTzOUfgmqGsaRCwyfVC7zJMKGxQgLA== X-Google-Smtp-Source: AGHT+IFZrakKMYzLH1hlpTmZ8YjX1jzb5KrZN54pNt1bg6BHlclq9ukwriMVTr5SRheNAoh2XVyTD2e79R69+gmG7bA= X-Received: by 2002:a05:6402:40c8:b0:567:15a6:848e with SMTP id z8-20020a05640240c800b0056715a6848emr3840975edb.18.1709551521589; Mon, 04 Mar 2024 03:25:21 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Kelly Choi Date: Mon, 4 Mar 2024 11:24:45 +0000 Message-ID: Subject: Re: Link to the 2023 xen summit schedule is broken To: =?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= Cc: xen-devel Content-Type: multipart/alternative; boundary="0000000000002b8db60612d3fb56" --0000000000002b8db60612d3fb56 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Marek, Try this link, it should show the sessions for 2023. https://xen2023.sched.com/ Many thanks, Kelly Choi Community Manager Xen Project On Sun, Mar 3, 2024 at 3:01=E2=80=AFAM Marek Marczykowski-G=C3=B3recki < marmarek@invisiblethingslab.com> wrote: > Hi, > > The link to the last year schedule at > https://events.linuxfoundation.org/archive/2023/xen-project-summit/ is > broken, it opens a page for upcoming "ONE summit" event that doesn't > look to be related to Xen Summit. > > -- > Best Regards, > Marek Marczykowski-G=C3=B3recki > Invisible Things Lab > --0000000000002b8db60612d3fb56 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Marek,

Try this link, it should show= the sessions for 2023.

Many thanks,
Kelly Choi

Community Manager
Xen Project=C2=A0

On Sun, Mar 3, 2024 at 3:01=E2=80=AFAM Marek Marczykowski-G=C3=B3re= cki <marmarek@invisib= lethingslab.com> wrote:
Hi,

The link to the last year schedule at
https://events.linuxfoundation.or= g/archive/2023/xen-project-summit/ is
broken, it opens a page for upcoming "ONE summit" event that does= n't
look to be related to Xen Summit.

--
Best Regards,
Marek Marczykowski-G=C3=B3recki
Invisible Things Lab
--0000000000002b8db60612d3fb56-- From xen-devel-bounces@lists.xenproject.org Mon Mar 04 11:42:14 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 11:42:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688338.1072381 (Exim 4.92) (envelope-from ) id 1rh6hr-0001JI-Of; Mon, 04 Mar 2024 11:42:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688338.1072381; Mon, 04 Mar 2024 11:42:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh6hr-0001JB-M0; Mon, 04 Mar 2024 11:42:07 +0000 Received: by outflank-mailman (input) for mailman id 688338; Mon, 04 Mar 2024 11:42:07 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh6hr-0001J5-15 for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 11:42:07 +0000 Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [2a00:1450:4864:20::62c]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 392090a8-da1c-11ee-a1ee-f123f15fe8a2; Mon, 04 Mar 2024 12:42:04 +0100 (CET) Received: by mail-ej1-x62c.google.com with SMTP id a640c23a62f3a-a458850dbddso4938066b.0 for ; Mon, 04 Mar 2024 03:42:04 -0800 (PST) Received: from [10.80.5.21] (default-46-102-197-194.interdsl.co.uk. [46.102.197.194]) by smtp.gmail.com with ESMTPSA id fw16-20020a170906c95000b00a449b175d2fsm3420559ejb.222.2024.03.04.03.42.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Mar 2024 03:42:04 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 392090a8-da1c-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1709552524; x=1710157324; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=snfhScXYKNnKUoeQj74fH7B2eTQCxeRrJzY3E9lPG5M=; b=LPJXjKuc2nLmshPswClNhJFd7P1OJuDV+Sd0/na2eMiHkm5pdsCMxx1JH5Sxyk2N2O kdBUQG+qhxh6oqOIkVKwKFThvjwEXAO7ssOXyGF+wWD8d04UYR8679F5oURyxjt7nKzK H4F0jTg1TTPFywlkTJmixeBbstcJn0BF2vPUc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709552524; x=1710157324; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=snfhScXYKNnKUoeQj74fH7B2eTQCxeRrJzY3E9lPG5M=; b=fhZr1OKohoqFQyORhic/vaNqZ6LCpeo64cbhsCnt2OCHNfyKQKvCE0zZsuRNVGhg1Z 5SXTcYrZQ7/HLQg94qZiAH+QFmHKhT6XLZqRBetLwNveayg1UfVF238CHErz3uMgoAFF nIWbfYGNnDjehnABlLvc9z5BANDGOqQh4xkxS7diB0UxAWAe3ixxYH5+6DTiSImK6c84 K7sXDri39ufkh74mzXM2czxmLpUkTK3g1FL1Ikl8U6rkviJbI2jB5Fjlk2s3OCCrhUog hZ40rm6YJo184GRLNPontLfe1NYDxV131c5ejJg/MVvyIzWmRL+g2WWoRB2iO6PKAO4o 4SMA== X-Forwarded-Encrypted: i=1; AJvYcCUA4VOIu7Esq138Rggr9FkJ0J2Sd4k0jfe8tCeInFiFLItT/mqCfu8BxPnCqz4Hn7k4J2/90iWwYbQpeelk83ClO3lFq1wBbwzehXkERdU= X-Gm-Message-State: AOJu0YwOwMo5uhvQv5+c1X70t+PuqlxMG9bknNgrXT7edVM14vyiCEHq 0RSVjpVMtfrYd/i9r8LbtxSODkOc0x8ypcsXdcUF+duDF8WCT+KSxZyWG5lr6/A= X-Google-Smtp-Source: AGHT+IFIkWbvxXqzrH9jBqABTlJqL63Uv/BugjsWwGTjPYFdDGbr5WM7ciRrcJjTFfDy525KTkhg0Q== X-Received: by 2002:a17:906:cc93:b0:a43:e46b:7a80 with SMTP id oq19-20020a170906cc9300b00a43e46b7a80mr5478341ejb.43.1709552524419; Mon, 04 Mar 2024 03:42:04 -0800 (PST) Message-ID: <70fcb88b-43d0-46e1-9d67-1f8a5d89f4f6@cloud.com> Date: Mon, 4 Mar 2024 11:42:01 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] hvmloader/PCI: skip huge BARs in certain calculations Content-Language: en-GB To: Jan Beulich , "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Neowutran References: <090d572c-5196-46b2-9d6b-741b7cb66d97@suse.com> From: Alejandro Vallejo In-Reply-To: <090d572c-5196-46b2-9d6b-741b7cb66d97@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi, On 04/03/2024 07:32, Jan Beulich wrote: > BARs of size 2Gb and up can't possibly fit below 4Gb: Both the bottom of > the lower 2Gb range and the top of the higher 2Gb range have special > purpose. Don't even have them influence whether to (perhaps) relocate > low RAM. > > Reported-by: Neowutran > Signed-off-by: Jan Beulich > --- > If we wanted to fit e.g. multiple 1Gb BARs, it would likely be prudent > to similarly avoid low RAM relocation in the first place. Yet accounting > for things differently depending on how many large BARs there are would > require more intrusive code changes.> > That said, I'm open to further lowering of the threshold. That'll > require different justification then, though. > GPUs without resizable BARs tend to expose 256MiB on the BAR regardless of the amount of internal VRAM, AFAIK. So IMO 256 MiB is not a totally unmotivated number. I don't know which other PCIe devices might expose such big BARs for comparison. Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Mon Mar 04 11:58:20 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 11:58:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688341.1072391 (Exim 4.92) (envelope-from ) id 1rh6xT-0003TG-1Y; Mon, 04 Mar 2024 11:58:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688341.1072391; Mon, 04 Mar 2024 11:58:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh6xS-0003T9-V6; Mon, 04 Mar 2024 11:58:14 +0000 Received: by outflank-mailman (input) for mailman id 688341; Mon, 04 Mar 2024 11:58:14 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh6xS-0003Sy-Gu for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 11:58:14 +0000 Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [2a00:1450:4864:20::629]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 79fb4ffb-da1e-11ee-afda-a90da7624cb6; Mon, 04 Mar 2024 12:58:12 +0100 (CET) Received: by mail-ej1-x629.google.com with SMTP id a640c23a62f3a-a3ed9cae56fso1005051466b.1 for ; Mon, 04 Mar 2024 03:58:12 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 79fb4ffb-da1e-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1709553492; x=1710158292; darn=lists.xenproject.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=4uzf6dNKIpQngPAbvvM4mnGw7+WpEfvrugk5KLb21Uk=; b=lCSix2X7h0b9DR9Ch8PZKM9HoD9QgXwi5gcMbdsFoAZ3APPgvEGhxty7iFQYCKgsTP C4b8nWHJM3PEuro4TgxHB+lq5DE+h7/jp0bmMRMwDEcD6J8m7Ziq++weim2lJeClAX63 NkQ1qKvojooUlPTVS4W/gW75jah+1tpf6Yjb0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709553492; x=1710158292; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=4uzf6dNKIpQngPAbvvM4mnGw7+WpEfvrugk5KLb21Uk=; b=KWIUXucHO6DUpAvC8qfmpI2cg/0ZXFFeeuRwocWefqBivjgFHSMwXlwU/nOfP3Pxxb tj00sRStdIKSZIyHoV5yizjamEsV/8yKqMRI4HJWBhfF7j4+4uyoquvWuROeEZwJHiKj WtSnC+Tb6PKCMSnETRKDi1AtYu6U/tNxyPeXCfOP7Q6GAdValXiTg/wmXk5L5hnruhRp Hg4OHOFYLPFZPSIfSsQScA3Ls4kLKGvxxVgTjbC6khvblpvQowEIboIPRsCWOH7uB3Is 6QhKm6Ic0nQvGiBMQbo2onKiid/fxuCthqZthtcK/xVN5I5QnbV0n8mSBpeunysyrLuC QlNw== X-Gm-Message-State: AOJu0Yxtki/VzED7jmiqMEPm8aaVX87NoKM/GNTLqt3qQMuuD3SDLBv8 DmT+Vyg45Xv494uqdPcwCbXp8V7BI/DE9uob9qRZFe7/MVHXgEEbOBK82pHbWntvxN9jF05X9WA X6hTJA6+wAX6cE00W3l3Q9M3M1SiGkxscLysmVb/aZh5MeB/aFFaRzu7n X-Google-Smtp-Source: AGHT+IHGwcvG4U2sYEKH2O+yz8ID0X8wgbAAI7tUy/tq1prZGHH4posMNqOzW9CrDP6e672fJ+4Vhz60PW1ZzvLmiog= X-Received: by 2002:a17:906:cec3:b0:a3c:5e17:1635 with SMTP id si3-20020a170906cec300b00a3c5e171635mr7679560ejb.30.1709553491880; Mon, 04 Mar 2024 03:58:11 -0800 (PST) MIME-Version: 1.0 From: Kelly Choi Date: Mon, 4 Mar 2024 11:57:35 +0000 Message-ID: Subject: [ANNOUNCE] Call for agenda items for Community Call To: xen-devel , xen-users@lists.xenproject.org, xen-announce@lists.xenproject.org Content-Type: multipart/alternative; boundary="0000000000009bc5150612d470ee" --0000000000009bc5150612d470ee Content-Type: text/plain; charset="UTF-8" Hi all, Please add your proposed agenda items below. https://cryptpad.fr/pad/#/2/pad/edit/VlIkjPmILf0abDG3j1Wn0091/ If any action items are missing or have been resolved, please add/remove them from the sheet. *CALL LINK: https://meet.jit.si/XenProjectCommunityCall * *DATE: Thursday 7th March 2024* *TIME: 1600 UTC (4 pm UK time)* *Note the following administrative conventions for the call:* ** To allow time to switch between meetings, we plan on starting theagenda at 16:05 UTC sharp. Aim to join by 16:03 UTC if possible to allocatetime to sort out technical difficulties.* If you want to be CC'ed please add or remove yourself from thesign-up-sheet at https://cryptpad.fr/pad/#/2/pad/edit/D9vGzihPxxAOe6RFPz0sRCf+/ == Dial-in Information ==## Meeting time16:00 - 17:00 British timeFurther International meeting times:https://www.timeanddate.com/worldclock/meetingdetails.html?year=2024&month=3&day=7&hour=16&min=0&sec=0&p1=1234&p2=37&p3=224&p4=179 * Thanks, Kelly Community Manager Xen Project ## Dial in details https://meet.jit.si/static/dialInInfo.html?room=XenProjectCommunityCall --0000000000009bc5150612d470ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

Please add your proposed ag= enda items below.

https://cryptpad.fr/pad/#/2/pad/edit/VlIkjPmILf0abD= G3j1Wn0091/=C2=A0

If any action items are missing or have bee= n resolved, please add/remove them from the sheet.=C2=A0

CALL=C2=A0LINK:=C2=A0https://meet.jit.si/XenProjectCommunityCall<= /p>

DATE: Thursday 7th March 2024

TIME: 1600 UTC (4 pm UK= time)

Note the following administrative conventions for the=C2= =A0call:

* To allow time to switch between meetings, we plan on starting t= he
agenda at 16:05 UTC sharp.=C2=A0 Aim to join by 16:03 UTC if possible= to allocate
time to sort out technical difficulties.

* If you wa= nt to be CC'ed please add or remove yourself from the
sign-up-sheet = at=C2=A0https://cryptpad.fr/pad/#/2/pa= d/edit/D9vGzihPxxAOe6RFPz0sRCf+/

=3D=3D=C2=A0Dial-in Information =3D=3D
## Meeting time
16:00 - 17:00= British time
Further International meeting times:
https://www.timeanddate.= com/worldclock/meetingdetails.html?year=3D2024&month=3D3&day=3D7&am= p;hour=3D16&min=3D0&sec=3D0&p1=3D1234&p2=3D37&p3=3D224&= amp;p4=3D179=C2=A0=C2=A0=C2=A0

Thanks,
Kelly
Community Mana= ger
Xen Project=C2=A0

#= #=C2=A0Dial=C2=A0in details
https://meet.jit.si/static/dialInInfo.h= tml?room=3DXenProjectCommunityCall

--0000000000009bc5150612d470ee-- From xen-devel-bounces@lists.xenproject.org Mon Mar 04 12:22:09 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 12:22:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688391.1072418 (Exim 4.92) (envelope-from ) id 1rh7KM-0001rV-IE; Mon, 04 Mar 2024 12:21:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688391.1072418; Mon, 04 Mar 2024 12:21:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh7KM-0001rO-EL; Mon, 04 Mar 2024 12:21:54 +0000 Received: by outflank-mailman (input) for mailman id 688391; Mon, 04 Mar 2024 12:21:54 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh7KM-0001rH-1M for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 12:21:54 +0000 Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [2607:f8b0:4864:20::22a]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id c6de11e0-da21-11ee-a1ee-f123f15fe8a2; Mon, 04 Mar 2024 13:21:50 +0100 (CET) Received: by mail-oi1-x22a.google.com with SMTP id 5614622812f47-3c1ea425a0fso557201b6e.3 for ; Mon, 04 Mar 2024 04:21:51 -0800 (PST) Received: from [10.80.67.149] (default-46-102-197-194.interdsl.co.uk. [46.102.197.194]) by smtp.gmail.com with ESMTPSA id a24-20020ac87218000000b0042ef85c6a42sm194641qtp.17.2024.03.04.04.21.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Mar 2024 04:21:48 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c6de11e0-da21-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709554910; x=1710159710; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:cc:to:subject:from:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=lhz+A8tKC1gvelqDSIx7ID/PY3PzPukLCWqUXdA2I9Q=; b=lKNpoByTcALnOecQnspFuHuiw93Q1GwyJXibMjHHpzHVnD+sxF+IRz7DU0ZIfz/wbC IoCM+o6wGvdIPh5Bu36spL66IBm3z7DO2Wbb5Dg+kFag0BuFIcnPZiRwCgDNEKqIPzUY 2Irbr1KuxZE7s4B4dhTtBDV1M1z5fBK/8Prek= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709554910; x=1710159710; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:cc:to:subject:from:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=lhz+A8tKC1gvelqDSIx7ID/PY3PzPukLCWqUXdA2I9Q=; b=WbI64MMMtWjpfBoEQyJOHEIQxisS2U64OxhYNuWcC/hICHcYw/JESHPAYcAi8AJZp0 osdBLf2VhKhpEXu0ERD6IrJkYIHigsu0eo1qV4A5ocAmYBsg/3Dz3Z26K5Y0ScJSOoT4 LjphPwtQ4Rlklm3Fla0u5nx9WxblOnXt1YRwANNJGOxBGpj515hqS1ySU5hWzvqhk9h1 Bjn0ny+JNg1NZBoFUK/mBbyfN0DFtYRsm5Qnrmk4wcHmg94kvS3dS7MHNpiGg5DJMK9q QFzTcRQFiXXSHdi5PCIyKdDwq7ryID7um8ovJ9pUiKeK/B9VNJgYmaf0/le/+43EMKCm MIRA== X-Forwarded-Encrypted: i=1; AJvYcCXGrxFyALzDNx9fWrPf1NLU9EaYnyaZ+qog3etUbJQOtc4PpSIw7QEEhVhLWu+w83x5+yBs6g9IdHc14xn+7dwzrYgwdcpfOlsRKWzRXFE= X-Gm-Message-State: AOJu0YyR1OV/9HM7eyzVDuQ0/u7+4ucipfhGDWIyj08h7H0viXdthLWp glOluH36OYdYIrKwkFnQ0qOh0lKf2UNsj5WiMr4bEQdoCK3nYKov5JxXNqB8nbA= X-Google-Smtp-Source: AGHT+IGf8yLuPkjw7MLU91ez2zvKrZ8knPVcbF7RvN7zj60aBar9sa/3zX0L9YLALKxxiSLSsmHIdg== X-Received: by 2002:aca:2b04:0:b0:3c1:4678:5aff with SMTP id i4-20020aca2b04000000b003c146785affmr9053178oik.31.1709554909855; Mon, 04 Mar 2024 04:21:49 -0800 (PST) Message-ID: <7bb5c1f1-f6ac-4345-a969-10387d08dbbc@citrix.com> Date: Mon, 4 Mar 2024 12:21:47 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Andrew Cooper Subject: Re: [PATCH] x86/cpu-policy: Hide x2APIC from PV guests To: Jan Beulich Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu , Xen-devel References: <20240229221448.2593171-1-andrew.cooper3@citrix.com> Content-Language: en-GB Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 04/03/2024 8:33 am, Jan Beulich wrote: > On 29.02.2024 23:14, Andrew Cooper wrote: >> PV guests can't write to MSR_APIC_BASE (in order to set EXTD), nor can they >> access any of the x2APIC MSR range. Therefore they mustn't see the x2APIC >> CPUID bit saying that they can. > This argumentation could then be used equally for the APIC bit. Why is it > correct to hide x2APIC, but not APIC? In an ideal world we'd hide APIC too. But Linux pvops doesn't tolerate it, and I'm not sure classic dom0 did either. >> Right now, the host x2APIC flag filters into PV guests, meaning that PV guests >> generally see x2APIC except on Zen1-and-older AMD systems. >> >> Linux works around this by explicitly hiding the bit itself, and filtering >> EXTD out of MSR_APIC_BASE reads. NetBSD behaves more in the spirit of PV >> guests, and entirely ignores the APIC when built as a PV guest. >> >> Change the annotation from !A to !S. This has a consequence of stripping it >> out of both PV featuremasks. However, as existing guests may have seen the >> bit, set it back into the PV Max policy; a VM which saw the bit and is alive >> enough to migrate will have ignored it one way or another. >> >> Hiding x2APIC does also change the contents of leaf 0xb, but as the >> information is nonsense to begin with, this is likely an improvement on the >> status quo. The blind reporting of APIC_ID = vCPU_ID * 2 isn't interlinked >> with the host's topology structure, and the APIC_IDs are useless without an >> MADT to start with. Dom0 is the only PV VM to get an MADT but it's the host >> one, meaning the two sets of APIC_IDs are from different address spaces. > Aiui the field will now be seen as zero on all CPUs. Is all CPUs having the > same APIC ID there really better than them all having different ones? Again - we're taking something that was conditionally like this, and making it unconditionally like this. When x2APIC is hidden, so is the precondition for the data in this leaf being valid. > Also while I agree that logically CPUID leaf 0xb EDX is tied to x2APIC being > available as a feature, nothing is said in this regard in the documentation > of that leaf. This in particular leaves open whether on a system with x2APIC > disabled in/by firmware the value would actually be zero. Yet that case could > be considered somewhat similar to the PV case here. I'm not aware of there being a capability to disable x2APIC in firmware. The only choices you got were which mode to default to, and (occasionally) whether to set the x2APIC opt-out in DMAR. ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Mar 04 13:01:28 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 13:01:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688396.1072428 (Exim 4.92) (envelope-from ) id 1rh7wV-0000fT-G5; Mon, 04 Mar 2024 13:01:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688396.1072428; Mon, 04 Mar 2024 13:01:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh7wV-0000fM-DL; Mon, 04 Mar 2024 13:01:19 +0000 Received: by outflank-mailman (input) for mailman id 688396; Mon, 04 Mar 2024 13:01:18 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh7wU-0000fC-06; Mon, 04 Mar 2024 13:01:18 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh7wT-0007Go-VI; Mon, 04 Mar 2024 13:01:17 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh7wT-0003DZ-Jv; Mon, 04 Mar 2024 13:01:17 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rh7wT-0005zQ-JU; Mon, 04 Mar 2024 13:01:17 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=rcwfdA4PUTj/M1A6LU9Q8zUQ1IyB+U/BDkuGbRLix7g=; b=ZYYgKsEPIsKCcNkT1Ij1ot60HU NOXWRIN4wmP3a8J247ml3rXXYQrXXIH2g09LvEZD3Fp1G/iDVsqw+ppw+jRIqdW0iJV6ReqSGlf0/ ZYqF49k5A2q6JRyJ5FisXhoy2BcXEjdzr2bO8A6PC9xV5oJyx60IesnNhJWq+FR/3aAE=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [ovmf test] 184892: all pass - PUSHED X-Osstest-Versions-This: ovmf=1ae5bee967bffcd6dbbabca913ea3c65d8f09c76 X-Osstest-Versions-That: ovmf=3775122ede395d934198ffdb0c173875a5e94c00 From: osstest service owner Date: Mon, 04 Mar 2024 13:01:17 +0000 flight 184892 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/184892/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 1ae5bee967bffcd6dbbabca913ea3c65d8f09c76 baseline version: ovmf 3775122ede395d934198ffdb0c173875a5e94c00 Last test of basis 184889 2024-03-04 07:41:17 Z 0 days Testing same since 184892 2024-03-04 10:11:18 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Ard Biesheuvel Gua Guo Himanshu Sharma 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-pvops pass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git 3775122ede..1ae5bee967 1ae5bee967bffcd6dbbabca913ea3c65d8f09c76 -> xen-tested-master From xen-devel-bounces@lists.xenproject.org Mon Mar 04 13:26:01 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 13:26:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688402.1072438 (Exim 4.92) (envelope-from ) id 1rh8KD-0004ay-DM; Mon, 04 Mar 2024 13:25:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688402.1072438; Mon, 04 Mar 2024 13:25:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh8KD-0004ar-Ae; Mon, 04 Mar 2024 13:25:49 +0000 Received: by outflank-mailman (input) for mailman id 688402; Mon, 04 Mar 2024 13:25:48 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh8KC-0004al-HC for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 13:25:48 +0000 Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [2a00:1450:4864:20::634]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id b5e14cb7-da2a-11ee-afda-a90da7624cb6; Mon, 04 Mar 2024 14:25:47 +0100 (CET) Received: by mail-ej1-x634.google.com with SMTP id a640c23a62f3a-a449c5411e1so377288766b.1 for ; Mon, 04 Mar 2024 05:25:47 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ld1-20020a170906f94100b00a451e507cfcsm1681285ejb.52.2024.03.04.05.25.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Mar 2024 05:25:46 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b5e14cb7-da2a-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709558746; x=1710163546; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=RBRkDZl/hRPgm+MdfM2Cf9hQXBSzf/1JP8gvjIGtFYY=; b=Zlmq21H4RSK43407xQR62leZSjDnA1iQe/MhPGxvkdD53Whbk5UyxG0VK+w2c78XQX AvOApAFjV5iMGpZtqHUCRndvWvyHYUc8Os0+MA6PFmYco5y1cmXmV/LorCWPjwPMC4i/ NgoMJ4sFv+y/rKNWRYMTKsxdoqH6mtsN5scEfVVxJJ8bpM7RTZMX81oQ9eLkC853O6sq z26LI1uPV50SlW5/CPiAZBcCHvecfvamDLUuF/yfrZP3J82J/kRSef6lODGJ5lxk3YsG dPaEsmF1Vwl5Bnk4LfSzjitSFDZ3hIL+idW2fiBj+AIeM2FaBtSiiLtz/y3tmAQDwu9O v1/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709558746; x=1710163546; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=RBRkDZl/hRPgm+MdfM2Cf9hQXBSzf/1JP8gvjIGtFYY=; b=X2qWJoF4Qv3nFztqF3W6sEyLcIR5nR6qlVm7nOjKF+yn7mQPzlRg1rl9kM6l7Y9GFc iVEj//pCk3Il0jzASXuWAAcLE8PwMJVLPo7Io1EGf+dbW3sGPN8wYVSrooa70ipSeDrN /I6tYMuLMlOjWeKCJOwiKKqDlkZ2U6evpg/d1X9z4ykPtr2bKOJ34B+pesPLz5FAyenU 7vXvldCLRPMV68LWWij8ZUevyZpJ8dwGdq4mF684BTLYLM0OBmMZGJYCZCfaRpVglV5d b9NIc/Wxa+DktoIQf4PM/T5bASxeQAsSQASiMqksTSkvH/iWKs2vUKfeDXocpx9S5Xla QP5Q== X-Gm-Message-State: AOJu0YwJz93sr/W7fdtyqTuGHdQ6TXIknvCMeZsdSTPAZmQuRqzthuMD YQg5je4FXV5r9sOaML5B/L1egGDyniOmyZftA2x87cVCARGLq7hZW5K3yMrk0w== X-Google-Smtp-Source: AGHT+IGiN48i6QsPxuG/DmaaqxhEzgLW5tbYV/M8xAU5FI+8xLs3Cuk+VK0jSoYu2CtDa+NpIKS1Cw== X-Received: by 2002:a17:906:f355:b0:a3e:c738:afa2 with SMTP id hg21-20020a170906f35500b00a3ec738afa2mr6649775ejb.76.1709558746586; Mon, 04 Mar 2024 05:25:46 -0800 (PST) Message-ID: <06cce36e-5936-4374-9b56-1cb166c2b8b7@suse.com> Date: Mon, 4 Mar 2024 14:25:45 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] hvmloader/PCI: skip huge BARs in certain calculations Content-Language: en-US To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Wei Liu , Neowutran References: <090d572c-5196-46b2-9d6b-741b7cb66d97@suse.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 04.03.2024 11:02, Roger Pau Monné wrote: > On Mon, Mar 04, 2024 at 08:32:22AM +0100, Jan Beulich wrote: >> BARs of size 2Gb and up can't possibly fit below 4Gb: Both the bottom of >> the lower 2Gb range and the top of the higher 2Gb range have special >> purpose. Don't even have them influence whether to (perhaps) relocate >> low RAM. > > Here you mention 2Gb BARs, yet the code below sets the maximum BAR > size supported below 4Gb to 1Gb. Hmm, I'm puzzled: There are no other BAR sizes between 1Gb and 2Gb. Anything up to 1Gb continues to work as is, while everything 2Gb and up has behavior changed. >> --- a/tools/firmware/hvmloader/pci.c >> +++ b/tools/firmware/hvmloader/pci.c >> @@ -33,6 +33,13 @@ uint32_t pci_mem_start = HVM_BELOW_4G_MM >> const uint32_t pci_mem_end = RESERVED_MEMBASE; >> uint64_t pci_hi_mem_start = 0, pci_hi_mem_end = 0; >> >> +/* >> + * BARs larger than this value are put in 64-bit space unconditionally. That >> + * is, such BARs also don't play into the determination of how big the lowmem >> + * MMIO hole needs to be. >> + */ >> +#define HUGE_BAR_THRESH GB(1) > > I would be fine with defining this to an even lower number, like > 256Mb, as to avoid as much as possible memory relocation in order to > make the MMIO hole bigger. As suggested in a post-commit-message remark, the main question then is how to justify this. >> @@ -367,7 +376,7 @@ void pci_setup(void) >> pci_mem_start = hvm_info->low_mem_pgend << PAGE_SHIFT; >> } >> >> - if ( mmio_total > (pci_mem_end - pci_mem_start) ) >> + if ( mmio_total > (pci_mem_end - pci_mem_start) || bar64_relocate ) >> { >> printf("Low MMIO hole not large enough for all devices," >> " relocating some BARs to 64-bit\n"); > > Is the above message now accurate? Given the current code the low > MMIO could be expanded up to 2Gb, yet BAR relocation will happen > unconditionally once a 1Gb BAR is found. Well, "all" may not be quite accurate anymore, yet would making it e.g. "all applicable" really much more meaningful? >> @@ -446,8 +455,9 @@ void pci_setup(void) >> * the code here assumes it to be.) >> * Should either of those two conditions change, this code will break. >> */ >> - using_64bar = bars[i].is_64bar && bar64_relocate >> - && (mmio_total > (mem_resource.max - mem_resource.base)); >> + using_64bar = bars[i].is_64bar && bar64_relocate && >> + (mmio_total > (mem_resource.max - mem_resource.base) || >> + bar_sz > HUGE_BAR_THRESH); >> bar_data = pci_readl(devfn, bar_reg); >> >> if ( (bar_data & PCI_BASE_ADDRESS_SPACE) == >> @@ -467,7 +477,8 @@ void pci_setup(void) >> resource = &mem_resource; >> bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK; >> } >> - mmio_total -= bar_sz; >> + if ( bar_sz <= HUGE_BAR_THRESH ) >> + mmio_total -= bar_sz; > > I'm missing the part where hvmloader notifies QEMU of the possibly > expanded base and size memory PCI MMIO regions, so that those are > reflected in the PCI root complex registers? I don't understand this comment: I'm not changing the interaction with qemu at all. Whatever the new calculation it'll be communicated to qemu just as before. > Overall I think we could simplify the code by having a hardcoded 1Gb > PCI MMIO hole below 4Gb, fill it with all the 32bit BARs and > (re)locate all 64bit BARs above 4Gb (not that I'm requesting you to do > it here). I'm afraid that would not work very well with OSes which aren't 64-bit BAR / PA aware (first and foremost non-PAE 32-bit ones). Iirc that's the reason why it wasn't done like you suggest back at the time. Jan From xen-devel-bounces@lists.xenproject.org Mon Mar 04 13:27:06 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 13:27:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688404.1072449 (Exim 4.92) (envelope-from ) id 1rh8LR-00055q-PU; Mon, 04 Mar 2024 13:27:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688404.1072449; Mon, 04 Mar 2024 13:27:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh8LR-00055j-Kt; Mon, 04 Mar 2024 13:27:05 +0000 Received: by outflank-mailman (input) for mailman id 688404; Mon, 04 Mar 2024 13:27:04 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh8LQ-00055b-AI for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 13:27:04 +0000 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id e1c22e16-da2a-11ee-afda-a90da7624cb6; Mon, 04 Mar 2024 14:27:02 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 3ED33CE130A; Mon, 4 Mar 2024 13:26:57 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E96F3C433C7; Mon, 4 Mar 2024 13:26:55 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e1c22e16-da2a-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1709558816; bh=+I0soG2y9wOLdzgs+iOEFQHNkm2pStAlIL7zVcgMi74=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=oMzp99FFoYxE/vOBF28I+Id1o/+jfqk2QKtf8z+qedFCDQo44dR1zoMcm4EHWUsN2 9S7n+Qb7qUQaJTViEMqp0ZTD1looj6HK046a++qWpRN5hfjMkaubXIkZT/MmcI6S8X vdbb37LSe6aZm0VVDWGarbOZAntFjiFfFUm5jW9o= Date: Mon, 4 Mar 2024 14:26:53 +0100 From: Greg KH To: Andrew Panyakin Cc: stable@vger.kernel.org, boris.ostrovsky@oracle.com, jgross@suse.com, sstabellini@kernel.org, oleksandr_tyshchenko@epam.com, jgrall@amazon.com, sashal@kernel.org, jeremy.fitzhardinge@citrix.com, konrad.wilk@oracle.com, xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, benh@amazon.com, mheyne@amazon.de Subject: Re: [PATCH 5.10] xen/events: close evtchn after mapping cleanup Message-ID: <2024030433-legacy-unrivaled-f5fc@gregkh> References: <20240302160357.GA2232656@uc3ecf78c6baf56.ant.amazon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240302160357.GA2232656@uc3ecf78c6baf56.ant.amazon.com> On Sat, Mar 02, 2024 at 08:03:57AM -0800, Andrew Panyakin wrote: > From: Maximilian Heyne > > Commit fa765c4b4aed2d64266b694520ecb025c862c5a9 upstream > > shutdown_pirq and startup_pirq are not taking the > irq_mapping_update_lock because they can't due to lock inversion. Both > are called with the irq_desc->lock being taking. The lock order, > however, is first irq_mapping_update_lock and then irq_desc->lock. > > This opens multiple races: > - shutdown_pirq can be interrupted by a function that allocates an event > channel: > > CPU0 CPU1 > shutdown_pirq { > xen_evtchn_close(e) > __startup_pirq { > EVTCHNOP_bind_pirq > -> returns just freed evtchn e > set_evtchn_to_irq(e, irq) > } > xen_irq_info_cleanup() { > set_evtchn_to_irq(e, -1) > } > } > > Assume here event channel e refers here to the same event channel > number. > After this race the evtchn_to_irq mapping for e is invalid (-1). > > - __startup_pirq races with __unbind_from_irq in a similar way. Because > __startup_pirq doesn't take irq_mapping_update_lock it can grab the > evtchn that __unbind_from_irq is currently freeing and cleaning up. In > this case even though the event channel is allocated, its mapping can > be unset in evtchn_to_irq. > > The fix is to first cleanup the mappings and then close the event > channel. In this way, when an event channel gets allocated it's > potential previous evtchn_to_irq mappings are guaranteed to be unset already. > This is also the reverse order of the allocation where first the event > channel is allocated and then the mappings are setup. > > On a 5.10 kernel prior to commit 3fcdaf3d7634 ("xen/events: modify internal > [un]bind interfaces"), we hit a BUG like the following during probing of NVMe > devices. The issue is that during nvme_setup_io_queues, pci_free_irq > is called for every device which results in a call to shutdown_pirq. > With many nvme devices it's therefore likely to hit this race during > boot because there will be multiple calls to shutdown_pirq and > startup_pirq are running potentially in parallel. > > ------------[ cut here ]------------ > blkfront: xvda: barrier or flush: disabled; persistent grants: enabled; indirect descriptors: enabled; bounce buffer: enabled > kernel BUG at drivers/xen/events/events_base.c:499! > invalid opcode: 0000 [#1] SMP PTI > CPU: 44 PID: 375 Comm: kworker/u257:23 Not tainted 5.10.201-191.748.amzn2.x86_64 #1 > Hardware name: Xen HVM domU, BIOS 4.11.amazon 08/24/2006 > Workqueue: nvme-reset-wq nvme_reset_work > RIP: 0010:bind_evtchn_to_cpu+0xdf/0xf0 > Code: 5d 41 5e c3 cc cc cc cc 44 89 f7 e8 2b 55 ad ff 49 89 c5 48 85 c0 0f 84 64 ff ff ff 4c 8b 68 30 41 83 fe ff 0f 85 60 ff ff ff <0f> 0b 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 0f 1f 44 00 00 > RSP: 0000:ffffc9000d533b08 EFLAGS: 00010046 > RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006 > RDX: 0000000000000028 RSI: 00000000ffffffff RDI: 00000000ffffffff > RBP: ffff888107419680 R08: 0000000000000000 R09: ffffffff82d72b00 > R10: 0000000000000000 R11: 0000000000000000 R12: 00000000000001ed > R13: 0000000000000000 R14: 00000000ffffffff R15: 0000000000000002 > FS: 0000000000000000(0000) GS:ffff88bc8b500000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: 0000000000000000 CR3: 0000000002610001 CR4: 00000000001706e0 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 > Call Trace: > ? show_trace_log_lvl+0x1c1/0x2d9 > ? show_trace_log_lvl+0x1c1/0x2d9 > ? set_affinity_irq+0xdc/0x1c0 > ? __die_body.cold+0x8/0xd > ? die+0x2b/0x50 > ? do_trap+0x90/0x110 > ? bind_evtchn_to_cpu+0xdf/0xf0 > ? do_error_trap+0x65/0x80 > ? bind_evtchn_to_cpu+0xdf/0xf0 > ? exc_invalid_op+0x4e/0x70 > ? bind_evtchn_to_cpu+0xdf/0xf0 > ? asm_exc_invalid_op+0x12/0x20 > ? bind_evtchn_to_cpu+0xdf/0xf0 > ? bind_evtchn_to_cpu+0xc5/0xf0 > set_affinity_irq+0xdc/0x1c0 > irq_do_set_affinity+0x1d7/0x1f0 > irq_setup_affinity+0xd6/0x1a0 > irq_startup+0x8a/0xf0 > __setup_irq+0x639/0x6d0 > ? nvme_suspend+0x150/0x150 > request_threaded_irq+0x10c/0x180 > ? nvme_suspend+0x150/0x150 > pci_request_irq+0xa8/0xf0 > ? __blk_mq_free_request+0x74/0xa0 > queue_request_irq+0x6f/0x80 > nvme_create_queue+0x1af/0x200 > nvme_create_io_queues+0xbd/0xf0 > nvme_setup_io_queues+0x246/0x320 > ? nvme_irq_check+0x30/0x30 > nvme_reset_work+0x1c8/0x400 > process_one_work+0x1b0/0x350 > worker_thread+0x49/0x310 > ? process_one_work+0x350/0x350 > kthread+0x11b/0x140 > ? __kthread_bind_mask+0x60/0x60 > ret_from_fork+0x22/0x30 > Modules linked in: > ---[ end trace a11715de1eee1873 ]--- > > Fixes: d46a78b05c0e ("xen: implement pirq type event channels") > Cc: stable@vger.kernel.org > Co-debugged-by: Andrew Panyakin > Signed-off-by: Maximilian Heyne > [apanyaki: backport to v5.10-stable] > Signed-off-by: Andrew Paniakin > --- > Compare to upstream patch this one does not have close_evtchn flag > because there is no need to handle static event channels. > This feature was added only in 58f6259b7a08f ("xen/evtchn: Introduce new > IOCTL to bind static evtchn") Where is the 5.15.y version of this commit? We have to have that before we can take a 5.10.y version, right? thanks, greg k-h From xen-devel-bounces@lists.xenproject.org Mon Mar 04 13:28:06 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 13:28:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688407.1072458 (Exim 4.92) (envelope-from ) id 1rh8MQ-0005gb-6W; Mon, 04 Mar 2024 13:28:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688407.1072458; Mon, 04 Mar 2024 13:28:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh8MQ-0005gU-2j; Mon, 04 Mar 2024 13:28:06 +0000 Received: by outflank-mailman (input) for mailman id 688407; Mon, 04 Mar 2024 13:28:05 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh8MP-0005gE-3g; Mon, 04 Mar 2024 13:28:05 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh8MP-0007iM-1D; Mon, 04 Mar 2024 13:28:05 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh8MO-00044C-N0; Mon, 04 Mar 2024 13:28:04 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rh8MO-0000sl-MO; Mon, 04 Mar 2024 13:28:04 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=eGrgvwAd9mQ+7QUYDeqI9aMoCUWko0V08xchJg7r5GE=; b=CvQtR4qvzK7VTG6XsmjTFAzYYj CwwEJ7Cyh1MZSyyIiCq71FKC0tr13du8A+qkrHMPPw/oOjFJHtKzfqhtsAbDRnPKrQzPUR7oITThN 4q6bOvp6exKDcJwuRstUg5GEYMu3Ls0SiEWZ599hdv6WB0deTYyUBbpETbyM/ehVg22M=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 184891: tolerable all pass - PUSHED X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=fc84b4a5a37b9250d87ef63983b48e1953bba6d1 X-Osstest-Versions-That: xen=856664f774bd5b66301c5f9022126b61b8cb492d From: osstest service owner Date: Mon, 04 Mar 2024 13:28:04 +0000 flight 184891 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/184891/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-check fail never pass version targeted for testing: xen fc84b4a5a37b9250d87ef63983b48e1953bba6d1 baseline version: xen 856664f774bd5b66301c5f9022126b61b8cb492d Last test of basis 184839 2024-03-02 02:00:28 Z 2 days Testing same since 184891 2024-03-04 10:02:19 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Jan Beulich Julien Grall Nicola Vetrini 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-amd64 pass 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 856664f774..fc84b4a5a3 fc84b4a5a37b9250d87ef63983b48e1953bba6d1 -> smoke From xen-devel-bounces@lists.xenproject.org Mon Mar 04 13:30:54 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 13:30:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688412.1072467 (Exim 4.92) (envelope-from ) id 1rh8P5-0007jg-II; Mon, 04 Mar 2024 13:30:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688412.1072467; Mon, 04 Mar 2024 13:30:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh8P5-0007jZ-FU; Mon, 04 Mar 2024 13:30:51 +0000 Received: by outflank-mailman (input) for mailman id 688412; Mon, 04 Mar 2024 13:30:50 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh8P4-0007jT-RW for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 13:30:50 +0000 Received: from mail-oa1-x30.google.com (mail-oa1-x30.google.com [2001:4860:4864:20::30]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 6916347c-da2b-11ee-a1ee-f123f15fe8a2; Mon, 04 Mar 2024 14:30:48 +0100 (CET) Received: by mail-oa1-x30.google.com with SMTP id 586e51a60fabf-220461b7597so2737464fac.3 for ; Mon, 04 Mar 2024 05:30:48 -0800 (PST) Received: from [10.80.67.149] (default-46-102-197-194.interdsl.co.uk. [46.102.197.194]) by smtp.gmail.com with ESMTPSA id 19-20020a05620a04d300b00787ad5ca70fsm4346946qks.122.2024.03.04.05.30.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Mar 2024 05:30:46 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6916347c-da2b-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709559047; x=1710163847; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=fyC0XW1fp4YI+DuazPFfvuL/5W60y9CbXjWPM1zsBMA=; b=HCiSVmdtjop5DtCJsJMIArYNCyBLtH3TFvzRJayDZwqjXisl9/aR09LwoGzfaW+eYM OrCxxAZpgDgbwj66CE1aQkg0uFj3CPjqJ56lvbkvepTpTQYquyklM8pPFmtteWb7VTon +G0lIF+qIZZ+T5Q3hZ9X3FjJ6dOvzuiQc+op0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709559047; x=1710163847; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=fyC0XW1fp4YI+DuazPFfvuL/5W60y9CbXjWPM1zsBMA=; b=l0bGQfEjcttbneyKiqT4VGxzVhpZC1C1lz2zM666sopUkpYFr+f4JFWBsuhMFiiNov Ihk60Mv9Tve1DC03AM9PPJrMTc2fJ0cJ+WZrTkxc4JfOON3K6l7qY4aJSinPxie0va1y B4+epu3hl0ePL0qhRnAK3naHiMxoJQ9E4GrC9HAT1pxp/l66YH4shtrjNlFrCXjVZjdD YZ2hrsfcmtnEA8QRClHQKHFEEKKFGZtEGqUy1pWwV8Glqs7p3/zQVFFBJmCYEzfFrLVM wIvEe4MfyxczdsP0dl5Q9JGQVBAp4d3Ae7t2bpmsLLUVTkPWmvoUGm7Hi8H85b7EuQzC zPiA== X-Forwarded-Encrypted: i=1; AJvYcCXliloKQCcJQE19M5YzqNhnto7yx34eex3ANmNtEBrc2lHEthjKzoXFccnHsgBtLUwiMMLH7wKzIermoB4bP/vmBK5GE/QSBZ14owHTDqo= X-Gm-Message-State: AOJu0YyAZpJoNwgd/XpQ68dixevGd8gmZTYqVTDgr/bhctM1uozFHQ6C 2JwHRjywrfIz18lBo+A5PvdlNn1eMF50K+l82FLsQdD/TgQN1yUzMp3RK8Jfelo= X-Google-Smtp-Source: AGHT+IHHQEyM1lYZfTXVX0FZ8qRt4NcNLHz0Q+3p62heijXliHZUGldIGnvL+kNgqhTaZ+TRzbzeDQ== X-Received: by 2002:a05:6870:9d1b:b0:21e:70fd:f86 with SMTP id pp27-20020a0568709d1b00b0021e70fd0f86mr12151947oab.33.1709559047171; Mon, 04 Mar 2024 05:30:47 -0800 (PST) Message-ID: Date: Mon, 4 Mar 2024 13:30:44 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/cpu-policy: Fix visibility of HTT/CMP_LEGACY in max policies Content-Language: en-GB To: Jan Beulich Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu , Xen-devel References: <20240301112829.2657865-1-andrew.cooper3@citrix.com> <0751a4ac-4e3b-47e4-8727-f3dd4610d446@suse.com> From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <0751a4ac-4e3b-47e4-8727-f3dd4610d446@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 04/03/2024 8:42 am, Jan Beulich wrote: > On 01.03.2024 12:28, Andrew Cooper wrote: >> --- a/xen/arch/x86/cpu-policy.c >> +++ b/xen/arch/x86/cpu-policy.c >> @@ -464,6 +464,16 @@ static void __init guest_common_max_feature_adjustments(uint32_t *fs) >> raw_cpu_policy.feat.clwb ) >> __set_bit(X86_FEATURE_CLWB, fs); >> } >> + >> + /* >> + * Topology information inside the guest is entirely at the toolstack's >> + * disgression, and bears no relationship to the host we're running on. >> + * >> + * HTT identifies p->basic.lppp as valid >> + * CMP_LEGACY identifies p->extd.nc as valid >> + */ >> + __set_bit(X86_FEATURE_HTT, fs); >> + __set_bit(X86_FEATURE_CMP_LEGACY, fs); >> } >> >> static void __init guest_common_default_feature_adjustments(uint32_t *fs) >> @@ -514,6 +524,18 @@ static void __init guest_common_default_feature_adjustments(uint32_t *fs) >> __clear_bit(X86_FEATURE_CLWB, fs); >> } >> >> + /* >> + * Topology information is at the toolstack's discretion so these are >> + * unconditionally set in max, but pick a default which matches the host. >> + */ >> + __clear_bit(X86_FEATURE_HTT, fs); >> + if ( cpu_has_htt ) >> + __set_bit(X86_FEATURE_HTT, fs); >> + >> + __clear_bit(X86_FEATURE_CMP_LEGACY, fs); >> + if ( cpu_has_cmp_legacy ) >> + __set_bit(X86_FEATURE_CMP_LEGACY, fs); > When running on a host with the respective bit clear, won't this break > (at least older) Linux'es logic? Iirc the unconditional setting of at > least HTT was tied to the unconditional multiplying by 2 of the vCPU ID > to derive the (fake) APIC ID. This patch doesn't change the default at all. All it does is expose (properly) in the max policy what Xen would tolerate the toolstack doing blindly. If there are problems in certain configurations, then they continue to be problems. Although I'll note that the unconditional multiplying by 2 was never about hyper-threading - Alejandro did some archaeology and found out that it was an LAPIC vs IOAPIC error in vmxloader.  The connection to HT has just been bad guesswork since. ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Mar 04 13:31:56 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 13:31:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688417.1072478 (Exim 4.92) (envelope-from ) id 1rh8Q4-0008Ey-RO; Mon, 04 Mar 2024 13:31:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688417.1072478; Mon, 04 Mar 2024 13:31:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh8Q4-0008Er-Od; Mon, 04 Mar 2024 13:31:52 +0000 Received: by outflank-mailman (input) for mailman id 688417; Mon, 04 Mar 2024 13:31:51 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh8Q3-00089p-QS for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 13:31:51 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 8e6a791e-da2b-11ee-afda-a90da7624cb6; Mon, 04 Mar 2024 14:31:50 +0100 (CET) Received: from [10.253.49.69] (unknown [160.78.253.140]) by support.bugseng.com (Postfix) with ESMTPSA id 603E94EE0737; Mon, 4 Mar 2024 14:31:49 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8e6a791e-da2b-11ee-afda-a90da7624cb6 Message-ID: Date: Mon, 4 Mar 2024 14:31:48 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/3] docs/misra/rules.rst: add rule 5.5 To: Jan Beulich , Stefano Stabellini Cc: andrew.cooper3@citrix.com, george.dunlap@citrix.com, julien@xen.org, bertrand.marquis@arm.com, roger.pau@citrix.com, xen-devel@lists.xenproject.org, Stefano Stabellini , roberto.bagnara@bugseng.com References: <20240213223334.3693410-2-stefano.stabellini@amd.com> <50719397-b053-43e1-9cf7-cc9eae9098ed@suse.com> <40b7465f-4966-43c7-8db3-e28a6cc48445@bugseng.com> <2da73259-a86e-4a13-9fd4-4217372f4b76@suse.com> <3632611e-61ff-455a-9cc1-990a1f663d83@bugseng.com> Content-Language: en-US, it From: Federico Serafini Organization: BUGSENG srl In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 01/03/24 09:06, Jan Beulich wrote: > On 01.03.2024 00:28, Stefano Stabellini wrote: >> On Wed, 14 Feb 2024, Federico Serafini wrote: >>> On 14/02/24 14:15, Jan Beulich wrote: >>>> On 14.02.2024 12:27, Federico Serafini wrote: >>>>> On 14/02/24 09:28, Jan Beulich wrote: >>>>>> On 13.02.2024 23:33, Stefano Stabellini wrote: >>>>>>> Signed-off-by: Stefano Stabellini >>>>>>> --- >>>>>>> docs/misra/rules.rst | 6 ++++++ >>>>>>> 1 file changed, 6 insertions(+) >>>>>>> >>>>>>> diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst >>>>>>> index c185366966..931158b354 100644 >>>>>>> --- a/docs/misra/rules.rst >>>>>>> +++ b/docs/misra/rules.rst >>>>>>> @@ -181,6 +181,12 @@ maintainers if you want to suggest a change. >>>>>>> headers (xen/include/public/) are allowed to retain longer >>>>>>> identifiers for backward compatibility. >>>>>>> + * - `Rule 5.5 >>>>>>> `_ >>>>>>> + - Required >>>>>>> + - Identifiers shall be distinct from macro names >>>>>>> + - Clashes between function-like macros and non-callable entities >>>>>>> + are allowed. The pattern #define x x is also allowed. >>>>>> >>>>>> Just for me to know what exactly is covered (hence also a question >>>>>> to Roberto as to [to be] implemented Eclair behavior): Even when >>>>>> the above would be sufficient (and imo better) people frequently >>>>>> write >>>>>> >>>>>> #define a(x, y) b(x, y) >>>>>> >>>>>> which, transformed to the specific case here, would then be >>>>>> >>>>>> #define a(x, y) a(x, y) >>>>>> >>>>>> I'd assume such ought to also be covered, but that's not clear >>>>>> from the spelling above. >>>>> >>>>> I list what happens in some different situations, >>>>> then we can find the right words for the documentation and/or >>>>> refine the configuration: >>>>> >>>>> If you >>>>> #define x x >>>>> and then use `x' as identifier, >>>>> the resulting violation is deviated (allowed pattern). >>>>> >>>>> If you >>>>> #define a(x, y) a(x, y) >>>>> and then use `a' as identifier for a non-callable entity, >>>>> the resulting violation is deviated (no clash with non-callable >>>>> entities). >>>>> If you use identifier `a' for a callable entity, the resulting violation >>>>> is reported: the allowed pattern covers only macros expanding to their >>>>> own name, in this case the macro name is considered to be >>>>> `a' only, not a(x, y). >>>>> >>>>> If you >>>>> #define a(x, y) b(x, y) >>>>> and then use `a' as identifier for a non-callable entity, >>>>> the resulting violation is deviated (no clash with non-callable >>>>> entities). >>>> >>>> I'm afraid I don't see what violation there is in this case, to >>>> deviate. As a result I'm also not sure I correctly understand the >>>> rest of your reply. >>> >>> #define a(x, y) b(x, y) >>> >>> int a; // Violation of Rule 5.5. >>> >>> The macro name `a' that exist before the preprocessing phase, >>> still exists after the preprocessing phase as identifier for the integer >>> variable and this is a violation. >>> >>>>> If you use `a' as identifier for a callable entity, >>>>> this is not a violation because after the preprocessing phase, >>>>> identifier `a' no longer exists. >>> I correct myself: >>> if you use `a' as identifier for a *function*, >>> it is not a violation because after the preprocessing phase >>> the identifier `a' no longer exists, for example: >>> >>> #define a(x, y) b(x, y) >>> >>> void a(int x, int y); // Ok. >> >> Federico, do you have a better wording suggestion for this rule? >> >> Jan, any further requests here? What would you like to see as next step? > > A more concise wording proposal would probably help. What do you think about: diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst index 1e134ccebc..a975b9a85f 100644 --- a/docs/misra/rules.rst +++ b/docs/misra/rules.rst @@ -181,6 +181,13 @@ maintainers if you want to suggest a change. headers (xen/include/public/) are allowed to retain longer identifiers for backward compatibility. + * - `Rule 5.5 `_ + - Required + - Identifiers shall be distinct from macro names + - Macros expanding to their own name are allowed (e.g., #define x x). + Clashes between names of function-like macros and identifiers of + non-callable entities are allowed. + * - `Rule 5.6 `_ - Required - A typedef name shall be a unique identifier -- Federico Serafini, M.Sc. Software Engineer, BUGSENG (http://bugseng.com) From xen-devel-bounces@lists.xenproject.org Mon Mar 04 14:17:15 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 14:17:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688424.1072488 (Exim 4.92) (envelope-from ) id 1rh97t-0006re-0g; Mon, 04 Mar 2024 14:17:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688424.1072488; Mon, 04 Mar 2024 14:17:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh97s-0006rX-TA; Mon, 04 Mar 2024 14:17:08 +0000 Received: by outflank-mailman (input) for mailman id 688424; Mon, 04 Mar 2024 14:17:07 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rh97r-0006rP-PS for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 14:17:07 +0000 Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [2a00:1450:4864:20::135]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id e12d72db-da31-11ee-afda-a90da7624cb6; Mon, 04 Mar 2024 15:17:06 +0100 (CET) Received: by mail-lf1-x135.google.com with SMTP id 2adb3069b0e04-512f54fc2dbso3721898e87.1 for ; Mon, 04 Mar 2024 06:17:06 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id n7-20020a05640206c700b00566757b30fbsm4637729edy.45.2024.03.04.06.17.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Mar 2024 06:17:05 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e12d72db-da31-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709561826; x=1710166626; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=a1jmLs6ai3nZb2yvPutDtB57Up6Vs+RvcmBcnNXsSUM=; b=L439reIiPcdID4HqCrPryqVB11XdOqMtG9V6+lp65zH0qLcd3fnAuoEiFgYJbIH7MA EHbVNy747K2CVW004cx+Oj6TYD4DIKuWU0HNgBay+HSKGubm4jWQepUzl6YIJzJiwflh unhw2KfxN0NXfIC5op0vOJJGXpILDsHQ1HeQ4TAma//e3n0kLTMou2J6GZ36o6hlXgKW GOR2E01zWlKDGR8E5dkPzIcjO+9lT+ZzATdzubFTh5ljGD8EezrIDF8N8pmxvLLfmxrf Sob58pX45MXlNVT1vqbYvk7gNzpVdEtbfJwX6TvdTlItI8n9NQiMky744M4U2JWY4W4U ofuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709561826; x=1710166626; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=a1jmLs6ai3nZb2yvPutDtB57Up6Vs+RvcmBcnNXsSUM=; b=teuYMF+UU2QL1UI0X/Ic2w+DLO++WV/VDwayWQfoIWj5BZDzB+fjcBBaTQ6xKTr71E ffaj2jsL612ljaVHuEVQHUM2uVjzEyx5/lZu1oUguzcDMzoUX1iyEU/+0bmNneh++lIS 0UCog1+hmajcVEfe2sc4+Tw/xARnh+7KHxueoJD2VKcjD4kvyh2/YGaq7GYF6N8Gtk5q jN/wEseckD6+Lgw7m6gsX6+b1Hy1rafpm4CHGdMiDG9bjwg1ze8HQjrogVL1HnC6tciW /vVv4+m27f768V4t7lLRkf0xAkUiVPLAtOmexyzB/ajC+p3MsTvr2CFD62PS17btA9uf W7hw== X-Forwarded-Encrypted: i=1; AJvYcCVkGkxPhNvnA+Mx1iV8+3ym/2hhc1XcqnhWAde3jeGv5nhMOrDKxoGzQPu2eWyb9HvK4lWB6pGXWjSmBfzEhObwHJAeWGWEfhuAzz2hxbQ= X-Gm-Message-State: AOJu0Yzsvf1rUflbaD+BXXoSv+Opx7YBKkXMtMm599cqHgzgrpmzQHLo +9H5aoWhSlSYXZnoSJvD5+NpoJRqpnr3Vx0Nl+QNR2D+G/1y+tauOHGltK8h6g== X-Google-Smtp-Source: AGHT+IG56tRR43+eB4kBy1QL4zeGVFpxV+ujT+uOM6He/XFckQNl3ZMmrDk3vgaV6jUi4Y/JKXbknA== X-Received: by 2002:ac2:5f99:0:b0:512:ed82:fd6f with SMTP id r25-20020ac25f99000000b00512ed82fd6fmr6337681lfe.60.1709561825668; Mon, 04 Mar 2024 06:17:05 -0800 (PST) Message-ID: <7747cb81-8fdb-4a5f-bfd1-c6c9bdb6039a@suse.com> Date: Mon, 4 Mar 2024 15:17:03 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/3] docs/misra/rules.rst: add rule 5.5 Content-Language: en-US To: Federico Serafini Cc: andrew.cooper3@citrix.com, george.dunlap@citrix.com, julien@xen.org, bertrand.marquis@arm.com, roger.pau@citrix.com, xen-devel@lists.xenproject.org, Stefano Stabellini , roberto.bagnara@bugseng.com, Stefano Stabellini References: <20240213223334.3693410-2-stefano.stabellini@amd.com> <50719397-b053-43e1-9cf7-cc9eae9098ed@suse.com> <40b7465f-4966-43c7-8db3-e28a6cc48445@bugseng.com> <2da73259-a86e-4a13-9fd4-4217372f4b76@suse.com> <3632611e-61ff-455a-9cc1-990a1f663d83@bugseng.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 04.03.2024 14:31, Federico Serafini wrote: > On 01/03/24 09:06, Jan Beulich wrote: >> On 01.03.2024 00:28, Stefano Stabellini wrote: >>> On Wed, 14 Feb 2024, Federico Serafini wrote: >>>> On 14/02/24 14:15, Jan Beulich wrote: >>>>> On 14.02.2024 12:27, Federico Serafini wrote: >>>>>> On 14/02/24 09:28, Jan Beulich wrote: >>>>>>> On 13.02.2024 23:33, Stefano Stabellini wrote: >>>>>>>> Signed-off-by: Stefano Stabellini >>>>>>>> --- >>>>>>>> docs/misra/rules.rst | 6 ++++++ >>>>>>>> 1 file changed, 6 insertions(+) >>>>>>>> >>>>>>>> diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst >>>>>>>> index c185366966..931158b354 100644 >>>>>>>> --- a/docs/misra/rules.rst >>>>>>>> +++ b/docs/misra/rules.rst >>>>>>>> @@ -181,6 +181,12 @@ maintainers if you want to suggest a change. >>>>>>>> headers (xen/include/public/) are allowed to retain longer >>>>>>>> identifiers for backward compatibility. >>>>>>>> + * - `Rule 5.5 >>>>>>>> `_ >>>>>>>> + - Required >>>>>>>> + - Identifiers shall be distinct from macro names >>>>>>>> + - Clashes between function-like macros and non-callable entities >>>>>>>> + are allowed. The pattern #define x x is also allowed. >>>>>>> >>>>>>> Just for me to know what exactly is covered (hence also a question >>>>>>> to Roberto as to [to be] implemented Eclair behavior): Even when >>>>>>> the above would be sufficient (and imo better) people frequently >>>>>>> write >>>>>>> >>>>>>> #define a(x, y) b(x, y) >>>>>>> >>>>>>> which, transformed to the specific case here, would then be >>>>>>> >>>>>>> #define a(x, y) a(x, y) >>>>>>> >>>>>>> I'd assume such ought to also be covered, but that's not clear >>>>>>> from the spelling above. >>>>>> >>>>>> I list what happens in some different situations, >>>>>> then we can find the right words for the documentation and/or >>>>>> refine the configuration: >>>>>> >>>>>> If you >>>>>> #define x x >>>>>> and then use `x' as identifier, >>>>>> the resulting violation is deviated (allowed pattern). >>>>>> >>>>>> If you >>>>>> #define a(x, y) a(x, y) >>>>>> and then use `a' as identifier for a non-callable entity, >>>>>> the resulting violation is deviated (no clash with non-callable >>>>>> entities). >>>>>> If you use identifier `a' for a callable entity, the resulting violation >>>>>> is reported: the allowed pattern covers only macros expanding to their >>>>>> own name, in this case the macro name is considered to be >>>>>> `a' only, not a(x, y). >>>>>> >>>>>> If you >>>>>> #define a(x, y) b(x, y) >>>>>> and then use `a' as identifier for a non-callable entity, >>>>>> the resulting violation is deviated (no clash with non-callable >>>>>> entities). >>>>> >>>>> I'm afraid I don't see what violation there is in this case, to >>>>> deviate. As a result I'm also not sure I correctly understand the >>>>> rest of your reply. >>>> >>>> #define a(x, y) b(x, y) >>>> >>>> int a; // Violation of Rule 5.5. >>>> >>>> The macro name `a' that exist before the preprocessing phase, >>>> still exists after the preprocessing phase as identifier for the integer >>>> variable and this is a violation. >>>> >>>>>> If you use `a' as identifier for a callable entity, >>>>>> this is not a violation because after the preprocessing phase, >>>>>> identifier `a' no longer exists. >>>> I correct myself: >>>> if you use `a' as identifier for a *function*, >>>> it is not a violation because after the preprocessing phase >>>> the identifier `a' no longer exists, for example: >>>> >>>> #define a(x, y) b(x, y) >>>> >>>> void a(int x, int y); // Ok. >>> >>> Federico, do you have a better wording suggestion for this rule? >>> >>> Jan, any further requests here? What would you like to see as next step? >> >> A more concise wording proposal would probably help. > > What do you think about: > > diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst > index 1e134ccebc..a975b9a85f 100644 > --- a/docs/misra/rules.rst > +++ b/docs/misra/rules.rst > @@ -181,6 +181,13 @@ maintainers if you want to suggest a change. > headers (xen/include/public/) are allowed to retain longer > identifiers for backward compatibility. > > + * - `Rule 5.5 > `_ > + - Required > + - Identifiers shall be distinct from macro names > + - Macros expanding to their own name are allowed (e.g., #define x x). > + Clashes between names of function-like macros and identifiers of > + non-callable entities are allowed. Imo that still leaves open e.g. the #define a(x, y) a(x, y) case: Permitted ("own name") or not permitted ("a" pretty clearly is expected to be a callable entity here, besides being a function-like macro)? Jan From xen-devel-bounces@lists.xenproject.org Mon Mar 04 15:39:26 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 15:39:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688431.1072498 (Exim 4.92) (envelope-from ) id 1rhAPG-0001mT-TC; Mon, 04 Mar 2024 15:39:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688431.1072498; Mon, 04 Mar 2024 15:39:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhAPG-0001mM-Pw; Mon, 04 Mar 2024 15:39:10 +0000 Received: by outflank-mailman (input) for mailman id 688431; Mon, 04 Mar 2024 15:39:10 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhAPG-0001lw-3B for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 15:39:10 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 567e71eb-da3d-11ee-a1ee-f123f15fe8a2; Mon, 04 Mar 2024 16:39:07 +0100 (CET) Received: from [10.253.49.69] (unknown [160.78.253.140]) by support.bugseng.com (Postfix) with ESMTPSA id 775974EE0737; Mon, 4 Mar 2024 16:39:06 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 567e71eb-da3d-11ee-a1ee-f123f15fe8a2 Message-ID: Date: Mon, 4 Mar 2024 16:39:05 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/3] docs/misra/rules.rst: add rule 5.5 Content-Language: en-US, it To: Jan Beulich Cc: andrew.cooper3@citrix.com, george.dunlap@citrix.com, julien@xen.org, bertrand.marquis@arm.com, roger.pau@citrix.com, xen-devel@lists.xenproject.org, Stefano Stabellini , roberto.bagnara@bugseng.com, Stefano Stabellini References: <20240213223334.3693410-2-stefano.stabellini@amd.com> <50719397-b053-43e1-9cf7-cc9eae9098ed@suse.com> <40b7465f-4966-43c7-8db3-e28a6cc48445@bugseng.com> <2da73259-a86e-4a13-9fd4-4217372f4b76@suse.com> <3632611e-61ff-455a-9cc1-990a1f663d83@bugseng.com> <7747cb81-8fdb-4a5f-bfd1-c6c9bdb6039a@suse.com> From: Federico Serafini Organization: BUGSENG srl In-Reply-To: <7747cb81-8fdb-4a5f-bfd1-c6c9bdb6039a@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 04/03/24 15:17, Jan Beulich wrote: > On 04.03.2024 14:31, Federico Serafini wrote: >> On 01/03/24 09:06, Jan Beulich wrote: >>> On 01.03.2024 00:28, Stefano Stabellini wrote: >>>> On Wed, 14 Feb 2024, Federico Serafini wrote: >>>>> On 14/02/24 14:15, Jan Beulich wrote: >>>>>> On 14.02.2024 12:27, Federico Serafini wrote: >>>>>>> On 14/02/24 09:28, Jan Beulich wrote: >>>>>>>> On 13.02.2024 23:33, Stefano Stabellini wrote: >>>>>>>>> Signed-off-by: Stefano Stabellini >>>>>>>>> --- >>>>>>>>> docs/misra/rules.rst | 6 ++++++ >>>>>>>>> 1 file changed, 6 insertions(+) >>>>>>>>> >>>>>>>>> diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst >>>>>>>>> index c185366966..931158b354 100644 >>>>>>>>> --- a/docs/misra/rules.rst >>>>>>>>> +++ b/docs/misra/rules.rst >>>>>>>>> @@ -181,6 +181,12 @@ maintainers if you want to suggest a change. >>>>>>>>> headers (xen/include/public/) are allowed to retain longer >>>>>>>>> identifiers for backward compatibility. >>>>>>>>> + * - `Rule 5.5 >>>>>>>>> `_ >>>>>>>>> + - Required >>>>>>>>> + - Identifiers shall be distinct from macro names >>>>>>>>> + - Clashes between function-like macros and non-callable entities >>>>>>>>> + are allowed. The pattern #define x x is also allowed. >>>>>>>> >>>>>>>> Just for me to know what exactly is covered (hence also a question >>>>>>>> to Roberto as to [to be] implemented Eclair behavior): Even when >>>>>>>> the above would be sufficient (and imo better) people frequently >>>>>>>> write >>>>>>>> >>>>>>>> #define a(x, y) b(x, y) >>>>>>>> >>>>>>>> which, transformed to the specific case here, would then be >>>>>>>> >>>>>>>> #define a(x, y) a(x, y) >>>>>>>> >>>>>>>> I'd assume such ought to also be covered, but that's not clear >>>>>>>> from the spelling above. >>>>>>> >>>>>>> I list what happens in some different situations, >>>>>>> then we can find the right words for the documentation and/or >>>>>>> refine the configuration: >>>>>>> >>>>>>> If you >>>>>>> #define x x >>>>>>> and then use `x' as identifier, >>>>>>> the resulting violation is deviated (allowed pattern). >>>>>>> >>>>>>> If you >>>>>>> #define a(x, y) a(x, y) >>>>>>> and then use `a' as identifier for a non-callable entity, >>>>>>> the resulting violation is deviated (no clash with non-callable >>>>>>> entities). >>>>>>> If you use identifier `a' for a callable entity, the resulting violation >>>>>>> is reported: the allowed pattern covers only macros expanding to their >>>>>>> own name, in this case the macro name is considered to be >>>>>>> `a' only, not a(x, y). >>>>>>> >>>>>>> If you >>>>>>> #define a(x, y) b(x, y) >>>>>>> and then use `a' as identifier for a non-callable entity, >>>>>>> the resulting violation is deviated (no clash with non-callable >>>>>>> entities). >>>>>> >>>>>> I'm afraid I don't see what violation there is in this case, to >>>>>> deviate. As a result I'm also not sure I correctly understand the >>>>>> rest of your reply. >>>>> >>>>> #define a(x, y) b(x, y) >>>>> >>>>> int a; // Violation of Rule 5.5. >>>>> >>>>> The macro name `a' that exist before the preprocessing phase, >>>>> still exists after the preprocessing phase as identifier for the integer >>>>> variable and this is a violation. >>>>> >>>>>>> If you use `a' as identifier for a callable entity, >>>>>>> this is not a violation because after the preprocessing phase, >>>>>>> identifier `a' no longer exists. >>>>> I correct myself: >>>>> if you use `a' as identifier for a *function*, >>>>> it is not a violation because after the preprocessing phase >>>>> the identifier `a' no longer exists, for example: >>>>> >>>>> #define a(x, y) b(x, y) >>>>> >>>>> void a(int x, int y); // Ok. >>>> >>>> Federico, do you have a better wording suggestion for this rule? >>>> >>>> Jan, any further requests here? What would you like to see as next step? >>> >>> A more concise wording proposal would probably help. >> >> What do you think about: >> >> diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst >> index 1e134ccebc..a975b9a85f 100644 >> --- a/docs/misra/rules.rst >> +++ b/docs/misra/rules.rst >> @@ -181,6 +181,13 @@ maintainers if you want to suggest a change. >> headers (xen/include/public/) are allowed to retain longer >> identifiers for backward compatibility. >> >> + * - `Rule 5.5 >> `_ >> + - Required >> + - Identifiers shall be distinct from macro names >> + - Macros expanding to their own name are allowed (e.g., #define x x). >> + Clashes between names of function-like macros and identifiers of >> + non-callable entities are allowed. > > Imo that still leaves open e.g. the > > #define a(x, y) a(x, y) > > case: Permitted ("own name") or not permitted ("a" pretty clearly is expected > to be a callable entity here, besides being a function-like macro)? I would not consider your example as a macro that expands to its own name, the macro name is considered to be `a' only. Rather, you example can be used to trigger the "callable-noncallable" part of the deviation, for example: #define a(x, y) a(x, y) void a(int x, int y); /* Not permitted (callable entity 'a'). */ void foo(int a); /* Permitted (non-callable entity `a'). */ -- Federico Serafini, M.Sc. Software Engineer, BUGSENG (http://bugseng.com) From xen-devel-bounces@lists.xenproject.org Mon Mar 04 16:10:55 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 16:10:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688436.1072528 (Exim 4.92) (envelope-from ) id 1rhAtx-0007s2-MF; Mon, 04 Mar 2024 16:10:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688436.1072528; Mon, 04 Mar 2024 16:10:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhAtx-0007rt-JP; Mon, 04 Mar 2024 16:10:53 +0000 Received: by outflank-mailman (input) for mailman id 688436; Mon, 04 Mar 2024 16:10:52 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhAtv-0007OP-Ul for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 16:10:51 +0000 Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [2a00:1450:4864:20::630]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id c497fdde-da41-11ee-a1ee-f123f15fe8a2; Mon, 04 Mar 2024 17:10:50 +0100 (CET) Received: by mail-ej1-x630.google.com with SMTP id a640c23a62f3a-a3ed9cae56fso1062774566b.1 for ; Mon, 04 Mar 2024 08:10:50 -0800 (PST) Received: from andrewcoop.citrite.net (default-46-102-197-194.interdsl.co.uk. [46.102.197.194]) by smtp.gmail.com with ESMTPSA id o4-20020a17090611c400b00a458d85f9d9sm202394eja.142.2024.03.04.08.10.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Mar 2024 08:10:46 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c497fdde-da41-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709568648; x=1710173448; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=TH1o9ervsPKAzEGLoFJ5wQZrXDTVu2urG7J9ug8iYgw=; b=vcAZo85w+c6NmrADiHaA8pYv8mwhpRX082etIj99UqIah//93PJ1GYo6gOGM9xVeuP e/wEK3EATdwaR/a4waHyAsD9TOxVY5gzx5kE1t03ionJkfhm6dO1wslUGgE/huNCHayS Dp11WgsP0qyAUNvHtzFPbjgAcLAFEgz9V2vcs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709568648; x=1710173448; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=TH1o9ervsPKAzEGLoFJ5wQZrXDTVu2urG7J9ug8iYgw=; b=K5t/PGs8RJ3SQ3jTHI1RWVwpZp3r1+x+DbK5Zsrk191gtUzniCToFogentAsZ5xzWh DeR+zN1hpUP2x6rGLBSiks65u/VjDiGidvyzxchenwhgXj108maBl3xOFtRpYJw/ewCs eQ4Zubzd5py6IpHB6EoV6S6qGQ8+vTfMIpg9DIXeqEO1AXidfk5kHldNruYwo2cTpJ5m IVc84fCPY/hVscHiNn5ekE4MCE2LKtn8XhI7xd6wLi0y+bUcB5jAdjdpCG/+B8h/wJYF SubrQuhbFVHY4pLVQG5KJiATb+BdDrnH2rbUuKcQRD8MG2SKNJgf1AWQtLwEJRaTxAWT R9ow== X-Gm-Message-State: AOJu0YzKXx4nuObgOIzFA/uQmBVXSl/akobGdFn9By6bIJFg1qswxEHR 2uYQD5FWtrkvwEPOfI7jgFORLwE7aslbMYEjj40KoAe5XUptsLZO+OaNIo6+oTyUhAXBclzKgfF u X-Google-Smtp-Source: AGHT+IFY7Zi3s5N1fO8bKi7PdLeyirYiZkfQWHjAWNFGcAEoYFpgczXzC9wdr4CmnLT9Osd3gTWMCA== X-Received: by 2002:a17:906:f6d7:b0:a3f:c3f0:69bf with SMTP id jo23-20020a170906f6d700b00a3fc3f069bfmr9230056ejb.13.1709568648570; Mon, 04 Mar 2024 08:10:48 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Wei Liu Subject: [PATCH 2/2] xen/nospec: Allow evaluate_nospec() to short circuit constant expressions Date: Mon, 4 Mar 2024 16:10:41 +0000 Message-Id: <20240304161041.3465897-3-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20240304161041.3465897-1-andrew.cooper3@citrix.com> References: <20240304161041.3465897-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit When the compiler can reduce the condition to a constant, it can elide the conditional and one of the basic blocks. However, arch_evaluate_nospec() will still insert speculation protection, despite there being nothing to protect. Allow the speculation protection to be skipped entirely when the compiler is removing the condition entirely. e.g. for x86, given: int foo(void) { if ( evaluate_nospec(1) ) return 2; else return 42; } then before, we get: : lfence mov $0x2,%eax retq and afterwards, we get: : mov $0x2,%eax retq which is correct. With no conditional branch to protect, the lfence isn't providing any relevant safety. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Wei Liu --- xen/include/xen/nospec.h | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/xen/include/xen/nospec.h b/xen/include/xen/nospec.h index a4155af08770..56cf67a44176 100644 --- a/xen/include/xen/nospec.h +++ b/xen/include/xen/nospec.h @@ -18,6 +18,15 @@ static always_inline bool evaluate_nospec(bool cond) #ifndef arch_evaluate_nospec #define arch_evaluate_nospec(cond) cond #endif + + /* + * If the compiler can reduce the condition to a constant, then it won't + * be emitting a conditional branch, and there's nothing needing + * protecting. + */ + if ( __builtin_constant_p(cond) ) + return cond; + return arch_evaluate_nospec(cond); } -- 2.30.2 From xen-devel-bounces@lists.xenproject.org Mon Mar 04 16:10:55 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 16:10:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688434.1072508 (Exim 4.92) (envelope-from ) id 1rhAtu-0007Oj-9x; Mon, 04 Mar 2024 16:10:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688434.1072508; Mon, 04 Mar 2024 16:10:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhAtu-0007Oc-5q; Mon, 04 Mar 2024 16:10:50 +0000 Received: by outflank-mailman (input) for mailman id 688434; Mon, 04 Mar 2024 16:10:48 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhAts-0007OP-Me for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 16:10:48 +0000 Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [2a00:1450:4864:20::62d]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id c1a7c6fb-da41-11ee-a1ee-f123f15fe8a2; Mon, 04 Mar 2024 17:10:45 +0100 (CET) Received: by mail-ej1-x62d.google.com with SMTP id a640c23a62f3a-a2f22bfb4e6so766364966b.0 for ; Mon, 04 Mar 2024 08:10:45 -0800 (PST) Received: from andrewcoop.citrite.net (default-46-102-197-194.interdsl.co.uk. [46.102.197.194]) by smtp.gmail.com with ESMTPSA id o4-20020a17090611c400b00a458d85f9d9sm202394eja.142.2024.03.04.08.10.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Mar 2024 08:10:42 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c1a7c6fb-da41-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709568644; x=1710173444; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=4m0zDQO2biprRxwFjTqFVdZtLQIYv/njsgLK8Kh6PTw=; b=UIl83JlE4KIlDOcn9Z7DBPOWqfqV2tcrk5/b2sRb16zSLbySoQ6LrVCk3cfpdy0uSC HEm5q7GE0Y0FiVIkqzWanUXxUp6GCATvOVo0mdN8gC4AeiJysaZDrz7z/CTFEItDKM0s i/Cu5YMWxCzLhTDNtqd+bFLXcGc8fBuYl7/Ic= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709568644; x=1710173444; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=4m0zDQO2biprRxwFjTqFVdZtLQIYv/njsgLK8Kh6PTw=; b=XQsbtFV3q7GMAs+0e//Sm4k2WpGiUtzU2I+sKLr3PJBmp4Vt4rH15HDFYF7BPGPKIM +30dJa/WFS9dQRyB4vAW+f2d0QIXrcAxuT97Gmp5d55ZXBTLVy1eoIZHLzcu10Alaiga QNeAO9zIwb1faJts672ptjfGG5Qc31RMyT/e2nVHp6/X7j6pjsUkcLB/fUEhMocFT4fm 7a9lxOUxjr9uuYP9u5GpcFrumfMIJoVEflGh/vQNeOJSpaq7+oYt/SST0C6dNZ2U18dm n0OfMOuYjc+0Xrlr7TI3C6Jp09GtLEIEZN7fkevg5DxF3x7M3SuGDn+QvvVtsg9c+vQy GCww== X-Gm-Message-State: AOJu0YwzP5aVJVWs3qDQMRvd+WA6/vcTF3QFoHhwmz18IxHa7hGKTxt6 Qasd7qPZaH1ijmm9SEDv3WCDIpQQUa8F18a+jdKK7/g+Tg0LE4Spc2pysOa53B9wrryuZnWEhj0 V X-Google-Smtp-Source: AGHT+IHDRMZ+23vcWpN4lcrxO2vhKWg2kCf/5jOYUYBeoKMraQt55cRqMefgIkn2HoPOAN5AOjdhow== X-Received: by 2002:a17:906:f35b:b0:a43:fd9e:2d69 with SMTP id hg27-20020a170906f35b00b00a43fd9e2d69mr7177614ejb.6.1709568643877; Mon, 04 Mar 2024 08:10:43 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Wei Liu , Stefano Stabellini , Julien Grall , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel , Oleksii Kurochko , Shawn Anastasio Subject: [PATCH 0/2] xen/nospec: Improvements Date: Mon, 4 Mar 2024 16:10:39 +0000 Message-Id: <20240304161041.3465897-1-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Andrew Cooper (2): xen/*/nospec: Provide common versions of evaluate_nospec/block_speculation xen/nospec: Allow evaluate_nospec() to short circuit constant expressions xen/arch/arm/include/asm/nospec.h | 9 -------- xen/arch/ppc/include/asm/nospec.h | 9 -------- xen/arch/riscv/include/asm/nospec.h | 9 -------- xen/arch/x86/include/asm/nospec.h | 8 ++++---- xen/include/xen/nospec.h | 32 +++++++++++++++++++++++++++++ 5 files changed, 36 insertions(+), 31 deletions(-) -- 2.30.2 From xen-devel-bounces@lists.xenproject.org Mon Mar 04 16:10:55 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 16:10:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688435.1072515 (Exim 4.92) (envelope-from ) id 1rhAtu-0007RP-IO; Mon, 04 Mar 2024 16:10:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688435.1072515; Mon, 04 Mar 2024 16:10:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhAtu-0007Qc-CA; Mon, 04 Mar 2024 16:10:50 +0000 Received: by outflank-mailman (input) for mailman id 688435; Mon, 04 Mar 2024 16:10:49 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhAtt-0007OU-33 for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 16:10:49 +0000 Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [2a00:1450:4864:20::635]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id c330c7b8-da41-11ee-afda-a90da7624cb6; Mon, 04 Mar 2024 17:10:47 +0100 (CET) Received: by mail-ej1-x635.google.com with SMTP id a640c23a62f3a-a4595bd5f8cso4171366b.0 for ; Mon, 04 Mar 2024 08:10:47 -0800 (PST) Received: from andrewcoop.citrite.net (default-46-102-197-194.interdsl.co.uk. [46.102.197.194]) by smtp.gmail.com with ESMTPSA id o4-20020a17090611c400b00a458d85f9d9sm202394eja.142.2024.03.04.08.10.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Mar 2024 08:10:44 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c330c7b8-da41-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709568646; x=1710173446; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=+lXQMZ0/v8LLtfSISpT5FKIyGzrtvmnapu4SQzpeFLs=; b=VdfHIqjIdcwMnAem79kpnzCe6sCfXhRPD08KaXWVgevOzgobt41I0usL8C+tGpzU4o bXIMgBLvqWIbLvbANGQVbyXB2tRUqhg8ULCW7enKMIldTf/M1wa7V1x3xAJpQhIlMGjl +gKm2vcWA60tlyJD98F6d6TlVVIz68s2L5f0k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709568646; x=1710173446; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=+lXQMZ0/v8LLtfSISpT5FKIyGzrtvmnapu4SQzpeFLs=; b=OlZFeIkyXouLYXqMP3RlY0/6JJNuUGydAihseqMVuQmX6q4enO1jCxzNOOdFoqEoiO GmqmH+6A+OjoMKX5Ka1kGrgbFU5EfADLpasfSW+E33q7eOBA3UpgNl108wD0zB73Riwv W0dgS+zVZYhqXJedD/L6EaJJOCzoY8SEqTahh0+Da/az/TkHrTqfslv2s9Da5+GPJ1qO wDUDDoQArV34ivaEWXwrrNkyah6BPUHJutAenz//VOG1oZ+r4iS25KSJ5m615UTpskvb 4sNQXywFilIYazxqj6K9g4mEmbML3G202O/eqQl83+Q+JhMm+ietrAWb+ZBBDSszcM0j +TDQ== X-Gm-Message-State: AOJu0Yxzzb7gnN2kAz+s9THlpNWKv310TiRTMKzzhYUgxAuoeR9MZQqH HVFM5xUFI5HuNlq4dk1EujjKN3Hxz0J8sXz74RBLPZR7vsLSf+drG+MOreYopfvmjC7rucpxxkK X X-Google-Smtp-Source: AGHT+IEX9lC5igf0y2ySPqdY9HDEV5TczzY9LqK+73xj+/NfgET68DSyBHDRumsVDdd1JqxDSuQt2Q== X-Received: by 2002:a17:906:c310:b0:a45:6423:ad94 with SMTP id s16-20020a170906c31000b00a456423ad94mr1446167ejz.43.1709568646069; Mon, 04 Mar 2024 08:10:46 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Wei Liu , Stefano Stabellini , Julien Grall , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel , Oleksii Kurochko , Shawn Anastasio Subject: [PATCH 1/2] xen/*/nospec: Provide common versions of evaluate_nospec/block_speculation Date: Mon, 4 Mar 2024 16:10:40 +0000 Message-Id: <20240304161041.3465897-2-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20240304161041.3465897-1-andrew.cooper3@citrix.com> References: <20240304161041.3465897-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit It is daft to require all architectures to provide empty implementations of this functionality. Provide evaluate_nospec() and block_speculation() unconditionally in xen/nospec.h with architectures able to opt in by providing suitable arch variants. Rename x86's implementation to the arch_*() variants. No functional change. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Wei Liu CC: Stefano Stabellini CC: Julien Grall CC: Volodymyr Babchuk CC: Bertrand Marquis CC: Michal Orzel CC: Oleksii Kurochko CC: Shawn Anastasio --- xen/arch/arm/include/asm/nospec.h | 9 --------- xen/arch/ppc/include/asm/nospec.h | 9 --------- xen/arch/riscv/include/asm/nospec.h | 9 --------- xen/arch/x86/include/asm/nospec.h | 8 ++++---- xen/include/xen/nospec.h | 23 +++++++++++++++++++++++ 5 files changed, 27 insertions(+), 31 deletions(-) diff --git a/xen/arch/arm/include/asm/nospec.h b/xen/arch/arm/include/asm/nospec.h index efac51fc03be..05df096faab0 100644 --- a/xen/arch/arm/include/asm/nospec.h +++ b/xen/arch/arm/include/asm/nospec.h @@ -12,15 +12,6 @@ # error "unknown ARM variant" #endif -static inline bool evaluate_nospec(bool condition) -{ - return condition; -} - -static inline void block_speculation(void) -{ -} - #endif /* _ASM_ARM_NOSPEC_H */ /* diff --git a/xen/arch/ppc/include/asm/nospec.h b/xen/arch/ppc/include/asm/nospec.h index b97322e48d32..9b57a7e4b24d 100644 --- a/xen/arch/ppc/include/asm/nospec.h +++ b/xen/arch/ppc/include/asm/nospec.h @@ -3,13 +3,4 @@ #ifndef __ASM_PPC_NOSPEC_H__ #define __ASM_PPC_NOSPEC_H__ -static inline bool evaluate_nospec(bool condition) -{ - return condition; -} - -static inline void block_speculation(void) -{ -} - #endif /* __ASM_PPC_NOSPEC_H__ */ diff --git a/xen/arch/riscv/include/asm/nospec.h b/xen/arch/riscv/include/asm/nospec.h index e30f0a781b68..b227fc61ed8b 100644 --- a/xen/arch/riscv/include/asm/nospec.h +++ b/xen/arch/riscv/include/asm/nospec.h @@ -4,15 +4,6 @@ #ifndef _ASM_RISCV_NOSPEC_H #define _ASM_RISCV_NOSPEC_H -static inline bool evaluate_nospec(bool condition) -{ - return condition; -} - -static inline void block_speculation(void) -{ -} - #endif /* _ASM_RISCV_NOSPEC_H */ /* diff --git a/xen/arch/x86/include/asm/nospec.h b/xen/arch/x86/include/asm/nospec.h index 07606834c4c9..defc97707f03 100644 --- a/xen/arch/x86/include/asm/nospec.h +++ b/xen/arch/x86/include/asm/nospec.h @@ -23,20 +23,20 @@ static always_inline bool barrier_nospec_false(void) return false; } -/* Allow to protect evaluation of conditionals with respect to speculation */ -static always_inline bool evaluate_nospec(bool condition) +static always_inline bool arch_evaluate_nospec(bool condition) { if ( condition ) return barrier_nospec_true(); else return barrier_nospec_false(); } +#define arch_evaluate_nospec arch_evaluate_nospec -/* Allow to block speculative execution in generic code */ -static always_inline void block_speculation(void) +static always_inline void arch_block_speculation(void) { barrier_nospec_true(); } +#define arch_block_speculation arch_block_speculation /** * array_index_mask_nospec() - generate a mask that is ~0UL when the diff --git a/xen/include/xen/nospec.h b/xen/include/xen/nospec.h index 4c250ebbd663..a4155af08770 100644 --- a/xen/include/xen/nospec.h +++ b/xen/include/xen/nospec.h @@ -9,6 +9,29 @@ #include +/* + * Protect a conditional branch from bad speculation. Architectures *must* + * provide arch_evaluate_nospec() for this to be effective. + */ +static always_inline bool evaluate_nospec(bool cond) +{ +#ifndef arch_evaluate_nospec +#define arch_evaluate_nospec(cond) cond +#endif + return arch_evaluate_nospec(cond); +} + +/* + * Halt speculation unconditonally. Architectures *must* provide + * arch_block_speculation() for this to be effective. + */ +static always_inline void block_speculation(void) +{ +#ifdef arch_block_speculation + arch_block_speculation(); +#endif +} + /** * array_index_mask_nospec() - generate a ~0 mask when index < size, 0 otherwise * @index: array element index -- 2.30.2 From xen-devel-bounces@lists.xenproject.org Mon Mar 04 16:32:10 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 16:32:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688444.1072540 (Exim 4.92) (envelope-from ) id 1rhBES-0003Oc-CV; Mon, 04 Mar 2024 16:32:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688444.1072540; Mon, 04 Mar 2024 16:32:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhBES-0003OV-A0; Mon, 04 Mar 2024 16:32:04 +0000 Received: by outflank-mailman (input) for mailman id 688444; Mon, 04 Mar 2024 16:32:03 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhBER-0003Na-7m for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 16:32:03 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhBEQ-0003Dy-Ma; Mon, 04 Mar 2024 16:32:02 +0000 Received: from gw1.octic.net ([88.97.20.152] helo=[10.0.1.240]) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1rhBEQ-0001fN-7N; Mon, 04 Mar 2024 16:32:02 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID; bh=VKJgEvGBOw/UC3HKTngodgixYYnofVuSQb3X32ZaFUo=; b=zOV6XJSOlH6jui0ek+FVxbYCbR nkhQ37ayEynLwy9g+NUU5RQ32qiv8cfdyTyAwqeBAMse4TBzxw/bYPtUzUaxbN3jzoxy68BVPcqWV vEbVtBg2p+8kLsfAoQKTLjVs3J8zqI6whFmV4c/wxpgOE5ypn+jX7I+bY7qaZKoOZHbI=; Message-ID: Date: Mon, 4 Mar 2024 16:31:59 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] xen/*/nospec: Provide common versions of evaluate_nospec/block_speculation Content-Language: en-GB To: Andrew Cooper , Xen-devel Cc: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu , Stefano Stabellini , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel , Oleksii Kurochko , Shawn Anastasio References: <20240304161041.3465897-1-andrew.cooper3@citrix.com> <20240304161041.3465897-2-andrew.cooper3@citrix.com> From: Julien Grall In-Reply-To: <20240304161041.3465897-2-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Andrew, On 04/03/2024 16:10, Andrew Cooper wrote: > It is daft to require all architectures to provide empty implementations of > this functionality. Oleksii recenlty sent a similar patch [1]. This was pushed back because from naming, it sounds like the helpers ought to be non-empty on every architecture. It would be best if asm-generic provides a safe version of the helpers. So my preference is to not have this patch. This can of course change if I see an explanation why it is empty on Arm (I believe it should contain csdb) and other arch would want the same. Cheers, [1] 5889d7a5fa81722472f95cc1448af0be8f359a7d.1707146506.git.oleksii.kurochko@gmail.com -- Julien Grall From xen-devel-bounces@lists.xenproject.org Mon Mar 04 16:36:27 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 16:36:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688447.1072551 (Exim 4.92) (envelope-from ) id 1rhBIg-00042R-1C; Mon, 04 Mar 2024 16:36:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688447.1072551; Mon, 04 Mar 2024 16:36:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhBIf-00042K-U4; Mon, 04 Mar 2024 16:36:25 +0000 Received: by outflank-mailman (input) for mailman id 688447; Mon, 04 Mar 2024 16:36:24 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhBIe-00042E-Ei for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 16:36:24 +0000 Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [2a00:1450:4864:20::52d]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 5558cf7f-da45-11ee-a1ee-f123f15fe8a2; Mon, 04 Mar 2024 17:36:22 +0100 (CET) Received: by mail-ed1-x52d.google.com with SMTP id 4fb4d7f45d1cf-5656e5754ccso6050344a12.0 for ; Mon, 04 Mar 2024 08:36:21 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id q22-20020a50aa96000000b00564e489ce9asm5029353edc.12.2024.03.04.08.36.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Mar 2024 08:36:20 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 5558cf7f-da45-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709570181; x=1710174981; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=UFU07q3UlHeJJoaB6lTGmqhiHfuhfu7yy/0BJqnd3Ho=; b=W9IVeqe5WYvdYqDgmeBU0IOP4uzaakH+dkOq5TLZifjaysdhmah/jmWx4VivYwQXW4 G0TYgT44mjcZqhq4w+zQg35RQW8odU146ebU6oNOdx1gKuuuFqdUW6UmalGAXpPKvaM4 JwpfjjcGd7QJXeB1WGN24LpnyllfqTVfpklRAohYdmnVqhseczYMxQv4pLjDIL8jSg8s 5r5ZxwMEqo1bEg3yi2TK3e2VLKVvEKAYqNPmuao8dIpD9OyZHayVLuAUxwb9ayANyjTD XN/Fo3rPU9c/xwGV9ODMrmKDt4Jddk0pBCsCYxbeRhAIqvu5Q4lCew+cWTwlpJbCfeuV +oDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709570181; x=1710174981; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=UFU07q3UlHeJJoaB6lTGmqhiHfuhfu7yy/0BJqnd3Ho=; b=lR4YBZRAlKaTkbpio5vxOq1uhV51Icja84piA1UeQvSR0GQ2GDik+nMyiFqZZ+lqKF VLcGxgbfZcQHv7IhrjUgIM5st6b/HAntMkkLIicM5BnYD1Rh8e0tMlS7j61WdWIDO4OW TPRnbZOY/3q6rlV6j/KEeJKsPsjIqADE2QrjleP4wezM/5J/9qhg1l9N1ibj/V22GRMH GeK5wq1/h1Rk3Aoz2BZeGUHiT1UPAaAPo2kDlnc0BjqrqinmfhoHBOEVEWQ5PoOKb2E6 UrZQH2L/xjmEWDK5CGdU15WqsDJeDXeKSCGIKS9E09jnvKqLr2tWGQvcfQb4ZfDnmeJ4 psZQ== X-Forwarded-Encrypted: i=1; AJvYcCXCdoSMuWcpRCeaeycbQiefHDigcT74OxQOmGtHuZn5GsrIcaNFIddbftDSXHjBlDM0C5dtfy0jPsfuPgOpOtZGo49El0hjmYXbSlwNaOc= X-Gm-Message-State: AOJu0YyGQ4jyIXHwHdEXl1tOCd9LWn5zyepruVKUQlNfNkASxXqGOjD2 kmCkmyo1hlXj3h6+7D0LCwifZCDtib6sf2EG+rvdpG6b7UawzJCwfOtmNtn6cQ== X-Google-Smtp-Source: AGHT+IE4V9OsJB1W76mF2N6NTiGLU3r30ut7usfrcbM8nMmyHyAnwN/9E9+KGVQKmvZetz1XNrxGrg== X-Received: by 2002:a05:6402:1249:b0:567:4441:89ad with SMTP id l9-20020a056402124900b00567444189admr2626236edw.15.1709570181088; Mon, 04 Mar 2024 08:36:21 -0800 (PST) Message-ID: <8e5d4c48-558d-40e2-851a-3eb6bfa5dbfe@suse.com> Date: Mon, 4 Mar 2024 17:36:20 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/3] docs/misra/rules.rst: add rule 5.5 Content-Language: en-US To: Federico Serafini Cc: andrew.cooper3@citrix.com, george.dunlap@citrix.com, julien@xen.org, bertrand.marquis@arm.com, roger.pau@citrix.com, xen-devel@lists.xenproject.org, Stefano Stabellini , roberto.bagnara@bugseng.com, Stefano Stabellini References: <20240213223334.3693410-2-stefano.stabellini@amd.com> <50719397-b053-43e1-9cf7-cc9eae9098ed@suse.com> <40b7465f-4966-43c7-8db3-e28a6cc48445@bugseng.com> <2da73259-a86e-4a13-9fd4-4217372f4b76@suse.com> <3632611e-61ff-455a-9cc1-990a1f663d83@bugseng.com> <7747cb81-8fdb-4a5f-bfd1-c6c9bdb6039a@suse.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 04.03.2024 16:39, Federico Serafini wrote: > On 04/03/24 15:17, Jan Beulich wrote: >> On 04.03.2024 14:31, Federico Serafini wrote: >>> On 01/03/24 09:06, Jan Beulich wrote: >>>> On 01.03.2024 00:28, Stefano Stabellini wrote: >>>>> On Wed, 14 Feb 2024, Federico Serafini wrote: >>>>>> On 14/02/24 14:15, Jan Beulich wrote: >>>>>>> On 14.02.2024 12:27, Federico Serafini wrote: >>>>>>>> On 14/02/24 09:28, Jan Beulich wrote: >>>>>>>>> On 13.02.2024 23:33, Stefano Stabellini wrote: >>>>>>>>>> Signed-off-by: Stefano Stabellini >>>>>>>>>> --- >>>>>>>>>> docs/misra/rules.rst | 6 ++++++ >>>>>>>>>> 1 file changed, 6 insertions(+) >>>>>>>>>> >>>>>>>>>> diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst >>>>>>>>>> index c185366966..931158b354 100644 >>>>>>>>>> --- a/docs/misra/rules.rst >>>>>>>>>> +++ b/docs/misra/rules.rst >>>>>>>>>> @@ -181,6 +181,12 @@ maintainers if you want to suggest a change. >>>>>>>>>> headers (xen/include/public/) are allowed to retain longer >>>>>>>>>> identifiers for backward compatibility. >>>>>>>>>> + * - `Rule 5.5 >>>>>>>>>> `_ >>>>>>>>>> + - Required >>>>>>>>>> + - Identifiers shall be distinct from macro names >>>>>>>>>> + - Clashes between function-like macros and non-callable entities >>>>>>>>>> + are allowed. The pattern #define x x is also allowed. >>>>>>>>> >>>>>>>>> Just for me to know what exactly is covered (hence also a question >>>>>>>>> to Roberto as to [to be] implemented Eclair behavior): Even when >>>>>>>>> the above would be sufficient (and imo better) people frequently >>>>>>>>> write >>>>>>>>> >>>>>>>>> #define a(x, y) b(x, y) >>>>>>>>> >>>>>>>>> which, transformed to the specific case here, would then be >>>>>>>>> >>>>>>>>> #define a(x, y) a(x, y) >>>>>>>>> >>>>>>>>> I'd assume such ought to also be covered, but that's not clear >>>>>>>>> from the spelling above. >>>>>>>> >>>>>>>> I list what happens in some different situations, >>>>>>>> then we can find the right words for the documentation and/or >>>>>>>> refine the configuration: >>>>>>>> >>>>>>>> If you >>>>>>>> #define x x >>>>>>>> and then use `x' as identifier, >>>>>>>> the resulting violation is deviated (allowed pattern). >>>>>>>> >>>>>>>> If you >>>>>>>> #define a(x, y) a(x, y) >>>>>>>> and then use `a' as identifier for a non-callable entity, >>>>>>>> the resulting violation is deviated (no clash with non-callable >>>>>>>> entities). >>>>>>>> If you use identifier `a' for a callable entity, the resulting violation >>>>>>>> is reported: the allowed pattern covers only macros expanding to their >>>>>>>> own name, in this case the macro name is considered to be >>>>>>>> `a' only, not a(x, y). >>>>>>>> >>>>>>>> If you >>>>>>>> #define a(x, y) b(x, y) >>>>>>>> and then use `a' as identifier for a non-callable entity, >>>>>>>> the resulting violation is deviated (no clash with non-callable >>>>>>>> entities). >>>>>>> >>>>>>> I'm afraid I don't see what violation there is in this case, to >>>>>>> deviate. As a result I'm also not sure I correctly understand the >>>>>>> rest of your reply. >>>>>> >>>>>> #define a(x, y) b(x, y) >>>>>> >>>>>> int a; // Violation of Rule 5.5. >>>>>> >>>>>> The macro name `a' that exist before the preprocessing phase, >>>>>> still exists after the preprocessing phase as identifier for the integer >>>>>> variable and this is a violation. >>>>>> >>>>>>>> If you use `a' as identifier for a callable entity, >>>>>>>> this is not a violation because after the preprocessing phase, >>>>>>>> identifier `a' no longer exists. >>>>>> I correct myself: >>>>>> if you use `a' as identifier for a *function*, >>>>>> it is not a violation because after the preprocessing phase >>>>>> the identifier `a' no longer exists, for example: >>>>>> >>>>>> #define a(x, y) b(x, y) >>>>>> >>>>>> void a(int x, int y); // Ok. >>>>> >>>>> Federico, do you have a better wording suggestion for this rule? >>>>> >>>>> Jan, any further requests here? What would you like to see as next step? >>>> >>>> A more concise wording proposal would probably help. >>> >>> What do you think about: >>> >>> diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst >>> index 1e134ccebc..a975b9a85f 100644 >>> --- a/docs/misra/rules.rst >>> +++ b/docs/misra/rules.rst >>> @@ -181,6 +181,13 @@ maintainers if you want to suggest a change. >>> headers (xen/include/public/) are allowed to retain longer >>> identifiers for backward compatibility. >>> >>> + * - `Rule 5.5 >>> `_ >>> + - Required >>> + - Identifiers shall be distinct from macro names >>> + - Macros expanding to their own name are allowed (e.g., #define x x). >>> + Clashes between names of function-like macros and identifiers of >>> + non-callable entities are allowed. >> >> Imo that still leaves open e.g. the >> >> #define a(x, y) a(x, y) >> >> case: Permitted ("own name") or not permitted ("a" pretty clearly is expected >> to be a callable entity here, besides being a function-like macro)? > > I would not consider your example as a macro that expands to its own > name, the macro name is considered to be `a' only. That's what I was assuming, and hence my asking back. I think the above ought to be permitted just like "#define x x", and hence the suggested text would need expanding, to ... > Rather, you example can be used to trigger the "callable-noncallable" > part of the deviation, for example: > > #define a(x, y) a(x, y) > > void a(int x, int y); /* Not permitted (callable entity 'a'). */ ... prevent this ("not permitted") from happening. I'm pretty sure you've already found instances of this pattern in our code base. Jan > void foo(int a); /* Permitted (non-callable entity `a'). */ > From xen-devel-bounces@lists.xenproject.org Mon Mar 04 16:41:40 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 16:41:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688451.1072561 (Exim 4.92) (envelope-from ) id 1rhBNX-0005xc-Ic; Mon, 04 Mar 2024 16:41:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688451.1072561; Mon, 04 Mar 2024 16:41:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhBNX-0005xV-Fb; Mon, 04 Mar 2024 16:41:27 +0000 Received: by outflank-mailman (input) for mailman id 688451; Mon, 04 Mar 2024 16:41:26 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhBNW-0005xP-4G for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 16:41:26 +0000 Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [2a00:1450:4864:20::62a]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 09af01be-da46-11ee-a1ee-f123f15fe8a2; Mon, 04 Mar 2024 17:41:24 +0100 (CET) Received: by mail-ej1-x62a.google.com with SMTP id a640c23a62f3a-a458b6d9cfeso52947966b.2 for ; Mon, 04 Mar 2024 08:41:24 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id v27-20020a170906381b00b00a449f43a7afsm3646231ejc.113.2024.03.04.08.41.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Mar 2024 08:41:23 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 09af01be-da46-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709570483; x=1710175283; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=n+HJ4iJUbtPJxRimA7erqWi8lOYahXTGCDnG02r/PSo=; b=U6MbQQo3Ca1KpYGXX/It/JMMQ4/QsKcodpgUVuLehwzwrP3Pvdq4B9NTzwN7QUv9TL 79heWoD/bUcVxX1ThDgEWL/nTPAkmz6qblL9kDnCcETIVeF/UETCP1UG6QnNu6vFXVyj bWs/Sbp74oJ8TyY0Ht6w32E4uP9IrV0MHbD1RnK58r9+2MGj1+58RDEe2RQVleMqWj5R X9yP1veasMqiVU7i+UzEJWbLDIcxIsOUaMaBeKPlZ6kKL3InPu+c+whbAqW8iKGliU66 /GwRj7U7ei7yYFfCOwnjHc2Qkd2Elk1pc/dIbWQ5tG1g0A615Wp3kMLNPsQlAP9N9N5q FWSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709570483; x=1710175283; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=n+HJ4iJUbtPJxRimA7erqWi8lOYahXTGCDnG02r/PSo=; b=eOuRcIyeqMEzpwz7UrnW5225Dw+KXeKcI3azFdsue/LW766hRBBPONRG8j/AKc2eDI fbfys0iiS34RP/RFcDsjfsU7Yv5fcQwK09YzON0h5/L79nxiNYW9jni4FmKK0sfq6+Jk /g7PbvdW+k5uLDKzBKufGlJzuXToplCyfcBuYCSUs/I0tRwuSSzqx22tl4eKND9dYGR1 8ekdQ3Huey9iPLjZaEbit+l4yS11AOTHWDqJe3S3AnAm96AGQWYvw2gXG+oWQGdCQMPe geDYuUL2naj24DpDjkhiuVaLI+tFFHcZh/ZNWuP/9bJ8mLhTjZlUhuD5+f5elnSyC+TV OxfA== X-Forwarded-Encrypted: i=1; AJvYcCWOJQ2wvd2WT2nTr1KjlLu12frFF5ljUNdazZxNfWMmDiUa987U+62nz54uNr16bSNDXKC92xFOUpKcQTlagftyPp6TIC4WZf7NjGoyvH4= X-Gm-Message-State: AOJu0YzEX3+TxIVnDdnC45I4hbPbwWlgvrd4cROMLtXu0Nzg4iy6bGDJ QIINZASCvm7hZQJCfwhExkR8GrKjEJ/3GWBh2ZPEHz4N51qd/kV7azA7oGOj6A== X-Google-Smtp-Source: AGHT+IGxNuVgF7/4XRCbxxGRYY9YtXVQIrv0RlKOGYd6qYunEAnzq7a1YWfFd6zuh7/UFUi7l4xmYA== X-Received: by 2002:a17:906:d215:b0:a44:7a25:736d with SMTP id w21-20020a170906d21500b00a447a25736dmr6374751ejz.21.1709570483690; Mon, 04 Mar 2024 08:41:23 -0800 (PST) Message-ID: Date: Mon, 4 Mar 2024 17:41:22 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] xen/*/nospec: Provide common versions of evaluate_nospec/block_speculation Content-Language: en-US To: Julien Grall Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu , Stefano Stabellini , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel , Oleksii Kurochko , Shawn Anastasio , Xen-devel , Andrew Cooper References: <20240304161041.3465897-1-andrew.cooper3@citrix.com> <20240304161041.3465897-2-andrew.cooper3@citrix.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 04.03.2024 17:31, Julien Grall wrote: > On 04/03/2024 16:10, Andrew Cooper wrote: >> It is daft to require all architectures to provide empty implementations of >> this functionality. > > Oleksii recenlty sent a similar patch [1]. This was pushed back because > from naming, it sounds like the helpers ought to be non-empty on every > architecture. > > It would be best if asm-generic provides a safe version of the helpers. > So my preference is to not have this patch. This can of course change if > I see an explanation why it is empty on Arm (I believe it should contain > csdb) and other arch would want the same. Except that there's no new asm-generic/ header here (as opposed to how Oleksii had it). Imo avoiding the need for empty stubs is okay this way, when introducing an asm-generic/ header would not have been. Of course if Arm wants to put something there rather sooner than later, then perhaps the functions better wouldn't be removed from there, just to then be put back pretty soon. Jan From xen-devel-bounces@lists.xenproject.org Mon Mar 04 16:41:46 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 16:41:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688452.1072571 (Exim 4.92) (envelope-from ) id 1rhBNq-0006J6-Ou; Mon, 04 Mar 2024 16:41:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688452.1072571; Mon, 04 Mar 2024 16:41:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhBNq-0006Iz-ME; Mon, 04 Mar 2024 16:41:46 +0000 Received: by outflank-mailman (input) for mailman id 688452; Mon, 04 Mar 2024 16:41:44 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhBNo-0006HK-OB; Mon, 04 Mar 2024 16:41:44 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhBNo-0003PF-It; Mon, 04 Mar 2024 16:41:44 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhBNo-00019b-5p; Mon, 04 Mar 2024 16:41:44 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rhBNo-0008Fx-57; Mon, 04 Mar 2024 16:41:44 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=cnSSDpOjbHDykoxC0K8mB77jmDj5mOrdBskRVpYE7Tk=; b=BhNtKZ8Ek0aJPhotmjn+MS45CM 7o6AiO6h0cx2BrOdLAzUhNJxZ2SZjnhISGmZR1ETBybMCek+KgavGalPowGVb234IN7+SyUxB+HvS UAdQvFGk+clZNnNammRdgttAgRksMk0Q2sPV1t9TAN/Iv+J+BeWgZmEZTYjVgPXaV5Qg=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-linus test] 184886: tolerable FAIL - PUSHED X-Osstest-Failures: linux-linus:test-armhf-armhf-xl:host-ping-check-xen:fail:heisenbug linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: linux=90d35da658da8cff0d4ecbb5113f5fac9d00eb72 X-Osstest-Versions-That: linux=58c806d867bf265c6fd16fc3bc62e2d3c156b5c9 From: osstest service owner Date: Mon, 04 Mar 2024 16:41:44 +0000 flight 184886 linux-linus real [real] flight 184898 linux-linus real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/184886/ http://logs.test-lab.xenproject.org/osstest/logs/184898/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-xl 10 host-ping-check-xen fail pass in 184898-retest Tests which did not succeed, but are not blocking: test-armhf-armhf-xl 15 migrate-support-check fail in 184898 never pass test-armhf-armhf-xl 16 saverestore-support-check fail in 184898 never pass test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop fail like 184880 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop fail like 184880 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop fail like 184880 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 184880 test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail like 184880 test-armhf-armhf-libvirt 16 saverestore-support-check fail like 184880 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop fail like 184880 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184880 test-amd64-amd64-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl 15 migrate-support-check fail never pass test-arm64-arm64-xl 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 15 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qcow2 14 migrate-support-check fail never pass test-amd64-amd64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-check fail never pass test-arm64-arm64-xl-vhd 14 migrate-support-check fail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-check fail never pass test-armhf-armhf-libvirt 15 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-check fail never pass version targeted for testing: linux 90d35da658da8cff0d4ecbb5113f5fac9d00eb72 baseline version: linux 58c806d867bf265c6fd16fc3bc62e2d3c156b5c9 Last test of basis 184880 2024-03-03 18:14:43 Z 0 days Testing same since 184886 2024-03-04 04:27:14 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Linus Torvalds jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl fail test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-amd64-dom0pvh-xl-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-freebsd11-amd64 pass test-amd64-amd64-freebsd12-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-examine-bios pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-amd64-dom0pvh-xl-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-amd64-xl-pvshim pass test-amd64-amd64-pygrub pass test-amd64-amd64-libvirt-qcow2 pass test-armhf-armhf-libvirt-qcow2 pass test-amd64-amd64-libvirt-raw pass test-arm64-arm64-libvirt-raw pass test-armhf-armhf-libvirt-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-examine-uefi pass test-amd64-amd64-xl-vhd pass test-arm64-arm64-xl-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these 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 : hint: The 'hooks/update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-receive' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. To xenbits.xen.org:/home/xen/git/linux-pvops.git 58c806d867bf2..90d35da658da8 90d35da658da8cff0d4ecbb5113f5fac9d00eb72 -> tested/linux-linus From xen-devel-bounces@lists.xenproject.org Mon Mar 04 16:45:24 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 16:45:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688458.1072581 (Exim 4.92) (envelope-from ) id 1rhBRK-00077Z-DH; Mon, 04 Mar 2024 16:45:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688458.1072581; Mon, 04 Mar 2024 16:45:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhBRK-00077S-9o; Mon, 04 Mar 2024 16:45:22 +0000 Received: by outflank-mailman (input) for mailman id 688458; Mon, 04 Mar 2024 16:45:21 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhBRJ-00077M-0A for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 16:45:21 +0000 Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [2a00:1450:4864:20::635]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 95b10957-da46-11ee-a1ee-f123f15fe8a2; Mon, 04 Mar 2024 17:45:19 +0100 (CET) Received: by mail-ej1-x635.google.com with SMTP id a640c23a62f3a-a44d084bfe1so287309266b.1 for ; Mon, 04 Mar 2024 08:45:19 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id j22-20020a170906475600b00a449d6184dasm3725976ejs.6.2024.03.04.08.45.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Mar 2024 08:45:18 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 95b10957-da46-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709570718; x=1710175518; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=Oe/r2d4RJngDwa1H4Tq1eS6gsby+Xery2InR4nGJGYM=; b=V1HpqxObf5CbFXWqC6QQ4HzX7D2SjBoFViyddFbR905mY4afLwZOCko8SWxdCTJUoe URA7mLDKwsRQMrlQtXQOKSZ3KkRC/CfN89H+WL6JVPj/gJrzvWx4M/8NC+zMpxIYOzjl kd9rGcHEN/vGVb/6T3EVlsTtd+Z9xR7FXiWIplm4QxEqHCqoerU6gIcfu2bqg2wrCW7i FsCWLssA+rb6QGvSdsngKLSbBxdIItmTJGiAFmOfS+oeZBzRzF/gnerE4pGqAdMw9d3V L6BrKf7tV/FWogBXISWYzX+KW9a4EiR7gQc7sdnvcTAnsXINn4/nTlRIp/x0Aq4oXKOb /dnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709570718; x=1710175518; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Oe/r2d4RJngDwa1H4Tq1eS6gsby+Xery2InR4nGJGYM=; b=ZOSasJQhEgbuRKcj5uEfFBr1AZJKy4MoccJeqp5wcL4FAVL9bjbLgKJxLc82lEA9ra 3qZTMrvpibzNfuZaDbuPAqxatoHMeVwbEH3uKQLDs+q1CmD4mU7qrQgb0bguq+EyTdk3 kNbdnZnTOeFW8ahbkrVzHJdofrlnzUuUTMpLr4QP1mKdCW1k/H2tPWvyHwmuxFE4iSPX RhTmNWSjyPSQjF7p1lBFE81d24en4E0jDTdMqAy1Pkf31u9Y9XOQUngCOUGyHDndcZJ8 DhBUtFWtCdAd67+droS5gT8Vxd1uWyX/NAADRB9wCIj9/GXaRjjSYQaP2mwq2lkNNUAK 5gKQ== X-Forwarded-Encrypted: i=1; AJvYcCWC/MxG2wkXg4MgWXO+B9LU+nAo4IsPJ7tTAHjBR1XTo0fLBKUCcb27mQgCEtCU9SBx5nF8AD11alb4bg14/jyXDPVO9RTZXbTByBvVY/8= X-Gm-Message-State: AOJu0YwBQZqRwMwzg1phLh1kgDiIMOo5HdCpNOxQ3LHNJaS3890DLvWI ztCCfD0nOjXSzY0F9SQ942TOvz+d8k5acEleZsDK3lcL6BoNEWndOAJLz0wBfA== X-Google-Smtp-Source: AGHT+IFgxOr2LHNlofjqmva7peyOUOrqXraP531SLg93JDQn4jizwYQi0PxG53ZjAAuEnX0lij1j5Q== X-Received: by 2002:a17:906:40d0:b0:a44:9e7e:64c3 with SMTP id a16-20020a17090640d000b00a449e7e64c3mr6901634ejk.10.1709570718481; Mon, 04 Mar 2024 08:45:18 -0800 (PST) Message-ID: <5220c8cf-bbc2-4f18-94ca-f1f30dd828c9@suse.com> Date: Mon, 4 Mar 2024 17:45:17 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] xen/*/nospec: Provide common versions of evaluate_nospec/block_speculation Content-Language: en-US To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu , Stefano Stabellini , Julien Grall , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel , Oleksii Kurochko , Shawn Anastasio , Xen-devel References: <20240304161041.3465897-1-andrew.cooper3@citrix.com> <20240304161041.3465897-2-andrew.cooper3@citrix.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20240304161041.3465897-2-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 04.03.2024 17:10, Andrew Cooper wrote: > --- a/xen/arch/x86/include/asm/nospec.h > +++ b/xen/arch/x86/include/asm/nospec.h > @@ -23,20 +23,20 @@ static always_inline bool barrier_nospec_false(void) > return false; > } > > -/* Allow to protect evaluation of conditionals with respect to speculation */ > -static always_inline bool evaluate_nospec(bool condition) > +static always_inline bool arch_evaluate_nospec(bool condition) > { > if ( condition ) > return barrier_nospec_true(); > else > return barrier_nospec_false(); > } > +#define arch_evaluate_nospec arch_evaluate_nospec > > -/* Allow to block speculative execution in generic code */ > -static always_inline void block_speculation(void) > +static always_inline void arch_block_speculation(void) > { > barrier_nospec_true(); > } > +#define arch_block_speculation arch_block_speculation I'm having some difficulty seeing the need for the renaming (adding or the arch_ prefixes): Why can't the original names be kept, and ... > --- a/xen/include/xen/nospec.h > +++ b/xen/include/xen/nospec.h > @@ -9,6 +9,29 @@ > > #include > > +/* > + * Protect a conditional branch from bad speculation. Architectures *must* > + * provide arch_evaluate_nospec() for this to be effective. > + */ > +static always_inline bool evaluate_nospec(bool cond) > +{ > +#ifndef arch_evaluate_nospec > +#define arch_evaluate_nospec(cond) cond > +#endif > + return arch_evaluate_nospec(cond); > +} > + > +/* > + * Halt speculation unconditonally. Architectures *must* provide > + * arch_block_speculation() for this to be effective. > + */ > +static always_inline void block_speculation(void) > +{ > +#ifdef arch_block_speculation > + arch_block_speculation(); > +#endif > +} ... stubs be introduced here if the original names aren't #define-d? IOW what does the extra layer gain us? Jan From xen-devel-bounces@lists.xenproject.org Mon Mar 04 16:46:28 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 16:46:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688462.1072590 (Exim 4.92) (envelope-from ) id 1rhBSN-0007d7-LD; Mon, 04 Mar 2024 16:46:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688462.1072590; Mon, 04 Mar 2024 16:46:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhBSN-0007d0-Ib; Mon, 04 Mar 2024 16:46:27 +0000 Received: by outflank-mailman (input) for mailman id 688462; Mon, 04 Mar 2024 16:46:25 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhBSL-0007cV-RE for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 16:46:25 +0000 Received: from mail-oo1-xc35.google.com (mail-oo1-xc35.google.com [2607:f8b0:4864:20::c35]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id bc15f146-da46-11ee-a1ee-f123f15fe8a2; Mon, 04 Mar 2024 17:46:24 +0100 (CET) Received: by mail-oo1-xc35.google.com with SMTP id 006d021491bc7-5a143047a4aso275133eaf.0 for ; Mon, 04 Mar 2024 08:46:24 -0800 (PST) Received: from [10.80.67.149] (default-46-102-197-194.interdsl.co.uk. [46.102.197.194]) by smtp.gmail.com with ESMTPSA id ev7-20020a056820310700b005a11b24176csm1033441oob.15.2024.03.04.08.46.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Mar 2024 08:46:21 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: bc15f146-da46-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709570783; x=1710175583; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=NO+YwGKxThnsKTJTVLQlONaHwyR9rPJPpqFRPNO5j2A=; b=QFoy1euldGOHMUpRglolV2xeJkJbk9TKMZ7jzqGIbdDXqgDfLpiDR/7hPB7V8A2Gow 2Rk1/ZuXi6FiL/eychyd7QJBuGpagBMfqd2YQ8+4LCauxdkPYVvJ8bnifUk9NCpkw6th UHopUv1y7fpuSXWwAi9rDXxM55QxCfX04yb04= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709570783; x=1710175583; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=NO+YwGKxThnsKTJTVLQlONaHwyR9rPJPpqFRPNO5j2A=; b=xBecu4/czHd9LjcUIqATdcnFl4ZqCbFwONjMuuCHX0M/8iDtmzA4kMtBZR+nyhBva3 SkfKvE7uLDeFGkF6eNPtqqIx5WrMAfW0d/Nurw6NKYlhbHugCtNfx6CDiakExev0uJkI oWlbIVIAC8gV7NWFWZsFkxU/ICkh2A6BRdnaGtpYlt/ZAavlp9tB7dndZVevqk2x6tFh c5uW4ivR+GxIWaKOAw0+BvyvW4n5w8d1YP4oB5TOQjVEm6IwnPsLv5Z5A4A4NiW7CRXs BaL4MFuzq7PjsBgLEHEPA90Hzp3Qx+RSQucbERvBFGZFY2qyawy4WJgina3YTlEkQZf9 vgdA== X-Forwarded-Encrypted: i=1; AJvYcCWKRVopd7KZe9kBs3r1RxoK7462fw0t9e+f66PBz7f5ao5Gz3sJUabAusd4GLhtdTnxk7mylj6PSVLPdI/UPzEGEmY4zm2MEFpXOAmQLTs= X-Gm-Message-State: AOJu0YwBrhqPU8wDv6h2XjP4OKvUzPz/VxQf+LnbSR8jNdwinbgcsprO H+4brfICpXwo3ZKJC5I3O801OtSYBNxjI+nbSx2Ty5g0MOC36Gt0CskGad+mX1c= X-Google-Smtp-Source: AGHT+IFhDPVjsigLJw8QtOGFk0xeiTZR1csgd03uKYDTTvM65zuEaSZh0hvn7jH7+Gp5nbFXTMYY6Q== X-Received: by 2002:a4a:55cb:0:b0:5a1:34cf:400c with SMTP id e194-20020a4a55cb000000b005a134cf400cmr3201440oob.9.1709570782841; Mon, 04 Mar 2024 08:46:22 -0800 (PST) Message-ID: <0c8cfbcf-d69b-499d-a915-df44713093ef@citrix.com> Date: Mon, 4 Mar 2024 16:46:18 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] xen/*/nospec: Provide common versions of evaluate_nospec/block_speculation Content-Language: en-GB To: Jan Beulich Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu , Stefano Stabellini , Julien Grall , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel , Oleksii Kurochko , Shawn Anastasio , Xen-devel References: <20240304161041.3465897-1-andrew.cooper3@citrix.com> <20240304161041.3465897-2-andrew.cooper3@citrix.com> <5220c8cf-bbc2-4f18-94ca-f1f30dd828c9@suse.com> From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <5220c8cf-bbc2-4f18-94ca-f1f30dd828c9@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 04/03/2024 4:45 pm, Jan Beulich wrote: > On 04.03.2024 17:10, Andrew Cooper wrote: >> --- a/xen/arch/x86/include/asm/nospec.h >> +++ b/xen/arch/x86/include/asm/nospec.h >> @@ -23,20 +23,20 @@ static always_inline bool barrier_nospec_false(void) >> return false; >> } >> >> -/* Allow to protect evaluation of conditionals with respect to speculation */ >> -static always_inline bool evaluate_nospec(bool condition) >> +static always_inline bool arch_evaluate_nospec(bool condition) >> { >> if ( condition ) >> return barrier_nospec_true(); >> else >> return barrier_nospec_false(); >> } >> +#define arch_evaluate_nospec arch_evaluate_nospec >> >> -/* Allow to block speculative execution in generic code */ >> -static always_inline void block_speculation(void) >> +static always_inline void arch_block_speculation(void) >> { >> barrier_nospec_true(); >> } >> +#define arch_block_speculation arch_block_speculation > I'm having some difficulty seeing the need for the renaming (adding > or the arch_ prefixes): Why can't the original names be kept, and > ... > >> --- a/xen/include/xen/nospec.h >> +++ b/xen/include/xen/nospec.h >> @@ -9,6 +9,29 @@ >> >> #include >> >> +/* >> + * Protect a conditional branch from bad speculation. Architectures *must* >> + * provide arch_evaluate_nospec() for this to be effective. >> + */ >> +static always_inline bool evaluate_nospec(bool cond) >> +{ >> +#ifndef arch_evaluate_nospec >> +#define arch_evaluate_nospec(cond) cond >> +#endif >> + return arch_evaluate_nospec(cond); >> +} >> + >> +/* >> + * Halt speculation unconditonally. Architectures *must* provide >> + * arch_block_speculation() for this to be effective. >> + */ >> +static always_inline void block_speculation(void) >> +{ >> +#ifdef arch_block_speculation >> + arch_block_speculation(); >> +#endif >> +} > ... stubs be introduced here if the original names aren't #define-d? > IOW what does the extra layer gain us? See the next patch. ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Mar 04 16:46:48 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 16:46:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688464.1072601 (Exim 4.92) (envelope-from ) id 1rhBSf-0007yz-SG; Mon, 04 Mar 2024 16:46:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688464.1072601; Mon, 04 Mar 2024 16:46:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhBSf-0007ys-PQ; Mon, 04 Mar 2024 16:46:45 +0000 Received: by outflank-mailman (input) for mailman id 688464; Mon, 04 Mar 2024 16:46:45 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhBSf-0007yd-5Q for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 16:46:45 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhBSZ-0003VU-C1; Mon, 04 Mar 2024 16:46:39 +0000 Received: from gw1.octic.net ([88.97.20.152] helo=[10.0.1.240]) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1rhBSZ-0002yb-6T; Mon, 04 Mar 2024 16:46:39 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID; bh=V7Ujo7GmuwqZz0sSemhtsATPgA/frtSwwN4i/1VZBcs=; b=rjFBC2iSRQwwrJbD1Jnc5pw4q0 27GhCUAbtQGbMBYFLdAfVkdi0BwUKDWffH/iVs3zpU4HUY6qbvM32iNo0rkjWOvy2xjgQdu0Wzxvw DTwbiODtxjblOU4KBtph34VOhxeDlzGuNGGfRtfPGinqXc323o8++EwV1tJWWUaREYNU=; Message-ID: <5c06c437-b62c-4bee-8694-1be597887718@xen.org> Date: Mon, 4 Mar 2024 16:46:37 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] xen/*/nospec: Provide common versions of evaluate_nospec/block_speculation Content-Language: en-GB To: Jan Beulich Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu , Stefano Stabellini , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel , Oleksii Kurochko , Shawn Anastasio , Xen-devel , Andrew Cooper References: <20240304161041.3465897-1-andrew.cooper3@citrix.com> <20240304161041.3465897-2-andrew.cooper3@citrix.com> From: Julien Grall In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Jan, On 04/03/2024 16:41, Jan Beulich wrote: > On 04.03.2024 17:31, Julien Grall wrote: >> On 04/03/2024 16:10, Andrew Cooper wrote: >>> It is daft to require all architectures to provide empty implementations of >>> this functionality. >> >> Oleksii recenlty sent a similar patch [1]. This was pushed back because >> from naming, it sounds like the helpers ought to be non-empty on every >> architecture. >> >> It would be best if asm-generic provides a safe version of the helpers. >> So my preference is to not have this patch. This can of course change if >> I see an explanation why it is empty on Arm (I believe it should contain >> csdb) and other arch would want the same. > > Except that there's no new asm-generic/ header here (as opposed to how > Oleksii had it). Imo avoiding the need for empty stubs is okay this way, > when introducing an asm-generic/ header would not have been. Of course > if Arm wants to put something there rather sooner than later, then > perhaps the functions better wouldn't be removed from there, just to then > be put back pretty soon. I am confused. I agree the patch is slightly different, but I thought the fundamental problem was the block_speculation() implementation may not be safe everywhere. And it was best to let each architecture decide how they want to implement (vs Xen decide for us the default). Reading the original thread, I thought you had agreed with that statement. Did I misinterpret? Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Mon Mar 04 16:48:02 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 16:48:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688467.1072611 (Exim 4.92) (envelope-from ) id 1rhBTt-0000Er-67; Mon, 04 Mar 2024 16:48:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688467.1072611; Mon, 04 Mar 2024 16:48:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhBTt-0000Ek-3F; Mon, 04 Mar 2024 16:48:01 +0000 Received: by outflank-mailman (input) for mailman id 688467; Mon, 04 Mar 2024 16:48:00 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhBTs-0000Ee-AT for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 16:48:00 +0000 Received: from mail-oo1-xc2b.google.com (mail-oo1-xc2b.google.com [2607:f8b0:4864:20::c2b]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id f4154e3e-da46-11ee-a1ee-f123f15fe8a2; Mon, 04 Mar 2024 17:47:58 +0100 (CET) Received: by mail-oo1-xc2b.google.com with SMTP id 006d021491bc7-5a11a6a08f2so1216216eaf.1 for ; Mon, 04 Mar 2024 08:47:58 -0800 (PST) Received: from [10.80.67.149] (default-46-102-197-194.interdsl.co.uk. [46.102.197.194]) by smtp.gmail.com with ESMTPSA id ev7-20020a056820310700b005a11b24176csm1033441oob.15.2024.03.04.08.47.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Mar 2024 08:47:55 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f4154e3e-da46-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709570877; x=1710175677; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=gHKl9xdwQ2yL9X6zUGAmLm1d7Ptxuf99vBL2Pl4xmZ8=; b=jci4qOwJN+gYWLfrJbeSVRyZNeLK/Gqyq3rvaY7P5+4QeIuZNSAxvi2rC4sDlpgjHG jUS2XWkPylxpzAqUJp9+aPFkyg2859bCpwc7Q6ViemFND8puAJqqTrJfct/zz7IYVTh+ Y/B3B/suuxpDVYiCuwba86tlGoTjS19jFfo/4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709570877; x=1710175677; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=gHKl9xdwQ2yL9X6zUGAmLm1d7Ptxuf99vBL2Pl4xmZ8=; b=qxlBPubL7lFYIjgquqKMHIodOlghmQDq99Vk+P+A08PVPmdeJG/jAA25HdEt/plDrm U+rEO+EbbBGrinpkguayqMfs04uXKNGU9Qz797yeB/5fKpwl0+jKutlVDD7GT7ow2Ue5 pEZ3fX917ALF0EeOwV/LqZ5uHZEt7edF7HLDzSHkcGf1ZKW95hyS00Ax2mVSF38378Hm 6LmhIY+Ug8DQl0Lq+0WGdp74+cVHWCWoFiQaB+I6/zVh0I5c+KT+lXsn0t418wIkrhNu RteSMbz7XxPp6o2lg2KoRol9lzL1FO1xrbiC1ONLO/IJ9Nefzim3s0NZp+o7FNFn/XI1 +9Lw== X-Forwarded-Encrypted: i=1; AJvYcCX6C4aL5IuepDB4l8rM0egRSR+5W7yoK3hFKSKmSnKW8zu0DU2vYZ5oPEj7Ohpehk5TEvglCjb/tLvp7cyEoS3SnBqMYVQlF/DBQlxhNOo= X-Gm-Message-State: AOJu0YzQZwMG5Vt6vVpwOkmK0PCfgiVg9DWMPLdW6v0bANod7cbxTLb/ KbRmLKaPlJDbjNL1kA/J4FoiU4hO09DyOPoc38ZQwY5wqS3k1E9C6xlFSUINOTE= X-Google-Smtp-Source: AGHT+IEuwEOl8qHZfpPh75bW1KD46Q6ssaKiM1+bE+8bMndphZHX9YiRmvc/sXXaKM6HpHgeF9HJuA== X-Received: by 2002:a4a:251d:0:b0:5a1:1e5e:1fce with SMTP id g29-20020a4a251d000000b005a11e5e1fcemr5237077ooa.1.1709570876837; Mon, 04 Mar 2024 08:47:56 -0800 (PST) Message-ID: Date: Mon, 4 Mar 2024 16:47:54 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] xen/*/nospec: Provide common versions of evaluate_nospec/block_speculation Content-Language: en-GB To: Jan Beulich , Julien Grall Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu , Stefano Stabellini , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel , Oleksii Kurochko , Shawn Anastasio , Xen-devel References: <20240304161041.3465897-1-andrew.cooper3@citrix.com> <20240304161041.3465897-2-andrew.cooper3@citrix.com> From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 04/03/2024 4:41 pm, Jan Beulich wrote: > On 04.03.2024 17:31, Julien Grall wrote: >> On 04/03/2024 16:10, Andrew Cooper wrote: >>> It is daft to require all architectures to provide empty implementations of >>> this functionality. >> Oleksii recenlty sent a similar patch [1]. This was pushed back because >> from naming, it sounds like the helpers ought to be non-empty on every >> architecture. >> >> It would be best if asm-generic provides a safe version of the helpers. >> So my preference is to not have this patch. This can of course change if >> I see an explanation why it is empty on Arm (I believe it should contain >> csdb) and other arch would want the same. > Except that there's no new asm-generic/ header here (as opposed to how > Oleksii had it). Imo avoiding the need for empty stubs is okay this way, > when introducing an asm-generic/ header would not have been. Of course > if Arm wants to put something there rather sooner than later, then > perhaps the functions better wouldn't be removed from there, just to then > be put back pretty soon. If the ARM maintainers want Spectre-v1 safety then they can do the work themselves, after this patch has gone in. ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Mar 04 16:55:35 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 16:55:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688471.1072623 (Exim 4.92) (envelope-from ) id 1rhBb6-0002bj-1n; Mon, 04 Mar 2024 16:55:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688471.1072623; Mon, 04 Mar 2024 16:55:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhBb5-0002bc-VY; Mon, 04 Mar 2024 16:55:27 +0000 Received: by outflank-mailman (input) for mailman id 688471; Mon, 04 Mar 2024 16:55:26 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhBb4-0002bW-BG for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 16:55:26 +0000 Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [2a00:1450:4864:20::52e]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id fee09b49-da47-11ee-afda-a90da7624cb6; Mon, 04 Mar 2024 17:55:25 +0100 (CET) Received: by mail-ed1-x52e.google.com with SMTP id 4fb4d7f45d1cf-566adfeced4so4960330a12.1 for ; Mon, 04 Mar 2024 08:55:25 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id zh14-20020a170906880e00b00a456573f9c5sm962292ejb.0.2024.03.04.08.55.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Mar 2024 08:55:24 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fee09b49-da47-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709571324; x=1710176124; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=RNFZEtzSJ+jfThZTaJeRrh/ySGvQQLfYI0+jZ2xyf0w=; b=AHR25hecsVyY4jlRCM3ep8JNxpt9F432fh2+VvRYBbXNCgkZAAo3fQt84j+rOdksLr PqRqd231yLH5v5PPGb3XIE6tKDsc/8dsblvfDjXxHTt9/XiH2tUJwB2OfflG+ryC3cJL 77BYh7tQ3Ne1LPmd6kw+7Gnl/aVdQ2VA00oRUrdNbUDv19A3h94yzacOlICXMJH2Iaqp nwlhubS3dElh/C6dMmrIgtjCfa3ffvuO1vJr3gm6ZDTYN9e7+y4cJEzoNtcBwnT6aEEF 1h1caotBpZr/PI6vIP9fdQiZ+qobaM9Ld5k5jkkhO7VUxarkxc3HuUGStaIh+rWGBf2+ AYsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709571324; x=1710176124; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=RNFZEtzSJ+jfThZTaJeRrh/ySGvQQLfYI0+jZ2xyf0w=; b=S8huiqtfnSaGAk4wDanWp+UvK6sx0pCdGZ6zGYNzDSuQbqswYLXordKP5FQ2NvDjDt hCCHJdJBVC6IIV+Cq3gXiSd5XOYre9HXiAKYuaFdiuqsUjQ+2390KEBp0BeAGmNmmFe8 C33xJ3V+i2EykYL6Dwgh9b3arrtPtRstu7PtWUcAWNlboUxHXdE93OLU1VVsRK+hiTF3 BrPh7As20ASP2/AyC7ROrIa9tbU6AjVVK9zU0Y0g4IQ8Mi0vufBFzHbyyzGJFOKGAi6P S+RPSfcUWvcCnfPKhqmjp1WKPlniErQQ5T9tkkjverfC6ncUE5U6jOeKtUfjojCg83cT ukFg== X-Forwarded-Encrypted: i=1; AJvYcCUJkdesmLo7TsyMP2ZRJyhRCGILDo4+tl0VH9UnJcvJlbZsWMKlHpg/eZzFubbUgVlgBClAaPgIEmyZ5X8hp7yvAhOmGIwiQfkhNh/z4X4= X-Gm-Message-State: AOJu0Yzt5mve7hy2JrNKXvXUChpzTSJ09Ia2Lj8LElZ976GfSl11dbJ8 sIg3O29mlLjpQlKW414HqutxfNJ1Zi0mrUARB1cEvqAI+MLs+ZflWIdbXVay7g== X-Google-Smtp-Source: AGHT+IGwsm6Oo+lqBQZLQcBjgPg2tqH2eB8mW3pw3q2ZpiqpREEVrrJGIJgAtNLRQmpgS5ReAclfHA== X-Received: by 2002:a17:906:f9c9:b0:a43:a834:c301 with SMTP id lj9-20020a170906f9c900b00a43a834c301mr7012574ejb.46.1709571324460; Mon, 04 Mar 2024 08:55:24 -0800 (PST) Message-ID: <141ed8a2-df4f-492c-a192-4ffa7f4c8384@suse.com> Date: Mon, 4 Mar 2024 17:55:22 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] xen/*/nospec: Provide common versions of evaluate_nospec/block_speculation Content-Language: en-US To: Julien Grall Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu , Stefano Stabellini , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel , Oleksii Kurochko , Shawn Anastasio , Xen-devel , Andrew Cooper References: <20240304161041.3465897-1-andrew.cooper3@citrix.com> <20240304161041.3465897-2-andrew.cooper3@citrix.com> <5c06c437-b62c-4bee-8694-1be597887718@xen.org> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <5c06c437-b62c-4bee-8694-1be597887718@xen.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 04.03.2024 17:46, Julien Grall wrote: > On 04/03/2024 16:41, Jan Beulich wrote: >> On 04.03.2024 17:31, Julien Grall wrote: >>> On 04/03/2024 16:10, Andrew Cooper wrote: >>>> It is daft to require all architectures to provide empty implementations of >>>> this functionality. >>> >>> Oleksii recenlty sent a similar patch [1]. This was pushed back because >>> from naming, it sounds like the helpers ought to be non-empty on every >>> architecture. >>> >>> It would be best if asm-generic provides a safe version of the helpers. >>> So my preference is to not have this patch. This can of course change if >>> I see an explanation why it is empty on Arm (I believe it should contain >>> csdb) and other arch would want the same. >> >> Except that there's no new asm-generic/ header here (as opposed to how >> Oleksii had it). Imo avoiding the need for empty stubs is okay this way, >> when introducing an asm-generic/ header would not have been. Of course >> if Arm wants to put something there rather sooner than later, then >> perhaps the functions better wouldn't be removed from there, just to then >> be put back pretty soon. > > I am confused. I agree the patch is slightly different, but I thought > the fundamental problem was the block_speculation() implementation may > not be safe everywhere. And it was best to let each architecture decide > how they want to implement (vs Xen decide for us the default). > > Reading the original thread, I thought you had agreed with that > statement. Did I misinterpret? Yes and no. Whatever is put in asm-generic/ ought to be correct and safe by default, imo. The same doesn't apply to fallbacks put in place in headers in xen/: If an arch doesn't provide its own implementation, it indicates that the default (fallback) is good enough. Still I can easily see that other views are possible here ... Jan From xen-devel-bounces@lists.xenproject.org Mon Mar 04 17:08:16 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 17:08:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688478.1072636 (Exim 4.92) (envelope-from ) id 1rhBnH-00050d-61; Mon, 04 Mar 2024 17:08:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688478.1072636; Mon, 04 Mar 2024 17:08:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhBnH-00050W-3H; Mon, 04 Mar 2024 17:08:03 +0000 Received: by outflank-mailman (input) for mailman id 688478; Mon, 04 Mar 2024 17:08:02 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhBnG-00050Q-Lg for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 17:08:02 +0000 Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [2607:f8b0:4864:20::729]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id c0b1b46f-da49-11ee-a1ee-f123f15fe8a2; Mon, 04 Mar 2024 18:08:00 +0100 (CET) Received: by mail-qk1-x729.google.com with SMTP id af79cd13be357-7882a0bcf82so48531985a.0 for ; Mon, 04 Mar 2024 09:08:00 -0800 (PST) Received: from [10.80.67.149] (default-46-102-197-194.interdsl.co.uk. [46.102.197.194]) by smtp.gmail.com with ESMTPSA id az17-20020a05620a171100b007882b4cecf8sm833945qkb.57.2024.03.04.09.07.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Mar 2024 09:07:58 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c0b1b46f-da49-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709572079; x=1710176879; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=grBI+R5l7zUIrymp7ugv/IqxjfbJ+5u0sP9KyA3WXxU=; b=Fu7F1dyrHr9j42/rErYmlqR+l7WTh21VTNjJdzy3RmGnFoGyPrr2/tMQWuRawwuK6L d6VmP/e1URvpC5Bglhgkd39SSwrbfhnx5T7vbHYCENYGEpbb7d4rvqfzaaIE+0S7o7Up Pm5p56lVaEbwo1szucTrJAy4rcC0KpCDFXiSk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709572079; x=1710176879; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=grBI+R5l7zUIrymp7ugv/IqxjfbJ+5u0sP9KyA3WXxU=; b=EUs5ERGGbQJpQGP8wkSzAQG2qZ4VsNUyOzW9smkr8FtG23S0UE56ypKn2OfIaZDDOV 1YSLa1em9M9TOxvUZFGdmdx8yjm6OVNv4RG/+BCOGZsuq22tJC5swL0wpLVLdbVyjnHa ZdBE3LBvtwfoxfW1sq8Y4fcYW8ToOFxcuGvao0LhDVdWDT29LmvlzxI59YVEQlDVc3ki Whe58yV+k55il8E2n6MpIk9Yv7Xwna56JtLNTRQWejTOPoqJhSMN1fWDjJ5KCOi9EvR5 fMhEZeDulgmK2De64lSbTq0milbjm7Q3D7dqYSdEEEU9RPfXOCiBYk9FQFbmQZyjtmsk b3ww== X-Forwarded-Encrypted: i=1; AJvYcCXbsTcyyjlb5TjSN0zRWUXBU933xSa+DTGWDeIOX7HRGJnhCOOLqVXsxWC/vYySy9EFQWaOHTTJVNfScva2oHJm3Emah+8ChxLTolR0av4= X-Gm-Message-State: AOJu0YymtgtaNiFYqw7D0YSdH34jEnY5wkuRPCCGC+sQyjwj6Kzyn44n QKFnFqX6tFCnRHLrulYRqV64M6j0MFJ8HKH7Uorux8uGKxlQRVwpRjs3yHOCsIY= X-Google-Smtp-Source: AGHT+IGuHOc6tkDINx8wJCfd5VXYquM7FrFGugq3Sib5v0L0ZrB9qQQqnb89/569AadrA7jNXUhK5w== X-Received: by 2002:a37:c441:0:b0:788:1a86:5428 with SMTP id h1-20020a37c441000000b007881a865428mr7721276qkm.58.1709572079072; Mon, 04 Mar 2024 09:07:59 -0800 (PST) Message-ID: <4fb729fa-8519-4244-a795-cc66a79cd346@citrix.com> Date: Mon, 4 Mar 2024 17:07:55 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] xen/*/nospec: Provide common versions of evaluate_nospec/block_speculation Content-Language: en-GB To: Jan Beulich , Julien Grall Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu , Stefano Stabellini , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel , Oleksii Kurochko , Shawn Anastasio , Xen-devel References: <20240304161041.3465897-1-andrew.cooper3@citrix.com> <20240304161041.3465897-2-andrew.cooper3@citrix.com> <5c06c437-b62c-4bee-8694-1be597887718@xen.org> <141ed8a2-df4f-492c-a192-4ffa7f4c8384@suse.com> From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <141ed8a2-df4f-492c-a192-4ffa7f4c8384@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 04/03/2024 4:55 pm, Jan Beulich wrote: > On 04.03.2024 17:46, Julien Grall wrote: >> On 04/03/2024 16:41, Jan Beulich wrote: >>> On 04.03.2024 17:31, Julien Grall wrote: >>>> On 04/03/2024 16:10, Andrew Cooper wrote: >>>>> It is daft to require all architectures to provide empty implementations of >>>>> this functionality. >>>> Oleksii recenlty sent a similar patch [1]. This was pushed back because >>>> from naming, it sounds like the helpers ought to be non-empty on every >>>> architecture. >>>> >>>> It would be best if asm-generic provides a safe version of the helpers. >>>> So my preference is to not have this patch. This can of course change if >>>> I see an explanation why it is empty on Arm (I believe it should contain >>>> csdb) and other arch would want the same. >>> Except that there's no new asm-generic/ header here (as opposed to how >>> Oleksii had it). Imo avoiding the need for empty stubs is okay this way, >>> when introducing an asm-generic/ header would not have been. Of course >>> if Arm wants to put something there rather sooner than later, then >>> perhaps the functions better wouldn't be removed from there, just to then >>> be put back pretty soon. >> I am confused. I agree the patch is slightly different, but I thought >> the fundamental problem was the block_speculation() implementation may >> not be safe everywhere. And it was best to let each architecture decide >> how they want to implement (vs Xen decide for us the default). >> >> Reading the original thread, I thought you had agreed with that >> statement. Did I misinterpret? > Yes and no. Whatever is put in asm-generic/ ought to be correct and safe > by default, imo. The same doesn't apply to fallbacks put in place in > headers in xen/: If an arch doesn't provide its own implementation, it > indicates that the default (fallback) is good enough. Still I can easily > see that other views are possible here ... With speculation, there's absolutely nothing we can possibly do in any common code which will be safe generally. But we can make it less invasive until an architecture wants to implement the primitives. ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Mar 04 17:40:35 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 17:40:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688482.1072646 (Exim 4.92) (envelope-from ) id 1rhCIf-00043B-B2; Mon, 04 Mar 2024 17:40:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688482.1072646; Mon, 04 Mar 2024 17:40:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhCIf-000434-8V; Mon, 04 Mar 2024 17:40:29 +0000 Received: by outflank-mailman (input) for mailman id 688482; Mon, 04 Mar 2024 17:40:28 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhCIe-00042y-0F for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 17:40:28 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhCIY-0004Yh-J5; Mon, 04 Mar 2024 17:40:22 +0000 Received: from gw1.octic.net ([88.97.20.152] helo=[10.0.1.240]) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1rhCIY-0001CH-2h; Mon, 04 Mar 2024 17:40:22 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID; bh=RGsUwa//dPMPat4ZgLkkCxnIgeKnDm03hKCkOxNBamk=; b=KzrEbwhlt2uWAR1gA6e9NjjnH1 pGKCG1oKLcnt9aq+OPru5R2EFJl7jfGXWGqsuVWpp48StYnV/5RHFUXtX4CBZlupzUrjM34PMkIpH z1si6SyF3xZSh20ZV6ZYlvgHOtEHxawArbfV35p93CoTpXyOOauFhBTRYCIHTWmHBMqc=; Message-ID: Date: Mon, 4 Mar 2024 17:40:19 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] xen/*/nospec: Provide common versions of evaluate_nospec/block_speculation Content-Language: en-GB To: Andrew Cooper , Jan Beulich Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu , Stefano Stabellini , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel , Oleksii Kurochko , Shawn Anastasio , Xen-devel References: <20240304161041.3465897-1-andrew.cooper3@citrix.com> <20240304161041.3465897-2-andrew.cooper3@citrix.com> <5c06c437-b62c-4bee-8694-1be597887718@xen.org> <141ed8a2-df4f-492c-a192-4ffa7f4c8384@suse.com> <4fb729fa-8519-4244-a795-cc66a79cd346@citrix.com> From: Julien Grall In-Reply-To: <4fb729fa-8519-4244-a795-cc66a79cd346@citrix.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Andrew, On 04/03/2024 17:07, Andrew Cooper wrote: > On 04/03/2024 4:55 pm, Jan Beulich wrote: >> On 04.03.2024 17:46, Julien Grall wrote: >>> On 04/03/2024 16:41, Jan Beulich wrote: >>>> On 04.03.2024 17:31, Julien Grall wrote: >>>>> On 04/03/2024 16:10, Andrew Cooper wrote: >>>>>> It is daft to require all architectures to provide empty implementations of >>>>>> this functionality. >>>>> Oleksii recenlty sent a similar patch [1]. This was pushed back because >>>>> from naming, it sounds like the helpers ought to be non-empty on every >>>>> architecture. >>>>> >>>>> It would be best if asm-generic provides a safe version of the helpers. >>>>> So my preference is to not have this patch. This can of course change if >>>>> I see an explanation why it is empty on Arm (I believe it should contain >>>>> csdb) and other arch would want the same. >>>> Except that there's no new asm-generic/ header here (as opposed to how >>>> Oleksii had it). Imo avoiding the need for empty stubs is okay this way, >>>> when introducing an asm-generic/ header would not have been. Of course >>>> if Arm wants to put something there rather sooner than later, then >>>> perhaps the functions better wouldn't be removed from there, just to then >>>> be put back pretty soon. >>> I am confused. I agree the patch is slightly different, but I thought >>> the fundamental problem was the block_speculation() implementation may >>> not be safe everywhere. And it was best to let each architecture decide >>> how they want to implement (vs Xen decide for us the default). >>> >>> Reading the original thread, I thought you had agreed with that >>> statement. Did I misinterpret? >> Yes and no. Whatever is put in asm-generic/ ought to be correct and safe >> by default, imo. The same doesn't apply to fallbacks put in place in >> headers in xen/: If an arch doesn't provide its own implementation, it >> indicates that the default (fallback) is good enough. Still I can easily >> see that other views are possible here ... > > With speculation, there's absolutely nothing we can possibly do in any > common code which will be safe generally. > > But we can make it less invasive until an architecture wants to > implement the primitives. I understand the goal. However, I am unsure it is a good idea to provide unsafe just to reduce the arch specific header by a few lines. My concern is new ports may not realize that block_speculation() needs to be implemented. This could end to a preventable XSA in the future. I guess the risk could be reduced if we had some documentation explaining how to port Xen to a new architecture (I am not asking you to write the doc). Anyway, I understand this is a matter of perspective. I will not oppose this change if you can get others to agree with the risk. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Mon Mar 04 17:51:15 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 17:51:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688485.1072656 (Exim 4.92) (envelope-from ) id 1rhCSt-00067n-AV; Mon, 04 Mar 2024 17:51:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688485.1072656; Mon, 04 Mar 2024 17:51:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhCSt-00067g-7o; Mon, 04 Mar 2024 17:51:03 +0000 Received: by outflank-mailman (input) for mailman id 688485; Mon, 04 Mar 2024 17:51:01 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhCSr-00067a-Rs for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 17:51:01 +0000 Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [2a00:1450:4864:20::532]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id c2836331-da4f-11ee-a1ee-f123f15fe8a2; Mon, 04 Mar 2024 18:50:59 +0100 (CET) Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-565d1656c12so8473877a12.1 for ; Mon, 04 Mar 2024 09:50:59 -0800 (PST) Received: from [10.80.67.149] (default-46-102-197-194.interdsl.co.uk. [46.102.197.194]) by smtp.gmail.com with ESMTPSA id q33-20020a05640224a100b00565ba75a739sm4891282eda.95.2024.03.04.09.50.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Mar 2024 09:50:57 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c2836331-da4f-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709574659; x=1710179459; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=XTH/5M9X+QD99F4Cgi89o2BVexvz80S8A8oly2kzLtk=; b=Wnu2CbitA45UmzABlBvAfZWy8QrFdfwZt4hpByfmHaSQ5mjYUH3s+yFw5CoLs/l8g1 a/ZRVC8/wEfP7cdci7RLxgZ3Gcd6dbMeCi7077uMSc/9DsBBZYofAB0X/WcsfyBT7fkN ZkeAherg6jvf0g6PsqfRvUEgOzwfYdZVouyO0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709574659; x=1710179459; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=XTH/5M9X+QD99F4Cgi89o2BVexvz80S8A8oly2kzLtk=; b=vu+kto2cDvT0/QN/n2QcNBjzzLncJOItNNQ2/lVCwnp7NLcO+2Ec5zGbZFVJT13pqX RITl7SOvdF57JzkUY00tRDAuGihOnKY0qoGPUqesixrnRTyMT2N6ExR4IQtpLeiFmGQa gn+zMNXCVNBeVOcbTVayOgHE/UV56FYvRoYeB1TgtC+64pLcGI6+2+/cJrrhHciF5eRK ZOFXdOFV0GPgk76bQ08FgQMAY933KI4E38Nd/ihA6AK81jfG+31Bz3VNLs1MXFMYmS8C raT9F2IOcFgLJp2Q1GMVYZJBc6mb+xDQqm3/t5HXocz5/XwFA+eyPawHSGlDfw23+s+r ScpQ== X-Forwarded-Encrypted: i=1; AJvYcCVGieLXCB51Ilp9WUjLqSDHG/vvIGQozn7W3nXQfF3Oe1gWbTXdCjPL16gauQHr8GytLs6Tnopi8vY1zxcwi5SbTXu9au2DUw7RMeUJxT0= X-Gm-Message-State: AOJu0YzrB5rLx93ON0QXvLAx7ZuREigp5WnEaxoCHl+zl9gmTkinhLB0 P/kFFI/Tky2ka7TH8G8A7yTCuMUBkeVH4br6LcOvq0xFDyKxNN76/hdjndVA4wo= X-Google-Smtp-Source: AGHT+IEJ3JgG4yOU52J4GV7CmTL2YRqxMRXotWiaF1MldeztNPcvihpyxZi1QePuSuNzlcvs7Y0oWA== X-Received: by 2002:a50:85c3:0:b0:566:5cd2:873 with SMTP id q3-20020a5085c3000000b005665cd20873mr199864edh.4.1709574659156; Mon, 04 Mar 2024 09:50:59 -0800 (PST) Message-ID: <3bc0b828-d3c5-447d-b338-c478d8e337fc@citrix.com> Date: Mon, 4 Mar 2024 17:50:57 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] xen/*/nospec: Provide common versions of evaluate_nospec/block_speculation Content-Language: en-GB To: Julien Grall , Jan Beulich Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu , Stefano Stabellini , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel , Oleksii Kurochko , Shawn Anastasio , Xen-devel References: <20240304161041.3465897-1-andrew.cooper3@citrix.com> <20240304161041.3465897-2-andrew.cooper3@citrix.com> <5c06c437-b62c-4bee-8694-1be597887718@xen.org> <141ed8a2-df4f-492c-a192-4ffa7f4c8384@suse.com> <4fb729fa-8519-4244-a795-cc66a79cd346@citrix.com> From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 04/03/2024 5:40 pm, Julien Grall wrote: > Hi Andrew, > > On 04/03/2024 17:07, Andrew Cooper wrote: >> On 04/03/2024 4:55 pm, Jan Beulich wrote: >>> On 04.03.2024 17:46, Julien Grall wrote: >>>> On 04/03/2024 16:41, Jan Beulich wrote: >>>>> On 04.03.2024 17:31, Julien Grall wrote: >>>>>> On 04/03/2024 16:10, Andrew Cooper wrote: >>>>>>> It is daft to require all architectures to provide empty >>>>>>> implementations of >>>>>>> this functionality. >>>>>> Oleksii recenlty sent a similar patch [1]. This was pushed back >>>>>> because >>>>>> from naming, it sounds like the helpers ought to be non-empty on >>>>>> every >>>>>> architecture. >>>>>> >>>>>> It would be best if asm-generic provides a safe version of the >>>>>> helpers. >>>>>> So my preference is to not have this patch. This can of course >>>>>> change if >>>>>> I see an explanation why it is empty on Arm (I believe it should >>>>>> contain >>>>>> csdb) and other arch would want the same. >>>>> Except that there's no new asm-generic/ header here (as opposed to >>>>> how >>>>> Oleksii had it). Imo avoiding the need for empty stubs is okay >>>>> this way, >>>>> when introducing an asm-generic/ header would not have been. Of >>>>> course >>>>> if Arm wants to put something there rather sooner than later, then >>>>> perhaps the functions better wouldn't be removed from there, just >>>>> to then >>>>> be put back pretty soon. >>>> I am confused. I agree the patch is slightly different, but I thought >>>> the fundamental problem was the block_speculation() implementation may >>>> not be safe everywhere. And it was best to let each architecture >>>> decide >>>> how they want to implement (vs Xen decide for us the default). >>>> >>>> Reading the original thread, I thought you had agreed with that >>>> statement. Did I misinterpret? >>> Yes and no. Whatever is put in asm-generic/ ought to be correct and >>> safe >>> by default, imo. The same doesn't apply to fallbacks put in place in >>> headers in xen/: If an arch doesn't provide its own implementation, it >>> indicates that the default (fallback) is good enough. Still I can >>> easily >>> see that other views are possible here ... >> >> With speculation, there's absolutely nothing we can possibly do in any >> common code which will be safe generally. >> >> But we can make it less invasive until an architecture wants to >> implement the primitives. > > I understand the goal. However, I am unsure it is a good idea to > provide unsafe just to reduce the arch specific header by a few lines. It doesn't matter if it's unsafe in the arch header or unsafe in the common code.  It's still unsafe. There is no change in risk here.  There's simply less blind copy/pasting of the unsafe form into new architectures in order to get Xen to compile. ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Mar 04 18:18:02 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 18:18:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688489.1072666 (Exim 4.92) (envelope-from ) id 1rhCsu-0001hr-Be; Mon, 04 Mar 2024 18:17:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688489.1072666; Mon, 04 Mar 2024 18:17:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhCsu-0001hk-94; Mon, 04 Mar 2024 18:17:56 +0000 Received: by outflank-mailman (input) for mailman id 688489; Mon, 04 Mar 2024 18:17:54 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhCss-0001hc-NR for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 18:17:54 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 843e982a-da53-11ee-afda-a90da7624cb6; Mon, 04 Mar 2024 19:17:53 +0100 (CET) Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) by support.bugseng.com (Postfix) with ESMTPA id 985DC4EE0737; Mon, 4 Mar 2024 19:17:52 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 843e982a-da53-11ee-afda-a90da7624cb6 MIME-Version: 1.0 Date: Mon, 04 Mar 2024 19:17:52 +0100 From: Nicola Vetrini To: Julien Grall , Stefano Stabellini , Bertrand Marquis , Michal Orzel Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, consulting@bugseng.com, andrew.cooper3@citrix.com, roger.pau@citrix.com, bertrand.marquis@arm.com, julien@xen.org, Volodymyr Babchuk , xen-devel@lists.xenproject.org Subject: Re: [XEN PATCH 02/10] xen/arm: address some violations of MISRA C Rule 20.7 In-Reply-To: <7c54b08875406e5b3a61325af124ae7f@bugseng.com> References: <905119be-8731-4669-ac7f-c21aed6845dc@suse.com> <7c54b08875406e5b3a61325af124ae7f@bugseng.com> Message-ID: <0aae1c64587cfbc67e81a20b36dd5056@bugseng.com> X-Sender: nicola.vetrini@bugseng.com Organization: BUGSENG s.r.l. Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Hi, as the maintainers of this subsystem, would you prefer Jan's version or the one in the patch? Both are fine w.r.t MISRA Rule 20.7 because the macro arguments themselves are parenthesized. >>> --- a/xen/arch/arm/include/asm/vgic-emul.h >>> +++ b/xen/arch/arm/include/asm/vgic-emul.h >>> @@ -6,11 +6,11 @@ >>> * a range of registers >>> */ >>> >>> -#define VREG32(reg) reg ... reg + 3 >>> -#define VREG64(reg) reg ... reg + 7 >>> +#define VREG32(reg) (reg) ... (reg) + 3 >>> +#define VREG64(reg) (reg) ... (reg) + 7 >> >> #define VREG32(reg) (reg) ... ((reg) + 3) >> #define VREG64(reg) (reg) ... ((reg) + 7) >> >> ? >> > > The outer parentheses are not required, but I can add them if the > maintainers share your view. -- Nicola Vetrini, BSc Software Engineer, BUGSENG srl (https://bugseng.com) From xen-devel-bounces@lists.xenproject.org Mon Mar 04 18:28:38 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 18:28:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688492.1072677 (Exim 4.92) (envelope-from ) id 1rhD3B-0003ee-7k; Mon, 04 Mar 2024 18:28:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688492.1072677; Mon, 04 Mar 2024 18:28:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhD3B-0003eX-53; Mon, 04 Mar 2024 18:28:33 +0000 Received: by outflank-mailman (input) for mailman id 688492; Mon, 04 Mar 2024 18:28:31 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhD39-0003eN-SN; Mon, 04 Mar 2024 18:28:31 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhD39-0005Yw-O4; Mon, 04 Mar 2024 18:28:31 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhD39-0003mt-Gt; Mon, 04 Mar 2024 18:28:31 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rhD39-00007g-GP; Mon, 04 Mar 2024 18:28:31 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=X40WUB8RzlHnxTKSl0RspQKBKKfcyjyam8kBpGG57jA=; b=ZC7mV8OyrWkJBlUJ7n0hc8cn3I YYf+4FBmQDYVbxYrjDeoGfGjkG04ATJXue0kKuTe8viRAnzersgDF2YqtZEc6BOt28FIULv5sGTG5 vN7+WEoWIJQ5qMHnCjOYV0hDa8T7UYPV4JBh4QuewDfzcxspNBKSeWCjixT7T9NL7BdY=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [ovmf test] 184899: all pass - PUSHED X-Osstest-Versions-This: ovmf=bff9815b616669f1cf743e412bc0000efe22dfb4 X-Osstest-Versions-That: ovmf=1ae5bee967bffcd6dbbabca913ea3c65d8f09c76 From: osstest service owner Date: Mon, 04 Mar 2024 18:28:31 +0000 flight 184899 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/184899/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf bff9815b616669f1cf743e412bc0000efe22dfb4 baseline version: ovmf 1ae5bee967bffcd6dbbabca913ea3c65d8f09c76 Last test of basis 184892 2024-03-04 10:11:18 Z 0 days Testing same since 184899 2024-03-04 16:43:32 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Michael Kubacki 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-pvops pass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git 1ae5bee967..bff9815b61 bff9815b616669f1cf743e412bc0000efe22dfb4 -> xen-tested-master From xen-devel-bounces@lists.xenproject.org Mon Mar 04 18:38:36 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 18:38:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688497.1072686 (Exim 4.92) (envelope-from ) id 1rhDCq-0005Xx-50; Mon, 04 Mar 2024 18:38:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688497.1072686; Mon, 04 Mar 2024 18:38:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhDCq-0005Xq-25; Mon, 04 Mar 2024 18:38:32 +0000 Received: by outflank-mailman (input) for mailman id 688497; Mon, 04 Mar 2024 18:38:31 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhDCp-0005Xk-Do for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 18:38:31 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhDCo-0005kS-R4; Mon, 04 Mar 2024 18:38:30 +0000 Received: from gw1.octic.net ([88.97.20.152] helo=[10.0.1.240]) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1rhDCo-0004RF-Ku; Mon, 04 Mar 2024 18:38:30 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID; bh=jcEZnOMVBu9kIpHYszVV8cdL1paqlzXqczhG5PEfTDw=; b=QGyKQbnFTRf+KZA0vVn+84XT0n MeoqEQQBdOr14vGaopSgo/ymUk7VHJGj29prh61Jn4AaeZXKo4RvWBBn9qc3zp0QMQ80V6CuXw/xm I6ErGS2jEstJ3qSmoqm39mQpAEB7aNJGPVNeEYRSUW5QxW7ziuxsgKNQcwudE1FbfxYY=; Message-ID: <8768d244-c52c-40da-8a99-0296cb9a8ca5@xen.org> Date: Mon, 4 Mar 2024 18:38:28 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/common: Do not allocate magic pages 1:1 for direct mapped domains Content-Language: en-GB To: Henry Wang , xen-devel@lists.xenproject.org Cc: Anthony PERARD , Juergen Gross , Andrew Cooper , George Dunlap , Jan Beulich , Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Alec Kwapis References: <20240226011935.169462-1-xin.wang2@amd.com> <3982ba47-6709-47e3-a9c2-e2d3b4a2d8e3@xen.org> <8e56b75d-10a2-4764-8244-3e596f9fc695@amd.com> <98739f8d-dc00-4db8-a0b2-07f054107acf@xen.org> From: Julien Grall In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 01/03/2024 03:03, Henry Wang wrote: > Hi Julien, Hi Henry, > On 2/28/2024 8:27 PM, Julien Grall wrote: >> Hi Henry, >>> ...here basically means we want to do the finding of the unused >>> region in toolstack. Since currently what we care about is only a >>> couple of pages instead of the whole memory map, could it be possible >>> that we do the opposite: in alloc_xs_page(), we issue a domctl >>> hypercall to Xen and do the finding work in Xen and return with the >>> found gfn? Then the page can be mapped by populate_physmap() from >>> alloc_xs_page() and used for XenStore. >> >> I know that DOMCTL hypercalls are not stable. But I am not overly >> happy with creating an hypercall which is just "fetch the magic >> regions". I think it need to be a more general one that would expose >> all the regions. >> >> Also, you can't really find the magic regions when the hypercall is >> done as we don't have the guest memory layout. This will need to be >> done in advance. >> >> Overall, I think it would be better if we provide an hypercall listing >> the regions currently occupied (similar to e820). One will have the >> type "magic pages". > > Would below design make sense to you: This looks good in principle. Some comments below. > > (1) Similarly as the e820, we can firstly introduce some data structures > in struct arch_domain: > > #define MEM_REGIONS_MAX 4 > > // For now we only care the magic regions, but in the future this can be > easily extended with other types such as RAM, MMIO etc. > enum mem_region_type { >     MEM_REGION_MAGIC, > }; > > struct mem_region { >     paddr_t start; >     paddr_t size; >     enum mem_region_type type; > }; > > struct domain_mem_map { >     unsigned int nr_mem_regions; >     struct mem_region region[MEM_REGIONS_MAX]; > }; If you plan to expose the same interface externally, then you will need to replace paddr_t with uint64_t and avoid using an enum in the structure. You will also want to expose a dynamic array (even if this is fixed in the hypervisor). > > struct arch_domain { > ... >     struct domain_mem_map mem_map; > }; > > (2) Then in domain creation time, for normal and static non-directmapped > Dom0less DomU, set d->arch.mem_map.region[0].start = GUEST_MAGIC_BASE > and the size to 4 pages. For static and directmapped Dom0less DomU, find > a free region of 4 pages for magic pages. The finding of a free region > can reuse the approach for extended region and be called before > make_hypervisor_node(), and when make_hypervisor_node() is called. We > carve the magic pages out from the actual extended region. > > (3) Add a new hypercall XENMEM_memory_map_domid (or a domctl). Input > will be domid and output will be the memory map of the domain recorded > in struct arch_domain. XENMEM_* are supposed to be stable interface. I am not aware of any use in the guest yet, so I think it would be best to use a DOMCTL. > > (4) In alloc_xs_page() and alloc_magic_pages, replace the hardcoded base > address with the new address found by the hypercall. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Mon Mar 04 18:47:48 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 18:47:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688500.1072697 (Exim 4.92) (envelope-from ) id 1rhDLi-0007Ni-0V; Mon, 04 Mar 2024 18:47:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688500.1072697; Mon, 04 Mar 2024 18:47:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhDLh-0007Nb-T2; Mon, 04 Mar 2024 18:47:41 +0000 Received: by outflank-mailman (input) for mailman id 688500; Mon, 04 Mar 2024 18:47:40 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhDLg-0007NT-M6 for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 18:47:40 +0000 Received: from smtp-fw-2101.amazon.com (smtp-fw-2101.amazon.com [72.21.196.25]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id abf442e5-da57-11ee-a1ee-f123f15fe8a2; Mon, 04 Mar 2024 19:47:38 +0100 (CET) Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO smtpout.prod.us-west-2.prod.farcaster.email.amazon.dev) ([10.43.8.6]) by smtp-border-fw-2101.iad2.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Mar 2024 18:47:35 +0000 Received: from EX19MTAEUC002.ant.amazon.com [10.0.43.254:47643] by smtpin.naws.eu-west-1.prod.farcaster.email.amazon.dev [10.0.42.5:2525] with esmtp (Farcaster) id abeaadb9-70cd-4744-b817-67fa8b437c78; Mon, 4 Mar 2024 18:47:33 +0000 (UTC) Received: from EX19D026EUB004.ant.amazon.com (10.252.61.64) by EX19MTAEUC002.ant.amazon.com (10.252.51.245) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.28; Mon, 4 Mar 2024 18:47:33 +0000 Received: from uc3ecf78c6baf56.ant.amazon.com (10.187.170.53) by EX19D026EUB004.ant.amazon.com (10.252.61.64) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.28; Mon, 4 Mar 2024 18:47:30 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: abf442e5-da57-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1709578058; x=1741114058; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=9wd9WUH4whGwXp0eHXVUdDwqcrqNWWjri6sAP3vphCI=; b=NOA8+81x7UlfsFakR5IQbhS9SIv1BV3DF9n9KdxaBU5FAJbEDtY1IDX6 raXjT/iehSw87DSk4ijD0o1xPqxd86k0XEhuRUWQQEAs2hlg9NXfyApE7 v4n1u4q6M3M8QYTqFaLUS2K2M3lPDYlXyTT94QdamYf1ia6gZy2DoFtbO g=; X-IronPort-AV: E=Sophos;i="6.06,204,1705363200"; d="scan'208";a="385374124" X-Farcaster-Flow-ID: abeaadb9-70cd-4744-b817-67fa8b437c78 Date: Mon, 4 Mar 2024 10:47:26 -0800 From: Andrew Panyakin To: Greg KH CC: , , , , , , , , , , , , , Subject: Re: [PATCH 5.10] xen/events: close evtchn after mapping cleanup Message-ID: <20240304184726.GA3441283@uc3ecf78c6baf56.ant.amazon.com> References: <20240302160357.GA2232656@uc3ecf78c6baf56.ant.amazon.com> <2024030433-legacy-unrivaled-f5fc@gregkh> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <2024030433-legacy-unrivaled-f5fc@gregkh> X-Originating-IP: [10.187.170.53] X-ClientProxiedBy: EX19D031UWC002.ant.amazon.com (10.13.139.212) To EX19D026EUB004.ant.amazon.com (10.252.61.64) On 04/03/2024, Greg KH wrote: > On Sat, Mar 02, 2024 at 08:03:57AM -0800, Andrew Panyakin wrote: > > From: Maximilian Heyne > > > > Commit fa765c4b4aed2d64266b694520ecb025c862c5a9 upstream [...] > Where is the 5.15.y version of this commit? We have to have that before > we can take a 5.10.y version, right? Remaining patches for 5.15 and 6.1 ready, will send once analyze test results. From xen-devel-bounces@lists.xenproject.org Mon Mar 04 19:19:36 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 19:19:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688503.1072706 (Exim 4.92) (envelope-from ) id 1rhDqM-0003jI-Bo; Mon, 04 Mar 2024 19:19:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688503.1072706; Mon, 04 Mar 2024 19:19:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhDqM-0003jB-94; Mon, 04 Mar 2024 19:19:22 +0000 Received: by outflank-mailman (input) for mailman id 688503; Mon, 04 Mar 2024 19:19:21 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhDqL-0003he-5B; Mon, 04 Mar 2024 19:19:21 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhDqL-0006YY-0u; Mon, 04 Mar 2024 19:19:21 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhDqK-0005Uk-K4; Mon, 04 Mar 2024 19:19:20 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rhDqK-0005ml-Jd; Mon, 04 Mar 2024 19:19:20 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=aLCUg/YfQXVZbWIzT94k11p7XBFYkQmivwDjb6XIx/U=; b=h+2O//E4xR5IFtfbp4v4T+jNuF a2DT8ag9eeB2JYx0XSk+0kZ4v1xKBN2bEQ55IyqEdaKWLbESnOaoixc+8ur7Vf8MHgWW/+IOvLxYf MHsEYwSEk0DJDuOuRRGR5SWyu1qe68K3GxK24uqBruo1ePC5EJzI7umgxqUBjVKqa6do=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable test] 184890: trouble: broken/fail/pass X-Osstest-Failures: xen-unstable:test-armhf-armhf-libvirt::broken:regression xen-unstable:test-armhf-armhf-libvirt:host-install(5):broken:heisenbug xen-unstable:test-amd64-amd64-xl-qemut-debianhvm-i386-xsm:debian-hvm-install:fail:heisenbug xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:windows-install:fail:heisenbug xen-unstable:test-amd64-i386-libvirt-pair:guest-migrate/dst_host/src_host/debian.repeat:fail:heisenbug xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: xen=856664f774bd5b66301c5f9022126b61b8cb492d X-Osstest-Versions-That: xen=efad36f1ba18946acecc030166b1a6bebeb88ea2 From: osstest service owner Date: Mon, 04 Mar 2024 19:19:20 +0000 flight 184890 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/184890/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt broken Tests which are failing intermittently (not blocking): test-armhf-armhf-libvirt 5 host-install(5) broken pass in 184882 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail in 184882 pass in 184890 test-amd64-amd64-xl-qemuu-win7-amd64 12 windows-install fail in 184882 pass in 184890 test-amd64-i386-libvirt-pair 28 guest-migrate/dst_host/src_host/debian.repeat fail pass in 184882 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail blocked in 184833 test-armhf-armhf-libvirt 16 saverestore-support-check fail in 184882 like 184833 test-armhf-armhf-libvirt 15 migrate-support-check fail in 184882 never pass test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop fail like 184833 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 184833 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop fail like 184833 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 184833 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 184833 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop fail like 184833 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 184833 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184833 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 184833 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop fail like 184833 test-amd64-amd64-libvirt-xsm 15 migrate-support-check fail never pass test-amd64-i386-xl-pvshim 14 guest-start fail never pass test-amd64-i386-libvirt 15 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-check fail never pass test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-check fail never pass test-arm64-arm64-xl 15 migrate-support-check fail never pass test-arm64-arm64-xl 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 15 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-check fail never pass test-amd64-i386-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-check fail never pass test-arm64-arm64-xl-vhd 14 migrate-support-check fail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-check fail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-check fail never pass version targeted for testing: xen 856664f774bd5b66301c5f9022126b61b8cb492d baseline version: xen efad36f1ba18946acecc030166b1a6bebeb88ea2 Last test of basis 184833 2024-03-01 14:11:30 Z 3 days Testing same since 184852 2024-03-02 16:36:22 Z 2 days 4 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Bertrand Marquis Roger Pau Monné Stefano Stabellini jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-dom0pvh-xl-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-qemuu-freebsd11-amd64 pass test-amd64-amd64-qemuu-freebsd12-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-examine-bios pass test-amd64-i386-examine-bios pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-dom0pvh-xl-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt broken test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair fail test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-armhf-armhf-libvirt-qcow2 pass test-amd64-amd64-xl-qcow2 pass test-arm64-arm64-libvirt-raw pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-libvirt-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-examine-uefi pass test-amd64-i386-examine-uefi pass test-amd64-amd64-libvirt-vhd pass test-arm64-arm64-xl-vhd pass test-armhf-armhf-xl-vhd pass test-amd64-i386-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these 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 broken-job test-armhf-armhf-libvirt broken broken-step test-armhf-armhf-libvirt host-install(5) Not pushing. ------------------------------------------------------------ commit 856664f774bd5b66301c5f9022126b61b8cb492d Author: Stefano Stabellini Date: Tue Feb 13 14:33:34 2024 -0800 docs/misra/rules.rst: add rule 14.4 Signed-off-by: Stefano Stabellini Acked-by: Bertrand Marquis commit c40bc0576dcc5acd4d7e22ef628eb4642f568533 Author: Roger Pau Monné Date: Fri Mar 1 13:42:27 2024 +0100 x86/mm: re-implement get_page_light() using an atomic increment The current usage of a cmpxchg loop to increase the value of page count is not optimal on amd64, as there's already an instruction to do an atomic add to a 64bit integer. Switch the code in get_page_light() to use an atomic increment, as that avoids a loop construct. This slightly changes the order of the checks, as current code will crash before modifying the page count_info if the conditions are not correct, while with the proposed change the crash will happen immediately after having carried the counter increase. Since we are crashing anyway, I don't believe the re-ordering to have any meaningful impact. Note that the page must already have a non-zero reference count which prevents the flags from changing, and the previous usage of the cmpxchg loop didn't guarantee that the rest of the fields in count_info didn't change while updating the reference count. Signed-off-by: Roger Pau Monné Reviewed-by: Andrew Cooper commit de17162cafd27f2865a3102a2ec0f386a02ed03d Author: Andrew Cooper Date: Thu Feb 29 11:26:40 2024 +0000 x86/cpu-policy: Allow for levelling of VERW side effects MD_CLEAR and FB_CLEAR need OR-ing across a migrate pool. Allow this, by having them unconditinally set in max, with the host values reflected in default. Annotate the bits as having special properies. Signed-off-by: Andrew Cooper Reviewed-by: Roger Pau Monné commit 0263dc9069ddb66335c72a159e09050b1600e56a Author: Andrew Cooper Date: Thu Feb 29 20:46:13 2024 +0000 tests/resource: Fix HVM guest in !SHADOW builds Right now, test-resource always creates HVM Shadow guests. But if Xen has SHADOW compiled out, running the test yields: $./test-resource XENMEM_acquire_resource tests Test x86 PV Created d1 Test grant table Test x86 PVH Skip: 95 - Operation not supported and doesn't really test HVM guests, but doesn't fail either. There's nothing paging-mode-specific about this test, so default to HAP if possible and provide a more specific message if neither HAP or Shadow are available. As we've got physinfo to hand, also provide more specific message about the absence of PV or HVM support. Signed-off-by: Andrew Cooper Acked-by: Roger Pau Monné commit e2d8a652251660c3252d92b442e1a9c5d6e6a1e9 Author: Andrew Cooper Date: Wed Feb 28 20:22:24 2024 +0000 x86/cpu-policy: Fix visibility of HTT/CMP_LEGACY in max policies The block in recalculate_cpuid_policy() predates the proper split between default and max policies, and was a "slightly max for a toolstack which knows about it" capability. It didn't get transformed properly in Xen 4.14. Because Xen will accept a VM with HTT/CMP_LEGACY seen, they should be visible in the max polices. Keep the default policy matching host settings. This manifested as an incorrectly-rejected migration across XenServer's Xen 4.13 -> 4.17 upgrade, as Xapi is slowly growing the logic to check a VM against the target max policy. Signed-off-by: Andrew Cooper Reviewed-by: Roger Pau Monné commit 5420aa165dfa5fe95dd84bb71cb96c15459935b1 Author: Andrew Cooper Date: Wed Feb 28 20:21:58 2024 +0000 x86/cpu-policy: Hide x2APIC from PV guests PV guests can't write to MSR_APIC_BASE (in order to set EXTD), nor can they access any of the x2APIC MSR range. Therefore they mustn't see the x2APIC CPUID bit saying that they can. Right now, the host x2APIC flag filters into PV guests, meaning that PV guests generally see x2APIC except on Zen1-and-older AMD systems. Linux works around this by explicitly hiding the bit itself, and filtering EXTD out of MSR_APIC_BASE reads. NetBSD behaves more in the spirit of PV guests, and entirely ignores the APIC when built as a PV guest. Change the annotation from !A to !S. This has a consequence of stripping it out of both PV featuremasks. However, as existing guests may have seen the bit, set it back into the PV Max policy; a VM which saw the bit and is alive enough to migrate will have ignored it one way or another. Hiding x2APIC does change the contents of leaf 0xb, but as the information is nonsense to begin with, this is likely an improvement on the status quo. Xen's blind assumption that APIC_ID = vCPU_ID * 2 isn't interlinked with the host's topology structure, where a PV guest may see real host values, and the APIC_IDs are useless without an MADT to start with. Dom0 is the only PV VM to get an MADT but it's the host one, meaning the two sets of APIC_IDs are from different address spaces. Signed-off-by: Andrew Cooper Reviewed-by: Roger Pau Monné (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Mon Mar 04 19:20:24 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 19:20:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688508.1072716 (Exim 4.92) (envelope-from ) id 1rhDrL-0005GZ-O7; Mon, 04 Mar 2024 19:20:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688508.1072716; Mon, 04 Mar 2024 19:20:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhDrL-0005GS-LS; Mon, 04 Mar 2024 19:20:23 +0000 Received: by outflank-mailman (input) for mailman id 688508; Mon, 04 Mar 2024 19:20:22 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhDrK-0005GK-Gi for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 19:20:22 +0000 Received: from smtp-fw-80007.amazon.com (smtp-fw-80007.amazon.com [99.78.197.218]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 3c920d46-da5c-11ee-a1ee-f123f15fe8a2; Mon, 04 Mar 2024 20:20:20 +0100 (CET) Received: from pdx4-co-svc-p1-lb2-vlan2.amazon.com (HELO smtpout.prod.us-west-2.prod.farcaster.email.amazon.dev) ([10.25.36.210]) by smtp-border-fw-80007.pdx80.corp.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Mar 2024 19:20:13 +0000 Received: from EX19MTAEUB002.ant.amazon.com [10.0.10.100:13445] by smtpin.naws.eu-west-1.prod.farcaster.email.amazon.dev [10.0.11.111:2525] with esmtp (Farcaster) id b368db1f-8b69-4baf-b72b-e07fa55b7192; Mon, 4 Mar 2024 19:20:12 +0000 (UTC) Received: from EX19D026EUB004.ant.amazon.com (10.252.61.64) by EX19MTAEUB002.ant.amazon.com (10.252.51.79) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.28; Mon, 4 Mar 2024 19:20:12 +0000 Received: from uc3ecf78c6baf56.ant.amazon.com (10.187.170.53) by EX19D026EUB004.ant.amazon.com (10.252.61.64) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.28; Mon, 4 Mar 2024 19:20:09 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3c920d46-da5c-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1709580020; x=1741116020; h=date:from:to:cc:subject:message-id:mime-version; bh=Hp/Pxo/mK3yvk0cAXe1HmgajLOcF/spYOUraUsiYG28=; b=Iedr2+eVMAJYK6DIEQ7RHDX1LrD+ZeE51ECt32eDtGZJaeZPlG6fwgSV hEEr/+Sts2MPFY4RB/FPF0p6B6BDNfQd21GgOEg8GURFsZ7Diq/al6g0E uUorX7BsZRX7oIRw9k1wa5pZJIYvyPph7Fz6MbQzfsMcMt+WQ28KPPnbM A=; X-IronPort-AV: E=Sophos;i="6.06,204,1705363200"; d="scan'208";a="278517762" X-Farcaster-Flow-ID: b368db1f-8b69-4baf-b72b-e07fa55b7192 Date: Mon, 4 Mar 2024 11:20:06 -0800 From: Andrew Panyakin To: CC: Andrew Panyakin , Juergen Gross , Stefano Stabellini , Julien Grall , Oleksandr Tyshchenko , Maximilian Heyne , Benjamin Herrenschmidt , Konrad Rzeszutek Wilk , "xen-devel@lists.xenproject.org" , "linux-kernel@vger.kernel.org" Subject: [PATCH 6.1] xen/events: close evtchn after mapping cleanup Message-ID: <20240304192006.GA3517973@uc3ecf78c6baf56.ant.amazon.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline X-Originating-IP: [10.187.170.53] X-ClientProxiedBy: EX19D031UWC002.ant.amazon.com (10.13.139.212) To EX19D026EUB004.ant.amazon.com (10.252.61.64) From: Maximilian Heyne Commit fa765c4b4aed2d64266b694520ecb025c862c5a9 upstream shutdown_pirq and startup_pirq are not taking the irq_mapping_update_lock because they can't due to lock inversion. Both are called with the irq_desc->lock being taking. The lock order, however, is first irq_mapping_update_lock and then irq_desc->lock. This opens multiple races: - shutdown_pirq can be interrupted by a function that allocates an event channel: CPU0 CPU1 shutdown_pirq { xen_evtchn_close(e) __startup_pirq { EVTCHNOP_bind_pirq -> returns just freed evtchn e set_evtchn_to_irq(e, irq) } xen_irq_info_cleanup() { set_evtchn_to_irq(e, -1) } } Assume here event channel e refers here to the same event channel number. After this race the evtchn_to_irq mapping for e is invalid (-1). - __startup_pirq races with __unbind_from_irq in a similar way. Because __startup_pirq doesn't take irq_mapping_update_lock it can grab the evtchn that __unbind_from_irq is currently freeing and cleaning up. In this case even though the event channel is allocated, its mapping can be unset in evtchn_to_irq. The fix is to first cleanup the mappings and then close the event channel. In this way, when an event channel gets allocated it's potential previous evtchn_to_irq mappings are guaranteed to be unset already. This is also the reverse order of the allocation where first the event channel is allocated and then the mappings are setup. On a 5.10 kernel prior to commit 3fcdaf3d7634 ("xen/events: modify internal [un]bind interfaces"), we hit a BUG like the following during probing of NVMe devices. The issue is that during nvme_setup_io_queues, pci_free_irq is called for every device which results in a call to shutdown_pirq. With many nvme devices it's therefore likely to hit this race during boot because there will be multiple calls to shutdown_pirq and startup_pirq are running potentially in parallel. ------------[ cut here ]------------ blkfront: xvda: barrier or flush: disabled; persistent grants: enabled; indirect descriptors: enabled; bounce buffer: enabled kernel BUG at drivers/xen/events/events_base.c:499! invalid opcode: 0000 [#1] SMP PTI CPU: 44 PID: 375 Comm: kworker/u257:23 Not tainted 5.10.201-191.748.amzn2.x86_64 #1 Hardware name: Xen HVM domU, BIOS 4.11.amazon 08/24/2006 Workqueue: nvme-reset-wq nvme_reset_work RIP: 0010:bind_evtchn_to_cpu+0xdf/0xf0 Code: 5d 41 5e c3 cc cc cc cc 44 89 f7 e8 2b 55 ad ff 49 89 c5 48 85 c0 0f 84 64 ff ff ff 4c 8b 68 30 41 83 fe ff 0f 85 60 ff ff ff <0f> 0b 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 0f 1f 44 00 00 RSP: 0000:ffffc9000d533b08 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006 RDX: 0000000000000028 RSI: 00000000ffffffff RDI: 00000000ffffffff RBP: ffff888107419680 R08: 0000000000000000 R09: ffffffff82d72b00 R10: 0000000000000000 R11: 0000000000000000 R12: 00000000000001ed R13: 0000000000000000 R14: 00000000ffffffff R15: 0000000000000002 FS: 0000000000000000(0000) GS:ffff88bc8b500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000002610001 CR4: 00000000001706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? show_trace_log_lvl+0x1c1/0x2d9 ? show_trace_log_lvl+0x1c1/0x2d9 ? set_affinity_irq+0xdc/0x1c0 ? __die_body.cold+0x8/0xd ? die+0x2b/0x50 ? do_trap+0x90/0x110 ? bind_evtchn_to_cpu+0xdf/0xf0 ? do_error_trap+0x65/0x80 ? bind_evtchn_to_cpu+0xdf/0xf0 ? exc_invalid_op+0x4e/0x70 ? bind_evtchn_to_cpu+0xdf/0xf0 ? asm_exc_invalid_op+0x12/0x20 ? bind_evtchn_to_cpu+0xdf/0xf0 ? bind_evtchn_to_cpu+0xc5/0xf0 set_affinity_irq+0xdc/0x1c0 irq_do_set_affinity+0x1d7/0x1f0 irq_setup_affinity+0xd6/0x1a0 irq_startup+0x8a/0xf0 __setup_irq+0x639/0x6d0 ? nvme_suspend+0x150/0x150 request_threaded_irq+0x10c/0x180 ? nvme_suspend+0x150/0x150 pci_request_irq+0xa8/0xf0 ? __blk_mq_free_request+0x74/0xa0 queue_request_irq+0x6f/0x80 nvme_create_queue+0x1af/0x200 nvme_create_io_queues+0xbd/0xf0 nvme_setup_io_queues+0x246/0x320 ? nvme_irq_check+0x30/0x30 nvme_reset_work+0x1c8/0x400 process_one_work+0x1b0/0x350 worker_thread+0x49/0x310 ? process_one_work+0x350/0x350 kthread+0x11b/0x140 ? __kthread_bind_mask+0x60/0x60 ret_from_fork+0x22/0x30 Modules linked in: ---[ end trace a11715de1eee1873 ]--- Fixes: d46a78b05c0e ("xen: implement pirq type event channels") Cc: stable@vger.kernel.org Co-debugged-by: Andrew Panyakin Signed-off-by: Maximilian Heyne --- Compare to upstream patch this one does not have close_evtchn flag because there is no need to handle static event channels. This feature was added only in 58f6259b7a08f ("xen/evtchn: Introduce new IOCTL to bind static evtchn") drivers/xen/events/events_base.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c index 00f8e349921d..96b96516c980 100644 --- a/drivers/xen/events/events_base.c +++ b/drivers/xen/events/events_base.c @@ -937,8 +937,8 @@ static void shutdown_pirq(struct irq_data *data) return; do_mask(info, EVT_MASK_REASON_EXPLICIT); - xen_evtchn_close(evtchn); xen_irq_info_cleanup(info); + xen_evtchn_close(evtchn); } static void enable_pirq(struct irq_data *data) @@ -982,8 +982,6 @@ static void __unbind_from_irq(unsigned int irq) unsigned int cpu = cpu_from_irq(irq); struct xenbus_device *dev; - xen_evtchn_close(evtchn); - switch (type_from_irq(irq)) { case IRQT_VIRQ: per_cpu(virq_to_irq, cpu)[virq_from_irq(irq)] = -1; @@ -1001,6 +999,7 @@ static void __unbind_from_irq(unsigned int irq) } xen_irq_info_cleanup(info); + xen_evtchn_close(evtchn); } xen_free_irq(irq); -- 2.40.1 From xen-devel-bounces@lists.xenproject.org Mon Mar 04 19:56:33 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 19:56:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688514.1072727 (Exim 4.92) (envelope-from ) id 1rhEQE-0001Lm-EW; Mon, 04 Mar 2024 19:56:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688514.1072727; Mon, 04 Mar 2024 19:56:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhEQE-0001Lf-AT; Mon, 04 Mar 2024 19:56:26 +0000 Received: by outflank-mailman (input) for mailman id 688514; Mon, 04 Mar 2024 19:56:24 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhEQC-0001LZ-HA for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 19:56:24 +0000 Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.4]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 4517cad8-da61-11ee-a1ee-f123f15fe8a2; Mon, 04 Mar 2024 20:56:21 +0100 (CET) Received: from m5p.com (mailhost.m5p.com [IPv6:2001:470:1f07:15ff:0:0:0:f7]) by mailhost.m5p.com (8.17.1/8.15.2) with ESMTPS id 424JuBmC026059 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 4 Mar 2024 14:56:17 -0500 (EST) (envelope-from ehem@m5p.com) Received: (from ehem@localhost) by m5p.com (8.17.1/8.15.2/Submit) id 424JuBjF026058; Mon, 4 Mar 2024 11:56:11 -0800 (PST) (envelope-from ehem) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 4517cad8-da61-11ee-a1ee-f123f15fe8a2 Date: Mon, 4 Mar 2024 11:56:11 -0800 From: Elliott Mitchell To: xen-devel@lists.xenproject.org, Jan Beulich , Andrew Cooper Subject: Re: Serious AMD-Vi issue Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=0.0 required=10.0 tests=KHOP_HELO_FCRDNS autolearn=unavailable autolearn_force=no version=4.0.0 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on mattapan.m5p.com On Mon, Feb 12, 2024 at 03:23:00PM -0800, Elliott Mitchell wrote: > On Thu, Jan 25, 2024 at 12:24:53PM -0800, Elliott Mitchell wrote: > > Apparently this was first noticed with 4.14, but more recently I've been > > able to reproduce the issue: > > > > https://bugs.debian.org/988477 > > > > The original observation features MD-RAID1 using a pair of Samsung > > SATA-attached flash devices. The main line shows up in `xl dmesg`: > > > > (XEN) AMD-Vi: IO_PAGE_FAULT: DDDD:bb:dd.f d0 addr ffffff???????000 flags 0x8 I > > > > Where the device points at the SATA controller. I've ended up > > reproducing this with some noticable differences. > > > > A major goal of RAID is to have different devices fail at different > > times. Hence my initial run had a Samsung device plus a device from > > another reputable flash manufacturer. > > > > I initially noticed this due to messages in domain 0's dmesg about > > errors from the SATA device. Wasn't until rather later that I noticed > > the IOMMU warnings in Xen's dmesg (perhaps post-domain 0 messages should > > be duplicated into domain 0's dmesg?). > > > > All of the failures consistently pointed at the Samsung device. Due to > > the expectation it would fail first (lower quality offering with > > lesser guarantees), I proceeded to replace it with a NVMe device. > > > > With some monitoring I discovered the NVMe device was now triggering > > IOMMU errors, though not nearly as many as the Samsung SATA device did. > > As such looks like AMD-Vi plus MD-RAID1 appears to be exposing some sort > > of IOMMU issue with Xen. > > > > > > All I can do is offer speculation about the underlying cause. There > > does seem to be a pattern of higher-performance flash storage devices > > being more severely effected. > > > > I was speculating about the issue being the MD-RAID1 driver abusing > > Linux's DMA infrastructure in some fashion. > > > > Upon further consideration, I'm wondering if this is perhaps a latency > > issue. I imagine there is some sort of flush after the IOMMU tables are > > modified. Perhaps the Samsung SATA (and all NVMe) devices were trying to > > execute commands before reloading the IOMMU tables is complete. > > Ping! > > The recipe seems to be Linux MD RAID1, plus Samsung SATA or any NVMe. > > To make it explicit, when I tried Crucial SATA + Samsung SATA. IOMMU > errors matched the Samsung SATA (a number of times the SATA driver > complained). > > As stated, I'm speculating lower latency devices starting to execute > commands before IOMMU tables have finished reloading. When originally > implemented fast flash devices were rare. I guess I'm lucky I ended up with some slightly higher-latency hardware. This is a very serious issue as data loss can occur. AMD needs to fund their Xen engineers more, otherwise soon AMD hardware may no longer be viable with Xen. -- (\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/) \BS ( | ehem+sigmsg@m5p.com PGP 87145445 | ) / \_CS\ | _____ -O #include O- _____ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 From xen-devel-bounces@lists.xenproject.org Mon Mar 04 20:19:39 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 20:19:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688519.1072737 (Exim 4.92) (envelope-from ) id 1rhEmR-0004Sk-9Y; Mon, 04 Mar 2024 20:19:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688519.1072737; Mon, 04 Mar 2024 20:19:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhEmR-0004Sd-4v; Mon, 04 Mar 2024 20:19:23 +0000 Received: by outflank-mailman (input) for mailman id 688519; Mon, 04 Mar 2024 20:19:22 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhEmQ-0004ST-LV; Mon, 04 Mar 2024 20:19:22 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhEmQ-0007kT-Jl; Mon, 04 Mar 2024 20:19:22 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhEmQ-00081R-B8; Mon, 04 Mar 2024 20:19:22 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rhEmQ-0000nj-Ac; Mon, 04 Mar 2024 20:19:22 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=tPS1pn//TthNN6c2zdnMerUucuLIk5jriuOUuAbNeq0=; b=joQvcvEYIo6Q2dLGE/lXeB6shX 4E369OL+4l9euWEMBhVnkKlJQsYJOak0UF3WCaW+1r/5Y1jtgrzSkeeG3Pt5g0OiADuNFZnO6YUL+ UUhPsdLqtP9xm9rghKVvzN6KOUa5EDQCSWpadNlNMDbd0V99hyrwb0U/z/9G+q6TrbBA=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [ovmf test] 184903: all pass - PUSHED X-Osstest-Versions-This: ovmf=918288ab5a7c3abe9c58d576ccc0ae32e2c7dea0 X-Osstest-Versions-That: ovmf=bff9815b616669f1cf743e412bc0000efe22dfb4 From: osstest service owner Date: Mon, 04 Mar 2024 20:19:22 +0000 flight 184903 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/184903/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 918288ab5a7c3abe9c58d576ccc0ae32e2c7dea0 baseline version: ovmf bff9815b616669f1cf743e412bc0000efe22dfb4 Last test of basis 184899 2024-03-04 16:43:32 Z 0 days Testing same since 184903 2024-03-04 18:41:12 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Michael Kubacki 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-pvops pass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git bff9815b61..918288ab5a 918288ab5a7c3abe9c58d576ccc0ae32e2c7dea0 -> xen-tested-master From xen-devel-bounces@lists.xenproject.org Mon Mar 04 21:22:15 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 21:22:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688528.1072747 (Exim 4.92) (envelope-from ) id 1rhFkz-0004NJ-LC; Mon, 04 Mar 2024 21:21:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688528.1072747; Mon, 04 Mar 2024 21:21:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhFkz-0004NC-IZ; Mon, 04 Mar 2024 21:21:57 +0000 Received: by outflank-mailman (input) for mailman id 688528; Mon, 04 Mar 2024 21:21:55 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhFkx-0004N4-IU for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 21:21:55 +0000 Received: from smtp-fw-52005.amazon.com (smtp-fw-52005.amazon.com [52.119.213.156]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 3864e258-da6d-11ee-afda-a90da7624cb6; Mon, 04 Mar 2024 22:21:53 +0100 (CET) Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO smtpout.prod.us-east-1.prod.farcaster.email.amazon.dev) ([10.43.8.6]) by smtp-border-fw-52005.iad7.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Mar 2024 21:21:52 +0000 Received: from EX19MTAEUB002.ant.amazon.com [10.0.10.100:20127] by smtpin.naws.eu-west-1.prod.farcaster.email.amazon.dev [10.0.42.123:2525] with esmtp (Farcaster) id d57f359e-8ff9-4dd4-a86f-6f9c3864b2ec; Mon, 4 Mar 2024 21:21:50 +0000 (UTC) Received: from EX19D026EUB004.ant.amazon.com (10.252.61.64) by EX19MTAEUB002.ant.amazon.com (10.252.51.79) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.28; Mon, 4 Mar 2024 21:21:46 +0000 Received: from uc3ecf78c6baf56.ant.amazon.com (10.187.170.53) by EX19D026EUB004.ant.amazon.com (10.252.61.64) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.28; Mon, 4 Mar 2024 21:21:43 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3864e258-da6d-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1709587314; x=1741123314; h=date:from:to:cc:subject:message-id:mime-version; bh=6zwWcPAYAWHQfzlWhyN0qe/pCFOF7SDZ5bS/wSSOiVg=; b=Kj8vWBpt2BG+l+Q4LZ5dp6EffkB4XujZ8SRSyESOYkwsS4O02PaFk6pr jXKHA1eS8ryTQZSrj+9IisorEvcW1ptfb2KeIpR/CJqPdkQWMVg736kVH Q4nUGhE6CSFxdLbC1f8bUZC9piKuWI0SViMYQQfMcfuAdSItJw+paHN7M A=; X-IronPort-AV: E=Sophos;i="6.06,204,1705363200"; d="scan'208";a="638522381" X-Farcaster-Flow-ID: d57f359e-8ff9-4dd4-a86f-6f9c3864b2ec Date: Mon, 4 Mar 2024 13:21:39 -0800 From: Andrew Panyakin To: CC: Boris Ostrovsky , Juergen Gross , Stefano Stabellini , "Oleksandr Tyshchenko" , Marc Zyngier , Samuel Holland , Sasha Levin , Maximilian Heyne , Jeremy Fitzhardinge , Konrad Rzeszutek Wilk , "xen-devel@lists.xenproject.org" , "linux-kernel@vger.kernel.org" Subject: [PATCH 5.15] xen/events: close evtchn after mapping cleanup Message-ID: <20240304212139.GA3585816@uc3ecf78c6baf56.ant.amazon.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline X-Originating-IP: [10.187.170.53] X-ClientProxiedBy: EX19D039UWB001.ant.amazon.com (10.13.138.119) To EX19D026EUB004.ant.amazon.com (10.252.61.64) From: Maximilian Heyne Commit fa765c4b4aed2d64266b694520ecb025c862c5a9 upstream shutdown_pirq and startup_pirq are not taking the irq_mapping_update_lock because they can't due to lock inversion. Both are called with the irq_desc->lock being taking. The lock order, however, is first irq_mapping_update_lock and then irq_desc->lock. This opens multiple races: - shutdown_pirq can be interrupted by a function that allocates an event channel: CPU0 CPU1 shutdown_pirq { xen_evtchn_close(e) __startup_pirq { EVTCHNOP_bind_pirq -> returns just freed evtchn e set_evtchn_to_irq(e, irq) } xen_irq_info_cleanup() { set_evtchn_to_irq(e, -1) } } Assume here event channel e refers here to the same event channel number. After this race the evtchn_to_irq mapping for e is invalid (-1). - __startup_pirq races with __unbind_from_irq in a similar way. Because __startup_pirq doesn't take irq_mapping_update_lock it can grab the evtchn that __unbind_from_irq is currently freeing and cleaning up. In this case even though the event channel is allocated, its mapping can be unset in evtchn_to_irq. The fix is to first cleanup the mappings and then close the event channel. In this way, when an event channel gets allocated it's potential previous evtchn_to_irq mappings are guaranteed to be unset already. This is also the reverse order of the allocation where first the event channel is allocated and then the mappings are setup. On a 5.10 kernel prior to commit 3fcdaf3d7634 ("xen/events: modify internal [un]bind interfaces"), we hit a BUG like the following during probing of NVMe devices. The issue is that during nvme_setup_io_queues, pci_free_irq is called for every device which results in a call to shutdown_pirq. With many nvme devices it's therefore likely to hit this race during boot because there will be multiple calls to shutdown_pirq and startup_pirq are running potentially in parallel. ------------[ cut here ]------------ blkfront: xvda: barrier or flush: disabled; persistent grants: enabled; indirect descriptors: enabled; bounce buffer: enabled kernel BUG at drivers/xen/events/events_base.c:499! invalid opcode: 0000 [#1] SMP PTI CPU: 44 PID: 375 Comm: kworker/u257:23 Not tainted 5.10.201-191.748.amzn2.x86_64 #1 Hardware name: Xen HVM domU, BIOS 4.11.amazon 08/24/2006 Workqueue: nvme-reset-wq nvme_reset_work RIP: 0010:bind_evtchn_to_cpu+0xdf/0xf0 Code: 5d 41 5e c3 cc cc cc cc 44 89 f7 e8 2b 55 ad ff 49 89 c5 48 85 c0 0f 84 64 ff ff ff 4c 8b 68 30 41 83 fe ff 0f 85 60 ff ff ff <0f> 0b 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 0f 1f 44 00 00 RSP: 0000:ffffc9000d533b08 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006 RDX: 0000000000000028 RSI: 00000000ffffffff RDI: 00000000ffffffff RBP: ffff888107419680 R08: 0000000000000000 R09: ffffffff82d72b00 R10: 0000000000000000 R11: 0000000000000000 R12: 00000000000001ed R13: 0000000000000000 R14: 00000000ffffffff R15: 0000000000000002 FS: 0000000000000000(0000) GS:ffff88bc8b500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000002610001 CR4: 00000000001706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? show_trace_log_lvl+0x1c1/0x2d9 ? show_trace_log_lvl+0x1c1/0x2d9 ? set_affinity_irq+0xdc/0x1c0 ? __die_body.cold+0x8/0xd ? die+0x2b/0x50 ? do_trap+0x90/0x110 ? bind_evtchn_to_cpu+0xdf/0xf0 ? do_error_trap+0x65/0x80 ? bind_evtchn_to_cpu+0xdf/0xf0 ? exc_invalid_op+0x4e/0x70 ? bind_evtchn_to_cpu+0xdf/0xf0 ? asm_exc_invalid_op+0x12/0x20 ? bind_evtchn_to_cpu+0xdf/0xf0 ? bind_evtchn_to_cpu+0xc5/0xf0 set_affinity_irq+0xdc/0x1c0 irq_do_set_affinity+0x1d7/0x1f0 irq_setup_affinity+0xd6/0x1a0 irq_startup+0x8a/0xf0 __setup_irq+0x639/0x6d0 ? nvme_suspend+0x150/0x150 request_threaded_irq+0x10c/0x180 ? nvme_suspend+0x150/0x150 pci_request_irq+0xa8/0xf0 ? __blk_mq_free_request+0x74/0xa0 queue_request_irq+0x6f/0x80 nvme_create_queue+0x1af/0x200 nvme_create_io_queues+0xbd/0xf0 nvme_setup_io_queues+0x246/0x320 ? nvme_irq_check+0x30/0x30 nvme_reset_work+0x1c8/0x400 process_one_work+0x1b0/0x350 worker_thread+0x49/0x310 ? process_one_work+0x350/0x350 kthread+0x11b/0x140 ? __kthread_bind_mask+0x60/0x60 ret_from_fork+0x22/0x30 Modules linked in: ---[ end trace a11715de1eee1873 ]--- Fixes: d46a78b05c0e ("xen: implement pirq type event channels") Cc: stable@vger.kernel.org Co-debugged-by: Andrew Panyakin Signed-off-by: Maximilian Heyne [apanyaki: backport to v5.15-stable] Signed-off-by: Andrew Paniakin --- Compare to upstream patch this one does not have close_evtchn flag because there is no need to handle static event channels. This feature was added only in 58f6259b7a08f ("xen/evtchn: Introduce new IOCTL to bind static evtchn") drivers/xen/events/events_base.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c index ee691b20d4a3..04ff194fecf4 100644 --- a/drivers/xen/events/events_base.c +++ b/drivers/xen/events/events_base.c @@ -936,8 +936,8 @@ static void shutdown_pirq(struct irq_data *data) return; do_mask(info, EVT_MASK_REASON_EXPLICIT); - xen_evtchn_close(evtchn); xen_irq_info_cleanup(info); + xen_evtchn_close(evtchn); } static void enable_pirq(struct irq_data *data) @@ -981,8 +981,6 @@ static void __unbind_from_irq(unsigned int irq) unsigned int cpu = cpu_from_irq(irq); struct xenbus_device *dev; - xen_evtchn_close(evtchn); - switch (type_from_irq(irq)) { case IRQT_VIRQ: per_cpu(virq_to_irq, cpu)[virq_from_irq(irq)] = -1; @@ -1000,6 +998,7 @@ static void __unbind_from_irq(unsigned int irq) } xen_irq_info_cleanup(info); + xen_evtchn_close(evtchn); } xen_free_irq(irq); -- 2.40.1 From xen-devel-bounces@lists.xenproject.org Mon Mar 04 21:50:21 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 21:50:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688531.1072756 (Exim 4.92) (envelope-from ) id 1rhGCN-0008VL-Or; Mon, 04 Mar 2024 21:50:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688531.1072756; Mon, 04 Mar 2024 21:50:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhGCN-0008VE-Le; Mon, 04 Mar 2024 21:50:15 +0000 Received: by outflank-mailman (input) for mailman id 688531; Mon, 04 Mar 2024 21:50:14 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhGCM-0008V8-AQ for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 21:50:14 +0000 Received: from smtp-fw-80007.amazon.com (smtp-fw-80007.amazon.com [99.78.197.218]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 2b5af81f-da71-11ee-afda-a90da7624cb6; Mon, 04 Mar 2024 22:50:12 +0100 (CET) Received: from pdx4-co-svc-p1-lb2-vlan2.amazon.com (HELO smtpout.prod.us-east-1.prod.farcaster.email.amazon.dev) ([10.25.36.210]) by smtp-border-fw-80007.pdx80.corp.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Mar 2024 21:50:01 +0000 Received: from EX19MTAEUC002.ant.amazon.com [10.0.17.79:26419] by smtpin.naws.eu-west-1.prod.farcaster.email.amazon.dev [10.0.20.189:2525] with esmtp (Farcaster) id e2b6372a-4e89-463b-887c-9553dfcc05aa; Mon, 4 Mar 2024 21:49:59 +0000 (UTC) Received: from EX19D026EUB004.ant.amazon.com (10.252.61.64) by EX19MTAEUC002.ant.amazon.com (10.252.51.245) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.28; Mon, 4 Mar 2024 21:49:59 +0000 Received: from uc3ecf78c6baf56.ant.amazon.com (10.187.170.53) by EX19D026EUB004.ant.amazon.com (10.252.61.64) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.28; Mon, 4 Mar 2024 21:49:56 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 2b5af81f-da71-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1709589012; x=1741125012; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=IPLuyADOds20t9F10dBuRgOvEI8caqH4znwPq4fIKLQ=; b=uTgKEy9tTUGr+S2yDsPbQfQR1npZ0s7guKimSbwXkA+p7w2CY3DHR1Fr +G5Tagl8y8xbKXPYqTyQLGZ+io73UlFxbP+TgbZuu7jpjLp5mZKF24bto GeTglJx4UYtpl93zcigcbwKEJmV+pz3l123hZjV007VrCEc4CvsrVmI5N 4=; X-IronPort-AV: E=Sophos;i="6.06,204,1705363200"; d="scan'208";a="278554992" X-Farcaster-Flow-ID: e2b6372a-4e89-463b-887c-9553dfcc05aa Date: Mon, 4 Mar 2024 13:49:51 -0800 From: Andrew Paniakin To: Greg KH CC: , , , , , , , , , , , , , , Subject: Re: [PATCH 5.10] xen/events: close evtchn after mapping cleanup Message-ID: <20240304214951.GA3603725@uc3ecf78c6baf56.ant.amazon.com> References: <20240302160357.GA2232656@uc3ecf78c6baf56.ant.amazon.com> <2024030433-legacy-unrivaled-f5fc@gregkh> <20240304184726.GA3441283@uc3ecf78c6baf56.ant.amazon.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20240304184726.GA3441283@uc3ecf78c6baf56.ant.amazon.com> X-Originating-IP: [10.187.170.53] X-ClientProxiedBy: EX19D031UWC004.ant.amazon.com (10.13.139.246) To EX19D026EUB004.ant.amazon.com (10.252.61.64) On 04/03/2024, Andrew Panyakin wrote: > On 04/03/2024, Greg KH wrote: > > On Sat, Mar 02, 2024 at 08:03:57AM -0800, Andrew Panyakin wrote: > > > From: Maximilian Heyne > > > > > > Commit fa765c4b4aed2d64266b694520ecb025c862c5a9 upstream > [...] > > Where is the 5.15.y version of this commit? We have to have that before > > we can take a 5.10.y version, right? > > Remaining patches for 5.15 and 6.1 ready, will send once analyze test > results. Remaining patches posted: 5.15: https://lore.kernel.org/all/20240304212139.GA3585816@uc3ecf78c6baf56.ant.amazon.com/ 6.1: https://lore.kernel.org/all/20240304192006.GA3517973@uc3ecf78c6baf56.ant.amazon.com/ From xen-devel-bounces@lists.xenproject.org Mon Mar 04 22:15:46 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 22:15:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688535.1072767 (Exim 4.92) (envelope-from ) id 1rhGau-0003ID-QN; Mon, 04 Mar 2024 22:15:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688535.1072767; Mon, 04 Mar 2024 22:15:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhGau-0003I6-NB; Mon, 04 Mar 2024 22:15:36 +0000 Received: by outflank-mailman (input) for mailman id 688535; Mon, 04 Mar 2024 22:15:35 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhGat-0003Hz-B9 for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 22:15:35 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhGas-0001Y4-W0; Mon, 04 Mar 2024 22:15:34 +0000 Received: from gw1.octic.net ([88.97.20.152] helo=[10.0.1.193]) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1rhGas-0007eb-Np; Mon, 04 Mar 2024 22:15:34 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID; bh=4SIzGA5dhCL6/TFze2sr+Z62EdHV7hyf9qgQqs3tcuA=; b=vDXvUAadIGLN8s8OVY2OVNclLC HDXXWEG1CRl2pY5LZB0/8YHlSCL2uF9t2xZooOjMOzpq1zBe4WpMW9HHmXfcAUoU8Vni3w8gVAi2d sQmWNtojYj436VXDLtDsLKCCKKQS2xl+ZLNfFaJ4pqiizWkL4K0lVoZRXpJIJfRFyDzI=; Message-ID: <1aa294ec-704c-4370-94c5-54573ed82af6@xen.org> Date: Mon, 4 Mar 2024 22:15:32 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Xen 4.18rc/ARM64 on Raspberry Pi 4B: Traffic in DomU crashing Dom0 when using VLANs Content-Language: en-GB To: Paul Leiber , Xen-devel Cc: Stefano Stabellini , george.dunlap@cloud.com, Michal Orzel , Bertrand Marquis References: <838ff75f-1352-4d3c-9bc1-c7a57c828231@onlineschubla.de> <4cddfd89-f195-4a50-a14d-b86121414e56@onlineschubla.de> <4d7dbce9-ef20-4702-8056-9d5ab8152721@onlineschubla.de> From: Julien Grall In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Paul, On 01/03/2024 19:37, Paul Leiber wrote: > Stopping xen-watchdog prevents the reboot. However, when triggering > traffic on the VLAN, Dom0 and DomU become completely unresponsive. No > error or kernel message is printed in the serial console. Thanks for providing some logs. See some comments below. How long did you wait before confirming dom0 is stucked? IIRC, Linux may print some RCU stall logs after a few minutes. > > Switching to Xen console works. Pressing '0' produces the following output: > > (XEN) '0' pressed -> dumping Dom0's registers > (XEN) *** Dumping Dom0 vcpu#0 state: *** > (XEN) ----[ Xen-4.19-unstable  arm64  debug=y  Tainted:   C    ]---- > (XEN) CPU:    0 > (XEN) PC:     ffff800008027e50 > (XEN) LR:     ffff800008027e44 > (XEN) SP_EL0: ffff800009c78f80 > (XEN) SP_EL1: ffff800008003b60 > (XEN) CPSR:   00000000000003c5 MODE:64-bit EL1h (Guest Kernel, handler) [...] > (XEN) *** Dumping Dom0 vcpu#1 state: *** > (XEN) ----[ Xen-4.19-unstable  arm64  debug=y  Tainted:   C    ]---- > (XEN) CPU:    0 > (XEN) PC:     ffff800008c5dc80 > (XEN) LR:     ffff800008c5dc88 > (XEN) SP_EL0: ffff000042272080 > (XEN) SP_EL1: ffff80000800b0e0 > (XEN) CPSR:   0000000080000305 MODE:64-bit EL1h (Guest Kernel, handler) [...] > (XEN) *** Dumping Dom0 vcpu#2 state: *** > (XEN) ----[ Xen-4.19-unstable  arm64  debug=y  Tainted:   C    ]---- > (XEN) CPU:    0 > (XEN) PC:     ffff800008027e50 > (XEN) LR:     ffff800008027e44 > (XEN) SP_EL0: ffff000042271040 > (XEN) SP_EL1: ffff800009fcbf20 > (XEN) CPSR:   00000000000003c5 MODE:64-bit EL1h (Guest Kernel, handler) [...] > (XEN) *** Dumping Dom0 vcpu#3 state: *** > (XEN) ----[ Xen-4.19-unstable  arm64  debug=y  Tainted:   C    ]---- > (XEN) CPU:    0 > (XEN) PC:     ffff800008027e50 > (XEN) LR:     ffff800008027e44 > (XEN) SP_EL0: ffff0000422730c0 > (XEN) SP_EL1: ffff800009fd3f20 > (XEN) CPSR:   00000000000003c5 MODE:64-bit EL1h (Guest Kernel, handler) All the PCs but one (vcpu#1) are the same. > (XEN) 'q' pressed -> dumping domain info (now = 727929105981) > (XEN) General information for domain 0: > (XEN)     refcnt=3 dying=0 pause_count=0 > (XEN)     nr_pages=262144 xenheap_pages=2 dirty_cpus={} max_pages=262144 > (XEN)     handle=00000000-0000-0000-0000-000000000000 vm_assist=00000020 > (XEN) p2m mappings for domain 0 (vmid 1): > (XEN)   1G mappings: 0 (shattered 1) > (XEN)   2M mappings: 422 (shattered 90) > (XEN)   4K mappings: 45372 > (XEN) Rangesets belonging to domain 0: > (XEN)     Interrupts { 32-152, 154-255 } > (XEN)     I/O Memory { 0-fe200, fe203-ff841, ff849-ffffffffffffffff } > (XEN) NODE affinity for domain 0: [0] > (XEN) VCPU information and callbacks for domain 0: > (XEN)   UNIT0 affinities: hard={0-3} soft={0-3} > (XEN)     VCPU0: CPU3 [has=F] poll=0 upcall_pend=01 upcall_mask=01 > (XEN)     pause_count=0 pause_flags=1 The vCPU is blocked. But... > (XEN) GICH_LRs (vcpu 0) mask=f > (XEN)    VCPU_LR[0]=2a000002 > (XEN)    VCPU_LR[1]=1a00001b > (XEN)    VCPU_LR[2]=1a000001 > (XEN)    VCPU_LR[3]=1a000010 ... it loosk like multiple IRQs are inflights. LR0 (holding IRQ2) is active but the others are pending. This is the same for vCPU #2, #3. vCPU #1 still seems to "work". AFAICT, Linux is using IRQ2 for the IPI CPU_STOP. So it sounds like dom0 may have panicked. Looking at the initial logs you posted. I see some messages from Xen but no messages at all from dom0 (including boot). Can you check if you have console=hvc0 on the Linux command line? If not, please add it and retry. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Mon Mar 04 23:55:31 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2024 23:55:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688538.1072776 (Exim 4.92) (envelope-from ) id 1rhI9J-0007vo-RF; Mon, 04 Mar 2024 23:55:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688538.1072776; Mon, 04 Mar 2024 23:55:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhI9J-0007vh-OG; Mon, 04 Mar 2024 23:55:13 +0000 Received: by outflank-mailman (input) for mailman id 688538; Mon, 04 Mar 2024 23:55:12 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhI9I-0007vb-G5 for xen-devel@lists.xenproject.org; Mon, 04 Mar 2024 23:55:12 +0000 Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [2a00:1450:4864:20::334]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id a20189a4-da82-11ee-afda-a90da7624cb6; Tue, 05 Mar 2024 00:55:09 +0100 (CET) Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-412e993a82eso980485e9.0 for ; Mon, 04 Mar 2024 15:55:09 -0800 (PST) Received: from [192.168.1.10] (host-92-3-248-192.as13285.net. [92.3.248.192]) by smtp.gmail.com with ESMTPSA id n6-20020a05600c4f8600b0041273fc463csm19245376wmq.17.2024.03.04.15.55.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Mar 2024 15:55:08 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a20189a4-da82-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709596509; x=1710201309; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=gFjlR66KPO0usqHuW9e+T4e948lNj9/F8zaQXgIQDQY=; b=U4JFHIvBzffcEQ6kyj7FYtg8NO/Nwk98QDjt4HEqX2Aj1arD8brmWI1Gd+gngil/+x 4qWGWN4B/Woxg5npvVpDWlUd6UHxBAg8Y2My86f9+AvX0ttiewf2pCVsmxlL5gmXOf28 RoSrNmobIOPLZc94PzHJcCwiv5maeOfzOM1zg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709596509; x=1710201309; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=gFjlR66KPO0usqHuW9e+T4e948lNj9/F8zaQXgIQDQY=; b=YagBoUUvB83vjPLjoj4fxtx0VsoCOC3UXy3XSCrq9TT1M55eIwAae3RjhmVH7ZLJ9h /XEa8xuhezkK0ynvDEPnhG0Aiavq/yqa5QqriT7gTb9z29kSQ7kpMV4xiQrvry3AWmQs 9+HtZvqfKntAwKXyEY0EX+BLnb2i62hOokfPoMb3vpb8q3zGgTf1VM9XrCdBElxmr+OS 22qQy4PyNPBJFf7fo/rqZcidGrQcz5i3j2mBufXxL1cDBkRQR1p2iGodbn7Arx2fmxzn sQNPC7O3Qn61vsTXoWU/R7DUs1qLKsxYUbT7EFDmkticJK5Y7Im/YG8+ZtGbF35d4zI4 fmDg== X-Forwarded-Encrypted: i=1; AJvYcCWoMWz5pIJRbt0PtDMAjSvakinBHp/jkuorn6GFAV5x7XsMcOP4jmQhLNCaw1T3D87/19VmG47L/DZRuCGv1qLv5zHwpO9YkCABRvSgDTg= X-Gm-Message-State: AOJu0YyKw5QJ6EUgggepcqpeqLPaOaHZ7fCtYleSxpIu5wtjJfCHqIFi XpAvF8Dw5RpMLHlO+t2FIRi/dHRTW2Dh9UPgEbVxQuEDdwsDVQGpC0X4WTC1v28= X-Google-Smtp-Source: AGHT+IGaHjaHlwyK1TiL4AEdsM45wvC26gPmSupneXhyO8wggJkMrX+LLbcy15hCeFl+BgeUF3Q0rg== X-Received: by 2002:a05:600c:1c9d:b0:412:dcab:7c79 with SMTP id k29-20020a05600c1c9d00b00412dcab7c79mr4239876wms.10.1709596508990; Mon, 04 Mar 2024 15:55:08 -0800 (PST) Message-ID: Date: Mon, 4 Mar 2024 23:55:07 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: AMD-Vi issue Content-Language: en-GB To: Elliott Mitchell , xen-devel@lists.xenproject.org Cc: Jan Beulich References: From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 25/01/2024 8:24 pm, Elliott Mitchell wrote: > The original observation features MD-RAID1 using a pair of Samsung > SATA-attached flash devices. The main line shows up in `xl dmesg`: > > (XEN) AMD-Vi: IO_PAGE_FAULT: DDDD:bb:dd.f d0 addr ffffff???????000 flags 0x8 I You have a device which is issuing interrupts which have been blocked due to the IOMMU configuration. But you've elided all details other than the fact it's assigned to dom0.  As such, there is nothing we can do to help. This isn't the first time you've been asked to provide a bare minimum amount of details such that we might be able to help.  I'm sorry you are having problems, but continuing to ping a question with no actionable information is unfair to those of us who are who are providing support to the community for free. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Mar 05 00:23:10 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 00:23:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688541.1072787 (Exim 4.92) (envelope-from ) id 1rhIaC-0004Dl-QK; Tue, 05 Mar 2024 00:23:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688541.1072787; Tue, 05 Mar 2024 00:23:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhIaC-0004De-N2; Tue, 05 Mar 2024 00:23:00 +0000 Received: by outflank-mailman (input) for mailman id 688541; Tue, 05 Mar 2024 00:22:58 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhIaA-0004DY-LE for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 00:22:58 +0000 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on20601.outbound.protection.outlook.com [2a01:111:f403:2414::601]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 8233a10d-da86-11ee-a1ee-f123f15fe8a2; Tue, 05 Mar 2024 01:22:55 +0100 (CET) Received: from BL0PR0102CA0049.prod.exchangelabs.com (2603:10b6:208:25::26) by IA1PR12MB8287.namprd12.prod.outlook.com (2603:10b6:208:3f5::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7339.38; Tue, 5 Mar 2024 00:22:47 +0000 Received: from BL02EPF0001A104.namprd05.prod.outlook.com (2603:10b6:208:25:cafe::4e) by BL0PR0102CA0049.outlook.office365.com (2603:10b6:208:25::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7339.39 via Frontend Transport; Tue, 5 Mar 2024 00:22:47 +0000 Received: from SATLEXMB03.amd.com (165.204.84.17) by BL02EPF0001A104.mail.protection.outlook.com (10.167.241.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7362.11 via Frontend Transport; Tue, 5 Mar 2024 00:22:47 +0000 Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Mon, 4 Mar 2024 18:22:46 -0600 Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB05.amd.com (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Mon, 4 Mar 2024 18:22:46 -0600 Received: from [172.31.100.92] (10.180.168.240) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.35 via Frontend Transport; Mon, 4 Mar 2024 18:22:43 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8233a10d-da86-11ee-a1ee-f123f15fe8a2 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=egu4wk/Fhl2TijLCU14VAaP6o6cBlf8nhajMclwt5kY0l1cdqCwt9ziPrms3tm/cIs/WNj+EszX5BbT3PpnbHSkiyRopmBXYMIKfOtSGDTeE0NaF/03xWJIe5LfLUu9lOTf0QOZmzn9wF5KuxLBNGmeoFrFXj7pJ9E8hBAsIYNxjHdBJg2ls5v6iu+zBReyIK4JpDi3MiPoqjuXvXHxSLhdoapA7Am1GqYGDs6U/Vp5HIFTZagkH34exuO/ofHWD/Zz0gPonDNVflvyRGa4w+DwCZtwmwCpv/6pbTewDj1G+oiy++B6woOZV3FCYuE0PwXkN1EzbAwsJNPY56fLxyA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=lApumrg/oXAOwe7s9VGN/Qeh2+4LdAEF1nu3NW6D50I=; b=oRazjeh2lTp/ujPcCRKUVN4QIKtl21scKJZj7uzeY1J/h4mmUCRFj+VXnVaYqLooGKir9eICOVxjCES+SHvPIabNaT/J2jlo7pLFdcDB1PXKp5SlLpHEd5MR5RuM6LSwNi6T8+5CmgrrErzsxiWH2oTkugRNotlUxbj52NxYiCNeCANqvBJbvuqujpteqLKl+XKToeRMj17Fs1BDx2xNFBZruPtxXYcy1fYM7C9nllCGTOLVYrUEB0VXWOKjHMkKLluWp9J0ea+gykidRIuapWwl6eB+gdVvY35/TJLdvWJFtGHqDOsJywoPy3P2lBdGqp3nQjR1QkHct4FUaAulwA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=xen.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lApumrg/oXAOwe7s9VGN/Qeh2+4LdAEF1nu3NW6D50I=; b=tZD8VizC1aJp+nC49AD0EGJBgvE/o3KQULMGNQiwHjKHkjwH+iZrgsihIDrBgqXlTvK0bWWyMBqxBfpH4EWyjHV9BUJuKF5mX525HCBBcYsGsTFZO/ijJRwnZpYZHzbeW1wt0XO0y5E3rIfw4YIuPyeXsbDVy8Ogfl5wn4QD63I= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C Message-ID: Date: Tue, 5 Mar 2024 08:22:37 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/common: Do not allocate magic pages 1:1 for direct mapped domains To: Julien Grall , CC: Anthony PERARD , Juergen Gross , Andrew Cooper , George Dunlap , Jan Beulich , "Stefano Stabellini" , Bertrand Marquis , Michal Orzel , "Volodymyr Babchuk" , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Alec Kwapis References: <20240226011935.169462-1-xin.wang2@amd.com> <3982ba47-6709-47e3-a9c2-e2d3b4a2d8e3@xen.org> <8e56b75d-10a2-4764-8244-3e596f9fc695@amd.com> <98739f8d-dc00-4db8-a0b2-07f054107acf@xen.org> <8768d244-c52c-40da-8a99-0296cb9a8ca5@xen.org> Content-Language: en-US From: Henry Wang In-Reply-To: <8768d244-c52c-40da-8a99-0296cb9a8ca5@xen.org> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: None (SATLEXMB05.amd.com: xin.wang2@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BL02EPF0001A104:EE_|IA1PR12MB8287:EE_ X-MS-Office365-Filtering-Correlation-Id: d1f1429d-5672-4620-f507-08dc3caa6261 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: TWL3+0ma104Zc+65XriEgNgyl4whKr61s0F36kztRsdQ8YRsTbkMDNEwU+SUte9kVfUpKNTB/ZKN54/xJliuMhGVLDx4dyzLBmTGBUsPTEU7iR68QUwFwLE34PhFs1KgF60Ew08T29px/GPK9wDDjl90kNZAa4xwI+G03p/fvyVk7Po+IF3v+eifHYGjnmgqwi26eJpyjgvLT4kUF4NlbTwn2rTnjfQbTynFhcTLpAR65vV0ASQj3Q5dnTV7iK2dT5YrbeOb308Jjs7fRswQZiTudwXT5chLB86znEUzdvyRk5CzFAwWNwUFqwLF+rPwvt3dR64FYFB01fM8WqeKHINM1u3qZXdQf0onVTbqefFpFBXKqiR6SbFkKcWk9LMQW3EnQ9b/pPQ6IAH3QJtpnzDMA+M97YwUGs0Cp+xbF+8YJuTDAvxsPcOcW99lJFkn3e90BqDUsKgceWriF5uipK/N/4bW/QYUxnqaJUWMr3iIMsOqCY1sbfKsRFy08TWmawLEjEH4FIAAQCksSY/x6YcdH9DVwPu+I1f5owPGyJ3hYapFZ/J3PHb21oTtX43LgiMFaJbHhazKU7ruiSh99BnFz2pjgVg3qhWYKctQL9zd+qVSZLxDqI25Od4PR5LOx4fAxBUMV739ZcWPdd9sdQpLIw2aN7+/0/WBiohMBQ4mJqH5030KKGr6UJjCjQ95LQxzD9hk1wDYbXegGDEcQeQ+CAmrONo5+0gM/T5RsZ2n+JOdiZWMM0DGNTnQRupD X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(82310400014)(36860700004)(376005);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Mar 2024 00:22:47.1992 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d1f1429d-5672-4620-f507-08dc3caa6261 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BL02EPF0001A104.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB8287 Hi Julien, On 3/5/2024 2:38 AM, Julien Grall wrote: > On 01/03/2024 03:03, Henry Wang wrote: >> Hi Julien, > Hi Henry, >> On 2/28/2024 8:27 PM, Julien Grall wrote: >>> Hi Henry, >>>> ...here basically means we want to do the finding of the unused >>>> region in toolstack. Since currently what we care about is only a >>>> couple of pages instead of the whole memory map, could it be >>>> possible that we do the opposite: in alloc_xs_page(), we issue a >>>> domctl hypercall to Xen and do the finding work in Xen and return >>>> with the found gfn? Then the page can be mapped by >>>> populate_physmap() from alloc_xs_page() and used for XenStore. >>> >>> I know that DOMCTL hypercalls are not stable. But I am not overly >>> happy with creating an hypercall which is just "fetch the magic >>> regions". I think it need to be a more general one that would expose >>> all the regions. >>> >>> Also, you can't really find the magic regions when the hypercall is >>> done as we don't have the guest memory layout. This will need to be >>> done in advance. >>> >>> Overall, I think it would be better if we provide an hypercall >>> listing the regions currently occupied (similar to e820). One will >>> have the type "magic pages". >> >> Would below design make sense to you: > > This looks good in principle. Great! Actually Michal helped a lot to come up with the proposal (Thanks Michal!). I am really sorry that I missed to mention this in my last email and didn't credit him properly. > Some comments below. >> (1) Similarly as the e820, we can firstly introduce some data >> structures in struct arch_domain: >> >> #define MEM_REGIONS_MAX 4 >> >> // For now we only care the magic regions, but in the future this can >> be easily extended with other types such as RAM, MMIO etc. >> enum mem_region_type { >>      MEM_REGION_MAGIC, >> }; >> >> struct mem_region { >>      paddr_t start; >>      paddr_t size; >>      enum mem_region_type type; >> }; >> >> struct domain_mem_map { >>      unsigned int nr_mem_regions; >>      struct mem_region region[MEM_REGIONS_MAX]; >> }; > > If you plan to expose the same interface externally, then you will > need to replace paddr_t with uint64_t and avoid using an enum in the > structure. Yes you are correct. Maybe we can also try using xen_pfn_t and the number of pages to describe the range as an alternative. I will use the one that makes the implementation easier. > You will also want to expose a dynamic array (even if this is fixed in > the hypervisor). Ok. >> struct arch_domain { >> ... >>      struct domain_mem_map mem_map; >> }; >> >> (2) Then in domain creation time, for normal and static >> non-directmapped Dom0less DomU, set d->arch.mem_map.region[0].start = >> GUEST_MAGIC_BASE and the size to 4 pages. For static and directmapped >> Dom0less DomU, find a free region of 4 pages for magic pages. The >> finding of a free region can reuse the approach for extended region >> and be called before make_hypervisor_node(), and when >> make_hypervisor_node() is called. We carve the magic pages out from >> the actual extended region. >> >> (3) Add a new hypercall XENMEM_memory_map_domid (or a domctl). Input >> will be domid and output will be the memory map of the domain >> recorded in struct arch_domain. > > XENMEM_* are supposed to be stable interface. I am not aware of any > use in the guest yet, so I think it would be best to use a DOMCTL. Sounds good to me. Thanks for the input! Kind regards, Henry >> >> (4) In alloc_xs_page() and alloc_magic_pages, replace the hardcoded >> base address with the new address found by the hypercall. > > Cheers, > From xen-devel-bounces@lists.xenproject.org Tue Mar 05 00:34:24 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 00:34:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688544.1072797 (Exim 4.92) (envelope-from ) id 1rhIl8-00061O-Q9; Tue, 05 Mar 2024 00:34:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688544.1072797; Tue, 05 Mar 2024 00:34:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhIl8-00061H-MA; Tue, 05 Mar 2024 00:34:18 +0000 Received: by outflank-mailman (input) for mailman id 688544; Tue, 05 Mar 2024 00:34:17 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhIl7-00061B-GO for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 00:34:17 +0000 Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.4]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 1752fb01-da88-11ee-afda-a90da7624cb6; Tue, 05 Mar 2024 01:34:15 +0100 (CET) Received: from m5p.com (mailhost.m5p.com [IPv6:2001:470:1f07:15ff:0:0:0:f7]) by mailhost.m5p.com (8.17.1/8.15.2) with ESMTPS id 4250Y3PG027067 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 4 Mar 2024 19:34:09 -0500 (EST) (envelope-from ehem@m5p.com) Received: (from ehem@localhost) by m5p.com (8.17.1/8.15.2/Submit) id 4250Y3I5027066; Mon, 4 Mar 2024 16:34:03 -0800 (PST) (envelope-from ehem) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1752fb01-da88-11ee-afda-a90da7624cb6 Date: Mon, 4 Mar 2024 16:34:03 -0800 From: Elliott Mitchell To: Andrew Cooper Cc: xen-devel@lists.xenproject.org, Jan Beulich Subject: Re: AMD-Vi issue Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=0.0 required=10.0 tests=KHOP_HELO_FCRDNS autolearn=unavailable autolearn_force=no version=4.0.0 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on mattapan.m5p.com On Mon, Mar 04, 2024 at 11:55:07PM +0000, Andrew Cooper wrote: > On 25/01/2024 8:24 pm, Elliott Mitchell wrote: > > The original observation features MD-RAID1 using a pair of Samsung > > SATA-attached flash devices. The main line shows up in `xl dmesg`: > > > > (XEN) AMD-Vi: IO_PAGE_FAULT: DDDD:bb:dd.f d0 addr ffffff???????000 flags 0x8 I > > You have a device which is issuing interrupts which have been blocked > due to the IOMMU configuration. > > But you've elided all details other than the fact it's assigned to > dom0. As such, there is nothing we can do to help. I've provided the details thought most likely to allow others to reproduce. I've pointed to a report from someone else with somewhat similar hardware who also encountered this (and had enough hardware to try several combinations). Sorry about being reluctant to send exact hardware serial numbers to a public mailing list. -- (\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/) \BS ( | ehem+sigmsg@m5p.com PGP 87145445 | ) / \_CS\ | _____ -O #include O- _____ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 From xen-devel-bounces@lists.xenproject.org Tue Mar 05 00:39:01 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 00:39:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688547.1072807 (Exim 4.92) (envelope-from ) id 1rhIpf-0006g9-Do; Tue, 05 Mar 2024 00:38:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688547.1072807; Tue, 05 Mar 2024 00:38:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhIpf-0006g2-9y; Tue, 05 Mar 2024 00:38:59 +0000 Received: by outflank-mailman (input) for mailman id 688547; Tue, 05 Mar 2024 00:38:58 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhIpe-0006fw-GY for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 00:38:58 +0000 Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [2a00:1450:4864:20::32e]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id c04df180-da88-11ee-afda-a90da7624cb6; Tue, 05 Mar 2024 01:38:57 +0100 (CET) Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-412e4426e32so10656975e9.2 for ; Mon, 04 Mar 2024 16:38:57 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c04df180-da88-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709599137; x=1710203937; darn=lists.xenproject.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Bj5zoTI69PLp3cR+V6/5ODnZceaydtC6xTdxHYis12E=; b=Ij+Ono4rXLyWddkT3NuS7WfxVqkRdf12Skm7fLOEVYLqcgwtfcO3MW9y15v0yx+pVc Rtr6v/GKW5n9tNHkU7+Yu4lj/tgUSwy4AGTtt87816BSOS/hjRt4+v9LbNe+w4f3XCO4 Kq8udCK4r6dMdLbaqSfAVEbX0zWgPAZsN6+WxnL1XljHpkkcHkWVnVfWDnZd+bWjrHKM 5B93Y1BlleUzh5I/mu42ehycUNN263f/sZb5lN53Ll9kSI21TMgh4OzECmfz4f7oeTG8 /71JuqPLsfFCn/fi7NE3EVOFY7gvRKc3lxIywvEXwDo4q8uPq6rvDIqsph2EpKebzRBS tlaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709599137; x=1710203937; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Bj5zoTI69PLp3cR+V6/5ODnZceaydtC6xTdxHYis12E=; b=GobK3iFOL20FPtj/iLHVBki4bq20kWz630TaOEqSTfe+4MoalaxnVQ8KJAmHj2JIPy wkb6N86EJlufWxHLrRzMiwOIDM7nSDwN+Xs7gGpL2S1qr5onHbpBBVJQQuIlKZe7lLGS gRSIeMV87W/akRwS4tx5jT8hUaPLeixROFXc++3a7WymkXz8Ka+N27ccJ46c00fK0Qkx 1Tz0B2tlk8maHl8kKNk8RxJ94nMH0tA0UjB/WGfz7qJKhrFx61JauFF/hEQ6ctbKYzfR nrAFotEIshkHPItrIdQDrE5gss0HoPsrS5L++o8iXJBwwgKAh2FqQLtNvtIcEcRX96T+ YT2A== X-Forwarded-Encrypted: i=1; AJvYcCV9PESO/rDzc6jOUFpcDQOeORS9o/WB2tq2El4nwuIqn2H0OijmmvBxIXYb55YxIEFRtYt8wken9ar+OvRvCCaezQOANI3BB/7I+uRQMco= X-Gm-Message-State: AOJu0YywFBkDO3P8Cmn4+MDreVw9ToBuj9D364QJcA4/uaXoitKRyy4r HCi26cofmwx3samTTBmEe48FnO5hgBVfOn/d4Z6JgWMN8j05KjcSa5OqOCWGGePyO+fah4GflSd au374t5lqsoxrQv5yrzRNe8xge0I= X-Google-Smtp-Source: AGHT+IHPuUlqp1ldZ1+USNRqTG8hjmjknNCOaSaQz6ztGJruA1SPY5lwFtYqj/d3Q7KwH/p72Add+tEiks5hC80Uxqg= X-Received: by 2002:a05:600c:444e:b0:412:ecc4:3c3a with SMTP id v14-20020a05600c444e00b00412ecc43c3amr154280wmn.40.1709599136434; Mon, 04 Mar 2024 16:38:56 -0800 (PST) MIME-Version: 1.0 References: <20240223235728.13981-1-alexei.starovoitov@gmail.com> <20240223235728.13981-3-alexei.starovoitov@gmail.com> In-Reply-To: From: Alexei Starovoitov Date: Mon, 4 Mar 2024 16:38:45 -0800 Message-ID: Subject: Re: [PATCH v2 bpf-next 2/3] mm, xen: Separate xen use cases from ioremap. To: Mike Rapoport Cc: bpf , Daniel Borkmann , Andrii Nakryiko , Linus Torvalds , Barret Rhoden , Johannes Weiner , Lorenzo Stoakes , Andrew Morton , Uladzislau Rezki , Christoph Hellwig , Boris Ostrovsky , sstabellini@kernel.org, Juergen Gross , linux-mm , xen-devel@lists.xenproject.org, Kernel Team Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Mar 3, 2024 at 11:55=E2=80=AFPM Mike Rapoport wro= te: > > On Fri, Feb 23, 2024 at 03:57:27PM -0800, Alexei Starovoitov wrote: > > From: Alexei Starovoitov > > > > xen grant table and xenbus ring are not ioremap the way arch specific c= ode is using it, > > so let's add VM_XEN flag to separate them from VM_IOREMAP users. > > xen will not and should not be calling ioremap_page_range() on that ran= ge. > > /proc/vmallocinfo will print such region as "xen" instead of "ioremap" = as well. > > > > Signed-off-by: Alexei Starovoitov > > --- > > arch/x86/xen/grant-table.c | 2 +- > > drivers/xen/xenbus/xenbus_client.c | 2 +- > > include/linux/vmalloc.h | 1 + > > mm/vmalloc.c | 7 +++++-- > > 4 files changed, 8 insertions(+), 4 deletions(-) > > > > diff --git a/arch/x86/xen/grant-table.c b/arch/x86/xen/grant-table.c > > index 1e681bf62561..b816db0349c4 100644 > > --- a/arch/x86/xen/grant-table.c > > +++ b/arch/x86/xen/grant-table.c > > @@ -104,7 +104,7 @@ static int arch_gnttab_valloc(struct gnttab_vm_area= *area, unsigned nr_frames) > > area->ptes =3D kmalloc_array(nr_frames, sizeof(*area->ptes), GFP_= KERNEL); > > if (area->ptes =3D=3D NULL) > > return -ENOMEM; > > - area->area =3D get_vm_area(PAGE_SIZE * nr_frames, VM_IOREMAP); > > + area->area =3D get_vm_area(PAGE_SIZE * nr_frames, VM_XEN); > > if (!area->area) > > goto out_free_ptes; > > if (apply_to_page_range(&init_mm, (unsigned long)area->area->addr= , > > diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xe= nbus_client.c > > index 32835b4b9bc5..b9c81a2d578b 100644 > > --- a/drivers/xen/xenbus/xenbus_client.c > > +++ b/drivers/xen/xenbus/xenbus_client.c > > @@ -758,7 +758,7 @@ static int xenbus_map_ring_pv(struct xenbus_device = *dev, > > bool leaked =3D false; > > int err =3D -ENOMEM; > > > > - area =3D get_vm_area(XEN_PAGE_SIZE * nr_grefs, VM_IOREMAP); > > + area =3D get_vm_area(XEN_PAGE_SIZE * nr_grefs, VM_XEN); > > if (!area) > > return -ENOMEM; > > if (apply_to_page_range(&init_mm, (unsigned long)area->addr, > > diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h > > index c720be70c8dd..223e51c243bc 100644 > > --- a/include/linux/vmalloc.h > > +++ b/include/linux/vmalloc.h > > @@ -28,6 +28,7 @@ struct iov_iter; /* in uio.h */ > > #define VM_FLUSH_RESET_PERMS 0x00000100 /* reset direct map and f= lush TLB on unmap, can't be freed in atomic context */ > > #define VM_MAP_PUT_PAGES 0x00000200 /* put pages and free arr= ay in vfree */ > > #define VM_ALLOW_HUGE_VMAP 0x00000400 /* Allow for huge pages o= n archs with HAVE_ARCH_HUGE_VMALLOC */ > > +#define VM_XEN 0x00000800 /* xen use cases = */ > > > > #if (defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)) &= & \ > > !defined(CONFIG_KASAN_VMALLOC) > > There's also VM_DEFER_KMEMLEAK a line below: Ohh. Good catch. Will fix. > I think it makes sense to use an enumeration for vm_flags, just like as > Suren did for GFP > (https://lore.kernel.org/linux-mm/20240224015800.2569851-1-surenb@google.= com/) Hmm. I'm pretty sure Christoph hates BIT macro obfuscation. I'm not a fan of it either, though we use it in bpf in a few places. If mm folks prefer that style they can do such conversion later. From xen-devel-bounces@lists.xenproject.org Tue Mar 05 00:48:32 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 00:48:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688551.1072817 (Exim 4.92) (envelope-from ) id 1rhIyp-0008V1-94; Tue, 05 Mar 2024 00:48:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688551.1072817; Tue, 05 Mar 2024 00:48:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhIyp-0008Uu-5n; Tue, 05 Mar 2024 00:48:27 +0000 Received: by outflank-mailman (input) for mailman id 688551; Tue, 05 Mar 2024 00:48:26 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhIyn-0008Um-Th for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 00:48:26 +0000 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.20]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 10a8f7d8-da8a-11ee-a1ee-f123f15fe8a2; Tue, 05 Mar 2024 01:48:23 +0100 (CET) Received: from fmviesa007.fm.intel.com ([10.60.135.147]) by orvoesa112.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Mar 2024 16:48:21 -0800 Received: from fmsmsx601.amr.corp.intel.com ([10.18.126.81]) by fmviesa007.fm.intel.com with ESMTP/TLS/AES256-GCM-SHA384; 04 Mar 2024 16:48:20 -0800 Received: from fmsmsx610.amr.corp.intel.com (10.18.126.90) by fmsmsx601.amr.corp.intel.com (10.18.126.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Mon, 4 Mar 2024 16:48:19 -0800 Received: from fmsedg601.ED.cps.intel.com (10.1.192.135) by fmsmsx610.amr.corp.intel.com (10.18.126.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35 via Frontend Transport; Mon, 4 Mar 2024 16:48:19 -0800 Received: from NAM02-BN1-obe.outbound.protection.outlook.com (104.47.51.41) by edgegateway.intel.com (192.55.55.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Mon, 4 Mar 2024 16:48:16 -0800 Received: from BN9PR11MB5276.namprd11.prod.outlook.com (2603:10b6:408:135::18) by CY8PR11MB7034.namprd11.prod.outlook.com (2603:10b6:930:52::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.22; Tue, 5 Mar 2024 00:48:05 +0000 Received: from BN9PR11MB5276.namprd11.prod.outlook.com ([fe80::39d:5a9c:c9f5:c327]) by BN9PR11MB5276.namprd11.prod.outlook.com ([fe80::39d:5a9c:c9f5:c327%5]) with mapi id 15.20.7362.019; Tue, 5 Mar 2024 00:48:05 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 10a8f7d8-da8a-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1709599704; x=1741135704; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=rxDH0q8yuC/kgo4baYZFlz6wgNJvXRfO1fIst9UQQZ8=; b=VelIXN5fHYewZv6iRwC4sqYqu+BYrOvSy6CYvfl9V9NqoJtd6H4bAtjs OPl8dRtuotxr54GayTX95ast4OGCSh9HGWkzUG/880HO17nfJRvLC58d2 Kw5JodEWiyioqJUhFCbadRYTppXbPV/fCE/xRRTblhg0CQ6N+HxjLlBWa UnIlCJ2gDj5zsPkIPs9XFl9+Wcr3m8/zh38i10ndG0aJ3urtbS9cNNwxd uD9qxO4PMW6MUCEs9u5JMAUkFvXDXkYTGbiEaaIiLucwV4PYgYnz3Scms qaq42YUOQxNaY4qsfBCh1CIKDeaJ5vY/MjAxI9jIlyhB3EYQ5plSjPDy2 A==; X-IronPort-AV: E=McAfee;i="6600,9927,11003"; a="4005157" X-IronPort-AV: E=Sophos;i="6.06,204,1705392000"; d="scan'208";a="4005157" X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.06,204,1705392000"; d="scan'208";a="9025911" ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XhZl/tHOphDTDiNED4pqxXIn9e2qyvIPFrRVk/pnTyk+KIlHYJhbXOLHReSbXjHYsH+WxY1tVVJw6soAhEfanGRlnhg7Oe3HVGgUyWLZctxyWWcAQU2aUcpkrM1dE/0Wqs6mhBoWkByKHB7MWRC6+a11q1fN2+ijU1G9KrvXbwj+QAw0925T+YlRpGigA2Mi9M2NnZQwogfahcRN2ZHK2yIb/TwqGeqSMGL8epzA6paPFi/jQHJmqTUBWm/wgUleE/OyojaTLOcvKzHWujJ+TV4aCgZ/+tk1z9o0D9PUFIvlZMDsucUA5ZxUiKcObWEezxyER4EzLlPdQ0Rgrr/vfg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=rxDH0q8yuC/kgo4baYZFlz6wgNJvXRfO1fIst9UQQZ8=; b=NzZJZi+XOvUhIYHi4+k0xBr1rUAHTCTy8zLqwf/kww3hDRQkOFZDWkBlMfsZB2IS8yQDK5eL14N0IRgeqoLtHzx4G5nt6s1oUGT2WWBMeRBv/hjokPS8al+08uXkmFjoxLEcKUr0IuqDypG9JpdyAYffYlEft7ieyWDGDL3BGoURFqvkuWjbZ3UkhaBRQsPCpY0O8gsR898WPoFs60Y1ZPtTEaTZ1sH2BbeLiocJCe14HQZEPmKG45NN4p5CcrWJVPFU0lXBuWzZori24tujnzAEE8mX23xXhMy6vTypGpYMK0Vc4NlieygA+alJiDs0saVOtne0YPe6czCovUiQ3A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none From: "Tian, Kevin" To: "Beulich, Jan" , "xen-devel@lists.xenproject.org" CC: "andrew.cooper3@citrix.com" , Wei Liu , =?utf-8?B?UGF1IE1vbm7DqSwgUm9nZXI=?= , "Nakajima, Jun" Subject: RE: [PATCH] MAINTAINERS: drop AMD SVM and Intel VT-x sections Thread-Topic: [PATCH] MAINTAINERS: drop AMD SVM and Intel VT-x sections Thread-Index: AQHabhY7yQbpZrz4nkSVm3UgsuStHbEoUIEA Date: Tue, 5 Mar 2024 00:48:05 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: BN9PR11MB5276:EE_|CY8PR11MB7034:EE_ x-ms-office365-filtering-correlation-id: 7ddaa7fb-6b7e-42ae-a959-08dc3cadeb29 x-ld-processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: R/ZbCMJP4j/M6c1S7noXSyES0hHFptvnf/r47BqBrOJ/ZVZ/LyJUyptdnAplHI7UBqBGG7bz1TuW6bQEfKOLZ3zHEEkKqW+lCKX9eBIqFrno8RBu5ChamYPTPPD5FzV9SSd0JQSEzPQbb45Cizu/zIY7JlICnZgEaJN3Pk/3k7dQ16knpeaWAdH51KD+5aZy1J3G+NGAlMxLT0KMp7+f93qqz2Sd5JFeBftk0Wygf5+QgouH4TEk1liw9/nNThCtnQBlwpcQrmFY/QBKpRo9nUYe8eBz+MxKklKmN+3+ntGf1rlT5hIEKlJK9J4heVunz3iQewkAaREs7YWGWZXea/gkw6+t2S8O9CdoFOviSZZP7S3BsPjbxICQJLq2LApJhxDD7IIuOEu0tcspk0TQRkht9hppPt4hyZutlfyQ450yh/vAeHLSKjN1zFEiTomHKZcp77J0A3vFP7Sg982coJLKxF2tRI7JdT+SoDq7c1kvjgS0Ph2ZXJ9dj0+V9YdIOiYed1c4e8wEEgLCFKDv4gQ1L2YRJzfL6RPelem1NT8Y+pjfNT3S9yctTp5id+Ro+218UOgpPqtca2BohixV2yTG8S0yjXZA5FLtQirEC8ehSkuKKPZ2WcgpuwZqn2XGXXoHAC5qOmU5S/n4S65rcUzmNd4taLeLG4P83rci+Pp7LdnObMBioNnvDr8gqtVTJuZryG3UppHfGLfooEax1bI53QghyST8RAw80+l9mBI= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR11MB5276.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(376005)(38070700009);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?UEVzSHJaSVJkbXBxY3hRWkFnN2VrWlgyb0FGUGtsR0FHVjBIdUhPaGNSdWYv?= =?utf-8?B?N0ZsQlFjNzFscy82R0I2dVhuL0lpUkJpZTdGMEw3MmNzSm1FaFlPSVJWT2s2?= =?utf-8?B?akh6V0N5OW5XdG42MnpySnFxUXBQZHFJak1Kd0szUGVjSUE3T3gxY3BkRXVR?= =?utf-8?B?VUNJa3Y0bGF2Q0dvVkZWWEFTbVNCRUs2em5XNllGUmxmZUdHWUl3ZXJ2Tzhq?= =?utf-8?B?N3VqaUxYQnN0TFB5VTNMTW5SVnJmN3dJK1BWanVDVGt5dkpLWnhnSUU3WmFz?= =?utf-8?B?TmNqRUdsNTR2ZHV2ejU0SVM3dHpzc2J3aVkvOXNHZEhudEJ6QjEzanlBMWcz?= =?utf-8?B?K2lQM25kUUF0YnF5WDY1ZWpVUU0wS1NWWGZHdUNwdnZwSWFhb28veUp5a3VT?= =?utf-8?B?M2cxc3krd1RnSE84WWZWK0ZaTjdXUklLeHZZeVZrOC94aURPTjhwNGNuVjB6?= =?utf-8?B?dzhvT21icjAvNDdjMDFlbWhHWHpnOVVINWVvSHh5VjZtS0JrWU9uVFd6d2lB?= =?utf-8?B?L0ZxSjB3R1FVd1RJWGNxQXJXVkthUXV2ZE42Mms2NkVydktSRTVxQ3FEY1Bj?= =?utf-8?B?RXRPa3M5cWttSThLQUNjeVdTRXJDRldCL0VMMjlsTVdKUW0zS1NzelBsQ0du?= =?utf-8?B?MHFScDduRmR0K3JybytXb0VhRVJEOVNTY2g0YnpERlhJZGtWbHdlMC82UVFa?= =?utf-8?B?d3dqNlYvR0NHYW81dUdMa3RPMHF0Rm0zZjhWa01zOEdlQk5oY0tDK092ZzN2?= =?utf-8?B?czV4REJPRmtrRVpxK3RsdU1mbzhBZzJuOUdWb0k1WmNYNUdCcDZzL3I4VnpG?= =?utf-8?B?ejVBbzY3MjJ4ejRjSEdWN3JyaUkzcTA1VmRjZVVFdVk1Lzc3Z3NUdlhyWHFp?= =?utf-8?B?UlFGRGZUR3NqYStabzREYzJqcmNkcXBSUEc2QmJxcTBWZDFHNmQyUEN6TGpx?= =?utf-8?B?RVNGRDA2aFkrdnd2QjdkVXZwZmZuUnR6QU9WQk5PQmpsSnlXQjI4UHpNL3NH?= =?utf-8?B?a01BclNjQ29zd0ZrYXVJaGVad1U2SnV4SU5pQkxDOHRIaUtlcDhjaS9XMHRB?= =?utf-8?B?a0dMWkJ0Vm00czJFSDI1djhWVk9tLzhaSDMrazZ2Q1ZkTC9SZlB3K3Ewd2or?= =?utf-8?B?RXpYa3FJU0lDWG80dmVXN29ZK2lGSlN6bytmb2pnM2VoMHVOT2tOUUhieml1?= =?utf-8?B?ci9LeU1STzg4YU5yTmFYQVNxWkRiZ053eXBtdkJxaDcrd2Q0WG1jNXhyTGda?= =?utf-8?B?aDRlemtXNEpibjdiWENhZ1lkT2l6ak5yc2lyY1RrYUw2WisyOFBoZEVWbVFr?= =?utf-8?B?QTF1Ti9nVGJjV2U1dERMWVU2bkZwM2xlYUVLRk9JWERYKy9hMHJVQjZyY0sx?= =?utf-8?B?R3hKMG02M0N0MVZ1TGt6bEVMOUpTSFRTeUs1RzJPOE1CdVRZQVhIb0lxWWQ5?= =?utf-8?B?cEprYlFxK0ovMXVxbnR4c1ZrWU1jZFFCWGlkVXZSNU1aa1ZrZmJGZWhSSWdw?= =?utf-8?B?U1dKRGlyTUN1ODFyQ1Q5eGVMMVdGWWpsMkZISzN0ckxmMGxlR2F5U212NHhE?= =?utf-8?B?SVlMcXZ4bXBRY0lzaEZaMW85N21VbnlmbzlpNEdaRU84a0QvN0Q4NndlWFds?= =?utf-8?B?cUNlQ0F5amd2VnIvVU14NnlaYVU3WHMraFJOLzNLc2srNlJYd081aXFReGVE?= =?utf-8?B?ZDJFMHZ1RUhnVSt3NmE2bkJJRVR3N0ltWHE4a1pZY0YwR3VGZ0ovMzVLRCtR?= =?utf-8?B?ZjRDYUhJVDJqTzk4WlRIUytYaUlJRkp3QTdKSFVaMGVFK2NkSjR3TGlZSVJZ?= =?utf-8?B?eE5NZXZvNXNSZ3U5Qjl1OHljZjlJQzNtTnRXUmVjRFVGSnhtcWZOYVZqL1R5?= =?utf-8?B?R05PUWM2ZTdHRk5jL0YzUFFoSWlLd2JBd0RWaXVpbXEzN2V5VTIzcEVNeTRO?= =?utf-8?B?QWs0NGU3d3NiYWE5V2Y5R21lVW5PY1RidHBQRk1CVllKQXErQUtsL2Z3SC9G?= =?utf-8?B?UURpRDVESGRuNXdMWi8yUVJ1MFpkVGxUVlNPbDJhUlE0SWlrR05tYzFaZmU5?= =?utf-8?B?WmcrUWtmKzNVWTR1UnMvRTFtYlVuSURsekNvTFJXZm00aHMwamxoRHdBaHFs?= =?utf-8?Q?P+cd/dMu9JBlFfyw8uDogHTcX?= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN9PR11MB5276.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7ddaa7fb-6b7e-42ae-a959-08dc3cadeb29 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2024 00:48:05.1532 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pq4nHYfAee2X7A1PE6RGKJbmawXsxILf8q1HuxKV8TPz63vitkL34liGItTtz48HqX1ohEiRJIw2GgeBF16/3A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR11MB7034 X-OriginatorOrg: intel.com PiBGcm9tOiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IFNlbnQ6IE1vbmRheSwg TWFyY2ggNCwgMjAyNCA1OjI4IFBNDQo+IA0KPiBXZSdkIGxpa2UgdG8gdGhhbmsgdGhlIFZULXgg bWFpbnRhaW5lcnMgZm9yIHRoZWlyIHBhc3QgY29udHJpYnV0aW9ucywNCj4gd2hpbGUgYXQgdGhl IHNhbWUgdGltZSB3ZSdkIGxpa2UgdG8gcmVmbGVjdCByZWFsaXR5IGFzIGl0IGhhcyBiZWVuIGZv cg0KPiBxdWl0ZSBzb21lIHRpbWUuIEhhdmUgVlQteCBtYWludGFpbmVyc2hpcCAoYW5kIGZvciBz eW1tZXRyeSBhbHNvIEFNRA0KPiBTVk0ncykgZmFsbCBiYWNrIHRvIGdlbmVyYWwgeDg2Lg0KPiAN Cj4gU2lnbmVkLW9mZi1ieTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPg0KPiANCg0K QWNrZWQtYnk6IEtldmluIFRpYW4gPGtldmluLnRpYW5AaW50ZWwuY29tPg0K From xen-devel-bounces@lists.xenproject.org Tue Mar 05 01:43:39 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 01:43:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688555.1072827 (Exim 4.92) (envelope-from ) id 1rhJq3-0007GK-72; Tue, 05 Mar 2024 01:43:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688555.1072827; Tue, 05 Mar 2024 01:43:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhJq3-0007GD-3h; Tue, 05 Mar 2024 01:43:27 +0000 Received: by outflank-mailman (input) for mailman id 688555; Tue, 05 Mar 2024 01:43:25 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhJq1-0007G7-6p for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 01:43:25 +0000 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id c02fdf88-da91-11ee-afda-a90da7624cb6; Tue, 05 Mar 2024 02:43:23 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 168B06123D; Tue, 5 Mar 2024 01:43:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 48522C433F1; Tue, 5 Mar 2024 01:43:20 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c02fdf88-da91-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1709603001; bh=UQ8xvgE4PyUtyvAlJerlsFFevZfWBtILYW06mJRvGhY=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=NsCnTsFaSUEIPedIWHWRpymkgPNVf49rpZyd4z47zz4k3kheE7AWtqL/RjKq7zwQr 1DP6AK+bOE8pMHSBpbojJlPRh7c0JxoGwv5/5OSfm228q4t3OPaR9ATP99/eE+0KHs 1JFuoxIsxSan/dSFKMjSEFoFOm7Xp0WgkyP+/OTZ7YHAReLc58prlpUiH0aTygxpOO Fxjv+5Wh9bIHRru5ahcYK1yITGctec5xUWQJChTVRhIIRC9NXbeSJH0ya3hf+FNmNw 7K81zavluFstjx+m69Ly+nB0k2bSVKMy1l3CGkr1zFXHS5JxBsYET4QrGfTKkluSPr w/4HCwZMSA3VQ== Date: Mon, 4 Mar 2024 17:43:18 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Nicola Vetrini cc: Julien Grall , Stefano Stabellini , Bertrand Marquis , Michal Orzel , xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, consulting@bugseng.com, andrew.cooper3@citrix.com, roger.pau@citrix.com, Volodymyr Babchuk , xen-devel@lists.xenproject.org Subject: Re: [XEN PATCH 02/10] xen/arm: address some violations of MISRA C Rule 20.7 In-Reply-To: <0aae1c64587cfbc67e81a20b36dd5056@bugseng.com> Message-ID: References: <905119be-8731-4669-ac7f-c21aed6845dc@suse.com> <7c54b08875406e5b3a61325af124ae7f@bugseng.com> <0aae1c64587cfbc67e81a20b36dd5056@bugseng.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Mon, 4 Mar 2024, Nicola Vetrini wrote: > Hi, > > as the maintainers of this subsystem, would you prefer Jan's version or the > one in the patch? > Both are fine w.r.t MISRA Rule 20.7 because the macro arguments themselves are > parenthesized. I prefer Jan's version. Thanks for asking Nicola. > > > > --- a/xen/arch/arm/include/asm/vgic-emul.h > > > > +++ b/xen/arch/arm/include/asm/vgic-emul.h > > > > @@ -6,11 +6,11 @@ > > > > * a range of registers > > > > */ > > > > > > > > -#define VREG32(reg) reg ... reg + 3 > > > > -#define VREG64(reg) reg ... reg + 7 > > > > +#define VREG32(reg) (reg) ... (reg) + 3 > > > > +#define VREG64(reg) (reg) ... (reg) + 7 > > > > > > #define VREG32(reg) (reg) ... ((reg) + 3) > > > #define VREG64(reg) (reg) ... ((reg) + 7) > > > > > > ? > > > > > > > The outer parentheses are not required, but I can add them if the > > maintainers share your view. From xen-devel-bounces@lists.xenproject.org Tue Mar 05 01:49:50 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 01:49:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688558.1072837 (Exim 4.92) (envelope-from ) id 1rhJw9-0007tz-Rh; Tue, 05 Mar 2024 01:49:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688558.1072837; Tue, 05 Mar 2024 01:49:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhJw9-0007ts-On; Tue, 05 Mar 2024 01:49:45 +0000 Received: by outflank-mailman (input) for mailman id 688558; Tue, 05 Mar 2024 01:49:44 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhJw8-0007tm-JE for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 01:49:44 +0000 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id a1e67385-da92-11ee-afda-a90da7624cb6; Tue, 05 Mar 2024 02:49:42 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id BD247CE0221; Tue, 5 Mar 2024 01:49:39 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A088CC433C7; Tue, 5 Mar 2024 01:49:37 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a1e67385-da92-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1709603379; bh=tghHVhCBl0yGVtdevgFGm/Tc2ZH2+DFLIe9oQckKlsc=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=WhoBa7LOeExYXabVeu0VqIELUzV75DBahYk7q2bFWDMmdtKUplDKai6SLH0XD54QR F/QbYnalLxxMI0zZkNs9WSvREWOGsOYY/Hq6wcu3ZGACeeYyyK44WCvrtrpwCIUo4K /ovXmRoD0y12fKbTMlfpKuv1DF1wJ8/fCHkHeC/nra+Gi+oRUZvXJ2Rs3ybKsnM4ej 3g2T1sXTnexOIrW56e24zn3ERd/lWVNUIfnmCAj+FuUpoi2dvRuivBjaXB1yJy9v5U G0AoDm6YLZ81a4QdsyfXR9efnRL20f0a5iGab12S/HjQ7FxCQseis5mg81PtsDyj9R 8kznca4+gE42Q== Date: Mon, 4 Mar 2024 17:49:36 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Jan Beulich cc: Federico Serafini , andrew.cooper3@citrix.com, george.dunlap@citrix.com, julien@xen.org, bertrand.marquis@arm.com, roger.pau@citrix.com, xen-devel@lists.xenproject.org, Stefano Stabellini , roberto.bagnara@bugseng.com, Stefano Stabellini Subject: Re: [PATCH v2 2/3] docs/misra/rules.rst: add rule 5.5 In-Reply-To: <8e5d4c48-558d-40e2-851a-3eb6bfa5dbfe@suse.com> Message-ID: References: <20240213223334.3693410-2-stefano.stabellini@amd.com> <50719397-b053-43e1-9cf7-cc9eae9098ed@suse.com> <40b7465f-4966-43c7-8db3-e28a6cc48445@bugseng.com> <2da73259-a86e-4a13-9fd4-4217372f4b76@suse.com> <3632611e-61ff-455a-9cc1-990a1f663d83@bugseng.com> <7747cb81-8fdb-4a5f-bfd1-c6c9bdb6039a@suse.com> <8e5d4c48-558d-40e2-851a-3eb6bfa5dbfe@suse.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Mon, 4 Mar 2024, Jan Beulich wrote: > On 04.03.2024 16:39, Federico Serafini wrote: > > On 04/03/24 15:17, Jan Beulich wrote: > >> On 04.03.2024 14:31, Federico Serafini wrote: > >>> On 01/03/24 09:06, Jan Beulich wrote: > >>>> On 01.03.2024 00:28, Stefano Stabellini wrote: > >>>>> On Wed, 14 Feb 2024, Federico Serafini wrote: > >>>>>> On 14/02/24 14:15, Jan Beulich wrote: > >>>>>>> On 14.02.2024 12:27, Federico Serafini wrote: > >>>>>>>> On 14/02/24 09:28, Jan Beulich wrote: > >>>>>>>>> On 13.02.2024 23:33, Stefano Stabellini wrote: > >>>>>>>>>> Signed-off-by: Stefano Stabellini > >>>>>>>>>> --- > >>>>>>>>>> docs/misra/rules.rst | 6 ++++++ > >>>>>>>>>> 1 file changed, 6 insertions(+) > >>>>>>>>>> > >>>>>>>>>> diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst > >>>>>>>>>> index c185366966..931158b354 100644 > >>>>>>>>>> --- a/docs/misra/rules.rst > >>>>>>>>>> +++ b/docs/misra/rules.rst > >>>>>>>>>> @@ -181,6 +181,12 @@ maintainers if you want to suggest a change. > >>>>>>>>>> headers (xen/include/public/) are allowed to retain longer > >>>>>>>>>> identifiers for backward compatibility. > >>>>>>>>>> + * - `Rule 5.5 > >>>>>>>>>> `_ > >>>>>>>>>> + - Required > >>>>>>>>>> + - Identifiers shall be distinct from macro names > >>>>>>>>>> + - Clashes between function-like macros and non-callable entities > >>>>>>>>>> + are allowed. The pattern #define x x is also allowed. > >>>>>>>>> > >>>>>>>>> Just for me to know what exactly is covered (hence also a question > >>>>>>>>> to Roberto as to [to be] implemented Eclair behavior): Even when > >>>>>>>>> the above would be sufficient (and imo better) people frequently > >>>>>>>>> write > >>>>>>>>> > >>>>>>>>> #define a(x, y) b(x, y) > >>>>>>>>> > >>>>>>>>> which, transformed to the specific case here, would then be > >>>>>>>>> > >>>>>>>>> #define a(x, y) a(x, y) > >>>>>>>>> > >>>>>>>>> I'd assume such ought to also be covered, but that's not clear > >>>>>>>>> from the spelling above. > >>>>>>>> > >>>>>>>> I list what happens in some different situations, > >>>>>>>> then we can find the right words for the documentation and/or > >>>>>>>> refine the configuration: > >>>>>>>> > >>>>>>>> If you > >>>>>>>> #define x x > >>>>>>>> and then use `x' as identifier, > >>>>>>>> the resulting violation is deviated (allowed pattern). > >>>>>>>> > >>>>>>>> If you > >>>>>>>> #define a(x, y) a(x, y) > >>>>>>>> and then use `a' as identifier for a non-callable entity, > >>>>>>>> the resulting violation is deviated (no clash with non-callable > >>>>>>>> entities). > >>>>>>>> If you use identifier `a' for a callable entity, the resulting violation > >>>>>>>> is reported: the allowed pattern covers only macros expanding to their > >>>>>>>> own name, in this case the macro name is considered to be > >>>>>>>> `a' only, not a(x, y). > >>>>>>>> > >>>>>>>> If you > >>>>>>>> #define a(x, y) b(x, y) > >>>>>>>> and then use `a' as identifier for a non-callable entity, > >>>>>>>> the resulting violation is deviated (no clash with non-callable > >>>>>>>> entities). > >>>>>>> > >>>>>>> I'm afraid I don't see what violation there is in this case, to > >>>>>>> deviate. As a result I'm also not sure I correctly understand the > >>>>>>> rest of your reply. > >>>>>> > >>>>>> #define a(x, y) b(x, y) > >>>>>> > >>>>>> int a; // Violation of Rule 5.5. > >>>>>> > >>>>>> The macro name `a' that exist before the preprocessing phase, > >>>>>> still exists after the preprocessing phase as identifier for the integer > >>>>>> variable and this is a violation. > >>>>>> > >>>>>>>> If you use `a' as identifier for a callable entity, > >>>>>>>> this is not a violation because after the preprocessing phase, > >>>>>>>> identifier `a' no longer exists. > >>>>>> I correct myself: > >>>>>> if you use `a' as identifier for a *function*, > >>>>>> it is not a violation because after the preprocessing phase > >>>>>> the identifier `a' no longer exists, for example: > >>>>>> > >>>>>> #define a(x, y) b(x, y) > >>>>>> > >>>>>> void a(int x, int y); // Ok. > >>>>> > >>>>> Federico, do you have a better wording suggestion for this rule? > >>>>> > >>>>> Jan, any further requests here? What would you like to see as next step? > >>>> > >>>> A more concise wording proposal would probably help. > >>> > >>> What do you think about: > >>> > >>> diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst > >>> index 1e134ccebc..a975b9a85f 100644 > >>> --- a/docs/misra/rules.rst > >>> +++ b/docs/misra/rules.rst > >>> @@ -181,6 +181,13 @@ maintainers if you want to suggest a change. > >>> headers (xen/include/public/) are allowed to retain longer > >>> identifiers for backward compatibility. > >>> > >>> + * - `Rule 5.5 > >>> `_ > >>> + - Required > >>> + - Identifiers shall be distinct from macro names > >>> + - Macros expanding to their own name are allowed (e.g., #define x x). > >>> + Clashes between names of function-like macros and identifiers of > >>> + non-callable entities are allowed. > >> > >> Imo that still leaves open e.g. the > >> > >> #define a(x, y) a(x, y) > >> > >> case: Permitted ("own name") or not permitted ("a" pretty clearly is expected > >> to be a callable entity here, besides being a function-like macro)? > > > > I would not consider your example as a macro that expands to its own > > name, the macro name is considered to be `a' only. > > That's what I was assuming, and hence my asking back. I think the > above ought to be permitted just like "#define x x", and hence the > suggested text would need expanding, to ... > > > Rather, you example can be used to trigger the "callable-noncallable" > > part of the deviation, for example: > > > > #define a(x, y) a(x, y) > > > > void a(int x, int y); /* Not permitted (callable entity 'a'). */ > > ... prevent this ("not permitted") from happening. I'm pretty sure > you've already found instances of this pattern in our code base. Sorry Jan, purely asking as a clarification because I couldn't understand what you wrote. You are asking for a clarification in the wording so that the following is explicitly allowed, right? #define a(x, y) a(x, y) void a(int x, int y); From xen-devel-bounces@lists.xenproject.org Tue Mar 05 01:52:24 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 01:52:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688561.1072847 (Exim 4.92) (envelope-from ) id 1rhJyh-0001Dk-9k; Tue, 05 Mar 2024 01:52:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688561.1072847; Tue, 05 Mar 2024 01:52:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhJyh-0001Dd-6q; Tue, 05 Mar 2024 01:52:23 +0000 Received: by outflank-mailman (input) for mailman id 688561; Tue, 05 Mar 2024 01:52:22 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhJyg-0001DX-Au for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 01:52:22 +0000 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id ffbf1b41-da92-11ee-a1ee-f123f15fe8a2; Tue, 05 Mar 2024 02:52:20 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id B53ABCE176C; Tue, 5 Mar 2024 01:52:17 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 34FBAC433C7; Tue, 5 Mar 2024 01:52:15 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ffbf1b41-da92-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1709603536; bh=yXTpxcHXVjCfHzE6Bw1Bh5Jx7YQUuR2HQaPwIuPASS8=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=qpK4/s3R7aypOCRD6pa1X7W7pFUQPFhXBrHttoPX0swnwuXCDuXZ5BVhi+x6Cq17B uMVjqE6iIp5j6Vu2EIaqApBQXb2WAkEL308KXgCLAnQv6jgQRMa2qI/VkSz5AbF5Z5 rlRNUat7xX3LRcYbV5bSC9suaSIJsNAgzXfU+0FW3cOQJJMlMPF6m2KykK2/4j8DdQ b3mqtT19oIRlRrvnPrltR2iLMhXiXxNOeBfzQwVsXRyMvzBxi/E2GSxnlQ/aXgFa2G cl4vB3cowYWwkhBnxhXxT4YxgaL7MeOiVKAIEbbdOJGZ5avFlkcfCHpZ2L2b1dIm9r s27sbmBmPkIrQ== Date: Mon, 4 Mar 2024 17:52:13 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Federico Serafini cc: xen-devel@lists.xenproject.org, consulting@bugseng.com, Simone Ballarin , Doug Goldstein , Stefano Stabellini , Andrew Cooper , George Dunlap , Jan Beulich , Julien Grall , Wei Liu Subject: Re: [XEN PATCH] automation/eclair: add deviation for MISRA C:2012 Rule 16.6 In-Reply-To: Message-ID: References: User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Mon, 4 Mar 2024, Federico Serafini wrote: > Update ECLAIR configuration to take into account the deviations > agreed during MISRA meetings. > > Signed-off-by: Federico Serafini Reviewed-by: Stefano Stabellini From xen-devel-bounces@lists.xenproject.org Tue Mar 05 02:03:17 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 02:03:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688565.1072857 (Exim 4.92) (envelope-from ) id 1rhK98-0003eC-9Q; Tue, 05 Mar 2024 02:03:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688565.1072857; Tue, 05 Mar 2024 02:03:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhK98-0003e5-51; Tue, 05 Mar 2024 02:03:10 +0000 Received: by outflank-mailman (input) for mailman id 688565; Tue, 05 Mar 2024 02:03:08 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhK96-0003dz-Or for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 02:03:08 +0000 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 81310a80-da94-11ee-a1ee-f123f15fe8a2; Tue, 05 Mar 2024 03:03:06 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id AB5FB61323; Tue, 5 Mar 2024 02:03:04 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 971E5C433A6; Tue, 5 Mar 2024 02:03:02 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 81310a80-da94-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1709604184; bh=44hF53+GnnUl7hHcXX4PnfbEfEIeWhtu+CufIDQem50=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=e3LYIXUHMkn7mZb3TEOgFkDzuXIQKnPZMhj+a0YTLd2iPS7tu9DUD1SGyKZXKSV06 goizl/Rzs6++OdGobb2m5yiAtoe6s5hlAvcvPNUcBEQr2nW9s2d72DeajtF/N+RwiP fzztViUjDtESRekDqq39DIJjUwMbH3HA3UVwuBMDTpZRG77OuE3gSwBH+RLB9itRhe 4YMOROusnRjqg/9Ap6M0DDkren8fC3NaMKpyZq9rY2lJaXZpVNqdkNTN6JnCpJFJfD t1NCUqDkG4CqGmX72oMvYcLQp1Nbrqs22W18WxDDbpf55P6+8rl5n1e2U4YbUfHRGn px2A+50oxbmLA== Date: Mon, 4 Mar 2024 18:03:00 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Jan Beulich cc: Stefano Stabellini , xen-devel@lists.xenproject.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, consulting@bugseng.com, andrew.cooper3@citrix.com, roger.pau@citrix.com, bertrand.marquis@arm.com, julien@xen.org, George Dunlap , Wei Liu , Nicola Vetrini Subject: Re: [XEN PATCH 10/10] xen/keyhandler: address violations of MISRA C Rule 20.7 In-Reply-To: Message-ID: References: <2bc4a964f0f2f47488e72237678e944dbdbd7bb7.1709219010.git.nicola.vetrini@bugseng.com> <1afd8805-7365-40ec-8e8e-468a83e20c40@suse.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Mon, 4 Mar 2024, Jan Beulich wrote: > On 02.03.2024 02:37, Stefano Stabellini wrote: > > On Fri, 1 Mar 2024, Jan Beulich wrote: > >> On 29.02.2024 23:57, Stefano Stabellini wrote: > >>> On Thu, 29 Feb 2024, Nicola Vetrini wrote: > >>>> MISRA C Rule 20.7 states: "Expressions resulting from the expansion > >>>> of macro parameters shall be enclosed in parentheses". Therefore, some > >>>> macro definitions should gain additional parentheses to ensure that all > >>>> current and future users will be safe with respect to expansions that > >>>> can possibly alter the semantics of the passed-in macro parameter. > >>>> > >>>> No functional change. > >>>> > >>>> Signed-off-by: Nicola Vetrini > >>> > >>> Reviewed-by: Stefano Stabellini > >> > >> You did see the discussion on earlier patches, though? I don't think > >> any of the parentheses here are needed or wanted. > > > > We need to align on this. Currently if we go by what's written in > > docs/misra/deviations.rst, then rhs should have parentheses. > > Quoting the actual patch again: [...] > What rhs are you talking about in light of this change? The only rhs I > can spot here is already parenthesized. Yes you are right. I replied here as an overall comment about our approach to 20.7, although this patch is not a good example. My reply was meant in the context of https://marc.info/?l=xen-devel&m=170928051025701 > > Can we safely claim that rhs parentheses are never needed? If so, then > > great, let's add it to deviations.rst and skip them here and other > > places in this patch series (e.g. patch #8). When I say "never" I am > > taking for granted that the caller is not doing something completely > > unacceptably broken such as: > > > > WRITE_SYSREG64(var +, TTBR0_EL1) > > I'm afraid I can't associate this with the patch here either. Instead in > the context here a (respective) construct as you mention above would simply > fail to build. Fair enough it will break the build. I was trying to clarify that when I wrote "the rhs parentheses are never needed" I meant "never" within reason. One can always find ways to break the system and I tried to make an example of something that for sure would break rhs or lhs without parentheses. I meant to say, if we don't account for exceptionally broken cases, can we safety say we don't need parentheses for rhs? > > If we cannot generically claim that rhs parentheses are never needed, > > then I don't think we should make any exceptions. We should add them here > > and everywhere else. It should be easy to write a macro or review a > > patch with a macro from someone else, and making special exception makes > > it more difficult for everyone. From xen-devel-bounces@lists.xenproject.org Tue Mar 05 03:05:36 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 03:05:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688569.1072866 (Exim 4.92) (envelope-from ) id 1rhL7M-0004Cv-Mg; Tue, 05 Mar 2024 03:05:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688569.1072866; Tue, 05 Mar 2024 03:05:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhL7M-0004Co-Jr; Tue, 05 Mar 2024 03:05:24 +0000 Received: by outflank-mailman (input) for mailman id 688569; Tue, 05 Mar 2024 03:05:23 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhL7L-0004Ci-AK for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 03:05:23 +0000 Received: from mail-oa1-x2a.google.com (mail-oa1-x2a.google.com [2001:4860:4864:20::2a]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 338b3410-da9d-11ee-afda-a90da7624cb6; Tue, 05 Mar 2024 04:05:21 +0100 (CET) Received: by mail-oa1-x2a.google.com with SMTP id 586e51a60fabf-21fa086008fso2129593fac.0 for ; Mon, 04 Mar 2024 19:05:21 -0800 (PST) Received: from localhost.localdomain ([2620:10d:c090:400::5:9426]) by smtp.gmail.com with ESMTPSA id y15-20020aa7854f000000b006e5a99942c6sm6822695pfn.88.2024.03.04.19.05.18 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Mon, 04 Mar 2024 19:05:19 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 338b3410-da9d-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709607920; x=1710212720; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=GO37OSQRQXlN2VGFyW6LzwjH/NpS/PSzwjkGcO70oKE=; b=bQnktXcuSynRg789+WgNB/k3JCU3EdOWVag3S7z4pUBxTxnoC0/7c1zCQKZ0bAYWTX AahY04IZolUXZyv/5oOLHvGAnFpdr1s1mwfDQ3vQV0mhzmFj+w89dA0EVfwIdzT2oHYa R2U9tviE/xyhwE6wTFS9SWEc/hX2zfhS46UxoT83X1I1U/XNttarPlV/ZUdd7ZoqZI4b m1Qb6CSWTOtC8bXTj6KlwcXuLQHMsgG10ZN3cq+CiFUKqnN7rmm+6cffZ33qL1zWlRxm dFgWr27N/xtHELoz+Sl5PghPtDCgGHE1IKKHF9Ud5UWjOqD0+JF/9RBKEBseO/oGrIoa jE/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709607920; x=1710212720; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=GO37OSQRQXlN2VGFyW6LzwjH/NpS/PSzwjkGcO70oKE=; b=LLBuW2g4LAD0i8cUE0UxImfJ3gJW6V0frbhqSllxtcE9DrP1nfZ4IXDPaUT/a+Qoe7 uteDBmXYCCg0CD1wY/oqu5n2jnlxir3OTui2JqTNHaSFsqTAHrVJHj9lGGfkNMJNP3/s viRZumuVihhk5N6gyErrJgYRPaPBYU9LmSKTpZsnrKKwE530gPIQkTN6vRhtoMcuUlJ2 97qiNV1geK1RoXwciIV6oAB338xzbDZr+m1D4TJGlhhJ5fL1MRuS3+6O1ZqnL78f892F AlCSADPh57XoY48TT3/4NpwzQ4gnUCPF72vtRwRiGHFRKbdml/B0ZslwJ7Z0VEnfKF3M lG9Q== X-Forwarded-Encrypted: i=1; AJvYcCV49LNWGYd+7HN6ZPjvk2pT0PUaPtu+2c9XKJao9LyoGevF7HdTEdlny1nS8tvRmdFtpkSvge5onnRXG6FhvM5uj5jA7POb8nLtzYuvvzE= X-Gm-Message-State: AOJu0YxTujz7O0XZ2EShSAFoulewQPllEU8obqZ/xFcnlkZL9lXXBCoj +Ijf+0JF2zwl3B8QQKcFNouV+hYMZwYsh22AqFuE66msF4KZjzGL X-Google-Smtp-Source: AGHT+IF4DC0r95WIbRC/5og05/9WKTnTnsPpk3e37OmDlc5CQCogzBPB5agJQ7Ifv5VhRu3af2p6Pw== X-Received: by 2002:a05:6870:898f:b0:220:99bf:c26d with SMTP id f15-20020a056870898f00b0022099bfc26dmr589777oaq.9.1709607919882; Mon, 04 Mar 2024 19:05:19 -0800 (PST) From: Alexei Starovoitov To: bpf@vger.kernel.org Cc: daniel@iogearbox.net, andrii@kernel.org, torvalds@linux-foundation.org, brho@google.com, hannes@cmpxchg.org, lstoakes@gmail.com, akpm@linux-foundation.org, urezki@gmail.com, hch@infradead.org, rppt@kernel.org, boris.ostrovsky@oracle.com, sstabellini@kernel.org, jgross@suse.com, linux-mm@kvack.org, xen-devel@lists.xenproject.org, kernel-team@fb.com Subject: [PATCH v4 bpf-next 0/2] mm: Enforce ioremap address space and introduce sparse vm_area Date: Mon, 4 Mar 2024 19:05:14 -0800 Message-Id: <20240305030516.41519-1-alexei.starovoitov@gmail.com> X-Mailer: git-send-email 2.39.3 (Apple Git-145) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Alexei Starovoitov v3 -> v4 - dropped VM_XEN patch for now. It will be in the follow up. - fixed constant as pointed out by Mike v2 -> v3 - added Christoph's reviewed-by to patch 1 - cap commit log lines to 75 chars - factored out common checks in patch 3 into helper - made vm_area_unmap_pages() return void There are various users of kernel virtual address space: vmalloc, vmap, ioremap, xen. - vmalloc use case dominates the usage. Such vm areas have VM_ALLOC flag and these areas are treated differently by KASAN. - the areas created by vmap() function should be tagged with VM_MAP (as majority of the users do). - ioremap areas are tagged with VM_IOREMAP and vm area start is aligned to size of the area unlike vmalloc/vmap. - there is also xen usage that is marked as VM_IOREMAP, but it doesn't call ioremap_page_range() unlike all other VM_IOREMAP users. To clean this up a bit, enforce that ioremap_page_range() checks the range and VM_IOREMAP flag. In addition BPF would like to reserve regions of kernel virtual address space and populate it lazily, similar to xen use cases. For that reason, introduce VM_SPARSE flag and vm_area_[un]map_pages() helpers to populate this sparse area. In the end the /proc/vmallocinfo will show "vmalloc" "vmap" "ioremap" "sparse" categories for different kinds of address regions. ioremap, sparse will return zero when dumped through /proc/kcore Alexei Starovoitov (2): mm: Enforce VM_IOREMAP flag and range in ioremap_page_range. mm: Introduce VM_SPARSE kind and vm_area_[un]map_pages(). include/linux/vmalloc.h | 5 +++ mm/vmalloc.c | 72 +++++++++++++++++++++++++++++++++++++++-- 2 files changed, 75 insertions(+), 2 deletions(-) -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Mar 05 03:05:36 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 03:05:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688570.1072878 (Exim 4.92) (envelope-from ) id 1rhL7P-0004RC-VM; Tue, 05 Mar 2024 03:05:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688570.1072878; Tue, 05 Mar 2024 03:05:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhL7P-0004R5-Qf; Tue, 05 Mar 2024 03:05:27 +0000 Received: by outflank-mailman (input) for mailman id 688570; Tue, 05 Mar 2024 03:05:25 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhL7N-0004Ci-Od for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 03:05:25 +0000 Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [2607:f8b0:4864:20::229]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 35d542d6-da9d-11ee-afda-a90da7624cb6; Tue, 05 Mar 2024 04:05:25 +0100 (CET) Received: by mail-oi1-x229.google.com with SMTP id 5614622812f47-3c1ea5e54d3so1115863b6e.0 for ; Mon, 04 Mar 2024 19:05:25 -0800 (PST) Received: from localhost.localdomain ([2620:10d:c090:400::5:9426]) by smtp.gmail.com with ESMTPSA id i37-20020a635865000000b005dc5289c4edsm7941060pgm.64.2024.03.04.19.05.22 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Mon, 04 Mar 2024 19:05:23 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 35d542d6-da9d-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709607924; x=1710212724; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=Lvs1TetY/ywxZOqb7cu6/qS8FYbgNwju0ZDKmLnC7pk=; b=eV+hOtfVSSrB4hO7qKY1NLugmhUP6FxyBU4rEdTt/Hl2uH3eFaCs90N3luwjiDnhsj plbcMZrj2oObEWr6BiR7F/3Dvm4GHypSABu71vh1VB169m25fRp/6bLFMhoM5wxTLl2r RxBEBwIwQBiTqbecJN6znNh2sktouvMyYJoPBqhDLLs6xMtCgay6RYkiiF3VPxFe045O dPDY4gBmshVD13Dh/ehNNIuMm3OdXNBmdD1fjqd7nN1Ay4oSuIi4ZxJd9hRG9bohAfwI A7yZW1FU0zsqrAmeEni+sEjrgVB3AIPqpYrobiUprqB0cFJQlC5S0XK/hpv0WzMUD2Zm /JTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709607924; x=1710212724; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Lvs1TetY/ywxZOqb7cu6/qS8FYbgNwju0ZDKmLnC7pk=; b=IR9O7gsAgAEDpWxG6okLL6LAL4idXIXo1i/YM28yicGTR4WdFWab+AMjuhHtQ676nk DerO5auzcERS2+JWWPRcKUSUqfsIDvxqZYPSqMw0WAERevUSpQiC9dyg4TTETwM8HPQZ y3w61uvlXGT+FgEjGBBWLQrpqNiDGJadKWVW7NgJVX05iM9wBliUOTKb7w0yqd9mjJo7 5Y7Aq+fBZPNfrgj/0TMrURf/mU9d/+ccDxEC5WDXKz2B8QoHrSnpuKIurEdeIvYximVJ QLYvTvEnYyHL+gp/rx/dzY87aDEsET+/rBB6Rav3ctp9Y6QsE0rR//mOcY452cqqKRpq E4XQ== X-Forwarded-Encrypted: i=1; AJvYcCWzjxPi4GqeKs/2eN4vHzL/ipZZ6O9LtAoYGnEwFAf5bRM9e8j+cFPxsKm9rFgVouR7EYx19zdc3697fBVqD9tEuvebc1YVmbCzjCfgZRI= X-Gm-Message-State: AOJu0Yyo9EEMrlxTpD60P3yllNQHRxb5kTr4VyZsi/96ByGpHQMHayLa MW25V9PAPYqMDx2zFMtlzy9+G3fDBzX/Sds+lvBbovnyAHObZMZI X-Google-Smtp-Source: AGHT+IFYfdb0wzVKskM65cSKwSSitCWQ5HIwpxCM5POpmVMYG5/Wx6Ndr8UyOlbODBpKZ1uFvI0VUw== X-Received: by 2002:a05:6808:4c3:b0:3c2:c13:978c with SMTP id a3-20020a05680804c300b003c20c13978cmr597466oie.5.1709607923728; Mon, 04 Mar 2024 19:05:23 -0800 (PST) From: Alexei Starovoitov To: bpf@vger.kernel.org Cc: daniel@iogearbox.net, andrii@kernel.org, torvalds@linux-foundation.org, brho@google.com, hannes@cmpxchg.org, lstoakes@gmail.com, akpm@linux-foundation.org, urezki@gmail.com, hch@infradead.org, rppt@kernel.org, boris.ostrovsky@oracle.com, sstabellini@kernel.org, jgross@suse.com, linux-mm@kvack.org, xen-devel@lists.xenproject.org, kernel-team@fb.com Subject: [PATCH v4 bpf-next 1/2] mm: Enforce VM_IOREMAP flag and range in ioremap_page_range. Date: Mon, 4 Mar 2024 19:05:15 -0800 Message-Id: <20240305030516.41519-2-alexei.starovoitov@gmail.com> X-Mailer: git-send-email 2.39.3 (Apple Git-145) In-Reply-To: <20240305030516.41519-1-alexei.starovoitov@gmail.com> References: <20240305030516.41519-1-alexei.starovoitov@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Alexei Starovoitov There are various users of get_vm_area() + ioremap_page_range() APIs. Enforce that get_vm_area() was requested as VM_IOREMAP type and range passed to ioremap_page_range() matches created vm_area to avoid accidentally ioremap-ing into wrong address range. Reviewed-by: Christoph Hellwig Signed-off-by: Alexei Starovoitov --- mm/vmalloc.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/mm/vmalloc.c b/mm/vmalloc.c index d12a17fc0c17..f42f98a127d5 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -307,8 +307,21 @@ static int vmap_range_noflush(unsigned long addr, unsigned long end, int ioremap_page_range(unsigned long addr, unsigned long end, phys_addr_t phys_addr, pgprot_t prot) { + struct vm_struct *area; int err; + area = find_vm_area((void *)addr); + if (!area || !(area->flags & VM_IOREMAP)) { + WARN_ONCE(1, "vm_area at addr %lx is not marked as VM_IOREMAP\n", addr); + return -EINVAL; + } + if (addr != (unsigned long)area->addr || + (void *)end != area->addr + get_vm_area_size(area)) { + WARN_ONCE(1, "ioremap request [%lx,%lx) doesn't match vm_area [%lx, %lx)\n", + addr, end, (long)area->addr, + (long)area->addr + get_vm_area_size(area)); + return -ERANGE; + } err = vmap_range_noflush(addr, end, phys_addr, pgprot_nx(prot), ioremap_max_page_shift); flush_cache_vmap(addr, end); -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Mar 05 03:05:37 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 03:05:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688571.1072887 (Exim 4.92) (envelope-from ) id 1rhL7V-0004iL-6S; Tue, 05 Mar 2024 03:05:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688571.1072887; Tue, 05 Mar 2024 03:05:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhL7V-0004iC-20; Tue, 05 Mar 2024 03:05:33 +0000 Received: by outflank-mailman (input) for mailman id 688571; Tue, 05 Mar 2024 03:05:32 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhL7U-0004h8-1j for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 03:05:32 +0000 Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [2607:f8b0:4864:20::433]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 387f0d39-da9d-11ee-a1ee-f123f15fe8a2; Tue, 05 Mar 2024 04:05:29 +0100 (CET) Received: by mail-pf1-x433.google.com with SMTP id d2e1a72fcca58-6e5eaf5bb3eso241187b3a.3 for ; Mon, 04 Mar 2024 19:05:29 -0800 (PST) Received: from localhost.localdomain ([2620:10d:c090:400::5:9426]) by smtp.gmail.com with ESMTPSA id ep2-20020a17090ae64200b0029932d175c3sm62083pjb.0.2024.03.04.19.05.25 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Mon, 04 Mar 2024 19:05:27 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 387f0d39-da9d-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709607928; x=1710212728; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=o3Uab1G5GTmyRpRg7HZiDcHzBw+gqXSTLydz3NAXDjw=; b=gOkNgpyRPvmrFVicUrkuIln4lBYJbQrChPJV2rMhHk6+5E2BdXIlJ7gpJmncLE1WNX +u6zUkRay2M5rJzl++bzhJUcaHKz8I8CHToEvissErl5pclIO+Kl0/81xc7xT05skV5i OCU4Y6XcT0Y5zmBTRwdgKrmnQbJhmytHv+PoQhKpKEO76qdhom+ZPOl+kH+/4Bmdgh1O ymTlfdpHcPyu/J/zm77wrVjKKp4pXB5jJhSfLfq9JSsO0bUvTjbRLSTm2y/zYEyaIDOl pF7cL9bUTE/BI0zbmzEhHUoF9kUw8joIusV27Ynmq+8eI3zBvuki8fqfBEKrICznVBql Zt+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709607928; x=1710212728; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=o3Uab1G5GTmyRpRg7HZiDcHzBw+gqXSTLydz3NAXDjw=; b=N53SwW+Z1m3kwAt/YLKr9sjAZHoB861BUaKIIa7rWqM4uub4wYcrVTEYythAJ/WHM9 3UAXceIraU1BasqVY071dGv4loxrrYCaEInCDqNutct3EKqLUVisnIoX4TirmqgVrlWM 3aQOJ8MN7s4+gc9tTHzN2LFW9GPZ4my/P6gRztfC0OHILDyuofc8bPeK8KidgbW2SajJ VVlP671QCfz5patWuN73K5hUie9uz2bdbJ63ELK8VpNIbFIUdxy5hzmh1SXzzmkOm3Wi GWBGJvfHtlHSoWZc9xhhiVrFUz9arr1WCEKP+Q3sFvP2Ht63nbvo8m+UHXbwzfU9SRPV Gziw== X-Forwarded-Encrypted: i=1; AJvYcCVNSOXRbQAgHPmW4aNwFhhycuSgzl51tbX+Wlh/NmdZNhqMdcuhmRvIlJh06HS2PRWtzS6yDcrwu0GHPOAP0izoWYxDWF/cru3vUsUJ4ys= X-Gm-Message-State: AOJu0Ywemocp7ZpSQ22mEBvtf1UyX4sLzDrsU0saC3H1Au1j8EUkB9RG g1PWzEE8zMKFFdDwxvZl6tsQNOavkj53Nu6aAnbWhj0KY5xSMaWd X-Google-Smtp-Source: AGHT+IHbzyFXZDmwTFXKOBQzhI/J5ZF4BBhSMJWYsXowuh6pvkssrM9sK35Jd24futLM3qVbKmDLRw== X-Received: by 2002:a05:6a20:1da:b0:1a1:4d41:3570 with SMTP id 26-20020a056a2001da00b001a14d413570mr470241pzz.59.1709607927721; Mon, 04 Mar 2024 19:05:27 -0800 (PST) From: Alexei Starovoitov To: bpf@vger.kernel.org Cc: daniel@iogearbox.net, andrii@kernel.org, torvalds@linux-foundation.org, brho@google.com, hannes@cmpxchg.org, lstoakes@gmail.com, akpm@linux-foundation.org, urezki@gmail.com, hch@infradead.org, rppt@kernel.org, boris.ostrovsky@oracle.com, sstabellini@kernel.org, jgross@suse.com, linux-mm@kvack.org, xen-devel@lists.xenproject.org, kernel-team@fb.com Subject: [PATCH v4 bpf-next 2/2] mm: Introduce VM_SPARSE kind and vm_area_[un]map_pages(). Date: Mon, 4 Mar 2024 19:05:16 -0800 Message-Id: <20240305030516.41519-3-alexei.starovoitov@gmail.com> X-Mailer: git-send-email 2.39.3 (Apple Git-145) In-Reply-To: <20240305030516.41519-1-alexei.starovoitov@gmail.com> References: <20240305030516.41519-1-alexei.starovoitov@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Alexei Starovoitov vmap/vmalloc APIs are used to map a set of pages into contiguous kernel virtual space. get_vm_area() with appropriate flag is used to request an area of kernel address range. It's used for vmalloc, vmap, ioremap, xen use cases. - vmalloc use case dominates the usage. Such vm areas have VM_ALLOC flag. - the areas created by vmap() function should be tagged with VM_MAP. - ioremap areas are tagged with VM_IOREMAP. BPF would like to extend the vmap API to implement a lazily-populated sparse, yet contiguous kernel virtual space. Introduce VM_SPARSE flag and vm_area_map_pages(area, start_addr, count, pages) API to map a set of pages within a given area. It has the same sanity checks as vmap() does. It also checks that get_vm_area() was created with VM_SPARSE flag which identifies such areas in /proc/vmallocinfo and returns zero pages on read through /proc/kcore. The next commits will introduce bpf_arena which is a sparsely populated shared memory region between bpf program and user space process. It will map privately-managed pages into a sparse vm area with the following steps: // request virtual memory region during bpf prog verification area = get_vm_area(area_size, VM_SPARSE); // on demand vm_area_map_pages(area, kaddr, kend, pages); vm_area_unmap_pages(area, kaddr, kend); // after bpf program is detached and unloaded free_vm_area(area); Signed-off-by: Alexei Starovoitov --- include/linux/vmalloc.h | 5 ++++ mm/vmalloc.c | 59 +++++++++++++++++++++++++++++++++++++++-- 2 files changed, 62 insertions(+), 2 deletions(-) diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h index c720be70c8dd..0f72c85a377b 100644 --- a/include/linux/vmalloc.h +++ b/include/linux/vmalloc.h @@ -35,6 +35,7 @@ struct iov_iter; /* in uio.h */ #else #define VM_DEFER_KMEMLEAK 0 #endif +#define VM_SPARSE 0x00001000 /* sparse vm_area. not all pages are present. */ /* bits [20..32] reserved for arch specific ioremap internals */ @@ -232,6 +233,10 @@ static inline bool is_vm_area_hugepages(const void *addr) } #ifdef CONFIG_MMU +int vm_area_map_pages(struct vm_struct *area, unsigned long start, + unsigned long end, struct page **pages); +void vm_area_unmap_pages(struct vm_struct *area, unsigned long start, + unsigned long end); void vunmap_range(unsigned long addr, unsigned long end); static inline void set_vm_flush_reset_perms(void *addr) { diff --git a/mm/vmalloc.c b/mm/vmalloc.c index f42f98a127d5..e5b8c70950bc 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -648,6 +648,58 @@ static int vmap_pages_range(unsigned long addr, unsigned long end, return err; } +static int check_sparse_vm_area(struct vm_struct *area, unsigned long start, + unsigned long end) +{ + might_sleep(); + if (WARN_ON_ONCE(area->flags & VM_FLUSH_RESET_PERMS)) + return -EINVAL; + if (WARN_ON_ONCE(area->flags & VM_NO_GUARD)) + return -EINVAL; + if (WARN_ON_ONCE(!(area->flags & VM_SPARSE))) + return -EINVAL; + if ((end - start) >> PAGE_SHIFT > totalram_pages()) + return -E2BIG; + if (start < (unsigned long)area->addr || + (void *)end > area->addr + get_vm_area_size(area)) + return -ERANGE; + return 0; +} + +/** + * vm_area_map_pages - map pages inside given sparse vm_area + * @area: vm_area + * @start: start address inside vm_area + * @end: end address inside vm_area + * @pages: pages to map (always PAGE_SIZE pages) + */ +int vm_area_map_pages(struct vm_struct *area, unsigned long start, + unsigned long end, struct page **pages) +{ + int err; + + err = check_sparse_vm_area(area, start, end); + if (err) + return err; + + return vmap_pages_range(start, end, PAGE_KERNEL, pages, PAGE_SHIFT); +} + +/** + * vm_area_unmap_pages - unmap pages inside given sparse vm_area + * @area: vm_area + * @start: start address inside vm_area + * @end: end address inside vm_area + */ +void vm_area_unmap_pages(struct vm_struct *area, unsigned long start, + unsigned long end) +{ + if (check_sparse_vm_area(area, start, end)) + return; + + vunmap_range(start, end); +} + int is_vmalloc_or_module_addr(const void *x) { /* @@ -3822,9 +3874,9 @@ long vread_iter(struct iov_iter *iter, const char *addr, size_t count) if (flags & VMAP_RAM) copied = vmap_ram_vread_iter(iter, addr, n, flags); - else if (!(vm && (vm->flags & VM_IOREMAP))) + else if (!(vm && (vm->flags & (VM_IOREMAP | VM_SPARSE)))) copied = aligned_vread_iter(iter, addr, n); - else /* IOREMAP area is treated as memory hole */ + else /* IOREMAP | SPARSE area is treated as memory hole */ copied = zero_iter(iter, n); addr += copied; @@ -4415,6 +4467,9 @@ static int s_show(struct seq_file *m, void *p) if (v->flags & VM_IOREMAP) seq_puts(m, " ioremap"); + if (v->flags & VM_SPARSE) + seq_puts(m, " sparse"); + if (v->flags & VM_ALLOC) seq_puts(m, " vmalloc"); -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Mar 05 05:05:41 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 05:05:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688590.1072941 (Exim 4.92) (envelope-from ) id 1rhMzY-0007hT-JJ; Tue, 05 Mar 2024 05:05:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688590.1072941; Tue, 05 Mar 2024 05:05:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhMzY-0007hM-GH; Tue, 05 Mar 2024 05:05:28 +0000 Received: by outflank-mailman (input) for mailman id 688590; Tue, 05 Mar 2024 05:05:27 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhMzX-0007hC-8R; Tue, 05 Mar 2024 05:05:27 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhMzX-0001sC-4V; Tue, 05 Mar 2024 05:05:27 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhMzW-0002mU-Px; Tue, 05 Mar 2024 05:05:26 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rhMzW-0005Ek-PT; Tue, 05 Mar 2024 05:05:26 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=gfMFvGL5u7F+TQ0KlwF1zEE2PpNI8toVW1lQy0c3Wy8=; b=JF7H48Sp4uCJiH0loNVZbv4RLD JOoiVi1iOJoCnUU3pOAMc4qB+EbRFMWskXhJHDi57Cp+1oshNa6CoV297t0rnMD+SXaAra4xxIzv7 i+pQGJ8fcTYzxC+Ih/5aD+GYLWLh9g7LV+lgd8SC9b7dcHdJShQT+8xeX03TtDqR750s=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable test] 184905: tolerable FAIL - PUSHED X-Osstest-Failures: xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: xen=fc84b4a5a37b9250d87ef63983b48e1953bba6d1 X-Osstest-Versions-That: xen=efad36f1ba18946acecc030166b1a6bebeb88ea2 From: osstest service owner Date: Tue, 05 Mar 2024 05:05:26 +0000 flight 184905 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/184905/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail blocked in 184833 test-armhf-armhf-libvirt 16 saverestore-support-check fail like 184833 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop fail like 184833 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 184833 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop fail like 184833 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 184833 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 184833 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop fail like 184833 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 184833 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184833 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 184833 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop fail like 184833 test-amd64-amd64-libvirt-xsm 15 migrate-support-check fail never pass test-amd64-i386-xl-pvshim 14 guest-start fail never pass test-amd64-i386-libvirt 15 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-check fail never pass test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-check fail never pass test-arm64-arm64-xl 15 migrate-support-check fail never pass test-arm64-arm64-xl 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 15 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-check fail never pass test-armhf-armhf-libvirt 15 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-check fail never pass test-amd64-i386-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-check fail never pass test-arm64-arm64-xl-vhd 14 migrate-support-check fail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-check fail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-check fail never pass version targeted for testing: xen fc84b4a5a37b9250d87ef63983b48e1953bba6d1 baseline version: xen efad36f1ba18946acecc030166b1a6bebeb88ea2 Last test of basis 184833 2024-03-01 14:11:30 Z 3 days Failing since 184852 2024-03-02 16:36:22 Z 2 days 5 attempts Testing same since 184905 2024-03-04 19:41:29 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Bertrand Marquis Jan Beulich Julien Grall Nicola Vetrini Roger Pau Monné Stefano Stabellini jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-dom0pvh-xl-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-qemuu-freebsd11-amd64 pass test-amd64-amd64-qemuu-freebsd12-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-examine-bios pass test-amd64-i386-examine-bios pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-dom0pvh-xl-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-armhf-armhf-libvirt-qcow2 pass test-amd64-amd64-xl-qcow2 pass test-arm64-arm64-libvirt-raw pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-libvirt-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-examine-uefi pass test-amd64-i386-examine-uefi pass test-amd64-amd64-libvirt-vhd pass test-arm64-arm64-xl-vhd pass test-armhf-armhf-xl-vhd pass test-amd64-i386-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these 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 efad36f1ba..fc84b4a5a3 fc84b4a5a37b9250d87ef63983b48e1953bba6d1 -> master From xen-devel-bounces@lists.xenproject.org Tue Mar 05 06:50:50 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 06:50:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688595.1072950 (Exim 4.92) (envelope-from ) id 1rhOdG-00056c-08; Tue, 05 Mar 2024 06:50:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688595.1072950; Tue, 05 Mar 2024 06:50:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhOdF-00056V-Tg; Tue, 05 Mar 2024 06:50:33 +0000 Received: by outflank-mailman (input) for mailman id 688595; Tue, 05 Mar 2024 06:50:33 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhOdF-00056P-4w for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 06:50:33 +0000 Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [2a00:1450:4864:20::62d]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id a766c30c-dabc-11ee-a1ee-f123f15fe8a2; Tue, 05 Mar 2024 07:50:29 +0100 (CET) Received: by mail-ej1-x62d.google.com with SMTP id a640c23a62f3a-a458850dbddso124124566b.0 for ; Mon, 04 Mar 2024 22:50:29 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id bx16-20020a170906a1d000b00a4588098c5esm1000025ejb.132.2024.03.04.22.50.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Mar 2024 22:50:28 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a766c30c-dabc-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709621429; x=1710226229; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=w+Hc3NpL4EVdaoxSZAfYJmZIkH8tu05K+0x9uZCYy/M=; b=Xvp/FmD0+cWSW+iBwddeAaUmqJXoA4aZ9EaG1vSqz1LL4ZkncEH/ELE2VvyoF3EGY/ WgyymIvYKbvUsz4Y1Yn0nZytwiWrj9UJqYJxv6CcKd/zp9Gm6YT0cer7J033UT8OB1HZ BHMqSZ+jXVmsYnRo5tYxTSudtmyORFERdeAHNdL0xfP4JCcl/+o39koyXs0FijUfG22G OjB2im41+PASVv/BSda/x+Dt6H21IlWyDMurlLCh7xqoEhGs6a0RPSwCvRG1ll1wgHQ0 5TCOI9wW9I+8ZTZp2tED2nx5pgG2Z7vfe8NcEalKnPQFpmvayc78ScZQxrhd9Y6vAkox 2xUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709621429; x=1710226229; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=w+Hc3NpL4EVdaoxSZAfYJmZIkH8tu05K+0x9uZCYy/M=; b=GeA+cjgBdped2GJn7hUpjRUZn+C+EPBCKlPOtV/eLi2b30t+j/uDzPVkdKfhI6e2ya 2jQoFw9j3CqhQ7xsciOQVRUxVjI1MOB811vnUdfcAFPsOsw7I3g8sSsCo0ZkdUWHTnL4 2scgIpm8ZP8Rr9YaJah3f9gog3h98hPFwHQN3E8FrbBxi0CvgIYvbn5cQ/Qr9sKv8wyG 6A35Y+y2YLX9Js/72bAdBuJzHZaHH30FWqor9vUnmk+vQMOxgOpx3mnubkIfj3k51Tqh gaJW/IRYFFZAexRPFCK4eJCv6CMRlQSViaIApxmDeKMeKsuoAAM/7hp5HhlCA1uDpjnx s55A== X-Forwarded-Encrypted: i=1; AJvYcCXj3JJN+/2+msB6qgAudpSlv/Fqr/WRBe/ReFDSQXI1ltvaO29lZ9jRFipIWVoheV4CSbeY2hmJNZKMJ0ny2do1fh/crC3USV4KPGoKbA0= X-Gm-Message-State: AOJu0Yxax+3yHY7Shw+QAEp5TjADso+ouKcamEZ43CCREoJ7biUbht2u +Bs1KGqxi9nlmfAM4UpNjA82bAJ0cxqdcYKmGLaaHRbgvJGvmzz6cGMRgSDMeg== X-Google-Smtp-Source: AGHT+IE9sS21fKKsW3AcgGexRHRnIC4aVMegjqjAVS5JVm6OOYsKeZBQjfc4nV7eSlenSSxXOY9Row== X-Received: by 2002:a17:906:4a55:b0:a44:978b:534a with SMTP id a21-20020a1709064a5500b00a44978b534amr6892079ejv.64.1709621428803; Mon, 04 Mar 2024 22:50:28 -0800 (PST) Message-ID: Date: Tue, 5 Mar 2024 07:50:27 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/3] docs/misra/rules.rst: add rule 5.5 Content-Language: en-US To: Stefano Stabellini Cc: Federico Serafini , andrew.cooper3@citrix.com, george.dunlap@citrix.com, julien@xen.org, bertrand.marquis@arm.com, roger.pau@citrix.com, xen-devel@lists.xenproject.org, Stefano Stabellini , roberto.bagnara@bugseng.com References: <20240213223334.3693410-2-stefano.stabellini@amd.com> <50719397-b053-43e1-9cf7-cc9eae9098ed@suse.com> <40b7465f-4966-43c7-8db3-e28a6cc48445@bugseng.com> <2da73259-a86e-4a13-9fd4-4217372f4b76@suse.com> <3632611e-61ff-455a-9cc1-990a1f663d83@bugseng.com> <7747cb81-8fdb-4a5f-bfd1-c6c9bdb6039a@suse.com> <8e5d4c48-558d-40e2-851a-3eb6bfa5dbfe@suse.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 05.03.2024 02:49, Stefano Stabellini wrote: > On Mon, 4 Mar 2024, Jan Beulich wrote: >> On 04.03.2024 16:39, Federico Serafini wrote: >>> On 04/03/24 15:17, Jan Beulich wrote: >>>> On 04.03.2024 14:31, Federico Serafini wrote: >>>>> On 01/03/24 09:06, Jan Beulich wrote: >>>>>> On 01.03.2024 00:28, Stefano Stabellini wrote: >>>>>>> On Wed, 14 Feb 2024, Federico Serafini wrote: >>>>>>>> On 14/02/24 14:15, Jan Beulich wrote: >>>>>>>>> On 14.02.2024 12:27, Federico Serafini wrote: >>>>>>>>>> On 14/02/24 09:28, Jan Beulich wrote: >>>>>>>>>>> On 13.02.2024 23:33, Stefano Stabellini wrote: >>>>>>>>>>>> Signed-off-by: Stefano Stabellini >>>>>>>>>>>> --- >>>>>>>>>>>> docs/misra/rules.rst | 6 ++++++ >>>>>>>>>>>> 1 file changed, 6 insertions(+) >>>>>>>>>>>> >>>>>>>>>>>> diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst >>>>>>>>>>>> index c185366966..931158b354 100644 >>>>>>>>>>>> --- a/docs/misra/rules.rst >>>>>>>>>>>> +++ b/docs/misra/rules.rst >>>>>>>>>>>> @@ -181,6 +181,12 @@ maintainers if you want to suggest a change. >>>>>>>>>>>> headers (xen/include/public/) are allowed to retain longer >>>>>>>>>>>> identifiers for backward compatibility. >>>>>>>>>>>> + * - `Rule 5.5 >>>>>>>>>>>> `_ >>>>>>>>>>>> + - Required >>>>>>>>>>>> + - Identifiers shall be distinct from macro names >>>>>>>>>>>> + - Clashes between function-like macros and non-callable entities >>>>>>>>>>>> + are allowed. The pattern #define x x is also allowed. >>>>>>>>>>> >>>>>>>>>>> Just for me to know what exactly is covered (hence also a question >>>>>>>>>>> to Roberto as to [to be] implemented Eclair behavior): Even when >>>>>>>>>>> the above would be sufficient (and imo better) people frequently >>>>>>>>>>> write >>>>>>>>>>> >>>>>>>>>>> #define a(x, y) b(x, y) >>>>>>>>>>> >>>>>>>>>>> which, transformed to the specific case here, would then be >>>>>>>>>>> >>>>>>>>>>> #define a(x, y) a(x, y) >>>>>>>>>>> >>>>>>>>>>> I'd assume such ought to also be covered, but that's not clear >>>>>>>>>>> from the spelling above. >>>>>>>>>> >>>>>>>>>> I list what happens in some different situations, >>>>>>>>>> then we can find the right words for the documentation and/or >>>>>>>>>> refine the configuration: >>>>>>>>>> >>>>>>>>>> If you >>>>>>>>>> #define x x >>>>>>>>>> and then use `x' as identifier, >>>>>>>>>> the resulting violation is deviated (allowed pattern). >>>>>>>>>> >>>>>>>>>> If you >>>>>>>>>> #define a(x, y) a(x, y) >>>>>>>>>> and then use `a' as identifier for a non-callable entity, >>>>>>>>>> the resulting violation is deviated (no clash with non-callable >>>>>>>>>> entities). >>>>>>>>>> If you use identifier `a' for a callable entity, the resulting violation >>>>>>>>>> is reported: the allowed pattern covers only macros expanding to their >>>>>>>>>> own name, in this case the macro name is considered to be >>>>>>>>>> `a' only, not a(x, y). >>>>>>>>>> >>>>>>>>>> If you >>>>>>>>>> #define a(x, y) b(x, y) >>>>>>>>>> and then use `a' as identifier for a non-callable entity, >>>>>>>>>> the resulting violation is deviated (no clash with non-callable >>>>>>>>>> entities). >>>>>>>>> >>>>>>>>> I'm afraid I don't see what violation there is in this case, to >>>>>>>>> deviate. As a result I'm also not sure I correctly understand the >>>>>>>>> rest of your reply. >>>>>>>> >>>>>>>> #define a(x, y) b(x, y) >>>>>>>> >>>>>>>> int a; // Violation of Rule 5.5. >>>>>>>> >>>>>>>> The macro name `a' that exist before the preprocessing phase, >>>>>>>> still exists after the preprocessing phase as identifier for the integer >>>>>>>> variable and this is a violation. >>>>>>>> >>>>>>>>>> If you use `a' as identifier for a callable entity, >>>>>>>>>> this is not a violation because after the preprocessing phase, >>>>>>>>>> identifier `a' no longer exists. >>>>>>>> I correct myself: >>>>>>>> if you use `a' as identifier for a *function*, >>>>>>>> it is not a violation because after the preprocessing phase >>>>>>>> the identifier `a' no longer exists, for example: >>>>>>>> >>>>>>>> #define a(x, y) b(x, y) >>>>>>>> >>>>>>>> void a(int x, int y); // Ok. >>>>>>> >>>>>>> Federico, do you have a better wording suggestion for this rule? >>>>>>> >>>>>>> Jan, any further requests here? What would you like to see as next step? >>>>>> >>>>>> A more concise wording proposal would probably help. >>>>> >>>>> What do you think about: >>>>> >>>>> diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst >>>>> index 1e134ccebc..a975b9a85f 100644 >>>>> --- a/docs/misra/rules.rst >>>>> +++ b/docs/misra/rules.rst >>>>> @@ -181,6 +181,13 @@ maintainers if you want to suggest a change. >>>>> headers (xen/include/public/) are allowed to retain longer >>>>> identifiers for backward compatibility. >>>>> >>>>> + * - `Rule 5.5 >>>>> `_ >>>>> + - Required >>>>> + - Identifiers shall be distinct from macro names >>>>> + - Macros expanding to their own name are allowed (e.g., #define x x). >>>>> + Clashes between names of function-like macros and identifiers of >>>>> + non-callable entities are allowed. >>>> >>>> Imo that still leaves open e.g. the >>>> >>>> #define a(x, y) a(x, y) >>>> >>>> case: Permitted ("own name") or not permitted ("a" pretty clearly is expected >>>> to be a callable entity here, besides being a function-like macro)? >>> >>> I would not consider your example as a macro that expands to its own >>> name, the macro name is considered to be `a' only. >> >> That's what I was assuming, and hence my asking back. I think the >> above ought to be permitted just like "#define x x", and hence the >> suggested text would need expanding, to ... >> >>> Rather, you example can be used to trigger the "callable-noncallable" >>> part of the deviation, for example: >>> >>> #define a(x, y) a(x, y) >>> >>> void a(int x, int y); /* Not permitted (callable entity 'a'). */ >> >> ... prevent this ("not permitted") from happening. I'm pretty sure >> you've already found instances of this pattern in our code base. > > Sorry Jan, purely asking as a clarification because I couldn't > understand what you wrote. > > You are asking for a clarification in the wording so that the following > is explicitly allowed, right? > > #define a(x, y) a(x, y) > void a(int x, int y); Yes. (Or, less desirable, unambiguously disallowed.) Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 05 07:00:55 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 07:00:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688599.1072962 (Exim 4.92) (envelope-from ) id 1rhOnD-0006wG-1T; Tue, 05 Mar 2024 07:00:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688599.1072962; Tue, 05 Mar 2024 07:00:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhOnC-0006w9-Su; Tue, 05 Mar 2024 07:00:50 +0000 Received: by outflank-mailman (input) for mailman id 688599; Tue, 05 Mar 2024 07:00:49 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhOnB-0006w3-Re for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 07:00:49 +0000 Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [2a00:1450:4864:20::634]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 17c8d3cf-dabe-11ee-a1ee-f123f15fe8a2; Tue, 05 Mar 2024 08:00:47 +0100 (CET) Received: by mail-ej1-x634.google.com with SMTP id a640c23a62f3a-a44cdb2d3a6so389898666b.2 for ; Mon, 04 Mar 2024 23:00:47 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id s5-20020a170906c30500b00a4588e03238sm985393ejz.49.2024.03.04.23.00.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Mar 2024 23:00:46 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 17c8d3cf-dabe-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709622047; x=1710226847; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=Nf8icuCYBgULOWuEIBWVrfHWIQzMo8D1uULlQymypaM=; b=Knu9/eTiIUi1YTH7z+2PWla8SHejI/Zy/ih/Q1wEu+2Iblus95JxYEE6To1M7p3ibH qzD6qzgAMw+/DlxMEZAU6elC1CdaNCa70N6rmWve4c3c+Sae2WZUewN/QkHXwmjT7mWd U03yS8qd37RB1akCIxBqt+ulv/Bv5NMtCsQvmhlIAvYMxO7uaRZoDCTE5IltrW2BpUvi OWdvONkupSS9MwZGikZ6g96UK44on/bxIC3ZB20reoHvdson41GsvLmSmH94W0PVEZ9h gj33+vzun6Ahj50Kz1NCP0w37Muh0+QFUrjg7GxQowOsb87S+F6FJ+AwWe0MAWkV83OA BWhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709622047; x=1710226847; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Nf8icuCYBgULOWuEIBWVrfHWIQzMo8D1uULlQymypaM=; b=eUHn8OwpJpc91r5tzeEKk+3/hIC07DiA4m2KQ0HttH/PdJ7s0LIfZkbT0COyEQhba/ Cl6x2w5bKPU6pijpOFNsoxJqt3q1JgRw15Wcp/sOITvSeW0ypzJTDtGCok4GQHB9GHM8 AGc0aACiCqVytNsfgcBnuS1PiTEauUttI2jHvPhZJAn8HhIfGNYlFjIJ36oZ8eNe9MTV FD4XTeK9QwLs6wWpbs23peRrZ0qqq9XvokyjuOYcFGCAHB7OVDsahQgupzncTfUKvUNx 8Nn1yRyHPiQ0dANlwMWK7BvxfCpb56Gttp31pIP9WOqi9aIvoT2gtpwHcaWzI0uXsnnd Gfyg== X-Gm-Message-State: AOJu0Yz9O8lVTvEx5VjARPsnrH+EiGUE0S5FqClGPfGTBK4eM7zZc6Ie y08kiiIs935lH9HxZ8hm3700gVdfWeH99KUyqrF09RKB/cxcec57aPXs22tHtQ== X-Google-Smtp-Source: AGHT+IHNbaswhkAzSgaIDgzEk4PeKUxQopwW20xf6VqpHEP6RRYPpByRQtENyroBp7IgEBKXtDCuQQ== X-Received: by 2002:a17:906:8318:b0:a45:597e:7628 with SMTP id j24-20020a170906831800b00a45597e7628mr3221713ejx.41.1709622046842; Mon, 04 Mar 2024 23:00:46 -0800 (PST) Message-ID: Date: Tue, 5 Mar 2024 08:00:45 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH 10/10] xen/keyhandler: address violations of MISRA C Rule 20.7 Content-Language: en-US To: Stefano Stabellini Cc: xen-devel@lists.xenproject.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, consulting@bugseng.com, andrew.cooper3@citrix.com, roger.pau@citrix.com, bertrand.marquis@arm.com, julien@xen.org, George Dunlap , Wei Liu , Nicola Vetrini References: <2bc4a964f0f2f47488e72237678e944dbdbd7bb7.1709219010.git.nicola.vetrini@bugseng.com> <1afd8805-7365-40ec-8e8e-468a83e20c40@suse.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 05.03.2024 03:03, Stefano Stabellini wrote: > On Mon, 4 Mar 2024, Jan Beulich wrote: >> On 02.03.2024 02:37, Stefano Stabellini wrote: >>> On Fri, 1 Mar 2024, Jan Beulich wrote: >>>> On 29.02.2024 23:57, Stefano Stabellini wrote: >>>>> On Thu, 29 Feb 2024, Nicola Vetrini wrote: >>>>>> MISRA C Rule 20.7 states: "Expressions resulting from the expansion >>>>>> of macro parameters shall be enclosed in parentheses". Therefore, some >>>>>> macro definitions should gain additional parentheses to ensure that all >>>>>> current and future users will be safe with respect to expansions that >>>>>> can possibly alter the semantics of the passed-in macro parameter. >>>>>> >>>>>> No functional change. >>>>>> >>>>>> Signed-off-by: Nicola Vetrini >>>>> >>>>> Reviewed-by: Stefano Stabellini >>>> >>>> You did see the discussion on earlier patches, though? I don't think >>>> any of the parentheses here are needed or wanted. >>> >>> We need to align on this. Currently if we go by what's written in >>> docs/misra/deviations.rst, then rhs should have parentheses. >> >> Quoting the actual patch again: > > [...] > >> What rhs are you talking about in light of this change? The only rhs I >> can spot here is already parenthesized. > > Yes you are right. I replied here as an overall comment about our > approach to 20.7, although this patch is not a good example. My reply > was meant in the context of https://marc.info/?l=xen-devel&m=170928051025701 I'm still confused: The rhs is being parenthsized there. It's the _lhs_ which isn't and ... >>> Can we safely claim that rhs parentheses are never needed? If so, then >>> great, let's add it to deviations.rst and skip them here and other >>> places in this patch series (e.g. patch #8). When I say "never" I am >>> taking for granted that the caller is not doing something completely >>> unacceptably broken such as: >>> >>> WRITE_SYSREG64(var +, TTBR0_EL1) >> >> I'm afraid I can't associate this with the patch here either. Instead in >> the context here a (respective) construct as you mention above would simply >> fail to build. > > Fair enough it will break the build. I was trying to clarify that when I > wrote "the rhs parentheses are never needed" I meant "never" within > reason. One can always find ways to break the system and I tried to make > an example of something that for sure would break rhs or lhs without > parentheses. > > I meant to say, if we don't account for exceptionally broken cases, can > we safety say we don't need parentheses for rhs? ... doesn't need to, unless - as you say - one contrives examples. Yet to clarify here as well: I assume you mean "we don't need parentheses for lhs". And note that even if your example used the first parameter as lhs of an assignment, the build would still break. The + there would not magically combine with the = to a += operator. Tokenization occurs ahead of preprocessing, so the expanded macro would still have a + token followed by a = one. The only way to alter tokens is by using the ## operator. Which in turn precludes using parentheses. Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 05 07:11:11 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 07:11:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688602.1072971 (Exim 4.92) (envelope-from ) id 1rhOx4-0000JW-TB; Tue, 05 Mar 2024 07:11:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688602.1072971; Tue, 05 Mar 2024 07:11:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhOx4-0000JP-QJ; Tue, 05 Mar 2024 07:11:02 +0000 Received: by outflank-mailman (input) for mailman id 688602; Tue, 05 Mar 2024 07:11:01 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhOx3-0000JJ-Cm for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 07:11:01 +0000 Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [2a00:1450:4864:20::62f]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 844bdb62-dabf-11ee-a1ee-f123f15fe8a2; Tue, 05 Mar 2024 08:10:58 +0100 (CET) Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-a441d7c6125so32655266b.2 for ; Mon, 04 Mar 2024 23:10:58 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id v23-20020a1709067d9700b00a42ee62b634sm5654329ejo.106.2024.03.04.23.10.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Mar 2024 23:10:58 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 844bdb62-dabf-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709622658; x=1710227458; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=amVKZ/G30n/Yzg6bBgArHwLkCX61RuWSAll7jyvS1po=; b=K8j9lHM9KMNDA9hzZMdsQNuHwz0quIw5FLLnxzyyK/bFZ56ZNyerLuLM0hHUmMP5rY g/Ma96W2kZP027Ne63f2S5Ab5/nQRiphHA64ANOtxOz+U6n3Yvw2DXXCn7ul8Ss1SDHD SAaHquDQBaY3BXKzdh5ZBeGU0J6gT17iCmGoswH7xG/rA/7psSKahmNaL1YK02J+2el4 t34tqsoUZEHAd42Iwe85XgvsY9lp/jTlpTWERvRVzjpiv6y4eRL5VJ/8aRUKkFcHipR/ pZ8tf9gXQDKQ/gMsTD7W6+nn/deU7TsQECPO2sElqGY1F1Q5Gvz60H+ExAPrhzEqzhQ3 2OtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709622658; x=1710227458; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=amVKZ/G30n/Yzg6bBgArHwLkCX61RuWSAll7jyvS1po=; b=MN9cghqQ2Iq1rszpDzsYg7KDBiv5Cm2eBVbpEggHnJfaxoTKe56jiPpcZZL2knb49L b4RkldeLIKDc1An2qyOO5d1PwN6UBGSiAHarfqQOGivsRJhTXCXL8blMphziLsY/79Xg kXxnJTKkEp4ta805e6HJSA7px3cdWyYf6BnziYQPArKmF0jCeXTn4gzpCkKIVpQbEwlk K5scxp7ANQhleqgbDfxGuRIcXwmJEfI+P5bZwqBOeMzq/Ap/6OO6DS0mJjR7C6Fok2As 8uPyn0unoqoA+XddQVuzq9fcPK77Vdkoz/3ifEq1PglHI+QAQKyxPRtMcqrpn04jFimG vniw== X-Forwarded-Encrypted: i=1; AJvYcCWLWKb3fUm3xg9Mvup2wG5X3/VkupgNYNCKBc9P5yIQNvmvJjXKa+ycxdcctbMUiAbwRCY+5vXtpmNeoHdncL4kqlFvLkQsw4vIgBpM3uM= X-Gm-Message-State: AOJu0YwKI6q0nPVQas8tMvfdKLAKIgvT3XUvZ7Gur3a8OK0mut/M9bA2 Fs6Mb0fK5wT2jW2eHuyRoxLQvzwCMvNvlBE+h7IFWiF+Qr0DSUnIfVW8qGy/jA== X-Google-Smtp-Source: AGHT+IGaLa2uneYabfShH6mk4vIvYURxmB3fkkrVoOSaYBK87QIXSM8kzW/+a5e1MOYJZ5W+KrPHMQ== X-Received: by 2002:a17:906:2e92:b0:a45:6b65:f6cb with SMTP id o18-20020a1709062e9200b00a456b65f6cbmr2639599eji.26.1709622658427; Mon, 04 Mar 2024 23:10:58 -0800 (PST) Message-ID: <012234d3-3677-4a1e-8e0c-6e67f582c55c@suse.com> Date: Tue, 5 Mar 2024 08:10:57 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] xen/*/nospec: Provide common versions of evaluate_nospec/block_speculation Content-Language: en-US To: Julien Grall Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu , Stefano Stabellini , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel , Oleksii Kurochko , Shawn Anastasio , Xen-devel , Andrew Cooper References: <20240304161041.3465897-1-andrew.cooper3@citrix.com> <20240304161041.3465897-2-andrew.cooper3@citrix.com> <5c06c437-b62c-4bee-8694-1be597887718@xen.org> <141ed8a2-df4f-492c-a192-4ffa7f4c8384@suse.com> <4fb729fa-8519-4244-a795-cc66a79cd346@citrix.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 04.03.2024 18:40, Julien Grall wrote: > Hi Andrew, > > On 04/03/2024 17:07, Andrew Cooper wrote: >> On 04/03/2024 4:55 pm, Jan Beulich wrote: >>> On 04.03.2024 17:46, Julien Grall wrote: >>>> On 04/03/2024 16:41, Jan Beulich wrote: >>>>> On 04.03.2024 17:31, Julien Grall wrote: >>>>>> On 04/03/2024 16:10, Andrew Cooper wrote: >>>>>>> It is daft to require all architectures to provide empty implementations of >>>>>>> this functionality. >>>>>> Oleksii recenlty sent a similar patch [1]. This was pushed back because >>>>>> from naming, it sounds like the helpers ought to be non-empty on every >>>>>> architecture. >>>>>> >>>>>> It would be best if asm-generic provides a safe version of the helpers. >>>>>> So my preference is to not have this patch. This can of course change if >>>>>> I see an explanation why it is empty on Arm (I believe it should contain >>>>>> csdb) and other arch would want the same. >>>>> Except that there's no new asm-generic/ header here (as opposed to how >>>>> Oleksii had it). Imo avoiding the need for empty stubs is okay this way, >>>>> when introducing an asm-generic/ header would not have been. Of course >>>>> if Arm wants to put something there rather sooner than later, then >>>>> perhaps the functions better wouldn't be removed from there, just to then >>>>> be put back pretty soon. >>>> I am confused. I agree the patch is slightly different, but I thought >>>> the fundamental problem was the block_speculation() implementation may >>>> not be safe everywhere. And it was best to let each architecture decide >>>> how they want to implement (vs Xen decide for us the default). >>>> >>>> Reading the original thread, I thought you had agreed with that >>>> statement. Did I misinterpret? >>> Yes and no. Whatever is put in asm-generic/ ought to be correct and safe >>> by default, imo. The same doesn't apply to fallbacks put in place in >>> headers in xen/: If an arch doesn't provide its own implementation, it >>> indicates that the default (fallback) is good enough. Still I can easily >>> see that other views are possible here ... >> >> With speculation, there's absolutely nothing we can possibly do in any >> common code which will be safe generally. >> >> But we can make it less invasive until an architecture wants to >> implement the primitives. > > I understand the goal. However, I am unsure it is a good idea to provide > unsafe just to reduce the arch specific header by a few lines. My > concern is new ports may not realize that block_speculation() needs to > be implemented. This could end to a preventable XSA in the future. > > I guess the risk could be reduced if we had some documentation > explaining how to port Xen to a new architecture (I am not asking you to > write the doc). But that's precisely the difference I'm trying to point out between having a stub header in asm-generic/ vs having the fallback in xen/nospec.h: This way an arch still has to supply asm/nospec.h, and hence they can be expected to consider what needs putting there and what can be left to the fallbacks (whether just "for the time being" is a separate question). Whereas allowing to simply point at the asm-generic/ header is (imo) far more likely to have only little thought applied ("oh, there is that generic header, let's just use it"). Yet as said, the line between the two can certainly be viewed as blurred. Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 05 07:15:51 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 07:15:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688604.1072981 (Exim 4.92) (envelope-from ) id 1rhP1i-0000uv-Co; Tue, 05 Mar 2024 07:15:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688604.1072981; Tue, 05 Mar 2024 07:15:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhP1i-0000uo-A8; Tue, 05 Mar 2024 07:15:50 +0000 Received: by outflank-mailman (input) for mailman id 688604; Tue, 05 Mar 2024 07:15:49 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhP1h-0000ui-9U for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 07:15:49 +0000 Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [2a00:1450:4864:20::62e]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 3040cefe-dac0-11ee-a1ee-f123f15fe8a2; Tue, 05 Mar 2024 08:15:47 +0100 (CET) Received: by mail-ej1-x62e.google.com with SMTP id a640c23a62f3a-a450615d1c4so383120466b.0 for ; Mon, 04 Mar 2024 23:15:47 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id x23-20020a170906135700b00a3e4c47bad1sm5681042ejb.8.2024.03.04.23.15.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Mar 2024 23:15:46 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3040cefe-dac0-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709622947; x=1710227747; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=UrOIQqrlLnse7tBZRX2qhEt+nOD1UM1Foj/eyt7sbUc=; b=OlMa+VN2D5KMtvGeNsx+QJPS7QIPbCJs81+aOM9Cm8F9s11FJS1AOO0XxgbQ+ViVvO NijXkB6K9psiBBXH6HIlVkD9M2c9vox/DtxOJg+P5x1HtBUd2pHLZkc2mkur+x9JF/MK 5z1QeKxYi+vH8/SWGn+FYiqh2MnDa1GOwKNxZ/yC9jt7YchEFsOENDpZflSYSer4ZG5J uUrk8UoBXCIV9fsnkKncuQo5qpxfTWMAdMEkvSvHwN/ByqBPjr9CPYcYPduVrZysnRLz zzXcfsA+dvGMEN8dJZdATlusG3jA75UTRjHcTq3yImQAXM034K53/s/DCZuVJFd1dU28 YKcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709622947; x=1710227747; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=UrOIQqrlLnse7tBZRX2qhEt+nOD1UM1Foj/eyt7sbUc=; b=eyZWs0SxPpRCDliNo01202x1Kwtwm6qcqlpAMYKrIdPGm5KzrAXmmC9rPgbTRmAySE BqvWiANxMMbzXAAGjze1le0fhjYTRSs0qD5+z66lDlZ8njBwzJJhgv27bG/5kyvF0mBh EcZtcUCt/XKKBghZsQrCocXVxea1yKVaq3BwyR+LI3rISyhhkhZFUq9b6rKv+aRw2dTm LU7AzsOtkhKiv6kzDw+Y7ay/87A96Q1GpQ5gumlS27JKf/E920knKK8Y81Ot2QchiY3C YYo/LBA8ZWrm3meVOUlZKN5oCDmxP8xm/Y/nbrV37/G22ukBO5xYAsvRR3msclsKqEti j+Qg== X-Forwarded-Encrypted: i=1; AJvYcCWwvaE2i81YADUAs6aI+0DsPY9RIQLXhmzLOd5R+nP/CWIRiFLAeRX60SN3+ACGiKV7dDOnJwgEBI20AOQmSnXLF16NAKadtWcYCnLijSY= X-Gm-Message-State: AOJu0YyQir7p2iDjMiJPWZ6MHQKfaVclC6VBYbhsfaEElr8TxBJuVuMd jOoRRmvtDbJUHnZxnjHDtLoKvHoz4MmtiA3eSVJOAl9jhMWJM/Sm/1fF0tihkg== X-Google-Smtp-Source: AGHT+IGyRoTrXJSoEbCIRT/b8sMy5rgR/gsp2T9aaZ93KKvx0x956GDLkJ/l3B8U8Nu8874gzSv+3w== X-Received: by 2002:a17:906:7fd8:b0:a45:297d:52b9 with SMTP id r24-20020a1709067fd800b00a45297d52b9mr1758865ejs.26.1709622946935; Mon, 04 Mar 2024 23:15:46 -0800 (PST) Message-ID: <620ac7e0-b6ce-4ea4-be0e-ec97984eebec@suse.com> Date: Tue, 5 Mar 2024 08:15:45 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] xen/*/nospec: Provide common versions of evaluate_nospec/block_speculation Content-Language: en-US To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu , Stefano Stabellini , Julien Grall , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel , Oleksii Kurochko , Shawn Anastasio , Xen-devel References: <20240304161041.3465897-1-andrew.cooper3@citrix.com> <20240304161041.3465897-2-andrew.cooper3@citrix.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20240304161041.3465897-2-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 04.03.2024 17:10, Andrew Cooper wrote: > It is daft to require all architectures to provide empty implementations of > this functionality. > > Provide evaluate_nospec() and block_speculation() unconditionally in > xen/nospec.h with architectures able to opt in by providing suitable arch > variants. > > Rename x86's implementation to the arch_*() variants. > > No functional change. > > Signed-off-by: Andrew Cooper Upon further thinking and with Julien's recent reply in mind: Acked-by: Jan Beulich Still I'd prefer if the arch_* were left out. They look to me to go this half step too far (despite now having looked at patch 2 as well; I'll reply there separately). And it is this which was why I decided that going the other half step (moving these handful lines of code) wasn't really worth it, when considering whether to make such a patch myself. Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 05 07:31:05 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 07:31:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688608.1072990 (Exim 4.92) (envelope-from ) id 1rhPGL-000491-IG; Tue, 05 Mar 2024 07:30:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688608.1072990; Tue, 05 Mar 2024 07:30:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhPGL-00048u-Fn; Tue, 05 Mar 2024 07:30:57 +0000 Received: by outflank-mailman (input) for mailman id 688608; Tue, 05 Mar 2024 07:30:56 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhPGK-00048k-6p for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 07:30:56 +0000 Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [2a00:1450:4864:20::62d]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 4ca49e35-dac2-11ee-a1ee-f123f15fe8a2; Tue, 05 Mar 2024 08:30:54 +0100 (CET) Received: by mail-ej1-x62d.google.com with SMTP id a640c23a62f3a-a293f2280c7so920329366b.1 for ; Mon, 04 Mar 2024 23:30:54 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id bl9-20020a170906c24900b00a45ab830eabsm211109ejb.51.2024.03.04.23.30.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Mar 2024 23:30:53 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 4ca49e35-dac2-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709623853; x=1710228653; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=197nhNBsq4cL0hPa5PQ1jF0N/hg0vDGOjhUx7AFo1Kw=; b=AFmh7a3NurJNEc002bqxxBeWHii7GS7wRJqX7txOMp2Vtb3UDWUPbjdd4jzDIR4OsW d1S4JCtRZL6VnSNKDQEcBunUnvQUTHi2U6Pe+UXIbfzHYbq6pc7D3GHBuIM1Xvoj4PoC os1hjycbzy4w4wPMrDFVBnn0v05H5U7G2HHDzzHXNOjFLdOnqdp0Jb924d147BlY/fKH L/1OU1HfXoGEferyW9C5fVVB67IVYH6NGfnodyo9rYxilnlGjkP4EkrK8TPY5Dz/E2p5 vHP67sh/Qdy1ERWBk7bkwRvUueQ85dhg8FZzb28CvLO9KRq9ySdaEo2Isk9wzc6+8O/v O8cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709623853; x=1710228653; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=197nhNBsq4cL0hPa5PQ1jF0N/hg0vDGOjhUx7AFo1Kw=; b=YM6rgl8shGgHEZCIJt9Bung98+HOrJ6tMywweQESynZ1VA5/M9pdP38toCraRMwsXD CwU22RQcTWizxTcAGBQ9h47J/NtiQoPUakGFGoVn7BUdr8IDX22sRKT3tPnjMGwjYmZv /1/fuk67s8Xl2jj4HM43QjfPzCBXfl0jhATH13/uE5Rza4nQ93+ym0X2aJx+nu+S0+gX rAqRci7KMkCBFBCqaKk99hD9WUOkoOF4ZpsP6XmNsvK6WDVFBDH41PgWdqP0v5tC8K4h jkCq+P2zJH8yRn/0YxH2fyBwPRsaLBHx6xHLme3tYTRiEX50I8CRm0bHDnqV5Pxg471X zaIQ== X-Forwarded-Encrypted: i=1; AJvYcCXgVsk2O1Wmif69uBk60r9+u29pVQeF3RQ6Lj2YVblodQttBBXhxgQcadDxn6mnMM5Imfl87ZGdxlVP+9ePnl3XpDROgak0u8FoYmhgdZk= X-Gm-Message-State: AOJu0YzGMDF/UemZFyCOGJRFBVteftZMlU0o9mKcvehTp3Nb6mdrItfV XIHB/MbR28jNdZPIhgmZIGNi6t87ATLsYG6aPM88IWJO6/9akoy8R1/2dstGOQ== X-Google-Smtp-Source: AGHT+IHK07/o2D+rdv5MbwmWJzh09zrb52W0ObjEsxKg2Ei2EOT/81RT0hKDjgSKjkxWlfrY4uIfbQ== X-Received: by 2002:a17:906:fb89:b0:a45:8efe:7c0 with SMTP id lr9-20020a170906fb8900b00a458efe07c0mr1407884ejb.48.1709623853595; Mon, 04 Mar 2024 23:30:53 -0800 (PST) Message-ID: <3f46f0f9-e3be-483f-9f4b-41f9a5a087eb@suse.com> Date: Tue, 5 Mar 2024 08:30:52 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/2] xen/nospec: Allow evaluate_nospec() to short circuit constant expressions Content-Language: en-US To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu , Xen-devel References: <20240304161041.3465897-1-andrew.cooper3@citrix.com> <20240304161041.3465897-3-andrew.cooper3@citrix.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20240304161041.3465897-3-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 04.03.2024 17:10, Andrew Cooper wrote: > --- a/xen/include/xen/nospec.h > +++ b/xen/include/xen/nospec.h > @@ -18,6 +18,15 @@ static always_inline bool evaluate_nospec(bool cond) > #ifndef arch_evaluate_nospec > #define arch_evaluate_nospec(cond) cond > #endif > + > + /* > + * If the compiler can reduce the condition to a constant, then it won't > + * be emitting a conditional branch, and there's nothing needing > + * protecting. > + */ > + if ( __builtin_constant_p(cond) ) > + return cond; > + > return arch_evaluate_nospec(cond); > } While for now, even after having some hours for considering, I can't point out anything concrete that could potentially become a problem here, I still have the gut feeling that this would better be left in the arch logic. (There's the oddity of what the function actually expands to if the #define in context actually takes effect, but that's merely cosmetic.) The one thing I'm firmly unhappy with is "won't" in the comment: We can't know what the compiler will do. I've certainly known of compilers which didn't as you indicate here. That was nothing remotely recent, but ancient DOS/Windows ones. Still, unlike with e.g. __{get,put}_user_bad() the compiler doing something unexpected would go entirely silently here. The other (minor) aspect I'm not entirely happy with is that you insert between the fallback #define and its use. I think (if we need such a #define in the first place) the two would better stay close together. As to the need for the #define: To me static always_inline bool evaluate_nospec(bool cond) { #ifdef arch_evaluate_nospec return arch_evaluate_nospec(cond); #else return cond; #endif } or even static always_inline bool evaluate_nospec(bool cond) { #ifdef arch_evaluate_nospec return arch_evaluate_nospec(cond); #endif return cond; } reads no worse, but perhaps slightly better, and is then consistent with block_speculation(). At which point the question about "insertion point" here would hopefully also disappear, as this addition is meaningful only ahead of the #else. Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 05 07:34:24 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 07:34:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688611.1073000 (Exim 4.92) (envelope-from ) id 1rhPJf-0004mJ-3j; Tue, 05 Mar 2024 07:34:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688611.1073000; Tue, 05 Mar 2024 07:34:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhPJf-0004mC-1E; Tue, 05 Mar 2024 07:34:23 +0000 Received: by outflank-mailman (input) for mailman id 688611; Tue, 05 Mar 2024 07:34:22 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhPJe-0004m1-5e for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 07:34:22 +0000 Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [2a00:1450:4864:20::52e]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id c8214330-dac2-11ee-afda-a90da7624cb6; Tue, 05 Mar 2024 08:34:21 +0100 (CET) Received: by mail-ed1-x52e.google.com with SMTP id 4fb4d7f45d1cf-565c6cf4819so10634571a12.1 for ; Mon, 04 Mar 2024 23:34:21 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id d8-20020a50fe88000000b005673e29cc0fsm2351194edt.54.2024.03.04.23.34.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Mar 2024 23:34:20 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c8214330-dac2-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709624061; x=1710228861; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=YkXHRLwqQQen41Vh/I0b74Fe81BXlt/sJghwfIeKq5o=; b=CX5LwFWxSjYEBP3gAynKz4IK9IbalVr6oBXNgPcp/82aFUP/6hKqxIqhOCtVXEWJ76 r/klmUpsl3DSbBRTNWVzoRRw56YO4cjak6mnKkcocsKh1eFlteaBbDcy9yhVYkV1HGEC UYXuErtcaFFmzXXkDOtqRmr5ymleRmuel3jTgGIQXl7llmcjKmkGmR6guGmd/DLdN/mn GAiJ+8HqxNv1rHpp9mWv0Ey/BnoXR6qxNOMyPe2JZcAUMKbm7kc0XHNRpyd0TrsgRr33 3A5pWV9aFY26CPhs8Yo6C7ob97VqRZ1AM7Pts1Wjn5rUy8AN9mWfIhzp3wrJ/o0h2lcf tY7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709624061; x=1710228861; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=YkXHRLwqQQen41Vh/I0b74Fe81BXlt/sJghwfIeKq5o=; b=TOuV+2a362lgYYzVFUaDwwUXQ+swbHDa7wXkhYQSUo4ZAy+L0/xHbh7/ND4Sik9/43 pd1c8599c+bY1mcZnRA/DkFfOrvUmjWQ0EBHKKjvGAKyGA7qeMLgTsoPHHjW9/D3cFUi gFgAmorhi63yLXMajDbYvf7rzn34B5vdQuE/bvEG+n0cjvpiyB4SG6eSOgEDn8nYTTTv wZqO+eCVE1YwXJlQJxO2CGUaKt8HYmpc7KVXmuqwcBG6WGlkM6aZz+FMTkMQVdml0xSz UHUK6Yq5s7txbNOaoeuEXrsS60V/GfDL3tAulxW3LijIW7YDMcyBDlwYZTJe86Hy9mvh 90Xw== X-Forwarded-Encrypted: i=1; AJvYcCWnKn+rskCzUrBm3b2A0F4e9s1Cb8cgWB5gnaifFmfMZQ7J9QYcBU4epLwK08E9F0AUpKh/k3BD3eKUvxpLPn9mq8aNsmt4uyIXGdaGWuQ= X-Gm-Message-State: AOJu0Ywj6y9Nskbo1jWPUWChCnW1x7gpAWGJENXkRFosmtSSy6oLRnIh uEa82VocyCcpFAijfBxoMnPG66vklJhYr8Eu9dfOoPlDdrf6+jKADdVf0pgrNA== X-Google-Smtp-Source: AGHT+IGtJrkWOuhbmki2x0qWHxgbqKKmw1E4KTXBNI0U/UMOPzHkDv+Gh8psZ+DDlMt4xrZBzFdeYw== X-Received: by 2002:a05:6402:31f3:b0:567:dd5:7afc with SMTP id dy19-20020a05640231f300b005670dd57afcmr1902733edb.8.1709624060725; Mon, 04 Mar 2024 23:34:20 -0800 (PST) Message-ID: Date: Tue, 5 Mar 2024 08:34:19 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] xen/*/nospec: Provide common versions of evaluate_nospec/block_speculation Content-Language: en-US To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu , Stefano Stabellini , Julien Grall , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel , Oleksii Kurochko , Shawn Anastasio , Xen-devel References: <20240304161041.3465897-1-andrew.cooper3@citrix.com> <20240304161041.3465897-2-andrew.cooper3@citrix.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20240304161041.3465897-2-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 04.03.2024 17:10, Andrew Cooper wrote: > --- a/xen/include/xen/nospec.h > +++ b/xen/include/xen/nospec.h > @@ -9,6 +9,29 @@ > > #include > > +/* > + * Protect a conditional branch from bad speculation. Architectures *must* > + * provide arch_evaluate_nospec() for this to be effective. > + */ > +static always_inline bool evaluate_nospec(bool cond) > +{ > +#ifndef arch_evaluate_nospec > +#define arch_evaluate_nospec(cond) cond Hmm, noticed only while replying to patch 2: If the #define is to be kept (see my reply there) it needs to be one of #define arch_evaluate_nospec(cond) (cond) or #define arch_evaluate_nospec Or it ought to be #undef-ed after use (thus preventing use in a context where "cond" may expand to other than "cond"). Jan > +#endif > + return arch_evaluate_nospec(cond); > +} > + > +/* > + * Halt speculation unconditonally. Architectures *must* provide > + * arch_block_speculation() for this to be effective. > + */ > +static always_inline void block_speculation(void) > +{ > +#ifdef arch_block_speculation > + arch_block_speculation(); > +#endif > +} > + > /** > * array_index_mask_nospec() - generate a ~0 mask when index < size, 0 otherwise > * @index: array element index From xen-devel-bounces@lists.xenproject.org Tue Mar 05 07:42:35 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 07:42:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688615.1073010 (Exim 4.92) (envelope-from ) id 1rhPRU-0006hc-S5; Tue, 05 Mar 2024 07:42:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688615.1073010; Tue, 05 Mar 2024 07:42:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhPRU-0006hV-PT; Tue, 05 Mar 2024 07:42:28 +0000 Received: by outflank-mailman (input) for mailman id 688615; Tue, 05 Mar 2024 07:42:27 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhPRT-0006hP-Km for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 07:42:27 +0000 Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [2a00:1450:4864:20::62f]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id e9539508-dac3-11ee-afda-a90da7624cb6; Tue, 05 Mar 2024 08:42:26 +0100 (CET) Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-a26ed1e05c7so895426266b.2 for ; Mon, 04 Mar 2024 23:42:26 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id an19-20020a17090656d300b00a4536b32ae0sm2255250ejc.30.2024.03.04.23.42.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Mar 2024 23:42:25 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e9539508-dac3-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709624546; x=1710229346; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=84R8AbOmfPnYlMLkc9ZNhLmmH6gcT0zgebxRsg5WjfQ=; b=SrLk7TwJhz+fki3YlGSVhzwg/01kJkWDU2SpZPzSR0WmmNHXgbleoN44DKhJ2lVU1G tnE2gcK/3eWTxBYxbbdZMef6sHJJOhFH58nsLmxaE/MWXAPCUumbLv6NSOR70syisSWR eQJBnsZkIfA7OiJJP10dYd5Sdg3OoUX9Z0QH4it0QJEhIehGDeovya02qmqS/vLBVeuK Ct99aIZaNDhSC1096Kx6PEL3lNBnPt+0QWXt2FJAFbDkCPLwo6Wz0+HjNIsq7mQm32HF P8jpJa9U+lL33xHJ/myACaS10DTz6pd5Re8be/xqnqMrpBkdNPsFzBf3upefmvsA+pB6 3XjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709624546; x=1710229346; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=84R8AbOmfPnYlMLkc9ZNhLmmH6gcT0zgebxRsg5WjfQ=; b=IrDECCTa+H3Zemn40eRdSZk6kINumoxVgUUOtNGEHwZ23RCnlaf2vYMVa4aw81llvs 6BtEEjJkTgmqJbZUoWFwJR0nlUvwF2/xEjYwI+cnYXS37RkpUOUD1Nzxf4EgrvxmYZjM 8hOL1QVlBRKsg+SFO/+kxpLitXRGqMYlGI6H/UMhG2SHMDIUx7pmp3KNpoCiKu10z/8o zkkTR2EOJt38+E1XRbH/0CgtiMqNkZxvrZ52naikpz7sAsVXwU1SMrwTyWiVfDM7iABc efZf3NJ78tai1uNfXGulXsQoh/kqBO01zM/JAVsKr53iaCa77h/2GQdvJXcf78noYfAU TU8w== X-Forwarded-Encrypted: i=1; AJvYcCWRm5Le9Q75Mrx9sOaBj0U74+nn0MDnVvvZqN+dfqqkwXRSXwKffPSujo4W7vrofQgqYPp991YVb25itdnBE2rsMpMnVR7NEgdb9Hz1t6M= X-Gm-Message-State: AOJu0Yxj0v/YNtRh91JujpyXOy9bzZYHiUrHxAcwZRstjYBV1biwnlcG uKWJcWH2DyROr4MZ+nXf/CPkI+TqbYBbZirJIhZuEkAQ/3krOuYpKs5GSlV5sQ== X-Google-Smtp-Source: AGHT+IHklhmfFAaRjcsTHjyiZJriZU6JO3b03Q1Z9qAnBfXM6pafrtOwcSllgg3XAym2ERnUlk0Xfw== X-Received: by 2002:a17:906:b254:b0:a45:ad52:d501 with SMTP id ce20-20020a170906b25400b00a45ad52d501mr95476ejb.12.1709624546010; Mon, 04 Mar 2024 23:42:26 -0800 (PST) Message-ID: Date: Tue, 5 Mar 2024 08:42:24 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 10/23] xen/riscv: introduces acrquire, release and full barriers Content-Language: en-US To: Oleksii Kurochko Cc: Alistair Francis , Bob Eshleman , Connor Davis , Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu , xen-devel@lists.xenproject.org References: <85eb894608120a05eb616cea721d24e02212a5cc.1708962629.git.oleksii.kurochko@gmail.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <85eb894608120a05eb616cea721d24e02212a5cc.1708962629.git.oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 26.02.2024 18:38, Oleksii Kurochko wrote: > Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich albeit ... > --- /dev/null > +++ b/xen/arch/riscv/include/asm/fence.h > @@ -0,0 +1,9 @@ > +/* SPDX-License-Identifier: GPL-2.0-or-later */ > +#ifndef _ASM_RISCV_FENCE_H > +#define _ASM_RISCV_FENCE_H > + > +#define RISCV_ACQUIRE_BARRIER "\tfence r , rw\n" > +#define RISCV_RELEASE_BARRIER "\tfence rw, w\n" > +#define RISCV_FULL_BARRIER "\tfence rw, rw\n" ... I'm not really happy with the \t and \n that are put here. My take on this is that it is the responsibility of the use site to supply such as and when necessary. Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 05 08:05:25 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 08:05:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688624.1073020 (Exim 4.92) (envelope-from ) id 1rhPnU-0002N1-1a; Tue, 05 Mar 2024 08:05:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688624.1073020; Tue, 05 Mar 2024 08:05:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhPnT-0002Mu-Uh; Tue, 05 Mar 2024 08:05:11 +0000 Received: by outflank-mailman (input) for mailman id 688624; Tue, 05 Mar 2024 08:05:10 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhPnS-0002Mo-H8 for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 08:05:10 +0000 Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [2a00:1450:4864:20::636]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 1401aac2-dac7-11ee-a1ee-f123f15fe8a2; Tue, 05 Mar 2024 09:05:06 +0100 (CET) Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-a4499ef8b5aso383143966b.0 for ; Tue, 05 Mar 2024 00:05:06 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id pv25-20020a170907209900b00a3ee9305b02sm5717054ejb.20.2024.03.05.00.05.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 Mar 2024 00:05:06 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1401aac2-dac7-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709625906; x=1710230706; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=ZppC4XnuYv6vFg7B59V/gfQbC07jiAGXp641l7cWU7E=; b=L8Ztma2gjG2oqJwxqvhGXBKeq2aPnw/F6BMNFYL44ngFIruf7jWVQqauMobF78zTKO 6v188OHtRUcQEft3n91uE3/TA9bR8zDACtV9j0wliYSNvrUMAYE3JOGZoKnWKjtx7Hz/ b1z8ZNXpCQS1uwlhDOivdZmOld/CfIgg4dXl80AAUJhKE9mh1Ag5yInOMESGOF7yB6zQ JKEIb5D1iF8RKKjr2Ali/u7nn1RBtEOyTgbgYsJhVwu6is+wTQXUvs9CSjWxQomYdmAV PYLZ75T0wB7mgi4y1E/LYtikwDP/1LRr8G5Ztl8DRWwPmLrvo0q3aq4/Kxe8h0RUPc0a ujwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709625906; x=1710230706; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ZppC4XnuYv6vFg7B59V/gfQbC07jiAGXp641l7cWU7E=; b=vRKHHDkHsuIjEDf4NR2jHUwxpIdQ6GAilaPQV8DrHWbVfAwe9JmPe/9n86PLo1pDqK 7b6MwDpR6jhWs3nLraEY3jatO+Dw9p3InQCorQ0RjCK0PaJcMP+7FydGJhCH+feMSARj 4rk32S/v1IkVxZP9oiTaxo9OJ4mnZKJ4Q3USu8pBZTzbk6Nbd8tCg6CKBI8Xr4nbSMrM BxKumuoYrWdQjaQ7s7qFBYPrcAqa8bdrYvgDLx3SaxpXBL3lznE88iDVy24kkhtMxbhN /nWrR06657xylZWoZaBTx6+kFocFjGv3+HAelwF5usMrposIiOIQTIMzWmIHUR0G+pgH 7XYw== X-Forwarded-Encrypted: i=1; AJvYcCUuCTMGWw0855KHL1BSANbbBhpssJnViqiiVle3yoqtBJHQaH4U3XXtlv+n44CBZEsdWVGvf0dCoCZvnRigkVrK84mxFBAk6qVKSBNyD5E= X-Gm-Message-State: AOJu0Yypjw+VzDGlpVhBX3tuxXSMqwVG9aDACRoqHo3ueupgjox/qjlo dQ5ghkLDZ1Fay6a9nX4LhO9c1px1yjPLtIwySVxCcHmpijlgvGfvpFTiskLm6A== X-Google-Smtp-Source: AGHT+IFEqoW+Qa2czMVSnUt2/MnyfQBRNlJ37D7Km/QFaXOcEAClGka3Zab4bJVZJU5PgINg2AUHGw== X-Received: by 2002:a17:906:7f0e:b0:a44:b91e:315a with SMTP id d14-20020a1709067f0e00b00a44b91e315amr6953008ejr.68.1709625906322; Tue, 05 Mar 2024 00:05:06 -0800 (PST) Message-ID: Date: Tue, 5 Mar 2024 09:05:05 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 18/23] xen/riscv: add minimal stuff to processor.h to build full Xen Content-Language: en-US To: Oleksii Kurochko Cc: Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu , Alistair Francis , Bob Eshleman , Connor Davis , xen-devel@lists.xenproject.org References: <4e1ee99a9ad71015b5e8860d20b63337b526d0e9.1708962629.git.oleksii.kurochko@gmail.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <4e1ee99a9ad71015b5e8860d20b63337b526d0e9.1708962629.git.oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 26.02.2024 18:39, Oleksii Kurochko wrote: > --- /dev/null > +++ b/docs/misc/riscv/booting.txt > @@ -0,0 +1,8 @@ > +System requirements > +=================== > + > +The following extensions are expected to be supported by a system on which > +Xen is run: > +- Zihintpause: > + On a system that doesn't have this extension, cpu_relax() should be > + implemented properly. Otherwise, an illegal instruction exception will arise. This decision wants justifying in the (presently once again empty) description. Furthermore - will there really be an illegal instruction exception otherwise? Isn't it the nature of hints that they are NOPs if not serving their designated purpose? > --- a/xen/arch/riscv/arch.mk > +++ b/xen/arch/riscv/arch.mk > @@ -5,6 +5,12 @@ $(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS)) > > CFLAGS-$(CONFIG_RISCV_64) += -mabi=lp64 > > +ifeq ($(CONFIG_RISCV_64),y) > +has_zihintpause = $(call as-insn,$(CC) -mabi=lp64 -march=rv64i_zihintpause, "pause",_zihintpause,) > +else > +has_zihintpause = $(call as-insn,$(CC) -mabi=ilp32 -march=rv32i_zihintpause, "pause",_zihintpause,) > +endif Considering that down the road likely more such tests will want adding, I think this wants further abstracting for the rv32/rv64 difference (ideally in a way that wouldn't make future RV128 wrongly and silently take the RV32 branch). This would include eliminating the -mabi=lp64 redundancy with what's visible in context, perhaps by way of introducing a separate helper macro, e.g. riscv-abi-$(CONFIG_RISCV_32) := -mabi=ilp32 riscv-abi-$(CONFIG_RISCV_64) := -mabi=lp64 I further see nothing wrong with also using $(riscv-march-y) here. I.e. overall _zihintpause := $(call as-insn,$(CC) $(riscv-abi-y) $(riscv-march-y)_zihintpause,"pause",_zihintpause) (still with potential of abstracting further through another macro such that not every such construct would need to spell out the ABI and arch compiler options). Plus a macro named has_* imo can be expected to expand to y or n. I would suggest to simply drop the "has", thus ... > @@ -12,7 +18,7 @@ riscv-march-$(CONFIG_RISCV_ISA_C) := $(riscv-march-y)c > # into the upper half _or_ the lower half of the address space. > # -mcmodel=medlow would force Xen into the lower half. > > -CFLAGS += -march=$(riscv-march-y) -mstrict-align -mcmodel=medany > +CFLAGS += -march=$(riscv-march-y)$(has_zihintpause) -mstrict-align -mcmodel=medany ... also making the use site look > --- a/xen/arch/riscv/include/asm/processor.h > +++ b/xen/arch/riscv/include/asm/processor.h > @@ -12,6 +12,9 @@ > > #ifndef __ASSEMBLY__ > > +/* TODO: need to be implemeted */ > +#define smp_processor_id() 0 > + > /* On stack VCPU state */ > struct cpu_user_regs > { > @@ -53,6 +56,26 @@ struct cpu_user_regs > unsigned long pregs; > }; > > +/* TODO: need to implement */ > +#define cpu_to_core(cpu) (0) > +#define cpu_to_socket(cpu) (0) Nit: Like above in smp_processor_id() no need for parentheses here. > +static inline void cpu_relax(void) > +{ > +#ifdef __riscv_zihintpause > + /* > + * Reduce instruction retirement. > + * This assumes the PC changes. What is this 2nd sentence about? > + */ > + __asm__ __volatile__ ( "pause" ); > +#else > + /* Encoding of the pause instruction */ > + __asm__ __volatile__ ( ".insn 0x100000F" ); May I ask that you spell out the leading zero here, to make clear there aren't, by mistake, one to few zeroes in the middle? Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 05 08:17:48 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 08:17:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688629.1073030 (Exim 4.92) (envelope-from ) id 1rhPzc-0004NT-3I; Tue, 05 Mar 2024 08:17:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688629.1073030; Tue, 05 Mar 2024 08:17:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhPzc-0004NM-0M; Tue, 05 Mar 2024 08:17:44 +0000 Received: by outflank-mailman (input) for mailman id 688629; Tue, 05 Mar 2024 08:17:43 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhPzb-0004NG-7r for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 08:17:43 +0000 Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [2a00:1450:4864:20::52b]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id d55bf106-dac8-11ee-a1ee-f123f15fe8a2; Tue, 05 Mar 2024 09:17:40 +0100 (CET) Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-56781070f38so1039781a12.0 for ; Tue, 05 Mar 2024 00:17:40 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id gb18-20020a170907961200b00a3efa4e033asm5730798ejc.151.2024.03.05.00.17.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 Mar 2024 00:17:40 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d55bf106-dac8-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709626660; x=1710231460; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=YNryQ+UoJKj1Zusgw6se3JUnddbRrREPTLmiIxV9B9g=; b=QsqeZgloKeAR8ctLKgMDTWz61ZFUMciFuKeqi9WQR/Ot1xvPusbaiVZPzekPO1AEzg az92pC/a7fwCGcM/R/XUAAd/Ewu/qIu3YyaREKyUkeHk/LXaj/ZMrIyZ5hCnGFyiQXmF DUK9uOXZTHDO8KESXJi6OhG8Ep9klrLRTRaVjY9xRmB7PKrVIx3zpjesM/IHGwAy/H07 n1dFJazxVaYUODHM0nnPQyB1UT3E+5hKy7LxoHVs76456z+dgZkubchWpkXQxfCUxDiA oqjRMmAqc7PB3wkqPEVAxw3K0Q8cx5SgF09SHyYwyF/RWW6QlumA29yLCpV6gi2j/+ef PNfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709626660; x=1710231460; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=YNryQ+UoJKj1Zusgw6se3JUnddbRrREPTLmiIxV9B9g=; b=Cs3d5wevOOROMGqGYX64zuUfRPY7Hr54ugtBEwptjiAKK6BtvWRUyW0/ZAb3l+nixO vip8JotqddLvaXVHDl49QKJzfZ89yGRz/u/ETAXeKtcth4Hbbbhee/WcMlQZGVLjMFOQ GIkH2o87PqG5LRo5S5TZdQ/ZIWemI23vYbhQQ59YlpOOXdMZ3K5k9aho7M15x0nUEfQ3 xAQHNrgvSCU8D1O479roL0fllx35ZrvHFiqKccBu0ZCv9INL5ZnnSYtmbDswrhrmUqly Wsu5mOGGrEN55Yicx1P6DPK+x3fu3NZ/sRu0p1vW+erbS74LgDcNy7KBeVlgoJ54qVY0 Frsw== X-Forwarded-Encrypted: i=1; AJvYcCWYX62Sb23+jS6y7/DJp255eOzWiJja8h5bItKShgTP6lMzrmcowkrGD7mmsUgqyg5fSuyTL9FTl13x5CmSVZ4/97U0avSPU7P30olIVR4= X-Gm-Message-State: AOJu0YwmYlAFVD5jnvEublipcAECYQ5o1DTPKL6AKE4DfcprSf/+k6i0 Osv9CoK2+bgJ9yejoby2pEJi1o+G6NHPtfFPCZTwKQSWmWRAhGnZrEGtjXzEfA== X-Google-Smtp-Source: AGHT+IF5t1CvBUWCq5XU7aetCd4wlqf3kU7m26ojMg8foU4I8/EmP+h+TtHC4wlPqBSTpaWYSXCBvA== X-Received: by 2002:a17:906:ce30:b0:a43:f924:d63 with SMTP id sd16-20020a170906ce3000b00a43f9240d63mr1982673ejb.26.1709626660383; Tue, 05 Mar 2024 00:17:40 -0800 (PST) Message-ID: <1aef844e-4ea9-4651-bba7-9e665abb8892@suse.com> Date: Tue, 5 Mar 2024 09:17:39 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 19/23] xen/riscv: add minimal stuff to mm.h to build full Xen Content-Language: en-US To: Oleksii Kurochko Cc: Alistair Francis , Bob Eshleman , Connor Davis , Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu , xen-devel@lists.xenproject.org References: <7f5d859b4dbc0593447ade0b221ece17eda68d1e.1708962629.git.oleksii.kurochko@gmail.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <7f5d859b4dbc0593447ade0b221ece17eda68d1e.1708962629.git.oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 26.02.2024 18:39, Oleksii Kurochko wrote: > --- a/xen/arch/riscv/include/asm/mm.h > +++ b/xen/arch/riscv/include/asm/mm.h > @@ -3,11 +3,252 @@ > #ifndef _ASM_RISCV_MM_H > #define _ASM_RISCV_MM_H > > +#include > +#include > +#include > +#include > +#include > + > #include > > #define pfn_to_paddr(pfn) ((paddr_t)(pfn) << PAGE_SHIFT) > #define paddr_to_pfn(pa) ((unsigned long)((pa) >> PAGE_SHIFT)) > > +#define paddr_to_pdx(pa) mfn_to_pdx(maddr_to_mfn(pa)) > +#define gfn_to_gaddr(gfn) pfn_to_paddr(gfn_x(gfn)) > +#define gaddr_to_gfn(ga) _gfn(paddr_to_pfn(ga)) > +#define mfn_to_maddr(mfn) pfn_to_paddr(mfn_x(mfn)) > +#define maddr_to_mfn(ma) _mfn(paddr_to_pfn(ma)) > +#define vmap_to_mfn(va) maddr_to_mfn(virt_to_maddr((vaddr_t)va)) va needs parenthesizing here. Also why vaddr_t here but ... > +#define vmap_to_page(va) mfn_to_page(vmap_to_mfn(va)) > + > +static inline unsigned long __virt_to_maddr(unsigned long va) > +{ > + BUG_ON("unimplemented"); > + return 0; > +} > + > +static inline void *__maddr_to_virt(unsigned long ma) > +{ > + BUG_ON("unimplemented"); > + return NULL; > +} > + > +#define virt_to_maddr(va) __virt_to_maddr((unsigned long)(va)) > +#define maddr_to_virt(pa) __maddr_to_virt((unsigned long)(pa)) ... unsigned long here? In fact for __maddr_to_virt() I think there better wouldn't be any cast, such that the compiler can spot if, by mistake, a pointer type value was passed in. Or, wait, we can go yet further (also on x86): There are no uses of __maddr_to_virt() except here. Hence the symbol isn't needed (anymore?) in the first place. > +/* Convert between Xen-heap virtual addresses and machine frame numbers. */ > +#define __virt_to_mfn(va) mfn_x(maddr_to_mfn(virt_to_maddr(va))) > +#define __mfn_to_virt(mfn) maddr_to_virt(mfn_to_maddr(_mfn(mfn))) > + > +/* > + * We define non-underscored wrappers for above conversion functions. > + * These are overriden in various source files while underscored version > + * remain intact. > + */ > +#define virt_to_mfn(va) __virt_to_mfn(va) > +#define mfn_to_virt(mfn) __mfn_to_virt(mfn) > + > +struct page_info > +{ > + /* Each frame can be threaded onto a doubly-linked list. */ > + struct page_list_entry list; > + > + /* Reference count and various PGC_xxx flags and fields. */ > + unsigned long count_info; > + > + /* Context-dependent fields follow... */ > + union { > + /* Page is in use: ((count_info & PGC_count_mask) != 0). */ > + struct { > + /* Type reference count and various PGT_xxx flags and fields. */ > + unsigned long type_info; > + } inuse; Blank line here please. Jan > + /* Page is on a free list: ((count_info & PGC_count_mask) == 0). */ > + union { > + struct { > + /* > + * Index of the first *possibly* unscrubbed page in the buddy. > + * One more bit than maximum possible order to accommodate > + * INVALID_DIRTY_IDX. > + */ > +#define INVALID_DIRTY_IDX ((1UL << (MAX_ORDER + 1)) - 1) > + unsigned long first_dirty:MAX_ORDER + 1; > + > + /* Do TLBs need flushing for safety before next page use? */ > + bool need_tlbflush:1; > + > +#define BUDDY_NOT_SCRUBBING 0 > +#define BUDDY_SCRUBBING 1 > +#define BUDDY_SCRUB_ABORT 2 > + unsigned long scrub_state:2; > + }; > + > + unsigned long val; > + } free; > + } u; > + > + union { > + /* Page is in use */ > + struct { > + /* Owner of this page (NULL if page is anonymous). */ > + struct domain *domain; > + } inuse; > + > + /* Page is on a free list. */ > + struct { > + /* Order-size of the free chunk this page is the head of. */ > + unsigned int order; > + } free; > + } v; > + > + union { > + /* > + * Timestamp from 'TLB clock', used to avoid extra safety flushes. > + * Only valid for: a) free pages, and b) pages with zero type count > + */ > + uint32_t tlbflush_timestamp; > + }; > +}; From xen-devel-bounces@lists.xenproject.org Tue Mar 05 08:33:35 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 08:33:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688633.1073040 (Exim 4.92) (envelope-from ) id 1rhQEs-0007tI-Da; Tue, 05 Mar 2024 08:33:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688633.1073040; Tue, 05 Mar 2024 08:33:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhQEs-0007tB-Au; Tue, 05 Mar 2024 08:33:30 +0000 Received: by outflank-mailman (input) for mailman id 688633; Tue, 05 Mar 2024 08:33:29 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhQEr-0007t5-8f for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 08:33:29 +0000 Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [2a00:1450:4864:20::629]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 0999745b-dacb-11ee-a1ee-f123f15fe8a2; Tue, 05 Mar 2024 09:33:27 +0100 (CET) Received: by mail-ej1-x629.google.com with SMTP id a640c23a62f3a-a44665605f3so568422666b.2 for ; Tue, 05 Mar 2024 00:33:27 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id pv18-20020a170907209200b00a44b90abb1dsm4127990ejb.110.2024.03.05.00.33.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 Mar 2024 00:33:26 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 0999745b-dacb-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709627606; x=1710232406; darn=lists.xenproject.org; h=content-transfer-encoding:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to; bh=LFMuQQVXEvQBi3w+KoeuqJ85gaYdYCISc5BsefqpMV0=; b=glhpi/giOepF8vsorulnU4whUim0j3PdRoPeAwjx7pb/awESflvDZ9OgxFjd2IbgN8 yd1VQTw4JJtDCyJUM+BLMyD2KFHrIQZWTc7Jp5i8rK8YuB3oTY2fvIMVWuRWQpNkGi0Z sWleqEBxFFaGIXL5+pkskv6YgJuxeE1nnUSLB0N7r5V/idiQ6mDAqK2Rq87LGfqPH7fF IsqfzFX77fF9a5Yg8dGkZG49T0bxLhlXiXz0c2ZEQO8MSXVyR8q7uUjzcp4dmlVpQirL drSwqQWiWx1TjiBD4mqWhBsnjOBJMImy9x73Dh4W9NAXNhrM39ftE3Qfp3XLww91q2WV 2YcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709627606; x=1710232406; h=content-transfer-encoding:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=LFMuQQVXEvQBi3w+KoeuqJ85gaYdYCISc5BsefqpMV0=; b=CQ+p8hETX/89MIxpbtEsS5/6GXOSuUNyi/GcSIM5lFuaNfIKLu8oh7bnCt6OV8YZN0 V9iM7Y9+BaMMxWjvQyTHguPrTMz/u908nKIjkwEDECQ53lBhxwT6gqOLNE/tTXnE+aUT 2gXn3nMKHOWd5sVx7eeEPLjFhij4mePf47rcRkLXfAwIRVs0cBh0wEv7P2P+AU/p2ItB KuU0XYZnDDYlJY6Of9DYaPwRVMXXWt43CuCC5GtUOeVIHRh3etYyElrRqwovZbtUjYLW 2SCdfFcyTxeD2fFkm2LFK77YOpsdywRwHybob0tr+DXnPpiq/0NYOFbK+mD+doZCatZ3 R0uQ== X-Gm-Message-State: AOJu0YzdujA391P6LURaxT95RFhuCSuOI+FjRXSStz0JN9MMgE8p1i3u 6ay1gG+x0PduZE3DuVvixKo4eEB7WafMQXGqnbY90Cd1eadjXLRfkqbd+Le5ItK+R/FlT1uoNMw = X-Google-Smtp-Source: AGHT+IHnBmNRf2j8z8HETjjGST44SUuYFu7KBmeSlr/pK0WP+xzztrNwkiGQW+XISuqbnHAjMeGx4w== X-Received: by 2002:a17:906:1356:b0:a45:d6f:2c63 with SMTP id x22-20020a170906135600b00a450d6f2c63mr4323815ejb.22.1709627606438; Tue, 05 Mar 2024 00:33:26 -0800 (PST) Message-ID: Date: Tue, 5 Mar 2024 09:33:25 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Julien Grall , Stefano Stabellini , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel , Oleksii Kurochko From: Jan Beulich Subject: [PATCH] x86+Arm: drop (rename) __virt_to_maddr() / __maddr_to_virt() Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit There's no use of them anymore except in the definitions of the non- underscore-prefixed aliases. Rename the inline functions, adjust the virt_to_maddr() #define-e, and purge the (x86-only) maddr_to_virt() one, thus eliminating a bogus cast which would have allowed the passing of a pointer type variable into maddr_to_virt() to go silently. Signed-off-by: Jan Beulich --- a/xen/arch/arm/include/asm/mm.h +++ b/xen/arch/arm/include/asm/mm.h @@ -256,12 +256,12 @@ static inline void __iomem *ioremap_wc(p /* Page-align address and convert to frame number format */ #define paddr_to_pfn_aligned(paddr) paddr_to_pfn(PAGE_ALIGN(paddr)) -static inline paddr_t __virt_to_maddr(vaddr_t va) +static inline paddr_t virt_to_maddr(vaddr_t va) { uint64_t par = va_to_par(va); return (par & PADDR_MASK & PAGE_MASK) | (va & ~PAGE_MASK); } -#define virt_to_maddr(va) __virt_to_maddr((vaddr_t)(va)) +#define virt_to_maddr(va) virt_to_maddr((vaddr_t)(va)) #ifdef CONFIG_ARM_32 /** --- a/xen/arch/x86/hvm/nestedhvm.c +++ b/xen/arch/x86/hvm/nestedhvm.c @@ -125,7 +125,7 @@ static int __init cf_check nestedhvm_set /* shadow_io_bitmaps can't be declared static because * they must fulfill hw requirements (page aligned section) * and doing so triggers the ASSERT(va >= XEN_VIRT_START) - * in __virt_to_maddr() + * in virt_to_maddr() * * So as a compromise pre-allocate them when xen boots. * This function must be called from within start_xen() when --- a/xen/arch/x86/include/asm/page.h +++ b/xen/arch/x86/include/asm/page.h @@ -269,8 +269,6 @@ void scrub_page_cold(void *); #define mfn_valid(mfn) __mfn_valid(mfn_x(mfn)) #define virt_to_mfn(va) __virt_to_mfn(va) #define mfn_to_virt(mfn) __mfn_to_virt(mfn) -#define virt_to_maddr(va) __virt_to_maddr((unsigned long)(va)) -#define maddr_to_virt(ma) __maddr_to_virt((unsigned long)(ma)) #define maddr_to_page(ma) __maddr_to_page(ma) #define page_to_maddr(pg) __page_to_maddr(pg) #define virt_to_page(va) __virt_to_page(va) --- a/xen/arch/x86/include/asm/x86_64/page.h +++ b/xen/arch/x86/include/asm/x86_64/page.h @@ -34,7 +34,7 @@ static inline unsigned long canonicalise #define pdx_to_virt(pdx) ((void *)(DIRECTMAP_VIRT_START + \ ((unsigned long)(pdx) << PAGE_SHIFT))) -static inline unsigned long __virt_to_maddr(unsigned long va) +static inline unsigned long virt_to_maddr(unsigned long va) { ASSERT(va < DIRECTMAP_VIRT_END); if ( va >= DIRECTMAP_VIRT_START ) @@ -47,8 +47,9 @@ static inline unsigned long __virt_to_ma return xen_phys_start + va - XEN_VIRT_START; } +#define virt_to_maddr(va) virt_to_maddr((unsigned long)(va)) -static inline void *__maddr_to_virt(unsigned long ma) +static inline void *maddr_to_virt(unsigned long ma) { /* Offset in the direct map, accounting for pdx compression */ unsigned long va_offset = maddr_to_directmapoff(ma); From xen-devel-bounces@lists.xenproject.org Tue Mar 05 08:40:24 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 08:40:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688637.1073050 (Exim 4.92) (envelope-from ) id 1rhQLT-00012m-1P; Tue, 05 Mar 2024 08:40:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688637.1073050; Tue, 05 Mar 2024 08:40:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhQLS-00012f-V9; Tue, 05 Mar 2024 08:40:18 +0000 Received: by outflank-mailman (input) for mailman id 688637; Tue, 05 Mar 2024 08:40:17 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhQLR-00012Y-HK for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 08:40:17 +0000 Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [2a00:1450:4864:20::52f]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id fd8b3322-dacb-11ee-afda-a90da7624cb6; Tue, 05 Mar 2024 09:40:16 +0100 (CET) Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-563d56ee65cso8108742a12.2 for ; Tue, 05 Mar 2024 00:40:16 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id v26-20020a50d59a000000b005643b41d128sm5822889edi.5.2024.03.05.00.40.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 Mar 2024 00:40:15 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fd8b3322-dacb-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709628016; x=1710232816; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=0ejqUOUk/3JLkFeTD5DwuFEiDWuc0toJwJKikq6OjC4=; b=LjywWm4V358VgGcRI/NF4wyt0Yoq9kZbUgmeMSOM4ifrRgs/1CaZoprHdULpO5f7c4 siWYcAvdhcQUbjev06Rcl7clf1eRWKT8Ruh7ZlaRqepu1j4cxzNeEc0VSMaOHX0Hx747 +/jUTtXWnAFQCWYnVn9VD2/6M4XkKSn4HEAL+lmhxAus/DoVmpp274Mlpu9d3Rthqgiy S4UtLkvy4784WYa/fJCC+v+h2ybo36BM/KpQQUi4uv2bvXf1BDLMYR2U9vbgb4TnIWAE L6lozOZzzybShAa4HO0f9CdCUAKARaxgCOzV2PUaRJNxeXI6JNWbTuhthuQ55cWXYZbp kdWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709628016; x=1710232816; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=0ejqUOUk/3JLkFeTD5DwuFEiDWuc0toJwJKikq6OjC4=; b=m3DsQuNtfK/qeHu5411d51Selxx4SCOCycmeBp1fbeRDO/eklF/y7uCFT7nAO6nSKm AELvepo7li5E5dYFv9n8vDRPAKroXKNYle+arKyr3tQQPI7FiI1rOe/TMfo6mDCMtkMS 5zQQZLFuuS9lySPz/29sSxL92LByhwsH5Q88dJjphKMyP2TdSmZ5PlqEcdHtjue5GvnJ uXO570rrehrzyrTUtmftL7sHKF5T39XzoknaZtLJGLik9HV9UKx2GlUwdf89JXmY+RFd UwuKrwMy57qkfMpPiC343f6rW1y8FjKqCd4pC8eejMYlD6SWSGCNq59e4NWut/325jW9 w/hw== X-Forwarded-Encrypted: i=1; AJvYcCUr8Gzw8svopU2YslFCc4/cBbgYQFbmoGmiMe62ZWSm6UvLcfZ+bLZCy/Jr0mJMRi2Fo8sCuG9Su3DxFqJvz9VaNTEpvBxGgCzZkAw8zu4= X-Gm-Message-State: AOJu0YwpbRBwPc/UCpZMY4fkKndN/wnr0vtvNYFtugi4xvUya0bkPhn6 GDRAwgCEJdaO+e0Ak3jx1JqkI38xKGRRAjfNBPuPoaZOPaI1ErvPydXxU758kQ== X-Google-Smtp-Source: AGHT+IFe3hNnqjs4jzNlQeyzczaXw+nkSDqdR7ECeEYFMbEBvkl2E/fSxpdjCd9+Ajmin0+WAJo4Vw== X-Received: by 2002:a05:6402:3584:b0:566:f66d:f3c6 with SMTP id y4-20020a056402358400b00566f66df3c6mr8592834edc.21.1709628015842; Tue, 05 Mar 2024 00:40:15 -0800 (PST) Message-ID: <9d950095-5400-4e1a-aea6-f450fa700ca3@suse.com> Date: Tue, 5 Mar 2024 09:40:13 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 21/23] xen/rirscv: add minimal amount of stubs to build full Xen To: Oleksii Kurochko Cc: Alistair Francis , Bob Eshleman , Connor Davis , Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu , xen-devel@lists.xenproject.org References: Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 26.02.2024 18:39, Oleksii Kurochko wrote: > Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich with one remark: > +/* > + * The following functions are defined in common/irq.c, which will be built in > + * the next commit, so these changes will be removed there. > + */ > + > +void cf_check irq_actor_none(struct irq_desc *desc) > +{ > + BUG_ON("unimplemented"); > +} > + > +unsigned int cf_check irq_startup_none(struct irq_desc *desc) > +{ > + BUG_ON("unimplemented"); > + > + return 0; > +} Neither patch descriptions nor comments should mention "the next commit" or anything alike. You want to describe things without making assumptions that two successively submitted patches are also committed in direct succession. Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 05 08:43:46 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 08:43:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688640.1073061 (Exim 4.92) (envelope-from ) id 1rhQOm-0001dW-Gf; Tue, 05 Mar 2024 08:43:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688640.1073061; Tue, 05 Mar 2024 08:43:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhQOm-0001dP-DE; Tue, 05 Mar 2024 08:43:44 +0000 Received: by outflank-mailman (input) for mailman id 688640; Tue, 05 Mar 2024 08:43:42 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhQOk-0001dH-Kx for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 08:43:42 +0000 Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [2a00:1450:4864:20::52f]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 772bcc98-dacc-11ee-a1ee-f123f15fe8a2; Tue, 05 Mar 2024 09:43:40 +0100 (CET) Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-563b7b3e3ecso8163161a12.0 for ; Tue, 05 Mar 2024 00:43:40 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ub13-20020a170907c80d00b00a4406929637sm5800778ejc.162.2024.03.05.00.43.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 Mar 2024 00:43:39 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 772bcc98-dacc-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709628220; x=1710233020; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=XsR044gu6WxyyYX1A5oId0NOLbDDnjjOM33+Bu/P7WI=; b=AbTQAHUpEoOldnNICdy70wz8BP32yXE5T3fXNkuCiAQdW8SFGhw9mos3zEZwWClcLQ O9LZnMbvy8RPfU95j0sO4jbUlIKPYiGStkkzfcMYEM6z/15CukbYMIYn8AWDsRFu11HA CuWrX/fonb4O/HBVOGTOYBPnPNZOFjdXA9cQPDJYhGQYY1ovxYfRjvXbBEos6faSpwzq XMa6AW+bYZPETrZYm9ngKa/lZrakyS0xOiJv4Rz6ZzwEDfKZAUnFUMIG2/bSc9PTZqAg kzcZhhGwNCQ/xI/7QU8du31dW3qw4SjKR6oppw3ueAxnrs1M7do+fVOx+XxX+xmfnTsn x3/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709628220; x=1710233020; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=XsR044gu6WxyyYX1A5oId0NOLbDDnjjOM33+Bu/P7WI=; b=Jaf9lYNhTpG+AeTw6K69iR4n/YHyvh81Kjg4Rc7Acis9zTcmjiNw15O7o1aigqNLaA CDpAXF4WjEOMOAhNVqsJDGIeE/85RwWTU55OS+EYP/vWK7m5Wwa4U3Dso+Kr5yTb8NeO K20MEJf3Lq/Ra/RttzS0IbP06XjrH1GVxIsKIKtW/F9SuIgUmfA+e2hGZDqck/vAW6/G S3mtAji8ogMFE5jfuMmmXw9fcvNAIN8cP87YLGqjMZtS6tGpGQl0nuC4UEm52KZiIgG5 kvEtmaGjMuRwHT2sEJv+3cqlGgRx6o4ggaQ5ZqtPFTgPgNeWGzpuLNB+Bd2RrQD3AyEk IJag== X-Forwarded-Encrypted: i=1; AJvYcCU2x9yzzq+GQc6gDYrJj8YqzDstaBTp4NJCZZZSEUU+MW+5MbuXS5oLDgKTNNiDFwjHcwSLz8+NWz1n0NDgKpNnKqZql7rp4mC9H7IzaF4= X-Gm-Message-State: AOJu0YzmAFUsJED2kymHxAYyItRLgzqmCsVJ1nlzDy54bfQp3TFUMTlb FI5oG3MrtCCsuxOQWd4ygU9fyrfb69fb0oKewa38FZdiOf6SCTQ15bNGyJI3+g== X-Google-Smtp-Source: AGHT+IFoy80EhLw4OlCM+DVFYjSQDFY0EM80FCPU0qNRg5StQdv7mFvZQkCj4W/gUtZo8H7oJf3AWg== X-Received: by 2002:a17:906:e96:b0:a3f:3470:6055 with SMTP id p22-20020a1709060e9600b00a3f34706055mr6580698ejf.37.1709628219752; Tue, 05 Mar 2024 00:43:39 -0800 (PST) Message-ID: <1fe3924d-e57a-4259-b71c-f2164bd5fead@suse.com> Date: Tue, 5 Mar 2024 09:43:38 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/3] x86: i387.c cleanup Content-Language: en-US To: Fouad Hilly Cc: Wei Liu , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu , Xen-devel References: <20240304091307.2295344-1-fouad.hilly@cloud.com> <20240304091307.2295344-2-fouad.hilly@cloud.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20240304091307.2295344-2-fouad.hilly@cloud.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 04.03.2024 10:13, Fouad Hilly wrote: > From: Wei Liu > > No functional change I don't think that's what's relevant to mention here. Saying that it's trailing blanks and spelling which are taken care of would have clarified what's to expect before even looking at the changes. I may decide to take the liberty of adding a sentence to this effect while committing ... > Signed-off-by: Wei Liu > Signed-off-by: Fouad Hilly Acked-by: Jan Beulich Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 05 09:06:36 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 09:06:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688645.1073073 (Exim 4.92) (envelope-from ) id 1rhQki-0005Lv-3r; Tue, 05 Mar 2024 09:06:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688645.1073073; Tue, 05 Mar 2024 09:06:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhQki-0005Lo-1F; Tue, 05 Mar 2024 09:06:24 +0000 Received: by outflank-mailman (input) for mailman id 688645; Tue, 05 Mar 2024 09:06:22 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhQkg-0005Lg-Kp for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 09:06:22 +0000 Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [2a00:1450:4864:20::52e]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id a114a4ce-dacf-11ee-a1ee-f123f15fe8a2; Tue, 05 Mar 2024 10:06:19 +0100 (CET) Received: by mail-ed1-x52e.google.com with SMTP id 4fb4d7f45d1cf-564fd9eea75so531120a12.3 for ; Tue, 05 Mar 2024 01:06:19 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id o7-20020a1709062e8700b00a4558314ea0sm1934513eji.15.2024.03.05.01.06.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 Mar 2024 01:06:18 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a114a4ce-dacf-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709629578; x=1710234378; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=b6myWXNcLURR9kBWEqO1eQi9eE7cOZznv0bO4f4eOv4=; b=KNOkQVAYEZQFrxEJTZ/rrwhGLcj3EL6Mhl8won8qRhocC1Lu65A7PRQO6pAdfsV08F f5lc6ddJTtBGfNHn/XvKdsYkl483ivBXlFmi0A5wD7YFkcNm78l1S2ylhdsh+Gq89MKa 7tb6n9v1qOcgG3tMMO+/nwcSAJ8IR0Ay/fxPvJNyAfqns0yj2Zx1faSIbH6UIh6R49IZ rV07JDy4dgLEEiZGyL9lzADINrJUbzxsAvkpVo+kgmmi1JUhvxNXxXzev6xDCSgu4+sT i99VvjHWemRBAuHVPnmasLgtDKXjVYxg68Ex0liUOXfhY/PUAOIBJJpvrcRnRU8a5fNl fQVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709629579; x=1710234379; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=b6myWXNcLURR9kBWEqO1eQi9eE7cOZznv0bO4f4eOv4=; b=GeT5jlW6ytZqpVk9ccaVwxc4l9DzoN2IBbDzitXwGnlOjsborrL8y9y1fi5DVBW1+F fMYcI2K0jJI08KKUexcvo6KV+EZ2/S8xq6UH7F/+ZcfcrGFP3u9ihj3XdfepK2rP3Nfm U6x1k/N7R10rjb6Pp4hEGrymwR+AKk0jZkFiHuUqNyldYgd2B1CtC+f++c8U7sX5nQF3 EfL5O00DCjaxiXcspux7k/Rw3Fap7+DE3BLTiiOgklpK9ghwbQTBNIyq7rdABdEaGlP1 0ACm/VQrKp5sloshrQa6/CNRVxFyzVkp3if86ApUTQP7XtP8MoinALpf8hsI31qy9BOZ 0Skw== X-Forwarded-Encrypted: i=1; AJvYcCXPJjKXz91R/q+1BbQ3FNycOgZpmboAJoR+ylq53SDuXgNI4MzhDdXSRWb829EQ0Hl+1RmZMZBY5poRumASe7+Zg5b1oKF7/U4z1cNIm2A= X-Gm-Message-State: AOJu0YxT2cYtG94DwK4AYtrZiJOQGbB1NE80oZIX48jb5aNcLMd4HRTO OS7BUfNg8yFANIIJiHgSZF592VVvrSTW6eVukt0aO0VjaI40nLKG1A0Spfeoog== X-Google-Smtp-Source: AGHT+IG+rJAItN1CrtcfXKfRD6gl22xYC2wANjGL9X48Ej1ez9dPed87kz9uNrm5dGZdQN3eiwMdfQ== X-Received: by 2002:a17:906:c7d0:b0:a44:8caf:a2e0 with SMTP id dc16-20020a170906c7d000b00a448cafa2e0mr9038850ejb.74.1709629578618; Tue, 05 Mar 2024 01:06:18 -0800 (PST) Message-ID: Date: Tue, 5 Mar 2024 10:06:17 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/3] x86: introduce xstate_zero Content-Language: en-US To: Fouad Hilly Cc: Wei Liu , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu , Xen-devel References: <20240304091307.2295344-1-fouad.hilly@cloud.com> <20240304091307.2295344-3-fouad.hilly@cloud.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20240304091307.2295344-3-fouad.hilly@cloud.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 04.03.2024 10:13, Fouad Hilly wrote: > +void xstate_zero(uint64_t mask) > +{ > + bool ok; > + struct xsave_struct tmp; > + > + tmp.fpu_sse.mxcsr = MXCSR_DEFAULT; This is a clear indication that the function name is wrong. Perhaps it is "reset" that was meant? > + tmp.xsave_hdr.xstate_bv = 0; > + tmp.xsave_hdr.xcomp_bv = 0; > + memset(tmp.xsave_hdr.reserved, 0, sizeof(tmp.xsave_hdr.reserved)); > + > + ok = xrstor__(&tmp, mask, mask); There's a lot of "tmp" that is left uninitialized, which would introduce a leak of (stack) data. I think "tmp" instead wants to have an initializer (consisting of just the explicit setting of MXCSR, leaving everything else to be default, i.e. zero-initialized). > + ASSERT(ok); > } > > bool xsave_enabled(const struct vcpu *v) > @@ -731,6 +753,9 @@ int handle_xsetbv(u32 index, u64 new_bv) > if ( (new_bv & ~xcr0_max) || !valid_xcr0(new_bv) ) > return -EINVAL; > > + /* Zero state components before writing new XCR0 */ > + xstate_zero(get_xcr0()); This change isn't explained in the description, doesn't fit the subject (i.e. mechanical and functional change likely want splitting), and is imo wrong: Why would XSETBV gain this kind of side effect, when processed (emulated) in Xen? What I can see may want clearing are state components which were never enabled before by a vCPU. That would then need doing after writing the new XCR0 value, though. And it looks like that's already in place - is there something wrong with that code? Or is this about clearing in hardware state components about to be turned off? If so, it would again need to be only the delta of components that's reset here, and their state would need saving first. Upon re-enabling of a component, that state would then need to be available for restoring. This need for saving of state would then also explain why what's presently named xstate_zero() can't very well use the vCPU's ->arch.xsave_area, but needs to have a (relatively big) on-stack variable instead. Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 05 09:23:08 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 09:23:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688649.1073084 (Exim 4.92) (envelope-from ) id 1rhR0n-0000dm-IX; Tue, 05 Mar 2024 09:23:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688649.1073084; Tue, 05 Mar 2024 09:23:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhR0n-0000df-FD; Tue, 05 Mar 2024 09:23:01 +0000 Received: by outflank-mailman (input) for mailman id 688649; Tue, 05 Mar 2024 09:23:00 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhR0m-0000dZ-AD for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 09:23:00 +0000 Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [2a00:1450:4864:20::52c]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id f462285c-dad1-11ee-afda-a90da7624cb6; Tue, 05 Mar 2024 10:22:58 +0100 (CET) Received: by mail-ed1-x52c.google.com with SMTP id 4fb4d7f45d1cf-564647bcdbfso6234596a12.2 for ; Tue, 05 Mar 2024 01:22:57 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id es14-20020a056402380e00b00566d9c8e6cesm4402905edb.21.2024.03.05.01.22.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 Mar 2024 01:22:57 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f462285c-dad1-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709630577; x=1710235377; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=8/lg/dBVXYVnTxa9YsDLClf8gxSp0d+Ecm3//9clkvk=; b=FeDuSGpZ8m1gsgZm6Ov24Zq0ci5xncJFoc17NNWIxdp10mFIYnnlp5liHsKRl5WfIg iK+kgqC5kL0HFinO8/+nMWAKLCEi6M3JY2KQy0+mDUE2t8A7NjZ1C4MPudjVMsuxuyL/ gMWCdhA0DHV07prkkMxAdJN9B51+M7xAcv71RBvgq27CrMohB2Wjh+EZzmN74ptmBdo9 cmKlFe79BwCIWFZJmlIcf60Gx3bWVywA0Q2C37ucGHUry3zbNOcG4lF3jdhtF/ne7ZNT UUYtQdWkig5FoLqALZcOYsWAoOUNm2uvI1HDG7W3AoHukNYVUSsBinkJu6uucjsWLncm B6yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709630577; x=1710235377; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=8/lg/dBVXYVnTxa9YsDLClf8gxSp0d+Ecm3//9clkvk=; b=cZvxGU9j0b1cqEXglB9nEttl3RL06I8A5oqDJAT4EG16T6DF/SAnXAc2lu21SxfYym k97c8m5ZoHYvArLm1eOET+xYT+AtmjlY+gzVDDQvM2MT2TLEc4W1Esr8SpfsONkkiEY7 uHKBG1zSusbQGEsS/breppOcVzD1HfJg0gG6DaRStW59Sk1lfFHGUG8AL4FAtyO0Ppty Ej/Ztou2xpXT5T2VfgKJl4iw37MtuBKKKI8v3niezavK954IbEbXMhMduBwSROla7jU7 6utqgVqgsvBJdqiE2mvzSCH6fmnYAnGKWCOeww4QEXmUdgsY9Pr1jcS4mCcMZJtegGfs DudQ== X-Forwarded-Encrypted: i=1; AJvYcCW4lEIAFFxbCs6kyMGwqb6cSy/Y4k631MFg0vSCMRW8QnRG8DdCni2EQ75iPv52OKgv4HuzoGWOBeTImIMk3Wax2NICahI7ikB4ZAxZHAE= X-Gm-Message-State: AOJu0YzIWEclXiHowl1FV2wmCxkKXdbrgM2msClQvqUaB8IBinlePtkx 6h2cYiV992UZ6pE85E6TLqSDPu5V6XmXr/v2KzJudw73lJXkShJ0dPJFBUx4Wg== X-Google-Smtp-Source: AGHT+IFj6YAOi9Pay0Z9dpIK8woAvsAmaEyk7nUtw6opE8f4fbFvvkst+s6I9bbdJZm/hjdTDOInWQ== X-Received: by 2002:a05:6402:2226:b0:566:2e42:8c38 with SMTP id cr6-20020a056402222600b005662e428c38mr6810620edb.2.1709630577428; Tue, 05 Mar 2024 01:22:57 -0800 (PST) Message-ID: <0f956920-48a1-4934-9ded-6aeda2a51867@suse.com> Date: Tue, 5 Mar 2024 10:22:56 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 3/3] x86: switch to eager fpu save / restore Content-Language: en-US To: Fouad Hilly Cc: Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Andrew Cooper , Wei Liu , George Dunlap , Julien Grall , Stefano Stabellini , Paul Durrant , Jun Nakajima , Kevin Tian , Xen-devel References: <20240304091307.2295344-1-fouad.hilly@cloud.com> <20240304091307.2295344-4-fouad.hilly@cloud.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20240304091307.2295344-4-fouad.hilly@cloud.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 04.03.2024 10:13, Fouad Hilly wrote: > From: Wei Liu > > Previously FPU is lazily switched. Due to the fact that a malicious > guest can speculatively read the not yet switched out register states, > we need to eagerly switch FPU states when a domain is scheduled to > run. The speculation aspect is already covered as of XSA-267, and hence imo cannot be used as a justification here. > In the new world, Xen will eagerly switch FPU context in the > scheduler. Xen itself won't set CR0.TS other than for the purpose of > servicing a PV guest. > > The following things are done: > > 1. Xen will only set and clear CR0.TS on behalf of a PV guest. Any #NM > received in Xen should only be delivered to the running PV guest. > > 2. Xen no longer causes vmexit for #NM for HVM guests when nested HVM > is not in use. > > 3. When nested HVM is in use, Xen needs to trap #NM if specified by > the L1 hypervisor, but all #NM handling is left to L1 hypervisor > to deal with. > > 4. Xen saves and restores FPU states wherever it needs to. The > following places are modified: > 1. Scheduling in and out a guest; > 2. Calling EFI runtime service; > 3. ACPI reset; > 4. x86 insn emulator fpu insn emulation. > > 5. Treat FPU as always initialised. Adjust following components: > 1. HVM vcpu context save / load code; > 2. arch_{get,set}_info_guest; > 3. VLAPIC code. > > 6. Delete lazy FPU handling code. This wants splitting up. I'm actually puzzled that step 6 does not include purging of e.g. opt_eager_fpu. Converting that to "always true" would seem to be the one first step with a functional change. All further steps would be removal of then-dead code. > Strip XCR0 and IA32_XSS manipulation from __context_switch. We need to > be able to zero out previously used state components. Push everything > into fpu_xrstor as that's the most suitable place. > > Tested on AMD with PKU disabled and Intel, no performance degradation. I dare to at least question whether this is going to hold once we support one of the huge state components (AMX patches have been pending for years). Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 05 09:25:21 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 09:25:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688651.1073094 (Exim 4.92) (envelope-from ) id 1rhR31-0001CZ-Uf; Tue, 05 Mar 2024 09:25:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688651.1073094; Tue, 05 Mar 2024 09:25:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhR31-0001CS-Qa; Tue, 05 Mar 2024 09:25:19 +0000 Received: by outflank-mailman (input) for mailman id 688651; Tue, 05 Mar 2024 09:25:19 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhR31-0001CM-C5 for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 09:25:19 +0000 Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [2607:f8b0:4864:20::f2b]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 471f15d5-dad2-11ee-a1ee-f123f15fe8a2; Tue, 05 Mar 2024 10:25:17 +0100 (CET) Received: by mail-qv1-xf2b.google.com with SMTP id 6a1803df08f44-68fcedcf8aaso25462046d6.2 for ; Tue, 05 Mar 2024 01:25:17 -0800 (PST) Received: from localhost ([213.195.118.74]) by smtp.gmail.com with ESMTPSA id nc6-20020a0562142dc600b0068fb9bdd7absm5514455qvb.74.2024.03.05.01.25.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Mar 2024 01:25:15 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 471f15d5-dad2-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709630716; x=1710235516; darn=lists.xenproject.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=A60ZVTWKctOxam6vMYDrKTVFVbMjSszILsN+KLqLg88=; b=B9ddwrdwQB6TdiE5J6XuM/+tfpGthxgytiCa74YmNQm+7MT0DH5KxcQF/gf7+0RKhE UxOqn/dVXY8+SRInN+iMpspXLSuuminvDiQbGCC4OUA+QAG2DKtuBHo40Wfo+2lQ4PAt opjz4GCmCifxRv1gOzubi3cV9xcF6ouQ0OGbk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709630716; x=1710235516; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=A60ZVTWKctOxam6vMYDrKTVFVbMjSszILsN+KLqLg88=; b=bG0/9e4AWu5rwvj4YpjBAnsUoE6yXDEUjWaITSiPszsgbKyq7DOtwjIfznjL5sXR3W bXkvZNqiEBfRqbAYHAuN+61xwXclQKbCgl84V0hRWU0dTXChO67W8kPyatz2TzMvMnLY 1kkoSlkeZApRIqwO78y4DruuxNuq4mTQMh2R5OdYQJeSNWnh0aWzT1Qn/XLScmTdevvI 3QILNwHZ242wVm95zFnM98IVpasGdIZZpyz4gWSTmFyv5lH8vQ29Dt3VQHusryTZVIyi uV/ZzgaCj+XSFhLDXHOcnB+bEj+x+JMjHQaLAdeXwuREDrHjxG6/JUDbJIxEWpJ43JiZ BGWQ== X-Gm-Message-State: AOJu0Yy4WMqQKAxRaX/1AGATxaEslm6xuKW4OFnS5MwNFmBnba4NAV9g CO7l/EyJZJiIOLYQKwQ++a050JH6d0BYds9ID0u5KkPemoh6pNiwKUox4ncK/1w= X-Google-Smtp-Source: AGHT+IGGPOqxF0FgMBddgmSOBpes/X9OR2/+vJNekXcYIUTTrmxCLEQ5J0glHevoF356AMkiEOyW8g== X-Received: by 2002:a0c:edb2:0:b0:68f:ecde:f13f with SMTP id h18-20020a0cedb2000000b0068fecdef13fmr1420248qvr.22.1709630716007; Tue, 05 Mar 2024 01:25:16 -0800 (PST) Date: Tue, 5 Mar 2024 10:25:13 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Wei Liu , Neowutran Subject: Re: [PATCH] hvmloader/PCI: skip huge BARs in certain calculations Message-ID: References: <090d572c-5196-46b2-9d6b-741b7cb66d97@suse.com> <06cce36e-5936-4374-9b56-1cb166c2b8b7@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <06cce36e-5936-4374-9b56-1cb166c2b8b7@suse.com> On Mon, Mar 04, 2024 at 02:25:45PM +0100, Jan Beulich wrote: > On 04.03.2024 11:02, Roger Pau Monné wrote: > > On Mon, Mar 04, 2024 at 08:32:22AM +0100, Jan Beulich wrote: > >> BARs of size 2Gb and up can't possibly fit below 4Gb: Both the bottom of > >> the lower 2Gb range and the top of the higher 2Gb range have special > >> purpose. Don't even have them influence whether to (perhaps) relocate > >> low RAM. > > > > Here you mention 2Gb BARs, yet the code below sets the maximum BAR > > size supported below 4Gb to 1Gb. > > Hmm, I'm puzzled: There are no other BAR sizes between 1Gb and 2Gb. > Anything up to 1Gb continues to work as is, while everything 2Gb and > up has behavior changed. My bad, I was confused. > >> --- a/tools/firmware/hvmloader/pci.c > >> +++ b/tools/firmware/hvmloader/pci.c > >> @@ -33,6 +33,13 @@ uint32_t pci_mem_start = HVM_BELOW_4G_MM > >> const uint32_t pci_mem_end = RESERVED_MEMBASE; > >> uint64_t pci_hi_mem_start = 0, pci_hi_mem_end = 0; > >> > >> +/* > >> + * BARs larger than this value are put in 64-bit space unconditionally. That > >> + * is, such BARs also don't play into the determination of how big the lowmem > >> + * MMIO hole needs to be. > >> + */ > >> +#define HUGE_BAR_THRESH GB(1) > > > > I would be fine with defining this to an even lower number, like > > 256Mb, as to avoid as much as possible memory relocation in order to > > make the MMIO hole bigger. > > As suggested in a post-commit-message remark, the main question then is > how to justify this. I think the justification is to avoid having to relocate memory in order to attempt to make the hole below 4Gb larger. > >> @@ -367,7 +376,7 @@ void pci_setup(void) > >> pci_mem_start = hvm_info->low_mem_pgend << PAGE_SHIFT; > >> } > >> > >> - if ( mmio_total > (pci_mem_end - pci_mem_start) ) > >> + if ( mmio_total > (pci_mem_end - pci_mem_start) || bar64_relocate ) > >> { > >> printf("Low MMIO hole not large enough for all devices," > >> " relocating some BARs to 64-bit\n"); > > > > Is the above message now accurate? Given the current code the low > > MMIO could be expanded up to 2Gb, yet BAR relocation will happen > > unconditionally once a 1Gb BAR is found. > > Well, "all" may not be quite accurate anymore, yet would making it e.g. > "all applicable" really much more meaningful? > > >> @@ -446,8 +455,9 @@ void pci_setup(void) > >> * the code here assumes it to be.) > >> * Should either of those two conditions change, this code will break. > >> */ > >> - using_64bar = bars[i].is_64bar && bar64_relocate > >> - && (mmio_total > (mem_resource.max - mem_resource.base)); > >> + using_64bar = bars[i].is_64bar && bar64_relocate && > >> + (mmio_total > (mem_resource.max - mem_resource.base) || > >> + bar_sz > HUGE_BAR_THRESH); > >> bar_data = pci_readl(devfn, bar_reg); > >> > >> if ( (bar_data & PCI_BASE_ADDRESS_SPACE) == > >> @@ -467,7 +477,8 @@ void pci_setup(void) > >> resource = &mem_resource; > >> bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK; > >> } > >> - mmio_total -= bar_sz; > >> + if ( bar_sz <= HUGE_BAR_THRESH ) > >> + mmio_total -= bar_sz; > > > > I'm missing the part where hvmloader notifies QEMU of the possibly > > expanded base and size memory PCI MMIO regions, so that those are > > reflected in the PCI root complex registers? > > I don't understand this comment: I'm not changing the interaction > with qemu at all. Whatever the new calculation it'll be communicated > to qemu just as before. That wasn't a complain about the patch, just me failing to see where this is done. > > Overall I think we could simplify the code by having a hardcoded 1Gb > > PCI MMIO hole below 4Gb, fill it with all the 32bit BARs and > > (re)locate all 64bit BARs above 4Gb (not that I'm requesting you to do > > it here). > > I'm afraid that would not work very well with OSes which aren't 64-bit > BAR / PA aware (first and foremost non-PAE 32-bit ones). Iirc that's > the reason why it wasn't done like you suggest back at the time. There will still be a ~1Gb window < 4Gb, so quite a bit of space. I'm unsure whether such OSes will have drivers to manage devices with that huge BARs in the first place. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Tue Mar 05 09:26:16 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 09:26:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688653.1073103 (Exim 4.92) (envelope-from ) id 1rhR3w-0001iu-5u; Tue, 05 Mar 2024 09:26:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688653.1073103; Tue, 05 Mar 2024 09:26:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhR3w-0001in-3H; Tue, 05 Mar 2024 09:26:16 +0000 Received: by outflank-mailman (input) for mailman id 688653; Tue, 05 Mar 2024 09:26:15 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhR3v-0001fb-6X for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 09:26:15 +0000 Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [2a00:1450:4864:20::62e]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 68a909d8-dad2-11ee-a1ee-f123f15fe8a2; Tue, 05 Mar 2024 10:26:13 +0100 (CET) Received: by mail-ej1-x62e.google.com with SMTP id a640c23a62f3a-a4532f84144so249464266b.3 for ; Tue, 05 Mar 2024 01:26:13 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id w17-20020a170906d21100b00a457a55b814sm1444630ejz.73.2024.03.05.01.26.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 Mar 2024 01:26:12 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 68a909d8-dad2-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709630772; x=1710235572; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=2JJo3GMuGF6faUVrtPbVVv//0bNWCj/rHRTAK1KsgDA=; b=KzBoHVQ9NLC9ADdTqpP2MyKUJxby0ftI7r1AVYYmA6GC4x8KTc0Qc7BgAQK3J++XKv V0maASOwCHJkk3CtOFr31MM4qD7yXrqvMAnG4aSqXgh7FMupXMrxzy484CNJdeY6deU/ NaTOa2ous2qIDpZeDFUymaOpamSBt2/H8JmpgPh4VifYpg4P29M9N8G2Ux7viASbEnj+ KrdimLKWbPYeGrEpj+B/+YihGEq5orIvyazrbgOGUDLkGfBj7DCL4mgqN5ijyqCpf7Qp AIHsIHMDjtxdjBpMHTOIAd9cQBZwFB9QOg1JVANetp/va+PpuWvm5UUKVJpQkorm18eJ fj5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709630772; x=1710235572; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=2JJo3GMuGF6faUVrtPbVVv//0bNWCj/rHRTAK1KsgDA=; b=LW/42XoA8ll9ACplKZ106cQxss6n5GPeKSqAR+i33OE17U/0hY/n1xw5Ee4nxx05+W lm717kr2j5+wwdb6u5BSmczWCDwBxtQ5EutRn5UCvhQs12BgZUp5P5r1g5enI08BXfIN WmZVLCZfdkWr0y1xJfwrsiV1F54lJmYcrbpPcesmkLi7qHM5oWZQsUwFQoFwGiwHTK6D b9JdDorw62K6sVvJ2cRAdgt6pf2lkik72pIwOler9ktyqXdT5CMLdWycoY0jC95hxW/Q mK+zbOArKDdMFFlrOv8CZLwrS6fJX6d20300asX9USV/uqWnrn8gOo6dFvL0laY0SRyI 2oxg== X-Forwarded-Encrypted: i=1; AJvYcCX1PED7DuaetdwytW2D4j+BvwyU9rJ3mBlvZMuBI6akkLXk9yfb4Djzf45zn/lXgSN0Y6vF+ZEf6066wcNva1LKvNYl8lilU3XRI9Z1vmg= X-Gm-Message-State: AOJu0YwkrfqRMDXdKIhxgMnGHq2uDpSrGTN2lUWax6NevFc6K1aV+uWk wZY+8FwrshJS/6975BkHOL6Ax/lzl2EClAd4QmK2SahChcMLLjVvPORhuH6A/Q== X-Google-Smtp-Source: AGHT+IGSXirh1+eyuhVCCqfAnIN1KKxuzFQDHjYS4lMFcSJVyOdZAWBc4WBmC4IVp4xZaRcxSVSQUw== X-Received: by 2002:a17:906:f2cb:b0:a45:a814:1cac with SMTP id gz11-20020a170906f2cb00b00a45a8141cacmr870589ejb.5.1709630772560; Tue, 05 Mar 2024 01:26:12 -0800 (PST) Message-ID: Date: Tue, 5 Mar 2024 10:26:11 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 0/3] X86/eager-fpu: Switch to eager fpu save/restore Content-Language: en-US To: Fouad Hilly Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Andrew Cooper , Wei Liu , George Dunlap , Julien Grall , Stefano Stabellini , Paul Durrant , Jun Nakajima , Kevin Tian , Xen-devel References: <20240304091307.2295344-1-fouad.hilly@cloud.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20240304091307.2295344-1-fouad.hilly@cloud.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 04.03.2024 10:13, Fouad Hilly wrote: > X86 Xen will only eagerly switch FPU context in the scheduler. > Xen itslef won't set CR0.TS other than for the purpose of servicing > a PV guset. > > Signed-off-by: Wei Liu > Signed-off-by: Roger Pau Monné > Signed-off-by: Fouad Hilly Throughout replying to the series I got back "undeliverable" responses for Wei's old address at Citrix (noticed only now when I looked at what has accumulated again in my inbox in the meantime). Can you please avoid having dead addresses in patch submissions? Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 05 09:31:59 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 09:31:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688657.1073113 (Exim 4.92) (envelope-from ) id 1rhR9O-0003w3-Om; Tue, 05 Mar 2024 09:31:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688657.1073113; Tue, 05 Mar 2024 09:31:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhR9O-0003vw-MJ; Tue, 05 Mar 2024 09:31:54 +0000 Received: by outflank-mailman (input) for mailman id 688657; Tue, 05 Mar 2024 09:31:53 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhR9N-0003vq-AO for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 09:31:53 +0000 Received: from mail-qv1-xf29.google.com (mail-qv1-xf29.google.com [2607:f8b0:4864:20::f29]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 328086e5-dad3-11ee-afda-a90da7624cb6; Tue, 05 Mar 2024 10:31:52 +0100 (CET) Received: by mail-qv1-xf29.google.com with SMTP id 6a1803df08f44-68facd7ea4bso24821676d6.0 for ; Tue, 05 Mar 2024 01:31:52 -0800 (PST) Received: from localhost ([213.195.118.74]) by smtp.gmail.com with ESMTPSA id or33-20020a05621446a100b0068f455083fbsm5988780qvb.63.2024.03.05.01.31.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Mar 2024 01:31:50 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 328086e5-dad3-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709631111; x=1710235911; darn=lists.xenproject.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=f7Hdyneh0bF9rKcOXYTu1KEF6mx7L0GYzE3MErGK9FE=; b=dccFRSrKsABZ49RTX00dP1P9tNJwaWRrmENZ1Qj3S1fBXkLn6D/CnJ3J7OH24teCO7 SnI8Am0SKc1mpdVjDJ3Bq70CvCWU2HlR2XMR2yYLHdqRovrxxIf+E+85sjK7LJVcUbs/ aUEpafppo67BMybKt7nGV+AGynBeOM65mVk7M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709631111; x=1710235911; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=f7Hdyneh0bF9rKcOXYTu1KEF6mx7L0GYzE3MErGK9FE=; b=voSWCpdNRrB4aF0GdEdCDcs6S8ud4otm+APHS7XGXN7ylT1U4SK6wxrIRqic+7s3Di WCWZ4knXTfl3l5Yok3kNtHWHYwBumgnam760zvMzBrQhv9ddctvWPgkh+G1WI3vfxyfg cLOhDwaYJgPlLKkzaMMMhjGGINrIPzUKWh8Jyu4drFK+XXZKQbTXPlpyDLsi5WvSqxPx wLxmpdk35fZognuvsBLuVASDXY3s4L2R4K/CD/hLE6YdIkX4KXyrXEgT3lBK6QpJut/Y bFuSeXUuMRP/hDvuFy4yi9e9pArkoZvdxl8QKs/Hv4IHDfxp54QIkWUGD6QvWeCGSNIm PWKQ== X-Gm-Message-State: AOJu0YzEPkny3FH89nsiq3u11p667grzzcmNCaXnQ18L7em9hf8tWiXN GWn6yY4HIGXCpt1Zi8ft3N0veXj+5XWcs2BznXfivS0agwfCc6Hd6tuF5e9y79MEJNHopWUZQ+j g X-Google-Smtp-Source: AGHT+IEVsPhLHwihvsLUKR+dooz4em4+DZA6bmfsmayJDeizklumS2XwHDvhV0BRCxN7vaY0NYu4/Q== X-Received: by 2002:ad4:4d06:0:b0:690:766e:56d2 with SMTP id l6-20020ad44d06000000b00690766e56d2mr1362156qvl.4.1709631110952; Tue, 05 Mar 2024 01:31:50 -0800 (PST) Date: Tue, 5 Mar 2024 10:31:48 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Wei Liu , Neowutran Subject: Re: [PATCH] hvmloader/PCI: skip huge BARs in certain calculations Message-ID: References: <090d572c-5196-46b2-9d6b-741b7cb66d97@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <090d572c-5196-46b2-9d6b-741b7cb66d97@suse.com> On Mon, Mar 04, 2024 at 08:32:22AM +0100, Jan Beulich wrote: > BARs of size 2Gb and up can't possibly fit below 4Gb: Both the bottom of > the lower 2Gb range and the top of the higher 2Gb range have special > purpose. Don't even have them influence whether to (perhaps) relocate > low RAM. > > Reported-by: Neowutran > Signed-off-by: Jan Beulich Acked-by: Roger Pau Monné > --- > If we wanted to fit e.g. multiple 1Gb BARs, it would likely be prudent > to similarly avoid low RAM relocation in the first place. Yet accounting > for things differently depending on how many large BARs there are would > require more intrusive code changes. > > That said, I'm open to further lowering of the threshold. That'll > require different justification then, though. > > --- a/tools/firmware/hvmloader/pci.c > +++ b/tools/firmware/hvmloader/pci.c > @@ -33,6 +33,13 @@ uint32_t pci_mem_start = HVM_BELOW_4G_MM > const uint32_t pci_mem_end = RESERVED_MEMBASE; > uint64_t pci_hi_mem_start = 0, pci_hi_mem_end = 0; > > +/* > + * BARs larger than this value are put in 64-bit space unconditionally. That > + * is, such BARs also don't play into the determination of how big the lowmem > + * MMIO hole needs to be. > + */ > +#define HUGE_BAR_THRESH GB(1) I would maybe name this `BAR_RELOCATE_THRESH, `HUGE_BAR` is too generic IMO. And also use 256Mb instead of 1GB, but just having a limit is good enough, we can further tune it afterwards. > + > enum virtual_vga virtual_vga = VGA_none; > unsigned long igd_opregion_pgbase = 0; > > @@ -286,9 +293,11 @@ void pci_setup(void) > bars[i].bar_reg = bar_reg; > bars[i].bar_sz = bar_sz; > > - if ( ((bar_data & PCI_BASE_ADDRESS_SPACE) == > - PCI_BASE_ADDRESS_SPACE_MEMORY) || > - (bar_reg == PCI_ROM_ADDRESS) ) > + if ( is_64bar && bar_sz > HUGE_BAR_THRESH ) > + bar64_relocate = 1; > + else if ( ((bar_data & PCI_BASE_ADDRESS_SPACE) == > + PCI_BASE_ADDRESS_SPACE_MEMORY) || > + (bar_reg == PCI_ROM_ADDRESS) ) > mmio_total += bar_sz; > > nr_bars++; > @@ -367,7 +376,7 @@ void pci_setup(void) > pci_mem_start = hvm_info->low_mem_pgend << PAGE_SHIFT; > } > > - if ( mmio_total > (pci_mem_end - pci_mem_start) ) > + if ( mmio_total > (pci_mem_end - pci_mem_start) || bar64_relocate ) > { > printf("Low MMIO hole not large enough for all devices," > " relocating some BARs to 64-bit\n"); > @@ -446,8 +455,9 @@ void pci_setup(void) > * the code here assumes it to be.) > * Should either of those two conditions change, this code will break. > */ > - using_64bar = bars[i].is_64bar && bar64_relocate > - && (mmio_total > (mem_resource.max - mem_resource.base)); > + using_64bar = bars[i].is_64bar && bar64_relocate && > + (mmio_total > (mem_resource.max - mem_resource.base) || > + bar_sz > HUGE_BAR_THRESH); There's a comment above this that starts with: "Relocate to high memory if the total amount of MMIO needed is more than the low MMIO available." I would slightly reword it to: "Relocate to high memory if the total amount of MMIO needed is more than the low MMIO available or BARs bigger that HUGE_BAR_THRESH are present." Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Tue Mar 05 09:56:55 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 09:56:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688675.1073132 (Exim 4.92) (envelope-from ) id 1rhRXU-00080Y-Tx; Tue, 05 Mar 2024 09:56:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688675.1073132; Tue, 05 Mar 2024 09:56:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhRXU-00080R-RN; Tue, 05 Mar 2024 09:56:48 +0000 Received: by outflank-mailman (input) for mailman id 688675; Tue, 05 Mar 2024 09:56:47 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhRXT-0007xL-Oy for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 09:56:47 +0000 Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [2a00:1450:4864:20::630]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id adc78e06-dad6-11ee-afda-a90da7624cb6; Tue, 05 Mar 2024 10:56:46 +0100 (CET) Received: by mail-ej1-x630.google.com with SMTP id a640c23a62f3a-a44ad785a44so448465966b.3 for ; Tue, 05 Mar 2024 01:56:47 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id r2-20020a170906c28200b00a412d3d509fsm5873123ejz.181.2024.03.05.01.56.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 Mar 2024 01:56:46 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: adc78e06-dad6-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709632606; x=1710237406; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=ucFQ0xxCbouAJ2JDdMP92CVuZCUdBlts7gkBrPP6vYI=; b=Al2s5bnNlzov5YlgnyqbvdcVimc5R97IeOcNJz97CoHJ2gwbhax57W+a42QL297HFb WlowQEeO0q1NxrrHA3cdko2+7DK1saNpxxKXScJfdxUA315qCIaJsxivPTMjJnsrNYAa W6R4E+ZP/XiiwUQSM8Lr7aZUavA9JQaiuIiu3q9rFKxPAQ8ktbmV0522qSoqt7B7VH3U evRrNvbM2tL2W+dMgqOppn/6toX8mgB4FKfKv6mLw56uIil2AGHb8n2byD4Kw9XBLBdb jb6tIG89vOF19Ixbpxw2Twd7fuic2CzVRAAsWNNdoMuqEmhEoQB7JsZsHKp9uyc/fora kwXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709632606; x=1710237406; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ucFQ0xxCbouAJ2JDdMP92CVuZCUdBlts7gkBrPP6vYI=; b=deFYw2szFrBprS4jMw2ovg00NLY5mbYzCfrcrnxoWsoADajHiC7I0nE+BBCO0FJDhz CL9zFauTBuhHrRZrhr20/5u6a0ENs2YLpXbNP/lC4doma2QIxf2njDaKh61kGaEguITO +GmmPe4vWhnkHIYFjRriYDL6jaVCZWVX2jw2B2O3+S4+tWj58Bcd/NuVjB7SYrbW6hB2 9+2iaUw4R85RGHBBW95HvBmiv+9MRwZsQiX3jSv+o5qykQePMLkUxRWegEYhFZY81LMJ KfpMdnSIspecJXPvQ5Vgn5omEMxKntj9SnHRWgjU5Ecs2FEmJaOUKYAExuJFJEdjg8lY 2kQg== X-Gm-Message-State: AOJu0YzjyuAhKAg1qM1eUGe+sPooMjZag4L/B62I5zq63+FXaspbGkbG spG+q+Q/9losmyVkvJGEV8vNsBoWvU9fhRdEdNrYuLmyKSUD5FRL20KCbQA6BQ== X-Google-Smtp-Source: AGHT+IHhh0YA00ouU8CyEgFMWh7iODFy5vSvFtvwL9rmrLJ9gcqhWiJGkarRd02AO5b1rO2s/YJR/g== X-Received: by 2002:a17:906:1155:b0:a45:7451:d255 with SMTP id i21-20020a170906115500b00a457451d255mr2890254eja.29.1709632606446; Tue, 05 Mar 2024 01:56:46 -0800 (PST) Message-ID: Date: Tue, 5 Mar 2024 10:56:45 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] hvmloader/PCI: skip huge BARs in certain calculations Content-Language: en-US To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Wei Liu , Neowutran References: <090d572c-5196-46b2-9d6b-741b7cb66d97@suse.com> <06cce36e-5936-4374-9b56-1cb166c2b8b7@suse.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 05.03.2024 10:25, Roger Pau Monné wrote: > On Mon, Mar 04, 2024 at 02:25:45PM +0100, Jan Beulich wrote: >> On 04.03.2024 11:02, Roger Pau Monné wrote: >>>> --- a/tools/firmware/hvmloader/pci.c >>>> +++ b/tools/firmware/hvmloader/pci.c >>>> @@ -33,6 +33,13 @@ uint32_t pci_mem_start = HVM_BELOW_4G_MM >>>> const uint32_t pci_mem_end = RESERVED_MEMBASE; >>>> uint64_t pci_hi_mem_start = 0, pci_hi_mem_end = 0; >>>> >>>> +/* >>>> + * BARs larger than this value are put in 64-bit space unconditionally. That >>>> + * is, such BARs also don't play into the determination of how big the lowmem >>>> + * MMIO hole needs to be. >>>> + */ >>>> +#define HUGE_BAR_THRESH GB(1) >>> >>> I would be fine with defining this to an even lower number, like >>> 256Mb, as to avoid as much as possible memory relocation in order to >>> make the MMIO hole bigger. >> >> As suggested in a post-commit-message remark, the main question then is >> how to justify this. > > I think the justification is to avoid having to relocate memory in > order to attempt to make the hole below 4Gb larger. Upon further thinking about it, I'm now pretty convinced that any lowering of the boundary would better be a separate change. Right here I'd like to stick to just the technically implied boundary. >>>> @@ -446,8 +455,9 @@ void pci_setup(void) >>>> * the code here assumes it to be.) >>>> * Should either of those two conditions change, this code will break. >>>> */ >>>> - using_64bar = bars[i].is_64bar && bar64_relocate >>>> - && (mmio_total > (mem_resource.max - mem_resource.base)); >>>> + using_64bar = bars[i].is_64bar && bar64_relocate && >>>> + (mmio_total > (mem_resource.max - mem_resource.base) || >>>> + bar_sz > HUGE_BAR_THRESH); >>>> bar_data = pci_readl(devfn, bar_reg); >>>> >>>> if ( (bar_data & PCI_BASE_ADDRESS_SPACE) == >>>> @@ -467,7 +477,8 @@ void pci_setup(void) >>>> resource = &mem_resource; >>>> bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK; >>>> } >>>> - mmio_total -= bar_sz; >>>> + if ( bar_sz <= HUGE_BAR_THRESH ) >>>> + mmio_total -= bar_sz; >>> >>> I'm missing the part where hvmloader notifies QEMU of the possibly >>> expanded base and size memory PCI MMIO regions, so that those are >>> reflected in the PCI root complex registers? >> >> I don't understand this comment: I'm not changing the interaction >> with qemu at all. Whatever the new calculation it'll be communicated >> to qemu just as before. > > That wasn't a complain about the patch, just me failing to see where > this is done. I see. Is there any such needed though? There's nothing root-complex-ish in PIIX4 after all, for not knowing of PCIe yet. The only datasheet I have readily available is for a slightly older variant of the 82371AB, yet I can't spot any registers there which would need updating (to inform qemu). >>> Overall I think we could simplify the code by having a hardcoded 1Gb >>> PCI MMIO hole below 4Gb, fill it with all the 32bit BARs and >>> (re)locate all 64bit BARs above 4Gb (not that I'm requesting you to do >>> it here). >> >> I'm afraid that would not work very well with OSes which aren't 64-bit >> BAR / PA aware (first and foremost non-PAE 32-bit ones). Iirc that's >> the reason why it wasn't done like you suggest back at the time. > > There will still be a ~1Gb window < 4Gb, so quite a bit of space. Yet not enough to fit a single 1Gb BAR. > I'm unsure whether such OSes will have drivers to manage devices with > that huge BARs in the first place. Assuming at least basic functionality of gfx cards is backwards compatible, I see nothing wrong with an old driver successfully attaching to a modern card surfacing, say, a 256Mb BAR. I'm afraid we need to be conservative here and keep configurations working which in principle can work without using any 64-bit addresses. Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 05 10:05:56 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 10:05:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688697.1073146 (Exim 4.92) (envelope-from ) id 1rhRgF-0001sy-Qp; Tue, 05 Mar 2024 10:05:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688697.1073146; Tue, 05 Mar 2024 10:05:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhRgF-0001sr-Nq; Tue, 05 Mar 2024 10:05:51 +0000 Received: by outflank-mailman (input) for mailman id 688697; Tue, 05 Mar 2024 10:05:51 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhRgE-0001sj-VX for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 10:05:50 +0000 Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [2a00:1450:4864:20::633]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id f0bd292d-dad7-11ee-a1ee-f123f15fe8a2; Tue, 05 Mar 2024 11:05:48 +0100 (CET) Received: by mail-ej1-x633.google.com with SMTP id a640c23a62f3a-a4499ef8b5aso396596466b.0 for ; Tue, 05 Mar 2024 02:05:48 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id o26-20020a1709061d5a00b00a44f6ce3e7fsm3340941ejh.77.2024.03.05.02.05.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 Mar 2024 02:05:48 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f0bd292d-dad7-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709633148; x=1710237948; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=7SmU9pewJHYbAF4aPkfQlh+Gg13jFRqwbbVdgo9MU2o=; b=RNUan2BbbHj696u4YCI4coGcoeJgBXQUvgvOXg0e6SbpQZ5PODrTYY9Ecygvcc4UPl eUa9PK/z5RYXqUo2u8LSbjXBbSrg7skwD+yzdxbG6hPkBuQsSJ1Co7Qb2AJw1CrhMhS7 kvxikduHeZzDI9OZRsk/JQsdf2HPb2W9EwQv6BLbEkTWY3auF+qCifKpS0XEBGFOs7mG uWXCcd/xH3aDWMhOHXg1gGA4Ox9sFU7egInFKoowf5F3HRYb/qR3DEK5rkRdAE4PjkmD fH/i9i0ktONhyewki+6OBRDgVbOsssniRXeACq9if/nxLA+kWb5CVXYhruVNBVxwZrIv VmUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709633148; x=1710237948; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=7SmU9pewJHYbAF4aPkfQlh+Gg13jFRqwbbVdgo9MU2o=; b=UIFbThBTNmuZ+mFHaFw7KlpydZAoGtiX19Ef6YaV+c2RF6KyDbLyB6k7FZDV9P8BqW vtw3CRXwgZKYw8Da0n3m8sfGctxgVFTQwpjsZv5meXhywyusycgjHDVtQj9M//3UvrMe 4JlYg6solA8BEqV+XIqQFZOLEU/cA5JiIs0rFZMzL9i295cC0/E0ZeMvyNl0vKbiSgSP XOycAffpu6iAskNS2IElHNcyHXZD0yxRP4yK9D3cVJ+u5j5lOmg1eo32uCiTUmjGobZG FAaRbH19WF+Sdrx1UP/gQOZVo+v6J4Om0b/rP+xAsftDtjPbhMPGtk6D3q828WKEMcg9 74Lg== X-Gm-Message-State: AOJu0YwIgQfOnF7nHtrrt7XoRQclsFvQ/6aJM9hFtDYJvOGpZMaByxDj yHcy7u8n3IwGNWXj6e4fftwiBpbXqi0mH5EwEs//tFt/f6H5NajN2QDbsr53wQ== X-Google-Smtp-Source: AGHT+IGGThR46eccxaXipKrE+fr3QWJm27ZfeIXFowA+lhRA7Tp2qyXCtv91a6HKjZLep5/Yj+7p1A== X-Received: by 2002:a17:906:ccc8:b0:a44:1a51:a1fd with SMTP id ot8-20020a170906ccc800b00a441a51a1fdmr7267817ejb.64.1709633148281; Tue, 05 Mar 2024 02:05:48 -0800 (PST) Message-ID: Date: Tue, 5 Mar 2024 11:05:47 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] hvmloader/PCI: skip huge BARs in certain calculations Content-Language: en-US To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Wei Liu , Neowutran References: <090d572c-5196-46b2-9d6b-741b7cb66d97@suse.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 05.03.2024 10:31, Roger Pau Monné wrote: > On Mon, Mar 04, 2024 at 08:32:22AM +0100, Jan Beulich wrote: >> BARs of size 2Gb and up can't possibly fit below 4Gb: Both the bottom of >> the lower 2Gb range and the top of the higher 2Gb range have special >> purpose. Don't even have them influence whether to (perhaps) relocate >> low RAM. >> >> Reported-by: Neowutran >> Signed-off-by: Jan Beulich > > Acked-by: Roger Pau Monné Thanks. >> --- a/tools/firmware/hvmloader/pci.c >> +++ b/tools/firmware/hvmloader/pci.c >> @@ -33,6 +33,13 @@ uint32_t pci_mem_start = HVM_BELOW_4G_MM >> const uint32_t pci_mem_end = RESERVED_MEMBASE; >> uint64_t pci_hi_mem_start = 0, pci_hi_mem_end = 0; >> >> +/* >> + * BARs larger than this value are put in 64-bit space unconditionally. That >> + * is, such BARs also don't play into the determination of how big the lowmem >> + * MMIO hole needs to be. >> + */ >> +#define HUGE_BAR_THRESH GB(1) > > I would maybe name this `BAR_RELOCATE_THRESH, `HUGE_BAR` is too > generic IMO. BAR_RELOC_THRESH it is then. > And also use 256Mb instead of 1GB, but just having a limit is good > enough, we can further tune it afterwards. As indicated in an earlier reply, I now firmly think that if we want to do so, it wants doing separately / incrementally. >> @@ -446,8 +455,9 @@ void pci_setup(void) >> * the code here assumes it to be.) >> * Should either of those two conditions change, this code will break. >> */ >> - using_64bar = bars[i].is_64bar && bar64_relocate >> - && (mmio_total > (mem_resource.max - mem_resource.base)); >> + using_64bar = bars[i].is_64bar && bar64_relocate && >> + (mmio_total > (mem_resource.max - mem_resource.base) || >> + bar_sz > HUGE_BAR_THRESH); > > There's a comment above this that starts with: > > "Relocate to high memory if the total amount of MMIO needed is more > than the low MMIO available." > > I would slightly reword it to: > > "Relocate to high memory if the total amount of MMIO needed is more > than the low MMIO available or BARs bigger that HUGE_BAR_THRESH are > present." Hmm, yes, done. Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 05 10:21:39 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 10:21:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688701.1073156 (Exim 4.92) (envelope-from ) id 1rhRvK-0004ub-5H; Tue, 05 Mar 2024 10:21:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688701.1073156; Tue, 05 Mar 2024 10:21:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhRvK-0004uU-0Z; Tue, 05 Mar 2024 10:21:26 +0000 Received: by outflank-mailman (input) for mailman id 688701; Tue, 05 Mar 2024 10:21:25 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhRvJ-0004sb-5N for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 10:21:25 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 1be1d1e4-dada-11ee-a1ee-f123f15fe8a2; Tue, 05 Mar 2024 11:21:20 +0100 (CET) Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) by support.bugseng.com (Postfix) with ESMTPA id B96A94EE0737; Tue, 5 Mar 2024 11:21:19 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1be1d1e4-dada-11ee-a1ee-f123f15fe8a2 MIME-Version: 1.0 Date: Tue, 05 Mar 2024 11:21:19 +0100 From: Nicola Vetrini To: Stefano Stabellini , Jbeulich Cc: michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, consulting@bugseng.com, andrew.cooper3@citrix.com, roger.pau@citrix.com, bertrand.marquis@arm.com, julien@xen.org, George Dunlap , Wei Liu , xen-devel@lists.xenproject.org Subject: Re: [XEN PATCH 04/10] xen/public: address violations of MISRA C Rule 20.7 In-Reply-To: References: <0cdc4dc2fcad699a2274277b32de3ee0207d5a2d.1709219010.git.nicola.vetrini@bugseng.com> <82940f688e5a5eee274fa579991ebd15@bugseng.com> Message-ID: <0e131a6795c9d28583e5e8c248843e67@bugseng.com> X-Sender: nicola.vetrini@bugseng.com Organization: BUGSENG s.r.l. Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 2024-02-29 23:49, Stefano Stabellini wrote: > On Thu, 29 Feb 2024, Nicola Vetrini wrote: >> On 2024-02-29 17:40, Jan Beulich wrote: >> > On 29.02.2024 16:27, Nicola Vetrini wrote: >> > > --- a/xen/include/public/xen.h >> > > +++ b/xen/include/public/xen.h >> > > @@ -988,7 +988,7 @@ typedef struct { >> > > ((b) >> 8) & 0xFF, ((b) >> 0) & 0xFF, \ >> > > ((c) >> 8) & 0xFF, ((c) >> 0) & 0xFF, \ >> > > ((d) >> 8) & 0xFF, ((d) >> 0) & 0xFF, \ >> > > - e1, e2, e3, e4, e5, e6}} >> > > + (e1), (e2), (e3), (e4), (e5), (e6)}} >> > >> > Why? Wasn't it agreed already that long macro arguments passed on >> > (no matter whether to a function, a macro, or like used here) don't >> > need parenthesizing? >> > >> >> That applies to all outermost macro invocations, but not to the >> innermost one. > > I don't understand what you mean. Maybe a couple of trivial examples > would help. > > >> If you want also aggregate initalizers to be deviated, that could be >> done >> (provided that the macro arg is not included in some expression, such >> as >> "{..., e1 + 1, ...}" > Sorry for the late reply. This is the current state: #define N(x) somestruct var = {..., x, ...}; // <- not deviated, violation here #define M(x) N(x) // <- deviated, no violation here ... M(0xff); The violation is resolved by {..., (x), ...} or by saying that when "x" is a whole expression in its fully expanded form, then we allow it not to be needlessly parenthesized, as Jan requested (unless I misunderstood his reply). In that case, the only this that would still give a violation in the above setting is questionable patterns such as #define Q(x) x, x > My gut feeling tells me that probably this is what we want but I'd > rather first understand exactly what you meant above -- Nicola Vetrini, BSc Software Engineer, BUGSENG srl (https://bugseng.com) From xen-devel-bounces@lists.xenproject.org Tue Mar 05 10:23:40 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 10:23:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688703.1073166 (Exim 4.92) (envelope-from ) id 1rhRxT-0005rN-El; Tue, 05 Mar 2024 10:23:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688703.1073166; Tue, 05 Mar 2024 10:23:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhRxT-0005rG-Br; Tue, 05 Mar 2024 10:23:39 +0000 Received: by outflank-mailman (input) for mailman id 688703; Tue, 05 Mar 2024 10:23:38 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhRxS-0005r6-Bm for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 10:23:38 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 6db66b2e-dada-11ee-afda-a90da7624cb6; Tue, 05 Mar 2024 11:23:37 +0100 (CET) Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) by support.bugseng.com (Postfix) with ESMTPA id 37CF24EE0737; Tue, 5 Mar 2024 11:23:37 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6db66b2e-dada-11ee-afda-a90da7624cb6 MIME-Version: 1.0 Date: Tue, 05 Mar 2024 11:23:37 +0100 From: Nicola Vetrini To: Stefano Stabellini Cc: xen-devel@lists.xenproject.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, consulting@bugseng.com, jbeulich@suse.com, andrew.cooper3@citrix.com, roger.pau@citrix.com, bertrand.marquis@arm.com, julien@xen.org, Rahul Singh , Volodymyr Babchuk Subject: Re: [XEN PATCH 06/10] arm/smmu: address some violations of MISRA C Rule 20.7 In-Reply-To: References: <8bbf294d832b973648e84e5d837b1878a84f7645.1709219010.git.nicola.vetrini@bugseng.com> Message-ID: X-Sender: nicola.vetrini@bugseng.com Organization: BUGSENG s.r.l. Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 2024-02-29 23:53, Stefano Stabellini wrote: > On Thu, 29 Feb 2024, Nicola Vetrini wrote: >> MISRA C Rule 20.7 states: "Expressions resulting from the expansion >> of macro parameters shall be enclosed in parentheses". Therefore, some >> macro definitions should gain additional parentheses to ensure that >> all >> current and future users will be safe with respect to expansions that >> can possibly alter the semantics of the passed-in macro parameter. >> >> No functional change. >> >> Signed-off-by: Nicola Vetrini >> --- >> xen/drivers/passthrough/arm/smmu.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/xen/drivers/passthrough/arm/smmu.c >> b/xen/drivers/passthrough/arm/smmu.c >> index 625ed0e41961..83196057a937 100644 >> --- a/xen/drivers/passthrough/arm/smmu.c >> +++ b/xen/drivers/passthrough/arm/smmu.c >> @@ -242,7 +242,7 @@ struct arm_smmu_xen_device { >> struct iommu_group *group; >> }; >> >> -#define dev_archdata(dev) ((struct arm_smmu_xen_device *)dev->iommu) >> +#define dev_archdata(dev) ((struct arm_smmu_xen_device >> *)(dev)->iommu) >> #define dev_iommu_domain(dev) (dev_archdata(dev)->domain) >> #define dev_iommu_group(dev) (dev_archdata(dev)->group) > > this is OK > > >> @@ -627,7 +627,7 @@ struct arm_smmu_master_cfg { >> }; >> #define INVALID_SMENDX -1 >> #define for_each_cfg_sme(cfg, i, idx, num) \ >> - for (i = 0; idx = cfg->smendx[i], i < num; ++i) >> + for (i = 0; idx = (cfg)->smendx[i], (i) < (num); ++(i)) > > The first i = 0 is missing parentheses? > Also idx misses parentheses? This is another case where the parentheses around the lhs are deviated currently. It's up to the maintainers to decide whether to add them regardless of that for consistency, or to keep it as is. -- Nicola Vetrini, BSc Software Engineer, BUGSENG srl (https://bugseng.com) From xen-devel-bounces@lists.xenproject.org Tue Mar 05 10:25:08 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 10:25:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688714.1073180 (Exim 4.92) (envelope-from ) id 1rhRyt-0006Si-Q3; Tue, 05 Mar 2024 10:25:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688714.1073180; Tue, 05 Mar 2024 10:25:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhRyt-0006Sb-N1; Tue, 05 Mar 2024 10:25:07 +0000 Received: by outflank-mailman (input) for mailman id 688714; Tue, 05 Mar 2024 10:25:06 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhRys-0005r6-Kc for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 10:25:06 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id a27634e0-dada-11ee-afda-a90da7624cb6; Tue, 05 Mar 2024 11:25:06 +0100 (CET) Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) by support.bugseng.com (Postfix) with ESMTPA id BDBB54EE0737; Tue, 5 Mar 2024 11:25:05 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a27634e0-dada-11ee-afda-a90da7624cb6 MIME-Version: 1.0 Date: Tue, 05 Mar 2024 11:25:05 +0100 From: Nicola Vetrini To: Stefano Stabellini Cc: Julien Grall , Bertrand Marquis , Michal Orzel , xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, consulting@bugseng.com, andrew.cooper3@citrix.com, roger.pau@citrix.com, Volodymyr Babchuk , xen-devel@lists.xenproject.org Subject: Re: [XEN PATCH 02/10] xen/arm: address some violations of MISRA C Rule 20.7 In-Reply-To: References: <905119be-8731-4669-ac7f-c21aed6845dc@suse.com> <7c54b08875406e5b3a61325af124ae7f@bugseng.com> <0aae1c64587cfbc67e81a20b36dd5056@bugseng.com> Message-ID: <1a53d19ab3d901ce82ce391606ffef92@bugseng.com> X-Sender: nicola.vetrini@bugseng.com Organization: BUGSENG s.r.l. Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 2024-03-05 02:43, Stefano Stabellini wrote: > On Mon, 4 Mar 2024, Nicola Vetrini wrote: >> Hi, >> >> as the maintainers of this subsystem, would you prefer Jan's version >> or the >> one in the patch? >> Both are fine w.r.t MISRA Rule 20.7 because the macro arguments >> themselves are >> parenthesized. > > I prefer Jan's version. Thanks for asking Nicola. > Ok, thanks. I'll modify it and keep an eye for possibly additional opinions of other maintainers. > >> > > > --- a/xen/arch/arm/include/asm/vgic-emul.h >> > > > +++ b/xen/arch/arm/include/asm/vgic-emul.h >> > > > @@ -6,11 +6,11 @@ >> > > > * a range of registers >> > > > */ >> > > > >> > > > -#define VREG32(reg) reg ... reg + 3 >> > > > -#define VREG64(reg) reg ... reg + 7 >> > > > +#define VREG32(reg) (reg) ... (reg) + 3 >> > > > +#define VREG64(reg) (reg) ... (reg) + 7 >> > > >> > > #define VREG32(reg) (reg) ... ((reg) + 3) >> > > #define VREG64(reg) (reg) ... ((reg) + 7) >> > > >> > > ? >> > > >> > >> > The outer parentheses are not required, but I can add them if the >> > maintainers share your view. -- Nicola Vetrini, BSc Software Engineer, BUGSENG srl (https://bugseng.com) From xen-devel-bounces@lists.xenproject.org Tue Mar 05 10:26:24 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 10:26:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688719.1073189 (Exim 4.92) (envelope-from ) id 1rhS07-00074G-6g; Tue, 05 Mar 2024 10:26:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688719.1073189; Tue, 05 Mar 2024 10:26:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhS07-000749-45; Tue, 05 Mar 2024 10:26:23 +0000 Received: by outflank-mailman (input) for mailman id 688719; Tue, 05 Mar 2024 10:26:21 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhS05-00073u-SK for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 10:26:21 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id ce94d3d4-dada-11ee-a1ee-f123f15fe8a2; Tue, 05 Mar 2024 11:26:20 +0100 (CET) Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) by support.bugseng.com (Postfix) with ESMTPA id 935DA4EE0737; Tue, 5 Mar 2024 11:26:19 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ce94d3d4-dada-11ee-a1ee-f123f15fe8a2 MIME-Version: 1.0 Date: Tue, 05 Mar 2024 11:26:19 +0100 From: Nicola Vetrini To: Jan Beulich Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, consulting@bugseng.com, andrew.cooper3@citrix.com, roger.pau@citrix.com, bertrand.marquis@arm.com, julien@xen.org, Wei Liu , xen-devel@lists.xenproject.org Subject: Re: [XEN PATCH 03/10] x86: address some violations of MISRA C Rule 20.7 In-Reply-To: References: <3c9e90aaf5dde769b689468fc818e4ae61fa11f3.1709219010.git.nicola.vetrini@bugseng.com> <14d94c7e-7cd4-4508-a74e-eddd6a592219@suse.com> <85c54b2492a87f0538831c8baf5a8c76@bugseng.com> Message-ID: X-Sender: nicola.vetrini@bugseng.com Organization: BUGSENG s.r.l. Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 2024-02-29 18:05, Jan Beulich wrote: > On 29.02.2024 17:45, Nicola Vetrini wrote: >> On 2024-02-29 17:37, Jan Beulich wrote: >>> On 29.02.2024 16:27, Nicola Vetrini wrote: >>>> --- a/xen/arch/x86/include/asm/irq.h >>>> +++ b/xen/arch/x86/include/asm/irq.h >>>> @@ -179,9 +179,9 @@ void cleanup_domain_irq_mapping(struct domain >>>> *d); >>>> void *__ret = radix_tree_lookup(&(d)->arch.hvm.emuirq_pirq, >>>> emuirq);\ >>>> __ret ? radix_tree_ptr_to_int(__ret) : IRQ_UNBOUND; >>>> \ >>>> }) >>>> -#define IRQ_UNBOUND -1 >>>> -#define IRQ_PT -2 >>>> -#define IRQ_MSI_EMU -3 >>>> +#define IRQ_UNBOUND (-1) >>>> +#define IRQ_PT (-2) >>>> +#define IRQ_MSI_EMU (-3) >>>> >>>> bool cpu_has_pending_apic_eoi(void); >>>> >>> >>> I'd be happy to ack this change right away. >>> >>>> --- a/xen/arch/x86/usercopy.c >>>> +++ b/xen/arch/x86/usercopy.c >>>> @@ -106,7 +106,7 @@ unsigned int copy_from_guest_ll(void *to, const >>>> void __user *from, unsigned int >>>> return n; >>>> } >>>> >>>> -#if GUARD(1) + 0 >>>> +#if GUARD((1)) + 0 >>> >>> I don't even understand the need for this one, and nothing is said in >>> the description in that regard. Generally I'm afraid I'm averse to >>> such (seemingly) redundant parentheses in macro invocations. >>> >> >> It's because >> #define UA_KEEP(args...) args >> #define GUARD UA_KEEP >> >> which would expand to #if 1 + 0, while the rule demands #if (1) + 0 >> I did note in the message after --- that I didn't wanna touch UA_KEEP >> so >> I did this instead, which I'm not particularly happy about either. I >> can >> remove this and deviate, there is no other issue with GUARD. > > Or > > #if (GUARD(1) + 0) > > ? To me at least that's quite a bit less odd. But I guess that still > wouldn't satisfy the rule. Perhaps even > > #if (GUARD(1)) + 0 > > would be a little less odd, albeit there I'd already be on the edge. > Sorry for the late reply. I'll split this in v2. Solution #2 seems ok at first glance. -- Nicola Vetrini, BSc Software Engineer, BUGSENG srl (https://bugseng.com) From xen-devel-bounces@lists.xenproject.org Tue Mar 05 10:26:37 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 10:26:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688720.1073199 (Exim 4.92) (envelope-from ) id 1rhS0K-0007PX-Dm; Tue, 05 Mar 2024 10:26:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688720.1073199; Tue, 05 Mar 2024 10:26:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhS0K-0007PO-BB; Tue, 05 Mar 2024 10:26:36 +0000 Received: by outflank-mailman (input) for mailman id 688720; Tue, 05 Mar 2024 10:26:35 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhS0J-00073u-2X for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 10:26:35 +0000 Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [2a00:1450:4864:20::630]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id d67e033d-dada-11ee-a1ee-f123f15fe8a2; Tue, 05 Mar 2024 11:26:33 +0100 (CET) Received: by mail-ej1-x630.google.com with SMTP id a640c23a62f3a-a458b6d9cfeso149291366b.2 for ; Tue, 05 Mar 2024 02:26:33 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id o4-20020a17090611c400b00a458d85f9d9sm1065893eja.142.2024.03.05.02.26.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 Mar 2024 02:26:32 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d67e033d-dada-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709634393; x=1710239193; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=7/rqBa4/qMoI+hdaAUnra3/joT1gvh94hGsQmmJ4oqk=; b=Et03VlktzmHFu3T+CjdMB57bMOWW1GzaYbNk30mNx7f5VEfSenWndTmsGOsi1+ox3+ oK/Egd2ZRBU4/ZwG+xb5KH4Xx6CtyvrmnDiIN1ZF/puqUET0Lrxxg14961NSp4LHGxK0 ZhlaISBlarHuLDxC1vqRTsiwVw0DU1jn513Dm+4iCDvypJ1IKUlEAw4Fx9elksy/B0Ty tj0Gf96w8e3FPYBgo098nAQ/w+Eb6KCU+3TtACFBEx5WIsB1JJNscQLnGAwU4EDRDVbe 5NlpSnie9RpX5gTxDUFdl1WzNR7eQelQe+13XuzAwDzgN9rMG//T+dSUKhmTjCCl1BmY 9kBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709634393; x=1710239193; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=7/rqBa4/qMoI+hdaAUnra3/joT1gvh94hGsQmmJ4oqk=; b=vLQo+86LAItqIQJt0n+1rNNGFXGV9HdVgjldHXnfcWJwLcIR5VtgVz3773zotB+oM7 ZbFtX5wHE1RPIg07Ld1fMP7crpVa924vM+qIqCZxPP2SZYSRIe6IczXFH2heRb/M+ME9 E6cOLoW7f7QeHw9avbdDrueiRYp8Ts1+rrkGaO+iom1bl0PTktj4YdnJa99rklTTh+px e8DoCbUKMN7sB4nBss+QYnwp+mn1BjlIHifxsQYBJeD7+FhkNkjUDYEhg7mA/KQARXVm KRA/b2RG9nNx88uj5jh+PJKkEx3wVw4N1LzfUU+5jAnJZgojy5KgBURdrniPGf80nsIT 7GOg== X-Forwarded-Encrypted: i=1; AJvYcCV6gGQ2n8pTJ9zG7Cb1rhmY3qiXjw96BjlBVlWAytcY6eeTPr0pzBVhwiruVmFiU8x7WJGAehjL1kLZTJu2kN5FBG9jCF4VAAM9KsEBj/o= X-Gm-Message-State: AOJu0YzpWExNF2LZDX7Rw+J5/CASd1YA5gbkDBLz658YmMmP7fYDjLPO rg0rbD09ub8XdD1imigMOMGh/vVrTyj30XPMQ9Quf5ghQ+Zajs0psJ1qs5q1tA== X-Google-Smtp-Source: AGHT+IFtWEnKPumr3vfzU3rW7noykNtvAMT51pEL4kW6LMT/p47V/p5yJonDJ2F8dx02xD02vEZ5Vw== X-Received: by 2002:a17:906:d045:b0:a44:5589:c098 with SMTP id bo5-20020a170906d04500b00a445589c098mr8263548ejb.7.1709634392759; Tue, 05 Mar 2024 02:26:32 -0800 (PST) Message-ID: Date: Tue, 5 Mar 2024 11:26:31 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH 04/10] xen/public: address violations of MISRA C Rule 20.7 Content-Language: en-US To: Nicola Vetrini Cc: michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, consulting@bugseng.com, andrew.cooper3@citrix.com, roger.pau@citrix.com, bertrand.marquis@arm.com, julien@xen.org, George Dunlap , Wei Liu , xen-devel@lists.xenproject.org, Stefano Stabellini References: <0cdc4dc2fcad699a2274277b32de3ee0207d5a2d.1709219010.git.nicola.vetrini@bugseng.com> <82940f688e5a5eee274fa579991ebd15@bugseng.com> <0e131a6795c9d28583e5e8c248843e67@bugseng.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <0e131a6795c9d28583e5e8c248843e67@bugseng.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 05.03.2024 11:21, Nicola Vetrini wrote: > On 2024-02-29 23:49, Stefano Stabellini wrote: >> On Thu, 29 Feb 2024, Nicola Vetrini wrote: >>> On 2024-02-29 17:40, Jan Beulich wrote: >>>> On 29.02.2024 16:27, Nicola Vetrini wrote: >>>>> --- a/xen/include/public/xen.h >>>>> +++ b/xen/include/public/xen.h >>>>> @@ -988,7 +988,7 @@ typedef struct { >>>>> ((b) >> 8) & 0xFF, ((b) >> 0) & 0xFF, \ >>>>> ((c) >> 8) & 0xFF, ((c) >> 0) & 0xFF, \ >>>>> ((d) >> 8) & 0xFF, ((d) >> 0) & 0xFF, \ >>>>> - e1, e2, e3, e4, e5, e6}} >>>>> + (e1), (e2), (e3), (e4), (e5), (e6)}} >>>> >>>> Why? Wasn't it agreed already that long macro arguments passed on >>>> (no matter whether to a function, a macro, or like used here) don't >>>> need parenthesizing? >>>> >>> >>> That applies to all outermost macro invocations, but not to the >>> innermost one. >> >> I don't understand what you mean. Maybe a couple of trivial examples >> would help. >> >> >>> If you want also aggregate initalizers to be deviated, that could be >>> done >>> (provided that the macro arg is not included in some expression, such >>> as >>> "{..., e1 + 1, ...}" >> > > Sorry for the late reply. This is the current state: > > #define N(x) somestruct var = {..., x, ...}; // <- not deviated, > violation here > #define M(x) N(x) // <- deviated, no violation here > > ... > > M(0xff); > > The violation is resolved by {..., (x), ...} or by saying that when "x" > is a whole expression in its fully expanded form, then we allow it not > to be needlessly parenthesized, as Jan requested (unless I misunderstood > his reply). Well, the thing I continue to have trouble with is "fully expanded form". That's not the criteria I'd like to see applied. To me all depends on how the macro is written, not what uses of the macro expand to. > In that case, the only this that would still give a > violation in the above setting is questionable patterns such as > > #define Q(x) x, x Right. #define Q(x) (x, x) ought to be okay though, rule-wise, no matter that it's questionable too. Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 05 11:18:12 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 11:18:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688760.1073310 (Exim 4.92) (envelope-from ) id 1rhSo8-0007u0-AI; Tue, 05 Mar 2024 11:18:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688760.1073310; Tue, 05 Mar 2024 11:18:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhSo8-0007tt-7Y; Tue, 05 Mar 2024 11:18:04 +0000 Received: by outflank-mailman (input) for mailman id 688760; Tue, 05 Mar 2024 11:18:03 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhSo6-0007th-Vh; Tue, 05 Mar 2024 11:18:02 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhSo6-0001pn-Qy; Tue, 05 Mar 2024 11:18:02 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhSo6-000430-I3; Tue, 05 Mar 2024 11:18:02 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rhSo6-0004dG-Hd; Tue, 05 Mar 2024 11:18:02 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=IU1D8t5ud6zSlliRHHPLt/fzO0kwezEydSHyOPNb/JI=; b=TXLJCRsyw19SDRg3efmfY9hzVA jVrZiupU3M5FHS5gWskKkUPYPMNOOh3GdbGNkov+CvSYl/3/ijIWZ+MMPR8/Rfzmpuw6NdOukhcyI kfo5loTqqLd0Hr2jtD/zLIjQKh7sIQyHcVDE2/Uy8Vcb+UtvkfkAx8dZ2stBcauFZOWk=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [ovmf test] 184908: all pass - PUSHED X-Osstest-Versions-This: ovmf=2a0d4a2641a706d6b964dea0c95b1e0362194f57 X-Osstest-Versions-That: ovmf=918288ab5a7c3abe9c58d576ccc0ae32e2c7dea0 From: osstest service owner Date: Tue, 05 Mar 2024 11:18:02 +0000 flight 184908 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/184908/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 2a0d4a2641a706d6b964dea0c95b1e0362194f57 baseline version: ovmf 918288ab5a7c3abe9c58d576ccc0ae32e2c7dea0 Last test of basis 184903 2024-03-04 18:41:12 Z 0 days Testing same since 184908 2024-03-05 09:12:54 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: "Lee, Chun-Yi" Lee, Chun-Yi 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-pvops pass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git 918288ab5a..2a0d4a2641 2a0d4a2641a706d6b964dea0c95b1e0362194f57 -> xen-tested-master From xen-devel-bounces@lists.xenproject.org Tue Mar 05 12:11:37 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 12:11:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688771.1073349 (Exim 4.92) (envelope-from ) id 1rhTds-00084M-Up; Tue, 05 Mar 2024 12:11:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688771.1073349; Tue, 05 Mar 2024 12:11:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhTds-00084F-RY; Tue, 05 Mar 2024 12:11:32 +0000 Received: by outflank-mailman (input) for mailman id 688771; Tue, 05 Mar 2024 12:11:31 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhTdr-0007LZ-06 for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 12:11:31 +0000 Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [2a00:1450:4864:20::632]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 7f3db319-dae9-11ee-a1ee-f123f15fe8a2; Tue, 05 Mar 2024 13:11:29 +0100 (CET) Received: by mail-ej1-x632.google.com with SMTP id a640c23a62f3a-a456ab934eeso256224266b.0 for ; Tue, 05 Mar 2024 04:11:29 -0800 (PST) Received: from andrewcoop.citrite.net (default-46-102-197-194.interdsl.co.uk. [46.102.197.194]) by smtp.gmail.com with ESMTPSA id gg4-20020a170906e28400b00a45b1194dacsm11429ejb.126.2024.03.05.04.11.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Mar 2024 04:11:26 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 7f3db319-dae9-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709640688; x=1710245488; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=oWpJEehPtMQOOKNL57tqrOWjao0ovLuzVCpvgDqElsg=; b=EITX2FJVa2gnDq/9ajeQv79PjPFUeL4L0KCgcKQkGPZeF6nL3CJs/fd0twmNI8WO/o Q89YpwUN+0j3GbwOTE+1CNBzn8RJursVj50gSR/ckv0V9XQZhirLCHldrSIHtibs+Uqy 2zM+QP3PghllzrNu0JJpbkqJWzbeWjQsDZQVA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709640688; x=1710245488; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=oWpJEehPtMQOOKNL57tqrOWjao0ovLuzVCpvgDqElsg=; b=Ggk6bNaoRX2jl+A5wmF0qcs2eerD/MhNCyCeQziRiQLEz9ws410Z0RxvRHdLibLAhZ KVWu5AlnsdByejCXi0jW1PD3jH9A73eP2SBtXd3ZePuOt2sU36SlBeO90M6JqTSsqMRf J9F4M75pXwwjX8VccstAhpJV18TVB4TItYUs3RCgq69ky+OE2cvwwX5ykMQ6SjmHYxY5 FR44ZfTPBNBbCKpOo218BChNh2D75ZxJ78CAIZiet6YiFztghlYkDK05Uwq3rl+biJEb y4B0ELwodTSgyG53Woe9aT48wWQviBBJp7LUMhvBCSxKUti/EGYUQDNvkXCEEghIuoSE 7bxA== X-Gm-Message-State: AOJu0Yw1KuKw0JNX9a1fDocWo/wLKmZYqZVCUQavX42pKzpzTb3b9bvt Gvzu7EnGuBCn2y4zGR7bBCKrPgxIXWZo4mMcEPhkmkcFK3GqXdcJk8ehWsZ1B6XUjHmAaNaOxq+ i X-Google-Smtp-Source: AGHT+IGZeAV7JmDHAFpT5RByDKtjLsj2hMKVaMz3gNdeOh4RUIz2opvOrxF9jr5pTaYTgsS3wc4Zdg== X-Received: by 2002:a17:906:6bd7:b0:a45:aefb:2145 with SMTP id t23-20020a1709066bd700b00a45aefb2145mr322620ejs.29.1709640687910; Tue, 05 Mar 2024 04:11:27 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Konrad Rzeszutek Wilk , Ross Lagerwall , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH 3/3] x86/livepatch: Relax permissions on rodata too Date: Tue, 5 Mar 2024 12:11:21 +0000 Message-Id: <20240305121121.3527944-4-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20240305121121.3527944-1-andrew.cooper3@citrix.com> References: <20240305121121.3527944-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This reinstates the capability to patch .rodata in load/unload hooks, which was lost when we stopped using CR0.WP=0 to patch. This turns out to be rather less of a large TODO than I thought at the time. Fixes: 8676092a0f16 ("x86/livepatch: Fix livepatch application when CET is active") Signed-off-by: Andrew Cooper --- CC: Konrad Rzeszutek Wilk CC: Ross Lagerwall CC: Jan Beulich CC: Roger Pau Monné --- xen/arch/x86/livepatch.c | 4 ++-- xen/common/virtual_region.c | 12 ++++++++++++ 2 files changed, 14 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/livepatch.c b/xen/arch/x86/livepatch.c index ee539f001b73..4f76127e1f77 100644 --- a/xen/arch/x86/livepatch.c +++ b/xen/arch/x86/livepatch.c @@ -62,7 +62,7 @@ int arch_livepatch_safety_check(void) int noinline arch_livepatch_quiesce(void) { /* - * Relax perms on .text to be RWX, so we can modify them. + * Relax perms on .text/.rodata, so we can modify them. * * This relaxes perms globally, but all other CPUs are waiting on us. */ @@ -75,7 +75,7 @@ int noinline arch_livepatch_quiesce(void) void noinline arch_livepatch_revive(void) { /* - * Reinstate perms on .text to be RX. This also cleans out the dirty + * Reinstate perms on .text/.rodata. This also cleans out the dirty * bits, which matters when CET Shstk is active. * * The other CPUs waiting for us could in principle have re-walked while diff --git a/xen/common/virtual_region.c b/xen/common/virtual_region.c index d2efe9e11492..f45812483b8e 100644 --- a/xen/common/virtual_region.c +++ b/xen/common/virtual_region.c @@ -91,9 +91,15 @@ void relax_virtual_region_perms(void) rcu_read_lock(&rcu_virtual_region_lock); list_for_each_entry_rcu( region, &virtual_region_list, list ) + { modify_xen_mappings_lite((unsigned long)region->text_start, PAGE_ALIGN((unsigned long)region->text_end), PAGE_HYPERVISOR_RWX); + if ( region->rodata_start ) + modify_xen_mappings_lite((unsigned long)region->rodata_start, + ROUNDUP((unsigned long)region->rodata_end, PAGE_SIZE), + PAGE_HYPERVISOR_RW); + } rcu_read_unlock(&rcu_virtual_region_lock); } @@ -103,9 +109,15 @@ void tighten_virtual_region_perms(void) rcu_read_lock(&rcu_virtual_region_lock); list_for_each_entry_rcu( region, &virtual_region_list, list ) + { modify_xen_mappings_lite((unsigned long)region->text_start, PAGE_ALIGN((unsigned long)region->text_end), PAGE_HYPERVISOR_RX); + if ( region->rodata_start ) + modify_xen_mappings_lite((unsigned long)region->rodata_start, + ROUNDUP((unsigned long)region->rodata_end, PAGE_SIZE), + PAGE_HYPERVISOR_RO); + } rcu_read_unlock(&rcu_virtual_region_lock); } #endif /* CONFIG_X86 */ -- 2.30.2 From xen-devel-bounces@lists.xenproject.org Tue Mar 05 12:11:37 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 12:11:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688768.1073319 (Exim 4.92) (envelope-from ) id 1rhTdo-0007Ls-9P; Tue, 05 Mar 2024 12:11:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688768.1073319; Tue, 05 Mar 2024 12:11:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhTdo-0007Lk-6n; Tue, 05 Mar 2024 12:11:28 +0000 Received: by outflank-mailman (input) for mailman id 688768; Tue, 05 Mar 2024 12:11:26 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhTdm-0007LZ-NU for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 12:11:26 +0000 Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [2a00:1450:4864:20::532]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 7c7236b5-dae9-11ee-a1ee-f123f15fe8a2; Tue, 05 Mar 2024 13:11:24 +0100 (CET) Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-565c6cf4819so11057987a12.1 for ; Tue, 05 Mar 2024 04:11:24 -0800 (PST) Received: from andrewcoop.citrite.net (default-46-102-197-194.interdsl.co.uk. [46.102.197.194]) by smtp.gmail.com with ESMTPSA id gg4-20020a170906e28400b00a45b1194dacsm11429ejb.126.2024.03.05.04.11.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Mar 2024 04:11:23 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 7c7236b5-dae9-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709640684; x=1710245484; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=f2ZND4JB6JB7qPw7eT3278I+2BCpLYACdoJCu9lm2BY=; b=p+bRHPQhZSm7fhLtGTQ0ejCkCuTHMrQKIg3B7m4M7RftdD4Ncpgh5X/RSbTsLZzTBH 2Ba1IbL3YP2ePt0VQx0iUrcRh4abuuG2jtmGa8NnMFKXGnjUeZTWGiwbfI9slQHIyju6 aLM8AeZ5xej3wp5XeqY9sUVPdSkIncDhij+R0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709640684; x=1710245484; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=f2ZND4JB6JB7qPw7eT3278I+2BCpLYACdoJCu9lm2BY=; b=cl9lm5bdBfgs4TgodOtQWhkiwGZH1NjmqDpk1hABPoukoc8l71oBBXffyI4/eYpHjR vlP/jYLf8U4EXyhuKbm/jSQuOuhlHrkvCU7tIiJqpFVPVLDzZdMQ4aiImrW0NpQiA+oh ZILicidaWwsHtmEpKGMvmI6tVQ0blYvUHIRm/Hrhz9l8WCQF5dmJCTWhoggO3npsaZLj WXgKtk5+ddROq6S2aB8DMBOcgN5r5t883ilUZlM8Zof/esWaEqhF7UMgpQqnJE2onKZP QFGiajBw6WP4Zzn28Oq4xOptMLpQ+7CryyjAwjjjyeuBG3lmRLrw+F6b6KG35H1JhuCu yqhg== X-Gm-Message-State: AOJu0YzD7chlMknGjbYhku+7pONlNsTrQWvLBkbxwm9/hVvai626eFzD q+J4fkb3vZhue1LzZo5LQW0KAqSwh8CqQ3dEgNAczZVZqD6C7dAbskkObgajLHcAV0dy4QeSosE c X-Google-Smtp-Source: AGHT+IGc4cZT9A/xbWBeAKYKw2cx50WBdiu4NFhYnOjLmHXlvdj0/HnWU/d+1FKwLzn+VrnzAj3BVA== X-Received: by 2002:a17:906:4ac4:b0:a44:52ec:b9e7 with SMTP id u4-20020a1709064ac400b00a4452ecb9e7mr2260939ejt.16.1709640683789; Tue, 05 Mar 2024 04:11:23 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Konrad Rzeszutek Wilk , Ross Lagerwall , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH 0/3] x86/livepatch: Reinstate the ability to patch .rodata Date: Tue, 5 Mar 2024 12:11:18 +0000 Message-Id: <20240305121121.3527944-1-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This capability was lost when fixing liveaptching vs CET, with a TODO to fix... Testing (In progress): https://gitlab.com/xen-project/people/andyhhp/xen/-/pipelines/1201429148 https://cirrus-ci.com/build/5510098735333376 Andrew Cooper (3): xen/virtual-region: Rename start/end fields xen/virtual-region: Include rodata pointers x86/livepatch: Relax permissions on rodata too xen/arch/x86/livepatch.c | 4 ++-- xen/common/livepatch.c | 10 ++++++++-- xen/common/virtual_region.c | 33 +++++++++++++++++++++++--------- xen/include/xen/virtual_region.h | 8 ++++++-- 4 files changed, 40 insertions(+), 15 deletions(-) base-commit: fc84b4a5a37b9250d87ef63983b48e1953bba6d1 -- 2.30.2 From xen-devel-bounces@lists.xenproject.org Tue Mar 05 12:11:37 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 12:11:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688770.1073340 (Exim 4.92) (envelope-from ) id 1rhTdq-0007oF-NV; Tue, 05 Mar 2024 12:11:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688770.1073340; Tue, 05 Mar 2024 12:11:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhTdq-0007o8-Jy; Tue, 05 Mar 2024 12:11:30 +0000 Received: by outflank-mailman (input) for mailman id 688770; Tue, 05 Mar 2024 12:11:28 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhTdo-0007Lm-SV for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 12:11:28 +0000 Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [2a00:1450:4864:20::533]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 7e1e1807-dae9-11ee-afda-a90da7624cb6; Tue, 05 Mar 2024 13:11:27 +0100 (CET) Received: by mail-ed1-x533.google.com with SMTP id 4fb4d7f45d1cf-564372fb762so7173760a12.0 for ; Tue, 05 Mar 2024 04:11:27 -0800 (PST) Received: from andrewcoop.citrite.net (default-46-102-197-194.interdsl.co.uk. [46.102.197.194]) by smtp.gmail.com with ESMTPSA id gg4-20020a170906e28400b00a45b1194dacsm11429ejb.126.2024.03.05.04.11.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Mar 2024 04:11:25 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 7e1e1807-dae9-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709640686; x=1710245486; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=TlpNxqFoSSL8NwQwwcPUu6ZlDVgEwc5H6nYzlIRPqfQ=; b=Cz7201utjqDyr5WU93gcP0Tsqi5T5JHC4DvXtJIcVtnweOj1aRX3Kzsj5RjuzUGI1o PwLEvzUCmCdo/OjjsuuunhQQG3DZr1MHX7fIfh+3L0rWYrLWBA2Fl+ZFNM/PNHt/tx4Y GX3li/q9A6a115XguLgmoY0kOyVQWS4nmmTZQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709640686; x=1710245486; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=TlpNxqFoSSL8NwQwwcPUu6ZlDVgEwc5H6nYzlIRPqfQ=; b=AVdmAmO6z4j4dgNco1hUamWwa0sU5WoX1knf1bpwkLsUi7gHMnsbJ4Xq3PPAS4ekak PvfYAVvnoNNrpBxHZtjlw0Rb7KZsQKkNKH6Iwfq7XWwuThbILFlCZrI8i0+PF1bM8Jpu uzxAewSLVTGSEJUISiqh8pAqNtBloDCGRhajTFSemr/CNDACpVr4BN95UaHISCRt4aTm cwI8lDUMzdXsn7XsQ/IQ/Y7R8Vuzx5YbNgamQTIX4wgnGH2nB/PvCkzdVSvCvwFtdNQP xe/eCrlAB2HVui3dMUXzL9NQxF/lM1aDsciagXGz6nKDbLNauQuOaqxO9/n4PMyev9yk /IkQ== X-Gm-Message-State: AOJu0YzkBtt/UcHzZEvsFp91a2+1moQ37UzIN7edjhsrxRtgsKkBNxmm ALR3BVfS4KhmLVDNQ3IzTjo15zr2U4jpJnE2Hhv53+tHpS3oQSRBB/hktqDUyVqN1X2BCuzv+dV E X-Google-Smtp-Source: AGHT+IGKF7MVptTJX8bpq+u++FqTm0yMW4c9pc8bxMUAAdOp88S7xT4NB26ZY7rr8aWOTnoRyXfkKA== X-Received: by 2002:a17:906:408d:b0:a45:69f5:c3c9 with SMTP id u13-20020a170906408d00b00a4569f5c3c9mr3304715ejj.6.1709640686294; Tue, 05 Mar 2024 04:11:26 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Konrad Rzeszutek Wilk , Ross Lagerwall , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH 2/3] xen/virtual-region: Include rodata pointers Date: Tue, 5 Mar 2024 12:11:20 +0000 Message-Id: <20240305121121.3527944-3-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20240305121121.3527944-1-andrew.cooper3@citrix.com> References: <20240305121121.3527944-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit These are optional. .init doesn't distinguish types of data like this, and livepatches don't necesserily have any .rodata either. No functional change. Signed-off-by: Andrew Cooper --- CC: Konrad Rzeszutek Wilk CC: Ross Lagerwall CC: Jan Beulich CC: Roger Pau Monné --- xen/common/livepatch.c | 6 ++++++ xen/common/virtual_region.c | 2 ++ xen/include/xen/virtual_region.h | 3 +++ 3 files changed, 11 insertions(+) diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c index 888beb273244..cabfb6391117 100644 --- a/xen/common/livepatch.c +++ b/xen/common/livepatch.c @@ -788,6 +788,12 @@ static int prepare_payload(struct payload *payload, region->text_start = payload->text_addr; region->text_end = payload->text_addr + payload->text_size; + if ( payload->ro_size ) + { + region->rodata_start = payload->ro_addr; + region->rodata_end = payload->ro_addr + payload->ro_size; + } + /* Optional sections. */ for ( i = 0; i < BUGFRAME_NR; i++ ) { diff --git a/xen/common/virtual_region.c b/xen/common/virtual_region.c index b74030d70065..d2efe9e11492 100644 --- a/xen/common/virtual_region.c +++ b/xen/common/virtual_region.c @@ -13,6 +13,8 @@ static struct virtual_region core = { .list = LIST_HEAD_INIT(core.list), .text_start = _stext, .text_end = _etext, + .rodata_start = _srodata, + .rodata_end = _erodata, }; /* Becomes irrelevant when __init sections are cleared. */ diff --git a/xen/include/xen/virtual_region.h b/xen/include/xen/virtual_region.h index c76e7d7932ff..7712f6ad3632 100644 --- a/xen/include/xen/virtual_region.h +++ b/xen/include/xen/virtual_region.h @@ -16,6 +16,9 @@ struct virtual_region const void *text_start; /* .text virtual address start. */ const void *text_end; /* .text virtual address end. */ + const void *rodata_start; /* .rodata virtual address start (optional). */ + const void *rodata_end; /* .rodata virtual address end. */ + /* If this is NULL the default lookup mechanism is used. */ symbols_lookup_t *symbols_lookup; -- 2.30.2 From xen-devel-bounces@lists.xenproject.org Tue Mar 05 12:11:37 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 12:11:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688769.1073324 (Exim 4.92) (envelope-from ) id 1rhTdo-0007Oj-Gj; Tue, 05 Mar 2024 12:11:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688769.1073324; Tue, 05 Mar 2024 12:11:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhTdo-0007NG-Cn; Tue, 05 Mar 2024 12:11:28 +0000 Received: by outflank-mailman (input) for mailman id 688769; Tue, 05 Mar 2024 12:11:27 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhTdn-0007LZ-Fl for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 12:11:27 +0000 Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [2a00:1450:4864:20::635]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 7d2d291d-dae9-11ee-a1ee-f123f15fe8a2; Tue, 05 Mar 2024 13:11:25 +0100 (CET) Received: by mail-ej1-x635.google.com with SMTP id a640c23a62f3a-a45a15f2bafso74917266b.0 for ; Tue, 05 Mar 2024 04:11:25 -0800 (PST) Received: from andrewcoop.citrite.net (default-46-102-197-194.interdsl.co.uk. [46.102.197.194]) by smtp.gmail.com with ESMTPSA id gg4-20020a170906e28400b00a45b1194dacsm11429ejb.126.2024.03.05.04.11.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Mar 2024 04:11:24 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 7d2d291d-dae9-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709640685; x=1710245485; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=PYhS+zW0jQOXj6T42uFUoaBTcCdbr7cDELY4xsIeX+0=; b=Qms27CZ2ENS6dBrvfKSWqb4oPJieyU6ihDFHRlBRfUB/g6iftqwh2wgJg/9jxQON8o ZYDsyXNfFgKGTKdsKWo6A6s7Hy3haQUumZS2wie+ufp88rdYsH7DLokJcVhJ/w2thZIV nCF5VkHpb/VAcMMVh3ABTYHFRDoKyTE1wG0rg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709640685; x=1710245485; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=PYhS+zW0jQOXj6T42uFUoaBTcCdbr7cDELY4xsIeX+0=; b=u2VluPVt9osoClaR8HVxb2rTMyXA4c1troXWc24DA7gcv9dHxcN4OtNcurJR/x/uVb 1yEobwgthHFfWIAemcG4HJ4h+GN4UMJR5LP3SPXdhnExIvYwCb+BGmGHkl3UJ5V0Wfiy 9vE/g8cQ4FmJ49o9wLrAg2tMxecvuiqI4F+TrL+iDfuTFSnIsUbl4HEZWQ/DAsUMsG5q aDC0hOBGkfEOfBD7BkYX2UK+iDLpn2D39IQYg4n311OygzuiSHTQMPv7HyurQFSZtF9L 5+MKdzHzIK/MJ9PPSIPQZpawM4ak/syiJIGF2aocD7cEq3vy6DFIcU6UxxmbWZ5sNhxi Jwug== X-Gm-Message-State: AOJu0YzG7Hxe5Z6S+8lw61LnfjdhsaNtmDpcG8Y6hywD4w9otxfVrb6X Qk1xoOgAdmdpFQ8EqvTgZlkqm5zWOUFUxsC3/ndhxXG4LSCu7xz5GRM0svSw6OjF6l8xCBtiTei E X-Google-Smtp-Source: AGHT+IFKUyzpwhCGvtaIMMqNDhJ0YRjW8uNvEgiydyOBwEO+msMV0to3klQOpaGxv6joRGhIOplAaQ== X-Received: by 2002:a17:906:d209:b0:a44:5927:3e67 with SMTP id w9-20020a170906d20900b00a4459273e67mr9061563ejz.23.1709640685070; Tue, 05 Mar 2024 04:11:25 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Konrad Rzeszutek Wilk , Ross Lagerwall , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH 1/3] xen/virtual-region: Rename start/end fields Date: Tue, 5 Mar 2024 12:11:19 +0000 Message-Id: <20240305121121.3527944-2-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20240305121121.3527944-1-andrew.cooper3@citrix.com> References: <20240305121121.3527944-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit ... to text_{start,end}. We're about to introduce another start/end pair. As minor cleanup, replace ROUNDUP(x, PAGE_SIZE) with the more consice PAGE_ALIGN() ahead of duplicating the example. No functional change. Signed-off-by: Andrew Cooper --- CC: Konrad Rzeszutek Wilk CC: Ross Lagerwall CC: Jan Beulich CC: Roger Pau Monné --- xen/common/livepatch.c | 4 ++-- xen/common/virtual_region.c | 19 ++++++++++--------- xen/include/xen/virtual_region.h | 5 +++-- 3 files changed, 15 insertions(+), 13 deletions(-) diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c index 5a7d5b7be0ad..888beb273244 100644 --- a/xen/common/livepatch.c +++ b/xen/common/livepatch.c @@ -785,8 +785,8 @@ static int prepare_payload(struct payload *payload, region = &payload->region; region->symbols_lookup = livepatch_symbols_lookup; - region->start = payload->text_addr; - region->end = payload->text_addr + payload->text_size; + region->text_start = payload->text_addr; + region->text_end = payload->text_addr + payload->text_size; /* Optional sections. */ for ( i = 0; i < BUGFRAME_NR; i++ ) diff --git a/xen/common/virtual_region.c b/xen/common/virtual_region.c index cefef3e47e73..b74030d70065 100644 --- a/xen/common/virtual_region.c +++ b/xen/common/virtual_region.c @@ -11,15 +11,15 @@ static struct virtual_region core = { .list = LIST_HEAD_INIT(core.list), - .start = _stext, - .end = _etext, + .text_start = _stext, + .text_end = _etext, }; /* Becomes irrelevant when __init sections are cleared. */ static struct virtual_region core_init __initdata = { .list = LIST_HEAD_INIT(core_init.list), - .start = _sinittext, - .end = _einittext, + .text_start = _sinittext, + .text_end = _einittext, }; /* @@ -39,7 +39,8 @@ const struct virtual_region *find_text_region(unsigned long addr) rcu_read_lock(&rcu_virtual_region_lock); list_for_each_entry_rcu ( iter, &virtual_region_list, list ) { - if ( (void *)addr >= iter->start && (void *)addr < iter->end ) + if ( (void *)addr >= iter->text_start && + (void *)addr < iter->text_end ) { region = iter; break; @@ -88,8 +89,8 @@ void relax_virtual_region_perms(void) rcu_read_lock(&rcu_virtual_region_lock); list_for_each_entry_rcu( region, &virtual_region_list, list ) - modify_xen_mappings_lite((unsigned long)region->start, - ROUNDUP((unsigned long)region->end, PAGE_SIZE), + modify_xen_mappings_lite((unsigned long)region->text_start, + PAGE_ALIGN((unsigned long)region->text_end), PAGE_HYPERVISOR_RWX); rcu_read_unlock(&rcu_virtual_region_lock); } @@ -100,8 +101,8 @@ void tighten_virtual_region_perms(void) rcu_read_lock(&rcu_virtual_region_lock); list_for_each_entry_rcu( region, &virtual_region_list, list ) - modify_xen_mappings_lite((unsigned long)region->start, - ROUNDUP((unsigned long)region->end, PAGE_SIZE), + modify_xen_mappings_lite((unsigned long)region->text_start, + PAGE_ALIGN((unsigned long)region->text_end), PAGE_HYPERVISOR_RX); rcu_read_unlock(&rcu_virtual_region_lock); } diff --git a/xen/include/xen/virtual_region.h b/xen/include/xen/virtual_region.h index d05362071135..c76e7d7932ff 100644 --- a/xen/include/xen/virtual_region.h +++ b/xen/include/xen/virtual_region.h @@ -12,8 +12,9 @@ struct virtual_region { struct list_head list; - const void *start; /* Virtual address start. */ - const void *end; /* Virtual address end. */ + + const void *text_start; /* .text virtual address start. */ + const void *text_end; /* .text virtual address end. */ /* If this is NULL the default lookup mechanism is used. */ symbols_lookup_t *symbols_lookup; -- 2.30.2 From xen-devel-bounces@lists.xenproject.org Tue Mar 05 12:11:46 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 12:11:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688772.1073360 (Exim 4.92) (envelope-from ) id 1rhTe6-0000Ax-77; Tue, 05 Mar 2024 12:11:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688772.1073360; Tue, 05 Mar 2024 12:11:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhTe6-0000Ao-3p; Tue, 05 Mar 2024 12:11:46 +0000 Received: by outflank-mailman (input) for mailman id 688772; Tue, 05 Mar 2024 12:11:45 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhTe5-00007V-0C; Tue, 05 Mar 2024 12:11:45 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhTe4-0002zy-Qt; Tue, 05 Mar 2024 12:11:44 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhTe4-0005go-HU; Tue, 05 Mar 2024 12:11:44 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rhTe4-0004ji-Gy; Tue, 05 Mar 2024 12:11:44 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=BmnI2F00p9fgF5RXAsZGiNT/vnVj8hgJMdFAP8305DY=; b=SKMsRLEB+26wbfFayV+xJ5kIvu 4wU0QzL8ocG5n0/h8x/jvHsjlDJkCnZcErf8mG35cUscgZI3cPUpHgoTRyGZouq6NUEXkTikVXCg8 j9pTKBU6+WllYRch3BAdYqWktWm0E4Q8Xnfi9irviDTSgZiNIFUiXTR6NMcLBJHEJGVI=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable test] 184907: tolerable FAIL X-Osstest-Failures: xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:windows-install:fail:heisenbug xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: xen=fc84b4a5a37b9250d87ef63983b48e1953bba6d1 X-Osstest-Versions-That: xen=fc84b4a5a37b9250d87ef63983b48e1953bba6d1 From: osstest service owner Date: Tue, 05 Mar 2024 12:11:44 +0000 flight 184907 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/184907/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 12 windows-install fail pass in 184905 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop fail in 184905 blocked in 184907 test-armhf-armhf-libvirt 16 saverestore-support-check fail like 184905 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop fail like 184905 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 184905 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop fail like 184905 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 184905 test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail like 184905 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 184905 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop fail like 184905 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 184905 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184905 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 184905 test-amd64-amd64-libvirt-xsm 15 migrate-support-check fail never pass test-amd64-i386-xl-pvshim 14 guest-start fail never pass test-amd64-i386-libvirt 15 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-check fail never pass test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-check fail never pass test-arm64-arm64-xl 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 15 migrate-support-check fail never pass test-arm64-arm64-xl 16 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 15 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-check fail never pass test-armhf-armhf-libvirt 15 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-check fail never pass test-amd64-i386-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-check fail never pass test-arm64-arm64-xl-vhd 14 migrate-support-check fail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-check fail never pass version targeted for testing: xen fc84b4a5a37b9250d87ef63983b48e1953bba6d1 baseline version: xen fc84b4a5a37b9250d87ef63983b48e1953bba6d1 Last test of basis 184907 2024-03-05 05:10:00 Z 0 days Testing same since (not found) 0 attempts jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-dom0pvh-xl-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-qemuu-freebsd11-amd64 pass test-amd64-amd64-qemuu-freebsd12-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-examine-bios pass test-amd64-i386-examine-bios pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-dom0pvh-xl-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-armhf-armhf-libvirt-qcow2 pass test-amd64-amd64-xl-qcow2 pass test-arm64-arm64-libvirt-raw pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-libvirt-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-examine-uefi pass test-amd64-i386-examine-uefi pass test-amd64-amd64-libvirt-vhd pass test-arm64-arm64-xl-vhd pass test-armhf-armhf-xl-vhd pass test-amd64-i386-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these 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 Published tested tree is already up to date. From xen-devel-bounces@lists.xenproject.org Tue Mar 05 12:21:30 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 12:21:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688785.1073369 (Exim 4.92) (envelope-from ) id 1rhTnS-00036h-7G; Tue, 05 Mar 2024 12:21:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688785.1073369; Tue, 05 Mar 2024 12:21:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhTnS-00036a-4i; Tue, 05 Mar 2024 12:21:26 +0000 Received: by outflank-mailman (input) for mailman id 688785; Tue, 05 Mar 2024 12:21:24 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhTnQ-00036E-H2 for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 12:21:24 +0000 Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [2a00:1450:4864:20::533]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id e1c3cc7c-daea-11ee-afda-a90da7624cb6; Tue, 05 Mar 2024 13:21:24 +0100 (CET) Received: by mail-ed1-x533.google.com with SMTP id 4fb4d7f45d1cf-56682b85220so8930555a12.1 for ; Tue, 05 Mar 2024 04:21:24 -0800 (PST) Received: from andrewcoop.citrite.net (default-46-102-197-194.interdsl.co.uk. [46.102.197.194]) by smtp.gmail.com with ESMTPSA id d17-20020a056402517100b005671100145dsm3559454ede.55.2024.03.05.04.21.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Mar 2024 04:21:22 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e1c3cc7c-daea-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709641283; x=1710246083; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=e3i4C+xzhxQOm5TomDZOcoUjBDYeat+d4hlJTa4Id/Q=; b=QiPnIF2i/WIkG+pSOtsHTLcU5YYzAo3RLG4iG0T1OnbVgYtxI0U0nK6zacLkFuaE5x ktIABviXw/y8/HT408mk/jXgWr+vVQnt4qWyoVFZEDdoNuQ+AgCx9U007ppUFtX4SozT MkHONaPR3saUtGl1jjYHAGSTUT/hBvBrqT1r4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709641283; x=1710246083; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=e3i4C+xzhxQOm5TomDZOcoUjBDYeat+d4hlJTa4Id/Q=; b=T3LWkcP7gcKlI9IXoccUKMpzOO/HViAJj1nD6P04EKO6xDHnaS0wm11RKupy4TYSxW /HqH+eAWVRO3qkL4yoEMqa+/reuHknj2zYK2Xj/lKrVUM8dNzhOEqmjUuKaP5kXaNs27 fckXcjYSmr7Dz2A/d4aJsRq0xRUl2CD7nyZj/a+B3GS6DVgRR/GHIylhNgGl561hZzS1 RMKdIDSc0PuAkGYiMQGVH7WcdDJlC0DcDpAGqfAVL0/d3lqubIDOXBmAT8566C6kTyay ijxla/Grg4FoMFBUeQ81AmlH7TeZqY2FcbjxZTJUoRgACKsoqv4EX6Gq6AhghGcFBFDX dXLw== X-Gm-Message-State: AOJu0Yx9pdQ37/q5GKYapCtsR72xNSkqNduZT/E17IvpmbkZBT2V9oR/ J53PJ+7IbHuok/Gd+cxHLyzUPuHP5TSvFxNd7HJBSp25mHMZGN4aZD+7BUj8y+kzh+i5w22F6Qj D X-Google-Smtp-Source: AGHT+IFynhTQKYhGLVqq9tzOLefAbg6pvPdrY7Js09ndbbQRoPATwuZA5uMChfo/Z/iZi0Iyg0pr1A== X-Received: by 2002:a05:6402:3d5:b0:567:6c77:dd43 with SMTP id t21-20020a05640203d500b005676c77dd43mr2764585edw.18.1709641282826; Tue, 05 Mar 2024 04:21:22 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Oleksii Kurochko , Shawn Anastasio Subject: [PATCH] xen/{RISCV,PPC}/xen.lds: Delete duplicate _erodata definitions Date: Tue, 5 Mar 2024 12:21:21 +0000 Message-Id: <20240305122121.3529541-1-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit This is bad copy/paste from somewhere. Retain the second _erodata symbol, which follows the Build ID, and matches the other architectures. No functional change. Signed-off-by: Andrew Cooper --- CC: Oleksii Kurochko CC: Shawn Anastasio --- xen/arch/ppc/xen.lds.S | 1 - xen/arch/riscv/xen.lds.S | 1 - 2 files changed, 2 deletions(-) diff --git a/xen/arch/ppc/xen.lds.S b/xen/arch/ppc/xen.lds.S index 030e1ee37b55..05b6db272805 100644 --- a/xen/arch/ppc/xen.lds.S +++ b/xen/arch/ppc/xen.lds.S @@ -60,7 +60,6 @@ SECTIONS VPCI_ARRAY . = ALIGN(POINTER_ALIGN); - _erodata = .; /* End of read-only data */ } :text #if defined(BUILD_ID) diff --git a/xen/arch/riscv/xen.lds.S b/xen/arch/riscv/xen.lds.S index 8510a87c4d06..ace6f49c579c 100644 --- a/xen/arch/riscv/xen.lds.S +++ b/xen/arch/riscv/xen.lds.S @@ -60,7 +60,6 @@ SECTIONS VPCI_ARRAY . = ALIGN(POINTER_ALIGN); - _erodata = .; /* End of read-only data */ } :text #if defined(BUILD_ID) base-commit: fc84b4a5a37b9250d87ef63983b48e1953bba6d1 prerequisite-patch-id: b14999775a3dc222f2f94d7d5d7a1db377de9cb9 prerequisite-patch-id: 00650d75df673992b4c8cb6d7ac61dab72b9b309 prerequisite-patch-id: 5464f5f1e7448cde38749a3744c9e74708727dee -- 2.30.2 From xen-devel-bounces@lists.xenproject.org Tue Mar 05 12:44:38 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 12:44:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688789.1073380 (Exim 4.92) (envelope-from ) id 1rhU9k-0006n9-VF; Tue, 05 Mar 2024 12:44:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688789.1073380; Tue, 05 Mar 2024 12:44:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhU9k-0006n2-RA; Tue, 05 Mar 2024 12:44:28 +0000 Received: by outflank-mailman (input) for mailman id 688789; Tue, 05 Mar 2024 12:44:28 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhU9k-0006mw-6D for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 12:44:28 +0000 Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [2a00:1450:4864:20::634]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 18c3f1f0-daee-11ee-a1ee-f123f15fe8a2; Tue, 05 Mar 2024 13:44:25 +0100 (CET) Received: by mail-ej1-x634.google.com with SMTP id a640c23a62f3a-a44f2d894b7so366544066b.1 for ; Tue, 05 Mar 2024 04:44:25 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id bo12-20020a170906d04c00b00a456f7628b7sm1792661ejb.27.2024.03.05.04.44.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 Mar 2024 04:44:23 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 18c3f1f0-daee-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709642664; x=1710247464; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=5i43aPJbdQgCLS7XtGHNgI9d3EjgkyrrCs5IB75O0us=; b=NvTR64+Vu1ln8dpDek+Grmy8VadKYwevuJqwjkTzT+oPMh76IkXWvOK5SgQPvSrRKi UcM8Jkjwd4VvkntQearDZnqAT2ksNJbrWfneAAhvJfGzVei3qC/1crwed4YaQUk/MCuB xwUqbKr/K6k/ahyiqwlUVXC5MNEeY0CNICShIJ/gzDk5PwVvvUdHpzmQcUMWB4o/tzUw obE57MzjHlKQMTvtSlyZogB1cCJEpjkdmk5zZtolaci3IFY/Zh67O0rxlLu57FWKf6Sz SdcMfI0PP9dOtPc8gkZSUJHLvTYyqx1q3VZ+PL2/5vgkYEgNReOttvJGcULhR/UKVRuY +MqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709642664; x=1710247464; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=5i43aPJbdQgCLS7XtGHNgI9d3EjgkyrrCs5IB75O0us=; b=j4l6/Mc55TIxwURB943y9huZkl3ZmyAgX6UC0ihWfrdPhGVQeQYMK7+fl2mGWRTrcD uqXvryAfappA0dbL11OeEUFKoLF4LavptrdV0qVVxBcMp9Zr2dATJ6vefCS31cd/aae1 Er/Y4fxMSbv8xhW+xgR6kZcgXt0XvaZ7WtwyCe0HrUVuCa3Tntmx2fKU2bCga+bEy0tY j2a6PjlIhrxF3kbKBSYo28FMmXRXAwfP4WcQDvqmMxZhYth2tAyALou23ubp2ghB+rVM m1dLoSIM/zBLl+qgwAQPJaObjpsTf9LVZym/ma67ZWQklQ00aUQgx4iXCvraIP40+dHL ImWQ== X-Forwarded-Encrypted: i=1; AJvYcCXPPp5CX8UtPnvwM54A2EPmkRkxVpMie+5o/IvG5FXaYZih7h9KJRdgtFvNbwXlR7Uwjw9bFil9tuS8+knA1X4pzGtjgrAjkn/Fqhn7l6E= X-Gm-Message-State: AOJu0YwsJptuXh3h+6t2go8xiUeNElNyt3Qxsc8RYvb5qUiXI40JMSFf q8I5t4iJuOobqSGpRLdCa3k6SoRcwiU+xAl9SvADGEyCWU257znwgh4dBuWGRQ== X-Google-Smtp-Source: AGHT+IHkO9vyaF0Q5PjcIxBVatSZEhBRlhB7Q3Kdv4XbFIOwDujuUEMTWQCsQ8V/ptixQfkNhVD6Lg== X-Received: by 2002:a17:906:a3cf:b0:a45:16af:bda1 with SMTP id ca15-20020a170906a3cf00b00a4516afbda1mr4456493ejb.12.1709642664297; Tue, 05 Mar 2024 04:44:24 -0800 (PST) Message-ID: Date: Tue, 5 Mar 2024 13:44:23 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/{RISCV,PPC}/xen.lds: Delete duplicate _erodata definitions Content-Language: en-US To: Andrew Cooper Cc: Oleksii Kurochko , Shawn Anastasio , Xen-devel References: <20240305122121.3529541-1-andrew.cooper3@citrix.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20240305122121.3529541-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 05.03.2024 13:21, Andrew Cooper wrote: > This is bad copy/paste from somewhere. Retain the second _erodata symbol, > which follows the Build ID, and matches the other architectures. > > No functional change. I.e. the 2nd one took effect? (To be honest I'm surprised the linker didn't complain about a duplicate symbol there.) > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Tue Mar 05 13:00:09 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 13:00:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688792.1073390 (Exim 4.92) (envelope-from ) id 1rhUOn-00016b-7a; Tue, 05 Mar 2024 13:00:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688792.1073390; Tue, 05 Mar 2024 13:00:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhUOn-00016U-3P; Tue, 05 Mar 2024 13:00:01 +0000 Received: by outflank-mailman (input) for mailman id 688792; Tue, 05 Mar 2024 13:00:00 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhUOm-00014v-Iy for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 13:00:00 +0000 Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [2607:f8b0:4864:20::730]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 4505e192-daf0-11ee-a1ee-f123f15fe8a2; Tue, 05 Mar 2024 13:59:58 +0100 (CET) Received: by mail-qk1-x730.google.com with SMTP id af79cd13be357-7881f80b2aeso39667485a.3 for ; Tue, 05 Mar 2024 04:59:58 -0800 (PST) Received: from [10.80.67.149] (default-46-102-197-194.interdsl.co.uk. [46.102.197.194]) by smtp.gmail.com with ESMTPSA id mv7-20020a056214338700b0068f8a00f581sm6128496qvb.106.2024.03.05.04.59.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 Mar 2024 04:59:56 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 4505e192-daf0-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709643597; x=1710248397; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=ju4tUB7F72eR7oZPnQnghhkysRyXA19ZzPw04aENNV8=; b=dtlqxPSYZ7O3LgX9Ee7C2ScExRfNb3kAdbRYCy4PJTyWQx5Gd4hst8Tc8pSUGyPfto 3e309Apd/IGUgXnur6vzGbQrqhzAO1eCQpYjJaxGcW2qJQx9/NV9aqUT2+XJkurGVGbF 2285+sPbnxMYeLGEb6bxOu8CixeqeIxL7bKW0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709643597; x=1710248397; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ju4tUB7F72eR7oZPnQnghhkysRyXA19ZzPw04aENNV8=; b=lFaYLQvqj1xwPqoAyLLGz8Pv2BlFIIQEQu8jBI+wlPNAQNgcC9/5Pag7cfBGS/YciH 5NFrke0fa6RLZebfPEruiEEDAHAWzpEeq32fwM2drl2QdrjaDB2Y4GYY3DwbWaH4jq6n 4D+Nz2MyReV9GCHCzBhPTvS/yMQV/2Py3oJ8eUy9bsTRAohgDdv5Pr5quHzGceV4zy5p 2hSq3fkH4IXa2kNujBCTHCne2XmqsKcfAzdBRpmWO1WItDQZN47HdNgUm5LT9ilo2S6s OyrF7YMOT/j/McwEYKLLenNFCqdxoKdA0u0l2AAO4/M6E0Zs28vaIIHX4RixQ2ZVCf+K g6UA== X-Forwarded-Encrypted: i=1; AJvYcCVxIIvS6cL5RkSgi6DJ7YTxsGNCsVsQ2Mz3uPGSdSk+YGTZXRDSnuDJ8p+uFkXrU7N15IWR13R4trPQsIPw779tEfWmBAGZi/bARGUWFsY= X-Gm-Message-State: AOJu0Yzzv3If94057PYqIRb4HoIUx20qyTy/j6h7lkuiTIcvViKcZKY0 3Ui9FYcChhWPtYd/LchH9GLSsJ0uI9Yg7THYcA0lcVcE1xRMho5it0TLyfy/djxhmh2VN2Sv0AK q X-Google-Smtp-Source: AGHT+IHuqqw7P+KwBu6BxqA8NHP11iXaK1O04qC3d4XUKkOXDVBlOW4gKhOIXL9jDOJsaDclqYVwlw== X-Received: by 2002:a0c:dd8a:0:b0:68f:3919:ebc2 with SMTP id v10-20020a0cdd8a000000b0068f3919ebc2mr1926791qvk.39.1709643597500; Tue, 05 Mar 2024 04:59:57 -0800 (PST) Message-ID: <0c0d350c-8b87-4870-aea8-6f9856009ce7@citrix.com> Date: Tue, 5 Mar 2024 12:59:54 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/{RISCV,PPC}/xen.lds: Delete duplicate _erodata definitions Content-Language: en-GB To: Jan Beulich Cc: Oleksii Kurochko , Shawn Anastasio , Xen-devel References: <20240305122121.3529541-1-andrew.cooper3@citrix.com> From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 05/03/2024 12:44 pm, Jan Beulich wrote: > On 05.03.2024 13:21, Andrew Cooper wrote: >> This is bad copy/paste from somewhere. Retain the second _erodata symbol, >> which follows the Build ID, and matches the other architectures. >> >> No functional change. > I.e. the 2nd one took effect? Seems to have done, yes. > (To be honest I'm surprised the linker > didn't complain about a duplicate symbol there.) > >> Signed-off-by: Andrew Cooper > Reviewed-by: Jan Beulich Thanks. From xen-devel-bounces@lists.xenproject.org Tue Mar 05 13:02:43 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 13:02:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688795.1073400 (Exim 4.92) (envelope-from ) id 1rhURO-0002Yl-Ij; Tue, 05 Mar 2024 13:02:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688795.1073400; Tue, 05 Mar 2024 13:02:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhURO-0002Ye-Fz; Tue, 05 Mar 2024 13:02:42 +0000 Received: by outflank-mailman (input) for mailman id 688795; Tue, 05 Mar 2024 13:02:41 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhURN-0002YY-JS for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 13:02:41 +0000 Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [2a00:1450:4864:20::534]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id a558eacc-daf0-11ee-a1ee-f123f15fe8a2; Tue, 05 Mar 2024 14:02:39 +0100 (CET) Received: by mail-ed1-x534.google.com with SMTP id 4fb4d7f45d1cf-5654f700705so7743247a12.1 for ; Tue, 05 Mar 2024 05:02:39 -0800 (PST) Received: from [10.80.67.149] (default-46-102-197-194.interdsl.co.uk. [46.102.197.194]) by smtp.gmail.com with ESMTPSA id dh18-20020a0564021d3200b0056760e830f0sm1885747edb.81.2024.03.05.05.02.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 Mar 2024 05:02:37 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a558eacc-daf0-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709643758; x=1710248558; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=fBWja+jM2d0PGuZam/o/TZhJWcnGuUdDP0aqZXCvB7w=; b=fjxNlQirDWMoP9UPRJBoyDvZIfQunu/vokZXC6gULzTO4P75rnS3/UdQjBBaDTRQ7T g1qX76nLSCDpUo9rwU/cTb/SYRY5WMS7v6nzE+spWsG/0qDeP2d5Iqci9pbxhsY2rwJ+ mVGKSH+IYFNNDZOLaaFqyACjJzYJuCSIMAhB0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709643758; x=1710248558; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=fBWja+jM2d0PGuZam/o/TZhJWcnGuUdDP0aqZXCvB7w=; b=bJ6WCCHRQVw76ckSsnSN0jvVUUeYmgu7ilP9s6y5EwmOZESWZDvH15SaWb9uuEdnR8 RlHWTfAcZ1efSosGW4xWmBZUIzUrXjxUc8wYKle1H4yUVluI3Zog4yVbzP7JN3/n+Zqe XhwbBoYzi9ZHsNUypp1AWo9HBBUo+QKRbGa4DtZBiBnUDiMTiWi4SZPDTnvBszp4ULdf OlCe0ETSRco/mNEpQlSVMVzHQ8PizWF6S24YxVPg55UeN9TiPvfmq8865TrS4juAUan3 C8lw85Kh5NFzbWnXKcFdHaZ80gbT2FytZNyhOwqxvS/weIiip20sXVHY0vd5ig2NQ0LR 9PYA== X-Gm-Message-State: AOJu0YwV9ySgJ5hn6wsXqd2XJn7A9kkIZTFbjWpcvFT3+NzEzBE/gq+M RaVbxhYYHIApDamwfy6dU1jLgELK2oNUHvgp5dOFy81KLnSPEKkWMQPIZlZMjdZZvRjq8sxnC/b 1 X-Google-Smtp-Source: AGHT+IHwEAbtsWzs7Nw2LWvks57AuuQAxw30sQuhzDI7Zp9gSu33Uk64+dnnm+lg6cxzllouDH/mRQ== X-Received: by 2002:a50:85c6:0:b0:565:9fff:6046 with SMTP id q6-20020a5085c6000000b005659fff6046mr9471361edh.3.1709643758148; Tue, 05 Mar 2024 05:02:38 -0800 (PST) Message-ID: Date: Tue, 5 Mar 2024 13:02:37 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 3/3] x86/livepatch: Relax permissions on rodata too Content-Language: en-GB To: Xen-devel Cc: Konrad Rzeszutek Wilk , Ross Lagerwall , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <20240305121121.3527944-1-andrew.cooper3@citrix.com> <20240305121121.3527944-4-andrew.cooper3@citrix.com> From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <20240305121121.3527944-4-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 05/03/2024 12:11 pm, Andrew Cooper wrote: > diff --git a/xen/common/virtual_region.c b/xen/common/virtual_region.c > index d2efe9e11492..f45812483b8e 100644 > --- a/xen/common/virtual_region.c > +++ b/xen/common/virtual_region.c > @@ -91,9 +91,15 @@ void relax_virtual_region_perms(void) > > rcu_read_lock(&rcu_virtual_region_lock); > list_for_each_entry_rcu( region, &virtual_region_list, list ) > + { > modify_xen_mappings_lite((unsigned long)region->text_start, > PAGE_ALIGN((unsigned long)region->text_end), > PAGE_HYPERVISOR_RWX); > + if ( region->rodata_start ) > + modify_xen_mappings_lite((unsigned long)region->rodata_start, > + ROUNDUP((unsigned long)region->rodata_end, PAGE_SIZE), I missed the final refresh to turn this to PAGE_ALIGN().  Fixed locally. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Mar 05 13:35:54 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 13:35:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688799.1073409 (Exim 4.92) (envelope-from ) id 1rhUxG-00080p-U9; Tue, 05 Mar 2024 13:35:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688799.1073409; Tue, 05 Mar 2024 13:35:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhUxG-00080i-Rc; Tue, 05 Mar 2024 13:35:38 +0000 Received: by outflank-mailman (input) for mailman id 688799; Tue, 05 Mar 2024 13:35:37 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhUxF-00080c-Jo for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 13:35:37 +0000 Received: from mail-qv1-xf2a.google.com (mail-qv1-xf2a.google.com [2607:f8b0:4864:20::f2a]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 3f5884e8-daf5-11ee-afda-a90da7624cb6; Tue, 05 Mar 2024 14:35:36 +0100 (CET) Received: by mail-qv1-xf2a.google.com with SMTP id 6a1803df08f44-68facd7ea4aso44532606d6.0 for ; Tue, 05 Mar 2024 05:35:36 -0800 (PST) Received: from localhost ([213.195.118.74]) by smtp.gmail.com with ESMTPSA id nh7-20020a056214390700b0068f35e9e9a2sm6200220qvb.8.2024.03.05.05.35.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Mar 2024 05:35:35 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3f5884e8-daf5-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709645735; x=1710250535; darn=lists.xenproject.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=odrCsce/jZR1UXVTEC1I/em2Ife2Dvrd6vDjPBqN+80=; b=G7b19aVd2qgj+l3s17Gg/oWQagUboCgnaggY2Pns1w0PLDYGx+q6JyfV2oQLLscL7A O7NlwVggqNRrBcAcZA3EaJvRj8573gkNdPm5STr8A8oRkT1lg/dtJpLiIn9Gz8jbztqe Gin/MeNctPUUDGCVIL6Pe8HdcB3cOe2MO8HZU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709645735; x=1710250535; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=odrCsce/jZR1UXVTEC1I/em2Ife2Dvrd6vDjPBqN+80=; b=ByebGpBWc3RS8w0gj7WqC/VRw+U77Zyle6FirSPE7rV1EFJX9V/iigTA7pFrsU7XxM XaeHJnOpWzTisw9Da+qskdAF0EbfBNToFjhpHpStFHOYO4hGR7hlNq2kC4r6+a9wQNTU 0fwOflCf1d7WbvQobKXAMwnl1YAQt2ReeifeAU1PJ9VUBRhXZ3pbUAYUcg93eGhJhflW kAO6nnJvDxYgc3GNi/dSifOTiF/eJ2JNDxWo6bg8PoEEaS7Mgu+r81Mhyyq97DyFrTe3 MIi4t3BgcpngRM54So5tIYJD6biDOTyW1OHEcTa8+nqps7uXsEjaS2mOJgyro+cajJwA rKRw== X-Gm-Message-State: AOJu0Yydc0mFkOf48uUvZyemO0a6bvVNMfWuDtXLfBoFwP3L6HQVEOQU mVWGL6luYVNXHmpTtDcwyymwxi/JbwIwjluINOttX5NAE6Ji4maRAhCX+aY4Xpk= X-Google-Smtp-Source: AGHT+IEOn3c21xLD0jw++8ODDgvgLt1bqp3f18eUuVccbAD47p/Qe4oagt/ZNrYZKtPH7IOzqPyWrg== X-Received: by 2002:a05:6214:131:b0:690:79e:6a7e with SMTP id w17-20020a056214013100b00690079e6a7emr3038125qvs.28.1709645735423; Tue, 05 Mar 2024 05:35:35 -0800 (PST) Date: Tue, 5 Mar 2024 14:35:33 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Andrew Cooper Cc: Xen-devel , Konrad Rzeszutek Wilk , Ross Lagerwall , Jan Beulich Subject: Re: [PATCH 1/3] xen/virtual-region: Rename start/end fields Message-ID: References: <20240305121121.3527944-1-andrew.cooper3@citrix.com> <20240305121121.3527944-2-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20240305121121.3527944-2-andrew.cooper3@citrix.com> On Tue, Mar 05, 2024 at 12:11:19PM +0000, Andrew Cooper wrote: > ... to text_{start,end}. We're about to introduce another start/end pair. > > As minor cleanup, replace ROUNDUP(x, PAGE_SIZE) with the more consice > PAGE_ALIGN() ahead of duplicating the example. > > No functional change. > > Signed-off-by: Andrew Cooper Reviewed-by: Roger Pau Monné Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Tue Mar 05 13:46:54 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 13:46:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688803.1073420 (Exim 4.92) (envelope-from ) id 1rhV85-0001hz-14; Tue, 05 Mar 2024 13:46:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688803.1073420; Tue, 05 Mar 2024 13:46:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhV84-0001hs-Ud; Tue, 05 Mar 2024 13:46:48 +0000 Received: by outflank-mailman (input) for mailman id 688803; Tue, 05 Mar 2024 13:46:47 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhV83-0001hm-TG for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 13:46:47 +0000 Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [2607:f8b0:4864:20::72e]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id ceeee53e-daf6-11ee-afda-a90da7624cb6; Tue, 05 Mar 2024 14:46:47 +0100 (CET) Received: by mail-qk1-x72e.google.com with SMTP id af79cd13be357-7882e94d408so139098085a.0 for ; Tue, 05 Mar 2024 05:46:46 -0800 (PST) Received: from localhost ([213.195.118.74]) by smtp.gmail.com with ESMTPSA id a15-20020a05620a066f00b00787cb0062cdsm1508702qkh.35.2024.03.05.05.46.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Mar 2024 05:46:45 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ceeee53e-daf6-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709646406; x=1710251206; darn=lists.xenproject.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=Vb190brPG5Rw20LTXSZPBr7sl3VdbGvfGp/atN9FAjI=; b=BJXui+BjUGdUx/qfR4o5nl1gBue+lP/xpoxioMDcl+jfwxsmDl7xTnOhTKR6+7cupt 6VQ/csG8iw+QFOlfMgbMgf8Ax/pFJRGTvOYYmHFKKEjpUZt0/LKHdzzEq25+AFbSLUmv ICLT0/VDbgOjJfJnMjUN+FvHoovIjd7Ngsamw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709646406; x=1710251206; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Vb190brPG5Rw20LTXSZPBr7sl3VdbGvfGp/atN9FAjI=; b=SYmUuj/YxN/UTrkDQasQugsIClUrxdeUU5AuAAe1isjFQ9NIki2Ga5bVQaZmhdDlFo 7l2jcmZjhBrEWweYhnVGd+UCokH+T0XFPbwQ5lvXUvHO4Q1OzMrba5b/eNqGs5TTnGMe 4W6mJihyvvSYXlIltU9Zueez2IfYEP5mnscOQyjQJYh31kYDB4j2eMGBkqk2/+47DuP7 ctJhV/0A/IMUu36QmQluZgB2RQM43barSlkZYtvggGwTmGmVccCSvtY8xCdP72ADyutY fnKcemdehqNQet2/Nj5W/N51K9a65Ue6QPWzLuTzzzgiwLi+7ffFGPm9BqQ77xQXnH8t A+yg== X-Gm-Message-State: AOJu0Yy95bu5MpgYjLRa644u8pq/T1/QlYarBpa3XvJfflaTM/kih56y 2qLCZLLv1iPiOKPwia9/8nvZIAxnn6cDjoafny5YqFjZuHiGtuwTOapWwOMU8vE= X-Google-Smtp-Source: AGHT+IF4IoBCHdBHpxQxgqenhqQ1Jp1gJpkiljRLSgGwS3+j6jLW19NamgBv0+cKHwfwyCWSL10IHQ== X-Received: by 2002:a05:620a:40d0:b0:788:2ee8:5e2e with SMTP id g16-20020a05620a40d000b007882ee85e2emr2425818qko.66.1709646405761; Tue, 05 Mar 2024 05:46:45 -0800 (PST) Date: Tue, 5 Mar 2024 14:46:43 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Andrew Cooper Cc: Xen-devel , Konrad Rzeszutek Wilk , Ross Lagerwall , Jan Beulich Subject: Re: [PATCH 2/3] xen/virtual-region: Include rodata pointers Message-ID: References: <20240305121121.3527944-1-andrew.cooper3@citrix.com> <20240305121121.3527944-3-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20240305121121.3527944-3-andrew.cooper3@citrix.com> On Tue, Mar 05, 2024 at 12:11:20PM +0000, Andrew Cooper wrote: > These are optional. .init doesn't distinguish types of data like this, and > livepatches don't necesserily have any .rodata either. > > No functional change. > > Signed-off-by: Andrew Cooper Reviewed-by: Roger Pau Monné Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Tue Mar 05 13:48:56 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 13:48:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688805.1073430 (Exim 4.92) (envelope-from ) id 1rhVA6-0002Ge-E3; Tue, 05 Mar 2024 13:48:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688805.1073430; Tue, 05 Mar 2024 13:48:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhVA6-0002GX-A0; Tue, 05 Mar 2024 13:48:54 +0000 Received: by outflank-mailman (input) for mailman id 688805; Tue, 05 Mar 2024 13:48:52 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhVA4-0002GR-Ij for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 13:48:52 +0000 Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [2607:f8b0:4864:20::829]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 193d962a-daf7-11ee-afda-a90da7624cb6; Tue, 05 Mar 2024 14:48:51 +0100 (CET) Received: by mail-qt1-x829.google.com with SMTP id d75a77b69052e-42efbc18f2fso8267971cf.0 for ; Tue, 05 Mar 2024 05:48:51 -0800 (PST) Received: from localhost ([213.195.118.74]) by smtp.gmail.com with ESMTPSA id f8-20020ac859c8000000b0042c61b99f42sm2991329qtf.46.2024.03.05.05.48.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Mar 2024 05:48:50 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 193d962a-daf7-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709646530; x=1710251330; darn=lists.xenproject.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=5fn+Keav2c02DqvvtZMmlbGmuVNwLiwEMWjhNZw740I=; b=FKPwdzKJJiXZlCE0kKX13JPtRC73kFdjw21Hf9ZOQ3X2xk0os0QksrQqzVLXIuyOBc tOeZA25X3rfNcga7N+e2RBQO15B9FhgCVbYuAj5Ej7YkcthBFxjQxg5OxqoOGVw+p77y 914J0o6IRVpBOf9hy467NLHfWxokB6wkfoxoA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709646530; x=1710251330; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=5fn+Keav2c02DqvvtZMmlbGmuVNwLiwEMWjhNZw740I=; b=I54NBIJ09X1FswSE+naGv3ZGQ2HkF6F/MTzFBjVGffIM/aJyNEMXLMBokoo7OuO8SN sENCR0j4xqw2RWrEAZu7uOQtFFz485jCYBCz20ofN/d4BHRYLrmaUCW5rU/+f+20GwCB z6qnO421TJ+CLDHh9DJU1i9MmpXzgeLJN6CqPCw7wS4misDPYe+SPCFMCoeUE3Uav/77 KURD3hLvW6OaNT13BqfsEA4ae7gqgpQbVxysrafFH2AWMuwm/85CqQH5gLENe6Zj6pV1 dZbBcY1RW4+jAIfMKwkcZ5KX6yQKYB3+N8lNOaeiTei6P7FOynSV89SzZ/HgJLAM/6EV W4tw== X-Gm-Message-State: AOJu0YwdYylUMx8O1Yqw3p/gBIgm1scLCUUK5wqX93CTGrg1o4w8AR/X I2W519+g0GriTHvQRhYmL5mLfoIUCJ5yqPdf1Ep2zG7gH5VtKebXM46ucPuIOH4= X-Google-Smtp-Source: AGHT+IEUghECJzUZj2yHCSHMu1WhZefzDOWneZnf2Q+NNrx78soYupX4MIUkiy6s3XjlrWXJH+MwVA== X-Received: by 2002:a05:622a:1b90:b0:42e:f166:17e5 with SMTP id bp16-20020a05622a1b9000b0042ef16617e5mr2667475qtb.23.1709646530540; Tue, 05 Mar 2024 05:48:50 -0800 (PST) Date: Tue, 5 Mar 2024 14:48:48 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Andrew Cooper Cc: Xen-devel , Konrad Rzeszutek Wilk , Ross Lagerwall , Jan Beulich Subject: Re: [PATCH 3/3] x86/livepatch: Relax permissions on rodata too Message-ID: References: <20240305121121.3527944-1-andrew.cooper3@citrix.com> <20240305121121.3527944-4-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Tue, Mar 05, 2024 at 01:02:37PM +0000, Andrew Cooper wrote: > On 05/03/2024 12:11 pm, Andrew Cooper wrote: > > diff --git a/xen/common/virtual_region.c b/xen/common/virtual_region.c > > index d2efe9e11492..f45812483b8e 100644 > > --- a/xen/common/virtual_region.c > > +++ b/xen/common/virtual_region.c > > @@ -91,9 +91,15 @@ void relax_virtual_region_perms(void) > > > > rcu_read_lock(&rcu_virtual_region_lock); > > list_for_each_entry_rcu( region, &virtual_region_list, list ) > > + { > > modify_xen_mappings_lite((unsigned long)region->text_start, > > PAGE_ALIGN((unsigned long)region->text_end), > > PAGE_HYPERVISOR_RWX); > > + if ( region->rodata_start ) > > + modify_xen_mappings_lite((unsigned long)region->rodata_start, > > + ROUNDUP((unsigned long)region->rodata_end, PAGE_SIZE), > > I missed the final refresh to turn this to PAGE_ALIGN().  Fixed locally. With that: Reviewed-by: Roger Pau Monné Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Tue Mar 05 14:04:27 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 14:04:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688809.1073439 (Exim 4.92) (envelope-from ) id 1rhVP3-0005yq-Ku; Tue, 05 Mar 2024 14:04:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688809.1073439; Tue, 05 Mar 2024 14:04:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhVP3-0005yj-IG; Tue, 05 Mar 2024 14:04:21 +0000 Received: by outflank-mailman (input) for mailman id 688809; Tue, 05 Mar 2024 14:04:20 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhVP2-0005yd-KZ for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 14:04:20 +0000 Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [2a00:1450:4864:20::629]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 41d5fb5e-daf9-11ee-a1ee-f123f15fe8a2; Tue, 05 Mar 2024 15:04:18 +0100 (CET) Received: by mail-ej1-x629.google.com with SMTP id a640c23a62f3a-a44e3176120so357305466b.1 for ; Tue, 05 Mar 2024 06:04:18 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id z20-20020a170906271400b00a441cb52bfcsm6098270ejc.165.2024.03.05.06.04.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 Mar 2024 06:04:17 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 41d5fb5e-daf9-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709647457; x=1710252257; darn=lists.xenproject.org; h=content-transfer-encoding:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to; bh=9gYp1d3LLJ7Rbx1dzq46z952PRA1TGcqipE4P/XboyY=; b=azPCxJrndwVWwA+h90xThTQlk9ESMvjQBC+BZwazDueRfBuEDhGTwmHHMQ60RxlKFF D3hGSZOK4lgd5OzJzdGmF0ekFOsMRm43BaR6zESK18WMOt0AZH10QCNPLBxE65HGiWr6 jXUwbUWY3ljoO7MftsykVOvOJOFtoAqaAj6o9ZNEbaJDr+l1ch+BdStDMiLD1RGDjBdb VkTe34/LZn+Ixe0IxOP2E7/NISO58pNAqd5hh/AzOhMax4A77Arp5pTqJtsmD+7X4iMf WC7GrK4VdFk2YVw+HJZmxYIfvvCGNnxs5ezd9vjj2K1vniV3A27r6QVa/NcGvVf2fo5A 60Dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709647457; x=1710252257; h=content-transfer-encoding:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=9gYp1d3LLJ7Rbx1dzq46z952PRA1TGcqipE4P/XboyY=; b=PLx4r+9zpTW399QSMrLmnU3Pz+IhFgXUMvC3w5fc0G+NkSsr7Vp7/ZTD6m5xyEo5R3 t4uygnzcYJSlTPVF7ZxyTHcqWD+H35P6VGCaMnOk347A6COYP2vHFXabQ7S+hzgtkxVO qdOhS9TCZ5d4jWWMpBZ3Yhioa7Hueyklf+tNTkArjcktmYYCF1wUn6y+Xab+48GZOTE9 qay2OJd4KsS2WJ6x4mxm4SfjTo2QptlKQstUTDg695ImY340Ffe4w9KvbN1ZLe7/YDMj jFuXzWrx688t67l9Oswqk48eTNWH2P3Pw8pFeQWdeQwRTCWIyVuui5bo42ZQ+x08SxMq gaBQ== X-Gm-Message-State: AOJu0YznEUFzD/tzP2Sjw5BbIpce2v20sNywWSGXP5xxH6zLjY44/nlA nFEAm25OTNl/HWwRR4vTnmaiHRIYYKPaEVU4qyJVHg5AZD44SzEfxTVYh6bsge1J5hOTApJmdwo = X-Google-Smtp-Source: AGHT+IEmx183CeLsgL4hlq8MMiJ4ZlOOteea0qMS5xQRs89h5q+8N9szLSe57ThrQil464A8UKtSQw== X-Received: by 2002:a17:906:560b:b0:a45:7dc6:5bb with SMTP id f11-20020a170906560b00b00a457dc605bbmr2853544ejq.71.1709647457608; Tue, 05 Mar 2024 06:04:17 -0800 (PST) Message-ID: <0ba4903d-638d-408e-bcd4-7c13cb56e078@suse.com> Date: Tue, 5 Mar 2024 15:04:16 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= From: Jan Beulich Subject: [PATCH] x86/entry: shrink insn size for some of our EFLAGS manipulation Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Much like was recently done for setting entry vector, and along the lines of what we already had in handle_exception_saved, avoid 32-bit immediates where 8-bit ones do. Reduces .text.entry size by 16 bytes in my non-CET reference build, while in my CET reference build section size doesn't change (there and in .text only padding space increases). Inspired by other long->byte conversion work. Signed-off-by: Jan Beulich --- Numbers above are biased by me also having the straight-line-speculation change in the tree, thus every JMP is followed by an INT3. Without that, .text.entry size would also shrink by 16 bytes in the CET build. --- a/xen/arch/x86/x86_64/entry.S +++ b/xen/arch/x86/x86_64/entry.S @@ -52,7 +52,7 @@ UNLIKELY_END(syscall_no_callback) movq %rax,TRAPBOUNCE_eip(%rdx) movb %cl,TRAPBOUNCE_flags(%rdx) call create_bounce_frame - andl $~X86_EFLAGS_DF,UREGS_eflags(%rsp) + andb $~(X86_EFLAGS_DF >> 8), UREGS_eflags + 1(%rsp) /* %rbx: struct vcpu */ test_all_events: ASSERT_NOT_IN_ATOMIC @@ -223,7 +223,7 @@ LABEL_LOCAL(.Lrestore_rcx_iret_exit_to_g /* No special register assumptions. */ iret_exit_to_guest: andl $~(X86_EFLAGS_IOPL | X86_EFLAGS_VM), EFRAME_eflags(%rsp) - orl $X86_EFLAGS_IF, EFRAME_eflags(%rsp) + orb $X86_EFLAGS_IF >> 8, EFRAME_eflags + 1(%rsp) addq $8,%rsp .Lft0: iretq _ASM_PRE_EXTABLE(.Lft0, handle_exception) @@ -346,7 +346,7 @@ LABEL(sysenter_eflags_saved, 0) GET_STACK_END(bx) /* PUSHF above has saved EFLAGS.IF clear (the caller had it set). */ - orl $X86_EFLAGS_IF, UREGS_eflags(%rsp) + orb $X86_EFLAGS_IF >> 8, UREGS_eflags + 1(%rsp) mov STACK_CPUINFO_FIELD(xen_cr3)(%rbx), %rcx test %rcx, %rcx jz .Lsyse_cr3_okay @@ -361,11 +361,11 @@ LABEL(sysenter_eflags_saved, 0) cmpb $0,VCPU_sysenter_disables_events(%rbx) movq VCPU_sysenter_addr(%rbx),%rax setne %cl - testl $X86_EFLAGS_NT,UREGS_eflags(%rsp) + testb $X86_EFLAGS_NT >> 8, UREGS_eflags + 1(%rsp) leaq VCPU_trap_bounce(%rbx),%rdx UNLIKELY_START(nz, sysenter_nt_set) pushfq - andl $~X86_EFLAGS_NT,(%rsp) + andb $~(X86_EFLAGS_NT >> 8), 1(%rsp) popfq UNLIKELY_END(sysenter_nt_set) testq %rax,%rax From xen-devel-bounces@lists.xenproject.org Tue Mar 05 14:18:06 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 14:18:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688812.1073449 (Exim 4.92) (envelope-from ) id 1rhVcG-00085K-P2; Tue, 05 Mar 2024 14:18:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688812.1073449; Tue, 05 Mar 2024 14:18:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhVcG-00085D-MZ; Tue, 05 Mar 2024 14:18:00 +0000 Received: by outflank-mailman (input) for mailman id 688812; Tue, 05 Mar 2024 14:17:59 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhVcF-000857-Gn for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 14:17:59 +0000 Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [2a00:1450:4864:20::535]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 2aaafc35-dafb-11ee-afda-a90da7624cb6; Tue, 05 Mar 2024 15:17:58 +0100 (CET) Received: by mail-ed1-x535.google.com with SMTP id 4fb4d7f45d1cf-565a3910f86so8561582a12.3 for ; Tue, 05 Mar 2024 06:17:58 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id d8-20020a50fe88000000b005673e29cc0fsm2708966edt.54.2024.03.05.06.17.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 Mar 2024 06:17:57 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 2aaafc35-dafb-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709648278; x=1710253078; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=nCffwEo8NtUKU4Kqg9J8D9/ZJln8QF61t69XY6li/lU=; b=C/tIJ+AA9TZl3Rdw2btzmuYQjcFS51U2UySq7k9T5N8/l01s2czLQr6Pg8c8APwRIW w6Js6qzEmy3RG4ARUj8MNJ7UmTCrxt7tvC0qanTzmggJhhk/Ssik5qIYysHrDpZXPwEO CRhNYpNpos9fAsQMfEDMYTCiZTTyJTSh/VCaN4pGVZZXEu0s36WwIMWtOghC2MMHFGTx /5PR6k8COw6HMjqMa+Ci/28nj3ICO2ie/yWDzk1Gc80gTluQg8TeVel/9IdhhwDXD+iE m7tEfTI7QceUkSxqkCdI7PATy4OlJP3uOlSSrul2WfNIDCpjhEThG9CDj8w3HZYLBwMB QFhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709648278; x=1710253078; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=nCffwEo8NtUKU4Kqg9J8D9/ZJln8QF61t69XY6li/lU=; b=gjUAnVOZx5P0ADGc1hBbqUaLM89bL2K1Ehj94ljrZwahwuZ7FzjBpjTorFBiyV2iIW f/dew/w1ZLlXLIEogpV8rXEDXW6NfgSiuqKW2U5mwKVYclm3dHzyJk9QvRn1NoEd63kB 1TbWrM5YNEITkWK8CSvese34CSqmzBQTeMYo+m2NNdUSxxzx8v9mgXkUxHCDgpU4pJXE I9VNboWM7SOua8bbyZDdO+bBBZ6CRLSmJepCvlwO5Wp8iYKk3JnWQsbg0xWln9co8S4H OCx+81poY13QCwj68YHWSwviUN4iDrRTkUA4A0R5GX6013SdlQTp1i0nnqFZkyNtMPMv eZ+A== X-Forwarded-Encrypted: i=1; AJvYcCWNTw3AACopNntRHAYtyxxnSmS7Nq03f7DXdUNSL2zUE81XYgr/+hmp7sDvCY+YZB1d8R6HaSPNPVY5TYUYLmYJg42nSS+Kl9v4Qu9cXtQ= X-Gm-Message-State: AOJu0Yx4BeGfB5t3ApcTqdxYVt8oTHILBewgX7Jtc7b9rsHf367lOeFi TlN81/pHLTGvmiXiE9aYxfo1M2zAE4ptyoq0QTNF6hGuBwn9yefkaA9B/IBg2w== X-Google-Smtp-Source: AGHT+IFHDom6al4eDJK0L9QRhF1B5dED61U5IocqYcu1gztiBPLC5RadfRuei/T270YKU7nX2WkxOA== X-Received: by 2002:a50:9ecd:0:b0:565:edf9:8038 with SMTP id a71-20020a509ecd000000b00565edf98038mr7239451edf.40.1709648277802; Tue, 05 Mar 2024 06:17:57 -0800 (PST) Message-ID: <87b82706-f538-4807-abaf-1e59cebd286b@suse.com> Date: Tue, 5 Mar 2024 15:17:56 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/3] xen/virtual-region: Include rodata pointers To: Andrew Cooper Cc: Konrad Rzeszutek Wilk , Ross Lagerwall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20240305121121.3527944-1-andrew.cooper3@citrix.com> <20240305121121.3527944-3-andrew.cooper3@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20240305121121.3527944-3-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 05.03.2024 13:11, Andrew Cooper wrote: > --- a/xen/include/xen/virtual_region.h > +++ b/xen/include/xen/virtual_region.h > @@ -16,6 +16,9 @@ struct virtual_region > const void *text_start; /* .text virtual address start. */ > const void *text_end; /* .text virtual address end. */ > > + const void *rodata_start; /* .rodata virtual address start (optional). */ > + const void *rodata_end; /* .rodata virtual address end. */ > + > /* If this is NULL the default lookup mechanism is used. */ > symbols_lookup_t *symbols_lookup; While perhaps the least bad one can do without quite a bit more churn, I'm still irritated by a virtual region (singular) suddenly covering two ranges of VA space. At the very least I think the description should say a word of justification in this regard. An alternative, after all, could have been for livepatch code to register separate regions for rodata (if present in a patch). A follow-on question then would be why ordinary data isn't reflected in a virtual region. Aiui that's just because livepatch presently has no need for it. Underlying question to both: Is the virtual region concept indeed meant to be fully tied to livepatch and its needs? Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 05 14:34:03 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 14:34:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688815.1073459 (Exim 4.92) (envelope-from ) id 1rhVrd-0003Is-38; Tue, 05 Mar 2024 14:33:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688815.1073459; Tue, 05 Mar 2024 14:33:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhVrd-0003Il-08; Tue, 05 Mar 2024 14:33:53 +0000 Received: by outflank-mailman (input) for mailman id 688815; Tue, 05 Mar 2024 14:33:51 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhVrb-0003IO-8x for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 14:33:51 +0000 Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [2a00:1450:4864:20::52a]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 6171e28a-dafd-11ee-a1ee-f123f15fe8a2; Tue, 05 Mar 2024 15:33:49 +0100 (CET) Received: by mail-ed1-x52a.google.com with SMTP id 4fb4d7f45d1cf-563d56ee65cso8639815a12.2 for ; Tue, 05 Mar 2024 06:33:49 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id y26-20020a056402135a00b0056694006fa7sm5900656edw.70.2024.03.05.06.33.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 Mar 2024 06:33:48 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6171e28a-dafd-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709649229; x=1710254029; darn=lists.xenproject.org; h=content-transfer-encoding:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to; bh=dXAIYdOVmaJtr5P/s2+33MPZa5QVmPdxL5PDXXJoJT8=; b=gUWzXNYiP9+7NphhJvmdIiqi8W/1Sfax44XlAJfPWHDYvCnnXPAN6xlx59I9L2Y12q tYoEOzze8lnDvvXeP2h5iy3Ubbqhvcx5nj982E3fAyojvKTnRv3H7xb31SyV/kPMVslx sZEa8hImZnqOZ5TyldrIEgObXln3LqPfbzRzDWCrXKaCJbExkkVY2zfIFwBPTKOCO77b G/qrVFQnHbkK/w3quXvY0qK6ZOq5rdD4Vn+4eeS7iSt160jqBLMyvS4xO4ZMaNNS/Jdd 2VRoA/cK6PzC6HvbY5yz3wUn93esjUmx5ZOLSlOKNlHg+8/6L/w7wXmNoTzKJy7wEnkb BeGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709649229; x=1710254029; h=content-transfer-encoding:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=dXAIYdOVmaJtr5P/s2+33MPZa5QVmPdxL5PDXXJoJT8=; b=aRWbJIDEoI1/ms6wUxw8oYc8xJC1A3Vng1rNNLdjB1xL8jevhqFkllzu1VbZU4crAL twjlUwIbwX4ouPZVF9kHRwML/LyAvxiousOF62UTgUS5t4kKK+G7yPl4G1pvvw1JOFV+ GjyTR5Ys1nYHZbx347cP36zXcmCluxHRmwCldEMeauZHKz82yjOl47kIWtda8rUq7MgA uLy0GJn+cV4spU9nSMI2vyj2K6Wj55S0U/Cbad5CshGrEc2sG1+Ol87QC4GbX+2CDt/I GN9NriWBGFOe9tS1AK5ugocmlrNNnjArVdC9tAe0XNBao9YUdKYDSd6jicIfl99Wo0wh pyOQ== X-Gm-Message-State: AOJu0YyQsToH44uJejH//VYX9b6c2rRKnYgCxQwkgS3iQYOOMCOaZ/Jf yEV1Zhw7GklQB6GsO6KKNYL9+D+WOz6t89f6yU6WHXjzwcDFkWBpcQ0dgAHUdUowjeSPycvIk6k = X-Google-Smtp-Source: AGHT+IHJ95z9b4X8dJ0/Ajco9LCr8fLKj1kqrm7C6Ssio3MkQudhQMnCSGKOYTWQtz/pXIrroxp7sg== X-Received: by 2002:a05:6402:2318:b0:565:1049:c013 with SMTP id l24-20020a056402231800b005651049c013mr8348985eda.10.1709649228752; Tue, 05 Mar 2024 06:33:48 -0800 (PST) Message-ID: <3aca1707-9eab-4b85-a4ae-e56508b15843@suse.com> Date: Tue, 5 Mar 2024 15:33:47 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: "xen-devel@lists.xenproject.org" Cc: Anthony Perard , Wei Liu , Juergen Gross From: Jan Beulich Subject: [PATCH] 9pfsd: allow building with old glibc Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Neither pread() / pwrite() nor O_DIRECTORY are available from glibc 2.11.3 headers without defining (e.g.) _GNU_SOURCE. Supplying the definition unconditionally shouldn't be a problem, seeing that various other tools/ components do so, too. Signed-off-by: Jan Beulich --- a/tools/9pfsd/Makefile +++ b/tools/9pfsd/Makefile @@ -5,7 +5,7 @@ XEN_ROOT = $(CURDIR)/../.. include $(XEN_ROOT)/tools/Rules.mk -CFLAGS += $(PTHREAD_CFLAGS) +CFLAGS += $(PTHREAD_CFLAGS) -D_GNU_SOURCE LDFLAGS += $(PTHREAD_LDFLAGS) TARGETS := xen-9pfsd From xen-devel-bounces@lists.xenproject.org Tue Mar 05 14:59:25 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 14:59:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688819.1073470 (Exim 4.92) (envelope-from ) id 1rhWG9-00073b-Qm; Tue, 05 Mar 2024 14:59:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688819.1073470; Tue, 05 Mar 2024 14:59:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhWG9-00073U-Nz; Tue, 05 Mar 2024 14:59:13 +0000 Received: by outflank-mailman (input) for mailman id 688819; Tue, 05 Mar 2024 14:59:12 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhWG8-00073O-Nb for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 14:59:12 +0000 Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [2a00:1450:4864:20::533]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id eb420032-db00-11ee-a1ee-f123f15fe8a2; Tue, 05 Mar 2024 15:59:09 +0100 (CET) Received: by mail-ed1-x533.google.com with SMTP id 4fb4d7f45d1cf-5672afabb86so2546416a12.3 for ; Tue, 05 Mar 2024 06:59:08 -0800 (PST) Received: from [192.168.206.239] ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id em2-20020a056402364200b00567a2564ab5sm436008edb.67.2024.03.05.06.59.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Mar 2024 06:59:07 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: eb420032-db00-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709650748; x=1710255548; darn=lists.xenproject.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=+QiESiRoL1LCDBlrlcFDG1GSlwvQ2buTt+o1iVhMZog=; b=i4+dwgVzp8Zf+yl/1bHllWU0w5sd4EXFbEtQSRVzdv738ufcoBEwWIRNF5K/86/eR5 UXw9Eajz1H4H27/AvJhXerS5cwsbsGq53w5haEEOmgnRL75x9sMRu7QoADpeDXNg+FRi pg5iQIMcXxuXZsqJb/FSzd40hwSLMZGrdNm8oKWzcy54DuhqaCKXYZ7mDxCqBJ6XF+wV THFeteuw9MFPxKwvXzXir3OGqhz2W9M7CcISazVFLWHStF5aYDTDx49oF2naNky5NjpU telMnNEO/9YIeuVnXZ+siqvSqWBQnschYo48tcqqzaQhhzj/qyCxZ381eKAK0y7ErVQo ODAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709650748; x=1710255548; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=+QiESiRoL1LCDBlrlcFDG1GSlwvQ2buTt+o1iVhMZog=; b=Dj/NL+yBLIQM2H73bLC5zfujEYgpsmppkVY02F4309zgn0DJVbkuQZ1wqCEAiRITQ0 Opo5tU8aJRz9EuR1ABkm9aSqap7Hw9+MdOKLH6ipbnF1P+2yLA2b8J2loSugfv53Db+d R8IS0mcAEaJHemJutHC1en+c1RFEsQJQCOfaT2bK93bhZ93xqDSgqU6yZEehx114uJKI 84wDx1OrHT+jzHtDAgrc9MlIsNhB4D3XwfitFmdDqBWUvASdRu2tPxtYntw3CggUY9F9 Uw5LLlfLJiaF9/OoQCHOx54usiN9A14XhQd4p3zVc0QPv0aZZLtcFJbRKZj9ltsW2/rZ uGgQ== X-Forwarded-Encrypted: i=1; AJvYcCUeEQL3FDy2HRTUcMvilPy3yluFRBZpnYA5feGQZT3I20rrspoJ/+7rHYralZfR92Ao+z32AdSAfVsvVibS7Qim3tLvepVlmUtHMbeHIi8= X-Gm-Message-State: AOJu0YxRmIx/H0JsxWo729cTO/hea47pC9QnFgWKHY3QJr5r7/R5MFAN 3HIjyRnlmev4sUPQrkQFDb3quVyB2eyJufNR/wqK41pbBhgdrXk6 X-Google-Smtp-Source: AGHT+IF+G2bGp4gqgY9gW8wgR37As/nsT5hENUB2TOfEPcc6zz6S/gTQbzh2PiQHW+k1IdsxTHUnRA== X-Received: by 2002:a50:c88b:0:b0:564:f6d5:f291 with SMTP id d11-20020a50c88b000000b00564f6d5f291mr7313536edh.34.1709650748181; Tue, 05 Mar 2024 06:59:08 -0800 (PST) Message-ID: Subject: Re: [PATCH] xen/{RISCV,PPC}/xen.lds: Delete duplicate _erodata definitions From: Oleksii To: Andrew Cooper , Xen-devel Cc: Shawn Anastasio Date: Tue, 05 Mar 2024 15:59:06 +0100 In-Reply-To: <20240305122121.3529541-1-andrew.cooper3@citrix.com> References: <20240305122121.3529541-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.50.2 (3.50.2-1.fc39) MIME-Version: 1.0 RISC-V changes look good to me. Reviewed-by: Oleksii Kurochko ~ Oleksii On Tue, 2024-03-05 at 12:21 +0000, Andrew Cooper wrote: > This is bad copy/paste from somewhere.=C2=A0 Retain the second _erodata > symbol, > which follows the Build ID, and matches the other architectures. >=20 > No functional change. >=20 > Signed-off-by: Andrew Cooper > --- > CC: Oleksii Kurochko > CC: Shawn Anastasio > --- > =C2=A0xen/arch/ppc/xen.lds.S=C2=A0=C2=A0 | 1 - > =C2=A0xen/arch/riscv/xen.lds.S | 1 - > =C2=A02 files changed, 2 deletions(-) >=20 > diff --git a/xen/arch/ppc/xen.lds.S b/xen/arch/ppc/xen.lds.S > index 030e1ee37b55..05b6db272805 100644 > --- a/xen/arch/ppc/xen.lds.S > +++ b/xen/arch/ppc/xen.lds.S > @@ -60,7 +60,6 @@ SECTIONS > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 VPCI_ARRAY > =C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 . =3D ALIGN(POINTER_ALIG= N); > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 _erodata =3D .;=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /* End of read-only data */ > =C2=A0=C2=A0=C2=A0=C2=A0 } :text > =C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0 #if defined(BUILD_ID) > diff --git a/xen/arch/riscv/xen.lds.S b/xen/arch/riscv/xen.lds.S > index 8510a87c4d06..ace6f49c579c 100644 > --- a/xen/arch/riscv/xen.lds.S > +++ b/xen/arch/riscv/xen.lds.S > @@ -60,7 +60,6 @@ SECTIONS > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 VPCI_ARRAY > =C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 . =3D ALIGN(POINTER_ALIG= N); > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 _erodata =3D .;=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /* End of read-only data */ > =C2=A0=C2=A0=C2=A0=C2=A0 } :text > =C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0 #if defined(BUILD_ID) >=20 > base-commit: fc84b4a5a37b9250d87ef63983b48e1953bba6d1 > prerequisite-patch-id: b14999775a3dc222f2f94d7d5d7a1db377de9cb9 > prerequisite-patch-id: 00650d75df673992b4c8cb6d7ac61dab72b9b309 > prerequisite-patch-id: 5464f5f1e7448cde38749a3744c9e74708727dee From xen-devel-bounces@lists.xenproject.org Tue Mar 05 15:03:06 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 15:03:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688822.1073480 (Exim 4.92) (envelope-from ) id 1rhWJt-0000Z8-9x; Tue, 05 Mar 2024 15:03:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688822.1073480; Tue, 05 Mar 2024 15:03:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhWJt-0000Z1-6c; Tue, 05 Mar 2024 15:03:05 +0000 Received: by outflank-mailman (input) for mailman id 688822; Tue, 05 Mar 2024 15:03:03 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhWJr-0000Yt-7B for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 15:03:03 +0000 Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [2a00:1450:4864:20::532]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 76477f51-db01-11ee-afda-a90da7624cb6; Tue, 05 Mar 2024 16:03:02 +0100 (CET) Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-55a5e7fa471so8068206a12.1 for ; Tue, 05 Mar 2024 07:03:02 -0800 (PST) Received: from [192.168.206.239] ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id be27-20020a0564021a3b00b0056650031d94sm5894671edb.90.2024.03.05.07.03.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Mar 2024 07:03:01 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 76477f51-db01-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709650982; x=1710255782; darn=lists.xenproject.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=nN42e+8rYTZ6z97lQyMhRThAmt74Iwq7aMCkyMtt+XY=; b=jD3MEcVl0/zK03T0vrI4fftdygq266ICh5doUp5q12hqY9DaWS9g9WRDkk/CMPe/hH fRgBu9mvn/3BqMZlU0+b2aaQe1jIL0UV4kAGaJ5XC8Rd51XvMQXoDSIwQgd+9IgV0IIj u7JIEWc65Ap977P5A4pOUNpjMjW2bGwfhTVjB4ZD5/Ya/OEljk9KNVWaQ6AsamOcHF99 rymp8Hwc52R75v7AY7XmokC4vm6AqalLDsAI/rzy0yr+/bBFcQ/cCql+bE/OtAUTtMtu AZ/oJwo5PT+TDPAXo9jFbxdqHaaxAxBfpNtDVPsHXkBi0hYdRWRUSktOuVcHJKvMhYOd 1PMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709650982; x=1710255782; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=nN42e+8rYTZ6z97lQyMhRThAmt74Iwq7aMCkyMtt+XY=; b=ttV/Omi0XE1EhJ8S9LQaHX0t1DXbq7sP9TX4gJvXjPtdDHjtydTFTMhEPe/8nfYt2f Kr4Af5wkMXsyn7PEV0N/5TrOb+bWo6v2GfDfwHbMEdXc9YQazHIzEM4TZWZZAZjL/8AR w+V/6vHrPKnxp4stiWOnJQVtzDJkdAQuZE3KXhWNWyDcKpzJg8Mmqua/XcnpEE2JeET7 6M8ysCBksdrfue0eUtKeA4BubP1AV8U6sjosxIDYhAsuO8d3bUEsS10lgGfLhNKfASXc nuRNvMmLN6M0OrHWOMTm3HbV1lJhzMPSuhLC6bOe6uBmtSRfwWel68wC/3h43SPAv9z4 7etg== X-Forwarded-Encrypted: i=1; AJvYcCXG/y55BxPWVe2EJIXbqELgKAjcbpEpAKlz3xn9sDwFvCkb3Xej3H+G2bhkdhWtcDkYLlNqkXo34i8ZpYQ4cENYT45z9nZ4KLhsQQ04/aA= X-Gm-Message-State: AOJu0Yx4Q3wM9YbVU18NlJub+C5gBO2avU4ryzrypS3xsCQ2/s6yQM2N BGLaUCJK3+T2kxDCl3aU5+hVlzkiuGXR7DIInOiuLmQNveeK7f4t X-Google-Smtp-Source: AGHT+IFJhYH5dUis8GC0r1af4C1zub4w7lB/q01Jdw7k2FYCU6xwwXZMAHt3LUCcHxQ/YVRuxbA8hQ== X-Received: by 2002:a05:6402:3584:b0:566:f66d:f3c6 with SMTP id y4-20020a056402358400b00566f66df3c6mr9500529edc.21.1709650981488; Tue, 05 Mar 2024 07:03:01 -0800 (PST) Message-ID: Subject: Re: [PATCH] x86+Arm: drop (rename) __virt_to_maddr() / __maddr_to_virt() From: Oleksii To: Jan Beulich , "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Wei Liu , Roger Pau =?ISO-8859-1?Q?Monn=E9?= , Julien Grall , Stefano Stabellini , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel Date: Tue, 05 Mar 2024 16:02:52 +0100 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.50.2 (3.50.2-1.fc39) MIME-Version: 1.0 Changes looks good to me. Reviewed-by: Oleksii Kurochko I'll update the RISC-V part correspondingly. ~ Oleksii On Tue, 2024-03-05 at 09:33 +0100, Jan Beulich wrote: > There's no use of them anymore except in the definitions of the non- > underscore-prefixed aliases. Rename the inline functions, adjust the > virt_to_maddr() #define-e, and purge the (x86-only) maddr_to_virt() > one, > thus eliminating a bogus cast which would have allowed the passing of > a > pointer type variable into maddr_to_virt() to go silently. >=20 > Signed-off-by: Jan Beulich >=20 > --- a/xen/arch/arm/include/asm/mm.h > +++ b/xen/arch/arm/include/asm/mm.h > @@ -256,12 +256,12 @@ static inline void __iomem *ioremap_wc(p > =C2=A0/* Page-align address and convert to frame number format */ > =C2=A0#define paddr_to_pfn_aligned(paddr)=C2=A0=C2=A0=C2=A0 > paddr_to_pfn(PAGE_ALIGN(paddr)) > =C2=A0 > -static inline paddr_t __virt_to_maddr(vaddr_t va) > +static inline paddr_t virt_to_maddr(vaddr_t va) > =C2=A0{ > =C2=A0=C2=A0=C2=A0=C2=A0 uint64_t par =3D va_to_par(va); > =C2=A0=C2=A0=C2=A0=C2=A0 return (par & PADDR_MASK & PAGE_MASK) | (va & ~P= AGE_MASK); > =C2=A0} > -#define virt_to_maddr(va)=C2=A0=C2=A0 __virt_to_maddr((vaddr_t)(va)) > +#define virt_to_maddr(va) virt_to_maddr((vaddr_t)(va)) > =C2=A0 > =C2=A0#ifdef CONFIG_ARM_32 > =C2=A0/** > --- a/xen/arch/x86/hvm/nestedhvm.c > +++ b/xen/arch/x86/hvm/nestedhvm.c > @@ -125,7 +125,7 @@ static int __init cf_check nestedhvm_set > =C2=A0=C2=A0=C2=A0=C2=A0 /* shadow_io_bitmaps can't be declared static be= cause > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *=C2=A0=C2=A0 they must fulfill hw require= ments (page aligned section) > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *=C2=A0=C2=A0 and doing so triggers the AS= SERT(va >=3D XEN_VIRT_START) > -=C2=A0=C2=A0=C2=A0=C2=A0 *=C2=A0=C2=A0 in __virt_to_maddr() > +=C2=A0=C2=A0=C2=A0=C2=A0 *=C2=A0=C2=A0 in virt_to_maddr() > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * So as a compromise pre-allocate them whe= n xen boots. > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * This function must be called from within= start_xen() when > --- a/xen/arch/x86/include/asm/page.h > +++ b/xen/arch/x86/include/asm/page.h > @@ -269,8 +269,6 @@ void scrub_page_cold(void *); > =C2=A0#define mfn_valid(mfn)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 __mfn_valid(mf= n_x(mfn)) > =C2=A0#define virt_to_mfn(va)=C2=A0=C2=A0=C2=A0=C2=A0 __virt_to_mfn(va) > =C2=A0#define mfn_to_virt(mfn)=C2=A0=C2=A0=C2=A0 __mfn_to_virt(mfn) > -#define virt_to_maddr(va)=C2=A0=C2=A0 __virt_to_maddr((unsigned long)(va= )) > -#define maddr_to_virt(ma)=C2=A0=C2=A0 __maddr_to_virt((unsigned long)(ma= )) > =C2=A0#define maddr_to_page(ma)=C2=A0=C2=A0 __maddr_to_page(ma) > =C2=A0#define page_to_maddr(pg)=C2=A0=C2=A0 __page_to_maddr(pg) > =C2=A0#define virt_to_page(va)=C2=A0=C2=A0=C2=A0 __virt_to_page(va) > --- a/xen/arch/x86/include/asm/x86_64/page.h > +++ b/xen/arch/x86/include/asm/x86_64/page.h > @@ -34,7 +34,7 @@ static inline unsigned long canonicalise > =C2=A0#define pdx_to_virt(pdx) ((void *)(DIRECTMAP_VIRT_START + \ > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ((unsigned = long)(pdx) << > PAGE_SHIFT))) > =C2=A0 > -static inline unsigned long __virt_to_maddr(unsigned long va) > +static inline unsigned long virt_to_maddr(unsigned long va) > =C2=A0{ > =C2=A0=C2=A0=C2=A0=C2=A0 ASSERT(va < DIRECTMAP_VIRT_END); > =C2=A0=C2=A0=C2=A0=C2=A0 if ( va >=3D DIRECTMAP_VIRT_START ) > @@ -47,8 +47,9 @@ static inline unsigned long __virt_to_ma > =C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0 return xen_phys_start + va - XEN_VIRT_START; > =C2=A0} > +#define virt_to_maddr(va) virt_to_maddr((unsigned long)(va)) > =C2=A0 > -static inline void *__maddr_to_virt(unsigned long ma) > +static inline void *maddr_to_virt(unsigned long ma) > =C2=A0{ > =C2=A0=C2=A0=C2=A0=C2=A0 /* Offset in the direct map, accounting for pdx = compression */ > =C2=A0=C2=A0=C2=A0=C2=A0 unsigned long va_offset =3D maddr_to_directmapof= f(ma); From xen-devel-bounces@lists.xenproject.org Tue Mar 05 15:16:11 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 15:16:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688825.1073490 (Exim 4.92) (envelope-from ) id 1rhWWU-0002m3-Du; Tue, 05 Mar 2024 15:16:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688825.1073490; Tue, 05 Mar 2024 15:16:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhWWU-0002lw-AK; Tue, 05 Mar 2024 15:16:06 +0000 Received: by outflank-mailman (input) for mailman id 688825; Tue, 05 Mar 2024 15:16:05 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhWWT-0002lq-UG for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 15:16:05 +0000 Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [2a00:1450:4864:20::132]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 48ba4548-db03-11ee-afda-a90da7624cb6; Tue, 05 Mar 2024 16:16:04 +0100 (CET) Received: by mail-lf1-x132.google.com with SMTP id 2adb3069b0e04-51341a5aafbso2883770e87.0 for ; Tue, 05 Mar 2024 07:16:04 -0800 (PST) Received: from [192.168.206.239] ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id k17-20020a192d11000000b00513200975b8sm2260118lfj.43.2024.03.05.07.16.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Mar 2024 07:16:03 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 48ba4548-db03-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709651764; x=1710256564; darn=lists.xenproject.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=hbwnm/lnZ1y0xmDyH+7GJGCVmhMJAz7GGhVKYVpt7jo=; b=WY1Avh1nyEEcHewhVclEPhtA06WY6VcZjhCxLU6DSqd3w4yivA87A2MDZxbnUhmGmj mHDMWB4KPTMPvc7vOU4R+6VuTZs5YCTiFseNvtoEC41j9U6nDpa4W0hDJmIO3ciguEh4 eCOEn4PattfhcYE7W1leOiMAMcjQ7/kwNansCyGLM7RqKsjyFQKr7ohpyN9nRBpjS/4Q jQs8hLTYmpGYyMddGd102WDfnVVI/eb4lznC0l/B7CL8Kbo/xtXUIjauC3KmEO//eLjT OUyjUpMMRTMSJHT+K1c1ptXRbLX5ErTuaB6HZYUhGD1QizIVlWk2afKSgUA7HPT9EU9l 3SpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709651764; x=1710256564; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=hbwnm/lnZ1y0xmDyH+7GJGCVmhMJAz7GGhVKYVpt7jo=; b=p4niSRftshh6PnEjd4wHwLHO3l/lKeQyMw8aN1vbg7G2T41c5nT0oxiYt5TBL/2uDl /hj5lhiYfABArV1n0ShWObYklrklIj6jTq60pLxHFaSHOImbMEcjQ6RVvo6q81iOTSln 2AmXlvmd3WXEqr5zi9bV4dM7VKMHvpOY7Ha4rL8SGpWGLveYW5DyU+c//pMEzDGTwtSy eRMQqpFEJKpJfEQgrAbGR0ZZJuxuxoPAoELrShUpckl9VLZlEGlUBJ+fAGVk2XLHOnqm rpJznNnFjVMfS7fjhZ7jqblq5843SoGThPjlwP5WwTEOpW6zE3NtaYEuB6E7aFoOx5st tLRw== X-Forwarded-Encrypted: i=1; AJvYcCW7n3N2DoUjXpge+FfizgbcIIVAJ6M0QcXDpAunw+PvBeuCVd+EOqVr6OlpsmDdiN4byA5bmlhHOCN7auuVa1ydlWYNXhJB2JijYqkU8ko= X-Gm-Message-State: AOJu0YxjO9zwgbWTyoVzXZlZP9nvxHx/sIqFP6nsnqE0DZe5j4RshFXQ 3Dltnjp6icomcKPVwaRdu81TAF8TOEC3qqut9JgEp2rmXe0KmviH X-Google-Smtp-Source: AGHT+IG9hZHYqYmYABjFYqhyZOBijiGqvkxv+KonlpWkCBRXJI8n6ZZGWWXKTqndkpXe6j7tpCB/hA== X-Received: by 2002:a05:6512:208d:b0:512:9dee:44fe with SMTP id t13-20020a056512208d00b005129dee44femr1267105lfr.26.1709651763912; Tue, 05 Mar 2024 07:16:03 -0800 (PST) Message-ID: <7df33568918536487ec75a05cd47cee128150c0c.camel@gmail.com> Subject: Re: [PATCH 1/2] xen/*/nospec: Provide common versions of evaluate_nospec/block_speculation From: Oleksii To: Andrew Cooper , Julien Grall , Jan Beulich Cc: Roger Pau =?ISO-8859-1?Q?Monn=E9?= , Wei Liu , Stefano Stabellini , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel , Shawn Anastasio , Xen-devel Date: Tue, 05 Mar 2024 16:15:58 +0100 In-Reply-To: <3bc0b828-d3c5-447d-b338-c478d8e337fc@citrix.com> References: <20240304161041.3465897-1-andrew.cooper3@citrix.com> <20240304161041.3465897-2-andrew.cooper3@citrix.com> <5c06c437-b62c-4bee-8694-1be597887718@xen.org> <141ed8a2-df4f-492c-a192-4ffa7f4c8384@suse.com> <4fb729fa-8519-4244-a795-cc66a79cd346@citrix.com> <3bc0b828-d3c5-447d-b338-c478d8e337fc@citrix.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.50.2 (3.50.2-1.fc39) MIME-Version: 1.0 On Mon, 2024-03-04 at 17:50 +0000, Andrew Cooper wrote: > On 04/03/2024 5:40 pm, Julien Grall wrote: > > Hi Andrew, > >=20 > > On 04/03/2024 17:07, Andrew Cooper wrote: > > > On 04/03/2024 4:55 pm, Jan Beulich wrote: > > > > On 04.03.2024 17:46, Julien Grall wrote: > > > > > On 04/03/2024 16:41, Jan Beulich wrote: > > > > > > On 04.03.2024 17:31, Julien Grall wrote: > > > > > > > On 04/03/2024 16:10, Andrew Cooper wrote: > > > > > > > > It is daft to require all architectures to provide > > > > > > > > empty > > > > > > > > implementations of > > > > > > > > this functionality. > > > > > > > Oleksii recenlty sent a similar patch [1]. This was > > > > > > > pushed back > > > > > > > because > > > > > > > from naming, it sounds like the helpers ought to be non- > > > > > > > empty on > > > > > > > every > > > > > > > architecture. > > > > > > >=20 > > > > > > > It would be best if asm-generic provides a safe version > > > > > > > of the > > > > > > > helpers. > > > > > > > So my preference is to not have this patch. This can of > > > > > > > course > > > > > > > change if > > > > > > > I see an explanation why it is empty on Arm (I believe it > > > > > > > should > > > > > > > contain > > > > > > > csdb) and other arch would want the same. > > > > > > Except that there's no new asm-generic/ header here (as > > > > > > opposed to > > > > > > how > > > > > > Oleksii had it). Imo avoiding the need for empty stubs is > > > > > > okay > > > > > > this way, > > > > > > when introducing an asm-generic/ header would not have > > > > > > been. Of > > > > > > course > > > > > > if Arm wants to put something there rather sooner than > > > > > > later, then > > > > > > perhaps the functions better wouldn't be removed from > > > > > > there, just > > > > > > to then > > > > > > be put back pretty soon. > > > > > I am confused. I agree the patch is slightly different, but I > > > > > thought > > > > > the fundamental problem was the block_speculation() > > > > > implementation may > > > > > not be safe everywhere. And it was best to let each > > > > > architecture > > > > > decide > > > > > how they want to implement (vs Xen decide for us the > > > > > default). > > > > >=20 > > > > > Reading the original thread, I thought you had agreed with > > > > > that > > > > > statement. Did I misinterpret? > > > > Yes and no. Whatever is put in asm-generic/ ought to be correct > > > > and > > > > safe > > > > by default, imo. The same doesn't apply to fallbacks put in > > > > place in > > > > headers in xen/: If an arch doesn't provide its own > > > > implementation, it > > > > indicates that the default (fallback) is good enough. Still I > > > > can > > > > easily > > > > see that other views are possible here ... > > >=20 > > > With speculation, there's absolutely nothing we can possibly do > > > in any > > > common code which will be safe generally. > > >=20 > > > But we can make it less invasive until an architecture wants to > > > implement the primitives. > >=20 > > I understand the goal. However, I am unsure it is a good idea to > > provide unsafe just to reduce the arch specific header by a few > > lines. >=20 > It doesn't matter if it's unsafe in the arch header or unsafe in the > common code.=C2=A0 It's still unsafe. >=20 > There is no change in risk here.=C2=A0 There's simply less blind > copy/pasting > of the unsafe form into new architectures in order to get Xen to > compile. So, we're revisiting this topic again. I agree that upon examining the current state of the code around these functions, it appears safe to provide stubs. However, the reason my patch was rejected is that it may not be entirely safe, as Julien pointed out that even with Arm, some functions shouldn't be empty. What I would like to propose is that it might be beneficial, at least in CONFIG_DEBUG=3Dy, to have a warning message. Does that make sense? ~ Oleksii From xen-devel-bounces@lists.xenproject.org Tue Mar 05 15:23:32 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 15:23:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688827.1073499 (Exim 4.92) (envelope-from ) id 1rhWdb-0004tV-3v; Tue, 05 Mar 2024 15:23:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688827.1073499; Tue, 05 Mar 2024 15:23:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhWdb-0004tO-1U; Tue, 05 Mar 2024 15:23:27 +0000 Received: by outflank-mailman (input) for mailman id 688827; Tue, 05 Mar 2024 15:23:25 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhWdZ-0004tI-Nx for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 15:23:25 +0000 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 4edae1a7-db04-11ee-afda-a90da7624cb6; Tue, 05 Mar 2024 16:23:24 +0100 (CET) Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 091A36B64A; Tue, 5 Mar 2024 15:23:24 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id D683013A5B; Tue, 5 Mar 2024 15:23:23 +0000 (UTC) Received: from dovecot-director2.suse.de ([10.150.64.162]) by imap1.dmz-prg2.suse.org with ESMTPSA id +WySMus452UNbQAAD6G6ig (envelope-from ); Tue, 05 Mar 2024 15:23:23 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 4edae1a7-db04-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1709652204; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=dHLIUDCUa+RshrDdjeSgXkl9M+svQd7sCRDJwufl2HQ=; b=luKFbel3ajGFwo/uOI0qZHiEn0+ElOrrQ3NjgV+q1gc2IDHCNPWFK0uDZB+AUl4J73mfUc 9a+hIV/CXUrgAA9U0XXN3fMRxF6FgLLIrvlT8MRTvHvf18G6YVqplRn5K+3OWuGHJ9C2M4 XwOa+6joiv/Nl887bQIQui/E3srwNwU= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1709652204; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=dHLIUDCUa+RshrDdjeSgXkl9M+svQd7sCRDJwufl2HQ=; b=luKFbel3ajGFwo/uOI0qZHiEn0+ElOrrQ3NjgV+q1gc2IDHCNPWFK0uDZB+AUl4J73mfUc 9a+hIV/CXUrgAA9U0XXN3fMRxF6FgLLIrvlT8MRTvHvf18G6YVqplRn5K+3OWuGHJ9C2M4 XwOa+6joiv/Nl887bQIQui/E3srwNwU= Message-ID: <0eeab3e6-f4fb-4723-a674-f5bbdb285356@suse.com> Date: Tue, 5 Mar 2024 16:23:23 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] 9pfsd: allow building with old glibc Content-Language: en-US To: Jan Beulich , "xen-devel@lists.xenproject.org" Cc: Anthony Perard , Wei Liu References: <3aca1707-9eab-4b85-a4ae-e56508b15843@suse.com> From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= In-Reply-To: <3aca1707-9eab-4b85-a4ae-e56508b15843@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: smtp-out1.suse.de; none X-Spamd-Result: default: False [-1.94 / 50.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; XM_UA_NO_VERSION(0.01)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; BAYES_HAM(-2.85)[99.36%]; RCVD_COUNT_THREE(0.00)[3]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:email]; FUZZY_BLOCKED(0.00)[rspamd.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; R_MIXED_CHARSET(1.00)[subject]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Spam-Level: X-Spam-Flag: NO X-Spam-Score: -1.94 On 05.03.24 15:33, Jan Beulich wrote: > Neither pread() / pwrite() nor O_DIRECTORY are available from glibc > 2.11.3 headers without defining (e.g.) _GNU_SOURCE. Supplying the > definition unconditionally shouldn't be a problem, seeing that various > other tools/ components do so, too. > > Signed-off-by: Jan Beulich Fine with me. Reviewed-by: Juergen Gross Juergen From xen-devel-bounces@lists.xenproject.org Tue Mar 05 15:43:50 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 15:43:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688850.1073518 (Exim 4.92) (envelope-from ) id 1rhWxD-0000SD-Q9; Tue, 05 Mar 2024 15:43:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688850.1073518; Tue, 05 Mar 2024 15:43:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhWxD-0000S6-NY; Tue, 05 Mar 2024 15:43:43 +0000 Received: by outflank-mailman (input) for mailman id 688850; Tue, 05 Mar 2024 15:43:42 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhWxC-0000Rw-SF for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 15:43:42 +0000 Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [2a00:1450:4864:20::135]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 23ce3a77-db07-11ee-a1ee-f123f15fe8a2; Tue, 05 Mar 2024 16:43:40 +0100 (CET) Received: by mail-lf1-x135.google.com with SMTP id 2adb3069b0e04-512bc0e8ce1so5925065e87.0 for ; Tue, 05 Mar 2024 07:43:40 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ef11-20020a17090697cb00b00a44bc99cd89sm4468776ejb.42.2024.03.05.07.43.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 Mar 2024 07:43:39 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 23ce3a77-db07-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709653420; x=1710258220; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=c2R+5X1nNtdhwGjUXAHlzPD1ubux/g3yfQA9c9bszBI=; b=GufEDD4qlUmfT/TVXLnzV82bPmHIkyKbwUlaL/9aKZftYgZGdvdOaQ2FPWK8PUsD3u dQkt1I7LQ5/9BZ6g7OdG/XZpH2uZCvscaYCjPv9x0iqg0ytqu6K3nWHg9OLFXvltSzyg Ak1dr+VQKwMJSTrj9O0FZhYW+L5CKceDY3USvvtW1uVNysaB79qEMRVADDQisOc4Ug5C QQ0+wMM8XYWIKrYH5X0LOgMHGiTJR3NrQNJRMZlHgrkUXKpdGJdtxuzDqRnt3B4RtL/K QwoPdaDTeiyeCCXqZt4KBrkgYgSYZKIYn6Y2oycITGhPdG+3ELAY0ogPPppflZuC7876 CdTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709653420; x=1710258220; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=c2R+5X1nNtdhwGjUXAHlzPD1ubux/g3yfQA9c9bszBI=; b=HUqZk/F9OdG0QgY4X4jHhLYQskuNz88hd1hQltUuxb6UDmXy5yXjQaqhCQYHUocvKG ikEZcG5Teoq9mZaR20CpLHgXkQ5INRXVKx8fs4IVrBopbzYh1/+gXpl39mMfYAkowjHe WxIFlijyCg/NUx5M91FK/MJetRf+AODhfsZVcylefmahDUHUgVZbk7YRrXZkenamvYpv SFkFBy51WiaHERatFafAa2RxKK7s/OPofqGKXDiKktZqyqrCRQ3AEHztb4z+4ZLD3YKs J0NlDWhHpTt0S8IfRLcnwJk0WA66F+esaDyaVn/Zwn7mjJGeFkQ179ZgJDSBQ8cLOUAZ Y8FQ== X-Forwarded-Encrypted: i=1; AJvYcCVvXm+TdxdtXRDJ/pEl5DShW0TLqP0lQr2YHjLCIebdiUcgAJ4p6v68QaMcgMSv3FSEHNhM88wS7tftgPmTOPndVmAcQA9nLkz/wOChW/U= X-Gm-Message-State: AOJu0Yw7fMGykmvEzUrsUQgXpeNwWkHHVjxE4v5TOMvFdzvAqKbUFJLU Y+Nmu/v/DFYyl++cUCxuSRXhnEPQmX/QHGzFP2DLp4xUh2USJZlMqqLGSiFJEA== X-Google-Smtp-Source: AGHT+IG7ni1+CrQYF7+X6UI7i6/Z5vxaz6KvxEDt3f/XqRH8IwWOn3AmnNsb4z1A9cz5ALgwXcLG0w== X-Received: by 2002:a05:6512:358c:b0:513:3e94:7ca3 with SMTP id m12-20020a056512358c00b005133e947ca3mr1504465lfr.48.1709653420231; Tue, 05 Mar 2024 07:43:40 -0800 (PST) Message-ID: <3d585715-7729-4a5a-b4e4-c0eb96601882@suse.com> Date: Tue, 5 Mar 2024 16:43:39 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] xen/*/nospec: Provide common versions of evaluate_nospec/block_speculation Content-Language: en-US To: Oleksii Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu , Stefano Stabellini , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel , Shawn Anastasio , Xen-devel , Andrew Cooper , Julien Grall References: <20240304161041.3465897-1-andrew.cooper3@citrix.com> <20240304161041.3465897-2-andrew.cooper3@citrix.com> <5c06c437-b62c-4bee-8694-1be597887718@xen.org> <141ed8a2-df4f-492c-a192-4ffa7f4c8384@suse.com> <4fb729fa-8519-4244-a795-cc66a79cd346@citrix.com> <3bc0b828-d3c5-447d-b338-c478d8e337fc@citrix.com> <7df33568918536487ec75a05cd47cee128150c0c.camel@gmail.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <7df33568918536487ec75a05cd47cee128150c0c.camel@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 05.03.2024 16:15, Oleksii wrote: > I agree that upon examining the current state of the code around these > functions, it appears safe to provide stubs. However, the reason my > patch was rejected is that it may not be entirely safe, as Julien > pointed out that even with Arm, some functions shouldn't be empty. > > What I would like to propose is that it might be beneficial, at least > in CONFIG_DEBUG=y, to have a warning message. Does that make sense? A warning message to what effect? And are you thinking of a build-time warning, or a runtime one? Plus wouldn't different aspects quickly lead to proliferation of warnings? Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 05 15:47:22 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 15:47:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688853.1073528 (Exim 4.92) (envelope-from ) id 1rhX0i-00014S-Cj; Tue, 05 Mar 2024 15:47:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688853.1073528; Tue, 05 Mar 2024 15:47:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhX0i-00014L-9I; Tue, 05 Mar 2024 15:47:20 +0000 Received: by outflank-mailman (input) for mailman id 688853; Tue, 05 Mar 2024 15:47:18 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhX0g-00014F-BU for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 15:47:18 +0000 Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [2607:f8b0:4864:20::72f]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id a496284e-db07-11ee-afda-a90da7624cb6; Tue, 05 Mar 2024 16:47:17 +0100 (CET) Received: by mail-qk1-x72f.google.com with SMTP id af79cd13be357-787990149edso311485085a.3 for ; Tue, 05 Mar 2024 07:47:17 -0800 (PST) Received: from [10.80.67.149] (default-46-102-197-194.interdsl.co.uk. [46.102.197.194]) by smtp.gmail.com with ESMTPSA id n4-20020a0cbe84000000b0069074aa1cbfsm2375256qvi.142.2024.03.05.07.47.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 Mar 2024 07:47:15 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a496284e-db07-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709653636; x=1710258436; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=6alVIozG2iZAob4U/VARNU2Z9ykD/4r9O8K+FFYHQeE=; b=E6zOuz2/UnIEHfWBPJ8SSPkgUXrRs3KgHYGhyB/uti5x9X5CGDRgYZuAmq/G523cuJ WpuJYHLl4Oc6ce6YHsvMSBIDTIhRKXlvK8laj0O9m1K6DqUZcjp8PgOdAp8A7RpQ6LhC dp3q+FJ1sMkH6FXrMN83/5+kk3dJ8xhlp5jOI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709653636; x=1710258436; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=6alVIozG2iZAob4U/VARNU2Z9ykD/4r9O8K+FFYHQeE=; b=NhKX8oSsd8l43vJyfnynDJOKN5+FRnGCW3GQbSMku1DtX2sW0AJ1FiZKcCRcwV8gnT 0/5CoXkFdse0FVM7zw0xeSpH8nlCTQrf6r/HZ0rp43ZoWF3il/0kl0kKvS8PDcCBSH6t T04h5lpGAsNjSK7k47GVMoAfSuEAX2Rw6NqthBd1V73pdevIcZOxfmMuv2QnteAqFK1/ pyaDT0nhmirVfc5P5iogb888kJE3Zi9UwbEZQvEv8tmw3tuyn7o1/3CgKOpPrB3KGfn0 6y2oRzbacmmMlvdyM2QAY8mVAWC5WrKuoP9asP6j3g1xXBJsCsgzCGIG1vn6xIpPVI3x yIPA== X-Forwarded-Encrypted: i=1; AJvYcCWYCqQKrR2lsq0R0DGIwj+IHEpfvbdgUUKGen6WZvW2uDa8L7U9TuscOhEhBNJFjUG7pX/fU3UR4rkbgpZTrXv0hpjJx8zQ6ORs6MUAuE8= X-Gm-Message-State: AOJu0YxQqGWU1t3Bgo31uxWNWhTxYMQP2SSFA1XpB1T6G/lVnxB0c4WA m0eQusN818RiWfRGWiTeMuhGvR+xDtslmVk9TrKDAAoVAhsB1OQec8PguOMVQtA= X-Google-Smtp-Source: AGHT+IGJNdCq11euNvwhoPJadQXk/wU8udr1RLuNTVgd4GZxY9VskOWjjKH+IqxH5epDLVvgY13NHw== X-Received: by 2002:a0c:e84f:0:b0:690:5745:5b48 with SMTP id l15-20020a0ce84f000000b0069057455b48mr2252773qvo.59.1709653636230; Tue, 05 Mar 2024 07:47:16 -0800 (PST) Message-ID: Date: Tue, 5 Mar 2024 15:47:13 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] xen/*/nospec: Provide common versions of evaluate_nospec/block_speculation Content-Language: en-GB To: Jan Beulich , Oleksii Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu , Stefano Stabellini , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel , Shawn Anastasio , Xen-devel , Julien Grall References: <20240304161041.3465897-1-andrew.cooper3@citrix.com> <20240304161041.3465897-2-andrew.cooper3@citrix.com> <5c06c437-b62c-4bee-8694-1be597887718@xen.org> <141ed8a2-df4f-492c-a192-4ffa7f4c8384@suse.com> <4fb729fa-8519-4244-a795-cc66a79cd346@citrix.com> <3bc0b828-d3c5-447d-b338-c478d8e337fc@citrix.com> <7df33568918536487ec75a05cd47cee128150c0c.camel@gmail.com> <3d585715-7729-4a5a-b4e4-c0eb96601882@suse.com> From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <3d585715-7729-4a5a-b4e4-c0eb96601882@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 05/03/2024 3:43 pm, Jan Beulich wrote: > On 05.03.2024 16:15, Oleksii wrote: >> I agree that upon examining the current state of the code around these >> functions, it appears safe to provide stubs. However, the reason my >> patch was rejected is that it may not be entirely safe, as Julien >> pointed out that even with Arm, some functions shouldn't be empty. >> >> What I would like to propose is that it might be beneficial, at least >> in CONFIG_DEBUG=y, to have a warning message. Does that make sense? > A warning message to what effect? And are you thinking of a build-time > warning, or a runtime one? Plus wouldn't different aspects quickly lead > to proliferation of warnings? Putting in a warning for something like this is specifically a bad idea. All it will do is cause people to ignore warnings, and that's the very worst thing Xen could do. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Mar 05 15:50:44 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 15:50:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688855.1073537 (Exim 4.92) (envelope-from ) id 1rhX3v-000316-Pz; Tue, 05 Mar 2024 15:50:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688855.1073537; Tue, 05 Mar 2024 15:50:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhX3v-00030z-N4; Tue, 05 Mar 2024 15:50:39 +0000 Received: by outflank-mailman (input) for mailman id 688855; Tue, 05 Mar 2024 15:50:37 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhX3t-00030t-MO for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 15:50:37 +0000 Received: from mail-oo1-xc2b.google.com (mail-oo1-xc2b.google.com [2607:f8b0:4864:20::c2b]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 1aec3b98-db08-11ee-afda-a90da7624cb6; Tue, 05 Mar 2024 16:50:36 +0100 (CET) Received: by mail-oo1-xc2b.google.com with SMTP id 006d021491bc7-5a16e549113so68593eaf.1 for ; Tue, 05 Mar 2024 07:50:36 -0800 (PST) Received: from localhost ([213.195.118.74]) by smtp.gmail.com with ESMTPSA id pf10-20020a056214498a00b0068f914ac80bsm6380202qvb.50.2024.03.05.07.50.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Mar 2024 07:50:34 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1aec3b98-db08-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709653835; x=1710258635; darn=lists.xenproject.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=cSwqEeyJX27O1JLT5yCpxeLX8dCP1IAM2t3/nC3O9uc=; b=sbkYPhC1K0whr5cN1kjC9iQQYp0aIOJ4M9qXu2Y+bnEPqL2/nWWbKCHVfArHMLUIgj fl8jk6JpQEDyjMlTZV0Skj+q7xfTLKQpYBaasSLojOSIsRRVrKd/MbEQ5vP7MmXYEIP3 bZn97Cgf5UZ06Rx252vxu2bk407rF2qq29o+g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709653835; x=1710258635; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=cSwqEeyJX27O1JLT5yCpxeLX8dCP1IAM2t3/nC3O9uc=; b=lVy1HsQn7HX+vdRHmfA6VfH6N/yxEnik5TrYT0JckBtxVT+0P4+QOIhZ8xRFIj9GTv 6jkHy8nTCo/oXdua2cma8max7Ler40gF8t21bsIxK/C1fRS80pxiKEWF+1raXGYmzT7H 7WoYDFHM1LNekY9fbA0SHgxVBWOW79PUZldwMuob209kqbpOj1sM3TpF6fY312S848uT nZRRO6S3Wq6R56KMPNljWxJlpmaODE95XRvLKIC9eKpcB7BT1rHTGzGLPIRxmksiYrtb fqH3Dx/ZB1oZW1Wo3EANxLhoyeCIH++aVPC8tthRAog/1mXa/IDYLKRs0P5kJNYeD+lr MVXg== X-Gm-Message-State: AOJu0YxDSQNNaQ5ZnGoRP8F1wtX/JEfRdzaSKFjhd6O1QQ+Amw+C5eG9 7ktc5UEfNR9oIInNFdkeSkvWSmH7M3jfzWtO0yj7ImbyRFnhLhkAa0UVRWOPcnA= X-Google-Smtp-Source: AGHT+IE/IMcuOiiWALJVnleoLZ9uK203bZmDz0H+yNwVrrrVSNk44jf3q+brmAGBQFsabIchMvDbPw== X-Received: by 2002:a05:6358:7587:b0:17b:f880:a3c1 with SMTP id x7-20020a056358758700b0017bf880a3c1mr2489415rwf.17.1709653834543; Tue, 05 Mar 2024 07:50:34 -0800 (PST) Date: Tue, 5 Mar 2024 16:50:32 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Stefano Stabellini Cc: xen-devel@lists.xenproject.org, Juergen Gross , Boris Ostrovsky , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Oleksandr Tyshchenko , linux-kernel@vger.kernel.org, Jan Beulich , Andrew Cooper Subject: Re: [PATCH RFC] x86/xen: attempt to inflate the memory balloon on PVH Message-ID: References: <20240220174341.56131-1-roger.pau@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Thu, Feb 22, 2024 at 05:16:09PM -0800, Stefano Stabellini wrote: > On Tue, 20 Feb 2024, Roger Pau Monne wrote: > > When running as PVH or HVM Linux will use holes in the memory map as scratch > > space to map grants, foreign domain pages and possibly miscellaneous other > > stuff. However the usage of such memory map holes for Xen purposes can be > > problematic. The request of holesby Xen happen quite early in the kernel boot > > process (grant table setup already uses scratch map space), and it's possible > > that by then not all devices have reclaimed their MMIO space. It's not > > unlikely for chunks of Xen scratch map space to end up using PCI bridge MMIO > > window memory, which (as expected) causes quite a lot of issues in the system. > > Am I understanding correctly that XEN_BALLOON_MEMORY_HOTPLUG doesn't > help because it becomes available too late in the PVH boot sequence? No, not really, the hoptplug mechanism is available as early as the balloon driver requires, the issue is that when Linux starts making use of such unpopulated ranges (for example in order to map the shared info page) many drivers have not yet reserved their MMIO regions, and so it's not uncommon for the balloon driver to end up using address ranges that would otherwise be used by device BARs for example. This causes havoc, Linux starts to reposition device BARs, sometimes it can manage to re-position them, otherwise some devices are not usable. > > At least for PVH dom0 we have the possibility of using regions marked as > > UNUSABLE in the e820 memory map. Either if the region is UNUSABLE in the > > native memory map, or it has been converted into UNUSABLE in order to hide RAM > > regions from dom0, the second stage translation page-tables can populate those > > areas without issues. > > > > PV already has this kind of logic, where the balloon driver is inflated at > > boot. Re-use the current logic in order to also inflate it when running as > > PVH. onvert UNUSABLE regions up to the ratio specified in EXTRA_MEM_RATIO to > > RAM, while reserving them using xen_add_extra_mem() (which is also moved so > > it's no longer tied to CONFIG_PV). > > > > Signed-off-by: Roger Pau Monné > > --- > > RFC reasons: > > > > * Note that it would be preferred for the hypervisor to provide an explicit > > range to be used as scratch mapping space, but that requires changes to Xen, > > and it's not fully clear whether Xen can figure out the position of all MMIO > > regions at boot in order to suggest a scratch mapping region for dom0. > > > > * Should the whole set of xen_{add,del,chk,inv}_extra_mem() functions be moved > > to a different file? For the purposes of PVH only xen_add_extra_mem() is > > moved and the chk and inv ones are PV specific and might not want moving to > > a separate file just to guard them with CONFIG_PV. > > --- > > arch/x86/include/asm/xen/hypervisor.h | 1 + > > arch/x86/platform/pvh/enlighten.c | 3 ++ > > arch/x86/xen/enlighten.c | 32 +++++++++++++ > > arch/x86/xen/enlighten_pvh.c | 68 +++++++++++++++++++++++++++ > > arch/x86/xen/setup.c | 44 ----------------- > > arch/x86/xen/xen-ops.h | 14 ++++++ > > drivers/xen/balloon.c | 2 - > > 7 files changed, 118 insertions(+), 46 deletions(-) > > > > diff --git a/arch/x86/include/asm/xen/hypervisor.h b/arch/x86/include/asm/xen/hypervisor.h > > index a9088250770f..31e2bf8d5db7 100644 > > --- a/arch/x86/include/asm/xen/hypervisor.h > > +++ b/arch/x86/include/asm/xen/hypervisor.h > > @@ -62,6 +62,7 @@ void xen_arch_unregister_cpu(int num); > > #ifdef CONFIG_PVH > > void __init xen_pvh_init(struct boot_params *boot_params); > > void __init mem_map_via_hcall(struct boot_params *boot_params_p); > > +void __init xen_reserve_extra_memory(struct boot_params *bootp); > > #endif > > > > /* Lazy mode for batching updates / context switch */ > > diff --git a/arch/x86/platform/pvh/enlighten.c b/arch/x86/platform/pvh/enlighten.c > > index 00a92cb2c814..a12117f3d4de 100644 > > --- a/arch/x86/platform/pvh/enlighten.c > > +++ b/arch/x86/platform/pvh/enlighten.c > > @@ -74,6 +74,9 @@ static void __init init_pvh_bootparams(bool xen_guest) > > } else > > xen_raw_printk("Warning: Can fit ISA range into e820\n"); > > > > + if (xen_guest) > > + xen_reserve_extra_memory(&pvh_bootparams); > > + > > pvh_bootparams.hdr.cmd_line_ptr = > > pvh_start_info.cmdline_paddr; > > > > diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c > > index 3c61bb98c10e..a01ca255b0c6 100644 > > --- a/arch/x86/xen/enlighten.c > > +++ b/arch/x86/xen/enlighten.c > > @@ -6,6 +6,7 @@ > > #include > > #include > > #include > > +#include > > #include > > #include > > > > @@ -350,3 +351,34 @@ void xen_arch_unregister_cpu(int num) > > } > > EXPORT_SYMBOL(xen_arch_unregister_cpu); > > #endif > > + > > +/* Amount of extra memory space we add to the e820 ranges */ > > +struct xen_memory_region xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] __initdata; > > + > > +void __init xen_add_extra_mem(unsigned long start_pfn, unsigned long n_pfns) > > +{ > > + unsigned int i; > > + > > + /* > > + * No need to check for zero size, should happen rarely and will only > > + * write a new entry regarded to be unused due to zero size. > > + */ > > + for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) { > > + /* Add new region. */ > > + if (xen_extra_mem[i].n_pfns == 0) { > > + xen_extra_mem[i].start_pfn = start_pfn; > > + xen_extra_mem[i].n_pfns = n_pfns; > > + break; > > + } > > + /* Append to existing region. */ > > + if (xen_extra_mem[i].start_pfn + xen_extra_mem[i].n_pfns == > > + start_pfn) { > > + xen_extra_mem[i].n_pfns += n_pfns; > > + break; > > + } > > + } > > + if (i == XEN_EXTRA_MEM_MAX_REGIONS) > > + printk(KERN_WARNING "Warning: not enough extra memory regions\n"); > > + > > + memblock_reserve(PFN_PHYS(start_pfn), PFN_PHYS(n_pfns)); > > +} > > diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c > > index ada3868c02c2..c28f073c1df5 100644 > > --- a/arch/x86/xen/enlighten_pvh.c > > +++ b/arch/x86/xen/enlighten_pvh.c > > @@ -1,6 +1,7 @@ > > // SPDX-License-Identifier: GPL-2.0 > > #include > > #include > > +#include > > > > #include > > > > @@ -72,3 +73,70 @@ void __init mem_map_via_hcall(struct boot_params *boot_params_p) > > } > > boot_params_p->e820_entries = memmap.nr_entries; > > } > > + > > +/* > > + * Reserve e820 UNUSABLE regions to inflate the memory balloon. > > + * > > + * On PVH dom0 the host memory map is used, RAM regions available to dom0 are > > + * located as the same place as in the native memory map, but since dom0 gets > > + * less memory than the total amount of host RAM the ranges that can't be > > + * populated are converted from RAM -> UNUSABLE. Use such regions (up to the > > + * ratio signaled in EXTRA_MEM_RATIO) in order to inflate the balloon driver at > > + * boot. Doing so prevents the guest (even if just temporary) from using holes > > + * in the memory map in order to map grants or foreign addresses, and > > + * hopefully limits the risk of a clash with a device MMIO region. Ideally the > > + * hypervisor should notify us which memory ranges are suitable for creating > > + * foreign mappings, but that's not yet implemented. > > + */ > > +void __init xen_reserve_extra_memory(struct boot_params *bootp) > > +{ > > + unsigned int i, ram_pages = 0, extra_pages; > > + > > + for (i = 0; i < bootp->e820_entries; i++) { > > + struct boot_e820_entry *e = &bootp->e820_table[i]; > > + > > + if (e->type != E820_TYPE_RAM) > > + continue; > > + ram_pages += PFN_DOWN(e->addr + e->size) - PFN_UP(e->addr); > > + } > > + > > + /* Max amount of extra memory. */ > > + extra_pages = EXTRA_MEM_RATIO * ram_pages; > > + > > + /* > > + * Convert UNUSABLE ranges to RAM and reserve them for foreign mapping > > + * purposes. > > + */ > > + for (i = 0; i < bootp->e820_entries && extra_pages; i++) { > > + struct boot_e820_entry *e = &bootp->e820_table[i]; > > + unsigned long pages; > > + > > + if (e->type != E820_TYPE_UNUSABLE) > > + continue; > > + > > + pages = min(extra_pages, > > + PFN_DOWN(e->addr + e->size) - PFN_UP(e->addr)); > > + > > + if (pages != (PFN_DOWN(e->addr + e->size) - PFN_UP(e->addr))) { > > + struct boot_e820_entry *next; > > + > > + if (bootp->e820_entries == > > + ARRAY_SIZE(bootp->e820_table)) > > + /* No space left to split - skip region. */ > > + continue; > > + > > + /* Split entry. */ > > + next = e + 1; > > + memmove(next, e, > > + (bootp->e820_entries - i) * sizeof(*e)); > > + bootp->e820_entries++; > > + next->addr = PAGE_ALIGN(e->addr) + PFN_PHYS(pages); > > + e->size = next->addr - e->addr; > > + next->size -= e->size; > > Is this really worth doing? Can we just skip this range and continue or > simply break out and call it a day? Or even add the whole range instead? > > The reason I am asking is that I am expecting E820_TYPE_UNUSABLE regions > not to be huge. Splitting one just to cover the few remaining pages out > of extra_pages doesn't seem worth it? No, they are usually quite huge on PVH dom0, because when building a PVH dom0 the E820_TYPE_RAM ranges that are not made available to dom0 because of a dom0_mem option end up being reported as E820_TYPE_UNUSABLE in the e820 provided to dom0. That's mostly the motivation of the change, to be able to reuse those ranges as scratch space for foreign mappings. Ideally the hypervisor should somehow report suitable ranges in the address space for domains to create foreign mappings, but this does require an amount of extra work I don't have time to do ATM, hence this stopgap proposal. > Everything else looks OK to me. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Tue Mar 05 16:17:19 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 16:17:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688860.1073548 (Exim 4.92) (envelope-from ) id 1rhXTW-0007Y5-QJ; Tue, 05 Mar 2024 16:17:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688860.1073548; Tue, 05 Mar 2024 16:17:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhXTW-0007Xy-NW; Tue, 05 Mar 2024 16:17:06 +0000 Received: by outflank-mailman (input) for mailman id 688860; Tue, 05 Mar 2024 16:17:05 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhXTV-0007Xs-Sf for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 16:17:05 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id cc48debd-db0b-11ee-a1ee-f123f15fe8a2; Tue, 05 Mar 2024 17:17:01 +0100 (CET) Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) by support.bugseng.com (Postfix) with ESMTPA id F13D74EE0737; Tue, 5 Mar 2024 17:17:00 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: cc48debd-db0b-11ee-a1ee-f123f15fe8a2 MIME-Version: 1.0 Date: Tue, 05 Mar 2024 17:17:00 +0100 From: Nicola Vetrini To: Jan Beulich Cc: michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, consulting@bugseng.com, andrew.cooper3@citrix.com, roger.pau@citrix.com, bertrand.marquis@arm.com, julien@xen.org, George Dunlap , Wei Liu , xen-devel@lists.xenproject.org, Stefano Stabellini Subject: Re: [XEN PATCH 04/10] xen/public: address violations of MISRA C Rule 20.7 In-Reply-To: References: <0cdc4dc2fcad699a2274277b32de3ee0207d5a2d.1709219010.git.nicola.vetrini@bugseng.com> <82940f688e5a5eee274fa579991ebd15@bugseng.com> <0e131a6795c9d28583e5e8c248843e67@bugseng.com> Message-ID: <388f684d9f161815c13d57ea76c656ac@bugseng.com> X-Sender: nicola.vetrini@bugseng.com Organization: BUGSENG s.r.l. Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 2024-03-05 11:26, Jan Beulich wrote: > On 05.03.2024 11:21, Nicola Vetrini wrote: >> On 2024-02-29 23:49, Stefano Stabellini wrote: >>> On Thu, 29 Feb 2024, Nicola Vetrini wrote: >>>> On 2024-02-29 17:40, Jan Beulich wrote: >>>>> On 29.02.2024 16:27, Nicola Vetrini wrote: >>>>>> --- a/xen/include/public/xen.h >>>>>> +++ b/xen/include/public/xen.h >>>>>> @@ -988,7 +988,7 @@ typedef struct { >>>>>> ((b) >> 8) & 0xFF, ((b) >> 0) & 0xFF, >>>>>> \ >>>>>> ((c) >> 8) & 0xFF, ((c) >> 0) & 0xFF, >>>>>> \ >>>>>> ((d) >> 8) & 0xFF, ((d) >> 0) & 0xFF, >>>>>> \ >>>>>> - e1, e2, e3, e4, e5, e6}} >>>>>> + (e1), (e2), (e3), (e4), (e5), (e6)}} >>>>> >>>>> Why? Wasn't it agreed already that long macro arguments passed on >>>>> (no matter whether to a function, a macro, or like used here) don't >>>>> need parenthesizing? >>>>> >>>> >>>> That applies to all outermost macro invocations, but not to the >>>> innermost one. >>> >>> I don't understand what you mean. Maybe a couple of trivial examples >>> would help. >>> >>> >>>> If you want also aggregate initalizers to be deviated, that could be >>>> done >>>> (provided that the macro arg is not included in some expression, >>>> such >>>> as >>>> "{..., e1 + 1, ...}" >>> >> >> Sorry for the late reply. This is the current state: >> >> #define N(x) somestruct var = {..., x, ...}; // <- not deviated, >> violation here >> #define M(x) N(x) // <- deviated, no violation here >> >> ... >> >> M(0xff); >> >> The violation is resolved by {..., (x), ...} or by saying that when >> "x" >> is a whole expression in its fully expanded form, then we allow it not >> to be needlessly parenthesized, as Jan requested (unless I >> misunderstood >> his reply). > > Well, the thing I continue to have trouble with is "fully expanded > form". > That's not the criteria I'd like to see applied. To me all depends on > how > the macro is written, not what uses of the macro expand to. > Sure. >> In that case, the only this that would still give a >> violation in the above setting is questionable patterns such as >> >> #define Q(x) x, x > > Right. > > #define Q(x) (x, x) > > ought to be okay though, rule-wise, no matter that it's questionable > too. > > Jan -- Nicola Vetrini, BSc Software Engineer, BUGSENG srl (https://bugseng.com) From xen-devel-bounces@lists.xenproject.org Tue Mar 05 16:30:05 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 16:30:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688863.1073558 (Exim 4.92) (envelope-from ) id 1rhXfy-0001L6-Ts; Tue, 05 Mar 2024 16:29:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688863.1073558; Tue, 05 Mar 2024 16:29:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhXfy-0001Kz-QW; Tue, 05 Mar 2024 16:29:58 +0000 Received: by outflank-mailman (input) for mailman id 688863; Tue, 05 Mar 2024 16:29:57 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhXfx-0001Kt-EM for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 16:29:57 +0000 Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [2a00:1450:4864:20::52b]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 996204df-db0d-11ee-a1ee-f123f15fe8a2; Tue, 05 Mar 2024 17:29:55 +0100 (CET) Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-5673b5a356eso1043611a12.0 for ; Tue, 05 Mar 2024 08:29:55 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id fd25-20020a056402389900b00567bada100asm256995edb.71.2024.03.05.08.29.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 Mar 2024 08:29:54 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 996204df-db0d-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709656194; x=1710260994; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:references:cc:to :from:content-language:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=KSuBIH22jFRjQKg6Sd62LtOG78dICAYHseiCEpadfFc=; b=NG8eQatAp8CruKqeYS6SPAGl6l0kv8X/mEEBvW2mKXhQ1ADXqYWvXDG0DmZJLF3JNb gPQwLWT5UCE/oJLpYdliIDTB5m+gWaT0PoXFPr2oxYzhpgrKuGw7U0f3NwRNYX08iFGL C3BkI6xuWtZLYyiEhvCGsfc7pvJZRVzAts7/XAzciO1h3mzGvHwXiHW1oBnZkzTBc1re gyfdyasBWXRW3pL4ChzZ7QpwBbGPoHsiy3AVSUZnb6oxrKxkjbIbEo4iHHuy2nblsVKS C6ZCWGPNfHVyjcasOTT40vaC5jCmr69x35GCgvKQkgiXPW9q9AVAv7ud6fzwzGF76KIa QM9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709656194; x=1710260994; h=content-transfer-encoding:in-reply-to:autocrypt:references:cc:to :from:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=KSuBIH22jFRjQKg6Sd62LtOG78dICAYHseiCEpadfFc=; b=DvucoywuWanDCrBdWJkCm8rO6k478mpokkgj+jPq0L9rIskaZcCzUVhrrIz3tWdZ/k YEfwmhDfjKF31v7T3r53TQtkDycMXh7jXGM9uyKuuWm7sq7kbq1A28fHKm347KXMpk1L KfjHRv4R03pWiNsKdEDlhaMigU7FejlS+xZK0e0WIMediuZE21cQ41EWXa/w+JKs9zt9 z1tEIwYBmuiM0SimA4/P+vlHJA592ErNE48kcgNghWRMdZZpVNE9NCPsC5wzMt7EHMLT j7GiDVSAltGgmlSzKRBrpWG1EkDAEt6WRRtXQcoJREdSh5Le+6OQS6LP4srmoiW519oI lFTA== X-Forwarded-Encrypted: i=1; AJvYcCXY/o4AEqhHmUiq9qP5VawPstDZRngJ/UoDzaW1tguWJfsvcInnfMiGZxGWW8OX4cwRtzxqWRzyN/F+uqAYon18PW4mbzKYdhgFFftfV0w= X-Gm-Message-State: AOJu0YyuXbGrpYT4FNEVAzZvPPnBAgaXYeUdWkzOANteozVwDEmqp7Nh mkUoDje1NoeCRfk1YFLrs4BOJhIxkdiVCZ2jtQDa9Z82BGVcXBdW1gqs0Qnfcw== X-Google-Smtp-Source: AGHT+IEPKO/ccT9FGw5eVo9SAw9LMrSvg5w3kW5yOHocgCHOOi+gU6csjSrVvNvEX4Q3ZoLhJcWUAw== X-Received: by 2002:a50:fc02:0:b0:566:ff31:ed52 with SMTP id i2-20020a50fc02000000b00566ff31ed52mr7347858edr.16.1709656194557; Tue, 05 Mar 2024 08:29:54 -0800 (PST) Message-ID: Date: Tue, 5 Mar 2024 17:29:53 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/3] docs/misra/rules.rst: add rule 5.5 Content-Language: en-US From: Jan Beulich To: Federico Serafini Cc: andrew.cooper3@citrix.com, george.dunlap@citrix.com, julien@xen.org, bertrand.marquis@arm.com, roger.pau@citrix.com, xen-devel@lists.xenproject.org, Stefano Stabellini , roberto.bagnara@bugseng.com, Stefano Stabellini References: <20240213223334.3693410-2-stefano.stabellini@amd.com> <50719397-b053-43e1-9cf7-cc9eae9098ed@suse.com> <40b7465f-4966-43c7-8db3-e28a6cc48445@bugseng.com> <2da73259-a86e-4a13-9fd4-4217372f4b76@suse.com> <3632611e-61ff-455a-9cc1-990a1f663d83@bugseng.com> <7747cb81-8fdb-4a5f-bfd1-c6c9bdb6039a@suse.com> <8e5d4c48-558d-40e2-851a-3eb6bfa5dbfe@suse.com> Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <8e5d4c48-558d-40e2-851a-3eb6bfa5dbfe@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 04.03.2024 17:36, Jan Beulich wrote: > On 04.03.2024 16:39, Federico Serafini wrote: >> On 04/03/24 15:17, Jan Beulich wrote: >>> On 04.03.2024 14:31, Federico Serafini wrote: >>>> On 01/03/24 09:06, Jan Beulich wrote: >>>>> On 01.03.2024 00:28, Stefano Stabellini wrote: >>>>>> On Wed, 14 Feb 2024, Federico Serafini wrote: >>>>>>> On 14/02/24 14:15, Jan Beulich wrote: >>>>>>>> On 14.02.2024 12:27, Federico Serafini wrote: >>>>>>>>> On 14/02/24 09:28, Jan Beulich wrote: >>>>>>>>>> On 13.02.2024 23:33, Stefano Stabellini wrote: >>>>>>>>>>> Signed-off-by: Stefano Stabellini >>>>>>>>>>> --- >>>>>>>>>>> docs/misra/rules.rst | 6 ++++++ >>>>>>>>>>> 1 file changed, 6 insertions(+) >>>>>>>>>>> >>>>>>>>>>> diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst >>>>>>>>>>> index c185366966..931158b354 100644 >>>>>>>>>>> --- a/docs/misra/rules.rst >>>>>>>>>>> +++ b/docs/misra/rules.rst >>>>>>>>>>> @@ -181,6 +181,12 @@ maintainers if you want to suggest a change. >>>>>>>>>>> headers (xen/include/public/) are allowed to retain longer >>>>>>>>>>> identifiers for backward compatibility. >>>>>>>>>>> + * - `Rule 5.5 >>>>>>>>>>> `_ >>>>>>>>>>> + - Required >>>>>>>>>>> + - Identifiers shall be distinct from macro names >>>>>>>>>>> + - Clashes between function-like macros and non-callable entities >>>>>>>>>>> + are allowed. The pattern #define x x is also allowed. >>>>>>>>>> >>>>>>>>>> Just for me to know what exactly is covered (hence also a question >>>>>>>>>> to Roberto as to [to be] implemented Eclair behavior): Even when >>>>>>>>>> the above would be sufficient (and imo better) people frequently >>>>>>>>>> write >>>>>>>>>> >>>>>>>>>> #define a(x, y) b(x, y) >>>>>>>>>> >>>>>>>>>> which, transformed to the specific case here, would then be >>>>>>>>>> >>>>>>>>>> #define a(x, y) a(x, y) >>>>>>>>>> >>>>>>>>>> I'd assume such ought to also be covered, but that's not clear >>>>>>>>>> from the spelling above. >>>>>>>>> >>>>>>>>> I list what happens in some different situations, >>>>>>>>> then we can find the right words for the documentation and/or >>>>>>>>> refine the configuration: >>>>>>>>> >>>>>>>>> If you >>>>>>>>> #define x x >>>>>>>>> and then use `x' as identifier, >>>>>>>>> the resulting violation is deviated (allowed pattern). >>>>>>>>> >>>>>>>>> If you >>>>>>>>> #define a(x, y) a(x, y) >>>>>>>>> and then use `a' as identifier for a non-callable entity, >>>>>>>>> the resulting violation is deviated (no clash with non-callable >>>>>>>>> entities). >>>>>>>>> If you use identifier `a' for a callable entity, the resulting violation >>>>>>>>> is reported: the allowed pattern covers only macros expanding to their >>>>>>>>> own name, in this case the macro name is considered to be >>>>>>>>> `a' only, not a(x, y). >>>>>>>>> >>>>>>>>> If you >>>>>>>>> #define a(x, y) b(x, y) >>>>>>>>> and then use `a' as identifier for a non-callable entity, >>>>>>>>> the resulting violation is deviated (no clash with non-callable >>>>>>>>> entities). >>>>>>>> >>>>>>>> I'm afraid I don't see what violation there is in this case, to >>>>>>>> deviate. As a result I'm also not sure I correctly understand the >>>>>>>> rest of your reply. >>>>>>> >>>>>>> #define a(x, y) b(x, y) >>>>>>> >>>>>>> int a; // Violation of Rule 5.5. >>>>>>> >>>>>>> The macro name `a' that exist before the preprocessing phase, >>>>>>> still exists after the preprocessing phase as identifier for the integer >>>>>>> variable and this is a violation. >>>>>>> >>>>>>>>> If you use `a' as identifier for a callable entity, >>>>>>>>> this is not a violation because after the preprocessing phase, >>>>>>>>> identifier `a' no longer exists. >>>>>>> I correct myself: >>>>>>> if you use `a' as identifier for a *function*, >>>>>>> it is not a violation because after the preprocessing phase >>>>>>> the identifier `a' no longer exists, for example: >>>>>>> >>>>>>> #define a(x, y) b(x, y) >>>>>>> >>>>>>> void a(int x, int y); // Ok. >>>>>> >>>>>> Federico, do you have a better wording suggestion for this rule? >>>>>> >>>>>> Jan, any further requests here? What would you like to see as next step? >>>>> >>>>> A more concise wording proposal would probably help. >>>> >>>> What do you think about: >>>> >>>> diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst >>>> index 1e134ccebc..a975b9a85f 100644 >>>> --- a/docs/misra/rules.rst >>>> +++ b/docs/misra/rules.rst >>>> @@ -181,6 +181,13 @@ maintainers if you want to suggest a change. >>>> headers (xen/include/public/) are allowed to retain longer >>>> identifiers for backward compatibility. >>>> >>>> + * - `Rule 5.5 >>>> `_ >>>> + - Required >>>> + - Identifiers shall be distinct from macro names >>>> + - Macros expanding to their own name are allowed (e.g., #define x x). >>>> + Clashes between names of function-like macros and identifiers of >>>> + non-callable entities are allowed. >>> >>> Imo that still leaves open e.g. the >>> >>> #define a(x, y) a(x, y) >>> >>> case: Permitted ("own name") or not permitted ("a" pretty clearly is expected >>> to be a callable entity here, besides being a function-like macro)? >> >> I would not consider your example as a macro that expands to its own >> name, the macro name is considered to be `a' only. > > That's what I was assuming, and hence my asking back. I think the > above ought to be permitted just like "#define x x", and hence the > suggested text would need expanding, to ... > >> Rather, you example can be used to trigger the "callable-noncallable" >> part of the deviation, for example: >> >> #define a(x, y) a(x, y) >> >> void a(int x, int y); /* Not permitted (callable entity 'a'). */ > > ... prevent this ("not permitted") from happening. I'm pretty sure > you've already found instances of this pattern in our code base. And btw, see https://lists.xen.org/archives/html/xen-devel/2024-03/msg00159.html for yet another slightly different pattern that I'd rather not see becoming "forbidden". Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 05 16:46:46 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 16:46:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688869.1073568 (Exim 4.92) (envelope-from ) id 1rhXw8-0004lL-Du; Tue, 05 Mar 2024 16:46:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688869.1073568; Tue, 05 Mar 2024 16:46:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhXw8-0004lE-A2; Tue, 05 Mar 2024 16:46:40 +0000 Received: by outflank-mailman (input) for mailman id 688869; Tue, 05 Mar 2024 16:46:39 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhXw7-0004l8-7L for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 16:46:39 +0000 Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [2a00:1450:4864:20::536]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id ee47a4ae-db0f-11ee-a1ee-f123f15fe8a2; Tue, 05 Mar 2024 17:46:37 +0100 (CET) Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-563b7b3e3ecso8911477a12.0 for ; Tue, 05 Mar 2024 08:46:36 -0800 (PST) Received: from [192.168.206.239] ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id i17-20020aa7c9d1000000b00567566227a5sm2304735edt.18.2024.03.05.08.46.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Mar 2024 08:46:35 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ee47a4ae-db0f-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709657196; x=1710261996; darn=lists.xenproject.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=v3/NMOHJDs30ug9FBLQJYBaiVg0bhu2Llz7x7XPvcms=; b=I0FrZrFmfa48QsEbsagvG2awhi4/vDOvaSbtGdDLudyFtUeqy7NIjd2mXgiMYkYbzb 7N90QxxySsK4nTNwwdSt7ySjQR4sQfUt6lJYOqPqLXVXkUs59d5xq2Kll0Jm4qZWXn9G EP2QD5TJsSl/LxmxE1abfln2IrDi+wALQqdop1GuxlQQVsqQATTTit4wLZyjNw1JhNuN w+cDiRJ+CoviuUUV1w1aECjVd9fLl4Ed8lgAVnOdNwEfSGpNu1cXnc0FftSSYnRgzd5c bA0Fn/Wd7OFayTDoFsRZIuVxleh4eLrBL5EQZ72jvvx2NtKU3u151OM+HeBXESX4X7/D 2B8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709657196; x=1710261996; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=v3/NMOHJDs30ug9FBLQJYBaiVg0bhu2Llz7x7XPvcms=; b=TPJf95cUaOvwM9hrvMOk5I1Kaj5WLmWlvcR16IjhPumdOITzUYycSIqiXoy6cJ6PRe m1J6SST1mxWsz00KewoaGGlhREPt/G6Y6UoLxILiA0iUl/RqomdrQxdNl/fy8PuE5koT 3GL59mhfES6KslkqsV/dzRI2m1PPg9ZLrWlHnpWGXkl1iZ2vARZRDNACLUijHGwUL2S5 OL+eHgVv6bD1s5TMImHpko5CJCTnKgCnYmpZ511QB2Svg/D3rDsJZOsWjTbIs1I3qPYp cBoJ9DnZexlCNJry/fEYFOmkwDfQMqAOX+DMU6zFJydi05rv8ReFfwhpJ2/wQu91b0eV jArg== X-Forwarded-Encrypted: i=1; AJvYcCUDnm4OUHA9cAh63Qb/xcbJp9TP3fDblnVicGmozS1QF35YtmOg+WTSU9QjfK7luheWgNVYQUYgxeWaowLUkdHwyx2i4WlnbhcRJKbDIuw= X-Gm-Message-State: AOJu0YyXsm3pbqDaGxe6RYbQxTBez1Tm9jGrNFZ6NcxW4TY34jeATRWt m5J8uN6+OKddyJ3CSWDd3DXnUIkRIt9wfO4RCtBJVIUDcdHGnRjB X-Google-Smtp-Source: AGHT+IFbvOra6kA+BjATWpVwUHHLlWB4Cfl0nQJXQi6pCQvnK6OHLA0fquX45PnWympXc1NodmyU6Q== X-Received: by 2002:aa7:c944:0:b0:566:18ba:6b80 with SMTP id h4-20020aa7c944000000b0056618ba6b80mr10271037edt.31.1709657195719; Tue, 05 Mar 2024 08:46:35 -0800 (PST) Message-ID: <5c83394e01f2c52ed14d5a7d2a21730c72e9f6cd.camel@gmail.com> Subject: Re: [PATCH v5 19/23] xen/riscv: add minimal stuff to mm.h to build full Xen From: Oleksii To: Jan Beulich Cc: Alistair Francis , Bob Eshleman , Connor Davis , Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu , xen-devel@lists.xenproject.org Date: Tue, 05 Mar 2024 17:46:34 +0100 In-Reply-To: <1aef844e-4ea9-4651-bba7-9e665abb8892@suse.com> References: <7f5d859b4dbc0593447ade0b221ece17eda68d1e.1708962629.git.oleksii.kurochko@gmail.com> <1aef844e-4ea9-4651-bba7-9e665abb8892@suse.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.50.2 (3.50.2-1.fc39) MIME-Version: 1.0 On Tue, 2024-03-05 at 09:17 +0100, Jan Beulich wrote: > On 26.02.2024 18:39, Oleksii Kurochko wrote: > > --- a/xen/arch/riscv/include/asm/mm.h > > +++ b/xen/arch/riscv/include/asm/mm.h > > @@ -3,11 +3,252 @@ > > =C2=A0#ifndef _ASM_RISCV_MM_H > > =C2=A0#define _ASM_RISCV_MM_H > > =C2=A0 > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > =C2=A0#include > > =C2=A0 > > =C2=A0#define pfn_to_paddr(pfn) ((paddr_t)(pfn) << PAGE_SHIFT) > > =C2=A0#define paddr_to_pfn(pa)=C2=A0 ((unsigned long)((pa) >> PAGE_SHIF= T)) > > =C2=A0 > > +#define paddr_to_pdx(pa)=C2=A0=C2=A0=C2=A0 mfn_to_pdx(maddr_to_mfn(pa)= ) > > +#define gfn_to_gaddr(gfn)=C2=A0=C2=A0 pfn_to_paddr(gfn_x(gfn)) > > +#define gaddr_to_gfn(ga)=C2=A0=C2=A0=C2=A0 _gfn(paddr_to_pfn(ga)) > > +#define mfn_to_maddr(mfn)=C2=A0=C2=A0 pfn_to_paddr(mfn_x(mfn)) > > +#define maddr_to_mfn(ma)=C2=A0=C2=A0=C2=A0 _mfn(paddr_to_pfn(ma)) > > +#define vmap_to_mfn(va)=C2=A0=C2=A0=C2=A0=C2=A0 > > maddr_to_mfn(virt_to_maddr((vaddr_t)va)) >=20 > va needs parenthesizing here. Also why vaddr_t here but ... >=20 > > +#define vmap_to_page(va)=C2=A0=C2=A0=C2=A0 mfn_to_page(vmap_to_mfn(va)= ) > > + > > +static inline unsigned long __virt_to_maddr(unsigned long va) > > +{ > > +=C2=A0=C2=A0=C2=A0 BUG_ON("unimplemented"); > > +=C2=A0=C2=A0=C2=A0 return 0; > > +} > > + > > +static inline void *__maddr_to_virt(unsigned long ma) > > +{ > > +=C2=A0=C2=A0=C2=A0 BUG_ON("unimplemented"); > > +=C2=A0=C2=A0=C2=A0 return NULL; > > +} > > + > > +#define virt_to_maddr(va) __virt_to_maddr((unsigned long)(va)) > > +#define maddr_to_virt(pa) __maddr_to_virt((unsigned long)(pa)) >=20 > ... unsigned long here? In fact for __maddr_to_virt() I think there > better wouldn't be any cast, such that the compiler can spot if, by > mistake, a pointer type value was passed in. Or, wait, we can go > yet further (also on x86): There are no uses of __maddr_to_virt() > except here. Hence the symbol isn't needed (anymore?) in the first > place. I used 'unsigned long' only because I declared __virt_to_maddr() with unsigned long argument, but I think it should should be vaddr_t as in input argument is expected to be VA and for a cast should be used vaddr_t too. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Tue Mar 05 17:30:12 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 17:30:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688874.1073577 (Exim 4.92) (envelope-from ) id 1rhYby-00031S-EI; Tue, 05 Mar 2024 17:29:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688874.1073577; Tue, 05 Mar 2024 17:29:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhYby-00031L-BM; Tue, 05 Mar 2024 17:29:54 +0000 Received: by outflank-mailman (input) for mailman id 688874; Tue, 05 Mar 2024 17:29:52 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhYbw-00030z-Ls for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 17:29:52 +0000 Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [2607:f8b0:4864:20::733]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id f763c41d-db15-11ee-a1ee-f123f15fe8a2; Tue, 05 Mar 2024 18:29:49 +0100 (CET) Received: by mail-qk1-x733.google.com with SMTP id af79cd13be357-7882e94d408so160983185a.0 for ; Tue, 05 Mar 2024 09:29:49 -0800 (PST) Received: from localhost ([213.195.118.74]) by smtp.gmail.com with ESMTPSA id c11-20020a05620a164b00b007882c4a273dsm1930017qko.128.2024.03.05.09.29.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Mar 2024 09:29:46 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f763c41d-db15-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709659787; x=1710264587; darn=lists.xenproject.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=DPgb3b1v+essC29DVEvEo1M5JN3RWeEK3t6EvjJlEYA=; b=EnqIn49pb5eHOY//JTIaHQy6Huaxc8byyrr5NN3wZsivSXLK+GrgwvYSoJ6jkf4yVI zdZnnFJUnS0sflpZdWck5Cwg7i03MZQIZRTbY0ZhPDhWvuUseltW9eVoc2XOP8HR9OIo JvdtW9RSN2+mWob6qo2SD6OCfLCmcQ9wRNAgc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709659787; x=1710264587; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=DPgb3b1v+essC29DVEvEo1M5JN3RWeEK3t6EvjJlEYA=; b=Lr8TcrGuHe/YuwLb90Jo/HT+S4YevT5rjxUsReTF8ctPvncy0jXK+YnLIKKTw+anyo NEoxGIh+/9h5ZqaOqTOH3gPmzGuW/bJ+9kVkR6VaoyzzTMVMBBFrIwb7loPiCcTmsyfY d0sGYaTjYH5Nxg91VwGFgFxyu54iMBOeKOa4EWvH6oXWjMlASk/mZ8P2HeBvTQNf8ObB E5nkPLBCnXGxksefajMv46hkCDyvgylOAwa0lgTgTXrlWZbbaP5/aV8vaAT3MZEQrKZv MzTbiEXL7X9SlnO2OMBwU2FtQQ6vXjJghfArxlYFRClNqg7R1pqQRAUrfxrF4hEKcbtg RN7w== X-Gm-Message-State: AOJu0YzhmhjnOFNgOq1u+wwphbSb3NTpGbYeIDmCogjArOI7nmTwNeI4 05QKBcNDTR2wBSc3+vyNdbtuALDZj/ALuAhZKJhjCx1VDi1DzpOjJPHutCR0TePFSVH51JJxTZq c X-Google-Smtp-Source: AGHT+IGsNH3IV8t4buHHz5+Y1t8P0/DmYCk6KYG3uwBzTNlCrAekWUbVz85diLSOyOpUHgqvYB/UQQ== X-Received: by 2002:ae9:e418:0:b0:788:1909:63bc with SMTP id q24-20020ae9e418000000b00788190963bcmr2493890qkc.51.1709659787152; Tue, 05 Mar 2024 09:29:47 -0800 (PST) Date: Tue, 5 Mar 2024 18:29:44 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: xen-devel@lists.xenproject.org Cc: Doug Goldstein , Stefano Stabellini Subject: Re: [PATCH 2/2] automation: introduce non debug clang based tests Message-ID: References: <20240229095529.17723-1-roger.pau@citrix.com> <20240229095529.17723-3-roger.pau@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20240229095529.17723-3-roger.pau@citrix.com> FWIW, this is not tied to patch 1, so can go in independently. I think it's a worthwhile improvement. Thanks, Roger. On Thu, Feb 29, 2024 at 10:55:29AM +0100, Roger Pau Monne wrote: > The generated code between the debug and release builds can be quite > different, as a note 2ce562b2a413 only manifested in non-debug builds due to > the usage of -O2. > > Duplicate the clang based test in order to test with both debug and non-debug > Xen builds. > > Signed-off-by: Roger Pau Monné > --- > automation/gitlab-ci/test.yaml | 18 ++++++++++++++++-- > 1 file changed, 16 insertions(+), 2 deletions(-) > > diff --git a/automation/gitlab-ci/test.yaml b/automation/gitlab-ci/test.yaml > index 8b7b2e4da92d..dedca794b257 100644 > --- a/automation/gitlab-ci/test.yaml > +++ b/automation/gitlab-ci/test.yaml > @@ -422,13 +422,20 @@ qemu-smoke-x86-64-gcc: > needs: > - debian-stretch-gcc-debug > > -qemu-smoke-x86-64-clang: > +qemu-smoke-x86-64-clang-debug: > extends: .qemu-x86-64 > script: > - ./automation/scripts/qemu-smoke-x86-64.sh pv 2>&1 | tee ${LOGFILE} > needs: > - debian-bookworm-clang-debug > > +qemu-smoke-x86-64-clang: > + extends: .qemu-x86-64 > + script: > + - ./automation/scripts/qemu-smoke-x86-64.sh pv 2>&1 | tee ${LOGFILE} > + needs: > + - debian-bookworm-clang > + > qemu-smoke-x86-64-gcc-pvh: > extends: .qemu-x86-64 > script: > @@ -436,13 +443,20 @@ qemu-smoke-x86-64-gcc-pvh: > needs: > - debian-stretch-gcc-debug > > -qemu-smoke-x86-64-clang-pvh: > +qemu-smoke-x86-64-clang-debug-pvh: > extends: .qemu-x86-64 > script: > - ./automation/scripts/qemu-smoke-x86-64.sh pvh 2>&1 | tee ${LOGFILE} > needs: > - debian-bookworm-clang-debug > > +qemu-smoke-x86-64-clang-pvh: > + extends: .qemu-x86-64 > + script: > + - ./automation/scripts/qemu-smoke-x86-64.sh pvh 2>&1 | tee ${LOGFILE} > + needs: > + - debian-bookworm-clang > + > qemu-smoke-riscv64-gcc: > extends: .qemu-riscv64 > script: > -- > 2.44.0 > From xen-devel-bounces@lists.xenproject.org Tue Mar 05 17:34:58 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 17:34:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688877.1073587 (Exim 4.92) (envelope-from ) id 1rhYgp-0004TR-Ts; Tue, 05 Mar 2024 17:34:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688877.1073587; Tue, 05 Mar 2024 17:34:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhYgp-0004TK-R4; Tue, 05 Mar 2024 17:34:55 +0000 Received: by outflank-mailman (input) for mailman id 688877; Tue, 05 Mar 2024 17:34:54 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhYgo-0004TE-PS for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 17:34:54 +0000 Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [2a00:1450:4864:20::533]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id ac889ac3-db16-11ee-a1ee-f123f15fe8a2; Tue, 05 Mar 2024 18:34:52 +0100 (CET) Received: by mail-ed1-x533.google.com with SMTP id 4fb4d7f45d1cf-565c6cf4819so11672044a12.1 for ; Tue, 05 Mar 2024 09:34:52 -0800 (PST) Received: from [172.20.10.2] (public-gprs207207.centertel.pl. [46.134.148.168]) by smtp.gmail.com with ESMTPSA id lx25-20020a170906af1900b00a45a73caa00sm943841ejb.43.2024.03.05.09.34.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Mar 2024 09:34:51 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ac889ac3-db16-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709660092; x=1710264892; darn=lists.xenproject.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=HLosnp2LjVLREBlCJNw5iVKzbG6ssOMWLMLkl+Dfa8E=; b=MIQyiwh9yVjyEisj8g/d9aGjiHJDWVkH4Xxh1jLIC/sMXyzX1MNGhgeGX3fd4hRIWQ 813eWovZYOWM1qGz7vxaAZmqetpbiaVQk4AjdO5hcxFcN1lMHlkvtr3snEvxTKjOmiTZ h6E/yBx/Jlam+mp5kzeu1U4S3H8yu5k0VfBK4CSaTjZTuKUFjXvoo0S2/tBz0I2RG5bK F/ZLJJcYSZFKlQGEijduG0rfsFmGK7c0xumAYq6c2MGkY0hzONAXO5hDFcX2zIgl/DJj aFrqorhumCRFNVzd1uDjEmSptvhJtk9QQfe0HKjR9drp/Zn4Dxj17d6N8B97hB38oCri NhRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709660092; x=1710264892; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=HLosnp2LjVLREBlCJNw5iVKzbG6ssOMWLMLkl+Dfa8E=; b=WAKCS8XR3nYVfexgns9BfZUAgCKXnRp0dmRpe16i5x4PY5hFrqL5fnz415aGv3U22m ecK96qJIXpcO5Tdo/5qp2VorNxvkOCBMfTLO5YT82Pb1P+G7EaZcwCUJS41btFqj3f5r FdjqfaHcC7e5zbzeP7tkHck5gFUeOKRGM0+MwlLTVGLHwDoCZRP/DaPCQeUTVJtu1wiO mas6RDj//yxGPG1N1FJfKvHGQcqynwD27CJ/pIw8J38Tc13w8w23r84nUn7AYr0z5zzB rA1RRvbpxNUUok6MRXxQcLPxVydt///mkuwNNorEsDVhk2YgvYrPbppEWV2cg/W0wOju zRYA== X-Forwarded-Encrypted: i=1; AJvYcCV/Sx3qoGdBHVZR6KoBiav4cM/GDhUKoYrNJOMQznAp+UgeunM8Ri4cMdq+Oumnp3J2vYVOo6MW8JRPtcRj3Gg/4nT61SEinHVKzg6owes= X-Gm-Message-State: AOJu0YwQne/T7iL1tqORQ4xfBmn+BngReHTeHBL6uFp1yJJZGBZvLRSM GReaAVKK1/0jHZZIPkS1Q44bzUWiUbrmQMNSTvE1b+2kgXmuJShV X-Google-Smtp-Source: AGHT+IFZqMoUCVE4SOi3MgnmLmNQvKP+K0JhwyYqGFXo7Y4R4d+UEn2aXMTSoz+DWXcrBSCcsIjx4g== X-Received: by 2002:a17:906:e4c:b0:a44:b96:2811 with SMTP id q12-20020a1709060e4c00b00a440b962811mr3518384eji.29.1709660092038; Tue, 05 Mar 2024 09:34:52 -0800 (PST) Message-ID: <35595505b2733f7200a62177338cc3ba98f6afaa.camel@gmail.com> Subject: Re: [PATCH v5 18/23] xen/riscv: add minimal stuff to processor.h to build full Xen From: Oleksii To: Jan Beulich Cc: Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu , Alistair Francis , Bob Eshleman , Connor Davis , xen-devel@lists.xenproject.org Date: Tue, 05 Mar 2024 18:34:50 +0100 In-Reply-To: References: <4e1ee99a9ad71015b5e8860d20b63337b526d0e9.1708962629.git.oleksii.kurochko@gmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.50.2 (3.50.2-1.fc39) MIME-Version: 1.0 On Tue, 2024-03-05 at 09:05 +0100, Jan Beulich wrote: > On 26.02.2024 18:39, Oleksii Kurochko wrote: > > --- /dev/null > > +++ b/docs/misc/riscv/booting.txt > > @@ -0,0 +1,8 @@ > > +System requirements > > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > + > > +The following extensions are expected to be supported by a system > > on which > > +Xen is run: > > +- Zihintpause: > > +=C2=A0 On a system that doesn't have this extension, cpu_relax() shoul= d > > be > > +=C2=A0 implemented properly. Otherwise, an illegal instruction > > exception will arise. >=20 > This decision wants justifying in the (presently once again empty) > description. >=20 > Furthermore - will there really be an illegal instruction exception > otherwise? > Isn't it the nature of hints that they are NOPs if not serving their > designated > purpose? You are right, they are NOPs, so I will drop the part about an illegal instruction exception. > > --- a/xen/arch/riscv/arch.mk > > +++ b/xen/arch/riscv/arch.mk > > @@ -5,6 +5,12 @@ $(call cc-options- > > add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS)) > > =C2=A0 > > =C2=A0CFLAGS-$(CONFIG_RISCV_64) +=3D -mabi=3Dlp64 > > =C2=A0 > > +ifeq ($(CONFIG_RISCV_64),y) > > +has_zihintpause =3D $(call as-insn,$(CC) -mabi=3Dlp64 - > > march=3Drv64i_zihintpause, "pause",_zihintpause,) > > +else > > +has_zihintpause =3D $(call as-insn,$(CC) -mabi=3Dilp32 - > > march=3Drv32i_zihintpause, "pause",_zihintpause,) > > +endif >=20 > Considering that down the road likely more such tests will want > adding, I think > this wants further abstracting for the rv32/rv64 difference (ideally > in a way > that wouldn't make future RV128 wrongly and silently take the RV32 > branch). > This would include eliminating the -mabi=3Dlp64 redundancy with what's > visible in > context, perhaps by way of introducing a separate helper macro, e.g. >=20 > riscv-abi-$(CONFIG_RISCV_32) :=3D -mabi=3Dilp32 > riscv-abi-$(CONFIG_RISCV_64) :=3D -mabi=3Dlp64 >=20 > I further see nothing wrong with also using $(riscv-march-y) here. > I.e. > overall >=20 > _zihintpause :=3D $(call as-insn,$(CC) $(riscv-abi-y) $(riscv-march- > y)_zihintpause,"pause",_zihintpause) >=20 > (still with potential of abstracting further through another macro > such > that not every such construct would need to spell out the ABI and > arch > compiler options). >=20 > Plus a macro named has_* imo can be expected to expand to y or n. I > would > suggest to simply drop the "has", thus ... >=20 > > @@ -12,7 +18,7 @@ riscv-march-$(CONFIG_RISCV_ISA_C)=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 :=3D > > $(riscv-march-y)c > > =C2=A0# into the upper half _or_ the lower half of the address space. > > =C2=A0# -mcmodel=3Dmedlow would force Xen into the lower half. > > =C2=A0 > > -CFLAGS +=3D -march=3D$(riscv-march-y) -mstrict-align -mcmodel=3Dmedany > > +CFLAGS +=3D -march=3D$(riscv-march-y)$(has_zihintpause) -mstrict-align > > -mcmodel=3Dmedany >=20 > ... also making the use site look=20 >=20 > > --- a/xen/arch/riscv/include/asm/processor.h > > +++ b/xen/arch/riscv/include/asm/processor.h > > @@ -12,6 +12,9 @@ > > =C2=A0 > > =C2=A0#ifndef __ASSEMBLY__ > > =C2=A0 > > +/* TODO: need to be implemeted */ > > +#define smp_processor_id() 0 > > + > > =C2=A0/* On stack VCPU state */ > > =C2=A0struct cpu_user_regs > > =C2=A0{ > > @@ -53,6 +56,26 @@ struct cpu_user_regs > > =C2=A0=C2=A0=C2=A0=C2=A0 unsigned long pregs; > > =C2=A0}; > > =C2=A0 > > +/* TODO: need to implement */ > > +#define cpu_to_core(cpu)=C2=A0=C2=A0 (0) > > +#define cpu_to_socket(cpu) (0) >=20 > Nit: Like above in smp_processor_id() no need for parentheses here. >=20 > > +static inline void cpu_relax(void) > > +{ > > +#ifdef __riscv_zihintpause > > +=C2=A0=C2=A0=C2=A0 /* > > +=C2=A0=C2=A0=C2=A0=C2=A0 * Reduce instruction retirement. > > +=C2=A0=C2=A0=C2=A0=C2=A0 * This assumes the PC changes. >=20 > What is this 2nd sentence about? cpu_relax() function was copied from Linux kernel and this comment exists there, but I couldn't find in zihintpause spec how it affects PC /IP, so it seems to me it can be dropped. My guess that the 2nd sentece was added because of the following words from the spec: The PAUSE instruction is a HINT that indicates the current hart=E2=80=99= s rate of instruction retirement should be temporarily reduced or paused. The duration of its effect must be bounded and may be zero. =20 So it says reduced or pause, but still doesn't make sense as no matter how long pause takes to complete, it will still advance PC. >=20 > > +=C2=A0=C2=A0=C2=A0=C2=A0 */ > > +=C2=A0=C2=A0=C2=A0 __asm__ __volatile__ ( "pause" ); > > +#else > > +=C2=A0=C2=A0=C2=A0 /* Encoding of the pause instruction */ > > +=C2=A0=C2=A0=C2=A0 __asm__ __volatile__ ( ".insn 0x100000F" ); >=20 > May I ask that you spell out the leading zero here, to make clear > there > aren't, by mistake, one to few zeroes in the middle? I will add a leading zero. The encoding is correct, I've verified with disassembler: c: 0100000f pause =20 ~ Oleksii From xen-devel-bounces@lists.xenproject.org Tue Mar 05 17:38:48 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 17:38:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688879.1073598 (Exim 4.92) (envelope-from ) id 1rhYkW-00053D-DB; Tue, 05 Mar 2024 17:38:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688879.1073598; Tue, 05 Mar 2024 17:38:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhYkW-000536-9t; Tue, 05 Mar 2024 17:38:44 +0000 Received: by outflank-mailman (input) for mailman id 688879; Tue, 05 Mar 2024 17:38:43 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhYkV-000530-BZ for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 17:38:43 +0000 Received: from raptorengineering.com (mail.raptorengineering.com [23.155.224.40]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 33cd889a-db17-11ee-a1ee-f123f15fe8a2; Tue, 05 Mar 2024 18:38:40 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.rptsys.com (Postfix) with ESMTP id 0BCD1828560E; Tue, 5 Mar 2024 11:38:39 -0600 (CST) Received: from mail.rptsys.com ([127.0.0.1]) by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id NBrXQqMEZfNp; Tue, 5 Mar 2024 11:38:38 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by mail.rptsys.com (Postfix) with ESMTP id 62995828550A; Tue, 5 Mar 2024 11:38:38 -0600 (CST) Received: from mail.rptsys.com ([127.0.0.1]) by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id qmqdPUzfW6Io; Tue, 5 Mar 2024 11:38:38 -0600 (CST) Received: from [10.11.0.3] (5.edge.rptsys.com [23.155.224.38]) by mail.rptsys.com (Postfix) with ESMTPSA id E906482854BC; Tue, 5 Mar 2024 11:38:37 -0600 (CST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 33cd889a-db17-11ee-a1ee-f123f15fe8a2 DKIM-Filter: OpenDKIM Filter v2.10.3 mail.rptsys.com 62995828550A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raptorengineering.com; s=B8E824E6-0BE2-11E6-931D-288C65937AAD; t=1709660318; bh=U6T2tYV9e61shtKrEuNart+zmH3iMh8JeDUYXj8kgR8=; h=Message-ID:Date:MIME-Version:To:From; b=W9nkX4+j1BxHJQKp3SXdwTgMzkajljXTnovTLmXEK+JsZSdzbJIVHgQlE8n8zg3Wv gFoV54n3EsD0qseKARy13ozg6JCrRYxx5b2Gk7fqEnYQ5qN0IQIBF6GfuPF+EQH7/T DXxaaOTebkzC1q96QMc0e9qj0wk/e/RRl6otX1WY= X-Virus-Scanned: amavisd-new at rptsys.com Message-ID: <1abef724-eaaf-40f7-83d8-248cae6621b5@raptorengineering.com> Date: Tue, 5 Mar 2024 11:38:37 -0600 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/{RISCV,PPC}/xen.lds: Delete duplicate _erodata definitions Content-Language: en-US To: Andrew Cooper , Xen-devel Cc: Oleksii Kurochko References: <20240305122121.3529541-1-andrew.cooper3@citrix.com> From: Shawn Anastasio In-Reply-To: <20240305122121.3529541-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Andrew, On 3/5/24 6:21 AM, Andrew Cooper wrote: > This is bad copy/paste from somewhere. Retain the second _erodata symbol, > which follows the Build ID, and matches the other architectures. > > No functional change. > > Signed-off-by: Andrew Cooper For the PPC part: Acked-by: Shawn Anastasio Thanks, Shawn From xen-devel-bounces@lists.xenproject.org Tue Mar 05 17:52:43 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 17:52:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688883.1073608 (Exim 4.92) (envelope-from ) id 1rhYxy-0000DU-I6; Tue, 05 Mar 2024 17:52:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688883.1073608; Tue, 05 Mar 2024 17:52:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhYxy-0000DN-El; Tue, 05 Mar 2024 17:52:38 +0000 Received: by outflank-mailman (input) for mailman id 688883; Tue, 05 Mar 2024 17:52:36 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhYxw-0000DH-IC for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 17:52:36 +0000 Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [2a00:1450:4864:20::636]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 2579fa64-db19-11ee-a1ee-f123f15fe8a2; Tue, 05 Mar 2024 18:52:34 +0100 (CET) Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-a293f2280c7so1033179866b.1 for ; Tue, 05 Mar 2024 09:52:34 -0800 (PST) Received: from [172.20.10.2] (public-gprs173058.centertel.pl. [46.134.15.67]) by smtp.gmail.com with ESMTPSA id sa20-20020a1709076d1400b00a4432543b21sm6216422ejc.198.2024.03.05.09.52.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Mar 2024 09:52:33 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 2579fa64-db19-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709661154; x=1710265954; darn=lists.xenproject.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=S6PY3p64Rq0HRsxx//H9v5T+vZVF7lFwR4YKvXX+DGM=; b=XmTOKlZiFpGN3NoTc5w7qXqCvA7vMHzGe2m5TmSk6Eu8q92s9I4SNOy9tBu6ur+Jcc qi5C75hEOSznTqkw8jSEmIPjcbZcHizCMJOoYSUyInQVT4PApgjUEyLvhVVjdany1d0V RI8y9vtAI63qeay998DQYee8YAhUgxAnBRT83UtH1Z1JjxFQskRMLFLGAxh4HOk4+3Hs BYVJvBw1AS/k50zoyfophoa2aLz+iCejqK+LpdbPjJAXaPfflcljWQ5gGPLQVsj3TaS9 nfINJkDZi2jugL7JvekZMtDR8ll8dQBpBfN0ZWGfrZ3tjZ3uqvSkoQNtC/n+z2QH6wlF TQ6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709661154; x=1710265954; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=S6PY3p64Rq0HRsxx//H9v5T+vZVF7lFwR4YKvXX+DGM=; b=PD+TK21tJ+85olJ9oS+XKtguMS5FvzbbchRLK1cyk5x9oXykktHh/1v3V/51oxIN3Y HNkGheIgeqoXfzlJNVyBeHPWFFRwuNkndZN0vrIVILoUQYxSH4H0yUc3QKAMNDGgjr+W uYb5eeKQhHk/KrfdFvCCY9ub/8UQ9SyrlLt8jg2RJZ/BbsSqXoNQrV9y+dsltLjmBc2P /lw2/ww4e7VOHA//7N91uNMuD+tJdkQBtA7QDjZ/FSsBdzD0kCdCwcdN6bRXNu/D2br0 hKIVQBnMb5H099KGquo5KjNoLArlgbzZ3uZyD6AeHMvaLbtEHFVRQ4jvvmmYpb2qFkmA Ut4g== X-Forwarded-Encrypted: i=1; AJvYcCWdBc6mFngoQUpkbAjlv4aJAbhLbgr8AIGbLzDpFcsLLH5mQWxricX8dXDEuJXT8CmPAa7U21eo+AlKcz0TzULUrUuVuOs1CLayYDNBBQE= X-Gm-Message-State: AOJu0Yyw0Qmq68uHiGkNTr86aKTU6CKBFQAp12fwjogN0JGGbrmo69oG o2K4WNC7v3fUpmSsUR4Gnxpbz6SXnlmapW3CRaFwTL83Q61Ox36H X-Google-Smtp-Source: AGHT+IGnuY6622U2WMafCLcqzlJwdExDYBbuY31qiKUeymY9UXru1DQgyJKrOF5+4STEMkFPrfjZQw== X-Received: by 2002:a17:906:6b91:b0:a45:b2d0:87e6 with SMTP id l17-20020a1709066b9100b00a45b2d087e6mr324509ejr.44.1709661153732; Tue, 05 Mar 2024 09:52:33 -0800 (PST) Message-ID: Subject: Re: Xen 4.19 release status tracking list [ March ] From: Oleksii To: Jan Beulich Cc: committers@xenproject.org, community.manager@xenproject.org, Kelly Choi , xen-devel@lists.xenproject.org Date: Tue, 05 Mar 2024 18:52:32 +0100 In-Reply-To: References: <91cc3f76029357f34bd5ca21966c42f0acb73720.camel@gmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.50.2 (3.50.2-1.fc39) MIME-Version: 1.0 On Mon, 2024-03-04 at 09:10 +0100, Jan Beulich wrote: > On 01.03.2024 18:21, Oleksii wrote: > > =C2=A0 * limit passing around of cpu_user_regs [ > > https://lore.kernel.org/xen-devel/ebc330a9-eafa-4858-b5cf-5694c4da911d@= suse.com/ > > ]: > > =C2=A0=C2=A0=C2=A0 new patch series version was sent. >=20 > This was committed already a while ago. >=20 > > =C2=A0 * [PATCH v2 0/5] xen/livepatch: fixes for the pre-apply / post- > > revert > > hooks [ > > https://lore.kernel.org/xen-devel/20240227112528.4540-1-roger.pau@citri= x.com/T/#m620c827bd097522d9d87b7f6511bc1599f6a8c84 > > ] >=20 > This went in last week, I think? Yes, you are right. I overlooked that. Accidentally, searched for the patch series subject, but not patches itself. Thanks ~ Oleksii >=20 > > Please reply with items you would like to see in 4.19 so that > > people > > know what is happening and prioritize accordingly. > > You're welcome to provide a description and use cases of the > > feature > > you're working on. >=20 > "x86/spec-ctrl: IBPB improvements" >=20 > Jan >=20 From xen-devel-bounces@lists.xenproject.org Tue Mar 05 18:57:44 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 18:57:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688890.1073618 (Exim 4.92) (envelope-from ) id 1rhZyg-0001bo-VS; Tue, 05 Mar 2024 18:57:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688890.1073618; Tue, 05 Mar 2024 18:57:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhZyg-0001bh-S1; Tue, 05 Mar 2024 18:57:26 +0000 Received: by outflank-mailman (input) for mailman id 688890; Tue, 05 Mar 2024 18:57:25 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhZyf-0001bV-Bg for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 18:57:25 +0000 Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [2a00:1450:4864:20::130]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 32ee4834-db22-11ee-a1ee-f123f15fe8a2; Tue, 05 Mar 2024 19:57:22 +0100 (CET) Received: by mail-lf1-x130.google.com with SMTP id 2adb3069b0e04-5135540c40dso1143695e87.3 for ; Tue, 05 Mar 2024 10:57:22 -0800 (PST) Received: from [192.168.206.239] ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id i10-20020a056512340a00b00513409c4472sm1309286lfr.31.2024.03.05.10.57.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Mar 2024 10:57:21 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 32ee4834-db22-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709665042; x=1710269842; darn=lists.xenproject.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=5WVydwxx6qmSKti8h+I/VwaGiN8g3FTWWDmAIX3/W9w=; b=ndxj2oqP06EHVj5IvVD24o0LslXzB3FFtT1ENOF0cPCFhffO5vKFgAbZvrWFFRDEXv rb0pXP432g3bQnKMd/PDDagmIJadpWhBRqV5fEA7XtOk23FKWu11pslkRFJ7FCvrcrbp 35KexwFq09NDcNTttQWcs2XkITUHAA+CoTW6qq4VDPgLLIFZ1NIf7EUeUhvhj7C75jkc TkV+znMezVcCL8jz41+MydsRJm1AlnrKzkw56g1LZtCqo1JHbNnB0VfZMDgCHlHL0ML2 fgte0jdxWlG/z8JzL50WxZL/+cV8WzirUM0RMLBUhDWYjgeQFBRH+gM/l6CWH50ai7AL 5iyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709665042; x=1710269842; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=5WVydwxx6qmSKti8h+I/VwaGiN8g3FTWWDmAIX3/W9w=; b=gik4mLPfHBBebbmzdp5Uy8UGuBSt6hP3dl5evT+IVRl40x86E0UiOa3jKkCeD+10go Q/FK1ke65dxip0GD5XhNOUe8YAQ2g0P0ObNi9DGq1D3FoO+mrLlg7ouVCEu3EEYQVLzT Ztl91VmGRaY+cYrfdJwMQhkfikBSs3v3691+sJ4InwnYU44yLKckh1+v6/DzfRGutrmy swzb9f9cIM5d3yeaQVuPSlzGgTmrjRSliGKGp2JBZmdSVD+otrcWMnf+T8vxeBv6xWRN sZTVFT+roiH+1hhC7lYr+TXCzo1H8f337fxtjLGp6Hkamc0ieNOH9bg+rZyXlimPO/O/ F3Lg== X-Forwarded-Encrypted: i=1; AJvYcCV29pGHdZfiVw1oJWKZUpEXVviTrrgaLAGXXt6mNmFrqRnIHP/jmkeLsa3qwS3GwIJjjsG7mTdyTMnqcgz2OKFoNSlZcgGrTJNS/7Z/chI= X-Gm-Message-State: AOJu0YxdsJ0gl3Ga3H9GqSTvhwuNN3Df7z+gOtfy6grEEDarS3LsHa0A zL9tsbmBnTuDG4EDJIeL7E3vQhl1/WAFgOvcLZwy77fFRCv2grAP X-Google-Smtp-Source: AGHT+IFIId0y+YC76TnEEV4w8GFSRvSlBM0QpTQSRnIU72hUrlWcihBk6BKl+zWEpMmJhBUhSAL41g== X-Received: by 2002:ac2:495d:0:b0:513:f34:3f1c with SMTP id o29-20020ac2495d000000b005130f343f1cmr1770708lfi.27.1709665041652; Tue, 05 Mar 2024 10:57:21 -0800 (PST) Message-ID: <3317829c581ff532e27fcc41c69033e520feec1c.camel@gmail.com> Subject: Re: [PATCH 1/2] xen/*/nospec: Provide common versions of evaluate_nospec/block_speculation From: Oleksii To: Jan Beulich Cc: Roger Pau =?ISO-8859-1?Q?Monn=E9?= , Wei Liu , Stefano Stabellini , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel , Shawn Anastasio , Xen-devel , Andrew Cooper , Julien Grall Date: Tue, 05 Mar 2024 19:56:52 +0100 In-Reply-To: <3d585715-7729-4a5a-b4e4-c0eb96601882@suse.com> References: <20240304161041.3465897-1-andrew.cooper3@citrix.com> <20240304161041.3465897-2-andrew.cooper3@citrix.com> <5c06c437-b62c-4bee-8694-1be597887718@xen.org> <141ed8a2-df4f-492c-a192-4ffa7f4c8384@suse.com> <4fb729fa-8519-4244-a795-cc66a79cd346@citrix.com> <3bc0b828-d3c5-447d-b338-c478d8e337fc@citrix.com> <7df33568918536487ec75a05cd47cee128150c0c.camel@gmail.com> <3d585715-7729-4a5a-b4e4-c0eb96601882@suse.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.50.2 (3.50.2-1.fc39) MIME-Version: 1.0 On Tue, 2024-03-05 at 16:43 +0100, Jan Beulich wrote: > On 05.03.2024 16:15, Oleksii wrote: > > I agree that upon examining the current state of the code around > > these > > functions, it appears safe to provide stubs. However, the reason my > > patch was rejected is that it may not be entirely safe, as Julien > > pointed out that even with Arm, some functions shouldn't be empty. > >=20 > > What I would like to propose is that it might be beneficial, at > > least > > in CONFIG_DEBUG=3Dy, to have a warning message. Does that make sense? >=20 > A warning message to what effect? And are you thinking of a build- > time > warning, or a runtime one? Plus wouldn't different aspects quickly > lead > to proliferation of warnings? A warning message about that an empty definition is provided for evaluate_nospec/block_speculation functions, so a developer will know that it can be an issue. Personally, I am OK with having this function empty by default as it is done in the patch with opportunity to being redefined in arch specific code if it is necessary, but I remembered that I had the similar questions in my patch series which probably should be covered in this patch series. Runtime message can also be an option, but I thought about build-time, but I agree that it can lead to proliferation of warning, so not the best one idea. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Tue Mar 05 19:13:48 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 19:13:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688894.1073637 (Exim 4.92) (envelope-from ) id 1rhaER-0005G2-FY; Tue, 05 Mar 2024 19:13:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688894.1073637; Tue, 05 Mar 2024 19:13:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhaER-0005Fv-Cs; Tue, 05 Mar 2024 19:13:43 +0000 Received: by outflank-mailman (input) for mailman id 688894; Tue, 05 Mar 2024 19:13:41 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhaEP-00051h-JD for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 19:13:41 +0000 Received: from wfhigh5-smtp.messagingengine.com (wfhigh5-smtp.messagingengine.com [64.147.123.156]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 7724e8af-db24-11ee-a1ee-f123f15fe8a2; Tue, 05 Mar 2024 20:13:39 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailfhigh.west.internal (Postfix) with ESMTP id C2CF518000D6; Tue, 5 Mar 2024 14:13:34 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Tue, 05 Mar 2024 14:13:35 -0500 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 5 Mar 2024 14:13:32 -0500 (EST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 7724e8af-db24-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= invisiblethingslab.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm1; t=1709666014; x=1709752414; bh=nvOByvjx8k WPG63sTIRe1BmgTRsqS6ZcwNedyy8aBUw=; b=L6mvHLd9wrihsHtOosYggrdoiw ZFihyd4oYfbtRnm4FKjyjxkTdLCcU25GEKv0b8kZmzHRqwoZbxNvtbMridFrya65 wXfSegSOTFQ1wKym+NPQFvSZY+Hm6NpcKXMxMJK20PuiLmiLAgtWh4MCrLaiaSSE ZImwdSQ3JXurzgEeVa8A0m6cKDInjax1xZ4jfoeUb/NgCYcQ3cbqOz61cxb2ujMB d5RQNrt8D4NFDHhZWy+o/znXhLGNHyeLoHJjqwAKoEQgM4Hi53Osu0WqTyo56Jyi ItEKIx061RI/IJu9vtyVmrTUCGJ3UsaEqBsYBbUvPjs8K4dNJWIXYTWtHU0Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1709666014; x= 1709752414; bh=nvOByvjx8kWPG63sTIRe1BmgTRsqS6ZcwNedyy8aBUw=; b=m duf5xbhB+kuAWGNS/+tzky4SMcW1CNQijU+qO3HPNujymJjZjucR9UK/Uf5cLaSk rvdUxa6ZGf6zAtaKNOSi3mv8Dkhtx9fcUs7bc4aqWZkLxc35HpG3xzIyPdaQM3Ox J5NxLDaur+XqRy+fM2q9GqU5b2uSD3KptMjOeV1cK9GyriupEGZ0yhEFZvXuDrp5 0f5PYZipxF9g+npcWUKlQzFjiWV4r/5iKD3yCnIPiCdNr1aT2UtaWjwRUVSe2Uyu 0TWNblTpPydOHrzO14JLfC603glPDk3EjgU+pMorfY3CUC8uYr7pWi/kyR4g+Y/F harrfNhgTQHSFkfllWsNA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrheelgdduudekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkofgjfhggtgfgsehtkeertdertdejnecuhfhrohhmpeforghr vghkucforghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesih hnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpefg ueduhefgvdefheehudejheefudevueeghfekhfehleegveduteeuiedugffgffenucevlh hushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgv khesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhm X-ME-Proxy: Feedback-ID: i1568416f:Fastmail From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= To: qemu-devel@nongnu.org Cc: Jason Andryuk , =?UTF-8?q?Fr=C3=A9d=C3=A9ric=20Pierret=20=28fepitre=29?= , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Stefano Stabellini , Anthony Perard , Paul Durrant , xen-devel@lists.xenproject.org (open list:X86 Xen CPUs) Subject: [PATCH v2 2/2] xen: fix stubdom PCI addr Date: Tue, 5 Mar 2024 20:12:30 +0100 Message-ID: <20240305191312.321127-2-marmarek@invisiblethingslab.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240305191312.321127-1-marmarek@invisiblethingslab.com> References: <20240305191312.321127-1-marmarek@invisiblethingslab.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Frédéric Pierret (fepitre) When running in a stubdomain, the config space access via sysfs needs to use BDF as seen inside stubdomain (connected via xen-pcifront), which is different from the real BDF. For other purposes (hypercall parameters etc), the real BDF needs to be used. Get the in-stubdomain BDF by looking up relevant PV PCI xenstore entries. Signed-off-by: Marek Marczykowski-Górecki --- Changes in v2: - use xs_node_scanf - use %d instead of %u to read values written as %d - add a comment from another iteration of this patch by Jason Andryuk --- hw/xen/xen-host-pci-device.c | 69 +++++++++++++++++++++++++++++++++++- hw/xen/xen-host-pci-device.h | 6 ++++ 2 files changed, 74 insertions(+), 1 deletion(-) diff --git a/hw/xen/xen-host-pci-device.c b/hw/xen/xen-host-pci-device.c index 8c6e9a1716..8ea2a5a4af 100644 --- a/hw/xen/xen-host-pci-device.c +++ b/hw/xen/xen-host-pci-device.c @@ -9,6 +9,8 @@ #include "qemu/osdep.h" #include "qapi/error.h" #include "qemu/cutils.h" +#include "hw/xen/xen-legacy-backend.h" +#include "hw/xen/xen-bus-helper.h" #include "xen-host-pci-device.h" #define XEN_HOST_PCI_MAX_EXT_CAP \ @@ -33,13 +35,67 @@ #define IORESOURCE_PREFETCH 0x00001000 /* No side effects */ #define IORESOURCE_MEM_64 0x00100000 +/* + * Non-passthrough (dom0) accesses are local PCI devices and use the given BDF + * Passthough (stubdom) accesses are through PV frontend PCI device. Those + * either have a BDF identical to the backend's BDF (xen-backend.passthrough=1) + * or a local virtual BDF (xen-backend.passthrough=0) + * + * We are always given the backend's BDF and need to lookup the appropriate + * local BDF for sysfs access. + */ +static void xen_host_pci_fill_local_addr(XenHostPCIDevice *d, Error **errp) +{ + unsigned int num_devs, len, i; + unsigned int domain, bus, dev, func; + char *be_path = NULL; + char path[80]; + + be_path = qemu_xen_xs_read(xenstore, 0, "device/pci/0/backend", &len); + if (!be_path) + goto out; + + if (xs_node_scanf(xenstore, 0, be_path, "num_devs", NULL, "%d", &num_devs) != 1) { + error_setg(errp, "Failed to read or parse %s/num_devs\n", be_path); + goto out; + } + + for (i = 0; i < num_devs; i++) { + snprintf(path, sizeof(path), "dev-%d", i); + if (xs_node_scanf(xenstore, 0, be_path, path, NULL, + "%x:%x:%x.%x", &domain, &bus, &dev, &func) != 4) { + error_setg(errp, "Failed to read or parse %s/%s\n", be_path, path); + goto out; + } + if (domain != d->domain || + bus != d->bus || + dev != d->dev || + func!= d->func) + continue; + snprintf(path, sizeof(path), "vdev-%d", i); + if (xs_node_scanf(xenstore, 0, be_path, path, NULL, + "%x:%x:%x.%x", &domain, &bus, &dev, &func) != 4) { + error_setg(errp, "Failed to read or parse %s/%s\n", be_path, path); + goto out; + } + d->local_domain = domain; + d->local_bus = bus; + d->local_dev = dev; + d->local_func = func; + goto out; + } + +out: + free(be_path); +} + static void xen_host_pci_sysfs_path(const XenHostPCIDevice *d, const char *name, char *buf, ssize_t size) { int rc; rc = snprintf(buf, size, "/sys/bus/pci/devices/%04x:%02x:%02x.%d/%s", - d->domain, d->bus, d->dev, d->func, name); + d->local_domain, d->local_bus, d->local_dev, d->local_func, name); assert(rc >= 0 && rc < size); } @@ -342,6 +398,17 @@ void xen_host_pci_device_get(XenHostPCIDevice *d, uint16_t domain, d->dev = dev; d->func = func; + if (xen_is_stubdomain) { + xen_host_pci_fill_local_addr(d, errp); + if (*errp) + goto error; + } else { + d->local_domain = d->domain; + d->local_bus = d->bus; + d->local_dev = d->dev; + d->local_func = d->func; + } + xen_host_pci_config_open(d, errp); if (*errp) { goto error; diff --git a/hw/xen/xen-host-pci-device.h b/hw/xen/xen-host-pci-device.h index 4d8d34ecb0..270dcb27f7 100644 --- a/hw/xen/xen-host-pci-device.h +++ b/hw/xen/xen-host-pci-device.h @@ -23,6 +23,12 @@ typedef struct XenHostPCIDevice { uint8_t dev; uint8_t func; + /* different from the above in case of stubdomain */ + uint16_t local_domain; + uint8_t local_bus; + uint8_t local_dev; + uint8_t local_func; + uint16_t vendor_id; uint16_t device_id; uint32_t class_code; -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Mar 05 19:13:48 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 19:13:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688893.1073628 (Exim 4.92) (envelope-from ) id 1rhaEQ-00051u-9U; Tue, 05 Mar 2024 19:13:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688893.1073628; Tue, 05 Mar 2024 19:13:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhaEQ-00051n-6Z; Tue, 05 Mar 2024 19:13:42 +0000 Received: by outflank-mailman (input) for mailman id 688893; Tue, 05 Mar 2024 19:13:40 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhaEN-00051b-Uu for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 19:13:40 +0000 Received: from wfhigh5-smtp.messagingengine.com (wfhigh5-smtp.messagingengine.com [64.147.123.156]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 75b348d1-db24-11ee-afda-a90da7624cb6; Tue, 05 Mar 2024 20:13:37 +0100 (CET) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailfhigh.west.internal (Postfix) with ESMTP id 9573F18000D5; Tue, 5 Mar 2024 14:13:31 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Tue, 05 Mar 2024 14:13:32 -0500 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 5 Mar 2024 14:13:29 -0500 (EST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 75b348d1-db24-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= invisiblethingslab.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:from:from:in-reply-to :message-id:mime-version:reply-to:subject:subject:to:to; s=fm1; t=1709666011; x=1709752411; bh=VSUlkpuYOEcRplvlXrjlVafcExCQb+jf CPZC81dIcIs=; b=EVK+O2lxJWxJMjL8Oz2Ln1tBkVKuV/WmtIkwnGMYtjdQR57j 6RJ3sUPaktu1KQ/hDsH9MuntTEwWscWxOpyXdZAVeR1HDGm2Vlg7Hd7lph9Bunjg rUGQlXZN5DauNZchbhTVNcVPEMuusvo7zB3+w/4+42WmfPwse7zXdmkC65kBoO0y Yxh8fdzLB+w60FMcxA+qsaE+ShPFWsFvc06lN3mXV6hnKezs+W2nXrp6QfiOj563 ExhpFgwLMfjuabTXq1fSXwKsy4M94aMYqBnrnoKvnVgQJ3QLUVsVt6ChzGwBnze3 t0FGKN9t/kKdW1veUNNBJiyIQJcd6VTiBxxzXw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:message-id:mime-version:reply-to:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; t=1709666011; x=1709752411; bh=VSUlkpuYOEcRp lvlXrjlVafcExCQb+jfCPZC81dIcIs=; b=qkaTI3+FUieGvdWlljrO44qas8wzF irqTvhOq699K6VfLAbSR/soYcSPh1/aJOOwr8zhS6VFx9GqpV7psSo1WYfMuvqLk 0gry0PSzPdRUHlWsAc8JHcZTPx3JDLe0iOJ9xDSrn+I80hgV8sRedfNZGxNs9ROY a66VjjnjxaYn/1H0aT72UOVsmRgN5U3/70EYi516VZg8Ax4C8F0yVO6H4QNzRrU8 EZMsnWumZa1D72vAAoIl3h0Xith7VTGL1jYIqJ9C/XEzaPecFRqX4+ZPfTUNAgjT MX2rXHJtuPSOF8s0yWdRwcqHC/hfCv3QSYmwaKjqAByXdC1HwJMtgU0sA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrheelgdduudekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkofggtgfgsehtkeertdertdejnecuhfhrohhmpeforghrvghk ucforghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvh hishhisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpeelkefh udelteelleelteetveeffeetffekteetjeehlefggeekleeghefhtdehvdenucevlhhush htvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhes ihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhm X-ME-Proxy: Feedback-ID: i1568416f:Fastmail From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= To: qemu-devel@nongnu.org Cc: Jason Andryuk , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Stefano Stabellini , Anthony Perard , Paul Durrant , xen-devel@lists.xenproject.org (open list:X86 Xen CPUs) Subject: [PATCH v2 1/2] hw/xen: detect when running inside stubdomain Date: Tue, 5 Mar 2024 20:12:29 +0100 Message-ID: <20240305191312.321127-1-marmarek@invisiblethingslab.com> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Introduce global xen_is_stubdomain variable when qemu is running inside a stubdomain instead of dom0. This will be relevant for subsequent patches, as few things like accessing PCI config space need to be done differently. Signed-off-by: Marek Marczykowski-Górecki --- Changes in v2: - use sigend int for domid to match xenstore_read_int() types, domid is in a signed range anyway - fix code style --- hw/xen/xen-legacy-backend.c | 16 ++++++++++++++++ include/hw/xen/xen.h | 1 + system/globals.c | 1 + 3 files changed, 18 insertions(+) diff --git a/hw/xen/xen-legacy-backend.c b/hw/xen/xen-legacy-backend.c index 124dd5f3d6..6bd4e6eb2f 100644 --- a/hw/xen/xen-legacy-backend.c +++ b/hw/xen/xen-legacy-backend.c @@ -603,6 +603,20 @@ static void xen_set_dynamic_sysbus(void) machine_class_allow_dynamic_sysbus_dev(mc, TYPE_XENSYSDEV); } +static bool xen_check_stubdomain(void) +{ + char *dm_path = g_strdup_printf("/local/domain/%d/image", xen_domid); + int32_t dm_domid; + bool is_stubdom = false; + + if (!xenstore_read_int(dm_path, "device-model-domid", &dm_domid)) { + is_stubdom = dm_domid != 0; + } + + g_free(dm_path); + return is_stubdom; +} + void xen_be_init(void) { xenstore = qemu_xen_xs_open(); @@ -616,6 +630,8 @@ void xen_be_init(void) exit(1); } + xen_is_stubdomain = xen_check_stubdomain(); + xen_sysdev = qdev_new(TYPE_XENSYSDEV); sysbus_realize_and_unref(SYS_BUS_DEVICE(xen_sysdev), &error_fatal); xen_sysbus = qbus_new(TYPE_XENSYSBUS, xen_sysdev, "xen-sysbus"); diff --git a/include/hw/xen/xen.h b/include/hw/xen/xen.h index 37ecc91fc3..ecb89ecfc1 100644 --- a/include/hw/xen/xen.h +++ b/include/hw/xen/xen.h @@ -36,6 +36,7 @@ enum xen_mode { extern uint32_t xen_domid; extern enum xen_mode xen_mode; extern bool xen_domid_restrict; +extern bool xen_is_stubdomain; int xen_pci_slot_get_pirq(PCIDevice *pci_dev, int irq_num); int xen_set_pci_link_route(uint8_t link, uint8_t irq); diff --git a/system/globals.c b/system/globals.c index b6d4e72530..ac27d88bd4 100644 --- a/system/globals.c +++ b/system/globals.c @@ -62,6 +62,7 @@ bool qemu_uuid_set; uint32_t xen_domid; enum xen_mode xen_mode = XEN_DISABLED; bool xen_domid_restrict; +bool xen_is_stubdomain; struct evtchn_backend_ops *xen_evtchn_ops; struct gnttab_backend_ops *xen_gnttab_ops; struct foreignmem_backend_ops *xen_foreignmem_ops; -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Mar 05 19:24:23 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 19:24:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688899.1073648 (Exim 4.92) (envelope-from ) id 1rhaOg-0007eF-Dg; Tue, 05 Mar 2024 19:24:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688899.1073648; Tue, 05 Mar 2024 19:24:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhaOg-0007e8-A4; Tue, 05 Mar 2024 19:24:18 +0000 Received: by outflank-mailman (input) for mailman id 688899; Tue, 05 Mar 2024 19:24:17 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhaOf-0007e2-Ek for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 19:24:17 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhaOe-0003Tj-9I; Tue, 05 Mar 2024 19:24:16 +0000 Received: from gw1.octic.net ([88.97.20.152] helo=[10.0.1.240]) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1rhaOe-00069c-0h; Tue, 05 Mar 2024 19:24:16 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID; bh=irgT0X8ufDLqbfEm8C0PZ2axnNEspdMiy57IUXO93jo=; b=LLFHfaV8z+usb+Q41JVUWAI+nV 7PiUPKiiTiUhHeFWO6BAYwBCyfRahZEZBh1qALCzjfTP2SZVF9j9Jre/67ZnlSf76iAs/O4y9tTif paidkOZBe8d2zAiUfX1x8Y1YPyyQeQtVc2uaKhfvHea0wTlgA397V3YUuPOCbbF0Dz+k=; Message-ID: Date: Tue, 5 Mar 2024 19:24:14 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86+Arm: drop (rename) __virt_to_maddr() / __maddr_to_virt() Content-Language: en-GB To: Jan Beulich , "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel , Oleksii Kurochko References: From: Julien Grall In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Jan, The title is quite confusing. I would have expected the macro... On 05/03/2024 08:33, Jan Beulich wrote: > There's no use of them anymore except in the definitions of the non- > underscore-prefixed aliases. Rename the inline functions, adjust the > virt_to_maddr() #define-e, and purge the (x86-only) maddr_to_virt() one, > thus eliminating a bogus cast which would have allowed the passing of a > pointer type variable into maddr_to_virt() to go silently. > > Signed-off-by: Jan Beulich > > --- a/xen/arch/arm/include/asm/mm.h > +++ b/xen/arch/arm/include/asm/mm.h > @@ -256,12 +256,12 @@ static inline void __iomem *ioremap_wc(p > /* Page-align address and convert to frame number format */ > #define paddr_to_pfn_aligned(paddr) paddr_to_pfn(PAGE_ALIGN(paddr)) > > -static inline paddr_t __virt_to_maddr(vaddr_t va) > +static inline paddr_t virt_to_maddr(vaddr_t va) > { > uint64_t par = va_to_par(va); > return (par & PADDR_MASK & PAGE_MASK) | (va & ~PAGE_MASK); > } > -#define virt_to_maddr(va) __virt_to_maddr((vaddr_t)(va)) > +#define virt_to_maddr(va) virt_to_maddr((vaddr_t)(va)) ... to be removed. But you keep it and just overload the name. I know it is not possible to remove the macro because some callers are using pointers (?). So I would rather prefer if we keep the name distinct on Arm. Let see what the other Arm maintainers think. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Tue Mar 05 22:45:46 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2024 22:45:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688905.1073658 (Exim 4.92) (envelope-from ) id 1rhdXO-0002SP-Bl; Tue, 05 Mar 2024 22:45:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688905.1073658; Tue, 05 Mar 2024 22:45:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhdXO-0002SI-8u; Tue, 05 Mar 2024 22:45:30 +0000 Received: by outflank-mailman (input) for mailman id 688905; Tue, 05 Mar 2024 22:45:29 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhdXN-0002SB-1Z for xen-devel@lists.xenproject.org; Tue, 05 Mar 2024 22:45:29 +0000 Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [2a00:1450:4864:20::32f]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 0fc911bd-db42-11ee-afda-a90da7624cb6; Tue, 05 Mar 2024 23:45:27 +0100 (CET) Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-412eddd14b9so8343265e9.2 for ; Tue, 05 Mar 2024 14:45:27 -0800 (PST) Received: from localhost.localdomain (82-64-138-184.subs.proxad.net. [82.64.138.184]) by smtp.googlemail.com with ESMTPSA id iv16-20020a05600c549000b00412ea93220asm3929518wmb.12.2024.03.05.14.45.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Mar 2024 14:45:26 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 0fc911bd-db42-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rabbit-lu.20230601.gappssmtp.com; s=20230601; t=1709678727; x=1710283527; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=ZQZyzUwJSWsCwe+Cq0i2MFZNLiLssuBmZ6olbZklGwQ=; b=fl/pffVl4SQOatIDuuK5uf95/S9Co4JHwZAifyi/r5aLj+YAzyGHnx3nZd2z3/q/Q/ MxyGGyQj9+frps6MfJcYbWP2nkt5Jcja4ev+cmwGxIBwoIWWS1LbORJylCgq/TeyHjWS fYu9ZykqqcMf6HQ4lu8k0cnKDui/l1dCzuYkDu5bY1lrzL2Jn2hW3TgO22e+2WfqIEBd Ckzuy0sD274cc9fvo5X1lNpspbAFf1ayhKLaejcKE3wSf/uoxdJicZXvgwOnqIVLN0+G K6RHxQWu/+YweEXZu0QTjO/R5+pA3bUPtajeDShPaF44iC7JU9cr9GRJjVX7MMrAfvR+ /osA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709678727; x=1710283527; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ZQZyzUwJSWsCwe+Cq0i2MFZNLiLssuBmZ6olbZklGwQ=; b=FypHsEHi4CxMaP1JDRwbg7dxzrQQ1yHXS6LFY1irZuhoYhwHDoyFyAf+NHtY3xUeOI ClIVp+MW7ComKpVvXly4EP6o8+qCyewQbT+cMZnWG0LY3pFmosWH6XdZ/5UfZBHKA9nt 4Cb9Svsgn4PztaoNY/qV3yhBfKJqtgjdbcpokG2sP+XPinVZld6XW2s8gyPq+jdtWIuZ tFeHNydKoTRfAYrfe6eoEIMTlkVHSC7PC/qIjSvMQ2OHmJp+Mv8tFfowNYgtediH0HRN 4bNEhbz097dQxlzaX5T+8rYKdR5J6gOyQwS10+JAt16RGMcKR05GVLTGkNv50OUuqQgY TVOg== X-Gm-Message-State: AOJu0Yw3TsUQ5wHykiUpIYWO9biHRyI5SMohOLCrJXAMXsCa5dl5jWaW MUy220FwRPUfxq970bTKge2jvutzHhao8snun0dT0Kb+Qf9WKO5Wp0dLyyz0qk9UrwgxltEWD+p l X-Google-Smtp-Source: AGHT+IHQlXRMpPhNrWjSdxyRlf4wFuacH8pdw6vr3ZWssC2YZhsc12EP5RouHp/YhU4/Mt6uO6dY8A== X-Received: by 2002:a05:600c:4ed2:b0:412:b674:28ff with SMTP id g18-20020a05600c4ed200b00412b67428ffmr9543857wmq.22.1709678726918; Tue, 05 Mar 2024 14:45:26 -0800 (PST) From: =?UTF-8?q?zithro=20/=20Cyril=20R=C3=A9bert?= To: xen-devel@lists.xenproject.org Cc: =?UTF-8?q?zithro=20/=20Cyril=20R=C3=A9bert?= , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Wei Liu , Anthony PERARD Subject: [PATCH] docs/man: add shutdown reasons to xl (list) man page Date: Tue, 5 Mar 2024 23:45:13 +0100 Message-Id: <019602d6da2ff78e6582b9b6aae6d76216e150c3.1709678713.git.slack@rabbit.lu> X-Mailer: git-send-email 2.39.2 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add the shutdown reasons to the paragraph of "xl list" concerning the shutdown status. I have copy/pasted the explanations from the source code : - tools/xl/xl_info.c (L379) - xen/include/public/sched.h (starting L158) Suggested-by: Roger Pau Monné Signed-off-by: Cyril Rébert / zithro --- docs/man/xl.1.pod.in | 34 ++++++++++++++++++++++++++++++++++ 1 file changed, 34 insertions(+) diff --git a/docs/man/xl.1.pod.in b/docs/man/xl.1.pod.in index bed8393473..2b046f97f1 100644 --- a/docs/man/xl.1.pod.in +++ b/docs/man/xl.1.pod.in @@ -370,6 +370,40 @@ scheduling by the Xen hypervisor. The guest OS has shut down (SCHEDOP_shutdown has been called) but the domain is not dying yet. +There are six shutdown reasons, which will be displayed after the "s" : B<-rscwS>. + +=over 4 + +=over 4 + +=item s- : poweroff + +Domain exited normally. Clean up and kill. + +=item sr : reboot + +Clean up, kill, and then restart. + +=item ss : suspend + +The domain is suspended. Clean up, save suspend info, kill. + +=item sc : crash + +Tell controller we've crashed. + +=item sw : watchdog + +Restart because watchdog time expired. + +=item sS : soft_reset + +Domain asked to perform 'soft reset' for it. The expected behavior is to reset internal Xen state for the domain returning it to the point where it was created but leaving the domain's memory contents and vCPU contexts intact. This will allow the domain to start over and set up all Xen specific interfaces again. + +=back + +=back + =item B The domain has crashed, which is always a violent ending. Usually -- 2.39.2 From xen-devel-bounces@lists.xenproject.org Wed Mar 06 02:09:34 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 02:09:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688916.1073668 (Exim 4.92) (envelope-from ) id 1rhgic-0001oa-7M; Wed, 06 Mar 2024 02:09:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688916.1073668; Wed, 06 Mar 2024 02:09:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhgic-0001oT-3z; Wed, 06 Mar 2024 02:09:18 +0000 Received: by outflank-mailman (input) for mailman id 688916; Wed, 06 Mar 2024 02:09:16 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhgiZ-0001oJ-VF; Wed, 06 Mar 2024 02:09:15 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhgiZ-0001SV-S1; Wed, 06 Mar 2024 02:09:15 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhgiZ-0000DK-G8; Wed, 06 Mar 2024 02:09:15 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rhgiZ-0003gr-Fc; Wed, 06 Mar 2024 02:09:15 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=CptID5NRESZLQxaS7dkbhCX5b/zNdmYAQo6IENi+9XQ=; b=zLullsEvb4HNSUHH20le9bI4Qf XMuS1bsuwhtxIDuxvlll2ERCUyuBFyWmu3uEnhoSNZbEWTLfdvydpiEIQpD4EGEIy9r41netGQ2FX xFdBHlxLCdVGzKtSX0K0A6e70DiZGhgVWIvppdl/AmpDuoKFvPAt2x4taD5LdvkemKgo=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.17-testing test] 184909: tolerable FAIL - PUSHED X-Osstest-Failures: xen-4.17-testing:test-amd64-amd64-xl-multivcpu:guest-localmigrate/x10:fail:heisenbug xen-4.17-testing:test-armhf-armhf-xl-vhd:guest-start:fail:heisenbug xen-4.17-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-4.17-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-4.17-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.17-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-4.17-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.17-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.17-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.17-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.17-testing:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking xen-4.17-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-4.17-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.17-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.17-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.17-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking xen-4.17-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.17-testing:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-4.17-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-4.17-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-4.17-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.17-testing:test-amd64-i386-libvirt-raw:migrate-support-check:fail:nonblocking xen-4.17-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-4.17-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.17-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-4.17-testing:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-4.17-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-4.17-testing:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-4.17-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-4.17-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-4.17-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.17-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-4.17-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-4.17-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.17-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.17-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-4.17-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-4.17-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-4.17-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-4.17-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-4.17-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-4.17-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-4.17-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.17-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-4.17-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-4.17-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-4.17-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-4.17-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.17-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.17-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-4.17-testing:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking xen-4.17-testing:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking xen-4.17-testing:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking xen-4.17-testing:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking xen-4.17-testing:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking xen-4.17-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: xen=54dacb5c02cba4676879ed077765734326b78e39 X-Osstest-Versions-That: xen=6cbccc4071ef49a8c591ecaddfdcb1cc26d28411 From: osstest service owner Date: Wed, 06 Mar 2024 02:09:15 +0000 flight 184909 xen-4.17-testing real [real] flight 184913 xen-4.17-testing real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/184909/ http://logs.test-lab.xenproject.org/osstest/logs/184913/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-multivcpu 20 guest-localmigrate/x10 fail pass in 184913-retest test-armhf-armhf-xl-vhd 13 guest-start fail pass in 184913-retest Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-vhd 14 migrate-support-check fail in 184913 never pass test-armhf-armhf-xl-vhd 15 saverestore-support-check fail in 184913 never pass test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 184838 test-armhf-armhf-libvirt 16 saverestore-support-check fail like 184838 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 184838 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop fail like 184838 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop fail like 184838 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 184838 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 184838 test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail like 184838 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop fail like 184838 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 184838 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop fail like 184838 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184838 test-amd64-i386-libvirt-xsm 15 migrate-support-check fail never pass test-amd64-i386-xl-pvshim 14 guest-start fail never pass test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-amd64-i386-libvirt 15 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-check fail never pass test-amd64-i386-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-check fail never pass test-arm64-arm64-xl 15 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-check fail never pass test-arm64-arm64-xl 16 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 15 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 15 migrate-support-check fail never pass test-armhf-armhf-libvirt 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 16 saverestore-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-check fail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-check fail never pass test-arm64-arm64-xl-vhd 14 migrate-support-check fail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-check fail never pass version targeted for testing: xen 54dacb5c02cba4676879ed077765734326b78e39 baseline version: xen 6cbccc4071ef49a8c591ecaddfdcb1cc26d28411 Last test of basis 184838 2024-03-02 01:55:37 Z 4 days Testing same since 184909 2024-03-05 11:07:12 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Anthony PERARD Jan Beulich Jason Andryuk Roger Pau Monné jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-dom0pvh-xl-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-qemuu-freebsd11-amd64 pass test-amd64-amd64-qemuu-freebsd12-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-dom0pvh-xl-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu fail test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-armhf-armhf-libvirt-qcow2 pass test-amd64-amd64-xl-qcow2 pass test-arm64-arm64-libvirt-raw pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-libvirt-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-arm64-arm64-xl-vhd pass test-armhf-armhf-xl-vhd fail test-amd64-i386-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these 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 6cbccc4071..54dacb5c02 54dacb5c02cba4676879ed077765734326b78e39 -> stable-4.17 From xen-devel-bounces@lists.xenproject.org Wed Mar 06 03:54:27 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 03:54:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688935.1073725 (Exim 4.92) (envelope-from ) id 1rhiM8-0007NF-L4; Wed, 06 Mar 2024 03:54:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688935.1073725; Wed, 06 Mar 2024 03:54:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhiM8-0007N8-IR; Wed, 06 Mar 2024 03:54:12 +0000 Received: by outflank-mailman (input) for mailman id 688935; Wed, 06 Mar 2024 03:54:10 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhiM6-0007My-QD; Wed, 06 Mar 2024 03:54:10 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhiM6-0003J8-Ky; Wed, 06 Mar 2024 03:54:10 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhiM6-0004v4-BB; Wed, 06 Mar 2024 03:54:10 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rhiM6-0001EX-Al; Wed, 06 Mar 2024 03:54:10 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=dPx5vMapvUbpMPtSb9sO/SaFZyfi+lD2TDDV+/4P1Go=; b=4E0dev2SY9aoBfBWLpYl9JKuDV qS/ibd933RO4hvAFCQPe/sHD+iqEJlBmwqJk3aLqTYAFU2CvoVJ9JmyYeOANZ8ajLU8SIMA+zS/P4 4HyPkq7EHGl3S2MRYkAgj6ZQbOoLeaY8RQxx2ZRmvAHDQTdqFdRLm+pbTLUo9oAsqzNE=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.18-testing test] 184910: tolerable FAIL - PUSHED X-Osstest-Failures: xen-4.18-testing:test-amd64-amd64-libvirt-vhd:guest-start/debian.repeat:fail:heisenbug xen-4.18-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.18-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-4.18-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.18-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.18-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.18-testing:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking xen-4.18-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-4.18-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.18-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.18-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking xen-4.18-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.18-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.18-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.18-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.18-testing:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-4.18-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-4.18-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-4.18-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.18-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.18-testing:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-4.18-testing:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-4.18-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-4.18-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-4.18-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.18-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-4.18-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.18-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-4.18-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-4.18-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.18-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-4.18-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-4.18-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-4.18-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.18-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-4.18-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-4.18-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-4.18-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.18-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-4.18-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-4.18-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-4.18-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-4.18-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-4.18-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-4.18-testing:test-amd64-i386-libvirt-raw:migrate-support-check:fail:nonblocking xen-4.18-testing:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking xen-4.18-testing:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking xen-4.18-testing:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking xen-4.18-testing:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking xen-4.18-testing:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking xen-4.18-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-4.18-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-4.18-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-4.18-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-4.18-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=fd7cb7a1d0433049d8fc59444d0e91b71728763e X-Osstest-Versions-That: xen=498b3624d0ecc1267773e6482fd0b732e90c4511 From: osstest service owner Date: Wed, 06 Mar 2024 03:54:10 +0000 flight 184910 xen-4.18-testing real [real] flight 184915 xen-4.18-testing real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/184910/ http://logs.test-lab.xenproject.org/osstest/logs/184915/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-libvirt-vhd 19 guest-start/debian.repeat fail pass in 184915-retest Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail blocked in 184813 test-armhf-armhf-libvirt 16 saverestore-support-check fail like 184813 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop fail like 184813 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop fail like 184813 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop fail like 184813 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 184813 test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail like 184813 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 184813 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 184813 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184813 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop fail like 184813 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 184813 test-amd64-i386-libvirt-xsm 15 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-check fail never pass test-amd64-i386-xl-pvshim 14 guest-start fail never pass test-amd64-i386-libvirt 15 migrate-support-check fail never pass test-amd64-amd64-libvirt 15 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-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-check fail never pass test-arm64-arm64-xl 15 migrate-support-check fail never pass test-arm64-arm64-xl 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-check fail never pass test-armhf-armhf-libvirt 15 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-check fail never pass test-amd64-i386-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-check fail never pass test-arm64-arm64-xl-vhd 14 migrate-support-check fail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 15 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-check fail never pass version targeted for testing: xen fd7cb7a1d0433049d8fc59444d0e91b71728763e baseline version: xen 498b3624d0ecc1267773e6482fd0b732e90c4511 Last test of basis 184813 2024-02-28 23:10:45 Z 6 days Testing same since 184910 2024-03-05 11:07:13 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Anthony PERARD Jan Beulich Jason Andryuk Roger Pau Monné jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-dom0pvh-xl-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-qemuu-freebsd11-amd64 pass test-amd64-amd64-qemuu-freebsd12-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-dom0pvh-xl-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-armhf-armhf-libvirt-qcow2 pass test-amd64-amd64-xl-qcow2 pass test-arm64-arm64-libvirt-raw pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-libvirt-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd fail test-arm64-arm64-xl-vhd pass test-armhf-armhf-xl-vhd pass test-amd64-i386-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these 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 498b3624d0..fd7cb7a1d0 fd7cb7a1d0433049d8fc59444d0e91b71728763e -> stable-4.18 From xen-devel-bounces@lists.xenproject.org Wed Mar 06 06:10:13 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 06:10:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688957.1073784 (Exim 4.92) (envelope-from ) id 1rhkTV-0008Bv-PC; Wed, 06 Mar 2024 06:09:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688957.1073784; Wed, 06 Mar 2024 06:09:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhkTV-0008Bo-MZ; Wed, 06 Mar 2024 06:09:57 +0000 Received: by outflank-mailman (input) for mailman id 688957; Wed, 06 Mar 2024 05:16:01 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhjdI-0001qR-VI for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 05:16:01 +0000 Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [2607:f8b0:4864:20::42c]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 9ce52d48-db78-11ee-a1ee-f123f15fe8a2; Wed, 06 Mar 2024 06:15:58 +0100 (CET) Received: by mail-pf1-x42c.google.com with SMTP id d2e1a72fcca58-6e62c65865cso442371b3a.2 for ; Tue, 05 Mar 2024 21:15:58 -0800 (PST) Received: from FLYINGPENG-MB1.tencent.com ([103.7.29.30]) by smtp.gmail.com with ESMTPSA id sh14-20020a17090b524e00b0029a7951c4a3sm12873809pjb.41.2024.03.05.21.15.54 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Tue, 05 Mar 2024 21:15:55 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 9ce52d48-db78-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709702156; x=1710306956; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=dYBvsZ67CiVZB3bSb45jpPKBS2zsFhtXBG4EnbIe+mI=; b=fUsKLL+ywLtDYpCy7YIaK/vMFXRd0871D/zCN+sTCYNS0UGJeAQJvu6Ap6Wl12EdRS XwdsCT1I+iuv1fIJtZsP7pBipDF5PWnB2sFVQXVMUxx2S3U20NebyYErMVnuwfz5qH18 UnWZyDWdZx33O1pC82W+GUv5Pn/dCt959WLJBzygxnuHFyWr83rchWXMKg8cOqbBbRij 2l9DeXHXKASfCJ3topGpre35M5tZa9fkvxvUmuNzICJE/73blGSZs3H2asscFKfFvTfh gJb6xXRQsX6HDi8v16+MWCcsYYqFyu45Y87/+zQuVfy+rPeldlinJDWcII+AjOfFoCFA 7Z9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709702156; x=1710306956; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=dYBvsZ67CiVZB3bSb45jpPKBS2zsFhtXBG4EnbIe+mI=; b=DeMuVBA4rKxBbm4fFhZTg/nU02hTFnLwdgjxgFcOLTVLO+GupQktNV7uRSSwM/cjTU nLRUfZNhvbJ03/1YqYmVH0OKrT9a6TRku/V1AvUJVxeCecemfQ+y9Vbe97hjBfmNlPS+ QDIbDF/brwEXDZDx7MKHnFpvCJB+uIcjZvMv6x0quKTIu5LUqOesEN7iZOdSnD8koFd1 U+tvVcaDfbwtbuNFd8Y0Ev9O+fFjKQ/5qqk+cNtOizfR93cOLGU4WdbTFGkxyNROq3Vk RXZ0v9685QxKDiWMvwQfmdoe8XHd9pM9ArprmZ2y/VIQrKlrPuxhMzyC6fvX47XVUJr9 qTBQ== X-Gm-Message-State: AOJu0YwvFF9pm53LuMNfoI1B5n/CrDtjTly+PtonvwSJddTPStUPDwV/ xu9UNl7KjurQ3rnbj3Db8sKT4g3YRJmqLsV7693I1q7jiVFv2t0t X-Google-Smtp-Source: AGHT+IEK+PqX3TVEP58pvrMY+azSjMdcESbNoY3Ftl0I8D/KGELEGWy2O6l0HBbkW4aA5JihnOog6g== X-Received: by 2002:a05:6a20:3d82:b0:1a1:216e:bdf8 with SMTP id s2-20020a056a203d8200b001a1216ebdf8mr3995682pzi.14.1709702156292; Tue, 05 Mar 2024 21:15:56 -0800 (PST) From: flyingpenghao@gmail.com X-Google-Original-From: flyingpeng@tencent.com To: roger.pau@citrix.com Cc: xen-devel@lists.xenproject.org, Peng Hao Subject: [PATCH] xen/blkback: use kmap_local_page() Date: Wed, 6 Mar 2024 13:15:48 +0800 Message-Id: <20240306051548.90954-1-flyingpeng@tencent.com> X-Mailer: git-send-email 2.39.3 (Apple Git-145) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Peng Hao From: Peng Hao Use kmap_local_page() instead of kmap_atomic() which has been deprecated. Signed-off-by: Peng Hao --- drivers/block/xen-blkback/blkback.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c index 4defd7f387c7..cce534f43292 100644 --- a/drivers/block/xen-blkback/blkback.c +++ b/drivers/block/xen-blkback/blkback.c @@ -937,8 +937,8 @@ static int xen_blkbk_parse_indirect(struct blkif_request *req, if ((n % SEGS_PER_INDIRECT_FRAME) == 0) { /* Map indirect segments */ if (segments) - kunmap_atomic(segments); - segments = kmap_atomic(pages[n/SEGS_PER_INDIRECT_FRAME]->page); + kunmap_local(segments); + segments = kmap_local_page(pages[n/SEGS_PER_INDIRECT_FRAME]->page); } i = n % SEGS_PER_INDIRECT_FRAME; -- 2.31.1 From xen-devel-bounces@lists.xenproject.org Wed Mar 06 06:12:52 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 06:12:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688961.1073793 (Exim 4.92) (envelope-from ) id 1rhkWJ-000191-6u; Wed, 06 Mar 2024 06:12:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688961.1073793; Wed, 06 Mar 2024 06:12:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhkWJ-00018u-4J; Wed, 06 Mar 2024 06:12:51 +0000 Received: by outflank-mailman (input) for mailman id 688961; Wed, 06 Mar 2024 06:12:50 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhkWI-00018i-Fn; Wed, 06 Mar 2024 06:12:50 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhkWI-0006W2-D2; Wed, 06 Mar 2024 06:12:50 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhkWI-0003H8-3q; Wed, 06 Mar 2024 06:12:50 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rhkWI-0005Xz-3O; Wed, 06 Mar 2024 06:12:50 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=AwUgQTmiMu6LHATA021wliZQfKa6GIyTtC5pOeHnKsA=; b=2AOAYoPM5qL61gB0fYfy74v682 UmxTYOqPyEwFJM0wR+iv+30UbStJayrqbJLu7c7yKm3iPdWo/qehndmx4yc606eqCr3DNkvdTLlW8 AWJHWaHRvGGLxCMt70fXTtxZCKZnFThcJTsmcgjENshfOsCOy67fstKB1Rsa5un+N0TY=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [ovmf test] 184916: all pass - PUSHED X-Osstest-Versions-This: ovmf=e60529df58e43f4d1652f862c6652b61f21e0691 X-Osstest-Versions-That: ovmf=2a0d4a2641a706d6b964dea0c95b1e0362194f57 From: osstest service owner Date: Wed, 06 Mar 2024 06:12:50 +0000 flight 184916 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/184916/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf e60529df58e43f4d1652f862c6652b61f21e0691 baseline version: ovmf 2a0d4a2641a706d6b964dea0c95b1e0362194f57 Last test of basis 184908 2024-03-05 09:12:54 Z 0 days Testing same since 184916 2024-03-06 03:43:04 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Dhaval Dhaval Sharma 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-pvops pass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git 2a0d4a2641..e60529df58 e60529df58e43f4d1652f862c6652b61f21e0691 -> xen-tested-master From xen-devel-bounces@lists.xenproject.org Wed Mar 06 07:22:33 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 07:22:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688967.1073803 (Exim 4.92) (envelope-from ) id 1rhlbX-00020H-2m; Wed, 06 Mar 2024 07:22:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688967.1073803; Wed, 06 Mar 2024 07:22:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhlbX-00020A-0A; Wed, 06 Mar 2024 07:22:19 +0000 Received: by outflank-mailman (input) for mailman id 688967; Wed, 06 Mar 2024 07:22:18 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhlbV-000204-V9 for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 07:22:17 +0000 Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [2a00:1450:4864:20::62d]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 426ff9ee-db8a-11ee-afda-a90da7624cb6; Wed, 06 Mar 2024 08:22:16 +0100 (CET) Received: by mail-ej1-x62d.google.com with SMTP id a640c23a62f3a-a449c5411e1so650130866b.1 for ; Tue, 05 Mar 2024 23:22:16 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id z20-20020a170906271400b00a441cb52bfcsm6862217ejc.165.2024.03.05.23.22.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 Mar 2024 23:22:15 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 426ff9ee-db8a-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709709736; x=1710314536; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=br3ZeMiDjo2cgWcMnb81aMNlRz+DfjDJhOCVrdZSIiw=; b=D0eMGTKozwchYyPxASWDISwGOexWsFpitmdDDDlom36+v/XqiQRCeCiPnM3JTZb+lG ISOdAKETmmwaoeaiwRVr/xHauBz/JrQgpnl9hHzVnDcuJHsEGf9kd0+sScITX+IyoDYI 1FlrBhj1d7xkfnaXtX3M1VsGrgvo4hYmI6LXOddMuj1BSkMasBHfX2pWYo4OVU8QgrSK M/SmTN+yQx3b9Mr3d1D0ZWjQU3PFNyfOb/EQTOEpHbrGRNH+eKf14z80K0jlfMW0r4Qo YabQ+/sq7Q+hdpS1YTvdGK4GOc1xt45+utfCQqQYC1GxPAut36r+co3UK6eLTg/9baER ptxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709709736; x=1710314536; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=br3ZeMiDjo2cgWcMnb81aMNlRz+DfjDJhOCVrdZSIiw=; b=B36OEFusW0VwZZ0chK4EEHLK+xAdK1K5Moc0EfyjH7VMUHPJOVthVRX8pVzXfg8b5e ay9+LAaBJ6jU/6WB3pb/yGE7Z6Njo3iIdckFULrUvYYfysFNycLndbcFwP5o63iYC1de iostnDM+L3Z86kuYLOfXzwVmo6lSLxu3qzFPkKIG/l/I48AQ7AAXw2z9QdJq2AF2HM8K dZU4NEC1a14Rk5CfdwwcEe896pWTne2wIhIhIpjMr5cRTKjxTIdyVvHGe5payuVXMXTi JJvAUjf6JUFoNmPUmha3dC4tfGPjas95fETz7beucaRVBjd7nplrR/pLl0sPI6MNtxSs y1zA== X-Forwarded-Encrypted: i=1; AJvYcCWAM9OGzEEJUVTOUTxiEOdZv3iKukgxeC5S/D5goX2gt+FudOBBcjaXQ+nJHR8s0zXpKvJsOVuMdOnmtHFYj+82kp4jKWRD7NFpLa6ydAE= X-Gm-Message-State: AOJu0YwNmX0TUPwEfg41vZaqnD7HWcX7l2bkD2t1YefN3di0AwZXhxBg GSNw77gYVcM7rLqo1mhb74ovjeCFJPBaoFvgle+2b/USMya4xVRiM8eVIbn57w== X-Google-Smtp-Source: AGHT+IE3zP2G1YtIf6OziwX2utqvDz11aVb/NhvXVHwYruSNo3yfAZ2zlmmUkrmbm5YLKAf9qWxiAw== X-Received: by 2002:a17:906:398a:b0:a44:e28d:31a0 with SMTP id h10-20020a170906398a00b00a44e28d31a0mr6939259eje.53.1709709735640; Tue, 05 Mar 2024 23:22:15 -0800 (PST) Message-ID: <6fb7b2c9-6665-4cbd-a1c4-24ebf7514b88@suse.com> Date: Wed, 6 Mar 2024 08:22:14 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86+Arm: drop (rename) __virt_to_maddr() / __maddr_to_virt() Content-Language: en-US To: Julien Grall Cc: Andrew Cooper , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel , Oleksii Kurochko , "xen-devel@lists.xenproject.org" References: From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 05.03.2024 20:24, Julien Grall wrote: > Hi Jan, > > The title is quite confusing. I would have expected the macro... > > On 05/03/2024 08:33, Jan Beulich wrote: >> There's no use of them anymore except in the definitions of the non- >> underscore-prefixed aliases. Rename the inline functions, adjust the >> virt_to_maddr() #define-e, and purge the (x86-only) maddr_to_virt() one, >> thus eliminating a bogus cast which would have allowed the passing of a >> pointer type variable into maddr_to_virt() to go silently. >> >> Signed-off-by: Jan Beulich >> >> --- a/xen/arch/arm/include/asm/mm.h >> +++ b/xen/arch/arm/include/asm/mm.h >> @@ -256,12 +256,12 @@ static inline void __iomem *ioremap_wc(p >> /* Page-align address and convert to frame number format */ >> #define paddr_to_pfn_aligned(paddr) paddr_to_pfn(PAGE_ALIGN(paddr)) >> >> -static inline paddr_t __virt_to_maddr(vaddr_t va) >> +static inline paddr_t virt_to_maddr(vaddr_t va) >> { >> uint64_t par = va_to_par(va); >> return (par & PADDR_MASK & PAGE_MASK) | (va & ~PAGE_MASK); >> } >> -#define virt_to_maddr(va) __virt_to_maddr((vaddr_t)(va)) >> +#define virt_to_maddr(va) virt_to_maddr((vaddr_t)(va)) > > ... to be removed. But you keep it and just overload the name. I know it > is not possible to remove the macro because some callers are using > pointers (?). Indeed. I actually tried without, but the build fails miserably. > So I would rather prefer if we keep the name distinct on Arm. > > Let see what the other Arm maintainers think. Well, okay. I'm a little surprised though; I was under the impression that a goal would be to, eventually, get rid of all the __-prefixed secondary variants of this kind of helpers. Jan From xen-devel-bounces@lists.xenproject.org Wed Mar 06 07:34:15 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 07:34:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688970.1073814 (Exim 4.92) (envelope-from ) id 1rhln0-0003ow-4c; Wed, 06 Mar 2024 07:34:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688970.1073814; Wed, 06 Mar 2024 07:34:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhln0-0003op-0i; Wed, 06 Mar 2024 07:34:10 +0000 Received: by outflank-mailman (input) for mailman id 688970; Wed, 06 Mar 2024 07:34:08 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhlmy-0003oj-3R for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 07:34:08 +0000 Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [2a00:1450:4864:20::533]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id e975e4e7-db8b-11ee-a1ee-f123f15fe8a2; Wed, 06 Mar 2024 08:34:06 +0100 (CET) Received: by mail-ed1-x533.google.com with SMTP id 4fb4d7f45d1cf-565a3910f86so9733751a12.3 for ; Tue, 05 Mar 2024 23:34:06 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id h6-20020a0564020e0600b00566d87734c0sm5521382edh.16.2024.03.05.23.34.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 Mar 2024 23:34:05 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e975e4e7-db8b-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709710445; x=1710315245; darn=lists.xenproject.org; h=content-transfer-encoding:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to; bh=pZ5Y9z+hZxEhmTStWr9SS8VQ2KHUVonSI9wVZkbY3U4=; b=Xri7zDWkmbAS5MmGeM7Je81PZPj2bgFrT+SIb5ySNq3CGsG4p0CZVCClu/QBEuZhnS IqMVtLBJ0vup3RYBRgvuta79Cn19huhvtXL17g4IwmH9+DB5MDVcVgERTOXR3fob6+ld ZKwfbhbzk4YzCQDzwlWew3TL1qcV8fAP2BBsq1QaYrdf8JXMauArMq6L9jLLdiL0PqTp 6Dv+TVYU8T2QhHriTPlLpVhidm91fxG/0KpgrF11OEzlMHPu33NrrjW4r/Eg1G4b5kNi KvD9gCFNKHAQ54WbSxmlNrfi43t/HqVcmEQ+PxIBTPzdHZvwDN6I5kYKOZRRVFVYnh6a wRpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709710445; x=1710315245; h=content-transfer-encoding:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=pZ5Y9z+hZxEhmTStWr9SS8VQ2KHUVonSI9wVZkbY3U4=; b=AC2R9vp/cfGoJGQe82vrQmwhmx47ivbhQMIiTI5O1y40zn90pjfoaH5L2Q6iJjE59X 87ytzeM1ZZ/yIMMdsPpyrk/CbLl5j8jTSmeq0qQ1K5m/25Ej13I+tjyh7WuBgcqwWDWQ il7wXcl2Y9kzcIuK7krSdR0d+cnsPCC4c89gTbzEInpwhCJwukClhVZJngXyJGQIyiA6 JFCv3+TEfDlyyyZOHs8D+AVkAcxH6i2r2Sn/+J4BPr9dYo0YdijzWigesnOad8Zj8Hu4 GBd3WazsD8qw4BHzholJzlxrKSGvFw6Q6iqg/hwHVregUzbA3Jyq+X/TrUnH88j5pA3p 1rcA== X-Gm-Message-State: AOJu0Yycw5UPEQ4v/syD1rAfSxE4URjS+UaeOUDnVV2VIs2QbiVunE5Q 9QTOmO9a+kZrTWT7LBCpVps1ELRcgU69zhGloCHRcHjylt5iQ/F+B56NwJmaGxEAx/rHSqD3+pw = X-Google-Smtp-Source: AGHT+IFJxaiZzsndaId/iEKEmUt5plO33xatbtDulALePkUVnHHnVTJZL1142XWjIdMWPrAVmtKkag== X-Received: by 2002:a05:6402:1d91:b0:566:b09e:8d24 with SMTP id dk17-20020a0564021d9100b00566b09e8d24mr8449629edb.12.1709710445459; Tue, 05 Mar 2024 23:34:05 -0800 (PST) Message-ID: Date: Wed, 6 Mar 2024 08:34:04 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= From: Jan Beulich Subject: [PATCH] x86/asm: add commas to BUILD_BUG_ON Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit In light of recent observations with how macros are handled by gas, let's play by what we informally set for ourselves as a guideline: Use commas to separate parameters/arguments. Signed-off-by: Jan Beulich --- a/xen/arch/x86/include/asm/asm_defns.h +++ b/xen/arch/x86/include/asm/asm_defns.h @@ -82,13 +82,13 @@ register unsigned long current_stack_poi #ifdef __ASSEMBLY__ -.macro BUILD_BUG_ON condstr cond:vararg +.macro BUILD_BUG_ON condstr, cond:vararg .if \cond .error "Condition \"\condstr\" not satisfied" .endif .endm /* preprocessor macro to make error message more user friendly */ -#define BUILD_BUG_ON(cond) BUILD_BUG_ON #cond cond +#define BUILD_BUG_ON(cond) BUILD_BUG_ON #cond, cond #ifdef HAVE_AS_QUOTED_SYM #define SUBSECTION_LBL(tag) \ From xen-devel-bounces@lists.xenproject.org Wed Mar 06 07:46:01 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 07:46:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688973.1073823 (Exim 4.92) (envelope-from ) id 1rhlyN-0005jY-3g; Wed, 06 Mar 2024 07:45:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688973.1073823; Wed, 06 Mar 2024 07:45:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhlyN-0005jR-1D; Wed, 06 Mar 2024 07:45:55 +0000 Received: by outflank-mailman (input) for mailman id 688973; Wed, 06 Mar 2024 07:45:53 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhlyL-0005jL-0P for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 07:45:53 +0000 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on20600.outbound.protection.outlook.com [2a01:111:f403:2418::600]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 8c86527c-db8d-11ee-a1ee-f123f15fe8a2; Wed, 06 Mar 2024 08:45:50 +0100 (CET) Received: from BN9P220CA0007.NAMP220.PROD.OUTLOOK.COM (2603:10b6:408:13e::12) by DS0PR12MB6391.namprd12.prod.outlook.com (2603:10b6:8:cd::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7339.39; Wed, 6 Mar 2024 07:45:46 +0000 Received: from BN2PEPF000044A1.namprd02.prod.outlook.com (2603:10b6:408:13e:cafe::d) by BN9P220CA0007.outlook.office365.com (2603:10b6:408:13e::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7339.39 via Frontend Transport; Wed, 6 Mar 2024 07:45:46 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by BN2PEPF000044A1.mail.protection.outlook.com (10.167.243.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7362.11 via Frontend Transport; Wed, 6 Mar 2024 07:45:45 +0000 Received: from SATLEXMB06.amd.com (10.181.40.147) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Wed, 6 Mar 2024 01:45:45 -0600 Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB06.amd.com (10.181.40.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Wed, 6 Mar 2024 01:45:45 -0600 Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend Transport; Wed, 6 Mar 2024 01:45:43 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8c86527c-db8d-11ee-a1ee-f123f15fe8a2 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NVH8okqh0vq2WyZNx5oH4mDtkyAHdGLc5mNRJ8gqoRJ6grQ+koj/Ro9nnWCPvtV2zxuBEVgs6jWuiLS383Q3WAoKpGjntLYs7B5JIMY8sFlXZMC3mxBr4xfmTTYipRl1eQg7SkoRtO2004TKwfH7CSWXQMdseOtypUrTpDucH0hyXRdWNlUyzjr7xUq7UI1BUoE8T8+e1Bwi89T9sCJXIil3DtcV+amuKC0O4rJB5JMXYWNRf8s++9tHkHPShV+fG6gM4TCpxbJXGrJaJWt7cewGoXMKhGIBVYFeT4xg6OPCLvaBKuf+QOwiefuZHo3LqQhNULKSMvwx0kkQ32VSPQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=0NiyVVxkm7qwYRYm/eVn+i/fZI60GXvgZNgQfOtD4RI=; b=ffnu5nrGM+d4pj9yL/WlPCKfdGnowzF+qlbRp7pbZiLDsEwKgK6m+GzEY/Cr7MNG2zx/FyP8vf1wkS2Ur1zaj2bNWqZOiY35UOCUkfwUDMBTRSdOvgj8EVKfAf8dB1Jllg8Kt3KnFwpcEK30HNmvFnBQqwZc9Yw0PmeOneT2n/AK6KryRfibXhHGwHirxeTvOEZtQTG/qy1CsdTJBYyQJjt5+9dT2+FlACSCHe5iHDzYCohrqrZ2kSZOxvT/9XauOUe1yUUb54oo7B+bbTpV72HibmdtjVb4TkoFSADjHCfaSFRVUtECBPTO8IH+hRyrGjtUWfiO6rqZrj/7NMShzg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=xen.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0NiyVVxkm7qwYRYm/eVn+i/fZI60GXvgZNgQfOtD4RI=; b=WVlxbIXY79CVf7/ikDvA04SDf1o8bcIt82WEbyYbaG9FyWL8lY4q7gTbuuQ0fnl2SOKCbe1nyVJ9cKnHESSoSzrP2Piwg4wZIAebzAvFjdeV0SxnQGAlRDLZ9rUb7TtSfcZaZ6vf9M0OobqtHi5wq99Yxuu/LyfQSQgWl+11Pf8= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C Message-ID: <7b59c858-a988-46ca-b5fd-41074970c2e1@amd.com> Date: Wed, 6 Mar 2024 08:45:42 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86+Arm: drop (rename) __virt_to_maddr() / __maddr_to_virt() To: Julien Grall , Jan Beulich , "xen-devel@lists.xenproject.org" CC: Andrew Cooper , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Volodymyr Babchuk , Bertrand Marquis , Oleksii Kurochko References: Content-Language: en-US From: Michal Orzel In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN2PEPF000044A1:EE_|DS0PR12MB6391:EE_ X-MS-Office365-Filtering-Correlation-Id: efb5605a-c0c9-4043-ac59-08dc3db16ef3 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: dZvTRjw5NnmvS73ZWinvyV0XsEEz+mt4+TPvCF1Waz/FZ4j5R35CXa+BY9GYP4Cz0IoQHm32oJvT3Gequ1eWFolEVuk3keefeSyER0uHWvXuFatv4fW4wJ2ctdiyVW5Dds7/qG1pDMU4KrpF1l2fdgQ3PRZlgzGh1FTlb4kY+7r3UJ8qnekZQgVmppZb5WsqtYO8WTroWHuiduJH4g+oJoaTmbfcvl2yQd5uEGBHHpuQd6CZP20lJ+jtqcGSyIQgeHnow4sJHIgHJNbgjNwz4EIVFJIrzFtlYV1E1uwq0po1g8j+kzuD852LXsLF7pcUxwG2VgDFh7MU8UV6gns7qa/8dRMyw6z2Mk9ny/gRo5MSifK4kqp3+LbtuUAPsfXRY/tl2rOyTJ5o4Ss2buTOnfeNWWHWPPBvh8UYzSxAqyim6WQKY28u8zNjuDxFlikOehBxHL0o/IqaGicphzzCplKm/79T3UPrv4rryhN+tEgPrQExlB0YsxXU49IGZvckTYePmUhZquY821qbCdra2fY5Twj4ras+2EbgBtlTZ10m+2EF+ffQK8xILvJwO1tzF1bZ9EXbIpuehjSyL+yvZU8tifpE4ccsEUlWbnY2Vs0kh999K7ftR6qQTqjnuiSJX7iyIAI3h+lkxfQ0z87HkiqXhc+vutblE9+WFZLzhevG+25uuPx9sH0tTafZI2Q+ITAZeLoECPXijDOECZ7mwopTYIuV2ZYCeujRPA5zNayWMcZPkTj2JLhIKbprgJU3 X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(82310400014)(36860700004)(376005);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Mar 2024 07:45:45.9267 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: efb5605a-c0c9-4043-ac59-08dc3db16ef3 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BN2PEPF000044A1.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB6391 On 05/03/2024 20:24, Julien Grall wrote: > > > Hi Jan, > > The title is quite confusing. I would have expected the macro... > > On 05/03/2024 08:33, Jan Beulich wrote: >> There's no use of them anymore except in the definitions of the non- >> underscore-prefixed aliases. Rename the inline functions, adjust the >> virt_to_maddr() #define-e, and purge the (x86-only) maddr_to_virt() one, >> thus eliminating a bogus cast which would have allowed the passing of a >> pointer type variable into maddr_to_virt() to go silently. >> >> Signed-off-by: Jan Beulich >> >> --- a/xen/arch/arm/include/asm/mm.h >> +++ b/xen/arch/arm/include/asm/mm.h >> @@ -256,12 +256,12 @@ static inline void __iomem *ioremap_wc(p >> /* Page-align address and convert to frame number format */ >> #define paddr_to_pfn_aligned(paddr) paddr_to_pfn(PAGE_ALIGN(paddr)) >> >> -static inline paddr_t __virt_to_maddr(vaddr_t va) >> +static inline paddr_t virt_to_maddr(vaddr_t va) >> { >> uint64_t par = va_to_par(va); >> return (par & PADDR_MASK & PAGE_MASK) | (va & ~PAGE_MASK); >> } >> -#define virt_to_maddr(va) __virt_to_maddr((vaddr_t)(va)) >> +#define virt_to_maddr(va) virt_to_maddr((vaddr_t)(va)) > > ... to be removed. But you keep it and just overload the name. I know it > is not possible to remove the macro because some callers are using > pointers (?). So I would rather prefer if we keep the name distinct on Arm. > > Let see what the other Arm maintainers think. I share the same opinion. If it's about double underscores that violates MISRA rule, I think we deviated it the same way we deviated unique identifiers (IIRC). ~Michal From xen-devel-bounces@lists.xenproject.org Wed Mar 06 08:13:39 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 08:13:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688981.1073833 (Exim 4.92) (envelope-from ) id 1rhmP7-0002VF-NQ; Wed, 06 Mar 2024 08:13:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688981.1073833; Wed, 06 Mar 2024 08:13:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhmP7-0002V8-KR; Wed, 06 Mar 2024 08:13:33 +0000 Received: by outflank-mailman (input) for mailman id 688981; Wed, 06 Mar 2024 08:13:32 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhmP6-0002Uy-8x; Wed, 06 Mar 2024 08:13:32 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhmP6-00014t-5r; Wed, 06 Mar 2024 08:13:32 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhmP5-00087E-Rt; Wed, 06 Mar 2024 08:13:31 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rhmP5-0006cw-RK; Wed, 06 Mar 2024 08:13:31 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=ezCnIhxLDOgkjfObiiCi1WlUEig8XVRKWg88TGQwe/c=; b=JBNv9E0DLM3UQno59+U0Ny/XTp TyBXsTxa1VGVNH5GoEN7bRRNxCw+e64e9ymzLmU98PjgqfkqnXluTCO1/MmVCCvgyBRji1bH6XXEk +4eSSjy611/QRGCs8hGNOahkMwc/RG1W3xSNYo8TKU8UbWRrIQY1FFYV9E9TW3wYltII=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-linus test] 184912: tolerable FAIL - PUSHED X-Osstest-Failures: linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: linux=29cd507cbec282e13dcf8f38072a100af96b2bb7 X-Osstest-Versions-That: linux=90d35da658da8cff0d4ecbb5113f5fac9d00eb72 From: osstest service owner Date: Wed, 06 Mar 2024 08:13:31 +0000 flight 184912 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/184912/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop fail like 184886 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop fail like 184886 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop fail like 184886 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 184886 test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail like 184886 test-armhf-armhf-libvirt 16 saverestore-support-check fail like 184886 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop fail like 184886 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184886 test-amd64-amd64-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl 15 migrate-support-check fail never pass test-arm64-arm64-xl 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 15 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 15 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 15 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qcow2 14 migrate-support-check fail never pass test-amd64-amd64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-check fail never pass test-arm64-arm64-xl-vhd 14 migrate-support-check fail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-libvirt 15 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-check fail never pass version targeted for testing: linux 29cd507cbec282e13dcf8f38072a100af96b2bb7 baseline version: linux 90d35da658da8cff0d4ecbb5113f5fac9d00eb72 Last test of basis 184886 2024-03-04 04:27:14 Z 2 days Testing same since 184912 2024-03-05 21:44:46 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Boqun Feng Coiby Xu Danil Rybakov Hans de Goede Harshit Mogalapalli Kirill A. Shutemov Linus Torvalds Michael Kelley Mimi Zohar Peter Martincic Ricardo B. Marliere Saurabh Sengar Souradeep Chakrabarti Wei Liu jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-amd64-dom0pvh-xl-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-freebsd11-amd64 pass test-amd64-amd64-freebsd12-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-examine-bios pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-amd64-dom0pvh-xl-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-amd64-xl-pvshim pass test-amd64-amd64-pygrub pass test-amd64-amd64-libvirt-qcow2 pass test-armhf-armhf-libvirt-qcow2 pass test-amd64-amd64-libvirt-raw pass test-arm64-arm64-libvirt-raw pass test-armhf-armhf-libvirt-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-examine-uefi pass test-amd64-amd64-xl-vhd pass test-arm64-arm64-xl-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these 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 : hint: The 'hooks/update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-receive' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. To xenbits.xen.org:/home/xen/git/linux-pvops.git 90d35da658da8..29cd507cbec28 29cd507cbec282e13dcf8f38072a100af96b2bb7 -> tested/linux-linus From xen-devel-bounces@lists.xenproject.org Wed Mar 06 08:42:13 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 08:42:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688986.1073844 (Exim 4.92) (envelope-from ) id 1rhmqd-0006wb-S9; Wed, 06 Mar 2024 08:41:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688986.1073844; Wed, 06 Mar 2024 08:41:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhmqd-0006wU-P8; Wed, 06 Mar 2024 08:41:59 +0000 Received: by outflank-mailman (input) for mailman id 688986; Wed, 06 Mar 2024 08:41:58 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhmqc-0006wM-Gn for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 08:41:58 +0000 Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com [2607:f8b0:4864:20::f35]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 638b389e-db95-11ee-afda-a90da7624cb6; Wed, 06 Mar 2024 09:41:56 +0100 (CET) Received: by mail-qv1-xf35.google.com with SMTP id 6a1803df08f44-6906a7870f3so14165126d6.0 for ; Wed, 06 Mar 2024 00:41:56 -0800 (PST) Received: from localhost ([213.195.118.74]) by smtp.gmail.com with ESMTPSA id om13-20020a0562143d8d00b0069049135a69sm7023441qvb.118.2024.03.06.00.41.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Mar 2024 00:41:55 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 638b389e-db95-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709714515; x=1710319315; darn=lists.xenproject.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=gRA45BD+xOCjZlCt+0rrl0MG9mC7LmUmAHQuHFIET2w=; b=eXBonDp4Et2PjJqPej77X+FwTC6dLQuPDiswoSzFMXH5v5aYFNGxda8V97BpBGahz4 FrqMTJHdZalvg3gce0CCH2XknChE890hq0GyHscMKN9RqHF41R1zz9i7dl9p/ADcW0Vb ZrGzzRKXeMhgUzj3g+z95Drj0CEVI3ohaIi6I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709714515; x=1710319315; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=gRA45BD+xOCjZlCt+0rrl0MG9mC7LmUmAHQuHFIET2w=; b=Y7gHvJHQJXnLFyhbXNUEN2UBWMe4ywSGC8cmaifA/wZzXq6mFIA1GngFOuPYgbyjH2 XQywxapJIixZx0T/j+dyMPxaAi612HqvqIfbEJ8u8fsFQ8o+o2MnoemVFG1bXPpLV61z esFNyTFpjekQ6NHP+ar60+K0hPFiJaFa2aXctr6n7nBLwLYRo3mToDhMQlql8f59LKHP UUgBw+fiRaG7RXQ41IjKZc4go7csg0wm79P1lYULGGajIGk5dapOmur6qsZM6AHqm9tE ZloYix5NyPeUd+OS9gYnfiSKG0e/82zyejpcdNfA6qzt/hPfsatP+hFQrkC0yqO4BZze kKQA== X-Gm-Message-State: AOJu0YyfqfKTSbdsSh/g79I7YhfOSxNYJyaKGqNYLD2x8rIGM0vPRpMt 1agCq8iagQNj/zEPGUtP8h7ADWNgBU8iKcu2ZzNOE/kFRmDP1RykpsF3qjqtxjw= X-Google-Smtp-Source: AGHT+IHpHaaRiPnv86gpjeI/vrv1bQdEaUCNhyFGxCmZwrQz3mpvQ2u7eoPrR2nhhxxk28dsqfwmAw== X-Received: by 2002:a05:6214:8ea:b0:690:4deb:3aa5 with SMTP id dr10-20020a05621408ea00b006904deb3aa5mr4141781qvb.42.1709714515606; Wed, 06 Mar 2024 00:41:55 -0800 (PST) Date: Wed, 6 Mar 2024 09:41:53 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: flyingpenghao@gmail.com Cc: xen-devel@lists.xenproject.org, Peng Hao Subject: Re: [PATCH] xen/blkback: use kmap_local_page() Message-ID: References: <20240306051548.90954-1-flyingpeng@tencent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20240306051548.90954-1-flyingpeng@tencent.com> On Wed, Mar 06, 2024 at 01:15:48PM +0800, flyingpenghao@gmail.com wrote: > From: Peng Hao > > From: Peng Hao > > Use kmap_local_page() instead of kmap_atomic() which has been > deprecated. > > Signed-off-by: Peng Hao > --- > drivers/block/xen-blkback/blkback.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c > index 4defd7f387c7..cce534f43292 100644 > --- a/drivers/block/xen-blkback/blkback.c > +++ b/drivers/block/xen-blkback/blkback.c > @@ -937,8 +937,8 @@ static int xen_blkbk_parse_indirect(struct blkif_request *req, > if ((n % SEGS_PER_INDIRECT_FRAME) == 0) { > /* Map indirect segments */ > if (segments) > - kunmap_atomic(segments); > - segments = kmap_atomic(pages[n/SEGS_PER_INDIRECT_FRAME]->page); > + kunmap_local(segments); > + segments = kmap_local_page(pages[n/SEGS_PER_INDIRECT_FRAME]->page); Don't you need to also switch to kunmap_local() then instead of kunmap_atomic()? Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Mar 06 09:41:06 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 09:41:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688993.1073870 (Exim 4.92) (envelope-from ) id 1rhnlk-0006uq-Ai; Wed, 06 Mar 2024 09:41:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688993.1073870; Wed, 06 Mar 2024 09:41:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhnlk-0006uj-7K; Wed, 06 Mar 2024 09:41:00 +0000 Received: by outflank-mailman (input) for mailman id 688993; Wed, 06 Mar 2024 09:40:59 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhnli-0006ud-W4 for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 09:40:59 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhnlg-0002va-U2; Wed, 06 Mar 2024 09:40:56 +0000 Received: from gw1.octic.net ([88.97.20.152] helo=[10.0.1.240]) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1rhnlg-0003GQ-OU; Wed, 06 Mar 2024 09:40:56 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID; bh=Fb4QIs2E09TeP9Ic2+DwL4sBKHqXS4NERNnQ8agFh8E=; b=yIkleGITnirJOFnDo0zhUE/Px4 1njfUzl8A0GXAuX87JXuMHrsJ37rGXOfjm4ki8X5yV3IexSNne/vh1oFHXNhHCVHi1yxaaBO7FDxs +Yguzt+u24p3Fe+8MDLRLc+OptBSajV9Hfzl3vsGBvNVO/8Q2AfBYdQiJxqE/iDs5N1s=; Message-ID: Date: Wed, 6 Mar 2024 09:40:55 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] SUPPORT.md: clarify support of booting 32-bit Xen on ARMv8 Content-Language: en-GB To: Stefano Stabellini , Michal Orzel Cc: xen-devel@lists.xenproject.org, Andrew Cooper , George Dunlap , Jan Beulich , Wei Liu References: <20240229121352.11264-1-michal.orzel@amd.com> <94176748-8438-460d-9434-6d18add55cef@amd.com> <544718e1-4855-4af1-a450-6362a8cd08f0@xen.org> <216e9119-a7f9-43f3-80f9-f1c15685cad3@amd.com> From: Julien Grall In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 29/02/2024 21:07, Stefano Stabellini wrote: > On Thu, 29 Feb 2024, Michal Orzel wrote: >> >> On 29/02/2024 13:40, Julien Grall wrote: >>> >>> >>> On 29/02/2024 12:37, Michal Orzel wrote: >>>> Hi Julien, >>> >>> Hi Michal, >>> >>>> >>>> On 29/02/2024 13:35, Julien Grall wrote: >>>>> On 29/02/2024 12:13, Michal Orzel wrote: >>>>>> Since commit bd1001db0af1 ("xen/arm: arm32: Allow Xen to boot on >>>>>> unidentified CPUs"), it's been possible to boot 32-bit Xen on ARMv8A CPUs >>>>>> in AArch32 state (assuming HW supports EL2 execution in AArch32). Clarify >>>>>> the support statement and mark it as Tech Preview, as this use case is >>>>>> uncommon and hasn't really been tested/hardened. >>>>>> >>>>>> Signed-off-by: Michal Orzel >>>>>> --- >>>>>> SUPPORT.md | 1 + >>>>>> 1 file changed, 1 insertion(+) >>>>>> >>>>>> diff --git a/SUPPORT.md b/SUPPORT.md >>>>>> index a90d1108c9d9..acc61230bb5e 100644 >>>>>> --- a/SUPPORT.md >>>>>> +++ b/SUPPORT.md >>>>>> @@ -40,6 +40,7 @@ supported in this document. >>>>>> Status: Supported >>>>> I would consider to use 'Status, Xen in aarch64 mode: Supported' and then... >>>>> >>>>>> Status, Cortex A57 r0p0-r1p1: Supported, not security supported >>>>>> Status, Cortex A77 r0p0-r1p0: Supported, not security supported >>>>>> + Status, Xen in AArch32 mode: Tech Preview >>>>> >>>>> ... move this line closer. What do you think? >>>> That works for me too (+AArch64 instead of aarch64). >>> >>> Ah yes. I keep forgetting capitalizing properly :). >>> >>>> Shall I respin the patch? >>> >>> Up to you. I am happy to fix it. But I will wait a day or two just to >>> give a chance for the others to comment. >> That works for me, let's wait for Bertrand and Stefano. > > I am fine with it Committed. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Wed Mar 06 09:45:10 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 09:45:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.688997.1073884 (Exim 4.92) (envelope-from ) id 1rhnpg-0007Xj-QX; Wed, 06 Mar 2024 09:45:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 688997.1073884; Wed, 06 Mar 2024 09:45:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhnpg-0007Xc-NO; Wed, 06 Mar 2024 09:45:04 +0000 Received: by outflank-mailman (input) for mailman id 688997; Wed, 06 Mar 2024 09:45:04 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhnpg-0007XW-Db for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 09:45:04 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhnpb-00031W-0d; Wed, 06 Mar 2024 09:44:59 +0000 Received: from gw1.octic.net ([88.97.20.152] helo=[10.0.1.240]) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1rhnpa-0003cc-P8; Wed, 06 Mar 2024 09:44:58 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID; bh=4EmkDsqh2P+Dad7Jqq0R+Wdkl+4jMYVIissUqXmAl+o=; b=ebRZELJQD0qhHvY+nhwjKMj9qk iZAQ3wwFnAzX7AuCdyLs5RaWXqFkE5nGMkWeNrP+lNFZa1ODVUUnizXygYPPitmtjiVCQ+GZvHLpR Gfoxqc/LLXkCJoHBBLssAgoNc7p/MjD3AFN31hMBOC6tDvEgoitBUMYt7qTrYizCHQ5A=; Message-ID: Date: Wed, 6 Mar 2024 09:44:56 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86+Arm: drop (rename) __virt_to_maddr() / __maddr_to_virt() Content-Language: en-GB To: Jan Beulich Cc: Andrew Cooper , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel , Oleksii Kurochko , "xen-devel@lists.xenproject.org" References: <6fb7b2c9-6665-4cbd-a1c4-24ebf7514b88@suse.com> From: Julien Grall In-Reply-To: <6fb7b2c9-6665-4cbd-a1c4-24ebf7514b88@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Jan, On 06/03/2024 07:22, Jan Beulich wrote: > On 05.03.2024 20:24, Julien Grall wrote: >> Hi Jan, >> >> The title is quite confusing. I would have expected the macro... >> >> On 05/03/2024 08:33, Jan Beulich wrote: >>> There's no use of them anymore except in the definitions of the non- >>> underscore-prefixed aliases. Rename the inline functions, adjust the >>> virt_to_maddr() #define-e, and purge the (x86-only) maddr_to_virt() one, >>> thus eliminating a bogus cast which would have allowed the passing of a >>> pointer type variable into maddr_to_virt() to go silently. >>> >>> Signed-off-by: Jan Beulich >>> >>> --- a/xen/arch/arm/include/asm/mm.h >>> +++ b/xen/arch/arm/include/asm/mm.h >>> @@ -256,12 +256,12 @@ static inline void __iomem *ioremap_wc(p >>> /* Page-align address and convert to frame number format */ >>> #define paddr_to_pfn_aligned(paddr) paddr_to_pfn(PAGE_ALIGN(paddr)) >>> >>> -static inline paddr_t __virt_to_maddr(vaddr_t va) >>> +static inline paddr_t virt_to_maddr(vaddr_t va) >>> { >>> uint64_t par = va_to_par(va); >>> return (par & PADDR_MASK & PAGE_MASK) | (va & ~PAGE_MASK); >>> } >>> -#define virt_to_maddr(va) __virt_to_maddr((vaddr_t)(va)) >>> +#define virt_to_maddr(va) virt_to_maddr((vaddr_t)(va)) >> >> ... to be removed. But you keep it and just overload the name. I know it >> is not possible to remove the macro because some callers are using >> pointers (?). > > Indeed. I actually tried without, but the build fails miserably. > >> So I would rather prefer if we keep the name distinct on Arm. >> >> Let see what the other Arm maintainers think. > > Well, okay. I'm a little surprised though; I was under the impression > that a goal would be to, eventually, get rid of all the __-prefixed > secondary variants of this kind of helpers. Because of MISRA? If so, you would be replacing one violation by another one (duplicated name). IIRC we decided to deviate it, yet I don't particular want to use the pattern in Arm headers when there is no need. If you are trying to solve MISRA, then I think we want to either remove the macro (not possible here) or suffix with the double-underscore the static inline helper. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Wed Mar 06 09:59:32 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 09:59:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689017.1073909 (Exim 4.92) (envelope-from ) id 1rho3d-0002Nh-GU; Wed, 06 Mar 2024 09:59:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689017.1073909; Wed, 06 Mar 2024 09:59:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rho3d-0002Na-Dk; Wed, 06 Mar 2024 09:59:29 +0000 Received: by outflank-mailman (input) for mailman id 689017; Wed, 06 Mar 2024 09:59:27 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rho3b-0002La-NS for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 09:59:27 +0000 Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [2a00:1450:4864:20::635]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 369ea254-dba0-11ee-a1ee-f123f15fe8a2; Wed, 06 Mar 2024 10:59:25 +0100 (CET) Received: by mail-ej1-x635.google.com with SMTP id a640c23a62f3a-a441d7c6125so176057166b.2 for ; Wed, 06 Mar 2024 01:59:25 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id w16-20020a170906185000b00a4551cc291esm3153416eje.40.2024.03.06.01.59.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 Mar 2024 01:59:24 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 369ea254-dba0-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709719165; x=1710323965; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=ChogrlZnSrn7Zj80mSp/ZBCpi766+icRGCu45I82H0o=; b=ba0R1nsoVRPN6vkBbYnokxUCBweSqr6h3mb798Is6OBggp8q2/YM1GZ5jaSf/L6BNb Tr4n9eOpkFtcosWfK2/CuKBIK/agH/50aEIqjwjRM6D/y/Y2ylBGOfvGKKQSA0jtqdK0 PHIGs2IVNLPRo5VXOBuDmd/88JfbUz2aMz/xy9rZJhYE6gQo+BFU+loXo/aOW2H/wxTQ MvJGq5tJKOYYtCdyoj746Fhzd2v2Nn9OFvf2RzZ6F/sHH8HmCfrLFA/48ND6VOD1iND6 AoPg+aHcWcGRSfXMchxSrownojQGsnXxaoatASsWidfcbTVSCzq+Y9l7T6joAZSLfLT3 zo7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709719165; x=1710323965; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ChogrlZnSrn7Zj80mSp/ZBCpi766+icRGCu45I82H0o=; b=qolytRsENI6yhzPMZyKVc6BuNtcaASAHVgWdEV3MVSIw+qKxCiuKQMe7QuvVExOYuH VuNSkdew/rkPf48hQ7y7JRVQYZbgfq+Nsyre59v+vKFIJfHPV7lRX4UO8a5MsDpn38Ac g16LPInnn86e0jvhxiPfMwqJ6pfO+Po9Rg7TGRW8w9Hh/LSWKR/ZtseglZP07XwhNCoK zAeqExZq18Qb9KhvlzddB8yBBIg2fJR6hc1SbA6aqvCKL/xTdvPy7QjyyPDkfgyAfrXb YtR1rhxRU4NI7jPY0Yt0m42muzVHyevKJ2M/q6+/jS2EUzsdtEi2H9juQsLZE04JxuvI GOIA== X-Forwarded-Encrypted: i=1; AJvYcCWqfq6ZGnGoFruhGAbJlY7MnCera5xINze1qFNMBPeVlBEygLBXlaC4CesBcd0yMzgvlx9RrHb7py7IosEr4wmLKcZdMvACbIqmDr10v1E= X-Gm-Message-State: AOJu0YxmOF4F27CW9S9BqKDeRERm/AXYUglVHuOI4yH0YiEgf3fFQnYP wTFmrstUuHORIEvzDX3QOoocg/y7hn16SvVOXRbCoHLflhWAyXchNgFjJQqPzg== X-Google-Smtp-Source: AGHT+IFgTmdIdOSxd26G7NXnG5W4K/G+5chVJHkS2Z2BmDILQ379z/txA7K1D1szlqJcPj7IazLqBg== X-Received: by 2002:a17:906:364d:b0:a43:811b:71de with SMTP id r13-20020a170906364d00b00a43811b71demr9372471ejb.38.1709719164961; Wed, 06 Mar 2024 01:59:24 -0800 (PST) Message-ID: <610e5e76-db0f-4509-84ed-c1bc085b4b6e@suse.com> Date: Wed, 6 Mar 2024 10:59:23 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86+Arm: drop (rename) __virt_to_maddr() / __maddr_to_virt() Content-Language: en-US To: Julien Grall Cc: Andrew Cooper , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel , Oleksii Kurochko , "xen-devel@lists.xenproject.org" References: <6fb7b2c9-6665-4cbd-a1c4-24ebf7514b88@suse.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 06.03.2024 10:44, Julien Grall wrote: > On 06/03/2024 07:22, Jan Beulich wrote: >> On 05.03.2024 20:24, Julien Grall wrote: >>> The title is quite confusing. I would have expected the macro... >>> >>> On 05/03/2024 08:33, Jan Beulich wrote: >>>> There's no use of them anymore except in the definitions of the non- >>>> underscore-prefixed aliases. Rename the inline functions, adjust the >>>> virt_to_maddr() #define-e, and purge the (x86-only) maddr_to_virt() one, >>>> thus eliminating a bogus cast which would have allowed the passing of a >>>> pointer type variable into maddr_to_virt() to go silently. >>>> >>>> Signed-off-by: Jan Beulich >>>> >>>> --- a/xen/arch/arm/include/asm/mm.h >>>> +++ b/xen/arch/arm/include/asm/mm.h >>>> @@ -256,12 +256,12 @@ static inline void __iomem *ioremap_wc(p >>>> /* Page-align address and convert to frame number format */ >>>> #define paddr_to_pfn_aligned(paddr) paddr_to_pfn(PAGE_ALIGN(paddr)) >>>> >>>> -static inline paddr_t __virt_to_maddr(vaddr_t va) >>>> +static inline paddr_t virt_to_maddr(vaddr_t va) >>>> { >>>> uint64_t par = va_to_par(va); >>>> return (par & PADDR_MASK & PAGE_MASK) | (va & ~PAGE_MASK); >>>> } >>>> -#define virt_to_maddr(va) __virt_to_maddr((vaddr_t)(va)) >>>> +#define virt_to_maddr(va) virt_to_maddr((vaddr_t)(va)) >>> >>> ... to be removed. But you keep it and just overload the name. I know it >>> is not possible to remove the macro because some callers are using >>> pointers (?). >> >> Indeed. I actually tried without, but the build fails miserably. >> >>> So I would rather prefer if we keep the name distinct on Arm. >>> >>> Let see what the other Arm maintainers think. >> >> Well, okay. I'm a little surprised though; I was under the impression >> that a goal would be to, eventually, get rid of all the __-prefixed >> secondary variants of this kind of helpers. > > Because of MISRA? If so, you would be replacing one violation by another > one (duplicated name). IIRC we decided to deviate it, yet I don't > particular want to use the pattern in Arm headers when there is no need. > > If you are trying to solve MISRA, then I think we want to either remove > the macro (not possible here) or suffix with the double-underscore the > static inline helper. No, Misra is only secondary here. Many of these helpers come in two flavors such than one can be overridden in individual source files. That's mainly connected to type-safety being generally wanted, but not always easy to achieve without a lot of code churn. We've made quite a bit of progress there, and imo ultimately the need for two flavors of doing the same thing ought to disappear. Jan From xen-devel-bounces@lists.xenproject.org Wed Mar 06 10:01:31 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 10:01:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689021.1073920 (Exim 4.92) (envelope-from ) id 1rho5Y-0004Cq-TI; Wed, 06 Mar 2024 10:01:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689021.1073920; Wed, 06 Mar 2024 10:01:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rho5Y-0004Cj-PJ; Wed, 06 Mar 2024 10:01:28 +0000 Received: by outflank-mailman (input) for mailman id 689021; Wed, 06 Mar 2024 10:01:27 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rho5X-0004CO-2E for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 10:01:27 +0000 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on20613.outbound.protection.outlook.com [2a01:111:f400:7e88::613]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 7d2f18f2-dba0-11ee-a1ee-f123f15fe8a2; Wed, 06 Mar 2024 11:01:24 +0100 (CET) Received: from PH8PR12MB7326.namprd12.prod.outlook.com (2603:10b6:510:216::7) by DM4PR12MB7766.namprd12.prod.outlook.com (2603:10b6:8:101::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.24; Wed, 6 Mar 2024 10:01:21 +0000 Received: from PH8PR12MB7326.namprd12.prod.outlook.com ([fe80::32a0:32b6:d5af:9ad0]) by PH8PR12MB7326.namprd12.prod.outlook.com ([fe80::32a0:32b6:d5af:9ad0%5]) with mapi id 15.20.7362.019; Wed, 6 Mar 2024 10:01:21 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 7d2f18f2-dba0-11ee-a1ee-f123f15fe8a2 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KYIyOovGYcGEq4o3TmvJ2ym3tDLIKVa5EAKV7RHTffktys+fnFrE2pIHpynw9mab2BOTc1RY+gKYbL5Eq1HYt3ZwigpLUEcOj8zFz5EDs+vzGQXxpQZcMk+3YxC9E5eySf35g2XPaFJ1L6CM6Q2Fv5hk/wb0dwovoK/LRYdCNaD6y/wgjcKJDe4KkofaJ4XcJ/xglLp4IGbKw1Q8loPyYZkA5MLfha5oHWbrTdkXRP4TzLEfnB30PAIwhbDkr9m68aSRJpDCBqJTMQtG1MZrZh1NzwXVWAvxozhn2WdkLAckWBABHZUjkZ9V4GXC2rdjcO5WSKfnYHNa8YhsixIfZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=oBhK/IB2GdsV13+WxPlXSYI7heqkoszeKiJGK1lctL4=; b=XW9m8S3Z9o/Vhvhch03GMi4s2+KIS9nJefCji5AUWJS6u0daJaVYvJqbg/ZwOECgQpJDOQtle1/wbpvX3V2JOmm7lzIswFIxQ47TB3iyVj2tbJHfDPl0lyV7bg9Vo+BbDza3PNziJ84QYn15bqg2ocPyKHPcJWbtR4fLeprAinVGDbwP+D5T1Dn5ZOdyjkBWnYrRIBmJ717ZVRfJ9PvmSQ2gSCny0JgObJIIqCkqfoYkCzPagOblu4HYw64+AlU1zDcDZeWQW1dhCSvNA0oazZcgv0g0FLXX06BihxJt4iCunt9Zjp1upj2miJp9BcTobX9furMUBznV/UpMszCPXw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oBhK/IB2GdsV13+WxPlXSYI7heqkoszeKiJGK1lctL4=; b=s2NttSzsHTqObaLytmPhwPPpWVG0rjFYTRfQ5M9DM3tbELKVVZ9lT6dz9uVwnADIuiQCPoV+DGLJU5iWtm/nulGOb5towUiGQsT+d1Whm7+b5DnaFiLrmlcME9VHFexGVNxbV/tvDTE74pq3Mx3bNLjPowGcqBmQTYLvqLPQz5Q= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; Message-ID: <5f751e78-de85-469a-9a01-ddde0ebd1db6@amd.com> Date: Wed, 6 Mar 2024 10:01:16 +0000 User-Agent: Mozilla Thunderbird Subject: Re: Xen 4.19 release status tracking list [ March ] To: Oleksii , xen-devel@lists.xenproject.org Cc: committers@xenproject.org, community.manager@xenproject.org, Kelly Choi References: <91cc3f76029357f34bd5ca21966c42f0acb73720.camel@gmail.com> Content-Language: en-GB From: Ayan Kumar Halder In-Reply-To: <91cc3f76029357f34bd5ca21966c42f0acb73720.camel@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO2P265CA0378.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a3::30) To PH8PR12MB7326.namprd12.prod.outlook.com (2603:10b6:510:216::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH8PR12MB7326:EE_|DM4PR12MB7766:EE_ X-MS-Office365-Filtering-Correlation-Id: e725f417-28d5-487d-e1c4-08dc3dc45fab X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: jOvljIzDBP60qFCp2HIfy76YvJ6W99PFV9/vnfUyFujWTcUoY4wtmDHNqcPEGdpVT5gDDGRBZeFio1m6ruS1tLrnkGcr7g5yRyKHOn3iIqw8/uYyKpKQ3+1bxrmvaAPluwEIbUNA1SrfQ4jlqSu2ruU+ANV2wwyIVNeqcjk6gjE57ca14qKfN0Y064rQ2stwuEwVRTAuy5mzt/1Hm9HNlohEe9tkfcbTTRfIz/2VKt9XRh8F27UQAc4KMwkePHM2wy+Jvp3n4eWVlMx3xGUW0adJahVv3ivLM3BTrCH0EAS5+uTxGe73sL57rkU0b+9/pTz0WHXgI1L55vqSuyPW4Kb+tPoUXbDkBKslj/dmS/b9x6VEi08MGWyXhVXa0eOBbuxKIIinGY8z+l7+tTtXZqs/Lk+dajVR9nfTFw2ZIk2NGw/yicuT7jz7QmsEWtrDw97lzBxfXr4u30ZlKqIZxHlCshGTOf68NJdfEN/JWKn6NpRGHVbnBkbs7apxLExHvwzOBPPr/bbbKbDHMe8iiH0NlBlpQxwmvm8jspF4wywr0oLjxzAI43tcyj6r7mum3ddfUBzlXhe38g9m8Gcmk/XisnvReG0wI6CWbO6zyhYqWk1JrJ6C6PU3DlzpncSt X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH8PR12MB7326.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(376005);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?OU9HckpYSkZ4Vi8xQXZxZnVtZDJ4RmlFWVlKRWNHS0d0S3A2VnljaW1kZGhx?= =?utf-8?B?R1JtSUN2QklmL3ZiZzhhV0hmOHp2bXpmWVdxcHh1aFg3M1hCNlFjWlFDQ3RJ?= =?utf-8?B?WTZZbFJWNjBCRzBKVHlidDBSSjlkQUhLaE1wdFZidDZHazRvbkVEcVFNeGEw?= =?utf-8?B?Z28vcHhRVFNaWWJVcmwvYllsREdseDdzQzlsSERSRTlUVndZdXNHOUpnRG5G?= =?utf-8?B?TTRKL0UwaUIwV25nVnVEZGx6YThrZngvZUsyVmx3Y2NhbEd1NGhYRlVwQVQz?= =?utf-8?B?eURCWU9ZTVFqaGtVcXRHa2ZRd0sxUWJ2YUJnTlZjS1BOelFVZGdvTTJ2em05?= =?utf-8?B?ZDJhcHhmWWt1M2RJY1JLckx5UFdXdEVlY2lHR3RtY0QwTHlSVFdtWTJYYmxH?= =?utf-8?B?aHNRZ2I5UEJndHJUL1dOb0VpWlJXbkFFVGJYZkhjTGgxR05HZFZwNkw3eDl6?= =?utf-8?B?UTVrTU1QaEdlMXZWa0RGSU50N2IydmRwdjF2ODYxMUJIYU9ibnl1ZlppL216?= =?utf-8?B?ZnNwRks5SUpBZkFaMmJLdXdYYUpzQTdxNEdOMlVDb3VjOFNULzZoWS9kMDFL?= =?utf-8?B?TEErQnlkbTErb2xwN1M4aWpuNEU3UWg5ampuci9XWnZCRnNhS2Eyc1VjaUdC?= =?utf-8?B?MHhoQzA3aFVaOExqTXBaWE11UDd5ZllRUnN2L0pyeERGb2VCUUw0dGZFbElB?= =?utf-8?B?NURPbml6M0ZBSEhjYW52anZUb25UTjEwK3BVa0VzOVFjdkxYckNYT0FpS1lv?= =?utf-8?B?eTRWdHA3eWV1R3BRMzVxdk5td2lBRlZobDltbEd2ZGJhdmUzTG9udmtEdVF2?= =?utf-8?B?a2tLNlFrMVdlVkVSbHRpMC9jYlMrZUxjY2Z6VW50Y0NMR09qZGFabnBUb0Vq?= =?utf-8?B?LzQ0QkVZNjhEYUNmN3hDNkJxdFhnR2lkRllMR0F4N1VhZmtaWU44ZllkcFg0?= =?utf-8?B?VkxOUVI1bm45SHF2SzZxa2dZZzFXU3diNEVFVTg2Vk95bWpVU3lLUVZsT1RY?= =?utf-8?B?YlBReEhLc3N1aXFpbVdCQi93Q0UxbkRNYm5IRWwzT1d6RzVDUXRqd1RxRmVi?= =?utf-8?B?WjhFWXZ5aGZMNG5hOUpMSlg1aTUwV1hSMmhkeUhubENlcitXYkxPYS90cm9P?= =?utf-8?B?cFJyczU4dnhvSkFWUlRXd2d3bHg4RHk1d3lPV1N4RkRmVVRBQjlub01vbkN3?= =?utf-8?B?OThNaU1pS0J4Mko1ayttR2lZeEtUTTJuTnRCaWlyQzR3ekVRWDlEQ2g2U1VX?= =?utf-8?B?WkJzYUpYQUZaMSsrRzlpQUcrb0w0ZWhzQzk0NW1MQVJlZEI0MXBhRW83bXps?= =?utf-8?B?NEFKK3h1Z292Tmxqd1FPUk9PSk1ENlJyM3puQTNodmt1YWhhbmhtSlpHNk83?= =?utf-8?B?LzlZWFJmdnJPWC9lN0loODMzUWNtMkJ3MTNoeVNaTTRMaHdETTdkRS84V3di?= =?utf-8?B?ZUtVbDJaYXNBMXNOam1raVRFY3l3RENlZlE2bnMzcnRXTGZLYkt0cFNacmNh?= =?utf-8?B?N082UVlFTHBnRUpzUTFrTS90bTgwc2FzVVkvRHJwUGJPLzdEVG9IdGRISG9M?= =?utf-8?B?Zk4zTmFnaHVxM2I5OUdjRzV2ZzFSS2ZUdFlhb2N0Z3RxeVYrZVU3TXFnWEsw?= =?utf-8?B?ZGVVdzVnWmxNVjFDeFJ3TnVFdEExMWJJWXZTQndwYm5wQ2w3dmhyK3JKeS9J?= =?utf-8?B?OGV0cUc5cEcreFJXeS9scU1GMXpNS1ZiRzVFaUIzYmE5MUhSdHJYZmdaZGpQ?= =?utf-8?B?WU0yU29lRWVBc1AxUkpXWmMwbWo5bllMV2haK25tUndnSjQyMTc1aTRuOG1S?= =?utf-8?B?TUFWOTAwVEhhL2U0WG5jbWd0UTBTU0U2VW5nSlV5a0xYNDdDS1l1bHAxZ3V3?= =?utf-8?B?eWw0TWtxT1RPdzIwSzNKZ3JhdEw5S2ZVL2FPY1Vac0JaRlovMDhqaGhhcmpX?= =?utf-8?B?MnEva2EzeDI2MmwwR05yMkkwQjBPazZ5Z01MUGgxSURYMy8zSGxUTWNleW84?= =?utf-8?B?YW4rZGhPU0VMZnNVVStoTktEdEt1enFPUEhORDZzME5KUnVBcm9XSUp4dFlp?= =?utf-8?B?MGhpc1VLU2ZaREc1VHBlT0pUMlRnOExuRGVGOEw3bnVPaWFNa082K245OGFT?= =?utf-8?Q?EWmfDcMbZTN2JvN5/Khn7wrvP?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: e725f417-28d5-487d-e1c4-08dc3dc45fab X-MS-Exchange-CrossTenant-AuthSource: PH8PR12MB7326.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Mar 2024 10:01:20.9773 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: TJ8XAwqHI7I4N54flGtywS76j88WPNnKYk8JfUtZv9pzdvFJOMmDfABXT19nB8p5zNuMGyA9hMxdznPxMCKTQw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB7766 On 01/03/2024 17:21, Oleksii wrote: > CAUTION: This message has originated from an External Source. Please use proper judgment and caution when opening attachments, clicking links, or responding to this email. > > > Hello everyone, Hi Oleksii, Greetings > > I would like to share with you a list for status tracking based on Xen > ML and community members comments: > > Arm: > * [PATCH v6 00/15] Arm cache coloring [ > https://lore.kernel.org/xen-devel/20240129171811.21382-1-carlo.nonato@minervasys.tech/ > ]: > new patch series version [v6] was sent > > * [PATCH v13 00/14] PCI devices passthrough on Arm, part 3 [ > https://lore.kernel.org/xen-devel/20240202213321.1920347-1-stewart.hildebrand@amd.com/ > ] > > PPC: > * [PATCH v2 0/7] Early Boot Allocation on Power [ > https://lore.kernel.org/xen-devel/cover.1702607884.git.sanastasio@raptorengineering.com/ > ] > > RISC-V: > * [PATCH v4 05/23] Enable build of full Xen for RISC-V [ > https://lore.kernel.org/xen-devel/cover.1708962629.git.oleksii.kurochko@gmail.com/ > ]: > a bulk of patch have been merged already and a new version was sent > to ML There is one more series https://patchew.org/Xen/20240220121743.3680715-1-ayan.kumar.halder@amd.com/ (Support for HVC_DCC registers). - Ayan > > x86: > * [PATCH 0/4] iommu/x86: fixes/improvements for unity range checks [ > https://lore.kernel.org/xen-devel/20240201170159.66330-1-roger.pau@citrix.com/ > ]: > * almost patch series have been merged already except the patch: > [PATCH 4/4] iommu/x86: make unity range checking more strict > > * [PATCH 0/8] x86: support AVX10.1 [ > https://lore.kernel.org/xen-devel/298db76f-d0ee-4d47-931f-1baa1a7546cf@suse.com/ > ] > > * APX support? > > * [PATCH v4 0/8] x86emul: misc additions [ > https://lore.kernel.org/xen-devel/9dd23064-c79e-4a50-9c71-c0e73b189944@suse.com/ > ]: > * [PATCH v4 3/8] VMX: tertiary execution control infrastructure - > was merged > > * [PATCH 0/7] VT-d: SATC handling and ATS tidying [ > https://lore.kernel.org/xen-devel/25506838-b818-4686-8c16-3a198338af44@suse.com/ > ] > > * [XEN PATCH 0/9] x86: parallelize AP bring-up during boot [ > https://lore.kernel.org/xen-devel/cover.1699982111.git.krystian.hebel@3mdeb.com/ > ] > > * [PATCH v2 00/12] x86: memcpy() / memset() (non-)ERMS flavors plus > fallout [ > https://lore.kernel.org/xen-devel/8f56a8f4-0482-932f-96a9-c791bebb4610@suse.com/ > ] > * [PATCH v2 01/12] x86: introduce ioremap_wc() - were merged > > common: > * annotate entry points with type and size" series: > The bulk of this has gone in, but there'll want to be follow-ups. > > * limit passing around of cpu_user_regs [ > https://lore.kernel.org/xen-devel/ebc330a9-eafa-4858-b5cf-5694c4da911d@suse.com/ > ]: > new patch series version was sent. > > * [PATCH v2 (resend) 00/27] Remove the directmap [ > https://lore.kernel.org/xen-devel/20240116192611.41112-1-eliasely@amazon.com/ > ] > > * [PATCH v9 0/7] Introduce generic headers [ > https://lore.kernel.org/all/cover.1708086091.git.oleksii.kurochko@gmail.com/ > ]: > Almost fully patch series were merged except several patches: > * [PATCH v9 1/7] automation: introduce fixed randconfig for > RISC-V > * [PATCH v9 2/7] xen/asm-generic: introduce stub header > monitor.h > * [PATCH v9 6/7] xen/ppc: switch PPC to use asm-generic/device.h > > * [PATCH] move __read_mostly to xen/cache.h [ > https://lore.kernel.org/xen-devel/f25eb5c9-7c14-6e23-8535-2c66772b333e@suse.com/ > ] > > * [XEN PATCH v2 1/3] xen: introduce STATIC_ASSERT_UNREACHABLE() [ > https://lore.kernel.org/xen-devel/42fc6ae8d3eb802429d29c774502ff232340dc84.1706259490.git.federico.serafini@bugseng.com/ > ] > > * MISRA rules updates: > [PATCH v2] docs/misra/rules.rst update [ > https://lore.kernel.org/xen-devel/alpine.DEB.2.22.394.2402131431070.1925432@ubuntu-linux-20-04-desktop/T/#maded3df1bebe68d0fe53c73e89f996ec395a39e5 > ] > > * [XEN PATCH 00/10] address some violations of MISRA C Rule 20.7 [ > https://lore.kernel.org/xen-devel/cover.1709219010.git.nicola.vetrini@bugseng.com/T/#t > ] > > * [PATCH v4 00/12] xen/spinlock: make recursive spinlocks a dedicated > type [ > https://lore.kernel.org/xen-devel/20231212094725.22184-1-jgross@suse.com/T/#t > ] > > * [PATCH v2 0/5] xen/livepatch: fixes for the pre-apply / post-revert > hooks [ > https://lore.kernel.org/xen-devel/20240227112528.4540-1-roger.pau@citrix.com/T/#m620c827bd097522d9d87b7f6511bc1599f6a8c84 > ] > > Completed: > Arm: > * [PATCH v1 repost 0/4] xen/arm64: Rework the MMU-off code > (idmap) so it is self-contained [ > https://lore.kernel.org/xen-devel/20240116143709.86584-1-julien@xen.org/ > ] > > x86: > * [PATCH v9 0/6] tools: enable xenstore-stubdom to use 9pfs [ > https://lore.kernel.org/xen-devel/20240229124830.13680-1-jgross@suse.com/ > ] > > common: > * [PATCH v2] NUMA: no need for asm/numa.h when !NUMA [ > https://lore.kernel.org/xen-devel/94cffa48-5e31-4557-827d-c6dec6031d05@suse.com/ > ] > * [PATCH] xen: move BUG_ON(), WARN_ON(), ASSERT(), > ASSERT_UNREACHABLE() to xen/bug.h [ > https://lore.kernel.org/xen-devel/4887b2d91a4bf2e8b4b66f03964259651981403b.1706897023.git.oleksii.kurochko@gmail.com/ > ] > * [PATCH] xen/lib: introduce generic find next bit operations [ > https://lore.kernel.org/xen-devel/52730e6314210ba4164a9934a720c4fda201447b.1706266854.git.oleksii.kurochko@gmail.com/ > ] > > Please reply with items you would like to see in 4.19 so that people > know what is happening and prioritize accordingly. > You're welcome to provide a description and use cases of the feature > you're working on. > > Have a nice week! > > Best regards, > Oleksii > From xen-devel-bounces@lists.xenproject.org Wed Mar 06 10:24:40 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 10:24:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689032.1073929 (Exim 4.92) (envelope-from ) id 1rhoRs-000832-P0; Wed, 06 Mar 2024 10:24:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689032.1073929; Wed, 06 Mar 2024 10:24:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhoRs-00082v-MG; Wed, 06 Mar 2024 10:24:32 +0000 Received: by outflank-mailman (input) for mailman id 689032; Wed, 06 Mar 2024 10:24:31 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhoRr-00082p-Lw for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 10:24:31 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhoRl-0003vs-6I; Wed, 06 Mar 2024 10:24:25 +0000 Received: from gw1.octic.net ([88.97.20.152] helo=[10.0.1.240]) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1rhoRk-0005pD-TJ; Wed, 06 Mar 2024 10:24:25 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID; bh=USlFkwQQXNjREb0RjuNpLPpBaj0cLKNsxoJ/LiNtvvM=; b=RTZb++6v3PvErwKGkny2o8dvdH CuWSHRZGYvF10SmpmzV0P5mYTEAu+PDqD0w6MVZtWwd9yQ7j23HBUHrltzST37ed10/L27rRvIfw8 afJKjwv3bMUGdWIo6wQ9KZzdS+ZFgInBVd3S1G5hSb4ZzwZ9NOqP5jM3pB8BOt8XXkVA=; Message-ID: <3264c64f-815a-4340-85cc-286c4983e902@xen.org> Date: Wed, 6 Mar 2024 10:24:22 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86+Arm: drop (rename) __virt_to_maddr() / __maddr_to_virt() Content-Language: en-GB To: Jan Beulich Cc: Andrew Cooper , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel , Oleksii Kurochko , "xen-devel@lists.xenproject.org" References: <6fb7b2c9-6665-4cbd-a1c4-24ebf7514b88@suse.com> <610e5e76-db0f-4509-84ed-c1bc085b4b6e@suse.com> From: Julien Grall In-Reply-To: <610e5e76-db0f-4509-84ed-c1bc085b4b6e@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Jan, On 06/03/2024 09:59, Jan Beulich wrote: > On 06.03.2024 10:44, Julien Grall wrote: >> On 06/03/2024 07:22, Jan Beulich wrote: >>> On 05.03.2024 20:24, Julien Grall wrote: >>>> The title is quite confusing. I would have expected the macro... >>>> >>>> On 05/03/2024 08:33, Jan Beulich wrote: >>>>> There's no use of them anymore except in the definitions of the non- >>>>> underscore-prefixed aliases. Rename the inline functions, adjust the >>>>> virt_to_maddr() #define-e, and purge the (x86-only) maddr_to_virt() one, >>>>> thus eliminating a bogus cast which would have allowed the passing of a >>>>> pointer type variable into maddr_to_virt() to go silently. >>>>> >>>>> Signed-off-by: Jan Beulich >>>>> >>>>> --- a/xen/arch/arm/include/asm/mm.h >>>>> +++ b/xen/arch/arm/include/asm/mm.h >>>>> @@ -256,12 +256,12 @@ static inline void __iomem *ioremap_wc(p >>>>> /* Page-align address and convert to frame number format */ >>>>> #define paddr_to_pfn_aligned(paddr) paddr_to_pfn(PAGE_ALIGN(paddr)) >>>>> >>>>> -static inline paddr_t __virt_to_maddr(vaddr_t va) >>>>> +static inline paddr_t virt_to_maddr(vaddr_t va) >>>>> { >>>>> uint64_t par = va_to_par(va); >>>>> return (par & PADDR_MASK & PAGE_MASK) | (va & ~PAGE_MASK); >>>>> } >>>>> -#define virt_to_maddr(va) __virt_to_maddr((vaddr_t)(va)) >>>>> +#define virt_to_maddr(va) virt_to_maddr((vaddr_t)(va)) >>>> >>>> ... to be removed. But you keep it and just overload the name. I know it >>>> is not possible to remove the macro because some callers are using >>>> pointers (?). >>> >>> Indeed. I actually tried without, but the build fails miserably. >>> >>>> So I would rather prefer if we keep the name distinct on Arm. >>>> >>>> Let see what the other Arm maintainers think. >>> >>> Well, okay. I'm a little surprised though; I was under the impression >>> that a goal would be to, eventually, get rid of all the __-prefixed >>> secondary variants of this kind of helpers. >> >> Because of MISRA? If so, you would be replacing one violation by another >> one (duplicated name). IIRC we decided to deviate it, yet I don't >> particular want to use the pattern in Arm headers when there is no need. >> >> If you are trying to solve MISRA, then I think we want to either remove >> the macro (not possible here) or suffix with the double-underscore the >> static inline helper. > > No, Misra is only secondary here. Many of these helpers come in two flavors > such than one can be overridden in individual source files. That's mainly > connected to type-safety being generally wanted, but not always easy to > achieve without a lot of code churn. We've made quite a bit of progress > there, and imo ultimately the need for two flavors of doing the same thing > ought to disappear. What about converting the static inline to a macro? As we cast 'va', I don't think we have any benefits to keep the static inline helper and provide a thin wrapper with just a cast. This would address my concern and possibly address your wish to remove the double-underscore version. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Wed Mar 06 10:26:54 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 10:26:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689035.1073940 (Exim 4.92) (envelope-from ) id 1rhoU9-00008L-6Y; Wed, 06 Mar 2024 10:26:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689035.1073940; Wed, 06 Mar 2024 10:26:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhoU9-00008D-2h; Wed, 06 Mar 2024 10:26:53 +0000 Received: by outflank-mailman (input) for mailman id 689035; Wed, 06 Mar 2024 10:26:52 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhoU8-000087-6G for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 10:26:52 +0000 Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [2a00:1450:4864:20::535]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 0b95eb85-dba4-11ee-afda-a90da7624cb6; Wed, 06 Mar 2024 11:26:51 +0100 (CET) Received: by mail-ed1-x535.google.com with SMTP id 4fb4d7f45d1cf-5643ae47cd3so8739109a12.3 for ; Wed, 06 Mar 2024 02:26:51 -0800 (PST) Received: from [10.80.67.149] (default-46-102-197-194.interdsl.co.uk. [46.102.197.194]) by smtp.gmail.com with ESMTPSA id v3-20020aa7d9c3000000b0056629f5de88sm6723865eds.61.2024.03.06.02.26.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 Mar 2024 02:26:50 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 0b95eb85-dba4-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709720811; x=1710325611; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=hqkZcduoLs4pC8nJPKoT71taUuDqf7NQvEL80J1mJcM=; b=dCT3meQaS3sShxhMh7kJF/EWUvEsTMtBR2vC0PhK82xmLzzJL46hhU5DqKMn0pRxmG ZmQMiLZOW1S2Crw+Q8zdVGQn2WNtcCbuKRLHsY7F7YTSvM4DTXdxgFZK5K0WaC/rKyg5 Wphqz4AwKQMFd3gHcfCl3Z/1pOQCURFUxAhV4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709720811; x=1710325611; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=hqkZcduoLs4pC8nJPKoT71taUuDqf7NQvEL80J1mJcM=; b=N2dKgpKGF+hxwzDjyZvGZHhIxmEWDvpmFiYUPoWBn5Uicq5thPPGeZMep/J3ic/Kvh GgPHzD/pWKmkwWJ6ta3qz9SCfBC5UC8UNBUbGps558MLswAxyEZcgRYuIIQ8yZN1GUuf /nChS/xEZSvj1Q9lcmKdsGxxXvB5oy+oYnWcbCjyvgFRo5jNX9lOWIgGYzys65omgdzX DsGBtQCqXTtz34xATM9lvts+O0Pc94BGN4Jgh2efcWf2dCb0Gxc40Vhr3dIMTCY+TPQa wYGYSI/jn0FV2oJSBaf+9fBJHG87p8M/1iEZPpS2wKH8hH24BbfhUUsLcCctJ3E2mdTA fIEw== X-Forwarded-Encrypted: i=1; AJvYcCW9Wd9nDt8rSACG5AsaTrKjLbbnK0tEYXZX1KkxYnZyDMaeOTGIQjKkwyjBXlJdbmWU8xnDYx0KXmG3Qo3Bm2lia9ra/TjQFyPzRZKo7zI= X-Gm-Message-State: AOJu0YyIia3xXz1EFsx9OQ497VcXVRwYvR1rPfNH0Tp+mtty3pc78FMu xDlOw/fDxx8i6WzF19itOziXEs00DJZor+qRJQTO4XF7i3P4IEizGQmm9NuDADA= X-Google-Smtp-Source: AGHT+IHpMcPo2RSBtHc31T0o8KdLkjVN8H3kkRBzJ96B+RdVPGAqZ0GMWJP6k8GygTCJl33iC7zizA== X-Received: by 2002:a05:6402:278f:b0:567:1221:d486 with SMTP id b15-20020a056402278f00b005671221d486mr9061515ede.33.1709720810594; Wed, 06 Mar 2024 02:26:50 -0800 (PST) Message-ID: <526a5ba3-1666-4f14-bb6a-01410ab1d350@citrix.com> Date: Wed, 6 Mar 2024 10:26:49 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/asm: add commas to BUILD_BUG_ON Content-Language: en-GB To: Jan Beulich , "xen-devel@lists.xenproject.org" Cc: Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 06/03/2024 7:34 am, Jan Beulich wrote: > In light of recent observations with how macros are handled by gas, > let's play by what we informally set for ourselves as a guideline: Use > commas to separate parameters/arguments. > > Signed-off-by: Jan Beulich Acked-by: Andrew Cooper However, there are some other examples wanting the same treatment. alternative-asm.h:14:.macro altinstruction_entry orig repl feature orig_len repl_len pad_len asm-defns.h:32:.macro INDIRECT_BRANCH insn:req arg:req asm_defns.h:284:.macro RESTORE_ALL adj=0 compat=0 spec_ctrl_asm.h:107:.macro DO_OVERWRITE_RSB tmp=rax xu Preferably, fix all of these in one go. As for observations about the other architectures, PPC uses commas everywhere.  RISC-V has no .macro's.  ARM looks to be a 50/50 mix. From xen-devel-bounces@lists.xenproject.org Wed Mar 06 10:28:08 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 10:28:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689038.1073950 (Exim 4.92) (envelope-from ) id 1rhoVL-0000je-If; Wed, 06 Mar 2024 10:28:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689038.1073950; Wed, 06 Mar 2024 10:28:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhoVL-0000jX-G1; Wed, 06 Mar 2024 10:28:07 +0000 Received: by outflank-mailman (input) for mailman id 689038; Wed, 06 Mar 2024 10:28:06 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhoVK-0000jP-24 for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 10:28:06 +0000 Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [2a00:1450:4864:20::52f]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 36eff936-dba4-11ee-a1ee-f123f15fe8a2; Wed, 06 Mar 2024 11:28:03 +0100 (CET) Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-55a5e7fa471so9588544a12.1 for ; Wed, 06 Mar 2024 02:28:03 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id fi12-20020a056402550c00b005661badcccesm6674829edb.87.2024.03.06.02.28.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 Mar 2024 02:28:03 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 36eff936-dba4-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709720883; x=1710325683; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=ZCaS9JodpzpYCKp8xEyt6G74gavd2Fizf67rI35Emrc=; b=NtCzTVrEdodvX7GOiAO+Y1JMk0HQ6oHFVNpN3JkXTnEC8aICCM2T5Ro2onmltDx3fk 03yLOkApHtjzpTTGE24SY1xK6SHKEa29FHPYrjFsNQO70yIUewM5284bcIvjfv3GuSF+ X9Hg13wCvZj127DMPmMfLK8TpeFw0T4W8yzHaSGCVLz4gQJqTkvrth2KFtQBA32RcnHj eajPnI2leRpADtUwm2C/fHjtYybVuXrl4IGbi+lRYDu40/vzpoNF2teDHiWJTrboE93T U05sS/Yy+FpA3GmQcSMpSoLQAgn3BWSl3dZp9QIDxy/bu52gkcem06y4wCyyDqVvQ3Fj 6pfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709720883; x=1710325683; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ZCaS9JodpzpYCKp8xEyt6G74gavd2Fizf67rI35Emrc=; b=DmP4fwS9SooSFwAOqFDHw/6u0UXPaFtmG1NQkInurx8OruG50zDf9O+qucUFLf7xZh O9SoGA+x9/uqaSG2PW5UXmlrhDSpKA8RvPlh3hY175eMxqqhiJEJCGLMzZQu2GVpxOjn YJ4vlm+oOdO7iNwaaygiIl6OaxY0hnDmNPkeppLJXx2aRsGGs1GwV2rRVE6Dc5FW6VYN H6iBcY8QiuGKfQYsYqwvqUqNttFTfiaZQGj2QsosAx798TtG8MxSLqz/nfPCrtPQ1z/+ kia2n6ti7585djGY0HTWJoFx3ESGPuCaZWe/9qgq6nn7DwadAPMyczeUmjRdNhqjSxz6 Kjjg== X-Forwarded-Encrypted: i=1; AJvYcCWEjfvRB1rjsWwA2Wrx/wsR7yu+VsMyBzieALlAb0UeXGIs81IYggukV8YBPKdx75BhsKDyrsBrLkdnikV24Eq0aw7C7R83zTJO2vwshCQ= X-Gm-Message-State: AOJu0Yzc4HZSQNLy1D/wYhv3HxFxGacehsk3EqSoyrLChl+kXlGRfzRl 96UKDOToW3GINVTfS+fulGolyixYjJDe4YxwOsB0BwSEc6P29Jc2/hBYiMcaOw== X-Google-Smtp-Source: AGHT+IEJXyTU6vJUo4RX5zLuuqBQZ7XqAKg0TvovsGjJq6zeevI3FGnF2QltXa5rwKW2q8u0FRcICA== X-Received: by 2002:aa7:ce05:0:b0:567:702d:ccb1 with SMTP id d5-20020aa7ce05000000b00567702dccb1mr4944131edv.20.1709720883488; Wed, 06 Mar 2024 02:28:03 -0800 (PST) Message-ID: <4043fd77-4342-43cb-81b9-ca5b8d75b881@suse.com> Date: Wed, 6 Mar 2024 11:28:02 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86+Arm: drop (rename) __virt_to_maddr() / __maddr_to_virt() Content-Language: en-US To: Julien Grall Cc: Andrew Cooper , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel , Oleksii Kurochko , "xen-devel@lists.xenproject.org" References: <6fb7b2c9-6665-4cbd-a1c4-24ebf7514b88@suse.com> <610e5e76-db0f-4509-84ed-c1bc085b4b6e@suse.com> <3264c64f-815a-4340-85cc-286c4983e902@xen.org> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <3264c64f-815a-4340-85cc-286c4983e902@xen.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 06.03.2024 11:24, Julien Grall wrote: > On 06/03/2024 09:59, Jan Beulich wrote: >> On 06.03.2024 10:44, Julien Grall wrote: >>> On 06/03/2024 07:22, Jan Beulich wrote: >>>> On 05.03.2024 20:24, Julien Grall wrote: >>>>> The title is quite confusing. I would have expected the macro... >>>>> >>>>> On 05/03/2024 08:33, Jan Beulich wrote: >>>>>> There's no use of them anymore except in the definitions of the non- >>>>>> underscore-prefixed aliases. Rename the inline functions, adjust the >>>>>> virt_to_maddr() #define-e, and purge the (x86-only) maddr_to_virt() one, >>>>>> thus eliminating a bogus cast which would have allowed the passing of a >>>>>> pointer type variable into maddr_to_virt() to go silently. >>>>>> >>>>>> Signed-off-by: Jan Beulich >>>>>> >>>>>> --- a/xen/arch/arm/include/asm/mm.h >>>>>> +++ b/xen/arch/arm/include/asm/mm.h >>>>>> @@ -256,12 +256,12 @@ static inline void __iomem *ioremap_wc(p >>>>>> /* Page-align address and convert to frame number format */ >>>>>> #define paddr_to_pfn_aligned(paddr) paddr_to_pfn(PAGE_ALIGN(paddr)) >>>>>> >>>>>> -static inline paddr_t __virt_to_maddr(vaddr_t va) >>>>>> +static inline paddr_t virt_to_maddr(vaddr_t va) >>>>>> { >>>>>> uint64_t par = va_to_par(va); >>>>>> return (par & PADDR_MASK & PAGE_MASK) | (va & ~PAGE_MASK); >>>>>> } >>>>>> -#define virt_to_maddr(va) __virt_to_maddr((vaddr_t)(va)) >>>>>> +#define virt_to_maddr(va) virt_to_maddr((vaddr_t)(va)) >>>>> >>>>> ... to be removed. But you keep it and just overload the name. I know it >>>>> is not possible to remove the macro because some callers are using >>>>> pointers (?). >>>> >>>> Indeed. I actually tried without, but the build fails miserably. >>>> >>>>> So I would rather prefer if we keep the name distinct on Arm. >>>>> >>>>> Let see what the other Arm maintainers think. >>>> >>>> Well, okay. I'm a little surprised though; I was under the impression >>>> that a goal would be to, eventually, get rid of all the __-prefixed >>>> secondary variants of this kind of helpers. >>> >>> Because of MISRA? If so, you would be replacing one violation by another >>> one (duplicated name). IIRC we decided to deviate it, yet I don't >>> particular want to use the pattern in Arm headers when there is no need. >>> >>> If you are trying to solve MISRA, then I think we want to either remove >>> the macro (not possible here) or suffix with the double-underscore the >>> static inline helper. >> >> No, Misra is only secondary here. Many of these helpers come in two flavors >> such than one can be overridden in individual source files. That's mainly >> connected to type-safety being generally wanted, but not always easy to >> achieve without a lot of code churn. We've made quite a bit of progress >> there, and imo ultimately the need for two flavors of doing the same thing >> ought to disappear. > > What about converting the static inline to a macro? As we cast 'va', I > don't think we have any benefits to keep the static inline helper and > provide a thin wrapper with just a cast. > > This would address my concern and possibly address your wish to remove > the double-underscore version. Hmm, I didn't even think in that direction, seeing that generally we aim at moving from macros to inline functions. But yes, if converting to a macro is acceptable, that'll be what I do in v2 then. Jan From xen-devel-bounces@lists.xenproject.org Wed Mar 06 10:33:36 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 10:33:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689041.1073960 (Exim 4.92) (envelope-from ) id 1rhoaa-00030w-6h; Wed, 06 Mar 2024 10:33:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689041.1073960; Wed, 06 Mar 2024 10:33:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhoaa-00030p-36; Wed, 06 Mar 2024 10:33:32 +0000 Received: by outflank-mailman (input) for mailman id 689041; Wed, 06 Mar 2024 10:33:31 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhoaZ-00030j-EN for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 10:33:31 +0000 Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [2a00:1450:4864:20::12b]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id f9bd474e-dba4-11ee-afda-a90da7624cb6; Wed, 06 Mar 2024 11:33:30 +0100 (CET) Received: by mail-lf1-x12b.google.com with SMTP id 2adb3069b0e04-5131c48055cso2090512e87.1 for ; Wed, 06 Mar 2024 02:33:30 -0800 (PST) Received: from [10.80.67.149] (default-46-102-197-194.interdsl.co.uk. [46.102.197.194]) by smtp.gmail.com with ESMTPSA id k23-20020a170906a39700b00a45aed84509sm1147699ejz.114.2024.03.06.02.33.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 Mar 2024 02:33:29 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f9bd474e-dba4-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709721210; x=1710326010; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=0DuHZk7DfosDTAwY8p2rqugvHEMWyCHkFZP9gg/EL5w=; b=i8ipgrIK5UwjXZjNk01NM3ETjm6XJ5KbQKiWJLOIyRH4PbBPdDItBXyQTChROC1lPF GCeDO2RT+OVu2cOoUhmfM3pSck8d7ffOdnnoFTP04RrPZv/T1EDmrDU/8JmHuAC2PjV2 xNzfhj9I55j36DRWfUutU8eq7LTlw6HxthfEo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709721210; x=1710326010; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=0DuHZk7DfosDTAwY8p2rqugvHEMWyCHkFZP9gg/EL5w=; b=NggFOYq5h8oJEAeyp7A4ZefcM7kRrbjRdaiERuCgxMq7ygwbPc+pwCMjW00pp/Ce37 SH9cY62k2E6gIUOggQTLPMG1TJE7tUBt9bKAfjm1+YHlUsbMqmRd89OetWgPwCJd6ULR tHywM0I9SNb83iqySXDH3PAAfLX29D8Hi3krQ1eKKWa9zbs2WBP3nXTQ6OF0M2rAtvMQ LL1JybRYBdmimxFoXMDBlP6gpI5M5V7s8cuNmpqJJBCgX4aOi506W7w+nGiSkVXt/u91 wD4UavOktcAGaABbMdINR9R69qIg++JNjOR4KZpdVxsSo1kGqEtIsk/SZQTcWhBLkBgE FxcA== X-Forwarded-Encrypted: i=1; AJvYcCXEVCx3L8V5i+s+SjnhURMfgBHwAsSU+beh78xPZqX6Ymx/aaAAXK4FB5aKDeyRERqp1vlzGNEldA9bu64TtDlbW1xL3MmnzYH7EPOLCzY= X-Gm-Message-State: AOJu0YwQIBMmvHAT4avz6e0WrdjW8/l9GONJN1RCuJuvj1BKB+yMBRND CJyptR4qwsxRLYK25+rL4os05bDI55qI11aQveEmqzont/pjC6JAfPXGnIg5mKk= X-Google-Smtp-Source: AGHT+IEA0Dva6xyEuhXZ/lo0Z/hfb720KSOM5aLok8UG9lQh7bA0wur87D4uVkKY4GiABfXSIPREZw== X-Received: by 2002:ac2:5ec5:0:b0:513:69b7:7522 with SMTP id d5-20020ac25ec5000000b0051369b77522mr210020lfq.28.1709721210130; Wed, 06 Mar 2024 02:33:30 -0800 (PST) Message-ID: <76cdb4b4-a9f5-46e6-bb30-515ffb37c45a@citrix.com> Date: Wed, 6 Mar 2024 10:33:28 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/entry: shrink insn size for some of our EFLAGS manipulation Content-Language: en-GB To: Jan Beulich , "xen-devel@lists.xenproject.org" Cc: Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <0ba4903d-638d-408e-bcd4-7c13cb56e078@suse.com> From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <0ba4903d-638d-408e-bcd4-7c13cb56e078@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 05/03/2024 2:04 pm, Jan Beulich wrote: > --- a/xen/arch/x86/x86_64/entry.S > +++ b/xen/arch/x86/x86_64/entry.S > @@ -52,7 +52,7 @@ UNLIKELY_END(syscall_no_callback) > movq %rax,TRAPBOUNCE_eip(%rdx) > movb %cl,TRAPBOUNCE_flags(%rdx) > call create_bounce_frame > - andl $~X86_EFLAGS_DF,UREGS_eflags(%rsp) > + andb $~(X86_EFLAGS_DF >> 8), UREGS_eflags + 1(%rsp) The other adjustments are fine, but what on earth are we doing with DF here? This looks straight up buggy.  We've got no legitimate reason to be playing with the guest's view of DF. ~Andrew From xen-devel-bounces@lists.xenproject.org Wed Mar 06 10:49:26 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 10:49:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689046.1073970 (Exim 4.92) (envelope-from ) id 1rhopj-0005ML-Fr; Wed, 06 Mar 2024 10:49:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689046.1073970; Wed, 06 Mar 2024 10:49:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhopj-0005ME-Cf; Wed, 06 Mar 2024 10:49:11 +0000 Received: by outflank-mailman (input) for mailman id 689046; Wed, 06 Mar 2024 10:49:10 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhopi-0005M8-MA for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 10:49:10 +0000 Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [2a00:1450:4864:20::533]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 290ffb3b-dba7-11ee-afda-a90da7624cb6; Wed, 06 Mar 2024 11:49:09 +0100 (CET) Received: by mail-ed1-x533.google.com with SMTP id 4fb4d7f45d1cf-55a5e7fa471so9623885a12.1 for ; Wed, 06 Mar 2024 02:49:09 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ij26-20020a056402159a00b00562d908daf4sm6745630edb.84.2024.03.06.02.49.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 Mar 2024 02:49:08 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 290ffb3b-dba7-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709722148; x=1710326948; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=CpnzL7zGupMqwZS40pL/dZlKvEN0NLrUTaa9NvbyAoM=; b=JYs1g8R+D+DnNnLkrOpAj/wo+Wr+MCz3DFJHOcrWrL8bcGMrAxDKc9C26pGOUMqBOd RqB4keqi19tT4WM7cdeNF52i1rg7HO79fKaNY7zyEX1/H7WX30zWHHrUcmup+VFAN1Pi ozkqvbSSSfG0PIW9+Hyud4kQyT/M2l9eGhC9zsOVjh2ABIQ5cHLWpQjYg9VVaGn7JSaL r3kOWLlmJIqKFrx4334oMsARYb3cHIy4+0T0HndDe/YxAVG39tLGlIrYzR+ZXpOUY+83 Hq2vtD9xNFka676qHiIFGnaJRjgITzV9I2+aMvnPEzl6ztf8H+c1VpprWVz5kJSXFCPk T/4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709722148; x=1710326948; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=CpnzL7zGupMqwZS40pL/dZlKvEN0NLrUTaa9NvbyAoM=; b=R73FS5Ar5IxJ2+8pp6VZSZdApAsJWUjJyVml95DId7JqMYDvsLP7sZX7jjP/mqQz0T VNmH2UA7KDIVD0VT51Bk/0W0GsEIXi7DIzRGRppSh6jfJqAWqnLPlrEglDGsICI8nEJ1 U9RIyheCHDTrXpwGvHJVV/4tHnNtqWnWP7Wdt0yVkwWamZSgU0MEMoR97FhD12YRsZL3 4u9R1EXBD9qLkSPuRfU5n/k1mqnZlm5eLrt6O7eyfm3+hXsbrKqM5ldZqpFIzdtUgyEH 2bvYxKKCeBd8rqLLqan+SaMH7uKaiQwq7eQwDvTTdizfIkGN5ZeUmFk8DuHKM41lQLAh Q3GA== X-Forwarded-Encrypted: i=1; AJvYcCVzqZAgk8YeR6Xz0WYzwHjjwsdhYDx55BRoXXFv/vfXlU8/D0o+NMHPdpvm9jOfD51ZsgKOsrwTLbxgdZNGNGH6Dl0K6i2YpT9Jd3XVs/s= X-Gm-Message-State: AOJu0YwmlLm6Gw6gn+fX9SxV+6264LqFoWSZojcuNSfLFOs3yaktUOIU vgI4AXmKLYtBUdwniweyhN4+zMXQCL6ckMeBVAjlnLatiFo91oy9aATfONJ/cw== X-Google-Smtp-Source: AGHT+IFUN9UXNnj0k0OuNO67KcXEKO/L6tJID18TJdIiegsPnO+4ye8+qQ9VHMUQEauIlMzOKwQXmw== X-Received: by 2002:aa7:ca4e:0:b0:567:f4ea:1066 with SMTP id j14-20020aa7ca4e000000b00567f4ea1066mr528355edt.18.1709722148652; Wed, 06 Mar 2024 02:49:08 -0800 (PST) Message-ID: <54bc9b3f-27af-41ea-9ab4-f35d38fe995d@suse.com> Date: Wed, 6 Mar 2024 11:49:07 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/entry: shrink insn size for some of our EFLAGS manipulation Content-Language: en-US To: Andrew Cooper Cc: Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , "xen-devel@lists.xenproject.org" References: <0ba4903d-638d-408e-bcd4-7c13cb56e078@suse.com> <76cdb4b4-a9f5-46e6-bb30-515ffb37c45a@citrix.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <76cdb4b4-a9f5-46e6-bb30-515ffb37c45a@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 06.03.2024 11:33, Andrew Cooper wrote: > On 05/03/2024 2:04 pm, Jan Beulich wrote: >> --- a/xen/arch/x86/x86_64/entry.S >> +++ b/xen/arch/x86/x86_64/entry.S >> @@ -52,7 +52,7 @@ UNLIKELY_END(syscall_no_callback) >> movq %rax,TRAPBOUNCE_eip(%rdx) >> movb %cl,TRAPBOUNCE_flags(%rdx) >> call create_bounce_frame >> - andl $~X86_EFLAGS_DF,UREGS_eflags(%rsp) >> + andb $~(X86_EFLAGS_DF >> 8), UREGS_eflags + 1(%rsp) > > The other adjustments are fine, but what on earth are we doing with DF here? > > This looks straight up buggy.  We've got no legitimate reason to be > playing with the guest's view of DF. This is the PV equivalent of the SYSCALL_MASK MSR, isn't it? With it not really being an (emulated) MSR, but an agreement that guests will only ever care about having DF cleared (besides the requested way of dealing with the event mask). One of the many things not written down anywhere ... Jan From xen-devel-bounces@lists.xenproject.org Wed Mar 06 11:14:53 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 11:14:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689060.1073980 (Exim 4.92) (envelope-from ) id 1rhpET-0002UN-Fl; Wed, 06 Mar 2024 11:14:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689060.1073980; Wed, 06 Mar 2024 11:14:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhpET-0002UG-CH; Wed, 06 Mar 2024 11:14:45 +0000 Received: by outflank-mailman (input) for mailman id 689060; Wed, 06 Mar 2024 11:14:43 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhpER-0002Sd-On for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 11:14:43 +0000 Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [2607:f8b0:4864:20::32b]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id ba5d6bcf-dbaa-11ee-a1ee-f123f15fe8a2; Wed, 06 Mar 2024 12:14:42 +0100 (CET) Received: by mail-ot1-x32b.google.com with SMTP id 46e09a7af769-6e4f7c0e723so659229a34.3 for ; Wed, 06 Mar 2024 03:14:42 -0800 (PST) Received: from [10.80.67.149] (default-46-102-197-194.interdsl.co.uk. [46.102.197.194]) by smtp.gmail.com with ESMTPSA id dq10-20020a05622a520a00b0042e703a8d74sm1675627qtb.56.2024.03.06.03.14.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 Mar 2024 03:14:39 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ba5d6bcf-dbaa-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709723681; x=1710328481; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=h9W04+U8PkRMf1aC54KQWNwc9UNC7v8bm+5+mkKCBao=; b=FxSXxjOgDFSamPGs/wtQXkWwAZQaDog3vsh9w8xGlTDxRWp9oWy9jv6s/8UPe36GsV 5RDVwYwtewLhncmr+LEi6mAE8uk8kdfuezqX9BS4dSeA9Ljh3hZ2FLIEgncE9PdQ9aOj 7CvyTzfDWnxFp3xihiQP2wx+RAzSQRX8Bji+4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709723681; x=1710328481; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=h9W04+U8PkRMf1aC54KQWNwc9UNC7v8bm+5+mkKCBao=; b=T68ojDqXVzadDYHEQQTITiDpDBEEKSwmsNHNfiEJbZehFtnW6lxb+3vZ87utgUmZFG dUB1MpJkiDbr4jgyr1vS0ig/70O/dVO76pC/QHIeDce5baaqTimfIwoJ7FR9u1Y174HI zIoU8OUNcYoxhCtzMqRZbXapeTZlVeJdA6peuPjHHz8m3Cidqn/h/CC7lC6C2OToQN4c Gn3qPTjUYUCb9uEzxjD/b7OSN867sAnu8MTCrk0CaFnfXgWjbXgKfMdHsfp72C37snsR 7LvS12rJLln87IWnzFDtlinUbckjX1qUsR7JfV33YP+wC0GIQGat5zV6Ysm8pqJ9wwWW Ny5g== X-Forwarded-Encrypted: i=1; AJvYcCU8APQjsl+zU3VPjkudAuT4eP3K1pVko8o6TvAELbIf4eDxRfkec4NlCODfw75vMwNf4MnTfPDuvbyhginpKdJmm0k/YdQjNJB5j6Q0itI= X-Gm-Message-State: AOJu0Yw8iG1Kys7LYYpJS9H7jSenGfu9C8qWxSNdQV/UyAzaRuyc/jAj OTQnv2B0rFhGwKxpsdoTO7XNqThEPtO9+3uk0gVft9zS0mlfUg5hR4QcgGbTzd4= X-Google-Smtp-Source: AGHT+IFg0MfFlmhReZjCYngZwRR7PhLTmUvMXdWgH6gBK8a6+RTIIDWnGEYWY4zBzmRUQ+QNlWMNcw== X-Received: by 2002:a05:6870:31c2:b0:221:3ef1:6885 with SMTP id x2-20020a05687031c200b002213ef16885mr3850466oac.5.1709723680679; Wed, 06 Mar 2024 03:14:40 -0800 (PST) Message-ID: Date: Wed, 6 Mar 2024 11:14:37 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/entry: shrink insn size for some of our EFLAGS manipulation Content-Language: en-GB To: Jan Beulich Cc: Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , "xen-devel@lists.xenproject.org" References: <0ba4903d-638d-408e-bcd4-7c13cb56e078@suse.com> <76cdb4b4-a9f5-46e6-bb30-515ffb37c45a@citrix.com> <54bc9b3f-27af-41ea-9ab4-f35d38fe995d@suse.com> From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <54bc9b3f-27af-41ea-9ab4-f35d38fe995d@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 06/03/2024 10:49 am, Jan Beulich wrote: > On 06.03.2024 11:33, Andrew Cooper wrote: >> On 05/03/2024 2:04 pm, Jan Beulich wrote: >>> --- a/xen/arch/x86/x86_64/entry.S >>> +++ b/xen/arch/x86/x86_64/entry.S >>> @@ -52,7 +52,7 @@ UNLIKELY_END(syscall_no_callback) >>> movq %rax,TRAPBOUNCE_eip(%rdx) >>> movb %cl,TRAPBOUNCE_flags(%rdx) >>> call create_bounce_frame >>> - andl $~X86_EFLAGS_DF,UREGS_eflags(%rsp) >>> + andb $~(X86_EFLAGS_DF >> 8), UREGS_eflags + 1(%rsp) >> The other adjustments are fine, but what on earth are we doing with DF here? >> >> This looks straight up buggy.  We've got no legitimate reason to be >> playing with the guest's view of DF. > This is the PV equivalent of the SYSCALL_MASK MSR, isn't it? Well, is it? It definitely never existed in 32bit builds of Xen, when the int80 direct trap existed. I don't see any evidence of it applying anywhere for compat PV guests either, even those with syscall enabled. > With it not > really being an (emulated) MSR, but an agreement that guests will only ever > care about having DF cleared (besides the requested way of dealing with the > event mask). One of the many things not written down anywhere ... If it's not written down, it doesn't exist... And even if this is supposed to be a PV-FMASK-ish thing, it's buggy because it apples also when #UD is raised for no registered callback.  (And yes, I realise there is a chronology issues here (the #UD check is the newer element), but it really will corrupt state as presented in a SIGSEGV frame. The question we need to answer is whether there is any remotely-credible way that a PV guest kernel author could be expecting this behaviour and relying on it. I honestly don't think there is. It fails the principle of least surprise compared to native behaviour, 32bit PV behaviour, and to every non-SYSCALL based 64bit event also. It either needs writing down somewhere (and the #UD case fixing), or it needs deleing, because continuing to leave it in this state isn't ok. ~Andrew From xen-devel-bounces@lists.xenproject.org Wed Mar 06 11:16:39 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 11:16:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689063.1073989 (Exim 4.92) (envelope-from ) id 1rhpGI-00034T-Sc; Wed, 06 Mar 2024 11:16:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689063.1073989; Wed, 06 Mar 2024 11:16:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhpGI-00034M-Ph; Wed, 06 Mar 2024 11:16:38 +0000 Received: by outflank-mailman (input) for mailman id 689063; Wed, 06 Mar 2024 11:16:37 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhpGH-00034G-Po for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 11:16:37 +0000 Received: from smtp-out1.suse.de (smtp-out1.suse.de [2a07:de40:b251:101:10:150:64:1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id fec9580d-dbaa-11ee-afda-a90da7624cb6; Wed, 06 Mar 2024 12:16:36 +0100 (CET) Received: from imap2.dmz-prg2.suse.org (imap2.dmz-prg2.suse.org [10.150.64.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 851D1224DB; Wed, 6 Mar 2024 11:16:34 +0000 (UTC) Received: from imap2.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap2.dmz-prg2.suse.org (Postfix) with ESMTPS id 30C7313A79; Wed, 6 Mar 2024 11:16:34 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap2.dmz-prg2.suse.org with ESMTPSA id XCQbCpJQ6GWAPgAAn2gu4w (envelope-from ); Wed, 06 Mar 2024 11:16:34 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fec9580d-dbaa-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1709723795; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=HJD9NQU4GT2PqKcUt8lgFTWuNUHKLP/7bYpY6Dky8iA=; b=OqYSsFvurkbpWAFqzH0FyBXUazDIGmT4LZXc5muuobKIfBIh8diXII2tzqtIzLbjONDXj+ 1wVnydbjUOuaEQZ6YTr094Inve0EnFA6tuX/cstQLeUw6qypypd5VOaeX2/OV3Kjp/Ncbp 21diHTJatA9zSylPLU2NdVT4v9vTv/o= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1709723794; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=HJD9NQU4GT2PqKcUt8lgFTWuNUHKLP/7bYpY6Dky8iA=; b=PBN16UXLfCAtRWwP6vyUdKibqBWh6xYB3aWdvnBkrBk9nGnjK26gPKx1vqpHhxE8hjg2yV iRuz53l0mcdNH2OLnAoLwDk3QKY2icy8B6AyVATXchKzrPnRTM804FloX0++Zf3CEJSLtY uc1uazISY58QixwwLMZh65uRWNlLxNM= From: Juergen Gross To: xen-devel@lists.xenproject.org Cc: Juergen Gross , Andrew Cooper , George Dunlap , Jan Beulich , Julien Grall , Stefano Stabellini , Wei Liu Subject: [PATCH] MAINTAINERS: add an entry for tools/9pfsd Date: Wed, 6 Mar 2024 12:16:31 +0100 Message-Id: <20240306111631.1696-1-jgross@suse.com> X-Mailer: git-send-email 2.35.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Authentication-Results: smtp-out1.suse.de; none X-Spamd-Result: default: False [4.90 / 50.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_MISSING_CHARSET(2.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; BROKEN_CONTENT_TYPE(1.50)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; RCPT_COUNT_SEVEN(0.00)[8]; MID_CONTAINS_FROM(1.00)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:email,citrix.com:email]; FUZZY_BLOCKED(0.00)[rspamd.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_ALL(0.00)[]; BAYES_HAM(-0.00)[31.20%] X-Spam-Level: **** X-Spam-Score: 4.90 X-Spam-Flag: NO Add me as the maintainer for the tools/9pfsd directory. Signed-off-by: Juergen Gross --- MAINTAINERS | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 076cf1e141..28fb35582b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -206,6 +206,12 @@ Maintainers List (try to look for most precise areas first) ----------------------------------- +9PFSD +M: Juergen Gross +M: Anthony PERARD +S: Supported +F: tools/9pfsd + ACPI M: Jan Beulich S: Supported -- 2.35.3 From xen-devel-bounces@lists.xenproject.org Wed Mar 06 11:17:46 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 11:17:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689065.1073999 (Exim 4.92) (envelope-from ) id 1rhpHN-0003aK-5v; Wed, 06 Mar 2024 11:17:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689065.1073999; Wed, 06 Mar 2024 11:17:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhpHN-0003aD-2r; Wed, 06 Mar 2024 11:17:45 +0000 Received: by outflank-mailman (input) for mailman id 689065; Wed, 06 Mar 2024 11:17:43 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhpHL-0003a3-AX for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 11:17:43 +0000 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 2635f582-dbab-11ee-afda-a90da7624cb6; Wed, 06 Mar 2024 12:17:42 +0100 (CET) Received: from imap2.dmz-prg2.suse.org (imap2.dmz-prg2.suse.org [10.150.64.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id BEDA93FF72; Wed, 6 Mar 2024 11:17:40 +0000 (UTC) Received: from imap2.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap2.dmz-prg2.suse.org (Postfix) with ESMTPS id 8A0E313A79; Wed, 6 Mar 2024 11:17:40 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap2.dmz-prg2.suse.org with ESMTPSA id gYI3INRQ6GXWPgAAn2gu4w (envelope-from ); Wed, 06 Mar 2024 11:17:40 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 2635f582-dbab-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1709723861; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=xHuzMuZf+SGDKE+y7OBsn8gOryBcsmiQazYM2WVKUKU=; b=oHzdocecuCQVCbXDXOOP4kKr8FYWoolfhx7I6R54gf0k6/0Rt/pVjr8lDxCHcUNHk3VLri j4d6YRYrIdC+emb11X/4iKm1gpnrn6Uc/qKaBNFBQj+veBhX3G0YjDltsUGe6J3uhCeEA8 WjswL1+KTWcOUy7hddZ9wj+edfyA+Yo= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1709723860; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=xHuzMuZf+SGDKE+y7OBsn8gOryBcsmiQazYM2WVKUKU=; b=Dpu5oaEpSobEY5HjoM3vaZXLdVFaM0nbUGhcGNLVDm+eTDkXyeAPzg+Hk47VaubkIxre/v JJscGTthqXDvQjrVAj97aiujVaeavkTt1mE5C4FcqDm6Akpb0cF+6xpSqvfCtiwZiWUtmi s2TyxO3hDZIPbPYluha/iM7VXm1taUE= From: Juergen Gross To: xen-devel@lists.xenproject.org Cc: Juergen Gross , Oleksii Kurochko , Community Manager Subject: [PATCH] CHANGELOG: add an entry for 9pfsd Date: Wed, 6 Mar 2024 12:17:38 +0100 Message-Id: <20240306111738.1815-1-jgross@suse.com> X-Mailer: git-send-email 2.35.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Authentication-Results: smtp-out1.suse.de; none X-Spamd-Result: default: False [6.40 / 50.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; BAYES_HAM(-0.00)[20.95%]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; FREEMAIL_ENVRCPT(0.00)[gmail.com]; R_MISSING_CHARSET(2.50)[]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; BROKEN_CONTENT_TYPE(1.50)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; MID_CONTAINS_FROM(1.00)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[keepachangelog.com:url,suse.com:email,changelog.md:url]; FUZZY_BLOCKED(0.00)[rspamd.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_CC(0.00)[suse.com,gmail.com,xenproject.org]; RCVD_TLS_ALL(0.00)[]; SUSPICIOUS_RECIPS(1.50)[] X-Spam-Level: ****** X-Spam-Score: 6.40 X-Spam-Flag: NO Add an entry to CHANGELOG.md regarding the new xen-9pfsd daemon. Signed-off-by: Juergen Gross --- CHANGELOG.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index f9874f9bb0..93fda73c00 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -18,6 +18,8 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/) - On x86: - Introduce a new x2APIC driver that uses Cluster Logical addressing mode for IPIs and Physical addressing mode for external interrupts. + - Add a new 9pfs backend running as a daemon in dom0. First user is + Xenstore-stubdom now being able to support full Xenstore trace capability. ### Removed - caml-stubdom. It hasn't built since 2014, was pinned to Ocaml 4.02, and has -- 2.35.3 From xen-devel-bounces@lists.xenproject.org Wed Mar 06 11:23:40 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 11:23:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689070.1074010 (Exim 4.92) (envelope-from ) id 1rhpN1-0005rv-QB; Wed, 06 Mar 2024 11:23:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689070.1074010; Wed, 06 Mar 2024 11:23:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhpN1-0005ro-NF; Wed, 06 Mar 2024 11:23:35 +0000 Received: by outflank-mailman (input) for mailman id 689070; Wed, 06 Mar 2024 11:23:35 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhpN1-0005ri-AG for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 11:23:35 +0000 Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [2a00:1450:4864:20::52e]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id f804ad58-dbab-11ee-afda-a90da7624cb6; Wed, 06 Mar 2024 12:23:34 +0100 (CET) Received: by mail-ed1-x52e.google.com with SMTP id 4fb4d7f45d1cf-56682b85220so10672608a12.1 for ; Wed, 06 Mar 2024 03:23:34 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id v19-20020aa7dbd3000000b0056761c83bdesm2891297edt.93.2024.03.06.03.23.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 Mar 2024 03:23:33 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f804ad58-dbab-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709724214; x=1710329014; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=xdPVuAV/bnXM4zPS4UOW1zskdaUODxvqiUt5UKkCVJw=; b=DG343bFdoMhogQcIgDGSdGfy1q+4hbRiQATmdcd5QxbIPx+7QimUJ4iQ8bMKS8Z8w1 XeR8NVMme0T/pfCnxGDybn3CmGL/vFPymbq8Zcn/5f9k0U5fEgkr8Tp+SRBtWUEeAqC+ 0Kv0KZPAid4Zhf9eR21rDgiiRF+WNLdPPATN5k5jOEz4ezAWZ+umcTlkTtxmp+N1sUjy WsGNfyJwqFe3GTPWkYLKVrc1UlJG7yD0kdJvedJ3Pt3T+EL0by8dBwqKjFkqHFY0EoK6 qaafOMx+Ukxcnn9NEW/0biFIcH3KphUxfVjZu07Nrq9tI7eR8rt8M7VCo43v8LYPksx9 4dGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709724214; x=1710329014; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=xdPVuAV/bnXM4zPS4UOW1zskdaUODxvqiUt5UKkCVJw=; b=JNXcsf6ka19AJnYn1sS0YgwTl6fRbZI1scOEi3rbf0VK3av3tt43TqT/jMWBUOd8lA IBDPE8jqXkCX5D5vsVlLRtrb7yLLqc/AkVbBtCnGxLg4u50rSa5Zq+Pg6lh2ekFGxdnF /3cJ5RltIQrX1z9g1586bYggs4qgCkQua+yPcg8ymJBAFJ89alk2bBvHY/tB1CEO8HW4 PA+LDStvBkT+eq/jcEAzjv0rLi+632+0fojTpL/gKseSToj2z4bhmqQMrRKQQuLk2E+c o1yt3Nl4tmDKGqpQXDBnkpKrPo+neQWTFKgex+b9dBhl2IEw5++beJr3B+u/hC4Jy1B3 nnmA== X-Forwarded-Encrypted: i=1; AJvYcCWfE2lGTgpaMIFpR3YPY1mEAuPf+IGZ3dDuufpmDF0oe9qzPTvnXf1xV+ZIhHESlPdb2Elh2zKPRMsAr/xU73DlQ2NVFHnY4/SbTOsYkF0= X-Gm-Message-State: AOJu0YwJzoqCNxTrw61mfMa3e6WXcL1K1OcektEl9tOmfx6vOOu84OA6 J+rdGbOJVO6adVqbTJ4papjQjbLL+BMHKyXkf7zyS3sEwKxCO4BHLV1UYawdyQ== X-Google-Smtp-Source: AGHT+IHfolM8TWg8b9BATTlJNhOWWx/VDw+QDtXGfY2NcezgTx662VcxdzeSCQFIRZtcRa3t+HVD6Q== X-Received: by 2002:a50:cc4d:0:b0:566:418d:7ba9 with SMTP id n13-20020a50cc4d000000b00566418d7ba9mr9185606edi.1.1709724213743; Wed, 06 Mar 2024 03:23:33 -0800 (PST) Message-ID: <56270f54-d86d-4849-9964-ae94318215b8@suse.com> Date: Wed, 6 Mar 2024 12:23:32 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] MAINTAINERS: add an entry for tools/9pfsd Content-Language: en-US To: Juergen Gross Cc: Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu , xen-devel@lists.xenproject.org References: <20240306111631.1696-1-jgross@suse.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20240306111631.1696-1-jgross@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 06.03.2024 12:16, Juergen Gross wrote: > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -206,6 +206,12 @@ Maintainers List (try to look for most precise areas first) > > ----------------------------------- > > +9PFSD > +M: Juergen Gross > +M: Anthony PERARD > +S: Supported > +F: tools/9pfsd This wants a trailing slash. Can pretty certainly be taken care of while committing. Jan From xen-devel-bounces@lists.xenproject.org Wed Mar 06 11:25:44 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 11:25:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689072.1074020 (Exim 4.92) (envelope-from ) id 1rhpP4-0006PF-4Y; Wed, 06 Mar 2024 11:25:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689072.1074020; Wed, 06 Mar 2024 11:25:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhpP4-0006P8-1Z; Wed, 06 Mar 2024 11:25:42 +0000 Received: by outflank-mailman (input) for mailman id 689072; Wed, 06 Mar 2024 11:25:41 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhpP3-0006P2-FE for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 11:25:41 +0000 Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [2a00:1450:4864:20::630]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 431d76d4-dbac-11ee-afda-a90da7624cb6; Wed, 06 Mar 2024 12:25:40 +0100 (CET) Received: by mail-ej1-x630.google.com with SMTP id a640c23a62f3a-a458eb7db13so112713066b.2 for ; Wed, 06 Mar 2024 03:25:40 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id w18-20020a17090652d200b00a4320e22b31sm7133679ejn.19.2024.03.06.03.25.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 Mar 2024 03:25:39 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 431d76d4-dbac-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709724340; x=1710329140; darn=lists.xenproject.org; h=content-transfer-encoding:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to; bh=Zf1Waj0LmMTyGt1GCCI2TdwHJ4hgHS02iTcHBtw6WHI=; b=cQ6yZitXcL3xBrbQ8v6Q42vDmTs4jH7liqCk4I8asmb1LfEqrL8vcE0gs7OWaXoN4r ZXBOesdFyRcMcy5swqEtCyAmbcu3RWzOXi/DGaiPHlViQrUVU+MU2zvsb+vHxFQrlv/h PUG5rIOhM/ujQcYr0yzasujHeF4E0GSrIh/9VcwLAlqfpUwBaTay50xSo65b55fnpB5D mhjZOa3rSfjcsz0xSG5huKqXOdqruI6VpFTJ1soIkY9xPpguOxFXgiAyBnU9dvaP7Wq6 F7/eY+1QgPpgEnI5gjClAbw54mlySJ41Non9mp/5DA145WtFgHKt6XVvR+zgC8JJ7aeT 026g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709724340; x=1710329140; h=content-transfer-encoding:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Zf1Waj0LmMTyGt1GCCI2TdwHJ4hgHS02iTcHBtw6WHI=; b=Nr8Jr+5slZTgN5cJjxPCNDTLPqfvw+4AtaSvmnde0LkQ+WbVP1EXUglyPIx0cWRF1L bs9GkR5BPF9u6eTjOLE5247h5IUopXQ9PYYTAOQ0RG+5hM/AE8lKXUXts94n+YlfEvPf yzIP5UTpOYTw5CKudjJHNXenbYD8riAUDaOOikSLp5NRTAHTObhkFNQw0P1WHzwTq3Eg Si1QwJqjce5e5dGWyYL07NMd2LIxvSO9cR75RPIjr3+1jUiwSyOPmhMcdF6+hKsMOAd8 jVWmi10ZfbP6+xK9PdwayJlZCtjgxcc1zl+vwAByZ0XN+MVX3s2Gy3V/fQT7xfmLPsD6 ITMA== X-Gm-Message-State: AOJu0YxuimFflQnWWJzjl7vg9Ce+lACqy+hlY4m0lK1pGwqfXMEXLWtZ 7srf4AVnOoNzFPn8j78wSYZQtCCZWxpXPJUYLlvvnfZPX7+/NoC5wtf/KGV0sIT6iquWngewa5A = X-Google-Smtp-Source: AGHT+IGnq28vUHn7hfcJEwujD1i++7PEuHNcqlOqt4hlZwl7YHrIF391IHGucqa2DimvaeRVfl6gyw== X-Received: by 2002:a17:906:ae56:b0:a45:46e0:be9a with SMTP id lf22-20020a170906ae5600b00a4546e0be9amr5779447ejb.35.1709724339792; Wed, 06 Mar 2024 03:25:39 -0800 (PST) Message-ID: Date: Wed, 6 Mar 2024 12:25:38 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= From: Jan Beulich Subject: [PATCH] x86/asm: add commas to further macros definitions/invocations Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit In light of recent observations with how macros are handled by gas, let's play by what we informally set for ourselves as a guideline: Use commas to separate parameters/arguments. Requested-by: Andrew Cooper Signed-off-by: Jan Beulich --- In INDIRECT_{CALL,JMP} adding commas to the arguments passed on makes things look a little odd (for no longer looking similar to ordinary use of instruction mnemonics + operands). Thoughts on omitting the commas there? --- a/xen/arch/x86/include/asm/alternative-asm.h +++ b/xen/arch/x86/include/asm/alternative-asm.h @@ -11,7 +11,7 @@ * enough information for the alternatives patching code to patch an * instruction. See apply_alternatives(). */ -.macro altinstruction_entry orig repl feature orig_len repl_len pad_len +.macro altinstruction_entry orig, repl, feature, orig_len, repl_len, pad_len .long \orig - . .long \repl - . .word \feature --- a/xen/arch/x86/include/asm/asm-defns.h +++ b/xen/arch/x86/include/asm/asm-defns.h @@ -29,7 +29,7 @@ BUG /* Shouldn't return */ .endm -.macro INDIRECT_BRANCH insn:req arg:req +.macro INDIRECT_BRANCH insn:req, arg:req /* * Create an indirect branch. insn is one of call/jmp, arg is a single * register. @@ -59,11 +59,11 @@ /* Convenience wrappers. */ .macro INDIRECT_CALL arg:req - INDIRECT_BRANCH call \arg + INDIRECT_BRANCH call, \arg .endm .macro INDIRECT_JMP arg:req - INDIRECT_BRANCH jmp \arg + INDIRECT_BRANCH jmp, \arg .endm #ifdef CONFIG_XEN_IBT --- a/xen/arch/x86/include/asm/asm_defns.h +++ b/xen/arch/x86/include/asm/asm_defns.h @@ -281,7 +281,7 @@ static always_inline void stac(void) * @compat: R8-R15 don't need reloading, but they are clobbered for added * safety against information leaks. */ -.macro RESTORE_ALL adj=0 compat=0 +.macro RESTORE_ALL adj=0, compat=0 .if !\compat movq UREGS_r15(%rsp), %r15 movq UREGS_r14(%rsp), %r14 --- a/xen/arch/x86/include/asm/spec_ctrl_asm.h +++ b/xen/arch/x86/include/asm/spec_ctrl_asm.h @@ -104,7 +104,7 @@ .L\@_done: .endm -.macro DO_OVERWRITE_RSB tmp=rax xu +.macro DO_OVERWRITE_RSB tmp=rax, xu /* * Requires nothing * Clobbers \tmp (%rax by default), %rcx --- a/xen/arch/x86/x86_64/compat/entry.S +++ b/xen/arch/x86/x86_64/compat/entry.S @@ -158,7 +158,7 @@ FUNC(compat_restore_all_guest) /* WARNING! `ret`, `call *`, `jmp *` not safe beyond this point. */ SPEC_CTRL_EXIT_TO_PV /* Req: a=spec_ctrl %rsp=regs/cpuinfo, Clob: cd */ - RESTORE_ALL adj=8 compat=1 + RESTORE_ALL adj=8, compat=1 .Lft0: iretq _ASM_PRE_EXTABLE(.Lft0, handle_exception) END(compat_restore_all_guest) From xen-devel-bounces@lists.xenproject.org Wed Mar 06 11:27:43 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 11:27:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689077.1074029 (Exim 4.92) (envelope-from ) id 1rhpR0-0006wX-Fo; Wed, 06 Mar 2024 11:27:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689077.1074029; Wed, 06 Mar 2024 11:27:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhpR0-0006wQ-DF; Wed, 06 Mar 2024 11:27:42 +0000 Received: by outflank-mailman (input) for mailman id 689077; Wed, 06 Mar 2024 11:27:41 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhpQz-0006wK-Cx for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 11:27:41 +0000 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 89ff522e-dbac-11ee-a1ee-f123f15fe8a2; Wed, 06 Mar 2024 12:27:39 +0100 (CET) Received: from imap2.dmz-prg2.suse.org (imap2.dmz-prg2.suse.org [10.150.64.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id B994268904; Wed, 6 Mar 2024 11:27:38 +0000 (UTC) Received: from imap2.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap2.dmz-prg2.suse.org (Postfix) with ESMTPS id 6A66513A79; Wed, 6 Mar 2024 11:27:38 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap2.dmz-prg2.suse.org with ESMTPSA id p213GCpT6GXYQAAAn2gu4w (envelope-from ); Wed, 06 Mar 2024 11:27:38 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 89ff522e-dbac-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1709724458; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=2tOUi2pLz/KlGD5TleWt7y59TdOBtrIZ9jq3gi4MeVc=; b=pIptgjxxz/NnxZ8pRCxuuzy8so1oZCfimeSzYbLfw6xs+dnGpPVezMVbsjoCYzI8h7LtDn cY8kEqANnDI+BeW6oDqVgU6N9Vmr64zQaQRpSkJevtjrWhVf4dP0XlYOAxHL7DtmZpLwzu udjudf/zdX6ejcdiEH2eSyaaddbsf6g= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1709724458; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=2tOUi2pLz/KlGD5TleWt7y59TdOBtrIZ9jq3gi4MeVc=; b=pIptgjxxz/NnxZ8pRCxuuzy8so1oZCfimeSzYbLfw6xs+dnGpPVezMVbsjoCYzI8h7LtDn cY8kEqANnDI+BeW6oDqVgU6N9Vmr64zQaQRpSkJevtjrWhVf4dP0XlYOAxHL7DtmZpLwzu udjudf/zdX6ejcdiEH2eSyaaddbsf6g= From: Juergen Gross To: xen-devel@lists.xenproject.org Cc: Juergen Gross , Andrew Cooper , George Dunlap , Jan Beulich , Julien Grall , Stefano Stabellini , Wei Liu Subject: [PATCH] SUPPORT.md: add xen-9pfsd Date: Wed, 6 Mar 2024 12:27:36 +0100 Message-Id: <20240306112736.2546-1-jgross@suse.com> X-Mailer: git-send-email 2.35.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Authentication-Results: smtp-out2.suse.de; none X-Spamd-Result: default: False [4.90 / 50.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_MISSING_CHARSET(2.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; BROKEN_CONTENT_TYPE(1.50)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; RCPT_COUNT_SEVEN(0.00)[8]; MID_CONTAINS_FROM(1.00)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:email]; FUZZY_BLOCKED(0.00)[rspamd.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_ALL(0.00)[]; BAYES_HAM(-0.00)[39.12%] X-Spam-Level: **** X-Spam-Score: 4.90 X-Spam-Flag: NO Add a support statement for the new xen-9pfsd backend. Set it to "Experimental", as some functionality for Linux guests is missing (only tested to work with Xenstore-stubdom). Signed-off-by: Juergen Gross --- SUPPORT.md | 1 + 1 file changed, 1 insertion(+) diff --git a/SUPPORT.md b/SUPPORT.md index a90d1108c9..8d21bc7945 100644 --- a/SUPPORT.md +++ b/SUPPORT.md @@ -664,6 +664,7 @@ there is currently no xl support. ### PV 9pfs (backend) Status, QEMU: Tech Preview + Status, xen-9pfsd: Experimental ### PVCalls (backend) -- 2.35.3 From xen-devel-bounces@lists.xenproject.org Wed Mar 06 11:28:29 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 11:28:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689079.1074040 (Exim 4.92) (envelope-from ) id 1rhpRk-0007T3-O9; Wed, 06 Mar 2024 11:28:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689079.1074040; Wed, 06 Mar 2024 11:28:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhpRk-0007Sw-LA; Wed, 06 Mar 2024 11:28:28 +0000 Received: by outflank-mailman (input) for mailman id 689079; Wed, 06 Mar 2024 11:28:27 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhpRj-0007Sk-QN for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 11:28:27 +0000 Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [2607:f8b0:4864:20::432]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id a5fa7486-dbac-11ee-afda-a90da7624cb6; Wed, 06 Mar 2024 12:28:27 +0100 (CET) Received: by mail-pf1-x432.google.com with SMTP id d2e1a72fcca58-6e649a2548cso722957b3a.3 for ; Wed, 06 Mar 2024 03:28:26 -0800 (PST) Received: from [10.80.67.149] (default-46-102-197-194.interdsl.co.uk. [46.102.197.194]) by smtp.gmail.com with ESMTPSA id o26-20020a056a001b5a00b006e4766d31bcsm10576344pfv.184.2024.03.06.03.28.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 Mar 2024 03:28:20 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a5fa7486-dbac-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709724505; x=1710329305; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=521epUU343fws/n3Qt/F/VfXYETfAXYIbBJqL9uNFAQ=; b=vj/fxu84u3liW+k173l829RoOwrAclTYpq2DJ3wmlxGh/uAu8bPpEWOavSIz+cOvCd zlA2TEiXzzvUWcZuVQKCw+HyzD/kokK1vJ7liRW3EoObTNWIW2CXy0Iwg6aA649YWRcH EVD8eIE16C9ASJQOQq+CZcNbv5Meimq3kAc0Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709724505; x=1710329305; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=521epUU343fws/n3Qt/F/VfXYETfAXYIbBJqL9uNFAQ=; b=xSm6IUdmEC2Cx15JFZ2qPVRgO8DthdEZ0QvxuwS3Ufc/n8w2z5HHfsPMMnu57vwVfo t4NYD4I3KnLPkBh31szK3AmIORB3wxoUr9QrQhNUXKXchx6nDxmb8KQBXW5qGfl3UOF1 LCzCco8F+tovu/MvG4pd/NOJYfaqoUWzuRxYmuaoYe7nbYc/0+bjyrfBqfj1bT3UoaJJ 4kYbVEKivrrQxDrKfruYzVwCdvhBxu4kUbLKy/JbtXj9NWn1v+9YylljWqdp6KNG3qvw 2wdkf9sI/Tn7PEZXvBEi4WQ8gxCkYcX0avDokuQeA2SmTU8I+L8o8D/5bZfgast49VOf qscg== X-Forwarded-Encrypted: i=1; AJvYcCVeJQ61pDl03/v8+tcXyneJOjtyYw8aAmgX4H13qDCnjbp8C3D1TEIUgUz5nOlijQXAAA8IG2Ol9FUY/QigyF1EYHQFyNV81kGDWI2natU= X-Gm-Message-State: AOJu0YxZCOqiX8urpDD2QnFRsn9szZF0k6gTQJ3nycXrPRBB6/XSALJx EWPshY5gIzhZp3lVPETTGf48hLhMlkLlmZMQdholqPHz+138PG8bZOku1OZ3XmE= X-Google-Smtp-Source: AGHT+IGLPj1fn+uorrr/C3YCghvXNhNpU00FrCR5m1uZcx+SPa6WhTfekH9n6dkUzRslxJcl5U3ToA== X-Received: by 2002:a05:6a00:2da8:b0:6e3:caa7:3038 with SMTP id fb40-20020a056a002da800b006e3caa73038mr18655049pfb.0.1709724504659; Wed, 06 Mar 2024 03:28:24 -0800 (PST) Message-ID: <89819348-2d62-40db-a998-0174290b2cc2@citrix.com> Date: Wed, 6 Mar 2024 11:28:17 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/asm: add commas to further macros definitions/invocations Content-Language: en-GB To: Jan Beulich , "xen-devel@lists.xenproject.org" Cc: Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 06/03/2024 11:25 am, Jan Beulich wrote: > In light of recent observations with how macros are handled by gas, > let's play by what we informally set for ourselves as a guideline: Use > commas to separate parameters/arguments. > > Requested-by: Andrew Cooper > Signed-off-by: Jan Beulich > --- > In INDIRECT_{CALL,JMP} adding commas to the arguments passed on makes > things look a little odd (for no longer looking similar to ordinary use > of instruction mnemonics + operands). Thoughts on omitting the commas > there? I'd prefer to go for consistency. Acked-by: Andrew Cooper From xen-devel-bounces@lists.xenproject.org Wed Mar 06 11:34:00 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 11:34:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689088.1074049 (Exim 4.92) (envelope-from ) id 1rhpX1-0001d8-FJ; Wed, 06 Mar 2024 11:33:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689088.1074049; Wed, 06 Mar 2024 11:33:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhpX1-0001d1-Cq; Wed, 06 Mar 2024 11:33:55 +0000 Received: by outflank-mailman (input) for mailman id 689088; Wed, 06 Mar 2024 11:33:53 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhpWz-0001cv-Iz for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 11:33:53 +0000 Received: from smtp-out2.suse.de (smtp-out2.suse.de [2a07:de40:b251:101:10:150:64:2]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 682c4665-dbad-11ee-afda-a90da7624cb6; Wed, 06 Mar 2024 12:33:52 +0100 (CET) Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 61B4268827; Wed, 6 Mar 2024 11:33:51 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 2598113A65; Wed, 6 Mar 2024 11:33:51 +0000 (UTC) Received: from dovecot-director2.suse.de ([10.150.64.162]) by imap1.dmz-prg2.suse.org with ESMTPSA id 15YzB59U6GWLFQAAD6G6ig (envelope-from ); Wed, 06 Mar 2024 11:33:51 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 682c4665-dbad-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1709724831; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=XWos/1lXlyQ7RHkskDWY40b7ic1MXb23n+nmckfVvzc=; b=hZSo0j89l3YvJ9zafpn9TehqNr133tdMWz2GWRiq+HNpQW4P6WnWAbRLldxvmlO6J/AbsO wdWLXPuXPcY1CKWc434Ki/G5rrHtviK0D1adRhw6wX4LFDweBBpsUGxX8XtZk2Ejw6P6G8 qfqNKyTDLFILMNsEy4r9nSfhYqKHWi0= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1709724831; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=XWos/1lXlyQ7RHkskDWY40b7ic1MXb23n+nmckfVvzc=; b=hZSo0j89l3YvJ9zafpn9TehqNr133tdMWz2GWRiq+HNpQW4P6WnWAbRLldxvmlO6J/AbsO wdWLXPuXPcY1CKWc434Ki/G5rrHtviK0D1adRhw6wX4LFDweBBpsUGxX8XtZk2Ejw6P6G8 qfqNKyTDLFILMNsEy4r9nSfhYqKHWi0= Message-ID: Date: Wed, 6 Mar 2024 12:33:50 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] MAINTAINERS: add an entry for tools/9pfsd Content-Language: en-US To: Jan Beulich Cc: Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu , xen-devel@lists.xenproject.org References: <20240306111631.1696-1-jgross@suse.com> <56270f54-d86d-4849-9964-ae94318215b8@suse.com> From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= In-Reply-To: <56270f54-d86d-4849-9964-ae94318215b8@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: smtp-out2.suse.de; none X-Spam-Level: X-Spam-Score: -3.13 X-Spamd-Result: default: False [-3.13 / 50.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; XM_UA_NO_VERSION(0.01)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; BAYES_HAM(-2.75)[98.93%]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; NEURAL_HAM_SHORT(-0.20)[-0.999]; RCPT_COUNT_SEVEN(0.00)[7]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:email,citrix.com:email]; FUZZY_BLOCKED(0.00)[rspamd.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; R_MIXED_CHARSET(0.91)[subject]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Spam-Flag: NO On 06.03.24 12:23, Jan Beulich wrote: > On 06.03.2024 12:16, Juergen Gross wrote: >> --- a/MAINTAINERS >> +++ b/MAINTAINERS >> @@ -206,6 +206,12 @@ Maintainers List (try to look for most precise areas first) >> >> ----------------------------------- >> >> +9PFSD >> +M: Juergen Gross >> +M: Anthony PERARD >> +S: Supported >> +F: tools/9pfsd > > This wants a trailing slash. Oh, indeed. > Can pretty certainly be taken care of while committing. Thanks, Juergen From xen-devel-bounces@lists.xenproject.org Wed Mar 06 11:34:12 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 11:34:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689089.1074059 (Exim 4.92) (envelope-from ) id 1rhpXI-00022k-Mw; Wed, 06 Mar 2024 11:34:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689089.1074059; Wed, 06 Mar 2024 11:34:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhpXI-00022d-KO; Wed, 06 Mar 2024 11:34:12 +0000 Received: by outflank-mailman (input) for mailman id 689089; Wed, 06 Mar 2024 11:34:12 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhpXI-0001zq-8B for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 11:34:12 +0000 Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [2a00:1450:4864:20::631]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 72eb2168-dbad-11ee-a1ee-f123f15fe8a2; Wed, 06 Mar 2024 12:34:10 +0100 (CET) Received: by mail-ej1-x631.google.com with SMTP id a640c23a62f3a-a456ab934eeso102439266b.0 for ; Wed, 06 Mar 2024 03:34:10 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id h5-20020a1709062dc500b00a45beb1c671sm416534eji.13.2024.03.06.03.34.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 Mar 2024 03:34:09 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 72eb2168-dbad-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709724849; x=1710329649; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=dNS0gCLcootkBbIZxm+AA/f3JUpLYF19paH20sxMMq4=; b=Yw0xXKEYY9FBY9LMoWb2sIabhjHRIRSrpK5EEzGHt9mivq+vnG8BvkaEqFrdlB3Rn7 eb6loRGvHxkFN3E8gWA3PuZgb37Py01hlIPbJxnwRVRWR2Iq76wa8g7hIDxCU9giBowT ze62zn3tDFWVpqYjGLcZ9JSlQSCIe1sQaiD1M36kcjbjBSX+s7jfA35CK3TL5816JzBY EpABC4Hm+PIgiQbGts4AEHEIrxzg7sCXevdjcXv2XgVnTbdpVKLvm3+oUyzGsIU4LTCn CzCGbHTDEkXDLnC00kFSEtSN13PrXT1B4Fhw3CrGtef1pOiocdagxCmWFy2R0ypY3+oB XKig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709724849; x=1710329649; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=dNS0gCLcootkBbIZxm+AA/f3JUpLYF19paH20sxMMq4=; b=WwVBljDUhfMTriAHQIt04/MPFFsk7DE0lkcgye+/0rwPw8CKszzZn0Mtlg+jdmPy79 sG0MbkL4a3DD+ZdYMwgC5CsFeaVwVvXl5behwtE4cj2/91d4UY/+Y5L8LXBRNyG/ETl2 JHLMXWEvsgb5pG9MijFCP5tKLsEmR0tjDI4mC1EkzFJ8mSfK1v5wb1pzUrwo1XVP0JPy D0/xfBF0M6xsra73uZbFrYwQjm3xzhWf1C5RXyTNVuelFKuLZi70Bx4i5bPIlMPsnqHo iYkFx7oXQPvJPMYBBrCC/QOAkS661vsqzfg3SDmtjj071E64SgL52aGkSGbXtIB9eR1w DD9Q== X-Forwarded-Encrypted: i=1; AJvYcCUqv0K/LWIScw1x1MOogU+Csmne236k/SrjX8ybviHo7zEOLMtTQ9jLttgYx9AYNKlBM+mU65eBqEQuWPHzNE6pHXORP8yUOcMNypjHKzI= X-Gm-Message-State: AOJu0YzOKQYUMY3LBJubvGgg81l4XwTXQT2Eewzoyv9xkJbfCR+68qX/ YBScG5OJQwVWyV8TqMoYj1SzfTALM88SM3qfVhNMl4LqwbR8bdormgONWAYYJg== X-Google-Smtp-Source: AGHT+IHJ2eRNl2iKwCCxtsP61JUNxJ9mSoja+Kto8uOBjqx6nHeBQ5v6xNo2JPwqdBLXXqXSS8vViA== X-Received: by 2002:a17:906:6b10:b0:a45:9e62:ff54 with SMTP id q16-20020a1709066b1000b00a459e62ff54mr4045071ejr.46.1709724849430; Wed, 06 Mar 2024 03:34:09 -0800 (PST) Message-ID: Date: Wed, 6 Mar 2024 12:34:08 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] SUPPORT.md: add xen-9pfsd Content-Language: en-US To: Juergen Gross Cc: Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu , xen-devel@lists.xenproject.org References: <20240306112736.2546-1-jgross@suse.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20240306112736.2546-1-jgross@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 06.03.2024 12:27, Juergen Gross wrote: > Add a support statement for the new xen-9pfsd backend. Set it to > "Experimental", as some functionality for Linux guests is missing > (only tested to work with Xenstore-stubdom). > > Signed-off-by: Juergen Gross Acked-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Wed Mar 06 11:48:59 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 11:48:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689094.1074070 (Exim 4.92) (envelope-from ) id 1rhplV-0004ki-V2; Wed, 06 Mar 2024 11:48:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689094.1074070; Wed, 06 Mar 2024 11:48:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhplV-0004kb-SI; Wed, 06 Mar 2024 11:48:53 +0000 Received: by outflank-mailman (input) for mailman id 689094; Wed, 06 Mar 2024 11:48:52 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhplU-0004kT-OM for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 11:48:52 +0000 Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [2a00:1450:4864:20::52b]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 8068285b-dbaf-11ee-afda-a90da7624cb6; Wed, 06 Mar 2024 12:48:51 +0100 (CET) Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-56781070f38so1309012a12.0 for ; Wed, 06 Mar 2024 03:48:51 -0800 (PST) Received: from localhost.localdomain ([217.156.233.157]) by smtp.gmail.com with ESMTPSA id y6-20020a056402358600b005645961ad39sm6764400edc.47.2024.03.06.03.48.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Mar 2024 03:48:50 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8068285b-dbaf-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709725731; x=1710330531; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=np/f+KMAe5bM0QmR4knfzGRTCYdocIjIi5uetrq305w=; b=NUSh7FTB7d4EBBAYF0MSnpxHObL7QqNC4uIz7k9473zhnr4mNFugl7smf8kMWwBtVZ 5ckxpeno/5hlVNEfWFxf7skQ09IVMa3qFw6Zz59Mkx6tNjAsknoHXkscgiHnxGaOcP5L k4CjFH9AkldB2lvjthM+aNBnC40mIpv20q7qQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709725731; x=1710330531; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=np/f+KMAe5bM0QmR4knfzGRTCYdocIjIi5uetrq305w=; b=YJ1oULhhglD2B89m7xToNRmW+1XvrlaUGIKRL9a19zIPH6WaLFr4e9qP6InLjSEI8E gqCwnhLflqK6l51OJYt52/ogTBqj+aCvDStCAkVIcHuzlwi/46uu7bBe5k78FZCZZDof pnRfRuLGCFZMI5MP8c4ShADjIqT0pJbRV6lRkPEiblIsRRJh92u9piHoomhJ9NXgi54b Hl5jG5ld93SgsEidYBt9K+5LXSF+e7OaidM4gtaXwdCi86UW1ZLcjlRAO6eIkrjnq8Mp ms5cV5MJQJM2uWw5MdguPrGQmnIgEUwDcRDjZxvs+PQsz4aIYJA3KtHmOXmvtv1zflMg GBEg== X-Gm-Message-State: AOJu0Ywe6x/sWpmZTJd3lhQ76JhMgaAuqMBThW/ITUFdPTY+jpeqfXTu x+naSVhrbuPkjvG+LWx0ZhlDJ9rDlqGXTbh6ZQVQeAQd9avoP2lBxIDoOPajTB21kxv7drJQbqJ N X-Google-Smtp-Source: AGHT+IELCUNgE3HJxQg2M7mLQt4Z59m1BOk6kt3fV2Eh1Y7sm4SrtzE7To059GhDwRc5pkYQAzfiaA== X-Received: by 2002:a17:906:e252:b0:a45:8b1d:696 with SMTP id gq18-20020a170906e25200b00a458b1d0696mr6079328ejb.8.1709725731002; Wed, 06 Mar 2024 03:48:51 -0800 (PST) From: Anthony PERARD To: xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , Juergen Gross , Roger Pau Monne Subject: [OSSTEST PATCH] ap-common: Switch to Linux 6.1 by default on x86 + drop dom0 i386 Date: Wed, 6 Mar 2024 11:47:41 +0000 Message-Id: <20240306114741.14564-1-anthony.perard@citrix.com> X-Mailer: git-send-email 2.39.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit linux-4.19 branch in xenbits is outdated, it haven't been updated and tested since 2020 as it has been disabled in osstest. Also, this 4.19 branch doesn't build on Bookworm. So we will start to use a newer version of Linux. We switch to 6.1 for the Arm* tests recently, so will use that same version for x86. Also, following commit 3a3089c94913 ("mfi-common: Drop Linux dom0 i386 tests for newer Linux branches"), 32bit dom0 isn't tested on newer Linux, so we need to drop all dom0 i386 tests wherever the default linux branch is used. That is, this changes in jobs will apply to "xen-unstable" branch but also all xen stable branches, seabios, qemu, osstest, libvirt, so every branch that aren't "linux-*". Here is the list jobs that changes, and whether they are replace, or have existing equivalents, on the "xen-unstable" branch. Changes compared with: OSSTEST_CONFIG=standalone-config-example nice eatmydata ./standalone-generate-dump-flight-runvars Gone, without exiting or new test-amd64-amd64-*: - test-amd64-i386-freebsd10-amd64 - test-amd64-i386-freebsd10-i386 - test-amd64-i386-qemut-rhel6hvm-amd - test-amd64-i386-qemut-rhel6hvm-intel - test-amd64-i386-qemuu-rhel6hvm-amd - test-amd64-i386-qemuu-rhel6hvm-intel Gone, but with exiting test-amd64-amd64-* equivalent: - test-amd64-coresched-i386-xl - test-amd64-i386-examine - test-amd64-i386-examine-bios - test-amd64-i386-examine-uefi - test-amd64-i386-libvirt - test-amd64-i386-libvirt-pair - test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm - test-amd64-i386-libvirt-xsm - test-amd64-i386-livepatch - test-amd64-i386-migrupgrade - test-amd64-i386-pair - test-amd64-i386-xl - test-amd64-i386-xl-pvshim - test-amd64-i386-xl-qemut-debianhvm-amd64 - test-amd64-i386-xl-qemut-debianhvm-i386-xsm - test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm - test-amd64-i386-xl-qemut-win7-amd64 - test-amd64-i386-xl-qemut-ws16-amd64 - test-amd64-i386-xl-qemuu-debianhvm-amd64 - test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow - test-amd64-i386-xl-qemuu-debianhvm-i386-xsm - test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict - test-amd64-i386-xl-qemuu-ovmf-amd64 - test-amd64-i386-xl-qemuu-win7-amd64 - test-amd64-i386-xl-qemuu-ws16-amd64 - test-amd64-i386-xl-shadow - test-amd64-i386-xl-simplat-amd64-buster - test-amd64-i386-xl-xsm Gone, but replaced by a new test-amd64-amd64-*: - test-amd64-i386-libvirt-raw - test-amd64-i386-xl-vhd Some test-amd64-amd64-* are also changed: - test-amd64-amd64-libvirt-vhd - test-amd64-amd64-qemuu-freebsd11-amd64 - test-amd64-amd64-qemuu-freebsd12-amd64 - test-amd64-amd64-xl-qcow2 + test-amd64-amd64-freebsd11-amd64 + test-amd64-amd64-freebsd12-amd64 + test-amd64-amd64-libvirt-qcow2 + test-amd64-amd64-libvirt-raw + test-amd64-amd64-xl-vhd In any case, the list of test would be the same as for the existing branch "linux-linus" or "linux-6.1" branches. Signed-off-by: Anthony PERARD --- ap-common | 2 +- mfi-common | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/ap-common b/ap-common index 48a95a22..5384891b 100644 --- a/ap-common +++ b/ap-common @@ -59,7 +59,7 @@ : ${PUSH_TREE_LINUX:=$XENBITS:/home/xen/git/linux-pvops.git} : ${BASE_TREE_LINUX:=git://xenbits.xen.org/linux-pvops.git} -: ${BASE_TAG_LINUX:=tested/linux-4.19} +: ${BASE_TAG_LINUX:=tested/linux-6.1} : ${BASE_TAG_LINUX_ARM:=tested/linux-6.1} if [ "x${TREE_LINUX}" = x ]; then diff --git a/mfi-common b/mfi-common index d8d167fd..e3a91e24 100644 --- a/mfi-common +++ b/mfi-common @@ -662,7 +662,7 @@ test_matrix_iterate () { case "${branch}_${dom0arch}" in linux-5.4_i386 | linux-[2-4].*_i386) ;; # keep 32-bit for old linux - linux-*_i386) continue;; + *_i386) continue;; esac dom0arches+=" $dom0arch" -- Anthony PERARD From xen-devel-bounces@lists.xenproject.org Wed Mar 06 11:54:44 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 11:54:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689097.1074079 (Exim 4.92) (envelope-from ) id 1rhpqx-00079B-HO; Wed, 06 Mar 2024 11:54:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689097.1074079; Wed, 06 Mar 2024 11:54:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhpqx-000794-Es; Wed, 06 Mar 2024 11:54:31 +0000 Received: by outflank-mailman (input) for mailman id 689097; Wed, 06 Mar 2024 11:54:30 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhpqw-00078y-HA for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 11:54:30 +0000 Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [2a00:1450:4864:20::635]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 49a15dc3-dbb0-11ee-afda-a90da7624cb6; Wed, 06 Mar 2024 12:54:29 +0100 (CET) Received: by mail-ej1-x635.google.com with SMTP id a640c23a62f3a-a3f893ad5f4so981383566b.2 for ; Wed, 06 Mar 2024 03:54:29 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id w3-20020a1709064a0300b00a449ebf3d58sm5694485eju.85.2024.03.06.03.54.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 Mar 2024 03:54:28 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 49a15dc3-dbb0-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709726069; x=1710330869; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=sQzbUWMozb32t6eQbESBiG7AGqyemyOFSeuNNrsTwfU=; b=W1ht+LRk6veusMmIrndSqCWRl3l9BfY699yebQrdfu3/49NSeqo+rdba5ztLA9c8Df LAdVjUx8hL2BmVLsxAph5hdG3AcxHvMeRoPJhzace7dr/kucMIzrJav7kg/lI1y+WcnM 0/g0EZp2K4X0LkDY0oiCc47rVHqIsphyHlnJ2fjLboLr/aMGNnqzyhML0mECJWZc+qhb A7KeTsymrcpx5hfltYqJ9vdbvyAT5vRoJHDEJGFK7nvfqE/I0KKDkl6C8X5etHoe6Bee zmzqwalTmOdDwcto+uAhhO/zNO94pR3QcMBwTQjgfXv54cctl0R0twKijAmH2MmJ1ZCC uuvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709726069; x=1710330869; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=sQzbUWMozb32t6eQbESBiG7AGqyemyOFSeuNNrsTwfU=; b=T1H4/dCPMVcZnHq/7ZKa+fz7skbzVLqar7zkfYIisJNk17pJG7FgaOluu/r3Oj4Jlu /k0X5CsOHlaBwaGCRODTL8QwXWESnfYi4lLQX8fHCAfgxGvsDMv4pwyhZB+xnrR+aLFn vhakU525HSY4QcaIk1DeRzL7+sQoaK8Zs7HgAfisE4qwk7kT1+Bk7lf0TOSmn2uoqlEl C+u8DDmpYInjiTJl/jf4ADLQl90lXJTvpScWA0+zko3+0baimfs+FhT9pYlL5oftSygi 4iTQZr19Vyllp4xaRwGvFJ2FVeTKyNJw8HElNG3eiiNAMqrok7eTtzDm/+imRkCkNeJD F5ug== X-Forwarded-Encrypted: i=1; AJvYcCUEnJki2DyAlj8+1lFBMVq9LZ64W4cPRClEbsmZdMdnrQ7S2rzZHuxF9BPnpk1is8UCb1POh3ddTBfeKWjwnD2JcCWtg2Z420GiAohEfjU= X-Gm-Message-State: AOJu0YysLmR7CR6uBAeNka7IGmXil/id1TsTZk3SjyKCbUMIQePy13xM 7z4iF+9fc/ENJ7YyHaAdoI685J3MZI4VGw4mClGy4LNZBRYdHQ5LIXAfeUty2A== X-Google-Smtp-Source: AGHT+IHhRXZMii21bXoQDuymGrboJDB4ahusTHVVkjx82tV2Hafgv5UUatuaTU29CCeoVeVXxTnpJQ== X-Received: by 2002:a17:907:11c1:b0:a43:4ce5:db5c with SMTP id va1-20020a17090711c100b00a434ce5db5cmr10894669ejb.16.1709726068750; Wed, 06 Mar 2024 03:54:28 -0800 (PST) Message-ID: Date: Wed, 6 Mar 2024 12:54:27 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/entry: shrink insn size for some of our EFLAGS manipulation Content-Language: en-US To: Andrew Cooper Cc: Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , "xen-devel@lists.xenproject.org" References: <0ba4903d-638d-408e-bcd4-7c13cb56e078@suse.com> <76cdb4b4-a9f5-46e6-bb30-515ffb37c45a@citrix.com> <54bc9b3f-27af-41ea-9ab4-f35d38fe995d@suse.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 06.03.2024 12:14, Andrew Cooper wrote: > On 06/03/2024 10:49 am, Jan Beulich wrote: >> On 06.03.2024 11:33, Andrew Cooper wrote: >>> On 05/03/2024 2:04 pm, Jan Beulich wrote: >>>> --- a/xen/arch/x86/x86_64/entry.S >>>> +++ b/xen/arch/x86/x86_64/entry.S >>>> @@ -52,7 +52,7 @@ UNLIKELY_END(syscall_no_callback) >>>> movq %rax,TRAPBOUNCE_eip(%rdx) >>>> movb %cl,TRAPBOUNCE_flags(%rdx) >>>> call create_bounce_frame >>>> - andl $~X86_EFLAGS_DF,UREGS_eflags(%rsp) >>>> + andb $~(X86_EFLAGS_DF >> 8), UREGS_eflags + 1(%rsp) >>> The other adjustments are fine, but what on earth are we doing with DF here? >>> >>> This looks straight up buggy.  We've got no legitimate reason to be >>> playing with the guest's view of DF. >> This is the PV equivalent of the SYSCALL_MASK MSR, isn't it? > > Well, is it? > > It definitely never existed in 32bit builds of Xen, when the int80 > direct trap existed. > > I don't see any evidence of it applying anywhere for compat PV guests > either, even those with syscall enabled. Neither int80 nor the 32-bit mode syscall apply the flags mask. Therefore why would we mimic such behavior in Xen? >> With it not >> really being an (emulated) MSR, but an agreement that guests will only ever >> care about having DF cleared (besides the requested way of dealing with the >> event mask). One of the many things not written down anywhere ... > > If it's not written down, it doesn't exist... IOW the PV interface as a whole largely doesn't exist. > And even if this is supposed to be a PV-FMASK-ish thing, it's buggy > because it apples also when #UD is raised for no registered callback.  > (And yes, I realise there is a chronology issues here (the #UD check is > the newer element), but it really will corrupt state as presented in a > SIGSEGV frame. > > The question we need to answer is whether there is any remotely-credible > way that a PV guest kernel author could be expecting this behaviour and > relying on it. > > I honestly don't think there is. I was going to say XenoLinux and its forward ports did, but upstream Linux does, too. The native and PV paths being largely shared, there's no CLD in sight anywhere. > It fails the principle of least surprise compared to native behaviour, > 32bit PV behaviour, and to every non-SYSCALL based 64bit event also. Why "every"? switch_to_kernel is used solely for syscall handling. And why do you consider this behavior surprising, when really it would be surprising for the flag to remain untouched from what user mode had, when taking into account how the MSR is set in the native case? > It either needs writing down somewhere (and the #UD case fixing), or it > needs deleing, because continuing to leave it in this state isn't ok. I can try to determine whether addressing the #UD case can be done in a non-intrusive way. If so, I can split off that part of the change here, and make it a separate one with the MOVL->MOVB just done on the side. But really this is scope creep: The change as is has no (intended) change in behavior. It ought to be fine to go in independently; the further work you ask for could be done up front or later on. Jan From xen-devel-bounces@lists.xenproject.org Wed Mar 06 11:57:11 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 11:57:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689100.1074090 (Exim 4.92) (envelope-from ) id 1rhptV-0007hE-U8; Wed, 06 Mar 2024 11:57:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689100.1074090; Wed, 06 Mar 2024 11:57:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhptV-0007h7-R5; Wed, 06 Mar 2024 11:57:09 +0000 Received: by outflank-mailman (input) for mailman id 689100; Wed, 06 Mar 2024 11:57:08 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhptU-0007gz-NO for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 11:57:08 +0000 Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [2a00:1450:4864:20::335]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id a73f3ed5-dbb0-11ee-a1ee-f123f15fe8a2; Wed, 06 Mar 2024 12:57:06 +0100 (CET) Received: by mail-wm1-x335.google.com with SMTP id 5b1f17b1804b1-412e6ba32easo21417335e9.0 for ; Wed, 06 Mar 2024 03:57:06 -0800 (PST) Received: from perard.uk.xensource.com (default-46-102-197-194.interdsl.co.uk. [46.102.197.194]) by smtp.gmail.com with ESMTPSA id g9-20020a05600c4ec900b00412ee7d65a6sm4500578wmq.6.2024.03.06.03.57.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Mar 2024 03:57:05 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a73f3ed5-dbb0-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1709726226; x=1710331026; darn=lists.xenproject.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=9DltjrE2zt2D3BwLB8iMrcHwv/uicyByZgF0Y2kIPa8=; b=cq0wTjkL9g/pLLgKc8BylMj2BnKH3kj0VLMiwklcBUA6vOuBYpXMqO7KKdZ0fb29DM 258V3UgK82vu7cldswjkd+GvVD1fJZDTB9m12sib03O0nLyxYMoPg07daynXcsfDJFeF MEhU4jZ/2QmxM0Qzc1RbByG51n4v3wZERO78Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709726226; x=1710331026; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=9DltjrE2zt2D3BwLB8iMrcHwv/uicyByZgF0Y2kIPa8=; b=GvYQPduq+1Y7n1vx58Unw63Y0dSKH2PLmKwTx3+jB15d6DYdUgJv+bm4iKf5Iboc6a 0BcLxVl3enR4Sz0u8wsmbitR05yevAYh2lF8DRVhKuPL3ZcZRPee0y2nrolvew0Odh5V 7bJ6VU1Own/l95hIbpdOWE3h2MoljeKJOTOEgFGcVWmIbAikD0Ldup06L7r9BaB6HILD 2D06oYMwHuOGRgeDa8ueHXCdOgcxZofFaBmSH5mb+FI5307cgvhS+Oo+TaT8QU6Jw54T rDPDxqHK4fGQf9LPKkg31cM8cNQtemgdqXVOn+SnNBxTSEMwtoWi07wR5XdFcAlbfFC1 hJiw== X-Gm-Message-State: AOJu0YyR+TTW21Jv617jDPQ3r+U1VSSppsqIaw9TISJ7qIXV0Y5cgE0v FKhrnoe9fwLkElD7+tf9aEQHzS344eMauvf4tY43bw08/QpMbF2W0WDkh6tPAug= X-Google-Smtp-Source: AGHT+IHECEfskrfgU4Ztwug6zpma2ubwATu/5OiVLFlOOeJlMS606X/qtr6eHDaeDVq2l1cCQ/JOJg== X-Received: by 2002:a05:600c:4e8e:b0:412:e70a:ab8a with SMTP id f14-20020a05600c4e8e00b00412e70aab8amr5177495wmq.25.1709726225827; Wed, 06 Mar 2024 03:57:05 -0800 (PST) Date: Wed, 6 Mar 2024 11:57:04 +0000 From: Anthony PERARD To: Fouad Hilly Cc: Xen-devel , Wei Liu , Juergen Gross Subject: Re: [PATCH v3] tools/xentop: Add VBD3 support to xentop Message-ID: <6fd0533e-1f91-480b-8d88-50a73c3a8aec@perard> References: <20240228113947.57053-1-fouad.hilly@cloud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240228113947.57053-1-fouad.hilly@cloud.com> On Wed, Feb 28, 2024 at 11:39:47AM +0000, Fouad Hilly wrote: > From: Pritha Srivastava > > xl now knows how to drive tapdisk, so modify libxenstat to > understand vbd3 statistics. > > Signed-off-by: Pritha Srivastava > Signed-off-by: Jorge Martin > Signed-off-by: Fouad Hilly Reviewed-by: Anthony PERARD Thanks, -- Anthony PERARD From xen-devel-bounces@lists.xenproject.org Wed Mar 06 12:00:00 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 12:00:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689103.1074100 (Exim 4.92) (envelope-from ) id 1rhpwA-0000RG-Dg; Wed, 06 Mar 2024 11:59:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689103.1074100; Wed, 06 Mar 2024 11:59:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhpwA-0000R9-B8; Wed, 06 Mar 2024 11:59:54 +0000 Received: by outflank-mailman (input) for mailman id 689103; Wed, 06 Mar 2024 11:59:52 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhpw8-0000Pn-St for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 11:59:52 +0000 Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [2607:f8b0:4864:20::d31]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 098879a7-dbb1-11ee-afda-a90da7624cb6; Wed, 06 Mar 2024 12:59:51 +0100 (CET) Received: by mail-io1-xd31.google.com with SMTP id ca18e2360f4ac-7bf7e37dc60so409024339f.3 for ; Wed, 06 Mar 2024 03:59:52 -0800 (PST) Received: from perard.uk.xensource.com (default-46-102-197-194.interdsl.co.uk. [46.102.197.194]) by smtp.gmail.com with ESMTPSA id d9-20020a0566022be900b007c846141896sm1095305ioy.48.2024.03.06.03.59.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Mar 2024 03:59:50 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 098879a7-dbb1-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1709726390; x=1710331190; darn=lists.xenproject.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=NvtCLWEkDnqIRcLE11fSaP0TSAScu/X/6l3pbT5JiFQ=; b=fy/viRlQi3xzlgKaKthG38k0H1ARe1MBvt1u1V8OPilfQ6vLOglEYoWnu8pXlfCtbY HQsxChessal1IGyQUtI0nB7+8HYmVOMEEt9V9/cDtTGU+27NWF/4npjf3zUl3TBxkmxa 4+vHzpjIoT9hvNyjn51cJWanNgI/dz1g9Lpsk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709726390; x=1710331190; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=NvtCLWEkDnqIRcLE11fSaP0TSAScu/X/6l3pbT5JiFQ=; b=N3D7maYSEdVvcmTm48U1oS389YkUQhU6i1X9upCZJbJxG1R7qqxm7c574nRYOQE+Ao GlxKmedDJ6/Hp9ayfKaMkdtXxWg3aJfyZCS8PTr7u+9MEmubVe7T8Ppfn1H1eWpXYi6O I5d4nEp/95WYHHhZB4DadJldHwhq/Lbsq7XBPLF4LFJXxTKYFcrLAaLcfhn3XpdtnjuF +0AyX0dXw6ZCs1q3a75wJF1pSzrvs0Ijn5IfaRpTmdRa/OR0OtY8i9ZFuZOt+jAmAamn Y+uIFxx9PvUg5HDEmsjYKfA4b0jhGrEEAFqW6CeCMIOBJW4q/C4RvNOGbXl8wLZbQr10 ep3g== X-Forwarded-Encrypted: i=1; AJvYcCXZzF4J5iBI23g3Jkb6ph6qtzmx/ntLVRH3Aa79MJevaUUQKTq1bHYnjLY/fp3jpOpmGD1DIRAdhiWp6ZLq5cgFDhrgNLX2TCmEjDMzSlo= X-Gm-Message-State: AOJu0YzGPKMODJwDtntqwkDA5MVkwm3o0CBUKYJV844gBWeQaN2f/zKp pBqMVAiQbHlHGWSUXCDZ0vinUoSfZLc6Lw38UdOjGkSbJmJZDsmzlTPtwJ2tn8Q= X-Google-Smtp-Source: AGHT+IG4dE44lmGq+NiQT2nvR63EU4cTEVoK7b+cjuwpN9C0wE4mGKyAnRNXVuhliERdO6D3Asjn3A== X-Received: by 2002:a05:6602:53:b0:7c8:395b:3e62 with SMTP id z19-20020a056602005300b007c8395b3e62mr13075071ioz.3.1709726390657; Wed, 06 Mar 2024 03:59:50 -0800 (PST) Date: Wed, 6 Mar 2024 11:59:47 +0000 From: Anthony PERARD To: =?iso-8859-1?Q?J=FCrgen_Gro=DF?= Cc: Jan Beulich , "xen-devel@lists.xenproject.org" , Wei Liu Subject: Re: [PATCH] 9pfsd: allow building with old glibc Message-ID: References: <3aca1707-9eab-4b85-a4ae-e56508b15843@suse.com> <0eeab3e6-f4fb-4723-a674-f5bbdb285356@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0eeab3e6-f4fb-4723-a674-f5bbdb285356@suse.com> On Tue, Mar 05, 2024 at 04:23:23PM +0100, Jrgen Gro wrote: > On 05.03.24 15:33, Jan Beulich wrote: > > Neither pread() / pwrite() nor O_DIRECTORY are available from glibc > > 2.11.3 headers without defining (e.g.) _GNU_SOURCE. Supplying the > > definition unconditionally shouldn't be a problem, seeing that various > > other tools/ components do so, too. > > > > Signed-off-by: Jan Beulich > > Fine with me. > > Reviewed-by: Juergen Gross Acked-by: Anthony PERARD Thanks, -- Anthony PERARD From xen-devel-bounces@lists.xenproject.org Wed Mar 06 12:58:44 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 12:58:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689120.1074122 (Exim 4.92) (envelope-from ) id 1rhqqn-0004Nr-3I; Wed, 06 Mar 2024 12:58:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689120.1074122; Wed, 06 Mar 2024 12:58:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhqqm-0004Nk-WF; Wed, 06 Mar 2024 12:58:25 +0000 Received: by outflank-mailman (input) for mailman id 689120; Wed, 06 Mar 2024 12:58:23 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhqql-0004NY-CY; Wed, 06 Mar 2024 12:58:23 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhqql-0007CN-6a; Wed, 06 Mar 2024 12:58:23 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhqql-0001oA-0O; Wed, 06 Mar 2024 12:58:23 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rhqqk-0007hq-W7; Wed, 06 Mar 2024 12:58:22 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=dF2ywNVIWFaYmCxnJl6gWEE/p5uQ8VMWF/maTKP6hQY=; b=i+3a+PqQCVEn+zM3xUXzum2IWE ytbkv3Ca0kwBN6K6VSYhbi9zFKO9WmAEZA9rGm6HNkgCUEG4tK0bg0ycKGkOXK45eVUR83vdSyjVK IcFDujNIGqpBHc7SyK62YWZdPlRu4FRHlzL3zuGyXEvrte+HBh9D6412Xu4LUamgLpCU=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable test] 184914: tolerable FAIL X-Osstest-Failures: xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:windows-install:fail:heisenbug xen-unstable:test-arm64-arm64-xl-credit1:guest-start/debian.repeat:fail:heisenbug xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: xen=fc84b4a5a37b9250d87ef63983b48e1953bba6d1 X-Osstest-Versions-That: xen=fc84b4a5a37b9250d87ef63983b48e1953bba6d1 From: osstest service owner Date: Wed, 06 Mar 2024 12:58:22 +0000 flight 184914 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/184914/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 12 windows-install fail in 184907 pass in 184914 test-arm64-arm64-xl-credit1 18 guest-start/debian.repeat fail pass in 184907 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop fail like 184905 test-armhf-armhf-libvirt 16 saverestore-support-check fail like 184907 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop fail like 184907 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 184907 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop fail like 184907 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 184907 test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail like 184907 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 184907 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop fail like 184907 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 184907 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184907 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 184907 test-amd64-amd64-libvirt-xsm 15 migrate-support-check fail never pass test-amd64-i386-xl-pvshim 14 guest-start fail never pass test-amd64-i386-libvirt 15 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-check fail never pass test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-check fail never pass test-arm64-arm64-xl 15 migrate-support-check fail never pass test-arm64-arm64-xl 16 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 15 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-check fail never pass test-armhf-armhf-libvirt 15 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-check fail never pass test-amd64-i386-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-check fail never pass test-arm64-arm64-xl-vhd 14 migrate-support-check fail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-check fail never pass version targeted for testing: xen fc84b4a5a37b9250d87ef63983b48e1953bba6d1 baseline version: xen fc84b4a5a37b9250d87ef63983b48e1953bba6d1 Last test of basis 184914 2024-03-06 01:52:03 Z 0 days Testing same since (not found) 0 attempts jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-dom0pvh-xl-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-qemuu-freebsd11-amd64 pass test-amd64-amd64-qemuu-freebsd12-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-examine-bios pass test-amd64-i386-examine-bios pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 fail test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-dom0pvh-xl-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-armhf-armhf-libvirt-qcow2 pass test-amd64-amd64-xl-qcow2 pass test-arm64-arm64-libvirt-raw pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-libvirt-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-examine-uefi pass test-amd64-i386-examine-uefi pass test-amd64-amd64-libvirt-vhd pass test-arm64-arm64-xl-vhd pass test-armhf-armhf-xl-vhd pass test-amd64-i386-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these 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 Published tested tree is already up to date. From xen-devel-bounces@lists.xenproject.org Wed Mar 06 13:13:18 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 13:13:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689125.1074131 (Exim 4.92) (envelope-from ) id 1rhr57-0008Pw-7J; Wed, 06 Mar 2024 13:13:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689125.1074131; Wed, 06 Mar 2024 13:13:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhr57-0008Pp-4g; Wed, 06 Mar 2024 13:13:13 +0000 Received: by outflank-mailman (input) for mailman id 689125; Wed, 06 Mar 2024 13:13:12 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhr56-0008Pj-Ez for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 13:13:12 +0000 Received: from mail.actia.se (mail.actia.se [212.181.117.226]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 4842ffde-dbbb-11ee-afda-a90da7624cb6; Wed, 06 Mar 2024 14:13:11 +0100 (CET) Received: from S036ANL.actianordic.se (10.12.31.117) by S036ANL.actianordic.se (10.12.31.117) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Wed, 6 Mar 2024 14:13:10 +0100 Received: from S036ANL.actianordic.se ([fe80::e13e:1feb:4ea6:ec69]) by S036ANL.actianordic.se ([fe80::e13e:1feb:4ea6:ec69%4]) with mapi id 15.01.2507.035; Wed, 6 Mar 2024 14:13:10 +0100 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 4842ffde-dbbb-11ee-afda-a90da7624cb6 From: John Ernberg To: Michal Orzel , Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk CC: "xen-devel@lists.xenproject.org" , "Peng Fan" , Jonas Blixt Subject: Re: [PATCH v2 1/2] xen/arm: Add imx8q{m,x} platform glue Thread-Topic: [PATCH v2 1/2] xen/arm: Add imx8q{m,x} platform glue Thread-Index: AQHaX1/Xeq0xXmpbZkiZsYYSHlNyGLELC+MAgABRRACAH2NoAA== Date: Wed, 6 Mar 2024 13:13:10 +0000 Message-ID: <50a4bbff-e81e-42d2-94b1-c9eb064253b5@actia.se> References: <20240214160644.3418228-1-john.ernberg@actia.se> <20240214160644.3418228-2-john.ernberg@actia.se> <3fe044c4-5e60-4e11-a99e-38534610640b@amd.com> <00df4ae3-8d14-41c3-95f1-65516c48e01c@actia.se> In-Reply-To: <00df4ae3-8d14-41c3-95f1-65516c48e01c@actia.se> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.12.12.30] x-esetresult: clean, is OK x-esetid: 37303A2958D72955627162 Content-Type: text/plain; charset="utf-8" Content-ID: <97C7EE6BECA1E1438BC59A58EC3A6B37@actia.se> Content-Transfer-Encoding: base64 MIME-Version: 1.0 SGkgTWljaGFsLA0KDQpPbiAyLzE1LzI0IDE0OjUzLCBKb2huIEVybmJlcmcgd3JvdGU6DQo+IEhp IE1pY2hhbCwNCj4gDQo+IE9uIDIvMTUvMjQgMTA6MDIsIE1pY2hhbCBPcnplbCB3cm90ZToNCj4+ IEhpLA0KPj4NCj4+IE9uIDE0LzAyLzIwMjQgMTc6MDYsIEpvaG4gRXJuYmVyZyB3cm90ZToNCj4+ Pg0KPj4+DQo+Pj4gV2hlbiB1c2luZyBMaW51eCBmb3IgZG9tMCB0aGVyZSBhcmUgYSBidW5jaCBv ZiBkcml2ZXJzIHRoYXQgbmVlZCB0byANCj4+PiBkbyBTTUMNCj4+PiBTSVAgY2FsbHMgaW50byB0 aGUgZmlybXdhcmUgdG8gZW5hYmxlIGNlcnRhaW4gaGFyZHdhcmUgYml0cyBsaWtlIHRoZQ0KPj4+ IHdhdGNoZG9nLg0KPj4+DQo+Pj4gUHJvdmlkZSBhIGJhc2ljIHBsYXRmb3JtIGdsdWUgdGhhdCBp bXBsZW1lbnRzIHRoZSBuZWVkZWQgU01DIGZvcndhcmRpbmcuDQo+Pj4NCj4+PiBUaGUgZm9ybWF0 IG9mIHRoZXNlIGNhbGxzIGFyZSBhcyBmb2xsb3dzOg0KPj4+IMKgIC0gcmVnIDA6IHNlcnZpY2Ug SUQNCj4+PiDCoCAtIHJlZyAxOiBmdW5jdGlvbiBJRA0KPj4+IMKgIHJlbWFpbmluZyByZWdzOiBh cmdzDQo+Pj4NCj4+PiBGb3Igbm93IHdlIG9ubHkgYWxsb3cgRG9tMCB0byBtYWtlIHRoZXNlIGNh bGxzIGFzIHRoZXkgYXJlIGFsbCBtYW5hZ2luZw0KPj4+IGhhcmR3YXJlLiBUaGVyZSBpcyBubyBz cGVjaWZpY2F0aW9uIGZvciB0aGVzZSBTSVAgY2FsbHMsIHRoZSBJRHMgYW5kIA0KPj4+IG5hbWVz DQo+Pj4gaGF2ZSBiZWVuIGV4dHJhY3RlZCBmcm9tIHRoZSB1cHN0cmVhbSBsaW51eCBrZXJuZWwg YW5kIHRoZSB2ZW5kb3IgDQo+Pj4ga2VybmVsLg0KPj4+DQo+Pj4gTW9zdCBvZiB0aGUgU0lQIGNh bGxzIGFyZSBvbmx5IGF2YWlsYWJsZSBmb3IgdGhlIGlNWDhNIHNlcmllcyBvZiANCj4+PiBTb0Nz LCBzbw0KPj4+IHRoZXkgYXJlIGVhc3kgdG8gcmVqZWN0IGFuZCB0aGV5IG5lZWQgdG8gYmUgcmV2 aXNpdGVkIHdoZW4gaU1YOE0gc2VyaWVzDQo+Pj4gc3VwcG9ydCBpcyBhZGRlZC4NCj4+IEdpdmVu IHRoYXQgeW91IG5hbWVkIHlvdXIgZHJpdmVyICpxbSBhbmQgeW91IHNlYXJjaCBmb3IgZHQgY29t cGF0aWJsZSANCj4+ICpxbSwgKnF4cCwgZG9lcyBpdCByZWFsbHkNCj4+IG1ha2Ugc2Vuc2UgdG8g YWRkIFNJUCBjYWxscyBmb3IgaU1YOE0/DQo+IA0KPiBUaGUgaWRlYSB3YXMgdG8gYmUgZXhwbGlj aXQgYWJvdXQgd2h5IGl0IG1ha2VzIG5vIHNlbnNlIHRvIHN1cHBvcnQgdGhvc2UgDQo+IFNJUHMg b24gYSBxbS9xeHAgaW1wbGVtZW50YXRpb24uDQo+IA0KPiBJIGNhbiB0YWtlIGl0IG91dCBpZiB0 aGF0J3Mgbm90IGFyZ3VtZW50IGVub3VnaCB0byBoYXZlIHRoZW0uDQoNClsgLi4uIF0NCg0KPj4+ ICsjZGVmaW5lIElNWF9TSVBfR0VUX1NPQ19JTkZPIDB4QzIwMDAwMDYNCj4+PiArI2RlZmluZSBJ TVhfU0lQX05PQ8KgwqDCoMKgwqDCoMKgwqDCoCAweEMyMDAwMDA4DQo+Pj4gKyNkZWZpbmUgSU1Y X1NJUF9XQUtFVVBfU1JDwqDCoCAweEMyMDAwMDA5DQo+Pj4gKyNkZWZpbmUgSU1YX1NJUF9PVFBf V1JJVEXCoMKgwqAgMHhDMjAwMDAwQg0KPj4gTG9va2luZyBhdCBBVEYsIGZvciBRTSxRWFAgdGhl cmUgYXJlIGFsc286DQo+PiBCVUlMRElORk8gMHhDMjAwMDAwMw0KPj4gT1RQX1JFQUTCoCAweEMy MDAwMDBBDQo+PiBTRVRfVEVNUMKgIDB4QzIwMDAwMEMNCj4gDQo+IEkgY2FuJ3QgZmluZCB0aGVt IGluIHRoZSBjdXJyZW50IExpbnV4IGNvZGUsIHBlcmhhcHMgZGVwcmVjYXRlZC4NCj4gSSBjYW4g YWRkIHRoZW0gYW5kIGRlbnkgdGhlbSBpZiBpdCBtYWtlcyBzZW5zZS4NCj4+DQo+Pj4gKw0KPj4+ ICsjZGVmaW5lIElNWF9TSVBfVElNRV9GX1JUQ19TRVRfVElNRcKgwqDCoMKgIDB4MDANCj4+PiAr I2RlZmluZSBJTVhfU0lQX1RJTUVfRl9XRE9HX1NUQVJUwqDCoMKgwqDCoMKgIDB4MDENCj4+PiAr I2RlZmluZSBJTVhfU0lQX1RJTUVfRl9XRE9HX1NUT1DCoMKgwqDCoMKgwqDCoCAweDAyDQo+Pj4g KyNkZWZpbmUgSU1YX1NJUF9USU1FX0ZfV0RPR19TRVRfQUNUwqDCoMKgwqAgMHgwMw0KPj4+ICsj ZGVmaW5lIElNWF9TSVBfVElNRV9GX1dET0dfUElOR8KgwqDCoMKgwqDCoMKgIDB4MDQNCj4+PiAr I2RlZmluZSBJTVhfU0lQX1RJTUVfRl9XRE9HX1NFVF9USU1FT1VUIDB4MDUNCj4+PiArI2RlZmlu ZSBJTVhfU0lQX1RJTUVfRl9XRE9HX0dFVF9TVEFUwqDCoMKgIDB4MDYNCj4+PiArI2RlZmluZSBJ TVhfU0lQX1RJTUVfRl9XRE9HX1NFVF9QUkVUSU1FIDB4MDcNCj4+PiArDQoNClBpbmcuDQoNClRo YW5rcyEgLy8gSm9obiBFcm5iZXJnDQo= From xen-devel-bounces@lists.xenproject.org Wed Mar 06 13:13:34 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 13:13:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689126.1074142 (Exim 4.92) (envelope-from ) id 1rhr5R-0000PH-Fv; Wed, 06 Mar 2024 13:13:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689126.1074142; Wed, 06 Mar 2024 13:13:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhr5R-0000PA-CV; Wed, 06 Mar 2024 13:13:33 +0000 Received: by outflank-mailman (input) for mailman id 689126; Wed, 06 Mar 2024 13:13:32 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhr5Q-0000Os-EF; Wed, 06 Mar 2024 13:13:32 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhr5Q-0007Xq-5U; Wed, 06 Mar 2024 13:13:32 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhr5P-0002AG-Ql; Wed, 06 Mar 2024 13:13:31 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rhr5P-0003J2-QG; Wed, 06 Mar 2024 13:13:31 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=nSXfphleN1I4A4eWOTHb7+E0Xrv7BykgeX6Bhz2sALM=; b=b6x02TQLIS7h0GToC3D8fz7l3s dg1hmmpsOb0wdfP5FPXs49TouBvdcE7/IASk7AHCBNkz0u9sobbh+oj6h0/cs94AMfeamdWd0/+R5 GAS8NQ1J4tpKZLTqgLP9x7MD3/aZ/xUwOJsqPmPzZKYJqYD5xIngCJ/h2zlyhJcv2Luw=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 184918: tolerable all pass - PUSHED X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=cd53ee9c41f991bbca75641e647005e013a3eac0 X-Osstest-Versions-That: xen=fc84b4a5a37b9250d87ef63983b48e1953bba6d1 From: osstest service owner Date: Wed, 06 Mar 2024 13:13:31 +0000 flight 184918 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/184918/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass version targeted for testing: xen cd53ee9c41f991bbca75641e647005e013a3eac0 baseline version: xen fc84b4a5a37b9250d87ef63983b48e1953bba6d1 Last test of basis 184891 2024-03-04 10:02:19 Z 2 days Testing same since 184918 2024-03-06 10:02:20 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Fouad Hilly Jan Beulich Julien Grall Michal Orzel Oleksii Kurochko Roger Pau Monné Wei Liu 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-amd64 pass 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 fc84b4a5a3..cd53ee9c41 cd53ee9c41f991bbca75641e647005e013a3eac0 -> smoke From xen-devel-bounces@lists.xenproject.org Wed Mar 06 13:13:37 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 13:13:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689130.1074152 (Exim 4.92) (envelope-from ) id 1rhr5V-0000iA-TD; Wed, 06 Mar 2024 13:13:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689130.1074152; Wed, 06 Mar 2024 13:13:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhr5V-0000hw-QS; Wed, 06 Mar 2024 13:13:37 +0000 Received: by outflank-mailman (input) for mailman id 689130; Wed, 06 Mar 2024 13:13:37 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhr5V-0008Pj-0K for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 13:13:37 +0000 Received: from mail.actia.se (mail.actia.se [212.181.117.226]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 573eb6eb-dbbb-11ee-afda-a90da7624cb6; Wed, 06 Mar 2024 14:13:36 +0100 (CET) Received: from S036ANL.actianordic.se (10.12.31.117) by S035ANL.actianordic.se (10.12.31.116) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Wed, 6 Mar 2024 14:13:36 +0100 Received: from S036ANL.actianordic.se ([fe80::e13e:1feb:4ea6:ec69]) by S036ANL.actianordic.se ([fe80::e13e:1feb:4ea6:ec69%4]) with mapi id 15.01.2507.035; Wed, 6 Mar 2024 14:13:36 +0100 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 573eb6eb-dbbb-11ee-afda-a90da7624cb6 From: John Ernberg To: Julien Grall , Peng Fan , "Stefano Stabellini" , Bertrand Marquis , Michal Orzel , "Volodymyr Babchuk" CC: Jonas Blixt , "xen-devel@lists.xenproject.org" Subject: Re: [PATCH 1/2] xen/arm: Add imx8q{m,x} platform glue Thread-Topic: [PATCH 1/2] xen/arm: Add imx8q{m,x} platform glue Thread-Index: AQHaVDuqVQ/kgxLZgUK/m8/hE0ez5bDzxxsAgAA1KwCAAVx5AIAAQjeAgAEdtQCAAyp5AIABm3uAgAZ8E4CAKNxDgA== Date: Wed, 6 Mar 2024 13:13:35 +0000 Message-ID: <911ec1bb-3733-4f37-839e-673a88e408ff@actia.se> References: <20240131114952.305805-1-john.ernberg@actia.se> <20240131114952.305805-2-john.ernberg@actia.se> <494d4961-ad8a-4d1d-aaa6-d1bfb9d6a137@actia.se> <167f0c7a-e037-446c-82f8-2584e35a7af1@xen.org> <012b5f83-2f9b-4477-965e-07b8506c0052@xen.org> <5a0c8f09-4f01-45e9-892c-86342c0d0ec5@xen.org> <08ae764c-3490-4dd1-ab70-7a855a98d16d@actia.se> In-Reply-To: <08ae764c-3490-4dd1-ab70-7a855a98d16d@actia.se> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.12.12.30] x-esetresult: clean, is OK x-esetid: 37303A2921D72955627162 Content-Type: text/plain; charset="utf-8" Content-ID: <2D6D0E34F6FE1C49B06607BD1330CBAE@actia.se> Content-Transfer-Encoding: base64 MIME-Version: 1.0 SGkgSnVsaWVuLA0KDQpPbiAyLzkvMjQgMTQ6MTQsIEpvaG4gRXJuYmVyZyB3cm90ZToNCj4gSGkg SnVsaWVuLA0KPiANCj4gQXBvbG9naWVzIGZvciB0aGUgZGVsYXksIEkgd2FzIHB1bGxlZCBhd2F5 IGZvciBhIGJpdC4NCj4gDQo+IE9uIDIvNS8yNCAxMToxMywgSnVsaWVuIEdyYWxsIHdyb3RlOg0K Pj4gSGksDQo+Pg0KPj4gT24gMDQvMDIvMjAyNCAwOTo0MCwgUGVuZyBGYW4gd3JvdGU6DQo+Pj4N Cj4+Pg0KPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+PiBGcm9tOiBKdWxpZW4g R3JhbGwgPGp1bGllbkB4ZW4ub3JnPg0KPj4+PiBTZW50OiAyMDI05bm0MuaciDLml6UgMTc6MjAN Cj4+Pj4gVG86IEpvaG4gRXJuYmVyZyA8am9obi5lcm5iZXJnQGFjdGlhLnNlPjsgU3RlZmFubyBT dGFiZWxsaW5pDQo+Pj4+IDxzc3RhYmVsbGluaUBrZXJuZWwub3JnPjsgQmVydHJhbmQgTWFycXVp cyA8YmVydHJhbmQubWFycXVpc0Bhcm0uY29tPjsNCj4+Pj4gTWljaGFsIE9yemVsIDxtaWNoYWwu b3J6ZWxAYW1kLmNvbT47IFZvbG9keW15ciBCYWJjaHVrDQo+Pj4+IDxWb2xvZHlteXJfQmFiY2h1 a0BlcGFtLmNvbT47IFBlbmcgRmFuIDxwZW5nLmZhbkBueHAuY29tPg0KPj4+PiBDYzogSm9uYXMg QmxpeHQgPGpvbmFzLmJsaXh0QGFjdGlhLnNlPjsgeGVuLWRldmVsQGxpc3RzLnhlbnByb2plY3Qu b3JnDQo+Pj4+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggMS8yXSB4ZW4vYXJtOiBBZGQgaW14OHF7bSx4 fSBwbGF0Zm9ybSBnbHVlDQo+Pj4+DQo+Pj4+IE9uIDAxLzAyLzIwMjQgMTY6MTcsIEpvaG4gRXJu YmVyZyB3cm90ZToNCj4+Pj4+IE9uIDIvMS8yNCAxMzoyMCwgSnVsaWVuIEdyYWxsIHdyb3RlOg0K Pj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+PiBPbiAzMS8wMS8yMDI0IDE1OjMyLCBKb2huIEVybmJlcmcg d3JvdGU6DQo+Pj4+Pj4+IEhpIEp1bGllbiwNCj4+Pj4+Pg0KPj4+Pj4+IEhpIEpvaG4sDQo+Pj4+ Pj4NCj4+Pj4+Pj4gT24gMS8zMS8yNCAxMzoyMiwgSnVsaWVuIEdyYWxsIHdyb3RlOg0KPj4+Pj4+ Pj4gSGksDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gT24gMzEvMDEvMjAyNCAxMTo1MCwgSm9obiBFcm5i ZXJnIHdyb3RlOg0KPiBbIC4uLiBdDQo+Pj4+Pj4NCj4+Pj4+Pj4+IEJ1dCBldmVuIGlmIHdlIHJl c3RyaWN0IHRvIGRvbTAsIGhhdmUgeW91IGNoZWNrZWQgdGhhdCBub25lIG9mIHRoZQ0KPj4+Pj4+ Pj4gU01DcyB1c2UgYnVmZmVycz8NCj4+Pj4+Pj4gSSBoYXZlbid0IGZvdW5kIGFueSBzdWNoIGlu c3RhbmNlcyBpbiB0aGUgTGludXgga2VybmVsIHdoZXJlIGENCj4+Pj4+Pj4gYnVmZmVyIGlzIHVz ZWQuIEFkZGluZyBhIGNhbGwgZmlsdGVyaW5nIGxpa2Ugc3VnZ2VzdGVkIGJlbG93DQo+Pj4+Pj4+ IGFkZGl0aW9ucyBvZiBzdWNoIGZ1bmN0aW9ucyBjYW4gYmUgZGlzY292ZXJlZCBhbmQgYWRhcHRl ZCBmb3IgaWYgDQo+Pj4+Pj4+IHRoZXkNCj4+Pj4gd291bGQgc2hvdyB1cCBsYXRlci4NCj4+Pj4+ Pj4+DQo+Pj4+Pj4+PiBSYXRoZXIgdGhhbiBwcm92aWRpbmcgYSBibGFua2V0IGZvcndhcmQsIHRv IG1lIGl0IHNvdW5kcyBtb3JlIGxpa2UNCj4+Pj4+Pj4+IHlvdSB3YW50IHRvIHByb3ZpZGUgYW4g YWxsb3dsaXN0IG9mIHRoZSBTTUNzLiBUaGlzIGlzIG1vcmUNCj4+Pj4+Pj4+IGZ1dHVyZXByb29m IGFuZCBhdm9pZCB0aGUgcmlzayB0byBleHBvc2UgdW5zYWZlIFNNQ3MgdG8gYW55IGRvbWFpbi4N Cj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBGb3IgYW4gZXhhbXBsZSwgeW91IGNhbiBoYXZlIGEgbG9vayBh dCB0aGUgRUVNSSBtZWRpYXRvciBmb3IgDQo+Pj4+Pj4+PiBYaWxpbnguDQo+Pj4+Pj4+DQo+Pj4+ Pj4+IEFjay4gRG8geW91IHByZWZlciB0byBzZWUgb25seSBvbiBTTUNDQyBzZXJ2aWNlIGxldmVs IG9yIGFsc28gb24NCj4+Pj4+Pj4gZnVuY3Rpb24gbGV2ZWw/IChhMSByZWdpc3RlciwgcGVyIGRl c2NyaXB0aW9uIGVhcmxpZXIpDQo+Pj4+Pj4NCj4+Pj4+PiBJIGFtIG5vdCBzdXJlLiBJdCB3aWxs IGRlcGVuZCBvbiB3aGV0aGVyIGl0IGlzIGNvcnJlY3QgdG8gZXhwb3NlDQo+Pj4+Pj4gKmFsbCog dGhlIGZ1bmN0aW9ucyB3aXRoaW4gYSBzZXJ2aWNlIGxldmVsIGFuZCB0aGV5IGhhdmUgdGhlIHNh bWUgDQo+Pj4+Pj4gZm9ybWF0Lg0KPj4+Pj4+DQo+Pj4+Pj4gSWYgeW91IGNhbid0IGd1YXJhbnRl ZSB0aGF0LCB0aGVuIHlvdSB3aWxsIG1vc3QgbGlrZWx5IG5lZWQgdG8NCj4+Pj4+PiBhbGxvd2xp c3QgYXQgdGhlIGZ1bmN0aW9uIGxldmVsLg0KPj4+Pj4+DQo+Pj4+Pj4gQWxzbywgZG8geW91IGhh dmUgYSBzcGVjIGluIGhhbmQgdGhhdCB3b3VsZCBoZWxwIHRvIHVuZGVyc3RhbmQgd2hpY2gNCj4+ Pj4+PiBzZXJ2aWNlL2Z1bmN0aW9uIGlzIGltcGxlbWVudGVkIHZpYSB0aG9zZSBTTUNzPw0KPj4+ Pj4NCj4+Pj4+IEkgZG9uJ3QgaGF2ZSB0aGUgc3BlYyB1bmZvcnR1bmF0ZWx5LCBidXQgSSB3aWxs IGFkZCBhIGZpbHRlciBvbiBib3RoDQo+Pj4+PiBzZXJ2aWNlIGFuZCBmdW5jdGlvbiBmb3IgVjIg YW5kIHdlJ2xsIHRha2UgaXQgZnJvbSB0aGVyZS4NCj4+Pj4NCj4+Pj4gQFBlbmcsIGRvIHlvdSBo YXZlIGFueSBzcGVjaWZpY2F0aW9uIHlvdSBjb3VsZCBzaGFyZT8gSG93IHN0YWJsZSBpcyB0aGUN Cj4+Pj4gaW50ZXJmYWNlPw0KPj4+DQo+Pj4gTm8gc3BlY2lmaWNhdGlvbiwgdGhlIHVzZSBpcyBJ TVhfU0lQX1ggaW4gbGludXgga2VybmVsIHNvdXJjZS4NCj4+Pg0KPj4+IFN1Y2ggYXMgSU1YX1NJ UF9SVEMsIElNWF9TSVBfVElNRVINCj4+Pg0KPj4+IEl0IGlzIHN0YWJsZSBhbmQgbm8gY2hhbmdl LCB3ZSBvbmx5IGFkZCBuZXcgU0lQIG1hY3JvIGlmIG5lZWRlZA0KPj4+IGFuZCBubyBjaGFuZ2Ug dGhlIG1lYW5pbmcgb3IgcmV1c2Ugb2xkIFNJUC4NCj4+DQo+PiBUaGFua3MgZm9yIHRoZSBhbnN3 ZXIuIEl0IGlzIGEgYml0IHVuZm9ydHVuYXRlIHRoZXJlIGFyZSBubyANCj4+IHNwZWNpZmljYXRp b24sIGJ1dCBhdCBsZWFzdCB0aGV5IGFyZSBzdGFibGUuDQo+Pg0KPj4gSSBoYXZlIHNlYXJjaGVk IElNWF9TSVAgaW4gTGludXgsIHRoZXJlIGRvZXNuJ3Qgc2VlbSBtYW55IHNvIHdlIGNvdWxkIA0K Pj4gYWxsb3dsaXN0IHRoZW0gKHNlZSBtb3JlIGJlbG93KS4gRG8geW91IGtub3cgaWYgdGhlcmUg YXJlIG1vcmUgDQo+PiBuZWNlc3NhcnkgdGhhdCBhcmUgbm90IHlldCB1cHN0cmVhbWVkIGluIExp bnV4Pw0KPiANCj4gSSB0b29rIGEgZGl2ZSBpbnRvIGJvdGggdXBzdHJlYW0ga2VybmVsIGFuZCB0 aGUgdmVuZG9yIHRyZWUgYW5kIGZvdW5kIA0KPiB0aGUgZm9sbG93aW5nIGxpc3QgYW5kIGZvciB3 aGljaCBTb0NzIHRoZXkgYXJlIGFwcGxpY2FibGUgKFBsZWFzZSANCj4gY29ycmVjdCBtZSBpZiB5 b3UgY2FuIFBlbmcpDQo+IA0KPiAweDgyMDAwMDA2IElNWF9TSVBfQlVTRlJFUV9DSEFOR0UgW3Vu c3VyZSwgcHJvYmFibHkgbm90IGlteDhdDQo+IDB4QzIwMDAwMDAgSU1YX1NJUF9HUEMgW29ubHkg aW14OG0gc2VyaWVzXQ0KPiAweEMyMDAwMDAxIElNWF9TSVBfQ1BVRlJFUSBbb25seSBpbXg4cXt4 LG19IHNlcmllc10NCj4gMHhDMjAwMDAwMiBJTVhfU0lQX1NSVEMgLyBJTVhfU0lQX1RJTUVSIFtv bmx5IGlteDhxe3gsbX0gc2VyaWVzXQ0KPiAweEMyMDAwMDA0IElNWF9TSVBfRERSX0RWRlMgW29u bHkgaW14OG0gc2VyaWVzXQ0KPiAweEMyMDAwMDA1IElNWF9TSVBfUlBST0MgLyBJTVhfU0lQX1NS QyBbb25seSBpbXg4bSBzZXJpZXNdDQo+IDB4QzIwMDAwMDYgSU1YX1NJUF9HRVRfU09DX0lORk8g W29ubHkgaW14OG0gc2VyaWVzXQ0KPiAweEMyMDAwMDA4IElNWF9TSVBfTk9DIFtvbmx5IGlteDht IHNlcmllc10NCj4gMHhDMjAwMDAwOSBJTVhfU0lQX1dBS0VVUF9TUkMgW29ubHkgaW14OHF7eCxt fSBzZXJpZXNdDQo+IDB4QzIwMDAwMEIgSU1YX1NJUF9PVFBfV1JJVEUgW29ubHkgaW14OHF7eCxt fSBzZXJpZXNdDQo+Pg0KPj4NCg0KWyAuLi4gXQ0KDQo+IA0KPj4gwqDCoCAqIElNWF9TSVBfVElN RVJfKjrCoCBUaGlzIHNlZW1zIHRvIGJlIHJlbGF0ZWQgdG8gdGhlIHdhdGNoZG9nLiANCj4+IFNo b3VsZG4ndCBkb20wIHJlbHkgb24gdGhlIHdhdGNoZG9nIHByb3ZpZGVkIGJ5IFhlbiBpbnN0ZWFk PyBTbyB0aG9zZSANCj4+IGNhbGwgd2lsbCBiZSB1c2VkIGJ5IFhlbi4NCj4gDQo+IFRoYXQgaXMg aW5kZWVkIGEgd2F0Y2hkb2cgU0lQLCBhbmQgYWxzbyBmb3Igc2V0dGluZyB0aGUgU29DIGludGVy bmFsIFJUQw0KPiBpZiBpdCBpcyBiZWluZyB1c2VkLg0KPiANCj4gSSBsb29rZWQgYXJvdW5kIGlm IHRoZXJlIHdhcyBwcmV2aW91cyBkaXNjdXNzaW9uIGFuZCBvbmx5IHJlYWxseSBmb3VuZCBbM10u DQo+IElzIHRoZSB4ZW4veGVuL2luY2x1ZGUvd2F0Y2hkb2cuaCBoZWFkZXIgbWVhbnQgdG8gYmUg Zm9yIHRoaXMga2luZCBvZiANCj4gd2F0Y2hkb2cgc3VwcG9ydCBvciBpcyB0aGF0IG1vcmUgZm9y IHRoZSBWTSB3YXRjaGRvZz8gTG9va2luZyBhdCB0aGUgeDg2IA0KPiBBQ1BJIE5NSSB3YXRjaGRv ZyBpdCBzZWVtcyBsaWtlIHRoZSBmb3JtZXIsIGJ1dCBJIGhhdmUgbmV2ZXIgd29ya2VkIHdpdGgg DQo+IHg4NiBub3IgQUNQSS4NCj4gDQo+IEN1cnJlbnRseSBmb3J3YXJkaW5nIGl0IHRvIERvbTAg aGFzIG5vdCBjYXVzZWQgYW55IHdhdGNoZG9nIHJlc2V0cyB3aXRoIA0KPiBvdXIgd2F0Y2hkb2cg dGltZW91dCBzZXR0aW5ncywgb3VyIHNwZWNpZmljIERvbTAgc2V0dXAgYW5kIFZNIGNvdW50Lg0K PiANCj4gRm9yIHRoZSByZW1haW5pbmcgYml0czoNCj4gDQo+IFRoZSB3YWtldXAgc3JjIGlzIG5v dCBpbiB0aGUgdXBzdHJlYW0ga2VybmVsIHlldCBhbmQgcmVsYXRlZCB0byBzeXN0ZW0gDQo+IHJl c3VtZSBmcm9tIHN1c3BlbmQgd2hpY2ggaXNuJ3Qgc3VwcG9ydGVkIGluIFhlbiBvbiBBUk0geWV0 IC0gc28gdGhpcyB3ZSANCj4gY2FuIGJsb2NrIHNhZmVseS4NCj4gDQo+IFRoZSBPVFAgd3JpdGUg aXMgZnVzZSBwcm9ncmFtbWluZyBpbiB0aGUgU29DIGZ1c2UgYmFua3MsIGFuZCBzaG91bGQgDQo+ IHByb2JhYmx5IGJlIGFsbG93ZWQgYnV0IHJlc2VydmVkIGZvciBEb20wLCBhcyB0aGlzIGNhbiBz ZXQgZnVzZXMgdGhhdA0KPiBhZmZlY3RzIHRoZSBTb0MgYm9vdC4NCj4gDQo+Pg0KPj4gQWxzbywg d2hhdCBoYXBwZW4gaWYgd2UgZG9uJ3QgZXhwb3NlIHRob3NlIFNNQyB0byBkb20wPw0KPj4NCj4+ IENoZWVycywNCj4+DQo+IA0KPiBbMV06IA0KPiBodHRwczovL2xvcmUua2VybmVsLm9yZy94ZW4t ZGV2ZWwvMTUxMDI0NzQyMS0yNDA5NC0xLWdpdC1zZW5kLWVtYWlsLW9sZWtzdHlzaEBnbWFpbC5j b20vDQo+IFsyXTogDQo+IGh0dHBzOi8vd3d3LnNsaWRlc2hhcmUubmV0L3hlbl9jb21fbWdyL3hw ZGRzMTgtY3B1ZnJlcS1pbi14ZW4tb24tYXJtLW9sZWtzYW5kci10eXNoY2hlbmtvLWVwYW0tc3lz dGVtcw0KPiBbM106IGh0dHBzOi8veGVuLXVzZXJzLm5hcmtpdmUuY29tL0lTWG5sbUIwL3dhdGNo ZG9nLXN1cHBvcnQtaW4teGVuDQo+IA0KPiBUaGFua3MhIC8vIEpvaG4gRXJuYmVyZw0KDQpQaW5n IG9uIHRoZSB3YXRjaGRvZyBkaXNjdXNzaW9uIGJpdHMuDQoNClRoYW5rcyEgLy8gSm9obiBFcm5i ZXJn From xen-devel-bounces@lists.xenproject.org Wed Mar 06 13:20:20 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 13:20:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689134.1074161 (Exim 4.92) (envelope-from ) id 1rhrBx-00032f-Jf; Wed, 06 Mar 2024 13:20:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689134.1074161; Wed, 06 Mar 2024 13:20:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhrBx-00032Y-Gq; Wed, 06 Mar 2024 13:20:17 +0000 Received: by outflank-mailman (input) for mailman id 689134; Wed, 06 Mar 2024 13:20:15 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhrBv-00032O-MO for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 13:20:15 +0000 Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [2a00:1450:4864:20::12d]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 448f3a3d-dbbc-11ee-afda-a90da7624cb6; Wed, 06 Mar 2024 14:20:14 +0100 (CET) Received: by mail-lf1-x12d.google.com with SMTP id 2adb3069b0e04-513173e8191so8651540e87.1 for ; Wed, 06 Mar 2024 05:20:14 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id pv18-20020a170907209200b00a44b90abb1dsm5488207ejb.110.2024.03.06.05.20.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 Mar 2024 05:20:13 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 448f3a3d-dbbc-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709731214; x=1710336014; darn=lists.xenproject.org; h=content-transfer-encoding:autocrypt:content-language:cc:to:subject :from:user-agent:mime-version:date:message-id:from:to:cc:subject :date:message-id:reply-to; bh=ir/m3nUHAc93iVzQkj1bZcSedz9SoljniaiWtgBL3sM=; b=QSL29rtgagCCMBYI8xLVOidHgqkpP6ovdNtTc7sH6MbSazXao9Ke2XX9clY3g+Eplo PpIkcG56P41QShMEPc2kBseQlrbWLlLvj09HoeIPKsiWaO81Dcrg71ElLEVVDJp5iKVo YCSRVQNLyEZHSyLTQYgW8NSaYtD2s7g6uFFLTj5fr6ug7xAGbEL0vlsT4wDr2v5J9u97 Uaske9pfNA805fxi7Fvu3zfR/PhVLCth38FJVqdpnpSA4fee6IdY7OJBwXruEhmy94Fd SpDrYKOQdJ3meCSK0fNeozP0j94HidUi1LL7NdWg2weGpTi4pBr19A3DqY9PGDYa4Cub XVNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709731214; x=1710336014; h=content-transfer-encoding:autocrypt:content-language:cc:to:subject :from:user-agent:mime-version:date:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=ir/m3nUHAc93iVzQkj1bZcSedz9SoljniaiWtgBL3sM=; b=sD+gLPsKsRE0thul37u0qT9NMPbaFApSl1ChNkAEc/Xzptaq5ji3B4Xcep52AaXhjT vFxPs3Y4WJn2IbF5tjhVav/3Gabxicr5bBALp1RB4NICESXQ5ZI9KzHORnWj03FDwXCp 1xVaHd/aG+LmqiQEostv/I717syBt9t8fkSNBs9RFz/5vNcWeQ9ZyI5sU5BgroTfMJQ6 ZSRhz/DI6N+7IsFNdKSv2nAiPg3K9pGMRhBs1GPNbX1gdlL7Kz1KTKn3i9IVE2yeOl/k /2qKZVbrGd8ZyJRa9S+3iZV3v4dP3gN2kbgaDDJrb+h03bUIOHAzD+cMe1uwCj1AXYsY y+kQ== X-Gm-Message-State: AOJu0YyjgNLn7RCFQqO5ZMVPTnC/VFMkFdSNJYd4aZZUgr3aM527UDdJ hQpQtKk/IgnLbRg8ekAYpnnLpmJD8aFUGxD59XBMBbZ2eoxHv6pnV5FCkUHN3eQ0OmNiRZfqWMM = X-Google-Smtp-Source: AGHT+IHoAuXlDSvZEWgCgyz7PSkyGjh+3vPeSz09C4rtgttNn6dWuo378+VQ41znJHZWBUWim4SDBw== X-Received: by 2002:ac2:4ed2:0:b0:513:1c07:3be1 with SMTP id p18-20020ac24ed2000000b005131c073be1mr3038198lfr.4.1709731214014; Wed, 06 Mar 2024 05:20:14 -0800 (PST) Message-ID: <88024bc6-6448-4bf5-b0f6-a75a697cb54f@suse.com> Date: Wed, 6 Mar 2024 14:20:12 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Jan Beulich Subject: [PATCH v2] x86/entry: shrink insn size for some of our EFLAGS manipulation To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Content-Language: en-US Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Much like was recently done for setting entry vector, and along the lines of what we already had in handle_exception_saved, avoid 32-bit immediates where 8-bit ones do. Reduces .text.entry size by 16 bytes in my non-CET reference build, while in my CET reference build section size doesn't change (there and in .text only padding space increases). Inspired by other long->byte conversion work. Signed-off-by: Jan Beulich --- Numbers above are biased by me also having the straight-line-speculation change in the tree, thus every JMP is followed by an INT3. Without that, .text.entry size would also shrink by 16 bytes in the CET build. --- v2: Drop switch_to_kernel change. --- a/xen/arch/x86/x86_64/entry.S +++ b/xen/arch/x86/x86_64/entry.S @@ -223,7 +223,7 @@ LABEL_LOCAL(.Lrestore_rcx_iret_exit_to_g /* No special register assumptions. */ iret_exit_to_guest: andl $~(X86_EFLAGS_IOPL | X86_EFLAGS_VM), EFRAME_eflags(%rsp) - orl $X86_EFLAGS_IF, EFRAME_eflags(%rsp) + orb $X86_EFLAGS_IF >> 8, EFRAME_eflags + 1(%rsp) addq $8,%rsp .Lft0: iretq _ASM_PRE_EXTABLE(.Lft0, handle_exception) @@ -346,7 +346,7 @@ LABEL(sysenter_eflags_saved, 0) GET_STACK_END(bx) /* PUSHF above has saved EFLAGS.IF clear (the caller had it set). */ - orl $X86_EFLAGS_IF, UREGS_eflags(%rsp) + orb $X86_EFLAGS_IF >> 8, UREGS_eflags + 1(%rsp) mov STACK_CPUINFO_FIELD(xen_cr3)(%rbx), %rcx test %rcx, %rcx jz .Lsyse_cr3_okay @@ -361,11 +361,11 @@ LABEL(sysenter_eflags_saved, 0) cmpb $0,VCPU_sysenter_disables_events(%rbx) movq VCPU_sysenter_addr(%rbx),%rax setne %cl - testl $X86_EFLAGS_NT,UREGS_eflags(%rsp) + testb $X86_EFLAGS_NT >> 8, UREGS_eflags + 1(%rsp) leaq VCPU_trap_bounce(%rbx),%rdx UNLIKELY_START(nz, sysenter_nt_set) pushfq - andl $~X86_EFLAGS_NT,(%rsp) + andb $~(X86_EFLAGS_NT >> 8), 1(%rsp) popfq UNLIKELY_END(sysenter_nt_set) testq %rax,%rax From xen-devel-bounces@lists.xenproject.org Wed Mar 06 13:45:08 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 13:45:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689333.1074172 (Exim 4.92) (envelope-from ) id 1rhrZs-0006t1-F4; Wed, 06 Mar 2024 13:45:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689333.1074172; Wed, 06 Mar 2024 13:45:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhrZs-0006su-CT; Wed, 06 Mar 2024 13:45:00 +0000 Received: by outflank-mailman (input) for mailman id 689333; Wed, 06 Mar 2024 13:44:59 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhrZr-0006so-3k for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 13:44:59 +0000 Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [2a00:1450:4864:20::533]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id b7fa7d10-dbbf-11ee-a1ee-f123f15fe8a2; Wed, 06 Mar 2024 14:44:56 +0100 (CET) Received: by mail-ed1-x533.google.com with SMTP id 4fb4d7f45d1cf-5640fef9fa6so8434230a12.0 for ; Wed, 06 Mar 2024 05:44:56 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id z42-20020a509e2d000000b005669d904871sm7287020ede.49.2024.03.06.05.44.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 Mar 2024 05:44:56 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b7fa7d10-dbbf-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709732696; x=1710337496; darn=lists.xenproject.org; h=content-transfer-encoding:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to; bh=PTTS79cJ01BN+KslCMfXg18XV1FMJ23RKExX5h1sW5g=; b=AXK2RjIkvw2OeOogSSIq6tfnAR9inGkpurs4zYO5PjASI7T90Q8/sW2xW1l8sPukgq 0wvFfmYeq3vHYOaZeGMUSJS7xf3qVf5a+7t1KES6iOFWp2J2+RJUyOYSBfcxOmjUQuRJ anAnMDMctNqabwtFRAj8u+ZawsYhK/9I0f0FhUIX++SiHrhyP/3DiEbLZ57FiYTuTogi ZIUGgh7s0FADqcCHN/7B+jdPHFhKMaRinppH2scshOzAjyDkaYkuOg2v+7kj+mOnJvN6 GY1lJc12Dp9R/9bmF0UaxvSi45qZah23ncGdIPuiRMYt/oHqoKTPG1X+eWyeYpnSX8rs 69xA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709732696; x=1710337496; h=content-transfer-encoding:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=PTTS79cJ01BN+KslCMfXg18XV1FMJ23RKExX5h1sW5g=; b=kQSuxXA5nRWJv4faMvVD0QrAKve1wH7rPu+Hr7yXZxElILk1seGbaGDHsQMC25x2Ie SvUsa2NxbDRbTaFOdiMmUK5PW/rsvDUrplDlHhD08RoSbpsMAIOVbXIDgxNSroOv+DH8 SwQvg8S21MNIxoZ97B421Z4YisrGjfKFGJpNk+S1oOWL/mIQZ3k30q6TqQ+8H/NYMEJA ciGNE7J+E7iPLq46BX6/QKvpyu/p6xKW/ztXRhk9osmhq4gc+9ZsEHV5QbzKaGmvM+GG QRYz7x2EcFS+/n6WtXLUNSJdRUh086sw/dZym/AwZf8ny4A7c8qdn2H2jh4SewgH1iJd 4Jpw== X-Gm-Message-State: AOJu0Yzh8/SVdrOzNDzYo9VwnZE5Vre8dA2PnS7GOZ9QREuRBBd1CRNi p4QwJ9eiEJwUQpzG4QBmeHb7fc0eZm8BtC4phhbPFVWIjB2qRY7RYiKLcsgQKHXeSB7bEqwwYos = X-Google-Smtp-Source: AGHT+IEQxSdjMAMzec/52TfDdoDu9tqo4chsAUQ2GTT7Oyqqct74SzPGy7Urfh8vu+i31mx2FrFBEQ== X-Received: by 2002:a50:c8cb:0:b0:566:a235:9355 with SMTP id k11-20020a50c8cb000000b00566a2359355mr11142264edh.33.1709732696236; Wed, 06 Mar 2024 05:44:56 -0800 (PST) Message-ID: <36cf1c15-faa5-4e25-8fdd-9c52076f4ca2@suse.com> Date: Wed, 6 Mar 2024 14:44:55 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= From: Jan Beulich Subject: [PATCH] x86/entry: don't clear DF when raising #UD for lack of syscall handler Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit While doing so is intentional when invoking the actual callback, to mimic a hard-coded SYCALL_MASK / FMASK MSR, the same should not be done when no handler is available and hence #UD is raised. Fixes: ca6fcf4321b3 ("x86/pv: Inject #UD for missing SYSCALL callbacks") Reported-by: Andrew Cooper Signed-off-by: Jan Beulich --- a/xen/arch/x86/x86_64/entry.S +++ b/xen/arch/x86/x86_64/entry.S @@ -38,6 +38,14 @@ FUNC_LOCAL(switch_to_kernel) setc %cl leal (,%rcx,TBF_INTERRUPT),%ecx + /* + * The PV ABI hardcodes the (guest-inaccessible and virtual) + * SYSCALL_MASK MSR such that DF (and nothing else) would be cleared. + * Note that the equivalent of IF (VGCF_syscall_disables_events) is + * dealt with separately above. + */ + mov $~X86_EFLAGS_DF, %esi + test %rax, %rax UNLIKELY_START(z, syscall_no_callback) /* TB_eip == 0 => #UD */ mov VCPU_trap_ctxt(%rbx), %rdi @@ -47,12 +55,13 @@ UNLIKELY_START(z, syscall_no_callback) / testb $4, X86_EXC_UD * TRAPINFO_sizeof + TRAPINFO_flags(%rdi) setnz %cl lea TBF_EXCEPTION(, %rcx, TBF_INTERRUPT), %ecx + or $~0, %esi # don't clear DF UNLIKELY_END(syscall_no_callback) movq %rax,TRAPBOUNCE_eip(%rdx) movb %cl,TRAPBOUNCE_flags(%rdx) call create_bounce_frame - andl $~X86_EFLAGS_DF,UREGS_eflags(%rsp) + and %esi, UREGS_eflags(%rsp) /* %rbx: struct vcpu */ test_all_events: ASSERT_NOT_IN_ATOMIC From xen-devel-bounces@lists.xenproject.org Wed Mar 06 13:57:16 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 13:57:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689338.1074182 (Exim 4.92) (envelope-from ) id 1rhrlf-0000UO-Hm; Wed, 06 Mar 2024 13:57:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689338.1074182; Wed, 06 Mar 2024 13:57:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhrlf-0000UH-ES; Wed, 06 Mar 2024 13:57:11 +0000 Received: by outflank-mailman (input) for mailman id 689338; Wed, 06 Mar 2024 13:57:10 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhrle-0000UB-KH for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 13:57:10 +0000 Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [2a00:1450:4864:20::52d]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 6c0aa140-dbc1-11ee-a1ee-f123f15fe8a2; Wed, 06 Mar 2024 14:57:08 +0100 (CET) Received: by mail-ed1-x52d.google.com with SMTP id 4fb4d7f45d1cf-56647babfe6so10016008a12.3 for ; Wed, 06 Mar 2024 05:57:08 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id f4-20020a05640214c400b005660742bf6bsm6964300edx.52.2024.03.06.05.57.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 Mar 2024 05:57:07 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6c0aa140-dbc1-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709733428; x=1710338228; darn=lists.xenproject.org; h=content-transfer-encoding:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to; bh=GpSXwArW6nSc+7qCqeXjiXiJRJKCqG2IrSnbmiJuBhE=; b=NOMlw2geZsg/VQPYmgUoJCOiR0S0Ay3QrHBSiuGkRjE4lOcOIX9yjm6QM+N+XqNWTB pk8/WzMnqHfkUtpXd1i3HtyE875o0L3Py5EISBrKy/pqxbJ+PKmx1PTDRi3KJZPMQ5lV msoS+1rSnnN5F6pvdIg1wgtwMwPuk1/JzRgW3Jwbns28AT9SEbsPOqo/qsBuFboJn8OC GRdd3ACAQ3HlXycd3tjSvws0PlHMKuPmj2+CIK1z6+f3B8eggRChVnbz2+qGuaOMhniP 4VfQiYaSQVZLVMQf7l1kJ594gumY3K7Dh7AdwNtEiOYw3TpWX3mbQz+6pwYhcrQxB9Wi e93A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709733428; x=1710338228; h=content-transfer-encoding:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=GpSXwArW6nSc+7qCqeXjiXiJRJKCqG2IrSnbmiJuBhE=; b=YkZ/owg/5WboE8ZzF2DRXAJd5VtnmxddJ3yor6DnJS2ihvXl+ZUepN3SGGcwv5NsG1 fqLCxYQaPol6zjbd8Z4mtN7aUJRikbZjJLQMga+DhwA+h+IYerxkyS+XJnzt31vrb9nx XRfB6mEjJLo+Jr5xJdRTxC1hN9z2EuNbtYqmekxEs5CX23zYyiFLVbDwY2WJl5KZz5s5 rHQUdqmBztObqlisDbx9kPGZH1p46F8ONz/hetFKV8Kbte2/HBPE88lW+lmGl5haAwyO PVkcnVruF/5RucOnkjxS+m8X0EkUNVgbyn4immlj0/W4rw9Q8ZBzdZx1LqjxB9ElilFy +a0g== X-Gm-Message-State: AOJu0YxGcHSgrS7BQAkIAc5ov3JoUE9THeAX4n9mv6JJiwoeB49zb/MX zf4w3wYFs2gORSvbLIX/w7j1QGGwv4aaYv2b8IP3MEs0nf1gr9d2TI2i8ED+vDFf41dDdGt8tSE = X-Google-Smtp-Source: AGHT+IEliJC6RtMBmtdjfaLY+Ep/8E9D/K60osP95+9w2tiABwxyL4DZmGGCl9dx9j5vdBNFcHKzVw== X-Received: by 2002:a50:8d86:0:b0:566:825b:98 with SMTP id r6-20020a508d86000000b00566825b0098mr10880581edh.6.1709733427792; Wed, 06 Mar 2024 05:57:07 -0800 (PST) Message-ID: Date: Wed, 6 Mar 2024 14:57:06 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= From: Jan Beulich Subject: [PATCH] x86/entry: re-order exception entry points Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Arrange for Disp8 JMPs to be usable. On top of the MOVL->MOVB conversion this further reduces entry point size, such that in particular INT3 (for guarding against straight line speculation) would then also still fit within the same 16-byte block, irrespective of CET-IBT being enabled. Of course when CC_SPLIT_SECTIONS=y the ordering here doesn't matter at all. Which of the non-IST exception entry points are moved is based on presumed / guessed frequency of use. Signed-off-by: Jan Beulich --- Arguably we could move all these entry points ahead of handle_exception, accepting that the first few will continue to use Disp32 JMPs. --- a/xen/arch/x86/x86_64/entry.S +++ b/xen/arch/x86/x86_64/entry.S @@ -725,6 +725,59 @@ FUNC(common_interrupt) jmp ret_from_intr END(common_interrupt) +FUNC(entry_BP) + ENDBR64 + pushq $0 + movb $X86_EXC_BP, EFRAME_entry_vector(%rsp) + jmp handle_exception +END(entry_BP) + +FUNC(entry_SS) + ENDBR64 + movb $X86_EXC_SS, EFRAME_entry_vector(%rsp) + jmp handle_exception +END(entry_SS) + +FUNC(entry_AC) + ENDBR64 + movb $X86_EXC_AC, EFRAME_entry_vector(%rsp) + jmp handle_exception +END(entry_AC) + +FUNC(entry_NM) + ENDBR64 + pushq $0 + movb $X86_EXC_NM, EFRAME_entry_vector(%rsp) + jmp handle_exception +END(entry_NM) + +FUNC(entry_MF) + ENDBR64 + pushq $0 + movb $X86_EXC_MF, EFRAME_entry_vector(%rsp) + jmp handle_exception +END(entry_MF) + +FUNC(entry_XM) + ENDBR64 + pushq $0 + movb $X86_EXC_XM, EFRAME_entry_vector(%rsp) + jmp handle_exception +END(entry_XM) + +FUNC(entry_UD) + ENDBR64 + pushq $0 + movb $X86_EXC_UD, EFRAME_entry_vector(%rsp) + jmp handle_exception +END(entry_UD) + +FUNC(entry_GP) + ENDBR64 + movb $X86_EXC_GP, EFRAME_entry_vector(%rsp) + jmp handle_exception +END(entry_GP) + FUNC(entry_PF) ENDBR64 movb $X86_EXC_PF, EFRAME_entry_vector(%rsp) @@ -908,41 +961,6 @@ FUNC(entry_DE) jmp handle_exception END(entry_DE) -FUNC(entry_MF) - ENDBR64 - pushq $0 - movb $X86_EXC_MF, EFRAME_entry_vector(%rsp) - jmp handle_exception -END(entry_MF) - -FUNC(entry_XM) - ENDBR64 - pushq $0 - movb $X86_EXC_XM, EFRAME_entry_vector(%rsp) - jmp handle_exception -END(entry_XM) - -FUNC(entry_NM) - ENDBR64 - pushq $0 - movb $X86_EXC_NM, EFRAME_entry_vector(%rsp) - jmp handle_exception -END(entry_NM) - -FUNC(entry_DB) - ENDBR64 - pushq $0 - movb $X86_EXC_DB, EFRAME_entry_vector(%rsp) - jmp handle_ist_exception -END(entry_DB) - -FUNC(entry_BP) - ENDBR64 - pushq $0 - movb $X86_EXC_BP, EFRAME_entry_vector(%rsp) - jmp handle_exception -END(entry_BP) - FUNC(entry_OF) ENDBR64 pushq $0 @@ -957,13 +975,6 @@ FUNC(entry_BR) jmp handle_exception END(entry_BR) -FUNC(entry_UD) - ENDBR64 - pushq $0 - movb $X86_EXC_UD, EFRAME_entry_vector(%rsp) - jmp handle_exception -END(entry_UD) - FUNC(entry_TS) ENDBR64 movb $X86_EXC_TS, EFRAME_entry_vector(%rsp) @@ -976,24 +987,6 @@ FUNC(entry_NP) jmp handle_exception END(entry_NP) -FUNC(entry_SS) - ENDBR64 - movb $X86_EXC_SS, EFRAME_entry_vector(%rsp) - jmp handle_exception -END(entry_SS) - -FUNC(entry_GP) - ENDBR64 - movb $X86_EXC_GP, EFRAME_entry_vector(%rsp) - jmp handle_exception -END(entry_GP) - -FUNC(entry_AC) - ENDBR64 - movb $X86_EXC_AC, EFRAME_entry_vector(%rsp) - jmp handle_exception -END(entry_AC) - FUNC(entry_CP) ENDBR64 movb $X86_EXC_CP, EFRAME_entry_vector(%rsp) @@ -1025,6 +1018,20 @@ FUNC(entry_DF) tailcall do_double_fault END(entry_DF) +FUNC(entry_DB) + ENDBR64 + pushq $0 + movb $X86_EXC_DB, EFRAME_entry_vector(%rsp) + jmp handle_ist_exception +END(entry_DB) + +FUNC(entry_MC) + ENDBR64 + pushq $0 + movb $X86_EXC_MC, EFRAME_entry_vector(%rsp) + jmp handle_ist_exception +END(entry_MC) + FUNC(entry_NMI) ENDBR64 pushq $0 @@ -1161,13 +1168,6 @@ FUNC(handle_ist_exception) #endif END(handle_ist_exception) -FUNC(entry_MC) - ENDBR64 - pushq $0 - movb $X86_EXC_MC, EFRAME_entry_vector(%rsp) - jmp handle_ist_exception -END(entry_MC) - /* No op trap handler. Required for kexec crash path. */ FUNC(trap_nop, 0) ENDBR64 From xen-devel-bounces@lists.xenproject.org Wed Mar 06 14:14:15 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 14:14:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689343.1074192 (Exim 4.92) (envelope-from ) id 1rhs1x-0004xO-Vk; Wed, 06 Mar 2024 14:14:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689343.1074192; Wed, 06 Mar 2024 14:14:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhs1x-0004xH-SP; Wed, 06 Mar 2024 14:14:01 +0000 Received: by outflank-mailman (input) for mailman id 689343; Wed, 06 Mar 2024 14:14:00 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhs1w-0004xB-NX for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 14:14:00 +0000 Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [2a00:1450:4864:20::62e]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id c5718ff6-dbc3-11ee-a1ee-f123f15fe8a2; Wed, 06 Mar 2024 15:13:57 +0100 (CET) Received: by mail-ej1-x62e.google.com with SMTP id a640c23a62f3a-a44ad785a44so627837066b.3 for ; Wed, 06 Mar 2024 06:13:57 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id pv25-20020a170907209900b00a3ee9305b02sm7144797ejb.20.2024.03.06.06.13.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 Mar 2024 06:13:56 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c5718ff6-dbc3-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709734437; x=1710339237; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=osycwpkQt/2CypUYKFLY9a62f0HXbFU/hnJEHqXTGpY=; b=KIqLrGl9q/iEp6lojGhRM5uaszHrGGlu7J76Vwj5HlEIEZXLXfSwPCPJUxUoky43dJ myzlcScHOp/Y7fJdbfta/XQoStrZQ1ZYtXUqccz4XU+fdV+WgkxbbotRmm1+j6p8rf+s zdxgqHOGDExR8QnqXEipG3ZHPGx9DGdZWHn4hSCq0QoC9/27CCjKjGnozqtzXJVFEFfZ 9RI+hwf2gTujskoADYSBkKjFIKTN340bB18MeYUD+YopC1fws9S2dv2vUkAk9qEywNTY QMajRYsK1daOtds+X/blmhCuR+paBrlo5ilPI/alGucrdiZqk9Xv2gRdRQBamapeBfYN 6wsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709734437; x=1710339237; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=osycwpkQt/2CypUYKFLY9a62f0HXbFU/hnJEHqXTGpY=; b=AwdgWBsa6YQ6ZBO6nQb5nZiUpmEMxfWPkMb3K3EgQ+8vAcB9vPrPdmcqJ0mUePU5Fh GiJ/iHHaoE+GgaaUr7H81fzzzS3jgPbWLsOZsAtFOj1WAHja5Sh1z0UAfGoYH/om6Imf 1z6dFNoA+EJ5XmXkIUktYCO2RfDbojE5gCQ3e59wlr+LOVvQIthfmOjsFIj4pvKcETaA XvBFOIUO+KCBov6DCfFmJSqdPrE/KZNLcaxINUEiLECD1WBVI6g45hxVxaqp9vjejvW6 2o05bSIoopnvqoPK/NvRWlJr4H91IaY1fcunL9vB+NiLzwKdIoWh+vjH7ylopvV5ozJG DHJg== X-Forwarded-Encrypted: i=1; AJvYcCUFQYQykn6Z+ZvPzTbDAbAGMKIN72+SQetF/n+nu6yJqJJwktM2Oy21s111EHj3T1JrsOy5ZTZMwRSGX1HIu7qYt5+tL0Q9SlbyHSuTeIQ= X-Gm-Message-State: AOJu0Ywg4oby+QQm2Xd/D/n/4qEVvAOb9atET6qSaNGO5xTLk0TZbftY /4dXYkJ+niC5gs+x3u4RakFWcp5C09uaiCPqyJSMqBq6cohvlTh8UFiDgNi+sw== X-Google-Smtp-Source: AGHT+IFTfYd1LAKFQqlBfqXAaRZd5BoYH4kwrdE2sFYuaT7gAwzeOg3kieZlGIHNUGrLRE8HyREebw== X-Received: by 2002:a17:906:57d4:b0:a45:a2cc:eb8b with SMTP id u20-20020a17090657d400b00a45a2cceb8bmr3876212ejr.13.1709734436725; Wed, 06 Mar 2024 06:13:56 -0800 (PST) Message-ID: <807c31d5-0c5a-4646-ba90-2f284289069f@suse.com> Date: Wed, 6 Mar 2024 15:13:54 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 12/23] xen/riscv: introduce io.h Content-Language: en-US To: Oleksii Kurochko Cc: Alistair Francis , Bob Eshleman , Connor Davis , Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu , xen-devel@lists.xenproject.org References: From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 26.02.2024 18:38, Oleksii Kurochko wrote: > --- /dev/null > +++ b/xen/arch/riscv/include/asm/io.h > @@ -0,0 +1,157 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +/* > + * The header taken form Linux 6.4.0-rc1 and is based on > + * arch/riscv/include/asm/mmio.h with the following changes: > + * - drop forcing of endianess for read*(), write*() functions as > + * no matter what CPU endianness, what endianness a particular device > + * (and hence its MMIO region(s)) is using is entirely independent. > + * Hence conversion, where necessary, needs to occur at a layer up. > + * Another one reason to drop endianess conversion is: > + * https://patchwork.kernel.org/project/linux-riscv/patch/20190411115623.5749-3-hch@lst.de/ > + * One of the answers of the author of the commit: > + * And we don't know if Linux will be around if that ever changes. > + * The point is: > + * a) the current RISC-V spec is LE only > + * b) the current linux port is LE only except for this little bit > + * There is no point in leaving just this bitrotting code around. It > + * just confuses developers, (very very slightly) slows down compiles > + * and will bitrot. It also won't be any significant help to a future Nit: Stray extra leading blank. > + * developer down the road doing a hypothetical BE RISC-V Linux port. > + * - drop unused argument of __io_ar() macros. > + * - drop "#define _raw_{read,write}{b,w,l,d,q} _raw_{read,write}{b,w,l,d,q}" > + * as they are unnessary. Nit: unnecessary (also ... > + * - Adopt the Xen code style for this header, considering that significant changes > + * are not anticipated in the future. > + * In the event of any issues, adapting them to Xen style should be easily > + * manageable. > + * - drop unnessary __r variables in macros read*_cpu() ... again here) > + * Copyright (C) 1996-2000 Russell King > + * Copyright (C) 2012 ARM Ltd. > + * Copyright (C) 2014 Regents of the University of California > + * Copyright (C) 2024 Vates > + */ > + > +#ifndef _ASM_RISCV_IO_H > +#define _ASM_RISCV_IO_H > + > +#include > + > +/* > + * The RISC-V ISA doesn't yet specify how to query or modify PMAs, so we can't > + * change the properties of memory regions. This should be fixed by the > + * upcoming platform spec. > + */ > +#define ioremap_nocache(addr, size) ioremap(addr, size) > +#define ioremap_wc(addr, size) ioremap(addr, size) > +#define ioremap_wt(addr, size) ioremap(addr, size) > + > +/* Generic IO read/write. These perform native-endian accesses. */ > +static inline void __raw_writeb(uint8_t val, volatile void __iomem *addr) > +{ > + asm volatile ( "sb %0, 0(%1)" : : "r" (val), "r" (addr) ); > +} I realize this is like Linux has it, but how is the compiler to know that *addr is being access here? If the omission of respective constraints here and below is intentional, I think a comment (covering all instances) is needed. Note that while supposedly cloned from Arm code, Arm variants do have such constraints in Linux. I'm sorry for not having paid (enough) attention earlier. > +static inline void __raw_writew(uint16_t val, volatile void __iomem *addr) > +{ > + asm volatile ( "sh %0, 0(%1)" : : "r" (val), "r" (addr) ); > +} > + > +static inline void __raw_writel(uint32_t val, volatile void __iomem *addr) > +{ > + asm volatile ( "sw %0, 0(%1)" : : "r" (val), "r" (addr) ); > +} > + > +#ifdef CONFIG_64BIT > +static inline void __raw_writeq(u64 val, volatile void __iomem *addr) uint64_t please > +{ > + asm volatile ( "sd %0, 0(%1)" : : "r" (val), "r" (addr) ); > +} > +#endif > + > +static inline uint8_t __raw_readb(const volatile void __iomem *addr) > +{ > + uint8_t val; > + > + asm volatile ( "lb %0, 0(%1)" : "=r" (val) : "r" (addr) ); > + return val; > +} > + > +static inline uint16_t __raw_readw(const volatile void __iomem *addr) > +{ > + uint16_t val; > + > + asm volatile ( "lh %0, 0(%1)" : "=r" (val) : "r" (addr) ); > + return val; > +} > + > +static inline uint32_t __raw_readl(const volatile void __iomem *addr) > +{ > + uint32_t val; > + > + asm volatile ( "lw %0, 0(%1)" : "=r" (val) : "r" (addr) ); > + return val; > +} > + > +#ifdef CONFIG_64BIT > +static inline u64 __raw_readq(const volatile void __iomem *addr) uint64_t please > +{ > + u64 val; and again > + asm volatile ( "ld %0, 0(%1)" : "=r" (val) : "r" (addr) ); > + return val; > +} > +#endif > + > +/* > + * Unordered I/O memory access primitives. These are even more relaxed than > + * the relaxed versions, as they don't even order accesses between successive > + * operations to the I/O regions. > + */ > +#define readb_cpu(c) __raw_readb(c) > +#define readw_cpu(c) __raw_readw(c) > +#define readl_cpu(c) __raw_readl(c) > + > +#define writeb_cpu(v, c) __raw_writeb(v, c) > +#define writew_cpu(v, c) __raw_writew(v, c) > +#define writel_cpu(v, c) __raw_writel(v, c) > + > +#ifdef CONFIG_64BIT > +#define readq_cpu(c) __raw_readq(c) > +#define writeq_cpu(v, c) __raw_writeq(v, c) > +#endif > + > +/* > + * I/O memory access primitives. Reads are ordered relative to any > + * following Normal memory access. Writes are ordered relative to any prior > + * Normal memory access. The memory barriers here are necessary as RISC-V > + * doesn't define any ordering between the memory space and the I/O space. > + */ > +#define __io_br() do { } while (0) > +#define __io_ar() asm volatile ( "fence i,r" : : : "memory" ); > +#define __io_bw() asm volatile ( "fence w,o" : : : "memory" ); > +#define __io_aw() do { } while (0) > + > +#define readb(c) ({ uint8_t v; __io_br(); v = readb_cpu(c); __io_ar(); v; }) > +#define readw(c) ({ uint16_t v; __io_br(); v = readw_cpu(c); __io_ar(); v; }) > +#define readl(c) ({ uint32_t v; __io_br(); v = readl_cpu(c); __io_ar(); v; }) > + > +#define writeb(v, c) ({ __io_bw(); writeb_cpu(v, c); __io_aw(); }) > +#define writew(v, c) ({ __io_bw(); writew_cpu(v, c); __io_aw(); }) > +#define writel(v, c) ({ __io_bw(); writel_cpu(v, c); __io_aw(); }) > + > +#ifdef CONFIG_64BIT > +#define readq(c) ({ uint64_t v; __io_br(); v = readq_cpu(c); __io_ar(); v; }) > +#define writeq(v, c) ({ __io_bw(); writeq_cpu(v, c); __io_aw(); }) > +#endif Overall looks much tidier now, thanks. Jan From xen-devel-bounces@lists.xenproject.org Wed Mar 06 14:19:40 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 14:19:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689346.1074202 (Exim 4.92) (envelope-from ) id 1rhs7L-0005Yb-IK; Wed, 06 Mar 2024 14:19:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689346.1074202; Wed, 06 Mar 2024 14:19:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhs7L-0005YU-F2; Wed, 06 Mar 2024 14:19:35 +0000 Received: by outflank-mailman (input) for mailman id 689346; Wed, 06 Mar 2024 14:19:34 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhs7J-0005YK-9F for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 14:19:34 +0000 Received: from bombadil.infradead.org (bombadil.infradead.org [2607:7c80:54:3::133]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 8c4089e4-dbc4-11ee-afda-a90da7624cb6; Wed, 06 Mar 2024 15:19:32 +0100 (CET) Received: from hch by bombadil.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1rhs7B-00000000Xnv-0zmt; Wed, 06 Mar 2024 14:19:25 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8c4089e4-dbc4-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=73xuAghPC4Z/eUTJDoMRemAMxFESv8bJnB9ykB4M4q8=; b=adopzwfBlGv617jauRQSoInnIu 77opbIWOak6y+04Xy2Y+F3QGbNIIWgltPv1B3jfbmx0HGPNz1pPSQdk34qAEikc9ZvCJvZjJoAI5B J4B9N0OiI1gO/gZkRS8eqoTXwkvK5flEYDWKMk8iOeR4ragVa+2o09nY0Fql5EcW8hJ9kKVa8Gpmz QP2y2KXeWWFZWt4gymcCvxvWLgBqb2YC3ayBuRfUiR3TZl9RojL1a66pRokOSd6hA3YJwNirtwtxh 3h/D2g5+Bf0LqD+oCBVJ7oBzR43QY2QZvd61YK611orrUfX1y5/GWIe5czjMd83jpt2hhCVgnjz5K kRK3aR8g==; Date: Wed, 6 Mar 2024 06:19:25 -0800 From: Christoph Hellwig To: Alexei Starovoitov Cc: bpf@vger.kernel.org, daniel@iogearbox.net, andrii@kernel.org, torvalds@linux-foundation.org, brho@google.com, hannes@cmpxchg.org, lstoakes@gmail.com, akpm@linux-foundation.org, urezki@gmail.com, hch@infradead.org, rppt@kernel.org, boris.ostrovsky@oracle.com, sstabellini@kernel.org, jgross@suse.com, linux-mm@kvack.org, xen-devel@lists.xenproject.org, kernel-team@fb.com Subject: Re: [PATCH v4 bpf-next 2/2] mm: Introduce VM_SPARSE kind and vm_area_[un]map_pages(). Message-ID: References: <20240305030516.41519-1-alexei.starovoitov@gmail.com> <20240305030516.41519-3-alexei.starovoitov@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240305030516.41519-3-alexei.starovoitov@gmail.com> X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html I'd still prefer to hide the vm_area, but for now: Reviewed-by: Christoph Hellwig From xen-devel-bounces@lists.xenproject.org Wed Mar 06 14:56:49 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 14:56:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689351.1074211 (Exim 4.92) (envelope-from ) id 1rhshH-0003Uj-67; Wed, 06 Mar 2024 14:56:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689351.1074211; Wed, 06 Mar 2024 14:56:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhshH-0003Uc-3W; Wed, 06 Mar 2024 14:56:43 +0000 Received: by outflank-mailman (input) for mailman id 689351; Wed, 06 Mar 2024 14:56:41 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhshF-0003UR-NS for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 14:56:41 +0000 Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [2a00:1450:4864:20::531]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id bc9a7c9a-dbc9-11ee-afda-a90da7624cb6; Wed, 06 Mar 2024 15:56:40 +0100 (CET) Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-563c403719cso9272739a12.2 for ; Wed, 06 Mar 2024 06:56:40 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ew5-20020a056402538500b005667a11b951sm6991707edb.86.2024.03.06.06.56.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 Mar 2024 06:56:38 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: bc9a7c9a-dbc9-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709736999; x=1710341799; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=a+FsV5KipwWiSj0tYCsBmAK1zNB7m7w39dTAj0h3ue8=; b=egzTev5Iebe3WVIPMcIxcCBIfcL89bVVJBP+t3QS6J1r0fnI+jJali+T7lkYjKcYx4 wZD9lwA3ICCxPYvyo7Ksf6LDGANT6CPdE7a8z3UpLCF1c32yqwNHGX6779auypJwkbIz jfT7YdKWxf3leG01LO1LRBN7Pv87RNnMYr/gtgf7mk303CZn3h54uizfCro2qfbIQ900 8m1Gkm9S6riYAq5DGIlG47WxLczS86/wy/VBCbI26LAblI4riXUGlADXOiWZWH6FYgwl WxpOR29kSGqWYPuyElDZejRU96PFiXc1ZSMAqocz2oMjpU5RhZKmvRSFW1/XxITCPGAq TRsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709736999; x=1710341799; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=a+FsV5KipwWiSj0tYCsBmAK1zNB7m7w39dTAj0h3ue8=; b=OCprdWAKqgg5ltWlvSvFcvz1dJb9YMNvtURpO4PGJ6/PM5VwiWCGErvlm1+Q4RyZs7 hJhDa1LYGHjcli7YD3PVAd7jlqN1edz9Dj8YqFOTi8eLawkfE/EXE1Y4PM9i+tkHyZw2 x3xlLEmM7GY9nP31FAdv7SwWK/41Bu6GtKtZEtpsVJuKrNw5EiWnahaZZuyJZZeuMH/N R4zfRRIXcBypWPhB/R8+VI05T/rDdKy76TqGJ2bw5TRpi9wua+QmpAjEwNdrch1wX4Au x8lMmPXDLmrsU7AAewT9R8q1f5qrkT6PsT5d3ACLswYWQbQRY9hf/zlkg4YhhS4ZlvVA MuBg== X-Forwarded-Encrypted: i=1; AJvYcCWqs8y0fPEGOFS/Gu5iXZZXWXxrZE0kTnkgHKCExxb7Q3gyRBq/ys36CT+dE2Wz49L86ybbydd8t7QzLLSpFxfvkK2Tm6e2aFnOY+jTB2Q= X-Gm-Message-State: AOJu0Yw1ImwN6rJkWXJT+11A38JhA/xp2n2Uyic2sAskEdAl82d1VveD 5MXCqkAn13wnqKYF8XS5UdlS8joxStLRHniHol0aMH2ZsSmCDfYngl9svD2fTw== X-Google-Smtp-Source: AGHT+IHml87uJ/rAIQzOGtXxD1kb84yhDVUUgPf0CZYhVS7D1av1c41eVza4sys0BnbMm4fW5eFNzA== X-Received: by 2002:a50:cc8e:0:b0:566:1794:7b2 with SMTP id q14-20020a50cc8e000000b00566179407b2mr12584096edi.13.1709736998879; Wed, 06 Mar 2024 06:56:38 -0800 (PST) Message-ID: <23ff1c20-91f3-4c60-9562-7f1cd57c1043@suse.com> Date: Wed, 6 Mar 2024 15:56:37 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 11/23] xen/riscv: introduce cmpxchg.h Content-Language: en-US To: Oleksii Kurochko Cc: Alistair Francis , Bob Eshleman , Connor Davis , Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu , xen-devel@lists.xenproject.org References: From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 26.02.2024 18:38, Oleksii Kurochko wrote: > The header was taken from Linux kernl 6.4.0-rc1. > > Addionally, were updated: > * add emulation of {cmp}xchg for 1/2 byte types using 32-bit atomic > access. > * replace tabs with spaces > * replace __* variale with *__ > * introduce generic version of xchg_* and cmpxchg_*. > > Implementation of 4- and 8-byte cases were left as it is done in > Linux kernel as according to the RISC-V spec: > ``` > Table A.5 ( only part of the table was copied here ) > > Linux Construct RVWMO Mapping > atomic relaxed amo.{w|d} > atomic acquire amo.{w|d}.aq > atomic release amo.{w|d}.rl > atomic amo.{w|d}.aqrl > > Linux Construct RVWMO LR/SC Mapping > atomic relaxed loop: lr.{w|d}; ; sc.{w|d}; bnez loop > atomic acquire loop: lr.{w|d}.aq; ; sc.{w|d}; bnez loop > atomic release loop: lr.{w|d}; ; sc.{w|d}.aqrl∗ ; bnez loop OR > fence.tso; loop: lr.{w|d}; ; sc.{w|d}∗ ; bnez loop > atomic loop: lr.{w|d}.aq; ; sc.{w|d}.aqrl; bnez loop > > The Linux mappings for release operations may seem stronger than necessary, > but these mappings are needed to cover some cases in which Linux requires > stronger orderings than the more intuitive mappings would provide. > In particular, as of the time this text is being written, Linux is actively > debating whether to require load-load, load-store, and store-store orderings > between accesses in one critical section and accesses in a subsequent critical > section in the same hart and protected by the same synchronization object. > Not all combinations of FENCE RW,W/FENCE R,RW mappings with aq/rl mappings > combine to provide such orderings. > There are a few ways around this problem, including: > 1. Always use FENCE RW,W/FENCE R,RW, and never use aq/rl. This suffices > but is undesirable, as it defeats the purpose of the aq/rl modifiers. > 2. Always use aq/rl, and never use FENCE RW,W/FENCE R,RW. This does not > currently work due to the lack of load and store opcodes with aq and rl > modifiers. As before I don't understand this point. Can you give an example of what sort of opcode / instruction is missing? > 3. Strengthen the mappings of release operations such that they would > enforce sufficient orderings in the presence of either type of acquire mapping. > This is the currently-recommended solution, and the one shown in Table A.5. > ``` > > But in Linux kenrel atomics were strengthen with fences: > ``` > Atomics present the same issue with locking: release and acquire > variants need to be strengthened to meet the constraints defined > by the Linux-kernel memory consistency model [1]. > > Atomics present a further issue: implementations of atomics such > as atomic_cmpxchg() and atomic_add_unless() rely on LR/SC pairs, > which do not give full-ordering with .aqrl; for example, current > implementations allow the "lr-sc-aqrl-pair-vs-full-barrier" test > below to end up with the state indicated in the "exists" clause. > > In order to "synchronize" LKMM and RISC-V's implementation, this > commit strengthens the implementations of the atomics operations > by replacing .rl and .aq with the use of ("lightweigth") fences, > and by replacing .aqrl LR/SC pairs in sequences such as: > > 0: lr.w.aqrl %0, %addr > bne %0, %old, 1f > ... > sc.w.aqrl %1, %new, %addr > bnez %1, 0b > 1: > > with sequences of the form: > > 0: lr.w %0, %addr > bne %0, %old, 1f > ... > sc.w.rl %1, %new, %addr /* SC-release */ > bnez %1, 0b > fence rw, rw /* "full" fence */ > 1: > > following Daniel's suggestion. > > These modifications were validated with simulation of the RISC-V > memory consistency model. > > C lr-sc-aqrl-pair-vs-full-barrier > > {} > > P0(int *x, int *y, atomic_t *u) > { > int r0; > int r1; > > WRITE_ONCE(*x, 1); > r0 = atomic_cmpxchg(u, 0, 1); > r1 = READ_ONCE(*y); > } > > P1(int *x, int *y, atomic_t *v) > { > int r0; > int r1; > > WRITE_ONCE(*y, 1); > r0 = atomic_cmpxchg(v, 0, 1); > r1 = READ_ONCE(*x); > } > > exists (u=1 /\ v=1 /\ 0:r1=0 /\ 1:r1=0) While I'm entirely willing to trust this can happen, I can't bring this in line with the A extension spec. Additionally it's not clear to me in how far all of this applies when you don't really use LR/SC in the 4- and 8-byte cases (and going forward likely also not in the 1- and 2-byte case, utilizing Zahba when available). > --- > Changes in V5: > - update the commit message. > - drop ALIGN_DOWN(). > - update the definition of emulate_xchg_1_2(): > - lr.d -> lr.w, sc.d -> sc.w. > - drop ret argument. > - code style fixes around asm volatile. > - update prototype. > - use asm named operands. > - rename local variables. > - add comment above the macros > - update the definition of __xchg_generic: > - drop local ptr__ variable. > - code style fixes around switch() > - update prototype. > - introduce RISCV_FULL_BARRIES. > - redefine cmpxchg() > - update emulate_cmpxchg_1_2(): > - update prototype > - update local variables names and usage of them > - use name asm operands. > - add comment above the macros > --- > Changes in V4: > - Code style fixes. > - enforce in __xchg_*() has the same type for new and *ptr, also "\n" > was removed at the end of asm instruction. > - dependency from https://lore.kernel.org/xen-devel/cover.1706259490.git.federico.serafini@bugseng.com/ > - switch from ASSERT_UNREACHABLE to STATIC_ASSERT_UNREACHABLE(). > - drop xchg32(ptr, x) and xchg64(ptr, x) as they aren't used. > - drop cmpxcg{32,64}_{local} as they aren't used. > - introduce generic version of xchg_* and cmpxchg_*. > - update the commit message. > --- > Changes in V3: > - update the commit message > - add emulation of {cmp}xchg_... for 1 and 2 bytes types > --- > Changes in V2: > - update the comment at the top of the header. > - change xen/lib.h to xen/bug.h. > - sort inclusion of headers properly. > --- > xen/arch/riscv/include/asm/cmpxchg.h | 258 +++++++++++++++++++++++++++ > 1 file changed, 258 insertions(+) > create mode 100644 xen/arch/riscv/include/asm/cmpxchg.h > > diff --git a/xen/arch/riscv/include/asm/cmpxchg.h b/xen/arch/riscv/include/asm/cmpxchg.h > new file mode 100644 > index 0000000000..66cbe26737 > --- /dev/null > +++ b/xen/arch/riscv/include/asm/cmpxchg.h > @@ -0,0 +1,258 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +/* Copyright (C) 2014 Regents of the University of California */ > + > +#ifndef _ASM_RISCV_CMPXCHG_H > +#define _ASM_RISCV_CMPXCHG_H > + > +#include > +#include > + > +#include > +#include > +#include > + > +#define __amoswap_generic(ptr, new, ret, sfx, pre, post) \ > +({ \ > + asm volatile( \ Nit: In Xen style this is lacking a blank ahead of the opening parenthesis. > + pre \ > + " amoswap" sfx " %0, %2, %1\n" \ > + post \ > + : "=r" (ret), "+A" (*ptr) \ > + : "r" (new) \ > + : "memory" ); \ > +}) > + > +/* > + * For LR and SC, the A extension requires that the address held in rs1 be > + * naturally aligned to the size of the operand (i.e., eight-byte aligned > + * for 64-bit words and four-byte aligned for 32-bit words). > + * If the address is not naturally aligned, an address-misaligned exception > + * or an access-fault exception will be generated. > + * > + * Thereby: > + * - for 1-byte xchg access the containing word by clearing low two bits > + * - for 2-byte xchg ccess the containing word by clearing first bit. "first bit" can still be ambiguous. Better say "bit 1". > + * Here and apparently also elsewhere: Stray trailing blank. Git has a config setting to warn you about (maybe even to automatically strip? such. > + * If resulting 4-byte access is still misalgined, it will fault just as > + * non-emulated 4-byte access would. > + */ > +#define emulate_xchg_1_2(ptr, new, sc_sfx, pre, post) \ > +({ \ > + uint32_t *aligned_ptr = (uint32_t *)((unsigned long)ptr & ~(0x4 - sizeof(*ptr))); \ Here and elsewhere: sizeof(*(ptr)) (i.e. the inner parentheses are needed also there). > + uint8_t new_val_pos = ((unsigned long)(ptr) & (0x4 - sizeof(*ptr))) * BITS_PER_BYTE; \ Why uint8_t? > + unsigned long mask = GENMASK(((sizeof(*ptr)) * BITS_PER_BYTE) - 1, 0) << new_val_pos; \ > + unsigned int new_ = new << new_val_pos; \ > + unsigned int old_val; \ > + unsigned int xchged_val; \ > + \ > + asm volatile ( \ > + pre \ > + "0: lr.w %[op_oldval], %[op_aligned_ptr]\n" \ > + " and %[op_xchged_val], %[op_oldval], %z[op_nmask]\n" \ > + " or %[op_xchged_val], %[op_xchged_val], %z[op_new]\n" \ > + " sc.w" sc_sfx " %[op_xchged_val], %[op_xchged_val], %[op_aligned_ptr]\n" \ > + " bnez %[op_xchged_val], 0b\n" \ > + post \ > + : [op_oldval] "=&r" (old_val), [op_xchged_val] "=&r" (xchged_val), [op_aligned_ptr]"+A" (*aligned_ptr) \ Too long line. Partly because you have op_ prefixes here which I can't recognized what they would be good for. The val / _val suffixes also don't appear to carry much useful information. And "xchged", being explicitly past tense, doesn't look to fit even up and until the SC, not to speak of afterwards. Anything wrong with calling this just tmp, aux, or scratch? > + : [op_new] "rJ" (new_), [op_nmask] "rJ" (~mask) \ > + : "memory" ); \ > + \ > + (__typeof__(*(ptr)))((old_val & mask) >> new_val_pos); \ > +}) > + > +#define __xchg_generic(ptr, new, size, sfx, pre, post) \ > +({ \ > + __typeof__(*(ptr)) new__ = (new); \ > + __typeof__(*(ptr)) ret__; \ > + switch ( size ) \ Can't this use sizeof(*(ptr)), allowing for one less macro parameter? > + { \ > + case 1: \ > + case 2: \ > + ret__ = emulate_xchg_1_2(ptr, new__, sfx, pre, post); \ > + break; \ > + case 4: \ > + __amoswap_generic(ptr, new__, ret__,\ > + ".w" sfx, pre, post); \ > + break; \ > + case 8: \ > + __amoswap_generic(ptr, new__, ret__,\ > + ".d" sfx, pre, post); \ > + break; \ In io.h you make sure to avoid rv64-only insns. Here you don't. The build would fail either way, but this still looks inconsistent. Also nit: Stray double blands (twice) ahead of "pre". Plus with this style of line continuation you want to consistently have exactly one blank ahead of each backslash. > + default: \ > + STATIC_ASSERT_UNREACHABLE(); \ > + } \ > + ret__; \ > +}) > + > +#define xchg_relaxed(ptr, x) \ > +({ \ > + __typeof__(*(ptr)) x_ = (x); \ What is the purpose of this, when __xchg_generic() already does this same type conversion? > + (__typeof__(*(ptr)))__xchg_generic(ptr, x_, sizeof(*(ptr)), "", "", ""); \ > +}) > + > +#define xchg_acquire(ptr, x) \ > +({ \ > + __typeof__(*(ptr)) x_ = (x); \ > + (__typeof__(*(ptr)))__xchg_generic(ptr, x_, sizeof(*(ptr)), \ > + "", "", RISCV_ACQUIRE_BARRIER); \ > +}) > + > +#define xchg_release(ptr, x) \ > +({ \ > + __typeof__(*(ptr)) x_ = (x); \ > + (__typeof__(*(ptr)))__xchg_generic(ptr, x_, sizeof(*(ptr)),\ > + "", RISCV_RELEASE_BARRIER, ""); \ > +}) As asked before: Are there going to be any uses of these three? Common code doesn't require them. And not needing to provide them would simplify things quite a bit, it seems. > +#define xchg(ptr, x) __xchg_generic(ptr, (unsigned long)(x), sizeof(*(ptr)), \ > + ".aqrl", "", "") According to the earlier comment (where I don't follow the example given), is .aqrl sufficient here? And even if it was for the 4- and 8-byte cases, is it sufficient in the 1- and 2-byte emulation case (where it then is appended to just the SC)? > +#define __generic_cmpxchg(ptr, old, new, ret, lr_sfx, sc_sfx, pre, post) \ > + ({ \ > + register unsigned int rc; \ > + asm volatile( \ > + pre \ > + "0: lr" lr_sfx " %0, %2\n" \ > + " bne %0, %z3, 1f\n" \ > + " sc" sc_sfx " %1, %z4, %2\n" \ > + " bnez %1, 0b\n" \ > + post \ > + "1:\n" \ > + : "=&r" (ret), "=&r" (rc), "+A" (*ptr) \ > + : "rJ" (old), "rJ" (new) \ > + : "memory"); \ > + }) > + > +/* > + * For LR and SC, the A extension requires that the address held in rs1 be > + * naturally aligned to the size of the operand (i.e., eight-byte aligned > + * for 64-bit words and four-byte aligned for 32-bit words). > + * If the address is not naturally aligned, an address-misaligned exception > + * or an access-fault exception will be generated. > + * > + * Thereby: > + * - for 1-byte xchg access the containing word by clearing low two bits > + * - for 2-byte xchg ccess the containing word by clearing first bit. > + * > + * If resulting 4-byte access is still misalgined, it will fault just as > + * non-emulated 4-byte access would. > + * > + * old_val was casted to unsigned long at the end of the define because of > + * the following issue: > + * ./arch/riscv/include/asm/cmpxchg.h:166:5: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] > + * 166 | (__typeof__(*(ptr)))(old_val >> new_val_pos); \ > + * | ^ > + * ./arch/riscv/include/asm/cmpxchg.h:184:17: note: in expansion of macro 'emulate_cmpxchg_1_2' > + * 184 | ret__ = emulate_cmpxchg_1_2(ptr, old, new, \ > + * | ^~~~~~~~~~~~~~~~~~~ > + * ./arch/riscv/include/asm/cmpxchg.h:227:5: note: in expansion of macro '__cmpxchg_generic' > + * 227 | __cmpxchg_generic(ptr, (unsigned long)(o), (unsigned long)(n), \ > + * | ^~~~~~~~~~~~~~~~~ > + * ./include/xen/lib.h:141:26: note: in expansion of macro '__cmpxchg' > + * 141 | ((__typeof__(*(ptr)))__cmpxchg(ptr, (unsigned long)o_, \ > + * | ^~~~~~~~~ > + * common/event_channel.c:109:13: note: in expansion of macro 'cmpxchgptr' > + * 109 | cmpxchgptr(&xen_consumers[i], NULL, fn); > + */ This is too much detail on the compile issue. Just mentioning that said cast is needed for cmpxchgptr() ought to be sufficient. > +#define emulate_cmpxchg_1_2(ptr, old, new, sc_sfx, pre, post) \ > +({ \ > + uint32_t *aligned_ptr = (uint32_t *)((unsigned long)ptr & ~(0x4 - sizeof(*ptr))); \ > + uint8_t new_val_pos = ((unsigned long)(ptr) & (0x4 - sizeof(*ptr))) * BITS_PER_BYTE; \ > + unsigned long mask = GENMASK(((sizeof(*ptr)) * BITS_PER_BYTE) - 1, 0) << new_val_pos; \ > + unsigned int old_ = old << new_val_pos; \ > + unsigned int new_ = new << new_val_pos; \ > + unsigned int old_val; \ > + unsigned int xchged_val; \ > + \ > + __asm__ __volatile__ ( \ > + pre \ > + "0: lr.w %[op_xchged_val], %[op_aligned_ptr]\n" \ > + " and %[op_oldval], %[op_xchged_val], %z[op_mask]\n" \ > + " bne %[op_oldval], %z[op_old], 1f\n" \ > + " xor %[op_xchged_val], %[op_oldval], %[op_xchged_val]\n" \ > + " or %[op_xchged_val], %[op_xchged_val], %z[op_new]\n" \ > + " sc.w" sc_sfx " %[op_xchged_val], %[op_xchged_val], %[op_aligned_ptr]\n" \ > + " bnez %[op_xchged_val], 0b\n" \ > + post \ > + "1:\n" \ > + : [op_oldval] "=&r" (old_val), [op_xchged_val] "=&r" (xchged_val), [op_aligned_ptr] "+A" (*aligned_ptr) \ > + : [op_old] "rJ" (old_), [op_new] "rJ" (new_), \ > + [op_mask] "rJ" (mask) \ > + : "memory" ); \ > + \ > + (__typeof__(*(ptr)))((unsigned long)old_val >> new_val_pos); \ > +}) > + > +/* > + * Atomic compare and exchange. Compare OLD with MEM, if identical, > + * store NEW in MEM. Return the initial value in MEM. Success is > + * indicated by comparing RETURN with OLD. > + */ > +#define __cmpxchg_generic(ptr, old, new, size, sc_sfx, pre, post) \ > +({ \ > + __typeof__(ptr) ptr__ = (ptr); \ > + __typeof__(*(ptr)) old__ = (__typeof__(*(ptr)))(old); \ > + __typeof__(*(ptr)) new__ = (__typeof__(*(ptr)))(new); \ > + __typeof__(*(ptr)) ret__; \ > + switch ( size ) \ > + { \ > + case 1: \ > + case 2: \ > + ret__ = emulate_cmpxchg_1_2(ptr, old, new, \ > + sc_sfx, pre, post); \ > + break; \ > + case 4: \ > + __generic_cmpxchg(ptr__, old__, new__, ret__, \ > + ".w", ".w"sc_sfx, pre, post); \ > + break; \ > + case 8: \ > + __generic_cmpxchg(ptr__, old__, new__, ret__, \ > + ".d", ".d"sc_sfx, pre, post); \ > + break; \ > + default: \ > + STATIC_ASSERT_UNREACHABLE(); \ > + } \ > + ret__; \ > +}) > + > +#define cmpxchg_relaxed(ptr, o, n) \ > +({ \ > + __typeof__(*(ptr)) o_ = (o); \ > + __typeof__(*(ptr)) n_ = (n); \ > + (__typeof__(*(ptr)))__cmpxchg_generic(ptr, \ > + o_, n_, sizeof(*(ptr)), "", "", ""); \ > +}) > + > +#define cmpxchg_acquire(ptr, o, n) \ > +({ \ > + __typeof__(*(ptr)) o_ = (o); \ > + __typeof__(*(ptr)) n_ = (n); \ > + (__typeof__(*(ptr)))__cmpxchg_generic(ptr, o_, n_, sizeof(*(ptr)), \ > + "", "", RISCV_ACQUIRE_BARRIER); \ > +}) > + > +#define cmpxchg_release(ptr, o, n) \ > +({ \ > + __typeof__(*(ptr)) o_ = (o); \ > + __typeof__(*(ptr)) n_ = (n); \ > + (__typeof__(*(ptr)))__cmpxchg_release(ptr, o_, n_, sizeof(*(ptr)), \ There's no __cmpxchg_release() afaics; dym __cmpxchg_generic()? Jan From xen-devel-bounces@lists.xenproject.org Wed Mar 06 14:57:21 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 14:57:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689354.1074222 (Exim 4.92) (envelope-from ) id 1rhsht-00042P-Ij; Wed, 06 Mar 2024 14:57:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689354.1074222; Wed, 06 Mar 2024 14:57:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhsht-00042I-G2; Wed, 06 Mar 2024 14:57:21 +0000 Received: by outflank-mailman (input) for mailman id 689354; Wed, 06 Mar 2024 14:57:20 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhshs-0003UR-II for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 14:57:20 +0000 Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [2a00:1450:4864:20::22b]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id d4a8e4a3-dbc9-11ee-afda-a90da7624cb6; Wed, 06 Mar 2024 15:57:19 +0100 (CET) Received: by mail-lj1-x22b.google.com with SMTP id 38308e7fff4ca-2d26227d508so11848141fa.2 for ; Wed, 06 Mar 2024 06:57:19 -0800 (PST) Received: from perard.uk.xensource.com (default-46-102-197-194.interdsl.co.uk. [46.102.197.194]) by smtp.gmail.com with ESMTPSA id r20-20020a2e9954000000b002d0c639e0cesm2642861ljj.6.2024.03.06.06.57.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Mar 2024 06:57:18 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d4a8e4a3-dbc9-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709737039; x=1710341839; darn=lists.xenproject.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=7/XM4P7Alhhd7zvbUIu8Gj2raXXBnYs05DM7NQFx5MM=; b=dZIlBbqlB9GwP9zOieORvITTwlmcRWs2hrcG4Z+nlCiiFPhymYydNNIrBKD1/wniU+ /u4KKJ9Wm8RbMzG4jqfcYq2cB/mchhwVzWqVsJuX1E6IpezQ908kLEULzu7NONtnQlA9 I126pXqN6VEDLr9AmCKWmJe887Wk4KbPXAf/8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709737039; x=1710341839; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=7/XM4P7Alhhd7zvbUIu8Gj2raXXBnYs05DM7NQFx5MM=; b=aeecx84tcwEAZiPgAXMI1TPHLQ85gdttepQ8mywcO6qgsmgKtG4RdJsov69Ym4MNly nKvNMQatkHEiNyiR8VF+sm0rM/49TaPOeoQwvIru66sfwgKfjSjZPhJWV15GJBKrvEiC f7Piw1Prv49LoFBF0qtBs3s0jnZaxCqOsvCTDTJWHQ0bj6NcvXWmcY3ELFArbRX6FV+K 0PzAfXFNIJ35D81KYOgEqpAzSqY9canv1P56UYBgE92OCuMNhL4OJF4hO2U9h6gil87y wKZo+/HuWvoJ3URqUWyYyAnyLRKjgYbtGK0mr2F0LnaVdhYqU3iJjkEbyEb5ocJjW8Yd wZ4w== X-Gm-Message-State: AOJu0YzFL0ZGjaa57688yC4bvXleZBf/XxjJrdd/nANPbF7toJSUaG4R jKdl+TW64s02NRM6JTVMfTMEb4UdFeUTc9LR95dp6eLzHYi+/NtcRS/+G1v0Ips= X-Google-Smtp-Source: AGHT+IGtvwiwfwdF+WjLiGUe2rUDed0eMWODyVNEtdnjb7iwzddijS9zgTAj2V+jfK+gpkFH8RJ0sA== X-Received: by 2002:a2e:9f48:0:b0:2d2:66bf:2c1d with SMTP id v8-20020a2e9f48000000b002d266bf2c1dmr3848771ljk.2.1709737039235; Wed, 06 Mar 2024 06:57:19 -0800 (PST) Date: Wed, 6 Mar 2024 14:57:16 +0000 From: Anthony PERARD To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , George Dunlap , Wei Liu , Roger Pau =?iso-8859-1?Q?Monn=E9?= Subject: Re: [PATCH 1/2] x86/EFI: correct compiler probing Message-ID: <9e26c1f2-add7-430b-9ba7-cce54d863955@perard> References: <089964f2-1b2c-4ee7-92cf-f50f2e967d5b@suse.com> <7f0d8e16-c580-4dba-a81a-72d5334052dc@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7f0d8e16-c580-4dba-a81a-72d5334052dc@suse.com> On Thu, Dec 07, 2023 at 11:48:12AM +0100, Jan Beulich wrote: > Passing in $(CFLAGS) means also requesting inclusion of certain headers > (via -include command line options). That's particularly xen/config.h, > which in turn requires generated/autoconf.h. This has not caused any > problems so far only because arch.mk is processed twice, and the missing The first pass is ignore because "include/config/auto.conf" is missing, and generating that will also generates "generated/autoconf.h" I think. So result don't matter, and make restart from scratch once "auto.conf" is generated. > header on the 1st pass would be there on the 2nd. Having added an > inclusion of asm/asm-macros.h to x86'es asm/config.h, the 2nd pass then I don't see asm-macros.h been included in asm/config.h, is this in a pending patch? > also fails on an initial, pristine build. > > As per dd40177c1bc8 ("x86-64/EFI: add CFLAGS to check compile") dropping > the use of $(CFLAGS) altogether isn't an option, though. Hence remove > the problematic options only. > > Signed-off-by: Jan Beulich In any case, patch looks fine: Reviewed-by: Anthony PERARD > --- > This is now the 3rd place where the -include needs dropping. I was half > decided to introduce a new lazy-expansion variable, yet it's not > consistently $(CFLAGS) that the options need purging from. Thoughts? Something like that I guess, we probably want to avoid the "-include" while testing the compiler. I guess introducing "-include config.h" once we have all CFLAGS might make more sense, that is at about the time where XEN_CFLAGS is currently introduced, but I haven't checked if that's fine to do. Cheers, -- Anthony PERARD From xen-devel-bounces@lists.xenproject.org Wed Mar 06 14:57:42 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 14:57:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689355.1074232 (Exim 4.92) (envelope-from ) id 1rhsiE-0004Xn-Rf; Wed, 06 Mar 2024 14:57:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689355.1074232; Wed, 06 Mar 2024 14:57:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhsiE-0004Xg-OF; Wed, 06 Mar 2024 14:57:42 +0000 Received: by outflank-mailman (input) for mailman id 689355; Wed, 06 Mar 2024 14:57:41 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhsiD-0003UR-FQ for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 14:57:41 +0000 Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [2a00:1450:4864:20::12b]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id e12f3e17-dbc9-11ee-afda-a90da7624cb6; Wed, 06 Mar 2024 15:57:40 +0100 (CET) Received: by mail-lf1-x12b.google.com with SMTP id 2adb3069b0e04-513181719easo5058917e87.3 for ; Wed, 06 Mar 2024 06:57:40 -0800 (PST) Received: from perard.uk.xensource.com (default-46-102-197-194.interdsl.co.uk. [46.102.197.194]) by smtp.gmail.com with ESMTPSA id o6-20020ac24bc6000000b0051357109ac6sm655578lfq.285.2024.03.06.06.57.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Mar 2024 06:57:39 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e12f3e17-dbc9-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1709737060; x=1710341860; darn=lists.xenproject.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=AkU99RQm0D8QAcmE/0JdPnQp0d5kBtsxpW2db+mpxqU=; b=VkWMaujaqiAl1CzP9hgMo7Z1hPvQAoN1/+inrH354bVm7H0yHrVpifiLn5cNvxT2X7 JFiP4aFV3Tn3/XWClX/yFKzwts8JuD0HKdj/3p1Oe+O7LXEXF6RxBjRCG93/aZy1Qz4w +zPgo4xFC0axYXxwE24LedNXLMttTg06ZS/Lw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709737060; x=1710341860; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=AkU99RQm0D8QAcmE/0JdPnQp0d5kBtsxpW2db+mpxqU=; b=IKbX8fcPms0DXdYIocJmvPf/yG3U6Nasj3EjRBvM3KHuIHy4cDT5dyaN/BoiqcAMYD Ug2mt8yNUJS36uUce1G90T3aAFLMH5BKeuPT8KcS1BMhGH9Ppd0uKb0gzOmK+mqugsCv nFhNbp5bZpGPIbUXjswXPe2MsPCdfLEd9XO0Xlhhmh2LHYFlJpYOGqgGORB3NiXteLo7 nPobWyCnd5b6UXF2ygyGceF9UZc6apzAQpgpqhsFOr8UVdUpA4DxEmgGaJ+Gul4i4Owq wPOe3xTfl33mqUI3EajPCmkwh49HBjJ21sClSeeqFl5wyR3lWGq+8YNRJZ5mrePj7oLt 4GdA== X-Gm-Message-State: AOJu0YySJeEyNMWJLMZljC11+UiZSjlMkIwOmK70xJnIU65/qanhr9OL 7Sy21Y60WKmFUAEAkakCDpwUcX1KPGFsdIqcXYZq6sbQfYn1AJ54YkpaUI09CI0= X-Google-Smtp-Source: AGHT+IFLPh00ZEJr+NAP9NsmNiHP/Db2TyelAP2m2+Rjl2brrhXwhkYfbDDmdaYxzfHLepT7v31OFA== X-Received: by 2002:a05:6512:39cd:b0:513:46cc:8966 with SMTP id k13-20020a05651239cd00b0051346cc8966mr4626055lfu.2.1709737060404; Wed, 06 Mar 2024 06:57:40 -0800 (PST) Date: Wed, 6 Mar 2024 14:57:38 +0000 From: Anthony PERARD To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu , Roger Pau =?iso-8859-1?Q?Monn=E9?= Subject: Re: [PATCH 2/2] Kbuild: simplify as-insn a little Message-ID: <4e090535-c31e-47f6-a560-047fb36aff3e@perard> References: <089964f2-1b2c-4ee7-92cf-f50f2e967d5b@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Thu, Dec 07, 2023 at 11:49:04AM +0100, Jan Beulich wrote: > As of 732571959f17 ("xen/build: use new $(c_flags) and $(a_flags) > instead of $(CFLAGS)") -M options aren't part of CFLAGS anymore, and > c_flags isn't supposed to be passed to this macro. Drop the now dead > part of filtering. > > Signed-off-by: Jan Beulich Reviewed-by: Anthony PERARD Thanks, -- Anthony PERARD From xen-devel-bounces@lists.xenproject.org Wed Mar 06 14:58:56 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 14:58:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689358.1074242 (Exim 4.92) (envelope-from ) id 1rhsjO-0005IW-75; Wed, 06 Mar 2024 14:58:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689358.1074242; Wed, 06 Mar 2024 14:58:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhsjO-0005IP-26; Wed, 06 Mar 2024 14:58:54 +0000 Received: by outflank-mailman (input) for mailman id 689358; Wed, 06 Mar 2024 14:58:53 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhsjN-0005I9-6a for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 14:58:53 +0000 Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [2a00:1450:4864:20::52f]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 0bad324f-dbca-11ee-afda-a90da7624cb6; Wed, 06 Mar 2024 15:58:52 +0100 (CET) Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-5645960cd56so2722183a12.1 for ; Wed, 06 Mar 2024 06:58:52 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id h26-20020aa7c95a000000b005663b0d7243sm6988183edt.83.2024.03.06.06.58.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 Mar 2024 06:58:51 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 0bad324f-dbca-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709737132; x=1710341932; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=9ozENvJB1pApgplskxvvlfAp50T1YuHiVXxE9PWgha0=; b=NZQyXYn67TrWpUdDIkamBrMQv+A7QSsa7mRjudZSMGlUYL2gYF7bHnq+a5KSOzerIp DpbBZbmirIqxAiIIvu1d2Y9m27MSOIJUGIiLnONZtqfIHaMZ7MIcK6bnuGKhsgxTPdfa RzM6z3Npb44cPG3HP/VJEnZbTzBnAU4X5dmh2DNEqzqtJk0RMPkKtVOLyDBituMYY/Xk pC0t3mVXCRnRNO2sQcsjVymwykwb7A+LQW/A+DwvVdsVEAIgR49/ZunPeefOGfLGkFpN ixdvnMH2iruOVH9ckXgxpwPIiRqknm/VHmXoZnPHBkTDv/KcZY+RVqsBg8ra4wDcW9KO +8vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709737132; x=1710341932; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=9ozENvJB1pApgplskxvvlfAp50T1YuHiVXxE9PWgha0=; b=ZT+qL/xoJ01V88WtKE/q4UCbEsCL+jMwfmHZUec/v6EFDA768Nuu0ifEbJSrbuUwI9 63AfespDLEhh2d7fhcMQ5lojs19OHlObMR9REDVMwVAbZ8jC5jSCwdwzAaKLDD8LHqwt 87QHSlyAR3m2nhGCZSX2v0db3jIUQaxYApY5LQIBSqoC4L3fFw9S8G4SetVWpcj9hVUz 3kOj7nrnC6VGzZ5ghjVKzaQI9YzRKJJSaVk5DFmoIbz6f0UT3DmwC1HwWMNO/sq48jgq UYhOeS2gM5gJ940fkKbZV3P995nG8tON+4K0xrr0m8gkuuQctP8H4Bt3G+pXnebkFvR4 U8fQ== X-Gm-Message-State: AOJu0YzJ/pri/nwfZNtTG3eNpZh8IAeSZ7txk0G0kenbMP3yCR408uvo nA32RM982qksQzYpedffn56K6wWvHIAmjpTvY4DuXndG+3AojOKnguPhh+TjjQ== X-Google-Smtp-Source: AGHT+IGLlbBnXGhePH/rCXWTqnxwoic4snkgPKinTAvbGqDUnO/jjhjzX7JV0ISZXo4Fwn+Iyy+qWA== X-Received: by 2002:a05:6402:2151:b0:566:6a0e:7625 with SMTP id bq17-20020a056402215100b005666a0e7625mr10374439edb.7.1709737131772; Wed, 06 Mar 2024 06:58:51 -0800 (PST) Message-ID: <7dd25eae-64ba-46d2-8dc1-5c697774102d@suse.com> Date: Wed, 6 Mar 2024 15:58:50 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] x86/EFI: correct compiler probing Content-Language: en-US To: Anthony PERARD Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , George Dunlap , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <089964f2-1b2c-4ee7-92cf-f50f2e967d5b@suse.com> <7f0d8e16-c580-4dba-a81a-72d5334052dc@suse.com> <9e26c1f2-add7-430b-9ba7-cce54d863955@perard> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <9e26c1f2-add7-430b-9ba7-cce54d863955@perard> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 06.03.2024 15:57, Anthony PERARD wrote: > On Thu, Dec 07, 2023 at 11:48:12AM +0100, Jan Beulich wrote: >> Passing in $(CFLAGS) means also requesting inclusion of certain headers >> (via -include command line options). That's particularly xen/config.h, >> which in turn requires generated/autoconf.h. This has not caused any >> problems so far only because arch.mk is processed twice, and the missing > > The first pass is ignore because "include/config/auto.conf" is missing, > and generating that will also generates "generated/autoconf.h" I think. > So result don't matter, and make restart from scratch once "auto.conf" > is generated. > >> header on the 1st pass would be there on the 2nd. Having added an >> inclusion of asm/asm-macros.h to x86'es asm/config.h, the 2nd pass then > > I don't see asm-macros.h been included in asm/config.h, is this > in a pending patch? Yes. I hoped to get this across with "Having added ...". >> also fails on an initial, pristine build. >> >> As per dd40177c1bc8 ("x86-64/EFI: add CFLAGS to check compile") dropping >> the use of $(CFLAGS) altogether isn't an option, though. Hence remove >> the problematic options only. >> >> Signed-off-by: Jan Beulich > > In any case, patch looks fine: > Reviewed-by: Anthony PERARD Thanks. Jan From xen-devel-bounces@lists.xenproject.org Wed Mar 06 15:11:56 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 15:11:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689369.1074251 (Exim 4.92) (envelope-from ) id 1rhsvt-0000XZ-9K; Wed, 06 Mar 2024 15:11:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689369.1074251; Wed, 06 Mar 2024 15:11:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhsvt-0000XS-6m; Wed, 06 Mar 2024 15:11:49 +0000 Received: by outflank-mailman (input) for mailman id 689369; Wed, 06 Mar 2024 15:11:47 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhsvr-0000XI-Ma; Wed, 06 Mar 2024 15:11:47 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhsvr-0001jj-K5; Wed, 06 Mar 2024 15:11:47 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhsvr-0005jO-8Y; Wed, 06 Mar 2024 15:11:47 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rhsvr-00015V-81; Wed, 06 Mar 2024 15:11:47 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=8wq6X3ZqizdjBqnvkd8yxXYVdy8o8g/oe/Zh3nIL3G0=; b=GralKr0iUEqqWBkLMT2XW0jP6W eXpgfLEZFu67A5WWiidnLx5axjmmhpQYKyWhGYgNvsZ6Sr9QVJZC8ny+mo35D2vVhGiCkvpqAFsnO dJUVCi3xEVW3n72zgvqQbLJSPo+epURpZjiz2iK3PzCZ35POpoBAmjVWXAzJWtJpQywU=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-linus test] 184917: regressions - FAIL X-Osstest-Failures: linux-linus:build-arm64:xen-build:fail:regression linux-linus:test-arm64-arm64-examine:build-check(1):blocked:nonblocking linux-linus:build-arm64-libvirt:build-check(1):blocked:nonblocking linux-linus:test-arm64-arm64-libvirt-raw:build-check(1):blocked:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking linux-linus:test-arm64-arm64-xl:build-check(1):blocked:nonblocking linux-linus:test-arm64-arm64-xl-credit1:build-check(1):blocked:nonblocking linux-linus:test-arm64-arm64-xl-credit2:build-check(1):blocked:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:build-check(1):blocked:nonblocking linux-linus:test-arm64-arm64-xl-vhd:build-check(1):blocked:nonblocking linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: linux=5847c9777c303a792202c609bd761dceb60f4eed X-Osstest-Versions-That: linux=29cd507cbec282e13dcf8f38072a100af96b2bb7 From: osstest service owner Date: Wed, 06 Mar 2024 15:11:47 +0000 flight 184917 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/184917/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 6 xen-build fail REGR. vs. 184912 Tests which did not succeed, but are not blocking: test-arm64-arm64-examine 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-raw 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit1 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-thunderx 1 build-check(1) blocked n/a test-arm64-arm64-xl-vhd 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop fail like 184912 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop fail like 184912 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop fail like 184912 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 184912 test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail like 184912 test-armhf-armhf-libvirt 16 saverestore-support-check fail like 184912 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop fail like 184912 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184912 test-amd64-amd64-libvirt-xsm 15 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 15 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 15 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qcow2 14 migrate-support-check fail never pass test-amd64-amd64-libvirt-raw 14 migrate-support-check fail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-libvirt 15 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-check fail never pass version targeted for testing: linux 5847c9777c303a792202c609bd761dceb60f4eed baseline version: linux 29cd507cbec282e13dcf8f38072a100af96b2bb7 Last test of basis 184912 2024-03-05 21:44:46 Z 0 days Testing same since 184917 2024-03-06 08:16:51 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Kamalesh Babulal Linus Torvalds Tejun Heo Waiman Long jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 fail build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt blocked build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl blocked test-armhf-armhf-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm blocked test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-amd64-dom0pvh-xl-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-freebsd11-amd64 pass test-amd64-amd64-freebsd12-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-examine-bios pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 blocked test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 blocked test-armhf-armhf-xl-credit2 pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine blocked test-armhf-armhf-examine pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-amd64-dom0pvh-xl-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-amd64-xl-pvshim pass test-amd64-amd64-pygrub pass test-amd64-amd64-libvirt-qcow2 pass test-armhf-armhf-libvirt-qcow2 pass test-amd64-amd64-libvirt-raw pass test-arm64-arm64-libvirt-raw blocked test-armhf-armhf-libvirt-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-arm64-arm64-xl-thunderx blocked test-amd64-amd64-examine-uefi pass test-amd64-amd64-xl-vhd pass test-arm64-arm64-xl-vhd blocked test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these 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 5847c9777c303a792202c609bd761dceb60f4eed Merge: 29cd507cbec2 25125a476283 Author: Linus Torvalds Date: Tue Mar 5 14:00:22 2024 -0800 Merge tag 'cgroup-for-6.8-rc7-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup Pull cgroup fixes from Tejun Heo: "Two cpuset fixes. Both are for bugs in error handling paths and low risk" * tag 'cgroup-for-6.8-rc7-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup: cgroup/cpuset: Fix retval in update_cpumask() cgroup/cpuset: Fix a memory leak in update_exclusive_cpumask() commit 25125a4762835d62ba1e540c1351d447fc1f6c7c Author: Kamalesh Babulal Date: Thu Feb 29 15:41:14 2024 +0530 cgroup/cpuset: Fix retval in update_cpumask() The update_cpumask(), checks for newly requested cpumask by calling validate_change(), which returns an error on passing an invalid set of cpu(s). Independent of the error returned, update_cpumask() always returns zero, suppressing the error and returning success to the user on writing an invalid cpu range for a cpuset. Fix it by returning retval instead, which is returned by validate_change(). Fixes: 99fe36ba6fc1 ("cgroup/cpuset: Improve temporary cpumasks handling") Signed-off-by: Kamalesh Babulal Reviewed-by: Waiman Long Cc: stable@vger.kernel.org # v6.6+ Signed-off-by: Tejun Heo commit 66f40b926dd249f74334a22162c09e7ec1ec5b07 Author: Waiman Long Date: Tue Feb 27 19:58:01 2024 -0500 cgroup/cpuset: Fix a memory leak in update_exclusive_cpumask() Fix a possible memory leak in update_exclusive_cpumask() by moving the alloc_cpumasks() down after the validate_change() check which can fail and still before the temporary cpumasks are needed. Fixes: e2ffe502ba45 ("cgroup/cpuset: Add cpuset.cpus.exclusive for v2") Reported-and-tested-by: Mirsad Todorovac Closes: https://lore.kernel.org/lkml/14915689-27a3-4cd8-80d2-9c30d0c768b6@alu.unizg.hr Signed-off-by: Waiman Long Signed-off-by: Tejun Heo Cc: stable@vger.kernel.org # v6.7+ From xen-devel-bounces@lists.xenproject.org Wed Mar 06 15:32:18 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 15:32:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689377.1074261 (Exim 4.92) (envelope-from ) id 1rhtFT-0004P4-0X; Wed, 06 Mar 2024 15:32:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689377.1074261; Wed, 06 Mar 2024 15:32:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhtFS-0004Ox-U5; Wed, 06 Mar 2024 15:32:02 +0000 Received: by outflank-mailman (input) for mailman id 689377; Wed, 06 Mar 2024 15:32:01 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhtFR-0004Or-6T for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 15:32:01 +0000 Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [2a00:1450:4864:20::62d]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id ac484a6f-dbce-11ee-afda-a90da7624cb6; Wed, 06 Mar 2024 16:31:59 +0100 (CET) Received: by mail-ej1-x62d.google.com with SMTP id a640c23a62f3a-a45bdf6e9c2so81000066b.0 for ; Wed, 06 Mar 2024 07:31:59 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id h17-20020a1709063c1100b00a42da3b6518sm7349399ejg.18.2024.03.06.07.31.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 Mar 2024 07:31:58 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ac484a6f-dbce-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709739119; x=1710343919; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=R7Bno0hyAUQO1crnpfNA0n5AIEwPTsHHAoqNPjU9xGg=; b=StuTVdS/IH7cC2OZ93VUaWqm77kcu6kqR6+cmD8tHKUcAvDuhYK4h3ktoTHzvVhkRr iAARe6OUqMNvg1OE2gIgFGZyEOIBC+bmlCgTyfitpEfJ8O4OSjQlSg7ESuwWGMcX1NTS JB+QfYDaGBkOWkj4LlsDDWFEb0fSv4lgeCKgzqAKBt5PrOQSbU9PD1GxnjNU7wphgimV F6Z5mgVVMe9Xw/s9RzRuorRmyi8zLR1APK5VJXmcYGS+gSD1PYnEp//ZZ4JRIJ/p/7EK NXVSCNeJyO6KkeZNSIeNm0ENuBa0qLr0bx/H/apBNqkF3z8x/9eFQVyNjCM4eoWNHzE1 Ye1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709739119; x=1710343919; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=R7Bno0hyAUQO1crnpfNA0n5AIEwPTsHHAoqNPjU9xGg=; b=OqGg8dU66Alb122RAf2c0RMSl+WOTXjaso64aH8bCprqCnIxOIqeT+iXkT72bpG4CI sOL+OM7dL4maYbj9EeGkV8wbPv6ygb6d186nrO/DndWv6b3sBEjFFi8rVKZpjc7wKXPt EUc2d6q5fBbOGZtjwkKmtQr+DN5g2rvXXqGj5IMxJXskxLJIPjXUg0jL+/JuA5uMUSby /jaSYvRtQt3DCoPxSXiNZWMGW2otJJ6R61w01Jp0BHZ6qhpm78ND0A+h4umvYfHzfBTe IMl6dKAfjksWSGDl1Qh+q2izhE4SNhv+iCCAmal2yrzXAxsmRqtcLevQKIcdJIuv3IQa 6aJQ== X-Forwarded-Encrypted: i=1; AJvYcCXfuSD+O24mWM3iUw9OF2vdj+aAUFrny+bhjG1YWXhvbwAHbknhWv9RrpgMwlYpoZFeBBQh+/NMRHgJPVCHLxao0RDepQMa0pl+kkVYahk= X-Gm-Message-State: AOJu0Yyu/gUBi4L0yvP9tfdpkqUy7NEqyuLoXhcfnb54to/lPTep5JyF M2jerkrq+stFQsdTeA9FdJNYjydyOxxw/47h3ipZVUM7eD9OycjqAt3aMj14Lg== X-Google-Smtp-Source: AGHT+IEpqExf5FjnbJqWEbz37JG1rVb5Ojr5R869FFikWQZEPQdBh2EoDEFhZYNWx0sSwRxt7HQ1bw== X-Received: by 2002:a17:906:348b:b0:a45:a348:32ad with SMTP id g11-20020a170906348b00b00a45a34832admr4055294ejb.74.1709739119019; Wed, 06 Mar 2024 07:31:59 -0800 (PST) Message-ID: <3d9b0fa3-d100-4e73-b5d5-782ef58e331a@suse.com> Date: Wed, 6 Mar 2024 16:31:56 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 13/23] xen/riscv: introduce atomic.h Content-Language: en-US To: Oleksii Kurochko Cc: Alistair Francis , Bob Eshleman , Connor Davis , Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu , xen-devel@lists.xenproject.org References: <85ad8c86901d045beed228947d4c3faf277af3ca.1708962629.git.oleksii.kurochko@gmail.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <85ad8c86901d045beed228947d4c3faf277af3ca.1708962629.git.oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 26.02.2024 18:38, Oleksii Kurochko wrote: > --- /dev/null > +++ b/xen/arch/riscv/include/asm/atomic.h > @@ -0,0 +1,296 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +/* > + * Taken and modified from Linux. > + * > + * The following changes were done: > + * - * atomic##prefix##_*xchg_*(atomic##prefix##_t *v, c_t n) were updated > + * to use__*xchg_generic() > + * - drop casts in write_atomic() as they are unnecessary > + * - drop introduction of WRITE_ONCE() and READ_ONCE(). > + * Xen provides ACCESS_ONCE() > + * - remove zero-length array access in read_atomic() > + * - drop defines similar to pattern > + * #define atomic_add_return_relaxed atomic_add_return_relaxed > + * - move not RISC-V specific functions to asm-generic/atomics-ops.h > + * > + * Copyright (C) 2007 Red Hat, Inc. All Rights Reserved. > + * Copyright (C) 2012 Regents of the University of California > + * Copyright (C) 2017 SiFive > + * Copyright (C) 2024 Vates SAS > + */ > + > +#ifndef _ASM_RISCV_ATOMIC_H > +#define _ASM_RISCV_ATOMIC_H > + > +#include > + > +#include > +#include > +#include > +#include > + > +#include While, because of the forward decls in xen/atomic.h, having this #include works, I wonder if it wouldn't better be placed further down. The compiler will likely have an easier time when it sees the inline definitions ahead of any uses. > +void __bad_atomic_size(void); > + > +/* > + * Legacy from Linux kernel. For some reason they wanted to have ordered > + * read/write access. Thereby read* is used instead of read_cpu() > + */ > +static always_inline void read_atomic_size(const volatile void *p, > + void *res, > + unsigned int size) > +{ > + switch ( size ) > + { > + case 1: *(uint8_t *)res = readb(p); break; > + case 2: *(uint16_t *)res = readw(p); break; > + case 4: *(uint32_t *)res = readl(p); break; > + case 8: *(uint32_t *)res = readq(p); break; This is the point where the lack of constraints in io.h (see my respective comment) becomes actually harmful: You're accessing not MMIO, but compiler- visible variables here. It needs to know which ones are read ... > + default: __bad_atomic_size(); break; > + } > +} > + > +#define read_atomic(p) ({ \ > + union { typeof(*p) val; char c[sizeof(*p)]; } x_; \ > + read_atomic_size(p, x_.c, sizeof(*p)); \ > + x_.val; \ > +}) > + > +#define write_atomic(p, x) \ > +({ \ > + typeof(*p) x__ = (x); \ > + switch ( sizeof(*p) ) \ > + { \ > + case 1: writeb(x__, p); break; \ > + case 2: writew(x__, p); break; \ > + case 4: writel(x__, p); break; \ > + case 8: writeq(x__, p); break; \ ... or written. Nit: There's a stray blank in the writeb() invocation. > + default: __bad_atomic_size(); break; \ > + } \ > + x__; \ > +}) > + > +#define add_sized(p, x) \ > +({ \ > + typeof(*(p)) x__ = (x); \ > + switch ( sizeof(*(p)) ) \ Like you have it here, {read,write}_atomic() also need p properly parenthesized. There look to be more parenthesization issues further down. > + { \ > + case 1: writeb(read_atomic(p) + x__, p); break; \ > + case 2: writew(read_atomic(p) + x__, p); break; \ > + case 4: writel(read_atomic(p) + x__, p); break; \ > + default: __bad_atomic_size(); break; \ > + } \ > +}) Any reason this doesn't have an 8-byte case? x86'es at least has one. > +#define __atomic_acquire_fence() \ > + __asm__ __volatile__ ( RISCV_ACQUIRE_BARRIER "" ::: "memory" ) > + > +#define __atomic_release_fence() \ > + __asm__ __volatile__ ( RISCV_RELEASE_BARRIER "" ::: "memory" ) Elsewhere you use asm volatile() - why __asm__ __volatile__() here? Or why not there (cmpxchg.h, io.h)? > +/* > + * First, the atomic ops that have no ordering constraints and therefor don't > + * have the AQ or RL bits set. These don't return anything, so there's only > + * one version to worry about. > + */ > +#define ATOMIC_OP(op, asm_op, I, asm_type, c_type, prefix) \ > +static inline \ > +void atomic##prefix##_##op(c_type i, atomic##prefix##_t *v) \ > +{ \ > + __asm__ __volatile__ ( \ > + " amo" #asm_op "." #asm_type " zero, %1, %0" \ > + : "+A" (v->counter) \ > + : "r" (I) \ > + : "memory" ); \ > +} \ > + > +#define ATOMIC_OPS(op, asm_op, I) \ > + ATOMIC_OP (op, asm_op, I, w, int, ) > + > +ATOMIC_OPS(add, add, i) > +ATOMIC_OPS(sub, add, -i) > +ATOMIC_OPS(and, and, i) > +ATOMIC_OPS( or, or, i) > +ATOMIC_OPS(xor, xor, i) > + > +#undef ATOMIC_OP > +#undef ATOMIC_OPS > + > +/* > + * Atomic ops that have ordered, relaxed, acquire, and release variants. > + * There's two flavors of these: the arithmatic ops have both fetch and return > + * versions, while the logical ops only have fetch versions. > + */ > +#define ATOMIC_FETCH_OP(op, asm_op, I, asm_type, c_type, prefix) \ > +static inline \ > +c_type atomic##prefix##_fetch_##op##_relaxed(c_type i, \ > + atomic##prefix##_t *v) \ > +{ \ > + register c_type ret; \ > + __asm__ __volatile__ ( \ > + " amo" #asm_op "." #asm_type " %1, %2, %0" \ > + : "+A" (v->counter), "=r" (ret) \ > + : "r" (I) \ > + : "memory" ); \ > + return ret; \ > +} \ > +static inline \ > +c_type atomic##prefix##_fetch_##op(c_type i, atomic##prefix##_t *v) \ > +{ \ > + register c_type ret; \ > + __asm__ __volatile__ ( \ > + " amo" #asm_op "." #asm_type ".aqrl %1, %2, %0" \ > + : "+A" (v->counter), "=r" (ret) \ > + : "r" (I) \ > + : "memory" ); \ > + return ret; \ > +} > + > +#define ATOMIC_OP_RETURN(op, asm_op, c_op, I, asm_type, c_type, prefix) \ > +static inline \ > +c_type atomic##prefix##_##op##_return_relaxed(c_type i, \ > + atomic##prefix##_t *v) \ > +{ \ > + return atomic##prefix##_fetch_##op##_relaxed(i, v) c_op I; \ > +} \ > +static inline \ > +c_type atomic##prefix##_##op##_return(c_type i, atomic##prefix##_t *v) \ > +{ \ > + return atomic##prefix##_fetch_##op(i, v) c_op I; \ > +} > + > +#define ATOMIC_OPS(op, asm_op, c_op, I) \ > + ATOMIC_FETCH_OP( op, asm_op, I, w, int, ) \ > + ATOMIC_OP_RETURN(op, asm_op, c_op, I, w, int, ) What purpose is the last macro argument when you only ever pass nothing for it (here and ... > +ATOMIC_OPS(add, add, +, i) > +ATOMIC_OPS(sub, add, +, -i) > + > +#undef ATOMIC_OPS > + > +#define ATOMIC_OPS(op, asm_op, I) \ > + ATOMIC_FETCH_OP(op, asm_op, I, w, int, ) ... here)? > +ATOMIC_OPS(and, and, i) > +ATOMIC_OPS( or, or, i) > +ATOMIC_OPS(xor, xor, i) > + > +#undef ATOMIC_OPS > + > +#undef ATOMIC_FETCH_OP > +#undef ATOMIC_OP_RETURN > + > +/* This is required to provide a full barrier on success. */ > +static inline int atomic_add_unless(atomic_t *v, int a, int u) > +{ > + int prev, rc; > + > + __asm__ __volatile__ ( > + "0: lr.w %[p], %[c]\n" > + " beq %[p], %[u], 1f\n" > + " add %[rc], %[p], %[a]\n" > + " sc.w.rl %[rc], %[rc], %[c]\n" > + " bnez %[rc], 0b\n" > + RISCV_FULL_BARRIER > + "1:\n" > + : [p] "=&r" (prev), [rc] "=&r" (rc), [c] "+A" (v->counter) > + : [a] "r" (a), [u] "r" (u) > + : "memory"); > + return prev; > +} > + > +/* > + * atomic_{cmp,}xchg is required to have exactly the same ordering semantics as > + * {cmp,}xchg and the operations that return, so they need a full barrier. > + */ > +#define ATOMIC_OP(c_t, prefix, size) \ > +static inline \ > +c_t atomic##prefix##_xchg_relaxed(atomic##prefix##_t *v, c_t n) \ > +{ \ > + return __xchg_generic(&(v->counter), n, size, "", "", ""); \ The inner parentheses aren't really needed here, are they? > +} \ > +static inline \ > +c_t atomic##prefix##_xchg_acquire(atomic##prefix##_t *v, c_t n) \ > +{ \ > + return __xchg_generic(&(v->counter), n, size, \ > + "", "", RISCV_ACQUIRE_BARRIER); \ > +} \ > +static inline \ > +c_t atomic##prefix##_xchg_release(atomic##prefix##_t *v, c_t n) \ > +{ \ > + return __xchg_generic(&(v->counter), n, size, \ > + "", RISCV_RELEASE_BARRIER, ""); \ > +} \ > +static inline \ > +c_t atomic##prefix##_xchg(atomic##prefix##_t *v, c_t n) \ > +{ \ > + return __xchg_generic(&(v->counter), n, size, \ > + ".aqrl", "", ""); \ > +} \ > +static inline \ > +c_t atomic##prefix##_cmpxchg_relaxed(atomic##prefix##_t *v, \ > + c_t o, c_t n) \ > +{ \ > + return __cmpxchg_generic(&(v->counter), o, n, size, \ > + "", "", ""); \ > +} \ > +static inline \ > +c_t atomic##prefix##_cmpxchg_acquire(atomic##prefix##_t *v, \ > + c_t o, c_t n) \ > +{ \ > + return __cmpxchg_generic(&(v->counter), o, n, size, \ > + "", "", RISCV_ACQUIRE_BARRIER); \ > +} \ > +static inline \ > +c_t atomic##prefix##_cmpxchg_release(atomic##prefix##_t *v, \ > + c_t o, c_t n) \ > +{ \ A hard tab looks to have been left here. > + return __cmpxchg_generic(&(v->counter), o, n, size, \ > + "", RISCV_RELEASE_BARRIER, ""); \ > +} \ > +static inline \ > +c_t atomic##prefix##_cmpxchg(atomic##prefix##_t *v, c_t o, c_t n) \ > +{ \ > + return __cmpxchg_generic(&(v->counter), o, n, size, \ > + ".rl", "", " fence rw, rw\n"); \ > +} > + > +#define ATOMIC_OPS() \ > + ATOMIC_OP(int, , 4) > + > +ATOMIC_OPS() > + > +#undef ATOMIC_OPS > +#undef ATOMIC_OP > + > +static inline int atomic_sub_if_positive(atomic_t *v, int offset) > +{ > + int prev, rc; > + > + __asm__ __volatile__ ( > + "0: lr.w %[p], %[c]\n" > + " sub %[rc], %[p], %[o]\n" > + " bltz %[rc], 1f\n" > + " sc.w.rl %[rc], %[rc], %[c]\n" > + " bnez %[rc], 0b\n" > + " fence rw, rw\n" > + "1:\n" > + : [p] "=&r" (prev), [rc] "=&r" (rc), [c] "+A" (v->counter) > + : [o] "r" (offset) > + : "memory" ); > + return prev - offset; > +} > + > +#define atomic_dec_if_positive(v) atomic_sub_if_positive(v, 1) Hmm, PPC for some reason also has the latter, but for both: Are they indeed going to be needed in RISC-V code? They certainly look unnecessary for the purpose of this series (allowing common code to build). > --- /dev/null > +++ b/xen/include/asm-generic/atomic-ops.h > @@ -0,0 +1,92 @@ > +#/* SPDX-License-Identifier: GPL-2.0 */ > +#ifndef _ASM_GENERIC_ATOMIC_OPS_H_ > +#define _ASM_GENERIC_ATOMIC_OPS_H_ > + > +#include > +#include If I'm not mistaken this header provides default implementations for every xen/atomic.h-provided forward inline declaration that can be synthesized from other atomic functions. I think a comment to this effect would want adding somewhere here. Jan From xen-devel-bounces@lists.xenproject.org Wed Mar 06 15:43:41 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 15:43:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689381.1074272 (Exim 4.92) (envelope-from ) id 1rhtQe-0006M2-2l; Wed, 06 Mar 2024 15:43:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689381.1074272; Wed, 06 Mar 2024 15:43:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhtQd-0006Lv-VX; Wed, 06 Mar 2024 15:43:35 +0000 Received: by outflank-mailman (input) for mailman id 689381; Wed, 06 Mar 2024 15:43:34 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhtQc-0006Lp-Aa for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 15:43:34 +0000 Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [2a00:1450:4864:20::32e]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 490a3a8a-dbd0-11ee-a1ee-f123f15fe8a2; Wed, 06 Mar 2024 16:43:32 +0100 (CET) Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-412f988d552so3724815e9.3 for ; Wed, 06 Mar 2024 07:43:32 -0800 (PST) Received: from perard.uk.xensource.com (default-46-102-197-194.interdsl.co.uk. [46.102.197.194]) by smtp.gmail.com with ESMTPSA id fa26-20020a05600c519a00b00412f698af9esm2109959wmb.17.2024.03.06.07.43.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Mar 2024 07:43:30 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 490a3a8a-dbd0-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1709739811; x=1710344611; darn=lists.xenproject.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=nOmtTVfGZfmyP3Z2U9Aye9gisuKvmOWpAI+mJklhUz4=; b=Mbm9vN6XnvvQz0AUkrqwR5ZpTx5t3qeBb6tZ1H5ISmBQZI1ZCS4ffeaX/kdDouuTV3 d/hZ3mmXH8cJYtY84F7BiJbn4pU3BX2tvTth0l5vBTmQvKY17YnItGfYWXSweCo3Hc8A 5A/5dqLy+GAYJN832A77YQ1ULTdqa/CqpVt/4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709739811; x=1710344611; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=nOmtTVfGZfmyP3Z2U9Aye9gisuKvmOWpAI+mJklhUz4=; b=B6bHJQ5n0AwSuKjYxbwhPYbnHzxtEIrvZ0A7T0KYRQKHORhhHQL8QIn9eqo0Y+oNTi q14EXo5aVUMWJ1nVkXCOQja0TYzRAzIFADgmnWDjklUZ5B+fIIa6hVTHacK+mK+wbtde OrtQjARNeNzmEW38x3h9eph+ZguUgPnhqc4P077kTND5BwRtqIhfCWSzuPDjwb/tinWD VFaOm6MyERUqR7zR2HDg5Jvz+3/s54zGQ4oxaM+kriFiDoE6dzEPEWt0ZNGihyCdrfMG 7/RJ6bdLeo23ojlc0IUEkKCA4zcnKZAhedCqqvu2CGGWppQNR5lOUtnpW4aZiSYo1JOX u4qw== X-Gm-Message-State: AOJu0YzdCraOL8Nu22WDq68TfoQaAy1B452TiNW3J/wNMRGLuJ30mWzs 9Dxan+blr8Hqw66QsE1SsGBumJi9ok61QvDOTzj8JXhOiI1ajRTOIUrzrhxc44o= X-Google-Smtp-Source: AGHT+IEhczkt+rPg5pLHJTIbY7c1Lr8OrlaVUDBAZBdEAQMw0ZSUx1fWK1Mii++8Y3VF5wCWA6j0gg== X-Received: by 2002:a05:600c:3151:b0:412:fc6f:e578 with SMTP id h17-20020a05600c315100b00412fc6fe578mr906060wmo.9.1709739811554; Wed, 06 Mar 2024 07:43:31 -0800 (PST) Date: Wed, 6 Mar 2024 15:43:30 +0000 From: Anthony PERARD To: zithro / Cyril =?iso-8859-1?Q?R=E9bert?= Cc: xen-devel@lists.xenproject.org, Roger Pau =?iso-8859-1?Q?Monn=E9?= , Wei Liu Subject: Re: [PATCH] docs/man: add shutdown reasons to xl (list) man page Message-ID: <5e8987de-36b1-4e00-876c-79a93e5334a9@perard> References: <019602d6da2ff78e6582b9b6aae6d76216e150c3.1709678713.git.slack@rabbit.lu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <019602d6da2ff78e6582b9b6aae6d76216e150c3.1709678713.git.slack@rabbit.lu> On Tue, Mar 05, 2024 at 11:45:13PM +0100, zithro / Cyril Rbert wrote: > Add the shutdown reasons to the paragraph of "xl list" concerning the > shutdown status. > I have copy/pasted the explanations from the source code : > > - tools/xl/xl_info.c (L379) Instead of a line number, how about the function name? - tools/xl/xl_info.c (list_domains()) > - xen/include/public/sched.h (starting L158) And here, I think that would be "sched_shutdown_reason". Line number tend to change as we add more code, which mean that the line number is only valid at the time it is written into the patch description. But functions and struct name are less likely to be renamed. > > Suggested-by: Roger Pau Monn > Signed-off-by: Cyril Rbert / zithro > --- > docs/man/xl.1.pod.in | 34 ++++++++++++++++++++++++++++++++++ > 1 file changed, 34 insertions(+) > > diff --git a/docs/man/xl.1.pod.in b/docs/man/xl.1.pod.in > index bed8393473..2b046f97f1 100644 > --- a/docs/man/xl.1.pod.in > +++ b/docs/man/xl.1.pod.in > @@ -370,6 +370,40 @@ scheduling by the Xen hypervisor. > The guest OS has shut down (SCHEDOP_shutdown has been called) but the > domain is not dying yet. > > +There are six shutdown reasons, which will be displayed after the "s" : B<-rscwS>. > + > +=over 4 > + > +=over 4 > + > +=item s- : poweroff It might look nicer to keep using B<> like the other states, that is B. > + > +Domain exited normally. Clean up and kill. I don't think we should copy the explanation from "sched.h", they seems mostly been written for someone writing a toolstack. A user of `xl` isn't expected to "clean up" an domain in that state, beside maybe running `xl destroy` because they've added "on_poweroff=preserve". > + > +=item sr : reboot > + > +Clean up, kill, and then restart. Same thing here as an other example, the only action a user can do I think is `xl destroy`. The "restart" bit is definitely targeted at the toolstack. There's no way to restart a vm, beside `xl destroy; xl create`. > +=item ss : suspend > + > +The domain is suspended. Clean up, save suspend info, kill. > + > +=item sc : crash > + > +Tell controller we've crashed. > + > +=item sw : watchdog > + > +Restart because watchdog time expired. > + > +=item sS : soft_reset > + > +Domain asked to perform 'soft reset' for it. The expected behavior is to reset internal Xen state for the domain returning it to the point where it was created but leaving the domain's memory contents and vCPU contexts intact. This will allow the domain to start over and set up all Xen specific interfaces again. > + > +=back > + > +=back > + > =item B This entry is now a duplicate of "sc", I think we can remove it. And probably keep the explanation. > The domain has crashed, which is always a violent ending. Usually Thanks, -- Anthony PERARD From xen-devel-bounces@lists.xenproject.org Wed Mar 06 16:25:24 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 16:25:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689385.1074282 (Exim 4.92) (envelope-from ) id 1rhu4z-0004fv-3E; Wed, 06 Mar 2024 16:25:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689385.1074282; Wed, 06 Mar 2024 16:25:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhu4z-0004fo-0T; Wed, 06 Mar 2024 16:25:17 +0000 Received: by outflank-mailman (input) for mailman id 689385; Wed, 06 Mar 2024 16:25:16 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhu4y-0004fh-Iy for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 16:25:16 +0000 Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [2a00:1450:4864:20::236]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 1add25f2-dbd6-11ee-a1ee-f123f15fe8a2; Wed, 06 Mar 2024 17:25:11 +0100 (CET) Received: by mail-lj1-x236.google.com with SMTP id 38308e7fff4ca-2d311081954so140991fa.2 for ; Wed, 06 Mar 2024 08:25:11 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1add25f2-dbd6-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1709742311; x=1710347111; darn=lists.xenproject.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=8mHfSd5dqMvjggqW3GpO2/SzQGRtbOI8jB0i0HRbgeo=; b=EgYHpDmcUqELjuFCrfLSLQtRgywGkMd17QhN/y9jnNKmihdysvZI2yoCnJtNUd+yxx qAzEA0F/+6e8zMDQkImN1WBdbQZDQokgfn59MVIExb8oUumUAT5/DRxQjmuwEExYhFcw OPNiyV0fRzEXUqqT2MnHiDEMLcuH6mi4gGjFI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709742311; x=1710347111; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=8mHfSd5dqMvjggqW3GpO2/SzQGRtbOI8jB0i0HRbgeo=; b=oh7hoq/yVd4wWrd7ph1zPe1vs0O5iiUgK2M/muK60kU4N6442NUIoGBauMOVwmr6sN ZpHWsmQzJ0u9Mfmb6ybzHgbD4/vxIdWgJANGWuaDSEx1SDuqeHxS2kOJHnrUf4gUZSXA DFbqi+8s1yKyR4VLlN37dqP5xMNqKoW63FtDwzNBCvIWdFfDCtAlb5a5kLuVpUyIngjb JIAjoPdC6HK8EI1eAqj/Da8kfxJ8xDQ/FTtJ/A7oK0TklWtSmne5v0otxzeA6j1Crb1v jOOy1rrPsZxZkwcOzPzhFSL4ogYvTUGwcjTm6CXPmQtDAQ4WUPccg8K90+RQ2WQO1osR ZP2A== X-Gm-Message-State: AOJu0YyM9penzqeESc2AowlOYf7dYJvtevggapYvMUJe81MoGuTb2QXq 30ulbiFBhmpcd3tqSV7WlKhkSEtW1740MUfYKno3bDlNkY69PNTOnhlEdRpzfDqlwEMkqj2S8/V 9k0dSON5JqOv5ATj4ua4Y9/QYZBRTNH/40QEubICMxHb1r+yv X-Google-Smtp-Source: AGHT+IGgwybRs5GXc6tnQKSWcDV2i+RIDltA5lDJSy8ZjETzvgCAroHuBNp3tilhh25fHvJ6anjHwLLsBlCoCdMy2EM= X-Received: by 2002:a2e:9f14:0:b0:2d2:1a1f:ad77 with SMTP id u20-20020a2e9f14000000b002d21a1fad77mr3477625ljk.13.1709742310071; Wed, 06 Mar 2024 08:25:10 -0800 (PST) MIME-Version: 1.0 From: Kelly Choi Date: Wed, 6 Mar 2024 16:24:33 +0000 Message-ID: Subject: [ANNOUNCE] Call for agenda items for Community Call - 7th March 2024 To: xen-devel Content-Type: multipart/alternative; boundary="0000000000000ccb900613006755" --0000000000000ccb900613006755 Content-Type: text/plain; charset="UTF-8" Hi all, Please add your proposed agenda items below. https://cryptpad.fr/pad/#/2/pad/edit/VlIkjPmILf0abDG3j1Wn0091/ If any action items are missing or have been resolved, please add/remove them from the sheet. *CALL LINK: https://meet.jit.si/XenProjectCommunityCall * *DATE: Thursday 7th March 2024* *TIME: 1600 UTC (4 pm UK time)* *Note the following administrative conventions for the call:* ** To allow time to switch between meetings, we plan on starting theagenda at 16:05 UTC sharp. Aim to join by 16:03 UTC if possible to allocatetime to sort out technical difficulties.* If you want to be CC'ed please add or remove yourself from thesign-up-sheet at https://cryptpad.fr/pad/#/2/pad/edit/D9vGzihPxxAOe6RFPz0sRCf+/ == Dial-in Information ==## Meeting time16:00 - 17:00 British timeFurther International meeting times:https://www.timeanddate.com/worldclock/meetingdetails.html?year=2024&month=3&day=7&hour=16&min=0&sec=0&p1=1234&p2=37&p3=224&p4=179 * ## Dial in details https://meet.jit.si/static/dialInInfo.html?room=XenProjectCommunityCall Many thanks, Kelly Choi Community Manager Xen Project --0000000000000ccb900613006755 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

Please add= your proposed agenda items below.

https://cryptpad= .fr/pad/#/2/pad/edit/VlIkjPmILf0abDG3j1Wn0091/=C2=A0

If any a= ction items are missing or have been resolved, please add/remove them from = the sheet.=C2=A0

CALL=C2=A0LINK:=C2=A0https://meet.jit.si/XenProjectCommunityCall

DATE: Thursday 7th March 2024

TIME: 1600 UTC (4 pm= UK time)

Note the following administrative conventions for the= =C2=A0call:

* To allow time to = switch between meetings, we plan on starting the
agenda at 16:05 UTC sha= rp.=C2=A0 Aim to join by 16:03 UTC if possible to allocate
time to sort = out technical difficulties.

* If you want to be CC'ed please add= or remove yourself from the
sign-up-sheet at=C2=A0https://cryptpad.fr/pad/#/2/pad/edit/D9vGzihPxxAOe6RFPz0sRC= f+/

=3D=3D=C2=A0Dial-in Information =3D=3D
## Meeting time16:00 - 17:00 British time
Further International meeting times:
https://ww= w.timeanddate.com/worldclock/meetingdetails.html?year=3D2024&month=3D3&= amp;day=3D7&hour=3D16&min=3D0&sec=3D0&p1=3D1234&p2=3D37= &p3=3D224&p4=3D179=C2=A0=C2=A0=C2=A0

##=C2=A0Dial=C2= =A0in details
https://me= et.jit.si/static/dialInInfo.html?room=3DXenProjectCommunityCall

<= div dir=3D"ltr">
Many thanks,
Kelly Choi

=
Community Manager
Xen Project=C2=A0
<= /div>
--0000000000000ccb900613006755-- From xen-devel-bounces@lists.xenproject.org Wed Mar 06 16:44:02 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 16:44:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689390.1074291 (Exim 4.92) (envelope-from ) id 1rhuMv-0007wa-Lq; Wed, 06 Mar 2024 16:43:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689390.1074291; Wed, 06 Mar 2024 16:43:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhuMv-0007wT-J2; Wed, 06 Mar 2024 16:43:49 +0000 Received: by outflank-mailman (input) for mailman id 689390; Wed, 06 Mar 2024 16:43:48 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhuMu-0007wK-3p for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 16:43:48 +0000 Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [2a00:1450:4864:20::133]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id b32fcfde-dbd8-11ee-a1ee-f123f15fe8a2; Wed, 06 Mar 2024 17:43:46 +0100 (CET) Received: by mail-lf1-x133.google.com with SMTP id 2adb3069b0e04-51326436876so1565525e87.1 for ; Wed, 06 Mar 2024 08:43:46 -0800 (PST) Received: from [192.168.206.239] ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id p14-20020a19f00e000000b005132cf9094dsm2368048lfc.36.2024.03.06.08.43.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Mar 2024 08:43:45 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b32fcfde-dbd8-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709743425; x=1710348225; darn=lists.xenproject.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=oTAhS6BPjC1OlEr+SwLhC4ThwGKDMP77my5pTBizAyE=; b=mUvFoAPJD1St6C+ojApcEfRF/QXIXIwaxSA2LAwSwJKpdMx5k6GRA+zlZ3hKpYQb3i wz3VuBdXgJcySkXvNgUyb3Zga+tQc3uyeTV5qddIjJZV1/g4jQo/7A8rQQzjpSgBDA9Q otjUPp8JPOuzTW6cChWC4v0ABw30v3jmOKj8dhUpdRrKCMfuXSZDUs1tyriXg2C/t7y6 ZDYWPqziH5xD+dV8LIHZXjDkDaGRyJUIZku5TKuHvSRpzwVPJCHxfVa1xKabA/5mIm4N 0KV3K7rf0vdxn1wlwXfLQ4TOynlBRDiBLg49vNZ6UAh/PtnOUnMxGE0Wbv4zR0ShoxvR xNXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709743425; x=1710348225; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=oTAhS6BPjC1OlEr+SwLhC4ThwGKDMP77my5pTBizAyE=; b=MIG8X6lHACsidfYfqcApCVJ3o+zEP+/PkxIW5KzvGueRcvmBwykFviByyBo20CD2XY Y8PuLWQpWGQEhZsyaoScx+gnS9ZixEhaWFjy+Tf9zsHlcoSVBfQEIuQXijW5zzfxwHnB InpiVRvrKsqAsw06Olg0lcMiZ6nlM4kmlOeafA+waV3Wlu9CuYw3OUJ/a1fSolMmlBUk Oc+F9Nk/W+aJWrnCMK7AYb65gNFMFs/5Tto4EB5DirOnHB2GX+R6ggWdAuXsZL2+60My zzl3+jcu5Tn1s/A7hcyplBzioxlMnEsIH6+zVhMXYThF/ZUdI17OFg7Xjfrn/dr8pBYa zBtw== X-Forwarded-Encrypted: i=1; AJvYcCXbYVJN5/wWbdPvRSNgUj8DWUQuyQL438MyopUHzP7sclIlUDaqVrtJbVDJ77gNQaObiJx21fyvfKaVftf7Yp7tk6am+puu7+Fycfp5stQ= X-Gm-Message-State: AOJu0YxJY7d+tGdjaoxL8VumjPNBC1VTcteWUl8vs4DxTBpgOnnupjqk gfzVtlCvNkp0yfkAIofnLUn/YP/tJkpln6IGsbyjuq4T6CZ1gH3S X-Google-Smtp-Source: AGHT+IETNvMAB8G8RD4G7IuoORU1JKVuKpH+bJSItVo4Mu1vuWsWw9L2uaYjsoxLSTJpgMMa9DNBQg== X-Received: by 2002:a19:f011:0:b0:512:fe3d:a991 with SMTP id p17-20020a19f011000000b00512fe3da991mr3584085lfc.61.1709743425299; Wed, 06 Mar 2024 08:43:45 -0800 (PST) Message-ID: <8ec313087bfd4449e259151688c1ba2cb5b3f24c.camel@gmail.com> Subject: Re: [PATCH] CHANGELOG: add an entry for 9pfsd From: Oleksii To: Juergen Gross , xen-devel@lists.xenproject.org Cc: Community Manager Date: Wed, 06 Mar 2024 17:43:44 +0100 In-Reply-To: <20240306111738.1815-1-jgross@suse.com> References: <20240306111738.1815-1-jgross@suse.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.50.2 (3.50.2-1.fc39) MIME-Version: 1.0 Hi Juergen, Looks good to me: Acked-by: Oleksii Kurochko ~ Oleksii On Wed, 2024-03-06 at 12:17 +0100, Juergen Gross wrote: > Add an entry to CHANGELOG.md regarding the new xen-9pfsd daemon. >=20 > Signed-off-by: Juergen Gross > --- > =C2=A0CHANGELOG.md | 2 ++ > =C2=A01 file changed, 2 insertions(+) >=20 > diff --git a/CHANGELOG.md b/CHANGELOG.md > index f9874f9bb0..93fda73c00 100644 > --- a/CHANGELOG.md > +++ b/CHANGELOG.md > @@ -18,6 +18,8 @@ The format is based on [Keep a > Changelog](https://keepachangelog.com/en/1.0.0/) > =C2=A0 - On x86: > =C2=A0=C2=A0=C2=A0 - Introduce a new x2APIC driver that uses Cluster Logi= cal > addressing mode > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 for IPIs and Physical addressing mode for = external interrupts. > + - Add a new 9pfs backend running as a daemon in dom0. First user is > +=C2=A0=C2=A0 Xenstore-stubdom now being able to support full Xenstore tr= ace > capability. > =C2=A0 > =C2=A0### Removed > =C2=A0- caml-stubdom.=C2=A0 It hasn't built since 2014, was pinned to Oca= ml > 4.02, and has From xen-devel-bounces@lists.xenproject.org Wed Mar 06 16:48:43 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 16:48:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689395.1074301 (Exim 4.92) (envelope-from ) id 1rhuRe-00005O-6O; Wed, 06 Mar 2024 16:48:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689395.1074301; Wed, 06 Mar 2024 16:48:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhuRe-00005H-3w; Wed, 06 Mar 2024 16:48:42 +0000 Received: by outflank-mailman (input) for mailman id 689395; Wed, 06 Mar 2024 16:48:40 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhuRc-00005B-Bw for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 16:48:40 +0000 Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [2a00:1450:4864:20::12a]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 612d88fb-dbd9-11ee-afda-a90da7624cb6; Wed, 06 Mar 2024 17:48:39 +0100 (CET) Received: by mail-lf1-x12a.google.com with SMTP id 2adb3069b0e04-512f3e75391so2134279e87.2 for ; Wed, 06 Mar 2024 08:48:38 -0800 (PST) Received: from draig.lan ([85.9.250.243]) by smtp.gmail.com with ESMTPSA id fk15-20020a05600c0ccf00b00412ff1acf05sm1021130wmb.7.2024.03.06.08.48.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Mar 2024 08:48:37 -0800 (PST) Received: from draig.lan (localhost [IPv6:::1]) by draig.lan (Postfix) with ESMTP id DE7A85F796; Wed, 6 Mar 2024 16:48:36 +0000 (GMT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 612d88fb-dbd9-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1709743718; x=1710348518; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=PgcX19QUQvO9a0rJ1WYbUKrpxkk0cHhIiPkrtv4Xua8=; b=APw3PZnzvflZzfU3ZXeCYAUUaczwMoppIGtlisEMSvUHsUZteBsVapMHp205Qaseod gmqhzk/Tu+dwkln3ioW8gCz783YsxYGaV9c71KBJSsU8JUghlHHIDHwg7bG8yNojLTvq AcDv2LyxGbBE2I31RT3bpjbQ6AAxECPDm3KGjqgnQmcGpdwVKfnxJef8mEZhRLJUtDdv zq6hoUk8SsxOdXCw+3NT4JAnb3cDaH9nWtlVjukmnZo+mhgrJaC/hq8DJhDvBOcz876D k8iVlnWAhcn/mRJ2pelEHm6lQkezYV6UFseSTPW9qpgmBy+RXTwpjPiggFc6S/Yr/sY+ ItKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709743718; x=1710348518; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=PgcX19QUQvO9a0rJ1WYbUKrpxkk0cHhIiPkrtv4Xua8=; b=oqikbLiGSYyMSX4ruuYIT/BofWx46v0vDg8fo/bQskVOdjimDlu3XdvU7MuavXvB/q C47uvyZika91rgZJK86LqKmvUYRnTfZee1sEVRFvjv0GwlLfjm+8BibR2blNSI41tAFT mL0XlcZMGf6Q6mzzNb5qbI3QBzyVyP1CTzxUIpTYe8bdhNDjr7GrYI6oAqWdh03sx8/K huvtePU/Q4GcXXDxROaytm5n6OEh/NEd/JEPYjaoGWKrkygjrOcRgqDQUW5d7SMlAXPs ZfAgBJ1JpUaau+8ZjZKeTmP1V3DDj+bXENoxqrYXanvWg2QBTeXD23YCRXZt9bNXGWlP kpRw== X-Gm-Message-State: AOJu0YyCBZEBEUnvd8rvSbYsBaRunvhIY2PSRcv5nOIRVJJiNyM48dmW pgtzanS60fqNOYxzgNd3JWei74j5AhzrspaWGacZFS3CNhx2R8L5VDxWnVIP39mM70uHpfjoGdp 2 X-Google-Smtp-Source: AGHT+IEys42Mf/xBgBycnQ/heyOKiVoOZovfkQDvdq4KY0U7LwmYAV1vfWAjpNlbh3i5L8X0r+12sw== X-Received: by 2002:a05:6512:2e4:b0:513:64d7:afb5 with SMTP id m4-20020a05651202e400b0051364d7afb5mr933469lfq.57.1709743717603; Wed, 06 Mar 2024 08:48:37 -0800 (PST) From: =?UTF-8?q?Alex=20Benn=C3=A9e?= To: xen-devel@lists.xenproject.org Cc: =?UTF-8?q?Alex=20Benn=C3=A9e?= Subject: [RFC PATCH] tools/libxl: force running dm when device_model_args set Date: Wed, 6 Mar 2024 16:48:29 +0000 Message-Id: <20240306164829.3815555-1-alex.bennee@linaro.org> X-Mailer: git-send-email 2.39.2 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit When device_model_args is set we almost certainly want to spawn the device model. This is most useful when debugging with QEMU and you want to specify a new device type for testing without teaching libxl about the device itself. Signed-off-by: Alex Bennée --- This is very much an RFC, it's useful to me as a developer but I can see an argument for being more cautious for production. --- tools/libs/light/libxl_dm.c | 6 ++++++ tools/libs/light/libxl_types.idl | 2 ++ tools/xl/xl_parse.c | 2 ++ 3 files changed, 10 insertions(+) diff --git a/tools/libs/light/libxl_dm.c b/tools/libs/light/libxl_dm.c index 620f381560..5774510aa0 100644 --- a/tools/libs/light/libxl_dm.c +++ b/tools/libs/light/libxl_dm.c @@ -3969,7 +3969,13 @@ int libxl__need_xenpv_qemu(libxl__gc *gc, libxl_domain_config *d_config) } } + /* finally if we've slurped extra args we almost certainly do */ + if (d_config->need_ext_dm) { + ret = 1; + } + out: + LOGD(INFO, domid, "need_qemu: %s", ret == 1 ? "yes":"no"); return ret; } diff --git a/tools/libs/light/libxl_types.idl b/tools/libs/light/libxl_types.idl index 2be194eb19..e7705bebe9 100644 --- a/tools/libs/light/libxl_types.idl +++ b/tools/libs/light/libxl_types.idl @@ -1113,6 +1113,8 @@ libxl_domain_config = Struct("domain_config", [ ("on_watchdog", libxl_action_on_shutdown), ("on_crash", libxl_action_on_shutdown), ("on_soft_reset", libxl_action_on_shutdown), + # true when we need to launch dm to serve the guest + ("need_ext_dm", bool), ], dir=DIR_IN) libxl_diskinfo = Struct("diskinfo", [ diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c index 52e20134a9..be0ea3e3dc 100644 --- a/tools/xl/xl_parse.c +++ b/tools/xl/xl_parse.c @@ -3083,6 +3083,8 @@ skip_usbdev: if (e && e != ESRCH) { \ fprintf(stderr,"xl: Unable to parse device_model_args"#type".\n");\ exit(-ERROR_FAIL); \ + } else if (e) { \ + d_config->need_ext_dm = true; \ } /* parse extra args for qemu, common to both pv, hvm */ -- 2.39.2 From xen-devel-bounces@lists.xenproject.org Wed Mar 06 16:56:37 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 16:56:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689398.1074312 (Exim 4.92) (envelope-from ) id 1rhuZE-000277-VS; Wed, 06 Mar 2024 16:56:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689398.1074312; Wed, 06 Mar 2024 16:56:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhuZE-000270-Sm; Wed, 06 Mar 2024 16:56:32 +0000 Received: by outflank-mailman (input) for mailman id 689398; Wed, 06 Mar 2024 16:56:31 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhuZD-00026u-T4 for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 16:56:31 +0000 Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [2a00:1450:4864:20::42e]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 79c8b058-dbda-11ee-a1ee-f123f15fe8a2; Wed, 06 Mar 2024 17:56:29 +0100 (CET) Received: by mail-wr1-x42e.google.com with SMTP id ffacd0b85a97d-33e383546c1so685092f8f.2 for ; Wed, 06 Mar 2024 08:56:28 -0800 (PST) Received: from draig.lan ([85.9.250.243]) by smtp.gmail.com with ESMTPSA id h18-20020a5d5052000000b0033cf4e47496sm17950600wrt.51.2024.03.06.08.56.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Mar 2024 08:56:27 -0800 (PST) Received: from draig.lan (localhost [IPv6:::1]) by draig.lan (Postfix) with ESMTP id 6A5BE5F88A; Wed, 6 Mar 2024 16:56:27 +0000 (GMT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 79c8b058-dbda-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1709744188; x=1710348988; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=QmO7ZZgYnvYeyC1/GW84LLWQW1EeC1P4rBQfQjcRcV0=; b=X/P4l1CRXDlRIZ1UamXH21t+KIBwZwWrR+2qGRR7D/0QXKUAZb/eHy5M3WIZrVE4Xg 8F3L3ko5drtk5EqMG03VMaVK5um9gmP/t0bU5TmX40qmMkgdJ/OlZ/U7xmKTw0ImO5rL 4XFJVKSijvz1Gnw8+oRz7FB+vJQh9YO3R9jWFI2AhPQdgfTyFwok/JRpz75BIZYWfk0w g1qOaK0H7Fl9/BFjwpnd0QIwrQNjpTQ0tf6BQXh3aGVBDZYrwqepV/zjt7FCBR7PqPtN kVzn0q4VZWvsGvokz9jEV11tj46lodmT5pA9l11zgb6mo4OWt/AVokYWMfkx/MWubFh7 MAcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709744188; x=1710348988; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=QmO7ZZgYnvYeyC1/GW84LLWQW1EeC1P4rBQfQjcRcV0=; b=gsv3xL+T+ldPOIaQeOH5JAFhOfzhPloDw/CON2pEjxTjRsaxzkCZAzgbfcvNu05Or3 +SVrSgpCVBwjV95y2diXXbAhUmP0zgK91aI1S1wm4LlVJpMkpiUIOMK65+xrAqo2gwBT PRH2kkYRM0aq7fNEoQYqVv28s3pu5AOCZvtRFgrC7ehW1Px7MkQ4tBoOQkpDd8awtiz7 y8RS2krnV+yxZrWYtANRpElR4PoOH/SCkP9HhOWHWx4vz5sPxyHH4rsL4Rq2qKg6XqE3 RmGj2MZpXBODRf4zaOhu7uFH2YQfuuO2MNbpriqiNqmNc2RWpuWdkoF6sUD8lF1FZlRo JeCQ== X-Gm-Message-State: AOJu0Yz0YElLlMWEuL3A1pS5UkRKFZL3uUJC8z0+/6qKY2u74FEMBZDB hXVreyxrZalRXlBgol4RUb+VYhLo7HSNBjIMMwQ0HD8dbUP2x8eQVqxuWNxuNVA= X-Google-Smtp-Source: AGHT+IE8V3aK2Sri5oE6eSGzqleS4sJmSeBCMsX3sQheIq1KhZ9SfzCrK3ZFaVL4AkWoYQlt49LhOw== X-Received: by 2002:a05:6000:1970:b0:33d:5548:435e with SMTP id da16-20020a056000197000b0033d5548435emr12514452wrb.53.1709744188167; Wed, 06 Mar 2024 08:56:28 -0800 (PST) From: =?UTF-8?q?Alex=20Benn=C3=A9e?= To: xen-devel@lists.xenproject.org Cc: julien@xen.org, sstabellini@kernel.org, bertrand.marquis@arm.com, =?UTF-8?q?Alex=20Benn=C3=A9e?= , Manos Pitsidianakis Subject: [RFC PATCH v2] xen/arm: improve handling of load/store instruction decoding Date: Wed, 6 Mar 2024 16:56:21 +0000 Message-Id: <20240306165621.3819343-1-alex.bennee@linaro.org> X-Mailer: git-send-email 2.39.2 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit While debugging VirtIO on Arm we ran into a warning due to memory being memcpy'd across MMIO space. While the bug was in the mappings the warning was a little confusing: (XEN) d47v2 Rn should not be equal to Rt except for r31 (XEN) d47v2 unhandled Arm instruction 0x3d800000 (XEN) d47v2 Unable to decode instruction The Rn == Rt warning is only applicable to single register load/stores so add some verification steps before to weed out unexpected accesses. While at it update the Arm ARM references to the latest version of the documentation. Signed-off-by: Alex Bennée Cc: Manos Pitsidianakis --- v2 - use single line comments where applicable - update Arm ARM references - use #defines for magic numbers --- xen/arch/arm/decode.c | 35 ++++++++++++++++++++------ xen/arch/arm/decode.h | 57 ++++++++++++++++++++++++++++++++++++++----- 2 files changed, 79 insertions(+), 13 deletions(-) diff --git a/xen/arch/arm/decode.c b/xen/arch/arm/decode.c index 2537dbebc1..73a88e4701 100644 --- a/xen/arch/arm/decode.c +++ b/xen/arch/arm/decode.c @@ -87,15 +87,36 @@ static int decode_arm64(register_t pc, mmio_info_t *info) return 1; } + /* Check this is a load/store of some sort */ + if ( (opcode.top_level.op1 & TL_LDST_OP1_MASK) != TL_LDST_OP1_VALUE ) + { + gprintk(XENLOG_ERR, "Not a load/store instruction op1=%u\n", + opcode.top_level.op1); + goto bad_loadstore; + } + + /* We are only expecting single register load/stores */ + if ( (opcode.ld_st.op0 & LS_SREG_OP0_MASK) != LS_SREG_OP0_VALUE ) + { + gprintk(XENLOG_ERR, "Not single register load/store op0=%u\n", + opcode.ld_st.op0); + goto bad_loadstore; + } + /* - * Refer Arm v8 ARM DDI 0487G.b, Page - C6-1107 - * "Shared decode for all encodings" (under ldr immediate) - * If n == t && n != 31, then the return value is implementation defined - * (can be WBSUPPRESS, UNKNOWN, UNDEFINED or NOP). Thus, we do not support - * this. This holds true for ldrb/ldrh immediate as well. + * Refer Arm v8 ARM DDI 0487J.a, Page - K1-12586 + * + * STR (immediate) CONSTRAINED UNPREDICTABLE behaviour + * + * "If the instruction encoding specifies pre-indexed addressing or + * post-indexed addressing, and n == t && n != 31, then one of the + * following behaviors must occur:" UNDEFINED, NOP or UNKNOWN + * + * Execution @ EL0/EL1 when HCR_EL2.TIDCP is 1 traps to EL2 with + * EC = 0. * - * Also refer, Page - C6-1384, the above described behaviour is same for - * str immediate. This holds true for strb/strh immediate as well + * This also hold true for LDR (immediate), Page K1-12581 and + * the RB/RH variants of both. */ if ( (opcode.ldr_str.rn == opcode.ldr_str.rt) && (opcode.ldr_str.rn != 31) ) { diff --git a/xen/arch/arm/decode.h b/xen/arch/arm/decode.h index 13db8ac968..188114a71e 100644 --- a/xen/arch/arm/decode.h +++ b/xen/arch/arm/decode.h @@ -24,17 +24,54 @@ #include /* - * Refer to the ARMv8 ARM (DDI 0487G.b), Section C4.1.4 Loads and Stores - * Page 318 specifies the following bit pattern for - * "load/store register (immediate post-indexed)". + * Refer to the ARMv8 ARM (DDI 0487J.a) * - * 31 30 29 27 26 25 23 21 20 11 9 4 0 + * Section C A64 Instruct Set Encoding + * + * C4.1 A64 instruction set encoding: + * + * 31 30 29 28 25 24 0 * ___________________________________________________________________ - * |size|1 1 1 |V |0 0 |opc |0 | imm9 |0 1 | Rn | Rt | - * |____|______|__|____|____|__|_______________|____|_________|_______| + * |op0 | x x | op1 | | + * |____|______|______|_______________________________________________| + * + * op0 = 0 is reserved + * op1 = x1x0 for Loads and Stores + * + * Section C4.1.88 Loads and Stores + * + * 31 28 27 26 25 24 23 22 21 16 15 12 11 10 9 0 + * ___________________________________________________________________ + * | op0 | 1 | op1 | 0 | op2 | | op3 | | op4 | | + * |________|___|_____|___|_____|__|__________|______|_____|__________| + * + * Page C4-653 Load/store register (immediate post-indexed) + * + * 31 30 29 27 26 25 24 23 22 21 20 12 11 10 9 5 4 0 + * ___________________________________________________________________ + * |size|1 1 1 |V | 0 0 | opc |0 | imm9 | 0 1 | Rn | Rt | + * |____|______|__|_____|_____|__|_______________|_____|______|_______| */ union instr { uint32_t value; + struct { + unsigned int ign2:25; + unsigned int op1:4; /* instruction class */ + unsigned int ign1:2; + unsigned int op0:1; /* value = 1b */ + } top_level; + struct { + unsigned int ign1:10; + unsigned int op4:2; + unsigned int ign2:4; + unsigned int op3:6; + unsigned int ign3:1; + unsigned int op2:2; + unsigned int fixed1:1; /* value = 0b */ + unsigned int op1:1; + unsigned int fixed2:1; /* value = 1b */ + unsigned int op0:4; + } ld_st; struct { unsigned int rt:5; /* Rt register */ unsigned int rn:5; /* Rn register */ @@ -49,6 +86,14 @@ union instr { } ldr_str; }; +/* Top level load/store encoding */ +#define TL_LDST_OP1_MASK 0b0101 +#define TL_LDST_OP1_VALUE 0b0100 + +/* Load/store single reg encoding */ +#define LS_SREG_OP0_MASK 0b0011 +#define LS_SREG_OP0_VALUE 0b0011 + #define POST_INDEX_FIXED_MASK 0x3B200C00 #define POST_INDEX_FIXED_VALUE 0x38000400 -- 2.39.2 From xen-devel-bounces@lists.xenproject.org Wed Mar 06 17:02:39 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 17:02:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689402.1074321 (Exim 4.92) (envelope-from ) id 1rhuf4-0004AP-Iq; Wed, 06 Mar 2024 17:02:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689402.1074321; Wed, 06 Mar 2024 17:02:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhuf4-0004AI-GB; Wed, 06 Mar 2024 17:02:34 +0000 Received: by outflank-mailman (input) for mailman id 689402; Wed, 06 Mar 2024 17:02:33 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhuf3-0004AA-8D for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 17:02:33 +0000 Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [2607:f8b0:4864:20::733]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 520c2721-dbdb-11ee-afda-a90da7624cb6; Wed, 06 Mar 2024 18:02:32 +0100 (CET) Received: by mail-qk1-x733.google.com with SMTP id af79cd13be357-7882bcace1aso103346085a.1 for ; Wed, 06 Mar 2024 09:02:32 -0800 (PST) Received: from localhost ([213.195.118.74]) by smtp.gmail.com with ESMTPSA id q15-20020a05620a038f00b007883218feb7sm2384169qkm.97.2024.03.06.09.02.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Mar 2024 09:02:30 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 520c2721-dbdb-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709744551; x=1710349351; darn=lists.xenproject.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=aH3iAdE2KZA7E0mXRJz3+0UjEpDPnmp2g33ORB0Owz8=; b=QrKSnuKkB05p5NbncCrOrktAOcPcnO+/ge19YQYYt6C2bLddx6m3XjFUdS58JoeDtN CgS8pZwBvvHEdYOfFbYPRqlACA0SZmUgk480CnWWnhD3HkJH+ePv2mtRaMCfcChcTCet XGvLp2vnYfm3QMQllVVUqXI8CLfCa+kJJvIKo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709744551; x=1710349351; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=aH3iAdE2KZA7E0mXRJz3+0UjEpDPnmp2g33ORB0Owz8=; b=PIhZg8jI00Ot30Dkt1oJ/1Hryv/xtLjKr+fXJrc7DW44AcqPctLdRSSNlU2Inq5f8d NXS0OF8F7kuml35Ee04KxwVFuHFeQhk9NM9CxVeQa8z0bT5Ewclrk9SIfrGFY3QPeYja 0DiNsKZP3qwU9mcJnStPb8v6jAaxA9dsOT0X3qCQm0/7mxycmrCZTu7BynLttzfUrhMU Rjkt9XwTNGVtND/x57Y5mz3i/Yig/TLJS3DAjb/qmLVYdDoHXFYkB8UIGGA5oB4U+WZZ +sCt1s8f5VaYjJbylAH07stnbsG5GgGH9/6pNPyLta+qPFf3L4iD4bZztQTmhRr6xlZL dFmg== X-Gm-Message-State: AOJu0Yx0AAUpo5gZP+28pnAvX2Cet+iybfnIJndA1WaBCEra2flSzfYS GuVgSNozj1IHErw/nfyG/9k0cYVe4Dtbm3o/rce7qJqYDNGp9LYOf73wJYhJgrE= X-Google-Smtp-Source: AGHT+IHCqX1okO3vJvA0qv5VfxtysxHq6675ByxjtPdlOl6kgFugRJL4f+p9CNauCTreLTsFqtHsBQ== X-Received: by 2002:a05:620a:8511:b0:788:1837:4b52 with SMTP id pe17-20020a05620a851100b0078818374b52mr5354726qkn.72.1709744551121; Wed, 06 Mar 2024 09:02:31 -0800 (PST) Date: Wed, 6 Mar 2024 18:02:28 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: zithro / Cyril =?utf-8?Q?R=C3=A9bert?= Cc: xen-devel@lists.xenproject.org, Wei Liu , Anthony PERARD Subject: Re: [PATCH] docs/man: add shutdown reasons to xl (list) man page Message-ID: References: <019602d6da2ff78e6582b9b6aae6d76216e150c3.1709678713.git.slack@rabbit.lu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <019602d6da2ff78e6582b9b6aae6d76216e150c3.1709678713.git.slack@rabbit.lu> On Tue, Mar 05, 2024 at 11:45:13PM +0100, zithro / Cyril Rébert wrote: > Add the shutdown reasons to the paragraph of "xl list" concerning the > shutdown status. > I have copy/pasted the explanations from the source code : > > - tools/xl/xl_info.c (L379) > - xen/include/public/sched.h (starting L158) > > Suggested-by: Roger Pau Monné > Signed-off-by: Cyril Rébert / zithro Thanks for doing this, Anthony already provided some feedback. > --- > docs/man/xl.1.pod.in | 34 ++++++++++++++++++++++++++++++++++ > 1 file changed, 34 insertions(+) > > diff --git a/docs/man/xl.1.pod.in b/docs/man/xl.1.pod.in > index bed8393473..2b046f97f1 100644 > --- a/docs/man/xl.1.pod.in > +++ b/docs/man/xl.1.pod.in > @@ -370,6 +370,40 @@ scheduling by the Xen hypervisor. > The guest OS has shut down (SCHEDOP_shutdown has been called) but the > domain is not dying yet. > > +There are six shutdown reasons, which will be displayed after the "s" : B<-rscwS>. > + > +=over 4 > + > +=over 4 > + > +=item s- : poweroff > + > +Domain exited normally. Clean up and kill. > + > +=item sr : reboot > + > +Clean up, kill, and then restart. > + > +=item ss : suspend > + > +The domain is suspended. Clean up, save suspend info, kill. > + > +=item sc : crash > + > +Tell controller we've crashed. > + > +=item sw : watchdog > + > +Restart because watchdog time expired. > + > +=item sS : soft_reset > + > +Domain asked to perform 'soft reset' for it. The expected behavior is to reset internal Xen state for the domain returning it to the point where it was created but leaving the domain's memory contents and vCPU contexts intact. This will allow the domain to start over and set up all Xen specific interfaces again. The man page sources are kept at 80 columns, can you please wrap this text so it doesn't exceed the 80 col limit? Roger. From xen-devel-bounces@lists.xenproject.org Wed Mar 06 17:03:13 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 17:03:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689405.1074332 (Exim 4.92) (envelope-from ) id 1rhufg-0004dM-S0; Wed, 06 Mar 2024 17:03:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689405.1074332; Wed, 06 Mar 2024 17:03:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhufg-0004dF-OG; Wed, 06 Mar 2024 17:03:12 +0000 Received: by outflank-mailman (input) for mailman id 689405; Wed, 06 Mar 2024 17:03:12 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhufg-0004AA-51 for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 17:03:12 +0000 Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [2a00:1450:4864:20::334]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 69b55285-dbdb-11ee-afda-a90da7624cb6; Wed, 06 Mar 2024 18:03:11 +0100 (CET) Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-412e96284b9so17527925e9.3 for ; Wed, 06 Mar 2024 09:03:11 -0800 (PST) Received: from [192.168.69.100] (vau06-h02-176-184-43-100.dsl.sta.abo.bbox.fr. [176.184.43.100]) by smtp.gmail.com with ESMTPSA id u21-20020a7bc055000000b004129a1097e7sm24003609wmc.12.2024.03.06.09.03.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 Mar 2024 09:03:10 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 69b55285-dbdb-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1709744591; x=1710349391; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:references:cc:to:from :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=r2aSHjVP+Xu8BA7aiHVPv6ilPDdzaBKFNJurg14KCaA=; b=APIkE72vYt8RezoIHgKYIOtqmquM86KQZTqKEcBoL1lqeRX8PE01UhteMiyKHz306a ZsW1tBZPugHHojL4ZxRZvYgcibkhL6cFpn35RcR0z6xnD6PKIZcoJ9Ld1h8g76frPpW9 P1jG5RxyLKh0q2F69e5MVdf6tiiyyQ4lqCDuifn1LuyprMWPPKHdvzHEQNMTBILRv1lW EZ0fhl7TGS3rSImNS92U8XLKEvx+DygKTYtv3Jg4KHqY1OPiD0E4HEQfV+a10I91cVul 6OgyNDiANlxu36F41XULgsguSEg3dcxqr0av3ctQ3zDtRntmikiLkBxtjCyhCcXzk3f4 xWRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709744591; x=1710349391; h=content-transfer-encoding:in-reply-to:references:cc:to:from :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=r2aSHjVP+Xu8BA7aiHVPv6ilPDdzaBKFNJurg14KCaA=; b=dImpclzI2GabZDCWKz31hC6hathR8B88xy/WsYNyqVuBgpsy6N2pavGBWYCI8k6kCm +mjHuIqsaEiqej+JIN01z1TS+fzYtFNibI43jMdSWbOEfqP0d/dvq2dZ57T4kRtQLSQm 2CHAjehBGgt6/miz/ZfsN5rnr/jPo8j/jGzcHlMkGA/wuwaP7GSkhl1PMo9q4NRRVbrC KXzgxIpZ8JfPG+6X7P1SpA0YzKvS4tTWaerVKr2h3SbKvIhovQNrhuNfYy3J4sN3L6oH +MxcLhQJ8ciRstJGRgFjtRhNmcCErSpYhegFO9qlMNitSDWsga/ZULtYmNEGIQBN1e86 K2qQ== X-Forwarded-Encrypted: i=1; AJvYcCWVwvyjwhGpJVF6+Ov5NjWJL9vW67Gl4chxoUQ4E2t40xXrB9B7iO3cv+pW+bNoAz4LTA/bsnEdIxYBfbsFt0fm1c4j38u358lVMd77KOk= X-Gm-Message-State: AOJu0YxOofIL1n1U9o8Y7FOlAw8vZaHXDLz27G7RI2pFXU/DxMTddz2t xW4J0K+2MA8FF7yEV78a1ylsX8Fn5f83GP4yg5dei51efL4+wRtnGE4gUiW4ROg= X-Google-Smtp-Source: AGHT+IEsDTdAWujgDph7eInjSucsXEx2XwJLDZSG22OQUW1INRiZK92/ydMK1V2qWC2wu4aeYu1cUg== X-Received: by 2002:a05:600c:1d9e:b0:412:ef25:aaa5 with SMTP id p30-20020a05600c1d9e00b00412ef25aaa5mr3453077wms.36.1709744590971; Wed, 06 Mar 2024 09:03:10 -0800 (PST) Message-ID: Date: Wed, 6 Mar 2024 18:03:08 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH-for-9.0 0/9] hw/xen: Have ARM targets use common xen_memory_listener Content-Language: en-US From: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Cc: Anthony Perard , Paul Durrant , David Woodhouse , Thomas Huth , qemu-arm@nongnu.org, Stefano Stabellini , Paolo Bonzini , =?UTF-8?Q?Alex_Benn=C3=A9e?= , xen-devel@lists.xenproject.org References: <20231114163123.74888-1-philmd@linaro.org> <0064f684-793e-4954-90cf-d39c21385a43@linaro.org> In-Reply-To: <0064f684-793e-4954-90cf-d39c21385a43@linaro.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit ping ^ 2 On 13/12/23 18:00, Philippe Mathieu-Daudé wrote: > ping? > > On 14/11/23 17:31, Philippe Mathieu-Daudé wrote: >> Hi, >> >> While looking at Xen target-specific code, I noticed some >> generic code used by x86 which is not implemented for ARM. >> >> Maybe ARM machines don't need it, I don't know. But I >> wanted to see if I can get this common code target agnostic >> and build it once, possibly bringing smth useful to ARM. >> >> The changes don't break CI testing and Avocado local tests. >> If this xen_memory_listener feature isn't required for ARM, >> I'll send follow up patch that keep this series with common >> xen_memory_listener but with a runtime flag to disable. >> >> Patches do the usual "change target-specific API to a >> target-agnostic one", in particular using "exec/target_page.h" >> at runtime. Then non-x86 code is extracted, then merged to >> the generic xen/xen-hvm-common.c. >> >> Thoughts? >> >> Regards, >> >> Phil. >> >> Based-on: <20231114143816.71079-1-philmd@linaro.org> > From xen-devel-bounces@lists.xenproject.org Wed Mar 06 17:10:03 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 17:10:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689410.1074341 (Exim 4.92) (envelope-from ) id 1rhumD-0005c1-KL; Wed, 06 Mar 2024 17:09:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689410.1074341; Wed, 06 Mar 2024 17:09:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhumD-0005bu-Hr; Wed, 06 Mar 2024 17:09:57 +0000 Received: by outflank-mailman (input) for mailman id 689410; Wed, 06 Mar 2024 17:09:56 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhumC-0005bm-L8 for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 17:09:56 +0000 Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [2607:f8b0:4864:20::102c]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 5994fac7-dbdc-11ee-a1ee-f123f15fe8a2; Wed, 06 Mar 2024 18:09:54 +0100 (CET) Received: by mail-pj1-x102c.google.com with SMTP id 98e67ed59e1d1-29b73427790so784464a91.3 for ; Wed, 06 Mar 2024 09:09:54 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 5994fac7-dbdc-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1709744993; x=1710349793; darn=lists.xenproject.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=0U80Crry40Slv1QE3y4yJdbKCWDS4Dp/mIdju7FW9SY=; b=ip2KPp+6g4ihG90CNErqJ6YYnObk3y6aeay+kMb75dowhA42/iX/AudSVLyG1k1Fbs Ya730tk/IIEVCsdg35qG6Xuh7I7JtmCw74rFUL6Bm6m0+maWdkoeFZ8BgJdEnKMvgZ4B 4q2X+AUaZYHh1dvtdMFud/ms9DrVj5xU+1txw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709744993; x=1710349793; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=0U80Crry40Slv1QE3y4yJdbKCWDS4Dp/mIdju7FW9SY=; b=hzqLDbz1N9KpLymeoXMEEkO46tazwMWtbdJ5Ydm7GrK2ocV1i9KKjNScJ2bL0fFy/m 5/6S+F8gVpCuTDWCXuM8wDyGJCpuUBuMGyNcH/J/Gg/DLNfSb1T0zRx4PxGaeOc4hZri gThhaneDnz/iozROuPhDbGSyP4aDpPjL2Jb0CQAjCocsANSJoDkA2Z8nIHcVZqn+jfyK /WKrukax73PGAFCAQripKi9hIwdbygO0qTCOi5cqaYro6NmbEUS815E1UHovotjAzPcJ 62Nv8hlE9ppTS/Z0ETKOUqVBrEh/Ht3aT0w8prgiyEKbiBgYqwuq7GlEpiGfjfy02nzu mauA== X-Forwarded-Encrypted: i=1; AJvYcCWoZOKp+UOURj4s0AEhgArZe7rrer0z5J3ULCdq0vJ1dZ/utLoW6pUdZMXWq/ItGvX2se0j/RjjZN8ExW0SDgxI8wJmJAavsTnc4wGwbSg= X-Gm-Message-State: AOJu0YzUtoOti+Nt4PMmEO7Q4cBnKgC09IA9ll8xMAY1PAEZSM9veHZN 6FYHRMPB+J4lIsK8aUDicLYuU41Fp0B1X863f1ZRlYfo9Rp3L/r/v//FJth1URiHpteWevTxy8i gknUExL1RMZSe+AYKRXAM0TRbDqbg9Jfi+7L1 X-Google-Smtp-Source: AGHT+IEkmpN7bv6DxA5SoOjFMDhoe9ugxZa6H1WJwPAUjdogQ4dceczaGLsE4BTAgctP6pwbPb8paqPW/U/Bs6BjYGg= X-Received: by 2002:a17:90b:17c9:b0:29b:6c0b:9c34 with SMTP id me9-20020a17090b17c900b0029b6c0b9c34mr3955463pjb.19.1709744993060; Wed, 06 Mar 2024 09:09:53 -0800 (PST) MIME-Version: 1.0 References: <20240305121121.3527944-1-andrew.cooper3@citrix.com> <20240305121121.3527944-3-andrew.cooper3@citrix.com> <87b82706-f538-4807-abaf-1e59cebd286b@suse.com> In-Reply-To: <87b82706-f538-4807-abaf-1e59cebd286b@suse.com> From: Ross Lagerwall Date: Wed, 6 Mar 2024 17:09:40 +0000 Message-ID: Subject: Re: [PATCH 2/3] xen/virtual-region: Include rodata pointers To: Jan Beulich Cc: Andrew Cooper , Konrad Rzeszutek Wilk , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Mar 5, 2024 at 2:17=E2=80=AFPM Jan Beulich wrot= e: > > On 05.03.2024 13:11, Andrew Cooper wrote: > > --- a/xen/include/xen/virtual_region.h > > +++ b/xen/include/xen/virtual_region.h > > @@ -16,6 +16,9 @@ struct virtual_region > > const void *text_start; /* .text virtual address st= art. */ > > const void *text_end; /* .text virtual address en= d. */ > > > > + const void *rodata_start; /* .rodata virtual address = start (optional). */ > > + const void *rodata_end; /* .rodata virtual address = end. */ > > + > > /* If this is NULL the default lookup mechanism is used. */ > > symbols_lookup_t *symbols_lookup; > > While perhaps the least bad one can do without quite a bit more churn, > I'm still irritated by a virtual region (singular) suddenly covering > two ranges of VA space. At the very least I think the description should > say a word of justification in this regard. An alternative, after all, > could have been for livepatch code to register separate regions for > rodata (if present in a patch). > > A follow-on question then would be why ordinary data isn't reflected in > a virtual region. Aiui that's just because livepatch presently has no > need for it. > > Underlying question to both: Is the virtual region concept indeed meant > to be fully tied to livepatch and its needs? > Virtual regions were introduced for live patching but I don't think it is completely tied to live patching. It was introduced so that any code can participate in symbol lookup, bug frame and exception table entry search, rather than special casing "if livepatch" in many places. I agree that the virtual region concept is being abused here - it's just being used as a convenient place to store rodata start/end and doesn't really have much to do with the text start & end / bug frame / exception table entry search that the virtual region is intended for. Maybe Andrew can explain why he used this approach? Ross From xen-devel-bounces@lists.xenproject.org Wed Mar 06 17:10:27 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 17:10:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689412.1074352 (Exim 4.92) (envelope-from ) id 1rhumg-0006ww-Sw; Wed, 06 Mar 2024 17:10:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689412.1074352; Wed, 06 Mar 2024 17:10:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhumg-0006wn-PR; Wed, 06 Mar 2024 17:10:26 +0000 Received: by outflank-mailman (input) for mailman id 689412; Wed, 06 Mar 2024 17:10:25 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhumf-0006wT-UJ for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 17:10:25 +0000 Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [2a00:1450:4864:20::431]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 6c400776-dbdc-11ee-afda-a90da7624cb6; Wed, 06 Mar 2024 18:10:25 +0100 (CET) Received: by mail-wr1-x431.google.com with SMTP id ffacd0b85a97d-33d118a181fso4565998f8f.1 for ; Wed, 06 Mar 2024 09:10:25 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6c400776-dbdc-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709745025; x=1710349825; darn=lists.xenproject.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=6OBT5bXPkoyKLfYbddxD+ROvxBpl2W6PqRGiln/kPZA=; b=NwVumK0/Qw8Hq6ldQfJBVNojI9QnOfjhiHLT4PEbIJnxWnmIuapRiBD7NIKrk4EQ7V 33J+4fD1bcEPwF+4lrHhn2mw7UV3lOwBfdHs9YJpYv4EOwSwC17M2wpKpTMZwjGAFHwr 5Gi+n5rw1FtDEHwzGhz/4hKnd1Aa4O3jGOutf9wuXv15DkBnh7ukA3KAHcw/i0EXsl9/ M0b2NkHiIi+0mdq9906yTCTHIV/N2jLR2r3oikRe2nhtSECUjRd56j9NM34jnZxRvPct rnu47ivGIN4mcoCxZy1+uejeBKvvP05M9YyOINAY+qDw3KKWI5xlQmTRmtMidg/wcuBP x51w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709745025; x=1710349825; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=6OBT5bXPkoyKLfYbddxD+ROvxBpl2W6PqRGiln/kPZA=; b=rnAZ5n+cL/kAvAMfusABYI3hyCbnF74iHtrzjWEYO05Fa8thZyaaY+mf9w+3I/xYsk LwCAHkiEFE7Sav5v3mT6ZjPSgvxPJ7ucIH+H95kBkjSMjf6MPtix+RAOI08XYsj/fn/2 orrOhnGj/Pd5vMVOod/mWYkIMTcuGF1E5J0XJIdN90+vYJg+cVOLOWb9pP1czCGNq5cN CwTfjCC2lAXgf5O+Q45GWvEnSNsfQGQ9hfX2iYhm0b/yKf5lgNOVGGy5Y1EgSKguDWtU FgZ8mk/Og2bX+EC1RRyQjmCA0A3wqKjwxMCwnAOAykck4iQ/eohYrrh3YYjLN9s1yY+B 38Hg== X-Forwarded-Encrypted: i=1; AJvYcCV4hy7BnlzkKGJR5QM3jHKdg0VzBB0Eo7xs4sDDIaUsvkU7JqF97gDeF4SRCCTggQJrTZsse1IoEVcNS3BN8hkzpzvppjNLcpNx+7l7fOk= X-Gm-Message-State: AOJu0Yz3kcPShIeHHfKzIgVLny7z84uSAFaf2NJ7q4AFkyQZ3P7sWMDA MxRBB8zo7YVJKQEzpOd5HNf7+jVatTKpKTKQM6mis9kObeGvRz2f6Bxm+ic8lCUAucQXn+WhKdy 67lHesiXyyZjoZEearUrY1RyKEWc= X-Google-Smtp-Source: AGHT+IHaHVgqaJ3Ya0z3ySAjTfGHID85e3oHDABmYYIqlhem3rnxGpjGokEsyeU7EVdhOrO/Ul5MOUMj1O2grGSJe8Q= X-Received: by 2002:adf:f74d:0:b0:33e:cc6:a998 with SMTP id z13-20020adff74d000000b0033e0cc6a998mr10007258wrp.6.1709745024405; Wed, 06 Mar 2024 09:10:24 -0800 (PST) MIME-Version: 1.0 References: <20240305030516.41519-1-alexei.starovoitov@gmail.com> <20240305030516.41519-3-alexei.starovoitov@gmail.com> In-Reply-To: From: Alexei Starovoitov Date: Wed, 6 Mar 2024 09:10:13 -0800 Message-ID: Subject: Re: [PATCH v4 bpf-next 2/2] mm: Introduce VM_SPARSE kind and vm_area_[un]map_pages(). To: Christoph Hellwig Cc: bpf , Daniel Borkmann , Andrii Nakryiko , Linus Torvalds , Barret Rhoden , Johannes Weiner , Lorenzo Stoakes , Andrew Morton , Uladzislau Rezki , Mike Rapoport , Boris Ostrovsky , sstabellini@kernel.org, Juergen Gross , linux-mm , xen-devel@lists.xenproject.org, Kernel Team Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Mar 6, 2024 at 6:19=E2=80=AFAM Christoph Hellwig wrote: > > I'd still prefer to hide the vm_area, but for now: > > Reviewed-by: Christoph Hellwig Thank you. I will think of a way to move get_vm_area() to mm/internal.h and propose a plan by lsf/mm/bpf in May. From xen-devel-bounces@lists.xenproject.org Wed Mar 06 17:15:05 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 17:15:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689419.1074362 (Exim 4.92) (envelope-from ) id 1rhur6-00081Y-CO; Wed, 06 Mar 2024 17:15:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689419.1074362; Wed, 06 Mar 2024 17:15:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhur6-00081R-9o; Wed, 06 Mar 2024 17:15:00 +0000 Received: by outflank-mailman (input) for mailman id 689419; Wed, 06 Mar 2024 17:14:58 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhur4-00081L-Ge for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 17:14:58 +0000 Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [2a00:1450:4864:20::631]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 0dfcfe0f-dbdd-11ee-a1ee-f123f15fe8a2; Wed, 06 Mar 2024 18:14:56 +0100 (CET) Received: by mail-ej1-x631.google.com with SMTP id a640c23a62f3a-a293f2280c7so2755666b.1 for ; Wed, 06 Mar 2024 09:14:56 -0800 (PST) Received: from [192.168.69.100] (vau06-h02-176-184-43-100.dsl.sta.abo.bbox.fr. [176.184.43.100]) by smtp.gmail.com with ESMTPSA id m26-20020a17090607da00b00a441ff174a3sm7372337ejc.90.2024.03.06.09.14.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 Mar 2024 09:14:55 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 0dfcfe0f-dbdd-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1709745296; x=1710350096; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=XjsyNthJQ6LEz6SX9rxTBbqUR1TTwhwhwoVKkXhpUAw=; b=E9NNxDZ5lE3kZLG7sekTYtw+9442Fex4Esv+GCbSLxposYVYgnULzLGMZoLJUQTONC gBj3otcl75DXus59OV2jEW9CSYjbcxmRDdJTZVwspgG6A/yC1Jg9BIylNXzLf89GUbEk KQ+wFFDagSVFmXQXKTF6dUwbv3xvvEFi9PVih1OaXF5pIbppwBLLp7ZkfKe+7sXNDzEs 4EAMw/WZgpJ55vfcwhhalZtc9aCmKmMX6AKZDJ2OMCv0prENBCZ/S8f0NTNeK2DQNM1j oCQjWUHo/b+7XqmFq1etfJ/3venrYULFgvSmPDOv7WpZiwl9Dg3GM8NxcQnLaUIVLxYD FEhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709745296; x=1710350096; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=XjsyNthJQ6LEz6SX9rxTBbqUR1TTwhwhwoVKkXhpUAw=; b=np/Ba06Q1t1FB4xs1wcLu7Bh+zayenPazkF93xUTBbZGhtDkHZ4gSOtfqDmcPHRv7I 9yNFpRiF0395aS7snH2B6vH80+AYJ+VC5NRx34je1ocxF0hBsHLtocGlGPc2gWxd4iJx 4DAe7eIkTQXkn56e6QXh06ik39GDIt/88Sk/zOvxZrqmLa+U6pGZdw+I/RCHssCZXJuN P9QzAAyuM/Ycs0nEDytQQGApHHYRRQNWkIc1Ec4JFtjT2MDzUTW+8Kf94b4/sR28rh9j dJMvfoO/EJwP7sFKJvPhDJMzOoaZEd2OskNK8e/I6ITCdR/bKyR8MGy0tclJ/LpYE4sW iehQ== X-Forwarded-Encrypted: i=1; AJvYcCUz/fn2Ts+3ZbGND2tmGnw2c68Pg39lDHQAwFXogSKyPZI672rAEnb5+c1CAvwzpaZkZSG4jkXhKA9i9ArRtEi94E6GgcoCEkPxfqJTdiQ= X-Gm-Message-State: AOJu0YyfzSqXAUgjbTq5mgZghbg2lgrdzj23ATv2IrXqBHW0hspy8vBd IPWlngQWHAdijheDYaRExHaudxMxC+VTEqbzM6T5T+VWUO48pAFusKsBaguHRGY= X-Google-Smtp-Source: AGHT+IEzDMCAv1jmeGC0ooiGaix7vjr0dWNnW+e2K3+cHwRyHziRS4ipyA3ZMUpeB9SviZ5lAMKGMA== X-Received: by 2002:a17:906:b154:b0:a45:da1:9375 with SMTP id bt20-20020a170906b15400b00a450da19375mr7102659ejb.30.1709745295992; Wed, 06 Mar 2024 09:14:55 -0800 (PST) Message-ID: <68c4a4ad-cc49-4917-b1d6-d0f28b611c05@linaro.org> Date: Wed, 6 Mar 2024 18:14:52 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH-for-9.0 v2 10/19] hw/xen: Rename 'ram_memory' global variable as 'xen_memory' Content-Language: en-US To: David Woodhouse , David Woodhouse , qemu-devel@nongnu.org Cc: =?UTF-8?Q?Alex_Benn=C3=A9e?= , Paul Durrant , qemu-arm@nongnu.org, Paolo Bonzini , Stefano Stabellini , Richard Henderson , xen-devel@lists.xenproject.org, qemu-block@nongnu.org, Anthony Perard , kvm@vger.kernel.org, Thomas Huth , Peter Maydell , Eduardo Habkost , "Michael S. Tsirkin" , Marcel Apfelbaum References: <20231114143816.71079-1-philmd@linaro.org> <20231114143816.71079-11-philmd@linaro.org> <84F1C2D8-4963-4815-8079-B44081234D41@infradead.org> From: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= In-Reply-To: <84F1C2D8-4963-4815-8079-B44081234D41@infradead.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 14/11/23 16:49, David Woodhouse wrote: > On 14 November 2023 09:38:06 GMT-05:00, "Philippe Mathieu-Daudé" wrote: >> To avoid a potential global variable shadow in >> hw/i386/pc_piix.c::pc_init1(), rename Xen's >> "ram_memory" as "xen_memory". >> >> Signed-off-by: Philippe Mathieu-Daudé > > Well OK, but aren't you going to be coming back later to eliminate global variables which are actually per-VM? > > Or is that the point, because *then* the conflicting name will actually matter? Eh I wasn't thinking about running 2 Xen VMs in the same QEMU process, but this is a good test case. I was thinking of running a Xen guest VM and another TCG VM in the same process. So IIUC xen_memory should be part of PCMachineState. > > Reviewed-by: David Woodhouse Thanks! From xen-devel-bounces@lists.xenproject.org Wed Mar 06 17:16:38 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 17:16:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689422.1074372 (Exim 4.92) (envelope-from ) id 1rhuse-00006e-Nb; Wed, 06 Mar 2024 17:16:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689422.1074372; Wed, 06 Mar 2024 17:16:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhuse-00006X-KN; Wed, 06 Mar 2024 17:16:36 +0000 Received: by outflank-mailman (input) for mailman id 689422; Wed, 06 Mar 2024 17:16:34 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhusc-00006P-LL for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 17:16:34 +0000 Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [2a00:1450:4864:20::136]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 4752ef5a-dbdd-11ee-a1ee-f123f15fe8a2; Wed, 06 Mar 2024 18:16:32 +0100 (CET) Received: by mail-lf1-x136.google.com with SMTP id 2adb3069b0e04-512b3b04995so5602466e87.3 for ; Wed, 06 Mar 2024 09:16:32 -0800 (PST) Received: from [192.168.69.100] (vau06-h02-176-184-43-100.dsl.sta.abo.bbox.fr. [176.184.43.100]) by smtp.gmail.com with ESMTPSA id m26-20020a17090607da00b00a441ff174a3sm7372337ejc.90.2024.03.06.09.16.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 Mar 2024 09:16:31 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 4752ef5a-dbdd-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1709745392; x=1710350192; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=MTstlGT/a18Frjz+rGLei+v7kWgyirApdQCesjszieE=; b=PAkjQpC7glJceQnF0s+8OVBPNvN85azfrlUTB0dm74iIwXT231JosVg9HzhCnbGqya S9TeUfcikREg/vRtLGfh8H6qzbGAvLDvHhC377ZVkjl5czRgWvaeEQSMpyB2TTVQoDpv mRS0+kMPpH1WlrLNtHQZFyPoY5rRgl6A9lSExN7cCrkU8tif3lgY+qegzt/cmwxb9HYX LA2ditSGkij/WfRTeWQhXhoCzjr3Og+k3LNsorg9N25rz1OtHQ8xaAPYo6e+cuc/09Zx Z+dSVRj2pT5oXVpcW1lJBfIj/egwdJ3WCNQ2UQT1/+npTrV4ly4QDxFr7bJk1XggsmFi jySA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709745392; x=1710350192; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=MTstlGT/a18Frjz+rGLei+v7kWgyirApdQCesjszieE=; b=wMSWG9PxRFxzAq25BN2RLWjtgtyBkj9dt/I8Y8MjswV825HGrXf9v0KukWKcmGmDk5 i1J+Kqwq8GI5GJV1eP+jBpYGUK8D7F0UdouflotSXE2p6WpqHTNWTidcpO3DXipN4rBO WBhF/lA2RgPYa7Rjlpo5UbclQhsPAx/9RN1yu+ahWHjORDKA3AdBOw2bm+FQQdF+t24F mVqeuwC0lQdX8mK4vH+3+oY/rGZTpD4MmWBv7MYAFTmZIR0heOKXD9T54OO/x5xYr8wr QGUxMDmEH9UekXwPvlpHozCLTYi2BpzglrXWJ/rTvTooFQ+lG2LEhlvaVwVT9tbfHjDi wdJA== X-Forwarded-Encrypted: i=1; AJvYcCVrJu8l+G/c6GDv3m1shWndVie2nUgNMYlmBKeYt7Y9GtYp4hX4//LYMjOVry10ufi2GuRatw8fLAtb2gSOycx6/y6wpROrjv0MsVHlxLg= X-Gm-Message-State: AOJu0Yz4FkZdQKIm2A3mKxp9shNvHsqm4/ne7NU/Q4WrnCOfrmLZGUpM vLf5ZO7HGj/swdRN+gWUJGVg/562/sw/SC8rdrPwmGC0X/7L39TfeXHa75mW/OU= X-Google-Smtp-Source: AGHT+IEEEm27HQQ1yt59I8k1pXk5Kp9RWbi0wEjybB+XpiWEN9134OAxfJLk1YHC0bnesbA0/Cv8CA== X-Received: by 2002:a05:6512:1152:b0:513:5203:e255 with SMTP id m18-20020a056512115200b005135203e255mr4652979lfg.7.1709745392070; Wed, 06 Mar 2024 09:16:32 -0800 (PST) Message-ID: <6de50dbc-9525-4e25-ba70-55aea0d3f044@linaro.org> Date: Wed, 6 Mar 2024 18:16:29 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH-for-9.0 v2 13/19] hw/xen: Remove use of 'target_ulong' in handle_ioreq() Content-Language: en-US To: David Woodhouse , qemu-devel@nongnu.org Cc: =?UTF-8?Q?Alex_Benn=C3=A9e?= , Paul Durrant , qemu-arm@nongnu.org, Paolo Bonzini , David Woodhouse , Stefano Stabellini , Richard Henderson , xen-devel@lists.xenproject.org, qemu-block@nongnu.org, Anthony Perard , kvm@vger.kernel.org, Thomas Huth , Anton Johansson References: <20231114143816.71079-1-philmd@linaro.org> <20231114143816.71079-14-philmd@linaro.org> From: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= In-Reply-To: <20231114143816.71079-14-philmd@linaro.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc'ing Anton. On 14/11/23 15:38, Philippe Mathieu-Daudé wrote: > Per commit f17068c1c7 ("xen-hvm: reorganize xen-hvm and move common > function to xen-hvm-common"), handle_ioreq() is expected to be > target-agnostic. However it uses 'target_ulong', which is a target > specific definition. > > Per xen/include/public/hvm/ioreq.h header: > > struct ioreq { > uint64_t addr; /* physical address */ > uint64_t data; /* data (or paddr of data) */ > uint32_t count; /* for rep prefixes */ > uint32_t size; /* size in bytes */ > uint32_t vp_eport; /* evtchn for notifications to/from device model */ > uint16_t _pad0; > uint8_t state:4; > uint8_t data_is_ptr:1; /* if 1, data above is the guest paddr > * of the real data to use. */ > uint8_t dir:1; /* 1=read, 0=write */ > uint8_t df:1; > uint8_t _pad1:1; > uint8_t type; /* I/O type */ > }; > typedef struct ioreq ioreq_t; > > If 'data' is not a pointer, it is a u64. > > - In PIO / VMWARE_PORT modes, only 32-bit are used. > > - In MMIO COPY mode, memory is accessed by chunks of 64-bit > > - In PCI_CONFIG mode, access is u8 or u16 or u32. > > - None of TIMEOFFSET / INVALIDATE use 'req'. > > - Fallback is only used in x86 for VMWARE_PORT. > > Masking the upper bits of 'data' to keep 'req->size' low bits > is irrelevant of the target word size. Remove the word size > check and always extract the relevant bits. > > Signed-off-by: Philippe Mathieu-Daudé > --- > hw/xen/xen-hvm-common.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/hw/xen/xen-hvm-common.c b/hw/xen/xen-hvm-common.c > index bb3cfb200c..fb81bd8fbc 100644 > --- a/hw/xen/xen-hvm-common.c > +++ b/hw/xen/xen-hvm-common.c > @@ -1,5 +1,6 @@ > #include "qemu/osdep.h" > #include "qemu/units.h" > +#include "qemu/bitops.h" > #include "qapi/error.h" > #include "trace.h" > > @@ -426,9 +427,8 @@ static void handle_ioreq(XenIOState *state, ioreq_t *req) > trace_handle_ioreq(req, req->type, req->dir, req->df, req->data_is_ptr, > req->addr, req->data, req->count, req->size); > > - if (!req->data_is_ptr && (req->dir == IOREQ_WRITE) && > - (req->size < sizeof (target_ulong))) { > - req->data &= ((target_ulong) 1 << (8 * req->size)) - 1; > + if (!req->data_is_ptr && (req->dir == IOREQ_WRITE)) { > + req->data = extract64(req->data, 0, BITS_PER_BYTE * req->size); > } > > if (req->dir == IOREQ_WRITE) From xen-devel-bounces@lists.xenproject.org Wed Mar 06 17:22:16 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 17:22:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689428.1074381 (Exim 4.92) (envelope-from ) id 1rhuy3-0002fY-Ac; Wed, 06 Mar 2024 17:22:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689428.1074381; Wed, 06 Mar 2024 17:22:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhuy3-0002ez-7x; Wed, 06 Mar 2024 17:22:11 +0000 Received: by outflank-mailman (input) for mailman id 689428; Wed, 06 Mar 2024 17:22:10 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhuy2-0002et-Ke for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 17:22:10 +0000 Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [2607:f8b0:4864:20::736]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id f445cf05-dbdd-11ee-afda-a90da7624cb6; Wed, 06 Mar 2024 18:21:23 +0100 (CET) Received: by mail-qk1-x736.google.com with SMTP id af79cd13be357-7884384438dso776485a.1 for ; Wed, 06 Mar 2024 09:21:23 -0800 (PST) Received: from [10.80.67.149] (default-46-102-197-194.interdsl.co.uk. [46.102.197.194]) by smtp.gmail.com with ESMTPSA id pa7-20020a056214480700b0068f8a21a065sm7692538qvb.13.2024.03.06.09.21.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 Mar 2024 09:21:21 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f445cf05-dbdd-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709745682; x=1710350482; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=1nxCopfxV6EPaal9AV9NrrH/uSsPcKDTN5Lg9Eqtxm0=; b=STH8+PseeWnXHqGh1GFJOFAVTEjmQS5VWeRB7zeZvPBQFCEd4o3m6mkxiCX7xajZfD DmaLpolCfA4y+z0UbGb/Bx7qGTfUad+TCnifRy9tYsDjQiX4ustSz0W4lnmx0j/Z+Xp7 rixgR7xX5EsfmAewBB23UsEAwH9+asHtqu65E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709745682; x=1710350482; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=1nxCopfxV6EPaal9AV9NrrH/uSsPcKDTN5Lg9Eqtxm0=; b=rk0Pf9SDMjiJNvnqWldZ2+h1HnHlXQGgl3Gtr6MUCTrhgHWRKrBmBgnjk7XSxPe5bq G6JJMm6u9z4zeoDDp+GhTBdagq1cpFOTp0O6ZXmrFxyk+JANv24oeUl8a+9+s8y/2Ap3 rG3JtIWOU/C6rbzVcyij8d+5AK7u1MXkTB+MpBZdlhkTTdkgqBv03XLm6ZG4m8KzOzCv AKTr68CX63KH2V8wsm7c3dzKNNu29fWKOXPW8HuN/iERJaac/f6C8e/whlITXaPDLD27 xXimxoVZz01Ns6ZRkmw4ugoGi5CO55u8z34KKkGoywUbdFKrnIblzl5nK5wxEinF9dyC 2vwQ== X-Forwarded-Encrypted: i=1; AJvYcCW+kriAvZbFccpsMLi8ZSXRp80+nmDeV+p7F7J/FCzTYsBc65G6qOLaB3o2qi3p2kJNa0mPsAU2k9oz0befh/PuLfXN5/YbRjvrC/4Ia5s= X-Gm-Message-State: AOJu0YwpixJGYwZTvXKK5Ri4YAUtFW1yDeM3T5Of11t8P2T/PGrLYCFc 4P265pPTsi+UMv8btdq/6wrzK9ijQlO3JJfdAu6dzEKs7U3ZCDlHv3Fza0RdLQInxJ4cr6G4fwG X X-Google-Smtp-Source: AGHT+IHZDpEhAuKepksGbYvfCWJt9FC0LhsmdRD5cSIpZSd48qCFy29X3e4nnc1HI9Z+8HxVASL6/A== X-Received: by 2002:ad4:56e3:0:b0:68f:edeb:6b8c with SMTP id cr3-20020ad456e3000000b0068fedeb6b8cmr4999098qvb.12.1709745682250; Wed, 06 Mar 2024 09:21:22 -0800 (PST) Message-ID: <82126c3a-0cde-452f-86aa-2571482f42aa@citrix.com> Date: Wed, 6 Mar 2024 17:21:19 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/3] xen/virtual-region: Include rodata pointers Content-Language: en-GB To: Ross Lagerwall , Jan Beulich Cc: Konrad Rzeszutek Wilk , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20240305121121.3527944-1-andrew.cooper3@citrix.com> <20240305121121.3527944-3-andrew.cooper3@citrix.com> <87b82706-f538-4807-abaf-1e59cebd286b@suse.com> From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 06/03/2024 5:09 pm, Ross Lagerwall wrote: > On Tue, Mar 5, 2024 at 2:17 PM Jan Beulich wrote: >> On 05.03.2024 13:11, Andrew Cooper wrote: >>> --- a/xen/include/xen/virtual_region.h >>> +++ b/xen/include/xen/virtual_region.h >>> @@ -16,6 +16,9 @@ struct virtual_region >>> const void *text_start; /* .text virtual address start. */ >>> const void *text_end; /* .text virtual address end. */ >>> >>> + const void *rodata_start; /* .rodata virtual address start (optional). */ >>> + const void *rodata_end; /* .rodata virtual address end. */ >>> + >>> /* If this is NULL the default lookup mechanism is used. */ >>> symbols_lookup_t *symbols_lookup; >> While perhaps the least bad one can do without quite a bit more churn, >> I'm still irritated by a virtual region (singular) suddenly covering >> two ranges of VA space. At the very least I think the description should >> say a word of justification in this regard. An alternative, after all, >> could have been for livepatch code to register separate regions for >> rodata (if present in a patch). >> >> A follow-on question then would be why ordinary data isn't reflected in >> a virtual region. Aiui that's just because livepatch presently has no >> need for it. >> >> Underlying question to both: Is the virtual region concept indeed meant >> to be fully tied to livepatch and its needs? >> > Virtual regions were introduced for live patching but I don't think it > is completely tied to live patching. It was introduced so that any code > can participate in symbol lookup, bug frame and exception table entry > search, rather than special casing "if livepatch" in many places. > > I agree that the virtual region concept is being abused here - it's just > being used as a convenient place to store rodata start/end and doesn't > really have much to do with the text start & end / bug frame / exception > table entry search that the virtual region is intended for. > > Maybe Andrew can explain why he used this approach? I feel the simplicity and obviousness of patch 3 speaks for itself. How do you propose fixing it differently. ~Andrew From xen-devel-bounces@lists.xenproject.org Wed Mar 06 17:29:10 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 17:29:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689434.1074392 (Exim 4.92) (envelope-from ) id 1rhv4k-0003MD-3t; Wed, 06 Mar 2024 17:29:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689434.1074392; Wed, 06 Mar 2024 17:29:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhv4k-0003M6-0o; Wed, 06 Mar 2024 17:29:06 +0000 Received: by outflank-mailman (input) for mailman id 689434; Wed, 06 Mar 2024 17:29:04 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhv4i-0003Ly-MQ for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 17:29:04 +0000 Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [2607:f8b0:4864:20::102a]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 05d76583-dbdf-11ee-a1ee-f123f15fe8a2; Wed, 06 Mar 2024 18:29:02 +0100 (CET) Received: by mail-pj1-x102a.google.com with SMTP id 98e67ed59e1d1-29b31254820so3034699a91.0 for ; Wed, 06 Mar 2024 09:29:02 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 05d76583-dbdf-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709746141; x=1710350941; darn=lists.xenproject.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Wo+d/Xr9lGCvYIjueal3SEaIryY8gDEHwf05Z8ZS13s=; b=goNwYS9wQ9wjSBKDpDnyXMKDzyq+n+fmWyGn5v6HiJ2Bi5dfWFNTDhke1AIszv6FO4 qrwVHL5++0VlG8+F0U3MdkNmLiKQl1RvGb2hEbI8QjPqcYvzoXTs6pXZbJvYQYTKeeWh Fli1os4FSMLimMTSHMkYSrLJfH9QzHg/JUFp5xOaNg0Tc4ZBOHbM+29c6zKGDiBpNmAH spAt2M3VtVq+mrMiWhhObTJLWntct3NtrNhP8l2A05kpMxX3NDEhhmVGNQV7TLVwyFuC ZTMrXgMnXyEG0q3qJUG4dfkp4w5iJ3DxPmTm55vzmGZfQvG/2KVSSYlLTPvqoiAki7b2 JMaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709746141; x=1710350941; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Wo+d/Xr9lGCvYIjueal3SEaIryY8gDEHwf05Z8ZS13s=; b=ELdEe4Ao/errSL04PqRcPawQp0DIdu+UUYyhStIn9aY6Fidrh4wH2NsO8WG/8/YKhz D2PYnIYtB7KAG2it0hkf4/cMlNZCP8Q+B6dBWfWmuDh6dMnwQ/Bb4utIl1u3s5ap6I1e zmQwmk0GZs5iYpzDP5NpcAnfJVvTG5MR0k/f8lfy6o4/egkUmwvxDxk61+jZ8ejvj8s7 MLIwXGya6hS+Gx4qyUAsjkoALDUqXLsABryXW9x7XTcua7OmArTimC1HmmbBvpG3oMiJ wkKAf0Qj88mQ1ITWxKJYyjVdGrl6WnrT5gbJbnaAniYSOTncERxbxIrQaviZDcH3ThDZ 21Yw== X-Gm-Message-State: AOJu0YwhX5YvYF+pp8JoMs0he/L8X/P3QT6RxcFy2aaOHhVf8gm/RaqC +338lVnBVocsqdz6bGgpaLNWWNsjkb1i0QfbThNYiXbkaLr7CYTDhPGdco44JymobHSyvMdTgA2 jG/14ERQi7yiZ0dR7OjD7YSuw7FAXb4L5gss= X-Google-Smtp-Source: AGHT+IHrFIb/6HH+eC1Cs2jKzwjkYPvAxyHsiGKlRjr2jbzcyMU/7KHLHmT8HduN9pt1aKRGdREp6ewAIBBxgd5s7j4= X-Received: by 2002:a17:90a:70f:b0:29b:7921:6b93 with SMTP id l15-20020a17090a070f00b0029b79216b93mr1612376pjl.47.1709746140781; Wed, 06 Mar 2024 09:29:00 -0800 (PST) MIME-Version: 1.0 References: <6ba9568a-ff8e-48ad-907f-74303e04d3a2@suse.com> <2eafe45b-fd97-472c-a173-459d6ff0b957@suse.com> <77c1c05d-a0a0-4292-9257-9b7fbebee0e3@suse.com> <2859ad22-8714-4628-8142-fc77fc2072c3@amd.com> <214585d5-689d-4ba6-bd48-359428a7ed8f@amd.com> In-Reply-To: From: =?UTF-8?Q?S=C3=A9bastien_Chaumat?= Date: Wed, 6 Mar 2024 18:28:49 +0100 Message-ID: Subject: Re: [BUG]i2c_hid_acpi broken with 4.17.2 on Framework Laptop 13 AMD To: xen-devel@lists.xenproject.org Cc: Jan Beulich , Mario Limonciello , Juergen Gross , =?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= Content-Type: multipart/alternative; boundary="00000000000060a6300613014b0b" --00000000000060a6300613014b0b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Reasoning backward (using a kernel without the pinctrl_amd driver to > ensure xen only is at stake) : > checking the diff in IOAPIC between bare metal and xen (IRQ7 is on > pin07 on APIC ) > > using kernel argument : apic=3Ddebug > > bare metal : > [ 0.715330] fedora kernel: ... APIC VERSION: 81050010 > ... > [ 0.715433] fedora kernel: pin07, disabled, edge , high, V(00), > IRR(0), S(0), physical, D(0000), M(0) > > xen : > [ 2.249582] fedora kernel: ... APIC VERSION: 00000014 > ... > [ 2.249730] fedora kernel: pin07, disabled, level, low , V(60), > IRR(0), S(0), physical, D(0000), M(0) > > So the APIC table is not the same. > > As strange as it looks the (IOAPIC 0) pin07 is correctly described by th= e > APIC in xen but yet differently than in baremetal. > But the APIC message comes long after the > [ 1.833145] fedora kernel: xen: registering gsi 7 triggering 0 polarit= y > 1 > > so I wonder if the APIC pin07 info had any influence. > > Finally found the fix : adding ioapic_ack=3Dnew to xen boot parameters. Not only the trackpad is now working but also the ACPI Embedded Controller which is completely disabled. S=C3=A9bastien --00000000000060a6300613014b0b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable



<= br>
Reasoning backward= =C2=A0 (using a=C2=A0 kernel without the pinctrl_amd driver to ensure xen o= nly is at stake) :
=C2=A0checking the diff in IOAPIC=C2=A0 betwee= n bare metal and xen=C2=A0 (IRQ7 is on pin07 on APIC )

<= /div>
using kernel argument : apic=3Ddebug

bar= e metal :
[ =C2=A0 =C2=A00.715330] fedora kernel: ... APIC VERSIO= N: 81050010
...
[ =C2=A0 =C2=A00.715433] fedora kernel:= =C2=A0pin07, disabled, edge , high, V(00), IRR(0), S(0), physical, D(0000)= , M(0)

xen :
[ =C2=A0 =C2=A02.249582= ] fedora kernel: ... APIC VERSION: 00000014
...
[ =C2= =A0 =C2=A02.249730] fedora kernel: =C2=A0pin07, disabled, level, low , V(60= ), IRR(0), S(0), physical, D(0000), M(0)

So the AP= IC table is not the same.

As strange as it looks t= he=C2=A0 (IOAPIC 0) pin07 is correctly described by the APIC in xen but yet= differently than in baremetal.
But the APIC message comes long a= fter the
[ =C2=A0 =C2=A01.833145] fedora kernel: xen: regist= ering gsi 7 triggering 0 polarity 1

so I wonder if= the APIC pin07 info had any influence.

Finally found the fix : adding ioapic_ack=3Dnew to xen boot parameters.
Not only th= e trackpad is now working but also the ACPI Embedded Controller which is co= mpletely disabled.

S=C3=A9bastien


--00000000000060a6300613014b0b-- From xen-devel-bounces@lists.xenproject.org Wed Mar 06 17:33:33 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 17:33:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689438.1074402 (Exim 4.92) (envelope-from ) id 1rhv8z-0005rV-Jk; Wed, 06 Mar 2024 17:33:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689438.1074402; Wed, 06 Mar 2024 17:33:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhv8z-0005rO-H3; Wed, 06 Mar 2024 17:33:29 +0000 Received: by outflank-mailman (input) for mailman id 689438; Wed, 06 Mar 2024 17:33:28 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhv8y-0005rI-0H for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 17:33:28 +0000 Received: from NAM02-BN1-obe.outbound.protection.outlook.com (mail-bn1nam02on20600.outbound.protection.outlook.com [2a01:111:f403:2407::600]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id a2e59ba9-dbdf-11ee-afda-a90da7624cb6; Wed, 06 Mar 2024 18:33:26 +0100 (CET) Received: from MN0PR12MB6101.namprd12.prod.outlook.com (2603:10b6:208:3cb::10) by CY8PR12MB7730.namprd12.prod.outlook.com (2603:10b6:930:85::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7339.38; Wed, 6 Mar 2024 17:33:22 +0000 Received: from MN0PR12MB6101.namprd12.prod.outlook.com ([fe80::dcf1:946c:3879:5765]) by MN0PR12MB6101.namprd12.prod.outlook.com ([fe80::dcf1:946c:3879:5765%4]) with mapi id 15.20.7339.035; Wed, 6 Mar 2024 17:33:20 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a2e59ba9-dbdf-11ee-afda-a90da7624cb6 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Dw9V9IpULwYHSjD7nn46QrROZ2tl9Mm6dz2/PJKPrg2Jg04WcJdFOyv/sp9t9icrlltdYdlO3n2mWc2pP/di3xm6oocSJsMhGOmmVbpNBCg5tra2qgJIOHFg4t3Zr3Y6WiN/cqvFnUUlk0rcjN5u5HAs7cpwL+OY/p4NdTb70MijZX0lICZ4QDLS3FvQxpWOI0PQn1usrMckqfoMd1gxqN+lOmGRZhV145DU2ykMWJVu9v9Ajo3Yd8m6UawGoSeKeGFBm35jvqGDutfqpoDU2kno9ARG80uvD2Ycm95DQJ9e1sfSDWkJfSq5lEmlJyGEaDntUflx3es+LKfErCEouQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=6SCUk1blSDm4CBP4y0a2QP95WF0lNlN6ALMTMkwD85c=; b=EwkaDBXQq2bdOW4+MfidivGB0xnOgEtlvfcuPKaJpZOGZuCJU6BPwKjGzgTNW00rh09ezxPyQ8gf+VWFb2lOe/nRZH7wI4YSLQvaZzOf/2EoSDszaGHe9GOdjwn1mYF0tlWpwRR78r5p0nKhcxkAnVk+95nwMfxNFJVmwnRQYo5Zvj/fzfAo3pvD9UwPFOR8UmJcQaZPNafJaeyBghWEUUTXx+7Hlvyt6wzpS1K6J0Ah7V1UHljJ5vWCWHgbUhhSKETKjsMArU0bblSrYtCKuyshrfkmvLrrDPXDe33nmb5tgAaXoycutBVygfoA/3HXIay13xjvki9GjaQTMXpiIA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6SCUk1blSDm4CBP4y0a2QP95WF0lNlN6ALMTMkwD85c=; b=YZlgJT6QQw5yC9wWDeS2cN4G8jxijar4trUeO71X4MZIIw9lkisEOaxRHoI7Yq6hLkVqjpnry17OygnbCT9LBu8SPcBHAza+zBp8R73NifeYcO9eg7rz1kgVRRjRc+NOKEcjcoaX++U3tI4MAwszgST6eQ4tt5GXW1JAT7cLHOA= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; Message-ID: Date: Wed, 6 Mar 2024 11:33:18 -0600 User-Agent: Mozilla Thunderbird Subject: Re: [BUG]i2c_hid_acpi broken with 4.17.2 on Framework Laptop 13 AMD Content-Language: en-US To: =?UTF-8?Q?S=C3=A9bastien_Chaumat?= , xen-devel@lists.xenproject.org Cc: Jan Beulich , Juergen Gross , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= References: <77c1c05d-a0a0-4292-9257-9b7fbebee0e3@suse.com> <2859ad22-8714-4628-8142-fc77fc2072c3@amd.com> <214585d5-689d-4ba6-bd48-359428a7ed8f@amd.com> From: Mario Limonciello In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: DM6PR08CA0037.namprd08.prod.outlook.com (2603:10b6:5:1e0::11) To MN0PR12MB6101.namprd12.prod.outlook.com (2603:10b6:208:3cb::10) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MN0PR12MB6101:EE_|CY8PR12MB7730:EE_ X-MS-Office365-Filtering-Correlation-Id: 23b3b19d-6ff5-48a7-cbab-08dc3e0383f2 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: M5nLoGjd/jTbvIwSi+Go/wI7vQtQKo1/P96ourzYkQhxD1qI8glzNrCAxx+RPeYTXfmbg+xZT9m1B94KNqEiXe9F1t25yNfXPR7O6YpU/qLpdjoodypdDVWq6kfSx97ymDqFy3Ai2a4R/a8t/bSWsAZ3bAIcS7zYAnGP9lkWfgJk3+vdfiewlRK0o3xyHSPnKGJKtANaczpj0UgzPFF57jI+G1t9g6PhRqy2KFeRvWBKUQDK2Bm50mqpPAv2M2B3JB1rPoo+6wrbOVfCFgBx9hA5KSF2z/klMKUPhK0YHlSG2qO8UvAutF9MM+pDdVba982wcpLEvDKGjahsiB0w3HFSRq+jTt5TeNZ3GLOojyiOUBYGGkOyZzRBcuiD9y+5R3DZIV624yvcRp1x7wJh0uNUJCCpZCmLBPXcbfIyqe6vTbJwwFA8jSRHCApObLpkBWcbxTWCWS90J90/HrOohawT+uUw4rupoF9VcNkUdd96tbE3sClPpDQKVoPJTF4tyUA6j16qYCMghi6Crha4bCylHbWVPgCPVavD/Gr9uLar5ItjEDSo036U1ON/zasncDY4WFvCLfnheaKXdDCnbf+NUBAFJ2pBVAA4vIz2C4k= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MN0PR12MB6101.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(376005);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?bFpWYVVvZkdpaDB1V1Z6K3lNaE5ETFh6TTdCRVNiaWN2U3lnVmV5dXF3MnpL?= =?utf-8?B?RndKS3J2MnJuVEtMRTYwMVlnWGtpaFNzeUJmSFN1RFoxcitJUDRkaWN3Z3pP?= =?utf-8?B?YXRVQU1wMkJDTUhzR20yeXBiZGdkaXlxd3pYWVpWOExwTllCNDFhSXlJT1Bj?= =?utf-8?B?QWxFME56c2NhMlNpUkVucFl6V2tDS1lYWDRheTJFQXNmZWNENEVsaEhYOXF2?= =?utf-8?B?UW5jcGhKWG5pelpJZjdJdU9IKzgzV2FlQ2xGNFhUODB6TnNFVGo2Y0ZnYmI3?= =?utf-8?B?TFdCdlJvTkxxR2czZlh1M0dmVzBmV2hhamg2U3Y3LzJDUVBpM2pxcGMxOEhW?= =?utf-8?B?SUNjN2NOYUd3NVdNOFJkam1zM2VaSXZKY1N2NEowTlp2VlZWV0tveGZadFhM?= =?utf-8?B?a1RaNFpWLzNRL2ZoUEVkL3Jzcm9Fa0N0WThDRnllQkxVVjRDemV4RmRTSGVm?= =?utf-8?B?c1dBRkFjQ285bHhvcC80YVY5cDhBQk10SG01Mjljc1o5UDYrM2NQSjJZb0Va?= =?utf-8?B?L0JlOUtLU0k3eTIyVTc2TzNzQXhGczhNZjVHTllpZ0VxbWdicXhtUUN5L2ZJ?= =?utf-8?B?bkNTcGxOM1dPTTFZT216Y0h4and5bW5rM2JPemV3NHVjMUlSRlpZTTY0WDFS?= =?utf-8?B?bEJXRUJYa25nTGxZa1gzaEwrNFpDWFZyWi9SRG5OcUlidk10ZExOS1lyL0VR?= =?utf-8?B?WU5TQ25zQ2JhVmtJdVQ4RUxCTWpSMGdNUE9VUVh2S3ZVa3Y0a0JzRHc4V21w?= =?utf-8?B?RWt3aC9IOTJFK0lHS05uVU00RitYZFl6b3pCdnYvVTZvTXpjbXR3NXZ6UjZX?= =?utf-8?B?YTdyYU9kamN5ZlU0bTJ0eW50Tk8wZmE1eFlsdFpKeWZPTFhIb0RMZkFxMllL?= =?utf-8?B?SDF2Wm1TNnlGOVJhdndhWnR4VVk3QTZPZGRyb2NWUWM1WkphL0hBczAwL2Nn?= =?utf-8?B?clZnUE9IQS9CM3BqY2JHUm4wVkVlNEJXN0l2czVpcHliYThrZXh1a0ZvZUZE?= =?utf-8?B?bWwzb2p3dWUxZnVRUXBuN3NDUTE3b3pxOG9IUGF3NDZpZ0hHRGIvdXJzYTNL?= =?utf-8?B?anNzQkc3OG9LWHUrQ2VYV3habFcxaGFKc0dYKzdmSnIxN3dNNUZGTlpCbzhN?= =?utf-8?B?ckhzVC9BMzBRVWkrejExWlExZW9CV1dsc2NoNVh2WHB4VmQxMndNZ3JaKzBR?= =?utf-8?B?QWUzeVpjQXdMRmtlMmZQL1N5Y3UwcFl6TVV2L0IwcHI0aHp2Zk5pSUhpVGZS?= =?utf-8?B?MGt2Tlg0aS9FZU1MWWtlQ1gxYWx4Sk9CUEsvZCtwRVhGZ2t2TkNNL0k2Nldk?= =?utf-8?B?TUl6SXJWR3JtZ2xXMFNNYmhJS1ZwNkhzSzhveHNNUzlQWTIwSDJqa1NSSlpV?= =?utf-8?B?K1RxUjRUZTZ3RkpOZVlhMjhJbUtCQktjbCtGWU9EK1VVT2xPQ2N6WUR0dlpM?= =?utf-8?B?WkxHOVdzYUowZGJPemJKLzA3WWg1bmRwbHdKaXBuZllpdWNhc09iakZpMFNV?= =?utf-8?B?N1U4bkt2aDV6RW1EczQ5Yi9mczlXVnhuV2xub2dFdnBoTlhzb0ZnNk4xSnIw?= =?utf-8?B?R3dqMTRObzJVTGdPRGpwMXViZ0R1cFB2MGszV3d0ZHBjOGh3SVpNNlJTNE81?= =?utf-8?B?dnIrK2x6NkN6a1JGRFdWOFV3WFRCcGhvTDEzT2lyeURHNDM0T2dFUjVlRS96?= =?utf-8?B?QkEycCs4bUcxZlFTbGxqcHB6ZjdGdHV2aUo2Y2tXNkZReHRIelU3aU00dENi?= =?utf-8?B?UVZMWXpMNll4YkhCeGNqV2JkelVlalphdmxCcnFLLy9XSG5GZW1QQ3N2bzdu?= =?utf-8?B?M1BqRXFFV1JKYXNLSXlreDdNQVplUEFwd3ZzbUtUMGRUdHhWVUc3TWRQMU9r?= =?utf-8?B?dmJTUnN4TTVYNXVPc3RuM1U4WDVXb0lZVC9zS2d6M0VUVlU2dnkvWjAzOVIw?= =?utf-8?B?b2h4NTBmQ1JieVJXRUcwQVRWWTcxN09BTElES1RZUnJhRzZJZlJDcWFtbHJN?= =?utf-8?B?SDNaOWdQNkRDRHVYRlJYbGhIRjRyZVhnbWVwdVJuQjBhdlZIN2d5c0NEeTV1?= =?utf-8?B?YTBUWTErcENYTTVsdjFkTFB6T09EdUdjRS8vdlJuZ2xhNlRhYlNDMHZhTmUz?= =?utf-8?Q?X1fgk1huwZ972aFjX+BsCXfoa?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 23b3b19d-6ff5-48a7-cbab-08dc3e0383f2 X-MS-Exchange-CrossTenant-AuthSource: MN0PR12MB6101.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Mar 2024 17:33:20.0794 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: q7e4lblHMn13azAGEAX4Uh7DbuVv1Qazssf1LH5YAU5usc+CyDYNkMUcF1HoAghjOliF1T3SyT9JQwnnuyouJQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB7730 On 3/6/2024 11:28, Sébastien Chaumat wrote: > > > > > Reasoning backward  (using a  kernel without the pinctrl_amd driver > to ensure xen only is at stake) : >  checking the diff in IOAPIC  between bare metal and xen  (IRQ7 is > on pin07 on APIC ) > > using kernel argument : apic=debug > > bare metal : > [    0.715330] fedora kernel: ... APIC VERSION: 81050010 > ... > [    0.715433] fedora kernel:  pin07, disabled, edge , high, V(00), > IRR(0), S(0), physical, D(0000), M(0) > > xen : > [    2.249582] fedora kernel: ... APIC VERSION: 00000014 > ... > [    2.249730] fedora kernel:  pin07, disabled, level, low , V(60), > IRR(0), S(0), physical, D(0000), M(0) > > So the APIC table is not the same. > > As strange as it looks the  (IOAPIC 0) pin07 is correctly described > by the APIC in xen but yet differently than in baremetal. > But the APIC message comes long after the > [    1.833145] fedora kernel: xen: registering gsi 7 triggering 0 > polarity 1 > > so I wonder if the APIC pin07 info had any influence. > > Finally found the fix : adding ioapic_ack=new to xen boot parameters. > Not only the trackpad is now working but also the ACPI Embedded > Controller which is completely disabled. > > Sébastien > That's great news! I'm personally totally unfamiliar with ioapic_ack=new, so I did a quick search and found out it's a Xen parameter (I came across https://xenbits.xen.org/docs/4.5-testing/misc/xen-command-line.html). This mentions that "new" should be the default, so why isn't it the case? Also; I'd be really interested to hear what happens with s2idle with Xen now (if it works). From xen-devel-bounces@lists.xenproject.org Wed Mar 06 17:41:37 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 17:41:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689441.1074412 (Exim 4.92) (envelope-from ) id 1rhvGm-0008Az-Ch; Wed, 06 Mar 2024 17:41:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689441.1074412; Wed, 06 Mar 2024 17:41:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhvGm-0008As-9Z; Wed, 06 Mar 2024 17:41:32 +0000 Received: by outflank-mailman (input) for mailman id 689441; Wed, 06 Mar 2024 17:41:30 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhvGk-0008Ah-CT; Wed, 06 Mar 2024 17:41:30 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhvGk-0005fW-Ah; Wed, 06 Mar 2024 17:41:30 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhvGk-0004Uu-19; Wed, 06 Mar 2024 17:41:30 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rhvGk-0007ZK-0g; Wed, 06 Mar 2024 17:41:30 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=nP5zqlUrtQwv4aFOLOgkbwOAmSm7vdF5brkU5cmEBWc=; b=QmS+Z9p6XbJuT6mXt051uDw0AQ 8gZ88EQxyiXotH/fojJ6XdAUgrCgrMF1MXfA1ITvgv0s4P4zw7T/uOQvkFQRqBLQ4XbRCKfEpLM+M pGp+UFYLIwfaCAzGcU7SXRv6c/8OkQ7KUxEp+Gn7eHvcMjUC681xThyo4IHmWYg46+hY=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 184920: tolerable all pass - PUSHED X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=66c8e9b76c61ff52cfc0b186a38208907845d093 X-Osstest-Versions-That: xen=cd53ee9c41f991bbca75641e647005e013a3eac0 From: osstest service owner Date: Wed, 06 Mar 2024 17:41:30 +0000 flight 184920 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/184920/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass version targeted for testing: xen 66c8e9b76c61ff52cfc0b186a38208907845d093 baseline version: xen cd53ee9c41f991bbca75641e647005e013a3eac0 Last test of basis 184918 2024-03-06 10:02:20 Z 0 days Testing same since 184920 2024-03-06 14:00:24 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Fouad Hilly Jan Beulich Jorge Martin Pritha Srivastava Shawn Anastasio 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-amd64 pass 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 cd53ee9c41..66c8e9b76c 66c8e9b76c61ff52cfc0b186a38208907845d093 -> smoke From xen-devel-bounces@lists.xenproject.org Wed Mar 06 18:06:26 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 18:06:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689449.1074422 (Exim 4.92) (envelope-from ) id 1rhvef-0004eR-9I; Wed, 06 Mar 2024 18:06:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689449.1074422; Wed, 06 Mar 2024 18:06:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhvef-0004eK-69; Wed, 06 Mar 2024 18:06:13 +0000 Received: by outflank-mailman (input) for mailman id 689449; Wed, 06 Mar 2024 18:06:12 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhvee-0004d0-2H for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 18:06:12 +0000 Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [2607:f8b0:4864:20::434]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 35ea86dc-dbe4-11ee-afda-a90da7624cb6; Wed, 06 Mar 2024 19:06:10 +0100 (CET) Received: by mail-pf1-x434.google.com with SMTP id d2e1a72fcca58-6e55731af5cso9941b3a.0 for ; Wed, 06 Mar 2024 10:06:10 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 35ea86dc-dbe4-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709748369; x=1710353169; darn=lists.xenproject.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=jCnpVeyFfXdTbIhuKBuIIoc4SALrNUWp/6mK4dSKgS4=; b=C0YHk/NpuzZSzHGPSkVIhgyLnddK5Bk00o5OKUam12c0lmRdHmcDWDx2UXJnNDFKUg 1Q/KgTgPp7n5sOyQ6WYH6ELmFc6zPS6NRQk9IOfbMoqaRAvqsPaHpF8CwuNaib35zrnV QWp1fboWyxWHjZf/dJgeFa8oAPrjhvy3PeyDHUxs+HOMGf/PPIPD8boDRqO58klvl1gk lQ1JG/6XmGnXZWHCTKaozBLwaRDyshFKI78kMIKgbP2Lzz4D3jUwpeXIkBrg2dBtqnx1 sgBT6mTs+udaOYZ3nRmHZKwzg6Af3+2n+dpnTH6nmYKRJgQ1vNivmOwWyOs080fOX90d 8AEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709748369; x=1710353169; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=jCnpVeyFfXdTbIhuKBuIIoc4SALrNUWp/6mK4dSKgS4=; b=xSBgK26p3IJrQppeV4kiPqXgUass036Y466a2MVmI6mWxBaXz3dpk1yeJw/w4c6n/C dR/OjITeY2EosVBI8ybTtkX+ItZjwCpgtW7wOJEoGJuzxFdxArCvSjg51umdvjA2tIri e4+EU86/XEOeszQs4dlym3ErXI7Br1X7+LVXphd+zeM3qZEtFG+3TqSGLefZOptkHl+S 9/eUilQVbHb1fQmoS2BiCNpuCrlQA5KSKEFVsA2SpphUYbIovkw/JyE2a3A2SNtezah3 Lmb/wDPC56J0WBimKGjOpc3YStcYq8an7+czgx9+/rf9to+9S/3kP9PwnZImkkS8N6f9 de/A== X-Gm-Message-State: AOJu0YwgYgSwD0UB3EpJyn3ngFcT82P+d2jyzUy07Lo0FnW8uNX549Dv 5oI3FMQPhrCJHRNotDC7rDxyNhzbA/vo0OCzoShzOAwfHDwDy9vLq1lJVH7IBcYbvETQS3mAz8n i8pJAmUia4LJo2KvusoTWmz2pKhxQo2XHYtM= X-Google-Smtp-Source: AGHT+IFsYS1REiupAenMfHwmVW9z7DBMbu0UdKMDMQtaE3Ot9QhciWomSnzudXJZ3d1/rlgML83QTXKCS84f4LZgI6U= X-Received: by 2002:a05:6a20:d809:b0:1a1:4840:7614 with SMTP id iv9-20020a056a20d80900b001a148407614mr7291711pzb.35.1709748368987; Wed, 06 Mar 2024 10:06:08 -0800 (PST) MIME-Version: 1.0 References: <77c1c05d-a0a0-4292-9257-9b7fbebee0e3@suse.com> <2859ad22-8714-4628-8142-fc77fc2072c3@amd.com> <214585d5-689d-4ba6-bd48-359428a7ed8f@amd.com> In-Reply-To: From: =?UTF-8?Q?S=C3=A9bastien_Chaumat?= Date: Wed, 6 Mar 2024 19:05:57 +0100 Message-ID: Subject: Re: [BUG]i2c_hid_acpi broken with 4.17.2 on Framework Laptop 13 AMD To: Mario Limonciello Cc: xen-devel@lists.xenproject.org, Jan Beulich , Juergen Gross , =?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= Content-Type: multipart/alternative; boundary="000000000000305e24061301d0d6" --000000000000305e24061301d0d6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Le mer. 6 mars 2024 =C3=A0 18:33, Mario Limonciello a =C3=A9crit : > On 3/6/2024 11:28, S=C3=A9bastien Chaumat wrote: > > > > > > > > > > Reasoning backward (using a kernel without the pinctrl_amd driver > > to ensure xen only is at stake) : > > checking the diff in IOAPIC between bare metal and xen (IRQ7 is > > on pin07 on APIC ) > > > > using kernel argument : apic=3Ddebug > > > > bare metal : > > [ 0.715330] fedora kernel: ... APIC VERSION: 81050010 > > ... > > [ 0.715433] fedora kernel: pin07, disabled, edge , high, V(00), > > IRR(0), S(0), physical, D(0000), M(0) > > > > xen : > > [ 2.249582] fedora kernel: ... APIC VERSION: 00000014 > > ... > > [ 2.249730] fedora kernel: pin07, disabled, level, low , V(60), > > IRR(0), S(0), physical, D(0000), M(0) > > > > So the APIC table is not the same. > > > > As strange as it looks the (IOAPIC 0) pin07 is correctly described > > by the APIC in xen but yet differently than in baremetal. > > But the APIC message comes long after the > > [ 1.833145] fedora kernel: xen: registering gsi 7 triggering 0 > > polarity 1 > > > > so I wonder if the APIC pin07 info had any influence. > > > > Finally found the fix : adding ioapic_ack=3Dnew to xen boot parameters. > > Not only the trackpad is now working but also the ACPI Embedded > > Controller which is completely disabled. > > > > S=C3=A9bastien > > > That's great news! I'm personally totally unfamiliar with > ioapic_ack=3Dnew, so I did a quick search and found out it's a Xen > parameter (I came across > https://xenbits.xen.org/docs/4.5-testing/misc/xen-command-line.html). > > This mentions that "new" should be the default, so why isn't it the case? > "This is the the default unless directed-EOI is supported" xl dmesg without forcing the parameters shows : (XEN) Enabled directed EOI with ioapic_ack_old on! > Also; I'd be really interested to hear what happens with s2idle with Xen > now (if it works). > suspend to RAM now works :) --000000000000305e24061301d0d6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Le=C2=A0mer. 6 mars 2024 =C3=A0=C2=A018:33, Mario Limonciel= lo <mario.limonciello@amd.c= om> a =C3=A9crit=C2=A0:
On 3= /6/2024 11:28, S=C3=A9bastien Chaumat wrote:
>
>
>
>
>=C2=A0 =C2=A0 =C2=A0Reasoning backward=C2=A0 (using a=C2=A0 kernel with= out the pinctrl_amd driver
>=C2=A0 =C2=A0 =C2=A0to ensure xen only is at stake) :
>=C2=A0 =C2=A0 =C2=A0 =C2=A0checking the diff in IOAPIC=C2=A0 between ba= re metal and xen=C2=A0 (IRQ7 is
>=C2=A0 =C2=A0 =C2=A0on pin07 on APIC )
>
>=C2=A0 =C2=A0 =C2=A0using kernel argument : apic=3Ddebug
>
>=C2=A0 =C2=A0 =C2=A0bare metal :
>=C2=A0 =C2=A0 =C2=A0[ =C2=A0 =C2=A00.715330] fedora kernel: ... APIC VE= RSION: 81050010
>=C2=A0 =C2=A0 =C2=A0...
>=C2=A0 =C2=A0 =C2=A0[ =C2=A0 =C2=A00.715433] fedora kernel: =C2=A0pin07= , disabled, edge , high, V(00),
>=C2=A0 =C2=A0 =C2=A0IRR(0), S(0), physical, D(0000), M(0)
>
>=C2=A0 =C2=A0 =C2=A0xen :
>=C2=A0 =C2=A0 =C2=A0[ =C2=A0 =C2=A02.249582] fedora kernel: ... APIC VE= RSION: 00000014
>=C2=A0 =C2=A0 =C2=A0...
>=C2=A0 =C2=A0 =C2=A0[ =C2=A0 =C2=A02.249730] fedora kernel: =C2=A0pin07= , disabled, level, low , V(60),
>=C2=A0 =C2=A0 =C2=A0IRR(0), S(0), physical, D(0000), M(0)
>
>=C2=A0 =C2=A0 =C2=A0So the APIC table is not the same.
>
>=C2=A0 =C2=A0 =C2=A0As strange as it looks the=C2=A0 (IOAPIC 0) pin07 i= s correctly described
>=C2=A0 =C2=A0 =C2=A0by the APIC in xen but yet differently than in bare= metal.
>=C2=A0 =C2=A0 =C2=A0But the APIC message comes long after the
>=C2=A0 =C2=A0 =C2=A0[ =C2=A0 =C2=A01.833145] fedora kernel: xen: regist= ering gsi 7 triggering 0
>=C2=A0 =C2=A0 =C2=A0polarity 1
>
>=C2=A0 =C2=A0 =C2=A0so I wonder if the APIC pin07 info had any influenc= e.
>
> Finally found the fix : adding ioapic_ack=3Dnew to xen boot parameters= .
> Not only the trackpad is now working but also the ACPI Embedded
> Controller which is completely disabled.
>
> S=C3=A9bastien
>
That's great news!=C2=A0 I'm personally totally unfamiliar with ioapic_ack=3Dnew, so I did a quick search and found out it's a Xen
parameter (I came across
https://xenbits.xen.org/docs/4.5-= testing/misc/xen-command-line.html).

This mentions that "new" should be the default, so why isn't = it the case?

=C2=A0"This is the th= e default unless directed-EOI is supported"
xl dmesg without= forcing the parameters shows :

(XEN) Enabled dire= cted EOI with ioapic_ack_old on!
=C2=A0
Also; I'd be really interested to hear what happens with s2idle with Xe= n
now (if it works).

suspend to RAM now w= orks :)
--000000000000305e24061301d0d6-- From xen-devel-bounces@lists.xenproject.org Wed Mar 06 18:08:32 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 18:08:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689452.1074432 (Exim 4.92) (envelope-from ) id 1rhvgr-0005IT-OZ; Wed, 06 Mar 2024 18:08:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689452.1074432; Wed, 06 Mar 2024 18:08:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhvgr-0005IM-Lf; Wed, 06 Mar 2024 18:08:29 +0000 Received: by outflank-mailman (input) for mailman id 689452; Wed, 06 Mar 2024 18:08:28 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhvgq-0005IG-5d for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 18:08:28 +0000 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on20601.outbound.protection.outlook.com [2a01:111:f403:2415::601]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 869d389d-dbe4-11ee-afda-a90da7624cb6; Wed, 06 Mar 2024 19:08:26 +0100 (CET) Received: from MN0PR12MB6101.namprd12.prod.outlook.com (2603:10b6:208:3cb::10) by PH7PR12MB6612.namprd12.prod.outlook.com (2603:10b6:510:210::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.24; Wed, 6 Mar 2024 18:08:22 +0000 Received: from MN0PR12MB6101.namprd12.prod.outlook.com ([fe80::dcf1:946c:3879:5765]) by MN0PR12MB6101.namprd12.prod.outlook.com ([fe80::dcf1:946c:3879:5765%4]) with mapi id 15.20.7339.035; Wed, 6 Mar 2024 18:08:22 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 869d389d-dbe4-11ee-afda-a90da7624cb6 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IXWswHKpyV4sj36i+QY0iSVVlHLD6L1GXbvDehMJFf/TV66IC7nbdCxQwcShIzds9I5QTq1euiwN6ts9vpYZp+2UTv3FBN90nhRTtjToNNzijihSBV97eBeOSl7qiCyPDayeTl5esD6ufvoGow585PJMF6BHlcDNtDAxAF5MCStu8+6ogUIb0ZtRy1qjIUl29h2W4ASFiNOC7cTZ3+G6xijpdKwERBVuShReoYJc+RBB7b+gMzaZSPhNZZEkz1LVB6kRoqY8N2BcKW53QSwSc7ANMXPv/c7gzIp/NvT4+m7cdsOElPnhIH1I5ScFbTPCSentYBvpc/+mo8PHjBIZ/w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=vCDgLiYEndT/i2zM6Nh2/QLh+4ErkHJLrN2eNndJs+E=; b=E4+7n90bJfPBWfWa2HAbwQSIC9DBAaMelp8ibd6ocTYCr2dFV3J4Z0TlJY4mrw0ZcFdrtqIjQFzT54eCWOgyIH6uTtCkpdNwNHuvq/nPgi2vMCDA3SxT9CuibriEV1k+6Y+VHR+ecqnO/o4EksXOJf95GfJ5xb8B025Nkw8J0W13TDQ2wa8Jgf41HMmENsOjbp9Z8cmr5ImtGB0B7HWil1BCea76gtcaWxXu+PZD8d40b/HhRJIXdHuKJY/SPove0GGCwLweQGEAlynwTkR80jslTdsxceCs0hOXnb1QlRQPG8ykyN7WeMUco35EC0H92gc/7gzl9kN0EfevRbtf8g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vCDgLiYEndT/i2zM6Nh2/QLh+4ErkHJLrN2eNndJs+E=; b=n/9dkPnPsze/2717LnI6rslqpoTccZ8iekjHWNQ62yRx0SQR21dccon96IN8VkGbyqhXfV0QJkEmcce2fgLX+BTrb1Yo4UFQfmSPLN8eZZHoPMKi7u2jzGHtVSOzGT/nBgvhs8/hQjNKBHfs8yYeaNwTtioPpXsyOTjm5N1gOwk= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; Message-ID: <19852f4d-fbeb-4314-a2cb-ab3f05da13ba@amd.com> Date: Wed, 6 Mar 2024 12:08:19 -0600 User-Agent: Mozilla Thunderbird Subject: Re: [BUG]i2c_hid_acpi broken with 4.17.2 on Framework Laptop 13 AMD Content-Language: en-US To: =?UTF-8?Q?S=C3=A9bastien_Chaumat?= Cc: xen-devel@lists.xenproject.org, Jan Beulich , Juergen Gross , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= References: <77c1c05d-a0a0-4292-9257-9b7fbebee0e3@suse.com> <2859ad22-8714-4628-8142-fc77fc2072c3@amd.com> <214585d5-689d-4ba6-bd48-359428a7ed8f@amd.com> From: Mario Limonciello In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: DM6PR02CA0128.namprd02.prod.outlook.com (2603:10b6:5:1b4::30) To MN0PR12MB6101.namprd12.prod.outlook.com (2603:10b6:208:3cb::10) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MN0PR12MB6101:EE_|PH7PR12MB6612:EE_ X-MS-Office365-Filtering-Correlation-Id: 0c99929e-468c-4710-fc21-08dc3e08694a X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: NaT6c8zKxmb5RQEDDeCIVnKHzR9kUMeNdCBO8BEIwfV0ftofyt3y3y4ePT0b+o99dGEfv/dbVE2o9K1t8ijCZ4CilywEtz1kSII/PrFOY5iBGkba79nQdNyjFWknCD4yCkL0kN5gVR9tQPEpjI1scv9tmd/UQaUskkGDi28W6arVDiPsD4814bk+gqrnLLy9+7TTnv5mr3CltlUCIZgDCAMAbpvbnxz0qi0SkirhviEW3nxJy22uWchCfVLgeffOOh4g/JfXyNGy9SL53DMlb2R8iFoI6PGHN2gnGqnDh1mXSIEoj5WCN4w0fyhPnTB+hMeoMSaatqGQiFEbc+eaFCxrAeTgB6WxZNetlzPBNj+jZCg/e+ANopCwKupSNbNVx0t9KYT5i4GZnOmPdEawnZgFr1iLd2juq+HvNKo1CZZxzsk/IXiOVTWqubPZ14sSIbKYnlEmmvdZELykWJjz2i+eet++h/iXK+o7+4q84fGzGhxl6Qskj2j/ADKehcTCPKoq2Z+3VxaF4obB4dIw0ennD2HDs36odkTSK+56U5r+xkTXB+Vngq7NB8VJR4k4Kuq2F4XrA5yjL+sOR6114LSe/RhcVSSSNIvaP6trO+I= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MN0PR12MB6101.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(376005);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?dlEwTGNMQi9zQmFQSU1wdXMySXh4UnU0NTJCa2M3OFVJVG5WeERya3Jwd3VQ?= =?utf-8?B?RmFVOWk5NGp6NmJ3QXVpdmRaZ2pmQ3dvdXZabCt2cy9aTWowbVJqQi9NS016?= =?utf-8?B?RVUreDUwQ3NzOHRQWkNialVvTjhVK05QVVA0ZDRFNnNQYmlaZll4aUJ0Tm1K?= =?utf-8?B?KzFGdUhRZ2ZFNlZHSHJCRUJiRjRKUjljc2xieThvSjErdWhYVWUvVUNRaHhw?= =?utf-8?B?K1V5YysrWHFRTG1uK0QvRU5GM25jM3lDN1B3Sll4emJGZ3QreVhzTVIrYUIz?= =?utf-8?B?Q3RVU3dSUWRwZ3FDa2VRUDdpSHYyOEo5bUo0Z1hWTXl3ajVPbk5FUVFXVDVl?= =?utf-8?B?U2NtSmtEbnNmWEdHWjdXcTlLRFpLMkxjNlR1SC8rZytBN09nODZwbTd2Q2M2?= =?utf-8?B?QWs5ZkU1Y1NBdjhBY3pTWHhtQTNIWkt2N1pxMmJhajlBajZkRmpOZHBpWjlI?= =?utf-8?B?UFpma1F1RHdPYWY0aThQNWhFYkRPVE0xbUxIVFJhUXVWRkI0VmJLTVoyRGRl?= =?utf-8?B?VWtGbjV0MXU3eURhZEpXVUhPZDBhY3NZTFl2SStkdU9mRk9UL1hqMTlCUEMw?= =?utf-8?B?M0FPR0ZqQW9rSi9rbHhaRzNUOFdrZW1nU3JlZG5MZVBpOW55UHpGZ0lOb0V4?= =?utf-8?B?SVZ1UittK3MxUFhNUTRjTWt4M3l3U1Q1V1pRQ2dtQW5KTDBBRVIvbFBkdlBI?= =?utf-8?B?N2wzc0ZEUG9UMmw4UklPSVBGYkRoZnZpa3hOYnAzaEtkWDBIeURYZmpxVlRt?= =?utf-8?B?ZWJGMjNOTU9MZGlHOVc0R1RPSUlKaWtHbUhDM0pNSUtObkM2blJMRXJ4QitI?= =?utf-8?B?MEwyMnJYOHQ2anRqY2F2UmxsMVJNS2Q2S0FlOFVyM29DOGZvZ2ZVZmJEMGlF?= =?utf-8?B?b045RjJVVXBtQzQ2VUxjU2ppQUpwTkNnNWkzcnVjbmIrQkhzbmJSV0syaGps?= =?utf-8?B?VGlmenlZQlh2S2VaTmxOM2ZuS203dlptdyt5N0JpTnlScHpSS0VSUW91R2w4?= =?utf-8?B?WXpoNGlwRitMcFovdS9saVpTTjFmRlJkNHEwb1lKQnBPK1IrTGl0MHlGU3pK?= =?utf-8?B?QjZOK0E4YSs4OW9ZcGpiL2FnY3ZVWDRXeEcvRTY1ZHdUMndyakpLcXIxYzIx?= =?utf-8?B?K3ZVcHRVckNKbnBTZG9qSzJZL2F0VE1kN0NrSFZGSEpNODVzUnlId1RnQTkx?= =?utf-8?B?YVJvSXBrdVJYSk1tVC84SjZIV2J6aG9xSVE0MTlaeUtXVFMzcy9LR0RidDhq?= =?utf-8?B?eE1iK0p3ODNDUkF3ZDNNMTNzZlAyNzNjM1V0S3RLOUF5djU3dnJIS01oVkhk?= =?utf-8?B?ZFVpZzFURXNzVDJLcDBvS1p6YzFqaWltb01vSzJJY3o0TmVvOVc0NmVnOWpq?= =?utf-8?B?N2Q5MzVzZWxNTVZKV2VtM2NVTGx5MWhPZ0cxdlI0Z0h1ZzNURXJGMEhVdHRC?= =?utf-8?B?WmNLZjNJRGdLdk9ZbEN4bS90Yld1cVpUN3JRR1p2NS91OVgrQUY2ZkxSRE9I?= =?utf-8?B?b1gwR0pLVGkzTEtFRzczQUJVdnRLWmpwanRTTnZDUzcwNk5vbGY4LzgzdnRL?= =?utf-8?B?dEVGUGV3VXZEeGhWRWc0dmZTNDZlTGU0YkNKbWRaU2hlYVZlSmxOVVRhNjVh?= =?utf-8?B?cGFISDhPekVSMVpIMVVRSVZYQ1FuM296elVUZGQvTjNUY296Q29JdzcrSDdJ?= =?utf-8?B?M09IVTE3ZkVhdTdGdFcvamtVdzJBbW1PZFo5NTZ3c0s5cmpmZlRiQUtMTWRD?= =?utf-8?B?VDhpWE5zVEc3MGU4ZEY1RVAveTA4YVQ3OVNmYTFnOFEyb1A3RkdjMElDOTRh?= =?utf-8?B?TFVocGxQai85cllhK1hmWGlpS0ZlQnJ5QnhWejhpVHhIU1dSeURyTXBxTGJq?= =?utf-8?B?TkEvemk3U0pIemVLM0U5dmdMTExVb1g1TkdBZ1RkZkdyMDhTTlVRT1l2WUdm?= =?utf-8?B?ZnAvZnZTUDBQak9FaXkyNkQ1eFZ2UHptQzV0Z3dyRkZ5WGQzb1pMOThURkdj?= =?utf-8?B?cHdMTFF6dWUyb3c2N0l6TWQyakhpekRtb3l1WVZXOHV4c1NHSjY3YW1OM1Zp?= =?utf-8?B?TzR3LzB3bW1JdjV0VWt5K2lFV0MwMUhuRy9zdmp6YXlkZm1FdGR6UnZjV3hx?= =?utf-8?Q?VGV2B2ZlbElFK9J08+ZQuAlpY?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0c99929e-468c-4710-fc21-08dc3e08694a X-MS-Exchange-CrossTenant-AuthSource: MN0PR12MB6101.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Mar 2024 18:08:22.7920 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: dm6fHIKw0ocqPKrVZYnT+cwu/uMRBGIh4ssPgyK2SXGswpctVGrGszpLd17N8RYSx9y/VyI3A7gDTDBPYEnPcA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB6612 On 3/6/2024 12:05, Sébastien Chaumat wrote: > > > Le mer. 6 mars 2024 à 18:33, Mario Limonciello > > a écrit : > > On 3/6/2024 11:28, Sébastien Chaumat wrote: > > > > > > > > > >     Reasoning backward  (using a  kernel without the pinctrl_amd > driver > >     to ensure xen only is at stake) : > >       checking the diff in IOAPIC  between bare metal and xen > (IRQ7 is > >     on pin07 on APIC ) > > > >     using kernel argument : apic=debug > > > >     bare metal : > >     [    0.715330] fedora kernel: ... APIC VERSION: 81050010 > >     ... > >     [    0.715433] fedora kernel:  pin07, disabled, edge , high, > V(00), > >     IRR(0), S(0), physical, D(0000), M(0) > > > >     xen : > >     [    2.249582] fedora kernel: ... APIC VERSION: 00000014 > >     ... > >     [    2.249730] fedora kernel:  pin07, disabled, level, low , > V(60), > >     IRR(0), S(0), physical, D(0000), M(0) > > > >     So the APIC table is not the same. > > > >     As strange as it looks the  (IOAPIC 0) pin07 is correctly > described > >     by the APIC in xen but yet differently than in baremetal. > >     But the APIC message comes long after the > >     [    1.833145] fedora kernel: xen: registering gsi 7 triggering 0 > >     polarity 1 > > > >     so I wonder if the APIC pin07 info had any influence. > > > > Finally found the fix : adding ioapic_ack=new to xen boot parameters. > > Not only the trackpad is now working but also the ACPI Embedded > > Controller which is completely disabled. > > > > Sébastien > > > That's great news!  I'm personally totally unfamiliar with > ioapic_ack=new, so I did a quick search and found out it's a Xen > parameter (I came across > https://xenbits.xen.org/docs/4.5-testing/misc/xen-command-line.html > ). > > This mentions that "new" should be the default, so why isn't it the > case? > > >  "This is the the default unless directed-EOI is supported" > xl dmesg without forcing the parameters shows : > > (XEN) Enabled directed EOI with ioapic_ack_old on! Got it; it sounds to me like a logic mismatch in Xen then. > > Also; I'd be really interested to hear what happens with s2idle with > Xen > now (if it works). > > > suspend to RAM now works :) Do you see /sys/power/suspend_stats/last_hw_sleep increasing with your suspend cycle? From xen-devel-bounces@lists.xenproject.org Wed Mar 06 18:29:20 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 18:29:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689458.1074442 (Exim 4.92) (envelope-from ) id 1rhw0s-0001Ac-Dg; Wed, 06 Mar 2024 18:29:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689458.1074442; Wed, 06 Mar 2024 18:29:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhw0s-0001AV-9x; Wed, 06 Mar 2024 18:29:10 +0000 Received: by outflank-mailman (input) for mailman id 689458; Wed, 06 Mar 2024 18:29:10 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhw0r-0001AP-MD for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 18:29:09 +0000 Received: from mail.zytor.com (unknown [2607:7c80:54:3::138]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 693b352d-dbe7-11ee-a1ee-f123f15fe8a2; Wed, 06 Mar 2024 19:29:05 +0100 (CET) Received: from [192.168.7.187] ([71.202.166.45]) (authenticated bits=0) by mail.zytor.com (8.17.2/8.17.1) with ESMTPSA id 426ISQw91528489 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 6 Mar 2024 10:28:27 -0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 693b352d-dbe7-11ee-a1ee-f123f15fe8a2 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 426ISQw91528489 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2024021201; t=1709749708; bh=XQAir3QRa5LQDi4wpuJlDHfgaqnwTrNgWliu5M/6UP4=; h=Date:Subject:From:To:Cc:References:In-Reply-To:From; b=WKyWZwZqRkd0DiLDAyMi5GM+f+MfmhKuUh/wbJdQIAdwUtv0kKzPL6nlh/4toQG/H PF5Sszl+gtSmhdTPeBuBZoPXgDpednmhUbwDvyXHs6II7gdoA1E3zeg/PhwZ73dJls GECwKlguNNbFXv1k5YyqHSQhjEfuQ02Rat/dl18qx/tXfRNV5ORM+CzK6AH1MFtJDx rs8r0MocTOaRThspYxT2xB/XSyXVwWNzICsGv2o8ILA5qwuJnnJhE2et++7cPh8dEr ktx8Vo53tnvOQQ6FPaZgfGQJY1PQosR7hboXEUQH0aSHWuBY857Qkl3g8TD3kGw9s/ 7BmBpxRWbTEIQ== Message-ID: Date: Wed, 6 Mar 2024 10:28:25 -0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/1] x86/fred: Fix init_task thread stack pointer initialization Content-Language: en-US From: Xin Li To: linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, jgross@suse.com, boris.ostrovsky@oracle.com, arnd@arndb.de, andrew.cooper3@citrix.com, brgerst@gmail.com References: <20240304083333.449322-1-xin@zytor.com> Autocrypt: addr=xin@zytor.com; keydata= xsDNBGUPz1cBDACS/9yOJGojBFPxFt0OfTWuMl0uSgpwk37uRrFPTTLw4BaxhlFL0bjs6q+0 2OfG34R+a0ZCuj5c9vggUMoOLdDyA7yPVAJU0OX6lqpg6z/kyQg3t4jvajG6aCgwSDx5Kzg5 Rj3AXl8k2wb0jdqRB4RvaOPFiHNGgXCs5Pkux/qr0laeFIpzMKMootGa4kfURgPhRzUaM1vy bsMsL8vpJtGUmitrSqe5dVNBH00whLtPFM7IbzKURPUOkRRiusFAsw0a1ztCgoFczq6VfAVu raTye0L/VXwZd+aGi401V2tLsAHxxckRi9p3mc0jExPc60joK+aZPy6amwSCy5kAJ/AboYtY VmKIGKx1yx8POy6m+1lZ8C0q9b8eJ8kWPAR78PgT37FQWKYS1uAroG2wLdK7FiIEpPhCD+zH wlslo2ETbdKjrLIPNehQCOWrT32k8vFNEMLP5G/mmjfNj5sEf3IOKgMTMVl9AFjsINLHcxEQ 6T8nGbX/n3msP6A36FDfdSEAEQEAAc0WWGluIExpIDx4aW5Aenl0b3IuY29tPsLBDQQTAQgA NxYhBIUq/WFSDTiOvUIqv2u9DlcdrjdRBQJlD89XBQkFo5qAAhsDBAsJCAcFFQgJCgsFFgID AQAACgkQa70OVx2uN1HUpgv/cM2fsFCQodLArMTX5nt9yqAWgA5t1srri6EgS8W3F+3Kitge tYTBKu6j5BXuXaX3vyfCm+zajDJN77JHuYnpcKKr13VcZi1Swv6Jx1u0II8DOmoDYLb1Q2ZW v83W55fOWJ2g72x/UjVJBQ0sVjAngazU3ckc0TeNQlkcpSVGa/qBIHLfZraWtdrNAQT4A1fa sWGuJrChBFhtKbYXbUCu9AoYmmbQnsx2EWoJy3h7OjtfFapJbPZql+no5AJ3Mk9eE5oWyLH+ QWqtOeJM7kKvn/dBudokFSNhDUw06e7EoVPSJyUIMbYtUO7g2+Atu44G/EPP0yV0J4lRO6EA wYRXff7+I1jIWEHpj5EFVYO6SmBg7zF2illHEW31JAPtdDLDHYcZDfS41caEKOQIPsdzQkaQ oW2hchcjcMPAfyhhRzUpVHLPxLCetP8vrVhTvnaZUo0xaVYb3+wjP+D5j/3+hwblu2agPsaE vgVbZ8Fx3TUxUPCAdr/p73DGg57oHjgezsDNBGUPz1gBDAD4Mg7hMFRQqlzotcNSxatlAQNL MadLfUTFz8wUUa21LPLrHBkUwm8RujehJrzcVbPYwPXIO0uyL/F///CogMNx7Iwo6by43KOy g89wVFhyy237EY76j1lVfLzcMYmjBoTH95fJC/lVb5Whxil6KjSN/R/y3jfG1dPXfwAuZ/4N cMoOslWkfZKJeEut5aZTRepKKF54T5r49H9F7OFLyxrC/uI9UDttWqMxcWyCkHh0v1Di8176 jjYRNTrGEfYfGxSp+3jYL3PoNceIMkqM9haXjjGl0W1B4BidK1LVYBNov0rTEzyr0a1riUrp Qk+6z/LHxCM9lFFXnqH7KWeToTOPQebD2B/Ah5CZlft41i8L6LOF/LCuDBuYlu/fI2nuCc8d m4wwtkou1Y/kIwbEsE/6RQwRXUZhzO6llfoN96Fczr/RwvPIK5SVMixqWq4QGFAyK0m/1ap4 bhIRrdCLVQcgU4glo17vqfEaRcTW5SgX+pGs4KIPPBE5J/ABD6pBnUUAEQEAAcLA/AQYAQgA JhYhBIUq/WFSDTiOvUIqv2u9DlcdrjdRBQJlD89ZBQkFo5qAAhsMAAoJEGu9DlcdrjdR4C0L /RcjolEjoZW8VsyxWtXazQPnaRvzZ4vhmGOsCPr2BPtMlSwDzTlri8BBG1/3t/DNK4JLuwEj OAIE3fkkm+UG4Kjud6aNeraDI52DRVCSx6xff3bjmJsJJMb12mWglN6LjdF6K+PE+OTJUh2F dOhslN5C2kgl0dvUuevwMgQF3IljLmi/6APKYJHjkJpu1E6luZec/lRbetHuNFtbh3xgFIJx 2RpgVDP4xB3f8r0I+y6ua+p7fgOjDLyoFjubRGed0Be45JJQEn7A3CSb6Xu7NYobnxfkwAGZ Q81a2XtvNS7Aj6NWVoOQB5KbM4yosO5+Me1V1SkX2jlnn26JPEvbV3KRFcwV5RnDxm4OQTSk PYbAkjBbm+tuJ/Sm+5Yp5T/BnKz21FoCS8uvTiziHj2H7Cuekn6F8EYhegONm+RVg3vikOpn gao85i4HwQTK9/D1wgJIQkdwWXVMZ6q/OALaBp82vQ2U9sjTyFXgDjglgh00VRAHP7u1Rcu4 l75w1xInsg== In-Reply-To: <20240304083333.449322-1-xin@zytor.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 3/4/2024 12:33 AM, Xin Li (Intel) wrote: > As TOP_OF_KERNEL_STACK_PADDING is defined as 0 on x86_64, no one noticed > it's missing in the calculation of the .sp field in INIT_THREAD until it > is defined to 16 with CONFIG_X86_FRED=y. > > Subtract TOP_OF_KERNEL_STACK_PADDING from the .sp field of INIT_THREAD. > > Fixes: 65c9cc9e2c14 ("x86/fred: Reserve space for the FRED stack frame") > Fixes: 3adee777ad0d ("x86/smpboot: Remove initial_stack on 64-bit") > Reported-by: kernel test robot > Closes: https://lore.kernel.org/oe-lkp/202402262159.183c2a37-lkp@intel.com > Signed-off-by: Xin Li (Intel) > --- Should this fix, if it looks good, be included for the coming merge window? Thanks! Xin > > Change Since v1: > * Apply offset TOP_OF_KERNEL_STACK_PADDING to all uses of __end_init_task > (Brian Gerst). > --- > arch/x86/include/asm/processor.h | 6 ++++-- > arch/x86/kernel/head_64.S | 3 ++- > arch/x86/xen/xen-head.S | 2 +- > 3 files changed, 7 insertions(+), 4 deletions(-) > > diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h > index 26620d7642a9..17fe81998ce4 100644 > --- a/arch/x86/include/asm/processor.h > +++ b/arch/x86/include/asm/processor.h > @@ -664,8 +664,10 @@ static __always_inline void prefetchw(const void *x) > #else > extern unsigned long __end_init_task[]; > > -#define INIT_THREAD { \ > - .sp = (unsigned long)&__end_init_task - sizeof(struct pt_regs), \ > +#define INIT_THREAD { \ > + .sp = (unsigned long)&__end_init_task - \ > + TOP_OF_KERNEL_STACK_PADDING - \ > + sizeof(struct pt_regs), \ > } > > extern unsigned long KSTK_ESP(struct task_struct *task); > diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S > index d4918d03efb4..c38e43589046 100644 > --- a/arch/x86/kernel/head_64.S > +++ b/arch/x86/kernel/head_64.S > @@ -26,6 +26,7 @@ > #include > #include > #include > +#include > > /* > * We are not able to switch in one step to the final KERNEL ADDRESS SPACE > @@ -66,7 +67,7 @@ SYM_CODE_START_NOALIGN(startup_64) > mov %rsi, %r15 > > /* Set up the stack for verify_cpu() */ > - leaq (__end_init_task - PTREGS_SIZE)(%rip), %rsp > + leaq (__end_init_task - TOP_OF_KERNEL_STACK_PADDING - PTREGS_SIZE)(%rip), %rsp > > leaq _text(%rip), %rdi > > diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S > index a0ea285878db..04101b984f24 100644 > --- a/arch/x86/xen/xen-head.S > +++ b/arch/x86/xen/xen-head.S > @@ -49,7 +49,7 @@ SYM_CODE_START(startup_xen) > ANNOTATE_NOENDBR > cld > > - leaq (__end_init_task - PTREGS_SIZE)(%rip), %rsp > + leaq (__end_init_task - TOP_OF_KERNEL_STACK_PADDING - PTREGS_SIZE)(%rip), %rsp > > /* Set up %gs. > * > > base-commit: e13841907b8fda0ae0ce1ec03684665f578416a8 From xen-devel-bounces@lists.xenproject.org Wed Mar 06 18:30:36 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 18:30:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689460.1074452 (Exim 4.92) (envelope-from ) id 1rhw2F-0002wz-Lu; Wed, 06 Mar 2024 18:30:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689460.1074452; Wed, 06 Mar 2024 18:30:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhw2F-0002ws-JA; Wed, 06 Mar 2024 18:30:35 +0000 Received: by outflank-mailman (input) for mailman id 689460; Wed, 06 Mar 2024 18:30:34 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhw2E-0002vE-HE for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 18:30:34 +0000 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 9d206f88-dbe7-11ee-a1ee-f123f15fe8a2; Wed, 06 Mar 2024 19:30:32 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 03AB661ACE; Wed, 6 Mar 2024 18:30:31 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPS id 92CB4C433F1; Wed, 6 Mar 2024 18:30:30 +0000 (UTC) Received: from aws-us-west-2-korg-oddjob-1.ci.codeaurora.org (localhost.localdomain [127.0.0.1]) by aws-us-west-2-korg-oddjob-1.ci.codeaurora.org (Postfix) with ESMTP id 75D01D84BDB; Wed, 6 Mar 2024 18:30:30 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 9d206f88-dbe7-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1709749830; bh=PbF2UlZV892Jxrsv7n/QNaCuvcvT+bdEwgeDba0rcjA=; h=Subject:From:Date:References:In-Reply-To:To:Cc:From; b=fwiXDfvlpQlGjUt62NAuwwDKSJswzGitGsNvpmH5JJsLFIOU1IdYtAoB1W3FFEwNl Heo7Oc4/XqjTSTf8XTrWqufWL0CndVvbmOhLiJFh+unzTvqh+0lZ2KV0wut+1Z8bOI LeK57dveh/uRc/EIjUKLKhOrsZ3f8pRkCC33dqADerQY8+AcoodtKAPCyEZKT4Y5FJ 7OGroKN89O9Ev4ImAbKnPPjsldWBbdcmHgAFepFtQ6e8s3tqS2Za9s0ZWIQc9YropM vGNlDE99EDrTjhMl98e59+kIVa4QiumCHwSTfYpKNXdd1Zsu2vUEItWQ8lNBCg3ngh UodUR2RADtwqg== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: Re: [PATCH v4 bpf-next 0/2] mm: Enforce ioremap address space and introduce sparse vm_area From: patchwork-bot+netdevbpf@kernel.org Message-Id: <170974983047.28981.6719841363638067454.git-patchwork-notify@kernel.org> Date: Wed, 06 Mar 2024 18:30:30 +0000 References: <20240305030516.41519-1-alexei.starovoitov@gmail.com> In-Reply-To: <20240305030516.41519-1-alexei.starovoitov@gmail.com> To: Alexei Starovoitov Cc: bpf@vger.kernel.org, daniel@iogearbox.net, andrii@kernel.org, torvalds@linux-foundation.org, brho@google.com, hannes@cmpxchg.org, lstoakes@gmail.com, akpm@linux-foundation.org, urezki@gmail.com, hch@infradead.org, rppt@kernel.org, boris.ostrovsky@oracle.com, sstabellini@kernel.org, jgross@suse.com, linux-mm@kvack.org, xen-devel@lists.xenproject.org, kernel-team@fb.com Hello: This series was applied to bpf/bpf-next.git (master) by Andrii Nakryiko : On Mon, 4 Mar 2024 19:05:14 -0800 you wrote: > From: Alexei Starovoitov > > v3 -> v4 > - dropped VM_XEN patch for now. It will be in the follow up. > - fixed constant as pointed out by Mike > > v2 -> v3 > - added Christoph's reviewed-by to patch 1 > - cap commit log lines to 75 chars > - factored out common checks in patch 3 into helper > - made vm_area_unmap_pages() return void > > [...] Here is the summary with links: - [v4,bpf-next,1/2] mm: Enforce VM_IOREMAP flag and range in ioremap_page_range. https://git.kernel.org/bpf/bpf-next/c/3e49a866c9dc - [v4,bpf-next,2/2] mm: Introduce VM_SPARSE kind and vm_area_[un]map_pages(). https://git.kernel.org/bpf/bpf-next/c/6b66b3a4ed5e You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html From xen-devel-bounces@lists.xenproject.org Wed Mar 06 18:49:27 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 18:49:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689466.1074462 (Exim 4.92) (envelope-from ) id 1rhwKM-0005rJ-5e; Wed, 06 Mar 2024 18:49:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689466.1074462; Wed, 06 Mar 2024 18:49:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhwKM-0005rC-2D; Wed, 06 Mar 2024 18:49:18 +0000 Received: by outflank-mailman (input) for mailman id 689466; Wed, 06 Mar 2024 18:49:17 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhwKL-0005r6-7r for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 18:49:17 +0000 Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [2607:f8b0:4864:20::102b]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 3ab816e7-dbea-11ee-afda-a90da7624cb6; Wed, 06 Mar 2024 19:49:16 +0100 (CET) Received: by mail-pj1-x102b.google.com with SMTP id 98e67ed59e1d1-299d3b09342so966794a91.2 for ; Wed, 06 Mar 2024 10:49:16 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3ab816e7-dbea-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709750954; x=1710355754; darn=lists.xenproject.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=QoO1LrsJxu96wCkUsoQYGKYUdq+e6Vh+9T/S+oZ4Tsc=; b=MgnRXC92OLARkwE/nOLbF8XueR8TFX2k1MHsIzF8ZdAZjYcICdJ5tepv/9JyuUY5JE YULKjFSI2C+L1kntykudR4DVmOJJ4shcsg4JQjzTtWJGtQHblUTNaTZlM4FR3uAKND/B utWf0kH5eqjDegMfZZJLLIHr9772C1C8hxVUPpZbMggR4ZRzIOzRva/QGFnBj/OTVs9d jlDWZ2Xs65xx7rAm26zb1Oh9/d3LQ0w0hMpj9QojMKlF/JwZ+YODWlPDAZAh2N+iA1iF QMCCLxy4i+qkZOm1v6JtM/2nG2aUblsvY8AvAlloh6Vi9B0CGM83vvOuJNmRu5tzMgvc zFRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709750954; x=1710355754; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=QoO1LrsJxu96wCkUsoQYGKYUdq+e6Vh+9T/S+oZ4Tsc=; b=Q8TEVKIIfJTS6Jj10ZfR+ME7QuWQHMDrX29VO8A+OwzbCLhipVisgY/FIReTRCymb8 8ph+xVf2N33qToltEBVAPAMZsVkLWdQn2RatpqMZtg4RzbzYB7sfKKwYEStfAXm2Su8N WiFu874WJ4XlOySdjnhF/ASoYKMbPOgdYTq3L1VZeXjO5WVWeVe2F/+myXg7l5I7UYg4 JdxHC9PE83mhN1+/SYckhGbP1ajgJBzju8Rk1eESxFNLr48ekT4iBLIU2VlIzZU+JmGu yUPNnVGu45ORujKMs4xzmvdJH4+qx6e3PYwEpkyCZiJlcE2D9T1DeIydsO1RL4Qi2Uwj yByw== X-Gm-Message-State: AOJu0Yx9++EszI8wVYsztkwFmWhC3fjodgLup3N0X73TkYIxSpaDIc/5 qy3xMHnJvKggE1COkI0Qy359lPy2FYsRfrafOg2OmAmscsAU/8gQbhlhUIDiWd2rKx6EdrSgCGg k9sYpIFI33ceggES5+ZArx/qnTnA= X-Google-Smtp-Source: AGHT+IHaJJW52dofk64COniQUe+c5hg7HGK2tCGF3WOx8xTKWraUIKgNOPsr+82GGMvG4uOy1x2xfFV2UhZABlQkpFk= X-Received: by 2002:a17:90a:b382:b0:29a:da46:8d27 with SMTP id e2-20020a17090ab38200b0029ada468d27mr15324341pjr.0.1709750954203; Wed, 06 Mar 2024 10:49:14 -0800 (PST) MIME-Version: 1.0 References: <77c1c05d-a0a0-4292-9257-9b7fbebee0e3@suse.com> <2859ad22-8714-4628-8142-fc77fc2072c3@amd.com> <214585d5-689d-4ba6-bd48-359428a7ed8f@amd.com> <19852f4d-fbeb-4314-a2cb-ab3f05da13ba@amd.com> In-Reply-To: <19852f4d-fbeb-4314-a2cb-ab3f05da13ba@amd.com> From: =?UTF-8?Q?S=C3=A9bastien_Chaumat?= Date: Wed, 6 Mar 2024 19:49:02 +0100 Message-ID: Subject: Re: [BUG]i2c_hid_acpi broken with 4.17.2 on Framework Laptop 13 AMD To: Mario Limonciello Cc: xen-devel@lists.xenproject.org, Jan Beulich , Juergen Gross , =?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= Content-Type: multipart/alternative; boundary="00000000000047a5f50613026ac0" --00000000000047a5f50613026ac0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Le mer. 6 mars 2024 =C3=A0 19:08, Mario Limonciello a =C3=A9crit : > On 3/6/2024 12:05, S=C3=A9bastien Chaumat wrote: > > > > > > Le mer. 6 mars 2024 =C3=A0 18:33, Mario Limonciello > > > a =C3=A9= crit : > > > > On 3/6/2024 11:28, S=C3=A9bastien Chaumat wrote: > > > > > > > > > > > > > > > Reasoning backward (using a kernel without the pinctrl_amd > > driver > > > to ensure xen only is at stake) : > > > checking the diff in IOAPIC between bare metal and xen > > (IRQ7 is > > > on pin07 on APIC ) > > > > > > using kernel argument : apic=3Ddebug > > > > > > bare metal : > > > [ 0.715330] fedora kernel: ... APIC VERSION: 81050010 > > > ... > > > [ 0.715433] fedora kernel: pin07, disabled, edge , high, > > V(00), > > > IRR(0), S(0), physical, D(0000), M(0) > > > > > > xen : > > > [ 2.249582] fedora kernel: ... APIC VERSION: 00000014 > > > ... > > > [ 2.249730] fedora kernel: pin07, disabled, level, low , > > V(60), > > > IRR(0), S(0), physical, D(0000), M(0) > > > > > > So the APIC table is not the same. > > > > > > As strange as it looks the (IOAPIC 0) pin07 is correctly > > described > > > by the APIC in xen but yet differently than in baremetal. > > > But the APIC message comes long after the > > > [ 1.833145] fedora kernel: xen: registering gsi 7 > triggering 0 > > > polarity 1 > > > > > > so I wonder if the APIC pin07 info had any influence. > > > > > > Finally found the fix : adding ioapic_ack=3Dnew to xen boot > parameters. > > > Not only the trackpad is now working but also the ACPI Embedded > > > Controller which is completely disabled. > > > > > > S=C3=A9bastien > > > > > That's great news! I'm personally totally unfamiliar with > > ioapic_ack=3Dnew, so I did a quick search and found out it's a Xen > > parameter (I came across > > https://xenbits.xen.org/docs/4.5-testing/misc/xen-command-line.html > > >). > > > > This mentions that "new" should be the default, so why isn't it the > > case? > > > > > > "This is the the default unless directed-EOI is supported" > > xl dmesg without forcing the parameters shows : > > > > (XEN) Enabled directed EOI with ioapic_ack_old on! > > Got it; it sounds to me like a logic mismatch in Xen then. > > > > > Also; I'd be really interested to hear what happens with s2idle wit= h > > Xen > > now (if it works). > > > > > > suspend to RAM now works :) > > Do you see /sys/power/suspend_stats/last_hw_sleep increasing with your > suspend cycle? > No, it does not increase (0). --00000000000047a5f50613026ac0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
Le=C2=A0mer. 6 mars 2024 =C3=A0=C2=A0= 19:08, Mario Limonciello <m= ario.limonciello@amd.com> a =C3=A9crit=C2=A0:
On 3/6/2024 12:05, S=C3=A9bastien Chau= mat wrote:
>
>
> Le=C2=A0mer. 6 mars 2024 =C3=A0=C2=A018:33, Mario Limonciello
> <mar= io.limonciello@amd.com <mailto:mario.limonciello@amd.com>> a =C3=A9cri= t=C2=A0:
>
>=C2=A0 =C2=A0 =C2=A0On 3/6/2024 11:28, S=C3=A9bastien Chaumat wrote: >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Reasoning backward=C2=A0 (= using a=C2=A0 kernel without the pinctrl_amd
>=C2=A0 =C2=A0 =C2=A0driver
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0to ensure xen only is at s= take) :
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0checking the diff i= n IOAPIC=C2=A0 between bare metal and xen
>=C2=A0 =C2=A0 =C2=A0(IRQ7 is
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0on pin07 on APIC )
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0using kernel argument : ap= ic=3Ddebug
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0bare metal :
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0[ =C2=A0 =C2=A00.715330] f= edora kernel: ... APIC VERSION: 81050010
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0...
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0[ =C2=A0 =C2=A00.715433] f= edora kernel: =C2=A0pin07, disabled, edge , high,
>=C2=A0 =C2=A0 =C2=A0V(00),
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0IRR(0), S(0), physical, D(= 0000), M(0)
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0xen :
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0[ =C2=A0 =C2=A02.249582] f= edora kernel: ... APIC VERSION: 00000014
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0...
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0[ =C2=A0 =C2=A02.249730] f= edora kernel: =C2=A0pin07, disabled, level, low ,
>=C2=A0 =C2=A0 =C2=A0V(60),
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0IRR(0), S(0), physical, D(= 0000), M(0)
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0So the APIC table is not t= he same.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0As strange as it looks the= =C2=A0 (IOAPIC 0) pin07 is correctly
>=C2=A0 =C2=A0 =C2=A0described
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0by the APIC in xen but yet= differently than in baremetal.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0But the APIC message comes= long after the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0[ =C2=A0 =C2=A01.833145] f= edora kernel: xen: registering gsi 7 triggering 0
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0polarity 1
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0so I wonder if the APIC pi= n07 info had any influence.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Finally found the fix : adding ioapic_ack=3Dn= ew to xen boot parameters.
>=C2=A0 =C2=A0 =C2=A0 > Not only the trackpad is now working but also= the ACPI Embedded
>=C2=A0 =C2=A0 =C2=A0 > Controller which is completely disabled.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > S=C3=A9bastien
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0That's great news!=C2=A0 I'm personally tot= ally unfamiliar with
>=C2=A0 =C2=A0 =C2=A0ioapic_ack=3Dnew, so I did a quick search and found= out it's a Xen
>=C2=A0 =C2=A0 =C2=A0parameter (I came across
>=C2=A0 =C2=A0 =C2=A0https://x= enbits.xen.org/docs/4.5-testing/misc/xen-command-line.html
>=C2=A0 =C2=A0 =C2=A0<https= ://xenbits.xen.org/docs/4.5-testing/misc/xen-command-line.html>). >
>=C2=A0 =C2=A0 =C2=A0This mentions that "new" should be the de= fault, so why isn't it the
>=C2=A0 =C2=A0 =C2=A0case?
>
>
>=C2=A0 =C2=A0"This is the the default unless directed-EOI is suppo= rted"
> xl dmesg without forcing the parameters shows :
>
> (XEN) Enabled directed EOI with ioapic_ack_old on!

Got it; it sounds to me like a logic mismatch in Xen then.

>
>=C2=A0 =C2=A0 =C2=A0Also; I'd be really interested to hear what hap= pens with s2idle with
>=C2=A0 =C2=A0 =C2=A0Xen
>=C2=A0 =C2=A0 =C2=A0now (if it works).
>
>
> suspend to RAM now works :)

Do you see /sys/power/suspend_stats/last_hw_sleep increasing with your
suspend cycle?

No,=C2=A0 it does not in= crease (0).
=C2=A0
--00000000000047a5f50613026ac0-- From xen-devel-bounces@lists.xenproject.org Wed Mar 06 18:50:56 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 18:50:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689469.1074471 (Exim 4.92) (envelope-from ) id 1rhwLv-0007kI-J9; Wed, 06 Mar 2024 18:50:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689469.1074471; Wed, 06 Mar 2024 18:50:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhwLv-0007kB-G5; Wed, 06 Mar 2024 18:50:55 +0000 Received: by outflank-mailman (input) for mailman id 689469; Wed, 06 Mar 2024 18:50:54 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhwLt-0007k1-Tq for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 18:50:53 +0000 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on20615.outbound.protection.outlook.com [2a01:111:f400:7ea9::615]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 73923d18-dbea-11ee-a1ee-f123f15fe8a2; Wed, 06 Mar 2024 19:50:51 +0100 (CET) Received: from BY3PR10CA0013.namprd10.prod.outlook.com (2603:10b6:a03:255::18) by DS7PR12MB8420.namprd12.prod.outlook.com (2603:10b6:8:e9::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7339.39; Wed, 6 Mar 2024 18:50:47 +0000 Received: from SJ5PEPF000001CE.namprd05.prod.outlook.com (2603:10b6:a03:255:cafe::4f) by BY3PR10CA0013.outlook.office365.com (2603:10b6:a03:255::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7339.39 via Frontend Transport; Wed, 6 Mar 2024 18:50:47 +0000 Received: from SATLEXMB03.amd.com (165.204.84.17) by SJ5PEPF000001CE.mail.protection.outlook.com (10.167.242.38) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7362.11 via Frontend Transport; Wed, 6 Mar 2024 18:50:46 +0000 Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Wed, 6 Mar 2024 12:50:45 -0600 Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB05.amd.com (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Wed, 6 Mar 2024 12:50:45 -0600 Received: from fedora.mshome.net (10.180.168.240) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.35 via Frontend Transport; Wed, 6 Mar 2024 12:50:44 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 73923d18-dbea-11ee-a1ee-f123f15fe8a2 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FUko/WRHKKy4khx/gNd6FIZb6OTcYmxUc56ULo6LbLSygrtZGNCn1jYvlwo+/8GDDjvqVICJobuI/jN4DZI8ap3BICpjp2d5Gh0zIwhS6AtPCK3aBhwrngpC2PV13EzmLrF6HUlh2ER+kkU7mz9N5y5hsAc/Dy2SYpKq783Q9mbWHJO8kbt0map2cvdGoh2x3HEq1wXnYM1OZcdOvyK4Cg7WRy7XrPvgGIC5GW2mlzX9MdRq6KRqQV6ZqIgnUc32F5NAGL1VZ5Bv1fOjSSUtoV1gDsLUZcMbBNSsaRj1hlbqlKCg6/PCWzsO0JBA/FdNbVlEdC/3dh+sgmzZrZ7HKg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=UXHnUUkP0I4VeoKV7/n47noRYWOiKkviRFLs6MBrGmU=; b=FmbQqw004F3CuzhI2HYEsqlBILPWJz1rt8ssFzTycTIlC+GSflBoTa8+NjDNl5Ib4gPEYoo0AaoqTtBOTuo9nD2A+BAj4geyAjmCWizB3DFIGjN3VGhtWUP0EwsOzJxOvSOEwsYfzp0ctQchpsDUhPy9ShslXBnVopuLd79T8/aAajTNJqg5VLiqBqiYQoRo002vFy1IoNfEkwlzpvQSze5yOdySHMJLgsoS8b5ZuHAEOqqOBU6FtdlYpEJ6n+fldAwQxeb/BuBl4tvjDWt7cBcsc9WTVrl5t2d/wPPnV5/fvUFgn+3oH/YvpvOwiuzJWM93H+7ePhV+O15G6/heYQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UXHnUUkP0I4VeoKV7/n47noRYWOiKkviRFLs6MBrGmU=; b=Ss+RV/atmNx1YgCBe/9QLqV/+GEdZy2V6cx1u35BGLXfYZHaVD2Im3MOEGHLYjFQMwvNUXKImsZqrRdU5B5Fs1lLZAI393uMRYbhkUp7YCR+1bu5ER/U6h/HBQagYB32uQrviyGGKTIJWumhBR1KMNKHWCw4ugp2vFz7QdOVRA0= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C From: Jason Andryuk To: CC: Jason Andryuk , Andrew Cooper , George Dunlap , "Jan Beulich" , Julien Grall , "Stefano Stabellini" , Wei Liu , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH 0/3] x86/pvh: Support relocating dom0 kernel Date: Wed, 6 Mar 2024 13:50:29 -0500 Message-ID: <20240306185032.103216-1-jason.andryuk@amd.com> X-Mailer: git-send-email 2.44.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain Received-SPF: None (SATLEXMB05.amd.com: jason.andryuk@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ5PEPF000001CE:EE_|DS7PR12MB8420:EE_ X-MS-Office365-Filtering-Correlation-Id: c9e4a1b4-af04-4651-4b1d-08dc3e0e5598 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Pl4qjhsryXvRh5yMGIJ3kaizq/WN9iqLE4A8pnHbGPNod2NMO3JNEGms/gOPYQyDIHEXOB5kazUr+QmkRZhmrgJrVFuhijGECLQfEfjxTvQsb1pgbNaft/9u/TOqs0W6/5GcbfxPuSFHontEZUKMWJgMPUDc9ckZ1vl/Hra5tnC66gpkh1jniVQ1d86xWRPettYR5Aag/80W3G5hOohKSDZT1i4CVuZg1KtxU8FALQiB66SC4oScueb2S4sflhfZgWKFJ4m519mLqhncaFbiLoei+AEZcWl4+bS06FzY/Dv9cBF08elFvLgHaHoEctGJl8e7KkJDXXx8A8ynRcbsx10Qg+UKle9YSkOZI0m4toNti7qlzl9pxTD3h+CsFG1Te9DkIB0vKrXQgeB08lVfmyDtLaXS93vNwGq9izClwjTGD13CCsZzMOfaN/giP95UydDKtYkdmFRwZGKX1pHX4sW86DJF8Mq0cgWi4/Y34DB4v5zlflyI1uaNrLhNI4dIeVSmWkwRSUZLiWeHHm15tNeFqIrq1g7UarUh4NtfqGz+x1tzXjhTcCE0JNgT1TKBuHERxz3bFAGeW1C6Uxtbv/glGs59IXmHsUv//YsLy5Bcx3YBaiMIfB+BP371Nks5nxMiA78o5j5G9m3ol2CGHK6QLJKFFvBG6pqBKpw0pvkRFTkS8SwMqkwbTRBT3EJAQjn4xELpva7j46DIA6uruc7bF7kK8dQg+Z2uLXH4mu3Z/vCW7wRl/BZjYzy7hDqx X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(36860700004)(376005)(82310400014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Mar 2024 18:50:46.4869 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c9e4a1b4-af04-4651-4b1d-08dc3e0e5598 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SJ5PEPF000001CE.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR12MB8420 Xen tries to load a PVH dom0 kernel at the fixed guest physical address from the elf headers. For Linux, this defaults to 0x1000000 (16MB), but it can be configured. Unfortunately there exist firmwares that have reserved regions at this address, so Xen fails to load the dom0 kernel since it's not RAM. The other issue is that the Linux PVH entry point is not position-independent. It expects to run at the compiled CONFIG_PHYSICAL_ADDRESS. This patch set expands the PVH dom0 builder to try to relocate the kernel if needed and possible. XENFEAT_pvh_relocatable is added for kernels to indicate they are relocatable. However, we may want to switch to an additional ELF note with the kernel alignment. Linux specifies a kernel alignment in the bzImage boot_params.setup_header, but that is not present the ELF vmlinux file. The first patch fixes some whitespace in features.h The second patch enhances bzimage_parse to pull the kernel_alignment into an optional align pointer. The third patch expands the pvh dom0 kernel placement code. I'll post an additional patch showing the Linux changes to make PVH relocatable. Jason Andryuk (3): features.h: Replace hard tabs xen/x86: bzImage parse kernel_alignment x86/PVH: Support relocatable dom0 kernels xen/arch/x86/bzimage.c | 4 +- xen/arch/x86/hvm/dom0_build.c | 113 ++++++++++++++++++++++++++++- xen/arch/x86/include/asm/bzimage.h | 3 +- xen/arch/x86/pv/dom0_build.c | 2 +- xen/include/public/features.h | 9 ++- 5 files changed, 124 insertions(+), 7 deletions(-) -- 2.44.0 From xen-devel-bounces@lists.xenproject.org Wed Mar 06 18:50:59 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 18:50:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689470.1074482 (Exim 4.92) (envelope-from ) id 1rhwLz-00081G-QI; Wed, 06 Mar 2024 18:50:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689470.1074482; Wed, 06 Mar 2024 18:50:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhwLz-000815-Mx; Wed, 06 Mar 2024 18:50:59 +0000 Received: by outflank-mailman (input) for mailman id 689470; Wed, 06 Mar 2024 18:50:58 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhwLy-0007k1-Jm for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 18:50:58 +0000 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on20600.outbound.protection.outlook.com [2a01:111:f403:2412::600]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 76ba7427-dbea-11ee-a1ee-f123f15fe8a2; Wed, 06 Mar 2024 19:50:57 +0100 (CET) Received: from SJ0PR03CA0115.namprd03.prod.outlook.com (2603:10b6:a03:333::30) by PH7PR12MB6393.namprd12.prod.outlook.com (2603:10b6:510:1ff::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.24; Wed, 6 Mar 2024 18:50:51 +0000 Received: from SJ5PEPF000001C9.namprd05.prod.outlook.com (2603:10b6:a03:333:cafe::41) by SJ0PR03CA0115.outlook.office365.com (2603:10b6:a03:333::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.24 via Frontend Transport; Wed, 6 Mar 2024 18:50:51 +0000 Received: from SATLEXMB03.amd.com (165.204.84.17) by SJ5PEPF000001C9.mail.protection.outlook.com (10.167.242.37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7362.11 via Frontend Transport; Wed, 6 Mar 2024 18:50:50 +0000 Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Wed, 6 Mar 2024 12:50:50 -0600 Received: from fedora.mshome.net (10.180.168.240) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.35 via Frontend Transport; Wed, 6 Mar 2024 12:50:49 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 76ba7427-dbea-11ee-a1ee-f123f15fe8a2 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IHlGKkbhfi7Hno1lfkBcEycr8YCl+rP1+Fn8GGHHSAaSw6tYYTXPceyeAWBVx+OcoH1DPyLltbJvAII5Gi4RDlzJEYUjOz03gkA3WUFQhlqyoOqQAnYVNjynKvhJyHdq646IPwoF5FSUoFIHkwUo8XmbzudXdZxkHRznj8RRxCISOVdlTVCMteA8RYySPyEjmSAg8/tMq3bMe0tQtagBg9W+YoAr9henhTIX/UTeBIZTA21p4E4hRUoUuof+m6yXab5PwTzCZfhSvORpp0Sj58o9hLKNjBctjf1B3xx4skFHM+RCk5EcYSvk0ljnliYKYcnKen6ENIjFwAlOlNG5Vw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=cI4hrktpx/kWTNvhDVvDVjPbshJv3KJBlQbf2ujpAwE=; b=YOg9uJzfvyraoU5rWhFC90dXk4cyqI1NfB/oLyMp5ilzlW0j2AeN6cXvgg/weyMr8u9TyY7Sn1+adXNIcVqQ6Eba7loAESyPmOGG6p/9xhfYRgKz0Vhf8BdZZUCGuYWyFatfh/rWiG3nS+OQa2TXtdMSE06/pbkXv7b8Ijdv8o7VyjctD5I9ao029o1cWjPEpvCVNK1OaBWijDRq9/sDekoPOGrz7cto0XTtjoJAfjItTUC+XJzFZ+C8MTTcbaAWNTojyardwCdGt6BIO1VPruWGDHLxUVa1GIWSS8USLsccOL8YiMvLGXK2zWvvyKV/YcNdq8BCb3M+PU0WXC3wAQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cI4hrktpx/kWTNvhDVvDVjPbshJv3KJBlQbf2ujpAwE=; b=F5pxZkdpyntkA89+NaICWhOxyjVJ8Q5jfDN3PuXiHHok7ReO50KGp2ZDQ81CIcvROjlDriGQPXQ8NK2Oj9YTLwpcCg7mDLuVvaSh4LYO8VO23hgRqdAdeOuXNPPN4kcaSyJPZsk2xKVugOJ3JvD76eDvxbNlAM+kscBpoIl/KOI= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C From: Jason Andryuk To: CC: Jason Andryuk , Andrew Cooper , George Dunlap , "Jan Beulich" , Julien Grall , "Stefano Stabellini" , Wei Liu Subject: [PATCH 1/3] features.h: Replace hard tabs Date: Wed, 6 Mar 2024 13:50:30 -0500 Message-ID: <20240306185032.103216-2-jason.andryuk@amd.com> X-Mailer: git-send-email 2.44.0 In-Reply-To: <20240306185032.103216-1-jason.andryuk@amd.com> References: <20240306185032.103216-1-jason.andryuk@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain Received-SPF: None (SATLEXMB03.amd.com: jason.andryuk@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ5PEPF000001C9:EE_|PH7PR12MB6393:EE_ X-MS-Office365-Filtering-Correlation-Id: daa1f0f3-b79f-4560-aa91-08dc3e0e582a X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: +E05yt9dPVP8ofr53jEtvKaCBFI/G/YO42q/37LEL6XbUxv1xfxpyoWIZkBk3GdaBxbjQaZQLSz2sFVxgEPXo/xXt+ObELXOqOUX3cnJUgkwGO+8H9NNzvKkafc2DwztYuo4dzItFfiSNpRCQ/G5UbbslukzWZ6Usv23uWHmiEYV1jOyPaCq/MQ7pj3zxQxx65I33qrhp7e/fgwfqeq8TYaOxLN/Qle7l9EPlB2EoE3vyJpbY3mCB34hDlMVQo9l5a91jROOgsQfbyc34JyVzlszEy8EyNyGqmQ/UuZbpxi+iup+2yFgqYnGU4M53Zcduo2YneRc321WhP3gN2mYzWliVWEd+EQupnCHlW2Bbd5VXgXQLd2DhPKnoKwiwe4YUWUb1q733LrSqxe6Jp8P68EDIttrp7fE2WsVUIH8Wv1g9QKMZIdXmxED7E1Z5iHj9cSBuhSgiAz6uCIqZjV4b+N9W6cp1bJ23IiTmw1BBvFA1a6zPAWNNXul8iJolpo7IAXffonZu1H0WCPMfozdg530zjgDDNMaA7xHz7itU+DNmaJaCRjrfgvVW2KcHlzS9JKaNQT6DrMRL4SBEqvoIBNPHzcLhbvIRD18jnTXqoZvGwisTSG4XwoUVIH1M+wRYyQVAXXugzSndg34hXaJZMYvhsJzmPiGf3kIipJtZiqEO6c+Pp7Tu1t8ph6tDQeRT5SUD8v7iPDkGMpka99yMEOaHRawUTAJeyOvwLlmMqOMO/Lfbg7E81E2ze7sh5Vf X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(82310400014)(36860700004)(376005);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Mar 2024 18:50:50.8173 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: daa1f0f3-b79f-4560-aa91-08dc3e0e582a X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SJ5PEPF000001C9.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB6393 Replace hard tabs to match the rest of the file. Fixes: 48a3fd1432 ("domain: expose newly introduced hypercalls as XENFEAT") Signed-off-by: Jason Andryuk --- xen/include/public/features.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/xen/include/public/features.h b/xen/include/public/features.h index 36936f6a4e..4437f25d25 100644 --- a/xen/include/public/features.h +++ b/xen/include/public/features.h @@ -117,8 +117,8 @@ * VCPUOP_register_runstate_phys_area * VCPUOP_register_vcpu_time_phys_area */ -#define XENFEAT_runstate_phys_area 18 -#define XENFEAT_vcpu_time_phys_area 19 +#define XENFEAT_runstate_phys_area 18 +#define XENFEAT_vcpu_time_phys_area 19 #define XENFEAT_NR_SUBMAPS 1 -- 2.44.0 From xen-devel-bounces@lists.xenproject.org Wed Mar 06 18:51:04 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 18:51:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689471.1074492 (Exim 4.92) (envelope-from ) id 1rhwM4-0008Iu-3P; Wed, 06 Mar 2024 18:51:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689471.1074492; Wed, 06 Mar 2024 18:51:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhwM3-0008Im-Uj; Wed, 06 Mar 2024 18:51:03 +0000 Received: by outflank-mailman (input) for mailman id 689471; Wed, 06 Mar 2024 18:51:02 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhwM2-0007k1-Rl for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 18:51:02 +0000 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on20630.outbound.protection.outlook.com [2a01:111:f400:7ea9::630]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 79f22f67-dbea-11ee-a1ee-f123f15fe8a2; Wed, 06 Mar 2024 19:51:01 +0100 (CET) Received: from MW4PR03CA0201.namprd03.prod.outlook.com (2603:10b6:303:b8::26) by CH3PR12MB8305.namprd12.prod.outlook.com (2603:10b6:610:12e::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.24; Wed, 6 Mar 2024 18:50:55 +0000 Received: from MWH0EPF000971E8.namprd02.prod.outlook.com (2603:10b6:303:b8:cafe::df) by MW4PR03CA0201.outlook.office365.com (2603:10b6:303:b8::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.24 via Frontend Transport; Wed, 6 Mar 2024 18:50:55 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by MWH0EPF000971E8.mail.protection.outlook.com (10.167.243.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7362.11 via Frontend Transport; Wed, 6 Mar 2024 18:50:54 +0000 Received: from SATLEXMB06.amd.com (10.181.40.147) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Wed, 6 Mar 2024 12:50:53 -0600 Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB06.amd.com (10.181.40.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Wed, 6 Mar 2024 12:50:53 -0600 Received: from fedora.mshome.net (10.180.168.240) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.35 via Frontend Transport; Wed, 6 Mar 2024 12:50:52 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 79f22f67-dbea-11ee-a1ee-f123f15fe8a2 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=P821ekqWkwpb1WpA9bQdt8MM3c3l5S4L03WdI2mXex3LC5tE7GgToPIn4ua7/DebJmGEC4uv3ogdM9nVRownD3aGvGvMUWNh9BuoqpAZI1H8I/1oRn/+jWJwwbSSNmKhu+EcT43xuKi9OISHFyXcC5u773+rXuPyMCUAqLr+wTz+/KMS91jetNP/OpaSmQ6/hHe2jz8i20Ht0zYFFlp6Y8AVHytLoPKOSCBwsZJJD10olZkcwf20ZATflUgJkScTpJSzfyJ3uQOFs4hRqjE9ugKVbdm7BQExlFK49kySRcma1CVZyh9zoZcX5DvEdMiVq0Y8ZvYe6b+B+w8iEA+98w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=qJKZwTEKdVYwdWhkLN1Jw/ThuraaXkFqSODcmfGNrWU=; b=nL94bnlCv/4bveM5XxdQwMJ0898M/k+9UnFkJJ0xcTxLUBS4/ViT7YFuN0IWXJXYMPHP2jimM+4uZS9sQ0DgBhKuyXz8Jled+SSq2ho84UFMemOe4l08DRmYbjNDogEPqt/aGyRHtWkO+YeTNO6CPyfuUbmcWvqNeieiKnFt8fZ0nae4BRxrdXR/Xzryir3rpm37duXj7ngxsmDLTi7PyUt/jHLMVsXyFnANdhN5BOZ6BJGeIeehVG9dEDSlGg7e+2qGyBk8DGA25HCFDOGAmC2YFycfjXkYXiKKJLxGK+HZMO3FpzZj8NIhVn1MzXRTcLlSQUI9M7zZIURU9+4yGQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qJKZwTEKdVYwdWhkLN1Jw/ThuraaXkFqSODcmfGNrWU=; b=2NWB+CWppj92dEdqirPOa6kUeHGxtu3LKUURz8JwY1BpZF6DXrQ3KeoD/X3veFKjWUYmEfP5+nOpRuYgRct4Jf0h6BJYdxFHJMgFlSBc7kYZQ+zS7KsbISGPUBxpMoJy39m7GTBa3tAHMle1yFWaEO4s4w/OCY8KTWZ+oPtJAbc= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C From: Jason Andryuk To: CC: Jason Andryuk , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Wei Liu Subject: [PATCH 2/3] xen/x86: bzImage parse kernel_alignment Date: Wed, 6 Mar 2024 13:50:31 -0500 Message-ID: <20240306185032.103216-3-jason.andryuk@amd.com> X-Mailer: git-send-email 2.44.0 In-Reply-To: <20240306185032.103216-1-jason.andryuk@amd.com> References: <20240306185032.103216-1-jason.andryuk@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MWH0EPF000971E8:EE_|CH3PR12MB8305:EE_ X-MS-Office365-Filtering-Correlation-Id: ac1c0a7e-1776-4cc5-aa16-08dc3e0e5a4c X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: hG93AnmSbi858NSe54/nyBoMuLzg/sPMOCDHXAG3jJRTQJOHdISHXP+YOnbAdJNm2F//16v/qHGRhu8XJaMq0wVyjAh7pFRf0SxRRExG45t7RE2zo7UZjvPecWpWbzWvzrKHH0Hdoc7wNdnL4Hs3RAh8m6Q7oZSBQ+CPv3pR0xmgWpWjthRDIgaMeLUUuM+HGQb78Bys13JWDoD5x5Xu7x/yUYVs4LP1XTbFlnVQz3zpum19vXeNPSUVZBKWoB6E1UEpwBGxStoPjrNTPnUTt/h22l/O3vrL7nWW+WcEmifnY2W0P+AA5yGLhojiLHIS+z/W9fp1kVVbsFwxTM3jE27s9osV5Z2rtrtxQFmW+eMcv4yK86adiifx9E9sc1y1I8vAF3I4IQN+QD4+NBcLwJxsZh+z53BI79hVivXNW1+Qmr0TThQ9zAJY7MoGy9SE7sVJcX+pkWVJ2u0eJrpo3eEPv5fcP+Nur9HiiCUV+kjOrKvvydekWKv+r3uZqNCo56gHaWlxVYdiRU8N7SVS3J/OeJp/4Mgph8/H14S6reAuICNq7U+iGF3tkBUzUyw00VpLQsgEewSEOcXoGNqQ5IuV135Geo874MZI9rKloeSUc17bs+kepsgJ71IK9JqLO7cIlNyENAxmhiGtqsAO4Wo6p88H/XjaiNuy4264nS3mp/HOqlLyh0dGtwdbJWFvPu5L0LZaUDGb5fsXo+lKOGawQXV/D5DNDGRQl/mHalrZoSW1kGOO+E1fSuRzmNo/ X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(82310400014)(36860700004)(376005);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Mar 2024 18:50:54.3643 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ac1c0a7e-1776-4cc5-aa16-08dc3e0e5a4c X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: MWH0EPF000971E8.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB8305 Expand bzimage_parse() to return kernel_alignment from the setup_header. This will be needed if loading a PVH kernel at a physical offset to compensate for a reserved E820 region. Signed-off-by: Jason Andryuk --- xen/arch/x86/bzimage.c | 4 +++- xen/arch/x86/hvm/dom0_build.c | 4 +++- xen/arch/x86/include/asm/bzimage.h | 3 +-- xen/arch/x86/pv/dom0_build.c | 2 +- 4 files changed, 8 insertions(+), 5 deletions(-) diff --git a/xen/arch/x86/bzimage.c b/xen/arch/x86/bzimage.c index ac4fd428be..0f4cfc49f7 100644 --- a/xen/arch/x86/bzimage.c +++ b/xen/arch/x86/bzimage.c @@ -105,7 +105,7 @@ unsigned long __init bzimage_headroom(void *image_start, } int __init bzimage_parse(void *image_base, void **image_start, - unsigned long *image_len) + unsigned long *image_len, unsigned int *align) { struct setup_header *hdr = (struct setup_header *)(*image_start); int err = bzimage_check(hdr, *image_len); @@ -118,6 +118,8 @@ int __init bzimage_parse(void *image_base, void **image_start, { *image_start += (hdr->setup_sects + 1) * 512 + hdr->payload_offset; *image_len = hdr->payload_length; + if ( align ) + *align = hdr->kernel_alignment; } if ( elf_is_elfbinary(*image_start, *image_len) ) diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c index 0ceda4140b..bbae8a5645 100644 --- a/xen/arch/x86/hvm/dom0_build.c +++ b/xen/arch/x86/hvm/dom0_build.c @@ -548,12 +548,14 @@ static int __init pvh_load_kernel(struct domain *d, const module_t *image, struct elf_binary elf; struct elf_dom_parms parms; paddr_t last_addr; + unsigned int align = 0; struct hvm_start_info start_info = { 0 }; struct hvm_modlist_entry mod = { 0 }; struct vcpu *v = d->vcpu[0]; int rc; - if ( (rc = bzimage_parse(image_base, &image_start, &image_len)) != 0 ) + rc = bzimage_parse(image_base, &image_start, &image_len, &align); + if ( rc != 0 ) { printk("Error trying to detect bz compressed kernel\n"); return rc; diff --git a/xen/arch/x86/include/asm/bzimage.h b/xen/arch/x86/include/asm/bzimage.h index 7ed69d3910..de4e9a446f 100644 --- a/xen/arch/x86/include/asm/bzimage.h +++ b/xen/arch/x86/include/asm/bzimage.h @@ -4,8 +4,7 @@ #include unsigned long bzimage_headroom(void *image_start, unsigned long image_length); - int bzimage_parse(void *image_base, void **image_start, - unsigned long *image_len); + unsigned long *image_len, unsigned int *align); #endif /* __X86_BZIMAGE_H__ */ diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c index d8043fa58a..e9fa8a9a82 100644 --- a/xen/arch/x86/pv/dom0_build.c +++ b/xen/arch/x86/pv/dom0_build.c @@ -416,7 +416,7 @@ int __init dom0_construct_pv(struct domain *d, d->max_pages = ~0U; - if ( (rc = bzimage_parse(image_base, &image_start, &image_len)) != 0 ) + if ( (rc = bzimage_parse(image_base, &image_start, &image_len, NULL)) != 0 ) return rc; if ( (rc = elf_init(&elf, image_start, image_len)) != 0 ) -- 2.44.0 From xen-devel-bounces@lists.xenproject.org Wed Mar 06 18:51:05 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 18:51:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689472.1074502 (Exim 4.92) (envelope-from ) id 1rhwM5-000079-Au; Wed, 06 Mar 2024 18:51:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689472.1074502; Wed, 06 Mar 2024 18:51:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhwM5-00006w-6r; Wed, 06 Mar 2024 18:51:05 +0000 Received: by outflank-mailman (input) for mailman id 689472; Wed, 06 Mar 2024 18:51:03 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhwM3-0007k1-Rx for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 18:51:03 +0000 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on20600.outbound.protection.outlook.com [2a01:111:f403:2418::600]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 7a3f438f-dbea-11ee-a1ee-f123f15fe8a2; Wed, 06 Mar 2024 19:51:01 +0100 (CET) Received: from BYAPR01CA0027.prod.exchangelabs.com (2603:10b6:a02:80::40) by LV8PR12MB9405.namprd12.prod.outlook.com (2603:10b6:408:1fa::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7339.38; Wed, 6 Mar 2024 18:50:58 +0000 Received: from SJ5PEPF000001CA.namprd05.prod.outlook.com (2603:10b6:a02:80:cafe::8e) by BYAPR01CA0027.outlook.office365.com (2603:10b6:a02:80::40) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7339.37 via Frontend Transport; Wed, 6 Mar 2024 18:50:57 +0000 Received: from SATLEXMB03.amd.com (165.204.84.17) by SJ5PEPF000001CA.mail.protection.outlook.com (10.167.242.39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7362.11 via Frontend Transport; Wed, 6 Mar 2024 18:50:57 +0000 Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Wed, 6 Mar 2024 12:50:56 -0600 Received: from fedora.mshome.net (10.180.168.240) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.35 via Frontend Transport; Wed, 6 Mar 2024 12:50:55 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 7a3f438f-dbea-11ee-a1ee-f123f15fe8a2 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ehYy/t29tVSxeR6pttbMARcufQoWH+zAxrqUJu/dx1ARtrToPVVtN5FawayNQwOw2gYvaNIwLJfB5sf9AqQ3T0SwHoYaP4ZV8Fo2POIUi4XNAnxcyJsFzIdUf6t9YxQoJJcDzItnLcUack8QDJXjCUh6H0hH+nYkYN1/ntdYUzlMO91Sie80hExVCnp+O0V26gJj/ubS0D1LvRBbBvXpMlkA9JCcUhnIdWkLRZaaA4uZC95qWv3jfd0mMysQeBj7O/+8d0BWWFL4aWVX5XQKRYn0Wsz1Eb+bLgPKQJRclPyHmP0X4/ODEDiNKrBYF1NOb5qjyDpiKFlj62zgRzB53Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=T3CZf4Zi/+LKE/JxglBmU2IixkGLM4biIR5p9SBTScI=; b=fqH2vtXhqKt590lDgbNd1+yk7bZk8PD1I2izsTmvbT2WwRq/suTbG1sJiKC44mzQJAUD085PW1gDJHrIa73I0TALmxa6s6hrInr9WcCFpuLdU+xBPIVEbXUGenhFx9dxhr1aNpUSK8JKFDAwloPmM3dEiCHGHHHphO5EXrmR0iBJR8zL0iLZq2t3E3IemrRsDWIKf+ZeAHB+CctsqsoXdYqo0cfgnQlYUsXF/3LaaVm+pVEdW9k3l3AiV954De7I1N43sMboFb1Nx2uuOVW53057jnJpvnj/ou02oWAqswSo46lyaBAWKt9Zm2EQC0honLogFatXYskgj0BC3ahtZg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=T3CZf4Zi/+LKE/JxglBmU2IixkGLM4biIR5p9SBTScI=; b=J1LoZ5QVDcPbn6hCpZgemz32LwgVxS1C1KkiQY5x/SGjd4W/k5ZiUMuoZBQuThjs/7zX64rmJeDLQomtoURhuK28rW5uKCM/nANpNgfBezsBdf93DJtKrlqn9KfDa+Pb/OY63dWCz8IB8hlx8lru5/zgJpXIM5+2A2bWjCSjqaA= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C From: Jason Andryuk To: CC: Jason Andryuk , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Wei Liu , George Dunlap , Julien Grall , Stefano Stabellini Subject: [PATCH 3/3] x86/PVH: Support relocatable dom0 kernels Date: Wed, 6 Mar 2024 13:50:32 -0500 Message-ID: <20240306185032.103216-4-jason.andryuk@amd.com> X-Mailer: git-send-email 2.44.0 In-Reply-To: <20240306185032.103216-1-jason.andryuk@amd.com> References: <20240306185032.103216-1-jason.andryuk@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain Received-SPF: None (SATLEXMB03.amd.com: jason.andryuk@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ5PEPF000001CA:EE_|LV8PR12MB9405:EE_ X-MS-Office365-Filtering-Correlation-Id: dd647ce7-5f4d-4745-6283-08dc3e0e5bf9 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: OB6lho4d4qmSJMsKLPPvUveVfU8ytiL8AGNH+LlCnFFswKRijAbPVaXix9XKQfuMKykWNvlvRBGMMbylFnPME6+bk1+G6ycByO1/dzEASRhNdv5xulj4ApsBbkoQB+f8R6o3AAcdi0+8kvKvYf2eAxC/Vi+TYGzZKhntTg0ONVKnxSxUodUT3gQwMOVqMUJu53AnymdMI+MGp8bemV8MbOZGalmwhF8tnlSMP5DiWIlyUNVpfIe/59eGgF0XFL88CMsDucZvU/NZz0UCPxeLfQyK7diqnDUkfufqDg1I4o0af+oWbBGZESCdURsm9Hi01sZ4Lq6aTfFmGcQrrlqKa/GN6vsazC3zKX8n4dcR6VM6bWgil4//KXlp+CVjT/fLE5/SvdjwCdDvr5oiMbb/QTkuamdAmkAAfjRkSPQIr6l5GzZsa1owD6xET2EmAZ/86A/pB/Rcc6xnje5qZYb/jYZoIFspnN3lZ5pRxiYNwTPbVbxSfd7HkftxzwfB8bgtmYxMHISOd4reh5AgwrJiS2NroyPxHRi40nTgnVw1b5cYL1XcByC/5pn/f4XRTibe9vvcyjs3fc9iRO5NGjq8CUNOhREDjv8Py9/7uTNbqu6cVGSxj/wMVRADHhKTCNnoqfj8QfX3vnJCnJyIor8JpN4uPQA3ZhZZCKtfnZ1rrFMNYn+Jgzfgl91AUvzGTPCc/plsugpCFGNhcarZNwSe3mCKJswkcmcAJOMzrvMN0++KQUffu643851tiB/vdkrx X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(82310400014)(36860700004)(376005);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Mar 2024 18:50:57.2052 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: dd647ce7-5f4d-4745-6283-08dc3e0e5bf9 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SJ5PEPF000001CA.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV8PR12MB9405 Xen tries to load a PVH dom0 kernel at the fixed guest physical address from the elf headers. For Linux, this defaults to 0x1000000 (16MB), but it can be configured. Unfortunately there exist firmwares that have reserved regions at this address, so Xen fails to load the dom0 kernel since it's not RAM. The PVH entry code is not relocatable - it loads from absolute addresses, which fail when the kernel is loaded at a different address. With a suitably modified kernel, a reloctable entry point is possible. Add the XENFEAT_pvh_relocatable flag to let a kernel indicate that it supports a relocatable entry path. Change the loading to check for an acceptable load address. If the kernel is relocatable, support finding an alternate load address. Linux cares about its physical alignment. This can be pulled out of the bzImage header, but not from the vmlinux ELF file. If an alignment can't be found, use 2MB. Signed-off-by: Jason Andryuk --- Put alignment as a new ELF note? Presence of that note would indicate relocation support without a new XENFEAT flag. Default alignment to a multiple of 2MB to make more cases work? It has to be a power of two, and a multiple might allow loading a customized kernel. A larger alignment would limit the number of possible load locations. --- xen/arch/x86/hvm/dom0_build.c | 109 ++++++++++++++++++++++++++++++++++ xen/include/public/features.h | 5 ++ 2 files changed, 114 insertions(+) diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c index bbae8a5645..34d68ee8fb 100644 --- a/xen/arch/x86/hvm/dom0_build.c +++ b/xen/arch/x86/hvm/dom0_build.c @@ -537,6 +537,109 @@ static paddr_t __init find_memory( return INVALID_PADDR; } +static bool __init check_load_address( + const struct domain *d, const struct elf_binary *elf) +{ + paddr_t kernel_start = (paddr_t)elf->dest_base & PAGE_MASK; + paddr_t kernel_end = ROUNDUP((paddr_t)elf->dest_base + elf->dest_size, + PAGE_SIZE); + unsigned int i; + + /* + * The memory map is sorted and all RAM regions starts and sizes are + * aligned to page boundaries. + */ + for ( i = 0; i < d->arch.nr_e820; i++ ) + { + paddr_t start = d->arch.e820[i].addr; + paddr_t end = d->arch.e820[i].addr + d->arch.e820[i].size; + + if ( start <= kernel_start && + end >= kernel_end && + d->arch.e820[i].type == E820_RAM ) + return true; + } + + return false; +} + +/* + * Find an e820 RAM region that fits the kernel at a suitable alignment. + */ +static paddr_t find_kernel_memory( + const struct domain *d, struct elf_binary *elf, paddr_t align) +{ + paddr_t kernel_start = (paddr_t)elf->dest_base & PAGE_MASK; + paddr_t kernel_end = ROUNDUP((paddr_t)elf->dest_base + elf->dest_size, + PAGE_SIZE); + unsigned int i; + + /* + * The memory map is sorted and all RAM regions starts and sizes are + * aligned to page boundaries. + */ + for ( i = 0; i < d->arch.nr_e820; i++ ) + { + paddr_t start = d->arch.e820[i].addr; + paddr_t end = d->arch.e820[i].addr + d->arch.e820[i].size; + paddr_t kstart, kend, offset; + + if ( d->arch.e820[i].type != E820_RAM ) + continue; + + if ( d->arch.e820[i].size < elf->dest_size ) + continue; + + if ( end < kernel_end ) + continue; + + kstart = ROUNDUP(start, align); + offset = kstart - kernel_start; + kend = kernel_end + offset; + + if ( kend <= end ) + return offset; + } + + return 0; +} + +/* + * Check the kernel load address, and adjust if necessary and possible. + */ +static bool __init adjust_load_address( + const struct domain *d, struct elf_binary *elf, struct elf_dom_parms *parms, + paddr_t align) +{ + paddr_t offset; + + /* Check load address */ + if ( check_load_address(d, elf) ) + return true; + + if ( !test_bit(XENFEAT_pvh_relocatable, parms->f_supported) ) + { + printk("Address conflict and %pd kernel is not relocatable\n", d); + return false; + } + + if ( align == 0 ) + align = MB(2); + + offset = find_kernel_memory(d, elf, align); + if ( offset == 0 ) + { + printk("Failed find a load offset for the kernel\n"); + return false; + } + + printk("Adjusting load address by %#lx\n", offset); + elf->dest_base += offset; + parms->phys_entry += offset; + + return true; +} + static int __init pvh_load_kernel(struct domain *d, const module_t *image, unsigned long image_headroom, module_t *initrd, void *image_base, @@ -587,6 +690,12 @@ static int __init pvh_load_kernel(struct domain *d, const module_t *image, elf.dest_base = (void *)(parms.virt_kstart - parms.virt_base); elf.dest_size = parms.virt_kend - parms.virt_kstart; + if ( !adjust_load_address(d, &elf, &parms, align) ) + { + printk("Unable to load kernel\n"); + return -ENOMEM; + } + elf_set_vcpu(&elf, v); rc = elf_load_binary(&elf); if ( rc < 0 ) diff --git a/xen/include/public/features.h b/xen/include/public/features.h index 4437f25d25..300480cb22 100644 --- a/xen/include/public/features.h +++ b/xen/include/public/features.h @@ -120,6 +120,11 @@ #define XENFEAT_runstate_phys_area 18 #define XENFEAT_vcpu_time_phys_area 19 +/* + * PVH: If set, the guest supports relocation in load address. + */ +#define XENFEAT_pvh_relocatable 20 + #define XENFEAT_NR_SUBMAPS 1 #endif /* __XEN_PUBLIC_FEATURES_H__ */ -- 2.44.0 From xen-devel-bounces@lists.xenproject.org Wed Mar 06 18:51:40 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 18:51:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689478.1074512 (Exim 4.92) (envelope-from ) id 1rhwMd-0001WR-OM; Wed, 06 Mar 2024 18:51:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689478.1074512; Wed, 06 Mar 2024 18:51:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhwMd-0001WI-LQ; Wed, 06 Mar 2024 18:51:39 +0000 Received: by outflank-mailman (input) for mailman id 689478; Wed, 06 Mar 2024 18:51:38 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhwMc-0007k1-6U for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 18:51:38 +0000 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on20605.outbound.protection.outlook.com [2a01:111:f400:7e88::605]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 8f09cd48-dbea-11ee-a1ee-f123f15fe8a2; Wed, 06 Mar 2024 19:51:36 +0100 (CET) Received: from MN0PR12MB6101.namprd12.prod.outlook.com (2603:10b6:208:3cb::10) by DS7PR12MB6216.namprd12.prod.outlook.com (2603:10b6:8:94::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.24; Wed, 6 Mar 2024 18:51:30 +0000 Received: from MN0PR12MB6101.namprd12.prod.outlook.com ([fe80::dcf1:946c:3879:5765]) by MN0PR12MB6101.namprd12.prod.outlook.com ([fe80::dcf1:946c:3879:5765%4]) with mapi id 15.20.7339.035; Wed, 6 Mar 2024 18:51:30 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8f09cd48-dbea-11ee-a1ee-f123f15fe8a2 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=D+y7TdmXNxBluEQEIVpgetIXXewbJNh+/VaSrdg2F6mhOGzvkvmXTiAuhOXl0eJlFFlWNwW50ZZ7QL/Il3WvNZi2/nMqcgo7lj5tU+zgNp0sPLYFoqz+VjSEZdsyXh7ZnYLv8XlbUeNtIDp4hU5Uh0pf4l1WeNBULqy3mWLuwFPeZPQ9SpSeVj3AbxQHGWj7uzioF2C3n3KC2Qo/GSb0squdHDURfsoYpqtzR46kvvZC0AJmAyv2a6thT3Cyd3oXdNuZNlTbimA2VOAoJ16nseojLYS7Jz7WCfiClCoSkthR01DM2gFdFk02HyHcHDIUxRl+4lcGOP7vrtZVCU2vkA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=njBIOzkPXzMFuv63yYQen7tK22va6bbzgMd3rSifM58=; b=kQxWnok/YXbUtLREMMbKbsErJt+U9QTQk6r57e4QAfyIJdZAL+t4SrX0/Tn4yhcPRFoc+hvRJPa+ed3y4XMNTb6mJ0Js+ijH1lRCCOHIO2DsgH+Dh7sXqvUskU6HNF5SwskV0WYSjhb7n1HlQS19CfpcTupOwnj4k9+AWnnpqtUOEY4NYFEPabCx/4YvmxTrQZMR5/r8lbNt0bkaTJrhSTyzuacNcQlv3absakr13EluhQC/JJSQp+qL5ofMwtuvEsei4YxNQPkIJBkQ54VKaZ83TGzJ2FTpdiONaorNbvPPQfKlUaXB0AbRYcGWKMPMdtnGrGsyb76NyolsZO/XmQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=njBIOzkPXzMFuv63yYQen7tK22va6bbzgMd3rSifM58=; b=mECtXOdOoVlr3XLksvSqT0Xi0X69mUxigSrJ9xn0FpIVER3Vs20tyTnq8UPfU3dxqJz5IlQgHVNC492pUAXDUstojOnWJjh65U/Fd1YtOH6Udto+10vYa305FgHLh7Hc54HgqAAKL6Et8xM3KqrSzvIPetQAkDGFF6bYe6IMGPc= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; Message-ID: <7c2f9983-a0b5-41f7-81cb-f196787f3dfb@amd.com> Date: Wed, 6 Mar 2024 12:51:28 -0600 User-Agent: Mozilla Thunderbird Subject: Re: [BUG]i2c_hid_acpi broken with 4.17.2 on Framework Laptop 13 AMD Content-Language: en-US To: =?UTF-8?Q?S=C3=A9bastien_Chaumat?= Cc: xen-devel@lists.xenproject.org, Jan Beulich , Juergen Gross , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= References: <77c1c05d-a0a0-4292-9257-9b7fbebee0e3@suse.com> <2859ad22-8714-4628-8142-fc77fc2072c3@amd.com> <214585d5-689d-4ba6-bd48-359428a7ed8f@amd.com> <19852f4d-fbeb-4314-a2cb-ab3f05da13ba@amd.com> From: Mario Limonciello In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: SA9PR03CA0028.namprd03.prod.outlook.com (2603:10b6:806:20::33) To MN0PR12MB6101.namprd12.prod.outlook.com (2603:10b6:208:3cb::10) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MN0PR12MB6101:EE_|DS7PR12MB6216:EE_ X-MS-Office365-Filtering-Correlation-Id: 60f1788e-f486-4727-a15a-08dc3e0e6fa4 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: TrhbM8zNiwCEN4aKk6yAiZm8qb991xjuTp9A0NUQpvcsDXDdT1oK7xj8mkD4YMIjCgi9R/Kdf/K/2pw8R6AFOnCOTfkztDToT03kJQqHjhElZkTied2u/bN0KJ9UxmnoRyUsfagAu6JiabkeE/AqFk5KKv3/gsbcBM17J3rsAbh0nTp4EK7rRI8c2NkVDQg0IZJPhtrPn/PjDZzfUOr9tozWVvhGccqWQLjVo9L7ONyP8JnV5RO1Wz2O7/0GLophTUdoeiBbB5VQsaFgl39+PzlAI7SVM/asz8RCGynyuLcqQ1ECpMXGPIBDGSNDT0aT0kT1XZz5hql+ovOauGPpguRo6yzPi/D9wWTk21DTvgPbbgNDgIO0mMxR2Cscl7rakDkPU7qhY3AQRrfb1BFJaYmPDT7T/ZTEyHN5BjE6/7mQe4V3E+R7onsg+G807BLRjSgvYJWJBobnQ3cePnHC4qzXy26z0G6mLnSoqxS9Y1RAKukZHvtefcMFvX+DfPPY6L/F677WmzhAEYn6NMOcKWgtJH7eMN40leKTDjl9AymkL3j9Q93GzWNsDtvO5Nt/S2VeRRrUfrZ92X0AdkvPdMX+m8oKJbRGiO6Uoc0D6Ro= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MN0PR12MB6101.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(376005);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?L2RkcHJQNk1JVzh2R3JwSGV2Y2dRcFFuVlN3TlI4NmhOaHRqMHFxTzVMd2J6?= =?utf-8?B?WFI0RXl3MGRpRjQ4dmdJNmxid0hMU1hRdUdISHA2RWE1SzZPQllvNXJtTUV3?= =?utf-8?B?QXJuN0o5bWhCMTUwK0IzYVhvcnNVM1NmVlNxZHZ0bHlvTW5pSG9vY1J6RTNF?= =?utf-8?B?QWM0SVVRQzNmU2U0UVpKWWkzRGNESWRCcWg0dGNaK2UwaVhzSGxrNzhoaEh5?= =?utf-8?B?eFlIUEVneU1sQzNKYzlTNWJYUUFYeElsMnVuYW14L1ROZTJvSlFHbXFiLzZQ?= =?utf-8?B?MklPZlhwRHFEUjFBR2xQM214YzNKUCs5cjA5Szc1eGQyOHhhNVY1aGtJdDFE?= =?utf-8?B?SmdGbnRTWDdqU2dyNzQ3ZUUvWDFNMzFvWTMvY20rSkM2eHNuc09yQkZTdEJ1?= =?utf-8?B?d0ZFUVdSd25FSDVTQWZrbldBYk5BWTQ3d3hMSVoxeDdQOFVua3ducXBwcmt5?= =?utf-8?B?a3owa3dGRHVvRlJDSlRHdlNGOUgyRzhCKzFLSWdSOVRpQTlGcEpSL3dTbzc3?= =?utf-8?B?WDNJRlZQckNnT0xXOVZCc0EyY0dYWHhMYWtlRVhtNldVc1U3MjN5WWVNdTBT?= =?utf-8?B?c0IrQjk2UWhiRVZlUCtxbXRYUG0yYk4xNTE1VzUvdkVNN0VXa2FHY3ZjOWUv?= =?utf-8?B?TVpxbnp0Z2hkczN4c212UnVKWkhWODd2Vy95OXFjVEZMOHJLKzRONUZtS0ky?= =?utf-8?B?NTB6d1gxcVlCS3NJeEZyRXg3aFk0WW5Da1lObk1PcVozamptODhRMHNFbzk0?= =?utf-8?B?RnR5Q2UrT0VVMDd4Q003aEhXYUFETzR4dEI2dS9ybWN3L2wyUXYzWGRiK2l5?= =?utf-8?B?NG9vc1BiWkphTktyckpaYktZWmE5clFjdXJSakNxUHVxVi96WnZCNU5NcFdz?= =?utf-8?B?OU1TcWZBVGkwclNsRE9SMnhoclZ5VnRSOEJWMnJGR2tTa1lxbkx6UDBBVHhB?= =?utf-8?B?V3ZvMzN2c3dENGV2OWhjalB2MnV3MlVEQjVYTmI5cW9sN3N2ellyN2YrdHVt?= =?utf-8?B?UlNSVS9ZYjMxWW16S3h6cFhWLzFMSDlVa0pzaGxQMmZvQzBQVG12ODN5cHly?= =?utf-8?B?ZHNidXFleWQ4U0Y0MC83QkVZd1RzL3d5QUM0Vy9NUmNKakNoYytYM3hIYkFy?= =?utf-8?B?YTFVNTZxeGROTkszYUx4ZExmRGlnY2xKdmtyaDczeDIwQnhOcmtDelcxbVpz?= =?utf-8?B?bitMSi95M2tKMnJCN3MzRmFpWmRCUVd6WlA2b2lnNHNyM0J3UmF5ZkhSR0RD?= =?utf-8?B?N240OEJuRW52UGtrOENnWFJUckptbHZuRGh4ZEpnQjVKcHV6YWQ4SVc2UXov?= =?utf-8?B?SG9TVkhXOHBWdHg1eWllYm96dXFtQUJLMkl0U1IyM1hJMDNJOXRYenFObU1K?= =?utf-8?B?djdwREFDM2NjSkJQYi9vQUpFc28zNlpLcFpxa0lzYlNYSk9kazR4SzNyaU94?= =?utf-8?B?WVg1REhRcUo5SmJEKzBDYVdWMEh3cmdYK2FqeGtreE1DZUx2OEJDRS9CTzEx?= =?utf-8?B?bk1jaVJhRjVsOEhYRTNmbHQ4My9seTUrbEdldTMxYlp0ZllTcVdNVnZJOUJj?= =?utf-8?B?ZzBFdDFNYWRtdmpheU5lazV3VXZFTEFNZXVJOWF3UkpGSS9SMlJjVCsyY2Fy?= =?utf-8?B?UURsRnJCTnNLTTRpN2RqY096OG9jNXpZSm5BeldZQnhnRGlhRDh6cVJyOWRU?= =?utf-8?B?VjluR0JBSFNMN0FaNmM1VlFnSXBlL1NHRVlVdk9oZmxpYjhGVG1ZRnRsaFhl?= =?utf-8?B?Vm80a0NLWFZsYVFPV3UveXBFZlpWU1pHZUY2QzUvWGhwWXJqT1VHaDM0Z2RQ?= =?utf-8?B?dmJtZkRaRmtKcXBBUGRhT2RzNDQxM3B0dHc2NjdYZmdsRUplcm0wVXp4aDls?= =?utf-8?B?ODVIbmp6eEowNkJQRTVFZGU2ZWZKRFdvQnpoM25zK3pxOFFKRWNCYlVKS09y?= =?utf-8?B?L3c3SHY1TXpYVEo2N2d1d20vWDZFVldoV2VBL1l1WE83WERBTVVmdVo0Zmlu?= =?utf-8?B?RThZZ3JhTDEvanBMM0FSUVN1aUZ1TlR3bjF6UXVvakZnUGN2NGhubTgwU2c5?= =?utf-8?B?VmhLenFNUFVXSjRLNGExOEpuaDAzbTkrZ3A3TUFLWVZNS2pLM1dCRlo0UWJG?= =?utf-8?Q?zprIoms8h88DZ4kofShA2K5lU?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 60f1788e-f486-4727-a15a-08dc3e0e6fa4 X-MS-Exchange-CrossTenant-AuthSource: MN0PR12MB6101.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Mar 2024 18:51:30.4695 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: ThBeWc4A1RayvVvBSdjWommayPUPM81uHANUE7pNiqJiohEnOUEyK9Q57gmb5PzpbwFF8pjhKDpLsJ2NlC6+6g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR12MB6216 On 3/6/2024 12:49, Sébastien Chaumat wrote: > > > Le mer. 6 mars 2024 à 19:08, Mario Limonciello > > a écrit : > > On 3/6/2024 12:05, Sébastien Chaumat wrote: > > > > > > Le mer. 6 mars 2024 à 18:33, Mario Limonciello > > > >> a écrit : > > > >     On 3/6/2024 11:28, Sébastien Chaumat wrote: > >      > > >      > > >      > > >      > > >      >     Reasoning backward  (using a  kernel without the > pinctrl_amd > >     driver > >      >     to ensure xen only is at stake) : > >      >       checking the diff in IOAPIC  between bare metal and xen > >     (IRQ7 is > >      >     on pin07 on APIC ) > >      > > >      >     using kernel argument : apic=debug > >      > > >      >     bare metal : > >      >     [    0.715330] fedora kernel: ... APIC VERSION: 81050010 > >      >     ... > >      >     [    0.715433] fedora kernel:  pin07, disabled, edge , > high, > >     V(00), > >      >     IRR(0), S(0), physical, D(0000), M(0) > >      > > >      >     xen : > >      >     [    2.249582] fedora kernel: ... APIC VERSION: 00000014 > >      >     ... > >      >     [    2.249730] fedora kernel:  pin07, disabled, level, > low , > >     V(60), > >      >     IRR(0), S(0), physical, D(0000), M(0) > >      > > >      >     So the APIC table is not the same. > >      > > >      >     As strange as it looks the  (IOAPIC 0) pin07 is correctly > >     described > >      >     by the APIC in xen but yet differently than in baremetal. > >      >     But the APIC message comes long after the > >      >     [    1.833145] fedora kernel: xen: registering gsi 7 > triggering 0 > >      >     polarity 1 > >      > > >      >     so I wonder if the APIC pin07 info had any influence. > >      > > >      > Finally found the fix : adding ioapic_ack=new to xen boot > parameters. > >      > Not only the trackpad is now working but also the ACPI > Embedded > >      > Controller which is completely disabled. > >      > > >      > Sébastien > >      > > >     That's great news!  I'm personally totally unfamiliar with > >     ioapic_ack=new, so I did a quick search and found out it's a Xen > >     parameter (I came across > > > https://xenbits.xen.org/docs/4.5-testing/misc/xen-command-line.html > > > >  >). > > > >     This mentions that "new" should be the default, so why isn't > it the > >     case? > > > > > >   "This is the the default unless directed-EOI is supported" > > xl dmesg without forcing the parameters shows : > > > > (XEN) Enabled directed EOI with ioapic_ack_old on! > > Got it; it sounds to me like a logic mismatch in Xen then. > > > > >     Also; I'd be really interested to hear what happens with > s2idle with > >     Xen > >     now (if it works). > > > > > > suspend to RAM now works :) > > Do you see /sys/power/suspend_stats/last_hw_sleep increasing with your > suspend cycle? > > > No,  it does not increase (0). > OK, then in that case I suggest you run https://gitlab.freedesktop.org/drm/amd/-/blob/master/scripts/amd_s2idle.py in the hypervisor to find out what's wrong. From xen-devel-bounces@lists.xenproject.org Wed Mar 06 19:32:24 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 19:32:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689493.1074522 (Exim 4.92) (envelope-from ) id 1rhwzp-00022G-Pt; Wed, 06 Mar 2024 19:32:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689493.1074522; Wed, 06 Mar 2024 19:32:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhwzp-000229-NH; Wed, 06 Mar 2024 19:32:09 +0000 Received: by outflank-mailman (input) for mailman id 689493; Wed, 06 Mar 2024 19:32:08 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhwzo-000221-57 for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 19:32:08 +0000 Received: from NAM02-BN1-obe.outbound.protection.outlook.com (mail-bn1nam02on20601.outbound.protection.outlook.com [2a01:111:f403:2407::601]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 367deeb3-dbf0-11ee-afda-a90da7624cb6; Wed, 06 Mar 2024 20:32:05 +0100 (CET) Received: from BYAPR01CA0009.prod.exchangelabs.com (2603:10b6:a02:80::22) by BY5PR12MB4274.namprd12.prod.outlook.com (2603:10b6:a03:206::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7339.39; Wed, 6 Mar 2024 19:32:02 +0000 Received: from SJ5PEPF000001CE.namprd05.prod.outlook.com (2603:10b6:a02:80:cafe::30) by BYAPR01CA0009.outlook.office365.com (2603:10b6:a02:80::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7339.38 via Frontend Transport; Wed, 6 Mar 2024 19:32:02 +0000 Received: from SATLEXMB03.amd.com (165.204.84.17) by SJ5PEPF000001CE.mail.protection.outlook.com (10.167.242.38) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7362.11 via Frontend Transport; Wed, 6 Mar 2024 19:32:01 +0000 Received: from SATLEXMB08.amd.com (10.181.40.132) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Wed, 6 Mar 2024 13:32:01 -0600 Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB08.amd.com (10.181.40.132) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Wed, 6 Mar 2024 11:32:00 -0800 Received: from fedora.mshome.net (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend Transport; Wed, 6 Mar 2024 13:32:00 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 367deeb3-dbf0-11ee-afda-a90da7624cb6 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZvKevZAJPNu3YrFrW/fz35Xx7DHkt+Z2RW0N58akXOdH6loFNxpF28dTWM0nXKDLL6fWz4y15kjQS2cesjHfmf9raIHpimR8Acdg6rMrWlgvM4XqTu549DuN/go0xASPsvXKnjOteScQn65Tg70MnCuPwGtl4S+kDI3aX4kMH5ovZbsLGAqvKw0phN5f6pH8UhkoQE1rB/NLEvFjR3/7N9nUamvgsiHHrHrHRRcTLyJdFtKkabV3zVbYfBr+/wzXKAj6Qcgo5TzdMbBwLmmbPr7q1VHTT3nTkP3wBUEI5n5En1R5oGT09kENS+yxSJfnUA9qEL12RkTWRinaUT+BjQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=s8ONsRt7COxj9gZV6Ct67FmT23zTc3WUV1SKIWOuv+Y=; b=kVT+fdiryFiyf7zkN11H/X6uKxZHgp5++xi6pP3jzG9R0dKqnbvztlS17zNkZRGcZ7aEao/aUH5b1r3wOkbtt2+6YaTvnKmR2aqrDL2zSwHj4uEXaSK1lGgHSaRRKKdFBBbrp/uLmaeXqdtkxwiKYbqabNxi1Fo90KVWrzW2SKKYMbZBIkYYHlNXmD3+amuW+poWVzfWuEKEkRB4qO6ISMTYwhqP8oiMDNmVYHf22cGxvt/zziv186zffwX02HFOtVgS632ViekUESdUJYyzbI34JK1Y8jv0wL45nx8vw+C5Kqv4CdSHOQAp9puizl9zHmZW2zvAJj5ZPd4WcFcAOQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=s8ONsRt7COxj9gZV6Ct67FmT23zTc3WUV1SKIWOuv+Y=; b=SzF5u2BxbFkCXqt05Kj5KHJmav1d2SxQ0tu2+onA/rdK7busQiIKU8cWjsPFy9KWfEgkTPcWvjJ4eVGL5H7SfaK3BiVq9Qyl5VB08X9gx2H97bYZUeZdpnoks6DfdkRq9bYRol/uwmQK0JIVXomFke9b3USsQ9RcYzXMxGhxYuU= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C From: Jason Andryuk To: CC: Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Andrew Cooper , "Juergen Gross" , Boris Ostrovsky , Jason Andryuk Subject: [LINUX PATCH] RFC: x86/pvh: Make Xen PVH entrypoint PIC Date: Wed, 6 Mar 2024 14:31:58 -0500 Message-ID: <20240306193158.104680-1-jason.andryuk@amd.com> X-Mailer: git-send-email 2.44.0 In-Reply-To: <20240306185032.103216-1-jason.andryuk@amd.com> References: <20240306185032.103216-1-jason.andryuk@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ5PEPF000001CE:EE_|BY5PR12MB4274:EE_ X-MS-Office365-Filtering-Correlation-Id: 5993f048-c7e8-40e8-d7bf-08dc3e141902 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: FWmQyTuW0iZT2iCWgeHDRMzbwoyiAP/Fs+lYpTBKidLoQ09FoyCsKhhM6hTNsrGaY5jofoG55do43s6Z3FZvi2jaiU98ZVnSLgUYfEmC5GzFkcfb6Yc0g9cRRNFjkGc9XgvTJvbai0l5BEuastDZg3FOYODhRu4sma49K9wOeXX6rLQWVwNneWstLY5LKXMryuGmTExUDNumbiLxqz3np/5auBk8Tv8cTwjUZbZgXADR/uV/epN7xTz2IjRLjogP6xoRGBbCyYC+QAniEym7Q5RyWGafBIm0wfafook2LRViiaQKEaq0/XVu1bCs2TtXtbia357q6ISZM/ZcfDp4cfYAWUfe+9uZpl2wE7pyxIQwacoKqIw4Uu0PQS19lwB+eEzc6EBQBlULDmb4cOLI9+ntDs72ekjOEZ9Ft8/wi75sba/Jj6lb+gck74U5X6NFWSER/xUaGPjbaRUPxywP64RooL27GiqtvM5Iyac2rZ79UHVV18Z5oTCaMuKqVgiKTc/O68Eqgsti2+7Ndle/fgezSzSWjZ8hU6IQsgmwjbixKjSgtwVIFyoJGuBOiDDwODUoW0lrxphHtXFXNxSWewYS23hozM9fDHtbgxDztIf2NloYTAJdEsCY0hTDXnVJwAhD7GITnuUTi9ziv/hS6+3k4ecaJ8vfZphvPNDfqRo+bSrkDil7pG41VnTFs8SmigsjEar5cmTeTlgPLyNpB6mbh5+NE+pqm5gYZPaIqNJzLUaYTRm5ZVJwPA700mVU X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(376005)(36860700004)(82310400014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Mar 2024 19:32:01.8246 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 5993f048-c7e8-40e8-d7bf-08dc3e141902 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SJ5PEPF000001CE.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR12MB4274 The Xen PVH entrypoint is 32bit non-PIC code running at a default load address of 0x1000000 (16MB) (CONFIG_PHYSICAL_START). Xen loads the kernel at that physical address inside the PVH container. When running a PVH Dom0, the system reserved addresses are mapped 1-1 into the PVH container. There exist system firmwares (Coreboot/EDK2) with reserved memory at 16MB. This creates a conflict where the PVH kernel cannot be loaded at that address. Modify the PVH entrypoint to be position-indepedent to allow flexibility in load address. Initial PVH entry runs at the physical addresses and then transitions to the identity mapped address. While executing xen_prepare_pvh() calls through pv_ops function pointers transition to the high mapped addresses. Additionally, __va() is called on some hvm_start_info physical addresses, we need the directmap address range is used. So we need to run page tables with all of those ranges mapped. Modifying init_top_pgt tables ran into issue since startup_64/__startup_64() will modify those page tables again. Use a dedicated set of page tables - pvh_init_top_pgt - for the PVH entry to avoid unwanted interactions. In xen_pvh_init(), __pa() is called to find the physical address of the hypercall page. Set phys_base temporarily before calling into xen_prepare_pvh(), which calls xen_pvh_init(), and clear it afterwards. __startup_64() assumes phys_base is zero and adds load_delta to it. If phys_base is already set, the calculation results in an incorrect cr3. TODO: The 32bit entry path needs additional work to have relocatable pagetables. TODO: Sync features.h from xen.git commit xxxxxxxxxx when it is commited. Signed-off-by: Jason Andryuk --- Put this out as an example for the Xen modifications. Will split for actual submission. Instead of setting and clearing phys_base, add a dedicated variable? Make __startup_64() exit if phys_base is already set to allow calling multiple times, and use that and init_top_pgt instead of adding additional page tables? --- arch/x86/platform/pvh/head.S | 195 ++++++++++++++++++++++++++++--- arch/x86/xen/xen-head.S | 7 +- include/xen/interface/features.h | 5 + 3 files changed, 190 insertions(+), 17 deletions(-) diff --git a/arch/x86/platform/pvh/head.S b/arch/x86/platform/pvh/head.S index f7235ef87bc3..bab857db55ef 100644 --- a/arch/x86/platform/pvh/head.S +++ b/arch/x86/platform/pvh/head.S @@ -50,11 +50,32 @@ #define PVH_CS_SEL (PVH_GDT_ENTRY_CS * 8) #define PVH_DS_SEL (PVH_GDT_ENTRY_DS * 8) +#define rva(x) ((x) - pvh_start_xen) + SYM_CODE_START_LOCAL(pvh_start_xen) UNWIND_HINT_END_OF_STACK cld - lgdt (_pa(gdt)) + /* + * See the comment for startup_32 for more details. We need to + * execute a call to get the execution address to be position + * independent, but we don't have a stack. Save and restore the + * magic field of start_info in ebx, and use that as the stack. + */ + mov (%ebx), %eax + leal 4(%ebx), %esp + ANNOTATE_INTRA_FUNCTION_CALL + call 1f +1: popl %ebp + mov %eax, (%ebx) + subl $ rva(1b), %ebp + movl $0, %esp + + leal rva(gdt)(%ebp), %eax + movl %eax, %ecx + leal rva(gdt_start)(%ebp), %ecx + movl %ecx, 2(%eax) + lgdt (%eax) mov $PVH_DS_SEL,%eax mov %eax,%ds @@ -62,14 +83,14 @@ SYM_CODE_START_LOCAL(pvh_start_xen) mov %eax,%ss /* Stash hvm_start_info. */ - mov $_pa(pvh_start_info), %edi + leal rva(pvh_start_info)(%ebp), %edi mov %ebx, %esi - mov _pa(pvh_start_info_sz), %ecx + movl rva(pvh_start_info_sz)(%ebp), %ecx shr $2,%ecx rep movsl - mov $_pa(early_stack_end), %esp + leal rva(early_stack_end)(%ebp), %esp /* Enable PAE mode. */ mov %cr4, %eax @@ -83,29 +104,83 @@ SYM_CODE_START_LOCAL(pvh_start_xen) btsl $_EFER_LME, %eax wrmsr + mov %ebp, %ebx + subl $LOAD_PHYSICAL_ADDR, %ebx /* offset */ + jz .Lpagetable_done + + /* Fixup page-tables for relocation. */ + leal rva(pvh_init_top_pgt)(%ebp), %edi + movl $512, %ecx +2: + movl 0x00(%edi), %eax + addl 0x04(%edi), %eax + jz 1f + addl %ebx, 0x00(%edi) +1: + addl $8, %edi + decl %ecx + jnz 2b + + /* L3 ident has a single entry. */ + leal rva(pvh_level3_ident_pgt)(%ebp), %edi + addl %ebx, 0x00(%edi) + + leal rva(pvh_level3_kernel_pgt)(%ebp), %edi + addl %ebx, (4096 - 16)(%edi) + addl %ebx, (4096 - 8)(%edi) + + /* pvh_level2_ident_pgt is fine - large pages */ + + /* pvh_level2_kernel_pgt needs adjustment - large pages */ + leal rva(pvh_level2_kernel_pgt)(%ebp), %edi + movl $512, %ecx +2: + movl 0x00(%edi), %eax + addl 0x04(%edi), %eax + jz 1f + addl %ebx, 0x00(%edi) +1: + addl $8, %edi + decl %ecx + jnz 2b + +.Lpagetable_done: /* Enable pre-constructed page tables. */ - mov $_pa(init_top_pgt), %eax + leal rva(pvh_init_top_pgt)(%ebp), %eax mov %eax, %cr3 mov $(X86_CR0_PG | X86_CR0_PE), %eax mov %eax, %cr0 /* Jump to 64-bit mode. */ - ljmp $PVH_CS_SEL, $_pa(1f) + pushl $PVH_CS_SEL + leal rva(1f)(%ebp), %eax + pushl %eax + lretl /* 64-bit entry point. */ .code64 1: /* Set base address in stack canary descriptor. */ mov $MSR_GS_BASE,%ecx - mov $_pa(canary), %eax + leal rva(canary)(%ebp), %eax xor %edx, %edx wrmsr + /* Calculate load offset from LOAD_PHYSICAL_ADDR and store in + * phys_base. __pa() needs phys_base set to calculate the the + * hypercall page in xen_pvh_init(). */ + movq %rbp, %rbx + subq $LOAD_PHYSICAL_ADDR, %rbx + movq %rbx, phys_base(%rip) call xen_prepare_pvh + /* Clear phys_base. startup_64/__startup_64 will *add* to its value, + so start from 0. */ + xor %rbx, %rbx + movq %rbx, phys_base(%rip) /* startup_64 expects boot_params in %rsi. */ - mov $_pa(pvh_bootparams), %rsi - mov $_pa(startup_64), %rax + lea rva(pvh_bootparams)(%ebp), %rsi + lea rva(startup_64)(%ebp), %rax ANNOTATE_RETPOLINE_SAFE jmp *%rax @@ -113,20 +188,27 @@ SYM_CODE_START_LOCAL(pvh_start_xen) call mk_early_pgtbl_32 - mov $_pa(initial_page_table), %eax + leal rva(initial_page_table)(%ebp), %eax mov %eax, %cr3 mov %cr0, %eax or $(X86_CR0_PG | X86_CR0_PE), %eax mov %eax, %cr0 - ljmp $PVH_CS_SEL, $1f + pushl $PVH_CS_SEL + leal rva(1f)(%ebp), %eax + pushl %eax + lretl + 1: call xen_prepare_pvh - mov $_pa(pvh_bootparams), %esi + leal rva(pvh_bootparams)(%ebp), %esi /* startup_32 doesn't expect paging and PAE to be on. */ - ljmp $PVH_CS_SEL, $_pa(2f) + pushl $PVH_CS_SEL + leal rva(2f)(%ebp), %eax + pushl %eax + lretl 2: mov %cr0, %eax and $~X86_CR0_PG, %eax @@ -135,15 +217,19 @@ SYM_CODE_START_LOCAL(pvh_start_xen) and $~X86_CR4_PAE, %eax mov %eax, %cr4 - ljmp $PVH_CS_SEL, $_pa(startup_32) + pushl $PVH_CS_SEL + leal rva(startup_32)(%ebp), %eax + pushl %eax + lretl #endif + SYM_CODE_END(pvh_start_xen) .section ".init.data","aw" .balign 8 SYM_DATA_START_LOCAL(gdt) - .word gdt_end - gdt_start - .long _pa(gdt_start) + .word gdt_end - gdt_start - 1 + .long 0 .word 0 SYM_DATA_END(gdt) SYM_DATA_START_LOCAL(gdt_start) @@ -163,5 +249,82 @@ SYM_DATA_START_LOCAL(early_stack) .fill BOOT_STACK_SIZE, 1, 0 SYM_DATA_END_LABEL(early_stack, SYM_L_LOCAL, early_stack_end) +/* + * We are not able to switch in one step to the final KERNEL ADDRESS SPACE + * because we need identity-mapped pages. + */ +#define l4_index(x) (((x) >> 39) & 511) +#define pud_index(x) (((x) >> PUD_SHIFT) & (PTRS_PER_PUD-1)) + +L4_PAGE_OFFSET = l4_index(__PAGE_OFFSET_BASE_L4) +L4_START_KERNEL = l4_index(__START_KERNEL_map) +L3_START_KERNEL = pud_index(__START_KERNEL_map) + +#define SYM_DATA_START_PAGE_ALIGNED(name) \ + SYM_START(name, SYM_L_GLOBAL, .balign PAGE_SIZE) + +/* Automate the creation of 1 to 1 mapping pmd entries */ +#define PMDS(START, PERM, COUNT) \ + i = 0 ; \ + .rept (COUNT) ; \ + .quad (START) + (i << PMD_SHIFT) + (PERM) ; \ + i = i + 1 ; \ + .endr + +/* + * Xen PVH needs a set of identity mapped and kernel high mapping + * page tables. pvh_start_xen starts running on the identity mapped + * page tables, but xen_prepare_pvh calls into the high mapping. + * These page tables are need to be relocatable and are only used until + * startup_64 transitions to init_top_pgt. + */ +SYM_DATA_START_PAGE_ALIGNED(pvh_init_top_pgt) + .quad pvh_level3_ident_pgt - __START_KERNEL_map + _KERNPG_TABLE_NOENC + .org pvh_init_top_pgt + L4_PAGE_OFFSET*8, 0 + .quad pvh_level3_ident_pgt - __START_KERNEL_map + _KERNPG_TABLE_NOENC + .org pvh_init_top_pgt + L4_START_KERNEL*8, 0 + /* (2^48-(2*1024*1024*1024))/(2^39) = 511 */ + .quad pvh_level3_kernel_pgt - __START_KERNEL_map + _PAGE_TABLE_NOENC +SYM_DATA_END(pvh_init_top_pgt) + +SYM_DATA_START_PAGE_ALIGNED(pvh_level3_ident_pgt) + .quad pvh_level2_ident_pgt - __START_KERNEL_map + _KERNPG_TABLE_NOENC + .fill 511, 8, 0 +SYM_DATA_END(pvh_level3_ident_pgt) +SYM_DATA_START_PAGE_ALIGNED(pvh_level2_ident_pgt) + /* + * Since I easily can, map the first 1G. + * Don't set NX because code runs from these pages. + * + * Note: This sets _PAGE_GLOBAL despite whether + * the CPU supports it or it is enabled. But, + * the CPU should ignore the bit. + */ + PMDS(0, __PAGE_KERNEL_IDENT_LARGE_EXEC, PTRS_PER_PMD) +SYM_DATA_END(pvh_level2_ident_pgt) +SYM_DATA_START_PAGE_ALIGNED(pvh_level3_kernel_pgt) + .fill L3_START_KERNEL,8,0 + /* (2^48-(2*1024*1024*1024)-((2^39)*511))/(2^30) = 510 */ + .quad pvh_level2_kernel_pgt - __START_KERNEL_map + _KERNPG_TABLE_NOENC + .quad 0 /* no fixmap */ +SYM_DATA_END(pvh_level3_kernel_pgt) + +SYM_DATA_START_PAGE_ALIGNED(pvh_level2_kernel_pgt) + /* + * Kernel high mapping. + * + * The kernel code+data+bss must be located below KERNEL_IMAGE_SIZE in + * virtual address space, which is 1 GiB if RANDOMIZE_BASE is enabled, + * 512 MiB otherwise. + * + * (NOTE: after that starts the module area, see MODULES_VADDR.) + * + * This table is eventually used by the kernel during normal runtime. + * Care must be taken to clear out undesired bits later, like _PAGE_RW + * or _PAGE_GLOBAL in some cases. + */ + PMDS(0, __PAGE_KERNEL_LARGE_EXEC, KERNEL_IMAGE_SIZE/PMD_SIZE) +SYM_DATA_END(pvh_level2_kernel_pgt) + ELFNOTE(Xen, XEN_ELFNOTE_PHYS32_ENTRY, _ASM_PTR (pvh_start_xen - __START_KERNEL_map)) diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S index a0ea285878db..e6994aaa8cc3 100644 --- a/arch/x86/xen/xen-head.S +++ b/arch/x86/xen/xen-head.S @@ -106,7 +106,12 @@ SYM_CODE_END(xen_cpu_bringup_again) # define FEATURES_PV 0 #endif #ifdef CONFIG_XEN_PVH -# define FEATURES_PVH (1 << XENFEAT_linux_rsdp_unrestricted) +# ifdef CONFIG_RELOCATABLE +# define FEATURES_PVH (1 << XENFEAT_linux_rsdp_unrestricted) | \ + (1 << XENFEAT_pvh_relocatable) +# else +# define FEATURES_PVH (1 << XENFEAT_linux_rsdp_unrestricted) +# endif #else # define FEATURES_PVH 0 #endif diff --git a/include/xen/interface/features.h b/include/xen/interface/features.h index 53f760378e39..92e7da9194c8 100644 --- a/include/xen/interface/features.h +++ b/include/xen/interface/features.h @@ -97,6 +97,11 @@ #define XENFEAT_not_direct_mapped 16 #define XENFEAT_direct_mapped 17 +/* + * PVH: If set, the guest supports being relocated in physical memory on entry. + */ +#define XENFEAT_pvh_relocatable 20 + #define XENFEAT_NR_SUBMAPS 1 #endif /* __XEN_PUBLIC_FEATURES_H__ */ -- 2.44.0 g From xen-devel-bounces@lists.xenproject.org Wed Mar 06 20:35:12 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 20:35:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689499.1074532 (Exim 4.92) (envelope-from ) id 1rhxyc-000422-8s; Wed, 06 Mar 2024 20:34:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689499.1074532; Wed, 06 Mar 2024 20:34:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhxyc-00041v-5d; Wed, 06 Mar 2024 20:34:58 +0000 Received: by outflank-mailman (input) for mailman id 689499; Wed, 06 Mar 2024 20:34:57 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhxyb-00041p-43 for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 20:34:57 +0000 Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [2607:f8b0:4864:20::102c]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id fc38a249-dbf8-11ee-a1ee-f123f15fe8a2; Wed, 06 Mar 2024 21:34:53 +0100 (CET) Received: by mail-pj1-x102c.google.com with SMTP id 98e67ed59e1d1-29b54503280so36346a91.1 for ; Wed, 06 Mar 2024 12:34:53 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fc38a249-dbf8-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709757292; x=1710362092; darn=lists.xenproject.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=2iCcJDiXsrXLE5cm6A+U9C8Mjw8UURfFAF9EyamTU9c=; b=Pa1FN3QbMNh1HZFINv40+lChTSrNaJXwk3poaKZYI93LELGiowDx8utHqhAX9YFGOu HRcT4KKnsrt6zwnZuy/3J2urpBgj5+b+hTgFWaBzp36JBdkttm/DMtWkf1ZIX7r81cT0 P3sSFCa2mEEiM/EeU5q6M6lKdPAc3G3ZuvphjxvUeJXY8AinLcA/VMuacciWt+pDkRqi J+v94325TyDeQr1RrnmETLeVywJ1RZ4UEz7fLMqB1bQ+CAQ/5W7A406sIGVlO+jOMofj X3UqyEqMoimZh4Lit8YskYWW1BwXTLNHxmQeiaEvc59vJfscOFrg8+rURNuvELyeBIo6 xkjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709757292; x=1710362092; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=2iCcJDiXsrXLE5cm6A+U9C8Mjw8UURfFAF9EyamTU9c=; b=D0lCvTPSIcrpguAGPp/21zND4PvJVEOvwcQrcoFJG5HUIRim+hFmrzSgdWueZRsYLG P0qJVdeOk6vwFKvwQVZBXEQLAJk0C5hYat4orNnA2aSBK+DBVRipIM2sW6eeK6PR7U7G e05bwmcG08dYyWkHpP1j4YsynrosrCSH/Kmrgn6weHJQHzt7UOSYrmhZt9SnuxJIFfTH XPZMIQwhLWidjoiH9A5cg+rJ37OiH5XSCLrXHtdIn6yg0nedOzqKZiP0sJU3Qk4f/w6F Vo+GqnzdvHoDW1eI4Dn2fOeQaYDewVjtfaMGNJeKj6nI/OOkBSbqIUqdXJaWJsiFDwwx b+cg== X-Gm-Message-State: AOJu0YwdndUFwgCfzrDGpzLCnLEClj1J8Bg9cLuF88Vwsxsow4uo69kg lx8E0P6OnTZq15jDMgEZ1c+ZxB7VNltFSGMW/qb4eu799Mhqq+ZhizF8T1JMCNgpncf434A/gBD 4gLJMQRn/i8dJZi/bOlG6ad5yRrM= X-Google-Smtp-Source: AGHT+IHjwLPsBA0scIZW1/LBL/Cif2agDptM5ki6+rfUdN5ydTW1OohSiPS4JBDRBhM+B5vAiHeqCg5Dkk0MFcHorHg= X-Received: by 2002:a17:90a:1c02:b0:29b:277d:2590 with SMTP id s2-20020a17090a1c0200b0029b277d2590mr16639198pjs.34.1709757291648; Wed, 06 Mar 2024 12:34:51 -0800 (PST) MIME-Version: 1.0 References: <77c1c05d-a0a0-4292-9257-9b7fbebee0e3@suse.com> <2859ad22-8714-4628-8142-fc77fc2072c3@amd.com> <214585d5-689d-4ba6-bd48-359428a7ed8f@amd.com> <19852f4d-fbeb-4314-a2cb-ab3f05da13ba@amd.com> <7c2f9983-a0b5-41f7-81cb-f196787f3dfb@amd.com> In-Reply-To: <7c2f9983-a0b5-41f7-81cb-f196787f3dfb@amd.com> From: =?UTF-8?Q?S=C3=A9bastien_Chaumat?= Date: Wed, 6 Mar 2024 21:34:39 +0100 Message-ID: Subject: Re: [BUG]i2c_hid_acpi broken with 4.17.2 on Framework Laptop 13 AMD To: Mario Limonciello Cc: xen-devel@lists.xenproject.org, Jan Beulich , Juergen Gross , =?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= Content-Type: multipart/alternative; boundary="000000000000055d1e061303e448" --000000000000055d1e061303e448 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Le mer. 6 mars 2024 =C3=A0 19:51, Mario Limonciello a =C3=A9crit : > On 3/6/2024 12:49, S=C3=A9bastien Chaumat wrote: > > > > > > Le mer. 6 mars 2024 =C3=A0 19:08, Mario Limonciello > > > a =C3=A9= crit : > > > > On 3/6/2024 12:05, S=C3=A9bastien Chaumat wrote: > > > > > > > > > Le mer. 6 mars 2024 =C3=A0 18:33, Mario Limonciello > > > > > > >> a =C3=A9crit : > > > > > > On 3/6/2024 11:28, S=C3=A9bastien Chaumat wrote: > > > > > > > > > > > > > > > > > > > > Reasoning backward (using a kernel without the > > pinctrl_amd > > > driver > > > > to ensure xen only is at stake) : > > > > checking the diff in IOAPIC between bare metal and > xen > > > (IRQ7 is > > > > on pin07 on APIC ) > > > > > > > > using kernel argument : apic=3Ddebug > > > > > > > > bare metal : > > > > [ 0.715330] fedora kernel: ... APIC VERSION: > 81050010 > > > > ... > > > > [ 0.715433] fedora kernel: pin07, disabled, edge = , > > high, > > > V(00), > > > > IRR(0), S(0), physical, D(0000), M(0) > > > > > > > > xen : > > > > [ 2.249582] fedora kernel: ... APIC VERSION: > 00000014 > > > > ... > > > > [ 2.249730] fedora kernel: pin07, disabled, level= , > > low , > > > V(60), > > > > IRR(0), S(0), physical, D(0000), M(0) > > > > > > > > So the APIC table is not the same. > > > > > > > > As strange as it looks the (IOAPIC 0) pin07 is > correctly > > > described > > > > by the APIC in xen but yet differently than in > baremetal. > > > > But the APIC message comes long after the > > > > [ 1.833145] fedora kernel: xen: registering gsi 7 > > triggering 0 > > > > polarity 1 > > > > > > > > so I wonder if the APIC pin07 info had any influence. > > > > > > > > Finally found the fix : adding ioapic_ack=3Dnew to xen bo= ot > > parameters. > > > > Not only the trackpad is now working but also the ACPI > > Embedded > > > > Controller which is completely disabled. > > > > > > > > S=C3=A9bastien > > > > > > > That's great news! I'm personally totally unfamiliar with > > > ioapic_ack=3Dnew, so I did a quick search and found out it's= a > Xen > > > parameter (I came across > > > > > https://xenbits.xen.org/docs/4.5-testing/misc/xen-command-line.html > > > > > > > > < > https://xenbits.xen.org/docs/4.5-testing/misc/xen-command-line.html < > https://xenbits.xen.org/docs/4.5-testing/misc/xen-command-line.html>>). > > > > > > This mentions that "new" should be the default, so why isn't > > it the > > > case? > > > > > > > > > "This is the the default unless directed-EOI is supported" > > > xl dmesg without forcing the parameters shows : > > > > > > (XEN) Enabled directed EOI with ioapic_ack_old on! > > > > Got it; it sounds to me like a logic mismatch in Xen then. > > > > > > > > Also; I'd be really interested to hear what happens with > > s2idle with > > > Xen > > > now (if it works). > > > > > > > > > suspend to RAM now works :) > > > > Do you see /sys/power/suspend_stats/last_hw_sleep increasing with > your > > suspend cycle? > > > > > > No, it does not increase (0). > > > > OK, then in that case I suggest you run > https://gitlab.freedesktop.org/drm/amd/-/blob/master/scripts/amd_s2idle.p= y > in the hypervisor to find out what's wrong. > > It fails with xen (not bare metal) during the prerequisite tests : =E2=9C=85 GPIO driver `pinctrl_amd` available Traceback (most recent call last): File "/home/sch/Downloads/amd_s2idle.py", line 2447, in test =3D app.prerequisites() ^^^^^^^^^^^^^^^^^^^ File "/home/sch/Downloads/amd_s2idle.py", line 1938, in prerequisites if not check(): ^^^^^^^ File "/home/sch/Downloads/amd_s2idle.py", line 826, in check_msr val =3D read_msr(reg, 0) ^^^^^^^^^^^^^^^^ File "/home/sch/Downloads/amd_s2idle.py", line 813, in read_msr val =3D struct.unpack("Q", os.read(f, 8))[0] ^^^^^^^^^^^^^ OSError: [Errno 5] Input/output error Last line in the log is : 2024-03-06 21:29:33,146 DEBUG: Lockdown: [none] integrity confidentiality --000000000000055d1e061303e448 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
Le=C2=A0mer. 6 mars 2024 =C3=A0=C2=A0= 19:51, Mario Limonciello <m= ario.limonciello@amd.com> a =C3=A9crit=C2=A0:
On 3/6/2024 12:49, S=C3=A9bastien Chau= mat wrote:
>
>
> Le=C2=A0mer. 6 mars 2024 =C3=A0=C2=A019:08, Mario Limonciello
> <mar= io.limonciello@amd.com <mailto:mario.limonciello@amd.com>> a =C3=A9cri= t=C2=A0:
>
>=C2=A0 =C2=A0 =C2=A0On 3/6/2024 12:05, S=C3=A9bastien Chaumat wrote: >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Le=C2=A0mer. 6 mars 2024 =C3=A0=C2=A018:33, M= ario Limonciello
>=C2=A0 =C2=A0 =C2=A0 > <mario.limonciello@amd.com <mailto:mario.limonciello@amd.co= m>
>=C2=A0 =C2=A0 =C2=A0<mailto:mario.limonciello@amd.com
>=C2=A0 =C2=A0 =C2=A0<mailto:mario.limonciello@amd.com>>> a =C3=A9cr= it=C2=A0:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0On 3/6/2024 11:28, S=C3=A9= bastien Chaumat wrote:
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0R= easoning backward=C2=A0 (using a=C2=A0 kernel without the
>=C2=A0 =C2=A0 =C2=A0pinctrl_amd
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0driver
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0t= o ensure xen only is at stake) :
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0checking the diff in IOAPIC=C2=A0 between bare metal and xen
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0(IRQ7 is
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0o= n pin07 on APIC )
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0u= sing kernel argument : apic=3Ddebug
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0b= are metal :
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0[= =C2=A0 =C2=A00.715330] fedora kernel: ... APIC VERSION: 81050010
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0.= ..
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0[= =C2=A0 =C2=A00.715433] fedora kernel: =C2=A0pin07, disabled, edge ,
>=C2=A0 =C2=A0 =C2=A0high,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0V(00),
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0I= RR(0), S(0), physical, D(0000), M(0)
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0x= en :
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0[= =C2=A0 =C2=A02.249582] fedora kernel: ... APIC VERSION: 00000014
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0.= ..
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0[= =C2=A0 =C2=A02.249730] fedora kernel: =C2=A0pin07, disabled, level,
>=C2=A0 =C2=A0 =C2=A0low ,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0V(60),
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0I= RR(0), S(0), physical, D(0000), M(0)
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0S= o the APIC table is not the same.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0A= s strange as it looks the=C2=A0 (IOAPIC 0) pin07 is correctly
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0described
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0b= y the APIC in xen but yet differently than in baremetal.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0B= ut the APIC message comes long after the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0[= =C2=A0 =C2=A01.833145] fedora kernel: xen: registering gsi 7
>=C2=A0 =C2=A0 =C2=A0triggering 0
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0p= olarity 1
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0s= o I wonder if the APIC pin07 info had any influence.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Finally found the fi= x : adding ioapic_ack=3Dnew to xen boot
>=C2=A0 =C2=A0 =C2=A0parameters.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Not only the trackpa= d is now working but also the ACPI
>=C2=A0 =C2=A0 =C2=A0Embedded
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Controller which is = completely disabled.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > S=C3=A9bastien
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0That's great news!=C2= =A0 I'm personally totally unfamiliar with
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0ioapic_ack=3Dnew, so I did= a quick search and found out it's a Xen
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0parameter (I came across >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0https://x= enbits.xen.org/docs/4.5-testing/misc/xen-command-line.html
>=C2=A0 =C2=A0 =C2=A0<https= ://xenbits.xen.org/docs/4.5-testing/misc/xen-command-line.html>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<https://xenbits.xen.org/docs/4.5-testing/misc/xen-command-line.html &= lt;https://xenbits.xen.org/docs/4= .5-testing/misc/xen-command-line.html>>).
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0This mentions that "n= ew" should be the default, so why isn't
>=C2=A0 =C2=A0 =C2=A0it the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0case?
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0"This is the the default unl= ess directed-EOI is supported"
>=C2=A0 =C2=A0 =C2=A0 > xl dmesg without forcing the parameters shows= :
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > (XEN) Enabled directed EOI with ioapic_ack_ol= d on!
>
>=C2=A0 =C2=A0 =C2=A0Got it; it sounds to me like a logic mismatch in Xe= n then.
>
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Also; I'd be really in= terested to hear what happens with
>=C2=A0 =C2=A0 =C2=A0s2idle with
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Xen
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0now (if it works).
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > suspend to RAM now works :)
>
>=C2=A0 =C2=A0 =C2=A0Do you see /sys/power/suspend_stats/last_hw_sleep i= ncreasing with your
>=C2=A0 =C2=A0 =C2=A0suspend cycle?
>
>
> No,=C2=A0 it does not increase (0).
>

OK, then in that case I suggest you run
https://gitlab.freedesktop= .org/drm/amd/-/blob/master/scripts/amd_s2idle.py
in the hypervisor to find out what's wrong.


It fails with xen (not bare metal) dur= ing the prerequisite tests :

=E2=9C=85 GPIO driver= `pinctrl_amd` available
Traceback (most recent call last):
=C2=A0 Fi= le "/home/sch/Downloads/amd_s2idle.py", line 2447, in <module&= gt;
=C2=A0 =C2=A0 test =3D app.prerequisites()
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0^^^^^^^^^^^^^^^^^^^
=C2=A0 File "/home/sch/Down= loads/amd_s2idle.py", line 1938, in prerequisites
=C2=A0 =C2=A0 if = not check():
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^^^^^^^
=C2=A0 = File "/home/sch/Downloads/amd_s2idle.py", line 826, in check_msr<= br>=C2=A0 =C2=A0 val =3D read_msr(reg, 0)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 ^^^^^^^^^^^^^^^^
=C2=A0 File "/home/sch/Downloads/amd_s2idle= .py", line 813, in read_msr
=C2=A0 =C2=A0 val =3D struct.unpack(&qu= ot;Q", os.read(f, 8))[0]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^^^^^^^^^^^^^=
OSError: [Errno 5] Input/output error

Last lin= e in the log is :
2024-03-06 21:29:33,146 DEBUG: Lockdown: [none]= integrity confidentiality

--000000000000055d1e061303e448-- From xen-devel-bounces@lists.xenproject.org Wed Mar 06 20:37:31 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 20:37:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689502.1074542 (Exim 4.92) (envelope-from ) id 1rhy13-0004Yl-NO; Wed, 06 Mar 2024 20:37:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689502.1074542; Wed, 06 Mar 2024 20:37:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhy13-0004Ye-K6; Wed, 06 Mar 2024 20:37:29 +0000 Received: by outflank-mailman (input) for mailman id 689502; Wed, 06 Mar 2024 20:37:28 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhy12-0004YY-Ct for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 20:37:28 +0000 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on20601.outbound.protection.outlook.com [2a01:111:f403:200a::601]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 57146142-dbf9-11ee-afda-a90da7624cb6; Wed, 06 Mar 2024 21:37:26 +0100 (CET) Received: from MN0PR12MB6101.namprd12.prod.outlook.com (2603:10b6:208:3cb::10) by DM6PR12MB4483.namprd12.prod.outlook.com (2603:10b6:5:2a2::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.24; Wed, 6 Mar 2024 20:37:21 +0000 Received: from MN0PR12MB6101.namprd12.prod.outlook.com ([fe80::dcf1:946c:3879:5765]) by MN0PR12MB6101.namprd12.prod.outlook.com ([fe80::dcf1:946c:3879:5765%4]) with mapi id 15.20.7339.035; Wed, 6 Mar 2024 20:37:21 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 57146142-dbf9-11ee-afda-a90da7624cb6 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JldIa/XzVoPqhGq1WrB/tnPheYs082TKLi4yl6LbLqf8cTYL/H2GtCBMhvWVzpbRuzDO22poFpPZ4WosvpFj+TSKhX9he3IMNew3UuhT66yseEq76LZt7Dp1Mc53LVmGMlXZAiAoGtH9gnaBB7brUvIbXx0B/eXhj+KLViCDFBA8kGnNN2ubjEiaEgnIdBXXVXe4xb4QNRk+Hb5LJWHULE/TdWJawebpyCga0EKde1zWA/QP709cntvqnOwI+LiI5gSX/RdmPjZ20ax3MAD7c7hQR/osnqdoh3t5aYhDSvnQo89xBX44qQdwIcx7NPMl6zZGYmOJhVQJAeSDePI1+Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=dWGdSP4rjHWo36FDooJJkETdC+jecOAAOvhQ960wGgk=; b=VxHD+duBm28GSe/DUyge6BQhbDny7FX0v8eHXz2RjweyTCDl3wtqdm48/WFnwkXo/quGuYd2BtLrmq9DUMqBiFfoovdqRAsJgejTjuYfhXAXTKdPw0EcZXS1cf8zSr7SzdocBDunORkEX4uVb/RVRKO9GbWmi4wK6ouoQZLEdp9IWkgSyD3Rw5XOnMeyjLLJlskbDSN9oPn/ZrZl5oCYNRG2x5H7SPLFYiN4YQmXXoVy2TgEDQOQxV/t+sKw6w8ApMq+k73N8IbUXU8QEHV/C2jzKVwbq5YPfJVOtKV582WR1RSFIvo8+H7ObxYzPzuiGnJ987Lvjollu0zPNFJ9jA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dWGdSP4rjHWo36FDooJJkETdC+jecOAAOvhQ960wGgk=; b=pfdL701ta8UBcG5Y6CS2nF15vsjwWqsKA3guhKTxCx5vb7KtlJPrvNOn2iz5hq/iiwByHTp0t6S3cJrw5F3YY2yiTqGljJKoGcYcw/37PLCskxcqcFGFr+X4fjtDiEj7HC9GronC78BfJnk7MH489nhRHamYfar/xdEZCLnLRNw= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; Message-ID: <2a609713-3eec-438e-80af-c1dfcfe598c4@amd.com> Date: Wed, 6 Mar 2024 14:37:20 -0600 User-Agent: Mozilla Thunderbird Subject: Re: [BUG]i2c_hid_acpi broken with 4.17.2 on Framework Laptop 13 AMD Content-Language: en-US To: =?UTF-8?Q?S=C3=A9bastien_Chaumat?= Cc: xen-devel@lists.xenproject.org, Jan Beulich , Juergen Gross , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= References: <77c1c05d-a0a0-4292-9257-9b7fbebee0e3@suse.com> <2859ad22-8714-4628-8142-fc77fc2072c3@amd.com> <214585d5-689d-4ba6-bd48-359428a7ed8f@amd.com> <19852f4d-fbeb-4314-a2cb-ab3f05da13ba@amd.com> <7c2f9983-a0b5-41f7-81cb-f196787f3dfb@amd.com> From: Mario Limonciello In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: DM6PR03CA0080.namprd03.prod.outlook.com (2603:10b6:5:333::13) To MN0PR12MB6101.namprd12.prod.outlook.com (2603:10b6:208:3cb::10) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MN0PR12MB6101:EE_|DM6PR12MB4483:EE_ X-MS-Office365-Filtering-Correlation-Id: 32fe51ad-db51-4805-43bd-08dc3e1d3958 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: ya9bAHIVmb0HOVMmeAaEyBnVf/EWgwP3D0t0PnFqN42hf8vyDRPQjvcnraloWOC4KO8aY95A9G505qN3dDA+c0eB+MTMuYrqMawyuv5py8oKqnpY+KngvzlGGcbqAdDi0gWsPX8nc7dJzkdNlwBh6heHndo7PMNQ0MQz4MRyz14TerVdTnmwEdmNLuEzjkyykXynBNxVoW+6AEwfGkHJX51/AFGFbZDUs5lX9GL+GTKhtic5nqR6U19rC2Iq6rCoHJgaPudCRXC8Ag6KW9k2XYeid6Zcqe49RzE7/0j5KMOarnzTuH8Dt1eZJIGRai8/N/LRmNuIPI5k9JKoAIeDUWnOceTKUZ6jeGuNROFNhwe/DfbljktzmMwa1HLxQSM25BdsyOfTJotVKqIREQUBthn7CWyiulw77Xbild1wBqlGgOYNhoPJwe5FXrJQsyx9t3Jm7zENzy5r22LDcnWx610FQ3Y6H3SvhLsr/UH16iR/iZHDXxmv0El7WjIE1kWkabtGL0hB3kAWofyk0aYG97j9FidUR6+z87uPoN4aCTeCpqXTns/3XL0njbykSzHMzJqxWnHH5BBmOcxTvzi6JWKciLJrvAKgesjOFoIZ9fk= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MN0PR12MB6101.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(376005);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?QU52dWRXNDd3OWJscUhLeWt3SmZGM1FsTm1nMkNHcVJmdjcybitibzV2SHps?= =?utf-8?B?bURpVzhJWmc0VEFZYjRPMkRvdDZSd3pzVFFFVEd6RzBGTzhKc2gxSlpTTGRk?= =?utf-8?B?UmtuWGk4cFJtTzhpcStYR2tDV2t3SWQrYlRpbEhoUlNyem9UU1JNUjVrZWxQ?= =?utf-8?B?bHVCeXlVWnJZeGR3K1ZndUdadmF0b1FnNWg2c0VRVU9BNzNUa09ySjQ2NWZz?= =?utf-8?B?S05HM1B4YzNJd2NzWUxpQ1VlZ3I3cjNzcWNpWXdQSnB6OGxWVFYwYlNpb1VG?= =?utf-8?B?VThaYkJmTXhtQSs0dzZFQzlkZEdjMHdsUUhNdHAvR1dnbWQ2Y2VwenBXRlI5?= =?utf-8?B?aWpQWENmVzJhQ2pPak5CMGVzbjFWb0tmeDRzUzN6Ny9SQnF0T1FyQnpqT3Rz?= =?utf-8?B?dytDR2hZRHJMcFJ1clF1aDlkRmF3dmp3TlhTMHF6ODdaSTRWMVcyMXQ2T2FR?= =?utf-8?B?YitWRFo5T2c0MUtpUDVMbkQvV0V2NjFDdjd0YzdIeXlSV1g5b3ZrU3BVOUdy?= =?utf-8?B?ZVRrQmtIZ0pBZmd1USs1YXpjQUUyYXhrN203ZWVZaDJ2ZytCckdxaHpxSGdV?= =?utf-8?B?NllQZmZNdGlkSjVCSUdaQVpxTFJaT3lVWEZTR3NuR0dyZmJKN05kZmp4N1hX?= =?utf-8?B?NmI3MGZpMkZQL3FNOU9HSHlMRWxXYWNnbTFCSitIVFcxTFppR3c0TERyMTZz?= =?utf-8?B?TllSYlF0TStFcWxyckg2VFo2bDFKVU9GNExOOUlqMHN5c1RRRWdFY1hmcnRv?= =?utf-8?B?RkFYcnQ0ZUU4QiszT0xsMkJmL3dWdjFhSk13Y0duRWJWSVh5NWNiQm9wMkxH?= =?utf-8?B?dWZadzEzaGREUWhqKzdPN0lsUWpTdGZONzBNVGpmT0txcE9iVlo3dHJRVkhX?= =?utf-8?B?eE9kbFNYeDI3cDdFeEpYTENrd1NBUVdjQzNPZ3J1Wi9xWWNUY0ZCWEcwOHhm?= =?utf-8?B?Y1FHMlhoWDF1R3dRQVdsNzVzdW5PeERoVjlhZytCamdxMi9WWEw1ZEtkSXhk?= =?utf-8?B?cDVVaFhocThMUWtId21JZUhhUkJ6c0p1OEZ6MVRPTnRCc3A3SndIWjZrSFVa?= =?utf-8?B?QTIrSmFoS254ZTU3QkE2NVA2eFBtMFJaUHVMVFpRUGw3S1Fla3NLdmp1c0Rm?= =?utf-8?B?MEZqaFVJcU9BTHNiUlZtRmdOYmVaYkp2UmNTWjB6enRZZVEzcU5UMGY0WjRO?= =?utf-8?B?Q0lLOGpEVUpaUHMwVVpLTWNyUzRudVdwa3hzVEU0WTlJcW9tYWxaMmZiN2RZ?= =?utf-8?B?NXlZS0o1WWE0Z2RuVXM4cE9neGN6OEs3MEFtTlJZMEdxbnZTcDNrOGt6Rmpw?= =?utf-8?B?clFZRDhqRlBaYVFkdG1rRURUK3pBSGVpL21IaXNDRWwwOHN2aHFLLy9PQjZP?= =?utf-8?B?dWtJb0VBRUszU2ZrOUx3dnRVWWFyenY4UlVFWm92Vmk2bUJWbTFHMW80Qzg1?= =?utf-8?B?NkZvaU5CYW8wQXBUc0Y1ZkR5a3dwQmRZTjJJcFM1VW96YVFBOU0xWm5HdURS?= =?utf-8?B?WHJVb2JVZlJnTTlIekJqVzRSMUVTcStqdGRJYmI5Q0JvM3VaUkFTd3U3S3N1?= =?utf-8?B?MXIzNWVNOTNsdy96enBTUTF0WTBQaUZBZ3lxV2czenIza0dicE1vbkZiTElB?= =?utf-8?B?Ukk0RmtxQzlzbG0xaUYzVEtZQ1JNbEN6TXd6UUd6bjFqbVhqQVoydWE1MG9U?= =?utf-8?B?dkEyNXhWK3M3K2M1MDhQSnVJcUlXY2dPK0FNS0QxaWdJSUVVc1Q1bmM0anRp?= =?utf-8?B?L0VxRGVGYkdLLzJKNTFNays5QWRkR0JJZGhsaE45cEFsU2dqYkRaUHRnUGxt?= =?utf-8?B?WGJnTEpkMkNSejB6OUFrMTFFVy9ZUkxjM1dRZEo4WDAxVzFwdVNqR2hueVBr?= =?utf-8?B?SGY3T0trVk1rcExQT0owbTd1S2xkQklEa2I3MlJNdWxadytsWTZBZG9RWXlq?= =?utf-8?B?L3RmaU00QkNnYzF1OVd6L0RVOHN0SEZjK2JsSTVveVlSWnRLamp4cWNFQVhm?= =?utf-8?B?eE5XYi93eDB2WHhKVW95VGw2ckJWOXpIR2VOTmtDZzJhRTA1dEpIb0ZCTFBN?= =?utf-8?B?OGtBSkZ0ZDMvcEduTmY4eXVTWnJmem1KL1UvVk9HZi8yd0lUWDhEVWN3NVVw?= =?utf-8?Q?N5LiAo/YyBDcDt5qvyIZm6rug?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 32fe51ad-db51-4805-43bd-08dc3e1d3958 X-MS-Exchange-CrossTenant-AuthSource: MN0PR12MB6101.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Mar 2024 20:37:21.8405 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: vwICybCBgzjZzPZQM2Vb6XPGh7t3o07WCQA+nqkCZWu3cCBAheJY+Aq/Y4DS56CQHDhyrOHtyNHPkPx0eWHkcg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4483 On 3/6/2024 14:34, Sébastien Chaumat wrote: > > > Le mer. 6 mars 2024 à 19:51, Mario Limonciello > > a écrit : > > On 3/6/2024 12:49, Sébastien Chaumat wrote: > > > > > > Le mer. 6 mars 2024 à 19:08, Mario Limonciello > > > >> a écrit : > > > >     On 3/6/2024 12:05, Sébastien Chaumat wrote: > >      > > >      > > >      > Le mer. 6 mars 2024 à 18:33, Mario Limonciello > >      > > > >      > >      >>> a écrit : > >      > > >      >     On 3/6/2024 11:28, Sébastien Chaumat wrote: > >      >      > > >      >      > > >      >      > > >      >      > > >      >      >     Reasoning backward  (using a  kernel without the > >     pinctrl_amd > >      >     driver > >      >      >     to ensure xen only is at stake) : > >      >      >       checking the diff in IOAPIC  between bare > metal and xen > >      >     (IRQ7 is > >      >      >     on pin07 on APIC ) > >      >      > > >      >      >     using kernel argument : apic=debug > >      >      > > >      >      >     bare metal : > >      >      >     [    0.715330] fedora kernel: ... APIC VERSION: > 81050010 > >      >      >     ... > >      >      >     [    0.715433] fedora kernel:  pin07, disabled, > edge , > >     high, > >      >     V(00), > >      >      >     IRR(0), S(0), physical, D(0000), M(0) > >      >      > > >      >      >     xen : > >      >      >     [    2.249582] fedora kernel: ... APIC VERSION: > 00000014 > >      >      >     ... > >      >      >     [    2.249730] fedora kernel:  pin07, disabled, > level, > >     low , > >      >     V(60), > >      >      >     IRR(0), S(0), physical, D(0000), M(0) > >      >      > > >      >      >     So the APIC table is not the same. > >      >      > > >      >      >     As strange as it looks the  (IOAPIC 0) pin07 is > correctly > >      >     described > >      >      >     by the APIC in xen but yet differently than in > baremetal. > >      >      >     But the APIC message comes long after the > >      >      >     [    1.833145] fedora kernel: xen: registering > gsi 7 > >     triggering 0 > >      >      >     polarity 1 > >      >      > > >      >      >     so I wonder if the APIC pin07 info had any > influence. > >      >      > > >      >      > Finally found the fix : adding ioapic_ack=new to > xen boot > >     parameters. > >      >      > Not only the trackpad is now working but also the ACPI > >     Embedded > >      >      > Controller which is completely disabled. > >      >      > > >      >      > Sébastien > >      >      > > >      >     That's great news!  I'm personally totally unfamiliar with > >      >     ioapic_ack=new, so I did a quick search and found out > it's a Xen > >      >     parameter (I came across > >      > > > > https://xenbits.xen.org/docs/4.5-testing/misc/xen-command-line.html > > > >  > > >      > > > >   >>). > >      > > >      >     This mentions that "new" should be the default, so why > isn't > >     it the > >      >     case? > >      > > >      > > >      >   "This is the the default unless directed-EOI is supported" > >      > xl dmesg without forcing the parameters shows : > >      > > >      > (XEN) Enabled directed EOI with ioapic_ack_old on! > > > >     Got it; it sounds to me like a logic mismatch in Xen then. > > > >      > > >      >     Also; I'd be really interested to hear what happens with > >     s2idle with > >      >     Xen > >      >     now (if it works). > >      > > >      > > >      > suspend to RAM now works :) > > > >     Do you see /sys/power/suspend_stats/last_hw_sleep increasing > with your > >     suspend cycle? > > > > > > No,  it does not increase (0). > > > > OK, then in that case I suggest you run > https://gitlab.freedesktop.org/drm/amd/-/blob/master/scripts/amd_s2idle.py > in the hypervisor to find out what's wrong. > > > It fails with xen (not bare metal) during the prerequisite tests : > The script might need some modifications for tests that don't make sense in the context of Xen. > ✅ GPIO driver `pinctrl_amd` available > Traceback (most recent call last): >   File "/home/sch/Downloads/amd_s2idle.py", line 2447, in >     test = app.prerequisites() >            ^^^^^^^^^^^^^^^^^^^ >   File "/home/sch/Downloads/amd_s2idle.py", line 1938, in prerequisites >     if not check(): >            ^^^^^^^ >   File "/home/sch/Downloads/amd_s2idle.py", line 826, in check_msr >     val = read_msr(reg, 0) >           ^^^^^^^^^^^^^^^^ >   File "/home/sch/Downloads/amd_s2idle.py", line 813, in read_msr >     val = struct.unpack("Q", os.read(f, 8))[0] >                              ^^^^^^^^^^^^^ > OSError: [Errno 5] Input/output error > > Last line in the log is : > 2024-03-06 21:29:33,146 DEBUG: Lockdown: [none] integrity confidentiality > Do you have userspace MSR support compiled in? If not; that could explain that problem. But it's very unlikely you changed the MSRs. For the purpose of finding where the suspend problem is, I'd comment out that specific check for now. From xen-devel-bounces@lists.xenproject.org Wed Mar 06 20:40:27 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 20:40:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689506.1074551 (Exim 4.92) (envelope-from ) id 1rhy3s-0006h4-6z; Wed, 06 Mar 2024 20:40:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689506.1074551; Wed, 06 Mar 2024 20:40:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhy3s-0006gx-49; Wed, 06 Mar 2024 20:40:24 +0000 Received: by outflank-mailman (input) for mailman id 689506; Wed, 06 Mar 2024 20:40:22 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhy3q-0006go-Be for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 20:40:22 +0000 Received: from mail.zytor.com (unknown [2607:7c80:54:3::138]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id bea9c604-dbf9-11ee-afda-a90da7624cb6; Wed, 06 Mar 2024 21:40:20 +0100 (CET) Received: from [127.0.0.1] ([76.133.66.138]) (authenticated bits=0) by mail.zytor.com (8.17.2/8.17.1) with ESMTPSA id 426KdmEp1568117 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 6 Mar 2024 12:39:48 -0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: bea9c604-dbf9-11ee-afda-a90da7624cb6 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 426KdmEp1568117 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2024021201; t=1709757590; bh=T+TFJC5MWmKywYtHsaL1+tz57km/tmqpnjzR2/q4Iy8=; h=Date:From:To:CC:Subject:In-Reply-To:References:From; b=IF22+C//PAdzoFM8/VC1KFqG86Yd4ozJyBLsozfUBX6dL48f4gjVLkL49nu+pfrmS tdDItHryquTqMaCAnNDb/lfU4fdOih7nPD1rscZBjqobxd5R4klrzAuFw9bfNo5fDo Ga9x/AR6CxYeyZCZkPtK4/TkBldMs5EFH9eOx1StAn5z5qFQmzZZ/4YGyTOtaniCPu v7LydORJLK3MIafxsts6K+MW780pijaPNPoxCGzPhPCnAsJdNN7DEE4zLUuVEzhoYi GMcpIAa3ksyd92zD2RbM7eBLLZWLLNECVhZU0XfErLpuM8uhp1GxVLHMyz8M+JHV2V iYAXCLEh7Kwfg== Date: Wed, 06 Mar 2024 12:39:46 -0800 From: "H. Peter Anvin" To: Xin Li , linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org CC: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, jgross@suse.com, boris.ostrovsky@oracle.com, arnd@arndb.de, andrew.cooper3@citrix.com, brgerst@gmail.com Subject: =?US-ASCII?Q?Re=3A_=5BPATCH_v2_1/1=5D_x86/fred=3A_Fix_init=5Ft?= =?US-ASCII?Q?ask_thread_stack_pointer_initialization?= User-Agent: K-9 Mail for Android In-Reply-To: References: <20240304083333.449322-1-xin@zytor.com> Message-ID: <82259B6F-2F57-4099-869D-84891D996664@zytor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On March 6, 2024 10:28:25 AM PST, Xin Li wrote: >On 3/4/2024 12:33 AM, Xin Li (Intel) wrote: >> As TOP_OF_KERNEL_STACK_PADDING is defined as 0 on x86_64, no one notice= d >> it's missing in the calculation of the =2Esp field in INIT_THREAD until= it >> is defined to 16 with CONFIG_X86_FRED=3Dy=2E >>=20 >> Subtract TOP_OF_KERNEL_STACK_PADDING from the =2Esp field of INIT_THREA= D=2E >>=20 >> Fixes: 65c9cc9e2c14 ("x86/fred: Reserve space for the FRED stack frame"= ) >> Fixes: 3adee777ad0d ("x86/smpboot: Remove initial_stack on 64-bit") >> Reported-by: kernel test robot >> Closes: https://lore=2Ekernel=2Eorg/oe-lkp/202402262159=2E183c2a37-lkp@= intel=2Ecom >> Signed-off-by: Xin Li (Intel) >> --- > >Should this fix, if it looks good, be included for the coming merge >window? > >Thanks! > Xin > >>=20 >> Change Since v1: >> * Apply offset TOP_OF_KERNEL_STACK_PADDING to all uses of __end_init_ta= sk >> (Brian Gerst)=2E >> --- >> arch/x86/include/asm/processor=2Eh | 6 ++++-- >> arch/x86/kernel/head_64=2ES | 3 ++- >> arch/x86/xen/xen-head=2ES | 2 +- >> 3 files changed, 7 insertions(+), 4 deletions(-) >>=20 >> diff --git a/arch/x86/include/asm/processor=2Eh b/arch/x86/include/asm/= processor=2Eh >> index 26620d7642a9=2E=2E17fe81998ce4 100644 >> --- a/arch/x86/include/asm/processor=2Eh >> +++ b/arch/x86/include/asm/processor=2Eh >> @@ -664,8 +664,10 @@ static __always_inline void prefetchw(const void *= x) >> #else >> extern unsigned long __end_init_task[]; >> -#define INIT_THREAD { \ >> - =2Esp =3D (unsigned long)&__end_init_task - sizeof(struct pt_regs), \ >> +#define INIT_THREAD { \ >> + =2Esp =3D (unsigned long)&__end_init_task - \ >> + TOP_OF_KERNEL_STACK_PADDING - \ >> + sizeof(struct pt_regs), \ >> } >> extern unsigned long KSTK_ESP(struct task_struct *task); >> diff --git a/arch/x86/kernel/head_64=2ES b/arch/x86/kernel/head_64=2ES >> index d4918d03efb4=2E=2Ec38e43589046 100644 >> --- a/arch/x86/kernel/head_64=2ES >> +++ b/arch/x86/kernel/head_64=2ES >> @@ -26,6 +26,7 @@ >> #include >> #include >> #include >> +#include >> /* >> * We are not able to switch in one step to the final KERNEL ADDRESS = SPACE >> @@ -66,7 +67,7 @@ SYM_CODE_START_NOALIGN(startup_64) >> mov %rsi, %r15 >> /* Set up the stack for verify_cpu() */ >> - leaq (__end_init_task - PTREGS_SIZE)(%rip), %rsp >> + leaq (__end_init_task - TOP_OF_KERNEL_STACK_PADDING - PTREGS_SIZE)(%r= ip), %rsp >> leaq _text(%rip), %rdi >> diff --git a/arch/x86/xen/xen-head=2ES b/arch/x86/xen/xen-head=2ES >> index a0ea285878db=2E=2E04101b984f24 100644 >> --- a/arch/x86/xen/xen-head=2ES >> +++ b/arch/x86/xen/xen-head=2ES >> @@ -49,7 +49,7 @@ SYM_CODE_START(startup_xen) >> ANNOTATE_NOENDBR >> cld >> - leaq (__end_init_task - PTREGS_SIZE)(%rip), %rsp >> + leaq (__end_init_task - TOP_OF_KERNEL_STACK_PADDING - PTREGS_SIZE)(%r= ip), %rsp >> /* Set up %gs=2E >> * >>=20 >> base-commit: e13841907b8fda0ae0ce1ec03684665f578416a8 > Absolutely=2E From xen-devel-bounces@lists.xenproject.org Wed Mar 06 20:42:11 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 20:42:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689510.1074562 (Exim 4.92) (envelope-from ) id 1rhy5a-0007DW-HP; Wed, 06 Mar 2024 20:42:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689510.1074562; Wed, 06 Mar 2024 20:42:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhy5a-0007DP-EC; Wed, 06 Mar 2024 20:42:10 +0000 Received: by outflank-mailman (input) for mailman id 689510; Wed, 06 Mar 2024 20:42:09 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhy5Z-0007DH-52 for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 20:42:09 +0000 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id feb9a33e-dbf9-11ee-afda-a90da7624cb6; Wed, 06 Mar 2024 21:42:08 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 93561CE18AA; Wed, 6 Mar 2024 20:42:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C7652C433C7; Wed, 6 Mar 2024 20:41:59 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: feb9a33e-dbf9-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1709757720; bh=F87rbMZnTbKfZEsOfR1PaoKgqSD8a33z5RdmXGnAvSk=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=BOXZkDmhAYut609VFoMHNENrQALFu2sz/6zEPx9Tb0DiwVDcYAqXURgXxj9vxciom wNTE2oBiosQWWi3JDmJk9aRfhaodBZOqBgg+M4LfDmn8PrlEu/aYjWO7e/q3J1gIUA 2a9QZVvAwuJFYBvJykttMuWKWikBfEnciMyDnenkmMn9PDHSueeeDVDRxvFRtso4XN oGFw1zKE+CErJQ1FgnkxrbGCP4adNYTYGwGqL72UpvTdP3TZYhBa4ftrih3X5G8/R3 OM3jvHvZhgx8Tamv2kMwov60lKvwlMHRDsn0jqiMLvGwQiGGxIlSyVpm1zJkm5taVc /xFwPP1NJCHkQ== Date: Wed, 6 Mar 2024 12:41:58 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Jason Andryuk cc: xen-devel@lists.xenproject.org, Andrew Cooper , George Dunlap , Jan Beulich , Julien Grall , Stefano Stabellini , Wei Liu Subject: Re: [PATCH 1/3] features.h: Replace hard tabs In-Reply-To: <20240306185032.103216-2-jason.andryuk@amd.com> Message-ID: References: <20240306185032.103216-1-jason.andryuk@amd.com> <20240306185032.103216-2-jason.andryuk@amd.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Wed, 6 Mar 2024, Jason Andryuk wrote: > Replace hard tabs to match the rest of the file. > > Fixes: 48a3fd1432 ("domain: expose newly introduced hypercalls as XENFEAT") > Signed-off-by: Jason Andryuk Reviewed-by: Stefano Stabellini From xen-devel-bounces@lists.xenproject.org Wed Mar 06 21:04:43 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 21:04:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689516.1074571 (Exim 4.92) (envelope-from ) id 1rhyRH-0002Ti-7Y; Wed, 06 Mar 2024 21:04:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689516.1074571; Wed, 06 Mar 2024 21:04:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhyRH-0002Tb-54; Wed, 06 Mar 2024 21:04:35 +0000 Received: by outflank-mailman (input) for mailman id 689516; Wed, 06 Mar 2024 21:04:34 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhyRF-0002TR-So for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 21:04:34 +0000 Received: from mail-oo1-xc32.google.com (mail-oo1-xc32.google.com [2607:f8b0:4864:20::c32]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 20ab3eca-dbfd-11ee-afda-a90da7624cb6; Wed, 06 Mar 2024 22:04:32 +0100 (CET) Received: by mail-oo1-xc32.google.com with SMTP id 006d021491bc7-5a136ac89b3so64604eaf.0 for ; Wed, 06 Mar 2024 13:04:32 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 20ab3eca-dbfd-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen-com.20230601.gappssmtp.com; s=20230601; t=1709759071; x=1710363871; darn=lists.xenproject.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=eqttQc0z5BWF+Q6AXLXQysSwEBzzLxVsfG6yMYfqEBc=; b=swWqlCHMmtAo8390tZF3nGOou0Gc9NpwD2obmTvecqErH2U7k4PLPcE+GMC6BIH4au bWH1oCVOPEgLFApFWMfTfAvh9LaUJiipZWF9l6BaOeCBRjLWX7gtodlOPj857rxu3M8K ln5R8U/lL0X7jdvYb4m3wRcKWPtTAGUp/R3HfC4WlUFdg0B5Vi0rn0J9/pcg0GKw5Zht v5OafqnhzbbS6GVugMk2RWhGYb4+kQEmq3VwXGiCm5sFgvrzrwhPu4+quWUO1wT4H+M9 4KieZhlOnwbLn3eauxCsbjLF+ZcQRbzX9TvKqtx/Iwovzik+THsL3nkKphQeKjv00jOb Zq4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709759071; x=1710363871; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=eqttQc0z5BWF+Q6AXLXQysSwEBzzLxVsfG6yMYfqEBc=; b=w+NWDWAaHlWRud4fgJgGSTGysH8kQxDYMhZo1w+gFQtM7ljp8vpuCOWmldZg6ManOl E+gBiUsK5oD5Uuc1GLvtsw0Xgmo9J4VBNcPL/FlP/J8s0bWrTXEelHwBe9kou2ip2x8Z JvaaobYa0cQMhiVQ9O63pW99il9bbeV2DjjbYxRChI7r6S1ekD6enYrIzktZjS8IANdQ LTF/oeLeDP2f+2dEMR0pp5XdYQ5wzYe9IyId71e/i0+JYtJ5kdAtWMCnVJXNz+tADFaA T/cPYjMEjBd/wpAWgEnIXLDlE+oQm32aK3X1cSEwHQpBRTM7fnZPwGY9la0R1I5/qyf3 VYeg== X-Forwarded-Encrypted: i=1; AJvYcCW8MYAHXT7DUy2gdqOBK2r4J9A82zBrstTs2AvV2VFMOoVUAcTyVGdwVGm6G4kZmZkM0BArJYLQvRPfkttXXQMOgQaDg7c68zx34R1QIaU= X-Gm-Message-State: AOJu0Ywy89DIuiBfCg/yfwRfCF6Atn/LUDpYJJSn12JwSDlNavnA73I8 zLXKpMorBaigABrgMLy2P5y3NJXav+gqKR8fu/Br1FfsQf16CPmmSARbPZrk3OatsWiMf61LBn2 GaMMUd78f4FP28D2liiiEEg+SNL5KC0XqCxJXnA== X-Google-Smtp-Source: AGHT+IH0C9ZIzGNFSz2j11GV3Dru4fT7GOz2PcdFewNaPrEAF+/MVK+QyAyKdBXc1oQAITbi8412yO35RUBzydE/0Wo= X-Received: by 2002:a05:6358:10a5:b0:17b:bd6e:22c9 with SMTP id j37-20020a05635810a500b0017bbd6e22c9mr8106933rwi.8.1709759071077; Wed, 06 Mar 2024 13:04:31 -0800 (PST) MIME-Version: 1.0 References: <20240305030516.41519-1-alexei.starovoitov@gmail.com> <20240305030516.41519-3-alexei.starovoitov@gmail.com> In-Reply-To: <20240305030516.41519-3-alexei.starovoitov@gmail.com> From: Pasha Tatashin Date: Wed, 6 Mar 2024 16:03:54 -0500 Message-ID: Subject: Re: [PATCH v4 bpf-next 2/2] mm: Introduce VM_SPARSE kind and vm_area_[un]map_pages(). To: Alexei Starovoitov Cc: bpf@vger.kernel.org, daniel@iogearbox.net, andrii@kernel.org, torvalds@linux-foundation.org, brho@google.com, hannes@cmpxchg.org, lstoakes@gmail.com, akpm@linux-foundation.org, urezki@gmail.com, hch@infradead.org, rppt@kernel.org, boris.ostrovsky@oracle.com, sstabellini@kernel.org, jgross@suse.com, linux-mm@kvack.org, xen-devel@lists.xenproject.org, kernel-team@fb.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Mar 4, 2024 at 10:05=E2=80=AFPM Alexei Starovoitov wrote: > > From: Alexei Starovoitov > > vmap/vmalloc APIs are used to map a set of pages into contiguous kernel > virtual space. > > get_vm_area() with appropriate flag is used to request an area of kernel > address range. It's used for vmalloc, vmap, ioremap, xen use cases. > - vmalloc use case dominates the usage. Such vm areas have VM_ALLOC flag. > - the areas created by vmap() function should be tagged with VM_MAP. > - ioremap areas are tagged with VM_IOREMAP. > > BPF would like to extend the vmap API to implement a lazily-populated > sparse, yet contiguous kernel virtual space. Introduce VM_SPARSE flag > and vm_area_map_pages(area, start_addr, count, pages) API to map a set > of pages within a given area. > It has the same sanity checks as vmap() does. > It also checks that get_vm_area() was created with VM_SPARSE flag > which identifies such areas in /proc/vmallocinfo > and returns zero pages on read through /proc/kcore. > > The next commits will introduce bpf_arena which is a sparsely populated > shared memory region between bpf program and user space process. It will > map privately-managed pages into a sparse vm area with the following step= s: > > // request virtual memory region during bpf prog verification > area =3D get_vm_area(area_size, VM_SPARSE); > > // on demand > vm_area_map_pages(area, kaddr, kend, pages); > vm_area_unmap_pages(area, kaddr, kend); > > // after bpf program is detached and unloaded > free_vm_area(area); > > Signed-off-by: Alexei Starovoitov > --- > include/linux/vmalloc.h | 5 ++++ > mm/vmalloc.c | 59 +++++++++++++++++++++++++++++++++++++++-- > 2 files changed, 62 insertions(+), 2 deletions(-) > > diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h > index c720be70c8dd..0f72c85a377b 100644 > --- a/include/linux/vmalloc.h > +++ b/include/linux/vmalloc.h > @@ -35,6 +35,7 @@ struct iov_iter; /* in uio.h */ > #else > #define VM_DEFER_KMEMLEAK 0 > #endif > +#define VM_SPARSE 0x00001000 /* sparse vm_area. not al= l pages are present. */ > > /* bits [20..32] reserved for arch specific ioremap internals */ > > @@ -232,6 +233,10 @@ static inline bool is_vm_area_hugepages(const void *= addr) > } > > #ifdef CONFIG_MMU > +int vm_area_map_pages(struct vm_struct *area, unsigned long start, > + unsigned long end, struct page **pages); > +void vm_area_unmap_pages(struct vm_struct *area, unsigned long start, > + unsigned long end); > void vunmap_range(unsigned long addr, unsigned long end); > static inline void set_vm_flush_reset_perms(void *addr) > { > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > index f42f98a127d5..e5b8c70950bc 100644 > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -648,6 +648,58 @@ static int vmap_pages_range(unsigned long addr, unsi= gned long end, > return err; > } > > +static int check_sparse_vm_area(struct vm_struct *area, unsigned long st= art, > + unsigned long end) > +{ > + might_sleep(); This interface and in general VM_SPARSE would be useful for dynamically grown kernel stacks [1]. However, the might_sleep() here would be a problem. We would need to be able to handle vm_area_map_pages() from interrupt disabled context therefore no sleeping. The caller would need to guarantee that the page tables are pre-allocated before the mapping. Pasha [1] https://lore.kernel.org/all/CA+CK2bBYt9RAVqASB2eLyRQxYT5aiL0fGhUu3TumQC= yJCNTWvw@mail.gmail.com From xen-devel-bounces@lists.xenproject.org Wed Mar 06 21:28:55 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 21:28:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689520.1074582 (Exim 4.92) (envelope-from ) id 1rhyoi-000674-5c; Wed, 06 Mar 2024 21:28:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689520.1074582; Wed, 06 Mar 2024 21:28:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhyoi-00066x-1x; Wed, 06 Mar 2024 21:28:48 +0000 Received: by outflank-mailman (input) for mailman id 689520; Wed, 06 Mar 2024 21:28:46 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhyog-00066r-MU for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 21:28:46 +0000 Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [2a00:1450:4864:20::436]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 825ed545-dc00-11ee-a1ee-f123f15fe8a2; Wed, 06 Mar 2024 22:28:44 +0100 (CET) Received: by mail-wr1-x436.google.com with SMTP id ffacd0b85a97d-33e122c8598so48292f8f.1 for ; Wed, 06 Mar 2024 13:28:44 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 825ed545-dc00-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709760523; x=1710365323; darn=lists.xenproject.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=O1WsOY8bv9E8W81TGc4aAT5ds7Sn1+QowuadTWjYWtk=; b=F2Z/b4WBDpHDuz5p0hMLYn5SO5FxF/jcnKHN5LIhCb+sZndnxsoteTLihGXtcIjz0B z0FVHmOesP8GzCzJteFYj8uWJMMoo1nihRI8XF3FPSVwTbELXWVgqgia0vq63hdKiKWs Huv8OfPnKV9PtHF+9Z8J1bKKjx7qHXW9+P85dX7dLesiixSyq0Gsn6xSrJsDLLEhJLn3 q0cu4jLp4jSmWStZ9lOyEgX1p8yQNIkJgByeF1m8W0jP4Gn5Wf2Y3ktkzA5ozZJ0OsD+ 0ODl79+4+EZa7ec7H+CpGTyaF/S0FGU84vixMNSXp24rGM4PznaKrO6lV9rMJspRNKVe OXrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709760523; x=1710365323; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=O1WsOY8bv9E8W81TGc4aAT5ds7Sn1+QowuadTWjYWtk=; b=q1GbjH6uAfP4WanDUimOShEdS5htLitzjYn2jH8JnIksBZa7tSJmdXtcI0+HcMTX7y 9PbYa4mOZ3Zn37Ai7yyV21YcXkac01mvd6HhVz9QuNxNXukABVMYT9KTiC/9EoXOQbtE HvFN8OmR/zAReV65ra/gh0ypXPXNaGVzjkO6ltj74CqxaxYwQloSH8O2Mb+X/AABFZBB MbL2HstsSe7KrPfh74P8hEvV/quS/zJFokz3m3SD+8qIOAcTZ0Ou8xC9tnTkH9D7Y7Ow jbjntTFibngbb5B+L6PY2fn7t5JzDbGvW/M/ZxmRSIqbrMRq/066XlpwS0BO9XXYsOEX l05g== X-Forwarded-Encrypted: i=1; AJvYcCWvezk6ZZBtbX9rV0wKc+fJ5XZDsv0YeYIAL2wctW5B6r/JLCg9gWRtUNZ3TmIaFV70dTq2UcK/i4IUrkwdaToNTpzlOWgEF9FlAwRJlGE= X-Gm-Message-State: AOJu0Ywh8HQj9OSFu7z7UYkYyU+DhvSEpnnWvy2YBhXnyVkTMLg6rAja M8k9lvx7MZbSWGNRXZmygRyBgvwiEF9yPJBEi4HfOfPGWhKLDTGwHyTwqZR/M0Ds8GkhXGHjLsq ptpKcDLTfW+gPGUIAze9hSIHPRPg= X-Google-Smtp-Source: AGHT+IE8LqByzqRA7G6sW+7haX1F0BJfAJWcPpQ+nTruzkV9H0WItHjtg14wkPEK8qPwytWAsZTgM/brnIzbFge2cI0= X-Received: by 2002:a5d:5750:0:b0:33d:1145:8787 with SMTP id q16-20020a5d5750000000b0033d11458787mr11006914wrw.25.1709760523501; Wed, 06 Mar 2024 13:28:43 -0800 (PST) MIME-Version: 1.0 References: <20240305030516.41519-1-alexei.starovoitov@gmail.com> <20240305030516.41519-3-alexei.starovoitov@gmail.com> In-Reply-To: From: Alexei Starovoitov Date: Wed, 6 Mar 2024 13:28:31 -0800 Message-ID: Subject: Re: [PATCH v4 bpf-next 2/2] mm: Introduce VM_SPARSE kind and vm_area_[un]map_pages(). To: Pasha Tatashin Cc: bpf , Daniel Borkmann , Andrii Nakryiko , Linus Torvalds , Barret Rhoden , Johannes Weiner , Lorenzo Stoakes , Andrew Morton , Uladzislau Rezki , Christoph Hellwig , Mike Rapoport , Boris Ostrovsky , sstabellini@kernel.org, Juergen Gross , linux-mm , xen-devel@lists.xenproject.org, Kernel Team Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Mar 6, 2024 at 1:04=E2=80=AFPM Pasha Tatashin wrote: > > On Mon, Mar 4, 2024 at 10:05=E2=80=AFPM Alexei Starovoitov > wrote: > > > > From: Alexei Starovoitov > > > > vmap/vmalloc APIs are used to map a set of pages into contiguous kernel > > virtual space. > > > > get_vm_area() with appropriate flag is used to request an area of kerne= l > > address range. It's used for vmalloc, vmap, ioremap, xen use cases. > > - vmalloc use case dominates the usage. Such vm areas have VM_ALLOC fla= g. > > - the areas created by vmap() function should be tagged with VM_MAP. > > - ioremap areas are tagged with VM_IOREMAP. > > > > BPF would like to extend the vmap API to implement a lazily-populated > > sparse, yet contiguous kernel virtual space. Introduce VM_SPARSE flag > > and vm_area_map_pages(area, start_addr, count, pages) API to map a set > > of pages within a given area. > > It has the same sanity checks as vmap() does. > > It also checks that get_vm_area() was created with VM_SPARSE flag > > which identifies such areas in /proc/vmallocinfo > > and returns zero pages on read through /proc/kcore. > > > > The next commits will introduce bpf_arena which is a sparsely populated > > shared memory region between bpf program and user space process. It wil= l > > map privately-managed pages into a sparse vm area with the following st= eps: > > > > // request virtual memory region during bpf prog verification > > area =3D get_vm_area(area_size, VM_SPARSE); > > > > // on demand > > vm_area_map_pages(area, kaddr, kend, pages); > > vm_area_unmap_pages(area, kaddr, kend); > > > > // after bpf program is detached and unloaded > > free_vm_area(area); > > > > Signed-off-by: Alexei Starovoitov > > --- > > include/linux/vmalloc.h | 5 ++++ > > mm/vmalloc.c | 59 +++++++++++++++++++++++++++++++++++++++-- > > 2 files changed, 62 insertions(+), 2 deletions(-) > > > > diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h > > index c720be70c8dd..0f72c85a377b 100644 > > --- a/include/linux/vmalloc.h > > +++ b/include/linux/vmalloc.h > > @@ -35,6 +35,7 @@ struct iov_iter; /* in uio.h */ > > #else > > #define VM_DEFER_KMEMLEAK 0 > > #endif > > +#define VM_SPARSE 0x00001000 /* sparse vm_area. not = all pages are present. */ > > > > /* bits [20..32] reserved for arch specific ioremap internals */ > > > > @@ -232,6 +233,10 @@ static inline bool is_vm_area_hugepages(const void= *addr) > > } > > > > #ifdef CONFIG_MMU > > +int vm_area_map_pages(struct vm_struct *area, unsigned long start, > > + unsigned long end, struct page **pages); > > +void vm_area_unmap_pages(struct vm_struct *area, unsigned long start, > > + unsigned long end); > > void vunmap_range(unsigned long addr, unsigned long end); > > static inline void set_vm_flush_reset_perms(void *addr) > > { > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > > index f42f98a127d5..e5b8c70950bc 100644 > > --- a/mm/vmalloc.c > > +++ b/mm/vmalloc.c > > @@ -648,6 +648,58 @@ static int vmap_pages_range(unsigned long addr, un= signed long end, > > return err; > > } > > > > +static int check_sparse_vm_area(struct vm_struct *area, unsigned long = start, > > + unsigned long end) > > +{ > > + might_sleep(); > > This interface and in general VM_SPARSE would be useful for > dynamically grown kernel stacks [1]. However, the might_sleep() here > would be a problem. We would need to be able to handle > vm_area_map_pages() from interrupt disabled context therefore no > sleeping. The caller would need to guarantee that the page tables are > pre-allocated before the mapping. Sounds like we'd need to differentiate two kinds of sparse regions. One that is really sparse where page tables are not populated (bpf use case= ) and another where only the pte level might be empty. Only the latter one will be usable for such auto-grow stacks. Months back I played with this idea: https://git.kernel.org/pub/scm/linux/kernel/git/ast/bpf.git/commit/?&id=3Dc= e63949a879f2f26c1c1834303e6dfbfb79d1fbd that "Make vmap_pages_range() allocate page tables down to the last (PTE) level.= " Essentially pass NULL instead of 'pages' into vmap_pages_range() and it will populate all levels except the last. Then the page fault handler can service a fault in auto-growing stack area if it has a page stashed in some per-cpu free list. I suspect this is something you might need for "16k stack that is populated on fault", plus a free list of 3 pages per-cpu, and set_pte_at() in pf handler. From xen-devel-bounces@lists.xenproject.org Wed Mar 06 21:31:39 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 21:31:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689522.1074592 (Exim 4.92) (envelope-from ) id 1rhyrS-0008AK-IC; Wed, 06 Mar 2024 21:31:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689522.1074592; Wed, 06 Mar 2024 21:31:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhyrS-0008AD-FM; Wed, 06 Mar 2024 21:31:38 +0000 Received: by outflank-mailman (input) for mailman id 689522; Wed, 06 Mar 2024 21:31:37 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhyrQ-0008A2-ND for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 21:31:37 +0000 Received: from fout7-smtp.messagingengine.com (fout7-smtp.messagingengine.com [103.168.172.150]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id e6cff01e-dc00-11ee-a1ee-f123f15fe8a2; Wed, 06 Mar 2024 22:31:33 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailfout.nyi.internal (Postfix) with ESMTP id 004B71380101; Wed, 6 Mar 2024 16:31:32 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Wed, 06 Mar 2024 16:31:32 -0500 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 6 Mar 2024 16:31:30 -0500 (EST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e6cff01e-dc00-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= invisiblethingslab.com; h=cc:cc:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1709760691; x=1709847091; bh=DORPyG1rT9K1X/ITePyxsRS31apnbdqz9ZRD2mr6WPw=; b= JHJW5n6L9szrMIB1x645aoVbBPtDKERwhzqvofA43FAt7lmETdc0QstN840ZMzgz RF155ngC6cDMOYAuvtZJXhcg8ot5+bId5oQQDJQd91wTL8qk2s/P4WwsG+33uM54 eiEex9XuBE563MfD7mSzZPW1e+3JR2qgzRU4YmNPsTrbrmeymsZEg6e4UDupezle Hvdmqp49GPw+/iv8JkS1XzSnIcdn8q4kS2QjOuS2Fgzj3SggqDsWpaJAd2bt39WW ZNdsyS6aS8X0L4QZMImctJIUyTUhie86CgdzaBUNN6ocCYAysBREZj6rbcQhYMGB Ezplcle3ESJjtU1L+4MVfA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1709760691; x=1709847091; bh=DORPyG1rT9K1X/ITePyxsRS31apn bdqz9ZRD2mr6WPw=; b=GPZZavt90866rF1elW2YKSy3FVp8i3W/Ep4vxBh+6yAC APjNJZnRN2mGpYuREc9JS3rMNI4gNew4KVBtqSMRLOPoQNaxJ+8IZPUYOaXsTMaF Tw7WHmG5VAgmU0Kp2Q/ydiQt8GB1fdR47gZfBkkcUjXQ4nlLu+i+Ika9d2s6ZyfV /I1Ho9h2pqbnco6S8qYe4mb+UixPGx/ajipApzE5eGFg7i6SY9Zc6TUH1vtEwtbE kaZLyDFUO2o3bAJtultbAeEKfxsuklAhN2vo0xxNxMPBiQsoQA1cZy2Tn9Z5NveY wT3UxHTMbYxDrkItgaxjIqT52AhMBlYP0kGi6CZVLg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledriedugddugeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkfhggtggujgesghdtroertddtjeenucfhrhhomhepofgrrhgv khcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinh hvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepfeek hfeffeegjeduleetffejtedtjeeuvdekgedtvdfgleekveehjeeuveehhedvnecuffhomh grihhnpehfrhgvvgguvghskhhtohhprdhorhhgpdgrmhgupghsvdhiughlvgdrphihnecu vehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrg hrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomh X-ME-Proxy: Feedback-ID: i1568416f:Fastmail Date: Wed, 6 Mar 2024 22:31:28 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Mario Limonciello Cc: =?utf-8?Q?S=C3=A9bastien?= Chaumat , xen-devel@lists.xenproject.org, Jan Beulich , Juergen Gross Subject: Re: [BUG]i2c_hid_acpi broken with 4.17.2 on Framework Laptop 13 AMD Message-ID: References: <19852f4d-fbeb-4314-a2cb-ab3f05da13ba@amd.com> <7c2f9983-a0b5-41f7-81cb-f196787f3dfb@amd.com> <2a609713-3eec-438e-80af-c1dfcfe598c4@amd.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="HT33YYw7sRW++IZl" Content-Disposition: inline In-Reply-To: <2a609713-3eec-438e-80af-c1dfcfe598c4@amd.com> --HT33YYw7sRW++IZl Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Mar 2024 22:31:28 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Mario Limonciello Cc: =?utf-8?Q?S=C3=A9bastien?= Chaumat , xen-devel@lists.xenproject.org, Jan Beulich , Juergen Gross Subject: Re: [BUG]i2c_hid_acpi broken with 4.17.2 on Framework Laptop 13 AMD On Wed, Mar 06, 2024 at 02:37:20PM -0600, Mario Limonciello wrote: > On 3/6/2024 14:34, S=C3=A9bastien Chaumat wrote: > >=20 > >=20 > > Le=C2=A0mer. 6 mars 2024 =C3=A0=C2=A019:51, Mario Limonciello > > > a =C3=A9= crit=C2=A0: > >=20 > > On 3/6/2024 12:49, S=C3=A9bastien Chaumat wrote: > > > > > > > > > Le=C2=A0mer. 6 mars 2024 =C3=A0=C2=A019:08, Mario Limonciello > > > > > > >> a =C3=A9crit=C2=A0: > > > > > >=C2=A0 =C2=A0 =C2=A0On 3/6/2024 12:05, S=C3=A9bastien Chaumat wro= te: > > >=C2=A0 =C2=A0 =C2=A0 > > > >=C2=A0 =C2=A0 =C2=A0 > > > >=C2=A0 =C2=A0 =C2=A0 > Le=C2=A0mer. 6 mars 2024 =C3=A0=C2=A018:33= , Mario Limonciello > > >=C2=A0 =C2=A0 =C2=A0 > > >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Also; I'd be really int= erested to hear what happens with > > >=C2=A0 =C2=A0 =C2=A0s2idle with > > >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Xen > > >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0now (if it works). > > >=C2=A0 =C2=A0 =C2=A0 > > > >=C2=A0 =C2=A0 =C2=A0 > > > >=C2=A0 =C2=A0 =C2=A0 > suspend to RAM now works :) > > > > > >=C2=A0 =C2=A0 =C2=A0Do you see /sys/power/suspend_stats/last_hw_s= leep increasing > > with your > > >=C2=A0 =C2=A0 =C2=A0suspend cycle? > > > > > > > > > No,=C2=A0 it does not increase (0). > > > > >=20 > > OK, then in that case I suggest you run > > https://gitlab.freedesktop.org/drm/amd/-/blob/master/scripts/amd_s2= idle.py > > in the hypervisor to find out what's wrong. > >=20 > >=20 > > It fails with xen (not bare metal) during the prerequisite tests : > >=20 >=20 > The script might need some modifications for tests that don't make sense = in > the context of Xen. >=20 > > =E2=9C=85 GPIO driver `pinctrl_amd` available > > Traceback (most recent call last): > > =C2=A0 File "/home/sch/Downloads/amd_s2idle.py", line 2447, in > > =C2=A0 =C2=A0 test =3D app.prerequisites() > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^^^^^^^^^^^^^^^^^^^ > > =C2=A0 File "/home/sch/Downloads/amd_s2idle.py", line 1938, in prerequ= isites > > =C2=A0 =C2=A0 if not check(): > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^^^^^^^ > > =C2=A0 File "/home/sch/Downloads/amd_s2idle.py", line 826, in check_msr > > =C2=A0 =C2=A0 val =3D read_msr(reg, 0) > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^^^^^^^^^^^^^^^^ > > =C2=A0 File "/home/sch/Downloads/amd_s2idle.py", line 813, in read_msr > > =C2=A0 =C2=A0 val =3D struct.unpack("Q", os.read(f, 8))[0] > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^^^^^^^^^^^^^ > > OSError: [Errno 5] Input/output error > >=20 > > Last line in the log is : > > 2024-03-06 21:29:33,146 DEBUG: Lockdown: [none] integrity confidentiali= ty > >=20 >=20 > Do you have userspace MSR support compiled in? If not; that could explain > that problem. But it's very unlikely you changed the MSRs. > For the purpose of finding where the suspend problem is, I'd comment out > that specific check for now. The s2idle isn't supported in Xen yet. Only S3 is. In fact, I have some work-in-progress patches for that, I may try testing them on this system. --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab --HT33YYw7sRW++IZl Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmXo4LEACgkQ24/THMrX 1yx74wgAiyFwN0neiD07/K9M1vgr92W7f1Sr/u3jmLZl1/OM2eHti44gl4G4ClEP le7TWLJw65QNKIAWnaHJuQdzTpm8+Xw5b5mQVnl9bKI9ixvC/H+WycuW25EQtv3z fykNDxvmz5x+hPY4hM+64jPTD0RcVmgkqrPFXUEkonPHjAiHiGUp9J2gmu9KcFDW cwUk5l7znUZdPC9SvUpTgJKVGf9wcmZCg5rXycij8Jvgp7d4SYlL2YmO5NrJC8E8 iFE7USj6sYLiJIWPki3Gmy2AC540lA/GeXBlcrtOaZHXZxv3bYzQiEi7Xuylfewi G4odHBLab4gkG/YtQnujTj7GIJhOGw== =MmtC -----END PGP SIGNATURE----- --HT33YYw7sRW++IZl-- From xen-devel-bounces@lists.xenproject.org Wed Mar 06 21:42:01 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 21:42:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689529.1074601 (Exim 4.92) (envelope-from ) id 1rhz1J-00024K-Gm; Wed, 06 Mar 2024 21:41:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689529.1074601; Wed, 06 Mar 2024 21:41:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhz1J-00024D-Dv; Wed, 06 Mar 2024 21:41:49 +0000 Received: by outflank-mailman (input) for mailman id 689529; Wed, 06 Mar 2024 21:41:48 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhz1I-0001yh-2l for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 21:41:48 +0000 Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [85.215.255.20]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 5503f32f-dc02-11ee-afda-a90da7624cb6; Wed, 06 Mar 2024 22:41:47 +0100 (CET) Received: from mail.onlineschubla.de by smtp.strato.de (RZmta 50.2.0 DYNA|AUTH) with ESMTPSA id Q6d30f026Lfif3M (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Wed, 6 Mar 2024 22:41:44 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.onlineschubla.de (Postfix) with ESMTP id 852762137F; Wed, 6 Mar 2024 22:41:43 +0100 (CET) Received: from mail.onlineschubla.de ([127.0.0.1]) by localhost (mail.onlineschubla.de [127.0.0.1]) (amavis, port 10024) with ESMTP id OfPODNHRmeaq; Wed, 6 Mar 2024 22:41:42 +0100 (CET) Received: from [10.0.0.105] (unknown [10.0.0.105]) by mail.onlineschubla.de (Postfix) with ESMTPA id B5AA52003F; Wed, 6 Mar 2024 22:41:42 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 5503f32f-dc02-11ee-afda-a90da7624cb6 ARC-Seal: i=1; a=rsa-sha256; t=1709761304; cv=none; d=strato.com; s=strato-dkim-0002; b=foCuluBHuJQHK+p9X7jWv05wVMJY2MUWCZ4qY1bbs32ruXYVXZhJ2B0oR9YtabOdS+ O/IMHQEiqx9VGbqxd724YZ1BZ+AQZCZZFwa2l6XHv/O1kYSCwZPaV/IXVYEIZCvK87Os KDKcGFHGnFt3wvDY4YkLF3RF+V62vlLmtgf8hcyjS/G1ASrvvrg23awmmp28weGajDDy fS5vZYgNYZiS97xxgl46odTlHorDJHOsCd9jUkHd8c59rifwq7+vlL7KnXI7fvqp/rVP GtTLSxoa7Y6Min9x6G1V0oIloPMtNk8sSLZV/ipadr7Dr70PBIixWbRPTVLQL4Gxo/k0 ToPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1709761304; s=strato-dkim-0002; d=strato.com; h=In-Reply-To:From:References:Cc:To:Subject:Date:Message-ID:Cc:Date: From:Subject:Sender; bh=rGB4GIoTsZOopZuUz/VCWygSuDvuwonXhHAwFJiy9tk=; b=R7thivFzXZaN+UbA8CpfFLg7wNrEH92C0t/du4+XS4DNdv1myBN7hh5tJagf74SSUg JA3CLhiwoXRfbSebpKrOfPS3w2iSJ8uSnc/i93pYkazHCNb5TbfvUHSdQv6bjP7z0T2i UYCeEkWRqOUHr4GV725sJvNtu/bdH+Z9jRC+zB7vrgLRwtBkmsq0t+/YTQ1hzEtV3yHp UhKPmys0b80khSTsW6KBOtEksy2BAl4NimpXjaVKoy1LjSXQbkfrtExhNxo9pN0OwpVo RquI0ZV99wI3JAAvH/x4C1fJHFXMBEBqGusKpczXl8jLlATzRLm/kGDfF0JGGiKIWG2M 7Enw== ARC-Authentication-Results: i=1; strato.com; arc=none; dkim=none X-RZG-CLASS-ID: mo00 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1709761304; s=strato-dkim-0002; d=onlineschubla.de; h=In-Reply-To:From:References:Cc:To:Subject:Date:Message-ID:Cc:Date: From:Subject:Sender; bh=rGB4GIoTsZOopZuUz/VCWygSuDvuwonXhHAwFJiy9tk=; b=iGgclRtTOvUa7WT+CGxNYd0LozMu78fl8x/UawY86SxEQmn+64jDU48QxZTFlZImbW 5bZJFB/l7uEBCMu9TkAzycmHPAknI7IwaDyYAzyu5yCBuJfUnE+FRUclU0sN/om85jAg 4wJ8RIULEwxP/UNMzLfjGLkbSazxi1Mmi0Kfftm9RJfNn1eyehvraRZ5eJR4CPT80d2I xacR73hBmDYYfAWvKRv/cXfy7ArvhcgbyQgHBdlAlhU3YWifK0sau3InWUUgJH6hQ7oE p+zOO5hSYgWUhhlTbdcJhqgWQ43gvsLaao4KWYZgLeQUYlpPFDUt/fuuy7r3dpxmLH9s DTzQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; t=1709761304; s=strato-dkim-0003; d=onlineschubla.de; h=In-Reply-To:From:References:Cc:To:Subject:Date:Message-ID:Cc:Date: From:Subject:Sender; bh=rGB4GIoTsZOopZuUz/VCWygSuDvuwonXhHAwFJiy9tk=; b=5SwiLbtP1EG7pZB6dq2e2wR5dwqAEuThIivBrUQCiCc9khK9HZSyBWLRk8tzQSKocc +pXkFngUupE3CEJntDAA== X-RZG-AUTH: ":PG0ReWCndfO3rCSML4AvNaDxJ7WJyilEI/NMX3IPsStZLbcZC9mNZx0oO96cCwacwToyD+C58ign1Q==" X-Virus-Scanned: Debian amavis at onlineschubla.de Message-ID: <925354c7-dedf-44be-8d1c-8e426c35521d@onlineschubla.de> Date: Wed, 6 Mar 2024 22:41:36 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Xen 4.18rc/ARM64 on Raspberry Pi 4B: Traffic in DomU crashing Dom0 when using VLANs Content-Language: en-US To: Julien Grall , Xen-devel Cc: Stefano Stabellini , george.dunlap@cloud.com, Michal Orzel , Bertrand Marquis References: <838ff75f-1352-4d3c-9bc1-c7a57c828231@onlineschubla.de> <4cddfd89-f195-4a50-a14d-b86121414e56@onlineschubla.de> <4d7dbce9-ef20-4702-8056-9d5ab8152721@onlineschubla.de> <1aa294ec-704c-4370-94c5-54573ed82af6@xen.org> From: Paul Leiber In-Reply-To: <1aa294ec-704c-4370-94c5-54573ed82af6@xen.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Julien Am 04.03.2024 um 23:15 schrieb Julien Grall: > Hi Paul, > > On 01/03/2024 19:37, Paul Leiber wrote: >> Stopping xen-watchdog prevents the reboot. However, when triggering >> traffic on the VLAN, Dom0 and DomU become completely unresponsive. No >> error or kernel message is printed in the serial console. > > Thanks for providing some logs. See some comments below. How long did > you wait before confirming dom0 is stucked? > > IIRC, Linux may print some RCU stall logs after a few minutes. > >> >> Switching to Xen console works. Pressing '0' produces the following >> output: >> >> (XEN) '0' pressed -> dumping Dom0's registers >> (XEN) *** Dumping Dom0 vcpu#0 state: *** >> (XEN) ----[ Xen-4.19-unstable  arm64  debug=y  Tainted:   C    ]---- >> (XEN) CPU:    0 >> (XEN) PC:     ffff800008027e50 >> (XEN) LR:     ffff800008027e44 >> (XEN) SP_EL0: ffff800009c78f80 >> (XEN) SP_EL1: ffff800008003b60 >> (XEN) CPSR:   00000000000003c5 MODE:64-bit EL1h (Guest Kernel, handler) > > [...] > >> (XEN) *** Dumping Dom0 vcpu#1 state: *** >> (XEN) ----[ Xen-4.19-unstable  arm64  debug=y  Tainted:   C    ]---- >> (XEN) CPU:    0 >> (XEN) PC:     ffff800008c5dc80 >> (XEN) LR:     ffff800008c5dc88 >> (XEN) SP_EL0: ffff000042272080 >> (XEN) SP_EL1: ffff80000800b0e0 >> (XEN) CPSR:   0000000080000305 MODE:64-bit EL1h (Guest Kernel, handler) > > [...] > >> (XEN) *** Dumping Dom0 vcpu#2 state: *** >> (XEN) ----[ Xen-4.19-unstable  arm64  debug=y  Tainted:   C    ]---- >> (XEN) CPU:    0 >> (XEN) PC:     ffff800008027e50 >> (XEN) LR:     ffff800008027e44 >> (XEN) SP_EL0: ffff000042271040 >> (XEN) SP_EL1: ffff800009fcbf20 >> (XEN) CPSR:   00000000000003c5 MODE:64-bit EL1h (Guest Kernel, handler) > > [...] > >> (XEN) *** Dumping Dom0 vcpu#3 state: *** >> (XEN) ----[ Xen-4.19-unstable  arm64  debug=y  Tainted:   C    ]---- >> (XEN) CPU:    0 >> (XEN) PC:     ffff800008027e50 >> (XEN) LR:     ffff800008027e44 >> (XEN) SP_EL0: ffff0000422730c0 >> (XEN) SP_EL1: ffff800009fd3f20 >> (XEN) CPSR:   00000000000003c5 MODE:64-bit EL1h (Guest Kernel, handler) > > All the PCs but one (vcpu#1) are the same. > >> (XEN) 'q' pressed -> dumping domain info (now = 727929105981) >> (XEN) General information for domain 0: >> (XEN)     refcnt=3 dying=0 pause_count=0 >> (XEN)     nr_pages=262144 xenheap_pages=2 dirty_cpus={} max_pages=262144 >> (XEN)     handle=00000000-0000-0000-0000-000000000000 vm_assist=00000020 >> (XEN) p2m mappings for domain 0 (vmid 1): >> (XEN)   1G mappings: 0 (shattered 1) >> (XEN)   2M mappings: 422 (shattered 90) >> (XEN)   4K mappings: 45372 >> (XEN) Rangesets belonging to domain 0: >> (XEN)     Interrupts { 32-152, 154-255 } >> (XEN)     I/O Memory { 0-fe200, fe203-ff841, ff849-ffffffffffffffff } >> (XEN) NODE affinity for domain 0: [0] >> (XEN) VCPU information and callbacks for domain 0: >> (XEN)   UNIT0 affinities: hard={0-3} soft={0-3} >> (XEN)     VCPU0: CPU3 [has=F] poll=0 upcall_pend=01 upcall_mask=01 >> (XEN)     pause_count=0 pause_flags=1 > > The vCPU is blocked. But... > >> (XEN) GICH_LRs (vcpu 0) mask=f >> (XEN)    VCPU_LR[0]=2a000002 >> (XEN)    VCPU_LR[1]=1a00001b >> (XEN)    VCPU_LR[2]=1a000001 >> (XEN)    VCPU_LR[3]=1a000010 > > ... it loosk like multiple IRQs are inflights. LR0 (holding IRQ2) is > active but the others are pending. This is the same for vCPU #2, #3. > vCPU #1 still seems to "work". > > AFAICT, Linux is using IRQ2 for the IPI CPU_STOP. So it sounds like dom0 > may have panicked. > > Looking at the initial logs you posted. I see some messages from Xen but > no messages at all from dom0 (including boot). Can you check if you have > console=hvc0 on the Linux command line? > > If not, please add it and retry. *facepalm* After activating Dom0 output in xen console with console=hvc0, Dom0 messages appear in xen console. Directly after triggering the crash, the following messages appear: [ 59.239150] ------------[ cut here ]------------ [ 59.243691] kernel BUG at kernel/dma/swiotlb.c:666! [ 59.248640] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP [ 59.254790] Modules linked in: bridge 8021q garp mrp stp llc binfmt_misc nls_ascii nls_cp437 vfat fat hci_uart btqca btrtl btbcm btintel btsdio bluetooth jitterentropy_rng sha512_generic sha512_arm64 aes_neon_bs brcmfmac aes_neon_blk brcmutil drbg ansi_cprng cfg80211 ecdh_generic rfkill ecc sg xen_pciback xen_netback xen_blkback xen_gntalloc xen_gntdev xen_evtchn loop fuse drm efi_pstore configfs xenfs xen_privcmd efivarfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic dm_mod dax sd_mod t10_pi crc64_rocksoft crc64 crc_t10dif crct10dif_generic uas usb_storage scsi_mod scsi_common broadcom bcm_phy_ptp bcm_phy_lib genet dwc2 mdio_bcm_unimac of_mdio udc_core fixed_phy xhci_plat_hcd roles fwnode_mdio xhci_hcd crct10dif_ce crct10dif_common sdhci_iproc sdhci_pltfm usbcore libphy sdhci usb_common [ 59.326308] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.1.0-17-arm64 #1 Debian 6.1.69-1 [ 59.334445] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 59.341469] pc : swiotlb_tbl_map_single+0x420/0x6d0 [ 59.346417] lr : 0x0 [ 59.348669] sp : ffff80000800b4e0 [ 59.352056] x29: ffff80000800b4e0 x28: 0000000000000000 x27: 0000000000000000 [ 59.359263] x26: 0000000000000000 x25: 0000000000000001 x24: ffff00004a2ca010 [ 59.366461] x23: ffff800009f54688 x22: 0000000042800000 x21: 0000000000000000 [ 59.373665] x20: 0001000000000000 x19: 0020000000000000 x18: fffffc0000000000 [ 59.380862] x17: 0000000000000119 x16: ffff800009c74560 x15: 78e9d7c1ef2ec7fd [ 59.388065] x14: 0000000000000000 x13: 0000000000000000 x12: ffff000048142c10 [ 59.395266] x11: ffff00004a2ca000 x10: 0000000000000002 x9 : ffff8000087ed3b4 [ 59.402468] x8 : 0000000000000010 x7 : 0000000000000000 x6 : 0000000000000000 [ 59.409671] x5 : ffff000048142f10 x4 : 0000000000000000 x3 : 0000000000000000 [ 59.416872] x2 : 0000000000000001 x1 : 0000000000000003 x0 : 0000000000000000 [ 59.424075] Call trace: [ 59.426590] swiotlb_tbl_map_single+0x420/0x6d0 [ 59.431189] xen_swiotlb_map_page+0xe4/0x440 [ 59.435528] dma_map_page_attrs+0x1e8/0x240 [ 59.439779] bcmgenet_xmit+0x194/0x7d0 [genet] [ 59.444292] dev_hard_start_xmit+0xa8/0x1c0 [ 59.448543] sch_direct_xmit+0x98/0x314 [ 59.452448] __dev_queue_xmit+0x9bc/0xdd4 [ 59.456526] vlan_dev_hard_start_xmit+0xb4/0x17c [8021q] [ 59.461906] dev_hard_start_xmit+0xa8/0x1c0 [ 59.466158] __dev_queue_xmit+0x254/0xdd4 [ 59.470236] br_dev_queue_push_xmit+0xd8/0x1f0 [bridge] [ 59.475529] br_forward_finish+0x5c/0xd0 [bridge] [ 59.480301] __br_forward+0x168/0x1d0 [bridge] [ 59.484814] br_forward+0x120/0x13c [bridge] [ 59.489152] br_handle_frame_finish+0x330/0x5c0 [bridge] [ 59.494533] br_handle_frame+0x2cc/0x3c0 [bridge] [ 59.499304] __netif_receive_skb_core.constprop.0+0x288/0xe70 [ 59.505118] __netif_receive_skb_one_core+0x44/0x90 [ 59.510064] __netif_receive_skb+0x20/0x70 [ 59.514229] netif_receive_skb+0x54/0x160 [ 59.518307] xenvif_tx_action+0x6b8/0x934 [xen_netback] [ 59.523608] xenvif_poll+0x3c/0xc0 [xen_netback] [ 59.528286] __napi_poll+0x40/0x1e0 [ 59.531843] net_rx_action+0x384/0x470 [ 59.535661] __do_softirq+0x120/0x338 [ 59.539392] ____do_softirq+0x18/0x24 [ 59.543130] call_on_irq_stack+0x24/0x50 [ 59.547115] do_softirq_own_stack+0x24/0x3c [ 59.551366] __irq_exit_rcu+0x104/0x130 [ 59.555271] irq_exit_rcu+0x18/0x24 [ 59.558829] el1_interrupt+0x38/0x54 [ 59.562473] el1h_64_irq_handler+0x18/0x2c [ 59.566638] el1h_64_irq+0x64/0x68 [ 59.570109] arch_cpu_idle+0x18/0x2c [ 59.573762] default_idle_call+0x50/0x114 [ 59.577831] do_idle+0x24c/0x2c0 [ 59.581129] cpu_startup_entry+0x3c/0x4c [ 59.585121] secondary_start_kernel+0x130/0x154 [ 59.589719] __secondary_switched+0xb0/0xb4 [ 59.593983] Code: f9400c00 cb0002c0 8a130016 17ffffed (d4210000) [ 59.600135] ---[ end trace 0000000000000000 ]--- [ 59.614441] Kernel panic - not syncing: Oops - BUG: Fatal exception in interrupt [ 59.621740] SMP: stopping secondary CPUs [ 59.625756] Kernel Offset: disabled [ 59.629283] CPU features: 0x80000,2002c080,0000421b [ 59.634230] Memory Limit: none [ 59.646915] ---[ end Kernel panic - not syncing: Oops - BUG: Fatal exception in interrupt ]--- I assume that this is the missing console output you were trying to get to. Just to make sure, I let the system wait for 15 minutes, but nothing happened anymore. Am I right when assuming that I now need to debug this kernel panic? Any hints you can give me already? Best regards, Paul From xen-devel-bounces@lists.xenproject.org Wed Mar 06 21:46:48 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 21:46:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689533.1074612 (Exim 4.92) (envelope-from ) id 1rhz66-0002en-3B; Wed, 06 Mar 2024 21:46:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689533.1074612; Wed, 06 Mar 2024 21:46:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhz65-0002eg-W8; Wed, 06 Mar 2024 21:46:45 +0000 Received: by outflank-mailman (input) for mailman id 689533; Wed, 06 Mar 2024 21:46:44 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhz64-0002ea-UB for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 21:46:44 +0000 Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [2607:f8b0:4864:20::833]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 059196f8-dc03-11ee-afda-a90da7624cb6; Wed, 06 Mar 2024 22:46:43 +0100 (CET) Received: by mail-qt1-x833.google.com with SMTP id d75a77b69052e-42ef17b4021so987131cf.0 for ; Wed, 06 Mar 2024 13:46:43 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 059196f8-dc03-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen-com.20230601.gappssmtp.com; s=20230601; t=1709761602; x=1710366402; darn=lists.xenproject.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=sqaAoKPOgm/rSWCI7eBbS/kktgGPF2ytcO0T40EpJ3Q=; b=RLe6nrJxim8GUSu19ZByZa3AZlxl5HcnMO8sF6qoGdzPzS6gqMe87kRpPHzVkeoQss 8f5PWZe8C1goYMsIDHiU1aWDOnpdNhDr+2U4raRzQsadDcH5bKZp7B+dzBeHo1FOxZMi gf9507B+8wvkWyDqPRrjFqz1LPzUl6z2X+gDVwmHIZ3aBJUQzLuPTlNGfiCpsIGkOlK/ 7zkz/FYYcnh58SFpaAVMcxJjbISH9E+myvrsUXdzSquLJG3MBCz5+e/xiaecnBohtOJR jmuzhCFy5xUMUVFyWlmLp91zKAJKdx5TMDJtHatFe13xHPoWQkepWFiVdB/B3rYWOGlQ Tkdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709761602; x=1710366402; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=sqaAoKPOgm/rSWCI7eBbS/kktgGPF2ytcO0T40EpJ3Q=; b=r1Qg4OibkFEgEl2EHH3wtQeXK9CxPJaFIil1IflGiHuirqb0Dh5wMyy1SJGfRJA/hz 0MA7PwOIrlYENzmgSoE7FSuPghg8yJhHFceLQC0wkBKG/io5ZvSRDumQkc8B5KHSMaYf 7D2WuWtPCZ9Z4rOnGHyi/NkWAhJYUy2bVkNTQBJpeqSqBVex3pj2WBcoDqHMAtMQkOa9 Fex9sESDJ+kmME5ExFhlvJUKttFqElvZH1I3MniblxkKsqhLkljFdNKINviQ/ZfeGplc qtaMdmias8W4+rm+q+sxFQJP3ol3butUTD0iryZsdMv9I/tyAzvG0hYFTtbKFEpvq0AR k1Zw== X-Forwarded-Encrypted: i=1; AJvYcCWFkxKFWVkNmKEZFoq3WHkCEtgikAM+c5caeRXh+P3BQl1D1oaLLR0MMg/lhJSJOziXIu5mYNEjVBzW/eqPEEbRTgzzT7twawM1WR7LO8w= X-Gm-Message-State: AOJu0Yxx19lmdLzYg0h7wE5MyGkhXjmL4Bi8UswrTpWolGSbXOo1kAWQ xOFRQ1Mlyo3Zv997VNDpeB0etdcNKM8GGMcojtYZ3cqEECWJKQqqA467Hy7dBHWxgXdVAZJ7bPt FX7RfkRwWLwojeRXayG3BPdMdNaZcYJ89K099Jg== X-Google-Smtp-Source: AGHT+IFM2e6KeyuiMDLqxycUojt02VdH+rm+iHu3K+tnBqw9pzAEUVRf5SsdUcF0xgYDCB5n+exrwO1T+sS2NaqjfMM= X-Received: by 2002:ac8:7e86:0:b0:42e:f7cf:ff98 with SMTP id w6-20020ac87e86000000b0042ef7cfff98mr7140911qtj.16.1709761602628; Wed, 06 Mar 2024 13:46:42 -0800 (PST) MIME-Version: 1.0 References: <20240305030516.41519-1-alexei.starovoitov@gmail.com> <20240305030516.41519-3-alexei.starovoitov@gmail.com> In-Reply-To: From: Pasha Tatashin Date: Wed, 6 Mar 2024 16:46:05 -0500 Message-ID: Subject: Re: [PATCH v4 bpf-next 2/2] mm: Introduce VM_SPARSE kind and vm_area_[un]map_pages(). To: Alexei Starovoitov Cc: bpf , Daniel Borkmann , Andrii Nakryiko , Linus Torvalds , Barret Rhoden , Johannes Weiner , Lorenzo Stoakes , Andrew Morton , Uladzislau Rezki , Christoph Hellwig , Mike Rapoport , Boris Ostrovsky , sstabellini@kernel.org, Juergen Gross , linux-mm , xen-devel@lists.xenproject.org, Kernel Team Content-Type: text/plain; charset="UTF-8" > > This interface and in general VM_SPARSE would be useful for > > dynamically grown kernel stacks [1]. However, the might_sleep() here > > would be a problem. We would need to be able to handle > > vm_area_map_pages() from interrupt disabled context therefore no > > sleeping. The caller would need to guarantee that the page tables are > > pre-allocated before the mapping. > > Sounds like we'd need to differentiate two kinds of sparse regions. > One that is really sparse where page tables are not populated (bpf use case) > and another where only the pte level might be empty. > Only the latter one will be usable for such auto-grow stacks. > > Months back I played with this idea: > https://git.kernel.org/pub/scm/linux/kernel/git/ast/bpf.git/commit/?&id=ce63949a879f2f26c1c1834303e6dfbfb79d1fbd > that > "Make vmap_pages_range() allocate page tables down to the last (PTE) level." > Essentially pass NULL instead of 'pages' into vmap_pages_range() > and it will populate all levels except the last. Yes, this is what is needed, however, it can be a little simpler with kernel stacks: given that the first page in the vm_area is mapped when stack is first allocated, and that the VA range is aligned to 16K, we actually are guaranteed to have all page table levels down to pte pre-allocated during that initial mapping. Therefore, we do not need to worry about allocating them later during PFs. > Then the page fault handler can service a fault in auto-growing stack > area if it has a page stashed in some per-cpu free list. > I suspect this is something you might need for > "16k stack that is populated on fault", > plus a free list of 3 pages per-cpu, > and set_pte_at() in pf handler. Yes, what you described is exactly what I am working on: using 3-pages per-cpu to handle kstack page faults. The only thing that is missing is that I would like to have the ability to call a non-sleeping version of vm_area_map_pages(). Pasha From xen-devel-bounces@lists.xenproject.org Wed Mar 06 22:05:12 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 22:05:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689537.1074621 (Exim 4.92) (envelope-from ) id 1rhzNp-0006sU-GU; Wed, 06 Mar 2024 22:05:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689537.1074621; Wed, 06 Mar 2024 22:05:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhzNp-0006sN-Du; Wed, 06 Mar 2024 22:05:05 +0000 Received: by outflank-mailman (input) for mailman id 689537; Wed, 06 Mar 2024 22:05:04 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhzNo-0006sH-SS for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 22:05:04 +0000 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on20600.outbound.protection.outlook.com [2a01:111:f403:2412::600]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 93cea14b-dc05-11ee-a1ee-f123f15fe8a2; Wed, 06 Mar 2024 23:05:02 +0100 (CET) Received: from MN0PR12MB6101.namprd12.prod.outlook.com (2603:10b6:208:3cb::10) by CYXPR12MB9278.namprd12.prod.outlook.com (2603:10b6:930:e5::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7339.39; Wed, 6 Mar 2024 22:04:58 +0000 Received: from MN0PR12MB6101.namprd12.prod.outlook.com ([fe80::dcf1:946c:3879:5765]) by MN0PR12MB6101.namprd12.prod.outlook.com ([fe80::dcf1:946c:3879:5765%4]) with mapi id 15.20.7339.035; Wed, 6 Mar 2024 22:04:57 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 93cea14b-dc05-11ee-a1ee-f123f15fe8a2 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ip1jrczsOLPsvsrj5u2d782eoljZdoFc80qAsc1hPCA3yP/TorirlmkbbNiFs1OSq/FWGVcaoEp1yJUi1ItD/2bu8LjId1yXdbu6OeH9AkcHUlE0GAwiy20XBuPz2fzuHuEw2jQlo/CKdqpGnWd8Rz5aHmLHgyjbOfvC9oo+4NZhX8KcYAA6ZC8VPDiokGyqp5qPGpu4VrlIoYESfzzoneb1BpitHeiocizAXOvd/YW4yW1E+i9eJOi+lTwe2NDFBsM5NXXFpjlTh8hEF+QTAEnXQGbx3o6JG7/Ez/nPYeMBKZlfEHZE43YjEnLOx9DJZYMO+/Un02aMax4z0m3k4g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=HNKQ2BtUCgV7nAkl0lAO02dCSCRS3Cbf7EoQOeptuC8=; b=HxaPcL1FB+nKEI/WdREuBhamt4+z46e9QT1JEE5/7Iciv1qVx1b/SG6o7fMCtscDRYhRFede8YAAjVMnT/uNz4CjD+HuYm0qmx6eF/HFpFqm4Gw15CQctB4wZeDMVa5HAaXwDmdblhRu9x7fecpyBODuEdW/ZFl601gw36GPOXDp2/QNbK4jUVIaZmd8TGEhehRuHUThyefRmrwxxJ1E3LSQyISgiN1GuYDrcpJAdgrHVRqVa9QoBRWOXDrlHFWwdw8RI5kAMdkiEL1dPgT1rsKHaqHU41TizhxRSAOfngvIgXFg/wAHE/9V6JgHSKeLJccAffoH3KGQTbAVEQZRBQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HNKQ2BtUCgV7nAkl0lAO02dCSCRS3Cbf7EoQOeptuC8=; b=04Xaath8yK5kGwIN18b1m0Ww6hZ0JOjPri4aKxNVbPUbKggUTEPWv6lZVEbjL/SvvmusFbehyfkNl7hU6K5bVmhIcTe753f2xkVnTcsXABKd2Sopx33cQea+StYa7Eo6CU5Dct/42xyNI1rBkk6AzBSydMqFCHxwu6Apj4HXTss= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; Message-ID: Date: Wed, 6 Mar 2024 16:04:55 -0600 User-Agent: Mozilla Thunderbird Subject: Re: [BUG]i2c_hid_acpi broken with 4.17.2 on Framework Laptop 13 AMD Content-Language: en-US To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= Cc: =?UTF-8?Q?S=C3=A9bastien_Chaumat?= , "xen-devel@lists.xenproject.org" , Jan Beulich , Juergen Gross References: <19852f4d-fbeb-4314-a2cb-ab3f05da13ba@amd.com> <7c2f9983-a0b5-41f7-81cb-f196787f3dfb@amd.com> <2a609713-3eec-438e-80af-c1dfcfe598c4@amd.com> From: Mario Limonciello In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: SA0PR11CA0049.namprd11.prod.outlook.com (2603:10b6:806:d0::24) To MN0PR12MB6101.namprd12.prod.outlook.com (2603:10b6:208:3cb::10) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MN0PR12MB6101:EE_|CYXPR12MB9278:EE_ X-MS-Office365-Filtering-Correlation-Id: 1bc09eb4-8383-4ea3-240d-08dc3e29762c X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: vPrbTWUtXCXTqo4z8x6ZyVhrlno1V7ts7GbAoQ61yHP1LN9+wRR9lk+yDtZ14mWjqONFaMR5vwTY/lJSuKO9XcL0Ykfr5Qmqy51sMfiQMo4dLM+QX6lOVd/KLEAZZCUyw5llu1UtN8ceKHOiMZUnbpHyT8ulbP+3cRlv9zdmwBxgVxQqc+DT98XZKmR1ksJcvAGlEgQVX4xxmLcaAAPv0ZXR7Li1QECycAAmV2se2q+zCh1hv35q9H0nKh16qb7ACfC+N78JjXoXbJogUpGe0Awy4uttJC+N09yGEKrt608VDNUQ6qYj5rcZEodCz51OwiBRwloxDBaE64hi+XfeYlznU54mGkHBOQTHJBx7C7C9/cdX9z4Yt9oqtRMHwuqkWT4Fa0C9lQ+/8Q/BUCnCpMqWymHEGKT3V1h4eL5KTUF/+CBhIi0HzFW8oNJ1OTllzcz3WmpwMoUA2GjmKbB79fA9dhnEkFeyj4JI8k3DHGoyB+oeyYYDJRU8j3BGXe/wVBfIhs2/LxFzfT408pLHGQr2+T7IAC7HkZBR3ABFx3dvDFFDBDxi54ijRRsrJ4+IyWLZz0WR1xfJYKZV+rCcOIgEKHdfn3ObwvAW7P3z8mo= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MN0PR12MB6101.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(376005);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ZHM5dy9CSnE4N1hTZHg4ZTA2VmJTcFltQUp5ZVArS2EzODJkOHg4elRxNTVv?= =?utf-8?B?VFIzRkxsM3Jzems2Ryt0bHNzajEzYUlaSzZ3OHQ4UmRVZDM0TzdIZVJ3bkZo?= =?utf-8?B?NGVHeFUzUXBZQVlCalhaTUkrQXF0YkJNY1o4OERpM0xHa25wb2lKaGdMY29s?= =?utf-8?B?aUR4UVBmQzZwaDE5OUM1V2pZM0FYRFVQdW5tdCtBV3JFeExTMHIzOXl6OUR3?= =?utf-8?B?NkwyWHBhTTBkeGtyMVU1dVpUQ0ZFWUtZOXh2VzNsRTVtOXRjZFExRWhoY0hm?= =?utf-8?B?cUVSYkVESTVDamVkaE1ZOXpZanpsVkNueThmUWhYbDIzTGFaR1BSTURzMWpZ?= =?utf-8?B?SmVBQWR3UVUwWEV0enJjYkN4OFB4VUlvRHF4VGRxNHkyV3E2WGs0b3RQbmxn?= =?utf-8?B?OGpwRmFXQW9pazFER2RDOEM0SlEraElaZUlNU1BXa0tjd2pTUHUzeCtKTmMv?= =?utf-8?B?L2s0cVZkektNd3VzY0lCK2NFZGxBSm9IdEViN0JPSWtGNlpZVS9GTGlwdFZS?= =?utf-8?B?S3N1NzN0MUQxUnV0RHJHOWFDaUx5Z0NxVXNNTXZQdWI4L3gxUU5pRWU5NEZW?= =?utf-8?B?SGxCZXFGRng1V09xcjZGWHFvMDRCMTZWelBmRnZhSGJvd1owdWFqOUZpYjJC?= =?utf-8?B?N09YbDduZkhxeDZ0WXc2NlRZRm95dFBVRHVWNXFGTFliMmpramZNazlmK2NE?= =?utf-8?B?ci9zUXA5YmhJbDB1bTUwVFFzK01RZEIrTDRHU2thNGlzREE5NmxvL0xpdThh?= =?utf-8?B?N3VmYmFmQ0xaRU1FVmt6T3lvQkVkS3k4dGNzSjhpTmNwSGlaakFoWTlOUElp?= =?utf-8?B?UlB0eXZlWndPS3dZQU5GcW5LTnhVYkJsMWpIMWlJQmY2Z0JnYzl1M0RKbndD?= =?utf-8?B?N0MyQ2l5a0dWaklxemVCTGJNQklvMkR3ZUxsdFdOeEVTOFZGcWFqRFo5QjQ0?= =?utf-8?B?a1hiMDNJeit6aHZvbmJpaEI5a24vU1RsdWZUZHRTL0hGV1RYR2N1Q2V4QlpU?= =?utf-8?B?VEJiRUhTR2ZRT1NjY1BsdzBXWUo1Wmgvamczak41dVdOait6QmkrUHdxMjNx?= =?utf-8?B?RkRFWVFPdzJIVEZSanVnUW5BU3pKZUVvUCtqQXRHdnU5VHhPNXNWdDFYYVFl?= =?utf-8?B?N1FLQXBRU0J2RWU0TEI4cWNQemlrK3JGR0ttNVFZMkt0cERaMHhGaWhqdHdC?= =?utf-8?B?SDVSd2VFQUhqbEVjaElYOEg2QVdoSVVBcE1IQU9nZ0NQcTgyZ2ZOdm8wamhx?= =?utf-8?B?UG9XRy9SRHQ2RDhmU2tYYWFIeXNDWGFlZ0lidnc5NnVYVG05Y3Q4UFE5RjRy?= =?utf-8?B?cEdGbDV2bnA1bFdWQngvUFRuUjM2amZsL2pDb00xdHlTaTlkRFhuaXF4cWMz?= =?utf-8?B?OUdudlhXaEpaL1lRWm9FeTVoWjJqNmpSVkpYM1ZuVkVLa1VWTVlzSmhPeVg4?= =?utf-8?B?cU4yak1QZnhzeVgrbXhHcHByVGdRQ1hLVjF2L1g5Ry9YOUNtYktIQlNSaUhZ?= =?utf-8?B?dWdLZkRtTjlrWFNxZmhSemhRTWhDOVROc2NkbHozRnA2cXQ2WUdERkQzbW13?= =?utf-8?B?WXNOT3hXTXM5OHVYWW1Vb3NrWWNJMEtoeGdGSTRSV05xYXVHOHRpRmgyMUMr?= =?utf-8?B?Z3B4RkM5WlF0ZU1tbUJlaittby9QbGN3c20xUHdZN3pPaHhnNzZ6WGY4VldK?= =?utf-8?B?c1IvUUM5MVd4U1MwRHlBaXlUZXhzdSt5dTg2OVZiQ2l0WDk4SS94S0x3aVho?= =?utf-8?B?czQvdkdEOFcwaG1ES2prWGdRUmpNODBYRDZzbUVJWDNIVmpneFN4cHdjT0Ft?= =?utf-8?B?WDNHMyt2ZFdtUmlsOWZnZVJLc1UrNXZNTEx6R0MxeW9pcWxGb3FxMmNhQUow?= =?utf-8?B?dlVqM3EwQS93S3NpMEpkRHcvZWpNVmFWT0VkbWNrTlpLMzZnVWRTYmJXOER0?= =?utf-8?B?RFVqcGIvTTYvSUlKNEFLQW1XRDVzUXV4NitsbVdlZFllV2JvZTlOMS9XalVO?= =?utf-8?B?Z0xsdVIzNVppSUV4bVRrUjZzWmtWZFE2cTEzV0g4ZFFSc3BVSlZIejFFbkE5?= =?utf-8?B?YlJKL1FzWnBkRjZzT1NiTHpIcmJEMUlqbkp3Uk9ZU09LaWNjUW5UN1FsN2pt?= =?utf-8?Q?S0Xhwerre4Zg2m4IgOYN5v5kt?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1bc09eb4-8383-4ea3-240d-08dc3e29762c X-MS-Exchange-CrossTenant-AuthSource: MN0PR12MB6101.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Mar 2024 22:04:57.8637 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: ZZiJu7SgXKIa7C6clVuFjyJRzEEH+zCao+TNjRXcDcLl/njEwi7zn3wHSaMnzfSsgfJA3NB2bnzIJ2eZSIucGw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CYXPR12MB9278 On 3/6/2024 15:31, Marek Marczykowski-Górecki wrote: > On Wed, Mar 06, 2024 at 02:37:20PM -0600, Mario Limonciello wrote: >> On 3/6/2024 14:34, Sébastien Chaumat wrote: >>> >>> >>> Le mer. 6 mars 2024 à 19:51, Mario Limonciello >>> > a écrit : >>> >>> On 3/6/2024 12:49, Sébastien Chaumat wrote: >>> > >>> > >>> > Le mer. 6 mars 2024 à 19:08, Mario Limonciello >>> > >>> >> >> a écrit : >>> > >>> >     On 3/6/2024 12:05, Sébastien Chaumat wrote: >>> >      > >>> >      > >>> >      > Le mer. 6 mars 2024 à 18:33, Mario Limonciello >>> >      > >> >      >     Also; I'd be really interested to hear what happens with >>> >     s2idle with >>> >      >     Xen >>> >      >     now (if it works). >>> >      > >>> >      > >>> >      > suspend to RAM now works :) >>> > >>> >     Do you see /sys/power/suspend_stats/last_hw_sleep increasing >>> with your >>> >     suspend cycle? >>> > >>> > >>> > No,  it does not increase (0). >>> > >>> >>> OK, then in that case I suggest you run >>> https://gitlab.freedesktop.org/drm/amd/-/blob/master/scripts/amd_s2idle.py >>> in the hypervisor to find out what's wrong. >>> >>> >>> It fails with xen (not bare metal) during the prerequisite tests : >>> >> >> The script might need some modifications for tests that don't make sense in >> the context of Xen. >> >>> ✅ GPIO driver `pinctrl_amd` available >>> Traceback (most recent call last): >>>   File "/home/sch/Downloads/amd_s2idle.py", line 2447, in >>>     test = app.prerequisites() >>>            ^^^^^^^^^^^^^^^^^^^ >>>   File "/home/sch/Downloads/amd_s2idle.py", line 1938, in prerequisites >>>     if not check(): >>>            ^^^^^^^ >>>   File "/home/sch/Downloads/amd_s2idle.py", line 826, in check_msr >>>     val = read_msr(reg, 0) >>>           ^^^^^^^^^^^^^^^^ >>>   File "/home/sch/Downloads/amd_s2idle.py", line 813, in read_msr >>>     val = struct.unpack("Q", os.read(f, 8))[0] >>>                              ^^^^^^^^^^^^^ >>> OSError: [Errno 5] Input/output error >>> >>> Last line in the log is : >>> 2024-03-06 21:29:33,146 DEBUG: Lockdown: [none] integrity confidentiality >>> >> >> Do you have userspace MSR support compiled in? If not; that could explain >> that problem. But it's very unlikely you changed the MSRs. >> For the purpose of finding where the suspend problem is, I'd comment out >> that specific check for now. > > The s2idle isn't supported in Xen yet. Only S3 is. In fact, I have some > work-in-progress patches for that, I may try testing them on this > system. > OK; the "most important parts" I want to point out that are on bare metal and might not be obvious: * Infra from drivers/acpi/x86/s2idle.c * amd-pmc driver * USB4 driver (thunderbolt.ko) * NVME needs to use "simple suspend" FYI - I'm going to be MIA for a while on personal leave starting this weekend, please keep me on CC on your progress and if you need help when I get back from my leave I'll comment on it. From xen-devel-bounces@lists.xenproject.org Wed Mar 06 22:10:23 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 22:10:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689541.1074632 (Exim 4.92) (envelope-from ) id 1rhzSt-0000LD-6f; Wed, 06 Mar 2024 22:10:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689541.1074632; Wed, 06 Mar 2024 22:10:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhzSt-0000L6-3U; Wed, 06 Mar 2024 22:10:19 +0000 Received: by outflank-mailman (input) for mailman id 689541; Wed, 06 Mar 2024 22:10:17 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhzSr-0000Kz-GQ for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 22:10:17 +0000 Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [2a00:1450:4864:20::230]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 50134a3b-dc06-11ee-afda-a90da7624cb6; Wed, 06 Mar 2024 23:10:16 +0100 (CET) Received: by mail-lj1-x230.google.com with SMTP id 38308e7fff4ca-2d23114b19dso1730291fa.3 for ; Wed, 06 Mar 2024 14:10:16 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 50134a3b-dc06-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709763016; x=1710367816; darn=lists.xenproject.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=5NWQLEqonMDh6NG/69B8NbTTnAVl5rzcZuafQfgUDI4=; b=nn1JMGGqXl13Le2m3ztpJTtP9NVtFFKHN3q6W+eJzLg9UYoaLEY3eHYrdPHcDxfmVR gt5bOvvR06NWkAUQ+7yfPjEtmdHArk5Vde5NR6C64nGZ3fMzW/Srry+yjN6ILg3/p054 z4bOWkPk5jazb6u1JA/6tIWu07HEZHzpNg0kHoisCLKqwPzgijx4QTdppltAFA4KCI7L P99xGi+bsp9EtotYjo6fuczfsINIsvUJOZH44IqhSde36YPy4MFLtGDA+W5N4V7N6U83 QeyMjGX5oSUYEYmGgPqzXTBeMvlolq/Dag/YycD4s7xmX5pQUMkja7tuKgUfnns66PX2 UOhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709763016; x=1710367816; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=5NWQLEqonMDh6NG/69B8NbTTnAVl5rzcZuafQfgUDI4=; b=MFoC2FBhHvA9RLLgXJemtL8a/X4YOcc2jUIzaeaNv6aWQILZGxDl6tMJi2VT0L1/zw otwe6boSjetnH7kBXshN0EyF9lNrhUxYqhyzBiRV+x/c9Uy0y7/HCavAy3mbQx7PL3ZJ hFu6jqyBlk4dTTvaC48T/HPMpqF1R0uMxsWIGwcaQ1laBjffblgRU+K1TuaeTgxcBWyQ bHdfqCmvH/HjFCyjiUMex0HWVUir3gkXO0vmi/Xd4yZ6q7tcyuIaZ/MMUVSMoVjWRKjx +dIt/kKTe8cziSAeC6G2scvtK4EAHP8KUSJZsYeVWs9H0u56+ClTFWMqYvq10jObwKo9 mLJg== X-Forwarded-Encrypted: i=1; AJvYcCU0Ij+Bb0TVQ96a/FUP+U/HtE6gNsRv0Bhvtp1L0Btnf/E5VFl4bsvfmm+A91gcxD9TzjYTSYXUq6UBd/zDNZCGpoWfj/D3GEDmnTU+AJE= X-Gm-Message-State: AOJu0YxL4UYXo1HDAq/Hh8hO4pn/edNTiEPEtxWx/e5oJuUqIPasx6p6 9Wg7dr2SRbhIp43tjHW4mquYATWpe0eKknJQqau3FNYrWuyB+s1uOSCDkrOQFCQSPJPjzR38vwD eZViLYI7wDuS9sRSWaBE7FAxonJs= X-Google-Smtp-Source: AGHT+IHPYB76mbDiS/XUTfkWHqwmL3kNzF5N+JY1DdNyjqhyY9qaowtzw4PJGridxk6QtBmqFNmFr9mJ/1Htw/GughA= X-Received: by 2002:a05:651c:220c:b0:2d2:d9b2:b2fc with SMTP id y12-20020a05651c220c00b002d2d9b2b2fcmr208065ljq.11.1709763015872; Wed, 06 Mar 2024 14:10:15 -0800 (PST) MIME-Version: 1.0 References: <79ed633d-b0bd-4a7d-a0c6-37a034e1ee96@suse.com> <0374516c-b5fa-4880-a07a-0b788f491e9a@xen.org> <271ae402-7400-4dc5-9222-88523b9a2922@suse.com> In-Reply-To: <271ae402-7400-4dc5-9222-88523b9a2922@suse.com> From: Christopher Clark Date: Wed, 6 Mar 2024 14:10:03 -0800 Message-ID: Subject: Re: Ping: [PATCH v2] Argo: don't obtain excess page references To: Jan Beulich , Julien Grall Cc: Andrew Cooper , George Dunlap , Stefano Stabellini , Wei Liu , "xen-devel@lists.xenproject.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Feb 28, 2024 at 6:52=E2=80=AFAM Jan Beulich wro= te: > > On 18.02.2024 19:01, Julien Grall wrote: > > On 14/02/2024 10:12, Jan Beulich wrote: > >> find_ring_mfn() already holds a page reference when trying to obtain a > >> writable type reference. We shouldn't make assumptions on the general > >> reference count limit being effectively "infinity". Obtain merely a ty= pe > >> ref, re-using the general ref by only dropping the previously acquired > >> one in the case of an error. > >> > >> Signed-off-by: Jan Beulich > > > > Reviewed-by: Julien Grall > > I'll give it till the end of the week for an ack to arrive (or a substant= ial > objection), and commit some time next week in the absence of any response= . I haven't gotten to this as quickly as I'd hoped for, sorry, but I've given reference to this thread to some of the downstream argo users / developers to see if there can be attention available and I'll be attending the Community Call. Christopher > > Jan > From xen-devel-bounces@lists.xenproject.org Wed Mar 06 22:13:11 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 22:13:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689546.1074643 (Exim 4.92) (envelope-from ) id 1rhzVd-0001Ln-Mt; Wed, 06 Mar 2024 22:13:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689546.1074643; Wed, 06 Mar 2024 22:13:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhzVd-0001Lg-Gv; Wed, 06 Mar 2024 22:13:09 +0000 Received: by outflank-mailman (input) for mailman id 689546; Wed, 06 Mar 2024 22:13:07 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rhzVb-0001LY-Js for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 22:13:07 +0000 Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [2a00:1450:4864:20::335]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id b543d8f8-dc06-11ee-afda-a90da7624cb6; Wed, 06 Mar 2024 23:13:06 +0100 (CET) Received: by mail-wm1-x335.google.com with SMTP id 5b1f17b1804b1-412ed3f1e3fso2395465e9.0 for ; Wed, 06 Mar 2024 14:13:06 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b543d8f8-dc06-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709763186; x=1710367986; darn=lists.xenproject.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=0co437MWlwiDr7sdvNxT0czQBG4oFsy/9/ksjHplhkY=; b=FGVcd0x81Fnv9hAhvFVskuJDt1v3kyKbhSO7/2DiOVxKqI9QMzw46m71fRD4U5SzQj 3O4kMIJ7trI/lqRQVRfh3x95A2YvHdwHBcCvATdp2T+X52Ruv1IrIp/EwPUD6AY27WUZ fbhUobMkEC0V8/EWqz+eb59rw1ib0liOzukQMQTRbAkclYpCogKJZFv5/9z9Ot5qtTCE diTtXXamLqD6NIK1ZMKREDNY9/M8axfTlChaZFL5v/vRw3+aT1zk8weS4I8U+uLl5oua WIBmEmK+07NfIQ3VW5bgQe4bgXzBPXYc9veHcbkK14aelCMWeQJ8TOFf5nWjzTI6u1iK Q8zA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709763186; x=1710367986; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=0co437MWlwiDr7sdvNxT0czQBG4oFsy/9/ksjHplhkY=; b=UgpJO7ZMF0NN4gJ9MxvRg4pPxd0XMqgNyLVec0IbBpWuPJ5+wEnB7OyfLhfk4dNamx tCvRSdvXNmZRdtJJMid7IPnNdpz8fOYaa4raIm162dQpK9rxlrat9mqT7w5pHBMMz+1p vTS6gOaAtsg8h8GLHc8/lcxThFrw5DIwLl6eUVwVcyalgKcwdw8jweSe9pDY7FT9Y7VF Ccyko7BeI2fF6c4JZr49r8Ab6jZN2pGOAJjvv2rKNKL5eZ1qhQtXRf1CSQ74Izj6ANbd gasmwB9S+Jw75a9o7JTZRXfDDnTF812jsW/HFQ/jXmIoSpygmgUyru36iEGfXrPIXmFS 8Izw== X-Forwarded-Encrypted: i=1; AJvYcCV2jEDSj0VqSxYmXtI722AmceYFCZ7D3TNkJHbgY7icM2GGXmpk4PwBFAKEBofD/4tB+1vPejzNfSprQ1KX66axJNzlOUhSv+r2qf9sh2w= X-Gm-Message-State: AOJu0YyVeY6D0zfUH6SuKGw7WOwXyB1V41iiwK64a6Z65u4duZRg9DZV rkVeDyTVuVLnehXbZ5lf7abGy2MKoC1dxh4GsOFUTB5FIKt6IEALG5/NtVK8hohZ56iHVegePVE UPJan78SHiVwfkkWh9B/dc5aavI0= X-Google-Smtp-Source: AGHT+IHM5WAdyGr/B7hLl36s77xYo/gy7yzLMW3COR6pSamXxzxHTbpB4M1O/zLuG0Dc6UyW1yEJEoYoydHCAh4AHuk= X-Received: by 2002:a05:6000:1cd2:b0:33d:82c1:f9d3 with SMTP id bf18-20020a0560001cd200b0033d82c1f9d3mr11649861wrb.4.1709763185840; Wed, 06 Mar 2024 14:13:05 -0800 (PST) MIME-Version: 1.0 References: <20240305030516.41519-1-alexei.starovoitov@gmail.com> <20240305030516.41519-3-alexei.starovoitov@gmail.com> In-Reply-To: From: Alexei Starovoitov Date: Wed, 6 Mar 2024 14:12:54 -0800 Message-ID: Subject: Re: [PATCH v4 bpf-next 2/2] mm: Introduce VM_SPARSE kind and vm_area_[un]map_pages(). To: Pasha Tatashin Cc: bpf , Daniel Borkmann , Andrii Nakryiko , Linus Torvalds , Barret Rhoden , Johannes Weiner , Lorenzo Stoakes , Andrew Morton , Uladzislau Rezki , Christoph Hellwig , Mike Rapoport , Boris Ostrovsky , sstabellini@kernel.org, Juergen Gross , linux-mm , xen-devel@lists.xenproject.org, Kernel Team Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Mar 6, 2024 at 1:46=E2=80=AFPM Pasha Tatashin wrote: > > > > This interface and in general VM_SPARSE would be useful for > > > dynamically grown kernel stacks [1]. However, the might_sleep() here > > > would be a problem. We would need to be able to handle > > > vm_area_map_pages() from interrupt disabled context therefore no > > > sleeping. The caller would need to guarantee that the page tables are > > > pre-allocated before the mapping. > > > > Sounds like we'd need to differentiate two kinds of sparse regions. > > One that is really sparse where page tables are not populated (bpf use = case) > > and another where only the pte level might be empty. > > Only the latter one will be usable for such auto-grow stacks. > > > > Months back I played with this idea: > > https://git.kernel.org/pub/scm/linux/kernel/git/ast/bpf.git/commit/?&id= =3Dce63949a879f2f26c1c1834303e6dfbfb79d1fbd > > that > > "Make vmap_pages_range() allocate page tables down to the last (PTE) le= vel." > > Essentially pass NULL instead of 'pages' into vmap_pages_range() > > and it will populate all levels except the last. > > Yes, this is what is needed, however, it can be a little simpler with > kernel stacks: > given that the first page in the vm_area is mapped when stack is first > allocated, and that the VA range is aligned to 16K, we actually are > guaranteed to have all page table levels down to pte pre-allocated > during that initial mapping. Therefore, we do not need to worry about > allocating them later during PFs. Ahh. Found: stack =3D __vmalloc_node_range(THREAD_SIZE, THREAD_ALIGN, ... > > Then the page fault handler can service a fault in auto-growing stack > > area if it has a page stashed in some per-cpu free list. > > I suspect this is something you might need for > > "16k stack that is populated on fault", > > plus a free list of 3 pages per-cpu, > > and set_pte_at() in pf handler. > > Yes, what you described is exactly what I am working on: using 3-pages > per-cpu to handle kstack page faults. The only thing that is missing > is that I would like to have the ability to call a non-sleeping > version of vm_area_map_pages(). vm_area_map_pages() cannot be non-sleepable, since the [start, end) range will dictate whether mid level allocs and locks are needed. Instead in alloc_thread_stack_node() you'd need a flavor of get_vm_area() that can align the range to THREAD_ALIGN. Then immediately call _sleepable_ vm_area_map_pages() to populate the first page and later set_pte_at() the other pages on demand from the fault handler. From xen-devel-bounces@lists.xenproject.org Wed Mar 06 22:57:32 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 22:57:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689550.1074651 (Exim 4.92) (envelope-from ) id 1ri0CL-0001AD-SL; Wed, 06 Mar 2024 22:57:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689550.1074651; Wed, 06 Mar 2024 22:57:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ri0CL-0001A6-PJ; Wed, 06 Mar 2024 22:57:17 +0000 Received: by outflank-mailman (input) for mailman id 689550; Wed, 06 Mar 2024 22:57:17 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ri0CK-0001A0-SV for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 22:57:16 +0000 Received: from mail-yw1-x1132.google.com (mail-yw1-x1132.google.com [2607:f8b0:4864:20::1132]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id df88148e-dc0c-11ee-afda-a90da7624cb6; Wed, 06 Mar 2024 23:57:15 +0100 (CET) Received: by mail-yw1-x1132.google.com with SMTP id 00721157ae682-60974cb1cd7so2862787b3.3 for ; Wed, 06 Mar 2024 14:57:14 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: df88148e-dc0c-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen-com.20230601.gappssmtp.com; s=20230601; t=1709765834; x=1710370634; darn=lists.xenproject.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=b4Nw3ruzCEh/6x6lraL5DkvfsiMjEFZksiQV2YYXotE=; b=F02zoOHROBzv5yu73P3nt+hRge0s/6tVRpIZtCrTyQX42dbPrO8syrXp+s0sWrZ8tI 5GyKaZNypPhGQCQ11tqkn+HG7nuOZXlxm0M6ZxdvYP+E3sKD/8NLs7DU159cYYUHiEmg I1ZU+y7Nm2WvqPGJFb7Gjkga5VaoQQWiJb6vPLW3ofTUHIZ6Bd5xSsf3xEgLIL+xzVzd 7DnuNYfOXDobzgXL3NAzeiV6HT+IeuEP0Z4nF/DPWqe3NMN2W52Xod17yNGbM9TzhUhf 5hjBNLlcgcScjD7E+m/v9U58umLKe/IWJzTLfqFOeoKRu7UYBh+s5bJnzrzWZGKZUMI4 P2yQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709765834; x=1710370634; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=b4Nw3ruzCEh/6x6lraL5DkvfsiMjEFZksiQV2YYXotE=; b=uLXxN33BvycF/CrqhBhLE6rV2FmufgMuzzPQKiWIjlboLa51Mv0lqmvvrX8K7EEzWn WOHk/E7FCSNmAhGQZPJRmKDHJWjYgQ1jrNJWAkafWBaDH5Y++Jny+yHrhIIudNRFfw2i TFC0MPz36CKa7hgvmOMCxWtyxF5UsxucDDKg2G1qK582wQj8IdOv0G9L62etVJORiGU6 d1WMAPzj2xPdDJ8ayyR/IlewkZqpAZGw1FikQjvI+ck5ttq7hyZ4LU8E9sK3JrXYf4qi QS6fecApZK/DoVd0V4qOX42hWpI37ZcwoUhhYeZDvKSavYtwoc2gH6sInfRGO4+c1KU5 5I4w== X-Forwarded-Encrypted: i=1; AJvYcCVkW3JSwlaPY0UppRs4BarF+8T5qu+gyfR1Q9aYn4W6g2D11TuFSKPM68wxT1gjgQOJvJ+tCy33nRvd4UykeUznF7gjxkRYwbQxLropyqc= X-Gm-Message-State: AOJu0YzUYkMo2rUX39S0Por0JlK/fYrMIU3upsVb/i2Vq8PUODUK/7w4 SZ8bKEwvziKvuh/bA1+bxhGAR1lwZlKjFUBCOKJs61BZMhjrASv+pBG1zI4AsfXPB7ogp7cZMux btsaxk00Vi/7ENTodT8qFUA21j/UkZ9ouyYsyTg== X-Google-Smtp-Source: AGHT+IHwPxKVjGasXZN3AkdEcSPiwiOeknvDH42CBz2GEXFk4GNpppovu9J9FQrbuAW73ifV1XqA6uY12hiEUCXFYQw= X-Received: by 2002:a25:5186:0:b0:dcc:99b6:830b with SMTP id f128-20020a255186000000b00dcc99b6830bmr13006393ybb.19.1709765833765; Wed, 06 Mar 2024 14:57:13 -0800 (PST) MIME-Version: 1.0 References: <20240305030516.41519-1-alexei.starovoitov@gmail.com> <20240305030516.41519-3-alexei.starovoitov@gmail.com> In-Reply-To: From: Pasha Tatashin Date: Wed, 6 Mar 2024 17:56:37 -0500 Message-ID: Subject: Re: [PATCH v4 bpf-next 2/2] mm: Introduce VM_SPARSE kind and vm_area_[un]map_pages(). To: Alexei Starovoitov Cc: bpf , Daniel Borkmann , Andrii Nakryiko , Linus Torvalds , Barret Rhoden , Johannes Weiner , Lorenzo Stoakes , Andrew Morton , Uladzislau Rezki , Christoph Hellwig , Mike Rapoport , Boris Ostrovsky , sstabellini@kernel.org, Juergen Gross , linux-mm , xen-devel@lists.xenproject.org, Kernel Team Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Mar 6, 2024 at 5:13=E2=80=AFPM Alexei Starovoitov wrote: > > On Wed, Mar 6, 2024 at 1:46=E2=80=AFPM Pasha Tatashin wrote: > > > > > > This interface and in general VM_SPARSE would be useful for > > > > dynamically grown kernel stacks [1]. However, the might_sleep() her= e > > > > would be a problem. We would need to be able to handle > > > > vm_area_map_pages() from interrupt disabled context therefore no > > > > sleeping. The caller would need to guarantee that the page tables a= re > > > > pre-allocated before the mapping. > > > > > > Sounds like we'd need to differentiate two kinds of sparse regions. > > > One that is really sparse where page tables are not populated (bpf us= e case) > > > and another where only the pte level might be empty. > > > Only the latter one will be usable for such auto-grow stacks. > > > > > > Months back I played with this idea: > > > https://git.kernel.org/pub/scm/linux/kernel/git/ast/bpf.git/commit/?&= id=3Dce63949a879f2f26c1c1834303e6dfbfb79d1fbd > > > that > > > "Make vmap_pages_range() allocate page tables down to the last (PTE) = level." > > > Essentially pass NULL instead of 'pages' into vmap_pages_range() > > > and it will populate all levels except the last. > > > > Yes, this is what is needed, however, it can be a little simpler with > > kernel stacks: > > given that the first page in the vm_area is mapped when stack is first > > allocated, and that the VA range is aligned to 16K, we actually are > > guaranteed to have all page table levels down to pte pre-allocated > > during that initial mapping. Therefore, we do not need to worry about > > allocating them later during PFs. > > Ahh. Found: > stack =3D __vmalloc_node_range(THREAD_SIZE, THREAD_ALIGN, ... > > > > Then the page fault handler can service a fault in auto-growing stack > > > area if it has a page stashed in some per-cpu free list. > > > I suspect this is something you might need for > > > "16k stack that is populated on fault", > > > plus a free list of 3 pages per-cpu, > > > and set_pte_at() in pf handler. > > > > Yes, what you described is exactly what I am working on: using 3-pages > > per-cpu to handle kstack page faults. The only thing that is missing > > is that I would like to have the ability to call a non-sleeping > > version of vm_area_map_pages(). > > vm_area_map_pages() cannot be non-sleepable, since the [start, end) > range will dictate whether mid level allocs and locks are needed. > > Instead in alloc_thread_stack_node() you'd need a flavor > of get_vm_area() that can align the range to THREAD_ALIGN. > Then immediately call _sleepable_ vm_area_map_pages() to populate > the first page and later set_pte_at() the other pages on demand > from the fault handler. We still need to get to PTE level to use set_pte_at(). So, either store it in task_struct for faster PF handling, or add another non-sleeping vmap function that will do something like this: vm_area_set_page_at(addr, page) { pgd =3D pgd_offset_k(addr) p4d =3D vunmap_p4d_range(pgd, addr) pud =3D pud_offset(p4d, addr) pmd =3D pmd_offset(pud, addr) pte =3D pte_offset_kernel(pmd, addr) set_pte_at(init_mm, addr, pte, mk_pte(page...)); } Pasha From xen-devel-bounces@lists.xenproject.org Wed Mar 06 22:57:59 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 22:57:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689552.1074663 (Exim 4.92) (envelope-from ) id 1ri0D1-0001cv-66; Wed, 06 Mar 2024 22:57:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689552.1074663; Wed, 06 Mar 2024 22:57:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ri0D1-0001co-1f; Wed, 06 Mar 2024 22:57:59 +0000 Received: by outflank-mailman (input) for mailman id 689552; Wed, 06 Mar 2024 22:57:57 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ri0Cz-0001cc-KG for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 22:57:57 +0000 Received: from mail-yw1-x1131.google.com (mail-yw1-x1131.google.com [2607:f8b0:4864:20::1131]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id f752c0f9-dc0c-11ee-a1ee-f123f15fe8a2; Wed, 06 Mar 2024 23:57:54 +0100 (CET) Received: by mail-yw1-x1131.google.com with SMTP id 00721157ae682-6099703e530so2757627b3.3 for ; Wed, 06 Mar 2024 14:57:54 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f752c0f9-dc0c-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen-com.20230601.gappssmtp.com; s=20230601; t=1709765874; x=1710370674; darn=lists.xenproject.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=T30BbYOoDoqevyGB85war3bXduSTpLM1AIfsEUvxyFs=; b=rpxR7IdxFinN/6nx1I4KBSLHs1xlq1uUQ+isP/ErU4++teSiqdoF3GriDxKkMYpEHL FYEwcQTWNmsAsMknVl2Xxwob9oZ8P4jSDoI/GEQT4TKWfMjfXTmA4EiWwCw9yQ7e6uoS iXeC57euSjqCD4zXkuYV79hDJpQqSPpImL/YQRkl0EN3lPTlkYu7Z+B1/++OHUVmgK08 p4Ls87NTCYJWhFcdJdzua3ApxT0QtZpUHK+91O643G+CRBCPr7ZkEwbGQN0BX0UOn0go cbyWkYHQqqmwyP12XyfZssXmUoU3DK/HYY4sdEKJsN3ErZjx1SWWJDRis9foC+iaYXWs 8t3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709765874; x=1710370674; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=T30BbYOoDoqevyGB85war3bXduSTpLM1AIfsEUvxyFs=; b=M/Xw4K5iNTU/Nv8hsgjuqI4c36e9voVmTcwBLyZ7pcFpvMwrOq1EpOwW2ZbuH+x/yQ OdpFQdCEFy2qO56HvDKNOKGh/83tLJ2SjueilSZjT5LRW72dOp7LV8kTM8tDzP827UOb y9DwsEbCOwaDCWW+oNWI4jnK4jr8O1dlD9rrr6H5WRAZa72mk2kfvsO67wqfAOkN5MiQ 1qqlLyvBRVXR0R2COSDmzPp6Bao8ftqbGhrp51W+vyNlK9Zwi5k1USGGH7DggLq1y6Rr asGPuDBDzmE1OrpXWyeFuLQarwgdZtrMyhwuDCdOROIinyTwoXcat8+u21HMgBQkw6x8 IG7Q== X-Forwarded-Encrypted: i=1; AJvYcCUsSR9UGj707VZq6LRlqXabPnn7dpyLzh3Glm5vfsdEPkn7hnvxhI6RWuXeyahBtUASpR+/1Nfs6dkXkFPCTSroFXOLiKdX3tAUz9AX4WM= X-Gm-Message-State: AOJu0YxyhbBpLIiecOI0cy0L64+dqC7ubDz9l7UOkrNdkU6tBmph4eGq crREXAGVOP+2vFS3mqGDFtbb+fbG0lbqOv8RuNuIe/lqUILG36ae/gEGKssvmfU22KJqitzuV4Y MF1/6u/m2IDsfwjSnDvnaTVPZAEVgtY7LtQNVIg== X-Google-Smtp-Source: AGHT+IH63s+eoFax9fdsbS9trqEfT/NfZeSwMdLE8iVC9tCXSyx9a+v6pqCiDdrSLUuvOaDIefTbxnfswQ7+lbT1/Qw= X-Received: by 2002:a0d:ddc7:0:b0:608:e844:4117 with SMTP id g190-20020a0dddc7000000b00608e8444117mr13169519ywe.33.1709765873400; Wed, 06 Mar 2024 14:57:53 -0800 (PST) MIME-Version: 1.0 References: <20240305030516.41519-1-alexei.starovoitov@gmail.com> <20240305030516.41519-3-alexei.starovoitov@gmail.com> In-Reply-To: <20240305030516.41519-3-alexei.starovoitov@gmail.com> From: Pasha Tatashin Date: Wed, 6 Mar 2024 17:57:16 -0500 Message-ID: Subject: Re: [PATCH v4 bpf-next 2/2] mm: Introduce VM_SPARSE kind and vm_area_[un]map_pages(). To: Alexei Starovoitov Cc: bpf@vger.kernel.org, daniel@iogearbox.net, andrii@kernel.org, torvalds@linux-foundation.org, brho@google.com, hannes@cmpxchg.org, lstoakes@gmail.com, akpm@linux-foundation.org, urezki@gmail.com, hch@infradead.org, rppt@kernel.org, boris.ostrovsky@oracle.com, sstabellini@kernel.org, jgross@suse.com, linux-mm@kvack.org, xen-devel@lists.xenproject.org, kernel-team@fb.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Mar 4, 2024 at 10:05=E2=80=AFPM Alexei Starovoitov wrote: > > From: Alexei Starovoitov > > vmap/vmalloc APIs are used to map a set of pages into contiguous kernel > virtual space. > > get_vm_area() with appropriate flag is used to request an area of kernel > address range. It's used for vmalloc, vmap, ioremap, xen use cases. > - vmalloc use case dominates the usage. Such vm areas have VM_ALLOC flag. > - the areas created by vmap() function should be tagged with VM_MAP. > - ioremap areas are tagged with VM_IOREMAP. > > BPF would like to extend the vmap API to implement a lazily-populated > sparse, yet contiguous kernel virtual space. Introduce VM_SPARSE flag > and vm_area_map_pages(area, start_addr, count, pages) API to map a set > of pages within a given area. > It has the same sanity checks as vmap() does. > It also checks that get_vm_area() was created with VM_SPARSE flag > which identifies such areas in /proc/vmallocinfo > and returns zero pages on read through /proc/kcore. > > The next commits will introduce bpf_arena which is a sparsely populated > shared memory region between bpf program and user space process. It will > map privately-managed pages into a sparse vm area with the following step= s: > > // request virtual memory region during bpf prog verification > area =3D get_vm_area(area_size, VM_SPARSE); > > // on demand > vm_area_map_pages(area, kaddr, kend, pages); > vm_area_unmap_pages(area, kaddr, kend); > > // after bpf program is detached and unloaded > free_vm_area(area); > > Signed-off-by: Alexei Starovoitov Reviewed-by: Pasha Tatashin From xen-devel-bounces@lists.xenproject.org Wed Mar 06 23:08:00 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 23:08:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689558.1074672 (Exim 4.92) (envelope-from ) id 1ri0Md-0004K0-2f; Wed, 06 Mar 2024 23:07:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689558.1074672; Wed, 06 Mar 2024 23:07:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ri0Mc-0004Jt-Uk; Wed, 06 Mar 2024 23:07:54 +0000 Received: by outflank-mailman (input) for mailman id 689558; Wed, 06 Mar 2024 23:07:53 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ri0Mb-0004Jn-LG for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 23:07:53 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ri0MR-0003qU-PL; Wed, 06 Mar 2024 23:07:43 +0000 Received: from gw1.octic.net ([88.97.20.152] helo=[10.0.1.193]) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1ri0MR-0001Gz-Hb; Wed, 06 Mar 2024 23:07:43 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID; bh=1tzl07rsQIT3k0ieYf2d585TF8knL080efVu/NGTT8c=; b=SIX03T6bVRalSaHZvFXCFdZZSV EY4+SZF0+56dGVe9OicLRCTUU/WZVWtlHR4k2/+kpzq6uol0PyyEnXoqOr2nouY2/4aokk0pr9U5E hmVL3goLnUIgbDWSrGKajXmrkfFydJ2SMuIkDkPbiPBwqdOzyxp1UFjPlX3ZLFxRlvw8=; Message-ID: Date: Wed, 6 Mar 2024 23:07:40 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] xen/arm: Add imx8q{m,x} platform glue Content-Language: en-GB To: John Ernberg , Peng Fan , Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Cc: Jonas Blixt , "xen-devel@lists.xenproject.org" References: <20240131114952.305805-1-john.ernberg@actia.se> <20240131114952.305805-2-john.ernberg@actia.se> <494d4961-ad8a-4d1d-aaa6-d1bfb9d6a137@actia.se> <167f0c7a-e037-446c-82f8-2584e35a7af1@xen.org> <012b5f83-2f9b-4477-965e-07b8506c0052@xen.org> <5a0c8f09-4f01-45e9-892c-86342c0d0ec5@xen.org> <08ae764c-3490-4dd1-ab70-7a855a98d16d@actia.se> <911ec1bb-3733-4f37-839e-673a88e408ff@actia.se> From: Julien Grall In-Reply-To: <911ec1bb-3733-4f37-839e-673a88e408ff@actia.se> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi John, > Ping on the watchdog discussion bits. Sorry for the late reply. On 06/03/2024 13:13, John Ernberg wrote: > On 2/9/24 14:14, John Ernberg wrote: >> >>>    * IMX_SIP_TIMER_*:  This seems to be related to the watchdog. >>> Shouldn't dom0 rely on the watchdog provided by Xen instead? So those >>> call will be used by Xen. >> >> That is indeed a watchdog SIP, and also for setting the SoC internal RTC >> if it is being used. >> >> I looked around if there was previous discussion and only really found [3]. >> Is the xen/xen/include/watchdog.h header meant to be for this kind of >> watchdog support or is that more for the VM watchdog? Looking at the x86 >> ACPI NMI watchdog it seems like the former, but I have never worked with >> x86 nor ACPI. include/watchdog.h contains helper to configure the watchdog for Xen. We also have per-VM watchdog and this is configured by the hypercall SCHEDOP_watchdog. >> >> Currently forwarding it to Dom0 has not caused any watchdog resets with >> our watchdog timeout settings, our specific Dom0 setup and VM count. IIUC, the SMC API for the watchdog would be similar to the ACPI NMI watchdog. So I think it would make more sense if this is not exposed to dom0 (even if Xen is doing nothing with it). Can you try to hide the SMCs and check if dom0 still behave properly? Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Wed Mar 06 23:12:15 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 23:12:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689562.1074681 (Exim 4.92) (envelope-from ) id 1ri0Qo-0006b3-LW; Wed, 06 Mar 2024 23:12:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689562.1074681; Wed, 06 Mar 2024 23:12:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ri0Qo-0006aw-Ib; Wed, 06 Mar 2024 23:12:14 +0000 Received: by outflank-mailman (input) for mailman id 689562; Wed, 06 Mar 2024 23:12:13 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ri0Qn-0006aa-0d for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 23:12:13 +0000 Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [2a00:1450:4864:20::429]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id f5cc2adb-dc0e-11ee-a1ee-f123f15fe8a2; Thu, 07 Mar 2024 00:12:11 +0100 (CET) Received: by mail-wr1-x429.google.com with SMTP id ffacd0b85a97d-33dcad9e3a2so85722f8f.3 for ; Wed, 06 Mar 2024 15:12:11 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f5cc2adb-dc0e-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709766730; x=1710371530; darn=lists.xenproject.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Jx5iRvChP8NO+/mhuLuLKmdBFsw3uQNbAw3BGNdYR3g=; b=eruK46yYo93Tga2s0NaogOzakhIgpjbZgtBBlinbLdJpSGiz6jOa6JkC3eF/QQLb6w C1eO3kAGEPiwtkUbGgaY3JEpLBD6oYz0LVelNgW/GUvdXxhm1z/xkQI0tsOXdenCqYQ2 Syg7lXZhaH/xvwAEsZeKoi7NIy+V4R/CE3tO28HzXdxCyEY/Pmy0WNoEokk3Ug1bxLAN Wlfqm1g3TgtHPhDY/Qvcq6RRh8m3w06wwHYMUc5GPCeiGNn5MVZTFqMV7yBVqhbXSlsB Zo5j3QwiM9zl1/93ZBhRUN52r5XdmCaAFOJ6FaYQbcOdzBzGBbGCIw9OD1tVbopHNZmM b82w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709766730; x=1710371530; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Jx5iRvChP8NO+/mhuLuLKmdBFsw3uQNbAw3BGNdYR3g=; b=Qvs7ofcodROuzd7R+yN/YmPUlUhy+iQL8zFWrhMJYai2faH8jXNM6Zn3Icv5CQTRR9 CfydTdxwZD7CCoa9P+WkKwh09rXq8uHcEv07mfGaPa3m1fdkVX9W9X5Npa1S301ZDPnU d+pL8vhe6Wts+qcwzznUcIiEJh0VaEcunAIT9LsS+tU4A0z5Kdj1HIezhQRrW9rpWfj9 9z5X3zewuWut69ST0j6Ti4z+lSatvc+K/k0OwhNl5fPH20N4FEm+H9gdmvWmAS8eaZnS XPQ9/LvfudwiUbVVf5PW/kDAERYHnvkYC/1NSjqVrCmxINGQBv3hco9SHVTDlk/JAA9X r2qw== X-Forwarded-Encrypted: i=1; AJvYcCUSIbwwAeqGbcqLkLVdqEI8VZyDlXwrg8PxGYgWuU9c4WEwkDA9yHRQ1+igxUd5HR6EKT/HxBPYEty7H2ChrmT47eG+6oA9+Nnqck9+8+w= X-Gm-Message-State: AOJu0YynkNQ947z7hb0lBm0luK4zkEJkK/4jQ13jMCkcn6YQ6L1G+4V8 sNyLGcRjLXNiC7hnd48MPHMgUE9YU8sQ7JsoF8K055vjyEEwJTJP/1IfF2JW0Q7YfA4NQ8oO6Hy WFdAOubZ7Sy+vZ9W+DmnC9RnwpKE= X-Google-Smtp-Source: AGHT+IGLGZhZkUQNkXFQULSBWx3zFTB/DY3Hwy4o8Qn6U6VB9fAcd5bv3pWUFD1OuIX/9JAsZj7/H8SpTHn4VXTZWJQ= X-Received: by 2002:a5d:5918:0:b0:33e:1bec:c48f with SMTP id v24-20020a5d5918000000b0033e1becc48fmr11116715wrd.24.1709766729962; Wed, 06 Mar 2024 15:12:09 -0800 (PST) MIME-Version: 1.0 References: <20240305030516.41519-1-alexei.starovoitov@gmail.com> <20240305030516.41519-3-alexei.starovoitov@gmail.com> In-Reply-To: From: Alexei Starovoitov Date: Wed, 6 Mar 2024 15:11:58 -0800 Message-ID: Subject: Re: [PATCH v4 bpf-next 2/2] mm: Introduce VM_SPARSE kind and vm_area_[un]map_pages(). To: Pasha Tatashin Cc: bpf , Daniel Borkmann , Andrii Nakryiko , Linus Torvalds , Barret Rhoden , Johannes Weiner , Lorenzo Stoakes , Andrew Morton , Uladzislau Rezki , Christoph Hellwig , Mike Rapoport , Boris Ostrovsky , sstabellini@kernel.org, Juergen Gross , linux-mm , xen-devel@lists.xenproject.org, Kernel Team Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Mar 6, 2024 at 2:57=E2=80=AFPM Pasha Tatashin wrote: > > On Wed, Mar 6, 2024 at 5:13=E2=80=AFPM Alexei Starovoitov > wrote: > > > > On Wed, Mar 6, 2024 at 1:46=E2=80=AFPM Pasha Tatashin wrote: > > > > > > > > This interface and in general VM_SPARSE would be useful for > > > > > dynamically grown kernel stacks [1]. However, the might_sleep() h= ere > > > > > would be a problem. We would need to be able to handle > > > > > vm_area_map_pages() from interrupt disabled context therefore no > > > > > sleeping. The caller would need to guarantee that the page tables= are > > > > > pre-allocated before the mapping. > > > > > > > > Sounds like we'd need to differentiate two kinds of sparse regions. > > > > One that is really sparse where page tables are not populated (bpf = use case) > > > > and another where only the pte level might be empty. > > > > Only the latter one will be usable for such auto-grow stacks. > > > > > > > > Months back I played with this idea: > > > > https://git.kernel.org/pub/scm/linux/kernel/git/ast/bpf.git/commit/= ?&id=3Dce63949a879f2f26c1c1834303e6dfbfb79d1fbd > > > > that > > > > "Make vmap_pages_range() allocate page tables down to the last (PTE= ) level." > > > > Essentially pass NULL instead of 'pages' into vmap_pages_range() > > > > and it will populate all levels except the last. > > > > > > Yes, this is what is needed, however, it can be a little simpler with > > > kernel stacks: > > > given that the first page in the vm_area is mapped when stack is firs= t > > > allocated, and that the VA range is aligned to 16K, we actually are > > > guaranteed to have all page table levels down to pte pre-allocated > > > during that initial mapping. Therefore, we do not need to worry about > > > allocating them later during PFs. > > > > Ahh. Found: > > stack =3D __vmalloc_node_range(THREAD_SIZE, THREAD_ALIGN, ... > > > > > > Then the page fault handler can service a fault in auto-growing sta= ck > > > > area if it has a page stashed in some per-cpu free list. > > > > I suspect this is something you might need for > > > > "16k stack that is populated on fault", > > > > plus a free list of 3 pages per-cpu, > > > > and set_pte_at() in pf handler. > > > > > > Yes, what you described is exactly what I am working on: using 3-page= s > > > per-cpu to handle kstack page faults. The only thing that is missing > > > is that I would like to have the ability to call a non-sleeping > > > version of vm_area_map_pages(). > > > > vm_area_map_pages() cannot be non-sleepable, since the [start, end) > > range will dictate whether mid level allocs and locks are needed. > > > > Instead in alloc_thread_stack_node() you'd need a flavor > > of get_vm_area() that can align the range to THREAD_ALIGN. > > Then immediately call _sleepable_ vm_area_map_pages() to populate > > the first page and later set_pte_at() the other pages on demand > > from the fault handler. > > We still need to get to PTE level to use set_pte_at(). So, either > store it in task_struct for faster PF handling, or add another > non-sleeping vmap function that will do something like this: > > vm_area_set_page_at(addr, page) > { > pgd =3D pgd_offset_k(addr) > p4d =3D vunmap_p4d_range(pgd, addr) > pud =3D pud_offset(p4d, addr) > pmd =3D pmd_offset(pud, addr) > pte =3D pte_offset_kernel(pmd, addr) > > set_pte_at(init_mm, addr, pte, mk_pte(page...)); > } Right. There are several flavors of this logic across the tree. What you're proposing is pretty much vmalloc_to_page() that returns pte even if !pte_present, instead of a page. x86 is doing mostly the same in lookup_address() fwiw. Good opportunity to clean all this up and share the code. From xen-devel-bounces@lists.xenproject.org Wed Mar 06 23:37:12 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 23:37:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689572.1074713 (Exim 4.92) (envelope-from ) id 1ri0os-0003ZQ-P9; Wed, 06 Mar 2024 23:37:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689572.1074713; Wed, 06 Mar 2024 23:37:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ri0os-0003ZJ-KH; Wed, 06 Mar 2024 23:37:06 +0000 Received: by outflank-mailman (input) for mailman id 689572; Wed, 06 Mar 2024 23:37:06 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ri0os-0003Z9-0I; Wed, 06 Mar 2024 23:37:06 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ri0or-0004SI-UF; Wed, 06 Mar 2024 23:37:05 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ri0or-0006ZU-K5; Wed, 06 Mar 2024 23:37:05 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1ri0or-0008QG-JY; Wed, 06 Mar 2024 23:37:05 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=4KOaSJrLSiwe1CVEhTedG+yAuLGWG2mCpQolXNd2NDM=; b=AKSYrJsP5346iZKe3+NbtGe805 EFoCj/Fa6VllxD7oe0sdUidBnd1bRQKMMx/LzJg7wzQZOxOr8gUn9mNlPdLEqeKR69HLN5Y2xA39D Y3OM6U9UH/h6/u2ZaKGbxvpPMVKkSuYtszVwCyYo6MqESLzGVe7pBM1i8NVvVIpSfEHk=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable test] 184919: tolerable FAIL - PUSHED X-Osstest-Failures: xen-unstable:test-armhf-armhf-libvirt-qcow2:guest-start:fail:heisenbug xen-unstable:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=cd53ee9c41f991bbca75641e647005e013a3eac0 X-Osstest-Versions-That: xen=fc84b4a5a37b9250d87ef63983b48e1953bba6d1 From: osstest service owner Date: Wed, 06 Mar 2024 23:37:05 +0000 flight 184919 xen-unstable real [real] flight 184926 xen-unstable real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/184919/ http://logs.test-lab.xenproject.org/osstest/logs/184926/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-libvirt-qcow2 13 guest-start fail pass in 184926-retest Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail in 184926 like 184914 test-armhf-armhf-libvirt-qcow2 14 migrate-support-check fail in 184926 never pass test-armhf-armhf-libvirt 16 saverestore-support-check fail like 184914 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop fail like 184914 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 184914 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop fail like 184914 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 184914 test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail like 184914 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 184914 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop fail like 184914 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184914 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 184914 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop fail like 184914 test-amd64-amd64-libvirt-xsm 15 migrate-support-check fail never pass test-amd64-i386-xl-pvshim 14 guest-start fail never pass test-amd64-i386-libvirt 15 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-check fail never pass test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-check fail never pass test-arm64-arm64-xl 15 migrate-support-check fail never pass test-arm64-arm64-xl 16 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 15 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-check fail never pass test-armhf-armhf-libvirt 15 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-check fail never pass test-amd64-i386-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-check fail never pass test-arm64-arm64-xl-vhd 14 migrate-support-check fail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass version targeted for testing: xen cd53ee9c41f991bbca75641e647005e013a3eac0 baseline version: xen fc84b4a5a37b9250d87ef63983b48e1953bba6d1 Last test of basis 184914 2024-03-06 01:52:03 Z 0 days Testing same since 184919 2024-03-06 13:39:01 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Fouad Hilly Jan Beulich Julien Grall Michal Orzel Oleksii Kurochko Roger Pau Monné Wei Liu jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-dom0pvh-xl-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-qemuu-freebsd11-amd64 pass test-amd64-amd64-qemuu-freebsd12-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-examine-bios pass test-amd64-i386-examine-bios pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-dom0pvh-xl-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-armhf-armhf-libvirt-qcow2 fail test-amd64-amd64-xl-qcow2 pass test-arm64-arm64-libvirt-raw pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-libvirt-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-examine-uefi pass test-amd64-i386-examine-uefi pass test-amd64-amd64-libvirt-vhd pass test-arm64-arm64-xl-vhd pass test-armhf-armhf-xl-vhd pass test-amd64-i386-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these 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 fc84b4a5a3..cd53ee9c41 cd53ee9c41f991bbca75641e647005e013a3eac0 -> master From xen-devel-bounces@lists.xenproject.org Wed Mar 06 23:38:09 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2024 23:38:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689576.1074722 (Exim 4.92) (envelope-from ) id 1ri0pt-00044E-2a; Wed, 06 Mar 2024 23:38:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689576.1074722; Wed, 06 Mar 2024 23:38:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ri0ps-000447-Up; Wed, 06 Mar 2024 23:38:08 +0000 Received: by outflank-mailman (input) for mailman id 689576; Wed, 06 Mar 2024 23:38:07 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ri0pr-00043v-GD for xen-devel@lists.xenproject.org; Wed, 06 Mar 2024 23:38:07 +0000 Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [2a00:1450:4864:20::532]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 95331f6a-dc12-11ee-afda-a90da7624cb6; Thu, 07 Mar 2024 00:38:06 +0100 (CET) Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-568107a9ff2so271722a12.3 for ; Wed, 06 Mar 2024 15:38:06 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 95331f6a-dc12-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709768286; x=1710373086; darn=lists.xenproject.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Rs435nhAJhDlf8VEGEp55iddRE0N5vlG0qIaHENxohA=; b=BDO62eFra8Ol3PDh/lUipnh3R89dNR/CYMVaxp8eFhs84SPq5PNAbbEFY8IHRg6IT2 9OrsYStfukNyFJzR5ArYYlCkkMb7iBhWtklPDc7GbUUf9bYQABdmfjP3XVAyaBXg6QaB v7PDwYRJ5iqKf/1RDRZW03zcKLH82hMBZ5zYWxxtl7uAAJzhhg+1aL8TDjDuFmuqQXv2 6ZCl7eerA/wALxvcrRRBdBiqonkp5iugDa1XPIkkBzal9AojuvqEf9/I9C34XT8exFUz Eqlj9WZo4+iAi0OigQfgLxraCTkIq2SUXot4pd5P5uhMCJGnge6WOoIbDDuoMUz3bnUY guIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709768286; x=1710373086; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Rs435nhAJhDlf8VEGEp55iddRE0N5vlG0qIaHENxohA=; b=DS35WgrfsIhvbPFdMubUjWRv82K2XkuUjE4RL/CD0qxUb7sgx/PcjKO/lXl2+ebXos SOU2yktLhuDEGdw+h2hzhasIjIUly5w+pNXYfjbEOz3QzGOBIViJu0jYvzX8lBOsO8CU MWSdI40DuWOs0adTtXJLXwp7FNkPwPEF/bbiA1A3rAzhHNKPwc2uuR85NDcNaLeP3LFj bOqzs8qf6LIsI2s031iNC7MY+epV4nXy/wY1X6//J968D8zoAN5YCfx24hMa4wiqM0jB 3FAExNLk2j3V7JG0i+YVV68y5IZaA2AL2N6VguOwj9kgElRhyWlftcZx/XZfBHuptPcc pOrQ== X-Gm-Message-State: AOJu0YwiZPWDhdZkBkxjbawd4yDDJ4Pa/l0+TDC/aty6ALSCSYdxy7l1 CwU6GaZjtaHXq4XQ6N3CgwEI5zIJ4GbYPsJxzdTNtxpTorqfe1ZwNHqBc66BVU4btn/9FE8xxsJ YAG+LZnA+pO6UcDHeWqONy7u4riMRzSXqH20= X-Google-Smtp-Source: AGHT+IF0uNmyNEI5H5qVpmLPkty3e5IOpkliyi+fP3fsHr8AmB81uFXT59GhqPxEgOMXdBsBx/6ycmrxTPxJXAd9XgU= X-Received: by 2002:a50:c90d:0:b0:565:e610:c358 with SMTP id o13-20020a50c90d000000b00565e610c358mr10526624edh.38.1709768286040; Wed, 06 Mar 2024 15:38:06 -0800 (PST) MIME-Version: 1.0 References: <79ed633d-b0bd-4a7d-a0c6-37a034e1ee96@suse.com> <0374516c-b5fa-4880-a07a-0b788f491e9a@xen.org> In-Reply-To: <0374516c-b5fa-4880-a07a-0b788f491e9a@xen.org> From: Christopher Clark Date: Wed, 6 Mar 2024 15:37:53 -0800 Message-ID: Subject: Re: [PATCH v2] Argo: don't obtain excess page references To: Jan Beulich , Julien Grall , openxt Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , George Dunlap , Stefano Stabellini , Wei Liu Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Feb 18, 2024 at 10:01=E2=80=AFAM Julien Grall wrot= e: > > Hi Jan, > > On 14/02/2024 10:12, Jan Beulich wrote: > > find_ring_mfn() already holds a page reference when trying to obtain a > > writable type reference. We shouldn't make assumptions on the general > > reference count limit being effectively "infinity". Obtain merely a typ= e > > ref, re-using the general ref by only dropping the previously acquired > > one in the case of an error. > > > > Signed-off-by: Jan Beulich > > Reviewed-by: Julien Grall > > > --- > > I further question the log-dirty check there: The present P2M type of a > > page doesn't really matter for writing to the page (plus it's stale by > > the time it is looked at). Instead I think every write to such a page > > needs to be accompanied by a call to paging_mark_dirty(). > > I agree with that. Adding OpenXT mailing list as I have found that I have not had the time available that I had hoped for to spend on reviewing this Argo change, and to provide opportunity for downstream feedback. Link to the posted patch (start of this thread): https://lists.xenproject.org/archives/html/xen-devel/2024-02/msg00858.html Christopher > > Cheers, > > -- > Julien Grall From xen-devel-bounces@lists.xenproject.org Thu Mar 07 01:31:35 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 01:31:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689606.1074747 (Exim 4.92) (envelope-from ) id 1ri2bN-0000Tb-5u; Thu, 07 Mar 2024 01:31:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689606.1074747; Thu, 07 Mar 2024 01:31:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ri2bN-0000TU-2I; Thu, 07 Mar 2024 01:31:17 +0000 Received: by outflank-mailman (input) for mailman id 689606; Thu, 07 Mar 2024 01:31:16 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ri2bM-0000TO-4L for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 01:31:16 +0000 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 60a95a80-dc22-11ee-afda-a90da7624cb6; Thu, 07 Mar 2024 02:31:12 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 5ABADCE1E7D; Thu, 7 Mar 2024 01:31:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E4828C433C7; Thu, 7 Mar 2024 01:31:06 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 60a95a80-dc22-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1709775068; bh=T5FPfb3bOwQwaxZ89tvSdalPvMidkFRd8A4ARsLFe9M=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=Gp7LErzAqZICGdof/gxR2NVw2QFjoj1Ir6prBrFbE07dT2b+RJxLmkyk1VrWSxskJ MvIulL4VXr7p6PfrWgxw1WJh33fr+yGpkw/5VQ+n+Me3OUFp3pEc9q4znD0AktNxsq Q2dFT/O2QraaK0TewO97y9hUyQkm366AwaBc0WTP30vi0/xx6RBjustWXMMtsaPgkX VVQZ0+pJAMmRDwcZfZLtk1S9YXBKWveow5JXmIJM2JP20UXdsyVWfiveIGbdlMuKRv LOuCoVFHT6V3TB9suCWYd6zVzM7uAiAPOahKN5U6yPYwKkgkkEYoZ8E852M493JrMu HTZ1QVfEX9bwg== Date: Wed, 6 Mar 2024 17:31:05 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Nicola Vetrini cc: xen-devel@lists.xenproject.org, sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, consulting@bugseng.com, jbeulich@suse.com, andrew.cooper3@citrix.com, roger.pau@citrix.com, bertrand.marquis@arm.com, julien@xen.org, Rahul Singh , Volodymyr Babchuk Subject: Re: [XEN PATCH 06/10] arm/smmu: address some violations of MISRA C Rule 20.7 In-Reply-To: <8bbf294d832b973648e84e5d837b1878a84f7645.1709219010.git.nicola.vetrini@bugseng.com> Message-ID: References: <8bbf294d832b973648e84e5d837b1878a84f7645.1709219010.git.nicola.vetrini@bugseng.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Thu, 29 Feb 2024, Nicola Vetrini wrote: > MISRA C Rule 20.7 states: "Expressions resulting from the expansion > of macro parameters shall be enclosed in parentheses". Therefore, some > macro definitions should gain additional parentheses to ensure that all > current and future users will be safe with respect to expansions that > can possibly alter the semantics of the passed-in macro parameter. > > No functional change. > > Signed-off-by: Nicola Vetrini Reviewed-by: Stefano Stabellini > --- > xen/drivers/passthrough/arm/smmu.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/xen/drivers/passthrough/arm/smmu.c b/xen/drivers/passthrough/arm/smmu.c > index 625ed0e41961..83196057a937 100644 > --- a/xen/drivers/passthrough/arm/smmu.c > +++ b/xen/drivers/passthrough/arm/smmu.c > @@ -242,7 +242,7 @@ struct arm_smmu_xen_device { > struct iommu_group *group; > }; > > -#define dev_archdata(dev) ((struct arm_smmu_xen_device *)dev->iommu) > +#define dev_archdata(dev) ((struct arm_smmu_xen_device *)(dev)->iommu) > #define dev_iommu_domain(dev) (dev_archdata(dev)->domain) > #define dev_iommu_group(dev) (dev_archdata(dev)->group) > > @@ -627,7 +627,7 @@ struct arm_smmu_master_cfg { > }; > #define INVALID_SMENDX -1 > #define for_each_cfg_sme(cfg, i, idx, num) \ > - for (i = 0; idx = cfg->smendx[i], i < num; ++i) > + for (i = 0; idx = (cfg)->smendx[i], (i) < (num); ++(i)) > > struct arm_smmu_master { > struct device_node *of_node; > -- > 2.34.1 > From xen-devel-bounces@lists.xenproject.org Thu Mar 07 01:40:39 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 01:40:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689609.1074757 (Exim 4.92) (envelope-from ) id 1ri2kB-0002YJ-Vm; Thu, 07 Mar 2024 01:40:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689609.1074757; Thu, 07 Mar 2024 01:40:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ri2kB-0002YC-T4; Thu, 07 Mar 2024 01:40:23 +0000 Received: by outflank-mailman (input) for mailman id 689609; Thu, 07 Mar 2024 01:40:22 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ri2kA-0002Y6-OZ for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 01:40:22 +0000 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 916ef542-dc23-11ee-a1ee-f123f15fe8a2; Thu, 07 Mar 2024 02:39:42 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 12DCD61BCE; Thu, 7 Mar 2024 01:39:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EAB0BC433F1; Thu, 7 Mar 2024 01:39:38 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 916ef542-dc23-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1709775580; bh=8TyXHrMAokNqX9PY/rXFl06PuUpnN21MPfNTOWlVI34=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=Rhn68/38bfSd0jT8y9UF89CvUvS5hvMnLKqAXNUq9GH/wDwgZ8hMJ1m4X1NYTqMon vi36A42F4t9v+wfzQekq6SKdYokPQWNZhRI7z25RyfkkhZ4mja5wlL7YGGkPtxlbdL QnZuZD6IH1E8pMG89lTQf1HCKOBRID2aMBVrKfkX0fNBG0tfmdON9+aq53Xc8IAqV7 M3krK3KS+r01AXS8IvmQOA/KQTttm5IJGfLBu2l6ZpIzXAjDQN9m/0twCJDKncoCzt OhDJmMqWJVjFLMoXHMu/Lejf+pB5JR50KAkphn2PL8YRaAq8IfkEqAi35MGrqYAHoa cuHHrCVh8ASig== Date: Wed, 6 Mar 2024 17:39:37 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Jan Beulich cc: Stefano Stabellini , xen-devel@lists.xenproject.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, consulting@bugseng.com, andrew.cooper3@citrix.com, roger.pau@citrix.com, bertrand.marquis@arm.com, julien@xen.org, George Dunlap , Wei Liu , Nicola Vetrini Subject: Re: [XEN PATCH 10/10] xen/keyhandler: address violations of MISRA C Rule 20.7 In-Reply-To: Message-ID: References: <2bc4a964f0f2f47488e72237678e944dbdbd7bb7.1709219010.git.nicola.vetrini@bugseng.com> <1afd8805-7365-40ec-8e8e-468a83e20c40@suse.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Tue, 5 Mar 2024, Jan Beulich wrote: > On 05.03.2024 03:03, Stefano Stabellini wrote: > > On Mon, 4 Mar 2024, Jan Beulich wrote: > >> On 02.03.2024 02:37, Stefano Stabellini wrote: > >>> On Fri, 1 Mar 2024, Jan Beulich wrote: > >>>> On 29.02.2024 23:57, Stefano Stabellini wrote: > >>>>> On Thu, 29 Feb 2024, Nicola Vetrini wrote: > >>>>>> MISRA C Rule 20.7 states: "Expressions resulting from the expansion > >>>>>> of macro parameters shall be enclosed in parentheses". Therefore, some > >>>>>> macro definitions should gain additional parentheses to ensure that all > >>>>>> current and future users will be safe with respect to expansions that > >>>>>> can possibly alter the semantics of the passed-in macro parameter. > >>>>>> > >>>>>> No functional change. > >>>>>> > >>>>>> Signed-off-by: Nicola Vetrini > >>>>> > >>>>> Reviewed-by: Stefano Stabellini > >>>> > >>>> You did see the discussion on earlier patches, though? I don't think > >>>> any of the parentheses here are needed or wanted. > >>> > >>> We need to align on this. Currently if we go by what's written in > >>> docs/misra/deviations.rst, then rhs should have parentheses. > >> > >> Quoting the actual patch again: > > > > [...] > > > >> What rhs are you talking about in light of this change? The only rhs I > >> can spot here is already parenthesized. > > > > Yes you are right. I replied here as an overall comment about our > > approach to 20.7, although this patch is not a good example. My reply > > was meant in the context of https://marc.info/?l=xen-devel&m=170928051025701 > > I'm still confused: The rhs is being parenthsized there. It's the _lhs_ > which isn't and ... > > >>> Can we safely claim that rhs parentheses are never needed? If so, then > >>> great, let's add it to deviations.rst and skip them here and other > >>> places in this patch series (e.g. patch #8). When I say "never" I am > >>> taking for granted that the caller is not doing something completely > >>> unacceptably broken such as: > >>> > >>> WRITE_SYSREG64(var +, TTBR0_EL1) > >> > >> I'm afraid I can't associate this with the patch here either. Instead in > >> the context here a (respective) construct as you mention above would simply > >> fail to build. > > > > Fair enough it will break the build. I was trying to clarify that when I > > wrote "the rhs parentheses are never needed" I meant "never" within > > reason. One can always find ways to break the system and I tried to make > > an example of something that for sure would break rhs or lhs without > > parentheses. > > > > I meant to say, if we don't account for exceptionally broken cases, can > > we safety say we don't need parentheses for rhs? > > ... doesn't need to, unless - as you say - one contrives examples. Yet to > clarify here as well: I assume you mean "we don't need parentheses for lhs". Yes. Far clarity, we are all aligned that lhs does not need parentheses and in fact it is even already deviated in docs/misra/deviations.rst. Now back to this specific patch. The problem is that the comma ',' doesn't need parenthesis for the parameters. However, the way we wrote the deviation in docs/misra/deviations.rst doesn't cover the case this patch is dealing with. docs/misra/deviations.rst only speaks of functions and macros arguments. Should we rephrase docs/misra/deviations.rst in terms of ',' instead ? Can ECLAR deal with it? > And note that even if your example used the first parameter as lhs of an > assignment, the build would still break. The + there would not magically > combine with the = to a += operator. Tokenization occurs ahead of > preprocessing, so the expanded macro would still have a + token followed by > a = one. The only way to alter tokens is by using the ## operator. Which in > turn precludes using parentheses. OK From xen-devel-bounces@lists.xenproject.org Thu Mar 07 01:51:27 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 01:51:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689614.1074768 (Exim 4.92) (envelope-from ) id 1ri2uf-0004hL-Vx; Thu, 07 Mar 2024 01:51:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689614.1074768; Thu, 07 Mar 2024 01:51:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ri2uf-0004hE-Rl; Thu, 07 Mar 2024 01:51:13 +0000 Received: by outflank-mailman (input) for mailman id 689614; Thu, 07 Mar 2024 01:51:12 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ri2ue-0004h8-ES for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 01:51:12 +0000 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 2819e9e0-dc25-11ee-afda-a90da7624cb6; Thu, 07 Mar 2024 02:51:05 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 4D95A61A3E; Thu, 7 Mar 2024 01:51:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E7483C433F1; Thu, 7 Mar 2024 01:51:00 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 2819e9e0-dc25-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1709776262; bh=R/F1ZSbpZekKrxNMmgsEC5tthbinM6LLxoMhze4B9pg=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=CQJYAn61BKlYlIwGv8Is9yXYj5aZwec5Yk7lGaSAZca500AVqd5Z78/d8WQlG0AKb OFzJAC8JW0SZ9PTb6MmjxW/PhtnKGx1gKurUlJ4sbSJIhgecsmyM4pjjirrr3p5vtK djeK51MGCIMIDghgrF5EtuI6iti+e+qs1yVHdWv1oeICk6ZuoFpEnQE1FErujsq0d2 6D6CyEe6WsVkW3kmZVsHKxah23msyrO/IUDOAIWSNtzRZkMvsmItSSZsPkNtj0yqzn RdhvP8Ow09BMK1EB62LvL+dzJJwrL+HiNYK2abnhvMTtkkunLCY9SW+DiVWgbD2bek uaC2b8CGvDcbw== Date: Wed, 6 Mar 2024 17:50:59 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= cc: Stefano Stabellini , xen-devel@lists.xenproject.org, Juergen Gross , Boris Ostrovsky , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Oleksandr Tyshchenko , linux-kernel@vger.kernel.org, Jan Beulich , Andrew Cooper Subject: Re: [PATCH RFC] x86/xen: attempt to inflate the memory balloon on PVH In-Reply-To: Message-ID: References: <20240220174341.56131-1-roger.pau@citrix.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323329-1275602164-1709776262=:853156" This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-1275602164-1709776262=:853156 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Tue, 5 Mar 2024, Roger Pau Monné wrote: > On Thu, Feb 22, 2024 at 05:16:09PM -0800, Stefano Stabellini wrote: > > On Tue, 20 Feb 2024, Roger Pau Monne wrote: > > > When running as PVH or HVM Linux will use holes in the memory map as scratch > > > space to map grants, foreign domain pages and possibly miscellaneous other > > > stuff. However the usage of such memory map holes for Xen purposes can be > > > problematic. The request of holesby Xen happen quite early in the kernel boot > > > process (grant table setup already uses scratch map space), and it's possible > > > that by then not all devices have reclaimed their MMIO space. It's not > > > unlikely for chunks of Xen scratch map space to end up using PCI bridge MMIO > > > window memory, which (as expected) causes quite a lot of issues in the system. > > > > Am I understanding correctly that XEN_BALLOON_MEMORY_HOTPLUG doesn't > > help because it becomes available too late in the PVH boot sequence? > > No, not really, the hoptplug mechanism is available as early as the > balloon driver requires, the issue is that when Linux starts making > use of such unpopulated ranges (for example in order to map the shared > info page) many drivers have not yet reserved their MMIO regions, and so it's > not uncommon for the balloon driver to end up using address ranges that > would otherwise be used by device BARs for example. > > This causes havoc, Linux starts to reposition device BARs, sometimes > it can manage to re-position them, otherwise some devices are not > usable. OK this is bad > > > At least for PVH dom0 we have the possibility of using regions marked as > > > UNUSABLE in the e820 memory map. Either if the region is UNUSABLE in the > > > native memory map, or it has been converted into UNUSABLE in order to hide RAM > > > regions from dom0, the second stage translation page-tables can populate those > > > areas without issues. > > > > > > PV already has this kind of logic, where the balloon driver is inflated at > > > boot. Re-use the current logic in order to also inflate it when running as > > > PVH. onvert UNUSABLE regions up to the ratio specified in EXTRA_MEM_RATIO to > > > RAM, while reserving them using xen_add_extra_mem() (which is also moved so > > > it's no longer tied to CONFIG_PV). > > > > > > Signed-off-by: Roger Pau Monné > > > --- > > > RFC reasons: > > > > > > * Note that it would be preferred for the hypervisor to provide an explicit > > > range to be used as scratch mapping space, but that requires changes to Xen, > > > and it's not fully clear whether Xen can figure out the position of all MMIO > > > regions at boot in order to suggest a scratch mapping region for dom0. > > > > > > * Should the whole set of xen_{add,del,chk,inv}_extra_mem() functions be moved > > > to a different file? For the purposes of PVH only xen_add_extra_mem() is > > > moved and the chk and inv ones are PV specific and might not want moving to > > > a separate file just to guard them with CONFIG_PV. > > > --- > > > arch/x86/include/asm/xen/hypervisor.h | 1 + > > > arch/x86/platform/pvh/enlighten.c | 3 ++ > > > arch/x86/xen/enlighten.c | 32 +++++++++++++ > > > arch/x86/xen/enlighten_pvh.c | 68 +++++++++++++++++++++++++++ > > > arch/x86/xen/setup.c | 44 ----------------- > > > arch/x86/xen/xen-ops.h | 14 ++++++ > > > drivers/xen/balloon.c | 2 - > > > 7 files changed, 118 insertions(+), 46 deletions(-) > > > > > > diff --git a/arch/x86/include/asm/xen/hypervisor.h b/arch/x86/include/asm/xen/hypervisor.h > > > index a9088250770f..31e2bf8d5db7 100644 > > > --- a/arch/x86/include/asm/xen/hypervisor.h > > > +++ b/arch/x86/include/asm/xen/hypervisor.h > > > @@ -62,6 +62,7 @@ void xen_arch_unregister_cpu(int num); > > > #ifdef CONFIG_PVH > > > void __init xen_pvh_init(struct boot_params *boot_params); > > > void __init mem_map_via_hcall(struct boot_params *boot_params_p); > > > +void __init xen_reserve_extra_memory(struct boot_params *bootp); > > > #endif > > > > > > /* Lazy mode for batching updates / context switch */ > > > diff --git a/arch/x86/platform/pvh/enlighten.c b/arch/x86/platform/pvh/enlighten.c > > > index 00a92cb2c814..a12117f3d4de 100644 > > > --- a/arch/x86/platform/pvh/enlighten.c > > > +++ b/arch/x86/platform/pvh/enlighten.c > > > @@ -74,6 +74,9 @@ static void __init init_pvh_bootparams(bool xen_guest) > > > } else > > > xen_raw_printk("Warning: Can fit ISA range into e820\n"); > > > > > > + if (xen_guest) > > > + xen_reserve_extra_memory(&pvh_bootparams); > > > + > > > pvh_bootparams.hdr.cmd_line_ptr = > > > pvh_start_info.cmdline_paddr; > > > > > > diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c > > > index 3c61bb98c10e..a01ca255b0c6 100644 > > > --- a/arch/x86/xen/enlighten.c > > > +++ b/arch/x86/xen/enlighten.c > > > @@ -6,6 +6,7 @@ > > > #include > > > #include > > > #include > > > +#include > > > #include > > > #include > > > > > > @@ -350,3 +351,34 @@ void xen_arch_unregister_cpu(int num) > > > } > > > EXPORT_SYMBOL(xen_arch_unregister_cpu); > > > #endif > > > + > > > +/* Amount of extra memory space we add to the e820 ranges */ > > > +struct xen_memory_region xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] __initdata; > > > + > > > +void __init xen_add_extra_mem(unsigned long start_pfn, unsigned long n_pfns) > > > +{ > > > + unsigned int i; > > > + > > > + /* > > > + * No need to check for zero size, should happen rarely and will only > > > + * write a new entry regarded to be unused due to zero size. > > > + */ > > > + for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) { > > > + /* Add new region. */ > > > + if (xen_extra_mem[i].n_pfns == 0) { > > > + xen_extra_mem[i].start_pfn = start_pfn; > > > + xen_extra_mem[i].n_pfns = n_pfns; > > > + break; > > > + } > > > + /* Append to existing region. */ > > > + if (xen_extra_mem[i].start_pfn + xen_extra_mem[i].n_pfns == > > > + start_pfn) { > > > + xen_extra_mem[i].n_pfns += n_pfns; > > > + break; > > > + } > > > + } > > > + if (i == XEN_EXTRA_MEM_MAX_REGIONS) > > > + printk(KERN_WARNING "Warning: not enough extra memory regions\n"); > > > + > > > + memblock_reserve(PFN_PHYS(start_pfn), PFN_PHYS(n_pfns)); > > > +} > > > diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c > > > index ada3868c02c2..c28f073c1df5 100644 > > > --- a/arch/x86/xen/enlighten_pvh.c > > > +++ b/arch/x86/xen/enlighten_pvh.c > > > @@ -1,6 +1,7 @@ > > > // SPDX-License-Identifier: GPL-2.0 > > > #include > > > #include > > > +#include > > > > > > #include > > > > > > @@ -72,3 +73,70 @@ void __init mem_map_via_hcall(struct boot_params *boot_params_p) > > > } > > > boot_params_p->e820_entries = memmap.nr_entries; > > > } > > > + > > > +/* > > > + * Reserve e820 UNUSABLE regions to inflate the memory balloon. > > > + * > > > + * On PVH dom0 the host memory map is used, RAM regions available to dom0 are > > > + * located as the same place as in the native memory map, but since dom0 gets > > > + * less memory than the total amount of host RAM the ranges that can't be > > > + * populated are converted from RAM -> UNUSABLE. Use such regions (up to the > > > + * ratio signaled in EXTRA_MEM_RATIO) in order to inflate the balloon driver at > > > + * boot. Doing so prevents the guest (even if just temporary) from using holes > > > + * in the memory map in order to map grants or foreign addresses, and > > > + * hopefully limits the risk of a clash with a device MMIO region. Ideally the > > > + * hypervisor should notify us which memory ranges are suitable for creating > > > + * foreign mappings, but that's not yet implemented. > > > + */ > > > +void __init xen_reserve_extra_memory(struct boot_params *bootp) > > > +{ > > > + unsigned int i, ram_pages = 0, extra_pages; > > > + > > > + for (i = 0; i < bootp->e820_entries; i++) { > > > + struct boot_e820_entry *e = &bootp->e820_table[i]; > > > + > > > + if (e->type != E820_TYPE_RAM) > > > + continue; > > > + ram_pages += PFN_DOWN(e->addr + e->size) - PFN_UP(e->addr); > > > + } > > > + > > > + /* Max amount of extra memory. */ > > > + extra_pages = EXTRA_MEM_RATIO * ram_pages; > > > + > > > + /* > > > + * Convert UNUSABLE ranges to RAM and reserve them for foreign mapping > > > + * purposes. > > > + */ > > > + for (i = 0; i < bootp->e820_entries && extra_pages; i++) { > > > + struct boot_e820_entry *e = &bootp->e820_table[i]; > > > + unsigned long pages; > > > + > > > + if (e->type != E820_TYPE_UNUSABLE) > > > + continue; > > > + > > > + pages = min(extra_pages, > > > + PFN_DOWN(e->addr + e->size) - PFN_UP(e->addr)); > > > + > > > + if (pages != (PFN_DOWN(e->addr + e->size) - PFN_UP(e->addr))) { > > > + struct boot_e820_entry *next; > > > + > > > + if (bootp->e820_entries == > > > + ARRAY_SIZE(bootp->e820_table)) > > > + /* No space left to split - skip region. */ > > > + continue; > > > + > > > + /* Split entry. */ > > > + next = e + 1; > > > + memmove(next, e, > > > + (bootp->e820_entries - i) * sizeof(*e)); > > > + bootp->e820_entries++; > > > + next->addr = PAGE_ALIGN(e->addr) + PFN_PHYS(pages); > > > + e->size = next->addr - e->addr; > > > + next->size -= e->size; > > > > Is this really worth doing? Can we just skip this range and continue or > > simply break out and call it a day? Or even add the whole range instead? > > > > The reason I am asking is that I am expecting E820_TYPE_UNUSABLE regions > > not to be huge. Splitting one just to cover the few remaining pages out > > of extra_pages doesn't seem worth it? > > No, they are usually quite huge on PVH dom0, because when building a > PVH dom0 the E820_TYPE_RAM ranges that are not made available to dom0 > because of a dom0_mem option end up being reported as > E820_TYPE_UNUSABLE in the e820 provided to dom0. > > That's mostly the motivation of the change, to be able to reuse those > ranges as scratch space for foreign mappings. > > Ideally the hypervisor should somehow report suitable ranges in the > address space for domains to create foreign mappings, but this does > require an amount of extra work I don't have time to do ATM, hence > this stopgap proposal. I see. We have gained this feature on ARM not long ago for Dom0 and Dom0less guests. All right, I have no reservations. The patch looks OK to me. Juergen? --8323329-1275602164-1709776262=:853156-- From xen-devel-bounces@lists.xenproject.org Thu Mar 07 02:09:31 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 02:09:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689619.1074788 (Exim 4.92) (envelope-from ) id 1ri3CL-0007wJ-I5; Thu, 07 Mar 2024 02:09:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689619.1074788; Thu, 07 Mar 2024 02:09:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ri3CL-0007wA-F4; Thu, 07 Mar 2024 02:09:29 +0000 Received: by outflank-mailman (input) for mailman id 689619; Thu, 07 Mar 2024 02:09:28 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ri3CK-0007vh-KQ for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 02:09:28 +0000 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id b89fa051-dc27-11ee-a1ee-f123f15fe8a2; Thu, 07 Mar 2024 03:09:26 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id BEA4661A39; Thu, 7 Mar 2024 02:09:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A78D4C433F1; Thu, 7 Mar 2024 02:09:23 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b89fa051-dc27-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1709777364; bh=GuemIr9Le5eQPaPn8YSEdkoZcPoNvZsUehMUKA4mBYI=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=at4ifUkLepJ3CMRiF0GS6kK2MH8ZcXWfibwX/CHle2wPA3nTyKdMtpxTctFMVTq8b 4lm3VQuZeXTOx4L+rXn+iipT7AMUIBniluz7VXjK/ZMM7NgOvnoxJxAgAjBFzOJTXX ITrXsQsWA2tCwayBZ9u2JL+Xi5jJzCeJ1D8gdpwJKIdrh6fET/KgxAu4oDpzUL3LLu nCtQcgor/+javtz4Cz3bUWJgb4XopPKiQHOtcuJnUGPKq8PBuj3XNt7ugfiGUWEFi0 ax7Wef77uC63EJBjV3ozsUnG86gDeur3Ypi8QijkTTtCGS3rwVeqSLNSzzzAmkz3Iw 4jAV5W7sqpsVw== Date: Wed, 6 Mar 2024 18:09:22 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Jason Andryuk cc: xen-devel@lists.xenproject.org, Jan Beulich , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu Subject: Re: [PATCH 2/3] xen/x86: bzImage parse kernel_alignment In-Reply-To: <20240306185032.103216-3-jason.andryuk@amd.com> Message-ID: References: <20240306185032.103216-1-jason.andryuk@amd.com> <20240306185032.103216-3-jason.andryuk@amd.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Wed, 6 Mar 2024, Jason Andryuk wrote: > Expand bzimage_parse() to return kernel_alignment from the setup_header. > This will be needed if loading a PVH kernel at a physical offset to > compensate for a reserved E820 region. > > Signed-off-by: Jason Andryuk Reviewed-by: Stefano Stabellini > --- > xen/arch/x86/bzimage.c | 4 +++- > xen/arch/x86/hvm/dom0_build.c | 4 +++- > xen/arch/x86/include/asm/bzimage.h | 3 +-- > xen/arch/x86/pv/dom0_build.c | 2 +- > 4 files changed, 8 insertions(+), 5 deletions(-) > > diff --git a/xen/arch/x86/bzimage.c b/xen/arch/x86/bzimage.c > index ac4fd428be..0f4cfc49f7 100644 > --- a/xen/arch/x86/bzimage.c > +++ b/xen/arch/x86/bzimage.c > @@ -105,7 +105,7 @@ unsigned long __init bzimage_headroom(void *image_start, > } > > int __init bzimage_parse(void *image_base, void **image_start, > - unsigned long *image_len) > + unsigned long *image_len, unsigned int *align) > { > struct setup_header *hdr = (struct setup_header *)(*image_start); > int err = bzimage_check(hdr, *image_len); > @@ -118,6 +118,8 @@ int __init bzimage_parse(void *image_base, void **image_start, > { > *image_start += (hdr->setup_sects + 1) * 512 + hdr->payload_offset; > *image_len = hdr->payload_length; > + if ( align ) > + *align = hdr->kernel_alignment; > } > > if ( elf_is_elfbinary(*image_start, *image_len) ) > diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c > index 0ceda4140b..bbae8a5645 100644 > --- a/xen/arch/x86/hvm/dom0_build.c > +++ b/xen/arch/x86/hvm/dom0_build.c > @@ -548,12 +548,14 @@ static int __init pvh_load_kernel(struct domain *d, const module_t *image, > struct elf_binary elf; > struct elf_dom_parms parms; > paddr_t last_addr; > + unsigned int align = 0; > struct hvm_start_info start_info = { 0 }; > struct hvm_modlist_entry mod = { 0 }; > struct vcpu *v = d->vcpu[0]; > int rc; > > - if ( (rc = bzimage_parse(image_base, &image_start, &image_len)) != 0 ) > + rc = bzimage_parse(image_base, &image_start, &image_len, &align); > + if ( rc != 0 ) > { > printk("Error trying to detect bz compressed kernel\n"); > return rc; > diff --git a/xen/arch/x86/include/asm/bzimage.h b/xen/arch/x86/include/asm/bzimage.h > index 7ed69d3910..de4e9a446f 100644 > --- a/xen/arch/x86/include/asm/bzimage.h > +++ b/xen/arch/x86/include/asm/bzimage.h > @@ -4,8 +4,7 @@ > #include > > unsigned long bzimage_headroom(void *image_start, unsigned long image_length); > - > int bzimage_parse(void *image_base, void **image_start, > - unsigned long *image_len); > + unsigned long *image_len, unsigned int *align); > > #endif /* __X86_BZIMAGE_H__ */ > diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c > index d8043fa58a..e9fa8a9a82 100644 > --- a/xen/arch/x86/pv/dom0_build.c > +++ b/xen/arch/x86/pv/dom0_build.c > @@ -416,7 +416,7 @@ int __init dom0_construct_pv(struct domain *d, > > d->max_pages = ~0U; > > - if ( (rc = bzimage_parse(image_base, &image_start, &image_len)) != 0 ) > + if ( (rc = bzimage_parse(image_base, &image_start, &image_len, NULL)) != 0 ) > return rc; > > if ( (rc = elf_init(&elf, image_start, image_len)) != 0 ) > -- > 2.44.0 > > From xen-devel-bounces@lists.xenproject.org Thu Mar 07 02:09:31 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 02:09:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689618.1074778 (Exim 4.92) (envelope-from ) id 1ri3CE-0007es-8M; Thu, 07 Mar 2024 02:09:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689618.1074778; Thu, 07 Mar 2024 02:09:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ri3CE-0007el-5K; Thu, 07 Mar 2024 02:09:22 +0000 Received: by outflank-mailman (input) for mailman id 689618; Thu, 07 Mar 2024 02:09:20 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ri3CC-0007bR-2y for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 02:09:20 +0000 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id b2f2aa8a-dc27-11ee-afda-a90da7624cb6; Thu, 07 Mar 2024 03:09:17 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id E9D23CE2364; Thu, 7 Mar 2024 02:09:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 16593C433F1; Thu, 7 Mar 2024 02:09:10 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b2f2aa8a-dc27-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1709777352; bh=hYROHoVH0buEWWfmdF9lYIqOOaFMpk53Aaj3DKaC1uA=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=eLi548Y2tDV6U5/gKH6izQuz+bR+LjEYJ8FvYnbS5BDBjHdzqE+ELHKk1pukD17Dy G12/i+ik2bwV8A+VlSh0x5pQ+YiHw03YJA8ieXMv0Kh4V2IRKF2mcRGbbeKH/1aXcJ EC5MO4nDakULFvjfUlkl+Sp/+SvSNsWP5vkianR06fndKO9p9kHkUJ2aIY+YTROi8y KYZeOjcTTSN9/QQ5wbf2gLeOeR3tcICwR3pToGclEjCCTyQXwkuX+SorRY4ELd6leC JLBwRGirfqz72vsTWYo109ozlpeOpRyvLw9L6Uint3w04O5DRrZ3QWKCVuEVehJZX/ FpHjgSLzqISTQ== Date: Wed, 6 Mar 2024 18:09:09 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Jason Andryuk cc: xen-devel@lists.xenproject.org, Jan Beulich , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu , George Dunlap , Julien Grall , Stefano Stabellini Subject: Re: [PATCH 3/3] x86/PVH: Support relocatable dom0 kernels In-Reply-To: <20240306185032.103216-4-jason.andryuk@amd.com> Message-ID: References: <20240306185032.103216-1-jason.andryuk@amd.com> <20240306185032.103216-4-jason.andryuk@amd.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Wed, 6 Mar 2024, Jason Andryuk wrote: > Xen tries to load a PVH dom0 kernel at the fixed guest physical address > from the elf headers. For Linux, this defaults to 0x1000000 (16MB), but > it can be configured. > > Unfortunately there exist firmwares that have reserved regions at this > address, so Xen fails to load the dom0 kernel since it's not RAM. > > The PVH entry code is not relocatable - it loads from absolute > addresses, which fail when the kernel is loaded at a different address. > With a suitably modified kernel, a reloctable entry point is possible. > > Add the XENFEAT_pvh_relocatable flag to let a kernel indicate that it > supports a relocatable entry path. > > Change the loading to check for an acceptable load address. If the > kernel is relocatable, support finding an alternate load address. > > Linux cares about its physical alignment. This can be pulled out of the > bzImage header, but not from the vmlinux ELF file. If an alignment > can't be found, use 2MB. > > Signed-off-by: Jason Andryuk > --- > Put alignment as a new ELF note? Presence of that note would indicate > relocation support without a new XENFEAT flag. > > Default alignment to a multiple of 2MB to make more cases work? It has > to be a power of two, and a multiple might allow loading a customized > kernel. A larger alignment would limit the number of possible load > locations. > --- > xen/arch/x86/hvm/dom0_build.c | 109 ++++++++++++++++++++++++++++++++++ > xen/include/public/features.h | 5 ++ > 2 files changed, 114 insertions(+) > > diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c > index bbae8a5645..34d68ee8fb 100644 > --- a/xen/arch/x86/hvm/dom0_build.c > +++ b/xen/arch/x86/hvm/dom0_build.c > @@ -537,6 +537,109 @@ static paddr_t __init find_memory( > return INVALID_PADDR; > } > > +static bool __init check_load_address( > + const struct domain *d, const struct elf_binary *elf) > +{ > + paddr_t kernel_start = (paddr_t)elf->dest_base & PAGE_MASK; > + paddr_t kernel_end = ROUNDUP((paddr_t)elf->dest_base + elf->dest_size, > + PAGE_SIZE); > + unsigned int i; > + > + /* > + * The memory map is sorted and all RAM regions starts and sizes are > + * aligned to page boundaries. > + */ > + for ( i = 0; i < d->arch.nr_e820; i++ ) > + { > + paddr_t start = d->arch.e820[i].addr; > + paddr_t end = d->arch.e820[i].addr + d->arch.e820[i].size; > + > + if ( start <= kernel_start && > + end >= kernel_end && > + d->arch.e820[i].type == E820_RAM ) > + return true; > + } > + > + return false; > +} > + > +/* > + * Find an e820 RAM region that fits the kernel at a suitable alignment. > + */ > +static paddr_t find_kernel_memory( > + const struct domain *d, struct elf_binary *elf, paddr_t align) > +{ > + paddr_t kernel_start = (paddr_t)elf->dest_base & PAGE_MASK; > + paddr_t kernel_end = ROUNDUP((paddr_t)elf->dest_base + elf->dest_size, > + PAGE_SIZE); > + unsigned int i; > + > + /* > + * The memory map is sorted and all RAM regions starts and sizes are > + * aligned to page boundaries. > + */ > + for ( i = 0; i < d->arch.nr_e820; i++ ) > + { > + paddr_t start = d->arch.e820[i].addr; > + paddr_t end = d->arch.e820[i].addr + d->arch.e820[i].size; > + paddr_t kstart, kend, offset; > + > + if ( d->arch.e820[i].type != E820_RAM ) > + continue; > + > + if ( d->arch.e820[i].size < elf->dest_size ) > + continue; > + > + if ( end < kernel_end ) > + continue; Why this check? Is it to make sure we look for e820 regions that are higher in terms of addresses? If so, couldn't we start from d->arch.nr_e820 and go down instead of starting from 0 and going up? The PVH entry point is a 32-bit entry point if I remember right? Do we need a 32-bit check? If so then it might not be a good idea to start from arch.nr_e820 and go down. > + kstart = ROUNDUP(start, align); > + offset = kstart - kernel_start; > + kend = kernel_end + offset; > + > + if ( kend <= end ) > + return offset; > + } > + > + return 0; > +} > + > +/* > + * Check the kernel load address, and adjust if necessary and possible. > + */ > +static bool __init adjust_load_address( > + const struct domain *d, struct elf_binary *elf, struct elf_dom_parms *parms, > + paddr_t align) > +{ > + paddr_t offset; > + > + /* Check load address */ > + if ( check_load_address(d, elf) ) > + return true; > + > + if ( !test_bit(XENFEAT_pvh_relocatable, parms->f_supported) ) > + { > + printk("Address conflict and %pd kernel is not relocatable\n", d); > + return false; > + } > + > + if ( align == 0 ) > + align = MB(2); > + > + offset = find_kernel_memory(d, elf, align); > + if ( offset == 0 ) > + { > + printk("Failed find a load offset for the kernel\n"); > + return false; > + } > + > + printk("Adjusting load address by %#lx\n", offset); > + elf->dest_base += offset; > + parms->phys_entry += offset; > + > + return true; > +} > + > static int __init pvh_load_kernel(struct domain *d, const module_t *image, > unsigned long image_headroom, > module_t *initrd, void *image_base, > @@ -587,6 +690,12 @@ static int __init pvh_load_kernel(struct domain *d, const module_t *image, > elf.dest_base = (void *)(parms.virt_kstart - parms.virt_base); > elf.dest_size = parms.virt_kend - parms.virt_kstart; > > + if ( !adjust_load_address(d, &elf, &parms, align) ) > + { > + printk("Unable to load kernel\n"); > + return -ENOMEM; > + } > + > elf_set_vcpu(&elf, v); > rc = elf_load_binary(&elf); > if ( rc < 0 ) > diff --git a/xen/include/public/features.h b/xen/include/public/features.h > index 4437f25d25..300480cb22 100644 > --- a/xen/include/public/features.h > +++ b/xen/include/public/features.h > @@ -120,6 +120,11 @@ > #define XENFEAT_runstate_phys_area 18 > #define XENFEAT_vcpu_time_phys_area 19 > > +/* > + * PVH: If set, the guest supports relocation in load address. > + */ > +#define XENFEAT_pvh_relocatable 20 > + > #define XENFEAT_NR_SUBMAPS 1 > > #endif /* __XEN_PUBLIC_FEATURES_H__ */ > -- > 2.44.0 > > From xen-devel-bounces@lists.xenproject.org Thu Mar 07 04:02:21 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 04:02:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689632.1074797 (Exim 4.92) (envelope-from ) id 1ri4xL-0001Df-Vq; Thu, 07 Mar 2024 04:02:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689632.1074797; Thu, 07 Mar 2024 04:02:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ri4xL-0001DY-T8; Thu, 07 Mar 2024 04:02:07 +0000 Received: by outflank-mailman (input) for mailman id 689632; Thu, 07 Mar 2024 04:02:06 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ri4xK-0001DO-GC; Thu, 07 Mar 2024 04:02:06 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ri4xK-0000ZL-BW; Thu, 07 Mar 2024 04:02:06 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ri4xK-00022Y-2i; Thu, 07 Mar 2024 04:02:06 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1ri4xK-0007qX-2K; Thu, 07 Mar 2024 04:02:06 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=ZjRpzAlygruF18h+uk6bNG/xezPlwNJP3kTtRx6YbdY=; b=oqvCOR/1kBGaSuj0F9KoFp0QZl ecPsBCA1bVoHVfIJLSn/NOsEPKEofS6eF46WNhZbhAcN45q+Ir0VNyXTAfP830WhcarmFZv47YfS4 S7ltadsTVTiVC98c2pYEynvJsm+lGpHzfsvvUJ5FLWtcCaoc4ZxKRL2BCLiCHVXZisr8=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-5.4 test] 184921: tolerable FAIL - PUSHED X-Osstest-Failures: linux-5.4:test-arm64-arm64-libvirt-raw:guest-start.2:fail:heisenbug linux-5.4:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:allowable linux-5.4:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-5.4:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-5.4:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-5.4:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-5.4:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-5.4:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-5.4:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-5.4:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-5.4:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking linux-5.4:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-5.4:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking linux-5.4:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking linux-5.4:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-i386-libvirt-raw:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: linux=3fec063b052e395f4920fbc59a8d0bb3c9666d76 X-Osstest-Versions-That: linux=e133c1ee6d7271007fdba3dbe78818afd88943f9 From: osstest service owner Date: Thu, 07 Mar 2024 04:02:06 +0000 flight 184921 linux-5.4 real [real] flight 184928 linux-5.4 real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/184921/ http://logs.test-lab.xenproject.org/osstest/logs/184928/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-arm64-arm64-libvirt-raw 18 guest-start.2 fail pass in 184928-retest Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 18 guest-start/debian.repeat fail REGR. vs. 184832 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 16 saverestore-support-check fail like 184832 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop fail like 184832 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 184832 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 184832 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop fail like 184832 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop fail like 184832 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop fail like 184832 test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail like 184832 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 184832 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 184832 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 184832 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184832 test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-check fail never pass test-amd64-i386-xl-pvshim 14 guest-start fail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-check fail never pass test-amd64-i386-libvirt 15 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-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-check fail never pass test-arm64-arm64-xl 15 migrate-support-check fail never pass test-arm64-arm64-xl 16 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 15 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-check fail never pass test-armhf-armhf-libvirt 15 migrate-support-check fail never pass test-amd64-i386-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-check fail never pass test-arm64-arm64-xl-vhd 14 migrate-support-check fail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-check fail never pass version targeted for testing: linux 3fec063b052e395f4920fbc59a8d0bb3c9666d76 baseline version: linux e133c1ee6d7271007fdba3dbe78818afd88943f9 Last test of basis 184832 2024-03-01 12:45:59 Z 5 days Testing same since 184921 2024-03-06 14:47:02 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Alexander Ofitserov Andrew Morton Ard Biesheuvel Arnd Bergmann Arturas Moskvinas Baokun Li Bartosz Golaszewski Christian Brauner Curtis Klein Dave Hansen David Howells David S. Miller David Sterba Eric Dumazet Florian Fainelli Florian Westphal Frank Li Greg Kroah-Hartman Hans de Goede Harshit Mogalapalli Ignat Korchagin Ivan Semenov Jakub Kicinski Javier Carrasco Johannes Berg Jon Hunter Kai-Heng Feng Lin Ma Linux Kernel Functional Testing Luiz Augusto von Dentz Michal Hocko Muchun Song Nikolay Aleksandrov Oleksij Rempel Oscar Salvador Pablo Neira Ayuso Paolo Abeni Paolo Bonzini Peng Ma Ryosuke Yasuoka Sasha Levin Sebastian Reichel Shuah Khan Takashi Iwai Ulf Hansson Vamsi Krishna Brahmajosyula Vinod Koul Yi Zhao Ying Hsu Yunjian Wang jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-dom0pvh-xl-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-qemuu-freebsd11-amd64 pass test-amd64-amd64-qemuu-freebsd12-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-examine-bios pass test-amd64-i386-examine-bios pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-dom0pvh-xl-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-armhf-armhf-libvirt-qcow2 pass test-amd64-amd64-xl-qcow2 pass test-arm64-arm64-libvirt-raw fail test-armhf-armhf-libvirt-raw pass test-amd64-i386-libvirt-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds fail test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-examine-uefi pass test-amd64-i386-examine-uefi pass test-amd64-amd64-libvirt-vhd pass test-arm64-arm64-xl-vhd pass test-armhf-armhf-xl-vhd pass test-amd64-i386-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these 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 : hint: The 'hooks/update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-receive' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. To xenbits.xen.org:/home/xen/git/linux-pvops.git e133c1ee6d727..3fec063b052e3 3fec063b052e395f4920fbc59a8d0bb3c9666d76 -> tested/linux-5.4 From xen-devel-bounces@lists.xenproject.org Thu Mar 07 05:55:32 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 05:55:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689639.1074807 (Exim 4.92) (envelope-from ) id 1ri6is-0008AH-29; Thu, 07 Mar 2024 05:55:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689639.1074807; Thu, 07 Mar 2024 05:55:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ri6ir-0008AA-VX; Thu, 07 Mar 2024 05:55:17 +0000 Received: by outflank-mailman (input) for mailman id 689639; Thu, 07 Mar 2024 05:55:17 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ri6iq-00089h-Sv for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 05:55:16 +0000 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on20601.outbound.protection.outlook.com [2a01:111:f403:2415::601]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 42ac9224-dc47-11ee-a1ee-f123f15fe8a2; Thu, 07 Mar 2024 06:55:11 +0100 (CET) Received: from BYAPR07CA0028.namprd07.prod.outlook.com (2603:10b6:a02:bc::41) by DS0PR12MB9397.namprd12.prod.outlook.com (2603:10b6:8:1bd::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.26; Thu, 7 Mar 2024 05:55:07 +0000 Received: from CO1PEPF000066E6.namprd05.prod.outlook.com (2603:10b6:a02:bc:cafe::83) by BYAPR07CA0028.outlook.office365.com (2603:10b6:a02:bc::41) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.26 via Frontend Transport; Thu, 7 Mar 2024 05:55:06 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by CO1PEPF000066E6.mail.protection.outlook.com (10.167.249.4) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7362.11 via Frontend Transport; Thu, 7 Mar 2024 05:55:05 +0000 Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Wed, 6 Mar 2024 23:55:01 -0600 Received: from henry-MS-7D54.amd.com (10.180.168.240) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.35 via Frontend Transport; Wed, 6 Mar 2024 23:55:00 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 42ac9224-dc47-11ee-a1ee-f123f15fe8a2 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=i3uF0LZ5mHUqL4lnhFMMXMWgtdMAuswDaXCrQszi8g3xssWak1GowtcbQ5D7GWN3yL7fX/gzCY23B12Mb4pkTSwyHPIempcHWd4i5YyTXCiHFp1j8XRghrRl6Aqy8UjR1vN9CK/EhbiA8GYWO657VLVty1DM3eOeF25l+KDORcOYNrSKBRdlJ05c66UodFRWVziTjOUDooLVARoMMwaSndKZ4fQnI0Va72FxpQqIyVsH+7YGqswDlM9sp3d9qkm9Fy4Kc0QNjPKyQFVrcaePOhiVX+QWxxaUK2iVR0qJ0WvDfTmiHPAZ0BRgp+vMlu1zNUgAAlSUfMVlnwiPuFM7mg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=78w9s71NV2KazP+BbvasXgCjVEuk6yUlpVAXh+Du19M=; b=hgTjJG7uUOqAuLC/3XDHeBrNQjGSV4oJrROh4ErMwEeVMznFAHRS9agjXK3xf3sAslgPqKfHqSfLq4pltwXLLs2vIM8sBwv2/O0lkreS3pJBR+xoT765aB3Dk8jAYHSCOu5Xv50o2KecUCLDYzqLywrDZIbhGjdlkJ4PDlD2dpceoTvzwOizQdgXIC8QaHxDjY6FXbXHVlm2KY9cbzWF6tjg4c3YJxarNnLn2J6lb9HhVaAeKvF2eXsOGd/wFqME0NaRS7uIcCnurZFbFB+85utq0MIndRCgjY8KtGstAPh1aR/nquKwxLQvLL4BUu/xJ8xDQXPzFzXL9PEM0JNkIA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=78w9s71NV2KazP+BbvasXgCjVEuk6yUlpVAXh+Du19M=; b=ENSW7ekQ3tV9tZn+UgjIU40tMgXXW5bWjYp+7vd1V6kl/955z/pGtPXktTy6Q+Hdx0QSc1lddj0GJmOZJwS0Ndh3NTfoS9T5JhpIgNFpaJZ6ef1ULRnSPAXQBdFqNaANGdPxfXvp10/J4Njhw4WLhRsXwZ+tz6gDm/6IEtnful4= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C From: Henry Wang To: CC: Henry Wang , Wei Liu , Anthony PERARD , Juergen Gross Subject: [PATCH] tools/9pfsd: Fix build error caused by strerror_r Date: Thu, 7 Mar 2024 13:54:50 +0800 Message-ID: <20240307055450.3158740-1-xin.wang2@amd.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain Received-SPF: None (SATLEXMB04.amd.com: xin.wang2@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CO1PEPF000066E6:EE_|DS0PR12MB9397:EE_ X-MS-Office365-Filtering-Correlation-Id: 3745b813-d816-436b-1385-08dc3e6b23a0 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: OhVbymWOMmnDrnazVXqQxWOGSAMWsF51VtD0DssZfG/yLh3hardnHnoDiHeZra6pbO+H481as9RMrDluAGFl6qikLPY6rIXdph7Lt4ydaV6jymJcjJoyDyIb7gjNDIFXosyv4cGKjpc6NrBFYceoOnqDuaXDV/9IaPdDJHBLlQOiIoIKmj6agu6bpLXHwDNuKTfT29Hx2wtv1D9CwhQNKqIbH5MJ9Ew1vXMSRpncxcq+MNhC+j3BIlR5Msa47XPaYVcyi907JYtL1WPYnWBIux/gwtWB/GbZntWSe8FKZQlsZRTr/hd1WvgfrWoM9ZdrysmuuSvIs0IQItneCMgeBjeKwgzOG3sofpVM6XzROKbrXB5OKu/USQc7hdNREYBPsq3bxZTUZxwMY+szLnmp7C8KdQRnDc5b2dxf0+NEnIB7H1hgQbvXPxw3i9YWHhkTud3yb81F5WS18k8EZ46uYg1rRWcqO8raqx37O4N+D2jFNbv+RAPp5qn7STkh45p3RC7tkWD7kHz+VbEg10DxdH5twNs8xqhzk8ihihHMPwaajphyCCMTlAgN416oZV40k4MVB15l7+udpALbH58x9MCbsoo9F5Hg/nERDqPxYttTMlsRgX/eYJn20k8HxV6SR8YnYjMQcPLSUICcnM1VtvklETKEbfFg8jLYOX7SrQVvnOVZ5ltUySJJgzLViUexndBojcwKEvuodJB7UQ7SSLEiBZ6hmbrfu2MTPWBBWtHoGOeMberIqJNoWjiQWZS8 X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(82310400014)(36860700004)(376005);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Mar 2024 05:55:05.8321 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 3745b813-d816-436b-1385-08dc3e6b23a0 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CO1PEPF000066E6.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB9397 Below error can be seen when doing Yocto build of the toolstack: | io.c: In function 'p9_error': | io.c:684:5: error: ignoring return value of 'strerror_r' declared with attribute 'warn_unused_result' [-Werror=unused-result] | 684 | strerror_r(err, ring->buffer, ring->ring_size); | | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | cc1: all warnings being treated as errors Fix it by adding a return value and check it properly. Signed-off-by: Henry Wang --- tools/9pfsd/io.c | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/tools/9pfsd/io.c b/tools/9pfsd/io.c index adb887c7d9..163eee6ecc 100644 --- a/tools/9pfsd/io.c +++ b/tools/9pfsd/io.c @@ -681,11 +681,17 @@ static void p9_error(struct ring *ring, uint16_t tag, uint32_t err) { unsigned int erroff; - strerror_r(err, ring->buffer, ring->ring_size); - erroff = add_string(ring, ring->buffer, strlen(ring->buffer)); - fill_buffer(ring, P9_CMD_ERROR, tag, "SU", - erroff != ~0 ? ring->str + erroff : "cannot allocate memory", - &err); + char *ret = strerror_r(err, ring->buffer, ring->ring_size); + + if ( ret ) + { + erroff = add_string(ring, ring->buffer, strlen(ring->buffer)); + fill_buffer(ring, P9_CMD_ERROR, tag, "SU", + erroff != ~0 ? + ring->str + erroff : + "cannot allocate memory", + &err); + } } static void p9_version(struct ring *ring, struct p9_header *hdr) -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Thu Mar 07 07:23:14 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 07:23:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689644.1074817 (Exim 4.92) (envelope-from ) id 1ri85j-0003k8-Ba; Thu, 07 Mar 2024 07:22:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689644.1074817; Thu, 07 Mar 2024 07:22:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ri85j-0003k1-8o; Thu, 07 Mar 2024 07:22:59 +0000 Received: by outflank-mailman (input) for mailman id 689644; Thu, 07 Mar 2024 07:22:58 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ri85i-0003jv-Qd for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 07:22:58 +0000 Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [2a00:1450:4864:20::632]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 8436f1ad-dc53-11ee-a1ee-f123f15fe8a2; Thu, 07 Mar 2024 08:22:55 +0100 (CET) Received: by mail-ej1-x632.google.com with SMTP id a640c23a62f3a-a45670f9508so78418766b.0 for ; Wed, 06 Mar 2024 23:22:55 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id qw28-20020a1709066a1c00b00a381ca0e589sm7911809ejc.22.2024.03.06.23.22.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 Mar 2024 23:22:54 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8436f1ad-dc53-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709796175; x=1710400975; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=/xmRdUvHLMnsKqHMkhW5o+z5O4BuUYwsSyD8ZCfnF+A=; b=P4fdnKs0DoVar7u7zk5BCrbTgNQ4eIEeVjL5v6Vcfxhj1PG7VitqxXW1EDtPjzGKr1 82/hUtt3uNG1CkCgYd5ed24Y+9NNmgtAsvwmvYYhEJ/Nje+fUB6Q03j3CALq2l3xdZue XiRuiyoOS3Mno+PEivukccLI5LZbqxHDzcd+JJQq8U71DPJeTrVNadgRNXUNrYCwbUJI VWD7iDKJ2IaWdSoibroIjamt5lHwqztvyqjY+S4VSz5NXPifrBqPN7fzf+WzVpZHpe+t +KZuIq7KuQ7+leWHO/3ZANXFNO4XSGG/esW6I7ehXdDIlB2b/XWyzQp+4XaR8HbjFZma kb4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709796175; x=1710400975; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=/xmRdUvHLMnsKqHMkhW5o+z5O4BuUYwsSyD8ZCfnF+A=; b=UVWalFwwDSlmFINrUw6f6cMR4UZajVw1ze4AmXAwRl9slWqZTt+abpvVRkK276v9Va 1NyV1QYCHUpet4oKr0rpDpE2T6k1OcuDfizCKUcso6kRIInVdd5SfPABp6dPWHVC6KUp BzTOTzv1iYKozMjp25b1fiZmEWRnNDE7RHNLF0IReDIWrW3ItJkZ7+r0lqDq2ETnpkcn PEZDq6QZ3dtDUzBLKyfFPWNk3b+VSNsPTGksfIpIzQR4L7fTGnPLVY6Qo1JsZEyJJ/Dj c3tlZgY/c6t/X16Eb5QtAVPT705MJJpfxNr9wZIGLFI+5z2KdCfCBhZBbxx0FpVwMJoI BUyw== X-Forwarded-Encrypted: i=1; AJvYcCUHfm/eWwokWC862q12n86UK8wh5Wj8QPNbQ39BMBDa1QMWTgdcSZ3vepPKeG4RlcLp/+P1Tvlqk9uVZ8Hw4JHU7nOBVjLf8UVtdL3Ddkw= X-Gm-Message-State: AOJu0YzjnPbKcW+3WTyTTHGakBe4V1kx38XB+v0czfAQXw1z6Fo8uu/u bbPJU51AYSebF9Hj9IRGS5KEgUWIH9t/6lZ/jYsOwDq+e2Z01/Sw7f1D+S0I2A== X-Google-Smtp-Source: AGHT+IGYNlPhtXoi1UiJ898y2bO3HMjKt2n+Y4J+k0ua9NGUAzcSWJh2VVOr5/e9RhWsw8D458xOkQ== X-Received: by 2002:a17:906:1959:b0:a3e:93d0:3443 with SMTP id b25-20020a170906195900b00a3e93d03443mr10623437eje.34.1709796174928; Wed, 06 Mar 2024 23:22:54 -0800 (PST) Message-ID: <7b98737a-c12b-462b-8e3f-593eced138e1@suse.com> Date: Thu, 7 Mar 2024 08:22:53 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] tools/9pfsd: Fix build error caused by strerror_r Content-Language: en-US To: Henry Wang , Juergen Gross Cc: Wei Liu , Anthony PERARD , xen-devel@lists.xenproject.org References: <20240307055450.3158740-1-xin.wang2@amd.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20240307055450.3158740-1-xin.wang2@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 07.03.2024 06:54, Henry Wang wrote: > Below error can be seen when doing Yocto build of the toolstack: > > | io.c: In function 'p9_error': > | io.c:684:5: error: ignoring return value of 'strerror_r' declared > with attribute 'warn_unused_result' [-Werror=unused-result] > | 684 | strerror_r(err, ring->buffer, ring->ring_size); > | | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > | cc1: all warnings being treated as errors > > Fix it by adding a return value and check it properly. > > Signed-off-by: Henry Wang > --- > tools/9pfsd/io.c | 16 +++++++++++----- > 1 file changed, 11 insertions(+), 5 deletions(-) > > diff --git a/tools/9pfsd/io.c b/tools/9pfsd/io.c > index adb887c7d9..163eee6ecc 100644 > --- a/tools/9pfsd/io.c > +++ b/tools/9pfsd/io.c > @@ -681,11 +681,17 @@ static void p9_error(struct ring *ring, uint16_t tag, uint32_t err) > { > unsigned int erroff; > > - strerror_r(err, ring->buffer, ring->ring_size); > - erroff = add_string(ring, ring->buffer, strlen(ring->buffer)); > - fill_buffer(ring, P9_CMD_ERROR, tag, "SU", > - erroff != ~0 ? ring->str + erroff : "cannot allocate memory", > - &err); > + char *ret = strerror_r(err, ring->buffer, ring->ring_size); > + > + if ( ret ) While you're checking the return value, this looks to be the only use of "ret". Which looks wrong for the GNU form of the function. But an up front question is whether we can expect all host OSes / libc implementations to actually support the GNU form. Using _GNU_SOURCE may, after all, then not be appropriate for a component using this function. Jürgen, thoughts? > + { > + erroff = add_string(ring, ring->buffer, strlen(ring->buffer)); > + fill_buffer(ring, P9_CMD_ERROR, tag, "SU", > + erroff != ~0 ? > + ring->str + erroff : > + "cannot allocate memory", Indentation looks questionable to me here, albeit tools/ may have different preferences than xen/. Jan > + &err); > + } > } > > static void p9_version(struct ring *ring, struct p9_header *hdr) From xen-devel-bounces@lists.xenproject.org Thu Mar 07 07:39:59 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 07:39:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689648.1074827 (Exim 4.92) (envelope-from ) id 1ri8M5-00063X-NJ; Thu, 07 Mar 2024 07:39:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689648.1074827; Thu, 07 Mar 2024 07:39:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ri8M5-00063Q-Kj; Thu, 07 Mar 2024 07:39:53 +0000 Received: by outflank-mailman (input) for mailman id 689648; Thu, 07 Mar 2024 07:39:52 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ri8M4-00063K-Ai for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 07:39:52 +0000 Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [2a00:1450:4864:20::52e]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id e0f0380e-dc55-11ee-a1ee-f123f15fe8a2; Thu, 07 Mar 2024 08:39:50 +0100 (CET) Received: by mail-ed1-x52e.google.com with SMTP id 4fb4d7f45d1cf-565ef8af2f5so581119a12.3 for ; Wed, 06 Mar 2024 23:39:50 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id z42-20020a509e2d000000b005669d904871sm8144564ede.49.2024.03.06.23.39.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 Mar 2024 23:39:49 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e0f0380e-dc55-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709797189; x=1710401989; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=BCV4sTx2yEU/u8q1cBmkuc6Qg/vaqDeD1BFa9Vn1fZU=; b=FkjjvEs/PCPu/IL2KF/qe0lmkBMGONm11mSnnJgOfA3G8KyOgvrmXT+LYl7hfIgT8N HhEh9fBnY2CNC9fehS8IY/kq5G/YdWqcFVP7m+jOcJvtdXtunzrtVX/cUVIUi2PFNgj9 hrOpjCRAfB9i6FlRRzPPkYW+xtrHdGRznmpIi/2K0Y+Jw13DMGxMGZ1iNStjfcBF4yob FIQpYEDoEuZzdElialwOqVFgmpY2fzVuNubwBPn5h3u7QlqWlBAzAaZdDuoOdFBc9Z5o 0zGS5LoOfsDccerja9HntJifmFtJGEHjL/vllWEmyJuwZW4xFSKJxQri6JmRjAocnq1Z Jr3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709797189; x=1710401989; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=BCV4sTx2yEU/u8q1cBmkuc6Qg/vaqDeD1BFa9Vn1fZU=; b=HFkumf0mtZeM2wO7BUClzlZ5B9emVnv6jOcjabFonqn4T/XI5TFWty4NHQ9xIhBK1Z BBMvy9ZnSJERAEDbBLVFmmPcdh6tvBiR9y4yjPF3WpgKcPicT+PbguN+CI5fJOg+Ud32 RWqPFkDQ03jSHL5OO/aThIqTeUAy5gwFGB8UUNZ3SSQe+QPfyBd2iF+nxnn0k5CmnvYw 1jYlHpGheUzPd4NuVK9ILyw/uBoNLNFsM8/0w7dkOW17iq0EaopjAV546uH6hlVE1mT5 pjLG25Dy/EWgrRU1Rq0Q874mALjCjEUmI5+J6DigJqNyw17MqiqwhDZK0b+hGiPcYECB tYJQ== X-Forwarded-Encrypted: i=1; AJvYcCXog3gc45k4mFdfn5GpVri9/pIXC/GbXByxPMVd84fpqIOztLxBPOLzUuQ0Z4vvPpqbMes1pwdFvHtxCN8PmTU9ZS9vRAafdI6qtTKOonQ= X-Gm-Message-State: AOJu0YzzXkY22VQYSjkUJ0UlIyxln2Lp/nSpv5p2vgCXEhGdYBmOja2x 40DRAfmxi81HA6eYxQsz7il+71YmmHWkZt9GaxNcRNES5KFnowmaR69J2Nx/Gg== X-Google-Smtp-Source: AGHT+IFJhHwcMmCCacBRAHlYz9aJq511aAo2pCW8zscxEn2SND7CrWERzFXhsTpl8E8DXHm0hFwJIw== X-Received: by 2002:a50:85c6:0:b0:565:9fff:6046 with SMTP id q6-20020a5085c6000000b005659fff6046mr13214584edh.3.1709797189486; Wed, 06 Mar 2024 23:39:49 -0800 (PST) Message-ID: <76ce9dcf-8cac-44b3-9550-f516024bad6e@suse.com> Date: Thu, 7 Mar 2024 08:39:48 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/3] xen/virtual-region: Include rodata pointers Content-Language: en-US To: Andrew Cooper Cc: Konrad Rzeszutek Wilk , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel , Ross Lagerwall References: <20240305121121.3527944-1-andrew.cooper3@citrix.com> <20240305121121.3527944-3-andrew.cooper3@citrix.com> <87b82706-f538-4807-abaf-1e59cebd286b@suse.com> <82126c3a-0cde-452f-86aa-2571482f42aa@citrix.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <82126c3a-0cde-452f-86aa-2571482f42aa@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 06.03.2024 18:21, Andrew Cooper wrote: > On 06/03/2024 5:09 pm, Ross Lagerwall wrote: >> On Tue, Mar 5, 2024 at 2:17 PM Jan Beulich wrote: >>> On 05.03.2024 13:11, Andrew Cooper wrote: >>>> --- a/xen/include/xen/virtual_region.h >>>> +++ b/xen/include/xen/virtual_region.h >>>> @@ -16,6 +16,9 @@ struct virtual_region >>>> const void *text_start; /* .text virtual address start. */ >>>> const void *text_end; /* .text virtual address end. */ >>>> >>>> + const void *rodata_start; /* .rodata virtual address start (optional). */ >>>> + const void *rodata_end; /* .rodata virtual address end. */ >>>> + >>>> /* If this is NULL the default lookup mechanism is used. */ >>>> symbols_lookup_t *symbols_lookup; >>> While perhaps the least bad one can do without quite a bit more churn, >>> I'm still irritated by a virtual region (singular) suddenly covering >>> two ranges of VA space. At the very least I think the description should >>> say a word of justification in this regard. An alternative, after all, >>> could have been for livepatch code to register separate regions for >>> rodata (if present in a patch). >>> >>> A follow-on question then would be why ordinary data isn't reflected in >>> a virtual region. Aiui that's just because livepatch presently has no >>> need for it. >>> >>> Underlying question to both: Is the virtual region concept indeed meant >>> to be fully tied to livepatch and its needs? >>> >> Virtual regions were introduced for live patching but I don't think it >> is completely tied to live patching. It was introduced so that any code >> can participate in symbol lookup, bug frame and exception table entry >> search, rather than special casing "if livepatch" in many places. >> >> I agree that the virtual region concept is being abused here - it's just >> being used as a convenient place to store rodata start/end and doesn't >> really have much to do with the text start & end / bug frame / exception >> table entry search that the virtual region is intended for. >> >> Maybe Andrew can explain why he used this approach? > > I feel the simplicity and obviousness of patch 3 speaks for itself. > > How do you propose fixing it differently. I'm not opposed to doing it the way you do, but I think it then needs clarifying (up front) what a virtual region really is. It looks to be morphing into a module description instead ... One easy option might be to have a comment next to the struct additions here making clear that this is rather an abuse, but chosen to be this way to keep things simple elsewhere. Jan From xen-devel-bounces@lists.xenproject.org Thu Mar 07 07:42:45 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 07:42:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689650.1074838 (Exim 4.92) (envelope-from ) id 1ri8Oq-0007Rz-3u; Thu, 07 Mar 2024 07:42:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689650.1074838; Thu, 07 Mar 2024 07:42:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ri8Oq-0007Rs-0v; Thu, 07 Mar 2024 07:42:44 +0000 Received: by outflank-mailman (input) for mailman id 689650; Thu, 07 Mar 2024 07:42:42 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ri8Oo-0007Rm-ON for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 07:42:42 +0000 Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [2a00:1450:4864:20::529]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 46f2d9c3-dc56-11ee-afda-a90da7624cb6; Thu, 07 Mar 2024 08:42:41 +0100 (CET) Received: by mail-ed1-x529.google.com with SMTP id 4fb4d7f45d1cf-5645960cd56so708933a12.1 for ; Wed, 06 Mar 2024 23:42:41 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id bx18-20020a170906a1d200b00a44f07e55d2sm5451506ejb.41.2024.03.06.23.42.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 Mar 2024 23:42:40 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 46f2d9c3-dc56-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709797361; x=1710402161; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=Y7e0DzqJ9/uRKDP87LkRLRn6M/3mWXMP2NGC8Tah1to=; b=HXsLoU64Yw2KCcJo9xjKm6kqxkeBe3TG+MBuZHLkpZYYkRC/lfVXb6+Hlya4A7vHeO ah2LwWH+3YBt//FeMWznHTAXCMZGGRUMD82j6m6dYLp+0CluPHokAeX2zbL+OdO3OJyv oSl2oTSa+2ltVZml/sS4VqcgUmkviXh3vtmRlKYMEljmUdejvvY0T9BlwbmQY2+dcMes NPL8DWTsBcEXlUrnVuXcop9i3KCyb9RO9hQtgxEyhxS4ul/IQx2kL9M4ejVETAQzNEbA MiZ61nax2TByHwSGpQVU3nF2NIAAGSHXtPULVafcXDiH/qOM6tUSZBF7u45UaOEKiRS2 q+RQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709797361; x=1710402161; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Y7e0DzqJ9/uRKDP87LkRLRn6M/3mWXMP2NGC8Tah1to=; b=kPZFb+N9ABn7dnzVzfTUtCqz4NLyLb7Wv6iVri65v65Lh9WCT8OO39ud+IUYnsuBKD OkAyoeQSxBJe44tt40wlWxU0dbpWlaXwPQnlq6dZ4wmQTB9N3R63F9v8iwzce0GjlSqe p9wWqdCXEZv7Yu/YXMAb+311RC1pLbqLncM/PXKZfh/AnRtwBNZm8EC5CYV7UGjsNPOQ ur0XlkB+E9M7zyc7uaeNtJbcdN9pU86GS7KxH2uJu4mXJl6g1TGNwlPeiR0b4hh3IT0i xQDDyqO4xA/3iEu1w1u4+QUmRm1qBZQBl1Ruv3PKuP5fpEhFpRNTeVF2HhIVkBW2NztM JN+w== X-Gm-Message-State: AOJu0Yx08nUr/j8/qneq21mSxacjaACHr1Cq+hrsIqwzLNZKfJbUaEr7 GIkZCEdXyMu5ko/2FWPdzl3mOGtn7m+6qmzTqIyINVoRUpy4zsKTzyM6ZSjsOg== X-Google-Smtp-Source: AGHT+IFFfp5sdqSVprdZh4oUG96In2rreu5flL0V9IhEIa9ot30sZbv0hPKWPa2D9jKPKVKTTA1q6w== X-Received: by 2002:a17:906:b7c9:b0:a3f:1055:28b7 with SMTP id fy9-20020a170906b7c900b00a3f105528b7mr10180167ejb.63.1709797360659; Wed, 06 Mar 2024 23:42:40 -0800 (PST) Message-ID: Date: Thu, 7 Mar 2024 08:42:39 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH 10/10] xen/keyhandler: address violations of MISRA C Rule 20.7 Content-Language: en-US To: Stefano Stabellini Cc: xen-devel@lists.xenproject.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, consulting@bugseng.com, andrew.cooper3@citrix.com, roger.pau@citrix.com, bertrand.marquis@arm.com, julien@xen.org, George Dunlap , Wei Liu , Nicola Vetrini References: <2bc4a964f0f2f47488e72237678e944dbdbd7bb7.1709219010.git.nicola.vetrini@bugseng.com> <1afd8805-7365-40ec-8e8e-468a83e20c40@suse.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 07.03.2024 02:39, Stefano Stabellini wrote: > On Tue, 5 Mar 2024, Jan Beulich wrote: >> On 05.03.2024 03:03, Stefano Stabellini wrote: >>> On Mon, 4 Mar 2024, Jan Beulich wrote: >>>> On 02.03.2024 02:37, Stefano Stabellini wrote: >>>>> On Fri, 1 Mar 2024, Jan Beulich wrote: >>>>>> On 29.02.2024 23:57, Stefano Stabellini wrote: >>>>>>> On Thu, 29 Feb 2024, Nicola Vetrini wrote: >>>>>>>> MISRA C Rule 20.7 states: "Expressions resulting from the expansion >>>>>>>> of macro parameters shall be enclosed in parentheses". Therefore, some >>>>>>>> macro definitions should gain additional parentheses to ensure that all >>>>>>>> current and future users will be safe with respect to expansions that >>>>>>>> can possibly alter the semantics of the passed-in macro parameter. >>>>>>>> >>>>>>>> No functional change. >>>>>>>> >>>>>>>> Signed-off-by: Nicola Vetrini >>>>>>> >>>>>>> Reviewed-by: Stefano Stabellini >>>>>> >>>>>> You did see the discussion on earlier patches, though? I don't think >>>>>> any of the parentheses here are needed or wanted. >>>>> >>>>> We need to align on this. Currently if we go by what's written in >>>>> docs/misra/deviations.rst, then rhs should have parentheses. >>>> >>>> Quoting the actual patch again: >>> >>> [...] >>> >>>> What rhs are you talking about in light of this change? The only rhs I >>>> can spot here is already parenthesized. >>> >>> Yes you are right. I replied here as an overall comment about our >>> approach to 20.7, although this patch is not a good example. My reply >>> was meant in the context of https://marc.info/?l=xen-devel&m=170928051025701 >> >> I'm still confused: The rhs is being parenthsized there. It's the _lhs_ >> which isn't and ... >> >>>>> Can we safely claim that rhs parentheses are never needed? If so, then >>>>> great, let's add it to deviations.rst and skip them here and other >>>>> places in this patch series (e.g. patch #8). When I say "never" I am >>>>> taking for granted that the caller is not doing something completely >>>>> unacceptably broken such as: >>>>> >>>>> WRITE_SYSREG64(var +, TTBR0_EL1) >>>> >>>> I'm afraid I can't associate this with the patch here either. Instead in >>>> the context here a (respective) construct as you mention above would simply >>>> fail to build. >>> >>> Fair enough it will break the build. I was trying to clarify that when I >>> wrote "the rhs parentheses are never needed" I meant "never" within >>> reason. One can always find ways to break the system and I tried to make >>> an example of something that for sure would break rhs or lhs without >>> parentheses. >>> >>> I meant to say, if we don't account for exceptionally broken cases, can >>> we safety say we don't need parentheses for rhs? >> >> ... doesn't need to, unless - as you say - one contrives examples. Yet to >> clarify here as well: I assume you mean "we don't need parentheses for lhs". > > Yes. Far clarity, we are all aligned that lhs does not need parentheses > and in fact it is even already deviated in docs/misra/deviations.rst. > > Now back to this specific patch. > > The problem is that the comma ',' doesn't need parenthesis for the > parameters. However, the way we wrote the deviation in > docs/misra/deviations.rst doesn't cover the case this patch is dealing > with. docs/misra/deviations.rst only speaks of functions and macros > arguments. > > Should we rephrase docs/misra/deviations.rst in terms of ',' instead ? That's what I've requested elsewhere, yes. > Can ECLAR deal with it? I seem to vaguely recall Nicola saying it can, but if not then it surely can be made to do so. Jan From xen-devel-bounces@lists.xenproject.org Thu Mar 07 08:26:21 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 08:26:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689667.1074872 (Exim 4.92) (envelope-from ) id 1ri94q-000666-V9; Thu, 07 Mar 2024 08:26:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689667.1074872; Thu, 07 Mar 2024 08:26:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ri94q-00065z-R2; Thu, 07 Mar 2024 08:26:08 +0000 Received: by outflank-mailman (input) for mailman id 689667; Thu, 07 Mar 2024 08:26:07 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ri94p-00065t-UZ for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 08:26:07 +0000 Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [2a00:1450:4864:20::62a]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 5771c96d-dc5c-11ee-afda-a90da7624cb6; Thu, 07 Mar 2024 09:26:05 +0100 (CET) Received: by mail-ej1-x62a.google.com with SMTP id a640c23a62f3a-a456ab934eeso92771166b.0 for ; Thu, 07 Mar 2024 00:26:05 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id o7-20020a170906288700b00a42ed7421b8sm8088558ejd.93.2024.03.07.00.26.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Mar 2024 00:26:05 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 5771c96d-dc5c-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709799965; x=1710404765; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=Y7l0GZitSpPL4w6PpS6/l7z/DlCc0WejNdMFZiCxAnc=; b=GzcoKCTPWYehOQY5wPyoJ+4H/6eWv1o8/Ve5lNp8mTtgYeSj3fxTIwrqKDT94WEu/U 99Dd5wR+/ZSc/9XTvsDOLezYMab5ykZLyLi/k+z6aCejV819Zr57YPIZsovSAknkTESS GCEzrJKoY7FYk3enCXIodOgy96MqlqNB8xZOVPBFeSgTpNbc1FojGfuLJ2b0nd7yU/2I 7M7UXkcUZCUyQacS5TTYZQsA9TpnWYNZ4MaZ3WI4PY7/Pmk0bA+y9JRUpyXEJCAD9lqu M1jsblmKYPzmY6125KWU5U74o+a/4rIef2ZK5Y3CSrH4aqRqSkTQHbgGl2ARRucnOojS 2TIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709799965; x=1710404765; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Y7l0GZitSpPL4w6PpS6/l7z/DlCc0WejNdMFZiCxAnc=; b=kZju/1qk3ze4OxaFFpFBRc6+gKKQrnH8bk8J6nFAJmUDl/4Yc68urlssOvLqU8bAFw t90TW8YVyp695jC0dlvgks5rRnDDsNtyoupNySUzQb6etdrHPlgI3+qRUXocuSaJNjAf PAmFXcfTKDNbFfbEz/WiL6gIoHcC+VfVjq33qIQyJQ1IModIudUvT8iNMHUhy4KVssFs BzHjH4K0rmu506Npjz7/TAB6IYjN0lr0X8iAjQ89gfI/cOsraYUzCdj8hQlMMzoBTdAA GRfHbiCjxa+T4Hdo6JWwun6HN0ZIdnTvr5yOsRZ9IEehlOUMcTtGBYGkJ3dSWPdPa86n WssQ== X-Gm-Message-State: AOJu0YwF73iYshafsStXKoibZ5k7T04RFyDeljjBJB2QIB9uYahsB8fc byZmpiDWJAjatPxPhWKJCjLhvO9qbDg48enbjIOWFdk2AExptgGVq609zjuPBw== X-Google-Smtp-Source: AGHT+IHEARlUQzPah8TcatUtYqt3dhawpWIQ4/frE2MAr7wPon90pWCRXps08MIqR1RYX+mleSUEfw== X-Received: by 2002:a17:906:d0c7:b0:a45:b74c:6e14 with SMTP id bq7-20020a170906d0c700b00a45b74c6e14mr3409610ejb.57.1709799965382; Thu, 07 Mar 2024 00:26:05 -0800 (PST) Message-ID: <8b02fb20-2e4d-4a68-b633-417c964e38be@suse.com> Date: Thu, 7 Mar 2024 09:26:03 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/3] xen/x86: bzImage parse kernel_alignment Content-Language: en-US To: Stefano Stabellini Cc: xen-devel@lists.xenproject.org, Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu , Jason Andryuk References: <20240306185032.103216-1-jason.andryuk@amd.com> <20240306185032.103216-3-jason.andryuk@amd.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 07.03.2024 03:09, Stefano Stabellini wrote: > On Wed, 6 Mar 2024, Jason Andryuk wrote: >> Expand bzimage_parse() to return kernel_alignment from the setup_header. >> This will be needed if loading a PVH kernel at a physical offset to >> compensate for a reserved E820 region. >> >> Signed-off-by: Jason Andryuk > > Reviewed-by: Stefano Stabellini Acked-by: Jan Beulich with two remarks: >> --- a/xen/arch/x86/hvm/dom0_build.c >> +++ b/xen/arch/x86/hvm/dom0_build.c >> @@ -548,12 +548,14 @@ static int __init pvh_load_kernel(struct domain *d, const module_t *image, >> struct elf_binary elf; >> struct elf_dom_parms parms; >> paddr_t last_addr; >> + unsigned int align = 0; Strictly speaking this isn't needed here, yet, and would suffice when added in the next patch. But I'm okay with keeping it. >> --- a/xen/arch/x86/include/asm/bzimage.h >> +++ b/xen/arch/x86/include/asm/bzimage.h >> @@ -4,8 +4,7 @@ >> #include >> >> unsigned long bzimage_headroom(void *image_start, unsigned long image_length); >> - >> int bzimage_parse(void *image_base, void **image_start, >> - unsigned long *image_len); >> + unsigned long *image_len, unsigned int *align); Any particular reason for dropping the blank line? I'd prefer if it was kept, and I may take the liberty to respectively adjust the patch while committing. Jan From xen-devel-bounces@lists.xenproject.org Thu Mar 07 08:39:35 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 08:39:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689672.1074882 (Exim 4.92) (envelope-from ) id 1ri9Hm-00009d-56; Thu, 07 Mar 2024 08:39:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689672.1074882; Thu, 07 Mar 2024 08:39:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ri9Hm-00009V-26; Thu, 07 Mar 2024 08:39:30 +0000 Received: by outflank-mailman (input) for mailman id 689672; Thu, 07 Mar 2024 08:39:29 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ri9Hk-00009N-Un for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 08:39:28 +0000 Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [2a00:1450:4864:20::634]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 34af9da5-dc5e-11ee-a1ee-f123f15fe8a2; Thu, 07 Mar 2024 09:39:26 +0100 (CET) Received: by mail-ej1-x634.google.com with SMTP id a640c23a62f3a-a36126ee41eso80262166b.2 for ; Thu, 07 Mar 2024 00:39:26 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id fy21-20020a170906b7d500b00a45c8b6e965sm753680ejb.3.2024.03.07.00.39.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Mar 2024 00:39:25 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 34af9da5-dc5e-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709800766; x=1710405566; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=we4U2tzwhZPs/jF6fgksLO1+xacGitITsRSu/NC2LTM=; b=FbQdwjYrRCGe60Jx/B5zZFt17USKlzIymQhtUvx/obPT0/3DAaqQAxjkQuU7suaZ1q wKhoiR6aP47dZBnhtr32NRREPndjhUaCyY8TnVZHwqEJBmdrdySit8wSsviH3zU/bjU6 8WVZxeYJxYGDw8pgn/VnIB7jZ9oF83P7E2g0fBwiu7lInXeQtfmjm0/3dUzW9fV6YAn4 lzdzzJyuW5jJ4LTSAppN/+TRFupqYThQwKEbihxxYw2ttcYZ8qJiIePrbNZ4PhETpp9Y IkuulFi60xPLLC2CWbGLK0n1fWm5TZEMhr+uWoqyC3LY6wieIkoYudCoexWbVSaG2yj7 a6Cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709800766; x=1710405566; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=we4U2tzwhZPs/jF6fgksLO1+xacGitITsRSu/NC2LTM=; b=WgYSYMWsA5Kgi1m9ITdfTpGDFjD8xQneENpPpotil9oVTnk4k0QqfUeuRAufZNxmb+ rt4/NOO8kFOsTNSSGLDfg3fiXdEjc6nFYBhccBGaY0pVISwRTgFADTyySh/NgO8GTGw6 cinJgcrXhNHKD7/kV+IwQfRXBMOfmvTZAnV+D16EjSokYIwureNRvQ9J/5HWvoHd0fWQ j3Hz9/jBpV4SO2kTvyGMaR14FcSonkh/SFpqjwSfvCr5AwbXcd5qP4yKTFm0iqxhDaur ozCN4b82fH6rD4O29miSU6ZMfOSo/YeN1+whCfNnsn3xgcZscru6s632fCmfnGDv/Kyt WQvA== X-Forwarded-Encrypted: i=1; AJvYcCU0yKxiJ6/Sbl3oQAhyNug3YR15NvJMsl3HRGjnG7U0LIZRdWRaOnQziDRXZsCKFtT0EUncazBKe/nxNDul7EawD086jbYoYYUEmci3MTQ= X-Gm-Message-State: AOJu0YwAN5hNME0qFWGoGLKSnyaDY0rt/F5+7ssg3OUOis1IQxqKxQVR Ug3+kp4uMkg9AHp1z/F+XhYSaf88iMHHb0EiZ/S7UirvCrhjaySaoaWAcfumaQ== X-Google-Smtp-Source: AGHT+IFrCLnJndWLjMsx1taV4EjvErmrHUJ1/I6GLZkn9emWz5Ygxf6qQmfpI71cokFqCZaay0puMw== X-Received: by 2002:a17:906:3e48:b0:a45:a9da:cc38 with SMTP id t8-20020a1709063e4800b00a45a9dacc38mr5059392eji.7.1709800765975; Thu, 07 Mar 2024 00:39:25 -0800 (PST) Message-ID: <962cad57-21a8-4882-a23a-95add04cac9b@suse.com> Date: Thu, 7 Mar 2024 09:39:24 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [BUG]i2c_hid_acpi broken with 4.17.2 on Framework Laptop 13 AMD Content-Language: en-US To: =?UTF-8?Q?S=C3=A9bastien_Chaumat?= Cc: Mario Limonciello , Juergen Gross , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , xen-devel@lists.xenproject.org References: <77c1c05d-a0a0-4292-9257-9b7fbebee0e3@suse.com> <2859ad22-8714-4628-8142-fc77fc2072c3@amd.com> <214585d5-689d-4ba6-bd48-359428a7ed8f@amd.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 06.03.2024 18:28, Sébastien Chaumat wrote: > Reasoning backward (using a kernel without the pinctrl_amd driver to >> ensure xen only is at stake) : >> checking the diff in IOAPIC between bare metal and xen (IRQ7 is on >> pin07 on APIC ) >> >> using kernel argument : apic=debug >> >> bare metal : >> [ 0.715330] fedora kernel: ... APIC VERSION: 81050010 >> ... >> [ 0.715433] fedora kernel: pin07, disabled, edge , high, V(00), >> IRR(0), S(0), physical, D(0000), M(0) >> >> xen : >> [ 2.249582] fedora kernel: ... APIC VERSION: 00000014 >> ... >> [ 2.249730] fedora kernel: pin07, disabled, level, low , V(60), >> IRR(0), S(0), physical, D(0000), M(0) >> >> So the APIC table is not the same. >> >> As strange as it looks the (IOAPIC 0) pin07 is correctly described by the >> APIC in xen but yet differently than in baremetal. >> But the APIC message comes long after the >> [ 1.833145] fedora kernel: xen: registering gsi 7 triggering 0 polarity >> 1 >> >> so I wonder if the APIC pin07 info had any influence. >> >> Finally found the fix : adding ioapic_ack=new to xen boot parameters. > Not only the trackpad is now working but also the ACPI Embedded Controller > which is completely disabled. Hmm, interesting. From someone else's laptop many years ago I had actually an indication in the opposite direction: That didn't work because of our defaulting to new (no directed EOI in sight yet back at that time). I wonder if overriding the ack method isn't actually just papering over the underlying actual issue here, whatever that is. IOW with the edge vs level mismatch addressed I'd hope the override could then be dropped again. Jan From xen-devel-bounces@lists.xenproject.org Thu Mar 07 08:40:38 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 08:40:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689674.1074892 (Exim 4.92) (envelope-from ) id 1ri9Ir-0001aU-Dx; Thu, 07 Mar 2024 08:40:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689674.1074892; Thu, 07 Mar 2024 08:40:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ri9Ir-0001aN-AU; Thu, 07 Mar 2024 08:40:37 +0000 Received: by outflank-mailman (input) for mailman id 689674; Thu, 07 Mar 2024 08:40:36 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ri9Iq-0001aD-AS for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 08:40:36 +0000 Received: from NAM02-DM3-obe.outbound.protection.outlook.com (mail-dm3nam02on20600.outbound.protection.outlook.com [2a01:111:f403:2405::600]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 5d31fcfe-dc5e-11ee-afda-a90da7624cb6; Thu, 07 Mar 2024 09:40:34 +0100 (CET) Received: from CH0PR03CA0417.namprd03.prod.outlook.com (2603:10b6:610:11b::6) by DS7PR12MB8274.namprd12.prod.outlook.com (2603:10b6:8:da::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.26; Thu, 7 Mar 2024 08:40:30 +0000 Received: from CH1PEPF0000A347.namprd04.prod.outlook.com (2603:10b6:610:11b:cafe::b0) by CH0PR03CA0417.outlook.office365.com (2603:10b6:610:11b::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7339.39 via Frontend Transport; Thu, 7 Mar 2024 08:40:30 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by CH1PEPF0000A347.mail.protection.outlook.com (10.167.244.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7362.11 via Frontend Transport; Thu, 7 Mar 2024 08:40:30 +0000 Received: from SATLEXMB06.amd.com (10.181.40.147) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 7 Mar 2024 02:40:29 -0600 Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB06.amd.com (10.181.40.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 7 Mar 2024 02:40:29 -0600 Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.35 via Frontend Transport; Thu, 7 Mar 2024 02:40:28 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 5d31fcfe-dc5e-11ee-afda-a90da7624cb6 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Q8lvsILVBXB3cHShi4eZ8xH762Xy5bExIKOsxYL2oIK2IR3SwwjPFe846xx36nfgQR5bR3q+uNITZWOZRG62hXRcj3RkChzaP0VbJ2OPkSksPTwgkHtSfChZwWnneiQmmUkLsoWzVaxAOYS1l4mGW9rMVDYYiLyvIMZARYvk7THEUW64pfC05qWfewu2vToV8UwIjmMpfvQTa3l4Gd9YX0lWkkDRanBKTkiPt6UjwOjIyhij6epllslkKWI1KpeyQDe8pp1Kt7pMUe3SoCT/R/MK/Xl5njSuIjpnuDGt8uci9zC2iq5d1In0HKt0A9z0wkoympMqEb3ac+8bh+mt5A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=w1nMzjLtwMORyPPhkWOuHDn8NKVpR+bJSH8OQwqLg9Q=; b=lOUXweC3ZmC/4gtNW7mbFn9KKjufZ7J7K2bcEITIl8wXuwgrvcTUrFizQFYRirA4feooo41H6X6vwwiSdqkwkAoWyirb9kzmHTun5zw3pX92LjS6CPWcT7EikK7iUXPmNl2kLR9CjNCdF6R3TKEo2oHHV/QCIWHjS58d/vgcY4mUWY7t8PtP7b4jjbgFnOJ57w/7a0wM/w5aXUCdzCwxFfHwm6ZsvqFbqbe/e/bd3AYAhv9mQCGA9pPzmGIhUYi+bm2JIh3pjjiWEFUzV7NVELWWMVTaC8aFeC2iuVb+WZeyuwon8gcoiw1f8o4Q2pxkBiYZgmoO6K7TYLnCMl390Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=linaro.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=w1nMzjLtwMORyPPhkWOuHDn8NKVpR+bJSH8OQwqLg9Q=; b=sHIhmXj27HRzV/CA4j3OOVai8GhW5kHtX0FNbrpLqg3Et2glBLAh5ozLixq6nXXhxBv3epxLnzm60d1W8t9nxgVsuQ2T/cmam4/A6mJsBdGtVEvJ7uEBRVxt+IETaS6GJDYd4XzJaxykffx3ouShT388UPBGqf1DL+594bNvaOU= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C Message-ID: <3cb1b056-59a7-4ffe-856d-e45aac1936a9@amd.com> Date: Thu, 7 Mar 2024 09:40:22 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH v2] xen/arm: improve handling of load/store instruction decoding To: =?UTF-8?Q?Alex_Benn=C3=A9e?= , CC: , , , Manos Pitsidianakis References: <20240306165621.3819343-1-alex.bennee@linaro.org> Content-Language: en-US From: Michal Orzel In-Reply-To: <20240306165621.3819343-1-alex.bennee@linaro.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH1PEPF0000A347:EE_|DS7PR12MB8274:EE_ X-MS-Office365-Filtering-Correlation-Id: 14931be4-006c-4c79-ef34-08dc3e823f1e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: XelT6DKEcX58PG3CHNPqQh9OBa9Ljt2TGG7mJ+SJn55jOUd8vckVajWjE4N2qGhENRctQPmGPOdO/XBulZW62VV4fKRExR73DdK60vHU2hCev6on8/yW8WXEdkduGXmlOsU60YKmDvDwEJNtrV9iufFPGgKWozXAnzpOXXvOlxg74AXiK1r7+1vHqLJi1TA1QnpgeX/rdHJT/VBZOSQi50G40l47HNgpavEt6Pmf6AUx9DiChkuzpDzbm9KOKHCKdBMw5Ja1DNFhzFP5NVHecUIR1j2oExoJW+3FP/EyZJFcdF4fsNJaJfpFhwENIGZCS2M4S5HeUoCmwztYMyPZMFfoDtvyqWOfFxU2+rR/r+Gr7klNB+gaLEjwonhSQl84VouhyycRKTdGl7AfBuIu03lm+lAhH5BpC159V4/ciWmawWH6G6SO/G/WCcrkCqvhhAvQNyLW9b7K9zWie44B3taRRiM7a7uJAKtef8SQaCZgeKtGGIXGIZe8L2s/27onPjuBHozuqzIXSU5npFexoJU7Zft0ZkLIiRlWsEHpI/neSFAuBiBVTrFYEMVMkI6dQfyIFxV6DeOA8JO/yAkAsRwL0fQdR3NwQthw+rXhlFMifIcCX56uwwX0sIlBrZKs3PAvXuUg/HX0HUM4CBPuH0BssPNSKtTRasf4jpoYtOFHljhtz8XgJYitwDkAfNTJDtA3vX+O0EhHpTZD6xvAIxahZo1CPK+ocpMs1dgqRzM2DzQk0xgYVaHx4coJlclF X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(82310400014)(36860700004)(376005);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Mar 2024 08:40:30.4805 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 14931be4-006c-4c79-ef34-08dc3e823f1e X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CH1PEPF0000A347.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR12MB8274 Hi Alex, NIT: RFC tag is no longer needed. On 06/03/2024 17:56, Alex Bennée wrote: > > > While debugging VirtIO on Arm we ran into a warning due to memory > being memcpy'd across MMIO space. While the bug was in the mappings > the warning was a little confusing: > > (XEN) d47v2 Rn should not be equal to Rt except for r31 > (XEN) d47v2 unhandled Arm instruction 0x3d800000 > (XEN) d47v2 Unable to decode instruction > > The Rn == Rt warning is only applicable to single register load/stores > so add some verification steps before to weed out unexpected accesses. > > While at it update the Arm ARM references to the latest version of the > documentation. > > Signed-off-by: Alex Bennée > Cc: Manos Pitsidianakis Move the CC line after --- so that it's not included in the final commit msg. > > --- > v2 > - use single line comments where applicable > - update Arm ARM references > - use #defines for magic numbers > --- > xen/arch/arm/decode.c | 35 ++++++++++++++++++++------ > xen/arch/arm/decode.h | 57 ++++++++++++++++++++++++++++++++++++++----- > 2 files changed, 79 insertions(+), 13 deletions(-) > > diff --git a/xen/arch/arm/decode.c b/xen/arch/arm/decode.c > index 2537dbebc1..73a88e4701 100644 > --- a/xen/arch/arm/decode.c > +++ b/xen/arch/arm/decode.c > @@ -87,15 +87,36 @@ static int decode_arm64(register_t pc, mmio_info_t *info) > return 1; > } > > + /* Check this is a load/store of some sort */ > + if ( (opcode.top_level.op1 & TL_LDST_OP1_MASK) != TL_LDST_OP1_VALUE ) > + { > + gprintk(XENLOG_ERR, "Not a load/store instruction op1=%u\n", > + opcode.top_level.op1); > + goto bad_loadstore; > + } > + > + /* We are only expecting single register load/stores */ > + if ( (opcode.ld_st.op0 & LS_SREG_OP0_MASK) != LS_SREG_OP0_VALUE ) > + { > + gprintk(XENLOG_ERR, "Not single register load/store op0=%u\n", NIT: missing 'a' between Not and single > + opcode.ld_st.op0); > + goto bad_loadstore; > + } > + > /* > - * Refer Arm v8 ARM DDI 0487G.b, Page - C6-1107 > - * "Shared decode for all encodings" (under ldr immediate) > - * If n == t && n != 31, then the return value is implementation defined > - * (can be WBSUPPRESS, UNKNOWN, UNDEFINED or NOP). Thus, we do not support > - * this. This holds true for ldrb/ldrh immediate as well. > + * Refer Arm v8 ARM DDI 0487J.a, Page - K1-12586 > + * > + * STR (immediate) CONSTRAINED UNPREDICTABLE behaviour > + * > + * "If the instruction encoding specifies pre-indexed addressing or > + * post-indexed addressing, and n == t && n != 31, then one of the > + * following behaviors must occur:" UNDEFINED, NOP or UNKNOWN > + * > + * Execution @ EL0/EL1 when HCR_EL2.TIDCP is 1 traps to EL2 with > + * EC = 0. > * > - * Also refer, Page - C6-1384, the above described behaviour is same for > - * str immediate. This holds true for strb/strh immediate as well > + * This also hold true for LDR (immediate), Page K1-12581 and > + * the RB/RH variants of both. > */ > if ( (opcode.ldr_str.rn == opcode.ldr_str.rt) && (opcode.ldr_str.rn != 31) ) > { > diff --git a/xen/arch/arm/decode.h b/xen/arch/arm/decode.h > index 13db8ac968..188114a71e 100644 > --- a/xen/arch/arm/decode.h > +++ b/xen/arch/arm/decode.h > @@ -24,17 +24,54 @@ > #include > > /* > - * Refer to the ARMv8 ARM (DDI 0487G.b), Section C4.1.4 Loads and Stores > - * Page 318 specifies the following bit pattern for > - * "load/store register (immediate post-indexed)". > + * Refer to the ARMv8 ARM (DDI 0487J.a) > * > - * 31 30 29 27 26 25 23 21 20 11 9 4 0 > + * Section C A64 Instruct Set Encoding This line is not needed > + * > + * C4.1 A64 instruction set encoding: NIT: I would put a comma after section number i.e. C4.1, A64 ... The same would apply in other places. > + * > + * 31 30 29 28 25 24 0 > * ___________________________________________________________________ > - * |size|1 1 1 |V |0 0 |opc |0 | imm9 |0 1 | Rn | Rt | > - * |____|______|__|____|____|__|_______________|____|_________|_______| > + * |op0 | x x | op1 | | > + * |____|______|______|_______________________________________________| > + * > + * op0 = 0 is reserved I'm not sure how to read it. It is reserved provided op1 is also 0. > + * op1 = x1x0 for Loads and Stores > + * > + * Section C4.1.88 Loads and Stores Missing colon at the end? > + * > + * 31 28 27 26 25 24 23 22 21 16 15 12 11 10 9 0 > + * ___________________________________________________________________ > + * | op0 | 1 | op1 | 0 | op2 | | op3 | | op4 | | > + * |________|___|_____|___|_____|__|__________|______|_____|__________| > + * > + * Page C4-653 Load/store register (immediate post-indexed) > + * > + * 31 30 29 27 26 25 24 23 22 21 20 12 11 10 9 5 4 0 > + * ___________________________________________________________________ > + * |size|1 1 1 |V | 0 0 | opc |0 | imm9 | 0 1 | Rn | Rt | > + * |____|______|__|_____|_____|__|_______________|_____|______|_______| > */ > union instr { > uint32_t value; > + struct { > + unsigned int ign2:25; Here, your numeration of ignore fields is in descending order (starting from lsb) but .., > + unsigned int op1:4; /* instruction class */ > + unsigned int ign1:2; > + unsigned int op0:1; /* value = 1b */ Why op0 = 0b1 ? This structure represents the generic bit layout (the emulation deals with single ldr/str). I would drop this comment. > + } top_level; > + struct { > + unsigned int ign1:10; here in ascending. Let's be consistent (fixed fields are in ascending order). > + unsigned int op4:2; > + unsigned int ign2:4; > + unsigned int op3:6; > + unsigned int ign3:1; > + unsigned int op2:2; > + unsigned int fixed1:1; /* value = 0b */ > + unsigned int op1:1; > + unsigned int fixed2:1; /* value = 1b */ > + unsigned int op0:4; > + } ld_st; > struct { > unsigned int rt:5; /* Rt register */ > unsigned int rn:5; /* Rn register */ > @@ -49,6 +86,14 @@ union instr { > } ldr_str; > }; > > +/* Top level load/store encoding */ > +#define TL_LDST_OP1_MASK 0b0101 > +#define TL_LDST_OP1_VALUE 0b0100 > + > +/* Load/store single reg encoding */ > +#define LS_SREG_OP0_MASK 0b0011 > +#define LS_SREG_OP0_VALUE 0b0011 > + > #define POST_INDEX_FIXED_MASK 0x3B200C00 > #define POST_INDEX_FIXED_VALUE 0x38000400 > > -- > 2.39.2 > > ~Michal From xen-devel-bounces@lists.xenproject.org Thu Mar 07 08:41:39 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 08:41:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689677.1074902 (Exim 4.92) (envelope-from ) id 1ri9Jq-00027p-MR; Thu, 07 Mar 2024 08:41:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689677.1074902; Thu, 07 Mar 2024 08:41:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ri9Jq-00027i-Jc; Thu, 07 Mar 2024 08:41:38 +0000 Received: by outflank-mailman (input) for mailman id 689677; Thu, 07 Mar 2024 08:41:37 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ri9Jp-00027Q-5W; Thu, 07 Mar 2024 08:41:37 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ri9Jp-0006ns-0k; Thu, 07 Mar 2024 08:41:37 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ri9Jo-0005dJ-IW; Thu, 07 Mar 2024 08:41:36 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1ri9Jo-0004IY-I6; Thu, 07 Mar 2024 08:41:36 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=qAlLGBl71XiqBGjZ2Jy/MDAgGXrpk+/ttchQNXAR5Xo=; b=FzwOffd1peFR6MMwY0VrMZY0P8 Mau8lYYtiTIfzMgL9qerRdcCuCaES8fiv1q63q94nA+KnWo0eLasxsaN+AoVK0Kv4+R53NQl5Qd7f B4q4Y1CdL87gdoQtGMgZNO9JdcyWJxopZlSxNeyRIpY2VE3WkJcuaakD48VErtjyHlas=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-6.1 test] 184922: tolerable FAIL - PUSHED X-Osstest-Failures: linux-6.1:test-amd64-amd64-xl-multivcpu:guest-localmigrate/x10:fail:heisenbug linux-6.1:test-armhf-armhf-xl-credit1:xen-boot:fail:heisenbug linux-6.1:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-6.1:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-6.1:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-6.1:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-6.1:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-6.1:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking linux-6.1:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-6.1:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-6.1:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-6.1:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking linux-6.1:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-6.1:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-6.1:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-6.1:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-6.1:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-6.1:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-6.1:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-6.1:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-6.1:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-6.1:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-6.1:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-6.1:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-6.1:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-6.1:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-6.1:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-6.1:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-6.1:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-6.1:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-6.1:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-6.1:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-6.1:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-6.1:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-6.1:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking linux-6.1:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-6.1:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-6.1:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-6.1:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking linux-6.1:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking linux-6.1:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking linux-6.1:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking linux-6.1:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking linux-6.1:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking linux-6.1:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking linux-6.1:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-6.1:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-6.1:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: linux=61adba85cc40287232a539e607164f273260e0fe X-Osstest-Versions-That: linux=a3eb3a74aa8c94e6c8130b55f3b031f29162868c From: osstest service owner Date: Thu, 07 Mar 2024 08:41:36 +0000 flight 184922 linux-6.1 real [real] flight 184929 linux-6.1 real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/184922/ http://logs.test-lab.xenproject.org/osstest/logs/184929/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-multivcpu 20 guest-localmigrate/x10 fail pass in 184929-retest test-armhf-armhf-xl-credit1 8 xen-boot fail pass in 184929-retest Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-credit1 15 migrate-support-check fail in 184929 never pass test-armhf-armhf-xl-credit1 16 saverestore-support-check fail in 184929 never pass test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail like 184831 test-armhf-armhf-libvirt 16 saverestore-support-check fail like 184841 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop fail like 184841 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 184841 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop fail like 184841 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop fail like 184841 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop fail like 184841 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184841 test-amd64-amd64-libvirt-xsm 15 migrate-support-check fail never pass test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-check fail never pass test-arm64-arm64-xl 15 migrate-support-check fail never pass test-arm64-arm64-xl 16 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 15 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-check fail never pass test-armhf-armhf-libvirt 15 migrate-support-check fail never pass test-amd64-amd64-libvirt-qcow2 14 migrate-support-check fail never pass test-amd64-amd64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-check fail never pass test-arm64-arm64-xl-vhd 14 migrate-support-check fail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-check fail never pass version targeted for testing: linux 61adba85cc40287232a539e607164f273260e0fe baseline version: linux a3eb3a74aa8c94e6c8130b55f3b031f29162868c Last test of basis 184841 2024-03-02 08:11:10 Z 5 days Testing same since 184922 2024-03-06 15:13:36 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Abdun Nihaal Adrian Hunter Alex Deucher Alexander Lobakin Alexander Ofitserov Alexander Stein Alexandru Gagniuc Andrew Morton Andy Shevchenko Anna Schumaker Ard Biesheuvel Ard Biesheuvel Arnd Bergmann Arturas Moskvinas Bartosz Golaszewski Bjorn Andersson Bjorn Andersson Bjorn Helgaas Borislav Petkov (AMD) Borislav Petkov Christian Brauner Christian König Christophe Kerello Chuck Lever Chunyan Zhang Clancy Shang Colin Ian King Curtis Klein Dai Ngo Daniel Borkmann Daniel Vetter Dave Hansen David Disseldorp David Howells David S. Miller David Sterba Davide Caratti Dimitris Vlachos Dmitry Baryshkov Dmitry Torokhov Doug Smythies Edward Lo Elad Nachman Elson Roy Serrao Eniac Zhang Eric Dumazet Evgeniy Baskov Filipe Manana Florian Fainelli Florian Westphal Frank Li Gaurav Batra Geert Uytterhoeven Geliang Tang Greg Kroah-Hartman Gustavo A. R. Silva Han Xu Hans de Goede Hans Peter Herbert Xu Hou Zhiqiang Ido Schimmel Ignat Korchagin Ingo Molnar Ivan Semenov Jakub Kicinski Jakub Raczynski Janaki Ramaiah Thota Javier Carrasco Jeff Layton Jeremy Kerr Jia-Ju Bai Jiri Bohac Jiri Slaby (SUSE) Jiri Slaby Joerg Roedel Johan Hovold Johannes Berg Jon Hunter Jonas Dreßler Juergen Gross Justin Iurman Kai-Heng Feng Kees Cook Kirill A. Shutemov Konstantin Komarov Krzysztof Kozlowski Kuniyuki Iwashima Leon Romanovsky Leon Romanovsky Lin Ma Linus Torvalds Linux Kernel Functional Testing Lorenzo Pieralisi Louis DeLosSantos Luca Ceresoli Luca Weiss Luiz Augusto von Dentz Lukasz Majewski Manivannan Sadhasivam Manivannan Sadhasivam Marek Vasut Mario Limonciello Martin Blumenstingl Martin K. Petersen Martin KaFai Lau Martynas Pumputis Mateusz Jończyk Matthew Auld Matthieu Baerts (NGI0) Maximilian Heyne Michael Ellerman Mickaël Salaün Mike Christie Min-Hua Chen Ming Lei Miquel Raynal Neil Armstrong NeilBrown Nicolas Belin Nikolay Aleksandrov Oleksij Rempel Pablo Neira Ayuso Palmer Dabbelt Paolo Abeni Paolo Bonzini Patrisious Haddad Pavel Machek (CIP) Pawan Gupta Peng Ma Petr Machata Pucha Himasekhar Reddy (A Contingent worker at Intel) Rafael J. Wysocki Rob Herring Robert Foss Ron Economos Ryosuke Yasuoka Sabrina Dubroca Salvatore Bonaccorso Saravana Kannan Sasha Levin Sean Christopherson Sebastian Reichel SeongJae Park Shawn Guo Shiraz Saleem Shuah Khan Steev Klimaszewski Stefan Wahren Stephen Boyd Steve Morvai Steven Rostedt (Google) Suren Baghdasaryan Tadeusz Struk Takashi Iwai Takashi Sakamoto Tasos Sahanidis Tetsuo Handa Thierry Reding Tim Schumacher Tomas Krcka Tony Nguyen Ulf Hansson Vicki Pfau Vinod Koul Will Deacon Xiaowei Bao Xiu Jianfeng Yang Shi Yann Sionneau Ye Bin Yi Zhao Ying Hsu Yunjian Wang Yuntao Wang Zijun Hu Zong Li jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-amd64-dom0pvh-xl-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-freebsd11-amd64 pass test-amd64-amd64-freebsd12-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-examine-bios pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 fail test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-amd64-dom0pvh-xl-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-amd64-xl-multivcpu fail test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-amd64-xl-pvshim pass test-amd64-amd64-pygrub pass test-amd64-amd64-libvirt-qcow2 pass test-armhf-armhf-libvirt-qcow2 pass test-amd64-amd64-libvirt-raw pass test-arm64-arm64-libvirt-raw pass test-armhf-armhf-libvirt-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-examine-uefi pass test-amd64-amd64-xl-vhd pass test-arm64-arm64-xl-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these 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 : hint: The 'hooks/update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-receive' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. To xenbits.xen.org:/home/xen/git/linux-pvops.git a3eb3a74aa8c9..61adba85cc402 61adba85cc40287232a539e607164f273260e0fe -> tested/linux-6.1 From xen-devel-bounces@lists.xenproject.org Thu Mar 07 09:30:43 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 09:30:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689694.1074915 (Exim 4.92) (envelope-from ) id 1riA56-00024I-Cp; Thu, 07 Mar 2024 09:30:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689694.1074915; Thu, 07 Mar 2024 09:30:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riA56-00024B-AH; Thu, 07 Mar 2024 09:30:28 +0000 Received: by outflank-mailman (input) for mailman id 689694; Thu, 07 Mar 2024 09:30:27 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riA55-000245-5F for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 09:30:27 +0000 Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [2607:f8b0:4864:20::82c]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 53cf966e-dc65-11ee-afda-a90da7624cb6; Thu, 07 Mar 2024 10:30:25 +0100 (CET) Received: by mail-qt1-x82c.google.com with SMTP id d75a77b69052e-42f13eebabbso2921141cf.3 for ; Thu, 07 Mar 2024 01:30:25 -0800 (PST) Received: from localhost ([213.195.118.74]) by smtp.gmail.com with ESMTPSA id he29-20020a05622a601d00b0042ee1ff302esm4843954qtb.66.2024.03.07.01.30.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Mar 2024 01:30:24 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 53cf966e-dc65-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709803824; x=1710408624; darn=lists.xenproject.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=5EkqeA+Q9vgb52Bj9IdDE0G1TqzZ7hUIGlxQCNPLfKQ=; b=dcbI7gwZysLOQQ2RcSkS/nycuodVrhaO8wGOs9GMHgqIrRdS5e08zCTHCElnekgQDK Sye+QzsBH21g2XfooKnmVJQgbifaW2bfkF3rUSlTO+X1zPT8rNwhH4RNX2S6DiGjDMRR gaknPfr8GBQrd9I5elIrM/oSUoVp7EIpygpbc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709803824; x=1710408624; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=5EkqeA+Q9vgb52Bj9IdDE0G1TqzZ7hUIGlxQCNPLfKQ=; b=v3rC6w1EL1vYAoEHmdJv29ibwy/Px82KHOQfXh8Vh/BVUEBkrAfo+Xcw/SgeovQdnI jhEQHSvtdeS6KZAcIrUCE7w/kE98KJqWurMw4PM4j3UHqMSjzxZNLWJCX6W80JLokEfY ZSWL65C5VZgNKOEQb4m4CukcBviRhgcvUjVBuD/R+6ZGUlh0n0RBrvKLcRZ0ztv9NWj/ 42LknmrRPe0tIHhSRx56o7U9C2HS0V4zCAwyfaTWJvFJVXoTKGh9ZkgKtJ338ZGG2fo5 zXXqo08r8BN8LzZYiZ3eIAzzHVxs+ZpY0WI0x+9kxJQc1sP70NVUihULYQZZOEoRYG2n tYhg== X-Gm-Message-State: AOJu0YzHzwwwd/k9BI1dWDDIBmFw4c5JTmonWI/ujSMjcZMKWhle6j8J 8FZyX7Bci7y5OiTSVhDyLp8N8ZB5ecHidozsfdI7bNJEAhMB0HeBs4xP5JHTU6Y= X-Google-Smtp-Source: AGHT+IHJyWl/nytobRd3BzNxS/KpUyq50cBg5xwCWUDkCilRbVXXPTokdYnKO2qPQq+DLNi2aV7dPg== X-Received: by 2002:ac8:5bc4:0:b0:42e:da42:9c73 with SMTP id b4-20020ac85bc4000000b0042eda429c73mr9321418qtb.57.1709803824476; Thu, 07 Mar 2024 01:30:24 -0800 (PST) Date: Thu, 7 Mar 2024 10:30:22 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jason Andryuk Cc: xen-devel@lists.xenproject.org, Jan Beulich , Andrew Cooper , Wei Liu , George Dunlap , Julien Grall , Stefano Stabellini Subject: Re: [PATCH 3/3] x86/PVH: Support relocatable dom0 kernels Message-ID: References: <20240306185032.103216-1-jason.andryuk@amd.com> <20240306185032.103216-4-jason.andryuk@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20240306185032.103216-4-jason.andryuk@amd.com> On Wed, Mar 06, 2024 at 01:50:32PM -0500, Jason Andryuk wrote: > Xen tries to load a PVH dom0 kernel at the fixed guest physical address > from the elf headers. For Linux, this defaults to 0x1000000 (16MB), but > it can be configured. > > Unfortunately there exist firmwares that have reserved regions at this > address, so Xen fails to load the dom0 kernel since it's not RAM. > > The PVH entry code is not relocatable - it loads from absolute > addresses, which fail when the kernel is loaded at a different address. > With a suitably modified kernel, a reloctable entry point is possible. > > Add the XENFEAT_pvh_relocatable flag to let a kernel indicate that it > supports a relocatable entry path. > > Change the loading to check for an acceptable load address. If the > kernel is relocatable, support finding an alternate load address. > > Linux cares about its physical alignment. This can be pulled out of the > bzImage header, but not from the vmlinux ELF file. If an alignment > can't be found, use 2MB. While I'm fine with having a Linux specific way, there needs to be a generic way of passing the alignment for non-bzImage kernels. ELF program headers have an align field, would that be suitable to use? In elf_parse_binary() where the p{start,end} is calculated, you could also fetch the p_offset from the lower found program header and use it as the required alignment. Would that be OK for Linux and maybe avoid having to fiddle with the bzImage header? FWIW it is likely fine for FreeBSD. > > Signed-off-by: Jason Andryuk I created a gitlab ticket for this: https://gitlab.com/xen-project/xen/-/issues/180 If you want to reference it. > --- > Put alignment as a new ELF note? Presence of that note would indicate > relocation support without a new XENFEAT flag. > > Default alignment to a multiple of 2MB to make more cases work? It has > to be a power of two, and a multiple might allow loading a customized > kernel. A larger alignment would limit the number of possible load > locations. > --- > xen/arch/x86/hvm/dom0_build.c | 109 ++++++++++++++++++++++++++++++++++ > xen/include/public/features.h | 5 ++ > 2 files changed, 114 insertions(+) > > diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c > index bbae8a5645..34d68ee8fb 100644 > --- a/xen/arch/x86/hvm/dom0_build.c > +++ b/xen/arch/x86/hvm/dom0_build.c > @@ -537,6 +537,109 @@ static paddr_t __init find_memory( > return INVALID_PADDR; > } > > +static bool __init check_load_address( > + const struct domain *d, const struct elf_binary *elf) > +{ > + paddr_t kernel_start = (paddr_t)elf->dest_base & PAGE_MASK; > + paddr_t kernel_end = ROUNDUP((paddr_t)elf->dest_base + elf->dest_size, > + PAGE_SIZE); You can use PAGE_ALIGN() here (and below) for simplicity. > + unsigned int i; > + > + /* > + * The memory map is sorted and all RAM regions starts and sizes are > + * aligned to page boundaries. > + */ > + for ( i = 0; i < d->arch.nr_e820; i++ ) > + { > + paddr_t start = d->arch.e820[i].addr; > + paddr_t end = d->arch.e820[i].addr + d->arch.e820[i].size; Since the memory map is sorted you can end the loop once end start >= kernel_end? As further regions are past the kernel destination. > + > + if ( start <= kernel_start && > + end >= kernel_end && > + d->arch.e820[i].type == E820_RAM ) > + return true; > + } > + > + return false; > +} > + > +/* > + * Find an e820 RAM region that fits the kernel at a suitable alignment. > + */ This (and other) comment seems to fit in a single line: /* ... */. > +static paddr_t find_kernel_memory( > + const struct domain *d, struct elf_binary *elf, paddr_t align) elf can be const AFAICT. > +{ > + paddr_t kernel_start = (paddr_t)elf->dest_base & PAGE_MASK; > + paddr_t kernel_end = ROUNDUP((paddr_t)elf->dest_base + elf->dest_size, > + PAGE_SIZE); > + unsigned int i; > + > + /* > + * The memory map is sorted and all RAM regions starts and sizes are > + * aligned to page boundaries. > + */ > + for ( i = 0; i < d->arch.nr_e820; i++ ) > + { > + paddr_t start = d->arch.e820[i].addr; > + paddr_t end = d->arch.e820[i].addr + d->arch.e820[i].size; > + paddr_t kstart, kend, offset; > + > + if ( d->arch.e820[i].type != E820_RAM ) > + continue; > + > + if ( d->arch.e820[i].size < elf->dest_size ) > + continue; > + > + if ( end < kernel_end ) > + continue; I'm not sure I understand this check, why would we refuse regions below the fixed kernel end? Those should be equally suitable if big enough and meeting the alignment requirements. > + > + kstart = ROUNDUP(start, align); > + offset = kstart - kernel_start; > + kend = kernel_end + offset; > + > + if ( kend <= end ) > + return offset; Why not return this as an address to use to load the kernel instead of an offset from dest_base? That would also make the calculations easier IMO. > + } This should be limited to a range below 4GB. > + return 0; > +} > + > +/* > + * Check the kernel load address, and adjust if necessary and possible. > + */ > +static bool __init adjust_load_address( > + const struct domain *d, struct elf_binary *elf, struct elf_dom_parms *parms, > + paddr_t align) > +{ > + paddr_t offset; > + > + /* Check load address */ > + if ( check_load_address(d, elf) ) > + return true; > + > + if ( !test_bit(XENFEAT_pvh_relocatable, parms->f_supported) ) > + { > + printk("Address conflict and %pd kernel is not relocatable\n", d); > + return false; > + } > + > + if ( align == 0 ) > + align = MB(2); > + > + offset = find_kernel_memory(d, elf, align); > + if ( offset == 0 ) > + { > + printk("Failed find a load offset for the kernel\n"); > + return false; > + } > + > + printk("Adjusting load address by %#lx\n", offset); I think this would be more helpful if the previous and the new ranges are printed, as I'm not sure the previous dest_base is printed, in which case the offset doesn't help much. I would do: if ( opt_dom0_verbose ) printk("relocating kernel from [%lx, %lx] -> [%lx, %lx]\n", ...); > + elf->dest_base += offset; > + parms->phys_entry += offset; As noted above, I think it would be better if find_kernel_memory() find an absolute address which is then adjusted here. > + > + return true; > +} > + > static int __init pvh_load_kernel(struct domain *d, const module_t *image, > unsigned long image_headroom, > module_t *initrd, void *image_base, > @@ -587,6 +690,12 @@ static int __init pvh_load_kernel(struct domain *d, const module_t *image, > elf.dest_base = (void *)(parms.virt_kstart - parms.virt_base); > elf.dest_size = parms.virt_kend - parms.virt_kstart; > > + if ( !adjust_load_address(d, &elf, &parms, align) ) check_and_adjust_? As the address is not unconditionally adjusted. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Mar 07 09:55:15 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 09:55:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689708.1074929 (Exim 4.92) (envelope-from ) id 1riASz-0005fI-DQ; Thu, 07 Mar 2024 09:55:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689708.1074929; Thu, 07 Mar 2024 09:55:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riASz-0005fB-An; Thu, 07 Mar 2024 09:55:09 +0000 Received: by outflank-mailman (input) for mailman id 689708; Thu, 07 Mar 2024 09:55:07 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riASx-0005f5-92 for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 09:55:07 +0000 Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [2607:f8b0:4864:20::234]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id c5f5428b-dc68-11ee-afda-a90da7624cb6; Thu, 07 Mar 2024 10:55:05 +0100 (CET) Received: by mail-oi1-x234.google.com with SMTP id 5614622812f47-3c219604f51so373546b6e.1 for ; Thu, 07 Mar 2024 01:55:05 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c5f5428b-dc68-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1709805304; x=1710410104; darn=lists.xenproject.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=OF8NOsya8q6lPS0cnvRqrZu0roqupg73tnRNu4gZNNQ=; b=GM5MyaUTgEytBFQycJksD6/NLYKQaI4pvJf0iMa2SGsPXOSI6veG7ma1Xx/Df+v3sY p7tKhSB+TY/HdJOildCAQPsd+Ndol5jIWGG40teX2G4SHNV8FHWnx/uiTYh9nqsmcJdH YnOh0iXUQ1AsMWHqFuFwWO54S8lr1VEvFDAVM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709805304; x=1710410104; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=OF8NOsya8q6lPS0cnvRqrZu0roqupg73tnRNu4gZNNQ=; b=A1Tkpwi0NtUxV7KJqo+zusVLhq27MCztI+3zYkQpVrgBvLyBZwQvDZmRXHedaHJIdF M2agD2K8DQXUoLeTGu+0V6OMU8Xhxi+J7AwMoyR2pvelsasmQcU71jlH8gKM65Gw0stt b3nqGy+oTHnNawYJJxU9XTU7HZrYT3SlNXOyu5TK3W5m8Tt28RYfr64pjH5Jqy9i0CKO 6YOa4dLvclbMFYzDD2HJn9r3Egxn9DZeucrPEm9fGXmPtx74GNk+YdiSj1agPZAy1qud SokR4DAsl4OaTEjIL/Tx5tVzhESFkXMMaqI4FxgzsltB8VGCDNSL2KUrKUA/WDBbgyNd qWig== X-Forwarded-Encrypted: i=1; AJvYcCUTPBQ26ouMzVqosFJWhwJzBlRldvBWbqlJnw2nXofrzkfYajpBv8sAATVX1aSDNNpnvOz8nkbuae5/acjBUBEIr0D3mJFiDYhnZxdECqY= X-Gm-Message-State: AOJu0Yyht0czV6vOtptHHSgNPzqLw3U6U05ozoFqQmYQ+jryJHUSB3SB hheOYraX8S8Wu4prbY4VB0lCvz2ZWN2U6lYDXEsyotojtHL/rNmeONgV/NpHUT/eOSAylM/IljI 7PRG1OXINSdTtlmAZX8xoNon35pjsJBeoT8YgCQ== X-Google-Smtp-Source: AGHT+IE5a4+QbsY1ES+vvfCudzxFBk3rzUJMaI7FxC11qN6UMiq2SCvXz4sAMxo5nbKMR3N8Zkurz+sMh3Ps5UeisMs= X-Received: by 2002:a05:6870:208:b0:221:2e06:c5d2 with SMTP id j8-20020a056870020800b002212e06c5d2mr8471486oad.58.1709805304527; Thu, 07 Mar 2024 01:55:04 -0800 (PST) MIME-Version: 1.0 References: <79ed633d-b0bd-4a7d-a0c6-37a034e1ee96@suse.com> <0374516c-b5fa-4880-a07a-0b788f491e9a@xen.org> In-Reply-To: From: George Dunlap Date: Thu, 7 Mar 2024 09:54:53 +0000 Message-ID: Subject: Re: [PATCH v2] Argo: don't obtain excess page references To: Christopher Clark Cc: Jan Beulich , Julien Grall , openxt , "xen-devel@lists.xenproject.org" , Andrew Cooper , Stefano Stabellini , Wei Liu Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Mar 6, 2024 at 11:38=E2=80=AFPM Christopher Clark wrote: > > On Sun, Feb 18, 2024 at 10:01=E2=80=AFAM Julien Grall wr= ote: > > > > Hi Jan, > > > > On 14/02/2024 10:12, Jan Beulich wrote: > > > find_ring_mfn() already holds a page reference when trying to obtain = a > > > writable type reference. We shouldn't make assumptions on the general > > > reference count limit being effectively "infinity". Obtain merely a t= ype > > > ref, re-using the general ref by only dropping the previously acquire= d > > > one in the case of an error. > > > > > > Signed-off-by: Jan Beulich > > > > Reviewed-by: Julien Grall > > > > > --- > > > I further question the log-dirty check there: The present P2M type of= a > > > page doesn't really matter for writing to the page (plus it's stale b= y > > > the time it is looked at). Instead I think every write to such a page > > > needs to be accompanied by a call to paging_mark_dirty(). > > > > I agree with that. > > Adding OpenXT mailing list as I have found that I have not had the > time available that I had hoped for to spend on reviewing this Argo > change, and to provide opportunity for downstream feedback. > > Link to the posted patch (start of this thread): > https://lists.xenproject.org/archives/html/xen-devel/2024-02/msg00858.htm= l Could we add some more designated reviewers / maintainers to the Argo code to help spread the load a bit? -George From xen-devel-bounces@lists.xenproject.org Thu Mar 07 10:00:51 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 10:00:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689711.1074939 (Exim 4.92) (envelope-from ) id 1riAYR-0007eO-0e; Thu, 07 Mar 2024 10:00:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689711.1074939; Thu, 07 Mar 2024 10:00:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riAYQ-0007eH-US; Thu, 07 Mar 2024 10:00:46 +0000 Received: by outflank-mailman (input) for mailman id 689711; Thu, 07 Mar 2024 10:00:46 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riAYQ-0007dw-3g for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 10:00:46 +0000 Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [2a00:1450:4864:20::32c]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 90b1cd7d-dc69-11ee-afda-a90da7624cb6; Thu, 07 Mar 2024 11:00:45 +0100 (CET) Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-412e96284b9so5660745e9.3 for ; Thu, 07 Mar 2024 02:00:45 -0800 (PST) Received: from localhost ([213.195.118.74]) by smtp.gmail.com with ESMTPSA id y24-20020a05600c341800b00412f6f4dea4sm2027120wmp.41.2024.03.07.02.00.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Mar 2024 02:00:44 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 90b1cd7d-dc69-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709805645; x=1710410445; darn=lists.xenproject.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=arMovgd2mIYnMLIDoAuAlvPpErBwmnW02thqvjtKbD8=; b=JzGhEDG8HX+8eC8HfN74hDEs+XswOz5zYD69nQFbTLFSf/mDa/vdVgIIEYBEotksaf dDSfyIv2NQcJcM3ee0IOBxIr7YD1iPPOPeZ4RenD3sZu8UjR7T3sK2KAiqiAxGrVIfSR ysylCckgDKj85F2zSdfKQ78jIaMLcNH6JvwuE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709805645; x=1710410445; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=arMovgd2mIYnMLIDoAuAlvPpErBwmnW02thqvjtKbD8=; b=mKRjZ8CvpE+jfbxi3XaJGGw1CEtChlulTzWZwG0xJm/X0xh/IS2O71zpu2RHfGPkoP abPG6XsI70wLOkZ24LzYdJ6SWJRB2XVjkCu1H0P1CBZCRlgzVPcOu2IPQR6eJae/4H0A qJQI+RYgjxfLRN1F8r4fPnlVxwa7cABNokgnDlGN5Snwi0l/egoPgAxdC+q9r3LMhETr BUom+zXilFDHYfAyHJ9nPShwwR+xKXIvncCOHSB3lDQZ1bdAyTeB26w2LuciAX5wrbjo xcMUuW8hobShFbuRla5H/bKgY8gEbhwQ/fQA8ee04+oU8qbWQ91Hsyv6ddq5lkU61VLN 1kcA== X-Gm-Message-State: AOJu0Ywl8nuH/PrfDkZmrmyh6Afh1KSr7klgqwVD6jRFLjoBAv29T45o Pyf6BUVDg/Zn5rhmYlaOCIZOSNeuLM4qJbjfTjMkq7B2FhXJo4BwYHdLk6WZfVY= X-Google-Smtp-Source: AGHT+IEUn/aZgDVhaZFPBF+ELwsOFaLiJMxKSj+uLOEmBCVVeca61mkWd8QhlvtEgqXvD03JizpeLQ== X-Received: by 2002:a05:600c:3ba5:b0:412:f979:587b with SMTP id n37-20020a05600c3ba500b00412f979587bmr2424003wms.17.1709805644662; Thu, 07 Mar 2024 02:00:44 -0800 (PST) Date: Thu, 7 Mar 2024 11:00:43 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jason Andryuk Cc: xen-devel@lists.xenproject.org, Andrew Cooper , George Dunlap , Jan Beulich , Julien Grall , Stefano Stabellini , Wei Liu Subject: Re: [PATCH 0/3] x86/pvh: Support relocating dom0 kernel Message-ID: References: <20240306185032.103216-1-jason.andryuk@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20240306185032.103216-1-jason.andryuk@amd.com> On Wed, Mar 06, 2024 at 01:50:29PM -0500, Jason Andryuk wrote: > Xen tries to load a PVH dom0 kernel at the fixed guest physical address > from the elf headers. For Linux, this defaults to 0x1000000 (16MB), but > it can be configured. > > Unfortunately there exist firmwares that have reserved regions at this > address, so Xen fails to load the dom0 kernel since it's not RAM. > > The other issue is that the Linux PVH entry point is not > position-independent. It expects to run at the compiled > CONFIG_PHYSICAL_ADDRESS. > > This patch set expands the PVH dom0 builder to try to relocate the > kernel if needed and possible. XENFEAT_pvh_relocatable is added for > kernels to indicate they are relocatable. However, we may want to > switch to an additional ELF note with the kernel alignment. Linux > specifies a kernel alignment in the bzImage boot_params.setup_header, > but that is not present the ELF vmlinux file. I wonder whether we need a pair of notes, to signal the min/max addresses the kernel supports being relocated to. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Mar 07 10:08:47 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 10:08:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689724.1074953 (Exim 4.92) (envelope-from ) id 1riAg6-0008N4-Qn; Thu, 07 Mar 2024 10:08:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689724.1074953; Thu, 07 Mar 2024 10:08:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riAg6-0008Mx-OE; Thu, 07 Mar 2024 10:08:42 +0000 Received: by outflank-mailman (input) for mailman id 689724; Thu, 07 Mar 2024 10:08:41 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riAg5-0008Mr-CE for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 10:08:41 +0000 Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [2a00:1450:4864:20::635]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id ab2ec8bc-dc6a-11ee-a1ee-f123f15fe8a2; Thu, 07 Mar 2024 11:08:39 +0100 (CET) Received: by mail-ej1-x635.google.com with SMTP id a640c23a62f3a-a3ddc13bbb3so332366666b.0 for ; Thu, 07 Mar 2024 02:08:39 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id wp1-20020a170907060100b00a44ce0671b1sm6025741ejb.108.2024.03.07.02.08.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Mar 2024 02:08:38 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ab2ec8bc-dc6a-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709806119; x=1710410919; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=jy4yY8qzffNwpBmB6TvO9ZBFkChaWm7czzs2MCLfRnI=; b=E7vpgZEt/buqeyDMtKPY18fO+j4s9so2RIdhS1xd9p/3ZEVc7+rXuZoQo86PIDET/F 3ZLheJRtEZklGAlCZnFh0pG5qH2fO5dgRokVx1xR2AVv3XlWbCdhJNNyLeo2KBIqcM+d wOfiEyeEeVIzu5vrePT/Ov+HTghWnJ0sqU5Q3MU4TvA74sKOV+l4bWvhC0US/N7hJFeV UjVdoo/av0mH8N9K0HHiNUnxM80yEnmhSndRkHQmh6ZPHkLa8kvYZkIYpy4eezieJi/Z C1uMHi64MPq4+/kCt9eojEUVpdz7KDz2OmYcMW/ylFL+2gTaP4+oB3GB39HMkgnttXhy uA0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709806119; x=1710410919; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=jy4yY8qzffNwpBmB6TvO9ZBFkChaWm7czzs2MCLfRnI=; b=hkR8Pp6D1XLQGzcwvHvm5FbOub1H//2c4K+1ZnmBPlekpROHfqVJOz5SnUs9iS6NSe x5ZjSDkgeNEZATsNAPDUbsCOcbpQFMF9VN9KkvRWcwhDrsEYFgPbG7ALANMRSGHtWFel plKqkhhjplOtyFbsn3roZvA/PtkDzIYaESNO+QFPIn+ycOA3oE9A55y4PIPKjZ2aTUkK DS9ncsJAHB7NnqoCRQUZrk7/WvPFere/jJry7cl/zB/lza56cddJdQFFR2V46xExYQRw TeoaIry7JCgeIsiRMZLTGrXZi/zPLMaGgWwzSxQj4DgXrC6qntr2Nv3C97atcbX3dMRg WLmA== X-Gm-Message-State: AOJu0Yx7slteStuS1TvJe1zCKGfA74FqBtako98CaryFhQIXx5gN33Xh EktcOs62yZuwDujqwfoEVjcFk98UFwJaE/2QHWSduW4GMdLUPSldLWH7YRikuw== X-Google-Smtp-Source: AGHT+IGx5v/S6Rg5mrHSdNUfi3/pV9V/H/8NiW756G0g+UfkTPLRNhCjGLrUcmdgvR7a/943LfqlDw== X-Received: by 2002:a17:906:894:b0:a43:acbd:db59 with SMTP id n20-20020a170906089400b00a43acbddb59mr941806eje.3.1709806118795; Thu, 07 Mar 2024 02:08:38 -0800 (PST) Message-ID: Date: Thu, 7 Mar 2024 11:08:37 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 0/3] x86/pvh: Support relocating dom0 kernel Content-Language: en-US To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk Cc: xen-devel@lists.xenproject.org, Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu References: <20240306185032.103216-1-jason.andryuk@amd.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 07.03.2024 11:00, Roger Pau Monné wrote: > On Wed, Mar 06, 2024 at 01:50:29PM -0500, Jason Andryuk wrote: >> Xen tries to load a PVH dom0 kernel at the fixed guest physical address >> from the elf headers. For Linux, this defaults to 0x1000000 (16MB), but >> it can be configured. >> >> Unfortunately there exist firmwares that have reserved regions at this >> address, so Xen fails to load the dom0 kernel since it's not RAM. >> >> The other issue is that the Linux PVH entry point is not >> position-independent. It expects to run at the compiled >> CONFIG_PHYSICAL_ADDRESS. >> >> This patch set expands the PVH dom0 builder to try to relocate the >> kernel if needed and possible. XENFEAT_pvh_relocatable is added for >> kernels to indicate they are relocatable. However, we may want to >> switch to an additional ELF note with the kernel alignment. Linux >> specifies a kernel alignment in the bzImage boot_params.setup_header, >> but that is not present the ELF vmlinux file. > > I wonder whether we need a pair of notes, to signal the min/max > addresses the kernel supports being relocated to. Plus, as per your other reply, a 3rd one to specify alignment needs. Then again - a single note can have multiple values. So perhaps it doesn't need to be more than one new notes (except if dealing with multi-value ones is deemed too complicated). Jan From xen-devel-bounces@lists.xenproject.org Thu Mar 07 10:21:06 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 10:21:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689738.1074967 (Exim 4.92) (envelope-from ) id 1riArz-0003dQ-U5; Thu, 07 Mar 2024 10:20:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689738.1074967; Thu, 07 Mar 2024 10:20:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riArz-0003dJ-RW; Thu, 07 Mar 2024 10:20:59 +0000 Received: by outflank-mailman (input) for mailman id 689738; Thu, 07 Mar 2024 10:20:58 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riAry-0003dD-NB for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 10:20:58 +0000 Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [2607:f8b0:4864:20::830]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 626a2734-dc6c-11ee-a1ee-f123f15fe8a2; Thu, 07 Mar 2024 11:20:56 +0100 (CET) Received: by mail-qt1-x830.google.com with SMTP id d75a77b69052e-42e63a658e1so2152151cf.3 for ; Thu, 07 Mar 2024 02:20:56 -0800 (PST) Received: from localhost ([213.195.118.74]) by smtp.gmail.com with ESMTPSA id l17-20020ac84591000000b0042f15132166sm500460qtn.52.2024.03.07.02.20.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Mar 2024 02:20:55 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 626a2734-dc6c-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709806855; x=1710411655; darn=lists.xenproject.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=sxc/MxlXvEOuxZfqktGZS6e46Q6TOq84VbsXVIWOBB8=; b=khg9xnLV3C+iVtbkqiFCEgm+hvJGASK1RJZh41mwZmdh5YBQpPomyvfYYJx3AGo4nZ zr4mFdvGp46qu2wVbC+hyKfTwZ2uPqftOFoQLcQSnjTUzhrNbimcbOL1qng6hQchEny8 C248THrmCdc2op23YpL/kJk1EaJhRA2um/JCU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709806855; x=1710411655; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=sxc/MxlXvEOuxZfqktGZS6e46Q6TOq84VbsXVIWOBB8=; b=RrpS1a3TAMRDK0xb95F85zo0JR4em/bh90ogq3TBQzzeVAO+aGynAcpwBRifMbAgda eRCt3klrU9ybmQy/osY1rFdqWjwI7HVk/pmt9Wzviao+k4geY+Kkbw5exYGubh1Za5fj /5hf1JPMnI9wQZqaYzLvPlZQrsw5ktFbl8KDNLpU4ZvwZuIjodk3f1RlQ3YtDaRoRj0S RggHWEZ+n50h0HH81CMHmWuQSl98k3wGyY20mWifRox5yLLiZ8pjiA7t9qAukRNOWIuD 24W/tVRccv0uC0XqRqedFiEwCNMEr2swSA8PEZ/4ri6lG1mvNKMchvryGz/HxhpWs0CN OSSA== X-Forwarded-Encrypted: i=1; AJvYcCUTQi042PcOtKFCjuHpUouDZVDsQcfmyzXJyUdSf0mT14KXfYUX/GFF9Yx+0w8VnC6UJFI8rjnPqX5NukeS6q1nnXSJlsdLnBwm6xWxKVA= X-Gm-Message-State: AOJu0YxTApW3bBvgNgbLvmRZZDBGkDO1bVyse1sCON80iVww/nljFNMC 9iQTn1ajLa/FIB9k3WW7TRxnq6flD3iG5bBN6a1EkJ1yh0X3ZKENd494VXcLoWc= X-Google-Smtp-Source: AGHT+IFvYDETf5O73MrtiwbOc7SFRgG52wQZnOryaoAxLVSQ+uVXyr6UDKeRyKHfkvOYMN0gAehylQ== X-Received: by 2002:a05:622a:1756:b0:42e:e412:c0dc with SMTP id l22-20020a05622a175600b0042ee412c0dcmr7820809qtk.43.1709806855430; Thu, 07 Mar 2024 02:20:55 -0800 (PST) Date: Thu, 7 Mar 2024 11:20:53 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: Jason Andryuk , xen-devel@lists.xenproject.org, Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu Subject: Re: [PATCH 0/3] x86/pvh: Support relocating dom0 kernel Message-ID: References: <20240306185032.103216-1-jason.andryuk@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Thu, Mar 07, 2024 at 11:08:37AM +0100, Jan Beulich wrote: > On 07.03.2024 11:00, Roger Pau Monné wrote: > > On Wed, Mar 06, 2024 at 01:50:29PM -0500, Jason Andryuk wrote: > >> Xen tries to load a PVH dom0 kernel at the fixed guest physical address > >> from the elf headers. For Linux, this defaults to 0x1000000 (16MB), but > >> it can be configured. > >> > >> Unfortunately there exist firmwares that have reserved regions at this > >> address, so Xen fails to load the dom0 kernel since it's not RAM. > >> > >> The other issue is that the Linux PVH entry point is not > >> position-independent. It expects to run at the compiled > >> CONFIG_PHYSICAL_ADDRESS. > >> > >> This patch set expands the PVH dom0 builder to try to relocate the > >> kernel if needed and possible. XENFEAT_pvh_relocatable is added for > >> kernels to indicate they are relocatable. However, we may want to > >> switch to an additional ELF note with the kernel alignment. Linux > >> specifies a kernel alignment in the bzImage boot_params.setup_header, > >> but that is not present the ELF vmlinux file. > > > > I wonder whether we need a pair of notes, to signal the min/max > > addresses the kernel supports being relocated to. > > Plus, as per your other reply, a 3rd one to specify alignment needs. Alignment we could in theory get from the ELF program header, if OSes fill those reliably. FreeBSD seems to do so, haven't checked Linux. > Then again - a single note can have multiple values. So perhaps it > doesn't need to be more than one new notes (except if dealing with > multi-value ones is deemed too complicated). I've never dealt with a multi-value note, if that's not overly complicated I would be fine with it, otherwise multiple notes are OK IMO. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Mar 07 10:25:38 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 10:25:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689741.1074978 (Exim 4.92) (envelope-from ) id 1riAwS-0004Hm-Hb; Thu, 07 Mar 2024 10:25:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689741.1074978; Thu, 07 Mar 2024 10:25:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riAwS-0004Hf-EX; Thu, 07 Mar 2024 10:25:36 +0000 Received: by outflank-mailman (input) for mailman id 689741; Thu, 07 Mar 2024 10:25:34 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riAwQ-0004HW-RL for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 10:25:34 +0000 Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [2a00:1450:4864:20::12b]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 070d1a2f-dc6d-11ee-a1ee-f123f15fe8a2; Thu, 07 Mar 2024 11:25:32 +0100 (CET) Received: by mail-lf1-x12b.google.com with SMTP id 2adb3069b0e04-51326436876so839521e87.1 for ; Thu, 07 Mar 2024 02:25:32 -0800 (PST) Received: from meli.delivery (adsl-101.37.6.0.tellas.gr. [37.6.0.101]) by smtp.gmail.com with ESMTPSA id x6-20020a05600c21c600b00412c8117a34sm2090971wmj.47.2024.03.07.02.25.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Mar 2024 02:25:31 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 070d1a2f-dc6d-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1709807132; x=1710411932; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:message-id:in-reply-to :references:user-agent:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to; bh=3K1GWJ1f0C4GCSxHKRkz5e3Ng8FTh6FRyaS1BmQg2fk=; b=QMgDLwbdPthdsqdfEBlsD93JObxk4uLTowQ4RA3mQsfMctP0zscodifa87qLgPzLsh DAK9CLv1zQQIKfW9+uQy5MJRlsMq9GKky/E5+lz5hitS5b5Z29C8ndACUKd8o7Lr9piQ MTLtp9IoJcDrncppHcazQd2oGwSpd0N6tQHxpuZSG0pOjeBCmexTNY+N19yXflUKaEDL c35nfZLUOMNyosGOSgMe4U9v45NVgQ4NNMtrQg0Cl1HxlqfXEwaoGV+k09dvTtOCACSN xmNJjbm/AEGuLSUw9hG/kjTDmVtNtsfK/jvOBw1SYZgg5Jrl9LtppXfAdWCELcz9mq1g 78pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709807132; x=1710411932; h=content-transfer-encoding:mime-version:message-id:in-reply-to :references:user-agent:subject:cc:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=3K1GWJ1f0C4GCSxHKRkz5e3Ng8FTh6FRyaS1BmQg2fk=; b=ODr/tYC1hY4isOdzRYkdDtQ7yNAiZow7R+bskUmRbGSh64HNOop13+w1xNAgONBshT HPGTEj8g7W+Svi79qdbZn8clqEz/UOwEZSS8TJXsVDBFhwsAHU3Jv+wZBpUj2yTSC008 DJA0x0ZOotbR7++KlyNc4sOKmGhmOx7pQwviGJX4Zx3wZivAA3AZcqMzSEhc8keXDrIm wVWwXhpYWcPY7x17VJAFS+BiREYkZe3V11TwXmlMHOxbbsLMxhVYe2JLsru9WGWjvpuW 4mZmxjlolfrDj40naSO2KsksBSBwCV2fd/BK/L+05Yp1DFr/tmEv5zl+Nh/q/D87Xywg qzoQ== X-Forwarded-Encrypted: i=1; AJvYcCXfVXq51HLRpHSPGs2GTpqVItbisJUho5cG9u/v7v404k9iKuPpJdmOPqrG46uwbhWthMImVvdAjqSp+WXd/VW49eN9kVgw4OKr3mtYJWs= X-Gm-Message-State: AOJu0YztHrlbRZo+wlHKUXZkgHVYPEv6aYDWni4ots2q5SHMF2JjKOMj PDV4ay2jb8KfCOm2nMOFeaGSTSPiQGJqXKX+IRzNvBBYT5w0TXxZ4ulyVFcTsAI= X-Google-Smtp-Source: AGHT+IEmwrna4+cJhHDAMTIscvykcCfu1Un1dNR4XkxhSSths4P8Hel+r/a7Gc/jMbe39MargcPFtw== X-Received: by 2002:ac2:4e8d:0:b0:513:80cd:e807 with SMTP id o13-20020ac24e8d000000b0051380cde807mr723350lfr.20.1709807131774; Thu, 07 Mar 2024 02:25:31 -0800 (PST) Date: Thu, 07 Mar 2024 12:02:25 +0200 From: Manos Pitsidianakis To: Michal Orzel , Alex Benn=?UTF-8?B?w6k=?= e , xen-devel@lists.xenproject.org Cc: julien@xen.org, sstabellini@kernel.org, bertrand.marquis@arm.com, Manos Pitsidianakis Bcc: Subject: Re: [RFC PATCH v2] xen/arm: improve handling of load/store instruction decoding User-Agent: meli 0.8.5-rc.3 References: <20240306165621.3819343-1-alex.bennee@linaro.org> <3cb1b056-59a7-4ffe-856d-e45aac1936a9@amd.com> In-Reply-To: <3cb1b056-59a7-4ffe-856d-e45aac1936a9@amd.com> Message-ID: <9z3mh.tiey2z2itr9a@linaro.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8; format=flowed Hi Michal, Alex, I'm responding to Michel but also giving my own review comments here. On Thu, 07 Mar 2024 10:40, Michal Orzel wrote: >Hi Alex, > >NIT: RFC tag is no longer needed. > >On 06/03/2024 17:56, Alex Bennée wrote: >> >> >> While debugging VirtIO on Arm we ran into a warning due to memory >> being memcpy'd across MMIO space. While the bug was in the mappings >> the warning was a little confusing: >> >> (XEN) d47v2 Rn should not be equal to Rt except for r31 >> (XEN) d47v2 unhandled Arm instruction 0x3d800000 >> (XEN) d47v2 Unable to decode instruction >> >> The Rn == Rt warning is only applicable to single register load/stores >> so add some verification steps before to weed out unexpected accesses. >> >> While at it update the Arm ARM references to the latest version of the >> documentation. >> >> Signed-off-by: Alex Bennée >> Cc: Manos Pitsidianakis >Move the CC line after --- so that it's not included in the final commit msg. > >> >> --- >> v2 >> - use single line comments where applicable >> - update Arm ARM references >> - use #defines for magic numbers >> --- >> xen/arch/arm/decode.c | 35 ++++++++++++++++++++------ >> xen/arch/arm/decode.h | 57 ++++++++++++++++++++++++++++++++++++++----- >> 2 files changed, 79 insertions(+), 13 deletions(-) >> >> diff --git a/xen/arch/arm/decode.c b/xen/arch/arm/decode.c >> index 2537dbebc1..73a88e4701 100644 >> --- a/xen/arch/arm/decode.c >> +++ b/xen/arch/arm/decode.c >> @@ -87,15 +87,36 @@ static int decode_arm64(register_t pc, mmio_info_t *info) >> return 1; >> } >> >> + /* Check this is a load/store of some sort */ >> + if ( (opcode.top_level.op1 & TL_LDST_OP1_MASK) != TL_LDST_OP1_VALUE ) >> + { >> + gprintk(XENLOG_ERR, "Not a load/store instruction op1=%u\n", >> + opcode.top_level.op1); >> + goto bad_loadstore; >> + } >> + >> + /* We are only expecting single register load/stores */ >> + if ( (opcode.ld_st.op0 & LS_SREG_OP0_MASK) != LS_SREG_OP0_VALUE ) >> + { >> + gprintk(XENLOG_ERR, "Not single register load/store op0=%u\n", >NIT: missing 'a' between Not and single > >> + opcode.ld_st.op0); >> + goto bad_loadstore; >> + } >> + >> /* >> - * Refer Arm v8 ARM DDI 0487G.b, Page - C6-1107 >> - * "Shared decode for all encodings" (under ldr immediate) >> - * If n == t && n != 31, then the return value is implementation defined >> - * (can be WBSUPPRESS, UNKNOWN, UNDEFINED or NOP). Thus, we do not support >> - * this. This holds true for ldrb/ldrh immediate as well. >> + * Refer Arm v8 ARM DDI 0487J.a, Page - K1-12586 >> + * >> + * STR (immediate) CONSTRAINED UNPREDICTABLE behaviour >> + * >> + * "If the instruction encoding specifies pre-indexed addressing or >> + * post-indexed addressing, and n == t && n != 31, then one of the >> + * following behaviors must occur:" UNDEFINED, NOP or UNKNOWN >> + * >> + * Execution @ EL0/EL1 when HCR_EL2.TIDCP is 1 traps to EL2 with >> + * EC = 0. >> * >> - * Also refer, Page - C6-1384, the above described behaviour is same for >> - * str immediate. This holds true for strb/strh immediate as well >> + * This also hold true for LDR (immediate), Page K1-12581 and >> + * the RB/RH variants of both. >> */ >> if ( (opcode.ldr_str.rn == opcode.ldr_str.rt) && (opcode.ldr_str.rn != 31) ) >> { >> diff --git a/xen/arch/arm/decode.h b/xen/arch/arm/decode.h >> index 13db8ac968..188114a71e 100644 >> --- a/xen/arch/arm/decode.h >> +++ b/xen/arch/arm/decode.h >> @@ -24,17 +24,54 @@ >> #include >> >> /* >> - * Refer to the ARMv8 ARM (DDI 0487G.b), Section C4.1.4 Loads and Stores >> - * Page 318 specifies the following bit pattern for >> - * "load/store register (immediate post-indexed)". >> + * Refer to the ARMv8 ARM (DDI 0487J.a) >> * >> - * 31 30 29 27 26 25 23 21 20 11 9 4 0 >> + * Section C A64 Instruct Set Encoding >This line is not needed I think it is needed for context (it answers the question "what is C4.1?" in the following line. >> + * >> + * C4.1 A64 instruction set encoding: >NIT: I would put a comma after section number i.e. C4.1, A64 ... >The same would apply in other places. Style manuals use either space (like here), a period (.) or colon (:), never a comma. > >> + * >> + * 31 30 29 28 25 24 0 >> * ___________________________________________________________________ >> - * |size|1 1 1 |V |0 0 |opc |0 | imm9 |0 1 | Rn | Rt | >> - * |____|______|__|____|____|__|_______________|____|_________|_______| >> + * |op0 | x x | op1 | | >> + * |____|______|______|_______________________________________________| >> + * >> + * op0 = 0 is reserved >I'm not sure how to read it. It is reserved provided op1 is also 0. Yes, it should say something like: > Decode field values op0 = 0, op1 = 0 are reserved. > Values op0 = 1, op1 = x1x0 correspond to Loads and Stores >> + * op1 = x1x0 for Loads and Stores >> + * >> + * Section C4.1.88 Loads and Stores >Missing colon at the end? It's a heading so a colon would not be appropriate. > >> + * >> + * 31 28 27 26 25 24 23 22 21 16 15 12 11 10 9 0 >> + * ___________________________________________________________________ >> + * | op0 | 1 | op1 | 0 | op2 | | op3 | | op4 | | >> + * |________|___|_____|___|_____|__|__________|______|_____|__________| >> + * Maybe we should add the op{0,1,2,3,4} values for consistency? > Values op0=xx11, op1=0, op2=0x, op3=0xxxxx, op4=01 correspond to > Load/store register (immediate post-indexed) >> + * Page C4-653 Load/store register (immediate post-indexed) >> + * >> + * 31 30 29 27 26 25 24 23 22 21 20 12 11 10 9 5 4 0 >> + * ___________________________________________________________________ >> + * |size|1 1 1 |V | 0 0 | opc |0 | imm9 | 0 1 | Rn | Rt | >> + * |____|______|__|_____|_____|__|_______________|_____|______|_______| >> */ >> union instr { >> uint32_t value; >> + struct { >> + unsigned int ign2:25; >Here, your numeration of ignore fields is in descending order (starting from lsb) but .., > >> + unsigned int op1:4; /* instruction class */ >> + unsigned int ign1:2; >> + unsigned int op0:1; /* value = 1b */ >Why op0 = 0b1 ? This structure represents the generic bit layout (the emulation deals with single ldr/str). >I would drop this comment. It is a reserved bit which can never be 0. > >> + } top_level; >> + struct { >> + unsigned int ign1:10; >here in ascending. Let's be consistent (fixed fields are in ascending order). Agreed, otherwise names like ign2, fixed1 are not helpful. >> + unsigned int op4:2; >> + unsigned int ign2:4; >> + unsigned int op3:6; >> + unsigned int ign3:1; >> + unsigned int op2:2; >> + unsigned int fixed1:1; /* value = 0b */ >> + unsigned int op1:1; >> + unsigned int fixed2:1; /* value = 1b */ >> + unsigned int op0:4; >> + } ld_st; >> struct { >> unsigned int rt:5; /* Rt register */ >> unsigned int rn:5; /* Rn register */ >> @@ -49,6 +86,14 @@ union instr { >> } ldr_str; >> }; >> >> +/* Top level load/store encoding */ >> +#define TL_LDST_OP1_MASK 0b0101 >> +#define TL_LDST_OP1_VALUE 0b0100 >> + >> +/* Load/store single reg encoding */ >> +#define LS_SREG_OP0_MASK 0b0011 >> +#define LS_SREG_OP0_VALUE 0b0011 >> + >> #define POST_INDEX_FIXED_MASK 0x3B200C00 >> #define POST_INDEX_FIXED_VALUE 0x38000400 >> >> -- >> 2.39.2 >> >> > From xen-devel-bounces@lists.xenproject.org Thu Mar 07 10:36:11 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 10:36:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689748.1074988 (Exim 4.92) (envelope-from ) id 1riB6U-0006Tj-Fi; Thu, 07 Mar 2024 10:35:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689748.1074988; Thu, 07 Mar 2024 10:35:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riB6U-0006Tc-Bp; Thu, 07 Mar 2024 10:35:58 +0000 Received: by outflank-mailman (input) for mailman id 689748; Thu, 07 Mar 2024 10:35:57 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riB6T-0006TR-CL for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 10:35:57 +0000 Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [2a00:1450:4864:20::129]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 7a27cf35-dc6e-11ee-a1ee-f123f15fe8a2; Thu, 07 Mar 2024 11:35:55 +0100 (CET) Received: by mail-lf1-x129.google.com with SMTP id 2adb3069b0e04-513173e8191so890714e87.1 for ; Thu, 07 Mar 2024 02:35:55 -0800 (PST) Received: from [192.168.206.239] ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id q28-20020ac2515c000000b005116d8eec66sm2996532lfd.216.2024.03.07.02.35.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Mar 2024 02:35:53 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 7a27cf35-dc6e-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709807754; x=1710412554; darn=lists.xenproject.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=uADE57dssii6EGqzuzhOShPjg2S28MNK0B3pGlSsvyI=; b=ZZG6hgVs45EFNTDMttUOB+TsrXNVuL+gcG188rd3OtwV2WpXJoAS+UR/3NGanINKC6 Rczljv/53LTGQvmQUNRizscp9WxSaWUheNng8B+6LA04+3/9yS+EM2ICKc4oBBXyqLh6 3btd7JeIqBILEGehNpxYAHANszslvFZ9PcXh06nTX5j+BMeUgArERfUtIQbhy67fg2JP VxYDgqqfr6EEttRkI1nXPEcVjvHHu/2HHxcClaG3O7TlkEQPLlp79H/b5SV3vZP3+kQy mKV5/NQlYFvJ0RnW62s/e13ST/XBI+fzgiJwrh7t5yBe/f+b7mtaQnEMh+vtnabuQ8CE Q89w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709807754; x=1710412554; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=uADE57dssii6EGqzuzhOShPjg2S28MNK0B3pGlSsvyI=; b=Lg6nJM6PchpXfH+qUEiDRe6AGmoG6MZeC3Qoj69NRaraonLYLQEaKHVFBMqZerxb0D Vm8byWkIftlpjuC9dmhUR3ctn3eAB0sNQVOaCo/8j6nhfyDyQgjyo1VBi2BC91JEaQTL UzqTkxrBv2HKl8glzEZ7e4JZ8RiAfTgxKX+5LThryK6XAu4F/Ie9cuSyOtup4fK1hcTj tUuK6atCWx13GaEjeqaEGajat4HbrMlVKflPHlvAOXTnSTuk58u75Mmun+m3zC6grknC vWpZjMg/P96JJ5gzFfTEHzUSilhbeGYrOFhUwe31631/wOU0ICzz8e0AfWW1Uyx0M9fj eoEw== X-Forwarded-Encrypted: i=1; AJvYcCX+tLEa2/lp51YSe1Lmcx0ZfhRyC9n5RpdzX9DXX3drScAb8DIMF12bLs0XwYYSubyv2cLDUIYjlcUavLDPdqm9Ud35IcxjVcdfhR72YRc= X-Gm-Message-State: AOJu0Yw4TeaIjzWrgOpETrj2/8xK+zPgxLDUUq7XfbguM53cxrAQJcu4 Dt+ijSkChMNKSk7SPl+MajEHybmf8nqjialNxK2eirszjZBdHk1T X-Google-Smtp-Source: AGHT+IGcdHiQQ0pnaYTmHaTmRYuQ3eucUUnTxNuaSlBl83o9Tvxa8o/jYKCwmAoZ2tq+D7kNmrNd2Q== X-Received: by 2002:a05:6512:308d:b0:513:5e6b:a191 with SMTP id z13-20020a056512308d00b005135e6ba191mr1236557lfd.50.1709807753932; Thu, 07 Mar 2024 02:35:53 -0800 (PST) Message-ID: Subject: Re: [PATCH v5 11/23] xen/riscv: introduce cmpxchg.h From: Oleksii To: Jan Beulich Cc: Alistair Francis , Bob Eshleman , Connor Davis , Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu , xen-devel@lists.xenproject.org Date: Thu, 07 Mar 2024 11:35:52 +0100 In-Reply-To: <23ff1c20-91f3-4c60-9562-7f1cd57c1043@suse.com> References: <23ff1c20-91f3-4c60-9562-7f1cd57c1043@suse.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.50.2 (3.50.2-1.fc39) MIME-Version: 1.0 On Wed, 2024-03-06 at 15:56 +0100, Jan Beulich wrote: > On 26.02.2024 18:38, Oleksii Kurochko wrote: > > The header was taken from Linux kernl 6.4.0-rc1. > >=20 > > Addionally, were updated: > > * add emulation of {cmp}xchg for 1/2 byte types using 32-bit atomic > > =C2=A0 access. > > * replace tabs with spaces > > * replace __* variale with *__ > > * introduce generic version of xchg_* and cmpxchg_*. > >=20 > > Implementation of 4- and 8-byte cases were left as it is done in > > Linux kernel as according to the RISC-V spec: > > ``` > > Table A.5 ( only part of the table was copied here ) > >=20 > > Linux Construct=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RVWMO Mapping > > atomic relaxed=C2=A0=C2=A0=C2=A0 amo.{w|d} > > atomic acquire=C2=A0=C2=A0=C2=A0 amo.{w|d}.aq > > atomic release=C2=A0=C2=A0=C2=A0 amo.{w|d}.rl > > atomic =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 amo.{w|d}.aqrl > >=20 > > Linux Construct=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RVWMO LR/SC Mapping > > atomic relaxed=C2=A0=C2=A0=C2=A0 loop: lr.{w|d}; ; sc.{w|d}; b= nez loop > > atomic acquire=C2=A0=C2=A0=C2=A0 loop: lr.{w|d}.aq; ; sc.{w|d}= ; bnez loop > > atomic release=C2=A0=C2=A0=C2=A0 loop: lr.{w|d}; ; sc.{w|d}.aq= rl=E2=88=97 ; bnez > > loop OR > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 fence.tso; = loop: lr.{w|d}; ; sc.{w|d}=E2=88=97 ; > > bnez loop > > atomic =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 loop: lr.{w|d}.aq; ; sc.{w|d}.aqrl; bnez > > loop > >=20 > > The Linux mappings for release operations may seem stronger than > > necessary, > > but these mappings are needed to cover some cases in which Linux > > requires > > stronger orderings than the more intuitive mappings would provide. > > In particular, as of the time this text is being written, Linux is > > actively > > debating whether to require load-load, load-store, and store-store > > orderings > > between accesses in one critical section and accesses in a > > subsequent critical > > section in the same hart and protected by the same synchronization > > object. > > Not all combinations of FENCE RW,W/FENCE R,RW mappings with aq/rl > > mappings > > combine to provide such orderings. > > There are a few ways around this problem, including: > > 1. Always use FENCE RW,W/FENCE R,RW, and never use aq/rl. This > > suffices > > =C2=A0=C2=A0 but is undesirable, as it defeats the purpose of the aq/rl > > modifiers. > > 2. Always use aq/rl, and never use FENCE RW,W/FENCE R,RW. This does > > not > > =C2=A0=C2=A0 currently work due to the lack of load and store opcodes w= ith aq > > and rl > > =C2=A0=C2=A0 modifiers. >=20 > As before I don't understand this point. Can you give an example of > what > sort of opcode / instruction is missing? If I understand the spec correctly then l{b|h|w|d} and s{b|h|w|d} instructions don't have aq or rl annotation. Here is text from the spec: ARM Operation RVWMO Mapping Load l{b|h|w|d} Load-Acquire fence rw, rw; l{b|h|w|d}; fence r,rw=20 Load-Exclusive lr.{w|d} Load-Acquire-Exclusive lr.{w|d}.aqrl Store s{b|h|w|d} Store-Release fence rw,w; s{b|h|w|d} Store-Exclusive sc.{w|d} Store-Release-Exclusive sc.{w|d}.rl dmb fence rw,rw dmb.ld fence r,rw dmb.st fence w,w isb fence.i; fence r,r Table A.4: Mappings from ARM operations to RISC-V operations Table A.4 provides a mapping from ARM memory operations onto RISC-V memory instructions. Since RISC-V does not currently have plain load and store opcodes with aq or rl annotations, ARM load-acquire and store-release operations should be mapped using fences instead. >=20 > > 3. Strengthen the mappings of release operations such that they > > would > > =C2=A0=C2=A0 enforce sufficient orderings in the presence of either typ= e of > > acquire mapping. > > =C2=A0=C2=A0 This is the currently-recommended solution, and the one sh= own in > > Table A.5. > > ``` > >=20 > > But in Linux kenrel atomics were strengthen with fences: > > ``` > > Atomics present the same issue with locking: release and acquire > > variants need to be strengthened to meet the constraints defined > > by the Linux-kernel memory consistency model [1]. > >=20 > > Atomics present a further issue: implementations of atomics such > > as atomic_cmpxchg() and atomic_add_unless() rely on LR/SC pairs, > > which do not give full-ordering with .aqrl; for example, current > > implementations allow the "lr-sc-aqrl-pair-vs-full-barrier" test > > below to end up with the state indicated in the "exists" clause. > >=20 > > In order to "synchronize" LKMM and RISC-V's implementation, this > > commit strengthens the implementations of the atomics operations > > by replacing .rl and .aq with the use of ("lightweigth") fences, > > and by replacing .aqrl LR/SC pairs in sequences such as: > >=20 > > 0:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 lr.w.aqrl=C2=A0 %0, %addr > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 bne=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 %0, %old, 1f > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ... > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sc.w.aqrl=C2=A0 %1, %new, %a= ddr > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 bnez=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 %1, 0b > > 1: > >=20 > > with sequences of the form: > >=20 > > 0:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 lr.w=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 %0, %addr > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 bne=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 %0, %old, 1f > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 ... > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sc.w.rl=C2=A0=C2=A0=C2=A0 %1= , %new, %addr=C2=A0=C2=A0 /* SC-release=C2=A0=C2=A0 */ > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 bnez=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 %1, 0b > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 fence=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 rw, rw=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 /* "full" fence */ > > 1: > >=20 > > following Daniel's suggestion. > >=20 > > These modifications were validated with simulation of the RISC-V > > memory consistency model. > >=20 > > C lr-sc-aqrl-pair-vs-full-barrier > >=20 > > {} > >=20 > > P0(int *x, int *y, atomic_t *u) > > { > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int r0; > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int r1; > >=20 > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 WRITE_ONCE(*x, 1); > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 r0 =3D atomic_cmpxchg(u, 0, = 1); > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 r1 =3D READ_ONCE(*y); > > } > >=20 > > P1(int *x, int *y, atomic_t *v) > > { > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int r0; > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int r1; > >=20 > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 WRITE_ONCE(*y, 1); > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 r0 =3D atomic_cmpxchg(v, 0, = 1); > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 r1 =3D READ_ONCE(*x); > > } > >=20 > > exists (u=3D1 /\ v=3D1 /\ 0:r1=3D0 /\ 1:r1=3D0) >=20 > While I'm entirely willing to trust this can happen, I can't bring > this > in line with the A extension spec. >=20 > Additionally it's not clear to me in how far all of this applies when > you don't really use LR/SC in the 4- and 8-byte cases (and going > forward > likely also not in the 1- and 2-byte case, utilizing Zahba when > available). It just explain what combination of fences, lr/sc, amoswap, .aq and .rl annotation can be combined, and why combinations introduced in this patch are used. >=20 > > --- > > Changes in V5: > > =C2=A0- update the commit message. > > =C2=A0- drop ALIGN_DOWN(). > > =C2=A0- update the definition of emulate_xchg_1_2():=20 > > =C2=A0=C2=A0 - lr.d -> lr.w, sc.d -> sc.w. > > =C2=A0=C2=A0 - drop ret argument. > > =C2=A0=C2=A0 - code style fixes around asm volatile. > > =C2=A0=C2=A0 - update prototype. > > =C2=A0=C2=A0 - use asm named operands. > > =C2=A0=C2=A0 - rename local variables. > > =C2=A0=C2=A0 - add comment above the macros > > =C2=A0- update the definition of __xchg_generic: > > =C2=A0=C2=A0 - drop local ptr__ variable. > > =C2=A0=C2=A0 - code style fixes around switch() > > =C2=A0=C2=A0 - update prototype. > > =C2=A0- introduce RISCV_FULL_BARRIES. > > =C2=A0- redefine cmpxchg() > > =C2=A0- update emulate_cmpxchg_1_2(): > > =C2=A0=C2=A0 - update prototype > > =C2=A0=C2=A0 - update local variables names and usage of them > > =C2=A0=C2=A0 - use name asm operands. > > =C2=A0=C2=A0 - add comment above the macros > > --- > > Changes in V4: > > =C2=A0- Code style fixes. > > =C2=A0- enforce in __xchg_*() has the same type for new and *ptr, also > > "\n" > > =C2=A0=C2=A0 was removed at the end of asm instruction. > > =C2=A0- dependency from > > https://lore.kernel.org/xen-devel/cover.1706259490.git.federico.serafin= i@bugseng.com/ > > =C2=A0- switch from ASSERT_UNREACHABLE to STATIC_ASSERT_UNREACHABLE(). > > =C2=A0- drop xchg32(ptr, x) and xchg64(ptr, x) as they aren't used. > > =C2=A0- drop cmpxcg{32,64}_{local} as they aren't used. > > =C2=A0- introduce generic version of xchg_* and cmpxchg_*. > > =C2=A0- update the commit message. > > --- > > Changes in V3: > > =C2=A0- update the commit message > > =C2=A0- add emulation of {cmp}xchg_... for 1 and 2 bytes types > > --- > > Changes in V2: > > =C2=A0- update the comment at the top of the header. > > =C2=A0- change xen/lib.h to xen/bug.h. > > =C2=A0- sort inclusion of headers properly. > > --- > > =C2=A0xen/arch/riscv/include/asm/cmpxchg.h | 258 > > +++++++++++++++++++++++++++ > > =C2=A01 file changed, 258 insertions(+) > > =C2=A0create mode 100644 xen/arch/riscv/include/asm/cmpxchg.h > >=20 > > diff --git a/xen/arch/riscv/include/asm/cmpxchg.h > > b/xen/arch/riscv/include/asm/cmpxchg.h > > new file mode 100644 > > index 0000000000..66cbe26737 > > --- /dev/null > > +++ b/xen/arch/riscv/include/asm/cmpxchg.h > > @@ -0,0 +1,258 @@ > > +/* SPDX-License-Identifier: GPL-2.0-only */ > > +/* Copyright (C) 2014 Regents of the University of California */ > > + > > +#ifndef _ASM_RISCV_CMPXCHG_H > > +#define _ASM_RISCV_CMPXCHG_H > > + > > +#include > > +#include > > + > > +#include > > +#include > > +#include > > + > > +#define __amoswap_generic(ptr, new, ret, sfx, pre, post) \ > > +({ \ > > +=C2=A0=C2=A0=C2=A0 asm volatile( \ >=20 > Nit: In Xen style this is lacking a blank ahead of the opening > parenthesis. >=20 > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 pre \ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 " amoswap" sfx " %0, %2, %1= \n" \ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 post \ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : "=3Dr" (ret), "+A" (*ptr)= \ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : "r" (new) \ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : "memory" ); \ > > +}) > > + > > +/* > > + * For LR and SC, the A extension requires that the address held > > in rs1 be > > + * naturally aligned to the size of the operand (i.e., eight-byte > > aligned > > + * for 64-bit words and four-byte aligned for 32-bit words). > > + * If the address is not naturally aligned, an address-misaligned > > exception > > + * or an access-fault exception will be generated. > > + *=20 > > + * Thereby: > > + * - for 1-byte xchg access the containing word by clearing low > > two bits > > + * - for 2-byte xchg ccess the containing word by clearing first > > bit. >=20 > "first bit" can still be ambiguous. Better say "bit 1". >=20 > > + *=20 >=20 > Here and apparently also elsewhere: Stray trailing blank. Git has a > config > setting to warn you about (maybe even to automatically strip? such. It would be useful for me. Thanks a lot for such recommendation. >=20 > > + * If resulting 4-byte access is still misalgined, it will fault > > just as > > + * non-emulated 4-byte access would. > > + */ > > +#define emulate_xchg_1_2(ptr, new, sc_sfx, pre, post) \ > > +({ \ > > +=C2=A0=C2=A0=C2=A0 uint32_t *aligned_ptr =3D (uint32_t *)((unsigned lo= ng)ptr & > > ~(0x4 - sizeof(*ptr))); \ >=20 > Here and elsewhere: sizeof(*(ptr)) (i.e. the inner parentheses are > needed > also there). >=20 > > +=C2=A0=C2=A0=C2=A0 uint8_t new_val_pos =3D ((unsigned long)(ptr) & (0x= 4 - > > sizeof(*ptr))) * BITS_PER_BYTE; \ >=20 > Why uint8_t? It is enough to cover possible start bit position of value that should be updated, so I decided to use uint8_t. >=20 > > +=C2=A0=C2=A0=C2=A0 unsigned long mask =3D GENMASK(((sizeof(*ptr)) * BI= TS_PER_BYTE) > > - 1, 0) << new_val_pos; \ > > +=C2=A0=C2=A0=C2=A0 unsigned int new_ =3D new << new_val_pos; \ > > +=C2=A0=C2=A0=C2=A0 unsigned int old_val; \ > > +=C2=A0=C2=A0=C2=A0 unsigned int xchged_val; \ > > +=C2=A0=C2=A0=C2=A0 \ > > +=C2=A0=C2=A0=C2=A0 asm volatile ( \ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 pre \ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "0: lr.w %[op_oldval], %[op= _aligned_ptr]\n" \ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "=C2=A0=C2=A0 and=C2=A0 %[o= p_xchged_val], %[op_oldval], %z[op_nmask]\n" \ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "=C2=A0=C2=A0 or=C2=A0=C2= =A0 %[op_xchged_val], %[op_xchged_val], %z[op_new]\n" > > \ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "=C2=A0=C2=A0 sc.w" sc_sfx = " %[op_xchged_val], %[op_xchged_val], > > %[op_aligned_ptr]\n" \ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "=C2=A0=C2=A0 bnez %[op_xch= ged_val], 0b\n" \ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 post \ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : [op_oldval] "=3D&r" (old_= val), [op_xchged_val] "=3D&r" > > (xchged_val), [op_aligned_ptr]"+A" (*aligned_ptr) \ >=20 > Too long line. Partly because you have op_ prefixes here which I > can't > recognized what they would be good for. The val / _val suffixes also > don't appear to carry much useful information. And "xchged", being > explicitly past tense, doesn't look to fit even up and until the SC, > not to speak of afterwards. Anything wrong with calling this just > tmp, > aux, or scratch? op_ can be dropped and named operand can be equal to local variable name, I thought it would be useful to understand that it is named operand, but after rethinking it looks like unneeded overhead. In case of emulate_xchg_1_2() there is no sense in val/_val suffixes as local variables don't intersect with macros variable, and the suffixes were added just to be in sync with emulate_cmpxchg_1_2 macros, but in case of emulate_cmpxchg_1_2(ptr, old, new, sc_sfx, pre, post), the macros has old argument, so to distinguish them _val was added. Probably, it would be better to rename it to read or read_old. >=20 > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : [op_new] "rJ" (new_), [op= _nmask] "rJ" (~mask) \ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : "memory" ); \ > > +=C2=A0=C2=A0=C2=A0 \ > > +=C2=A0=C2=A0=C2=A0 (__typeof__(*(ptr)))((old_val & mask) >> new_val_po= s); \ > > +}) > > + > > +#define __xchg_generic(ptr, new, size, sfx, pre, post) \ > > +({ \ > > +=C2=A0=C2=A0=C2=A0 __typeof__(*(ptr)) new__ =3D (new); \ > > +=C2=A0=C2=A0=C2=A0 __typeof__(*(ptr)) ret__; \ > > +=C2=A0=C2=A0=C2=A0 switch ( size ) \ >=20 > Can't this use sizeof(*(ptr)), allowing for one less macro parameter? >=20 > > +=C2=A0=C2=A0=C2=A0 { \ > > +=C2=A0=C2=A0=C2=A0 case 1: \ > > +=C2=A0=C2=A0=C2=A0 case 2: \ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ret__ =3D emulate_xchg_1_2(= ptr, new__, sfx, pre, post); \ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 break; \ > > +=C2=A0=C2=A0=C2=A0 case 4: \ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 __amoswap_generic(ptr, new_= _, ret__,\ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 ".w" sfx,=C2=A0 pre, post); \ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 break; \ > > +=C2=A0=C2=A0=C2=A0 case 8: \ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 __amoswap_generic(ptr, new_= _, ret__,\ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 ".d" sfx,=C2=A0 pre, post); \ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 break; \ >=20 > In io.h you make sure to avoid rv64-only insns. Here you don't. The > build > would fail either way, but this still looks inconsistent. >=20 > Also nit: Stray double blands (twice) ahead of "pre". Plus with this > style > of line continuation you want to consistently have exactly one blank > ahead > of each backslash. >=20 > > +=C2=A0=C2=A0=C2=A0 default: \ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 STATIC_ASSERT_UNREACHABLE()= ; \ > > +=C2=A0=C2=A0=C2=A0 } \ > > +=C2=A0=C2=A0=C2=A0 ret__; \ > > +}) > > + > > +#define xchg_relaxed(ptr, x) \ > > +({ \ > > +=C2=A0=C2=A0=C2=A0 __typeof__(*(ptr)) x_ =3D (x); \ >=20 > What is the purpose of this, when __xchg_generic() already does this > same > type conversion? >=20 > > +=C2=A0=C2=A0=C2=A0 (__typeof__(*(ptr)))__xchg_generic(ptr, x_, sizeof(= *(ptr)), > > "", "", ""); \ > > +}) > > + > > +#define xchg_acquire(ptr, x) \ > > +({ \ > > +=C2=A0=C2=A0=C2=A0 __typeof__(*(ptr)) x_ =3D (x); \ > > +=C2=A0=C2=A0=C2=A0 (__typeof__(*(ptr)))__xchg_generic(ptr, x_, sizeof(= *(ptr)), \ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 "", "", > > RISCV_ACQUIRE_BARRIER); \ > > +}) > > + > > +#define xchg_release(ptr, x) \ > > +({ \ > > +=C2=A0=C2=A0=C2=A0 __typeof__(*(ptr)) x_ =3D (x); \ > > +=C2=A0=C2=A0=C2=A0 (__typeof__(*(ptr)))__xchg_generic(ptr, x_, sizeof(= *(ptr)),\ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 "", RISCV_RELEASE_BARRIER, > > ""); \ > > +}) >=20 > As asked before: Are there going to be any uses of these three? > Common > code doesn't require them. And not needing to provide them would > simplify things quite a bit, it seems. I checked my private branches and it looks to me that I introduced them only for the correspondent atomic operations ( which was copied from Linux Kernel ) which are not also used. So we could definitely drop these macros for now, but should xchg_generic() be updated as well? If to look at: #define xchg(ptr, x) __xchg_generic(ptr, (unsigned long)(x), sizeof(* (ptr)), \ ".aqrl", "", "") Last two arguments start to be unneeded, but I've wanted to leave them, in case someone will needed to back xchg_{release, acquire, ...}. Does it make any sense? >=20 > > +#define xchg(ptr, x) __xchg_generic(ptr, (unsigned long)(x), > > sizeof(*(ptr)), \ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ".aqrl",= "", "") >=20 > According to the earlier comment (where I don't follow the example > given), > is .aqrl sufficient here? And even if it was for the 4- and 8-byte > cases, > is it sufficient in the 1- and 2-byte emulation case (where it then > is > appended to just the SC)? If I understand your question correctly then accroding to the spec., .aqrl is enough for amo.{w|d} instructions: Linux Construct RVWMO AMO Mapping atomic relaxed amo.{w|d} atomic acquire amo.{w|d}.aq atomic release amo.{w|d}.rl atomic amo.{w|d}.aqrl but in case of lr/sc you are right sc requires suffix too: Linux Construct RVWMO LR/SC Mapping atomic relaxed loop: lr.{w|d}; ; sc.{w|d}; bnez loop atomic acquire loop: lr.{w|d}.aq; ; sc.{w|d}; bnez loop atomic release loop: lr.{w|d}; ; sc.{w|d}.aqrl=E2=88=97 ; bn= ez=20 loop OR fence.tso; loop: lr.{w|d}; ; sc.{w|d}=E2=88=97 ; bnez loop atomic loop: lr.{w|d}.aq; ; sc.{w|d}.aqrl; bnez loop =20 I will add sc_sfx to emulate_xchg_1_2(). The only question is left if __xchg_generic(ptr, new, size, sfx, pre, post) should be changed to: __xchg_generic(ptr, new, size, sfx1, sfx2, pre, post) to cover both cases amo.{w|d}.sfx1 and lr.{w|d}.sfx1 ... sc.{w|d}.sfx2? ~ Oleksii >=20 > > +#define __generic_cmpxchg(ptr, old, new, ret, lr_sfx, sc_sfx, pre, > > post) \ > > + ({ \ > > +=C2=A0=C2=A0=C2=A0 register unsigned int rc; \ > > +=C2=A0=C2=A0=C2=A0 asm volatile( \ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 pre \ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "0: lr" lr_sfx " %0, %2\n" = \ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "=C2=A0=C2=A0 bne=C2=A0 %0,= %z3, 1f\n" \ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "=C2=A0=C2=A0 sc" sc_sfx " = %1, %z4, %2\n" \ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "=C2=A0=C2=A0 bnez %1, 0b\n= " \ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 post \ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "1:\n" \ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : "=3D&r" (ret), "=3D&r" (r= c), "+A" (*ptr) \ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : "rJ" (old), "rJ" (new) \ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : "memory"); \ > > + }) > > + > > +/* > > + * For LR and SC, the A extension requires that the address held > > in rs1 be > > + * naturally aligned to the size of the operand (i.e., eight-byte > > aligned > > + * for 64-bit words and four-byte aligned for 32-bit words). > > + * If the address is not naturally aligned, an address-misaligned > > exception > > + * or an access-fault exception will be generated. > > + *=20 > > + * Thereby: > > + * - for 1-byte xchg access the containing word by clearing low > > two bits > > + * - for 2-byte xchg ccess the containing word by clearing first > > bit. > > + *=20 > > + * If resulting 4-byte access is still misalgined, it will fault > > just as > > + * non-emulated 4-byte access would. > > + * > > + * old_val was casted to unsigned long at the end of the define > > because of > > + * the following issue: > > + * ./arch/riscv/include/asm/cmpxchg.h:166:5: error: cast to > > pointer from integer of different size [-Werror=3Dint-to-pointer- > > cast] > > + * 166 |=C2=A0=C2=A0=C2=A0=C2=A0 (__typeof__(*(ptr)))(old_val >> new_v= al_pos); \ > > + *=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 ^ > > + * ./arch/riscv/include/asm/cmpxchg.h:184:17: note: in expansion > > of macro 'emulate_cmpxchg_1_2' > > + * 184 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ret__ =3D emu= late_cmpxchg_1_2(ptr, old, new, \ > > + *=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ^~~~~~~~~~~~~~~~~~~ > > + * ./arch/riscv/include/asm/cmpxchg.h:227:5: note: in expansion of > > macro '__cmpxchg_generic' > > + * 227 |=C2=A0=C2=A0=C2=A0=C2=A0 __cmpxchg_generic(ptr, (unsigned long= )(o), (unsigned > > long)(n), \ > > + *=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 ^~~~~~~~~~~~~~~~~ > > + * ./include/xen/lib.h:141:26: note: in expansion of macro > > '__cmpxchg' > > + * 141 |=C2=A0=C2=A0=C2=A0=C2=A0 ((__typeof__(*(ptr)))__cmpxchg(ptr, (= unsigned > > long)o_,=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 \ > > + *=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ^~~~~~~~~ > > + * common/event_channel.c:109:13: note: in expansion of macro > > 'cmpxchgptr' > > + * 109 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 cmpxchgptr(&xen_consumers[i], NULL, fn); > > + */ >=20 > This is too much detail on the compile issue. Just mentioning that > said > cast is needed for cmpxchgptr() ought to be sufficient. >=20 > > +#define emulate_cmpxchg_1_2(ptr, old, new, sc_sfx, pre, post) \ > > +({ \ > > +=C2=A0=C2=A0=C2=A0 uint32_t *aligned_ptr =3D (uint32_t *)((unsigned lo= ng)ptr & > > ~(0x4 - sizeof(*ptr))); \ > > +=C2=A0=C2=A0=C2=A0 uint8_t new_val_pos =3D ((unsigned long)(ptr) & (0x= 4 - > > sizeof(*ptr))) * BITS_PER_BYTE; \ > > +=C2=A0=C2=A0=C2=A0 unsigned long mask =3D GENMASK(((sizeof(*ptr)) * BI= TS_PER_BYTE) > > - 1, 0) << new_val_pos; \ > > +=C2=A0=C2=A0=C2=A0 unsigned int old_ =3D old << new_val_pos; \ > > +=C2=A0=C2=A0=C2=A0 unsigned int new_ =3D new << new_val_pos; \ > > +=C2=A0=C2=A0=C2=A0 unsigned int old_val; \ > > +=C2=A0=C2=A0=C2=A0 unsigned int xchged_val; \ > > +=C2=A0=C2=A0=C2=A0 \ > > +=C2=A0=C2=A0=C2=A0 __asm__ __volatile__ ( \ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 pre \ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "0: lr.w %[op_xchged_val], = %[op_aligned_ptr]\n" \ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "=C2=A0=C2=A0 and=C2=A0 %[o= p_oldval], %[op_xchged_val], %z[op_mask]\n" \ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "=C2=A0=C2=A0 bne=C2=A0 %[o= p_oldval], %z[op_old], 1f\n" \ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "=C2=A0=C2=A0 xor=C2=A0 %[o= p_xchged_val], %[op_oldval], > > %[op_xchged_val]\n" \ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "=C2=A0=C2=A0 or=C2=A0=C2= =A0 %[op_xchged_val], %[op_xchged_val], %z[op_new]\n" > > \ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "=C2=A0=C2=A0 sc.w" sc_sfx = " %[op_xchged_val], %[op_xchged_val], > > %[op_aligned_ptr]\n" \ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "=C2=A0=C2=A0 bnez %[op_xch= ged_val], 0b\n" \ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 post \ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "1:\n" \ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : [op_oldval] "=3D&r" (old_= val), [op_xchged_val] "=3D&r" > > (xchged_val), [op_aligned_ptr] "+A" (*aligned_ptr) \ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : [op_old] "rJ" (old_), [op= _new] "rJ" (new_), \ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [op_mask] "rJ" = (mask) \ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : "memory" ); \ > > +=C2=A0=C2=A0=C2=A0 \ > > +=C2=A0=C2=A0=C2=A0 (__typeof__(*(ptr)))((unsigned long)old_val >> new_= val_pos); \ > > +}) > > + > > +/* > > + * Atomic compare and exchange.=C2=A0 Compare OLD with MEM, if > > identical, > > + * store NEW in MEM.=C2=A0 Return the initial value in MEM.=C2=A0 Succ= ess is > > + * indicated by comparing RETURN with OLD. > > + */ > > +#define __cmpxchg_generic(ptr, old, new, size, sc_sfx, pre, post) > > \ > > +({ \ > > +=C2=A0=C2=A0=C2=A0 __typeof__(ptr) ptr__ =3D (ptr); \ > > +=C2=A0=C2=A0=C2=A0 __typeof__(*(ptr)) old__ =3D (__typeof__(*(ptr)))(o= ld); \ > > +=C2=A0=C2=A0=C2=A0 __typeof__(*(ptr)) new__ =3D (__typeof__(*(ptr)))(n= ew); \ > > +=C2=A0=C2=A0=C2=A0 __typeof__(*(ptr)) ret__; \ > > +=C2=A0=C2=A0=C2=A0 switch ( size ) \ > > +=C2=A0=C2=A0=C2=A0 { \ > > +=C2=A0=C2=A0=C2=A0 case 1: \ > > +=C2=A0=C2=A0=C2=A0 case 2: \ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ret__ =3D emulate_cmpxchg_1= _2(ptr, old, new, \ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 sc_sfx, pre, post); \ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 break; \ > > +=C2=A0=C2=A0=C2=A0 case 4: \ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 __generic_cmpxchg(ptr__, ol= d__, new__, ret__, \ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 ".w", ".w"sc_sfx, pre, post); \ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 break; \ > > +=C2=A0=C2=A0=C2=A0 case 8: \ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 __generic_cmpxchg(ptr__, ol= d__, new__, ret__, \ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 ".d", ".d"sc_sfx, pre, post); \ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 break; \ > > +=C2=A0=C2=A0=C2=A0 default: \ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 STATIC_ASSERT_UNREACHABLE()= ; \ > > +=C2=A0=C2=A0=C2=A0 } \ > > +=C2=A0=C2=A0=C2=A0 ret__; \ > > +}) > > + > > +#define cmpxchg_relaxed(ptr, o, n) \ > > +({ \ > > +=C2=A0=C2=A0=C2=A0 __typeof__(*(ptr)) o_ =3D (o); \ > > +=C2=A0=C2=A0=C2=A0 __typeof__(*(ptr)) n_ =3D (n); \ > > +=C2=A0=C2=A0=C2=A0 (__typeof__(*(ptr)))__cmpxchg_generic(ptr, \ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 o_, n_, sizeof(*(ptr)), "", "= ", ""); \ > > +}) > > + > > +#define cmpxchg_acquire(ptr, o, n) \ > > +({ \ > > +=C2=A0=C2=A0=C2=A0 __typeof__(*(ptr)) o_ =3D (o); \ > > +=C2=A0=C2=A0=C2=A0 __typeof__(*(ptr)) n_ =3D (n); \ > > +=C2=A0=C2=A0=C2=A0 (__typeof__(*(ptr)))__cmpxchg_generic(ptr, o_, n_, > > sizeof(*(ptr)), \ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 "", "", > > RISCV_ACQUIRE_BARRIER); \ > > +}) > > + > > +#define cmpxchg_release(ptr, o, n) \ > > +({ \ > > +=C2=A0=C2=A0=C2=A0 __typeof__(*(ptr)) o_ =3D (o); \ > > +=C2=A0=C2=A0=C2=A0 __typeof__(*(ptr)) n_ =3D (n); \ > > +=C2=A0=C2=A0=C2=A0 (__typeof__(*(ptr)))__cmpxchg_release(ptr, o_, n_, > > sizeof(*(ptr)), \ >=20 > There's no __cmpxchg_release() afaics; dym __cmpxchg_generic()? >=20 > Jan From xen-devel-bounces@lists.xenproject.org Thu Mar 07 10:39:06 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 10:39:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689751.1074998 (Exim 4.92) (envelope-from ) id 1riB9W-00078d-0y; Thu, 07 Mar 2024 10:39:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689751.1074998; Thu, 07 Mar 2024 10:39:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riB9V-00078W-UN; Thu, 07 Mar 2024 10:39:05 +0000 Received: by outflank-mailman (input) for mailman id 689751; Thu, 07 Mar 2024 10:39:05 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riB9V-00078Q-08 for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 10:39:05 +0000 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on20601.outbound.protection.outlook.com [2a01:111:f403:2415::601]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id ea7ea32a-dc6e-11ee-afda-a90da7624cb6; Thu, 07 Mar 2024 11:39:03 +0100 (CET) Received: from PH7P221CA0019.NAMP221.PROD.OUTLOOK.COM (2603:10b6:510:32a::15) by SN7PR12MB7131.namprd12.prod.outlook.com (2603:10b6:806:2a3::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.26; Thu, 7 Mar 2024 10:39:00 +0000 Received: from SN1PEPF0002529F.namprd05.prod.outlook.com (2603:10b6:510:32a:cafe::25) by PH7P221CA0019.outlook.office365.com (2603:10b6:510:32a::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7339.39 via Frontend Transport; Thu, 7 Mar 2024 10:39:00 +0000 Received: from SATLEXMB03.amd.com (165.204.84.17) by SN1PEPF0002529F.mail.protection.outlook.com (10.167.242.6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7362.11 via Frontend Transport; Thu, 7 Mar 2024 10:38:59 +0000 Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 7 Mar 2024 04:38:56 -0600 Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB05.amd.com (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 7 Mar 2024 04:38:56 -0600 Received: from henry-MS-7D54.amd.com (10.180.168.240) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.35 via Frontend Transport; Thu, 7 Mar 2024 04:38:54 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ea7ea32a-dc6e-11ee-afda-a90da7624cb6 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bBS64xvIJFiZ/RmlsJu2t/bhmHzhPYvs9uksPESOdxDIUe5SW8NgACsrscNkgezUqddbKfQKW0CRld3QQdQnm2k+HxTPRgcjZL3H3y7MzxgCPfB9A8XaCFwK/VapU62dVpLhH//uhDfzgfqOg0wzS/fKh4vyccun1IKLiPbC2K4CyrAcEoVv5KkRYO1aus3z/5IFMUkBhlRH4lqTpp/t/BfOjoEP24UzJ8SVsc5oo148mGSY7IkUefGSjQgLcZ4kxHeTT67NNnPBnVbDi0P9ayUB/JWMRGQGs0UeEJghlR7TegU4XRqvgxLK3Z+dzekQejkvqzSipH9sqErJD0y4Rw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=0lDKtyh31u8dwYxymmmUfs05dLNVR57uq36d4Emq/4c=; b=UKimA3iljT+dE17uTdFw0/IJglP1Q0h4nzcl03SoneClpp3zdgkznIJBj09ViCRVLwyOWJlyyy2Xj1Jal9NEAr+q5C36go5RNvnG3/0B1QWkH/64Qf3O3ZwzGWPxiz9IFg8wF5KfKizD8KYUDiV9QZUq7jNZJzTZizDtADJhXKS3ESqy3gxxilwpWU9y4cvsze8D8UdmT6QUf3uLEJaHtIHmr/dzZz8aP1LBxwW235BROMOKrVfQcLUdwBLzaahmGjSRxaJ7J32QEifDvApsRxkBHWDvrupfib5BbfV4LZghofIBqikhHCe4pBk1UX0HCCB6B4G8P5cCCNjrius0Fg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0lDKtyh31u8dwYxymmmUfs05dLNVR57uq36d4Emq/4c=; b=jHgd62uIAb6PvBhefbYq83NVqVUGqWFlVuVgoZDDVXi0SCFGmS/cIDRzTm7DdJ9117FXbGEoT/4MPbIdFA0G6z3frMBosQ6/ImEQ/tIjMd5vQ01Kr5e1s+zsK5FDeVK9DRZpuoDJzF4/bDeH02IS83D5e1C01wg0OyIAt+Wu/ig= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C From: Henry Wang To: CC: Henry Wang , Wei Liu , Anthony PERARD , Juergen Gross , Jan Beulich Subject: [PATCH v2] tools/9pfsd: Fix build error caused by strerror_r() Date: Thu, 7 Mar 2024 18:38:47 +0800 Message-ID: <20240307103847.3710737-1-xin.wang2@amd.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain Received-SPF: None (SATLEXMB05.amd.com: xin.wang2@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SN1PEPF0002529F:EE_|SN7PR12MB7131:EE_ X-MS-Office365-Filtering-Correlation-Id: cfe1a8ce-c3e9-4caa-3f49-08dc3e92cc82 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: EgnAYggpIssm+uWVc8jTBhI1aO8EcbCQmlMvpK+GCe0UpX5goxzIBXJ+aRfIbIKOC995cP0fh3D7i6YZX0JJ+WIOcMn27y4/RjutEgamSd+K7vum7kEj0kdkIMJYdtd7y5167phDga89mHHM0d2FmTNXNCQQZBKZyE59eLP2TtW2wwiZM41tl++cdF8R2eOh/JrwUfW/3sZdxvTTQn9B+nELPCqOSZQNvZPeke2DX4oUU89S6cvtoHCcLddZ/sj7JiRv4E0R6vRz04sMJcQ39pVJWwyWXR9ozfGVyobc3ucsf87GtOHI61LzK0Ad9kOjZ5Fb06DUuud08GRvphKPxyLpU2WCb/KpvJduB3Z6guMLst43fl/RVYjB0gQxY7Uzr9jYA5UOg316GGx97jeGNOK0BGQCYUZB1sMfiXaZOImDK5xieh7yY9/aN7iLPUP+vhnFzxHZ2jMhduIl4IjHZ7q6KiJZHiu1nEScq432svJP5hl2orv/mN6nywEVtxaxzqBJL7+bWomJ1nDCdE9fdKSgY8UEPbYidevtTKSSyCe1fYRvBsnzsqpZ4ywxbxvsSvpRnEBT7AA3nSDNOqUgzKnCmm8EthFqClSMboS7ZA8ZXWEa8GPPMDhx12Av9WBdkL363A4UzYO13Syy6il8tH2pGvIRbxkC4PnoHB0UxMNzJ8c95GpD25BeqyNKlJtozT5Usm1mZtoA1lqobOgzdtNxfmc7j3dM54UAZ1FvxeJzE1CAvXi2DoMf/EkEmkGQ X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(82310400014)(376005)(36860700004);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Mar 2024 10:38:59.6378 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: cfe1a8ce-c3e9-4caa-3f49-08dc3e92cc82 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SN1PEPF0002529F.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB7131 Below error can be seen when doing Yocto build of the toolstack: | io.c: In function 'p9_error': | io.c:684:5: error: ignoring return value of 'strerror_r' declared with attribute 'warn_unused_result' [-Werror=unused-result] | 684 | strerror_r(err, ring->buffer, ring->ring_size); | | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | cc1: all warnings being treated as errors Fix the build by using strerror() to replace strerror_r(). Since strerror() is thread-unsafe, use a separate local mutex to protect the action. The steps would then become: Acquire the mutex first, invoke strerror(), copy the string from strerror() to the designated buffer and then drop the mutex. Signed-off-by: Henry Wang --- tools/9pfsd/io.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/tools/9pfsd/io.c b/tools/9pfsd/io.c index adb887c7d9..2b80c9528d 100644 --- a/tools/9pfsd/io.c +++ b/tools/9pfsd/io.c @@ -680,8 +680,18 @@ static bool name_ok(const char *str) static void p9_error(struct ring *ring, uint16_t tag, uint32_t err) { unsigned int erroff; + static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER; + char *strerror_str; + RING_IDX strerror_len = 0, copy_len = 0; + + pthread_mutex_lock(&mutex); + strerror_str = strerror(err); + strerror_len = strlen(strerror_str) + 1; + copy_len = min(strerror_len, ring->ring_size); + memcpy(ring->buffer, strerror_str, copy_len); + ((char *)(ring->buffer))[copy_len - 1] = '\0'; + pthread_mutex_unlock(&mutex); - strerror_r(err, ring->buffer, ring->ring_size); erroff = add_string(ring, ring->buffer, strlen(ring->buffer)); fill_buffer(ring, P9_CMD_ERROR, tag, "SU", erroff != ~0 ? ring->str + erroff : "cannot allocate memory", -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Thu Mar 07 10:43:29 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 10:43:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689754.1075008 (Exim 4.92) (envelope-from ) id 1riBDh-0000nQ-Gq; Thu, 07 Mar 2024 10:43:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689754.1075008; Thu, 07 Mar 2024 10:43:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riBDh-0000nJ-EC; Thu, 07 Mar 2024 10:43:25 +0000 Received: by outflank-mailman (input) for mailman id 689754; Thu, 07 Mar 2024 10:43:24 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riBDg-0000nD-Ih for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 10:43:24 +0000 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on20601.outbound.protection.outlook.com [2a01:111:f403:200a::601]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 84a0db5d-dc6f-11ee-afda-a90da7624cb6; Thu, 07 Mar 2024 11:43:23 +0100 (CET) Received: from MN2PR18CA0014.namprd18.prod.outlook.com (2603:10b6:208:23c::19) by CH3PR12MB8403.namprd12.prod.outlook.com (2603:10b6:610:133::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.24; Thu, 7 Mar 2024 10:43:17 +0000 Received: from BL02EPF0001A101.namprd05.prod.outlook.com (2603:10b6:208:23c:cafe::c7) by MN2PR18CA0014.outlook.office365.com (2603:10b6:208:23c::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.26 via Frontend Transport; Thu, 7 Mar 2024 10:43:17 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by BL02EPF0001A101.mail.protection.outlook.com (10.167.241.132) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7362.11 via Frontend Transport; Thu, 7 Mar 2024 10:43:17 +0000 Received: from SATLEXMB06.amd.com (10.181.40.147) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 7 Mar 2024 04:43:16 -0600 Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB06.amd.com (10.181.40.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 7 Mar 2024 04:43:16 -0600 Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.35 via Frontend Transport; Thu, 7 Mar 2024 04:43:15 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 84a0db5d-dc6f-11ee-afda-a90da7624cb6 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cp3DA5l32izZlCgppM6/6/+UrlMpX1coOQx+aWUxFj88rZb46VMoHD5jFK40suZ3F3FCzE3IWHAIkBsipgz3zezpEyDzSp7jvZXsSKXu1djBuH2MUSd7gnGDbDZ8JIt9jxIy+txSiKHrj1SJiaxmV7eD0rhvNxnuLRd/8bgRVSlmWj843uZddmMOPE1lLGUEAJ7TbP9ecyILkesbd3jTbdwun+PgVgeZ6rgHZzpX9PqyRauTAc3Dg6cBiTHIyLONb6UCbWepzWJxEIH5Klfk4nslO9+lRew6jHD/oJ7BEmUEE/vbkowmjNmKJvMW7rHISV8awDrpmyT/Xuhm5/Ci0A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=GguB6Fj7X2ib2jvi6DRRf55VTe2TQEPTmcFfApAs/qQ=; b=QaszeEq4p0U5Ec2JW/vHTETX58qROaVm5gRQxc/J0+KuCzqu78eVJW/a/mTGNW5Kh/4zJQ+g9NmRnQHZSHFPfHW7bD1QOGodCnTId+eVsryyqg3LvS/SRawP5A5Kae3dI03DsGKy/edYEAFv8MlGBrQdF8sRrjcrl1uIKjSAXppl06C8LuOybeK6JwPoKfnaQs4cvpzWrtzqI/cD8xBHXiKu8EwJbkTDkr9oTOFgW8g4SSpVjTGUcYMXlhApAesK92XPqF8U8/w+/yUvV5R3akxouUl4/c5vkHQL9t/UJpu/aQCavgcOFBDrT5wYSpe9X91ZeTuWA8nvb1AkJb34sA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=linaro.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GguB6Fj7X2ib2jvi6DRRf55VTe2TQEPTmcFfApAs/qQ=; b=sEWPmnfva5nVY3r7nsCTUQRfKH8cD/2X+crko8/nH93QgSBhMMAxXvbBWHNrTKN/Vi54I6LaJPy+sqE4AOJkGplujZJjx8DoL5zoVsXpMOlLO1X1AMy5CMsxLyDDD+X8vIaLL4qHkd36sACfJzXbBlZvlhAT2FlcUisBFNDcv6w= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C Message-ID: <5eaf5a24-d9b6-4045-8b90-61897464d7a2@amd.com> Date: Thu, 7 Mar 2024 11:43:14 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH v2] xen/arm: improve handling of load/store instruction decoding Content-Language: en-US To: Manos Pitsidianakis , =?UTF-8?Q?Alex_Benn_=C3=A9_e?= , CC: , , References: <20240306165621.3819343-1-alex.bennee@linaro.org> <3cb1b056-59a7-4ffe-856d-e45aac1936a9@amd.com> <9z3mh.tiey2z2itr9a@linaro.org> From: Michal Orzel In-Reply-To: <9z3mh.tiey2z2itr9a@linaro.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BL02EPF0001A101:EE_|CH3PR12MB8403:EE_ X-MS-Office365-Filtering-Correlation-Id: 19b09ebe-2ef6-4a98-898f-08dc3e9365e6 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: YIDeGHO8AUZ8CZbEgUaNRMK+1b1DZXIU1dFtf0mZXo2Va/zLQUuLYD82DYMO4UIGqwK5HMlnYZjHDydtXMdUwMa9ICrCe0UwXWBe1pTkt0OOtjZO61RVi3PhL3fXlh7OcIB7JhP85UemwGWtyM6ewQ2fpJHA53jpcuFZV9xEOLoFuc3Q9S2sonPAp95rSK0p7FwLSilckDq5PffsP7NOVVeK+IBoQKDKL85ZVDVrSPhqzrMTYkTYQxP/TyU470vDmiO5WeBBDUNwGk05Piv5SKmsu3VpMEWoWLx2c1JgPjMIlZkBmKgIrU9wykDZoFdusoGjtQ+rsozAVeTFZA70laHBIKIGugIIbczZcnnhpAm2odaBPrmXzqkVNPmCeZVaiPTAlJJO3PETYAnb0k1XmlrLMRcTY52LPe1/eYPFPlJMV1u6099LAyHnah3xOwoMKZ6RqdLdps6IBT/uoMpeiVQ3Cdn/i2prMxmu1IujiQHD8EhEYg9B8vwjpVzlA1e4q5ufMe9T7AVz6iPSpZ0CkK5b1gxhlVtW2DMRnPmEhETt7d/75pcnfY29zcPiClx27Gu+7BbgxciUyg8NU8PhT+8wcO32rN8aJYF8efGH+zhX06vdcUXeB1sNPhgMz12uAAy1tZiltprkFcGu5olkt/vxB2ewuXrZAtDpA0lWWuOe0QPi5HknplnhOKo8yuTIz9Vt+Rk26AbLyMHOs3kgqAqZtFX6viRyOaeisuG6E1XPeOvcvSRTPipNPthqyr1c X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(376005)(36860700004)(82310400014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Mar 2024 10:43:17.0021 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 19b09ebe-2ef6-4a98-898f-08dc3e9365e6 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BL02EPF0001A101.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB8403 On 07/03/2024 11:02, Manos Pitsidianakis wrote: > > > Hi Michal, Alex, > > I'm responding to Michel but also giving my own review comments here. > > On Thu, 07 Mar 2024 10:40, Michal Orzel wrote: >> Hi Alex, >> >> NIT: RFC tag is no longer needed. >> >> On 06/03/2024 17:56, Alex Bennée wrote: >>> >>> >>> While debugging VirtIO on Arm we ran into a warning due to memory >>> being memcpy'd across MMIO space. While the bug was in the mappings >>> the warning was a little confusing: >>> >>> (XEN) d47v2 Rn should not be equal to Rt except for r31 >>> (XEN) d47v2 unhandled Arm instruction 0x3d800000 >>> (XEN) d47v2 Unable to decode instruction >>> >>> The Rn == Rt warning is only applicable to single register load/stores >>> so add some verification steps before to weed out unexpected accesses. >>> >>> While at it update the Arm ARM references to the latest version of the >>> documentation. >>> >>> Signed-off-by: Alex Bennée >>> Cc: Manos Pitsidianakis >> Move the CC line after --- so that it's not included in the final commit msg. >> >>> >>> --- >>> v2 >>> - use single line comments where applicable >>> - update Arm ARM references >>> - use #defines for magic numbers >>> --- >>> xen/arch/arm/decode.c | 35 ++++++++++++++++++++------ >>> xen/arch/arm/decode.h | 57 ++++++++++++++++++++++++++++++++++++++----- >>> 2 files changed, 79 insertions(+), 13 deletions(-) >>> >>> diff --git a/xen/arch/arm/decode.c b/xen/arch/arm/decode.c >>> index 2537dbebc1..73a88e4701 100644 >>> --- a/xen/arch/arm/decode.c >>> +++ b/xen/arch/arm/decode.c >>> @@ -87,15 +87,36 @@ static int decode_arm64(register_t pc, mmio_info_t *info) >>> return 1; >>> } >>> >>> + /* Check this is a load/store of some sort */ >>> + if ( (opcode.top_level.op1 & TL_LDST_OP1_MASK) != TL_LDST_OP1_VALUE ) >>> + { >>> + gprintk(XENLOG_ERR, "Not a load/store instruction op1=%u\n", >>> + opcode.top_level.op1); >>> + goto bad_loadstore; >>> + } >>> + >>> + /* We are only expecting single register load/stores */ >>> + if ( (opcode.ld_st.op0 & LS_SREG_OP0_MASK) != LS_SREG_OP0_VALUE ) >>> + { >>> + gprintk(XENLOG_ERR, "Not single register load/store op0=%u\n", >> NIT: missing 'a' between Not and single >> >>> + opcode.ld_st.op0); >>> + goto bad_loadstore; >>> + } >>> + >>> /* >>> - * Refer Arm v8 ARM DDI 0487G.b, Page - C6-1107 >>> - * "Shared decode for all encodings" (under ldr immediate) >>> - * If n == t && n != 31, then the return value is implementation defined >>> - * (can be WBSUPPRESS, UNKNOWN, UNDEFINED or NOP). Thus, we do not support >>> - * this. This holds true for ldrb/ldrh immediate as well. >>> + * Refer Arm v8 ARM DDI 0487J.a, Page - K1-12586 >>> + * >>> + * STR (immediate) CONSTRAINED UNPREDICTABLE behaviour >>> + * >>> + * "If the instruction encoding specifies pre-indexed addressing or >>> + * post-indexed addressing, and n == t && n != 31, then one of the >>> + * following behaviors must occur:" UNDEFINED, NOP or UNKNOWN >>> + * >>> + * Execution @ EL0/EL1 when HCR_EL2.TIDCP is 1 traps to EL2 with >>> + * EC = 0. >>> * >>> - * Also refer, Page - C6-1384, the above described behaviour is same for >>> - * str immediate. This holds true for strb/strh immediate as well >>> + * This also hold true for LDR (immediate), Page K1-12581 and >>> + * the RB/RH variants of both. >>> */ >>> if ( (opcode.ldr_str.rn == opcode.ldr_str.rt) && (opcode.ldr_str.rn != 31) ) >>> { >>> diff --git a/xen/arch/arm/decode.h b/xen/arch/arm/decode.h >>> index 13db8ac968..188114a71e 100644 >>> --- a/xen/arch/arm/decode.h >>> +++ b/xen/arch/arm/decode.h >>> @@ -24,17 +24,54 @@ >>> #include >>> >>> /* >>> - * Refer to the ARMv8 ARM (DDI 0487G.b), Section C4.1.4 Loads and Stores >>> - * Page 318 specifies the following bit pattern for >>> - * "load/store register (immediate post-indexed)". >>> + * Refer to the ARMv8 ARM (DDI 0487J.a) >>> * >>> - * 31 30 29 27 26 25 23 21 20 11 9 4 0 >>> + * Section C A64 Instruct Set Encoding >> This line is not needed > > I think it is needed for context (it answers the question "what is > C4.1?" in the following line. > >>> + * >>> + * C4.1 A64 instruction set encoding: >> NIT: I would put a comma after section number i.e. C4.1, A64 ... >> The same would apply in other places. > > Style manuals use either space (like here), a period (.) or colon (:), > never a comma. Since it's a NIT, I'm not going to object. I just care about readability, we do not need to adhere to any "style manuals". > >> >>> + * >>> + * 31 30 29 28 25 24 0 >>> * ___________________________________________________________________ >>> - * |size|1 1 1 |V |0 0 |opc |0 | imm9 |0 1 | Rn | Rt | >>> - * |____|______|__|____|____|__|_______________|____|_________|_______| >>> + * |op0 | x x | op1 | | >>> + * |____|______|______|_______________________________________________| >>> + * >>> + * op0 = 0 is reserved >> I'm not sure how to read it. It is reserved provided op1 is also 0. > > Yes, it should say something like: > >> Decode field values op0 = 0, op1 = 0 are reserved. >> Values op0 = 1, op1 = x1x0 correspond to Loads and Stores > >>> + * op1 = x1x0 for Loads and Stores >>> + * >>> + * Section C4.1.88 Loads and Stores >> Missing colon at the end? > > It's a heading so a colon would not be appropriate. In this case why was it added before in: "C4.1 A64 instruction set encoding:" > >> >>> + * >>> + * 31 28 27 26 25 24 23 22 21 16 15 12 11 10 9 0 >>> + * ___________________________________________________________________ >>> + * | op0 | 1 | op1 | 0 | op2 | | op3 | | op4 | | >>> + * |________|___|_____|___|_____|__|__________|______|_____|__________| >>> + * > > Maybe we should add the op{0,1,2,3,4} values for consistency? > >> Values op0=xx11, op1=0, op2=0x, op3=0xxxxx, op4=01 correspond to >> Load/store register (immediate post-indexed) I think this should stay neutral in case we add a new emulation in a future. > >>> + * Page C4-653 Load/store register (immediate post-indexed) >>> + * >>> + * 31 30 29 27 26 25 24 23 22 21 20 12 11 10 9 5 4 0 >>> + * ___________________________________________________________________ >>> + * |size|1 1 1 |V | 0 0 | opc |0 | imm9 | 0 1 | Rn | Rt | >>> + * |____|______|__|_____|_____|__|_______________|_____|______|_______| >>> */ >>> union instr { >>> uint32_t value; >>> + struct { >>> + unsigned int ign2:25; >> Here, your numeration of ignore fields is in descending order (starting from lsb) but .., >> >>> + unsigned int op1:4; /* instruction class */ >>> + unsigned int ign1:2; >>> + unsigned int op0:1; /* value = 1b */ >> Why op0 = 0b1 ? This structure represents the generic bit layout (the emulation deals with single ldr/str). >> I would drop this comment. > > It is a reserved bit which can never be 0. Where did you take this information from? As I wrote above, I don't think we should bind this union to a single use case we currently have. The struct top_level should represent the generic encoding of A64 instruction. ~Michal From xen-devel-bounces@lists.xenproject.org Thu Mar 07 10:46:45 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 10:46:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689758.1075018 (Exim 4.92) (envelope-from ) id 1riBGt-0001Ll-UO; Thu, 07 Mar 2024 10:46:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689758.1075018; Thu, 07 Mar 2024 10:46:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riBGt-0001Le-Qp; Thu, 07 Mar 2024 10:46:43 +0000 Received: by outflank-mailman (input) for mailman id 689758; Thu, 07 Mar 2024 10:46:42 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riBGs-0001LT-AB for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 10:46:42 +0000 Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [2a00:1450:4864:20::633]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id fb5afb53-dc6f-11ee-afda-a90da7624cb6; Thu, 07 Mar 2024 11:46:41 +0100 (CET) Received: by mail-ej1-x633.google.com with SMTP id a640c23a62f3a-a44628725e3so101459666b.0 for ; Thu, 07 Mar 2024 02:46:41 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id i7-20020a17090639c700b00a45ae9636d2sm2297200eje.107.2024.03.07.02.46.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Mar 2024 02:46:40 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fb5afb53-dc6f-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709808401; x=1710413201; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=UZ3Hlv3IloJ+ZC2OKOC4rqgHWvC3LhHGBUj0s74mEFI=; b=GJRSK7DoLd8NSqC8t/Uf37znVjVKoMZsArc+kHBY8ARH7oyauFfaEBx4e5VZBTAKg0 9OyixqIci/9Z3Bz9c7evUhP0SeFnbv1+17GT5i65ZK7quLGHK+cXaDHEh3O0IDT2xOGA MPQvcxcJpLrZslfFcDis/02eGuWuKZDVxRc1x43PW5ZgXUHVIbzawP9fOEugJ5yqi0DP DQ4zTwPBQOfqcXboQL+/iuYZzWawjQsBYULEuTi0N0WC6qiRPD989ie/u2r1IrHonjLN cUNi0kzbWrpm5CEgsK+PPFjzQVq+Ft6QaFMfTjMax391Ox75sQB6g7JYcMJPvCYPh+jp OvmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709808401; x=1710413201; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=UZ3Hlv3IloJ+ZC2OKOC4rqgHWvC3LhHGBUj0s74mEFI=; b=NKLo/SjhjECoRfoZGBVb47901HG3c5HK2Yk1bMBdEKUeyvyWryE4LPLzl8RAKXF06r Xty8faytvKAygO0rgL9HWC09y7ezlh+CBcj2a1lxcOoh2SHgRi8JfFKfQ1cF7/sCiZFa zTd9J6CTBEVyd5Rc3FQb0GU79SAfxLPln2oMTTX7ZbKA1a3EyYSegPEhympGueo14B7R 7MjiQHDPZ60TWit1Rh69PHcU57UPCq++UhSukShLz+FaZ96HNY71YQ2DvqBXaI0iHlug giYZcI9o4ejSrfIUDZm5EEba5dA/Pib7vh4XG5Kqpa4X3qiY7wvdmtv0YGce6aeGVPEj aD3g== X-Forwarded-Encrypted: i=1; AJvYcCUEwPFtQgG48GYFKP3eDNIMralYYi19KaT68gqyJtyeDXPLhIb7sQ1BkwJktMWg6xq2tzO7PmUgko/J9yuDrTLXuUkd+Cy8NAJO9Wctw7E= X-Gm-Message-State: AOJu0Yy9WBFojLYCZI5teAnuX596UxAwlQg1kPhD/OpE49zl2gkLT0H3 cZEGpwNTX8VjnWSFH6bWz4rc9+1gVwHjMUu3S9UrJrnlFMiOP1sMz22CthtqZw== X-Google-Smtp-Source: AGHT+IG2QmYH74T2ZqsmxzCAYzR6PKE5C77KI/OsRCHlk7x9YXnp8/40KEn72bakMQ8fanJArv+llA== X-Received: by 2002:a17:906:4902:b0:a45:1254:abd5 with SMTP id b2-20020a170906490200b00a451254abd5mr8819334ejq.58.1709808400644; Thu, 07 Mar 2024 02:46:40 -0800 (PST) Message-ID: Date: Thu, 7 Mar 2024 11:46:39 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 11/23] xen/riscv: introduce cmpxchg.h Content-Language: en-US To: Oleksii Cc: Alistair Francis , Bob Eshleman , Connor Davis , Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu , xen-devel@lists.xenproject.org References: <23ff1c20-91f3-4c60-9562-7f1cd57c1043@suse.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 07.03.2024 11:35, Oleksii wrote: > On Wed, 2024-03-06 at 15:56 +0100, Jan Beulich wrote: >> On 26.02.2024 18:38, Oleksii Kurochko wrote: >>> The header was taken from Linux kernl 6.4.0-rc1. >>> >>> Addionally, were updated: >>> * add emulation of {cmp}xchg for 1/2 byte types using 32-bit atomic >>>   access. >>> * replace tabs with spaces >>> * replace __* variale with *__ >>> * introduce generic version of xchg_* and cmpxchg_*. >>> >>> Implementation of 4- and 8-byte cases were left as it is done in >>> Linux kernel as according to the RISC-V spec: >>> ``` >>> Table A.5 ( only part of the table was copied here ) >>> >>> Linux Construct       RVWMO Mapping >>> atomic relaxed    amo.{w|d} >>> atomic acquire    amo.{w|d}.aq >>> atomic release    amo.{w|d}.rl >>> atomic             amo.{w|d}.aqrl >>> >>> Linux Construct       RVWMO LR/SC Mapping >>> atomic relaxed    loop: lr.{w|d}; ; sc.{w|d}; bnez loop >>> atomic acquire    loop: lr.{w|d}.aq; ; sc.{w|d}; bnez loop >>> atomic release    loop: lr.{w|d}; ; sc.{w|d}.aqrl∗ ; bnez >>> loop OR >>>                        fence.tso; loop: lr.{w|d}; ; sc.{w|d}∗ ; >>> bnez loop >>> atomic             loop: lr.{w|d}.aq; ; sc.{w|d}.aqrl; bnez >>> loop >>> >>> The Linux mappings for release operations may seem stronger than >>> necessary, >>> but these mappings are needed to cover some cases in which Linux >>> requires >>> stronger orderings than the more intuitive mappings would provide. >>> In particular, as of the time this text is being written, Linux is >>> actively >>> debating whether to require load-load, load-store, and store-store >>> orderings >>> between accesses in one critical section and accesses in a >>> subsequent critical >>> section in the same hart and protected by the same synchronization >>> object. >>> Not all combinations of FENCE RW,W/FENCE R,RW mappings with aq/rl >>> mappings >>> combine to provide such orderings. >>> There are a few ways around this problem, including: >>> 1. Always use FENCE RW,W/FENCE R,RW, and never use aq/rl. This >>> suffices >>>    but is undesirable, as it defeats the purpose of the aq/rl >>> modifiers. >>> 2. Always use aq/rl, and never use FENCE RW,W/FENCE R,RW. This does >>> not >>>    currently work due to the lack of load and store opcodes with aq >>> and rl >>>    modifiers. >> >> As before I don't understand this point. Can you give an example of >> what >> sort of opcode / instruction is missing? > If I understand the spec correctly then l{b|h|w|d} and s{b|h|w|d} > instructions don't have aq or rl annotation. How would load insns other that LR and store insns other than SC come into play here? >>> 3. Strengthen the mappings of release operations such that they >>> would >>>    enforce sufficient orderings in the presence of either type of >>> acquire mapping. >>>    This is the currently-recommended solution, and the one shown in >>> Table A.5. >>> ``` >>> >>> But in Linux kenrel atomics were strengthen with fences: >>> ``` >>> Atomics present the same issue with locking: release and acquire >>> variants need to be strengthened to meet the constraints defined >>> by the Linux-kernel memory consistency model [1]. >>> >>> Atomics present a further issue: implementations of atomics such >>> as atomic_cmpxchg() and atomic_add_unless() rely on LR/SC pairs, >>> which do not give full-ordering with .aqrl; for example, current >>> implementations allow the "lr-sc-aqrl-pair-vs-full-barrier" test >>> below to end up with the state indicated in the "exists" clause. >>> >>> In order to "synchronize" LKMM and RISC-V's implementation, this >>> commit strengthens the implementations of the atomics operations >>> by replacing .rl and .aq with the use of ("lightweigth") fences, >>> and by replacing .aqrl LR/SC pairs in sequences such as: >>> >>> 0:      lr.w.aqrl  %0, %addr >>>         bne        %0, %old, 1f >>>         ... >>>         sc.w.aqrl  %1, %new, %addr >>>         bnez       %1, 0b >>> 1: >>> >>> with sequences of the form: >>> >>> 0:      lr.w       %0, %addr >>>         bne        %0, %old, 1f >>>               ... >>>         sc.w.rl    %1, %new, %addr   /* SC-release   */ >>>         bnez       %1, 0b >>>         fence      rw, rw            /* "full" fence */ >>> 1: >>> >>> following Daniel's suggestion. >>> >>> These modifications were validated with simulation of the RISC-V >>> memory consistency model. >>> >>> C lr-sc-aqrl-pair-vs-full-barrier >>> >>> {} >>> >>> P0(int *x, int *y, atomic_t *u) >>> { >>>         int r0; >>>         int r1; >>> >>>         WRITE_ONCE(*x, 1); >>>         r0 = atomic_cmpxchg(u, 0, 1); >>>         r1 = READ_ONCE(*y); >>> } >>> >>> P1(int *x, int *y, atomic_t *v) >>> { >>>         int r0; >>>         int r1; >>> >>>         WRITE_ONCE(*y, 1); >>>         r0 = atomic_cmpxchg(v, 0, 1); >>>         r1 = READ_ONCE(*x); >>> } >>> >>> exists (u=1 /\ v=1 /\ 0:r1=0 /\ 1:r1=0) >> >> While I'm entirely willing to trust this can happen, I can't bring >> this >> in line with the A extension spec. >> >> Additionally it's not clear to me in how far all of this applies when >> you don't really use LR/SC in the 4- and 8-byte cases (and going >> forward >> likely also not in the 1- and 2-byte case, utilizing Zahba when >> available). > It just explain what combination of fences, lr/sc, amoswap, .aq and .rl > annotation can be combined, and why combinations introduced in this > patch are used. Except that I don't understand that explanation, iow why said combination of values could be observed even when using suffixes properly. >>> +    uint8_t new_val_pos = ((unsigned long)(ptr) & (0x4 - >>> sizeof(*ptr))) * BITS_PER_BYTE; \ >> >> Why uint8_t? > It is enough to cover possible start bit position of value that should > be updated, so I decided to use uint8_t. Please take a look at the "Types" section in ./CODING_STYLE. >>> +    { \ >>> +    case 1: \ >>> +    case 2: \ >>> +        ret__ = emulate_xchg_1_2(ptr, new__, sfx, pre, post); \ >>> +        break; \ >>> +    case 4: \ >>> +        __amoswap_generic(ptr, new__, ret__,\ >>> +                          ".w" sfx,  pre, post); \ >>> +        break; \ >>> +    case 8: \ >>> +        __amoswap_generic(ptr, new__, ret__,\ >>> +                          ".d" sfx,  pre, post); \ >>> +        break; \ >> >> In io.h you make sure to avoid rv64-only insns. Here you don't. The >> build >> would fail either way, but this still looks inconsistent. >> >> Also nit: Stray double blands (twice) ahead of "pre". Plus with this >> style >> of line continuation you want to consistently have exactly one blank >> ahead >> of each backslash. >> >>> +    default: \ >>> +        STATIC_ASSERT_UNREACHABLE(); \ >>> +    } \ >>> +    ret__; \ >>> +}) >>> + >>> +#define xchg_relaxed(ptr, x) \ >>> +({ \ >>> +    __typeof__(*(ptr)) x_ = (x); \ >> >> What is the purpose of this, when __xchg_generic() already does this >> same >> type conversion? >> >>> +    (__typeof__(*(ptr)))__xchg_generic(ptr, x_, sizeof(*(ptr)), >>> "", "", ""); \ >>> +}) >>> + >>> +#define xchg_acquire(ptr, x) \ >>> +({ \ >>> +    __typeof__(*(ptr)) x_ = (x); \ >>> +    (__typeof__(*(ptr)))__xchg_generic(ptr, x_, sizeof(*(ptr)), \ >>> +                                       "", "", >>> RISCV_ACQUIRE_BARRIER); \ >>> +}) >>> + >>> +#define xchg_release(ptr, x) \ >>> +({ \ >>> +    __typeof__(*(ptr)) x_ = (x); \ >>> +    (__typeof__(*(ptr)))__xchg_generic(ptr, x_, sizeof(*(ptr)),\ >>> +                                       "", RISCV_RELEASE_BARRIER, >>> ""); \ >>> +}) >> >> As asked before: Are there going to be any uses of these three? >> Common >> code doesn't require them. And not needing to provide them would >> simplify things quite a bit, it seems. > I checked my private branches and it looks to me that I introduced them > only for the correspondent atomic operations ( which was copied from > Linux Kernel ) which are not also used. > > So we could definitely drop these macros for now, but should > xchg_generic() be updated as well? If to look at: > #define xchg(ptr, x) __xchg_generic(ptr, (unsigned long)(x), sizeof(* > (ptr)), \ > ".aqrl", "", "") > Last two arguments start to be unneeded, but I've wanted to leave them, > in case someone will needed to back xchg_{release, acquire, ...}. Does > it make any sense? It all depends on how it's justified in the description. >>> +#define xchg(ptr, x) __xchg_generic(ptr, (unsigned long)(x), >>> sizeof(*(ptr)), \ >>> +                                    ".aqrl", "", "") >> >> According to the earlier comment (where I don't follow the example >> given), >> is .aqrl sufficient here? And even if it was for the 4- and 8-byte >> cases, >> is it sufficient in the 1- and 2-byte emulation case (where it then >> is >> appended to just the SC)? > If I understand your question correctly then accroding to the spec., > .aqrl is enough for amo.{w|d} instructions: > Linux Construct RVWMO AMO Mapping > atomic relaxed amo.{w|d} > atomic acquire amo.{w|d}.aq > atomic release amo.{w|d}.rl > atomic amo.{w|d}.aqrl > but in case of lr/sc you are right sc requires suffix too: > Linux Construct RVWMO LR/SC Mapping > atomic relaxed loop: lr.{w|d}; ; sc.{w|d}; bnez loop > atomic acquire loop: lr.{w|d}.aq; ; sc.{w|d}; bnez loop > atomic release loop: lr.{w|d}; ; sc.{w|d}.aqrl∗ ; bnez > loop OR fence.tso; loop: lr.{w|d}; ; sc.{w|d}∗ ; bnez loop > atomic loop: lr.{w|d}.aq; ; sc.{w|d}.aqrl; bnez > loop > > I will add sc_sfx to emulate_xchg_1_2(). The only question is left if > __xchg_generic(ptr, new, size, sfx, pre, post) should be changed to: > __xchg_generic(ptr, new, size, sfx1, sfx2, pre, post) to cover both > cases amo.{w|d}.sfx1 and lr.{w|d}.sfx1 ... sc.{w|d}.sfx2? I expect that's going to be necessary. In the end you'll see what's needed when making the code adjustment. Jan From xen-devel-bounces@lists.xenproject.org Thu Mar 07 11:01:44 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 11:01:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689763.1075028 (Exim 4.92) (envelope-from ) id 1riBVH-0005K4-8z; Thu, 07 Mar 2024 11:01:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689763.1075028; Thu, 07 Mar 2024 11:01:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riBVH-0005Jx-5y; Thu, 07 Mar 2024 11:01:35 +0000 Received: by outflank-mailman (input) for mailman id 689763; Thu, 07 Mar 2024 11:01:34 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riBVG-0005Jr-8r for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 11:01:34 +0000 Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [2a00:1450:4864:20::12b]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 0def3188-dc72-11ee-a1ee-f123f15fe8a2; Thu, 07 Mar 2024 12:01:31 +0100 (CET) Received: by mail-lf1-x12b.google.com with SMTP id 2adb3069b0e04-513173e8191so917773e87.1 for ; Thu, 07 Mar 2024 03:01:31 -0800 (PST) Received: from [192.168.206.239] ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id q7-20020ac246e7000000b005131d018bb1sm3005813lfo.94.2024.03.07.03.01.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Mar 2024 03:01:30 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 0def3188-dc72-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709809291; x=1710414091; darn=lists.xenproject.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=9qexdayklPi60il4bLQIUY4ne8AaWgndZYd8dPz8eAo=; b=fYtVW4AKC6pjNGCJyOAW1Z6C28daX5DKQeN2vsrUsingeXVKyfFAPTmze9yvNc1Xzp wnJTB7jgrs/3/kPHRZV30/neVDmJSf4/jXV2iJIX2fZLHzYW5uqyscYYDuUSk7S5EgT5 a5YAWlu/Wrh6cZ86w/JUAepHORjGtcSKOPNo8LlGcu7yhcJyheIpTZk3mdcOnrNTGqOG MUxchpJ8CP0irYgsSGZOaXD8ClRrAoc9cO5A8sp1RNHki9JNFf1JMhDj248JRbwSWc8A /MvdacsGG+NCAXI/zsF/lZ6p4/8oeJ2c1oHUW/ECr1LAcFkM1wQdjWcfhlQEzaAsxHGE HM7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709809291; x=1710414091; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=9qexdayklPi60il4bLQIUY4ne8AaWgndZYd8dPz8eAo=; b=Aamhr46JGUd77dQnPPFiaSklK3F1mgkoceGTWEBpmC4xPhnD2JhTwOW/7pU21OfFQr JRROIYYkmXnjKzN4jBFqeyA9QIQr2G/JMwjbCQj0q5oVJBuY4Gyj21mj8vJBYQEFSLzN c2/boEFNuAkWgQxHTw+eEPgdmPgFJoMLqFY0HPJnroXbxCQFCDHSOSojdo17OhEQxF1m BqI3WHIte5kMxgLdNN7ySGQMuT9mbZZCe+vpBQZTNpfIMQQixXovxt+AUtBfVBc8cp3W 4xJ1Z6oOlB2EErzjFEk+swXNzO+3lgwqguCJS2nPmdOwn/tQ7iKqlG6EGU103jYs20pR 75yw== X-Forwarded-Encrypted: i=1; AJvYcCWaZDVZqeU6g2dBOzmaxQXbACL1nn6cattqN8LvjgBYSaSYbcO12UdBeShwNKJ3OmTFiCoR2PGBihwi/E/VuSjX79wAkd1E3UTtavcvN5Y= X-Gm-Message-State: AOJu0YwPrgod5YaNJqdPvJ/ZlaSoFqkyyPIzjWEEktN4OC7eAQunJ0dC sM4B5GPhCwGdN8TmDugjLZewaNlQz0LfzXNWjJ9gi/XcQpkifnY3 X-Google-Smtp-Source: AGHT+IECBO1ilNKUUgC/aHEZgOxLDkp6mssV7hLhZ2FUq00Hsr8/OwyfBrVTjFlcTGHN++7sB/maZg== X-Received: by 2002:ac2:491e:0:b0:513:1ff9:2bb4 with SMTP id n30-20020ac2491e000000b005131ff92bb4mr1085070lfi.30.1709809290478; Thu, 07 Mar 2024 03:01:30 -0800 (PST) Message-ID: Subject: Re: [PATCH v5 11/23] xen/riscv: introduce cmpxchg.h From: Oleksii To: Jan Beulich Cc: Alistair Francis , Bob Eshleman , Connor Davis , Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu , xen-devel@lists.xenproject.org Date: Thu, 07 Mar 2024 12:01:29 +0100 In-Reply-To: References: <23ff1c20-91f3-4c60-9562-7f1cd57c1043@suse.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.50.2 (3.50.2-1.fc39) MIME-Version: 1.0 On Thu, 2024-03-07 at 11:46 +0100, Jan Beulich wrote: > On 07.03.2024 11:35, Oleksii wrote: > > On Wed, 2024-03-06 at 15:56 +0100, Jan Beulich wrote: > > > On 26.02.2024 18:38, Oleksii Kurochko wrote: > > > > The header was taken from Linux kernl 6.4.0-rc1. > > > >=20 > > > > Addionally, were updated: > > > > * add emulation of {cmp}xchg for 1/2 byte types using 32-bit > > > > atomic > > > > =C2=A0 access. > > > > * replace tabs with spaces > > > > * replace __* variale with *__ > > > > * introduce generic version of xchg_* and cmpxchg_*. > > > >=20 > > > > Implementation of 4- and 8-byte cases were left as it is done > > > > in > > > > Linux kernel as according to the RISC-V spec: > > > > ``` > > > > Table A.5 ( only part of the table was copied here ) > > > >=20 > > > > Linux Construct=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RVWMO Mapping > > > > atomic relaxed=C2=A0=C2=A0=C2=A0 amo.{w|d} > > > > atomic acquire=C2=A0=C2=A0=C2=A0 amo.{w|d}.aq > > > > atomic release=C2=A0=C2=A0=C2=A0 amo.{w|d}.rl > > > > atomic =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 amo.{w|d}.aqrl > > > >=20 > > > > Linux Construct=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RVWMO LR/SC Map= ping > > > > atomic relaxed=C2=A0=C2=A0=C2=A0 loop: lr.{w|d}; ; sc.{w|d= }; bnez > > > > loop > > > > atomic acquire=C2=A0=C2=A0=C2=A0 loop: lr.{w|d}.aq; ; sc.{= w|d}; bnez > > > > loop > > > > atomic release=C2=A0=C2=A0=C2=A0 loop: lr.{w|d}; ; sc.{w|d= }.aqrl=E2=88=97 ; > > > > bnez > > > > loop OR > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 fence.ts= o; loop: lr.{w|d}; ; > > > > sc.{w|d}=E2=88=97 ; > > > > bnez loop > > > > atomic =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 loop: lr.{w|d}.aq; ; sc.{w|d}.aqrl; > > > > bnez > > > > loop > > > >=20 > > > > The Linux mappings for release operations may seem stronger > > > > than > > > > necessary, > > > > but these mappings are needed to cover some cases in which > > > > Linux > > > > requires > > > > stronger orderings than the more intuitive mappings would > > > > provide. > > > > In particular, as of the time this text is being written, Linux > > > > is > > > > actively > > > > debating whether to require load-load, load-store, and store- > > > > store > > > > orderings > > > > between accesses in one critical section and accesses in a > > > > subsequent critical > > > > section in the same hart and protected by the same > > > > synchronization > > > > object. > > > > Not all combinations of FENCE RW,W/FENCE R,RW mappings with > > > > aq/rl > > > > mappings > > > > combine to provide such orderings. > > > > There are a few ways around this problem, including: > > > > 1. Always use FENCE RW,W/FENCE R,RW, and never use aq/rl. This > > > > suffices > > > > =C2=A0=C2=A0 but is undesirable, as it defeats the purpose of the a= q/rl > > > > modifiers. > > > > 2. Always use aq/rl, and never use FENCE RW,W/FENCE R,RW. This > > > > does > > > > not > > > > =C2=A0=C2=A0 currently work due to the lack of load and store opcod= es > > > > with aq > > > > and rl > > > > =C2=A0=C2=A0 modifiers. > > >=20 > > > As before I don't understand this point. Can you give an example > > > of > > > what > > > sort of opcode / instruction is missing? > > If I understand the spec correctly then l{b|h|w|d} and s{b|h|w|d} > > instructions don't have aq or rl annotation. >=20 > How would load insns other that LR and store insns other than SC come > into play here? This part of the spec. is not only about LR and SC which cover Load- Exclusive and Store-Exclusive cases, but also about non-Exclusive cases for each l{b|h|w|d} and s{b|h|w|d} are used. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Thu Mar 07 11:04:06 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 11:04:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689765.1075038 (Exim 4.92) (envelope-from ) id 1riBXg-0005sU-L8; Thu, 07 Mar 2024 11:04:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689765.1075038; Thu, 07 Mar 2024 11:04:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riBXg-0005sN-Ia; Thu, 07 Mar 2024 11:04:04 +0000 Received: by outflank-mailman (input) for mailman id 689765; Thu, 07 Mar 2024 11:04:04 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riBXg-0005sH-0g for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 11:04:04 +0000 Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [2a00:1450:4864:20::529]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 679a0eef-dc72-11ee-a1ee-f123f15fe8a2; Thu, 07 Mar 2024 12:04:01 +0100 (CET) Received: by mail-ed1-x529.google.com with SMTP id 4fb4d7f45d1cf-56657bcd555so832352a12.3 for ; Thu, 07 Mar 2024 03:04:01 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id v29-20020a50a45d000000b005649f17558bsm8310969edb.42.2024.03.07.03.04.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Mar 2024 03:04:01 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 679a0eef-dc72-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709809441; x=1710414241; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=Wgfiv/l/q4Cl1rIELcJuiMKkt6DFqZ7ZdPyrQjSqOg0=; b=O7CDa80hIBT449CKddpET9TSE2AbPuy088zLAYs6ZTk2NJk4dzdFPh3+ntCjCsCOKJ 0o5r2UUX20x9SG+KZKQIN3qKlU1dMoqLq6ygea90AT7uVU4wsgTHI/Re462XGTs+2VlT YHv1EFd7LXKQb8z5SgelGZKQu1s6ffPowR6NJWGJG1KHf8LxIu8xheVLgYRR73dAULt/ eqV8KbzTUmD9Bd4zuJtsoOObvwqj9LwzpghoB+xVOtwHjbSbcbuspxsXMA997BK9URRf NRuRn/WRrBwwd1idp6RlAPfN8cv2N5dkHUgYh64h3Al+6C1KWaa1lgC1mOG3YztOpcs1 Qpiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709809441; x=1710414241; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Wgfiv/l/q4Cl1rIELcJuiMKkt6DFqZ7ZdPyrQjSqOg0=; b=UxP28tI33SyWkxnivGu68DXU3VJRjAWW8qZEmbkuVcvB/rAqE7yCpe+GwlOex0A84r umWrmbetFBcq0Zakds/4KgmnCELNGwSPyGm/+U2L9/gvu4D7/bO/p/5hH1b7Y2WSaN3g ijyAK5hsRmad+gHwNsrVwVPOx+13OQUru+KwHb0lLIvs8Ts+ykfF+frVIuRJcJ66Av1O Ircd/BJlWfSUN/OEkbnFJ+LnHpAkdZTQM81Bj/tz6d9rGuaEWPGOuCOynGKjRXpBh0zt uy5o/Y5wpJ1Tb0wgfknmNMh5nFhJ/HUBNcsSVEOs9F3LFVLh724nwt/XEjnqyG8LAatb QzhA== X-Forwarded-Encrypted: i=1; AJvYcCWlo2tG0j97Uk5P7g4CscblvelYRIHDX3e0Y4T5buNcq/kcseSJgk2DI5oJmg4sJCUqQqWuWrgrnqpnjymyBvXOuCBDkaNRjxjcfvU/iM8= X-Gm-Message-State: AOJu0YyZZ+c7ydAf6gezAxQkljAiww9fF55CPKjyLVlunvIRI43t/oiN uO4G89N6A01/mSm76jP+B3p/s6ed5fh0sdtfJy/wOfEvY63yKni5zfT8xAYwfg== X-Google-Smtp-Source: AGHT+IG4DPOB1uYdKCOOEjKLmKXTAuLYXyjLK+YjR+25T9+wH/oFGebCGKN8pKcCDp7b4ORQAknc3A== X-Received: by 2002:aa7:d5c9:0:b0:567:a73f:ac79 with SMTP id d9-20020aa7d5c9000000b00567a73fac79mr4761634eds.36.1709809441374; Thu, 07 Mar 2024 03:04:01 -0800 (PST) Message-ID: <8428e980-ac88-40bb-8334-d52deeb52bb0@suse.com> Date: Thu, 7 Mar 2024 12:04:00 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] tools/9pfsd: Fix build error caused by strerror_r() Content-Language: en-US To: Henry Wang Cc: Wei Liu , Anthony PERARD , Juergen Gross , xen-devel@lists.xenproject.org References: <20240307103847.3710737-1-xin.wang2@amd.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20240307103847.3710737-1-xin.wang2@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 07.03.2024 11:38, Henry Wang wrote: > Below error can be seen when doing Yocto build of the toolstack: > > | io.c: In function 'p9_error': > | io.c:684:5: error: ignoring return value of 'strerror_r' declared > with attribute 'warn_unused_result' [-Werror=unused-result] > | 684 | strerror_r(err, ring->buffer, ring->ring_size); > | | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > | cc1: all warnings being treated as errors > > Fix the build by using strerror() to replace strerror_r(). Since > strerror() is thread-unsafe, use a separate local mutex to protect > the action. The steps would then become: Acquire the mutex first, > invoke strerror(), copy the string from strerror() to the designated > buffer and then drop the mutex. > Fixes: f4900d6d69b5 ("9pfsd: allow building with old glibc") > Signed-off-by: Henry Wang Reviewed-by: Jan Beulich albeit there are a number of cosmetic aspects I'd have done differently (see bottom of mail). The one thing I'd really like to ask for it a comment ... > --- a/tools/9pfsd/io.c > +++ b/tools/9pfsd/io.c > @@ -680,8 +680,18 @@ static bool name_ok(const char *str) > static void p9_error(struct ring *ring, uint16_t tag, uint32_t err) > { > unsigned int erroff; > + static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER; > + char *strerror_str; > + RING_IDX strerror_len = 0, copy_len = 0; > + ... here explaining why strerror_r() isn't used. Unless other comments arise and a v3 would be needed, I'd add /* * While strerror_r() exists, it comes in a POSIX and a GNU flavor. * Let's try to avoid trying to be clever with determining which * one it is that the underlying C library offers, when really we * don't expect this function to be called very often. */ while committing. Anyway it'll need a maintainer ack first. > + pthread_mutex_lock(&mutex); > + strerror_str = strerror(err); > + strerror_len = strlen(strerror_str) + 1; > + copy_len = min(strerror_len, ring->ring_size); > + memcpy(ring->buffer, strerror_str, copy_len); > + ((char *)(ring->buffer))[copy_len - 1] = '\0'; > + pthread_mutex_unlock(&mutex); > > - strerror_r(err, ring->buffer, ring->ring_size); > erroff = add_string(ring, ring->buffer, strlen(ring->buffer)); > fill_buffer(ring, P9_CMD_ERROR, tag, "SU", > erroff != ~0 ? ring->str + erroff : "cannot allocate memory", pthread_mutex_lock(&mutex); str = strerror(err); len = min(strlen(str), ring->ring_size - 1); memcpy(ring->buffer, str, len); ((char *)ring->buffer)[len] = '\0'; pthread_mutex_unlock(&mutex); Jan From xen-devel-bounces@lists.xenproject.org Thu Mar 07 11:04:08 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 11:04:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689766.1075048 (Exim 4.92) (envelope-from ) id 1riBXk-00068L-Rr; Thu, 07 Mar 2024 11:04:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689766.1075048; Thu, 07 Mar 2024 11:04:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riBXk-00068E-Ow; Thu, 07 Mar 2024 11:04:08 +0000 Received: by outflank-mailman (input) for mailman id 689766; Thu, 07 Mar 2024 11:04:07 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riBXj-0005sH-IJ for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 11:04:07 +0000 Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [2a00:1450:4864:20::334]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 69d0564c-dc72-11ee-a1ee-f123f15fe8a2; Thu, 07 Mar 2024 12:04:05 +0100 (CET) Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-41312cf36a8so1714105e9.0 for ; Thu, 07 Mar 2024 03:04:05 -0800 (PST) Received: from meli.delivery (adsl-101.37.6.0.tellas.gr. [37.6.0.101]) by smtp.gmail.com with ESMTPSA id c6-20020a05600c0a4600b00412f2136793sm2395336wmq.44.2024.03.07.03.04.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Mar 2024 03:04:04 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 69d0564c-dc72-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1709809445; x=1710414245; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:message-id:in-reply-to :references:user-agent:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to; bh=y/YHYrBcAuwAYsvgxQDkgi/+/ASQ6Z2Ja+hha7xSnoM=; b=EzVpK5W+x0ahezxLQ3I8G2ywMsv5ju/8y+QPFORfmSHDR5LWfTN0P6t/ASqRl3DdUb 2OqwoUN+soefbvxFtPd1/PftTwnk+oqUXbSBRVrBb6doYVT0wreJaWouLq62eGc79Ezj OUhsDvCwl4WlR6vBLYwzof6+DhqV8gEGJhRJqY4I/iNlm9/qLtkGs9muwh2pslLYcFwe qDFB5dHmGcdnOKpBBEPuZgx3VWfCxBlct9Af2Xu4qd4pa0+91ZZJeGZEUFMYQcxkwZND 98tZHzZJ7TGGqhAaEObgVddXO+Wnbjgc0eM9/1dWuDqkR/NaY9u9ItFkKEIzSL47Flkf dhaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709809445; x=1710414245; h=content-transfer-encoding:mime-version:message-id:in-reply-to :references:user-agent:subject:cc:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=y/YHYrBcAuwAYsvgxQDkgi/+/ASQ6Z2Ja+hha7xSnoM=; b=n34cAv25WXI5riHFmGvV29/+7wS8FoxbMusJgYzZT9ZMctf2L56Ea7Od3Y5RDDLdCi Afm2qNKmtUKtrBrdIdptKVKCqnsi+Wu0hvRogkH35dZJigDPHRu2GaF6nU6kUNOgt0uk hN5LUu1KL4gmxLtrYx5bLozW2Sf/HwO/LV9YRTD3hK8NAKHbuLNHjgCeNXmgFqx3GFy9 OEXnzhctM117D+ZFYJ/g6imwpc0lve2WH+xa1gfHVNc6RNVMOPNI4AAUmyALrlwQkU0s R2t/4Rc7yPDVRg2Uo2/qWvvl2zbdiSqDlfdpaqFl6JA/q9djH9ogz991DuZU135jUel9 ZIGw== X-Forwarded-Encrypted: i=1; AJvYcCVCL9SaLRz3z2ZELYRw1nCd1lIBnede4a+bm+BHdkbtyMcMP49F0IcFLhdcoJt0IfXxQwiK58MxHN7y/WT3Y3zq0YHbNpoyL9GvwsOk9UI= X-Gm-Message-State: AOJu0YwDUTm8qN2NawOV0AYC+YKzB0m1nWhOxB22LsQT+3vOU/GRMVe2 nYBFGUAEkRBXJMk5BQ/X0EHgaYTXrSqiwaIx+T9oa13fZ8xiOdHzaoemTTfnS/s= X-Google-Smtp-Source: AGHT+IHaAws1XqkU4NwrR+6W6/kfS49fq/4B1VyIX6VkNndanIKiC48FMk2IagcIM592qtws8DKWKA== X-Received: by 2002:a05:600c:1d03:b0:412:c7b2:5636 with SMTP id l3-20020a05600c1d0300b00412c7b25636mr13372940wms.23.1709809444882; Thu, 07 Mar 2024 03:04:04 -0800 (PST) Date: Thu, 07 Mar 2024 12:46:02 +0200 From: Manos Pitsidianakis To: Michal Orzel , xen-devel@lists.xenproject.org, Alex Benn=?UTF-8?B?w6k=?= e Cc: julien@xen.org, sstabellini@kernel.org, bertrand.marquis@arm.com Bcc: Subject: Re: [RFC PATCH v2] xen/arm: improve handling of load/store instruction decoding User-Agent: meli 0.8.5-rc.3 References: <20240306165621.3819343-1-alex.bennee@linaro.org> <3cb1b056-59a7-4ffe-856d-e45aac1936a9@amd.com> <9z3mh.tiey2z2itr9a@linaro.org> <5eaf5a24-d9b6-4045-8b90-61897464d7a2@amd.com> In-Reply-To: <5eaf5a24-d9b6-4045-8b90-61897464d7a2@amd.com> Message-ID: <9z5eq.tgi8mkv6tysq@linaro.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8; format=flowed On Thu, 07 Mar 2024 12:43, Michal Orzel wrote: > > >On 07/03/2024 11:02, Manos Pitsidianakis wrote: >> >> >> Hi Michal, Alex, >> >> I'm responding to Michel but also giving my own review comments here. >> >> On Thu, 07 Mar 2024 10:40, Michal Orzel wrote: >>> Hi Alex, >>> >>> NIT: RFC tag is no longer needed. >>> >>> On 06/03/2024 17:56, Alex Bennée wrote: >>>> >>>> >>>> While debugging VirtIO on Arm we ran into a warning due to memory >>>> being memcpy'd across MMIO space. While the bug was in the mappings >>>> the warning was a little confusing: >>>> >>>> (XEN) d47v2 Rn should not be equal to Rt except for r31 >>>> (XEN) d47v2 unhandled Arm instruction 0x3d800000 >>>> (XEN) d47v2 Unable to decode instruction >>>> >>>> The Rn == Rt warning is only applicable to single register load/stores >>>> so add some verification steps before to weed out unexpected accesses. >>>> >>>> While at it update the Arm ARM references to the latest version of the >>>> documentation. >>>> >>>> Signed-off-by: Alex Bennée >>>> Cc: Manos Pitsidianakis >>> Move the CC line after --- so that it's not included in the final commit msg. >>> >>>> >>>> --- >>>> v2 >>>> - use single line comments where applicable >>>> - update Arm ARM references >>>> - use #defines for magic numbers >>>> --- >>>> xen/arch/arm/decode.c | 35 ++++++++++++++++++++------ >>>> xen/arch/arm/decode.h | 57 ++++++++++++++++++++++++++++++++++++++----- >>>> 2 files changed, 79 insertions(+), 13 deletions(-) >>>> >>>> diff --git a/xen/arch/arm/decode.c b/xen/arch/arm/decode.c >>>> index 2537dbebc1..73a88e4701 100644 >>>> --- a/xen/arch/arm/decode.c >>>> +++ b/xen/arch/arm/decode.c >>>> @@ -87,15 +87,36 @@ static int decode_arm64(register_t pc, mmio_info_t *info) >>>> return 1; >>>> } >>>> >>>> + /* Check this is a load/store of some sort */ >>>> + if ( (opcode.top_level.op1 & TL_LDST_OP1_MASK) != TL_LDST_OP1_VALUE ) >>>> + { >>>> + gprintk(XENLOG_ERR, "Not a load/store instruction op1=%u\n", >>>> + opcode.top_level.op1); >>>> + goto bad_loadstore; >>>> + } >>>> + >>>> + /* We are only expecting single register load/stores */ >>>> + if ( (opcode.ld_st.op0 & LS_SREG_OP0_MASK) != LS_SREG_OP0_VALUE ) >>>> + { >>>> + gprintk(XENLOG_ERR, "Not single register load/store op0=%u\n", >>> NIT: missing 'a' between Not and single >>> >>>> + opcode.ld_st.op0); >>>> + goto bad_loadstore; >>>> + } >>>> + >>>> /* >>>> - * Refer Arm v8 ARM DDI 0487G.b, Page - C6-1107 >>>> - * "Shared decode for all encodings" (under ldr immediate) >>>> - * If n == t && n != 31, then the return value is implementation defined >>>> - * (can be WBSUPPRESS, UNKNOWN, UNDEFINED or NOP). Thus, we do not support >>>> - * this. This holds true for ldrb/ldrh immediate as well. >>>> + * Refer Arm v8 ARM DDI 0487J.a, Page - K1-12586 >>>> + * >>>> + * STR (immediate) CONSTRAINED UNPREDICTABLE behaviour >>>> + * >>>> + * "If the instruction encoding specifies pre-indexed addressing or >>>> + * post-indexed addressing, and n == t && n != 31, then one of the >>>> + * following behaviors must occur:" UNDEFINED, NOP or UNKNOWN >>>> + * >>>> + * Execution @ EL0/EL1 when HCR_EL2.TIDCP is 1 traps to EL2 with >>>> + * EC = 0. >>>> * >>>> - * Also refer, Page - C6-1384, the above described behaviour is same for >>>> - * str immediate. This holds true for strb/strh immediate as well >>>> + * This also hold true for LDR (immediate), Page K1-12581 and >>>> + * the RB/RH variants of both. >>>> */ >>>> if ( (opcode.ldr_str.rn == opcode.ldr_str.rt) && (opcode.ldr_str.rn != 31) ) >>>> { >>>> diff --git a/xen/arch/arm/decode.h b/xen/arch/arm/decode.h >>>> index 13db8ac968..188114a71e 100644 >>>> --- a/xen/arch/arm/decode.h >>>> +++ b/xen/arch/arm/decode.h >>>> @@ -24,17 +24,54 @@ >>>> #include >>>> >>>> /* >>>> - * Refer to the ARMv8 ARM (DDI 0487G.b), Section C4.1.4 Loads and Stores >>>> - * Page 318 specifies the following bit pattern for >>>> - * "load/store register (immediate post-indexed)". >>>> + * Refer to the ARMv8 ARM (DDI 0487J.a) >>>> * >>>> - * 31 30 29 27 26 25 23 21 20 11 9 4 0 >>>> + * Section C A64 Instruct Set Encoding >>> This line is not needed >> >> I think it is needed for context (it answers the question "what is >> C4.1?" in the following line. >> >>>> + * >>>> + * C4.1 A64 instruction set encoding: >>> NIT: I would put a comma after section number i.e. C4.1, A64 ... >>> The same would apply in other places. >> >> Style manuals use either space (like here), a period (.) or colon (:), >> never a comma. >Since it's a NIT, I'm not going to object. I just care about readability, we do not >need to adhere to any "style manuals". I agree about readability :) the manuals mention was not an appeal to authority, just a sign of what is more common out there hence readable for more people. It is a nitpicking and subjective of course, so I'm not arguing for/against it, just sharing my 2 cents. > >> >>> >>>> + * >>>> + * 31 30 29 28 25 24 0 >>>> * ___________________________________________________________________ >>>> - * |size|1 1 1 |V |0 0 |opc |0 | imm9 |0 1 | Rn | Rt | >>>> - * |____|______|__|____|____|__|_______________|____|_________|_______| >>>> + * |op0 | x x | op1 | | >>>> + * |____|______|______|_______________________________________________| >>>> + * >>>> + * op0 = 0 is reserved >>> I'm not sure how to read it. It is reserved provided op1 is also 0. >> >> Yes, it should say something like: >> >>> Decode field values op0 = 0, op1 = 0 are reserved. >>> Values op0 = 1, op1 = x1x0 correspond to Loads and Stores >> >>>> + * op1 = x1x0 for Loads and Stores >>>> + * >>>> + * Section C4.1.88 Loads and Stores >>> Missing colon at the end? >> >> It's a heading so a colon would not be appropriate. >In this case why was it added before in: >"C4.1 A64 instruction set encoding:" It should be removed from that, good point. Or at least put a colon here and in all headers for consistency. > >> >>> >>>> + * >>>> + * 31 28 27 26 25 24 23 22 21 16 15 12 11 10 9 0 >>>> + * ___________________________________________________________________ >>>> + * | op0 | 1 | op1 | 0 | op2 | | op3 | | op4 | | >>>> + * |________|___|_____|___|_____|__|__________|______|_____|__________| >>>> + * >> >> Maybe we should add the op{0,1,2,3,4} values for consistency? >> >>> Values op0=xx11, op1=0, op2=0x, op3=0xxxxx, op4=01 correspond to >>> Load/store register (immediate post-indexed) >I think this should stay neutral in case we add a new emulation in a future. Do you mean for future Arm versions? decode.{c,h} should definitely be more future-proof... I think it's okay in this case only because the comment block starts with the source's name "ARMv8 ARM (DDI 0487J.a)". I don't object however to what you're saying, either is fine for me! > >> >>>> + * Page C4-653 Load/store register (immediate post-indexed) >>>> + * >>>> + * 31 30 29 27 26 25 24 23 22 21 20 12 11 10 9 5 4 0 >>>> + * ___________________________________________________________________ >>>> + * |size|1 1 1 |V | 0 0 | opc |0 | imm9 | 0 1 | Rn | Rt | >>>> + * |____|______|__|_____|_____|__|_______________|_____|______|_______| >>>> */ >>>> union instr { >>>> uint32_t value; >>>> + struct { >>>> + unsigned int ign2:25; >>> Here, your numeration of ignore fields is in descending order (starting from lsb) but .., >>> >>>> + unsigned int op1:4; /* instruction class */ >>>> + unsigned int ign1:2; >>>> + unsigned int op0:1; /* value = 1b */ >>> Why op0 = 0b1 ? This structure represents the generic bit layout (the emulation deals with single ldr/str). >>> I would drop this comment. >> >> It is a reserved bit which can never be 0. >Where did you take this information from? >As I wrote above, I don't think we should bind this union to a single >use case we currently have. >The struct top_level should represent the generic encoding of A64 instruction. C4.1, page C4-400. op0 is only zero in the reserved (unallocated) case, for the generic encoding. > >~Michal From xen-devel-bounces@lists.xenproject.org Thu Mar 07 11:11:10 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 11:11:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689772.1075057 (Exim 4.92) (envelope-from ) id 1riBeT-0000AS-Hc; Thu, 07 Mar 2024 11:11:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689772.1075057; Thu, 07 Mar 2024 11:11:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riBeT-0000AL-F0; Thu, 07 Mar 2024 11:11:05 +0000 Received: by outflank-mailman (input) for mailman id 689772; Thu, 07 Mar 2024 11:11:04 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riBeS-0000AF-6V for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 11:11:04 +0000 Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [2a00:1450:4864:20::631]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 62c34146-dc73-11ee-afda-a90da7624cb6; Thu, 07 Mar 2024 12:11:03 +0100 (CET) Received: by mail-ej1-x631.google.com with SMTP id a640c23a62f3a-a44e3176120so109193366b.1 for ; Thu, 07 Mar 2024 03:11:03 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id lf12-20020a170906ae4c00b00a3f27031d7bsm8043800ejb.104.2024.03.07.03.11.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Mar 2024 03:11:02 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 62c34146-dc73-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709809863; x=1710414663; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=71RSYLN/uz8qSBo9Kp7W+3dnHLjJGaoFokT6rdz7n5I=; b=QawMHwTrKwh6rTvcl8EaeaoZpgPSGH90emaNgMgASByC6bsi7daGDS/TIGRo8uWG4B BEltUQbNj9uFQNxETzfSGXUEDRe/WfYujhDyLfC94X39H/3hDYTGyS2qP/uYTuZf0zwo TXM2Cq2/cKjCZ7TCioHUGBt5rME9nkuzM6ax0LtgZ2ayeqYDpxwSkhOX0QXQ071N1K/V 8pDVO/DaWZS5VN35BykT8UiWGhiZSa+c6/BNXwnchL5JYivZIFOOp/cacsBidU0HfTDE DGS9ZxDmpZFy7RFWNP4+IMBEey/wev8QaJzakgL0lHy8mMY5gMXTkTs1H/EK7d5fgEw5 4WBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709809863; x=1710414663; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=71RSYLN/uz8qSBo9Kp7W+3dnHLjJGaoFokT6rdz7n5I=; b=lQqQiXzkcflV4EoqZ0gO5Y4gO4rvK4MUGcqjB++Doi4wVH2bqaHEnLJZmqVihFhQ65 6NTTmRuB4Z37GlbQ47wh9gwQAtNvrzMEuQSyaH7Dfk4wtwRMbMdDUmre/jbJ+EPWO1TK dTQ/VyZpdGrgfdOtV1ZrTStGdikSidYTVbUE4qtrHKym0SbvZznoO8ZnCwJ820TiXYOV gz6knwyYc9qhWI2oEEsZnA2uGpAzoYM+35G2NJrKb1G5Z+MLATx6p9k2IGf/FNUqbVpg pnurbgBIJPDrUg54J0Dw1RMMsNFQcaZvImoEk/b5G8+onWptsbK5aCs6Q7V/bej3XGfB JpLw== X-Forwarded-Encrypted: i=1; AJvYcCWm3uqBIgEAmNRtBG51jQ2+tkAHfAWmg9hKXm5n45gIYYWJXcjrbn2gBPRPdnmJc9BpAX5c7h07CDO0rSJ3yMaAFLGSexQsCPmy2j6hHLU= X-Gm-Message-State: AOJu0Yxs6lOo5rPMsZug3n/JYVAP+pTvMS6NO3Ye7ALsY3r8/K4QGsIn bQiUFfyP1rE4z67avyQmrZRVhs/OOWHWP8/lutvQPq1fOL2a11YR7mzJ2I2JVg== X-Google-Smtp-Source: AGHT+IGc3YZK783YKajrmC3jm/u8JX2JHCTGRbhD7F9PPtvGG9IKrfNCO0cSygh8el9/MOXqQjry3A== X-Received: by 2002:a17:906:d9d9:b0:a44:eab2:a57 with SMTP id qk25-20020a170906d9d900b00a44eab20a57mr10489727ejb.45.1709809862548; Thu, 07 Mar 2024 03:11:02 -0800 (PST) Message-ID: <8ef64462-d810-4be1-923f-973de340cda2@suse.com> Date: Thu, 7 Mar 2024 12:11:00 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 11/23] xen/riscv: introduce cmpxchg.h To: Oleksii Cc: Alistair Francis , Bob Eshleman , Connor Davis , Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu , xen-devel@lists.xenproject.org References: <23ff1c20-91f3-4c60-9562-7f1cd57c1043@suse.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 07.03.2024 12:01, Oleksii wrote: > On Thu, 2024-03-07 at 11:46 +0100, Jan Beulich wrote: >> On 07.03.2024 11:35, Oleksii wrote: >>> On Wed, 2024-03-06 at 15:56 +0100, Jan Beulich wrote: >>>> On 26.02.2024 18:38, Oleksii Kurochko wrote: >>>>> The header was taken from Linux kernl 6.4.0-rc1. >>>>> >>>>> Addionally, were updated: >>>>> * add emulation of {cmp}xchg for 1/2 byte types using 32-bit >>>>> atomic >>>>>   access. >>>>> * replace tabs with spaces >>>>> * replace __* variale with *__ >>>>> * introduce generic version of xchg_* and cmpxchg_*. >>>>> >>>>> Implementation of 4- and 8-byte cases were left as it is done >>>>> in >>>>> Linux kernel as according to the RISC-V spec: >>>>> ``` >>>>> Table A.5 ( only part of the table was copied here ) >>>>> >>>>> Linux Construct       RVWMO Mapping >>>>> atomic relaxed    amo.{w|d} >>>>> atomic acquire    amo.{w|d}.aq >>>>> atomic release    amo.{w|d}.rl >>>>> atomic             amo.{w|d}.aqrl >>>>> >>>>> Linux Construct       RVWMO LR/SC Mapping >>>>> atomic relaxed    loop: lr.{w|d}; ; sc.{w|d}; bnez >>>>> loop >>>>> atomic acquire    loop: lr.{w|d}.aq; ; sc.{w|d}; bnez >>>>> loop >>>>> atomic release    loop: lr.{w|d}; ; sc.{w|d}.aqrl∗ ; >>>>> bnez >>>>> loop OR >>>>>                        fence.tso; loop: lr.{w|d}; ; >>>>> sc.{w|d}∗ ; >>>>> bnez loop >>>>> atomic             loop: lr.{w|d}.aq; ; sc.{w|d}.aqrl; >>>>> bnez >>>>> loop Note the load and store forms mentioned here. How would ... >>>>> The Linux mappings for release operations may seem stronger >>>>> than >>>>> necessary, >>>>> but these mappings are needed to cover some cases in which >>>>> Linux >>>>> requires >>>>> stronger orderings than the more intuitive mappings would >>>>> provide. >>>>> In particular, as of the time this text is being written, Linux >>>>> is >>>>> actively >>>>> debating whether to require load-load, load-store, and store- >>>>> store >>>>> orderings >>>>> between accesses in one critical section and accesses in a >>>>> subsequent critical >>>>> section in the same hart and protected by the same >>>>> synchronization >>>>> object. >>>>> Not all combinations of FENCE RW,W/FENCE R,RW mappings with >>>>> aq/rl >>>>> mappings >>>>> combine to provide such orderings. >>>>> There are a few ways around this problem, including: >>>>> 1. Always use FENCE RW,W/FENCE R,RW, and never use aq/rl. This >>>>> suffices >>>>>    but is undesirable, as it defeats the purpose of the aq/rl >>>>> modifiers. >>>>> 2. Always use aq/rl, and never use FENCE RW,W/FENCE R,RW. This >>>>> does >>>>> not >>>>>    currently work due to the lack of load and store opcodes >>>>> with aq >>>>> and rl >>>>>    modifiers. >>>> >>>> As before I don't understand this point. Can you give an example >>>> of >>>> what >>>> sort of opcode / instruction is missing? >>> If I understand the spec correctly then l{b|h|w|d} and s{b|h|w|d} >>> instructions don't have aq or rl annotation. >> >> How would load insns other that LR and store insns other than SC come >> into play here? > > This part of the spec. is not only about LR and SC which cover Load- > Exclusive and Store-Exclusive cases, but also about non-Exclusive cases > for each l{b|h|w|d} and s{b|h|w|d} are used. ... the spec (obviously covering other forms, too) be relevant when reasoning whether just suffixes or actual barrier insns need using? Jan From xen-devel-bounces@lists.xenproject.org Thu Mar 07 11:29:58 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 11:29:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689780.1075068 (Exim 4.92) (envelope-from ) id 1riBwe-0002uH-2W; Thu, 07 Mar 2024 11:29:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689780.1075068; Thu, 07 Mar 2024 11:29:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riBwd-0002uA-WA; Thu, 07 Mar 2024 11:29:51 +0000 Received: by outflank-mailman (input) for mailman id 689780; Thu, 07 Mar 2024 11:29:50 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riBwc-0002u0-F4; Thu, 07 Mar 2024 11:29:50 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riBwc-0003bt-Ca; Thu, 07 Mar 2024 11:29:50 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riBwc-0001SD-4k; Thu, 07 Mar 2024 11:29:50 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1riBwc-0008B3-4M; Thu, 07 Mar 2024 11:29:50 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=L9eeakj+ND6lQ9ta7pqR1UXhHlGefFQ7UFY63FycLE0=; b=ZqfyDMZUVtNwmXlzhyxt/eVQob q9NztEEwsvrNa7Mk4NbrgZgQQ0e6Yw6C6Xd8d5Ts5lzngewyNKVy7t40yms6hULw11STCVCUI/GYL JbfUUjE6qcW5jR7OTuX3MHzD89WcIhMbgpxP49ixSyiKbiSMFBeRACu2DrsRXWmZi8dE=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 184930: tolerable all pass - PUSHED X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=08bb338f09a54d3b39f0d952bbd67461d8e5d0ed X-Osstest-Versions-That: xen=66c8e9b76c61ff52cfc0b186a38208907845d093 From: osstest service owner Date: Thu, 07 Mar 2024 11:29:50 +0000 flight 184930 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/184930/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass version targeted for testing: xen 08bb338f09a54d3b39f0d952bbd67461d8e5d0ed baseline version: xen 66c8e9b76c61ff52cfc0b186a38208907845d093 Last test of basis 184920 2024-03-06 14:00:24 Z 0 days Testing same since 184930 2024-03-07 09:02:12 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Jan Beulich Juergen Gross Oleksii Kurochko 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-amd64 pass 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 66c8e9b76c..08bb338f09 08bb338f09a54d3b39f0d952bbd67461d8e5d0ed -> smoke From xen-devel-bounces@lists.xenproject.org Thu Mar 07 11:31:27 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 11:31:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689784.1075077 (Exim 4.92) (envelope-from ) id 1riBy9-0004Nq-Da; Thu, 07 Mar 2024 11:31:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689784.1075077; Thu, 07 Mar 2024 11:31:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riBy9-0004Nj-Al; Thu, 07 Mar 2024 11:31:25 +0000 Received: by outflank-mailman (input) for mailman id 689784; Thu, 07 Mar 2024 11:31:23 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riBy7-0004Nd-Pw for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 11:31:23 +0000 Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [2607:f8b0:4864:20::829]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 394e3abd-dc76-11ee-afda-a90da7624cb6; Thu, 07 Mar 2024 12:31:22 +0100 (CET) Received: by mail-qt1-x829.google.com with SMTP id d75a77b69052e-42f111283a6so3592031cf.3 for ; Thu, 07 Mar 2024 03:31:22 -0800 (PST) Received: from [10.80.67.149] (default-46-102-197-194.interdsl.co.uk. [46.102.197.194]) by smtp.gmail.com with ESMTPSA id o15-20020a05622a138f00b0042f176214fasm965633qtk.20.2024.03.07.03.31.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Mar 2024 03:31:20 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 394e3abd-dc76-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709811081; x=1710415881; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=gyNI05QeRLDuCft6Q0TMVa1za849GYTYdr1mWG2TE1c=; b=ntCYNutsOhgAMXZXQ/wmuUXsn4XhTOekDsUkZXXRl5x7504zHiqjitzqnDpqmQnilj TsTawj/Q51C0pWlsrUxGuGhCNc7jQ5jk/q7iAdd/d25Mf7mucL8XUAVzwMnA6xbXPXHw 4z28HM3l+OQfeGhr6uaDHmh6+MuX9gLxuTcjc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709811081; x=1710415881; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=gyNI05QeRLDuCft6Q0TMVa1za849GYTYdr1mWG2TE1c=; b=iAZT/5e/YfPHj3pHcqQ/DMEMlIFO4M4HH5fYqf7hEZD0ypaQkRAjJy8vqxKdAHGE+N mm/ATCul1kUxsxDF+7wugCXsGV9S48L1zLngRyxj15ycrETrKOPkTfG71jFs2ZLQcm6x g3sCTICES2iyLo6tK+U/Szj0x67rd20haQ4M5OCGS4N+Z3ULsvkwHoT+g5IGT+fyP3OM 0one3a5/JMLRiQoXEaTG/CUC2r+3DSMnJg5o2/1NZxNURpTMzCxS0c0AYQ+Cj37j2I54 OarPs9+shn88CK78C5U1hZ1hrCwFSUvsd91+4IN2PSBYUbdCOyNUglLZaw/e1ZlZZgXJ HDjw== X-Forwarded-Encrypted: i=1; AJvYcCXPJ2qnq3rxaGGF3ck4SsWPyzTFdjOKRxuUB7Hp7za3yi7lA74Ia+CImMdt692K+c9uQdriam84sV1SD8VZKw8yYBns7w86b014EuYpTOA= X-Gm-Message-State: AOJu0YzZi1Z0cu9utoMTMwZTWN5hs1gZVAP66c5//n1I0xfZ1BY1aEqL vb4BCmZOTPC41uDB8gxymN0adH8STOSF68crmRhKRCMR0YrA8gfMChWJgR1mpI4= X-Google-Smtp-Source: AGHT+IGtYy0wFJpKttynUChdkllZlPhsSAhmKnV1SNJVpAwgdECLP6mUVBoF1nPPzX1fH0+L7K4fjw== X-Received: by 2002:a05:622a:1743:b0:42e:ec81:73ca with SMTP id l3-20020a05622a174300b0042eec8173camr8162498qtk.67.1709811081554; Thu, 07 Mar 2024 03:31:21 -0800 (PST) Message-ID: <9e827057-9306-4a2a-8816-410661bf8892@citrix.com> Date: Thu, 7 Mar 2024 11:31:18 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/3] xen/virtual-region: Include rodata pointers Content-Language: en-GB To: Jan Beulich Cc: Konrad Rzeszutek Wilk , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel , Ross Lagerwall References: <20240305121121.3527944-1-andrew.cooper3@citrix.com> <20240305121121.3527944-3-andrew.cooper3@citrix.com> <87b82706-f538-4807-abaf-1e59cebd286b@suse.com> <82126c3a-0cde-452f-86aa-2571482f42aa@citrix.com> <76ce9dcf-8cac-44b3-9550-f516024bad6e@suse.com> From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <76ce9dcf-8cac-44b3-9550-f516024bad6e@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 07/03/2024 7:39 am, Jan Beulich wrote: > On 06.03.2024 18:21, Andrew Cooper wrote: >> On 06/03/2024 5:09 pm, Ross Lagerwall wrote: >>> On Tue, Mar 5, 2024 at 2:17 PM Jan Beulich wrote: >>>> On 05.03.2024 13:11, Andrew Cooper wrote: >>>>> --- a/xen/include/xen/virtual_region.h >>>>> +++ b/xen/include/xen/virtual_region.h >>>>> @@ -16,6 +16,9 @@ struct virtual_region >>>>> const void *text_start; /* .text virtual address start. */ >>>>> const void *text_end; /* .text virtual address end. */ >>>>> >>>>> + const void *rodata_start; /* .rodata virtual address start (optional). */ >>>>> + const void *rodata_end; /* .rodata virtual address end. */ >>>>> + >>>>> /* If this is NULL the default lookup mechanism is used. */ >>>>> symbols_lookup_t *symbols_lookup; >>>> While perhaps the least bad one can do without quite a bit more churn, >>>> I'm still irritated by a virtual region (singular) suddenly covering >>>> two ranges of VA space. At the very least I think the description should >>>> say a word of justification in this regard. An alternative, after all, >>>> could have been for livepatch code to register separate regions for >>>> rodata (if present in a patch). >>>> >>>> A follow-on question then would be why ordinary data isn't reflected in >>>> a virtual region. Aiui that's just because livepatch presently has no >>>> need for it. >>>> >>>> Underlying question to both: Is the virtual region concept indeed meant >>>> to be fully tied to livepatch and its needs? >>>> >>> Virtual regions were introduced for live patching but I don't think it >>> is completely tied to live patching. It was introduced so that any code >>> can participate in symbol lookup, bug frame and exception table entry >>> search, rather than special casing "if livepatch" in many places. >>> >>> I agree that the virtual region concept is being abused here - it's just >>> being used as a convenient place to store rodata start/end and doesn't >>> really have much to do with the text start & end / bug frame / exception >>> table entry search that the virtual region is intended for. >>> >>> Maybe Andrew can explain why he used this approach? >> I feel the simplicity and obviousness of patch 3 speaks for itself. >> >> How do you propose fixing it differently. > I'm not opposed to doing it the way you do, but I think it then needs > clarifying (up front) what a virtual region really is. It looks to be > morphing into a module description instead ... One easy option might > be to have a comment next to the struct additions here making clear > that this is rather an abuse, but chosen to be this way to keep things > simple elsewhere. The thing called virtual_region already describes 6 ranges, and I'm adding a 7th. It has been a module-ish description right from the very outset.  I don't think it is fair to describe this as an abuse at all. Is this going to satisfy the outstanding concerns? diff --git a/xen/include/xen/virtual_region.h b/xen/include/xen/virtual_region.h index d05362071135..9d150beb8a87 100644 --- a/xen/include/xen/virtual_region.h +++ b/xen/include/xen/virtual_region.h @@ -9,6 +9,12 @@  #include  #include   +/* + * Despite it's name, this is module(ish) description. + * + * There's one region for .text/etc, one region for .init during boot only, + * and one region per livepatch. + */  struct virtual_region  {      struct list_head list; ~Andrew From xen-devel-bounces@lists.xenproject.org Thu Mar 07 11:46:32 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 11:46:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689796.1075092 (Exim 4.92) (envelope-from ) id 1riCCZ-0007dS-N0; Thu, 07 Mar 2024 11:46:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689796.1075092; Thu, 07 Mar 2024 11:46:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riCCZ-0007dL-KW; Thu, 07 Mar 2024 11:46:19 +0000 Received: by outflank-mailman (input) for mailman id 689796; Thu, 07 Mar 2024 11:46:18 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riCCY-0007dF-8M for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 11:46:18 +0000 Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [2a00:1450:4864:20::134]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 4ec6e88e-dc78-11ee-afda-a90da7624cb6; Thu, 07 Mar 2024 12:46:17 +0100 (CET) Received: by mail-lf1-x134.google.com with SMTP id 2adb3069b0e04-513382f40e9so949391e87.2 for ; Thu, 07 Mar 2024 03:46:17 -0800 (PST) Received: from meli.delivery (adsl-101.37.6.0.tellas.gr. [37.6.0.101]) by smtp.gmail.com with ESMTPSA id j33-20020a05600c1c2100b00413101235b0sm1951412wms.2.2024.03.07.03.46.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Mar 2024 03:46:16 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 4ec6e88e-dc78-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1709811977; x=1710416777; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:message-id:in-reply-to :references:user-agent:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to; bh=3FEKikgmbE/r5zzOA+k0Nr1gqI/iXTequF89jFi37Kw=; b=aVtLvOu7VA9sAxkO4mUUjig5X7a3JGUOy58c33x+ZtQY8e1fV60AbWYS0+3uSqLw9H TsMPJbTWEDaStl5f2sHybCn3xEll/kY6HCIPURk+9+uXc/50PXPTPnC5M6slTvnz3v5J VmfNZn5lEldi59AI3YN/hO11dj6CYF67YYCplNeDl8qKpX3ewkF5fnmKCgWnhACpZWZh nItauKP2Mbmp3EvuRj+xj4iEiufALqzRw2Iu57x2Q/lJiNInQ6C+5QHzAIwTymri9f8v FGLmv40NlqJhMnIeIUEhfHyyrGOz0YZSKc1HNSh1Nme1UHzezZsmH5yESY9S2mtPXZWd SUUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709811977; x=1710416777; h=content-transfer-encoding:mime-version:message-id:in-reply-to :references:user-agent:subject:cc:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=3FEKikgmbE/r5zzOA+k0Nr1gqI/iXTequF89jFi37Kw=; b=FFlFK6Kmvj8BGkWdwX6C9NrtuOKfcsGuwXTxiapeqzpqjokLqZKy/OgUFuM04Fc3kh nmkQMs4lvzcD58Es2JbuZFTUWvb4KwYvVS7xac53lt48RXW2i1yeLdHnCPi3iYZ4bvhR svRDoRi1jZY6UFoVXZXNepxdfRPV3toMSCvcbLwq8rLLoywHrO2ig6ym38hR9ERWbXks auym4fgdK6TTgVGdu+/CAHqoBdcluiYQIDw5BHnrY9jNvblormXW6XQF9G4ODqbk7qht NQEkflHBKQ3NC7MQG5YjiAz4K2LkLBPWWhVzaYIU+4bTUElvW+mt/6LP0R5wJnpjl10M BZBQ== X-Forwarded-Encrypted: i=1; AJvYcCXXlY5i3k/cPvJ9CuMqLyHK55V8V+3PYRlXbrcPqhoxywVmkXc8xbEyV55EWBDgO26cMrSrF4J904IeUOhwbbHjyr4S5O/wukGN+i3ptz8= X-Gm-Message-State: AOJu0Ywz4htyXNlcwzj6jQhUMraYMAp7CmFkKTLNttXbBf3NSNnbFJPO iZ8Bp2szKlgjMCzo7dwYGurV/Rerwjix8MlXKiA6nPaqQFrki1klFgVnW6EHRFs= X-Google-Smtp-Source: AGHT+IFH3wkwuGOA+F/yj5AIdWusXZJacoA67XWG5i8L99raCDY6RqXWR5e9a7fc4f3xfADZKnZc2w== X-Received: by 2002:ac2:5223:0:b0:513:4777:f8c9 with SMTP id i3-20020ac25223000000b005134777f8c9mr1204156lfl.6.1709811976634; Thu, 07 Mar 2024 03:46:16 -0800 (PST) Date: Thu, 07 Mar 2024 13:43:50 +0200 From: Manos Pitsidianakis To: qemu-devel@nongnu.org, Philippe Mathieu-Daud=?UTF-8?B?w6kg?= Cc: Anthony Perard , Paul Durrant , David Woodhouse , Thomas Huth , qemu-arm@nongnu.org, Stefano Stabellini , Paolo Bonzini , Alex Benn=?UTF-8?B?w6k=?= e , xen-devel@lists.xenproject.org, Philippe Mathieu-Daud=?UTF-8?B?w6kg?=, Richard Henderson , Eduardo Habkost , "Michael S. Tsirkin" , Marcel Apfelbaum Bcc: Subject: Re: [PATCH-for-9.0 1/9] hw/xen/hvm: Inline TARGET_PAGE_ALIGN() macro User-Agent: meli 0.8.5-rc.3 References: <20231114163123.74888-1-philmd@linaro.org> <20231114163123.74888-2-philmd@linaro.org> In-Reply-To: <20231114163123.74888-2-philmd@linaro.org> Message-ID: <9z7d2.v9odatywozfr@linaro.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8; format=flowed On Tue, 14 Nov 2023 18:31, Philippe Mathieu-Daudé wrote: >Use TARGET_PAGE_SIZE to calculate TARGET_PAGE_ALIGN. > >Signed-off-by: Philippe Mathieu-Daudé >--- > hw/i386/xen/xen-hvm.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c >index f1c30d1384..8aa6a1ec3b 100644 >--- a/hw/i386/xen/xen-hvm.c >+++ b/hw/i386/xen/xen-hvm.c >@@ -678,7 +678,7 @@ void xen_arch_set_memory(XenIOState *state, MemoryRegionSection *section, > trace_xen_client_set_memory(start_addr, size, log_dirty); > > start_addr &= TARGET_PAGE_MASK; >- size = TARGET_PAGE_ALIGN(size); >+ size = ROUND_UP(size, TARGET_PAGE_SIZE); > > if (add) { > if (!memory_region_is_rom(section->mr)) { >-- >2.41.0 > > Reviewed-by: Manos Pitsidianakis From xen-devel-bounces@lists.xenproject.org Thu Mar 07 11:49:02 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 11:49:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689798.1075102 (Exim 4.92) (envelope-from ) id 1riCFB-0008Bc-38; Thu, 07 Mar 2024 11:49:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689798.1075102; Thu, 07 Mar 2024 11:49:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riCFB-0008BV-0Z; Thu, 07 Mar 2024 11:49:01 +0000 Received: by outflank-mailman (input) for mailman id 689798; Thu, 07 Mar 2024 11:49:00 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riCFA-0008BP-7v for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 11:49:00 +0000 Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [2a00:1450:4864:20::332]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id af59e324-dc78-11ee-afda-a90da7624cb6; Thu, 07 Mar 2024 12:48:59 +0100 (CET) Received: by mail-wm1-x332.google.com with SMTP id 5b1f17b1804b1-4130ff11782so4275125e9.2 for ; Thu, 07 Mar 2024 03:48:59 -0800 (PST) Received: from meli.delivery (adsl-101.109.242.224.tellas.gr. [109.242.224.101]) by smtp.gmail.com with ESMTPSA id fa18-20020a05600c519200b004130c1dc29csm2432000wmb.22.2024.03.07.03.48.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Mar 2024 03:48:58 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: af59e324-dc78-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1709812139; x=1710416939; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:message-id:in-reply-to :references:user-agent:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to; bh=G/SbbEMUCs/VycRuaZQyQX/2EumGC/JTHxyB6vdSb1o=; b=yhOxkDFtz2bS9KDAlk96rVv42aoydj1uATX3GQtJBMfQAHRWZhA/4nbeF/8KAx/yZN nfEanmp0mC+tRt9dcjqhdCvza8Os687AMHPSzisDuEh0Eq9fUXQSAaNoFAJz8NJ0VvR6 3qL5xKZ0xMnMLNzd9iqkTZ6QKK4r66rwo5galGh+7VIMEkVWQ3PvtXgH/OVV2SkLm3hG 4AHXwgG50/T9nfu2YQKaqayXDVoIxGlxKKTJiNXk+qLSsidEXf7LVRWSpg3H7IkJIejj Ch/G1uV/K6bJnypDIgBEQiiDhaSEpaqD4HVaeArcK6BPjEF/0SfX45FSeomTCG2ILxwZ KhcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709812139; x=1710416939; h=content-transfer-encoding:mime-version:message-id:in-reply-to :references:user-agent:subject:cc:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=G/SbbEMUCs/VycRuaZQyQX/2EumGC/JTHxyB6vdSb1o=; b=PhXhuX7tcoxd4hkDEVT2THkCemByP9+5cdCVpUZAbDftM2CUhfEe8ftSYG1IEDbTEK sNhc/0Tad8ET0KDR2n0hltZ4qdnrcF6cR8Stv35n3JnQkdUpB0xXA2k/oiKEu008QJ/F e3jXmYYOs/qPDVtVNH1cASXCUI/ngVVX3Ll6QJF5bs95mV+1Ioq+ZtjsdGgfCZ4NymoK GJiZdAy+nNb7AA4TQGZh73gHuKp2s7/Kx9esoqwcc6QQ4/Qvwn5bQCiMBxOaxgTuCjZg Ra35X4/kTVKQdMe9HoONH8tbjiSM277f5Q5rrg0BRyJKOyg/QXMdKV88ma1Ktv+Coplf 9ujg== X-Forwarded-Encrypted: i=1; AJvYcCVUWoVdSq147m8veFbiXe2SMH2t331AmQ8737cOOgaMgQjPGh2tGaPY90Q9hXP3EAfwOKO4lgxqD5opsL+sAX7xBZzzFnDWBXsdkOwk12w= X-Gm-Message-State: AOJu0YyFrhUE3Pto41nZAf4T7ORc3RTnkGHecqTb5pquyp5eHdHiFOBN FbXH+5oKtL+1qfT1H/cblV55zj//GPmmUqoPXE8CP5juJNKyIpKz8E9IfDX2O/8= X-Google-Smtp-Source: AGHT+IGkmoMw3a1DPayc7QnWHr4dDS3sIBh8SO1Tg4XHtfrHtXIYWWCQjxeTzAsb6sqGUSlj3ULtUw== X-Received: by 2002:a05:600c:3c86:b0:412:8d98:78a with SMTP id bg6-20020a05600c3c8600b004128d98078amr14629463wmb.13.1709812138686; Thu, 07 Mar 2024 03:48:58 -0800 (PST) Date: Thu, 07 Mar 2024 13:46:27 +0200 From: Manos Pitsidianakis To: qemu-arm@nongnu.org, Philippe Mathieu-Daud=?UTF-8?B?w6kg?=, qemu-devel@nongnu.org Cc: Anthony Perard , Paul Durrant , David Woodhouse , Thomas Huth , qemu-arm@nongnu.org, Stefano Stabellini , Paolo Bonzini , Alex Benn=?UTF-8?B?w6k=?= e , xen-devel@lists.xenproject.org, Philippe Mathieu-Daud=?UTF-8?B?w6kg?=, "Michael S. Tsirkin" , Marcel Apfelbaum , Richard Henderson , Eduardo Habkost Bcc: Subject: Re: [PATCH-for-9.0 2/9] hw/xen/hvm: Propagate page_mask to a pair of functions User-Agent: meli 0.8.5-rc.3 References: <20231114163123.74888-1-philmd@linaro.org> <20231114163123.74888-3-philmd@linaro.org> In-Reply-To: <20231114163123.74888-3-philmd@linaro.org> Message-ID: <9z7hk.qddjfbvts5k7@linaro.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8; format=flowed On Tue, 14 Nov 2023 18:31, Philippe Mathieu-Daudé wrote: >We are going to replace TARGET_PAGE_MASK by a >runtime variable. In order to reduce code duplication, >propagate TARGET_PAGE_MASK to get_physmapping() and >xen_phys_offset_to_gaddr(). > >Signed-off-by: Philippe Mathieu-Daudé >--- > hw/i386/xen/xen-hvm.c | 18 ++++++++++-------- > 1 file changed, 10 insertions(+), 8 deletions(-) > >diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c >index 8aa6a1ec3b..3b10425986 100644 >--- a/hw/i386/xen/xen-hvm.c >+++ b/hw/i386/xen/xen-hvm.c >@@ -174,11 +174,12 @@ static void xen_ram_init(PCMachineState *pcms, > } > } > >-static XenPhysmap *get_physmapping(hwaddr start_addr, ram_addr_t size) >+static XenPhysmap *get_physmapping(hwaddr start_addr, ram_addr_t size, >+ int page_mask) > { > XenPhysmap *physmap = NULL; > >- start_addr &= TARGET_PAGE_MASK; >+ start_addr &= page_mask; > > QLIST_FOREACH(physmap, &xen_physmap, list) { > if (range_covers_byte(physmap->start_addr, physmap->size, start_addr)) { >@@ -188,9 +189,10 @@ static XenPhysmap *get_physmapping(hwaddr start_addr, ram_addr_t size) > return NULL; > } > >-static hwaddr xen_phys_offset_to_gaddr(hwaddr phys_offset, ram_addr_t size) >+static hwaddr xen_phys_offset_to_gaddr(hwaddr phys_offset, ram_addr_t size, >+ int page_mask) > { >- hwaddr addr = phys_offset & TARGET_PAGE_MASK; >+ hwaddr addr = phys_offset & page_mask; > XenPhysmap *physmap = NULL; > > QLIST_FOREACH(physmap, &xen_physmap, list) { >@@ -252,7 +254,7 @@ static int xen_add_to_physmap(XenIOState *state, > hwaddr phys_offset = memory_region_get_ram_addr(mr); > const char *mr_name; > >- if (get_physmapping(start_addr, size)) { >+ if (get_physmapping(start_addr, size, TARGET_PAGE_MASK)) { > return 0; > } > if (size <= 0) { >@@ -325,7 +327,7 @@ static int xen_remove_from_physmap(XenIOState *state, > XenPhysmap *physmap = NULL; > hwaddr phys_offset = 0; > >- physmap = get_physmapping(start_addr, size); >+ physmap = get_physmapping(start_addr, size, TARGET_PAGE_MASK); > if (physmap == NULL) { > return -1; > } >@@ -373,7 +375,7 @@ static void xen_sync_dirty_bitmap(XenIOState *state, > int rc, i, j; > const XenPhysmap *physmap = NULL; > >- physmap = get_physmapping(start_addr, size); >+ physmap = get_physmapping(start_addr, size, TARGET_PAGE_MASK); > if (physmap == NULL) { > /* not handled */ > return; >@@ -633,7 +635,7 @@ void xen_hvm_modified_memory(ram_addr_t start, ram_addr_t length) > int rc; > ram_addr_t start_pfn, nb_pages; > >- start = xen_phys_offset_to_gaddr(start, length); >+ start = xen_phys_offset_to_gaddr(start, length, TARGET_PAGE_MASK); > > if (length == 0) { > length = TARGET_PAGE_SIZE; >-- >2.41.0 > > Reviewed-by: Manos Pitsidianakis From xen-devel-bounces@lists.xenproject.org Thu Mar 07 11:54:36 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 11:54:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689802.1075114 (Exim 4.92) (envelope-from ) id 1riCKV-00027w-Ns; Thu, 07 Mar 2024 11:54:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689802.1075114; Thu, 07 Mar 2024 11:54:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riCKV-00027p-JH; Thu, 07 Mar 2024 11:54:31 +0000 Received: by outflank-mailman (input) for mailman id 689802; Thu, 07 Mar 2024 11:54:30 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riCKU-00027j-Tf for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 11:54:30 +0000 Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [2a00:1450:4864:20::232]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 7477a11b-dc79-11ee-afda-a90da7624cb6; Thu, 07 Mar 2024 12:54:29 +0100 (CET) Received: by mail-lj1-x232.google.com with SMTP id 38308e7fff4ca-2d240d8baf6so9188791fa.3 for ; Thu, 07 Mar 2024 03:54:29 -0800 (PST) Received: from meli.delivery (adsl-101.109.242.224.tellas.gr. [109.242.224.101]) by smtp.gmail.com with ESMTPSA id i9-20020a5d6309000000b0033e122a9a91sm19368088wru.105.2024.03.07.03.54.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Mar 2024 03:54:29 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 7477a11b-dc79-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1709812469; x=1710417269; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:message-id:in-reply-to :references:user-agent:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to; bh=D4wGmyvUQ61mLBJ031BInsy1nVuxKAhaid0zefzzgGc=; b=RMEwsQ0eFAIJPSZlxSOtAUdD7z53wNeYy/7PvzYzwkEa39hamRh0NbNpRriLGG0Y75 IHtvC3I1XOPpN+dJobVtqDpcz1eMlRksoTTI3AFMJzPmWzQZMKf6kOGrKqRT/ZtQlHak VPzEzQpkEfzm9n5HoyQV1BetGGoKeFDf9NTs2ZLpnD2vexSmHdtIPQyWSmLY1gYdJxWp QEzfYKlgMX9GQc4UqPFSBO7F7py0vc6s3ZIwqHJ2cA075u5zaMn/8q0F4/EASIfiamMv rgcAe6rvP2buKUIfFfme5/8kyCPDJBUPk5BxyS6KTtw4HZ9eYrdhG3XCmiAg0L8CPrXC 3ClQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709812469; x=1710417269; h=content-transfer-encoding:mime-version:message-id:in-reply-to :references:user-agent:subject:cc:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=D4wGmyvUQ61mLBJ031BInsy1nVuxKAhaid0zefzzgGc=; b=tKCQnkn2QiiN5KCbuCzzJXxkzgknC7RfIwvsYcZ+vXyq3NEjPKsz/w5b2arlPi1gNp FCMRlI7SJfyjG4bbJlWTIgRgPzC9oIaMwWdME3BpIql6708abAfCHD8HpP8ZObSvtajQ 9wcMXp8LsZLH6STEV6v8v0hPVkRaXalxctRSFQpxZOwxTiiG2HibFXCfpnih89CItYll hx24Sg85I1XXQn7Z0mJKf/w3fQCdtSTRvo811d6UwiWaWbUVD2KnvKTW6Q1WNhEl/EiC 3137uKTC7x3BaSBHH9I8cMEiQQutMI85TuhQO6alokw0rpqHj6lyhXYLDRNe1Z8mJzpS z8ZA== X-Forwarded-Encrypted: i=1; AJvYcCUe4VFK1InFYkKaI5aioTtPdg/wKc4SI4gKqP+VhTS/IgV1x+JNq7SK9DYFXtzQZhb4vP+kHuPb5o7EXny9oKIFqGjs65YP12uG5RT8CcU= X-Gm-Message-State: AOJu0Yy1BPDlWaxVYOxaLygVhOPaYKZ90m/lwBHFI4dxf7O0yl52yLnS WCruIXdoDFvhcrBGzziGr6VoNJqLKQhp0K+MKVrPGXqkaauV7LDIRdI2Z6XgZf0= X-Google-Smtp-Source: AGHT+IHz5Cvig/z02xR0HuA2J9PkQo8Dyofphkh0RFYr8J9DsKohKy9DtwP9NgjeqhuAqzXFKS1QlQ== X-Received: by 2002:a2e:9ad6:0:b0:2d3:e236:ddc2 with SMTP id p22-20020a2e9ad6000000b002d3e236ddc2mr1155474ljj.30.1709812469290; Thu, 07 Mar 2024 03:54:29 -0800 (PST) Date: Thu, 07 Mar 2024 13:49:11 +0200 From: Manos Pitsidianakis To: qemu-arm@nongnu.org, Philippe Mathieu-Daud=?UTF-8?B?w6kg?=, qemu-devel@nongnu.org Cc: Anthony Perard , Paul Durrant , David Woodhouse , Thomas Huth , qemu-arm@nongnu.org, Stefano Stabellini , Paolo Bonzini , Alex Benn=?UTF-8?B?w6k=?= e , xen-devel@lists.xenproject.org, Philippe Mathieu-Daud=?UTF-8?B?w6kg?=, Richard Henderson , Eduardo Habkost , "Michael S. Tsirkin" , Marcel Apfelbaum Bcc: Subject: Re: [PATCH-for-9.0 3/9] hw/xen/hvm: Get target page size at runtime User-Agent: meli 0.8.5-rc.3 References: <20231114163123.74888-1-philmd@linaro.org> <20231114163123.74888-4-philmd@linaro.org> In-Reply-To: <20231114163123.74888-4-philmd@linaro.org> Message-ID: <9z7qq.40e122bkrid@linaro.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8; format=flowed On Tue, 14 Nov 2023 18:31, Philippe Mathieu-Daudé wrote: >In order to build this file once for all targets, replace: > > TARGET_PAGE_BITS -> qemu_target_page_bits() > TARGET_PAGE_SIZE -> qemu_target_page_size() > TARGET_PAGE_MASK -> -qemu_target_page_size() > >Signed-off-by: Philippe Mathieu-Daudé >--- > hw/i386/xen/xen-hvm.c | 62 +++++++++++++++++++++++++++---------------- > 1 file changed, 39 insertions(+), 23 deletions(-) > >diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c >index 3b10425986..b64204ea94 100644 >--- a/hw/i386/xen/xen-hvm.c >+++ b/hw/i386/xen/xen-hvm.c >@@ -22,6 +22,7 @@ > > #include "hw/xen/xen-hvm-common.h" > #include >+#include "exec/target_page.h" > #include "cpu.h" > > static MemoryRegion ram_640k, ram_lo, ram_hi; >@@ -247,6 +248,9 @@ static int xen_add_to_physmap(XenIOState *state, > MemoryRegion *mr, > hwaddr offset_within_region) > { >+ unsigned target_page_bits = qemu_target_page_bits(); >+ int page_size = qemu_target_page_size(); >+ int page_mask = -page_size; > unsigned long nr_pages; > int rc = 0; > XenPhysmap *physmap = NULL; >@@ -254,7 +258,7 @@ static int xen_add_to_physmap(XenIOState *state, > hwaddr phys_offset = memory_region_get_ram_addr(mr); > const char *mr_name; > >- if (get_physmapping(start_addr, size, TARGET_PAGE_MASK)) { >+ if (get_physmapping(start_addr, size, page_mask)) { > return 0; > } > if (size <= 0) { >@@ -294,9 +298,9 @@ go_physmap: > return 0; > } > >- pfn = phys_offset >> TARGET_PAGE_BITS; >- start_gpfn = start_addr >> TARGET_PAGE_BITS; >- nr_pages = size >> TARGET_PAGE_BITS; >+ pfn = phys_offset >> target_page_bits; >+ start_gpfn = start_addr >> target_page_bits; >+ nr_pages = size >> target_page_bits; > rc = xendevicemodel_relocate_memory(xen_dmod, xen_domid, nr_pages, pfn, > start_gpfn); > if (rc) { >@@ -310,8 +314,8 @@ go_physmap: > } > > rc = xendevicemodel_pin_memory_cacheattr(xen_dmod, xen_domid, >- start_addr >> TARGET_PAGE_BITS, >- (start_addr + size - 1) >> TARGET_PAGE_BITS, >+ start_addr >> target_page_bits, >+ (start_addr + size - 1) >> target_page_bits, > XEN_DOMCTL_MEM_CACHEATTR_WB); > if (rc) { > error_report("pin_memory_cacheattr failed: %s", strerror(errno)); >@@ -323,11 +327,14 @@ static int xen_remove_from_physmap(XenIOState *state, > hwaddr start_addr, > ram_addr_t size) > { >+ unsigned target_page_bits = qemu_target_page_bits(); >+ int page_size = qemu_target_page_size(); >+ int page_mask = -page_size; > int rc = 0; > XenPhysmap *physmap = NULL; > hwaddr phys_offset = 0; > >- physmap = get_physmapping(start_addr, size, TARGET_PAGE_MASK); >+ physmap = get_physmapping(start_addr, size, page_mask); > if (physmap == NULL) { > return -1; > } >@@ -338,9 +345,9 @@ static int xen_remove_from_physmap(XenIOState *state, > DPRINTF("unmapping vram to %"HWADDR_PRIx" - %"HWADDR_PRIx", at " > "%"HWADDR_PRIx"\n", start_addr, start_addr + size, phys_offset); > >- size >>= TARGET_PAGE_BITS; >- start_addr >>= TARGET_PAGE_BITS; >- phys_offset >>= TARGET_PAGE_BITS; >+ size >>= target_page_bits; >+ start_addr >>= target_page_bits; >+ phys_offset >>= target_page_bits; > rc = xendevicemodel_relocate_memory(xen_dmod, xen_domid, size, start_addr, > phys_offset); > if (rc) { >@@ -369,13 +376,16 @@ static void xen_sync_dirty_bitmap(XenIOState *state, > hwaddr start_addr, > ram_addr_t size) > { >- hwaddr npages = size >> TARGET_PAGE_BITS; >+ unsigned target_page_bits = qemu_target_page_bits(); >+ int page_size = qemu_target_page_size(); >+ int page_mask = -page_size; >+ hwaddr npages = size >> target_page_bits; > const int width = sizeof(unsigned long) * 8; > size_t bitmap_size = DIV_ROUND_UP(npages, width); > int rc, i, j; > const XenPhysmap *physmap = NULL; > >- physmap = get_physmapping(start_addr, size, TARGET_PAGE_MASK); >+ physmap = get_physmapping(start_addr, size, page_mask); > if (physmap == NULL) { > /* not handled */ > return; >@@ -389,7 +399,7 @@ static void xen_sync_dirty_bitmap(XenIOState *state, > return; > } > >- rc = xen_track_dirty_vram(xen_domid, start_addr >> TARGET_PAGE_BITS, >+ rc = xen_track_dirty_vram(xen_domid, start_addr >> target_page_bits, > npages, dirty_bitmap); > if (rc < 0) { > #ifndef ENODATA >@@ -410,8 +420,7 @@ static void xen_sync_dirty_bitmap(XenIOState *state, > j = ctzl(map); > map &= ~(1ul << j); > memory_region_set_dirty(framebuffer, >- (i * width + j) * TARGET_PAGE_SIZE, >- TARGET_PAGE_SIZE); >+ (i * width + j) * page_size, page_size); > }; > } > } >@@ -631,17 +640,21 @@ void xen_register_framebuffer(MemoryRegion *mr) > > void xen_hvm_modified_memory(ram_addr_t start, ram_addr_t length) > { >+ unsigned target_page_bits = qemu_target_page_bits(); >+ int page_size = qemu_target_page_size(); >+ int page_mask = -page_size; >+ > if (unlikely(xen_in_migration)) { > int rc; > ram_addr_t start_pfn, nb_pages; > >- start = xen_phys_offset_to_gaddr(start, length, TARGET_PAGE_MASK); >+ start = xen_phys_offset_to_gaddr(start, length, page_mask); > > if (length == 0) { >- length = TARGET_PAGE_SIZE; >+ length = page_size; > } >- start_pfn = start >> TARGET_PAGE_BITS; >- nb_pages = ((start + length + TARGET_PAGE_SIZE - 1) >> TARGET_PAGE_BITS) >+ start_pfn = start >> target_page_bits; >+ nb_pages = ((start + length + page_size - 1) >> target_page_bits) > - start_pfn; > rc = xen_modified_memory(xen_domid, start_pfn, nb_pages); > if (rc) { >@@ -664,6 +677,9 @@ void qmp_xen_set_global_dirty_log(bool enable, Error **errp) > void xen_arch_set_memory(XenIOState *state, MemoryRegionSection *section, > bool add) > { >+ unsigned target_page_bits = qemu_target_page_bits(); >+ int page_size = qemu_target_page_size(); >+ int page_mask = -page_size; > hwaddr start_addr = section->offset_within_address_space; > ram_addr_t size = int128_get64(section->size); > bool log_dirty = memory_region_is_logging(section->mr, DIRTY_MEMORY_VGA); >@@ -679,8 +695,8 @@ void xen_arch_set_memory(XenIOState *state, MemoryRegionSection *section, > > trace_xen_client_set_memory(start_addr, size, log_dirty); > >- start_addr &= TARGET_PAGE_MASK; >- size = ROUND_UP(size, TARGET_PAGE_SIZE); >+ start_addr &= page_mask; >+ size = ROUND_UP(size, page_size); > > if (add) { > if (!memory_region_is_rom(section->mr)) { >@@ -689,8 +705,8 @@ void xen_arch_set_memory(XenIOState *state, MemoryRegionSection *section, > } else { > mem_type = HVMMEM_ram_ro; > if (xen_set_mem_type(xen_domid, mem_type, >- start_addr >> TARGET_PAGE_BITS, >- size >> TARGET_PAGE_BITS)) { >+ start_addr >> target_page_bits, >+ size >> target_page_bits)) { > DPRINTF("xen_set_mem_type error, addr: "HWADDR_FMT_plx"\n", > start_addr); > } >-- >2.41.0 > > Reviewed-by: Manos Pitsidianakis From xen-devel-bounces@lists.xenproject.org Thu Mar 07 11:55:55 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 11:55:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689805.1075122 (Exim 4.92) (envelope-from ) id 1riCLq-0002nV-2y; Thu, 07 Mar 2024 11:55:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689805.1075122; Thu, 07 Mar 2024 11:55:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riCLq-0002nO-08; Thu, 07 Mar 2024 11:55:54 +0000 Received: by outflank-mailman (input) for mailman id 689805; Thu, 07 Mar 2024 11:55:52 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riCLo-0002nE-In for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 11:55:52 +0000 Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [2a00:1450:4864:20::332]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id a53a9652-dc79-11ee-afda-a90da7624cb6; Thu, 07 Mar 2024 12:55:51 +0100 (CET) Received: by mail-wm1-x332.google.com with SMTP id 5b1f17b1804b1-412f55695d1so7252625e9.0 for ; Thu, 07 Mar 2024 03:55:51 -0800 (PST) Received: from meli.delivery (adsl-101.109.242.224.tellas.gr. [109.242.224.101]) by smtp.gmail.com with ESMTPSA id r11-20020a05600c35cb00b004127057d6b9sm2517388wmq.35.2024.03.07.03.55.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Mar 2024 03:55:50 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a53a9652-dc79-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1709812551; x=1710417351; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:message-id:in-reply-to :references:user-agent:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to; bh=S2WmJe5+VMgo3q0Y6DtKVBoMQYi4KEJJ63YECSnGdAI=; b=ti9lqOzxB3HbfaCeLZHY9v7EZlsjgowvN1YP+0s7bhET55tmnJgDpTitGEjrdz6Ywz uQmQF78ggM/vlzIp1gllsQb+BjDb8+2aqN+KWtcWg5qcEJcjpdDqb1MtiUdaMYj217+v mzjyq3zAYP6pp00SnhbAzS71KDq5Sr4AZqs6Yta1a0lut5XBQBFRF7BwgOleVYmLcDsG wBJeN90y4zJM+PWcXBQB6XnhO+/OS6w9GBsyAIma7oX42seAA63/0YIkIfkYIdChFiUH FS8TXmG3Q9Y9CwGSeCWXr+kpSKJBHkj4UZ516to278B++g4jM2lXsyoGEuwazutcpzeI DYJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709812551; x=1710417351; h=content-transfer-encoding:mime-version:message-id:in-reply-to :references:user-agent:subject:cc:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=S2WmJe5+VMgo3q0Y6DtKVBoMQYi4KEJJ63YECSnGdAI=; b=X34X8ITZJkZxD2nfKD9NGAZu9KPQqAwd+Oofm/kOqzrKndQyIh+LlRig3sDm+6sUKY cCmWYH9/asiEnzbGVBjEHj1q83Gxw5qyqPZs8KkNbGBuQPodmCW89BehT0Vnv167w+bV tycAUdVFhdCIqMSrIFQsy8mpWbqqroWS2xG/ue3P6o7RDmAIIX8eW9Yg6PiI2n0uS/mb laIb77QoMQUkOYma06f3rz+3lZJH58aVxyhE2Bw47EIK3n3ljRTZgXfKl5GRH5XhlvDZ +fcsUnsDRDX/iu6Q78kAxJGAHcPvIpXNhVIXB5yd7Fr7pEFBcUca9cGEES4DsHf8Dezv SLgg== X-Forwarded-Encrypted: i=1; AJvYcCV2x4X+FtM6OZaY08H909+txupaeTuUcCaorc7M2NpTzPxWTjnQzVWzguwlQG3eAKnJXSTp+pYR0jQmV07L152cnfH7s4aruc6V1FAYPJQ= X-Gm-Message-State: AOJu0YwowhDTSWPxeQtKXwpyXTk21HPBOC4jGOX/yoOzAypE0CBpahnZ 7gpL9EQ4uzAvqKFz/Xa5HHTwW2+YwHwhz2Ew8Qtx7pl7q8kFocnC1b6Ttc9alVU= X-Google-Smtp-Source: AGHT+IGSeoRtR4+ZIJLregRqLFeBUzAzoogr8Ud+254lhRno0eax5sWI6+KhquUo7luhLcS/qDwyrg== X-Received: by 2002:a05:600c:5247:b0:412:9dd0:f7e7 with SMTP id fc7-20020a05600c524700b004129dd0f7e7mr13265305wmb.22.1709812551075; Thu, 07 Mar 2024 03:55:51 -0800 (PST) Date: Thu, 07 Mar 2024 13:54:35 +0200 From: Manos Pitsidianakis To: qemu-devel@nongnu.org, Philippe Mathieu-Daud=?UTF-8?B?w6kg?= Cc: Anthony Perard , Paul Durrant , David Woodhouse , Thomas Huth , qemu-arm@nongnu.org, Stefano Stabellini , Paolo Bonzini , Alex Benn=?UTF-8?B?w6k=?= e , xen-devel@lists.xenproject.org, Philippe Mathieu-Daud=?UTF-8?B?w6kg?=, Peter Maydell , "Michael S. Tsirkin" , Marcel Apfelbaum , Richard Henderson , Eduardo Habkost Bcc: Subject: Re: [PATCH-for-9.0 4/9] hw/xen/hvm: Expose xen_memory_listener declaration User-Agent: meli 0.8.5-rc.3 References: <20231114163123.74888-1-philmd@linaro.org> <20231114163123.74888-5-philmd@linaro.org> In-Reply-To: <20231114163123.74888-5-philmd@linaro.org> Message-ID: <9z7t0.nx533lxsltko@linaro.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8; format=flowed On Tue, 14 Nov 2023 18:31, Philippe Mathieu-Daudé wrote: >There can only be a single xen_memory_listener definition >in a qemu-system binary. > >Signed-off-by: Philippe Mathieu-Daudé >--- > include/hw/xen/xen-hvm-common.h | 1 + > hw/arm/xen_arm.c | 2 +- > hw/i386/xen/xen-hvm.c | 2 +- > 3 files changed, 3 insertions(+), 2 deletions(-) > >diff --git a/include/hw/xen/xen-hvm-common.h b/include/hw/xen/xen-hvm-common.h >index 83ed16f425..0fed15ed04 100644 >--- a/include/hw/xen/xen-hvm-common.h >+++ b/include/hw/xen/xen-hvm-common.h >@@ -18,6 +18,7 @@ > extern MemoryRegion xen_memory; > extern MemoryListener xen_io_listener; > extern DeviceListener xen_device_listener; >+extern const MemoryListener xen_memory_listener; > > //#define DEBUG_XEN_HVM > >diff --git a/hw/arm/xen_arm.c b/hw/arm/xen_arm.c >index b478d74ea0..39dcd74d07 100644 >--- a/hw/arm/xen_arm.c >+++ b/hw/arm/xen_arm.c >@@ -38,7 +38,7 @@ > #define TYPE_XEN_ARM MACHINE_TYPE_NAME("xenpvh") > OBJECT_DECLARE_SIMPLE_TYPE(XenArmState, XEN_ARM) > >-static const MemoryListener xen_memory_listener = { >+const MemoryListener xen_memory_listener = { > .region_add = xen_region_add, > .region_del = xen_region_del, > .log_start = NULL, >diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c >index b64204ea94..a65a96f0de 100644 >--- a/hw/i386/xen/xen-hvm.c >+++ b/hw/i386/xen/xen-hvm.c >@@ -469,7 +469,7 @@ static void xen_log_global_stop(MemoryListener *listener) > xen_in_migration = false; > } > >-static const MemoryListener xen_memory_listener = { >+const MemoryListener xen_memory_listener = { > .name = "xen-memory", > .region_add = xen_region_add, > .region_del = xen_region_del, >-- >2.41.0 > > Reviewed-by: Manos Pitsidianakis From xen-devel-bounces@lists.xenproject.org Thu Mar 07 11:57:33 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 11:57:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689810.1075132 (Exim 4.92) (envelope-from ) id 1riCNP-0003Kv-Du; Thu, 07 Mar 2024 11:57:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689810.1075132; Thu, 07 Mar 2024 11:57:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riCNP-0003Ko-B2; Thu, 07 Mar 2024 11:57:31 +0000 Received: by outflank-mailman (input) for mailman id 689810; Thu, 07 Mar 2024 11:57:29 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riCNN-0003Ki-Ha for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 11:57:29 +0000 Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [2a00:1450:4864:20::433]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id de3d06bb-dc79-11ee-a1ee-f123f15fe8a2; Thu, 07 Mar 2024 12:57:27 +0100 (CET) Received: by mail-wr1-x433.google.com with SMTP id ffacd0b85a97d-33e383546c1so414375f8f.2 for ; Thu, 07 Mar 2024 03:57:27 -0800 (PST) Received: from meli.delivery (adsl-101.37.6.0.tellas.gr. [37.6.0.101]) by smtp.gmail.com with ESMTPSA id ck4-20020a5d5e84000000b0033e2b9f647asm14506048wrb.31.2024.03.07.03.57.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Mar 2024 03:57:26 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: de3d06bb-dc79-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1709812647; x=1710417447; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:message-id:in-reply-to :references:user-agent:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to; bh=57A09yidrpDPUR1r7F8CHS4CvBdl9GurP/NjYKl3Cg4=; b=eke7JxnznCc0A/kZKQdl5wxi1VxhfDQJdWJ2ilw3NL3MdP6Pc2tdcOriBRKL8LpiX3 PXjS3mwH5S2nqc+rc2GV5IwfTBbAi3MdEhva/Sj+vZiwId7E3v18KyCDhGiehZdfK/GM wcvjaLyq7dUddhaDM36qerigS0xXo37HjASeX1xFTzuJPZnTSjHBCMCPXn7G9Kenr9lI oDjFgXXfvyhbs0AGqqIh7Uu+BtBrxafPD7JrZ6sju6kqFmmg8EZWRjGvdVMj2fKOtvd2 4famhP7Qh9qRHkah5/DopySo0bnywT85AXBYGnThHpzqlacNyJp2PZ9gENW9ARpVo7XN /rmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709812647; x=1710417447; h=content-transfer-encoding:mime-version:message-id:in-reply-to :references:user-agent:subject:cc:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=57A09yidrpDPUR1r7F8CHS4CvBdl9GurP/NjYKl3Cg4=; b=UMOSgVtRK8q5L+n7SkRs1+cam7fIk5XpYUDW6x4cVJzrguXYJprR8yL3tn4KKQUclM 7ck7IgyfV6YNtqlJr2d5B+brPvqhYzncYYnho9Xhp69MLNbOjORzNSqQoVjtpqc83NbB 9TSosDIJhltHFb5PjO3Ely8V7JJUqw2EqjJW5COQY0LXSVBAPuKSgCwnPnvttSp+RsU3 hJInLDnOX76u8T0vNDLrO57u3ViOd3vTcXDVu+i6yii6z8hwiwup2P+FiUm17XtX5NXr 7KlQJqDsOBM3J8QwF+KKSzBcBAazrQHwv/GDHo7aZSDDst2+adn+MUXSGgbXHgd9gIaC AIhQ== X-Forwarded-Encrypted: i=1; AJvYcCXHw9Morm6qkLjNTgzG3MKnqctzsPQvIKAItdYLCKdPqOEY+rFoV+fWnyWr5n/Xs3Eq0kV3/LvPqWB2SnAo94nwk48v5/RV4XpRE3MyD2Y= X-Gm-Message-State: AOJu0Yza3Y79eERDHtskgiWQuZgpINTWKWIdrglSXxQIPuZVkGudI8X+ /YgNjNFKclkY0x9HzonbGhniyWdVCnY7Sc/OpU8OaC9f9wyEzFnEsKfNDnWIYDw= X-Google-Smtp-Source: AGHT+IESCFwpHQmPxOg130/0yHnqMR5/u93SMsub5nGrOR8b42+ayiblaPN9pioxp+dZdBxzB/xsng== X-Received: by 2002:a5d:6e90:0:b0:33e:d27:4f8c with SMTP id k16-20020a5d6e90000000b0033e0d274f8cmr12927971wrz.6.1709812647026; Thu, 07 Mar 2024 03:57:27 -0800 (PST) Date: Thu, 07 Mar 2024 13:55:56 +0200 From: Manos Pitsidianakis To: qemu-arm@nongnu.org, Philippe Mathieu-Daud=?UTF-8?B?w6kg?=, qemu-devel@nongnu.org Cc: Anthony Perard , Paul Durrant , David Woodhouse , Thomas Huth , qemu-arm@nongnu.org, Stefano Stabellini , Paolo Bonzini , Alex Benn=?UTF-8?B?w6k=?= e , xen-devel@lists.xenproject.org, Philippe Mathieu-Daud=?UTF-8?B?w6kg?=, Richard Henderson , Eduardo Habkost , "Michael S. Tsirkin" , Marcel Apfelbaum Bcc: Subject: Re: [PATCH-for-9.0 5/9] hw/xen/hvm: Expose xen_read_physmap() prototype User-Agent: meli 0.8.5-rc.3 References: <20231114163123.74888-1-philmd@linaro.org> <20231114163123.74888-6-philmd@linaro.org> In-Reply-To: <20231114163123.74888-6-philmd@linaro.org> Message-ID: <9z7vo.cvkkbfxdigjz@linaro.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8; format=flowed On Tue, 14 Nov 2023 18:31, Philippe Mathieu-Daudé wrote: >In a pair of commit we are going to call xen_read_physmap() >out of hw/i386/xen/xen-hvm.c. > >Signed-off-by: Philippe Mathieu-Daudé >--- > include/hw/xen/xen-hvm-common.h | 1 + > hw/i386/xen/xen-hvm.c | 4 ++-- > 2 files changed, 3 insertions(+), 2 deletions(-) > >diff --git a/include/hw/xen/xen-hvm-common.h b/include/hw/xen/xen-hvm-common.h >index 0fed15ed04..536712dc83 100644 >--- a/include/hw/xen/xen-hvm-common.h >+++ b/include/hw/xen/xen-hvm-common.h >@@ -97,6 +97,7 @@ void xen_register_ioreq(XenIOState *state, unsigned int max_cpus, > > void cpu_ioreq_pio(ioreq_t *req); > >+void xen_read_physmap(XenIOState *state); > void xen_arch_handle_ioreq(XenIOState *state, ioreq_t *req); > void xen_arch_set_memory(XenIOState *state, > MemoryRegionSection *section, >diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c >index a65a96f0de..789779d02c 100644 >--- a/hw/i386/xen/xen-hvm.c >+++ b/hw/i386/xen/xen-hvm.c >@@ -525,7 +525,7 @@ static void handle_vmport_ioreq(XenIOState *state, ioreq_t *req) > } > > #ifdef XEN_COMPAT_PHYSMAP >-static void xen_read_physmap(XenIOState *state) >+void xen_read_physmap(XenIOState *state) > { > XenPhysmap *physmap = NULL; > unsigned int len, num, i; >@@ -573,7 +573,7 @@ static void xen_read_physmap(XenIOState *state) > free(entries); > } > #else >-static void xen_read_physmap(XenIOState *state) >+void xen_read_physmap(XenIOState *state) > { > } > #endif >-- >2.41.0 > > Reviewed-by: Manos Pitsidianakis From xen-devel-bounces@lists.xenproject.org Thu Mar 07 11:59:03 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 11:59:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689812.1075142 (Exim 4.92) (envelope-from ) id 1riCOs-0003tb-OM; Thu, 07 Mar 2024 11:59:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689812.1075142; Thu, 07 Mar 2024 11:59:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riCOs-0003tU-LZ; Thu, 07 Mar 2024 11:59:02 +0000 Received: by outflank-mailman (input) for mailman id 689812; Thu, 07 Mar 2024 11:59:00 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riCOq-0003tK-Lg for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 11:59:00 +0000 Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [2a00:1450:4864:20::130]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 152fe795-dc7a-11ee-afda-a90da7624cb6; Thu, 07 Mar 2024 12:58:59 +0100 (CET) Received: by mail-lf1-x130.google.com with SMTP id 2adb3069b0e04-512ed314881so777460e87.2 for ; Thu, 07 Mar 2024 03:58:59 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ij26-20020a056402159a00b00562d908daf4sm7917540edb.84.2024.03.07.03.58.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Mar 2024 03:58:58 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 152fe795-dc7a-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709812739; x=1710417539; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=NkWgtVrgHNXYdr5zpOWR3hO6nJsL4QKcOzXrz3opT4s=; b=S0ActWMyVWscpOXDYLKZsP8m/NqAbjukSi+L771wiyAJ4qWBgJhw/fBq5GOwWrsjmo iZhkEZPCaOyIHUCCrQJc+KHd6moYIvRKZNzMd5cC1q3+18xDP2mbwTCHs3GGwp1qwZ07 eyUrn6+XYECLfKMDmIddcutL0e89qQTGVi0M/Pwg+KCMDW4IA8uviGFDIwWWhpHquhFY JTHObddQlbG8TzX/2SvNZN5D4gPfKM0EQGzG/x4eH8zjuZM90crP8ejLB13YBIWmGsLh X//9AhRz8PVwAqxn9ClAeTe8X0So+t9dcburg1nnkgwF8bSNI0xtYJVf0kvMpNyrsYT5 vUiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709812739; x=1710417539; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=NkWgtVrgHNXYdr5zpOWR3hO6nJsL4QKcOzXrz3opT4s=; b=IOfDit8yEfexAF689rDIRh9OrRZoEhbiL07hsMCWb//rJJP3lt4PUUvUDjOVqH17M5 pqWsA9MDXg7WaXFpFo2qfPx2EihkJ5Jy+QbMcWJZlulMOw76huEOVo7NmpXCCqhAq5qb jEo3rvrO1CZkxudNO7amihCaZ4MWs/sdBJxEncGoB7KFBsFcVIKYBznGO/IYo+FpN8kj YE41VHFjyh5pBBtiG+N5yk6XR7VwLcdPnL3vC6ur/F5jTri33dDVq/SRPKj8fpEM0fkO dTSGSYTQXLUSBCXZnjYR4DDalHdCVK5EfO62lMJyMocJG06rKZ3bZOh+jA4vVTS87O4t gB2A== X-Forwarded-Encrypted: i=1; AJvYcCWE8zOiUwVbghI3k+DBNU2cmnGN1JLMWpPgefIkVJG+QrEw/RR8FlUfPeRTGLSvldZvxAvXwI5PUf0B3jnYDRSUYx5AWRbKoQGiQkYm1sY= X-Gm-Message-State: AOJu0YzX5OVPUv/D8vBM1vQBuXiVFD0BwttBebgmrzkCbiuBwiVRGWVM IoA5GpUsB7EEKUgMBRIE0HAuHWWX/jyWyN7eVg5gE5ItQAUDYHJ4Ji2Lb3K1YQ== X-Google-Smtp-Source: AGHT+IGQpnrdn98AeRdJWp4PM5NewRjaKr5623O/73AB2yb4toaBuVxTfTmjzg8C29o4pfcbtjU+8w== X-Received: by 2002:a05:6512:118e:b0:513:25dc:25f8 with SMTP id g14-20020a056512118e00b0051325dc25f8mr1491189lfr.32.1709812739038; Thu, 07 Mar 2024 03:58:59 -0800 (PST) Message-ID: <818ac202-5473-4638-b140-45272b1041ed@suse.com> Date: Thu, 7 Mar 2024 12:58:57 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/3] xen/virtual-region: Include rodata pointers Content-Language: en-US To: Andrew Cooper Cc: Konrad Rzeszutek Wilk , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel , Ross Lagerwall References: <20240305121121.3527944-1-andrew.cooper3@citrix.com> <20240305121121.3527944-3-andrew.cooper3@citrix.com> <87b82706-f538-4807-abaf-1e59cebd286b@suse.com> <82126c3a-0cde-452f-86aa-2571482f42aa@citrix.com> <76ce9dcf-8cac-44b3-9550-f516024bad6e@suse.com> <9e827057-9306-4a2a-8816-410661bf8892@citrix.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <9e827057-9306-4a2a-8816-410661bf8892@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 07.03.2024 12:31, Andrew Cooper wrote: > On 07/03/2024 7:39 am, Jan Beulich wrote: >> On 06.03.2024 18:21, Andrew Cooper wrote: >>> On 06/03/2024 5:09 pm, Ross Lagerwall wrote: >>>> On Tue, Mar 5, 2024 at 2:17 PM Jan Beulich wrote: >>>>> On 05.03.2024 13:11, Andrew Cooper wrote: >>>>>> --- a/xen/include/xen/virtual_region.h >>>>>> +++ b/xen/include/xen/virtual_region.h >>>>>> @@ -16,6 +16,9 @@ struct virtual_region >>>>>> const void *text_start; /* .text virtual address start. */ >>>>>> const void *text_end; /* .text virtual address end. */ >>>>>> >>>>>> + const void *rodata_start; /* .rodata virtual address start (optional). */ >>>>>> + const void *rodata_end; /* .rodata virtual address end. */ >>>>>> + >>>>>> /* If this is NULL the default lookup mechanism is used. */ >>>>>> symbols_lookup_t *symbols_lookup; >>>>> While perhaps the least bad one can do without quite a bit more churn, >>>>> I'm still irritated by a virtual region (singular) suddenly covering >>>>> two ranges of VA space. At the very least I think the description should >>>>> say a word of justification in this regard. An alternative, after all, >>>>> could have been for livepatch code to register separate regions for >>>>> rodata (if present in a patch). >>>>> >>>>> A follow-on question then would be why ordinary data isn't reflected in >>>>> a virtual region. Aiui that's just because livepatch presently has no >>>>> need for it. >>>>> >>>>> Underlying question to both: Is the virtual region concept indeed meant >>>>> to be fully tied to livepatch and its needs? >>>>> >>>> Virtual regions were introduced for live patching but I don't think it >>>> is completely tied to live patching. It was introduced so that any code >>>> can participate in symbol lookup, bug frame and exception table entry >>>> search, rather than special casing "if livepatch" in many places. >>>> >>>> I agree that the virtual region concept is being abused here - it's just >>>> being used as a convenient place to store rodata start/end and doesn't >>>> really have much to do with the text start & end / bug frame / exception >>>> table entry search that the virtual region is intended for. >>>> >>>> Maybe Andrew can explain why he used this approach? >>> I feel the simplicity and obviousness of patch 3 speaks for itself. >>> >>> How do you propose fixing it differently. >> I'm not opposed to doing it the way you do, but I think it then needs >> clarifying (up front) what a virtual region really is. It looks to be >> morphing into a module description instead ... One easy option might >> be to have a comment next to the struct additions here making clear >> that this is rather an abuse, but chosen to be this way to keep things >> simple elsewhere. > > The thing called virtual_region already describes 6 ranges, and I'm > adding a 7th. Hmm, yes, in a way you're right. > It has been a module-ish description right from the very outset.  I > don't think it is fair to describe this as an abuse at all. > > Is this going to satisfy the outstanding concerns? Yes. And thank you for bearing with me. Jan > diff --git a/xen/include/xen/virtual_region.h > b/xen/include/xen/virtual_region.h > index d05362071135..9d150beb8a87 100644 > --- a/xen/include/xen/virtual_region.h > +++ b/xen/include/xen/virtual_region.h > @@ -9,6 +9,12 @@ >  #include >  #include >   > +/* > + * Despite it's name, this is module(ish) description. > + * > + * There's one region for .text/etc, one region for .init during boot only, > + * and one region per livepatch. > + */ >  struct virtual_region >  { >      struct list_head list; > > ~Andrew From xen-devel-bounces@lists.xenproject.org Thu Mar 07 12:00:55 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 12:00:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689819.1075153 (Exim 4.92) (envelope-from ) id 1riCQe-00066K-EZ; Thu, 07 Mar 2024 12:00:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689819.1075153; Thu, 07 Mar 2024 12:00:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riCQe-00066D-BT; Thu, 07 Mar 2024 12:00:52 +0000 Received: by outflank-mailman (input) for mailman id 689819; Thu, 07 Mar 2024 12:00:50 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riCQc-0005nb-LD for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 12:00:50 +0000 Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [2a00:1450:4864:20::332]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 56608282-dc7a-11ee-a1ee-f123f15fe8a2; Thu, 07 Mar 2024 13:00:49 +0100 (CET) Received: by mail-wm1-x332.google.com with SMTP id 5b1f17b1804b1-412f0655d81so6609735e9.2 for ; Thu, 07 Mar 2024 04:00:49 -0800 (PST) Received: from meli.delivery (adsl-101.37.6.0.tellas.gr. [37.6.0.101]) by smtp.gmail.com with ESMTPSA id v23-20020a05600c215700b00412e84e59d8sm2356539wml.44.2024.03.07.04.00.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Mar 2024 04:00:48 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 56608282-dc7a-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1709812848; x=1710417648; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:message-id:in-reply-to :references:user-agent:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to; bh=twWUN2kiBJHMBkCBDehi/T5jG7Og4Pb2CjHBjUGsfYE=; b=QgLYnYWN23HmLxzGZ0MT61DVxSOe8PjC9HjCDVuMMrheEFYvV+uJyGguCtWIrVTV+N 7q5LgndY7TYVdxwTfdgrZ2UnN/LKAuGCdHzxxI9p1N88Z4uCDuh8kieSFJlPtcvMWX/m /oa5YImGdiZgFzJJ21pP77/iWH/EAt6syMWU86AQ6o56GIqSOJ3Gd/uM2X6N8gvRkJ5p 3ViWMqKPqKMSLerHnuk5LWPsSp2wZjWmhwE7nC/hqIAh4khMnAbvzixvwSYhsA6j8ant Yv09QP7YmV5MnGGGZR7tyTyd6xUAnDU3FecmxL9vBMOUCg4WlygvB9lMyUZLYmy0Q8It DcnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709812848; x=1710417648; h=content-transfer-encoding:mime-version:message-id:in-reply-to :references:user-agent:subject:cc:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=twWUN2kiBJHMBkCBDehi/T5jG7Og4Pb2CjHBjUGsfYE=; b=OAsT3C2q/Q6CKC10xTveq7UtrDqWx2Cf18sUgrqaUdTyX0Cxi/UHs5gGmNNvHt8VYC GLx7jKQjMqFgqroNBSwjSq9BoqYohwAa/zt4MUluxrwX+F88u3cwDHtDrjK4j35gpyIQ EDU9hOK8BU7c5GRvRNpOgyBiQ++yeCXusubGTr9gLJ5Rn2fuh4l6t2mGOH3PTRJBeOjo WbfiEqV+32oRl8qwvZb4p/Q6QwDEB+Cmw599BHLTsdxdcatZRrP4Z+RG0EnmmRDN6q9S fMLikIUjUOQQbVXqeDFsuwER/IOHAcS+ylxkLKlJCEwNJbwbQYWUHaAORrPzP2CQSjz9 LjJA== X-Forwarded-Encrypted: i=1; AJvYcCUyrOWg5NpzFbX1m54SjvIGLXV6DurimsftLzaleqZrjzr4kJz4fkOVlKcG2ViD+6/cyNgY3U8RjDtZvZzJ2gOtjZlCP70bGl47K03vZIA= X-Gm-Message-State: AOJu0Yx9wYytOljoSMz1tJ0Al31+Q7iDw3FYiN/BNHQ6Y0zJgOPhaZRz 5RCP1voioGr8986qKZG0M5La50t0U5YG2dQqJd0wT3W2TxS+La4Ma5KcDJX6Q5A= X-Google-Smtp-Source: AGHT+IHpiLitTFNjn86v2ggcN10vD7epyc0jEhUeO7saXhtlWV7ljeU238OFndl2+3dWsKcBM0XbgQ== X-Received: by 2002:a05:600c:5252:b0:412:de1f:cdfb with SMTP id fc18-20020a05600c525200b00412de1fcdfbmr9194532wmb.20.1709812848632; Thu, 07 Mar 2024 04:00:48 -0800 (PST) Date: Thu, 07 Mar 2024 13:58:43 +0200 From: Manos Pitsidianakis To: qemu-devel@nongnu.org, Philippe Mathieu-Daud=?UTF-8?B?w6kg?= Cc: Anthony Perard , Paul Durrant , David Woodhouse , Thomas Huth , qemu-arm@nongnu.org, Stefano Stabellini , Paolo Bonzini , Alex Benn=?UTF-8?B?w6k=?= e , xen-devel@lists.xenproject.org, Philippe Mathieu-Daud=?UTF-8?B?w6kg?=, "Michael S. Tsirkin" , Marcel Apfelbaum , Richard Henderson , Eduardo Habkost Bcc: Subject: Re: [RFC PATCH-for-9.0 6/9] hw/xen/hvm: Initialize xen_physmap QLIST in xen_read_physmap() User-Agent: meli 0.8.5-rc.3 References: <20231114163123.74888-1-philmd@linaro.org> <20231114163123.74888-7-philmd@linaro.org> In-Reply-To: <20231114163123.74888-7-philmd@linaro.org> Message-ID: <9z81a.ekdgcipljjf2@linaro.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8; format=flowed On Tue, 14 Nov 2023 18:31, Philippe Mathieu-Daudé wrote: >xen_read_physmap() is the first function requiring >xen_physmap QLIST being initialized. Move the init >call there. > >Signed-off-by: Philippe Mathieu-Daudé >--- > hw/i386/xen/xen-hvm.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > >diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c >index 789779d02c..3b9c31c1c8 100644 >--- a/hw/i386/xen/xen-hvm.c >+++ b/hw/i386/xen/xen-hvm.c >@@ -532,6 +532,8 @@ void xen_read_physmap(XenIOState *state) > char path[80], *value = NULL; > char **entries = NULL; > >+ QLIST_INIT(&xen_physmap); >+ > snprintf(path, sizeof(path), > "/local/domain/0/device-model/%d/physmap", xen_domid); > entries = xs_directory(state->xenstore, 0, path, &num); >@@ -575,6 +577,7 @@ void xen_read_physmap(XenIOState *state) > #else > void xen_read_physmap(XenIOState *state) > { >+ QLIST_INIT(&xen_physmap); > } > #endif > >@@ -595,7 +598,6 @@ void xen_hvm_init_pc(PCMachineState *pcms, MemoryRegion **ram_memory) > > xen_register_ioreq(state, max_cpus, &xen_memory_listener); > >- QLIST_INIT(&xen_physmap); > xen_read_physmap(state); > > suspend.notify = xen_suspend_notifier; >-- >2.41.0 > > Reviewed-by: Manos Pitsidianakis From xen-devel-bounces@lists.xenproject.org Thu Mar 07 12:01:12 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 12:01:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689820.1075162 (Exim 4.92) (envelope-from ) id 1riCQy-0006Wd-M9; Thu, 07 Mar 2024 12:01:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689820.1075162; Thu, 07 Mar 2024 12:01:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riCQy-0006WU-Jd; Thu, 07 Mar 2024 12:01:12 +0000 Received: by outflank-mailman (input) for mailman id 689820; Thu, 07 Mar 2024 12:01:11 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riCQx-0006W1-9K; Thu, 07 Mar 2024 12:01:11 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riCQx-0004tJ-5Y; Thu, 07 Mar 2024 12:01:11 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riCQw-0002Cd-QN; Thu, 07 Mar 2024 12:01:10 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1riCQw-0008W1-Pu; Thu, 07 Mar 2024 12:01:10 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=qtzIXBFa1bWHF0n1FfNDQl1/xfaqV8lfjAFADzTATok=; b=dwDNfjlBUt881Z/zlIOG3f3kz5 l8J1TygwBKAUZjnwA68GSwfqfOzdbzgePU6Mf8c3afDRAAME+RJzHXv86fFQ7us4ntNgW9krbZ61V QTm+05hEKTv1/IZbrRiBnPKBvgncJtSe4pkNavKM7LvAqjDfDnfu985t2rHudBsb5WBE=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-linus test] 184923: regressions - FAIL X-Osstest-Failures: linux-linus:build-arm64:xen-build:fail:regression linux-linus:test-armhf-armhf-xl-multivcpu:host-ping-check-xen:fail:heisenbug linux-linus:test-arm64-arm64-xl-credit1:build-check(1):blocked:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking linux-linus:test-arm64-arm64-libvirt-raw:build-check(1):blocked:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:build-check(1):blocked:nonblocking linux-linus:build-arm64-libvirt:build-check(1):blocked:nonblocking linux-linus:test-arm64-arm64-examine:build-check(1):blocked:nonblocking linux-linus:test-arm64-arm64-xl-vhd:build-check(1):blocked:nonblocking linux-linus:test-arm64-arm64-xl-credit2:build-check(1):blocked:nonblocking linux-linus:test-arm64-arm64-xl:build-check(1):blocked:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: linux=5847c9777c303a792202c609bd761dceb60f4eed X-Osstest-Versions-That: linux=29cd507cbec282e13dcf8f38072a100af96b2bb7 From: osstest service owner Date: Thu, 07 Mar 2024 12:01:10 +0000 flight 184923 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/184923/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 6 xen-build fail in 184917 REGR. vs. 184912 Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-multivcpu 10 host-ping-check-xen fail pass in 184917 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-credit1 1 build-check(1) blocked in 184917 n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked in 184917 n/a test-arm64-arm64-libvirt-raw 1 build-check(1) blocked in 184917 n/a test-arm64-arm64-xl-thunderx 1 build-check(1) blocked in 184917 n/a build-arm64-libvirt 1 build-check(1) blocked in 184917 n/a test-arm64-arm64-examine 1 build-check(1) blocked in 184917 n/a test-arm64-arm64-xl-vhd 1 build-check(1) blocked in 184917 n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked in 184917 n/a test-arm64-arm64-xl 1 build-check(1) blocked in 184917 n/a test-armhf-armhf-xl-multivcpu 15 migrate-support-check fail in 184917 never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-check fail in 184917 never pass test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop fail like 184912 test-armhf-armhf-libvirt 16 saverestore-support-check fail like 184912 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop fail like 184912 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop fail like 184912 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 184912 test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail like 184912 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop fail like 184912 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184912 test-amd64-amd64-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl 15 migrate-support-check fail never pass test-arm64-arm64-xl 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 15 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 15 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 15 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-check fail never pass test-armhf-armhf-libvirt 15 migrate-support-check fail never pass test-amd64-amd64-libvirt-qcow2 14 migrate-support-check fail never pass test-amd64-amd64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-check fail never pass test-arm64-arm64-xl-vhd 14 migrate-support-check fail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-check fail never pass version targeted for testing: linux 5847c9777c303a792202c609bd761dceb60f4eed baseline version: linux 29cd507cbec282e13dcf8f38072a100af96b2bb7 Last test of basis 184912 2024-03-05 21:44:46 Z 1 days Testing same since 184917 2024-03-06 08:16:51 Z 1 days 2 attempts ------------------------------------------------------------ People who touched revisions under test: Kamalesh Babulal Linus Torvalds Tejun Heo Waiman Long jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-amd64-dom0pvh-xl-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-freebsd11-amd64 pass test-amd64-amd64-freebsd12-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-examine-bios pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-amd64-dom0pvh-xl-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu fail test-amd64-amd64-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-amd64-xl-pvshim pass test-amd64-amd64-pygrub pass test-amd64-amd64-libvirt-qcow2 pass test-armhf-armhf-libvirt-qcow2 pass test-amd64-amd64-libvirt-raw pass test-arm64-arm64-libvirt-raw pass test-armhf-armhf-libvirt-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-examine-uefi pass test-amd64-amd64-xl-vhd pass test-arm64-arm64-xl-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these 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 5847c9777c303a792202c609bd761dceb60f4eed Merge: 29cd507cbec2 25125a476283 Author: Linus Torvalds Date: Tue Mar 5 14:00:22 2024 -0800 Merge tag 'cgroup-for-6.8-rc7-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup Pull cgroup fixes from Tejun Heo: "Two cpuset fixes. Both are for bugs in error handling paths and low risk" * tag 'cgroup-for-6.8-rc7-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup: cgroup/cpuset: Fix retval in update_cpumask() cgroup/cpuset: Fix a memory leak in update_exclusive_cpumask() commit 25125a4762835d62ba1e540c1351d447fc1f6c7c Author: Kamalesh Babulal Date: Thu Feb 29 15:41:14 2024 +0530 cgroup/cpuset: Fix retval in update_cpumask() The update_cpumask(), checks for newly requested cpumask by calling validate_change(), which returns an error on passing an invalid set of cpu(s). Independent of the error returned, update_cpumask() always returns zero, suppressing the error and returning success to the user on writing an invalid cpu range for a cpuset. Fix it by returning retval instead, which is returned by validate_change(). Fixes: 99fe36ba6fc1 ("cgroup/cpuset: Improve temporary cpumasks handling") Signed-off-by: Kamalesh Babulal Reviewed-by: Waiman Long Cc: stable@vger.kernel.org # v6.6+ Signed-off-by: Tejun Heo commit 66f40b926dd249f74334a22162c09e7ec1ec5b07 Author: Waiman Long Date: Tue Feb 27 19:58:01 2024 -0500 cgroup/cpuset: Fix a memory leak in update_exclusive_cpumask() Fix a possible memory leak in update_exclusive_cpumask() by moving the alloc_cpumasks() down after the validate_change() check which can fail and still before the temporary cpumasks are needed. Fixes: e2ffe502ba45 ("cgroup/cpuset: Add cpuset.cpus.exclusive for v2") Reported-and-tested-by: Mirsad Todorovac Closes: https://lore.kernel.org/lkml/14915689-27a3-4cd8-80d2-9c30d0c768b6@alu.unizg.hr Signed-off-by: Waiman Long Signed-off-by: Tejun Heo Cc: stable@vger.kernel.org # v6.7+ From xen-devel-bounces@lists.xenproject.org Thu Mar 07 12:03:14 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 12:03:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689830.1075172 (Exim 4.92) (envelope-from ) id 1riCSu-0007Ur-2x; Thu, 07 Mar 2024 12:03:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689830.1075172; Thu, 07 Mar 2024 12:03:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riCSu-0007Ui-0G; Thu, 07 Mar 2024 12:03:12 +0000 Received: by outflank-mailman (input) for mailman id 689830; Thu, 07 Mar 2024 12:03:10 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riCSs-0007Ub-N6 for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 12:03:10 +0000 Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [2a00:1450:4864:20::133]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id a96b4cd0-dc7a-11ee-a1ee-f123f15fe8a2; Thu, 07 Mar 2024 13:03:08 +0100 (CET) Received: by mail-lf1-x133.google.com with SMTP id 2adb3069b0e04-5131a9b3d5bso897535e87.0 for ; Thu, 07 Mar 2024 04:03:08 -0800 (PST) Received: from meli.delivery (adsl-101.37.6.0.tellas.gr. [37.6.0.101]) by smtp.gmail.com with ESMTPSA id er15-20020a05600c84cf00b00412ff07df2bsm2390077wmb.37.2024.03.07.04.03.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Mar 2024 04:03:07 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a96b4cd0-dc7a-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1709812988; x=1710417788; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:message-id:in-reply-to :references:user-agent:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to; bh=RlBrkMTf7SSQDKl3PVutEMaJuCE9dxB8RnU5YDrlXDE=; b=UJ0a4GF7EtfryS6Fi2I4wM7sXMwoMjDYx09bLrFFKFcMLRXZ7H+FaHO3Vf3D+hEXzN 4erI36RkHw+ns0kv7zYOmu2EHyQM1M7WjyBZL7MStnl0p3oA5xY+mey4CwsNQYa4iR5M Sww0ftQAVVGSfSixPKbN1QEOIXwS6An/LS9UYsMx/KTepZT68kOMl0pIUpn9TU0m2q1B YwSb8XFFgLz4B2L8GWW4BhpR4edIMfZJKac0tqpQDJA18dOaDELeE2Qp1Y1iyv1fkpO8 uTW605sSzyqdl0x2d3Y3fuubWp6FAx05IQASvYMjfN65xGa1fcVYSi23nM0Mj+Z8w7LM mhPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709812988; x=1710417788; h=content-transfer-encoding:mime-version:message-id:in-reply-to :references:user-agent:subject:cc:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=RlBrkMTf7SSQDKl3PVutEMaJuCE9dxB8RnU5YDrlXDE=; b=uFBXPXh6XsX5vD8Z9NkYb/cGepH8/3I4CsrNqpGXSRfrMeZfkW2SCPQilk/RhA00hF hF2dNSP2s6WvwSm/1San+ICBnUXp0X+ZRyuHdERZhi6KJrir0XrfmQVENxwIfM9m3xHu ESWk9ZpHcCxVUHGt+k8exPyv5bRDIYROZ0OzUJCCzsee3ktEDQ3cCYQ/VMSs3s1cuUNr VIF/dNjJbHty2mnmybhfca31wvZgkTkxx9k5nery/YBxdHH0GzDMqQRBgfMxqG1cGoKf PNl4EZSkS/Aubh98FklAi9b3E3n2JDte/kmYbRRQw3xR7DRAI3Sp2uvkScEIl6O66Xgd ukXw== X-Forwarded-Encrypted: i=1; AJvYcCVbcULrgCEZBWgZnXb85gWP6K6+6vlvCppJsv/c4ZP5t8YJ3NfppBftUG1ZYeJEZj04sWWOhDuD+qtljXS3ZYFSlCfHNNvnepf+fE0zwEU= X-Gm-Message-State: AOJu0YxIRq164n/kDGRlqAOwQMvxO25lD3EDl8jDl8bVaucRDxHCDfCv Wz7mmV9MwPHv6g4g5fWIf6PsEGpT+GfnMS2X1sygpIbGh7O0aBpSnGHZbRmh1es= X-Google-Smtp-Source: AGHT+IH+F3G+airsYrms0kUgm+WIurfZtRY7dRSZgr1FNrsZyAAIUW2iMiYlIEHJHqJC3i9gBMXNhA== X-Received: by 2002:a19:f612:0:b0:513:2c86:3498 with SMTP id x18-20020a19f612000000b005132c863498mr1257889lfe.48.1709812987752; Thu, 07 Mar 2024 04:03:07 -0800 (PST) Date: Thu, 07 Mar 2024 14:01:08 +0200 From: Manos Pitsidianakis To: qemu-arm@nongnu.org, Philippe Mathieu-Daud=?UTF-8?B?w6kg?=, qemu-devel@nongnu.org Cc: Anthony Perard , Paul Durrant , David Woodhouse , Thomas Huth , qemu-arm@nongnu.org, Stefano Stabellini , Paolo Bonzini , Alex Benn=?UTF-8?B?w6k=?= e , xen-devel@lists.xenproject.org, Philippe Mathieu-Daud=?UTF-8?B?w6kg?=, "Michael S. Tsirkin" , Marcel Apfelbaum , Richard Henderson , Eduardo Habkost Bcc: Subject: Re: [PATCH-for-9.0 7/9] hw/xen/hvm: Extract common code to xen-hvm-common.c User-Agent: meli 0.8.5-rc.3 References: <20231114163123.74888-1-philmd@linaro.org> <20231114163123.74888-8-philmd@linaro.org> In-Reply-To: <20231114163123.74888-8-philmd@linaro.org> Message-ID: <9z855.fonsju6rcb0l@linaro.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8; format=flowed On Tue, 14 Nov 2023 18:31, Philippe Mathieu-Daudé wrote: >Extract non-x86 specific code out of xen-hvm.c, >to xen-hvm-common.c. For now this new file is >only build for x86 targets. s/build/built > >Signed-off-by: Philippe Mathieu-Daudé >--- > hw/i386/xen/xen-hvm-common.c | 473 +++++++++++++++++++++++++++++++++++ > hw/i386/xen/xen-hvm.c | 459 --------------------------------- > hw/i386/xen/meson.build | 1 + > 3 files changed, 474 insertions(+), 459 deletions(-) > create mode 100644 hw/i386/xen/xen-hvm-common.c > >diff --git a/hw/i386/xen/xen-hvm-common.c b/hw/i386/xen/xen-hvm-common.c >new file mode 100644 >index 0000000000..e8ef0e0c94 >--- /dev/null >+++ b/hw/i386/xen/xen-hvm-common.c >@@ -0,0 +1,473 @@ >+/* >+ * Copyright (C) 2010 Citrix Ltd. >+ * >+ * This work is licensed under the terms of the GNU GPL, version 2. See >+ * the COPYING file in the top-level directory. >+ * >+ * Contributions after 2012-01-13 are licensed under the terms of the >+ * GNU GPL, version 2 or (at your option) any later version. >+ */ >+ >+#include "qemu/osdep.h" >+#include "qemu/range.h" >+#include "qapi/qapi-commands-migration.h" >+#include "exec/target_page.h" >+#include "hw/xen/xen-hvm-common.h" >+#include "trace.h" >+ >+static MemoryRegion *framebuffer; >+static bool xen_in_migration; >+ >+static QLIST_HEAD(, XenPhysmap) xen_physmap; >+static const XenPhysmap *log_for_dirtybit; >+/* Buffer used by xen_sync_dirty_bitmap */ >+static unsigned long *dirty_bitmap; >+ >+static XenPhysmap *get_physmapping(hwaddr start_addr, ram_addr_t size, >+ int page_mask) >+{ >+ XenPhysmap *physmap = NULL; >+ >+ start_addr &= -page_mask; >+ >+ QLIST_FOREACH(physmap, &xen_physmap, list) { >+ if (range_covers_byte(physmap->start_addr, physmap->size, start_addr)) { >+ return physmap; >+ } >+ } >+ return NULL; >+} >+ >+static hwaddr xen_phys_offset_to_gaddr(hwaddr phys_offset, ram_addr_t size, >+ int page_mask) >+{ >+ hwaddr addr = phys_offset & -page_mask; >+ XenPhysmap *physmap = NULL; >+ >+ QLIST_FOREACH(physmap, &xen_physmap, list) { >+ if (range_covers_byte(physmap->phys_offset, physmap->size, addr)) { >+ return physmap->start_addr + (phys_offset - physmap->phys_offset); >+ } >+ } >+ >+ return phys_offset; >+} >+ >+#ifdef XEN_COMPAT_PHYSMAP >+static int xen_save_physmap(XenIOState *state, XenPhysmap *physmap) >+{ >+ char path[80], value[17]; >+ >+ snprintf(path, sizeof(path), >+ "/local/domain/0/device-model/%d/physmap/%"PRIx64"/start_addr", >+ xen_domid, (uint64_t)physmap->phys_offset); >+ snprintf(value, sizeof(value), "%"PRIx64, (uint64_t)physmap->start_addr); >+ if (!xs_write(state->xenstore, 0, path, value, strlen(value))) { >+ return -1; >+ } >+ snprintf(path, sizeof(path), >+ "/local/domain/0/device-model/%d/physmap/%"PRIx64"/size", >+ xen_domid, (uint64_t)physmap->phys_offset); >+ snprintf(value, sizeof(value), "%"PRIx64, (uint64_t)physmap->size); >+ if (!xs_write(state->xenstore, 0, path, value, strlen(value))) { >+ return -1; >+ } >+ if (physmap->name) { >+ snprintf(path, sizeof(path), >+ "/local/domain/0/device-model/%d/physmap/%"PRIx64"/name", >+ xen_domid, (uint64_t)physmap->phys_offset); >+ if (!xs_write(state->xenstore, 0, path, >+ physmap->name, strlen(physmap->name))) { >+ return -1; >+ } >+ } >+ return 0; >+} >+#else >+static int xen_save_physmap(XenIOState *state, XenPhysmap *physmap) >+{ >+ return 0; >+} >+#endif >+ >+static int xen_add_to_physmap(XenIOState *state, >+ hwaddr start_addr, >+ ram_addr_t size, >+ MemoryRegion *mr, >+ hwaddr offset_within_region) >+{ >+ unsigned target_page_bits = qemu_target_page_bits(); >+ int page_size = qemu_target_page_size(); >+ int page_mask = -page_size; >+ unsigned long nr_pages; >+ int rc = 0; >+ XenPhysmap *physmap = NULL; >+ hwaddr pfn, start_gpfn; >+ hwaddr phys_offset = memory_region_get_ram_addr(mr); >+ const char *mr_name; >+ >+ if (get_physmapping(start_addr, size, page_mask)) { >+ return 0; >+ } >+ if (size <= 0) { >+ return -1; >+ } >+ >+ /* Xen can only handle a single dirty log region for now and we want >+ * the linear framebuffer to be that region. >+ * Avoid tracking any regions that is not videoram and avoid tracking >+ * the legacy vga region. */ >+ if (mr == framebuffer && start_addr > 0xbffff) { >+ goto go_physmap; >+ } >+ return -1; >+ >+go_physmap: >+ DPRINTF("mapping vram to %"HWADDR_PRIx" - %"HWADDR_PRIx"\n", >+ start_addr, start_addr + size); >+ >+ mr_name = memory_region_name(mr); >+ >+ physmap = g_new(XenPhysmap, 1); >+ >+ physmap->start_addr = start_addr; >+ physmap->size = size; >+ physmap->name = mr_name; >+ physmap->phys_offset = phys_offset; >+ >+ QLIST_INSERT_HEAD(&xen_physmap, physmap, list); >+ >+ if (runstate_check(RUN_STATE_INMIGRATE)) { >+ /* Now when we have a physmap entry we can replace a dummy mapping with >+ * a real one of guest foreign memory. */ >+ uint8_t *p = xen_replace_cache_entry(phys_offset, start_addr, size); >+ assert(p && p == memory_region_get_ram_ptr(mr)); >+ >+ return 0; >+ } >+ >+ pfn = phys_offset >> target_page_bits; >+ start_gpfn = start_addr >> target_page_bits; >+ nr_pages = size >> target_page_bits; >+ rc = xendevicemodel_relocate_memory(xen_dmod, xen_domid, nr_pages, pfn, >+ start_gpfn); >+ if (rc) { >+ int saved_errno = errno; >+ >+ error_report("relocate_memory %lu pages from GFN %"HWADDR_PRIx >+ " to GFN %"HWADDR_PRIx" failed: %s", >+ nr_pages, pfn, start_gpfn, strerror(saved_errno)); >+ errno = saved_errno; >+ return -1; >+ } >+ >+ rc = xendevicemodel_pin_memory_cacheattr(xen_dmod, xen_domid, >+ start_addr >> target_page_bits, >+ (start_addr + size - 1) >> target_page_bits, >+ XEN_DOMCTL_MEM_CACHEATTR_WB); >+ if (rc) { >+ error_report("pin_memory_cacheattr failed: %s", strerror(errno)); >+ } >+ return xen_save_physmap(state, physmap); >+} >+ >+static int xen_remove_from_physmap(XenIOState *state, >+ hwaddr start_addr, >+ ram_addr_t size) >+{ >+ unsigned target_page_bits = qemu_target_page_bits(); >+ int page_size = qemu_target_page_size(); >+ int page_mask = -page_size; >+ int rc = 0; >+ XenPhysmap *physmap = NULL; >+ hwaddr phys_offset = 0; >+ >+ physmap = get_physmapping(start_addr, size, page_mask); >+ if (physmap == NULL) { >+ return -1; >+ } >+ >+ phys_offset = physmap->phys_offset; >+ size = physmap->size; >+ >+ DPRINTF("unmapping vram to %"HWADDR_PRIx" - %"HWADDR_PRIx", at " >+ "%"HWADDR_PRIx"\n", start_addr, start_addr + size, phys_offset); >+ >+ size >>= target_page_bits; >+ start_addr >>= target_page_bits; >+ phys_offset >>= target_page_bits; >+ rc = xendevicemodel_relocate_memory(xen_dmod, xen_domid, size, start_addr, >+ phys_offset); >+ if (rc) { >+ int saved_errno = errno; >+ >+ error_report("relocate_memory "RAM_ADDR_FMT" pages" >+ " from GFN %"HWADDR_PRIx >+ " to GFN %"HWADDR_PRIx" failed: %s", >+ size, start_addr, phys_offset, strerror(saved_errno)); >+ errno = saved_errno; >+ return -1; >+ } >+ >+ QLIST_REMOVE(physmap, list); >+ if (log_for_dirtybit == physmap) { >+ log_for_dirtybit = NULL; >+ g_free(dirty_bitmap); >+ dirty_bitmap = NULL; >+ } >+ g_free(physmap); >+ >+ return 0; >+} >+ >+static void xen_sync_dirty_bitmap(XenIOState *state, >+ hwaddr start_addr, >+ ram_addr_t size) >+{ >+ unsigned target_page_bits = qemu_target_page_bits(); >+ int page_size = qemu_target_page_size(); >+ int page_mask = -page_size; >+ hwaddr npages = size >> target_page_bits; >+ const int width = sizeof(unsigned long) * 8; >+ size_t bitmap_size = DIV_ROUND_UP(npages, width); >+ int rc, i, j; >+ const XenPhysmap *physmap = NULL; >+ >+ physmap = get_physmapping(start_addr, size, page_mask); >+ if (physmap == NULL) { >+ /* not handled */ >+ return; >+ } >+ >+ if (log_for_dirtybit == NULL) { >+ log_for_dirtybit = physmap; >+ dirty_bitmap = g_new(unsigned long, bitmap_size); >+ } else if (log_for_dirtybit != physmap) { >+ /* Only one range for dirty bitmap can be tracked. */ >+ return; >+ } >+ >+ rc = xen_track_dirty_vram(xen_domid, start_addr >> target_page_bits, >+ npages, dirty_bitmap); >+ if (rc < 0) { >+#ifndef ENODATA >+#define ENODATA ENOENT >+#endif >+ if (errno == ENODATA) { >+ memory_region_set_dirty(framebuffer, 0, size); >+ DPRINTF("xen: track_dirty_vram failed (0x" HWADDR_FMT_plx >+ ", 0x" HWADDR_FMT_plx "): %s\n", >+ start_addr, start_addr + size, strerror(errno)); >+ } >+ return; >+ } >+ >+ for (i = 0; i < bitmap_size; i++) { >+ unsigned long map = dirty_bitmap[i]; >+ while (map != 0) { >+ j = ctzl(map); >+ map &= ~(1ul << j); >+ memory_region_set_dirty(framebuffer, >+ (i * width + j) * page_size, >+ page_size); >+ }; >+ } >+} >+ >+static void xen_log_start(MemoryListener *listener, >+ MemoryRegionSection *section, >+ int old, int new) >+{ >+ XenIOState *state = container_of(listener, XenIOState, memory_listener); >+ >+ if (new & ~old & (1 << DIRTY_MEMORY_VGA)) { >+ xen_sync_dirty_bitmap(state, section->offset_within_address_space, >+ int128_get64(section->size)); >+ } >+} >+ >+static void xen_log_stop(MemoryListener *listener, MemoryRegionSection *section, >+ int old, int new) >+{ >+ if (old & ~new & (1 << DIRTY_MEMORY_VGA)) { >+ log_for_dirtybit = NULL; >+ g_free(dirty_bitmap); >+ dirty_bitmap = NULL; >+ /* Disable dirty bit tracking */ >+ xen_track_dirty_vram(xen_domid, 0, 0, NULL); >+ } >+} >+ >+static void xen_log_sync(MemoryListener *listener, MemoryRegionSection *section) >+{ >+ XenIOState *state = container_of(listener, XenIOState, memory_listener); >+ >+ xen_sync_dirty_bitmap(state, section->offset_within_address_space, >+ int128_get64(section->size)); >+} >+ >+static void xen_log_global_start(MemoryListener *listener) >+{ >+ if (xen_enabled()) { >+ xen_in_migration = true; >+ } >+} >+ >+static void xen_log_global_stop(MemoryListener *listener) >+{ >+ xen_in_migration = false; >+} >+ >+const MemoryListener xen_memory_listener = { >+ .name = "xen-memory", >+ .region_add = xen_region_add, >+ .region_del = xen_region_del, >+ .log_start = xen_log_start, >+ .log_stop = xen_log_stop, >+ .log_sync = xen_log_sync, >+ .log_global_start = xen_log_global_start, >+ .log_global_stop = xen_log_global_stop, >+ .priority = MEMORY_LISTENER_PRIORITY_ACCEL, >+}; >+ >+#ifdef XEN_COMPAT_PHYSMAP >+void xen_read_physmap(XenIOState *state) >+{ >+ XenPhysmap *physmap = NULL; >+ unsigned int len, num, i; >+ char path[80], *value = NULL; >+ char **entries = NULL; >+ >+ QLIST_INIT(&xen_physmap); >+ >+ snprintf(path, sizeof(path), >+ "/local/domain/0/device-model/%d/physmap", xen_domid); >+ entries = xs_directory(state->xenstore, 0, path, &num); >+ if (entries == NULL) >+ return; >+ >+ for (i = 0; i < num; i++) { >+ physmap = g_new(XenPhysmap, 1); >+ physmap->phys_offset = strtoull(entries[i], NULL, 16); >+ snprintf(path, sizeof(path), >+ "/local/domain/0/device-model/%d/physmap/%s/start_addr", >+ xen_domid, entries[i]); >+ value = xs_read(state->xenstore, 0, path, &len); >+ if (value == NULL) { >+ g_free(physmap); >+ continue; >+ } >+ physmap->start_addr = strtoull(value, NULL, 16); >+ free(value); >+ >+ snprintf(path, sizeof(path), >+ "/local/domain/0/device-model/%d/physmap/%s/size", >+ xen_domid, entries[i]); >+ value = xs_read(state->xenstore, 0, path, &len); >+ if (value == NULL) { >+ g_free(physmap); >+ continue; >+ } >+ physmap->size = strtoull(value, NULL, 16); >+ free(value); >+ >+ snprintf(path, sizeof(path), >+ "/local/domain/0/device-model/%d/physmap/%s/name", >+ xen_domid, entries[i]); >+ physmap->name = xs_read(state->xenstore, 0, path, &len); >+ >+ QLIST_INSERT_HEAD(&xen_physmap, physmap, list); >+ } >+ free(entries); >+} >+#else >+void xen_read_physmap(XenIOState *state) >+{ >+ QLIST_INIT(&xen_physmap); >+} >+#endif >+ >+void xen_register_framebuffer(MemoryRegion *mr) >+{ >+ framebuffer = mr; >+} >+ >+void xen_hvm_modified_memory(ram_addr_t start, ram_addr_t length) >+{ >+ unsigned target_page_bits = qemu_target_page_bits(); >+ int page_size = qemu_target_page_size(); >+ int page_mask = -page_size; >+ >+ if (unlikely(xen_in_migration)) { >+ int rc; >+ ram_addr_t start_pfn, nb_pages; >+ >+ start = xen_phys_offset_to_gaddr(start, length, page_mask); >+ >+ if (length == 0) { >+ length = page_size; >+ } >+ start_pfn = start >> target_page_bits; >+ nb_pages = ((start + length + page_size - 1) >> target_page_bits) >+ - start_pfn; >+ rc = xen_modified_memory(xen_domid, start_pfn, nb_pages); >+ if (rc) { >+ fprintf(stderr, >+ "%s failed for "RAM_ADDR_FMT" ("RAM_ADDR_FMT"): %i, %s\n", >+ __func__, start, nb_pages, errno, strerror(errno)); >+ } >+ } >+} >+ >+void qmp_xen_set_global_dirty_log(bool enable, Error **errp) >+{ >+ if (enable) { >+ memory_global_dirty_log_start(GLOBAL_DIRTY_MIGRATION); >+ } else { >+ memory_global_dirty_log_stop(GLOBAL_DIRTY_MIGRATION); >+ } >+} >+ >+void xen_arch_set_memory(XenIOState *state, MemoryRegionSection *section, >+ bool add) >+{ >+ unsigned target_page_bits = qemu_target_page_bits(); >+ int page_size = qemu_target_page_size(); >+ int page_mask = -page_size; >+ hwaddr start_addr = section->offset_within_address_space; >+ ram_addr_t size = int128_get64(section->size); >+ bool log_dirty = memory_region_is_logging(section->mr, DIRTY_MEMORY_VGA); >+ hvmmem_type_t mem_type; >+ >+ if (!memory_region_is_ram(section->mr)) { >+ return; >+ } >+ >+ if (log_dirty != add) { >+ return; >+ } >+ >+ trace_xen_client_set_memory(start_addr, size, log_dirty); >+ >+ start_addr &= page_mask; >+ size = ROUND_UP(size, page_size); >+ >+ if (add) { >+ if (!memory_region_is_rom(section->mr)) { >+ xen_add_to_physmap(state, start_addr, size, >+ section->mr, section->offset_within_region); >+ } else { >+ mem_type = HVMMEM_ram_ro; >+ if (xen_set_mem_type(xen_domid, mem_type, >+ start_addr >> target_page_bits, >+ size >> target_page_bits)) { >+ DPRINTF("xen_set_mem_type error, addr: "HWADDR_FMT_plx"\n", >+ start_addr); >+ } >+ } >+ } else { >+ if (xen_remove_from_physmap(state, start_addr, size) < 0) { >+ DPRINTF("physmapping does not exist at "HWADDR_FMT_plx"\n", start_addr); >+ } >+ } >+} >diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c >index 3b9c31c1c8..5657693e1b 100644 >--- a/hw/i386/xen/xen-hvm.c >+++ b/hw/i386/xen/xen-hvm.c >@@ -9,16 +9,11 @@ > */ > > #include "qemu/osdep.h" >-#include "qemu/units.h" >-#include "qapi/error.h" >-#include "qapi/qapi-commands-migration.h" >-#include "trace.h" > > #include "hw/i386/pc.h" > #include "hw/irq.h" > #include "hw/i386/apic-msidef.h" > #include "hw/xen/xen-x86.h" >-#include "qemu/range.h" > > #include "hw/xen/xen-hvm-common.h" > #include >@@ -26,8 +21,6 @@ > #include "cpu.h" > > static MemoryRegion ram_640k, ram_lo, ram_hi; >-static MemoryRegion *framebuffer; >-static bool xen_in_migration; > > /* Compatibility with older version */ > >@@ -56,10 +49,6 @@ typedef struct shared_vmport_iopage shared_vmport_iopage_t; > > static shared_vmport_iopage_t *shared_vmport_page; > >-static QLIST_HEAD(, XenPhysmap) xen_physmap; >-static const XenPhysmap *log_for_dirtybit; >-/* Buffer used by xen_sync_dirty_bitmap */ >-static unsigned long *dirty_bitmap; > static Notifier suspend; > static Notifier wakeup; > >@@ -175,312 +164,6 @@ static void xen_ram_init(PCMachineState *pcms, > } > } > >-static XenPhysmap *get_physmapping(hwaddr start_addr, ram_addr_t size, >- int page_mask) >-{ >- XenPhysmap *physmap = NULL; >- >- start_addr &= page_mask; >- >- QLIST_FOREACH(physmap, &xen_physmap, list) { >- if (range_covers_byte(physmap->start_addr, physmap->size, start_addr)) { >- return physmap; >- } >- } >- return NULL; >-} >- >-static hwaddr xen_phys_offset_to_gaddr(hwaddr phys_offset, ram_addr_t size, >- int page_mask) >-{ >- hwaddr addr = phys_offset & page_mask; >- XenPhysmap *physmap = NULL; >- >- QLIST_FOREACH(physmap, &xen_physmap, list) { >- if (range_covers_byte(physmap->phys_offset, physmap->size, addr)) { >- return physmap->start_addr + (phys_offset - physmap->phys_offset); >- } >- } >- >- return phys_offset; >-} >- >-#ifdef XEN_COMPAT_PHYSMAP >-static int xen_save_physmap(XenIOState *state, XenPhysmap *physmap) >-{ >- char path[80], value[17]; >- >- snprintf(path, sizeof(path), >- "/local/domain/0/device-model/%d/physmap/%"PRIx64"/start_addr", >- xen_domid, (uint64_t)physmap->phys_offset); >- snprintf(value, sizeof(value), "%"PRIx64, (uint64_t)physmap->start_addr); >- if (!xs_write(state->xenstore, 0, path, value, strlen(value))) { >- return -1; >- } >- snprintf(path, sizeof(path), >- "/local/domain/0/device-model/%d/physmap/%"PRIx64"/size", >- xen_domid, (uint64_t)physmap->phys_offset); >- snprintf(value, sizeof(value), "%"PRIx64, (uint64_t)physmap->size); >- if (!xs_write(state->xenstore, 0, path, value, strlen(value))) { >- return -1; >- } >- if (physmap->name) { >- snprintf(path, sizeof(path), >- "/local/domain/0/device-model/%d/physmap/%"PRIx64"/name", >- xen_domid, (uint64_t)physmap->phys_offset); >- if (!xs_write(state->xenstore, 0, path, >- physmap->name, strlen(physmap->name))) { >- return -1; >- } >- } >- return 0; >-} >-#else >-static int xen_save_physmap(XenIOState *state, XenPhysmap *physmap) >-{ >- return 0; >-} >-#endif >- >-static int xen_add_to_physmap(XenIOState *state, >- hwaddr start_addr, >- ram_addr_t size, >- MemoryRegion *mr, >- hwaddr offset_within_region) >-{ >- unsigned target_page_bits = qemu_target_page_bits(); >- int page_size = qemu_target_page_size(); >- int page_mask = -page_size; >- unsigned long nr_pages; >- int rc = 0; >- XenPhysmap *physmap = NULL; >- hwaddr pfn, start_gpfn; >- hwaddr phys_offset = memory_region_get_ram_addr(mr); >- const char *mr_name; >- >- if (get_physmapping(start_addr, size, page_mask)) { >- return 0; >- } >- if (size <= 0) { >- return -1; >- } >- >- /* Xen can only handle a single dirty log region for now and we want >- * the linear framebuffer to be that region. >- * Avoid tracking any regions that is not videoram and avoid tracking >- * the legacy vga region. */ >- if (mr == framebuffer && start_addr > 0xbffff) { >- goto go_physmap; >- } >- return -1; >- >-go_physmap: >- DPRINTF("mapping vram to %"HWADDR_PRIx" - %"HWADDR_PRIx"\n", >- start_addr, start_addr + size); >- >- mr_name = memory_region_name(mr); >- >- physmap = g_new(XenPhysmap, 1); >- >- physmap->start_addr = start_addr; >- physmap->size = size; >- physmap->name = mr_name; >- physmap->phys_offset = phys_offset; >- >- QLIST_INSERT_HEAD(&xen_physmap, physmap, list); >- >- if (runstate_check(RUN_STATE_INMIGRATE)) { >- /* Now when we have a physmap entry we can replace a dummy mapping with >- * a real one of guest foreign memory. */ >- uint8_t *p = xen_replace_cache_entry(phys_offset, start_addr, size); >- assert(p && p == memory_region_get_ram_ptr(mr)); >- >- return 0; >- } >- >- pfn = phys_offset >> target_page_bits; >- start_gpfn = start_addr >> target_page_bits; >- nr_pages = size >> target_page_bits; >- rc = xendevicemodel_relocate_memory(xen_dmod, xen_domid, nr_pages, pfn, >- start_gpfn); >- if (rc) { >- int saved_errno = errno; >- >- error_report("relocate_memory %lu pages from GFN %"HWADDR_PRIx >- " to GFN %"HWADDR_PRIx" failed: %s", >- nr_pages, pfn, start_gpfn, strerror(saved_errno)); >- errno = saved_errno; >- return -1; >- } >- >- rc = xendevicemodel_pin_memory_cacheattr(xen_dmod, xen_domid, >- start_addr >> target_page_bits, >- (start_addr + size - 1) >> target_page_bits, >- XEN_DOMCTL_MEM_CACHEATTR_WB); >- if (rc) { >- error_report("pin_memory_cacheattr failed: %s", strerror(errno)); >- } >- return xen_save_physmap(state, physmap); >-} >- >-static int xen_remove_from_physmap(XenIOState *state, >- hwaddr start_addr, >- ram_addr_t size) >-{ >- unsigned target_page_bits = qemu_target_page_bits(); >- int page_size = qemu_target_page_size(); >- int page_mask = -page_size; >- int rc = 0; >- XenPhysmap *physmap = NULL; >- hwaddr phys_offset = 0; >- >- physmap = get_physmapping(start_addr, size, page_mask); >- if (physmap == NULL) { >- return -1; >- } >- >- phys_offset = physmap->phys_offset; >- size = physmap->size; >- >- DPRINTF("unmapping vram to %"HWADDR_PRIx" - %"HWADDR_PRIx", at " >- "%"HWADDR_PRIx"\n", start_addr, start_addr + size, phys_offset); >- >- size >>= target_page_bits; >- start_addr >>= target_page_bits; >- phys_offset >>= target_page_bits; >- rc = xendevicemodel_relocate_memory(xen_dmod, xen_domid, size, start_addr, >- phys_offset); >- if (rc) { >- int saved_errno = errno; >- >- error_report("relocate_memory "RAM_ADDR_FMT" pages" >- " from GFN %"HWADDR_PRIx >- " to GFN %"HWADDR_PRIx" failed: %s", >- size, start_addr, phys_offset, strerror(saved_errno)); >- errno = saved_errno; >- return -1; >- } >- >- QLIST_REMOVE(physmap, list); >- if (log_for_dirtybit == physmap) { >- log_for_dirtybit = NULL; >- g_free(dirty_bitmap); >- dirty_bitmap = NULL; >- } >- g_free(physmap); >- >- return 0; >-} >- >-static void xen_sync_dirty_bitmap(XenIOState *state, >- hwaddr start_addr, >- ram_addr_t size) >-{ >- unsigned target_page_bits = qemu_target_page_bits(); >- int page_size = qemu_target_page_size(); >- int page_mask = -page_size; >- hwaddr npages = size >> target_page_bits; >- const int width = sizeof(unsigned long) * 8; >- size_t bitmap_size = DIV_ROUND_UP(npages, width); >- int rc, i, j; >- const XenPhysmap *physmap = NULL; >- >- physmap = get_physmapping(start_addr, size, page_mask); >- if (physmap == NULL) { >- /* not handled */ >- return; >- } >- >- if (log_for_dirtybit == NULL) { >- log_for_dirtybit = physmap; >- dirty_bitmap = g_new(unsigned long, bitmap_size); >- } else if (log_for_dirtybit != physmap) { >- /* Only one range for dirty bitmap can be tracked. */ >- return; >- } >- >- rc = xen_track_dirty_vram(xen_domid, start_addr >> target_page_bits, >- npages, dirty_bitmap); >- if (rc < 0) { >-#ifndef ENODATA >-#define ENODATA ENOENT >-#endif >- if (errno == ENODATA) { >- memory_region_set_dirty(framebuffer, 0, size); >- DPRINTF("xen: track_dirty_vram failed (0x" HWADDR_FMT_plx >- ", 0x" HWADDR_FMT_plx "): %s\n", >- start_addr, start_addr + size, strerror(errno)); >- } >- return; >- } >- >- for (i = 0; i < bitmap_size; i++) { >- unsigned long map = dirty_bitmap[i]; >- while (map != 0) { >- j = ctzl(map); >- map &= ~(1ul << j); >- memory_region_set_dirty(framebuffer, >- (i * width + j) * page_size, page_size); >- }; >- } >-} >- >-static void xen_log_start(MemoryListener *listener, >- MemoryRegionSection *section, >- int old, int new) >-{ >- XenIOState *state = container_of(listener, XenIOState, memory_listener); >- >- if (new & ~old & (1 << DIRTY_MEMORY_VGA)) { >- xen_sync_dirty_bitmap(state, section->offset_within_address_space, >- int128_get64(section->size)); >- } >-} >- >-static void xen_log_stop(MemoryListener *listener, MemoryRegionSection *section, >- int old, int new) >-{ >- if (old & ~new & (1 << DIRTY_MEMORY_VGA)) { >- log_for_dirtybit = NULL; >- g_free(dirty_bitmap); >- dirty_bitmap = NULL; >- /* Disable dirty bit tracking */ >- xen_track_dirty_vram(xen_domid, 0, 0, NULL); >- } >-} >- >-static void xen_log_sync(MemoryListener *listener, MemoryRegionSection *section) >-{ >- XenIOState *state = container_of(listener, XenIOState, memory_listener); >- >- xen_sync_dirty_bitmap(state, section->offset_within_address_space, >- int128_get64(section->size)); >-} >- >-static void xen_log_global_start(MemoryListener *listener) >-{ >- if (xen_enabled()) { >- xen_in_migration = true; >- } >-} >- >-static void xen_log_global_stop(MemoryListener *listener) >-{ >- xen_in_migration = false; >-} >- >-const MemoryListener xen_memory_listener = { >- .name = "xen-memory", >- .region_add = xen_region_add, >- .region_del = xen_region_del, >- .log_start = xen_log_start, >- .log_stop = xen_log_stop, >- .log_sync = xen_log_sync, >- .log_global_start = xen_log_global_start, >- .log_global_stop = xen_log_global_stop, >- .priority = MEMORY_LISTENER_PRIORITY_ACCEL, >-}; >- > static void regs_to_cpu(vmware_regs_t *vmport_regs, ioreq_t *req) > { > X86CPU *cpu; >@@ -524,63 +207,6 @@ static void handle_vmport_ioreq(XenIOState *state, ioreq_t *req) > current_cpu = NULL; > } > >-#ifdef XEN_COMPAT_PHYSMAP >-void xen_read_physmap(XenIOState *state) >-{ >- XenPhysmap *physmap = NULL; >- unsigned int len, num, i; >- char path[80], *value = NULL; >- char **entries = NULL; >- >- QLIST_INIT(&xen_physmap); >- >- snprintf(path, sizeof(path), >- "/local/domain/0/device-model/%d/physmap", xen_domid); >- entries = xs_directory(state->xenstore, 0, path, &num); >- if (entries == NULL) >- return; >- >- for (i = 0; i < num; i++) { >- physmap = g_new(XenPhysmap, 1); >- physmap->phys_offset = strtoull(entries[i], NULL, 16); >- snprintf(path, sizeof(path), >- "/local/domain/0/device-model/%d/physmap/%s/start_addr", >- xen_domid, entries[i]); >- value = xs_read(state->xenstore, 0, path, &len); >- if (value == NULL) { >- g_free(physmap); >- continue; >- } >- physmap->start_addr = strtoull(value, NULL, 16); >- free(value); >- >- snprintf(path, sizeof(path), >- "/local/domain/0/device-model/%d/physmap/%s/size", >- xen_domid, entries[i]); >- value = xs_read(state->xenstore, 0, path, &len); >- if (value == NULL) { >- g_free(physmap); >- continue; >- } >- physmap->size = strtoull(value, NULL, 16); >- free(value); >- >- snprintf(path, sizeof(path), >- "/local/domain/0/device-model/%d/physmap/%s/name", >- xen_domid, entries[i]); >- physmap->name = xs_read(state->xenstore, 0, path, &len); >- >- QLIST_INSERT_HEAD(&xen_physmap, physmap, list); >- } >- free(entries); >-} >-#else >-void xen_read_physmap(XenIOState *state) >-{ >- QLIST_INIT(&xen_physmap); >-} >-#endif >- > static void xen_wakeup_notifier(Notifier *notifier, void *data) > { > xc_set_hvm_param(xen_xc, xen_domid, HVM_PARAM_ACPI_S_STATE, 0); >@@ -635,91 +261,6 @@ err: > exit(1); > } > >-void xen_register_framebuffer(MemoryRegion *mr) >-{ >- framebuffer = mr; >-} >- >-void xen_hvm_modified_memory(ram_addr_t start, ram_addr_t length) >-{ >- unsigned target_page_bits = qemu_target_page_bits(); >- int page_size = qemu_target_page_size(); >- int page_mask = -page_size; >- >- if (unlikely(xen_in_migration)) { >- int rc; >- ram_addr_t start_pfn, nb_pages; >- >- start = xen_phys_offset_to_gaddr(start, length, page_mask); >- >- if (length == 0) { >- length = page_size; >- } >- start_pfn = start >> target_page_bits; >- nb_pages = ((start + length + page_size - 1) >> target_page_bits) >- - start_pfn; >- rc = xen_modified_memory(xen_domid, start_pfn, nb_pages); >- if (rc) { >- fprintf(stderr, >- "%s failed for "RAM_ADDR_FMT" ("RAM_ADDR_FMT"): %i, %s\n", >- __func__, start, nb_pages, errno, strerror(errno)); >- } >- } >-} >- >-void qmp_xen_set_global_dirty_log(bool enable, Error **errp) >-{ >- if (enable) { >- memory_global_dirty_log_start(GLOBAL_DIRTY_MIGRATION); >- } else { >- memory_global_dirty_log_stop(GLOBAL_DIRTY_MIGRATION); >- } >-} >- >-void xen_arch_set_memory(XenIOState *state, MemoryRegionSection *section, >- bool add) >-{ >- unsigned target_page_bits = qemu_target_page_bits(); >- int page_size = qemu_target_page_size(); >- int page_mask = -page_size; >- hwaddr start_addr = section->offset_within_address_space; >- ram_addr_t size = int128_get64(section->size); >- bool log_dirty = memory_region_is_logging(section->mr, DIRTY_MEMORY_VGA); >- hvmmem_type_t mem_type; >- >- if (!memory_region_is_ram(section->mr)) { >- return; >- } >- >- if (log_dirty != add) { >- return; >- } >- >- trace_xen_client_set_memory(start_addr, size, log_dirty); >- >- start_addr &= page_mask; >- size = ROUND_UP(size, page_size); >- >- if (add) { >- if (!memory_region_is_rom(section->mr)) { >- xen_add_to_physmap(state, start_addr, size, >- section->mr, section->offset_within_region); >- } else { >- mem_type = HVMMEM_ram_ro; >- if (xen_set_mem_type(xen_domid, mem_type, >- start_addr >> target_page_bits, >- size >> target_page_bits)) { >- DPRINTF("xen_set_mem_type error, addr: "HWADDR_FMT_plx"\n", >- start_addr); >- } >- } >- } else { >- if (xen_remove_from_physmap(state, start_addr, size) < 0) { >- DPRINTF("physmapping does not exist at "HWADDR_FMT_plx"\n", start_addr); >- } >- } >-} >- > void xen_arch_handle_ioreq(XenIOState *state, ioreq_t *req) > { > switch (req->type) { >diff --git a/hw/i386/xen/meson.build b/hw/i386/xen/meson.build >index 3f0df8bc07..d38759cfe4 100644 >--- a/hw/i386/xen/meson.build >+++ b/hw/i386/xen/meson.build >@@ -1,6 +1,7 @@ > i386_ss.add(when: 'CONFIG_XEN', if_true: files( > 'xen_apic.c', > 'xen_pvdevice.c', >+ 'xen-hvm-common.c', > )) > i386_ss.add(when: ['CONFIG_XEN', xen], if_true: files( > 'xen-hvm.c', >-- >2.41.0 > > Reviewed-by: Manos Pitsidianakis From xen-devel-bounces@lists.xenproject.org Thu Mar 07 12:03:59 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 12:03:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689834.1075183 (Exim 4.92) (envelope-from ) id 1riCTf-00088j-GB; Thu, 07 Mar 2024 12:03:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689834.1075183; Thu, 07 Mar 2024 12:03:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riCTf-00088c-Bu; Thu, 07 Mar 2024 12:03:59 +0000 Received: by outflank-mailman (input) for mailman id 689834; Thu, 07 Mar 2024 12:03:57 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riCTd-00088N-EQ for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 12:03:57 +0000 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id c60a19c0-dc7a-11ee-afda-a90da7624cb6; Thu, 07 Mar 2024 13:03:56 +0100 (CET) Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 182798BF31; Thu, 7 Mar 2024 10:51:34 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id D8A7D136BA; Thu, 7 Mar 2024 10:51:33 +0000 (UTC) Received: from dovecot-director2.suse.de ([10.150.64.162]) by imap1.dmz-prg2.suse.org with ESMTPSA id soIxMzWc6WXQLgAAD6G6ig (envelope-from ); Thu, 07 Mar 2024 10:51:33 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c60a19c0-dc7a-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1709808694; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=tuHwPybvE5hMjpcpcZlE8QFw92PG+ODqE3BCZxcVPZ8=; b=uK7g144909ntXCZe4DHTvzk1PG0eWIVbb8MjdAdo1M1vWsVHVosHEzTt/2OBiRksAgKSvz J6mCJxXmziCe3sSwcvM3nWBNyHvMxvTYSSJllSnoWu3zRkQbojbNa7I0B3JO4GMTPIGLdl K/pn6aRNAU6AGwNjo/TNRu1rYEwkGiM= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1709808694; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=tuHwPybvE5hMjpcpcZlE8QFw92PG+ODqE3BCZxcVPZ8=; b=uK7g144909ntXCZe4DHTvzk1PG0eWIVbb8MjdAdo1M1vWsVHVosHEzTt/2OBiRksAgKSvz J6mCJxXmziCe3sSwcvM3nWBNyHvMxvTYSSJllSnoWu3zRkQbojbNa7I0B3JO4GMTPIGLdl K/pn6aRNAU6AGwNjo/TNRu1rYEwkGiM= Message-ID: <86f363fb-80f4-45cd-aa1f-58b504546422@suse.com> Date: Thu, 7 Mar 2024 11:51:33 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] tools/9pfsd: Fix build error caused by strerror_r() Content-Language: en-US To: Henry Wang , xen-devel@lists.xenproject.org Cc: Wei Liu , Anthony PERARD , Jan Beulich References: <20240307103847.3710737-1-xin.wang2@amd.com> From: Juergen Gross Autocrypt: addr=jgross@suse.com; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw== In-Reply-To: <20240307103847.3710737-1-xin.wang2@amd.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------wA8tX3hB8D6JIW2l19BzxTUy" Authentication-Results: smtp-out1.suse.de; none X-Spam-Level: X-Spam-Score: -1.97 X-Spamd-Result: default: False [-1.97 / 50.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; XM_UA_NO_VERSION(0.01)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; BAYES_HAM(-0.00)[19.31%]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; HAS_ATTACHMENT(0.00)[]; NEURAL_HAM_LONG(-0.79)[-0.788]; MIME_BASE64_TEXT_BOGUS(1.00)[]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; NEURAL_HAM_SHORT(-0.19)[-0.969]; MIME_BASE64_TEXT(0.10)[]; SIGNED_PGP(-2.00)[]; FUZZY_BLOCKED(0.00)[rspamd.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_UNKNOWN(0.10)[application/pgp-keys] X-Spam-Flag: NO This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------wA8tX3hB8D6JIW2l19BzxTUy Content-Type: multipart/mixed; boundary="------------d40fObzGrHuDArI6nykm1dbX"; protected-headers="v1" From: Juergen Gross To: Henry Wang , xen-devel@lists.xenproject.org Cc: Wei Liu , Anthony PERARD , Jan Beulich Message-ID: <86f363fb-80f4-45cd-aa1f-58b504546422@suse.com> Subject: Re: [PATCH v2] tools/9pfsd: Fix build error caused by strerror_r() References: <20240307103847.3710737-1-xin.wang2@amd.com> In-Reply-To: <20240307103847.3710737-1-xin.wang2@amd.com> Autocrypt-Gossip: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs= --------------d40fObzGrHuDArI6nykm1dbX Content-Type: multipart/mixed; boundary="------------wjN1uD6UfRUCE5TjQkRJqiak" --------------wjN1uD6UfRUCE5TjQkRJqiak Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMDcuMDMuMjQgMTE6MzgsIEhlbnJ5IFdhbmcgd3JvdGU6DQo+IEJlbG93IGVycm9yIGNh biBiZSBzZWVuIHdoZW4gZG9pbmcgWW9jdG8gYnVpbGQgb2YgdGhlIHRvb2xzdGFjazoNCj4g DQo+IHwgaW8uYzogSW4gZnVuY3Rpb24gJ3A5X2Vycm9yJzoNCj4gfCBpby5jOjY4NDo1OiBl cnJvcjogaWdub3JpbmcgcmV0dXJuIHZhbHVlIG9mICdzdHJlcnJvcl9yJyBkZWNsYXJlZA0K PiAgICB3aXRoIGF0dHJpYnV0ZSAnd2Fybl91bnVzZWRfcmVzdWx0JyBbLVdlcnJvcj11bnVz ZWQtcmVzdWx0XQ0KPiB8ICAgNjg0IHwgICAgIHN0cmVycm9yX3IoZXJyLCByaW5nLT5idWZm ZXIsIHJpbmctPnJpbmdfc2l6ZSk7DQo+IHwgICAgICAgfCAgICAgXn5+fn5+fn5+fn5+fn5+ fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fg0KPiB8IGNjMTogYWxsIHdhcm5pbmdz IGJlaW5nIHRyZWF0ZWQgYXMgZXJyb3JzDQo+IA0KPiBGaXggdGhlIGJ1aWxkIGJ5IHVzaW5n IHN0cmVycm9yKCkgdG8gcmVwbGFjZSBzdHJlcnJvcl9yKCkuIFNpbmNlDQo+IHN0cmVycm9y KCkgaXMgdGhyZWFkLXVuc2FmZSwgdXNlIGEgc2VwYXJhdGUgbG9jYWwgbXV0ZXggdG8gcHJv dGVjdA0KPiB0aGUgYWN0aW9uLiBUaGUgc3RlcHMgd291bGQgdGhlbiBiZWNvbWU6IEFjcXVp cmUgdGhlIG11dGV4IGZpcnN0LA0KPiBpbnZva2Ugc3RyZXJyb3IoKSwgY29weSB0aGUgc3Ry aW5nIGZyb20gc3RyZXJyb3IoKSB0byB0aGUgZGVzaWduYXRlZA0KPiBidWZmZXIgYW5kIHRo ZW4gZHJvcCB0aGUgbXV0ZXguDQo+IA0KPiBTaWduZWQtb2ZmLWJ5OiBIZW5yeSBXYW5nIDx4 aW4ud2FuZzJAYW1kLmNvbT4NCg0KTWF5YmUgYWRkIGEgIkZpeGVzOiIgdGFnIHJlZmVyZW5j aW5nIEphbidzIHBhdGNoPw0KDQpBbmQgSSB3b3VsZCBleHBhbmQgb24gdGhlIHJlYXNvbiB3 aHkgeW91IGFyZSB1c2luZyBzdHJlcnJvcigpIGluc3RlYWQgb2YganVzdA0KY2hlY2tpbmcg dGhlIHN0cmVycm9yX3IoKSByZXN1bHQuIFNvbWV0aGluZyBsaWtlOg0KDQogICBVc2luZyBz dHJlcnJvcl9yKCkgd2l0aG91dCBzcGVjaWFsIGNhc2luZyBkaWZmZXJlbnQgYnVpbGQNCiAg IGVudmlyb25tZW50cyBpcyBpbXBvc3NpYmxlIGR1ZSB0byB0aGUgZGlmZmVyZW50IHJldHVy biB0eXBlcw0KICAgKGludCB2cyBjaGFyICopIGRlcGVuZGluZyBvbiB0aGUgZW52aXJvbm1l bnQuIEFzIHA5X2Vycm9yKCkNCiAgIGlzIG5vdCBvbiBhIHBlcmZvcm1hbmNlIGNyaXRpY2Fs IHBhdGgsIHVzaW5nIHN0cmVycm9yKCkgd2l0aCBhDQogICBtdXRleCBvdWdodCB0byBiZSBm aW5lLg0KDQo+IC0tLQ0KPiAgIHRvb2xzLzlwZnNkL2lvLmMgfCAxMiArKysrKysrKysrKy0N Cj4gICAxIGZpbGUgY2hhbmdlZCwgMTEgaW5zZXJ0aW9ucygrKSwgMSBkZWxldGlvbigtKQ0K PiANCj4gZGlmZiAtLWdpdCBhL3Rvb2xzLzlwZnNkL2lvLmMgYi90b29scy85cGZzZC9pby5j DQo+IGluZGV4IGFkYjg4N2M3ZDkuLjJiODBjOTUyOGQgMTAwNjQ0DQo+IC0tLSBhL3Rvb2xz LzlwZnNkL2lvLmMNCj4gKysrIGIvdG9vbHMvOXBmc2QvaW8uYw0KPiBAQCAtNjgwLDggKzY4 MCwxOCBAQCBzdGF0aWMgYm9vbCBuYW1lX29rKGNvbnN0IGNoYXIgKnN0cikNCj4gICBzdGF0 aWMgdm9pZCBwOV9lcnJvcihzdHJ1Y3QgcmluZyAqcmluZywgdWludDE2X3QgdGFnLCB1aW50 MzJfdCBlcnIpDQo+ICAgew0KPiAgICAgICB1bnNpZ25lZCBpbnQgZXJyb2ZmOw0KPiArICAg IHN0YXRpYyBwdGhyZWFkX211dGV4X3QgbXV0ZXggPSBQVEhSRUFEX01VVEVYX0lOSVRJQUxJ WkVSOw0KPiArICAgIGNoYXIgKnN0cmVycm9yX3N0cjsNCj4gKyAgICBSSU5HX0lEWCBzdHJl cnJvcl9sZW4gPSAwLCBjb3B5X2xlbiA9IDA7DQoNCkkgd291bGRuJ3QgdXNlIFJJTkdfSURY IGZvciB0aGUgdHlwZSwgYnV0IHVuc2lnbmVkIGludC4NCg0KPiArDQo+ICsgICAgcHRocmVh ZF9tdXRleF9sb2NrKCZtdXRleCk7DQo+ICsgICAgc3RyZXJyb3Jfc3RyID0gc3RyZXJyb3Io ZXJyKTsNCj4gKyAgICBzdHJlcnJvcl9sZW4gPSBzdHJsZW4oc3RyZXJyb3Jfc3RyKSArIDE7 DQo+ICsgICAgY29weV9sZW4gPSBtaW4oc3RyZXJyb3JfbGVuLCByaW5nLT5yaW5nX3NpemUp Ow0KPiArICAgIG1lbWNweShyaW5nLT5idWZmZXIsIHN0cmVycm9yX3N0ciwgY29weV9sZW4p Ow0KPiArICAgICgoY2hhciAqKShyaW5nLT5idWZmZXIpKVtjb3B5X2xlbiAtIDFdID0gJ1ww JzsNCj4gKyAgICBwdGhyZWFkX211dGV4X3VubG9jaygmbXV0ZXgpOw0KPiAgIA0KPiAtICAg IHN0cmVycm9yX3IoZXJyLCByaW5nLT5idWZmZXIsIHJpbmctPnJpbmdfc2l6ZSk7DQo+ICAg ICAgIGVycm9mZiA9IGFkZF9zdHJpbmcocmluZywgcmluZy0+YnVmZmVyLCBzdHJsZW4ocmlu Zy0+YnVmZmVyKSk7DQo+ICAgICAgIGZpbGxfYnVmZmVyKHJpbmcsIFA5X0NNRF9FUlJPUiwg dGFnLCAiU1UiLA0KPiAgICAgICAgICAgICAgICAgICBlcnJvZmYgIT0gfjAgPyByaW5nLT5z dHIgKyBlcnJvZmYgOiAiY2Fubm90IGFsbG9jYXRlIG1lbW9yeSIsDQoNCg0KSnVlcmdlbg0K --------------wjN1uD6UfRUCE5TjQkRJqiak Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2 kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i 1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u +6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4 RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7 8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK 7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/ Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK /1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1 c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4 k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu 5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6 AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr 0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD 534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422 bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay 7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib 4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX kt+z4drzFUyEjLM1vVvIMjkUoJs=3D =3DeeAB -----END PGP PUBLIC KEY BLOCK----- --------------wjN1uD6UfRUCE5TjQkRJqiak-- --------------d40fObzGrHuDArI6nykm1dbX-- --------------wA8tX3hB8D6JIW2l19BzxTUy Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmXpnDUFAwAAAAAACgkQsN6d1ii/Ey9M swf/QFHHnG1cUUY7PuOYtKPuYw4fF0gZeJ8C3HRys916f2kl0itopGkPGBIRm2zqXG4lSZ97nJPP GnR4rEsrO/+vHKhdQqcOnFK6TxSbcPrEWYQYGc2AsRnY/yYnohJnuOiubPWcbH55a2dxUCBT3mmT /o976Ao4ya2QrrMk5UHkeRlV3rMpgHtCp7GO/IMp/LBpDc+P2Um1gOfp59j6nqO+l0xRqLDzCKEt YGQum7HNwsCjIfkfjRWFTvyUUtSBFU85kEl67eP1CeyID5WpDuOgjJlEKmpDSH826tEqb7Ww4egJ tSoc7oaZ6XbqvwksSmcdpexVIuo3+Mj8TFv1NjBSvQ== =Wl0M -----END PGP SIGNATURE----- --------------wA8tX3hB8D6JIW2l19BzxTUy-- From xen-devel-bounces@lists.xenproject.org Thu Mar 07 12:07:37 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 12:07:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689843.1075193 (Exim 4.92) (envelope-from ) id 1riCX5-0000ed-Tr; Thu, 07 Mar 2024 12:07:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689843.1075193; Thu, 07 Mar 2024 12:07:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riCX5-0000eW-Qd; Thu, 07 Mar 2024 12:07:31 +0000 Received: by outflank-mailman (input) for mailman id 689843; Thu, 07 Mar 2024 12:07:30 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riCX4-0000eQ-16 for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 12:07:30 +0000 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 44338b7c-dc7b-11ee-a1ee-f123f15fe8a2; Thu, 07 Mar 2024 13:07:28 +0100 (CET) Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id D65E28CB76; Thu, 7 Mar 2024 11:24:07 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 9883D12FC5; Thu, 7 Mar 2024 11:24:07 +0000 (UTC) Received: from dovecot-director2.suse.de ([10.150.64.162]) by imap1.dmz-prg2.suse.org with ESMTPSA id 6HQyI9ej6WXTNgAAD6G6ig (envelope-from ); Thu, 07 Mar 2024 11:24:07 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 44338b7c-dc7b-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1709810649; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=5cqPX6N+wH9KRuiabw7On6KIb8naTRpV4GZkL3aitYg=; b=lOZdJF2PXSuKW392+rZRs4LrXuTEaHsQKMFQXUx1wA4WOLESogRtJH+G3Zl2kWthQD0TI5 XIqp4TpL39knYbP5ni+jTuiqK7DFbeCtQcqq0WklUyniFpq88el4i3pWCSEUADUC3/izOv pNd6NB79s4SEqh/iWGWNQ2bW9xf7F5Q= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1709810647; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=5cqPX6N+wH9KRuiabw7On6KIb8naTRpV4GZkL3aitYg=; b=AOURSnBendg5+AmvYTPseHZmci+i7C+9T56oNoWDS5Swi8xSmVUAiiiMEtDoEyOsIvGfVl VaJuMa7WcxDs211UxXldrKIL1bG+0d6HSdb60uE6bkcp6lv2iWgY1gBWog4mKrV/y+mBpG 3IX0Y8LcUSX/ZdIZEQrb+b0WKU88cp4= Message-ID: <833782ae-9699-492a-9d18-2644873c97c7@suse.com> Date: Thu, 7 Mar 2024 12:24:06 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] tools/9pfsd: Fix build error caused by strerror_r() Content-Language: en-US To: Henry Wang , xen-devel@lists.xenproject.org Cc: Wei Liu , Anthony PERARD , Jan Beulich References: <20240307103847.3710737-1-xin.wang2@amd.com> From: Juergen Gross Autocrypt: addr=jgross@suse.com; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw== In-Reply-To: <20240307103847.3710737-1-xin.wang2@amd.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------GzcNd0SKpWreGVsULyqzyjZh" X-Spam-Level: Authentication-Results: smtp-out1.suse.de; none X-Spamd-Result: default: False [-1.06 / 50.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; XM_UA_NO_VERSION(0.01)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; BAYES_HAM(-0.07)[62.34%]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; HAS_ATTACHMENT(0.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; MIME_BASE64_TEXT(0.10)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[amd.com:email]; SIGNED_PGP(-2.00)[]; FUZZY_BLOCKED(0.00)[rspamd.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_UNKNOWN(0.10)[application/pgp-keys] X-Spam-Score: -1.06 X-Spam-Flag: NO This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------GzcNd0SKpWreGVsULyqzyjZh Content-Type: multipart/mixed; boundary="------------FSFWKrraijj73rt1GB8oAUQR"; protected-headers="v1" From: Juergen Gross To: Henry Wang , xen-devel@lists.xenproject.org Cc: Wei Liu , Anthony PERARD , Jan Beulich Message-ID: <833782ae-9699-492a-9d18-2644873c97c7@suse.com> Subject: Re: [PATCH v2] tools/9pfsd: Fix build error caused by strerror_r() References: <20240307103847.3710737-1-xin.wang2@amd.com> In-Reply-To: <20240307103847.3710737-1-xin.wang2@amd.com> Autocrypt-Gossip: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs= --------------FSFWKrraijj73rt1GB8oAUQR Content-Type: multipart/mixed; boundary="------------0pZQSts9OenJZFun8DJNO4JD" --------------0pZQSts9OenJZFun8DJNO4JD Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMDcuMDMuMjQgMTE6MzgsIEhlbnJ5IFdhbmcgd3JvdGU6DQo+IEJlbG93IGVycm9yIGNh biBiZSBzZWVuIHdoZW4gZG9pbmcgWW9jdG8gYnVpbGQgb2YgdGhlIHRvb2xzdGFjazoNCj4g DQo+IHwgaW8uYzogSW4gZnVuY3Rpb24gJ3A5X2Vycm9yJzoNCj4gfCBpby5jOjY4NDo1OiBl cnJvcjogaWdub3JpbmcgcmV0dXJuIHZhbHVlIG9mICdzdHJlcnJvcl9yJyBkZWNsYXJlZA0K PiAgICB3aXRoIGF0dHJpYnV0ZSAnd2Fybl91bnVzZWRfcmVzdWx0JyBbLVdlcnJvcj11bnVz ZWQtcmVzdWx0XQ0KPiB8ICAgNjg0IHwgICAgIHN0cmVycm9yX3IoZXJyLCByaW5nLT5idWZm ZXIsIHJpbmctPnJpbmdfc2l6ZSk7DQo+IHwgICAgICAgfCAgICAgXn5+fn5+fn5+fn5+fn5+ fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fg0KPiB8IGNjMTogYWxsIHdhcm5pbmdz IGJlaW5nIHRyZWF0ZWQgYXMgZXJyb3JzDQo+IA0KPiBGaXggdGhlIGJ1aWxkIGJ5IHVzaW5n IHN0cmVycm9yKCkgdG8gcmVwbGFjZSBzdHJlcnJvcl9yKCkuIFNpbmNlDQo+IHN0cmVycm9y KCkgaXMgdGhyZWFkLXVuc2FmZSwgdXNlIGEgc2VwYXJhdGUgbG9jYWwgbXV0ZXggdG8gcHJv dGVjdA0KPiB0aGUgYWN0aW9uLiBUaGUgc3RlcHMgd291bGQgdGhlbiBiZWNvbWU6IEFjcXVp cmUgdGhlIG11dGV4IGZpcnN0LA0KPiBpbnZva2Ugc3RyZXJyb3IoKSwgY29weSB0aGUgc3Ry aW5nIGZyb20gc3RyZXJyb3IoKSB0byB0aGUgZGVzaWduYXRlZA0KPiBidWZmZXIgYW5kIHRo ZW4gZHJvcCB0aGUgbXV0ZXguDQo+IA0KPiBTaWduZWQtb2ZmLWJ5OiBIZW5yeSBXYW5nIDx4 aW4ud2FuZzJAYW1kLmNvbT4NCj4gLS0tDQo+ICAgdG9vbHMvOXBmc2QvaW8uYyB8IDEyICsr KysrKysrKysrLQ0KPiAgIDEgZmlsZSBjaGFuZ2VkLCAxMSBpbnNlcnRpb25zKCspLCAxIGRl bGV0aW9uKC0pDQo+IA0KPiBkaWZmIC0tZ2l0IGEvdG9vbHMvOXBmc2QvaW8uYyBiL3Rvb2xz LzlwZnNkL2lvLmMNCj4gaW5kZXggYWRiODg3YzdkOS4uMmI4MGM5NTI4ZCAxMDA2NDQNCj4g LS0tIGEvdG9vbHMvOXBmc2QvaW8uYw0KPiArKysgYi90b29scy85cGZzZC9pby5jDQo+IEBA IC02ODAsOCArNjgwLDE4IEBAIHN0YXRpYyBib29sIG5hbWVfb2soY29uc3QgY2hhciAqc3Ry KQ0KPiAgIHN0YXRpYyB2b2lkIHA5X2Vycm9yKHN0cnVjdCByaW5nICpyaW5nLCB1aW50MTZf dCB0YWcsIHVpbnQzMl90IGVycikNCj4gICB7DQo+ICAgICAgIHVuc2lnbmVkIGludCBlcnJv ZmY7DQo+ICsgICAgc3RhdGljIHB0aHJlYWRfbXV0ZXhfdCBtdXRleCA9IFBUSFJFQURfTVVU RVhfSU5JVElBTElaRVI7DQo+ICsgICAgY2hhciAqc3RyZXJyb3Jfc3RyOw0KPiArICAgIFJJ TkdfSURYIHN0cmVycm9yX2xlbiA9IDAsIGNvcHlfbGVuID0gMDsNCj4gKw0KPiArICAgIHB0 aHJlYWRfbXV0ZXhfbG9jaygmbXV0ZXgpOw0KPiArICAgIHN0cmVycm9yX3N0ciA9IHN0cmVy cm9yKGVycik7DQo+ICsgICAgc3RyZXJyb3JfbGVuID0gc3RybGVuKHN0cmVycm9yX3N0cikg KyAxOw0KPiArICAgIGNvcHlfbGVuID0gbWluKHN0cmVycm9yX2xlbiwgcmluZy0+cmluZ19z aXplKTsNCg0KSG1tLCBJIHRoaW5rIHdlIGV2ZW4gX25lZWRfIHRvIGNhcCB0aGUgc3RyaW5n IGVhcmxpZXIuDQoNCkEgc3RyaW5nIGluIHRoZSA5cGZzIHByb3RvY29sIGlzIGEgMiBieXRl IGxlbmd0aCBmaWVsZCBwbHVzIHRoZSBzdHJpbmcuDQpJbiBjYXNlIG9mIGEgcmluZyBsYXJn ZXIgdGhhbiA2NTUzNSBieXRlcyB0aGlzIHdvdWxkIG1lYW4gdGhlIHJlc3VsdCBvZg0Kc3Ry ZXJyb3IoKSBjb3VsZCAoaW4gdGhlb3J5KSBvdmVyZmxvdyB0aGUgc3RyaW5nIGZvcm1hdCBv ZiA5cGZzLg0KDQpBZGRpdGlvbmFsbHkgdGhlIHN0cmluZyBzaG91bGQgYmUgYSBfc2hvcnRf IGRlc2NyaXB0aW9uIG9mIHRoZSBlcnJvciwgc28NCkknZCBsaWtlIHRvIHN1Z2dlc3QgdG8g bm90IHVzZSByaW5nX3NpemUgYXMgdGhlIHVwcGVyIGJvdW5kIGZvciB0aGUgc3RyaW5nDQps ZW5ndGgsIGJ1dCBhIGZpeGVkIHZhbHVlIGRlZmluZWQgYXMgYSBtYWNybywgZS5nLjoNCg0K I2RlZmluZSBNQVhfRVJSU1RSX0xFTiA4MA0KDQoNCkp1ZXJnZW4NCg== --------------0pZQSts9OenJZFun8DJNO4JD Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2 kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i 1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u +6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4 RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7 8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK 7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/ Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK /1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1 c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4 k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu 5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6 AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr 0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD 534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422 bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay 7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib 4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX kt+z4drzFUyEjLM1vVvIMjkUoJs=3D =3DeeAB -----END PGP PUBLIC KEY BLOCK----- --------------0pZQSts9OenJZFun8DJNO4JD-- --------------FSFWKrraijj73rt1GB8oAUQR-- --------------GzcNd0SKpWreGVsULyqzyjZh Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmXpo9cFAwAAAAAACgkQsN6d1ii/Ey91 Cgf9FnPKd6RXvkNEMfSIgi8vMgYxA5pjzh3zvHk2UB3N0sET7R4P5ehZiCaBBB4eXXozj+J4qKyw ucLVJYS0CnXvQ0aDys5oto62oKnHdUJcIZHcZNpYD8/qRyH51gFGUy1MQARqWLRsr7jGrW99O2xG j4MW8Mk030ZsA4u1CiI4O6JJD9pORfJ8xPsB03q46eay5pTRSCckHdnXx4BmQOjr8flTZUxgZfDF mm7Ok9sllGD2AdC4vJVwrXtJbqU5Y9plpAdeWaD3bupb4u5vBEEYIWFlUEh2FDBNe1ESLM3t2k58 seCuPxDKTZlhxUsICETvwxI2SRbw6YgivUYJfCYM6A== =zZBy -----END PGP SIGNATURE----- --------------GzcNd0SKpWreGVsULyqzyjZh-- From xen-devel-bounces@lists.xenproject.org Thu Mar 07 12:10:59 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 12:10:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689846.1075203 (Exim 4.92) (envelope-from ) id 1riCaQ-00029Z-Fa; Thu, 07 Mar 2024 12:10:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689846.1075203; Thu, 07 Mar 2024 12:10:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riCaQ-00029S-CJ; Thu, 07 Mar 2024 12:10:58 +0000 Received: by outflank-mailman (input) for mailman id 689846; Thu, 07 Mar 2024 12:10:57 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riCaO-00029K-BX for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 12:10:56 +0000 Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [2a00:1450:4864:20::333]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id bf351c79-dc7b-11ee-afda-a90da7624cb6; Thu, 07 Mar 2024 13:10:54 +0100 (CET) Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-41312890df0so2511245e9.2 for ; Thu, 07 Mar 2024 04:10:54 -0800 (PST) Received: from meli.delivery (adsl-101.109.242.224.tellas.gr. [109.242.224.101]) by smtp.gmail.com with ESMTPSA id q8-20020a05600c46c800b00413099fc248sm2535514wmo.3.2024.03.07.04.10.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Mar 2024 04:10:53 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: bf351c79-dc7b-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1709813454; x=1710418254; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:message-id:in-reply-to :references:user-agent:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to; bh=VChtDWH+qLD7Mp6r4cSwpKorizYtCui+hljfjCqt8Mo=; b=hmEng2M8YRHA6WzBkl843CA+w/RvaFKEKyy4IX4Z2vsFpSZeDtTmcVnCdvn8GhW8pW 6Olh2C+sucqEhNUzkk/7nGphStKRfaB3B5T9YojvYm9AB3RgL+ahwri/eS1TE7smihVc j0CuA2+5MQbzYd14dDvRSC7SDah54zrKlMTTQIy42w6wDxAimU7t4yEZgrAT4BrykVZO hQsZygDZiKryD39RF0Mqv1muTOFbOHLUq9CXOVoP3ZdjYfTSqvbfA1fKuKCyG9UV/ItU I2sjOW7+XnS3ambnjtE1yZjYk+/H1p8m0PntbILzoafCuWMC9HFVqpgZKSvPPxqeDghX 4q7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709813454; x=1710418254; h=content-transfer-encoding:mime-version:message-id:in-reply-to :references:user-agent:subject:cc:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=VChtDWH+qLD7Mp6r4cSwpKorizYtCui+hljfjCqt8Mo=; b=eNjsRzElmPK+UJIC/m2V7IdSvV9FEwqerQ7CVTktpZMQweMjY7PALk/ullg3Cz2TFt k6BUzAnFC3WJf/o2y3zd7I7gSG4F7SiJJplz0KfzkA7SUfk8abZ1yYAEOyrxR+aZY7js QLRSqCS3Vc/m+euznhGk3XoAEolqqeclkfwKj4INUCDK20UvJrBuznCxLLtQGZ3lQt33 YxWKlwuhNXHg07PCRiEPDA0tITx5AshuA0QLueRVCve1jRswYf9wcJwUPOLHDs8TqJQp KCY9uIucWhaJ0U53LQOKDpX+fEy3SEP9snNtLSwd7jrbeqhBwi0aLdvQAcqLX3hryUF8 1t9Q== X-Forwarded-Encrypted: i=1; AJvYcCU1F4lhe+BciKInP+kEb2yyntwKnpliM5QYTqL10tBTX2XZH+zwh71JU+z2QEpI11C6K5QpEL7iTk20g1/h4STy4kaueenk20JS7ecFkxQ= X-Gm-Message-State: AOJu0YxTZF8NALWOmKz/u1TUbBZxw3nttvZgBzIfi55jrXS19vUivKvQ 97z74zMrB3pvdf4v08IOcs/XHfTq7xms2rIHHqvx8kXd+DMBb8z+FyMFpUe+J+c= X-Google-Smtp-Source: AGHT+IG5z5IjVvtvOh5lFpn2L/IBKC3TeobA4WgnMiVUeb4EgtJ2NdEDpXSSrkWV2Mm0pxt9sAidoA== X-Received: by 2002:a05:600c:4f51:b0:413:7f:dc4c with SMTP id m17-20020a05600c4f5100b00413007fdc4cmr2350715wmq.5.1709813453708; Thu, 07 Mar 2024 04:10:53 -0800 (PST) Date: Thu, 07 Mar 2024 14:03:13 +0200 From: Manos Pitsidianakis To: qemu-devel@nongnu.org, Philippe Mathieu-Daud=?UTF-8?B?w6kg?= Cc: Anthony Perard , Paul Durrant , David Woodhouse , Thomas Huth , qemu-arm@nongnu.org, Stefano Stabellini , Paolo Bonzini , Alex Benn=?UTF-8?B?w6k=?= e , xen-devel@lists.xenproject.org, Philippe Mathieu-Daud=?UTF-8?B?w6kg?=, Peter Maydell , "Michael S. Tsirkin" , Marcel Apfelbaum , Richard Henderson , Eduardo Habkost Bcc: Subject: Re: [RFC PATCH-for-9.0 8/9] hw/xen/hvm: Merge xen-hvm-common.c files User-Agent: meli 0.8.5-rc.3 References: <20231114163123.74888-1-philmd@linaro.org> <20231114163123.74888-9-philmd@linaro.org> In-Reply-To: <20231114163123.74888-9-philmd@linaro.org> Message-ID: <9z8i3.ib1i46u337uu@linaro.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8; format=flowed On Tue, 14 Nov 2023 18:31, Philippe Mathieu-Daudé wrote: >hw/i386/xen/xen-hvm-common.c content is target agnostic, >and should be common to all targets. Merge both files. >Remove the now unnecessary xen_register_framebuffer() stub. > >ARM targets now inherit the common xen_memory_listener. > >Signed-off-by: Philippe Mathieu-Daudé >--- > hw/arm/xen_arm.c | 24 -- > hw/i386/xen/xen-hvm-common.c | 473 ----------------------------------- > hw/xen/xen-hvm-common.c | 458 +++++++++++++++++++++++++++++++++ > stubs/xen-hw-stub.c | 4 - > hw/i386/xen/meson.build | 1 - > 5 files changed, 458 insertions(+), 502 deletions(-) > delete mode 100644 hw/i386/xen/xen-hvm-common.c > >diff --git a/hw/arm/xen_arm.c b/hw/arm/xen_arm.c >index 39dcd74d07..0ead84c9e1 100644 >--- a/hw/arm/xen_arm.c >+++ b/hw/arm/xen_arm.c >@@ -38,17 +38,6 @@ > #define TYPE_XEN_ARM MACHINE_TYPE_NAME("xenpvh") > OBJECT_DECLARE_SIMPLE_TYPE(XenArmState, XEN_ARM) > >-const MemoryListener xen_memory_listener = { >- .region_add = xen_region_add, >- .region_del = xen_region_del, >- .log_start = NULL, >- .log_stop = NULL, >- .log_sync = NULL, >- .log_global_start = NULL, >- .log_global_stop = NULL, >- .priority = MEMORY_LISTENER_PRIORITY_ACCEL, >-}; >- > struct XenArmState { > /*< private >*/ > MachineState parent; >@@ -136,19 +125,6 @@ void xen_arch_handle_ioreq(XenIOState *state, ioreq_t *req) > return; > } > >-void xen_arch_set_memory(XenIOState *state, MemoryRegionSection *section, >- bool add) >-{ >-} >- >-void xen_hvm_modified_memory(ram_addr_t start, ram_addr_t length) >-{ >-} >- >-void qmp_xen_set_global_dirty_log(bool enable, Error **errp) >-{ >-} I think this is not correct, Xen on arm does not do migration and does not handle memory (the hardware does). We should keep the stubs here. And not merge the physmapping/dirty mapping of i386 to the common code. .. which I guess means xen_memory_listener cannot be shared either. Unless it's non-const and i386 code sets the log_* callback fields on init. >- > #ifdef CONFIG_TPM > static void xen_enable_tpm(XenArmState *xam) > { >diff --git a/hw/i386/xen/xen-hvm-common.c b/hw/i386/xen/xen-hvm-common.c >deleted file mode 100644 >index e8ef0e0c94..0000000000 >--- a/hw/i386/xen/xen-hvm-common.c >+++ /dev/null >@@ -1,473 +0,0 @@ >-/* >- * Copyright (C) 2010 Citrix Ltd. >- * >- * This work is licensed under the terms of the GNU GPL, version 2. See >- * the COPYING file in the top-level directory. >- * >- * Contributions after 2012-01-13 are licensed under the terms of the >- * GNU GPL, version 2 or (at your option) any later version. >- */ >- >-#include "qemu/osdep.h" >-#include "qemu/range.h" >-#include "qapi/qapi-commands-migration.h" >-#include "exec/target_page.h" >-#include "hw/xen/xen-hvm-common.h" >-#include "trace.h" >- >-static MemoryRegion *framebuffer; >-static bool xen_in_migration; >- >-static QLIST_HEAD(, XenPhysmap) xen_physmap; >-static const XenPhysmap *log_for_dirtybit; >-/* Buffer used by xen_sync_dirty_bitmap */ >-static unsigned long *dirty_bitmap; >- >-static XenPhysmap *get_physmapping(hwaddr start_addr, ram_addr_t size, >- int page_mask) >-{ >- XenPhysmap *physmap = NULL; >- >- start_addr &= -page_mask; >- >- QLIST_FOREACH(physmap, &xen_physmap, list) { >- if (range_covers_byte(physmap->start_addr, physmap->size, start_addr)) { >- return physmap; >- } >- } >- return NULL; >-} >- >-static hwaddr xen_phys_offset_to_gaddr(hwaddr phys_offset, ram_addr_t size, >- int page_mask) >-{ >- hwaddr addr = phys_offset & -page_mask; >- XenPhysmap *physmap = NULL; >- >- QLIST_FOREACH(physmap, &xen_physmap, list) { >- if (range_covers_byte(physmap->phys_offset, physmap->size, addr)) { >- return physmap->start_addr + (phys_offset - physmap->phys_offset); >- } >- } >- >- return phys_offset; >-} >- >-#ifdef XEN_COMPAT_PHYSMAP >-static int xen_save_physmap(XenIOState *state, XenPhysmap *physmap) >-{ >- char path[80], value[17]; >- >- snprintf(path, sizeof(path), >- "/local/domain/0/device-model/%d/physmap/%"PRIx64"/start_addr", >- xen_domid, (uint64_t)physmap->phys_offset); >- snprintf(value, sizeof(value), "%"PRIx64, (uint64_t)physmap->start_addr); >- if (!xs_write(state->xenstore, 0, path, value, strlen(value))) { >- return -1; >- } >- snprintf(path, sizeof(path), >- "/local/domain/0/device-model/%d/physmap/%"PRIx64"/size", >- xen_domid, (uint64_t)physmap->phys_offset); >- snprintf(value, sizeof(value), "%"PRIx64, (uint64_t)physmap->size); >- if (!xs_write(state->xenstore, 0, path, value, strlen(value))) { >- return -1; >- } >- if (physmap->name) { >- snprintf(path, sizeof(path), >- "/local/domain/0/device-model/%d/physmap/%"PRIx64"/name", >- xen_domid, (uint64_t)physmap->phys_offset); >- if (!xs_write(state->xenstore, 0, path, >- physmap->name, strlen(physmap->name))) { >- return -1; >- } >- } >- return 0; >-} >-#else >-static int xen_save_physmap(XenIOState *state, XenPhysmap *physmap) >-{ >- return 0; >-} >-#endif >- >-static int xen_add_to_physmap(XenIOState *state, >- hwaddr start_addr, >- ram_addr_t size, >- MemoryRegion *mr, >- hwaddr offset_within_region) >-{ >- unsigned target_page_bits = qemu_target_page_bits(); >- int page_size = qemu_target_page_size(); >- int page_mask = -page_size; >- unsigned long nr_pages; >- int rc = 0; >- XenPhysmap *physmap = NULL; >- hwaddr pfn, start_gpfn; >- hwaddr phys_offset = memory_region_get_ram_addr(mr); >- const char *mr_name; >- >- if (get_physmapping(start_addr, size, page_mask)) { >- return 0; >- } >- if (size <= 0) { >- return -1; >- } >- >- /* Xen can only handle a single dirty log region for now and we want >- * the linear framebuffer to be that region. >- * Avoid tracking any regions that is not videoram and avoid tracking >- * the legacy vga region. */ >- if (mr == framebuffer && start_addr > 0xbffff) { >- goto go_physmap; >- } >- return -1; >- >-go_physmap: >- DPRINTF("mapping vram to %"HWADDR_PRIx" - %"HWADDR_PRIx"\n", >- start_addr, start_addr + size); >- >- mr_name = memory_region_name(mr); >- >- physmap = g_new(XenPhysmap, 1); >- >- physmap->start_addr = start_addr; >- physmap->size = size; >- physmap->name = mr_name; >- physmap->phys_offset = phys_offset; >- >- QLIST_INSERT_HEAD(&xen_physmap, physmap, list); >- >- if (runstate_check(RUN_STATE_INMIGRATE)) { >- /* Now when we have a physmap entry we can replace a dummy mapping with >- * a real one of guest foreign memory. */ >- uint8_t *p = xen_replace_cache_entry(phys_offset, start_addr, size); >- assert(p && p == memory_region_get_ram_ptr(mr)); >- >- return 0; >- } >- >- pfn = phys_offset >> target_page_bits; >- start_gpfn = start_addr >> target_page_bits; >- nr_pages = size >> target_page_bits; >- rc = xendevicemodel_relocate_memory(xen_dmod, xen_domid, nr_pages, pfn, >- start_gpfn); >- if (rc) { >- int saved_errno = errno; >- >- error_report("relocate_memory %lu pages from GFN %"HWADDR_PRIx >- " to GFN %"HWADDR_PRIx" failed: %s", >- nr_pages, pfn, start_gpfn, strerror(saved_errno)); >- errno = saved_errno; >- return -1; >- } >- >- rc = xendevicemodel_pin_memory_cacheattr(xen_dmod, xen_domid, >- start_addr >> target_page_bits, >- (start_addr + size - 1) >> target_page_bits, >- XEN_DOMCTL_MEM_CACHEATTR_WB); >- if (rc) { >- error_report("pin_memory_cacheattr failed: %s", strerror(errno)); >- } >- return xen_save_physmap(state, physmap); >-} >- >-static int xen_remove_from_physmap(XenIOState *state, >- hwaddr start_addr, >- ram_addr_t size) >-{ >- unsigned target_page_bits = qemu_target_page_bits(); >- int page_size = qemu_target_page_size(); >- int page_mask = -page_size; >- int rc = 0; >- XenPhysmap *physmap = NULL; >- hwaddr phys_offset = 0; >- >- physmap = get_physmapping(start_addr, size, page_mask); >- if (physmap == NULL) { >- return -1; >- } >- >- phys_offset = physmap->phys_offset; >- size = physmap->size; >- >- DPRINTF("unmapping vram to %"HWADDR_PRIx" - %"HWADDR_PRIx", at " >- "%"HWADDR_PRIx"\n", start_addr, start_addr + size, phys_offset); >- >- size >>= target_page_bits; >- start_addr >>= target_page_bits; >- phys_offset >>= target_page_bits; >- rc = xendevicemodel_relocate_memory(xen_dmod, xen_domid, size, start_addr, >- phys_offset); >- if (rc) { >- int saved_errno = errno; >- >- error_report("relocate_memory "RAM_ADDR_FMT" pages" >- " from GFN %"HWADDR_PRIx >- " to GFN %"HWADDR_PRIx" failed: %s", >- size, start_addr, phys_offset, strerror(saved_errno)); >- errno = saved_errno; >- return -1; >- } >- >- QLIST_REMOVE(physmap, list); >- if (log_for_dirtybit == physmap) { >- log_for_dirtybit = NULL; >- g_free(dirty_bitmap); >- dirty_bitmap = NULL; >- } >- g_free(physmap); >- >- return 0; >-} >- >-static void xen_sync_dirty_bitmap(XenIOState *state, >- hwaddr start_addr, >- ram_addr_t size) >-{ >- unsigned target_page_bits = qemu_target_page_bits(); >- int page_size = qemu_target_page_size(); >- int page_mask = -page_size; >- hwaddr npages = size >> target_page_bits; >- const int width = sizeof(unsigned long) * 8; >- size_t bitmap_size = DIV_ROUND_UP(npages, width); >- int rc, i, j; >- const XenPhysmap *physmap = NULL; >- >- physmap = get_physmapping(start_addr, size, page_mask); >- if (physmap == NULL) { >- /* not handled */ >- return; >- } >- >- if (log_for_dirtybit == NULL) { >- log_for_dirtybit = physmap; >- dirty_bitmap = g_new(unsigned long, bitmap_size); >- } else if (log_for_dirtybit != physmap) { >- /* Only one range for dirty bitmap can be tracked. */ >- return; >- } >- >- rc = xen_track_dirty_vram(xen_domid, start_addr >> target_page_bits, >- npages, dirty_bitmap); >- if (rc < 0) { >-#ifndef ENODATA >-#define ENODATA ENOENT >-#endif >- if (errno == ENODATA) { >- memory_region_set_dirty(framebuffer, 0, size); >- DPRINTF("xen: track_dirty_vram failed (0x" HWADDR_FMT_plx >- ", 0x" HWADDR_FMT_plx "): %s\n", >- start_addr, start_addr + size, strerror(errno)); >- } >- return; >- } >- >- for (i = 0; i < bitmap_size; i++) { >- unsigned long map = dirty_bitmap[i]; >- while (map != 0) { >- j = ctzl(map); >- map &= ~(1ul << j); >- memory_region_set_dirty(framebuffer, >- (i * width + j) * page_size, >- page_size); >- }; >- } >-} >- >-static void xen_log_start(MemoryListener *listener, >- MemoryRegionSection *section, >- int old, int new) >-{ >- XenIOState *state = container_of(listener, XenIOState, memory_listener); >- >- if (new & ~old & (1 << DIRTY_MEMORY_VGA)) { >- xen_sync_dirty_bitmap(state, section->offset_within_address_space, >- int128_get64(section->size)); >- } >-} >- >-static void xen_log_stop(MemoryListener *listener, MemoryRegionSection *section, >- int old, int new) >-{ >- if (old & ~new & (1 << DIRTY_MEMORY_VGA)) { >- log_for_dirtybit = NULL; >- g_free(dirty_bitmap); >- dirty_bitmap = NULL; >- /* Disable dirty bit tracking */ >- xen_track_dirty_vram(xen_domid, 0, 0, NULL); >- } >-} >- >-static void xen_log_sync(MemoryListener *listener, MemoryRegionSection *section) >-{ >- XenIOState *state = container_of(listener, XenIOState, memory_listener); >- >- xen_sync_dirty_bitmap(state, section->offset_within_address_space, >- int128_get64(section->size)); >-} >- >-static void xen_log_global_start(MemoryListener *listener) >-{ >- if (xen_enabled()) { >- xen_in_migration = true; >- } >-} >- >-static void xen_log_global_stop(MemoryListener *listener) >-{ >- xen_in_migration = false; >-} >- >-const MemoryListener xen_memory_listener = { >- .name = "xen-memory", >- .region_add = xen_region_add, >- .region_del = xen_region_del, >- .log_start = xen_log_start, >- .log_stop = xen_log_stop, >- .log_sync = xen_log_sync, >- .log_global_start = xen_log_global_start, >- .log_global_stop = xen_log_global_stop, >- .priority = MEMORY_LISTENER_PRIORITY_ACCEL, >-}; >- >-#ifdef XEN_COMPAT_PHYSMAP >-void xen_read_physmap(XenIOState *state) >-{ >- XenPhysmap *physmap = NULL; >- unsigned int len, num, i; >- char path[80], *value = NULL; >- char **entries = NULL; >- >- QLIST_INIT(&xen_physmap); >- >- snprintf(path, sizeof(path), >- "/local/domain/0/device-model/%d/physmap", xen_domid); >- entries = xs_directory(state->xenstore, 0, path, &num); >- if (entries == NULL) >- return; >- >- for (i = 0; i < num; i++) { >- physmap = g_new(XenPhysmap, 1); >- physmap->phys_offset = strtoull(entries[i], NULL, 16); >- snprintf(path, sizeof(path), >- "/local/domain/0/device-model/%d/physmap/%s/start_addr", >- xen_domid, entries[i]); >- value = xs_read(state->xenstore, 0, path, &len); >- if (value == NULL) { >- g_free(physmap); >- continue; >- } >- physmap->start_addr = strtoull(value, NULL, 16); >- free(value); >- >- snprintf(path, sizeof(path), >- "/local/domain/0/device-model/%d/physmap/%s/size", >- xen_domid, entries[i]); >- value = xs_read(state->xenstore, 0, path, &len); >- if (value == NULL) { >- g_free(physmap); >- continue; >- } >- physmap->size = strtoull(value, NULL, 16); >- free(value); >- >- snprintf(path, sizeof(path), >- "/local/domain/0/device-model/%d/physmap/%s/name", >- xen_domid, entries[i]); >- physmap->name = xs_read(state->xenstore, 0, path, &len); >- >- QLIST_INSERT_HEAD(&xen_physmap, physmap, list); >- } >- free(entries); >-} >-#else >-void xen_read_physmap(XenIOState *state) >-{ >- QLIST_INIT(&xen_physmap); >-} >-#endif >- >-void xen_register_framebuffer(MemoryRegion *mr) >-{ >- framebuffer = mr; >-} >- >-void xen_hvm_modified_memory(ram_addr_t start, ram_addr_t length) >-{ >- unsigned target_page_bits = qemu_target_page_bits(); >- int page_size = qemu_target_page_size(); >- int page_mask = -page_size; >- >- if (unlikely(xen_in_migration)) { >- int rc; >- ram_addr_t start_pfn, nb_pages; >- >- start = xen_phys_offset_to_gaddr(start, length, page_mask); >- >- if (length == 0) { >- length = page_size; >- } >- start_pfn = start >> target_page_bits; >- nb_pages = ((start + length + page_size - 1) >> target_page_bits) >- - start_pfn; >- rc = xen_modified_memory(xen_domid, start_pfn, nb_pages); >- if (rc) { >- fprintf(stderr, >- "%s failed for "RAM_ADDR_FMT" ("RAM_ADDR_FMT"): %i, %s\n", >- __func__, start, nb_pages, errno, strerror(errno)); >- } >- } >-} >- >-void qmp_xen_set_global_dirty_log(bool enable, Error **errp) >-{ >- if (enable) { >- memory_global_dirty_log_start(GLOBAL_DIRTY_MIGRATION); >- } else { >- memory_global_dirty_log_stop(GLOBAL_DIRTY_MIGRATION); >- } >-} >- >-void xen_arch_set_memory(XenIOState *state, MemoryRegionSection *section, >- bool add) >-{ >- unsigned target_page_bits = qemu_target_page_bits(); >- int page_size = qemu_target_page_size(); >- int page_mask = -page_size; >- hwaddr start_addr = section->offset_within_address_space; >- ram_addr_t size = int128_get64(section->size); >- bool log_dirty = memory_region_is_logging(section->mr, DIRTY_MEMORY_VGA); >- hvmmem_type_t mem_type; >- >- if (!memory_region_is_ram(section->mr)) { >- return; >- } >- >- if (log_dirty != add) { >- return; >- } >- >- trace_xen_client_set_memory(start_addr, size, log_dirty); >- >- start_addr &= page_mask; >- size = ROUND_UP(size, page_size); >- >- if (add) { >- if (!memory_region_is_rom(section->mr)) { >- xen_add_to_physmap(state, start_addr, size, >- section->mr, section->offset_within_region); >- } else { >- mem_type = HVMMEM_ram_ro; >- if (xen_set_mem_type(xen_domid, mem_type, >- start_addr >> target_page_bits, >- size >> target_page_bits)) { >- DPRINTF("xen_set_mem_type error, addr: "HWADDR_FMT_plx"\n", >- start_addr); >- } >- } >- } else { >- if (xen_remove_from_physmap(state, start_addr, size) < 0) { >- DPRINTF("physmapping does not exist at "HWADDR_FMT_plx"\n", start_addr); >- } >- } >-} >diff --git a/hw/xen/xen-hvm-common.c b/hw/xen/xen-hvm-common.c >index 73fa2c414d..50ce45effc 100644 >--- a/hw/xen/xen-hvm-common.c >+++ b/hw/xen/xen-hvm-common.c >@@ -1,7 +1,9 @@ > #include "qemu/osdep.h" > #include "qemu/units.h" > #include "qemu/bitops.h" >+#include "qemu/range.h" > #include "qapi/error.h" >+#include "qapi/qapi-commands-migration.h" > #include "exec/target_page.h" > #include "trace.h" > >@@ -11,6 +13,462 @@ > #include "hw/boards.h" > > MemoryRegion xen_memory; >+static MemoryRegion *framebuffer; >+static bool xen_in_migration; >+ >+static QLIST_HEAD(, XenPhysmap) xen_physmap; >+static const XenPhysmap *log_for_dirtybit; >+/* Buffer used by xen_sync_dirty_bitmap */ >+static unsigned long *dirty_bitmap; >+ >+static XenPhysmap *get_physmapping(hwaddr start_addr, ram_addr_t size, >+ int page_mask) >+{ >+ XenPhysmap *physmap = NULL; >+ >+ start_addr &= -page_mask; >+ >+ QLIST_FOREACH(physmap, &xen_physmap, list) { >+ if (range_covers_byte(physmap->start_addr, physmap->size, start_addr)) { >+ return physmap; >+ } >+ } >+ return NULL; >+} >+ >+static hwaddr xen_phys_offset_to_gaddr(hwaddr phys_offset, ram_addr_t size, >+ int page_mask) >+{ >+ hwaddr addr = phys_offset & -page_mask; >+ XenPhysmap *physmap = NULL; >+ >+ QLIST_FOREACH(physmap, &xen_physmap, list) { >+ if (range_covers_byte(physmap->phys_offset, physmap->size, addr)) { >+ return physmap->start_addr + (phys_offset - physmap->phys_offset); >+ } >+ } >+ >+ return phys_offset; >+} >+ >+#ifdef XEN_COMPAT_PHYSMAP >+static int xen_save_physmap(XenIOState *state, XenPhysmap *physmap) >+{ >+ char path[80], value[17]; >+ >+ snprintf(path, sizeof(path), >+ "/local/domain/0/device-model/%d/physmap/%"PRIx64"/start_addr", >+ xen_domid, (uint64_t)physmap->phys_offset); >+ snprintf(value, sizeof(value), "%"PRIx64, (uint64_t)physmap->start_addr); >+ if (!xs_write(state->xenstore, 0, path, value, strlen(value))) { >+ return -1; >+ } >+ snprintf(path, sizeof(path), >+ "/local/domain/0/device-model/%d/physmap/%"PRIx64"/size", >+ xen_domid, (uint64_t)physmap->phys_offset); >+ snprintf(value, sizeof(value), "%"PRIx64, (uint64_t)physmap->size); >+ if (!xs_write(state->xenstore, 0, path, value, strlen(value))) { >+ return -1; >+ } >+ if (physmap->name) { >+ snprintf(path, sizeof(path), >+ "/local/domain/0/device-model/%d/physmap/%"PRIx64"/name", >+ xen_domid, (uint64_t)physmap->phys_offset); >+ if (!xs_write(state->xenstore, 0, path, >+ physmap->name, strlen(physmap->name))) { >+ return -1; >+ } >+ } >+ return 0; >+} >+#else >+static int xen_save_physmap(XenIOState *state, XenPhysmap *physmap) >+{ >+ return 0; >+} >+#endif >+ >+static int xen_add_to_physmap(XenIOState *state, >+ hwaddr start_addr, >+ ram_addr_t size, >+ MemoryRegion *mr, >+ hwaddr offset_within_region) >+{ >+ unsigned target_page_bits = qemu_target_page_bits(); >+ int page_size = qemu_target_page_size(); >+ int page_mask = -page_size; >+ unsigned long nr_pages; >+ int rc = 0; >+ XenPhysmap *physmap = NULL; >+ hwaddr pfn, start_gpfn; >+ hwaddr phys_offset = memory_region_get_ram_addr(mr); >+ const char *mr_name; >+ >+ if (get_physmapping(start_addr, size, page_mask)) { >+ return 0; >+ } >+ if (size <= 0) { >+ return -1; >+ } >+ >+ /* Xen can only handle a single dirty log region for now and we want >+ * the linear framebuffer to be that region. >+ * Avoid tracking any regions that is not videoram and avoid tracking >+ * the legacy vga region. */ >+ if (mr == framebuffer && start_addr > 0xbffff) { >+ goto go_physmap; >+ } >+ return -1; >+ >+go_physmap: >+ DPRINTF("mapping vram to %"HWADDR_PRIx" - %"HWADDR_PRIx"\n", >+ start_addr, start_addr + size); >+ >+ mr_name = memory_region_name(mr); >+ >+ physmap = g_new(XenPhysmap, 1); >+ >+ physmap->start_addr = start_addr; >+ physmap->size = size; >+ physmap->name = mr_name; >+ physmap->phys_offset = phys_offset; >+ >+ QLIST_INSERT_HEAD(&xen_physmap, physmap, list); >+ >+ if (runstate_check(RUN_STATE_INMIGRATE)) { >+ /* Now when we have a physmap entry we can replace a dummy mapping with >+ * a real one of guest foreign memory. */ >+ uint8_t *p = xen_replace_cache_entry(phys_offset, start_addr, size); >+ assert(p && p == memory_region_get_ram_ptr(mr)); >+ >+ return 0; >+ } >+ >+ pfn = phys_offset >> target_page_bits; >+ start_gpfn = start_addr >> target_page_bits; >+ nr_pages = size >> target_page_bits; >+ rc = xendevicemodel_relocate_memory(xen_dmod, xen_domid, nr_pages, pfn, >+ start_gpfn); >+ if (rc) { >+ int saved_errno = errno; >+ >+ error_report("relocate_memory %lu pages from GFN %"HWADDR_PRIx >+ " to GFN %"HWADDR_PRIx" failed: %s", >+ nr_pages, pfn, start_gpfn, strerror(saved_errno)); >+ errno = saved_errno; >+ return -1; >+ } >+ >+ rc = xendevicemodel_pin_memory_cacheattr(xen_dmod, xen_domid, >+ start_addr >> target_page_bits, >+ (start_addr + size - 1) >> target_page_bits, >+ XEN_DOMCTL_MEM_CACHEATTR_WB); >+ if (rc) { >+ error_report("pin_memory_cacheattr failed: %s", strerror(errno)); >+ } >+ return xen_save_physmap(state, physmap); >+} >+ >+static int xen_remove_from_physmap(XenIOState *state, >+ hwaddr start_addr, >+ ram_addr_t size) >+{ >+ unsigned target_page_bits = qemu_target_page_bits(); >+ int page_size = qemu_target_page_size(); >+ int page_mask = -page_size; >+ int rc = 0; >+ XenPhysmap *physmap = NULL; >+ hwaddr phys_offset = 0; >+ >+ physmap = get_physmapping(start_addr, size, page_mask); >+ if (physmap == NULL) { >+ return -1; >+ } >+ >+ phys_offset = physmap->phys_offset; >+ size = physmap->size; >+ >+ DPRINTF("unmapping vram to %"HWADDR_PRIx" - %"HWADDR_PRIx", at " >+ "%"HWADDR_PRIx"\n", start_addr, start_addr + size, phys_offset); >+ >+ size >>= target_page_bits; >+ start_addr >>= target_page_bits; >+ phys_offset >>= target_page_bits; >+ rc = xendevicemodel_relocate_memory(xen_dmod, xen_domid, size, start_addr, >+ phys_offset); >+ if (rc) { >+ int saved_errno = errno; >+ >+ error_report("relocate_memory "RAM_ADDR_FMT" pages" >+ " from GFN %"HWADDR_PRIx >+ " to GFN %"HWADDR_PRIx" failed: %s", >+ size, start_addr, phys_offset, strerror(saved_errno)); >+ errno = saved_errno; >+ return -1; >+ } >+ >+ QLIST_REMOVE(physmap, list); >+ if (log_for_dirtybit == physmap) { >+ log_for_dirtybit = NULL; >+ g_free(dirty_bitmap); >+ dirty_bitmap = NULL; >+ } >+ g_free(physmap); >+ >+ return 0; >+} >+ >+static void xen_sync_dirty_bitmap(XenIOState *state, >+ hwaddr start_addr, >+ ram_addr_t size) >+{ >+ unsigned target_page_bits = qemu_target_page_bits(); >+ int page_size = qemu_target_page_size(); >+ int page_mask = -page_size; >+ hwaddr npages = size >> target_page_bits; >+ const int width = sizeof(unsigned long) * 8; >+ size_t bitmap_size = DIV_ROUND_UP(npages, width); >+ int rc, i, j; >+ const XenPhysmap *physmap = NULL; >+ >+ physmap = get_physmapping(start_addr, size, page_mask); >+ if (physmap == NULL) { >+ /* not handled */ >+ return; >+ } >+ >+ if (log_for_dirtybit == NULL) { >+ log_for_dirtybit = physmap; >+ dirty_bitmap = g_new(unsigned long, bitmap_size); >+ } else if (log_for_dirtybit != physmap) { >+ /* Only one range for dirty bitmap can be tracked. */ >+ return; >+ } >+ >+ rc = xen_track_dirty_vram(xen_domid, start_addr >> target_page_bits, >+ npages, dirty_bitmap); >+ if (rc < 0) { >+#ifndef ENODATA >+#define ENODATA ENOENT >+#endif >+ if (errno == ENODATA) { >+ memory_region_set_dirty(framebuffer, 0, size); >+ DPRINTF("xen: track_dirty_vram failed (0x" HWADDR_FMT_plx >+ ", 0x" HWADDR_FMT_plx "): %s\n", >+ start_addr, start_addr + size, strerror(errno)); >+ } >+ return; >+ } >+ >+ for (i = 0; i < bitmap_size; i++) { >+ unsigned long map = dirty_bitmap[i]; >+ while (map != 0) { >+ j = ctzl(map); >+ map &= ~(1ul << j); >+ memory_region_set_dirty(framebuffer, >+ (i * width + j) * page_size, >+ page_size); >+ }; >+ } >+} >+ >+static void xen_log_start(MemoryListener *listener, >+ MemoryRegionSection *section, >+ int old, int new) >+{ >+ XenIOState *state = container_of(listener, XenIOState, memory_listener); >+ >+ if (new & ~old & (1 << DIRTY_MEMORY_VGA)) { >+ xen_sync_dirty_bitmap(state, section->offset_within_address_space, >+ int128_get64(section->size)); >+ } >+} >+ >+static void xen_log_stop(MemoryListener *listener, MemoryRegionSection *section, >+ int old, int new) >+{ >+ if (old & ~new & (1 << DIRTY_MEMORY_VGA)) { >+ log_for_dirtybit = NULL; >+ g_free(dirty_bitmap); >+ dirty_bitmap = NULL; >+ /* Disable dirty bit tracking */ >+ xen_track_dirty_vram(xen_domid, 0, 0, NULL); >+ } >+} >+ >+static void xen_log_sync(MemoryListener *listener, MemoryRegionSection *section) >+{ >+ XenIOState *state = container_of(listener, XenIOState, memory_listener); >+ >+ xen_sync_dirty_bitmap(state, section->offset_within_address_space, >+ int128_get64(section->size)); >+} >+ >+static void xen_log_global_start(MemoryListener *listener) >+{ >+ if (xen_enabled()) { >+ xen_in_migration = true; >+ } >+} >+ >+static void xen_log_global_stop(MemoryListener *listener) >+{ >+ xen_in_migration = false; >+} >+ >+const MemoryListener xen_memory_listener = { >+ .name = "xen-memory", >+ .region_add = xen_region_add, >+ .region_del = xen_region_del, >+ .log_start = xen_log_start, >+ .log_stop = xen_log_stop, >+ .log_sync = xen_log_sync, >+ .log_global_start = xen_log_global_start, >+ .log_global_stop = xen_log_global_stop, >+ .priority = MEMORY_LISTENER_PRIORITY_ACCEL, >+}; >+ >+#ifdef XEN_COMPAT_PHYSMAP >+void xen_read_physmap(XenIOState *state) >+{ >+ XenPhysmap *physmap = NULL; >+ unsigned int len, num, i; >+ char path[80], *value = NULL; >+ char **entries = NULL; >+ >+ QLIST_INIT(&xen_physmap); >+ >+ snprintf(path, sizeof(path), >+ "/local/domain/0/device-model/%d/physmap", xen_domid); >+ entries = xs_directory(state->xenstore, 0, path, &num); >+ if (entries == NULL) >+ return; >+ >+ for (i = 0; i < num; i++) { >+ physmap = g_new(XenPhysmap, 1); >+ physmap->phys_offset = strtoull(entries[i], NULL, 16); >+ snprintf(path, sizeof(path), >+ "/local/domain/0/device-model/%d/physmap/%s/start_addr", >+ xen_domid, entries[i]); >+ value = xs_read(state->xenstore, 0, path, &len); >+ if (value == NULL) { >+ g_free(physmap); >+ continue; >+ } >+ physmap->start_addr = strtoull(value, NULL, 16); >+ free(value); >+ >+ snprintf(path, sizeof(path), >+ "/local/domain/0/device-model/%d/physmap/%s/size", >+ xen_domid, entries[i]); >+ value = xs_read(state->xenstore, 0, path, &len); >+ if (value == NULL) { >+ g_free(physmap); >+ continue; >+ } >+ physmap->size = strtoull(value, NULL, 16); >+ free(value); >+ >+ snprintf(path, sizeof(path), >+ "/local/domain/0/device-model/%d/physmap/%s/name", >+ xen_domid, entries[i]); >+ physmap->name = xs_read(state->xenstore, 0, path, &len); >+ >+ QLIST_INSERT_HEAD(&xen_physmap, physmap, list); >+ } >+ free(entries); >+} >+#else >+void xen_read_physmap(XenIOState *state) >+{ >+ QLIST_INIT(&xen_physmap); >+} >+#endif >+ >+void xen_register_framebuffer(MemoryRegion *mr) >+{ >+ framebuffer = mr; >+} >+ >+void xen_hvm_modified_memory(ram_addr_t start, ram_addr_t length) >+{ >+ unsigned target_page_bits = qemu_target_page_bits(); >+ int page_size = qemu_target_page_size(); >+ int page_mask = -page_size; >+ >+ if (unlikely(xen_in_migration)) { >+ int rc; >+ ram_addr_t start_pfn, nb_pages; >+ >+ start = xen_phys_offset_to_gaddr(start, length, page_mask); >+ >+ if (length == 0) { >+ length = page_size; >+ } >+ start_pfn = start >> target_page_bits; >+ nb_pages = ((start + length + page_size - 1) >> target_page_bits) >+ - start_pfn; >+ rc = xen_modified_memory(xen_domid, start_pfn, nb_pages); >+ if (rc) { >+ fprintf(stderr, >+ "%s failed for "RAM_ADDR_FMT" ("RAM_ADDR_FMT"): %i, %s\n", >+ __func__, start, nb_pages, errno, strerror(errno)); >+ } >+ } >+} >+ >+void qmp_xen_set_global_dirty_log(bool enable, Error **errp) >+{ >+ if (enable) { >+ memory_global_dirty_log_start(GLOBAL_DIRTY_MIGRATION); >+ } else { >+ memory_global_dirty_log_stop(GLOBAL_DIRTY_MIGRATION); >+ } >+} >+ >+void xen_arch_set_memory(XenIOState *state, MemoryRegionSection *section, >+ bool add) >+{ >+ unsigned target_page_bits = qemu_target_page_bits(); >+ int page_size = qemu_target_page_size(); >+ int page_mask = -page_size; >+ hwaddr start_addr = section->offset_within_address_space; >+ ram_addr_t size = int128_get64(section->size); >+ bool log_dirty = memory_region_is_logging(section->mr, DIRTY_MEMORY_VGA); >+ hvmmem_type_t mem_type; >+ >+ if (!memory_region_is_ram(section->mr)) { >+ return; >+ } >+ >+ if (log_dirty != add) { >+ return; >+ } >+ >+ trace_xen_client_set_memory(start_addr, size, log_dirty); >+ >+ start_addr &= page_mask; >+ size = ROUND_UP(size, page_size); >+ >+ if (add) { >+ if (!memory_region_is_rom(section->mr)) { >+ xen_add_to_physmap(state, start_addr, size, >+ section->mr, section->offset_within_region); >+ } else { >+ mem_type = HVMMEM_ram_ro; >+ if (xen_set_mem_type(xen_domid, mem_type, >+ start_addr >> target_page_bits, >+ size >> target_page_bits)) { >+ DPRINTF("xen_set_mem_type error, addr: "HWADDR_FMT_plx"\n", >+ start_addr); >+ } >+ } >+ } else { >+ if (xen_remove_from_physmap(state, start_addr, size) < 0) { >+ DPRINTF("physmapping does not exist at "HWADDR_FMT_plx"\n", start_addr); >+ } >+ } >+} > > void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, MemoryRegion *mr, > Error **errp) >diff --git a/stubs/xen-hw-stub.c b/stubs/xen-hw-stub.c >index 53c6a6f2a0..da8912f037 100644 >--- a/stubs/xen-hw-stub.c >+++ b/stubs/xen-hw-stub.c >@@ -13,7 +13,3 @@ int xen_is_pirq_msi(uint32_t msi_data) > { > return 0; > } >- >-void xen_register_framebuffer(MemoryRegion *mr) >-{ >-} >diff --git a/hw/i386/xen/meson.build b/hw/i386/xen/meson.build >index d38759cfe4..3f0df8bc07 100644 >--- a/hw/i386/xen/meson.build >+++ b/hw/i386/xen/meson.build >@@ -1,7 +1,6 @@ > i386_ss.add(when: 'CONFIG_XEN', if_true: files( > 'xen_apic.c', > 'xen_pvdevice.c', >- 'xen-hvm-common.c', > )) > i386_ss.add(when: ['CONFIG_XEN', xen], if_true: files( > 'xen-hvm.c', >-- >2.41.0 > > From xen-devel-bounces@lists.xenproject.org Thu Mar 07 12:13:18 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 12:13:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689850.1075213 (Exim 4.92) (envelope-from ) id 1riCcc-0003GL-Vr; Thu, 07 Mar 2024 12:13:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689850.1075213; Thu, 07 Mar 2024 12:13:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riCcc-0003GE-So; Thu, 07 Mar 2024 12:13:14 +0000 Received: by outflank-mailman (input) for mailman id 689850; Thu, 07 Mar 2024 12:13:14 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riCcb-0003DH-VX for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 12:13:13 +0000 Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [2a00:1450:4864:20::42a]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 11d6f9cf-dc7c-11ee-afda-a90da7624cb6; Thu, 07 Mar 2024 13:13:13 +0100 (CET) Received: by mail-wr1-x42a.google.com with SMTP id ffacd0b85a97d-33e162b1b71so739944f8f.1 for ; Thu, 07 Mar 2024 04:13:13 -0800 (PST) Received: from meli.delivery (adsl-101.37.6.0.tellas.gr. [37.6.0.101]) by smtp.gmail.com with ESMTPSA id v7-20020a5d59c7000000b0033e475940fasm7826319wry.66.2024.03.07.04.13.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Mar 2024 04:13:12 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 11d6f9cf-dc7c-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1709813592; x=1710418392; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:message-id:in-reply-to :references:user-agent:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to; bh=9jKcNU8mtddf0xD96048JENdNgxkV5RZUTuB2JvZ3Dk=; b=mtBeJ2gwxTs0RibJDQAgXBAdt/WjVGPAxSAElc6Kx0S96Zi2KkmewX5388FNMQSWJG zolYazeJEUqKgFcVdwq1guhbJJmIfX3j8dHtonpgFnBI0IE0aDYKIRO9d5mOuizvGROX pu/bUWfWd1kIJ2nn2eWEMhBtzXacoAwajz7wtBQBYHfT9KJOwmgz79Oz4FA5krChOSzA 292tSNYMEoCq8r6ZTGEOA0r1rKTTkNWI6AwPggSb2X3ZVIiyWhQBwerlE+iJPXNPiZkt 6aNJYgWENqWWbdNn2g16WZ8fht+MjYYAW1qlMIRRegNPXc76UgL56WuO2W+kIU2jdcxH RUsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709813592; x=1710418392; h=content-transfer-encoding:mime-version:message-id:in-reply-to :references:user-agent:subject:cc:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=9jKcNU8mtddf0xD96048JENdNgxkV5RZUTuB2JvZ3Dk=; b=LpjsnU8PtA7yD12/lH4MfW9RyXwrJy4pLihZaMaAPbrrq/Bt7jqfevKb7v5KnABaf/ YCPyS3xKNxUaMq1fS4gEZ7LX1KGbNg1fx2h8Fl0WVPJxJhjMPaBojMFZKTIgiJzTNhmf aTm7wXDfvYwifwAmc7yAd9h0sAUxdG0u2QM3gVfzhGu6fK4A8t1rvoJjdA3pYBcfs6CG X60LDJR4sSFYcj8JV9ik+quFgcG6BeSBIC4gkKzGUfQCzwXihf/xn4ek+0v70JbcyOMc 62XuqnzU0al04cmFRcwJqbL+gOa0mRt/oGy6r79VjbZIhHFLtkFACQaug6GzPIfBBM+d VhsA== X-Forwarded-Encrypted: i=1; AJvYcCXVzLe+D0VhVb8DO5dEQP3AcCyXDDk0qKrDPF8p3odeZcBhyjLdXg68ojB5aEYYF/Upv0+fmXtDLD7liIuUEoJmugSiMcp+XYBEM8QPk9M= X-Gm-Message-State: AOJu0YxgkVu5FADTSvoAdBKf9wn2cWx4Mlj0ZOXMjW9t8oi250HR0/VB pmBt394ZybeMY2sGxmvamspgrJ1WXmW2+wAUaNM0BzgaxQPBgtr/SjIViTrW6Ko= X-Google-Smtp-Source: AGHT+IEZSbHZqEkiGm8ptHFul1KfAi5rGSBCKI8+od071N4EROSygV23LA7LHPIPhTI5uqeuF0rSog== X-Received: by 2002:a5d:64af:0:b0:33e:5310:820f with SMTP id m15-20020a5d64af000000b0033e5310820fmr5236522wrp.67.1709813592443; Thu, 07 Mar 2024 04:13:12 -0800 (PST) Date: Thu, 07 Mar 2024 14:11:03 +0200 From: Manos Pitsidianakis To: qemu-arm@nongnu.org, Philippe Mathieu-Daud=?UTF-8?B?w6kg?=, qemu-devel@nongnu.org Cc: Anthony Perard , Paul Durrant , David Woodhouse , Thomas Huth , qemu-arm@nongnu.org, Stefano Stabellini , Paolo Bonzini , Alex Benn=?UTF-8?B?w6k=?= e , xen-devel@lists.xenproject.org, Philippe Mathieu-Daud=?UTF-8?B?w6kg?= Bcc: Subject: Re: [PATCH-for-9.0 9/9] hw/xen/hvm: Inline xen_arch_set_memory() User-Agent: meli 0.8.5-rc.3 References: <20231114163123.74888-1-philmd@linaro.org> <20231114163123.74888-10-philmd@linaro.org> In-Reply-To: <20231114163123.74888-10-philmd@linaro.org> Message-ID: <9z8lx.2kzq0em3zqbp@linaro.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8; format=flowed On Tue, 14 Nov 2023 18:31, Philippe Mathieu-Daudé wrote: >xen_arch_set_memory() is not arch-specific anymore. Being >called once, inline it in xen_set_memory(). > >Signed-off-by: Philippe Mathieu-Daudé >--- > include/hw/xen/xen-hvm-common.h | 3 - > hw/xen/xen-hvm-common.c | 104 ++++++++++++++++---------------- > 2 files changed, 51 insertions(+), 56 deletions(-) > >diff --git a/include/hw/xen/xen-hvm-common.h b/include/hw/xen/xen-hvm-common.h >index 536712dc83..a1b8a2783b 100644 >--- a/include/hw/xen/xen-hvm-common.h >+++ b/include/hw/xen/xen-hvm-common.h >@@ -99,8 +99,5 @@ void cpu_ioreq_pio(ioreq_t *req); > > void xen_read_physmap(XenIOState *state); > void xen_arch_handle_ioreq(XenIOState *state, ioreq_t *req); >-void xen_arch_set_memory(XenIOState *state, >- MemoryRegionSection *section, >- bool add); > > #endif /* HW_XEN_HVM_COMMON_H */ >diff --git a/hw/xen/xen-hvm-common.c b/hw/xen/xen-hvm-common.c >index 50ce45effc..789c6b4b7a 100644 >--- a/hw/xen/xen-hvm-common.c >+++ b/hw/xen/xen-hvm-common.c >@@ -426,50 +426,6 @@ void qmp_xen_set_global_dirty_log(bool enable, Error **errp) > } > } > >-void xen_arch_set_memory(XenIOState *state, MemoryRegionSection *section, >- bool add) >-{ >- unsigned target_page_bits = qemu_target_page_bits(); >- int page_size = qemu_target_page_size(); >- int page_mask = -page_size; >- hwaddr start_addr = section->offset_within_address_space; >- ram_addr_t size = int128_get64(section->size); >- bool log_dirty = memory_region_is_logging(section->mr, DIRTY_MEMORY_VGA); >- hvmmem_type_t mem_type; >- >- if (!memory_region_is_ram(section->mr)) { >- return; >- } >- >- if (log_dirty != add) { >- return; >- } >- >- trace_xen_client_set_memory(start_addr, size, log_dirty); >- >- start_addr &= page_mask; >- size = ROUND_UP(size, page_size); >- >- if (add) { >- if (!memory_region_is_rom(section->mr)) { >- xen_add_to_physmap(state, start_addr, size, >- section->mr, section->offset_within_region); >- } else { >- mem_type = HVMMEM_ram_ro; >- if (xen_set_mem_type(xen_domid, mem_type, >- start_addr >> target_page_bits, >- size >> target_page_bits)) { >- DPRINTF("xen_set_mem_type error, addr: "HWADDR_FMT_plx"\n", >- start_addr); >- } >- } >- } else { >- if (xen_remove_from_physmap(state, start_addr, size) < 0) { >- DPRINTF("physmapping does not exist at "HWADDR_FMT_plx"\n", start_addr); >- } >- } >-} >- > void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, MemoryRegion *mr, > Error **errp) > { >@@ -512,20 +468,62 @@ static void xen_set_memory(struct MemoryListener *listener, > bool add) > { > XenIOState *state = container_of(listener, XenIOState, memory_listener); >+ unsigned target_page_bits = qemu_target_page_bits(); >+ int page_size = qemu_target_page_size(); >+ int page_mask = -page_size; >+ hwaddr start_addr; >+ ram_addr_t size; >+ bool log_dirty; >+ hvmmem_type_t mem_type; >+ > > if (section->mr == &xen_memory) { > return; >- } else { >- if (add) { >- xen_map_memory_section(xen_domid, state->ioservid, >- section); >- } else { >- xen_unmap_memory_section(xen_domid, state->ioservid, >- section); >- } > } > >- xen_arch_set_memory(state, section, add); >+ if (add) { >+ xen_map_memory_section(xen_domid, state->ioservid, >+ section); >+ } else { >+ xen_unmap_memory_section(xen_domid, state->ioservid, >+ section); >+ } >+ >+ if (!memory_region_is_ram(section->mr)) { >+ return; >+ } >+ >+ log_dirty = memory_region_is_logging(section->mr, DIRTY_MEMORY_VGA); >+ >+ if (log_dirty != add) { >+ return; >+ } >+ >+ start_addr = section->offset_within_address_space; >+ size = int128_get64(section->size); >+ trace_xen_client_set_memory(start_addr, size, log_dirty); >+ >+ start_addr &= page_mask; >+ size = ROUND_UP(size, page_size); >+ >+ if (add) { >+ if (!memory_region_is_rom(section->mr)) { >+ xen_add_to_physmap(state, start_addr, size, >+ section->mr, section->offset_within_region); >+ } else { >+ mem_type = HVMMEM_ram_ro; >+ if (xen_set_mem_type(xen_domid, mem_type, >+ start_addr >> target_page_bits, >+ size >> target_page_bits)) { >+ DPRINTF("xen_set_mem_type error, addr: "HWADDR_FMT_plx"\n", >+ start_addr); >+ } >+ } >+ } else { >+ if (xen_remove_from_physmap(state, start_addr, size) < 0) { >+ DPRINTF("physmapping does not exist at "HWADDR_FMT_plx"\n", start_addr); >+ } >+ } > } > > void xen_region_add(MemoryListener *listener, >-- >2.41.0 > > Same observation as in previous patch, in Arm xen, qemu doesn't handle memory, it is only responsible for devices and their memory. From xen-devel-bounces@lists.xenproject.org Thu Mar 07 12:16:16 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 12:16:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689852.1075223 (Exim 4.92) (envelope-from ) id 1riCfX-0004BK-DL; Thu, 07 Mar 2024 12:16:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689852.1075223; Thu, 07 Mar 2024 12:16:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riCfX-0004BD-AL; Thu, 07 Mar 2024 12:16:15 +0000 Received: by outflank-mailman (input) for mailman id 689852; Thu, 07 Mar 2024 12:16:14 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riCfW-0004B7-2I for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 12:16:14 +0000 Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [2607:f8b0:4864:20::72f]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 7c5fd32c-dc7c-11ee-a1ee-f123f15fe8a2; Thu, 07 Mar 2024 13:16:12 +0100 (CET) Received: by mail-qk1-x72f.google.com with SMTP id af79cd13be357-7884bfc77acso3147185a.1 for ; Thu, 07 Mar 2024 04:16:12 -0800 (PST) Received: from [10.80.67.149] (default-46-102-197-194.interdsl.co.uk. [46.102.197.194]) by smtp.gmail.com with ESMTPSA id vv24-20020a05620a563800b0078821ab6668sm5015970qkn.34.2024.03.07.04.16.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Mar 2024 04:16:10 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 7c5fd32c-dc7c-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709813771; x=1710418571; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=YVs+BxVlwZMWWSv06IRPU7DiZaS7F6CzcUc0mkPOuaE=; b=hBu7ngQRrOlQW5HOw9MgtuePvECkg5CNCDn+MO5/3IfTIjj32WK8DPl0as5PiXmb92 SZROL4eDS/12C8VDM5m6kTDAqOJl4pkezhbUmhE2/9wA1yr5USNaXk1+iNgiVqHn4aKd DPXdrOe25XZm7xPpliXnVS/JfJEJysG2J1tfM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709813771; x=1710418571; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=YVs+BxVlwZMWWSv06IRPU7DiZaS7F6CzcUc0mkPOuaE=; b=JrHeI7FFCdXb6X6Wm8P/7MEuKgETs12AJyAHPL7hocLYG9SboKJgQmSK/CRSf38qFP zhm8iheDuYWz/CGNXcvaof6NlBv66puiKfoIWbGvyA2YyxlbfRx8xPyqLK38zQ62a+U5 sXzdNk7s6l+JlLSab0NCUiitCPb0IoAQmMpVgHC3POkQiS1YWXD2UvpFqX41vBQdM9U0 Pt+uYV75f8Uw7mMXnX2/2X8GqAa/nhfzytVleS/sWl8nrJ1faCPLGqBr+Jxhdxw5eprU 3nn6ZY69Z0JeSRPwuZhfq5yLVSrNUm1kXuxKxF0K7RxhiFBqz0AeSw0oI31hF+D9I78A tbuw== X-Forwarded-Encrypted: i=1; AJvYcCUG2LX8B8kovu7z4AUwxBHFWfkMd2dH+zWGZTh9kA5KqIxJaLUzETxhpk4a6oSkEhzXF6gJf51Tej3PtNkGk+1g/zmAiA7/radcV6ltJl8= X-Gm-Message-State: AOJu0Yzmz4qrPxaXXJ8dAmAbALOPRMXgCet3vHhAYSJz8GnS6IZYa1m7 T88Tru2FxW/FsumqrZSpPquIJr664BvlWQyFbULppikgYdvBRTxzh7Sz1ojcDJg= X-Google-Smtp-Source: AGHT+IFeNEeNc66TzOYEswILIHEvQI7AlVThlYIpa4WrWBrqu1nuDKfzsjqCG3Gk5j2cnUSK7p5O3Q== X-Received: by 2002:a05:620a:5373:b0:788:332d:6f7e with SMTP id op51-20020a05620a537300b00788332d6f7emr7875162qkn.39.1709813771111; Thu, 07 Mar 2024 04:16:11 -0800 (PST) Message-ID: Date: Thu, 7 Mar 2024 12:16:08 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/3] xen/virtual-region: Include rodata pointers Content-Language: en-GB To: Jan Beulich Cc: Konrad Rzeszutek Wilk , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel , Ross Lagerwall References: <20240305121121.3527944-1-andrew.cooper3@citrix.com> <20240305121121.3527944-3-andrew.cooper3@citrix.com> <87b82706-f538-4807-abaf-1e59cebd286b@suse.com> <82126c3a-0cde-452f-86aa-2571482f42aa@citrix.com> <76ce9dcf-8cac-44b3-9550-f516024bad6e@suse.com> <9e827057-9306-4a2a-8816-410661bf8892@citrix.com> <818ac202-5473-4638-b140-45272b1041ed@suse.com> From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <818ac202-5473-4638-b140-45272b1041ed@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 07/03/2024 11:58 am, Jan Beulich wrote: > On 07.03.2024 12:31, Andrew Cooper wrote: >> >> The thing called virtual_region already describes 6 ranges, and I'm >> adding a 7th. > Hmm, yes, in a way you're right. > >> It has been a module-ish description right from the very outset.  I >> don't think it is fair to describe this as an abuse at all. >> >> Is this going to satisfy the outstanding concerns? > Yes. And thank you for bearing with me. No problem.  I'm glad that we've come to an agreement. Ross? ~Andrew > > Jan > >> diff --git a/xen/include/xen/virtual_region.h >> b/xen/include/xen/virtual_region.h >> index d05362071135..9d150beb8a87 100644 >> --- a/xen/include/xen/virtual_region.h >> +++ b/xen/include/xen/virtual_region.h >> @@ -9,6 +9,12 @@ >>  #include >>  #include >>   >> +/* >> + * Despite it's name, this is module(ish) description. >> + * >> + * There's one region for .text/etc, one region for .init during boot only, >> + * and one region per livepatch. >> + */ >>  struct virtual_region >>  { >>      struct list_head list; >> >> ~Andrew From xen-devel-bounces@lists.xenproject.org Thu Mar 07 12:20:00 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 12:20:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689857.1075232 (Exim 4.92) (envelope-from ) id 1riCj4-000635-Tx; Thu, 07 Mar 2024 12:19:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689857.1075232; Thu, 07 Mar 2024 12:19:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riCj4-00062y-RN; Thu, 07 Mar 2024 12:19:54 +0000 Received: by outflank-mailman (input) for mailman id 689857; Thu, 07 Mar 2024 12:19:53 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riCj2-00061A-Uf for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 12:19:53 +0000 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on20601.outbound.protection.outlook.com [2a01:111:f403:2412::601]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id fe89621e-dc7c-11ee-afda-a90da7624cb6; Thu, 07 Mar 2024 13:19:51 +0100 (CET) Received: from PR3P251CA0028.EURP251.PROD.OUTLOOK.COM (2603:10a6:102:b5::19) by IA1PR12MB6044.namprd12.prod.outlook.com (2603:10b6:208:3d4::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.24; Thu, 7 Mar 2024 12:19:46 +0000 Received: from SN1PEPF0002BA4D.namprd03.prod.outlook.com (2603:10a6:102:b5:cafe::5d) by PR3P251CA0028.outlook.office365.com (2603:10a6:102:b5::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.26 via Frontend Transport; Thu, 7 Mar 2024 12:19:45 +0000 Received: from SATLEXMB03.amd.com (165.204.84.17) by SN1PEPF0002BA4D.mail.protection.outlook.com (10.167.242.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7362.11 via Frontend Transport; Thu, 7 Mar 2024 12:19:44 +0000 Received: from SATLEXMB06.amd.com (10.181.40.147) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 7 Mar 2024 06:19:43 -0600 Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB06.amd.com (10.181.40.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 7 Mar 2024 06:19:42 -0600 Received: from [172.31.100.92] (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend Transport; Thu, 7 Mar 2024 06:19:41 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fe89621e-dc7c-11ee-afda-a90da7624cb6 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RMY9hmf6oX/3ohGTUzigcPu/mg+by+CTQ7UM6KxUaU9tduuCqPePMxx43Ab7ByKuR9tfPgmwS6X3DCOOLIx/Im+7Ymq0vjqN3Zc6ETJMAuLbudRBl85C8IFBKYMuTCN8YsOpN1UCczcvdKAxfKzWN3gp2IfurH6jmLugj0L0OuYnKBP7NFHkmk9VG2zkVU2X65Y9FLdzZhvz1NCi9nvpjpCRdEAvax2ksZj1YWN7+dR35R+8Fc85ED9WWkCnW38oiIPeBZEF4pMILsHcch7fDHrezDY6dhQuP+AyHNE7KwLqC2Qdjj+VVTZSKL04ArED15bhHUHL/ILoaZ5u4Hw7Cg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=k0gcwpiaF4ajbC6fPVDyeiKq/4opE2bwQfKz6n50CTQ=; b=GRnLqLsltyQcv7FFQM4f2jasKXgG4JDcGuV8+FNkuOkvH0FTOoplhAWqYuyMI0LR4jhJOidiOyFhMoff1QzX1VOGW3GnnoxTfB8IuBplT1QCvsVML/j5rG+9N2shM9PxYYRk4FS3Z2K/5dpVFJ6eGKsmDjh9lw6ooI5mYZYMXALnSYe6XN46q7QUI5GrtxG9fiRCnXDcYHA1sPwJd9FgssQt6qR4MF37UM/5tfGhk0RGEx57Noza/uwyscquOjkIB00bfwUvp3oZVfwtDfNSpsjvJVJdp10p2ClQKRQiXj23EygUeWwAB1b9fOlIgHP837kq3FvQK1xiy8Ws3/tLmg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=k0gcwpiaF4ajbC6fPVDyeiKq/4opE2bwQfKz6n50CTQ=; b=h6T4MHdgoHGzxGa/MYZMEWY70IEe24by8t1FbDtuAIha0pk/nYi/TYS08aozUWgEL9EodsU5Q4/a4MFYCEdOTmAV7wqFMkTLwANVxDGg7TcR9RcFbtq8g4tp+EypGBGx2O0W0N53F+bejtJbsr2mO+XnlCd/mQ9h2PeoxQcYP5E= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C Message-ID: <87b4f7fc-29a8-4201-83c5-afb9169a222d@amd.com> Date: Thu, 7 Mar 2024 20:19:40 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] tools/9pfsd: Fix build error caused by strerror_r() To: Jan Beulich CC: Wei Liu , Anthony PERARD , "Juergen Gross" , References: <20240307103847.3710737-1-xin.wang2@amd.com> <8428e980-ac88-40bb-8334-d52deeb52bb0@suse.com> Content-Language: en-US From: Henry Wang In-Reply-To: <8428e980-ac88-40bb-8334-d52deeb52bb0@suse.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SN1PEPF0002BA4D:EE_|IA1PR12MB6044:EE_ X-MS-Office365-Filtering-Correlation-Id: 77a97465-f791-416f-1636-08dc3ea0df4e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: ueSOFoVkIpCSe4vSMAxdW/hWKLPfrwsGA1lJMa5R4398LW9F+YVHmg4FUHtq2p8ZVVx82IfL+QXLUeBsJTc0BaZJQIqC/n4BUs96RVa9CzAIbDNJ7NuVwcLxdcqoJx0Qjygs/C/J79kYJ1gz9Ev0v/EA3his06euQdbFRjz2G66/OR5zQKjqCSQCirUQ+lqV7IIIg2i5UAAS7zBOYqmWwhyPybSyov+vvT/gOdK0heOp+geodilz9pX1m2gtRdDyk1MiLTvw5PxdGVlmyyJvR/JnBbAuUos9Hcwws/t7BnhajClP3RLrNT8kdKfcSITk2spd/Rk7iqHbkwAwZ77tlC71n5UMwe3I86aceaMdoayZJHhJJPEPlXCsEoZDE7bC7fo47IXbNrMBhHt7LhLOdwIYEeq10uhHlH6Z+KbWGq7+lV3nL7Wqzb/x4BoNoMFmAlFQOk3u8mqiTgFXYvkfJ870T2CbvoVJklzRumobJAlfrTHk1xhNyVc12C6VvSwW4EsbEQcZhLDZK+geOHIjl7oyIwLF6Yqr9FomwKhUyHeAx8j7lF/N9DmqKxTHyD8BOk0f8qNAQwbl61uN7RJzRlRFdpk2xZTvOcsys/kHImxQgFcnws1l2sUi4eVY9I+5MUtrBchtjAi5fraSlXTZ+cd8yo/e2yDll69u61sKzrLBrgAVo4kut/M57vo9nbK39wIwT6/diVnXLwu1Rm9i4Icg9HmJwMliKvrWsWs0mn3V+Pzvu6HUuo+VCQQQWlYf X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(36860700004)(376005)(82310400014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Mar 2024 12:19:44.1112 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 77a97465-f791-416f-1636-08dc3ea0df4e X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SN1PEPF0002BA4D.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB6044 Hi Jan, On 3/7/2024 7:04 PM, Jan Beulich wrote: > On 07.03.2024 11:38, Henry Wang wrote: >> Below error can be seen when doing Yocto build of the toolstack: >> >> | io.c: In function 'p9_error': >> | io.c:684:5: error: ignoring return value of 'strerror_r' declared >> with attribute 'warn_unused_result' [-Werror=unused-result] >> | 684 | strerror_r(err, ring->buffer, ring->ring_size); >> | | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> | cc1: all warnings being treated as errors >> >> Fix the build by using strerror() to replace strerror_r(). Since >> strerror() is thread-unsafe, use a separate local mutex to protect >> the action. The steps would then become: Acquire the mutex first, >> invoke strerror(), copy the string from strerror() to the designated >> buffer and then drop the mutex. >> >> >> Fixes: f4900d6d69b5 ("9pfsd: allow building with old glibc") I will add this tag in v3. >> Signed-off-by: Henry Wang > Reviewed-by: Jan Beulich Thanks! > albeit there are a number of cosmetic aspects I'd have done differently > (see bottom of mail). The one thing I'd really like to ask for it a > comment ... > >> --- a/tools/9pfsd/io.c >> +++ b/tools/9pfsd/io.c >> @@ -680,8 +680,18 @@ static bool name_ok(const char *str) >> static void p9_error(struct ring *ring, uint16_t tag, uint32_t err) >> { >> unsigned int erroff; >> + static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER; >> + char *strerror_str; >> + RING_IDX strerror_len = 0, copy_len = 0; >> + > ... here explaining why strerror_r() isn't used. Unless other comments > arise and a v3 would be needed, I'd add > > /* > * While strerror_r() exists, it comes in a POSIX and a GNU flavor. > * Let's try to avoid trying to be clever with determining which > * one it is that the underlying C library offers, when really we > * don't expect this function to be called very often. > */ > > while committing. Since I am working on a V3 which will be sent out soon, please don't bother :) I will handle it from my side. > Anyway it'll need a maintainer ack first. > >> + pthread_mutex_lock(&mutex); >> + strerror_str = strerror(err); >> + strerror_len = strlen(strerror_str) + 1; >> + copy_len = min(strerror_len, ring->ring_size); >> + memcpy(ring->buffer, strerror_str, copy_len); >> + ((char *)(ring->buffer))[copy_len - 1] = '\0'; >> + pthread_mutex_unlock(&mutex); >> >> - strerror_r(err, ring->buffer, ring->ring_size); >> erroff = add_string(ring, ring->buffer, strlen(ring->buffer)); >> fill_buffer(ring, P9_CMD_ERROR, tag, "SU", >> erroff != ~0 ? ring->str + erroff : "cannot allocate memory", > pthread_mutex_lock(&mutex); > str = strerror(err); > len = min(strlen(str), ring->ring_size - 1); This actually will fire below errors on my build env, hence I separated them with a different variable. tools/include/xen-tools/common-macros.h:38:21: error: comparison of distinct pointer types lacks a cast [-Werror] |    38 |         (void) (&_x == &_y);                    \ |       |                     ^~ | io.c:695:11: note: in expansion of macro 'min' |   695 |     len = min(strlen(str), MAX_ERRSTR_LEN - 1);; |       |           ^~~ | cc1: all warnings being treated as errors > memcpy(ring->buffer, str, len); > ((char *)ring->buffer)[len] = '\0'; > pthread_mutex_unlock(&mutex); I will follow your style in V3 if you don't have any specific comment on the error that I posted above (plus also not strongly disagree with my approach in v2). Kind regards, Henry > Jan From xen-devel-bounces@lists.xenproject.org Thu Mar 07 12:23:39 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 12:23:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689861.1075243 (Exim 4.92) (envelope-from ) id 1riCmf-0007wN-Ew; Thu, 07 Mar 2024 12:23:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689861.1075243; Thu, 07 Mar 2024 12:23:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riCmf-0007wG-CE; Thu, 07 Mar 2024 12:23:37 +0000 Received: by outflank-mailman (input) for mailman id 689861; Thu, 07 Mar 2024 12:23:36 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riCme-0007wA-9B for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 12:23:36 +0000 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on20600.outbound.protection.outlook.com [2a01:111:f403:2412::600]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 83ffc5fa-dc7d-11ee-afda-a90da7624cb6; Thu, 07 Mar 2024 13:23:35 +0100 (CET) Received: from CH0PR07CA0028.namprd07.prod.outlook.com (2603:10b6:610:32::33) by MN0PR12MB6342.namprd12.prod.outlook.com (2603:10b6:208:3c1::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.27; Thu, 7 Mar 2024 12:23:30 +0000 Received: from CH1PEPF0000AD75.namprd04.prod.outlook.com (2603:10b6:610:32:cafe::72) by CH0PR07CA0028.outlook.office365.com (2603:10b6:610:32::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.27 via Frontend Transport; Thu, 7 Mar 2024 12:23:30 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by CH1PEPF0000AD75.mail.protection.outlook.com (10.167.244.54) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7362.11 via Frontend Transport; Thu, 7 Mar 2024 12:23:30 +0000 Received: from SATLEXMB08.amd.com (10.181.40.132) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 7 Mar 2024 06:23:29 -0600 Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB08.amd.com (10.181.40.132) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 7 Mar 2024 04:23:29 -0800 Received: from [172.31.100.92] (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend Transport; Thu, 7 Mar 2024 06:23:28 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 83ffc5fa-dc7d-11ee-afda-a90da7624cb6 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=c566m8QQrLEe67WmQ5apK+U0G4CLLwFLwf197nkMF3FofR7/2YRRUXt/mROlNj/Xe/OChVLXQO51EUHAvL0aPBznn+1Bio83c5CJM29EX+gNFoHtNbc/RLRaVb/qXCAK9abz/MrXSGEPIJCAhIRt3j9NXgAvZNNLLkMOvYvfsSSz4j+WMufPx2+GuYzBZ4M3Ic0/SgxwESCdcGdhzk6Qa33ML7+JhMkoIjVKhJpSsdTbyce112CyJltY80ivGkzMw+W4Ear542CPibqO+CFoT0fAucNFr1NzFMXqiJ70ClwX4cCj6CjysW3nsEAfizx2yckZQbu7Fy8zP1NdPCbdyw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=xIvYTYf4ZZUtA8PeomYaaxZ3wiW64APXTpJB+YGmRRg=; b=P1yZ9Fe0k5va8RYeGX3bBwAmiG3wF2o53EsiDhd8PCVV1xxfcRiyUHLoaiTssMcPvYxVn/N7V7E4G5QkS1XA3MuzI8K8mfR5vEP2tBOzdb9RyTKCG2RC9kw0PFEWDfa+K0LGWo29btbuOWtBaGs2lqn1bTgzKxobCF/1/iSCrXel/ILxRofZ1ToXbqmepZHEJaEiOfw+FHaLG5KIkhpddBSlJgOneBiXJRT2TiU/e2Wpi0Pe58JIDrPXhzdB/bGalie1bCkHnBYig3VyHi4tDsP2nb62DYH/JkLGsBIe14wo1Y/H7EKR39yawZkFsrXRLAhbCK4VayvyL1lr3dClHw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xIvYTYf4ZZUtA8PeomYaaxZ3wiW64APXTpJB+YGmRRg=; b=i7Q13wwwb9QwVGXLFC75VhsM4MSKhXDlkdTXwC9dyYA07Yz2Z1s5jrkDGHAQ5rdWdhXl73Ndasu0JtKLOP1+Qbx+Mzg8xpz3paphUZHtW/tBkSoY9VooG+IOKk3rVtN/Xzef9Izkw62yRfm25gK9AmdnBYar7DXH9weIAFLuRrc= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C Message-ID: <3bb50a0d-cb0f-493a-b9a2-06e621fa8d16@amd.com> Date: Thu, 7 Mar 2024 20:23:27 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] tools/9pfsd: Fix build error caused by strerror_r() Content-Language: en-US To: Juergen Gross , CC: Wei Liu , Anthony PERARD , "Jan Beulich" References: <20240307103847.3710737-1-xin.wang2@amd.com> <86f363fb-80f4-45cd-aa1f-58b504546422@suse.com> From: Henry Wang In-Reply-To: <86f363fb-80f4-45cd-aa1f-58b504546422@suse.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH1PEPF0000AD75:EE_|MN0PR12MB6342:EE_ X-MS-Office365-Filtering-Correlation-Id: a144c132-5ccf-412b-772a-08dc3ea16607 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Hre+SexOKZrYlN2K2LkRXjps/vCe7LeUe3JT10hNX4AwUsLBES/MfKppIHfwOInaTEnkoI+0lh2IBgDSuBIfYAllrGj2WQJ9TRBQljzQYXzsib65ivi3FUTfr5K4fc3g0jCq1qxhpQD7f9IpF7i7j+IVHjJ+ZfPXtUqXKvETJ9sb7N38hSU1O7StxU8VyU2E/ipgo4NeJWqioiqcpjaMVC359w2GAfrTBLhRGZTXI5ncPDyz/Pjez64HN2D2mYsusHMSBKOZF9jFNw2Nq1AOReCz+lKZbF96DvziCXu9nH63hShpApwY/8DStVvBdJbXHaA1nVt64n3Ly0nTeagqB2AbV7W9ukPo7IfPtagPQjSWmGdlMbShnNjJNmISnEzrObsHg4wX+ttIBjxhYtzYspnpRfZUfPsmTsWxie2h0Q2rC5XuZ7/dA4vq965r8oMHvGnVicOoJAq6rwDv8RCes2Vy2DW7QwUgw4DicmBoty4H94UQGCsFU3nJoIKt2R8jM8kCwJTk9Dsr0+ukLolJQlve+qDv6ZBUU+82IgOGP3SAVq2o+KM+VHVUwjrfIAS48qZxGVLx6Bh2sBvQ5kDoEFWrIcsGzN+j9VdtguHMmNo9JjH0P6/UkgFl+unGmVnyj+qLhi+LCTVt5frPRiqbyMmBnwMuPXQS2W/gmun/6+enjDPjWqk9yLVPCkXvjUreIJIIopMacFJofSKNcVRBNWWFcq+zNoh8b1p00XwDb4ZB4RdPOO5JHGekHGsTz6LI X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(82310400014)(36860700004)(376005);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Mar 2024 12:23:30.1564 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: a144c132-5ccf-412b-772a-08dc3ea16607 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CH1PEPF0000AD75.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB6342 Hi Juergen, On 3/7/2024 6:51 PM, Juergen Gross wrote: > On 07.03.24 11:38, Henry Wang wrote: >> Below error can be seen when doing Yocto build of the toolstack: >> >> | io.c: In function 'p9_error': >> | io.c:684:5: error: ignoring return value of 'strerror_r' declared >>    with attribute 'warn_unused_result' [-Werror=unused-result] >> |   684 |     strerror_r(err, ring->buffer, ring->ring_size); >> |       |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> | cc1: all warnings being treated as errors >> >> Fix the build by using strerror() to replace strerror_r(). Since >> strerror() is thread-unsafe, use a separate local mutex to protect >> the action. The steps would then become: Acquire the mutex first, >> invoke strerror(), copy the string from strerror() to the designated >> buffer and then drop the mutex. >> >> Signed-off-by: Henry Wang > > Maybe add a "Fixes:" tag referencing Jan's patch? Yes, will do. > And I would expand on the reason why you are using strerror() instead > of just > checking the strerror_r() result. Something like: > >   Using strerror_r() without special casing different build >   environments is impossible due to the different return types >   (int vs char *) depending on the environment. As p9_error() >   is not on a performance critical path, using strerror() with a >   mutex ought to be fine. Thanks! Will add in commit message. >> --- >>   tools/9pfsd/io.c | 12 +++++++++++- >>   1 file changed, 11 insertions(+), 1 deletion(-) >> >> diff --git a/tools/9pfsd/io.c b/tools/9pfsd/io.c >> index adb887c7d9..2b80c9528d 100644 >> --- a/tools/9pfsd/io.c >> +++ b/tools/9pfsd/io.c >> @@ -680,8 +680,18 @@ static bool name_ok(const char *str) >>   static void p9_error(struct ring *ring, uint16_t tag, uint32_t err) >>   { >>       unsigned int erroff; >> +    static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER; >> +    char *strerror_str; >> +    RING_IDX strerror_len = 0, copy_len = 0; > > I wouldn't use RING_IDX for the type, but unsigned int. Ok, I just mainly wanted to keep some consistency, but yeah unsigned int is definitely ok. Will follow your suggestion. Kind regards, Henry From xen-devel-bounces@lists.xenproject.org Thu Mar 07 12:26:30 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 12:26:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689864.1075253 (Exim 4.92) (envelope-from ) id 1riCpO-0000YP-Se; Thu, 07 Mar 2024 12:26:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689864.1075253; Thu, 07 Mar 2024 12:26:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riCpO-0000YI-PW; Thu, 07 Mar 2024 12:26:26 +0000 Received: by outflank-mailman (input) for mailman id 689864; Thu, 07 Mar 2024 12:26:25 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riCpN-0000XW-9a for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 12:26:25 +0000 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on20627.outbound.protection.outlook.com [2a01:111:f400:7e88::627]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id e91493ba-dc7d-11ee-afda-a90da7624cb6; Thu, 07 Mar 2024 13:26:24 +0100 (CET) Received: from BN0PR02CA0007.namprd02.prod.outlook.com (2603:10b6:408:e4::12) by MW6PR12MB8757.namprd12.prod.outlook.com (2603:10b6:303:239::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.24; Thu, 7 Mar 2024 12:26:20 +0000 Received: from BN3PEPF0000B078.namprd04.prod.outlook.com (2603:10b6:408:e4:cafe::66) by BN0PR02CA0007.outlook.office365.com (2603:10b6:408:e4::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.26 via Frontend Transport; Thu, 7 Mar 2024 12:26:20 +0000 Received: from SATLEXMB03.amd.com (165.204.84.17) by BN3PEPF0000B078.mail.protection.outlook.com (10.167.243.123) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7362.11 via Frontend Transport; Thu, 7 Mar 2024 12:26:20 +0000 Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 7 Mar 2024 06:26:20 -0600 Received: from [172.31.100.92] (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend Transport; Thu, 7 Mar 2024 06:26:18 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e91493ba-dc7d-11ee-afda-a90da7624cb6 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ELuAjBX5Iktx29iAdpILthbGM61whPuIDgZa1SLeTLafL3L4CAkD48bbNFLZ9qJLaQyqc7vz74FpxOsA9wwDJoulMynWvcGKmCOFGZ0Kije2X/FX+kxMY/YJnlrweXq/nITsBBX853w95usgZU2dnY/VnM1foPK3YzphKHxCWDn/aT6xBnn0IUne9Ku8cjswtIvBYGoyIvbqB5t9M3mvmzWtMevZhIzf5TxrJUGLII+HPp5KWrQqGhZoo/7A3mtk69G4yTbBeoWKV3zDvbKkAplSmNwKhXPVIr6lr599LDQ+mh2aXvuPBbh6//sK+oLR9YTHuAnM6KjL/g8e378Csg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=5wOySSNZ3bdO+GZF+3nlrL9FW8KPKKFgpVKKiEZRwe0=; b=DyirWL8cewCRNE3GXpGi4WgFNO6tFZNhB0AQwtUhmO0vaYPaGrV4LVLX/5bKoHLbaH37veuxeS6jh6muukGRsNNSqn05LIv7zMQmTlAPVC1jkyLVAfG1b1NYhQxitIQ1wlqNWSC3czJONcXesojylG11Atk9K8GsatsSssYF8/lhFxZa+mDjNGik2lwFI+cU5YtaaodSnvt3LHKjIL0mZRskOfzYSoE3rsyQqbRAH8F/y1QyCzernTZcyxefGJ1zNmM7J4YD879wLQ4IcKLdTbEEl/hIjRiRSACrGnaRV2miAcHEmWIQjMfvxtXvQHpvglHI6ovBImz2+io7anQSGA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5wOySSNZ3bdO+GZF+3nlrL9FW8KPKKFgpVKKiEZRwe0=; b=RNUk46SCQ+AyATyRHcCaW7gNzl/2Rjr4AxsMaXCxHljG/a7QPtU+ptgbaNXUf8jacbHygd+93D/inbV2WeyTqkpCBim2iPKSKxG8ffSMY/ZL4DivvfMeTyxctONMTv3u092S72A8aISaviKQl9sPXvCqVo5SHHXQ+bS7VuehyDE= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C Message-ID: <65a2cd92-2a7c-43b8-8257-13115b6f7fd5@amd.com> Date: Thu, 7 Mar 2024 20:26:17 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] tools/9pfsd: Fix build error caused by strerror_r() Content-Language: en-US To: Juergen Gross , CC: Wei Liu , Anthony PERARD , Jan Beulich References: <20240307103847.3710737-1-xin.wang2@amd.com> <833782ae-9699-492a-9d18-2644873c97c7@suse.com> From: Henry Wang In-Reply-To: <833782ae-9699-492a-9d18-2644873c97c7@suse.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: None (SATLEXMB03.amd.com: xin.wang2@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN3PEPF0000B078:EE_|MW6PR12MB8757:EE_ X-MS-Office365-Filtering-Correlation-Id: ef5b16ae-5d12-4ef4-a6a6-08dc3ea1cb89 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: x1owsk/JymdHen1UyY3T9DVX2ScWl0bzA+NqJdnUCosb7Z5jeMKjUHbLqFtnCCB98/F+F768bbPWEAPyHc77IulFLQhWumUmkG6vLOJwNpg4h81c0v0VS1jwr7EPmlM1nyLwMSew/32jAH37pQXQGxeGaJ+WnsPDAttvx9SD6vDzJFnSryGQIFWJX5kGy38Y5+YWklbnO3gPt1TxDDfrCg9Y47dcZn6S3a4RaFytQsCcEte5tBPxnj+l6njnpFz9Klhor7xuHNE7aRVWqUWXdbTnLdU24xRioNVq58G4sXjREDwKf0OROijq8bUU1MhcLfu0yKHUrp+nf8H5n74PmfDgSvvcHUdr8OmfJyTLX+QWONvXROOv5JHHJv2l8shTaaFA4qYlv5WfLv1SB8h2/4gd7SkmsFu8Ewysn7cQOG2lI78knj9LbtVIEzXy8UEFkHbjExeYD7roLbXBRJFr2Sgylgbo/fkpRB+g1/mpV3iMgnSRjKh6m5VHB2agqouCFEi1iBL5WI6CS4IQUeyQ8HHoCgWJ27dwcNL/jiRuRhP8EwVLPGoTsi0R4nYmI8mDMub8Pm99FC/G+QAPC7iQFwecqxP8PDgACya6/N8w7ddNlFI15Au0Mu6tPdIo9GNt5kg9Vb2d0S8ZgnS61StK84aShqgGXv9UHtciCSEjH837W+prn0n41qh6Toe6D8u4HxxTvJW3n9/3QnQQHjUIMdcEAKYZ2ITZ1YObgcXVflSGTQVQ85dNQQTVRiQDdUOj X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(82310400014)(36860700004)(376005);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Mar 2024 12:26:20.4751 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ef5b16ae-5d12-4ef4-a6a6-08dc3ea1cb89 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BN3PEPF0000B078.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW6PR12MB8757 Hi Juergen, On 3/7/2024 7:24 PM, Juergen Gross wrote: > On 07.03.24 11:38, Henry Wang wrote: >> Below error can be seen when doing Yocto build of the toolstack: >> >> | io.c: In function 'p9_error': >> | io.c:684:5: error: ignoring return value of 'strerror_r' declared >>    with attribute 'warn_unused_result' [-Werror=unused-result] >> |   684 |     strerror_r(err, ring->buffer, ring->ring_size); >> |       |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> | cc1: all warnings being treated as errors >> >> Fix the build by using strerror() to replace strerror_r(). Since >> strerror() is thread-unsafe, use a separate local mutex to protect >> the action. The steps would then become: Acquire the mutex first, >> invoke strerror(), copy the string from strerror() to the designated >> buffer and then drop the mutex. >> >> Signed-off-by: Henry Wang >> --- >>   tools/9pfsd/io.c | 12 +++++++++++- >>   1 file changed, 11 insertions(+), 1 deletion(-) >> >> diff --git a/tools/9pfsd/io.c b/tools/9pfsd/io.c >> index adb887c7d9..2b80c9528d 100644 >> --- a/tools/9pfsd/io.c >> +++ b/tools/9pfsd/io.c >> @@ -680,8 +680,18 @@ static bool name_ok(const char *str) >>   static void p9_error(struct ring *ring, uint16_t tag, uint32_t err) >>   { >>       unsigned int erroff; >> +    static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER; >> +    char *strerror_str; >> +    RING_IDX strerror_len = 0, copy_len = 0; >> + >> +    pthread_mutex_lock(&mutex); >> +    strerror_str = strerror(err); >> +    strerror_len = strlen(strerror_str) + 1; >> +    copy_len = min(strerror_len, ring->ring_size); > > Hmm, I think we even _need_ to cap the string earlier. > > A string in the 9pfs protocol is a 2 byte length field plus the string. > In case of a ring larger than 65535 bytes this would mean the result of > strerror() could (in theory) overflow the string format of 9pfs. > > Additionally the string should be a _short_ description of the error, so > I'd like to suggest to not use ring_size as the upper bound for the > string > length, but a fixed value defined as a macro, e.g.: > > #define MAX_ERRSTR_LEN 80 I can use a macro-defined value in v3, sure. Kind regards, Henry > Juergen From xen-devel-bounces@lists.xenproject.org Thu Mar 07 12:28:21 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 12:28:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689868.1075263 (Exim 4.92) (envelope-from ) id 1riCrE-00015z-7r; Thu, 07 Mar 2024 12:28:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689868.1075263; Thu, 07 Mar 2024 12:28:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riCrE-00015s-41; Thu, 07 Mar 2024 12:28:20 +0000 Received: by outflank-mailman (input) for mailman id 689868; Thu, 07 Mar 2024 12:28:18 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riCrC-00015m-Gr for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 12:28:18 +0000 Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [2a00:1450:4864:20::229]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 2c6769de-dc7e-11ee-a1ee-f123f15fe8a2; Thu, 07 Mar 2024 13:28:16 +0100 (CET) Received: by mail-lj1-x229.google.com with SMTP id 38308e7fff4ca-2d3f4fef377so10402521fa.1 for ; Thu, 07 Mar 2024 04:28:16 -0800 (PST) Received: from [192.168.206.239] ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id u23-20020a2e8557000000b002d2c8c25ca6sm2960924ljj.125.2024.03.07.04.28.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Mar 2024 04:28:15 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 2c6769de-dc7e-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709814496; x=1710419296; darn=lists.xenproject.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=GgwUo71JuL3GonfSKL3S+jfvhcE2fWDoEKNr/owHYcI=; b=OXffShxc5S/9vLWNBKiighly/IGE14ogxRbfQVDMw6ORQyR5RhigaUW/3xny3aUhMf 6iD6qRjjLiqZQQCqvFPoUj/ftG4H4Q8P9f7UOrRnQaVN/MyubirVE301rBqRZJZdnL9a cnZhVVAX0GtUQiOc2PByZK1QSxXPmVcdjginmvCCy6t9+hKNWruD4ciXiamJCmBg2RFL reB1l42OqB4X5I6XBcSsbMB6Bx4+XK294FEDfIIYerEi12fQK10Jqjhtp16cqmMi4JnQ ked90IMoQ2OUNGSOwfMzraoeJKNOnxitmj2/KCiWfdy2EjwOrmK8WHYGYgYoCzjCzcD4 bxrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709814496; x=1710419296; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=GgwUo71JuL3GonfSKL3S+jfvhcE2fWDoEKNr/owHYcI=; b=fk6lTV8WMxJdW9GnqoxtIccLL6NQxsMdJOOs8SuDW9zCXkgZ2L6FAzbT7WIcqKUHTz oQYFVixDqlFc+bZw6+2QyRSZGxwnGzXqNd6hWdYKv76NgfuYhrAHhdNzxFb6nKPZEm8r S9paJQ4jzbezaxHl3byTnK/MlyFjaVeaUeWMvjYiMmvMQb+JZoR9iWcorjvj0otg57+H ADRrNIHhqVNrg4gb6GW5VLlguk+XrQ26xMkbksl06wXUd3dNIvRSaLwuGdXrrEmEXNbx qXIh01Re5lV6L+X3iyZaH5qFf1czLBeYJ4BNFH+JPtSQgNh9oQprdU83/3t5TRjD6n9o 9++w== X-Forwarded-Encrypted: i=1; AJvYcCUSy269ZnGZks0GTrvg/jENEtdWqDbUXtuTdX5KtgYwXqUfNr7IPdbmq1GjfD7jBgz7M1Fp7rjDdI94qtbPqzZYBIV30e/FS1G+N/e44QY= X-Gm-Message-State: AOJu0Yw5zI031Sztf8xhI6OekivXzhlZyvmSxgsBklAwwv3GSF11U2me SsX4nOf06Vy6e2xIUf/9rd93Go3mnlPJwXfdd1z+zrf0e2cW9d5Y X-Google-Smtp-Source: AGHT+IHxQZeDFhI2yNVyIu7+JqeButMno0aQ2yC2yeT48EFWSIPozuF2FxjzeGxNUdg5IpGcKa1VKQ== X-Received: by 2002:a05:651c:1505:b0:2d2:206a:2f2a with SMTP id e5-20020a05651c150500b002d2206a2f2amr1690385ljf.17.1709814495509; Thu, 07 Mar 2024 04:28:15 -0800 (PST) Message-ID: <3ca486b6476c366d5d3f18297cd07dce38993b19.camel@gmail.com> Subject: Re: [PATCH v5 11/23] xen/riscv: introduce cmpxchg.h From: Oleksii To: Jan Beulich Cc: Alistair Francis , Bob Eshleman , Connor Davis , Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu , xen-devel@lists.xenproject.org Date: Thu, 07 Mar 2024 13:28:14 +0100 In-Reply-To: <8ef64462-d810-4be1-923f-973de340cda2@suse.com> References: <23ff1c20-91f3-4c60-9562-7f1cd57c1043@suse.com> <8ef64462-d810-4be1-923f-973de340cda2@suse.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.50.2 (3.50.2-1.fc39) MIME-Version: 1.0 On Thu, 2024-03-07 at 12:11 +0100, Jan Beulich wrote: > On 07.03.2024 12:01, Oleksii wrote: > > On Thu, 2024-03-07 at 11:46 +0100, Jan Beulich wrote: > > > On 07.03.2024 11:35, Oleksii wrote: > > > > On Wed, 2024-03-06 at 15:56 +0100, Jan Beulich wrote: > > > > > On 26.02.2024 18:38, Oleksii Kurochko wrote: > > > > > > The header was taken from Linux kernl 6.4.0-rc1. > > > > > >=20 > > > > > > Addionally, were updated: > > > > > > * add emulation of {cmp}xchg for 1/2 byte types using 32- > > > > > > bit > > > > > > atomic > > > > > > =C2=A0 access. > > > > > > * replace tabs with spaces > > > > > > * replace __* variale with *__ > > > > > > * introduce generic version of xchg_* and cmpxchg_*. > > > > > >=20 > > > > > > Implementation of 4- and 8-byte cases were left as it is > > > > > > done > > > > > > in > > > > > > Linux kernel as according to the RISC-V spec: > > > > > > ``` > > > > > > Table A.5 ( only part of the table was copied here ) > > > > > >=20 > > > > > > Linux Construct=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RVWMO Mappi= ng > > > > > > atomic relaxed=C2=A0=C2=A0=C2=A0 amo.{w|d} > > > > > > atomic acquire=C2=A0=C2=A0=C2=A0 amo.{w|d}.aq > > > > > > atomic release=C2=A0=C2=A0=C2=A0 amo.{w|d}.rl > > > > > > atomic =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 amo.{w|d}.aqrl > > > > > >=20 > > > > > > Linux Construct=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RVWMO LR/SC= Mapping > > > > > > atomic relaxed=C2=A0=C2=A0=C2=A0 loop: lr.{w|d}; ; sc.= {w|d}; bnez > > > > > > loop > > > > > > atomic acquire=C2=A0=C2=A0=C2=A0 loop: lr.{w|d}.aq; ; = sc.{w|d}; > > > > > > bnez > > > > > > loop > > > > > > atomic release=C2=A0=C2=A0=C2=A0 loop: lr.{w|d}; ; sc.= {w|d}.aqrl=E2=88=97 > > > > > > ; > > > > > > bnez > > > > > > loop OR > > > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 fence= .tso; loop: lr.{w|d}; ; > > > > > > sc.{w|d}=E2=88=97 ; > > > > > > bnez loop > > > > > > atomic =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 loop: lr.{w|d}.aq; ; > > > > > > sc.{w|d}.aqrl; > > > > > > bnez > > > > > > loop >=20 > Note the load and store forms mentioned here. How would ... >=20 > > > > > > The Linux mappings for release operations may seem stronger > > > > > > than > > > > > > necessary, > > > > > > but these mappings are needed to cover some cases in which > > > > > > Linux > > > > > > requires > > > > > > stronger orderings than the more intuitive mappings would > > > > > > provide. > > > > > > In particular, as of the time this text is being written, > > > > > > Linux > > > > > > is > > > > > > actively > > > > > > debating whether to require load-load, load-store, and > > > > > > store- > > > > > > store > > > > > > orderings > > > > > > between accesses in one critical section and accesses in a > > > > > > subsequent critical > > > > > > section in the same hart and protected by the same > > > > > > synchronization > > > > > > object. > > > > > > Not all combinations of FENCE RW,W/FENCE R,RW mappings with > > > > > > aq/rl > > > > > > mappings > > > > > > combine to provide such orderings. > > > > > > There are a few ways around this problem, including: > > > > > > 1. Always use FENCE RW,W/FENCE R,RW, and never use aq/rl. > > > > > > This > > > > > > suffices > > > > > > =C2=A0=C2=A0 but is undesirable, as it defeats the purpose of t= he > > > > > > aq/rl > > > > > > modifiers. > > > > > > 2. Always use aq/rl, and never use FENCE RW,W/FENCE R,RW. > > > > > > This > > > > > > does > > > > > > not > > > > > > =C2=A0=C2=A0 currently work due to the lack of load and store o= pcodes > > > > > > with aq > > > > > > and rl > > > > > > =C2=A0=C2=A0 modifiers. > > > > >=20 > > > > > As before I don't understand this point. Can you give an > > > > > example > > > > > of > > > > > what > > > > > sort of opcode / instruction is missing? > > > > If I understand the spec correctly then l{b|h|w|d} and > > > > s{b|h|w|d} > > > > instructions don't have aq or rl annotation. > > >=20 > > > How would load insns other that LR and store insns other than SC > > > come > > > into play here? > >=20 > > This part of the spec. is not only about LR and SC which cover > > Load- > > Exclusive and Store-Exclusive cases, but also about non-Exclusive > > cases > > for each l{b|h|w|d} and s{b|h|w|d} are used. >=20 > ... the spec (obviously covering other forms, too) be relevant when > reasoning whether just suffixes or actual barrier insns need using? Based on 3 rules which are in the commit message and in the spec., there is no difference between what option should be used ( at least, I wasn't able to find an explanation in that paragraph ), but based on the tables provided in the same paragraph ( and partially in the commit message ) if an instruction has .aq or .rl annotation it should be used. And speaking about xchg and cmpxcgh case and their implementations, all instructions have .ar/.rl suffixes, so we'd rather prefer suffixes instead of barriers.=20 Does it make sense? ~ Oleksii From xen-devel-bounces@lists.xenproject.org Thu Mar 07 12:40:09 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 12:40:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689872.1075273 (Exim 4.92) (envelope-from ) id 1riD2Y-0004r6-6W; Thu, 07 Mar 2024 12:40:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689872.1075273; Thu, 07 Mar 2024 12:40:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riD2Y-0004qe-2N; Thu, 07 Mar 2024 12:40:02 +0000 Received: by outflank-mailman (input) for mailman id 689872; Thu, 07 Mar 2024 12:40:00 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riD2W-0004ja-7Y for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 12:40:00 +0000 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on20600.outbound.protection.outlook.com [2a01:111:f403:2415::600]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id ce788571-dc7f-11ee-afda-a90da7624cb6; Thu, 07 Mar 2024 13:39:58 +0100 (CET) Received: from BY5PR16CA0020.namprd16.prod.outlook.com (2603:10b6:a03:1a0::33) by DS0PR12MB7581.namprd12.prod.outlook.com (2603:10b6:8:13d::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7339.39; Thu, 7 Mar 2024 12:39:56 +0000 Received: from SJ1PEPF00001CE9.namprd03.prod.outlook.com (2603:10b6:a03:1a0:cafe::bd) by BY5PR16CA0020.outlook.office365.com (2603:10b6:a03:1a0::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.27 via Frontend Transport; Thu, 7 Mar 2024 12:39:55 +0000 Received: from SATLEXMB03.amd.com (165.204.84.17) by SJ1PEPF00001CE9.mail.protection.outlook.com (10.167.242.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7362.11 via Frontend Transport; Thu, 7 Mar 2024 12:39:55 +0000 Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 7 Mar 2024 06:39:54 -0600 Received: from xcbayankuma40.xilinx.com (10.180.168.240) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.35 via Frontend Transport; Thu, 7 Mar 2024 06:39:53 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ce788571-dc7f-11ee-afda-a90da7624cb6 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TO+zMB8nhPgtXZVOMKY1ba6zp4Wtw0unFS+Sv6PpKl39y43HW4nYCd6Z+mLCMbNea6zlZcki7iVqbNITHfbTxkaWbH0SzgMN52jAddX6OIDkYI5GppxVOTTUxP6a4QiDdHR8x3Pyrvwi1hZtevySxJvtvCC+3I313oTuEk/KwkTKVr6JlqkGHPdR5PvfQMhmeW7SOvCsZhT74WZKbKktPc/T5LU0orhFdvel/DGZHvx7wkGBkkZmNSKObr2jywNbtaI6dgpcx2PmhK1BiyAddqpNoF6l03YNdDa8dRPIXd/I74SfMKMnEYIylYi1ZOI07O3SR8vCKXw6gGXDyI+gsQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Sctp/GUPyTcFVFaoDcBFiWSmPf7+5jiwVDm3nmV1ngM=; b=kqb3Qk0SxGt2SzZilEuNRCpkeAXcG6yU5PXcaa3U8WevlSwhnItrskizUyQTthdwU4hyTLkFrwEGF+LLYNItBlB8TR71u7sVy5tbpDZVQJf/eynng3tTQgLOQsG39EKX9MruwOXUcrCjCV95kFbzmxE3PjkhUrfW0HiXBh7LBKt3PqgIj0JAvRe+0A7dpM37X6I08267wmJ/qDBQ1oaaBhlPXmIavnM+LGJ1TQHecAbUE7WGfU4Wf7xNE7+p0rqhcvUHr/iK3+kj93KaJ/oFmThmQgNFATdL/IxAPQ8ciPaXiy3e741SaChwrW4dKD49WUaK1s+IDCv5BQeqwdyOWA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Sctp/GUPyTcFVFaoDcBFiWSmPf7+5jiwVDm3nmV1ngM=; b=RLSKSQvQZQLm1agDyMOMyFDdxA0hGgpiLewDCuu9yN/9d5oMuVV941SKf3NFPjopGpUsmjsJZGIHOtUGtF1i6/R5b3X0rUni7LYrovs8ugj0ld3F5or6hIZ70VsOAgq1h2k3YhAhd+K+Au9BsJhN+7610ASEhek65B3rXBobGqc= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C From: Ayan Kumar Halder To: CC: , , , , , , Ayan Kumar Halder Subject: [XEN v6 0/3] xen/arm: Add emulation of Debug Data Transfer Registers Date: Thu, 7 Mar 2024 12:39:40 +0000 Message-ID: <20240307123943.1991755-1-ayan.kumar.halder@amd.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain Received-SPF: None (SATLEXMB03.amd.com: ayan.kumar.halder@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ1PEPF00001CE9:EE_|DS0PR12MB7581:EE_ X-MS-Office365-Filtering-Correlation-Id: b0d2d8ab-3e7c-46f9-95b8-08dc3ea3b155 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 8heBDVP4mfRUoeCrx/8J4RWCtBmCVguGIBHtxNwdZwNmESXGBBAR2b8NqZW5NavY5kvBF3Ym6/j0mmexXss3XRB6MZxQ0QsitAY6V0ORIcuDllYzxYjAAfi+SI+f9y56Zr9+zHX/TBu1t+oDRfKr8cgpBIadOoefQelDDwORsxXfkNfMlwG7zYy5PWk/nY1x/bhbfMK+nMIvPiXfioJL063VWmMsrVfBlT8Kz1YrMQS5PdYTT9fjCQmNGDLseFC/k11CihMkvq0TMmotm1na1eLhkFbDFG7o4iVQo39ZNSYB1CNwHJFesmgMZxqDVdgPuQBhdIPeoUUli0O8bKDzYPd8nCpIIhjbzt8aM6oQfeeKXD52WdAAw0RahfWbrDrfOvo6phI2zPHpjlvQV/0B6H5Hcxc73fynFcGKAp6U5XiDZc2kF2QT0KnQfGBvkwP3fFy1TP0yMJ1IQYLnQq9FBf+LdqXFn0fKiKn7kDWExv7m1y7/Z8XgA7x8Zq2vPZgyznvl9c6pzV7bZE2WhBu0vFWNwLgplkkSoTYQsbZY45sltqTnrlAFsN7/omZd0JIBpnSetub8Lq3F6oXBBQAc0Tvfzs6Ufy9P425uvAPuMkfk7edihhnOWxAlrLJJximT2Sy2BFNSqvHsaBOF/+I2r+7kcoX2PheStnvE7OrAzS7fJy0HKLTWpUtuDJZXXLs9CkfZ+3Dn/1SFBeFRltyOfA== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(376005)(36860700004)(82310400014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Mar 2024 12:39:55.4285 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b0d2d8ab-3e7c-46f9-95b8-08dc3ea3b155 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SJ1PEPF00001CE9.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB7581 Hi, Refer https://lore.kernel.org/all/alpine.DEB.2.22.394.2312071341540.1265976@ubuntu-linux-20-04-desktop/T/ for the previous discussion on this issue. Also, the linux earlycon hvc driver has been fixed. See https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git/commit/?h=tty-next&id=0ec058ece2f933aed66b76bd5cb9b5e6764853c3 Changes from v1:- 1. Split the change across 3 patches as per the design consensus. v2 :- 1. Reordered the patches. v3 :- 1. Change mentioned in individual patches. v4 :- 1. Change mentioned in individual patches. v5 :- 1. Change mentioned in individual patches. Ayan Kumar Halder (2): xen/arm: Introduce CONFIG_PARTIAL_EMULATION and "partial-emulation" cmd option xen/arm: arm32: Add emulation of Debug Data Transfer Registers Michal Orzel (1): xen/arm: arm64: Add emulation of Debug Data Transfer Registers SUPPORT.md | 17 +++++++ docs/misc/xen-command-line.pandoc | 11 +++++ xen/arch/arm/Kconfig | 9 ++++ xen/arch/arm/arm64/vsysreg.c | 69 +++++++++++++++++++--------- xen/arch/arm/include/asm/arm64/hsr.h | 3 ++ xen/arch/arm/include/asm/cpregs.h | 2 + xen/arch/arm/include/asm/traps.h | 6 +++ xen/arch/arm/traps.c | 9 ++++ xen/arch/arm/vcpreg.c | 62 +++++++++++++++++-------- 9 files changed, 149 insertions(+), 39 deletions(-) -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Thu Mar 07 12:40:35 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 12:40:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689875.1075282 (Exim 4.92) (envelope-from ) id 1riD35-0006Ev-J0; Thu, 07 Mar 2024 12:40:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689875.1075282; Thu, 07 Mar 2024 12:40:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riD35-0006Eo-GG; Thu, 07 Mar 2024 12:40:35 +0000 Received: by outflank-mailman (input) for mailman id 689875; Thu, 07 Mar 2024 12:40:34 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riD34-0004ja-GF for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 12:40:34 +0000 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on20600.outbound.protection.outlook.com [2a01:111:f403:2415::600]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id e37bdc99-dc7f-11ee-afda-a90da7624cb6; Thu, 07 Mar 2024 13:40:33 +0100 (CET) Received: from SJ0PR05CA0106.namprd05.prod.outlook.com (2603:10b6:a03:334::21) by CH3PR12MB8971.namprd12.prod.outlook.com (2603:10b6:610:177::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7339.39; Thu, 7 Mar 2024 12:40:31 +0000 Received: from CO1PEPF000042AA.namprd03.prod.outlook.com (2603:10b6:a03:334:cafe::82) by SJ0PR05CA0106.outlook.office365.com (2603:10b6:a03:334::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.6 via Frontend Transport; Thu, 7 Mar 2024 12:40:30 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by CO1PEPF000042AA.mail.protection.outlook.com (10.167.243.39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7362.11 via Frontend Transport; Thu, 7 Mar 2024 12:40:29 +0000 Received: from SATLEXMB08.amd.com (10.181.40.132) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 7 Mar 2024 06:40:29 -0600 Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB08.amd.com (10.181.40.132) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 7 Mar 2024 04:40:28 -0800 Received: from xcbayankuma40.xilinx.com (10.180.168.240) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.35 via Frontend Transport; Thu, 7 Mar 2024 06:40:27 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e37bdc99-dc7f-11ee-afda-a90da7624cb6 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bLdhMBlV9KCAe5MtTnpRljroS+gFNScAwnuuIijc2rQuS1Tq/wB8ikNVkfTBVV+OOmJVOHBH8NpzLd+U+8VGWlnJOoRmYNTOF5yFZm+80nNXDtWxWdY7fqrx/utuNH0bKxpaFIzH0F/j7gBl2N8hZIkAEnMaITgzHHTV8bsWOTqykPcG137WrNWXS8GM6DcRqF6jlD8Ppv/DpLSCkyGR8QOCQ1Odx2hz8FTDcEYplXqkYS9MctzSjVlha87LqRQM3sNwl+xr1DaAPNrwShaoI8T7ONFFOXX2k4zblhGEnDXE2Lmnjg+hseMyPaPKmaMJ6w8nw1sajP/fgjbCdyuA2A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=PMIOVJVSy6u/LzekxPUJWc7zfls/wR2k+xzI6m7KP7g=; b=MYK7FyQSwFSS0MHIBiekvZBs7MiTLmk8EPZ4L14Be2Zy4DIVYa4y/ntQFEaPCreN122Et8XQJi5nqOyBsQv3dBXYU9hg0M1RsIpLLjP5wuOeJGs+MYUFaxsdQTCYmnIfixJdzxbMv1kcYCkG+HQN8uV7EWQh38QZ1H5Si/68fVvmnsqrGbksiDOFKyEgxfuU3wDd8xQR7CmYThU78GNSl3NqwPstUZOd9bm+nNFeRlaX+B9xUov7SsLrcPGlxkO2Q8q+31oC3NnT33clul5znU6lAUijBi05hCQB503y6XX9HxWtTQ1KoUJB5wkKeLG125+2AI+tCCQ5rY5yEcXxmg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PMIOVJVSy6u/LzekxPUJWc7zfls/wR2k+xzI6m7KP7g=; b=0vNuLyR4D/PTyHe09kSmUxygCkxesztwC5HVozByBY6AKtnhX/myL7160vB3u7o1wsx987HuZLIACOVHpfqEp8++F0xNpekTXoOETbDttgVNatxNU4pnnfI+fgJysoG0KCgAbanLJEd7TNLPDkkBA8iUIH7fqdCIqkBRPPvkfKY= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C From: Ayan Kumar Halder To: CC: , , , , , , Ayan Kumar Halder Subject: [XEN v6 1/3] xen/arm: Introduce CONFIG_PARTIAL_EMULATION and "partial-emulation" cmd option Date: Thu, 7 Mar 2024 12:39:41 +0000 Message-ID: <20240307123943.1991755-2-ayan.kumar.halder@amd.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20240307123943.1991755-1-ayan.kumar.halder@amd.com> References: <20240307123943.1991755-1-ayan.kumar.halder@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CO1PEPF000042AA:EE_|CH3PR12MB8971:EE_ X-MS-Office365-Filtering-Correlation-Id: ff8503de-184a-4303-da77-08dc3ea3c5da X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 59WKqOGY8lE0yAdkhnk9z7uaufBuS7swX3HL6qbM0elxFO2PGyZf7kpiol6jFjTBHEelD3DbDgUESODrSOQXJiOaKGOmpS+JhbCcT6XlnnpOCBC1yJs+w/zlr1/ZhtNVXCOGKzOR9eFP0dMDSnS5F0f+hS91kjTehHKrgOoB8OYnRa6YhlvaI1B2/aEzCKS/iOc8vQbU0598Th9nuWSlnt+ZmVanjc73feoHp+L5v60FKgkuLfFn06F5aj5/+G5tBI0nX63z3Yl4sS8q0F6nd9reqrnMxpj3G0732viOTm0PrB7M5SSapI79lY7dzl5ycmcWK5Cd3KKK5BNH7MPcRN5nmFyB9f1wSTGyFYJV/X62bQhd61f06GhOmYwVGDMhZoSvZbULBMZFysT8g/+nJRPZdr24KHPN6LwR0Z5WC5kXUBrDxGB8cjRM1iv50P/n/a/Zptt9ejlFzTs7sCQia5geo45pfWNSXv07oX9XboPGT5sAJrL2821mfySZ5KVW53Winq0PSpUB+9ZmYo86GkXSJyrsXKO4ThLTdR+yGomOh2KazJi4heWOeInmx8/3iyeMKYRz7Nmx/quBst7/Rixx/2A+76cdhktHG5viQ4Uvyraqvmho14X2u2+7PP5lWbOai+BNlvkB2cNfogrhLpUk2b2shPYH0dVdb7hLZ4K2hEosM2yAk/oiJtPL/64TUEfo1w9JO/QbqPTMO2AnK/cwaqXw9/ayQ65POJlgBHNOhWGAfoR0y6tYjo6dQjBu X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(36860700004)(82310400014)(376005);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Mar 2024 12:40:29.8407 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ff8503de-184a-4303-da77-08dc3ea3c5da X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CO1PEPF000042AA.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB8971 There can be situations when the registers cannot be emulated to their full functionality. This can be due to the complexity involved. In such cases, one can emulate those registers as RAZ/WI for example. We call them as partial emulation. Some registers are non-optional and as such there is nothing preventing an OS from accessing them. Instead of injecting undefined exception (which might result in crashing a guest), one may want to prefer a partial emulation to let the guest running (in some cases accepting the fact that it might result in unwanted behavior). A suitable example of this (as seen in subsequent patches) is emulation of DBGDTRTX_EL0 (on Arm64) and DBGDTRTXINT(on Arm32). These non-optional registers can be emulated as RAZ/WI and they can be enclosed within CONFIG_PARTIAL_EMULATION. Further, "partial-emulation" command line option allows us to enable/disable partial emulation at run time. While CONFIG_PARTIAL_EMULATION enables support for partial emulation at compile time (i.e. adds code for partial emulation), this option may be enabled or disabled by Yocto or other build systems. However if the build system turns this option on, users can use scripts like Imagebuilder to generate uboot-script which will append "partial-emulation=true" to xen command line to turn on the partial emulation. Thus, it helps to avoid rebuilding xen. By default, "CONFIG_PARTIAL_EMULATION=y" and "partial-emulation=false". This is done so that Xen supports partial emulation. However, customers are fully aware when they enable partial emulation. It's important to note that enabling such support might result in unwanted/non-spec compliant behavior. Added a note in SUPPORT.md to clarify the security support for partial emulation. Signed-off-by: Ayan Kumar Halder Signed-off-by: Michal Orzel --- Changes from v1 :- 1. New patch introduced in v2. v2 :- 1. Reordered the patches so that the config and command line option is introduced in the first patch. v3 :- 1. Defined a macro 'partial_emulation' to reduce if-defs. 2. Fixed style issues. v4 :- 1. Added a note in SUPPORT.md. v5 :- 1. Dropped R-b 2. Update the commit message and Kconfig message. 3. Update 'SUPPORT.md' message. SUPPORT.md | 9 +++++++++ docs/misc/xen-command-line.pandoc | 11 +++++++++++ xen/arch/arm/Kconfig | 9 +++++++++ xen/arch/arm/include/asm/traps.h | 6 ++++++ xen/arch/arm/traps.c | 9 +++++++++ 5 files changed, 44 insertions(+) diff --git a/SUPPORT.md b/SUPPORT.md index 7eb6875cfa..b49da114ab 100644 --- a/SUPPORT.md +++ b/SUPPORT.md @@ -102,6 +102,15 @@ Extension to the GICv3 interrupt controller to support MSI. Status: Experimental +### ARM/Partial Emulation + +Enable partial emulation of registers, otherwise considered unimplemented, +that would normally trigger a fault injection. + + Status: Supported, with caveats + +Only the following system registers are security supported: + ### ARM Scalable Vector Extension (SVE/SVE2) Arm64 domains can use Scalable Vector Extension (SVE/SVE2). diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc index 02896598df..023c5e7225 100644 --- a/docs/misc/xen-command-line.pandoc +++ b/docs/misc/xen-command-line.pandoc @@ -1942,6 +1942,17 @@ This option is ignored in **pv-shim** mode. > Default: `on` +### partial-emulation (arm) +> `= ` + +> Default: `false` + +Flag to enable or disable partial emulation of system/coprocessor registers. +Only effective if CONFIG_PARTIAL_EMULATION is enabled. + +**WARNING: Enabling this option might result in unwanted/non-spec compliant +behavior.** + ### pci = List of [ serr=, perr= ] diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig index 40f834bb71..f8139a773a 100644 --- a/xen/arch/arm/Kconfig +++ b/xen/arch/arm/Kconfig @@ -234,6 +234,15 @@ config STATIC_EVTCHN This option enables establishing static event channel communication between domains on a dom0less system (domU-domU as well as domU-dom0). +config PARTIAL_EMULATION + bool "Enable partial emulation of system/coprocessor registers" + default y + help + This option enables partial emulation of registers to prevent possible + guests crashing when accessing registers which are not optional but have + not been emulated to their complete functionality. Enabling this might + result in unwanted/non-spec compliant behavior. + endmenu menu "ARM errata workaround via the alternative framework" diff --git a/xen/arch/arm/include/asm/traps.h b/xen/arch/arm/include/asm/traps.h index 883dae368e..9a60dbf70e 100644 --- a/xen/arch/arm/include/asm/traps.h +++ b/xen/arch/arm/include/asm/traps.h @@ -10,6 +10,12 @@ # include #endif +#ifdef CONFIG_PARTIAL_EMULATION +extern bool partial_emulation; +#else +#define partial_emulation false +#endif + /* * GUEST_BUG_ON is intended for checking that the guest state has not been * corrupted in hardware and/or that the hardware behaves as we diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c index 9c10e8f78c..d1c7a6c516 100644 --- a/xen/arch/arm/traps.c +++ b/xen/arch/arm/traps.c @@ -42,6 +42,15 @@ #include #include +/* + * partial_emulation: If true, partial emulation for system/coprocessor + * registers will be enabled. + */ +#ifdef CONFIG_PARTIAL_EMULATION +bool __ro_after_init partial_emulation = false; +boolean_param("partial-emulation", partial_emulation); +#endif + /* The base of the stack must always be double-word aligned, which means * that both the kernel half of struct cpu_user_regs (which is pushed in * entry.S) and struct cpu_info (which lives at the bottom of a Xen -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Thu Mar 07 12:40:39 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 12:40:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689876.1075293 (Exim 4.92) (envelope-from ) id 1riD39-0006W7-PV; Thu, 07 Mar 2024 12:40:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689876.1075293; Thu, 07 Mar 2024 12:40:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riD39-0006Vy-Mo; Thu, 07 Mar 2024 12:40:39 +0000 Received: by outflank-mailman (input) for mailman id 689876; Thu, 07 Mar 2024 12:40:39 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riD38-00060p-Uw for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 12:40:38 +0000 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on20600.outbound.protection.outlook.com [2a01:111:f403:2418::600]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id e54450b4-dc7f-11ee-a1ee-f123f15fe8a2; Thu, 07 Mar 2024 13:40:37 +0100 (CET) Received: from MW2PR16CA0066.namprd16.prod.outlook.com (2603:10b6:907:1::43) by PH7PR12MB9104.namprd12.prod.outlook.com (2603:10b6:510:2f3::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7339.39; Thu, 7 Mar 2024 12:40:33 +0000 Received: from CO1PEPF000042A8.namprd03.prod.outlook.com (2603:10b6:907:1:cafe::49) by MW2PR16CA0066.outlook.office365.com (2603:10b6:907:1::43) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.26 via Frontend Transport; Thu, 7 Mar 2024 12:40:33 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by CO1PEPF000042A8.mail.protection.outlook.com (10.167.243.37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7362.11 via Frontend Transport; Thu, 7 Mar 2024 12:40:32 +0000 Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 7 Mar 2024 06:40:31 -0600 Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB05.amd.com (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 7 Mar 2024 06:40:31 -0600 Received: from xcbayankuma40.xilinx.com (10.180.168.240) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.35 via Frontend Transport; Thu, 7 Mar 2024 06:40:30 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e54450b4-dc7f-11ee-a1ee-f123f15fe8a2 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ADEsEXqDv97laYcPccBjgvytDiQ7J6hxu6acZpQlc30abBFTvXcH0MD9DBT/JufTtqvujVYTaZdsXRPAaV9v1sNPeba0qXBLACoqYOZ5dxoUAQEy5x/L9PzPAH5D3EwS1a0eToVEdrbtaWnHyVY9IWszbBipc3sjs14NCufIiEpWRPFSQcBQF7TmOLOyzF8U5MfrTCZnyhHgWDwIdWsp1VlqupgdGuniQ63lwpTNYci1LHcKlH8N8DpjIvsa5ghZakWwrQbBSVVbZi17nZqChInMpNGy1gi2AhbMzgBkV0NVJX3xwUl1VSDa5yVy8ym2THEnIi+A0wIhaVqWqHzgKA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=WA09ySjvIBLO6YzmcvJCT2DSUP4qszeYzbwIgvcjmgo=; b=dWWt/OQDrpxXpc3I8+3dh4Zbu1ykD61CpE6f54nmTOQH5rY6StWtdiwglLcyC4jysBTrMMDTN7RS6gOPgOdpBRuAb8YKsyh1LA1Zhbcgo0WwLcT3bmB+kBWKFrn/A+GojdVNEl0/g7cNLuGgBiaQ8OTGoMBrfIMXPpr/nqz89xUKCrdswfFHrGHSdkAaBpxnGGR9Ey7WwqNxCX3CJ30yPLbqjHMHU/FurH+qJHgRTVN+x6YKL3uYp/9SVhaYCLxIpU4J16B5ZnKeTxb0BS/Qfu2mzoWtzfL2QLSw+enIw+KOmdhYShzpMaRSx35+OMnkaL4kCjlZCxiZOBXWC4RwEg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WA09ySjvIBLO6YzmcvJCT2DSUP4qszeYzbwIgvcjmgo=; b=U7ElEWWhOTreyUpZ1SEopPHCKqKwFpog543aYqem8H3QI05kJ2k+fgxXpJF3niDn/xVwi4ilkxkGj2FjhiaBTGFnd8dMv5zDu7HadZxnZOyaslczDDN491TzQ7b6qh+dZC7SMCjAj4SRfkmQJzd4oB5GwbMvU4Ojt5WrTsErWMk= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C From: Ayan Kumar Halder To: CC: , , , , , , Ayan Kumar Halder Subject: [XEN v6 2/3] xen/arm: arm64: Add emulation of Debug Data Transfer Registers Date: Thu, 7 Mar 2024 12:39:42 +0000 Message-ID: <20240307123943.1991755-3-ayan.kumar.halder@amd.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20240307123943.1991755-1-ayan.kumar.halder@amd.com> References: <20240307123943.1991755-1-ayan.kumar.halder@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain Received-SPF: None (SATLEXMB05.amd.com: ayan.kumar.halder@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CO1PEPF000042A8:EE_|PH7PR12MB9104:EE_ X-MS-Office365-Filtering-Correlation-Id: 77b989ad-e3b1-4ad5-2e4e-08dc3ea3c785 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: HrSmHpLnOl/0Yr5QPRBQkGykp7CFCTk/GuxNmWxoZxBik91Hvj/lpod08yF1DugowsLV8d+DwW2J9kb0RJhNUSufZtKoJ8Fk9WNl5O3b59Ci77YasLh8QYNNLBNr+u0IOsJOaYoyXfyYpqZLbSXdJ0yiu9aBIzK3Fz1Trr49xHfCqtS9Ug91MfxVGMu+Nj39l3ulbNo0Ok21/1vJwlsFWA9QWUUu5WDgBqbNRPIfGoD85ykGQ31AU6SVvEupl9ShyD5sTUWEa9+4CUvptbCmmtTIVoKKwPBc6TVhNrDHwbNeNXLShAjdnxhWe3T8Ex99mpwiQmgOe+5jlHe+/ZoVllrnzrSw47DBLtlAC53n1LY0fwDu4kWMJssOkYEEJT69fBvruiOMpHWGmfy45d6wzLScouqoBMx1fVAPy84aUA1/yotxNNzfQEp99FPf7sRMcvXEuWpAN5wgKFyg6EeOKoJvqlr9nEqYKkCzTeIqeItkyDXUk5YO4kPy031rzcqvd8vL+45E8C25EhyIzh3bKwEjAP+EQn9YBdiBTrOvqWdWpkSXB8kRC1dpdruVE0P42hLBHEvfD2nud1ZsjzreuAMnr+lYdtCPKjK19Q2UtNI40GbZPoyL9JgtDhQDiRLFuksxtkVslHseKBURQ8dE0TWwKVSHtpvnd5kSUTam/1YqcTnVbg8dWTWm8fLFfP63XQTkgG9MjpWn5P5PLctJHhu6FfrbZ1d12ITICXjocbV3A21LmaEm8V5n+hU9C/vz X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(36860700004)(82310400014)(376005);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Mar 2024 12:40:32.6190 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 77b989ad-e3b1-4ad5-2e4e-08dc3ea3c785 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CO1PEPF000042A8.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB9104 From: Michal Orzel Currently, if user enables HVC_DCC config option in Linux, it invokes access to debug data transfer registers (i.e. DBGDTRTX_EL0 on arm64, DBGDTRTXINT on arm32). As these registers are not emulated, Xen injects an undefined exception to the guest and Linux crashes. To prevent this crash, introduce a partial emulation of DBGDTR[TR]X_EL0 (these registers share the same encoding) as RAZ/WI and MDCCSR_EL0 as TXfull. Refer ARM DDI 0487J.a ID042523, D19.3.8, DBGDTRTX_EL0 "If TXfull is set to 1, set DTRRX and DTRTX to UNKNOWN". Thus, any OS is expected to read MDCCSR_EL0 and check for TXfull before using DBGDTRTX_EL0. Linux does it via hvc_dcc_init() ---> hvc_dcc_check(), and returns -ENODEV in case TXfull bit is still set after writing a test character. This way we prevent the guest from making use of HVC DCC as a console. Signed-off-by: Michal Orzel Signed-off-by: Ayan Kumar Halder --- Changes from v1 :- 1. DBGDTR_EL0 does not emulate RXfull. This is to avoid giving the OS any indication that the RX buffer is full and is waiting to be read. 2. In Arm32, DBGOSLSR is emulated. Also DBGDTRTXINT is emulated at EL0 only. 3. Fixed the commit message and inline code comments. v2 :- 1. Split the patch into two (separate patches for arm64 and arm32). 2. Removed the "fail" label. 3. Fixed the commit message. v3 :- 1. "HSR_SYSREG_MDCCSR_EL0" emulation differs based on whether partial_emulation_enabled is true or not. 2. If partial_emulation_enabled is false, then access to HSR_SYSREG_DBGDTR_EL0, HSR_SYSREG_DBGDTRTX_EL0 would lead to undefined exception. v4 :- 1. Invoked "goto fail" from "default:" to ensure compliance with MISRA 15.3. v5 :- 1. Fixed style issues. 2. Removed R-b. 3. Removed HSR_SYSREG_ prefixes from registers. SUPPORT.md | 5 ++ xen/arch/arm/arm64/vsysreg.c | 69 +++++++++++++++++++--------- xen/arch/arm/include/asm/arm64/hsr.h | 3 ++ 3 files changed, 56 insertions(+), 21 deletions(-) diff --git a/SUPPORT.md b/SUPPORT.md index b49da114ab..afbd820084 100644 --- a/SUPPORT.md +++ b/SUPPORT.md @@ -111,6 +111,11 @@ that would normally trigger a fault injection. Only the following system registers are security supported: + MDCCSR_EL0 + DBGDTR_EL0 + DBGDTRTX_EL0 + DBGDTRRX_EL0 + ### ARM Scalable Vector Extension (SVE/SVE2) Arm64 domains can use Scalable Vector Extension (SVE/SVE2). diff --git a/xen/arch/arm/arm64/vsysreg.c b/xen/arch/arm/arm64/vsysreg.c index b5d54c569b..c73b2c95ce 100644 --- a/xen/arch/arm/arm64/vsysreg.c +++ b/xen/arch/arm/arm64/vsysreg.c @@ -82,6 +82,7 @@ TVM_REG(CONTEXTIDR_EL1) void do_sysreg(struct cpu_user_regs *regs, const union hsr hsr) { + const struct hsr_sysreg sysreg = hsr.sysreg; int regidx = hsr.sysreg.reg; struct vcpu *v = current; @@ -159,9 +160,6 @@ void do_sysreg(struct cpu_user_regs *regs, * * Unhandled: * MDCCINT_EL1 - * DBGDTR_EL0 - * DBGDTRRX_EL0 - * DBGDTRTX_EL0 * OSDTRRX_EL1 * OSDTRTX_EL1 * OSECCR_EL1 @@ -171,12 +169,42 @@ void do_sysreg(struct cpu_user_regs *regs, */ case HSR_SYSREG_MDSCR_EL1: return handle_raz_wi(regs, regidx, hsr.sysreg.read, hsr, 1); + + /* + * Xen doesn't expose a real (or emulated) Debug Communications Channel + * (DCC) to a domain. Yet the Arm ARM implies this is not an optional + * feature. So some domains may start to probe it. For instance, the + * HVC_DCC driver in Linux (since f377775dc083 and at least up to v6.7), + * will try to write some characters and check if the transmit buffer + * has emptied. + */ case HSR_SYSREG_MDCCSR_EL0: /* + * By setting TX status bit (only if partial emulation is enabled) to + * indicate the transmit buffer is full, we would hint the OS that the + * DCC is probably not working. + * + * Bit 29: TX full + * * Accessible at EL0 only if MDSCR_EL1.TDCC is set to 0. We emulate that * register as RAZ/WI above. So RO at both EL0 and EL1. */ - return handle_ro_raz(regs, regidx, hsr.sysreg.read, hsr, 0); + return handle_ro_read_val(regs, regidx, hsr.sysreg.read, hsr, 0, + partial_emulation ? (1U << 29) : 0); + + case HSR_SYSREG_DBGDTR_EL0: + /* DBGDTR[TR]X_EL0 share the same encoding */ + case HSR_SYSREG_DBGDTRTX_EL0: + /* + * Emulate as RAZ/WI (only if partial emulation is enabled) to prevent + * injecting undefined exception. + * Accessible at EL0 only if MDSCR_EL1.TDCC is set to 0. We emulate that + * register as RAZ/WI. + */ + if ( !partial_emulation ) + goto fail; + return handle_raz_wi(regs, regidx, hsr.sysreg.read, hsr, 0); + HSR_SYSREG_DBG_CASES(DBGBVR): HSR_SYSREG_DBG_CASES(DBGBCR): HSR_SYSREG_DBG_CASES(DBGWVR): @@ -394,26 +422,25 @@ void do_sysreg(struct cpu_user_regs *regs, * And all other unknown registers. */ default: - { - const struct hsr_sysreg sysreg = hsr.sysreg; - - gdprintk(XENLOG_ERR, - "%s %d, %d, c%d, c%d, %d %s x%d @ 0x%"PRIregister"\n", - sysreg.read ? "mrs" : "msr", - sysreg.op0, sysreg.op1, - sysreg.crn, sysreg.crm, - sysreg.op2, - sysreg.read ? "=>" : "<=", - sysreg.reg, regs->pc); - gdprintk(XENLOG_ERR, - "unhandled 64-bit sysreg access %#"PRIregister"\n", - hsr.bits & HSR_SYSREG_REGS_MASK); - inject_undef_exception(regs, hsr); - return; - } + goto fail; } regs->pc += 4; + return; + + fail: + gdprintk(XENLOG_ERR, + "%s %d, %d, c%d, c%d, %d %s x%d @ 0x%"PRIregister"\n", + sysreg.read ? "mrs" : "msr", + sysreg.op0, sysreg.op1, + sysreg.crn, sysreg.crm, + sysreg.op2, + sysreg.read ? "=>" : "<=", + sysreg.reg, regs->pc); + gdprintk(XENLOG_ERR, + "unhandled 64-bit sysreg access %#"PRIregister"\n", + hsr.bits & HSR_SYSREG_REGS_MASK); + inject_undef_exception(regs, hsr); } /* diff --git a/xen/arch/arm/include/asm/arm64/hsr.h b/xen/arch/arm/include/asm/arm64/hsr.h index e691d41c17..1495ccddea 100644 --- a/xen/arch/arm/include/asm/arm64/hsr.h +++ b/xen/arch/arm/include/asm/arm64/hsr.h @@ -47,6 +47,9 @@ #define HSR_SYSREG_OSDLR_EL1 HSR_SYSREG(2,0,c1,c3,4) #define HSR_SYSREG_DBGPRCR_EL1 HSR_SYSREG(2,0,c1,c4,4) #define HSR_SYSREG_MDCCSR_EL0 HSR_SYSREG(2,3,c0,c1,0) +#define HSR_SYSREG_DBGDTR_EL0 HSR_SYSREG(2,3,c0,c4,0) +#define HSR_SYSREG_DBGDTRTX_EL0 HSR_SYSREG(2,3,c0,c5,0) +#define HSR_SYSREG_DBGDTRRX_EL0 HSR_SYSREG(2,3,c0,c5,0) #define HSR_SYSREG_DBGBVRn_EL1(n) HSR_SYSREG(2,0,c0,c##n,4) #define HSR_SYSREG_DBGBCRn_EL1(n) HSR_SYSREG(2,0,c0,c##n,5) -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Thu Mar 07 12:40:42 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 12:40:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689877.1075303 (Exim 4.92) (envelope-from ) id 1riD3C-0006lw-1o; Thu, 07 Mar 2024 12:40:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689877.1075303; Thu, 07 Mar 2024 12:40:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riD3B-0006lk-UV; Thu, 07 Mar 2024 12:40:41 +0000 Received: by outflank-mailman (input) for mailman id 689877; Thu, 07 Mar 2024 12:40:41 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riD3B-00060p-3c for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 12:40:41 +0000 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on20601.outbound.protection.outlook.com [2a01:111:f403:2418::601]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id e6b5ae22-dc7f-11ee-a1ee-f123f15fe8a2; Thu, 07 Mar 2024 13:40:39 +0100 (CET) Received: from BYAPR01CA0014.prod.exchangelabs.com (2603:10b6:a02:80::27) by CY8PR12MB8195.namprd12.prod.outlook.com (2603:10b6:930:77::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7339.39; Thu, 7 Mar 2024 12:40:35 +0000 Received: from SJ1PEPF00001CEA.namprd03.prod.outlook.com (2603:10b6:a02:80:cafe::63) by BYAPR01CA0014.outlook.office365.com (2603:10b6:a02:80::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7339.38 via Frontend Transport; Thu, 7 Mar 2024 12:40:35 +0000 Received: from SATLEXMB03.amd.com (165.204.84.17) by SJ1PEPF00001CEA.mail.protection.outlook.com (10.167.242.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7362.11 via Frontend Transport; Thu, 7 Mar 2024 12:40:35 +0000 Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 7 Mar 2024 06:40:34 -0600 Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB05.amd.com (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 7 Mar 2024 06:40:34 -0600 Received: from xcbayankuma40.xilinx.com (10.180.168.240) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.35 via Frontend Transport; Thu, 7 Mar 2024 06:40:33 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e6b5ae22-dc7f-11ee-a1ee-f123f15fe8a2 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YAyXdCV/J4N0JT8gTDwrBJlmEwmiYLfWetPGYHjEsnjjTWHKMx5czvMN4TPnxyvkG0j8Pdw0g/fMJOlhINB80ruIzliCnVbW0VtgMj3NmSFDUb7YIsyG6QPI5bnXbtekaS+EOUEGeOEFbqvFvu0sCAGYVHXesL9avx24QhOQREuMx06SJv9VJ5ST73XWd9yc6Gh+Dosui3ZDAw6qKTwZJMO/m8LXHEJY5ujvyNPCEGOsj0y23IxUVmD2UW37EqUjkYRKZaVBfSMQYOmyaThjIZbD79bHh9DGXwbamuo6anwrE1TaJ3Osh45pcxnmDeGga/37bieb+gfbSjhh+7V+UA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=OXmedK0QVYV/fwcpnxU7YEJJLCulbSQoe7KyRDQYIbc=; b=A5FpYE28p1/OmPdw1GyU58E/7kZYec8rSDxJi8+vtjxJZpVpBrn5tMcQy0fkT3onOQ6/39AIh3eLkyFHLMa2k2LReVhl3SCiuIk1BtE8PtWmjz+7rlT+RDwMbMVSEzDm8qRBmSBNVnKzwMKi4QFgXpIM3gSK18RyAEKHzkyGld/unzs5WCBva33ia0Jf57+jG5uwUyKoEN6fb0o+4Pd2Cz1F/C9zLqaiZfHZO9ODRcvoQ9ac1FlwSOE7hUgFwstcecDndK5viB/aVWSzm7Tq+UVDh9/qkfnUwI5XLVSxCg5FKUB9PkysgD59qJJqShiqsi/tcvLgc3H5PqsUcjFTeA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OXmedK0QVYV/fwcpnxU7YEJJLCulbSQoe7KyRDQYIbc=; b=oecZOkyH1Ab1KnnO+55Mds7cfzkAljyfBEmYyLtW2k25sMKzEflEI0xIP3qOH8zxIFco4dmLeqGJ6ZgDYTRDr17UaX5A0jo+JxDP41+1xep9Gh9hMKOO3xGzgTibLlH1a0dr3NM26wHpIT/TV9lbTaEF4yeCXXYL7CSrmFp42IA= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C From: Ayan Kumar Halder To: CC: , , , , , , Ayan Kumar Halder Subject: [XEN v6 3/3] xen/arm: arm32: Add emulation of Debug Data Transfer Registers Date: Thu, 7 Mar 2024 12:39:43 +0000 Message-ID: <20240307123943.1991755-4-ayan.kumar.halder@amd.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20240307123943.1991755-1-ayan.kumar.halder@amd.com> References: <20240307123943.1991755-1-ayan.kumar.halder@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain Received-SPF: None (SATLEXMB05.amd.com: ayan.kumar.halder@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ1PEPF00001CEA:EE_|CY8PR12MB8195:EE_ X-MS-Office365-Filtering-Correlation-Id: 41aa4874-edf2-44d1-00a1-08dc3ea3c8fc X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: hPnoC1wDIG/EhSH152dotqXoK99hU8fT0/V+facNvujZA1JOsAhGqjHRegtozf/bz0dhuhuzs/4hUMAMSxFGTrlXAO7rOanq1wIJC3H11p5NF/oEfoH8p0z+937nlEJfFUxhSoxnEEK8e+tIieI8wEmFKGxdPe834H0/0oCAgM+KbKFCbkWCQ5uqVA6H4WvK1xLjy4YoKtknL/I3QP6ZBR60AmgyXzXQ+YDZuPjQAcavybVmekIa1qyABOcmvDPwyP6OMKJX1T3aap0rMVXD9hgjXhNwYo1CpZJH/EylQ9RsbC6X78STrA+so85njxKBYyEEA28bmDP+lGpmTJJTkV0+GjUAD+ws/S2w2v4AW6s2lA48pjf5dkIeKxu5dOPsElbrDgEOdwQNjAsVIYb7djNlL16JippRgTQvYposCtmoQSKTsxU5BPz7nSF5qNQGcsnRwCHwk18v6O2CLgtTEmj0/39DEgmVKshW6F5ampNX7iTqieds78rk1j48+iWiOHysGogXZxjddflD4/wRP++jDA37W3vS57eGQqZ0CtlmfaUw0pgD5pXWujRuHvudfOWrmKE+r1c6nU1mRRAfzt2Cz+66Fj/vWcW0YO+btRX97+N1B63KEU65MkH/PnHVLgUA+xmZGs5l8P1nympwAojG/p+Nt6/VhZbDxZh65or5gueyEFpyatiEb+YbT9Eqc4fUfQd6gqG/WAO5Ber/GA8b+lhDgjdpEYCfnt5UEOVcyhx5HZaLqznGEHBTMQTP X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(82310400014)(36860700004)(376005);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Mar 2024 12:40:35.1223 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 41aa4874-edf2-44d1-00a1-08dc3ea3c8fc X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SJ1PEPF00001CEA.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB8195 When user enables HVC_DCC config option in Linux, it invokes access to debug transfer register (i.e. DBGDTRTXINT). As this register is not emulated, Xen injects an undefined exception to the guest and Linux crashes. To prevent this crash, introduce a partial emulation of DBGDTR[TR]XINT (these registers share the same encoding) as RAZ/WI and DBGDSCRINT as TXfull. Refer ARM DDI 0487J.a ID042523, G8.3.19, DBGDTRTXint: "If TXfull is set to 1, set DTRTX to UNKNOWN". As a pre-requisite, DBGOSLSR should be emulated in the same way as its AArch64 variant (i.e. OSLSR_EL1). This is to ensure that DBGOSLSR.OSLK is 0, which allows us to skip the emulation of DBGDSCREXT (TXfull is treated as UNK/SBZP) and focus on DBGDSCRINT. DBGOSLSR.OSLM[1] is set to 1 to mantain consistency with Arm64. Take the opportunity to fix the minimum EL for DBGDSCRINT, which should be 0. Signed-off-by: Ayan Kumar Halder Signed-off-by: Michal Orzel --- Changes from v1 :- 1. DBGDTR_EL0 does not emulate RXfull. This is to avoid giving the OS any indication that the RX buffer is full and is waiting to be read. 2. In Arm32, DBGOSLSR is emulated. Also DBGDTRTXINT is emulated at EL0 only. 3. Fixed the commit message and inline code comments. v2 :- 1. Split the patch into two (separate patches for arm64 and arm32). 2. Fixed in line comments and style related issues. 3. Updated commit message to mention DBGDSCRINT handling. v3 :- 1. The original emulation of DBGDSCRINT is retained when 'partial_emulation' is false. 2. If 'partial_emulation' is false, then access to DBGDTRTXINT will lead to undefined exception. v4 :- 1. Invoked "goto fail" from "default:" to ensure compliance with MISRA 15.3. v5 :- 1. Reword the commit message 2. Remove the 'return' at the end of function. SUPPORT.md | 3 ++ xen/arch/arm/include/asm/cpregs.h | 2 + xen/arch/arm/vcpreg.c | 62 ++++++++++++++++++++++--------- 3 files changed, 49 insertions(+), 18 deletions(-) diff --git a/SUPPORT.md b/SUPPORT.md index afbd820084..e0ff30cfe9 100644 --- a/SUPPORT.md +++ b/SUPPORT.md @@ -115,6 +115,9 @@ Only the following system registers are security supported: DBGDTR_EL0 DBGDTRTX_EL0 DBGDTRRX_EL0 + DBGDSCRINT + DBGDTRTXINT + DBGDTRRXINT ### ARM Scalable Vector Extension (SVE/SVE2) diff --git a/xen/arch/arm/include/asm/cpregs.h b/xen/arch/arm/include/asm/cpregs.h index 6b083de204..aec9e8f329 100644 --- a/xen/arch/arm/include/asm/cpregs.h +++ b/xen/arch/arm/include/asm/cpregs.h @@ -75,6 +75,8 @@ #define DBGDIDR p14,0,c0,c0,0 /* Debug ID Register */ #define DBGDSCRINT p14,0,c0,c1,0 /* Debug Status and Control Internal */ #define DBGDSCREXT p14,0,c0,c2,2 /* Debug Status and Control External */ +#define DBGDTRRXINT p14,0,c0,c5,0 /* Debug Data Transfer Register, Receive */ +#define DBGDTRTXINT p14,0,c0,c5,0 /* Debug Data Transfer Register, Transmit */ #define DBGVCR p14,0,c0,c7,0 /* Vector Catch */ #define DBGBVR0 p14,0,c0,c0,4 /* Breakpoint Value 0 */ #define DBGBCR0 p14,0,c0,c0,5 /* Breakpoint Control 0 */ diff --git a/xen/arch/arm/vcpreg.c b/xen/arch/arm/vcpreg.c index a2d0500704..b203f4a142 100644 --- a/xen/arch/arm/vcpreg.c +++ b/xen/arch/arm/vcpreg.c @@ -493,11 +493,12 @@ void do_cp14_32(struct cpu_user_regs *regs, const union hsr hsr) * ARMv8 (DDI 0487A.d): D1-1509 Table D1-58 * * Unhandled: - * DBGOSLSR * DBGPRCR */ case HSR_CPREG32(DBGOSLAR): return handle_wo_wi(regs, regidx, cp32.read, hsr, 1); + case HSR_CPREG32(DBGOSLSR): + return handle_ro_read_val(regs, regidx, cp32.read, hsr, 1, 1U << 3); case HSR_CPREG32(DBGOSDLR): return handle_raz_wi(regs, regidx, cp32.read, hsr, 1); @@ -509,8 +510,6 @@ void do_cp14_32(struct cpu_user_regs *regs, const union hsr hsr) * * Unhandled: * DBGDCCINT - * DBGDTRRXint - * DBGDTRTXint * DBGWFAR * DBGDTRTXext * DBGDTRRXext, @@ -548,12 +547,27 @@ void do_cp14_32(struct cpu_user_regs *regs, const union hsr hsr) break; } + /* + * Xen doesn't expose a real (or emulated) Debug Communications Channel + * (DCC) to a domain. Yet the Arm ARM implies this is not an optional + * feature. So some domains may start to probe it. For instance, the + * HVC_DCC driver in Linux (since f377775dc083 and at least up to v6.7), + * will try to write some characters and check if the transmit buffer has + * emptied. + */ case HSR_CPREG32(DBGDSCRINT): /* - * Read-only register. Accessible by EL0 if DBGDSCRext.UDCCdis - * is set to 0, which we emulated below. + * By setting TX status bit (only if partial emulation is enabled) to + * indicate the transmit buffer is full, we would hint the OS that the + * DCC is probably not working. + * + * Bit 29: TX full + * + * Accessible at EL0 only if DBGDSCRext.UDCCdis is set to 0. We emulate + * this as RAZ/WI in the next case. So RO at both EL0 and EL1. */ - return handle_ro_raz(regs, regidx, cp32.read, hsr, 1); + return handle_ro_read_val(regs, regidx, cp32.read, hsr, 0, + partial_emulation ? (1U << 29) : 0); case HSR_CPREG32(DBGDSCREXT): /* @@ -562,6 +576,18 @@ void do_cp14_32(struct cpu_user_regs *regs, const union hsr hsr) */ return handle_raz_wi(regs, regidx, cp32.read, hsr, 1); + /* DBGDTR[TR]XINT share the same encoding */ + case HSR_CPREG32(DBGDTRTXINT): + /* + * Emulate as RAZ/WI (only if partial emulation is enabled) to prevent + * injecting undefined exception. + * Accessible at EL0 only if DBGDSCREXT is set to 0. We emulate that + * register as RAZ/WI. + */ + if ( !partial_emulation ) + goto fail; + return handle_raz_wi(regs, regidx, cp32.read, hsr, 0); + case HSR_CPREG32(DBGVCR): case HSR_CPREG32(DBGBVR0): case HSR_CPREG32(DBGBCR0): @@ -591,17 +617,20 @@ void do_cp14_32(struct cpu_user_regs *regs, const union hsr hsr) * And all other unknown registers. */ default: - gdprintk(XENLOG_ERR, - "%s p14, %d, r%d, cr%d, cr%d, %d @ 0x%"PRIregister"\n", - cp32.read ? "mrc" : "mcr", - cp32.op1, cp32.reg, cp32.crn, cp32.crm, cp32.op2, regs->pc); - gdprintk(XENLOG_ERR, "unhandled 32-bit cp14 access %#"PRIregister"\n", - hsr.bits & HSR_CP32_REGS_MASK); - inject_undef_exception(regs, hsr); - return; + goto fail; } advance_pc(regs, hsr); + return; + + fail: + gdprintk(XENLOG_ERR, + "%s p14, %d, r%d, cr%d, cr%d, %d @ 0x%"PRIregister"\n", + cp32.read ? "mrc" : "mcr", + cp32.op1, cp32.reg, cp32.crn, cp32.crm, cp32.op2, regs->pc); + gdprintk(XENLOG_ERR, "unhandled 32-bit cp14 access %#"PRIregister"\n", + hsr.bits & HSR_CP32_REGS_MASK); + inject_undef_exception(regs, hsr); } void do_cp14_64(struct cpu_user_regs *regs, const union hsr hsr) @@ -659,10 +688,7 @@ void do_cp14_dbg(struct cpu_user_regs *regs, const union hsr hsr) * ARMv8 (DDI 0487A.d): D1-1509 Table D1-58 * * Unhandled: - * DBGDTRTXint - * DBGDTRRXint - * - * And all other unknown registers. + * All unknown registers. */ gdprintk(XENLOG_ERR, "%s p14, %d, r%d, r%d, cr%d @ 0x%"PRIregister"\n", -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Thu Mar 07 12:44:36 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 12:44:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689882.1075312 (Exim 4.92) (envelope-from ) id 1riD6x-0000WN-MJ; Thu, 07 Mar 2024 12:44:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689882.1075312; Thu, 07 Mar 2024 12:44:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riD6x-0000WG-JZ; Thu, 07 Mar 2024 12:44:35 +0000 Received: by outflank-mailman (input) for mailman id 689882; Thu, 07 Mar 2024 12:44:34 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riD6v-0000W6-V9 for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 12:44:33 +0000 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on20611.outbound.protection.outlook.com [2a01:111:f400:7e88::611]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 7155abc5-dc80-11ee-a1ee-f123f15fe8a2; Thu, 07 Mar 2024 13:44:32 +0100 (CET) Received: from DS7PR03CA0202.namprd03.prod.outlook.com (2603:10b6:5:3b6::27) by CY8PR12MB8067.namprd12.prod.outlook.com (2603:10b6:930:74::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7339.39; Thu, 7 Mar 2024 12:44:29 +0000 Received: from CY4PEPF0000FCC4.namprd03.prod.outlook.com (2603:10b6:5:3b6:cafe::a9) by DS7PR03CA0202.outlook.office365.com (2603:10b6:5:3b6::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.27 via Frontend Transport; Thu, 7 Mar 2024 12:44:29 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by CY4PEPF0000FCC4.mail.protection.outlook.com (10.167.242.106) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7362.11 via Frontend Transport; Thu, 7 Mar 2024 12:44:29 +0000 Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 7 Mar 2024 06:44:26 -0600 Received: from [172.31.100.92] (10.180.168.240) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.35 via Frontend Transport; Thu, 7 Mar 2024 06:44:24 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 7155abc5-dc80-11ee-a1ee-f123f15fe8a2 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Efe5HahjTkY8+5D7nmhm+VG6vfxltcEwlvw8IkYtoI0FUrXvN6Hs/9BIT/926KMGGvI+wyrtHJwtobIbs4S1z/pY4zy+4SAAW3jQVM3YowePgOvpUJ83pYTgCItQkc7hgyQAxFQu6rG4M44bYgpFNueylxe4E5pQUoif/+6tqLSXcOrNts7THfnjgGbgiPZuI0LVyU6wUSvmNfF/HgAdxc0VAM5bskfFielOOSio/sEHBW0frhF++Lqzx3ELpTt3vJikzSd7292FnOcKSNSjS90eSSDx4APEkmqfz1FeeBY3zH/qFC4YYUa+QMsP5VuCE8bxZekMtUtOS4HFrsNPkg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Z1tEW7MOkAIHsGVkrducJxUr8jRNcyh6yysEubrAtEo=; b=L73Y0C7f+6EOWtYZiCUEWJQsSPjlYohoqFxzdj5gbZpS8pPo8uijDotI1r+xmknXn3cG/fd1jVBnA1WW816+aokNRFZKgj69bQpTFY7XS4Z1RUJJZgIJgeP+KMUStIR2c5Uyj1yR5hLzYFdsrN+t/B/36I2VK0mWDSL/F+OItilsWT3SRoqKFbAeDVxGy3Cv9FBmjvkxWyTSjxpPlYYXJKfZ4ZUZXeopAGaobDXKP97dpfOOjfAe0W2OxIL5QCaEw786KgQ2+qXwh+JRchOT+ofmDrjliTmMZXIRoDAoqnLqu7JbUwCMdhqMFGGIRj7ufEEos/JqNBNKWFrterqlJA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Z1tEW7MOkAIHsGVkrducJxUr8jRNcyh6yysEubrAtEo=; b=OY9XqOA/ucq5GGNfBsCD7s6TGgeQtY91F2fhET9HNsnufFadOVhH8dyJoeU/CN0hZdzflHnlP5r8cckxClK6fMBCaW4+LXpgNr+wk2eKtL58qHZpyzB6KURP3LGyffGJhTW7dfqa7BdQXYoRTRoNuzJkJv3wTMkn3o7Qzxrf1LE= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C Message-ID: Date: Thu, 7 Mar 2024 20:44:24 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] tools/9pfsd: Fix build error caused by strerror_r() Content-Language: en-US From: Henry Wang To: Jan Beulich CC: Wei Liu , Anthony PERARD , Juergen Gross , References: <20240307103847.3710737-1-xin.wang2@amd.com> <8428e980-ac88-40bb-8334-d52deeb52bb0@suse.com> <87b4f7fc-29a8-4201-83c5-afb9169a222d@amd.com> In-Reply-To: <87b4f7fc-29a8-4201-83c5-afb9169a222d@amd.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: None (SATLEXMB04.amd.com: xin.wang2@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CY4PEPF0000FCC4:EE_|CY8PR12MB8067:EE_ X-MS-Office365-Filtering-Correlation-Id: 2fbedf34-4c17-4912-4b34-08dc3ea4549b X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: JoLA1M8DrXAm3sUAwWibnHT3PlpmNrO5+6D6tkXPqOB+VEkvNEy/8Ii5Rrc9DWAf1o+WxPoqzEfW46SnKDCt/cKNaSInNBiU46rjyoVZ7/b2GA3C5cZzQa1hEDE/cQc2sIvG0SoGQanzNRXuNAhOHjDA9q4nt3IqZ6wt2F2JD9j59T4rsmUAOjTIVpxWWLCnIosDvWokEZjzWsr65vhc9pK5L102rm8yVN79e0cuemRuPJj4Zm6/qLNo1MHhVBV0lHxl1DaWoPiEayDk5mb2sab+rZ7opG1GG0AFn4p5w0JP2oHK8z5oxaPc+Jz4twyxt6F3VXVPeqXPfTETFHW6PvQHe2AnQpDOjGwgIxlfocuze9yMwrsIxMN57XLD/XhQxc4ef9ap2muK9t9CI2TyaM5yEdly6dUv+WmQq7o38CFFruXCXwBdfWq5BcHRYM77UC9uF3CpF3+SLZjxfpJ8ACAMowAgOl6l4qrwAl7hPcOFoiNKwMA1d/MfSMUbBsifRTO5WaT40SsE67sX8sWINgDTA1OYlQnIbp4ucmYrICBRF+Q8k1q0DJL/gQcCl6J4MGdFfAvmyLecYILAgsQ6S9VMJDynQPftA3l60ThdihuV3wTZCFN4omWDwBg4rDJV0zs0PmOb3BP3NaatbcLcCXQIeJ/WqSbur71nbg+VImzUMR57lOHXeozpVftXCpVT2uhPmpL6ratT/s8L7gk2BMqJqYDx0PNqwbjiyVbwSeGVRTwJc/e4G+vVaPwrZbCY X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(82310400014)(36860700004)(376005);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Mar 2024 12:44:29.3852 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 2fbedf34-4c17-4912-4b34-08dc3ea4549b X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CY4PEPF0000FCC4.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB8067 On 3/7/2024 8:19 PM, Henry Wang wrote: >>      len = min(strlen(str), ring->ring_size - 1); > > This actually will fire below errors on my build env, hence I > separated them with a different variable. > > tools/include/xen-tools/common-macros.h:38:21: error: comparison of > distinct pointer types lacks a cast [-Werror] > |    38 |         (void) (&_x == &_y); \ > |       |                     ^~ > | io.c:695:11: note: in expansion of macro 'min' > |   695 |     len = min(strlen(str), MAX_ERRSTR_LEN - 1);; > |       |           ^~~ > | cc1: all warnings being treated as errors > >>      memcpy(ring->buffer, str, len); >>      ((char *)ring->buffer)[len] = '\0'; >>      pthread_mutex_unlock(&mutex); > > I will follow your style in V3 if you don't have any specific comment > on the error that I posted above (plus also not strongly disagree with > my approach in v2). In fact I think ``` len = min(strlen(str), (size_t)(MAX_ERRSTR_LEN - 1)); ``` is better. Kind regards, Henry > Kind regards, > Henry > >> Jan From xen-devel-bounces@lists.xenproject.org Thu Mar 07 13:02:07 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 13:02:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689889.1075322 (Exim 4.92) (envelope-from ) id 1riDNZ-0005wc-Tn; Thu, 07 Mar 2024 13:01:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689889.1075322; Thu, 07 Mar 2024 13:01:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riDNZ-0005wV-Qw; Thu, 07 Mar 2024 13:01:45 +0000 Received: by outflank-mailman (input) for mailman id 689889; Thu, 07 Mar 2024 13:01:44 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riDNY-0005wP-5P for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 13:01:44 +0000 Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [2a00:1450:4864:20::12c]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id d88b4d0d-dc82-11ee-afda-a90da7624cb6; Thu, 07 Mar 2024 14:01:43 +0100 (CET) Received: by mail-lf1-x12c.google.com with SMTP id 2adb3069b0e04-513181719easo657136e87.3 for ; Thu, 07 Mar 2024 05:01:43 -0800 (PST) Received: from [192.168.206.239] ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id j16-20020ac253b0000000b005131cb35b42sm3030452lfh.298.2024.03.07.05.01.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Mar 2024 05:01:42 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d88b4d0d-dc82-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709816503; x=1710421303; darn=lists.xenproject.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=V1y2FJyPs+k3PDp6e5opcymWlk+q387INNZNDKg1BzA=; b=kJKX+51zS09OK0cy5QW/lDHVK8pw6MTJYPs7wIilkeSXPbWCZxtSvO3zQ3bl9/v/08 ZZgaQfFWVKrQm4HDfNt8bOnTMDqJwOMA1Pm7be1v0uAY1MfRo9VmUkCPc8zIziyFy8uD Ghi/Z0dCHm/2kP1/lSydNhy+mPmLndKmRSc+il5Isftm3iHDGbVTtLE372MBUmsufdNq 5+fsfTo+DWY6Tl4VDqcj6o1QQQcDhk62f6lHabsEp8AFEKs9fy6FbhU5rkwLYg1IRbSK xLkArOBOIeeLy+kM0kS1Q7peqKhM2mgzh0xZin/9JKZ0yBShVnvGmqi/2kxJpd40eeHG Nvkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709816503; x=1710421303; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=V1y2FJyPs+k3PDp6e5opcymWlk+q387INNZNDKg1BzA=; b=b88g3G6M5yZeHruZFGOmEUlXFs3jmQ0e6tWOULKJCIbMageBbYSDbWGHSMrPMV5SMT 5hsyHBQSmstpfDhP4oLIfZd5kNXtxlf/Tr53mncplVxQr+sIZ5lOq0IGktv5riTHRdWF p6qCOy8iyp93iaYaCKBwAesAVczidOOTM7WmxuizBnz2aygJLCsQvGhanmACluo4gLmj XDYE7lIpbLYmKJ7Q+3z+GqDGODlmRL/QsT7S5jrJjThZ0DTPfdi9ZgMBAKfgGqtgy3Xl YppQe5YHRC5W2AhIlpCXLWU+LyDfTHc6gejFGADNvmsdUumQrs/40ud3n9De60zjmH7f yZTA== X-Forwarded-Encrypted: i=1; AJvYcCUdVrsrIdGIUHoObJECovdER38qgfuqDaLMYS6A8RZaJhLOVVrPIJlbxGrGisIs1n0UejYH9+76bfGuXub4vl9tdAkiPHDI7lU1twwILfw= X-Gm-Message-State: AOJu0YwMEbSVdfNOFFycZiXGybwEpkDDY9wlzQ/JlwMnOEcC7HTCFBvI tdQw7KVuHLX4IA5DgU0vxNpBLeBI2nlj31o2xdu+TKn1HCA4UDSh X-Google-Smtp-Source: AGHT+IFMOjQqW9/32uytgFsRj9xGJUyGSpduAvI/Se53uWer3Rz4KEz9wCS2rGwNmMWvSI7P9prWNQ== X-Received: by 2002:a05:6512:4851:b0:513:54c6:9f68 with SMTP id ep17-20020a056512485100b0051354c69f68mr1285058lfb.18.1709816502471; Thu, 07 Mar 2024 05:01:42 -0800 (PST) Message-ID: Subject: Re: [PATCH v5 12/23] xen/riscv: introduce io.h From: Oleksii To: Jan Beulich Cc: Alistair Francis , Bob Eshleman , Connor Davis , Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu , xen-devel@lists.xenproject.org Date: Thu, 07 Mar 2024 14:01:41 +0100 In-Reply-To: <807c31d5-0c5a-4646-ba90-2f284289069f@suse.com> References: <807c31d5-0c5a-4646-ba90-2f284289069f@suse.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.50.2 (3.50.2-1.fc39) MIME-Version: 1.0 On Wed, 2024-03-06 at 15:13 +0100, Jan Beulich wrote: > > +/* Generic IO read/write.=C2=A0 These perform native-endian accesses. > > */ > > +static inline void __raw_writeb(uint8_t val, volatile void __iomem > > *addr) > > +{ > > +=C2=A0=C2=A0=C2=A0 asm volatile ( "sb %0, 0(%1)" : : "r" (val), "r" (a= ddr) ); > > +} >=20 > I realize this is like Linux has it, but how is the compiler to know > that > *addr is being access here?=C2=A0 Assembler syntax told compiler that. 0(%1) - means that the memory location pointed to by the address in register %1. > If the omission of respective constraints here > and below is intentional, I think a comment (covering all instances) > is > needed. Note that while supposedly cloned from Arm code, Arm variants > do > have such constraints in Linux. >=20 It uses this constains only in arm32: #define __raw_writeb __raw_writeb static inline void __raw_writeb(u8 val, volatile void __iomem *addr) { asm volatile("strb %1, %0" : : "Qo" (*(volatile u8 __force *)addr), "r" (val)); } But in case of arm64: #define __raw_writeb __raw_writeb static __always_inline void __raw_writeb(u8 val, volatile void __iomem *addr) { asm volatile("strb %w0, [%1]" : : "rZ" (val), "r" (addr)); } And again looking at the defintion they use different option of strb instruction, and in case of strb they use [%1] which tells compiler that %1 is addressed which should be dereferenced. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Thu Mar 07 13:04:17 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 13:04:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689891.1075333 (Exim 4.92) (envelope-from ) id 1riDQ0-0006rv-AB; Thu, 07 Mar 2024 13:04:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689891.1075333; Thu, 07 Mar 2024 13:04:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riDQ0-0006ro-6S; Thu, 07 Mar 2024 13:04:16 +0000 Received: by outflank-mailman (input) for mailman id 689891; Thu, 07 Mar 2024 13:04:14 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riDPy-0006rg-8K for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 13:04:14 +0000 Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [2607:f8b0:4864:20::1032]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 30e7f194-dc83-11ee-a1ee-f123f15fe8a2; Thu, 07 Mar 2024 14:04:12 +0100 (CET) Received: by mail-pj1-x1032.google.com with SMTP id 98e67ed59e1d1-29ae4c7da02so523993a91.2 for ; Thu, 07 Mar 2024 05:04:12 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 30e7f194-dc83-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709816651; x=1710421451; darn=lists.xenproject.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=K8KoaNI1LMVC8yIyXhS5P9xvcqQjNdkTXiETLJzEH24=; b=sI4mt2rcv+FLiRO/LyCnirgVg1V/U2PQkTq8ZECujlIBaU5HUbF2ZAJUWghiR9BbqF iQvzHWcGBSXVC1oQ6FF/bRcZ29eh9NruQwQuYJ/6j+YI2kCwJ3LP7c95Xyi44OhdgTzK +m6qBfKaOVFfxZ/KhGPkZ1xS6SPwMJzAkeoQo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709816651; x=1710421451; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=K8KoaNI1LMVC8yIyXhS5P9xvcqQjNdkTXiETLJzEH24=; b=A8gQY5Dy0vnawUCaY2Rj7XCaXKQQJbHEGNizOqtgnibUZaggb3S6HQ/ci2sO/6QteU Qh+kyNoVcfR55XaTk2R/TN9lr+v3Qlf/LzoSA6idStA9DfhplI0LCEWlKLeZ+wXTz+yw uO+8NlqBbUvxsJ+P9ly5c2rvyl9c5czj98pBI9RnfMn330E3nJCR3xOA1ye7JHxlOAnF ZrEwwKxxTQRLwScMz9fOg585KUSm2co3DwSP4bEBm3fUj+5wmM3di9lvNx1XQvN2ypJb /ulYaBsEn2lDYEpY5AfMqCgVKzUn6C5Csb5FPndEx1hCBafxYA+McIdvOjAZfjkmPxmm bPTw== X-Forwarded-Encrypted: i=1; AJvYcCXNuilteRBilNS7AAETSsBkLpewngTaCS+XSqjDciT3glHyXEwP1EmzChi/zBttlTU3nCcbmCJTenfgzT5ii6XGdp1+p5YukNLUN+2H+b4= X-Gm-Message-State: AOJu0YzacrymtCfLetFHr+TdyCvBabQZKdfQlVbHeXbP4RaySSEiqCwH DbF1G9Nr1pyHYVFBSryAKzyGs2f+x+6M29VXxbT01/10lKJiUKAPHjmmHOYcsINSz2XNDxWg1o/ GreopHPpHl0KPpcpa0xYJbV0xXN740PBfVhCc X-Google-Smtp-Source: AGHT+IHTzmzrNV39VVqUwCjVMBqXjqhLlCwObB+zNLHSNIPP6JFCsXE95Wdry7ezSqDUwY+jsaDP5IhghpAJEliInRs= X-Received: by 2002:a17:90b:78a:b0:299:3efe:8209 with SMTP id l10-20020a17090b078a00b002993efe8209mr14005945pjz.4.1709816650717; Thu, 07 Mar 2024 05:04:10 -0800 (PST) MIME-Version: 1.0 References: <20240305121121.3527944-1-andrew.cooper3@citrix.com> <20240305121121.3527944-3-andrew.cooper3@citrix.com> <87b82706-f538-4807-abaf-1e59cebd286b@suse.com> <82126c3a-0cde-452f-86aa-2571482f42aa@citrix.com> <76ce9dcf-8cac-44b3-9550-f516024bad6e@suse.com> <9e827057-9306-4a2a-8816-410661bf8892@citrix.com> <818ac202-5473-4638-b140-45272b1041ed@suse.com> In-Reply-To: From: Ross Lagerwall Date: Thu, 7 Mar 2024 13:03:58 +0000 Message-ID: Subject: Re: [PATCH 2/3] xen/virtual-region: Include rodata pointers To: Andrew Cooper Cc: Jan Beulich , Konrad Rzeszutek Wilk , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Mar 7, 2024 at 12:16=E2=80=AFPM Andrew Cooper wrote: > > On 07/03/2024 11:58 am, Jan Beulich wrote: > > On 07.03.2024 12:31, Andrew Cooper wrote: > >> > >> The thing called virtual_region already describes 6 ranges, and I'm > >> adding a 7th. > > Hmm, yes, in a way you're right. > > > >> It has been a module-ish description right from the very outset. I > >> don't think it is fair to describe this as an abuse at all. > >> > >> Is this going to satisfy the outstanding concerns? > > Yes. And thank you for bearing with me. > > No problem. I'm glad that we've come to an agreement. > > Ross? > Yes, I think that is fine with the additional description clarifying it. With that, Reviewed-by: Ross Lagerwall > > > > > Jan > > > >> diff --git a/xen/include/xen/virtual_region.h > >> b/xen/include/xen/virtual_region.h > >> index d05362071135..9d150beb8a87 100644 > >> --- a/xen/include/xen/virtual_region.h > >> +++ b/xen/include/xen/virtual_region.h > >> @@ -9,6 +9,12 @@ > >> #include > >> #include > >> > >> +/* > >> + * Despite it's name, this is module(ish) description. > >> + * > >> + * There's one region for .text/etc, one region for .init during boot= only, > >> + * and one region per livepatch. > >> + */ > >> struct virtual_region > >> { > >> struct list_head list; > >> > >> ~Andrew > From xen-devel-bounces@lists.xenproject.org Thu Mar 07 13:05:06 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 13:05:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689893.1075343 (Exim 4.92) (envelope-from ) id 1riDQo-0007PM-IA; Thu, 07 Mar 2024 13:05:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689893.1075343; Thu, 07 Mar 2024 13:05:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riDQo-0007PF-FO; Thu, 07 Mar 2024 13:05:06 +0000 Received: by outflank-mailman (input) for mailman id 689893; Thu, 07 Mar 2024 13:05:06 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riDQo-0007P5-2a for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 13:05:06 +0000 Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [2607:f8b0:4864:20::102f]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 50653376-dc83-11ee-afda-a90da7624cb6; Thu, 07 Mar 2024 14:05:05 +0100 (CET) Received: by mail-pj1-x102f.google.com with SMTP id 98e67ed59e1d1-29954bb87b4so531153a91.2 for ; Thu, 07 Mar 2024 05:05:05 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 50653376-dc83-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709816704; x=1710421504; darn=lists.xenproject.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=nKZLMsjd9ZD8pZaVWQUzyI6GfpWKpoCwubMVbR7UGEc=; b=atnyoh9Kq7z93zPR+j+tD5aZ7DMvhOM1yOICun/IgCwUeGwmMtlsKDL92yCiQFYLif 9papoDT6PsJf+45/T3ZhUQabZ7SkjonOn7sZvvdxOuhVYovJGmQXZnattd+c/ocd4LUH eEW2Ys8sHrpTbVka5ZhG3grcPOONhlY9C6L3o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709816704; x=1710421504; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=nKZLMsjd9ZD8pZaVWQUzyI6GfpWKpoCwubMVbR7UGEc=; b=PnTbbjZr9Wi/LxzjoIgs/jEgz6y/PhribY+x2H3u7VsHvpFc8+hE8EeINBJzrsfGec ytj75Uu08QLpCifUkP7T6HBLRvoU6qYpJA7Mgm+yiVlZU2YMLE1CdKKqBD8u4uZm0MB+ Cnc+deXPOgXmHVHRWlj/dHXIT23NzEQ3zdy4xeMjL5HdH5gUX+BANn4njUfU4RwNIjuR s6U24uHIvByQypwiKgoETYqtQfTIV1XS2cOSL7adheZ9K8BbffEmPX9a4jW6PhRJHPVX fbgLAVqdV040kckx/cjzgai9vaEpfoRxvb5VW9GDQcMKMrkmEKnMlYyeOuwmNgNBxfvY 84jg== X-Gm-Message-State: AOJu0Yx+9+ObJm52tzA57b4DtswQCge8zTeQy3qf6BCC3X9x1vA04X3o 4db6+/PFeHxy6NnEVGi7Ml9nTRvUO9/B11J87TlEHvhDw5+dwliKAYm/xRhqBV1e+muqKIOrNuq QXaWWDcy+KtlQDh/xO0Nd9a3VddoKG14SVM0K X-Google-Smtp-Source: AGHT+IE2JQC9swy4Mus2gtg9CMQOzTVy2xa5rsIEBl7jWj+n1lfyqNLmstntW3wrKHi5W/nw2q8q/NHaaPmda1iyQYw= X-Received: by 2002:a17:90a:4296:b0:299:5b95:cd7d with SMTP id p22-20020a17090a429600b002995b95cd7dmr13373916pjg.45.1709816703656; Thu, 07 Mar 2024 05:05:03 -0800 (PST) MIME-Version: 1.0 References: <20240305121121.3527944-1-andrew.cooper3@citrix.com> <20240305121121.3527944-4-andrew.cooper3@citrix.com> In-Reply-To: From: Ross Lagerwall Date: Thu, 7 Mar 2024 13:04:51 +0000 Message-ID: Subject: Re: [PATCH 3/3] x86/livepatch: Relax permissions on rodata too To: Andrew Cooper Cc: Xen-devel , Konrad Rzeszutek Wilk , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Mar 5, 2024 at 1:02=E2=80=AFPM Andrew Cooper wrote: > > On 05/03/2024 12:11 pm, Andrew Cooper wrote: > > diff --git a/xen/common/virtual_region.c b/xen/common/virtual_region.c > > index d2efe9e11492..f45812483b8e 100644 > > --- a/xen/common/virtual_region.c > > +++ b/xen/common/virtual_region.c > > @@ -91,9 +91,15 @@ void relax_virtual_region_perms(void) > > > > rcu_read_lock(&rcu_virtual_region_lock); > > list_for_each_entry_rcu( region, &virtual_region_list, list ) > > + { > > modify_xen_mappings_lite((unsigned long)region->text_start, > > PAGE_ALIGN((unsigned long)region->tex= t_end), > > PAGE_HYPERVISOR_RWX); > > + if ( region->rodata_start ) > > + modify_xen_mappings_lite((unsigned long)region->rodata_sta= rt, > > + ROUNDUP((unsigned long)region->ro= data_end, PAGE_SIZE), > > I missed the final refresh to turn this to PAGE_ALIGN(). Fixed locally. In that case, Reviewed-by: Ross Lagerwall From xen-devel-bounces@lists.xenproject.org Thu Mar 07 13:05:50 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 13:05:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689895.1075353 (Exim 4.92) (envelope-from ) id 1riDRV-0007yg-QP; Thu, 07 Mar 2024 13:05:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689895.1075353; Thu, 07 Mar 2024 13:05:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riDRV-0007yZ-Nk; Thu, 07 Mar 2024 13:05:49 +0000 Received: by outflank-mailman (input) for mailman id 689895; Thu, 07 Mar 2024 13:05:48 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riDRU-0007yR-Qr for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 13:05:48 +0000 Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [2607:f8b0:4864:20::1036]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 6961b2ee-dc83-11ee-a1ee-f123f15fe8a2; Thu, 07 Mar 2024 14:05:47 +0100 (CET) Received: by mail-pj1-x1036.google.com with SMTP id 98e67ed59e1d1-29b1ee96191so516093a91.0 for ; Thu, 07 Mar 2024 05:05:47 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6961b2ee-dc83-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709816745; x=1710421545; darn=lists.xenproject.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Aq/IIui6NlkqqF0mR0ekTDaM6i7W+Eg6RvK6usUzWAU=; b=GkCRQ/4D5uUcTy1dgayk5BGoMzSYQVC7qlP3tJETlsjxNEaUVaGLsuNMn9uzz2vhey 2Ult6dV7RbgjaRKhau/47ZMa3aqJsIw0xj8SwrzVSwJeAfwQCkf9A/yUOTIJhD+yPBbT On0l0b0kprWUxvuFFao7nKww5856/jWBeswTo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709816745; x=1710421545; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Aq/IIui6NlkqqF0mR0ekTDaM6i7W+Eg6RvK6usUzWAU=; b=jJuH42XDMiKkYMcWvzdzUzOBnfzpGPUwxxRm+BORpUp7rzzWQnD119rZsQ589CCD5s busqcTDSIyYlUNahBY0wB7kNKu/O2qc/pHosetKhln89MtIiUhjjroq2itr+OhRkw4W9 M2OYtnEI2I1qcq4htbLjMTP5Z2+4Lox9GxeA7aJA6frf/zXHNT4sK8WeeByXb8UOEz21 LkmhjSm/Ox8im5LkGNVT90AQ2AOc3muJEri6zj+AJ04p/yHCBm5Xba7Fqp2Di7Tccr6l 6Y+N2fPUxvD5dhBIIfUDeYdDIFBXo3opSNR9qDq84qjALAlshPyrH9ylPdlNVPNo5A4J ZasQ== X-Gm-Message-State: AOJu0Yzx8k/qeTKBu9XlaFv/WdGvITUcXD8wfWfudLZ0ohBMBc9hCkUK WDT2JP4EvCBSJnO0OFo/HBmF5ZJPf6NFxweEg6fDIWNDzhgrAQF3euoJz9yet3BjhC+FzI0cZaO XcAjeiz19ozjZ3fTJHeNcZRRsvHscZC3vRglO X-Google-Smtp-Source: AGHT+IGLnn8RptkZu7AsublN8Z7lLDx3eCuLlisgUyfG8yEoUZycegMaLslD/OU1ezh3IuZB8v9zAqO5Wx+XCsj2xSs= X-Received: by 2002:a17:90a:a516:b0:299:2927:4d2c with SMTP id a22-20020a17090aa51600b0029929274d2cmr15142043pjq.48.1709816745501; Thu, 07 Mar 2024 05:05:45 -0800 (PST) MIME-Version: 1.0 References: <20240305121121.3527944-1-andrew.cooper3@citrix.com> <20240305121121.3527944-2-andrew.cooper3@citrix.com> In-Reply-To: <20240305121121.3527944-2-andrew.cooper3@citrix.com> From: Ross Lagerwall Date: Thu, 7 Mar 2024 13:05:33 +0000 Message-ID: Subject: Re: [PATCH 1/3] xen/virtual-region: Rename start/end fields To: Andrew Cooper Cc: Xen-devel , Konrad Rzeszutek Wilk , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Mar 5, 2024 at 12:11=E2=80=AFPM Andrew Cooper wrote: > > ... to text_{start,end}. We're about to introduce another start/end pair= . > > As minor cleanup, replace ROUNDUP(x, PAGE_SIZE) with the more consice > PAGE_ALIGN() ahead of duplicating the example. > > No functional change. > > Signed-off-by: Andrew Cooper Reviewed-by: Ross Lagerwall From xen-devel-bounces@lists.xenproject.org Thu Mar 07 13:10:54 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 13:10:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689900.1075362 (Exim 4.92) (envelope-from ) id 1riDWN-0001te-B7; Thu, 07 Mar 2024 13:10:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689900.1075362; Thu, 07 Mar 2024 13:10:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riDWN-0001tX-80; Thu, 07 Mar 2024 13:10:51 +0000 Received: by outflank-mailman (input) for mailman id 689900; Thu, 07 Mar 2024 13:10:50 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riDWM-0001tR-CX for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 13:10:50 +0000 Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [2a00:1450:4864:20::62c]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 1e19aa65-dc84-11ee-afda-a90da7624cb6; Thu, 07 Mar 2024 14:10:49 +0100 (CET) Received: by mail-ej1-x62c.google.com with SMTP id a640c23a62f3a-a36126ee41eso123767166b.2 for ; Thu, 07 Mar 2024 05:10:49 -0800 (PST) Received: from [10.80.67.149] (default-46-102-197-194.interdsl.co.uk. [46.102.197.194]) by smtp.gmail.com with ESMTPSA id v23-20020a1709067d9700b00a42ee62b634sm8152780ejo.106.2024.03.07.05.10.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Mar 2024 05:10:47 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1e19aa65-dc84-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709817049; x=1710421849; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=hV2WSuyRyPExQa5jSD0DJFpKRZ2Eyk1E/Pq71hg1bnY=; b=ii43PKbsNdapdCQ9YiwjFyDMr0LfJXJty+87jaQMcJ/HGlspgs3fLi4oEas9JJQXOq +Wn8iPwv20w8lFZc//y7qe+dHz0HTboa9zgEXToXbWlu/04cS6ZQcAjy9Vns06ne7s2m 88HXnS5ZM3Id0yxXf8C7QhRDYBT4wbEEHaG3Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709817049; x=1710421849; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=hV2WSuyRyPExQa5jSD0DJFpKRZ2Eyk1E/Pq71hg1bnY=; b=pFcHQG/WIcP2SGkzfRaHJ8c7Esm4hnkjcHxmFIlabuDSogfIBF0UhhhutEvhmtVrNG DqkVBZVXyI/udQBXi5DjV8t34MZ+ilb4whV5zBY9tnWqIwUlnHJDao3Hwn+ddj0NQdB6 fALbCDWbb5e3qVHuXPTyJCyzNAQN8XCa9RJUCkGxI3HIi66MUcQk6GBXvD7iJ+YvnQkf 5QY2bv6nFh/SUz1OBMDG9Nd51CG587g79BLVynveYXA36RliILw6lI+7vb32+AK0rFmU jIBqHQUP5rGNkBP6cuu2Ns1Wpme3bhAXQsWXN6FSM861h14LCGhtPuMILuXWx0A4rWzM Mgbw== X-Forwarded-Encrypted: i=1; AJvYcCW6IP9QoJwLpkujsEN1Q06QY2KfVHPVSg+KxjldHRtZpNaB2c9mRvsJ4zcSUUhleeurTzRu0qv3oM6zAuy0MDWzqhIFmqVpbv7eq2oIlnc= X-Gm-Message-State: AOJu0YzW+GWzglmlF/smyI5yEVwuovXLtdjTUjYaQz1vesY4jbBMNSFt XnnV7iPMNgR4Sfkstr/C12rFAOmY28ddH6gr70khNVyrVN08Y6VDkCYGYkn3Nh0= X-Google-Smtp-Source: AGHT+IHsFum3LG/SeJ+0EH5uRR3Lyh5qL68a9iEEzpTMISAdaLjdAgu1pdaHioFvANp+i+lJzW6HCA== X-Received: by 2002:a17:906:3c17:b0:a43:86f3:b00d with SMTP id h23-20020a1709063c1700b00a4386f3b00dmr12789782ejg.0.1709817048934; Thu, 07 Mar 2024 05:10:48 -0800 (PST) Message-ID: Date: Thu, 7 Mar 2024 13:10:46 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/3] xen/virtual-region: Include rodata pointers Content-Language: en-GB To: Ross Lagerwall Cc: Jan Beulich , Konrad Rzeszutek Wilk , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20240305121121.3527944-1-andrew.cooper3@citrix.com> <20240305121121.3527944-3-andrew.cooper3@citrix.com> <87b82706-f538-4807-abaf-1e59cebd286b@suse.com> <82126c3a-0cde-452f-86aa-2571482f42aa@citrix.com> <76ce9dcf-8cac-44b3-9550-f516024bad6e@suse.com> <9e827057-9306-4a2a-8816-410661bf8892@citrix.com> <818ac202-5473-4638-b140-45272b1041ed@suse.com> From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 07/03/2024 1:03 pm, Ross Lagerwall wrote: > On Thu, Mar 7, 2024 at 12:16 PM Andrew Cooper wrote: >> On 07/03/2024 11:58 am, Jan Beulich wrote: >>> On 07.03.2024 12:31, Andrew Cooper wrote: >>>> The thing called virtual_region already describes 6 ranges, and I'm >>>> adding a 7th. >>> Hmm, yes, in a way you're right. >>> >>>> It has been a module-ish description right from the very outset. I >>>> don't think it is fair to describe this as an abuse at all. >>>> >>>> Is this going to satisfy the outstanding concerns? >>> Yes. And thank you for bearing with me. >> No problem. I'm glad that we've come to an agreement. >> >> Ross? >> > Yes, I think that is fine with the additional description clarifying it. > > With that, > > Reviewed-by: Ross Lagerwall Thanks. It occurs to me that this comment is best in patch 1, which is the patch that removes the final trace of this looking like a single thing. ~Andrew From xen-devel-bounces@lists.xenproject.org Thu Mar 07 13:24:47 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 13:24:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689909.1075373 (Exim 4.92) (envelope-from ) id 1riDjl-0006aY-Ip; Thu, 07 Mar 2024 13:24:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689909.1075373; Thu, 07 Mar 2024 13:24:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riDjl-0006aR-FQ; Thu, 07 Mar 2024 13:24:41 +0000 Received: by outflank-mailman (input) for mailman id 689909; Thu, 07 Mar 2024 13:24:40 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riDjk-0006aL-91 for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 13:24:40 +0000 Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [2a00:1450:4864:20::234]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 0c921d39-dc86-11ee-afda-a90da7624cb6; Thu, 07 Mar 2024 14:24:39 +0100 (CET) Received: by mail-lj1-x234.google.com with SMTP id 38308e7fff4ca-2d28051376eso12498341fa.0 for ; Thu, 07 Mar 2024 05:24:39 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id y6-20020a056402358600b005645961ad39sm7947077edc.47.2024.03.07.05.24.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Mar 2024 05:24:38 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 0c921d39-dc86-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709817878; x=1710422678; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=enFu7DIqss8P1zQJNCZ0yqSNnMex2W4vkY8dXDd8McQ=; b=RCLgShVGWC+UzNtRrgFQ2ZHerwfGLQ9H9042mKulXt9daAykBPRbgQIAy6NA+Ilt8p 7Z4mvNRet6ayWp/ZB3on1itGIy3sNePyrwdKT1XoNwT/0ypYmda53IK/JMvpg1t1wiV+ 7q1si75zvBlComMV+PgkNEZaWwth0IkVVo9lj7OijdiG6xDl3+bksM9ePu1AS3sk5/5Z f4ZtacMMWnjBA1AHSClk588pOIzMaUQM6j6iPcvWCIljxyR2rvMBpPLJtTEe2xSLyUMV XqtoyI01UuqdVPLRtaYSG/VJOi67jCAVJgEigBgCn5eudRTRtlaJyJ4nJqTlxi7kqeOf nNMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709817878; x=1710422678; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=enFu7DIqss8P1zQJNCZ0yqSNnMex2W4vkY8dXDd8McQ=; b=RDApmRaKIj75PwTxixlJ9dE4Yhe+iJLegHi3pH5o87X6GF+O1ZHEeiQRazfExaJk9U eg2+5I4+OYK+U9XuiMhPhphiDqWzs5J5DjvegbTPCcxDMtW5X/iIeC0g0IMF0f4w+Jqy wDPNQhOax/3Gy6HM5bTltmUHOLZfkpq3d4qm1Th1gje5gnhdsQ0kq/uGVCDcln0wJb3r ic4WIctyzl0K6HPIiFEXjO/YD0Q7zQNpVSdjCh5mXzCLnE5NuBzXwWknzALj7OqhEZXn PSsZ7Rq+8P5bZ4xqXhk02Pn4oVXtysH4sznxwwRyHBpzEFMGWVbKHmV/mt91OcRRhZDI I6qA== X-Forwarded-Encrypted: i=1; AJvYcCXufP74WVF4DrwmDIdZ6Y5pYZJpAHQqUK9li9aHOs+TLI7n0DY2PxJ83FF4niMh8p+0SJtvHq2petulTv0kpTiYrkvkCfpaeqCDx7rSTQ8= X-Gm-Message-State: AOJu0YyriTCobQ3f/NNPZj+VR1uS4IC8AvkbUj6QQY1vOwIzwlOvKI9b rjUVKcFBnWhncTDtWz8iOW+AvYo1ThFK3KnLa81oRIeQieIKGMnIHK64EzvTIw== X-Google-Smtp-Source: AGHT+IGhWfMvNwIpz3mwR9dY8f2oBNG/WCaTnCX5r1o1egGqC4ZUJNkPcrMpGh19IBEoDKmuP6Ns6A== X-Received: by 2002:a2e:a7c5:0:b0:2d4:874:24df with SMTP id x5-20020a2ea7c5000000b002d4087424dfmr1499833ljp.49.1709817878493; Thu, 07 Mar 2024 05:24:38 -0800 (PST) Message-ID: Date: Thu, 7 Mar 2024 14:24:37 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 12/23] xen/riscv: introduce io.h Content-Language: en-US To: Oleksii Cc: Alistair Francis , Bob Eshleman , Connor Davis , Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu , xen-devel@lists.xenproject.org References: <807c31d5-0c5a-4646-ba90-2f284289069f@suse.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 07.03.2024 14:01, Oleksii wrote: > On Wed, 2024-03-06 at 15:13 +0100, Jan Beulich wrote: >>> +/* Generic IO read/write.  These perform native-endian accesses. >>> */ >>> +static inline void __raw_writeb(uint8_t val, volatile void __iomem >>> *addr) >>> +{ >>> +    asm volatile ( "sb %0, 0(%1)" : : "r" (val), "r" (addr) ); >>> +} >> >> I realize this is like Linux has it, but how is the compiler to know >> that >> *addr is being access here?  > Assembler syntax told compiler that. 0(%1) - means that the memory > location pointed to by the address in register %1. No, the compiler doesn't decompose the string to figure how operands are used. That's what the constraints are for. The only two things the compiler does with the string is replace % operators and count line separators. >> If the omission of respective constraints here >> and below is intentional, I think a comment (covering all instances) >> is >> needed. Note that while supposedly cloned from Arm code, Arm variants >> do >> have such constraints in Linux. >> > It uses this constains only in arm32: > #define __raw_writeb __raw_writeb > static inline void __raw_writeb(u8 val, volatile void __iomem *addr) > { > asm volatile("strb %1, %0" > : : "Qo" (*(volatile u8 __force *)addr), "r" > (val)); > } > > But in case of arm64: > > #define __raw_writeb __raw_writeb > static __always_inline void __raw_writeb(u8 val, volatile void __iomem > *addr) > { > asm volatile("strb %w0, [%1]" : : "rZ" (val), "r" (addr)); > } > > And again looking at the defintion they use different option of strb > instruction, and in case of strb they use [%1] which tells compiler > that %1 is addressed which should be dereferenced. Same bug here then; I happened to look at Arm32 only. As mentioned in the other patch using what's provided here, the problem becomes more than latent only there. And I can't spot such use in Arm64 code, so it is likely only a latent bug there. Jan From xen-devel-bounces@lists.xenproject.org Thu Mar 07 13:30:13 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 13:30:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689913.1075382 (Exim 4.92) (envelope-from ) id 1riDp4-0000L0-4Z; Thu, 07 Mar 2024 13:30:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689913.1075382; Thu, 07 Mar 2024 13:30:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riDp4-0000Ks-1m; Thu, 07 Mar 2024 13:30:10 +0000 Received: by outflank-mailman (input) for mailman id 689913; Thu, 07 Mar 2024 13:30:09 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riDp3-0000Km-5t for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 13:30:09 +0000 Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [2a00:1450:4864:20::135]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id d0a9dd77-dc86-11ee-afda-a90da7624cb6; Thu, 07 Mar 2024 14:30:08 +0100 (CET) Received: by mail-lf1-x135.google.com with SMTP id 2adb3069b0e04-51325c38d10so1918749e87.1 for ; Thu, 07 Mar 2024 05:30:08 -0800 (PST) Received: from [192.168.206.239] ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id 25-20020ac24859000000b005134b2b45easm1555473lfy.232.2024.03.07.05.30.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Mar 2024 05:30:06 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d0a9dd77-dc86-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709818207; x=1710423007; darn=lists.xenproject.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=jxQW79O+/oYAtOwX+pJYmMMRf1q+vtbVl8k9fmKfxYs=; b=dx2hkXMOAoTQSvDTZthLq+TG+34yCVHl/GmA+dAGDmW0iI5dzZ+YT9gcF2gKPyYsQY epsEnf6VQs/yhVdQ0SfZPBa1trFzAmMr9FzALrDo71JBp72cj9155roSdfdZpH6POv4/ w5OwQdH0rTYxSO/LTzjrt8af4SWSegr55jvAYXqvm+ZqZo+46ZFwGw73/eQzntK6ehXI gcsDwAw/+3qC6ZRsooAf2jAKGewbvxFHKnEO5e8KcXdaDWGB8zJrfScq1rsshDyEt/GM Nl5AI8B69uWYBeRlYRoQcPKXTajxDHAV/Rqvk26Z2Y9HZcU0IcsuRFuMdTZ70fLm/MSz YOdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709818207; x=1710423007; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=jxQW79O+/oYAtOwX+pJYmMMRf1q+vtbVl8k9fmKfxYs=; b=RMYQYEBBkckNaQ+1PyZLwEszu0PUtar1A8Bb42qL3mGCoIENcb6jMmJeeYEnTpjpXm OLofkItv7oYYscf7ldzDPsKfdcJDV6xcKKXpY8U5l0EDwTfQ9Ba3kKEXXIUkgTfokSZy mPakXSZ32E/AGTaWOATXaEblheDop3pqxy6XW7wtG0qcoVs6GxsvLJ8kBhSYjnBdu6k+ 2JDQg5LMoJIWuPHlQkQ+PnQXE4zvj6JnZO/T+8MZQnHyONyNA2SAVBw5m89cJ09exZnQ d4PQEt4H5Fov2paxD+Gdx0HbDHgTtIFvWrAH44htifMifqWJRNGI97vKpyzL6KB1eb0B kCQQ== X-Forwarded-Encrypted: i=1; AJvYcCV3lVaT6EXZgVpuIgOrJermd5wrVY/v0j3A752fjq3cyo0s7fCS6PepyXiBG2p2p7Au85c2qvqyVCEsg8zLe8hdPmYFR7E6eejX08SnpE0= X-Gm-Message-State: AOJu0Yyr2Ef1sDyTwDMkd6QfAwrUePor5dhIeJKDKxI1aDbQeT/5aOBC gbHcqgi7cuzFrknzN3owvr5Oevz4Xn3TgLyMQcIhDphpa/7Qcsc0 X-Google-Smtp-Source: AGHT+IEI6ZPfI3NLl36MvLuh2gq1lSXnT0ai635sd9XKWejCmnIXtl9jfzm+F2X07MPwr391RFeHww== X-Received: by 2002:ac2:489c:0:b0:513:2c5f:1078 with SMTP id x28-20020ac2489c000000b005132c5f1078mr92555lfc.8.1709818207088; Thu, 07 Mar 2024 05:30:07 -0800 (PST) Message-ID: <7ae660e5da986503a1353f07ecf298bd9814afe1.camel@gmail.com> Subject: Re: [PATCH v5 13/23] xen/riscv: introduce atomic.h From: Oleksii To: Jan Beulich Cc: Alistair Francis , Bob Eshleman , Connor Davis , Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu , xen-devel@lists.xenproject.org Date: Thu, 07 Mar 2024 14:30:06 +0100 In-Reply-To: <3d9b0fa3-d100-4e73-b5d5-782ef58e331a@suse.com> References: <85ad8c86901d045beed228947d4c3faf277af3ca.1708962629.git.oleksii.kurochko@gmail.com> <3d9b0fa3-d100-4e73-b5d5-782ef58e331a@suse.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 User-Agent: Evolution 3.50.2 (3.50.2-1.fc39) MIME-Version: 1.0 T24gV2VkLCAyMDI0LTAzLTA2IGF0IDE2OjMxICswMTAwLCBKYW4gQmV1bGljaCB3cm90ZToKPiBP biAyNi4wMi4yMDI0IDE4OjM4LCBPbGVrc2lpIEt1cm9jaGtvIHdyb3RlOgo+ID4gLS0tIC9kZXYv bnVsbAo+ID4gKysrIGIveGVuL2FyY2gvcmlzY3YvaW5jbHVkZS9hc20vYXRvbWljLmgKPiA+IEBA IC0wLDAgKzEsMjk2IEBACj4gPiArLyogU1BEWC1MaWNlbnNlLUlkZW50aWZpZXI6IEdQTC0yLjAt b25seSAqLwo+ID4gKy8qCj4gPiArICogVGFrZW4gYW5kIG1vZGlmaWVkIGZyb20gTGludXguCj4g PiArICoKPiA+ICsgKiBUaGUgZm9sbG93aW5nIGNoYW5nZXMgd2VyZSBkb25lOgo+ID4gKyAqIC0g KiBhdG9taWMjI3ByZWZpeCMjXyp4Y2hnXyooYXRvbWljIyNwcmVmaXgjI190ICp2LCBjX3Qgbikg d2VyZQo+ID4gdXBkYXRlZAo+ID4gKyAqwqDCoMKgwqAgdG8gdXNlX18qeGNoZ19nZW5lcmljKCkK PiA+ICsgKiAtIGRyb3AgY2FzdHMgaW4gd3JpdGVfYXRvbWljKCkgYXMgdGhleSBhcmUgdW5uZWNl c3NhcnkKPiA+ICsgKiAtIGRyb3AgaW50cm9kdWN0aW9uIG9mIFdSSVRFX09OQ0UoKSBhbmQgUkVB RF9PTkNFKCkuCj4gPiArICrCoMKgIFhlbiBwcm92aWRlcyBBQ0NFU1NfT05DRSgpCj4gPiArICog LSByZW1vdmUgemVyby1sZW5ndGggYXJyYXkgYWNjZXNzIGluIHJlYWRfYXRvbWljKCkKPiA+ICsg KiAtIGRyb3AgZGVmaW5lcyBzaW1pbGFyIHRvIHBhdHRlcm4KPiA+ICsgKsKgwqAgI2RlZmluZSBh dG9taWNfYWRkX3JldHVybl9yZWxheGVkwqDCoCBhdG9taWNfYWRkX3JldHVybl9yZWxheGVkCj4g PiArICogLSBtb3ZlIG5vdCBSSVNDLVYgc3BlY2lmaWMgZnVuY3Rpb25zIHRvIGFzbS1nZW5lcmlj L2F0b21pY3MtCj4gPiBvcHMuaAo+ID4gKyAqIAo+ID4gKyAqIENvcHlyaWdodCAoQykgMjAwNyBS ZWQgSGF0LCBJbmMuIEFsbCBSaWdodHMgUmVzZXJ2ZWQuCj4gPiArICogQ29weXJpZ2h0IChDKSAy MDEyIFJlZ2VudHMgb2YgdGhlIFVuaXZlcnNpdHkgb2YgQ2FsaWZvcm5pYQo+ID4gKyAqIENvcHly aWdodCAoQykgMjAxNyBTaUZpdmUKPiA+ICsgKiBDb3B5cmlnaHQgKEMpIDIwMjQgVmF0ZXMgU0FT Cj4gPiArICovCj4gPiArCj4gPiArI2lmbmRlZiBfQVNNX1JJU0NWX0FUT01JQ19ICj4gPiArI2Rl ZmluZSBfQVNNX1JJU0NWX0FUT01JQ19ICj4gPiArCj4gPiArI2luY2x1ZGUgPHhlbi9hdG9taWMu aD4KPiA+ICsKPiA+ICsjaW5jbHVkZSA8YXNtL2NtcHhjaGcuaD4KPiA+ICsjaW5jbHVkZSA8YXNt L2ZlbmNlLmg+Cj4gPiArI2luY2x1ZGUgPGFzbS9pby5oPgo+ID4gKyNpbmNsdWRlIDxhc20vc3lz dGVtLmg+Cj4gPiArCj4gPiArI2luY2x1ZGUgPGFzbS1nZW5lcmljL2F0b21pYy1vcHMuaD4KPiAK PiBXaGlsZSwgYmVjYXVzZSBvZiB0aGUgZm9yd2FyZCBkZWNscyBpbiB4ZW4vYXRvbWljLmgsIGhh dmluZyB0aGlzCj4gI2luY2x1ZGUKPiB3b3JrcywgSSB3b25kZXIgaWYgaXQgd291bGRuJ3QgYmV0 dGVyIGJlIHBsYWNlZCBmdXJ0aGVyIGRvd24uIFRoZQo+IGNvbXBpbGVyCj4gd2lsbCBsaWtlbHkg aGF2ZSBhbiBlYXNpZXIgdGltZSB3aGVuIGl0IHNlZXMgdGhlIGlubGluZSBkZWZpbml0aW9ucwo+ IGFoZWFkCj4gb2YgYW55IHVzZXMuCkRvIHlvdSBtZWFuIHRvIG1vdmUgaXQgYWZ0ZXIgI2RlZmlu ZSBfX2F0b21pY19yZWxlYXNlX2ZlbmNlKCkgPwoKPiAKPiA+ICt2b2lkIF9fYmFkX2F0b21pY19z aXplKHZvaWQpOwo+ID4gKwo+ID4gKy8qCj4gPiArICogTGVnYWN5IGZyb20gTGludXgga2VybmVs LiBGb3Igc29tZSByZWFzb24gdGhleSB3YW50ZWQgdG8gaGF2ZQo+ID4gb3JkZXJlZAo+ID4gKyAq IHJlYWQvd3JpdGUgYWNjZXNzLiBUaGVyZWJ5IHJlYWQqIGlzIHVzZWQgaW5zdGVhZCBvZgo+ID4g cmVhZDxYPl9jcHUoKQo+ID4gKyAqLwo+ID4gK3N0YXRpYyBhbHdheXNfaW5saW5lIHZvaWQgcmVh ZF9hdG9taWNfc2l6ZShjb25zdCB2b2xhdGlsZSB2b2lkICpwLAo+ID4gK8KgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoCB2b2lkICpyZXMsCj4gPiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg IHVuc2lnbmVkIGludCBzaXplKQo+ID4gK3sKPiA+ICvCoMKgwqAgc3dpdGNoICggc2l6ZSApCj4g PiArwqDCoMKgIHsKPiA+ICvCoMKgwqAgY2FzZSAxOiAqKHVpbnQ4X3QgKilyZXMgPSByZWFkYihw KTsgYnJlYWs7Cj4gPiArwqDCoMKgIGNhc2UgMjogKih1aW50MTZfdCAqKXJlcyA9IHJlYWR3KHAp OyBicmVhazsKPiA+ICvCoMKgwqAgY2FzZSA0OiAqKHVpbnQzMl90ICopcmVzID0gcmVhZGwocCk7 IGJyZWFrOwo+ID4gK8KgwqDCoCBjYXNlIDg6ICoodWludDMyX3QgKilyZXPCoCA9IHJlYWRxKHAp OyBicmVhazsKPiAKPiBUaGlzIGlzIHRoZSBwb2ludCB3aGVyZSB0aGUgbGFjayBvZiBjb25zdHJh aW50cyBpbiBpby5oIChzZWUgbXkKPiByZXNwZWN0aXZlCj4gY29tbWVudCkgYmVjb21lcyBhY3R1 YWxseSBoYXJtZnVsOiBZb3UncmUgYWNjZXNzaW5nIG5vdCBNTUlPLCBidXQKPiBjb21waWxlci0K PiB2aXNpYmxlIHZhcmlhYmxlcyBoZXJlLiBJdCBuZWVkcyB0byBrbm93IHdoaWNoIG9uZXMgYXJl IHJlYWQgLi4uCj4gCj4gPiArwqDCoMKgIGRlZmF1bHQ6IF9fYmFkX2F0b21pY19zaXplKCk7IGJy ZWFrOwo+ID4gK8KgwqDCoCB9Cj4gPiArfQo+ID4gKwo+ID4gKyNkZWZpbmUgcmVhZF9hdG9taWMo cCkgKHvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqAgXAo+ID4gK8KgwqDCoCB1bmlvbiB7IHR5cGVvZigqcCkgdmFsOyBjaGFyIGNbc2l6 ZW9mKCpwKV07IH0geF87wqDCoCBcCj4gPiArwqDCoMKgIHJlYWRfYXRvbWljX3NpemUocCwgeF8u Yywgc2l6ZW9mKCpwKSk7wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgXAo+ID4gK8KgwqDCoCB4 Xy52YWw7wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBcCj4gPiArfSkKPiA+ICsKPiA+ ICsjZGVmaW5lIHdyaXRlX2F0b21pYyhwLCB4KcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgXAo+ID4gKyh7wqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBcCj4gPiArwqDCoMKgIHR5cGVvZigqcCkg eF9fID0gKHgpO8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoCBcCj4gPiArwqDCoMKgIHN3aXRjaCAoIHNpemVvZigqcCkgKcKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBcCj4g PiArwqDCoMKgIHvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFwK PiA+ICvCoMKgwqAgY2FzZSAxOiB3cml0ZWIoeF9fLMKgIHApOyBicmVhazvCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFwKPiA+ICvCoMKgwqAgY2FzZSAyOiB3cml0ZXco eF9fLCBwKTsgYnJlYWs7wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg IFwKPiA+ICvCoMKgwqAgY2FzZSA0OiB3cml0ZWwoeF9fLCBwKTsgYnJlYWs7wqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFwKPiA+ICvCoMKgwqAgY2FzZSA4OiB3cml0 ZXEoeF9fLCBwKTsgYnJlYWs7wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgIFwKPiAKPiAuLi4gb3Igd3JpdHRlbi4KPiAKPiBOaXQ6IFRoZXJlJ3MgYSBzdHJheSBibGFu ayBpbiB0aGUgd3JpdGViKCkgaW52b2NhdGlvbi4KPiAKPiA+ICvCoMKgwqAgZGVmYXVsdDogX19i YWRfYXRvbWljX3NpemUoKTsgYnJlYWs7wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFwK PiA+ICvCoMKgwqAgfcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAg XAo+ID4gK8KgwqDCoCB4X187wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBc Cj4gPiArfSkKPiA+ICsKPiA+ICsjZGVmaW5lIGFkZF9zaXplZChwLCB4KcKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgXAo+ID4g Kyh7wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBcCj4g PiArwqDCoMKgIHR5cGVvZigqKHApKSB4X18gPSAoeCk7wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgXAo+ID4gK8KgwqDCoCBzd2l0Y2ggKCBz aXplb2YoKihwKSkgKcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgIFwKPiAKPiBMaWtlIHlvdSBoYXZlIGl0IGhlcmUsIHtyZWFkLHdyaXRlfV9h dG9taWMoKSBhbHNvIG5lZWQgcCBwcm9wZXJseQo+IHBhcmVudGhlc2l6ZWQuIFRoZXJlIGxvb2sg dG8gYmUgbW9yZSBwYXJlbnRoZXNpemF0aW9uIGlzc3VlcyBmdXJ0aGVyCj4gZG93bi4KPiAKPiA+ ICvCoMKgwqAge8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgXAo+ ID4gK8KgwqDCoCBjYXNlIDE6IHdyaXRlYihyZWFkX2F0b21pYyhwKSArIHhfXywgcCk7IGJyZWFr O8KgwqDCoMKgIFwKPiA+ICvCoMKgwqAgY2FzZSAyOiB3cml0ZXcocmVhZF9hdG9taWMocCkgKyB4 X18sIHApOyBicmVhazvCoMKgwqDCoCBcCj4gPiArwqDCoMKgIGNhc2UgNDogd3JpdGVsKHJlYWRf YXRvbWljKHApICsgeF9fLCBwKTsgYnJlYWs7wqDCoMKgwqAgXAo+ID4gK8KgwqDCoCBkZWZhdWx0 OiBfX2JhZF9hdG9taWNfc2l6ZSgpOyBicmVhazvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqAgXAo+ID4gK8KgwqDCoCB9wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoCBcCj4gPiArfSkKPiAKPiBBbnkgcmVhc29uIHRoaXMgZG9lc24ndCBoYXZlIGFuIDgtYnl0 ZSBjYXNlPyB4ODYnZXMgYXQgbGVhc3QgaGFzIG9uZS4KSnVzdCBtaXNzZWQgdG8gYWRkIGFuZCBu byBjb21waWxlciBlcnJvciBJIGhhZCwgYnV0IEknbGwgYWRkZWQgY2FzZSA4LgoKPiAKPiA+ICsj ZGVmaW5lIF9fYXRvbWljX2FjcXVpcmVfZmVuY2UoKSBcCj4gPiArwqDCoMKgIF9fYXNtX18gX192 b2xhdGlsZV9fICggUklTQ1ZfQUNRVUlSRV9CQVJSSUVSICIiIDo6OiAibWVtb3J5IiApCj4gPiAr Cj4gPiArI2RlZmluZSBfX2F0b21pY19yZWxlYXNlX2ZlbmNlKCkgXAo+ID4gK8KgwqDCoCBfX2Fz bV9fIF9fdm9sYXRpbGVfXyAoIFJJU0NWX1JFTEVBU0VfQkFSUklFUiAiIiA6OjogIm1lbW9yeSIg KQo+IAo+IEVsc2V3aGVyZSB5b3UgdXNlIGFzbSB2b2xhdGlsZSgpIC0gd2h5IF9fYXNtX18gX192 b2xhdGlsZV9fKCkgaGVyZT8KPiBPciB3aHkgbm90IHRoZXJlIChjbXB4Y2hnLmgsIGlvLmgpPwpJ dCBpcyBob3cgaXQgd2FzIGRlZmluZWQgaW4gTGludXgga2VybmVsLCBzbyBJIGRlY2lkZWQgdG8g dXNlIHRoZWlyCmNvZGUgc3R5bGUsIGJ1dCBjb25zaWRlcmluZyB0aGlzIG1hY3JvcyBsaWtlbHkg bm90IHRvIGJlIGNoYW5nZWQgSSBjYW4KdXBkYXRlIHRoaXMgbGluZXMgd2l0aCBhc20gdm9sYXRp bGUuCgo+IAo+ID4gKy8qCj4gPiArICogRmlyc3QsIHRoZSBhdG9taWMgb3BzIHRoYXQgaGF2ZSBu byBvcmRlcmluZyBjb25zdHJhaW50cyBhbmQKPiA+IHRoZXJlZm9yIGRvbid0Cj4gPiArICogaGF2 ZSB0aGUgQVEgb3IgUkwgYml0cyBzZXQuwqAgVGhlc2UgZG9uJ3QgcmV0dXJuIGFueXRoaW5nLCBz bwo+ID4gdGhlcmUncyBvbmx5Cj4gPiArICogb25lIHZlcnNpb24gdG8gd29ycnkgYWJvdXQuCj4g PiArICovCj4gPiArI2RlZmluZSBBVE9NSUNfT1Aob3AsIGFzbV9vcCwgSSwgYXNtX3R5cGUsIGNf dHlwZSwgcHJlZml4KcKgIFwKPiA+ICtzdGF0aWMgaW5saW5lwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqAgXAo+ID4gK3ZvaWQgYXRvbWljIyNwcmVmaXgjI18jI29wKGNfdHlwZSBp LCBhdG9taWMjI3ByZWZpeCMjX3QgKnYpIFwKPiA+ICt7wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgXAo+ID4gK8KgwqDCoCBfX2FzbV9f IF9fdm9sYXRpbGVfXyAowqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFwKPiA+ICvCoMKgwqDCoMKgwqDCoCAiwqDCoCBhbW8i ICNhc21fb3AgIi4iICNhc21fdHlwZSAiIHplcm8sICUxLCAlMCLCoMKgwqDCoMKgIFwKPiA+ICvC oMKgwqDCoMKgwqDCoCA6ICIrQSIgKHYtPmNvdW50ZXIpwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBcCj4gPiArwqDCoMKgwqDC oMKgwqAgOiAiciIgKEkpwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFwKPiA+ICvCoMKgwqDC oMKgwqDCoCA6ICJtZW1vcnkiICk7wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBcCj4gPiArfcKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFwKPiA+ ICsKPiA+ICsjZGVmaW5lIEFUT01JQ19PUFMob3AsIGFzbV9vcCwgSSnCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFwKPiA+ICvCoMKgwqDCoMKgwqDC oCBBVE9NSUNfT1AgKG9wLCBhc21fb3AsIEksIHcsIGludCzCoMKgICkKPiA+ICsKPiA+ICtBVE9N SUNfT1BTKGFkZCwgYWRkLMKgIGkpCj4gPiArQVRPTUlDX09QUyhzdWIsIGFkZCwgLWkpCj4gPiAr QVRPTUlDX09QUyhhbmQsIGFuZCzCoCBpKQo+ID4gK0FUT01JQ19PUFMoIG9yLMKgIG9yLMKgIGkp Cj4gPiArQVRPTUlDX09QUyh4b3IsIHhvcizCoCBpKQo+ID4gKwo+ID4gKyN1bmRlZiBBVE9NSUNf T1AKPiA+ICsjdW5kZWYgQVRPTUlDX09QUwo+ID4gKwo+ID4gKy8qCj4gPiArICogQXRvbWljIG9w cyB0aGF0IGhhdmUgb3JkZXJlZCwgcmVsYXhlZCwgYWNxdWlyZSwgYW5kIHJlbGVhc2UKPiA+IHZh cmlhbnRzLgo+ID4gKyAqIFRoZXJlJ3MgdHdvIGZsYXZvcnMgb2YgdGhlc2U6IHRoZSBhcml0aG1h dGljIG9wcyBoYXZlIGJvdGgKPiA+IGZldGNoIGFuZCByZXR1cm4KPiA+ICsgKiB2ZXJzaW9ucywg d2hpbGUgdGhlIGxvZ2ljYWwgb3BzIG9ubHkgaGF2ZSBmZXRjaCB2ZXJzaW9ucy4KPiA+ICsgKi8K PiA+ICsjZGVmaW5lIEFUT01JQ19GRVRDSF9PUChvcCwgYXNtX29wLCBJLCBhc21fdHlwZSwgY190 eXBlLAo+ID4gcHJlZml4KcKgwqDCoCBcCj4gPiArc3RhdGljCj4gPiBpbmxpbmXCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgXAo+ID4gK2NfdHlwZSBh dG9taWMjI3ByZWZpeCMjX2ZldGNoXyMjb3AjI19yZWxheGVkKGNfdHlwZQo+ID4gaSzCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoCBcCj4gPiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgIGF0b21pYyMjcHJlZml4IyNfdAo+ID4gKnYpwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBcCj4gPiAre8KgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAKPiA+ IMKgIFwKPiA+ICvCoMKgwqAgcmVnaXN0ZXIgY190eXBlCj4gPiByZXQ7wqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqAgXAo+ID4gK8KgwqDCoCBfX2FzbV9fIF9fdm9sYXRpbGVfXwo+ID4gKMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgXAo+ID4gK8KgwqDCoMKgwqDCoMKgICLCoMKgIGFtbyIg I2FzbV9vcCAiLiIgI2FzbV90eXBlICIgJTEsICUyLAo+ID4gJTAiwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgIFwKPiA+ICvCoMKgwqDCoMKgwqDCoCA6ICIrQSIgKHYtPmNvdW50ZXIpLCAi PXIiCj4gPiAocmV0KcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgIFwKPiA+ICvCoMKgwqDCoMKgwqDCoCA6ICJyIgo+ID4gKEkpwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBcCj4gPiArwqDCoMKgwqDCoMKgwqAg OiAibWVtb3J5Igo+ID4gKTvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBcCj4g PiArwqDCoMKgIHJldHVybgo+ID4gcmV0O8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgIFwKPiA+ICt9wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoAo+ID4gwqAgXAo+ID4gK3N0 YXRpYwo+ID4gaW5saW5lwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgIFwKPiA+ICtjX3R5cGUgYXRvbWljIyNwcmVmaXgjI19mZXRjaF8jI29wKGNfdHlw ZSBpLCBhdG9taWMjI3ByZWZpeCMjX3QKPiA+ICp2KSBcCj4gPiAre8KgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAK PiA+IMKgIFwKPiA+ICvCoMKgwqAgcmVnaXN0ZXIgY190eXBlCj4gPiByZXQ7wqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqAgXAo+ID4gK8KgwqDCoCBfX2FzbV9fIF9fdm9sYXRpbGVfXwo+ID4g KMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgXAo+ID4gK8KgwqDCoMKgwqDCoMKgICLCoMKgIGFt byIgI2FzbV9vcCAiLiIgI2FzbV90eXBlICIuYXFybMKgICUxLCAlMiwKPiA+ICUwIsKgwqDCoMKg wqDCoMKgwqDCoCBcCj4gPiArwqDCoMKgwqDCoMKgwqAgOiAiK0EiICh2LT5jb3VudGVyKSwgIj1y Igo+ID4gKHJldCnCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoCBcCj4gPiArwqDCoMKgwqDCoMKgwqAgOiAiciIKPiA+IChJKcKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgXAo+ID4gK8KgwqDCoMKgwqDCoMKgIDog Im1lbW9yeSIKPiA+ICk7wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgXAo+ID4g K8KgwqDCoCByZXR1cm4KPiA+IHJldDvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoCBcCj4gPiArfQo+ID4gKwo+ID4gKyNkZWZpbmUgQVRPTUlDX09QX1JFVFVS TihvcCwgYXNtX29wLCBjX29wLCBJLCBhc21fdHlwZSwgY190eXBlLAo+ID4gcHJlZml4KSBcCj4g PiArc3RhdGljCj4gPiBpbmxpbmXCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBcCj4gPiArY190eXBlIGF0b21pYyMjcHJlZml4IyNfIyNv cCMjX3JldHVybl9yZWxheGVkKGNfdHlwZQo+ID4gaSzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoCBcCj4gPiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqAgYXRvbWljIyNwcmVmaXgjI190Cj4gPiAqdinCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFwKPiA+ICt7wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoAo+ID4gwqDC oMKgwqDCoCBcCj4gPiArwqDCoMKgwqDCoMKgwqAgcmV0dXJuIGF0b21pYyMjcHJlZml4IyNfZmV0 Y2hfIyNvcCMjX3JlbGF4ZWQoaSwgdikgY19vcAo+ID4gSTvCoMKgwqDCoMKgIFwKPiA+ICt9wqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoAo+ID4gwqDCoMKgwqDCoCBcCj4gPiArc3RhdGljCj4gPiBpbmxpbmXCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBc Cj4gPiArY190eXBlIGF0b21pYyMjcHJlZml4IyNfIyNvcCMjX3JldHVybihjX3R5cGUgaSwgYXRv bWljIyNwcmVmaXgjI190Cj4gPiAqdinCoCBcCj4gPiAre8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAKPiA+IMKg wqDCoMKgwqAgXAo+ID4gK8KgwqDCoMKgwqDCoMKgIHJldHVybiBhdG9taWMjI3ByZWZpeCMjX2Zl dGNoXyMjb3AoaSwgdikgY19vcAo+ID4gSTvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAg XAo+ID4gK30KPiA+ICsKPiA+ICsjZGVmaW5lIEFUT01JQ19PUFMob3AsIGFzbV9vcCwgY19vcCwK PiA+IEkpwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoCBcCj4gPiArwqDCoMKgwqDCoMKgwqAgQVRPTUlDX0ZFVENIX09QKCBvcCwg YXNtX29wLMKgwqDCoMKgwqDCoCBJLCB3LCBpbnQswqDCoAo+ID4gKcKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAgXAo+ID4gK8KgwqDCoMKgwqDCoMKgIEFUT01JQ19PUF9SRVRVUk4ob3AsIGFz bV9vcCwgY19vcCwgSSwgdywgaW50LMKgwqAgKQo+IAo+IFdoYXQgcHVycG9zZSBpcyB0aGUgbGFz dCBtYWNybyBhcmd1bWVudCB3aGVuIHlvdSBvbmx5IGV2ZXIgcGFzcwo+IG5vdGhpbmcKPiBmb3Ig aXQgKGhlcmUgYW5kIC4uLgo+IAo+ID4gK0FUT01JQ19PUFMoYWRkLCBhZGQsICsswqAgaSkKPiA+ ICtBVE9NSUNfT1BTKHN1YiwgYWRkLCArLCAtaSkKPiA+ICsKPiA+ICsjdW5kZWYgQVRPTUlDX09Q Uwo+ID4gKwo+ID4gKyNkZWZpbmUgQVRPTUlDX09QUyhvcCwgYXNtX29wLCBJKSBcCj4gPiArwqDC oMKgwqDCoMKgwqAgQVRPTUlDX0ZFVENIX09QKG9wLCBhc21fb3AsIEksIHcsIGludCzCoMKgICkK PiAKPiAuLi4gaGVyZSk/CmZvciBnZW5lcmljIEFUT01JQzY0IGl0IGlzIG5vdCB1c2VkOgoKI2lm ZGVmIENPTkZJR19HRU5FUklDX0FUT01JQzY0CiNkZWZpbmUgQVRPTUlDX09QUyhvcCwgYXNtX29w LCBjX29wLApJKQkJCQkJXAogICAgICAgIEFUT01JQ19GRVRDSF9PUCggb3AsIGFzbV9vcCwgICAg ICAgSSwgdywgaW50LCAgCikJCVwKICAgICAgICBBVE9NSUNfT1BfUkVUVVJOKG9wLCBhc21fb3As IGNfb3AsIEksIHcsIGludCwgICApCiNlbHNlCiNkZWZpbmUgQVRPTUlDX09QUyhvcCwgYXNtX29w LCBjX29wLApJKQkJCQkJXAogICAgICAgIEFUT01JQ19GRVRDSF9PUCggb3AsIGFzbV9vcCwgICAg ICAgSSwgdywgaW50LCAgCikJCVwKICAgICAgICBBVE9NSUNfT1BfUkVUVVJOKG9wLCBhc21fb3As IGNfb3AsIEksIHcsIGludCwgIAopCQlcCiAgICAgICAgQVRPTUlDX0ZFVENIX09QKCBvcCwgYXNt X29wLCAgICAgICBJLCBkLCBzNjQsCjY0KQkJXAogICAgICAgIEFUT01JQ19PUF9SRVRVUk4ob3As IGFzbV9vcCwgY19vcCwgSSwgZCwgczY0LCA2NCkKI2VuZGlmCgooIHRoZSBjb2RlIGlzIGZyb20g TGludXgga2VybmVsICkKT25seSBDT05GSUdfR0VORVJJQ19BVE9NSUM2ND15IHdhcyBwb3J0ZWQg dG8gWGVuLgoKPiAKPiA+ICtBVE9NSUNfT1BTKGFuZCwgYW5kLCBpKQo+ID4gK0FUT01JQ19PUFMo IG9yLMKgIG9yLCBpKQo+ID4gK0FUT01JQ19PUFMoeG9yLCB4b3IsIGkpCj4gPiArCj4gPiArI3Vu ZGVmIEFUT01JQ19PUFMKPiA+ICsKPiA+ICsjdW5kZWYgQVRPTUlDX0ZFVENIX09QCj4gPiArI3Vu ZGVmIEFUT01JQ19PUF9SRVRVUk4KPiA+ICsKPiA+ICsvKiBUaGlzIGlzIHJlcXVpcmVkIHRvIHBy b3ZpZGUgYSBmdWxsIGJhcnJpZXIgb24gc3VjY2Vzcy4gKi8KPiA+ICtzdGF0aWMgaW5saW5lIGlu dCBhdG9taWNfYWRkX3VubGVzcyhhdG9taWNfdCAqdiwgaW50IGEsIGludCB1KQo+ID4gK3sKPiA+ ICvCoMKgwqDCoMKgwqAgaW50IHByZXYsIHJjOwo+ID4gKwo+ID4gK8KgwqDCoCBfX2FzbV9fIF9f dm9sYXRpbGVfXyAoCj4gPiArwqDCoMKgwqDCoMKgwqAgIjA6IGxyLnfCoMKgwqDCoCAlW3BdLMKg ICVbY11cbiIKPiA+ICvCoMKgwqDCoMKgwqDCoCAiwqDCoCBiZXHCoMKgwqDCoMKgICVbcF0swqAg JVt1XSwgMWZcbiIKPiA+ICvCoMKgwqDCoMKgwqDCoCAiwqDCoCBhZGTCoMKgwqDCoMKgICVbcmNd LCAlW3BdLCAlW2FdXG4iCj4gPiArwqDCoMKgwqDCoMKgwqAgIsKgwqAgc2Mudy5ybMKgICVbcmNd LCAlW3JjXSwgJVtjXVxuIgo+ID4gK8KgwqDCoMKgwqDCoMKgICLCoMKgIGJuZXrCoMKgwqDCoCAl W3JjXSwgMGJcbiIKPiA+ICvCoMKgwqDCoMKgwqDCoCBSSVNDVl9GVUxMX0JBUlJJRVIKPiA+ICvC oMKgwqDCoMKgwqDCoCAiMTpcbiIKPiA+ICvCoMKgwqDCoMKgwqDCoCA6IFtwXSAiPSZyIiAocHJl diksIFtyY10gIj0mciIgKHJjKSwgW2NdICIrQSIgKHYtPmNvdW50ZXIpCj4gPiArwqDCoMKgwqDC oMKgwqAgOiBbYV0gInIiIChhKSwgW3VdICJyIiAodSkKPiA+ICvCoMKgwqDCoMKgwqDCoCA6ICJt ZW1vcnkiKTsKPiA+ICvCoMKgwqAgcmV0dXJuIHByZXY7Cj4gPiArfQo+ID4gKwo+ID4gKy8qCj4g PiArICogYXRvbWljX3tjbXAsfXhjaGcgaXMgcmVxdWlyZWQgdG8gaGF2ZSBleGFjdGx5IHRoZSBz YW1lIG9yZGVyaW5nCj4gPiBzZW1hbnRpY3MgYXMKPiA+ICsgKiB7Y21wLH14Y2hnIGFuZCB0aGUg b3BlcmF0aW9ucyB0aGF0IHJldHVybiwgc28gdGhleSBuZWVkIGEgZnVsbAo+ID4gYmFycmllci4K PiA+ICsgKi8KPiA+ICsjZGVmaW5lIEFUT01JQ19PUChjX3QsIHByZWZpeCwgc2l6ZSnCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgXAo+ID4gK3N0 YXRpYyBpbmxpbmXCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFwK PiA+ICtjX3QgYXRvbWljIyNwcmVmaXgjI194Y2hnX3JlbGF4ZWQoYXRvbWljIyNwcmVmaXgjI190 ICp2LCBjX3QgbikgXAo+ID4gK3vCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFwKPiA+ICvCoMKgwqAgcmV0dXJuIF9feGNo Z19nZW5lcmljKCYodi0+Y291bnRlciksIG4sIHNpemUsICIiLCAiIiwgIiIpO8KgIFwKPiAKPiBU aGUgaW5uZXIgcGFyZW50aGVzZXMgYXJlbid0IHJlYWxseSBuZWVkZWQgaGVyZSwgYXJlIHRoZXk/ Cj4gCj4gPiArfcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqAgXAo+ID4gK3N0YXRpYyBpbmxpbmXCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFwKPiA+ICtjX3QgYXRvbWljIyNwcmVmaXgjI194 Y2hnX2FjcXVpcmUoYXRvbWljIyNwcmVmaXgjI190ICp2LCBjX3QgbikgXAo+ID4gK3vCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgIFwKPiA+ICvCoMKgwqAgcmV0dXJuIF9feGNoZ19nZW5lcmljKCYodi0+Y291bnRlciksIG4s IHNpemUswqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBcCj4gPiArwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgIiIsICIiLCBSSVNDVl9BQ1FVSVJF X0JBUlJJRVIpO8KgwqDCoMKgwqDCoCBcCj4gPiArfcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgXAo+ID4gK3N0YXRpYyBp bmxpbmXCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFwKPiA+ICtj X3QgYXRvbWljIyNwcmVmaXgjI194Y2hnX3JlbGVhc2UoYXRvbWljIyNwcmVmaXgjI190ICp2LCBj X3QgbikgXAo+ID4gK3vCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFwKPiA+ICvCoMKgwqAgcmV0dXJuIF9feGNoZ19nZW5l cmljKCYodi0+Y291bnRlciksIG4sIHNpemUswqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBc Cj4gPiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAg IiIsIFJJU0NWX1JFTEVBU0VfQkFSUklFUiwgIiIpO8KgwqDCoMKgwqDCoCBcCj4gPiArfcKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqAgXAo+ID4gK3N0YXRpYyBpbmxpbmXCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgIFwKPiA+ICtjX3QgYXRvbWljIyNwcmVmaXgjI194Y2hnKGF0b21pYyMjcHJl Zml4IyNfdCAqdiwgY190IG4pwqDCoMKgwqDCoMKgwqDCoCBcCj4gPiAre8KgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgXAo+ ID4gK8KgwqDCoCByZXR1cm4gX194Y2hnX2dlbmVyaWMoJih2LT5jb3VudGVyKSwgbiwgc2l6ZSzC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFwKPiA+ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAiLmFxcmwiLCAiIiwgIiIpO8KgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgXAo+ID4gK33CoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFwKPiA+ICtz dGF0aWMgaW5saW5lwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBc Cj4gPiArY190IGF0b21pYyMjcHJlZml4IyNfY21weGNoZ19yZWxheGVkKGF0b21pYyMjcHJlZml4 IyNfdCAqdizCoMKgwqDCoCBcCj4gPiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoCBjX3QgbywgY190IG4pwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBcCj4gPiAre8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgXAo+ID4gK8KgwqDCoCBy ZXR1cm4gX19jbXB4Y2hnX2dlbmVyaWMoJih2LT5jb3VudGVyKSwgbywgbiwgc2l6ZSzCoMKgwqDC oMKgwqDCoMKgIFwKPiA+ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoCAiIiwgIiIsICIiKTvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoCBcCj4gPiArfcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgXAo+ID4gK3N0YXRpYyBpbmxpbmXC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFwKPiA+ICtjX3QgYXRv bWljIyNwcmVmaXgjI19jbXB4Y2hnX2FjcXVpcmUoYXRvbWljIyNwcmVmaXgjI190ICp2LMKgwqDC oMKgIFwKPiA+ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGNfdCBv LCBjX3QgbinCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgIFwKPiA+ICt7wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBcCj4gPiArwqDCoMKgIHJldHVybiBfX2NtcHhj aGdfZ2VuZXJpYygmKHYtPmNvdW50ZXIpLCBvLCBuLCBzaXplLMKgwqDCoMKgwqDCoMKgwqAgXAo+ ID4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgICIiLCAiIiwgUklTQ1ZfQUNRVUlSRV9CQVJSSUVSKTvCoMKgwqAgXAo+ID4gK33CoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgIFwKPiA+ICtzdGF0aWMgaW5saW5lwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoCBcCj4gPiArY190IGF0b21pYyMjcHJlZml4IyNfY21weGNoZ19yZWxlYXNlKGF0 b21pYyMjcHJlZml4IyNfdCAqdizCoMKgwqDCoCBcCj4gPiArwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoCBjX3QgbywgY190IG4pwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBcCj4gPiArewnCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoAo+ID4gwqAgXAo+ IAo+IEEgaGFyZCB0YWIgbG9va3MgdG8gaGF2ZSBiZWVuIGxlZnQgaGVyZS4KPiAKPiA+ICvCoMKg wqAgcmV0dXJuIF9fY21weGNoZ19nZW5lcmljKCYodi0+Y291bnRlciksIG8sIG4sIHNpemUswqDC oMKgwqDCoMKgwqDCoCBcCj4gPiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqAgIiIsIFJJU0NWX1JFTEVBU0VfQkFSUklFUiwgIiIpO8KgwqDC oCBcCj4gPiArfcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqAgXAo+ID4gK3N0YXRpYyBpbmxpbmXCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFwKPiA+ICtjX3QgYXRvbWljIyNwcmVmaXgjI19j bXB4Y2hnKGF0b21pYyMjcHJlZml4IyNfdCAqdiwgY190IG8sIGNfdCBuKQo+ID4gXAo+ID4gK3vC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgIFwKPiA+ICvCoMKgwqAgcmV0dXJuIF9fY21weGNoZ19nZW5lcmljKCYodi0+Y291 bnRlciksIG8sIG4sIHNpemUswqDCoMKgwqDCoMKgwqDCoCBcCj4gPiArwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgIi5ybCIsICIiLCAiIGZl bmNlIHJ3LCByd1xuIik7wqDCoMKgwqAgXAo+ID4gK30KPiA+ICsKPiA+ICsjZGVmaW5lIEFUT01J Q19PUFMoKSBcCj4gPiArwqDCoMKgIEFUT01JQ19PUChpbnQswqDCoCAsIDQpCj4gPiArCj4gPiAr QVRPTUlDX09QUygpCj4gPiArCj4gPiArI3VuZGVmIEFUT01JQ19PUFMKPiA+ICsjdW5kZWYgQVRP TUlDX09QCj4gPiArCj4gPiArc3RhdGljIGlubGluZSBpbnQgYXRvbWljX3N1Yl9pZl9wb3NpdGl2 ZShhdG9taWNfdCAqdiwgaW50IG9mZnNldCkKPiA+ICt7Cj4gPiArwqDCoMKgwqDCoMKgIGludCBw cmV2LCByYzsKPiA+ICsKPiA+ICvCoMKgwqAgX19hc21fXyBfX3ZvbGF0aWxlX18gKAo+ID4gK8Kg wqDCoMKgwqDCoMKgICIwOiBsci53wqDCoMKgwqAgJVtwXSzCoCAlW2NdXG4iCj4gPiArwqDCoMKg wqDCoMKgwqAgIsKgwqAgc3ViwqDCoMKgwqDCoCAlW3JjXSwgJVtwXSwgJVtvXVxuIgo+ID4gK8Kg wqDCoMKgwqDCoMKgICLCoMKgIGJsdHrCoMKgwqDCoCAlW3JjXSwgMWZcbiIKPiA+ICvCoMKgwqDC oMKgwqDCoCAiwqDCoCBzYy53LnJswqAgJVtyY10sICVbcmNdLCAlW2NdXG4iCj4gPiArwqDCoMKg wqDCoMKgwqAgIsKgwqAgYm5lesKgwqDCoMKgICVbcmNdLCAwYlxuIgo+ID4gK8KgwqDCoMKgwqDC oMKgICLCoMKgIGZlbmNlwqDCoMKgIHJ3LCByd1xuIgo+ID4gK8KgwqDCoMKgwqDCoMKgICIxOlxu Igo+ID4gK8KgwqDCoMKgwqDCoMKgIDogW3BdICI9JnIiIChwcmV2KSwgW3JjXSAiPSZyIiAocmMp LCBbY10gIitBIiAodi0+Y291bnRlcikKPiA+ICvCoMKgwqDCoMKgwqDCoCA6IFtvXSAiciIgKG9m ZnNldCkKPiA+ICvCoMKgwqDCoMKgwqDCoCA6ICJtZW1vcnkiICk7Cj4gPiArwqDCoMKgIHJldHVy biBwcmV2IC0gb2Zmc2V0Owo+ID4gK30KPiA+ICsKPiA+ICsjZGVmaW5lIGF0b21pY19kZWNfaWZf cG9zaXRpdmUodikJYXRvbWljX3N1Yl9pZl9wb3NpdGl2ZSh2LAo+ID4gMSkKPiAKPiBIbW0sIFBQ QyBmb3Igc29tZSByZWFzb24gYWxzbyBoYXMgdGhlIGxhdHRlciwgYnV0IGZvciBib3RoOiBBcmUg dGhleQo+IGluZGVlZAo+IGdvaW5nIHRvIGJlIG5lZWRlZCBpbiBSSVNDLVYgY29kZT8gVGhleSBj ZXJ0YWlubHkgbG9vayB1bm5lY2Vzc2FyeQo+IGZvciB0aGUKPiBwdXJwb3NlIG9mIHRoaXMgc2Vy aWVzIChhbGxvd2luZyBjb21tb24gY29kZSB0byBidWlsZCkuCkkgY2hlY2tlZCBteSBwcml2YXRl IGJyYW5jaGVkIGFuZCBJIGRvbid0IHVzZSBpdCBzdGlsbCwgc28gaXQgbWFrZXMKc2Vuc2UgdG8g ZHJvcCBpdC4KCj4gCj4gPiAtLS0gL2Rldi9udWxsCj4gPiArKysgYi94ZW4vaW5jbHVkZS9hc20t Z2VuZXJpYy9hdG9taWMtb3BzLmgKPiA+IEBAIC0wLDAgKzEsOTIgQEAKPiA+ICsjLyogU1BEWC1M aWNlbnNlLUlkZW50aWZpZXI6IEdQTC0yLjAgKi8KPiA+ICsjaWZuZGVmIF9BU01fR0VORVJJQ19B VE9NSUNfT1BTX0hfCj4gPiArI2RlZmluZSBfQVNNX0dFTkVSSUNfQVRPTUlDX09QU19IXwo+ID4g Kwo+ID4gKyNpbmNsdWRlIDx4ZW4vYXRvbWljLmg+Cj4gPiArI2luY2x1ZGUgPHhlbi9saWIuaD4K PiAKPiBJZiBJJ20gbm90IG1pc3Rha2VuIHRoaXMgaGVhZGVyIHByb3ZpZGVzIGRlZmF1bHQgaW1w bGVtZW50YXRpb25zIGZvcgo+IGV2ZXJ5Cj4geGVuL2F0b21pYy5oLXByb3ZpZGVkIGZvcndhcmQg aW5saW5lIGRlY2xhcmF0aW9uIHRoYXQgY2FuIGJlCj4gc3ludGhlc2l6ZWQKPiBmcm9tIG90aGVy IGF0b21pYyBmdW5jdGlvbnMuIEkgdGhpbmsgYSBjb21tZW50IHRvIHRoaXMgZWZmZWN0IHdvdWxk Cj4gd2FudAo+IGFkZGluZyBzb21ld2hlcmUgaGVyZS4KSSB0aGluayB3ZSBjYW4gZHJvcCB0aGlz IGluY2x1c2lvbiBoZXJlIGFzIGluY2x1c2lvbiBvZiBhc20tCmdlbmVyaWMvYXRvbWljLW9wcy5o IHdpbGwgYmUgYWx3YXlzIGdvIHdpdGggaW5jbHVzaW9uIG9mIHhlbi9hdG9taWMuaC4KCn4gT2xl a3NpaQo= From xen-devel-bounces@lists.xenproject.org Thu Mar 07 13:44:14 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 13:44:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689917.1075393 (Exim 4.92) (envelope-from ) id 1riE2Z-0004Xs-FK; Thu, 07 Mar 2024 13:44:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689917.1075393; Thu, 07 Mar 2024 13:44:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riE2Z-0004Xl-Az; Thu, 07 Mar 2024 13:44:07 +0000 Received: by outflank-mailman (input) for mailman id 689917; Thu, 07 Mar 2024 13:44:06 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riE2Y-0004Xf-Me for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 13:44:06 +0000 Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [2a00:1450:4864:20::236]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id c363807c-dc88-11ee-afda-a90da7624cb6; Thu, 07 Mar 2024 14:44:05 +0100 (CET) Received: by mail-lj1-x236.google.com with SMTP id 38308e7fff4ca-2d220e39907so12691061fa.1 for ; Thu, 07 Mar 2024 05:44:05 -0800 (PST) Received: from [192.168.206.239] ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id x8-20020ac24888000000b0051339f52ab2sm2382652lfc.44.2024.03.07.05.44.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Mar 2024 05:44:03 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c363807c-dc88-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709819044; x=1710423844; darn=lists.xenproject.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=dLQyOgC7oCB4XH+j56vcNggej4dBp4ikLJCYir2pJAk=; b=ikHAYHM3tG15Fjb/Ye+0SzUgYlyg5fq44QATvVqwm4pMYgMMclD7b4dvD0tpV9sXu2 KpCFOJsk4cJ4AqoDTI1lekf9fwijFwj6cCG5u3tcTRASAcXAK6AsmJmUSWB5jbCEd7Y8 EM0sOnaX1d0WuoaEN9GdeH/9MaBnFggK6To9BIBnBb3MTkqIDxRenCFRJ2HtC1a8Gm17 5Ng/iGFvUTIZhRqjeP6IHJSkRXfION7bYhjed4o4AqA8C/F+lAoWcUCvQbCKJAgt/oR/ g3Gzs99fbPAbF7pne0HndUzWGh6UKWUaze/Cu8zUWV/kVdI2vqCdw1Pnmlb4DdY4PYZl lkQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709819044; x=1710423844; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=dLQyOgC7oCB4XH+j56vcNggej4dBp4ikLJCYir2pJAk=; b=ie/P7kQ0PqIFmFUHTb+4ejlbOJaeJwYmJM82cds7NCL4UvoDHQaziblNtXyLKF+8zC pFK0qvKvTxfZCbt4Ar5WPfZvNI7AoOm2dm0nUBK2f29IOLK4Ak4n9KlIqcap/KxQwWRO PjkJ5pj8+JufQGLPA5UedKW16a5uSvPtq9U6eexN7j6kRf/w1bLonZZXn07aGL87mvlF tiJZq61c/yp4bA9Iv7Tl9yOZeWEJMkW9jRPpmdsfUg3WDsuWd+KPTlSm06Y88GusJRpb IeJxxVjIR8Rswt2PEht+gJwvNhUk1F7+fwQupoDR0iZQ/A+Y+sw0jjx4dfO3NdJArLhe c30A== X-Forwarded-Encrypted: i=1; AJvYcCUlQWqSO7fWboCcPntlJpgw0qxHhO51nZ7CbU9nCaxW9OYocoAag5NVkmbrwdNHmMWwtkFs2oTQyry8fHBipGLCPDbdUfaKXQflmhHOyDA= X-Gm-Message-State: AOJu0YzMsjSgXtAfpQX5V3rBcVjw2gFbzOTS32grRJaFMIk3C5l9eGIi qOs9kVSUz+b8joyTb218Gkmm9gt+bdTLhmLlTzYV6UXlhvHLahXQ X-Google-Smtp-Source: AGHT+IFeWdb9Ze3uZWUOe+fLt7Nd4TwW3pzQ4SKUyp/ZjKMalMQwsGaGL6dLzSiMQGOIbD5D1OcGQA== X-Received: by 2002:a19:3841:0:b0:513:6108:60a3 with SMTP id d1-20020a193841000000b00513610860a3mr1398776lfj.45.1709819043976; Thu, 07 Mar 2024 05:44:03 -0800 (PST) Message-ID: <2a3e49bf94332c17b50e4f0f745e4b28b16dceb1.camel@gmail.com> Subject: Re: [PATCH v5 12/23] xen/riscv: introduce io.h From: Oleksii To: Jan Beulich Cc: Alistair Francis , Bob Eshleman , Connor Davis , Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu , xen-devel@lists.xenproject.org Date: Thu, 07 Mar 2024 14:44:02 +0100 In-Reply-To: References: <807c31d5-0c5a-4646-ba90-2f284289069f@suse.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.50.2 (3.50.2-1.fc39) MIME-Version: 1.0 On Thu, 2024-03-07 at 14:24 +0100, Jan Beulich wrote: > On 07.03.2024 14:01, Oleksii wrote: > > On Wed, 2024-03-06 at 15:13 +0100, Jan Beulich wrote: > > > > +/* Generic IO read/write.=C2=A0 These perform native-endian > > > > accesses. > > > > */ > > > > +static inline void __raw_writeb(uint8_t val, volatile void > > > > __iomem > > > > *addr) > > > > +{ > > > > +=C2=A0=C2=A0=C2=A0 asm volatile ( "sb %0, 0(%1)" : : "r" (val), "r= " (addr) ); > > > > +} > > >=20 > > > I realize this is like Linux has it, but how is the compiler to > > > know > > > that > > > *addr is being access here?=C2=A0 > > Assembler syntax told compiler that. 0(%1) - means that the memory > > location pointed to by the address in register %1. >=20 > No, the compiler doesn't decompose the string to figure how operands > are used. That's what the constraints are for. The only two things > the > compiler does with the string is replace % operators and count line > separators. It looks like I am missing something. addr -> a some register ( because of "r" contraint ). val -> is also register ( because of "r" contraint ). So the compiler will update instert an instruction: sb reg1, 0(reg2) what means *(uint_8 *)reg2 =3D (uint8_t)reg1. What am I missing? ~ Oleksii From xen-devel-bounces@lists.xenproject.org Thu Mar 07 13:52:59 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 13:52:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689921.1075403 (Exim 4.92) (envelope-from ) id 1riEB5-0007tD-7z; Thu, 07 Mar 2024 13:52:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689921.1075403; Thu, 07 Mar 2024 13:52:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riEB5-0007t6-59; Thu, 07 Mar 2024 13:52:55 +0000 Received: by outflank-mailman (input) for mailman id 689921; Thu, 07 Mar 2024 13:52:53 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riEB3-0007t0-NY for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 13:52:53 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id fdde3b9b-dc89-11ee-afda-a90da7624cb6; Thu, 07 Mar 2024 14:52:52 +0100 (CET) Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) by support.bugseng.com (Postfix) with ESMTPA id CB8364EE0738; Thu, 7 Mar 2024 14:52:51 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fdde3b9b-dc89-11ee-afda-a90da7624cb6 MIME-Version: 1.0 Date: Thu, 07 Mar 2024 14:52:51 +0100 From: Nicola Vetrini To: Jan Beulich Cc: Stefano Stabellini , xen-devel@lists.xenproject.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, consulting@bugseng.com, andrew.cooper3@citrix.com, roger.pau@citrix.com, bertrand.marquis@arm.com, julien@xen.org, George Dunlap , Wei Liu Subject: Re: [XEN PATCH 10/10] xen/keyhandler: address violations of MISRA C Rule 20.7 In-Reply-To: References: <2bc4a964f0f2f47488e72237678e944dbdbd7bb7.1709219010.git.nicola.vetrini@bugseng.com> <1afd8805-7365-40ec-8e8e-468a83e20c40@suse.com> Message-ID: <43b7edf1f4d9169a36198b18519c5714@bugseng.com> X-Sender: nicola.vetrini@bugseng.com Organization: BUGSENG s.r.l. Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 2024-03-07 08:42, Jan Beulich wrote: > On 07.03.2024 02:39, Stefano Stabellini wrote: >> On Tue, 5 Mar 2024, Jan Beulich wrote: >>> On 05.03.2024 03:03, Stefano Stabellini wrote: >>>> On Mon, 4 Mar 2024, Jan Beulich wrote: >>>>> On 02.03.2024 02:37, Stefano Stabellini wrote: >>>>>> On Fri, 1 Mar 2024, Jan Beulich wrote: >>>>>>> On 29.02.2024 23:57, Stefano Stabellini wrote: >>>>>>>> On Thu, 29 Feb 2024, Nicola Vetrini wrote: >>>>>>>>> MISRA C Rule 20.7 states: "Expressions resulting from the >>>>>>>>> expansion >>>>>>>>> of macro parameters shall be enclosed in parentheses". >>>>>>>>> Therefore, some >>>>>>>>> macro definitions should gain additional parentheses to ensure >>>>>>>>> that all >>>>>>>>> current and future users will be safe with respect to >>>>>>>>> expansions that >>>>>>>>> can possibly alter the semantics of the passed-in macro >>>>>>>>> parameter. >>>>>>>>> >>>>>>>>> No functional change. >>>>>>>>> >>>>>>>>> Signed-off-by: Nicola Vetrini >>>>>>>> >>>>>>>> Reviewed-by: Stefano Stabellini >>>>>>> >>>>>>> You did see the discussion on earlier patches, though? I don't >>>>>>> think >>>>>>> any of the parentheses here are needed or wanted. >>>>>> >>>>>> We need to align on this. Currently if we go by what's written in >>>>>> docs/misra/deviations.rst, then rhs should have parentheses. >>>>> >>>>> Quoting the actual patch again: >>>> >>>> [...] >>>> >>>>> What rhs are you talking about in light of this change? The only >>>>> rhs I >>>>> can spot here is already parenthesized. >>>> >>>> Yes you are right. I replied here as an overall comment about our >>>> approach to 20.7, although this patch is not a good example. My >>>> reply >>>> was meant in the context of >>>> https://marc.info/?l=xen-devel&m=170928051025701 >>> >>> I'm still confused: The rhs is being parenthsized there. It's the >>> _lhs_ >>> which isn't and ... >>> >>>>>> Can we safely claim that rhs parentheses are never needed? If so, >>>>>> then >>>>>> great, let's add it to deviations.rst and skip them here and other >>>>>> places in this patch series (e.g. patch #8). When I say "never" I >>>>>> am >>>>>> taking for granted that the caller is not doing something >>>>>> completely >>>>>> unacceptably broken such as: >>>>>> >>>>>> WRITE_SYSREG64(var +, TTBR0_EL1) >>>>> >>>>> I'm afraid I can't associate this with the patch here either. >>>>> Instead in >>>>> the context here a (respective) construct as you mention above >>>>> would simply >>>>> fail to build. >>>> >>>> Fair enough it will break the build. I was trying to clarify that >>>> when I >>>> wrote "the rhs parentheses are never needed" I meant "never" within >>>> reason. One can always find ways to break the system and I tried to >>>> make >>>> an example of something that for sure would break rhs or lhs without >>>> parentheses. >>>> >>>> I meant to say, if we don't account for exceptionally broken cases, >>>> can >>>> we safety say we don't need parentheses for rhs? >>> >>> ... doesn't need to, unless - as you say - one contrives examples. >>> Yet to >>> clarify here as well: I assume you mean "we don't need parentheses >>> for lhs". >> >> Yes. Far clarity, we are all aligned that lhs does not need >> parentheses >> and in fact it is even already deviated in docs/misra/deviations.rst. >> >> Now back to this specific patch. >> >> The problem is that the comma ',' doesn't need parenthesis for the >> parameters. However, the way we wrote the deviation in >> docs/misra/deviations.rst doesn't cover the case this patch is dealing >> with. docs/misra/deviations.rst only speaks of functions and macros >> arguments. >> >> Should we rephrase docs/misra/deviations.rst in terms of ',' instead ? > > That's what I've requested elsewhere, yes. > >> Can ECLAR deal with it? > > I seem to vaguely recall Nicola saying it can, but if not then it > surely > can be made to do so. > > Jan Yes. In v2 I'll write the deviation, so that this patch and other can be dropped, since they only deal with this subcase. -- Nicola Vetrini, BSc Software Engineer, BUGSENG srl (https://bugseng.com) From xen-devel-bounces@lists.xenproject.org Thu Mar 07 13:56:35 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 13:56:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689924.1075412 (Exim 4.92) (envelope-from ) id 1riEEb-0008TI-N6; Thu, 07 Mar 2024 13:56:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689924.1075412; Thu, 07 Mar 2024 13:56:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riEEb-0008TB-KL; Thu, 07 Mar 2024 13:56:33 +0000 Received: by outflank-mailman (input) for mailman id 689924; Thu, 07 Mar 2024 13:56:32 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riEEZ-0008T0-Sv for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 13:56:31 +0000 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on20601.outbound.protection.outlook.com [2a01:111:f403:2417::601]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 7ecb0847-dc8a-11ee-a1ee-f123f15fe8a2; Thu, 07 Mar 2024 14:56:29 +0100 (CET) Received: from SJ0PR13CA0138.namprd13.prod.outlook.com (2603:10b6:a03:2c6::23) by CH3PR12MB8880.namprd12.prod.outlook.com (2603:10b6:610:17b::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.26; Thu, 7 Mar 2024 13:56:23 +0000 Received: from SJ5PEPF000001C8.namprd05.prod.outlook.com (2603:10b6:a03:2c6:cafe::1c) by SJ0PR13CA0138.outlook.office365.com (2603:10b6:a03:2c6::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.8 via Frontend Transport; Thu, 7 Mar 2024 13:56:22 +0000 Received: from SATLEXMB03.amd.com (165.204.84.17) by SJ5PEPF000001C8.mail.protection.outlook.com (10.167.242.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7362.11 via Frontend Transport; Thu, 7 Mar 2024 13:56:22 +0000 Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 7 Mar 2024 07:56:21 -0600 Received: from henry-MS-7D54.amd.com (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend Transport; Thu, 7 Mar 2024 07:56:20 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 7ecb0847-dc8a-11ee-a1ee-f123f15fe8a2 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XyQ4q3jfixL9gdKLG6NBP4HiurWtUXx2Bl5GbNvqXMcA0ktHPLL+CHfFGMSPzTHvuVpFrxPU/WO6FCt0KfbdFuDV5yJ44KWZBqC697SCxkRUN1gABQHJULSA9f5hbh/jSb2q66KcOxpr60XnhRo1wd23pAPw0tXAbS+7+K02mjkmdXMTK5Fu+ngussSyCqaZ5SaKiO9wg1sWWmAXkzJosY0SDBCyGVG6Z+IAJYzTodAPlXMr+WVmwaTv4ORXG3xHeOBV8REwnYaLQScER96E+2XathxgAyX6fwGyUR5FsEQcSY8EtJDaP3d2HUF43VRrjohk6k2BqluimXoM+LkJTA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=kwMVbPg4+WKCy5F7bQxVc2/fbCEkF426EOJxgKoiuOA=; b=XdWRjWtrSkRAA9T5zbTLZl6+HFlLAEnp7mcoCpS7oDYGnc34aI5SLaRp1rwiZzDM3p/04ZA7WR+rWhob31lAJSLO+pEkyc+HLZaw3wwB1CG6vdmrOqNinbB7IWOTONYl6EFV58AyJZMzgt9SAMQKXSs16CL/CCBLJjly6HkLQ7mZBrLYXwNaUksjF4b+n4eMlOM9v7ymqw37wctmsmgFyz8hvdRPvN88ZhsCI2xftwyJ5DvW6g1pYzS0XavKgX0LX6BgFZ287uQaM3qz2rFauA4pgk66hiaCUpI6FOtL7yTMt/odCiTm1PQLxdqQ5l7ZsYMzntMpbXVjlro3V8eKEA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kwMVbPg4+WKCy5F7bQxVc2/fbCEkF426EOJxgKoiuOA=; b=D1OgkKghrTa3m0J2mVy2X9Jbm6jLnJFXb9piCiuF9V+KL4UbYpqr+BDlELwuSOgmnLj21c1ZSsJfy9oz9s0jcJv0HGn8qkTcUeX+eMSjenAiKKTaQWfOG9NtO9bR8WsrvhePRmNwS6JJL6HxfzuBQm1JNW+0giiwAfAOauVIEhs= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C From: Henry Wang To: CC: Henry Wang , Wei Liu , Anthony PERARD , Juergen Gross , Jan Beulich Subject: [PATCH v3] tools/9pfsd: Fix build error caused by strerror_r Date: Thu, 7 Mar 2024 21:56:16 +0800 Message-ID: <20240307135616.3953774-1-xin.wang2@amd.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain Received-SPF: None (SATLEXMB03.amd.com: xin.wang2@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ5PEPF000001C8:EE_|CH3PR12MB8880:EE_ X-MS-Office365-Filtering-Correlation-Id: 9323798b-54aa-45ba-74f5-08dc3eae5f74 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: jOToZOAqNWqYzVcLYojz+kHg3agXpGw0d6AvVwTwWl3lMwfwbjAL277fKgXKKLv5RYiq32At1neHsGVN5tTiqB5EJWCHuhCnVBYLTYJYiYYu1u2VVFuDhIaN5N4ELLSUhlirHCtqaY1Ku3cpspHuMlWCyB1XpX3LGwiknJbCiOi9GfXhM0Yiww/rj3pp1C6HDhZowZHEug5uTFaPtfBHQGYp/PofNcG/LFRpgVIJ0aLT6W76geJmOi1umKvNgworbo04s0+D0d5zxfBMWa1Mk9spV0LBWXe1vjll2U0AGEEM1WfMz0KBD7Lad6lDtWsRhonyNlG3cgQ/G0Z+wUVQJ4G1k2Vm5/jDXdf0C9XH3d5u+r99Nr1pXccgux8VrYog6Xac36qOPvZUmXlLkTpsawNjGYngaGUe1lXJ3N5/M8vyrHjEva8ajBFxM0d8b9KBB8isJpqJVki8q5XtYEiTHSObZQe7gozKkbKFcDUM4F8fevIRUWbUOtNj0JA4BeyxYOY/OYOxQQdTBepq4RO5H0/WuFsbKHCvODz2nZd2/en851j/+tB87x+Xx3Uc+k6WBkZOFgLX5fvBpjr+LugNN45tnAwCE/K9z1/pNdqKXfd3B4NtbTgQB8V7l9YnaCgGuBYcIH7sJenrKR23dCWNVkfGNIsSyFt6Tiu6rCFpazpZ1y28li/CF/MWsx7rCb7AjTWhdCxiuq442Nn/4cxxYuWW9vAjlwGmk1gyFykZCDC6jb0JUFPLPSfmYbwPmTrg X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(82310400014)(376005)(36860700004);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Mar 2024 13:56:22.5217 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 9323798b-54aa-45ba-74f5-08dc3eae5f74 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SJ5PEPF000001C8.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB8880 Below error can be seen when doing Yocto build of the toolstack: | io.c: In function 'p9_error': | io.c:684:5: error: ignoring return value of 'strerror_r' declared with attribute 'warn_unused_result' [-Werror=unused-result] | 684 | strerror_r(err, ring->buffer, ring->ring_size); | | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | cc1: all warnings being treated as errors Using strerror_r() without special casing different build environments is impossible due to the different return types (int vs char *) depending on the environment. As p9_error() is not on a performance critical path, using strerror() with a mutex ought to be fine. So, fix the build by using strerror() to replace strerror_r(). The steps would then become: Acquire the mutex first, invoke strerror(), copy the string from strerror() to the designated buffer and then drop the mutex. Fixes: f4900d6d69b5 ("9pfsd: allow building with old glibc") Signed-off-by: Henry Wang Reviewed-by: Jan Beulich --- v3: - Add in-code comment and commit msg to explain why use strerror_r(). - Cosmetic and style changes about the logic. - Add Jan's Reviewed-by tag. - Add a "Fixes" tag. - Use a macro-defined value for the maximum error string length. --- tools/9pfsd/io.c | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/tools/9pfsd/io.c b/tools/9pfsd/io.c index adb887c7d9..df1be3df7d 100644 --- a/tools/9pfsd/io.c +++ b/tools/9pfsd/io.c @@ -677,11 +677,28 @@ static bool name_ok(const char *str) return true; } +/* Including the '\0' */ +#define MAX_ERRSTR_LEN 80 static void p9_error(struct ring *ring, uint16_t tag, uint32_t err) { unsigned int erroff; + static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER; + char *str; + size_t len = 0; + + /* + * While strerror_r() exists, it comes in a POSIX and a GNU flavor. + * Let's try to avoid trying to be clever with determining which + * one it is that the underlying C library offers, when really we + * don't expect this function to be called very often. + */ + pthread_mutex_lock(&mutex); + str = strerror(err); + len = min(strlen(str), (size_t)(MAX_ERRSTR_LEN - 1)); + memcpy(ring->buffer, str, len); + ((char *)ring->buffer)[len] = '\0'; + pthread_mutex_unlock(&mutex); - strerror_r(err, ring->buffer, ring->ring_size); erroff = add_string(ring, ring->buffer, strlen(ring->buffer)); fill_buffer(ring, P9_CMD_ERROR, tag, "SU", erroff != ~0 ? ring->str + erroff : "cannot allocate memory", -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Thu Mar 07 14:17:15 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 14:17:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689927.1075422 (Exim 4.92) (envelope-from ) id 1riEYQ-0005PX-B0; Thu, 07 Mar 2024 14:17:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689927.1075422; Thu, 07 Mar 2024 14:17:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riEYQ-0005PQ-8T; Thu, 07 Mar 2024 14:17:02 +0000 Received: by outflank-mailman (input) for mailman id 689927; Thu, 07 Mar 2024 14:17:00 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riEYO-0005PK-4y for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 14:17:00 +0000 Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [2a00:1450:4864:20::534]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 5b9f9ff1-dc8d-11ee-a1ee-f123f15fe8a2; Thu, 07 Mar 2024 15:16:58 +0100 (CET) Received: by mail-ed1-x534.google.com with SMTP id 4fb4d7f45d1cf-56682b85220so1305132a12.1 for ; Thu, 07 Mar 2024 06:16:58 -0800 (PST) Received: from perard.uk.xensource.com (default-46-102-197-194.interdsl.co.uk. [46.102.197.194]) by smtp.gmail.com with ESMTPSA id ch14-20020a170906c2ce00b00a42ea946917sm8253661ejb.130.2024.03.07.06.16.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Mar 2024 06:16:57 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 5b9f9ff1-dc8d-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1709821017; x=1710425817; darn=lists.xenproject.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=xTJKudv5n555xDB36nbOT1Mlzplfm/E/PA4E8+tCLoA=; b=HUKiYKYUe1oDZBV9bQUvM37KJk+2Qgw2XqhPQYkdEBoT6OOwJKGp9B9CVP/MHuy1bD yeapz7+EKYkPAe4qJEYAZTwPVh+3sFuFrCoqWISVsycU00+MgHXg+RvIcPuCmJ0tyui3 5ts7BlOrA62tOHuZufESusmor3qRQTmd6gB4A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709821017; x=1710425817; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=xTJKudv5n555xDB36nbOT1Mlzplfm/E/PA4E8+tCLoA=; b=ZQ9WZ1Ls7HOAFTidHobE/jjG75CI+HUudhaLfGgISh8B6UYEtg1OH9LrqFivr8dOkV y5qSUxTzgIwfYGaIeEpJ8bv8BG36VT9IgM5Ct9XxXfIM7IFymoBbikdeiZueh+yshUzr 8jyat8E3yMlceEQ3y2/1A1eVN/5F1yf+Od10qxZM46tpBgP+FCbnlPUcCVxAQvGz0l3I pjHHhMU+98PlA+VJlYb9R+R7+xAhDxAUHnqDX8DnuRECE2OHO8E07HeOjS/AdtpF9umJ jbdC6hYEwS/ezVW25sVMOpBzAMWk7TREwDnly6si4N4qH1t/N492Sky3qrARZN+eaAtF 0j9Q== X-Gm-Message-State: AOJu0Yy+8ejxAEVDL64o6TVnKbzQ8IBfb3y5Gzq/AnZDSZ0FqEUpJR9x M0V6CdajhdoqumX0d6CgsTyxE+cnvL5TOsjQ/2qqWGBE9VvHfh1vK627UuwGkFI= X-Google-Smtp-Source: AGHT+IFtFUYlb87wle99gwYQ1C6aNcvPqx/m9s9NlmjqX7BWoWZfPstlUD251iq+d/rVqE97q2LaZw== X-Received: by 2002:a17:906:6bda:b0:a45:b1d8:200c with SMTP id t26-20020a1709066bda00b00a45b1d8200cmr4476135ejs.14.1709821017569; Thu, 07 Mar 2024 06:16:57 -0800 (PST) Date: Thu, 7 Mar 2024 14:16:56 +0000 From: Anthony PERARD To: Henry Wang Cc: xen-devel@lists.xenproject.org, Wei Liu , Juergen Gross , Jan Beulich Subject: Re: [PATCH v3] tools/9pfsd: Fix build error caused by strerror_r Message-ID: <6c3cfb96-0f39-49ec-84bd-c37e0701563b@perard> References: <20240307135616.3953774-1-xin.wang2@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240307135616.3953774-1-xin.wang2@amd.com> On Thu, Mar 07, 2024 at 09:56:16PM +0800, Henry Wang wrote: > Below error can be seen when doing Yocto build of the toolstack: > > | io.c: In function 'p9_error': > | io.c:684:5: error: ignoring return value of 'strerror_r' declared > with attribute 'warn_unused_result' [-Werror=unused-result] > | 684 | strerror_r(err, ring->buffer, ring->ring_size); > | | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > | cc1: all warnings being treated as errors > > Using strerror_r() without special casing different build environments > is impossible due to the different return types (int vs char *) > depending on the environment. As p9_error() is not on a performance > critical path, using strerror() with a mutex ought to be fine. So, > fix the build by using strerror() to replace strerror_r(). The steps > would then become: Acquire the mutex first, invoke strerror(), copy > the string from strerror() to the designated buffer and then drop the > mutex. > > Fixes: f4900d6d69b5 ("9pfsd: allow building with old glibc") > Signed-off-by: Henry Wang > Reviewed-by: Jan Beulich Acked-by: Anthony PERARD -- Anthony PERARD From xen-devel-bounces@lists.xenproject.org Thu Mar 07 14:23:01 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 14:23:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689930.1075432 (Exim 4.92) (envelope-from ) id 1riEe8-00087S-Vm; Thu, 07 Mar 2024 14:22:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689930.1075432; Thu, 07 Mar 2024 14:22:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riEe8-00087L-S7; Thu, 07 Mar 2024 14:22:56 +0000 Received: by outflank-mailman (input) for mailman id 689930; Thu, 07 Mar 2024 14:22:56 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riEe8-00087F-1s for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 14:22:56 +0000 Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [2a00:1450:4864:20::52f]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 2fbf4021-dc8e-11ee-a1ee-f123f15fe8a2; Thu, 07 Mar 2024 15:22:54 +0100 (CET) Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-567fbbd7658so1018239a12.2 for ; Thu, 07 Mar 2024 06:22:54 -0800 (PST) Received: from ?IPV6:2003:e5:8715:c000:52ff:24ed:f304:23c0? (p200300e58715c00052ff24edf30423c0.dip0.t-ipconnect.de. [2003:e5:8715:c000:52ff:24ed:f304:23c0]) by smtp.gmail.com with ESMTPSA id b20-20020a0564021f1400b00567fa27e75fsm1469233edb.32.2024.03.07.06.22.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Mar 2024 06:22:53 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 2fbf4021-dc8e-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709821373; x=1710426173; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:from:user-agent:mime-version:date:message-id:from:to :cc:subject:date:message-id:reply-to; bh=jT28SHMr5mx2yX++aDezcFhRzuKSnqFFIEiMbPt46Zc=; b=LI7EmJJpeDPQcvv318soto6MV9iHTUu7iYwtPGhc+jZYWySGyiWeo6KSUr+E6+tZxT oZLfNioD1dw6PUROMMFd00d58LTEdputRgFdlWlxlIwvcFNkK4M5HayViqoPoEaILwiu Y4yi4+frOyXrT156cPkzMKGHtsAgbAPocjar6j4Rh++unF5auMKmUc2BcBh0PAGUq0bc uERnleSdWmINhh7U9WPma36Ic1I3GRUZ7zULi2jhZN6aRHOmyOZnhNwSFPZ0rn+6b1zC C3lMytElPkhN78NrUKAG0yNVRvJTGl9TecZshG0tZA5gm1X4YpceRgRqqp/rDNdqJ0e7 NPBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709821373; x=1710426173; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:from:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=jT28SHMr5mx2yX++aDezcFhRzuKSnqFFIEiMbPt46Zc=; b=KKbBzLwRGsA3V0Kh3+EaG900kHcKJB0aE4jui8aXAq43RChnMqjZ1yhbRCeSSV6dBC 8m1ev+v3hBfJl8XBFA+8LCsElyLb24rLo9Z//ZnoGueT5UdMr7FBiDyBAdkEkzPyCyTo j6zK90AVFs1ajhtYyxYXC486oPzaU9KGDiJedVwQLclCEzPPIIolg11FBnVTL4C9O/KF mYxbhM8IyLGxqwd0NuS5Cbf9VjRYY14CHIkStu/YGXNO4h0ZpwnghkumMjmkZTmz7e6D /3c/0MYL+u4aNEJ14i5sye8zhpFHCk0QD/94jdTThtTpwkWzuZEwIlW/3N2fMPwn5JCg Ybjw== X-Forwarded-Encrypted: i=1; AJvYcCWNvHOBGAULTFvzzXdkoNOtOhDvE2dsqaD75gqGGxQHxCo4HQhEbEiDL5mzlqd4+E326m8HqZaBlHLNHqP1ZkGPpewsKIV3g9fyZt6zVzI= X-Gm-Message-State: AOJu0YymLjMx6Fu620VbEKbZ+aAqn6CJsXAG3JxIVBxdhJzhxIsgfjZK jwMq65vUz0lkOU7PQgzH0sXfbWxFl5J0Ii34TvSrgV8gv0RqPtkV53BpNkFBXdo= X-Google-Smtp-Source: AGHT+IEOIimfJ+6+xWtw0gpdBm8m9URQc3TAdIuUHP72uJAqKMRiI0OJ/ZKhOPcYUGsiqVhfE0QLVw== X-Received: by 2002:a05:6402:2315:b0:565:59a:a103 with SMTP id l21-20020a056402231500b00565059aa103mr13416402eda.33.1709821373594; Thu, 07 Mar 2024 06:22:53 -0800 (PST) Message-ID: <6488c9a2-b071-4ee0-b02d-5a0711bf5129@suse.com> Date: Thu, 7 Mar 2024 15:22:52 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Subject: Re: [PATCH v3] tools/9pfsd: Fix build error caused by strerror_r To: Henry Wang , xen-devel@lists.xenproject.org Cc: Wei Liu , Anthony PERARD , Jan Beulich References: <20240307135616.3953774-1-xin.wang2@amd.com> Content-Language: en-US In-Reply-To: <20240307135616.3953774-1-xin.wang2@amd.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 07.03.24 14:56, Henry Wang wrote: > Below error can be seen when doing Yocto build of the toolstack: > > | io.c: In function 'p9_error': > | io.c:684:5: error: ignoring return value of 'strerror_r' declared > with attribute 'warn_unused_result' [-Werror=unused-result] > | 684 | strerror_r(err, ring->buffer, ring->ring_size); > | | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > | cc1: all warnings being treated as errors > > Using strerror_r() without special casing different build environments > is impossible due to the different return types (int vs char *) > depending on the environment. As p9_error() is not on a performance > critical path, using strerror() with a mutex ought to be fine. So, > fix the build by using strerror() to replace strerror_r(). The steps > would then become: Acquire the mutex first, invoke strerror(), copy > the string from strerror() to the designated buffer and then drop the > mutex. > > Fixes: f4900d6d69b5 ("9pfsd: allow building with old glibc") > Signed-off-by: Henry Wang > Reviewed-by: Jan Beulich Reviewed-by: Juergen Gross Juergen From xen-devel-bounces@lists.xenproject.org Thu Mar 07 15:03:02 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 15:03:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689941.1075463 (Exim 4.92) (envelope-from ) id 1riFGo-0000Gl-6U; Thu, 07 Mar 2024 15:02:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689941.1075463; Thu, 07 Mar 2024 15:02:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riFGo-0000Ge-3f; Thu, 07 Mar 2024 15:02:54 +0000 Received: by outflank-mailman (input) for mailman id 689941; Thu, 07 Mar 2024 15:02:52 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riFGm-0000GY-Do for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 15:02:52 +0000 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id c39e347f-dc93-11ee-afda-a90da7624cb6; Thu, 07 Mar 2024 16:02:49 +0100 (CET) Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 5A91475D2B; Thu, 7 Mar 2024 14:00:36 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 2D8B712FC5; Thu, 7 Mar 2024 14:00:36 +0000 (UTC) Received: from dovecot-director2.suse.de ([10.150.64.162]) by imap1.dmz-prg2.suse.org with ESMTPSA id 7fSACYTI6WU/WwAAD6G6ig (envelope-from ); Thu, 07 Mar 2024 14:00:36 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c39e347f-dc93-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1709820036; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=jT28SHMr5mx2yX++aDezcFhRzuKSnqFFIEiMbPt46Zc=; b=Lr6eISMmHQns097mFfKdA1BlprQ3DNOn4DStXx4GiLehEOs0V7q+Nw/b4F5BJql+kMegPB KgWWGJZ5r2GfryVg+514zGgU03MIssxak58Pe7od1i9sbNuKdS9gvD+d9TW8yKfQa9AKhZ UDD5345W6cyaJ1ySdCWO7wOch9Vswgg= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1709820036; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=jT28SHMr5mx2yX++aDezcFhRzuKSnqFFIEiMbPt46Zc=; b=Lr6eISMmHQns097mFfKdA1BlprQ3DNOn4DStXx4GiLehEOs0V7q+Nw/b4F5BJql+kMegPB KgWWGJZ5r2GfryVg+514zGgU03MIssxak58Pe7od1i9sbNuKdS9gvD+d9TW8yKfQa9AKhZ UDD5345W6cyaJ1ySdCWO7wOch9Vswgg= Message-ID: <9f1bb57f-bcee-4367-9c36-e8571f48d162@suse.com> Date: Thu, 7 Mar 2024 15:00:35 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3] tools/9pfsd: Fix build error caused by strerror_r Content-Language: en-US To: Henry Wang , xen-devel@lists.xenproject.org Cc: Wei Liu , Anthony PERARD , Jan Beulich References: <20240307135616.3953774-1-xin.wang2@amd.com> From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= In-Reply-To: <20240307135616.3953774-1-xin.wang2@amd.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: smtp-out2.suse.de; none X-Spam-Level: X-Spam-Score: -1.09 X-Spamd-Result: default: False [-1.09 / 50.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; XM_UA_NO_VERSION(0.01)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; BAYES_HAM(-0.57)[81.24%]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; NEURAL_HAM_SHORT(-0.20)[-1.000]; DBL_BLOCKED_OPENRESOLVER(0.00)[amd.com:email,suse.com:email]; FUZZY_BLOCKED(0.00)[rspamd.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; R_MIXED_CHARSET(0.77)[subject]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Spam-Flag: NO On 07.03.24 14:56, Henry Wang wrote: > Below error can be seen when doing Yocto build of the toolstack: > > | io.c: In function 'p9_error': > | io.c:684:5: error: ignoring return value of 'strerror_r' declared > with attribute 'warn_unused_result' [-Werror=unused-result] > | 684 | strerror_r(err, ring->buffer, ring->ring_size); > | | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > | cc1: all warnings being treated as errors > > Using strerror_r() without special casing different build environments > is impossible due to the different return types (int vs char *) > depending on the environment. As p9_error() is not on a performance > critical path, using strerror() with a mutex ought to be fine. So, > fix the build by using strerror() to replace strerror_r(). The steps > would then become: Acquire the mutex first, invoke strerror(), copy > the string from strerror() to the designated buffer and then drop the > mutex. > > Fixes: f4900d6d69b5 ("9pfsd: allow building with old glibc") > Signed-off-by: Henry Wang > Reviewed-by: Jan Beulich Reviewed-by: Juergen Gross Juergen From xen-devel-bounces@lists.xenproject.org Thu Mar 07 15:11:30 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 15:11:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689944.1075472 (Exim 4.92) (envelope-from ) id 1riFP4-00025r-0K; Thu, 07 Mar 2024 15:11:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689944.1075472; Thu, 07 Mar 2024 15:11:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riFP3-00025k-Te; Thu, 07 Mar 2024 15:11:25 +0000 Received: by outflank-mailman (input) for mailman id 689944; Thu, 07 Mar 2024 15:11:24 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riFP2-00025e-Jm for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 15:11:24 +0000 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on20600.outbound.protection.outlook.com [2a01:111:f403:2009::600]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id f497e1a0-dc94-11ee-a1ee-f123f15fe8a2; Thu, 07 Mar 2024 16:11:22 +0100 (CET) Received: from BL1PR13CA0352.namprd13.prod.outlook.com (2603:10b6:208:2c6::27) by SN7PR12MB6767.namprd12.prod.outlook.com (2603:10b6:806:269::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.24; Thu, 7 Mar 2024 15:11:17 +0000 Received: from BL6PEPF0001AB51.namprd04.prod.outlook.com (2603:10b6:208:2c6:cafe::9e) by BL1PR13CA0352.outlook.office365.com (2603:10b6:208:2c6::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.9 via Frontend Transport; Thu, 7 Mar 2024 15:11:17 +0000 Received: from SATLEXMB03.amd.com (165.204.84.17) by BL6PEPF0001AB51.mail.protection.outlook.com (10.167.242.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7362.11 via Frontend Transport; Thu, 7 Mar 2024 15:11:17 +0000 Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 7 Mar 2024 09:11:16 -0600 Received: from [172.17.205.23] (10.180.168.240) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35 via Frontend Transport; Thu, 7 Mar 2024 09:11:15 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f497e1a0-dc94-11ee-a1ee-f123f15fe8a2 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ng+1ycah4IcZbdHOPuQ+4lOH71CN4jm2TuN7oaqnV96gQ86kmvZnUGFGsRuCy1BvLN4dhzAZUfi7PIzx77QqFIUOOPGb4B5NwOtNPD37YBL6ns1zsp6l80+XIsSTjkdM0s9HGHyRbW5sJSAyZd7W/d6so9i8S2f5FdVhp0Zxo1W5NpUC0+0TpKEbO3LtSP7UweJIF2ZVxrCyBMcXoikmVUHC/t/3jNYND3z6Zdel/3a0pQZaBbGXtO0E2JEPaajF3UmId4TEsly2cHAq6QSQdY3ISQ0tIPu9rOx0eeZ74gpduezeZ+/WlBahj3z1Q8y7FiGPEyqLO+KLqynwWESFNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=lyz5ZBTCWm9VEOHTTlST/3STwxadr7r9q9oasJWdGoE=; b=Jy84SKO+QLj5qnN1a/53rD06rlRB53UM6hw5Fe6gateMglbz+h4+GPPiDmTkaeB/4QQUSxT6dNE4U3Vv1G+RH9vzWmS4sUhxrVUNXNdEfjZwmJTVz6Uw9XROsWV2TMfQ9tNWQEgMNsUCNL0cpePj7FzP+zBhy4YZK/qsTePjQI3vREm4licIzxaGTNs1HaRo/Na5pWOQudEyFyrSFTv5izZstmTHttFqIt79iqamNZ1FR8l1uhwUZ7USoWe2BBrWkg1FHDcZL6Jg36GaAh8xY0DOJwPLj7COqIIn7g9QmDIfL7J/2X3rmsVxuni+Q7CwfiuQhhwA5TZ0gFSOBGtddQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lyz5ZBTCWm9VEOHTTlST/3STwxadr7r9q9oasJWdGoE=; b=y+s1phGgZX3LYZbB2CKix9Jb4Bm+dj1GXc8d/b03IPYWQKhwj0eQfelmmzwnLWsYTcJXPXJaElphBLiaN0YSOIUGkS1xPhVWiag5b/RJSTamwvQx/AQOz7TDeejIwPReYrrtoeQ7XoDw+mpwjvWVyICBQzxNJN+MpouHagDzMMU= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C Message-ID: <264c495a-de34-458b-b1f2-80fc58829c06@amd.com> Date: Thu, 7 Mar 2024 10:06:54 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/3] xen/x86: bzImage parse kernel_alignment To: Jan Beulich , Stefano Stabellini CC: , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu References: <20240306185032.103216-1-jason.andryuk@amd.com> <20240306185032.103216-3-jason.andryuk@amd.com> <8b02fb20-2e4d-4a68-b633-417c964e38be@suse.com> Content-Language: en-US From: Jason Andryuk In-Reply-To: <8b02fb20-2e4d-4a68-b633-417c964e38be@suse.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: None (SATLEXMB03.amd.com: jason.andryuk@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BL6PEPF0001AB51:EE_|SN7PR12MB6767:EE_ X-MS-Office365-Filtering-Correlation-Id: 4445ac16-815e-4fad-1ee7-08dc3eb8d6d1 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: z1KgQMhL/TGeUgFQrlON4obJrRhYz8P3lVwh9qoqEKXEjJwISMe4EoBYstqcuXU3dJn0FAdZ+BQOw//GbyMYiql9NNhsxAO7C+xpqihzC56mIrO10TTF2iuAVURMBKh7wHXIosOANhqgGGi7H3v9OTcN5nd54VUckPnlyY3mkFjdhmbn8Wzh3OJQiEd0y1/oc5CgbWUlRJvkLgYVRXxJhH6uqtjL3sHLRXCQ1xWMUiESVWgXXTxJPGbX3yvntbZDlIQY1xy3QCooggC8EnRKfI+0yjYGsfcSWgLV3rHQGaxXUYEGlPByYRLAOtF/CrdVhL7DXY1WX4Am7+d+205f2cTDSyzwyeMWy9PE9oMkO3K3u1bhTtKMMQ71kwVJ6f9sezEEwTdLo3qctSBIN3Z/Blz3R9zaKvhQeZp2ObsiacVimsDrJ8+iDGKl0RG//w6fw112IEWypmBTV5FymYaFPdTWsnZa5d+zgB0OWZ2JZgJThM9x8ciIWnogNK8jRkj+AxaVBaxLPDGWvxK/XlyKD/8GAO/150PCKjlp+Mn1zz7XXnH2TcHJssqbKM9uQnicBm5bifkwgQaMBl6uj3fnY48KKMaOBzxHE8AHqWrR4OiFcWMXoXk9xYx7alByIkbAJoN707SwNvRr/+88PXuw0D+UgPVc2FC0f4dFRZcPYEOaPxr+K7PgqaicW7IWPopxeTLjHtKof8cf9VRsqjf9ztuk7AHgWwbAEK0BZmhPss6Vgn59JL8VX0luNga2J/rw X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(82310400014)(376005)(36860700004);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Mar 2024 15:11:17.8232 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 4445ac16-815e-4fad-1ee7-08dc3eb8d6d1 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BL6PEPF0001AB51.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB6767 On 2024-03-07 03:26, Jan Beulich wrote: > On 07.03.2024 03:09, Stefano Stabellini wrote: >> On Wed, 6 Mar 2024, Jason Andryuk wrote: >>> Expand bzimage_parse() to return kernel_alignment from the setup_header. >>> This will be needed if loading a PVH kernel at a physical offset to >>> compensate for a reserved E820 region. >>> >>> Signed-off-by: Jason Andryuk >> >> Reviewed-by: Stefano Stabellini > > Acked-by: Jan Beulich > with two remarks: > >>> --- a/xen/arch/x86/hvm/dom0_build.c >>> +++ b/xen/arch/x86/hvm/dom0_build.c >>> @@ -548,12 +548,14 @@ static int __init pvh_load_kernel(struct domain *d, const module_t *image, >>> struct elf_binary elf; >>> struct elf_dom_parms parms; >>> paddr_t last_addr; >>> + unsigned int align = 0; > > Strictly speaking this isn't needed here, yet, and would suffice when added > in the next patch. But I'm okay with keeping it. > >>> --- a/xen/arch/x86/include/asm/bzimage.h >>> +++ b/xen/arch/x86/include/asm/bzimage.h >>> @@ -4,8 +4,7 @@ >>> #include >>> >>> unsigned long bzimage_headroom(void *image_start, unsigned long image_length); >>> - >>> int bzimage_parse(void *image_base, void **image_start, >>> - unsigned long *image_len); >>> + unsigned long *image_len, unsigned int *align); > > Any particular reason for dropping the blank line? I'd prefer if it was kept, > and I may take the liberty to respectively adjust the patch while committing. No, no particular reason. The blank line can be retained. Thanks, Jason From xen-devel-bounces@lists.xenproject.org Thu Mar 07 15:33:09 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 15:33:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689947.1075483 (Exim 4.92) (envelope-from ) id 1riFjr-0006zt-Mj; Thu, 07 Mar 2024 15:32:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689947.1075483; Thu, 07 Mar 2024 15:32:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riFjr-0006zm-JT; Thu, 07 Mar 2024 15:32:55 +0000 Received: by outflank-mailman (input) for mailman id 689947; Thu, 07 Mar 2024 15:32:54 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riFjq-0006ze-8t for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 15:32:54 +0000 Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [2a00:1450:4864:20::52f]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id f5ca9b5a-dc97-11ee-a1ee-f123f15fe8a2; Thu, 07 Mar 2024 16:32:51 +0100 (CET) Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-564fd9eea75so1471398a12.3 for ; Thu, 07 Mar 2024 07:32:51 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id i23-20020a0564020f1700b00567f780d4a2sm1614385eda.78.2024.03.07.07.32.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Mar 2024 07:32:50 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f5ca9b5a-dc97-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709825571; x=1710430371; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=ICTD9W1jZNKmaeymhp1OA1AH+0jy22X0d9edds9WeIo=; b=YAFTiY+6ZxRoKL8UbrRkYrn5zghfBJwselnnsQHeeQIU9pfOEPuShHzBrl/x1SXolR 266ruF2f1oBuipouly3mbhROmDXJKWALoiqAEKPimaESzFXj3dS5Cza7PCLwBSx1OyrJ qQSbj6M5Vy4D12HdfkKAxB/oWl/TgVnL56FpZ2JqaA3wBqTqVE5n4Li+DHRVzGpLV1B4 1wnOiz8dmxh/j24GaUj9sLFBEodJciG7OCh9tdnXZ14xP++lv8GIlhtrDppnHtgnQsd1 NkXXXdlbQRnzEloo9m+AFNgB/vG0hI2rHe9Alg6w6jC5k7oNJvehTOvTZiy04MTzJQ8Y 75dQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709825571; x=1710430371; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ICTD9W1jZNKmaeymhp1OA1AH+0jy22X0d9edds9WeIo=; b=fyMWm7CF4T0VR6aaBdiOKjw1hGG4H35eIl2hsREMV1eYWDbmnpwj2y4Nwc7w6AEfMJ OmvA/efSsa34zVYQRywkeXALrsb02tmXoIIgnEDxReSEOGotN8/8s8f6ED9QN741RbIl OcsBDR+k6LlCL8ZX4Wwhnu/5CraMHd2XUmDgEbC9EJ5NDHk4z9gpt9O05PpTAKU2m/TB hWWl0qNBpxyyIJvbNIs7IiogJoZq+U4jUFoIVaFSahWQ517R7JikPhjFNC1zUAwPxemA DtKag8kRm2eMYd5NTBd92okSvD/Sf7KPg7t8FqvYA7NK+9h/JQqbLSOlPJJYJadUEFQV UiQA== X-Forwarded-Encrypted: i=1; AJvYcCWTxSzujSvkJHapEh2f82+X+LQlIGGa0gga6ZzJfWRWTJePI5d2PWh/DxU3i5pJbLe578kGKB81ARL0I9zODx/MRGu9hZ+eEM+56n8T8nY= X-Gm-Message-State: AOJu0Yxazl9/hlRgLiWLtiGcfBay1KE/WdaMqA2ynLNnA65hhajBVxkJ 6IovSFII9V9KripyD0heY4sbK8EvoPkybsg4LO0OyxKzQq4O7h8N2sjXcVBpug== X-Google-Smtp-Source: AGHT+IE4a6ySWnbqC1+6etZSY5njGHdzxOmDXQc+iri7lQX9wLSodv5Uy94bi6zTeOu3jeIxS20h8w== X-Received: by 2002:a50:c354:0:b0:567:672f:6076 with SMTP id q20-20020a50c354000000b00567672f6076mr108987edb.14.1709825571223; Thu, 07 Mar 2024 07:32:51 -0800 (PST) Message-ID: <2a05c233-b3c5-417c-bd6b-8b1c21f03c3d@suse.com> Date: Thu, 7 Mar 2024 16:32:49 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 12/23] xen/riscv: introduce io.h Content-Language: en-US To: Oleksii Cc: Alistair Francis , Bob Eshleman , Connor Davis , Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu , xen-devel@lists.xenproject.org References: <807c31d5-0c5a-4646-ba90-2f284289069f@suse.com> <2a3e49bf94332c17b50e4f0f745e4b28b16dceb1.camel@gmail.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <2a3e49bf94332c17b50e4f0f745e4b28b16dceb1.camel@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 07.03.2024 14:44, Oleksii wrote: > On Thu, 2024-03-07 at 14:24 +0100, Jan Beulich wrote: >> On 07.03.2024 14:01, Oleksii wrote: >>> On Wed, 2024-03-06 at 15:13 +0100, Jan Beulich wrote: >>>>> +/* Generic IO read/write.  These perform native-endian >>>>> accesses. >>>>> */ >>>>> +static inline void __raw_writeb(uint8_t val, volatile void >>>>> __iomem >>>>> *addr) >>>>> +{ >>>>> +    asm volatile ( "sb %0, 0(%1)" : : "r" (val), "r" (addr) ); >>>>> +} >>>> >>>> I realize this is like Linux has it, but how is the compiler to >>>> know >>>> that >>>> *addr is being access here?  >>> Assembler syntax told compiler that. 0(%1) - means that the memory >>> location pointed to by the address in register %1. >> >> No, the compiler doesn't decompose the string to figure how operands >> are used. That's what the constraints are for. The only two things >> the >> compiler does with the string is replace % operators and count line >> separators. > It looks like I am missing something. > > addr -> a some register ( because of "r" contraint ). > val -> is also register ( because of "r" contraint ). > > So the compiler will update instert an instruction: > sb reg1, 0(reg2) > > what means *(uint_8 *)reg2 = (uint8_t)reg1. > > What am I missing? The fact that the compiler will not know that *(uint_8 *)reg2 actually changes across this asm(). It may therefore continue to hold a cached value in a register, without knowing that its contents went stale. Jan From xen-devel-bounces@lists.xenproject.org Thu Mar 07 15:40:17 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 15:40:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689949.1075493 (Exim 4.92) (envelope-from ) id 1riFqv-0000WM-8v; Thu, 07 Mar 2024 15:40:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689949.1075493; Thu, 07 Mar 2024 15:40:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riFqv-0000WF-5t; Thu, 07 Mar 2024 15:40:13 +0000 Received: by outflank-mailman (input) for mailman id 689949; Thu, 07 Mar 2024 15:40:11 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riFqt-0000Uk-Bx for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 15:40:11 +0000 Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [2a00:1450:4864:20::633]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id fab7a26a-dc98-11ee-a1ee-f123f15fe8a2; Thu, 07 Mar 2024 16:40:09 +0100 (CET) Received: by mail-ej1-x633.google.com with SMTP id a640c23a62f3a-a3ddc13bbb3so393985266b.0 for ; Thu, 07 Mar 2024 07:40:09 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id x23-20020a170906135700b00a3e4c47bad1sm8339268ejb.8.2024.03.07.07.40.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Mar 2024 07:40:08 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fab7a26a-dc98-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709826009; x=1710430809; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=B+ZRYqFkGQ8TOETEYoUTH6C8N+BrzyX5yY0YORN6HLQ=; b=MPGkRW7+gRQGkkhgNRgBTtTrvPEbtvxfLCQDXtYE4BPi0f2ksNyTLl89qdBEWOlfXH OVvZp64nsEK+rCLv2ItnhckesoSq1lVlFngGPVqVCQZrZtbTIcS7o8tD+J46XgqScYsH i3iIL0Lp1Ge62mHrx3T92afA6xN0TCw7Bj0U3ANJolMO9ibml0HRlUjEW//jactHiEAF Odu21/+86hUcRw4G1L6mOrQojtdIppNMS5scO3Z2VqarZ5vfc9N3qqkK2gCPphP8HfXp 7dZ87FyWLAIedrpZ1kVMACaXbWIeRujNixIBaZZ7mdz57rFh43qJW1gxNTGEWuEEZ1xn Iyrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709826009; x=1710430809; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=B+ZRYqFkGQ8TOETEYoUTH6C8N+BrzyX5yY0YORN6HLQ=; b=tuGjvoPSfyQEFgOCYKDEohef4EPKGwf4xKm9y8r5Lvk7rB9tE86op4qX1ru3BTE0Oi 9k9KRML1vmka2PQRtfgtkV0ACYqchktSOiajVlrNOEFI9Hil7Re7sktqtH23dHEx/ohg 93VuOxOXmxoRc56m8c08gVJ3w0fRmL/VWAyQeRXXEBvG8QUeKlvOBUxlRF48n5LVztP0 GU1Rba6VMYEyqi4jy+tczVfC5lUgBmDiCV0T1YtfXC1kRDHjU121Gf78yjST8kVlL43K IhZNgCv4rmnqlrw+bLj6FEKMIdOH1Aj9bLGIL8QsHr5i6pMxPnxq/DR5VO+CZyxQc+0E +GkQ== X-Forwarded-Encrypted: i=1; AJvYcCVPSPkZyMZFZAjiiKasN8Q888XnNQ6vt4mCaCy9dAwQa3CVvPaGbi/PfCglsGS9QUBizSse68SXyeLnIGdo2DP6pIq4sH6DXTJ3N1BoayM= X-Gm-Message-State: AOJu0Yyex3Qp1c5tkVf4fdosRosFLCL6WkSlPprQ9iWi8KcBktdejjpH nZcKmfj+efJtdnZmbYp0JZTDQYVhz3mOHSf8Wu7lnx4e3LZsnOhKrChjXEIejA== X-Google-Smtp-Source: AGHT+IEblmYc7Rd5KdWLc+n/63cHvUNmdGWrnvS4I4eFSLy+ErrR0dCQ/ttDKk2Iro5btdh/OzeTFQ== X-Received: by 2002:a17:906:3bda:b0:a45:2cf3:6c65 with SMTP id v26-20020a1709063bda00b00a452cf36c65mr475340ejf.25.1709826009009; Thu, 07 Mar 2024 07:40:09 -0800 (PST) Message-ID: Date: Thu, 7 Mar 2024 16:40:07 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 13/23] xen/riscv: introduce atomic.h Content-Language: en-US To: Oleksii Cc: Alistair Francis , Bob Eshleman , Connor Davis , Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu , xen-devel@lists.xenproject.org References: <85ad8c86901d045beed228947d4c3faf277af3ca.1708962629.git.oleksii.kurochko@gmail.com> <3d9b0fa3-d100-4e73-b5d5-782ef58e331a@suse.com> <7ae660e5da986503a1353f07ecf298bd9814afe1.camel@gmail.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <7ae660e5da986503a1353f07ecf298bd9814afe1.camel@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 07.03.2024 14:30, Oleksii wrote: > On Wed, 2024-03-06 at 16:31 +0100, Jan Beulich wrote: >> On 26.02.2024 18:38, Oleksii Kurochko wrote: >>> --- /dev/null >>> +++ b/xen/arch/riscv/include/asm/atomic.h >>> @@ -0,0 +1,296 @@ >>> +/* SPDX-License-Identifier: GPL-2.0-only */ >>> +/* >>> + * Taken and modified from Linux. >>> + * >>> + * The following changes were done: >>> + * - * atomic##prefix##_*xchg_*(atomic##prefix##_t *v, c_t n) were >>> updated >>> + *     to use__*xchg_generic() >>> + * - drop casts in write_atomic() as they are unnecessary >>> + * - drop introduction of WRITE_ONCE() and READ_ONCE(). >>> + *   Xen provides ACCESS_ONCE() >>> + * - remove zero-length array access in read_atomic() >>> + * - drop defines similar to pattern >>> + *   #define atomic_add_return_relaxed   atomic_add_return_relaxed >>> + * - move not RISC-V specific functions to asm-generic/atomics- >>> ops.h >>> + * >>> + * Copyright (C) 2007 Red Hat, Inc. All Rights Reserved. >>> + * Copyright (C) 2012 Regents of the University of California >>> + * Copyright (C) 2017 SiFive >>> + * Copyright (C) 2024 Vates SAS >>> + */ >>> + >>> +#ifndef _ASM_RISCV_ATOMIC_H >>> +#define _ASM_RISCV_ATOMIC_H >>> + >>> +#include >>> + >>> +#include >>> +#include >>> +#include >>> +#include >>> + >>> +#include >> >> While, because of the forward decls in xen/atomic.h, having this >> #include >> works, I wonder if it wouldn't better be placed further down. The >> compiler >> will likely have an easier time when it sees the inline definitions >> ahead >> of any uses. > Do you mean to move it after #define __atomic_release_fence() ? Perhaps yet further down, at least after the arithmetic ops were defined. >>> --- /dev/null >>> +++ b/xen/include/asm-generic/atomic-ops.h >>> @@ -0,0 +1,92 @@ >>> +#/* SPDX-License-Identifier: GPL-2.0 */ >>> +#ifndef _ASM_GENERIC_ATOMIC_OPS_H_ >>> +#define _ASM_GENERIC_ATOMIC_OPS_H_ >>> + >>> +#include >>> +#include >> >> If I'm not mistaken this header provides default implementations for >> every >> xen/atomic.h-provided forward inline declaration that can be >> synthesized >> from other atomic functions. I think a comment to this effect would >> want >> adding somewhere here. > I think we can drop this inclusion here as inclusion of asm- > generic/atomic-ops.h will be always go with inclusion of xen/atomic.h. I'm okay with dropping that include, but that wasn't the purpose of my comment. I was rather asking for a comment to be added here stating what is (not) to be present in this header. Jan From xen-devel-bounces@lists.xenproject.org Thu Mar 07 16:12:34 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 16:12:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689956.1075502 (Exim 4.92) (envelope-from ) id 1riGM7-0006xm-Cn; Thu, 07 Mar 2024 16:12:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689956.1075502; Thu, 07 Mar 2024 16:12:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riGM7-0006xf-AD; Thu, 07 Mar 2024 16:12:27 +0000 Received: by outflank-mailman (input) for mailman id 689956; Thu, 07 Mar 2024 16:12:26 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riGM6-0006xX-5m for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 16:12:26 +0000 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on20601.outbound.protection.outlook.com [2a01:111:f403:2412::601]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 79f182f0-dc9d-11ee-a1ee-f123f15fe8a2; Thu, 07 Mar 2024 17:12:22 +0100 (CET) Received: from CY5PR19CA0088.namprd19.prod.outlook.com (2603:10b6:930:83::7) by MN0PR12MB5713.namprd12.prod.outlook.com (2603:10b6:208:370::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.26; Thu, 7 Mar 2024 16:12:17 +0000 Received: from CY4PEPF0000E9CF.namprd03.prod.outlook.com (2603:10b6:930:83:cafe::64) by CY5PR19CA0088.outlook.office365.com (2603:10b6:930:83::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.26 via Frontend Transport; Thu, 7 Mar 2024 16:12:14 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by CY4PEPF0000E9CF.mail.protection.outlook.com (10.167.241.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7362.11 via Frontend Transport; Thu, 7 Mar 2024 16:12:14 +0000 Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 7 Mar 2024 10:12:13 -0600 Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB05.amd.com (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 7 Mar 2024 10:12:13 -0600 Received: from [172.17.205.23] (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35 via Frontend Transport; Thu, 7 Mar 2024 10:12:10 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 79f182f0-dc9d-11ee-a1ee-f123f15fe8a2 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ASCg67Cn/6H8V3IvUD4rsYP1H87Z1z4VUq6D+VJc5NttscSAQLCZSerFugoz2pS9wBWqBuNjdaRSoPcXZHgiu//MINIIAl4MfkHHfmrzt75WkcgTaD0WjOVYyDrWEFE3k/uSqGcpcbaSafjUS7LTnkWsssqnP1wIDh/ZbTQLMNJ/uGEJUlmkdVQhq2Q/2I5vAiXFVzA/3HqxLleTwIB9PK6somyMO8R2+f2snymd8DyrbYiWBI0rlWKkuMLgJopuVw83LLaqXpUs4RN1e5X6U1R8ZdCVkV0ad0gtRUcag6uPqRwaXX7WdbdzdaXbRthliiCO+PB2baipHRdA3JfsIA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=IZfJHW4+qhmx6Ya7GyNzxiynp2FfaAyMQKvtIGqcTsY=; b=g7dRg2Lc+wojhi4bfCHZJ/OdF+RQCOdpN5BCX3HbDVZ/gVQRiJx9DvfpB4PmSkpyWIDuE46CnIlcFh5ks5EFMRTY/mf5G42r54UtBgTjXoFCmUwv5gHp7OW6i8/6lTeZiQs1BE5toi+aV8KgFB1Mr163SjdBCZtYzN2GPrCOQMK/l0CoRjcAaC2kblytMkhmkE2hgGnEkgAU3JK4Ioehy0iIcus5j3JbvbhtDo5Ws2Kxq0DCPjw2B5SguSrJ/w5NDZyrpGIOw3LXv2nB83sfQ+QM0twKiSe6UvDuOF3UA2OIdY5ZbbMiEGDOHkrRe/nlWZh/6KcJZtsUkEbYcIprTQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=kernel.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IZfJHW4+qhmx6Ya7GyNzxiynp2FfaAyMQKvtIGqcTsY=; b=hbw2lLuUdR+Zgdsj+kJbz80mz54Lg+gE7HXdDgi+bFUA1uklAtCHCleXHC6WS83zeFGE7d8JIeXCUPl5018TuodSaRIdEhzo+jLnXEGajX2h0PD/VsvtmRJv+c5iiXM094VVKhI3/HX1sqfCfXlcmCzpatQeFp6GLPdciyX5ZKY= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C Message-ID: Date: Thu, 7 Mar 2024 11:07:52 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 3/3] x86/PVH: Support relocatable dom0 kernels Content-Language: en-US To: Stefano Stabellini CC: , Jan Beulich , "Andrew Cooper" , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu , George Dunlap , Julien Grall References: <20240306185032.103216-1-jason.andryuk@amd.com> <20240306185032.103216-4-jason.andryuk@amd.com> From: Jason Andryuk In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: None (SATLEXMB05.amd.com: jason.andryuk@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CY4PEPF0000E9CF:EE_|MN0PR12MB5713:EE_ X-MS-Office365-Filtering-Correlation-Id: d9d6265e-1411-436d-c4ed-08dc3ec15a22 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: NMon65UOXmGAlFtoAk2r1kpgr1OyIZwpV1C7O4VpgBFtWyNjh13sm85VtwEZRYMj9qxHTJGcWVW0CGTbl+Yyv0FZNmlVaBinUqZ79WjbaSLzHKqA4dbKxVqL1k5FpJhn84z3OjfUIAznh/Fl3vLaKazQCdkLVJ234+J5//smviOhIcpg0iEohUj5hfPRn4T1XwS4COjSYAUi8JU+Wx35TOg6Ndj3V7JtPy5Hem9TnmtcN/F91FBtHfvSW1juC2RoyBO0JQ9/WNpHqH2HSgH7B0RdyjAM05HFHERvrmoX+MNFTbmYsPK9gtX8cmzRdgWqLK2Ql6LH56FkrIzfiZpTAuFDc0/9SHrzkFXjmPss4WjPE2Ja/hJJ81dZhkaRksSulTb2OS6iYlMaOv7IwNP6Dowxz8aPB/9IopFxN6P9SCdr13weOhAHwrbK2oJFVqMeB3K3x9dzOvZ2AbwBy0ys288dY8VlMV07UJYfG+EpZwQNVrnuo+RKLRgWTKYw8viOULZ8qJbog7TzAVFWn+FWORiB13hb0YW4RSfsCSFkNfqsIpqEuvPkNswaOd9NrDwr5w1Y6Xq1PeXyY/SyYLSXIjTeBOwDKtCbZaEv0nv5Y+ypM10oz/hy5SnyGVEoYwO9Suy8qvl9Ur+YnXme4srzExxebavG7Ql/NDQJ4KddQyNaomozNEyeD3o0+riKex/Do/N/TQLOG0Iz+4trZvgcB1rdijHW9vxLV4vmbNXtjgeU2R+06fwQhyvjBYOBz0++ X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(376005)(36860700004)(82310400014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Mar 2024 16:12:14.0512 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d9d6265e-1411-436d-c4ed-08dc3ec15a22 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CY4PEPF0000E9CF.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB5713 On 2024-03-06 21:09, Stefano Stabellini wrote: > On Wed, 6 Mar 2024, Jason Andryuk wrote: >> Xen tries to load a PVH dom0 kernel at the fixed guest physical address >> from the elf headers. For Linux, this defaults to 0x1000000 (16MB), but >> it can be configured. >> >> Unfortunately there exist firmwares that have reserved regions at this >> address, so Xen fails to load the dom0 kernel since it's not RAM. >> >> The PVH entry code is not relocatable - it loads from absolute >> addresses, which fail when the kernel is loaded at a different address. >> With a suitably modified kernel, a reloctable entry point is possible. >> >> Add the XENFEAT_pvh_relocatable flag to let a kernel indicate that it >> supports a relocatable entry path. >> >> Change the loading to check for an acceptable load address. If the >> kernel is relocatable, support finding an alternate load address. >> >> Linux cares about its physical alignment. This can be pulled out of the >> bzImage header, but not from the vmlinux ELF file. If an alignment >> can't be found, use 2MB. >> >> Signed-off-by: Jason Andryuk >> --- >> Put alignment as a new ELF note? Presence of that note would indicate >> relocation support without a new XENFEAT flag. >> >> Default alignment to a multiple of 2MB to make more cases work? It has >> to be a power of two, and a multiple might allow loading a customized >> kernel. A larger alignment would limit the number of possible load >> locations. >> --- >> xen/arch/x86/hvm/dom0_build.c | 109 ++++++++++++++++++++++++++++++++++ >> xen/include/public/features.h | 5 ++ >> 2 files changed, 114 insertions(+) >> >> diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c >> index bbae8a5645..34d68ee8fb 100644 >> --- a/xen/arch/x86/hvm/dom0_build.c >> +++ b/xen/arch/x86/hvm/dom0_build.c >> @@ -537,6 +537,109 @@ static paddr_t __init find_memory( >> return INVALID_PADDR; >> } >> >> +static bool __init check_load_address( >> + const struct domain *d, const struct elf_binary *elf) >> +{ >> + paddr_t kernel_start = (paddr_t)elf->dest_base & PAGE_MASK; >> + paddr_t kernel_end = ROUNDUP((paddr_t)elf->dest_base + elf->dest_size, >> + PAGE_SIZE); >> + unsigned int i; >> + >> + /* >> + * The memory map is sorted and all RAM regions starts and sizes are >> + * aligned to page boundaries. >> + */ >> + for ( i = 0; i < d->arch.nr_e820; i++ ) >> + { >> + paddr_t start = d->arch.e820[i].addr; >> + paddr_t end = d->arch.e820[i].addr + d->arch.e820[i].size; >> + >> + if ( start <= kernel_start && >> + end >= kernel_end && >> + d->arch.e820[i].type == E820_RAM ) >> + return true; >> + } >> + >> + return false; >> +} >> + >> +/* >> + * Find an e820 RAM region that fits the kernel at a suitable alignment. >> + */ >> +static paddr_t find_kernel_memory( >> + const struct domain *d, struct elf_binary *elf, paddr_t align) >> +{ >> + paddr_t kernel_start = (paddr_t)elf->dest_base & PAGE_MASK; >> + paddr_t kernel_end = ROUNDUP((paddr_t)elf->dest_base + elf->dest_size, >> + PAGE_SIZE); >> + unsigned int i; >> + >> + /* >> + * The memory map is sorted and all RAM regions starts and sizes are >> + * aligned to page boundaries. >> + */ >> + for ( i = 0; i < d->arch.nr_e820; i++ ) >> + { >> + paddr_t start = d->arch.e820[i].addr; >> + paddr_t end = d->arch.e820[i].addr + d->arch.e820[i].size; >> + paddr_t kstart, kend, offset; >> + >> + if ( d->arch.e820[i].type != E820_RAM ) >> + continue; >> + >> + if ( d->arch.e820[i].size < elf->dest_size ) >> + continue; >> + >> + if ( end < kernel_end ) >> + continue; > > Why this check? Is it to make sure we look for e820 regions that are > higher in terms of addresses? If so, couldn't we start from > d->arch.nr_e820 and go down instead of starting from 0 and going up? Yes, I thought we only wanted a higher address. The Linux bzImage entry code uses the LOAD_PHYSICAL_ADDR (CONFIG_PHYSICAL_START/elf->dest_base) as a minimum when extracting vmlinux for a relocatable kernel. I'm not sure if that is strictly required though. I also thought a smaller adjustment would be better, so starting from the lower e820 entries would find the first acceptable one. But that may not matter. > The PVH entry point is a 32-bit entry point if I remember right? Do we > need a 32-bit check? If so then it might not be a good idea to start > from arch.nr_e820 and go down. Yes, the entry point is 32-bit, so you are correct that that the range should to be limited at 4GB. Regards, Jason From xen-devel-bounces@lists.xenproject.org Thu Mar 07 16:21:57 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 16:21:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689960.1075513 (Exim 4.92) (envelope-from ) id 1riGVF-0000md-89; Thu, 07 Mar 2024 16:21:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689960.1075513; Thu, 07 Mar 2024 16:21:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riGVF-0000mW-56; Thu, 07 Mar 2024 16:21:53 +0000 Received: by outflank-mailman (input) for mailman id 689960; Thu, 07 Mar 2024 16:21:52 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riGVE-0000mQ-8S for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 16:21:52 +0000 Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [2a00:1450:4864:20::62a]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id cd642e44-dc9e-11ee-a1ee-f123f15fe8a2; Thu, 07 Mar 2024 17:21:50 +0100 (CET) Received: by mail-ej1-x62a.google.com with SMTP id a640c23a62f3a-a3f893ad5f4so156207166b.2 for ; Thu, 07 Mar 2024 08:21:50 -0800 (PST) Received: from [192.168.206.239] ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id g6-20020a1709061c8600b00a458680f004sm3731236ejh.125.2024.03.07.08.21.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Mar 2024 08:21:49 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: cd642e44-dc9e-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709828510; x=1710433310; darn=lists.xenproject.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=5r0TFK5eLLZbZ1q8qH9KlUkTT3jPePM5yfZWEG26zaU=; b=Oczn22wiF24aMgUwiNTP3wxWhN0P9PvQyzSSXTYpPJc3uwTrJTm39zEqYJeacqGnBd hJDSzpRgdho4dDraSUiSSS+UVyqjOSuV2+xrvGGLo2FJkKdUVt/JxLaQ9BPm7TeQ7TSe oWVYTm8KvHbFa7D5j01Apkjj8PhCSnEhImiOqU5Nq6KpJpTwUhm280ZcjDfZ/yTZXIm4 OgmucZFxv8rNJVgXi/6LQW7QIXOW+UJtCcY9zu3qy6UlpSakjk/SzKPlliUVTyiTWPNH aVK9x7/BWvqwsySUMh0hqPxbULWE4R5bm2Se/jI6PfLgdKuOgXrKDCog1VAGb9IJhofr VTxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709828510; x=1710433310; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=5r0TFK5eLLZbZ1q8qH9KlUkTT3jPePM5yfZWEG26zaU=; b=qIEfuRD4l4mO8ADY0Q1XdJNdeW2P/ShIMAYq/7/wUvJZQ0JDKhsR0nwRB6g1I8k2z6 vc9lvdW4Ip3kMEiC48LQp8QfpsKvnqoC833xnJx2APv3pUjhM8EYRugLD0ZXRXuieb93 gqDzrJ9j2abkPzPWn4uNh+igmkR8XJe5KphtNozkLsRsxPlo8ZjJo3d5pKOKgkEae/Fw LiWvva2h5Y0kwyvDQoXSSTE3FZfVVLEqm/HQwdjqFvjbTUJ/lBJy9X31W9P5Q+YohwbW IUHScPXlK6t5XzpU80n9wl+/n5iX1yXretKGwfCT6muoV1pxP2A3eKnnVN+hzkvbc+hC 16uw== X-Forwarded-Encrypted: i=1; AJvYcCW/wF7GbEt/MxaSGzgcmiJpIz2LPMPeN7h6cT68w5dfAIMobtKCFBWZWV+QlX8KWs5d7wp/B3VC33fzSMc0facS66+1B9CnVk0MyDgbWsw= X-Gm-Message-State: AOJu0YxJrLjk2vXX0QD1Egj0kKRjwL9auO8Ze+D5zSSFi1ePVv6HDT5N Z7KnbfXIEHVphO0/rawG9LRWjfFjvBx4238QyZHvNc01HD7+O/Ln X-Google-Smtp-Source: AGHT+IH8vH/0ALBHbwvHWf02rrrVPOOBo0EiUFxMPjebCYUSmInsrG/dJtlQXA6p98gXszuZimRiuQ== X-Received: by 2002:a17:906:1185:b0:a3e:da6:85f8 with SMTP id n5-20020a170906118500b00a3e0da685f8mr11522258eja.30.1709828509566; Thu, 07 Mar 2024 08:21:49 -0800 (PST) Message-ID: Subject: Re: [PATCH v5 12/23] xen/riscv: introduce io.h From: Oleksii To: Jan Beulich Cc: Alistair Francis , Bob Eshleman , Connor Davis , Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu , xen-devel@lists.xenproject.org Date: Thu, 07 Mar 2024 17:21:48 +0100 In-Reply-To: <2a05c233-b3c5-417c-bd6b-8b1c21f03c3d@suse.com> References: <807c31d5-0c5a-4646-ba90-2f284289069f@suse.com> <2a3e49bf94332c17b50e4f0f745e4b28b16dceb1.camel@gmail.com> <2a05c233-b3c5-417c-bd6b-8b1c21f03c3d@suse.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.50.2 (3.50.2-1.fc39) MIME-Version: 1.0 On Thu, 2024-03-07 at 16:32 +0100, Jan Beulich wrote: > On 07.03.2024 14:44, Oleksii wrote: > > On Thu, 2024-03-07 at 14:24 +0100, Jan Beulich wrote: > > > On 07.03.2024 14:01, Oleksii wrote: > > > > On Wed, 2024-03-06 at 15:13 +0100, Jan Beulich wrote: > > > > > > +/* Generic IO read/write.=C2=A0 These perform native-endian > > > > > > accesses. > > > > > > */ > > > > > > +static inline void __raw_writeb(uint8_t val, volatile void > > > > > > __iomem > > > > > > *addr) > > > > > > +{ > > > > > > +=C2=A0=C2=A0=C2=A0 asm volatile ( "sb %0, 0(%1)" : : "r" (val)= , "r" > > > > > > (addr) ); > > > > > > +} > > > > >=20 > > > > > I realize this is like Linux has it, but how is the compiler > > > > > to > > > > > know > > > > > that > > > > > *addr is being access here?=C2=A0 > > > > Assembler syntax told compiler that. 0(%1) - means that the > > > > memory > > > > location pointed to by the address in register %1. > > >=20 > > > No, the compiler doesn't decompose the string to figure how > > > operands > > > are used. That's what the constraints are for. The only two > > > things > > > the > > > compiler does with the string is replace % operators and count > > > line > > > separators. > > It looks like I am missing something. > >=20 > > addr -> a some register ( because of "r" contraint ). > > val -> is also register ( because of "r" contraint ). > >=20 > > So the compiler will update instert an instruction: > > =C2=A0sb reg1, 0(reg2) > >=20 > > what means *(uint_8 *)reg2 =3D (uint8_t)reg1. > >=20 > > What am I missing? >=20 > The fact that the compiler will not know that *(uint_8 *)reg2 > actually > changes across this asm(). It may therefore continue to hold a cached > value in a register, without knowing that its contents went stale. Then it makes sense to me. Thanks. It explains why it is needed +Q, but I don't understand why constraint 'o' isn't used for __raw_writew, but was used for __raw_writeb: static inline void __raw_writeb(u8 val, volatile void __iomem *addr) { asm volatile("strb %1, %0" : "+Qo" (*(volatile u8 __force *)addr) : "r" (val)); } =20 static inline void __raw_writew(u16 val, volatile void __iomem *addr) { asm volatile("strh %1, %0" : "+Q" (*(volatile u16 __force *)addr) : "r" (val)); }=20 =20 If I understand correctly 'o' that the address is offsettable, so why addr can not be offsettable for everyone case? And one more thing, in Xen constraint "+" is used, but in Linux it was dropped: https://patchwork.kernel.org/project/linux-arm-kernel/patch/1426958753-2690= 3-1-git-send-email-peter@hurleysoftware.com/ To me it looks like constraints should be always "+Qo". ~ Oleksii From xen-devel-bounces@lists.xenproject.org Thu Mar 07 17:05:50 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 17:05:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689970.1075523 (Exim 4.92) (envelope-from ) id 1riHBa-0007mN-GP; Thu, 07 Mar 2024 17:05:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689970.1075523; Thu, 07 Mar 2024 17:05:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riHBa-0007mG-CP; Thu, 07 Mar 2024 17:05:38 +0000 Received: by outflank-mailman (input) for mailman id 689970; Thu, 07 Mar 2024 17:05:37 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riHBZ-0007mA-0w for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 17:05:37 +0000 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on20601.outbound.protection.outlook.com [2a01:111:f403:2416::601]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id e8891bdd-dca4-11ee-afda-a90da7624cb6; Thu, 07 Mar 2024 18:05:35 +0100 (CET) Received: from CH0PR03CA0386.namprd03.prod.outlook.com (2603:10b6:610:119::29) by DS7PR12MB5767.namprd12.prod.outlook.com (2603:10b6:8:76::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.24; Thu, 7 Mar 2024 17:05:26 +0000 Received: from DS2PEPF0000343A.namprd02.prod.outlook.com (2603:10b6:610:119:cafe::97) by CH0PR03CA0386.outlook.office365.com (2603:10b6:610:119::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.27 via Frontend Transport; Thu, 7 Mar 2024 17:05:25 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by DS2PEPF0000343A.mail.protection.outlook.com (10.167.18.37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7362.11 via Frontend Transport; Thu, 7 Mar 2024 17:05:25 +0000 Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 7 Mar 2024 11:05:19 -0600 Received: from [172.17.205.23] (10.180.168.240) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.35 via Frontend Transport; Thu, 7 Mar 2024 11:05:19 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e8891bdd-dca4-11ee-afda-a90da7624cb6 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gU6h9lWqS9YCfyvaCTnFuKnDZi7RQE2RbGD7ZScrk1apdFpurciu3rLT/2M8dGqKJ26SDAE4kyFpPkk7qQZv6KZZ2e2yRMMRIuLbOaP58Jc5aJsMsrYmWTbSAwvBFDwhXcLnl1wPwNIymS6tfVM7YgFLHO4edcN+OPx9MoHvNYj0MEI4qiupEETzR2Ee5lc5/dycaaE5XqlBHSQ5IX1koCxKRShQtKyCvVgmrxX8FhK/6yzMgkjSp30AFM5SVyWzxBAfcT/JUf7NFQ8LX5At8FkjjscXZxrgc/jiqxQS6tVPjXEFVW3LVuswjMlmCJbT4mLsVWnOIGKHJwcNIr8jKw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=peDdfk8CtYT+D01TwAjKTx9fXGe/hb4qFEAKpOAB/4E=; b=TrPFdy2RaWn46xFo91oG5z4TO0AJ0uOwtKDDVYZveXPGDH/CsakHJQwX+MMy7c4x9q9k3dbfIF/hyA122faKhbKxytMFS3d99G0tUZ0vAppLgOgW2BxF0g0noa+0URNx1DAkw/idTOl7BMy44YuYKJpGLfLshUELDQ3Rv8aIThg26r8L64NALRNyWnE3eoolEhLJEUhn/ft1mDDJ4eAcHCL8Yo+bERdwGdKeStqCYbfj8x8ZmlWK9ESH78JBRHcQPjSaO/lTFLlcuqiOL7rBSRDctiCA6ThA+ySDVOrFguKG6VIVlcDR8Wgbxvyi7tDvRdd3XOl2/ucNc1L87CStHw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=citrix.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=peDdfk8CtYT+D01TwAjKTx9fXGe/hb4qFEAKpOAB/4E=; b=YNyrYPi/Zz+D4eR3W1NNzPkuHHRlGS+76+2Dvxs9DUeXKVLhI3f/6GYCPfNj1kDVDAnMQ8RunGHxyJHYGv4Z5JWrXggG2oPFvo1GJTQAh4W6iaZD56hcSxKDGUrioAesyFySccK4A+jG4Oy40zkQGFxLdm8IOesRE+cX3VWyrC0= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C Message-ID: Date: Thu, 7 Mar 2024 12:01:02 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Jason Andryuk Subject: Re: [PATCH 3/3] x86/PVH: Support relocatable dom0 kernels To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= CC: , Jan Beulich , Andrew Cooper , Wei Liu , George Dunlap , Julien Grall , Stefano Stabellini References: <20240306185032.103216-1-jason.andryuk@amd.com> <20240306185032.103216-4-jason.andryuk@amd.com> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: None (SATLEXMB04.amd.com: jason.andryuk@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS2PEPF0000343A:EE_|DS7PR12MB5767:EE_ X-MS-Office365-Filtering-Correlation-Id: 0a976f22-89c3-41c6-eed0-08dc3ec8c88d X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 6iC7Vz/1C1yepYZpsDWOe+tSF/ZBtIbHQGyLCdRDgBOq+gCTPQE+DliyVsOeCYY0zBvaHVzqGLksCTkD3IqNLHztw9upDAAqngC0PEVuX4PBYlFt9dN8LD8BttOG6+Z+IoxxDrhMTrMpIy8LO4E3eKf+VF4SX/Mzh10vLiZSVlKUshQd4h/kvO0cTAZmuBbyJvF+St48h6sGWHwSX+t1G8n1DqO8l1Zdv4DffcxU/x9vycS2lj+lC8awOiq65pA4nrA56SUmKCaBrolHY0mWEYEnVMT8lxr469ExGRkyX8RQJWt0Hi6/IyLJoeiWso4lIEOn/vUlrMS3kyzhmX9VC7p0fP5QRVO0PCX20Qr4WX/DK7VBfecRaPxjtEezs2ClwpRG6fQgpXb1UHvLHfufdid+LR/zNfTjnuid5AqNDLVcFNYngkeGMLz7pl8xIMRCgH2xDaDBbBfkQOOEchd5/ZGrOXHtFLlegYFZFZO21aNiBQXEKbE1+eJCU120NBGAH1I/9o7Cza4yoRwCmcpj4CVD9ptNyqR+ixneDG7mgbDfLjGzTyUvYg1Xz7AC9VboPDie7NrBF8cp4HMq1F8pf2hAVBPCwEsLYWD+WFIuedz0ufPuZVH41pbKfq0n8e9TQ5xBAe/RI/9s6abM0uxFJmILnpkeiNcsep/DT9y5krTP15Zq4Y9OPDS5etIaEe/YJkQxYdJbem5GhrKE6xJZ5A== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(36860700004)(376005)(82310400014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Mar 2024 17:05:25.7956 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 0a976f22-89c3-41c6-eed0-08dc3ec8c88d X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: DS2PEPF0000343A.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR12MB5767 On 2024-03-07 04:30, Roger Pau Monné wrote: > On Wed, Mar 06, 2024 at 01:50:32PM -0500, Jason Andryuk wrote: >> Xen tries to load a PVH dom0 kernel at the fixed guest physical address >> from the elf headers. For Linux, this defaults to 0x1000000 (16MB), but >> it can be configured. >> >> Unfortunately there exist firmwares that have reserved regions at this >> address, so Xen fails to load the dom0 kernel since it's not RAM. >> >> The PVH entry code is not relocatable - it loads from absolute >> addresses, which fail when the kernel is loaded at a different address. >> With a suitably modified kernel, a reloctable entry point is possible. >> >> Add the XENFEAT_pvh_relocatable flag to let a kernel indicate that it >> supports a relocatable entry path. >> >> Change the loading to check for an acceptable load address. If the >> kernel is relocatable, support finding an alternate load address. >> >> Linux cares about its physical alignment. This can be pulled out of the >> bzImage header, but not from the vmlinux ELF file. If an alignment >> can't be found, use 2MB. > > While I'm fine with having a Linux specific way, there needs to be a > generic way of passing the alignment for non-bzImage kernels. > > ELF program headers have an align field, would that be suitable to > use? Unfortunately, it doesn't seem correct. Linux has CONFIG_PHYSICAL_ALIGN, and it doesn't seem to be used in the elf headers. As a quick test, I set CONFIG_PHYSICAL_ALIGN=0x800000, but the elf align values are still 0x200000. > In elf_parse_binary() where the p{start,end} is calculated, you could > also fetch the p_offset from the lower found program header and use it > as the required alignment. Would that be OK for Linux and maybe avoid > having to fiddle with the bzImage header? FWIW it is likely fine for > FreeBSD. Adding an explicit value in an elf note would avoid any ambiguity. >> >> Signed-off-by: Jason Andryuk > > I created a gitlab ticket for this: > > https://gitlab.com/xen-project/xen/-/issues/180 > > If you want to reference it. Will do >> --- >> Put alignment as a new ELF note? Presence of that note would indicate >> relocation support without a new XENFEAT flag. >> >> Default alignment to a multiple of 2MB to make more cases work? It has >> to be a power of two, and a multiple might allow loading a customized >> kernel. A larger alignment would limit the number of possible load >> locations. >> --- >> xen/arch/x86/hvm/dom0_build.c | 109 ++++++++++++++++++++++++++++++++++ >> xen/include/public/features.h | 5 ++ >> 2 files changed, 114 insertions(+) >> >> diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c >> index bbae8a5645..34d68ee8fb 100644 >> --- a/xen/arch/x86/hvm/dom0_build.c >> +++ b/xen/arch/x86/hvm/dom0_build.c >> @@ -537,6 +537,109 @@ static paddr_t __init find_memory( >> return INVALID_PADDR; >> } >> >> +static bool __init check_load_address( >> + const struct domain *d, const struct elf_binary *elf) >> +{ >> + paddr_t kernel_start = (paddr_t)elf->dest_base & PAGE_MASK; >> + paddr_t kernel_end = ROUNDUP((paddr_t)elf->dest_base + elf->dest_size, >> + PAGE_SIZE); > > You can use PAGE_ALIGN() here (and below) for simplicity. Ok >> + unsigned int i; >> + >> + /* >> + * The memory map is sorted and all RAM regions starts and sizes are >> + * aligned to page boundaries. >> + */ >> + for ( i = 0; i < d->arch.nr_e820; i++ ) >> + { >> + paddr_t start = d->arch.e820[i].addr; >> + paddr_t end = d->arch.e820[i].addr + d->arch.e820[i].size; > > Since the memory map is sorted you can end the loop once end start >= > kernel_end? As further regions are past the kernel destination. Yes, thanks. >> + >> + if ( start <= kernel_start && >> + end >= kernel_end && >> + d->arch.e820[i].type == E820_RAM ) >> + return true; >> + } >> + >> + return false; >> +} >> + >> +/* >> + * Find an e820 RAM region that fits the kernel at a suitable alignment. >> + */ > > This (and other) comment seems to fit in a single line: /* ... */. Ok >> +static paddr_t find_kernel_memory( >> + const struct domain *d, struct elf_binary *elf, paddr_t align) > > elf can be const AFAICT. Ok >> +{ >> + paddr_t kernel_start = (paddr_t)elf->dest_base & PAGE_MASK; >> + paddr_t kernel_end = ROUNDUP((paddr_t)elf->dest_base + elf->dest_size, >> + PAGE_SIZE); >> + unsigned int i; >> + >> + /* >> + * The memory map is sorted and all RAM regions starts and sizes are >> + * aligned to page boundaries. >> + */ >> + for ( i = 0; i < d->arch.nr_e820; i++ ) >> + { >> + paddr_t start = d->arch.e820[i].addr; >> + paddr_t end = d->arch.e820[i].addr + d->arch.e820[i].size; >> + paddr_t kstart, kend, offset; >> + >> + if ( d->arch.e820[i].type != E820_RAM ) >> + continue; >> + >> + if ( d->arch.e820[i].size < elf->dest_size ) >> + continue; >> + >> + if ( end < kernel_end ) >> + continue; > > I'm not sure I understand this check, why would we refuse regions > below the fixed kernel end? Those should be equally suitable if big > enough and meeting the alignment requirements. I thought (Linux at least) wouldn't want to be moved lower - only higher in ram. There was some Linux boot code that gave me that impression, but it may not be strictly true. >> + >> + kstart = ROUNDUP(start, align); >> + offset = kstart - kernel_start; >> + kend = kernel_end + offset; >> + >> + if ( kend <= end ) >> + return offset; > > Why not return this as an address to use to load the kernel instead of > an offset from dest_base? That would also make the calculations > easier IMO. phys_entry needs to be updated as well as dest_base, so returning the offset seemed more useful. >> + } > > This should be limited to a range below 4GB. Yes. >> + return 0; >> +} >> + >> +/* >> + * Check the kernel load address, and adjust if necessary and possible. >> + */ >> +static bool __init adjust_load_address( >> + const struct domain *d, struct elf_binary *elf, struct elf_dom_parms *parms, >> + paddr_t align) >> +{ >> + paddr_t offset; >> + >> + /* Check load address */ >> + if ( check_load_address(d, elf) ) >> + return true; >> + >> + if ( !test_bit(XENFEAT_pvh_relocatable, parms->f_supported) ) >> + { >> + printk("Address conflict and %pd kernel is not relocatable\n", d); >> + return false; >> + } >> + >> + if ( align == 0 ) >> + align = MB(2); >> + >> + offset = find_kernel_memory(d, elf, align); >> + if ( offset == 0 ) >> + { >> + printk("Failed find a load offset for the kernel\n"); >> + return false; >> + } >> + >> + printk("Adjusting load address by %#lx\n", offset); > > I think this would be more helpful if the previous and the new ranges > are printed, as I'm not sure the previous dest_base is printed, in > which case the offset doesn't help much. I would do: > > if ( opt_dom0_verbose ) > printk("relocating kernel from [%lx, %lx] -> [%lx, %lx]\n", ...); dest_base was printed (maybe with extra verbosity), but this message is clearer since it shows the end result. >> + elf->dest_base += offset; >> + parms->phys_entry += offset; > > As noted above, I think it would be better if find_kernel_memory() > find an absolute address which is then adjusted here. I thought the modification with just offset was clearer compared to: params->phys_entry += (reloc_base - elf->dest_base); elf->dest_base = reloc_base; But I'm fine making the change. >> + >> + return true; >> +} >> + >> static int __init pvh_load_kernel(struct domain *d, const module_t *image, >> unsigned long image_headroom, >> module_t *initrd, void *image_base, >> @@ -587,6 +690,12 @@ static int __init pvh_load_kernel(struct domain *d, const module_t *image, >> elf.dest_base = (void *)(parms.virt_kstart - parms.virt_base); >> elf.dest_size = parms.virt_kend - parms.virt_kstart; >> >> + if ( !adjust_load_address(d, &elf, &parms, align) ) > > check_and_adjust_? As the address is not unconditionally adjusted. I thought it was a little too wordy, but it is more accurate. I'll rename it. Thanks for taking a look. -Jason From xen-devel-bounces@lists.xenproject.org Thu Mar 07 17:08:27 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 17:08:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689973.1075533 (Exim 4.92) (envelope-from ) id 1riHEI-0008NZ-0b; Thu, 07 Mar 2024 17:08:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689973.1075533; Thu, 07 Mar 2024 17:08:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riHEH-0008NS-U0; Thu, 07 Mar 2024 17:08:25 +0000 Received: by outflank-mailman (input) for mailman id 689973; Thu, 07 Mar 2024 17:08:24 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riHEG-0008N4-0V for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 17:08:24 +0000 Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [2a00:1450:4864:20::131]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 4ce65270-dca5-11ee-a1ee-f123f15fe8a2; Thu, 07 Mar 2024 18:08:22 +0100 (CET) Received: by mail-lf1-x131.google.com with SMTP id 2adb3069b0e04-5131c0691feso1526403e87.1 for ; Thu, 07 Mar 2024 09:08:21 -0800 (PST) Received: from [192.168.206.239] ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id f12-20020a05651201cc00b00513360ebd22sm2551021lfp.118.2024.03.07.09.08.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Mar 2024 09:08:20 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 4ce65270-dca5-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709831301; x=1710436101; darn=lists.xenproject.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=ViU2v0qBRASJJ7QWLeqYy0/HQnnBlvBlJiZL/b+CMsc=; b=Tq39TXViKArPXWw2oMepVBssBTWXTlvzj5/4VkL17uc6gthW+DT9ZaxD5TNRYENLqd ZAXNaphy1unK14Sv8km3d9w/4sM/0ALR6hOqJz9zpIZzA9didBHHcdK/6w2l8ajUxpqn 2OXo1Y2ytR7wCDvSud2CbEuU/1TyGJFh7fB9xbcIH3WRWPM3ljDqxqyHw+vTZ5PBq7EM RPv/gWLL4cirANLtn+LehzboaSU51FXR3xBE350vfc02z6oTVgTAdPPbEPim4y/nb0bT 7fPL1NODz/LpDFexN/lakNSArqRWMDDzAm3jT4UeutgxZRljTIthzVpoPOBfqAu5+P4n gYuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709831301; x=1710436101; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=ViU2v0qBRASJJ7QWLeqYy0/HQnnBlvBlJiZL/b+CMsc=; b=t2y1Rv5lbxw7Qzs07pB7jhbgw3boi7sp8blah6fD0Z9mqt/fUCN86eANxutoh7JbLX 1sUe/FY25eI3iwzVpe9298rYvXpzlBW4F4fRez1PcO9BG1vdmrkt7Cs4nIOIOKhF5imx 0L0t4GVW2fz6j7/YdnBbpZ1qWywSDkc3aPkeukgKKsvqS8ea+5mKTSF+w5EpXFvbOQpN ob8ATfwCK9XbWuVW7WstQXLMz58hStf0lSd3yEyj8x2PJG+XjyDWZ6CH66Stftc0lyxL nJiSNfvXofHSixeC55NwtMz0Q8/0vyC4oA7BjvcOUfcatKrzraCvGplaKPn7qTkKclqX zp4g== X-Forwarded-Encrypted: i=1; AJvYcCVnmrBz63zVvcKjpVqsQvJCIa7j5WTbPxYsDBhz37RM4zujOFnqyYFhi+MeE39BNbEKoiUFYIKl3JX/yHSP8FF/FHkJ9lOy56+A2cyH1E8= X-Gm-Message-State: AOJu0YwOGIsVqiBS38foYAOYQJamfericXerUQg8MUsh/zbF4GicuTi7 c52ls7Hv+RavG6U6VsKl/sgK4PnoJUAQKC4rt342e6/QbWMM55eW X-Google-Smtp-Source: AGHT+IFCy+1qkHbSXi3+x5WAqAVxxB/7wcM6pQ+w8nIVeD8daUd7709MAmi0ugx5OaIEiBU1w6+x1Q== X-Received: by 2002:ac2:514a:0:b0:513:6ac7:138c with SMTP id q10-20020ac2514a000000b005136ac7138cmr1725104lfd.40.1709831300561; Thu, 07 Mar 2024 09:08:20 -0800 (PST) Message-ID: Subject: Re: [PATCH] move __read_mostly to xen/cache.h From: Oleksii To: Jan Beulich Cc: George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu , Roger Pau =?ISO-8859-1?Q?Monn=E9?= , Bertrand Marquis , Volodymyr Babchuk , Shawn Anastasio , "xen-devel@lists.xenproject.org" , Andrew Cooper Date: Thu, 07 Mar 2024 18:08:19 +0100 In-Reply-To: <64466285-35b8-497c-a12b-60fe0c998ba6@suse.com> References: <893a5ebf-54e2-f2b2-1365-2a6d36ed3a39@suse.com> <64466285-35b8-497c-a12b-60fe0c998ba6@suse.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.50.2 (3.50.2-1.fc39) MIME-Version: 1.0 On Fri, 2023-12-22 at 12:09 +0100, Jan Beulich wrote: > On 22.12.2023 10:39, Oleksii wrote: > > On Tue, 2023-08-08 at 12:32 +0200, Jan Beulich wrote: > > > On 08.08.2023 12:18, Andrew Cooper wrote: > > > > On 08/08/2023 10:46 am, Jan Beulich wrote: > > > > > There's no need for every arch to define its own identical > > > > > copy. > > > > > If down > > > > > the road an arch needs to customize it, we can add #ifndef > > > > > around > > > > > the > > > > > common #define. > > > > >=20 > > > > > To be on the safe side build-breakage-wise, change a couple > > > > > of > > > > > #include > > > > > to the xen/ equivalent. > > > > >=20 > > > > > Signed-off-by: Jan Beulich > > > >=20 > > > > Could we find a better place to put this? > > > >=20 > > > > __read_mostly is just a section.=C2=A0 It's relationship to the > > > > cache is > > > > only > > > > microarchitectural, and is not the same kind of information as > > > > the > > > > rest > > > > of cache.h > > > >=20 > > > > __ro_after_init is only here because __read_mostly is here, but > > > > has > > > > absolutely nothing to do with caches whatsoever. > > > >=20 > > > > If we're cleaning them up, they ought to live elsewhere. > > >=20 > > > I would be considering init.h (for having most other __section() > > > uses, > > > and for also needing __read_mostly), but that's not a great place > > > to > > > put these either. In fact I see less connection there than for > > > cache.h. > > > So the primary need is a good suggestion (I'm hesitant to suggest > > > to > > > introduce section.h just for this). > > Andrew sent some suggestions here: > > https://lore.kernel.org/xen-devel/3df1dad8-3476-458f-9022-160e0af57d39@= citrix.com/ > >=20 > > Will that work for you? >=20 > I still need to properly look at the suggested options. Have you had a chance to review the suggested options? ~ Oleksii From xen-devel-bounces@lists.xenproject.org Thu Mar 07 17:13:33 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 17:13:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689976.1075542 (Exim 4.92) (envelope-from ) id 1riHJ9-00026J-I7; Thu, 07 Mar 2024 17:13:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689976.1075542; Thu, 07 Mar 2024 17:13:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riHJ9-00026C-Ff; Thu, 07 Mar 2024 17:13:27 +0000 Received: by outflank-mailman (input) for mailman id 689976; Thu, 07 Mar 2024 17:13:25 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riHJ7-00025n-CW for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 17:13:25 +0000 Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [2a00:1450:4864:20::22a]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 018dc424-dca6-11ee-afda-a90da7624cb6; Thu, 07 Mar 2024 18:13:24 +0100 (CET) Received: by mail-lj1-x22a.google.com with SMTP id 38308e7fff4ca-2d2991e8c12so11612801fa.0 for ; Thu, 07 Mar 2024 09:13:24 -0800 (PST) Received: from [192.168.206.239] ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id a14-20020a2e980e000000b002d0a7ba3215sm3114843ljj.85.2024.03.07.09.13.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Mar 2024 09:13:23 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 018dc424-dca6-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709831604; x=1710436404; darn=lists.xenproject.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=qrlFTiBd5RZIoLfeqX5Iuykltkt949AokDl3AMi6iY0=; b=MCqazaxxrsIpDTQn1OzooM/zBNWMUvSVUOFR+rFygyWN7TEwwe1sjalmiuN7PXrMrt 4TBfiPKCYrHFSa8waKQZHcA5piXt5CwU2OCudjNgdRyEEcp2DF9Xfz41+SfkM89J+4ce X2RJlszQXULyAK0v5Gal2Cst1gg7cVIr1F7MAp2nNv8QhOC1GiyOHCQN4jPXLHrsNUGi k7KNCzi4EzPAnfeUlvxfvERYrwTJOzVdG7QbYf6fZuzXjXuQy740Gqbt613EAWdDFzvP 49XlNNaI8RyUlCapV6H42xakIL/yw0qUpVjTQrrZj3RfHmgF354VUDnlACGwux2Q8qZ6 XQ5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709831604; x=1710436404; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=qrlFTiBd5RZIoLfeqX5Iuykltkt949AokDl3AMi6iY0=; b=myHrTIKOG7SbCqn/PXLJKugkeR0CHowynb4Xtz8J7i+0yrmUmGPrWr3raOIIBwE25C f1SKPvvIhWnusWuan0bnFR3lcQcP21aDVTwKeocruk/+T2xIjrwiIUbhGuvJFaE6Oqn0 d0Rw07tMYuR5JK4J42qQ7dCQyObh+Rq8sTuJ34R6pc2wqPVKdKg3rOOnu+45lfQrA8sN ME55y85D0ts8xQCwrwPt91uWMkrzdTQ6AZIA9cB0h1Oz3ihqxl+uuNWu5RBq/1NlApmx T2Q5HRbdxi26pejK1NSuZYUvz5o9z2D6sfdk7BzdiKTiKewr0Y2/cJcH8iLLPQ2Pq1hm w6Jw== X-Gm-Message-State: AOJu0YySHyZq796gSuXLzxiDUIQS9Xpn2qNHQfxccbhAAxnPVvU4Q88G Nz3/YhRBmcSaZWG2HNPCgTUkXlOb+aDwoDAPuK2NhM9zgK2cM8XXW+MIkgzPWBo= X-Google-Smtp-Source: AGHT+IFHhBFaeFrp/MK6nlv6+oceZk2cqA02MKFl85idmcEwZfhVDDj013GrypXmzO8ENodpcbZCOw== X-Received: by 2002:a2e:978e:0:b0:2d2:6457:4087 with SMTP id y14-20020a2e978e000000b002d264574087mr351650lji.6.1709831603419; Thu, 07 Mar 2024 09:13:23 -0800 (PST) Message-ID: <563cbcbf1bb4b540b858c187618969b75bd37481.camel@gmail.com> Subject: Re: [PATCH v9 1/7] automation: introduce fixed randconfig for RISC-V From: Oleksii To: xen-devel@lists.xenproject.org, Doug Goldstein , Stefano Stabellini Cc: Michal Orzel Date: Thu, 07 Mar 2024 18:13:22 +0100 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.50.2 (3.50.2-1.fc39) MIME-Version: 1.0 Hello Doug and Stefano, While Michal has reviewed this patch, I understand that I still need your Acked-by. Could you please take a moment to review the patch? Thanks in advance. ~ Oleksii On Fri, 2024-02-16 at 13:39 +0100, Oleksii Kurochko wrote: > This patch introduces the anchor riscv-fixed-randconfig, > which includes all configurations that should be disabled for > randconfig builds. >=20 > Suggested-by: Stefano Stabellini > Signed-off-by: Oleksii Kurochko > --- > The patch were introduced after discussion in a topic: > =C2=A0 > https://lore.kernel.org/xen-devel/cover.1701966261.git.oleksii.kurochko@g= mail.com > / > --- > Changes in V9: > =C2=A0- add '|' symbol after EXTRA_FIXED_RANDCONFIG to make variables in > EXTRA_FIXED_RANDCONFIG > =C2=A0=C2=A0 be separated by new line. > =C2=A0- instead of introduction of new file for riscv-fixed-randconfig, > introduce an anchor > =C2=A0=C2=A0 inside build.yaml > --- > Changes in V8: > =C2=A0- Nothing changed. Only rebase > --- > Changes in V7: > =C2=A0- Nothing changed. Only rebase > --- > Changes in V6: > =C2=A0- The patch was introduced in this version of patch series. > --- > =C2=A0automation/gitlab-ci/build.yaml | 14 ++++++++++---- > =C2=A01 file changed, 10 insertions(+), 4 deletions(-) >=20 > diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab- > ci/build.yaml > index 6d2cb18b88..aac29ee13a 100644 > --- a/automation/gitlab-ci/build.yaml > +++ b/automation/gitlab-ci/build.yaml > @@ -512,6 +512,14 @@ alpine-3.18-gcc-debug-arm64-boot-cpupools: > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CONFIG_BOOT_TIME_CPUPOOLS=3Dy > =C2=A0 > =C2=A0# RISC-V 64 cross-build > +.riscv-fixed-randconfig: > +=C2=A0 variables: &riscv-fixed-randconfig > +=C2=A0=C2=A0=C2=A0 EXTRA_FIXED_RANDCONFIG: | > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CONFIG_COVERAGE=3Dn > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CONFIG_EXPERT=3Dy > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CONFIG_GRANT_TABLE=3Dn > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CONFIG_MEM_ACCESS=3Dn > + > =C2=A0archlinux-current-gcc-riscv64: > =C2=A0=C2=A0 extends: .gcc-riscv64-cross-build > =C2=A0=C2=A0 variables: > @@ -532,8 +540,7 @@ archlinux-current-gcc-riscv64-randconfig: > =C2=A0=C2=A0=C2=A0=C2=A0 CONTAINER: archlinux:current-riscv64 > =C2=A0=C2=A0=C2=A0=C2=A0 KBUILD_DEFCONFIG: tiny64_defconfig > =C2=A0=C2=A0=C2=A0=C2=A0 RANDCONFIG: y > -=C2=A0=C2=A0=C2=A0 EXTRA_FIXED_RANDCONFIG: > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CONFIG_COVERAGE=3Dn > +=C2=A0=C2=A0=C2=A0 <<: *riscv-fixed-randconfig > =C2=A0 > =C2=A0archlinux-current-gcc-riscv64-debug-randconfig: > =C2=A0=C2=A0 extends: .gcc-riscv64-cross-build-debug > @@ -541,8 +548,7 @@ archlinux-current-gcc-riscv64-debug-randconfig: > =C2=A0=C2=A0=C2=A0=C2=A0 CONTAINER: archlinux:current-riscv64 > =C2=A0=C2=A0=C2=A0=C2=A0 KBUILD_DEFCONFIG: tiny64_defconfig > =C2=A0=C2=A0=C2=A0=C2=A0 RANDCONFIG: y > -=C2=A0=C2=A0=C2=A0 EXTRA_FIXED_RANDCONFIG: > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CONFIG_COVERAGE=3Dn > +=C2=A0=C2=A0=C2=A0 <<: *riscv-fixed-randconfig > =C2=A0 > =C2=A0# Power cross-build > =C2=A0debian-bullseye-gcc-ppc64le: From xen-devel-bounces@lists.xenproject.org Thu Mar 07 17:14:17 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 17:14:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689978.1075552 (Exim 4.92) (envelope-from ) id 1riHJw-0002a8-SA; Thu, 07 Mar 2024 17:14:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689978.1075552; Thu, 07 Mar 2024 17:14:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riHJw-0002a1-PV; Thu, 07 Mar 2024 17:14:16 +0000 Received: by outflank-mailman (input) for mailman id 689978; Thu, 07 Mar 2024 17:14:15 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riHJv-0002Zl-I4 for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 17:14:15 +0000 Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [2a00:1450:4864:20::52a]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 1de6a0a2-dca6-11ee-a1ee-f123f15fe8a2; Thu, 07 Mar 2024 18:14:12 +0100 (CET) Received: by mail-ed1-x52a.google.com with SMTP id 4fb4d7f45d1cf-567fbbd723cso1399741a12.3 for ; Thu, 07 Mar 2024 09:14:12 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id gq13-20020a170906e24d00b00a45621ded4bsm4460517ejb.146.2024.03.07.09.14.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Mar 2024 09:14:11 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1de6a0a2-dca6-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709831651; x=1710436451; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=5FzSgLdAWYaoILd8r6pOp9cL4FDfyhV7+g5Vlst+zBU=; b=NwVTi6ERmIFgaCV2LFG+3ji3TOYTEPT81mAC48fKlm4siHikgESDTNY9agb+D8ufvV fUolxhIfpjzDpRRAucvwlDXBf01s7dVn6cxWrFJ0qwPXGK4hS7ffjIlBSu7hQmLlxi4C Y24gjuZQEYBwgh2vJVi3n0wBK5n9OnJmLCBOqeFDpoTUGmdM7ruEo99NUqknY75axfZh NADDxN9ummCCzdyp5eLpf+rGnjiHlFBU5nLmmGX16AghS9QQAUXFEbgjpGzJmEfydJXi V5DTffBETrYAvy9oLpbjD9usqOhPEWzfBIURkFDYiv6uY0zPl/O/Vm/Y0q5sC2lab8VM +WFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709831651; x=1710436451; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=5FzSgLdAWYaoILd8r6pOp9cL4FDfyhV7+g5Vlst+zBU=; b=n7q1AKVrqA6q7YOf246AaLObB09uaOoIcdF9qvq6QuR/24Y6ovsNG9eEUJnQNSX2FV Pb9h+HoHZ8oBY9deBhiG+ldsYwr86ATD9GcWTi2e9tSiuh4uCi/50CFXQ/6dS64m3/Go YN61NLL0Wxhr+8HP1+qckwdVnCAlPHT7iloQHEqjn5knQeKEQv/xdo1yoNjXHga8+qOL r/bKVZ+Xb5js4pGBFW8zLvaKc6N2G0aA3T+2UB4jPlVDR0VcXsmXveDwWwAg0zEpihm2 7a6oNDdYU0/GafaKBqQHHoSAto3K4WPt0PQ53jPZRy1GzFTD3F2loRFruFi2UeqxHJg8 ASvw== X-Forwarded-Encrypted: i=1; AJvYcCXpaEpnNoUj0qVG4OYyJzltCIh/OXj6deOVyeqkUh+QDIKJWYtG973VhTW7eIs/bRPOUUyAFTyogapudWQMmEYiqM4PR40b/rAF06EyN/c= X-Gm-Message-State: AOJu0YwJtDXEmfNUXIW0Yfpu62w2Tq7YIq4ltPx+P8ZN7H6ej8+XAfbm kPb3QsVsaq3f/4w5v+KORG+Uplgsjrj7+nwFQKdKZ1Dye30kL9C3n/x3OtfGjA== X-Google-Smtp-Source: AGHT+IHBgPIBJXAb8p9LS15ZVwJ2Ii5yz/Zko3U4SVv68bIIIjgO2vY+v259rSmUKbXH47soK6YPng== X-Received: by 2002:a17:906:3798:b0:a3f:bd94:4d80 with SMTP id n24-20020a170906379800b00a3fbd944d80mr13101311ejc.76.1709831651474; Thu, 07 Mar 2024 09:14:11 -0800 (PST) Message-ID: Date: Thu, 7 Mar 2024 18:14:09 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 12/23] xen/riscv: introduce io.h Content-Language: en-US To: Oleksii Cc: Alistair Francis , Bob Eshleman , Connor Davis , Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu , xen-devel@lists.xenproject.org References: <807c31d5-0c5a-4646-ba90-2f284289069f@suse.com> <2a3e49bf94332c17b50e4f0f745e4b28b16dceb1.camel@gmail.com> <2a05c233-b3c5-417c-bd6b-8b1c21f03c3d@suse.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 07.03.2024 17:21, Oleksii wrote: > On Thu, 2024-03-07 at 16:32 +0100, Jan Beulich wrote: >> On 07.03.2024 14:44, Oleksii wrote: >>> On Thu, 2024-03-07 at 14:24 +0100, Jan Beulich wrote: >>>> On 07.03.2024 14:01, Oleksii wrote: >>>>> On Wed, 2024-03-06 at 15:13 +0100, Jan Beulich wrote: >>>>>>> +/* Generic IO read/write.  These perform native-endian >>>>>>> accesses. >>>>>>> */ >>>>>>> +static inline void __raw_writeb(uint8_t val, volatile void >>>>>>> __iomem >>>>>>> *addr) >>>>>>> +{ >>>>>>> +    asm volatile ( "sb %0, 0(%1)" : : "r" (val), "r" >>>>>>> (addr) ); >>>>>>> +} >>>>>> >>>>>> I realize this is like Linux has it, but how is the compiler >>>>>> to >>>>>> know >>>>>> that >>>>>> *addr is being access here?  >>>>> Assembler syntax told compiler that. 0(%1) - means that the >>>>> memory >>>>> location pointed to by the address in register %1. >>>> >>>> No, the compiler doesn't decompose the string to figure how >>>> operands >>>> are used. That's what the constraints are for. The only two >>>> things >>>> the >>>> compiler does with the string is replace % operators and count >>>> line >>>> separators. >>> It looks like I am missing something. >>> >>> addr -> a some register ( because of "r" contraint ). >>> val -> is also register ( because of "r" contraint ). >>> >>> So the compiler will update instert an instruction: >>>  sb reg1, 0(reg2) >>> >>> what means *(uint_8 *)reg2 = (uint8_t)reg1. >>> >>> What am I missing? >> >> The fact that the compiler will not know that *(uint_8 *)reg2 >> actually >> changes across this asm(). It may therefore continue to hold a cached >> value in a register, without knowing that its contents went stale. > Then it makes sense to me. Thanks. FTAOD similar considerations apply to memory reads. The compiler may need to know that values held in registers first need writing back to memory before an asm() can be invoked. > It explains why it is needed +Q, but > I don't understand why constraint 'o' isn't used for __raw_writew, but > was used for __raw_writeb: > > static inline void __raw_writeb(u8 val, volatile void __iomem *addr) > { > asm volatile("strb %1, %0" > : "+Qo" (*(volatile u8 __force *)addr) > : "r" (val)); > } > > static inline void __raw_writew(u16 val, volatile void __iomem *addr) > { > asm volatile("strh %1, %0" > : "+Q" (*(volatile u16 __force *)addr) > : "r" (val)); > } > > If I understand correctly 'o' that the address is offsettable, so why > addr can not be offsettable for everyone case? I don't know; there may be peculiarities in RISC-V specific constraints. > And one more thing, in Xen constraint "+" is used, but in Linux it was > dropped: > https://patchwork.kernel.org/project/linux-arm-kernel/patch/1426958753-26903-1-git-send-email-peter@hurleysoftware.com/ > > To me it looks like constraints should be always "+Qo". For plain writes it should at least be "=Qo" then, yes. To me making those input operands on Arm can't have been quite right. Jan From xen-devel-bounces@lists.xenproject.org Thu Mar 07 17:35:19 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 17:35:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689987.1075563 (Exim 4.92) (envelope-from ) id 1riHe7-0006eD-IZ; Thu, 07 Mar 2024 17:35:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689987.1075563; Thu, 07 Mar 2024 17:35:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riHe7-0006e6-Ew; Thu, 07 Mar 2024 17:35:07 +0000 Received: by outflank-mailman (input) for mailman id 689987; Thu, 07 Mar 2024 17:35:06 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riHe6-0006e0-FE for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 17:35:06 +0000 Received: from raptorengineering.com (mail.raptorengineering.com [23.155.224.40]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 06f75882-dca9-11ee-a1ee-f123f15fe8a2; Thu, 07 Mar 2024 18:35:03 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.rptsys.com (Postfix) with ESMTP id 7491782856FA; Thu, 7 Mar 2024 11:35:00 -0600 (CST) Received: from mail.rptsys.com ([127.0.0.1]) by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id LbL3n2Y4vAaT; Thu, 7 Mar 2024 11:34:59 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by mail.rptsys.com (Postfix) with ESMTP id AAA4F82856FE; Thu, 7 Mar 2024 11:34:59 -0600 (CST) Received: from mail.rptsys.com ([127.0.0.1]) by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id oHXl8wvS613K; Thu, 7 Mar 2024 11:34:59 -0600 (CST) Received: from [10.11.0.3] (5.edge.rptsys.com [23.155.224.38]) by mail.rptsys.com (Postfix) with ESMTPSA id ED59F82856FA; Thu, 7 Mar 2024 11:34:58 -0600 (CST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 06f75882-dca9-11ee-a1ee-f123f15fe8a2 DKIM-Filter: OpenDKIM Filter v2.10.3 mail.rptsys.com AAA4F82856FE DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raptorengineering.com; s=B8E824E6-0BE2-11E6-931D-288C65937AAD; t=1709832899; bh=ZMBdjjR09bmjZSXANLLktA8uFjvRHzvTeNuNDPpY/fE=; h=Message-ID:Date:MIME-Version:To:From; b=IP6X+ZAmRoX6+PvYJUB4hm+73Vt5G7Y+N7zS8PK5YoFG/ZOOH2dKHWnWSJv0oGkTr ZRLUF1FCnoSX6dhY+XA5itJIR68FcNn7FydwO3TJ/Sjfj9fewWpwkOQlG8H8gkvJYQ LA55jbtH9+8WQbDTdk//DSEdA2hyKHAumz4u87QE= X-Virus-Scanned: amavisd-new at rptsys.com Message-ID: Date: Thu, 7 Mar 2024 11:34:58 -0600 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v9 2/7] xen/asm-generic: introduce stub header monitor.h To: Oleksii Kurochko , xen-devel@lists.xenproject.org Cc: Tamas K Lengyel , Alexandru Isaila , Petre Pircalabu , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Jan Beulich , Julien Grall References: <296530c13b8400f6872d4afc8cc14e2fcfc7a2d5.1708086092.git.oleksii.kurochko@gmail.com> Content-Language: en-US From: Shawn Anastasio In-Reply-To: <296530c13b8400f6872d4afc8cc14e2fcfc7a2d5.1708086092.git.oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Oleksii, On 2/16/24 6:39 AM, Oleksii Kurochko wrote: > The header is shared between several archs so it is > moved to asm-generic. > > Switch partly Arm and PPC to asm-generic/monitor.h and only > arch_monitor_get_capabilities() left in arch-specific/monitor.h. > > Signed-off-by: Oleksii Kurochko > Acked-by: Jan Beulich > Acked-by: Tamas K Lengyel > Acked-by: Julien Grall Acked-by: Shawn Anastasio Thanks, Shawn From xen-devel-bounces@lists.xenproject.org Thu Mar 07 17:37:44 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 17:37:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689989.1075572 (Exim 4.92) (envelope-from ) id 1riHgc-0007AL-UV; Thu, 07 Mar 2024 17:37:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689989.1075572; Thu, 07 Mar 2024 17:37:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riHgc-0007AE-RX; Thu, 07 Mar 2024 17:37:42 +0000 Received: by outflank-mailman (input) for mailman id 689989; Thu, 07 Mar 2024 17:37:42 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riHgb-0007A8-VX for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 17:37:42 +0000 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on20600.outbound.protection.outlook.com [2a01:111:f403:2412::600]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 6415b87c-dca9-11ee-a1ee-f123f15fe8a2; Thu, 07 Mar 2024 18:37:39 +0100 (CET) Received: from BL1PR13CA0229.namprd13.prod.outlook.com (2603:10b6:208:2bf::24) by MW4PR12MB5604.namprd12.prod.outlook.com (2603:10b6:303:18d::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.27; Thu, 7 Mar 2024 17:37:35 +0000 Received: from BL02EPF0001A0FA.namprd03.prod.outlook.com (2603:10b6:208:2bf:cafe::7e) by BL1PR13CA0229.outlook.office365.com (2603:10b6:208:2bf::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.9 via Frontend Transport; Thu, 7 Mar 2024 17:37:35 +0000 Received: from SATLEXMB03.amd.com (165.204.84.17) by BL02EPF0001A0FA.mail.protection.outlook.com (10.167.242.101) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7362.11 via Frontend Transport; Thu, 7 Mar 2024 17:37:35 +0000 Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 7 Mar 2024 11:37:35 -0600 Received: from [172.17.205.23] (10.180.168.240) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.35 via Frontend Transport; Thu, 7 Mar 2024 11:37:34 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6415b87c-dca9-11ee-a1ee-f123f15fe8a2 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Hkgz3m1XLeIl7XwjYi9qkTa+DTJmgkaUpZa0V9UG41PVdi+A/ooCUKIS055ug6SzzhO0qrWClC6WOn139rd5FYJoVCJgNmk/ZJ1vGxf9CekaRxX8RqfDx0ZIO89aawVA+7BkRyUSyoH+ui0Tq6jBWNSRVQ0G300Igc/m4uGUtuhhd15ncMRAQl/yEvdlMQ0GYaPOHD0azBxKI4agJDaZKEmcWIanYnTqtSjXmfaj8psEMOamnmx60RW/NELWbA/Jenek2R+6HFz/YayctGCGSXBL2d1Vgm54SM488KECVbOlqRdgidyTx58nF93U6oOoULPFJ28DXa3r5HczwUUF3A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=yv7KW5Wwm4Hia1oW6MlVGs+pvsoaPx39pBEuqEVNQoM=; b=AtUfXvw2zTYcJDc4+7iJcQrXmacuewA6uuPvFmINCp2Vh/gJ0immwjExcHMtq4sOu8xJN6XmAtJ1Gu48buEorIaeiKtSeE76T/hpyg0IwvRk8KtYVnNoZDB6AF9th3Y3+4zJoFb6o4u1yTNlqZniB2neKYYFy5ejW37hjZWhPCEVyfxYoICLuZGgoS0d7q1gtQByloPDpBl5O1SQAG3Dw+XunRZNM19hhgUlitIlhfXoJR7bWlAow2CSpRN2j0X3TMkXkSFob8kDw+am5gYE0toY7u+n/mI2avYJVNRUP38nfaIcoIfbYCha+P0HzqNrtfTWcjEnwnym6eCM6Pp4dQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=citrix.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yv7KW5Wwm4Hia1oW6MlVGs+pvsoaPx39pBEuqEVNQoM=; b=1/WUZaqlr4PgIVz+bUxAyjvYiRuRLMb8siG4WM+UPfe07RILp84ssIsxgk+G5McF7z4QtsquUt8ihK7Vb1n64BDVdomAueD6kFjyu80qMH72Y9NFQ6Km6mTGFQaHlbuOudsQWpg6YerLe5EbZgS0xoc5nwUNmxurHloHOSM2xBc= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C Message-ID: Date: Thu, 7 Mar 2024 12:33:17 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Jason Andryuk Subject: Re: [PATCH 0/3] x86/pvh: Support relocating dom0 kernel To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jan Beulich CC: , Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu References: <20240306185032.103216-1-jason.andryuk@amd.com> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: None (SATLEXMB03.amd.com: jason.andryuk@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BL02EPF0001A0FA:EE_|MW4PR12MB5604:EE_ X-MS-Office365-Filtering-Correlation-Id: adbf749f-0a5c-48a5-bac3-08dc3ecd46ae X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 5aN9+mw9Vt1HE8GmQ/hWZcYb95GpPyaY6SvgGwMJnq0kOnIk9lHzfIld7nMRL4z4ZOBz+WY9Ot42ZsTLv0dGixZl1TqZl4+r+y1R86MK/0xAX0RJubNx0kFrIoGh0720rt5FY5UNacjrZO9fpJhpLIyYyN7linQhJXJ44xZl0Y1JRAyt3GR2t2z/66kGPEdtkyjUxZ6tBS5Tj7RdTriIND4GoMB56V2Rm05EE2sY8Ep0DDmu2YB9maUmLm+uKdQO6RdiM9PXYxq0jJHz5vZGwwvU20wtezXLcOsV2Gv/NqeDAoDo88WWoYrGDNVUpWRYEGw88Vwt6/Lx1U4WoCA3e/lFJG6dG/zWoyp2eWLVtOMPikQLGOtMLnyNSDKEH8eWtMa+c8jynDbYKFztuCykvbKBEC5U/Qk3fezk0kgCf1SORQAx38ao8id1ylbia+OYLc++aaKT9m7H5LmqyNC+fvttyh79mo0DqC1xysjtYUqh8J6jW9k6tSHwYbphzzXBYCpQ/B3Sk85tnc3GiBMVpPFkAAjXXiDfnTsonsXSYhAkRvC6oMzqTw39Lmd0kKy76BNSjMbo2Oio+hO9F05oKun0zLdWOCQ7dBEakkatcNgwucVhsAm9ZcF+q6gYOs9BSdLrWQnlFWXcXKYKnJd1mmuixUvZWhhMwdrfzVGSE72vT2GY5Tp4tlNvKcDJ+6DX4ztHMOh8v/VWYJFDq/8hwz9y9X6o4MAILq/ImDz1GFfW+TbK1BCojnTBTDiZLc36 X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(36860700004)(376005)(82310400014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Mar 2024 17:37:35.4373 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: adbf749f-0a5c-48a5-bac3-08dc3ecd46ae X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BL02EPF0001A0FA.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR12MB5604 On 2024-03-07 05:20, Roger Pau Monné wrote: > On Thu, Mar 07, 2024 at 11:08:37AM +0100, Jan Beulich wrote: >> On 07.03.2024 11:00, Roger Pau Monné wrote: >>> On Wed, Mar 06, 2024 at 01:50:29PM -0500, Jason Andryuk wrote: >>>> Xen tries to load a PVH dom0 kernel at the fixed guest physical address >>>> from the elf headers. For Linux, this defaults to 0x1000000 (16MB), but >>>> it can be configured. >>>> >>>> Unfortunately there exist firmwares that have reserved regions at this >>>> address, so Xen fails to load the dom0 kernel since it's not RAM. >>>> >>>> The other issue is that the Linux PVH entry point is not >>>> position-independent. It expects to run at the compiled >>>> CONFIG_PHYSICAL_ADDRESS. >>>> >>>> This patch set expands the PVH dom0 builder to try to relocate the >>>> kernel if needed and possible. XENFEAT_pvh_relocatable is added for >>>> kernels to indicate they are relocatable. However, we may want to >>>> switch to an additional ELF note with the kernel alignment. Linux >>>> specifies a kernel alignment in the bzImage boot_params.setup_header, >>>> but that is not present the ELF vmlinux file. >>> >>> I wonder whether we need a pair of notes, to signal the min/max >>> addresses the kernel supports being relocated to. >> >> Plus, as per your other reply, a 3rd one to specify alignment needs. > > Alignment we could in theory get from the ELF program header, if OSes > fill those reliably. FreeBSD seems to do so, haven't checked Linux. I will look into this more, but at first glance, I don't see a connection between Linux's CONFIG_PHYSICAL_ALIGN and the values in the elf headers. As a quick test, I set CONFIG_PHYSICAL_ALIGN=0x800000, but the elf align values are still 0x200000. The elf header values may be a suitable fallback though? >> Then again - a single note can have multiple values. So perhaps it >> doesn't need to be more than one new notes (except if dealing with >> multi-value ones is deemed too complicated). > > I've never dealt with a multi-value note, if that's not overly > complicated I would be fine with it, otherwise multiple notes are OK > IMO. It looks like a single note can be followed by arbitrary data, so putting three values in should be fine. PVH is defined with a 32bit entry point, so are 32bit min, max & align values acceptable, or should 64bit be specified? Linux uses _ASM_PTR for PHYS32_ENTRY so its size matches the bitness of the target (32 on 32/ 64 on 64). I guess I'll follow that unless I hear a preference otherwise. Regards, Jason From xen-devel-bounces@lists.xenproject.org Thu Mar 07 17:39:13 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 17:39:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689992.1075582 (Exim 4.92) (envelope-from ) id 1riHi3-0007lJ-D2; Thu, 07 Mar 2024 17:39:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689992.1075582; Thu, 07 Mar 2024 17:39:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riHi3-0007lC-9f; Thu, 07 Mar 2024 17:39:11 +0000 Received: by outflank-mailman (input) for mailman id 689992; Thu, 07 Mar 2024 17:39:09 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riHi1-0007l4-8U for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 17:39:09 +0000 Received: from raptorengineering.com (mail.raptorengineering.com [23.155.224.40]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 9972c31a-dca9-11ee-afda-a90da7624cb6; Thu, 07 Mar 2024 18:39:08 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.rptsys.com (Postfix) with ESMTP id 4EB2582855A1; Thu, 7 Mar 2024 11:39:07 -0600 (CST) Received: from mail.rptsys.com ([127.0.0.1]) by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id iU8oE_TrQOe9; Thu, 7 Mar 2024 11:39:06 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by mail.rptsys.com (Postfix) with ESMTP id 664C182855B8; Thu, 7 Mar 2024 11:39:06 -0600 (CST) Received: from mail.rptsys.com ([127.0.0.1]) by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id AHE0EaSul25K; Thu, 7 Mar 2024 11:39:06 -0600 (CST) Received: from [10.11.0.3] (5.edge.rptsys.com [23.155.224.38]) by mail.rptsys.com (Postfix) with ESMTPSA id 3C4E982855A1; Thu, 7 Mar 2024 11:39:05 -0600 (CST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 9972c31a-dca9-11ee-afda-a90da7624cb6 DKIM-Filter: OpenDKIM Filter v2.10.3 mail.rptsys.com 664C182855B8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raptorengineering.com; s=B8E824E6-0BE2-11E6-931D-288C65937AAD; t=1709833146; bh=t954ueSKLgjWoEQM91mNNJKW3WH93MLRfcA0jU+Sols=; h=Message-ID:Date:MIME-Version:To:From; b=TCgErGr41Qc9s8UpCg+1Po7o4J+bgIBE1Yo5kJNwN5HeA/blVuzCU7HUQ+6CoX4cP yaPXjbWzGo+f+CMAYH0qntGiNF90qPndPUIoFI9ivX0jtz8eE8Ep1oknpQdJH9DsdY fZFrCJzh1aODBBiQRVOOxzeW9Hg+JITySChYd6aQ= X-Virus-Scanned: amavisd-new at rptsys.com Message-ID: Date: Thu, 7 Mar 2024 11:39:04 -0600 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v9 3/7] xen/asm-generic: ifdef inclusion of Content-Language: en-US To: Oleksii Kurochko , xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Tamas K Lengyel , Alexandru Isaila , Petre Pircalabu , Alistair Francis , Bob Eshleman , Connor Davis , Jan Beulich , Julien Grall References: From: Shawn Anastasio In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Oleksii, On 2/16/24 6:39 AM, Oleksii Kurochko wrote: > ifdefing inclusion of in > allows to avoid generation of empty header > for the case when !CONFIG_MEM_ACCESS. > > For Arm it was explicitly added inclusion of for p2m.c > and traps.c because they require some functions from which > aren't available in case of !CONFIG_MEM_ACCESS. > > Suggested-by: Jan Beulich > Signed-off-by: Oleksii Kurochko > Acked-by: Tamas K Lengyel > Acked-by: Julien Grall Acked-by: Shawn Anastasio Thanks, Shawn From xen-devel-bounces@lists.xenproject.org Thu Mar 07 17:42:41 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 17:42:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.689995.1075592 (Exim 4.92) (envelope-from ) id 1riHlM-0001Yy-R6; Thu, 07 Mar 2024 17:42:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 689995.1075592; Thu, 07 Mar 2024 17:42:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riHlM-0001Yr-OC; Thu, 07 Mar 2024 17:42:36 +0000 Received: by outflank-mailman (input) for mailman id 689995; Thu, 07 Mar 2024 17:42:36 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riHlM-0001Yl-EM for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 17:42:36 +0000 Received: from raptorengineering.com (mail.raptorengineering.com [23.155.224.40]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 146b957e-dcaa-11ee-a1ee-f123f15fe8a2; Thu, 07 Mar 2024 18:42:34 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.rptsys.com (Postfix) with ESMTP id 8537D82855A1; Thu, 7 Mar 2024 11:42:33 -0600 (CST) Received: from mail.rptsys.com ([127.0.0.1]) by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id mJxmg77ypgQS; Thu, 7 Mar 2024 11:42:33 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by mail.rptsys.com (Postfix) with ESMTP id EFF3882855B8; Thu, 7 Mar 2024 11:42:32 -0600 (CST) Received: from mail.rptsys.com ([127.0.0.1]) by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id fAOJl1r7LOu4; Thu, 7 Mar 2024 11:42:32 -0600 (CST) Received: from [10.11.0.3] (5.edge.rptsys.com [23.155.224.38]) by mail.rptsys.com (Postfix) with ESMTPSA id 91F1A82855A1; Thu, 7 Mar 2024 11:42:32 -0600 (CST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 146b957e-dcaa-11ee-a1ee-f123f15fe8a2 DKIM-Filter: OpenDKIM Filter v2.10.3 mail.rptsys.com EFF3882855B8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raptorengineering.com; s=B8E824E6-0BE2-11E6-931D-288C65937AAD; t=1709833353; bh=udLhNytx/iZirHQTMFoTliqlsufJ0/pYIaFsuxGAJRo=; h=Message-ID:Date:MIME-Version:To:From; b=jiAjiIKN9n8uJJ+BsHQ8e1upfBXet83CeuF21w5f7Q9NRICkg0iWUCltrLovf3/Sx T0mc3XMecCGPMBCSJFXKV0nDp4YIkVDS2cSsXxvgWxyIba/T4u3jiP0ctAG4x+rnJm 4MTflt/2ZX/ws0TnYGrZvU3x3JBiHrol1KnWTpWI= X-Virus-Scanned: amavisd-new at rptsys.com Message-ID: <8d602d68-b5d1-416d-b6b3-d9c0593e762c@raptorengineering.com> Date: Thu, 7 Mar 2024 11:42:31 -0600 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v9 6/7] xen/ppc: switch PPC to use asm-generic/device.h Content-Language: en-US To: Oleksii Kurochko , xen-devel@lists.xenproject.org References: <222ae66639312712e145bd04d5dd1ebd2c511d43.1708086092.git.oleksii.kurochko@gmail.com> From: Shawn Anastasio In-Reply-To: <222ae66639312712e145bd04d5dd1ebd2c511d43.1708086092.git.oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Oleksii, On 2/16/24 6:39 AM, Oleksii Kurochko wrote: > Signed-off-by: Oleksii Kurochko Acked-by: Shawn Anastasio Thanks, Shawn From xen-devel-bounces@lists.xenproject.org Thu Mar 07 17:47:23 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 17:47:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690001.1075602 (Exim 4.92) (envelope-from ) id 1riHpy-0002BA-Cn; Thu, 07 Mar 2024 17:47:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690001.1075602; Thu, 07 Mar 2024 17:47:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riHpy-0002B3-9f; Thu, 07 Mar 2024 17:47:22 +0000 Received: by outflank-mailman (input) for mailman id 690001; Thu, 07 Mar 2024 17:47:21 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riHpx-0002At-81; Thu, 07 Mar 2024 17:47:21 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riHpx-0000Al-5p; Thu, 07 Mar 2024 17:47:21 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riHpw-0005pS-PJ; Thu, 07 Mar 2024 17:47:20 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1riHpw-0001Ck-Om; Thu, 07 Mar 2024 17:47:20 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=/TBIHdg33pAtiWzrY9Z0zcbpJPBX1AiIZBepE2/jPB0=; b=5AggEBmThWLA99DsoUm1OCENtM QOWP/SusbRgZf+Q4Ai06/Qum0xcmeCVwglHawvDmxGcQIvhDqAZerZJLjFed0f9rhhxOz4m/7/V2V PQIDfNN38o3g6c06XdhGOK3MLuExfNupV0LO9MkHdWGNmXwJlQnv08pqAGj32XzgDalU=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 184932: tolerable all pass - PUSHED X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=90173fc5a2a826bbcabde22af405d0a617818b70 X-Osstest-Versions-That: xen=08bb338f09a54d3b39f0d952bbd67461d8e5d0ed From: osstest service owner Date: Thu, 07 Mar 2024 17:47:20 +0000 flight 184932 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/184932/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass version targeted for testing: xen 90173fc5a2a826bbcabde22af405d0a617818b70 baseline version: xen 08bb338f09a54d3b39f0d952bbd67461d8e5d0ed Last test of basis 184930 2024-03-07 09:02:12 Z 0 days Testing same since 184932 2024-03-07 15:02:11 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Anthony PERARD Henry Wang Juergen Gross 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-amd64 pass 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 08bb338f09..90173fc5a2 90173fc5a2a826bbcabde22af405d0a617818b70 -> smoke From xen-devel-bounces@lists.xenproject.org Thu Mar 07 18:12:09 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 18:12:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690010.1075612 (Exim 4.92) (envelope-from ) id 1riIDl-0008Dh-8h; Thu, 07 Mar 2024 18:11:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690010.1075612; Thu, 07 Mar 2024 18:11:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riIDl-0008Da-5x; Thu, 07 Mar 2024 18:11:57 +0000 Received: by outflank-mailman (input) for mailman id 690010; Thu, 07 Mar 2024 18:11:56 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riIDk-0008DU-MB for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 18:11:56 +0000 Received: from metis.whiteo.stw.pengutronix.de (metis.whiteo.stw.pengutronix.de [2a0a:edc0:2:b01:1d::104]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 2d9ab83e-dcae-11ee-a1ee-f123f15fe8a2; Thu, 07 Mar 2024 19:11:54 +0100 (CET) Received: from drehscheibe.grey.stw.pengutronix.de ([2a0a:edc0:0:c01:1d::a2]) by metis.whiteo.stw.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1riIDe-0000sq-J2; Thu, 07 Mar 2024 19:11:50 +0100 Received: from [2a0a:edc0:0:900:1d::77] (helo=ptz.office.stw.pengutronix.de) by drehscheibe.grey.stw.pengutronix.de with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1riIDc-004zYn-MH; Thu, 07 Mar 2024 19:11:48 +0100 Received: from ukl by ptz.office.stw.pengutronix.de with local (Exim 4.96) (envelope-from ) id 1riIDc-001Swq-1x; Thu, 07 Mar 2024 19:11:48 +0100 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 2d9ab83e-dcae-11ee-a1ee-f123f15fe8a2 From: =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?= To: Juergen Gross , Stefano Stabellini Cc: Oleksandr Tyshchenko , xen-devel@lists.xenproject.org, kernel@pengutronix.de Subject: [PATCH] xen/grant-dma-iommu: Convert to platform remove callback returning void Date: Thu, 7 Mar 2024 19:11:34 +0100 Message-ID: <20240307181135.191192-2-u.kleine-koenig@pengutronix.de> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Developer-Signature: v=1; a=openpgp-sha256; l=1877; i=u.kleine-koenig@pengutronix.de; h=from:subject; bh=El0UTdrAQowm1iKos5TD66q4tVWDQzk42DU65xvUqJ0=; b=owEBbQGS/pANAwAKAY+A+1h9Ev5OAcsmYgBl6gNX5w0OJDNnrwmDEvT8HL9x9bwCJYpiexfFN nbbgBrq9a6JATMEAAEKAB0WIQQ/gaxpOnoeWYmt/tOPgPtYfRL+TgUCZeoDVwAKCRCPgPtYfRL+ TqxxB/4xv6IDLtYa45vRFzwQlweSvr6J3Zkgcd/JmLTEZ331puT9srnr9mpWMRh2bHJreLv1lSF ObP0c2b0rv5bL7TRj041HwMUzHTbVwC0nluAoKMzxu1/G/pzUb2chq2zwZwCfRdvJDhDVcYnDo8 qcUZ+Q1nQlkvbFXuG7CxTJXvZhxfGuaiWDPM6ZiJKImavbQ2hCG85zhQJF51HqU2T4u8ULmr9PU +Ff2DNanFDbPMSd/3NQiPSA6X0ciw7ju5SsbcblmiBDRliCRWASJo0TAsqGGVhKwbv2V7HwHEwU Qaan9LCVP2H8q8JE4zOZJr4WnGfdvtiwkjnGN3ptreG+LHwT X-Developer-Key: i=u.kleine-koenig@pengutronix.de; a=openpgp; fpr=0D2511F322BFAB1C1580266BE2DCDD9132669BD6 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 2a0a:edc0:0:c01:1d::a2 X-SA-Exim-Mail-From: ukl@pengutronix.de X-SA-Exim-Scanned: No (on metis.whiteo.stw.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: xen-devel@lists.xenproject.org The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König --- drivers/xen/grant-dma-iommu.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/xen/grant-dma-iommu.c b/drivers/xen/grant-dma-iommu.c index 6a9fe02c6bfc..2ee750a03c2f 100644 --- a/drivers/xen/grant-dma-iommu.c +++ b/drivers/xen/grant-dma-iommu.c @@ -51,14 +51,12 @@ static int grant_dma_iommu_probe(struct platform_device *pdev) return 0; } -static int grant_dma_iommu_remove(struct platform_device *pdev) +static void grant_dma_iommu_remove(struct platform_device *pdev) { struct grant_dma_iommu_device *mmu = platform_get_drvdata(pdev); platform_set_drvdata(pdev, NULL); iommu_device_unregister(&mmu->iommu); - - return 0; } static struct platform_driver grant_dma_iommu_driver = { @@ -67,7 +65,7 @@ static struct platform_driver grant_dma_iommu_driver = { .of_match_table = grant_dma_iommu_of_match, }, .probe = grant_dma_iommu_probe, - .remove = grant_dma_iommu_remove, + .remove_new = grant_dma_iommu_remove, }; static int __init grant_dma_iommu_init(void) base-commit: 11afac187274a6177a7ac82997f8691c0f469e41 -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Thu Mar 07 19:43:54 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 19:43:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690019.1075623 (Exim 4.92) (envelope-from ) id 1riJeS-0005Yt-Lg; Thu, 07 Mar 2024 19:43:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690019.1075623; Thu, 07 Mar 2024 19:43:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riJeS-0005Ym-IX; Thu, 07 Mar 2024 19:43:36 +0000 Received: by outflank-mailman (input) for mailman id 690019; Thu, 07 Mar 2024 19:43:35 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riJeR-0005Ya-A4; Thu, 07 Mar 2024 19:43:35 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riJeR-0003Ao-45; Thu, 07 Mar 2024 19:43:35 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riJeQ-00032f-Tm; Thu, 07 Mar 2024 19:43:34 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1riJeQ-0000bk-TD; Thu, 07 Mar 2024 19:43:34 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=8aWzy0x6sjclOJqlpdLcoloMWM8VAx+zw+2tHlyeZ5U=; b=0chyM0NR+QE2s/I3zeoGcpgcPB PxZUnYwqH82gQD13kYFDiy2VQEHzckl7p3RxJRXofu42F2fz+5+mA4k3YKFv8RzcyetdbU9/t4bYa H3H9p8n2MjQ4yWN4t8XL5QMRueoq9CrWCoeXxSFOLLREsO1RlrjGBhQLreS236RJqFlI=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable test] 184927: tolerable FAIL - PUSHED X-Osstest-Failures: xen-unstable:test-amd64-i386-xl-qemut-debianhvm-amd64:guest-start/debianhvm.repeat:fail:heisenbug xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:windows-install:fail:heisenbug xen-unstable:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: xen=66c8e9b76c61ff52cfc0b186a38208907845d093 X-Osstest-Versions-That: xen=cd53ee9c41f991bbca75641e647005e013a3eac0 From: osstest service owner Date: Thu, 07 Mar 2024 19:43:34 +0000 flight 184927 xen-unstable real [real] flight 184939 xen-unstable real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/184927/ http://logs.test-lab.xenproject.org/osstest/logs/184939/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-i386-xl-qemut-debianhvm-amd64 20 guest-start/debianhvm.repeat fail pass in 184939-retest test-amd64-amd64-xl-qemuu-win7-amd64 12 windows-install fail pass in 184939-retest Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail blocked in 184919 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop fail in 184939 like 184919 test-armhf-armhf-libvirt 16 saverestore-support-check fail like 184919 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop fail like 184919 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 184919 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop fail like 184919 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 184919 test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail like 184919 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 184919 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop fail like 184919 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184919 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 184919 test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-check fail never pass test-amd64-i386-xl-pvshim 14 guest-start fail never pass test-amd64-i386-libvirt 15 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-check fail never pass test-arm64-arm64-xl 15 migrate-support-check fail never pass test-arm64-arm64-xl 16 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 15 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-check fail never pass test-armhf-armhf-libvirt 15 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-check fail never pass test-amd64-i386-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-check fail never pass test-arm64-arm64-xl-vhd 14 migrate-support-check fail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-check fail never pass version targeted for testing: xen 66c8e9b76c61ff52cfc0b186a38208907845d093 baseline version: xen cd53ee9c41f991bbca75641e647005e013a3eac0 Last test of basis 184919 2024-03-06 13:39:01 Z 1 days Testing same since 184927 2024-03-07 00:10:52 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Fouad Hilly Jan Beulich Jorge Martin Pritha Srivastava Shawn Anastasio jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-dom0pvh-xl-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 fail test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-qemuu-freebsd11-amd64 pass test-amd64-amd64-qemuu-freebsd12-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-examine-bios pass test-amd64-i386-examine-bios pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-dom0pvh-xl-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-armhf-armhf-libvirt-qcow2 pass test-amd64-amd64-xl-qcow2 pass test-arm64-arm64-libvirt-raw pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-libvirt-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-examine-uefi pass test-amd64-i386-examine-uefi pass test-amd64-amd64-libvirt-vhd pass test-arm64-arm64-xl-vhd pass test-armhf-armhf-xl-vhd pass test-amd64-i386-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these 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 cd53ee9c41..66c8e9b76c 66c8e9b76c61ff52cfc0b186a38208907845d093 -> master From xen-devel-bounces@lists.xenproject.org Thu Mar 07 20:31:24 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 20:31:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690029.1075644 (Exim 4.92) (envelope-from ) id 1riKOa-0004Zq-8p; Thu, 07 Mar 2024 20:31:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690029.1075644; Thu, 07 Mar 2024 20:31:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riKOa-0004Zj-6N; Thu, 07 Mar 2024 20:31:16 +0000 Received: by outflank-mailman (input) for mailman id 690029; Thu, 07 Mar 2024 20:31:15 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riKOZ-0004Zd-7Y for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 20:31:15 +0000 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id a197a177-dcc1-11ee-a1ee-f123f15fe8a2; Thu, 07 Mar 2024 21:31:11 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 2D1A3CE1F19; Thu, 7 Mar 2024 20:31:04 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B851DC43390; Thu, 7 Mar 2024 20:31:02 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a197a177-dcc1-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1709843463; bh=mUVcCyTLj0kXyQP9uUsYNjA19PfEYI17uNl1Kv1jVVo=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=gBu3vI9BxBP3g3bhI4yxTBaYAvPtV5UXh4YtK4t7N4L1NIg5cqdUnZoQI+rRhboky h/VQL/eHFUKrbTcoRlde1u22jKEXTZwidowjvmsuWmdF5xqRZxspQU+jnQfhpcUiTG lV1PT9FKcE8MXUmr2oJknSLrMgqqxPD7QxqL/rV+2ML6px5Uu6ldfSsIFQdc5XLS88 BbvlZZmMjt22Mpn7Z8f1CzZuH/qu4ZY76fBuHvUcV2KqNO5FIFVzTHTh0+zFqhgWnI ZpOlqzAiHHwiq9iiaDKabk1oHsQinfQMkg028A0zlVpa2wf4zKn2kXryGMgjKt9vpB 0drhPm2Gmv3Qg== Date: Thu, 7 Mar 2024 12:31:01 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Oleksii cc: xen-devel@lists.xenproject.org, Doug Goldstein , Stefano Stabellini , Michal Orzel Subject: Re: [PATCH v9 1/7] automation: introduce fixed randconfig for RISC-V In-Reply-To: <563cbcbf1bb4b540b858c187618969b75bd37481.camel@gmail.com> Message-ID: References: <563cbcbf1bb4b540b858c187618969b75bd37481.camel@gmail.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="8323329-90541720-1709843451=:853156" Content-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-90541720-1709843451=:853156 Content-Type: text/plain; CHARSET=UTF-8 Content-Transfer-Encoding: 8BIT Content-ID: On Thu, 7 Mar 2024, Oleksii wrote: > Hello Doug and Stefano, > > While Michal has reviewed this patch, I understand that I still need > your Acked-by. > > Could you please take a moment to review the patch? > > Thanks in advance. Acked-by: Stefano Stabellini > ~ Oleksii > > On Fri, 2024-02-16 at 13:39 +0100, Oleksii Kurochko wrote: > > This patch introduces the anchor riscv-fixed-randconfig, > > which includes all configurations that should be disabled for > > randconfig builds. > > > > Suggested-by: Stefano Stabellini > > Signed-off-by: Oleksii Kurochko > > --- > > The patch were introduced after discussion in a topic: > >   > > https://lore.kernel.org/xen-devel/cover.1701966261.git.oleksii.kurochko@gmail.com > > / > > --- > > Changes in V9: > >  - add '|' symbol after EXTRA_FIXED_RANDCONFIG to make variables in > > EXTRA_FIXED_RANDCONFIG > >    be separated by new line. > >  - instead of introduction of new file for riscv-fixed-randconfig, > > introduce an anchor > >    inside build.yaml > > --- > > Changes in V8: > >  - Nothing changed. Only rebase > > --- > > Changes in V7: > >  - Nothing changed. Only rebase > > --- > > Changes in V6: > >  - The patch was introduced in this version of patch series. > > --- > >  automation/gitlab-ci/build.yaml | 14 ++++++++++---- > >  1 file changed, 10 insertions(+), 4 deletions(-) > > > > diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab- > > ci/build.yaml > > index 6d2cb18b88..aac29ee13a 100644 > > --- a/automation/gitlab-ci/build.yaml > > +++ b/automation/gitlab-ci/build.yaml > > @@ -512,6 +512,14 @@ alpine-3.18-gcc-debug-arm64-boot-cpupools: > >        CONFIG_BOOT_TIME_CPUPOOLS=y > >   > >  # RISC-V 64 cross-build > > +.riscv-fixed-randconfig: > > +  variables: &riscv-fixed-randconfig > > +    EXTRA_FIXED_RANDCONFIG: | > > +      CONFIG_COVERAGE=n > > +      CONFIG_EXPERT=y > > +      CONFIG_GRANT_TABLE=n > > +      CONFIG_MEM_ACCESS=n > > + > >  archlinux-current-gcc-riscv64: > >    extends: .gcc-riscv64-cross-build > >    variables: > > @@ -532,8 +540,7 @@ archlinux-current-gcc-riscv64-randconfig: > >      CONTAINER: archlinux:current-riscv64 > >      KBUILD_DEFCONFIG: tiny64_defconfig > >      RANDCONFIG: y > > -    EXTRA_FIXED_RANDCONFIG: > > -      CONFIG_COVERAGE=n > > +    <<: *riscv-fixed-randconfig > >   > >  archlinux-current-gcc-riscv64-debug-randconfig: > >    extends: .gcc-riscv64-cross-build-debug > > @@ -541,8 +548,7 @@ archlinux-current-gcc-riscv64-debug-randconfig: > >      CONTAINER: archlinux:current-riscv64 > >      KBUILD_DEFCONFIG: tiny64_defconfig > >      RANDCONFIG: y > > -    EXTRA_FIXED_RANDCONFIG: > > -      CONFIG_COVERAGE=n > > +    <<: *riscv-fixed-randconfig > >   > >  # Power cross-build > >  debian-bullseye-gcc-ppc64le: > --8323329-90541720-1709843451=:853156-- From xen-devel-bounces@lists.xenproject.org Thu Mar 07 20:50:06 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 20:50:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690033.1075655 (Exim 4.92) (envelope-from ) id 1riKgb-00073i-Pc; Thu, 07 Mar 2024 20:49:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690033.1075655; Thu, 07 Mar 2024 20:49:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riKgb-00073b-Mb; Thu, 07 Mar 2024 20:49:53 +0000 Received: by outflank-mailman (input) for mailman id 690033; Thu, 07 Mar 2024 20:49:52 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riKga-00073V-EO for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 20:49:52 +0000 Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [2a00:1450:4864:20::636]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 3e1f257e-dcc4-11ee-afda-a90da7624cb6; Thu, 07 Mar 2024 21:49:51 +0100 (CET) Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-a4467d570cdso18181866b.3 for ; Thu, 07 Mar 2024 12:49:51 -0800 (PST) Received: from [192.168.206.239] ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id h20-20020a170906591400b00a3d5efc65e0sm8611857ejq.91.2024.03.07.12.49.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Mar 2024 12:49:49 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3e1f257e-dcc4-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709844590; x=1710449390; darn=lists.xenproject.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=DKY0/kjpyBwXqZPFaZC8zJg2HyVpPDaHzKDxYdT5r00=; b=j4wPxJOZ+HFpGtW7jH5xMFwRYUeZbqUz30GRoxUrilsbPjY3zUCn9XVT/aKo7InSIR j3NmrZlVsVy81v0kx4IhdhQAgcjLg4yRCij/nbQ9citIG0wzQJPB0u83hq45Cw3CpfcH 10rQfOki1upT9/FpdVTqOCIVi5Hk+2f1bX+Itbs0OZAcKXVthpgW/IZ1fk/XeAcnzyH1 6dXheynDq8lY5gPxwH+CDuwPTP0Dl56CDe1hUPEIBSuGzCYxRQ5wTD3jTmoilpJNMyTS Sf/m+Pg+aTuwJbt+6wG3Sk2XOhVWVznQiitd6f3EOXE4o8kD0yamWNfDa4dyReJsYwmp ervQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709844590; x=1710449390; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=DKY0/kjpyBwXqZPFaZC8zJg2HyVpPDaHzKDxYdT5r00=; b=QnyW1YcNFtT3jJU7XZ/hSd1ZnHmCki53ydgzkFuxBgxx3ach7NlRMbcqEE6jXocAGv lZb9yfVUvE476mAPtzCsSR7cLMX4xJfJ+d9Ld/Czewa7yPmX174mwDhRbi7ERMkR+CBF 6ba3Tf0N0gv8hyELaGaa3fMeNRGgXk3BCVWRnLMfO1f4B4fNW5Wk7OdxMoArvnMf0jN4 29VNK5ndx+/Xn94WuachymLaqIUsMoRmO80NC0dYuvDwtX2BEDMTlvx4a7Bpm7/YkvGP 0XjcQEe1RVssKF2Cr7ZvFH2JujgWdR4KSxErRho+2JkKOtIvwcwr8pn9jyNSuGzCqN/n UA7Q== X-Forwarded-Encrypted: i=1; AJvYcCUWBz9qrN9J5UG8HGf3JJ2GHadlhBHc7dZqHLebr5oYA9J9suhMtyp8tTgmSf5AnTH2Gdro6rht5doLB/i2E63b6lpjmVdPfJa1pNgci1U= X-Gm-Message-State: AOJu0Yy3rTjl3wJkAcrKOMhWyBVbo7eLPTkk/AMtEiXk/XroKTdlIRff /HX6dVvlZl/lGcfHsdHsuReyY8LMDn2fj4Cd7exyV6OYPVBwTpO8 X-Google-Smtp-Source: AGHT+IEakc2RD8id5JNyrpqEb+cESrJsM/f+7ocKWxnIzn97bNVuli84qqKH9iP5UBojjkIPSuH5SA== X-Received: by 2002:a17:906:685:b0:a44:fe70:1b82 with SMTP id u5-20020a170906068500b00a44fe701b82mr10075176ejb.8.1709844590235; Thu, 07 Mar 2024 12:49:50 -0800 (PST) Message-ID: <9ec718f3bba178d437035add3c7467011fc3ffc0.camel@gmail.com> Subject: Re: [PATCH v5 12/23] xen/riscv: introduce io.h From: Oleksii To: Jan Beulich Cc: Alistair Francis , Bob Eshleman , Connor Davis , Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu , xen-devel@lists.xenproject.org Date: Thu, 07 Mar 2024 21:49:49 +0100 In-Reply-To: References: <807c31d5-0c5a-4646-ba90-2f284289069f@suse.com> <2a3e49bf94332c17b50e4f0f745e4b28b16dceb1.camel@gmail.com> <2a05c233-b3c5-417c-bd6b-8b1c21f03c3d@suse.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.50.2 (3.50.2-1.fc39) MIME-Version: 1.0 On Thu, 2024-03-07 at 18:14 +0100, Jan Beulich wrote: > For plain writes it should at least be "=3DQo" then, yes. Constraints Q is a machine specific constraint, and I am not sure that it makes sense to use "=3Do" only and probably it is a reason why it is enough only "r". Does it make sense? > To me making those > input operands on Arm can't have been quite right. I don't understand why they both are input, logically it looks like an address should be an output. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Thu Mar 07 20:54:06 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 20:54:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690036.1075665 (Exim 4.92) (envelope-from ) id 1riKkg-0008VS-8z; Thu, 07 Mar 2024 20:54:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690036.1075665; Thu, 07 Mar 2024 20:54:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riKkg-0008VL-5R; Thu, 07 Mar 2024 20:54:06 +0000 Received: by outflank-mailman (input) for mailman id 690036; Thu, 07 Mar 2024 20:54:05 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riKkf-0008VF-2k for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 20:54:05 +0000 Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [2a00:1450:4864:20::231]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id d4fc3a95-dcc4-11ee-afda-a90da7624cb6; Thu, 07 Mar 2024 21:54:04 +0100 (CET) Received: by mail-lj1-x231.google.com with SMTP id 38308e7fff4ca-2d27184197cso17879571fa.1 for ; Thu, 07 Mar 2024 12:54:04 -0800 (PST) Received: from [192.168.206.239] ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id y20-20020a05651c155400b002d3fc4cf12fsm979387ljp.13.2024.03.07.12.54.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Mar 2024 12:54:03 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d4fc3a95-dcc4-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709844843; x=1710449643; darn=lists.xenproject.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=imm5FjPSdjM/H/Il0nN2XawdNAy51EuJsfA6i504/7o=; b=ZcbEDJH5ZkW9uUrWXxjlFEM8Zmvh9foeK8+Jeb25Htn03sUi5zA8tJ+Gz2AcDcJtIu EVg/f6+IBd3GVsq30x4H6WgrxH+oml5pk0y0C5VnKm0KDabAq0R7itu9C0DN7ozOcBfJ yLWu6FOHD71dBtDoh+XEyOxrqNf8WWXh9bZ2CglLXadazIUsXFyEMQH8xOgkTrSoXUXZ NU2byk1wocKnhuksTRPMZCGjX8bznXXRd2wSShW0KWnqfs6T8kI7ALpb9dn5dTYPujy3 tZGMv6PmFCaVnhVPtU9PnH4xp8+gfJIkVK12ffCxdeaLvCcxvuADXUvJWX/MmFquiGri Pfsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709844843; x=1710449643; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=imm5FjPSdjM/H/Il0nN2XawdNAy51EuJsfA6i504/7o=; b=l3ioSjecGpH+K0zWvIHH9jfYzRT2bXD/khnnRWIIBtXHgU+1xWx+g8b25IFfnzPPSH hizzr9GBbzs+SyADOUVf1X9zZJ3eKKQsBhnUh8uYHvENXy4mFwXcsdtfHQ6wXlU5G6iB +a+hszDOfTnAsuRwxsgBtflrG6ANptUAjJdpsHzS5PLd/FLK6CjL2C/H75/f9FTBfU2s Xj5xqnreQeGIzUlR/xWCM5+Eo/R7nh7aTQNlMxA4g1bkcPqnRieBwBiZZvs/Xdwgz0Mm eWtxzDopjt9KfS5XsGqNvKayOmohfivFG5IDx7lZKu1KCxvqu+zl2Uh2TQTndZNIk2e0 r0ow== X-Forwarded-Encrypted: i=1; AJvYcCUx+CO0ujuKETKKDK2K5KTyZw5kPfxa3MeNYsxOjni7IZvDP7ZNG17YrC3Wplgba/W4wNj7ZmYE8iMcCPgrBST+/pWrD1j26AUMDxkNuZc= X-Gm-Message-State: AOJu0YzR2RGAOyDdUnoxNatarfZRG43oHpXmH6b7qWEAEUHkjaHchcmN GNSAVNB6KjEIh/Tid3KL5Y6H7aOka1jaJVrJBZs0i1VaLWQIhjJc X-Google-Smtp-Source: AGHT+IF+qmH1hGbuPwPu8NWHRuqnXJjS+4b4+wAzJ0cSa+Dc17QEnUUN7ALIGXt1mVNQSa078Wqgww== X-Received: by 2002:a2e:b788:0:b0:2d3:6739:7e94 with SMTP id n8-20020a2eb788000000b002d367397e94mr2479689ljo.14.1709844843330; Thu, 07 Mar 2024 12:54:03 -0800 (PST) Message-ID: Subject: Re: [PATCH v5 12/23] xen/riscv: introduce io.h From: Oleksii To: Jan Beulich Cc: Alistair Francis , Bob Eshleman , Connor Davis , Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu , xen-devel@lists.xenproject.org Date: Thu, 07 Mar 2024 21:54:02 +0100 In-Reply-To: <9ec718f3bba178d437035add3c7467011fc3ffc0.camel@gmail.com> References: <807c31d5-0c5a-4646-ba90-2f284289069f@suse.com> <2a3e49bf94332c17b50e4f0f745e4b28b16dceb1.camel@gmail.com> <2a05c233-b3c5-417c-bd6b-8b1c21f03c3d@suse.com> <9ec718f3bba178d437035add3c7467011fc3ffc0.camel@gmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.50.2 (3.50.2-1.fc39) MIME-Version: 1.0 On Thu, 2024-03-07 at 21:49 +0100, Oleksii wrote: > On Thu, 2024-03-07 at 18:14 +0100, Jan Beulich wrote: > > For plain writes it should at least be "=3DQo" then, yes. > Constraints Q is a machine specific constraint, and I am not sure > that > it makes sense to use "=3Do" only and probably it is a reason why it is > enough only "r". Does it make sense? Probably for RISC-V can be used: RISC-V=E2=80=94config/riscv/constraints.md ... A An address that is held in a general-purpose register. ... AArch64 family=E2=80=94config/aarch64/constraints.md: ... Q A memory address which uses a single base register with no offset ... Also 'no offset' explains why it was added 'o' constraint for Arm additionally. ~ Oleksii >=20 > > =C2=A0To me making those > > input operands on Arm can't have been quite right. > I=C2=A0 don't understand why they both are input, logically it looks like > an > address should be an output. >=20 > ~ Oleksii >=20 From xen-devel-bounces@lists.xenproject.org Thu Mar 07 21:40:05 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 21:40:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690041.1075674 (Exim 4.92) (envelope-from ) id 1riLT4-0007iu-JA; Thu, 07 Mar 2024 21:39:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690041.1075674; Thu, 07 Mar 2024 21:39:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riLT4-0007in-Ft; Thu, 07 Mar 2024 21:39:58 +0000 Received: by outflank-mailman (input) for mailman id 690041; Thu, 07 Mar 2024 21:39:56 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riLT2-0007ic-PF for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 21:39:56 +0000 Received: from mail133-16.atl131.mandrillapp.com (mail133-16.atl131.mandrillapp.com [198.2.133.16]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 3bf7ea36-dccb-11ee-a1ee-f123f15fe8a2; Thu, 07 Mar 2024 22:39:54 +0100 (CET) Received: from pmta13.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail133-16.atl131.mandrillapp.com (Mailchimp) with ESMTP id 4TrN4S5HHszB5pBbs for ; Thu, 7 Mar 2024 21:39:52 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 69ea55a8c2a44cbeb47edb7fbc9fa4c8; Thu, 07 Mar 2024 21:39:52 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3bf7ea36-dccb-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1709847592; x=1710108092; bh=00POTxB1zrlLZFJpELQ2i438glsnk01REfkxGshruHk=; h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version: Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From; b=0t1yPr+gTkajgp+d5RPN4SN4xVHhJLj2x7A50fq0KSSYBuy/g9tZIOUzLaZM3vC+u LzX60VMHFodjs9ejZBUgJKKjfsDyYc9tMhUUlThrPGfSmMKOjZ2KYNKvTUIfNKUffM mITvTcSuNP1VEWw1LKxS10ylEBN6rGRwo1x8ycbkom6n42C4r0N1pEUBC1RcSSIsv/ dKZQCkwuyVkYxIILO+i+OuGn1wje+5PeodT6/cEiyRehThdmCajRyoP0UDHsU8+RJU Apv0bhY1unlqZXqIz1D3XIUywH7U7qn0BuvzSkWstuNx17rm6kGF9fQwryTld66fPE juNjjp0ss/7xA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1709847592; x=1710108092; i=vaishali.thakkar@vates.tech; bh=00POTxB1zrlLZFJpELQ2i438glsnk01REfkxGshruHk=; h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version: Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From; b=DfodxubCpJKq2jItGWrCVTAjsvoktQsh+C9CpYdD89dozI/kbPK/8P/3RMo2Im0MB BaZN9AQx3jq+nOV/vfR/AFsrFx68ZFpd6/d2irmYgoJR7u0S2O/vRigStLR1zS4xBu ze1YPWY04tc+B+x084qXah+mce89qMyyoI0tZlKHZZQPtSI/Nf4iWHcydkDRyGunie bOfzOTQKvdlMtBBrLP9P8FmQwr89TFNqsqQaXhzvGq1r2kWV4Hd2f2f9A+57+KE7vJ Ke1D/kRg6RJqlMbZhIdyCKg7vkqeRrQ9rxhtdGkSiETxj4/ehh6bcFWJNpT+PSNYgj gFwsSkAmAJ9jQ== From: Vaishali Thakkar Subject: =?utf-8?Q?[PATCH=200/2]=20x86/svm=20:=20Misc=20changes=20for=20few=20vmcb=20bits?= X-Mailer: git-send-email 2.44.0 X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1709847591479 To: xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger.pau@citrix.com, wl@xen.org, Vaishali Thakkar Message-Id: X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.69ea55a8c2a44cbeb47edb7fbc9fa4c8?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20240307:md Date: Thu, 07 Mar 2024 21:39:52 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, In this patchset, first patch removes the unnecessary suffix from a bunch of vmcb bits and the second patch is about printing the status of sev and sev-es bits while dumping VMCB. Vaishali Thakkar (2): x86/svm: Drop the _enabled suffix from vmcb bits x86/svmdebug: Print sev and sev_es vmcb bits xen/arch/x86/hvm/svm/nestedsvm.c | 14 +++++++------- xen/arch/x86/hvm/svm/svm.c | 2 +- xen/arch/x86/hvm/svm/svmdebug.c | 2 ++ xen/arch/x86/hvm/svm/vmcb.c | 2 +- xen/arch/x86/include/asm/hvm/svm/vmcb.h | 18 +++++++++--------- 5 files changed, 20 insertions(+), 18 deletions(-) -- 2.44.0 From xen-devel-bounces@lists.xenproject.org Thu Mar 07 21:40:07 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 21:40:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690042.1075685 (Exim 4.92) (envelope-from ) id 1riLTD-0000Q3-Qk; Thu, 07 Mar 2024 21:40:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690042.1075685; Thu, 07 Mar 2024 21:40:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riLTD-0000Pv-Ni; Thu, 07 Mar 2024 21:40:07 +0000 Received: by outflank-mailman (input) for mailman id 690042; Thu, 07 Mar 2024 21:40:06 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riLTC-0000KD-KF for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 21:40:06 +0000 Received: from mail133-16.atl131.mandrillapp.com (mail133-16.atl131.mandrillapp.com [198.2.133.16]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 41f7076b-dccb-11ee-afda-a90da7624cb6; Thu, 07 Mar 2024 22:40:04 +0100 (CET) Received: from pmta13.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail133-16.atl131.mandrillapp.com (Mailchimp) with ESMTP id 4TrN4g4M2JzB5pBbr for ; Thu, 7 Mar 2024 21:40:03 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 68cdb6bd0a584db49c51c55065d55838; Thu, 07 Mar 2024 21:40:03 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 41f7076b-dccb-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1709847603; x=1710108103; bh=cceUZwddrDnmNjiA/VLcSBuFRH5W1h6hq9ubKjkkGx4=; h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=Nf3vYPSabMg0FqmQ9PsDIBIIi/jF2P5Q7FaQbxA+0dejiS0mCe/SNTlRW6Dvfa9IP 4dK9/WLu6DqKNGcU+zJ4yaAHoxWi0I4XTxeKFO+Kk5x0xL2xkZY//AZrerOpvtVIkL OHaxAFY4uDGNTr9Zr7pBWGEXhJp/JspMCR5GV1ZhSoLyQbwKaupTtuCJH8SN96X30x Z19Nfo8vzqAX6Kped99IpgH69iK2u8Y/Q4K5l/YPI3t+lw6Y9P3qcAlUfB89xYEtFv HEi1YlC2l6E/YVPDhhj2QXeTJPvZHH32SjAloy1sPzsfCgSkAb0i31Van1K8nINocY NejYkgryOmpwA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1709847603; x=1710108103; i=vaishali.thakkar@vates.tech; bh=cceUZwddrDnmNjiA/VLcSBuFRH5W1h6hq9ubKjkkGx4=; h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=0cgekZOBujBqiZIDtmTYdTBGgVu+Z0SW5lnts6/DjQ0jw54OOdsZwkTBYJubhVRUr k1HZ/uFyQ9VPAW3Q6h1z50Kbi65WsfWWpM747HooKFadtlLvZiuby6+NSZKeiEfRBI VDST4VEjG6f+8TrOAisKBTORO9TlhPLkxMxegqgY1H1BAAAF8EJ/epT8m238SdBpUn BqUF6zRyuGfkHCvgqUgcl3l+QUGwxAit0Ab5Dxa/De7/sc8OrCSu/+dFXylqQM34hT YUO9M9H6cf4ggJ90UGRfb1OazZCcSUMdx9WkMNkaNNfid1sgQ5jhF+J9ygLeFOxfFk mR8407PdUiiWQ== From: Vaishali Thakkar Subject: =?utf-8?Q?[PATCH=201/2]=20x86/svm:=20Drop=20the=20=5Fenabled=20suffix=20from=20vmcb=20bits?= X-Mailer: git-send-email 2.44.0 X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1709847602167 To: xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger.pau@citrix.com, wl@xen.org, Vaishali Thakkar Message-Id: <3c419824febca229cedf2a3bd42cb68d3a3d56a8.1709846387.git.vaishali.thakkar@vates.tech> In-Reply-To: References: X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.68cdb6bd0a584db49c51c55065d55838?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20240307:md Date: Thu, 07 Mar 2024 21:40:03 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit The suffix is redundant for np/sev/sev-es bits. Drop it to avoid adding extra code volume. Suggested-by: Andrew Cooper Signed-off-by: Vaishali Thakkar i --- xen/arch/x86/hvm/svm/nestedsvm.c | 14 +++++++------- xen/arch/x86/hvm/svm/svm.c | 2 +- xen/arch/x86/hvm/svm/vmcb.c | 2 +- xen/arch/x86/include/asm/hvm/svm/vmcb.h | 18 +++++++++--------- 4 files changed, 18 insertions(+), 18 deletions(-) diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c index e4e01add8c..7e285cf85a 100644 --- a/xen/arch/x86/hvm/svm/nestedsvm.c +++ b/xen/arch/x86/hvm/svm/nestedsvm.c @@ -571,7 +571,7 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct cpu_user_regs *regs) if ( nestedhvm_paging_mode_hap(v) ) { /* host nested paging + guest nested paging. */ - n2vmcb->_np_enable = 1; + n2vmcb->_np = 1; nestedsvm_vmcb_set_nestedp2m(v, ns_vmcb, n2vmcb); @@ -585,7 +585,7 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct cpu_user_regs *regs) else if ( paging_mode_hap(v->domain) ) { /* host nested paging + guest shadow paging. */ - n2vmcb->_np_enable = 1; + n2vmcb->_np = 1; /* Keep h_cr3 as it is. */ n2vmcb->_h_cr3 = n1vmcb->_h_cr3; /* When l1 guest does shadow paging @@ -601,7 +601,7 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct cpu_user_regs *regs) else { /* host shadow paging + guest shadow paging. */ - n2vmcb->_np_enable = 0; + n2vmcb->_np = 0; n2vmcb->_h_cr3 = 0x0; /* TODO: Once shadow-shadow paging is in place come back to here @@ -706,7 +706,7 @@ nsvm_vcpu_vmentry(struct vcpu *v, struct cpu_user_regs *regs, } /* nested paging for the guest */ - svm->ns_hap_enabled = !!ns_vmcb->_np_enable; + svm->ns_hap_enabled = !!ns_vmcb->_np; /* Remember the V_INTR_MASK in hostflags */ svm->ns_hostflags.fields.vintrmask = !!ns_vmcb->_vintr.fields.intr_masking; @@ -1084,7 +1084,7 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs) if ( nestedhvm_paging_mode_hap(v) ) { /* host nested paging + guest nested paging. */ - ns_vmcb->_np_enable = n2vmcb->_np_enable; + ns_vmcb->_np = n2vmcb->_np; ns_vmcb->_cr3 = n2vmcb->_cr3; /* The vmcb->h_cr3 is the shadowed h_cr3. The original * unshadowed guest h_cr3 is kept in ns_vmcb->h_cr3, @@ -1093,7 +1093,7 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs) else if ( paging_mode_hap(v->domain) ) { /* host nested paging + guest shadow paging. */ - ns_vmcb->_np_enable = 0; + ns_vmcb->_np = 0; /* Throw h_cr3 away. Guest is not allowed to set it or * it can break out, otherwise (security hole!) */ ns_vmcb->_h_cr3 = 0x0; @@ -1104,7 +1104,7 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs) else { /* host shadow paging + guest shadow paging. */ - ns_vmcb->_np_enable = 0; + ns_vmcb->_np = 0; ns_vmcb->_h_cr3 = 0x0; /* The vmcb->_cr3 is the shadowed cr3. The original * unshadowed guest cr3 is kept in ns_vmcb->_cr3, diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c index b551eac807..1b38f6a494 100644 --- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c @@ -473,7 +473,7 @@ static int svm_vmcb_restore(struct vcpu *v, struct hvm_hw_cpu *c) if ( paging_mode_hap(v->domain) ) { - vmcb_set_np_enable(vmcb, 1); + vmcb_set_np(vmcb, 1); vmcb_set_g_pat(vmcb, MSR_IA32_CR_PAT_RESET /* guest PAT */); vmcb_set_h_cr3(vmcb, pagetable_get_paddr(p2m_get_pagetable(p2m))); } diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c index 282fe7cdbe..a8dd87ca36 100644 --- a/xen/arch/x86/hvm/svm/vmcb.c +++ b/xen/arch/x86/hvm/svm/vmcb.c @@ -133,7 +133,7 @@ static int construct_vmcb(struct vcpu *v) if ( paging_mode_hap(v->domain) ) { - vmcb->_np_enable = 1; /* enable nested paging */ + vmcb->_np = 1; /* enable nested paging */ vmcb->_g_pat = MSR_IA32_CR_PAT_RESET; /* guest PAT */ vmcb->_h_cr3 = pagetable_get_paddr( p2m_get_pagetable(p2m_get_hostp2m(v->domain))); diff --git a/xen/arch/x86/include/asm/hvm/svm/vmcb.h b/xen/arch/x86/include/asm/hvm/svm/vmcb.h index 91221ff4e2..76507576ba 100644 --- a/xen/arch/x86/include/asm/hvm/svm/vmcb.h +++ b/xen/arch/x86/include/asm/hvm/svm/vmcb.h @@ -473,12 +473,12 @@ struct vmcb_struct { intinfo_t exit_int_info; /* offset 0x88 */ union { /* offset 0x90 - cleanbit 4 */ struct { - bool _np_enable :1; - bool _sev_enable :1; - bool _sev_es_enable :1; - bool _gmet :1; - bool _np_sss :1; - bool _vte :1; + bool _np :1; + bool _sev :1; + bool _sev_es :1; + bool _gmet :1; + bool _np_sss :1; + bool _vte :1; }; uint64_t _np_ctrl; }; @@ -645,9 +645,9 @@ VMCB_ACCESSORS(msrpm_base_pa, iopm) VMCB_ACCESSORS(guest_asid, asid) VMCB_ACCESSORS(vintr, tpr) VMCB_ACCESSORS(np_ctrl, np) -VMCB_ACCESSORS_(np_enable, bool, np) -VMCB_ACCESSORS_(sev_enable, bool, np) -VMCB_ACCESSORS_(sev_es_enable, bool, np) +VMCB_ACCESSORS_(np, bool, np) +VMCB_ACCESSORS_(sev, bool, np) +VMCB_ACCESSORS_(sev_es, bool, np) VMCB_ACCESSORS_(gmet, bool, np) VMCB_ACCESSORS_(vte, bool, np) VMCB_ACCESSORS(h_cr3, np) -- 2.44.0 From xen-devel-bounces@lists.xenproject.org Thu Mar 07 21:40:10 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 21:40:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690043.1075694 (Exim 4.92) (envelope-from ) id 1riLTG-0000gG-5i; Thu, 07 Mar 2024 21:40:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690043.1075694; Thu, 07 Mar 2024 21:40:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riLTG-0000g5-2b; Thu, 07 Mar 2024 21:40:10 +0000 Received: by outflank-mailman (input) for mailman id 690043; Thu, 07 Mar 2024 21:40:09 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riLTF-0007ic-8w for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 21:40:09 +0000 Received: from mail137-23.atl71.mandrillapp.com (mail137-23.atl71.mandrillapp.com [198.2.137.23]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 43b9fe28-dccb-11ee-a1ee-f123f15fe8a2; Thu, 07 Mar 2024 22:40:07 +0100 (CET) Received: from pmta07.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail137-23.atl71.mandrillapp.com (Mailchimp) with ESMTP id 4TrN4k11pWz1XLPtB for ; Thu, 7 Mar 2024 21:40:06 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id c1048633bc104bee924125ad065e382c; Thu, 07 Mar 2024 21:40:06 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 43b9fe28-dccb-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1709847606; x=1710108106; bh=7ADkLZwRQhzXGdiUMxsI+/EhhIGWK2TxOmfDmaI2ACw=; h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=0GetQ7d6lW38OBwUVSvyZt9yQEsyz9rXkwWTsZLUyp84b/c1KMC/FQcjXhqoBQ6Ll CwV9RyVcNcdxpotFHBjCC+bsPXgd6CR39CZ6a/QO4xMH4Qv+4lCWyfEOZB5aeBfLJ2 VbtdXtT0kDSNApHgaXcskdf1E6qkMCn/S/LjQEDbqPXLQkqaHRZ3mnNpdlviBIUghK kJv33UFBCvdsUWYcQiDJfMz0Gk7JZMuZPvZOgaua9QgcomwKJ3njQSW7KLQS8mVfkS iGs//xPM4u3lxgdPgVjnOCZpxpRnWzyuDsyzSfIVvA8vMIJP+wvq+A7dnU5sayX+yB J4l23Mz2Cxh2w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1709847606; x=1710108106; i=vaishali.thakkar@vates.tech; bh=7ADkLZwRQhzXGdiUMxsI+/EhhIGWK2TxOmfDmaI2ACw=; h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=jQ3WujnoCVAehDD1VLmYo8HHamcpEDGQlijkuNavf7h7n795XsAGUWwaL9YDgOIvG 1GD3jd4lK10QUnAV3XOdPyg5DbzruNKWg15PUzflc3lIlEoGbCSznQa2/3WvdMbG93 sMtRw9ZYWCF4J/SDAw3gGrvpGtwMeKpfeqqkO3iwnOnFo9VmIXyIY446K+MqmwzJ45 X6AgzGVBKlbgNPh4xHfhwlp4cIq2DgiRI6Zt9hQUQK+p9kb5Y7nW/+2LHk3wkxBGkE XWhrL2yVyxQu+8d5LcB7IGd3YSjieCRzvB3MDGIhlENBBM2fkU66Ilxbjr8Rue/SOX hHypLFOFziK8Q== From: Vaishali Thakkar Subject: =?utf-8?Q?[PATCH=202/2]=20x86/svmdebug:=20Print=20sev=20and=20sev=5Fes=20vmcb=20bits?= X-Mailer: git-send-email 2.44.0 X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1709847604792 To: xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger.pau@citrix.com, wl@xen.org, Vaishali Thakkar Message-Id: <9cc6b407ec3b45f034b7deb6f5f44a561eecca47.1709846387.git.vaishali.thakkar@vates.tech> In-Reply-To: References: X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.c1048633bc104bee924125ad065e382c?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20240307:md Date: Thu, 07 Mar 2024 21:40:06 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit While sev and sev_es bits are not yet enabled in xen, including their status in the VMCB dump could be informational.Therefore, print it via svmdebug. Signed-off-by: Vaishali Thakkar --- JFYI, we'll send the follow-up patches with the enablement of sev and ASP driver. --- xen/arch/x86/hvm/svm/svmdebug.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/xen/arch/x86/hvm/svm/svmdebug.c b/xen/arch/x86/hvm/svm/svmdebug.c index 24358c6eea..f54b426fb3 100644 --- a/xen/arch/x86/hvm/svm/svmdebug.c +++ b/xen/arch/x86/hvm/svm/svmdebug.c @@ -53,6 +53,8 @@ void svm_vmcb_dump(const char *from, const struct vmcb_struct *vmcb) vmcb->exitinfo1, vmcb->exitinfo2); printk("np_ctrl = %#"PRIx64" guest_asid = %#x\n", vmcb_get_np_ctrl(vmcb), vmcb_get_guest_asid(vmcb)); + printk("sev = %d sev_es = %d\n", + vmcb_get_sev(vmcb), vmcb_get_sev_es(vmcb)); printk("virtual vmload/vmsave = %d, virt_ext = %#"PRIx64"\n", vmcb->virt_ext.fields.vloadsave_enable, vmcb->virt_ext.bytes); printk("cpl = %d efer = %#"PRIx64" star = %#"PRIx64" lstar = %#"PRIx64"\n", -- 2.44.0 From xen-devel-bounces@lists.xenproject.org Thu Mar 07 22:15:21 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 22:15:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690056.1075706 (Exim 4.92) (envelope-from ) id 1riM14-0008C7-N7; Thu, 07 Mar 2024 22:15:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690056.1075706; Thu, 07 Mar 2024 22:15:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riM14-0008C0-IY; Thu, 07 Mar 2024 22:15:06 +0000 Received: by outflank-mailman (input) for mailman id 690056; Thu, 07 Mar 2024 22:15:05 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riM13-0008BZ-F8 for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 22:15:05 +0000 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 251b167d-dcd0-11ee-a1ee-f123f15fe8a2; Thu, 07 Mar 2024 23:15:03 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 78D8861D4C; Thu, 7 Mar 2024 22:15:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8E3B1C433C7; Thu, 7 Mar 2024 22:15:01 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 251b167d-dcd0-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1709849702; bh=ImqCRmQ0LNYndfa/qXhGMKDnHDvm3W+hzBKcpcvdFb4=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=kEc/AU6tdERsft279aFt2X6a/R8McrOuX3o4rngLNLRyCbnyxxMS8vteGHPRvNxiI 3CnOHklwy2Pofn2mGucXmlmTj7zUHGy5s26UPx7QFqkMiMs1QelRB3DvpH+6AnrrHW QrKxkQkxqJwZRVkgM3ri5hqoTi3gnGCBeQ5/ijb7+j+8DupVDIi4VbT/YglUDFyWQg JUdW+x48mNMtsg4xgeYrnusrU/ToeJuP77MO5EZXhbzD5Dw2jQfZUoZBP+WP1+276Q KE7e185toxbhC0eGm0voMfvatc5hhzNCbOX/ZGcZRA1NtvwLqHmKcnNbCd7bsBesDn V/Px3aObX+uTQ== Date: Thu, 7 Mar 2024 14:15:00 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Roger Pau Monne cc: xen-devel@lists.xenproject.org, Doug Goldstein , Stefano Stabellini Subject: Re: [PATCH 2/2] automation: introduce non debug clang based tests In-Reply-To: <20240229095529.17723-3-roger.pau@citrix.com> Message-ID: References: <20240229095529.17723-1-roger.pau@citrix.com> <20240229095529.17723-3-roger.pau@citrix.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323329-187522848-1709849702=:853156" This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-187522848-1709849702=:853156 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Thu, 29 Feb 2024, Roger Pau Monne wrote: > The generated code between the debug and release builds can be quite > different, as a note 2ce562b2a413 only manifested in non-debug builds due to > the usage of -O2. > > Duplicate the clang based test in order to test with both debug and non-debug > Xen builds. > > Signed-off-by: Roger Pau Monné Reviewed-by: Stefano Stabellini --8323329-187522848-1709849702=:853156-- From xen-devel-bounces@lists.xenproject.org Thu Mar 07 23:23:06 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 23:23:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690062.1075715 (Exim 4.92) (envelope-from ) id 1riN4d-0005Cn-Cj; Thu, 07 Mar 2024 23:22:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690062.1075715; Thu, 07 Mar 2024 23:22:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riN4d-0005Cg-A6; Thu, 07 Mar 2024 23:22:51 +0000 Received: by outflank-mailman (input) for mailman id 690062; Thu, 07 Mar 2024 23:22:50 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riN4c-0005CT-Bp for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 23:22:50 +0000 Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [2a00:1450:4864:20::32e]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 9b6960ea-dcd9-11ee-a1ee-f123f15fe8a2; Fri, 08 Mar 2024 00:22:47 +0100 (CET) Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-413131d40f4so2135205e9.3 for ; Thu, 07 Mar 2024 15:22:47 -0800 (PST) Received: from [192.168.86.29] ([83.104.235.82]) by smtp.gmail.com with ESMTPSA id y24-20020a05600c341800b00412f6f4dea4sm3901363wmp.41.2024.03.07.15.22.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Mar 2024 15:22:45 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 9b6960ea-dcd9-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709853766; x=1710458566; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=Ex4/icQFidJpYIkE03Yk5gfU4TXdYqbRCh9cL/On5yw=; b=KRTWRPbKbXeg0P1e+88hVExKPHY7F1Zfg9QeQaXzq+8hwOXyBKBW1BP2tYy5aTPFiR T8jwqK8mGcDWtSngRRMGA1E51nmileIaRkrC9WUehCAh4tQoy0SY1IpxMaLHfTf3SHVM NBXDxcZqOgTFvjl5/odrPEwtaY2Yxp2G/3Kvc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709853766; x=1710458566; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Ex4/icQFidJpYIkE03Yk5gfU4TXdYqbRCh9cL/On5yw=; b=TafA2EFm8rY/lpXP8qt2pWxURh5QCgHlNgCcU/alnrhqPdYYsVtVTYaO8t0DIxyErP phzz+qI2x4sdYDRxY1ZGvDjWKkJG3+yUcOkxucAOLshM5C2oJQSmY0pKZprzY5cVODty zonuz0XvveQlWqqXI/hP24xONTTcZ0dIxWJR0Ek2bA/qt/i0IA/9DRxIuFEai4KdDgWt 4yNHKl+nS3gS48DxPhdH3tiJySVmUAa468wNle7mgp1wrEAXKgN3AIXq2uT9YKMkVwQW +Ku+v16OV24a0Grkerw7gFq4WPPjgjFT4rvaPK2ZR6oP4xrnRkFTBbE5NzvSI1QKlo7P rVcw== X-Forwarded-Encrypted: i=1; AJvYcCW+xyjk+WkTf3BwVl/0enSy/xouL29RtDhhwhegjTVODICqdL3/E5oUMYPMZoziZgUXI/2QIsnFTW/oQSAn5iXxc55GkfJB+z1LYT2zkPg= X-Gm-Message-State: AOJu0YyFUZfCPmPfncq/WeJ75qkAEEElXBQ+jO/uTlctJm2ZaC+55h78 pEySe42nNVbMJEwDpw9GRAP3m+fdfvWMa94xpVCMJTcEqx4yEXrkctJsZc9PzLo= X-Google-Smtp-Source: AGHT+IFZUEYyiKHjj7IZb9ZbXpLPMXE8UTH/cW5RfvQq+gIh7tmbnBD909WrSTnRhGSfds8kxazd2Q== X-Received: by 2002:a05:600c:4ed2:b0:412:b674:28ff with SMTP id g18-20020a05600c4ed200b00412b67428ffmr14664570wmq.22.1709853766416; Thu, 07 Mar 2024 15:22:46 -0800 (PST) Message-ID: Date: Thu, 7 Mar 2024 23:22:45 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] x86/svm: Drop the _enabled suffix from vmcb bits Content-Language: en-GB To: Vaishali Thakkar , xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, roger.pau@citrix.com, wl@xen.org References: <3c419824febca229cedf2a3bd42cb68d3a3d56a8.1709846387.git.vaishali.thakkar@vates.tech> From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <3c419824febca229cedf2a3bd42cb68d3a3d56a8.1709846387.git.vaishali.thakkar@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 07/03/2024 9:40 pm, Vaishali Thakkar wrote: > The suffix is redundant for np/sev/sev-es bits. Drop it > to avoid adding extra code volume. > > Suggested-by: Andrew Cooper > Signed-off-by: Vaishali Thakkar i Typo on the end of your email address? > diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c > index e4e01add8c..7e285cf85a 100644 > --- a/xen/arch/x86/hvm/svm/nestedsvm.c > +++ b/xen/arch/x86/hvm/svm/nestedsvm.c > @@ -706,7 +706,7 @@ nsvm_vcpu_vmentry(struct vcpu *v, struct cpu_user_regs *regs, > } > > /* nested paging for the guest */ > - svm->ns_hap_enabled = !!ns_vmcb->_np_enable; > + svm->ns_hap_enabled = !!ns_vmcb->_np; Because the type of is bool, the !! can be dropped too while changing this line. It seems that this was missing cleanup from f57ae00635 "SVM: split _np_enable VMCB field". Anyway, Reviewed-by: Andrew Cooper and I'm happy to fix on commit. From xen-devel-bounces@lists.xenproject.org Thu Mar 07 23:35:03 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2024 23:35:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690066.1075725 (Exim 4.92) (envelope-from ) id 1riNGN-0007mT-Dg; Thu, 07 Mar 2024 23:34:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690066.1075725; Thu, 07 Mar 2024 23:34:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riNGN-0007mM-Az; Thu, 07 Mar 2024 23:34:59 +0000 Received: by outflank-mailman (input) for mailman id 690066; Thu, 07 Mar 2024 23:34:58 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riNGM-0007mC-7p for xen-devel@lists.xenproject.org; Thu, 07 Mar 2024 23:34:58 +0000 Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [2a00:1450:4864:20::331]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 4eb2b697-dcdb-11ee-afda-a90da7624cb6; Fri, 08 Mar 2024 00:34:57 +0100 (CET) Received: by mail-wm1-x331.google.com with SMTP id 5b1f17b1804b1-413161dae46so4488755e9.3 for ; Thu, 07 Mar 2024 15:34:57 -0800 (PST) Received: from [192.168.86.29] ([83.104.235.82]) by smtp.gmail.com with ESMTPSA id bq26-20020a5d5a1a000000b0033e2777f313sm16689938wrb.72.2024.03.07.15.34.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Mar 2024 15:34:56 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 4eb2b697-dcdb-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709854497; x=1710459297; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=m+77g2/BzW4D6dQgLN0/JFcef5gXJ4V23qaqh5TBrxg=; b=eMl2W1PhlLyeW6e+9/ZxvlIzQvkooou8mN1moQTurd1w3Lg7OCFKti7Ieag5Ux1AV7 B3Zp/MK5y8XP8+aZoljh1LFVOxNNRrghZSfSFkqbiu1Bo4Oq6T24CVG9g+I9aH4D1bCl 0zK371DOwM3rCRlqx0tu0cCNwErKybrgrFCnQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709854497; x=1710459297; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=m+77g2/BzW4D6dQgLN0/JFcef5gXJ4V23qaqh5TBrxg=; b=UxYFcGyLi5Ju5kciPtWD9nDQ10yh/CHz/f/ha+sxPlVgvNmPntmszvpgE6cCPH89rZ ZSe0eJff6ImO3aXQwTBsTcwRJIw2RHKb4hx5IYJrBjW8fk1nqSULD8WaipB2Bc7p/dj/ k9jYyixqj4aciiY7fqTcchR2x78v5s0POs9MyhOgHqyV1MFIubozoGAQiUK3AmPhMi+L YT+P2R6jZgMJaGEOKBzX0oQwL/Z4hfDobnd/CrWyM5xYtARSD7vt6Vl8RTnjn+16BIYG yam1e9S4M8CbjFyEP69YfNc0iDWZ/8ApkGW4GTHjEqb2PY5qY5UeMqLJc8127T3cANcB 2ZSw== X-Forwarded-Encrypted: i=1; AJvYcCVw1Rte9benVMUzwDboP1C2TKlKQuKj64GQ/kJkXdwsTQVaevvaYjwDEh07tQP15NyFGlbYbQu3MD7HKq1GoQgxFlc/6lkUgh/JZbcq0TI= X-Gm-Message-State: AOJu0Yy+Yi1HHXVU5z52fS1aY7QMGWPryusskrKwZMNHXofqfR6YPG28 T4Eun5I2pP8f7DIm+Oxp5ulzd24gdEEjEtXxKEO3UDqykoIxaP6LFWe+GV3Smr0= X-Google-Smtp-Source: AGHT+IGrGKQWuMQ4tPH6GIWCn/tTFolVkrBDaH68V6+6u877hjgNd+60aaXsGBE0OzaZEaMasMfkuQ== X-Received: by 2002:a5d:4144:0:b0:33d:d2bc:bf41 with SMTP id c4-20020a5d4144000000b0033dd2bcbf41mr13795897wrq.31.1709854496721; Thu, 07 Mar 2024 15:34:56 -0800 (PST) Message-ID: <715771bb-bff4-46d7-82b0-d0ad6d7a33ae@citrix.com> Date: Thu, 7 Mar 2024 23:34:55 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/2] x86/svmdebug: Print sev and sev_es vmcb bits Content-Language: en-GB To: Vaishali Thakkar , xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, roger.pau@citrix.com, wl@xen.org References: <9cc6b407ec3b45f034b7deb6f5f44a561eecca47.1709846387.git.vaishali.thakkar@vates.tech> From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <9cc6b407ec3b45f034b7deb6f5f44a561eecca47.1709846387.git.vaishali.thakkar@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 07/03/2024 9:40 pm, Vaishali Thakkar wrote: > diff --git a/xen/arch/x86/hvm/svm/svmdebug.c b/xen/arch/x86/hvm/svm/svmdebug.c > index 24358c6eea..f54b426fb3 100644 > --- a/xen/arch/x86/hvm/svm/svmdebug.c > +++ b/xen/arch/x86/hvm/svm/svmdebug.c > @@ -53,6 +53,8 @@ void svm_vmcb_dump(const char *from, const struct vmcb_struct *vmcb) > vmcb->exitinfo1, vmcb->exitinfo2); > printk("np_ctrl = %#"PRIx64" guest_asid = %#x\n", > vmcb_get_np_ctrl(vmcb), vmcb_get_guest_asid(vmcb)); > + printk("sev = %d sev_es = %d\n", > + vmcb_get_sev(vmcb), vmcb_get_sev_es(vmcb)); Hmm.  These are covered by the previous line printing all of np_ctrl.  What about rearranging the previous line to be something like: printk("asid: %#x, np_ctrl: %#"PRIx64" -%s%s%s\n",     vmcb->_asid, vmcb->_np_ctrl,     vmcb->_np ? " NP" : "",     vmcb->_sev ? " SEV" : "",     ...); This is more compact (things like "guest" in "guest asid" is entirely redundant), and provides both the raw _np_ctrl field and a bit-by-bit decode on the same line, rather than having different parts of the info on different lines and bools written out in longhand? See xen/arch/x86/spec_ctrl.c: print_details() for a rather more complete example of this style of printk() rendering for bits, including how to tabulate it for better readability. ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Mar 08 01:55:02 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2024 01:55:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690077.1075755 (Exim 4.92) (envelope-from ) id 1riPRs-0002bu-72; Fri, 08 Mar 2024 01:55:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690077.1075755; Fri, 08 Mar 2024 01:55:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riPRs-0002bl-3x; Fri, 08 Mar 2024 01:55:00 +0000 Received: by outflank-mailman (input) for mailman id 690077; Fri, 08 Mar 2024 01:54:58 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riPRq-0002aR-DV for xen-devel@lists.xenproject.org; Fri, 08 Mar 2024 01:54:58 +0000 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on20601.outbound.protection.outlook.com [2a01:111:f403:200a::601]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id dd69a49a-dcee-11ee-afda-a90da7624cb6; Fri, 08 Mar 2024 02:54:57 +0100 (CET) Received: from CH0PR03CA0057.namprd03.prod.outlook.com (2603:10b6:610:b3::32) by LV2PR12MB5944.namprd12.prod.outlook.com (2603:10b6:408:14f::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.26; Fri, 8 Mar 2024 01:54:53 +0000 Received: from CH3PEPF00000009.namprd04.prod.outlook.com (2603:10b6:610:b3:cafe::83) by CH0PR03CA0057.outlook.office365.com (2603:10b6:610:b3::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7339.37 via Frontend Transport; Fri, 8 Mar 2024 01:54:53 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by CH3PEPF00000009.mail.protection.outlook.com (10.167.244.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7362.11 via Frontend Transport; Fri, 8 Mar 2024 01:54:52 +0000 Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 7 Mar 2024 19:54:51 -0600 Received: from henry-MS-7D54.amd.com (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend Transport; Thu, 7 Mar 2024 19:54:48 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: dd69a49a-dcee-11ee-afda-a90da7624cb6 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GSs6ZcY4ffWJ1SQDXMRasVmV/zSNHo7EaKF/09azEe7oYUggQnqd1cZUL4iSQcoKRP40SUZsNks1hNOncxJtXZv7pM62himqUOtEALk7mcBVysjpDPasdvFBMbtIDP7Rga64nZEbjFJC9uzTuv43WoOXgatCzDesbVzS1x7g9jxixfeBAZXhvw0QHIimZ0+kst/AD+I+SetOOTTqpbxL/ChfIEfZQZ3ZQ69pLUl6IlhLL2p/bG7dQi0bGCj1/5f4fYOMM/cvwTevCGIsluOL2pBHvFtzneQPpp+ssza+SweQvElqirrGLQ/3x3RWT6yFMpdDhkJimyY8XZnG/Hvq/A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=jTrQweeqJ5wfSQ1EelNhRROTV7nnkDh3tQqIf7Bk5jk=; b=ZK+zljpj6ZIthlzADNJbbkaTcBGBTpgEwqgME+dVn2b3SG1vze20wwAZa66cthI9eHiUcBCSVvvLXXvCDuq9AMKaqkvQroJVhuq14KTwAm/HeyVpts8g5BgoFCAea1vQZJt3MyI6IaJhsZ1cmfBoErAs8jF2PCcfY9JiqbLCwpClatLmxj+2OjTM+yzgsWYFcDaydrjtyPiL9nBeRB0SaU9BCC7FS5HZtsEnplLIAkcB3WjGxbBP9UvwaX+bTp00gR/GkRECH9jFlrgSQPaN0uPTEXzYy3/q+hajVjQEKlcq1MDXmh5pAvlqK6dExOKf3+ACBCtWjYQVcWDP7tTolw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jTrQweeqJ5wfSQ1EelNhRROTV7nnkDh3tQqIf7Bk5jk=; b=VeCQykNFOg29ITZ3pXoS1YURxh6H91pI89/X2qSPnw27RvnqmATj6hYk3YHpD5c1fJSEbL4oeaW7FuA3cSVZKwXtCOLVtMW6rgBjd8VKAO/8o8IL6LOBMMpQouhUCAtNNRJ6p2uyrKCBTyaRLUwRsmHu6bUjVNWg4SHU5b4UsnI= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C From: Henry Wang To: CC: Henry Wang , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , "Volodymyr Babchuk" , Andrew Cooper , George Dunlap , "Jan Beulich" , Wei Liu , Shawn Anastasio , Alistair Francis , Bob Eshleman , "Connor Davis" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH v2 2/5] xen/domain.h: Centrialize is_domain_direct_mapped() Date: Fri, 8 Mar 2024 09:54:32 +0800 Message-ID: <20240308015435.4044339-3-xin.wang2@amd.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240308015435.4044339-1-xin.wang2@amd.com> References: <20240308015435.4044339-1-xin.wang2@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain Received-SPF: None (SATLEXMB04.amd.com: xin.wang2@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH3PEPF00000009:EE_|LV2PR12MB5944:EE_ X-MS-Office365-Filtering-Correlation-Id: b2327975-6b70-4fb4-6436-08dc3f12bf00 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 2uhOvfvapcZUJ6UsU8iuObgLlp7sB0bdDo3yY7b+0LOckNzr87hHHmp7GWKdmjm96bpfj8ygM3gRqOsCv5jhrkc9TPnYYE+MIeWwXtz5GkX3SyK0xyNZcP2aLEJ6DsfQWj3Z+2vZ9dj2Zqpd1tmvMbCeZWXYGZ05q5I5bSaDOKSg3inv7RWDUMA1jGh3nhDhseLq1mGgu+KG5M31pu+MR6NXCbKeNA2jHbQwLNKj3DZYr1E4VvnqAkjzPCYFawfodtYVkMv3hdunUnSy189KCUDamV5QlgpdiVSJ89LWEHc4+xA1vQBsr17LUObIDZoyWtg/AjsaVmq2Y+oMIlH1IfSSx1CiTOAXSs1ZV5jBhni1g+SxKOUH1f0OmEvdqBA+VjTtccLZyGqK4NHjlWAIXSRQsDCCOlwqYIyarqvudTwXyI0cOVE7UWTRRCmYDunjZa3sTMJrgriZBmUdBRPT1bblI1TlB6eD99UfFrtTtZy3XDLSke6Yo0jHtR4m7hYlxtM1xZaVKTJgkW4oRRh0pNkGJfUN1QtjTLONP/0uJaRCbso37tXV6e9gSzWPWVNVVUuLki5IeUMW4ES5jemnN32u0bVUsoF+4Q03SC9wptc32IRxBk64WOg2gr2ZK+ZtyJv1E6mQuUV2zh84Cbd36plvd0J3YfqcB3w5WSlj36RS3OpkvVH/XUQgMvxQWqgnm19/QlOjVayRWv9O1kZBYIN5hXFH39oNWqhITjqSDCV8OS6zX/PPXJ6Uffzdvii5 X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(1800799015)(7416005)(376005)(36860700004)(82310400014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Mar 2024 01:54:52.5577 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b2327975-6b70-4fb4-6436-08dc3f12bf00 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CH3PEPF00000009.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV2PR12MB5944 Currently direct mapped domain is only supported by the Arm architecture at the domain creation time by setting the CDF_directmap flag. There is not a need for every non-Arm architecture, i.e. x86, RISC-V and PPC, to define a stub is_domain_direct_mapped() in arch header. Move is_domain_direct_mapped() to a centralized place at xen/domain.h and evaluate CDF_directmap for non-Arm architecture to 0. Signed-off-by: Henry Wang --- v2: - New patch --- xen/arch/arm/include/asm/domain.h | 2 -- xen/arch/ppc/include/asm/domain.h | 2 -- xen/arch/riscv/include/asm/domain.h | 2 -- xen/arch/x86/include/asm/domain.h | 1 - xen/include/xen/domain.h | 3 +++ 5 files changed, 3 insertions(+), 7 deletions(-) diff --git a/xen/arch/arm/include/asm/domain.h b/xen/arch/arm/include/asm/domain.h index 8218afb862..f1d72c6e48 100644 --- a/xen/arch/arm/include/asm/domain.h +++ b/xen/arch/arm/include/asm/domain.h @@ -29,8 +29,6 @@ enum domain_type { #define is_64bit_domain(d) (0) #endif -#define is_domain_direct_mapped(d) ((d)->cdf & CDF_directmap) - /* * Is the domain using the host memory layout? * diff --git a/xen/arch/ppc/include/asm/domain.h b/xen/arch/ppc/include/asm/domain.h index 573276d0a8..3a447272c6 100644 --- a/xen/arch/ppc/include/asm/domain.h +++ b/xen/arch/ppc/include/asm/domain.h @@ -10,8 +10,6 @@ struct hvm_domain uint64_t params[HVM_NR_PARAMS]; }; -#define is_domain_direct_mapped(d) ((void)(d), 0) - /* TODO: Implement */ #define guest_mode(r) ({ (void)(r); BUG_ON("unimplemented"); 0; }) diff --git a/xen/arch/riscv/include/asm/domain.h b/xen/arch/riscv/include/asm/domain.h index 0f5dc2be40..027bfa8a93 100644 --- a/xen/arch/riscv/include/asm/domain.h +++ b/xen/arch/riscv/include/asm/domain.h @@ -10,8 +10,6 @@ struct hvm_domain uint64_t params[HVM_NR_PARAMS]; }; -#define is_domain_direct_mapped(d) ((void)(d), 0) - struct arch_vcpu_io { }; diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h index 622d22bef2..4bd78e3a6d 100644 --- a/xen/arch/x86/include/asm/domain.h +++ b/xen/arch/x86/include/asm/domain.h @@ -22,7 +22,6 @@ #define is_hvm_pv_evtchn_domain(d) (is_hvm_domain(d) && \ ((d)->arch.hvm.irq->callback_via_type == HVMIRQ_callback_vector || \ (d)->vcpu[0]->arch.hvm.evtchn_upcall_vector)) -#define is_domain_direct_mapped(d) ((void)(d), 0) #define VCPU_TRAP_NONE 0 #define VCPU_TRAP_NMI 1 diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h index b1a4aa6f38..3de5635291 100644 --- a/xen/include/xen/domain.h +++ b/xen/include/xen/domain.h @@ -41,6 +41,8 @@ void arch_get_domain_info(const struct domain *d, #ifdef CONFIG_ARM /* Should domain memory be directly mapped? */ #define CDF_directmap (1U << 1) +#else +#define CDF_directmap 0 #endif /* Is domain memory on static allocation? */ #ifdef CONFIG_STATIC_MEMORY @@ -49,6 +51,7 @@ void arch_get_domain_info(const struct domain *d, #define CDF_staticmem 0 #endif +#define is_domain_direct_mapped(d) ((d)->cdf & CDF_directmap) #define is_domain_using_staticmem(d) ((d)->cdf & CDF_staticmem) /* -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Mar 08 01:55:02 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2024 01:55:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690075.1075735 (Exim 4.92) (envelope-from ) id 1riPRj-00026F-LG; Fri, 08 Mar 2024 01:54:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690075.1075735; Fri, 08 Mar 2024 01:54:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riPRj-000268-Ic; Fri, 08 Mar 2024 01:54:51 +0000 Received: by outflank-mailman (input) for mailman id 690075; Fri, 08 Mar 2024 01:54:50 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riPRi-000262-P4 for xen-devel@lists.xenproject.org; Fri, 08 Mar 2024 01:54:50 +0000 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on20602.outbound.protection.outlook.com [2a01:111:f400:7ea9::602]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id d78fdf4e-dcee-11ee-a1ee-f123f15fe8a2; Fri, 08 Mar 2024 02:54:48 +0100 (CET) Received: from DM6PR10CA0001.namprd10.prod.outlook.com (2603:10b6:5:60::14) by PH0PR12MB7010.namprd12.prod.outlook.com (2603:10b6:510:21c::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.26; Fri, 8 Mar 2024 01:54:44 +0000 Received: from CH3PEPF0000000D.namprd04.prod.outlook.com (2603:10b6:5:60:cafe::9b) by DM6PR10CA0001.outlook.office365.com (2603:10b6:5:60::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.27 via Frontend Transport; Fri, 8 Mar 2024 01:54:44 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by CH3PEPF0000000D.mail.protection.outlook.com (10.167.244.43) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7362.11 via Frontend Transport; Fri, 8 Mar 2024 01:54:43 +0000 Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 7 Mar 2024 19:54:43 -0600 Received: from henry-MS-7D54.amd.com (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend Transport; Thu, 7 Mar 2024 19:54:38 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d78fdf4e-dcee-11ee-a1ee-f123f15fe8a2 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WNuE5xxsvFf4xHIugzT8Xm6ceMac17QjOcve+bIo68ipvAzytXEtJDELHgLh0PfFAquexVWxKc1cumvQCJ3nO7iTY9gaOFI5bVBQxeV2/dDRcGDi30BRsBO08tz9hfJMgPnU+/Hu5Eogywvi+xgVFx8JcSBU1vAxLRV90n3gqIQDPqDDZBa+gi8TniYRQqHO5e/1Ei4x3EvtmTnAINDLGSu54isA144MwiHbUv9yGADlQuKsi1gTWBl41NFqjjdgwOZoZiseRtVSjLBCvG4BGh0P5eHpnzq14am6jbashu32+/pD5NbhM3hEEwsUxs4gIvDWA9fwVynwvajAER7q6w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=GhUdtdfcxsQe269IkHKqtEwCey5V9ybQdEKmYerVnUM=; b=hoNJmeMXSoGSx9zUSDAOzAofVMkbge7EcYZYwrN6jGDQwzWX+GmNKq8gg7VNmckS4YzmGoKzZnJ4eDJ1DNHE8YsF/9bgFn7adsbN8BznxwAsnNhDl06k99+wgKxzVFwAzIkFAhMFVbB5ND9PXm8fAP3zq94ylQ/lkNt7tdOMgxkOR06gHjZjQgTqr+mw/fKbmvsuDnZaQtzPLq0JjtozDzAnD9JDJaIjaWus4kVW+oKXmPlrtE2+Ix5Az0WaG081n/xQtm1jRfnQuSe0Uk1GE8i2WBZ7oKEBqNHr0Ly8454rRiuLDp9Oy7Imrmav9KZ5tmwrAJ+BAXZH447DKF7Duw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GhUdtdfcxsQe269IkHKqtEwCey5V9ybQdEKmYerVnUM=; b=D1W5aYFB/iZGkco2/plYdO7HKqwdNWUi/Os5C5FnoNwINBGpQEgQd38ZX7L7vhhMNMJ23cbPH5lWJ+8KKoVnP5luLhvX97wKEPpCspeBPxe3zQx/PEX3QVaaADWr9v0LIbK0hvEPOUGCo4+XE2YvhrPDUMAjls0ilgZGhc4rpP4= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C From: Henry Wang To: CC: Henry Wang , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , "Volodymyr Babchuk" , Andrew Cooper , George Dunlap , "Jan Beulich" , Wei Liu , Shawn Anastasio , Alistair Francis , Bob Eshleman , "Connor Davis" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Anthony PERARD , "Juergen Gross" Subject: [PATCH v2 0/5] DOMCTL-based guest magic regions allocation for dom0less Date: Fri, 8 Mar 2024 09:54:30 +0800 Message-ID: <20240308015435.4044339-1-xin.wang2@amd.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain Received-SPF: None (SATLEXMB04.amd.com: xin.wang2@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH3PEPF0000000D:EE_|PH0PR12MB7010:EE_ X-MS-Office365-Filtering-Correlation-Id: 1528252f-2a49-4dc1-c6f7-08dc3f12b9b4 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: QApuq2I/5jo41AUlwKjCZbFfkPNGDTO46qJuEFKoFhM+0b5xNWY5CG97EPWhTgi76j7acTz0QehJ11G6KrIGrP9iJtE8flETBhqPWU+MYucxgTLWlYwy4YznZLVkSpulMoBJHZTFUhniAWVUuHr7xemPul3wvsxPE/Ryrn1kIjwW8iVdIxx/VWmZu6LRcf2YD5B673BV0/d66nh3EL+stxRVwdN35lWtFb4eOiBKYgQnSDqkE/xMt72jeDX8YkBiI6SOvNegzumRvyQj1GfICSw21X7Sp5NmILUhZ5z9yHMyGeboErF9/yjVv5+mrQfxKpLFVz8ICoLmj8qdmMKacD0XkQnYjdcETfqTs97LiRqvEQKKUrlXYCiwX34etYbgFAC67myT49HAA/VLCBjR2TVI5k41s00KmuePVq62QEd0Gwdub7CaRYoDYDiTE1rZmxmPh7Vq2P5EYISPqmcWtByzd3w4MGqFZrTDCXrkeNuEUODjREmQlllzurxF1Ivfok8HRrIb3PUFZpk+aatrvS8UNWiivuAJ6GOBLFLqanHeTmb69KF7yQ2bHsBIKG1vgC7ASi5+xpSCOancQfYCD4b0D6sgYoj1SIOgH38Ym3p8HBXDD9ylHfW/2xwnX6Uxx9bTaONqN1n+oA6/OmzdAa0KkhuNSB35n6Fx9rx+LiH4a6iw37mCgiQPPlu/advAsXOh7GKZQRyxMy3z3NmdIwWYDkqkQ5iFRUZnBY+KBXvOeoOtow3oVtVZkXX1qHNh X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(1800799015)(376005)(7416005)(36860700004)(82310400014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Mar 2024 01:54:43.6892 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 1528252f-2a49-4dc1-c6f7-08dc3f12b9b4 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CH3PEPF0000000D.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR12MB7010 An error message can seen from the init-dom0less application on direct-mapped 1:1 domains: ``` Allocating magic pages memory.c:238:d0v0 mfn 0x39000 doesn't belong to d1 Error on alloc magic pages ``` This is because populate_physmap() automatically assumes gfn == mfn for direct mapped domains. This cannot be true for the magic pages that are allocated later for Dom0less DomUs from the init-dom0less helper application executed in Dom0. For domain using statically allocated memory but not 1:1 direct-mapped, similar error "failed to retrieve a reserved page" can be seen as the reserved memory list is empty at that time. This series tries to fix this issue using a DOMCTL-based approach, because for 1:1 direct-mapped domUs, we need to avoid the RAM regions and inform the toolstack about the region found by hypervisor for mapping the magic pages. The first 2 patches are simple clean-ups. Patch 3 introduced a new DOMCTL to get the guest memory map, currently only used for the magic page regions. Patch 4 uses the same approach as finding the extended regions to find the guest magic page regions for direct-mapped DomUs. Patch 5 makes the init-dom0less application consume the DOMCTL to avoid hardcoding the guest magic base address. Henry Wang (5): xen/arm: Rename assign_static_memory_11() for consistency xen/domain.h: Centrialize is_domain_direct_mapped() xen/domctl, tools: Introduce a new domctl to get guest memory map xen/arm: Find unallocated spaces for magic pages of direct-mapped domU xen/memory, tools: Make init-dom0less consume XEN_DOMCTL_get_mem_map tools/helpers/init-dom0less.c | 22 +++++++++--- tools/include/xenctrl.h | 4 +++ tools/libs/ctrl/xc_domain.c | 32 +++++++++++++++++ xen/arch/arm/dom0less-build.c | 45 +++++++++++++++++++++++- xen/arch/arm/domain.c | 6 ++++ xen/arch/arm/domain_build.c | 30 ++++++++++------ xen/arch/arm/domctl.c | 19 +++++++++- xen/arch/arm/include/asm/domain.h | 10 ++++-- xen/arch/arm/include/asm/domain_build.h | 2 ++ xen/arch/arm/include/asm/static-memory.h | 8 ++--- xen/arch/arm/static-memory.c | 5 +-- xen/arch/ppc/include/asm/domain.h | 2 -- xen/arch/riscv/include/asm/domain.h | 2 -- xen/arch/x86/include/asm/domain.h | 1 - xen/common/memory.c | 10 ++++-- xen/include/public/arch-arm.h | 4 +++ xen/include/public/domctl.h | 21 +++++++++++ xen/include/public/memory.h | 5 +++ xen/include/xen/domain.h | 3 ++ xen/include/xen/mm.h | 2 ++ 20 files changed, 201 insertions(+), 32 deletions(-) -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Mar 08 01:55:02 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2024 01:55:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690076.1075744 (Exim 4.92) (envelope-from ) id 1riPRn-0002L5-V7; Fri, 08 Mar 2024 01:54:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690076.1075744; Fri, 08 Mar 2024 01:54:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riPRn-0002Ky-SW; Fri, 08 Mar 2024 01:54:55 +0000 Received: by outflank-mailman (input) for mailman id 690076; Fri, 08 Mar 2024 01:54:54 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riPRm-000262-AL for xen-devel@lists.xenproject.org; Fri, 08 Mar 2024 01:54:54 +0000 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on20600.outbound.protection.outlook.com [2a01:111:f403:2412::600]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id dabc7394-dcee-11ee-a1ee-f123f15fe8a2; Fri, 08 Mar 2024 02:54:52 +0100 (CET) Received: from DM6PR10CA0002.namprd10.prod.outlook.com (2603:10b6:5:60::15) by SA0PR12MB7001.namprd12.prod.outlook.com (2603:10b6:806:2c0::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.24; Fri, 8 Mar 2024 01:54:47 +0000 Received: from CH3PEPF0000000D.namprd04.prod.outlook.com (2603:10b6:5:60:cafe::27) by DM6PR10CA0002.outlook.office365.com (2603:10b6:5:60::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.27 via Frontend Transport; Fri, 8 Mar 2024 01:54:47 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by CH3PEPF0000000D.mail.protection.outlook.com (10.167.244.43) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7362.11 via Frontend Transport; Fri, 8 Mar 2024 01:54:47 +0000 Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 7 Mar 2024 19:54:46 -0600 Received: from henry-MS-7D54.amd.com (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend Transport; Thu, 7 Mar 2024 19:54:44 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: dabc7394-dcee-11ee-a1ee-f123f15fe8a2 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LrbOO0R3HbwVD8i17/u6NyTVrytsLJlqwJqo9h12AcfNq210pVfNaP9fTiTF2sGm/MJJVaSMw7uQpdG/al5Zt84NjgKwsHD0DeIRoPx7KBuhhzXVZ0fysQFwRmqHHd7R9Dhv0FYeVgrOxNwiKyBntTHx1iPZhU1JYvotco/WWwje0Iv46jk9xiYVXLHR7Ga7qjO42cbnUCiQpegOVkw6B2PKHz9MLTbSBJvXXVrSW8NWWjm5xg25S2QegpXK0b4Q42M37regoxg2jJ6GbGierOdqJ9eZfPrCC9DdDEo8xQ7ZqELEK87X5xhNzsfrr1fW027gCzxP6f36HOX0EBg51A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=t+i1Nrwfs3RtzHQxrkA9Q/UxYobRSCipIPuuOohcu4M=; b=OqD7j2+pBbQKSJemR7k5d7fNhk4BHfbtJzX39H/LLWeERTWwYpeuN7LASrzZN+IdjSj1/nvIA0ySHSdHYXP0+WGHixnemoakFkbkKRSaktPC3yM3lYrZTMGc+uIS9flWHv+ZLzHxlBQxHsO+Vt9XjvMZN4dHanld0g1gyxYYGopmT2xAB1bFaoXMQXBUOH7UR3smiDB2aV7moQfTAwWlMhdD0reDlD3z6m7NJpgTtv845DXKxvSBwXJwaBJre035ElDMxu/AXr3vzUIZ2zJ7kSFxB2g5gKvFLXfD2zEf0Z8Awe3XU9STeL80NFaBbVUenD1q4Zie8FVjO3Xte5AO+Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=t+i1Nrwfs3RtzHQxrkA9Q/UxYobRSCipIPuuOohcu4M=; b=4Ubdres3RNzCsVrJnpv5T9kC8Wp7I13Ear5jk3r4dht3aEp4yMgDZoC79ycuBu6q0Elu994q+Wd6c0Q9ybseKY2iZznlhrzEkU1Mo+3/QO2gkX6wbXRWMTitZacYV4Ro9aVdyn2mMXSL68uh+hZWlWozuG1Gmh2gzVKlnTka5Jk= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C From: Henry Wang To: CC: Henry Wang , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , "Volodymyr Babchuk" Subject: [PATCH v2 1/5] xen/arm: Rename assign_static_memory_11() for consistency Date: Fri, 8 Mar 2024 09:54:31 +0800 Message-ID: <20240308015435.4044339-2-xin.wang2@amd.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240308015435.4044339-1-xin.wang2@amd.com> References: <20240308015435.4044339-1-xin.wang2@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain Received-SPF: None (SATLEXMB04.amd.com: xin.wang2@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH3PEPF0000000D:EE_|SA0PR12MB7001:EE_ X-MS-Office365-Filtering-Correlation-Id: d1e475ed-1378-433f-83c8-08dc3f12bbfa X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: /9Q/4lcYBxbykpoXUM/fT/CW1Nrc89QJIVrrF1vK1MD9RWhgqn8Czd1FQRckfhiTjT5oMjJWfwzcVpAsn74AQrVXtoVlvpe0FNGxbQS4c8rcAFI48GiNVVR3HvF3X9VoxLYyKgihEYb9d7ngp5Gn8/lPYKLd+Cc/nMEPcYtftDgxZMRqxjbpod8GQnnUvnzeSmvxBqZlTx+K5mEDLCXAoJmM/wGPHk1kmcAevX92uj7xM3GAb2z5bYJ9/UMmW01I1Jcn88DPKHPjbhGLS1hm4MfEKur8mgO/LETPUhyITGG2laF8WYOgLw0QaYNQQHbXTVsRl5KsUcRtS8j9magy2WpFE1hAcQap/1gVp+i0wM+xxWNvfmXAxBv+9kOaWXG5nh+p0JYYzXPwKLWYd/WOIxqduijE1HpyisxVUk8+SI8ee6wMQzwVUti7PwICRf9KYwDp1OK7Dl4DI8CpQc+nzLJkssABVIxiY4LgO9WmQvreKJJYdJccagS2y4DXrPdtCXO2lo3tp9jZY+/8ckqz2wZpWmHKd0ghwfAo5/Xq/M4WDHknfbQmg3WJqogvt6IhF82TS2FHiWjUPSzEhTARKsxazmottxusBJE4HEmQGaT+vyZncyJn1s8NA8Ilg6ciztDQ+Yi7W++xN0WoXS0NOxzfTS1Y7xsTwpMfYtoht8Q16f+DZOIDP+Vvu3IvcP0l1dH0XJGALP/1j9565/3eDp3Ymhoid/wJRuHJSjGh2JuVkByYKuiaDwG5vAYwWZuh X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(1800799015)(82310400014)(376005)(36860700004);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Mar 2024 01:54:47.4861 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d1e475ed-1378-433f-83c8-08dc3f12bbfa X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CH3PEPF0000000D.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR12MB7001 Currently on Arm there are 4 functions to allocate memory as domain RAM at boot time for different types of domains: (1) allocate_memory(): To allocate memory for Dom0less DomUs that do not use static memory. (2) allocate_static_memory(): To allocate memory for Dom0less DomUs that use static memory. (3) allocate_memory_11(): To allocate memory for Dom0. (4) assign_static_memory_11(): To allocate memory for Dom0less DomUs that use static memory and directmapped. To keep consistency between the names and the in-code comment on top of the functions, rename assign_static_memory_11() to allocate_static_memory_11(). No functional change intended. Signed-off-by: Henry Wang --- v2: - New patch --- xen/arch/arm/dom0less-build.c | 2 +- xen/arch/arm/include/asm/static-memory.h | 8 ++++---- xen/arch/arm/static-memory.c | 5 +++-- 3 files changed, 8 insertions(+), 7 deletions(-) diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c index fb63ec6fd1..1e1c8d83ae 100644 --- a/xen/arch/arm/dom0less-build.c +++ b/xen/arch/arm/dom0less-build.c @@ -806,7 +806,7 @@ static int __init construct_domU(struct domain *d, else if ( !is_domain_direct_mapped(d) ) allocate_static_memory(d, &kinfo, node); else - assign_static_memory_11(d, &kinfo, node); + allocate_static_memory_11(d, &kinfo, node); rc = process_shm(d, &kinfo, node); if ( rc < 0 ) diff --git a/xen/arch/arm/include/asm/static-memory.h b/xen/arch/arm/include/asm/static-memory.h index 3e3efd70c3..667e6d3804 100644 --- a/xen/arch/arm/include/asm/static-memory.h +++ b/xen/arch/arm/include/asm/static-memory.h @@ -9,7 +9,7 @@ void allocate_static_memory(struct domain *d, struct kernel_info *kinfo, const struct dt_device_node *node); -void assign_static_memory_11(struct domain *d, struct kernel_info *kinfo, +void allocate_static_memory_11(struct domain *d, struct kernel_info *kinfo, const struct dt_device_node *node); void init_staticmem_pages(void); @@ -22,9 +22,9 @@ static inline void allocate_static_memory(struct domain *d, ASSERT_UNREACHABLE(); } -static inline void assign_static_memory_11(struct domain *d, - struct kernel_info *kinfo, - const struct dt_device_node *node) +static inline void allocate_static_memory_11(struct domain *d, + struct kernel_info *kinfo, + const struct dt_device_node *node) { ASSERT_UNREACHABLE(); } diff --git a/xen/arch/arm/static-memory.c b/xen/arch/arm/static-memory.c index cffbab7241..20333a7f94 100644 --- a/xen/arch/arm/static-memory.c +++ b/xen/arch/arm/static-memory.c @@ -187,8 +187,9 @@ void __init allocate_static_memory(struct domain *d, struct kernel_info *kinfo, * The static memory will be directly mapped in the guest(Guest Physical * Address == Physical Address). */ -void __init assign_static_memory_11(struct domain *d, struct kernel_info *kinfo, - const struct dt_device_node *node) +void __init allocate_static_memory_11(struct domain *d, + struct kernel_info *kinfo, + const struct dt_device_node *node) { u32 addr_cells, size_cells, reg_cells; unsigned int nr_banks, bank = 0; -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Mar 08 01:55:06 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2024 01:55:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690078.1075765 (Exim 4.92) (envelope-from ) id 1riPRy-0002wP-FA; Fri, 08 Mar 2024 01:55:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690078.1075765; Fri, 08 Mar 2024 01:55:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riPRy-0002wF-Bh; Fri, 08 Mar 2024 01:55:06 +0000 Received: by outflank-mailman (input) for mailman id 690078; Fri, 08 Mar 2024 01:55:05 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riPRw-0002aR-RK for xen-devel@lists.xenproject.org; Fri, 08 Mar 2024 01:55:04 +0000 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on20600.outbound.protection.outlook.com [2a01:111:f403:2416::600]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id e172b442-dcee-11ee-afda-a90da7624cb6; Fri, 08 Mar 2024 02:55:04 +0100 (CET) Received: from CH0PR08CA0003.namprd08.prod.outlook.com (2603:10b6:610:33::8) by DS0PR12MB7701.namprd12.prod.outlook.com (2603:10b6:8:133::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.27; Fri, 8 Mar 2024 01:55:00 +0000 Received: from CH3PEPF0000000C.namprd04.prod.outlook.com (2603:10b6:610:33:cafe::86) by CH0PR08CA0003.outlook.office365.com (2603:10b6:610:33::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.24 via Frontend Transport; Fri, 8 Mar 2024 01:54:59 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by CH3PEPF0000000C.mail.protection.outlook.com (10.167.244.39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7362.11 via Frontend Transport; Fri, 8 Mar 2024 01:54:59 +0000 Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 7 Mar 2024 19:54:56 -0600 Received: from henry-MS-7D54.amd.com (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend Transport; Thu, 7 Mar 2024 19:54:53 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e172b442-dcee-11ee-afda-a90da7624cb6 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ret327N92ICMcm5oO0QKCrm/ZGhpRc9Ov+6+EkyJys/G6X5ThsABN+bJH+bT4KOSEize8/BbZ/WlId0fUZAYJfG0FDe01pS5cNn49LqlXMbfT3OlgFs8GDbig9taY4QX7Aa05BiJLCHumrN+fO+7aUq29h77OL6Zlcy6KCnwG/NFm/Fbpiq3OTzwWXuPATrXPpTf4d2N8TIbvw9JPn/HwLYrBKnkFP6CJmbTpxLX4Tew0nrRkcZV9VvoLPNNBdpt8EsKiXFXgpllhdJK+FstdkbXEOaw9FAFGCMOwmlRCKMZ+8HTYPuz9zUOiqOfR3tZ/pG4Z103zbvT/K5t0oJOHA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=5JLhDJckjBrTEJORORb//VfOB3M3GRvGRS0zsUFs98o=; b=X9Ko+PlWhRCOGTRjKwWC2G3ooiAE7PsLeEkTdqlg3A2SlAOQ6i806P2PehNJ5grMqX2xwlFeRTUKGEWPXbB2OzyAhvJmAEEERyem2Bgh/kFUGNqoaP2e7Tv3QH/b7ecwbtYMYV3tfDht/CKQTELRBY3Orc/uttRMV+xUmNegIXFj6CsRkqKNSQciPbAIkFmlEgQxskyHf1exOuPsAnD0YfcGDblncRTKZIF+SU4Pc5i4eGJUOlr+nFUQrR+DtZMEJEpCn8S+iP/AlSl27d7Q4NlBlBhPqN+wQGPDsPKJMhH33q8LcjBBtdGA1gxQ6vZHUOaN5mDGeSE1+vLqSRfPvw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5JLhDJckjBrTEJORORb//VfOB3M3GRvGRS0zsUFs98o=; b=2jweelHA3iyHSHrP52YxQ1iTT1+9WZ253Y4xc//KG0h8hDjD9JXJrPROKyfyolK9kJ4Jqp2k5kOba1v/LsQFjbb/2uZILLqUmErnBPNy73igtkUBrrZs0GL3kWPcL+ZP4elwKWvx1a1LHnqWWcWg8SNDU/otU2aFhyVXbmOikmo= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C From: Henry Wang To: CC: Henry Wang , Wei Liu , Anthony PERARD , Juergen Gross , Andrew Cooper , George Dunlap , "Jan Beulich" , Julien Grall , "Stefano Stabellini" , Bertrand Marquis , Michal Orzel , "Volodymyr Babchuk" , Alec Kwapis Subject: [PATCH v2 3/5] xen/domctl, tools: Introduce a new domctl to get guest memory map Date: Fri, 8 Mar 2024 09:54:33 +0800 Message-ID: <20240308015435.4044339-4-xin.wang2@amd.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240308015435.4044339-1-xin.wang2@amd.com> References: <20240308015435.4044339-1-xin.wang2@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain Received-SPF: None (SATLEXMB04.amd.com: xin.wang2@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH3PEPF0000000C:EE_|DS0PR12MB7701:EE_ X-MS-Office365-Filtering-Correlation-Id: 179b062c-8f68-4748-b45c-08dc3f12c319 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 7ktN1Z/K0/PgOFfDzVGPYbkEwXDvsudwHWbVk5xAddK+aZqrG5MqmLLmQLfYihXrml7NrFtd1lwBipWl8nruMsVtZMPj9NFTCKHiDHHsNIM5/YaKn0jgajBCdnQ9PfJi+fo9BjzlxFdX92wSRis6pKImaTlPzhesQSoN7pwrVHMsaY2O46vSgzxzOatUse4CvsgdcE/pLMRXAyAIzXzi0/HnNgbZ95/9bsCKX3fG0hT9Ij24nGcRw9KnQTUk6kQ2QMYrTbC7S7s370rSf7BZRRxaFJgJpAowhiAVRXr+svZUQ26JjvbTfZqAZMKDFev9WNaHCAxqVu1xWbCglHP0o7CHGHI8PiQp1OaqGt2L7cweMCdfDKeu7hZgKp1iLJUUW8IuUe/x/nbNgJzyMLGNVWVWMxO2Uvd4KzO2lG6syh8w9RW/Mofc1CvilpvJyy0ddBWZnSiO5V+RWKpXa45+ADujIflTx7Vz2qLYgCo89azwkE5IXRDv0p2O9dNNdFbmo6AvaZd0Sm9KyE9NIhE2ACHrzdbw9vqzLvWTsyYbRzlLZL45QwJPWviF2N9BR3Wrn8r+fpIa2pvZ5nMHV5R3oKz50CzsDBr/PZyFtQkT+px98bBAeCxmqs/AK2zPD5RCahXMl7NgyyIS8M7OAYiQ47lVFo3wXM4VHe3C2Y58eGZuzIjIDvPTOjiqjirRuD3Lw7iMDmgHT1hrG3r9OQjiK7cTFDoSZ4DmDEoLGvCiWm3cYc3zisNWKhvuMLFgUHOA X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(1800799015)(7416005)(376005)(36860700004)(82310400014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Mar 2024 01:54:59.4345 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 179b062c-8f68-4748-b45c-08dc3f12c319 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CH3PEPF0000000C.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB7701 There are some use cases where the toolstack needs to know the guest memory map. For example, the toolstack helper application "init-dom0less" needs to know the guest magic page regions for 1:1 direct-mapped dom0less DomUs to allocate magic pages. To address such needs, add XEN_DOMCTL_get_mem_map hypercall and related data structures to query the hypervisor for the guest memory map. The guest memory map is recorded in the domain structure and currently only guest magic page region is recorded in the guest memory map. The guest magic page region is initialized at the domain creation time as the layout in the public header, and it is updated for 1:1 dom0less DomUs (see the following commit) to avoid conflict with RAM. Take the opportunity to drop an unnecessary empty line to keep the coding style consistent in the file. Reported-by: Alec Kwapis Signed-off-by: Henry Wang --- v2: - New patch RFC: I think the newly introduced "struct xen_domctl_mem_map" is quite duplicated with "struct xen_memory_map", any comment on reuse the "struct xen_memory_map" for simplicity? --- tools/include/xenctrl.h | 4 ++++ tools/libs/ctrl/xc_domain.c | 32 +++++++++++++++++++++++++++++++ xen/arch/arm/domain.c | 6 ++++++ xen/arch/arm/domctl.c | 19 +++++++++++++++++- xen/arch/arm/include/asm/domain.h | 8 ++++++++ xen/include/public/arch-arm.h | 4 ++++ xen/include/public/domctl.h | 21 ++++++++++++++++++++ 7 files changed, 93 insertions(+), 1 deletion(-) diff --git a/tools/include/xenctrl.h b/tools/include/xenctrl.h index 2ef8b4e054..b25e9772a2 100644 --- a/tools/include/xenctrl.h +++ b/tools/include/xenctrl.h @@ -1195,6 +1195,10 @@ int xc_domain_setmaxmem(xc_interface *xch, uint32_t domid, uint64_t max_memkb); +int xc_get_domain_mem_map(xc_interface *xch, uint32_t domid, + struct xen_mem_region mem_regions[], + uint32_t *nr_regions); + int xc_domain_set_memmap_limit(xc_interface *xch, uint32_t domid, unsigned long map_limitkb); diff --git a/tools/libs/ctrl/xc_domain.c b/tools/libs/ctrl/xc_domain.c index f2d9d14b4d..64b46bdfb4 100644 --- a/tools/libs/ctrl/xc_domain.c +++ b/tools/libs/ctrl/xc_domain.c @@ -697,6 +697,38 @@ int xc_domain_setmaxmem(xc_interface *xch, return do_domctl(xch, &domctl); } +int xc_get_domain_mem_map(xc_interface *xch, uint32_t domid, + struct xen_mem_region mem_regions[], + uint32_t *nr_regions) +{ + int rc; + struct xen_domctl domctl = { + .cmd = XEN_DOMCTL_get_mem_map, + .domain = domid, + .u.mem_map = { + .nr_mem_regions = *nr_regions, + }, + }; + + DECLARE_HYPERCALL_BOUNCE(mem_regions, + sizeof(xen_mem_region_t) * (*nr_regions), + XC_HYPERCALL_BUFFER_BOUNCE_OUT); + + if ( !mem_regions || xc_hypercall_bounce_pre(xch, mem_regions) || + (*nr_regions) < 1 ) + return -1; + + set_xen_guest_handle(domctl.u.mem_map.buffer, mem_regions); + + rc = do_domctl(xch, &domctl); + + xc_hypercall_bounce_post(xch, mem_regions); + + *nr_regions = domctl.u.mem_map.nr_mem_regions; + + return rc; +} + #if defined(__i386__) || defined(__x86_64__) int xc_domain_set_memory_map(xc_interface *xch, uint32_t domid, diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c index 5e7a7f3e7e..54f3601ab0 100644 --- a/xen/arch/arm/domain.c +++ b/xen/arch/arm/domain.c @@ -696,6 +696,7 @@ int arch_domain_create(struct domain *d, { unsigned int count = 0; int rc; + struct mem_map_domain *mem_map = &d->arch.mem_map; BUILD_BUG_ON(GUEST_MAX_VCPUS < MAX_VIRT_CPUS); @@ -785,6 +786,11 @@ int arch_domain_create(struct domain *d, d->arch.sve_vl = config->arch.sve_vl; #endif + mem_map->regions[mem_map->nr_mem_regions].start = GUEST_MAGIC_BASE; + mem_map->regions[mem_map->nr_mem_regions].size = GUEST_MAGIC_SIZE; + mem_map->regions[mem_map->nr_mem_regions].type = GUEST_MEM_REGION_MAGIC; + mem_map->nr_mem_regions++; + return 0; fail: diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c index ad56efb0f5..92024bcaa0 100644 --- a/xen/arch/arm/domctl.c +++ b/xen/arch/arm/domctl.c @@ -148,7 +148,6 @@ long arch_do_domctl(struct xen_domctl *domctl, struct domain *d, return 0; } - case XEN_DOMCTL_vuart_op: { int rc; @@ -176,6 +175,24 @@ long arch_do_domctl(struct xen_domctl *domctl, struct domain *d, return rc; } + case XEN_DOMCTL_get_mem_map: + { + int rc; + /* + * Cap the number of regions to the minimum value between toolstack and + * hypervisor to avoid overflowing the buffer. + */ + uint32_t nr_regions = min(d->arch.mem_map.nr_mem_regions, + domctl->u.mem_map.nr_mem_regions); + + if ( copy_to_guest(domctl->u.mem_map.buffer, + d->arch.mem_map.regions, + nr_regions) || + __copy_to_guest(u_domctl, domctl, 1) ) + rc = -EFAULT; + + return rc; + } default: return subarch_do_domctl(domctl, d, u_domctl); } diff --git a/xen/arch/arm/include/asm/domain.h b/xen/arch/arm/include/asm/domain.h index f1d72c6e48..a559a9e499 100644 --- a/xen/arch/arm/include/asm/domain.h +++ b/xen/arch/arm/include/asm/domain.h @@ -10,6 +10,7 @@ #include #include #include +#include #include struct hvm_domain @@ -59,6 +60,11 @@ struct paging_domain { unsigned long p2m_total_pages; }; +struct mem_map_domain { + unsigned int nr_mem_regions; + struct xen_mem_region regions[XEN_MAX_MEM_REGIONS]; +}; + struct arch_domain { #ifdef CONFIG_ARM_64 @@ -77,6 +83,8 @@ struct arch_domain struct paging_domain paging; + struct mem_map_domain mem_map; + struct vmmio vmmio; /* Continuable domain_relinquish_resources(). */ diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h index a25e87dbda..a06eaf2dab 100644 --- a/xen/include/public/arch-arm.h +++ b/xen/include/public/arch-arm.h @@ -420,6 +420,10 @@ typedef uint64_t xen_callback_t; * should instead use the FDT. */ +/* Guest memory region types */ +#define GUEST_MEM_REGION_DEFAULT 0 +#define GUEST_MEM_REGION_MAGIC 1 + /* Physical Address Space */ /* Virtio MMIO mappings */ diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h index a33f9ec32b..77bf999651 100644 --- a/xen/include/public/domctl.h +++ b/xen/include/public/domctl.h @@ -946,6 +946,25 @@ struct xen_domctl_paging_mempool { uint64_aligned_t size; /* Size in bytes. */ }; +#define XEN_MAX_MEM_REGIONS 1 + +struct xen_mem_region { + uint64_t start; + uint64_t size; + unsigned int type; +}; +typedef struct xen_mem_region xen_mem_region_t; +DEFINE_XEN_GUEST_HANDLE(xen_mem_region_t); + +struct xen_domctl_mem_map { + /* IN & OUT */ + uint32_t nr_mem_regions; + /* OUT */ + XEN_GUEST_HANDLE(xen_mem_region_t) buffer; +}; +typedef struct xen_domctl_mem_map xen_domctl_mem_map_t; +DEFINE_XEN_GUEST_HANDLE(xen_domctl_mem_map_t); + #if defined(__i386__) || defined(__x86_64__) struct xen_domctl_vcpu_msr { uint32_t index; @@ -1277,6 +1296,7 @@ struct xen_domctl { #define XEN_DOMCTL_vmtrace_op 84 #define XEN_DOMCTL_get_paging_mempool_size 85 #define XEN_DOMCTL_set_paging_mempool_size 86 +#define XEN_DOMCTL_get_mem_map 87 #define XEN_DOMCTL_gdbsx_guestmemio 1000 #define XEN_DOMCTL_gdbsx_pausevcpu 1001 #define XEN_DOMCTL_gdbsx_unpausevcpu 1002 @@ -1339,6 +1359,7 @@ struct xen_domctl { struct xen_domctl_vuart_op vuart_op; struct xen_domctl_vmtrace_op vmtrace_op; struct xen_domctl_paging_mempool paging_mempool; + struct xen_domctl_mem_map mem_map; uint8_t pad[128]; } u; }; -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Mar 08 01:55:08 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2024 01:55:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690079.1075775 (Exim 4.92) (envelope-from ) id 1riPRz-0003E1-TA; Fri, 08 Mar 2024 01:55:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690079.1075775; Fri, 08 Mar 2024 01:55:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riPRz-0003Ds-Ot; Fri, 08 Mar 2024 01:55:07 +0000 Received: by outflank-mailman (input) for mailman id 690079; Fri, 08 Mar 2024 01:55:06 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riPRy-000262-Ih for xen-devel@lists.xenproject.org; Fri, 08 Mar 2024 01:55:06 +0000 Received: from NAM04-DM6-obe.outbound.protection.outlook.com (mail-dm6nam04on20600.outbound.protection.outlook.com [2a01:111:f403:2409::600]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id e18692dd-dcee-11ee-a1ee-f123f15fe8a2; Fri, 08 Mar 2024 02:55:05 +0100 (CET) Received: from CH0PR08CA0008.namprd08.prod.outlook.com (2603:10b6:610:33::13) by DM6PR12MB4299.namprd12.prod.outlook.com (2603:10b6:5:223::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.27; Fri, 8 Mar 2024 01:55:00 +0000 Received: from CH3PEPF0000000C.namprd04.prod.outlook.com (2603:10b6:610:33:cafe::bc) by CH0PR08CA0008.outlook.office365.com (2603:10b6:610:33::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.27 via Frontend Transport; Fri, 8 Mar 2024 01:55:00 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by CH3PEPF0000000C.mail.protection.outlook.com (10.167.244.39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7362.11 via Frontend Transport; Fri, 8 Mar 2024 01:55:00 +0000 Received: from SATLEXMB08.amd.com (10.181.40.132) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 7 Mar 2024 19:54:59 -0600 Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB08.amd.com (10.181.40.132) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 7 Mar 2024 17:54:59 -0800 Received: from henry-MS-7D54.amd.com (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend Transport; Thu, 7 Mar 2024 19:54:57 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e18692dd-dcee-11ee-a1ee-f123f15fe8a2 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=imiHSEHGSKFUxX351jEEMbsY5UW+40/WFtHMOEaDJdhAIax8YrU1FASa2FuDtJ1e2MLxbRePU1A/w8FtOP88TRSNIANvAkSxA8XORyZFA3jktPPbRBiz63mbqUW6kky0n3uhziP2KzqgdVnOH36oF5au/2QD8Ra5z0ebkAw6Oa4Oh8YLo7G0aidlWx6E2I27dRz8GnKTTyyFuZc0e7sXGrNmVk+FTryuuHAsYAZw+T2qmEKXyvajEvbGnPDsHb45fZn4qyCSYmu6cm+yGOp6o35MeChQb+3k1FFR+EclbUsjO5PHgWX9flE5W/fj4IEv5om0LEriDLxzLl1f+h2Cjg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=CE58BMIuONHX86OiEvm3TsjUfQMGClGr8nUX/wXf4kY=; b=ie1kjj8PIHBKlY8lnXGfTlKkvZ4zXX5XR+sTVaebriEBPfclQIAF6bHRPaDIkFWrzoE3XR7N86ML5a5gghC362cEwqbhOytOeI+4G1p3TDQTPb0ZKIGkOwJFcsTP8QKNsyDQFR6VeE7ETw9cnmG+c++a/wQam6OsVjg+Mlp3lQHxyR89nIBCityOpxsuXmWnKi1WNlOTRCfPwioyVol0geMhNqh955hbu1JH2KLOBi80KPvFoOAUTTnKm8E/t466BorQjXaPTi7g2bs+iQFzn8Ahii5ddGyZJO4NupO3g8RwIr7T5HtLG/2c+e+UdciZXTsTpIMVk7vJwf1S8CskBQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CE58BMIuONHX86OiEvm3TsjUfQMGClGr8nUX/wXf4kY=; b=qEjq0KVfr1B8U9cBm+lK0Y9TigEXsglYA/GhGQ5mPtS5sCk4hGMLvx4C695jrf7AIWqpop+EhcU+3CMVxVKRsYqm8jeUtzKSdAcsM3UBJ4jHqJn1f5L7ZmZvlB7RitTQFfGFslB7E5vWE2U2nTpx/eIr4Qeq/fj5tCZ3AXRypqw= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C From: Henry Wang To: CC: Henry Wang , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , "Volodymyr Babchuk" , Alec Kwapis Subject: [PATCH v2 4/5] xen/arm: Find unallocated spaces for magic pages of direct-mapped domU Date: Fri, 8 Mar 2024 09:54:34 +0800 Message-ID: <20240308015435.4044339-5-xin.wang2@amd.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240308015435.4044339-1-xin.wang2@amd.com> References: <20240308015435.4044339-1-xin.wang2@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH3PEPF0000000C:EE_|DM6PR12MB4299:EE_ X-MS-Office365-Filtering-Correlation-Id: c5a2fb12-47a0-462e-ae6b-08dc3f12c395 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 8xp3Qzu2hTg/oEmD5mEnWMxjdBceJg0feH5EFHbKD6K/FtDLh3/xFKM/j7jiHbZ8OAG4fl6gWUiyx4YDMXMLzQ0lsf0kaV4xCg8Vh3QOOVIQ0A2IXB2LxUTBhP39cCuULDHvQIEZ6aFmNb19fXtCxOtmQZeY/HotUBzBkXsl2ooNuiblhY41pPbtisXizxvNK+lSjWhRPVHgbE7+dCwcPt64tptCJg4EpiaBrjFndnCha0DQukJsBbSH2q0ei9kJLSHiw8EQ780+I0gL7pfz5r8Ak5MfWoL3BNyAztxTtdXhacmw2Y2vOZ9hI+xra5hMnQgBSyJfeF1GaWdY0dFbL4agJHm8E0f4ZquRMrrYx0f5sK4cg1HpqGSkWkQ9FsxeX636oQk56FXnw3csmxCMeG3mLlKxtCCixdzrzBZllC8e0YdDi/MayDbnkBAevE8VzdYMDQ7EomR4Qz8lxfxmey/yDczQYcW0uqCifUHb98nWIY2lbpOAn2MyPVVy45/SfB0N0u+DFHBdmXGOSiYKd26ajrRjf+W3OsrIKtXTenayNSR0zf7h+npkI6kvwdzo9HrwvSGyWoX3B2njB+eEzVcTNkzjpi4sSbMaIAkTDiCo+r0woqeSbnjc1Lf4sTAnHGJy28A/o1Jid9iVsgOSMHhWRQNl632g8A+8mCYdHc+GFdCRAd8vPYnlT8wDfS89LanITOWCVnVUnQSlkOhmNJwEbGZuSvUnq46CCie4WsE0nXfYlxqvDCwnPIko2be7 X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(1800799015)(82310400014)(36860700004)(376005);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Mar 2024 01:55:00.2626 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c5a2fb12-47a0-462e-ae6b-08dc3f12c395 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CH3PEPF0000000C.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4299 For 1:1 direct-mapped dom0less DomUs, the magic pages should not clash with any RAM region. To find a proper region for guest magic pages, we can reuse the logic of finding domain extended regions. Extract the logic of finding domain extended regions to a helper function named find_unused_memory() and use it to find unallocated spaces for magic pages before make_hypervisor_node(). The result magic page region is added to the reserved memory section of the bootinfo so that it is carved out from the extended regions. Reported-by: Alec Kwapis Signed-off-by: Henry Wang --- v2: - New patch --- xen/arch/arm/dom0less-build.c | 43 +++++++++++++++++++++++++ xen/arch/arm/domain_build.c | 30 ++++++++++------- xen/arch/arm/include/asm/domain_build.h | 2 ++ 3 files changed, 64 insertions(+), 11 deletions(-) diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c index 1e1c8d83ae..99447bfb0c 100644 --- a/xen/arch/arm/dom0less-build.c +++ b/xen/arch/arm/dom0less-build.c @@ -682,6 +682,49 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo) if ( kinfo->dom0less_feature & DOM0LESS_ENHANCED_NO_XS ) { + if ( is_domain_direct_mapped(d) ) + { + struct meminfo *avail_magic_regions = xzalloc(struct meminfo); + struct meminfo *rsrv_mem = &bootinfo.reserved_mem; + struct mem_map_domain *mem_map = &d->arch.mem_map; + uint64_t magic_region_start = INVALID_PADDR; + uint64_t magic_region_size = GUEST_MAGIC_SIZE; + unsigned int i; + + if ( !avail_magic_regions ) + return -ENOMEM; + + ret = find_unused_memory(d, kinfo, avail_magic_regions); + if ( ret ) + { + printk(XENLOG_WARNING + "%pd: failed to find a region for domain magic pages\n", + d); + goto err; + } + + magic_region_start = avail_magic_regions->bank[0].start; + + /* + * Register the magic region as reserved mem to make sure this + * region will not be counted when allocating extended regions. + */ + rsrv_mem->bank[rsrv_mem->nr_banks].start = magic_region_start; + rsrv_mem->bank[rsrv_mem->nr_banks].size = magic_region_size; + rsrv_mem->bank[rsrv_mem->nr_banks].type = MEMBANK_DEFAULT; + rsrv_mem->nr_banks++; + + /* Update the domain memory map. */ + for ( i = 0; i < mem_map->nr_mem_regions; i++ ) + { + if ( mem_map->regions[i].type == GUEST_MEM_REGION_MAGIC ) + { + mem_map->regions[i].start = magic_region_start; + mem_map->regions[i].size = magic_region_size; + } + } + } + ret = make_hypervisor_node(d, kinfo, addrcells, sizecells); if ( ret ) goto err; diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c index 085d88671e..b36b98ee7d 100644 --- a/xen/arch/arm/domain_build.c +++ b/xen/arch/arm/domain_build.c @@ -1110,6 +1110,24 @@ static int __init find_domU_holes(const struct kernel_info *kinfo, return res; } +int __init find_unused_memory(struct domain *d, const struct kernel_info *kinfo, + struct meminfo *mem_region) +{ + int res; + + if ( is_domain_direct_mapped(d) ) + { + if ( !is_iommu_enabled(d) ) + res = find_unallocated_memory(kinfo, mem_region); + else + res = find_memory_holes(kinfo, mem_region); + } + else + res = find_domU_holes(kinfo, mem_region); + + return res; +} + int __init make_hypervisor_node(struct domain *d, const struct kernel_info *kinfo, int addrcells, int sizecells) @@ -1161,17 +1179,7 @@ int __init make_hypervisor_node(struct domain *d, if ( !ext_regions ) return -ENOMEM; - if ( is_domain_direct_mapped(d) ) - { - if ( !is_iommu_enabled(d) ) - res = find_unallocated_memory(kinfo, ext_regions); - else - res = find_memory_holes(kinfo, ext_regions); - } - else - { - res = find_domU_holes(kinfo, ext_regions); - } + res = find_unused_memory(d, kinfo, ext_regions); if ( res ) printk(XENLOG_WARNING "%pd: failed to allocate extended regions\n", diff --git a/xen/arch/arm/include/asm/domain_build.h b/xen/arch/arm/include/asm/domain_build.h index da9e6025f3..4458012644 100644 --- a/xen/arch/arm/include/asm/domain_build.h +++ b/xen/arch/arm/include/asm/domain_build.h @@ -10,6 +10,8 @@ bool allocate_bank_memory(struct domain *d, struct kernel_info *kinfo, gfn_t sgfn, paddr_t tot_size); int construct_domain(struct domain *d, struct kernel_info *kinfo); int domain_fdt_begin_node(void *fdt, const char *name, uint64_t unit); +int find_unused_memory(struct domain *d, const struct kernel_info *kinfo, + struct meminfo *mem_region); int make_chosen_node(const struct kernel_info *kinfo); int make_cpus_node(const struct domain *d, void *fdt); int make_hypervisor_node(struct domain *d, const struct kernel_info *kinfo, -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Mar 08 01:55:11 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2024 01:55:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690080.1075785 (Exim 4.92) (envelope-from ) id 1riPS3-0003cq-4e; Fri, 08 Mar 2024 01:55:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690080.1075785; Fri, 08 Mar 2024 01:55:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riPS3-0003ci-1K; Fri, 08 Mar 2024 01:55:11 +0000 Received: by outflank-mailman (input) for mailman id 690080; Fri, 08 Mar 2024 01:55:09 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riPS1-0002aR-UA for xen-devel@lists.xenproject.org; Fri, 08 Mar 2024 01:55:09 +0000 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on20611.outbound.protection.outlook.com [2a01:111:f400:7e88::611]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id e402671c-dcee-11ee-afda-a90da7624cb6; Fri, 08 Mar 2024 02:55:09 +0100 (CET) Received: from SJ0P220CA0015.NAMP220.PROD.OUTLOOK.COM (2603:10b6:a03:41b::19) by PH7PR12MB7455.namprd12.prod.outlook.com (2603:10b6:510:20e::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.24; Fri, 8 Mar 2024 01:55:05 +0000 Received: from SJ1PEPF00001CDD.namprd05.prod.outlook.com (2603:10b6:a03:41b:cafe::71) by SJ0P220CA0015.outlook.office365.com (2603:10b6:a03:41b::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.27 via Frontend Transport; Fri, 8 Mar 2024 01:55:04 +0000 Received: from SATLEXMB03.amd.com (165.204.84.17) by SJ1PEPF00001CDD.mail.protection.outlook.com (10.167.242.5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7362.11 via Frontend Transport; Fri, 8 Mar 2024 01:55:04 +0000 Received: from SATLEXMB06.amd.com (10.181.40.147) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 7 Mar 2024 19:55:03 -0600 Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB06.amd.com (10.181.40.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 7 Mar 2024 19:55:02 -0600 Received: from henry-MS-7D54.amd.com (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend Transport; Thu, 7 Mar 2024 19:55:00 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e402671c-dcee-11ee-afda-a90da7624cb6 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=P1Zb0LmRdLxFMkCQtY9gpGwYCD7CklSEZ/wkEAjq8kUT+rI9oluL0YPOb9Vh8QnMRb+h3+dxQ19txY+azfcR9PpQRopoHZhEZWwvXwiWZcgEvUaQDbaWJuDkqXPT1MasnuPvBC0tNtULBAgQ3G4PBLKmyg7hvWcDSXAwlafKxOm9tH6L0qzK2md/91oac2TlQ3yb/2iy8h7KOo2GrGI5iebTZEas6vQzmpYRfSIc79aVEEHgsT7uUCTqNULEwZh4hoK3hePdvHB2JaZn8M2MXne2T69B+HinDMmClA0NW+V0FwrJh4rER/BkQ3ZRetRU7OMrZgxhxrywmrcN6F+fFg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=dchuisJ+SMUCW3UvJNt1sybC0OWRLBHo54+nPU/5Sjc=; b=S/9pQ+orprZ9xcyVM2Iz5Y+Kb5qUmgzaYikQHIAV+dh9dV3RJI3Ox0ibtTC2CbfZlX6hnlpTla0E1BpIPcOeLGMGbhZEyv4mo5QMUTrHwsvZ46X3UA9f3K+Cia0AcQn5ItnhMLSWshxlplmcQ57O2rDr5dLMr3itguoFe4P8KhwDBXq7vOGHFdn63jzVtjuO6+WhneFKOcd0d1xXnKSJ/BATdCuTNKZbwXV8qyo96bvGv31UKGEkgJn85mmKP0Nl8jdc1R7sGYfFuBV/2J/wNBO2MBH/HMymyL0puu1fWxj+VyFPAeBgMRTbL1/hX6VmM+Bylp1mKmLrfS6VlJpRSQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dchuisJ+SMUCW3UvJNt1sybC0OWRLBHo54+nPU/5Sjc=; b=b4KTavVIXCXaKuz7dY1cv0LrppCmcWY0LgsNpvKgLG8sJSq7kjeuZgePzgMoaTulYzT6T8cs6pdJSJhcwb2loOhw0yuI6ciN6RpGT62UC/qAPizkB9HF9SS6Qx3KEQjzoX7PcPCG//4MUKELrht3S1OPZTMHnYB2zCNIFS8BZcY= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C From: Henry Wang To: CC: Henry Wang , Wei Liu , Anthony PERARD , Andrew Cooper , George Dunlap , Jan Beulich , Julien Grall , Stefano Stabellini , Alec Kwapis Subject: [PATCH v2 5/5] xen/memory, tools: Make init-dom0less consume XEN_DOMCTL_get_mem_map Date: Fri, 8 Mar 2024 09:54:35 +0800 Message-ID: <20240308015435.4044339-6-xin.wang2@amd.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240308015435.4044339-1-xin.wang2@amd.com> References: <20240308015435.4044339-1-xin.wang2@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ1PEPF00001CDD:EE_|PH7PR12MB7455:EE_ X-MS-Office365-Filtering-Correlation-Id: e0b20390-affa-4904-1240-08dc3f12c609 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: hYS5GjdLVbARs8YBYv1+LhEnnAJk++V6YZLO7DGMPk4oBmPEHHKaxdk12rolQRQEqmHlOrwTPCCCr71C8uQvUcKC1vy84lCJaMFYMjbCcoLa+RxxTnCI2b/ianaYagcrgpDvL6zxSn383vFqGQCIjBlwhHLUueUqwFb7FCS5xQzED8ihBNJ3nJeIHAz+crWhpUoDxAoyqFO9Ex0imT1rs5qP+0XZLWd/SC06UJEKOjrcMrtvvYcZuFH6ST7E0CbIjgQlKFNQyO8T1faeJZvCNNKnjXI+Kf5xcLkQfXvMA9Xn6hLSfROahCU0IICoF+F7y35D4w/bcv+XD2AJ7DE0CmLYoFZVtDzOyK9R/qxCWHqGghtVR9Jehmu06FEebVU4YYiNGur2+oL3ZT837REZH6/wOywarJNx4KouzdsubsHNr1BSDtloGhNjbn7g7zl8mqQJvlpqL2AFP2a5Dza2wDpKPxfsaJgmnRfmTCLwAoKxs8inR5VwzpbXpH+kTjV7Ac4DWAHWMGwAEebSpyCA3QdtCj42k2eIVY15ykQX8v2a79TvspSBVqd4DJxg/lFshS1qc1CTXGVExsm4KvlwfMTv1wwIDy0eSj13AyTtU7fDG0tUdWiteMJFBBbXhsqg8+g3uAGZncsWsHpL4JHNM5YO3g8WvfEt4ctuKG/sfMuVpvcdHewanb3v3vOOXu02Fk6ShOOSEi9/y9OTTOe68TCLJFNApRDrshKayCiB7xF3pDl55i1ojIzI1lmyalFm X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(1800799015)(82310400014)(376005)(36860700004);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Mar 2024 01:55:04.2962 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e0b20390-affa-4904-1240-08dc3f12c609 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SJ1PEPF00001CDD.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB7455 Previous commits enable the toolstack to get the domain memory map, therefore instead of hardcoding the guest magic pages region, use the XEN_DOMCTL_get_mem_map domctl to get the start address of the guest magic pages region. Add the (XEN)MEMF_force_heap_alloc memory flags to force populate_physmap() to allocate page from domheap instead of using 1:1 or static allocated pages to map the magic pages. Reported-by: Alec Kwapis Signed-off-by: Henry Wang --- v2: - New patch --- tools/helpers/init-dom0less.c | 22 ++++++++++++++++++---- xen/common/memory.c | 10 ++++++++-- xen/include/public/memory.h | 5 +++++ xen/include/xen/mm.h | 2 ++ 4 files changed, 33 insertions(+), 6 deletions(-) diff --git a/tools/helpers/init-dom0less.c b/tools/helpers/init-dom0less.c index fee93459c4..92c612f6da 100644 --- a/tools/helpers/init-dom0less.c +++ b/tools/helpers/init-dom0less.c @@ -23,16 +23,30 @@ static int alloc_xs_page(struct xc_interface_core *xch, libxl_dominfo *info, uint64_t *xenstore_pfn) { - int rc; - const xen_pfn_t base = GUEST_MAGIC_BASE >> XC_PAGE_SHIFT; - xen_pfn_t p2m = (GUEST_MAGIC_BASE >> XC_PAGE_SHIFT) + XENSTORE_PFN_OFFSET; + int rc, i; + xen_pfn_t base = ((xen_pfn_t)-1); + xen_pfn_t p2m = ((xen_pfn_t)-1); + uint32_t nr_regions = XEN_MAX_MEM_REGIONS; + struct xen_mem_region mem_regions[XEN_MAX_MEM_REGIONS] = {0}; + + rc = xc_get_domain_mem_map(xch, info->domid, mem_regions, &nr_regions); + + for ( i = 0; i < nr_regions; i++ ) + { + if ( mem_regions[i].type == GUEST_MEM_REGION_MAGIC ) + { + base = mem_regions[i].start >> XC_PAGE_SHIFT; + p2m = (mem_regions[i].start >> XC_PAGE_SHIFT) + XENSTORE_PFN_OFFSET; + } + } rc = xc_domain_setmaxmem(xch, info->domid, info->max_memkb + (XC_PAGE_SIZE/1024)); if (rc < 0) return rc; - rc = xc_domain_populate_physmap_exact(xch, info->domid, 1, 0, 0, &p2m); + rc = xc_domain_populate_physmap_exact(xch, info->domid, 1, 0, + XENMEMF_force_heap_alloc, &p2m); if (rc < 0) return rc; diff --git a/xen/common/memory.c b/xen/common/memory.c index b3b05c2ec0..18b6c16aed 100644 --- a/xen/common/memory.c +++ b/xen/common/memory.c @@ -219,7 +219,8 @@ static void populate_physmap(struct memop_args *a) } else { - if ( is_domain_direct_mapped(d) ) + if ( is_domain_direct_mapped(d) && + !(a->memflags & MEMF_force_heap_alloc) ) { mfn = _mfn(gpfn); @@ -246,7 +247,8 @@ static void populate_physmap(struct memop_args *a) mfn = _mfn(gpfn); } - else if ( is_domain_using_staticmem(d) ) + else if ( is_domain_using_staticmem(d) && + !(a->memflags & MEMF_force_heap_alloc) ) { /* * No easy way to guarantee the retrieved pages are contiguous, @@ -1433,6 +1435,10 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg) && (reservation.mem_flags & XENMEMF_populate_on_demand) ) args.memflags |= MEMF_populate_on_demand; + if ( op == XENMEM_populate_physmap + && (reservation.mem_flags & XENMEMF_force_heap_alloc) ) + args.memflags |= MEMF_force_heap_alloc; + if ( xsm_memory_adjust_reservation(XSM_TARGET, curr_d, d) ) { rcu_unlock_domain(d); diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h index 5e545ae9a4..2a1bfa5bfa 100644 --- a/xen/include/public/memory.h +++ b/xen/include/public/memory.h @@ -41,6 +41,11 @@ #define XENMEMF_exact_node(n) (XENMEMF_node(n) | XENMEMF_exact_node_request) /* Flag to indicate the node specified is virtual node */ #define XENMEMF_vnode (1<<18) +/* + * Flag to force populate physmap to use pages from domheap instead of 1:1 + * or static allocation. + */ +#define XENMEMF_force_heap_alloc (1<<19) #endif struct xen_memory_reservation { diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h index bb29b352ec..a4554f730d 100644 --- a/xen/include/xen/mm.h +++ b/xen/include/xen/mm.h @@ -205,6 +205,8 @@ struct npfec { #define MEMF_no_icache_flush (1U<<_MEMF_no_icache_flush) #define _MEMF_no_scrub 8 #define MEMF_no_scrub (1U<<_MEMF_no_scrub) +#define _MEMF_force_heap_alloc 9 +#define MEMF_force_heap_alloc (1U<<_MEMF_force_heap_alloc) #define _MEMF_node 16 #define MEMF_node_mask ((1U << (8 * sizeof(nodeid_t))) - 1) #define MEMF_node(n) ((((n) + 1) & MEMF_node_mask) << _MEMF_node) -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Mar 08 02:05:16 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2024 02:05:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690095.1075795 (Exim 4.92) (envelope-from ) id 1riPbk-0007Ur-1O; Fri, 08 Mar 2024 02:05:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690095.1075795; Fri, 08 Mar 2024 02:05:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riPbj-0007Uk-Uk; Fri, 08 Mar 2024 02:05:11 +0000 Received: by outflank-mailman (input) for mailman id 690095; Fri, 08 Mar 2024 02:05:11 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riPbi-0007Ue-W4 for xen-devel@lists.xenproject.org; Fri, 08 Mar 2024 02:05:10 +0000 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on20600.outbound.protection.outlook.com [2a01:111:f403:2416::600]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 4a1c949d-dcf0-11ee-afda-a90da7624cb6; Fri, 08 Mar 2024 03:05:10 +0100 (CET) Received: from BY5PR16CA0002.namprd16.prod.outlook.com (2603:10b6:a03:1a0::15) by PH7PR12MB9176.namprd12.prod.outlook.com (2603:10b6:510:2e9::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7339.38; Fri, 8 Mar 2024 02:05:06 +0000 Received: from SJ5PEPF000001D3.namprd05.prod.outlook.com (2603:10b6:a03:1a0:cafe::13) by BY5PR16CA0002.outlook.office365.com (2603:10b6:a03:1a0::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.27 via Frontend Transport; Fri, 8 Mar 2024 02:05:05 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by SJ5PEPF000001D3.mail.protection.outlook.com (10.167.242.55) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7362.11 via Frontend Transport; Fri, 8 Mar 2024 02:05:05 +0000 Received: from SATLEXMB08.amd.com (10.181.40.132) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 7 Mar 2024 20:05:04 -0600 Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB08.amd.com (10.181.40.132) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 7 Mar 2024 18:05:04 -0800 Received: from [10.65.148.173] (10.180.168.240) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.35 via Frontend Transport; Thu, 7 Mar 2024 20:05:02 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 4a1c949d-dcf0-11ee-afda-a90da7624cb6 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VCn96wmVrCWJZXeGCR04Cq7hyzKDIdgAuQnX0i43Qy8MChoCHLFhMYYiv1va2/nPGXRFBEfYqw6O5mH28K8oKMlhH9SKI3dhft4YziXaAvNsNByMKcDt8Bdvm3P2zWB0o/TZZ62alXjmbtTSxghayjpR1zIaOezTKtvPBTC9k4iKQSVv/YKfnxYZQyUT55XYnHk8ZusVbmkuKQHDY0MoSGFNSUZ5N9u8xRcmkiqDAAf1d1iRX+0p8gkU8Q6KF9gPWQgJoTdRO+mjV8UnO019rl+hVN8WrKd153H80c3Y4JhxtuLkqQSy41ehgEaV6VtmBwhpcaU3fDVRS+76UYdZEg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=aWht1MNQ3Gq4RBQho9LuB0HNOJ172OUQAVl2sl/yOVc=; b=nGdNrZHyXomfRpm5fsHomH6jSGhGQA+jF+9irg3CRNesLoeOeMxi8yrzDdZKXrA6iwBEMbR61ZrkN5Ai7uWWW30mHFE0FKHE1Qy906ma1FV6T7IhGK20+Hr86018pcTZWOxlwLIXi3p0hEkf4MvDvIg21eZo/pFoxuK9AuddUuUxUwrDsDehx4WFW2FPaD6VKcxLwsAEPcb8GIbZGsvgBOtbocXD0twOGYBjsmsfnwBjX/V5iMVfK04Ofdq/ntp5pjSLvlOrq3mHcKkZh7ncJxS9e/uOtA1/y6U1oY1jyq5yiITEoqe+5k60E8cjUfOA30ShfCI7cBuAKdNM5KHm6g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=xen.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aWht1MNQ3Gq4RBQho9LuB0HNOJ172OUQAVl2sl/yOVc=; b=NpDqNBNqs34UBnbDiZgz6x7+z5dfXjqdMn9uBHaiZEGX7Vsq01/sUm7I3ylgQsj7RxfNWqP1AahCjXXdLRNS7WuRDbYZT0A/lBDGToqpY15t/asUikfMZkRQK5to+yP2i/hjvGtxNNiSA+QZmBuviFnyWk2cmnXlqeYATUEKfyg= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C Message-ID: <800eaf87-053a-424d-ad0e-2b725a37de89@amd.com> Date: Fri, 8 Mar 2024 10:05:01 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/arm: Set correct per-cpu cpu_core_mask To: Julien Grall , Bertrand Marquis , Stefano Stabellini , "xen-devel@lists.xenproject.org" CC: Michal Orzel , Volodymyr Babchuk References: <20240226030146.179465-1-xin.wang2@amd.com> Content-Language: en-US From: Henry Wang In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ5PEPF000001D3:EE_|PH7PR12MB9176:EE_ X-MS-Office365-Filtering-Correlation-Id: 736e2ed2-dc66-4a0d-4ef6-08dc3f142c34 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: zLrKSvoJftUOCbhgdYsaoVWnFwIli0xYAyRKIWeRE6Ai+e1908wpqTrfsxU2M2FpoPF0O9wm9L6ARrJO0WzNkMiAAOVMcnRpsiX24ltMTPfne69rAPFmHfr1WmWV6K/qkcgCtp4Fd903LOKInKEZ+Md0Hq4YxN3Mb05wYP31S8pwXBJ9Cff/cdDei/B7rbzfOjxxQebKtHMdYZleDcA/RwtbZRDXP4Q9pZXyd2ExXL913bUhu3pPQcdnhBNbikNrAmCxbmgVIjY/Vv/LTKde3vZpOg+NGWdW/V66yabvhRysR83yREbJ9l+8WULwLkuu+uRXz7LBIRzMbIB4Oj2LnVPTFjT35KdR0H+bt86I2KrmefQT5qbbwhkianqsX7O9F8gShumdCGXzd2WN+26JiGsGYqbfbLjIn7/QCfGn8ANFw1EC7/15tpge8qPl41tCP7eGR41+quRzoolJ2/QskboO1BnQAsEsixA+WIj17PSOLtJ9dV1lhfJhBVCT3ocQJVBag5/UVcD7ygVIwcmhP0wM51g/oxKnsxl3cQ4P8oHr+OOU6N7DASX3yQe5ATAkANuUh1tijCb83jh54fku6kb16kFNDbEWbbwUtO97B5R7uXeo29hfAsCeDaWgM34G2qP7NjGKw3igzuHhpzvzcsxhKcHc3wTTxMkyF4I2k2xTDQ4lkiiaQ7vnEZcwWG6NM2GN5/7WrJ9SwTf04Soq6g== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(1800799015)(36860700004)(376005)(82310400014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Mar 2024 02:05:05.2039 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 736e2ed2-dc66-4a0d-4ef6-08dc3f142c34 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SJ5PEPF000001D3.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB9176 Hi everyone, On 2/26/2024 6:43 PM, Michal Orzel wrote: >>>> xen/arch/arm/smpboot.c | 6 +++++- >>>> 1 file changed, 5 insertions(+), 1 deletion(-) >>>> >>>> + /* PE not implemented using a multithreading type approach. */ >>>> + if ( system_cpuinfo.mpidr.mt == 0 ) >>> Do we need this check? It mt was true, cpu_sibling_mask would be incorrect >>> anyway (it would still be 1). >> I added this check for playing safe, because I only want to do the correct thing >> in this patch and avoid make things worse for MT case. With this patch, non-MT >> case can be improved and the MT case is remain unchanged. >> >> But I agree with you, and I would be more than happy if I can run a MT setup and >> finish the "else" part with this patch or follow-ups. Do you know maybe qemu can >> allow me to emulate a MT setup so that I can fix it properly in v2? Thanks! > A65 is the only Arm CPU with SMT and I'm not aware of Qemu being able to emulate it. > AFAICT, in Xen on Arm we assume no SMT, hence my question about your check. With or without it, > some parts would still be incorrect (like cpu_sibling_mask), so what's the point in having a partial check. > I would keep your solution without the check. Others may have a different opinion though. Since there isn't much discussion followed-up in this thread, I am wondering do we have more inputs/opinions on this topic? If everyone agrees, I've followed Michal's suggestion in v2 [1]. [1] https://lore.kernel.org/xen-devel/20240228015822.56108-1-xin.wang2@amd.com/ Kind regards, Henry > ~Michal From xen-devel-bounces@lists.xenproject.org Fri Mar 08 05:58:57 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2024 05:58:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690106.1075805 (Exim 4.92) (envelope-from ) id 1riTFh-0000P4-Qq; Fri, 08 Mar 2024 05:58:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690106.1075805; Fri, 08 Mar 2024 05:58:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riTFh-0000Ox-NY; Fri, 08 Mar 2024 05:58:41 +0000 Received: by outflank-mailman (input) for mailman id 690106; Fri, 08 Mar 2024 05:58:40 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riTFf-0000Or-TF for xen-devel@lists.xenproject.org; Fri, 08 Mar 2024 05:58:40 +0000 Received: from mail133-16.atl131.mandrillapp.com (mail133-16.atl131.mandrillapp.com [198.2.133.16]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id e75db6c1-dd10-11ee-a1ee-f123f15fe8a2; Fri, 08 Mar 2024 06:58:37 +0100 (CET) Received: from pmta13.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail133-16.atl131.mandrillapp.com (Mailchimp) with ESMTP id 4Trb7t2KpYzB5pBbD for ; Fri, 8 Mar 2024 05:58:34 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 2a27077793ac411e905485c792ecbb46; Fri, 08 Mar 2024 05:58:34 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e75db6c1-dd10-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1709877514; x=1710138014; bh=751vofDCA/vRhU97VqgC+qIbx9vn2FxcZ1jcFyYQs/I=; h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=tga6kFnepwpS+zcmdONa4PBVCoQk3V+7BIIcOMOcMZKriGTZD8M0uLcKGuYZ6b3rn jB2/Dy+N8dD0ZBiOBBUjsEL12Cqn1N5+AByYp95lZtluItYBd5drdNDyQQmrMLOCU5 bsrxl5GC/GyGrsTgi3OYv7N21t0NCXI/U6gLddVX3YqABIJEwGDEZvJh2WSQmowOKW /zmqdNTyvxS+0aP3Cw4V2BvhaVrgQ06jOl8g+3VB1eauK9XwlpueFzWbEgMthB7QlB dEJzXpq8Qq6flqZQXQHJ0CW47Wb5ipOkuQGUy8QfN+sCpXwPUiXSESse/9YLYKVGW9 F7OU7xmRnc2vQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1709877514; x=1710138014; i=vaishali.thakkar@vates.tech; bh=751vofDCA/vRhU97VqgC+qIbx9vn2FxcZ1jcFyYQs/I=; h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=kcLEAHF9E3L6msK4iBuS1Kvb/wqKiaC7x52BdOcsXeHrN3xKMGQz6vYikkHvRN1o+ s7zsl8AaTbTtuijj+BXdezbAB/VlDyGt5x2SK1CEm7n3srbjk4pi53qwX5KfUPbClW B0hrTcBP1a4ofLHrM5I0GXPpKd3RDAuw+L52TRav9jS4AhZMYxVD8UNfG5PUpMyRrG ybnv2L6J3UBLwysrr40y1VuT1zloGHCQ2HeH35bzwL5WgUx7zwvD/yqYJ3o/2uDx60 53m6qXJoUsqi8Kh9dMbXzOIp/wcCEX6DKPeF7mxWvJYhS6O76RUhuP41cuUqWMzF4f X8nq1g1h1YySA== From: Vaishali Thakkar Subject: =?utf-8?Q?Re:=20[PATCH=201/2]=20x86/svm:=20Drop=20the=20=5Fenabled=20suffix=20from=20vmcb=20bits?= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1709877512995 Message-Id: <12ed3de3-294b-4154-9a16-ca038dc85173@vates.tech> To: Andrew Cooper , xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, roger.pau@citrix.com, wl@xen.org References: <3c419824febca229cedf2a3bd42cb68d3a3d56a8.1709846387.git.vaishali.thakkar@vates.tech> In-Reply-To: X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.2a27077793ac411e905485c792ecbb46?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20240308:md Date: Fri, 08 Mar 2024 05:58:34 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 3/8/24 00:22, Andrew Cooper wrote: > On 07/03/2024 9:40 pm, Vaishali Thakkar wrote: >> The suffix is redundant for np/sev/sev-es bits. Drop it >> to avoid adding extra code volume. >> >> Suggested-by: Andrew Cooper >> Signed-off-by: Vaishali Thakkar i > > Typo on the end of your email address? Oops, thanks for catching it. >> diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c >> index e4e01add8c..7e285cf85a 100644 >> --- a/xen/arch/x86/hvm/svm/nestedsvm.c >> +++ b/xen/arch/x86/hvm/svm/nestedsvm.c >> @@ -706,7 +706,7 @@ nsvm_vcpu_vmentry(struct vcpu *v, struct cpu_user_regs *regs, >> } >> >> /* nested paging for the guest */ >> - svm->ns_hap_enabled = !!ns_vmcb->_np_enable; >> + svm->ns_hap_enabled = !!ns_vmcb->_np; > > Because the type of is bool, the !! can be dropped too while changing > this line. Thanks for the review. As I'm sending the revised patchset anyway, will fix both things in this patch too. > It seems that this was missing cleanup from f57ae00635 "SVM: split > _np_enable VMCB field". > > Anyway, Reviewed-by: Andrew Cooper and I'm > happy to fix on commit. From xen-devel-bounces@lists.xenproject.org Fri Mar 08 06:02:13 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2024 06:02:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690110.1075815 (Exim 4.92) (envelope-from ) id 1riTJ5-0002JD-Bg; Fri, 08 Mar 2024 06:02:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690110.1075815; Fri, 08 Mar 2024 06:02:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riTJ5-0002J6-7D; Fri, 08 Mar 2024 06:02:11 +0000 Received: by outflank-mailman (input) for mailman id 690110; Fri, 08 Mar 2024 06:02:10 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riTJ4-0002Iw-3H for xen-devel@lists.xenproject.org; Fri, 08 Mar 2024 06:02:10 +0000 Received: from mail133-16.atl131.mandrillapp.com (mail133-16.atl131.mandrillapp.com [198.2.133.16]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 654c649d-dd11-11ee-afda-a90da7624cb6; Fri, 08 Mar 2024 07:02:08 +0100 (CET) Received: from pmta13.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail133-16.atl131.mandrillapp.com (Mailchimp) with ESMTP id 4TrbCz4kHBzB5p8ZB for ; Fri, 8 Mar 2024 06:02:07 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 706fbfc849da40c79c75a6093f27b8d5; Fri, 08 Mar 2024 06:02:07 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 654c649d-dd11-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1709877727; x=1710138227; bh=dAk+YeuwyP3EIAncoXFv7ngd3uVTOT0U1ZgR+Pf70fE=; h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=dsdU7Viqtr9zRJ3TFQOSecIGDKjWDikqVvzf0QmBGMEK0EF6s33XoE5x7WDT8Fesg s5Oepjo4ptxSSuFdHC7hP3b3eIanqT7/D5BxtGG2aqBc/gEXyiiJGMtj/lNF+3IwNF no3wcZ/IrH7Wx7kVmCvttJZiJl2ZWUOZ1sfUw9nbHGXu9oafdhx4L1ZLuCcgmuIvbd 4OOx0tG+fltitEVi1/Y/eLd8dpVL1FRXUiJspeC8DSqdEfm5h1kE2L3Pkpp0Q9NZe7 4O5JfY+p0oxQ7/tojYrDz6d4B8WQXuztGYcjDlxhczdAiIGA7UmrK8X4F3/AG4hJex /Huwnk4pQLR9w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1709877727; x=1710138227; i=vaishali.thakkar@vates.tech; bh=dAk+YeuwyP3EIAncoXFv7ngd3uVTOT0U1ZgR+Pf70fE=; h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=Xq8vUWoN/K+R3BWUSq6qu0wfy3avsrLbj4asr3kXPBv+FV20hN3Bvi6ErYpaT3dng KXr7GS+42IyVpNUG/umW8iKUcD07OSan7bxHPZmpJVnntvpmXanQP5jV01YRr19DgJ ajrBEkNhdYXT5N1mMgYy/iJk9ERfYTzSq5XroPYFyultBCoQssCPoTTPAKRjsR+dDQ 3f8sFnou4mdWmzA30Mv5jATc2s9G2MoKj6CPTPddS72bHuTr/5Oy8Qs83jdQ9Oo3Fp OMtUbARq/hA4veNTKq1iwdrvG8H4LTjFm8bGvx2P6BkAH3WdgSy51h4U/vCY0E0YtZ 0KByedCVFG6pA== From: Vaishali Thakkar Subject: =?utf-8?Q?Re:=20[PATCH=202/2]=20x86/svmdebug:=20Print=20sev=20and=20sev=5Fes=20vmcb=20bits?= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1709877726549 Message-Id: <1df84eaf-0a7b-4e35-b0ce-05989393e671@vates.tech> To: Andrew Cooper , xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, roger.pau@citrix.com, wl@xen.org References: <9cc6b407ec3b45f034b7deb6f5f44a561eecca47.1709846387.git.vaishali.thakkar@vates.tech> <715771bb-bff4-46d7-82b0-d0ad6d7a33ae@citrix.com> In-Reply-To: <715771bb-bff4-46d7-82b0-d0ad6d7a33ae@citrix.com> X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.706fbfc849da40c79c75a6093f27b8d5?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20240308:md Date: Fri, 08 Mar 2024 06:02:07 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 3/8/24 00:34, Andrew Cooper wrote: > On 07/03/2024 9:40 pm, Vaishali Thakkar wrote: >> diff --git a/xen/arch/x86/hvm/svm/svmdebug.c b/xen/arch/x86/hvm/svm/svmd= ebug.c >> index 24358c6eea..f54b426fb3 100644 >> --- a/xen/arch/x86/hvm/svm/svmdebug.c >> +++ b/xen/arch/x86/hvm/svm/svmdebug.c >> @@ -53,6 +53,8 @@ void svm_vmcb_dump(const char *from, const struct vmcb= _struct *vmcb) >> vmcb->exitinfo1, vmcb->exitinfo2); >> printk("np_ctrl =3D %#"PRIx64" guest_asid =3D %#x\n", >> vmcb_get_np_ctrl(vmcb), vmcb_get_guest_asid(vmcb)); >> + printk("sev =3D %d sev_es =3D %d\n", >> + vmcb_get_sev(vmcb), vmcb_get_sev_es(vmcb)); > > Hmm.=C2=A0 These are covered by the previous line printing all of np_ctrl= . > What about rearranging the previous line to be something like: > > printk("asid: %#x, np_ctrl: %#"PRIx64" -%s%s%s\n", > =C2=A0=C2=A0=C2=A0 vmcb->_asid, vmcb->_np_ctrl, > =C2=A0=C2=A0=C2=A0 vmcb->_np ? " NP" : "", > =C2=A0=C2=A0=C2=A0 vmcb->_sev ? " SEV" : "", > =C2=A0=C2=A0=C2=A0 ...); > > This is more compact (things like "guest" in "guest asid" is entirely > redundant), and provides both the raw _np_ctrl field and a bit-by-bit > decode on the same line, rather than having different parts of the info > on different lines and bools written out in longhand? Good point. Will change it in the revised v2. > See xen/arch/x86/spec_ctrl.c: print_details() for a rather more complete > example of this style of printk() rendering for bits, including how to > tabulate it for better readability. Thanks for pointing to the reference. > ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Mar 08 07:03:29 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2024 07:03:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690113.1075825 (Exim 4.92) (envelope-from ) id 1riUGD-0003Px-Al; Fri, 08 Mar 2024 07:03:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690113.1075825; Fri, 08 Mar 2024 07:03:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riUGD-0003Pq-70; Fri, 08 Mar 2024 07:03:17 +0000 Received: by outflank-mailman (input) for mailman id 690113; Fri, 08 Mar 2024 07:03:16 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riUGC-0003PW-EO for xen-devel@lists.xenproject.org; Fri, 08 Mar 2024 07:03:16 +0000 Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [2a00:1450:4864:20::635]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id ee241168-dd19-11ee-a1ee-f123f15fe8a2; Fri, 08 Mar 2024 08:03:13 +0100 (CET) Received: by mail-ej1-x635.google.com with SMTP id a640c23a62f3a-a44628725e3so210837266b.0 for ; Thu, 07 Mar 2024 23:03:13 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id k14-20020a170906a38e00b00a45f3524ac3sm103550ejz.118.2024.03.07.23.03.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Mar 2024 23:03:12 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ee241168-dd19-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709881393; x=1710486193; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=u65kGKGP9OS4t/YRB0fHFsYT9hmTBiOmEwHyF8Oinww=; b=N39IZ5kG94JTRepz4vpXzpLo4h69aGSQKxaeGaDwNvb1NoDLHKrT7ncEvq0XBwk9Ew A4yCeyilIMH10u045GMcmJ7Vy+2z58pu8WLTR4HLvlWo9rcKev4dPLriZJ+TRrRMLhQP HlTAGo4mmbQ17VYJEYdbep/L69UHcbLV41+R4FHWtYNlz3EcXaH19yeundRH3q4MRqiV 3l3U9x9KmzWFDCVewWhymFI47LO7ydJRbhoMpOVYZacIJ508Yz/k3eiOGdbI+WETXmJe MkSLkw+OVZIe3ZaAGLQ/wxbclYYjmYeVSRMDOkx8OzA+ynyvzeFwpkyrmvC8THz/nFcT +/mQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709881393; x=1710486193; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=u65kGKGP9OS4t/YRB0fHFsYT9hmTBiOmEwHyF8Oinww=; b=w8VNyQ7LUGJiksVUErfX4e/W6/Wqmf0T9PQbd/Kps5lSSG8sFQ39INWABkPOuqBhPJ +GL/SUXLpisiSedushVbeDDNIKI6j+Px+81hIcyKDrlPs1ZxSO+5aDIp6gi5C1hgGcFj ai+okr3wjkaNYq0Q4In2yrF9V8HTDmYwtbGYd91u9w69I1yqDCdSyPBqUYkllNRBB+vT VM6EQ6UZqgj9OKsvqXXes4/K7BcjPEYWUAbEhaw93nwoPdDlt7URWMhMgXXqo+q82h8w blhNaIOtQWtBQu0Avr3lGTjSXoT4j6uUQ1kK3b71+WJJcJOFPLC8/zEjVC9f1hvc3MWA EEhQ== X-Gm-Message-State: AOJu0YxCz5YrRCWQotd8zrO1zvUaJMZPAoSiIIlqx0PWQkl61IkeRkIW aNTKe0mpzBjpQGaDYZAbqNi5cNsiIBrEa3WS7vsHmNxWrALHAXMwX5eCU3TWEA== X-Google-Smtp-Source: AGHT+IEaEnJqREv01fQAU0+qpgaUs2hhF0cV375ZfNWdY/z62Pc0DE0bwGQIaxJiEeh6XqvCCAUNnw== X-Received: by 2002:a17:907:367:b0:a43:f020:57ed with SMTP id rs7-20020a170907036700b00a43f02057edmr13978704ejb.73.1709881392977; Thu, 07 Mar 2024 23:03:12 -0800 (PST) Message-ID: Date: Fri, 8 Mar 2024 08:03:11 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 0/3] x86/pvh: Support relocating dom0 kernel Content-Language: en-US To: Jason Andryuk Cc: xen-devel@lists.xenproject.org, Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <20240306185032.103216-1-jason.andryuk@amd.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 07.03.2024 18:33, Jason Andryuk wrote: > On 2024-03-07 05:20, Roger Pau Monné wrote: >> On Thu, Mar 07, 2024 at 11:08:37AM +0100, Jan Beulich wrote: >>> On 07.03.2024 11:00, Roger Pau Monné wrote: >>>> On Wed, Mar 06, 2024 at 01:50:29PM -0500, Jason Andryuk wrote: >>>>> Xen tries to load a PVH dom0 kernel at the fixed guest physical address >>>>> from the elf headers. For Linux, this defaults to 0x1000000 (16MB), but >>>>> it can be configured. >>>>> >>>>> Unfortunately there exist firmwares that have reserved regions at this >>>>> address, so Xen fails to load the dom0 kernel since it's not RAM. >>>>> >>>>> The other issue is that the Linux PVH entry point is not >>>>> position-independent. It expects to run at the compiled >>>>> CONFIG_PHYSICAL_ADDRESS. >>>>> >>>>> This patch set expands the PVH dom0 builder to try to relocate the >>>>> kernel if needed and possible. XENFEAT_pvh_relocatable is added for >>>>> kernels to indicate they are relocatable. However, we may want to >>>>> switch to an additional ELF note with the kernel alignment. Linux >>>>> specifies a kernel alignment in the bzImage boot_params.setup_header, >>>>> but that is not present the ELF vmlinux file. >>>> >>>> I wonder whether we need a pair of notes, to signal the min/max >>>> addresses the kernel supports being relocated to. >>> >>> Plus, as per your other reply, a 3rd one to specify alignment needs. >> >> Alignment we could in theory get from the ELF program header, if OSes >> fill those reliably. FreeBSD seems to do so, haven't checked Linux. > > I will look into this more, but at first glance, I don't see a > connection between Linux's CONFIG_PHYSICAL_ALIGN and the values in the > elf headers. As a quick test, I set CONFIG_PHYSICAL_ALIGN=0x800000, but > the elf align values are still 0x200000. > > The elf header values may be a suitable fallback though? Imo, given the above, explicit values should be required. Better not load a kernel than doing so and then getting hard to debug crashes. Jan From xen-devel-bounces@lists.xenproject.org Fri Mar 08 07:18:39 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2024 07:18:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690117.1075835 (Exim 4.92) (envelope-from ) id 1riUUx-0005XE-Ex; Fri, 08 Mar 2024 07:18:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690117.1075835; Fri, 08 Mar 2024 07:18:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riUUx-0005X7-Ax; Fri, 08 Mar 2024 07:18:31 +0000 Received: by outflank-mailman (input) for mailman id 690117; Fri, 08 Mar 2024 07:18:30 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riUUw-0005X1-AA for xen-devel@lists.xenproject.org; Fri, 08 Mar 2024 07:18:30 +0000 Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [2a00:1450:4864:20::52f]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 0eab2fbe-dd1c-11ee-a1ee-f123f15fe8a2; Fri, 08 Mar 2024 08:18:27 +0100 (CET) Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-564372fb762so627079a12.0 for ; Thu, 07 Mar 2024 23:18:27 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id l13-20020aa7d94d000000b0056828004c75sm579845eds.51.2024.03.07.23.18.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Mar 2024 23:18:26 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 0eab2fbe-dd1c-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709882306; x=1710487106; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=QfZcAyokEhcr3g+gmO7LAD2eQKRA9xZssWV+SW3Ru+c=; b=DL+qEZEUKfvCYBmb8uzbsIt2EVreekv8i90weqlOHRufoV0n0gcb9SK76mtlydT25r KKRMZr8wVqRGGMoZZ4tCJusu98GwSaxEFTOWVq8VZELAy2PKBi0/xT60sLzzoD3w3avM 8ymBNgW+wqxkQmlUQOvlursRid+1GlMr9EIbDmFsdldrs7p7/3/XdqT5ZwfTMUbRWcMF /rJRjXMIdHvl6a5oxG7zEfC/YkLXPyT6N0FpJ3OLAWH4FK3/kkWWQhmVvjOeUYtZsQoU SKvlio1x4JoYYRo3iegu6wR+TmIQuT5AYumXc+5HJ4ZHjnKMHh14RGscNiNYdUejvAMH b1vA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709882306; x=1710487106; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=QfZcAyokEhcr3g+gmO7LAD2eQKRA9xZssWV+SW3Ru+c=; b=CUVHOnOk4sw10AGu9azeQubPw186Wt0PuVm1RLeDFjZTbnsT1zz5I0hGiEeeMVap8j Yl0qtBiJV4PFlYi7v/1NsRTCk2B928OVmJsoW1hy4brGg+BA/5Eqwj4E6GxSlE25T0Vc ZOKY3ljq7OhsXNofdyh2bm12sSod94ODSX0r9Iv8ogSGCwTWxlh/PJ+w21yu8dgshngy v26a0VlEglBI2himFqXocUhLuFVIcqaXD7JC5fymgnhFAVyzJb4gQcGa5w91ZpVMUyL3 YAcAmnFs/d47jHJeAbsAahUiOx3iTNZeRHHi+h6R3+Rds5p7Vt0JSsS//ZB2LgG7e4nB 043Q== X-Forwarded-Encrypted: i=1; AJvYcCVCtxX++RcS6RGyR1s8OfO+/SeSTLDBWSmvSlnX55BR1CVSl2bLHrePzCGz12aJiyoIrxSvFovoLlZUOKdcn+s612PBXTD1evMdaxpc4qM= X-Gm-Message-State: AOJu0Yx2Ng5s2kFnmXhf0UiBsmPvn7OPj635FrMDniZVuryBH5qD2E9x IWVLucJik2P5sr/a/XlZaZypeauUmm1jpAkrnmMyt35m8zmUZGr2s6oOP7w+ZQ== X-Google-Smtp-Source: AGHT+IGJy7zMTfl2hzXYs/0qb354ygpOPOx5PjLGAyXyLhohemM1LAVzVE3VNFv9jSyeWT3SkX6L7A== X-Received: by 2002:a05:6402:2311:b0:568:1599:b854 with SMTP id l17-20020a056402231100b005681599b854mr1146266eda.42.1709882306603; Thu, 07 Mar 2024 23:18:26 -0800 (PST) Message-ID: Date: Fri, 8 Mar 2024 08:18:25 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 12/23] xen/riscv: introduce io.h Content-Language: en-US To: Oleksii Cc: Alistair Francis , Bob Eshleman , Connor Davis , Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu , xen-devel@lists.xenproject.org References: <807c31d5-0c5a-4646-ba90-2f284289069f@suse.com> <2a3e49bf94332c17b50e4f0f745e4b28b16dceb1.camel@gmail.com> <2a05c233-b3c5-417c-bd6b-8b1c21f03c3d@suse.com> <9ec718f3bba178d437035add3c7467011fc3ffc0.camel@gmail.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <9ec718f3bba178d437035add3c7467011fc3ffc0.camel@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 07.03.2024 21:49, Oleksii wrote: > On Thu, 2024-03-07 at 18:14 +0100, Jan Beulich wrote: >> For plain writes it should at least be "=Qo" then, yes. > Constraints Q is a machine specific constraint, and I am not sure that > it makes sense to use "=o" only and probably it is a reason why it is > enough only "r". Does it make sense? Especially the 'only "r"' part doesn't, no. I also don't see why "=o" would make no sense - that's fundamentally no different than "=m". Unless the immediates used in the ultimate insns are large enough to cover the full range of possible values, my take is that "o" is never appropriate to use. With one exception in a case like we have here: If the operand isn't used in the actual instruction(s), then that's fine, as the specific value of the adjusted immediate wouldn't matter at all. As to "Q" - that's an Arm constraint anyway, not a RISC-V one? If so, I'm not sure why we're discussing it here. In any event, I'd be curious to understand in how far the combination "Qo" makes sense. >> To me making those >> input operands on Arm can't have been quite right. > I don't understand why they both are input, logically it looks like an > address should be an output. How would an address be an output, when that's needed to be calculated for the memory access to take place? It would be an output (and presumably a dummy/fake one) only if the address calculation was done in the asm() itself (and there I don't mean the operands, but the actual assembly instruction(s)). Jan From xen-devel-bounces@lists.xenproject.org Fri Mar 08 07:24:35 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2024 07:24:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690119.1075846 (Exim 4.92) (envelope-from ) id 1riUal-0007bu-3i; Fri, 08 Mar 2024 07:24:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690119.1075846; Fri, 08 Mar 2024 07:24:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riUak-0007bn-VB; Fri, 08 Mar 2024 07:24:30 +0000 Received: by outflank-mailman (input) for mailman id 690119; Fri, 08 Mar 2024 07:24:30 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riUak-0007bb-87; Fri, 08 Mar 2024 07:24:30 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riUak-0001OU-2u; Fri, 08 Mar 2024 07:24:30 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riUaj-0004V4-OK; Fri, 08 Mar 2024 07:24:29 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1riUaj-0003jc-Np; Fri, 08 Mar 2024 07:24:29 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=Qki+9zyBeHrK6+8JIBTbPQjE6dsjVQJhTex70u2qccI=; b=pzgjjnUO0wpf1pt9RYJUGBLsA8 FbGcH7UmeB1rzMZ7H7nRYlGSC8rd26BVme5nLmoqrUbny9h+b1I/hFThomE+ObThIA5EC7aJrcdXc j9pvQoJzB8MAVs/aooeWLQY4o9fjbyq0vEIGpV1LCNzC3fCgPsNppTbUDbUhXg7UtKs0=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-linus test] 184931: tolerable FAIL - PUSHED X-Osstest-Failures: linux-linus:test-armhf-armhf-libvirt-qcow2:guest-start.2:fail:heisenbug linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: linux=67be068d31d423b857ffd8c34dbcc093f8dfff76 X-Osstest-Versions-That: linux=29cd507cbec282e13dcf8f38072a100af96b2bb7 From: osstest service owner Date: Fri, 08 Mar 2024 07:24:29 +0000 flight 184931 linux-linus real [real] flight 184941 linux-linus real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/184931/ http://logs.test-lab.xenproject.org/osstest/logs/184941/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-libvirt-qcow2 18 guest-start.2 fail pass in 184941-retest Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop fail like 184912 test-armhf-armhf-libvirt 16 saverestore-support-check fail like 184912 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop fail like 184912 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop fail like 184912 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 184912 test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail like 184912 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop fail like 184912 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184912 test-amd64-amd64-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl 15 migrate-support-check fail never pass test-arm64-arm64-xl 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 15 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 15 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 15 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-check fail never pass test-armhf-armhf-libvirt 15 migrate-support-check fail never pass test-amd64-amd64-libvirt-qcow2 14 migrate-support-check fail never pass test-amd64-amd64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-check fail never pass test-arm64-arm64-xl-vhd 14 migrate-support-check fail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-check fail never pass version targeted for testing: linux 67be068d31d423b857ffd8c34dbcc093f8dfff76 baseline version: linux 29cd507cbec282e13dcf8f38072a100af96b2bb7 Last test of basis 184912 2024-03-05 21:44:46 Z 2 days Failing since 184917 2024-03-06 08:16:51 Z 1 days 3 attempts Testing same since 184931 2024-03-07 12:02:46 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrey Skvortsov Arnd Bergmann Bart Van Assche Bjorn Andersson Christian Brauner Conor Dooley Daniel Baluta David Howells Dawei Li Dmitry Baryshkov Eric Biggers Fabio Estevam Francesco Dolcini Francesco Dolcini # Toradex Colibri iMX7 Georgi Djakov Herbert Xu Jens Wiklander Jernej Skrabec Johan Hovold Jon Hunter Kamalesh Babulal Konrad Dybcio Linus Torvalds Liu Ying Marek Vasut Neil Armstrong Shawn Guo Sumit Garg Tejun Heo Thierry Reding Tong Tiangen Waiman Long jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-amd64-dom0pvh-xl-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-freebsd11-amd64 pass test-amd64-amd64-freebsd12-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-examine-bios pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-amd64-dom0pvh-xl-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-amd64-xl-pvshim pass test-amd64-amd64-pygrub pass test-amd64-amd64-libvirt-qcow2 pass test-armhf-armhf-libvirt-qcow2 fail test-amd64-amd64-libvirt-raw pass test-arm64-arm64-libvirt-raw pass test-armhf-armhf-libvirt-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-examine-uefi pass test-amd64-amd64-xl-vhd pass test-arm64-arm64-xl-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these 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 : hint: The 'hooks/update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-receive' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. To xenbits.xen.org:/home/xen/git/linux-pvops.git 29cd507cbec28..67be068d31d42 67be068d31d423b857ffd8c34dbcc093f8dfff76 -> tested/linux-linus From xen-devel-bounces@lists.xenproject.org Fri Mar 08 07:26:24 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2024 07:26:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690124.1075856 (Exim 4.92) (envelope-from ) id 1riUcZ-0008Cs-J6; Fri, 08 Mar 2024 07:26:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690124.1075856; Fri, 08 Mar 2024 07:26:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riUcZ-0008Cl-Eb; Fri, 08 Mar 2024 07:26:23 +0000 Received: by outflank-mailman (input) for mailman id 690124; Fri, 08 Mar 2024 07:26:22 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riUcY-0008Cf-4s for xen-devel@lists.xenproject.org; Fri, 08 Mar 2024 07:26:22 +0000 Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [2a00:1450:4864:20::632]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 28a2e7fb-dd1d-11ee-a1ee-f123f15fe8a2; Fri, 08 Mar 2024 08:26:20 +0100 (CET) Received: by mail-ej1-x632.google.com with SMTP id a640c23a62f3a-a45bdf6e9c2so210683366b.0 for ; Thu, 07 Mar 2024 23:26:20 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id dl7-20020a170907944700b00a45f39b2d16sm89600ejc.200.2024.03.07.23.26.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Mar 2024 23:26:19 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 28a2e7fb-dd1d-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709882780; x=1710487580; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=uTWcfXJrYzYS20fiF3OEBcA73p13jR931MWUyarmd+8=; b=YLWjM1k43Dmu/Rzm/cfU6gviVBLprevUUZN3D+cwrTf0o7sLAYWAKETY+LKr27ei65 GSqGDnBBqGjYdXLzrfjNF5zl10bEUhFd9XkP82ZYDaIZyF6le6kAViBVxxeYd3D0KFVw UccEUpQ375daYgodswFy6kSAGGluErLPAYOfC8/cj6FozqJugXA0reZAvf6/uYvCUtXK Glja7orXgFY9kCHKrkola7eSX3pDX/G3ux79ROWzuOPEouoeIONb0Cr0OcRUWlX4o7Dz XbRvwLdqhDXzIrvd/13lcCOzLuD2aicFC58cV5QpezHfIw5QlhcGhsPk6HuThFwGwrN9 nxsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709882780; x=1710487580; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=uTWcfXJrYzYS20fiF3OEBcA73p13jR931MWUyarmd+8=; b=KZqJ9c+JTBKPnS+198vf6TjRIye4OLLqApB0XELcwUGmlmZ1td+01InfmP8UMwaZ6Y XGbe5uRfL9+wyrYm4GXXXQzL3b3q0QDpVXJ/bjuzxbmtCkrOQfE4kWj/bdFOMo5K7KX2 9vGuYNu+cbpL1YIK2h+ltHNCBV4LPSoJ8ADauPWrlR2MwYMm2aoLTU6Ic6gO/OK6WHVM sRJhaVEj6PcPokxjhOj7/M3mzljDBvJdjq2RZSTGrdRoORkof0bhpc9fMHBu4irmyAz5 QONbJoRFav0R+/8+qfZAviUyMPU0LycL4d3ySLv3lLFDvOlTZVHb36kHQR7qPO/+mlIN aURA== X-Forwarded-Encrypted: i=1; AJvYcCUEX+FXBuATYTVNPDBDm+8tuOn76HTyKHMW/Bm3e7j9g5ZjbgKcCESqSJcgoXPYWjn2B86sZb5YDGVK/j63XxBMwKnbOLlL1lImizyVCJg= X-Gm-Message-State: AOJu0YwuAyFmWXfnqb7I+40eatpA3PLH4+2Cg2hHH5Etik7+0D1C+/bY np8aHDX1PdQntDT3w0gMhPWO7LpW5nDU6XqPpSEkTI3axPR3QZ5q+ljNSxjW9A== X-Google-Smtp-Source: AGHT+IHA8ulfjCOmXk9YJlfxOprdM0oT+hgSeYyia3ycXFOHD3gEbhv6SDsKzyWHGqQ/6pqIlVxV/Q== X-Received: by 2002:a17:906:f0d1:b0:a45:a448:b08f with SMTP id dk17-20020a170906f0d100b00a45a448b08fmr7493101ejb.54.1709882779680; Thu, 07 Mar 2024 23:26:19 -0800 (PST) Message-ID: <82375df2-f7fd-43a1-9183-f4823fe791ec@suse.com> Date: Fri, 8 Mar 2024 08:26:18 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 12/23] xen/riscv: introduce io.h Content-Language: en-US To: Oleksii Cc: Alistair Francis , Bob Eshleman , Connor Davis , Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu , xen-devel@lists.xenproject.org References: <807c31d5-0c5a-4646-ba90-2f284289069f@suse.com> <2a3e49bf94332c17b50e4f0f745e4b28b16dceb1.camel@gmail.com> <2a05c233-b3c5-417c-bd6b-8b1c21f03c3d@suse.com> <9ec718f3bba178d437035add3c7467011fc3ffc0.camel@gmail.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 07.03.2024 21:54, Oleksii wrote: > On Thu, 2024-03-07 at 21:49 +0100, Oleksii wrote: >> On Thu, 2024-03-07 at 18:14 +0100, Jan Beulich wrote: >>> For plain writes it should at least be "=Qo" then, yes. >> Constraints Q is a machine specific constraint, and I am not sure >> that >> it makes sense to use "=o" only and probably it is a reason why it is >> enough only "r". Does it make sense? > Probably for RISC-V can be used: > RISC-V—config/riscv/constraints.md > ... > A > An address that is held in a general-purpose register. > ... Just from the description I would have said no, but looking at what "A" actually expands to it is indeed RISC-V's counterpart of Arm's "Q". So yes, this looks like what amo* want to use, and then as a real operand, not just a fake one. > AArch64 family—config/aarch64/constraints.md: > ... > Q > A memory address which uses a single base register with no > offset > ... > Also 'no offset' explains why it was added 'o' constraint for Arm > additionally. I don't think it does. Jan From xen-devel-bounces@lists.xenproject.org Fri Mar 08 07:29:53 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2024 07:29:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690128.1075865 (Exim 4.92) (envelope-from ) id 1riUfs-0000yo-23; Fri, 08 Mar 2024 07:29:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690128.1075865; Fri, 08 Mar 2024 07:29:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riUfr-0000yh-UT; Fri, 08 Mar 2024 07:29:47 +0000 Received: by outflank-mailman (input) for mailman id 690128; Fri, 08 Mar 2024 07:29:47 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riUfr-0000yb-56 for xen-devel@lists.xenproject.org; Fri, 08 Mar 2024 07:29:47 +0000 Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [2a00:1450:4864:20::532]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id a2d8a960-dd1d-11ee-a1ee-f123f15fe8a2; Fri, 08 Mar 2024 08:29:45 +0100 (CET) Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-563cb3ba9daso1963057a12.3 for ; Thu, 07 Mar 2024 23:29:45 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id k15-20020aa7c38f000000b00568229390f2sm877985edq.70.2024.03.07.23.29.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Mar 2024 23:29:44 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a2d8a960-dd1d-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709882985; x=1710487785; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=T4TSznoAriWsUNcIPeGIus6j96yiP1D9gFaPIigEgJM=; b=aUxr6cKRfVl0Xkbz9UfqQY42H7kgelg4dCSIEzZ7Y0tc77z7NxmokRLRy8sArHmBEy 558Y7BzmPXveFADht1krkUrWPdNiwHuD36DWm7Kwk49hUvvCuPmO4WIpxWNDPUGqzLMG M1juSHU9+dGnB/MSZ03XXTUPPSUh48fQKR9+ZC+0V7xZVelojfh1s3TOQZwwnaScctwn n+xTQM7jsrs17nJLmdMiwkUbyFqdoMqBsNv44MzVaFIVRRvXJnpowCsIv2LUy/3igoxZ b6ELgNnVidTw6O7CEySplylgxzAmfzc32+T/6iLSHuQ49L4xeJJmgTddhZmgvmvrPd5e vwPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709882985; x=1710487785; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=T4TSznoAriWsUNcIPeGIus6j96yiP1D9gFaPIigEgJM=; b=pYcH6086Mg+Aug1fwmsi5gV6d0zAOELoaHeJWkME4qiYjoLYnJw/FkkVf1BNNKfYDk JCvkMsJ9Ysz/rjwc9+oRAXzFKy6Nv2sxvt78+lt9DLG8i8cmtOijyrCIiqDjN0765Fll ok4XWexyY8mMgeIcwoJ3/KfCvse3rEhw4PPC4tfr47GoGqXnl65m7Tk38EV1xunY1HNC lS0XkFFTXT+Fe0pIuvF2e0adopkCpAq2dN1AOuaYcs9U4bfSwz7OKoWLCRzes+waQVqn tIfQDnqtRGnKKXCJxbRYmw2iDCZglRvSAOgluN7UX5keI/uvYkyhBfuqJDlZfCv2LnT0 iFqw== X-Forwarded-Encrypted: i=1; AJvYcCUtXp8kFPB/LxJDoTLwuRzsiwWS4Tw0Pyh4yKJuB/vKHDzJSDlNYlxFyc1kfTvoRt7YlfLOVrC+kJ6iRJaJPmtacyLGWZftldaqdzG5J+w= X-Gm-Message-State: AOJu0Yy+rg8aoQq79KZln5i54APghZWFCXLGEAjr3ccfqdcVJrM/nP6z P/Qk4w/wxsvnGTHgRVWbTFuXbR5eU0mQ1R5U043dZxC9XkQ/XQq/0+GETvrpbQ== X-Google-Smtp-Source: AGHT+IFOjqxwB69wkNyorCEMKbKNzwn7ir1b9yKiAyY5+588AN3u+dJXBTao6aGKYGjreGjp+Z4iGg== X-Received: by 2002:a50:8ad7:0:b0:565:f90c:1263 with SMTP id k23-20020a508ad7000000b00565f90c1263mr1418333edk.9.1709882984739; Thu, 07 Mar 2024 23:29:44 -0800 (PST) Message-ID: <267da690-b925-4679-8462-a7f91f8efd65@suse.com> Date: Fri, 8 Mar 2024 08:29:43 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] x86/svm: Drop the _enabled suffix from vmcb bits Content-Language: en-US To: Vaishali Thakkar Cc: andrew.cooper3@citrix.com, roger.pau@citrix.com, wl@xen.org, xen-devel@lists.xenproject.org References: <3c419824febca229cedf2a3bd42cb68d3a3d56a8.1709846387.git.vaishali.thakkar@vates.tech> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <3c419824febca229cedf2a3bd42cb68d3a3d56a8.1709846387.git.vaishali.thakkar@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 07.03.2024 22:40, Vaishali Thakkar wrote: > --- a/xen/arch/x86/hvm/svm/nestedsvm.c > +++ b/xen/arch/x86/hvm/svm/nestedsvm.c > @@ -571,7 +571,7 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct cpu_user_regs *regs) > if ( nestedhvm_paging_mode_hap(v) ) > { > /* host nested paging + guest nested paging. */ > - n2vmcb->_np_enable = 1; > + n2vmcb->_np = 1; Given the field is bool, "true" here and elsewhere as well as ... > @@ -601,7 +601,7 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct cpu_user_regs *regs) > else > { > /* host shadow paging + guest shadow paging. */ > - n2vmcb->_np_enable = 0; > + n2vmcb->_np = 0; ... "false" here (and once again further down)? Jan From xen-devel-bounces@lists.xenproject.org Fri Mar 08 08:10:42 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2024 08:10:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690137.1075874 (Exim 4.92) (envelope-from ) id 1riVJG-0000fE-CN; Fri, 08 Mar 2024 08:10:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690137.1075874; Fri, 08 Mar 2024 08:10:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riVJG-0000f7-8x; Fri, 08 Mar 2024 08:10:30 +0000 Received: by outflank-mailman (input) for mailman id 690137; Fri, 08 Mar 2024 08:10:28 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riVJE-0000f0-KY for xen-devel@lists.xenproject.org; Fri, 08 Mar 2024 08:10:28 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 52010593-dd23-11ee-a1ee-f123f15fe8a2; Fri, 08 Mar 2024 09:10:26 +0100 (CET) Received: from nico.bugseng.com (unknown [46.228.253.194]) by support.bugseng.com (Postfix) with ESMTPSA id A63524EE0738; Fri, 8 Mar 2024 09:10:24 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 52010593-dd23-11ee-a1ee-f123f15fe8a2 From: Nicola Vetrini To: nicola.vetrini@bugseng.com, xen-devel@lists.xenproject.org Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, consulting@bugseng.com, bertrand.marquis@arm.com, julien@xen.org, Andrew Cooper , George Dunlap , Jan Beulich , Wei Liu Subject: [XEN PATCH] xen/compiler: deviate the inline macro for MISRA C Rule 20.4 Date: Fri, 8 Mar 2024 09:10:21 +0100 Message-Id: X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Rule 20.4 states: "A macro shall not be defined with the same name as a keyword". Defining this macro with the same name as the inline keyword allows for additionally checking that out-of-lined static inline functions end up in the correct section while minimizing churn and has a positive impact on the overall safety. See [1] for additional context on the motivation of this deviation. No functional change. [1] https://lore.kernel.org/xen-devel/adaa6d55-266d-4df8-8967-9340080d17e4@citrix.com/ Signed-off-by: Nicola Vetrini --- docs/misra/safe.json | 8 ++++++++ xen/include/xen/compiler.h | 1 + 2 files changed, 9 insertions(+) diff --git a/docs/misra/safe.json b/docs/misra/safe.json index 952324f85cf9..a2bbacddf06a 100644 --- a/docs/misra/safe.json +++ b/docs/misra/safe.json @@ -28,6 +28,14 @@ }, { "id": "SAF-3-safe", + "analyser": { + "eclair": "MC3R1.R20.4" + }, + "name": "MC3R1.R20.4: allow the augmentation of the inline keyword in some build configurations", + "text": "The definition of this macro named inline allows further checking in some build configurations that certain symbols end up in the right sections." + }, + { + "id": "SAF-4-safe", "analyser": {}, "name": "Sentinel", "text": "Next ID to be used" diff --git a/xen/include/xen/compiler.h b/xen/include/xen/compiler.h index 16d554f2a593..e3d9f9fb8e4b 100644 --- a/xen/include/xen/compiler.h +++ b/xen/include/xen/compiler.h @@ -82,6 +82,7 @@ * inline functions not expanded inline get placed in .init.text. */ #include +/* SAF-3-safe MISRA C Rule 20.4: define the inline macro to perform checks */ #define inline inline __init #endif -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Mar 08 08:18:26 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2024 08:18:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690141.1075884 (Exim 4.92) (envelope-from ) id 1riVQs-0001lj-1R; Fri, 08 Mar 2024 08:18:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690141.1075884; Fri, 08 Mar 2024 08:18:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riVQr-0001lc-V0; Fri, 08 Mar 2024 08:18:21 +0000 Received: by outflank-mailman (input) for mailman id 690141; Fri, 08 Mar 2024 08:18:20 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riVQq-0001lV-Pp for xen-devel@lists.xenproject.org; Fri, 08 Mar 2024 08:18:20 +0000 Received: from NAM02-BN1-obe.outbound.protection.outlook.com (mail-bn1nam02on20601.outbound.protection.outlook.com [2a01:111:f403:2407::601]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 6adf07dd-dd24-11ee-afda-a90da7624cb6; Fri, 08 Mar 2024 09:18:18 +0100 (CET) Received: from CYZPR05CA0025.namprd05.prod.outlook.com (2603:10b6:930:a3::26) by PH7PR12MB6979.namprd12.prod.outlook.com (2603:10b6:510:1b9::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.26; Fri, 8 Mar 2024 08:18:15 +0000 Received: from CY4PEPF0000E9D8.namprd05.prod.outlook.com (2603:10b6:930:a3:cafe::c2) by CYZPR05CA0025.outlook.office365.com (2603:10b6:930:a3::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7270.17 via Frontend Transport; Fri, 8 Mar 2024 08:18:14 +0000 Received: from SATLEXMB03.amd.com (165.204.84.17) by CY4PEPF0000E9D8.mail.protection.outlook.com (10.167.241.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7362.11 via Frontend Transport; Fri, 8 Mar 2024 08:18:14 +0000 Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Fri, 8 Mar 2024 02:18:13 -0600 Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend Transport; Fri, 8 Mar 2024 02:18:12 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6adf07dd-dd24-11ee-afda-a90da7624cb6 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OWPc4cajZmRnA2RhpiRSvId2fIIcm+Vmpu77pK6gMs1naY0dfRe2Q6dh/JpQq/tr1rL5Ish+u5CRwVm+vs3Snit4adOfnesYM8lRZ+RSTq8C7uixg1UYZPfd6/0Mbf0Bas/wis+T0GLoIwWgJufIrSqrv+vTDAjREcUnrBlM4uuUxCAYcRPb7zAULpZUwHnTvYqoGBNRxTeGcfo6qzwlgmh0cT1dunhbyres3weYUZHN929B0HcmRIgQuq7ttihfXYWTztNEYJi7IuUlKQYkyerrxOZ7ETDC/1yD4slycyNXBJkk6dZXoVy/Dr7hCNhRw6K1wT+CRpCHu8VsFParPQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=/o/qfVD/Fv0BwhkYHbhR/IRyVl9FYyao5rHFVXRWxes=; b=H9lardNGijMNj7PUOu1qgIzXMpQ2RaLO8YOSsxQCft4dlzwy6nrbOdKvprsJlAmgGyZTL3eTjUcPeHVtEfdzHkYVvjPTTJzATQAqT6iXeaPWkDbmXdmNGw8B+uHvRMSQErrfwBA2xIDX1LmGf3/fLSftBKHyCj5wk9b1aP41LxIbMEETwBAoO9h7n6b3XT/2yarjw+wgVXLGtf3nfEYT9A3HlR+P4IqI/2LZ6A8+v4ury4dhYVyy2sCu9hPdBR4rDGivQS02u61aBneBStDge9iKk/CzpDqvKIbre7TD1ZFKadaJwsJIoPHugp7teDHzdmD5StwsGXwO7djW1ZZx0g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/o/qfVD/Fv0BwhkYHbhR/IRyVl9FYyao5rHFVXRWxes=; b=HWhAg5bBn1lIwO6SgVW0hoAzKc/7VoxybmvFKyqVwSe3xxYuR0kPyydEzfuU86c5954hFVRQCFuC56YwJ7wBoJtL8R5TTJQml5mlgnnSg47djoGgaRyGzdDfWPmqpkctHUo6LZCVtLdiDgjmfzw8et4PzsHMhxzxnjxFe+IOi08= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C Message-ID: <50342ff8-ddc7-44a9-9166-9755edf44782@amd.com> Date: Fri, 8 Mar 2024 09:18:11 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/5] xen/arm: Rename assign_static_memory_11() for consistency Content-Language: en-US To: Henry Wang , CC: Stefano Stabellini , Julien Grall , Bertrand Marquis , "Volodymyr Babchuk" References: <20240308015435.4044339-1-xin.wang2@amd.com> <20240308015435.4044339-2-xin.wang2@amd.com> From: Michal Orzel In-Reply-To: <20240308015435.4044339-2-xin.wang2@amd.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Received-SPF: None (SATLEXMB03.amd.com: michal.orzel@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CY4PEPF0000E9D8:EE_|PH7PR12MB6979:EE_ X-MS-Office365-Filtering-Correlation-Id: eacab02f-2ff5-4e8e-41ce-08dc3f484d29 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: J4wUinicne5/QGGHH++g92uDrBCTZe2rTqFev7gv3qcMsxiIhQFzk1rb8A5EHAjmCgVdu/KkLKdJFfi6duRTrNlb7seg5OqBBXpLX/hUQOJ0VdVwulSIRs1dGhD2c6GjWNRDFe66+KsLwnjLVxcp+WbQ3303sHkZGM1Fg/29A82ly+uAioynFAusawPZW6NX5bhnEDuKAh3NaJmDQgCCx2HXKdXUWKH6lrQ7kuzLN4jPxgXmUE4LV78NZMGvGXlk2XalhEDgE+sJ8+uM2HeqqjyH7L0ULwzXyns4VS3+Wk++PDjyPviSjbCMQgCTGLf6MOPP8aYL0J/B1PdqxCHevmEZoAUzH1civtpVdbMx29tC2G8CSx9mj3Ve6SHsZz2QYn8mYHDJR8+X/SDt8tHQSKczu5SaS8lvIY2FG5ax8IYXtDMYKsGHX2XGZAGhlk9THgx1teAMDeRNSpyiKpuXwTYajpogHw3a/CkRaZSuqg35hBpCs0b87tAEQ3lmu1USMgMoMZvo07b1vO+j+OofQUxftlzrHPhF1HqNw+lbZMxcrMXVXcMKkd8CokpbaD5MDOQOiuTNdRWKC4kfAYvuR4kobcspzqGVepaRZMhmGxMikxOQkPgoeAxrzrwXTij74gbvULdJJnT9kjisXxlOanAk06mN85K4R3eIlE3efwD+AG3Qc+/6ekVWHVGQdnFGTWSyakErRC9AB+FqAGvt0w== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(82310400014)(36860700004)(1800799015)(376005);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Mar 2024 08:18:14.3418 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: eacab02f-2ff5-4e8e-41ce-08dc3f484d29 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CY4PEPF0000E9D8.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB6979 Hi Henry, On 08/03/2024 02:54, Henry Wang wrote: > Currently on Arm there are 4 functions to allocate memory as domain > RAM at boot time for different types of domains: > (1) allocate_memory(): To allocate memory for Dom0less DomUs that > do not use static memory. > (2) allocate_static_memory(): To allocate memory for Dom0less DomUs > that use static memory. > (3) allocate_memory_11(): To allocate memory for Dom0. > (4) assign_static_memory_11(): To allocate memory for Dom0less DomUs > that use static memory and directmapped. > > To keep consistency between the names and the in-code comment on top > of the functions, rename assign_static_memory_11() to > allocate_static_memory_11(). No functional change intended. There was a reason for this naming. The function is called assign_ and not allocate_ because there is no allocation done inside. The function maps specified host regions to guest regions. Refer: https://lore.kernel.org/xen-devel/20220214031956.3726764-6-penny.zheng@arm.com/ ~Michal From xen-devel-bounces@lists.xenproject.org Fri Mar 08 08:22:43 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2024 08:22:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690143.1075894 (Exim 4.92) (envelope-from ) id 1riVV3-0003pV-H9; Fri, 08 Mar 2024 08:22:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690143.1075894; Fri, 08 Mar 2024 08:22:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riVV3-0003pO-Ec; Fri, 08 Mar 2024 08:22:41 +0000 Received: by outflank-mailman (input) for mailman id 690143; Fri, 08 Mar 2024 08:22:40 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riVV2-0003pI-En for xen-devel@lists.xenproject.org; Fri, 08 Mar 2024 08:22:40 +0000 Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [2a00:1450:4864:20::632]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 0638e288-dd25-11ee-a1ee-f123f15fe8a2; Fri, 08 Mar 2024 09:22:38 +0100 (CET) Received: by mail-ej1-x632.google.com with SMTP id a640c23a62f3a-a36126ee41eso252072566b.2 for ; Fri, 08 Mar 2024 00:22:38 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id wr8-20020a170907700800b00a4553c6d52csm5201299ejb.35.2024.03.08.00.22.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 08 Mar 2024 00:22:37 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 0638e288-dd25-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709886158; x=1710490958; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=7IpdHhhuLFHbI0ErOEGqPbgvR+15c+WF3hb1fCx+t+c=; b=f32KlLiRN09wyBmXdySWCtlWYruc9TZxwkH09tIBMBnxJp4WoLTZLwKktqC+Q/+sdI Suu6KkvMXWDY539Qf+1lKdTrVTOSztzSwK6b2QFXJFvbHsLpI8Yc65JKU+yt3oG9TRvU FwUIrBTw0KTcRhEFUnvHMNV4gGuiG1PAXRIjrV9TC1Qm/Z+XRqIvNwYjnxZY97+cvpeR Xz1TRRFzSGZdERVdV5rUKJDHXCWPPwD+XRM2SafS4O6hv1DxS7Z1UP79xn724MHyHRre sEcVDm7CyO8WgWnDb1SR9fIlgPrfvnjEb4KhnwPzyPAXnapWbvP/rk3O8dQoXxTxOW5b 42qA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709886158; x=1710490958; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=7IpdHhhuLFHbI0ErOEGqPbgvR+15c+WF3hb1fCx+t+c=; b=qZmWfvOypAeFQEevbHbQmIwxKsyOLRvZRDT/qWanGftnRPT6VXpaqufzd1TZwJWegU N5/S3Wkb8Ddc6uq+/gvQnKEvVHj+qkLjxNR/sfcEFXxKThs8/m+Ww9ZYPsCgTK6eJSt6 Gw34pbDZ1IoWg7bSWCRiGJbsszXE103TxWjcIqGUYu3LYI9xqdp2zxemJvDIBV1l7hGL 9seCCc+aIEd3JbfnvnEIvqoCs1kjaenuH/ngW/fV3C+QNEgHUMnBEu6LyUY6Z3qFEkEd 5spOXxjNK0GUl7nwxFqP3zAlENwuobPkn6LxGb9p6T9zx5i9cUI2ptPfo2l6qLdsKYdR B8xw== X-Forwarded-Encrypted: i=1; AJvYcCVAmhunakTsiAl3SipAcC1M2b/2/dWym3oYOaxIevOp9py7A0WwtHHT8wo2r9RNZhTs4TjzuZIziR/nCQQ0pfndaK+Lj4D0eyWSYz9X2VE= X-Gm-Message-State: AOJu0YxV6CDDZ35y5emuEeTI8etHLzLNIuRqcivjPavDcqqMYL6YE8bB FgXSYN2T7f8aw5aGxPh1Jn9dFTBcZXxoBvQL/L+ln/Ilz3IL0o0J0x/BkYkUdA== X-Google-Smtp-Source: AGHT+IFA5QHAvAdYpC+IX2uv6ux1It03Owp9CCqvEm3JoaHolfElRBGR4N8AqrXbv5UatLBfU6NKUA== X-Received: by 2002:a17:906:99d2:b0:a45:f352:73b0 with SMTP id s18-20020a17090699d200b00a45f35273b0mr398165ejn.65.1709886157920; Fri, 08 Mar 2024 00:22:37 -0800 (PST) Message-ID: Date: Fri, 8 Mar 2024 09:22:36 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] move __read_mostly to xen/cache.h Content-Language: en-US To: Oleksii , Andrew Cooper Cc: George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Bertrand Marquis , Volodymyr Babchuk , Shawn Anastasio , "xen-devel@lists.xenproject.org" References: <893a5ebf-54e2-f2b2-1365-2a6d36ed3a39@suse.com> <64466285-35b8-497c-a12b-60fe0c998ba6@suse.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 07.03.2024 18:08, Oleksii wrote: > On Fri, 2023-12-22 at 12:09 +0100, Jan Beulich wrote: >> On 22.12.2023 10:39, Oleksii wrote: >>> On Tue, 2023-08-08 at 12:32 +0200, Jan Beulich wrote: >>>> On 08.08.2023 12:18, Andrew Cooper wrote: >>>>> On 08/08/2023 10:46 am, Jan Beulich wrote: >>>>>> There's no need for every arch to define its own identical >>>>>> copy. >>>>>> If down >>>>>> the road an arch needs to customize it, we can add #ifndef >>>>>> around >>>>>> the >>>>>> common #define. >>>>>> >>>>>> To be on the safe side build-breakage-wise, change a couple >>>>>> of >>>>>> #include >>>>>> to the xen/ equivalent. >>>>>> >>>>>> Signed-off-by: Jan Beulich >>>>> >>>>> Could we find a better place to put this? >>>>> >>>>> __read_mostly is just a section.  It's relationship to the >>>>> cache is >>>>> only >>>>> microarchitectural, and is not the same kind of information as >>>>> the >>>>> rest >>>>> of cache.h >>>>> >>>>> __ro_after_init is only here because __read_mostly is here, but >>>>> has >>>>> absolutely nothing to do with caches whatsoever. >>>>> >>>>> If we're cleaning them up, they ought to live elsewhere. >>>> >>>> I would be considering init.h (for having most other __section() >>>> uses, >>>> and for also needing __read_mostly), but that's not a great place >>>> to >>>> put these either. In fact I see less connection there than for >>>> cache.h. >>>> So the primary need is a good suggestion (I'm hesitant to suggest >>>> to >>>> introduce section.h just for this). >>> Andrew sent some suggestions here: >>> https://lore.kernel.org/xen-devel/3df1dad8-3476-458f-9022-160e0af57d39@citrix.com/ >>> >>> Will that work for you? >> >> I still need to properly look at the suggested options. > Have you had a chance to review the suggested options? I'm sure you've seen https://lists.xen.org/archives/html/xen-devel/2024-01/msg00145.html To add to that - xen/linkage.h is for assembly code only right now. While I'd be happy to add C stuff there, there's an (imo) obvious issue with code churn then: All C files using __read_mostly would then need to be changed to include xen/linkage.h. And no, I don't view including the file once in a "central" other header file as a viable solution: That's where some of our really bad header dependency issues come from. Plus a goal ought to be (imo) that touching a header like this one would better not result in a full re-build of everything, when doing incremental builds. Same obviously goes for the case of introducing xen/sections.h, i.e. the other proposed alternative. Bottom line: Given the state of our tree, I still view my proposed placement as the least bad one for the time being. To change my view, I'd still expect a _viable_ alternative proposal to be made. Jan From xen-devel-bounces@lists.xenproject.org Fri Mar 08 08:23:00 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2024 08:23:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690144.1075905 (Exim 4.92) (envelope-from ) id 1riVVL-0004FG-SD; Fri, 08 Mar 2024 08:22:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690144.1075905; Fri, 08 Mar 2024 08:22:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riVVL-0004F9-P0; Fri, 08 Mar 2024 08:22:59 +0000 Received: by outflank-mailman (input) for mailman id 690144; Fri, 08 Mar 2024 08:22:58 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riVVK-0004Bl-HE for xen-devel@lists.xenproject.org; Fri, 08 Mar 2024 08:22:58 +0000 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on20600.outbound.protection.outlook.com [2a01:111:f403:2415::600]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 10f30a83-dd25-11ee-afda-a90da7624cb6; Fri, 08 Mar 2024 09:22:57 +0100 (CET) Received: from MN2PR01CA0049.prod.exchangelabs.com (2603:10b6:208:23f::18) by BY5PR12MB4178.namprd12.prod.outlook.com (2603:10b6:a03:20e::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.28; Fri, 8 Mar 2024 08:22:54 +0000 Received: from BL6PEPF0001AB55.namprd02.prod.outlook.com (2603:10b6:208:23f:cafe::73) by MN2PR01CA0049.outlook.office365.com (2603:10b6:208:23f::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.27 via Frontend Transport; Fri, 8 Mar 2024 08:22:54 +0000 Received: from SATLEXMB03.amd.com (165.204.84.17) by BL6PEPF0001AB55.mail.protection.outlook.com (10.167.241.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7362.11 via Frontend Transport; Fri, 8 Mar 2024 08:22:53 +0000 Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Fri, 8 Mar 2024 02:22:51 -0600 Received: from [10.65.148.173] (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend Transport; Fri, 8 Mar 2024 02:22:50 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 10f30a83-dd25-11ee-afda-a90da7624cb6 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aK5JKkWX6i6hZH2Qrq/h3ifb8OsNqCBc38YMXSassGTXzqmPHq/IOoTcQI6bdt1ZPLdIPLNc2oaW8fJYMaakfwHVmd72dE+OdGBmvcAmLm0vqN5qgJHPPEOl0XqudeX76mnufKj1vUTwV+z3GBzOAVx/UbdYxZz+PqXsbuTtiB2MC1XPloKlEK6OSnpz2//KT4J5JhfMnYo3/s9mmUS3v60glV3E+EZPKyQaMAxkLJZoLkX3Tc6x2JCu4WObcCWs8AS689fOCu5DCFbmmD8NIFl/BUzJG5+KI3naYkZqGUOr+hvhPzKXi0k9e+zKuHkrWD3yUrTdD7odBresLCGTUQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Qu6lGHsbzTEZviLMY0r5d8+iU6TwWvIkPVdFXGaqUvI=; b=RzzusNbRhvOV189vopjF0pro/U2Mvs0Ddj/SHqkRIFr2WMqAwQP8lc6LoZofXijm1kjpUl4kZ9v5j865ozoyz8VzD4YDqKaH6nPSZsd7NbdYPDXuOrzGhQdr66vKpBPlkEdisjwqx78LvlU/fjTZr23ipztfhuW/Iqvo+BY3g7GXxTMbpc6UalZ+EYs+3desuYonoKj77UbDyR6UXfGELYZG2mLum7NNyiOvFhQ+EBlamV0ZHW+3vBfuBW8Fpqfj2Bx1EI2/IeExwqhyNuMoWxYtDT8RRYMCwQSyTZmHpqN5t4yT+13tZ+biINDyXYbZVyKX1kKIxyvlx9HjgReYpQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Qu6lGHsbzTEZviLMY0r5d8+iU6TwWvIkPVdFXGaqUvI=; b=CLTu8jdQNxs0Rv0B8XKvuWJFF7AP3EQJQyUr4IGQNjYenFGK7Ztlmczi2LFmjwIOyEHlFgjucVoB+VKiQFFBUqEUM3fndZpZthqRwxXDdYuYjdoIuuXqFbSM2IAIUzdG+z/Gh9eYBhVCdVElospGaGOMMaT7wnJmSwJeMcUc7BE= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C Message-ID: <2e6dc9e4-5283-4c4d-8d40-b00861ea8020@amd.com> Date: Fri, 8 Mar 2024 16:22:49 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/5] xen/arm: Rename assign_static_memory_11() for consistency To: Michal Orzel , CC: Stefano Stabellini , Julien Grall , Bertrand Marquis , "Volodymyr Babchuk" References: <20240308015435.4044339-1-xin.wang2@amd.com> <20240308015435.4044339-2-xin.wang2@amd.com> <50342ff8-ddc7-44a9-9166-9755edf44782@amd.com> Content-Language: en-US From: Henry Wang In-Reply-To: <50342ff8-ddc7-44a9-9166-9755edf44782@amd.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: None (SATLEXMB03.amd.com: xin.wang2@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BL6PEPF0001AB55:EE_|BY5PR12MB4178:EE_ X-MS-Office365-Filtering-Correlation-Id: acb5ad15-0323-4663-a6ac-08dc3f48f38f X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: SkoxyEEmcqEJHfBOrctScs7KperppsL7D9ep7/aZZnuqQXnQCgUIieLYEp1l/9xm+iMnSQB29Drk53HCkohr58MiIrns4FpVvEdixIuZ/+CQ7Ewm7269tO1sfFNUqAXwaemCeOED88uN8iZ3jycKBDLTb0UadJTcFWaqQC6snK7B4prOiCsUD1K1l2lPcTVh+9XnwfRjVijE6COiS46RZ3AMw/6/FgVBP8ntkhU15Oz/rB05xtBKMMvsuBBA/8lwb+C8xPiKyn/se80ff4p11oiHFYeQkZiJD35l2IRi+OQQHbWCxa2r8U4kWdUTxkR9/iV67ju9AKkSINyI+x6RkVzGb8TmpXWZBc0EMptmdJv2XFD0Xph6bEsJfGRn1aRrP7RtYanEGmkSO6FOFtZDpb4ED62B19kjkten+n7T+nsMz14cru/FmL76JoN0OQ6uXKL7mOWDVq/sJ9YqvrXZU/vogKIjRtc3rD2s9sVrjOd35YlS+oV+IuexV3DlA8o3F0HncE4HiVtpUX1Oy1irgManFzCo8NKMY41f57HXy+CT6DWENz2a85zY/dXKLZcEjaK45hNwKWaUnaJTn1nwhKCSzCcalEqvIRwbbeirg+wsimP4x3UghCxUdrq1RBW918W1+5R52Iy1zEnUTZD7avqff/5HMXh7JQcojcC3S7sysbv9CPnNgPaoF9fvcp5/2rpb8k0Z1tvFQP2IoWzLQw== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(82310400014)(376005)(36860700004)(1800799015);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Mar 2024 08:22:53.5772 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: acb5ad15-0323-4663-a6ac-08dc3f48f38f X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BL6PEPF0001AB55.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR12MB4178 Hi Michal, On 3/8/2024 4:18 PM, Michal Orzel wrote: > Hi Henry, > > On 08/03/2024 02:54, Henry Wang wrote: >> Currently on Arm there are 4 functions to allocate memory as domain >> RAM at boot time for different types of domains: >> (1) allocate_memory(): To allocate memory for Dom0less DomUs that >> do not use static memory. >> (2) allocate_static_memory(): To allocate memory for Dom0less DomUs >> that use static memory. >> (3) allocate_memory_11(): To allocate memory for Dom0. >> (4) assign_static_memory_11(): To allocate memory for Dom0less DomUs >> that use static memory and directmapped. >> >> To keep consistency between the names and the in-code comment on top >> of the functions, rename assign_static_memory_11() to >> allocate_static_memory_11(). No functional change intended. > There was a reason for this naming. The function is called assign_ and not allocate_ because > there is no allocation done inside. The function maps specified host regions to guest regions. > Refer: > https://lore.kernel.org/xen-devel/20220214031956.3726764-6-penny.zheng@arm.com/ Emmm I indeed had the same idea and thought there should be a reason about the naming, but at the same time still misguided by the in-code comment on top of the function saying "Allocate static memory as RAM for one specific domain d." :/ I guess I will either simply drop this patch or correct the above in-code comment (which I am not sure if it is worthwhile for an independent patch). Anyway, thanks for the info! Kind regards, Henry > ~Michal From xen-devel-bounces@lists.xenproject.org Fri Mar 08 08:34:22 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2024 08:34:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690154.1075915 (Exim 4.92) (envelope-from ) id 1riVgH-0006js-S8; Fri, 08 Mar 2024 08:34:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690154.1075915; Fri, 08 Mar 2024 08:34:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riVgH-0006jl-Oh; Fri, 08 Mar 2024 08:34:17 +0000 Received: by outflank-mailman (input) for mailman id 690154; Fri, 08 Mar 2024 08:34:16 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riVgG-0006jf-5h for xen-devel@lists.xenproject.org; Fri, 08 Mar 2024 08:34:16 +0000 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2061d.outbound.protection.outlook.com [2a01:111:f400:7e88::61d]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id a4d46ed7-dd26-11ee-afda-a90da7624cb6; Fri, 08 Mar 2024 09:34:15 +0100 (CET) Received: from SJ0PR03CA0073.namprd03.prod.outlook.com (2603:10b6:a03:331::18) by MN6PR12MB8589.namprd12.prod.outlook.com (2603:10b6:208:47d::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.24; Fri, 8 Mar 2024 08:34:09 +0000 Received: from SJ5PEPF000001D7.namprd05.prod.outlook.com (2603:10b6:a03:331:cafe::7d) by SJ0PR03CA0073.outlook.office365.com (2603:10b6:a03:331::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.28 via Frontend Transport; Fri, 8 Mar 2024 08:34:09 +0000 Received: from SATLEXMB03.amd.com (165.204.84.17) by SJ5PEPF000001D7.mail.protection.outlook.com (10.167.242.59) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7362.11 via Frontend Transport; Fri, 8 Mar 2024 08:34:08 +0000 Received: from SATLEXMB06.amd.com (10.181.40.147) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Fri, 8 Mar 2024 02:34:08 -0600 Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB06.amd.com (10.181.40.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Fri, 8 Mar 2024 02:34:08 -0600 Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend Transport; Fri, 8 Mar 2024 02:34:06 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a4d46ed7-dd26-11ee-afda-a90da7624cb6 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Uuss416UppmybuDGVMWsM9cCNsVXNnShImPsLUELW79Bl2sCiI45D9EKio35Y3pauc7L8f6i4ANrxBaNiQ5qH0yRZQeunf27d4DQfNbZ2TPVQjjUXfnfFuHP7ON7q2keBpKwHXx4QHlQHYLdQiFCzhJVD6omdzqXgRuO02xXGuk2uSk/JHi39Sx3dseV57WjGH/Hn0BluV67f2iQOVJ1AnOtDm+58i+6P4HsAvXsxkVrjxYRUvlTfZwQYbvzpbLuksGh0QlXlMlG2dYvsI1VMz8gOe6Ws/Imf/mzerTskm9EoJAzacneKpkThE4NFMeITKQdlMJSJe+4lmeGxLq19g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=5hmyfLLKk0cdTvnFCYAQ7vqWbo640poNRGcfmE9g+r4=; b=Zr0BaCyYC31kKTk5kumbmaY2alCMxq/ICiKwhrRC4WNeggAimGVPDuHdg3Q0U578XKtVxeGKXWa+IUWCblhH/gMsmAfozOjoeWQYkHK0yH7KbscDiUsKoShUWP8vcpImNCdQn2mZea3MvfRmW2xVedEkjm0k8j6+w6Qx3I3dp+3twtybqWnkTLpgXl9v0xmKBWIb2uhH7cmopLcRdgxfQyfztVZUidTcF8BNOMK3ICprZwCS27Q8o93KlBbakuRuC6UBF1BLY9ZL3YEU9gUcU8bk0OlqFarF3ATXujOAd6VarEKcPdgFGAOSGm1dOT+OCMaZVXinA9jD3S/i0JLrdA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=xen.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5hmyfLLKk0cdTvnFCYAQ7vqWbo640poNRGcfmE9g+r4=; b=EOKEN57Y4sIrR4n2FsmOB0VLHIjnV6ldWVGQvPSajYl+5HveHOAryv6vaqt5ETVZFPByvFgj7aT3FUWaiU+SefQ53EgxCxWNOq+sfKQ2RJ5oS92FhGeTs/Xhg0U6qKv+Yy4cwyrMsBTusLXjHWEHPAuvxH5Mk/yeVoVq0WthcJk= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C Message-ID: Date: Fri, 8 Mar 2024 09:34:06 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/arm: Set correct per-cpu cpu_core_mask To: Henry Wang , Julien Grall , "Bertrand Marquis" , Stefano Stabellini , "xen-devel@lists.xenproject.org" CC: Volodymyr Babchuk References: <20240226030146.179465-1-xin.wang2@amd.com> <800eaf87-053a-424d-ad0e-2b725a37de89@amd.com> Content-Language: en-US From: Michal Orzel In-Reply-To: <800eaf87-053a-424d-ad0e-2b725a37de89@amd.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ5PEPF000001D7:EE_|MN6PR12MB8589:EE_ X-MS-Office365-Filtering-Correlation-Id: 94ad79f6-97c3-4cf5-6e0d-08dc3f4a8622 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: QwFP2S/oYRNWcSinT0CVUyHkYmxApPKc35DOEGalq00sPAGKviwOYNjbJOsGI4yTJsO9D5k16+q0eZQ1YozT3iO86IyDt/hBcsEwOSiN51dpZkCv4oYWuM/1tZ+JqLiJPDwZ+82rGhDpFh/WMVpjTzOb4kXWg9d371tZQKQLIV5UF3SKZepfYUA/g3oGRR8oS+c78lpfsQJIiRh4bDYxiEJaxCtRzv1G4zmEm2uYMW7ODQpHr7p63X0ZDvWV0bsL5o2Ac9Lo07WhZkDx8v0fgmtlgL3y+/lrikVRylsOlBvfsLsv3B5SVw5O/NF2AGsYzda8nvUdBaCbhLCPjITiNffdcyv/RqKwH+oy3hn0Qs9gqk/oaidPahTQG7mLaz1u7QJUpkkAXcrbOuQ4QoHYep0kFOd+Ne4RA6mBxX2JCVkRicNh91c2hoaxOebB3q5D40uQXfscz9L/EJ1ZZBfXGga4L83ziBJwyBPo+6DZtTjp9ul4eG1qxHfJTKoXPITQsitTzMgrE4z9QX7ZDIXR9wSSKQflWCSG6zAoku3eGS9kklY9RVoa65UWrtoVeQwtS1hMlKMt6z+zWeT82FBOu0aKs7edo4WrxguSa+2TIEqIfQ705KB7uIZazbCQ6dtgvZ036VYjOkoNfU1rSK9Q/1QmiA1mL3ivcdGjdV/TSYjSH9QhRG4pc3AuDs3hgEVpWx5FRrbolZLvgLftb60cktWb4aKwRDkJXWwzW8CnIe/6B4Wy9mYPSiyhyuPOFaNR X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(376005)(1800799015)(82310400014)(36860700004);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Mar 2024 08:34:08.8894 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 94ad79f6-97c3-4cf5-6e0d-08dc3f4a8622 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SJ5PEPF000001D7.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN6PR12MB8589 Hi Henry, On 08/03/2024 03:05, Henry Wang wrote: > Hi everyone, > > On 2/26/2024 6:43 PM, Michal Orzel wrote: >>>>> xen/arch/arm/smpboot.c | 6 +++++- >>>>> 1 file changed, 5 insertions(+), 1 deletion(-) >>>>> >>>>> + /* PE not implemented using a multithreading type approach. */ >>>>> + if ( system_cpuinfo.mpidr.mt == 0 ) >>>> Do we need this check? It mt was true, cpu_sibling_mask would be incorrect >>>> anyway (it would still be 1). >>> I added this check for playing safe, because I only want to do the correct thing >>> in this patch and avoid make things worse for MT case. With this patch, non-MT >>> case can be improved and the MT case is remain unchanged. >>> >>> But I agree with you, and I would be more than happy if I can run a MT setup and >>> finish the "else" part with this patch or follow-ups. Do you know maybe qemu can >>> allow me to emulate a MT setup so that I can fix it properly in v2? Thanks! >> A65 is the only Arm CPU with SMT and I'm not aware of Qemu being able to emulate it. >> AFAICT, in Xen on Arm we assume no SMT, hence my question about your check. With or without it, >> some parts would still be incorrect (like cpu_sibling_mask), so what's the point in having a partial check. >> I would keep your solution without the check. Others may have a different opinion though. > > Since there isn't much discussion followed-up in this thread, I am > wondering do we have more inputs/opinions on this topic? If everyone > agrees, I've followed Michal's suggestion in v2 [1]. I clearly forgot to say in v2 that I'm ok with this change, so: Reviewed-by: Michal Orzel ~Michal From xen-devel-bounces@lists.xenproject.org Fri Mar 08 08:42:18 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2024 08:42:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690157.1075925 (Exim 4.92) (envelope-from ) id 1riVnx-0000Vb-LL; Fri, 08 Mar 2024 08:42:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690157.1075925; Fri, 08 Mar 2024 08:42:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riVnx-0000VU-HE; Fri, 08 Mar 2024 08:42:13 +0000 Received: by outflank-mailman (input) for mailman id 690157; Fri, 08 Mar 2024 08:42:11 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riVnv-0000VO-Cm for xen-devel@lists.xenproject.org; Fri, 08 Mar 2024 08:42:11 +0000 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id c01f010f-dd27-11ee-afda-a90da7624cb6; Fri, 08 Mar 2024 09:42:09 +0100 (CET) Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 447B337C29; Fri, 8 Mar 2024 06:34:29 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id E8389133DC; Fri, 8 Mar 2024 06:34:28 +0000 (UTC) Received: from dovecot-director2.suse.de ([10.150.64.162]) by imap1.dmz-prg2.suse.org with ESMTPSA id uoIxN3Sx6mWeNQAAD6G6ig (envelope-from ); Fri, 08 Mar 2024 06:34:28 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c01f010f-dd27-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1709879669; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=Lr7gU0MQuMochstTN77IioZPiHfUK7OyRh5d0/ZMFkg=; b=rZwyN3U+XmkyCbG4nZKe5921wimaSmjp1Lm0a9qs0o/zJEsn0ThvICYhzeA0/4mlscK+0s EtH/9cPA6awvqGlQBCSaN+uTdijosstyp/o+3rPlKkwQRXaTwvdwyCojYU5HN42zAnm2oC HiG5x4DzDOGcnv2643AJxN3Su9rKLPg= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1709879669; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=Lr7gU0MQuMochstTN77IioZPiHfUK7OyRh5d0/ZMFkg=; b=rZwyN3U+XmkyCbG4nZKe5921wimaSmjp1Lm0a9qs0o/zJEsn0ThvICYhzeA0/4mlscK+0s EtH/9cPA6awvqGlQBCSaN+uTdijosstyp/o+3rPlKkwQRXaTwvdwyCojYU5HN42zAnm2oC HiG5x4DzDOGcnv2643AJxN3Su9rKLPg= Message-ID: <9c2c4ca6-2815-4b80-bcf2-f6a530da66ea@suse.com> Date: Fri, 8 Mar 2024 07:34:28 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 3/3] x86/PVH: Support relocatable dom0 kernels Content-Language: en-US To: Jason Andryuk , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: xen-devel@lists.xenproject.org, Jan Beulich , Andrew Cooper , Wei Liu , George Dunlap , Julien Grall , Stefano Stabellini References: <20240306185032.103216-1-jason.andryuk@amd.com> <20240306185032.103216-4-jason.andryuk@amd.com> From: Juergen Gross Autocrypt: addr=jgross@suse.com; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw== In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------vRclu37ITDsKe1utYse6bxeb" X-Spam-Level: Authentication-Results: smtp-out1.suse.de; dkim=pass header.d=suse.com header.s=susede1 header.b=rZwyN3U+ X-Spamd-Result: default: False [-5.20 / 50.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[suse.com:s=susede1]; XM_UA_NO_VERSION(0.01)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; BAYES_HAM(-3.00)[100.00%]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; HAS_ATTACHMENT(0.00)[]; URIBL_BLOCKED(0.00)[suse.com:dkim]; RCVD_COUNT_THREE(0.00)[3]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; DKIM_TRACE(0.00)[suse.com:+]; MIME_BASE64_TEXT(0.10)[]; RCPT_COUNT_SEVEN(0.00)[9]; MX_GOOD(-0.01)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:dkim]; SIGNED_PGP(-2.00)[]; FUZZY_BLOCKED(0.00)[rspamd.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_UNKNOWN(0.10)[application/pgp-keys] X-Spam-Score: -5.20 X-Rspamd-Queue-Id: 447B337C29 X-Spam-Flag: NO X-Rspamd-Server: rspamd1.dmz-prg2.suse.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------vRclu37ITDsKe1utYse6bxeb Content-Type: multipart/mixed; boundary="------------GF0TWJhzhearXNZmSsrkc62f"; protected-headers="v1" From: Juergen Gross To: Jason Andryuk , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: xen-devel@lists.xenproject.org, Jan Beulich , Andrew Cooper , Wei Liu , George Dunlap , Julien Grall , Stefano Stabellini Message-ID: <9c2c4ca6-2815-4b80-bcf2-f6a530da66ea@suse.com> Subject: Re: [PATCH 3/3] x86/PVH: Support relocatable dom0 kernels References: <20240306185032.103216-1-jason.andryuk@amd.com> <20240306185032.103216-4-jason.andryuk@amd.com> In-Reply-To: Autocrypt-Gossip: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs= --------------GF0TWJhzhearXNZmSsrkc62f Content-Type: multipart/mixed; boundary="------------ORq6uGNhgEWIkqKSw0dsgC2E" --------------ORq6uGNhgEWIkqKSw0dsgC2E Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMDcuMDMuMjQgMTg6MDEsIEphc29uIEFuZHJ5dWsgd3JvdGU6DQo+IE9uIDIwMjQtMDMt MDcgMDQ6MzAsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6DQo+PiBPbiBXZWQsIE1hciAwNiwg MjAyNCBhdCAwMTo1MDozMlBNIC0wNTAwLCBKYXNvbiBBbmRyeXVrIHdyb3RlOg0KPj4+IFhl biB0cmllcyB0byBsb2FkIGEgUFZIIGRvbTAga2VybmVsIGF0IHRoZSBmaXhlZCBndWVzdCBw aHlzaWNhbCBhZGRyZXNzDQo+Pj4gZnJvbSB0aGUgZWxmIGhlYWRlcnMuwqAgRm9yIExpbnV4 LCB0aGlzIGRlZmF1bHRzIHRvIDB4MTAwMDAwMCAoMTZNQiksIGJ1dA0KPj4+IGl0IGNhbiBi ZSBjb25maWd1cmVkLg0KPj4+DQo+Pj4gVW5mb3J0dW5hdGVseSB0aGVyZSBleGlzdCBmaXJt d2FyZXMgdGhhdCBoYXZlIHJlc2VydmVkIHJlZ2lvbnMgYXQgdGhpcw0KPj4+IGFkZHJlc3Ms IHNvIFhlbiBmYWlscyB0byBsb2FkIHRoZSBkb20wIGtlcm5lbCBzaW5jZSBpdCdzIG5vdCBS QU0uDQo+Pj4NCj4+PiBUaGUgUFZIIGVudHJ5IGNvZGUgaXMgbm90IHJlbG9jYXRhYmxlIC0g aXQgbG9hZHMgZnJvbSBhYnNvbHV0ZQ0KPj4+IGFkZHJlc3Nlcywgd2hpY2ggZmFpbCB3aGVu IHRoZSBrZXJuZWwgaXMgbG9hZGVkIGF0IGEgZGlmZmVyZW50IGFkZHJlc3MuDQo+Pj4gV2l0 aCBhIHN1aXRhYmx5IG1vZGlmaWVkIGtlcm5lbCwgYSByZWxvY3RhYmxlIGVudHJ5IHBvaW50 IGlzIHBvc3NpYmxlLg0KPj4+DQo+Pj4gQWRkIHRoZSBYRU5GRUFUX3B2aF9yZWxvY2F0YWJs ZSBmbGFnIHRvIGxldCBhIGtlcm5lbCBpbmRpY2F0ZSB0aGF0IGl0DQo+Pj4gc3VwcG9ydHMg YSByZWxvY2F0YWJsZSBlbnRyeSBwYXRoLg0KPj4+DQo+Pj4gQ2hhbmdlIHRoZSBsb2FkaW5n IHRvIGNoZWNrIGZvciBhbiBhY2NlcHRhYmxlIGxvYWQgYWRkcmVzcy7CoCBJZiB0aGUNCj4+ PiBrZXJuZWwgaXMgcmVsb2NhdGFibGUsIHN1cHBvcnQgZmluZGluZyBhbiBhbHRlcm5hdGUg bG9hZCBhZGRyZXNzLg0KPj4+DQo+Pj4gTGludXggY2FyZXMgYWJvdXQgaXRzIHBoeXNpY2Fs IGFsaWdubWVudC7CoCBUaGlzIGNhbiBiZSBwdWxsZWQgb3V0IG9mIHRoZQ0KPj4+IGJ6SW1h Z2UgaGVhZGVyLCBidXQgbm90IGZyb20gdGhlIHZtbGludXggRUxGIGZpbGUuwqAgSWYgYW4g YWxpZ25tZW50DQo+Pj4gY2FuJ3QgYmUgZm91bmQsIHVzZSAyTUIuDQo+Pg0KPj4gV2hpbGUg SSdtIGZpbmUgd2l0aCBoYXZpbmcgYSBMaW51eCBzcGVjaWZpYyB3YXksIHRoZXJlIG5lZWRz IHRvIGJlIGENCj4+IGdlbmVyaWMgd2F5IG9mIHBhc3NpbmcgdGhlIGFsaWdubWVudCBmb3Ig bm9uLWJ6SW1hZ2Uga2VybmVscy4NCj4+DQo+PiBFTEYgcHJvZ3JhbSBoZWFkZXJzIGhhdmUg YW4gYWxpZ24gZmllbGQsIHdvdWxkIHRoYXQgYmUgc3VpdGFibGUgdG8NCj4+IHVzZT8NCj4g DQo+IFVuZm9ydHVuYXRlbHksIGl0IGRvZXNuJ3Qgc2VlbSBjb3JyZWN0LsKgIExpbnV4IGhh cyBDT05GSUdfUEhZU0lDQUxfQUxJR04sIGFuZCBpdCANCj4gZG9lc24ndCBzZWVtIHRvIGJl IHVzZWQgaW4gdGhlIGVsZiBoZWFkZXJzLsKgIEFzIGEgcXVpY2sgdGVzdCwgSSBzZXQgDQo+ IENPTkZJR19QSFlTSUNBTF9BTElHTj0weDgwMDAwMCwgYnV0IHRoZSBlbGYgYWxpZ24gdmFs dWVzIGFyZSBzdGlsbCAweDIwMDAwMC4NCg0KQW4gZXhjZXJwdCBmcm9tIHRoZSBrZXJuZWwn cyBhcmNoL3g4Ni9NYWtlZmlsZToNCg0KIw0KIyBUaGUgNjQtYml0IGtlcm5lbCBtdXN0IGJl IGFsaWduZWQgdG8gMk1CLiAgUGFzcyAteiBtYXgtcGFnZS1zaXplPTB4MjAwMDAwIHRvDQoj IHRoZSBsaW5rZXIgdG8gZm9yY2UgMk1CIHBhZ2Ugc2l6ZSByZWdhcmRsZXNzIG9mIHRoZSBk ZWZhdWx0IHBhZ2Ugc2l6ZSB1c2VkDQojIGJ5IHRoZSBsaW5rZXIuDQojDQppZmRlZiBDT05G SUdfWDg2XzY0DQpMREZMQUdTX3ZtbGludXggKz0gLXogbWF4LXBhZ2Utc2l6ZT0weDIwMDAw MA0KZW5kaWYNCg0KDQpKdWVyZ2VuDQo= --------------ORq6uGNhgEWIkqKSw0dsgC2E Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2 kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i 1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u +6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4 RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7 8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK 7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/ Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK /1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1 c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4 k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu 5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6 AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr 0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD 534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422 bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay 7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib 4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX kt+z4drzFUyEjLM1vVvIMjkUoJs=3D =3DeeAB -----END PGP PUBLIC KEY BLOCK----- --------------ORq6uGNhgEWIkqKSw0dsgC2E-- --------------GF0TWJhzhearXNZmSsrkc62f-- --------------vRclu37ITDsKe1utYse6bxeb Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmXqsXQFAwAAAAAACgkQsN6d1ii/Ey/w Zgf/fOYQ5nRstsKs3VozbODlTj/DDAES7bzxTGY+p+u78GRAAD8wujjD0fcqDku8I8XbXDp0dYVn 4o9a7ippQcuSJzYVscWdvkg+omoNCoVot43VdYEcTS6fImDJO0qig3OBO8oY00kG3U7x7vmIKN4K olT8sVziL00oM+4ywxjPbt/EgmxwNPswl034pUy91z9uGBmmSbiuFa34gVzICBv341lI04JnUpKc 5XmN6iGdvZwmTRrC3HfiOjGNovzZoSyn6o8JdMGjV/ZxuOVhabiHQGreZx5wbgafPSuwlHbNhbGH D0ZJZlR8RUcC/X3Iv8yOiXhneWLSiZbreLkC6/IvjQ== =aASE -----END PGP SIGNATURE----- --------------vRclu37ITDsKe1utYse6bxeb-- From xen-devel-bounces@lists.xenproject.org Fri Mar 08 08:59:24 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2024 08:59:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690162.1075935 (Exim 4.92) (envelope-from ) id 1riW4T-000348-3N; Fri, 08 Mar 2024 08:59:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690162.1075935; Fri, 08 Mar 2024 08:59:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riW4S-000341-VT; Fri, 08 Mar 2024 08:59:16 +0000 Received: by outflank-mailman (input) for mailman id 690162; Fri, 08 Mar 2024 08:59:16 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riW4S-00032N-7d for xen-devel@lists.xenproject.org; Fri, 08 Mar 2024 08:59:16 +0000 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on20600.outbound.protection.outlook.com [2a01:111:f403:2415::600]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 22d5da16-dd2a-11ee-afda-a90da7624cb6; Fri, 08 Mar 2024 09:59:14 +0100 (CET) Received: from MN2PR20CA0029.namprd20.prod.outlook.com (2603:10b6:208:e8::42) by SJ2PR12MB8740.namprd12.prod.outlook.com (2603:10b6:a03:53f::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.26; Fri, 8 Mar 2024 08:59:11 +0000 Received: from BN3PEPF0000B072.namprd04.prod.outlook.com (2603:10b6:208:e8:cafe::b7) by MN2PR20CA0029.outlook.office365.com (2603:10b6:208:e8::42) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.27 via Frontend Transport; Fri, 8 Mar 2024 08:59:11 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by BN3PEPF0000B072.mail.protection.outlook.com (10.167.243.117) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7362.11 via Frontend Transport; Fri, 8 Mar 2024 08:59:10 +0000 Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Fri, 8 Mar 2024 02:59:10 -0600 Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend Transport; Fri, 8 Mar 2024 02:59:07 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 22d5da16-dd2a-11ee-afda-a90da7624cb6 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=G0swNRpX5GHKcgROXa2VVmIEwWWtiHi2oQ6Z8HSbusrqFXhLwV9BjPwJKE0NyetyOsvGDLz01Li7OA5pqScpQOq4wdYG5W7vvfUN81rxku77uqLQhdWe8udkP/tgGZHQfra+XCuLutp6DOKaZPrlWmmmiXch68b+BANiZSIUeetNi86L0NDrMaQ1IIeRwHArw5QHK66uOvxZnJjNtTgDXg7HacW0A4NsrCSbcKhFPgsSGkOx2T2669+mXiMqq08IW4vNZx8PkRsjnMl0rofHMmcEixPyB+UalWYumcvUeFtiZrSzI0e3JITio0PA6yWjv01XaPd5fXaroM1ab0pbMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=K9sNdPLlbtFRpgOPK0KF+208UXe6iwnzIMtL9DNuzFw=; b=DKj+9N+sNc/Z7e6RRXWuOd6ys8Xl0Cf3osPQJQBFgvsU+VYmKUJPmKh2+2kUPsa2EiOSzn3qpqqQvqh3xJEkdc4KtMc2LHeMw7x6Oaw1rDUqNPJEiaNy1tLgvDdOEf5LH4zcXbJUwB93K96/o5sxqr3qfdytY5yKL6m+gLh8YKl/e5J7AxUt73DlngSjdGzqFozIx+3GZ7JGMPwD+64P2AGD+NGAf/w1Mu3XfKZqfdIBJpmhyab4ulmmdDfTY+1tnVnZo8KsfRuq53r53igIBE96yH8LQ7Llmv+ncgVgpBEv44p5Btzr8cqbdqj2wxsD7Gc2AnsQFV+gG+Usf8GpmQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=K9sNdPLlbtFRpgOPK0KF+208UXe6iwnzIMtL9DNuzFw=; b=jSP3YBJpKn8//KzVvYkNG+UoIcjyp8Tu0aFVmoJP0ZesWy+4sjkKnk+0La9MqE6McAbGVJHHaK+Gx9eNGaAdNcHizU9JeRbHPaybQf5h9mV24uFtN0/srsBudJ3eYHEx+4oDSAUUQiH49kXO32UGiwWXbDTzkUJ7YSUkTPKzoks= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C Message-ID: <9b55829a-3248-4bd4-b36b-a709debf46f3@amd.com> Date: Fri, 8 Mar 2024 09:59:07 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/5] xen/domain.h: Centrialize is_domain_direct_mapped() Content-Language: en-US To: Henry Wang , CC: Stefano Stabellini , Julien Grall , Bertrand Marquis , "Volodymyr Babchuk" , Andrew Cooper , George Dunlap , "Jan Beulich" , Wei Liu , Shawn Anastasio , Alistair Francis , Bob Eshleman , "Connor Davis" , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <20240308015435.4044339-1-xin.wang2@amd.com> <20240308015435.4044339-3-xin.wang2@amd.com> From: Michal Orzel In-Reply-To: <20240308015435.4044339-3-xin.wang2@amd.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Received-SPF: None (SATLEXMB04.amd.com: michal.orzel@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN3PEPF0000B072:EE_|SJ2PR12MB8740:EE_ X-MS-Office365-Filtering-Correlation-Id: 63ad3974-c55b-43b4-d435-08dc3f4e055a X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: mxXnTICps9zkc3S11/KB+NFdvzEuFlWDa1sVQa0Wu9n/u917EZ8/p4yqgjV/wab8urtPQfKF1ETbImUyJTYEKw5yEUNqQ5BjYbcHbQLwXkOvT7wv2Yy6sN/EbwOJnmLEX9ICbgKs0yr3TDEH7InuT5Gq7MIkKX4cTNrwNeYG5d8YhPZ8CQ/BnT5yS1FJLPhT8Cs5DIN785Nu1r/k+f/Cn96zxNZPlIJ3T4rhM+GckR8MJeIJwzLAT5Iu4140bd94gDwQC1ap0VK63/an7RONcW/yr8gmUo5Qegl6FAVI3LxHjTh38r+txe+oq+FU0ujGkG5mCFSpCTqsqbp6iO3lEd8UnUAAUL6DIiIIDBS2r4pdxCLoOugHcewQ/z1qWpb49dBZgySKqnG4ll0jqqmKh/Ji/Q0hplvDqLmV74u0zCn3a0WAJbkXgE7ubn9+q1YqQWMuIj5ceYdkPiHQ1PlF2W6UEm0zg0oubvgooys+5UTSX9KTTp79cn67jHSaBlBpMeC/EexFoJEJ0YRM100psEaoJ7a54ujnrXcHdDwQ6epDP4fW93Zps/I9m2FASuOBh8G2Au0YIB4+JSnOPxoWVFINDtoTydPBGTl8nm0sWx0lNYhUsbadUQCBKHnzD2PVghVNku0Udd9/HtClrEkVj5qwa2UpVgrqHqTMxlt+HBFZzaU8A0vPpZMOpfAzhpbn3AERSUjyIZDgPE3srdu26kaogyNnZ8G0IuY0r69DIB94Bh6RQo3OGcqmzPJMTpv4 X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(82310400014)(376005)(1800799015)(7416005)(36860700004);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Mar 2024 08:59:10.9136 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 63ad3974-c55b-43b4-d435-08dc3f4e055a X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BN3PEPF0000B072.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB8740 Hi Henry, On 08/03/2024 02:54, Henry Wang wrote: > Currently direct mapped domain is only supported by the Arm > architecture at the domain creation time by setting the CDF_directmap > flag. There is not a need for every non-Arm architecture, i.e. x86, > RISC-V and PPC, to define a stub is_domain_direct_mapped() in arch > header. > > Move is_domain_direct_mapped() to a centralized place at xen/domain.h > and evaluate CDF_directmap for non-Arm architecture to 0. > > Signed-off-by: Henry Wang Shouldn't you add Suggested-by: Jan? Reviewed-by: Michal Orzel Another alternative would be to let the arch header define it if needed and use a centralized stub in xen/domain.h: #ifndef is_domain_direct_mapped #define is_domain_direct_mapped(d) ((void)(d), 0) #endif I'm not sure which solution is better. ~Michal From xen-devel-bounces@lists.xenproject.org Fri Mar 08 09:06:24 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2024 09:06:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690164.1075944 (Exim 4.92) (envelope-from ) id 1riWBI-0005C4-OA; Fri, 08 Mar 2024 09:06:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690164.1075944; Fri, 08 Mar 2024 09:06:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riWBI-0005Bx-Lc; Fri, 08 Mar 2024 09:06:20 +0000 Received: by outflank-mailman (input) for mailman id 690164; Fri, 08 Mar 2024 09:06:19 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riWBH-0005Br-Mq for xen-devel@lists.xenproject.org; Fri, 08 Mar 2024 09:06:19 +0000 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on20600.outbound.protection.outlook.com [2a01:111:f403:2418::600]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 1fe36de4-dd2b-11ee-afda-a90da7624cb6; Fri, 08 Mar 2024 10:06:18 +0100 (CET) Received: from DM5PR07CA0093.namprd07.prod.outlook.com (2603:10b6:4:ae::22) by SJ2PR12MB7823.namprd12.prod.outlook.com (2603:10b6:a03:4c9::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.24; Fri, 8 Mar 2024 09:06:15 +0000 Received: from CY4PEPF0000FCC3.namprd03.prod.outlook.com (2603:10b6:4:ae:cafe::6d) by DM5PR07CA0093.outlook.office365.com (2603:10b6:4:ae::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.29 via Frontend Transport; Fri, 8 Mar 2024 09:06:14 +0000 Received: from SATLEXMB03.amd.com (165.204.84.17) by CY4PEPF0000FCC3.mail.protection.outlook.com (10.167.242.105) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7362.11 via Frontend Transport; Fri, 8 Mar 2024 09:06:13 +0000 Received: from SATLEXMB08.amd.com (10.181.40.132) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Fri, 8 Mar 2024 03:06:13 -0600 Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB08.amd.com (10.181.40.132) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Fri, 8 Mar 2024 01:06:12 -0800 Received: from [10.65.148.173] (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend Transport; Fri, 8 Mar 2024 03:06:08 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1fe36de4-dd2b-11ee-afda-a90da7624cb6 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QRbmHyY/UMvfD830aBYngbjFodrxaDZ0Fus5xrxE8lxW+/av+s4hk8VtPJx1fboywYMxqQZkYHA0Pp+TtheirSv/ZLJ/cIXhBY+sMaEZ16JZvk0ThxAtnEMCV6dWg7SiOCjKsVb9+igV2SAM3X8jMsjHAfsa9ocqC13e+G8IwjDirf8FtK9gItD+yj8yLSVp2Up8PMdbmswFZW7AkK//TSQcb7RUVjHa1qwacvEaaOsP4k4AKFXrDvxkA8uQBF9eu4obCu1gvl3/LpDT6n/5y/z5h0/vPU9ydWRIpCWdDd6GG7PfihRI9m6czkgHXxq/lMFrWqqxwEnAAvn+oUPmtA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ZCIa36OT7Ie20s1OkNd4ALvetqu5pbW3dNmXe+yj5Jw=; b=BJWqSoqOMO3hOxB8BJDM+azkMKqa+XXmYKKTNmiegEtLKT4gZogbi6AFivRXTvr9cEbspnQ2C8lwj150w1NhL3TLZLPOSO4MvPOGWRLS525It5dSiiLReCjsp/dYVq6lfV4obfj0d9AF8e0ccdPqBFWNTyv9RDFsAK1Ta1y0DCy3hw4He8hU9XInHgpckRsLwWqbCkaCJnn+eVpez9Jkh5POaZtUIvzZNaU2D+DRccxe9RjdPIC742jY7Z8geQS6CuPIe5j4tlFSMAtf8Dp9QEwtmmhJpm15lCR4r+GQeixsPqVKFF4veBtPuASHlvS2O1MWW6p9+o0lJzve7fUI5g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZCIa36OT7Ie20s1OkNd4ALvetqu5pbW3dNmXe+yj5Jw=; b=yMi7STFY7RlzUhPw8RYGL2CGjCfz0c6HU3pbxU4wu8KJi+Z/ORfz3WC22FAArGCUHj9vVexEeiKVOWzC0Df1AXWEZWbjd/4r0Wnkoh9opXN21A7R4IDikbpFmbBaWShAwZfaHxLhLK0eKJ8ffoz7mzgopW0SYiBbKb5XrXP8Tzc= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C Message-ID: <4cd6aec3-aa5e-47fd-9d33-c03848e3f563@amd.com> Date: Fri, 8 Mar 2024 17:06:08 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/5] xen/domain.h: Centrialize is_domain_direct_mapped() To: Michal Orzel , CC: Stefano Stabellini , Julien Grall , Bertrand Marquis , "Volodymyr Babchuk" , Andrew Cooper , George Dunlap , "Jan Beulich" , Wei Liu , Shawn Anastasio , Alistair Francis , Bob Eshleman , "Connor Davis" , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <20240308015435.4044339-1-xin.wang2@amd.com> <20240308015435.4044339-3-xin.wang2@amd.com> <9b55829a-3248-4bd4-b36b-a709debf46f3@amd.com> Content-Language: en-US From: Henry Wang In-Reply-To: <9b55829a-3248-4bd4-b36b-a709debf46f3@amd.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CY4PEPF0000FCC3:EE_|SJ2PR12MB7823:EE_ X-MS-Office365-Filtering-Correlation-Id: 7aa53bbe-2618-4ecc-afc0-08dc3f4f0173 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: t9SnWTCZdKkTV5Y8rdQ1R3N2cNawRUnJsZxCg3RtJXnplUAL43zPgogurPU2MfObugG8SMLBj5r7ZNEncbILGxqv1WfQj2Rk8k8zlai+RkYi64t34f8EYkf7vzmp45VP6kyFHNJlczXj7doVGbXLKy6mgzp6fqzaav5k8I/6zqlclSILTbBn+eik1rW32fLaecI6jzsI2/2krCsAz58Ub+3Wk1OxjAfHVYFNlgH6pdH2mCTC0nZAiVwwpsQeAk1zMd4QwwKysktHRhvB4u3tt7QVoRzHKFK6pm/Qu4mE4BmyXnLHdpHEeKkKDvSaqtWOIuO+qQX1g73DLK5eMQfgOYhvZKYVnehzq2vo3KY9K3kWfJfnav9BwNDjTz6vAX4ulMB3eMX7gSPtsz+/Y0Tqgbw8Ti7sSy0ye0WpfTydxSpvat1D4lj4JijVDV2XO8r6H90MYtJEXCdBmzaI6N7xKeP7cDBPAoPlTwiEGxJskxPOVk4JMziWWFGp++4m15sQN59WUnLo1b3/VDIOmZhy/+cDSWBWlDHGxZekqCWDWF1NeiCxiDDXGBUhfmpZq2tre0FlrzSDLmjiuUpZ7Zx0AnaMcj1tM+tXZgyAfeyakZ/Upkh/Suf7p2rRzHsBI5/n2g57fifibGLBd8IFQmNKR6MYXl6Utkc5qB4EoAz2A+8wfscYCIZhl/Tap9qzxKGkBWpR+UxFbX1YW2oI4T9+kRgfeNraayisp5d5REh1MMxX3xXmo5gLFk0zPEcJpzw9 X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(36860700004)(82310400014)(376005)(1800799015)(7416005);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Mar 2024 09:06:13.7999 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 7aa53bbe-2618-4ecc-afc0-08dc3f4f0173 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CY4PEPF0000FCC3.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB7823 Hi Michal, On 3/8/2024 4:59 PM, Michal Orzel wrote: > Hi Henry, > > On 08/03/2024 02:54, Henry Wang wrote: >> Currently direct mapped domain is only supported by the Arm >> architecture at the domain creation time by setting the CDF_directmap >> flag. There is not a need for every non-Arm architecture, i.e. x86, >> RISC-V and PPC, to define a stub is_domain_direct_mapped() in arch >> header. >> >> Move is_domain_direct_mapped() to a centralized place at xen/domain.h >> and evaluate CDF_directmap for non-Arm architecture to 0. >> >> Signed-off-by: Henry Wang > Shouldn't you add Suggested-by: Jan? Yeah indeed I should have added it. I always have a hard time to determine if I should add "Suggested-by"/"Reported-by" tags, sorry for missing it this time. I will add it in the next version. > Reviewed-by: Michal Orzel Thanks! > Another alternative would be to let the arch header define it if needed and use a centralized stub in xen/domain.h: > > #ifndef is_domain_direct_mapped > #define is_domain_direct_mapped(d) ((void)(d), 0) > #endif > > I'm not sure which solution is better. Thanks for the suggestion. I am fine with either way, so let's see what the others would say and I will do the update of this patch accordingly. Kind regards, Henry > ~Michal From xen-devel-bounces@lists.xenproject.org Fri Mar 08 09:41:29 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2024 09:41:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690174.1075954 (Exim 4.92) (envelope-from ) id 1riWj8-0004Nv-AK; Fri, 08 Mar 2024 09:41:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690174.1075954; Fri, 08 Mar 2024 09:41:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riWj8-0004No-7p; Fri, 08 Mar 2024 09:41:18 +0000 Received: by outflank-mailman (input) for mailman id 690174; Fri, 08 Mar 2024 09:41:17 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riWj7-0004Ni-6v for xen-devel@lists.xenproject.org; Fri, 08 Mar 2024 09:41:17 +0000 Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [2a00:1450:4864:20::62f]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 020db18a-dd30-11ee-afda-a90da7624cb6; Fri, 08 Mar 2024 10:41:15 +0100 (CET) Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-a45aa7cb2b3so78911266b.3 for ; Fri, 08 Mar 2024 01:41:15 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id j15-20020a1709062a0f00b00a45a96a9c37sm3718424eje.65.2024.03.08.01.41.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 08 Mar 2024 01:41:15 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 020db18a-dd30-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709890875; x=1710495675; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=jmSsKLPYAaz9blRG6WOiSihLRNSkYpITEvogtn/i+P8=; b=dErXhkHkunsXn7VkyEvcL0EraKUIA0d1TOhC3GcQQKywVeYJOVWKs9y+bp5qrJ0BW4 YYlUefmqHUvOTKXyoleDm5xOpLedbuT4YNYRORiXyVtouY0GMSo8HS2OwBWsWs0ehEb7 8z9tyYZX9si8SBAo0A23qdXhd3BcUb7oTECnIAWREPiyutiAT0wjJSFh1mWEiyntcPIW NMbnpwwxvePeL0IQQXtCbok1/FTkX1zZCmVIGMqp+MYoaEp6SzcESFNh9Jo1DZklWVKJ P2kLhJFQlQpw5ZGDdIOTAu73biWMpnQN+ur2M7uckU7elW6WbaohRA2TOFmZI3hQEiYz WAJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709890875; x=1710495675; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=jmSsKLPYAaz9blRG6WOiSihLRNSkYpITEvogtn/i+P8=; b=Plqq6Nh+TH65i5u0iqTldJ44U0akBUK1Fv8UzLXevsATG1BRLlfLFOKY6nB1XwnAmf erKWMhDQxq1DZdLDJ9x73uAG6MCY+P+tvClPASadYCUbKSlWrZWTBLOmhOL2vC1cSwUI XzyCY7L2yOJNTuQwYeKktHojCy9w+m+BZMvOEZ2v7JImX4TSCT9nxJtpnnDVr0i14c/R I2x5I+Ux9YEGpK1/lMmaHX/J4vYgBQxFOFH1g9u4czt+NIKVwt0Tf+UhOQEcX8TAK4PN PQYqqm8heuFhPVwbX7p9NuYXy6Dzm7h5ORTT8huUNNxBtrKyBiBmMBu0mUOqmfAl3qxA 2tDQ== X-Forwarded-Encrypted: i=1; AJvYcCUpunq11bWFMce97r64Y+JhXdVDXgxecXUq6UPJiDkcV+PViMD3Ob0ANVx88IGiVh5k6jVLFEhOdHWALN7BeWzAZO/WorxYfemAZl0qyN8= X-Gm-Message-State: AOJu0YxjUhhgPrzUBmI+sEq8pHttv7v3j2EFQQ/n2n7/FWdKXrA9csdQ wuTChQQmLR3Z8OLuo7XvU7ifYOgqNVRKrBzjQmrTzFcqdj4ags4hkaZiBYA96Q== X-Google-Smtp-Source: AGHT+IEsCWOQHYFlDksJcYmzkFuwCR3ZFVoJVR9skT902aE5DgANzzSqil3FjyR2Rxb3CZi1KsTnGw== X-Received: by 2002:a17:906:f148:b0:a43:ef41:e9e2 with SMTP id gw8-20020a170906f14800b00a43ef41e9e2mr14067276ejb.52.1709890875334; Fri, 08 Mar 2024 01:41:15 -0800 (PST) Message-ID: <603a218e-422d-4600-8247-7d8b16109b8f@suse.com> Date: Fri, 8 Mar 2024 10:41:13 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/5] xen/domain.h: Centrialize is_domain_direct_mapped() Content-Language: en-US To: Henry Wang Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk , Andrew Cooper , George Dunlap , Wei Liu , Shawn Anastasio , Alistair Francis , Bob Eshleman , Connor Davis , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org, Michal Orzel References: <20240308015435.4044339-1-xin.wang2@amd.com> <20240308015435.4044339-3-xin.wang2@amd.com> <9b55829a-3248-4bd4-b36b-a709debf46f3@amd.com> <4cd6aec3-aa5e-47fd-9d33-c03848e3f563@amd.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <4cd6aec3-aa5e-47fd-9d33-c03848e3f563@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 08.03.2024 10:06, Henry Wang wrote: > On 3/8/2024 4:59 PM, Michal Orzel wrote: >> Another alternative would be to let the arch header define it if needed and use a centralized stub in xen/domain.h: >> >> #ifndef is_domain_direct_mapped >> #define is_domain_direct_mapped(d) ((void)(d), 0) >> #endif >> >> I'm not sure which solution is better. > > Thanks for the suggestion. I am fine with either way, so let's see what > the others would say and I will do the update of this patch accordingly. While I wouldn't strictly mind the addition of an #ifdef, I'd prefer it to be omitted until such time when an arch would really want to override it. IOW patch as-is Reviewed-by: Jan Beulich Jan From xen-devel-bounces@lists.xenproject.org Fri Mar 08 09:55:42 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2024 09:55:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690177.1075965 (Exim 4.92) (envelope-from ) id 1riWwz-0006hE-Gt; Fri, 08 Mar 2024 09:55:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690177.1075965; Fri, 08 Mar 2024 09:55:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riWwz-0006h7-EG; Fri, 08 Mar 2024 09:55:37 +0000 Received: by outflank-mailman (input) for mailman id 690177; Fri, 08 Mar 2024 09:55:36 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riWwy-0006gi-91 for xen-devel@lists.xenproject.org; Fri, 08 Mar 2024 09:55:36 +0000 Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [2607:f8b0:4864:20::102b]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 01a71165-dd32-11ee-afda-a90da7624cb6; Fri, 08 Mar 2024 10:55:35 +0100 (CET) Received: by mail-pj1-x102b.google.com with SMTP id 98e67ed59e1d1-2997a92e23bso469347a91.3 for ; Fri, 08 Mar 2024 01:55:34 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 01a71165-dd32-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709891733; x=1710496533; darn=lists.xenproject.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=5ifjvHbDAhZQc5abUXoVUI3Kazd4Dp+NXqN6HCkRFBg=; b=MZ48ZQxenxyxxmTvr557aAMj9Yq11XtbuCvew7grsXkwE7egRf6UpVvA7w7o3omTMu od3VWM7zY8HB+3udcWR3ajN3WDkCZ2ZWUy62BPX0D9TYb8lFj5rOXda+FiD1Ifxegmpe XFzCd9kCjh0BkKE8LHS+mZK3hhSVGPF+pvpHx1hu5d3grCwv6q2GAEzM7oPO/IoFc7mi Fz5b6Yoh54VaDNnqQdBsW7rpJNUvEptj4Ba/NLo+R3Lju+FMKaWxBn8mWFBmz59W+sUu hWUp77+113R18kaMgsaw4WRdTddCUQuur8WYM0gJ1FHY3UspJJoZURCyUZe7TrF6jOIP P1FQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709891733; x=1710496533; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=5ifjvHbDAhZQc5abUXoVUI3Kazd4Dp+NXqN6HCkRFBg=; b=DYjsr44mwv95J93E7u/csyAKhtSrxxaevhIvwlKRdFblXGzuKEiti0xhSbY7QDHpz7 F2UpeTYn1SWOycxZCWvLYbl8R1KuJCIBHghN6cGD5ycyIR0d7vW7dhwTkzUGcwMxLyVr M7pM5lTKgDXBrae+kDIPm+ZshYdfl6NN/o4hvJcPe9dkjNxwgyYFVrU8XDdASPnsz+si /TiBAJm3UoK4us+uC8HINHqAW8XGrh/bjy9wF+W2khHUliUr3xw3GhvT7bOMkRUJ35bN lznlnlopqpHWXBGVNF977AzPn9g0J0PKgYRdlabaQRHRVBS6ObCX0/unKEr7fkz0V/AQ 9FtQ== X-Forwarded-Encrypted: i=1; AJvYcCXjBkrQe67TDX/7I7TEd0rTGx8Ei34DjvPXNp6v92J0BJ5g1Xlq05wmUsIl5kd5c6G2MJXIaBS2ZDANchzT009LvOyWEWyaC2t6ri8wevg= X-Gm-Message-State: AOJu0YwuT8tk3FE6hLlvlu4cikpaPCZ+5M2IBap+ypSaJeKnwa/SfQKZ rrdPc+RObn4tJgOKrfWLzb6RVyLL1XsrXYQiqTcklxLRzewtIzZbhH0i+ctyZ3OZdWLJ6gudYPi AReNQRVtpgFA8gdiCvo+GO/4Q+ug= X-Google-Smtp-Source: AGHT+IEQ9I1y9eOV9bma6ShJRxtMu+ulvK7X4CA25n/zSetrCcsS9aLRn6/7Tr/XSX8LCz1yoawVg0Vg367FRyjgjZk= X-Received: by 2002:a17:90a:7782:b0:29b:bbef:9134 with SMTP id v2-20020a17090a778200b0029bbbef9134mr224905pjk.8.1709891733208; Fri, 08 Mar 2024 01:55:33 -0800 (PST) MIME-Version: 1.0 References: <77c1c05d-a0a0-4292-9257-9b7fbebee0e3@suse.com> <2859ad22-8714-4628-8142-fc77fc2072c3@amd.com> <214585d5-689d-4ba6-bd48-359428a7ed8f@amd.com> <962cad57-21a8-4882-a23a-95add04cac9b@suse.com> In-Reply-To: <962cad57-21a8-4882-a23a-95add04cac9b@suse.com> From: =?UTF-8?Q?S=C3=A9bastien_Chaumat?= Date: Fri, 8 Mar 2024 10:55:21 +0100 Message-ID: Subject: Re: [BUG]i2c_hid_acpi broken with 4.17.2 on Framework Laptop 13 AMD To: Jan Beulich Cc: Mario Limonciello , Juergen Gross , =?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= , xen-devel@lists.xenproject.org Content-Type: multipart/alternative; boundary="0000000000005ce88c06132331f4" --0000000000005ce88c06132331f4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Le jeu. 7 mars 2024, 09:39, Jan Beulich a =C3=A9crit : > On 06.03.2024 18:28, S=C3=A9bastien Chaumat wrote: > > Reasoning backward (using a kernel without the pinctrl_amd driver to > >> ensure xen only is at stake) : > >> checking the diff in IOAPIC between bare metal and xen (IRQ7 is on > >> pin07 on APIC ) > >> > >> using kernel argument : apic=3Ddebug > >> > >> bare metal : > >> [ 0.715330] fedora kernel: ... APIC VERSION: 81050010 > >> ... > >> [ 0.715433] fedora kernel: pin07, disabled, edge , high, V(00), > >> IRR(0), S(0), physical, D(0000), M(0) > >> > >> xen : > >> [ 2.249582] fedora kernel: ... APIC VERSION: 00000014 > >> ... > >> [ 2.249730] fedora kernel: pin07, disabled, level, low , V(60), > >> IRR(0), S(0), physical, D(0000), M(0) > >> > >> So the APIC table is not the same. > >> > >> As strange as it looks the (IOAPIC 0) pin07 is correctly described by > the > >> APIC in xen but yet differently than in baremetal. > >> But the APIC message comes long after the > >> [ 1.833145] fedora kernel: xen: registering gsi 7 triggering 0 > polarity > >> 1 > >> > >> so I wonder if the APIC pin07 info had any influence. > >> > >> Finally found the fix : adding ioapic_ack=3Dnew to xen boot parameters= . > > Not only the trackpad is now working but also the ACPI Embedded > Controller > > which is completely disabled. > > Hmm, interesting. From someone else's laptop many years ago I had actuall= y > an indication in the opposite direction: That didn't work because of our > defaulting to new (no directed EOI in sight yet back at that time). I > wonder if overriding the ack method isn't actually just papering over the > underlying actual issue here, whatever that is. IOW with the edge vs leve= l > mismatch addressed I'd hope the override could then be dropped again. > I suppose you refert to : https://xen-devel.narkive.com/1Lbaex65/irq-issues-with-directed-eoi-and-io-= apic-ack-methods - I did override the IRQ configuration all allong my debugs (the handler was correctly set to level, yet not all flags were identical between dom0 and bare metal). In the end, with the ioapic_ack=3Dnew, I could even leave the wrong edge binding for IRQ7. - besides the touchpad, the ACPI EC was also non functional without forcing ioapic_ack. And in bare metal the EC does a lot of work of during early kernel setup. S=C3=A9bastien --0000000000005ce88c06132331f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Le jeu. 7 mars 2024, 09:39, Jan Beulich <jbeulich@suse.com> a =C3=A9crit=C2=A0:
On 06.03.2024 18:28, S=C3=A9bastien C= haumat wrote:
> Reasoning backward=C2=A0 (using a=C2=A0 kernel without the pinctrl_amd= driver to
>> ensure xen only is at stake) :
>>=C2=A0 checking the diff in IOAPIC=C2=A0 between bare metal and xen= =C2=A0 (IRQ7 is on
>> pin07 on APIC )
>>
>> using kernel argument : apic=3Ddebug
>>
>> bare metal :
>> [=C2=A0 =C2=A0 0.715330] fedora kernel: ... APIC VERSION: 81050010=
>> ...
>> [=C2=A0 =C2=A0 0.715433] fedora kernel:=C2=A0 pin07, disabled, edg= e , high, V(00),
>> IRR(0), S(0), physical, D(0000), M(0)
>>
>> xen :
>> [=C2=A0 =C2=A0 2.249582] fedora kernel: ... APIC VERSION: 00000014=
>> ...
>> [=C2=A0 =C2=A0 2.249730] fedora kernel:=C2=A0 pin07, disabled, lev= el, low , V(60),
>> IRR(0), S(0), physical, D(0000), M(0)
>>
>> So the APIC table is not the same.
>>
>> As strange as it looks the=C2=A0 (IOAPIC 0) pin07 is correctly des= cribed by the
>> APIC in xen but yet differently than in baremetal.
>> But the APIC message comes long after the
>> [=C2=A0 =C2=A0 1.833145] fedora kernel: xen: registering gsi 7 tri= ggering 0 polarity
>> 1
>>
>> so I wonder if the APIC pin07 info had any influence.
>>
>> Finally found the fix : adding ioapic_ack=3Dnew to xen boot parame= ters.
> Not only the trackpad is now working but also the ACPI Embedded Contro= ller
> which is completely disabled.

Hmm, interesting. From someone else's laptop many years ago I had actua= lly
an indication in the opposite direction: That didn't work because of ou= r
defaulting to new (no directed EOI in sight yet back at that time). I
wonder if overriding the ack method isn't actually just papering over t= he
underlying actual issue here, whatever that is. IOW with the edge vs level<= br> mismatch addressed I'd hope the override could then be dropped again.


=C2=A0- = I did override the IRQ configuration all allong my debugs (the handler was = correctly set to level, yet not all flags were identical between dom0 and b= are metal). In the end, with the ioapic_ack=3Dnew, I could even leave the w= rong edge binding for IRQ7.

=C2=A0- besides the touchpad, the ACPI EC was also non functional witho= ut forcing ioapic_ack. And in bare metal the EC does a lot of work of durin= g early kernel setup.

= =C2=A0S=C3=A9bastien
--0000000000005ce88c06132331f4-- From xen-devel-bounces@lists.xenproject.org Fri Mar 08 10:14:29 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2024 10:14:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690186.1075975 (Exim 4.92) (envelope-from ) id 1riXF7-0002HS-TK; Fri, 08 Mar 2024 10:14:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690186.1075975; Fri, 08 Mar 2024 10:14:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riXF7-0002HL-PA; Fri, 08 Mar 2024 10:14:21 +0000 Received: by outflank-mailman (input) for mailman id 690186; Fri, 08 Mar 2024 10:14:20 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riXF6-0002HF-DM for xen-devel@lists.xenproject.org; Fri, 08 Mar 2024 10:14:20 +0000 Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [2a00:1450:4864:20::536]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 9fb8ebf4-dd34-11ee-a1ee-f123f15fe8a2; Fri, 08 Mar 2024 11:14:18 +0100 (CET) Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-56647babfe6so913861a12.3 for ; Fri, 08 Mar 2024 02:14:18 -0800 (PST) Received: from [192.168.206.239] ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id f27-20020a170906085b00b00a44ef54b6b6sm6715591ejd.58.2024.03.08.02.14.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 Mar 2024 02:14:17 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 9fb8ebf4-dd34-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709892858; x=1710497658; darn=lists.xenproject.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=hRQ6Jn+GB5bFeLy1drOwXVbCMQkuPuur8nXU6OgB4M8=; b=YPrTcYzGySGPLfubMGMvIoHJU3ezQMsCytfKa5U4jxyMSg7tno7tlsEYQejxEZnxYE ZpokT3MtN/U78ETivqAtIcan+l9roGQFdbFamNIKohGy5pGGY1k7IQu0Ct/ET3L1vgsb KsPQ4IuM5eInIEzYGhIFDBK8aGtqZOvB9KhiT0pGkF2zY/SgiAl4XjyMEgGXMI953YQE +Zp/p20gARWqf4frKhP0aUh/ZPtG7ybc6Ntai6VNZ/byIQbl8QK4rNylBd7eUws2E/m7 As2qgYRNOo4rHEevI+DehbmnYpEe96QDuJ5D8DmVDfUjUFJWXaXJPg0ejhDjuK+fgIiW 87Iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709892858; x=1710497658; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=hRQ6Jn+GB5bFeLy1drOwXVbCMQkuPuur8nXU6OgB4M8=; b=av0WPuh6EWz052FO4gHwUnzMUagJkxuPYk+G3XAWFqQgL8bKG4r962DAotF1NiK40z TTWLwTMHzFoChqCa0m9c7JChm+j4JJZDsACJc5oKO+i1FkqTfNkG87afpFsZDKKBbxiL VUgVfKdlKCeduNzkBFSG7mTGWKzd454e2oMluy7DmCWpq+htxMw52D2TQf7blg9xtecG aIbDTqfasw38RitBZrS9wCF3d3pCfBpyYawt6iO/dQF1HAucCSQ/GKYQLmgoZN5PPMvi OENk43N3S0sjcT4snisdAx2leZyFptximIjnRXCdp6sqoqy3Ay0IwWp0ApI7tA55RhOv XNQQ== X-Forwarded-Encrypted: i=1; AJvYcCU3lRJuFb1CYzoUv06RNIpbHPErTN+1eHNyaGJlkF361g1D9gKKiI1bMmHdokb8qhSbRmhIw/UkYzfQGSSVFCvPOEUzBGSc/i325AGbQPY= X-Gm-Message-State: AOJu0Ywa311/L0AyxVNPiCdjUWl0kZk3ho1a5n07ATeaGbKyJS7vT1i/ eyHqJpBeiISO2IAOke+OYBSpVypL1+urWx1tm/q/yMnmWtRBOAJG X-Google-Smtp-Source: AGHT+IEZPM49OF6HYMrpuvD4RCAYg5eXoujFXBZeT826+b0JWAoRM+elpa/zZ+SSG6Y3hSUiETLnFA== X-Received: by 2002:a17:906:4712:b0:a45:84e7:b265 with SMTP id y18-20020a170906471200b00a4584e7b265mr8632868ejq.7.1709892857406; Fri, 08 Mar 2024 02:14:17 -0800 (PST) Message-ID: <4b6c9458efc85a57c14c6b6147d47245fece1f88.camel@gmail.com> Subject: Re: [PATCH v5 12/23] xen/riscv: introduce io.h From: Oleksii To: Jan Beulich Cc: Alistair Francis , Bob Eshleman , Connor Davis , Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu , xen-devel@lists.xenproject.org Date: Fri, 08 Mar 2024 11:14:15 +0100 In-Reply-To: <82375df2-f7fd-43a1-9183-f4823fe791ec@suse.com> References: <807c31d5-0c5a-4646-ba90-2f284289069f@suse.com> <2a3e49bf94332c17b50e4f0f745e4b28b16dceb1.camel@gmail.com> <2a05c233-b3c5-417c-bd6b-8b1c21f03c3d@suse.com> <9ec718f3bba178d437035add3c7467011fc3ffc0.camel@gmail.com> <82375df2-f7fd-43a1-9183-f4823fe791ec@suse.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.50.2 (3.50.2-1.fc39) MIME-Version: 1.0 On Fri, 2024-03-08 at 08:26 +0100, Jan Beulich wrote: > On 07.03.2024 21:54, Oleksii wrote: > > On Thu, 2024-03-07 at 21:49 +0100, Oleksii wrote: > > > On Thu, 2024-03-07 at 18:14 +0100, Jan Beulich wrote: > > > > For plain writes it should at least be "=3DQo" then, yes. > > > Constraints Q is a machine specific constraint, and I am not sure > > > that > > > it makes sense to use "=3Do" only and probably it is a reason why > > > it is > > > enough only "r". Does it make sense? > > Probably for RISC-V can be used: > > RISC-V=E2=80=94config/riscv/constraints.md > > =C2=A0=C2=A0 ... > > =C2=A0=C2=A0 A > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 An address that is held in a gener= al-purpose register. > > =C2=A0=C2=A0 ... >=20 > Just from the description I would have said no, but looking at what > "A" > actually expands to it is indeed RISC-V's counterpart of Arm's "Q". > So > yes, this looks like what amo* want to use, and then as a real > operand, > not just a fake one. I am not sure that I know how to check correctly how "A" expands, but I tried to look at code which will be generated with and without constraints and it is the same: // static inline void __raw_writel(uint32_t val, volatile void __iomem *addr) // { // asm volatile ( "sw %0, 0(%1)" : : "r" (val), "r"(addr) ); // } =20 static inline void __raw_writel(uint32_t val, volatile void __iomem *addr) { asm volatile ( "sw %0, %1" : : "r" (val), "Ao" (*(volatile uint32_t __force *)addr) ); } =20 ffffffffc003d774: aabbd7b7 lui a5,0xaabbd ffffffffc003d778: cdd78793 add a5,a5,-803 # ffffffffaabbccdd ffffffffc003d77c: f8f42423 sw a5,-120(s0) ffffffffc003d780: 0140000f fence w,o =20 >=20 > > AArch64 family=E2=80=94config/aarch64/constraints.md: > > =C2=A0=C2=A0 ... > > =C2=A0=C2=A0 Q > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A memory address which uses a sing= le base register with no > > =C2=A0=C2=A0 offset > > =C2=A0=C2=A0 ... > > Also 'no offset' explains why it was added 'o' constraint for Arm > > additionally. >=20 > I don't think it does. >=20 > Jan From xen-devel-bounces@lists.xenproject.org Fri Mar 08 10:44:37 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2024 10:44:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690194.1075985 (Exim 4.92) (envelope-from ) id 1riXiB-0007mP-3O; Fri, 08 Mar 2024 10:44:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690194.1075985; Fri, 08 Mar 2024 10:44:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riXiA-0007mI-VQ; Fri, 08 Mar 2024 10:44:22 +0000 Received: by outflank-mailman (input) for mailman id 690194; Fri, 08 Mar 2024 10:44:21 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riXi9-0007mC-Ip for xen-devel@lists.xenproject.org; Fri, 08 Mar 2024 10:44:21 +0000 Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [2a00:1450:4864:20::634]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id d1a4c762-dd38-11ee-afda-a90da7624cb6; Fri, 08 Mar 2024 11:44:20 +0100 (CET) Received: by mail-ej1-x634.google.com with SMTP id a640c23a62f3a-a45c006ab82so258820866b.3 for ; Fri, 08 Mar 2024 02:44:20 -0800 (PST) Received: from ?IPV6:2003:e5:8715:c000:52ff:24ed:f304:23c0? (p200300e58715c00052ff24edf30423c0.dip0.t-ipconnect.de. [2003:e5:8715:c000:52ff:24ed:f304:23c0]) by smtp.gmail.com with ESMTPSA id qw28-20020a1709066a1c00b00a381ca0e589sm9143282ejc.22.2024.03.08.02.44.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 08 Mar 2024 02:44:19 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d1a4c762-dd38-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709894659; x=1710499459; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=rqyo1Ozj3kkEIPRj2BTXEgAdVk5xtil/9n1qtnu1Pcw=; b=Lu4mSfUUgW2Bw5/gqqPDAcobscRxihzP4vDA9twF98zuMfgXONKEfosHpCb9KXaWam Z5/B0m1/9zd+rxePRx/3zcJg3ctEOkmDuvKODu6SIYr3dnxHCKaN2me8xUecw3ARwpgB 04Eikq3RubK3Lw6ArRija1/V6bQwfToGyQwOI6g31vvQN0enB7nOIeljU7K/gY6920Y4 JjUHejD1rdXKOcJm9MR6lzF/6LeP2ngJb7aeJzX6ZGzchEHBLFyIge6ElYIN9r80D0AS RTDkxf5gJbUNbKI+bR+gdQT22NYpCWW7i07k/ZCAsn1rs5Oy/Qjpk9OS59AEFIOmBW15 ZBYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709894659; x=1710499459; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=rqyo1Ozj3kkEIPRj2BTXEgAdVk5xtil/9n1qtnu1Pcw=; b=R4N53CoB6G4fSk57doWY0HYquZXuRt6cGgvr8T+jn6xBIxFUxLyg9mgHyClwmVS4Hd o/lA0X0hPlQDVcQopArTL5bJZyoaAlDbhpAqVN3XK4jmkRjDTuBFXT6DkooKNVLk6S45 PQPFfVCYKSmOI//OxcTtHfYEB8oI39sm+fVQFbuljLjoNQP9jhc9ctDmR6oKXJ7onLcz A164Zz6SITW4yyNybahtS/Mm5jk0z77Uizogllj6qqWdYLtSvSH26HT6oNENdPvE26ja +nX88CX7KSoZohRa0zm40xUeIedvmvbOA0LEo9dRQK0x0ATMaU1ez4KCjNjn0YbBRdiN KLNQ== X-Forwarded-Encrypted: i=1; AJvYcCVjU6zT3CKogdbpGh674QYYbD/zxdOmnsj6IFJMw3gzN1jtmIE926Q4mwPyIwv/MD4wUcPKbJyTZZ1z4ALeFftd9sx5BpBLtBLD9d+sge4= X-Gm-Message-State: AOJu0YwFMoUX+A0OfBJ6/CWDWQDTK6/ow70KF1wHPPRb0B3LvG/V9kSp MZlh+6G+ULaPOaG3/M2UBdX6/onkqph7kMZw4odtb8mIUlU2SvyroXyHD+DPufA= X-Google-Smtp-Source: AGHT+IFa6C3iAF/szUL0WlQeNpe8wcBtHEqOX8Y5ln2fUfYZWdhgUrMKRCSGzkxNxe3X+0IVFHoIFA== X-Received: by 2002:a17:906:35cd:b0:a44:dc35:df19 with SMTP id p13-20020a17090635cd00b00a44dc35df19mr12080192ejb.67.1709894659653; Fri, 08 Mar 2024 02:44:19 -0800 (PST) Message-ID: <23249fa7-1721-4d47-a0d4-b592913e4560@suse.com> Date: Fri, 8 Mar 2024 11:44:18 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/grant-dma-iommu: Convert to platform remove callback returning void Content-Language: en-US To: =?UTF-8?Q?Uwe_Kleine-K=C3=B6nig?= , Stefano Stabellini Cc: Oleksandr Tyshchenko , xen-devel@lists.xenproject.org, kernel@pengutronix.de References: <20240307181135.191192-2-u.kleine-koenig@pengutronix.de> From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= In-Reply-To: <20240307181135.191192-2-u.kleine-koenig@pengutronix.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 07.03.24 19:11, Uwe Kleine-König wrote: > The .remove() callback for a platform driver returns an int which makes > many driver authors wrongly assume it's possible to do error handling by > returning an error code. However the value returned is ignored (apart > from emitting a warning) and this typically results in resource leaks. > > To improve here there is a quest to make the remove callback return > void. In the first step of this quest all drivers are converted to > .remove_new(), which already returns void. Eventually after all drivers > are converted, .remove_new() will be renamed to .remove(). > > Trivially convert this driver from always returning zero in the remove > callback to the void returning variant. > > Signed-off-by: Uwe Kleine-König Reviewed-by: Juergen Gross Juergen From xen-devel-bounces@lists.xenproject.org Fri Mar 08 11:21:17 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2024 11:21:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690221.1076009 (Exim 4.92) (envelope-from ) id 1riYHq-0006P5-7n; Fri, 08 Mar 2024 11:21:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690221.1076009; Fri, 08 Mar 2024 11:21:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riYHq-0006Om-4d; Fri, 08 Mar 2024 11:21:14 +0000 Received: by outflank-mailman (input) for mailman id 690221; Fri, 08 Mar 2024 11:21:12 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riYHo-00067S-Te for xen-devel@lists.xenproject.org; Fri, 08 Mar 2024 11:21:12 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id f80cadda-dd3d-11ee-afda-a90da7624cb6; Fri, 08 Mar 2024 12:21:12 +0100 (CET) Received: from nico.bugseng.com (unknown [46.228.253.194]) by support.bugseng.com (Postfix) with ESMTPSA id 5DC274EE074E; Fri, 8 Mar 2024 12:21:10 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f80cadda-dd3d-11ee-afda-a90da7624cb6 From: Nicola Vetrini To: nicola.vetrini@bugseng.com, xen-devel@lists.xenproject.org Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, consulting@bugseng.com, bertrand.marquis@arm.com, julien@xen.org, Andrew Cooper , George Dunlap , Jan Beulich , Wei Liu Subject: [XEN PATCH v2 2/7] xen/include: address violations of MISRA C Rule 20.7 Date: Fri, 8 Mar 2024 12:20:59 +0100 Message-Id: <5be252bfb30682d33aecca11921dcdfcc17f9ae6.1709896401.git.nicola.vetrini@bugseng.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit MISRA C Rule 20.7 states: "Expressions resulting from the expansion of macro parameters shall be enclosed in parentheses". Therefore, some macro definitions should gain additional parentheses to ensure that all current and future users will be safe with respect to expansions that can possibly alter the semantics of the passed-in macro parameter. No functional change. Signed-off-by: Nicola Vetrini --- Changes in v2: - split from an earlier patch --- xen/include/xen/bug.h | 2 +- xen/include/xen/init.h | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/xen/include/xen/bug.h b/xen/include/xen/bug.h index 2c45c462fc63..77fe1e1ba840 100644 --- a/xen/include/xen/bug.h +++ b/xen/include/xen/bug.h @@ -80,7 +80,7 @@ struct bug_frame { [bf_type] "i" (type), \ [bf_ptr] "i" (ptr), \ [bf_msg] "i" (msg), \ - [bf_line_lo] "i" ((line & ((1 << BUG_LINE_LO_WIDTH) - 1)) \ + [bf_line_lo] "i" (((line) & ((1 << BUG_LINE_LO_WIDTH) - 1)) \ << BUG_DISP_WIDTH), \ [bf_line_hi] "i" (((line) >> BUG_LINE_LO_WIDTH) << BUG_DISP_WIDTH) diff --git a/xen/include/xen/init.h b/xen/include/xen/init.h index 1d7c0216bc80..0a4223833755 100644 --- a/xen/include/xen/init.h +++ b/xen/include/xen/init.h @@ -63,9 +63,9 @@ typedef int (*initcall_t)(void); typedef void (*exitcall_t)(void); #define presmp_initcall(fn) \ - const static initcall_t __initcall_##fn __init_call("presmp") = fn + const static initcall_t __initcall_##fn __init_call("presmp") = (fn) #define __initcall(fn) \ - const static initcall_t __initcall_##fn __init_call("1") = fn + const static initcall_t __initcall_##fn __init_call("1") = (fn) #define __exitcall(fn) \ static exitcall_t __exitcall_##fn __exit_call = fn -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Mar 08 11:21:17 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2024 11:21:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690223.1076035 (Exim 4.92) (envelope-from ) id 1riYHs-00074d-To; Fri, 08 Mar 2024 11:21:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690223.1076035; Fri, 08 Mar 2024 11:21:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riYHs-00074W-R7; Fri, 08 Mar 2024 11:21:16 +0000 Received: by outflank-mailman (input) for mailman id 690223; Fri, 08 Mar 2024 11:21:15 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riYHr-00067H-Fd for xen-devel@lists.xenproject.org; Fri, 08 Mar 2024 11:21:15 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id f8c7a6ae-dd3d-11ee-a1ee-f123f15fe8a2; Fri, 08 Mar 2024 12:21:13 +0100 (CET) Received: from nico.bugseng.com (unknown [46.228.253.194]) by support.bugseng.com (Postfix) with ESMTPSA id 938824EE0751; Fri, 8 Mar 2024 12:21:12 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f8c7a6ae-dd3d-11ee-a1ee-f123f15fe8a2 From: Nicola Vetrini To: nicola.vetrini@bugseng.com, xen-devel@lists.xenproject.org Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, consulting@bugseng.com, bertrand.marquis@arm.com, julien@xen.org, Andrew Cooper , George Dunlap , Jan Beulich , Wei Liu Subject: [XEN PATCH v2 4/7] xen/param: address violations of MISRA C Rule 20.7 Date: Fri, 8 Mar 2024 12:21:01 +0100 Message-Id: <6ad91190bd777ee76d94efbe71341a38dbcdb428.1709896401.git.nicola.vetrini@bugseng.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit MISRA C Rule 20.7 states: "Expressions resulting from the expansion of macro parameters shall be enclosed in parentheses". Therefore, some macro definitions should gain additional parentheses to ensure that all current and future users will be safe with respect to expansions that can possibly alter the semantics of the passed-in macro parameter. No functional change. Signed-off-by: Nicola Vetrini --- xen/include/xen/param.h | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/xen/include/xen/param.h b/xen/include/xen/param.h index 13607e0e50e0..1bdbab34ab1f 100644 --- a/xen/include/xen/param.h +++ b/xen/include/xen/param.h @@ -45,42 +45,42 @@ extern const struct kernel_param __setup_start[], __setup_end[]; #define TEMP_NAME(base) _TEMP_NAME(base, __LINE__) #define custom_param(_name, _var) \ - __setup_str __setup_str_##_var[] = _name; \ + __setup_str __setup_str_##_var[] = (_name); \ __kparam __setup_##_var = \ { .name = __setup_str_##_var, \ .type = OPT_CUSTOM, \ - .par.func = _var } + .par.func = (_var) } #define boolean_param(_name, _var) \ - __setup_str __setup_str_##_var[] = _name; \ + __setup_str __setup_str_##_var[] = (_name); \ __kparam __setup_##_var = \ { .name = __setup_str_##_var, \ .type = OPT_BOOL, \ .len = sizeof(_var) + \ BUILD_BUG_ON_ZERO(sizeof(_var) != sizeof(bool)), \ - .par.var = &_var } + .par.var = &(_var) } #define integer_param(_name, _var) \ - __setup_str __setup_str_##_var[] = _name; \ + __setup_str __setup_str_##_var[] = (_name); \ __kparam __setup_##_var = \ { .name = __setup_str_##_var, \ .type = OPT_UINT, \ .len = sizeof(_var), \ - .par.var = &_var } + .par.var = &(_var) } #define size_param(_name, _var) \ - __setup_str __setup_str_##_var[] = _name; \ + __setup_str __setup_str_##_var[] = (_name); \ __kparam __setup_##_var = \ { .name = __setup_str_##_var, \ .type = OPT_SIZE, \ .len = sizeof(_var), \ - .par.var = &_var } + .par.var = &(_var) } #define string_param(_name, _var) \ - __setup_str __setup_str_##_var[] = _name; \ + __setup_str __setup_str_##_var[] = (_name); \ __kparam __setup_##_var = \ { .name = __setup_str_##_var, \ .type = OPT_STR, \ .len = sizeof(_var), \ - .par.var = &_var } + .par.var = &(_var) } #define ignore_param(_name) \ - __setup_str TEMP_NAME(__setup_str_ign)[] = _name; \ + __setup_str TEMP_NAME(__setup_str_ign)[] = (_name); \ __kparam TEMP_NAME(__setup_ign) = \ { .name = TEMP_NAME(__setup_str_ign), \ .type = OPT_IGNORE } -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Mar 08 11:21:17 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2024 11:21:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690219.1075995 (Exim 4.92) (envelope-from ) id 1riYHo-00067a-Qv; Fri, 08 Mar 2024 11:21:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690219.1075995; Fri, 08 Mar 2024 11:21:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riYHo-00067T-N7; Fri, 08 Mar 2024 11:21:12 +0000 Received: by outflank-mailman (input) for mailman id 690219; Fri, 08 Mar 2024 11:21:11 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riYHn-00067H-C8 for xen-devel@lists.xenproject.org; Fri, 08 Mar 2024 11:21:11 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id f65b130e-dd3d-11ee-a1ee-f123f15fe8a2; Fri, 08 Mar 2024 12:21:09 +0100 (CET) Received: from nico.bugseng.com (unknown [46.228.253.194]) by support.bugseng.com (Postfix) with ESMTPSA id 02CC04EE0738; Fri, 8 Mar 2024 12:21:06 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f65b130e-dd3d-11ee-a1ee-f123f15fe8a2 From: Nicola Vetrini To: nicola.vetrini@bugseng.com, xen-devel@lists.xenproject.org Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, consulting@bugseng.com, bertrand.marquis@arm.com, julien@xen.org, Andrew Cooper , George Dunlap , Jan Beulich , Wei Liu , Volodymyr Babchuk , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Rahul Singh Subject: [XEN PATCH v2 0/7] address some violations of MISRA C Rule 20.7 Date: Fri, 8 Mar 2024 12:20:57 +0100 Message-Id: X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Hi all, this series aims to refactor some macros that cause violations of MISRA C Rule 20.7 ("Expressions resulting from the expansion of macro parameters shall be enclosed in parentheses"). All the macros touched by these patches are in some way involved in violations, and the strategy adopted to bring them into compliance is to add parentheses around macro arguments where needed. Given that the community has previously requested a deviation from the rule, as stated in docs/misra/deviations.rst, and reported below for convenience [1], some macro parameters do not need any adjusting (e.g., when used as lhs to an assignment in statement expressions), but in some cases (most notably in patch 3) such adjustments have been made for consistency. This series fixes a significant portion of the violations on Arm (from ~14000 to ~2500). On x86, though there is one patch touching it, there are still many more; they will be part of a later series. Changes in v2: - Removed a hunk of patch 1 touching __config_enabled (will be deviated in a subsequent series). - Split patch 1 into three patches, for easier reviewing. - Made minor adjustments to "xen-arm-address-some...". - Dropped GUARD(1) hunk from the x86 patch. - Dropped patch 4, 5 and 10: they will be subject to a deviation in the future. - Patch 7, 8, 9 have been committed already. Nicola Vetrini (7): xen/spinlock: address violations of MISRA C Rule 20.7 xen/include: address violations of MISRA C Rule 20.7 xen/list: address violations of MISRA C Rule 20.7 xen/param: address violations of MISRA C Rule 20.7 xen/arm: address some violations of MISRA C Rule 20.7 x86/irq: parenthesize negative constants arm/smmu: address some violations of MISRA C Rule 20.7 xen/arch/arm/arm64/cpufeature.c | 14 ++-- xen/arch/arm/cpuerrata.c | 8 +-- xen/arch/arm/include/asm/arm64/sysregs.h | 2 +- xen/arch/arm/include/asm/guest_atomics.h | 4 +- xen/arch/arm/include/asm/mm.h | 2 +- xen/arch/arm/include/asm/smccc.h | 36 +++++----- xen/arch/arm/include/asm/vgic-emul.h | 8 +-- xen/arch/arm/vcpreg.c | 5 +- xen/arch/x86/include/asm/irq.h | 8 +-- xen/drivers/passthrough/arm/smmu.c | 4 +- xen/include/xen/bug.h | 2 +- xen/include/xen/init.h | 4 +- xen/include/xen/list.h | 83 ++++++++++++------------ xen/include/xen/param.h | 22 +++---- xen/include/xen/spinlock.h | 2 +- 15 files changed, 102 insertions(+), 102 deletions(-) -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Mar 08 11:21:17 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2024 11:21:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690220.1076005 (Exim 4.92) (envelope-from ) id 1riYHq-0006Lr-0P; Fri, 08 Mar 2024 11:21:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690220.1076005; Fri, 08 Mar 2024 11:21:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riYHp-0006Lk-TS; Fri, 08 Mar 2024 11:21:13 +0000 Received: by outflank-mailman (input) for mailman id 690220; Fri, 08 Mar 2024 11:21:12 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riYHo-00067H-2M for xen-devel@lists.xenproject.org; Fri, 08 Mar 2024 11:21:12 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id f70e9300-dd3d-11ee-a1ee-f123f15fe8a2; Fri, 08 Mar 2024 12:21:10 +0100 (CET) Received: from nico.bugseng.com (unknown [46.228.253.194]) by support.bugseng.com (Postfix) with ESMTPSA id 0CAA94EE074D; Fri, 8 Mar 2024 12:21:08 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f70e9300-dd3d-11ee-a1ee-f123f15fe8a2 From: Nicola Vetrini To: nicola.vetrini@bugseng.com, xen-devel@lists.xenproject.org Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, consulting@bugseng.com, bertrand.marquis@arm.com, julien@xen.org, Andrew Cooper , George Dunlap , Jan Beulich , Wei Liu Subject: [XEN PATCH v2 1/7] xen/spinlock: address violations of MISRA C Rule 20.7 Date: Fri, 8 Mar 2024 12:20:58 +0100 Message-Id: <59e9749d3c6a22469bc9fb804b7b7c13850e9e94.1709896401.git.nicola.vetrini@bugseng.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit MISRA C Rule 20.7 states: "Expressions resulting from the expansion of macro parameters shall be enclosed in parentheses". Therefore, some macro definitions should gain additional parentheses to ensure that all current and future users will be safe with respect to expansions that can possibly alter the semantics of the passed-in macro parameter. No functional change. Signed-off-by: Nicola Vetrini --- xen/include/xen/spinlock.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/include/xen/spinlock.h b/xen/include/xen/spinlock.h index 1cd9120eac7a..0e6a083dfb9e 100644 --- a/xen/include/xen/spinlock.h +++ b/xen/include/xen/spinlock.h @@ -94,7 +94,7 @@ struct lock_profile_qhead { int32_t idx; /* index for printout */ }; -#define _LOCK_PROFILE(lockname) { .name = #lockname, .lock = &lockname, } +#define _LOCK_PROFILE(lockname) { .name = #lockname, .lock = &(lockname), } #define _LOCK_PROFILE_PTR(name) \ static struct lock_profile * const __lock_profile_##name \ __used_section(".lockprofile.data") = \ -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Mar 08 11:21:17 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2024 11:21:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690222.1076014 (Exim 4.92) (envelope-from ) id 1riYHq-0006VM-I6; Fri, 08 Mar 2024 11:21:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690222.1076014; Fri, 08 Mar 2024 11:21:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riYHq-0006U9-Db; Fri, 08 Mar 2024 11:21:14 +0000 Received: by outflank-mailman (input) for mailman id 690222; Fri, 08 Mar 2024 11:21:13 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riYHp-00067S-JD for xen-devel@lists.xenproject.org; Fri, 08 Mar 2024 11:21:13 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id f86ed5ae-dd3d-11ee-afda-a90da7624cb6; Fri, 08 Mar 2024 12:21:12 +0100 (CET) Received: from nico.bugseng.com (unknown [46.228.253.194]) by support.bugseng.com (Postfix) with ESMTPSA id EE06F4EE074F; Fri, 8 Mar 2024 12:21:11 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f86ed5ae-dd3d-11ee-afda-a90da7624cb6 From: Nicola Vetrini To: nicola.vetrini@bugseng.com, xen-devel@lists.xenproject.org Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, consulting@bugseng.com, bertrand.marquis@arm.com, julien@xen.org, Andrew Cooper , George Dunlap , Jan Beulich , Wei Liu Subject: [XEN PATCH v2 3/7] xen/list: address violations of MISRA C Rule 20.7 Date: Fri, 8 Mar 2024 12:21:00 +0100 Message-Id: X-Mailer: git-send-email 2.34.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit MISRA C Rule 20.7 states: "Expressions resulting from the expansion of macro parameters shall be enclosed in parentheses". Therefore, some macro definitions should gain additional parentheses to ensure that all current and future users will be safe with respect to expansions that can possibly alter the semantics of the passed-in macro parameter. No functional change. Signed-off-by: Nicola Vetrini --- Changes in v2: - changes to list.h are all in this patch; - Parenthesized some instances of "pos" and "n" even when already covered by the deviation on the lhs of an assingment for consistency. --- xen/include/xen/list.h | 83 +++++++++++++++++++++--------------------- 1 file changed, 41 insertions(+), 42 deletions(-) diff --git a/xen/include/xen/list.h b/xen/include/xen/list.h index b5eab3a1eb6c..27cafcce2c82 100644 --- a/xen/include/xen/list.h +++ b/xen/include/xen/list.h @@ -479,9 +479,9 @@ static inline void list_splice_init(struct list_head *list, * @n: another &struct list_head to use as temporary storage * @head: the head for your list. */ -#define list_for_each_backwards_safe(pos, n, head) \ - for ( pos = (head)->prev, n = pos->prev; pos != (head); \ - pos = n, n = pos->prev ) +#define list_for_each_backwards_safe(pos, n, head) \ + for ( (pos) = (head)->prev, n = (pos)->prev; (pos) != (head); \ + (pos) = n, n = (pos)->prev ) /** * list_for_each_entry - iterate over list of given type @@ -490,9 +490,9 @@ static inline void list_splice_init(struct list_head *list, * @member: the name of the list_struct within the struct. */ #define list_for_each_entry(pos, head, member) \ - for (pos = list_entry((head)->next, typeof(*pos), member); \ - &pos->member != (head); \ - pos = list_entry(pos->member.next, typeof(*pos), member)) + for ((pos) = list_entry((head)->next, typeof(*(pos)), member); \ + &(pos)->member != (head); \ + (pos) = list_entry((pos)->member.next, typeof(*(pos)), member)) /** * list_for_each_entry_reverse - iterate backwards over list of given type. @@ -501,9 +501,9 @@ static inline void list_splice_init(struct list_head *list, * @member: the name of the list_struct within the struct. */ #define list_for_each_entry_reverse(pos, head, member) \ - for (pos = list_entry((head)->prev, typeof(*pos), member); \ - &pos->member != (head); \ - pos = list_entry(pos->member.prev, typeof(*pos), member)) + for ((pos) = list_entry((head)->prev, typeof(*(pos)), member); \ + &(pos)->member != (head); \ + (pos) = list_entry((pos)->member.prev, typeof(*(pos)), member)) /** * list_prepare_entry - prepare a pos entry for use in @@ -516,7 +516,7 @@ static inline void list_splice_init(struct list_head *list, * list_for_each_entry_continue. */ #define list_prepare_entry(pos, head, member) \ - ((pos) ? : list_entry(head, typeof(*pos), member)) + ((pos) ? : list_entry(head, typeof(*(pos)), member)) /** * list_for_each_entry_continue - continue iteration over list of given type @@ -527,10 +527,10 @@ static inline void list_splice_init(struct list_head *list, * Continue to iterate over list of given type, continuing after * the current position. */ -#define list_for_each_entry_continue(pos, head, member) \ - for (pos = list_entry(pos->member.next, typeof(*pos), member); \ - &pos->member != (head); \ - pos = list_entry(pos->member.next, typeof(*pos), member)) +#define list_for_each_entry_continue(pos, head, member) \ + for ((pos) = list_entry((pos)->member.next, typeof(*(pos)), member); \ + &(pos)->member != (head); \ + (pos) = list_entry((pos)->member.next, typeof(*(pos)), member)) /** * list_for_each_entry_from - iterate over list of given type from the @@ -542,8 +542,8 @@ static inline void list_splice_init(struct list_head *list, * Iterate over list of given type, continuing from current position. */ #define list_for_each_entry_from(pos, head, member) \ - for (; &pos->member != (head); \ - pos = list_entry(pos->member.next, typeof(*pos), member)) + for (; &(pos)->member != (head); \ + (pos) = list_entry((pos)->member.next, typeof(*(pos)), member)) /** * list_for_each_entry_safe - iterate over list of given type safe @@ -554,10 +554,10 @@ static inline void list_splice_init(struct list_head *list, * @member: the name of the list_struct within the struct. */ #define list_for_each_entry_safe(pos, n, head, member) \ - for (pos = list_entry((head)->next, typeof(*pos), member), \ - n = list_entry(pos->member.next, typeof(*pos), member); \ - &pos->member != (head); \ - pos = n, n = list_entry(n->member.next, typeof(*n), member)) + for ((pos) = list_entry((head)->next, typeof(*(pos)), member), \ + (n) = list_entry((pos)->member.next, typeof(*(pos)), member); \ + &(pos)->member != (head); \ + (pos) = (n), (n) = list_entry((n)->member.next, typeof(*(n)), member)) /** * list_for_each_entry_safe_continue @@ -569,11 +569,11 @@ static inline void list_splice_init(struct list_head *list, * Iterate over list of given type, continuing after current point, * safe against removal of list entry. */ -#define list_for_each_entry_safe_continue(pos, n, head, member) \ - for (pos = list_entry(pos->member.next, typeof(*pos), member), \ - n = list_entry(pos->member.next, typeof(*pos), member); \ - &pos->member != (head); \ - pos = n, n = list_entry(n->member.next, typeof(*n), member)) +#define list_for_each_entry_safe_continue(pos, n, head, member) \ + for ((pos) = list_entry((pos)->member.next, typeof(*(pos)), member), \ + (n) = list_entry((pos)->member.next, typeof(*(pos)), member); \ + &(pos)->member != (head); \ + (pos) = (n), (n) = list_entry((n)->member.next, typeof(*(n)), member)) /** * list_for_each_entry_safe_from @@ -586,9 +586,9 @@ static inline void list_splice_init(struct list_head *list, * removal of list entry. */ #define list_for_each_entry_safe_from(pos, n, head, member) \ - for (n = list_entry(pos->member.next, typeof(*pos), member); \ - &pos->member != (head); \ - pos = n, n = list_entry(n->member.next, typeof(*n), member)) + for ((n) = list_entry((pos)->member.next, typeof(*(pos)), member); \ + &(pos)->member != (head); \ + (pos) = (n), (n) = list_entry((n)->member.next, typeof(*(n)), member)) /** * list_for_each_entry_safe_reverse @@ -601,10 +601,10 @@ static inline void list_splice_init(struct list_head *list, * of list entry. */ #define list_for_each_entry_safe_reverse(pos, n, head, member) \ - for (pos = list_entry((head)->prev, typeof(*pos), member), \ - n = list_entry(pos->member.prev, typeof(*pos), member); \ - &pos->member != (head); \ - pos = n, n = list_entry(n->member.prev, typeof(*n), member)) + for ((pos) = list_entry((head)->prev, typeof(*(pos)), member), \ + (n) = list_entry((pos)->member.prev, typeof(*(pos)), member); \ + &(pos)->member != (head); \ + (pos) = (n), (n) = list_entry((n)->member.prev, typeof(*(n)), member)) /** * list_for_each_rcu - iterate over an rcu-protected list @@ -616,14 +616,14 @@ static inline void list_splice_init(struct list_head *list, * as long as the traversal is guarded by rcu_read_lock(). */ #define list_for_each_rcu(pos, head) \ - for (pos = (head)->next; \ + for ((pos) = (head)->next; \ rcu_dereference(pos) != (head); \ - pos = pos->next) + (pos) = (pos)->next) #define __list_for_each_rcu(pos, head) \ - for (pos = (head)->next; \ + for ((pos) = (head)->next; \ rcu_dereference(pos) != (head); \ - pos = pos->next) + (pos) = (pos)->next) /** * list_for_each_safe_rcu @@ -638,9 +638,9 @@ static inline void list_splice_init(struct list_head *list, * as long as the traversal is guarded by rcu_read_lock(). */ #define list_for_each_safe_rcu(pos, n, head) \ - for (pos = (head)->next; \ - n = rcu_dereference(pos)->next, pos != (head); \ - pos = n) + for ((pos) = (head)->next; \ + (n) = rcu_dereference(pos)->next, (pos) != (head); \ + (pos) = (n)) /** * list_for_each_entry_rcu - iterate over rcu list of given type @@ -653,9 +653,9 @@ static inline void list_splice_init(struct list_head *list, * as long as the traversal is guarded by rcu_read_lock(). */ #define list_for_each_entry_rcu(pos, head, member) \ - for (pos = list_entry((head)->next, typeof(*pos), member); \ + for ((pos) = list_entry((head)->next, typeof(*(pos)), member); \ &rcu_dereference(pos)->member != (head); \ - pos = list_entry(pos->member.next, typeof(*pos), member)) + (pos) = list_entry((pos)->member.next, typeof(*(pos)), member)) /** * list_for_each_continue_rcu @@ -977,4 +977,3 @@ static inline void hlist_add_after_rcu(struct hlist_node *prev, pos = pos->next) #endif /* __XEN_LIST_H__ */ - -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Mar 08 11:21:18 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2024 11:21:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690224.1076045 (Exim 4.92) (envelope-from ) id 1riYHu-0007Lb-9O; Fri, 08 Mar 2024 11:21:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690224.1076045; Fri, 08 Mar 2024 11:21:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riYHu-0007LM-3q; Fri, 08 Mar 2024 11:21:18 +0000 Received: by outflank-mailman (input) for mailman id 690224; Fri, 08 Mar 2024 11:21:16 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riYHs-00067H-Fl for xen-devel@lists.xenproject.org; Fri, 08 Mar 2024 11:21:16 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id f97d751c-dd3d-11ee-a1ee-f123f15fe8a2; Fri, 08 Mar 2024 12:21:14 +0100 (CET) Received: from nico.bugseng.com (unknown [46.228.253.194]) by support.bugseng.com (Postfix) with ESMTPSA id AB5144EE074C; Fri, 8 Mar 2024 12:21:13 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f97d751c-dd3d-11ee-a1ee-f123f15fe8a2 From: Nicola Vetrini To: nicola.vetrini@bugseng.com, xen-devel@lists.xenproject.org Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, consulting@bugseng.com, bertrand.marquis@arm.com, julien@xen.org, Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Wei Liu Subject: [XEN PATCH v2 6/7] x86/irq: parenthesize negative constants Date: Fri, 8 Mar 2024 12:21:03 +0100 Message-Id: <9b7e9135952e51043427e3233305917126c95659.1709896401.git.nicola.vetrini@bugseng.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit These constants are parenthesized to avoid them from possibly influencing the semantics of the constructs where it is used, especially inside macros invocations. This also resolves some violations of MISRA C Rule 20.7 ("Expressions resulting from the expansion of macro parameters shall be enclosed in parentheses"). No functional change. Signed-off-by: Nicola Vetrini --- Changes in v2: - dropped the controversial GUARD(1) hunk --- xen/arch/x86/include/asm/irq.h | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/xen/arch/x86/include/asm/irq.h b/xen/arch/x86/include/asm/irq.h index 082a3d6bbc6a..7d49f3c1904a 100644 --- a/xen/arch/x86/include/asm/irq.h +++ b/xen/arch/x86/include/asm/irq.h @@ -172,16 +172,16 @@ void cleanup_domain_irq_mapping(struct domain *d); void *__ret = radix_tree_lookup(&(d)->arch.irq_pirq, irq); \ __ret ? radix_tree_ptr_to_int(__ret) : 0; \ }) -#define PIRQ_ALLOCATED -1 +#define PIRQ_ALLOCATED (-1) #define domain_pirq_to_emuirq(d, pirq) pirq_field(d, pirq, \ arch.hvm.emuirq, IRQ_UNBOUND) #define domain_emuirq_to_pirq(d, emuirq) ({ \ void *__ret = radix_tree_lookup(&(d)->arch.hvm.emuirq_pirq, emuirq);\ __ret ? radix_tree_ptr_to_int(__ret) : IRQ_UNBOUND; \ }) -#define IRQ_UNBOUND -1 -#define IRQ_PT -2 -#define IRQ_MSI_EMU -3 +#define IRQ_UNBOUND (-1) +#define IRQ_PT (-2) +#define IRQ_MSI_EMU (-3) bool cpu_has_pending_apic_eoi(void); -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Mar 08 11:21:19 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2024 11:21:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690225.1076055 (Exim 4.92) (envelope-from ) id 1riYHv-0007cr-Gz; Fri, 08 Mar 2024 11:21:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690225.1076055; Fri, 08 Mar 2024 11:21:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riYHv-0007cb-Cu; Fri, 08 Mar 2024 11:21:19 +0000 Received: by outflank-mailman (input) for mailman id 690225; Fri, 08 Mar 2024 11:21:17 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riYHt-00067H-Fp for xen-devel@lists.xenproject.org; Fri, 08 Mar 2024 11:21:17 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id f916982d-dd3d-11ee-a1ee-f123f15fe8a2; Fri, 08 Mar 2024 12:21:13 +0100 (CET) Received: from nico.bugseng.com (unknown [46.228.253.194]) by support.bugseng.com (Postfix) with ESMTPSA id 2DF404EE0750; Fri, 8 Mar 2024 12:21:13 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f916982d-dd3d-11ee-a1ee-f123f15fe8a2 From: Nicola Vetrini To: nicola.vetrini@bugseng.com, xen-devel@lists.xenproject.org Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, consulting@bugseng.com, bertrand.marquis@arm.com, julien@xen.org, Volodymyr Babchuk Subject: [XEN PATCH v2 5/7] xen/arm: address some violations of MISRA C Rule 20.7 Date: Fri, 8 Mar 2024 12:21:02 +0100 Message-Id: X-Mailer: git-send-email 2.34.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit MISRA C Rule 20.7 states: "Expressions resulting from the expansion of macro parameters shall be enclosed in parentheses". Therefore, some macro definitions should gain additional parentheses to ensure that all current and future users will be safe with respect to expansions that can possibly alter the semantics of the passed-in macro parameter. No functional change. Signed-off-by: Nicola Vetrini --- Style in arm64/cpufeature.c has not been amended, because this file seems to be kept in sync with its Linux counterpart. Changes in v2: - Added parentheses for consistency --- xen/arch/arm/arm64/cpufeature.c | 14 ++++----- xen/arch/arm/cpuerrata.c | 8 +++--- xen/arch/arm/include/asm/arm64/sysregs.h | 2 +- xen/arch/arm/include/asm/guest_atomics.h | 4 +-- xen/arch/arm/include/asm/mm.h | 2 +- xen/arch/arm/include/asm/smccc.h | 36 ++++++++++++------------ xen/arch/arm/include/asm/vgic-emul.h | 8 +++--- xen/arch/arm/vcpreg.c | 5 ++-- 8 files changed, 40 insertions(+), 39 deletions(-) diff --git a/xen/arch/arm/arm64/cpufeature.c b/xen/arch/arm/arm64/cpufeature.c index 864413d9cc03..6fb8974ade7f 100644 --- a/xen/arch/arm/arm64/cpufeature.c +++ b/xen/arch/arm/arm64/cpufeature.c @@ -78,13 +78,13 @@ #define __ARM64_FTR_BITS(SIGNED, VISIBLE, STRICT, TYPE, SHIFT, WIDTH, SAFE_VAL) \ { \ - .sign = SIGNED, \ - .visible = VISIBLE, \ - .strict = STRICT, \ - .type = TYPE, \ - .shift = SHIFT, \ - .width = WIDTH, \ - .safe_val = SAFE_VAL, \ + .sign = (SIGNED), \ + .visible = (VISIBLE), \ + .strict = (STRICT), \ + .type = (TYPE), \ + .shift = (SHIFT), \ + .width = (WIDTH), \ + .safe_val = (SAFE_VAL), \ } /* Define a feature with unsigned values */ diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c index a28fa6ac78cc..2b7101ea2524 100644 --- a/xen/arch/arm/cpuerrata.c +++ b/xen/arch/arm/cpuerrata.c @@ -461,13 +461,13 @@ static bool has_ssbd_mitigation(const struct arm_cpu_capabilities *entry) #define MIDR_RANGE(model, min, max) \ .matches = is_affected_midr_range, \ - .midr_model = model, \ - .midr_range_min = min, \ - .midr_range_max = max + .midr_model = (model), \ + .midr_range_min = (min), \ + .midr_range_max = (max) #define MIDR_ALL_VERSIONS(model) \ .matches = is_affected_midr_range, \ - .midr_model = model, \ + .midr_model = (model), \ .midr_range_min = 0, \ .midr_range_max = (MIDR_VARIANT_MASK | MIDR_REVISION_MASK) diff --git a/xen/arch/arm/include/asm/arm64/sysregs.h b/xen/arch/arm/include/asm/arm64/sysregs.h index 3fdeb9d8cdef..b593e4028b53 100644 --- a/xen/arch/arm/include/asm/arm64/sysregs.h +++ b/xen/arch/arm/include/asm/arm64/sysregs.h @@ -465,7 +465,7 @@ /* Access to system registers */ #define WRITE_SYSREG64(v, name) do { \ - uint64_t _r = v; \ + uint64_t _r = (v); \ asm volatile("msr "__stringify(name)", %0" : : "r" (_r)); \ } while (0) #define READ_SYSREG64(name) ({ \ diff --git a/xen/arch/arm/include/asm/guest_atomics.h b/xen/arch/arm/include/asm/guest_atomics.h index a1745f8613f6..8893eb9a55d7 100644 --- a/xen/arch/arm/include/asm/guest_atomics.h +++ b/xen/arch/arm/include/asm/guest_atomics.h @@ -32,7 +32,7 @@ static inline void guest_##name(struct domain *d, int nr, volatile void *p) \ perfc_incr(atomics_guest_paused); \ \ domain_pause_nosync(d); \ - name(nr, p); \ + (name)(nr, p); \ domain_unpause(d); \ } @@ -52,7 +52,7 @@ static inline int guest_##name(struct domain *d, int nr, volatile void *p) \ perfc_incr(atomics_guest_paused); \ \ domain_pause_nosync(d); \ - oldbit = name(nr, p); \ + oldbit = (name)(nr, p); \ domain_unpause(d); \ \ return oldbit; \ diff --git a/xen/arch/arm/include/asm/mm.h b/xen/arch/arm/include/asm/mm.h index cbcf3bf14767..48538b5337aa 100644 --- a/xen/arch/arm/include/asm/mm.h +++ b/xen/arch/arm/include/asm/mm.h @@ -250,7 +250,7 @@ static inline void __iomem *ioremap_wc(paddr_t start, size_t len) #define gaddr_to_gfn(ga) _gfn(paddr_to_pfn(ga)) #define mfn_to_maddr(mfn) pfn_to_paddr(mfn_x(mfn)) #define maddr_to_mfn(ma) _mfn(paddr_to_pfn(ma)) -#define vmap_to_mfn(va) maddr_to_mfn(virt_to_maddr((vaddr_t)va)) +#define vmap_to_mfn(va) maddr_to_mfn(virt_to_maddr((vaddr_t)(va))) #define vmap_to_page(va) mfn_to_page(vmap_to_mfn(va)) /* Page-align address and convert to frame number format */ diff --git a/xen/arch/arm/include/asm/smccc.h b/xen/arch/arm/include/asm/smccc.h index 1adcd37443c7..a289c48b7ffd 100644 --- a/xen/arch/arm/include/asm/smccc.h +++ b/xen/arch/arm/include/asm/smccc.h @@ -122,56 +122,56 @@ struct arm_smccc_res { #define __constraint_read_7 __constraint_read_6, "r" (r7) #define __declare_arg_0(a0, res) \ - struct arm_smccc_res *___res = res; \ - register unsigned long r0 ASM_REG(0) = (uint32_t)a0; \ + struct arm_smccc_res *___res = (res); \ + register unsigned long r0 ASM_REG(0) = (uint32_t)(a0); \ register unsigned long r1 ASM_REG(1); \ register unsigned long r2 ASM_REG(2); \ register unsigned long r3 ASM_REG(3) #define __declare_arg_1(a0, a1, res) \ - typeof(a1) __a1 = a1; \ - struct arm_smccc_res *___res = res; \ - register unsigned long r0 ASM_REG(0) = (uint32_t)a0; \ + typeof(a1) __a1 = (a1); \ + struct arm_smccc_res *___res = (res); \ + register unsigned long r0 ASM_REG(0) = (uint32_t)(a0); \ register unsigned long r1 ASM_REG(1) = __a1; \ register unsigned long r2 ASM_REG(2); \ register unsigned long r3 ASM_REG(3) #define __declare_arg_2(a0, a1, a2, res) \ - typeof(a1) __a1 = a1; \ - typeof(a2) __a2 = a2; \ - struct arm_smccc_res *___res = res; \ - register unsigned long r0 ASM_REG(0) = (uint32_t)a0; \ + typeof(a1) __a1 = (a1); \ + typeof(a2) __a2 = (a2); \ + struct arm_smccc_res *___res = (res); \ + register unsigned long r0 ASM_REG(0) = (uint32_t)(a0); \ register unsigned long r1 ASM_REG(1) = __a1; \ register unsigned long r2 ASM_REG(2) = __a2; \ register unsigned long r3 ASM_REG(3) #define __declare_arg_3(a0, a1, a2, a3, res) \ - typeof(a1) __a1 = a1; \ - typeof(a2) __a2 = a2; \ - typeof(a3) __a3 = a3; \ - struct arm_smccc_res *___res = res; \ - register unsigned long r0 ASM_REG(0) = (uint32_t)a0; \ + typeof(a1) __a1 = (a1); \ + typeof(a2) __a2 = (a2); \ + typeof(a3) __a3 = (a3); \ + struct arm_smccc_res *___res = (res); \ + register unsigned long r0 ASM_REG(0) = (uint32_t)(a0); \ register unsigned long r1 ASM_REG(1) = __a1; \ register unsigned long r2 ASM_REG(2) = __a2; \ register unsigned long r3 ASM_REG(3) = __a3 #define __declare_arg_4(a0, a1, a2, a3, a4, res) \ - typeof(a4) __a4 = a4; \ + typeof(a4) __a4 = (a4); \ __declare_arg_3(a0, a1, a2, a3, res); \ register unsigned long r4 ASM_REG(4) = __a4 #define __declare_arg_5(a0, a1, a2, a3, a4, a5, res) \ - typeof(a5) __a5 = a5; \ + typeof(a5) __a5 = (a5); \ __declare_arg_4(a0, a1, a2, a3, a4, res); \ register typeof(a5) r5 ASM_REG(5) = __a5 #define __declare_arg_6(a0, a1, a2, a3, a4, a5, a6, res) \ - typeof(a6) __a6 = a6; \ + typeof(a6) __a6 = (a6); \ __declare_arg_5(a0, a1, a2, a3, a4, a5, res); \ register typeof(a6) r6 ASM_REG(6) = __a6 #define __declare_arg_7(a0, a1, a2, a3, a4, a5, a6, a7, res) \ - typeof(a7) __a7 = a7; \ + typeof(a7) __a7 = (a7); \ __declare_arg_6(a0, a1, a2, a3, a4, a5, a6, res); \ register typeof(a7) r7 ASM_REG(7) = __a7 diff --git a/xen/arch/arm/include/asm/vgic-emul.h b/xen/arch/arm/include/asm/vgic-emul.h index e52fbaa3ec04..fd0cfa2175fe 100644 --- a/xen/arch/arm/include/asm/vgic-emul.h +++ b/xen/arch/arm/include/asm/vgic-emul.h @@ -6,11 +6,11 @@ * a range of registers */ -#define VREG32(reg) reg ... reg + 3 -#define VREG64(reg) reg ... reg + 7 +#define VREG32(reg) (reg) ... ((reg) + 3) +#define VREG64(reg) (reg) ... ((reg) + 7) -#define VRANGE32(start, end) start ... end + 3 -#define VRANGE64(start, end) start ... end + 7 +#define VRANGE32(start, end) (start) ... ((end) + 3) +#define VRANGE64(start, end) (start) ... ((end) + 7) /* * 64 bits registers can be accessible using 32-bit and 64-bit unless diff --git a/xen/arch/arm/vcpreg.c b/xen/arch/arm/vcpreg.c index a2d050070473..019cf34f003a 100644 --- a/xen/arch/arm/vcpreg.c +++ b/xen/arch/arm/vcpreg.c @@ -39,7 +39,8 @@ */ #ifdef CONFIG_ARM_64 -#define WRITE_SYSREG_SZ(sz, val, sysreg) WRITE_SYSREG((uint##sz##_t)val, sysreg) +#define WRITE_SYSREG_SZ(sz, val, sysreg) \ + WRITE_SYSREG((uint##sz##_t)(val), sysreg) #else /* * WRITE_SYSREG{32/64} on arm32 is defined as variadic macro which imposes @@ -64,7 +65,7 @@ static bool func(struct cpu_user_regs *regs, type##sz##_t *r, bool read) \ bool cache_enabled = vcpu_has_cache_enabled(v); \ \ GUEST_BUG_ON(read); \ - WRITE_SYSREG_SZ(sz, *r, reg); \ + WRITE_SYSREG_SZ(sz, *(r), reg); \ \ p2m_toggle_cache(v, cache_enabled); \ \ -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Mar 08 11:21:19 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2024 11:21:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690226.1076060 (Exim 4.92) (envelope-from ) id 1riYHv-0007fF-Sz; Fri, 08 Mar 2024 11:21:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690226.1076060; Fri, 08 Mar 2024 11:21:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riYHv-0007du-KY; Fri, 08 Mar 2024 11:21:19 +0000 Received: by outflank-mailman (input) for mailman id 690226; Fri, 08 Mar 2024 11:21:18 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riYHu-00067H-G7 for xen-devel@lists.xenproject.org; Fri, 08 Mar 2024 11:21:18 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id f9d9c3dd-dd3d-11ee-a1ee-f123f15fe8a2; Fri, 08 Mar 2024 12:21:15 +0100 (CET) Received: from nico.bugseng.com (unknown [46.228.253.194]) by support.bugseng.com (Postfix) with ESMTPSA id 5E37C4EE0752; Fri, 8 Mar 2024 12:21:14 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f9d9c3dd-dd3d-11ee-a1ee-f123f15fe8a2 From: Nicola Vetrini To: nicola.vetrini@bugseng.com, xen-devel@lists.xenproject.org Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, consulting@bugseng.com, bertrand.marquis@arm.com, julien@xen.org, Rahul Singh , Volodymyr Babchuk Subject: [XEN PATCH v2 7/7] arm/smmu: address some violations of MISRA C Rule 20.7 Date: Fri, 8 Mar 2024 12:21:04 +0100 Message-Id: <21369cdaa0aa34253716d4c999956faee60445ab.1709896401.git.nicola.vetrini@bugseng.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit MISRA C Rule 20.7 states: "Expressions resulting from the expansion of macro parameters shall be enclosed in parentheses". Therefore, some macro definitions should gain additional parentheses to ensure that all current and future users will be safe with respect to expansions that can possibly alter the semantics of the passed-in macro parameter. No functional change. Signed-off-by: Nicola Vetrini Reviewed-by: Stefano Stabellini --- xen/drivers/passthrough/arm/smmu.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/xen/drivers/passthrough/arm/smmu.c b/xen/drivers/passthrough/arm/smmu.c index 625ed0e41961..83196057a937 100644 --- a/xen/drivers/passthrough/arm/smmu.c +++ b/xen/drivers/passthrough/arm/smmu.c @@ -242,7 +242,7 @@ struct arm_smmu_xen_device { struct iommu_group *group; }; -#define dev_archdata(dev) ((struct arm_smmu_xen_device *)dev->iommu) +#define dev_archdata(dev) ((struct arm_smmu_xen_device *)(dev)->iommu) #define dev_iommu_domain(dev) (dev_archdata(dev)->domain) #define dev_iommu_group(dev) (dev_archdata(dev)->group) @@ -627,7 +627,7 @@ struct arm_smmu_master_cfg { }; #define INVALID_SMENDX -1 #define for_each_cfg_sme(cfg, i, idx, num) \ - for (i = 0; idx = cfg->smendx[i], i < num; ++i) + for (i = 0; idx = (cfg)->smendx[i], (i) < (num); ++(i)) struct arm_smmu_master { struct device_node *of_node; -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Mar 08 11:49:58 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2024 11:49:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690247.1076075 (Exim 4.92) (envelope-from ) id 1riYjR-0005Iu-2h; Fri, 08 Mar 2024 11:49:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690247.1076075; Fri, 08 Mar 2024 11:49:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riYjQ-0005In-Vr; Fri, 08 Mar 2024 11:49:44 +0000 Received: by outflank-mailman (input) for mailman id 690247; Fri, 08 Mar 2024 11:49:43 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riYjP-0005Ih-9s for xen-devel@lists.xenproject.org; Fri, 08 Mar 2024 11:49:43 +0000 Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [2a00:1450:4864:20::22f]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id f315d342-dd41-11ee-afda-a90da7624cb6; Fri, 08 Mar 2024 12:49:41 +0100 (CET) Received: by mail-lj1-x22f.google.com with SMTP id 38308e7fff4ca-2d3f4fef377so26282811fa.1 for ; Fri, 08 Mar 2024 03:49:41 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id q28-20020a056402033c00b005659ea1caf0sm9032689edw.6.2024.03.08.03.49.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 08 Mar 2024 03:49:40 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f315d342-dd41-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709898581; x=1710503381; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=LYSxsbfCaqJmxK/kthROoPnBXg+uGsR3Nai26hb3HRM=; b=HTY+1LaPp5m89fyt3lDomPChTTiPAd3DbIOADKg7M7HBICnYcWJyrsCxkhUjkHDKMw 4Dx8zfx2NbOC7dulmiG1BlZZ9ipeSsXbyM081E7D29cM4YRQBKN2YU6JHjIrKJIsrm+y NvUM/01bKRg9/StLw97S4/ZR5hwFnZElXap7D+0lB1BULNEzHrJZsnl2RBCitOVM8NzF TAdAh/NRFfL2UZGuojb+viWf/P1XbuRfhdS3g5rQMefOL5YXEGXwTfbfHHWOGuM+Pm/n UAItNtGTWmJS+MdUqOz7QFYbBohVh6AVCyGpudQzQHgx+CV6VmnSqGszGfwkNZbl3QTT VRhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709898581; x=1710503381; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=LYSxsbfCaqJmxK/kthROoPnBXg+uGsR3Nai26hb3HRM=; b=pxiqlrRoEG9sfLVRNFjBzA5RGWcZZv8uQOjAPYUxHOjhq3+vba0WIQZHOy8oXRJusl q8KZ8Qedjy+Res/UPbn2v1bZZ4lmUuL5XSGZfA0+yNI58GQ6OCVhRLET6DlcBBwy93hN /4Zd8hfim1/2jN5qgAF2VdNAl9G0rxn6Y/6wZzlPcPZtDu5cSIFSBON4p7yO/WzlMO7r 1KA/LJgzWqg12qFs7ShPrCSajt9KSbJLkSi07AKPIUpCcjlEXszuHrof5UmfbTcxZ63I rosxKr17NUT4zHsnyxsS15VME6/eGfV9/1Nh0K0SzXjuq0AoHjx/Gmbc8iZMKNxsNSGX ya9Q== X-Forwarded-Encrypted: i=1; AJvYcCU191OCWrnhTVCVk3QImrjXfUWXWfmvYxGje8K63btrZEK3M9H/FYTyajoZQv2+kjg6ZN1sTvi+flxSzU4QpdO07QDVXfCvKJ++O73jLZI= X-Gm-Message-State: AOJu0YzCBqtuRdtdHaSFTl2wL9lexNFoimWf+tTbSE843xYGSVaKuGa8 kIz3P2kptK2OAep9dXcwy54gY1HK+252gfEv5QESJUnx9JvFvQof5RFEyQO+gg== X-Google-Smtp-Source: AGHT+IEvkEu52WdorTWlgKesCBAD/gvFoSuDDVv0RA5kXh4FtkYcdKaOMdB/CN3MGDy8tnJHcrPRNA== X-Received: by 2002:a2e:9dd9:0:b0:2d4:874:24a0 with SMTP id x25-20020a2e9dd9000000b002d4087424a0mr3211851ljj.51.1709898581164; Fri, 08 Mar 2024 03:49:41 -0800 (PST) Message-ID: Date: Fri, 8 Mar 2024 12:49:39 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 12/23] xen/riscv: introduce io.h Content-Language: en-US To: Oleksii Cc: Alistair Francis , Bob Eshleman , Connor Davis , Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu , xen-devel@lists.xenproject.org References: <807c31d5-0c5a-4646-ba90-2f284289069f@suse.com> <2a3e49bf94332c17b50e4f0f745e4b28b16dceb1.camel@gmail.com> <2a05c233-b3c5-417c-bd6b-8b1c21f03c3d@suse.com> <9ec718f3bba178d437035add3c7467011fc3ffc0.camel@gmail.com> <82375df2-f7fd-43a1-9183-f4823fe791ec@suse.com> <4b6c9458efc85a57c14c6b6147d47245fece1f88.camel@gmail.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <4b6c9458efc85a57c14c6b6147d47245fece1f88.camel@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 08.03.2024 11:14, Oleksii wrote: > On Fri, 2024-03-08 at 08:26 +0100, Jan Beulich wrote: >> On 07.03.2024 21:54, Oleksii wrote: >>> On Thu, 2024-03-07 at 21:49 +0100, Oleksii wrote: >>>> On Thu, 2024-03-07 at 18:14 +0100, Jan Beulich wrote: >>>>> For plain writes it should at least be "=Qo" then, yes. >>>> Constraints Q is a machine specific constraint, and I am not sure >>>> that >>>> it makes sense to use "=o" only and probably it is a reason why >>>> it is >>>> enough only "r". Does it make sense? >>> Probably for RISC-V can be used: >>> RISC-V—config/riscv/constraints.md >>>    ... >>>    A >>>        An address that is held in a general-purpose register. >>>    ... >> >> Just from the description I would have said no, but looking at what >> "A" >> actually expands to it is indeed RISC-V's counterpart of Arm's "Q". >> So >> yes, this looks like what amo* want to use, and then as a real >> operand, >> not just a fake one. > I am not sure that I know how to check correctly how "A" expands, but I > tried to look at code which will be generated with and without > constraints and it is the same: As expected. > // static inline void __raw_writel(uint32_t val, volatile void > __iomem *addr) > // { > // asm volatile ( "sw %0, 0(%1)" : : "r" (val), "r"(addr) ); > // } > > static inline void __raw_writel(uint32_t val, volatile void __iomem > *addr) > { > asm volatile ( "sw %0, %1" : : "r" (val), "Ao" (*(volatile > uint32_t __force *)addr) ); You want just "A" here though; adding an offset (as "o" permits) would yield an insn which the assembler would reject. Also just to remind you: In write functions you need "=A" (and in amo ones "+A"), i.e. the memory operand then needs to be an output, not an input. Jan From xen-devel-bounces@lists.xenproject.org Fri Mar 08 11:52:01 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2024 11:52:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690252.1076086 (Exim 4.92) (envelope-from ) id 1riYlb-0006jr-Iz; Fri, 08 Mar 2024 11:51:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690252.1076086; Fri, 08 Mar 2024 11:51:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riYlb-0006jk-EB; Fri, 08 Mar 2024 11:51:59 +0000 Received: by outflank-mailman (input) for mailman id 690252; Fri, 08 Mar 2024 11:51:58 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riYla-0006je-4y for xen-devel@lists.xenproject.org; Fri, 08 Mar 2024 11:51:58 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 43e1142b-dd42-11ee-afda-a90da7624cb6; Fri, 08 Mar 2024 12:51:57 +0100 (CET) Received: from truciolo.homenet.telecomitalia.it (host-82-58-32-177.retail.telecomitalia.it [82.58.32.177]) by support.bugseng.com (Postfix) with ESMTPSA id 797D54EE0738; Fri, 8 Mar 2024 12:51:56 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 43e1142b-dd42-11ee-afda-a90da7624cb6 From: Federico Serafini To: xen-devel@lists.xenproject.org Cc: consulting@bugseng.com, Federico Serafini , Andrew Cooper , George Dunlap , Jan Beulich , Julien Grall , Stefano Stabellini , Wei Liu Subject: [XEN PATCH] xen/evtchn: address violations of MISRA C:2012 Rules 16.3 and 16.4 Date: Fri, 8 Mar 2024 12:51:49 +0100 Message-Id: <3ec419e30227a8016c28e04524cd36a549aaddcf.1709898466.git.federico.serafini@bugseng.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Add missing break statements to address violations of MISRA C:2012 Rule 16.3 ("An unconditional `break' statement shall terminate every switch-clause"). Add missing default cases to address violations of MISRA C:2012 Rule 16.4 (Every `switch' statement shall have a `default' label). No functional change. Signed-off-by: Federico Serafini --- xen/common/event_channel.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c index 15aec5dcbb..cf19020e49 100644 --- a/xen/common/event_channel.c +++ b/xen/common/event_channel.c @@ -130,9 +130,12 @@ static bool virq_is_global(unsigned int virq) case VIRQ_ARCH_0 ... VIRQ_ARCH_7: return arch_virq_is_global(virq); + + default: + ASSERT(virq < NR_VIRQS); + break; } - ASSERT(virq < NR_VIRQS); return true; } @@ -846,6 +849,7 @@ int evtchn_send(struct domain *ld, unsigned int lport) break; default: ret = -EINVAL; + break; } out: @@ -1672,6 +1676,9 @@ static void domain_dump_evtchn_info(struct domain *d) case ECS_VIRQ: printk(" v=%d", chn->u.virq); break; + default: + /* Nothing to do in other cases. */ + break; } ssid = xsm_show_security_evtchn(d, chn); -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Mar 08 11:52:05 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2024 11:52:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690253.1076095 (Exim 4.92) (envelope-from ) id 1riYlh-00070H-P4; Fri, 08 Mar 2024 11:52:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690253.1076095; Fri, 08 Mar 2024 11:52:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riYlh-000708-MR; Fri, 08 Mar 2024 11:52:05 +0000 Received: by outflank-mailman (input) for mailman id 690253; Fri, 08 Mar 2024 11:52:04 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riYlg-0006zo-TK for xen-devel@lists.xenproject.org; Fri, 08 Mar 2024 11:52:04 +0000 Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [2a00:1450:4864:20::633]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 47485b3d-dd42-11ee-a1ee-f123f15fe8a2; Fri, 08 Mar 2024 12:52:03 +0100 (CET) Received: by mail-ej1-x633.google.com with SMTP id a640c23a62f3a-a44e3176120so276255166b.1 for ; Fri, 08 Mar 2024 03:52:03 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id lo2-20020a170906fa0200b00a45a687b52asm3964798ejb.213.2024.03.08.03.52.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 08 Mar 2024 03:52:02 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 47485b3d-dd42-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709898722; x=1710503522; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:references:cc:to :from:content-language:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=Yzjvtpd02EXTD0CBLiukYiC98wqWFipIlesqqLdxagc=; b=JbMKBEu8/ujXvvvMfGpBL/ZYYs9R8jd/xEj5YCYIXhoYrLgwOCR0B6rTVAsgohTvHm 03W7Xd0J/w5y1Kh+3HNeH2waMAeaIs1MkeOebCWrWrekii87uWc2opnyeM/IbsOycLYh gvBkxOLEnqMYaN/jHqKOeiFlUkcE6VcBb9eodc0vfVTaV9WoFVHsn/7Tx9ozt3YyJt/X fH9DB8y7YYRxz0/r3FYpuQD+YQnOJBHXg0uC7GZYbrlvlf7lOakiap98D2I2cfQ9ou5a xKfL6XMsRP5E3pnxaciWOtdufGLD7yV9END6R9g/BauZYL3Jrs1ybpfPHGdfptLTCRD8 lT2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709898722; x=1710503522; h=content-transfer-encoding:in-reply-to:autocrypt:references:cc:to :from:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Yzjvtpd02EXTD0CBLiukYiC98wqWFipIlesqqLdxagc=; b=wPeIa8JEIQvU8BLcyRxCl9bBjL9IlHt5f2whvpoyM0XPK/OUH4SxDIRAXHc+SJm7uZ Jff17sSZV7OJsmLiU1w3wMBR/pwcy/QiyC+nA3KIclWcRSTjrDcgjhrKuL9AfItTQf/T EtZrazRobrU7MQDKyGZnb6QaycWA/lPM6++3N7RhqBRbDqo5ZMB0Y1roflvrA9TNK9ur Vlnem+gYhhW9FxViqRWdZY+2V1cMSL+l6YIa7ivghR7WcrqrqOLChq/eBfPfJeDkV8QM uP9QQqyR/frH05cwbR5+JlFo64s/xVINm+7kWFCce/LdNyZ5z9lwsV9pf9j+hga2MMYe gIkw== X-Forwarded-Encrypted: i=1; AJvYcCVwqC41V90MBzOsgIEDNJJvX8peaM/j/fEQ8AoQ8swQwR0ImrZZCs5181FfTwk6t1vPeHdHzdtBGDTWIe4hbu3nXb1mKQMC4JFo/gj0OsY= X-Gm-Message-State: AOJu0Yzff1H3nHTJBEYoirv2cIG8b+iC+2GRGDLeco3f1MF04nAHicWY l5xnVgiZ8L6v7yfFUwmwXAtcMiNd0dHl1EzIyYMYIUGCnxzJHdWyp3oVKjPMkA== X-Google-Smtp-Source: AGHT+IGoWoK7V6eeh0TOne5BkJtCxB5wfbROSlxf9soWoiTAM2vcSnVJ/R0ucKGBDxQmA1d2rgP/Xg== X-Received: by 2002:a17:906:695:b0:a45:1850:e6ed with SMTP id u21-20020a170906069500b00a451850e6edmr11153123ejb.6.1709898722379; Fri, 08 Mar 2024 03:52:02 -0800 (PST) Message-ID: Date: Fri, 8 Mar 2024 12:52:00 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 12/23] xen/riscv: introduce io.h Content-Language: en-US From: Jan Beulich To: Oleksii Cc: Alistair Francis , Bob Eshleman , Connor Davis , Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu , xen-devel@lists.xenproject.org References: <807c31d5-0c5a-4646-ba90-2f284289069f@suse.com> <2a3e49bf94332c17b50e4f0f745e4b28b16dceb1.camel@gmail.com> <2a05c233-b3c5-417c-bd6b-8b1c21f03c3d@suse.com> <9ec718f3bba178d437035add3c7467011fc3ffc0.camel@gmail.com> <82375df2-f7fd-43a1-9183-f4823fe791ec@suse.com> <4b6c9458efc85a57c14c6b6147d47245fece1f88.camel@gmail.com> Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 08.03.2024 12:49, Jan Beulich wrote: > On 08.03.2024 11:14, Oleksii wrote: >> On Fri, 2024-03-08 at 08:26 +0100, Jan Beulich wrote: >>> On 07.03.2024 21:54, Oleksii wrote: >>>> On Thu, 2024-03-07 at 21:49 +0100, Oleksii wrote: >>>>> On Thu, 2024-03-07 at 18:14 +0100, Jan Beulich wrote: >>>>>> For plain writes it should at least be "=Qo" then, yes. >>>>> Constraints Q is a machine specific constraint, and I am not sure >>>>> that >>>>> it makes sense to use "=o" only and probably it is a reason why >>>>> it is >>>>> enough only "r". Does it make sense? >>>> Probably for RISC-V can be used: >>>> RISC-V—config/riscv/constraints.md >>>>    ... >>>>    A >>>>        An address that is held in a general-purpose register. >>>>    ... >>> >>> Just from the description I would have said no, but looking at what >>> "A" >>> actually expands to it is indeed RISC-V's counterpart of Arm's "Q". >>> So >>> yes, this looks like what amo* want to use, and then as a real >>> operand, >>> not just a fake one. >> I am not sure that I know how to check correctly how "A" expands, but I >> tried to look at code which will be generated with and without >> constraints and it is the same: > > As expected. > >> // static inline void __raw_writel(uint32_t val, volatile void >> __iomem *addr) >> // { >> // asm volatile ( "sw %0, 0(%1)" : : "r" (val), "r"(addr) ); >> // } >> >> static inline void __raw_writel(uint32_t val, volatile void __iomem >> *addr) >> { >> asm volatile ( "sw %0, %1" : : "r" (val), "Ao" (*(volatile >> uint32_t __force *)addr) ); > > You want just "A" here though; adding an offset (as "o" permits) would > yield an insn which the assembler would reject. Wait - this is plain SW, so can't it even be the more generic "m" then? (As said, I'm uncertain about "o"; in general I think it's risky to use.) Jan > Also just to remind > you: In write functions you need "=A" (and in amo ones "+A"), i.e. the > memory operand then needs to be an output, not an input. > > Jan From xen-devel-bounces@lists.xenproject.org Fri Mar 08 12:01:58 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2024 12:01:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690263.1076105 (Exim 4.92) (envelope-from ) id 1riYvA-00010w-S8; Fri, 08 Mar 2024 12:01:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690263.1076105; Fri, 08 Mar 2024 12:01:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riYvA-00010p-P4; Fri, 08 Mar 2024 12:01:52 +0000 Received: by outflank-mailman (input) for mailman id 690263; Fri, 08 Mar 2024 12:01:51 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riYv9-00010j-QK for xen-devel@lists.xenproject.org; Fri, 08 Mar 2024 12:01:51 +0000 Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [2a00:1450:4864:20::534]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id a591b237-dd43-11ee-afda-a90da7624cb6; Fri, 08 Mar 2024 13:01:50 +0100 (CET) Received: by mail-ed1-x534.google.com with SMTP id 4fb4d7f45d1cf-5683093ffbbso622893a12.1 for ; Fri, 08 Mar 2024 04:01:50 -0800 (PST) Received: from [192.168.206.239] ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id es14-20020a056402380e00b00566d9c8e6cesm7832390edb.21.2024.03.08.04.01.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 Mar 2024 04:01:49 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a591b237-dd43-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709899310; x=1710504110; darn=lists.xenproject.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=Np6OnpckeZVNGXoI0tK1G+zWIcIRU+/QyLKRbrCJ+xg=; b=lavU1pciln6IdO5JbcKNRGmKeCj5ZGWefTqv5SaWl2IXzajI0nBgpp3Ngbq8ZdCiam NksOLrmTW/M/4pjVhPYPOun4jK3d5nIs/eY6v16662T9CoPRK4zGw/dyrqO/W6ElwMsi tMTmZVVjix5Ve/B/kI16QmRfCI7nTRE6UlMAK3rNXkorTkPp3kcaVfzyMT9df7keYlKF bY96slQ7AMzsElvqcH1d6Hav9rLRB+PT40InQPV6uZg7wKHiNaCQjg2v0p1vu9rYV4X0 APJj3M+x6C9VdljCrZnmLyEnESs1xfPfZ/My1kMNfVtmjGb8LVqKwb65n7WKBDJ/zdM6 QPhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709899310; x=1710504110; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=Np6OnpckeZVNGXoI0tK1G+zWIcIRU+/QyLKRbrCJ+xg=; b=G+iqYl3ekIlb0+sLof1CZ2hpSmQPvo16OFJkwlIbvu8pBipdQtV9kP5yzQanN2nCU+ mJr9VIK0VqTabEtDPWKN2+JdqY8DdhxIjYPkARo7D0DrY67xbhmrydzc7RFCg1Kwibn8 +EdvpHClH4YMvuEG91YMr1DSiSuConh56zEQ0eQLosXfqecEDXzrl9JUZaNDf27WgDRA +gaL6xZ1wdBYWtkNq55TeHEYLGmp4t/Ir+gqrZp1AYfcPsRBusR3ACX1CT1BMZRhkVY6 ZmMoPzddL4OnJbxiHl0VtcHH3KMxZppuZmFYNOzCKfiKt44Ztp9XrAj4dksD50q8rbBQ a9nA== X-Forwarded-Encrypted: i=1; AJvYcCVezf1FTy8T7uLbfQf0o4OWPzJU3LRz+xKPQ33Tk5XGtYOR7XKLWO2EoS9Wel2wkW2oiVtA0I42yoIrrsxlR2c2KkQbFY17LVZnXDlCxY4= X-Gm-Message-State: AOJu0Yw3JV2wXj1OP37y3aQyogcS4Z6Wa+NuZ4QJgPeb61gAzVAdUyXQ 39YUebR+R5ZllpH2y0KHtFKC+9c9aq56HTKXvSvD7yZszHtjIWB4 X-Google-Smtp-Source: AGHT+IHEf4k1cAFCyBc91/yWA6kjAwmW5Cqd9qnnNfQK7YC2A/cxVifFoBV19rWf3XddzR7cbWWAZQ== X-Received: by 2002:a50:aa9c:0:b0:567:23a2:5b1e with SMTP id q28-20020a50aa9c000000b0056723a25b1emr1833514edc.23.1709899309901; Fri, 08 Mar 2024 04:01:49 -0800 (PST) Message-ID: <4343336e663ec5de6c8f322485fb65032a7c0585.camel@gmail.com> Subject: Re: [PATCH] move __read_mostly to xen/cache.h From: Oleksii To: Jan Beulich , Andrew Cooper Cc: George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu , Roger Pau =?ISO-8859-1?Q?Monn=E9?= , Bertrand Marquis , Volodymyr Babchuk , Shawn Anastasio , "xen-devel@lists.xenproject.org" Date: Fri, 08 Mar 2024 13:01:48 +0100 In-Reply-To: References: <893a5ebf-54e2-f2b2-1365-2a6d36ed3a39@suse.com> <64466285-35b8-497c-a12b-60fe0c998ba6@suse.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.50.2 (3.50.2-1.fc39) MIME-Version: 1.0 On Fri, 2024-03-08 at 09:22 +0100, Jan Beulich wrote: > On 07.03.2024 18:08, Oleksii wrote: > > On Fri, 2023-12-22 at 12:09 +0100, Jan Beulich wrote: > > > On 22.12.2023 10:39, Oleksii wrote: > > > > On Tue, 2023-08-08 at 12:32 +0200, Jan Beulich wrote: > > > > > On 08.08.2023 12:18, Andrew Cooper wrote: > > > > > > On 08/08/2023 10:46 am, Jan Beulich wrote: > > > > > > > There's no need for every arch to define its own > > > > > > > identical > > > > > > > copy. > > > > > > > If down > > > > > > > the road an arch needs to customize it, we can add > > > > > > > #ifndef > > > > > > > around > > > > > > > the > > > > > > > common #define. > > > > > > >=20 > > > > > > > To be on the safe side build-breakage-wise, change a > > > > > > > couple > > > > > > > of > > > > > > > #include > > > > > > > to the xen/ equivalent. > > > > > > >=20 > > > > > > > Signed-off-by: Jan Beulich > > > > > >=20 > > > > > > Could we find a better place to put this? > > > > > >=20 > > > > > > __read_mostly is just a section.=C2=A0 It's relationship to the > > > > > > cache is > > > > > > only > > > > > > microarchitectural, and is not the same kind of information > > > > > > as > > > > > > the > > > > > > rest > > > > > > of cache.h > > > > > >=20 > > > > > > __ro_after_init is only here because __read_mostly is here, > > > > > > but > > > > > > has > > > > > > absolutely nothing to do with caches whatsoever. > > > > > >=20 > > > > > > If we're cleaning them up, they ought to live elsewhere. > > > > >=20 > > > > > I would be considering init.h (for having most other > > > > > __section() > > > > > uses, > > > > > and for also needing __read_mostly), but that's not a great > > > > > place > > > > > to > > > > > put these either. In fact I see less connection there than > > > > > for > > > > > cache.h. > > > > > So the primary need is a good suggestion (I'm hesitant to > > > > > suggest > > > > > to > > > > > introduce section.h just for this). > > > > Andrew sent some suggestions here: > > > > https://lore.kernel.org/xen-devel/3df1dad8-3476-458f-9022-160e0af57= d39@citrix.com/ > > > >=20 > > > > Will that work for you? > > >=20 > > > I still need to properly look at the suggested options. > > Have you had a chance to review the suggested options? >=20 > I'm sure you've seen >=20 > https://lists.xen.org/archives/html/xen-devel/2024-01/msg00145.html >=20 > To add to that - xen/linkage.h is for assembly code only right now. > While > I'd be happy to add C stuff there, there's an (imo) obvious issue > with > code churn then: All C files using __read_mostly would then need to > be > changed to include xen/linkage.h. And no, I don't view including the > file > once in a "central" other header file as a viable solution: That's > where > some of our really bad header dependency issues come from. Plus a > goal > ought to be (imo) that touching a header like this one would better > not > result in a full re-build of everything, when doing incremental > builds. >=20 > Same obviously goes for the case of introducing xen/sections.h, i.e. > the > other proposed alternative. >=20 > Bottom line: Given the state of our tree, I still view my proposed > placement as the least bad one for the time being. To change my view, > I'd still expect a _viable_ alternative proposal to be made. Based on your replies, I can conclude that there is no good place for __read_mostly and __ro_after_init. If my conclusion is correct, then an introduction of a new header is required. I totally agree that the inclusion of the introduced header to 'central' header only for the reason not to update all C files using __read_mostly macros is not a good solution, but I don't see an issue with an update of all C files which use __read_mostly/__ro_after_init if it is required. I realize that it can be a huge amount of files, but if the situation requires that, it looks not so bad solution. If to look at places where is included now, then there wouldn't be too many places that needed to be updated. Despite this fact, I don't think that an introduction of xen/section.h is a bad solution, xen/cache.h can also be a good place for it as my understanding of __read_mostly is that it is not only meant for just read-only data, there are performance reasons for using it: /* * __read_mostly is used to keep rarely changing variables out of frequently * updated cachelines. Its use should be reserved for data that is used * frequently in hot paths. Performance traces can help decide when to use * this. You want __read_mostly data to be tightly packed, so that in the * best case multiple frequently read variables for a hot path will be next * to each other in order to reduce the number of cachelines needed to * execute a critical path. */ Not related to my words above, here is a little remark about the patch changes. Does it make sense to wrap the definition of __read_mostly() by "#ifndef __read_mostly" in case architecture decides to redefine it? ~ Oleksii From xen-devel-bounces@lists.xenproject.org Fri Mar 08 12:07:10 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2024 12:07:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690268.1076114 (Exim 4.92) (envelope-from ) id 1riZ0D-0001b4-Bl; Fri, 08 Mar 2024 12:07:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690268.1076114; Fri, 08 Mar 2024 12:07:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riZ0D-0001ax-8m; Fri, 08 Mar 2024 12:07:05 +0000 Received: by outflank-mailman (input) for mailman id 690268; Fri, 08 Mar 2024 12:07:04 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riZ0C-0001an-Bv; Fri, 08 Mar 2024 12:07:04 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riZ0C-0007pJ-92; Fri, 08 Mar 2024 12:07:04 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riZ0B-0006hR-SV; Fri, 08 Mar 2024 12:07:03 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1riZ0B-00025V-Rx; Fri, 08 Mar 2024 12:07:03 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=vMHpJtl6OW1ECN5jtiaHiwldid4uSDDTfKFb+HAEKW4=; b=sPWXC2KCsw0NLit9arToPylbUm PU/3nwUI0DECoSY+Mq+StKj24oZkNZXPRi2c3E5ZKAQKqHjskHlHBNMHmAEFowDYIJvFLGmgbSwYV vWwFLreUKAVAUxVNUOHvbZHg9X/7S9FaoARrVZbkyWLP7lpy6au1PddXiFcp0qcYr1Bc=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [ovmf test] 184943: all pass - PUSHED X-Osstest-Versions-This: ovmf=ccf91b518f22102d446f26320110d30ea0fc1fa9 X-Osstest-Versions-That: ovmf=e60529df58e43f4d1652f862c6652b61f21e0691 From: osstest service owner Date: Fri, 08 Mar 2024 12:07:03 +0000 flight 184943 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/184943/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf ccf91b518f22102d446f26320110d30ea0fc1fa9 baseline version: ovmf e60529df58e43f4d1652f862c6652b61f21e0691 Last test of basis 184916 2024-03-06 03:43:04 Z 2 days Testing same since 184943 2024-03-08 09:11:25 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Gerd Hoffmann Laszlo Ersek 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-pvops pass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git e60529df58..ccf91b518f ccf91b518f22102d446f26320110d30ea0fc1fa9 -> xen-tested-master From xen-devel-bounces@lists.xenproject.org Fri Mar 08 12:17:54 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2024 12:17:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690275.1076124 (Exim 4.92) (envelope-from ) id 1riZAZ-0003hA-B1; Fri, 08 Mar 2024 12:17:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690275.1076124; Fri, 08 Mar 2024 12:17:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riZAZ-0003h3-7l; Fri, 08 Mar 2024 12:17:47 +0000 Received: by outflank-mailman (input) for mailman id 690275; Fri, 08 Mar 2024 12:17:46 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riZAY-0003gx-K7 for xen-devel@lists.xenproject.org; Fri, 08 Mar 2024 12:17:46 +0000 Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [2a00:1450:4864:20::529]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id deda2cba-dd45-11ee-afda-a90da7624cb6; Fri, 08 Mar 2024 13:17:45 +0100 (CET) Received: by mail-ed1-x529.google.com with SMTP id 4fb4d7f45d1cf-563cb3ba9daso2271439a12.3 for ; Fri, 08 Mar 2024 04:17:45 -0800 (PST) Received: from [192.168.206.239] ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id i20-20020a170906445400b00a44e3c8423dsm6980537ejp.24.2024.03.08.04.17.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 Mar 2024 04:17:44 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: deda2cba-dd45-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709900265; x=1710505065; darn=lists.xenproject.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=wiotCRCj8UweM4PWlXFTcPM6v+tuqzpfj8w2t1hCxOw=; b=GHj+bsYTgtT7rviNg1FlMog8//W57PvSK2wMtnHRU2m7QKDf2We3ywKb5X7oxKIDuO QsneNWO7tUdqD47uUMgw8glqgBztK5jscfO50dCZJ0t83aEdKD1Cpq3nTy1HpAnAROgs tFWdDBrA975kER6wGNCp00kbDVotUCDb3CY8HuG1g2CkKEtWH370wb6wQEYJuJMm1Vcl XSFomxVhT3azdFI7mvzaaovbI7EWUmcfMId0adMpbec44sPiuKCQV6EuQLYvpx8HLrRU UjHGuaBxNrQi5LDe7eOMHYVd4IID++EUseiLQlHia4Fj90VtkHHFb2BebRfaF1cLKnI5 3Axg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709900265; x=1710505065; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=wiotCRCj8UweM4PWlXFTcPM6v+tuqzpfj8w2t1hCxOw=; b=HSa5erNtgMd0mIMDS1+svA3T7daV7RoHV2BeCkjHarFRI7W5+blbj3wBWyjkf1HmXD cyZC/5JjvWPxM8dvfMsHTZjjOo8DkCMzBRwoX3UDQo55chMIwfbZu1ykvtMnJ1KtNKJL uVwn+ZFjQFa25gfL2vqeQ23pnFnOdfWurqLG0p/sKl8FW1lmRmHFuNcaST00Co2/v4VV yOOnkjXy/skrG7/uvCDHk/FhPCY4HKBCnmYpcl3z/6SQilhFRJfg9J5hs431fgFvxtQw qBCeB1jTMeLva8va+v7IqQDjanfl7Mc3Py8PSXRldnaFcicaSO4wEqcuhx+BmVALPVLb 3smg== X-Forwarded-Encrypted: i=1; AJvYcCUOfBgswH4kerKiwz4jpI3/JG6jy8q1IdAOeSf4s0qnjCNay0wGEgDedoPGteSQB0UNa9brdBbZQvTD4ITcECmsCdpmyYXfaEHQmGKEyGY= X-Gm-Message-State: AOJu0YzEpIbFGLTOXe1XqFvUQAFQC8bUN1ooLe0Zv365Eph+ZdeSQrfi S+QMDA0eWXJvELRUEDxUXq++3fOAxc01TFnQzlzWs/u1LB2Euvv6 X-Google-Smtp-Source: AGHT+IE/6gUmlk+T09zXf4+7mjCyI9x0mdCe75XjPcdm6HgbO1FV28YxVk+Y42PNXcg6/RpMvwLJ2w== X-Received: by 2002:a17:907:c283:b0:a45:f24a:7dfb with SMTP id tk3-20020a170907c28300b00a45f24a7dfbmr1055696ejc.60.1709900265012; Fri, 08 Mar 2024 04:17:45 -0800 (PST) Message-ID: Subject: Re: [PATCH v5 12/23] xen/riscv: introduce io.h From: Oleksii To: Jan Beulich Cc: Alistair Francis , Bob Eshleman , Connor Davis , Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu , xen-devel@lists.xenproject.org Date: Fri, 08 Mar 2024 13:17:43 +0100 In-Reply-To: References: <807c31d5-0c5a-4646-ba90-2f284289069f@suse.com> <2a3e49bf94332c17b50e4f0f745e4b28b16dceb1.camel@gmail.com> <2a05c233-b3c5-417c-bd6b-8b1c21f03c3d@suse.com> <9ec718f3bba178d437035add3c7467011fc3ffc0.camel@gmail.com> <82375df2-f7fd-43a1-9183-f4823fe791ec@suse.com> <4b6c9458efc85a57c14c6b6147d47245fece1f88.camel@gmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.50.2 (3.50.2-1.fc39) MIME-Version: 1.0 On Fri, 2024-03-08 at 12:52 +0100, Jan Beulich wrote: > On 08.03.2024 12:49, Jan Beulich wrote: > > On 08.03.2024 11:14, Oleksii wrote: > > > On Fri, 2024-03-08 at 08:26 +0100, Jan Beulich wrote: > > > > On 07.03.2024 21:54, Oleksii wrote: > > > > > On Thu, 2024-03-07 at 21:49 +0100, Oleksii wrote: > > > > > > On Thu, 2024-03-07 at 18:14 +0100, Jan Beulich wrote: > > > > > > > For plain writes it should at least be "=3DQo" then, yes. > > > > > > Constraints Q is a machine specific constraint, and I am > > > > > > not sure > > > > > > that > > > > > > it makes sense to use "=3Do" only and probably it is a reason > > > > > > why > > > > > > it is > > > > > > enough only "r". Does it make sense? > > > > > Probably for RISC-V can be used: > > > > > RISC-V=E2=80=94config/riscv/constraints.md > > > > > =C2=A0=C2=A0 ... > > > > > =C2=A0=C2=A0 A > > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 An address that is held in a= general-purpose register. > > > > > =C2=A0=C2=A0 ... > > > >=20 > > > > Just from the description I would have said no, but looking at > > > > what > > > > "A" > > > > actually expands to it is indeed RISC-V's counterpart of Arm's > > > > "Q". > > > > So > > > > yes, this looks like what amo* want to use, and then as a real > > > > operand, > > > > not just a fake one. > > > I am not sure that I know how to check correctly how "A" expands, > > > but I > > > tried to look at code which will be generated with and without > > > constraints and it is the same: > >=20 > > As expected. But if it is epxected and generated code is the same, do we really need constraints then? > >=20 > > > =C2=A0=C2=A0 // static inline void __raw_writel(uint32_t val, volatil= e void > > > =C2=A0=C2=A0 __iomem *addr) > > > =C2=A0=C2=A0 // { > > > =C2=A0=C2=A0 //=C2=A0=C2=A0=C2=A0=C2=A0 asm volatile ( "sw %0, 0(%1)"= : : "r" (val), "r"(addr) > > > ); > > > =C2=A0=C2=A0 // } > > > =C2=A0=C2=A0=20 > > > =C2=A0=C2=A0 static inline void __raw_writel(uint32_t val, volatile v= oid > > > __iomem > > > =C2=A0=C2=A0 *addr) > > > =C2=A0=C2=A0 { > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 asm volatile ( "sw %0, %1" : : "= r" (val), "Ao" (*(volatile > > > =C2=A0=C2=A0 uint32_t __force *)addr) ); > >=20 > > You want just "A" here though; adding an offset (as "o" permits) > > would > > yield an insn which the assembler would reject. >=20 > Wait - this is plain SW, so can't it even be the more generic "m" > then? > (As said, I'm uncertain about "o"; in general I think it's risky to > use.) What do you mean by "plain SW"? Are you suggesting changing 'm' to 'o' so that the final result will be "Am"? Based on the descriptions of 'A' and 'm', it seems to me that we can just use 'A' alone because both constraints indicate that the operand is in memory, and 'A' specifically denotes that an address is held in a register. >=20 >=20 > > Also just to remind > > you: In write functions you need "=3DA" (and in amo ones "+A"), i.e. > > the > > memory operand then needs to be an output, not an input. Could you please clarify about which one amo you are speaking? That one who are defined by ATOMIC_OP and ATOMIC_FETCH_OP? They are already using +A constraints: __asm__ __volatile__ ( \ " amo" #asm_op "." #asm_type " %1, %2, %0" \ : "+A" (v->counter), "=3Dr" (ret) \ : "r" (I) \ : "memory" ); \ ~ Oleksii From xen-devel-bounces@lists.xenproject.org Fri Mar 08 12:50:57 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2024 12:50:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690281.1076136 (Exim 4.92) (envelope-from ) id 1riZgQ-0002Bo-RE; Fri, 08 Mar 2024 12:50:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690281.1076136; Fri, 08 Mar 2024 12:50:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riZgQ-0002Bh-N9; Fri, 08 Mar 2024 12:50:42 +0000 Received: by outflank-mailman (input) for mailman id 690281; Fri, 08 Mar 2024 12:50:42 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riZgQ-0002Bb-7t for xen-devel@lists.xenproject.org; Fri, 08 Mar 2024 12:50:42 +0000 Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [2a00:1450:4864:20::530]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 7806bd19-dd4a-11ee-afda-a90da7624cb6; Fri, 08 Mar 2024 13:50:40 +0100 (CET) Received: by mail-ed1-x530.google.com with SMTP id 4fb4d7f45d1cf-565b434f90aso2547308a12.3 for ; Fri, 08 Mar 2024 04:50:40 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id b20-20020a0564021f1400b00567fa27e75fsm2482656edb.32.2024.03.08.04.50.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 08 Mar 2024 04:50:39 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 7806bd19-dd4a-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709902240; x=1710507040; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=duzkN5rCJViDoOmFyMREhl5qpHFckjUcy257VC1+gdc=; b=LpV9RuAYEnYAx5yzI5MUFTCRFN9b3p39hQjbWtEenWmSMlbdr1+2rgreawFQ0A3rw4 CzAsVCd1+YAgdH/+k27QyHXZNgEsMWq9JRSli3VEmDnE+Fs7BdWV4x7VLIqrCoKJTsNP T2/0FDeathBVFmYq6Bv30IiGEJL5C27RFm4MIYQouY8bMRIOHjARgHoaZJq/MjbpgEMd 4zG4eahpuh5OqJskNmENRlLk8T5hYzrorwgXRreWOj3Xd60sF0VIqrVFP5B/AE5mnkRk dReUhVRGwjUFoOIBLznd6Ev8ikfcUTECt6kPWq+SrrdupJKbxRCnwcOQoElNEVA4+Z07 QEag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709902240; x=1710507040; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=duzkN5rCJViDoOmFyMREhl5qpHFckjUcy257VC1+gdc=; b=LRSQ+SIuGI3qCv26tdE9M48YBYL8TCCsm7l6DmlgoTXExhvKS9dUMM6qzR4+L9KwsM 7ZLt4tOcxMObs6LW3QPQCI/xIlrJQEJoRlxXCyminULgw8DAhxO1ak1LJzl90IVOHa9x gf/RYUVCcWgY1RzqXo78OEaYI7pQ5UycSfGYmFMYPHs7HEXJ43yyF+tciLev9g6WYzsc Axz09Z/qGRSEFCn6DLkNpar8qvmBWiRUWwjqiaRZ63KP1dgWoySx8esAs/uHW9dLF9Dx Bxb4/SeYXgDTh1NVzBpHZ4Yy3dSci4PJdLHNWj2unwFUFeYPANqkQXgVM10I/EjcoscN p8xg== X-Forwarded-Encrypted: i=1; AJvYcCVKF/khoKRvUkT+r/RjHyH0JiiwlmdPaOHGgpg1mMPBXTekvb89a65sMTV2Y581tmeGJWqfVrcrRpzvDGWOBQwZTc0DB87nb41q16WUKRM= X-Gm-Message-State: AOJu0Yxb+qi/RKlZs+xpnV6qalv+l755kkZDZIZrJFPsUre9F2iWrCst qLPWiqz1QdyKg+eIvJafxD/NZVDKlPbX0PAZWJV2/Q+04xtVgif7WnjtvkAN6w== X-Google-Smtp-Source: AGHT+IE92XOU3yNL3vBUbUHGVVXTypYopKNsx/UVaHJT57kpGrMFzqZwYBIwQEvzz0nr4LscsiuXfA== X-Received: by 2002:a50:8e1e:0:b0:566:9437:c89c with SMTP id 30-20020a508e1e000000b005669437c89cmr1937406edw.22.1709902240089; Fri, 08 Mar 2024 04:50:40 -0800 (PST) Message-ID: <45f82faf-cd70-4da8-bcbf-cffde6ab9d93@suse.com> Date: Fri, 8 Mar 2024 13:50:38 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] move __read_mostly to xen/cache.h Content-Language: en-US To: Oleksii Cc: George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Bertrand Marquis , Volodymyr Babchuk , Shawn Anastasio , "xen-devel@lists.xenproject.org" , Andrew Cooper References: <893a5ebf-54e2-f2b2-1365-2a6d36ed3a39@suse.com> <64466285-35b8-497c-a12b-60fe0c998ba6@suse.com> <4343336e663ec5de6c8f322485fb65032a7c0585.camel@gmail.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <4343336e663ec5de6c8f322485fb65032a7c0585.camel@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 08.03.2024 13:01, Oleksii wrote: > On Fri, 2024-03-08 at 09:22 +0100, Jan Beulich wrote: >> On 07.03.2024 18:08, Oleksii wrote: >>> On Fri, 2023-12-22 at 12:09 +0100, Jan Beulich wrote: >>>> On 22.12.2023 10:39, Oleksii wrote: >>>>> On Tue, 2023-08-08 at 12:32 +0200, Jan Beulich wrote: >>>>>> On 08.08.2023 12:18, Andrew Cooper wrote: >>>>>>> On 08/08/2023 10:46 am, Jan Beulich wrote: >>>>>>>> There's no need for every arch to define its own >>>>>>>> identical >>>>>>>> copy. >>>>>>>> If down >>>>>>>> the road an arch needs to customize it, we can add >>>>>>>> #ifndef >>>>>>>> around >>>>>>>> the >>>>>>>> common #define. >>>>>>>> >>>>>>>> To be on the safe side build-breakage-wise, change a >>>>>>>> couple >>>>>>>> of >>>>>>>> #include >>>>>>>> to the xen/ equivalent. >>>>>>>> >>>>>>>> Signed-off-by: Jan Beulich >>>>>>> >>>>>>> Could we find a better place to put this? >>>>>>> >>>>>>> __read_mostly is just a section.  It's relationship to the >>>>>>> cache is >>>>>>> only >>>>>>> microarchitectural, and is not the same kind of information >>>>>>> as >>>>>>> the >>>>>>> rest >>>>>>> of cache.h >>>>>>> >>>>>>> __ro_after_init is only here because __read_mostly is here, >>>>>>> but >>>>>>> has >>>>>>> absolutely nothing to do with caches whatsoever. >>>>>>> >>>>>>> If we're cleaning them up, they ought to live elsewhere. >>>>>> >>>>>> I would be considering init.h (for having most other >>>>>> __section() >>>>>> uses, >>>>>> and for also needing __read_mostly), but that's not a great >>>>>> place >>>>>> to >>>>>> put these either. In fact I see less connection there than >>>>>> for >>>>>> cache.h. >>>>>> So the primary need is a good suggestion (I'm hesitant to >>>>>> suggest >>>>>> to >>>>>> introduce section.h just for this). >>>>> Andrew sent some suggestions here: >>>>> https://lore.kernel.org/xen-devel/3df1dad8-3476-458f-9022-160e0af57d39@citrix.com/ >>>>> >>>>> Will that work for you? >>>> >>>> I still need to properly look at the suggested options. >>> Have you had a chance to review the suggested options? >> >> I'm sure you've seen >> >> https://lists.xen.org/archives/html/xen-devel/2024-01/msg00145.html >> >> To add to that - xen/linkage.h is for assembly code only right now. >> While >> I'd be happy to add C stuff there, there's an (imo) obvious issue >> with >> code churn then: All C files using __read_mostly would then need to >> be >> changed to include xen/linkage.h. And no, I don't view including the >> file >> once in a "central" other header file as a viable solution: That's >> where >> some of our really bad header dependency issues come from. Plus a >> goal >> ought to be (imo) that touching a header like this one would better >> not >> result in a full re-build of everything, when doing incremental >> builds. >> >> Same obviously goes for the case of introducing xen/sections.h, i.e. >> the >> other proposed alternative. >> >> Bottom line: Given the state of our tree, I still view my proposed >> placement as the least bad one for the time being. To change my view, >> I'd still expect a _viable_ alternative proposal to be made. > Based on your replies, I can conclude that there is no good place for > __read_mostly and __ro_after_init. No, no, I'd be happy with xen/linkage.h, if there wasn't the need to then add perhaps many dozens of #include-s throughout the tree. > Not related to my words above, here is a little remark about the patch > changes. Does it make sense to wrap the definition of __read_mostly() > by "#ifndef __read_mostly" in case architecture decides to redefine it? I'd say not ahead of there actually arising such a need. Jan From xen-devel-bounces@lists.xenproject.org Fri Mar 08 12:54:36 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2024 12:54:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690284.1076144 (Exim 4.92) (envelope-from ) id 1riZkB-0002os-D4; Fri, 08 Mar 2024 12:54:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690284.1076144; Fri, 08 Mar 2024 12:54:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riZkB-0002ol-9p; Fri, 08 Mar 2024 12:54:35 +0000 Received: by outflank-mailman (input) for mailman id 690284; Fri, 08 Mar 2024 12:54:34 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riZkA-0002of-Ac for xen-devel@lists.xenproject.org; Fri, 08 Mar 2024 12:54:34 +0000 Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [2a00:1450:4864:20::533]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 01c6a1c9-dd4b-11ee-a1ee-f123f15fe8a2; Fri, 08 Mar 2024 13:54:31 +0100 (CET) Received: by mail-ed1-x533.google.com with SMTP id 4fb4d7f45d1cf-5682e8f21a7so742765a12.3 for ; Fri, 08 Mar 2024 04:54:32 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ij26-20020a056402159a00b00562d908daf4sm9055092edb.84.2024.03.08.04.54.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 08 Mar 2024 04:54:31 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 01c6a1c9-dd4b-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709902471; x=1710507271; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=oF2pgstCBNsuBk6SDQqwKrHQIG36P3mhLVhxcYSQ1vw=; b=UbZv6BNBzAm2d9uJskQpJL9PHjZt3oBSgctezLZ+HtJcfI9fLmsmN2XlDStTW/durv +l5Gm81jt3UkgdZCrVkt2OUFgjxUcIUaa2iZG5DPzWiz/e9oaFp+SiLnKLyd65JWsmlK KW6P3uSyYvK+A9Xmjw1zctmej5hQhEZXwS+LoGhKOb7kkHKWbj8e1Gz9H7nQ/Zdow9kN Sy1/EWHQxW7QBrdN+KpgwmhyhbxQ65paNxpdCAmPt/Fje9Zed5Pgsv50f89lcKloDxCY AzAU93JzW5BxbfyMsGHnY46qI7cuuzi4Deb1CWwjHg3rWrp1hSMLecMwXgO1jKPrrlUz IVGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709902471; x=1710507271; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=oF2pgstCBNsuBk6SDQqwKrHQIG36P3mhLVhxcYSQ1vw=; b=RL3mCysssTcMOeJJNQLN9XgbQYkUc3HJA8fg4GeF02xCHapmmSNbtANaQ7L6e27rxR CxWiRrFYDf9RYlNC/Fk//g6EAecFuGhB40MTXIHqoJkVMEPNpFtFHeNAK0S694JrHfIt dhzxvlu0JCEzTDjsgLEnVvQHlVqlhYreEu0UrFgHUymmvYeVbxZXosZvRCBJdPMRyv3e /4cljR0li6VwFsRQPVjOXd7LZP+M5pyScDJdo2hR6PE7O7bsxoi6xjIl8bPyT2sKIuyC 9ErbAcSlEMqpwpie5fQq/3nuEiLMmFJmG8OdWbYN0O3FQELddfMM60aLTEgGxfSWNb5W 776w== X-Forwarded-Encrypted: i=1; AJvYcCUdTQtEeguK1tJFY1N2HvpOoCWbBEIcXS2kmNDVFYt2FAh3lwlWvFpbgKzv0jgEgawZ3I6J0Z6TxCiEWd29hN3iK44sYZ0ewZTGcLmnTss= X-Gm-Message-State: AOJu0Yzyrni5UIXU7lPxA/840bhv/qUmOfOkXgXqcZLJtRp6jbxMi4lU 8QnJlMR33S8ie4xXAkPN9FsbaZyq9cA2AenDepgSulAqqB1KCLfaWWzs5bfJTw== X-Google-Smtp-Source: AGHT+IHAwtdkWBmrPa9MjRRgw97aJwcpZ6/9VE3SZ2VvEiPLiBC5Mwd2A0Jej/wizOW+RyWv3CLBZA== X-Received: by 2002:a50:8e4f:0:b0:568:b18:ee19 with SMTP id 15-20020a508e4f000000b005680b18ee19mr1963243edx.16.1709902471517; Fri, 08 Mar 2024 04:54:31 -0800 (PST) Message-ID: Date: Fri, 8 Mar 2024 13:54:29 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 12/23] xen/riscv: introduce io.h Content-Language: en-US To: Oleksii Cc: Alistair Francis , Bob Eshleman , Connor Davis , Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu , xen-devel@lists.xenproject.org References: <807c31d5-0c5a-4646-ba90-2f284289069f@suse.com> <2a3e49bf94332c17b50e4f0f745e4b28b16dceb1.camel@gmail.com> <2a05c233-b3c5-417c-bd6b-8b1c21f03c3d@suse.com> <9ec718f3bba178d437035add3c7467011fc3ffc0.camel@gmail.com> <82375df2-f7fd-43a1-9183-f4823fe791ec@suse.com> <4b6c9458efc85a57c14c6b6147d47245fece1f88.camel@gmail.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 08.03.2024 13:17, Oleksii wrote: > On Fri, 2024-03-08 at 12:52 +0100, Jan Beulich wrote: >> On 08.03.2024 12:49, Jan Beulich wrote: >>> On 08.03.2024 11:14, Oleksii wrote: >>>> On Fri, 2024-03-08 at 08:26 +0100, Jan Beulich wrote: >>>>> On 07.03.2024 21:54, Oleksii wrote: >>>>>> On Thu, 2024-03-07 at 21:49 +0100, Oleksii wrote: >>>>>>> On Thu, 2024-03-07 at 18:14 +0100, Jan Beulich wrote: >>>>>>>> For plain writes it should at least be "=Qo" then, yes. >>>>>>> Constraints Q is a machine specific constraint, and I am >>>>>>> not sure >>>>>>> that >>>>>>> it makes sense to use "=o" only and probably it is a reason >>>>>>> why >>>>>>> it is >>>>>>> enough only "r". Does it make sense? >>>>>> Probably for RISC-V can be used: >>>>>> RISC-V—config/riscv/constraints.md >>>>>>    ... >>>>>>    A >>>>>>        An address that is held in a general-purpose register. >>>>>>    ... >>>>> >>>>> Just from the description I would have said no, but looking at >>>>> what >>>>> "A" >>>>> actually expands to it is indeed RISC-V's counterpart of Arm's >>>>> "Q". >>>>> So >>>>> yes, this looks like what amo* want to use, and then as a real >>>>> operand, >>>>> not just a fake one. >>>> I am not sure that I know how to check correctly how "A" expands, >>>> but I >>>> tried to look at code which will be generated with and without >>>> constraints and it is the same: >>> >>> As expected. > But if it is epxected and generated code is the same, do we really need > constraints then? Yes. Again: Proper constraints are the only way for the compiler to know everything it needs to know to generate correct code around an asm(). >>>>    // static inline void __raw_writel(uint32_t val, volatile void >>>>    __iomem *addr) >>>>    // { >>>>    //     asm volatile ( "sw %0, 0(%1)" : : "r" (val), "r"(addr) >>>> ); >>>>    // } >>>>    >>>>    static inline void __raw_writel(uint32_t val, volatile void >>>> __iomem >>>>    *addr) >>>>    { >>>>        asm volatile ( "sw %0, %1" : : "r" (val), "Ao" (*(volatile >>>>    uint32_t __force *)addr) ); >>> >>> You want just "A" here though; adding an offset (as "o" permits) >>> would >>> yield an insn which the assembler would reject. >> >> Wait - this is plain SW, so can't it even be the more generic "m" >> then? >> (As said, I'm uncertain about "o"; in general I think it's risky to >> use.) > What do you mean by "plain SW"? The plain store instruction, i.e. not SC. That one permits wider addressing modes iirc, which we ought to permit where possible. > Are you suggesting changing 'm' to 'o' so that the final result will be > "Am"? Based on the descriptions of 'A' and 'm', it seems to me that we > can just use 'A' alone because both constraints indicate that the > operand is in memory, and 'A' specifically denotes that an address is > held in a register. No, no "A" at all. Just "m", which is a superset of "A" anyway. >>> Also just to remind >>> you: In write functions you need "=A" (and in amo ones "+A"), i.e. >>> the >>> memory operand then needs to be an output, not an input. > Could you please clarify about which one amo you are speaking? That one > who are defined by ATOMIC_OP and ATOMIC_FETCH_OP? All. They're all read-modify-write operations if I'm not mistaken. > They are already > using +A constraints: > __asm__ __volatile__ ( \ > " amo" #asm_op "." #asm_type " %1, %2, %0" \ > : "+A" (v->counter), "=r" (ret) \ > : "r" (I) \ > : "memory" ); \ Good. I merely thought I'd mention that aspect for completeness. Jan From xen-devel-bounces@lists.xenproject.org Fri Mar 08 13:41:03 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2024 13:41:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690297.1076154 (Exim 4.92) (envelope-from ) id 1riaSu-0003Xu-Mt; Fri, 08 Mar 2024 13:40:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690297.1076154; Fri, 08 Mar 2024 13:40:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riaSu-0003Xm-KP; Fri, 08 Mar 2024 13:40:48 +0000 Received: by outflank-mailman (input) for mailman id 690297; Fri, 08 Mar 2024 13:40:47 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riaSt-0003Xb-2v for xen-devel@lists.xenproject.org; Fri, 08 Mar 2024 13:40:47 +0000 Received: from mail.actia.se (mail.actia.se [212.181.117.226]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 7681c0c7-dd51-11ee-a1ee-f123f15fe8a2; Fri, 08 Mar 2024 14:40:44 +0100 (CET) Received: from S036ANL.actianordic.se (10.12.31.117) by S036ANL.actianordic.se (10.12.31.117) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Fri, 8 Mar 2024 14:40:44 +0100 Received: from S036ANL.actianordic.se ([fe80::e13e:1feb:4ea6:ec69]) by S036ANL.actianordic.se ([fe80::e13e:1feb:4ea6:ec69%4]) with mapi id 15.01.2507.035; Fri, 8 Mar 2024 14:40:44 +0100 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 7681c0c7-dd51-11ee-a1ee-f123f15fe8a2 From: John Ernberg To: Julien Grall , Peng Fan , "Stefano Stabellini" , Bertrand Marquis , Michal Orzel , "Volodymyr Babchuk" CC: Jonas Blixt , "xen-devel@lists.xenproject.org" Subject: Re: [PATCH 1/2] xen/arm: Add imx8q{m,x} platform glue Thread-Topic: [PATCH 1/2] xen/arm: Add imx8q{m,x} platform glue Thread-Index: AQHaVDuqVQ/kgxLZgUK/m8/hE0ez5bDzxxsAgAA1KwCAAVx5AIAAQjeAgAEdtQCAAyp5AIABm3uAgAZ8E4CAKNxDgIAApfwAgAKGQoA= Date: Fri, 8 Mar 2024 13:40:44 +0000 Message-ID: <848794f3-a337-49d9-84db-a969970f071b@actia.se> References: <20240131114952.305805-1-john.ernberg@actia.se> <20240131114952.305805-2-john.ernberg@actia.se> <494d4961-ad8a-4d1d-aaa6-d1bfb9d6a137@actia.se> <167f0c7a-e037-446c-82f8-2584e35a7af1@xen.org> <012b5f83-2f9b-4477-965e-07b8506c0052@xen.org> <5a0c8f09-4f01-45e9-892c-86342c0d0ec5@xen.org> <08ae764c-3490-4dd1-ab70-7a855a98d16d@actia.se> <911ec1bb-3733-4f37-839e-673a88e408ff@actia.se> In-Reply-To: Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.12.12.30] x-esetresult: clean, is OK x-esetid: 37303A2958D72955627366 Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 SGkgSnVsaWVuLA0KDQpPbiAzLzcvMjQgMDA6MDcsIEp1bGllbiBHcmFsbCB3cm90ZToNCj4gSGkg Sm9obiwNCj4gDQo+ICA+IFBpbmcgb24gdGhlIHdhdGNoZG9nIGRpc2N1c3Npb24gYml0cy4NCj4g DQo+IFNvcnJ5IGZvciB0aGUgbGF0ZSByZXBseS4NCj4gDQo+IE9uIDA2LzAzLzIwMjQgMTM6MTMs IEpvaG4gRXJuYmVyZyB3cm90ZToNCj4+IE9uIDIvOS8yNCAxNDoxNCwgSm9obiBFcm5iZXJnIHdy b3RlOg0KPj4+DQo+Pj4+IMKgwqDCoCAqIElNWF9TSVBfVElNRVJfKjrCoCBUaGlzIHNlZW1zIHRv IGJlIHJlbGF0ZWQgdG8gdGhlIHdhdGNoZG9nLg0KPj4+PiBTaG91bGRuJ3QgZG9tMCByZWx5IG9u IHRoZSB3YXRjaGRvZyBwcm92aWRlZCBieSBYZW4gaW5zdGVhZD8gU28gdGhvc2UNCj4+Pj4gY2Fs bCB3aWxsIGJlIHVzZWQgYnkgWGVuLg0KPj4+DQo+Pj4gVGhhdCBpcyBpbmRlZWQgYSB3YXRjaGRv ZyBTSVAsIGFuZCBhbHNvIGZvciBzZXR0aW5nIHRoZSBTb0MgaW50ZXJuYWwgUlRDDQo+Pj4gaWYg aXQgaXMgYmVpbmcgdXNlZC4NCj4+Pg0KPj4+IEkgbG9va2VkIGFyb3VuZCBpZiB0aGVyZSB3YXMg cHJldmlvdXMgZGlzY3Vzc2lvbiBhbmQgb25seSByZWFsbHkgDQo+Pj4gZm91bmQgWzNdLg0KPj4+ IElzIHRoZSB4ZW4veGVuL2luY2x1ZGUvd2F0Y2hkb2cuaCBoZWFkZXIgbWVhbnQgdG8gYmUgZm9y IHRoaXMga2luZCBvZg0KPj4+IHdhdGNoZG9nIHN1cHBvcnQgb3IgaXMgdGhhdCBtb3JlIGZvciB0 aGUgVk0gd2F0Y2hkb2c/IExvb2tpbmcgYXQgdGhlIHg4Ng0KPj4+IEFDUEkgTk1JIHdhdGNoZG9n IGl0IHNlZW1zIGxpa2UgdGhlIGZvcm1lciwgYnV0IEkgaGF2ZSBuZXZlciB3b3JrZWQgd2l0aA0K Pj4+IHg4NiBub3IgQUNQSS4NCj4gDQo+IGluY2x1ZGUvd2F0Y2hkb2cuaCBjb250YWlucyBoZWxw ZXIgdG8gY29uZmlndXJlIHRoZSB3YXRjaGRvZyBmb3IgWGVuLiBXZSANCj4gYWxzbyBoYXZlIHBl ci1WTSB3YXRjaGRvZyBhbmQgdGhpcyBpcyBjb25maWd1cmVkIGJ5IHRoZSBoeXBlcmNhbGwgDQo+ IFNDSEVET1Bfd2F0Y2hkb2cuDQo+IA0KPj4+DQo+Pj4gQ3VycmVudGx5IGZvcndhcmRpbmcgaXQg dG8gRG9tMCBoYXMgbm90IGNhdXNlZCBhbnkgd2F0Y2hkb2cgcmVzZXRzIHdpdGgNCj4+PiBvdXIg d2F0Y2hkb2cgdGltZW91dCBzZXR0aW5ncywgb3VyIHNwZWNpZmljIERvbTAgc2V0dXAgYW5kIFZN IGNvdW50Lg0KPiANCj4gSUlVQywgdGhlIFNNQyBBUEkgZm9yIHRoZSB3YXRjaGRvZyB3b3VsZCBi ZSBzaW1pbGFyIHRvIHRoZSBBQ1BJIE5NSSANCj4gd2F0Y2hkb2cuIFNvIEkgdGhpbmsgaXQgd291 bGQgbWFrZSBtb3JlIHNlbnNlIGlmIHRoaXMgaXMgbm90IGV4cG9zZWQgdG8gDQo+IGRvbTAgKGV2 ZW4gaWYgWGVuIGlzIGRvaW5nIG5vdGhpbmcgd2l0aCBpdCkuDQo+IA0KPiBDYW4geW91IHRyeSB0 byBoaWRlIHRoZSBTTUNzIGFuZCBjaGVjayBpZiBkb20wIHN0aWxsIGJlaGF2ZSBwcm9wZXJseT8N Cj4gDQo+IENoZWVycywNCj4gDQoNClRoaXMgU01DIG1hbmFnZXMgYSBoYXJkd2FyZSB3YXRjaGRv ZywgaWYgaXQncyBub3QgcGluZ2VkIHdpdGhpbiBhIA0Kc3BlY2lmaWMgaW50ZXJ2YWwgdGhlIGVu dGlyZSBib2FyZCByZXNldHMuDQoNCklmIEkgYmxvY2sgdGhlIFNNQ3MgdGhlIHdhdGNoZG9nIGRy aXZlciBpbiBEb20wIHdpbGwgZmFpbCB0byBwaW5nIHRoZSANCndhdGNoZG9nLCB0cmlnZ2VyaW5n IGEgYm9hcmQgcmVzZXQgYmVjYXVzZSB0aGUgc3lzdGVtIGxvb2tzIHRvIGhhdmUgDQpiZWNvbWUg dW5yZXNwb25zaXZlLiBUaGUgcmVhc29uIHRoaXMgcGF0Y2ggc2V0IHN0YXJ0ZWQgaXMgYmVjYXVz ZSB3ZSANCmNvdWxkbid0IHBpbmcgdGhlIHdhdGNoZG9nIHdoZW4gcnVubmluZyB3aXRoIFhlbi4N Cg0KSW4gb3VyIHNwZWNpZmljIHN5c3RlbSB0aGUgYm9vdGxvYWRlciBlbmFibGVzIHRoZSB3YXRj aGRvZyBhcyBlYXJseSBhcyANCnBvc3NpYmxlIHNvIHRoYXQgd2UgY2FuIGdldCB3YXRjaGRvZyBw cm90ZWN0aW9uIGZvciBhcyBtdWNoIG9mIHRoZSBib290IA0KYXMgd2UgcG9zc2libHkgY2FuLg0K DQpTbywgaWYgd2UgYXJlIHRvIGJsb2NrIHRoZSBTTUMgZnJvbSBEb20wLCB0aGVuIFhlbiBuZWVk cyB0byB0YWtlIG92ZXIgDQp0aGUgcGluZ2luZy4gSXQgY291bGQgYmUgaW1wbGVtZW50ZWQgc2lt aWxhcmx5IHRvIHRoZSBOTUkgd2F0Y2hkb2csIA0KZXhjZXB0IHRoYXQgdGhlIHN5c3RlbSB3aWxs IHJlc2V0IGlmIHRoZSBwaW5nIGlzIG1pc3NlZCByYXRoZXIgdGhhbiANCmJhY2t0cmFjZS4NCkl0 IHdvdWxkIGFsc28gbWVhbiB0aGF0IFhlbiB3aWxsIGdldCBhIHdob2xlIHdhdGNoZG9nIGRyaXZl ci1jYXRlZ29yeSANCmR1ZSB0byB0aGUgd2F0Y2hkb2cgYmVpbmcgdmVuZG9yIGFuZCBzb21ldGlt ZXMgZXZlbiBTb0Mgc3BlY2lmaWMgd2hlbiBpdCANCmNvbWVzIHRvIEFybS4NCg0KTXkgdW5kZXJz dGFuZGluZyBvZiB0aGUgZG9tYWluIHdhdGNoZG9nIGNvZGUgaXMgdGhhdCB0b2RheSB0aGUgZG9t YWluIA0KbmVlZHMgdG8gY2FsbCBTQ0hFRE9QX3dhdGNoZG9nIGF0IGxlYXN0IG9uY2UgdG8gc3Rh cnQgdGhlIHdhdGNoZG9nIA0KdGltZXIuIFNpbmNlIHdhdGNoZG9nIHByb3RlY3Rpb24gdGhyb3Vn aCB0aGUgd2hvbGUgYm9vdCBwcm9jZXNzIGlzIA0KZGVzaXJhYmxlIHdlJ2QgbmVlZCBzb21lIGNv cmUgY2hhbmdlcywgc3VjaCBhcyBhbiBvcHRpb24gdG8gc3RhcnQgdGhlIA0KZG9tYWluIHdhdGNo ZG9nIG9uIGluaXQuDQoNCkl0J3MgcXVpdGUgYSBiaWcgY2hhbmdlIHRvIG1ha2UsIHdoaWxlIEkg YW0gbm90IGFnYWluc3QgZG9pbmcgaXQgaWYgaXQgDQptYWtlcyBzZW5zZSwgSSBub3cgd29uZGVy IGlmIFhlbiBzaG91bGQgbWFuYWdlIGhhcmR3YXJlIHdhdGNoZG9ncy4NCkxvb2tpbmcgYXQgdGhl IGRvbWFpbiB3YXRjaGRvZyBjb2RlIGl0IGxvb2tzIGxpa2UgaWYgYSBkb21haW4gZG9lcyBub3Qg DQpnZXQgZW5vdWdoIGV4ZWN1dGlvbiB0aW1lLCB0aGUgd2F0Y2hkb2cgd2lsbCBub3QgYmUgcGlu Z2VkIGVub3VnaCBhbmQgDQp0aGUgZ3Vlc3Qgd2lsbCBiZSByZXNldC4gU28gZWl0aGVyIHdhdGNo ZG9nIGFwcHJvYWNoIHJlcXVpcmVzIERvbTAgdG8gDQpnZXQgZXhlY3V0aW9uIHRpbWUuIERvbTAg YWxzbyBuZWVkcyB0byBzZXJ2aWNlIGFsbCB0aGUgUFYgYmFja2VuZHMgaXQncyANCnJlc3BvbnNp YmxlIGZvci4gSSdtIG5vdCBzdXJlIGl0J3MgdmFsdWFibGUgdG8gYWRkIGFub3RoZXIgbGF5ZXIg b2YgDQp3YXRjaGRvZyBmb3IgdGhpcyBzY2VuYXJpbyBhcyB0aGUgZW5kIHJlc3VsdCAoY2hlY2tp bmcgdGhhdCB0aGUgZW50aXJlIA0Kc3lzdGVtIHdvcmtzKSBpcyBhY2hpZXZlZCB3aXRob3V0IGl0 IGFzIHdlbGwuDQoNClNvLCBiZWZvcmUgSSB0cnkgdG8gZmluZCB0aGUgdGltZSB0byBtYWtlIGEg cHJvcG9zYWwgZm9yIG1vdmluZyB0aGUgDQpoYXJkd2FyZSB3YXRjaGRvZyBiaXQgdG8gWGVuLCBk byB3ZSByZWFsbHkgd2FudCBpdD8NCg0KVGhhbmtzISAvLyBKb2huIEVybmJlcmc= From xen-devel-bounces@lists.xenproject.org Fri Mar 08 13:45:39 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2024 13:45:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690299.1076166 (Exim 4.92) (envelope-from ) id 1riaXa-0004Gt-9J; Fri, 08 Mar 2024 13:45:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690299.1076166; Fri, 08 Mar 2024 13:45:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riaXa-0004Gm-5A; Fri, 08 Mar 2024 13:45:38 +0000 Received: by outflank-mailman (input) for mailman id 690299; Fri, 08 Mar 2024 13:45:36 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riaXY-0004Ga-J8; Fri, 08 Mar 2024 13:45:36 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riaXY-0001Qr-GZ; Fri, 08 Mar 2024 13:45:36 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riaXY-0002pc-87; Fri, 08 Mar 2024 13:45:36 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1riaXY-0000Hs-7T; Fri, 08 Mar 2024 13:45:36 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=rRjdG5DXdrDKECr5FltHN8ijTb1iT8BI1va+BiyT/8I=; b=1wJOs/Gelc75n1eTbwAjaZVpfN PE/Mhn5IlfjtUnLGFYIF1IllnvrV2+BGsubi6+AgitAibtfOz74qtF/XQs9NE/gpJVGI9OdsR+sEO lHOu1QBZe/d+1X9U77ZmUBQvpfFW0QW6n73bvS9VMKDrG16DzRPUwJ3su39oeCTB/HhA=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable test] 184940: regressions - FAIL X-Osstest-Failures: xen-unstable:test-amd64-amd64-livepatch:livepatch-run:fail:regression xen-unstable:test-amd64-i386-livepatch:livepatch-run:fail:regression xen-unstable:test-arm64-arm64-xl-credit1:xen-boot:fail:heisenbug xen-unstable:test-amd64-amd64-libvirt-vhd:guest-start:fail:heisenbug xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:windows-install:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: xen=90173fc5a2a826bbcabde22af405d0a617818b70 X-Osstest-Versions-That: xen=66c8e9b76c61ff52cfc0b186a38208907845d093 From: osstest service owner Date: Fri, 08 Mar 2024 13:45:36 +0000 flight 184940 xen-unstable real [real] flight 184945 xen-unstable real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/184940/ http://logs.test-lab.xenproject.org/osstest/logs/184945/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-livepatch 13 livepatch-run fail REGR. vs. 184927 test-amd64-i386-livepatch 13 livepatch-run fail REGR. vs. 184927 Tests which are failing intermittently (not blocking): test-arm64-arm64-xl-credit1 8 xen-boot fail pass in 184945-retest test-amd64-amd64-libvirt-vhd 13 guest-start fail pass in 184945-retest Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-credit1 15 migrate-support-check fail in 184945 never pass test-arm64-arm64-xl-credit1 16 saverestore-support-check fail in 184945 never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-check fail in 184945 never pass test-armhf-armhf-libvirt 16 saverestore-support-check fail like 184927 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop fail like 184927 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 184927 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop fail like 184927 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 184927 test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail like 184927 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 184927 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop fail like 184927 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 184927 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184927 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 184927 test-amd64-amd64-xl-qemuu-win7-amd64 12 windows-install fail like 184927 test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-check fail never pass test-amd64-i386-xl-pvshim 14 guest-start fail never pass test-amd64-i386-libvirt 15 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-check fail never pass test-arm64-arm64-xl 15 migrate-support-check fail never pass test-arm64-arm64-xl 16 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 15 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-check fail never pass test-armhf-armhf-libvirt 15 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-check fail never pass test-amd64-i386-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-check fail never pass test-arm64-arm64-xl-vhd 14 migrate-support-check fail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-check fail never pass version targeted for testing: xen 90173fc5a2a826bbcabde22af405d0a617818b70 baseline version: xen 66c8e9b76c61ff52cfc0b186a38208907845d093 Last test of basis 184927 2024-03-07 00:10:52 Z 1 days Testing same since 184940 2024-03-07 19:47:48 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Anthony PERARD Henry Wang Jan Beulich Juergen Gross Oleksii Kurochko jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-dom0pvh-xl-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-qemuu-freebsd11-amd64 pass test-amd64-amd64-qemuu-freebsd12-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-examine-bios pass test-amd64-i386-examine-bios pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 fail test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-dom0pvh-xl-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch fail test-amd64-i386-livepatch fail test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-armhf-armhf-libvirt-qcow2 pass test-amd64-amd64-xl-qcow2 pass test-arm64-arm64-libvirt-raw pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-libvirt-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-examine-uefi pass test-amd64-i386-examine-uefi pass test-amd64-amd64-libvirt-vhd fail test-arm64-arm64-xl-vhd pass test-armhf-armhf-xl-vhd pass test-amd64-i386-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these 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 90173fc5a2a826bbcabde22af405d0a617818b70 Author: Henry Wang Date: Thu Mar 7 21:56:16 2024 +0800 tools/9pfsd: Fix build error caused by strerror_r Below error can be seen when doing Yocto build of the toolstack: | io.c: In function 'p9_error': | io.c:684:5: error: ignoring return value of 'strerror_r' declared with attribute 'warn_unused_result' [-Werror=unused-result] | 684 | strerror_r(err, ring->buffer, ring->ring_size); | | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | cc1: all warnings being treated as errors Using strerror_r() without special casing different build environments is impossible due to the different return types (int vs char *) depending on the environment. As p9_error() is not on a performance critical path, using strerror() with a mutex ought to be fine. So, fix the build by using strerror() to replace strerror_r(). The steps would then become: Acquire the mutex first, invoke strerror(), copy the string from strerror() to the designated buffer and then drop the mutex. Fixes: f4900d6d69b5 ("9pfsd: allow building with old glibc") Signed-off-by: Henry Wang Reviewed-by: Jan Beulich Reviewed-by: Juergen Gross Acked-by: Anthony PERARD commit b52c45b1bdf04469495dd046ba15dd35a8becfa5 Author: Juergen Gross Date: Wed Mar 6 12:16:31 2024 +0100 MAINTAINERS: add an entry for tools/9pfsd Add me as the maintainer for the tools/9pfsd directory. Signed-off-by: Juergen Gross Reviewed-by: Andrew Cooper commit b083b1c393dc8961acf0959b1d2e0ad459985ae3 Author: Andrew Cooper Date: Tue Mar 5 11:39:19 2024 +0000 x86/livepatch: Relax permissions on rodata too This reinstates the capability to patch .rodata in load/unload hooks, which was lost when we stopped using CR0.WP=0 to patch. This turns out to be rather less of a large TODO than I thought at the time. Fixes: 8676092a0f16 ("x86/livepatch: Fix livepatch application when CET is active") Signed-off-by: Andrew Cooper Reviewed-by: Roger Pau Monné Reviewed-by: Ross Lagerwall commit ef969144a425e39f5b214a875b5713d0ea8575fb Author: Andrew Cooper Date: Tue Mar 5 11:35:12 2024 +0000 xen/virtual-region: Include rodata pointers These are optional. .init doesn't distinguish types of data like this, and livepatches don't necesserily have any .rodata either. No functional change. Signed-off-by: Andrew Cooper Reviewed-by: Roger Pau Monné Reviewed-by: Ross Lagerwall commit 989556c6f8ca080f5f202417af97d1188b9ba52a Author: Andrew Cooper Date: Tue Mar 5 11:28:33 2024 +0000 xen/virtual-region: Rename the start/end fields ... to text_{start,end}. We're about to introduce another start/end pair. Despite it's name, struct virtual_region has always been a module-ish description. Call this out specifically. As minor cleanup, replace ROUNDUP(x, PAGE_SIZE) with the more concise PAGE_ALIGN() ahead of duplicating the example. No functional change. Signed-off-by: Andrew Cooper Reviewed-by: Roger Pau Monné Reviewed-by: Ross Lagerwall commit 08bb338f09a54d3b39f0d952bbd67461d8e5d0ed Author: Juergen Gross Date: Thu Mar 7 09:18:04 2024 +0100 SUPPORT.md: add xen-9pfsd Add a support statement for the new xen-9pfsd backend. Set it to "Experimental", as some functionality for Linux guests is missing (only tested to work with Xenstore-stubdom). Signed-off-by: Juergen Gross Acked-by: Jan Beulich commit 49b664f5bffa3a86734c66491d7dcdebbdecfb26 Author: Jan Beulich Date: Thu Mar 7 09:17:26 2024 +0100 x86/asm: add commas to further macros definitions/invocations In light of recent observations with how macros are handled by gas, let's play by what we informally set for ourselves as a guideline: Use commas to separate parameters/arguments. Requested-by: Andrew Cooper Signed-off-by: Jan Beulich Acked-by: Andrew Cooper commit 4ad4df0964aa374562fa574d4671d278f54f5d32 Author: Juergen Gross Date: Thu Mar 7 09:16:53 2024 +0100 CHANGELOG: add an entry for 9pfsd Add an entry to CHANGELOG.md regarding the new xen-9pfsd daemon. Signed-off-by: Juergen Gross Acked-by: Oleksii Kurochko commit 9249a441c98ff063c0c065538b419a3bf1dac24a Author: Jan Beulich Date: Thu Mar 7 09:16:13 2024 +0100 x86/asm: add commas to BUILD_BUG_ON In light of recent observations with how macros are handled by gas, let's play by what we informally set for ourselves as a guideline: Use commas to separate parameters/arguments. Signed-off-by: Jan Beulich Acked-by: Andrew Cooper commit 5daf46b439454921c19ca30840bb39424b36444b Author: Jan Beulich Date: Thu Mar 7 09:15:17 2024 +0100 Kbuild: simplify as-insn a little As of 732571959f17 ("xen/build: use new $(c_flags) and $(a_flags) instead of $(CFLAGS)") -M options aren't part of CFLAGS anymore, and c_flags isn't supposed to be passed to this macro. Drop the now dead part of filtering. Signed-off-by: Jan Beulich Reviewed-by: Anthony PERARD commit 2f7481d59255680c1de98f43467d3862453dd50a Author: Jan Beulich Date: Thu Mar 7 09:14:55 2024 +0100 x86/EFI: correct compiler probing Passing in $(CFLAGS) means also requesting inclusion of certain headers (via -include command line options). That's particularly xen/config.h, which in turn requires generated/autoconf.h. This has not caused any problems so far only because arch.mk is processed twice, and the missing header on the 1st pass would be there on the 2nd. Having added an inclusion of asm/asm-macros.h to x86'es asm/config.h, the 2nd pass then also fails on an initial, pristine build. As per dd40177c1bc8 ("x86-64/EFI: add CFLAGS to check compile") dropping the use of $(CFLAGS) altogether isn't an option, though. Hence remove the problematic options only. Signed-off-by: Jan Beulich Reviewed-by: Anthony PERARD (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Fri Mar 08 13:56:27 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2024 13:56:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690307.1076174 (Exim 4.92) (envelope-from ) id 1riahr-0006fN-BX; Fri, 08 Mar 2024 13:56:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690307.1076174; Fri, 08 Mar 2024 13:56:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riahr-0006fG-8U; Fri, 08 Mar 2024 13:56:15 +0000 Received: by outflank-mailman (input) for mailman id 690307; Fri, 08 Mar 2024 13:56:13 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riahp-0006f4-Sc for xen-devel@lists.xenproject.org; Fri, 08 Mar 2024 13:56:13 +0000 Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [2a00:1450:4864:20::629]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 9e7ceae1-dd53-11ee-a1ee-f123f15fe8a2; Fri, 08 Mar 2024 14:56:10 +0100 (CET) Received: by mail-ej1-x629.google.com with SMTP id a640c23a62f3a-a45aa7cb2b3so112045966b.3 for ; Fri, 08 Mar 2024 05:56:10 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id qw16-20020a1709066a1000b00a3edb758561sm9273026ejc.129.2024.03.08.05.56.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 08 Mar 2024 05:56:10 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 9e7ceae1-dd53-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1709906170; x=1710510970; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:cc:references :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=LQt+anzuoreJqZXjI7mW21JZ1SpXQKd5IvO+pVvYhDY=; b=fRvrDto7KiQcjCPe5xVC9cGt+TceSPH94gg9EjRHEcSPds20ECRlgCPhBa087d6n8n LhiyJzpg2NKWRWSY4MuuvAQkx3SXnQy35zEAgvUCFBbQ4eW58/PQxoU0Sqpc1/2tNQpr DlkGf9b86x7USHTGNGHcsJO99/G8CQWZ+WN/6ZBDn12sZl8WBZ8crC0R5zjS2/qXUQKs fGGNk7X0sq8lvBKLbQjAIFEyyIbj/7TsYI5IH1/+qxkdGEtOUz0o+Z+dSYi9nrHWnZyW iFFNIJBsC2KvhbiZemsuo57m2aLc2aWYh34IUT8j7CTW75DBxAtQMog/A6Q7Fu5BtDda A7Yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709906170; x=1710510970; h=content-transfer-encoding:in-reply-to:autocrypt:from:cc:references :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=LQt+anzuoreJqZXjI7mW21JZ1SpXQKd5IvO+pVvYhDY=; b=HxDL6wBqYnfXC73r9G6+vgYZxJIdhqnl42D4WdQou9Sxol6tkoUJ8+m6iKSwhW59CZ Jx5mW2hqrHRCEUjvAjsZghI/P0aJ1GUI/Wvb2CSqww5jLHOqASlaHhGwU22QJuQAUeqN pL7vCk/2E+DHsgZPevZJ44G+WZg7OO+3lx3idfF0tT4mDrVfFRF6E4WDiIlLC9Ju8vcJ NYqdQjWfDmsn4YZ4ThQtOm4lN1e0LtvydSS6AFcwZkw30RlpnjZdrwz7hfyWubM+w/Gd kl/i5fPGwQ5B9fEqSjQqJCHWBP1IK58oS5aee8A1LCNRP6qglK1MRW4drovwFFg1nIE0 xs9Q== X-Gm-Message-State: AOJu0YzZNU0/LPJI9BITcIccD9wQqnM0jphrP15hmUElz/sn/+IZzVvx N3riTEqr+JzujZdrPJjWkCskJKAzUA2m2+FEqXfHem3KHPUysjyNAc+khQMIjJimyRlnmIVU/wU = X-Google-Smtp-Source: AGHT+IEzjNbzCNVhFfCokMmXcWTBscTY/w67gEAT41R1RyP8dqF/nyHc+jbdbNCEMjd1vPWrscPXXw== X-Received: by 2002:a17:906:b00c:b0:a44:c1a9:ee37 with SMTP id v12-20020a170906b00c00b00a44c1a9ee37mr13600966ejy.61.1709906170248; Fri, 08 Mar 2024 05:56:10 -0800 (PST) Message-ID: <5c21d349-5021-490f-bc6b-eb5973622688@suse.com> Date: Fri, 8 Mar 2024 14:56:08 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [xen-unstable test] 184940: regressions - FAIL Content-Language: en-US To: xen-devel@lists.xenproject.org References: Cc: osstest service owner From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 08.03.2024 14:45, osstest service owner wrote: > flight 184940 xen-unstable real [real] > flight 184945 xen-unstable real-retest [real] > http://logs.test-lab.xenproject.org/osstest/logs/184940/ > http://logs.test-lab.xenproject.org/osstest/logs/184945/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: > test-amd64-amd64-livepatch 13 livepatch-run fail REGR. vs. 184927 > test-amd64-i386-livepatch 13 livepatch-run fail REGR. vs. 184927 Hmm, both have "(XEN) common/livep" following the shell prompt, i.e. an incomplete hypervisor log message (maybe a failed assertion?), suggesting a triple fault may have occurred. While some livepatch related changes are under test, I can't (for now) connect any of them (or any of the other changes) with such behavior. Jan From xen-devel-bounces@lists.xenproject.org Fri Mar 08 13:59:33 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2024 13:59:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690310.1076185 (Exim 4.92) (envelope-from ) id 1rial1-0007Wb-Os; Fri, 08 Mar 2024 13:59:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690310.1076185; Fri, 08 Mar 2024 13:59:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rial1-0007WB-M8; Fri, 08 Mar 2024 13:59:31 +0000 Received: by outflank-mailman (input) for mailman id 690310; Fri, 08 Mar 2024 13:59:30 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rial0-0007SX-Db for xen-devel@lists.xenproject.org; Fri, 08 Mar 2024 13:59:30 +0000 Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [2607:f8b0:4864:20::830]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 13f0529a-dd54-11ee-a1ee-f123f15fe8a2; Fri, 08 Mar 2024 14:59:28 +0100 (CET) Received: by mail-qt1-x830.google.com with SMTP id d75a77b69052e-42f13eebabbso9799921cf.3 for ; Fri, 08 Mar 2024 05:59:28 -0800 (PST) Received: from [192.168.86.29] ([83.104.235.82]) by smtp.gmail.com with ESMTPSA id d17-20020ac85351000000b0042f148f6caasm2453283qto.78.2024.03.08.05.59.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 08 Mar 2024 05:59:26 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 13f0529a-dd54-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1709906367; x=1710511167; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=v/+37e/CZnsEbkRBexCvC3pluOt7LMrL9B3WZcXqPu4=; b=ZgJpWbMYQ3AkFPVYcpH48sEGYqge2O/H3GDnTt1/B3mUidlS1CmBe7XmnzhfR7Rk75 db0sc4M4WdatOuIlnQ42xRYdNpCfzXfgGiij8/btyA74HP9+mIGZshqMfCDC0U8x7Q8+ KOO/Y3A+4d1DsU8s4lhHT/eoFYwx5ba0/EvO8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709906367; x=1710511167; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=v/+37e/CZnsEbkRBexCvC3pluOt7LMrL9B3WZcXqPu4=; b=QraOCoFc8VsZnzJ8UBVEz5vWHlb1nrEko/ECZmjCMOvqxjB80Q7o2CJAJ5Y2YlOZta 7Wmrt1c5WTc5F9fUdy6TpkUGDuECbujcVriOjPGMXw0x745Mdt7daNheR32GB0uhvP/V LUwvyDxrdlvqEPhQMTcpR2maqjVwCS3tw+1DmaPOPCNg9b13jhm8jvvfww5RJ97GRtww spoEHakwuRZ4hyuhNBZx5mVfzHusJ4Tb3+s+M9jQP1sBiUtlEMqA+zZlPXVpDbaiQYd/ Dpx+JJDV5NZaAYIhtDGewKmkbwWOnjh1uQybibNJLPZVuksmjC8h74gaXRHaJ0HmxAua Vu/w== X-Forwarded-Encrypted: i=1; AJvYcCUKgOQgyrFMe16dJW2iQMXa2/SDo9yjAcyee+zGnhKu0Z+O8svBrjTfAtTR9Ulk8wHlBrp+5ihKPLDo7rHeQ3c2Vb2gzL2QudjvVHmc4NM= X-Gm-Message-State: AOJu0YxVraLqNaxXIs80rnCTU7OttcQ5EAv3tZAOsXe/wqFuMU8KNMCJ aIiZ2AueEgrbNpSTVZkxLPmHdlBlCphfZNXYm/mUFscfUSpLo4WYrKVdvZQsaXU= X-Google-Smtp-Source: AGHT+IFoPHKtY9ZPxS7YtBzkiGHnX2qzlkS3O+7Gnek0VVottCuWWniwZ/EkS3VOjPN9ra7VGXaR9g== X-Received: by 2002:a05:622a:118f:b0:42e:d2a7:9eee with SMTP id m15-20020a05622a118f00b0042ed2a79eeemr25173qtk.46.1709906367186; Fri, 08 Mar 2024 05:59:27 -0800 (PST) Message-ID: Date: Fri, 8 Mar 2024 13:59:25 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [xen-unstable test] 184940: regressions - FAIL Content-Language: en-GB To: Jan Beulich , xen-devel@lists.xenproject.org Cc: osstest service owner References: <5c21d349-5021-490f-bc6b-eb5973622688@suse.com> From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <5c21d349-5021-490f-bc6b-eb5973622688@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 08/03/2024 1:56 pm, Jan Beulich wrote: > On 08.03.2024 14:45, osstest service owner wrote: >> flight 184940 xen-unstable real [real] >> flight 184945 xen-unstable real-retest [real] >> http://logs.test-lab.xenproject.org/osstest/logs/184940/ >> http://logs.test-lab.xenproject.org/osstest/logs/184945/ >> >> Regressions :-( >> >> Tests which did not succeed and are blocking, >> including tests which could not be run: >> test-amd64-amd64-livepatch 13 livepatch-run fail REGR. vs. 184927 >> test-amd64-i386-livepatch 13 livepatch-run fail REGR. vs. 184927 > Hmm, both have "(XEN) common/livep" following the shell prompt, > i.e. an incomplete hypervisor log message (maybe a failed assertion?), > suggesting a triple fault may have occurred. While some livepatch > related changes are under test, I can't (for now) connect any of them > (or any of the other changes) with such behavior. Well... that's ominously my changes then, but our testing seems happy with them. ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Mar 08 14:05:17 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2024 14:05:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690313.1076198 (Exim 4.92) (envelope-from ) id 1riaqW-0001AF-CZ; Fri, 08 Mar 2024 14:05:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690313.1076198; Fri, 08 Mar 2024 14:05:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riaqW-0001A8-8m; Fri, 08 Mar 2024 14:05:12 +0000 Received: by outflank-mailman (input) for mailman id 690313; Fri, 08 Mar 2024 14:05:11 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riaqV-0001A1-NT for xen-devel@lists.xenproject.org; Fri, 08 Mar 2024 14:05:11 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riaqL-0001wf-T1; Fri, 08 Mar 2024 14:05:01 +0000 Received: from gw1.octic.net ([88.97.20.152] helo=[10.0.1.240]) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1riaqL-0003Ob-Lc; Fri, 08 Mar 2024 14:05:01 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID; bh=+SP+fyHAEWzq/M9ruBj6he5Ab9v6PnVgoi6FmrbjuH8=; b=F69wLXlKNMmzvtSgu5CconVXuL uIa3jelVf3MjrIMdv68+mBi35IBhgjFf/Hz58+IbLSssAduHCIpRMJEh4sh2iQ2GTFLor76IA6FZ2 scJtRYVmRUS61L9/pYQFek3KjDhQh/BNP/kfmoPt2Uv8m71RBmXvIZ6P7MV9NfbwrILk=; Message-ID: <48038c7f-d7cd-4100-a41b-8042bcb93208@xen.org> Date: Fri, 8 Mar 2024 14:04:59 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] xen/arm: Add imx8q{m,x} platform glue Content-Language: en-GB To: John Ernberg , Peng Fan , Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Cc: Jonas Blixt , "xen-devel@lists.xenproject.org" References: <20240131114952.305805-1-john.ernberg@actia.se> <20240131114952.305805-2-john.ernberg@actia.se> <494d4961-ad8a-4d1d-aaa6-d1bfb9d6a137@actia.se> <167f0c7a-e037-446c-82f8-2584e35a7af1@xen.org> <012b5f83-2f9b-4477-965e-07b8506c0052@xen.org> <5a0c8f09-4f01-45e9-892c-86342c0d0ec5@xen.org> <08ae764c-3490-4dd1-ab70-7a855a98d16d@actia.se> <911ec1bb-3733-4f37-839e-673a88e408ff@actia.se> <848794f3-a337-49d9-84db-a969970f071b@actia.se> From: Julien Grall In-Reply-To: <848794f3-a337-49d9-84db-a969970f071b@actia.se> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi John, Thank you for the reply. On 08/03/2024 13:40, John Ernberg wrote: > On 3/7/24 00:07, Julien Grall wrote: >> > Ping on the watchdog discussion bits. >> >> Sorry for the late reply. >> >> On 06/03/2024 13:13, John Ernberg wrote: >>> On 2/9/24 14:14, John Ernberg wrote: >>>> >>>>>     * IMX_SIP_TIMER_*:  This seems to be related to the watchdog. >>>>> Shouldn't dom0 rely on the watchdog provided by Xen instead? So those >>>>> call will be used by Xen. >>>> >>>> That is indeed a watchdog SIP, and also for setting the SoC internal RTC >>>> if it is being used. >>>> >>>> I looked around if there was previous discussion and only really >>>> found [3]. >>>> Is the xen/xen/include/watchdog.h header meant to be for this kind of >>>> watchdog support or is that more for the VM watchdog? Looking at the x86 >>>> ACPI NMI watchdog it seems like the former, but I have never worked with >>>> x86 nor ACPI. >> >> include/watchdog.h contains helper to configure the watchdog for Xen. We >> also have per-VM watchdog and this is configured by the hypercall >> SCHEDOP_watchdog. >> >>>> >>>> Currently forwarding it to Dom0 has not caused any watchdog resets with >>>> our watchdog timeout settings, our specific Dom0 setup and VM count. >> >> IIUC, the SMC API for the watchdog would be similar to the ACPI NMI >> watchdog. So I think it would make more sense if this is not exposed to >> dom0 (even if Xen is doing nothing with it). >> >> Can you try to hide the SMCs and check if dom0 still behave properly? >> >> Cheers, >> > > This SMC manages a hardware watchdog, if it's not pinged within a > specific interval the entire board resets. Do you know what's the default interval? Is it large enough so Xen + dom0 can boot (at least up to when the watchdog driver is initialized)? > > If I block the SMCs the watchdog driver in Dom0 will fail to ping the > watchdog, triggering a board reset because the system looks to have > become unresponsive. The reason this patch set started is because we > couldn't ping the watchdog when running with Xen. > > In our specific system the bootloader enables the watchdog as early as > possible so that we can get watchdog protection for as much of the boot > as we possibly can. > > So, if we are to block the SMC from Dom0, then Xen needs to take over > the pinging. It could be implemented similarly to the NMI watchdog, > except that the system will reset if the ping is missed rather than > backtrace. > It would also mean that Xen will get a whole watchdog driver-category > due to the watchdog being vendor and sometimes even SoC specific when it > comes to Arm. > > My understanding of the domain watchdog code is that today the domain > needs to call SCHEDOP_watchdog at least once to start the watchdog > timer. Since watchdog protection through the whole boot process is > desirable we'd need some core changes, such as an option to start the > domain watchdog on init. > > It's quite a big change to make For clarification, above you seem to mention two changes: 1) Allow Xen to use the HW watchdog 2) Allow the domain to use the watchdog early I am assuming by big change, you are referring to 2? , while I am not against doing it if it > makes sense, I now wonder if Xen should manage hardware watchdogs. > Looking at the domain watchdog code it looks like if a domain does not > get enough execution time, the watchdog will not be pinged enough and > the guest will be reset. So either watchdog approach requires Dom0 to > get execution time. Dom0 also needs to service all the PV backends it's > responsible for. I'm not sure it's valuable to add another layer of > watchdog for this scenario as the end result (checking that the entire > system works) is achieved without it as well. > > So, before I try to find the time to make a proposal for moving the > hardware watchdog bit to Xen, do we really want it? Thanks for the details. Given that the watchdog is enabled by the bootloader, I think we want Xen to drive the watchdog for two reasons: 1) In true dom0less environment, dom0 would not exist 2) You are relying on Xen + Dom0 to boot (or at least enough to get the watchdog working) within the watchdog interval. Let see what the other Arm maintainer thinks. -- Julien Grall From xen-devel-bounces@lists.xenproject.org Fri Mar 08 14:13:49 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2024 14:13:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690318.1076207 (Exim 4.92) (envelope-from ) id 1riayl-0003fL-54; Fri, 08 Mar 2024 14:13:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690318.1076207; Fri, 08 Mar 2024 14:13:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riayl-0003fE-1f; Fri, 08 Mar 2024 14:13:43 +0000 Received: by outflank-mailman (input) for mailman id 690318; Fri, 08 Mar 2024 14:13:41 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riayj-0003f5-K9 for xen-devel@lists.xenproject.org; Fri, 08 Mar 2024 14:13:41 +0000 Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [2a00:1450:4864:20::132]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 10344cd1-dd56-11ee-afda-a90da7624cb6; Fri, 08 Mar 2024 15:13:40 +0100 (CET) Received: by mail-lf1-x132.google.com with SMTP id 2adb3069b0e04-51381021af1so1172035e87.0 for ; Fri, 08 Mar 2024 06:13:40 -0800 (PST) Received: from [192.168.2.1] (82-64-138-184.subs.proxad.net. [82.64.138.184]) by smtp.googlemail.com with ESMTPSA id gw7-20020a05600c850700b004131cf78b4bsm217270wmb.12.2024.03.08.06.13.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 08 Mar 2024 06:13:39 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 10344cd1-dd56-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rabbit-lu.20230601.gappssmtp.com; s=20230601; t=1709907220; x=1710512020; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=7XAbHe3tvltBkDMNXGP8CG3mD1nQs603kllqrVvmKiY=; b=fuYattArEH/Vg6Sznsi6ff9Uflv/AbvOD64pmEUNZ/2P6ewrsTccwpa7Tg91VgzOde 8bcVPY68Kv0gitdMQh899m5WFCFLH+cDLMMYmkuo6/8b3UEtWoOlbD2ncCl/eSIVOT+T cyVwoQOpqHS/EaBzrLUEy7x4YVvagO1axRXswJeh2kh22EETcSi7aWT55vWPHqz9YcH9 KuIFwCN/wx122wJqLTRY6/aCmg0+CYxTH7JiXbFXNp3x6cA+08GxdLQKyu8N3twZDS3H ORO7FyYx59EP0nNvodPGOKoa9NqcCYwPjwpFAwmJeSGJP14DxGAU/Mi2lCi7OrrmhbuP uOEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709907220; x=1710512020; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=7XAbHe3tvltBkDMNXGP8CG3mD1nQs603kllqrVvmKiY=; b=p9iteSjEEflqUo3MHQrgOQJRAie19oELx7QCI0NeSrYsrQYCghN/v3xMhhZZqrMGva nsAR6UNscTmNYg9UiR1Yh+nfQawpgIORrxP8IkG/lgz9bVP0ezHfR3ym/n/YEqFzwGF6 qHoOR+QUkwckvLYaQL5rhmVhuHuQNuqV+MyBSgxlHO01PP3GHHyV/8WNWVcrqtwZDfUS kzIh1qUHUW1LhgrNJfqaGlgwRgwrTxkvBSRZdBvnrvFHGz7aO4GRgIrXz3+7B3eDvKEH tAYaC2ikfuecwBuw9DEMWWc53UIqM995jchjOcL4MO0a4gbGkV7cCP/h5DiLZxoajPhY 5rOg== X-Gm-Message-State: AOJu0YxjvwNh3ET9p6d0cm22H+B8s3J7Ee4cPYWFiuxw4zAMdtN7v1lz 5DGEt6OS1GACcXuuKF073eGAE0FEe1qW8yYEjToWQo3NYJzlY92PCKEQxyEKDz4= X-Google-Smtp-Source: AGHT+IHHyMgfPmmrz8wWvAMD475ekmMq2W1vHljLZEFs+uHP/F5Y0ttyry/ouByw4YhvR8jCf0PFKg== X-Received: by 2002:a05:6512:3b9:b0:513:5dee:3a7d with SMTP id v25-20020a05651203b900b005135dee3a7dmr3081205lfp.50.1709907219716; Fri, 08 Mar 2024 06:13:39 -0800 (PST) Message-ID: <172632e1-9d9a-415d-a6e7-47e3803ab6c6@rabbit.lu> Date: Fri, 8 Mar 2024 15:13:37 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] docs/man: add shutdown reasons to xl (list) man page Content-Language: en-US To: Anthony PERARD Cc: xen-devel@lists.xenproject.org, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu References: <019602d6da2ff78e6582b9b6aae6d76216e150c3.1709678713.git.slack@rabbit.lu> <5e8987de-36b1-4e00-876c-79a93e5334a9@perard> From: zithro In-Reply-To: <5e8987de-36b1-4e00-876c-79a93e5334a9@perard> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 06 Mar 2024 16:43, Anthony PERARD wrote: > On Tue, Mar 05, 2024 at 11:45:13PM +0100, zithro / Cyril Rébert wrote: >> Add the shutdown reasons to the paragraph of "xl list" concerning the >> shutdown status. >> I have copy/pasted the explanations from the source code : >> >> - tools/xl/xl_info.c (L379) > > Instead of a line number, how about the function name? > - tools/xl/xl_info.c (list_domains()) > >> - xen/include/public/sched.h (starting L158) > > And here, I think that would be "sched_shutdown_reason". > > Line number tend to change as we add more code, which mean that the line > number is only valid at the time it is written into the patch > description. But functions and struct name are less likely to be > renamed. Agreed, and for all other remarks too, so will send a v2. (I'll also add Roger's remark about wrapping the long line). > From xen-devel-bounces@lists.xenproject.org Fri Mar 08 14:14:00 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2024 14:14:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690319.1076218 (Exim 4.92) (envelope-from ) id 1riaz2-0003zn-C9; Fri, 08 Mar 2024 14:14:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690319.1076218; Fri, 08 Mar 2024 14:14:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riaz2-0003ze-8g; Fri, 08 Mar 2024 14:14:00 +0000 Received: by outflank-mailman (input) for mailman id 690319; Fri, 08 Mar 2024 14:13:59 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riaz1-0003xm-0L for xen-devel@lists.xenproject.org; Fri, 08 Mar 2024 14:13:59 +0000 Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [2a00:1450:4864:20::531]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 1a0b060b-dd56-11ee-a1ee-f123f15fe8a2; Fri, 08 Mar 2024 15:13:57 +0100 (CET) Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-563bb51c36eso2285340a12.2 for ; Fri, 08 Mar 2024 06:13:57 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1a0b060b-dd56-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1709907236; x=1710512036; darn=lists.xenproject.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=05gSGMW5+/FEQxjOa7nPRDuwgAU8PNa0oI5umgHVvaA=; b=CrLst/0T1JJAZNX+G0YQrM2kdUzcSU8c8Yqpj44Pi7/bU3JtdlOT+X06ALcySNCU5G zSHGsCYq+JVuGH+9PflJ3qKLZ7b1Eg9j+NbQehk7ILDiFYhlxVa3nUtOwW86tua04pet nrIabGAqrV8YyoPxZzPv2WJACiPeP1/O4Lf5M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709907236; x=1710512036; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=05gSGMW5+/FEQxjOa7nPRDuwgAU8PNa0oI5umgHVvaA=; b=h3SjZu2ghDT30vzX/AkEWLvwg1QgPa+pg5aOgqs+QFnkz1tpss2IYeC+hIP2z+jQyD INJ7dfH0DoiCPAGgBZNJUee0j20jr+/JzGXbEVm07TJCnFUCMtDjONMAitI9itZz1ETl GMS6nkxVLMB/J1GXGaeQmNUdpttiv1JXH8N3QwJW4CmWqADjwQPnnxxxIdma0WOweQAf 0jKr7/DIEok+VUL1y7wJYEQKjdj0V4bu0+fdUP6WDSW6qjzjrOOeLN9aip5i4JkvqG4A hH68D22xGflOGuakcEGJyoAZwxQfpDFSVZUwsd2g2heBWWY25zYYsHgbDhsBKWSbr4y0 HAPw== X-Gm-Message-State: AOJu0YxKJQwFZSZNxnp7QLBDutQ1ZcNd60xzDoGzVRX3rddqrThrYpeF 2FoRAAocC3KXwqVZOiVIyi78CowqEmWE8CRtDahCBcZF6wW9+4YUsv1xVmZ07A2I2CnDCQisvvZ fw3r1LyRQrKnabt42fvwe1jqKSRoMZXqxetCKyQDIL0fyS46UN+s= X-Google-Smtp-Source: AGHT+IFBZuMIBZ2JDLXUCEPXwGPzLtMtOZWsXrT95Ig+kYeC0Q+w7SyoMmtxdcLVeuCUxB+/7YpxqRSXoCkcdqWV3Xc= X-Received: by 2002:a50:c314:0:b0:565:7116:d533 with SMTP id a20-20020a50c314000000b005657116d533mr2304117edb.6.1709907235980; Fri, 08 Mar 2024 06:13:55 -0800 (PST) MIME-Version: 1.0 From: Kelly Choi Date: Fri, 8 Mar 2024 14:13:19 +0000 Message-ID: Subject: March - Community call recording To: xen-devel Content-Type: multipart/alternative; boundary="000000000000666aba061326cd4b" --000000000000666aba061326cd4b Content-Type: text/plain; charset="UTF-8" Hi all, The March community call recording has been uploaded: https://youtu.be/IBKUEy5ZSrQ This has also been saved in the Cryptpad file. Many thanks, Kelly Choi Community Manager Xen Project --000000000000666aba061326cd4b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

The March community call record= ing has been uploaded:=C2=A0https:= //youtu.be/IBKUEy5ZSrQ
T= his has also been saved in the Cryptpad file.

Many= thanks,
Kelly Choi

Community Manager
Xen Project=C2=A0
--000000000000666aba061326cd4b-- From xen-devel-bounces@lists.xenproject.org Fri Mar 08 15:20:04 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2024 15:20:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690335.1076239 (Exim 4.92) (envelope-from ) id 1ric0k-00087V-US; Fri, 08 Mar 2024 15:19:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690335.1076239; Fri, 08 Mar 2024 15:19:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ric0k-00087O-RX; Fri, 08 Mar 2024 15:19:50 +0000 Received: by outflank-mailman (input) for mailman id 690335; Fri, 08 Mar 2024 15:19:49 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ric0i-000860-S4 for xen-devel@lists.xenproject.org; Fri, 08 Mar 2024 15:19:48 +0000 Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [2a00:1450:4864:20::32b]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 4bca6f16-dd5f-11ee-a1ee-f123f15fe8a2; Fri, 08 Mar 2024 16:19:46 +0100 (CET) Received: by mail-wm1-x32b.google.com with SMTP id 5b1f17b1804b1-41316512055so7978985e9.2 for ; Fri, 08 Mar 2024 07:19:46 -0800 (PST) Received: from localhost.localdomain (82-64-138-184.subs.proxad.net. [82.64.138.184]) by smtp.googlemail.com with ESMTPSA id d8-20020a05600c4c0800b004130889c7b3sm5993105wmp.34.2024.03.08.07.19.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 Mar 2024 07:19:44 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 4bca6f16-dd5f-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rabbit-lu.20230601.gappssmtp.com; s=20230601; t=1709911185; x=1710515985; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=0Thr5ENyvPLoF4bqDxKM90EiB1TJ9YdmJBGx+I/Z+q8=; b=DO4hSaa6tIxmFn3NXc4O3l0KFQPob5PyFPN6dQikXP9OIR3Gu46sc2VvpcespgsEG2 pm3tSB1uO8mBubyP0N1SHaUV/uz+N0JtA+fooVSqlvM56RYtPQUbOyPYah5JuiKFqlCk 4m6mVn/x7WmQJKg/FpKa5v+KlghoNGMUA4V07lWxyOhUVdIpRvB10wbu3ddYDhFNwzir WTOLazUx3XXkTNhkqmvpExn4+7v5+4BZYtyPABMVhovTnb1OPVjEVmF/RFfsnzZYnK5C 8Su6loz6Or1vCvMkKULhW8S3A8m7O8mautd8VS+luhVPRooGCyDh/MWInYmRLwDd4cwo 06hA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709911185; x=1710515985; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=0Thr5ENyvPLoF4bqDxKM90EiB1TJ9YdmJBGx+I/Z+q8=; b=rvZgLW9YWz3amAfv+/gIWDNrYOECrlWMkk65VTBsJ02SHhHE+8SeTtmFToy+TNip1A 9f8l3oxV6966JNPCvoNLDgCJH28ptr6jQV9IFNssAXFHMvc/Cb4f2CenxoFHNrXlRQg5 NDqYxbsx3ZVhDz+Qd7I2e8weCHEG3kBIpDw4vEaFA8uhpvE6WO6ihPZmqllFQydlw1oX qnM51Z4KVk0oL3tiF8e30OAwj/dOMoLeoG0HG9XUGAnK0xNoZArmjB3zdl9gj3G3Wlr0 qEPo+aiNCihvH2/yqfEj7hluA5NzHR3IRWbE+ljAy3KIeVlx1a9ehkzTh9koByGjlkgP zztA== X-Gm-Message-State: AOJu0Yx1M9jpOeQ+K86DePlsE/n0iH6VgB7wgXpp5v7E0WoTUehkt5iv Kgvwmg24+OXjlD0UQBpfT0MX+ByOUEmbWUGefmT+jtgLHWaswNCZw/W+4w5akCJO0IRxSrNOxhJ I X-Google-Smtp-Source: AGHT+IHiaAJqPMGi9k6Smk9LMBKkuT2WruGkYhVCrqw6IuwF0IcCTr53NN+mer6aP7WmLNw7uYa5Iw== X-Received: by 2002:a05:600c:3515:b0:412:eff3:8497 with SMTP id h21-20020a05600c351500b00412eff38497mr7544830wmq.1.1709911185282; Fri, 08 Mar 2024 07:19:45 -0800 (PST) From: =?UTF-8?q?zithro=20/=20Cyril=20R=C3=A9bert?= To: xen-devel@lists.xenproject.org Cc: =?UTF-8?q?zithro=20/=20Cyril=20R=C3=A9bert?= , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Wei Liu , Anthony PERARD Subject: [PATCH v2] docs/man: add shutdown reasons to xl (list) man page Date: Fri, 8 Mar 2024 16:19:20 +0100 Message-Id: <0a2fcad111622431b8cd54c69adc3dedd24fb572.1709910923.git.slack@rabbit.lu> X-Mailer: git-send-email 2.39.2 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add the shutdown reasons to the paragraph of "xl list" concerning the shutdown status. I have adapted the explanations from the source code : - tools/xl/xl_info.c : function "list_domains()", variable "shutdown_reason_letters" - xen/include/public/sched.h : variable "shed_shutdown_reason" Suggested-by: Roger Pau Monné Signed-off-by: Cyril Rébert / zithro --- v2: - apply changes from Anthony and Roger Questions (unblocking): - why a double space between all sentences ? - how to get a "simple LF" ? Ie. I want to use
, not

(a simple has no effect, a double renders a

) --- docs/man/xl.1.pod.in | 40 +++++++++++++++++++++++++++++++++++++++- 1 file changed, 39 insertions(+), 1 deletion(-) diff --git a/docs/man/xl.1.pod.in b/docs/man/xl.1.pod.in index bed8393473..d37227ba58 100644 --- a/docs/man/xl.1.pod.in +++ b/docs/man/xl.1.pod.in @@ -370,12 +370,50 @@ scheduling by the Xen hypervisor. The guest OS has shut down (SCHEDOP_shutdown has been called) but the domain is not dying yet. -=item B +There are six shutdown reasons, which will be displayed after the "s" : B<-rscwS>. + +Note that some states will only be displayed if "on_poweroff=preserve" is set in +the config file, see L). + +=over 4 + +=over 4 + +=item B + +The domain exited normally, it will get destroyed. + +=item B + +The domain will reboot. + +=item B + +The domain is suspended to disk or to RAM. If suspended to disk, the domain will +get destroyed. + +=item B The domain has crashed, which is always a violent ending. Usually this state only occurs if the domain has been configured not to restart on a crash. See L for more info. +=item B + +Restart because watchdog time expired. + +=item B + +The domain asked to perform 'soft reset' for it. The expected behavior +is to reset internal Xen state for the domain returning it to the point +where it was created but leaving the domain's memory contents and vCPU +contexts intact. This will allow the domain to start over and set up +all Xen specific interfaces again. + +=back + +=back + =item B The domain is in the process of dying, but hasn't completely shut down or -- 2.39.2 From xen-devel-bounces@lists.xenproject.org Fri Mar 08 17:14:46 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2024 17:14:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690359.1076256 (Exim 4.92) (envelope-from ) id 1ridnk-0001DY-1w; Fri, 08 Mar 2024 17:14:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690359.1076256; Fri, 08 Mar 2024 17:14:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ridnj-0001DR-VA; Fri, 08 Mar 2024 17:14:31 +0000 Received: by outflank-mailman (input) for mailman id 690359; Fri, 08 Mar 2024 17:14:30 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ridni-0001DL-0y for xen-devel@lists.xenproject.org; Fri, 08 Mar 2024 17:14:30 +0000 Received: from mailout1.w1.samsung.com (mailout1.w1.samsung.com [210.118.77.11]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 4f86b800-dd6f-11ee-afda-a90da7624cb6; Fri, 08 Mar 2024 18:14:26 +0100 (CET) Received: from eucas1p1.samsung.com (unknown [182.198.249.206]) by mailout1.w1.samsung.com (KnoxPortal) with ESMTP id 20240308171423euoutp01b376bd1afabfb23ebe82e3516c38fac9~62WtkzBrg1001510015euoutp01s for ; Fri, 8 Mar 2024 17:14:23 +0000 (GMT) Received: from eusmges3new.samsung.com (unknown [203.254.199.245]) by eucas1p2.samsung.com (KnoxPortal) with ESMTP id 20240308171423eucas1p2371311a5b08d9706eaf93179362c94a4~62WtQk0AA1558315583eucas1p2a; Fri, 8 Mar 2024 17:14:23 +0000 (GMT) Received: from eucas1p2.samsung.com ( [182.198.249.207]) by eusmges3new.samsung.com (EUCPMTA) with SMTP id D8.9D.09552.F674BE56; Fri, 8 Mar 2024 17:14:23 +0000 (GMT) Received: from eusmtrp2.samsung.com (unknown [182.198.249.139]) by eucas1p2.samsung.com (KnoxPortal) with ESMTPA id 20240308171422eucas1p293895be469655aa618535cf199b0c43a~62WsXkhLx1558115581eucas1p2O; Fri, 8 Mar 2024 17:14:22 +0000 (GMT) Received: from eusmgms1.samsung.com (unknown [182.198.249.179]) by eusmtrp2.samsung.com (KnoxPortal) with ESMTP id 20240308171422eusmtrp24638ab6298336da4c1c0e8a41a4a64fc~62WsW41FF2621526215eusmtrp2E; Fri, 8 Mar 2024 17:14:22 +0000 (GMT) Received: from eusmtip2.samsung.com ( [203.254.199.222]) by eusmgms1.samsung.com (EUCPMTA) with SMTP id 02.2F.09146.E674BE56; Fri, 8 Mar 2024 17:14:22 +0000 (GMT) Received: from [106.210.134.192] (unknown [106.210.134.192]) by eusmtip2.samsung.com (KnoxPortal) with ESMTPA id 20240308171421eusmtip21f5afb8678a08bd51cca727cfeea567f~62WrRSVaA2266422664eusmtip2R; Fri, 8 Mar 2024 17:14:21 +0000 (GMT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 4f86b800-dd6f-11ee-afda-a90da7624cb6 DKIM-Filter: OpenDKIM Filter v2.11.0 mailout1.w1.samsung.com 20240308171423euoutp01b376bd1afabfb23ebe82e3516c38fac9~62WtkzBrg1001510015euoutp01s DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1709918063; bh=DSDacrVBnLQUXSKvLn3/E67RoDPwbljmlkbfkQl9jbw=; h=Date:Subject:To:Cc:From:In-Reply-To:References:From; b=c9Xdc3MH/xVf6+dULK54d9bPJDYmO7KLujMYxCNxfOcZcvVDqr8/dd7163R7/ZzL1 Ap5hL6uI8DFKeOqH8jhDEbyJLQ955dLiCyVsA5dfOENtXhUu3TrDktjjb33dXu6Ja2 RSYL6IamUWzMUdlJ3NuP5ynIy1s0n41r1uV2fplQ= X-AuditID: cbfec7f5-853ff70000002550-40-65eb476faf57 Message-ID: <1f49d568-24f9-4003-b222-515f33a99cf2@samsung.com> Date: Fri, 8 Mar 2024 18:14:21 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 bpf-next 1/2] mm: Enforce VM_IOREMAP flag and range in ioremap_page_range. Content-Language: en-US To: Alexei Starovoitov , bpf@vger.kernel.org Cc: daniel@iogearbox.net, andrii@kernel.org, torvalds@linux-foundation.org, brho@google.com, hannes@cmpxchg.org, lstoakes@gmail.com, akpm@linux-foundation.org, urezki@gmail.com, hch@infradead.org, rppt@kernel.org, boris.ostrovsky@oracle.com, sstabellini@kernel.org, jgross@suse.com, linux-mm@kvack.org, xen-devel@lists.xenproject.org, kernel-team@fb.com From: Marek Szyprowski In-Reply-To: <20240305030516.41519-2-alexei.starovoitov@gmail.com> Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOKsWRmVeSWpSXmKPExsWy7djP87r57q9TDVadFLGYs34Nm0XD4w5W i++/ZzNbXJzeymLx+chxNourPZ9ZLBYv/MZssXqTr8XpCYuYLObcNLI41vee1eLemv+sFne+ zWO3OLJ+O5PF6nXxFo/63rJbrL7IYvF9y2QmByGPw2/eM3tMbH7H7rFz1l12jwWbSj02r9Dy 6Lpxidlj06pONo9Nnyaxe5yY8ZvF4/CHKyweH5/eYvFYv+Uqi8fnTXIBvFFcNimpOZllqUX6 dglcGScWzWMsOKdc8WzdWfYGxslyXYwcHBICJhLrbiZ2MXJxCAmsYJRY2DOFGcL5wijRM+kd I4TzmVHi768zQA4nWMfaqU1MEInljBL37/+GqvrIKPFm01VmkCpeATuJbQ8XM4HYLAIqEn/a H7NDxAUlTs58wgJiiwrIS9y/NQMsLiyQLHH57wUwm1lAXOLWk/lgvSICXhJ3t7axQMRfM0ns vloBYrMJGEp0ve1iA7E5BZwk9j56zApRIy/RvHU22A8SAvc4Je5u+80GcbaLxP7tk6BeEJZ4 dXwLO4QtI/F/53wmiIZ2RokFv+9DORMYJRqe34LqsJa4c+4XGyjImAU0Jdbv0ocIO0pM6XjH BAlJPokbbwUhjuCTmLRtOjNEmFeio00IolpNYtbxdXBrD164xDyBUWkWUrDMQvL+LCTvzELY u4CRZRWjeGppcW56arFxXmq5XnFibnFpXrpecn7uJkZg2jz97/jXHYwrXn3UO8TIxMF4iFGC g1lJhJfF4mWqEG9KYmVValF+fFFpTmrxIUZpDhYlcV7VFPlUIYH0xJLU7NTUgtQimCwTB6dU A5M4z6VXBs4R515kOB54fal0Y0Pt2Vcr1E8F7tRgiGmPWXjm1I50i/5bTc1Ho4O5e1I4A393 xxQun3b1I3d7eN6uHlezg2L/vm8yZolO04iZo75cYbf46Sw17fTkztWT+1Z9tn20/cS2D6+s 1+s62rydEf6t8fQ7xRvvL2/ylnr590JUoWJN2Y/b/EwLayesOprhzNd16/ESry9Xipcv+lw6 g4HJOsFBYuebx7btx0Krzz+RuZellpA86a7z9I27vDQePjNITNQ/foyv7c6Mp+tj8oKWf9q6 aSbH1nfVEj/a1f+d1BZ7PWVh8T2m3fvPyac3PJQ/cOCm6mnHskXTNfS1YupdGhQkDylV+aXr M2crsRRnJBpqMRcVJwIA1gwiTQoEAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupileLIzCtJLcpLzFFi42I5/e/4Pd0899epBq3bpSzmrF/DZtHwuIPV 4vvv2cwWF6e3slh8PnKczeJqz2cWi8ULvzFbrN7ka3F6wiImizk3jSyO9b1ntbi35j+rxZ1v 89gtjqzfzmSxel28xaO+t+wWqy+yWHzfMpnJQcjj8Jv3zB4Tm9+xe+ycdZfdY8GmUo/NK7Q8 um5cYvbYtKqTzWPTp0nsHidm/GbxOPzhCovHx6e3WDzWb7nK4vF5k1wAb5SeTVF+aUmqQkZ+ cYmtUrShhZGeoaWFnpGJpZ6hsXmslZGpkr6dTUpqTmZZapG+XYJexolF8xgLzilXPFt3lr2B cbJcFyMnh4SAicTaqU1MXYxcHEICSxklXsx/wwqRkJE4Oa0ByhaW+HOtiw2i6D2jxN5zrewg CV4BO4ltDxczgdgsAioSf9ofQ8UFJU7OfMICYosKyEvcvzUDLC4skCzx8uUjsKHMAuISt57M B+sVEfCSuLu1jQVkAbPAayaJ+0tbGEESQgKVEu/Xd4M1sAkYSnS9BbmCk4NTwEli76PHUIPM JLq2djFC2PISzVtnM09gFJqF5I5ZSPbNQtIyC0nLAkaWVYwiqaXFuem5xYZ6xYm5xaV56XrJ +bmbGIGJYtuxn5t3MM579VHvECMTB+MhRgkOZiURXhaLl6lCvCmJlVWpRfnxRaU5qcWHGE2B gTGRWUo0OR+YqvJK4g3NDEwNTcwsDUwtzYyVxHk9CzoShQTSE0tSs1NTC1KLYPqYODilGpic Js67+29/Ar8Dd3hCoWv05FdBc6SCp88z5RXlWbfmaZLzIUmn6K4wgZaFff9d/LeaLOZ71FQ+ fYHrg46rc44eutZkl3zj9VEbmYmv5zembVjNVnvVs8LT/tOBW09ZV9vY37OZxxzP/qNUcMIW UbeCaVN/eT14l8ms73Ks2aZKdEYAX/3Ry5sNE0ymGcT6faybv4XjX29B80bLr32RFssm+Nfy 7+5zqWirdOY6q7xsQdVjL+b2CxKeuXPT5P5KP9Lgklq/7vo6qalaLTYzvRTmSnreXS5+4Lzg kUTv73YCfQFn351dEH6l0sCXK0BVRok7QTvU3u3iuvnaFTyM899oXvptySbxcubJKuGl4kos xRmJhlrMRcWJAJJePS+dAwAA X-CMS-MailID: 20240308171422eucas1p293895be469655aa618535cf199b0c43a X-Msg-Generator: CA Content-Type: text/plain; charset="utf-8" X-RootMTR: 20240308171422eucas1p293895be469655aa618535cf199b0c43a X-EPHeader: CA CMS-TYPE: 201P X-CMS-RootMailID: 20240308171422eucas1p293895be469655aa618535cf199b0c43a References: <20240305030516.41519-1-alexei.starovoitov@gmail.com> <20240305030516.41519-2-alexei.starovoitov@gmail.com> On 05.03.2024 04:05, Alexei Starovoitov wrote: > From: Alexei Starovoitov > > There are various users of get_vm_area() + ioremap_page_range() APIs. > Enforce that get_vm_area() was requested as VM_IOREMAP type and range > passed to ioremap_page_range() matches created vm_area to avoid > accidentally ioremap-ing into wrong address range. > > Reviewed-by: Christoph Hellwig > Signed-off-by: Alexei Starovoitov > --- This patch landed in today's linux-next as commit 3e49a866c9dc ("mm: Enforce VM_IOREMAP flag and range in ioremap_page_range."). Unfortunately it triggers the following warning on all my test machines with PCI bridges. Here is an example reproduced with QEMU and ARM64 'virt' machine: pci-host-generic 4010000000.pcie: host bridge /pcie@10000000 ranges: pci-host-generic 4010000000.pcie:       IO 0x003eff0000..0x003effffff -> 0x0000000000 pci-host-generic 4010000000.pcie:      MEM 0x0010000000..0x003efeffff -> 0x0010000000 pci-host-generic 4010000000.pcie:      MEM 0x8000000000..0xffffffffff -> 0x8000000000 ------------[ cut here ]------------ vm_area at addr fffffbfffe800000 is not marked as VM_IOREMAP WARNING: CPU: 0 PID: 1 at mm/vmalloc.c:315 ioremap_page_range+0x8c/0x174 Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.8.0-rc6+ #14694 Hardware name: linux,dummy-virt (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ioremap_page_range+0x8c/0x174 lr : ioremap_page_range+0x8c/0x174 sp : ffff800083faba10 ... Call trace:  ioremap_page_range+0x8c/0x174  pci_remap_iospace+0x74/0x88  devm_pci_remap_iospace+0x54/0xac  devm_of_pci_bridge_init+0x160/0x1fc  devm_pci_alloc_host_bridge+0xb4/0xd0  pci_host_common_probe+0x44/0x1a0  platform_probe+0x68/0xd8  really_probe+0x148/0x2b4  __driver_probe_device+0x78/0x12c  driver_probe_device+0xdc/0x164  __driver_attach+0x9c/0x1ac  bus_for_each_dev+0x74/0xd4  driver_attach+0x24/0x30  bus_add_driver+0xe4/0x1e8  driver_register+0x60/0x128  __platform_driver_register+0x28/0x34  gen_pci_driver_init+0x1c/0x28  do_one_initcall+0x74/0x2f4  kernel_init_freeable+0x28c/0x4dc  kernel_init+0x24/0x1dc  ret_from_fork+0x10/0x20 irq event stamp: 74360 hardirqs last  enabled at (74359): [] console_unlock+0x120/0x12c hardirqs last disabled at (74360): [] el1_dbg+0x24/0x8c softirqs last  enabled at (71258): [] __do_softirq+0x4a0/0x4e8 softirqs last disabled at (71245): [] ____do_softirq+0x10/0x1c ---[ end trace 0000000000000000 ]--- pci-host-generic 4010000000.pcie: error -22: failed to map resource [io  0x0000-0xffff] pci-host-generic 4010000000.pcie: Memory resource size exceeds max for 32 bits pci-host-generic 4010000000.pcie: ECAM at [mem 0x4010000000-0x401fffffff] for [bus 00-ff] pci-host-generic 4010000000.pcie: PCI host bridge to bus 0000:00 pci_bus 0000:00: root bus resource [bus 00-ff] pci_bus 0000:00: root bus resource [mem 0x10000000-0x3efeffff] pci_bus 0000:00: root bus resource [mem 0x8000000000-0xffffffffff] pci 0000:00:00.0: [1b36:0008] type 00 class 0x060000 conventional PCI endpoint It looks that PCI related code must be somehow adjusted for this change. > mm/vmalloc.c | 13 +++++++++++++ > 1 file changed, 13 insertions(+) > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > index d12a17fc0c17..f42f98a127d5 100644 > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -307,8 +307,21 @@ static int vmap_range_noflush(unsigned long addr, unsigned long end, > int ioremap_page_range(unsigned long addr, unsigned long end, > phys_addr_t phys_addr, pgprot_t prot) > { > + struct vm_struct *area; > int err; > > + area = find_vm_area((void *)addr); > + if (!area || !(area->flags & VM_IOREMAP)) { > + WARN_ONCE(1, "vm_area at addr %lx is not marked as VM_IOREMAP\n", addr); > + return -EINVAL; > + } > + if (addr != (unsigned long)area->addr || > + (void *)end != area->addr + get_vm_area_size(area)) { > + WARN_ONCE(1, "ioremap request [%lx,%lx) doesn't match vm_area [%lx, %lx)\n", > + addr, end, (long)area->addr, > + (long)area->addr + get_vm_area_size(area)); > + return -ERANGE; > + } > err = vmap_range_noflush(addr, end, phys_addr, pgprot_nx(prot), > ioremap_max_page_shift); > flush_cache_vmap(addr, end); Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland From xen-devel-bounces@lists.xenproject.org Fri Mar 08 17:17:08 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2024 17:17:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690362.1076265 (Exim 4.92) (envelope-from ) id 1ridqE-0001l9-Dg; Fri, 08 Mar 2024 17:17:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690362.1076265; Fri, 08 Mar 2024 17:17:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ridqE-0001l2-Au; Fri, 08 Mar 2024 17:17:06 +0000 Received: by outflank-mailman (input) for mailman id 690362; Fri, 08 Mar 2024 17:17:04 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ridqC-0001kk-RM for xen-devel@lists.xenproject.org; Fri, 08 Mar 2024 17:17:04 +0000 Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [2a00:1450:4864:20::12c]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id aea0dd46-dd6f-11ee-afda-a90da7624cb6; Fri, 08 Mar 2024 18:17:03 +0100 (CET) Received: by mail-lf1-x12c.google.com with SMTP id 2adb3069b0e04-51321e71673so2585585e87.2 for ; Fri, 08 Mar 2024 09:17:03 -0800 (PST) Received: from perard.uk.xensource.com (default-46-102-197-194.interdsl.co.uk. [46.102.197.194]) by smtp.gmail.com with ESMTPSA id p19-20020a05600c419300b0041294d015fbsm6272422wmh.40.2024.03.08.09.17.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 Mar 2024 09:17:02 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: aea0dd46-dd6f-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1709918223; x=1710523023; darn=lists.xenproject.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=pHT22q20LOhDsFUsysvtbs6WGw7zAZt1pm32ji4d6KY=; b=N+1MsWHiYGjj95okwPE+ju5n59NkLBKvmo/J+clz9U46IJGzt/YuoHzQcFePGPAnS5 rDRYc4SHXgInl/AbEosnfUWdgq0pnBTZArT9B3OQKNwCqN/6Bv6FQn0g5lmFNcf1KX4x /8XDiTkauQlsfIVkCd2m5G2VPZBcAjGeWKu1E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709918223; x=1710523023; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=pHT22q20LOhDsFUsysvtbs6WGw7zAZt1pm32ji4d6KY=; b=nu8vY60EW08T9n88wINF6XLVRKv01azf/hxYq0foBvMAbDtB+KzVvS1cySqfe3a4x3 M5iqMoP7J8tX5l7FWY/rga6C9T6l99jKyyhhQ5nkgyR+agDVic+bMlSAIgtC3X5246Xl O70LVZu+3DiU3OCNt+5QYzufhpeihL8yDUCZXB/cEIC+mibv8mHyG3DPJukSnxus6tLg mVMHzagPu8PYofm+/ivPh6sEw2BULo+bNLFF4r73SIKeoXl+fjvdbWmcX7w4Yu988aum M0anrvRewDJpQx9LBNjpxURQlx6sfl337KFrMkolKRl8v4YpsM0OSDTVLfvjw2UH99x9 Er9g== X-Forwarded-Encrypted: i=1; AJvYcCVJ1/Ln4plFXtMdsKhx4ZbCXG0H0qh3MrdcfemHdmjucUd/XA0EaOaxr2QV6fwAdM1Z7O1po2s5is17N2HiZ7cIyp7qfOWHMZgU5m/v/uM= X-Gm-Message-State: AOJu0YzHNNhQUMjPaCoqbPxyK5iT0yPwjCw520LtYHibxzCEUPr4HH/i sFTylPXO+yqLo/+MzhCguUgzvs4ZAebaTM+/zPkbHGbkt1WOfgZQEJFiw1eMNB0= X-Google-Smtp-Source: AGHT+IEU7Rdcx8SJgoLNA+lYk/KOZq6CeemPaCgTAadtIVoFsRgKcJ27c8QiP6HFeGa6On80nI0ddA== X-Received: by 2002:a19:6904:0:b0:513:3106:ac63 with SMTP id e4-20020a196904000000b005133106ac63mr3497403lfc.17.1709918223066; Fri, 08 Mar 2024 09:17:03 -0800 (PST) Date: Fri, 8 Mar 2024 17:17:02 +0000 From: Anthony PERARD To: Alex =?iso-8859-1?Q?Benn=E9e?= Cc: Marek =?iso-8859-1?Q?Marczykowski-G=F3recki?= , xen-devel@lists.xenproject.org, qemu-devel@nongnu.org Subject: Re: [PATCH] i386: load kernel on xen using DMA Message-ID: <5975d575-d800-4520-a1b9-278cf51d108c@perard> References: <20210426034709.595432-1-marmarek@invisiblethingslab.com> <87sg1feemf.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87sg1feemf.fsf@linaro.org> On Fri, Jun 18, 2021 at 09:54:14AM +0100, Alex Benne wrote: > > Marek Marczykowski-Grecki writes: > > > Kernel on Xen is loaded via fw_cfg. Previously it used non-DMA version, > > which loaded the kernel (and initramfs) byte by byte. Change this > > to DMA, to load in bigger chunks. > > This change alone reduces load time of a (big) kernel+initramfs from > > ~10s down to below 1s. > > > > This change was suggested initially here: > > https://lore.kernel.org/xen-devel/20180216204031.000052e9@gmail.com/ > > Apparently this alone is already enough to get massive speedup. > > > > Signed-off-by: Marek Marczykowski-Grecki > > --- > > hw/i386/pc.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/hw/i386/pc.c b/hw/i386/pc.c > > index 8a84b25a03..14e43d4da4 100644 > > --- a/hw/i386/pc.c > > +++ b/hw/i386/pc.c > > @@ -839,7 +839,8 @@ void xen_load_linux(PCMachineState *pcms) > > > > assert(MACHINE(pcms)->kernel_filename != NULL); > > > > - fw_cfg = fw_cfg_init_io(FW_CFG_IO_BASE); > > + fw_cfg = fw_cfg_init_io_dma(FW_CFG_IO_BASE, FW_CFG_IO_BASE + 4, > > + &address_space_memory); > > fw_cfg_add_i16(fw_cfg, FW_CFG_NB_CPUS, x86ms->boot_cpus); > > rom_set_fw(fw_cfg); > > Gentle ping. The fix looks perfectly sane to me but I don't have any x86 > Xen HW to test this one. Are the x86 maintainers happy to take this on? Yes. It looks like it works well with both SeaBIOS and OVMF, so the patch is good. > FWIW: > > Reviewed-by: Alex Benne Reviewed-by: Anthony PERARD Thanks, -- Anthony PERARD From xen-devel-bounces@lists.xenproject.org Fri Mar 08 17:22:15 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2024 17:22:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690365.1076278 (Exim 4.92) (envelope-from ) id 1ridv9-0003r0-09; Fri, 08 Mar 2024 17:22:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690365.1076278; Fri, 08 Mar 2024 17:22:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ridv8-0003qt-Tu; Fri, 08 Mar 2024 17:22:10 +0000 Received: by outflank-mailman (input) for mailman id 690365; Fri, 08 Mar 2024 17:22:09 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ridv7-0003ql-CL for xen-devel@lists.xenproject.org; Fri, 08 Mar 2024 17:22:09 +0000 Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [2a00:1450:4864:20::333]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 642ab14b-dd70-11ee-afda-a90da7624cb6; Fri, 08 Mar 2024 18:22:08 +0100 (CET) Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-4131b27cda2so5078795e9.0 for ; Fri, 08 Mar 2024 09:22:08 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 642ab14b-dd70-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709918528; x=1710523328; darn=lists.xenproject.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=jucViIz8xwJxIjrz/FZM/DDlB3DLqqBFRzm+RODn104=; b=e0CSeSXeLLIIX8BC/28pbCf4d1FYCIQF4KFbh0Z/e/mNEIJ2XyiPVAaKpGEsc79QSx Cnybls7GtAZPVFQj5Bz3pl+m8z4x1gzD7LN0d5qlQS0p1E78jzZIJcLCZcg7Y5zHfQfz 7abv+UaggYVq7XaeDRUNsan8kg7tdEbaO9tYUQaolVP6t3pj+9OyZEDgQQiSodfHMCvw mF21oe3syYUGl5J+b3lRkZqAz2y8LWylhYboKeyK9I8hTcZp9gJT17oKWu2vrqxte9H1 VzBYR6IgrEvHQF94xrRULd/sdYAxy5qNeSeZ9LzYMlsnKv59HDlsLOnTBZOE/227F6ij Ruqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709918528; x=1710523328; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=jucViIz8xwJxIjrz/FZM/DDlB3DLqqBFRzm+RODn104=; b=bdC8DjWHq4qLtICSdCUlS9UvjyLccLckBWbg6g2De2jf8FLBCAb1Opri9abRUSu8If aOZydzdkmcF3RW6BPOF85G9Pr+SCcp8r3EiMyt1OTWirDHSRk5X+Sa6FvsoZf5qOcNbd rAOhAnuVB+Lwc+jXEvC7JmuhzkuW/Ci5F7ZGWK7LxLHudq/JNnHcVYsc5CfxBoQigIRH kqhCBnDU9cDtalwEVl12cj0XxC+q44Wu02JN3iNr3wYoNHCg0MRxHFkhXKeKxSPfWckI Uf/MztNMULbgoIrrjNhTKdlkXPCpupLZpUKAhPrrPVudVHU7NIVa9FUAVXyfcP9G71pY TOZg== X-Forwarded-Encrypted: i=1; AJvYcCULoVXqcK76sdY6c0OTuCv1APw6/8IN2GqkhTB1ZgPAB8hmEhYKc2LUQ1Q3XEiXVcG8OcI77eou9XGXYn2xRpeadRVZOWqC0d9yyZ7uVN8= X-Gm-Message-State: AOJu0Yx7/fPHbJlHdvTVpNUN36mN0Yo5p7RPs9Qx8XAdmDA0K0xigOWh hvHXUjrg4/yp0e/Art1ZJShfbJUvUpaKBVyE6eqCB8R4KoI35emRlIBppEkEbALhDo6FWt5iEB+ 3tqC9fXq4VhdgE/CjycYCV6kSDO8= X-Google-Smtp-Source: AGHT+IEsyTvVxIZznYVc7DZoZGa2Ni1s/uRtj8TYmazDkx3DsdR9S3CA2W36uHp4bLl2A4XXQ6ZxfYXr1V2wkcErN0Q= X-Received: by 2002:a5d:670a:0:b0:33e:7c19:dec8 with SMTP id o10-20020a5d670a000000b0033e7c19dec8mr208779wru.21.1709918527648; Fri, 08 Mar 2024 09:22:07 -0800 (PST) MIME-Version: 1.0 References: <20240305030516.41519-1-alexei.starovoitov@gmail.com> <20240305030516.41519-2-alexei.starovoitov@gmail.com> <1f49d568-24f9-4003-b222-515f33a99cf2@samsung.com> In-Reply-To: <1f49d568-24f9-4003-b222-515f33a99cf2@samsung.com> From: Alexei Starovoitov Date: Fri, 8 Mar 2024 09:21:56 -0800 Message-ID: Subject: Re: [PATCH v4 bpf-next 1/2] mm: Enforce VM_IOREMAP flag and range in ioremap_page_range. To: Marek Szyprowski Cc: bpf , Daniel Borkmann , Andrii Nakryiko , Linus Torvalds , Barret Rhoden , Johannes Weiner , Lorenzo Stoakes , Andrew Morton , Uladzislau Rezki , Christoph Hellwig , Mike Rapoport , Boris Ostrovsky , sstabellini@kernel.org, Juergen Gross , linux-mm , xen-devel@lists.xenproject.org, Kernel Team Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Mar 8, 2024 at 9:14=E2=80=AFAM Marek Szyprowski wrote: > > On 05.03.2024 04:05, Alexei Starovoitov wrote: > > From: Alexei Starovoitov > > > > There are various users of get_vm_area() + ioremap_page_range() APIs. > > Enforce that get_vm_area() was requested as VM_IOREMAP type and range > > passed to ioremap_page_range() matches created vm_area to avoid > > accidentally ioremap-ing into wrong address range. > > > > Reviewed-by: Christoph Hellwig > > Signed-off-by: Alexei Starovoitov > > --- > > This patch landed in today's linux-next as commit 3e49a866c9dc ("mm: > Enforce VM_IOREMAP flag and range in ioremap_page_range."). > Unfortunately it triggers the following warning on all my test machines > with PCI bridges. Here is an example reproduced with QEMU and ARM64 > 'virt' machine: Sorry about the breakage. Here is the thread where we're discussing the fix: https://lore.kernel.org/bpf/CAADnVQLP=3DdxBb+RiMGXoaCEuRrbK387J6B+pfzWKF_F= =3DaRgCPQ@mail.gmail.com/ From xen-devel-bounces@lists.xenproject.org Fri Mar 08 17:35:27 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2024 17:35:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690370.1076292 (Exim 4.92) (envelope-from ) id 1rie7q-0006ED-5K; Fri, 08 Mar 2024 17:35:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690370.1076292; Fri, 08 Mar 2024 17:35:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rie7q-0006E6-1b; Fri, 08 Mar 2024 17:35:18 +0000 Received: by outflank-mailman (input) for mailman id 690370; Fri, 08 Mar 2024 17:35:17 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rie7p-0006Dz-An for xen-devel@lists.xenproject.org; Fri, 08 Mar 2024 17:35:17 +0000 Received: from mail-oo1-xc2a.google.com (mail-oo1-xc2a.google.com [2607:f8b0:4864:20::c2a]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 3940fe07-dd72-11ee-afda-a90da7624cb6; Fri, 08 Mar 2024 18:35:16 +0100 (CET) Received: by mail-oo1-xc2a.google.com with SMTP id 006d021491bc7-5a17a739935so1320168eaf.1 for ; Fri, 08 Mar 2024 09:35:16 -0800 (PST) Received: from perard.uk.xensource.com (default-46-102-197-194.interdsl.co.uk. [46.102.197.194]) by smtp.gmail.com with ESMTPSA id z5-20020a05683020c500b006e12266433csm2248064otq.27.2024.03.08.09.35.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 Mar 2024 09:35:14 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3940fe07-dd72-11ee-afda-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1709919314; x=1710524114; darn=lists.xenproject.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=42z1c6En4OMO73HSWbt9qhFCGOY4c7z3vfsZqA96K6s=; b=FgsYw5pQ1bzlE8obkLOtIg0GLrJ8DKrUJOPcHKo6bfrVTyVAwXti3hPV6rZDMGfC0O 54aXCBKs8x9F/5ZOeLHLSEBQ/Io6c7il9Do+aA25WYWZX1pqrwcptOZYaYLy7XvBIwcw 1xwihDKE4+lODR13gx8avxEnYuQlliYlKiKCA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709919314; x=1710524114; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=42z1c6En4OMO73HSWbt9qhFCGOY4c7z3vfsZqA96K6s=; b=VY6npIeBk+nmWgEGGyS5nT1mRC8/rPx7yzEuG4rTWOiSTjvrVQtc0GrtmkdyxPUOoE xaRQt3Rp9b+rOltTR9WFNT6B7lXKvmlc5riMASX6pe2i09YXY0mBlRoKwZ6W0t7GVkk6 gYvybbObvZoLnNqIKWVoxPOccIvscs2QCcEvKp0NJuq2Wl65ZmpK5gsWmYOgzv2E/jLB MYwCblK0/msNTRCDh67WOuBGluSdF+cfLxRs6NZWO8UtAQJjf+z6l5scCJHBfiR4dMoY m/bYZ9oPi6h1vGHb2WoERhECcQjAlfDfmixfXs8xwQ5vWfEyREJ4tHePYnE6D8hb7X00 eBmw== X-Forwarded-Encrypted: i=1; AJvYcCUztK4UOQPVtbXE7zlgewecj5UNLV6wy/fiBN4mPXbGcpNqI1mVNav9T+fYN4fRrgNhlYAROZ39Jcmzak11laoEIYs0lXtMEVAPexbwxwI= X-Gm-Message-State: AOJu0Yx5f2z2iWiDkvCGWakphMz3VikC8EFF6dUlkSdKnrKYVowWYjqM u6oyZnljPY8ydSeQSgDDJs97xtztS14sxBJaHocxXZ7ztKYgSKZ0l5P46cTvUoA= X-Google-Smtp-Source: AGHT+IFP+iIn7ziPACo/W5ywuwt3jU9vKOJI+Md4melHw3m+IPRBayOOv3MnfyWInvHuBqQD34WXQg== X-Received: by 2002:a05:6820:2227:b0:5a1:34cf:400c with SMTP id cj39-20020a056820222700b005a134cf400cmr12525786oob.9.1709919314653; Fri, 08 Mar 2024 09:35:14 -0800 (PST) Date: Fri, 8 Mar 2024 17:35:08 +0000 From: Anthony PERARD To: Philippe =?iso-8859-1?Q?Mathieu-Daud=E9?= Cc: qemu-devel@nongnu.org, qemu-riscv@nongnu.org, qemu-s390x@nongnu.org, Paolo Bonzini , kvm@vger.kernel.org, qemu-ppc@nongnu.org, qemu-arm@nongnu.org, Richard Henderson , Zhao Liu , Mark Cave-Ayland , "Michael S. Tsirkin" , Marcel Apfelbaum , =?iso-8859-1?Q?C=E9dric?= Le Goater , Nicholas Piggin , =?iso-8859-1?Q?Fr=E9d=E9ric?= Barrat , Alex =?iso-8859-1?Q?Benn=E9e?= , Viresh Kumar , mzamazal@redhat.com, Stefano Stabellini , Paul Durrant , Peter Xu , Fabiano Rosas , Peter Maydell , Cameron Esfahani , Roman Bolshakov , Laurent Vivier , Daniel Henrique Barboza , Palmer Dabbelt , Alistair Francis , Bin Meng , Weiwei Li , Liu Zhiwei , xen-devel@lists.xenproject.org Subject: Re: [PATCH v3 01/29] bulk: Access existing variables initialized to &S->F when available Message-ID: References: <20240129164514.73104-1-philmd@linaro.org> <20240129164514.73104-2-philmd@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20240129164514.73104-2-philmd@linaro.org> On Mon, Jan 29, 2024 at 05:44:43PM +0100, Philippe Mathieu-Daud wrote: > When a variable is initialized to &struct->field, use it > in place. Rationale: while this makes the code more concise, > this also helps static analyzers. > > Mechanical change using the following Coccinelle spatch script: > > @@ > type S, F; > identifier s, m, v; > @@ > S *s; > ... > F *v = &s->m; > <+... > - &s->m > + v > ...+> > > Inspired-by: Zhao Liu > Signed-off-by: Philippe Mathieu-Daud > --- > diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c > index 36e6f93c37..10ddf6bc91 100644 > --- a/hw/xen/xen_pt.c > +++ b/hw/xen/xen_pt.c > @@ -710,7 +710,7 @@ static void xen_pt_destroy(PCIDevice *d) { > uint8_t intx; > int rc; > > - if (machine_irq && !xen_host_pci_device_closed(&s->real_device)) { > + if (machine_irq && !xen_host_pci_device_closed(host_dev)) { > intx = xen_pt_pci_intx(s); > rc = xc_domain_unbind_pt_irq(xen_xc, xen_domid, machine_irq, > PT_IRQ_TYPE_PCI, > @@ -759,8 +759,8 @@ static void xen_pt_destroy(PCIDevice *d) { > memory_listener_unregister(&s->io_listener); > s->listener_set = false; > } > - if (!xen_host_pci_device_closed(&s->real_device)) { > - xen_host_pci_device_put(&s->real_device); > + if (!xen_host_pci_device_closed(host_dev)) { > + xen_host_pci_device_put(host_dev); For the Xen part: Reviewed-by: Anthony PERARD Thanks, -- Anthony PERARD From xen-devel-bounces@lists.xenproject.org Fri Mar 08 22:30:28 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2024 22:30:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690408.1076344 (Exim 4.92) (envelope-from ) id 1riij9-0004wf-0S; Fri, 08 Mar 2024 22:30:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690408.1076344; Fri, 08 Mar 2024 22:30:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riij8-0004wY-TR; Fri, 08 Mar 2024 22:30:06 +0000 Received: by outflank-mailman (input) for mailman id 690408; Fri, 08 Mar 2024 22:30:05 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riij7-0004qW-JQ for xen-devel@lists.xenproject.org; Fri, 08 Mar 2024 22:30:05 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riij7-0003WK-4X; Fri, 08 Mar 2024 22:30:05 +0000 Received: from gw1.octic.net ([88.97.20.152] helo=[10.0.1.193]) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1riij6-0008NY-QY; Fri, 08 Mar 2024 22:30:04 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID; bh=ut4po0fGiouZP8lbowdSquir9Zb3msRU+4o4fMADWTc=; b=hZCavOFpNCmHyWd8bZDiBBydUg JutA5eAViYfrWVjw2KI5R2Wdodx5CEuRZy8aO39+Ze6QN00ecNLqy0Yh/bbc+Lt6UdoVMZZ7SOs8X pa4uGiPu2CrGd2mh9BAT9bkDdRdloufSpiFyuFMI3N6DxW3F9JYljqXLKC3jKQeZ9BPk=; Message-ID: <1439263a-c96d-48bb-bd3c-1427071ecd17@xen.org> Date: Fri, 8 Mar 2024 22:30:03 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 13/15] xen/arm: make consider_modules() available for xen relocation Content-Language: en-GB To: Carlo Nonato , xen-devel@lists.xenproject.org Cc: andrea.bastoni@minervasys.tech, Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Henry Wang , Ayan Kumar Halder References: <20240129171811.21382-1-carlo.nonato@minervasys.tech> <20240129171811.21382-14-carlo.nonato@minervasys.tech> From: Julien Grall In-Reply-To: <20240129171811.21382-14-carlo.nonato@minervasys.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit (+ Ayan + Henry) Hi Carlo, On 29/01/2024 17:18, Carlo Nonato wrote: > Cache coloring must physically relocate Xen in order to color the hypervisor > and consider_modules() is a key function that is needed to find a new > available physical address. > > 672d67f339c0 ("xen/arm: Split MMU-specific setup_mm() and related code out") > moved consider_modules() under arm32. Move it back to setup.c and make it > non-static so that it can be used outside. > > Signed-off-by: Carlo Nonato > --- > v6: > - new patch > --- > xen/arch/arm/arm32/mmu/mm.c | 93 +------------------------------- > xen/arch/arm/include/asm/setup.h | 3 ++ > xen/arch/arm/setup.c | 92 +++++++++++++++++++++++++++++++ Ayan, Henry, will the function consider_modules() be used for the MPU code? If not, then I think the function should live in arm/mmu/setup.c. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Fri Mar 08 23:01:04 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2024 23:01:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690413.1076360 (Exim 4.92) (envelope-from ) id 1rijCx-0001WH-44; Fri, 08 Mar 2024 23:00:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690413.1076360; Fri, 08 Mar 2024 23:00:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rijCx-0001WA-1I; Fri, 08 Mar 2024 23:00:55 +0000 Received: by outflank-mailman (input) for mailman id 690413; Fri, 08 Mar 2024 23:00:53 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rijCv-0001W4-ER for xen-devel@lists.xenproject.org; Fri, 08 Mar 2024 23:00:53 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rijCv-00045Y-0Y; Fri, 08 Mar 2024 23:00:53 +0000 Received: from gw1.octic.net ([88.97.20.152] helo=[10.0.1.193]) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1rijCu-0001dQ-KY; Fri, 08 Mar 2024 23:00:52 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID; bh=bc/IZ4AQvBbxrIptymI6T8NPQr21T6cU63Qn1bPFCG0=; b=JymAW1rY//dSiEi0wElrfjjG/L UAqfL/sNLRlUAFrCJC0uwW9/OTsbzK8BBriA0RaWUe49Arx9vTcV2MAbh+griEXHfUSPM4r+2lg3Z iPIqsBRs6F3bJ2rnCHZ8OhRgMi4AkPD8mAiB/DFod/dcJNvQk70krwlj2GTBRoQV5msE=; Message-ID: <8e4677a7-0550-4f02-aa7a-3f499f955cb3@xen.org> Date: Fri, 8 Mar 2024 23:00:50 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 14/15] xen/arm: add cache coloring support for Xen Content-Language: en-GB To: Carlo Nonato , xen-devel@lists.xenproject.org Cc: andrea.bastoni@minervasys.tech, Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , George Dunlap , Jan Beulich , Wei Liu , Marco Solieri References: <20240129171811.21382-1-carlo.nonato@minervasys.tech> <20240129171811.21382-15-carlo.nonato@minervasys.tech> From: Julien Grall In-Reply-To: <20240129171811.21382-15-carlo.nonato@minervasys.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Carlo, On 29/01/2024 17:18, Carlo Nonato wrote: > diff --git a/xen/arch/arm/arm64/mmu/head.S b/xen/arch/arm/arm64/mmu/head.S > index fa40b696dd..7926849ab1 100644 > --- a/xen/arch/arm/arm64/mmu/head.S > +++ b/xen/arch/arm/arm64/mmu/head.S > @@ -427,6 +427,60 @@ fail: PRINT("- Boot failed -\r\n") > b 1b > ENDPROC(fail) > > +/* > + * Copy Xen to new location and switch TTBR > + * x0 ttbr > + * x1 source address > + * x2 destination address > + * x3 length > + * > + * Source and destination must be word aligned, length is rounded up > + * to a 16 byte boundary. > + * > + * MUST BE VERY CAREFUL when saving things to RAM over the copy > + */ > +ENTRY(relocate_xen) > + /* > + * Copy 16 bytes at a time using: > + * x9: counter > + * x10: data > + * x11: data > + * x12: source > + * x13: destination > + */ > + mov x9, x3 > + mov x12, x1 > + mov x13, x2 > + > +1: ldp x10, x11, [x12], #16 > + stp x10, x11, [x13], #16 > + > + subs x9, x9, #16 > + bgt 1b > + > + /* > + * Flush destination from dcache using: > + * x9: counter > + * x10: step > + * x11: vaddr > + * > + * This is to ensure data is visible to the instruction cache > + */ > + dsb sy > + > + mov x9, x3 > + ldr x10, =dcache_line_bytes /* x10 := step */ > + ldr x10, [x10] > + mov x11, x2 > + > +1: dc cvac, x11 > + > + add x11, x11, x10 > + subs x9, x9, x10 > + bgt 1b > + I would add a comment here explaining you are relying on the dsb/isb in switch_ttbr_id(). > + b switch_ttbr_id > + > /* > * Switch TTBR > * > @@ -452,7 +506,8 @@ ENTRY(switch_ttbr_id) > > /* > * 5) Flush I-cache > - * This should not be necessary but it is kept for safety. > + * This should not be necessary in the general case, but it's needed > + * for cache coloring because in that case code is relocated. I think there is missing "because" just after "in that case". > */ > ic iallu > isb > diff --git a/xen/arch/arm/arm64/mmu/mm.c b/xen/arch/arm/arm64/mmu/mm.c > index d2651c9486..07cf8040a2 100644 > --- a/xen/arch/arm/arm64/mmu/mm.c > +++ b/xen/arch/arm/arm64/mmu/mm.c > @@ -1,6 +1,7 @@ > /* SPDX-License-Identifier: GPL-2.0 */ > > #include > +#include > #include > #include > > @@ -125,27 +126,46 @@ void update_identity_mapping(bool enable) > } > > extern void switch_ttbr_id(uint64_t ttbr); > +extern void relocate_xen(uint64_t ttbr, void *src, void *dst, size_t len); > > typedef void (switch_ttbr_fn)(uint64_t ttbr); > +typedef void (relocate_xen_fn)(uint64_t ttbr, void *src, void *dst, size_t len); > > void __init switch_ttbr(uint64_t ttbr) > { > - vaddr_t id_addr = virt_to_maddr(switch_ttbr_id); > - switch_ttbr_fn *fn = (switch_ttbr_fn *)id_addr; > + vaddr_t vaddr, id_addr; > lpae_t pte; > > + if ( llc_coloring_enabled ) > + vaddr = (vaddr_t)relocate_xen; > + else > + vaddr = (vaddr_t)switch_ttbr_id; > + > + id_addr = virt_to_maddr(vaddr); > + > /* Enable the identity mapping in the boot page tables */ > update_identity_mapping(true); > > /* Enable the identity mapping in the runtime page tables */ > - pte = pte_of_xenaddr((vaddr_t)switch_ttbr_id); > + pte = pte_of_xenaddr(vaddr); > pte.pt.table = 1; > pte.pt.xn = 0; > pte.pt.ro = 1; > write_pte(&xen_third_id[third_table_offset(id_addr)], pte); > > /* Switch TTBR */ > - fn(ttbr); > + if ( llc_coloring_enabled ) > + { > + relocate_xen_fn *fn = (relocate_xen_fn *)id_addr; > + > + fn(ttbr, _start, (void *)BOOT_RELOC_VIRT_START, _end - _start); > + } > + else > + { > + switch_ttbr_fn *fn = (switch_ttbr_fn *)id_addr; > + > + fn(ttbr); > + } > > /* > * Disable the identity mapping in the runtime page tables. > diff --git a/xen/arch/arm/include/asm/mmu/layout.h b/xen/arch/arm/include/asm/mmu/layout.h > index a3b546465b..7228c9fb82 100644 > --- a/xen/arch/arm/include/asm/mmu/layout.h > +++ b/xen/arch/arm/include/asm/mmu/layout.h > @@ -30,6 +30,7 @@ > * 10M - 12M Fixmap: special-purpose 4K mapping slots > * 12M - 16M Early boot mapping of FDT > * 16M - 18M Livepatch vmap (if compiled in) > + * 16M - 22M Cache-colored Xen text, data, bss (temporary, if compiled in) > * > * 1G - 2G VMAP: ioremap and early_ioremap > * > @@ -74,6 +75,8 @@ > #define BOOT_FDT_VIRT_START (FIXMAP_VIRT_START + FIXMAP_VIRT_SIZE) > #define BOOT_FDT_VIRT_SIZE _AT(vaddr_t, MB(4)) > > +#define BOOT_RELOC_VIRT_START (BOOT_FDT_VIRT_START + BOOT_FDT_VIRT_SIZE) > + > #ifdef CONFIG_LIVEPATCH > #define LIVEPATCH_VMAP_START (BOOT_FDT_VIRT_START + BOOT_FDT_VIRT_SIZE) > #define LIVEPATCH_VMAP_SIZE _AT(vaddr_t, MB(2)) > diff --git a/xen/arch/arm/llc-coloring.c b/xen/arch/arm/llc-coloring.c > index eee1e80e2d..bbb39214a8 100644 > --- a/xen/arch/arm/llc-coloring.c > +++ b/xen/arch/arm/llc-coloring.c > @@ -9,6 +9,7 @@ > > #include > #include > +#include > > /* Return the LLC way size by probing the hardware */ > unsigned int __init get_llc_way_size(void) > @@ -62,7 +63,65 @@ unsigned int __init get_llc_way_size(void) > return line_size * num_sets; > } > > -void __init arch_llc_coloring_init(void) {} > +/** > + * get_xen_paddr - get physical address to relocate Xen to > + * > + * Xen is relocated to as near to the top of RAM as possible and > + * aligned to a XEN_PADDR_ALIGN boundary. > + */ > +static paddr_t __init get_xen_paddr(uint32_t xen_size) AFAICT, xen_size will be the size of a color. Is it possible that this will be bigger than 4GB? If so, this needs to be converted to a paddr_t. > +{ > + struct meminfo *mi = &bootinfo.mem; AFAICT, you are not modifying meminfo. So this can be const. > + paddr_t min_size; > + paddr_t paddr = 0; > + int i; unsigned int please. I understand this is re-imported previous code, but we should avoid re-introduce issues with it. > + > + min_size = (xen_size + (XEN_PADDR_ALIGN-1)) & ~(XEN_PADDR_ALIGN-1); coding style: space before/after -. > + > + /* Find the highest bank with enough space. */ > + for ( i = 0; i < mi->nr_banks; i++ ) > + { > + const struct membank *bank = &mi->bank[i]; > + paddr_t s, e; > + > + if ( bank->size >= min_size ) > + { > + e = consider_modules(bank->start, bank->start + bank->size, > + min_size, XEN_PADDR_ALIGN, 0); > + if ( !e ) > + continue; > + > +#ifdef CONFIG_ARM_32 > + /* Xen must be under 4GB */ > + if ( e > 0x100000000ULL ) > + e = 0x100000000ULL; Can you replace with GB(4)? This makes easier to confirm the constant are correct. > + if ( e < bank->start ) > + continue; > +#endif > + > + s = e - min_size; > + > + if ( s > paddr ) > + paddr = s; > + } > + } > + > + if ( !paddr ) > + panic("Not enough memory to relocate Xen\n"); > + > + printk("Placing Xen at 0x%"PRIpaddr"-0x%"PRIpaddr"\n", > + paddr, paddr + min_size); > + > + return paddr; > +} > + > +void __init arch_llc_coloring_init(void) > +{ > + struct bootmodule *xen_bootmodule = boot_module_find_by_kind(BOOTMOD_XEN); I would add BUG_ON(xen_bootmodule). This would make it easier that trying to figure a NULL pointer dereference. > + > + xen_bootmodule->size = xen_colored_map_size(); > + xen_bootmodule->start = get_xen_paddr(xen_bootmodule->size); > +} > > /* > * Local variables: > diff --git a/xen/arch/arm/mmu/setup.c b/xen/arch/arm/mmu/setup.c > index 72725840b6..f3e4f6c304 100644 > --- a/xen/arch/arm/mmu/setup.c > +++ b/xen/arch/arm/mmu/setup.c > @@ -7,6 +7,7 @@ > > #include > #include > +#include > #include > #include > > @@ -15,6 +16,11 @@ > /* Override macros from asm/page.h to make them work with mfn_t */ > #undef mfn_to_virt > #define mfn_to_virt(mfn) __mfn_to_virt(mfn_x(mfn)) > +#undef virt_to_mfn > +#define virt_to_mfn(va) _mfn(__virt_to_mfn(va)) > + > +#define virt_to_reloc_virt(virt) \ > + (((vaddr_t)virt) - XEN_VIRT_START + BOOT_RELOC_VIRT_START) > > /* Main runtime page tables */ > > @@ -69,6 +75,7 @@ static void __init __maybe_unused build_assertions(void) > /* 2MB aligned regions */ > BUILD_BUG_ON(XEN_VIRT_START & ~SECOND_MASK); > BUILD_BUG_ON(FIXMAP_ADDR(0) & ~SECOND_MASK); > + BUILD_BUG_ON(BOOT_RELOC_VIRT_START & ~SECOND_MASK); > /* 1GB aligned regions */ > #ifdef CONFIG_ARM_32 > BUILD_BUG_ON(XENHEAP_VIRT_START & ~FIRST_MASK); > @@ -132,7 +139,12 @@ static void __init __maybe_unused build_assertions(void) > > lpae_t __init pte_of_xenaddr(vaddr_t va) > { > - paddr_t ma = va + phys_offset; > + paddr_t ma; > + > + if ( llc_coloring_enabled ) > + ma = virt_to_maddr(virt_to_reloc_virt(va)); > + else > + ma = va + phys_offset; > > return mfn_to_xen_entry(maddr_to_mfn(ma), MT_NORMAL); > } > @@ -218,9 +230,44 @@ static void xen_pt_enforce_wnx(void) > flush_xen_tlb_local(); > } > > +static void __init create_llc_coloring_mappings(void) > +{ > + lpae_t pte; > + unsigned int i; > + struct bootmodule *xen_bootmodule = boot_module_find_by_kind(BOOTMOD_XEN); Please add a BUILD_BUG_ON() just to confirm xen_bootmodule is not NULL. > + mfn_t mfn = maddr_to_mfn(xen_bootmodule->start); > + > + for_each_xen_colored_mfn( mfn, i ) > + { > + pte = mfn_to_xen_entry(mfn, MT_NORMAL); > + pte.pt.table = 1; /* level 3 mappings always have this bit set */ > + xen_xenmap[i] = pte; > + } > + > + for ( i = 0; i < XEN_NR_ENTRIES(2); i++ ) > + { > + vaddr_t va = BOOT_RELOC_VIRT_START + (i << XEN_PT_LEVEL_SHIFT(2)); > + > + pte = mfn_to_xen_entry(virt_to_mfn(xen_xenmap + > + i * XEN_PT_LPAE_ENTRIES), > + MT_NORMAL); > + pte.pt.table = 1; > + write_pte(&boot_second[second_table_offset(va)], pte); > + } > +} > + > /* > - * Boot-time pagetable setup. > + * Boot-time pagetable setup with coloring support > * Changes here may need matching changes in head.S > + * > + * The cache coloring support consists of: > + * - Create colored mapping that conforms to Xen color selection in xen_xenmap[] > + * - Link the mapping in boot page tables using BOOT_RELOC_VIRT_START as vaddr > + * - pte_of_xenaddr() takes care of translating addresses to the new space > + * during runtime page tables creation > + * - Relocate xen and update TTBR with the new address in the colored space > + * (see switch_ttbr()) > + * - Protect the new space > */ > void __init setup_pagetables(unsigned long boot_phys_offset) > { > @@ -230,6 +277,9 @@ void __init setup_pagetables(unsigned long boot_phys_offset) > > phys_offset = boot_phys_offset; > > + if ( llc_coloring_enabled ) > + create_llc_coloring_mappings(); > + > arch_setup_page_tables(); > > #ifdef CONFIG_ARM_64 > @@ -257,13 +307,7 @@ void __init setup_pagetables(unsigned long boot_phys_offset) > break; > pte = pte_of_xenaddr(va); > pte.pt.table = 1; /* third level mappings always have this bit set */ > - if ( is_kernel_text(va) || is_kernel_inittext(va) ) > - { > - pte.pt.xn = 0; > - pte.pt.ro = 1; > - } > - if ( is_kernel_rodata(va) ) > - pte.pt.ro = 1; > + pte.pt.xn = 0; /* Permissions will be enforced later. Allow execution */ I feel this patch contains a lot of change that are cache coloring specific but somewhat different. I think you could have split in a more piece meal one which would have made the review easier. No need to split this patch now, but if there are more place to change, then please consider to do them in separate patches. > xen_xenmap[i] = pte; > } > > @@ -289,8 +333,43 @@ void __init setup_pagetables(unsigned long boot_phys_offset) > ttbr = (uintptr_t) cpu0_pgtable + phys_offset; > #endif > > + if ( llc_coloring_enabled ) > + ttbr = virt_to_maddr(virt_to_reloc_virt(THIS_CPU_PGTABLE)); You are using THIS_CPU_PGTABLE here, but technically it is only valid after #ifdef CONFIG_ARM_32 per_cpu(xen_pgtable, ...) = ... #endif AFAICT, you haven't moved it. > + > switch_ttbr(ttbr); > > + /* Protect Xen */ > + for ( i = 0; i < XEN_NR_ENTRIES(3); i++ ) > + { > + vaddr_t va = XEN_VIRT_START + (i << PAGE_SHIFT); > + lpae_t *entry = xen_xenmap + i; > + > + if ( !is_kernel(va) ) > + break; > + > + pte = read_atomic(entry); > + > + if ( is_kernel_text(va) || is_kernel_inittext(va) ) > + { > + pte.pt.xn = 0; > + pte.pt.ro = 1; > + } else if ( is_kernel_rodata(va) ) { > + pte.pt.ro = 1; > + pte.pt.xn = 1; > + } else { > + pte.pt.xn = 1; > + pte.pt.ro = 0; > + } > + > + write_pte(entry, pte); > + } > + > + /* > + * We modified live page-tables. Ensure the TBLs are invalidated s/TBLs/TLBs/ > + * before setting enforcing the WnX permissions. > + */ > + flush_xen_tlb_local(); > + > xen_pt_enforce_wnx(); > > #ifdef CONFIG_ARM_32 > diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c > index 28f4761705..64a449f78d 100644 > --- a/xen/arch/arm/setup.c > +++ b/xen/arch/arm/setup.c > @@ -816,8 +816,6 @@ void asmlinkage __init start_xen(unsigned long boot_phys_offset, > /* Initialize traps early allow us to get backtrace when an error occurred */ > init_traps(); > > - setup_pagetables(boot_phys_offset); > - > smp_clear_cpu_maps(); > > device_tree_flattened = early_fdt_map(fdt_paddr); > @@ -841,6 +839,9 @@ void asmlinkage __init start_xen(unsigned long boot_phys_offset, > > llc_coloring_init(); > > + setup_pagetables(boot_phys_offset); Please add a comment on top explaining that setup_pagetables() relies on the cache coloring feature to be initalized. > + device_tree_flattened = early_fdt_map(fdt_paddr); I understand why you are calling early_fdt_map(). But it reads odd that this is called twice. I think you want to explain in a comment why this is called again and why we don't unmap the previous one. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Fri Mar 08 23:03:49 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2024 23:03:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690415.1076370 (Exim 4.92) (envelope-from ) id 1rijFk-00024j-If; Fri, 08 Mar 2024 23:03:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690415.1076370; Fri, 08 Mar 2024 23:03:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rijFk-00024c-ER; Fri, 08 Mar 2024 23:03:48 +0000 Received: by outflank-mailman (input) for mailman id 690415; Fri, 08 Mar 2024 23:03:47 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rijFj-00024R-Gi for xen-devel@lists.xenproject.org; Fri, 08 Mar 2024 23:03:47 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rijFj-00048E-9F; Fri, 08 Mar 2024 23:03:47 +0000 Received: from gw1.octic.net ([88.97.20.152] helo=[10.0.1.193]) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1rijFj-0001m0-4N; Fri, 08 Mar 2024 23:03:47 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID; bh=HkmVvyzi/bmdSNj+nB7BW0i7l0s7STdV+hLaTQjGULI=; b=YASpvM5IY97lvZUg87/sELzPVu GiC6rqNQFYjRMF47xH1kAv33O3uMolGCNkZ36XDHaE0qG8KwjniI6idZ5MxtsaRAF52haYJbNmxii z4djTR0zBz26AEcj6oTG5pEdnAW3pFxv6d528DzTVqM2An3AOx+/HNvtxFQsxc5MxGsY=; Message-ID: Date: Fri, 8 Mar 2024 23:03:45 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 15/15] support: add cache coloring arm64 experimental feature Content-Language: en-GB To: Carlo Nonato , xen-devel@lists.xenproject.org Cc: andrea.bastoni@minervasys.tech, Andrew Cooper , George Dunlap , Jan Beulich , Stefano Stabellini , Wei Liu References: <20240129171811.21382-1-carlo.nonato@minervasys.tech> <20240129171811.21382-16-carlo.nonato@minervasys.tech> From: Julien Grall In-Reply-To: <20240129171811.21382-16-carlo.nonato@minervasys.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Carlo, On 29/01/2024 17:18, Carlo Nonato wrote: > Signed-off-by: Carlo Nonato > --- > v6: > - new patch > --- > SUPPORT.md | 7 +++++++ I would consider to fold it in patch #1. So we could potentially to start committing the series. In any case: Acked-by: Julien Grall Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Sat Mar 09 00:01:08 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 09 Mar 2024 00:01:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690422.1076385 (Exim 4.92) (envelope-from ) id 1rik92-00041E-JS; Sat, 09 Mar 2024 00:00:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690422.1076385; Sat, 09 Mar 2024 00:00:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rik92-000417-Gi; Sat, 09 Mar 2024 00:00:56 +0000 Received: by outflank-mailman (input) for mailman id 690422; Sat, 09 Mar 2024 00:00:54 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rik90-00040v-GN; Sat, 09 Mar 2024 00:00:54 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rik90-0005hk-DA; Sat, 09 Mar 2024 00:00:54 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rik90-0003Bw-33; Sat, 09 Mar 2024 00:00:54 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rik90-0000nT-2R; Sat, 09 Mar 2024 00:00:54 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=QiOmxm53tZJwFGqF+bI1YAx1pwjmbcc9cVtD0tBTFIM=; b=Cm4ytvAfeUw3lsN/Xo11/iCFXN zXWsbzeudZ2hEUP55fHl5MjQ4NtOyppG1OVg/Y3Bg6Tq31W5iyEry2O+bFieK0mZ4jYMlGOl7o6hW ipeMrUo66Na2EvSERCVQzM1eNRpBUeWjp0Gtt1hH2dPx7LrRF1EW4eN8RLYzMsRGS1E0=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-linus test] 184942: tolerable FAIL - PUSHED X-Osstest-Failures: linux-linus:test-amd64-amd64-freebsd11-amd64:guest-localmigrate/x10:fail:heisenbug linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: linux=3aaa8ce7a3350d95b241046ae2401103a4384ba2 X-Osstest-Versions-That: linux=67be068d31d423b857ffd8c34dbcc093f8dfff76 From: osstest service owner Date: Sat, 09 Mar 2024 00:00:54 +0000 flight 184942 linux-linus real [real] flight 184958 linux-linus real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/184942/ http://logs.test-lab.xenproject.org/osstest/logs/184958/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-freebsd11-amd64 19 guest-localmigrate/x10 fail pass in 184958-retest Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop fail like 184931 test-armhf-armhf-libvirt 16 saverestore-support-check fail like 184931 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop fail like 184931 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop fail like 184931 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 184931 test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail like 184931 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop fail like 184931 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184931 test-amd64-amd64-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl 15 migrate-support-check fail never pass test-arm64-arm64-xl 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 15 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 15 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 15 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-check fail never pass test-armhf-armhf-libvirt 15 migrate-support-check fail never pass test-amd64-amd64-libvirt-qcow2 14 migrate-support-check fail never pass test-amd64-amd64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-check fail never pass test-arm64-arm64-xl-vhd 14 migrate-support-check fail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-check fail never pass version targeted for testing: linux 3aaa8ce7a3350d95b241046ae2401103a4384ba2 baseline version: linux 67be068d31d423b857ffd8c34dbcc093f8dfff76 Last test of basis 184931 2024-03-07 12:02:46 Z 1 days Testing same since 184942 2024-03-08 07:27:45 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Alan Brady Alexei Starovoitov Andrew Ballance Andrew Morton Arnd Bergmann Aya Levin Chandan Kumar Rout (A Contingent Worker at Intel) Charles Keepax Daniel Borkmann David S. Miller Eduard Zingerman Edward Adam Davis Emeel Hakim Emil Tantilov Eric Dumazet Florian Kauer Florian Westphal Gao Xiang Gavin Li Geliang Tang Guillaume Nault Horatiu Vultur Ilias Apalodimas Ivan Vecera Jacob Keller Jakub Kicinski Jason Xing Jesse Brandeburg Jianbo Liu Karthikeyan Ramasubramanian Kees Cook Krishneil Singh Lena Wang Leon Romanovsky Linus Torvalds Maciej Fijalkowski Magnus Karlsson Mark Brown Martin KaFai Lau Masahisa Kojima Matthieu Baerts (NGI0) Michal Schmidt Michal Swiatkowski Mike Yu Moshe Shemesh Naama Meir Nathan Chancellor Niklas Cassel Niklas Söderlund Oleksij Rempel Pablo Neira Ayuso Paolo Abeni Puranjay Mohan Qi Zheng Quentin Schulz Rafal Romanowski Rahul Rameshbabu Rand Deeb Saeed Mahameed Sasha Neftin Steffen Klassert Steven Rostedt (Google) Tobias Jakobi (Compleo) Toke Høiland-Jørgensen Tony Nguyen Vlastimil Babka Will Deacon Yonghong Song Yongzhi Liu jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-amd64-dom0pvh-xl-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-freebsd11-amd64 fail test-amd64-amd64-freebsd12-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-examine-bios pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-amd64-dom0pvh-xl-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-amd64-xl-pvshim pass test-amd64-amd64-pygrub pass test-amd64-amd64-libvirt-qcow2 pass test-armhf-armhf-libvirt-qcow2 pass test-amd64-amd64-libvirt-raw pass test-arm64-arm64-libvirt-raw pass test-armhf-armhf-libvirt-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-examine-uefi pass test-amd64-amd64-xl-vhd pass test-arm64-arm64-xl-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these 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 : hint: The 'hooks/update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-receive' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. To xenbits.xen.org:/home/xen/git/linux-pvops.git 67be068d31d42..3aaa8ce7a3350 3aaa8ce7a3350d95b241046ae2401103a4384ba2 -> tested/linux-linus From xen-devel-bounces@lists.xenproject.org Sat Mar 09 01:17:27 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 09 Mar 2024 01:17:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690436.1076407 (Exim 4.92) (envelope-from ) id 1rilKp-0004po-SO; Sat, 09 Mar 2024 01:17:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690436.1076407; Sat, 09 Mar 2024 01:17:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rilKp-0004ph-P1; Sat, 09 Mar 2024 01:17:11 +0000 Received: by outflank-mailman (input) for mailman id 690436; Sat, 09 Mar 2024 01:17:10 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rilKo-0004pb-Aj for xen-devel@lists.xenproject.org; Sat, 09 Mar 2024 01:17:10 +0000 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id be63f0cb-ddb2-11ee-afdb-a90da7624cb6; Sat, 09 Mar 2024 02:17:08 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 73E6860EC0; Sat, 9 Mar 2024 01:17:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 52C46C433F1; Sat, 9 Mar 2024 01:17:03 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: be63f0cb-ddb2-11ee-afdb-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1709947025; bh=8je4Crl/Z3efIc1qlcOV20ttvsZSJbCMin/n/tKDpuw=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=oBAwFcfs8SvEDWrn/JEQckHhmBMlA0QpqOgz3zAAJqWwH7CLm0g1niqsOaVn7WF+d gbs3jH558T1iI1eVaOFwOGuv4eVj6+MiQ1H7vr2iC8faX8R+gi8Um2MIy/L5NW8H3Y yENen0kVsXNpT/ZSWi6VJHsI1YcOnweHhA0q+VOWC/aLT9/cGr+dOVuBoneN8g4L04 oZZzquoLyhauR1WAFUaun3Ave9qOwf1MOt8R0Y5zLZ5RmAZEdWHoAE5BAgawBDOrVF j7bcbjQPK7KxeM4I8Y4gpdhWTHnM0Wog71/9BDyHlTdLnasJqeKCcRAnI8ttkR3JLI aqWjMnJ6L8pLQ== Date: Fri, 8 Mar 2024 17:17:01 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Nicola Vetrini cc: xen-devel@lists.xenproject.org, sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, consulting@bugseng.com, bertrand.marquis@arm.com, julien@xen.org, Andrew Cooper , George Dunlap , Jan Beulich , Wei Liu Subject: Re: [XEN PATCH] xen/compiler: deviate the inline macro for MISRA C Rule 20.4 In-Reply-To: Message-ID: References: User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Fri, 8 Mar 2024, Nicola Vetrini wrote: > Rule 20.4 states: "A macro shall not be defined with the same name > as a keyword". > > Defining this macro with the same name as the inline keyword > allows for additionally checking that out-of-lined static inline > functions end up in the correct section while minimizing churn and > has a positive impact on the overall safety. See [1] for additional > context on the motivation of this deviation. > > No functional change. > > [1] https://lore.kernel.org/xen-devel/adaa6d55-266d-4df8-8967-9340080d17e4@citrix.com/ > > Signed-off-by: Nicola Vetrini Reviewed-by: Stefano Stabellini From xen-devel-bounces@lists.xenproject.org Sat Mar 09 01:20:18 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 09 Mar 2024 01:20:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690439.1076421 (Exim 4.92) (envelope-from ) id 1rilNp-0006m5-AV; Sat, 09 Mar 2024 01:20:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690439.1076421; Sat, 09 Mar 2024 01:20:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rilNp-0006ly-7C; Sat, 09 Mar 2024 01:20:17 +0000 Received: by outflank-mailman (input) for mailman id 690439; Sat, 09 Mar 2024 01:20:16 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rilNo-0006lr-Gj for xen-devel@lists.xenproject.org; Sat, 09 Mar 2024 01:20:16 +0000 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 2ddc47aa-ddb3-11ee-afdb-a90da7624cb6; Sat, 09 Mar 2024 02:20:15 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 801FDCE0FB5; Sat, 9 Mar 2024 01:20:08 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5FDFBC433F1; Sat, 9 Mar 2024 01:20:05 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 2ddc47aa-ddb3-11ee-afdb-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1709947206; bh=WTwP83cGz0XwSAiav32aPdOT6N9F7rICSXGaAvjCrPg=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=rTJ7yn0byvmRobP/aH1MmusZxIlPDU+2X+G5d7/e+JOOmrfMrL+ZWUnkACKmFuBhc NMTRRpX16EspxMYlI92Q7M7vZKMj1CXC4I/++nac3r3F1phCnESZIrA+kMTL7q3sIl ok1FAC2VDbgx/5NGbElVoEa2NNWeZ3IBfehGAvi7aXNy2lNLVrdjNfpX5pLhJYKi3/ LhM05yOYo/AZvFqTWFSTX7PFM8UnEDOKmLbsulNKgi2Ehz5iWbFTRuOYJjTQYxZ7Ga XLp7FrXmRSL9ECPxjPZ7EBEJBIDb7/byzG0iELtZb5UEBA0XOLCRbd4VQviA5u5rGq XtqncCE5reoPA== Date: Fri, 8 Mar 2024 17:20:03 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Federico Serafini cc: xen-devel@lists.xenproject.org, consulting@bugseng.com, Andrew Cooper , George Dunlap , Jan Beulich , Julien Grall , Stefano Stabellini , Wei Liu Subject: Re: [XEN PATCH] xen/evtchn: address violations of MISRA C:2012 Rules 16.3 and 16.4 In-Reply-To: <3ec419e30227a8016c28e04524cd36a549aaddcf.1709898466.git.federico.serafini@bugseng.com> Message-ID: References: <3ec419e30227a8016c28e04524cd36a549aaddcf.1709898466.git.federico.serafini@bugseng.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Fri, 8 Mar 2024, Federico Serafini wrote: > Add missing break statements to address violations of MISRA C:2012 > Rule 16.3 ("An unconditional `break' statement shall terminate every > switch-clause"). > > Add missing default cases to address violations of MISRA C:2012 > Rule 16.4 (Every `switch' statement shall have a `default' label). > > No functional change. > > Signed-off-by: Federico Serafini Reviewed-by: Stefano Stabellini From xen-devel-bounces@lists.xenproject.org Sat Mar 09 01:24:09 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 09 Mar 2024 01:24:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690441.1076430 (Exim 4.92) (envelope-from ) id 1rilRV-0007Md-Pt; Sat, 09 Mar 2024 01:24:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690441.1076430; Sat, 09 Mar 2024 01:24:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rilRV-0007MU-NN; Sat, 09 Mar 2024 01:24:05 +0000 Received: by outflank-mailman (input) for mailman id 690441; Sat, 09 Mar 2024 01:24:04 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rilRU-0007MO-FD for xen-devel@lists.xenproject.org; Sat, 09 Mar 2024 01:24:04 +0000 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id b5cf75c7-ddb3-11ee-afdb-a90da7624cb6; Sat, 09 Mar 2024 02:24:03 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 50F6FCE1DF4; Sat, 9 Mar 2024 01:24:00 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C34A5C43390; Sat, 9 Mar 2024 01:23:57 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b5cf75c7-ddb3-11ee-afdb-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1709947439; bh=N4Zlr2YBEF2Zmj+/2VFqqlC0xz7Y3kl8JtrrJtLq/F4=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=H4izAxdRXS45+38iQF7jY/0xjhXFrT7fbRPe9Ho9UjEwQAHEWoMQUlDcrVo2ppsIS uuGJi0TjffJDa5OqzdI//gILNjkllYkh3Cw+4b0GanlELQKuRrw+hHXqmnXp/cF7la ERds2m8B+NvjFstU7vFBRJwQX/iiJfFPIKsuxg+0Tu5V3MO98vuK6EXlbehpuTLdfS R9nAlmt8mFvnRFPzuJLRj5WBY0svBp8GDumqmhYOTuimWROssw8r6D04e+XjxC5ULV hLB0UzuZGbwB2dNHGKcVTxhTtzzoaRVK1QoaGl2ByDzq8uwKe6rwO9ZOaxfJRdsbvS qy7+IEm5SsxBg== Date: Fri, 8 Mar 2024 17:23:56 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Nicola Vetrini cc: xen-devel@lists.xenproject.org, sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, consulting@bugseng.com, bertrand.marquis@arm.com, julien@xen.org, Andrew Cooper , George Dunlap , Jan Beulich , Wei Liu Subject: Re: [XEN PATCH v2 1/7] xen/spinlock: address violations of MISRA C Rule 20.7 In-Reply-To: <59e9749d3c6a22469bc9fb804b7b7c13850e9e94.1709896401.git.nicola.vetrini@bugseng.com> Message-ID: References: <59e9749d3c6a22469bc9fb804b7b7c13850e9e94.1709896401.git.nicola.vetrini@bugseng.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Fri, 8 Mar 2024, Nicola Vetrini wrote: > MISRA C Rule 20.7 states: "Expressions resulting from the expansion > of macro parameters shall be enclosed in parentheses". Therefore, some > macro definitions should gain additional parentheses to ensure that all > current and future users will be safe with respect to expansions that > can possibly alter the semantics of the passed-in macro parameter. > > No functional change. > > Signed-off-by: Nicola Vetrini Reviewed-by: Stefano Stabellini From xen-devel-bounces@lists.xenproject.org Sat Mar 09 01:26:41 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 09 Mar 2024 01:26:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690444.1076443 (Exim 4.92) (envelope-from ) id 1rilTz-0007uN-5v; Sat, 09 Mar 2024 01:26:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690444.1076443; Sat, 09 Mar 2024 01:26:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rilTz-0007uG-3N; Sat, 09 Mar 2024 01:26:39 +0000 Received: by outflank-mailman (input) for mailman id 690444; Sat, 09 Mar 2024 01:26:38 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rilTy-0007u8-6k for xen-devel@lists.xenproject.org; Sat, 09 Mar 2024 01:26:38 +0000 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 11822305-ddb4-11ee-afdb-a90da7624cb6; Sat, 09 Mar 2024 02:26:37 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id D82CECE1DF4; Sat, 9 Mar 2024 01:26:30 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D4A80C433F1; Sat, 9 Mar 2024 01:26:27 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 11822305-ddb4-11ee-afdb-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1709947589; bh=N4Zlr2YBEF2Zmj+/2VFqqlC0xz7Y3kl8JtrrJtLq/F4=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=D59PEel4gAxnPjFERTRN8Yn1NLQqlINo+xEZWOHj6sgJzPulHYE91La8WBhZ8GJWT 0VUgNTTCHHyoFiilOI1d6En8jp3u0HO4NFCV2s32fu6A0GLqEvUZasT4QM0pXfe2+J VvIR6hepT1d5/ZlI0WDHNHnjTbS486ThUjG7gyEtWRJhdAyOWbwr6s/Gy5Z9uZk64Q TLy6BaorAi79+ECNoJLsR/HscOezukYlJJ0M6R9BhhWGr6GKT+ErQ+QKWRQvxMtNXC FSxB3PzHvsQTw75sI1VY3q9RLpggvTjk1Rcf0Kl0IDBPtWAVfNY9tyPKAaHd7suerO +bV3SY6jLPgkw== Date: Fri, 8 Mar 2024 17:26:26 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Nicola Vetrini cc: xen-devel@lists.xenproject.org, sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, consulting@bugseng.com, bertrand.marquis@arm.com, julien@xen.org, Andrew Cooper , George Dunlap , Jan Beulich , Wei Liu Subject: Re: [XEN PATCH v2 2/7] xen/include: address violations of MISRA C Rule 20.7 In-Reply-To: <5be252bfb30682d33aecca11921dcdfcc17f9ae6.1709896401.git.nicola.vetrini@bugseng.com> Message-ID: References: <5be252bfb30682d33aecca11921dcdfcc17f9ae6.1709896401.git.nicola.vetrini@bugseng.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Fri, 8 Mar 2024, Nicola Vetrini wrote: > MISRA C Rule 20.7 states: "Expressions resulting from the expansion > of macro parameters shall be enclosed in parentheses". Therefore, some > macro definitions should gain additional parentheses to ensure that all > current and future users will be safe with respect to expansions that > can possibly alter the semantics of the passed-in macro parameter. > > No functional change. > > Signed-off-by: Nicola Vetrini Reviewed-by: Stefano Stabellini From xen-devel-bounces@lists.xenproject.org Sat Mar 09 01:30:12 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 09 Mar 2024 01:30:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690448.1076454 (Exim 4.92) (envelope-from ) id 1rilXL-0001ef-MJ; Sat, 09 Mar 2024 01:30:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690448.1076454; Sat, 09 Mar 2024 01:30:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rilXL-0001eY-IF; Sat, 09 Mar 2024 01:30:07 +0000 Received: by outflank-mailman (input) for mailman id 690448; Sat, 09 Mar 2024 01:30:06 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rilXK-0001ZQ-JL for xen-devel@lists.xenproject.org; Sat, 09 Mar 2024 01:30:06 +0000 Received: from sin.source.kernel.org (sin.source.kernel.org [2604:1380:40e1:4800::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 8db01e72-ddb4-11ee-afdb-a90da7624cb6; Sat, 09 Mar 2024 02:30:05 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 04969CE2A37; Sat, 9 Mar 2024 01:30:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 765D0C433F1; Sat, 9 Mar 2024 01:30:00 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8db01e72-ddb4-11ee-afdb-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1709947802; bh=N4Zlr2YBEF2Zmj+/2VFqqlC0xz7Y3kl8JtrrJtLq/F4=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=Iwy3tPn5X0OLKe2t3V7y1g2S8w+4jbozuYSTx0H8cFhitQtqCHg4LzmsejFNJtJZY MpmRqlxHI8dCMGNzsjdPI+xKRVn1cfTR1TYIVtDq/IQiwuf+mF4hUiG0B6T4vUFcXO nA6fT1iMcQOD05NxjUgTC5DjLq/ZanqB1PNw41+U3NVwkqR55cssY1dbTykH7yJAi5 k6ASLy7d8m0hII6DsUaKlbtjsi7OLl3OheJJjkePg5/JxQCA0AUEgnzAsn52L/94+K mc5fPx8zhn/IAusyaRVePf2WYXM2qJPKgWDY6JB8VeUVZc+kaQ6smZaURB12WB0PY8 +/sc7UfLApGGw== Date: Fri, 8 Mar 2024 17:29:58 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Nicola Vetrini cc: xen-devel@lists.xenproject.org, sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, consulting@bugseng.com, bertrand.marquis@arm.com, julien@xen.org, Andrew Cooper , George Dunlap , Jan Beulich , Wei Liu Subject: Re: [XEN PATCH v2 3/7] xen/list: address violations of MISRA C Rule 20.7 In-Reply-To: Message-ID: References: User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Fri, 8 Mar 2024, Nicola Vetrini wrote: > MISRA C Rule 20.7 states: "Expressions resulting from the expansion > of macro parameters shall be enclosed in parentheses". Therefore, some > macro definitions should gain additional parentheses to ensure that all > current and future users will be safe with respect to expansions that > can possibly alter the semantics of the passed-in macro parameter. > > No functional change. > > Signed-off-by: Nicola Vetrini Reviewed-by: Stefano Stabellini From xen-devel-bounces@lists.xenproject.org Sat Mar 09 01:32:26 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 09 Mar 2024 01:32:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690450.1076464 (Exim 4.92) (envelope-from ) id 1rilZZ-0002Bx-2Q; Sat, 09 Mar 2024 01:32:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690450.1076464; Sat, 09 Mar 2024 01:32:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rilZY-0002Bq-U0; Sat, 09 Mar 2024 01:32:24 +0000 Received: by outflank-mailman (input) for mailman id 690450; Sat, 09 Mar 2024 01:32:23 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rilZX-0002Bd-Lj for xen-devel@lists.xenproject.org; Sat, 09 Mar 2024 01:32:23 +0000 Received: from dfw.source.kernel.org (dfw.source.kernel.org [2604:1380:4641:c500::1]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id dea8e782-ddb4-11ee-a1ee-f123f15fe8a2; Sat, 09 Mar 2024 02:32:21 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 0D2B56117D; Sat, 9 Mar 2024 01:32:19 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E7388C433C7; Sat, 9 Mar 2024 01:32:16 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: dea8e782-ddb4-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1709947938; bh=N4Zlr2YBEF2Zmj+/2VFqqlC0xz7Y3kl8JtrrJtLq/F4=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=ES94JaM5KQUZg2wNEojB4BVTSqTM5TDEBvnSB0STZj0SBNvlT7Ld7IPZBjeecfaBL 0FFA/NNvZ5VUyGEc7aiTGoON7KrSmIDBROyueiQ7A5L7XwJ4dw3JwyuTiP/66dqn/g /C9Fc3kDWXoTApJOUkPwFDSmZ9aEnn3kbx2gBKJOwdUkhGwq59SffCOAqSm9P+bpLx v+RbRze2XVSgoTcUF2CTOV+Ek9SyrjYhfmsgkwi8VTtTktCU9e6xlfYOstrNSey7Op WDb61UuD/GQK8lz9CAij46vaaZBIeVlull3qoyRPoQxj1zwxpxuw1e+FCEx5h3dK9Q uMPfjRsHzQ41Q== Date: Fri, 8 Mar 2024 17:32:15 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Nicola Vetrini cc: xen-devel@lists.xenproject.org, sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, consulting@bugseng.com, bertrand.marquis@arm.com, julien@xen.org, Andrew Cooper , George Dunlap , Jan Beulich , Wei Liu Subject: Re: [XEN PATCH v2 4/7] xen/param: address violations of MISRA C Rule 20.7 In-Reply-To: <6ad91190bd777ee76d94efbe71341a38dbcdb428.1709896401.git.nicola.vetrini@bugseng.com> Message-ID: References: <6ad91190bd777ee76d94efbe71341a38dbcdb428.1709896401.git.nicola.vetrini@bugseng.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Fri, 8 Mar 2024, Nicola Vetrini wrote: > MISRA C Rule 20.7 states: "Expressions resulting from the expansion > of macro parameters shall be enclosed in parentheses". Therefore, some > macro definitions should gain additional parentheses to ensure that all > current and future users will be safe with respect to expansions that > can possibly alter the semantics of the passed-in macro parameter. > > No functional change. > > Signed-off-by: Nicola Vetrini Reviewed-by: Stefano Stabellini From xen-devel-bounces@lists.xenproject.org Sat Mar 09 01:54:13 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 09 Mar 2024 01:54:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690457.1076473 (Exim 4.92) (envelope-from ) id 1riluP-0006PT-Mr; Sat, 09 Mar 2024 01:53:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690457.1076473; Sat, 09 Mar 2024 01:53:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riluP-0006PM-KB; Sat, 09 Mar 2024 01:53:57 +0000 Received: by outflank-mailman (input) for mailman id 690457; Sat, 09 Mar 2024 01:53:56 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riluO-0006PG-HD for xen-devel@lists.xenproject.org; Sat, 09 Mar 2024 01:53:56 +0000 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id e186f6d0-ddb7-11ee-afdb-a90da7624cb6; Sat, 09 Mar 2024 02:53:54 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id AC369CE2A71; Sat, 9 Mar 2024 01:53:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BFBB2C433C7; Sat, 9 Mar 2024 01:53:46 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e186f6d0-ddb7-11ee-afdb-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1709949228; bh=XrMeFPwOFOGCQgjOreaoVBFZhLjyv6y6Ow3Hq7Qr4dE=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=nd/A696e6P3XGY+fY9eFOg9psu+LW0DtPCMuZYgteSZLN09IMc6JFj9cvw7BkC/99 I5qI8mhwFp7JR5Ntn9ymd5bJ581sJK9remgAEa57PPgfLqa5dCE2gcSmxU0dr5nKZc bA9f4ne0hlgHLOBeOznx9VCKBZXOmdtGsf2ePuWi4JFeTjxIoLAbSD+8DkAw7OPnSY GOPb4zIdbEcne/ZWZEv4b07ATzHTdKZ7WHqW5S24tiAVeOX4WmYCupPT9DKWu+3hLg sukrHu4qg2Jc1clSeSHml9/PuQ9OUdX+K1sAZBqGmKl6FhDLDCUpXN9Qvne2oWAvY0 K/jfHn/8u3wug== Date: Fri, 8 Mar 2024 17:53:45 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Nicola Vetrini cc: xen-devel@lists.xenproject.org, sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, consulting@bugseng.com, bertrand.marquis@arm.com, julien@xen.org, Volodymyr Babchuk Subject: Re: [XEN PATCH v2 5/7] xen/arm: address some violations of MISRA C Rule 20.7 In-Reply-To: Message-ID: References: User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Fri, 8 Mar 2024, Nicola Vetrini wrote: > MISRA C Rule 20.7 states: "Expressions resulting from the expansion > of macro parameters shall be enclosed in parentheses". Therefore, some > macro definitions should gain additional parentheses to ensure that all > current and future users will be safe with respect to expansions that > can possibly alter the semantics of the passed-in macro parameter. > > No functional change. > > Signed-off-by: Nicola Vetrini Reviewed-by: Stefano Stabellini There are a couple of cases below where parentheses are not strictly necessary but this patch is following the decided deviation pattern. > --- > Style in arm64/cpufeature.c has not been amended, because this file seems > to be kept in sync with its Linux counterpart. > > Changes in v2: > - Added parentheses for consistency > --- > xen/arch/arm/arm64/cpufeature.c | 14 ++++----- > xen/arch/arm/cpuerrata.c | 8 +++--- > xen/arch/arm/include/asm/arm64/sysregs.h | 2 +- > xen/arch/arm/include/asm/guest_atomics.h | 4 +-- > xen/arch/arm/include/asm/mm.h | 2 +- > xen/arch/arm/include/asm/smccc.h | 36 ++++++++++++------------ > xen/arch/arm/include/asm/vgic-emul.h | 8 +++--- > xen/arch/arm/vcpreg.c | 5 ++-- > 8 files changed, 40 insertions(+), 39 deletions(-) > > diff --git a/xen/arch/arm/arm64/cpufeature.c b/xen/arch/arm/arm64/cpufeature.c > index 864413d9cc03..6fb8974ade7f 100644 > --- a/xen/arch/arm/arm64/cpufeature.c > +++ b/xen/arch/arm/arm64/cpufeature.c > @@ -78,13 +78,13 @@ > > #define __ARM64_FTR_BITS(SIGNED, VISIBLE, STRICT, TYPE, SHIFT, WIDTH, SAFE_VAL) \ > { \ > - .sign = SIGNED, \ > - .visible = VISIBLE, \ > - .strict = STRICT, \ > - .type = TYPE, \ > - .shift = SHIFT, \ > - .width = WIDTH, \ > - .safe_val = SAFE_VAL, \ > + .sign = (SIGNED), \ > + .visible = (VISIBLE), \ > + .strict = (STRICT), \ > + .type = (TYPE), \ > + .shift = (SHIFT), \ > + .width = (WIDTH), \ > + .safe_val = (SAFE_VAL), \ > } > > /* Define a feature with unsigned values */ > diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c > index a28fa6ac78cc..2b7101ea2524 100644 > --- a/xen/arch/arm/cpuerrata.c > +++ b/xen/arch/arm/cpuerrata.c > @@ -461,13 +461,13 @@ static bool has_ssbd_mitigation(const struct arm_cpu_capabilities *entry) > > #define MIDR_RANGE(model, min, max) \ > .matches = is_affected_midr_range, \ > - .midr_model = model, \ > - .midr_range_min = min, \ > - .midr_range_max = max > + .midr_model = (model), \ > + .midr_range_min = (min), \ > + .midr_range_max = (max) > > #define MIDR_ALL_VERSIONS(model) \ > .matches = is_affected_midr_range, \ > - .midr_model = model, \ > + .midr_model = (model), \ > .midr_range_min = 0, \ > .midr_range_max = (MIDR_VARIANT_MASK | MIDR_REVISION_MASK) > > diff --git a/xen/arch/arm/include/asm/arm64/sysregs.h b/xen/arch/arm/include/asm/arm64/sysregs.h > index 3fdeb9d8cdef..b593e4028b53 100644 > --- a/xen/arch/arm/include/asm/arm64/sysregs.h > +++ b/xen/arch/arm/include/asm/arm64/sysregs.h > @@ -465,7 +465,7 @@ > /* Access to system registers */ > > #define WRITE_SYSREG64(v, name) do { \ > - uint64_t _r = v; \ > + uint64_t _r = (v); \ > asm volatile("msr "__stringify(name)", %0" : : "r" (_r)); \ > } while (0) > #define READ_SYSREG64(name) ({ \ > diff --git a/xen/arch/arm/include/asm/guest_atomics.h b/xen/arch/arm/include/asm/guest_atomics.h > index a1745f8613f6..8893eb9a55d7 100644 > --- a/xen/arch/arm/include/asm/guest_atomics.h > +++ b/xen/arch/arm/include/asm/guest_atomics.h > @@ -32,7 +32,7 @@ static inline void guest_##name(struct domain *d, int nr, volatile void *p) \ > perfc_incr(atomics_guest_paused); \ > \ > domain_pause_nosync(d); \ > - name(nr, p); \ > + (name)(nr, p); \ > domain_unpause(d); \ > } > > @@ -52,7 +52,7 @@ static inline int guest_##name(struct domain *d, int nr, volatile void *p) \ > perfc_incr(atomics_guest_paused); \ > \ > domain_pause_nosync(d); \ > - oldbit = name(nr, p); \ > + oldbit = (name)(nr, p); \ > domain_unpause(d); \ > \ > return oldbit; \ > diff --git a/xen/arch/arm/include/asm/mm.h b/xen/arch/arm/include/asm/mm.h > index cbcf3bf14767..48538b5337aa 100644 > --- a/xen/arch/arm/include/asm/mm.h > +++ b/xen/arch/arm/include/asm/mm.h > @@ -250,7 +250,7 @@ static inline void __iomem *ioremap_wc(paddr_t start, size_t len) > #define gaddr_to_gfn(ga) _gfn(paddr_to_pfn(ga)) > #define mfn_to_maddr(mfn) pfn_to_paddr(mfn_x(mfn)) > #define maddr_to_mfn(ma) _mfn(paddr_to_pfn(ma)) > -#define vmap_to_mfn(va) maddr_to_mfn(virt_to_maddr((vaddr_t)va)) > +#define vmap_to_mfn(va) maddr_to_mfn(virt_to_maddr((vaddr_t)(va))) > #define vmap_to_page(va) mfn_to_page(vmap_to_mfn(va)) > > /* Page-align address and convert to frame number format */ > diff --git a/xen/arch/arm/include/asm/smccc.h b/xen/arch/arm/include/asm/smccc.h > index 1adcd37443c7..a289c48b7ffd 100644 > --- a/xen/arch/arm/include/asm/smccc.h > +++ b/xen/arch/arm/include/asm/smccc.h > @@ -122,56 +122,56 @@ struct arm_smccc_res { > #define __constraint_read_7 __constraint_read_6, "r" (r7) > > #define __declare_arg_0(a0, res) \ > - struct arm_smccc_res *___res = res; \ > - register unsigned long r0 ASM_REG(0) = (uint32_t)a0; \ > + struct arm_smccc_res *___res = (res); \ > + register unsigned long r0 ASM_REG(0) = (uint32_t)(a0); \ > register unsigned long r1 ASM_REG(1); \ > register unsigned long r2 ASM_REG(2); \ > register unsigned long r3 ASM_REG(3) > > #define __declare_arg_1(a0, a1, res) \ > - typeof(a1) __a1 = a1; \ > - struct arm_smccc_res *___res = res; \ > - register unsigned long r0 ASM_REG(0) = (uint32_t)a0; \ > + typeof(a1) __a1 = (a1); \ > + struct arm_smccc_res *___res = (res); \ > + register unsigned long r0 ASM_REG(0) = (uint32_t)(a0); \ > register unsigned long r1 ASM_REG(1) = __a1; \ > register unsigned long r2 ASM_REG(2); \ > register unsigned long r3 ASM_REG(3) > > #define __declare_arg_2(a0, a1, a2, res) \ > - typeof(a1) __a1 = a1; \ > - typeof(a2) __a2 = a2; \ > - struct arm_smccc_res *___res = res; \ > - register unsigned long r0 ASM_REG(0) = (uint32_t)a0; \ > + typeof(a1) __a1 = (a1); \ > + typeof(a2) __a2 = (a2); \ > + struct arm_smccc_res *___res = (res); \ > + register unsigned long r0 ASM_REG(0) = (uint32_t)(a0); \ > register unsigned long r1 ASM_REG(1) = __a1; \ > register unsigned long r2 ASM_REG(2) = __a2; \ > register unsigned long r3 ASM_REG(3) > > #define __declare_arg_3(a0, a1, a2, a3, res) \ > - typeof(a1) __a1 = a1; \ > - typeof(a2) __a2 = a2; \ > - typeof(a3) __a3 = a3; \ > - struct arm_smccc_res *___res = res; \ > - register unsigned long r0 ASM_REG(0) = (uint32_t)a0; \ > + typeof(a1) __a1 = (a1); \ > + typeof(a2) __a2 = (a2); \ > + typeof(a3) __a3 = (a3); \ > + struct arm_smccc_res *___res = (res); \ > + register unsigned long r0 ASM_REG(0) = (uint32_t)(a0); \ > register unsigned long r1 ASM_REG(1) = __a1; \ > register unsigned long r2 ASM_REG(2) = __a2; \ > register unsigned long r3 ASM_REG(3) = __a3 > > #define __declare_arg_4(a0, a1, a2, a3, a4, res) \ > - typeof(a4) __a4 = a4; \ > + typeof(a4) __a4 = (a4); \ > __declare_arg_3(a0, a1, a2, a3, res); \ > register unsigned long r4 ASM_REG(4) = __a4 > > #define __declare_arg_5(a0, a1, a2, a3, a4, a5, res) \ > - typeof(a5) __a5 = a5; \ > + typeof(a5) __a5 = (a5); \ > __declare_arg_4(a0, a1, a2, a3, a4, res); \ > register typeof(a5) r5 ASM_REG(5) = __a5 > > #define __declare_arg_6(a0, a1, a2, a3, a4, a5, a6, res) \ > - typeof(a6) __a6 = a6; \ > + typeof(a6) __a6 = (a6); \ > __declare_arg_5(a0, a1, a2, a3, a4, a5, res); \ > register typeof(a6) r6 ASM_REG(6) = __a6 > > #define __declare_arg_7(a0, a1, a2, a3, a4, a5, a6, a7, res) \ > - typeof(a7) __a7 = a7; \ > + typeof(a7) __a7 = (a7); \ > __declare_arg_6(a0, a1, a2, a3, a4, a5, a6, res); \ > register typeof(a7) r7 ASM_REG(7) = __a7 > > diff --git a/xen/arch/arm/include/asm/vgic-emul.h b/xen/arch/arm/include/asm/vgic-emul.h > index e52fbaa3ec04..fd0cfa2175fe 100644 > --- a/xen/arch/arm/include/asm/vgic-emul.h > +++ b/xen/arch/arm/include/asm/vgic-emul.h > @@ -6,11 +6,11 @@ > * a range of registers > */ > > -#define VREG32(reg) reg ... reg + 3 > -#define VREG64(reg) reg ... reg + 7 > +#define VREG32(reg) (reg) ... ((reg) + 3) > +#define VREG64(reg) (reg) ... ((reg) + 7) > > -#define VRANGE32(start, end) start ... end + 3 > -#define VRANGE64(start, end) start ... end + 7 > +#define VRANGE32(start, end) (start) ... ((end) + 3) > +#define VRANGE64(start, end) (start) ... ((end) + 7) > > /* > * 64 bits registers can be accessible using 32-bit and 64-bit unless > diff --git a/xen/arch/arm/vcpreg.c b/xen/arch/arm/vcpreg.c > index a2d050070473..019cf34f003a 100644 > --- a/xen/arch/arm/vcpreg.c > +++ b/xen/arch/arm/vcpreg.c > @@ -39,7 +39,8 @@ > */ > > #ifdef CONFIG_ARM_64 > -#define WRITE_SYSREG_SZ(sz, val, sysreg) WRITE_SYSREG((uint##sz##_t)val, sysreg) > +#define WRITE_SYSREG_SZ(sz, val, sysreg) \ > + WRITE_SYSREG((uint##sz##_t)(val), sysreg) > #else > /* > * WRITE_SYSREG{32/64} on arm32 is defined as variadic macro which imposes > @@ -64,7 +65,7 @@ static bool func(struct cpu_user_regs *regs, type##sz##_t *r, bool read) \ > bool cache_enabled = vcpu_has_cache_enabled(v); \ > \ > GUEST_BUG_ON(read); \ > - WRITE_SYSREG_SZ(sz, *r, reg); \ > + WRITE_SYSREG_SZ(sz, *(r), reg); \ > \ > p2m_toggle_cache(v, cache_enabled); \ > \ > -- > 2.34.1 > From xen-devel-bounces@lists.xenproject.org Sat Mar 09 01:54:45 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 09 Mar 2024 01:54:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690460.1076484 (Exim 4.92) (envelope-from ) id 1rilvB-0006wf-2j; Sat, 09 Mar 2024 01:54:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690460.1076484; Sat, 09 Mar 2024 01:54:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rilvA-0006wY-Vy; Sat, 09 Mar 2024 01:54:44 +0000 Received: by outflank-mailman (input) for mailman id 690460; Sat, 09 Mar 2024 01:54:43 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rilv9-0006PG-Mb for xen-devel@lists.xenproject.org; Sat, 09 Mar 2024 01:54:43 +0000 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id ff022e4f-ddb7-11ee-afdb-a90da7624cb6; Sat, 09 Mar 2024 02:54:43 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 9EEB76118A; Sat, 9 Mar 2024 01:54:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 965B5C433F1; Sat, 9 Mar 2024 01:54:39 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ff022e4f-ddb7-11ee-afdb-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1709949281; bh=XUeS+0b6S2pK6vhttQMLnbSiJSjANX5yRdWb8HmlEPc=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=qPuEaQS8PjbmSFfiQBEWk6/Y7zfAU5+PvSH7KCq8gmhLhQ2DASD0/md5Zyh9sxGOy muZH3i64eNYt5rdic3FmgZZ4TFABxUUI7ab7xCfiL1Xmzf+dwHMPYxjExR1GPQiBGO 9IqIzMSYgz/ATvMdOnCuSclKwWK1JtFIALcFXRUTpm6wVjdurz6L+mixVYGcONhMLa o/y3k3mMXDQ58qirQ8el5tPNMYjhHNfRK3bpq0/XeNt4xK7xbQxL3PFLyeXkkVWUGF z35G0Z3usfp3NO4WcjnFEofzFTSBtiFOZnZFDZ6yzd0cMF37ERpf12n6vUrKMOPi1s 0Jtt86cxwMuOg== Date: Fri, 8 Mar 2024 17:54:37 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Nicola Vetrini cc: xen-devel@lists.xenproject.org, sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, consulting@bugseng.com, bertrand.marquis@arm.com, julien@xen.org, Jan Beulich , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu Subject: Re: [XEN PATCH v2 6/7] x86/irq: parenthesize negative constants In-Reply-To: <9b7e9135952e51043427e3233305917126c95659.1709896401.git.nicola.vetrini@bugseng.com> Message-ID: References: <9b7e9135952e51043427e3233305917126c95659.1709896401.git.nicola.vetrini@bugseng.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Fri, 8 Mar 2024, Nicola Vetrini wrote: > These constants are parenthesized to avoid them from > possibly influencing the semantics of the constructs where it is used, > especially inside macros invocations. > > This also resolves some violations of MISRA C Rule 20.7 > ("Expressions resulting from the expansion of macro parameters shall > be enclosed in parentheses"). > > No functional change. > > Signed-off-by: Nicola Vetrini Reviewed-by: Stefano Stabellini From xen-devel-bounces@lists.xenproject.org Sat Mar 09 01:59:44 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 09 Mar 2024 01:59:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690466.1076493 (Exim 4.92) (envelope-from ) id 1rilzm-0007s8-Kf; Sat, 09 Mar 2024 01:59:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690466.1076493; Sat, 09 Mar 2024 01:59:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rilzm-0007s1-He; Sat, 09 Mar 2024 01:59:30 +0000 Received: by outflank-mailman (input) for mailman id 690466; Sat, 09 Mar 2024 01:59:29 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rilzl-0007jS-2X for xen-devel@lists.xenproject.org; Sat, 09 Mar 2024 01:59:29 +0000 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id a82acc80-ddb8-11ee-a1ee-f123f15fe8a2; Sat, 09 Mar 2024 02:59:26 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id AA0A3611AB; Sat, 9 Mar 2024 01:59:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C820AC433F1; Sat, 9 Mar 2024 01:59:23 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a82acc80-ddb8-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1709949565; bh=EYg93nlU33GjOu7UC4cTWsN0LpqrP9c+Suy0F97oH2o=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=HV9SIEQ8XMYEFZMzTn2Anit8mFpGz8l9+ViMvsaKTgESmfJu1VSdEN7NFxcNdWRcf /aJmjVUzeyT1QEvuXtztuGPkH6CKlF/ZTzhwyypfuEVtL7PT5VaPkHiKen4U01m4eF jcGFW7fj9bpUGvhSrjGw9QZYoj3ub2iFF9A6+uSJnOfMADe3CnMKk/Vo3Zi8UOqH+r MQmk+Lc78+FXRdDsCxHYjemWOFowJ1egSd2Idq3rEjCp897V1KupmVGI7d4DG/w1tH 0aNkOWkwUtUu4+V3EA7VX7PJ6QHsg0UWzebbXecnuChXCq2q2m+sSW05+9MuNVufm0 Y8jEI8AkpvSoQ== Date: Fri, 8 Mar 2024 17:59:22 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Jan Beulich cc: Stefano Stabellini , federico.serafini@bugseng.com, Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Julien Grall , Bertrand Marquis , xen-devel@lists.xenproject.org, michal.orzel@amd.com, george.dunlap@cloud.com Subject: Re: [PATCH] do_multicall and MISRA Rule 8.3 In-Reply-To: <5a8f90d6-6502-4d93-9fd7-45fea0ede24a@suse.com> Message-ID: References: <5a8f90d6-6502-4d93-9fd7-45fea0ede24a@suse.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII I would like to resurrect this thread and ask other opinions. On Thu, 23 Nov 2023, Jan Beulich wrote: > On 22.11.2023 22:46, Stefano Stabellini wrote: > > Two out of three do_multicall definitions/declarations use uint32_t as > > type for the "nr_calls" parameters. Change the third one to be > > consistent with the other two. > > > > Link: https://lore.kernel.org/xen-devel/7e3abd4c0ef5127a07a60de1bf090a8aefac8e5c.1692717906.git.federico.serafini@bugseng.com/ > > Link: https://lore.kernel.org/xen-devel/alpine.DEB.2.22.394.2308251502430.6458@ubuntu-linux-20-04-desktop/ > > Signed-off-by: Stefano Stabellini > > --- > > Note that a previous discussion showed disagreement between maintainers > > on this topic. The source of disagreements are that we don't want to > > change a guest-visible ABI and we haven't properly documented how to use > > types for guest ABIs. > > > > As an example, fixed-width types have the advantage of being explicit > > about their size but sometimes register-size types are required (e.g. > > unsigned long). The C specification says little about the size of > > unsigned long and today, and we even use unsigned int in guest ABIs > > without specifying the expected width of unsigned int on the various > > arches. As Jan pointed out, in Xen we assume sizeof(int) >= 4, but > > that's not written anywhere as far as I can tell. > > > > I think the appropriate solution would be to document properly our > > expectations of both fixed-width and non-fixed-width types, and how to > > use them for guest-visible ABIs. > > > > In this patch I used uint32_t for a couple of reasons: > > - until we have better documentation, I feel more confident in using > > explicitly-sized integers in guest-visible ABIs > > I disagree with this way of looking at it. Guests don't invoke these > functions directly, and our assembly code sitting in between already is > expected to (and does) guarantee that (in the case here) unsigned int > would be okay to use (as would be unsigned long, but at least on x86 > that's slightly less efficient), in line with what ./CODING_STYLE says. > > Otoh structure definitions in the public interface of course need to > use fixed with types (and still doesn't properly do so in a few cases). > > Jan > From xen-devel-bounces@lists.xenproject.org Sat Mar 09 02:35:28 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 09 Mar 2024 02:35:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690477.1076507 (Exim 4.92) (envelope-from ) id 1rimYM-0007Rp-84; Sat, 09 Mar 2024 02:35:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690477.1076507; Sat, 09 Mar 2024 02:35:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rimYM-0007Ri-5b; Sat, 09 Mar 2024 02:35:14 +0000 Received: by outflank-mailman (input) for mailman id 690477; Sat, 09 Mar 2024 02:35:13 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rimYL-0007RY-MO; Sat, 09 Mar 2024 02:35:13 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rimYL-00071d-Jv; Sat, 09 Mar 2024 02:35:13 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rimYL-0001Uk-By; Sat, 09 Mar 2024 02:35:13 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rimYL-0003so-BR; Sat, 09 Mar 2024 02:35:13 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Message-Id:Subject:To; bh=DxGPJnoNMKAMxiLBFZQNXj8/zAd7zRM+f4Wy5CT2sec=; b=XJMkSKgarU9st5TBsAiVCNhAaJ SML2pseKzloroiwBs9XoWYbn3gBJZUSXP29ytJLXebk72zSoMKEwIcG021Qy7PP+ENHFbhuojuM6L +JJZU1Y0FCSEHKXD2e9AXAaT+A5j1JuzVpGkk+Q2bagq2TjZ+k83HUix8Ibp/Z8/RLPY=; To: xen-devel@lists.xenproject.org Subject: [xen-unstable bisection] complete test-amd64-amd64-livepatch Message-Id: From: osstest service owner Date: Sat, 09 Mar 2024 02:35:13 +0000 branch xen-unstable xenbranch xen-unstable job test-amd64-amd64-livepatch testid livepatch-run Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git 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: b083b1c393dc8961acf0959b1d2e0ad459985ae3 Bug not present: ef969144a425e39f5b214a875b5713d0ea8575fb Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/184963/ commit b083b1c393dc8961acf0959b1d2e0ad459985ae3 Author: Andrew Cooper Date: Tue Mar 5 11:39:19 2024 +0000 x86/livepatch: Relax permissions on rodata too This reinstates the capability to patch .rodata in load/unload hooks, which was lost when we stopped using CR0.WP=0 to patch. This turns out to be rather less of a large TODO than I thought at the time. Fixes: 8676092a0f16 ("x86/livepatch: Fix livepatch application when CET is active") Signed-off-by: Andrew Cooper Reviewed-by: Roger Pau Monné Reviewed-by: Ross Lagerwall For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable/test-amd64-amd64-livepatch.livepatch-run.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/test-amd64-amd64-livepatch.livepatch-run --summary-out=tmp/184963.bisection-summary --basis-template=184927 --blessings=real,real-bisect,real-retry xen-unstable test-amd64-amd64-livepatch livepatch-run Searching for failure / basis pass: 184940 fail [host=rimava0] / 184927 [host=pinot0] 184919 [host=septiner0] 184914 [host=elbling0] 184907 [host=albana0] 184905 [host=huxelrebe1] 184882 [host=debina0] 184875 [host=albana1] 184852 [host=huxelrebe0] 184833 [host=nobling1] 184828 [host=sabro1] 184820 [host=italia0] 184811 [host=rimava1] 184796 [host=italia1] 184780 [host=fiano1] 184776 [host=fiano0] 184767 [host=elbling1] 184763 [host=sabro0] 184756 [host=pinot1] 184752 [host=godello1] 184746 [host=himrod0] 184732 [host=debina1] 18\ 4729 ok. Failure / basis pass flights: 184940 / 184729 (tree with no url: minios) (tree with no url: ovmf) (tree with no url: seabios) Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git Latest c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 90173fc5a2a826bbcabde22af405d0a617818b70 Basis pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 9ee7dc877b8754ce2fc82500feea52c04d4e6409 Generating revisions with ./adhoc-revtuple-generator git://xenbits.xen.org/linux-pvops.git#c3038e718a19fc596f7b1baba0f83d5146dc7784-c3038e718a19fc596f7b1baba0f83d5146dc7784 git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/qemu-xen-traditional.git#3d273dd05e51e5a1ffba3d98c7437ee84e8f8764-3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 git://xenbits.xen.org/qemu-xen.git#0df9387c8983e1b1e72d8c574356f57\ 2342c03e6-0df9387c8983e1b1e72d8c574356f572342c03e6 git://xenbits.xen.org/xen.git#9ee7dc877b8754ce2fc82500feea52c04d4e6409-90173fc5a2a826bbcabde22af405d0a617818b70 >From git://cache:9419/git://xenbits.xen.org/xen 90173fc5a2..ef31ffbc3d staging -> origin/staging Loaded 5001 nodes in revision graph Searching for test results: 184729 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 9ee7dc877b8754ce2fc82500feea52c04d4e6409 184732 [host=debina1] 184746 [host=himrod0] 184752 [host=godello1] 184756 [host=pinot1] 184763 [host=sabro0] 184767 [host=elbling1] 184776 [host=fiano0] 184780 [host=fiano1] 184796 [host=italia1] 184811 [host=rimava1] 184820 [host=italia0] 184828 [host=sabro1] 184833 [host=nobling1] 184852 [host=huxelrebe0] 184875 [host=albana1] 184882 [host=debina0] 184905 [host=huxelrebe1] 184907 [host=albana0] 184914 [host=elbling0] 184919 [host=septiner0] 184948 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 90173fc5a2a826bbcabde22af405d0a617818b70 184927 [host=pinot0] 184950 blocked c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 52ebde3cfae240e708571742eb7b6942efbd42a2 184940 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 90173fc5a2a826bbcabde22af405d0a617818b70 184947 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 9ee7dc877b8754ce2fc82500feea52c04d4e6409 184951 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 efad36f1ba18946acecc030166b1a6bebeb88ea2 184952 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 e7b62fcfd9dd66398dd0d3c79b3bae216db64e97 184953 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 9249a441c98ff063c0c065538b419a3bf1dac24a 184954 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 989556c6f8ca080f5f202417af97d1188b9ba52a 184955 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 b083b1c393dc8961acf0959b1d2e0ad459985ae3 184956 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 ef969144a425e39f5b214a875b5713d0ea8575fb 184957 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 b083b1c393dc8961acf0959b1d2e0ad459985ae3 184959 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 ef969144a425e39f5b214a875b5713d0ea8575fb 184960 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 b083b1c393dc8961acf0959b1d2e0ad459985ae3 184962 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 ef969144a425e39f5b214a875b5713d0ea8575fb 184963 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 b083b1c393dc8961acf0959b1d2e0ad459985ae3 Searching for interesting versions Result found: flight 184729 (pass), for basis pass For basis failure, parent search stopping at c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 ef969144a425e39f5b214a875b5713d0ea8575fb, results HASH(0x5591d618a750) HASH(0x5591d60ef270) HASH(0x5591d5baf750) For basis failure, parent search stopping at c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8\ 983e1b1e72d8c574356f572342c03e6 989556c6f8ca080f5f202417af97d1188b9ba52a, results HASH(0x5591d60fa1e8) For basis failure, parent search stopping at c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 9249a441c98ff063c0c065538b419a3bf1dac24a, results HASH(0x5591d6110530) For basis failure, parent search stopping at c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f\ 0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 e7b62fcfd9dd66398dd0d3c79b3bae216db64e97, results HASH(0x5591d610ba78) For basis failure, parent search stopping at c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 efad36f1ba18946acecc030166b1a6bebeb88ea2, results HASH(0x5591d60e7c40) For basis failure, parent search stopping at c3038e718a19\ fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 52ebde3cfae240e708571742eb7b6942efbd42a2, results HASH(0x5591d6101428) For basis failure, parent search stopping at c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 9ee7dc877b8754ce2fc82500feea52c04d4e6409, results HASH(0x5591d61055e\ 0) HASH(0x5591d610b478) Result found: flight 184940 (fail), for basis failure (at ancestor ~2910) Repro found: flight 184947 (pass), for basis pass Repro found: flight 184948 (fail), for basis failure 0 revisions at c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 ef969144a425e39f5b214a875b5713d0ea8575fb No revisions left to test, checking graph state. Result found: flight 184956 (pass), for last pass Result found: flight 184957 (fail), for first failure Repro found: flight 184959 (pass), for last pass Repro found: flight 184960 (fail), for first failure Repro found: flight 184962 (pass), for last pass Repro found: flight 184963 (fail), for first failure *** Found and reproduced problem changeset *** Bug is in tree: xen git://xenbits.xen.org/xen.git Bug introduced: b083b1c393dc8961acf0959b1d2e0ad459985ae3 Bug not present: ef969144a425e39f5b214a875b5713d0ea8575fb Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/184963/ commit b083b1c393dc8961acf0959b1d2e0ad459985ae3 Author: Andrew Cooper Date: Tue Mar 5 11:39:19 2024 +0000 x86/livepatch: Relax permissions on rodata too This reinstates the capability to patch .rodata in load/unload hooks, which was lost when we stopped using CR0.WP=0 to patch. This turns out to be rather less of a large TODO than I thought at the time. Fixes: 8676092a0f16 ("x86/livepatch: Fix livepatch application when CET is active") Signed-off-by: Andrew Cooper Reviewed-by: Roger Pau Monné Reviewed-by: Ross Lagerwall Revision graph left in /home/logs/results/bisect/xen-unstable/test-amd64-amd64-livepatch.livepatch-run.{dot,ps,png,html,svg}. ---------------------------------------- 184963: tolerable ALL FAIL flight 184963 xen-unstable real-bisect [real] http://logs.test-lab.xenproject.org/osstest/logs/184963/ Failures :-/ but no regressions. Tests which did not succeed, including tests which could not be run: test-amd64-amd64-livepatch 13 livepatch-run fail baseline untested jobs: test-amd64-amd64-livepatch 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 From xen-devel-bounces@lists.xenproject.org Sat Mar 09 03:29:34 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 09 Mar 2024 03:29:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690486.1076521 (Exim 4.92) (envelope-from ) id 1rinOp-0007eR-ST; Sat, 09 Mar 2024 03:29:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690486.1076521; Sat, 09 Mar 2024 03:29:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rinOp-0007eK-Pk; Sat, 09 Mar 2024 03:29:27 +0000 Received: by outflank-mailman (input) for mailman id 690486; Sat, 09 Mar 2024 03:29:26 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rinOo-0007eC-7p for xen-devel@lists.xenproject.org; Sat, 09 Mar 2024 03:29:26 +0000 Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [2a00:1450:4864:20::52b]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 39e50be4-ddc5-11ee-afdb-a90da7624cb6; Sat, 09 Mar 2024 04:29:24 +0100 (CET) Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-5649c25369aso1865952a12.2 for ; Fri, 08 Mar 2024 19:29:24 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 39e50be4-ddc5-11ee-afdb-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709954964; x=1710559764; darn=lists.xenproject.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Va8ogusGZwdaKepctfLfXDDaga65WunO9ZGuU+9NtAE=; b=EZKiUTl2J+0oGvw1zXfb9yfyk/GpxOWWs3ds49qdc2Y+dn7HSmS9qsf+AYQAOuTrHg P9Wga+2MFxYhlCTgy37Qmv6o3kl0odkvmmu5t9nmX2s1EvsMfmJJfUTfkgGPMKE/G0k+ w68U+QsoEnaHyeVyyElVLSnn6h2g3UpChKnBulz9hmGGViWG8PAREaQVke9NAq/mqP2D 0lxp04b/ktEUf64jnL0K4HDGIvraceiwOVdK2ebxCcn/llJejbJ7jxPD3QX4DGPY14KS MjlHGJ+olCbZE8Tu5q42aevziTOrjVqO5CL9hCvX/Yg1nBRbLugjrtOknoyfKugQ/Z0e nr/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709954964; x=1710559764; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Va8ogusGZwdaKepctfLfXDDaga65WunO9ZGuU+9NtAE=; b=Cx7NiieX7aFxqUYa23usHUR7Uu6y+Y1YSECpfi9YfAkUg+C2iSpS3xae81vzVL6SBP LgMM09wZvd2ExwZw38fAGuIfhDQVtp7R1sWKC0r6A++dHNAYEmQbi9NI6fN/OWwS/8Yd 8DXQ1A199NxQs2hqR04Vj7wLqtKrWN5NO6DA0n9GQH60un2hGc1Caf9k5YuxygGd47gp YMivWtQyfGQ/KR84WvWWij3uJlXrTWOIlQIP7BQJ0bCFBZatA3KH3kq6ZlH9aahmEXq7 VF55tDuG073rB5AeOHefaUk5bn/75uHomb3C7q60VDJBi1ICEu/Y/6XTXasQkkIN7fLV 3I/A== X-Forwarded-Encrypted: i=1; AJvYcCW29+wjabla2YOuGLKSDU5Vcot7Pa0oXPn9CVyN+qT8o1hJKOQy31WATVIHzdpcy6bxPCr8oqwRsdmXBZV0bFyfTwHedkfuK8q9dZKpX0I= X-Gm-Message-State: AOJu0Yz3T02ZbmGfFAjXpq1h3ODHQcLKXHz7NzRDgIBYCK6lIY3XaAu9 SqBH9XcLpBh70GSf1Or+UyUlPcXgx2SkdJPMi9YgcMhiS7wDk5LZULUERWCEvmaTTAfckCeY4iy vvP5qNOl9a6MCoSAvBGzdONrznBY= X-Google-Smtp-Source: AGHT+IGAGGrOzMwhBAKfnLe170l7WdnKP+Is5I9SeSwO++dhjS2Gz++v7KuOxzYPkHCn5T2VAxp61pjrLtMX0iV+cac= X-Received: by 2002:a50:d6d7:0:b0:568:1f9f:eca4 with SMTP id l23-20020a50d6d7000000b005681f9feca4mr553180edj.42.1709954963873; Fri, 08 Mar 2024 19:29:23 -0800 (PST) MIME-Version: 1.0 References: <20240305191312.321127-1-marmarek@invisiblethingslab.com> In-Reply-To: <20240305191312.321127-1-marmarek@invisiblethingslab.com> From: Jason Andryuk Date: Fri, 8 Mar 2024 22:29:12 -0500 Message-ID: Subject: Re: [PATCH v2 1/2] hw/xen: detect when running inside stubdomain To: =?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= Cc: qemu-devel@nongnu.org, Stefano Stabellini , Anthony Perard , Paul Durrant , "open list:X86 Xen CPUs" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Mar 5, 2024 at 2:13=E2=80=AFPM Marek Marczykowski-G=C3=B3recki wrote: > > Introduce global xen_is_stubdomain variable when qemu is running inside > a stubdomain instead of dom0. This will be relevant for subsequent > patches, as few things like accessing PCI config space need to be done > differently. > > Signed-off-by: Marek Marczykowski-G=C3=B3recki Reviewed-by: Jason Andryuk From xen-devel-bounces@lists.xenproject.org Sat Mar 09 03:36:00 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 09 Mar 2024 03:36:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690490.1076534 (Exim 4.92) (envelope-from ) id 1rinUy-0000x9-Ho; Sat, 09 Mar 2024 03:35:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690490.1076534; Sat, 09 Mar 2024 03:35:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rinUy-0000x2-Eq; Sat, 09 Mar 2024 03:35:48 +0000 Received: by outflank-mailman (input) for mailman id 690490; Sat, 09 Mar 2024 03:35:46 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rinUw-0000wd-NU for xen-devel@lists.xenproject.org; Sat, 09 Mar 2024 03:35:46 +0000 Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [2a00:1450:4864:20::233]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 1d0c3c95-ddc6-11ee-afdb-a90da7624cb6; Sat, 09 Mar 2024 04:35:45 +0100 (CET) Received: by mail-lj1-x233.google.com with SMTP id 38308e7fff4ca-2d269b2ff48so38906531fa.3 for ; Fri, 08 Mar 2024 19:35:45 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1d0c3c95-ddc6-11ee-afdb-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709955345; x=1710560145; darn=lists.xenproject.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ytsxnHtpmEBKqqWctGKiw7/Ms2x8N2LrUmUr2AL0+wY=; b=S2ZZQaoe7/pTDa9hXV+9xXUzfNuf2VrkISzq0b8Cbu0bgR6y6o17Qa77gU5957NHgJ 8A3Q/VlR97i7EBbmAHcqjEvofbMatE17fWQdBzOSnABom0Hvtl/6pNMGQ8OOHxak8jh3 8qcVOUOPA7dpCEd4famih20vHG9fAWPj1vVQ+3QuhAS6Ku7oxxLT/qAKQ+LwgPgeQy7d OmXy8vkzjG8OSaPqtSrh7ljma1UyGuyytXydk/4kvkZ8WcSWgf3x+FY7ew2swy1Z+Em2 jTUxH6FY51S0U7IN5gUYlY60JkkkbtvHMlX3Hvn139yVvuFXErFvJXxXTUXcNts3IJXe TMJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709955345; x=1710560145; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ytsxnHtpmEBKqqWctGKiw7/Ms2x8N2LrUmUr2AL0+wY=; b=h3lcXO1Vvj+0Kx/Y+ENFrSySo0v6qmxRvhjUNCd5vKzeZMFpAtroBmAPwg0b8a6LOH Xr582x0nW0nvq8JbXWRMmpOQv85XcBZ2bjZJgoV89soNtt7z+EyE8puqYvT5VKHjsSR2 TjDWTslfoxn8YwXlqAbL1liP3LT0T0BclLwPZxizOc2Q+qcLvcq/FQPQn3mqEk5a50J5 yPzHdOaFaHntI1NQwrJxVYKS5lR1TdzUvuhrWcqX0cxZw7VmF6wK4lzXV/7FIOZXxf0e s7BteswPHHbxzCUQwqgaPZkw/AS80mMzIJL8lGyV0ZksGFVotYVedx3IW3rd2IZuvujY s3CA== X-Forwarded-Encrypted: i=1; AJvYcCWoGU2ON44CeMVJ0sQbsjNLAZyHlON2d769RM0mHmZsF/m5OPHso4W3o6Oxe7dCk+zHgsDvCv7P99F8pVqpkVzU+fUQLpZs25ir35yes10= X-Gm-Message-State: AOJu0Yy7mRPsswSKKKcuu1etfQ6p+1fOF28Ff9pzcOu5tCee2GZaK8tM WNeTZ5I/FDXztgCVAx8Oo09tNDVuWe+4eUCzsfRVN6PJJjJOD21FAaxeGz7xw+BgUxhmocoKYmN NGk890abMe88zrjQIusHYM2OR/Mu+cJjYziI= X-Google-Smtp-Source: AGHT+IEyJOtEREPXpZYtaMDNs4rOhx8WJyezwfQ1NA7tbhObr8lAboMBnMFazQ7OWymEHbqP1y5Qx8WpLPp7ieRlQsg= X-Received: by 2002:a2e:8ec5:0:b0:2d4:21d6:b05e with SMTP id e5-20020a2e8ec5000000b002d421d6b05emr513293ljl.52.1709955344857; Fri, 08 Mar 2024 19:35:44 -0800 (PST) MIME-Version: 1.0 References: <20240305191312.321127-1-marmarek@invisiblethingslab.com> <20240305191312.321127-2-marmarek@invisiblethingslab.com> In-Reply-To: <20240305191312.321127-2-marmarek@invisiblethingslab.com> From: Jason Andryuk Date: Fri, 8 Mar 2024 22:35:33 -0500 Message-ID: Subject: Re: [PATCH v2 2/2] xen: fix stubdom PCI addr To: =?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= Cc: qemu-devel@nongnu.org, =?UTF-8?B?RnLDqWTDqXJpYyBQaWVycmV0IChmZXBpdHJlKQ==?= , Stefano Stabellini , Anthony Perard , Paul Durrant , "open list:X86 Xen CPUs" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Mar 5, 2024 at 2:13=E2=80=AFPM Marek Marczykowski-G=C3=B3recki wrote: > > From: Fr=C3=A9d=C3=A9ric Pierret (fepitre) Needs to be changed to Marek. > When running in a stubdomain, the config space access via sysfs needs to > use BDF as seen inside stubdomain (connected via xen-pcifront), which is > different from the real BDF. For other purposes (hypercall parameters > etc), the real BDF needs to be used. > Get the in-stubdomain BDF by looking up relevant PV PCI xenstore > entries. > > Signed-off-by: Marek Marczykowski-G=C3=B3recki > --- > Changes in v2: > - use xs_node_scanf > - use %d instead of %u to read values written as %d > - add a comment from another iteration of this patch by Jason Andryuk > --- > hw/xen/xen-host-pci-device.c | 69 +++++++++++++++++++++++++++++++++++- > hw/xen/xen-host-pci-device.h | 6 ++++ > 2 files changed, 74 insertions(+), 1 deletion(-) > > diff --git a/hw/xen/xen-host-pci-device.c b/hw/xen/xen-host-pci-device.c > index 8c6e9a1716..8ea2a5a4af 100644 > --- a/hw/xen/xen-host-pci-device.c > +++ b/hw/xen/xen-host-pci-device.c > @@ -9,6 +9,8 @@ > #include "qemu/osdep.h" > #include "qapi/error.h" > #include "qemu/cutils.h" > +#include "hw/xen/xen-legacy-backend.h" > +#include "hw/xen/xen-bus-helper.h" > #include "xen-host-pci-device.h" > > #define XEN_HOST_PCI_MAX_EXT_CAP \ > @@ -33,13 +35,67 @@ > #define IORESOURCE_PREFETCH 0x00001000 /* No side effects */ > #define IORESOURCE_MEM_64 0x00100000 > > +/* > + * Non-passthrough (dom0) accesses are local PCI devices and use the giv= en BDF > + * Passthough (stubdom) accesses are through PV frontend PCI device. Th= ose > + * either have a BDF identical to the backend's BDF (xen-backend.passthr= ough=3D1) > + * or a local virtual BDF (xen-backend.passthrough=3D0) > + * > + * We are always given the backend's BDF and need to lookup the appropri= ate > + * local BDF for sysfs access. > + */ > +static void xen_host_pci_fill_local_addr(XenHostPCIDevice *d, Error **er= rp) > +{ > + unsigned int num_devs, len, i; > + unsigned int domain, bus, dev, func; > + char *be_path =3D NULL; > + char path[80]; path is now only used for dev/vdev-%d, so 80 could be reduced. > + > + be_path =3D qemu_xen_xs_read(xenstore, 0, "device/pci/0/backend", &l= en); > + if (!be_path) error_setg() here? > + goto out; > + > + if (xs_node_scanf(xenstore, 0, be_path, "num_devs", NULL, "%d", &num= _devs) !=3D 1) { > + error_setg(errp, "Failed to read or parse %s/num_devs\n", be_pat= h); > + goto out; > + } > + > + for (i =3D 0; i < num_devs; i++) { > + snprintf(path, sizeof(path), "dev-%d", i); > + if (xs_node_scanf(xenstore, 0, be_path, path, NULL, > + "%x:%x:%x.%x", &domain, &bus, &dev, &func) != =3D 4) { > + error_setg(errp, "Failed to read or parse %s/%s\n", be_path,= path); > + goto out; > + } > + if (domain !=3D d->domain || > + bus !=3D d->bus || > + dev !=3D d->dev || > + func!=3D d->func) > + continue; > + snprintf(path, sizeof(path), "vdev-%d", i); > + if (xs_node_scanf(xenstore, 0, be_path, path, NULL, > + "%x:%x:%x.%x", &domain, &bus, &dev, &func) != =3D 4) { > + error_setg(errp, "Failed to read or parse %s/%s\n", be_path,= path); > + goto out; > + } > + d->local_domain =3D domain; > + d->local_bus =3D bus; > + d->local_dev =3D dev; > + d->local_func =3D func; > + goto out; > + } error_setg here in case we exited the loop without finding a match? Thanks, Jason > + > +out: > + free(be_path); > +} > + From xen-devel-bounces@lists.xenproject.org Sat Mar 09 06:31:06 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 09 Mar 2024 06:31:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690509.1076559 (Exim 4.92) (envelope-from ) id 1riqEM-0004tc-SC; Sat, 09 Mar 2024 06:30:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690509.1076559; Sat, 09 Mar 2024 06:30:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riqEM-0004tU-PV; Sat, 09 Mar 2024 06:30:50 +0000 Received: by outflank-mailman (input) for mailman id 690509; Sat, 09 Mar 2024 06:30:49 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riqEL-0004t3-73; Sat, 09 Mar 2024 06:30:49 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riqEL-0003OR-5P; Sat, 09 Mar 2024 06:30:49 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riqEK-00086K-P0; Sat, 09 Mar 2024 06:30:48 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1riqEK-0006B5-OX; Sat, 09 Mar 2024 06:30:48 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=82ROUxkEtiwSdz/lv+kjamuEeeKE7vA2aKY6dWGKByo=; b=2qB2GZxxL37HQgLFHq7Uspzy4a xm+LJ3huCvwgGW+jGorBLNewLWp4X9fuCnJjAdofpEqbnFtmsKMrqQFzwDB/2c1eobelgP5gYny8D Ut6t7hHnHtHVrAxL0VNZwVGGWluVQ/3tWlZSSl2IT937sy+rhuuH7sTZDKGXl1B86rYk=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 184965: tolerable all pass - PUSHED X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=ef31ffbc3dc124173fc9420988772fa96bc4bf12 X-Osstest-Versions-That: xen=90173fc5a2a826bbcabde22af405d0a617818b70 From: osstest service owner Date: Sat, 09 Mar 2024 06:30:48 +0000 flight 184965 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/184965/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass version targeted for testing: xen ef31ffbc3dc124173fc9420988772fa96bc4bf12 baseline version: xen 90173fc5a2a826bbcabde22af405d0a617818b70 Last test of basis 184932 2024-03-07 15:02:11 Z 1 days Testing same since 184965 2024-03-09 03:00:25 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Federico Serafini 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-amd64 pass 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 90173fc5a2..ef31ffbc3d ef31ffbc3dc124173fc9420988772fa96bc4bf12 -> smoke From xen-devel-bounces@lists.xenproject.org Sat Mar 09 06:44:45 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 09 Mar 2024 06:44:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690514.1076568 (Exim 4.92) (envelope-from ) id 1riqRm-0006y8-2O; Sat, 09 Mar 2024 06:44:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690514.1076568; Sat, 09 Mar 2024 06:44:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riqRl-0006y1-VX; Sat, 09 Mar 2024 06:44:41 +0000 Received: by outflank-mailman (input) for mailman id 690514; Sat, 09 Mar 2024 06:44:40 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riqRk-0006xt-Nw for xen-devel@lists.xenproject.org; Sat, 09 Mar 2024 06:44:40 +0000 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on20601.outbound.protection.outlook.com [2a01:111:f403:2417::601]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 7f2b37a4-dde0-11ee-afdb-a90da7624cb6; Sat, 09 Mar 2024 07:44:37 +0100 (CET) Received: from DM6PR02CA0145.namprd02.prod.outlook.com (2603:10b6:5:332::12) by IA0PR12MB8423.namprd12.prod.outlook.com (2603:10b6:208:3dc::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.31; Sat, 9 Mar 2024 06:44:33 +0000 Received: from DS1PEPF0001709C.namprd05.prod.outlook.com (2603:10b6:5:332:cafe::98) by DM6PR02CA0145.outlook.office365.com (2603:10b6:5:332::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.29 via Frontend Transport; Sat, 9 Mar 2024 06:44:33 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by DS1PEPF0001709C.mail.protection.outlook.com (10.167.18.106) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7386.12 via Frontend Transport; Sat, 9 Mar 2024 06:44:33 +0000 Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Sat, 9 Mar 2024 00:44:32 -0600 Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB05.amd.com (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Sat, 9 Mar 2024 00:44:32 -0600 Received: from [172.31.69.246] (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend Transport; Sat, 9 Mar 2024 00:44:29 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 7f2b37a4-dde0-11ee-afdb-a90da7624cb6 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=O+/PE5nEYDTuultTWUFL5vUR39hl7X+K+C9GmNg5FZ/iHRmEwRD/0I8/qilqDGWGpl9RtXOThStexzhQOoPRQlyAD17weolc3uBjCcwP4DHip3ATBah46wRXjo8ovzXU29tASbxfTTa5WQ7bg7aK/OsbWI4UX+RiWi5hYQxjpysBkVC/FV5wGNA29zExUQg1bGTAkUxQJ6ctBC5TQAl/neNZc0mrKqJfMLlhagGpg6UgSPXWHKU6pDlTQbEpLTQx3i26CPoFtR8gqdu0SGWlLOF4EoX7LnHN0z6Jj/RcK52tEUX0eoZKkyBmxFF0c4OWAhUFVI+pXWc1e8P+TQKcWQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=yCnF0ak/3FNORbw4KMWfvnU4kh709Ckgp2TgFULY740=; b=AynDmcFR9cHNxYzHSRsNVR76Ct3NcZUz1zjbhAyW3Elhj69qmHVaxY6y6bW24a2OzuidYZ+dv0pkdZgtIiyOn9F6QqUhkEtmnkm2z3NwiBazJ79DO5pwkNLnuaXa1RtcZiWaBVYBqf5ScRjdpk51edZ/4+rvfF/aL4PKosKdrcbid7IuZfhgFRcYbKpP/hjcMkZh9i2hXdn4YL1wZoHooV9iKzpD6mNmzcplJpBNs9TS5J31S30cz09oxswp2QkJkaPwaloRjyIWEjGL2ebE+ImAFhJQmbbZMmTNuLK7Q0qIS7GlSqcbBWC0SPGkbWwlReSeffFSuiZikOC9f2BfVw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=xen.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yCnF0ak/3FNORbw4KMWfvnU4kh709Ckgp2TgFULY740=; b=mxkfJsPseAM9yVVskzu05tiRWVO20JgqNeUagknUrh5RQ7YQqikNpSFk7mIr3KSih8oLc4imjXubAIFN03b6f8dTgVCbkBiM5dW8uYUQY+E/ws/kp/EFMbeInvK5JfH8GHeYoGipb2A/wvIq28fjWE6a0gyZNVd7/XwjdTBSxdE= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C Message-ID: <8df22d81-ce3d-4a90-8aa9-34ec66d237c6@amd.com> Date: Sat, 9 Mar 2024 14:44:28 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 13/15] xen/arm: make consider_modules() available for xen relocation To: Julien Grall , Ayan Kumar Halder , CC: , Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Henry Wang , Carlo Nonato References: <20240129171811.21382-1-carlo.nonato@minervasys.tech> <20240129171811.21382-14-carlo.nonato@minervasys.tech> <1439263a-c96d-48bb-bd3c-1427071ecd17@xen.org> Content-Language: en-US From: Henry Wang In-Reply-To: <1439263a-c96d-48bb-bd3c-1427071ecd17@xen.org> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: None (SATLEXMB05.amd.com: xin.wang2@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS1PEPF0001709C:EE_|IA0PR12MB8423:EE_ X-MS-Office365-Filtering-Correlation-Id: 34667c13-d2fe-4b04-6cb0-08dc40046119 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: ddn4dKUpidd78AdcOpX+v4hNyboNtJiHQA4cAWPhcMTiA5mfqvD2R0gDqdV4cZBG4oYlbyGZtRhMECg8n2AKd8igBnwJCx6lPmLIUKJ3dk4KxwvRu4NsvafVl7durPK20JpqVGxXK8L6+6VK1ZQKE1M0tDrotiGihiy0Hr7P2lPFhBcSjExu6PB+dARTq8iU/5OFA1cU87Us4dHqtKxhx6SSVQWtTW6iPPpoW5hM52AeuC28ajfsWBpNjqpxIe58cAirtULKPIuRQ6YpZyyf/2SRiYq7e5RVMH8yNWnpYyzrybA45bj56zx2oHaakMpDwJYVHtNIynXaJIEDJqI2IbzAKUkEoX5u0mwyGDXRZJXAK+QisAEMRzjNqooBYlP/zS+F/bKtTQIU0Zo+0NTAHpXTr7+8bDYwooMx818ZBi/aIkpGxwHTfFb/H2Jk1B1X8yOKyYGD0T+16vdv2EfkoOWq94rfTXuYSQv5ejkmmJwcKTsCtPO5VbeOPyZrRCLdAm0gTViA2TbK/s4jTEa0spuFBTUrs2uhIxXVS1K82SilVtjcF4f0HjflkiZGE4xwWtW6NIJy/ej5FRDeDEcWGR2C8QlwCF4vTvK+S3H5wlqKqdCjXOBgvTlEtXG/GBAqQuIh/ucO2J+7Sg2lqat7uUYFEc4pV29J5YweiubuYPm3dC21xZdW84CN6kaBQ6dXqrSdRN7sPQJVa6tQmM0t114Sol3an/G3T/m9ktc6T6SqNOymMXS5mxzHRK1W8amv X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(82310400014)(36860700004)(376005)(1800799015);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Mar 2024 06:44:33.1152 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 34667c13-d2fe-4b04-6cb0-08dc40046119 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: DS1PEPF0001709C.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR12MB8423 Hi Julien, On 3/9/2024 6:30 AM, Julien Grall wrote: > (+ Ayan + Henry) (- my old email address + the new one) > Hi Carlo, > > On 29/01/2024 17:18, Carlo Nonato wrote: >> Cache coloring must physically relocate Xen in order to color the >> hypervisor >> and consider_modules() is a key function that is needed to find a new >> available physical address. >> >> 672d67f339c0 ("xen/arm: Split MMU-specific setup_mm() and related >> code out") >> moved consider_modules() under arm32. Move it back to setup.c and >> make it >> non-static so that it can be used outside. >> >> Signed-off-by: Carlo Nonato >> --- >> v6: >> - new patch >> --- >>   xen/arch/arm/arm32/mmu/mm.c      | 93 +------------------------------- >>   xen/arch/arm/include/asm/setup.h |  3 ++ >>   xen/arch/arm/setup.c             | 92 +++++++++++++++++++++++++++++++ > > Ayan, Henry, will the function consider_modules() be used for the MPU > code? I checked all the MPU branches (the recent arm64 implementation and an arm32 branch to my best knowledge), no I don't think the function will be used for the MPU code. However I am not sure if Ayan has a newer arm32 MPU branch on top of the latest staging or so using the function, Ayan would you like to add some comments? > If not, then I think the function should live in arm/mmu/setup.c. +1, arm/mmu/setup.c is a good place. Kind regards, Henry > > Cheers, > From xen-devel-bounces@lists.xenproject.org Sat Mar 09 06:48:43 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 09 Mar 2024 06:48:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690517.1076579 (Exim 4.92) (envelope-from ) id 1riqVd-0007Yg-Ht; Sat, 09 Mar 2024 06:48:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690517.1076579; Sat, 09 Mar 2024 06:48:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riqVd-0007YZ-Em; Sat, 09 Mar 2024 06:48:41 +0000 Received: by outflank-mailman (input) for mailman id 690517; Sat, 09 Mar 2024 06:48:40 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riqVc-0007YP-HJ; Sat, 09 Mar 2024 06:48:40 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riqVc-0003jP-Dx; Sat, 09 Mar 2024 06:48:40 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1riqVc-0000Mh-2s; Sat, 09 Mar 2024 06:48:40 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1riqVc-0006WF-2S; Sat, 09 Mar 2024 06:48:40 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=aDYFS242V4NI7+0OScDaCqs/YCJtxiT+94E8T8RZHls=; b=3gKAAQD/HTOpHXHvAB3pdUvVwj Q/jdytWPQwiH5sayAODDd7Zc0AgHWRy1wgKj/Tw+XVA1/0g5ZIWITAhTKB4N9NRuwP++38RocS0Wq EQ7Ap5ecQWVZ3anO+KLOtObHhH2AZ3tnyig2gYGin90b1BOBrAHQwoqjhnrSa6hJfLPE=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-linus test] 184961: regressions - FAIL X-Osstest-Failures: linux-linus:test-armhf-armhf-xl-credit1:xen-boot:fail:regression linux-linus:build-arm64-pvops:kernel-build:fail:regression linux-linus:test-arm64-arm64-examine:build-check(1):blocked:nonblocking linux-linus:test-arm64-arm64-libvirt-raw:build-check(1):blocked:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking linux-linus:test-arm64-arm64-xl:build-check(1):blocked:nonblocking linux-linus:test-arm64-arm64-xl-credit1:build-check(1):blocked:nonblocking linux-linus:test-arm64-arm64-xl-credit2:build-check(1):blocked:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:build-check(1):blocked:nonblocking linux-linus:test-arm64-arm64-xl-vhd:build-check(1):blocked:nonblocking linux-linus:test-arm64-arm64-xl-xsm:build-check(1):blocked:nonblocking linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: linux=10d48d70e82d7d19eb9157fdb599bfce4a5768bc X-Osstest-Versions-That: linux=3aaa8ce7a3350d95b241046ae2401103a4384ba2 From: osstest service owner Date: Sat, 09 Mar 2024 06:48:40 +0000 flight 184961 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/184961/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-credit1 8 xen-boot fail REGR. vs. 184942 build-arm64-pvops 6 kernel-build fail REGR. vs. 184942 Tests which did not succeed, but are not blocking: test-arm64-arm64-examine 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-raw 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit1 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-thunderx 1 build-check(1) blocked n/a test-arm64-arm64-xl-vhd 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop fail like 184942 test-armhf-armhf-libvirt 16 saverestore-support-check fail like 184942 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop fail like 184942 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop fail like 184942 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 184942 test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail like 184942 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop fail like 184942 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184942 test-amd64-amd64-libvirt-xsm 15 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 15 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-check fail never pass test-armhf-armhf-libvirt 15 migrate-support-check fail never pass test-amd64-amd64-libvirt-qcow2 14 migrate-support-check fail never pass test-amd64-amd64-libvirt-raw 14 migrate-support-check fail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-check fail never pass version targeted for testing: linux 10d48d70e82d7d19eb9157fdb599bfce4a5768bc baseline version: linux 3aaa8ce7a3350d95b241046ae2401103a4384ba2 Last test of basis 184942 2024-03-08 07:27:45 Z 0 days Testing same since 184961 2024-03-09 00:14:58 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Al Raj Hassain Alan Stern Alban Boyé Alex Deucher Alexander Usyskin Andi Shyti Andreas Pape Andy Chi Angel Iglesias Animesh Manna Ankit Nautiyal Antonio Borneo Badhri Jagan Sridharan Bartosz Golaszewski Chris Yokum Christoph Niedermaier Cong Yang Cosmin Tanislav Daniel Vetter Dave Airlie Dmitry Torokhov Douglas Anderson Ekansh Gupta Eugeniu Rosca Frej Drejhammar Greg Kroah-Hartman Hans de Goede Ian Abbott Imre Deak Jani Nikula Janusz Krzysztofik Javier Carrasco Jean-Baptiste Maneyrol Jiri Slaby Johan Hovold Jonathan Cameron Joonas Lahtinen Kailang Yang Karol Herbst Kees Cook Krishna Kurapati Kuninori Morimoto Li Ma Linus Torvalds Linus Walleij Ma Jun Mano Ségransan Mark Brown Mathias Krause Mathias Nyman Matthew Auld Max Nguyen Maxime Ripard Maxime Ripard Melissa Wen Mika Westerberg Neil Armstrong Nicolas Pitre Nirmoy Das Nuno Sa Paul Menzel Paul Menzel # Dell XPS 15 7590 Peter Collingbourne Pierre-Louis Bossart RD Babiera Rickard x Andersson Rob Herring Rodrigo Vivi Sherry Sun songxiebing Srinivas Kandagatla Stefan Binding Stuart Henderson Suraj Kandpal Takashi Iwai Thomas Hellstrom Thomas Hellström Thomas Zimmermann Tomas Winkler Tvrtko Ursulin Uwe Kleine-König Vasileios Amoiridis Ville Syrjälä Wentong Wu William Breathitt Gray Yeswanth Rayapati Yicong Yang jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops fail build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl blocked test-armhf-armhf-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm blocked test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm blocked test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-amd64-dom0pvh-xl-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-freebsd11-amd64 pass test-amd64-amd64-freebsd12-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-examine-bios pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 blocked test-armhf-armhf-xl-credit1 fail test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 blocked test-armhf-armhf-xl-credit2 pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine blocked test-armhf-armhf-examine pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-amd64-dom0pvh-xl-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-amd64-xl-pvshim pass test-amd64-amd64-pygrub pass test-amd64-amd64-libvirt-qcow2 pass test-armhf-armhf-libvirt-qcow2 pass test-amd64-amd64-libvirt-raw pass test-arm64-arm64-libvirt-raw blocked test-armhf-armhf-libvirt-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-arm64-arm64-xl-thunderx blocked test-amd64-amd64-examine-uefi pass test-amd64-amd64-xl-vhd pass test-arm64-arm64-xl-vhd blocked test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these 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 2183 lines long.) From xen-devel-bounces@lists.xenproject.org Sat Mar 09 08:11:46 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 09 Mar 2024 08:11:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690539.1076595 (Exim 4.92) (envelope-from ) id 1rirnm-0005TH-29; Sat, 09 Mar 2024 08:11:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690539.1076595; Sat, 09 Mar 2024 08:11:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rirnl-0005TA-UE; Sat, 09 Mar 2024 08:11:29 +0000 Received: by outflank-mailman (input) for mailman id 690539; Sat, 09 Mar 2024 08:11:28 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rirnk-0005T0-Ot; Sat, 09 Mar 2024 08:11:28 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rirnk-0005td-KB; Sat, 09 Mar 2024 08:11:28 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rirnk-0005Lh-AL; Sat, 09 Mar 2024 08:11:28 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rirnk-0006aJ-9v; Sat, 09 Mar 2024 08:11:28 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=CLmO8gDKZrODaSwxlsMfcoO5P6d91FeMnsLf0WWyE38=; b=Cxg1gQQP1W8yavCsHWBiC2ZKlR LA1hm0VTKsxoQVxALENzfkHX+Tu41KO06RBlyFzpE+5bhcfbLEhXy2SaBn/frUV5y2jKGR5LPJ2ED aB5Q1OIzeABuuyHAjcbOzppFgX0lp7+Fla/o42/X9RiBxfZkScldPvZsTfzp+sbfQKHc=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable test] 184946: regressions - trouble: fail/pass/starved X-Osstest-Failures: xen-unstable:test-amd64-amd64-livepatch:livepatch-run:fail:regression xen-unstable:test-amd64-i386-livepatch:livepatch-run:fail:regression xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:hosts-allocate:starved:nonblocking xen-unstable:test-arm64-arm64-xl-vhd:hosts-allocate:starved:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:hosts-allocate:starved:nonblocking X-Osstest-Versions-This: xen=90173fc5a2a826bbcabde22af405d0a617818b70 X-Osstest-Versions-That: xen=66c8e9b76c61ff52cfc0b186a38208907845d093 From: osstest service owner Date: Sat, 09 Mar 2024 08:11:28 +0000 flight 184946 xen-unstable real [real] flight 184970 xen-unstable real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/184946/ http://logs.test-lab.xenproject.org/osstest/logs/184970/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-livepatch 13 livepatch-run fail REGR. vs. 184927 test-amd64-i386-livepatch 13 livepatch-run fail REGR. vs. 184927 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop fail blocked in 184927 test-armhf-armhf-libvirt 16 saverestore-support-check fail like 184927 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop fail like 184927 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 184927 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop fail like 184927 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 184927 test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail like 184927 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 184927 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop fail like 184927 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 184927 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184927 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 184927 test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-check fail never pass test-amd64-i386-xl-pvshim 14 guest-start fail never pass test-amd64-i386-libvirt 15 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-check fail never pass test-arm64-arm64-xl 15 migrate-support-check fail never pass test-arm64-arm64-xl 16 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 15 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-check fail never pass test-armhf-armhf-libvirt 15 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-check fail never pass test-amd64-i386-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 3 hosts-allocate starved n/a test-arm64-arm64-xl-vhd 3 hosts-allocate starved n/a test-arm64-arm64-xl-credit2 3 hosts-allocate starved n/a version targeted for testing: xen 90173fc5a2a826bbcabde22af405d0a617818b70 baseline version: xen 66c8e9b76c61ff52cfc0b186a38208907845d093 Last test of basis 184927 2024-03-07 00:10:52 Z 2 days Testing same since 184940 2024-03-07 19:47:48 Z 1 days 2 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Anthony PERARD Henry Wang Jan Beulich Juergen Gross Oleksii Kurochko jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm starved test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-dom0pvh-xl-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-qemuu-freebsd11-amd64 pass test-amd64-amd64-qemuu-freebsd12-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-examine-bios pass test-amd64-i386-examine-bios pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 starved test-armhf-armhf-xl-credit2 pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-dom0pvh-xl-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch fail test-amd64-i386-livepatch fail test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-armhf-armhf-libvirt-qcow2 pass test-amd64-amd64-xl-qcow2 pass test-arm64-arm64-libvirt-raw pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-libvirt-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-examine-uefi pass test-amd64-i386-examine-uefi pass test-amd64-amd64-libvirt-vhd pass test-arm64-arm64-xl-vhd starved test-armhf-armhf-xl-vhd pass test-amd64-i386-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these 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 90173fc5a2a826bbcabde22af405d0a617818b70 Author: Henry Wang Date: Thu Mar 7 21:56:16 2024 +0800 tools/9pfsd: Fix build error caused by strerror_r Below error can be seen when doing Yocto build of the toolstack: | io.c: In function 'p9_error': | io.c:684:5: error: ignoring return value of 'strerror_r' declared with attribute 'warn_unused_result' [-Werror=unused-result] | 684 | strerror_r(err, ring->buffer, ring->ring_size); | | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | cc1: all warnings being treated as errors Using strerror_r() without special casing different build environments is impossible due to the different return types (int vs char *) depending on the environment. As p9_error() is not on a performance critical path, using strerror() with a mutex ought to be fine. So, fix the build by using strerror() to replace strerror_r(). The steps would then become: Acquire the mutex first, invoke strerror(), copy the string from strerror() to the designated buffer and then drop the mutex. Fixes: f4900d6d69b5 ("9pfsd: allow building with old glibc") Signed-off-by: Henry Wang Reviewed-by: Jan Beulich Reviewed-by: Juergen Gross Acked-by: Anthony PERARD commit b52c45b1bdf04469495dd046ba15dd35a8becfa5 Author: Juergen Gross Date: Wed Mar 6 12:16:31 2024 +0100 MAINTAINERS: add an entry for tools/9pfsd Add me as the maintainer for the tools/9pfsd directory. Signed-off-by: Juergen Gross Reviewed-by: Andrew Cooper commit b083b1c393dc8961acf0959b1d2e0ad459985ae3 Author: Andrew Cooper Date: Tue Mar 5 11:39:19 2024 +0000 x86/livepatch: Relax permissions on rodata too This reinstates the capability to patch .rodata in load/unload hooks, which was lost when we stopped using CR0.WP=0 to patch. This turns out to be rather less of a large TODO than I thought at the time. Fixes: 8676092a0f16 ("x86/livepatch: Fix livepatch application when CET is active") Signed-off-by: Andrew Cooper Reviewed-by: Roger Pau Monné Reviewed-by: Ross Lagerwall commit ef969144a425e39f5b214a875b5713d0ea8575fb Author: Andrew Cooper Date: Tue Mar 5 11:35:12 2024 +0000 xen/virtual-region: Include rodata pointers These are optional. .init doesn't distinguish types of data like this, and livepatches don't necesserily have any .rodata either. No functional change. Signed-off-by: Andrew Cooper Reviewed-by: Roger Pau Monné Reviewed-by: Ross Lagerwall commit 989556c6f8ca080f5f202417af97d1188b9ba52a Author: Andrew Cooper Date: Tue Mar 5 11:28:33 2024 +0000 xen/virtual-region: Rename the start/end fields ... to text_{start,end}. We're about to introduce another start/end pair. Despite it's name, struct virtual_region has always been a module-ish description. Call this out specifically. As minor cleanup, replace ROUNDUP(x, PAGE_SIZE) with the more concise PAGE_ALIGN() ahead of duplicating the example. No functional change. Signed-off-by: Andrew Cooper Reviewed-by: Roger Pau Monné Reviewed-by: Ross Lagerwall commit 08bb338f09a54d3b39f0d952bbd67461d8e5d0ed Author: Juergen Gross Date: Thu Mar 7 09:18:04 2024 +0100 SUPPORT.md: add xen-9pfsd Add a support statement for the new xen-9pfsd backend. Set it to "Experimental", as some functionality for Linux guests is missing (only tested to work with Xenstore-stubdom). Signed-off-by: Juergen Gross Acked-by: Jan Beulich commit 49b664f5bffa3a86734c66491d7dcdebbdecfb26 Author: Jan Beulich Date: Thu Mar 7 09:17:26 2024 +0100 x86/asm: add commas to further macros definitions/invocations In light of recent observations with how macros are handled by gas, let's play by what we informally set for ourselves as a guideline: Use commas to separate parameters/arguments. Requested-by: Andrew Cooper Signed-off-by: Jan Beulich Acked-by: Andrew Cooper commit 4ad4df0964aa374562fa574d4671d278f54f5d32 Author: Juergen Gross Date: Thu Mar 7 09:16:53 2024 +0100 CHANGELOG: add an entry for 9pfsd Add an entry to CHANGELOG.md regarding the new xen-9pfsd daemon. Signed-off-by: Juergen Gross Acked-by: Oleksii Kurochko commit 9249a441c98ff063c0c065538b419a3bf1dac24a Author: Jan Beulich Date: Thu Mar 7 09:16:13 2024 +0100 x86/asm: add commas to BUILD_BUG_ON In light of recent observations with how macros are handled by gas, let's play by what we informally set for ourselves as a guideline: Use commas to separate parameters/arguments. Signed-off-by: Jan Beulich Acked-by: Andrew Cooper commit 5daf46b439454921c19ca30840bb39424b36444b Author: Jan Beulich Date: Thu Mar 7 09:15:17 2024 +0100 Kbuild: simplify as-insn a little As of 732571959f17 ("xen/build: use new $(c_flags) and $(a_flags) instead of $(CFLAGS)") -M options aren't part of CFLAGS anymore, and c_flags isn't supposed to be passed to this macro. Drop the now dead part of filtering. Signed-off-by: Jan Beulich Reviewed-by: Anthony PERARD commit 2f7481d59255680c1de98f43467d3862453dd50a Author: Jan Beulich Date: Thu Mar 7 09:14:55 2024 +0100 x86/EFI: correct compiler probing Passing in $(CFLAGS) means also requesting inclusion of certain headers (via -include command line options). That's particularly xen/config.h, which in turn requires generated/autoconf.h. This has not caused any problems so far only because arch.mk is processed twice, and the missing header on the 1st pass would be there on the 2nd. Having added an inclusion of asm/asm-macros.h to x86'es asm/config.h, the 2nd pass then also fails on an initial, pristine build. As per dd40177c1bc8 ("x86-64/EFI: add CFLAGS to check compile") dropping the use of $(CFLAGS) altogether isn't an option, though. Hence remove the problematic options only. Signed-off-by: Jan Beulich Reviewed-by: Anthony PERARD (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Sat Mar 09 11:52:27 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 09 Mar 2024 11:52:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690901.1076617 (Exim 4.92) (envelope-from ) id 1rivFM-0008Bu-32; Sat, 09 Mar 2024 11:52:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690901.1076617; Sat, 09 Mar 2024 11:52:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rivFL-0008Bm-Tu; Sat, 09 Mar 2024 11:52:11 +0000 Received: by outflank-mailman (input) for mailman id 690901; Sat, 09 Mar 2024 11:52:10 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rivFK-0008Bc-Kx; Sat, 09 Mar 2024 11:52:10 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rivFK-0001hz-K4; Sat, 09 Mar 2024 11:52:10 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rivFK-0001uS-9s; Sat, 09 Mar 2024 11:52:10 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rivFK-0004N0-9M; Sat, 09 Mar 2024 11:52:10 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=543qRhnNOv11VmTygzqYMKJc4I3DfnuRUdI7Do4vFA4=; b=fL+vPF3125OfFEav5gLTssyUTN pe8LpRpNwTu+v+Cu+VjEc++q/tu7/MV00ueCA44OTh9bq+tNqtf1pPu7RTMiJotR5H93D8R++sQak MV6E6l7HxqD9qgCb7TAgwWZERgdhQy+M+X38qTsV/6zI/CLyK/OIGoku+Yju4bmZGR2U=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [seabios test] 184972: tolerable FAIL - PUSHED X-Osstest-Failures: seabios:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking seabios:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking seabios:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking seabios:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking seabios:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking seabios:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking seabios:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: seabios=163fd9f0872f95366cfe34eb11568934c2d2fe29 X-Osstest-Versions-That: seabios=82faf1d5c8b25375b9029f2d6668135e62455a8c From: osstest service owner Date: Sat, 09 Mar 2024 11:52:10 +0000 flight 184972 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/184972/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop fail like 184478 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 184478 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184478 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop fail like 184478 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 184478 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass version targeted for testing: seabios 163fd9f0872f95366cfe34eb11568934c2d2fe29 baseline version: seabios 82faf1d5c8b25375b9029f2d6668135e62455a8c Last test of basis 184478 2024-01-26 16:12:35 Z 42 days Testing same since 184972 2024-03-09 07:11:10 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Igor Mammedov 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-pvops pass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-qemuu-freebsd11-amd64 pass test-amd64-amd64-qemuu-freebsd12-amd64 pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/seabios.git 82faf1d..163fd9f 163fd9f0872f95366cfe34eb11568934c2d2fe29 -> xen-tested-master From xen-devel-bounces@lists.xenproject.org Sat Mar 09 14:09:33 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 09 Mar 2024 14:09:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690940.1076646 (Exim 4.92) (envelope-from ) id 1rixNu-0007Xg-Rq; Sat, 09 Mar 2024 14:09:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690940.1076646; Sat, 09 Mar 2024 14:09:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rixNu-0007XZ-Nx; Sat, 09 Mar 2024 14:09:10 +0000 Received: by outflank-mailman (input) for mailman id 690940; Sat, 09 Mar 2024 14:09:09 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rixNt-0007XP-38; Sat, 09 Mar 2024 14:09:09 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rixNs-0004Hn-UM; Sat, 09 Mar 2024 14:09:08 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rixNs-0001iI-JM; Sat, 09 Mar 2024 14:09:08 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rixNs-00064H-Iy; Sat, 09 Mar 2024 14:09:08 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Message-Id:Subject:To; bh=5FiXmiKJDZQTWUlKmQRfF+CrJoSRajSm1i5ZgYzFC3c=; b=5sxfq0ZvmKQMSaDTIEAnKQkOeG aPF/rGUA2tV6Q2PIy5ZVAV0nvTC/quYgBzlmqBvWaW6OHBf/4U8lEsPXpyMOy9R+Zz/IgON/ZA6jE t1lXvsatYSk15gzaxJKcQr3eKLJseVLzU9XXrYErP0nJTIVA2ONdHi/imJT/kXABcUC4=; To: xen-devel@lists.xenproject.org Subject: [xen-unstable bisection] complete test-amd64-i386-livepatch Message-Id: From: osstest service owner Date: Sat, 09 Mar 2024 14:09:08 +0000 branch xen-unstable xenbranch xen-unstable job test-amd64-i386-livepatch testid livepatch-run Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git 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: b083b1c393dc8961acf0959b1d2e0ad459985ae3 Bug not present: ef969144a425e39f5b214a875b5713d0ea8575fb Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/184979/ commit b083b1c393dc8961acf0959b1d2e0ad459985ae3 Author: Andrew Cooper Date: Tue Mar 5 11:39:19 2024 +0000 x86/livepatch: Relax permissions on rodata too This reinstates the capability to patch .rodata in load/unload hooks, which was lost when we stopped using CR0.WP=0 to patch. This turns out to be rather less of a large TODO than I thought at the time. Fixes: 8676092a0f16 ("x86/livepatch: Fix livepatch application when CET is active") Signed-off-by: Andrew Cooper Reviewed-by: Roger Pau Monné Reviewed-by: Ross Lagerwall For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable/test-amd64-i386-livepatch.livepatch-run.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/test-amd64-i386-livepatch.livepatch-run --summary-out=tmp/184979.bisection-summary --basis-template=184927 --blessings=real,real-bisect,real-retry xen-unstable test-amd64-i386-livepatch livepatch-run Searching for failure / basis pass: 184946 fail [host=albana1] / 184927 [host=italia0] 184919 [host=huxelrebe0] 184914 [host=nobling0] 184907 [host=huxelrebe1] 184905 [host=albana0] 184882 ok. Failure / basis pass flights: 184946 / 184882 (tree with no url: minios) (tree with no url: ovmf) (tree with no url: seabios) Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git Latest c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 90173fc5a2a826bbcabde22af405d0a617818b70 Basis pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 856664f774bd5b66301c5f9022126b61b8cb492d Generating revisions with ./adhoc-revtuple-generator git://xenbits.xen.org/linux-pvops.git#c3038e718a19fc596f7b1baba0f83d5146dc7784-c3038e718a19fc596f7b1baba0f83d5146dc7784 git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/qemu-xen-traditional.git#3d273dd05e51e5a1ffba3d98c7437ee84e8f8764-3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 git://xenbits.xen.org/qemu-xen.git#0df9387c8983e1b1e72d8c574356f57\ 2342c03e6-0df9387c8983e1b1e72d8c574356f572342c03e6 git://xenbits.xen.org/xen.git#856664f774bd5b66301c5f9022126b61b8cb492d-90173fc5a2a826bbcabde22af405d0a617818b70 Loaded 5001 nodes in revision graph Searching for test results: 184852 [host=elbling0] 184875 [host=debina1] 184882 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 856664f774bd5b66301c5f9022126b61b8cb492d 184905 [host=albana0] 184907 [host=huxelrebe1] 184914 [host=nobling0] 184919 [host=huxelrebe0] 184927 [host=italia0] 184940 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 90173fc5a2a826bbcabde22af405d0a617818b70 184964 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 856664f774bd5b66301c5f9022126b61b8cb492d 184966 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 90173fc5a2a826bbcabde22af405d0a617818b70 184968 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 f4900d6d69b534a00a2d6f8981a3bd5dc22a7c0b 184946 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 90173fc5a2a826bbcabde22af405d0a617818b70 184969 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 49b664f5bffa3a86734c66491d7dcdebbdecfb26 184973 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 ef969144a425e39f5b214a875b5713d0ea8575fb 184975 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 b083b1c393dc8961acf0959b1d2e0ad459985ae3 184976 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 ef969144a425e39f5b214a875b5713d0ea8575fb 184977 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 b083b1c393dc8961acf0959b1d2e0ad459985ae3 184978 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 ef969144a425e39f5b214a875b5713d0ea8575fb 184979 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 b083b1c393dc8961acf0959b1d2e0ad459985ae3 Searching for interesting versions Result found: flight 184882 (pass), for basis pass For basis failure, parent search stopping at c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 ef969144a425e39f5b214a875b5713d0ea8575fb, results HASH(0x55db160eb820) HASH(0x55db16100c68) HASH(0x55db1610c4e0) For basis failure, parent search stopping at c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8\ 983e1b1e72d8c574356f572342c03e6 49b664f5bffa3a86734c66491d7dcdebbdecfb26, results HASH(0x55db161081a8) For basis failure, parent search stopping at c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 f4900d6d69b534a00a2d6f8981a3bd5dc22a7c0b, results HASH(0x55db161050f8) For basis failure, parent search stopping at c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f\ 0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 856664f774bd5b66301c5f9022126b61b8cb492d, results HASH(0x55db160faaa8) HASH(0x55db160f45e8) Result found: flight 184940 (fail), for basis failure (at ancestor ~2910) Repro found: flight 184964 (pass), for basis pass Repro found: flight 184966 (fail), for basis failure 0 revisions at c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 ef969144a425e39f5b214a875b5713d0ea8575fb No revisions left to test, checking graph state. Result found: flight 184973 (pass), for last pass Result found: flight 184975 (fail), for first failure Repro found: flight 184976 (pass), for last pass Repro found: flight 184977 (fail), for first failure Repro found: flight 184978 (pass), for last pass Repro found: flight 184979 (fail), for first failure *** Found and reproduced problem changeset *** Bug is in tree: xen git://xenbits.xen.org/xen.git Bug introduced: b083b1c393dc8961acf0959b1d2e0ad459985ae3 Bug not present: ef969144a425e39f5b214a875b5713d0ea8575fb Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/184979/ commit b083b1c393dc8961acf0959b1d2e0ad459985ae3 Author: Andrew Cooper Date: Tue Mar 5 11:39:19 2024 +0000 x86/livepatch: Relax permissions on rodata too This reinstates the capability to patch .rodata in load/unload hooks, which was lost when we stopped using CR0.WP=0 to patch. This turns out to be rather less of a large TODO than I thought at the time. Fixes: 8676092a0f16 ("x86/livepatch: Fix livepatch application when CET is active") Signed-off-by: Andrew Cooper Reviewed-by: Roger Pau Monné Reviewed-by: Ross Lagerwall Revision graph left in /home/logs/results/bisect/xen-unstable/test-amd64-i386-livepatch.livepatch-run.{dot,ps,png,html,svg}. ---------------------------------------- 184979: tolerable ALL FAIL flight 184979 xen-unstable real-bisect [real] http://logs.test-lab.xenproject.org/osstest/logs/184979/ Failures :-/ but no regressions. Tests which did not succeed, including tests which could not be run: test-amd64-i386-livepatch 13 livepatch-run fail baseline untested jobs: test-amd64-i386-livepatch 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 From xen-devel-bounces@lists.xenproject.org Sat Mar 09 19:22:47 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 09 Mar 2024 19:22:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690968.1076655 (Exim 4.92) (envelope-from ) id 1rj2H9-0000M3-V7; Sat, 09 Mar 2024 19:22:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690968.1076655; Sat, 09 Mar 2024 19:22:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rj2H9-0000Lw-SP; Sat, 09 Mar 2024 19:22:31 +0000 Received: by outflank-mailman (input) for mailman id 690968; Sat, 09 Mar 2024 19:22:30 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rj2H8-0000Lp-A2 for xen-devel@lists.xenproject.org; Sat, 09 Mar 2024 19:22:30 +0000 Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [2a00:1450:4864:20::235]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 5dcb3ae4-de4a-11ee-a1ee-f123f15fe8a2; Sat, 09 Mar 2024 20:22:27 +0100 (CET) Received: by mail-lj1-x235.google.com with SMTP id 38308e7fff4ca-2d269b2ff48so48590471fa.3 for ; Sat, 09 Mar 2024 11:22:27 -0800 (PST) Received: from m1x-phil.lan ([176.176.181.237]) by smtp.gmail.com with ESMTPSA id h27-20020a170906399b00b00a3ce60b003asm1185569eje.176.2024.03.09.11.22.25 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Sat, 09 Mar 2024 11:22:26 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 5dcb3ae4-de4a-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1710012147; x=1710616947; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=9v68VdV/ZTxTWOB82N2ZE0IksCha8mce59bQC7Dz3io=; b=yEpkwDrDEK9gaMVwUMhBTD2iC76eIDs4c3mmaukr5E31sU94xeMu6QaKLxJfSo2t1j MJxXYh7ad+g/qkJJ2G632FiB2zEeYc9/djsaoD2L6mZDAwcXB1KOiOoMoYXf1lG6qj7F QBVqbi71bp1j5WJYA9bkVYdxuIzXlQ8azJgEIjI6XoLJYlsfb1+o+rMDXK1Ynf4RyNmB RUUmdea/ApF5S8CAx67ZzRuOb+uSy2pPMdTcKVV5B5+QOTWALZBJ1Fm/ER56RUyAE7sk r0qL1Mx7Rb+7AtvtX2jbf7Z85hdvoGVmmpRcwSaJ/ZHX1Fq2eFrcvd4HZmKOFEHeVKmI lpeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710012147; x=1710616947; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=9v68VdV/ZTxTWOB82N2ZE0IksCha8mce59bQC7Dz3io=; b=e6chuYUxQtZjAVvFqDUEObICxKFHeyC/U1b8GXjOGP5BYVqd0VAQ8sFIuU+BY6EcHD /c0rSwOXcm0XWFzbzma1XlU0SrgmhKzqPGKrWd285viywcZCk377ShZ3M9UNA2E9k3JP hAAI8DqjGRvpUGxFj027UOx2hsyO27l1UBC4unA0EKeFx0PqDZpbaqPsIBosiuuU7Rqu ZqG2LR/2dzMxtE+hi+gAAZBR7PwGPJnT2UCGy7XgG3WI7DoOERcZ3P3zBcLoRuAZKLA5 3wlTlhZWLW7InP4j07PcTzHuoJXiSI4l9DX5kTLILqjycRhg2grudI/uaU7DifZNtEVd NV1g== X-Forwarded-Encrypted: i=1; AJvYcCU2pc9OGjGA3nygowsQAUHrmwABysQdyWat600LL82lOF1/SghAzy9IUFRqt224IK6lTU8w9D0XCsMXyL5y2cqTp8L8/uEO9iEcE2HkKKY= X-Gm-Message-State: AOJu0YxeXDDNM4clBePbZtuZ0W5fYCLRA3jvmipHELd1ykNy1/xM11F2 2IGkGqymFu8RoRNK7LXp1gVyhHyFWQ5zjzpElkP5BALBSGM0liwAEN1mdcCx/H0= X-Google-Smtp-Source: AGHT+IEPUeAq3OvXQ6d5BNC7LVFINL5jOukf6dFmDeF5FkUQjdJ+zjK8mwm9i8o+ivn3j1gVM1bH4g== X-Received: by 2002:ac2:43d2:0:b0:513:486a:57af with SMTP id u18-20020ac243d2000000b00513486a57afmr1542144lfl.7.1710012147310; Sat, 09 Mar 2024 11:22:27 -0800 (PST) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Cc: qemu-ppc@nongnu.org, qemu-arm@nongnu.org, =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Richard Henderson , David Woodhouse , Stefano Stabellini , Anthony Perard , Paul Durrant , xen-devel@lists.xenproject.org Subject: [PULL 02/43] sysemu/xen: Forbid using Xen headers in user emulation Date: Sat, 9 Mar 2024 20:21:29 +0100 Message-ID: <20240309192213.23420-3-philmd@linaro.org> X-Mailer: git-send-email 2.41.0 In-Reply-To: <20240309192213.23420-1-philmd@linaro.org> References: <20240309192213.23420-1-philmd@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Xen is a system specific accelerator, it makes no sense to include its headers in user emulation. Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: Richard Henderson Reviewed-by: David Woodhouse Message-Id: <20231114143816.71079-3-philmd@linaro.org> --- include/sysemu/xen.h | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/include/sysemu/xen.h b/include/sysemu/xen.h index bc13ad5692..a9f591f26d 100644 --- a/include/sysemu/xen.h +++ b/include/sysemu/xen.h @@ -10,6 +10,10 @@ #ifndef SYSEMU_XEN_H #define SYSEMU_XEN_H +#ifdef CONFIG_USER_ONLY +#error Cannot include sysemu/xen.h from user emulation +#endif + #include "exec/cpu-common.h" #ifdef NEED_CPU_H @@ -26,16 +30,13 @@ extern bool xen_allowed; #define xen_enabled() (xen_allowed) -#ifndef CONFIG_USER_ONLY void xen_hvm_modified_memory(ram_addr_t start, ram_addr_t length); void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, struct MemoryRegion *mr, Error **errp); -#endif #else /* !CONFIG_XEN_IS_POSSIBLE */ #define xen_enabled() 0 -#ifndef CONFIG_USER_ONLY static inline void xen_hvm_modified_memory(ram_addr_t start, ram_addr_t length) { /* nothing */ @@ -45,7 +46,6 @@ static inline void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, { g_assert_not_reached(); } -#endif #endif /* CONFIG_XEN_IS_POSSIBLE */ -- 2.41.0 From xen-devel-bounces@lists.xenproject.org Sat Mar 09 19:22:47 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 09 Mar 2024 19:22:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690969.1076665 (Exim 4.92) (envelope-from ) id 1rj2HF-0000ap-6H; Sat, 09 Mar 2024 19:22:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690969.1076665; Sat, 09 Mar 2024 19:22:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rj2HF-0000ai-3I; Sat, 09 Mar 2024 19:22:37 +0000 Received: by outflank-mailman (input) for mailman id 690969; Sat, 09 Mar 2024 19:22:35 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rj2HD-0000Lp-9w for xen-devel@lists.xenproject.org; Sat, 09 Mar 2024 19:22:35 +0000 Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [2a00:1450:4864:20::62d]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 614e9094-de4a-11ee-a1ee-f123f15fe8a2; Sat, 09 Mar 2024 20:22:33 +0100 (CET) Received: by mail-ej1-x62d.google.com with SMTP id a640c23a62f3a-a4604c8bd61so45581866b.2 for ; Sat, 09 Mar 2024 11:22:33 -0800 (PST) Received: from m1x-phil.lan ([176.176.181.237]) by smtp.gmail.com with ESMTPSA id sd21-20020a170906ce3500b00a45f3524ac3sm1161512ejb.118.2024.03.09.11.22.32 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Sat, 09 Mar 2024 11:22:32 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 614e9094-de4a-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1710012153; x=1710616953; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=hXABjAaMhxHgVCCn4BlGHy0+qqoq0gDIyiPdTnOnZyc=; b=nPcRDCmZ1T2jOk7q0fXylebJDqvb13cUqGxZo8BL10LZ9daa+9J7fhQQHryzXPF5Pd RrkkvfcbBCXPRecf1+w4QzeupkbIsS+sPcbpdAIHrymO7dnDR57g42qeb3AR5yU8MowN NStnv9KC3DdC4MH3wXlRJj6wtKsAz3+MaEPrP81QRIwmq3MUiKPJSqR/LH+4MqJXXAKN 4fy1cBqw60WkzJW62c5RntSfd1/zaz9j97iesz5BvOjc5+je4wuKAiURoaKserUYf6Wb vsfjYLKONtslnYSgxfbcKNYmJg9T6QXoc65YU+sWfpXdeN+cXJaJBPVuf91iz5BkzS1H Ke5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710012153; x=1710616953; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=hXABjAaMhxHgVCCn4BlGHy0+qqoq0gDIyiPdTnOnZyc=; b=XE7XCw4kYToKSJ0ITTLdBDgxQsWnDFUAE3EFgbn82S6ggjLg2F1p7nn/DiK5Z2Ym5E A/m7j0ulCXZIHN5Py+sJXE4tLgltytgAi9dfm8My5+JA6B+Zkxfhm8AcCDXqOipw2LOR xQg12j1BhbLjceu6NxlKoDfexc+ye234G6xfA0Z9EL3y+X3dzGZ9REXpiteKA7h20VRi 5Sqjay8kjFG5+a3vcsqXRZXLnva+HdGpVQtwKdzwZRK6tmn5Pn79bxhu6A3FjRRrB8qG SneUwLjtqMOBbU6zddixK5p4QhOqr6BKq23ER7dCre8MnkF2lvlHJu8JH1SPyplfjAwP /T5g== X-Forwarded-Encrypted: i=1; AJvYcCVZDG3hcKf2ELc7Qe7KfW40nDAIoFcgaBavtXGWpOzMZnDniCKuCu15ZknfrNFhMjmDjVR90EnbuFSThT4+OUh99GIl49mSR5VnvxB9aZw= X-Gm-Message-State: AOJu0YzlTPJ8ICUre1QqLAwQIF8iLAu6yid/fKm5yWsv5tLwJlu4a6Vi oWEEkNKg2SvdPuuyZ5XnxLsKQwMeJqIxSYSpgqj23di4qmqXTkLN3A4Rre0+f2s= X-Google-Smtp-Source: AGHT+IG1/vyvQGvmM09S/M6+IuzayHPuZieilQc2Rg23/rY/x2WN2KV9nhRWH7snP7zUoE6gG7SZXw== X-Received: by 2002:a17:906:4f02:b0:a44:446b:e99e with SMTP id t2-20020a1709064f0200b00a44446be99emr1256763eju.31.1710012153357; Sat, 09 Mar 2024 11:22:33 -0800 (PST) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Cc: qemu-ppc@nongnu.org, qemu-arm@nongnu.org, =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , David Woodhouse , Stefano Stabellini , Anthony Perard , Paul Durrant , xen-devel@lists.xenproject.org Subject: [PULL 03/43] sysemu/xen-mapcache: Check Xen availability with CONFIG_XEN_IS_POSSIBLE Date: Sat, 9 Mar 2024 20:21:30 +0100 Message-ID: <20240309192213.23420-4-philmd@linaro.org> X-Mailer: git-send-email 2.41.0 In-Reply-To: <20240309192213.23420-1-philmd@linaro.org> References: <20240309192213.23420-1-philmd@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit "sysemu/xen.h" defines CONFIG_XEN_IS_POSSIBLE as a target-agnostic version of CONFIG_XEN accelerator. Use it in order to use "sysemu/xen-mapcache.h" in target-agnostic files. Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: David Woodhouse Message-Id: <20231114143816.71079-4-philmd@linaro.org> --- include/sysemu/xen-mapcache.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/include/sysemu/xen-mapcache.h b/include/sysemu/xen-mapcache.h index c8e7c2f6cf..10c2e3082a 100644 --- a/include/sysemu/xen-mapcache.h +++ b/include/sysemu/xen-mapcache.h @@ -10,10 +10,11 @@ #define XEN_MAPCACHE_H #include "exec/cpu-common.h" +#include "sysemu/xen.h" typedef hwaddr (*phys_offset_to_gaddr_t)(hwaddr phys_offset, ram_addr_t size); -#ifdef CONFIG_XEN +#ifdef CONFIG_XEN_IS_POSSIBLE void xen_map_cache_init(phys_offset_to_gaddr_t f, void *opaque); -- 2.41.0 From xen-devel-bounces@lists.xenproject.org Sat Mar 09 19:22:54 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 09 Mar 2024 19:22:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690970.1076675 (Exim 4.92) (envelope-from ) id 1rj2HW-00010k-Cd; Sat, 09 Mar 2024 19:22:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690970.1076675; Sat, 09 Mar 2024 19:22:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rj2HW-00010b-A1; Sat, 09 Mar 2024 19:22:54 +0000 Received: by outflank-mailman (input) for mailman id 690970; Sat, 09 Mar 2024 19:22:52 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rj2HU-0000Lp-QP for xen-devel@lists.xenproject.org; Sat, 09 Mar 2024 19:22:52 +0000 Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [2a00:1450:4864:20::532]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 6bb07afb-de4a-11ee-a1ee-f123f15fe8a2; Sat, 09 Mar 2024 20:22:51 +0100 (CET) Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-5683576ea18so1629602a12.3 for ; Sat, 09 Mar 2024 11:22:51 -0800 (PST) Received: from m1x-phil.lan ([176.176.181.237]) by smtp.gmail.com with ESMTPSA id y18-20020a056402359200b005648d0eebdbsm1141497edc.96.2024.03.09.11.22.49 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Sat, 09 Mar 2024 11:22:50 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6bb07afb-de4a-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1710012171; x=1710616971; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=cFjMT6zDVz6FC8tPUCQ4kyyMrqKZ8chKsrslRHOyQyw=; b=hqWP6DRWgkzN45MOE2UT7rnZNTDaIdFeIGsBI7g0SFhcDByj9VNMn4tkv4RkII1SMW 3et43EGjnaA6tmM/e49eWaloOqs0OeRtSmK7+27UnNt+1+vmhsyVezXIBVBSUePwhDnn YljL/icdZ9C6eIM2fRZWl9vWbP7F8bva/HIM/qnIFizRllMbpTE+/0Ez8ge/pQkRxM6V LIvd69B9wZaPNnCBlQyFv0FELtqvtzvrbRN/B3jHjqM6tSM5ci9A4+7Y+jJpwHmt9sxv SesTlMfqleuwZDPUXf1qIHRV/39FHXMAlqDI6wvu0Vntz2+SJGh4/f+ERpI2A7r89NwB 9YRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710012171; x=1710616971; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=cFjMT6zDVz6FC8tPUCQ4kyyMrqKZ8chKsrslRHOyQyw=; b=ah1+w6EQNqYaIt4ubwFX5YbS0FOAXpCYkuCY1YuoeDv8DDYT0EnYeziSEHOCIez9lc 5eEANgEvD/gQgRqBktDfwfq5/RVih/KAeg6SNZNqQMcEb2RnZniSfZmySWAzYUyawcAq LwrPcXbXktZ9CIrT3PDdSHLahjTPO5IrD03OtjtAv25bSPdeLi5DnJoCsTr01tH0uiAM mPNFniOVVWWxh5RQnbmXzGa5TAtljJMej4icu+W6rsHW6v46900LNTEgwSbkgUJYieHd iDOSXJ2syHdJ/jFh1RNXk0RNqCtGxs8GOFbAGCpNBUqDmpyoKhXoy0PRfNQ+x/Obh4IW pPOw== X-Forwarded-Encrypted: i=1; AJvYcCVQCkqfxWCRSkkgpRcKFSYWX+cQS0YKgnFEVjCPXuhMkgw2/ngsIiY+GpX6d4DHuLa6kfeO9SWRCbXl+ge8Us8X0dmQ2sf3SuSFPBiFvmM= X-Gm-Message-State: AOJu0Yz/B2TMgwHavTWwAnetKgB7Z2QIN+xWC8QgYIo/HZMHK+1YPtJo 9QRxoIfdqTQ8KfwqT+PfU+ZUUHTO/z/+aCyJ5S6GmWZ3Qwlf4ZEDNtTyWr5TMc4= X-Google-Smtp-Source: AGHT+IEOGwIBYdP/mzwuHWgPMjU0SlF6nHZcYJJa0Wt9irOScU0CVSd5Ssk82Pi/m/B9Cv/46kpyew== X-Received: by 2002:a50:934a:0:b0:568:1882:651f with SMTP id n10-20020a50934a000000b005681882651fmr1774495eda.25.1710012170814; Sat, 09 Mar 2024 11:22:50 -0800 (PST) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Cc: qemu-ppc@nongnu.org, qemu-arm@nongnu.org, =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , David Woodhouse , Stefano Stabellini , Anthony Perard , Paul Durrant , Paolo Bonzini , xen-devel@lists.xenproject.org Subject: [PULL 06/43] hw/xen: Remove unnecessary xen_hvm_inject_msi() stub Date: Sat, 9 Mar 2024 20:21:33 +0100 Message-ID: <20240309192213.23420-7-philmd@linaro.org> X-Mailer: git-send-email 2.41.0 In-Reply-To: <20240309192213.23420-1-philmd@linaro.org> References: <20240309192213.23420-1-philmd@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Since commit 04b0de0ee8 ("xen: factor out common functions") xen_hvm_inject_msi() stub is not required. Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: David Woodhouse Message-Id: <20231114143816.71079-8-philmd@linaro.org> --- stubs/xen-hw-stub.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/stubs/xen-hw-stub.c b/stubs/xen-hw-stub.c index 7d7ffe83a9..6cf0e9a4c1 100644 --- a/stubs/xen-hw-stub.c +++ b/stubs/xen-hw-stub.c @@ -24,10 +24,6 @@ int xen_set_pci_link_route(uint8_t link, uint8_t irq) return -1; } -void xen_hvm_inject_msi(uint64_t addr, uint32_t data) -{ -} - int xen_is_pirq_msi(uint32_t msi_data) { return 0; -- 2.41.0 From xen-devel-bounces@lists.xenproject.org Sat Mar 09 19:23:01 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 09 Mar 2024 19:23:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690971.1076685 (Exim 4.92) (envelope-from ) id 1rj2Hd-0001Ry-Jk; Sat, 09 Mar 2024 19:23:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690971.1076685; Sat, 09 Mar 2024 19:23:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rj2Hd-0001Rr-Gp; Sat, 09 Mar 2024 19:23:01 +0000 Received: by outflank-mailman (input) for mailman id 690971; Sat, 09 Mar 2024 19:22:59 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rj2Hb-0001PG-TJ for xen-devel@lists.xenproject.org; Sat, 09 Mar 2024 19:22:59 +0000 Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [2a00:1450:4864:20::12a]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 6f7053c8-de4a-11ee-afdb-a90da7624cb6; Sat, 09 Mar 2024 20:22:58 +0100 (CET) Received: by mail-lf1-x12a.google.com with SMTP id 2adb3069b0e04-51321e71673so3517333e87.2 for ; Sat, 09 Mar 2024 11:22:57 -0800 (PST) Received: from m1x-phil.lan ([176.176.181.237]) by smtp.gmail.com with ESMTPSA id 24-20020a508e58000000b00566f92f1facsm1220206edx.36.2024.03.09.11.22.55 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Sat, 09 Mar 2024 11:22:56 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6f7053c8-de4a-11ee-afdb-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1710012177; x=1710616977; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=5TjXBOuAt82J0vCEpvih+prFEkSXa24TTOPlq290ir4=; b=dzI5nZudVzm/07E0dJ9+u14kaSFAahpYErUiYSNzNJhul0vvQZDBs9hXURwhEZIWAn ZuugjowlFPVIoz1DoWViIKiq99K2e9hBs7i8hM7F2YzZUAqgfwqUQP/92SW0Alin5WJA iSLk0EYLvMTuXYmVjXsCdsSMAmxTCcxLSLKNoEsU5jYVdrNSCUJh3A91GY2P8UtPxlX6 6bAgRLxzE0sVEX+XRrFPda482zJI3JoYfHkp1dt29S9tZ0NNeEFvsZZVAKLB2jNc01LU 8rZGOnbOgy2PMp6TJ/xDB2eVXgSyRPhhZybwL1JeOCRnXGL8TVuhi4Z+jjX0LcZg/+sS wSvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710012177; x=1710616977; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=5TjXBOuAt82J0vCEpvih+prFEkSXa24TTOPlq290ir4=; b=XRMLEBxjYPXa0/+Whv56TeWKN1acN0fEWtZ0qj7lJTIYFvF7fF2siiGaW+3lI1xVGP gBKVN2AmnrRfc7dsrG4Ngujbo8Z87J1IaLHQCLIL2At0Udf34KQfe0MXO03fRn3D/fp1 lUbY/mgfFLVDU8W+9qjUmgoNl25gVCSQ1Ll92HkSZefxcZjwUnBXdYtLGtMNZ4Ca63P8 XXsvVu4/Dnc0uMsfULvZWaU3eMnUV39ktvNDlNu0SFJU1nb2562d+UxMeUVgr3IncOBR bSByvxzf65Qs5O5PiyGvANKkQYPvRYrM3CqvkADWTnYmjNVxx4D7fNejIq+4/Bja7l3u H0DQ== X-Forwarded-Encrypted: i=1; AJvYcCWunoYpHV5tDT7QbgJZDW7O5Ozc5o1hH0LKALvVRCHIvVVoxAqCX5HLAtq/fcNZ1LAtLMyj2/pjKas2f7fMa62LDaqpB/Z6PyZwuouI1yA= X-Gm-Message-State: AOJu0YzKjwsgbjBMiQpxa5dd0qVs/F/ArWbypje2EZyg5ZfOq95WCBpZ pRpK6BbI0byag2fgBk61Ve9C0xBoJ2sK11HhhjPRH9QXBMUmn3gxg96kmdP0LHw= X-Google-Smtp-Source: AGHT+IFu3iF5YfsPHFl4QgKzLThNg0KEglVlBZvKN0xPMmy0J9g6tryab3kSYkTuJAqwUaCGcPfaPg== X-Received: by 2002:a19:ae17:0:b0:512:d6b6:dc44 with SMTP id f23-20020a19ae17000000b00512d6b6dc44mr1371505lfc.66.1710012177076; Sat, 09 Mar 2024 11:22:57 -0800 (PST) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Cc: qemu-ppc@nongnu.org, qemu-arm@nongnu.org, =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , David Woodhouse , Peter Maydell , Stefano Stabellini , Anthony Perard , Paul Durrant , "Michael S. Tsirkin" , Marcel Apfelbaum , Paolo Bonzini , Richard Henderson , Eduardo Habkost , xen-devel@lists.xenproject.org Subject: [PULL 07/43] hw/xen: Rename 'ram_memory' global variable as 'xen_memory' Date: Sat, 9 Mar 2024 20:21:34 +0100 Message-ID: <20240309192213.23420-8-philmd@linaro.org> X-Mailer: git-send-email 2.41.0 In-Reply-To: <20240309192213.23420-1-philmd@linaro.org> References: <20240309192213.23420-1-philmd@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit To avoid a potential global variable shadow in hw/i386/pc_piix.c::pc_init1(), rename Xen's "ram_memory" as "xen_memory". Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: David Woodhouse Message-Id: <20231114143816.71079-11-philmd@linaro.org> --- include/hw/xen/xen-hvm-common.h | 2 +- hw/arm/xen_arm.c | 6 +++--- hw/i386/xen/xen-hvm.c | 10 +++++----- hw/xen/xen-hvm-common.c | 6 +++--- 4 files changed, 12 insertions(+), 12 deletions(-) diff --git a/include/hw/xen/xen-hvm-common.h b/include/hw/xen/xen-hvm-common.h index 4b1d728f35..65a51aac2e 100644 --- a/include/hw/xen/xen-hvm-common.h +++ b/include/hw/xen/xen-hvm-common.h @@ -15,7 +15,7 @@ #include "qemu/error-report.h" #include -extern MemoryRegion ram_memory; +extern MemoryRegion xen_memory; extern MemoryListener xen_io_listener; extern DeviceListener xen_device_listener; diff --git a/hw/arm/xen_arm.c b/hw/arm/xen_arm.c index 32776d94df..15fa7dfa84 100644 --- a/hw/arm/xen_arm.c +++ b/hw/arm/xen_arm.c @@ -114,14 +114,14 @@ static void xen_init_ram(MachineState *machine) block_len = GUEST_RAM1_BASE + ram_size[1]; } - memory_region_init_ram(&ram_memory, NULL, "xen.ram", block_len, + memory_region_init_ram(&xen_memory, NULL, "xen.ram", block_len, &error_fatal); - memory_region_init_alias(&ram_lo, NULL, "xen.ram.lo", &ram_memory, + memory_region_init_alias(&ram_lo, NULL, "xen.ram.lo", &xen_memory, GUEST_RAM0_BASE, ram_size[0]); memory_region_add_subregion(sysmem, GUEST_RAM0_BASE, &ram_lo); if (ram_size[1] > 0) { - memory_region_init_alias(&ram_hi, NULL, "xen.ram.hi", &ram_memory, + memory_region_init_alias(&ram_hi, NULL, "xen.ram.hi", &xen_memory, GUEST_RAM1_BASE, ram_size[1]); memory_region_add_subregion(sysmem, GUEST_RAM1_BASE, &ram_hi); } diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c index f42621e674..1ae943370b 100644 --- a/hw/i386/xen/xen-hvm.c +++ b/hw/i386/xen/xen-hvm.c @@ -149,12 +149,12 @@ static void xen_ram_init(PCMachineState *pcms, */ block_len = (4 * GiB) + x86ms->above_4g_mem_size; } - memory_region_init_ram(&ram_memory, NULL, "xen.ram", block_len, + memory_region_init_ram(&xen_memory, NULL, "xen.ram", block_len, &error_fatal); - *ram_memory_p = &ram_memory; + *ram_memory_p = &xen_memory; memory_region_init_alias(&ram_640k, NULL, "xen.ram.640k", - &ram_memory, 0, 0xa0000); + &xen_memory, 0, 0xa0000); memory_region_add_subregion(sysmem, 0, &ram_640k); /* Skip of the VGA IO memory space, it will be registered later by the VGA * emulated device. @@ -163,12 +163,12 @@ static void xen_ram_init(PCMachineState *pcms, * the Options ROM, so it is registered here as RAM. */ memory_region_init_alias(&ram_lo, NULL, "xen.ram.lo", - &ram_memory, 0xc0000, + &xen_memory, 0xc0000, x86ms->below_4g_mem_size - 0xc0000); memory_region_add_subregion(sysmem, 0xc0000, &ram_lo); if (x86ms->above_4g_mem_size > 0) { memory_region_init_alias(&ram_hi, NULL, "xen.ram.hi", - &ram_memory, 0x100000000ULL, + &xen_memory, 0x100000000ULL, x86ms->above_4g_mem_size); memory_region_add_subregion(sysmem, 0x100000000ULL, &ram_hi); } diff --git a/hw/xen/xen-hvm-common.c b/hw/xen/xen-hvm-common.c index baa1adb9f2..dc69cada57 100644 --- a/hw/xen/xen-hvm-common.c +++ b/hw/xen/xen-hvm-common.c @@ -9,7 +9,7 @@ #include "hw/boards.h" #include "hw/xen/arch_hvm.h" -MemoryRegion ram_memory; +MemoryRegion xen_memory; void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, MemoryRegion *mr, Error **errp) @@ -26,7 +26,7 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, MemoryRegion *mr, return; } - if (mr == &ram_memory) { + if (mr == &xen_memory) { return; } @@ -53,7 +53,7 @@ static void xen_set_memory(struct MemoryListener *listener, { XenIOState *state = container_of(listener, XenIOState, memory_listener); - if (section->mr == &ram_memory) { + if (section->mr == &xen_memory) { return; } else { if (add) { -- 2.41.0 From xen-devel-bounces@lists.xenproject.org Sat Mar 09 19:23:06 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 09 Mar 2024 19:23:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690972.1076694 (Exim 4.92) (envelope-from ) id 1rj2Hh-0001m4-VY; Sat, 09 Mar 2024 19:23:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690972.1076694; Sat, 09 Mar 2024 19:23:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rj2Hh-0001lx-SP; Sat, 09 Mar 2024 19:23:05 +0000 Received: by outflank-mailman (input) for mailman id 690972; Sat, 09 Mar 2024 19:23:05 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rj2Hh-0000Lp-6g for xen-devel@lists.xenproject.org; Sat, 09 Mar 2024 19:23:05 +0000 Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [2a00:1450:4864:20::631]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 7319aa81-de4a-11ee-a1ee-f123f15fe8a2; Sat, 09 Mar 2024 20:23:03 +0100 (CET) Received: by mail-ej1-x631.google.com with SMTP id a640c23a62f3a-a45aa7cb2b3so235244866b.3 for ; Sat, 09 Mar 2024 11:23:03 -0800 (PST) Received: from m1x-phil.lan ([176.176.181.237]) by smtp.gmail.com with ESMTPSA id x19-20020a1709064bd300b00a44e2f3024bsm1172780ejv.68.2024.03.09.11.23.01 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Sat, 09 Mar 2024 11:23:02 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 7319aa81-de4a-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1710012183; x=1710616983; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=Q44dwAJ9zWJURYp9hh0U7wvOFqEH1mwy4JxGXOeg8jA=; b=N30iY6udcSXFerUkOTtu1tk37o+Ry8uP2nm5eR32c0NFM3bWwetYf6+0lCc/gcJRwv n4RU4uw5f4HcQAYtEh+uzrUMpUj+S4gQQMu/R5eCIU9bQycAGYMLQy/AYJpCq0drQCkT Ki/ZXHtD6AuBed6P2KXaaqKt+PEblN/CEXiZ2PQAxyzk+nVeGCPCz97KEt1lcHg0pVXK Sb7bAetNJ2MUZHGXsZvWoyKzE6+Abf/g6gBs+0zPQretHSj2iTd/wKMXVxSIKhHK3fct oWMRFgEhaftQYn0JrVXY1NQS0D+iPNu/+mwYar+LnzRtFeS9SIeMTsykHDgECBV690iO D9qQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710012183; x=1710616983; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Q44dwAJ9zWJURYp9hh0U7wvOFqEH1mwy4JxGXOeg8jA=; b=P/JbiVpwvMXPgWTHwmQ0pQxKK2pmFEXMNyROXY/HB5hYAUDyCt6qCOjjOyVqsFQBDm LDhiHXWW9bahuPPrTFDfrwMRXGo0CzReAe01ZkF7HzLby6RlofdxEMYjv2SUc79YOlzU 1yIWWD1UD0LHUztct50VgybGrOzhL2iNGinjgugv6bsOvdT6aoABnIZ2n2TKyaNALF37 VW3U+kw3FFtCiD4FrYswZDiLYHKfL5I06+ttlQk6jmSaEVNuT1DoPmwzxb2PNULwbgAn zK45ZB/WEc6pvNRAOggNGl1jS/caTjwYTE9DnxQem1QhNc4/e2ahUZZapaW07uLIcy8d MRcg== X-Forwarded-Encrypted: i=1; AJvYcCXEgKwK+4EBszgYaiutHoTdk7SmjPbL55lzzCtmpHWWVph4dy0Xz33DHPfdkabMskPWJl6meQEpw9Fy2hypF/8MjvVWO++OUguMN+10rCE= X-Gm-Message-State: AOJu0Yy5WylpHd3eHpvorQV5G9H0gT2iofV9T+vXOU3+u/GXq+S+N9Oh /Y4UZk5AtiW7sTtLymK7cLX1qIG1DA9PQ/eVg3rCSdNxuX6YlhEvs8GN1RcDwDQ= X-Google-Smtp-Source: AGHT+IHOQkfTUB7DFZUnzFt5SN8xXU0FWBVOfPyoMZQqgOTUu5nO+XttuLhInRopNUGb3cs1S/BhDQ== X-Received: by 2002:a17:907:7898:b0:a45:119e:3dec with SMTP id ku24-20020a170907789800b00a45119e3decmr1327777ejc.73.1710012183067; Sat, 09 Mar 2024 11:23:03 -0800 (PST) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Cc: qemu-ppc@nongnu.org, qemu-arm@nongnu.org, =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Richard Henderson , David Woodhouse , Stefano Stabellini , Anthony Perard , Paul Durrant , xen-devel@lists.xenproject.org Subject: [PULL 08/43] hw/xen: Use target-agnostic qemu_target_page_bits() Date: Sat, 9 Mar 2024 20:21:35 +0100 Message-ID: <20240309192213.23420-9-philmd@linaro.org> X-Mailer: git-send-email 2.41.0 In-Reply-To: <20240309192213.23420-1-philmd@linaro.org> References: <20240309192213.23420-1-philmd@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Instead of the target-specific TARGET_PAGE_BITS definition, use qemu_target_page_bits() which is target agnostic. Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: Richard Henderson Reviewed-by: David Woodhouse Message-Id: <20231114143816.71079-15-philmd@linaro.org> --- hw/xen/xen-hvm-common.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/hw/xen/xen-hvm-common.c b/hw/xen/xen-hvm-common.c index dc69cada57..1627da7398 100644 --- a/hw/xen/xen-hvm-common.c +++ b/hw/xen/xen-hvm-common.c @@ -1,6 +1,7 @@ #include "qemu/osdep.h" #include "qemu/units.h" #include "qapi/error.h" +#include "exec/target_page.h" #include "trace.h" #include "hw/pci/pci_host.h" @@ -14,6 +15,7 @@ MemoryRegion xen_memory; void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, MemoryRegion *mr, Error **errp) { + unsigned target_page_bits = qemu_target_page_bits(); unsigned long nr_pfn; xen_pfn_t *pfn_list; int i; @@ -32,11 +34,11 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, MemoryRegion *mr, trace_xen_ram_alloc(ram_addr, size); - nr_pfn = size >> TARGET_PAGE_BITS; + nr_pfn = size >> target_page_bits; pfn_list = g_new(xen_pfn_t, nr_pfn); for (i = 0; i < nr_pfn; i++) { - pfn_list[i] = (ram_addr >> TARGET_PAGE_BITS) + i; + pfn_list[i] = (ram_addr >> target_page_bits) + i; } if (xc_domain_populate_physmap_exact(xen_xc, xen_domid, nr_pfn, 0, 0, pfn_list)) { -- 2.41.0 From xen-devel-bounces@lists.xenproject.org Sat Mar 09 19:23:11 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 09 Mar 2024 19:23:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690973.1076705 (Exim 4.92) (envelope-from ) id 1rj2Hn-0002BR-6Q; Sat, 09 Mar 2024 19:23:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690973.1076705; Sat, 09 Mar 2024 19:23:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rj2Hn-0002BK-3K; Sat, 09 Mar 2024 19:23:11 +0000 Received: by outflank-mailman (input) for mailman id 690973; Sat, 09 Mar 2024 19:23:09 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rj2Hl-0001PG-Ih for xen-devel@lists.xenproject.org; Sat, 09 Mar 2024 19:23:09 +0000 Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [2a00:1450:4864:20::230]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 7663cc5e-de4a-11ee-afdb-a90da7624cb6; Sat, 09 Mar 2024 20:23:09 +0100 (CET) Received: by mail-lj1-x230.google.com with SMTP id 38308e7fff4ca-2d29aad15a5so27055951fa.3 for ; Sat, 09 Mar 2024 11:23:09 -0800 (PST) Received: from m1x-phil.lan ([176.176.181.237]) by smtp.gmail.com with ESMTPSA id fg3-20020a056402548300b005656bbb5b3fsm1153256edb.63.2024.03.09.11.23.07 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Sat, 09 Mar 2024 11:23:08 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 7663cc5e-de4a-11ee-afdb-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1710012189; x=1710616989; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=9jsjeEWjsUkRHeCpOh+pko9UBxzZs1OaWzN0fIY08/s=; b=kbFeCqtcxyu0ZMoPR+81vtw2gCiXdwtkkXHsZzeNQfQEPGLzFwf/LZo9US35DRqPi9 JbEoUIWP087d8hLPW7k44KNXjZyvT01OHjdrulF4fybUEOJMmc/CfmQ8yYvvisOazcgB w9jjQBbeY4rl7epZ9gGoY7eXW7IQya1GX6Mrs8S/8pgHWVh/X3mUmrIUXv6T/a+lMGsy rgdcZ2KrTBWS9i8T6ByiCAXFX2eO7tCWO6Nh5uY2+4RRW1GRXqG0YE13kjp0J5RqIApD kv9CqtNIahDBdaceKpZRbn+0LbJX1rs8QWlkduoLuGe3SXMWIGX39Q9YtKfo+AYIdXQ5 DMNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710012189; x=1710616989; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=9jsjeEWjsUkRHeCpOh+pko9UBxzZs1OaWzN0fIY08/s=; b=O2T7JIMRJ66WLMyNTih1ZIB7A19BwTmODmD4ecSbYejcxD7OHERIsVcHFEC460dTiP F5fn6S6oxUnHkskPrSyxcWcAesz9WHCXyS8wsyBm9r13wGPSzVJ0ighJ+YwccMMjnEJZ wFLX7beuAkLqeEC5bd46gauYs586pqqptYAvHbc9SlmcXjwNCjT4L52icN+bJaposCwA namym6zBrezQ1x0BY/tmmg9FxM472EuzhGwAWgHyH4aOQ6bAaPESr7D0dzKcc7CrS9Kk HHFtW9XO5K/+mgP5ed4gAGWageQQCGsE4v5VBRscszT0UnCuY4/j704EiEp7vh6pmnBO JHCQ== X-Forwarded-Encrypted: i=1; AJvYcCUj/90gRVbTQvoQ3JSErjilhFs79tm0+Rlo5i1itc55bJ+pFrBNwPiXA6wqWBpz8PRhHriifPPtGpnmsdbfPzQtJpTho5iQftFF50M9ywM= X-Gm-Message-State: AOJu0Yzs7cMbCFh5+rb+nbu8SBvYIEXRaU83usxcUX8eFt8MES8nQlxX Fc2YtMzEkeCIljbbY5kvjfmxlopeQodnYC5VifSZIDlMBwX8MfurKQciXhzJsWk= X-Google-Smtp-Source: AGHT+IHVJYQKMJoF6M5h+nBzkB9MQSOKRczhtHaq4vuFR2+EzQeH6DE9+nIiaOsLgRl8gEGAHG9UzQ== X-Received: by 2002:a05:651c:61f:b0:2d4:22b6:e6a4 with SMTP id k31-20020a05651c061f00b002d422b6e6a4mr1215415lje.30.1710012188800; Sat, 09 Mar 2024 11:23:08 -0800 (PST) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Cc: qemu-ppc@nongnu.org, qemu-arm@nongnu.org, =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , David Woodhouse , Stefano Stabellini , Anthony Perard , Paul Durrant , xen-devel@lists.xenproject.org Subject: [PULL 09/43] hw/xen/xen_pt: Add missing license Date: Sat, 9 Mar 2024 20:21:36 +0100 Message-ID: <20240309192213.23420-10-philmd@linaro.org> X-Mailer: git-send-email 2.41.0 In-Reply-To: <20240309192213.23420-1-philmd@linaro.org> References: <20240309192213.23420-1-philmd@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Commit eaab4d60d3 ("Introduce Xen PCI Passthrough, qdevice") introduced both xen_pt.[ch], but only added the license to xen_pt.c. Use the same license for xen_pt.h. Suggested-by: David Woodhouse Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: David Woodhouse Message-Id: <20231114143816.71079-17-philmd@linaro.org> --- hw/xen/xen_pt.h | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/hw/xen/xen_pt.h b/hw/xen/xen_pt.h index 31bcfdf705..d3180bb134 100644 --- a/hw/xen/xen_pt.h +++ b/hw/xen/xen_pt.h @@ -1,3 +1,13 @@ +/* + * Copyright (c) 2007, Neocleus Corporation. + * Copyright (c) 2007, Intel Corporation. + * + * SPDX-License-Identifier: GPL-2.0-only + * + * Alex Novik + * Allen Kay + * Guy Zana + */ #ifndef XEN_PT_H #define XEN_PT_H -- 2.41.0 From xen-devel-bounces@lists.xenproject.org Sat Mar 09 19:23:17 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 09 Mar 2024 19:23:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690974.1076715 (Exim 4.92) (envelope-from ) id 1rj2Ht-0002de-Dz; Sat, 09 Mar 2024 19:23:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690974.1076715; Sat, 09 Mar 2024 19:23:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rj2Ht-0002dV-Ay; Sat, 09 Mar 2024 19:23:17 +0000 Received: by outflank-mailman (input) for mailman id 690974; Sat, 09 Mar 2024 19:23:16 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rj2Hs-0001PG-9Y for xen-devel@lists.xenproject.org; Sat, 09 Mar 2024 19:23:16 +0000 Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [2a00:1450:4864:20::131]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 7a608a61-de4a-11ee-afdb-a90da7624cb6; Sat, 09 Mar 2024 20:23:15 +0100 (CET) Received: by mail-lf1-x131.google.com with SMTP id 2adb3069b0e04-5131316693cso4162562e87.0 for ; Sat, 09 Mar 2024 11:23:15 -0800 (PST) Received: from m1x-phil.lan ([176.176.181.237]) by smtp.gmail.com with ESMTPSA id p16-20020a17090653d000b00a45464679b1sm1162257ejo.127.2024.03.09.11.23.13 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Sat, 09 Mar 2024 11:23:15 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 7a608a61-de4a-11ee-afdb-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1710012195; x=1710616995; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=0dapH6sMmnV9ZamVJJtysMb9yL4xw8w3bAoh22EL4Vo=; b=fHCxpYTJrujOGvx39nMCUL0k5oKD5+rHFeT5I+lFFnN4j068UFbLSG/WOLeEM1/ZZH VQ+ShR+2TCfQHNsG5C8vMloNdd7NFyttFp1ENyqj1z0/jdFnGrL3h3Dgn+0NSbPBoccV PQv6+jix2ZrszySLNw6mU7Rbq5QKs201e0NS79WHEwviKTOJaP7vtjQjnph8/wnli1/B WuaGqE72Blhnul0+66zjBxSNh98Dro0+qPVvZAgDTkcyOqDOLHVA++yzDe+vS+2Dw+gp eF5u8qTBQNFvjGUNXRdXCENCR3in48YGY2ykg6YsYgLQit8ZKshUk0cCyuX9WegJZ4qO o2Cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710012195; x=1710616995; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=0dapH6sMmnV9ZamVJJtysMb9yL4xw8w3bAoh22EL4Vo=; b=Ppo5TI/Yyvp2rjXG1SynzSn1AYJViCYlku2aGhAB6UX1pLYrBgzVybofkcRqf4/5uN WpOt8EHH+CEzl6rmdjkaoDFTNRIWVhy9PnDD3q01W/CScowecRN2vQF3uZHnU/4PZnva xIOrsBrcxNo0M4L7q/od0kO0lnm+mdxkMsOGcJWFqB4un2K+dg0OfNAvwIJLuNEA5khX nsSurh7ed8juKI/DgoTjlY5nKelLD8f7ZKalz3rDyT2iy2RhwmFIlPEWS5jz1basghkU rH4L62tyDK6l5o5wL7bbAVGDCbusrjF944qHJ3Z80wb1VJXKsMnIvvx/SWzSHSpRLrFw +Lmg== X-Forwarded-Encrypted: i=1; AJvYcCWcUz2V1bll2BET1Rj/LjW8uJ27NopxQpovkVD7E/p2kEoYDS5UvBoZqclmNwvjDx47Yb2E/QX47aNhlaQqFItoTDLSs9a4E+je83/cAe4= X-Gm-Message-State: AOJu0Yym+YItdot1fU8kRrHveAnrtxOaDYbRUgcFwMCqzc0Q1MyBUl6V vDqAu78YEB485kwzUy89+LHq1SzIiLFuKjbAXrwIC/2MCjGexb0w3JUMbxWPlu0= X-Google-Smtp-Source: AGHT+IFZ9Fs+PsF2jnfTNVld6iD1aF/yC/++Clb+ISz5eMReGA6KlLI+TlLWLbqJFmWdTAeuAL2cvw== X-Received: by 2002:a19:f709:0:b0:513:54c6:9f68 with SMTP id z9-20020a19f709000000b0051354c69f68mr1301272lfe.18.1710012195436; Sat, 09 Mar 2024 11:23:15 -0800 (PST) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Cc: qemu-ppc@nongnu.org, qemu-arm@nongnu.org, =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , David Woodhouse , Stefano Stabellini , Anthony Perard , Paul Durrant , Paolo Bonzini , Richard Henderson , Eduardo Habkost , "Michael S. Tsirkin" , Marcel Apfelbaum , xen-devel@lists.xenproject.org Subject: [PULL 10/43] hw/xen: Extract 'xen_igd.h' from 'xen_pt.h' Date: Sat, 9 Mar 2024 20:21:37 +0100 Message-ID: <20240309192213.23420-11-philmd@linaro.org> X-Mailer: git-send-email 2.41.0 In-Reply-To: <20240309192213.23420-1-philmd@linaro.org> References: <20240309192213.23420-1-philmd@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit "hw/xen/xen_pt.h" requires "hw/xen/xen_native.h" which is target specific. It also declares IGD methods, which are not target specific. Target-agnostic code can use IGD methods. To allow that, extract these methos into a new "hw/xen/xen_igd.h" header. Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: David Woodhouse Message-Id: <20231114143816.71079-18-philmd@linaro.org> --- hw/xen/xen_pt.h | 14 -------------- include/hw/xen/xen_igd.h | 33 +++++++++++++++++++++++++++++++++ accel/xen/xen-all.c | 1 + hw/i386/pc_piix.c | 1 + hw/xen/xen_pt.c | 3 ++- hw/xen/xen_pt_config_init.c | 3 ++- hw/xen/xen_pt_graphics.c | 3 ++- hw/xen/xen_pt_stub.c | 2 +- 8 files changed, 42 insertions(+), 18 deletions(-) create mode 100644 include/hw/xen/xen_igd.h diff --git a/hw/xen/xen_pt.h b/hw/xen/xen_pt.h index d3180bb134..095a0f0365 100644 --- a/hw/xen/xen_pt.h +++ b/hw/xen/xen_pt.h @@ -15,9 +15,6 @@ #include "xen-host-pci-device.h" #include "qom/object.h" -bool xen_igd_gfx_pt_enabled(void); -void xen_igd_gfx_pt_set(bool value, Error **errp); - void xen_pt_log(const PCIDevice *d, const char *f, ...) G_GNUC_PRINTF(2, 3); #define XEN_PT_ERR(d, _f, _a...) xen_pt_log(d, "%s: Error: "_f, __func__, ##_a) @@ -62,12 +59,6 @@ typedef struct XenPTDeviceClass { XenPTQdevRealize pci_qdev_realize; } XenPTDeviceClass; -uint32_t igd_read_opregion(XenPCIPassthroughState *s); -void xen_igd_reserve_slot(PCIBus *pci_bus); -void igd_write_opregion(XenPCIPassthroughState *s, uint32_t val); -void xen_igd_passthrough_isa_bridge_create(XenPCIPassthroughState *s, - XenHostPCIDevice *dev); - /* function type for config reg */ typedef int (*xen_pt_conf_reg_init) (XenPCIPassthroughState *, XenPTRegInfo *, uint32_t real_offset, @@ -353,11 +344,6 @@ static inline bool xen_pt_has_msix_mapping(XenPCIPassthroughState *s, int bar) void *pci_assign_dev_load_option_rom(PCIDevice *dev, int *size, unsigned int domain, unsigned int bus, unsigned int slot, unsigned int function); -static inline bool is_igd_vga_passthrough(XenHostPCIDevice *dev) -{ - return (xen_igd_gfx_pt_enabled() - && ((dev->class_code >> 0x8) == PCI_CLASS_DISPLAY_VGA)); -} int xen_pt_register_vga_regions(XenHostPCIDevice *dev); int xen_pt_unregister_vga_regions(XenHostPCIDevice *dev); void xen_pt_setup_vga(XenPCIPassthroughState *s, XenHostPCIDevice *dev, diff --git a/include/hw/xen/xen_igd.h b/include/hw/xen/xen_igd.h new file mode 100644 index 0000000000..7ffca06c10 --- /dev/null +++ b/include/hw/xen/xen_igd.h @@ -0,0 +1,33 @@ +/* + * Copyright (c) 2007, Neocleus Corporation. + * Copyright (c) 2007, Intel Corporation. + * + * SPDX-License-Identifier: GPL-2.0-only + * + * Alex Novik + * Allen Kay + * Guy Zana + */ +#ifndef XEN_IGD_H +#define XEN_IGD_H + +#include "hw/xen/xen-host-pci-device.h" + +typedef struct XenPCIPassthroughState XenPCIPassthroughState; + +bool xen_igd_gfx_pt_enabled(void); +void xen_igd_gfx_pt_set(bool value, Error **errp); + +uint32_t igd_read_opregion(XenPCIPassthroughState *s); +void xen_igd_reserve_slot(PCIBus *pci_bus); +void igd_write_opregion(XenPCIPassthroughState *s, uint32_t val); +void xen_igd_passthrough_isa_bridge_create(XenPCIPassthroughState *s, + XenHostPCIDevice *dev); + +static inline bool is_igd_vga_passthrough(XenHostPCIDevice *dev) +{ + return (xen_igd_gfx_pt_enabled() + && ((dev->class_code >> 0x8) == PCI_CLASS_DISPLAY_VGA)); +} + +#endif diff --git a/accel/xen/xen-all.c b/accel/xen/xen-all.c index 5ff0cb8bd9..0bdefce537 100644 --- a/accel/xen/xen-all.c +++ b/accel/xen/xen-all.c @@ -15,6 +15,7 @@ #include "hw/xen/xen_native.h" #include "hw/xen/xen-legacy-backend.h" #include "hw/xen/xen_pt.h" +#include "hw/xen/xen_igd.h" #include "chardev/char.h" #include "qemu/accel.h" #include "sysemu/cpus.h" diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c index ce6aad758d..e123458bbc 100644 --- a/hw/i386/pc_piix.c +++ b/hw/i386/pc_piix.c @@ -55,6 +55,7 @@ #ifdef CONFIG_XEN #include #include "hw/xen/xen_pt.h" +#include "hw/xen/xen_igd.h" #endif #include "hw/xen/xen-x86.h" #include "hw/xen/xen.h" diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c index 36e6f93c37..a8edabdabc 100644 --- a/hw/xen/xen_pt.c +++ b/hw/xen/xen_pt.c @@ -59,7 +59,8 @@ #include "hw/pci/pci.h" #include "hw/qdev-properties.h" #include "hw/qdev-properties-system.h" -#include "xen_pt.h" +#include "hw/xen/xen_pt.h" +#include "hw/xen/xen_igd.h" #include "hw/xen/xen.h" #include "hw/xen/xen-legacy-backend.h" #include "qemu/range.h" diff --git a/hw/xen/xen_pt_config_init.c b/hw/xen/xen_pt_config_init.c index 2b8680b112..ba4cd78238 100644 --- a/hw/xen/xen_pt_config_init.c +++ b/hw/xen/xen_pt_config_init.c @@ -15,7 +15,8 @@ #include "qemu/osdep.h" #include "qapi/error.h" #include "qemu/timer.h" -#include "xen_pt.h" +#include "hw/xen/xen_pt.h" +#include "hw/xen/xen_igd.h" #include "hw/xen/xen-legacy-backend.h" #define XEN_PT_MERGE_VALUE(value, data, val_mask) \ diff --git a/hw/xen/xen_pt_graphics.c b/hw/xen/xen_pt_graphics.c index 0aed3bb6fd..6c2e3f4840 100644 --- a/hw/xen/xen_pt_graphics.c +++ b/hw/xen/xen_pt_graphics.c @@ -3,7 +3,8 @@ */ #include "qemu/osdep.h" #include "qapi/error.h" -#include "xen_pt.h" +#include "hw/xen/xen_pt.h" +#include "hw/xen/xen_igd.h" #include "xen-host-pci-device.h" static unsigned long igd_guest_opregion; diff --git a/hw/xen/xen_pt_stub.c b/hw/xen/xen_pt_stub.c index 5c108446a8..72feebeb20 100644 --- a/hw/xen/xen_pt_stub.c +++ b/hw/xen/xen_pt_stub.c @@ -6,7 +6,7 @@ */ #include "qemu/osdep.h" -#include "hw/xen/xen_pt.h" +#include "hw/xen/xen_igd.h" #include "qapi/error.h" bool xen_igd_gfx_pt_enabled(void) -- 2.41.0 From xen-devel-bounces@lists.xenproject.org Sat Mar 09 19:23:25 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 09 Mar 2024 19:23:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690976.1076726 (Exim 4.92) (envelope-from ) id 1rj2I1-0003Hc-Nq; Sat, 09 Mar 2024 19:23:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690976.1076726; Sat, 09 Mar 2024 19:23:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rj2I1-0003HU-IH; Sat, 09 Mar 2024 19:23:25 +0000 Received: by outflank-mailman (input) for mailman id 690976; Sat, 09 Mar 2024 19:23:23 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rj2Hz-0000Lp-MQ for xen-devel@lists.xenproject.org; Sat, 09 Mar 2024 19:23:23 +0000 Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [2a00:1450:4864:20::631]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 7e33ef02-de4a-11ee-a1ee-f123f15fe8a2; Sat, 09 Mar 2024 20:23:22 +0100 (CET) Received: by mail-ej1-x631.google.com with SMTP id a640c23a62f3a-a44f2d894b7so410823566b.1 for ; Sat, 09 Mar 2024 11:23:22 -0800 (PST) Received: from m1x-phil.lan ([176.176.181.237]) by smtp.gmail.com with ESMTPSA id g21-20020a170906595500b00a45a96a9c37sm1182786ejr.65.2024.03.09.11.23.19 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Sat, 09 Mar 2024 11:23:21 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 7e33ef02-de4a-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1710012202; x=1710617002; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=A3YPWAKLFpXy74v59/y9ZVQ7mfzqWdCePg5o0rXQJdU=; b=WGMZShYZLxi8XKRo8QOv1JT27KOo+vUH+RE2vuiFfnbXpIVXsWjrapKQlmhOT8hfdy PORz8Zyin31DkaKVjXtMB9rMLAy+RvQsSMHzIXCPcqBZ7OmoHSaLSXknqVkE3xqBtNQK Ka2m1anq4cXog7dj5m3o2eS+yViJY7WJ0vLhr7itViZ8fG+Gva/C2CcN/7C4VLvOrkr3 016+SeJnXKE4+CKg/WuVZwZ8NDpHAgU7xh0v7neLdstg1l4tM+dEcmPdJx1qIUcUUA9i vTiw1QqGM5V2eUN0Y1lS3cWeYU0St4bl+vSezz8PVBRj9ZBZeYJThjvfyB00CCb/gQMr PpDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710012202; x=1710617002; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=A3YPWAKLFpXy74v59/y9ZVQ7mfzqWdCePg5o0rXQJdU=; b=pjU2BYunbzat3gCVnJwqrjnC3f7lmiQn/CeSL49kQRmXhHjHtdVa36QrP6BwPlE/mr Ya4eKdNViYPvxJdmcx+0QiX4yauCdyYZqOXll3HPI2kfsmyZfN/8NF3b86VXmjhj+Cy9 IrLBb+TzNjTElwd5svBrhFkLQkBO+QZSKApq95/SR/jdPnlPN9aGRt826yUCv3zRxDCa rP0Ip0+m14BKkZ3HJVzRXIOrdeHntFY42ryHtFKH8E6Bm/ESpFRaLNXtPVdXxmBY+Ou5 2JBQV6tc0OAw8GGir1Lv1bqb295XlqNzeq1HUmSuupuCj7bqzorVKvy6hneGyrQ9sJFR O3sA== X-Forwarded-Encrypted: i=1; AJvYcCV7zGDt3AsloAqtQa/XqxlUApXQtzC0QBKK8OauU1/cYRIKUg2mDVS5Qlai1JZcnJeaOPGRrWFChMRiU2JFVa57GUTsKGSfZBuTlzMJUVk= X-Gm-Message-State: AOJu0YwXHJxy+59ntkzMi2j4dV1VuyM4Q31G8dD7oPo7jcChQNK5BZP9 qYZ7Bh4B/3yEZkYUasBBhnWll7+HIT9Bze6yGK8LtNh9iRQZskhkIAPfkhZQb9g= X-Google-Smtp-Source: AGHT+IESzjyaLuyggJlbtw/UU7wtPA1UXBAfVV9w8oQeEuaTMGyVqGqT6YAp9h+VrsWLnSESfaBeNA== X-Received: by 2002:a17:906:b110:b0:a45:c9fb:86d7 with SMTP id u16-20020a170906b11000b00a45c9fb86d7mr1387127ejy.54.1710012201803; Sat, 09 Mar 2024 11:23:21 -0800 (PST) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Cc: qemu-ppc@nongnu.org, qemu-arm@nongnu.org, =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , David Woodhouse , Stefano Stabellini , Anthony Perard , Paul Durrant , "Michael S. Tsirkin" , Marcel Apfelbaum , Paolo Bonzini , Richard Henderson , Eduardo Habkost , xen-devel@lists.xenproject.org Subject: [PULL 11/43] hw/i386/xen: Compile 'xen-hvm.c' with Xen CPPFLAGS Date: Sat, 9 Mar 2024 20:21:38 +0100 Message-ID: <20240309192213.23420-12-philmd@linaro.org> X-Mailer: git-send-email 2.41.0 In-Reply-To: <20240309192213.23420-1-philmd@linaro.org> References: <20240309192213.23420-1-philmd@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit xen-hvm.c calls xc_set_hvm_param() from , so better compile it with Xen CPPFLAGS. Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: David Woodhouse Message-Id: <20231114143816.71079-19-philmd@linaro.org> --- hw/i386/xen/meson.build | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/hw/i386/xen/meson.build b/hw/i386/xen/meson.build index 3dc4c4f106..3f0df8bc07 100644 --- a/hw/i386/xen/meson.build +++ b/hw/i386/xen/meson.build @@ -1,8 +1,10 @@ i386_ss.add(when: 'CONFIG_XEN', if_true: files( - 'xen-hvm.c', 'xen_apic.c', 'xen_pvdevice.c', )) +i386_ss.add(when: ['CONFIG_XEN', xen], if_true: files( + 'xen-hvm.c', +)) i386_ss.add(when: 'CONFIG_XEN_BUS', if_true: files( 'xen_platform.c', -- 2.41.0 From xen-devel-bounces@lists.xenproject.org Sat Mar 09 19:23:30 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 09 Mar 2024 19:23:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690977.1076735 (Exim 4.92) (envelope-from ) id 1rj2I5-0003jX-U3; Sat, 09 Mar 2024 19:23:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690977.1076735; Sat, 09 Mar 2024 19:23:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rj2I5-0003ik-R8; Sat, 09 Mar 2024 19:23:29 +0000 Received: by outflank-mailman (input) for mailman id 690977; Sat, 09 Mar 2024 19:23:28 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rj2I4-0001PG-PI for xen-devel@lists.xenproject.org; Sat, 09 Mar 2024 19:23:28 +0000 Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [2a00:1450:4864:20::534]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 81d4d069-de4a-11ee-afdb-a90da7624cb6; Sat, 09 Mar 2024 20:23:28 +0100 (CET) Received: by mail-ed1-x534.google.com with SMTP id 4fb4d7f45d1cf-568107a9ff2so3517022a12.3 for ; Sat, 09 Mar 2024 11:23:28 -0800 (PST) Received: from m1x-phil.lan ([176.176.181.237]) by smtp.gmail.com with ESMTPSA id d18-20020a50fb12000000b0056486eaa669sm1182154edq.50.2024.03.09.11.23.26 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Sat, 09 Mar 2024 11:23:27 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 81d4d069-de4a-11ee-afdb-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1710012208; x=1710617008; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=yLHD9GT6b5p3TJG9MYP2E7Mrw1kvuaLUPhHVHq70H4k=; b=In1Lyq191c8Z+vXQDtP8fdftoqvjPNGRcCJIjkBSmIh1karawBCO1YaYH3cO0bE2B2 feHKgRTJbt+d4bVBgUuav2ejns+R6kxEQKr8M3nSDK+M9Msi+WOsuaD8DUSVsxfJk1rT 8Crv/o0qWQ+3mqSPESCA47rAgypJD/kBjYtXoo41WLgpFl5oGb2BfA52ITJtX3ZqQ2Vp DU3AE3em/wcWjeWMiJTYaPxPphngQx7GrIyIEh2jAYtnna0Ntu+hr3pnien1oxbt7+JR fxvvXZx2he4b6i39A7e7d6AXHpEfCMI+IFxqoDLKZGbIau11GlMJG4DS4t3pqD5B1q6M aSHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710012208; x=1710617008; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=yLHD9GT6b5p3TJG9MYP2E7Mrw1kvuaLUPhHVHq70H4k=; b=dPZ/RQTORjiLbWVLGSHdMKcWDmW1fsyCfz/5ipyytK8NCq2/+bbE0ZTpyPOyJHI9ix giSVHL0sAZMsXC1680GtlEKLS1fZL9i1WgQxKzmYT5EIBNheaJV/wxkGcAWumZIgSldg wVfwPDeCM41iQyNy5Jt0ziRo65T2X0TKPugPcKo/RjtPj41mPhMEV93AUJPXmtwZCnj1 /1un8FkbEZZvqAU41lEr2uJfdzXHowZHjxl7w/zAiCd9/PIb52eYe4E6PV0IYJodIHzV j7soScsEFk7HRabqHoNPMEUGmgV0fpMOnykOrBlB1m+rp+1gWdlloHaperxDQBNGhbxz L02g== X-Forwarded-Encrypted: i=1; AJvYcCWnJuU7vp6dmb1VXGpKyQBYKvdww2Fdq3pGSYpm0XjfZ+grgy/PSMHDn8lXpRz1dnUWNC9oLvQNxQZdJJtWVrDS3+BG8ThgssDFuOHBGR4= X-Gm-Message-State: AOJu0YyGZdbqyd22DAcUBi3mosD5tkjOfMiKS9AfdOE3+w8GRY8tQILe CbyYNF5J6SPwZ9vn/iWPRU/vP91XCbdl1OZ6A/7GllpTNrIS6eM//4tjeDZFgn8= X-Google-Smtp-Source: AGHT+IElag8KDyPQHd/yd7cCq1cSr3wdf4BCFyMPlhbecbflegKHRhCxKpfa2+2S5Xx9q4YSEt6pXw== X-Received: by 2002:a50:9fc9:0:b0:568:1b94:fb88 with SMTP id c67-20020a509fc9000000b005681b94fb88mr1660926edf.23.1710012208009; Sat, 09 Mar 2024 11:23:28 -0800 (PST) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Cc: qemu-ppc@nongnu.org, qemu-arm@nongnu.org, =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Manos Pitsidianakis , Stefano Stabellini , Anthony Perard , Paul Durrant , Paolo Bonzini , Richard Henderson , Eduardo Habkost , "Michael S. Tsirkin" , Marcel Apfelbaum , xen-devel@lists.xenproject.org Subject: [PULL 12/43] hw/xen/hvm: Inline TARGET_PAGE_ALIGN() macro Date: Sat, 9 Mar 2024 20:21:39 +0100 Message-ID: <20240309192213.23420-13-philmd@linaro.org> X-Mailer: git-send-email 2.41.0 In-Reply-To: <20240309192213.23420-1-philmd@linaro.org> References: <20240309192213.23420-1-philmd@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Use TARGET_PAGE_SIZE to calculate TARGET_PAGE_ALIGN. Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: Manos Pitsidianakis Message-Id: <20231114163123.74888-2-philmd@linaro.org> --- hw/i386/xen/xen-hvm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c index 1ae943370b..8235782ef7 100644 --- a/hw/i386/xen/xen-hvm.c +++ b/hw/i386/xen/xen-hvm.c @@ -678,7 +678,7 @@ void arch_xen_set_memory(XenIOState *state, MemoryRegionSection *section, trace_xen_client_set_memory(start_addr, size, log_dirty); start_addr &= TARGET_PAGE_MASK; - size = TARGET_PAGE_ALIGN(size); + size = ROUND_UP(size, TARGET_PAGE_SIZE); if (add) { if (!memory_region_is_rom(section->mr)) { -- 2.41.0 From xen-devel-bounces@lists.xenproject.org Sat Mar 09 19:23:37 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 09 Mar 2024 19:23:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690979.1076746 (Exim 4.92) (envelope-from ) id 1rj2ID-0004IH-DC; Sat, 09 Mar 2024 19:23:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690979.1076746; Sat, 09 Mar 2024 19:23:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rj2ID-0004IA-8y; Sat, 09 Mar 2024 19:23:37 +0000 Received: by outflank-mailman (input) for mailman id 690979; Sat, 09 Mar 2024 19:23:36 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rj2IC-0000Lp-3l for xen-devel@lists.xenproject.org; Sat, 09 Mar 2024 19:23:36 +0000 Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [2a00:1450:4864:20::535]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 857f947f-de4a-11ee-a1ee-f123f15fe8a2; Sat, 09 Mar 2024 20:23:34 +0100 (CET) Received: by mail-ed1-x535.google.com with SMTP id 4fb4d7f45d1cf-5682360e095so2919755a12.1 for ; Sat, 09 Mar 2024 11:23:34 -0800 (PST) Received: from m1x-phil.lan ([176.176.181.237]) by smtp.gmail.com with ESMTPSA id l20-20020a170906a41400b00a46163be639sm251749ejz.12.2024.03.09.11.23.32 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Sat, 09 Mar 2024 11:23:33 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 857f947f-de4a-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1710012214; x=1710617014; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=GjJ9Xc35+gwGwrFshf70kAsb/Zk8w4JUpjKATwEq64Y=; b=Cz93Ty6kH9Ww33ARglTIEs5esvgrOwNs6eu98xl9xRIsRJ6jCcEfkJE6TZGABnY0Os E4PDiRG9cwpEVowt3vdpdLBrQrx5iUnfoV5+QCBfkzvFA9IBs7C6CJgbFHPvVUfpqEmT TFVFArMbQHJCNcACjdkCUzoIwPO23jw9nMvh7QzlzuS5mD7zHwVipOkblYGa610SKEdx qVAQE7g0UyeiRz/Blb43JeXi7jV3hqZOKoUhkbcrd0+KXdf/5MlV4G7Kju/GZYFLRI56 To0miIHACBrtgSWKHKCLXEpOFk+8QoxGUOJdGezwx/NftnIEwfcvtCTXgWi9K+KMN5Ij QLgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710012214; x=1710617014; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=GjJ9Xc35+gwGwrFshf70kAsb/Zk8w4JUpjKATwEq64Y=; b=BLZRRsJ0pyyd5DPpoB9D5GvTVI+H35tMVqqz5P+V80GB3Dz9hrl8nLkP68gjk8KUeG E2L4e7jA752FK7DrbSxQKkkgeo0m4JzyIfPzcU6BDQxdY/rFDislBky92Y4STcuH1ABW ZNYiOrEX3owJYz4pKXS6Ix3JshsPreBZ8iRR+ctdKERJozhLUrVQW16ty/YnXroXhRF5 A4OD+/GrtoNTV84fRNPPfV/vPvuf0AFdRxnYRMRN4v5QcOMq+f2gz8lCTyMAojXpAm4V c1Vx5bFVBzYYmItPD264+8loksaq6JWEIjSoUcpy/G69CBIZ+WLK6/WKdsIySH16zobN Irlw== X-Forwarded-Encrypted: i=1; AJvYcCVwibozan0IzIMmNjCgIIXyu4zZFQy/x6l5wfD7jJYnRoaymQeaEsT4q3ga/2AFTxtPB6pq3b64clVhQZp4aXATr6PvzeZCEwYs7DgS0LY= X-Gm-Message-State: AOJu0YwoL3oWPNf437Tbg7aiN9frHnmSL3D+ZPUIS0Ty+YYgY7ig+w64 iYxRV78Ju4Xi7wO6BgVMWt40lkp6IHw2HTYN4ezVEBAu3NsbaHSyE6CZHE61Ap8= X-Google-Smtp-Source: AGHT+IFUzNU4pC8ZaO+fIzpjlcMgyQZHUIXDLCwBTxfANDlJj9gCS9ZbhsgrrNnhXeKdaH05pNglXQ== X-Received: by 2002:a17:907:d389:b0:a45:92c4:7892 with SMTP id vh9-20020a170907d38900b00a4592c47892mr1630790ejc.56.1710012214113; Sat, 09 Mar 2024 11:23:34 -0800 (PST) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Cc: qemu-ppc@nongnu.org, qemu-arm@nongnu.org, =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Manos Pitsidianakis , Stefano Stabellini , Anthony Perard , Paul Durrant , "Michael S. Tsirkin" , Marcel Apfelbaum , Paolo Bonzini , Richard Henderson , Eduardo Habkost , xen-devel@lists.xenproject.org Subject: [PULL 13/43] hw/xen/hvm: Propagate page_mask to a pair of functions Date: Sat, 9 Mar 2024 20:21:40 +0100 Message-ID: <20240309192213.23420-14-philmd@linaro.org> X-Mailer: git-send-email 2.41.0 In-Reply-To: <20240309192213.23420-1-philmd@linaro.org> References: <20240309192213.23420-1-philmd@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit We are going to replace TARGET_PAGE_MASK by a runtime variable. In order to reduce code duplication, propagate TARGET_PAGE_MASK to get_physmapping() and xen_phys_offset_to_gaddr(). Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: Manos Pitsidianakis Message-Id: <20231114163123.74888-3-philmd@linaro.org> --- hw/i386/xen/xen-hvm.c | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c index 8235782ef7..844b11ae08 100644 --- a/hw/i386/xen/xen-hvm.c +++ b/hw/i386/xen/xen-hvm.c @@ -174,11 +174,12 @@ static void xen_ram_init(PCMachineState *pcms, } } -static XenPhysmap *get_physmapping(hwaddr start_addr, ram_addr_t size) +static XenPhysmap *get_physmapping(hwaddr start_addr, ram_addr_t size, + int page_mask) { XenPhysmap *physmap = NULL; - start_addr &= TARGET_PAGE_MASK; + start_addr &= page_mask; QLIST_FOREACH(physmap, &xen_physmap, list) { if (range_covers_byte(physmap->start_addr, physmap->size, start_addr)) { @@ -188,9 +189,10 @@ static XenPhysmap *get_physmapping(hwaddr start_addr, ram_addr_t size) return NULL; } -static hwaddr xen_phys_offset_to_gaddr(hwaddr phys_offset, ram_addr_t size) +static hwaddr xen_phys_offset_to_gaddr(hwaddr phys_offset, ram_addr_t size, + int page_mask) { - hwaddr addr = phys_offset & TARGET_PAGE_MASK; + hwaddr addr = phys_offset & page_mask; XenPhysmap *physmap = NULL; QLIST_FOREACH(physmap, &xen_physmap, list) { @@ -252,7 +254,7 @@ static int xen_add_to_physmap(XenIOState *state, hwaddr phys_offset = memory_region_get_ram_addr(mr); const char *mr_name; - if (get_physmapping(start_addr, size)) { + if (get_physmapping(start_addr, size, TARGET_PAGE_MASK)) { return 0; } if (size <= 0) { @@ -325,7 +327,7 @@ static int xen_remove_from_physmap(XenIOState *state, XenPhysmap *physmap = NULL; hwaddr phys_offset = 0; - physmap = get_physmapping(start_addr, size); + physmap = get_physmapping(start_addr, size, TARGET_PAGE_MASK); if (physmap == NULL) { return -1; } @@ -373,7 +375,7 @@ static void xen_sync_dirty_bitmap(XenIOState *state, int rc, i, j; const XenPhysmap *physmap = NULL; - physmap = get_physmapping(start_addr, size); + physmap = get_physmapping(start_addr, size, TARGET_PAGE_MASK); if (physmap == NULL) { /* not handled */ return; @@ -633,7 +635,7 @@ void xen_hvm_modified_memory(ram_addr_t start, ram_addr_t length) int rc; ram_addr_t start_pfn, nb_pages; - start = xen_phys_offset_to_gaddr(start, length); + start = xen_phys_offset_to_gaddr(start, length, TARGET_PAGE_MASK); if (length == 0) { length = TARGET_PAGE_SIZE; -- 2.41.0 From xen-devel-bounces@lists.xenproject.org Sat Mar 09 19:23:42 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 09 Mar 2024 19:23:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690980.1076755 (Exim 4.92) (envelope-from ) id 1rj2II-0004mG-KM; Sat, 09 Mar 2024 19:23:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690980.1076755; Sat, 09 Mar 2024 19:23:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rj2II-0004m9-HM; Sat, 09 Mar 2024 19:23:42 +0000 Received: by outflank-mailman (input) for mailman id 690980; Sat, 09 Mar 2024 19:23:41 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rj2IH-0001PG-JI for xen-devel@lists.xenproject.org; Sat, 09 Mar 2024 19:23:41 +0000 Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [2a00:1450:4864:20::633]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 8959b764-de4a-11ee-afdb-a90da7624cb6; Sat, 09 Mar 2024 20:23:41 +0100 (CET) Received: by mail-ej1-x633.google.com with SMTP id a640c23a62f3a-a44ad785a44so229182966b.3 for ; Sat, 09 Mar 2024 11:23:41 -0800 (PST) Received: from m1x-phil.lan ([176.176.181.237]) by smtp.gmail.com with ESMTPSA id k9-20020a1709063e0900b00a45a73e0be9sm1167156eji.180.2024.03.09.11.23.38 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Sat, 09 Mar 2024 11:23:40 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8959b764-de4a-11ee-afdb-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1710012220; x=1710617020; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=nJ7HW/Ft7i83AZTN2mskut6mEUi0nRJo8gD5MOoOvrw=; b=P8jkQ+ybtwbClY1iPTzida1BCEbdz/lFV879UtmldppvbbqOk2jOLyFBxx7ABRiujg UzzIrGRc8WUYaII3MCNeAiFFnfxC55I+QMBvfnvDBVp54RIAFnPpZgM9IrpPpsmalgHG SIQWrJcdrhzfUrqNi9CWl9Tuc+CfrDp3G3GYBF2p5DeYzHPFRqdG9pOx8DgtbZa3HkkA jHU15kA41b7A9XcZMd8ZdoPo04tydENv4Df970bRDMjwA+gKTCb7T4QF5tE5RbG8+7QC gLV2ArsJbpcBDmTo73TuBuSM8sD8CyPU9dk1EL/gsFqT24W+WcW1l54KPVXbR0TBRa8Z n7Tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710012220; x=1710617020; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=nJ7HW/Ft7i83AZTN2mskut6mEUi0nRJo8gD5MOoOvrw=; b=WQaoEMfo1AfmP3DT3JfWydH2BTV0BsELObJStYFgKHEaVlZUQmu/i0P8ka35ErR7a4 BQgGmeAov9FKtU40QZe/mdZ4jVTYNx7pNXNE37rU/6kH2VfrvWR5AuLQdcfQf7KffT4t vWpRxwwEFlRz9ZIIBtmj3NhGhvA+OxY02HcTIWSI8h9hPcTskrNf7csKC8qY6+CGaKbI SgGP8x5BTymJxVJkaSWa0tRkR5eop7ybv5X6FcJZgFhVlYWU2NwaSvVVBr+oURQUx7Se oz5FDRZUNKvPRt2+47r6FNmwMXXct2ZZE2js/EHFGLtSMJCJwqAOViy4k/VxIcsCvHhd jKjw== X-Forwarded-Encrypted: i=1; AJvYcCXfxmG0dP3atvuY/zL80ZxPtpiO23lC23dRoFADIwFx1pCaRAvXW9ONiEMHVj1QGljj7u9knyIWtyYjLC3PUEAzgFzZp7hqnMj73aY+s2M= X-Gm-Message-State: AOJu0YwGpEP7Azw8/YpbpJOrO3AIxEwMAACV4+PGDQWrAs4eJbupcpoj 2W/XQc7a8gSuq7jqsqBvIOiuo6XG0EwxpX1bNgltSX7cD0it8CIFaZ/Wf3LrawU= X-Google-Smtp-Source: AGHT+IGJ8dRKKvAEJydBIDk5EIHimW4WL5gyfDXoimVbXutg1h6Ab0DpFGsPNz89nrlp7nNRGTQq2A== X-Received: by 2002:a17:907:96ab:b0:a44:17da:424 with SMTP id hd43-20020a17090796ab00b00a4417da0424mr1554598ejc.56.1710012220525; Sat, 09 Mar 2024 11:23:40 -0800 (PST) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Cc: qemu-ppc@nongnu.org, qemu-arm@nongnu.org, =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Manos Pitsidianakis , Stefano Stabellini , Anthony Perard , Paul Durrant , Paolo Bonzini , Richard Henderson , Eduardo Habkost , "Michael S. Tsirkin" , Marcel Apfelbaum , xen-devel@lists.xenproject.org Subject: [PULL 14/43] hw/xen/hvm: Get target page size at runtime Date: Sat, 9 Mar 2024 20:21:41 +0100 Message-ID: <20240309192213.23420-15-philmd@linaro.org> X-Mailer: git-send-email 2.41.0 In-Reply-To: <20240309192213.23420-1-philmd@linaro.org> References: <20240309192213.23420-1-philmd@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit In order to build this file once for all targets, replace: TARGET_PAGE_BITS -> qemu_target_page_bits() TARGET_PAGE_SIZE -> qemu_target_page_size() TARGET_PAGE_MASK -> -qemu_target_page_size() Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: Manos Pitsidianakis Message-Id: <20231114163123.74888-4-philmd@linaro.org> --- hw/i386/xen/xen-hvm.c | 62 +++++++++++++++++++++++++++---------------- 1 file changed, 39 insertions(+), 23 deletions(-) diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c index 844b11ae08..7745cb3963 100644 --- a/hw/i386/xen/xen-hvm.c +++ b/hw/i386/xen/xen-hvm.c @@ -23,6 +23,7 @@ #include "hw/xen/xen-hvm-common.h" #include "hw/xen/arch_hvm.h" #include +#include "exec/target_page.h" static MemoryRegion ram_640k, ram_lo, ram_hi; static MemoryRegion *framebuffer; @@ -247,6 +248,9 @@ static int xen_add_to_physmap(XenIOState *state, MemoryRegion *mr, hwaddr offset_within_region) { + unsigned target_page_bits = qemu_target_page_bits(); + int page_size = qemu_target_page_size(); + int page_mask = -page_size; unsigned long nr_pages; int rc = 0; XenPhysmap *physmap = NULL; @@ -254,7 +258,7 @@ static int xen_add_to_physmap(XenIOState *state, hwaddr phys_offset = memory_region_get_ram_addr(mr); const char *mr_name; - if (get_physmapping(start_addr, size, TARGET_PAGE_MASK)) { + if (get_physmapping(start_addr, size, page_mask)) { return 0; } if (size <= 0) { @@ -294,9 +298,9 @@ go_physmap: return 0; } - pfn = phys_offset >> TARGET_PAGE_BITS; - start_gpfn = start_addr >> TARGET_PAGE_BITS; - nr_pages = size >> TARGET_PAGE_BITS; + pfn = phys_offset >> target_page_bits; + start_gpfn = start_addr >> target_page_bits; + nr_pages = size >> target_page_bits; rc = xendevicemodel_relocate_memory(xen_dmod, xen_domid, nr_pages, pfn, start_gpfn); if (rc) { @@ -310,8 +314,8 @@ go_physmap: } rc = xendevicemodel_pin_memory_cacheattr(xen_dmod, xen_domid, - start_addr >> TARGET_PAGE_BITS, - (start_addr + size - 1) >> TARGET_PAGE_BITS, + start_addr >> target_page_bits, + (start_addr + size - 1) >> target_page_bits, XEN_DOMCTL_MEM_CACHEATTR_WB); if (rc) { error_report("pin_memory_cacheattr failed: %s", strerror(errno)); @@ -323,11 +327,14 @@ static int xen_remove_from_physmap(XenIOState *state, hwaddr start_addr, ram_addr_t size) { + unsigned target_page_bits = qemu_target_page_bits(); + int page_size = qemu_target_page_size(); + int page_mask = -page_size; int rc = 0; XenPhysmap *physmap = NULL; hwaddr phys_offset = 0; - physmap = get_physmapping(start_addr, size, TARGET_PAGE_MASK); + physmap = get_physmapping(start_addr, size, page_mask); if (physmap == NULL) { return -1; } @@ -338,9 +345,9 @@ static int xen_remove_from_physmap(XenIOState *state, DPRINTF("unmapping vram to %"HWADDR_PRIx" - %"HWADDR_PRIx", at " "%"HWADDR_PRIx"\n", start_addr, start_addr + size, phys_offset); - size >>= TARGET_PAGE_BITS; - start_addr >>= TARGET_PAGE_BITS; - phys_offset >>= TARGET_PAGE_BITS; + size >>= target_page_bits; + start_addr >>= target_page_bits; + phys_offset >>= target_page_bits; rc = xendevicemodel_relocate_memory(xen_dmod, xen_domid, size, start_addr, phys_offset); if (rc) { @@ -369,13 +376,16 @@ static void xen_sync_dirty_bitmap(XenIOState *state, hwaddr start_addr, ram_addr_t size) { - hwaddr npages = size >> TARGET_PAGE_BITS; + unsigned target_page_bits = qemu_target_page_bits(); + int page_size = qemu_target_page_size(); + int page_mask = -page_size; + hwaddr npages = size >> target_page_bits; const int width = sizeof(unsigned long) * 8; size_t bitmap_size = DIV_ROUND_UP(npages, width); int rc, i, j; const XenPhysmap *physmap = NULL; - physmap = get_physmapping(start_addr, size, TARGET_PAGE_MASK); + physmap = get_physmapping(start_addr, size, page_mask); if (physmap == NULL) { /* not handled */ return; @@ -389,7 +399,7 @@ static void xen_sync_dirty_bitmap(XenIOState *state, return; } - rc = xen_track_dirty_vram(xen_domid, start_addr >> TARGET_PAGE_BITS, + rc = xen_track_dirty_vram(xen_domid, start_addr >> target_page_bits, npages, dirty_bitmap); if (rc < 0) { #ifndef ENODATA @@ -410,8 +420,7 @@ static void xen_sync_dirty_bitmap(XenIOState *state, j = ctzl(map); map &= ~(1ul << j); memory_region_set_dirty(framebuffer, - (i * width + j) * TARGET_PAGE_SIZE, - TARGET_PAGE_SIZE); + (i * width + j) * page_size, page_size); }; } } @@ -631,17 +640,21 @@ void xen_register_framebuffer(MemoryRegion *mr) void xen_hvm_modified_memory(ram_addr_t start, ram_addr_t length) { + unsigned target_page_bits = qemu_target_page_bits(); + int page_size = qemu_target_page_size(); + int page_mask = -page_size; + if (unlikely(xen_in_migration)) { int rc; ram_addr_t start_pfn, nb_pages; - start = xen_phys_offset_to_gaddr(start, length, TARGET_PAGE_MASK); + start = xen_phys_offset_to_gaddr(start, length, page_mask); if (length == 0) { - length = TARGET_PAGE_SIZE; + length = page_size; } - start_pfn = start >> TARGET_PAGE_BITS; - nb_pages = ((start + length + TARGET_PAGE_SIZE - 1) >> TARGET_PAGE_BITS) + start_pfn = start >> target_page_bits; + nb_pages = ((start + length + page_size - 1) >> target_page_bits) - start_pfn; rc = xen_modified_memory(xen_domid, start_pfn, nb_pages); if (rc) { @@ -664,6 +677,9 @@ void qmp_xen_set_global_dirty_log(bool enable, Error **errp) void arch_xen_set_memory(XenIOState *state, MemoryRegionSection *section, bool add) { + unsigned target_page_bits = qemu_target_page_bits(); + int page_size = qemu_target_page_size(); + int page_mask = -page_size; hwaddr start_addr = section->offset_within_address_space; ram_addr_t size = int128_get64(section->size); bool log_dirty = memory_region_is_logging(section->mr, DIRTY_MEMORY_VGA); @@ -679,8 +695,8 @@ void arch_xen_set_memory(XenIOState *state, MemoryRegionSection *section, trace_xen_client_set_memory(start_addr, size, log_dirty); - start_addr &= TARGET_PAGE_MASK; - size = ROUND_UP(size, TARGET_PAGE_SIZE); + start_addr &= page_mask; + size = ROUND_UP(size, page_size); if (add) { if (!memory_region_is_rom(section->mr)) { @@ -689,8 +705,8 @@ void arch_xen_set_memory(XenIOState *state, MemoryRegionSection *section, } else { mem_type = HVMMEM_ram_ro; if (xen_set_mem_type(xen_domid, mem_type, - start_addr >> TARGET_PAGE_BITS, - size >> TARGET_PAGE_BITS)) { + start_addr >> target_page_bits, + size >> target_page_bits)) { DPRINTF("xen_set_mem_type error, addr: "HWADDR_FMT_plx"\n", start_addr); } -- 2.41.0 From xen-devel-bounces@lists.xenproject.org Sat Mar 09 19:23:51 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 09 Mar 2024 19:23:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690981.1076765 (Exim 4.92) (envelope-from ) id 1rj2IP-0005Ni-Ts; Sat, 09 Mar 2024 19:23:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690981.1076765; Sat, 09 Mar 2024 19:23:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rj2IP-0005NR-Px; Sat, 09 Mar 2024 19:23:49 +0000 Received: by outflank-mailman (input) for mailman id 690981; Sat, 09 Mar 2024 19:23:48 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rj2IO-0000Lp-Lv for xen-devel@lists.xenproject.org; Sat, 09 Mar 2024 19:23:48 +0000 Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [2a00:1450:4864:20::535]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 8d0d55fe-de4a-11ee-a1ee-f123f15fe8a2; Sat, 09 Mar 2024 20:23:47 +0100 (CET) Received: by mail-ed1-x535.google.com with SMTP id 4fb4d7f45d1cf-5654f700705so3903295a12.1 for ; Sat, 09 Mar 2024 11:23:47 -0800 (PST) Received: from m1x-phil.lan ([176.176.181.237]) by smtp.gmail.com with ESMTPSA id lt10-20020a170906fa8a00b00a45ab830eabsm1179687ejb.51.2024.03.09.11.23.45 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Sat, 09 Mar 2024 11:23:46 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8d0d55fe-de4a-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1710012226; x=1710617026; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=ZjbUGqOjGDJ48BD/FCrBKjFot720kk8N7cpG04DHyuw=; b=kbT2qHxTeQyHAtrzgnXBb0Yhs4phmhmYBxX5jYmdvYUaR60c1rt75vUgqpCJ49yDB2 r8ZdfOkw1AJ5k+DwIW//Pw6avF7aqrgPQBOgQmDjoTsovPYDggJUnYORbDwI3O1aO2eK Ye0B33LvKVDWxjklWkBiR/Ruc3cUcRPtNeqol3Jq4UWPdsDffKGl/lBOqBi2kI8rahuE ilyC2KTjjzHHyXX4Ix95kb9/7K3K6FK46mHj7RQtghaf+vmNKoBhJ2BjmCHtoS6R+HNn +w/MOJwbTubXdJ0mvJFG5l5PFTnwpRl/r8Rd5HSAg2l6m6kkUalTfPsUfdoDMMaQ1RZJ WV3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710012227; x=1710617027; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ZjbUGqOjGDJ48BD/FCrBKjFot720kk8N7cpG04DHyuw=; b=FTEFM/SZYEXL2r0657aFGHm8YVA5yo0LPXNnLCJnlkva2TQC64MvynneycL/q1hoTJ J/+uT12atWspLmuMIqfrrO5PvGm0YvT6xNukrMqxXSt7JoEvQHU7yZUgo5w555I7kXBa 5KvZy7UtJ3DKGi9uRBYnRQVW0s7w9xcfW3CXu3Jc8eXfSUgBVHEa+w3pvCEz/PkH7LIR 8C10/d2LZLelYLMq/1fTpXnMBz7IJApaOPl/z5WTVhv+fmfa1YRTYjuo8i9vpQXI8rvl U0mZIg0GpTWF60YDyJy/pzcMWGSEzY4oQCw5scThVEcYhJOSzlR6Vi40ghOCyGn+qTuu +O7A== X-Forwarded-Encrypted: i=1; AJvYcCV0+WSyO0sNv1hlL3cf0/2T6XbQK6yQkBLIDwPyogFd6R1qalyVvm+IP2r5TQ9OBcwDj1/S6EmiJeIHHoiMowRcZOCT+9W5b0PQ4D8H7ao= X-Gm-Message-State: AOJu0YxnLooYvgbPRIS7IwR6HDgY6JDwN17Un9K2ysbGid10IJszhhjr 4KsG8m0gnOEBUxumswW72Dnjqps+z2OZzUmBLP3CDRlepguVH9quU6sqQHQSkVudw2N1bZR+an0 j X-Google-Smtp-Source: AGHT+IHsirtIOeTRkWpIs3e5yCTD71AujDzccS4QPk7Rv1bmDdnDigFagjmowzpwOIomavcvEpokKQ== X-Received: by 2002:a17:906:b0d0:b0:a44:8c1b:8877 with SMTP id bk16-20020a170906b0d000b00a448c1b8877mr1523044ejb.50.1710012226664; Sat, 09 Mar 2024 11:23:46 -0800 (PST) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Cc: qemu-ppc@nongnu.org, qemu-arm@nongnu.org, Zhao Liu , Stefano Stabellini , Anthony Perard , Paul Durrant , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , Paolo Bonzini , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , xen-devel@lists.xenproject.org Subject: [PULL 15/43] hw/char/xen_console: Fix missing ERRP_GUARD() for error_prepend() Date: Sat, 9 Mar 2024 20:21:42 +0100 Message-ID: <20240309192213.23420-16-philmd@linaro.org> X-Mailer: git-send-email 2.41.0 In-Reply-To: <20240309192213.23420-1-philmd@linaro.org> References: <20240309192213.23420-1-philmd@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Zhao Liu As the comment in qapi/error, passing @errp to error_prepend() requires ERRP_GUARD(): * = Why, when and how to use ERRP_GUARD() = * * Without ERRP_GUARD(), use of the @errp parameter is restricted: ... * - It should not be passed to error_prepend(), error_vprepend() or * error_append_hint(), because that doesn't work with &error_fatal. * ERRP_GUARD() lifts these restrictions. * * To use ERRP_GUARD(), add it right at the beginning of the function. * @errp can then be used without worrying about the argument being * NULL or &error_fatal. ERRP_GUARD() could avoid the case when @errp is the pointer of error_fatal, the user can't see this additional information, because exit() happens in error_setg earlier than information is added [1]. The xen_console_connect() passes @errp to error_prepend() without ERRP_GUARD(). There're 2 places will call xen_console_connect(): - xen_console_realize(): the @errp is from DeviceClass.realize()'s parameter. - xen_console_frontend_changed(): the @errp points its caller's @local_err. To avoid the issue like [1] said, add missing ERRP_GUARD() at the beginning of xen_console_connect(). [1]: Issue description in the commit message of commit ae7c80a7bd73 ("error: New macro ERRP_GUARD()"). Cc: Stefano Stabellini Cc: Anthony Perard Cc: Paul Durrant Cc: "Marc-André Lureau" Cc: Paolo Bonzini Signed-off-by: Zhao Liu Acked-by: Anthony PERARD Message-ID: <20240228163723.1775791-15-zhao1.liu@linux.intel.com> Signed-off-by: Philippe Mathieu-Daudé --- hw/char/xen_console.c | 1 + 1 file changed, 1 insertion(+) diff --git a/hw/char/xen_console.c b/hw/char/xen_console.c index 5cbee2f184..683c92aca1 100644 --- a/hw/char/xen_console.c +++ b/hw/char/xen_console.c @@ -206,6 +206,7 @@ static bool con_event(void *_xendev) static bool xen_console_connect(XenDevice *xendev, Error **errp) { + ERRP_GUARD(); XenConsole *con = XEN_CONSOLE_DEVICE(xendev); unsigned int port, limit; -- 2.41.0 From xen-devel-bounces@lists.xenproject.org Sat Mar 09 19:23:54 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 09 Mar 2024 19:23:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.690982.1076775 (Exim 4.92) (envelope-from ) id 1rj2IU-0005mP-7T; Sat, 09 Mar 2024 19:23:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 690982.1076775; Sat, 09 Mar 2024 19:23:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rj2IU-0005mG-2U; Sat, 09 Mar 2024 19:23:54 +0000 Received: by outflank-mailman (input) for mailman id 690982; Sat, 09 Mar 2024 19:23:53 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rj2IT-0001PG-KJ for xen-devel@lists.xenproject.org; Sat, 09 Mar 2024 19:23:53 +0000 Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [2a00:1450:4864:20::62e]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 90a0bd32-de4a-11ee-afdb-a90da7624cb6; Sat, 09 Mar 2024 20:23:53 +0100 (CET) Received: by mail-ej1-x62e.google.com with SMTP id a640c23a62f3a-a45bb2a9c20so389479566b.0 for ; Sat, 09 Mar 2024 11:23:53 -0800 (PST) Received: from m1x-phil.lan ([176.176.181.237]) by smtp.gmail.com with ESMTPSA id k5-20020a170906578500b00a449ebf3d58sm1178448ejq.85.2024.03.09.11.23.51 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Sat, 09 Mar 2024 11:23:52 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 90a0bd32-de4a-11ee-afdb-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1710012233; x=1710617033; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=0qhkX9N0f7mv4U6Enm7PREVuXkmrXKzBrsiRapOf0sE=; b=lgdBTmbi/sBA8OH1UM4YfGlOYFOjwWc159O0HgOayc1yO3kClIVB8LTSqPfZydHHVi v6x301MY+QMF1NMPH6JAOQaIgWQQrlpc8I81sdMbF0fUrGzShsKL1/wk2Y3AhVlwTXaW hc8AAdCyxWxn03G9Fws75WOyM5hVDPLtIUu5JjbBc/GpJa245KHu+EEyRwGkNJmd3mf2 RB0a4omrDd/X9e35PnhMkcLszH54sL/5tTlPpEJyPX9jkwk/v2nIiCaxx8Q8lJ6fq7UV 1ZtYvN4ktPd179rhrRr9I+J5134I7Be8aV1LVrwQT7AmdQdME+H/bNQqNjd4ZE/k/qQe W1XQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710012233; x=1710617033; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=0qhkX9N0f7mv4U6Enm7PREVuXkmrXKzBrsiRapOf0sE=; b=n9nGnTLQK3yUFDedsNDbX6DXHWe4OGi/9mjXZNTS/hdaSYizd6r9anCzRm1OT6kk8K szPTdXSK5LCNoXhBDU64YaCa7TKjG/hyGKcU068cheM3hOe5XVjDlaUbbYGKYojvYC3V sysKxW8Z17SgnBBKHRCVfWjaio5vYsyBtJ+8EarSXOEd9SFC/V0A90Ns0qOZwmRf+a64 QbaYdw6JV6z4mRo7GX6JpQTUHYoO2QGKkJqRED9ZC00SSul4ecAcWEH3HoRW3Hx/fESA r9tS90BLm48xQeyVkAw49Y8glsI2H3bbKG6fxGp2h7oowLDk2GihK8G+SuColxZ7f/QY YUvA== X-Forwarded-Encrypted: i=1; AJvYcCW6rFlEyPbkSQ8mOXdhZFB0FyiepOs7ip3c4xVBFtQVRvuR2hx3zNWPDechmxgGs6yDIlUSUfbiK2VZFH9f9tuSc466GTo6PZGu2qY2Nmw= X-Gm-Message-State: AOJu0YxKvz9LLTdZKcAk2AQEzcZ+BCy2VhNgd+IqHkU5bbVMJJazy2wV ExZxfhIo/3mn4U5KC5byZbbVjjvxaoLdB2xfpY6HNFr78jDB2L8URurfMWagZRg= X-Google-Smtp-Source: AGHT+IE0pC1PtPPUFeJGmL9nn03Tms40CF9fkNhPdedtB8UjjmtZf/tpA8FjVipfHktzZdaLWkMqpQ== X-Received: by 2002:a17:907:c28a:b0:a43:900a:31c5 with SMTP id tk10-20020a170907c28a00b00a43900a31c5mr1698253ejc.4.1710012232757; Sat, 09 Mar 2024 11:23:52 -0800 (PST) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Cc: qemu-ppc@nongnu.org, qemu-arm@nongnu.org, Zhao Liu , Stefano Stabellini , Anthony Perard , Paul Durrant , Jason Wang , Thomas Huth , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , xen-devel@lists.xenproject.org Subject: [PULL 16/43] hw/net/xen_nic: Fix missing ERRP_GUARD() for error_prepend() Date: Sat, 9 Mar 2024 20:21:43 +0100 Message-ID: <20240309192213.23420-17-philmd@linaro.org> X-Mailer: git-send-email 2.41.0 In-Reply-To: <20240309192213.23420-1-philmd@linaro.org> References: <20240309192213.23420-1-philmd@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Zhao Liu As the comment in qapi/error, passing @errp to error_prepend() requires ERRP_GUARD(): * = Why, when and how to use ERRP_GUARD() = * * Without ERRP_GUARD(), use of the @errp parameter is restricted: ... * - It should not be passed to error_prepend(), error_vprepend() or * error_append_hint(), because that doesn't work with &error_fatal. * ERRP_GUARD() lifts these restrictions. * * To use ERRP_GUARD(), add it right at the beginning of the function. * @errp can then be used without worrying about the argument being * NULL or &error_fatal. ERRP_GUARD() could avoid the case when @errp is the pointer of error_fatal, the user can't see this additional information, because exit() happens in error_setg earlier than information is added [1]. The xen_netdev_connect() passes @errp to error_prepend(), and its @errp parameter is from xen_device_frontend_changed(). Though its @errp points to @local_err of xen_device_frontend_changed(), to follow the requirement of @errp, add missing ERRP_GUARD() at the beginning of this function. [1]: Issue description in the commit message of commit ae7c80a7bd73 ("error: New macro ERRP_GUARD()"). Cc: Stefano Stabellini Cc: Anthony Perard Cc: Paul Durrant Cc: Jason Wang Signed-off-by: Zhao Liu Acked-by: Anthony PERARD Reviewed-by: Thomas Huth Message-ID: <20240229143914.1977550-3-zhao1.liu@linux.intel.com> Signed-off-by: Philippe Mathieu-Daudé --- hw/net/xen_nic.c | 1 + 1 file changed, 1 insertion(+) diff --git a/hw/net/xen_nic.c b/hw/net/xen_nic.c index 453fdb9819..89487b49ba 100644 --- a/hw/net/xen_nic.c +++ b/hw/net/xen_nic.c @@ -351,6 +351,7 @@ static bool net_event(void *_xendev) static bool xen_netdev_connect(XenDevice *xendev, Error **errp) { + ERRP_GUARD(); XenNetDev *netdev = XEN_NET_DEVICE(xendev); unsigned int port, rx_copy; -- 2.41.0 From xen-devel-bounces@lists.xenproject.org Sat Mar 09 19:28:45 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 09 Mar 2024 19:28:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691012.1076785 (Exim 4.92) (envelope-from ) id 1rj2N6-0007PO-Ri; Sat, 09 Mar 2024 19:28:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691012.1076785; Sat, 09 Mar 2024 19:28:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rj2N6-0007PH-P0; Sat, 09 Mar 2024 19:28:40 +0000 Received: by outflank-mailman (input) for mailman id 691012; Sat, 09 Mar 2024 19:28:39 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rj2N5-0007P7-RW; Sat, 09 Mar 2024 19:28:39 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rj2N5-0002ev-Md; Sat, 09 Mar 2024 19:28:39 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rj2N5-0004ER-8t; Sat, 09 Mar 2024 19:28:39 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rj2N5-000714-8Y; Sat, 09 Mar 2024 19:28:39 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=+8vC2bTqJV0YmHzQKf2hTZTvIpRVzQKQjWu6wbHFcxw=; b=5sA56OzVQuJDn4QUE4Ph3w2KQk hxNhcV0tuGnLL4c7wSTqrs4ddsIWUTDWcf83d2NPCImnJJWGqKN5ZL9XsFuZnPA8TQF3kP+fEpwXs ATBRmNtCv9wKkDYSXORGGnVJBy/EB8sh4L1ToEVetEHdmLj2kWNjcwjfhBWC05GWvLOk=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-linus test] 184971: tolerable FAIL - PUSHED X-Osstest-Failures: linux-linus:test-amd64-amd64-pair:guest-migrate/dst_host/src_host:fail:heisenbug linux-linus:test-amd64-amd64-xl-qemut-debianhvm-i386-xsm:debian-hvm-install:fail:heisenbug linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: linux=09e5c48fea173b72f1c763776136eeb379b1bc47 X-Osstest-Versions-That: linux=3aaa8ce7a3350d95b241046ae2401103a4384ba2 From: osstest service owner Date: Sat, 09 Mar 2024 19:28:39 +0000 flight 184971 linux-linus real [real] flight 184981 linux-linus real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/184971/ http://logs.test-lab.xenproject.org/osstest/logs/184981/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-pair 27 guest-migrate/dst_host/src_host fail pass in 184981-retest test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail pass in 184981-retest Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop fail like 184942 test-armhf-armhf-libvirt 16 saverestore-support-check fail like 184942 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop fail like 184942 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop fail like 184942 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 184942 test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail like 184942 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop fail like 184942 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184942 test-amd64-amd64-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl 15 migrate-support-check fail never pass test-arm64-arm64-xl 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 15 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 15 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-check fail never pass test-armhf-armhf-libvirt 15 migrate-support-check fail never pass test-amd64-amd64-libvirt-qcow2 14 migrate-support-check fail never pass test-amd64-amd64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-check fail never pass test-arm64-arm64-xl-vhd 14 migrate-support-check fail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-check fail never pass version targeted for testing: linux 09e5c48fea173b72f1c763776136eeb379b1bc47 baseline version: linux 3aaa8ce7a3350d95b241046ae2401103a4384ba2 Last test of basis 184942 2024-03-08 07:27:45 Z 1 days Failing since 184961 2024-03-09 00:14:58 Z 0 days 2 attempts Testing same since 184971 2024-03-09 06:52:06 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Al Raj Hassain Alan Stern Alban Boyé Alex Deucher Alexander Usyskin Andi Shyti Andreas Pape Andy Chi Angel Iglesias Animesh Manna Ankit Nautiyal Antonio Borneo Badhri Jagan Sridharan Bartosz Golaszewski Chris Yokum Christoph Niedermaier Cong Yang Cosmin Tanislav Daniel Vetter Dave Airlie Dmitry Torokhov Douglas Anderson Ekansh Gupta Eugeniu Rosca Frej Drejhammar Greg Kroah-Hartman Hans de Goede Ian Abbott Ilya Dryomov Imre Deak Jani Nikula Janusz Krzysztofik Javier Carrasco Jean-Baptiste Maneyrol Jiri Slaby Johan Hovold Jonathan Cameron Joonas Lahtinen Kailang Yang Karol Herbst Kees Cook Krishna Kurapati Kuninori Morimoto Li Ma Linus Torvalds Linus Walleij Luis Henriques Ma Jun Mano Ségransan Mark Brown Mathias Krause Mathias Nyman Matthew Auld Max Nguyen Maxime Ripard Maxime Ripard Melissa Wen Mika Westerberg Neil Armstrong Nicolas Pitre Nirmoy Das Nuno Sa Paul Menzel Paul Menzel # Dell XPS 15 7590 Peter Collingbourne Pierre-Louis Bossart RD Babiera Rickard x Andersson Rob Herring Rodrigo Vivi Sherry Sun songxiebing Srinivas Kandagatla Stefan Binding Stuart Henderson Suraj Kandpal Takashi Iwai Thomas Hellstrom Thomas Hellström Thomas Zimmermann Tomas Winkler Tvrtko Ursulin Uwe Kleine-König Vasileios Amoiridis Ville Syrjälä Wentong Wu William Breathitt Gray Xiubo Li Yeswanth Rayapati Yicong Yang jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm fail test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-amd64-dom0pvh-xl-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-freebsd11-amd64 pass test-amd64-amd64-freebsd12-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-examine-bios pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-amd64-dom0pvh-xl-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair fail test-amd64-amd64-libvirt-pair pass test-amd64-amd64-xl-pvshim pass test-amd64-amd64-pygrub pass test-amd64-amd64-libvirt-qcow2 pass test-armhf-armhf-libvirt-qcow2 pass test-amd64-amd64-libvirt-raw pass test-arm64-arm64-libvirt-raw pass test-armhf-armhf-libvirt-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-examine-uefi pass test-amd64-amd64-xl-vhd pass test-arm64-arm64-xl-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these 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 : hint: The 'hooks/update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-receive' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. To xenbits.xen.org:/home/xen/git/linux-pvops.git 3aaa8ce7a3350..09e5c48fea173 09e5c48fea173b72f1c763776136eeb379b1bc47 -> tested/linux-linus From xen-devel-bounces@lists.xenproject.org Sun Mar 10 02:47:59 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 10 Mar 2024 02:47:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691042.1076795 (Exim 4.92) (envelope-from ) id 1rj9E2-0008HU-4v; Sun, 10 Mar 2024 02:47:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691042.1076795; Sun, 10 Mar 2024 02:47:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rj9E2-0008HN-1F; Sun, 10 Mar 2024 02:47:46 +0000 Received: by outflank-mailman (input) for mailman id 691042; Sun, 10 Mar 2024 02:47:44 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rj9E0-0008HD-NI; Sun, 10 Mar 2024 02:47:44 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rj9E0-0001iC-Gk; Sun, 10 Mar 2024 02:47:44 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rj9E0-0001Ve-5Z; Sun, 10 Mar 2024 02:47:44 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rj9E0-00005h-5H; Sun, 10 Mar 2024 02:47:44 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=BIfeFC9lo+m0C34BGn8Nrn94TK7c/9NIgPAvMXBngKI=; b=ACIQQivefyqcxd78Mstk8hIwRN aQYb0dm0FINrBAsqAYfbDQ+/jtmR0GuJBJfozowBbsoVM7eyd47+UFk8aJLT/84rDfPWWx0ov98YV Yw1OAsq9VC3xEHMOyFNpfAprd7WYX7kL7xtsjLdnAHJG419KxIfe+9ut1M7N4/l//KeE=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable test] 184974: regressions - FAIL X-Osstest-Failures: xen-unstable:test-amd64-amd64-livepatch:livepatch-run:fail:regression xen-unstable:test-amd64-i386-livepatch:livepatch-run:fail:regression xen-unstable:test-amd64-i386-xl-qemut-debianhvm-amd64:guest-localmigrate/x10:fail:heisenbug xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: xen=ef31ffbc3dc124173fc9420988772fa96bc4bf12 X-Osstest-Versions-That: xen=66c8e9b76c61ff52cfc0b186a38208907845d093 From: osstest service owner Date: Sun, 10 Mar 2024 02:47:44 +0000 flight 184974 xen-unstable real [real] flight 184983 xen-unstable real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/184974/ http://logs.test-lab.xenproject.org/osstest/logs/184983/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-livepatch 13 livepatch-run fail REGR. vs. 184927 test-amd64-i386-livepatch 13 livepatch-run fail REGR. vs. 184927 Tests which are failing intermittently (not blocking): test-amd64-i386-xl-qemut-debianhvm-amd64 18 guest-localmigrate/x10 fail pass in 184983-retest Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop fail blocked in 184927 test-armhf-armhf-libvirt 16 saverestore-support-check fail like 184927 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop fail like 184927 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 184927 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop fail like 184927 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 184927 test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail like 184927 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 184927 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop fail like 184927 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 184927 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184927 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 184927 test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-amd64-i386-xl-pvshim 14 guest-start fail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-check fail never pass test-amd64-i386-libvirt 15 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-check fail never pass test-arm64-arm64-xl 15 migrate-support-check fail never pass test-arm64-arm64-xl 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 15 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-check fail never pass test-armhf-armhf-libvirt 15 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-check fail never pass test-amd64-i386-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-check fail never pass test-arm64-arm64-xl-vhd 14 migrate-support-check fail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-check fail never pass version targeted for testing: xen ef31ffbc3dc124173fc9420988772fa96bc4bf12 baseline version: xen 66c8e9b76c61ff52cfc0b186a38208907845d093 Last test of basis 184927 2024-03-07 00:10:52 Z 3 days Failing since 184940 2024-03-07 19:47:48 Z 2 days 3 attempts Testing same since 184974 2024-03-09 08:14:48 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Anthony PERARD Federico Serafini Henry Wang Jan Beulich Juergen Gross Oleksii Kurochko jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-dom0pvh-xl-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 fail test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-qemuu-freebsd11-amd64 pass test-amd64-amd64-qemuu-freebsd12-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-examine-bios pass test-amd64-i386-examine-bios pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-dom0pvh-xl-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch fail test-amd64-i386-livepatch fail test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-armhf-armhf-libvirt-qcow2 pass test-amd64-amd64-xl-qcow2 pass test-arm64-arm64-libvirt-raw pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-libvirt-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-examine-uefi pass test-amd64-i386-examine-uefi pass test-amd64-amd64-libvirt-vhd pass test-arm64-arm64-xl-vhd pass test-armhf-armhf-xl-vhd pass test-amd64-i386-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these 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 ef31ffbc3dc124173fc9420988772fa96bc4bf12 Author: Federico Serafini Date: Mon Mar 4 11:28:37 2024 +0100 automation/eclair: add deviation for MISRA C:2012 Rule 16.6 Update ECLAIR configuration to take into account the deviations agreed during MISRA meetings. Signed-off-by: Federico Serafini Reviewed-by: Stefano Stabellini commit 90173fc5a2a826bbcabde22af405d0a617818b70 Author: Henry Wang Date: Thu Mar 7 21:56:16 2024 +0800 tools/9pfsd: Fix build error caused by strerror_r Below error can be seen when doing Yocto build of the toolstack: | io.c: In function 'p9_error': | io.c:684:5: error: ignoring return value of 'strerror_r' declared with attribute 'warn_unused_result' [-Werror=unused-result] | 684 | strerror_r(err, ring->buffer, ring->ring_size); | | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | cc1: all warnings being treated as errors Using strerror_r() without special casing different build environments is impossible due to the different return types (int vs char *) depending on the environment. As p9_error() is not on a performance critical path, using strerror() with a mutex ought to be fine. So, fix the build by using strerror() to replace strerror_r(). The steps would then become: Acquire the mutex first, invoke strerror(), copy the string from strerror() to the designated buffer and then drop the mutex. Fixes: f4900d6d69b5 ("9pfsd: allow building with old glibc") Signed-off-by: Henry Wang Reviewed-by: Jan Beulich Reviewed-by: Juergen Gross Acked-by: Anthony PERARD commit b52c45b1bdf04469495dd046ba15dd35a8becfa5 Author: Juergen Gross Date: Wed Mar 6 12:16:31 2024 +0100 MAINTAINERS: add an entry for tools/9pfsd Add me as the maintainer for the tools/9pfsd directory. Signed-off-by: Juergen Gross Reviewed-by: Andrew Cooper commit b083b1c393dc8961acf0959b1d2e0ad459985ae3 Author: Andrew Cooper Date: Tue Mar 5 11:39:19 2024 +0000 x86/livepatch: Relax permissions on rodata too This reinstates the capability to patch .rodata in load/unload hooks, which was lost when we stopped using CR0.WP=0 to patch. This turns out to be rather less of a large TODO than I thought at the time. Fixes: 8676092a0f16 ("x86/livepatch: Fix livepatch application when CET is active") Signed-off-by: Andrew Cooper Reviewed-by: Roger Pau Monné Reviewed-by: Ross Lagerwall commit ef969144a425e39f5b214a875b5713d0ea8575fb Author: Andrew Cooper Date: Tue Mar 5 11:35:12 2024 +0000 xen/virtual-region: Include rodata pointers These are optional. .init doesn't distinguish types of data like this, and livepatches don't necesserily have any .rodata either. No functional change. Signed-off-by: Andrew Cooper Reviewed-by: Roger Pau Monné Reviewed-by: Ross Lagerwall commit 989556c6f8ca080f5f202417af97d1188b9ba52a Author: Andrew Cooper Date: Tue Mar 5 11:28:33 2024 +0000 xen/virtual-region: Rename the start/end fields ... to text_{start,end}. We're about to introduce another start/end pair. Despite it's name, struct virtual_region has always been a module-ish description. Call this out specifically. As minor cleanup, replace ROUNDUP(x, PAGE_SIZE) with the more concise PAGE_ALIGN() ahead of duplicating the example. No functional change. Signed-off-by: Andrew Cooper Reviewed-by: Roger Pau Monné Reviewed-by: Ross Lagerwall commit 08bb338f09a54d3b39f0d952bbd67461d8e5d0ed Author: Juergen Gross Date: Thu Mar 7 09:18:04 2024 +0100 SUPPORT.md: add xen-9pfsd Add a support statement for the new xen-9pfsd backend. Set it to "Experimental", as some functionality for Linux guests is missing (only tested to work with Xenstore-stubdom). Signed-off-by: Juergen Gross Acked-by: Jan Beulich commit 49b664f5bffa3a86734c66491d7dcdebbdecfb26 Author: Jan Beulich Date: Thu Mar 7 09:17:26 2024 +0100 x86/asm: add commas to further macros definitions/invocations In light of recent observations with how macros are handled by gas, let's play by what we informally set for ourselves as a guideline: Use commas to separate parameters/arguments. Requested-by: Andrew Cooper Signed-off-by: Jan Beulich Acked-by: Andrew Cooper commit 4ad4df0964aa374562fa574d4671d278f54f5d32 Author: Juergen Gross Date: Thu Mar 7 09:16:53 2024 +0100 CHANGELOG: add an entry for 9pfsd Add an entry to CHANGELOG.md regarding the new xen-9pfsd daemon. Signed-off-by: Juergen Gross Acked-by: Oleksii Kurochko commit 9249a441c98ff063c0c065538b419a3bf1dac24a Author: Jan Beulich Date: Thu Mar 7 09:16:13 2024 +0100 x86/asm: add commas to BUILD_BUG_ON In light of recent observations with how macros are handled by gas, let's play by what we informally set for ourselves as a guideline: Use commas to separate parameters/arguments. Signed-off-by: Jan Beulich Acked-by: Andrew Cooper commit 5daf46b439454921c19ca30840bb39424b36444b Author: Jan Beulich Date: Thu Mar 7 09:15:17 2024 +0100 Kbuild: simplify as-insn a little As of 732571959f17 ("xen/build: use new $(c_flags) and $(a_flags) instead of $(CFLAGS)") -M options aren't part of CFLAGS anymore, and c_flags isn't supposed to be passed to this macro. Drop the now dead part of filtering. Signed-off-by: Jan Beulich Reviewed-by: Anthony PERARD commit 2f7481d59255680c1de98f43467d3862453dd50a Author: Jan Beulich Date: Thu Mar 7 09:14:55 2024 +0100 x86/EFI: correct compiler probing Passing in $(CFLAGS) means also requesting inclusion of certain headers (via -include command line options). That's particularly xen/config.h, which in turn requires generated/autoconf.h. This has not caused any problems so far only because arch.mk is processed twice, and the missing header on the 1st pass would be there on the 2nd. Having added an inclusion of asm/asm-macros.h to x86'es asm/config.h, the 2nd pass then also fails on an initial, pristine build. As per dd40177c1bc8 ("x86-64/EFI: add CFLAGS to check compile") dropping the use of $(CFLAGS) altogether isn't an option, though. Hence remove the problematic options only. Signed-off-by: Jan Beulich Reviewed-by: Anthony PERARD (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Sun Mar 10 03:56:01 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 10 Mar 2024 03:56:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691049.1076804 (Exim 4.92) (envelope-from ) id 1rjAHq-0007Qn-86; Sun, 10 Mar 2024 03:55:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691049.1076804; Sun, 10 Mar 2024 03:55:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjAHq-0007Qg-52; Sun, 10 Mar 2024 03:55:46 +0000 Received: by outflank-mailman (input) for mailman id 691049; Sun, 10 Mar 2024 03:55:45 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjAHp-0007QU-Bo; Sun, 10 Mar 2024 03:55:45 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjAHp-0002wD-7q; Sun, 10 Mar 2024 03:55:45 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjAHo-00032A-Tj; Sun, 10 Mar 2024 03:55:45 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rjAHo-0002B8-TM; Sun, 10 Mar 2024 03:55:44 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=XpZV5XSuJHUaAdSn2vFmR8108j+yLpChvLHHGA07hc0=; b=IxAdlOgLiVDZmG0tB6eCWqDMW9 RRxyZwf18oWfAkPQBUrhkzPD22fJoW20oBC/cjnJf27L2rKe2gMsUDYxjgyIq5Zeyt9WTUsDS/NoI jJa2+pMofLDocuMQ251tzme3J7Dq9QWjMTg9ciHdQFHdCRGZj+XmRb2n9+SdWO/Dc57k=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-linus test] 184982: regressions - FAIL X-Osstest-Failures: linux-linus:build-arm64-pvops:kernel-build:fail:regression linux-linus:test-arm64-arm64-examine:build-check(1):blocked:nonblocking linux-linus:test-arm64-arm64-libvirt-raw:build-check(1):blocked:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking linux-linus:test-arm64-arm64-xl:build-check(1):blocked:nonblocking linux-linus:test-arm64-arm64-xl-credit1:build-check(1):blocked:nonblocking linux-linus:test-arm64-arm64-xl-credit2:build-check(1):blocked:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:build-check(1):blocked:nonblocking linux-linus:test-arm64-arm64-xl-vhd:build-check(1):blocked:nonblocking linux-linus:test-arm64-arm64-xl-xsm:build-check(1):blocked:nonblocking linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-debianhvm-i386-xsm:debian-hvm-install:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: linux=005f6f34bd47eaa61d939a2727fc648e687b84c1 X-Osstest-Versions-That: linux=09e5c48fea173b72f1c763776136eeb379b1bc47 From: osstest service owner Date: Sun, 10 Mar 2024 03:55:44 +0000 flight 184982 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/184982/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-pvops 6 kernel-build fail REGR. vs. 184971 Tests which did not succeed, but are not blocking: test-arm64-arm64-examine 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-raw 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit1 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-thunderx 1 build-check(1) blocked n/a test-arm64-arm64-xl-vhd 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 16 saverestore-support-check fail like 184971 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop fail like 184971 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop fail like 184971 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop fail like 184971 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 184971 test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail like 184971 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail like 184971 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop fail like 184971 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184971 test-amd64-amd64-libvirt-xsm 15 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 15 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-check fail never pass test-armhf-armhf-libvirt 15 migrate-support-check fail never pass test-amd64-amd64-libvirt-qcow2 14 migrate-support-check fail never pass test-amd64-amd64-libvirt-raw 14 migrate-support-check fail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-check fail never pass version targeted for testing: linux 005f6f34bd47eaa61d939a2727fc648e687b84c1 baseline version: linux 09e5c48fea173b72f1c763776136eeb379b1bc47 Last test of basis 184971 2024-03-09 06:52:06 Z 0 days Testing same since 184982 2024-03-09 19:42:22 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andi Shyti Christophe JAILLET Edmund Raile Heiner Kallweit Linus Torvalds Takashi Sakamoto Tommy Huang jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops fail build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl blocked test-armhf-armhf-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm fail test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm blocked test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm blocked test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-amd64-dom0pvh-xl-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-freebsd11-amd64 pass test-amd64-amd64-freebsd12-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-examine-bios pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 blocked test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 blocked test-armhf-armhf-xl-credit2 pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine blocked test-armhf-armhf-examine pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-amd64-dom0pvh-xl-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-amd64-xl-pvshim pass test-amd64-amd64-pygrub pass test-amd64-amd64-libvirt-qcow2 pass test-armhf-armhf-libvirt-qcow2 pass test-amd64-amd64-libvirt-raw pass test-arm64-arm64-libvirt-raw blocked test-armhf-armhf-libvirt-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-arm64-arm64-xl-thunderx blocked test-amd64-amd64-examine-uefi pass test-amd64-amd64-xl-vhd pass test-arm64-arm64-xl-vhd blocked test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these 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 005f6f34bd47eaa61d939a2727fc648e687b84c1 Merge: 66695e7d94fc ac168d6770aa Author: Linus Torvalds Date: Sat Mar 9 10:32:03 2024 -0800 Merge tag 'i2c-for-6.8-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux Pull i2c fixes from Wolfram Sang: "Two patches from Heiner for the i801 are targeting muxes discovered while working on some other features. Essentially, there is a reordering when adding optional slaves and proper cleanup upon registering a mux device. Christophe fixes the exit path in the wmt driver that was leaving the clocks hanging, and the last fix from Tommy avoids false error reports in IRQ" * tag 'i2c-for-6.8-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: i2c: aspeed: Fix the dummy irq expected print i2c: wmt: Fix an error handling path in wmt_i2c_probe() i2c: i801: Avoid potential double call to gpiod_remove_lookup_table i2c: i801: Fix using mux_pdev before it's set commit 66695e7d94fc499f26411044e07cc1386e4f3aa7 Merge: 09e5c48fea17 575801663c7d Author: Linus Torvalds Date: Sat Mar 9 10:25:14 2024 -0800 Merge tag 'firewire-fixes-6.8-final' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394 Pull firewire fix from Takashi Sakamoto: "A fix to suppress a warning about unreleased IRQ for 1394 OHCI hardware when disabling MSI. In Linux kernel v6.5, a PCI driver for 1394 OHCI hardware was optimized into the managed device resources. Edmund Raile points out that the change brings the warning about unreleased IRQ at the call of pci_disable_msi(), since the API expects that the relevant IRQ has already been released in advance. As long as the API is called in .remove callback of PCI device operation, it is prohibited to maintain the IRQ as the part of managed device resource. As a workaround, the IRQ is explicitly released at .remove callback, before the call of pci_disable_msi(). pci_disable_msi() is legacy API nowadays in PCI MSI implementation. I have a plan to replace it with the modern API in the development for the future version of Linux kernel. So at present I keep them as is" * tag 'firewire-fixes-6.8-final' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394: firewire: ohci: prevent leak of left-over IRQ on unbind commit ac168d6770aa12ee201c7474e1361810d5fc723a Author: Tommy Huang Date: Tue Mar 5 09:19:06 2024 +0800 i2c: aspeed: Fix the dummy irq expected print When the i2c error condition occurred and master state was not idle, the master irq function will goto complete state without any other interrupt handling. It would cause dummy irq expected print. Under this condition, assign the irq_status into irq_handle. For example, when the abnormal start / stop occurred (bit 5) with normal stop status (bit 4) at same time. Then the normal stop status would not be handled and it would cause irq expected print in the aspeed_i2c_bus_irq. ... aspeed-i2c-bus x. i2c-bus: irq handled != irq. Expected 0x00000030, but was 0x00000020 ... Fixes: 3e9efc3299dd ("i2c: aspeed: Handle master/slave combined irq events properly") Cc: Jae Hyun Yoo Signed-off-by: Tommy Huang Signed-off-by: Andi Shyti commit 97fd62e3269d2d47cefd421ffe144f9eafab8315 Author: Christophe JAILLET Date: Fri Jan 5 15:39:35 2024 +0100 i2c: wmt: Fix an error handling path in wmt_i2c_probe() wmt_i2c_reset_hardware() calls clk_prepare_enable(). So, should an error occur after it, it should be undone by a corresponding clk_disable_unprepare() call, as already done in the remove function. Fixes: 560746eb79d3 ("i2c: vt8500: Add support for I2C bus on Wondermedia SoCs") Signed-off-by: Christophe JAILLET Signed-off-by: Andi Shyti commit ceb013b2d9a2946035de5e1827624edc85ae9484 Author: Heiner Kallweit Date: Mon Mar 4 21:31:06 2024 +0100 i2c: i801: Avoid potential double call to gpiod_remove_lookup_table If registering the platform device fails, the lookup table is removed in the error path. On module removal we would try to remove the lookup table again. Fix this by setting priv->lookup only if registering the platform device was successful. In addition free the memory allocated for the lookup table in the error path. Fixes: d308dfbf62ef ("i2c: mux/i801: Switch to use descriptor passing") Cc: stable@vger.kernel.org Reviewed-by: Andi Shyti Reviewed-by: Linus Walleij Signed-off-by: Heiner Kallweit Signed-off-by: Andi Shyti commit 09f02902eb9cd41d4b88f4a5b93696297b57a3b0 Author: Heiner Kallweit Date: Sun Mar 3 11:45:22 2024 +0100 i2c: i801: Fix using mux_pdev before it's set i801_probe_optional_slaves() is called before i801_add_mux(). This results in mux_pdev being checked before it's set by i801_add_mux(). Fix this by changing the order of the calls. I consider this safe as I see no dependencies. Fixes: 80e56b86b59e ("i2c: i801: Simplify class-based client device instantiation") Cc: stable@vger.kernel.org Signed-off-by: Heiner Kallweit Reviewed-by: Andi Shyti Signed-off-by: Andi Shyti commit 575801663c7dc38f826212b39e3b91a4a8661c33 Author: Edmund Raile Date: Thu Feb 29 14:47:59 2024 +0000 firewire: ohci: prevent leak of left-over IRQ on unbind Commit 5a95f1ded28691e6 ("firewire: ohci: use devres for requested IRQ") also removed the call to free_irq() in pci_remove(), leading to a leftover irq of devm_request_irq() at pci_disable_msi() in pci_remove() when unbinding the driver from the device remove_proc_entry: removing non-empty directory 'irq/136', leaking at least 'firewire_ohci' Call Trace: ? remove_proc_entry+0x19c/0x1c0 ? __warn+0x81/0x130 ? remove_proc_entry+0x19c/0x1c0 ? report_bug+0x171/0x1a0 ? console_unlock+0x78/0x120 ? handle_bug+0x3c/0x80 ? exc_invalid_op+0x17/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? remove_proc_entry+0x19c/0x1c0 unregister_irq_proc+0xf4/0x120 free_desc+0x3d/0xe0 ? kfree+0x29f/0x2f0 irq_free_descs+0x47/0x70 msi_domain_free_locked.part.0+0x19d/0x1d0 msi_domain_free_irqs_all_locked+0x81/0xc0 pci_free_msi_irqs+0x12/0x40 pci_disable_msi+0x4c/0x60 pci_remove+0x9d/0xc0 [firewire_ohci 01b483699bebf9cb07a3d69df0aa2bee71db1b26] pci_device_remove+0x37/0xa0 device_release_driver_internal+0x19f/0x200 unbind_store+0xa1/0xb0 remove irq with devm_free_irq() before pci_disable_msi() also remove it in fail_msi: of pci_probe() as this would lead to an identical leak Cc: stable@vger.kernel.org Fixes: 5a95f1ded28691e6 ("firewire: ohci: use devres for requested IRQ") Signed-off-by: Edmund Raile Link: https://lore.kernel.org/r/20240229144723.13047-2-edmund.raile@proton.me Signed-off-by: Takashi Sakamoto From xen-devel-bounces@lists.xenproject.org Sun Mar 10 10:29:31 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 10 Mar 2024 10:29:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691074.1076815 (Exim 4.92) (envelope-from ) id 1rjGQd-00077W-71; Sun, 10 Mar 2024 10:29:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691074.1076815; Sun, 10 Mar 2024 10:29:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjGQd-00077P-3a; Sun, 10 Mar 2024 10:29:15 +0000 Received: by outflank-mailman (input) for mailman id 691074; Sun, 10 Mar 2024 10:29:14 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjGQc-00077F-0C; Sun, 10 Mar 2024 10:29:14 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjGQb-0002ux-Pc; Sun, 10 Mar 2024 10:29:13 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjGQb-0000E3-Ev; Sun, 10 Mar 2024 10:29:13 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rjGQb-00058X-EO; Sun, 10 Mar 2024 10:29:13 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=FC/g5/fGsACOZxdJkGRC1DUGsdLx9OwETil0lt728LI=; b=v8kcQaGV9+vuBqgj3TRV0UJla1 tYlM+UbNQSikk2VRrQqJSEHkk0guhoXNOeYdOa4J03bgW5V5l7jLg3s6Afn5iUOfeXH6DyDf8wg4y VH3lC8FTi/2cg8YoJVuDLJ79GmS1H/bO16/xreeobvcsiakzpwfWnQEHxctuRfv+Ick4=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable test] 184984: regressions - FAIL X-Osstest-Failures: xen-unstable:test-amd64-amd64-livepatch:livepatch-run:fail:regression xen-unstable:test-amd64-i386-livepatch:livepatch-run:fail:regression xen-unstable:test-amd64-i386-xl-qemut-debianhvm-amd64:guest-localmigrate/x10:fail:heisenbug xen-unstable:test-xtf-amd64-amd64-1:xen-boot:fail:heisenbug xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:windows-install:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: xen=ef31ffbc3dc124173fc9420988772fa96bc4bf12 X-Osstest-Versions-That: xen=66c8e9b76c61ff52cfc0b186a38208907845d093 From: osstest service owner Date: Sun, 10 Mar 2024 10:29:13 +0000 flight 184984 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/184984/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-livepatch 13 livepatch-run fail REGR. vs. 184927 test-amd64-i386-livepatch 13 livepatch-run fail REGR. vs. 184927 Tests which are failing intermittently (not blocking): test-amd64-i386-xl-qemut-debianhvm-amd64 18 guest-localmigrate/x10 fail in 184974 pass in 184984 test-xtf-amd64-amd64-1 8 xen-boot fail pass in 184974 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop fail in 184974 blocked in 184927 test-armhf-armhf-libvirt 16 saverestore-support-check fail like 184927 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop fail like 184927 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 184927 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop fail like 184927 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 184927 test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail like 184927 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 184927 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop fail like 184927 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 184927 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184927 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 184927 test-amd64-amd64-xl-qemuu-win7-amd64 12 windows-install fail like 184927 test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-amd64-i386-xl-pvshim 14 guest-start fail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-check fail never pass test-amd64-i386-libvirt 15 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-check fail never pass test-arm64-arm64-xl 15 migrate-support-check fail never pass test-arm64-arm64-xl 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 15 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-check fail never pass test-armhf-armhf-libvirt 15 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-check fail never pass test-amd64-i386-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-check fail never pass test-arm64-arm64-xl-vhd 14 migrate-support-check fail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-check fail never pass version targeted for testing: xen ef31ffbc3dc124173fc9420988772fa96bc4bf12 baseline version: xen 66c8e9b76c61ff52cfc0b186a38208907845d093 Last test of basis 184927 2024-03-07 00:10:52 Z 3 days Failing since 184940 2024-03-07 19:47:48 Z 2 days 4 attempts Testing same since 184974 2024-03-09 08:14:48 Z 1 days 2 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Anthony PERARD Federico Serafini Henry Wang Jan Beulich Juergen Gross Oleksii Kurochko jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 fail test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-dom0pvh-xl-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-qemuu-freebsd11-amd64 pass test-amd64-amd64-qemuu-freebsd12-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-examine-bios pass test-amd64-i386-examine-bios pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-dom0pvh-xl-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch fail test-amd64-i386-livepatch fail test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-armhf-armhf-libvirt-qcow2 pass test-amd64-amd64-xl-qcow2 pass test-arm64-arm64-libvirt-raw pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-libvirt-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-examine-uefi pass test-amd64-i386-examine-uefi pass test-amd64-amd64-libvirt-vhd pass test-arm64-arm64-xl-vhd pass test-armhf-armhf-xl-vhd pass test-amd64-i386-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these 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 ef31ffbc3dc124173fc9420988772fa96bc4bf12 Author: Federico Serafini Date: Mon Mar 4 11:28:37 2024 +0100 automation/eclair: add deviation for MISRA C:2012 Rule 16.6 Update ECLAIR configuration to take into account the deviations agreed during MISRA meetings. Signed-off-by: Federico Serafini Reviewed-by: Stefano Stabellini commit 90173fc5a2a826bbcabde22af405d0a617818b70 Author: Henry Wang Date: Thu Mar 7 21:56:16 2024 +0800 tools/9pfsd: Fix build error caused by strerror_r Below error can be seen when doing Yocto build of the toolstack: | io.c: In function 'p9_error': | io.c:684:5: error: ignoring return value of 'strerror_r' declared with attribute 'warn_unused_result' [-Werror=unused-result] | 684 | strerror_r(err, ring->buffer, ring->ring_size); | | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | cc1: all warnings being treated as errors Using strerror_r() without special casing different build environments is impossible due to the different return types (int vs char *) depending on the environment. As p9_error() is not on a performance critical path, using strerror() with a mutex ought to be fine. So, fix the build by using strerror() to replace strerror_r(). The steps would then become: Acquire the mutex first, invoke strerror(), copy the string from strerror() to the designated buffer and then drop the mutex. Fixes: f4900d6d69b5 ("9pfsd: allow building with old glibc") Signed-off-by: Henry Wang Reviewed-by: Jan Beulich Reviewed-by: Juergen Gross Acked-by: Anthony PERARD commit b52c45b1bdf04469495dd046ba15dd35a8becfa5 Author: Juergen Gross Date: Wed Mar 6 12:16:31 2024 +0100 MAINTAINERS: add an entry for tools/9pfsd Add me as the maintainer for the tools/9pfsd directory. Signed-off-by: Juergen Gross Reviewed-by: Andrew Cooper commit b083b1c393dc8961acf0959b1d2e0ad459985ae3 Author: Andrew Cooper Date: Tue Mar 5 11:39:19 2024 +0000 x86/livepatch: Relax permissions on rodata too This reinstates the capability to patch .rodata in load/unload hooks, which was lost when we stopped using CR0.WP=0 to patch. This turns out to be rather less of a large TODO than I thought at the time. Fixes: 8676092a0f16 ("x86/livepatch: Fix livepatch application when CET is active") Signed-off-by: Andrew Cooper Reviewed-by: Roger Pau Monné Reviewed-by: Ross Lagerwall commit ef969144a425e39f5b214a875b5713d0ea8575fb Author: Andrew Cooper Date: Tue Mar 5 11:35:12 2024 +0000 xen/virtual-region: Include rodata pointers These are optional. .init doesn't distinguish types of data like this, and livepatches don't necesserily have any .rodata either. No functional change. Signed-off-by: Andrew Cooper Reviewed-by: Roger Pau Monné Reviewed-by: Ross Lagerwall commit 989556c6f8ca080f5f202417af97d1188b9ba52a Author: Andrew Cooper Date: Tue Mar 5 11:28:33 2024 +0000 xen/virtual-region: Rename the start/end fields ... to text_{start,end}. We're about to introduce another start/end pair. Despite it's name, struct virtual_region has always been a module-ish description. Call this out specifically. As minor cleanup, replace ROUNDUP(x, PAGE_SIZE) with the more concise PAGE_ALIGN() ahead of duplicating the example. No functional change. Signed-off-by: Andrew Cooper Reviewed-by: Roger Pau Monné Reviewed-by: Ross Lagerwall commit 08bb338f09a54d3b39f0d952bbd67461d8e5d0ed Author: Juergen Gross Date: Thu Mar 7 09:18:04 2024 +0100 SUPPORT.md: add xen-9pfsd Add a support statement for the new xen-9pfsd backend. Set it to "Experimental", as some functionality for Linux guests is missing (only tested to work with Xenstore-stubdom). Signed-off-by: Juergen Gross Acked-by: Jan Beulich commit 49b664f5bffa3a86734c66491d7dcdebbdecfb26 Author: Jan Beulich Date: Thu Mar 7 09:17:26 2024 +0100 x86/asm: add commas to further macros definitions/invocations In light of recent observations with how macros are handled by gas, let's play by what we informally set for ourselves as a guideline: Use commas to separate parameters/arguments. Requested-by: Andrew Cooper Signed-off-by: Jan Beulich Acked-by: Andrew Cooper commit 4ad4df0964aa374562fa574d4671d278f54f5d32 Author: Juergen Gross Date: Thu Mar 7 09:16:53 2024 +0100 CHANGELOG: add an entry for 9pfsd Add an entry to CHANGELOG.md regarding the new xen-9pfsd daemon. Signed-off-by: Juergen Gross Acked-by: Oleksii Kurochko commit 9249a441c98ff063c0c065538b419a3bf1dac24a Author: Jan Beulich Date: Thu Mar 7 09:16:13 2024 +0100 x86/asm: add commas to BUILD_BUG_ON In light of recent observations with how macros are handled by gas, let's play by what we informally set for ourselves as a guideline: Use commas to separate parameters/arguments. Signed-off-by: Jan Beulich Acked-by: Andrew Cooper commit 5daf46b439454921c19ca30840bb39424b36444b Author: Jan Beulich Date: Thu Mar 7 09:15:17 2024 +0100 Kbuild: simplify as-insn a little As of 732571959f17 ("xen/build: use new $(c_flags) and $(a_flags) instead of $(CFLAGS)") -M options aren't part of CFLAGS anymore, and c_flags isn't supposed to be passed to this macro. Drop the now dead part of filtering. Signed-off-by: Jan Beulich Reviewed-by: Anthony PERARD commit 2f7481d59255680c1de98f43467d3862453dd50a Author: Jan Beulich Date: Thu Mar 7 09:14:55 2024 +0100 x86/EFI: correct compiler probing Passing in $(CFLAGS) means also requesting inclusion of certain headers (via -include command line options). That's particularly xen/config.h, which in turn requires generated/autoconf.h. This has not caused any problems so far only because arch.mk is processed twice, and the missing header on the 1st pass would be there on the 2nd. Having added an inclusion of asm/asm-macros.h to x86'es asm/config.h, the 2nd pass then also fails on an initial, pristine build. As per dd40177c1bc8 ("x86-64/EFI: add CFLAGS to check compile") dropping the use of $(CFLAGS) altogether isn't an option, though. Hence remove the problematic options only. Signed-off-by: Jan Beulich Reviewed-by: Anthony PERARD (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Sun Mar 10 14:07:13 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 10 Mar 2024 14:07:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691136.1076824 (Exim 4.92) (envelope-from ) id 1rjJpI-0004LZ-7C; Sun, 10 Mar 2024 14:06:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691136.1076824; Sun, 10 Mar 2024 14:06:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjJpI-0004LS-4V; Sun, 10 Mar 2024 14:06:56 +0000 Received: by outflank-mailman (input) for mailman id 691136; Sun, 10 Mar 2024 14:06:54 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjJpG-0004LE-5I for xen-devel@lists.xenproject.org; Sun, 10 Mar 2024 14:06:54 +0000 Received: from fout6-smtp.messagingengine.com (fout6-smtp.messagingengine.com [103.168.172.149]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 70836c24-dee7-11ee-a1ee-f123f15fe8a2; Sun, 10 Mar 2024 15:06:51 +0100 (CET) Received: from compute7.internal (compute7.nyi.internal [10.202.2.48]) by mailfout.nyi.internal (Postfix) with ESMTP id AF9F613800D2; Sun, 10 Mar 2024 10:06:49 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Sun, 10 Mar 2024 10:06:49 -0400 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 10 Mar 2024 10:06:48 -0400 (EDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 70836c24-dee7-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= invisiblethingslab.com; h=cc:cc:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1710079609; x=1710166009; bh=YLuo/dAv41dl03TJqdFSAWwkWXjXj38XB6Sedj0IcS8=; b= SZbQOQdGgPxidLwbwsghN7sxRZGsvt6cDANEAB0A95hzJ133exY/G/87pVnz7+gi Vect1dGi8/BmZLPx+1AshrfyqRu4dWnmNiyimBRst4z2RJABHVhT13cVCMv6opkM RUaqmd/rdktBTMWhFSjC/FsdQL4D0rtvZGRx8DadSi9nrOTQ7zBQetLHIpxIm2gW DEeFibrcqwZIMuJ41PXqePLxJPYIAHPYCruThyfnvuHrCileg8a4bmj/BIzuGJ8R nx56roZ3CRfZhUqu2Jk5LzEgFsLKbIB9GlZadvPdnQFNksqOC67G/Mi9k08NahbR vfu1+pu3hur2jHq+ATgMkQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1710079609; x=1710166009; bh=YLuo/dAv41dl03TJqdFSAWwkWXjX j38XB6Sedj0IcS8=; b=Quy8sDR/TMav9F2SIITXzccHKPGc1AD/TUqSzJxmEl/q yKZxz0vGUOnFnCx7mUy+C+l+7Lvkjp3Rfc256dR+/QgKWGAPIJ26KFtoBOE0uh9o mlTyUtRGjbUC64x35n9ARkZu+sI2mAEIe9UG5YSFSua48Mafincjh2mlUXw0V2OP cQes8luK687gMKqH6+yj1HDDYZXoFtegBHJaii4lNX/aE4qFPXoUnt2gHESGH3Bw Xcr1hEH5tPLdJ8UHQqGKzZc4UUodFtmgAx4Yk04J+EglkyfoSxmIQpeRJGN0KZgD 8sN3PDHkWZRDMMfU24mHj/f1hIBHZ1DflynMJ2nqTg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrieelgdeitdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvvefukfhfgggtuggjsehgtderredttdejnecuhfhrohhmpeforghrvghk ucforghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvh hishhisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpefgudel teefvefhfeehieetleeihfejhfeludevteetkeevtedtvdegueetfeejudenucevlhhush htvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhes ihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhm X-ME-Proxy: Feedback-ID: i1568416f:Fastmail Date: Sun, 10 Mar 2024 15:06:45 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Jan Beulich , Juergen Gross , Roger Pau =?utf-8?B?TW9ubsOp?= Cc: Patrick Plenefisch , xen-devel@lists.xenproject.org, Jason Andryuk Subject: Re: E820 memory allocation issue on Threadripper platforms Message-ID: References: <1708c3d7-662a-44bc-b9b3-4ab9f8642d7b@suse.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ObQU90+Tv37NxnH1" Content-Disposition: inline In-Reply-To: --ObQU90+Tv37NxnH1 Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Sun, 10 Mar 2024 15:06:45 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Jan Beulich , Juergen Gross , Roger Pau =?utf-8?B?TW9ubsOp?= Cc: Patrick Plenefisch , xen-devel@lists.xenproject.org, Jason Andryuk Subject: Re: E820 memory allocation issue on Threadripper platforms On Fri, Jan 19, 2024 at 02:40:06PM +0100, Marek Marczykowski-G=C3=B3recki w= rote: > On Thu, Jan 18, 2024 at 01:23:56AM -0500, Patrick Plenefisch wrote: > > On Wed, Jan 17, 2024 at 3:46=E2=80=AFAM Jan Beulich = wrote: > > > On 17.01.2024 07:12, Patrick Plenefisch wrote: > > > > As someone who hasn't built a kernel in over a decade, should I fig= ure > > > out > > > > how to do a kernel build with CONFIG_PHYSICAL_START=3D0x2000000 and= report > > > > back? > > > > > > That was largely a suggestion to perhaps allow you to gain some > > > workable setup. It would be of interest to us largely for completenes= s. > > > > >=20 > > Typo aside, setting the boot to 2MiB works! It works better for PV >=20 > Are there any downsides of running kernel with > CONFIG_PHYSICAL_START=3D0x200000? I can confirm it fixes the issue on > another affected system, and if there aren't any practical downsides, > I'm tempted to change it the default kernel in Qubes OS. I have the answer here: CONFIG_PHYSICAL_START=3D0x200000 breaks booting Xen in KVM with OVMF. There, the memory map has: (XEN) 0000000100000-00000007fffff type=3D7 attr=3D000000000000000f (XEN) 0000000800000-0000000807fff type=3D10 attr=3D000000000000000f (XEN) 0000000808000-000000080afff type=3D7 attr=3D000000000000000f (XEN) 000000080b000-000000080bfff type=3D10 attr=3D000000000000000f (XEN) 000000080c000-000000080ffff type=3D7 attr=3D000000000000000f (XEN) 0000000810000-00000008fffff type=3D10 attr=3D000000000000000f (XEN) 0000000900000-00000015fffff type=3D4 attr=3D000000000000000f So, starting at 0x1000000 worked since type=3D4 (boot service data) is available at that time already, but with 0x200000 it conflicts with those AcpiNvs areas around 0x800000. I'm cc-ing Jason since I see he claimed relevant gitlab issue. This conflict at least gives easy test environment with console logged to a file. --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab --ObQU90+Tv37NxnH1 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmXtvnYACgkQ24/THMrX 1yxV0AgAgJxV5CkKwofT2ZkKEfOqP8twXWsnscmm/+x81sa/mWkVCxrG4Bn5MJGF p20G+WtALnR64Gq7l5M0ktQSqvQHxb5Q+AUvg2wzGqxnG4NYySkO6sybSXr3r7UJ KoB5Zop7UwUzZe4iWia0/Uzc6QZqxs//cKxLoUBK1bcZNgejEGJ+jFvSMFof8Wsk 8TUdDJoVcBjRnscYAqnjgb0fc8gcLZbeueE8pUfnDrfkO2CCehDjlSwGYzfWcUGZ 92FOglJ0WxQLjqxW8C+FpK2jPJZ8ev+p2jQIlyRWSv98DpqRdP7NRC0pDgZoPEwz u4YPepY5LqyWjt/2OAxqgJp+/tQo8g== =q6rT -----END PGP SIGNATURE----- --ObQU90+Tv37NxnH1-- From xen-devel-bounces@lists.xenproject.org Sun Mar 10 14:08:52 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 10 Mar 2024 14:08:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691139.1076834 (Exim 4.92) (envelope-from ) id 1rjJr9-0004ss-I1; Sun, 10 Mar 2024 14:08:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691139.1076834; Sun, 10 Mar 2024 14:08:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjJr9-0004sl-FD; Sun, 10 Mar 2024 14:08:51 +0000 Received: by outflank-mailman (input) for mailman id 691139; Sun, 10 Mar 2024 14:08:50 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjJr8-0004sb-JB; Sun, 10 Mar 2024 14:08:50 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjJr8-0006sV-GH; Sun, 10 Mar 2024 14:08:50 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjJr8-0001D5-36; Sun, 10 Mar 2024 14:08:50 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rjJr8-0005PJ-2f; Sun, 10 Mar 2024 14:08:50 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=CIet6bpHl7KF5DzZLFrscUjaB5S/slrE4lpsElsU1PU=; b=ufGLVhMknK8OYUgxxvu0nULklf xWYcjIriLQw7qGdQWH373rZUCj0z7iuAIDe8B5cHIbSqaG6KdrCD0BD9+5Hyxd+E4jPoGHxFe6+PL sW9m1D1ssvs5tqg/FmZIU9ddFpifaDnYkLIM4IUNqZqs1fARkkNOu7VMku0jlMwLJW80=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-linus test] 184985: tolerable FAIL - PUSHED X-Osstest-Failures: linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: linux=005f6f34bd47eaa61d939a2727fc648e687b84c1 X-Osstest-Versions-That: linux=09e5c48fea173b72f1c763776136eeb379b1bc47 From: osstest service owner Date: Sun, 10 Mar 2024 14:08:50 +0000 flight 184985 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/184985/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 16 saverestore-support-check fail like 184971 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop fail like 184971 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop fail like 184971 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop fail like 184971 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 184971 test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail like 184971 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop fail like 184971 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184971 test-amd64-amd64-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl 15 migrate-support-check fail never pass test-arm64-arm64-xl 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 15 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 15 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-check fail never pass test-armhf-armhf-libvirt 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qcow2 14 migrate-support-check fail never pass test-amd64-amd64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-check fail never pass test-arm64-arm64-xl-vhd 14 migrate-support-check fail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-check fail never pass version targeted for testing: linux 005f6f34bd47eaa61d939a2727fc648e687b84c1 baseline version: linux 09e5c48fea173b72f1c763776136eeb379b1bc47 Last test of basis 184971 2024-03-09 06:52:06 Z 1 days Testing same since 184982 2024-03-09 19:42:22 Z 0 days 2 attempts ------------------------------------------------------------ People who touched revisions under test: Andi Shyti Christophe JAILLET Edmund Raile Heiner Kallweit Linus Torvalds Takashi Sakamoto Tommy Huang jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-amd64-dom0pvh-xl-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-freebsd11-amd64 pass test-amd64-amd64-freebsd12-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-examine-bios pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-amd64-dom0pvh-xl-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-amd64-xl-pvshim pass test-amd64-amd64-pygrub pass test-amd64-amd64-libvirt-qcow2 pass test-armhf-armhf-libvirt-qcow2 pass test-amd64-amd64-libvirt-raw pass test-arm64-arm64-libvirt-raw pass test-armhf-armhf-libvirt-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-examine-uefi pass test-amd64-amd64-xl-vhd pass test-arm64-arm64-xl-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these 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 : hint: The 'hooks/update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-receive' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. To xenbits.xen.org:/home/xen/git/linux-pvops.git 09e5c48fea173..005f6f34bd47e 005f6f34bd47eaa61d939a2727fc648e687b84c1 -> tested/linux-linus From xen-devel-bounces@lists.xenproject.org Sun Mar 10 17:21:51 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 10 Mar 2024 17:21:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691150.1076845 (Exim 4.92) (envelope-from ) id 1rjMrY-0001NP-Vb; Sun, 10 Mar 2024 17:21:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691150.1076845; Sun, 10 Mar 2024 17:21:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjMrY-0001NI-Ra; Sun, 10 Mar 2024 17:21:28 +0000 Received: by outflank-mailman (input) for mailman id 691150; Sun, 10 Mar 2024 17:21:28 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjMrY-0001NC-FH for Xen-devel@lists.xenproject.org; Sun, 10 Mar 2024 17:21:28 +0000 Received: from mail.outstep.net (mail.outstep.net [213.136.84.29]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id a0113fc2-df02-11ee-afdc-a90da7624cb6; Sun, 10 Mar 2024 18:21:26 +0100 (CET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 7FAEE234103E for ; Sun, 10 Mar 2024 18:21:20 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a0113fc2-df02-11ee-afdc-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outstep.com; s=dkim; t=1710091286; h=from:subject:date:message-id:to:mime-version:content-type: content-transfer-encoding:content-language; bh=IuAIS+Yo07L+MdDuJ67c6r2QR6m4nIQe1JVvrg4/eEU=; b=N4LFpq27zCztWcTzFbmxzbBL0GiRQUpMR2GX/5dC+SWjUM2H96i+9MEcF+/w6sSqYhAqqy mozXPurzhaH+O9EKJGX57Jg+xgF19PuDRVzP45GBwmFUyKwPSrgbsdxsgDucs7hLOAjas/ MWcdBdHUz9dge1wqXMnknEDJUX4T4fxTX52HcxJblqAt58VW/EguFy0iOL8mqFHEIA6rHU +P6w5FUohmGjPP9+eOOIbbdZARvP/sqkkGt/LNhWY6RUJ9fhUnkMCNzy6c9tBWJHhTwb9R KOHNfHcGFmhApv9YfRI99QkuYKTx3R1l6DbVSpoBv/SUYv9/n9J2rb2isTDCZQ== Message-ID: <637c0919-e12c-4e1e-b7b7-95706a63951e@outstep.com> Date: Sun, 10 Mar 2024 13:21:09 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Xen-devel@lists.xenproject.org Content-Language: en-US From: Lonnie Cumberland Subject: Local VM console PoC Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Last-TLS-Session-Version: TLSv1.3 Hello All, I am beginning my exploration with Xen (Alpine-Xen and XCP-ng) for a PoC project in which I think that I might have to figure out how to modify the latest Xen source code to make it happen, but wanted to see if I might be able to get some guidance and advice from the developers forum here. What I am initially seeking to do, and while I also know that you can get access to th VM consoles via VNC (Not sure if RDP is compiled in as well) and also knowing that after booting Dom0 has the console (text and graphics if available), what I am seeking to do is to have Xen boot and the instead of Dom0 hacing the console, I would like to be able to auto-boot a DomU and then let it have the console in full screen mode. This will probably be a DomU VM with a graphics frontend running after it boots. (i.e. Ubuntu, Windows, etc.) but not Dom0. Of course, once I can figure this part out, the second step would be to have multiple DomUs running and to then be able to page between them via some universal Hot-Key sequence. Basically, I want to modify the Xen code so that it can do this on the local physical machine. While, I do not think that Xen can do this right now, although I could be wrong, I would like to edit the sources to allow for this, if possible. Any ideas, or guidance as to where to look in the code to get started would be greatly appreciated. Thanks in advance, Lonnie From xen-devel-bounces@lists.xenproject.org Sun Mar 10 19:00:46 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 10 Mar 2024 19:00:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691162.1076854 (Exim 4.92) (envelope-from ) id 1rjOPP-0004A3-W4; Sun, 10 Mar 2024 19:00:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691162.1076854; Sun, 10 Mar 2024 19:00:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjOPP-00049w-SV; Sun, 10 Mar 2024 19:00:31 +0000 Received: by outflank-mailman (input) for mailman id 691162; Sun, 10 Mar 2024 19:00:30 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjOPO-00049m-PZ; Sun, 10 Mar 2024 19:00:30 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjOPO-0003nl-LP; Sun, 10 Mar 2024 19:00:30 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjOPO-0006uS-9F; Sun, 10 Mar 2024 19:00:30 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rjOPO-0002Zs-8u; Sun, 10 Mar 2024 19:00:30 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=QKqdRI6yQOfOc/wSO+RodQ97/ebnjZ1BNf6HRElV5lo=; b=rVWpThlF9D/hHA+1dNKTp+MXVo nzA5AmPyrCTG2YuANpj8O6l5PdN9WQd4uvvxJT8iLi9XVm7//8V67BYPc/h5YDWeSDcKWEkmZGZOW 86SU/5HFkUxUtBonMoZGY/jERMc4nuL7CJCMdwG5FTa+4h3TDTcfyWpKrkK4ETxtk9yk=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable test] 184986: regressions - FAIL X-Osstest-Failures: xen-unstable:test-amd64-amd64-livepatch:livepatch-run:fail:regression xen-unstable:test-amd64-i386-livepatch:livepatch-run:fail:regression xen-unstable:test-xtf-amd64-amd64-1:xen-boot:fail:heisenbug xen-unstable:test-amd64-amd64-xl-credit1:guest-localmigrate/x10:fail:heisenbug xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:windows-install:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: xen=ef31ffbc3dc124173fc9420988772fa96bc4bf12 X-Osstest-Versions-That: xen=66c8e9b76c61ff52cfc0b186a38208907845d093 From: osstest service owner Date: Sun, 10 Mar 2024 19:00:30 +0000 flight 184986 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/184986/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-livepatch 13 livepatch-run fail REGR. vs. 184927 test-amd64-i386-livepatch 13 livepatch-run fail REGR. vs. 184927 Tests which are failing intermittently (not blocking): test-xtf-amd64-amd64-1 8 xen-boot fail in 184984 pass in 184986 test-amd64-amd64-xl-credit1 20 guest-localmigrate/x10 fail pass in 184984 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 16 saverestore-support-check fail like 184927 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop fail like 184927 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 184927 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop fail like 184927 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 184927 test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail like 184927 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 184927 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop fail like 184927 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 184927 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 184927 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184927 test-amd64-amd64-xl-qemuu-win7-amd64 12 windows-install fail like 184927 test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-amd64-i386-xl-pvshim 14 guest-start fail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-check fail never pass test-amd64-i386-libvirt 15 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-check fail never pass test-arm64-arm64-xl 15 migrate-support-check fail never pass test-arm64-arm64-xl 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 15 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-check fail never pass test-armhf-armhf-libvirt 15 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-check fail never pass test-amd64-i386-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-check fail never pass test-arm64-arm64-xl-vhd 14 migrate-support-check fail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-check fail never pass version targeted for testing: xen ef31ffbc3dc124173fc9420988772fa96bc4bf12 baseline version: xen 66c8e9b76c61ff52cfc0b186a38208907845d093 Last test of basis 184927 2024-03-07 00:10:52 Z 3 days Failing since 184940 2024-03-07 19:47:48 Z 2 days 5 attempts Testing same since 184974 2024-03-09 08:14:48 Z 1 days 3 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Anthony PERARD Federico Serafini Henry Wang Jan Beulich Juergen Gross Oleksii Kurochko jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-dom0pvh-xl-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-qemuu-freebsd11-amd64 pass test-amd64-amd64-qemuu-freebsd12-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-examine-bios pass test-amd64-i386-examine-bios pass test-amd64-amd64-xl-credit1 fail test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-dom0pvh-xl-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch fail test-amd64-i386-livepatch fail test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-armhf-armhf-libvirt-qcow2 pass test-amd64-amd64-xl-qcow2 pass test-arm64-arm64-libvirt-raw pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-libvirt-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-examine-uefi pass test-amd64-i386-examine-uefi pass test-amd64-amd64-libvirt-vhd pass test-arm64-arm64-xl-vhd pass test-armhf-armhf-xl-vhd pass test-amd64-i386-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these 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 ef31ffbc3dc124173fc9420988772fa96bc4bf12 Author: Federico Serafini Date: Mon Mar 4 11:28:37 2024 +0100 automation/eclair: add deviation for MISRA C:2012 Rule 16.6 Update ECLAIR configuration to take into account the deviations agreed during MISRA meetings. Signed-off-by: Federico Serafini Reviewed-by: Stefano Stabellini commit 90173fc5a2a826bbcabde22af405d0a617818b70 Author: Henry Wang Date: Thu Mar 7 21:56:16 2024 +0800 tools/9pfsd: Fix build error caused by strerror_r Below error can be seen when doing Yocto build of the toolstack: | io.c: In function 'p9_error': | io.c:684:5: error: ignoring return value of 'strerror_r' declared with attribute 'warn_unused_result' [-Werror=unused-result] | 684 | strerror_r(err, ring->buffer, ring->ring_size); | | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | cc1: all warnings being treated as errors Using strerror_r() without special casing different build environments is impossible due to the different return types (int vs char *) depending on the environment. As p9_error() is not on a performance critical path, using strerror() with a mutex ought to be fine. So, fix the build by using strerror() to replace strerror_r(). The steps would then become: Acquire the mutex first, invoke strerror(), copy the string from strerror() to the designated buffer and then drop the mutex. Fixes: f4900d6d69b5 ("9pfsd: allow building with old glibc") Signed-off-by: Henry Wang Reviewed-by: Jan Beulich Reviewed-by: Juergen Gross Acked-by: Anthony PERARD commit b52c45b1bdf04469495dd046ba15dd35a8becfa5 Author: Juergen Gross Date: Wed Mar 6 12:16:31 2024 +0100 MAINTAINERS: add an entry for tools/9pfsd Add me as the maintainer for the tools/9pfsd directory. Signed-off-by: Juergen Gross Reviewed-by: Andrew Cooper commit b083b1c393dc8961acf0959b1d2e0ad459985ae3 Author: Andrew Cooper Date: Tue Mar 5 11:39:19 2024 +0000 x86/livepatch: Relax permissions on rodata too This reinstates the capability to patch .rodata in load/unload hooks, which was lost when we stopped using CR0.WP=0 to patch. This turns out to be rather less of a large TODO than I thought at the time. Fixes: 8676092a0f16 ("x86/livepatch: Fix livepatch application when CET is active") Signed-off-by: Andrew Cooper Reviewed-by: Roger Pau Monné Reviewed-by: Ross Lagerwall commit ef969144a425e39f5b214a875b5713d0ea8575fb Author: Andrew Cooper Date: Tue Mar 5 11:35:12 2024 +0000 xen/virtual-region: Include rodata pointers These are optional. .init doesn't distinguish types of data like this, and livepatches don't necesserily have any .rodata either. No functional change. Signed-off-by: Andrew Cooper Reviewed-by: Roger Pau Monné Reviewed-by: Ross Lagerwall commit 989556c6f8ca080f5f202417af97d1188b9ba52a Author: Andrew Cooper Date: Tue Mar 5 11:28:33 2024 +0000 xen/virtual-region: Rename the start/end fields ... to text_{start,end}. We're about to introduce another start/end pair. Despite it's name, struct virtual_region has always been a module-ish description. Call this out specifically. As minor cleanup, replace ROUNDUP(x, PAGE_SIZE) with the more concise PAGE_ALIGN() ahead of duplicating the example. No functional change. Signed-off-by: Andrew Cooper Reviewed-by: Roger Pau Monné Reviewed-by: Ross Lagerwall commit 08bb338f09a54d3b39f0d952bbd67461d8e5d0ed Author: Juergen Gross Date: Thu Mar 7 09:18:04 2024 +0100 SUPPORT.md: add xen-9pfsd Add a support statement for the new xen-9pfsd backend. Set it to "Experimental", as some functionality for Linux guests is missing (only tested to work with Xenstore-stubdom). Signed-off-by: Juergen Gross Acked-by: Jan Beulich commit 49b664f5bffa3a86734c66491d7dcdebbdecfb26 Author: Jan Beulich Date: Thu Mar 7 09:17:26 2024 +0100 x86/asm: add commas to further macros definitions/invocations In light of recent observations with how macros are handled by gas, let's play by what we informally set for ourselves as a guideline: Use commas to separate parameters/arguments. Requested-by: Andrew Cooper Signed-off-by: Jan Beulich Acked-by: Andrew Cooper commit 4ad4df0964aa374562fa574d4671d278f54f5d32 Author: Juergen Gross Date: Thu Mar 7 09:16:53 2024 +0100 CHANGELOG: add an entry for 9pfsd Add an entry to CHANGELOG.md regarding the new xen-9pfsd daemon. Signed-off-by: Juergen Gross Acked-by: Oleksii Kurochko commit 9249a441c98ff063c0c065538b419a3bf1dac24a Author: Jan Beulich Date: Thu Mar 7 09:16:13 2024 +0100 x86/asm: add commas to BUILD_BUG_ON In light of recent observations with how macros are handled by gas, let's play by what we informally set for ourselves as a guideline: Use commas to separate parameters/arguments. Signed-off-by: Jan Beulich Acked-by: Andrew Cooper commit 5daf46b439454921c19ca30840bb39424b36444b Author: Jan Beulich Date: Thu Mar 7 09:15:17 2024 +0100 Kbuild: simplify as-insn a little As of 732571959f17 ("xen/build: use new $(c_flags) and $(a_flags) instead of $(CFLAGS)") -M options aren't part of CFLAGS anymore, and c_flags isn't supposed to be passed to this macro. Drop the now dead part of filtering. Signed-off-by: Jan Beulich Reviewed-by: Anthony PERARD commit 2f7481d59255680c1de98f43467d3862453dd50a Author: Jan Beulich Date: Thu Mar 7 09:14:55 2024 +0100 x86/EFI: correct compiler probing Passing in $(CFLAGS) means also requesting inclusion of certain headers (via -include command line options). That's particularly xen/config.h, which in turn requires generated/autoconf.h. This has not caused any problems so far only because arch.mk is processed twice, and the missing header on the 1st pass would be there on the 2nd. Having added an inclusion of asm/asm-macros.h to x86'es asm/config.h, the 2nd pass then also fails on an initial, pristine build. As per dd40177c1bc8 ("x86-64/EFI: add CFLAGS to check compile") dropping the use of $(CFLAGS) altogether isn't an option, though. Hence remove the problematic options only. Signed-off-by: Jan Beulich Reviewed-by: Anthony PERARD (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Sun Mar 10 22:23:09 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 10 Mar 2024 22:23:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691171.1076865 (Exim 4.92) (envelope-from ) id 1rjRZ8-0007lo-Nn; Sun, 10 Mar 2024 22:22:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691171.1076865; Sun, 10 Mar 2024 22:22:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjRZ8-0007lh-KM; Sun, 10 Mar 2024 22:22:46 +0000 Received: by outflank-mailman (input) for mailman id 691171; Sun, 10 Mar 2024 22:22:45 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjRZ6-0007lX-VX; Sun, 10 Mar 2024 22:22:44 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjRZ6-00074c-Ra; Sun, 10 Mar 2024 22:22:44 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjRZ6-0002Hk-Ct; Sun, 10 Mar 2024 22:22:44 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rjRZ6-0003JX-CO; Sun, 10 Mar 2024 22:22:44 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=7KklgaqnQUetgv2gyAvnvMLvFCsHjUmehdMz8Bo1sTA=; b=iqUhNnTEN2lsaW1ZmrBHzPgB2p WOPIV/I6sTs7jvVZhC7kA1Fvgkk/lYR0lrLDSiMgID/ZuE3UC8GT4AtiDjQXdubpMLOK6ZqE+82gb fWTwYjtci+gHUt8SToROs1tlb1F2kWdJJmtLuv04JZn5AJSSy9nbzUSLqkrmMLXZn6bI=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [seabios test] 184988: tolerable FAIL - PUSHED X-Osstest-Failures: seabios:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking seabios:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking seabios:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking seabios:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking seabios:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking seabios:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking seabios:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: seabios=5d87ff2542c1116e07ae74ba84197a0013e08db1 X-Osstest-Versions-That: seabios=163fd9f0872f95366cfe34eb11568934c2d2fe29 From: osstest service owner Date: Sun, 10 Mar 2024 22:22:44 +0000 flight 184988 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/184988/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop fail like 184972 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 184972 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184972 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop fail like 184972 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 184972 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass version targeted for testing: seabios 5d87ff2542c1116e07ae74ba84197a0013e08db1 baseline version: seabios 163fd9f0872f95366cfe34eb11568934c2d2fe29 Last test of basis 184972 2024-03-09 07:11:10 Z 1 days Testing same since 184988 2024-03-10 17:11:02 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Daniel Verkamp 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-pvops pass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-qemuu-freebsd11-amd64 pass test-amd64-amd64-qemuu-freebsd12-amd64 pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/seabios.git 163fd9f..5d87ff2 5d87ff2542c1116e07ae74ba84197a0013e08db1 -> xen-tested-master From xen-devel-bounces@lists.xenproject.org Mon Mar 11 02:19:27 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 02:19:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691181.1076875 (Exim 4.92) (envelope-from ) id 1rjVFu-0005K8-1U; Mon, 11 Mar 2024 02:19:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691181.1076875; Mon, 11 Mar 2024 02:19:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjVFt-0005K1-To; Mon, 11 Mar 2024 02:19:09 +0000 Received: by outflank-mailman (input) for mailman id 691181; Mon, 11 Mar 2024 02:19:08 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjVFs-0005Jv-8a for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 02:19:08 +0000 Received: from fhigh8-smtp.messagingengine.com (fhigh8-smtp.messagingengine.com [103.168.172.159]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id ba7efaf3-df4d-11ee-afdc-a90da7624cb6; Mon, 11 Mar 2024 03:19:05 +0100 (CET) Received: from compute7.internal (compute7.nyi.internal [10.202.2.48]) by mailfhigh.nyi.internal (Postfix) with ESMTP id 7FD8C11400A3; Sun, 10 Mar 2024 22:19:02 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Sun, 10 Mar 2024 22:19:02 -0400 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 10 Mar 2024 22:19:01 -0400 (EDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ba7efaf3-df4d-11ee-afdc-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= invisiblethingslab.com; h=cc:cc:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1710123542; x=1710209942; bh=VP2jc/P8qd46OULqCsZHqh9JHFNlEKiqUCBbplUrN3g=; b= DDg4xkWuZwLAh5CWDH2GvIkzlK+ZJhTz7j0S1kEnWXJP6H6Gb4Gu4fOyZS5mY/mM IaWekjvx1P5/IH/h7yYv3ZsumXnZog1X+0kGjjbXVPUwSfzgoSyCor+OuA+zUlZR Qk4Cfu61GqZTctvw3RuBb5KTNiaf88Si+4bhKLA9R9ZgakmjNuj3kOgNrQb2kb/+ BtG5Gwc0tveJnfEar/uRIakJHq6qmQp0b7bYREXBb8ytozvjpTwTEfJpGFVEVeR8 1QmoVZbdCdr+FDn7SagVrGplTgPmFug9xqEiLQnWTUoxDQgATwxn6/NiZTeJwkr/ 1pC8as0fl+KTcjNdWoVvxA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1710123542; x=1710209942; bh=VP2jc/P8qd46OULqCsZHqh9JHFNl EKiqUCBbplUrN3g=; b=cZ0vIIrHx3SQ40cfpvKLEbw93iXiZbPb9CjH8RII9ynw aTU2x3tWhR6ySfkvjNPmwzOF6dS0vWm6WJPbcY7kBy8m+SJu95k3r28cpkfntlzX F4zzcFileAkNVRn0STIyzcPPi97EuTOgdt5jrUBOqZTTxB4frxOcxav7mPU9IaDx f+f4Ih4G2V9pav2ARxH79Gx2QxQjUEb8vZwVNu4mms7NDzxhcAO+j5wfJtsWaIA/ 3yLxtoyNaMK0dx/hSg75LOkDuqXH3WL/bUFymCa4Q3Z2e7jNfF290qG6CEjoyG/k HnLV0sEg9LEL3Xfq6eYSLOmEo9FCv5a+YH4HaoKJSA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrjedtgdegiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvvefukfhfgggtuggjsehgtderredttdejnecuhfhrohhmpeforghrvghk ucforghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvh hishhisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpeetfeeu ueevvdeuvdefkeehhfegjefhtddvleefveegjeekfeevudevfeeljeefgeenucffohhmrg hinhepghhithhhuhgsrdgtohhmpdhgihhtlhgrsgdrtghomhenucevlhhushhtvghrufhi iigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhesihhnvhhish hisghlvghthhhinhhgshhlrggsrdgtohhm X-ME-Proxy: Feedback-ID: i1568416f:Fastmail Date: Mon, 11 Mar 2024 03:18:58 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Roger Pau Monne Cc: xen-devel@lists.xenproject.org, Jan Beulich , Andrew Cooper , oxjo@proton.me Subject: Regression with xhci console (was: [PATCH 1/4] amd-vi: fix IVMD memory type checks) Message-ID: References: <20240201170159.66330-1-roger.pau@citrix.com> <20240201170159.66330-2-roger.pau@citrix.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0K9+IosBBskMkRSx" Content-Disposition: inline In-Reply-To: <20240201170159.66330-2-roger.pau@citrix.com> --0K9+IosBBskMkRSx Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Mon, 11 Mar 2024 03:18:58 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Roger Pau Monne Cc: xen-devel@lists.xenproject.org, Jan Beulich , Andrew Cooper , oxjo@proton.me Subject: Regression with xhci console (was: [PATCH 1/4] amd-vi: fix IVMD memory type checks) On Thu, Feb 01, 2024 at 06:01:56PM +0100, Roger Pau Monne wrote: > The current code that parses the IVMD blocks is relaxed with regard to the > restriction that such unity regions should always fall into memory ranges > marked as reserved in the memory map. >=20 > However the type checks for the IVMD addresses are inverted, and as a res= ult > IVMD ranges falling into RAM areas are accepted. Note that having such r= anges > in the first place is a firmware bug, as IVMD should always fall into res= erved > ranges. >=20 > Fixes: ed6c77ebf0c1 ('AMD/IOMMU: check / convert IVMD ranges for being / = to be reserved') > Signed-off-by: Roger Pau Monn=C3=A9 FYI Xen 4.17.3 with this patch (but not others in the series) causes panic on boot on Framework 14 AMD laptop: (XEN) [0000000044570000, 000000005077efff] (usable) ... (XEN) AMD-Vi: Warning: IVMD: [4f83f000,4f880000) is not (entirely) in r= eserved memory (XEN) AMD-Vi: Error: IVMD: page at 4f83f000 can't be converted ... (XEN) Xen BUG at drivers/passthrough/amd/iommu_init.c:1386 Full boot log at https://github.com/QubesOS/qubes-issues/issues/9030 4.17.2 worked fine. I'll try the whole series (and the follow up one), but I don't expect any difference. This looks to be related to XHCI console, which does use the same API to allow device to DMA into relevant buffers even when the rest of XHCI is used by dom0 (or even other domain if 'share=3Dyes' is used): https://gitlab.com/xen-project/xen/-/blob/staging/xen/drivers/char/xhci-dbc= =2Ec?ref_type=3Dheads#L1421-1424 --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab --0K9+IosBBskMkRSx Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmXuahMACgkQ24/THMrX 1yx3YAf/dhs2ytpdfDthEzokauYeBlsjAQyVzVsFnQlGDlYPg0gRCDVxZUQ85h6r vQXqxjCEhKGH1XCr+rGwtzwNHUUBxuYaHlqAlIe0QVIy9/ZwqUcAtVEUpe63At6o h8b8Bx4PTEeYl935cerpogU+ISttrWwfwZVf4nD72frPIOc998si8Mcr1O/4lj/p /St7Mgy2VZn+bEm5xHbuvSRrEtiiMbi3cLTfrX/M1H2zfvFBEwTK9a4wT3TNPEtC mDNBOA/CN7cBC3v3E1u+12qjSa0eeEa/0/6hizZJuSt0RLrLtDrIh+RmgR5SeQvS nSLVAWKRHTMxqaS3fikfkhsEeG9g4Q== =T+r4 -----END PGP SIGNATURE----- --0K9+IosBBskMkRSx-- From xen-devel-bounces@lists.xenproject.org Mon Mar 11 03:00:01 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 03:00:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691185.1076884 (Exim 4.92) (envelope-from ) id 1rjVtH-0001hY-18; Mon, 11 Mar 2024 02:59:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691185.1076884; Mon, 11 Mar 2024 02:59:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjVtG-0001hR-UJ; Mon, 11 Mar 2024 02:59:50 +0000 Received: by outflank-mailman (input) for mailman id 691185; Mon, 11 Mar 2024 02:59:49 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjVtF-0001hH-Tj; Mon, 11 Mar 2024 02:59:49 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjVtF-0005v7-Qi; Mon, 11 Mar 2024 02:59:49 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjVtF-0004xr-ET; Mon, 11 Mar 2024 02:59:49 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rjVtF-0000VS-Dz; Mon, 11 Mar 2024 02:59:49 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=OOCEZYanhAUB2vKguLDYVOsLZM7PS/x5OPYSXgIk7KU=; b=vGSq9r+Iz/oilSbJ7aL//XUVIf k7RDW1+0T3AzB8UokPxvLJ0b2qbkeX095XZU6Ytl9UIVAaD+91qrZIYaZC5pfzkevNU77pHAtQYBX uCcyJ+9MS+kqBlLkMmxJBbhrGhbE3lxac2Zp+6dSNVVJAwInpRz8My9tCsuIKomlPvD0=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-linus test] 184987: tolerable FAIL - PUSHED X-Osstest-Failures: linux-linus:test-amd64-amd64-freebsd12-amd64:guest-localmigrate/x10:fail:heisenbug linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: linux=137e0ec05aeb657472d2f84dbb3081016160334b X-Osstest-Versions-That: linux=005f6f34bd47eaa61d939a2727fc648e687b84c1 From: osstest service owner Date: Mon, 11 Mar 2024 02:59:49 +0000 flight 184987 linux-linus real [real] flight 184990 linux-linus real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/184987/ http://logs.test-lab.xenproject.org/osstest/logs/184990/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-freebsd12-amd64 19 guest-localmigrate/x10 fail pass in 184990-retest Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 16 saverestore-support-check fail like 184985 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop fail like 184985 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop fail like 184985 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop fail like 184985 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 184985 test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail like 184985 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop fail like 184985 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184985 test-amd64-amd64-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl 15 migrate-support-check fail never pass test-arm64-arm64-xl 16 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 15 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 15 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-check fail never pass test-armhf-armhf-libvirt 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qcow2 14 migrate-support-check fail never pass test-amd64-amd64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-check fail never pass test-arm64-arm64-xl-vhd 14 migrate-support-check fail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-check fail never pass version targeted for testing: linux 137e0ec05aeb657472d2f84dbb3081016160334b baseline version: linux 005f6f34bd47eaa61d939a2727fc648e687b84c1 Last test of basis 184985 2024-03-10 04:00:27 Z 0 days Testing same since 184987 2024-03-10 16:44:17 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Kai Huang Linus Torvalds Paolo Bonzini Sean Christopherson jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-amd64-dom0pvh-xl-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-freebsd11-amd64 pass test-amd64-amd64-freebsd12-amd64 fail test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-examine-bios pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-amd64-dom0pvh-xl-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-amd64-xl-pvshim pass test-amd64-amd64-pygrub pass test-amd64-amd64-libvirt-qcow2 pass test-armhf-armhf-libvirt-qcow2 pass test-amd64-amd64-libvirt-raw pass test-arm64-arm64-libvirt-raw pass test-armhf-armhf-libvirt-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-examine-uefi pass test-amd64-amd64-xl-vhd pass test-arm64-arm64-xl-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these 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 : hint: The 'hooks/update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-receive' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. To xenbits.xen.org:/home/xen/git/linux-pvops.git 005f6f34bd47e..137e0ec05aeb6 137e0ec05aeb657472d2f84dbb3081016160334b -> tested/linux-linus From xen-devel-bounces@lists.xenproject.org Mon Mar 11 06:03:51 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 06:03:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691194.1076896 (Exim 4.92) (envelope-from ) id 1rjYl3-0006Nf-1x; Mon, 11 Mar 2024 06:03:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691194.1076896; Mon, 11 Mar 2024 06:03:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjYl2-0006NY-TL; Mon, 11 Mar 2024 06:03:32 +0000 Received: by outflank-mailman (input) for mailman id 691194; Mon, 11 Mar 2024 06:03:31 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjYl1-0006NM-QA; Mon, 11 Mar 2024 06:03:31 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjYl1-0001iA-K2; Mon, 11 Mar 2024 06:03:31 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjYl1-00044Z-Bh; Mon, 11 Mar 2024 06:03:31 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rjYl1-0006Po-BG; Mon, 11 Mar 2024 06:03:31 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=79kEOL1UBktxRqs8DVcLXZXzBmoL0UY7SVQc83DUt80=; b=g4oOEc85qG5DuDinZJVQEuF09v eWSiFkaHH6PWQjdugqL2YGsP9ALfSQ1R99PMGFJsSaQ2Q+0tGFZwItpsN4FGC2Hkf555cCovWGqUp c5J/FNAmITpF/sfwVQMzDra6QoFw63vXl4a5RJ3evduNZJq4sdjERi2HRtTU1dOXW38o=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable test] 184989: regressions - FAIL X-Osstest-Failures: xen-unstable:test-amd64-amd64-livepatch:livepatch-run:fail:regression xen-unstable:test-amd64-i386-livepatch:livepatch-run:fail:regression xen-unstable:test-amd64-amd64-xl-credit1:guest-localmigrate/x10:fail:heisenbug xen-unstable:test-amd64-amd64-xl-qemut-debianhvm-amd64:guest-localmigrate/x10:fail:heisenbug xen-unstable:test-amd64-i386-xl-qemut-debianhvm-i386-xsm:debian-hvm-install:fail:heisenbug xen-unstable:test-amd64-amd64-xl-qemut-debianhvm-i386-xsm:debian-hvm-install:fail:heisenbug xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:windows-install:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: xen=ef31ffbc3dc124173fc9420988772fa96bc4bf12 X-Osstest-Versions-That: xen=66c8e9b76c61ff52cfc0b186a38208907845d093 From: osstest service owner Date: Mon, 11 Mar 2024 06:03:31 +0000 flight 184989 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/184989/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-livepatch 13 livepatch-run fail REGR. vs. 184927 test-amd64-i386-livepatch 13 livepatch-run fail REGR. vs. 184927 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-credit1 20 guest-localmigrate/x10 fail in 184986 pass in 184989 test-amd64-amd64-xl-qemut-debianhvm-amd64 18 guest-localmigrate/x10 fail pass in 184986 test-amd64-i386-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail pass in 184986 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail pass in 184986 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop fail blocked in 184927 test-amd64-amd64-xl-qemuu-win7-amd64 12 windows-install fail in 184986 like 184927 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop fail like 184927 test-armhf-armhf-libvirt 16 saverestore-support-check fail like 184927 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 184927 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop fail like 184927 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 184927 test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail like 184927 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 184927 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop fail like 184927 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 184927 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 184927 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184927 test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-amd64-i386-xl-pvshim 14 guest-start fail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-check fail never pass test-amd64-i386-libvirt 15 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-check fail never pass test-arm64-arm64-xl 15 migrate-support-check fail never pass test-arm64-arm64-xl 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 15 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-check fail never pass test-armhf-armhf-libvirt 15 migrate-support-check fail never pass test-amd64-i386-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-check fail never pass test-arm64-arm64-xl-vhd 14 migrate-support-check fail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-check fail never pass version targeted for testing: xen ef31ffbc3dc124173fc9420988772fa96bc4bf12 baseline version: xen 66c8e9b76c61ff52cfc0b186a38208907845d093 Last test of basis 184927 2024-03-07 00:10:52 Z 4 days Failing since 184940 2024-03-07 19:47:48 Z 3 days 6 attempts Testing same since 184974 2024-03-09 08:14:48 Z 1 days 4 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Anthony PERARD Federico Serafini Henry Wang Jan Beulich Juergen Gross Oleksii Kurochko jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm fail test-amd64-i386-xl-qemut-debianhvm-i386-xsm fail test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-dom0pvh-xl-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 fail test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-qemuu-freebsd11-amd64 pass test-amd64-amd64-qemuu-freebsd12-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-examine-bios pass test-amd64-i386-examine-bios pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-dom0pvh-xl-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch fail test-amd64-i386-livepatch fail test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-armhf-armhf-libvirt-qcow2 pass test-amd64-amd64-xl-qcow2 pass test-arm64-arm64-libvirt-raw pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-libvirt-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-examine-uefi pass test-amd64-i386-examine-uefi pass test-amd64-amd64-libvirt-vhd pass test-arm64-arm64-xl-vhd pass test-armhf-armhf-xl-vhd pass test-amd64-i386-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these 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 ef31ffbc3dc124173fc9420988772fa96bc4bf12 Author: Federico Serafini Date: Mon Mar 4 11:28:37 2024 +0100 automation/eclair: add deviation for MISRA C:2012 Rule 16.6 Update ECLAIR configuration to take into account the deviations agreed during MISRA meetings. Signed-off-by: Federico Serafini Reviewed-by: Stefano Stabellini commit 90173fc5a2a826bbcabde22af405d0a617818b70 Author: Henry Wang Date: Thu Mar 7 21:56:16 2024 +0800 tools/9pfsd: Fix build error caused by strerror_r Below error can be seen when doing Yocto build of the toolstack: | io.c: In function 'p9_error': | io.c:684:5: error: ignoring return value of 'strerror_r' declared with attribute 'warn_unused_result' [-Werror=unused-result] | 684 | strerror_r(err, ring->buffer, ring->ring_size); | | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | cc1: all warnings being treated as errors Using strerror_r() without special casing different build environments is impossible due to the different return types (int vs char *) depending on the environment. As p9_error() is not on a performance critical path, using strerror() with a mutex ought to be fine. So, fix the build by using strerror() to replace strerror_r(). The steps would then become: Acquire the mutex first, invoke strerror(), copy the string from strerror() to the designated buffer and then drop the mutex. Fixes: f4900d6d69b5 ("9pfsd: allow building with old glibc") Signed-off-by: Henry Wang Reviewed-by: Jan Beulich Reviewed-by: Juergen Gross Acked-by: Anthony PERARD commit b52c45b1bdf04469495dd046ba15dd35a8becfa5 Author: Juergen Gross Date: Wed Mar 6 12:16:31 2024 +0100 MAINTAINERS: add an entry for tools/9pfsd Add me as the maintainer for the tools/9pfsd directory. Signed-off-by: Juergen Gross Reviewed-by: Andrew Cooper commit b083b1c393dc8961acf0959b1d2e0ad459985ae3 Author: Andrew Cooper Date: Tue Mar 5 11:39:19 2024 +0000 x86/livepatch: Relax permissions on rodata too This reinstates the capability to patch .rodata in load/unload hooks, which was lost when we stopped using CR0.WP=0 to patch. This turns out to be rather less of a large TODO than I thought at the time. Fixes: 8676092a0f16 ("x86/livepatch: Fix livepatch application when CET is active") Signed-off-by: Andrew Cooper Reviewed-by: Roger Pau Monné Reviewed-by: Ross Lagerwall commit ef969144a425e39f5b214a875b5713d0ea8575fb Author: Andrew Cooper Date: Tue Mar 5 11:35:12 2024 +0000 xen/virtual-region: Include rodata pointers These are optional. .init doesn't distinguish types of data like this, and livepatches don't necesserily have any .rodata either. No functional change. Signed-off-by: Andrew Cooper Reviewed-by: Roger Pau Monné Reviewed-by: Ross Lagerwall commit 989556c6f8ca080f5f202417af97d1188b9ba52a Author: Andrew Cooper Date: Tue Mar 5 11:28:33 2024 +0000 xen/virtual-region: Rename the start/end fields ... to text_{start,end}. We're about to introduce another start/end pair. Despite it's name, struct virtual_region has always been a module-ish description. Call this out specifically. As minor cleanup, replace ROUNDUP(x, PAGE_SIZE) with the more concise PAGE_ALIGN() ahead of duplicating the example. No functional change. Signed-off-by: Andrew Cooper Reviewed-by: Roger Pau Monné Reviewed-by: Ross Lagerwall commit 08bb338f09a54d3b39f0d952bbd67461d8e5d0ed Author: Juergen Gross Date: Thu Mar 7 09:18:04 2024 +0100 SUPPORT.md: add xen-9pfsd Add a support statement for the new xen-9pfsd backend. Set it to "Experimental", as some functionality for Linux guests is missing (only tested to work with Xenstore-stubdom). Signed-off-by: Juergen Gross Acked-by: Jan Beulich commit 49b664f5bffa3a86734c66491d7dcdebbdecfb26 Author: Jan Beulich Date: Thu Mar 7 09:17:26 2024 +0100 x86/asm: add commas to further macros definitions/invocations In light of recent observations with how macros are handled by gas, let's play by what we informally set for ourselves as a guideline: Use commas to separate parameters/arguments. Requested-by: Andrew Cooper Signed-off-by: Jan Beulich Acked-by: Andrew Cooper commit 4ad4df0964aa374562fa574d4671d278f54f5d32 Author: Juergen Gross Date: Thu Mar 7 09:16:53 2024 +0100 CHANGELOG: add an entry for 9pfsd Add an entry to CHANGELOG.md regarding the new xen-9pfsd daemon. Signed-off-by: Juergen Gross Acked-by: Oleksii Kurochko commit 9249a441c98ff063c0c065538b419a3bf1dac24a Author: Jan Beulich Date: Thu Mar 7 09:16:13 2024 +0100 x86/asm: add commas to BUILD_BUG_ON In light of recent observations with how macros are handled by gas, let's play by what we informally set for ourselves as a guideline: Use commas to separate parameters/arguments. Signed-off-by: Jan Beulich Acked-by: Andrew Cooper commit 5daf46b439454921c19ca30840bb39424b36444b Author: Jan Beulich Date: Thu Mar 7 09:15:17 2024 +0100 Kbuild: simplify as-insn a little As of 732571959f17 ("xen/build: use new $(c_flags) and $(a_flags) instead of $(CFLAGS)") -M options aren't part of CFLAGS anymore, and c_flags isn't supposed to be passed to this macro. Drop the now dead part of filtering. Signed-off-by: Jan Beulich Reviewed-by: Anthony PERARD commit 2f7481d59255680c1de98f43467d3862453dd50a Author: Jan Beulich Date: Thu Mar 7 09:14:55 2024 +0100 x86/EFI: correct compiler probing Passing in $(CFLAGS) means also requesting inclusion of certain headers (via -include command line options). That's particularly xen/config.h, which in turn requires generated/autoconf.h. This has not caused any problems so far only because arch.mk is processed twice, and the missing header on the 1st pass would be there on the 2nd. Having added an inclusion of asm/asm-macros.h to x86'es asm/config.h, the 2nd pass then also fails on an initial, pristine build. As per dd40177c1bc8 ("x86-64/EFI: add CFLAGS to check compile") dropping the use of $(CFLAGS) altogether isn't an option, though. Hence remove the problematic options only. Signed-off-by: Jan Beulich Reviewed-by: Anthony PERARD (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Mon Mar 11 07:33:05 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 07:33:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691203.1076905 (Exim 4.92) (envelope-from ) id 1rja9T-0007pK-A2; Mon, 11 Mar 2024 07:32:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691203.1076905; Mon, 11 Mar 2024 07:32:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rja9T-0007pD-6T; Mon, 11 Mar 2024 07:32:51 +0000 Received: by outflank-mailman (input) for mailman id 691203; Mon, 11 Mar 2024 07:32:49 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rja9R-0007p7-QK for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 07:32:49 +0000 Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [2a00:1450:4864:20::535]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 8e1651c9-df79-11ee-a1ee-f123f15fe8a2; Mon, 11 Mar 2024 08:32:46 +0100 (CET) Received: by mail-ed1-x535.google.com with SMTP id 4fb4d7f45d1cf-5684db9147dso1002884a12.2 for ; Mon, 11 Mar 2024 00:32:46 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id bm24-20020a0564020b1800b005682f8b62a6sm2616809edb.97.2024.03.11.00.32.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Mar 2024 00:32:45 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8e1651c9-df79-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1710142366; x=1710747166; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=B3RvATf96rWv6M4+vM3PXqEhIxUAX6vcQRD5Vf2iN8A=; b=bwyXJ2LNT6+cK78+n9yDkmH4h7/fHc6/n+X47OENCEKy0oIq/FD/52QFznhLrSMuGn GtPEOt6NNRFlr+p0ftb1EzLHHQKraYW7KQwXfGbxc5RtNmKgnQpjxALBJ1Omt4GL3/fR 6qRKx9tORJmqDcxWYUWUh9U5WxMc/7n7V9dd7Iss9DlBaN2WcTxN2gW/BfpG0udGXr9E ZJXoDTTladrWO13rhSid3qJjFtogT1LxlBSb/D96HEUBTfDGJvu2fj1nh6UT9kGQ3BDr H0/cBLpJ84/S9NVq5yXMWzZ/tjaG55mAePkPR7qe6DxWn6dtgZlIL8FT/l61K09IczPE iQ6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710142366; x=1710747166; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=B3RvATf96rWv6M4+vM3PXqEhIxUAX6vcQRD5Vf2iN8A=; b=i3G4mFtXJI6/3Ee2ew4E/3CT9XwsUsX/J5bsny7tW/kN9GEFPcXW+93+xNB2woXnA6 ep1dVczYJC00Y06osYRFPQCgJN9uGLMG1iZ2cqygnHHZguoydpHFc7UTg6znmdz156dO jGxRERS7xV7TnPgqGaAiY/d0tvMZiVFnRop1QU/5b8kovbxiYEcFFbqbeRs9tTQ5DSl0 xGeQOkNtsXC/qeFCTyPBlJYP+lqEoRZu04ZPVhoKtKFem3Iomjcg5EwVQPUPoeF/6hJY MundY6x8pH9altXL7k4Nuc4p3FwjbWHCTVaGz+W9n2vLw4Z2nEhcfOM/s+PZLr+F1+j1 r/uQ== X-Forwarded-Encrypted: i=1; AJvYcCXRF+Q2V7FRQe0BBe4q8NbAkadecOeduykOglguzeTYpXiq63Ss9R5Td5TywVKPoXYIlTaMS9LL7z/slKZPWZHxZp3LhjP82aeICiwKImo= X-Gm-Message-State: AOJu0YwQ2gpS55rpseyjZg7fBYRAFjoG0dIFTayzeHCCBiiBcL6nYMH/ HJLEzqZbC9OFLk30nbZwMHmuI2Fajl16EYzekQJ1Fr5RVS7NPTaN45pFmRGNjw== X-Google-Smtp-Source: AGHT+IH6Vkzm37VcSz+pvebU/96ODzs6PMdegr8j4jXCeuOsCALjSsVOZC46ECmXwBicAute4wsPDA== X-Received: by 2002:a50:ab1c:0:b0:568:3367:d603 with SMTP id s28-20020a50ab1c000000b005683367d603mr3606916edc.2.1710142365871; Mon, 11 Mar 2024 00:32:45 -0700 (PDT) Message-ID: <6e2c0cb6-89de-4429-8f43-c4687a26cefe@suse.com> Date: Mon, 11 Mar 2024 08:32:46 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH] xen/compiler: deviate the inline macro for MISRA C Rule 20.4 Content-Language: en-US To: Nicola Vetrini Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, consulting@bugseng.com, bertrand.marquis@arm.com, julien@xen.org, Andrew Cooper , George Dunlap , Wei Liu , xen-devel@lists.xenproject.org References: From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 08.03.2024 09:10, Nicola Vetrini wrote: > Rule 20.4 states: "A macro shall not be defined with the same name > as a keyword". > > Defining this macro with the same name as the inline keyword > allows for additionally checking that out-of-lined static inline > functions end up in the correct section while minimizing churn and > has a positive impact on the overall safety. See [1] for additional > context on the motivation of this deviation. > > No functional change. > > [1] https://lore.kernel.org/xen-devel/adaa6d55-266d-4df8-8967-9340080d17e4@citrix.com/ > > Signed-off-by: Nicola Vetrini > --- > docs/misra/safe.json | 8 ++++++++ > xen/include/xen/compiler.h | 1 + > 2 files changed, 9 insertions(+) > > diff --git a/docs/misra/safe.json b/docs/misra/safe.json > index 952324f85cf9..a2bbacddf06a 100644 > --- a/docs/misra/safe.json > +++ b/docs/misra/safe.json > @@ -28,6 +28,14 @@ > }, > { > "id": "SAF-3-safe", > + "analyser": { > + "eclair": "MC3R1.R20.4" > + }, > + "name": "MC3R1.R20.4: allow the augmentation of the inline keyword in some build configurations", > + "text": "The definition of this macro named inline allows further checking in some build configurations that certain symbols end up in the right sections." > + }, With this wording the ID isn't going to be re-usable anywhere else. Even if the exact same reasoning would apply. > + { > + "id": "SAF-4-safe", > "analyser": {}, > "name": "Sentinel", > "text": "Next ID to be used" > diff --git a/xen/include/xen/compiler.h b/xen/include/xen/compiler.h > index 16d554f2a593..e3d9f9fb8e4b 100644 > --- a/xen/include/xen/compiler.h > +++ b/xen/include/xen/compiler.h > @@ -82,6 +82,7 @@ > * inline functions not expanded inline get placed in .init.text. > */ > #include > +/* SAF-3-safe MISRA C Rule 20.4: define the inline macro to perform checks */ > #define inline inline __init > #endif I don't think the definition is "to perform checks"; it's rather to make sure checking elsewhere wouldn't (seemingly) randomly fail. 'Override "inline" for section contents checks to pass when the compiler chooses not to inline a particular function' perhaps? Albeit that's getting long-ish, I fear. Jan From xen-devel-bounces@lists.xenproject.org Mon Mar 11 07:40:29 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 07:40:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691208.1076915 (Exim 4.92) (envelope-from ) id 1rjaGo-00011l-5h; Mon, 11 Mar 2024 07:40:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691208.1076915; Mon, 11 Mar 2024 07:40:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjaGo-00011e-2A; Mon, 11 Mar 2024 07:40:26 +0000 Received: by outflank-mailman (input) for mailman id 691208; Mon, 11 Mar 2024 07:40:24 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjaGm-00011V-CT for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 07:40:24 +0000 Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [2a00:1450:4864:20::62a]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 9da9c632-df7a-11ee-a1ee-f123f15fe8a2; Mon, 11 Mar 2024 08:40:22 +0100 (CET) Received: by mail-ej1-x62a.google.com with SMTP id a640c23a62f3a-a3fb8b0b7acso284738066b.2 for ; Mon, 11 Mar 2024 00:40:22 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id y26-20020a170906471a00b00a45ad52d510sm2608883ejq.139.2024.03.11.00.40.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Mar 2024 00:40:21 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 9da9c632-df7a-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1710142821; x=1710747621; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=kNSQpzQh8XqKnFyK4B50zqOK1xBn3feJQ+pPGR+Q9lY=; b=JlYGFyWuK9wl3VnwKepzwu3r4Xu3EQGITAWGLScVHLUa4Wy3u00PVm1SPRf+SWfcW5 dmwkQoMwDmsddWAyk2DSURs7LbfZ+m+TeXE/0V9Q1N6Ra/ezuHk9EAsS5Xo2ajc0xWch dz8BD89AAk+EsmmxOuqzQ3Jrq+1IDI6IA1M7QNgrhusr2QZpQdhjmslnrqvputO0kHEB 2GS3BAorETilx4avCva0HihdfFG5kOueoDzLbqwTiaBkp2CV/K5KlZDZccx26E4AYhQV nAd0x1lJ8c1Gl0v4g9nULfayHLjP9tc1zZhuh14VlPqbVROF7eheECEP1kUSmm9JEHo9 qKMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710142821; x=1710747621; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=kNSQpzQh8XqKnFyK4B50zqOK1xBn3feJQ+pPGR+Q9lY=; b=C9Unwyj3ujUpMcQ2r/McZtLJgOA7teekONVQAbcx1lRDgeFENt57JTRt2xrnNbRJD7 N64CSwB5hiY30VsFLliQqrPmqBVJhtWo4CtHPZOda31FFcHM4LCeX9F8TrTKs935AQgv U2yojVtwSKVJzKXhOEurDnd+53mv9hc/oxPTNf/xaDA3REGzOyjXlMeV1ky/W725GisF 0Bgpnl/RAs2CBuvDDztD6NKb59Wu/AbPu0DfUEEwULib+44w6/lDqbKStnt0Lb3sLeDP waBDDp1w03pj2YXNiulQ/mTF6Ux4cdRH32vzMcYUJG9z1ZgynjAfB6hvcQFsgQtFmv2i ngWA== X-Forwarded-Encrypted: i=1; AJvYcCULXKYlSRTNhl4RQ2xqdMSRSB4NyqGj5dS+HVNUx6+SujFWcPhcs00W+SK2+sX4Z8VajTJ41q6Ct5PpgXQgH5S/UCMY/M4xs4KpxbL2+b0= X-Gm-Message-State: AOJu0YyR6gstAvmaORwISw27n/lQlVmAuyQqXsEcSNspvPSWUHfHbE5K 1sfkW1mlxgrWhTOUXxkgTyCKUGhuR86YrYjZI8GsLjgCipxbBx2ZsWCZ0eCnHw== X-Google-Smtp-Source: AGHT+IHxAPMZBAyhZCi/rlbcCgEbREQxW1vZ7bus7lsBZwpHK09gC8T7NVgPm8DBy7e91I6fpi3ekA== X-Received: by 2002:a17:907:7847:b0:a44:1fcf:9b97 with SMTP id lb7-20020a170907784700b00a441fcf9b97mr3062251ejc.24.1710142821487; Mon, 11 Mar 2024 00:40:21 -0700 (PDT) Message-ID: Date: Mon, 11 Mar 2024 08:40:22 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH] xen/evtchn: address violations of MISRA C:2012 Rules 16.3 and 16.4 Content-Language: en-US To: Federico Serafini , Stefano Stabellini Cc: consulting@bugseng.com, Andrew Cooper , George Dunlap , Julien Grall , Wei Liu , xen-devel@lists.xenproject.org References: <3ec419e30227a8016c28e04524cd36a549aaddcf.1709898466.git.federico.serafini@bugseng.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <3ec419e30227a8016c28e04524cd36a549aaddcf.1709898466.git.federico.serafini@bugseng.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 08.03.2024 12:51, Federico Serafini wrote: > --- a/xen/common/event_channel.c > +++ b/xen/common/event_channel.c > @@ -130,9 +130,12 @@ static bool virq_is_global(unsigned int virq) > > case VIRQ_ARCH_0 ... VIRQ_ARCH_7: > return arch_virq_is_global(virq); > + > + default: > + ASSERT(virq < NR_VIRQS); > + break; > } > > - ASSERT(virq < NR_VIRQS); > return true; > } Just for my understanding: The ASSERT() is moved so the "default" would consist of more than just "break". Why is it that then the "return" isn't moved, too? > @@ -846,6 +849,7 @@ int evtchn_send(struct domain *ld, unsigned int lport) > break; > default: > ret = -EINVAL; > + break; > } I certainly agree here. > @@ -1672,6 +1676,9 @@ static void domain_dump_evtchn_info(struct domain *d) > case ECS_VIRQ: > printk(" v=%d", chn->u.virq); > break; > + default: > + /* Nothing to do in other cases. */ > + break; > } Yes this, just to mention it, while in line with what Misra demands is pretty meaningless imo: The absence of "default" says exactly what the comment now says. FTAOD - this is a comment towards the Misra guideline, not so much towards the specific change here. One other remark though, considering the specific function we're in: In a certifiable environment, will there actually be the capability to issue debug keys? Shouldn't we have a Kconfig option allowing to remove all that from a build (and then also from relevant scans)? Jan From xen-devel-bounces@lists.xenproject.org Mon Mar 11 07:49:04 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 07:49:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691212.1076925 (Exim 4.92) (envelope-from ) id 1rjaP3-0001fT-Uy; Mon, 11 Mar 2024 07:48:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691212.1076925; Mon, 11 Mar 2024 07:48:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjaP3-0001fM-Rr; Mon, 11 Mar 2024 07:48:57 +0000 Received: by outflank-mailman (input) for mailman id 691212; Mon, 11 Mar 2024 07:48:56 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjaP2-0001fG-27 for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 07:48:56 +0000 Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [2a00:1450:4864:20::52d]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id cf63db75-df7b-11ee-afdc-a90da7624cb6; Mon, 11 Mar 2024 08:48:55 +0100 (CET) Received: by mail-ed1-x52d.google.com with SMTP id 4fb4d7f45d1cf-563c595f968so4814949a12.0 for ; Mon, 11 Mar 2024 00:48:55 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id oz14-20020a170906cd0e00b00a44a859fd9dsm2654988ejb.174.2024.03.11.00.48.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Mar 2024 00:48:54 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: cf63db75-df7b-11ee-afdc-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1710143334; x=1710748134; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=5YnNVAOc7BXvV5iVxvavJvXDOKz/8kh5qY/iWDfQuo0=; b=Jd+aOOHBA7BJUfQRL4ujWxV+m9w8Ttvca67/ySYfhraWAxB0Nb2jNujdMw5FFbBtNV IAQUMJl3+/2VvuT6cZLgu7DAJzndvqQjtXlYxuyLKSmYVvBN3Sifz+d5gE+lpCSOrBt2 u5IfFEHl6GflgtaYA5vryE2mKBVv/RHu/t/EBrrVtgQ7haaVxUbf/VL6jK2YZTrwaLeX quUtLRjfv9pqYbcNzaHJYYSPcOlKh3eAs94ob+camlyBHj6FMHi1tTwqHgr/BEtQa8DG 0a8VI6L/ya3Qsb32U4uu8IMd7WjgIEqDk79moemxuHlit3NTNk4kgwSKUr7YIjbzpJws qBUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710143334; x=1710748134; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=5YnNVAOc7BXvV5iVxvavJvXDOKz/8kh5qY/iWDfQuo0=; b=dwaABXSKsGJzgddOZ4hw2HvOUw5vc5LM/hVvWygDLMGYqPgNINzwVI2iHntzDxCDJe BnQJDjpGbEAy7B20nWWMYuKc0ox3pTgsJUnbm9gwKP2B6y+kz/vhYViw2FRfSzsjHOCb 6wVWMn7YnrrseYxCrASQSJXzXCF/vh4UwxTv+Qp5sm31V1ByDV0TPMIGTz+eNniNFUCi LxCMUFr5eQT2sjo5eb90Vpg2N2nkFkToEu5/VH23xPW/KiYBRYgJ98VP9DwRkqkjC01R YD66V2SAVXrefSroEcp/4Ium+k0Coe6HlSvCIOFJzhfURggZt160dpL4yISJpvWw72uV VVfg== X-Forwarded-Encrypted: i=1; AJvYcCU64qCD97AHn06VcRrpeCqGH8Y7LUHbcSrZon2CobU4uiS8HKjrboIFk19tSNFWdRCWPJ8DkM58FF8PD6Sdv0xWMWjXYMkxMVa4OJSe5ao= X-Gm-Message-State: AOJu0Ywvemt3LNGlyrtejXGqZy/ikJMCIkIvr5gMOcz3eGL1q45GwjTz 3pLA705Q2YldcRdBM9+1ZCHWN2rFHWUti+ii74ujGIcc2mDC9tZou2DunUcJpg== X-Google-Smtp-Source: AGHT+IE0zHiIdB9+wg9JSh8aBlHc7Vl6l9/UnGMzGeYHGT24LuoYdmP0qpNoAjQF4ep9OYyTvAIF5Q== X-Received: by 2002:a17:907:c20e:b0:a46:19a7:3b2 with SMTP id ti14-20020a170907c20e00b00a4619a703b2mr2452848ejc.37.1710143334531; Mon, 11 Mar 2024 00:48:54 -0700 (PDT) Message-ID: <0d3af110-773e-40bd-bd95-b385f49a7c47@suse.com> Date: Mon, 11 Mar 2024 08:48:55 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH v2 3/7] xen/list: address violations of MISRA C Rule 20.7 Content-Language: en-US To: Nicola Vetrini Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, consulting@bugseng.com, bertrand.marquis@arm.com, julien@xen.org, Andrew Cooper , George Dunlap , Wei Liu , xen-devel@lists.xenproject.org References: From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 08.03.2024 12:21, Nicola Vetrini wrote: > --- a/xen/include/xen/list.h > +++ b/xen/include/xen/list.h > @@ -479,9 +479,9 @@ static inline void list_splice_init(struct list_head *list, > * @n: another &struct list_head to use as temporary storage > * @head: the head for your list. > */ > -#define list_for_each_backwards_safe(pos, n, head) \ > - for ( pos = (head)->prev, n = pos->prev; pos != (head); \ > - pos = n, n = pos->prev ) > +#define list_for_each_backwards_safe(pos, n, head) \ > + for ( (pos) = (head)->prev, n = (pos)->prev; (pos) != (head); \ > + (pos) = n, n = (pos)->prev ) I think this is worse than before and incomplete: At least the rhs use of n also needs parenthesizing. Plus if pos is parenthesized even in lhs instances, imo n ought to be, too. Jan From xen-devel-bounces@lists.xenproject.org Mon Mar 11 07:50:40 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 07:50:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691215.1076935 (Exim 4.92) (envelope-from ) id 1rjaQh-0003Dc-7w; Mon, 11 Mar 2024 07:50:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691215.1076935; Mon, 11 Mar 2024 07:50:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjaQh-0003DV-5C; Mon, 11 Mar 2024 07:50:39 +0000 Received: by outflank-mailman (input) for mailman id 691215; Mon, 11 Mar 2024 07:50:38 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjaQg-0003DP-Ge for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 07:50:38 +0000 Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [2a00:1450:4864:20::534]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 0bde9c53-df7c-11ee-a1ee-f123f15fe8a2; Mon, 11 Mar 2024 08:50:36 +0100 (CET) Received: by mail-ed1-x534.google.com with SMTP id 4fb4d7f45d1cf-5649c25369aso3509303a12.2 for ; Mon, 11 Mar 2024 00:50:36 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id bm24-20020a0564020b1800b005682f8b62a6sm2630131edb.97.2024.03.11.00.50.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Mar 2024 00:50:35 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 0bde9c53-df7c-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1710143436; x=1710748236; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=heOoF6FxPXs5QfTjJ0UPeg4ZxggrXWoqaBJ8pkjzs4o=; b=TlQ94GfMpz2B5zGoTCaGjftZ8fqeB7VKMWc0Nk8Yd8rmCl/sKsl6GLByhVXqu4swV/ bFZMpCcJPMjcXGAbFzhfsbY5665ZDpPkPAa2bRx9YfcNFQDRwMBmmluBWC4ESi5lew/O dT3E6JOMq6/7EnykMAwAg/qwe8n2I4+Z0OjRsNa9MfzHUwkfsLodC+JySsE+PmpRZzfv +iofQB1qIXeJbxmzRjANbaotfNI/WZ4tMffSKU1H9XeGq5Xwv0u18vHmE5Ixdhy277eI p/MwlnzP1WrKRahVI1RCGnROZL0RY9fM6nUagpIjy89zAm7atoWIZ5JtdsPxnm9mZO0G ds2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710143436; x=1710748236; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=heOoF6FxPXs5QfTjJ0UPeg4ZxggrXWoqaBJ8pkjzs4o=; b=wHqPIGiVyiekn3ZgiF8ls2j24MDEGsJp3kDjA9/ikA3ajQ/ZFcZIlUshcu2u7F0M6E X8KSn5DZifRTR7ZAm4VxijieGu1gBzj95ktDhSFEtzCIiz/fnNwBK85HQqIpIL5ZpMRo wsUnSj0iU0MJhmgJcGY96m7D+4zk6cJTTHK70K+G/8vGTLq2jB8hi+giELjjHCmdlqDv KnKZvzQI4+0NLuuLbEbpgbsSv9P1r1jzGu3K400i0UJpG+v8SxA2CPExJYKfYGkS3U32 WQ3evmVT864VVsA1qwKiJcXbIfQcxiuPM+zCRIDmA2mkzzhvNT5fS91javr6BRQJYWIE J0eg== X-Gm-Message-State: AOJu0Yzw5dU2HGDT+n+Xf1vbz4R1pIVPUYxiOUd0SuIL7xqUnMnoY4Sn 21vzYmW7T9B2eJ4shuw6d8AnDjmm0G0acuK8VPSEmQLwpKVh5rtz/aPIHZyB6A== X-Google-Smtp-Source: AGHT+IGL8ovGi+HY4xGYzYTRNd5gLrld9lXPXG9R1mMykyhL22NTuOACuk/gAvk1NQXL3EoiqobWGw== X-Received: by 2002:a50:d59c:0:b0:568:1c64:277c with SMTP id v28-20020a50d59c000000b005681c64277cmr4108140edi.15.1710143435959; Mon, 11 Mar 2024 00:50:35 -0700 (PDT) Message-ID: <2a676fc3-ce69-4943-9c40-66056d5503da@suse.com> Date: Mon, 11 Mar 2024 08:50:36 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH v2 6/7] x86/irq: parenthesize negative constants Content-Language: en-US To: Nicola Vetrini Cc: xen-devel@lists.xenproject.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, consulting@bugseng.com, bertrand.marquis@arm.com, julien@xen.org, Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu , Stefano Stabellini References: <9b7e9135952e51043427e3233305917126c95659.1709896401.git.nicola.vetrini@bugseng.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 09.03.2024 02:54, Stefano Stabellini wrote: > On Fri, 8 Mar 2024, Nicola Vetrini wrote: >> These constants are parenthesized to avoid them from >> possibly influencing the semantics of the constructs where it is used, >> especially inside macros invocations. >> >> This also resolves some violations of MISRA C Rule 20.7 >> ("Expressions resulting from the expansion of macro parameters shall >> be enclosed in parentheses"). >> >> No functional change. >> >> Signed-off-by: Nicola Vetrini > > Reviewed-by: Stefano Stabellini Acked-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Mon Mar 11 07:58:33 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 07:58:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691224.1076949 (Exim 4.92) (envelope-from ) id 1rjaYI-000425-2Q; Mon, 11 Mar 2024 07:58:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691224.1076949; Mon, 11 Mar 2024 07:58:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjaYH-00041y-W9; Mon, 11 Mar 2024 07:58:29 +0000 Received: by outflank-mailman (input) for mailman id 691224; Mon, 11 Mar 2024 07:58:28 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjaYG-00041s-JO for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 07:58:28 +0000 Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [2a00:1450:4864:20::536]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 2400827f-df7d-11ee-a1ee-f123f15fe8a2; Mon, 11 Mar 2024 08:58:26 +0100 (CET) Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-5684ea117a3so1799282a12.0 for ; Mon, 11 Mar 2024 00:58:26 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id d23-20020a056402001700b0056857701bf5sm924632edu.81.2024.03.11.00.58.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Mar 2024 00:58:25 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 2400827f-df7d-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1710143906; x=1710748706; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=dulDBGKIMAQ9Uv14fCeI1V67r13X50fp7iYs7ios30M=; b=GoaTC/SLxf7iolph2CpXu5ovPPBWHErB/W8aD9Vdj0nCpn2AdB/ta0v5JCBoLF2KH7 hjahZPOHHtm0ae3E226VWf17XLt3By3rXWQ+qioPw8Jl3n1MIknTET7ZNYvbuZHGbglu BauWVkVjGv1L+tV7NhQO6eAWsoq3blwgIwASqw9s9GTqN/H4goo4ukTY4dHElrsgYnum y6oVKYg7BsNbbNA1tf4ZIajlREczsqSu8L9f2W1HyoxBzgAqr5Y6pOlmrbVQJkDCA2S2 FiD+7uEW7gFXFEAM8etxh4l96K4ks312OFsy2DB/cP9cHYobolIz1RPh2CjYHA1UZZ4z D22g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710143906; x=1710748706; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=dulDBGKIMAQ9Uv14fCeI1V67r13X50fp7iYs7ios30M=; b=kq0QdJdLVrrXPyUTWT9V5/MK9ya1uxUxv/d2l3dGV9siyGsIMgXphzucCYpF3Vdagd niuBAUbBtNVOtDvwoTZcqu+vCvy3KLZ54Khbgbe0kepolaBOwjCO/l/gKaOKsFIapja6 pioUBsHc6VBNoKghH1INcw46wtK8iAjJzgJ6AxZ2rbeO4aOR2Xk71crGPu/n6OjFTC/x mNGNWg/FWGNGxPl01KEIsjnEJZ5oBATwzwHFD01O29yYKlVYi1kBpIB/VlZtdtDyYJdG 9lBLWjAwc4XcBCFDvL/JrGvS1Pg52gl6iPNDRPH9mPo1+XL0xopbiDYzjnWQvOr3vPcy LeWQ== X-Gm-Message-State: AOJu0YxCXY6zwFrKmeHu9RqtR05IZ73MpO8j29aghYov6YSeyABh3hIp hW5r1fHz43eItmL+UzgL75FNVpPWIOEue1Y8SyOufZ6L4k0KmlU4UiBPDAvvFiNN/BwHt6O/8aI = X-Google-Smtp-Source: AGHT+IGrdxd/u+FE6iafc/9gjlBKPk2NURp0uO2ROocOsm6mVDQw7uTpKwKLJFghH4KY9+sljDOvkQ== X-Received: by 2002:a50:8e18:0:b0:565:6e57:fa3d with SMTP id 24-20020a508e18000000b005656e57fa3dmr3915525edw.10.1710143905891; Mon, 11 Mar 2024 00:58:25 -0700 (PDT) Message-ID: <608aa381-a099-459e-96c3-1f05f29ed3c3@suse.com> Date: Mon, 11 Mar 2024 08:58:26 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Regression with xhci console Content-Language: en-US To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= Cc: xen-devel@lists.xenproject.org, Andrew Cooper , oxjo@proton.me, Roger Pau Monne References: <20240201170159.66330-1-roger.pau@citrix.com> <20240201170159.66330-2-roger.pau@citrix.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 11.03.2024 03:18, Marek Marczykowski-Górecki wrote: > On Thu, Feb 01, 2024 at 06:01:56PM +0100, Roger Pau Monne wrote: >> The current code that parses the IVMD blocks is relaxed with regard to the >> restriction that such unity regions should always fall into memory ranges >> marked as reserved in the memory map. >> >> However the type checks for the IVMD addresses are inverted, and as a result >> IVMD ranges falling into RAM areas are accepted. Note that having such ranges >> in the first place is a firmware bug, as IVMD should always fall into reserved >> ranges. >> >> Fixes: ed6c77ebf0c1 ('AMD/IOMMU: check / convert IVMD ranges for being / to be reserved') >> Signed-off-by: Roger Pau Monné > > FYI Xen 4.17.3 with this patch (but not others in the series) causes > panic on boot on Framework 14 AMD laptop: > > (XEN) [0000000044570000, 000000005077efff] (usable) > ... > (XEN) AMD-Vi: Warning: IVMD: [4f83f000,4f880000) is not (entirely) in reserved memory > (XEN) AMD-Vi: Error: IVMD: page at 4f83f000 can't be converted > ... > (XEN) Xen BUG at drivers/passthrough/amd/iommu_init.c:1386 > > Full boot log at https://github.com/QubesOS/qubes-issues/issues/9030 > 4.17.2 worked fine. > I'll try the whole series (and the follow up one), but I don't expect > any difference. > > This looks to be related to XHCI console, which does use the same API to > allow device to DMA into relevant buffers even when the rest of XHCI is > used by dom0 (or even other domain if 'share=yes' is used): > https://gitlab.com/xen-project/xen/-/blob/staging/xen/drivers/char/xhci-dbc.c?ref_type=heads#L1421-1424 Hmm, yes, this is what we get for allowing such (ab)use. I guess we need to have iommu_add_extra_reserved_device_memory() actually convert the region in question, to satisfy the later check. Care to make a patch? Jan From xen-devel-bounces@lists.xenproject.org Mon Mar 11 08:19:56 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 08:19:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691237.1076960 (Exim 4.92) (envelope-from ) id 1rjasw-0007tE-9D; Mon, 11 Mar 2024 08:19:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691237.1076960; Mon, 11 Mar 2024 08:19:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjasw-0007t7-6X; Mon, 11 Mar 2024 08:19:50 +0000 Received: by outflank-mailman (input) for mailman id 691237; Mon, 11 Mar 2024 08:19:49 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjasv-0007t1-1J for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 08:19:49 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 1eeb4061-df80-11ee-a1ee-f123f15fe8a2; Mon, 11 Mar 2024 09:19:46 +0100 (CET) Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) by support.bugseng.com (Postfix) with ESMTPA id 35DDC4EE0C90; Mon, 11 Mar 2024 09:19:46 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1eeb4061-df80-11ee-a1ee-f123f15fe8a2 MIME-Version: 1.0 Date: Mon, 11 Mar 2024 09:19:46 +0100 From: Nicola Vetrini To: Jan Beulich Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, consulting@bugseng.com, bertrand.marquis@arm.com, julien@xen.org, Andrew Cooper , George Dunlap , Wei Liu , xen-devel@lists.xenproject.org Subject: Re: [XEN PATCH v2 3/7] xen/list: address violations of MISRA C Rule 20.7 In-Reply-To: <0d3af110-773e-40bd-bd95-b385f49a7c47@suse.com> References: <0d3af110-773e-40bd-bd95-b385f49a7c47@suse.com> Message-ID: <1215e0e44cc061e34c7da143e82a32e1@bugseng.com> X-Sender: nicola.vetrini@bugseng.com Organization: BUGSENG s.r.l. Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 2024-03-11 08:48, Jan Beulich wrote: > On 08.03.2024 12:21, Nicola Vetrini wrote: >> --- a/xen/include/xen/list.h >> +++ b/xen/include/xen/list.h >> @@ -479,9 +479,9 @@ static inline void list_splice_init(struct >> list_head *list, >> * @n: another &struct list_head to use as temporary storage >> * @head: the head for your list. >> */ >> -#define list_for_each_backwards_safe(pos, n, head) \ >> - for ( pos = (head)->prev, n = pos->prev; pos != (head); \ >> - pos = n, n = pos->prev ) >> +#define list_for_each_backwards_safe(pos, n, head) \ >> + for ( (pos) = (head)->prev, n = (pos)->prev; (pos) != (head); \ >> + (pos) = n, n = (pos)->prev ) > > I think this is worse than before and incomplete: At least the rhs use > of n > also needs parenthesizing. Plus if pos is parenthesized even in lhs > instances, imo n ought to be, too. > You are right: this was simply an oversight. -- Nicola Vetrini, BSc Software Engineer, BUGSENG srl (https://bugseng.com) From xen-devel-bounces@lists.xenproject.org Mon Mar 11 08:40:05 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 08:40:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691242.1076969 (Exim 4.92) (envelope-from ) id 1rjbCK-0002RJ-RL; Mon, 11 Mar 2024 08:39:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691242.1076969; Mon, 11 Mar 2024 08:39:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjbCK-0002RC-Ou; Mon, 11 Mar 2024 08:39:52 +0000 Received: by outflank-mailman (input) for mailman id 691242; Mon, 11 Mar 2024 08:39:51 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjbCJ-0002R6-TZ for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 08:39:51 +0000 Received: from mail.actia.se (mail.actia.se [212.181.117.226]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id ec7f22f2-df82-11ee-afdc-a90da7624cb6; Mon, 11 Mar 2024 09:39:50 +0100 (CET) Received: from S036ANL.actianordic.se (10.12.31.117) by S035ANL.actianordic.se (10.12.31.116) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Mon, 11 Mar 2024 09:39:49 +0100 Received: from S036ANL.actianordic.se ([fe80::e13e:1feb:4ea6:ec69]) by S036ANL.actianordic.se ([fe80::e13e:1feb:4ea6:ec69%4]) with mapi id 15.01.2507.035; Mon, 11 Mar 2024 09:39:49 +0100 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ec7f22f2-df82-11ee-afdc-a90da7624cb6 From: John Ernberg To: Julien Grall , Peng Fan , "Stefano Stabellini" , Bertrand Marquis , Michal Orzel , "Volodymyr Babchuk" CC: Jonas Blixt , "xen-devel@lists.xenproject.org" Subject: Re: [PATCH 1/2] xen/arm: Add imx8q{m,x} platform glue Thread-Topic: [PATCH 1/2] xen/arm: Add imx8q{m,x} platform glue Thread-Index: AQHaVDuqVQ/kgxLZgUK/m8/hE0ez5bDzxxsAgAA1KwCAAVx5AIAAQjeAgAEdtQCAAyp5AIABm3uAgAZ8E4CAKNxDgIAApfwAgAKGQoCAAAbIgIAEXCQA Date: Mon, 11 Mar 2024 08:39:49 +0000 Message-ID: <7f49fd48-808b-4a05-98ee-3f53fd8574d5@actia.se> References: <20240131114952.305805-1-john.ernberg@actia.se> <20240131114952.305805-2-john.ernberg@actia.se> <494d4961-ad8a-4d1d-aaa6-d1bfb9d6a137@actia.se> <167f0c7a-e037-446c-82f8-2584e35a7af1@xen.org> <012b5f83-2f9b-4477-965e-07b8506c0052@xen.org> <5a0c8f09-4f01-45e9-892c-86342c0d0ec5@xen.org> <08ae764c-3490-4dd1-ab70-7a855a98d16d@actia.se> <911ec1bb-3733-4f37-839e-673a88e408ff@actia.se> <848794f3-a337-49d9-84db-a969970f071b@actia.se> <48038c7f-d7cd-4100-a41b-8042bcb93208@xen.org> In-Reply-To: <48038c7f-d7cd-4100-a41b-8042bcb93208@xen.org> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.12.12.30] x-esetresult: clean, is OK x-esetid: 37303A2921D72955627C62 Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 SGkgSnVsaWVuLA0KDQpPbiAzLzgvMjQgMTU6MDQsIEp1bGllbiBHcmFsbCB3cm90ZToNCj4gSGkg Sm9obiwNCj4gDQo+IFRoYW5rIHlvdSBmb3IgdGhlIHJlcGx5Lg0KPiANCj4gT24gMDgvMDMvMjAy NCAxMzo0MCwgSm9obiBFcm5iZXJnIHdyb3RlOg0KPj4gT24gMy83LzI0IDAwOjA3LCBKdWxpZW4g R3JhbGwgd3JvdGU6DQo+Pj4gwqAgPiBQaW5nIG9uIHRoZSB3YXRjaGRvZyBkaXNjdXNzaW9uIGJp dHMuDQo+Pj4NCj4+PiBTb3JyeSBmb3IgdGhlIGxhdGUgcmVwbHkuDQo+Pj4NCj4+PiBPbiAwNi8w My8yMDI0IDEzOjEzLCBKb2huIEVybmJlcmcgd3JvdGU6DQo+Pj4+IE9uIDIvOS8yNCAxNDoxNCwg Sm9obiBFcm5iZXJnIHdyb3RlOg0KPj4+Pj4NCj4+Pj4+PiDCoMKgwqDCoCAqIElNWF9TSVBfVElN RVJfKjrCoCBUaGlzIHNlZW1zIHRvIGJlIHJlbGF0ZWQgdG8gdGhlIHdhdGNoZG9nLg0KPj4+Pj4+ IFNob3VsZG4ndCBkb20wIHJlbHkgb24gdGhlIHdhdGNoZG9nIHByb3ZpZGVkIGJ5IFhlbiBpbnN0 ZWFkPyBTbyB0aG9zZQ0KPj4+Pj4+IGNhbGwgd2lsbCBiZSB1c2VkIGJ5IFhlbi4NCj4+Pj4+DQo+ Pj4+PiBUaGF0IGlzIGluZGVlZCBhIHdhdGNoZG9nIFNJUCwgYW5kIGFsc28gZm9yIHNldHRpbmcg dGhlIFNvQyANCj4+Pj4+IGludGVybmFsIFJUQw0KPj4+Pj4gaWYgaXQgaXMgYmVpbmcgdXNlZC4N Cj4+Pj4+DQo+Pj4+PiBJIGxvb2tlZCBhcm91bmQgaWYgdGhlcmUgd2FzIHByZXZpb3VzIGRpc2N1 c3Npb24gYW5kIG9ubHkgcmVhbGx5DQo+Pj4+PiBmb3VuZCBbM10uDQo+Pj4+PiBJcyB0aGUgeGVu L3hlbi9pbmNsdWRlL3dhdGNoZG9nLmggaGVhZGVyIG1lYW50IHRvIGJlIGZvciB0aGlzIGtpbmQg b2YNCj4+Pj4+IHdhdGNoZG9nIHN1cHBvcnQgb3IgaXMgdGhhdCBtb3JlIGZvciB0aGUgVk0gd2F0 Y2hkb2c/IExvb2tpbmcgYXQgDQo+Pj4+PiB0aGUgeDg2DQo+Pj4+PiBBQ1BJIE5NSSB3YXRjaGRv ZyBpdCBzZWVtcyBsaWtlIHRoZSBmb3JtZXIsIGJ1dCBJIGhhdmUgbmV2ZXIgd29ya2VkIA0KPj4+ Pj4gd2l0aA0KPj4+Pj4geDg2IG5vciBBQ1BJLg0KPj4+DQo+Pj4gaW5jbHVkZS93YXRjaGRvZy5o IGNvbnRhaW5zIGhlbHBlciB0byBjb25maWd1cmUgdGhlIHdhdGNoZG9nIGZvciBYZW4uIFdlDQo+ Pj4gYWxzbyBoYXZlIHBlci1WTSB3YXRjaGRvZyBhbmQgdGhpcyBpcyBjb25maWd1cmVkIGJ5IHRo ZSBoeXBlcmNhbGwNCj4+PiBTQ0hFRE9QX3dhdGNoZG9nLg0KPj4+DQo+Pj4+Pg0KPj4+Pj4gQ3Vy cmVudGx5IGZvcndhcmRpbmcgaXQgdG8gRG9tMCBoYXMgbm90IGNhdXNlZCBhbnkgd2F0Y2hkb2cg cmVzZXRzIA0KPj4+Pj4gd2l0aA0KPj4+Pj4gb3VyIHdhdGNoZG9nIHRpbWVvdXQgc2V0dGluZ3Ms IG91ciBzcGVjaWZpYyBEb20wIHNldHVwIGFuZCBWTSBjb3VudC4NCj4+Pg0KPj4+IElJVUMsIHRo ZSBTTUMgQVBJIGZvciB0aGUgd2F0Y2hkb2cgd291bGQgYmUgc2ltaWxhciB0byB0aGUgQUNQSSBO TUkNCj4+PiB3YXRjaGRvZy4gU28gSSB0aGluayBpdCB3b3VsZCBtYWtlIG1vcmUgc2Vuc2UgaWYg dGhpcyBpcyBub3QgZXhwb3NlZCB0bw0KPj4+IGRvbTAgKGV2ZW4gaWYgWGVuIGlzIGRvaW5nIG5v dGhpbmcgd2l0aCBpdCkuDQo+Pj4NCj4+PiBDYW4geW91IHRyeSB0byBoaWRlIHRoZSBTTUNzIGFu ZCBjaGVjayBpZiBkb20wIHN0aWxsIGJlaGF2ZSBwcm9wZXJseT8NCj4+Pg0KPj4+IENoZWVycywN Cj4+Pg0KPj4NCj4+IFRoaXMgU01DIG1hbmFnZXMgYSBoYXJkd2FyZSB3YXRjaGRvZywgaWYgaXQn cyBub3QgcGluZ2VkIHdpdGhpbiBhDQo+PiBzcGVjaWZpYyBpbnRlcnZhbCB0aGUgZW50aXJlIGJv YXJkIHJlc2V0cy4NCj4gDQo+IERvIHlvdSBrbm93IHdoYXQncyB0aGUgZGVmYXVsdCBpbnRlcnZh bD8gSXMgaXQgbGFyZ2UgZW5vdWdoIHNvIFhlbiArIA0KPiBkb20wIGNhbiBib290IChhdCBsZWFz dCB1cCB0byB3aGVuIHRoZSB3YXRjaGRvZyBkcml2ZXIgaXMgaW5pdGlhbGl6ZWQpPw0KPiANCj4+ DQo+PiBJZiBJIGJsb2NrIHRoZSBTTUNzIHRoZSB3YXRjaGRvZyBkcml2ZXIgaW4gRG9tMCB3aWxs IGZhaWwgdG8gcGluZyB0aGUNCj4+IHdhdGNoZG9nLCB0cmlnZ2VyaW5nIGEgYm9hcmQgcmVzZXQg YmVjYXVzZSB0aGUgc3lzdGVtIGxvb2tzIHRvIGhhdmUNCj4+IGJlY29tZSB1bnJlc3BvbnNpdmUu IFRoZSByZWFzb24gdGhpcyBwYXRjaCBzZXQgc3RhcnRlZCBpcyBiZWNhdXNlIHdlDQo+PiBjb3Vs ZG4ndCBwaW5nIHRoZSB3YXRjaGRvZyB3aGVuIHJ1bm5pbmcgd2l0aCBYZW4uDQo+Pg0KPj4gSW4g b3VyIHNwZWNpZmljIHN5c3RlbSB0aGUgYm9vdGxvYWRlciBlbmFibGVzIHRoZSB3YXRjaGRvZyBh cyBlYXJseSBhcw0KPj4gcG9zc2libGUgc28gdGhhdCB3ZSBjYW4gZ2V0IHdhdGNoZG9nIHByb3Rl Y3Rpb24gZm9yIGFzIG11Y2ggb2YgdGhlIGJvb3QNCj4+IGFzIHdlIHBvc3NpYmx5IGNhbi4NCj4+ DQo+PiBTbywgaWYgd2UgYXJlIHRvIGJsb2NrIHRoZSBTTUMgZnJvbSBEb20wLCB0aGVuIFhlbiBu ZWVkcyB0byB0YWtlIG92ZXINCj4+IHRoZSBwaW5naW5nLiBJdCBjb3VsZCBiZSBpbXBsZW1lbnRl ZCBzaW1pbGFybHkgdG8gdGhlIE5NSSB3YXRjaGRvZywNCj4+IGV4Y2VwdCB0aGF0IHRoZSBzeXN0 ZW0gd2lsbCByZXNldCBpZiB0aGUgcGluZyBpcyBtaXNzZWQgcmF0aGVyIHRoYW4NCj4+IGJhY2t0 cmFjZS4NCj4+IEl0IHdvdWxkIGFsc28gbWVhbiB0aGF0IFhlbiB3aWxsIGdldCBhIHdob2xlIHdh dGNoZG9nIGRyaXZlci1jYXRlZ29yeQ0KPj4gZHVlIHRvIHRoZSB3YXRjaGRvZyBiZWluZyB2ZW5k b3IgYW5kIHNvbWV0aW1lcyBldmVuIFNvQyBzcGVjaWZpYyB3aGVuIGl0DQo+PiBjb21lcyB0byBB cm0uDQo+Pg0KPj4gTXkgdW5kZXJzdGFuZGluZyBvZiB0aGUgZG9tYWluIHdhdGNoZG9nIGNvZGUg aXMgdGhhdCB0b2RheSB0aGUgZG9tYWluDQo+PiBuZWVkcyB0byBjYWxsIFNDSEVET1Bfd2F0Y2hk b2cgYXQgbGVhc3Qgb25jZSB0byBzdGFydCB0aGUgd2F0Y2hkb2cNCj4+IHRpbWVyLiBTaW5jZSB3 YXRjaGRvZyBwcm90ZWN0aW9uIHRocm91Z2ggdGhlIHdob2xlIGJvb3QgcHJvY2VzcyBpcw0KPj4g ZGVzaXJhYmxlIHdlJ2QgbmVlZCBzb21lIGNvcmUgY2hhbmdlcywgc3VjaCBhcyBhbiBvcHRpb24g dG8gc3RhcnQgdGhlDQo+PiBkb21haW4gd2F0Y2hkb2cgb24gaW5pdC4gPg0KPj4gSXQncyBxdWl0 ZSBhIGJpZyBjaGFuZ2UgdG8gbWFrZQ0KPiANCj4gRm9yIGNsYXJpZmljYXRpb24sIGFib3ZlIHlv dSBzZWVtIHRvIG1lbnRpb24gdHdvIGNoYW5nZXM6DQo+IA0KPiAgwqAxKSBBbGxvdyBYZW4gdG8g dXNlIHRoZSBIVyB3YXRjaGRvZw0KPiAgwqAyKSBBbGxvdyB0aGUgZG9tYWluIHRvIHVzZSB0aGUg d2F0Y2hkb2cgZWFybHkNCj4gDQo+IEkgYW0gYXNzdW1pbmcgYnkgYmlnIGNoYW5nZSwgeW91IGFy ZSByZWZlcnJpbmcgdG8gMj8NCg0KQm90aCBvZiB0aGVtLiBJJ20gZXhwZWN0aW5nIHRoZSBhZGRp dGlvbiBvZiBhIG5ldyBkcml2ZXIgY2F0ZWdvcnkgDQooaGFyZHdhcmUgd2F0Y2hkb2cpIHRvIGJl IGEgZGVjZW50IGFtb3VudCBvZiB3b3JrIGFzIHdlbGwuDQo+IA0KPiAsIHdoaWxlIEkgYW0gbm90 IGFnYWluc3QgZG9pbmcgaXQgaWYgaXQNCj4+IG1ha2VzIHNlbnNlLCBJIG5vdyB3b25kZXIgaWYg WGVuIHNob3VsZCBtYW5hZ2UgaGFyZHdhcmUgd2F0Y2hkb2dzLg0KPj4gTG9va2luZyBhdCB0aGUg ZG9tYWluIHdhdGNoZG9nIGNvZGUgaXQgbG9va3MgbGlrZSBpZiBhIGRvbWFpbiBkb2VzIG5vdA0K Pj4gZ2V0IGVub3VnaCBleGVjdXRpb24gdGltZSwgdGhlIHdhdGNoZG9nIHdpbGwgbm90IGJlIHBp bmdlZCBlbm91Z2ggYW5kDQo+PiB0aGUgZ3Vlc3Qgd2lsbCBiZSByZXNldC4gU28gZWl0aGVyIHdh dGNoZG9nIGFwcHJvYWNoIHJlcXVpcmVzIERvbTAgdG8NCj4+IGdldCBleGVjdXRpb24gdGltZS4g RG9tMCBhbHNvIG5lZWRzIHRvIHNlcnZpY2UgYWxsIHRoZSBQViBiYWNrZW5kcyBpdCdzDQo+PiBy ZXNwb25zaWJsZSBmb3IuIEknbSBub3Qgc3VyZSBpdCdzIHZhbHVhYmxlIHRvIGFkZCBhbm90aGVy IGxheWVyIG9mDQo+PiB3YXRjaGRvZyBmb3IgdGhpcyBzY2VuYXJpbyBhcyB0aGUgZW5kIHJlc3Vs dCAoY2hlY2tpbmcgdGhhdCB0aGUgZW50aXJlDQo+PiBzeXN0ZW0gd29ya3MpIGlzIGFjaGlldmVk IHdpdGhvdXQgaXQgYXMgd2VsbC4NCj4+DQo+PiBTbywgYmVmb3JlIEkgdHJ5IHRvIGZpbmQgdGhl IHRpbWUgdG8gbWFrZSBhIHByb3Bvc2FsIGZvciBtb3ZpbmcgdGhlDQo+PiBoYXJkd2FyZSB3YXRj aGRvZyBiaXQgdG8gWGVuLCBkbyB3ZSByZWFsbHkgd2FudCBpdD8NCj4gDQo+IFRoYW5rcyBmb3Ig dGhlIGRldGFpbHMuIEdpdmVuIHRoYXQgdGhlIHdhdGNoZG9nIGlzIGVuYWJsZWQgYnkgdGhlIA0K PiBib290bG9hZGVyLCBJIHRoaW5rIHdlIHdhbnQgWGVuIHRvIGRyaXZlIHRoZSB3YXRjaGRvZyBm b3IgdHdvIHJlYXNvbnM6DQo+ICDCoDEpIEluIHRydWUgZG9tMGxlc3MgZW52aXJvbm1lbnQsIGRv bTAgd291bGQgbm90IGV4aXN0DQo+ICDCoDIpIFlvdSBhcmUgcmVseWluZyBvbiBYZW4gKyBEb20w IHRvIGJvb3QgKG9yIGF0IGxlYXN0IGVub3VnaCB0byBnZXQgDQo+IHRoZSB3YXRjaGRvZyB3b3Jr aW5nKSB3aXRoaW4gdGhlIHdhdGNoZG9nIGludGVydmFsLg0KPiANCj4gTGV0IHNlZSB3aGF0IHRo ZSBvdGhlciBBcm0gbWFpbnRhaW5lciB0aGlua3MuDQo+IA0KDQpSZWdhcmRzIC8vIEpvaG4gRXJu YmVyZw== From xen-devel-bounces@lists.xenproject.org Mon Mar 11 09:00:17 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 09:00:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691261.1077042 (Exim 4.92) (envelope-from ) id 1rjbW2-0006xV-9C; Mon, 11 Mar 2024 09:00:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691261.1077042; Mon, 11 Mar 2024 09:00:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjbW2-0006xO-5g; Mon, 11 Mar 2024 09:00:14 +0000 Received: by outflank-mailman (input) for mailman id 691261; Mon, 11 Mar 2024 09:00:13 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjbW1-0006iu-9W for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 09:00:13 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id c5248ef2-df85-11ee-afdc-a90da7624cb6; Mon, 11 Mar 2024 10:00:12 +0100 (CET) Received: from beta.station (net-93-144-106-196.cust.vodafonedsl.it [93.144.106.196]) by support.bugseng.com (Postfix) with ESMTPSA id F11A14EE0C97; Mon, 11 Mar 2024 10:00:11 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c5248ef2-df85-11ee-afdc-a90da7624cb6 From: Simone Ballarin To: xen-devel@lists.xenproject.org Cc: consulting@bugseng.com, sstabellini@kernel.org, Simone Ballarin , Andrew Cooper , George Dunlap , Jan Beulich , Julien Grall , Wei Liu , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [XEN PATCH v3 03/16] misra: add deviations for direct inclusion guards Date: Mon, 11 Mar 2024 09:59:12 +0100 Message-Id: <1fdfec12fd2207c294f50d01d8ec32f890b915d7.1710145041.git.simone.ballarin@bugseng.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Add deviation comments to address violations of MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order to prevent the contents of a header file being included more than once"). Inclusion guards must appear at the beginning of the headers (comments are permitted anywhere). This patch adds deviation comments using the format specified in docs/misra/safe.json for headers with just the direct inclusion guard before the inclusion guard since they are safe and not supposed to comply with the directive. Signed-off-by: Simone Ballarin --- Changes in v3: - fix inconsistent deviation ID The patch has been introduced in v2. --- docs/misra/safe.json | 8 ++++++++ xen/arch/arm/include/asm/hypercall.h | 1 + xen/arch/x86/include/asm/hypercall.h | 1 + 3 files changed, 10 insertions(+) diff --git a/docs/misra/safe.json b/docs/misra/safe.json index d2489379a7..363c9e21b0 100644 --- a/docs/misra/safe.json +++ b/docs/misra/safe.json @@ -44,6 +44,14 @@ }, { "id": "SAF-5-safe", + "analyser": { + "eclair": "MC3R1.D4.10" + }, + "name": "Dir 4.10: direct inclusion guard before", + "text": "Headers with just the direct inclusion guard before the inclusion guard are safe." + }, + { + "id": "SAF-6-safe", "analyser": {}, "name": "Sentinel", "text": "Next ID to be used" diff --git a/xen/arch/arm/include/asm/hypercall.h b/xen/arch/arm/include/asm/hypercall.h index ccd26c5184..b754475cd0 100644 --- a/xen/arch/arm/include/asm/hypercall.h +++ b/xen/arch/arm/include/asm/hypercall.h @@ -1,3 +1,4 @@ +/* SAF-5-safe direct inclusion guard before */ #ifndef __XEN_HYPERCALL_H__ #error "asm/hypercall.h should not be included directly - include xen/hypercall.h instead" #endif diff --git a/xen/arch/x86/include/asm/hypercall.h b/xen/arch/x86/include/asm/hypercall.h index ec2edc771e..1a51ae02bf 100644 --- a/xen/arch/x86/include/asm/hypercall.h +++ b/xen/arch/x86/include/asm/hypercall.h @@ -2,6 +2,7 @@ * asm-x86/hypercall.h */ +/* SAF-5-safe direct inclusion guard before */ #ifndef __XEN_HYPERCALL_H__ #error "asm/hypercall.h should not be included directly - include xen/hypercall.h instead" #endif -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Mon Mar 11 09:00:17 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 09:00:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691262.1077047 (Exim 4.92) (envelope-from ) id 1rjbW2-00070S-Iu; Mon, 11 Mar 2024 09:00:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691262.1077047; Mon, 11 Mar 2024 09:00:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjbW2-0006zX-Cl; Mon, 11 Mar 2024 09:00:14 +0000 Received: by outflank-mailman (input) for mailman id 691262; Mon, 11 Mar 2024 09:00:13 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjbW1-0006j9-AA for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 09:00:13 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id c45e3e27-df85-11ee-a1ee-f123f15fe8a2; Mon, 11 Mar 2024 10:00:11 +0100 (CET) Received: from beta.station (net-93-144-106-196.cust.vodafonedsl.it [93.144.106.196]) by support.bugseng.com (Postfix) with ESMTPSA id B8C4D4EE0C96; Mon, 11 Mar 2024 10:00:10 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c45e3e27-df85-11ee-a1ee-f123f15fe8a2 From: Simone Ballarin To: xen-devel@lists.xenproject.org Cc: consulting@bugseng.com, sstabellini@kernel.org, Simone Ballarin , Andrew Cooper , George Dunlap , Jan Beulich , Julien Grall , Wei Liu , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [XEN PATCH v3 01/16] misra: add deviation for headers that explicitly avoid guards Date: Mon, 11 Mar 2024 09:59:10 +0100 Message-Id: <310fe4a0ccd0ad45bcf1cd9811ac56c9a560dd0b.1710145041.git.simone.ballarin@bugseng.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Some headers, under specific circumstances (documented in a comment at the beginning of the file), explicitly avoid inclusion guards: the caller is responsible for including them correctly. These files are not supposed to comply with Directive 4.10: "Precautions shall be taken in order to prevent the contents of a header file being included more than once" This patch adds deviation cooments for headers that avoid guards. Signed-off-by: Simone Ballarin --- Changes in v3: - fix inconsistent deviation ID - change comment-based deviation text Changes in v2: - use the format introduced with doc/misra/safe.json instead of a generic text-based deviation --- docs/misra/safe.json | 9 +++++++++ xen/include/public/arch-x86/cpufeatureset.h | 1 + xen/include/public/errno.h | 1 + 3 files changed, 11 insertions(+) diff --git a/docs/misra/safe.json b/docs/misra/safe.json index 952324f85c..e98956d604 100644 --- a/docs/misra/safe.json +++ b/docs/misra/safe.json @@ -28,6 +28,15 @@ }, { "id": "SAF-3-safe", + "analyser": { + "eclair": "MC3R1.D4.10" + }, + "name": "Dir 4.10: headers that leave it up to the caller to include them correctly", + "text": "Headers that deliberatively avoid inclusion guards explicitly leaving responsibility to the caller are allowed." + + }, + { + "id": "SAF-4-safe", "analyser": {}, "name": "Sentinel", "text": "Next ID to be used" diff --git a/xen/include/public/arch-x86/cpufeatureset.h b/xen/include/public/arch-x86/cpufeatureset.h index 0374cec3a2..f78a461d93 100644 --- a/xen/include/public/arch-x86/cpufeatureset.h +++ b/xen/include/public/arch-x86/cpufeatureset.h @@ -23,6 +23,7 @@ * their XEN_CPUFEATURE() being appropriate in the included context. */ +/* SAF-3-safe omitted inclusion guard */ #ifndef XEN_CPUFEATURE /* diff --git a/xen/include/public/errno.h b/xen/include/public/errno.h index 5a78a7607c..28e064b67f 100644 --- a/xen/include/public/errno.h +++ b/xen/include/public/errno.h @@ -17,6 +17,7 @@ * will unilaterally #undef XEN_ERRNO(). */ +/* SAF-3-safe omitted inclusion guard */ #ifndef XEN_ERRNO /* -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Mon Mar 11 09:00:17 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 09:00:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691260.1077031 (Exim 4.92) (envelope-from ) id 1rjbW1-0006j7-2K; Mon, 11 Mar 2024 09:00:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691260.1077031; Mon, 11 Mar 2024 09:00:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjbW0-0006j0-Vr; Mon, 11 Mar 2024 09:00:12 +0000 Received: by outflank-mailman (input) for mailman id 691260; Mon, 11 Mar 2024 09:00:12 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjbW0-0006iu-Ip for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 09:00:12 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id c42047f1-df85-11ee-afdc-a90da7624cb6; Mon, 11 Mar 2024 10:00:11 +0100 (CET) Received: from beta.station (net-93-144-106-196.cust.vodafonedsl.it [93.144.106.196]) by support.bugseng.com (Postfix) with ESMTPSA id E48FD4EE0C90; Mon, 11 Mar 2024 10:00:09 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c42047f1-df85-11ee-afdc-a90da7624cb6 From: Simone Ballarin To: xen-devel@lists.xenproject.org Cc: consulting@bugseng.com, sstabellini@kernel.org, Simone Ballarin , Andrew Cooper , George Dunlap , Jan Beulich , Julien Grall , Wei Liu , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Doug Goldstein , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [XEN PATCH v3 00/16] xen: address violation of MISRA C:2012 Directive 4.10 Date: Mon, 11 Mar 2024 09:59:09 +0100 Message-Id: X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit The Xen sources contain violations of MISRA C:2012 Directive 4.10 whose headline states: "Precautions shall be taken in order to prevent the contents of a header file being included more than once". As stated in v2, the following naming convention has been estabilished: - arch/.../include/asm/ headers -> ASM__H - private headers ->

__H - asm-generic headers -> ASM_GENERIC__H Since there would have been conflicting guards between architectures (which is a violation of the directive), there has been a need for ASM headers to specify if the inclusion guard referred to ARM or X86. Hence it has been decided to adopt instead: - arch//include/asm//.h -> ASM____H The subdir used is the smallest possible to avoid collisions. For example, it has been observed that in "xen/arch/arm/include/asm/arm32" and "xen/arch/arm/include/asm/arm64" there are plenty of header files with the same name, hence _ARMxx_ was added as subdirectory. There has been a need to define a standard for generated headers too: - include/generated//.h-> GENERATED___H - arch//include/generated/asm/.h-> _GENERATED_ASM__H To summarize, here are all the rules that have been applied: - private headers -> __H - asm-generic headers -> ASM_GENERIC__H - arch//include/asm//.h -> ASM____H - include/generated//.h-> GENERATED___H - arch//include/generated/asm/.h-> _GENERATED_ASM__H Links to the discussions: https://lists.xenproject.org/archives/html/xen-devel/2023-09/msg01928.html https://lists.xenproject.org/archives/html/xen-devel/2023-10/msg01784.html https://lists.xenproject.org/archives/html/xen-devel/2023-10/msg02073.html Changes in v3: Add/amend inclusion guards to address violations of the Directive and the new naming convention. Remove trailing underscores. Modify creation rule for asm-offsets.h to conform to the new standard and to not generate conflicting guards between architectures (which is a violation of the Directive). Maria Celeste Cesario (6): xen/arm: address violations of MISRA C:2012 Directive 4.10 xen: address violations of MISRA C:2012 Directive 4.10 xen: add deviations for MISRA C.2012 Directive 4.10 xen/x86: address violations of MISRA C:2012 Directive 4.10 x86/mtrr: address violations of MISRA C:2012 Directive 4.10 xen/lz4: address violations of MISRA C:2012 Directive 4.10 Simone Ballarin (10): misra: add deviation for headers that explicitly avoid guards misra: modify deviations for empty and generated headers misra: add deviations for direct inclusion guards xen/arm: address violations of MISRA C:2012 Directive 4.10 xen/x86: address violations of MISRA C:2012 Directive 4.10 x86/EFI: address violations of MISRA C:2012 Directive 4.10 xen/common: address violations of MISRA C:2012 Directive 4.10 xen/efi: address violations of MISRA C:2012 Directive 4.10 xen: address violations of MISRA C:2012 Directive 4.10 x86/asm: address violations of MISRA C:2012 Directive 4.10 .../eclair_analysis/ECLAIR/deviations.ecl | 12 +++--- docs/misra/deviations.rst | 7 ++++ docs/misra/safe.json | 40 +++++++++++++++++++ xen/arch/arm/efi/efi-boot.h | 6 +++ xen/arch/arm/efi/runtime.h | 1 + xen/arch/arm/include/asm/domain.h | 6 +-- xen/arch/arm/include/asm/efibind.h | 5 +++ xen/arch/arm/include/asm/event.h | 6 +-- xen/arch/arm/include/asm/grant_table.h | 6 +-- xen/arch/arm/include/asm/hypercall.h | 1 + xen/arch/arm/include/asm/io.h | 6 +-- xen/arch/arm/include/asm/irq.h | 6 +-- xen/arch/arm/include/asm/smp.h | 6 +-- xen/arch/arm/include/asm/spinlock.h | 6 +-- xen/arch/arm/include/asm/system.h | 6 +-- xen/arch/x86/Makefile | 10 +++-- xen/arch/x86/cpu/cpu.h | 5 +++ xen/arch/x86/cpu/mtrr/mtrr.h | 4 ++ xen/arch/x86/efi/efi-boot.h | 7 ++++ xen/arch/x86/efi/runtime.h | 5 +++ xen/arch/x86/include/asm/compat.h | 5 +++ xen/arch/x86/include/asm/cpufeatures.h | 5 +-- xen/arch/x86/include/asm/domain.h | 6 +-- xen/arch/x86/include/asm/efibind.h | 5 +++ xen/arch/x86/include/asm/event.h | 6 +-- xen/arch/x86/include/asm/grant_table.h | 6 +-- xen/arch/x86/include/asm/hypercall.h | 1 + xen/arch/x86/include/asm/io.h | 6 +-- xen/arch/x86/include/asm/irq.h | 6 +-- xen/arch/x86/include/asm/smp.h | 6 +-- xen/arch/x86/include/asm/spinlock.h | 6 +-- xen/arch/x86/include/asm/system.h | 6 +-- xen/arch/x86/x86_64/mmconfig.h | 5 +++ xen/arch/x86/x86_emulate/private.h | 5 +++ xen/build.mk | 6 ++- xen/common/decompress.h | 5 +++ xen/common/efi/efi.h | 5 +++ xen/common/event_channel.h | 5 +++ xen/common/lz4/defs.h | 5 +++ xen/include/Makefile | 12 ++++-- xen/include/public/arch-x86/cpufeatureset.h | 1 + xen/include/public/arch-x86/xen.h | 1 + xen/include/public/errno.h | 1 + xen/include/xen/err.h | 8 ++-- xen/include/xen/pci_ids.h | 5 +++ xen/include/xen/softirq.h | 8 ++-- xen/include/xen/vmap.h | 8 ++-- xen/scripts/Makefile.asm-generic | 16 +++++++- 48 files changed, 233 insertions(+), 78 deletions(-) -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Mon Mar 11 09:00:17 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 09:00:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691265.1077073 (Exim 4.92) (envelope-from ) id 1rjbW4-0007dE-Ji; Mon, 11 Mar 2024 09:00:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691265.1077073; Mon, 11 Mar 2024 09:00:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjbW4-0007aH-EZ; Mon, 11 Mar 2024 09:00:16 +0000 Received: by outflank-mailman (input) for mailman id 691265; Mon, 11 Mar 2024 09:00:15 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjbW3-0006iu-8G for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 09:00:15 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id c5c13633-df85-11ee-afdc-a90da7624cb6; Mon, 11 Mar 2024 10:00:13 +0100 (CET) Received: from beta.station (net-93-144-106-196.cust.vodafonedsl.it [93.144.106.196]) by support.bugseng.com (Postfix) with ESMTPSA id 2A4544EE0C9C; Mon, 11 Mar 2024 10:00:13 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c5c13633-df85-11ee-afdc-a90da7624cb6 From: Simone Ballarin To: xen-devel@lists.xenproject.org Cc: consulting@bugseng.com, sstabellini@kernel.org, Simone Ballarin , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Wei Liu , Maria Celeste Cesario Subject: [XEN PATCH v3 05/16] xen/x86: address violations of MISRA C:2012 Directive 4.10 Date: Mon, 11 Mar 2024 09:59:14 +0100 Message-Id: X-Mailer: git-send-email 2.34.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Add or move inclusion guards to address violations of MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order to prevent the contents of a header file being included more than once"). Inclusion guards must appear at the beginning of the headers (comments are permitted anywhere). Mechanical change. Signed-off-by: Simone Ballarin Signed-off-by: Maria Celeste Cesario --- Changes in v3: - remove trailing underscores - change inclusion guard name to adhere to the new standard Changes in v2: - remove extra blanks - drop changes in C files Note: Changes in Makefile were not strictly necessary in v1 and a maintainer asked to remove them since there was a deviation for generated headers. Starting from v2, they are required since the deviation has been removed by another patch of this series. --- xen/arch/x86/Makefile | 10 ++++++---- xen/arch/x86/cpu/cpu.h | 5 +++++ xen/arch/x86/x86_64/mmconfig.h | 5 +++++ xen/arch/x86/x86_emulate/private.h | 5 +++++ 4 files changed, 21 insertions(+), 4 deletions(-) diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile index 26d8740529..4548cdc53d 100644 --- a/xen/arch/x86/Makefile +++ b/xen/arch/x86/Makefile @@ -258,18 +258,20 @@ $(obj)/asm-macros.i: CFLAGS-y += -P $(objtree)/arch/x86/include/asm/asm-macros.h: $(obj)/asm-macros.i $(src)/Makefile $(call filechk,asm-macros.h) +ARCHDIR = $(shell echo $(SRCARCH) | tr a-z A-Z) + define filechk_asm-macros.h + echo '#ifndef ASM_$(ARCHDIR)_ASM_MACROS_H'; \ + echo '#define ASM_$(ARCHDIR)_ASM_MACROS_H'; \ echo '#if 0'; \ echo '.if 0'; \ echo '#endif'; \ - echo '#ifndef __ASM_MACROS_H__'; \ - echo '#define __ASM_MACROS_H__'; \ echo 'asm ( ".include \"$@\"" );'; \ - echo '#endif /* __ASM_MACROS_H__ */'; \ echo '#if 0'; \ echo '.endif'; \ cat $<; \ - echo '#endif' + echo '#endif'; \ + echo '#endif /* ASM_$(ARCHDIR)_ASM_MACROS_H */' endef $(obj)/efi.lds: AFLAGS-y += -DEFI diff --git a/xen/arch/x86/cpu/cpu.h b/xen/arch/x86/cpu/cpu.h index e3d06278b3..b763cdf3da 100644 --- a/xen/arch/x86/cpu/cpu.h +++ b/xen/arch/x86/cpu/cpu.h @@ -1,3 +1,6 @@ +#ifndef XEN_ARCH_X86_CPU_CPU_H +#define XEN_ARCH_X86_CPU_CPU_H + /* attempt to consolidate cpu attributes */ struct cpu_dev { void (*c_early_init)(struct cpuinfo_x86 *c); @@ -24,3 +27,5 @@ void amd_init_lfence(struct cpuinfo_x86 *c); void amd_init_ssbd(const struct cpuinfo_x86 *c); void amd_init_spectral_chicken(void); void detect_zen2_null_seg_behaviour(void); + +#endif /* XEN_ARCH_X86_CPU_CPU_H */ diff --git a/xen/arch/x86/x86_64/mmconfig.h b/xen/arch/x86/x86_64/mmconfig.h index 3da4b21e9b..c8e67a67db 100644 --- a/xen/arch/x86/x86_64/mmconfig.h +++ b/xen/arch/x86/x86_64/mmconfig.h @@ -5,6 +5,9 @@ * Author: Allen Kay - adapted from linux */ +#ifndef XEN_ARCH_X86_X86_64_MMCONFIG_H +#define XEN_ARCH_X86_X86_64_MMCONFIG_H + #define PCI_DEVICE_ID_INTEL_E7520_MCH 0x3590 #define PCI_DEVICE_ID_INTEL_82945G_HB 0x2770 @@ -72,3 +75,5 @@ int pci_mmcfg_reserved(uint64_t address, unsigned int segment, int pci_mmcfg_arch_init(void); int pci_mmcfg_arch_enable(unsigned int idx); void pci_mmcfg_arch_disable(unsigned int idx); + +#endif /* XEN_ARCH_X86_X86_64_MMCONFIG_H */ diff --git a/xen/arch/x86/x86_emulate/private.h b/xen/arch/x86/x86_emulate/private.h index 0fa26ba00a..835161cb53 100644 --- a/xen/arch/x86/x86_emulate/private.h +++ b/xen/arch/x86/x86_emulate/private.h @@ -6,6 +6,9 @@ * Copyright (c) 2005-2007 XenSource Inc. */ +#ifndef XEN_ARCH_X86_X86_EMULATE_PRIVATE_H +#define XEN_ARCH_X86_X86_EMULATE_PRIVATE_H + #ifdef __XEN__ # include @@ -836,3 +839,5 @@ static inline int read_ulong(enum x86_segment seg, *val = 0; return ops->read(seg, offset, val, bytes, ctxt); } + +#endif /* XEN_ARCH_X86_X86_EMULATE_PRIVATE_H */ -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Mon Mar 11 09:00:17 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 09:00:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691264.1077067 (Exim 4.92) (envelope-from ) id 1rjbW4-0007T9-2i; Mon, 11 Mar 2024 09:00:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691264.1077067; Mon, 11 Mar 2024 09:00:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjbW3-0007SC-T7; Mon, 11 Mar 2024 09:00:15 +0000 Received: by outflank-mailman (input) for mailman id 691264; Mon, 11 Mar 2024 09:00:14 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjbW2-0006iu-83 for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 09:00:14 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id c5755589-df85-11ee-afdc-a90da7624cb6; Mon, 11 Mar 2024 10:00:13 +0100 (CET) Received: from beta.station (net-93-144-106-196.cust.vodafonedsl.it [93.144.106.196]) by support.bugseng.com (Postfix) with ESMTPSA id A07264EE0C99; Mon, 11 Mar 2024 10:00:12 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c5755589-df85-11ee-afdc-a90da7624cb6 From: Simone Ballarin To: xen-devel@lists.xenproject.org Cc: consulting@bugseng.com, sstabellini@kernel.org, Simone Ballarin , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Maria Celeste Cesario Subject: [XEN PATCH v3 04/16] xen/arm: address violations of MISRA C:2012 Directive 4.10 Date: Mon, 11 Mar 2024 09:59:13 +0100 Message-Id: <868ede5a23489e018e272188edfbee572d1ad393.1710145041.git.simone.ballarin@bugseng.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Add inclusion guard to address violations of MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order to prevent the contents of a header file being included more than once"). Mechanical change. Signed-off-by: Simone Ballarin Signed-off-by: Maria Celeste Cesario --- Changes in v3: - remove trailing underscores - change inclusion guard name to adhere to the new standard Changes in v2: - drop changes in xen/arch/arm/include/asm/hypercall.h - drop changes in xen/arch/arm/include/asm/iocap.h since they are not related with the directive --- xen/arch/arm/efi/efi-boot.h | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/xen/arch/arm/efi/efi-boot.h b/xen/arch/arm/efi/efi-boot.h index 0cb29f90a0..580859fecd 100644 --- a/xen/arch/arm/efi/efi-boot.h +++ b/xen/arch/arm/efi/efi-boot.h @@ -3,6 +3,10 @@ * is intended to be included by common/efi/boot.c _only_, and * therefore can define arch specific global variables. */ + +#ifndef XEN_ARCH_ARM_EFI_EFI_BOOT_H +#define XEN_ARCH_ARM_EFI_EFI_BOOT_H + #include #include #include @@ -992,6 +996,8 @@ static void __init efi_arch_flush_dcache_area(const void *vaddr, UINTN size) __flush_dcache_area(vaddr, size); } +#endif /* XEN_ARCH_ARM_EFI_EFI_BOOT_H */ + /* * Local variables: * mode: C -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Mon Mar 11 09:00:17 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 09:00:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691266.1077082 (Exim 4.92) (envelope-from ) id 1rjbW5-0007j6-8j; Mon, 11 Mar 2024 09:00:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691266.1077082; Mon, 11 Mar 2024 09:00:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjbW4-0007hC-Pw; Mon, 11 Mar 2024 09:00:16 +0000 Received: by outflank-mailman (input) for mailman id 691266; Mon, 11 Mar 2024 09:00:15 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjbW3-0006j9-QO for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 09:00:15 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id c616516b-df85-11ee-a1ee-f123f15fe8a2; Mon, 11 Mar 2024 10:00:14 +0100 (CET) Received: from beta.station (net-93-144-106-196.cust.vodafonedsl.it [93.144.106.196]) by support.bugseng.com (Postfix) with ESMTPSA id AC1DE4EE0C9F; Mon, 11 Mar 2024 10:00:13 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c616516b-df85-11ee-a1ee-f123f15fe8a2 From: Simone Ballarin To: xen-devel@lists.xenproject.org Cc: consulting@bugseng.com, sstabellini@kernel.org, Simone Ballarin , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Wei Liu , Maria Celeste Cesario Subject: [XEN PATCH v3 06/16] x86/EFI: address violations of MISRA C:2012 Directive 4.10 Date: Mon, 11 Mar 2024 09:59:15 +0100 Message-Id: X-Mailer: git-send-email 2.34.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Add inclusion guard to address violations of MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order to prevent the contents of a header file being included more than once"). Mechanical change. Signed-off-by: Simone Ballarin Signed-off-by: Maria Celeste Cesario --- Changes in v3: - remove trailing underscores - change inclusion guard name to adhere to the new standard --- xen/arch/x86/efi/efi-boot.h | 7 +++++++ xen/arch/x86/efi/runtime.h | 5 +++++ 2 files changed, 12 insertions(+) diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h index 8ea64e31cd..df6eaa9e9e 100644 --- a/xen/arch/x86/efi/efi-boot.h +++ b/xen/arch/x86/efi/efi-boot.h @@ -3,6 +3,11 @@ * is intended to be included by common/efi/boot.c _only_, and * therefore can define arch specific global variables. */ + +#ifndef XEN_ARCH_X86_EFI_EFI_BOOT_H +#define XEN_ARCH_X86_EFI_EFI_BOOT_H + + #include #include #include @@ -905,6 +910,8 @@ void asmlinkage __init efi_multiboot2(EFI_HANDLE ImageHandle, efi_exit_boot(ImageHandle, SystemTable); } +#endif /* XEN_ARCH_X86_EFI_EFI_BOOT_H */ + /* * Local variables: * mode: C diff --git a/xen/arch/x86/efi/runtime.h b/xen/arch/x86/efi/runtime.h index 77866c5f21..13d4ba66b6 100644 --- a/xen/arch/x86/efi/runtime.h +++ b/xen/arch/x86/efi/runtime.h @@ -1,3 +1,6 @@ +#ifndef XEN_ARCH_X86_EFI_RUNTIME_H +#define XEN_ARCH_X86_EFI_RUNTIME_H + #include #include #include @@ -17,3 +20,5 @@ void efi_update_l4_pgtable(unsigned int l4idx, l4_pgentry_t l4e) } } #endif + +#endif /* XEN_ARCH_X86_EFI_RUNTIME_H */ -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Mon Mar 11 09:00:17 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 09:00:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691263.1077062 (Exim 4.92) (envelope-from ) id 1rjbW3-0007QX-Pf; Mon, 11 Mar 2024 09:00:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691263.1077062; Mon, 11 Mar 2024 09:00:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjbW3-0007QK-Kv; Mon, 11 Mar 2024 09:00:15 +0000 Received: by outflank-mailman (input) for mailman id 691263; Mon, 11 Mar 2024 09:00:14 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjbW2-0006j9-0I for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 09:00:14 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id c4c1e773-df85-11ee-a1ee-f123f15fe8a2; Mon, 11 Mar 2024 10:00:12 +0100 (CET) Received: from beta.station (net-93-144-106-196.cust.vodafonedsl.it [93.144.106.196]) by support.bugseng.com (Postfix) with ESMTPSA id 4BD344EE0C98; Mon, 11 Mar 2024 10:00:11 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c4c1e773-df85-11ee-a1ee-f123f15fe8a2 From: Simone Ballarin To: xen-devel@lists.xenproject.org Cc: consulting@bugseng.com, sstabellini@kernel.org, Simone Ballarin , Doug Goldstein , Andrew Cooper , George Dunlap , Jan Beulich , Julien Grall , Wei Liu , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [XEN PATCH v3 02/16] misra: modify deviations for empty and generated headers Date: Mon, 11 Mar 2024 09:59:11 +0100 Message-Id: <8a491f641a8931b6ccc91fca1da6cdfa090c5b36.1710145041.git.simone.ballarin@bugseng.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit This patch modifies deviations for Directive 4.10: "Precautions shall be taken in order to prevent the contents of a header file being included more than once" This patch avoids the file-based deviation for empty headers, and replaces it with a comment-based one using the format specified in docs/misra/safe.json. Generated headers are not generally safe against multi-inclusions, whether a header is safe depends on the nature of the generated code in the header. For that reason, this patch drops the deviation for generated headers. Signed-off-by: Simone Ballarin --- Changes in v2: - use the format introduced with doc/misra/safe.json instead of a file-based deviation for empty headers - remove deviation for generated headers The reason of moving the comment-based deviation in "runtime.h" is that it should appear immediatly before the violation and, for files with no tokens, the location is the the last line of the file. --- automation/eclair_analysis/ECLAIR/deviations.ecl | 7 ------- docs/misra/safe.json | 13 ++++++++++--- xen/arch/arm/efi/runtime.h | 1 + xen/include/Makefile | 2 +- 4 files changed, 12 insertions(+), 11 deletions(-) diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl index 9ac3ee4dfd..039ffaf52a 100644 --- a/automation/eclair_analysis/ECLAIR/deviations.ecl +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl @@ -63,13 +63,6 @@ they are not instances of commented-out code." -config=MC3R1.D4.3,reports+={disapplied,"!(any_area(any_loc(file(^xen/arch/arm/arm64/.*$))))"} -doc_end --doc_begin="This header file is autogenerated or empty, therefore it poses no -risk if included more than once." --file_tag+={empty_header, "^xen/arch/arm/efi/runtime\\.h$"} --file_tag+={autogen_headers, "^xen/include/xen/compile\\.h$||^xen/include/generated/autoconf.h$||^xen/include/xen/hypercall-defs.h$"} --config=MC3R1.D4.10,reports+={safe, "all_area(all_loc(file(empty_header||autogen_headers)))"} --doc_end - -doc_begin="Files that are intended to be included more than once do not need to conform to the directive." -config=MC3R1.D4.10,reports+={safe, "first_area(text(^/\\* This file is legitimately included multiple times\\. \\*/$, begin-4))"} diff --git a/docs/misra/safe.json b/docs/misra/safe.json index e98956d604..d2489379a7 100644 --- a/docs/misra/safe.json +++ b/docs/misra/safe.json @@ -33,10 +33,17 @@ }, "name": "Dir 4.10: headers that leave it up to the caller to include them correctly", "text": "Headers that deliberatively avoid inclusion guards explicitly leaving responsibility to the caller are allowed." - - }, - { + }, + { "id": "SAF-4-safe", + "analyser": { + "eclair": "MC3R1.D4.10" + }, + "name": "Dir 4.10: empty headers", + "text": "Empty headers pose no risk if included more than once." + }, + { + "id": "SAF-5-safe", "analyser": {}, "name": "Sentinel", "text": "Next ID to be used" diff --git a/xen/arch/arm/efi/runtime.h b/xen/arch/arm/efi/runtime.h index 25afcebed1..732bf4a18c 100644 --- a/xen/arch/arm/efi/runtime.h +++ b/xen/arch/arm/efi/runtime.h @@ -1 +1,2 @@ /* Placeholder for ARM-specific runtime include/declarations */ +/* SAF-4-safe empty header */ diff --git a/xen/include/Makefile b/xen/include/Makefile index 2e61b50139..a77c9ffb7e 100644 --- a/xen/include/Makefile +++ b/xen/include/Makefile @@ -53,7 +53,7 @@ cmd_compat_h = \ mv -f $@.new $@ quiet_cmd_stub_h = GEN $@ -cmd_stub_h = echo '/* empty */' >$@ +cmd_stub_h = echo '/* SAF-4-safe empty header */' >$@ quiet_cmd_compat_i = CPP $@ cmd_compat_i = $(CPP) $(filter-out -Wa$(comma)% -include %/include/xen/config.h,$(XEN_CFLAGS)) $(cppflags-y) -o $@ $< -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Mon Mar 11 09:00:18 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 09:00:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691267.1077092 (Exim 4.92) (envelope-from ) id 1rjbW6-00084Q-EW; Mon, 11 Mar 2024 09:00:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691267.1077092; Mon, 11 Mar 2024 09:00:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjbW6-00082p-4l; Mon, 11 Mar 2024 09:00:18 +0000 Received: by outflank-mailman (input) for mailman id 691267; Mon, 11 Mar 2024 09:00:16 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjbW4-0006iu-8Y for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 09:00:16 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id c6687e97-df85-11ee-afdc-a90da7624cb6; Mon, 11 Mar 2024 10:00:14 +0100 (CET) Received: from beta.station (net-93-144-106-196.cust.vodafonedsl.it [93.144.106.196]) by support.bugseng.com (Postfix) with ESMTPSA id 37EFA4EE0C9B; Mon, 11 Mar 2024 10:00:14 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c6687e97-df85-11ee-afdc-a90da7624cb6 From: Simone Ballarin To: xen-devel@lists.xenproject.org Cc: consulting@bugseng.com, sstabellini@kernel.org, Simone Ballarin , Andrew Cooper , George Dunlap , Jan Beulich , Julien Grall , Wei Liu , Maria Celeste Cesario Subject: [XEN PATCH v3 07/16] xen/common: address violations of MISRA C:2012 Directive 4.10 Date: Mon, 11 Mar 2024 09:59:16 +0100 Message-Id: X-Mailer: git-send-email 2.34.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Add inclusion guards to address violations of MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order to prevent the contents of a header file being included more than once"). Mechanical change. Signed-off-by: Simone Ballarin Signed-off-by: Maria Celeste Cesario --- Changes in v3: - remove trailing underscores - change inclusion guard name to adhere to the new standard Changes in v2: - drop changes in C files --- xen/common/decompress.h | 5 +++++ xen/common/event_channel.h | 5 +++++ 2 files changed, 10 insertions(+) diff --git a/xen/common/decompress.h b/xen/common/decompress.h index e8195b353a..41848274ab 100644 --- a/xen/common/decompress.h +++ b/xen/common/decompress.h @@ -1,3 +1,6 @@ +#ifndef XEN_COMMON_DECOMPRESS_H +#define XEN_COMMON_DECOMPRESS_H + #ifdef __XEN__ #include @@ -23,3 +26,5 @@ #define large_free free #endif + +#endif /* XEN_COMMON_DECOMPRESS_H */ diff --git a/xen/common/event_channel.h b/xen/common/event_channel.h index 45219ca67c..a23e39a713 100644 --- a/xen/common/event_channel.h +++ b/xen/common/event_channel.h @@ -1,5 +1,8 @@ /* Event channel handling private header. */ +#ifndef XEN_COMMON_EVENT_CHANNEL_H +#define XEN_COMMON_EVENT_CHANNEL_H + #include static inline unsigned int max_evtchns(const struct domain *d) @@ -52,6 +55,8 @@ int evtchn_fifo_init_control(struct evtchn_init_control *init_control); int evtchn_fifo_expand_array(const struct evtchn_expand_array *expand_array); void evtchn_fifo_destroy(struct domain *d); +#endif /* XEN_COMMON_EVENT_CHANNEL_H */ + /* * Local variables: * mode: C -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Mon Mar 11 09:00:19 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 09:00:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691268.1077096 (Exim 4.92) (envelope-from ) id 1rjbW7-0008Db-1w; Mon, 11 Mar 2024 09:00:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691268.1077096; Mon, 11 Mar 2024 09:00:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjbW6-0008Ad-Po; Mon, 11 Mar 2024 09:00:18 +0000 Received: by outflank-mailman (input) for mailman id 691268; Mon, 11 Mar 2024 09:00:17 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjbW4-0006j9-Q4 for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 09:00:16 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id c6a8ece6-df85-11ee-a1ee-f123f15fe8a2; Mon, 11 Mar 2024 10:00:15 +0100 (CET) Received: from beta.station (net-93-144-106-196.cust.vodafonedsl.it [93.144.106.196]) by support.bugseng.com (Postfix) with ESMTPSA id BECF04EE0CA0; Mon, 11 Mar 2024 10:00:14 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c6a8ece6-df85-11ee-a1ee-f123f15fe8a2 From: Simone Ballarin To: xen-devel@lists.xenproject.org Cc: consulting@bugseng.com, sstabellini@kernel.org, Simone Ballarin , Jan Beulich , Maria Celeste Cesario Subject: [XEN PATCH v3 08/16] xen/efi: address violations of MISRA C:2012 Directive 4.10 Date: Mon, 11 Mar 2024 09:59:17 +0100 Message-Id: X-Mailer: git-send-email 2.34.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Add inclusion guards to address violations of MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order to prevent the contents of a header file being included more than once"). Mechanical change. Signed-off-by: Simone Ballarin Signed-off-by: Maria Celeste Cesario --- Changes in v3: - remove trailing underscores - change inclusion guard name to adhere to the new standard Changes in v2: - drop changes in C files --- xen/common/efi/efi.h | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/xen/common/efi/efi.h b/xen/common/efi/efi.h index c02fbb7b69..ab604ebd59 100644 --- a/xen/common/efi/efi.h +++ b/xen/common/efi/efi.h @@ -1,3 +1,6 @@ +#ifndef XEN_COMMON_EFI_EFI_H +#define XEN_COMMON_EFI_EFI_H + #include #include #include @@ -51,3 +54,5 @@ void free_ebmalloc_unused_mem(void); const void *pe_find_section(const void *image, const UINTN image_size, const CHAR16 *section_name, UINTN *size_out); + +#endif /* XEN_COMMON_EFI_EFI_H */ -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Mon Mar 11 09:00:20 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 09:00:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691269.1077106 (Exim 4.92) (envelope-from ) id 1rjbW7-0008LK-Sb; Mon, 11 Mar 2024 09:00:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691269.1077106; Mon, 11 Mar 2024 09:00:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjbW7-0008Ia-Gr; Mon, 11 Mar 2024 09:00:19 +0000 Received: by outflank-mailman (input) for mailman id 691269; Mon, 11 Mar 2024 09:00:17 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjbW5-0006j9-D7 for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 09:00:17 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id c6fdbf60-df85-11ee-a1ee-f123f15fe8a2; Mon, 11 Mar 2024 10:00:15 +0100 (CET) Received: from beta.station (net-93-144-106-196.cust.vodafonedsl.it [93.144.106.196]) by support.bugseng.com (Postfix) with ESMTPSA id 2D0764EE0CA3; Mon, 11 Mar 2024 10:00:15 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c6fdbf60-df85-11ee-a1ee-f123f15fe8a2 From: Simone Ballarin To: xen-devel@lists.xenproject.org Cc: consulting@bugseng.com, sstabellini@kernel.org, Simone Ballarin , Andrew Cooper , George Dunlap , Jan Beulich , Julien Grall , Wei Liu , Maria Celeste Cesario Subject: [XEN PATCH v3 09/16] xen: address violations of MISRA C:2012 Directive 4.10 Date: Mon, 11 Mar 2024 09:59:18 +0100 Message-Id: <504cdd2a0f27d28e0a87492f75476b123b68bbc0.1710145041.git.simone.ballarin@bugseng.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Amend inclusion guards to address violations of MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order to prevent the contents of a header file being included more than once"). Inclusion guards must appear at the beginning of the headers (comments are permitted anywhere) and the #if directive cannot be used for other checks. Mechanical change. Signed-off-by: Simone Ballarin Signed-off-by: Maria Celeste Cesario --- Changes in v3: - remove trailing underscores - change inclusion guard name to adhere to the new standard Changes in v2: - drop changes in xen/include/xen/unaligned.h since this second series adds a comment-based deviation in a separate patch - use #ifndef instead of #if !defined() --- xen/include/xen/err.h | 8 +++++--- xen/include/xen/pci_ids.h | 5 +++++ xen/include/xen/softirq.h | 8 +++++--- xen/include/xen/vmap.h | 8 +++++--- 4 files changed, 20 insertions(+), 9 deletions(-) diff --git a/xen/include/xen/err.h b/xen/include/xen/err.h index cbdd1bf7f8..360307c5da 100644 --- a/xen/include/xen/err.h +++ b/xen/include/xen/err.h @@ -1,5 +1,6 @@ -#if !defined(__XEN_ERR_H__) && !defined(__ASSEMBLY__) -#define __XEN_ERR_H__ +#ifndef XEN_INCLUDE_XEN_ERR_H +#define XEN_INCLUDE_XEN_ERR_H +#ifndef __ASSEMBLY__ #include #include @@ -41,4 +42,5 @@ static inline int __must_check PTR_RET(const void *ptr) return IS_ERR(ptr) ? PTR_ERR(ptr) : 0; } -#endif /* __XEN_ERR_H__ */ +#endif /* __ASSEMBLY__ */ +#endif /* XEN_INCLUDE_XEN_ERR_H */ diff --git a/xen/include/xen/pci_ids.h b/xen/include/xen/pci_ids.h index e798477a7e..8f2318bccd 100644 --- a/xen/include/xen/pci_ids.h +++ b/xen/include/xen/pci_ids.h @@ -1,3 +1,6 @@ +#ifndef XEN_INCLUDE_XEN_PCI_IDS_H +#define XEN_INCLUDE_XEN_PCI_IDS_H + #define PCI_VENDOR_ID_AMD 0x1022 #define PCI_VENDOR_ID_NVIDIA 0x10de @@ -11,3 +14,5 @@ #define PCI_VENDOR_ID_BROADCOM 0x14e4 #define PCI_VENDOR_ID_INTEL 0x8086 + +#endif /* XEN_INCLUDE_XEN_PCI_IDS_H */ diff --git a/xen/include/xen/softirq.h b/xen/include/xen/softirq.h index 33d6f2ecd2..d108cdd4bc 100644 --- a/xen/include/xen/softirq.h +++ b/xen/include/xen/softirq.h @@ -1,5 +1,6 @@ -#if !defined(__XEN_SOFTIRQ_H__) && !defined(__ASSEMBLY__) -#define __XEN_SOFTIRQ_H__ +#ifndef XEN_INCLUDE_XEN_SOFTIRQ_H +#define XEN_INCLUDE_XEN_SOFTIRQ_H +#ifndef __ASSEMBLY__ /* Low-latency softirqs come first in the following list. */ enum { @@ -40,4 +41,5 @@ void cpu_raise_softirq_batch_finish(void); */ void process_pending_softirqs(void); -#endif /* __XEN_SOFTIRQ_H__ */ +#endif /* __ASSEMBLY__ */ +#endif /* XEN_INCLUDE_XEN_SOFTIRQ_H */ diff --git a/xen/include/xen/vmap.h b/xen/include/xen/vmap.h index 0c16baa85f..bb83f5f64a 100644 --- a/xen/include/xen/vmap.h +++ b/xen/include/xen/vmap.h @@ -1,5 +1,6 @@ -#if !defined(__XEN_VMAP_H__) && defined(VMAP_VIRT_START) -#define __XEN_VMAP_H__ +#ifndef XEN_INCLUDE_XEN_VMAP_H +#define XEN_INCLUDE_XEN_VMAP_H +#ifdef VMAP_VIRT_START #include #include @@ -42,4 +43,5 @@ static inline void vm_init(void) vm_init_type(VMAP_DEFAULT, (void *)VMAP_VIRT_START, arch_vmap_virt_end()); } -#endif /* __XEN_VMAP_H__ */ +#endif /* VMAP_VIRT_START */ +#endif /* XEN_INCLUDE_XEN_VMAP_H */ -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Mon Mar 11 09:00:21 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 09:00:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691271.1077114 (Exim 4.92) (envelope-from ) id 1rjbW9-000081-0f; Mon, 11 Mar 2024 09:00:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691271.1077114; Mon, 11 Mar 2024 09:00:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjbW8-0008U8-Dc; Mon, 11 Mar 2024 09:00:20 +0000 Received: by outflank-mailman (input) for mailman id 691271; Mon, 11 Mar 2024 09:00:18 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjbW6-0006j9-0j for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 09:00:18 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id c7593b5a-df85-11ee-a1ee-f123f15fe8a2; Mon, 11 Mar 2024 10:00:16 +0100 (CET) Received: from beta.station (net-93-144-106-196.cust.vodafonedsl.it [93.144.106.196]) by support.bugseng.com (Postfix) with ESMTPSA id B42534EE0C90; Mon, 11 Mar 2024 10:00:15 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c7593b5a-df85-11ee-a1ee-f123f15fe8a2 From: Simone Ballarin To: xen-devel@lists.xenproject.org Cc: consulting@bugseng.com, sstabellini@kernel.org, Simone Ballarin , Andrew Cooper , George Dunlap , Jan Beulich , Julien Grall , Wei Liu , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Maria Celeste Cesario Subject: [XEN PATCH v3 10/16] x86/asm: address violations of MISRA C:2012 Directive 4.10 Date: Mon, 11 Mar 2024 09:59:19 +0100 Message-Id: <1e44047e767431c32621ae44d3121bc2152b3cb5.1710145041.git.simone.ballarin@bugseng.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Amend generation script, add inclusion guards to address violations of MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order to prevent the contents of a header file being included more than once"). This patch amends the Makefile adding the required inclusion guards for xlat.h. Add deviation comment for files intended for multiple inclusion. Signed-off-by: Simone Ballarin Signed-off-by: Maria Celeste Cesario --- Changes in v3: - fix inconsistent deviation ID - remove trailing underscores Changes in v2: - merge patches 7/13 and 13/13 of v1 as they had the same commit message - amend the Makefile to produce the required inclusion guard - use the format introduced with doc/misra/safe.json instead of a generic text-based deviation --- docs/misra/safe.json | 8 ++++++++ xen/arch/x86/include/asm/compat.h | 5 +++++ xen/arch/x86/include/asm/cpufeatures.h | 5 +---- xen/arch/x86/include/asm/efibind.h | 5 +++++ xen/include/Makefile | 10 ++++++++-- 5 files changed, 27 insertions(+), 6 deletions(-) diff --git a/docs/misra/safe.json b/docs/misra/safe.json index 363c9e21b0..13208d18ec 100644 --- a/docs/misra/safe.json +++ b/docs/misra/safe.json @@ -52,6 +52,14 @@ }, { "id": "SAF-6-safe", + "analyser": { + "eclair": "MC3R1.D4.10" + }, + "name": "Dir 4.10: file intended for multiple inclusion", + "text": "Files intended for multiple inclusion are not supposed to comply with D4.10." + }, + { + "id": "SAF-7-safe", "analyser": {}, "name": "Sentinel", "text": "Next ID to be used" diff --git a/xen/arch/x86/include/asm/compat.h b/xen/arch/x86/include/asm/compat.h index 818cad87db..36e7750843 100644 --- a/xen/arch/x86/include/asm/compat.h +++ b/xen/arch/x86/include/asm/compat.h @@ -2,6 +2,9 @@ * compat.h */ +#ifndef ASM_X86_COMPAT_H +#define ASM_X86_COMPAT_H + #ifdef CONFIG_COMPAT #define COMPAT_BITS_PER_LONG 32 @@ -18,3 +21,5 @@ int switch_compat(struct domain *); #include static inline int switch_compat(struct domain *d) { return -EOPNOTSUPP; } #endif + +#endif /* ASM_X86_COMPAT_H */ diff --git a/xen/arch/x86/include/asm/cpufeatures.h b/xen/arch/x86/include/asm/cpufeatures.h index c3aad21c3b..a65754d553 100644 --- a/xen/arch/x86/include/asm/cpufeatures.h +++ b/xen/arch/x86/include/asm/cpufeatures.h @@ -1,7 +1,4 @@ -/* - * Explicitly intended for multiple inclusion. - */ - +/* SAF-6-safe file intended for multiple inclusion */ #include /* Number of capability words covered by the featureset words. */ diff --git a/xen/arch/x86/include/asm/efibind.h b/xen/arch/x86/include/asm/efibind.h index bce02f3707..75684742be 100644 --- a/xen/arch/x86/include/asm/efibind.h +++ b/xen/arch/x86/include/asm/efibind.h @@ -1,2 +1,7 @@ +#ifndef ASM_X86_EFIBIND_H +#define ASM_X86_EFIBIND_H + #include #include + +#endif /* ASM_X86_EFIBIND_H */ diff --git a/xen/include/Makefile b/xen/include/Makefile index a77c9ffb7e..e777921eb1 100644 --- a/xen/include/Makefile +++ b/xen/include/Makefile @@ -104,10 +104,16 @@ $(obj)/compat/.xlat/%.lst: $(srcdir)/xlat.lst FORCE xlat-y := $(shell sed -ne 's,@arch@,$(compat-arch-y),g' -re 's,^[?!][[:blank:]]+[^[:blank:]]+[[:blank:]]+,,p' $(srcdir)/xlat.lst | uniq) xlat-y := $(filter $(patsubst compat/%,%,$(headers-y)),$(xlat-y)) +ARCHDIR = $(shell echo $(SRCARCH) | tr a-z A-Z) + quiet_cmd_xlat_h = GEN $@ -cmd_xlat_h = \ - cat $(filter %.h,$^) >$@.new; \ +define cmd_xlat_h + echo "#ifndef ASM_$(ARCHDIR)_COMPAT_XLAT_H" > $@.new; \ + echo "#define ASM_$(ARCHDIR)_COMPAT_XLAT_H" >> $@.new; \ + cat $(filter %.h,$^) >> $@.new; \ + echo "#endif /* ASM_$(ARCHDIR)_COMPAT_XLAT_H */" >> $@.new; \ mv -f $@.new $@ +endef $(obj)/compat/xlat.h: $(addprefix $(obj)/compat/.xlat/,$(xlat-y)) FORCE $(call if_changed,xlat_h) -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Mon Mar 11 09:00:22 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 09:00:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691270.1077124 (Exim 4.92) (envelope-from ) id 1rjbW9-0000KW-Vr; Mon, 11 Mar 2024 09:00:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691270.1077124; Mon, 11 Mar 2024 09:00:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjbW9-0000Ek-7p; Mon, 11 Mar 2024 09:00:21 +0000 Received: by outflank-mailman (input) for mailman id 691270; Mon, 11 Mar 2024 09:00:18 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjbW6-0006iu-1H for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 09:00:18 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id c7f9c963-df85-11ee-afdc-a90da7624cb6; Mon, 11 Mar 2024 10:00:17 +0100 (CET) Received: from beta.station (net-93-144-106-196.cust.vodafonedsl.it [93.144.106.196]) by support.bugseng.com (Postfix) with ESMTPSA id D11F94EE0C95; Mon, 11 Mar 2024 10:00:16 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c7f9c963-df85-11ee-afdc-a90da7624cb6 From: Simone Ballarin To: xen-devel@lists.xenproject.org Cc: consulting@bugseng.com, sstabellini@kernel.org, Maria Celeste Cesario , Andrew Cooper , George Dunlap , Jan Beulich , Julien Grall , Wei Liu , Simone Ballarin Subject: [XEN PATCH v3 12/16] xen: address violations of MISRA C:2012 Directive 4.10 Date: Mon, 11 Mar 2024 09:59:21 +0100 Message-Id: X-Mailer: git-send-email 2.34.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Maria Celeste Cesario Modify creation rule for asm-offsets.h to conform to the new standard and to not generate conflicting guards between architectures (which is a violation of the directive). Modify generic-y creation rule to generate code without violations and to conform to the new standard. Mechanical change. --- Commit introduced in v3 Signed-off-by: Maria Celeste Cesario Signed-off-by: Simone Ballarin --- xen/build.mk | 6 ++++-- xen/scripts/Makefile.asm-generic | 16 +++++++++++++++- 2 files changed, 19 insertions(+), 3 deletions(-) diff --git a/xen/build.mk b/xen/build.mk index 0f490ca71b..bd8b93e2ae 100644 --- a/xen/build.mk +++ b/xen/build.mk @@ -45,6 +45,8 @@ asm-offsets.s: arch/$(SRCARCH)/$(ARCH)/asm-offsets.c $(CC) $(call cpp_flags,$(c_flags)) -S -g0 -o $@.new -MQ $@ $< $(call move-if-changed,$@.new,$@) +ARCHDIR = $(shell echo $(SRCARCH) | tr a-z A-Z) + arch/$(SRCARCH)/include/asm/asm-offsets.h: asm-offsets.s @(set -e; \ echo "/*"; \ @@ -54,8 +56,8 @@ arch/$(SRCARCH)/include/asm/asm-offsets.h: asm-offsets.s echo " *"; \ echo " */"; \ echo ""; \ - echo "#ifndef __ASM_OFFSETS_H__"; \ - echo "#define __ASM_OFFSETS_H__"; \ + echo "#ifndef ASM_$(ARCHDIR)_ASM_OFFSETS_H"; \ + echo "#define ASM_$(ARCHDIR)_ASM_OFFSETS_H"; \ echo ""; \ sed -rne "/^[^#].*==>/{s:.*==>(.*)<==.*:\1:; s: [\$$#]: :; p;}"; \ echo ""; \ diff --git a/xen/scripts/Makefile.asm-generic b/xen/scripts/Makefile.asm-generic index b0d356bfa3..3b538bc7a4 100644 --- a/xen/scripts/Makefile.asm-generic +++ b/xen/scripts/Makefile.asm-generic @@ -31,8 +31,22 @@ generated-y := $(addprefix $(obj)/, $(generated-y)) old-headers := $(wildcard $(obj)/*.h) unwanted := $(filter-out $(generic-y) $(generated-y),$(old-headers)) +define header_stub +#ifndef ASM_GENERIC_$(3)_$(2)_H +#define ASM_GENERIC_$(3)_$(2)_H + +#include + +#endif /* ASM_GENERIC_$(3)_$(2)_H */ +endef + +arch = $(shell echo $(SRCARCH) | tr a-z A-Z) + +header_body = $(call header_stub,$*,$(shell echo "$*" | tr a-z A-Z),$(arch)) +export header_body + quiet_cmd_wrap = WRAP $@ - cmd_wrap = echo "\#include " > $@ + cmd_wrap = echo "$$header_body" > $@ quiet_cmd_remove = REMOVE $(unwanted) cmd_remove = rm -f $(unwanted) -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Mon Mar 11 09:00:23 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 09:00:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691272.1077133 (Exim 4.92) (envelope-from ) id 1rjbWB-0000er-6q; Mon, 11 Mar 2024 09:00:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691272.1077133; Mon, 11 Mar 2024 09:00:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjbWA-0000aS-JB; Mon, 11 Mar 2024 09:00:22 +0000 Received: by outflank-mailman (input) for mailman id 691272; Mon, 11 Mar 2024 09:00:18 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjbW6-0006iu-Pw for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 09:00:18 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id c85b0784-df85-11ee-afdc-a90da7624cb6; Mon, 11 Mar 2024 10:00:18 +0100 (CET) Received: from beta.station (net-93-144-106-196.cust.vodafonedsl.it [93.144.106.196]) by support.bugseng.com (Postfix) with ESMTPSA id 65B984EE0C9E; Mon, 11 Mar 2024 10:00:17 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c85b0784-df85-11ee-afdc-a90da7624cb6 From: Simone Ballarin To: xen-devel@lists.xenproject.org Cc: consulting@bugseng.com, sstabellini@kernel.org, Maria Celeste Cesario , Simone Ballarin , Doug Goldstein , Andrew Cooper , George Dunlap , Jan Beulich , Julien Grall , Wei Liu , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [XEN PATCH v3 13/16] xen: add deviations for MISRA C.2012 Directive 4.10 Date: Mon, 11 Mar 2024 09:59:22 +0100 Message-Id: <787aa5a65135796c825d366b43e00ba018c0065b.1710145041.git.simone.ballarin@bugseng.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Maria Celeste Cesario Add safe deviation for *.c files, as estabilished in past discussion. Add SAF deviation for files that need an #include directive before guard. Signed-off-by: Maria Celeste Cesario Signed-off-by: Simone Ballarin --- Commit introduced in v3 Link to the discussion thread: https://lists.xenproject.org/archives/html/xen-devel/2023-09/msg00239.html --- automation/eclair_analysis/ECLAIR/deviations.ecl | 5 +++++ docs/misra/deviations.rst | 7 +++++++ docs/misra/safe.json | 8 ++++++++ xen/include/public/arch-x86/xen.h | 1 + 4 files changed, 21 insertions(+) diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl index 039ffaf52a..8082239ccc 100644 --- a/automation/eclair_analysis/ECLAIR/deviations.ecl +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl @@ -69,6 +69,11 @@ conform to the directive." -config=MC3R1.D4.10,reports+={safe, "first_area(text(^/\\* Generated file, do not edit! \\*/$, begin-3))"} -doc_end +-doc_begin="Including multiple times a .c file is safe because every function or data item +it defines would (in the common case) be already defined. Peer reviewed by the community." +-config=MC3R1.D4.10,reports+={safe, "all_area(all_loc(^.*\\.c$))"} +-doc_end + # # Series 5. # diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst index ce855ddae6..7b32dbd23f 100644 --- a/docs/misra/deviations.rst +++ b/docs/misra/deviations.rst @@ -30,6 +30,13 @@ Deviations related to MISRA C:2012 Directives: not to add an additional encapsulation layer. - Tagged as `deliberate` for ECLAIR. + * - D4.10 + - Including multiple times a .c file is safe because every function or data item + it defines would in (the common case) be already defined. + Peer reviewed by the community. + - Tagged as `safe` for ECLAIR. + + Deviations related to MISRA C:2012 Rules: ----------------------------------------- diff --git a/docs/misra/safe.json b/docs/misra/safe.json index 13208d18ec..dd61b47194 100644 --- a/docs/misra/safe.json +++ b/docs/misra/safe.json @@ -60,6 +60,14 @@ }, { "id": "SAF-7-safe", + "analyser": { + "eclair": "MC3R1.D4.10" + }, + "name": "Dir 4.10: include needed before guard", + "text": "These files need to start with an include directive to generate preprocessed code in the correct order." + }, + { + "id": "SAF-8-safe", "analyser": {}, "name": "Sentinel", "text": "Next ID to be used" diff --git a/xen/include/public/arch-x86/xen.h b/xen/include/public/arch-x86/xen.h index c0f4551247..0b2e9271f8 100644 --- a/xen/include/public/arch-x86/xen.h +++ b/xen/include/public/arch-x86/xen.h @@ -7,6 +7,7 @@ * Copyright (c) 2004-2006, K A Fraser */ +/* SAF-7-safe include before guard needed for correct code generation */ #include "../xen.h" #ifndef __XEN_PUBLIC_ARCH_X86_XEN_H__ -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Mon Mar 11 09:00:24 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 09:00:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691273.1077141 (Exim 4.92) (envelope-from ) id 1rjbWB-0000q2-V2; Mon, 11 Mar 2024 09:00:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691273.1077141; Mon, 11 Mar 2024 09:00:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjbWB-0000nU-Dx; Mon, 11 Mar 2024 09:00:23 +0000 Received: by outflank-mailman (input) for mailman id 691273; Mon, 11 Mar 2024 09:00:19 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjbW7-0006j9-0o for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 09:00:19 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id c7a8977b-df85-11ee-a1ee-f123f15fe8a2; Mon, 11 Mar 2024 10:00:17 +0100 (CET) Received: from beta.station (net-93-144-106-196.cust.vodafonedsl.it [93.144.106.196]) by support.bugseng.com (Postfix) with ESMTPSA id 53C8B4EE0C9A; Mon, 11 Mar 2024 10:00:16 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c7a8977b-df85-11ee-a1ee-f123f15fe8a2 From: Simone Ballarin To: xen-devel@lists.xenproject.org Cc: consulting@bugseng.com, sstabellini@kernel.org, Maria Celeste Cesario , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Simone Ballarin Subject: [XEN PATCH v3 11/16] xen/arm: address violations of MISRA C:2012 Directive 4.10 Date: Mon, 11 Mar 2024 09:59:20 +0100 Message-Id: X-Mailer: git-send-email 2.34.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Maria Celeste Cesario Add or modify inclusion guards to address violations of MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order to prevent the contents of a header file being included more than once"). Mechanical change. --- Commit introduced in v3 Signed-off-by: Maria Celeste Cesario Signed-off-by: Simone Ballarin --- xen/arch/arm/include/asm/domain.h | 6 +++--- xen/arch/arm/include/asm/efibind.h | 5 +++++ xen/arch/arm/include/asm/event.h | 6 +++--- xen/arch/arm/include/asm/grant_table.h | 6 +++--- xen/arch/arm/include/asm/io.h | 6 +++--- xen/arch/arm/include/asm/irq.h | 6 +++--- xen/arch/arm/include/asm/smp.h | 6 +++--- xen/arch/arm/include/asm/spinlock.h | 6 +++--- xen/arch/arm/include/asm/system.h | 6 +++--- 9 files changed, 29 insertions(+), 24 deletions(-) diff --git a/xen/arch/arm/include/asm/domain.h b/xen/arch/arm/include/asm/domain.h index 8218afb862..b7dc023a25 100644 --- a/xen/arch/arm/include/asm/domain.h +++ b/xen/arch/arm/include/asm/domain.h @@ -1,5 +1,5 @@ -#ifndef __ASM_DOMAIN_H__ -#define __ASM_DOMAIN_H__ +#ifndef ASM_ARM_DOMAIN_H +#define ASM_ARM_DOMAIN_H #include #include @@ -312,7 +312,7 @@ static inline void update_guest_memory_policy(struct vcpu *v, struct guest_memory_policy *gmp) {} -#endif /* __ASM_DOMAIN_H__ */ +#endif /* ASM_ARM_DOMAIN_H */ /* * Local variables: diff --git a/xen/arch/arm/include/asm/efibind.h b/xen/arch/arm/include/asm/efibind.h index 09dca7a8c9..689bf63232 100644 --- a/xen/arch/arm/include/asm/efibind.h +++ b/xen/arch/arm/include/asm/efibind.h @@ -1,2 +1,7 @@ +#ifndef ASM_ARM_EFI_BIND_H +#define ASM_ARM_EFI_BIND_H + #include #include + +#endif /* ASM_ARM_EFI_BIND_H */ diff --git a/xen/arch/arm/include/asm/event.h b/xen/arch/arm/include/asm/event.h index b14c166ad6..db5d5ea37a 100644 --- a/xen/arch/arm/include/asm/event.h +++ b/xen/arch/arm/include/asm/event.h @@ -1,5 +1,5 @@ -#ifndef __ASM_EVENT_H__ -#define __ASM_EVENT_H__ +#ifndef ASM_ARM_EVENT_H +#define ASM_ARM_EVENT_H #include @@ -52,7 +52,7 @@ static inline bool arch_virq_is_global(unsigned int virq) return true; } -#endif +#endif /* ASM_ARM_EVENT_H */ /* * Local variables: * mode: C diff --git a/xen/arch/arm/include/asm/grant_table.h b/xen/arch/arm/include/asm/grant_table.h index d3c518a926..0363c6aa1e 100644 --- a/xen/arch/arm/include/asm/grant_table.h +++ b/xen/arch/arm/include/asm/grant_table.h @@ -1,5 +1,5 @@ -#ifndef __ASM_GRANT_TABLE_H__ -#define __ASM_GRANT_TABLE_H__ +#ifndef ASM_ARM_GRANT_TABLE_H +#define ASM_ARM_GRANT_TABLE_H #include #include @@ -76,7 +76,7 @@ int replace_grant_host_mapping(uint64_t gpaddr, mfn_t frame, #define gnttab_need_iommu_mapping(d) \ (is_domain_direct_mapped(d) && is_iommu_enabled(d)) -#endif /* __ASM_GRANT_TABLE_H__ */ +#endif /* ASM_ARM_GRANT_TABLE_H */ /* * Local variables: * mode: C diff --git a/xen/arch/arm/include/asm/io.h b/xen/arch/arm/include/asm/io.h index e426804424..8b5f811ec8 100644 --- a/xen/arch/arm/include/asm/io.h +++ b/xen/arch/arm/include/asm/io.h @@ -1,5 +1,5 @@ -#ifndef _ASM_IO_H -#define _ASM_IO_H +#ifndef ASM_ARM_IO_H +#define ASM_ARM_IO_H #if defined(CONFIG_ARM_32) # include @@ -9,7 +9,7 @@ # error "unknown ARM variant" #endif -#endif +#endif /* ASM_ARM_IO_H */ /* * Local variables: * mode: C diff --git a/xen/arch/arm/include/asm/irq.h b/xen/arch/arm/include/asm/irq.h index c8044b0371..48b46de51f 100644 --- a/xen/arch/arm/include/asm/irq.h +++ b/xen/arch/arm/include/asm/irq.h @@ -1,5 +1,5 @@ -#ifndef _ASM_HW_IRQ_H -#define _ASM_HW_IRQ_H +#ifndef ASM_ARM_IRQ_H +#define ASM_ARM_IRQ_H #include #include @@ -99,7 +99,7 @@ void irq_set_affinity(struct irq_desc *desc, const cpumask_t *mask); */ bool irq_type_set_by_domain(const struct domain *d); -#endif /* _ASM_HW_IRQ_H */ +#endif /* ASM_ARM_IRQ_H */ /* * Local variables: * mode: C diff --git a/xen/arch/arm/include/asm/smp.h b/xen/arch/arm/include/asm/smp.h index e99a3a3f53..44e4183470 100644 --- a/xen/arch/arm/include/asm/smp.h +++ b/xen/arch/arm/include/asm/smp.h @@ -1,5 +1,5 @@ -#ifndef __ASM_SMP_H -#define __ASM_SMP_H +#ifndef ASM_ARM_SMP_H +#define ASM_ARM_SMP_H #ifndef __ASSEMBLY__ #include @@ -39,7 +39,7 @@ extern unsigned int smp_get_max_cpus(void); #define cpu_physical_id(cpu) cpu_logical_map(cpu) -#endif +#endif /* ASM_ARM_SMP_H */ /* * Local variables: diff --git a/xen/arch/arm/include/asm/spinlock.h b/xen/arch/arm/include/asm/spinlock.h index 42b0f584fe..326005c39a 100644 --- a/xen/arch/arm/include/asm/spinlock.h +++ b/xen/arch/arm/include/asm/spinlock.h @@ -1,5 +1,5 @@ -#ifndef __ASM_SPINLOCK_H -#define __ASM_SPINLOCK_H +#ifndef ASM_ARM_SPINLOCK_H +#define ASM_ARM_SPINLOCK_H #define arch_lock_acquire_barrier() smp_mb() #define arch_lock_release_barrier() smp_mb() @@ -12,4 +12,4 @@ #define arch_lock_signal_wmb() arch_lock_signal() -#endif /* __ASM_SPINLOCK_H */ +#endif /* ASM_ARM_SPINLOCK_H */ diff --git a/xen/arch/arm/include/asm/system.h b/xen/arch/arm/include/asm/system.h index 65d5c8e423..faf9227f53 100644 --- a/xen/arch/arm/include/asm/system.h +++ b/xen/arch/arm/include/asm/system.h @@ -1,6 +1,6 @@ /* Portions taken from Linux arch arm */ -#ifndef __ASM_SYSTEM_H -#define __ASM_SYSTEM_H +#ifndef ASM_ARM_SYSTEM_H +#define ASM_ARM_SYSTEM_H #include #include @@ -62,7 +62,7 @@ static inline int local_abort_is_enabled(void) extern struct vcpu *__context_switch(struct vcpu *prev, struct vcpu *next); -#endif +#endif /* ASM_ARM_SYSTEM_H */ /* * Local variables: * mode: C -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Mon Mar 11 09:00:25 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 09:00:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691274.1077149 (Exim 4.92) (envelope-from ) id 1rjbWD-0001AV-0V; Mon, 11 Mar 2024 09:00:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691274.1077149; Mon, 11 Mar 2024 09:00:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjbWC-00016O-IV; Mon, 11 Mar 2024 09:00:24 +0000 Received: by outflank-mailman (input) for mailman id 691274; Mon, 11 Mar 2024 09:00:20 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjbW8-0006j9-7r for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 09:00:20 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id c8a8545d-df85-11ee-a1ee-f123f15fe8a2; Mon, 11 Mar 2024 10:00:18 +0100 (CET) Received: from beta.station (net-93-144-106-196.cust.vodafonedsl.it [93.144.106.196]) by support.bugseng.com (Postfix) with ESMTPSA id 0C5F54EE0C99; Mon, 11 Mar 2024 10:00:18 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c8a8545d-df85-11ee-a1ee-f123f15fe8a2 From: Simone Ballarin To: xen-devel@lists.xenproject.org Cc: consulting@bugseng.com, sstabellini@kernel.org, Maria Celeste Cesario , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Wei Liu Subject: [XEN PATCH v3 14/16] xen/x86: address violations of MISRA C:2012 Directive 4.10 Date: Mon, 11 Mar 2024 09:59:23 +0100 Message-Id: <305d6474a84e16d44c193a93e2c2ca91d6dd0f7e.1710145041.git.simone.ballarin@bugseng.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Maria Celeste Cesario Edit inclusion guards to address violations of MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order to prevent the contents of a header file being included more than once"). Mechanical change. --- Commit introduced in v3 Signed-off-by: Maria Celeste Cesario Signed-off-by: Simone Ballarin --- xen/arch/x86/include/asm/domain.h | 6 +++--- xen/arch/x86/include/asm/event.h | 6 +++--- xen/arch/x86/include/asm/grant_table.h | 6 +++--- xen/arch/x86/include/asm/io.h | 6 +++--- xen/arch/x86/include/asm/irq.h | 6 +++--- xen/arch/x86/include/asm/smp.h | 6 +++--- xen/arch/x86/include/asm/spinlock.h | 6 +++--- xen/arch/x86/include/asm/system.h | 6 +++--- 8 files changed, 24 insertions(+), 24 deletions(-) diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h index 622d22bef2..cb7b01f7ef 100644 --- a/xen/arch/x86/include/asm/domain.h +++ b/xen/arch/x86/include/asm/domain.h @@ -1,5 +1,5 @@ -#ifndef __ASM_DOMAIN_H__ -#define __ASM_DOMAIN_H__ +#ifndef ASM_X86_DOMAIN_H +#define ASM_X86_DOMAIN_H #include #include @@ -780,7 +780,7 @@ struct arch_vcpu_io { /* Maxphysaddr supportable by the paging infrastructure. */ unsigned int domain_max_paddr_bits(const struct domain *d); -#endif /* __ASM_DOMAIN_H__ */ +#endif /* ASM_X86_DOMAIN_H */ /* * Local variables: diff --git a/xen/arch/x86/include/asm/event.h b/xen/arch/x86/include/asm/event.h index 5e09ede6d7..c0b6088c91 100644 --- a/xen/arch/x86/include/asm/event.h +++ b/xen/arch/x86/include/asm/event.h @@ -6,8 +6,8 @@ * */ -#ifndef __ASM_EVENT_H__ -#define __ASM_EVENT_H__ +#ifndef ASM_X86_EVENT_H +#define ASM_X86_EVENT_H #include @@ -53,4 +53,4 @@ static inline bool arch_virq_is_global(unsigned int virq) (pv_shim && (chn)->port && (chn)->state == ECS_RESERVED) #endif -#endif +#endif /* ASM_X86_EVENT_H */ diff --git a/xen/arch/x86/include/asm/grant_table.h b/xen/arch/x86/include/asm/grant_table.h index 5c23cec90c..2468f21ad6 100644 --- a/xen/arch/x86/include/asm/grant_table.h +++ b/xen/arch/x86/include/asm/grant_table.h @@ -4,8 +4,8 @@ * Copyright (c) 2004-2005 K A Fraser */ -#ifndef __ASM_GRANT_TABLE_H__ -#define __ASM_GRANT_TABLE_H__ +#ifndef ASM_X86_GRANT_TABLE_H +#define ASM_X86_GRANT_TABLE_H #include @@ -72,4 +72,4 @@ static inline void gnttab_clear_flags(struct domain *d, #define gnttab_need_iommu_mapping(d) \ (!paging_mode_translate(d) && need_iommu_pt_sync(d)) -#endif /* __ASM_GRANT_TABLE_H__ */ +#endif /* ASM_X86_GRANT_TABLE_H */ diff --git a/xen/arch/x86/include/asm/io.h b/xen/arch/x86/include/asm/io.h index 9b19d2d389..9371784584 100644 --- a/xen/arch/x86/include/asm/io.h +++ b/xen/arch/x86/include/asm/io.h @@ -1,5 +1,5 @@ -#ifndef _ASM_IO_H -#define _ASM_IO_H +#ifndef ASM_X86_IO_H +#define ASM_X86_IO_H #include #include @@ -57,4 +57,4 @@ struct cpu_user_regs; unsigned int ioemul_handle_proliant_quirk( uint8_t opcode, char *io_emul_stub, const struct cpu_user_regs *regs); -#endif +#endif /* ASM_X86_IO_H */ diff --git a/xen/arch/x86/include/asm/irq.h b/xen/arch/x86/include/asm/irq.h index 082a3d6bbc..f8139842b4 100644 --- a/xen/arch/x86/include/asm/irq.h +++ b/xen/arch/x86/include/asm/irq.h @@ -1,5 +1,5 @@ -#ifndef _ASM_HW_IRQ_H -#define _ASM_HW_IRQ_H +#ifndef ASM_X86_IRQ_H +#define ASM_X86_IRQ_H /* (C) 1992, 1993 Linus Torvalds, (C) 1997 Ingo Molnar */ @@ -192,4 +192,4 @@ int allocate_and_map_gsi_pirq(struct domain *d, int index, int *pirq_p); int allocate_and_map_msi_pirq(struct domain *d, int index, int *pirq_p, int type, struct msi_info *msi); -#endif /* _ASM_HW_IRQ_H */ +#endif /* ASM_X86_IRQ_H */ diff --git a/xen/arch/x86/include/asm/smp.h b/xen/arch/x86/include/asm/smp.h index c8c7960134..cdfe9ea96f 100644 --- a/xen/arch/x86/include/asm/smp.h +++ b/xen/arch/x86/include/asm/smp.h @@ -1,5 +1,5 @@ -#ifndef __ASM_SMP_H -#define __ASM_SMP_H +#ifndef ASM_X86_SMP_H +#define ASM_X86_SMP_H /* * We need the APIC definitions automatically as part of 'smp.h' @@ -81,4 +81,4 @@ void *cpu_alloc_stack(unsigned int cpu); #endif /* !__ASSEMBLY__ */ -#endif +#endif /* ASM_X86_SMP_H */ diff --git a/xen/arch/x86/include/asm/spinlock.h b/xen/arch/x86/include/asm/spinlock.h index 56f6095752..2a86560343 100644 --- a/xen/arch/x86/include/asm/spinlock.h +++ b/xen/arch/x86/include/asm/spinlock.h @@ -1,5 +1,5 @@ -#ifndef __ASM_SPINLOCK_H -#define __ASM_SPINLOCK_H +#ifndef ASM_X86_SPINLOCK_H +#define ASM_X86_SPINLOCK_H #define _raw_read_unlock(l) \ BUILD_BUG_ON(sizeof((l)->lock) != 4); /* Clang doesn't support %z in asm. */ \ @@ -24,4 +24,4 @@ arch_lock_signal(); \ }) -#endif /* __ASM_SPINLOCK_H */ +#endif /* ASM_X86_SPINLOCK_H */ diff --git a/xen/arch/x86/include/asm/system.h b/xen/arch/x86/include/asm/system.h index 73cb16ca68..12e8b974b1 100644 --- a/xen/arch/x86/include/asm/system.h +++ b/xen/arch/x86/include/asm/system.h @@ -1,5 +1,5 @@ -#ifndef __ASM_SYSTEM_H -#define __ASM_SYSTEM_H +#ifndef ASM_X86_SYSTEM_H +#define ASM_X86_SYSTEM_H #include #include @@ -269,4 +269,4 @@ void load_system_tables(void); void percpu_traps_init(void); void subarch_percpu_traps_init(void); -#endif +#endif /* ASM_X86_SYSTEM_H */ -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Mon Mar 11 09:00:26 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 09:00:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691275.1077157 (Exim 4.92) (envelope-from ) id 1rjbWE-0001MF-7Z; Mon, 11 Mar 2024 09:00:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691275.1077157; Mon, 11 Mar 2024 09:00:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjbWD-0001If-Bo; Mon, 11 Mar 2024 09:00:25 +0000 Received: by outflank-mailman (input) for mailman id 691275; Mon, 11 Mar 2024 09:00:21 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjbW9-0006j9-0y for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 09:00:21 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id c8f7fdf3-df85-11ee-a1ee-f123f15fe8a2; Mon, 11 Mar 2024 10:00:19 +0100 (CET) Received: from beta.station (net-93-144-106-196.cust.vodafonedsl.it [93.144.106.196]) by support.bugseng.com (Postfix) with ESMTPSA id 831634EE0CA1; Mon, 11 Mar 2024 10:00:18 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c8f7fdf3-df85-11ee-a1ee-f123f15fe8a2 From: Simone Ballarin To: xen-devel@lists.xenproject.org Cc: consulting@bugseng.com, sstabellini@kernel.org, Maria Celeste Cesario , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Wei Liu , Simone Ballarin Subject: [XEN PATCH v3 15/16] x86/mtrr: address violations of MISRA C:2012 Directive 4.10 Date: Mon, 11 Mar 2024 09:59:24 +0100 Message-Id: <33413c877af70c8aed05ed1bc7b259c59087cb96.1710145041.git.simone.ballarin@bugseng.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Maria Celeste Cesario Add inclusion guard to address violations of MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order to prevent the contents of a header file being included more than once"). Mechanical change. --- Commit introduced in v3 Signed-off-by: Maria Celeste Cesario Signed-off-by: Simone Ballarin --- xen/arch/x86/cpu/mtrr/mtrr.h | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/xen/arch/x86/cpu/mtrr/mtrr.h b/xen/arch/x86/cpu/mtrr/mtrr.h index a9741e0cb0..632bf658be 100644 --- a/xen/arch/x86/cpu/mtrr/mtrr.h +++ b/xen/arch/x86/cpu/mtrr/mtrr.h @@ -1,6 +1,8 @@ /* * local mtrr defines. */ +#ifndef X86_CPU_MTRR_MTRR_H +#define X86_CPU_MTRR_MTRR_H #define MTRR_CHANGE_MASK_FIXED 0x01 #define MTRR_CHANGE_MASK_VARIABLE 0x02 @@ -25,3 +27,5 @@ extern u64 size_or_mask, size_and_mask; extern unsigned int num_var_ranges; void mtrr_state_warn(void); + +#endif /* X86_CPU_MTRR_MTRR_H */ -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Mon Mar 11 09:00:27 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 09:00:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691276.1077166 (Exim 4.92) (envelope-from ) id 1rjbWF-0001bA-9H; Mon, 11 Mar 2024 09:00:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691276.1077166; Mon, 11 Mar 2024 09:00:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjbWE-0001TI-EW; Mon, 11 Mar 2024 09:00:26 +0000 Received: by outflank-mailman (input) for mailman id 691276; Mon, 11 Mar 2024 09:00:22 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjbWA-0006j9-1F for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 09:00:22 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id c94b92b3-df85-11ee-a1ee-f123f15fe8a2; Mon, 11 Mar 2024 10:00:19 +0100 (CET) Received: from beta.station (net-93-144-106-196.cust.vodafonedsl.it [93.144.106.196]) by support.bugseng.com (Postfix) with ESMTPSA id 0C23F4EE0C9C; Mon, 11 Mar 2024 10:00:19 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c94b92b3-df85-11ee-a1ee-f123f15fe8a2 From: Simone Ballarin To: xen-devel@lists.xenproject.org Cc: consulting@bugseng.com, sstabellini@kernel.org, Maria Celeste Cesario , Andrew Cooper , George Dunlap , Jan Beulich , Julien Grall , Wei Liu , Simone Ballarin Subject: [XEN PATCH v3 16/16] xen/lz4: address violations of MISRA C:2012 Directive 4.10 Date: Mon, 11 Mar 2024 09:59:25 +0100 Message-Id: <1d02e429534b9b1c53fd3c5b82588e3803434c92.1710145041.git.simone.ballarin@bugseng.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Maria Celeste Cesario Add inclusion guard to address violations of MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order to prevent the contents of a header file being included more than once"). Mechanical change. --- Commit introduced in v3 Signed-off-by: Maria Celeste Cesario Signed-off-by: Simone Ballarin --- xen/common/lz4/defs.h | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/xen/common/lz4/defs.h b/xen/common/lz4/defs.h index 6d81113266..ecfbf07f83 100644 --- a/xen/common/lz4/defs.h +++ b/xen/common/lz4/defs.h @@ -8,6 +8,9 @@ * published by the Free Software Foundation. */ +#ifndef COMMON_LZ4_DEFS_H +#define COMMON_LZ4_DEFS_H + #ifdef __XEN__ #include #include @@ -166,3 +169,5 @@ typedef struct _U64_S { u64 v; } U64_S; LZ4_WILDCOPY(s, d, e); \ d = e; \ } while (0) + +#endif /* COMMON_LZ4_DEFS_H */ -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Mon Mar 11 09:02:30 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 09:02:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691298.1077202 (Exim 4.92) (envelope-from ) id 1rjbYD-00073y-C6; Mon, 11 Mar 2024 09:02:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691298.1077202; Mon, 11 Mar 2024 09:02:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjbYD-00073r-88; Mon, 11 Mar 2024 09:02:29 +0000 Received: by outflank-mailman (input) for mailman id 691298; Mon, 11 Mar 2024 09:02:28 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjbYC-00073Z-AS for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 09:02:28 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 146594af-df86-11ee-a1ee-f123f15fe8a2; Mon, 11 Mar 2024 10:02:25 +0100 (CET) Received: from [172.20.10.8] (unknown [37.163.170.24]) by support.bugseng.com (Postfix) with ESMTPSA id B67174EE0C90; Mon, 11 Mar 2024 10:02:23 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 146594af-df86-11ee-a1ee-f123f15fe8a2 Message-ID: <602c2da1-d5ab-4120-ab19-37e75820d129@bugseng.com> Date: Mon, 11 Mar 2024 10:02:21 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH] xen/evtchn: address violations of MISRA C:2012 Rules 16.3 and 16.4 To: Jan Beulich , Stefano Stabellini Cc: consulting@bugseng.com, Andrew Cooper , George Dunlap , Julien Grall , Wei Liu , xen-devel@lists.xenproject.org References: <3ec419e30227a8016c28e04524cd36a549aaddcf.1709898466.git.federico.serafini@bugseng.com> Content-Language: en-US, it From: Federico Serafini Organization: BUGSENG srl In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 11/03/24 08:40, Jan Beulich wrote: > On 08.03.2024 12:51, Federico Serafini wrote: >> --- a/xen/common/event_channel.c >> +++ b/xen/common/event_channel.c >> @@ -130,9 +130,12 @@ static bool virq_is_global(unsigned int virq) >> >> case VIRQ_ARCH_0 ... VIRQ_ARCH_7: >> return arch_virq_is_global(virq); >> + >> + default: >> + ASSERT(virq < NR_VIRQS); >> + break; >> } >> >> - ASSERT(virq < NR_VIRQS); >> return true; >> } > > Just for my understanding: The ASSERT() is moved so the "default" would > consist of more than just "break". Why is it that then the "return" isn't > moved, too? No reason in particular. If preferred, I can move it too. > >> @@ -846,6 +849,7 @@ int evtchn_send(struct domain *ld, unsigned int lport) >> break; >> default: >> ret = -EINVAL; >> + break; >> } > > I certainly agree here. > >> @@ -1672,6 +1676,9 @@ static void domain_dump_evtchn_info(struct domain *d) >> case ECS_VIRQ: >> printk(" v=%d", chn->u.virq); >> break; >> + default: >> + /* Nothing to do in other cases. */ >> + break; >> } > > Yes this, just to mention it, while in line with what Misra demands is > pretty meaningless imo: The absence of "default" says exactly what the > comment now says. FTAOD - this is a comment towards the Misra guideline, > not so much towards the specific change here. Both you and Stefano reviewed the code and agreed on the fact that doing nothing for the default case is the right thing and now the code explicitly says that without letting any doubts. Furthermore, during the reviews it could happen that you notice a switch where something needs to be done for the default case. -- Federico Serafini, M.Sc. Software Engineer, BUGSENG (http://bugseng.com) From xen-devel-bounces@lists.xenproject.org Mon Mar 11 09:11:33 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 09:11:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691335.1077212 (Exim 4.92) (envelope-from ) id 1rjbgd-0001O3-Mf; Mon, 11 Mar 2024 09:11:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691335.1077212; Mon, 11 Mar 2024 09:11:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjbgd-0001Nv-Gz; Mon, 11 Mar 2024 09:11:11 +0000 Received: by outflank-mailman (input) for mailman id 691335; Mon, 11 Mar 2024 09:11:10 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjbgb-0001Np-Pj for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 09:11:10 +0000 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2060e.outbound.protection.outlook.com [2a01:111:f400:7e88::60e]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 4a3abd23-df87-11ee-a1ee-f123f15fe8a2; Mon, 11 Mar 2024 10:11:06 +0100 (CET) Received: from DS7PR03CA0026.namprd03.prod.outlook.com (2603:10b6:5:3b8::31) by PH8PR12MB8606.namprd12.prod.outlook.com (2603:10b6:510:1ce::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.35; Mon, 11 Mar 2024 09:11:01 +0000 Received: from CY4PEPF0000E9D1.namprd03.prod.outlook.com (2603:10b6:5:3b8:cafe::77) by DS7PR03CA0026.outlook.office365.com (2603:10b6:5:3b8::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.35 via Frontend Transport; Mon, 11 Mar 2024 09:11:01 +0000 Received: from SATLEXMB03.amd.com (165.204.84.17) by CY4PEPF0000E9D1.mail.protection.outlook.com (10.167.241.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7386.12 via Frontend Transport; Mon, 11 Mar 2024 09:11:00 +0000 Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Mon, 11 Mar 2024 04:10:59 -0500 Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend Transport; Mon, 11 Mar 2024 04:10:57 -0500 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 4a3abd23-df87-11ee-a1ee-f123f15fe8a2 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oOoBJ1abOBTHg8Ftshmo6/+6gbJk0DQWc7wFpEl0yU+e8PlNUnPBa/ePEtpVk0RDbE6X/jln2NHhEtwT+H7mzaNknkxR2MnJzGJrIpDY1dnzjPZ8AmS/Orgcf0HMerbog/7ELG2pSTomx5RVS1Tag0myd3UE+jvSddLC7OhOCiX3eDQGDvtsE0pA1V54tuFBUTl/K+X4OIQ2kbEGdQpdC6JZutHkkCszVy+Pt1B9gogUuSTbBN5JSBx1w5G+JvIzlABRnQVbZz+sJxVnlDnQEpOqk/ZfA1MZKdJ4LvLJoPSu8da/fmWn2KhPUPlBd19o7/wxGCyG9uvwu3kKZUIaYw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=UYT6tYCtp9BiW0YOTbTimG9Dk+e985YPJ1amZ/gULAc=; b=AbsT9jd9Z02f82vJm0UrV1rFYtLsyNHbPgG3beHfJEdoJZeRFcT6mdtceX4bo2WMiYPFz3db+zOThM3oocxny2R3HrkAKgqv9E3n4peIIplgMrYeH20qN2qL7AZijJ9j9cwD6xGp1J7Uy7jLu8JpoRIV6S+hpauWYGZc53IVpj560uZjiMsOAGiX7qkQ8TZvfHdienkZS0WHLcdoV9a8UbzpFlAnMWI7+miNLZsUvvHjHhvaGK8bNz0bEqPkEKTncFgDv4Eh2GsqR791fRik/z2k9FvY6b9fOeuAEFsTKfNlVxkvCXJH9lRNvo68Foz8H1PbZQAElWQzilwfwwPpRA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UYT6tYCtp9BiW0YOTbTimG9Dk+e985YPJ1amZ/gULAc=; b=h3pEkDZeLw5AvreoQB2IvcQUBGhFX+X2nYTnhpIgViGW2XIugFOOt/FmZfeQKq3a98niCmiHgxiEplvn9ZfSlikKiKB9Lq1JnYb4gnHjXuakL+WrBZDOQtJTy5xXUIH39h33ISuJtu6KsUxejHlrTMG5LBRlod8NsbSnEb8KFGg= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C Message-ID: Date: Mon, 11 Mar 2024 10:10:57 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 3/5] xen/domctl, tools: Introduce a new domctl to get guest memory map Content-Language: en-US To: Henry Wang , CC: Wei Liu , Anthony PERARD , "Juergen Gross" , Andrew Cooper , "George Dunlap" , Jan Beulich , "Julien Grall" , Stefano Stabellini , "Bertrand Marquis" , Volodymyr Babchuk , Alec Kwapis References: <20240308015435.4044339-1-xin.wang2@amd.com> <20240308015435.4044339-4-xin.wang2@amd.com> From: Michal Orzel In-Reply-To: <20240308015435.4044339-4-xin.wang2@amd.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Received-SPF: None (SATLEXMB03.amd.com: michal.orzel@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CY4PEPF0000E9D1:EE_|PH8PR12MB8606:EE_ X-MS-Office365-Filtering-Correlation-Id: d8c5d7bf-6bc0-4d3c-2e25-08dc41ab2ba0 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: /dKsxQzC7B2i/euBkD2qnAfkLtaLxqlJlsXf2t1zkwTzWaUZ3CpBNCkBvuLnIDdjfD19IGC8sP/Y9PW7VFRdd1OTYvtPzSwbEU12cGnu9MoGGMPLaFKTKE4+Fj388bKAxeeJG1NU6W0iQTktFGOOoYlVCM3McWpfMscTpRuohciYj8dhH4qSmYuJIQGuIWYJPKCtNWTXQdwH+vZBYxoeZC807N/gtcN95PbMINvz5UIj+LGY4ZCxgltV0HTButRZIAjOv+xapLj9JFbb/hA15ZAUY7rMgwxGDnwd+3m28A/hu8RxJ8KqwaCcPwyXBNaLXrdJ9B9hK5B4mF3RVoXsevjReukPuAgsCkWILWJXQ15W7WVQN9t99AXKpurHPK1BMvf494k5emgtcMBLhk7ZQGzGRUuOGIdr2a2O22tSdw5tYdWn4+BGcxlXXRRFsTQmNyMlWNBbKeMpVfV/5RaKPu/Pp8NldHZKJyLfEAs37wJusyzfagWVyZJUdL9FzH1876KqfcupgU4RjkOp09bLllHaoAEyGM5z+BqoWUBJI6fh7/z4kLIKVIMrQ8e9fJj/0hm79ko77ximv/lmC+HcaysbcAOq7Kbm23AAxLSVKz4sFWrs5D5LMAFIvFY77HYVy6sddPX3j3Jy2BHVrEYweoP/nRrMuCOUE/fMtmFZqA5N+4IIpendwH0TYbRe5/Tag8vCOIe57YFfbt0MvlldNOR2oVZXchFbRlYFKv5WtZI7JuQ4skmvAdd7oRXuOnp9 X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(1800799015)(7416005)(376005)(36860700004)(82310400014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Mar 2024 09:11:00.5804 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d8c5d7bf-6bc0-4d3c-2e25-08dc41ab2ba0 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CY4PEPF0000E9D1.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR12MB8606 Hi Henry, On 08/03/2024 02:54, Henry Wang wrote: > There are some use cases where the toolstack needs to know the guest > memory map. For example, the toolstack helper application > "init-dom0less" needs to know the guest magic page regions for 1:1 > direct-mapped dom0less DomUs to allocate magic pages. > > To address such needs, add XEN_DOMCTL_get_mem_map hypercall and > related data structures to query the hypervisor for the guest memory > map. The guest memory map is recorded in the domain structure and > currently only guest magic page region is recorded in the guest > memory map. The guest magic page region is initialized at the domain > creation time as the layout in the public header, and it is updated > for 1:1 dom0less DomUs (see the following commit) to avoid conflict > with RAM. > > Take the opportunity to drop an unnecessary empty line to keep the > coding style consistent in the file. > > Reported-by: Alec Kwapis > Signed-off-by: Henry Wang > --- > v2: > - New patch > RFC: I think the newly introduced "struct xen_domctl_mem_map" is > quite duplicated with "struct xen_memory_map", any comment on reuse > the "struct xen_memory_map" for simplicity? > --- > tools/include/xenctrl.h | 4 ++++ > tools/libs/ctrl/xc_domain.c | 32 +++++++++++++++++++++++++++++++ > xen/arch/arm/domain.c | 6 ++++++ > xen/arch/arm/domctl.c | 19 +++++++++++++++++- > xen/arch/arm/include/asm/domain.h | 8 ++++++++ > xen/include/public/arch-arm.h | 4 ++++ > xen/include/public/domctl.h | 21 ++++++++++++++++++++ > 7 files changed, 93 insertions(+), 1 deletion(-) > > diff --git a/tools/include/xenctrl.h b/tools/include/xenctrl.h > index 2ef8b4e054..b25e9772a2 100644 > --- a/tools/include/xenctrl.h > +++ b/tools/include/xenctrl.h > @@ -1195,6 +1195,10 @@ int xc_domain_setmaxmem(xc_interface *xch, > uint32_t domid, > uint64_t max_memkb); > > +int xc_get_domain_mem_map(xc_interface *xch, uint32_t domid, > + struct xen_mem_region mem_regions[], > + uint32_t *nr_regions); > + > int xc_domain_set_memmap_limit(xc_interface *xch, > uint32_t domid, > unsigned long map_limitkb); > diff --git a/tools/libs/ctrl/xc_domain.c b/tools/libs/ctrl/xc_domain.c > index f2d9d14b4d..64b46bdfb4 100644 > --- a/tools/libs/ctrl/xc_domain.c > +++ b/tools/libs/ctrl/xc_domain.c > @@ -697,6 +697,38 @@ int xc_domain_setmaxmem(xc_interface *xch, > return do_domctl(xch, &domctl); > } > > +int xc_get_domain_mem_map(xc_interface *xch, uint32_t domid, > + struct xen_mem_region mem_regions[], > + uint32_t *nr_regions) > +{ > + int rc; > + struct xen_domctl domctl = { > + .cmd = XEN_DOMCTL_get_mem_map, > + .domain = domid, > + .u.mem_map = { > + .nr_mem_regions = *nr_regions, > + }, > + }; > + > + DECLARE_HYPERCALL_BOUNCE(mem_regions, > + sizeof(xen_mem_region_t) * (*nr_regions), > + XC_HYPERCALL_BUFFER_BOUNCE_OUT); > + > + if ( !mem_regions || xc_hypercall_bounce_pre(xch, mem_regions) || > + (*nr_regions) < 1 ) > + return -1; > + > + set_xen_guest_handle(domctl.u.mem_map.buffer, mem_regions); > + > + rc = do_domctl(xch, &domctl); > + > + xc_hypercall_bounce_post(xch, mem_regions); > + > + *nr_regions = domctl.u.mem_map.nr_mem_regions; > + > + return rc; > +} > + > #if defined(__i386__) || defined(__x86_64__) > int xc_domain_set_memory_map(xc_interface *xch, > uint32_t domid, > diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c > index 5e7a7f3e7e..54f3601ab0 100644 > --- a/xen/arch/arm/domain.c > +++ b/xen/arch/arm/domain.c > @@ -696,6 +696,7 @@ int arch_domain_create(struct domain *d, > { > unsigned int count = 0; > int rc; > + struct mem_map_domain *mem_map = &d->arch.mem_map; > > BUILD_BUG_ON(GUEST_MAX_VCPUS < MAX_VIRT_CPUS); > > @@ -785,6 +786,11 @@ int arch_domain_create(struct domain *d, > d->arch.sve_vl = config->arch.sve_vl; > #endif > > + mem_map->regions[mem_map->nr_mem_regions].start = GUEST_MAGIC_BASE; You don't check for exceeding max number of regions. Is the expectation that nr_mem_regions is 0 at this stage? Maybe add an ASSERT here. > + mem_map->regions[mem_map->nr_mem_regions].size = GUEST_MAGIC_SIZE; > + mem_map->regions[mem_map->nr_mem_regions].type = GUEST_MEM_REGION_MAGIC; > + mem_map->nr_mem_regions++; > + > return 0; > > fail: > diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c > index ad56efb0f5..92024bcaa0 100644 > --- a/xen/arch/arm/domctl.c > +++ b/xen/arch/arm/domctl.c > @@ -148,7 +148,6 @@ long arch_do_domctl(struct xen_domctl *domctl, struct domain *d, > > return 0; > } > - > case XEN_DOMCTL_vuart_op: > { > int rc; > @@ -176,6 +175,24 @@ long arch_do_domctl(struct xen_domctl *domctl, struct domain *d, > > return rc; > } > + case XEN_DOMCTL_get_mem_map: > + { > + int rc; Without initialization, what will be the rc value on success? > + /* > + * Cap the number of regions to the minimum value between toolstack and > + * hypervisor to avoid overflowing the buffer. > + */ > + uint32_t nr_regions = min(d->arch.mem_map.nr_mem_regions, > + domctl->u.mem_map.nr_mem_regions); > + > + if ( copy_to_guest(domctl->u.mem_map.buffer, > + d->arch.mem_map.regions, > + nr_regions) || > + __copy_to_guest(u_domctl, domctl, 1) ) In domctl.h, you wrote that nr_regions is IN/OUT but you don't seem to write back the actual number of regions. > + rc = -EFAULT; > + > + return rc; > + } > default: > return subarch_do_domctl(domctl, d, u_domctl); > } > diff --git a/xen/arch/arm/include/asm/domain.h b/xen/arch/arm/include/asm/domain.h > index f1d72c6e48..a559a9e499 100644 > --- a/xen/arch/arm/include/asm/domain.h > +++ b/xen/arch/arm/include/asm/domain.h > @@ -10,6 +10,7 @@ > #include > #include > #include > +#include > #include > > struct hvm_domain > @@ -59,6 +60,11 @@ struct paging_domain { > unsigned long p2m_total_pages; > }; > > +struct mem_map_domain { > + unsigned int nr_mem_regions; > + struct xen_mem_region regions[XEN_MAX_MEM_REGIONS]; > +}; > + > struct arch_domain > { > #ifdef CONFIG_ARM_64 > @@ -77,6 +83,8 @@ struct arch_domain > > struct paging_domain paging; > > + struct mem_map_domain mem_map; > + > struct vmmio vmmio; > > /* Continuable domain_relinquish_resources(). */ > diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h > index a25e87dbda..a06eaf2dab 100644 > --- a/xen/include/public/arch-arm.h > +++ b/xen/include/public/arch-arm.h > @@ -420,6 +420,10 @@ typedef uint64_t xen_callback_t; > * should instead use the FDT. > */ > > +/* Guest memory region types */ > +#define GUEST_MEM_REGION_DEFAULT 0 What's the purpose of this default type? It seems unusued. > +#define GUEST_MEM_REGION_MAGIC 1 > + > /* Physical Address Space */ > > /* Virtio MMIO mappings */ > diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h > index a33f9ec32b..77bf999651 100644 > --- a/xen/include/public/domctl.h > +++ b/xen/include/public/domctl.h > @@ -946,6 +946,25 @@ struct xen_domctl_paging_mempool { > uint64_aligned_t size; /* Size in bytes. */ > }; > > +#define XEN_MAX_MEM_REGIONS 1 The max number of regions can differ between arches. How are you going to handle it? ~Michal From xen-devel-bounces@lists.xenproject.org Mon Mar 11 09:46:19 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 09:46:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691340.1077222 (Exim 4.92) (envelope-from ) id 1rjcEX-0005Yl-7y; Mon, 11 Mar 2024 09:46:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691340.1077222; Mon, 11 Mar 2024 09:46:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjcEX-0005Ye-5L; Mon, 11 Mar 2024 09:46:13 +0000 Received: by outflank-mailman (input) for mailman id 691340; Mon, 11 Mar 2024 09:46:11 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjcEV-0005YW-P9 for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 09:46:11 +0000 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on20601.outbound.protection.outlook.com [2a01:111:f403:2415::601]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 2f3f6f4d-df8c-11ee-a1ee-f123f15fe8a2; Mon, 11 Mar 2024 10:46:08 +0100 (CET) Received: from DS7PR05CA0036.namprd05.prod.outlook.com (2603:10b6:8:2f::25) by MW4PR12MB7120.namprd12.prod.outlook.com (2603:10b6:303:222::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.35; Mon, 11 Mar 2024 09:46:05 +0000 Received: from DS1PEPF0001709C.namprd05.prod.outlook.com (2603:10b6:8:2f:cafe::73) by DS7PR05CA0036.outlook.office365.com (2603:10b6:8:2f::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.17 via Frontend Transport; Mon, 11 Mar 2024 09:46:05 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by DS1PEPF0001709C.mail.protection.outlook.com (10.167.18.106) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7386.12 via Frontend Transport; Mon, 11 Mar 2024 09:46:04 +0000 Received: from SATLEXMB08.amd.com (10.181.40.132) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Mon, 11 Mar 2024 04:46:04 -0500 Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB08.amd.com (10.181.40.132) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Mon, 11 Mar 2024 02:46:04 -0700 Received: from [10.65.148.173] (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend Transport; Mon, 11 Mar 2024 04:46:01 -0500 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 2f3f6f4d-df8c-11ee-a1ee-f123f15fe8a2 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gFnQI3yypiCq/eX47VxOoJ/pDaSQ0bn5Pqs8Oqs7cyiL/iVHUhIf7P3t6ppY54pjuAvt25uYj00utgCT27dg13PdrFtDvBIeE/dSSrEen7O/TUnBkjU0weTV5zK26lM7W2t/AODX/XKXQPNNLePxpaZ7WklmK6n1Rw61/Xtr2SYA/UkHBKuFWm7VDlSbd3qUjHvNVJxgOrma4M42fYFslo6K3m5msnk8XxOeNFUrnEvmikDv+motTJX/4/dzAXutx+oc3e1+wIz8UXSWi2p5MjOFsWuImcelmHkkZLvYemGUxtJ3J7sT11hnDfquHEJhKc0psyFOiA/ajyLa9ejskg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=dimKD9WEZ+AXOmV4JiStlxQSYUnWW7h85oCYHLBQvBQ=; b=P4D9eynklWJXXDsyPWYg6qHSt38dP1RCayInkE7zuWrBCC42oQsf6tHixa6sQEMAiPnVn6phJWzI7Z96p0FgatoxUsSPenL142B5CJeNZ6aPcoss6pZXu6zq+4W+U38M8xDy4WeDMFzeLoGv6KZxfAp0N2jsXLZJPMwqh5mHnaNlScrCVAhSOQ2czOyDNETQ2Lk2S29fg4ohSYqkYsk1gnZr3yn1Qn5a1WCs32pSRnorhpLYovJU1S3UpP6chfg79FneOUWX/vt4WVJq5QOWizZbQSJ4uJZHFsJFr79MZPDACLuUo+3hX1pVqsodADe5+obr5N5ZOumVRJ/cjyDfOQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dimKD9WEZ+AXOmV4JiStlxQSYUnWW7h85oCYHLBQvBQ=; b=v33Fm26CVc62xddAIwQwtn6su5/L2y8KHPlm/yjYhdwDHVAF9xH9905YRRUSt8il88bua4kmYn3DXj/WFTXYSltAIw0iSTGyJh0J0sNnbFMlkPAoTMu5mEc82GYcKEBheweENx5TeZFhQ/TX1bCQPkx2msC6+DMRtydKn58A42s= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C Message-ID: <6c53d4fc-638e-4f88-b25f-8d71065c8984@amd.com> Date: Mon, 11 Mar 2024 17:46:00 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 3/5] xen/domctl, tools: Introduce a new domctl to get guest memory map To: Michal Orzel , CC: Wei Liu , Anthony PERARD , "Juergen Gross" , Andrew Cooper , "George Dunlap" , Jan Beulich , "Julien Grall" , Stefano Stabellini , Bertrand Marquis , Volodymyr Babchuk , Alec Kwapis References: <20240308015435.4044339-1-xin.wang2@amd.com> <20240308015435.4044339-4-xin.wang2@amd.com> Content-Language: en-US From: Henry Wang In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS1PEPF0001709C:EE_|MW4PR12MB7120:EE_ X-MS-Office365-Filtering-Correlation-Id: 63121bf9-77bf-44ca-7169-08dc41b011ea X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: k9zxBKPH44fZ4jnEv4TB+jEI+TKw0bxyJAnHnNkq0zYMwxrnev1tr8Q2va/V4AneXCvYBa5byf8te09JMf6A3aWXlyjgKwRQPiVzxrjSH2dzpBgw6A5vDub5xtzRUyVVVQiaqcH036wXDEbnQXhBDkDnGFiEBMozdMk9Vdt+DYBtv8VbA1A07qWwJJZVc2rMEDRaB62YMKrQDGf28wA2LUxmXVR4NI+ZH2LI2//hfCPQAZq1npv9jdXCX5yuMp9ep1BZiOw7tFlWi7zovafR+nzBJTELiXrXC/ZNE17kvGL9EW3c2ZQH1XKxHeXgXHET/ZKCLVtqc7lHgQqohW7T5aj72BnUQBOZPEnzjcuU44rZMqiYEEwZY8B1oaWhG7oBQbUoOddfCpTtvbcldA4hSB4WYllUhC6AjI4T7zcu0AFgAEzvm3qoGEXTI/bpZ/6Upp6HVcsBG68mrfFz7ejAo10XuN5OMPyxZVt0fWLRqB/zbFC92Nm378a6aVhfD3vdz4eG5g5uydT7vL4IA1zR20yUaUR2wzKLS3vADOmQ7IAdr2t9HZw+u0zfNr9SBmuRB0jp7ySnJmfgxROhHOr/18yJ8hOTvZk3EE2L8C1pwutJLCxZq85ms5a5oW36swH08feI5oJ7bJLtSQ9fTWqMAgMMkTASriEcsz66kduAGlL3TC1LRtje0W1aHotILThzgKvxNI1zXwuyP5O9hngzqeLKaTs1ubTCcOa7mcNe3aQXLinWOkKgr2ifvEeezCVy X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(36860700004)(7416005)(82310400014)(1800799015)(376005);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Mar 2024 09:46:04.9456 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 63121bf9-77bf-44ca-7169-08dc41b011ea X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: DS1PEPF0001709C.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR12MB7120 Hi Michal, On 3/11/2024 5:10 PM, Michal Orzel wrote: > Hi Henry, > > diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c > index 5e7a7f3e7e..54f3601ab0 100644 > --- a/xen/arch/arm/domain.c > +++ b/xen/arch/arm/domain.c > @@ -696,6 +696,7 @@ int arch_domain_create(struct domain *d, > { > unsigned int count = 0; > int rc; > + struct mem_map_domain *mem_map = &d->arch.mem_map; > > BUILD_BUG_ON(GUEST_MAX_VCPUS < MAX_VIRT_CPUS); > > @@ -785,6 +786,11 @@ int arch_domain_create(struct domain *d, > d->arch.sve_vl = config->arch.sve_vl; > #endif > > + mem_map->regions[mem_map->nr_mem_regions].start = GUEST_MAGIC_BASE; > You don't check for exceeding max number of regions. Is the expectation that nr_mem_regions > is 0 at this stage? Maybe add an ASSERT here. Sure, I will add the checking. >> + mem_map->regions[mem_map->nr_mem_regions].size = GUEST_MAGIC_SIZE; >> + mem_map->regions[mem_map->nr_mem_regions].type = GUEST_MEM_REGION_MAGIC; >> + mem_map->nr_mem_regions++; >> + >> return 0; >> >> fail: >> diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c >> index ad56efb0f5..92024bcaa0 100644 >> --- a/xen/arch/arm/domctl.c >> +++ b/xen/arch/arm/domctl.c >> @@ -148,7 +148,6 @@ long arch_do_domctl(struct xen_domctl *domctl, struct domain *d, >> >> return 0; >> } >> - >> case XEN_DOMCTL_vuart_op: >> { >> int rc; >> @@ -176,6 +175,24 @@ long arch_do_domctl(struct xen_domctl *domctl, struct domain *d, >> >> return rc; >> } >> + case XEN_DOMCTL_get_mem_map: >> + { >> + int rc; > Without initialization, what will be the rc value on success? Thanks for catching this (and the copy back issue below). I made a silly mistake here and didn't catch it as I also missed checking the rc in the toolstack side...I will fix both side. >> + /* >> + * Cap the number of regions to the minimum value between toolstack and >> + * hypervisor to avoid overflowing the buffer. >> + */ >> + uint32_t nr_regions = min(d->arch.mem_map.nr_mem_regions, >> + domctl->u.mem_map.nr_mem_regions); >> + >> + if ( copy_to_guest(domctl->u.mem_map.buffer, >> + d->arch.mem_map.regions, >> + nr_regions) || >> + __copy_to_guest(u_domctl, domctl, 1) ) > In domctl.h, you wrote that nr_regions is IN/OUT but you don't seem to write back the actual number > of regions. Thanks. Added "domctl->u.mem_map.nr_mem_regions = nr_regions;" locally. >> +/* Guest memory region types */ >> +#define GUEST_MEM_REGION_DEFAULT 0 > What's the purpose of this default type? It seems unusued. I added it because struct arch_domain (or we should say struct domain) is zalloc-ed. So the default type field in struct xen_mem_region is 0. Otherwise we may (mistakenly) define a region type as 0 and lead to mistakes. >> +#define GUEST_MEM_REGION_MAGIC 1 >> + >> /* Physical Address Space */ >> >> /* Virtio MMIO mappings */ >> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h >> index a33f9ec32b..77bf999651 100644 >> --- a/xen/include/public/domctl.h >> +++ b/xen/include/public/domctl.h >> @@ -946,6 +946,25 @@ struct xen_domctl_paging_mempool { >> uint64_aligned_t size; /* Size in bytes. */ >> }; >> >> +#define XEN_MAX_MEM_REGIONS 1 > The max number of regions can differ between arches. How are you going to handle it? I think we can add ``` #ifndef XEN_MAX_MEM_REGIONS #define XEN_MAX_MEM_REGIONS 1 #endif ``` here and define the arch specific XEN_MAX_MEM_REGIONS in public/arch-*.h. I will fix this in v3. Kind regards, Henry > ~Michal From xen-devel-bounces@lists.xenproject.org Mon Mar 11 09:51:22 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 09:51:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691344.1077232 (Exim 4.92) (envelope-from ) id 1rjcJR-0007Fp-UQ; Mon, 11 Mar 2024 09:51:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691344.1077232; Mon, 11 Mar 2024 09:51:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjcJR-0007Fi-RR; Mon, 11 Mar 2024 09:51:17 +0000 Received: by outflank-mailman (input) for mailman id 691344; Mon, 11 Mar 2024 09:51:16 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjcJQ-0007Fa-S3 for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 09:51:16 +0000 Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [2a00:1450:4864:20::62c]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id e64f7c47-df8c-11ee-a1ee-f123f15fe8a2; Mon, 11 Mar 2024 10:51:14 +0100 (CET) Received: by mail-ej1-x62c.google.com with SMTP id a640c23a62f3a-a45ecef71deso305197266b.2 for ; Mon, 11 Mar 2024 02:51:14 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id wk8-20020a170907054800b00a46021ef90csm2434146ejb.107.2024.03.11.02.51.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Mar 2024 02:51:14 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e64f7c47-df8c-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1710150674; x=1710755474; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=cjw1qo3T7OGwuTk84hXD8wjyH/8ueDiGizGMBQp+aGQ=; b=Y6XH9/2HRZRoHYrCMGWISeBvxFcoSVBovnLrSIZEfl1XufgMRERhlII5dRe6L6PbV9 k7197LbKStjIxdUAoYQIMlJRc4h7Tj5DIwF2zoPDoTcl/nX7DXetMYLN40pPrL0l3QbI AglhCbRWJ/ccoAkn4vy81T+QyRQa+EK7IUSpU/vTIUbB6leT4R6APv/9u7AoqCzBr+SY P7Nk9jM8sNhm2lpzHu0G4Kcb3yURVF4xAtgFCwUg3iuPB9+jQag2ubUXR7xyzBIo0Qbh za9RNDTDnskquHEk30Gwf2tH2YeqMCuRdgmLhLaxmc35/0xmcO4q2VNF+nd3LKgzi5jJ GCyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710150674; x=1710755474; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=cjw1qo3T7OGwuTk84hXD8wjyH/8ueDiGizGMBQp+aGQ=; b=lRQ05OVc65utxL7ayd0xrOVc3Ld1fgflLg9BID/HNrFExPPlvv0R7l5+Mm4yT6feGj hjM4I62byyiaSEIXJycEicMO8A7Dy67QKfTHgpopRbKpDitGjqHOS3CEpE43O9Mc20ST ruAXlQRN/DYLHIwkYS983tqERPx6bMD1cvZ7nDQXkEUVDNGeEZ3cOBZtNTzr/wrLilP6 pnaKx2+72MOG5RuoBJsYXOH9l44kLjy2/diPOfC+OrD3vdhUCyrWmYAq/EcBIyUl3/Zg 8BJuzUC/Di/urm+ItZxyDDAr782S9iWlH0iK6FRY31IBgpZd73oziHF2fNnCjvEIuexP sAlQ== X-Forwarded-Encrypted: i=1; AJvYcCXNGIh60SYlJgDBqTvfp5HWBJz8TzH2+vOYPV8SifRnXcB7obyvpu/heo/ffJR/X7mxjYRLT0WBByw9wukxwGUp2zZXmLBRo/8wSqwokFA= X-Gm-Message-State: AOJu0YwioTl9Qa5zcVzVai6CJ73nnpiOXHIf/TGw1mAn+PanGHZTnS/o 1BXtdyKLsR89ykmXaqcZX1KiXqEBl8Me+o6N0MTu+TxGPla19tx1p4QtzSxsaQ== X-Google-Smtp-Source: AGHT+IElfjJDp4q7VIQduRqcTYK67XilJNwZdAqIIGWtHzqPXHZJn1/lD24bPQc/bX8Rmgat1tKdNQ== X-Received: by 2002:a17:906:16d7:b0:a45:5bc1:ac35 with SMTP id t23-20020a17090616d700b00a455bc1ac35mr3447494ejd.30.1710150674312; Mon, 11 Mar 2024 02:51:14 -0700 (PDT) Message-ID: <874fc4f8-f862-4fa7-b436-dd1420d010a7@suse.com> Date: Mon, 11 Mar 2024 10:51:15 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH] xen/evtchn: address violations of MISRA C:2012 Rules 16.3 and 16.4 Content-Language: en-US To: Federico Serafini , Stefano Stabellini Cc: consulting@bugseng.com, Andrew Cooper , George Dunlap , Julien Grall , Wei Liu , xen-devel@lists.xenproject.org References: <3ec419e30227a8016c28e04524cd36a549aaddcf.1709898466.git.federico.serafini@bugseng.com> <602c2da1-d5ab-4120-ab19-37e75820d129@bugseng.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <602c2da1-d5ab-4120-ab19-37e75820d129@bugseng.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 11.03.2024 10:02, Federico Serafini wrote: > On 11/03/24 08:40, Jan Beulich wrote: >> On 08.03.2024 12:51, Federico Serafini wrote: >>> --- a/xen/common/event_channel.c >>> +++ b/xen/common/event_channel.c >>> @@ -130,9 +130,12 @@ static bool virq_is_global(unsigned int virq) >>> >>> case VIRQ_ARCH_0 ... VIRQ_ARCH_7: >>> return arch_virq_is_global(virq); >>> + >>> + default: >>> + ASSERT(virq < NR_VIRQS); >>> + break; >>> } >>> >>> - ASSERT(virq < NR_VIRQS); >>> return true; >>> } >> >> Just for my understanding: The ASSERT() is moved so the "default" would >> consist of more than just "break". Why is it that then the "return" isn't >> moved, too? > > No reason in particular. > If preferred, I can move it too. I for one would prefer that, yes. But what's needed up front is that we decide what we want to do _consistently_ in all such cases. >>> @@ -1672,6 +1676,9 @@ static void domain_dump_evtchn_info(struct domain *d) >>> case ECS_VIRQ: >>> printk(" v=%d", chn->u.virq); >>> break; >>> + default: >>> + /* Nothing to do in other cases. */ >>> + break; >>> } >> >> Yes this, just to mention it, while in line with what Misra demands is >> pretty meaningless imo: The absence of "default" says exactly what the >> comment now says. FTAOD - this is a comment towards the Misra guideline, >> not so much towards the specific change here. > > Both you and Stefano reviewed the code and agreed on the fact that doing > nothing for the default case is the right thing and now the code > explicitly says that without letting any doubts. > Furthermore, during the reviews it could happen that you notice a switch > where something needs to be done for the default case. That shouldn't happen during review. Anyone proposing a patch to add such a comment wants to first have made sure the comment is actually applicable there. Otherwise we're in "mechanically add comments" territory, which I think we all agreed we want to avoid. Jan From xen-devel-bounces@lists.xenproject.org Mon Mar 11 10:00:05 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 10:00:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691349.1077242 (Exim 4.92) (envelope-from ) id 1rjcRs-00088e-N1; Mon, 11 Mar 2024 10:00:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691349.1077242; Mon, 11 Mar 2024 10:00:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjcRs-00088X-KR; Mon, 11 Mar 2024 10:00:00 +0000 Received: by outflank-mailman (input) for mailman id 691349; Mon, 11 Mar 2024 09:59:59 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjcRr-00088P-5s for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 09:59:59 +0000 Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [2a00:1450:4864:20::536]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 1e201384-df8e-11ee-afdc-a90da7624cb6; Mon, 11 Mar 2024 10:59:58 +0100 (CET) Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-55a5e7fa471so3391071a12.1 for ; Mon, 11 Mar 2024 02:59:58 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id cq15-20020a056402220f00b0056761c83bdesm2768225edb.93.2024.03.11.02.59.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Mar 2024 02:59:57 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1e201384-df8e-11ee-afdc-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1710151197; x=1710755997; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=njDdIhoPqBZTh60yJEisQtVCv8xuKwPRrDCjbBuHbEE=; b=RdntzaVqgtujZgXLPbY9W7aX++Jb+7tl++mdUBee+PKP99curvU47n9W8kbjnkFa0w dr2+9fz4ipSaa6iDnQg4lTTexRJI11acqG5lNZVH21Wk4uPMHc+veRoT19UOBqvaz48M 1me1OOR6XWFa/TypZPCHjA63fYGpp5LXo3eEZ7btUI+j21bhIekEG3FULWwOvfhS3D+J nFm8gd2Bb7jWmkYGDiTm6AvFj8Jvm8BHgRjaWe0Hv0XagylvAABaUxIklglsMtPD3/bB mcZ/311iQc0TYlN9G0/L32wB17hkQoi3yU5WYa7K1oAVX0U068T33UnJRDseS5AHkOX1 NBPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710151197; x=1710755997; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=njDdIhoPqBZTh60yJEisQtVCv8xuKwPRrDCjbBuHbEE=; b=ntn9sQTV/LFeg9ECXuhUpXLJYIQGDfIAWmw3KqMotWHJqJ1Mvq5YF0KY0VfnhBbD/t p5ghBuElVo9QQt28ZH/5MJomdDctU4Q30hkhF1AKFzexjwj1bXwgiOKuBzr939drHVvg F7OFsCFckAIwSFUXMG4Py1QZACieL6krpnobrCqCNEIjJq8/eL9i4WsRVQ7MBDniDHoX 05TsIs+sjROI0Z4W6NxqHpNiFz0YUG1s/V3qdbvTbDefULeb3pXL+0W71kZNUxxG3aUy XjhrdYniGBOg3y1tCayt6/am02BluPdM9UsRtTR9bJbw7wJzVAmn9xfO1J/O+3puTqai 6ciA== X-Forwarded-Encrypted: i=1; AJvYcCXvek+gPHZc1LsDQMQsa7xYutsfylqY0sgMtv+xooaAnBg2FnLWwOC2SozBIh+flWHEEZBOuyal8aaxuW7c8dvHh9CsbsHfexbT+fTCjbY= X-Gm-Message-State: AOJu0Yz1zsP25cEiJXK79KxXC7mzSYKA6w+jDYl51kuyBru2ehZgNOS6 USfQXSLBl8z1zTbgstmTxErupDFhVIYP/pEQB17hLCrW6ftA0mRWPwk0O/gsfQ== X-Google-Smtp-Source: AGHT+IGXP0mS1rcBOG+TIYfcyljwRC7NyYxNvyayzFfGgNXHBrfAmtW+C2NSw7BTSq4BN5Mmx11mgA== X-Received: by 2002:a05:6402:5c3:b0:568:13f5:81eb with SMTP id n3-20020a05640205c300b0056813f581ebmr3820946edx.38.1710151197497; Mon, 11 Mar 2024 02:59:57 -0700 (PDT) Message-ID: Date: Mon, 11 Mar 2024 10:59:58 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH v3 00/16] xen: address violation of MISRA C:2012 Directive 4.10 Content-Language: en-US To: Simone Ballarin Cc: consulting@bugseng.com, sstabellini@kernel.org, Andrew Cooper , George Dunlap , Julien Grall , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Doug Goldstein , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , xen-devel@lists.xenproject.org References: From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 11.03.2024 09:59, Simone Ballarin wrote: > The Xen sources contain violations of MISRA C:2012 Directive 4.10 whose headline states: > "Precautions shall be taken in order to prevent the contents of a header file > being included more than once". > > As stated in v2, the following naming convention has been estabilished: > - arch/.../include/asm/ headers -> ASM__H > - private headers -> __H > - asm-generic headers -> ASM_GENERIC__H > > Since there would have been conflicting guards between architectures (which is a violation > of the directive), Why would this be a violation? The two sets of headers aren't use together, and any scan should only point out collisions in what's actively used, I'd hope. > there has been a need for ASM headers to specify if the inclusion guard > referred to ARM or X86. Hence it has been decided to adopt instead: > - arch//include/asm//.h -> ASM____H > > The subdir used is the smallest possible to avoid collisions. For example, it has been > observed that in "xen/arch/arm/include/asm/arm32" and "xen/arch/arm/include/asm/arm64" there > are plenty of header files with the same name, hence _ARMxx_ was added as subdirectory. Why couldn't _ together be ARMxx there, allowing us to get away with one less name component. > There has been a need to define a standard for generated headers too: > - include/generated//.h-> GENERATED___H > - arch//include/generated/asm/.h-> _GENERATED_ASM__H > > To summarize, here are all the rules that have been applied: > - private headers -> __H And here is the full path? I thought I had indicated before that this is going to lead to excessively long identifiers. > - asm-generic headers -> ASM_GENERIC__H > - arch//include/asm//.h -> ASM____H > - include/generated//.h-> GENERATED___H > - arch//include/generated/asm/.h-> _GENERATED_ASM__H And _ASM_ is merely a precaution for stuff appearing outside of asm/ (which doesn't seem very likely)? Jan From xen-devel-bounces@lists.xenproject.org Mon Mar 11 10:02:11 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 10:02:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691353.1077252 (Exim 4.92) (envelope-from ) id 1rjcTy-0001G2-3U; Mon, 11 Mar 2024 10:02:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691353.1077252; Mon, 11 Mar 2024 10:02:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjcTx-0001Fv-Vc; Mon, 11 Mar 2024 10:02:09 +0000 Received: by outflank-mailman (input) for mailman id 691353; Mon, 11 Mar 2024 10:02:08 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjcTw-0001Fn-Jk for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 10:02:08 +0000 Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [2a00:1450:4864:20::635]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 6b6466cb-df8e-11ee-afdc-a90da7624cb6; Mon, 11 Mar 2024 11:02:07 +0100 (CET) Received: by mail-ej1-x635.google.com with SMTP id a640c23a62f3a-a44ad785a44so348614966b.3 for ; Mon, 11 Mar 2024 03:02:07 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id fx3-20020a170906b74300b00a4380e85e5csm2694420ejb.202.2024.03.11.03.02.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Mar 2024 03:02:06 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6b6466cb-df8e-11ee-afdc-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1710151327; x=1710756127; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=qbg+vF7i72557q4DEOv0RK5/78u1N0LCfCUG3/X9Hlc=; b=Hohm33CR08NIau6PTuyM2DeJkXsZ6IZPQS3hLeclxMUbdbsTqrZERDqtKXRcGjMzgS 44q8+fG62GMsw5gRauWA9UGjrOtDQcYonX8KK2/XOX46zOxMZ/5xvXrKmKNIFyw6gpmV MbZiAJLpqFTRB9gok2O7gUyHtFIX3BGi9u/F/iKKRyGOi97wfsjUM3geHy+a1NB7h1Kj N9pw0tuNjvBWSM2qA1NIbArADZIB+oCGZVe1ZyTj80KUGkg7b/G7JmXxhe8Ur1QXkxnl zi0fACYI2TEn8QqrKUFofBh9cqeEQpMT1wBlN/e3CiY5/B8Ysofak9JnmT0GMAPaMDrh qQqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710151327; x=1710756127; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=qbg+vF7i72557q4DEOv0RK5/78u1N0LCfCUG3/X9Hlc=; b=vbBnOQWYEy0S7kLhUGdwpul/rEd/TsbT3dBldpR1k6SlixmehUSOITjc43OEjEEPDF 5CjryyH+3Um75OLHqc6WAUHux0MWrByyPUtZRDLNxB1mZd8gtvt7BtUC34y9OluoRcWi FNkpgRtaKR9JQ9jc+wOttXQKXovZS0hpR/vZvT1TTds4lYrkCVgAVR0zdQ7r5fNKPV5k vBJvo9c5Eo0jtgWZcAh4G7FREaEbKK9XbPNVYogG2g0s7c9qM/Fz6geJ8rKd2+Jv/ejQ UQ1aVOCNLliBbGk3V0OuvC/qzN+RrVCLCKT039EhlXwnYF/abox37F7gasYczFTQRn3Q oKrA== X-Forwarded-Encrypted: i=1; AJvYcCUom+7YHp/C+gD61frXkumfVoI+WfoiavAybVAoOc2cMJdxh/DUOyfCrQ0JZThQsS92l6s9dDim4fhtyEuwkm1LKb49Mn2IOQY1sBjazfk= X-Gm-Message-State: AOJu0YyFD6fVkYxUGOCCirgslvH7GLAqvZCPRySE4M+zp1XFADDzxXF9 VhGggkMDwM/hah3AGnlWki6qIcIj90M5OS3kPagQCTyUTUjG5I2p/ryKNLWDefSIWMcMx9T8U9E = X-Google-Smtp-Source: AGHT+IEeDrQduDtSQsmtJ852fLDutA1VfLEa0Kl36lYhEk1p6XjIVPeUNxvtTMkoRRIwBn8mYqE2Ug== X-Received: by 2002:a17:906:6897:b0:a45:a2cc:eb8b with SMTP id n23-20020a170906689700b00a45a2cceb8bmr3445154ejr.13.1710151327159; Mon, 11 Mar 2024 03:02:07 -0700 (PDT) Message-ID: Date: Mon, 11 Mar 2024 11:02:07 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH v3 01/16] misra: add deviation for headers that explicitly avoid guards Content-Language: en-US To: Simone Ballarin Cc: consulting@bugseng.com, sstabellini@kernel.org, Andrew Cooper , George Dunlap , Julien Grall , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <310fe4a0ccd0ad45bcf1cd9811ac56c9a560dd0b.1710145041.git.simone.ballarin@bugseng.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <310fe4a0ccd0ad45bcf1cd9811ac56c9a560dd0b.1710145041.git.simone.ballarin@bugseng.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 11.03.2024 09:59, Simone Ballarin wrote: > Some headers, under specific circumstances (documented in a comment at > the beginning of the file), explicitly avoid inclusion guards: the caller > is responsible for including them correctly. > > These files are not supposed to comply with Directive 4.10: > "Precautions shall be taken in order to prevent the contents of a header > file being included more than once" > > This patch adds deviation cooments for headers that avoid guards. > > Signed-off-by: Simone Ballarin > > --- > Changes in v3: > - fix inconsistent deviation ID > - change comment-based deviation text > Changes in v2: > - use the format introduced with doc/misra/safe.json instead of > a generic text-based deviation > --- > docs/misra/safe.json | 9 +++++++++ > xen/include/public/arch-x86/cpufeatureset.h | 1 + > xen/include/public/errno.h | 1 + > 3 files changed, 11 insertions(+) I understand something wants doing, but having such comments appear in public headers feels wrong to me. I'm afraid I have no good alternative suggestion. Jan From xen-devel-bounces@lists.xenproject.org Mon Mar 11 10:08:57 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 10:08:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691357.1077262 (Exim 4.92) (envelope-from ) id 1rjcaT-00021G-KG; Mon, 11 Mar 2024 10:08:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691357.1077262; Mon, 11 Mar 2024 10:08:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjcaT-000219-HZ; Mon, 11 Mar 2024 10:08:53 +0000 Received: by outflank-mailman (input) for mailman id 691357; Mon, 11 Mar 2024 10:08:53 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjcaT-000213-05 for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 10:08:53 +0000 Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [2a00:1450:4864:20::52d]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 5ba74645-df8f-11ee-a1ee-f123f15fe8a2; Mon, 11 Mar 2024 11:08:50 +0100 (CET) Received: by mail-ed1-x52d.google.com with SMTP id 4fb4d7f45d1cf-563c595f968so5013307a12.0 for ; Mon, 11 Mar 2024 03:08:50 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id j14-20020a170906474e00b00a44adc01f13sm2697155ejs.196.2024.03.11.03.08.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Mar 2024 03:08:49 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 5ba74645-df8f-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1710151730; x=1710756530; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=KUHS0hw5GthlB6BizdBU0xbbpqvs867SBrZ9HQhcCdQ=; b=E0VQHxS6MavwVsm538mM4nKhApZXLfSZ8Ba/IWZ+YIa+oWSKiDKOONaa+mOM1sU+gd fLEZ1RXGQiK/Nc8rPGl2GACKvK1gjvWgmKYmgXsXUyYYmzp+I1vRFgCCAlZiIvL70XhC Vn46TEyClYmJ4cJAPgO38ZP8x2Ra7XrFB44Wt7WLAazRj0KM+QfbQzaev1jBz7pk1OoD 94mZ8C6VOiOL0P59QjUkcfCv/h9i43omd9DD/te1e3OOLCAhbH7tcnvTh03hU9vwP11z v36zdYnE0lKfPU1zsdvJo3LZPbkOWtqXZLSLH6E8bIn/RRnXIuWrVYtv/h1yGwX6orQJ hXLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710151730; x=1710756530; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=KUHS0hw5GthlB6BizdBU0xbbpqvs867SBrZ9HQhcCdQ=; b=hiDxyT7/4o0ZiODAdJ9c29ucleByk2oT6X+Fn/uuINlqB+Ieem8a8DVr3vF5qKfEtH bhVZYYnQAhjVg0gOaGqGtlArI8QE6Tbg7h8E5l2uEXzbwiHx1NDfQYlwChirzdNKBvdg nWlRxayv9GTtqL6BcEtbu7Vv20zuQYvET5QzliNE+TIP0MJEM/iB1DRKTMq9lt4wfOS1 YngiqNJ1S81JXF1kfZjEcyJLBD3Sp4odYVr7uvxsdHT+HR7nzLgJoJLs2WxklM7c7EKJ oVTgOlqiNjtyxpSBLk463nMQ/OeJbfenO/vTyp3W8X82ssJWLQ9IrhXjWh0QNG2d6oaP wvgA== X-Forwarded-Encrypted: i=1; AJvYcCWJ5fnn7hFjkEhINLL1CE3ghVZSSorXZqEVaIFS0Dxk1+YV3RzJaxTg3FGzie+ap6vBB4QSCZTLie7R++v+N3S3c/mRkY8xO2mgRx/8cuk= X-Gm-Message-State: AOJu0YxTBLIRKaklH+H2zzyHRm/m13Rd3AcwicikjHzkptyKx9d+kv4F n+3ZNEy8Nm5m00GRrJ/ORTKr2r+9mDzi/FvDS8DFqU4KHtX+HyOZ5qSBt8SAhA== X-Google-Smtp-Source: AGHT+IHKWlkOLJ0nPqpfDdjciCyKEVyTDO/m+Cfo6buab+FqcKBTPUwvAQ1nd/M0/jFNcIxRNceWhQ== X-Received: by 2002:a17:907:8743:b0:a46:27ac:b954 with SMTP id qo3-20020a170907874300b00a4627acb954mr1610930ejc.54.1710151730195; Mon, 11 Mar 2024 03:08:50 -0700 (PDT) Message-ID: Date: Mon, 11 Mar 2024 11:08:50 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH v3 03/16] misra: add deviations for direct inclusion guards Content-Language: en-US To: Simone Ballarin Cc: consulting@bugseng.com, sstabellini@kernel.org, Andrew Cooper , George Dunlap , Julien Grall , Wei Liu , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <1fdfec12fd2207c294f50d01d8ec32f890b915d7.1710145041.git.simone.ballarin@bugseng.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <1fdfec12fd2207c294f50d01d8ec32f890b915d7.1710145041.git.simone.ballarin@bugseng.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 11.03.2024 09:59, Simone Ballarin wrote: > Add deviation comments to address violations of > MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order > to prevent the contents of a header file being included more than > once"). > > Inclusion guards must appear at the beginning of the headers > (comments are permitted anywhere). > > This patch adds deviation comments using the format specified > in docs/misra/safe.json for headers with just the direct > inclusion guard before the inclusion guard since they are > safe and not supposed to comply with the directive. > > Signed-off-by: Simone Ballarin > > --- > Changes in v3: > - fix inconsistent deviation ID > The patch has been introduced in v2. > --- > docs/misra/safe.json | 8 ++++++++ > xen/arch/arm/include/asm/hypercall.h | 1 + > xen/arch/x86/include/asm/hypercall.h | 1 + > 3 files changed, 10 insertions(+) What about asm-generic/hypercall.h? > --- a/xen/arch/arm/include/asm/hypercall.h > +++ b/xen/arch/arm/include/asm/hypercall.h > @@ -1,3 +1,4 @@ > +/* SAF-5-safe direct inclusion guard before */ > #ifndef __XEN_HYPERCALL_H__ > #error "asm/hypercall.h should not be included directly - include xen/hypercall.h instead" > #endif > --- a/xen/arch/x86/include/asm/hypercall.h > +++ b/xen/arch/x86/include/asm/hypercall.h > @@ -2,6 +2,7 @@ > * asm-x86/hypercall.h > */ > > +/* SAF-5-safe direct inclusion guard before */ > #ifndef __XEN_HYPERCALL_H__ > #error "asm/hypercall.h should not be included directly - include xen/hypercall.h instead" > #endif Iirc it was said that this way checking for correct guards is suppressed altogether in Eclair, which is not what we want. Can you clarify this, please? Jan From xen-devel-bounces@lists.xenproject.org Mon Mar 11 10:11:05 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 10:11:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691361.1077272 (Exim 4.92) (envelope-from ) id 1rjccY-0003gP-2p; Mon, 11 Mar 2024 10:11:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691361.1077272; Mon, 11 Mar 2024 10:11:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjccX-0003gI-Vj; Mon, 11 Mar 2024 10:11:01 +0000 Received: by outflank-mailman (input) for mailman id 691361; Mon, 11 Mar 2024 10:11:01 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjccX-0003g8-CM for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 10:11:01 +0000 Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [2a00:1450:4864:20::52f]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id a8656f59-df8f-11ee-a1ee-f123f15fe8a2; Mon, 11 Mar 2024 11:10:59 +0100 (CET) Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-568307fe62eso3567938a12.1 for ; Mon, 11 Mar 2024 03:10:59 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id h4-20020a170906260400b00a461e10094asm1366091ejc.95.2024.03.11.03.10.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Mar 2024 03:10:58 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a8656f59-df8f-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1710151859; x=1710756659; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=HY3G0C8ssgCw4IYQAmu5w9eJ4+9WJnmVFND2gySiPCQ=; b=SFHaIIFUVd90qkA2p9V2CLO2T5mHPd3imjXJPLuZtI4WQ+5bTmPZ5co1QBxpRH9VbI uxhkSUEGWqitbDDSXU2wCTiUYjYhw8gts9BjLlnQm7A5qbD2bbRBbWOP9nKs5I/9t4IF KKH2rxVoYPYQeiPlp15v04co+e7c+eMCsmRyQNWl8/XSmtFhWsSkHOcOoBGZ2Ku3hNma kr7jLl8pw8pH52RFjw3SIhjqkXympQzysnpfUzpeG9Ln5P15fkWeAt0SG9Oh2X6Wsaqc 56y7nEU2KoJPBQUWRtM7NyeqKPFxYbWFdrw7W591+CCxyvyAIq0iePBMqyryxYEEDPgU y7yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710151859; x=1710756659; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=HY3G0C8ssgCw4IYQAmu5w9eJ4+9WJnmVFND2gySiPCQ=; b=EfuinjJtqNZCwMb4nR1IGgabC0+nZR/GsNbO9Yuz4pRG9+rInXyustlTieOA31qs2U ulw/lLJQBJHdCg8dqGz0eG0fYKXetYNLR2Jc0oshe5WtJfrPuNv0HrPUPUxT811L3lyu 98D6hR1a6az94RojLdlkONvxZ/EYLTXN1oZixyXzYZVtVTkS/bAXmiig72FsPtW2zPzK ptLvksMJlBngJMljnX72IkPSbmb+EJRBfHQigTDul6lw2WxFtkzrykO883G71pBIeyIi FCJFHKLfToqROhfPO/+fZ1MQZyyPXYMk9CgvW6S+p59l0neyOFXNJFnIxE6IntBepjPq HBzg== X-Forwarded-Encrypted: i=1; AJvYcCVLrsGZR7EwuRJV9Z+hQ4oIX+5bLMVU9RjtKJmRVr+alqOoQGDsVOPizjFscQXQQY4djZg+AX0kaoLC9B4LwrVnHZ6dogL2bGWWqao6aNQ= X-Gm-Message-State: AOJu0YxswUxUxjbZeSuZ5SGncczBPf5HI+vDuPHwPye/LdnQp+a0twrD 5GNJKL9Ddw21ydmbgG6taS3jrtHYj123Nfwoujhgvll4lVExz2htE8nNXPb1Dw== X-Google-Smtp-Source: AGHT+IF2Dfh+ZcaReek5qofW2ooz5uwVemsb+ar5ciV8rJKsqGYCKF0taCd/dBbziYZ8NywZ1EuZdw== X-Received: by 2002:a17:907:8b98:b0:a46:2643:845f with SMTP id tb24-20020a1709078b9800b00a462643845fmr2203254ejc.58.1710151858987; Mon, 11 Mar 2024 03:10:58 -0700 (PDT) Message-ID: <332ebf49-9aa4-42fd-99be-bda16580c92f@suse.com> Date: Mon, 11 Mar 2024 11:10:59 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH v3 04/16] xen/arm: address violations of MISRA C:2012 Directive 4.10 Content-Language: en-US To: Simone Ballarin Cc: consulting@bugseng.com, sstabellini@kernel.org, Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Maria Celeste Cesario , xen-devel@lists.xenproject.org References: <868ede5a23489e018e272188edfbee572d1ad393.1710145041.git.simone.ballarin@bugseng.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <868ede5a23489e018e272188edfbee572d1ad393.1710145041.git.simone.ballarin@bugseng.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 11.03.2024 09:59, Simone Ballarin wrote: > --- a/xen/arch/arm/efi/efi-boot.h > +++ b/xen/arch/arm/efi/efi-boot.h > @@ -3,6 +3,10 @@ > * is intended to be included by common/efi/boot.c _only_, and > * therefore can define arch specific global variables. > */ > + > +#ifndef XEN_ARCH_ARM_EFI_EFI_BOOT_H > +#define XEN_ARCH_ARM_EFI_EFI_BOOT_H Related to my question raised against the cover letter, what does the XEN_ prefix gain us here? All building of the hypervisor binaries happens inside the xen/ subtree. Jan From xen-devel-bounces@lists.xenproject.org Mon Mar 11 10:15:56 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 10:15:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691367.1077281 (Exim 4.92) (envelope-from ) id 1rjch6-0004IA-K8; Mon, 11 Mar 2024 10:15:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691367.1077281; Mon, 11 Mar 2024 10:15:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjch6-0004I3-HX; Mon, 11 Mar 2024 10:15:44 +0000 Received: by outflank-mailman (input) for mailman id 691367; Mon, 11 Mar 2024 10:15:43 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjch5-0004Hx-3u for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 10:15:43 +0000 Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [2a00:1450:4864:20::630]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 4eb46285-df90-11ee-a1ee-f123f15fe8a2; Mon, 11 Mar 2024 11:15:38 +0100 (CET) Received: by mail-ej1-x630.google.com with SMTP id a640c23a62f3a-a4627a7233aso117115566b.1 for ; Mon, 11 Mar 2024 03:15:38 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id s13-20020a170906168d00b00a462bd5ddcdsm628573ejd.144.2024.03.11.03.15.37 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Mar 2024 03:15:37 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 4eb46285-df90-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1710152138; x=1710756938; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=Bk9VSZLSe3R6ckTqwWmyIGqBXh5+oRT91UuzhN+BqNw=; b=esbu3LBnCO3geLd53IzVwjm3mnmZ0BielgG8zmt4wHrIVxs583ovdlxrvB8+zZI1bF iUg915JAFYcv17gRCX9Pj+nf0TR58K4JgkEmMEHRA9NKB9Lm3dtDiquUBPFCdi+lLP20 277FeWfgt1oHHlkYk8nucRtNOuuHgvv3Vst2v6XpMd97LeW/EcytFO1nR5KHmsqNLzNE FR5IZ6QXVwV0dYNXVTqJ/06uziTBZ+Zje4fjr+0xY1F2HGbamSGXXKtT0be+RVwJueUk piz0y060OsAkuZzB9QbSWq5Ia9LwxcKS5MSx84E7hVgkzBgBIzIsDytanxhnsFrAFoBk SS8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710152138; x=1710756938; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Bk9VSZLSe3R6ckTqwWmyIGqBXh5+oRT91UuzhN+BqNw=; b=p4C717GpbYb9r02tNHX7l8F44itTFxbB1gF10SQknM4lU70yT73Yi0/iKLUIllkEkw ZgYo1uvc41umOl/IMEdpiV+1oXmSM1Rft+d15OgPW/zsKkEoqamQiPc4NBMPBBMiSyMf uGv37EnQANiv3WyyQPcmruNoEzpnUnRxOFj/vxUYKUzHiX/1Jbo/D1A5jhpTRgkBVX/z PIcmnbvXtpB9GdNJFroKP85xOxAmhQfR3MxCqh2PA7mUspgZdFouu1bxH6vydJ5JPFo2 xfdQi1DALoLO5Pgh9PNwcyKYYWixeibGPdCIBiBfmjQ/1pLLZVYLWPjQVXofCILRzF3t sTKA== X-Gm-Message-State: AOJu0Yx3Of36z/annkXGgIHJ532zgMUdkoBnD6NgZ3Er+rF/FlA7JlwA u7Z/aCDUU7rfzhGqRl9OpSc1pcFDMQNk/vJMw9e8JOlWKvACDptw9Og+Q0ZstMauRAK9O7geZcs = X-Google-Smtp-Source: AGHT+IHUGlC6fFcoD0e/UZ+V0xepMb/URTdzXiC4Vvv4hMauGPxqDfa6pVD2QssNXhVAtRE4rxucsw== X-Received: by 2002:a17:906:c290:b0:a46:1f8f:a0b0 with SMTP id r16-20020a170906c29000b00a461f8fa0b0mr3087757ejz.13.1710152138023; Mon, 11 Mar 2024 03:15:38 -0700 (PDT) Message-ID: <55f7b5f5-0f0d-4c80-aeeb-a2e8f22f1197@suse.com> Date: Mon, 11 Mar 2024 11:15:38 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: xen | Failed pipeline for staging | e90089db Content-Language: en-US To: "xen-devel@lists.xenproject.org" References: <65eed65856f57_2c8a520124653@gitlab-sidekiq-catchall-v2-df9f7d5b4-ts6r7.mail> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <65eed65856f57_2c8a520124653@gitlab-sidekiq-catchall-v2-df9f7d5b4-ts6r7.mail> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 11.03.2024 11:00, GitLab wrote: > > > Pipeline #1208433952 has failed! > > Project: xen ( https://gitlab.com/xen-project/hardware/xen ) > Branch: staging ( https://gitlab.com/xen-project/hardware/xen/-/commits/staging ) > > Commit: e90089db ( https://gitlab.com/xen-project/hardware/xen/-/commit/e90089db3fab06dc8947fcd64f1ed54569e708a6 ) > Commit Message: arm/smmu: address some violations of MISRA C Ru... > Commit Author: Nicola Vetrini > Committed by: Jan Beulich ( https://gitlab.com/jbeulich ) > > > Pipeline #1208433952 ( https://gitlab.com/xen-project/hardware/xen/-/pipelines/1208433952 ) triggered by Jan Beulich ( https://gitlab.com/jbeulich ) > had 2 failed jobs. > > Job #6362049499 ( https://gitlab.com/xen-project/hardware/xen/-/jobs/6362049499/raw ) > > Stage: build > Name: ubuntu-trusty-gcc I'm afraid I can't make sense of this supposed failure. > Job #6362049553 ( https://gitlab.com/xen-project/hardware/xen/-/jobs/6362049553/raw ) > > Stage: test > Name: build-each-commit-gcc This one simply timed out once again, for it taking too long to build a dozen commits in non-incremental fashion. Jan From xen-devel-bounces@lists.xenproject.org Mon Mar 11 10:20:54 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 10:20:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691371.1077292 (Exim 4.92) (envelope-from ) id 1rjcm3-0006F7-5w; Mon, 11 Mar 2024 10:20:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691371.1077292; Mon, 11 Mar 2024 10:20:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjcm3-0006F0-2s; Mon, 11 Mar 2024 10:20:51 +0000 Received: by outflank-mailman (input) for mailman id 691371; Mon, 11 Mar 2024 10:20:49 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjcm1-0006Eu-K2 for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 10:20:49 +0000 Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [2a00:1450:4864:20::233]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 078d35ad-df91-11ee-afdc-a90da7624cb6; Mon, 11 Mar 2024 11:20:48 +0100 (CET) Received: by mail-lj1-x233.google.com with SMTP id 38308e7fff4ca-2d27fef509eso67471661fa.3 for ; Mon, 11 Mar 2024 03:20:48 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id h25-20020a1709070b1900b00a3e5adf11c7sm2696964ejl.157.2024.03.11.03.20.47 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Mar 2024 03:20:47 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 078d35ad-df91-11ee-afdc-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1710152448; x=1710757248; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=4nOoUMQ1fb+vrW2YXvGVfqAbVjEUbKgIjCyWyBUNyY8=; b=gAMWdX9Ux/PjsbcQvNm4Nab9uL3wYB4MtEaGDqQhfyhwlFruWm+gNKeLxrsn4/NlkU /8ZouqbYGvZzJDt6KrPLxnajOAJizfkcFG/dInn/c/yNb6qBpNn7k+9pn4f9qe8ByuJU ifdFtzTl2yuGLfEnKgzbWtSQjAyfsyJgwYnwNKpolL6Rp4NrAdb7W8HA2PGLb1mV3ZT/ 6NCpFiITA+RmBynryNX2T0n6LBM1vRmkIMo8JeyfW5XHTku+NwQu6EQkhLqIyP6fPUJ1 T8JRf+4pEiU5/bAJUbevBTOQzmEKUNBspV0H/sGnJfjwWZEx6yO4fN4YfpTqaonI3wgc q9Tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710152448; x=1710757248; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=4nOoUMQ1fb+vrW2YXvGVfqAbVjEUbKgIjCyWyBUNyY8=; b=n62/M/4bfpw8G4vOekm6SrB4/JWnQqGYs0HxkxyIkTvBShI35MDobZMGQcD3EjU/+Y s0anRcjqaZJ0mCvM041wDEr0Wo1lHhj5OquhCfa2QIlGn1CI11YAXReVnUpwqtwS/2Gb 6MsaFSxp0JGwP9Hy84J/5floZuSk1C+dRj8fP/mMj2HwIOiUsvDCLxp8cn40Y9ytZ6MI ggttBfN0e6hpqCxPxLPdrgQprXEXuuO/D85eaW0L5YRTFZEgSwsywX3Q/WtWgwqJpAJs 9LnFEaqcXKL3DRltv14WPuL/cEnZDuPtd4BxspLWCHmi6TF/GnuNupB+qiLZi7vbLBfj 8VIA== X-Gm-Message-State: AOJu0YyLO008OKxjTyZ36P72QlJNYixE+cIoSddiNtWd0hB43qerpqc4 ulzuQl3qQEIqUoEAbGXFA44mKnNqE2IHRVvSbDZ7IPLOa/KQuvr/NRoJIewYcEjBJI1OeCm8dAg = X-Google-Smtp-Source: AGHT+IEhoohpxrSbQV38QSj45UViPX4ANs46DLLT2142VsjWD/BIpkENWNVNKtf7b/FEaAwxRrjHWg== X-Received: by 2002:a2e:97d1:0:b0:2d2:b337:f55d with SMTP id m17-20020a2e97d1000000b002d2b337f55dmr3746733ljj.16.1710152447967; Mon, 11 Mar 2024 03:20:47 -0700 (PDT) Message-ID: <167864dd-32b7-4ce2-b844-c033815308cf@suse.com> Date: Mon, 11 Mar 2024 11:20:49 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: xen | Failed pipeline for staging | 1396892d Content-Language: en-US To: "xen-devel@lists.xenproject.org" References: <65eed87594573_2c8a3cc158049@gitlab-sidekiq-catchall-v2-df9f7d5b4-wgfn8.mail> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <65eed87594573_2c8a3cc158049@gitlab-sidekiq-catchall-v2-df9f7d5b4-wgfn8.mail> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 11.03.2024 11:09, GitLab wrote: > > > Pipeline #1208444169 has failed! > > Project: xen ( https://gitlab.com/xen-project/hardware/xen ) > Branch: staging ( https://gitlab.com/xen-project/hardware/xen/-/commits/staging ) > > Commit: 1396892d ( https://gitlab.com/xen-project/hardware/xen/-/commit/1396892d801cf148644cd5590be2f143648f9083 ) > Commit Message: xen/ppc: switch PPC to use asm-generic/device.h... > Commit Author: Oleksii Kurochko ( https://gitlab.com/olkur ) > Committed by: Jan Beulich ( https://gitlab.com/jbeulich ) > > > Pipeline #1208444169 ( https://gitlab.com/xen-project/hardware/xen/-/pipelines/1208444169 ) triggered by Jan Beulich ( https://gitlab.com/jbeulich ) > had 2 failed jobs. > > Job #6362114743 ( https://gitlab.com/xen-project/hardware/xen/-/jobs/6362114743/raw ) > > Stage: build > Name: alpine-3.18-gcc-debug Perhaps a networking glitch: make[2]: Leaving directory '/builds/xen-project/hardware/xen/extras/mini-os-remote' touch mk-headers-x86_64 wget: can't connect to remote host (104.239.192.120): Connection refused wget: can't connect to remote host (104.239.192.120): Connection refused make[1]: *** [Makefile:90: newlib-1.16.0.tar.gz] Error 1 make[1]: *** Waiting for unfinished jobs.... make[1]: *** [Makefile:119: zlib-1.2.3.tar.gz] Error 1 wget: can't connect to remote host (104.239.192.120): Connection refused make[1]: *** [Makefile:139: pciutils-2.2.9.tar.bz2] Error 1 make[1]: Leaving directory '/builds/xen-project/hardware/xen/stubdom' make: *** [Makefile:151: install-stubdom] Error 2 > Job #6362114850 ( https://gitlab.com/xen-project/hardware/xen/-/jobs/6362114850/raw ) > > Stage: build > Name: debian-bookworm-gcc Possibly here too: fatal: remote error: git-cache-proxy: git remote died with error exit code 1 // Fetching origin // fatal: unable to access 'https://xenbits.xen.org/git-http/mini-os.git/': Failed to connect to xenbits.xen.org port 443: Connection refused // error: Could not fetch origin make: *** [Makefile:23: mini-os-dir] Error 128 make: *** Waiting for unfinished jobs.... However, I'm puzzled by quite a few ocaml issues along the lines of File "config.ml", line 102, characters 16-31: 102 | | Failure "int_of_string" -> append (k, "expect int arg") ^^^^^^^^^^^^^^^ Warning 52 [fragile-literal-pattern]: Code should not depend on the actual values of this constructor's arguments. They are only for information and may change in future versions. (See manual section 11.5) Apparently just warnings, but the "Failure" in there makes them not appear so at the first glance. Jan From xen-devel-bounces@lists.xenproject.org Mon Mar 11 10:48:56 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 10:48:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691379.1077301 (Exim 4.92) (envelope-from ) id 1rjdD8-0001RH-7l; Mon, 11 Mar 2024 10:48:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691379.1077301; Mon, 11 Mar 2024 10:48:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjdD8-0001RA-5G; Mon, 11 Mar 2024 10:48:50 +0000 Received: by outflank-mailman (input) for mailman id 691379; Mon, 11 Mar 2024 10:48:49 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjdD7-0001R4-0x for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 10:48:49 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id f0306a8e-df94-11ee-afdc-a90da7624cb6; Mon, 11 Mar 2024 11:48:47 +0100 (CET) Received: from [157.138.166.139] (unknown [157.138.166.139]) by support.bugseng.com (Postfix) with ESMTPSA id AAAB84EE0C90; Mon, 11 Mar 2024 11:48:46 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f0306a8e-df94-11ee-afdc-a90da7624cb6 Message-ID: Date: Mon, 11 Mar 2024 11:48:45 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH] xen/evtchn: address violations of MISRA C:2012 Rules 16.3 and 16.4 Content-Language: en-US, it To: Jan Beulich , Stefano Stabellini Cc: consulting@bugseng.com, Andrew Cooper , George Dunlap , Julien Grall , Wei Liu , xen-devel@lists.xenproject.org References: <3ec419e30227a8016c28e04524cd36a549aaddcf.1709898466.git.federico.serafini@bugseng.com> <602c2da1-d5ab-4120-ab19-37e75820d129@bugseng.com> <874fc4f8-f862-4fa7-b436-dd1420d010a7@suse.com> From: Federico Serafini Organization: BUGSENG srl In-Reply-To: <874fc4f8-f862-4fa7-b436-dd1420d010a7@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 11/03/24 10:51, Jan Beulich wrote: > On 11.03.2024 10:02, Federico Serafini wrote: >> On 11/03/24 08:40, Jan Beulich wrote: >>> On 08.03.2024 12:51, Federico Serafini wrote: >>>> --- a/xen/common/event_channel.c >>>> +++ b/xen/common/event_channel.c >>>> @@ -130,9 +130,12 @@ static bool virq_is_global(unsigned int virq) >>>> >>>> case VIRQ_ARCH_0 ... VIRQ_ARCH_7: >>>> return arch_virq_is_global(virq); >>>> + >>>> + default: >>>> + ASSERT(virq < NR_VIRQS); >>>> + break; >>>> } >>>> >>>> - ASSERT(virq < NR_VIRQS); >>>> return true; >>>> } >>> >>> Just for my understanding: The ASSERT() is moved so the "default" would >>> consist of more than just "break". Why is it that then the "return" isn't >>> moved, too? >> >> No reason in particular. >> If preferred, I can move it too. > > I for one would prefer that, yes. But what's needed up front is that we > decide what we want to do _consistently_ in all such cases. The only reason I left the return at the end is because it is slightly more compliant to advisory (and not accepted) Rule 15.5 that says to place a single return at the end of the function and to not use early returns. > >>>> @@ -1672,6 +1676,9 @@ static void domain_dump_evtchn_info(struct domain *d) >>>> case ECS_VIRQ: >>>> printk(" v=%d", chn->u.virq); >>>> break; >>>> + default: >>>> + /* Nothing to do in other cases. */ >>>> + break; >>>> } >>> >>> Yes this, just to mention it, while in line with what Misra demands is >>> pretty meaningless imo: The absence of "default" says exactly what the >>> comment now says. FTAOD - this is a comment towards the Misra guideline, >>> not so much towards the specific change here. >> >> Both you and Stefano reviewed the code and agreed on the fact that doing >> nothing for the default case is the right thing and now the code >> explicitly says that without letting any doubts. >> Furthermore, during the reviews it could happen that you notice a switch >> where something needs to be done for the default case. > > That shouldn't happen during review. Anyone proposing a patch to add such > a comment wants to first have made sure the comment is actually applicable > there. Otherwise we're in "mechanically add comments" territory, which I > think we all agreed we want to avoid. What I wanted to say is that adding the comment is not completely meaningless: it makes the intention of the code explicit and such intention is double/triple checked. -- Federico Serafini, M.Sc. Software Engineer, BUGSENG (http://bugseng.com) From xen-devel-bounces@lists.xenproject.org Mon Mar 11 10:54:36 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 10:54:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691382.1077313 (Exim 4.92) (envelope-from ) id 1rjdId-00038M-Sl; Mon, 11 Mar 2024 10:54:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691382.1077313; Mon, 11 Mar 2024 10:54:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjdId-00038F-OT; Mon, 11 Mar 2024 10:54:31 +0000 Received: by outflank-mailman (input) for mailman id 691382; Mon, 11 Mar 2024 10:54:30 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjdIc-000389-7c for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 10:54:30 +0000 Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [2a00:1450:4864:20::333]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id bc056e20-df95-11ee-afdc-a90da7624cb6; Mon, 11 Mar 2024 11:54:29 +0100 (CET) Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-4132c64fdceso2158835e9.3 for ; Mon, 11 Mar 2024 03:54:29 -0700 (PDT) Received: from localhost ([213.195.118.74]) by smtp.gmail.com with ESMTPSA id j27-20020a05600c1c1b00b00412f83e0c11sm15195642wms.22.2024.03.11.03.54.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 Mar 2024 03:54:27 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: bc056e20-df95-11ee-afdc-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1710154468; x=1710759268; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=qFSbJRUt82khlam4F2vn9PAAVNAJOSdtfHu56s/6wSM=; b=itgv/4mnIAW4XOYQ7E2ujHbGmoiIIj1m313EW3/B7+72JZlZcdLku0kkPsh4K3a+4+ 3JHV3q35QdORpYZTKJSLIrTGkIcwsqGRcggfYAM0780uC3G75raICAIMT65dsdomtcjh KVQ1Zaq9KH/s6mueXfCFr8GhQ+mcwr/WueX5w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710154468; x=1710759268; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=qFSbJRUt82khlam4F2vn9PAAVNAJOSdtfHu56s/6wSM=; b=ORE5+PYd3yHLzZsL3mcvEfrVk/29kv8nIx7GBb7KMBYUJ+/01KcFfI9PMQ90Jvj9CL vpMJe3Lfilj+u1I19+wqg3855iyBdGoYpNjJOy8i3KQFlSDAfPgWMZs6jUJ/ZVm6zkJR Ydd0wSYh+ZhzDp+f3LHMyU2ki6KraU3SXGcDICGpkoonQa5toea415RRhw2r5aX3wuk+ /Phxmy/+AeQTKDR+13nkHUcxkW7oUdEMWIZqZS8IocVsXIcWexOtVOINqmIrbGbIGG6T FvpJrOnkUOCVwIGMHOjMI1h8gpP2uHGPo2bw2xRUJPujMcm1N56dKBfyHEcsWDR+iiGG eewQ== X-Gm-Message-State: AOJu0Yz8eDJoGo0MF5Zeu0jdDt9eTReavTOwJ0doIQgP68pdqEKyPs1n XJk5LC362AN/0+viO9eR5H9M3ZS1hxQszCbs+sc5+1bAnLz4Il8s3lQVmCc92aeSWWSnM/TTbeN 0 X-Google-Smtp-Source: AGHT+IGiNELZqdLPiQLT4VoVaFfhmhTBYxmO60jlc4Sn12sHDUzMgsHvokkcLAwKi5bqGtHyYKQw1w== X-Received: by 2002:a05:600c:4449:b0:413:1f5c:baa6 with SMTP id v9-20020a05600c444900b004131f5cbaa6mr4765016wmn.30.1710154468051; Mon, 11 Mar 2024 03:54:28 -0700 (PDT) From: Roger Pau Monne To: xen-devel@lists.xenproject.org Cc: Roger Pau Monne , Jan Beulich , Andrew Cooper , Wei Liu Subject: [PATCH] x86/mm: fix detection of last L1 entry in modify_xen_mappings_lite() Date: Mon, 11 Mar 2024 11:54:16 +0100 Message-ID: <20240311105416.4556-1-roger.pau@citrix.com> X-Mailer: git-send-email 2.44.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The current logic to detect when to switch to the next L1 table is incorrectly using l2_table_offset() in order to notice when the last entry on the current L1 table has been reached. It should instead use l1_table_offset() to check whether the index has wrapped to point to the first entry, and so the next L1 table should be used. Fixes: 8676092a0f16 ('x86/livepatch: Fix livepatch application when CET is active') Signed-off-by: Roger Pau Monné --- This fixes the osstest livepatch related crash, we have been lucky so far that the .text section didn't seem to have hit this. --- xen/arch/x86/mm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index 2aff6d4b5338..0c6658298de2 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -5959,7 +5959,7 @@ void init_or_livepatch modify_xen_mappings_lite( v += 1UL << L1_PAGETABLE_SHIFT; - if ( l2_table_offset(v) == 0 ) + if ( l1_table_offset(v) == 0 ) break; } -- 2.44.0 From xen-devel-bounces@lists.xenproject.org Mon Mar 11 10:55:28 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 10:55:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691385.1077321 (Exim 4.92) (envelope-from ) id 1rjdJY-0003gl-7M; Mon, 11 Mar 2024 10:55:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691385.1077321; Mon, 11 Mar 2024 10:55:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjdJY-0003ge-4n; Mon, 11 Mar 2024 10:55:28 +0000 Received: by outflank-mailman (input) for mailman id 691385; Mon, 11 Mar 2024 10:55:26 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjdJW-0003gT-Ti for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 10:55:26 +0000 Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [2a00:1450:4864:20::332]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id ddc07ad0-df95-11ee-afdc-a90da7624cb6; Mon, 11 Mar 2024 11:55:26 +0100 (CET) Received: by mail-wm1-x332.google.com with SMTP id 5b1f17b1804b1-4132600824bso5738905e9.2 for ; Mon, 11 Mar 2024 03:55:26 -0700 (PDT) Received: from [10.80.67.149] (default-46-102-197-194.interdsl.co.uk. [46.102.197.194]) by smtp.gmail.com with ESMTPSA id o16-20020a5d58d0000000b0033b87c2725csm6117958wrf.104.2024.03.11.03.55.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Mar 2024 03:55:25 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ddc07ad0-df95-11ee-afdc-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1710154525; x=1710759325; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=8KYI5kGDhcj4DC23WDO5d3YQClzg6IQFRR/v+VHskNA=; b=Cj3xbjyo2HjhnklktrFQ7XZOqsZJolbWHNtgrr4IEIOo++TD2oLxXbP7mCeHSdvNyS tezch8xx45lQcDxKP2Ryi96HJoEMBP44sk76d5/+EuJscUm+clZsyFMUmFsyMQ/nbjma MC4JljTZCxqsDkb7eShldNrwMOmOIccukZWhs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710154525; x=1710759325; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=8KYI5kGDhcj4DC23WDO5d3YQClzg6IQFRR/v+VHskNA=; b=BdmrygKX6aFQzY77w0BckDwQFblQ/wwsR8ijl9oN2Z7HuMhKNij8qIB0rEg7tlqG6D 6cN0hu00aGUWbhs6Gg9QR2hCGfai/rMjqNGANUeVPnSCo78z6K6KGAWeD3YukXOuUccD jhgJzIlk/GwYn8znK0pQPgb/VKzFQfMhPLnqEtpAV6aCrwEmRkAilOGBIh1d7is95Qz5 liomGCIzAyvBNTtdvrjCObnwl79+j+/+c6t58rQLSBZx+xqnBW0gWhBelYybgffpCoDd QR3cW38YDwtlc/itq2aTVSL7zbkwuDL2pIBGxNKIVCGSbctY0tKXqjRiyQaqur2Z44Y6 kl5Q== X-Forwarded-Encrypted: i=1; AJvYcCU8wAXKbFh0tQsln97Kdi8q8g7q6KDYxTFU+oetkqSqS6GjTM8hDQLEON3xyD71EqYLBPFaoTDSf2fGcyxD+m7sDLpM3/see1R5HPcsZ+4= X-Gm-Message-State: AOJu0YxxcPCyJjg5aL4hD80zeIvBrjZDl4grVWpnAi7hIc83UngI/sB3 xuFqfIK8yq5fF0+mfAjaxTDvwQDOLbuxuN9XW9vNoTT7a5e/GgR5hs6rKs7GQAiviUdCH4Bc76X q X-Google-Smtp-Source: AGHT+IEAM9P3cmoPeV2oKWkNhkBBe2yRDB4Bqn/X7NcSs5e6kD0MI4B3eBmDM8G9hopOcOqzc8tWwA== X-Received: by 2002:adf:e582:0:b0:33e:8b93:e79e with SMTP id l2-20020adfe582000000b0033e8b93e79emr19101wrm.26.1710154525427; Mon, 11 Mar 2024 03:55:25 -0700 (PDT) Message-ID: Date: Mon, 11 Mar 2024 10:55:24 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: xen | Failed pipeline for staging | 1396892d Content-Language: en-GB To: Jan Beulich , "xen-devel@lists.xenproject.org" References: <65eed87594573_2c8a3cc158049@gitlab-sidekiq-catchall-v2-df9f7d5b4-wgfn8.mail> <167864dd-32b7-4ce2-b844-c033815308cf@suse.com> From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <167864dd-32b7-4ce2-b844-c033815308cf@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 11/03/2024 10:20 am, Jan Beulich wrote: > On 11.03.2024 11:09, GitLab wrote: >> >> Pipeline #1208444169 has failed! >> >> Project: xen ( https://gitlab.com/xen-project/hardware/xen ) >> Branch: staging ( https://gitlab.com/xen-project/hardware/xen/-/commits/staging ) >> >> Commit: 1396892d ( https://gitlab.com/xen-project/hardware/xen/-/commit/1396892d801cf148644cd5590be2f143648f9083 ) >> Commit Message: xen/ppc: switch PPC to use asm-generic/device.h... >> Commit Author: Oleksii Kurochko ( https://gitlab.com/olkur ) >> Committed by: Jan Beulich ( https://gitlab.com/jbeulich ) >> >> >> Pipeline #1208444169 ( https://gitlab.com/xen-project/hardware/xen/-/pipelines/1208444169 ) triggered by Jan Beulich ( https://gitlab.com/jbeulich ) >> had 2 failed jobs. >> >> Job #6362114743 ( https://gitlab.com/xen-project/hardware/xen/-/jobs/6362114743/raw ) >> >> Stage: build >> Name: alpine-3.18-gcc-debug > Perhaps a networking glitch: > > make[2]: Leaving directory '/builds/xen-project/hardware/xen/extras/mini-os-remote' > touch mk-headers-x86_64 > wget: can't connect to remote host (104.239.192.120): Connection refused > wget: can't connect to remote host (104.239.192.120): Connection refused > make[1]: *** [Makefile:90: newlib-1.16.0.tar.gz] Error 1 > make[1]: *** Waiting for unfinished jobs.... > make[1]: *** [Makefile:119: zlib-1.2.3.tar.gz] Error 1 > wget: can't connect to remote host (104.239.192.120): Connection refused > make[1]: *** [Makefile:139: pciutils-2.2.9.tar.bz2] Error 1 > make[1]: Leaving directory '/builds/xen-project/hardware/xen/stubdom' > make: *** [Makefile:151: install-stubdom] Error 2 > > >> Job #6362114850 ( https://gitlab.com/xen-project/hardware/xen/-/jobs/6362114850/raw ) >> >> Stage: build >> Name: debian-bookworm-gcc > Possibly here too: > > fatal: remote error: git-cache-proxy: git remote died with error exit code 1 // Fetching origin // fatal: unable to access 'https://xenbits.xen.org/git-http/mini-os.git/': Failed to connect to xenbits.xen.org port 443: Connection refused // error: Could not fetch origin > make: *** [Makefile:23: mini-os-dir] Error 128 > make: *** Waiting for unfinished jobs.... The networking isn't as stable as would be idea.  I just rerun these and they tend to go away. > > However, I'm puzzled by quite a few ocaml issues along the lines of > > File "config.ml", line 102, characters 16-31: > 102 | | Failure "int_of_string" -> append (k, "expect int arg") > ^^^^^^^^^^^^^^^ > Warning 52 [fragile-literal-pattern]: Code should not depend on the actual values of > this constructor's arguments. They are only for information > and may change in future versions. (See manual section 11.5) > > Apparently just warnings, but the "Failure" in there makes them not appear > so at the first glance. "Failure" is just a type of exception in the Ocaml Language. This overall diagnostic is just a warning, and fixing it is one a todo list somewhere. ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Mar 11 11:01:48 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 11:01:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691395.1077332 (Exim 4.92) (envelope-from ) id 1rjdPb-0005f4-U0; Mon, 11 Mar 2024 11:01:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691395.1077332; Mon, 11 Mar 2024 11:01:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjdPb-0005ex-QQ; Mon, 11 Mar 2024 11:01:43 +0000 Received: by outflank-mailman (input) for mailman id 691395; Mon, 11 Mar 2024 11:01:42 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjdPa-0005er-Tj for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 11:01:42 +0000 Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [2a00:1450:4864:20::135]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id bd5a520a-df96-11ee-a1ee-f123f15fe8a2; Mon, 11 Mar 2024 12:01:41 +0100 (CET) Received: by mail-lf1-x135.google.com with SMTP id 2adb3069b0e04-51320ca689aso3240963e87.2 for ; Mon, 11 Mar 2024 04:01:41 -0700 (PDT) Received: from [10.80.67.149] (default-46-102-197-194.interdsl.co.uk. [46.102.197.194]) by smtp.gmail.com with ESMTPSA id n23-20020ac242d7000000b005131b423d80sm1033734lfl.160.2024.03.11.04.01.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Mar 2024 04:01:39 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: bd5a520a-df96-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1710154900; x=1710759700; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=/MW2QcR+fBI2ctibF2XXgYOn0s+CU8tedK8srXQt3m4=; b=e7XgSG2Yqk09JcieGOYwV/7ENlI2y9Jzl5jF++05FOM8I/+jSkUXkrSARSS6Z5zm7+ BmkFiflF8wnmnCtnOx/wiSQc5zwHdcVA1Slub7sZQETsgZ0X8Y0b5W31qnPL4wn6av6X Oi6FqH/ZYBWvIIMUW5kNI2c1x1H2scSMkkKnY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710154900; x=1710759700; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=/MW2QcR+fBI2ctibF2XXgYOn0s+CU8tedK8srXQt3m4=; b=HVNaPWY8tPAhS7TR3U1R0nHzNsGHB4EQBWnBMqJWNaUGPsNUDRKnMYyWnt1rZgLNMJ UfGD3Q57iJKNQpM97dPZqGSxr62I4iFeivnYisJDhveEmENwH8EZDkaE3jZ+abiKl/gb UyqIXMbqGsnNWC9wLdJicYc/EfHaBBaineIc515aNXGMALb7zyohv68yJ4z2PJuHcbBW G8ue9NUDCi/xc0hiBWEtp7RHBxNtnaszdkL5Rq76lWMAPHen6zDbGoAIruQbwciHle/X oDSh0oE1Ga9g/9kKiMId5iOQh1B46KxVgTet6ZYD3tvhU+/7W9IQ5/VU2ZEeSqX1IHzE Eeug== X-Forwarded-Encrypted: i=1; AJvYcCW+teRPIyjkszI1vx0Sq/Blsw0vJj2VG0jobY3YPfSlBIyXxvmNM1US6SBYV/TubZW5VtSBj+S2Ag4w4dkjfn2Cna66rkwqRvN/o+9ndOc= X-Gm-Message-State: AOJu0Yzfrp2JJct69BOHqr/wvv+ADesPtR4MsT1QG86USsq/cb96Hu93 XXRPx1XECWTEmVT15HQcQMJOvNcHQvgJgxLyMdicGahmgagSrZz6/twI7D2fUGA= X-Google-Smtp-Source: AGHT+IG9/wh43oPwXJI5AOBQDpfjiNvplT/l51tUtzQUW8999tstAK+i/dm20NXOLjmC80WI8UH/nw== X-Received: by 2002:ac2:4c38:0:b0:513:1a9c:ae77 with SMTP id u24-20020ac24c38000000b005131a9cae77mr3678316lfq.52.1710154900377; Mon, 11 Mar 2024 04:01:40 -0700 (PDT) Message-ID: Date: Mon, 11 Mar 2024 11:01:38 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/mm: fix detection of last L1 entry in modify_xen_mappings_lite() Content-Language: en-GB To: Roger Pau Monne , xen-devel@lists.xenproject.org Cc: Jan Beulich , Wei Liu References: <20240311105416.4556-1-roger.pau@citrix.com> From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <20240311105416.4556-1-roger.pau@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 11/03/2024 10:54 am, Roger Pau Monne wrote: > The current logic to detect when to switch to the next L1 table is incorrectly > using l2_table_offset() in order to notice when the last entry on the current > L1 table has been reached. > > It should instead use l1_table_offset() to check whether the index has wrapped > to point to the first entry, and so the next L1 table should be used. > > Fixes: 8676092a0f16 ('x86/livepatch: Fix livepatch application when CET is active') > Signed-off-by: Roger Pau Monné Reviewed-by: Andrew Cooper > --- > This fixes the osstest livepatch related crash, we have been lucky so far that > the .text section didn't seem to have hit this. I'm very surprised too. From xen-devel-bounces@lists.xenproject.org Mon Mar 11 11:04:47 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 11:04:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691399.1077342 (Exim 4.92) (envelope-from ) id 1rjdSV-0006EE-An; Mon, 11 Mar 2024 11:04:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691399.1077342; Mon, 11 Mar 2024 11:04:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjdSV-0006E7-7n; Mon, 11 Mar 2024 11:04:43 +0000 Received: by outflank-mailman (input) for mailman id 691399; Mon, 11 Mar 2024 11:04:41 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjdST-0006E1-TB for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 11:04:41 +0000 Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [2a00:1450:4864:20::531]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 28907615-df97-11ee-afdc-a90da7624cb6; Mon, 11 Mar 2024 12:04:41 +0100 (CET) Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-5673b5a356eso4379711a12.0 for ; Mon, 11 Mar 2024 04:04:41 -0700 (PDT) Received: from [10.80.67.149] (default-46-102-197-194.interdsl.co.uk. [46.102.197.194]) by smtp.gmail.com with ESMTPSA id a10-20020a17090640ca00b00a4550e8ae70sm2770802ejk.63.2024.03.11.04.04.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Mar 2024 04:04:40 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 28907615-df97-11ee-afdc-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1710155080; x=1710759880; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=B99vhk+y0uiy3tqw4ypWKDbYu2zT+5lYQQrd1Y678FA=; b=lGmImCS4ERud2ii6ZCvuJufakYDT0uDzRkQFHTPOMMFALl/fPnHucE0k1BfYiyx6hU jEobgFYSCgFSqfEiCmDebgyqgF09CeU7ICwNrgt6/k+mKVOUnmh+8bUDH+7Rhq5PrQ1K PyaBa+nbT+MARgNIK0HEIm/0p9wvRoymbi2lU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710155080; x=1710759880; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=B99vhk+y0uiy3tqw4ypWKDbYu2zT+5lYQQrd1Y678FA=; b=X5Y25cpIOlEspEwZXC2NBW1Iu5Ds9UiMgumoY/RS2iIp+qHPWwoQvgzG4K2rN00RzW Axk3y/dtGz0mK5FoQnzbMZIK8B+8+chkU9dWp5cKvBa3TVdk9LPX9fdUQWRPO8Wg9apZ YlWWyAk8WFB8xOjtqxSjhHtknF7qxrrHaG44mzjjfwb0GZAaMFJ8Wwtz2qu+IvmDFUH8 YLjjsug9F4vSnlQkTO810EP7souzoFUhZTGpab8EEd9Dn5uJhP8fBSmIJjj1I9zU1EED joFUtq2PeFmHfkYGK3aA3hG/xL/Isml8tGr/GbhzPOSYjAYQji2Db6ivi2kMn9RoxLE1 HHEA== X-Forwarded-Encrypted: i=1; AJvYcCXQVbKqTvuuopNqzxVKkgJRpZfQbtI3x5nX9UAI/eR3K3bktyyswChxhrkuVXbmyoWF7BqZF1uU87b0ja1prtFKUfEppcG9vDJpdZTOgaw= X-Gm-Message-State: AOJu0YyB+WxQRtR5EGJoW7A90r6F6tYJUfZZtvvJoD/ny+N2jks09fLc 3Y0gbTeoaN7HY8IUR5/tsvUyz+dWojCaibCPDxZeePPWKRM+Oqbhq2M8BVcMGBE= X-Google-Smtp-Source: AGHT+IH+75W5SD1QjQhmgwUzP9jKVnw+9RIMC8QpF76HlqeJvpOFa5Acso3DIohj66fKLiLxCxkdFQ== X-Received: by 2002:a17:907:970a:b0:a46:22fc:74d3 with SMTP id jg10-20020a170907970a00b00a4622fc74d3mr2691932ejc.72.1710155080457; Mon, 11 Mar 2024 04:04:40 -0700 (PDT) Message-ID: Date: Mon, 11 Mar 2024 11:04:39 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: xen | Failed pipeline for staging | e90089db Content-Language: en-GB To: Jan Beulich , "xen-devel@lists.xenproject.org" References: <65eed65856f57_2c8a520124653@gitlab-sidekiq-catchall-v2-df9f7d5b4-ts6r7.mail> <55f7b5f5-0f0d-4c80-aeeb-a2e8f22f1197@suse.com> From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <55f7b5f5-0f0d-4c80-aeeb-a2e8f22f1197@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 11/03/2024 10:15 am, Jan Beulich wrote: > On 11.03.2024 11:00, GitLab wrote: >> >> Pipeline #1208433952 has failed! >> >> Project: xen ( https://gitlab.com/xen-project/hardware/xen ) >> Branch: staging ( https://gitlab.com/xen-project/hardware/xen/-/commits/staging ) >> >> Commit: e90089db ( https://gitlab.com/xen-project/hardware/xen/-/commit/e90089db3fab06dc8947fcd64f1ed54569e708a6 ) >> Commit Message: arm/smmu: address some violations of MISRA C Ru... >> Commit Author: Nicola Vetrini >> Committed by: Jan Beulich ( https://gitlab.com/jbeulich ) >> >> >> Pipeline #1208433952 ( https://gitlab.com/xen-project/hardware/xen/-/pipelines/1208433952 ) triggered by Jan Beulich ( https://gitlab.com/jbeulich ) >> had 2 failed jobs. >> >> Job #6362049499 ( https://gitlab.com/xen-project/hardware/xen/-/jobs/6362049499/raw ) >> >> Stage: build >> Name: ubuntu-trusty-gcc > I'm afraid I can't make sense of this supposed failure. fatal: unable to access 'https://gitlab.com/xen-project/hardware/xen.git/': Couldn't connect to server Networking failure. > >> Job #6362049553 ( https://gitlab.com/xen-project/hardware/xen/-/jobs/6362049553/raw ) >> >> Stage: test >> Name: build-each-commit-gcc > This one simply timed out once again, for it taking too long to build a > dozen commits in non-incremental fashion. Irritatingly the timeout is per-repo not a global setting.  I've bumped this back up to 3h to match the other main repos. ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Mar 11 11:15:06 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 11:15:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691406.1077351 (Exim 4.92) (envelope-from ) id 1rjdcS-0008D8-82; Mon, 11 Mar 2024 11:15:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691406.1077351; Mon, 11 Mar 2024 11:15:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjdcS-0008D1-5P; Mon, 11 Mar 2024 11:15:00 +0000 Received: by outflank-mailman (input) for mailman id 691406; Mon, 11 Mar 2024 11:14:58 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjdcQ-0008BZ-H6 for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 11:14:58 +0000 Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [2a00:1450:4864:20::531]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 97f5114f-df98-11ee-afdc-a90da7624cb6; Mon, 11 Mar 2024 12:14:57 +0100 (CET) Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-5683247fd0fso3918194a12.3 for ; Mon, 11 Mar 2024 04:14:57 -0700 (PDT) Received: from [10.80.5.21] (default-46-102-197-194.interdsl.co.uk. [46.102.197.194]) by smtp.gmail.com with ESMTPSA id cn19-20020a0564020cb300b0056828004c75sm2857898edb.51.2024.03.11.04.14.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Mar 2024 04:14:56 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 97f5114f-df98-11ee-afdc-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1710155697; x=1710760497; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=yod/563l2iAIl2xPs4D0/Pv76sN1ucJ7AXa1PUo2AV8=; b=QbJLNQACOEUS5b1m1AXJCes4zcX5d3U2ZNIiB8JRTOfuB4eVWcXQQtMSSHUoWxWbzL HJ16+/Imu6B5J1O2B4frTSGWcxAMeqphQuhzKvfiFTw+i11dxdXFjI49CJKcR9SHkfaO E69eyezvj3SDBrKb3mgGG6cOmN26ScUIk+H2w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710155697; x=1710760497; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=yod/563l2iAIl2xPs4D0/Pv76sN1ucJ7AXa1PUo2AV8=; b=VKDTCOOG756yympi6q7wcYvwnm4fHj8xp5eSz+H5Fnvfn/oE3ZhvLvF4oQgReGH7up hkgiMXNpg0G2fLRyIFcM0WJ8AvIXK38IHk9OeO6NvLECVvvpc/JHfEJ95IW3At9+yZ9J PAMVL1bD58SmnMg5tN7/JTNfxLJwO1ZL496FGbBPRN9AZrdey7DOJ1iMADKLpno9v55i +nLU9aiO0htQEyu15z9IxvjLQkd0s7RBtRkYxcRNSOu7j7lFuTo/JLOlZKZsnIDyXfLg bN9GgTPetA4p6FciD9o9ezSE/YTtq+KfUo1Wwx1NpGCaRHUyLIOkIJW1NIryX8Uqfp+B XrJw== X-Forwarded-Encrypted: i=1; AJvYcCV0l7sVmhhNzEhwSvvuEJBlRY74OhSALeRKJn0LsPsxCMKOC90tgPWUBakMZd5n37nX2NsUgQs5CPCSmivwRgosHsBU6+h7FYy0b17mgoQ= X-Gm-Message-State: AOJu0Yyy00nrstHx4j+s4saLwZCvcaUFMpy5AA2Tu4/qoWJ8vAnk35ps q/O86I4i1DrvfzUkYe0IhKgzJLsb+lT/0nxBxuspg5Btc1vMKYcYe2Y0JlSIoSc= X-Google-Smtp-Source: AGHT+IFhaM3MYXHZJttcahwtr8QDA1HFZ+hQDhu2HVwGMaoI8U+5xg8L/iqtb1tDad1gSGIYLNgd9w== X-Received: by 2002:a50:cc9c:0:b0:567:fb9b:37d5 with SMTP id q28-20020a50cc9c000000b00567fb9b37d5mr4198119edi.32.1710155696847; Mon, 11 Mar 2024 04:14:56 -0700 (PDT) Message-ID: <18cb61b2-780c-4378-9279-b5764e9d99a6@cloud.com> Date: Mon, 11 Mar 2024 11:14:55 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/mm: fix detection of last L1 entry in modify_xen_mappings_lite() To: Andrew Cooper , Roger Pau Monne , xen-devel@lists.xenproject.org Cc: Jan Beulich , Wei Liu References: <20240311105416.4556-1-roger.pau@citrix.com> Content-Language: en-GB From: Alejandro Vallejo In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 11/03/2024 11:01, Andrew Cooper wrote: > On 11/03/2024 10:54 am, Roger Pau Monne wrote: >> The current logic to detect when to switch to the next L1 table is incorrectly >> using l2_table_offset() in order to notice when the last entry on the current >> L1 table has been reached. >> >> It should instead use l1_table_offset() to check whether the index has wrapped >> to point to the first entry, and so the next L1 table should be used. >> >> Fixes: 8676092a0f16 ('x86/livepatch: Fix livepatch application when CET is active') >> Signed-off-by: Roger Pau Monné > > Reviewed-by: Andrew Cooper > >> --- >> This fixes the osstest livepatch related crash, we have been lucky so far that >> the .text section didn't seem to have hit this. > > I'm very surprised too. > The two stages for software debugging: 1. I really don't see how it can possibly fail. 2. I really don't see how it could have possibly worked. From xen-devel-bounces@lists.xenproject.org Mon Mar 11 11:29:43 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 11:29:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691413.1077365 (Exim 4.92) (envelope-from ) id 1rjdqW-0002Qq-Iw; Mon, 11 Mar 2024 11:29:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691413.1077365; Mon, 11 Mar 2024 11:29:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjdqW-0002Qj-GO; Mon, 11 Mar 2024 11:29:32 +0000 Received: by outflank-mailman (input) for mailman id 691413; Mon, 11 Mar 2024 11:29:31 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjdqV-0002QZ-HX for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 11:29:31 +0000 Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [2a00:1450:4864:20::233]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id a0128b77-df9a-11ee-afdc-a90da7624cb6; Mon, 11 Mar 2024 12:29:29 +0100 (CET) Received: by mail-lj1-x233.google.com with SMTP id 38308e7fff4ca-2d28051376eso38152751fa.0 for ; Mon, 11 Mar 2024 04:29:29 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id fk6-20020a056402398600b005685eaa19d2sm853989edb.5.2024.03.11.04.29.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Mar 2024 04:29:29 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a0128b77-df9a-11ee-afdc-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1710156569; x=1710761369; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=Fw8THqtdVIILJCkIF8WdQcMGdgk7pbjBYcYVlpKgqDM=; b=eVCkp1KDu39vk+bcfXon18bX4ID1LK4mhA0afg7Jz0qbhkLySeyakCHt6jDeHqnBHt g9N2kRvMLQDjxXTA4hQ5us9AZMDpCeXqsQdGVv53sQsoQ9iQ4RzUKUXSay2WRAHRMigI 1iEZ1cd05KwtE6o87JlPD7p0BB7yjM8lHgZzbRzTWR9sgLxKB0dN7To8w4dZVwES2vav 3/luixDVymee1sK9/YPiN4w5IO0NgyQbXnTZu73oLvcAvnlUKWt6B4C4xaTbWcYrj11h ijnp86+3h7stgtIslk/RVoiw6iNfDpGZwRFQzrYZ2+mq6eSgZiYhkRIMTfL6W9P30uEe AaGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710156569; x=1710761369; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Fw8THqtdVIILJCkIF8WdQcMGdgk7pbjBYcYVlpKgqDM=; b=D4R4fGpKVxg3hHpsgyypfxFJgsT6Hd9VB5xSsGmlrQgfVGSt85VVwIVVa5umKdkoqt bgI8JgkZhRTs0K4XNvPkl/+85IztD8VGCv/yPNdsUSHTck+qY1OEy5AJJtuuh8rVU0vp G92xzq9yVy2lGCbMX9FvVWlyiYNelWVYfAYANFzU8k3FjWCvIFnP3Lk8XQWq5erlUhrE SyycNA19uHVFbrOEMxGUhHMsjDWezBwjE60L0Y35a2tb0IpOxBdHCm4FK3MUKoi6lIqZ uJkBH67xeRqvAoK0gyDSVqueYWXV9gObcTqqF3r9rteRO1hQCCi9hbGQCHivVAV7YaaY H+eQ== X-Forwarded-Encrypted: i=1; AJvYcCU2kEkFjq1+Y/4mEYDDXvm0h9+FQIgA8UyRt5iOkCJyc3hpvBSMABWKp0pV3rkCDh+AaKC2O/WY1mON0McCLyldf3zUjMwBJggqvDIOm+M= X-Gm-Message-State: AOJu0Yy7BLNMhVOnyevRkhYggKJGOs54MIY9QIuFLxKtcOlggFxPa6TW NxymMB4Brx92UDOGdR6Og40supfszBGG2mij7ixNHelZIpuIHTzoyuMpURrR6Q== X-Google-Smtp-Source: AGHT+IFkmyJFRPUDAKWXzI4HIB6i5NbZ5pU9U6PzknwegwRdnwn5B9uPjc8rydyYYih6P0g1IDnRsA== X-Received: by 2002:a2e:8e3a:0:b0:2d2:a8b3:a20e with SMTP id r26-20020a2e8e3a000000b002d2a8b3a20emr3524318ljk.53.1710156569312; Mon, 11 Mar 2024 04:29:29 -0700 (PDT) Message-ID: Date: Mon, 11 Mar 2024 12:29:30 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/mm: fix detection of last L1 entry in modify_xen_mappings_lite() Content-Language: en-US To: Roger Pau Monne Cc: Andrew Cooper , Wei Liu , xen-devel@lists.xenproject.org References: <20240311105416.4556-1-roger.pau@citrix.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20240311105416.4556-1-roger.pau@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 11.03.2024 11:54, Roger Pau Monne wrote: > The current logic to detect when to switch to the next L1 table is incorrectly > using l2_table_offset() in order to notice when the last entry on the current > L1 table has been reached. > > It should instead use l1_table_offset() to check whether the index has wrapped > to point to the first entry, and so the next L1 table should be used. > > Fixes: 8676092a0f16 ('x86/livepatch: Fix livepatch application when CET is active') > Signed-off-by: Roger Pau Monné > --- > This fixes the osstest livepatch related crash, we have been lucky so far that > the .text section didn't seem to have hit this. About half a megabyte more to go until .text could run into such an issue, I guess, just considering the core Xen image. Patches are presumably not large enough to stand a sufficient risk of hitting the issue. I think there's another latent problem though, related to this part of the comment ahead of the function: * It is the callers responsibility to not pass s or e in the middle of * superpages if changing the permission on the whole superpage is going to be * a problem. This only suggests that for a pointer into the middle of a superpage the effect may be wider than intended. But with s misaligned modulo 2Mb the superpage part of the loop would keep v misaligned, and if the 2nd 2Mb range wasn't a superpage, part of the range wouldn't be touched at all. Right now with .text always 2Mb-aligned (and with there not being a superpage mapping across _srodata) there's no issue as long as superpages aren't used in patch loading. Yet recall that .text used to be only 1Mb aligned in older Xen versions, and this fact isn't entirely set in stone when !XEN_ALIGN_2M. Jan From xen-devel-bounces@lists.xenproject.org Mon Mar 11 11:33:04 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 11:33:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691416.1077376 (Exim 4.92) (envelope-from ) id 1rjdtu-00045Y-1l; Mon, 11 Mar 2024 11:33:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691416.1077376; Mon, 11 Mar 2024 11:33:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjdtt-00045R-Ue; Mon, 11 Mar 2024 11:33:01 +0000 Received: by outflank-mailman (input) for mailman id 691416; Mon, 11 Mar 2024 11:33:00 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjdts-00045H-MR for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 11:33:00 +0000 Received: from mail-oa1-x2c.google.com (mail-oa1-x2c.google.com [2001:4860:4864:20::2c]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 1c75e208-df9b-11ee-afdc-a90da7624cb6; Mon, 11 Mar 2024 12:32:59 +0100 (CET) Received: by mail-oa1-x2c.google.com with SMTP id 586e51a60fabf-221e1910c3bso737280fac.1 for ; Mon, 11 Mar 2024 04:32:59 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1c75e208-df9b-11ee-afdc-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1710156778; x=1710761578; darn=lists.xenproject.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=bWI6rhjTQ7kTO17emW9lIPCEDSxGphud145pHZ5LsHg=; b=LtyIvvawdpANy2AuowQW2uvrT7Sy0KFCsfGt5Wjge18VfDVEqgsHoVBNPLjLErOUkv vaA+ZEpuYEWvLMYTXWoWx+AET8ArRdjF3M0Dnvi+ieNpViP9UqsmD20+TCCDb9KyY3+B qaL/JE/XAAQ/tQRB0FPAVAjezSiWPo9tIlMJI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710156778; x=1710761578; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=bWI6rhjTQ7kTO17emW9lIPCEDSxGphud145pHZ5LsHg=; b=TrsZHeM0ZlPRgiTL5i4LLuKZSPuVanMlu64phQbzRW+SzotGrZtDofYe8A7gl0xiOV ekOlVcb2BqUou0Y9/kYBLWaCAxVpfYQtqT/RXcswq1PPv9+vG+3mJRbVlFarzPpE6Sif XAR1FPhrJoTXKTDkgAgOaRpmORVZR0lhYSSkr3KMfJ98y3ySy3pl1nvcc658gS90TVyV DxyTtbkzHYx4+m5AawKtDW9VVryulAny0aI+nHcQ9lY9+Jp0MQXUTaG+jAO++wpm5mLy C1GvtpmpXCUALFQ80HWNxfknjjyPFagfDsE6dR45dC/cKuEP7pu0cSc417h8CX/ATPDK uXtw== X-Forwarded-Encrypted: i=1; AJvYcCVZdDdbQlFKl1YAI6chls5OBdzZTG4/4YblHOdBQVhgR9nJMZLfsaQR1dDCZILoyCiKYz1+z0SVyG00AY3AnbyQhi4OMVs711ox/U9b210= X-Gm-Message-State: AOJu0Yw3I8486Bw39oWyinmIFZe5/XTDNIgCT8ex2f7t8WHbKGJCSnP8 IxIZY7eo8eXU/+yu7E+A2iaDTqonQVLXm0cU94qK8ANQ9Y/Oo7lcbVgm44ql/ei7KzawaKlKPfs wlTuFOVqDgCuj/hhmcfmLdgpp8zNnk/EtVXzaZA== X-Google-Smtp-Source: AGHT+IELpPt4F0u++9xXEHuSWcKChQnBzcW1yF+YKNcpINgytJoAoCJm3v7vF/u5IVA4ElxJzus9+lo6ngHEhM+QmGM= X-Received: by 2002:a05:6870:d88d:b0:21e:bd75:1947 with SMTP id oe13-20020a056870d88d00b0021ebd751947mr6793099oac.59.1710156778018; Mon, 11 Mar 2024 04:32:58 -0700 (PDT) MIME-Version: 1.0 References: <5a8f90d6-6502-4d93-9fd7-45fea0ede24a@suse.com> In-Reply-To: From: George Dunlap Date: Mon, 11 Mar 2024 11:32:47 +0000 Message-ID: Subject: Re: [PATCH] do_multicall and MISRA Rule 8.3 To: Stefano Stabellini Cc: Jan Beulich , federico.serafini@bugseng.com, Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Julien Grall , Bertrand Marquis , xen-devel@lists.xenproject.org, michal.orzel@amd.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Mar 9, 2024 at 1:59=E2=80=AFAM Stefano Stabellini wrote: > > I would like to resurrect this thread and ask other opinions. > > > On Thu, 23 Nov 2023, Jan Beulich wrote: > > On 22.11.2023 22:46, Stefano Stabellini wrote: > > > Two out of three do_multicall definitions/declarations use uint32_t a= s > > > type for the "nr_calls" parameters. Change the third one to be > > > consistent with the other two. > > > > > > Link: https://lore.kernel.org/xen-devel/7e3abd4c0ef5127a07a60de1bf090= a8aefac8e5c.1692717906.git.federico.serafini@bugseng.com/ > > > Link: https://lore.kernel.org/xen-devel/alpine.DEB.2.22.394.230825150= 2430.6458@ubuntu-linux-20-04-desktop/ > > > Signed-off-by: Stefano Stabellini > > > --- > > > Note that a previous discussion showed disagreement between maintaine= rs > > > on this topic. The source of disagreements are that we don't want to > > > change a guest-visible ABI and we haven't properly documented how to = use > > > types for guest ABIs. > > > > > > As an example, fixed-width types have the advantage of being explicit > > > about their size but sometimes register-size types are required (e.g. > > > unsigned long). The C specification says little about the size of > > > unsigned long and today, and we even use unsigned int in guest ABIs > > > without specifying the expected width of unsigned int on the various > > > arches. As Jan pointed out, in Xen we assume sizeof(int) >=3D 4, but > > > that's not written anywhere as far as I can tell. > > > > > > I think the appropriate solution would be to document properly our > > > expectations of both fixed-width and non-fixed-width types, and how t= o > > > use them for guest-visible ABIs. > > > > > > In this patch I used uint32_t for a couple of reasons: > > > - until we have better documentation, I feel more confident in using > > > explicitly-sized integers in guest-visible ABIs > > > > I disagree with this way of looking at it. Guests don't invoke these > > functions directly, and our assembly code sitting in between already is > > expected to (and does) guarantee that (in the case here) unsigned int > > would be okay to use (as would be unsigned long, but at least on x86 > > that's slightly less efficient), in line with what ./CODING_STYLE says. > > > > Otoh structure definitions in the public interface of course need to > > use fixed with types (and still doesn't properly do so in a few cases). You didn't address the other argument, which was that all the other definitions have uint32_t; in particular, common/multicall.c:do_multicall() takes uint32_t. Surely that should match the non-compat definition in include/hypercall-defs.c? Whether they should both be `unsigned int` or `uint32_t` I don't really feel like I have a good enough grasp of the situation to form a strong opinion. -George From xen-devel-bounces@lists.xenproject.org Mon Mar 11 11:41:37 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 11:41:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691422.1077385 (Exim 4.92) (envelope-from ) id 1rje28-0006Bw-Rp; Mon, 11 Mar 2024 11:41:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691422.1077385; Mon, 11 Mar 2024 11:41:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rje28-0006Bp-Ou; Mon, 11 Mar 2024 11:41:32 +0000 Received: by outflank-mailman (input) for mailman id 691422; Mon, 11 Mar 2024 11:41:31 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rje27-0006Bj-Jx for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 11:41:31 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 4cf6eafd-df9c-11ee-a1ee-f123f15fe8a2; Mon, 11 Mar 2024 12:41:29 +0100 (CET) Received: from [192.168.1.9] (net-93-144-106-196.cust.vodafonedsl.it [93.144.106.196]) by support.bugseng.com (Postfix) with ESMTPSA id 63F214EE0C90; Mon, 11 Mar 2024 12:41:28 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 4cf6eafd-df9c-11ee-a1ee-f123f15fe8a2 Message-ID: <93179ace-f201-40d9-8348-372d59e4030b@bugseng.com> Date: Mon, 11 Mar 2024 12:41:27 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH v3 00/16] xen: address violation of MISRA C:2012 Directive 4.10 To: Jan Beulich Cc: consulting@bugseng.com, sstabellini@kernel.org, Andrew Cooper , George Dunlap , Julien Grall , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Doug Goldstein , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , xen-devel@lists.xenproject.org References: Content-Language: en-US From: Simone Ballarin Organization: BUGSENG In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 11/03/24 10:59, Jan Beulich wrote: > On 11.03.2024 09:59, Simone Ballarin wrote: >> The Xen sources contain violations of MISRA C:2012 Directive 4.10 whose headline states: >> "Precautions shall be taken in order to prevent the contents of a header file >> being included more than once". >> >> As stated in v2, the following naming convention has been estabilished: >> - arch/.../include/asm/ headers -> ASM__H >> - private headers -> __H >> - asm-generic headers -> ASM_GENERIC__H >> >> Since there would have been conflicting guards between architectures (which is a violation >> of the directive), > > Why would this be a violation? The two sets of headers aren't use together, > and any scan should only point out collisions in what's actively used, I'd > hope. > A header guard cannot be used multiple times in the same project, so it's a question of whether or not we want to consider each arch variant part of the same project. In case, we can define a new rule for these files. >> there has been a need for ASM headers to specify if the inclusion guard >> referred to ARM or X86. Hence it has been decided to adopt instead: >> - arch//include/asm//.h -> ASM____H >> >> The subdir used is the smallest possible to avoid collisions. For example, it has been >> observed that in "xen/arch/arm/include/asm/arm32" and "xen/arch/arm/include/asm/arm64" there >> are plenty of header files with the same name, hence _ARMxx_ was added as subdirectory. > > Why couldn't _ together be ARMxx there, allowing us to get > away with one less name component. > I agree. >> There has been a need to define a standard for generated headers too: >> - include/generated//.h-> GENERATED___H >> - arch//include/generated/asm/.h-> _GENERATED_ASM__H >> >> To summarize, here are all the rules that have been applied: >> - private headers -> __H > > And here is the full path? I thought I had indicated before that > this is going to lead to excessively long identifiers. > Yes, dir is the full path. This general fallback rule to use when more specific rules do not apply. If this generates excessively long guards, we can simply add more rules. >> - asm-generic headers -> ASM_GENERIC__H >> - arch//include/asm//.h -> ASM____H >> - include/generated//.h-> GENERATED___H >> - arch//include/generated/asm/.h-> _GENERATED_ASM__H > > And _ASM_ is merely a precaution for stuff appearing outside of asm/ (which > doesn't seem very likely)? > Yes, it is. Do you prefer dropping the _ARM_? > Jan -- Simone Ballarin, M.Sc. Field Application Engineer, BUGSENG (https://bugseng.com) From xen-devel-bounces@lists.xenproject.org Mon Mar 11 11:51:08 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 11:51:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691426.1077395 (Exim 4.92) (envelope-from ) id 1rjeBK-0008Bf-NP; Mon, 11 Mar 2024 11:51:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691426.1077395; Mon, 11 Mar 2024 11:51:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjeBK-0008BY-Kw; Mon, 11 Mar 2024 11:51:02 +0000 Received: by outflank-mailman (input) for mailman id 691426; Mon, 11 Mar 2024 11:51:00 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjeBI-0008BS-Ms for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 11:51:00 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjeBE-0003RM-QR; Mon, 11 Mar 2024 11:50:56 +0000 Received: from gw1.octic.net ([88.97.20.152] helo=[10.0.1.240]) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1rjeBE-00007L-Ef; Mon, 11 Mar 2024 11:50:56 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID; bh=eQO21LfS/aY0RyIaasupQpvJMEvM6d5GN2Ya6wT5+tE=; b=q8SfdCxKFYpRoZq/DqJOCz/27L SetGpQYTsLk14R13W4jMnHRLjY3nEspl8SuJUFNUEJf6IOXELiX6XspTsOsdnCLtfqPDIm1CdfjD9 insPoVJpDJ2i5boKsC+p53OoznLu00ZoWaQaD0u/OffIdKzxKExH74/lH2PaOb471ZeQ=; Message-ID: Date: Mon, 11 Mar 2024 11:50:54 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] do_multicall and MISRA Rule 8.3 Content-Language: en-GB To: George Dunlap , Stefano Stabellini Cc: Jan Beulich , federico.serafini@bugseng.com, Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Bertrand Marquis , xen-devel@lists.xenproject.org, michal.orzel@amd.com References: <5a8f90d6-6502-4d93-9fd7-45fea0ede24a@suse.com> From: Julien Grall In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi, On 11/03/2024 11:32, George Dunlap wrote: > On Sat, Mar 9, 2024 at 1:59 AM Stefano Stabellini > wrote: >> >> I would like to resurrect this thread and ask other opinions. >> >> >> On Thu, 23 Nov 2023, Jan Beulich wrote: >>> On 22.11.2023 22:46, Stefano Stabellini wrote: >>>> Two out of three do_multicall definitions/declarations use uint32_t as >>>> type for the "nr_calls" parameters. Change the third one to be >>>> consistent with the other two. >>>> >>>> Link: https://lore.kernel.org/xen-devel/7e3abd4c0ef5127a07a60de1bf090a8aefac8e5c.1692717906.git.federico.serafini@bugseng.com/ >>>> Link: https://lore.kernel.org/xen-devel/alpine.DEB.2.22.394.2308251502430.6458@ubuntu-linux-20-04-desktop/ >>>> Signed-off-by: Stefano Stabellini >>>> --- >>>> Note that a previous discussion showed disagreement between maintainers >>>> on this topic. The source of disagreements are that we don't want to >>>> change a guest-visible ABI and we haven't properly documented how to use >>>> types for guest ABIs. >>>> >>>> As an example, fixed-width types have the advantage of being explicit >>>> about their size but sometimes register-size types are required (e.g. >>>> unsigned long). The C specification says little about the size of >>>> unsigned long and today, and we even use unsigned int in guest ABIs >>>> without specifying the expected width of unsigned int on the various >>>> arches. As Jan pointed out, in Xen we assume sizeof(int) >= 4, but >>>> that's not written anywhere as far as I can tell. >>>> >>>> I think the appropriate solution would be to document properly our >>>> expectations of both fixed-width and non-fixed-width types, and how to >>>> use them for guest-visible ABIs. >>>> >>>> In this patch I used uint32_t for a couple of reasons: >>>> - until we have better documentation, I feel more confident in using >>>> explicitly-sized integers in guest-visible ABIs >>> >>> I disagree with this way of looking at it. Guests don't invoke these >>> functions directly, and our assembly code sitting in between already is >>> expected to (and does) guarantee that (in the case here) unsigned int >>> would be okay to use (as would be unsigned long, but at least on x86 >>> that's slightly less efficient), in line with what ./CODING_STYLE says. >>> >>> Otoh structure definitions in the public interface of course need to >>> use fixed with types (and still doesn't properly do so in a few cases). > > You didn't address the other argument, which was that all the other > definitions have uint32_t; in particular, > common/multicall.c:do_multicall() takes uint32_t. Surely that should > match the non-compat definition in include/hypercall-defs.c? > > Whether they should both be `unsigned int` or `uint32_t` I don't > really feel like I have a good enough grasp of the situation to form a > strong opinion. FWIW +1. We at least need some consistency. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Mon Mar 11 12:00:40 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 12:00:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691435.1077407 (Exim 4.92) (envelope-from ) id 1rjeKZ-0001pS-RK; Mon, 11 Mar 2024 12:00:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691435.1077407; Mon, 11 Mar 2024 12:00:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjeKZ-0001pL-MI; Mon, 11 Mar 2024 12:00:35 +0000 Received: by outflank-mailman (input) for mailman id 691435; Mon, 11 Mar 2024 12:00:35 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjeKZ-0001jR-4c for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 12:00:35 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id f737c340-df9e-11ee-afdc-a90da7624cb6; Mon, 11 Mar 2024 13:00:34 +0100 (CET) Received: from [192.168.1.9] (net-93-144-106-196.cust.dsl.teletu.it [93.144.106.196]) by support.bugseng.com (Postfix) with ESMTPSA id 3DAED4EE0C90; Mon, 11 Mar 2024 13:00:33 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f737c340-df9e-11ee-afdc-a90da7624cb6 Message-ID: <6472eb42-157a-4d6e-b5bb-daa74fbbd97b@bugseng.com> Date: Mon, 11 Mar 2024 13:00:32 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH v3 03/16] misra: add deviations for direct inclusion guards Content-Language: en-US To: Jan Beulich Cc: consulting@bugseng.com, sstabellini@kernel.org, Andrew Cooper , George Dunlap , Julien Grall , Wei Liu , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <1fdfec12fd2207c294f50d01d8ec32f890b915d7.1710145041.git.simone.ballarin@bugseng.com> From: Simone Ballarin Organization: BUGSENG In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 11/03/24 11:08, Jan Beulich wrote: > On 11.03.2024 09:59, Simone Ballarin wrote: >> Add deviation comments to address violations of >> MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order >> to prevent the contents of a header file being included more than >> once"). >> >> Inclusion guards must appear at the beginning of the headers >> (comments are permitted anywhere). >> >> This patch adds deviation comments using the format specified >> in docs/misra/safe.json for headers with just the direct >> inclusion guard before the inclusion guard since they are >> safe and not supposed to comply with the directive. >> >> Signed-off-by: Simone Ballarin >> >> --- >> Changes in v3: >> - fix inconsistent deviation ID >> The patch has been introduced in v2. >> --- >> docs/misra/safe.json | 8 ++++++++ >> xen/arch/arm/include/asm/hypercall.h | 1 + >> xen/arch/x86/include/asm/hypercall.h | 1 + >> 3 files changed, 10 insertions(+) > > What about asm-generic/hypercall.h? Apparently the file is not part of the analysed build. > >> --- a/xen/arch/arm/include/asm/hypercall.h >> +++ b/xen/arch/arm/include/asm/hypercall.h >> @@ -1,3 +1,4 @@ >> +/* SAF-5-safe direct inclusion guard before */ >> #ifndef __XEN_HYPERCALL_H__ >> #error "asm/hypercall.h should not be included directly - include xen/hypercall.h instead" >> #endif >> --- a/xen/arch/x86/include/asm/hypercall.h >> +++ b/xen/arch/x86/include/asm/hypercall.h >> @@ -2,6 +2,7 @@ >> * asm-x86/hypercall.h >> */ >> >> +/* SAF-5-safe direct inclusion guard before */ >> #ifndef __XEN_HYPERCALL_H__ >> #error "asm/hypercall.h should not be included directly - include xen/hypercall.h instead" >> #endif > > Iirc it was said that this way checking for correct guards is suppressed > altogether in Eclair, which is not what we want. Can you clarify this, > please? > My first change was moving this check inside the guard. You commented my patch saying that this would be an error because someone can include it directly if it has already been included indirectly. I replied telling that this was the case also before the change. You agreed with me, and we decided that the correct thing would be fixing the check and not apply my temporary change to address the finding. Considering that the code should be amended, a SAF deviation seems to me the most appropriate way for suppressing these findings. > Jan > -- Simone Ballarin, M.Sc. Field Application Engineer, BUGSENG (https://bugseng.com) From xen-devel-bounces@lists.xenproject.org Mon Mar 11 12:07:10 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 12:07:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691440.1077415 (Exim 4.92) (envelope-from ) id 1rjeQr-0002V2-Di; Mon, 11 Mar 2024 12:07:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691440.1077415; Mon, 11 Mar 2024 12:07:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjeQr-0002Uv-B1; Mon, 11 Mar 2024 12:07:05 +0000 Received: by outflank-mailman (input) for mailman id 691440; Mon, 11 Mar 2024 12:07:04 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjeQq-0002Up-30 for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 12:07:04 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id df1fe9bf-df9f-11ee-afdc-a90da7624cb6; Mon, 11 Mar 2024 13:07:03 +0100 (CET) Received: from [192.168.1.9] (net-93-144-106-196.cust.vodafonedsl.it [93.144.106.196]) by support.bugseng.com (Postfix) with ESMTPSA id 6CACA4EE0C90; Mon, 11 Mar 2024 13:07:02 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: df1fe9bf-df9f-11ee-afdc-a90da7624cb6 Message-ID: Date: Mon, 11 Mar 2024 13:07:01 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH v3 04/16] xen/arm: address violations of MISRA C:2012 Directive 4.10 Content-Language: en-US To: Jan Beulich Cc: consulting@bugseng.com, sstabellini@kernel.org, Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Maria Celeste Cesario , xen-devel@lists.xenproject.org References: <868ede5a23489e018e272188edfbee572d1ad393.1710145041.git.simone.ballarin@bugseng.com> <332ebf49-9aa4-42fd-99be-bda16580c92f@suse.com> From: Simone Ballarin Organization: BUGSENG In-Reply-To: <332ebf49-9aa4-42fd-99be-bda16580c92f@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 11/03/24 11:10, Jan Beulich wrote: > On 11.03.2024 09:59, Simone Ballarin wrote: >> --- a/xen/arch/arm/efi/efi-boot.h >> +++ b/xen/arch/arm/efi/efi-boot.h >> @@ -3,6 +3,10 @@ >> * is intended to be included by common/efi/boot.c _only_, and >> * therefore can define arch specific global variables. >> */ >> + >> +#ifndef XEN_ARCH_ARM_EFI_EFI_BOOT_H >> +#define XEN_ARCH_ARM_EFI_EFI_BOOT_H > > Related to my question raised against the cover letter, what does the > XEN_ prefix gain us here? All building of the hypervisor binaries > happens inside the xen/ subtree. > > Jan what do you thing about adding this rule: arch/// -> ___H ? -- Simone Ballarin, M.Sc. Field Application Engineer, BUGSENG (https://bugseng.com) From xen-devel-bounces@lists.xenproject.org Mon Mar 11 12:09:04 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 12:09:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691450.1077425 (Exim 4.92) (envelope-from ) id 1rjeSl-00034V-Op; Mon, 11 Mar 2024 12:09:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691450.1077425; Mon, 11 Mar 2024 12:09:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjeSl-00034O-Lh; Mon, 11 Mar 2024 12:09:03 +0000 Received: by outflank-mailman (input) for mailman id 691450; Mon, 11 Mar 2024 12:09:01 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjeSj-00034E-So; Mon, 11 Mar 2024 12:09:01 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjeSj-0003oJ-PF; Mon, 11 Mar 2024 12:09:01 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjeSj-0004hF-Cy; Mon, 11 Mar 2024 12:09:01 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rjeSj-00068S-CS; Mon, 11 Mar 2024 12:09:01 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=OXI9sYvxBMps3hQP6lAEazckiQfH+EH3JsRDyEHgWKM=; b=FlpeARasaEvdy94Yylgrk5iUZz LvGQxnESI76op+WmzWta/rB+tR/rljsISpP9SpKfZ18t4yrp0/wYchnHfb1wig5nFKF/HoctzvT4h OvCMOTq/FEkW8x9Do5mFoZVcUza6Fo+5r+0mMHfuS8RcGR3VHMlHci033nHArttfnGKQ=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 184993: tolerable all pass - PUSHED X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=1396892d801cf148644cd5590be2f143648f9083 X-Osstest-Versions-That: xen=ef31ffbc3dc124173fc9420988772fa96bc4bf12 From: osstest service owner Date: Mon, 11 Mar 2024 12:09:01 +0000 flight 184993 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/184993/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass version targeted for testing: xen 1396892d801cf148644cd5590be2f143648f9083 baseline version: xen ef31ffbc3dc124173fc9420988772fa96bc4bf12 Last test of basis 184965 2024-03-09 03:00:25 Z 2 days Testing same since 184993 2024-03-11 09:02:15 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Henry Wang Jan Beulich Jason Andryuk Julien Grall Kevin Tian Nicola Vetrini Oleksii Kurochko Roger Pau Monné Shawn Anastasio Tamas K Lengyel 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-amd64 pass 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 ef31ffbc3d..1396892d80 1396892d801cf148644cd5590be2f143648f9083 -> smoke From xen-devel-bounces@lists.xenproject.org Mon Mar 11 12:12:42 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 12:12:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691462.1077436 (Exim 4.92) (envelope-from ) id 1rjeWD-0004rS-6W; Mon, 11 Mar 2024 12:12:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691462.1077436; Mon, 11 Mar 2024 12:12:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjeWD-0004rL-3v; Mon, 11 Mar 2024 12:12:37 +0000 Received: by outflank-mailman (input) for mailman id 691462; Mon, 11 Mar 2024 12:12:36 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjeWC-0004rD-7L for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 12:12:36 +0000 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on20600.outbound.protection.outlook.com [2a01:111:f403:2412::600]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id a3e60ad2-dfa0-11ee-afdc-a90da7624cb6; Mon, 11 Mar 2024 13:12:35 +0100 (CET) Received: from PH8PR12MB7326.namprd12.prod.outlook.com (2603:10b6:510:216::7) by SJ2PR12MB8830.namprd12.prod.outlook.com (2603:10b6:a03:4d0::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.34; Mon, 11 Mar 2024 12:12:30 +0000 Received: from PH8PR12MB7326.namprd12.prod.outlook.com ([fe80::32a0:32b6:d5af:9ad0]) by PH8PR12MB7326.namprd12.prod.outlook.com ([fe80::32a0:32b6:d5af:9ad0%5]) with mapi id 15.20.7362.035; Mon, 11 Mar 2024 12:12:30 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a3e60ad2-dfa0-11ee-afdc-a90da7624cb6 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FXP74RcxFOYoZ5WsbxL1BFHjDdD+rxQYaYqwVevU2A3NFoOJ1kJWmSQA7YTFOKUWGjRH7cRYwDCQlkEzPaKUF4mZswy23MBcw1JI0WBiTQsnG1KX73/Nal6lY0iHuSgnd5pY0OdGbWRA3TC16wcdFn9TBbabkAfBK1O5ycJN6XHwFWn7kQZ64P/I7aLUwBb8q31aiZFAn9QA4esXr8vzvy04H//0Ttkqae4cPMZqrGA1SrrMO8Gk1BIHxyoLiG3ucDP68zKXVV2g8eVU+H//+O1yi1LFH75rIXhx5ChR0zufZbCq8MZlY+Ap+LslO7Lxl7a65FPPiT4PlhSuYnh51A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=7elGRJ+5uZHqWxZOechfI8xXAJnZFubshb8angl6ins=; b=lfwOX9+vjuea2dQ0uEUo4wXcfBS6jdhOTxJhdZ7p6F4GLyCs9QGZWb3leIeeM/Qfs9cV4IksKUPLHALUbXfQ/SIril7dqGI96vb1p1qWvgRmkQCJSOBkWGkvkXeD+g0SAsq8jWPWK/2uGuz3vymnPuNKFh32y1EaWWQYorgFU64yS2icdlaUMW5Hoyu36wOEBUnQDUEaaVV9h/abHHBF79+OLdJVln1n2Lg3AcUUCNP7AdpBqYStkdUUD2GwOf826VNugNJgqTdT+5ZWu5ncJbCQywUzvqSXkj4KAdfbu7VUFF2YMX5q7edXHFDi9emj06uaux8CWQZUfeHf+i5oQQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7elGRJ+5uZHqWxZOechfI8xXAJnZFubshb8angl6ins=; b=KrrysTpowxWnF9pUAfbry/GRCUBTumpD6FMokSoqfHYXWOTlvW8nXPvcnRZV31pM7TjdzV+35gZtL7RAAx+Fv9eqvKHW2HieNclRqhTn5CLAbMhPy0YnrcUVyxioWWsAppUbvJ69Iq8nkRZBjKl3rHTTr+c6Wk08DfWUkzGA+QM= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; Message-ID: Date: Mon, 11 Mar 2024 12:12:24 +0000 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 13/15] xen/arm: make consider_modules() available for xen relocation To: Henry Wang , Julien Grall , Ayan Kumar Halder , xen-devel@lists.xenproject.org Cc: andrea.bastoni@minervasys.tech, Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Carlo Nonato References: <20240129171811.21382-1-carlo.nonato@minervasys.tech> <20240129171811.21382-14-carlo.nonato@minervasys.tech> <1439263a-c96d-48bb-bd3c-1427071ecd17@xen.org> <8df22d81-ce3d-4a90-8aa9-34ec66d237c6@amd.com> Content-Language: en-GB From: Ayan Kumar Halder In-Reply-To: <8df22d81-ce3d-4a90-8aa9-34ec66d237c6@amd.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0162.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:188::23) To PH8PR12MB7326.namprd12.prod.outlook.com (2603:10b6:510:216::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH8PR12MB7326:EE_|SJ2PR12MB8830:EE_ X-MS-Office365-Filtering-Correlation-Id: 50c4f2ac-17a7-4ef4-c190-08dc41c4861d X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: ZT3vLFTdzseovab42DdYh4je8BJ2l079b4LROtYU98je8c7etuMLmphzH9AuppiAoNuAfJqXPJ3MIk0duaL7kCr2XQ7axBig6FjjeyXZc4r49h/YR6a8OnjafBGarRG6CN+PedNVbh3qXzozWjPNxyw42fNtZuhfIfHwL+mL3pljMtlk575jZv16Q9eqw32OSyhDzbe0D+eFObnFILHCOsRtSWj9rhBBzM9c9pfadCLt5ws9x4IuuZUWRxCtrjBU2ifs+XlRk8L6IA8y5fKNiQnjAwKpn4Wy9BurkLVsYDzKClE23LyaFHo/wmasWEPNH2YjXQe0EPzFJ4NPXJ7VnEK/xu3IN0rNTj71St5tVR4XtASsVu2wujspwbWqWbG7z4YS1WKtffblLrYJGId7atRincmnRia4mtP4bnTigKsbMMWAy6FUMeYDnueBT0Du3X+5/USYULPsw1IHwOds3P5tdFYVbW0JmwuR6R154ELG8kiT3y5wFvKg/Snr8OMRsa6UoZflENx92n7H9albtK4dz8uZUnSuoIxJxNDCGhyPqeND6f2vWiSFyA1REDG/hnaVVAVrVCcqVpk57zsWDGbGu2ROSPhX86bYOJhTiscU2J+cKyFAdr49LFjf7xguL4zGf2Tg9dd027oGwsAGHY1ipJ78BZtbF6BgIfSOxjo= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH8PR12MB7326.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(1800799015)(376005);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?NEZjUTRRa1pLb0VlOXRMYTFNZ0pJNDUzNXpsS0FzNnNkSzJUMGtQdVNyNzZL?= =?utf-8?B?WFdNQVJmc2t6R2FERjVZNWtJU21zUk5nL09WenorWFJvSDlNb2ZkTVdBLzN2?= =?utf-8?B?OFZmeEdYVk9pUERxZStCVFFadGM2Vi9RZXBQeTc3RnJYdjZMc2NLYXFLSElK?= =?utf-8?B?bDBTdmxlL1VsK3owQlMrYUswdmgyTjRVVElFa3lqUmhEODM2WXZSaTRlZFRk?= =?utf-8?B?eVZDMWJmSDBkOENqUFk3OFFqYWsyb3RIUkQ0d3lHek5ZYkNVSHk2b2Z3UUNl?= =?utf-8?B?NjVkdzZ4UHZremRrTGFuR292anZRS2dRYnI5WHI4UkMza2licGIxQk9aTlAr?= =?utf-8?B?LzNsdU04ZG5Gdk5RblhUdmloMys0KzRsbTZ6eHF2Sk0xNGpLVlN4RGF2aXRC?= =?utf-8?B?T0R2VXhlTG9VZnpQaUlvK0YvYk5kMFovcUZqTUxFVDNnSGdWdTRGdWxXc2Jr?= =?utf-8?B?bk91aFVocGlzajVKdlNtc01lWmdJZEdUTmd4SkZueFkyWTVndWdoSkUxaFo2?= =?utf-8?B?djdsOXpZMUZ0ZkJEc05nNGpza0x4K1JhdUg5M1RFTUVDUGZCNDNtVXBYME9j?= =?utf-8?B?Nzh0SVFrYkdneFQ2YmV3dzV6UGQwUTZ0SG1RczlHMGJwQ2V6WGtOdEtnTy9o?= =?utf-8?B?TlgzdUpwZVo5NWRzOXV2R2xkWkpnK0Z4NkFyT05NMjVuNjFsRkxVZWJYYXcv?= =?utf-8?B?RzVGU1VjMkFjaXFUMGhWTHFsYzFDYUZwQXpvTkpzanZXN0tWK2VCcm1yb0hD?= =?utf-8?B?ZUIrUG9nekpodnFpdllNMVpGS3IxNGZkckkyeWozTGpRUWFQRG93Q2FRN0J4?= =?utf-8?B?T2oyMnBldFJoNDdXTU13Smk2dytjL3BJVERkWkM5Y3JBc0swcXp3aHhzUmpw?= =?utf-8?B?dytzWmsyKzFocVhPRVhvTUtWR0NTNkk3NXBFa0pENS81ZURuakRyZldxZHd4?= =?utf-8?B?bDE1WmEzUytQYSs3ZU1CZ3BDYWk3bDZyRDNvOVlkMTdxNzFrcFdITEZ6cUhZ?= =?utf-8?B?c2w2eXkwZmlGVnJrRnltVm1TYm1RdmkxNVFNdTZ1TXZ3WU9pTVJ6NDBGQjhD?= =?utf-8?B?KzZOZlZLM25jNjhtWlFYVHV4LytaUGZiNWFwZzkvdTNvbjdhY1h5YVpQQXV3?= =?utf-8?B?aS9DSWFLd0ZJTDNtaFVTaHNiSXl0ZFBScFFlOThENzVzTHJISWlHeXRnN0J2?= =?utf-8?B?djhkVHphM3E0SjV3YkQ0UmF3WnMveVlqOSt4VDZTdjlaSE1rTmdFNloxTko4?= =?utf-8?B?ZE5pbThZRmprRlVYOVZ6eXltVjQ2ZHFxcHBkdDIxMHJGa0JRU05oZHFhT1Zx?= =?utf-8?B?OXl1SjZZa0Zvb1hUektOUjI3bjB3NHNlSUVWZWNFQ2N0L2pzaDR6dGw0R2Jw?= =?utf-8?B?Y2dhQ042VDV6YXNkQlJoUUpaNDNkRGEzVWZWTDd0UTU1YytyRG0rZlMzYU9Y?= =?utf-8?B?RGJmRHhuRnZKK0NkS1hDYXlESU5BOWxUMHFQc1ZkWEdCeTdDbUNWSlcyeXZV?= =?utf-8?B?cVlUeG01SkZRc0NOdC92NkhlWGFqTXpxcGhxblg2aWpyR0RZLzRSMktqd0Fk?= =?utf-8?B?UVJhWklYSjJyQnJGMG1WTVl4ZXRHcmZERHk4N0N2MmUveXdFdjJpMFZ6NGQ4?= =?utf-8?B?MXYzb1ZvSlc1V1dxQTFBMnl4M1BNZ2JnTE8wN1NWcHo2S2dRWFQ0Ty96OVNC?= =?utf-8?B?ZGpMVmlkbmg1VFh2clNYbmdTTlpOZVdRUjNZTmxiSTdLa2VpdWZHTnFISVJq?= =?utf-8?B?eHJxWGNXU0JkY1g3R3JZelNtNm94a05nU2FRNkk4Z0wxSE94WEFLODlvWDVi?= =?utf-8?B?ZlhrSitZZVZ1aDBhTzRsbkJXWFhseVBFZDc5eTl1YnpkY0tsRUwxaUZuelRH?= =?utf-8?B?N3N0UTg3NlZIbUwveXU5WE0wNEJTQzRvM2luVkx2Wmdlby9vbUJDOHFOKzk5?= =?utf-8?B?eFQxYlFaMVFDdTR1LzVOWm5MSk90QVlvRkdjTlFvc3lyek80MzY2c3BSVVdN?= =?utf-8?B?UWZNb3A1a3R0SkxMUlRGOXVrL3c1SmltbVdiY0ZLSmJNcnRldkZENjNMaDZP?= =?utf-8?B?UnZVRzZmS2t4NWpXY0QwVXR0OTZXbktJblcxZDhzK2xxVkhhSmZPbG1lUHF2?= =?utf-8?Q?1ewl/J+bGSApXe9b9RjyayZEY?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 50c4f2ac-17a7-4ef4-c190-08dc41c4861d X-MS-Exchange-CrossTenant-AuthSource: PH8PR12MB7326.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Mar 2024 12:12:30.2264 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: R2C6PvptPf6HnsAAqeKeips5ZmahWg9aDp+s2SUOguZ0U50avWFGvMA83fc13STapU61XSBG5VVsGiNrXbj8EQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB8830 On 09/03/2024 06:44, Henry Wang wrote: > Hi Julien, Hi Julien/Henry, > > On 3/9/2024 6:30 AM, Julien Grall wrote: >> (+ Ayan + Henry) > > (- my old email address + the new one) > >> Hi Carlo, >> >> On 29/01/2024 17:18, Carlo Nonato wrote: >>> Cache coloring must physically relocate Xen in order to color the >>> hypervisor >>> and consider_modules() is a key function that is needed to find a new >>> available physical address. >>> >>> 672d67f339c0 ("xen/arm: Split MMU-specific setup_mm() and related >>> code out") >>> moved consider_modules() under arm32. Move it back to setup.c and >>> make it >>> non-static so that it can be used outside. >>> >>> Signed-off-by: Carlo Nonato >>> --- >>> v6: >>> - new patch >>> --- >>>   xen/arch/arm/arm32/mmu/mm.c      | 93 >>> +------------------------------- >>>   xen/arch/arm/include/asm/setup.h |  3 ++ >>>   xen/arch/arm/setup.c             | 92 +++++++++++++++++++++++++++++++ >> >> Ayan, Henry, will the function consider_modules() be used for the MPU >> code? > > I checked all the MPU branches (the recent arm64 implementation and an > arm32 branch to my best knowledge), no I don't think the function will > be used for the MPU code. However I am not sure if Ayan has a newer > arm32 MPU branch on top of the latest staging or so using the > function, Ayan would you like to add some comments? Yes, Henry is correct. consider_modules() is mmu specific only. - Ayan > >> If not, then I think the function should live in arm/mmu/setup.c. > > +1, arm/mmu/setup.c is a good place. > > Kind regards, > Henry > >> >> Cheers, >> > From xen-devel-bounces@lists.xenproject.org Mon Mar 11 12:40:29 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 12:40:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691470.1077463 (Exim 4.92) (envelope-from ) id 1rjex5-0001Ye-Vm; Mon, 11 Mar 2024 12:40:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691470.1077463; Mon, 11 Mar 2024 12:40:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjex5-0001XA-Pa; Mon, 11 Mar 2024 12:40:23 +0000 Received: by outflank-mailman (input) for mailman id 691470; Mon, 11 Mar 2024 12:40:22 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjex4-0001Rf-IE for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 12:40:22 +0000 Received: from mail137-23.atl71.mandrillapp.com (mail137-23.atl71.mandrillapp.com [198.2.137.23]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 85ae7c8b-dfa4-11ee-afdc-a90da7624cb6; Mon, 11 Mar 2024 13:40:21 +0100 (CET) Received: from pmta07.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail137-23.atl71.mandrillapp.com (Mailchimp) with ESMTP id 4Ttbw42Nt0z1XLHZT for ; Mon, 11 Mar 2024 12:40:20 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id ba8489844df646b8be3e19510b24de5f; Mon, 11 Mar 2024 12:40:20 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 85ae7c8b-dfa4-11ee-afdc-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1710160820; x=1710421320; bh=Cxgq3bbdihMzzz0i/yJ6y0gLddK7ZJN9AgjAgXDglbY=; h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=ewq9IwVliO7fJjXd7JSJPnb4ywN9wTTx2jye8wjZNGU0eoCTC0aZQzrrRQjsWBXdA Wy8yh/dqthYroV9uSuGuv+/sVKrAQRVugZro7WVwTfcM8K4O/X+435G/YNRMN3KmR1 nQp2ztlYJh8Qoko8XcoiS3IAY0h39RmQQ9e7wL3rWSDfiHdHM6RQQCwmhASXV7aKCq 1YwAXPXqyzoaEujfsDTzpRK+YHtmK0GaC+1M2nMWLYTZxy6BOwTrx362mRc7K1QdK1 aDy/0SGoYEIwlm4kojcR8ls8GJsLp08j6QwEyVwTciAMEZWV0cREO7o5dDbrHGppgx MRFt4bIDwMXtw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1710160820; x=1710421320; i=vaishali.thakkar@vates.tech; bh=Cxgq3bbdihMzzz0i/yJ6y0gLddK7ZJN9AgjAgXDglbY=; h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=EPJLYuhCeQWHHb/RwHi5+jxffaZLJco29SZ99Rxu7aiAGdwhTJMIgn2ajhSBId+ru rDfYOkvohrFAauPB5AAdF7Kz9qYtx9X5e5u5//iC6ccKKce+wKoWvfWxRL+nMNhW+s 1a6SGNT7etd171Jtp78QiTNVFUFSJL5kKz8bc7sefqfBIaOjeZaipZDg7Dp6j0xEA9 OtMcqhtHxTwkdLKFsxzgfgGZNU7t6jGqvkeAiIP6/w/OsXXU21zVsDi/YL7Jvignwt PIWS0TWdih6eDTfp1FD34bKCGF8I2oh93wpt5mmbeNTCXs5GJhpDY85BU52kOnPWva ku0dA3aX9OuoA== From: Vaishali Thakkar Subject: =?utf-8?Q?[PATCH=20v2=202/3]=20x86/svm:=20Drop=20the=20suffix=20=5Fguest=20from=20vmcb=20bit?= X-Mailer: git-send-email 2.44.0 X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1710160819329 To: xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger.pau@citrix.com, wl@xen.org, Vaishali Thakkar Message-Id: In-Reply-To: References: X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.ba8489844df646b8be3e19510b24de5f?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20240311:md Date: Mon, 11 Mar 2024 12:40:20 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit The suffix _guest is redundant for asid bit. Drop it to avoid adding extra code volume. Suggested-by: Andrew Cooper Signed-off-by: Vaishali Thakkar --- Changes since v1: - This patch wasn't part of v1. It's been added to address Andrew's suggestion. --- xen/arch/x86/hvm/svm/asid.c | 6 +++--- xen/arch/x86/hvm/svm/nestedsvm.c | 8 ++++---- xen/arch/x86/hvm/svm/svmdebug.c | 4 ++-- xen/arch/x86/include/asm/hvm/svm/nestedsvm.h | 2 +- xen/arch/x86/include/asm/hvm/svm/vmcb.h | 6 +++--- 5 files changed, 13 insertions(+), 13 deletions(-) diff --git a/xen/arch/x86/hvm/svm/asid.c b/xen/arch/x86/hvm/svm/asid.c index 28e0dbc176..d5f70f8848 100644 --- a/xen/arch/x86/hvm/svm/asid.c +++ b/xen/arch/x86/hvm/svm/asid.c @@ -37,14 +37,14 @@ void svm_asid_handle_vmrun(void) /* ASID 0 indicates that ASIDs are disabled. */ if ( p_asid->asid == 0 ) { - vmcb_set_guest_asid(vmcb, 1); + vmcb_set_asid(vmcb, 1); vmcb->tlb_control = cpu_has_svm_flushbyasid ? TLB_CTRL_FLUSH_ASID : TLB_CTRL_FLUSH_ALL; return; } - if ( vmcb_get_guest_asid(vmcb) != p_asid->asid ) - vmcb_set_guest_asid(vmcb, p_asid->asid); + if ( vmcb_get_asid(vmcb) != p_asid->asid ) + vmcb_set_asid(vmcb, p_asid->asid); vmcb->tlb_control = !need_flush ? TLB_CTRL_NO_FLUSH : diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c index 37548cf05c..adbd49b5a2 100644 --- a/xen/arch/x86/hvm/svm/nestedsvm.c +++ b/xen/arch/x86/hvm/svm/nestedsvm.c @@ -157,7 +157,7 @@ int cf_check nsvm_vcpu_reset(struct vcpu *v) svm->ns_hap_enabled = 0; svm->ns_vmcb_guestcr3 = 0; svm->ns_vmcb_hostcr3 = 0; - svm->ns_guest_asid = 0; + svm->ns_asid = 0; svm->ns_hostflags.bytes = 0; svm->ns_vmexit.exitinfo1 = 0; svm->ns_vmexit.exitinfo2 = 0; @@ -698,11 +698,11 @@ nsvm_vcpu_vmentry(struct vcpu *v, struct cpu_user_regs *regs, /* Convert explicitely to boolean. Deals with l1 guests * that use flush-by-asid w/o checking the cpuid bits */ nv->nv_flushp2m = !!ns_vmcb->tlb_control; - if ( svm->ns_guest_asid != ns_vmcb->_guest_asid ) + if ( svm->ns_asid != ns_vmcb->_asid ) { nv->nv_flushp2m = 1; hvm_asid_flush_vcpu_asid(&vcpu_nestedhvm(v).nv_n2asid); - svm->ns_guest_asid = ns_vmcb->_guest_asid; + svm->ns_asid = ns_vmcb->_asid; } /* nested paging for the guest */ @@ -1046,7 +1046,7 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs) /* Keep it. It's maintainted by the l1 guest. */ /* ASID */ - /* ns_vmcb->_guest_asid = n2vmcb->_guest_asid; */ + /* ns_vmcb->_asid = n2vmcb->_asid; */ /* TLB control */ ns_vmcb->tlb_control = 0; diff --git a/xen/arch/x86/hvm/svm/svmdebug.c b/xen/arch/x86/hvm/svm/svmdebug.c index 24358c6eea..0d714c728c 100644 --- a/xen/arch/x86/hvm/svm/svmdebug.c +++ b/xen/arch/x86/hvm/svm/svmdebug.c @@ -51,8 +51,8 @@ void svm_vmcb_dump(const char *from, const struct vmcb_struct *vmcb) vmcb->exitcode, vmcb->exit_int_info.raw); printk("exitinfo1 = %#"PRIx64" exitinfo2 = %#"PRIx64"\n", vmcb->exitinfo1, vmcb->exitinfo2); - printk("np_ctrl = %#"PRIx64" guest_asid = %#x\n", - vmcb_get_np_ctrl(vmcb), vmcb_get_guest_asid(vmcb)); + printk("np_ctrl = %#"PRIx64" asid = %#x\n", + vmcb_get_np_ctrl(vmcb), vmcb_get_asid(vmcb)); printk("virtual vmload/vmsave = %d, virt_ext = %#"PRIx64"\n", vmcb->virt_ext.fields.vloadsave_enable, vmcb->virt_ext.bytes); printk("cpl = %d efer = %#"PRIx64" star = %#"PRIx64" lstar = %#"PRIx64"\n", diff --git a/xen/arch/x86/include/asm/hvm/svm/nestedsvm.h b/xen/arch/x86/include/asm/hvm/svm/nestedsvm.h index 406fc082b1..7767cd6080 100644 --- a/xen/arch/x86/include/asm/hvm/svm/nestedsvm.h +++ b/xen/arch/x86/include/asm/hvm/svm/nestedsvm.h @@ -51,7 +51,7 @@ struct nestedsvm { * the l1 guest nested page table */ uint64_t ns_vmcb_guestcr3, ns_vmcb_hostcr3; - uint32_t ns_guest_asid; + uint32_t ns_asid; bool ns_hap_enabled; diff --git a/xen/arch/x86/include/asm/hvm/svm/vmcb.h b/xen/arch/x86/include/asm/hvm/svm/vmcb.h index 76507576ba..5d539fcdcf 100644 --- a/xen/arch/x86/include/asm/hvm/svm/vmcb.h +++ b/xen/arch/x86/include/asm/hvm/svm/vmcb.h @@ -383,7 +383,7 @@ typedef union bool intercepts:1; /* 0: cr/dr/exception/general intercepts, * pause_filter_count, tsc_offset */ bool iopm:1; /* 1: iopm_base_pa, msrpm_base_pa */ - bool asid:1; /* 2: guest_asid */ + bool asid:1; /* 2: asid */ bool tpr:1; /* 3: vintr */ bool np:1; /* 4: np_enable, h_cr3, g_pat */ bool cr:1; /* 5: cr0, cr3, cr4, efer */ @@ -413,7 +413,7 @@ struct vmcb_struct { u64 _iopm_base_pa; /* offset 0x40 - cleanbit 1 */ u64 _msrpm_base_pa; /* offset 0x48 - cleanbit 1 */ u64 _tsc_offset; /* offset 0x50 - cleanbit 0 */ - u32 _guest_asid; /* offset 0x58 - cleanbit 2 */ + u32 _asid; /* offset 0x58 - cleanbit 2 */ u8 tlb_control; /* offset 0x5C - TLB_CTRL_* */ u8 res07[3]; vintr_t _vintr; /* offset 0x60 - cleanbit 3 */ @@ -642,7 +642,7 @@ VMCB_ACCESSORS(pause_filter_thresh, intercepts) VMCB_ACCESSORS(tsc_offset, intercepts) VMCB_ACCESSORS(iopm_base_pa, iopm) VMCB_ACCESSORS(msrpm_base_pa, iopm) -VMCB_ACCESSORS(guest_asid, asid) +VMCB_ACCESSORS(asid, asid) VMCB_ACCESSORS(vintr, tpr) VMCB_ACCESSORS(np_ctrl, np) VMCB_ACCESSORS_(np, bool, np) -- 2.44.0 From xen-devel-bounces@lists.xenproject.org Mon Mar 11 12:40:29 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 12:40:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691471.1077476 (Exim 4.92) (envelope-from ) id 1rjex9-0001wy-4p; Mon, 11 Mar 2024 12:40:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691471.1077476; Mon, 11 Mar 2024 12:40:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjex9-0001wo-1O; Mon, 11 Mar 2024 12:40:27 +0000 Received: by outflank-mailman (input) for mailman id 691471; Mon, 11 Mar 2024 12:40:26 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjex7-0001DQ-Vd for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 12:40:25 +0000 Received: from mail133-16.atl131.mandrillapp.com (mail133-16.atl131.mandrillapp.com [198.2.133.16]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 876d2021-dfa4-11ee-a1ee-f123f15fe8a2; Mon, 11 Mar 2024 13:40:24 +0100 (CET) Received: from pmta13.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail133-16.atl131.mandrillapp.com (Mailchimp) with ESMTP id 4Ttbw71sPJzB5p4sx for ; Mon, 11 Mar 2024 12:40:23 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 6e106d0a939c4ed98993494d8a9ebb63; Mon, 11 Mar 2024 12:40:23 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 876d2021-dfa4-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1710160823; x=1710421323; bh=ObAF48AeNm2DpnzGP89I41fPkikpyHP3PqijIW+HbJw=; h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=zsEQ87j2Raj6duvyqT7L88rKgjns1yT66T5Hhk6ds9gfjeC/frAIalQhnQh5rlv+X i5UCKxzQRUxwxnNdrPtFK5qtDloWh4/oJDeuIZoY8vigq83FpZKThPi6Sv29af0Oll BEPiLFN/T1ffPpsJsHnxKlo6MbhOcINQ61P1tX1haXN3aedowv0O0UZ5EAPvxDPLEA okdAcl3hh7UZQT0dmnKzQ93rkMuri1AXFC7pfwSm5k4ZLsND2K+uwfWwBBiUXV1W72 EC4Sol5PvLTYboAjI7zRIOOTTC/RrDN/VEkVwaO2ziZFCRYDQnLFS43NmNKJNM5bpS zS6NaQHXVdtmQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1710160823; x=1710421323; i=vaishali.thakkar@vates.tech; bh=ObAF48AeNm2DpnzGP89I41fPkikpyHP3PqijIW+HbJw=; h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=d3BTdvb9m6Ine2ZVIvNrtZIi7F/LCubi9egWqs2/GZFiVT8W7bjDaf/ZVwIon7qS+ us/WtsDn3HJIgWsA2Rn0owd/rhjM/NIiq0a9sH23IE0D7NV8xtGqqhBZsssCU5/O4J cBAWL0sS+ASyTC6Juh/HQBl1X6I1rlHHDSOpvNPzEYLKXdJ9XoMm8rfECUIVZNd8pi Q9KTrUR34NQlnFPiql/Wxhcj8Onvlf80jlAmi9v0fIKWObJqsIn1WQdih6cHbITKFk YalhZNZmP9HJcIARXNW+l0p7+o8voBa2WHZTcz27dUBzc0ca78WVYZGN4Lri5bzCnd DSO6hAoOr1HRg== From: Vaishali Thakkar Subject: =?utf-8?Q?[PATCH=20v2=203/3]=20x86/svmdebug:=20Print=20sev=20and=20sev=5Fes=20vmcb=20bits?= X-Mailer: git-send-email 2.44.0 X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1710160820928 To: xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger.pau@citrix.com, wl@xen.org, Vaishali Thakkar Message-Id: <0e688a18a97e495352e2b08cb7634abbc238da1b.1710149462.git.vaishali.thakkar@vates.tech> In-Reply-To: References: X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.6e106d0a939c4ed98993494d8a9ebb63?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20240311:md Date: Mon, 11 Mar 2024 12:40:23 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit While sev and sev_es bits are not yet enabled in xen, including their status in the VMCB dump could be informational.Therefore, print it via svmdebug. Signed-off-by: Vaishali Thakkar --- Changes since v1: - Pretty printing --- xen/arch/x86/hvm/svm/svmdebug.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/hvm/svm/svmdebug.c b/xen/arch/x86/hvm/svm/svmdebug.c index 0d714c728c..ba5fa40071 100644 --- a/xen/arch/x86/hvm/svm/svmdebug.c +++ b/xen/arch/x86/hvm/svm/svmdebug.c @@ -51,8 +51,11 @@ void svm_vmcb_dump(const char *from, const struct vmcb_struct *vmcb) vmcb->exitcode, vmcb->exit_int_info.raw); printk("exitinfo1 = %#"PRIx64" exitinfo2 = %#"PRIx64"\n", vmcb->exitinfo1, vmcb->exitinfo2); - printk("np_ctrl = %#"PRIx64" asid = %#x\n", - vmcb_get_np_ctrl(vmcb), vmcb_get_asid(vmcb)); + printk("asid = %#x np_ctrl = %#"PRIx64" - %s%s%s\n", + vmcb_get_asid(vmcb), vmcb_get_np_ctrl(vmcb), + vmcb_get_np(vmcb) ? "NP" : "", + vmcb_get_sev(vmcb) ? "SEV" : "", + vmcb_get_sev_es(vmcb) ? "SEV_ES" : ""); printk("virtual vmload/vmsave = %d, virt_ext = %#"PRIx64"\n", vmcb->virt_ext.fields.vloadsave_enable, vmcb->virt_ext.bytes); printk("cpl = %d efer = %#"PRIx64" star = %#"PRIx64" lstar = %#"PRIx64"\n", -- 2.44.0 From xen-devel-bounces@lists.xenproject.org Mon Mar 11 12:40:29 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 12:40:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691469.1077457 (Exim 4.92) (envelope-from ) id 1rjex5-0001S3-ID; Mon, 11 Mar 2024 12:40:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691469.1077457; Mon, 11 Mar 2024 12:40:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjex5-0001Rw-Da; Mon, 11 Mar 2024 12:40:23 +0000 Received: by outflank-mailman (input) for mailman id 691469; Mon, 11 Mar 2024 12:40:22 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjex4-0001Rf-B4 for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 12:40:22 +0000 Received: from mail133-16.atl131.mandrillapp.com (mail133-16.atl131.mandrillapp.com [198.2.133.16]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 850c4a39-dfa4-11ee-afdc-a90da7624cb6; Mon, 11 Mar 2024 13:40:20 +0100 (CET) Received: from pmta13.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail133-16.atl131.mandrillapp.com (Mailchimp) with ESMTP id 4Ttbw25VXTzB5p4t7 for ; Mon, 11 Mar 2024 12:40:18 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id baf6d3bc498b4aa2b7c9b531ba09262f; Mon, 11 Mar 2024 12:40:18 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 850c4a39-dfa4-11ee-afdc-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1710160818; x=1710421318; bh=KPvVYpZqmz9UEvKzcaJVoJvfsDLmwkcYJ6FKhk1ss8M=; h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=p8vkAxuq10vAoTKmOECat0acqO3h0gyDSE5tOZGKhyhHeK6yW0bt1/vTVyB5hAzhu DEvaDkFsMGjUCIeKjppdaYImhnS0rkK3hnGYGnvGgZYzW1UUaB+tFrC9M6uQyzhted fAHpwepwzZ4CwtKgfCdYNtyCVCwBSmtkJuzxNr9RiL1WGxP0DmBqxfMQ8h+8tpXUY5 rfrE1nmDEb873seGyZzezc8lQs6lRvU/LXeGSzgZVxKvsCmtVQ6SmE+euxUVhnv2iF 1ANNl62BXTg08KIQvY5FkDwvRQBtCV+UQBW2lX5LRB/LgJqUV/WpZ+l8xBYCcDU0Xr oWvUIEC+XJ5Bg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1710160818; x=1710421318; i=vaishali.thakkar@vates.tech; bh=KPvVYpZqmz9UEvKzcaJVoJvfsDLmwkcYJ6FKhk1ss8M=; h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=Cyq8/FCo8+YTOdXDgwufyuTDg1AEd/gg8eckxOZfZ5FnhjH+vLPNhPbhBembxFAHc i7EN6kbZxqZfMZxPVM4daspvLW2ZOcPDoXVgVLzbcuzM9Z4LSNb6k31RK29bbOko4O zpQFa85KGaDPRqR9wChnnEJexbbvv98Em1dN7/SIlJ0FATPeXrMUWCbtbvUmQ5O6nR 1yKhKkPeqw84QvUMaGIVOGTLAC8xsnUCpkIjy07+HL9uvY1Qm9zdw4abjKtb3HsiBn kTbLBJZ//hsXhodi36G6PQ+tSq7pjwqf/nN94OYAHarnjEwHDDPCGmgFxUdeMsr9RV u3L8/WGYG/AmA== From: Vaishali Thakkar Subject: =?utf-8?Q?[PATCH=20v2=201/3]=20x86/svm:=20Drop=20the=20=5Fenabled=20suffix=20from=20vmcb=20bits?= X-Mailer: git-send-email 2.44.0 X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1710160817615 To: xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger.pau@citrix.com, wl@xen.org, Vaishali Thakkar Message-Id: <8e6d8cac54ca05f1202580b574c548e08988d8f6.1710149462.git.vaishali.thakkar@vates.tech> In-Reply-To: References: X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.baf6d3bc498b4aa2b7c9b531ba09262f?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20240311:md Date: Mon, 11 Mar 2024 12:40:18 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit The suffix is redundant for np/sev/sev-es bits. Drop it to avoid adding extra code volume. While we're here, drop the double negations in one of the instances of _np bit and replace 0/1 with false/true in the use cases of _np. Suggested-by: Andrew Cooper Signed-off-by: Vaishali Thakkar Reviewed-by: Andrew Cooper --- Changes since v1: - Address Andrew and Jan's reviews related to dropping double negation and replacing 0/1 with false/true - Fix the typo around signed-off-by --- xen/arch/x86/hvm/svm/nestedsvm.c | 14 +++++++------- xen/arch/x86/hvm/svm/svm.c | 2 +- xen/arch/x86/hvm/svm/vmcb.c | 2 +- xen/arch/x86/include/asm/hvm/svm/vmcb.h | 18 +++++++++--------- 4 files changed, 18 insertions(+), 18 deletions(-) diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c index e4e01add8c..37548cf05c 100644 --- a/xen/arch/x86/hvm/svm/nestedsvm.c +++ b/xen/arch/x86/hvm/svm/nestedsvm.c @@ -571,7 +571,7 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct cpu_user_regs *regs) if ( nestedhvm_paging_mode_hap(v) ) { /* host nested paging + guest nested paging. */ - n2vmcb->_np_enable = 1; + n2vmcb->_np = true; nestedsvm_vmcb_set_nestedp2m(v, ns_vmcb, n2vmcb); @@ -585,7 +585,7 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct cpu_user_regs *regs) else if ( paging_mode_hap(v->domain) ) { /* host nested paging + guest shadow paging. */ - n2vmcb->_np_enable = 1; + n2vmcb->_np = true; /* Keep h_cr3 as it is. */ n2vmcb->_h_cr3 = n1vmcb->_h_cr3; /* When l1 guest does shadow paging @@ -601,7 +601,7 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct cpu_user_regs *regs) else { /* host shadow paging + guest shadow paging. */ - n2vmcb->_np_enable = 0; + n2vmcb->_np = false; n2vmcb->_h_cr3 = 0x0; /* TODO: Once shadow-shadow paging is in place come back to here @@ -706,7 +706,7 @@ nsvm_vcpu_vmentry(struct vcpu *v, struct cpu_user_regs *regs, } /* nested paging for the guest */ - svm->ns_hap_enabled = !!ns_vmcb->_np_enable; + svm->ns_hap_enabled = ns_vmcb->_np; /* Remember the V_INTR_MASK in hostflags */ svm->ns_hostflags.fields.vintrmask = !!ns_vmcb->_vintr.fields.intr_masking; @@ -1084,7 +1084,7 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs) if ( nestedhvm_paging_mode_hap(v) ) { /* host nested paging + guest nested paging. */ - ns_vmcb->_np_enable = n2vmcb->_np_enable; + ns_vmcb->_np = n2vmcb->_np; ns_vmcb->_cr3 = n2vmcb->_cr3; /* The vmcb->h_cr3 is the shadowed h_cr3. The original * unshadowed guest h_cr3 is kept in ns_vmcb->h_cr3, @@ -1093,7 +1093,7 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs) else if ( paging_mode_hap(v->domain) ) { /* host nested paging + guest shadow paging. */ - ns_vmcb->_np_enable = 0; + ns_vmcb->_np = false; /* Throw h_cr3 away. Guest is not allowed to set it or * it can break out, otherwise (security hole!) */ ns_vmcb->_h_cr3 = 0x0; @@ -1104,7 +1104,7 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs) else { /* host shadow paging + guest shadow paging. */ - ns_vmcb->_np_enable = 0; + ns_vmcb->_np = false; ns_vmcb->_h_cr3 = 0x0; /* The vmcb->_cr3 is the shadowed cr3. The original * unshadowed guest cr3 is kept in ns_vmcb->_cr3, diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c index b551eac807..1b38f6a494 100644 --- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c @@ -473,7 +473,7 @@ static int svm_vmcb_restore(struct vcpu *v, struct hvm_hw_cpu *c) if ( paging_mode_hap(v->domain) ) { - vmcb_set_np_enable(vmcb, 1); + vmcb_set_np(vmcb, 1); vmcb_set_g_pat(vmcb, MSR_IA32_CR_PAT_RESET /* guest PAT */); vmcb_set_h_cr3(vmcb, pagetable_get_paddr(p2m_get_pagetable(p2m))); } diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c index 282fe7cdbe..770a0228d4 100644 --- a/xen/arch/x86/hvm/svm/vmcb.c +++ b/xen/arch/x86/hvm/svm/vmcb.c @@ -133,7 +133,7 @@ static int construct_vmcb(struct vcpu *v) if ( paging_mode_hap(v->domain) ) { - vmcb->_np_enable = 1; /* enable nested paging */ + vmcb->_np = true; /* enable nested paging */ vmcb->_g_pat = MSR_IA32_CR_PAT_RESET; /* guest PAT */ vmcb->_h_cr3 = pagetable_get_paddr( p2m_get_pagetable(p2m_get_hostp2m(v->domain))); diff --git a/xen/arch/x86/include/asm/hvm/svm/vmcb.h b/xen/arch/x86/include/asm/hvm/svm/vmcb.h index 91221ff4e2..76507576ba 100644 --- a/xen/arch/x86/include/asm/hvm/svm/vmcb.h +++ b/xen/arch/x86/include/asm/hvm/svm/vmcb.h @@ -473,12 +473,12 @@ struct vmcb_struct { intinfo_t exit_int_info; /* offset 0x88 */ union { /* offset 0x90 - cleanbit 4 */ struct { - bool _np_enable :1; - bool _sev_enable :1; - bool _sev_es_enable :1; - bool _gmet :1; - bool _np_sss :1; - bool _vte :1; + bool _np :1; + bool _sev :1; + bool _sev_es :1; + bool _gmet :1; + bool _np_sss :1; + bool _vte :1; }; uint64_t _np_ctrl; }; @@ -645,9 +645,9 @@ VMCB_ACCESSORS(msrpm_base_pa, iopm) VMCB_ACCESSORS(guest_asid, asid) VMCB_ACCESSORS(vintr, tpr) VMCB_ACCESSORS(np_ctrl, np) -VMCB_ACCESSORS_(np_enable, bool, np) -VMCB_ACCESSORS_(sev_enable, bool, np) -VMCB_ACCESSORS_(sev_es_enable, bool, np) +VMCB_ACCESSORS_(np, bool, np) +VMCB_ACCESSORS_(sev, bool, np) +VMCB_ACCESSORS_(sev_es, bool, np) VMCB_ACCESSORS_(gmet, bool, np) VMCB_ACCESSORS_(vte, bool, np) VMCB_ACCESSORS(h_cr3, np) -- 2.44.0 From xen-devel-bounces@lists.xenproject.org Mon Mar 11 12:40:29 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 12:40:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691468.1077445 (Exim 4.92) (envelope-from ) id 1rjex2-0001De-AL; Mon, 11 Mar 2024 12:40:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691468.1077445; Mon, 11 Mar 2024 12:40:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjex2-0001DX-6z; Mon, 11 Mar 2024 12:40:20 +0000 Received: by outflank-mailman (input) for mailman id 691468; Mon, 11 Mar 2024 12:40:18 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjex0-0001DQ-Du for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 12:40:18 +0000 Received: from mail137-23.atl71.mandrillapp.com (mail137-23.atl71.mandrillapp.com [198.2.137.23]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 8247e937-dfa4-11ee-a1ee-f123f15fe8a2; Mon, 11 Mar 2024 13:40:15 +0100 (CET) Received: from pmta07.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail137-23.atl71.mandrillapp.com (Mailchimp) with ESMTP id 4Ttbvx4Gbzz1XLHZS for ; Mon, 11 Mar 2024 12:40:13 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 0d202f572a42476ba738db1285fab61f; Mon, 11 Mar 2024 12:40:13 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8247e937-dfa4-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1710160813; x=1710421313; bh=hIyJ/wVgm7EM796HLFHzmm1TJtjO8KPO/CkfRPlI9cc=; h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version: Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From; b=rUvnEDs4joSaTUHjhf33Bl2CJa2m5Me/SxoJhoJgJyheLxVops/7MoLtxLRuvt0jV eo8F21LPR3yEabvNvvxPVwzB4yx1lccn1PQPtV20ITOWZZ/cI3h6QGctu1ROwuHPz+ x8DZ3kXd5yYayRm3ZDbcg4uco3PYhjsz0x972hqT8FZWLB6ajLKmdkSrC/mE2RmZAA jCsQNDlRDMGLw3sW5kL+S29pO33II2X2HhtoaGx1ROIuqsn4zcc0znw2Qu3yYDtoAR PYz6qVpbDpD+UJxJzLPekiFaSvPVCygGAZLJJbc0sCu5hnHLSLexRO9mj/ni2BxJHl QMVOowBaibSZA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1710160813; x=1710421313; i=vaishali.thakkar@vates.tech; bh=hIyJ/wVgm7EM796HLFHzmm1TJtjO8KPO/CkfRPlI9cc=; h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version: Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From; b=TQ2tzfAzGtI/UYIDPJoKKZe057H44t07FxBkSpBGMKx+rd9n8rk5dw4nDSQF0FSd1 OOCDx2cMOBNflpcG+nKPMicJB8LZhIagbwtivE8L8Mp3SAu/gNmR/H8v3wDpA98cSO +9HNoBt9tQf2AC9XhcPLTQBpYF9803Y6EwJV/pvkcZ5AAEQEz6hFFP1APoeOKzxaiU scFd2Hx+/DZUA6fYxizssye0y05rXlgdAyFZkKZnCCi8NxLwpoq6Ek6pIplRy20qfN +kUnY5z+o+QZNhYchkNXjXxLplAaINAy3ZcYhO5PdZD/RgJfCYBc4a9DF3RGPvqJte 9YnmuDuGAnrdA== From: Vaishali Thakkar Subject: =?utf-8?Q?[PATCH=20v2=200/3]=20x86/svm=20:=20Misc=20changes=20for=20few=20vmcb=20bits?= X-Mailer: git-send-email 2.44.0 X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1710160812371 To: xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger.pau@citrix.com, wl@xen.org, Vaishali Thakkar Message-Id: X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.0d202f572a42476ba738db1285fab61f?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20240311:md Date: Mon, 11 Mar 2024 12:40:13 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, In this patchset, first & second patch removes the unnecessary suffix from a bunch of vmcb bits. Third patch is about printing the status of sev and sev-es bits while dumping VMCB. Changes since v1: - Address comments from Andrew and Jan - Add extrapatch to drop the suffix _guest as per Andrew's suggestion in one of the reviews - Address Andrew's comment with respect to pretty printing Vaishali Thakkar (3): x86/svm: Drop the _enabled suffix from vmcb bits x86/svm: Drop the suffix _guest from vmcb bit x86/svmdebug: Print sev and sev_es vmcb bits xen/arch/x86/hvm/svm/asid.c | 6 ++--- xen/arch/x86/hvm/svm/nestedsvm.c | 22 +++++++++--------- xen/arch/x86/hvm/svm/svm.c | 2 +- xen/arch/x86/hvm/svm/svmdebug.c | 7 ++++-- xen/arch/x86/hvm/svm/vmcb.c | 2 +- xen/arch/x86/include/asm/hvm/svm/nestedsvm.h | 2 +- xen/arch/x86/include/asm/hvm/svm/vmcb.h | 24 ++++++++++---------- 7 files changed, 34 insertions(+), 31 deletions(-) -- 2.44.0 From xen-devel-bounces@lists.xenproject.org Mon Mar 11 13:27:50 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 13:27:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691488.1077486 (Exim 4.92) (envelope-from ) id 1rjfgt-0001LF-GS; Mon, 11 Mar 2024 13:27:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691488.1077486; Mon, 11 Mar 2024 13:27:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjfgt-0001L8-DC; Mon, 11 Mar 2024 13:27:43 +0000 Received: by outflank-mailman (input) for mailman id 691488; Mon, 11 Mar 2024 13:27:42 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjfgs-0001L2-Fj for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 13:27:42 +0000 Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [2a00:1450:4864:20::62f]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 22ba6173-dfab-11ee-afdc-a90da7624cb6; Mon, 11 Mar 2024 14:27:41 +0100 (CET) Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-a44cdb2d3a6so608379366b.2 for ; Mon, 11 Mar 2024 06:27:41 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id k13-20020a1709065fcd00b00a44f0d99d58sm2840433ejv.208.2024.03.11.06.27.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Mar 2024 06:27:40 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 22ba6173-dfab-11ee-afdc-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1710163660; x=1710768460; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=Hyc/fCYjIBQbOdpQFKuI9KPdXdwvVUgTGvJ8uWgzWZg=; b=HBhxZkc0c3Ep+XgnU2kQVRFpNA75fASIDhpbE0nd1DY04OyOE/Mk3XvXVoTAaS5Lut n7UvC6gk8Ei0uyyef9wI2hbJ+nlEgH2u1WBMFL02XjLLktSrTYNxVXFe1g3nAtkCnOmS ACRuHWaCaiLcMfd52C7IBczKtf13fYMy0ahO4PYUVAWwDQURLZ4ILBHC0JC6fD2aQYE+ /MFKXnjVxkq44RIYwhXV2FCszZzQWAeqlM6z+2WEfp4bUbGxgIRdcyNk6qdZZNRI8MC+ SzSxejz0wYqcJIdJ641VW6sff7rhgEGa4SQ5Xy20IbBFN5piniLx+f3yTdy7Oe1Ds0a5 CEQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710163660; x=1710768460; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Hyc/fCYjIBQbOdpQFKuI9KPdXdwvVUgTGvJ8uWgzWZg=; b=cg1cx7VRm9C9OwERO71iV9JC3cMg70O8cYVu4nvrpKEHoPsGxIPoaa0RXsmMezwbtm pfZ1zjk4SMEbfbcjFXwoLt+ojEL2jsHJbBT75WjEbFU7T1tSKnVSNcCpGHFzNbDiVa7A j7TIb3uqV3In9TsgNo18rvImfTFSrkPrSpesP3i5vTH+ZVTF7XseiAaxnY/Wom7tBYAQ HjL+uRdxyO1EBQKV39BAoWX/3XK6cuZUQFoJWs6Sl01CNb2yaIsLk1ZLJBu7Ur42b2xY 132+mjt/sPrzX6AKZVHdmUImz3juBqbAZ2maOozcELrjzk9gQ6FxxN4UK1Rr3XJqhKg4 SfAw== X-Forwarded-Encrypted: i=1; AJvYcCUO0oI0rG8JIJGv6uMS3qqWLvawvQ6qzfZGlwhHqgXM+cVqqQhUYUnMYzF6YI+PGXFED25USKeS9/WXK3lLYtW+UvHc7e1zXB9ntVMbb6k= X-Gm-Message-State: AOJu0YyZfJDWqGMIk8pIDJcVDzi56929ShY3fE42vJmBZQHvaT2UE9Ko lT15ajbvyBmkWWVwfCj/qbH3BNwaDkddXXZ+O/Ha+67P8mBIhtuJH3Z1KodJpA== X-Google-Smtp-Source: AGHT+IEsSikZrp4z1pNULPMGsvAyMeROrjCGGp8GxVk/K2flPycktt6ZToWXPCBKiVy7OHrwKkTvsw== X-Received: by 2002:a17:906:d1cb:b0:a46:23e8:2fb2 with SMTP id bs11-20020a170906d1cb00b00a4623e82fb2mr321132ejb.62.1710163660590; Mon, 11 Mar 2024 06:27:40 -0700 (PDT) Message-ID: <0756f3b5-6efa-4113-b88e-9638327b3e1e@suse.com> Date: Mon, 11 Mar 2024 14:27:39 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH v3 00/16] xen: address violation of MISRA C:2012 Directive 4.10 To: Simone Ballarin Cc: consulting@bugseng.com, sstabellini@kernel.org, Andrew Cooper , George Dunlap , Julien Grall , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Doug Goldstein , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , xen-devel@lists.xenproject.org References: <93179ace-f201-40d9-8348-372d59e4030b@bugseng.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <93179ace-f201-40d9-8348-372d59e4030b@bugseng.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 11.03.2024 12:41, Simone Ballarin wrote: > On 11/03/24 10:59, Jan Beulich wrote: >> On 11.03.2024 09:59, Simone Ballarin wrote: >>> The Xen sources contain violations of MISRA C:2012 Directive 4.10 whose headline states: >>> "Precautions shall be taken in order to prevent the contents of a header file >>> being included more than once". >>> >>> As stated in v2, the following naming convention has been estabilished: >>> - arch/.../include/asm/ headers -> ASM__H >>> - private headers -> __H >>> - asm-generic headers -> ASM_GENERIC__H >>> >>> Since there would have been conflicting guards between architectures (which is a violation >>> of the directive), >> >> Why would this be a violation? The two sets of headers aren't use together, >> and any scan should only point out collisions in what's actively used, I'd >> hope. >> > > A header guard cannot be used multiple times in the same project, so it's a question > of whether or not we want to consider each arch variant part of the same project. > In case, we can define a new rule for these files. > >>> there has been a need for ASM headers to specify if the inclusion guard >>> referred to ARM or X86. Hence it has been decided to adopt instead: >>> - arch//include/asm//.h -> ASM____H >>> >>> The subdir used is the smallest possible to avoid collisions. For example, it has been >>> observed that in "xen/arch/arm/include/asm/arm32" and "xen/arch/arm/include/asm/arm64" there >>> are plenty of header files with the same name, hence _ARMxx_ was added as subdirectory. >> >> Why couldn't _ together be ARMxx there, allowing us to get >> away with one less name component. >> > > I agree. > >>> There has been a need to define a standard for generated headers too: >>> - include/generated//.h-> GENERATED___H >>> - arch//include/generated/asm/.h-> _GENERATED_ASM__H >>> >>> To summarize, here are all the rules that have been applied: >>> - private headers -> __H >> >> And here is the full path? I thought I had indicated before that >> this is going to lead to excessively long identifiers. >> > > Yes, dir is the full path. This general fallback rule to use when more specific rules do not apply. > If this generates excessively long guards, we can simply add more rules. >>> - asm-generic headers -> ASM_GENERIC__H >>> - arch//include/asm//.h -> ASM____H >>> - include/generated//.h-> GENERATED___H >>> - arch//include/generated/asm/.h-> _GENERATED_ASM__H >> >> And _ASM_ is merely a precaution for stuff appearing outside of asm/ (which >> doesn't seem very likely)? > > Yes, it is. Do you prefer dropping the _ARM_? Well, I prefer any measure keeping down the length of these identifiers. Jan From xen-devel-bounces@lists.xenproject.org Mon Mar 11 13:45:06 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 13:45:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691492.1077496 (Exim 4.92) (envelope-from ) id 1rjfxW-0004Yr-Rr; Mon, 11 Mar 2024 13:44:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691492.1077496; Mon, 11 Mar 2024 13:44:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjfxW-0004Yk-PJ; Mon, 11 Mar 2024 13:44:54 +0000 Received: by outflank-mailman (input) for mailman id 691492; Mon, 11 Mar 2024 13:44:53 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjfxV-0004Ya-4u; Mon, 11 Mar 2024 13:44:53 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjfxU-0005OL-W5; Mon, 11 Mar 2024 13:44:53 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjfxU-00072i-Ix; Mon, 11 Mar 2024 13:44:52 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rjfxU-0005uc-IR; Mon, 11 Mar 2024 13:44:52 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=1JUo9zDk/bcA9yvPbx6nsVbHsVH6u0pLDcK0K/hnLjE=; b=MTfHlHs0wMWlq6x58AXV3cUhAa ReeV/de4UNuCi2mYmF++zsQudGDVRSytykj4h+IpSirGU1BuCJ9uFWKnAh7v6trfCq8E1VUFZ4kxq C0SDQNQpZ8IhXWbIu+pX64yFEWi55ysjJ6mdAvoSKGd80TF12WS06B+JrIXE4c/E2GPg=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-linus test] 184991: tolerable FAIL - PUSHED X-Osstest-Failures: linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: linux=e8f897f4afef0031fe618a8e94127a0934896aba X-Osstest-Versions-That: linux=137e0ec05aeb657472d2f84dbb3081016160334b From: osstest service owner Date: Mon, 11 Mar 2024 13:44:52 +0000 flight 184991 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/184991/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 16 saverestore-support-check fail like 184987 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop fail like 184987 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop fail like 184987 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop fail like 184987 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 184987 test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail like 184987 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop fail like 184987 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184987 test-amd64-amd64-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl 15 migrate-support-check fail never pass test-arm64-arm64-xl 16 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 15 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 15 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-check fail never pass test-armhf-armhf-libvirt 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qcow2 14 migrate-support-check fail never pass test-amd64-amd64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-check fail never pass test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-arm64-arm64-xl-vhd 14 migrate-support-check fail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-check fail never pass version targeted for testing: linux e8f897f4afef0031fe618a8e94127a0934896aba baseline version: linux 137e0ec05aeb657472d2f84dbb3081016160334b Last test of basis 184987 2024-03-10 16:44:17 Z 0 days Testing same since 184991 2024-03-11 03:03:07 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Johan Hovold Linus Torvalds Neil Armstrong Sachin Sant Steven Rostedt (Google) Vinod Koul jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-amd64-dom0pvh-xl-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-freebsd11-amd64 pass test-amd64-amd64-freebsd12-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-examine-bios pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-amd64-dom0pvh-xl-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-amd64-xl-pvshim pass test-amd64-amd64-pygrub pass test-amd64-amd64-libvirt-qcow2 pass test-armhf-armhf-libvirt-qcow2 pass test-amd64-amd64-libvirt-raw pass test-arm64-arm64-libvirt-raw pass test-armhf-armhf-libvirt-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-examine-uefi pass test-amd64-amd64-xl-vhd pass test-arm64-arm64-xl-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these 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 : hint: The 'hooks/update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-receive' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. To xenbits.xen.org:/home/xen/git/linux-pvops.git 137e0ec05aeb6..e8f897f4afef0 e8f897f4afef0031fe618a8e94127a0934896aba -> tested/linux-linus From xen-devel-bounces@lists.xenproject.org Mon Mar 11 13:46:58 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 13:46:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691499.1077505 (Exim 4.92) (envelope-from ) id 1rjfzV-00059F-AQ; Mon, 11 Mar 2024 13:46:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691499.1077505; Mon, 11 Mar 2024 13:46:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjfzV-000598-7r; Mon, 11 Mar 2024 13:46:57 +0000 Received: by outflank-mailman (input) for mailman id 691499; Mon, 11 Mar 2024 13:46:55 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjfzT-00058W-LW for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 13:46:55 +0000 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on20601.outbound.protection.outlook.com [2a01:111:f403:2416::601]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id d107b31c-dfad-11ee-a1ee-f123f15fe8a2; Mon, 11 Mar 2024 14:46:53 +0100 (CET) Received: from PH7P221CA0026.NAMP221.PROD.OUTLOOK.COM (2603:10b6:510:32a::21) by BY5PR12MB4049.namprd12.prod.outlook.com (2603:10b6:a03:201::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.35; Mon, 11 Mar 2024 13:46:46 +0000 Received: from SN1PEPF0002529E.namprd05.prod.outlook.com (2603:10b6:510:32a:cafe::b5) by PH7P221CA0026.outlook.office365.com (2603:10b6:510:32a::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.36 via Frontend Transport; Mon, 11 Mar 2024 13:46:46 +0000 Received: from SATLEXMB03.amd.com (165.204.84.17) by SN1PEPF0002529E.mail.protection.outlook.com (10.167.242.5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7386.12 via Frontend Transport; Mon, 11 Mar 2024 13:46:45 +0000 Received: from SATLEXMB06.amd.com (10.181.40.147) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Mon, 11 Mar 2024 08:46:45 -0500 Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB06.amd.com (10.181.40.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Mon, 11 Mar 2024 08:46:45 -0500 Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.35 via Frontend Transport; Mon, 11 Mar 2024 08:46:43 -0500 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d107b31c-dfad-11ee-a1ee-f123f15fe8a2 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CtinkVnah7GuApJLazNjFldi9a7m2Mp08KdUNZujQrEe7sZuLic+KLWt0PR3ltylkkMnXFa3rkdSsfpbcCBd6FBQZsciBj7Qhz0ZTMDXDOHC238ZhCJq2JOIA1Pu50EtmMK4z8k0LEOxZs2fzPIIGP6bqPtROnFunhJsdjgm2L6FQUkimec/6iRuyJnnVhSTKRAQGSR+dciTstXy9xDE7ecT749Plc6IFbxWjfoX+8dZzevKJIYwQg3EzsGnBLK9Ny0RkeQcNQ6QTF3i/GUjX8POpncyyy3C8vJC65pEDcoaafrhiGYT34RA/y3tpN+n5tB4X81WVZONw98ZTZkzGA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=LX5tZpRAfK5z1BaWM+DhWh42XoB4kkl3hXYhqmsyTfk=; b=X+BDn5Q0MB80qEpSIxL6p07jYbLq20tFUgjq1SJAA9FVCVcDF7P4JktHPqpilCccUWZ/fdEuEXfaKd+ghuvFk1uYRC6paYec/hC/sQCDPff5PqmgiS/Z/qiixiCirHLTiPPEtlouBASxyGUM+dkVii02FjxExSJxJr0EYiO/RvVaef7ogFY0eZWzMq7fvyIAsf7FQiFDQiuUW0mQt2aw5J0yUwJoh93ITAQ2YBOnnH446OtF4738lj68lh9boRjndqAIl9FD5L1EMqwgzxJ05tGaTv0uDgpjwrK+iEwJWPbMqL3BEt86WruR2MaEUPx/v3E9KkGrTsP/yvvQNjW22A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LX5tZpRAfK5z1BaWM+DhWh42XoB4kkl3hXYhqmsyTfk=; b=Bseu0aO9/xZWiv7LuXGX+Yjo0fxJAnOCt2nckjDjWwTtxl3ejwDgvGY3BPTj6QvbSk+hQ7nDB2aqzBIdN2FJrviICFmPVc0+QlYNiccBO25GFUy6nc6rTMxxQd+xJldSRK9t1v6q1DlOr4DGpyT80BxtvcjrbON8ap0VyXtMDTM= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C Message-ID: <4821f30b-94a6-4a2a-8c46-81a9d1e288a4@amd.com> Date: Mon, 11 Mar 2024 14:46:38 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 4/5] xen/arm: Find unallocated spaces for magic pages of direct-mapped domU Content-Language: en-US To: Henry Wang , CC: Stefano Stabellini , Julien Grall , Bertrand Marquis , "Volodymyr Babchuk" , Alec Kwapis References: <20240308015435.4044339-1-xin.wang2@amd.com> <20240308015435.4044339-5-xin.wang2@amd.com> From: Michal Orzel In-Reply-To: <20240308015435.4044339-5-xin.wang2@amd.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SN1PEPF0002529E:EE_|BY5PR12MB4049:EE_ X-MS-Office365-Filtering-Correlation-Id: 7de0c8bd-2003-4b1c-f00b-08dc41d1b13d X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: COy+ncP1I1KfdBKZZTszkpfc7qRO0qHWYuGVyebnFRwYOM7G6A7YRJeqIFYSrF2jN2GU1g24odSgrJBkUCmZKc/lG9OOc4F0eUSARs7ChhABQD4gRslivaez9HlW5BTuFhLz7bITa/w/0fkkVJoWMJC4cqT/dHTOP17gSXpyCDGqBImF/URb+C86DbnBllFUgIGjBodWGoOt5xqh1tDroGVDUNR+/V64WWjTRIXQKlv1SE46KfcER1j6HXLRFhgqLieXZod2Fy7MxtGXvBh8EQ/jyDi7MESg76vBZKPBzWWSv0sWqFkig55KcWAnFeSZam5fIpD+IUhddWH5GFr6i7PkHgunXACMcqFHoOmXcHGCilRrQfWGHdhG4A7B4lIyHhgbzsFr7Osyr1Rtwb6fY+fl1iFv3u4O6tKd5WLJZq5MhkCG+aoO04Qe9wOFI6p0PRx+OKwMRMuYqrL0/7u0K4EMMjrsfYLXmrQF6oHqDyP+ETsOVo5qtBwTo6HRXMLSNqqHGrj+2WdZuAMooMBqqEh8pGMBAZREXgxhOVIWDMDItqAPs4JOgeAnXBg8lCqZ/4rnjFgYSUCLBJkXVj2HvPLSAjgR8QVUZDSAz/5jljjPNDvGbsQ/9hPD81E7JhItx9VWeEnpYZ04XF3XbmhoHNyK5GgXcPhjgWNyD1NGuxlEnXA/wUCcbDiyQrZh2twUGNGC92ZHq4Ou5TmDxO//YRRlx//rAkJDPOlcPRymEpaN2p3DMv7MOuzUzwVdCqX0 X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(376005)(36860700004)(82310400014)(1800799015);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Mar 2024 13:46:45.6739 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 7de0c8bd-2003-4b1c-f00b-08dc41d1b13d X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SN1PEPF0002529E.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR12MB4049 Hi Henry, On 08/03/2024 02:54, Henry Wang wrote: > For 1:1 direct-mapped dom0less DomUs, the magic pages should not clash > with any RAM region. To find a proper region for guest magic pages, > we can reuse the logic of finding domain extended regions. > > Extract the logic of finding domain extended regions to a helper > function named find_unused_memory() and use it to find unallocated > spaces for magic pages before make_hypervisor_node(). The result magic > page region is added to the reserved memory section of the bootinfo so > that it is carved out from the extended regions. > > Reported-by: Alec Kwapis > Signed-off-by: Henry Wang > --- > v2: > - New patch > --- > xen/arch/arm/dom0less-build.c | 43 +++++++++++++++++++++++++ > xen/arch/arm/domain_build.c | 30 ++++++++++------- > xen/arch/arm/include/asm/domain_build.h | 2 ++ > 3 files changed, 64 insertions(+), 11 deletions(-) > > diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c > index 1e1c8d83ae..99447bfb0c 100644 > --- a/xen/arch/arm/dom0less-build.c > +++ b/xen/arch/arm/dom0less-build.c > @@ -682,6 +682,49 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo) > > if ( kinfo->dom0less_feature & DOM0LESS_ENHANCED_NO_XS ) > { > + if ( is_domain_direct_mapped(d) ) > + { This whole block is dependent on static memory feature that is compiled out by default. Shouldn't you move it to static-memory.c ? > + struct meminfo *avail_magic_regions = xzalloc(struct meminfo); I can't see corresponding xfree(avail_magic_regions). It's not going to be used after unused memory regions are retrieved. > + struct meminfo *rsrv_mem = &bootinfo.reserved_mem; > + struct mem_map_domain *mem_map = &d->arch.mem_map; > + uint64_t magic_region_start = INVALID_PADDR; What's the purpose of this initialization? magic_region_start is going to be re-assigned before making use of this value. > + uint64_t magic_region_size = GUEST_MAGIC_SIZE; Why not paddr_t? > + unsigned int i; > + > + if ( !avail_magic_regions ) > + return -ENOMEM; What about memory allocated for kinfo->fdt? You should goto err; > + > + ret = find_unused_memory(d, kinfo, avail_magic_regions); > + if ( ret ) > + { > + printk(XENLOG_WARNING > + "%pd: failed to find a region for domain magic pages\n", > + d); > + goto err; What about memory allocated for avail_magic_regions? You should free it. > + } > + > + magic_region_start = avail_magic_regions->bank[0].start; > + > + /* > + * Register the magic region as reserved mem to make sure this > + * region will not be counted when allocating extended regions. Well, this is only true in case find_unallocated_memory() is used to retrieve free regions. What if our direct mapped domU used partial dtb and IOMMU is in use? In this case, find_memory_holes() will be used and the behavior will be different. Also, I'm not sure if it is a good idea to call find_unused_memory twice (with lots of steps inside) just to retrieve 16MB (btw. add_ext_regions will only return 64MB+ regions) region for magic pages. I'll let other maintainers share their opinion. Also, CCing Carlo since he was in a need of retrieving free memory regions as well for cache coloring with dom0. ~Michal From xen-devel-bounces@lists.xenproject.org Mon Mar 11 13:50:44 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 13:50:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691502.1077515 (Exim 4.92) (envelope-from ) id 1rjg35-0006v6-OT; Mon, 11 Mar 2024 13:50:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691502.1077515; Mon, 11 Mar 2024 13:50:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjg35-0006uz-M1; Mon, 11 Mar 2024 13:50:39 +0000 Received: by outflank-mailman (input) for mailman id 691502; Mon, 11 Mar 2024 13:50:38 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjg34-0006ut-Fp for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 13:50:38 +0000 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on20601.outbound.protection.outlook.com [2a01:111:f403:2416::601]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 55dd4be6-dfae-11ee-a1ee-f123f15fe8a2; Mon, 11 Mar 2024 14:50:36 +0100 (CET) Received: from CY5PR18CA0033.namprd18.prod.outlook.com (2603:10b6:930:13::16) by CH3PR12MB9394.namprd12.prod.outlook.com (2603:10b6:610:1cf::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.35; Mon, 11 Mar 2024 13:50:31 +0000 Received: from CY4PEPF0000E9D9.namprd05.prod.outlook.com (2603:10b6:930:13:cafe::60) by CY5PR18CA0033.outlook.office365.com (2603:10b6:930:13::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.35 via Frontend Transport; Mon, 11 Mar 2024 13:50:31 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by CY4PEPF0000E9D9.mail.protection.outlook.com (10.167.241.77) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7386.12 via Frontend Transport; Mon, 11 Mar 2024 13:50:30 +0000 Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Mon, 11 Mar 2024 08:50:30 -0500 Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.35 via Frontend Transport; Mon, 11 Mar 2024 08:50:28 -0500 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 55dd4be6-dfae-11ee-a1ee-f123f15fe8a2 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SVcuWv9k9mLNcc3rrNSv9pdT3ZPI+WeSD9kJim7ozu9n+CMbZMN+tGCgpwHc6hE/2qnsBOoR8VkYhUveR6vxNhw1FbdyYr9z9QtsOMUaqawYeYjJ2IpBOxEPHt5K4b/gLieNZMYYHryRM9I1eyRk9yl0pNpt2j+xC+2zJJMBolr9NNPw6TK1pteafFTWDjdQITiAG7wxaW/sv3Yf8hnqCbve6tMhjHFi/j0elAgNYJXlff/iX5u4pJCD7Ike/AFz2Fdzu3BHK/TrSxvuL9jFIZi06PrIR+7+GUgziXEw01DhMJHJfp4UO8bsctMnBsPqihM/BT6DtUOgiPoKe1k0MA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=V9M1EeZ8VI0siVPOy8ACdOyTocZjT09LZon/LZAUW9U=; b=cIBMptySXdUfxX1qkGN9CxkBSDhbymZ10yEb7N1KZVqHjDuzpLNncTdpjfZknLyyIwa46T2ESAhz2/L+/6smOxbbK8AJOv/QaLsO9gtIqawARnkcASiCnFrXFwFrUHiUPVEdSMzcrLBStUI9A1XgymcAWhiM1UX4RucHs8y3JirW95v+YC4RpRA+i9kpU6327alPDxh/oQlXBMd9uDLeuN4vk6zwzSobJeSAUBey5D4r1oHEgoxEisMupOgiRi2XgJCMYbXgIkahStkXWh/TUzQS+G/07M27P4PY2+xdOWGNJCD7Zx4/NyxIsT8XFHGpjJrbgw0Jfvzv4fKFfIb5nQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=V9M1EeZ8VI0siVPOy8ACdOyTocZjT09LZon/LZAUW9U=; b=PPGyamqI2CQ2PnIV8yd7nRe0Y+5cN822BXd2O7fPo6J7rTIcjw10RtyrcDyu4lYqBOjyFB9xDlrxFZTbaN/TTNmJOsJE7//Oi3hhCKj//A2kgr6FAOzVAB/Gbt72F7aXJMqmtGe4drj6dB9cfWpSpJVHkPR593bRUZhEeKclRcE= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C Message-ID: <3ed07a07-e423-477d-8a87-7d40bd9a54b9@amd.com> Date: Mon, 11 Mar 2024 14:50:23 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 4/5] xen/arm: Find unallocated spaces for magic pages of direct-mapped domU Content-Language: en-US From: Michal Orzel To: Henry Wang , CC: Stefano Stabellini , Julien Grall , Bertrand Marquis , "Volodymyr Babchuk" , Alec Kwapis , Carlo Nonato References: <20240308015435.4044339-1-xin.wang2@amd.com> <20240308015435.4044339-5-xin.wang2@amd.com> <4821f30b-94a6-4a2a-8c46-81a9d1e288a4@amd.com> In-Reply-To: <4821f30b-94a6-4a2a-8c46-81a9d1e288a4@amd.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Received-SPF: None (SATLEXMB04.amd.com: michal.orzel@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CY4PEPF0000E9D9:EE_|CH3PR12MB9394:EE_ X-MS-Office365-Filtering-Correlation-Id: 12c80433-9e9a-4986-5699-08dc41d23782 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: y7GGoh7M0oQ+NOPqiOTLDc5WKRbMV7ER8ASG/ozyuUiq4t3EETbGf+FsrzUhYEbmeCa7Sasx90huqNIX5bkBOUuxlfmSwwcfbv5MAb2PRL5cfkp0ALroLKGpeuYUKkvApInOhzH/Pbfsn9nidyMUSXCSJV0LHx1p0y2oW8+0s2yCGl9B1MAHIUfbT6lYeeIa9Tc0b01JA9ml8U9YrpwPbzhrVW1f1YWqX/v3RoQOUf8rfVZOz1sNQ1fGyrBhA7WUrZsewHyLcEAbCiUJLUAGXTY64XCxoJiyrvH1/S2NIMjnoW3BYd994fZHyGbSBYmaC52A691AOU114MAOxVCm3Da2NwTY+VIxnxjrYG5IID8ZLr+dF7pkuTF/KZqqt5vQPkPYA9fUzFKxw2EzmLvmlXx5n2EZrcu+VtycsqrPX54zLzpJVUiVDECEBZry3O5yq77xvEyti7tRlL5Gxkn14KVWAY0hzB8zuqbn25iPZjUV0NWDWtldNIw0E/hGX84QA2tmOgPwAuZwjdNIdYUoAFBEB/r6xaTmuSlUJpPRNVNXt2RhJ4s+64xgJVVBA5rWAYihJyTcBbALuMckVNNhDkQu+PoVZsdzWHrv5hlIhP8UtqVOUlMKRMwfgzH6Jy9378nKtHOkBwn1JWknJqk/63ZtO5Z4DAAn41kxgNIXEvAKfq4NqxGeRTUurovQakQXwrJeAwrlP9yZpQFEuP5O+DeDhhuo6+Z6LlH0cHn+tgcUgCBuO7xtlopq3SCo95/Z X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(82310400014)(36860700004)(1800799015)(376005);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Mar 2024 13:50:30.8901 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 12c80433-9e9a-4986-5699-08dc41d23782 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CY4PEPF0000E9D9.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB9394 On 11/03/2024 14:46, Michal Orzel wrote: > > > Hi Henry, > > On 08/03/2024 02:54, Henry Wang wrote: >> For 1:1 direct-mapped dom0less DomUs, the magic pages should not clash >> with any RAM region. To find a proper region for guest magic pages, >> we can reuse the logic of finding domain extended regions. >> >> Extract the logic of finding domain extended regions to a helper >> function named find_unused_memory() and use it to find unallocated >> spaces for magic pages before make_hypervisor_node(). The result magic >> page region is added to the reserved memory section of the bootinfo so >> that it is carved out from the extended regions. >> >> Reported-by: Alec Kwapis >> Signed-off-by: Henry Wang >> --- >> v2: >> - New patch >> --- >> xen/arch/arm/dom0less-build.c | 43 +++++++++++++++++++++++++ >> xen/arch/arm/domain_build.c | 30 ++++++++++------- >> xen/arch/arm/include/asm/domain_build.h | 2 ++ >> 3 files changed, 64 insertions(+), 11 deletions(-) >> >> diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c >> index 1e1c8d83ae..99447bfb0c 100644 >> --- a/xen/arch/arm/dom0less-build.c >> +++ b/xen/arch/arm/dom0less-build.c >> @@ -682,6 +682,49 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo) >> >> if ( kinfo->dom0less_feature & DOM0LESS_ENHANCED_NO_XS ) >> { >> + if ( is_domain_direct_mapped(d) ) >> + { > This whole block is dependent on static memory feature that is compiled out by default. > Shouldn't you move it to static-memory.c ? > >> + struct meminfo *avail_magic_regions = xzalloc(struct meminfo); > I can't see corresponding xfree(avail_magic_regions). It's not going to be used after unused memory > regions are retrieved. > >> + struct meminfo *rsrv_mem = &bootinfo.reserved_mem; >> + struct mem_map_domain *mem_map = &d->arch.mem_map; >> + uint64_t magic_region_start = INVALID_PADDR; > What's the purpose of this initialization? magic_region_start is going to be re-assigned before making use of this value. > >> + uint64_t magic_region_size = GUEST_MAGIC_SIZE; > Why not paddr_t? > >> + unsigned int i; >> + >> + if ( !avail_magic_regions ) >> + return -ENOMEM; > What about memory allocated for kinfo->fdt? You should goto err; > >> + >> + ret = find_unused_memory(d, kinfo, avail_magic_regions); >> + if ( ret ) >> + { >> + printk(XENLOG_WARNING >> + "%pd: failed to find a region for domain magic pages\n", >> + d); >> + goto err; > What about memory allocated for avail_magic_regions? You should free it. > >> + } >> + >> + magic_region_start = avail_magic_regions->bank[0].start; >> + >> + /* >> + * Register the magic region as reserved mem to make sure this >> + * region will not be counted when allocating extended regions. > Well, this is only true in case find_unallocated_memory() is used to retrieve free regions. > What if our direct mapped domU used partial dtb and IOMMU is in use? In this case, > find_memory_holes() will be used and the behavior will be different. > > Also, I'm not sure if it is a good idea to call find_unused_memory twice (with lots of steps inside) > just to retrieve 16MB (btw. add_ext_regions will only return 64MB+ regions) region for magic pages. > I'll let other maintainers share their opinion. > > Also, CCing Carlo since he was in a need of retrieving free memory regions as well for cache coloring with dom0. In the end, I forgot to CC Carlo. Adding him now. ~Michal From xen-devel-bounces@lists.xenproject.org Mon Mar 11 13:56:18 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 13:56:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691505.1077526 (Exim 4.92) (envelope-from ) id 1rjg8T-0007Vo-CO; Mon, 11 Mar 2024 13:56:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691505.1077526; Mon, 11 Mar 2024 13:56:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjg8T-0007Vh-90; Mon, 11 Mar 2024 13:56:13 +0000 Received: by outflank-mailman (input) for mailman id 691505; Mon, 11 Mar 2024 13:56:11 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjg8R-0007VY-UY for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 13:56:11 +0000 Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [2a00:1450:4864:20::52f]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 1dc89c24-dfaf-11ee-afdc-a90da7624cb6; Mon, 11 Mar 2024 14:56:10 +0100 (CET) Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-563c403719cso5266850a12.2 for ; Mon, 11 Mar 2024 06:56:10 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id lt10-20020a170906fa8a00b00a45ab830eabsm2896848ejb.51.2024.03.11.06.56.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Mar 2024 06:56:10 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1dc89c24-dfaf-11ee-afdc-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1710165370; x=1710770170; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=QDP7ErY6NRkBE4AyzZdVhP6LRsPdLqAoMkS1X/+Oq2g=; b=OmJiR4F/9+fwi1xiLHFEMulb4t6f6fIiikw74dMutekE4atOy+vIwoDc4Ffkb9scvO /zO9YHpjJgpjpIk6MwJWD/INXvx5fBY5GegFCWWxeWB6/BD+gFWdmOMtus4XWGKD35Xn 7vC7npTCvoE0hJk1Hsesl0OdEqb1UFJj4YwN/gKkPpl6ujNCa34xwAvYvBG2m2mAed/o U+puiF2G96xnnp5iWW8UMkDeO2lqE3qohgPfUdwAV+a7vAcQmu3aVYu8o1q47Xc/N70h rMn/cXvrVDx6wtAf5fP5OnSmE7yPGA2ORO6HuIOXSNur3zG1Wr0BF7uy+nCciBzXF2Ye 8t6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710165370; x=1710770170; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=QDP7ErY6NRkBE4AyzZdVhP6LRsPdLqAoMkS1X/+Oq2g=; b=R6LScjMpamJx7VVJPHjvmZmtwlRgbncm9AyxOTQ/ME7LWuMTNVGd1MRvmdxogOzTAh xN+jh6G1EhzRlV0GRwhp4sMy8lo+DxqCkJrvRxCOaEz4bkNxEahWD/zFvL0nS/gznoSk leopm2Qj2URI/24I2aDljxmFF8uNqdQAzlkcYX7ZyE6aCaf5OH7krAitYdgOivgJ29op ObBN35zo7oNxyn/Wap7PZsXe9wgz+H/SlUdMws6g3b1yup697ohIGL3Z9dX9E6Lv/2LW hWAe8iND0kqTLAmFXljjJZicGHDdCKo31rE8fKgRZ5b9apWOAp+qlxEUr5EALKFSIlAt wxOw== X-Forwarded-Encrypted: i=1; AJvYcCX5PyjUrn7XWI2tDZdXciBG+ku6dwIkviQ4BVUKfCRPQI/ukl4JXWnfmzQjkGFtF2l7e3URErX3r2175LW6pjGNwWl+d6423bJpO6Y5tng= X-Gm-Message-State: AOJu0YwrKD7gsgtl8KfvD7CNQVYhWLK0MiGVqClnfXZ6XhwExfk8rcj5 2+kxJvEitMGaLrsPoS6SarKAR9bcKEFRvzfBGIXi5CpEpv76XXjrLPBICUYJQw== X-Google-Smtp-Source: AGHT+IFtNB2nYNoB1DibmJG+hGzbaGVzA96D6WaV9uI8HLszYuIihebzeCoTJC/YDis7ChLxduaSKA== X-Received: by 2002:a17:906:dfd7:b0:a45:b761:2c2 with SMTP id jt23-20020a170906dfd700b00a45b76102c2mr347813ejc.60.1710165370324; Mon, 11 Mar 2024 06:56:10 -0700 (PDT) Message-ID: Date: Mon, 11 Mar 2024 14:56:09 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH v3 03/16] misra: add deviations for direct inclusion guards Content-Language: en-US To: Simone Ballarin Cc: consulting@bugseng.com, sstabellini@kernel.org, Andrew Cooper , George Dunlap , Julien Grall , Wei Liu , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <1fdfec12fd2207c294f50d01d8ec32f890b915d7.1710145041.git.simone.ballarin@bugseng.com> <6472eb42-157a-4d6e-b5bb-daa74fbbd97b@bugseng.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <6472eb42-157a-4d6e-b5bb-daa74fbbd97b@bugseng.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 11.03.2024 13:00, Simone Ballarin wrote: > On 11/03/24 11:08, Jan Beulich wrote: >> On 11.03.2024 09:59, Simone Ballarin wrote: >>> --- a/xen/arch/arm/include/asm/hypercall.h >>> +++ b/xen/arch/arm/include/asm/hypercall.h >>> @@ -1,3 +1,4 @@ >>> +/* SAF-5-safe direct inclusion guard before */ >>> #ifndef __XEN_HYPERCALL_H__ >>> #error "asm/hypercall.h should not be included directly - include xen/hypercall.h instead" >>> #endif >>> --- a/xen/arch/x86/include/asm/hypercall.h >>> +++ b/xen/arch/x86/include/asm/hypercall.h >>> @@ -2,6 +2,7 @@ >>> * asm-x86/hypercall.h >>> */ >>> >>> +/* SAF-5-safe direct inclusion guard before */ >>> #ifndef __XEN_HYPERCALL_H__ >>> #error "asm/hypercall.h should not be included directly - include xen/hypercall.h instead" >>> #endif >> >> Iirc it was said that this way checking for correct guards is suppressed >> altogether in Eclair, which is not what we want. Can you clarify this, >> please? >> > > My first change was moving this check inside the guard. > You commented my patch saying that this would be an error because someone can > include it directly if it has already been included indirectly. > I replied telling that this was the case also before the change. > You agreed with me, and we decided that the correct thing would be fixing the > check and not apply my temporary change to address the finding. > > Considering that the code should be amended, a SAF deviation seems to me > the most appropriate way for suppressing these findings. Since I don't feel your reply addresses my question, asking differently: With your change in place, will failure to have proper guards (later) in these headers still be reported by Eclair? Jan From xen-devel-bounces@lists.xenproject.org Mon Mar 11 14:00:12 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 14:00:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691511.1077535 (Exim 4.92) (envelope-from ) id 1rjgCH-00019J-0o; Mon, 11 Mar 2024 14:00:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691511.1077535; Mon, 11 Mar 2024 14:00:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjgCG-00019C-UW; Mon, 11 Mar 2024 14:00:08 +0000 Received: by outflank-mailman (input) for mailman id 691511; Mon, 11 Mar 2024 14:00:07 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjgCF-000196-FO for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 14:00:07 +0000 Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [2a00:1450:4864:20::534]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id aa3edf29-dfaf-11ee-afdc-a90da7624cb6; Mon, 11 Mar 2024 15:00:06 +0100 (CET) Received: by mail-ed1-x534.google.com with SMTP id 4fb4d7f45d1cf-5654f700705so5538613a12.1 for ; Mon, 11 Mar 2024 07:00:06 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id o23-20020aa7c7d7000000b005686b5c3c1asm85188eds.22.2024.03.11.07.00.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Mar 2024 07:00:05 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: aa3edf29-dfaf-11ee-afdc-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1710165606; x=1710770406; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=XpooZHg+CV2yNcshQoJ6X8E7wnLTEI5aoH7Wph+2j9M=; b=HgiZpdfBl3CRRNyXbVs/nURddAHqRJsYPfum7hfhHh+qsGBS4VB6P9fYY6QxDyfgnD QmhkqK1Y7/MkXVpZHgLFG0o45GduVzyW+Mbq6tqmdCS7MKduFFCW+ibewpnKIptkkXSh QsvKM8ueg5v+hfAyL1IL1V5087Z3mS7EnnUhh4+FjLiJHfZo7pV7mo+jS0k6b/Mf//wU xM2T5A9sQyai3O0Nkui872qzJoLpE/3CIueVGBb4qtjzxHXmPKsNsSjxy/pOPPBDWALG KB+qePDI2S18XtE4O6W0ZuNM3Gw9Sr8ddputF60cbY7mL8uLYQwR/7KZl8WHdTuDCshh GPAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710165606; x=1710770406; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=XpooZHg+CV2yNcshQoJ6X8E7wnLTEI5aoH7Wph+2j9M=; b=KHxPAc7PwLECyF6mfhP1znwtfdi/8ojsBH3I7zcRT3LZE/xAE9IPZNnOq2Q35y6s/h p7acQn9wCOCxl8zhOGGoUmJCkDjdWK4PtAWJ9OOC/88T+5uA04RpZycfXgpJYjPGHcfg XLkFX5oGN+W2uAP593GL4Hggqo0GrNKfbNRluie/++w1A4gskuhz9PTkg0qgXPrK5frs WaaoXIkNpazGHsdaeql+8sY2IEECSL15rqMje2yvXYFTK2BAVquvcMnxVrWaAI75jDB5 tXmerZUr7a7GXGIJINPm5p1xlBpogV99FrZ4Lar/QsfE/H7R0qNRaovyOahTtTN9+aPm brOQ== X-Forwarded-Encrypted: i=1; AJvYcCXvmDvq3rrpA8n4nROacxa5TcOLz2XpbXwPcaNcMymX/ipfjv9NT7+J4kLzKj9BFtpTlKdSUwBCRHZ66a4J0gHuc81wvTKEwmTcromVvQg= X-Gm-Message-State: AOJu0Yy2QdZSij2UZTs1KrsC51aaDRzcWTtYrQd9FMvik4slxWNDmrKH rJeD+Roqfu7Vft7Q81C0sgiixjOChjl9f5XNlEbygeXaTzOcfkHoTXh0/2FeAQ== X-Google-Smtp-Source: AGHT+IHjXTwhhguu9vFXH9+NGxITtnMVQkkWKdAVEdfoTN212VSGRh5dOsTazD8hQ6N0jEwmvBdn5A== X-Received: by 2002:a50:9b15:0:b0:567:26ba:d207 with SMTP id o21-20020a509b15000000b0056726bad207mr303533edi.18.1710165606019; Mon, 11 Mar 2024 07:00:06 -0700 (PDT) Message-ID: Date: Mon, 11 Mar 2024 15:00:04 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH v3 04/16] xen/arm: address violations of MISRA C:2012 Directive 4.10 Content-Language: en-US To: Simone Ballarin Cc: consulting@bugseng.com, sstabellini@kernel.org, Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Maria Celeste Cesario , xen-devel@lists.xenproject.org References: <868ede5a23489e018e272188edfbee572d1ad393.1710145041.git.simone.ballarin@bugseng.com> <332ebf49-9aa4-42fd-99be-bda16580c92f@suse.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 11.03.2024 13:07, Simone Ballarin wrote: > On 11/03/24 11:10, Jan Beulich wrote: >> On 11.03.2024 09:59, Simone Ballarin wrote: >>> --- a/xen/arch/arm/efi/efi-boot.h >>> +++ b/xen/arch/arm/efi/efi-boot.h >>> @@ -3,6 +3,10 @@ >>> * is intended to be included by common/efi/boot.c _only_, and >>> * therefore can define arch specific global variables. >>> */ >>> + >>> +#ifndef XEN_ARCH_ARM_EFI_EFI_BOOT_H >>> +#define XEN_ARCH_ARM_EFI_EFI_BOOT_H >> >> Related to my question raised against the cover letter, what does the >> XEN_ prefix gain us here? All building of the hypervisor binaries >> happens inside the xen/ subtree. > > what do you thing about adding this rule: > arch/// -> ___H > ? Yet better - even the ARCH_ is gone then. Of course we want to then be reasonably sure no arch appears with a name matching some of the other top-level (under xen/) subdirs. Jan From xen-devel-bounces@lists.xenproject.org Mon Mar 11 14:14:33 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 14:14:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691516.1077545 (Exim 4.92) (envelope-from ) id 1rjgQ7-00036C-7F; Mon, 11 Mar 2024 14:14:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691516.1077545; Mon, 11 Mar 2024 14:14:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjgQ7-000365-4e; Mon, 11 Mar 2024 14:14:27 +0000 Received: by outflank-mailman (input) for mailman id 691516; Mon, 11 Mar 2024 14:14:25 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjgQ5-00035z-Ca for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 14:14:25 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id a956c6cd-dfb1-11ee-afdc-a90da7624cb6; Mon, 11 Mar 2024 15:14:24 +0100 (CET) Received: from [192.168.1.9] (net-93-144-106-196.cust.vodafonedsl.it [93.144.106.196]) by support.bugseng.com (Postfix) with ESMTPSA id F2D074EE0C90; Mon, 11 Mar 2024 15:14:22 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a956c6cd-dfb1-11ee-afdc-a90da7624cb6 Message-ID: <3e4bb597-3624-418e-93d0-b95042fd27a7@bugseng.com> Date: Mon, 11 Mar 2024 15:14:22 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH v3 03/16] misra: add deviations for direct inclusion guards Content-Language: en-US To: Jan Beulich Cc: consulting@bugseng.com, sstabellini@kernel.org, Andrew Cooper , George Dunlap , Julien Grall , Wei Liu , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <1fdfec12fd2207c294f50d01d8ec32f890b915d7.1710145041.git.simone.ballarin@bugseng.com> <6472eb42-157a-4d6e-b5bb-daa74fbbd97b@bugseng.com> From: Simone Ballarin Organization: BUGSENG In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 11/03/24 14:56, Jan Beulich wrote: > On 11.03.2024 13:00, Simone Ballarin wrote: >> On 11/03/24 11:08, Jan Beulich wrote: >>> On 11.03.2024 09:59, Simone Ballarin wrote: >>>> --- a/xen/arch/arm/include/asm/hypercall.h >>>> +++ b/xen/arch/arm/include/asm/hypercall.h >>>> @@ -1,3 +1,4 @@ >>>> +/* SAF-5-safe direct inclusion guard before */ >>>> #ifndef __XEN_HYPERCALL_H__ >>>> #error "asm/hypercall.h should not be included directly - include xen/hypercall.h instead" >>>> #endif >>>> --- a/xen/arch/x86/include/asm/hypercall.h >>>> +++ b/xen/arch/x86/include/asm/hypercall.h >>>> @@ -2,6 +2,7 @@ >>>> * asm-x86/hypercall.h >>>> */ >>>> >>>> +/* SAF-5-safe direct inclusion guard before */ >>>> #ifndef __XEN_HYPERCALL_H__ >>>> #error "asm/hypercall.h should not be included directly - include xen/hypercall.h instead" >>>> #endif >>> >>> Iirc it was said that this way checking for correct guards is suppressed >>> altogether in Eclair, which is not what we want. Can you clarify this, >>> please? >>> >> >> My first change was moving this check inside the guard. >> You commented my patch saying that this would be an error because someone can >> include it directly if it has already been included indirectly. >> I replied telling that this was the case also before the change. >> You agreed with me, and we decided that the correct thing would be fixing the >> check and not apply my temporary change to address the finding. >> >> Considering that the code should be amended, a SAF deviation seems to me >> the most appropriate way for suppressing these findings. > > Since I don't feel your reply addresses my question, asking differently: With > your change in place, will failure to have proper guards (later) in these > headers still be reported by Eclair? > > Jan > No, if you put something between the check and the guard, no violation will be reported. -- Simone Ballarin, M.Sc. Field Application Engineer, BUGSENG (https://bugseng.com) From xen-devel-bounces@lists.xenproject.org Mon Mar 11 15:49:13 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 15:49:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691531.1077561 (Exim 4.92) (envelope-from ) id 1rjhta-0006NQ-MT; Mon, 11 Mar 2024 15:48:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691531.1077561; Mon, 11 Mar 2024 15:48:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjhta-0006NJ-Jm; Mon, 11 Mar 2024 15:48:58 +0000 Received: by outflank-mailman (input) for mailman id 691531; Mon, 11 Mar 2024 15:48:57 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjhtZ-0006ND-Ad for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 15:48:57 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id ddc294d0-dfbe-11ee-afdc-a90da7624cb6; Mon, 11 Mar 2024 16:48:55 +0100 (CET) Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) by support.bugseng.com (Postfix) with ESMTPA id DDC404EE0C90; Mon, 11 Mar 2024 16:48:54 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ddc294d0-dfbe-11ee-afdc-a90da7624cb6 MIME-Version: 1.0 Date: Mon, 11 Mar 2024 16:48:54 +0100 From: Nicola Vetrini To: Jan Beulich Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, consulting@bugseng.com, bertrand.marquis@arm.com, julien@xen.org, Andrew Cooper , George Dunlap , Wei Liu , xen-devel@lists.xenproject.org Subject: Re: [XEN PATCH] xen/compiler: deviate the inline macro for MISRA C Rule 20.4 In-Reply-To: <6e2c0cb6-89de-4429-8f43-c4687a26cefe@suse.com> References: <6e2c0cb6-89de-4429-8f43-c4687a26cefe@suse.com> Message-ID: <81b1e9adc87618865c0134fe069d41cf@bugseng.com> X-Sender: nicola.vetrini@bugseng.com Organization: BUGSENG s.r.l. Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 2024-03-11 08:32, Jan Beulich wrote: > On 08.03.2024 09:10, Nicola Vetrini wrote: >> Rule 20.4 states: "A macro shall not be defined with the same name >> as a keyword". >> >> Defining this macro with the same name as the inline keyword >> allows for additionally checking that out-of-lined static inline >> functions end up in the correct section while minimizing churn and >> has a positive impact on the overall safety. See [1] for additional >> context on the motivation of this deviation. >> >> No functional change. >> >> [1] >> https://lore.kernel.org/xen-devel/adaa6d55-266d-4df8-8967-9340080d17e4@citrix.com/ >> >> Signed-off-by: Nicola Vetrini >> --- >> docs/misra/safe.json | 8 ++++++++ >> xen/include/xen/compiler.h | 1 + >> 2 files changed, 9 insertions(+) >> >> diff --git a/docs/misra/safe.json b/docs/misra/safe.json >> index 952324f85cf9..a2bbacddf06a 100644 >> --- a/docs/misra/safe.json >> +++ b/docs/misra/safe.json >> @@ -28,6 +28,14 @@ >> }, >> { >> "id": "SAF-3-safe", >> + "analyser": { >> + "eclair": "MC3R1.R20.4" >> + }, >> + "name": "MC3R1.R20.4: allow the augmentation of the >> inline keyword in some build configurations", >> + "text": "The definition of this macro named inline allows >> further checking in some build configurations that certain symbols end >> up in the right sections." >> + }, > > With this wording the ID isn't going to be re-usable anywhere else. > Even > if the exact same reasoning would apply. > What about "name": "MC3R1.R20.4: allow the definition of a macro with the same name as a keyword in some special cases" and "text": "The definition of a macro with the same name as a keyword can be useful in certain configurations to improve the guarantees that can be provided by Xen. See docs/misra/deviations.rst for a precise rationale for all such cases. and then.. >> + { >> + "id": "SAF-4-safe", >> "analyser": {}, >> "name": "Sentinel", >> "text": "Next ID to be used" >> diff --git a/xen/include/xen/compiler.h b/xen/include/xen/compiler.h >> index 16d554f2a593..e3d9f9fb8e4b 100644 >> --- a/xen/include/xen/compiler.h >> +++ b/xen/include/xen/compiler.h >> @@ -82,6 +82,7 @@ >> * inline functions not expanded inline get placed in .init.text. >> */ >> #include >> +/* SAF-3-safe MISRA C Rule 20.4: define the inline macro to perform >> checks */ >> #define inline inline __init >> #endif > > I don't think the definition is "to perform checks"; it's rather to > make > sure checking elsewhere wouldn't (seemingly) randomly fail. 'Override > "inline" for section contents checks to pass when the compiler chooses > not to inline a particular function' perhaps? Albeit that's getting > long-ish, I fear. put this message in deviations.rst > > Jan is this proposal more appealing? -- Nicola Vetrini, BSc Software Engineer, BUGSENG srl (https://bugseng.com) From xen-devel-bounces@lists.xenproject.org Mon Mar 11 16:04:31 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 16:04:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691534.1077571 (Exim 4.92) (envelope-from ) id 1rji8W-000121-PU; Mon, 11 Mar 2024 16:04:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691534.1077571; Mon, 11 Mar 2024 16:04:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rji8W-00011u-Ma; Mon, 11 Mar 2024 16:04:24 +0000 Received: by outflank-mailman (input) for mailman id 691534; Mon, 11 Mar 2024 16:04:23 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rji8U-00011o-JM for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 16:04:23 +0000 Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [2a00:1450:4864:20::42d]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 04dc5da0-dfc1-11ee-a1ee-f123f15fe8a2; Mon, 11 Mar 2024 17:04:20 +0100 (CET) Received: by mail-wr1-x42d.google.com with SMTP id ffacd0b85a97d-33e94c12f33so1411626f8f.3 for ; Mon, 11 Mar 2024 09:04:20 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 04dc5da0-dfc1-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; t=1710173059; x=1710777859; darn=lists.xenproject.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=6Fr8o0HYE1r5nGvdTOwaWJX0ACdCUNcwkOd1BS07tq4=; b=KRMBuk/skYNV+X57BzzX4ByCZNW4l7UqqZ92X4X4Q10I0mAa2LBl97F2Tqhtsv22sw BDLL/ErxGvi474OQSbsTBZcXEO2lPLPWEc7Uxc3jkWdhEZlvJ2MoEJE4ddtdCIUHDAUI 4N6Su2LgjsNi3MYOfQsM6sHXxmJVABGfr13DvrDg0gZt0T+wNeSN8SVbw1TVjCH/Wu8m L8yTCw5NC36PSdDsbVfxWgcNE+8f+6KgIVXJddFEuGS4PxRDYQEvQJx+qMbysCkYQJBE jxwAj15WAvZrar/HMZ5CSkcoYP2nRon/C/lkFSJc/ycQPeqPJGewJtxchk+7nteXyQNd nuqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710173059; x=1710777859; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=6Fr8o0HYE1r5nGvdTOwaWJX0ACdCUNcwkOd1BS07tq4=; b=GQrXtCIcoG0tWskjCpfa8NxgN38LsapI7KC1mhlBV4j64mLadkxq/fD+5m8KJvvlmu oI0IpJfMqdqnKKcBZvucz9+Eu3G+VBY7li+v/Xb8/1XEoo53Bc4ntQCd7cJWoOQ+oZvw 26aolMfRfwn0fa2JZHvjHICEkTh0JD/2Rs43waCqpVHn4ujsqTquXJc7ym6aSVeWKgag /uEz1Y6wrurTQy3usYH7BLPYU9GsPiHkCiAn8VrqpNPpt7XsgA+VhXooJ0H/QGVXpaKk nhBW8BXzn+nX3nbrrhdn4AOTkDY3I5+tDmTvDRG9fW5t+xbEGJctBzHhoYO0XfmfaOX7 09UQ== X-Gm-Message-State: AOJu0Yz/nxHALiQ2aCZgsaykh9FFtutRBF7RfNhwf0tofGdwoyEItqUZ tATIX22M3h9hdzDmWY4xTNAd67vgzgCJW/OpnKVsvWsaEjolKJr1DifrhuG4dw686P8uSUw5hqV prrB4IyyO7gqoSRXCv0XPx5uGus0= X-Google-Smtp-Source: AGHT+IGm3YGrBsha2YmM1pLIcxrpruCFHxGFn9mdqFLzRGv2HdccNMQWFD9IutsP1FuwId2lPrsIDVYGCGhm4vjcqwQ= X-Received: by 2002:adf:f68c:0:b0:33e:800d:e87a with SMTP id v12-20020adff68c000000b0033e800de87amr4321535wrp.34.1710173059216; Mon, 11 Mar 2024 09:04:19 -0700 (PDT) MIME-Version: 1.0 References: <5b3f46f3-3c9f-57fb-00a5-94128f41e34a@suse.com> In-Reply-To: <5b3f46f3-3c9f-57fb-00a5-94128f41e34a@suse.com> From: George Dunlap Date: Mon, 11 Mar 2024 16:04:07 +0000 Message-ID: Subject: Re: [PATCH v2] x86/PoD: move increment of entry count To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , George Dunlap Content-Type: multipart/alternative; boundary="000000000000b2ffc8061364b1fd" --000000000000b2ffc8061364b1fd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jan 4, 2022 at 10:58=E2=80=AFAM Jan Beulich wro= te: > When not holding the PoD lock across the entire region covering P2M > update and stats update, the entry count should indicate too large a > value in preference to a too small one, to avoid functions bailing early > when they find the count is zero. Hence increments should happen ahead > of P2M updates, while decrements should happen only after. Deal with the > one place where this hasn't been the case yet. > > Signed-off-by: Jan Beulich > --- > v2: Add comments. > --- > While it might be possible to hold the PoD lock over the entire > operation, I didn't want to chance introducing a lock order violation on > a perhaps rarely taken code path. > [No idea how I missed this 2 years ago, sorry for the delay] Actually I think just holding the lock is probably the right thing to do. We already grab gfn_lock() over the entire operation, and p2m_set_entry() ASSERTs gfn_locked_by_me(); and all we have to do to trigger the check is boot any guest in PoD mode at all; surely we have osstest tests for that? -George --000000000000b2ffc8061364b1fd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jan 4, 2022 at 10:58=E2=80=AFAM J= an Beulich <jbeul= ich@suse.com> wrote:
When not holding the PoD lock across= the entire region covering P2M
update and stats update, the entry count should indicate too large a
value in preference to a too small one, to avoid functions bailing early when they find the count is zero. Hence increments should happen ahead
of P2M updates, while decrements should happen only after. Deal with the one place where this hasn't been the case yet.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v2: Add comments.
---
While it might be possible to hold the PoD lock over the entire
operation, I didn't want to chance introducing a lock order violation o= n
a perhaps rarely taken code path.

[No i= dea how I missed this 2 years ago, sorry for the delay]

Actually I think just holding the lock is probably the right thing to= do.=C2=A0 We already grab gfn_lock() over the entire operation, and p2m_se= t_entry() ASSERTs gfn_locked_by_me(); and all we have to do to trigger the = check is boot any guest in PoD mode at all; surely we have osstest tests fo= r that?

=C2=A0-George
--000000000000b2ffc8061364b1fd-- From xen-devel-bounces@lists.xenproject.org Mon Mar 11 16:09:31 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 16:09:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691536.1077581 (Exim 4.92) (envelope-from ) id 1rjiDQ-0001i7-AG; Mon, 11 Mar 2024 16:09:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691536.1077581; Mon, 11 Mar 2024 16:09:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjiDQ-0001i0-7W; Mon, 11 Mar 2024 16:09:28 +0000 Received: by outflank-mailman (input) for mailman id 691536; Mon, 11 Mar 2024 16:09:26 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjiDO-0001hu-B8 for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 16:09:26 +0000 Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [2a00:1450:4864:20::62c]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id bad487ce-dfc1-11ee-afdc-a90da7624cb6; Mon, 11 Mar 2024 17:09:25 +0100 (CET) Received: by mail-ej1-x62c.google.com with SMTP id a640c23a62f3a-a45ecef71deso361189166b.2 for ; Mon, 11 Mar 2024 09:09:25 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id s24-20020a170906a19800b00a457a55b814sm2978213ejy.73.2024.03.11.09.09.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Mar 2024 09:09:24 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: bad487ce-dfc1-11ee-afdc-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1710173365; x=1710778165; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=nJqpmJtgmVhNC95Vex/8VJRvWc2nAOnRuBlXFdHMVkA=; b=gXZ6rWUQ+psHO56DhDoDvMgBX2brOVtu/Yd3HJX3nlZFkiA0b0nRaoi6NxfJtm2p7A 3TawN4SycR/X08qsWQxFnkjHTxQY8pQLLB9quAq3kS7LErhmkF6JZCQuKUFhkLHg6/Jn wd1LHIC6HmkEJEKdffaDfqiW80uu4W5J2pWrEWeUE+Un4XxbFU2G+VP+7oyPBnq89MZ2 IGBHSn4qV/aQDt86/SF9b0Smrw5wrmDff/cC/4Y70jwR+UQM1p8yA08/cPipdtkdWZmG Nx6qBua1wtN7xOzhyUTfsyZmk8rObzUqhBgUwFUt44/qZSYd5Kjo4RLwDt3JWlofWpBj WP9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710173365; x=1710778165; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=nJqpmJtgmVhNC95Vex/8VJRvWc2nAOnRuBlXFdHMVkA=; b=vurPfGsM7WHYm+3vPABmNgF9mGL02YNEoo01pxlW8ougtaPfKNrVJQgEq8zbt/0WZc se1eToe71PQD3hYELcw0NEg82ecnnjHLhWQ1IlFNjiMkfQ4/wSeFDOQ/SXGW8ApOS0wR mN8MxRiZPLydNUHwkt50Vvr6obn1EjazV8lGVZkE2XNJp0yPLKChDTT/ngMMi0ermq0O 0AWvIhumPKyvOyBmXfNWAa70fLQTjXeml/wy3pVquadGQxl7tAvf2KT2gHl4vEPoI45D OGi03mvxkBmg9NO0/0A1qL1C85WxxQ5Ok1wW2WkuaLuWAXEs/e9EaifQOnG7ng5kag6L a87w== X-Forwarded-Encrypted: i=1; AJvYcCUhhqK60mNNMFMrYexLB9P3CITcmNyR+Yp1jQ1d801qz0WbsKgoqX/qC4s8ViQr01f9qVaQK5UjO6Z+9D01lgBJH7QZdiY+khWIPUvm4EE= X-Gm-Message-State: AOJu0YxR5dGxgdoMhF6VQda8JZeYx2GodteDkSTDMErIaZHI87MIc7WI xCUhLDdW+/F1Ah8kXtCjaY2fnqj07pGN+iqrG71k6xT88CmdKmanUhkJGO9JtrVXQnExo7z7AVg = X-Google-Smtp-Source: AGHT+IGj3cDhbwfLVHu7QpyqTxjrR5MTEWR4A/Nly8OTgqnfr+qJyziQyA95owfAwJIsYClEmermrg== X-Received: by 2002:a17:906:b7c6:b0:a46:2c22:7ec6 with SMTP id fy6-20020a170906b7c600b00a462c227ec6mr1792493ejb.35.1710173364751; Mon, 11 Mar 2024 09:09:24 -0700 (PDT) Message-ID: Date: Mon, 11 Mar 2024 17:09:23 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH] xen/compiler: deviate the inline macro for MISRA C Rule 20.4 Content-Language: en-US To: Nicola Vetrini Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, consulting@bugseng.com, bertrand.marquis@arm.com, julien@xen.org, Andrew Cooper , George Dunlap , Wei Liu , xen-devel@lists.xenproject.org References: <6e2c0cb6-89de-4429-8f43-c4687a26cefe@suse.com> <81b1e9adc87618865c0134fe069d41cf@bugseng.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <81b1e9adc87618865c0134fe069d41cf@bugseng.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 11.03.2024 16:48, Nicola Vetrini wrote: > On 2024-03-11 08:32, Jan Beulich wrote: >> On 08.03.2024 09:10, Nicola Vetrini wrote: >>> --- a/docs/misra/safe.json >>> +++ b/docs/misra/safe.json >>> @@ -28,6 +28,14 @@ >>> }, >>> { >>> "id": "SAF-3-safe", >>> + "analyser": { >>> + "eclair": "MC3R1.R20.4" >>> + }, >>> + "name": "MC3R1.R20.4: allow the augmentation of the >>> inline keyword in some build configurations", >>> + "text": "The definition of this macro named inline allows >>> further checking in some build configurations that certain symbols end >>> up in the right sections." >>> + }, >> >> With this wording the ID isn't going to be re-usable anywhere else. >> Even >> if the exact same reasoning would apply. >> > > What about > > "name": "MC3R1.R20.4: allow the definition of a macro with the same name > as a keyword in some special cases" > > and > > "text": "The definition of a macro with the same name as a keyword can > be useful in certain configurations to improve the guarantees that can > be provided by Xen. See docs/misra/deviations.rst for a precise > rationale for all such cases. > > and then.. > >>> + { >>> + "id": "SAF-4-safe", >>> "analyser": {}, >>> "name": "Sentinel", >>> "text": "Next ID to be used" >>> diff --git a/xen/include/xen/compiler.h b/xen/include/xen/compiler.h >>> index 16d554f2a593..e3d9f9fb8e4b 100644 >>> --- a/xen/include/xen/compiler.h >>> +++ b/xen/include/xen/compiler.h >>> @@ -82,6 +82,7 @@ >>> * inline functions not expanded inline get placed in .init.text. >>> */ >>> #include >>> +/* SAF-3-safe MISRA C Rule 20.4: define the inline macro to perform >>> checks */ >>> #define inline inline __init >>> #endif >> >> I don't think the definition is "to perform checks"; it's rather to >> make >> sure checking elsewhere wouldn't (seemingly) randomly fail. 'Override >> "inline" for section contents checks to pass when the compiler chooses >> not to inline a particular function' perhaps? Albeit that's getting >> long-ish, I fear. > > put this message in deviations.rst > > is this proposal more appealing? I think so, yes. Jan From xen-devel-bounces@lists.xenproject.org Mon Mar 11 16:20:22 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 16:20:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691541.1077591 (Exim 4.92) (envelope-from ) id 1rjiNs-0004LP-BR; Mon, 11 Mar 2024 16:20:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691541.1077591; Mon, 11 Mar 2024 16:20:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjiNs-0004LI-7V; Mon, 11 Mar 2024 16:20:16 +0000 Received: by outflank-mailman (input) for mailman id 691541; Mon, 11 Mar 2024 16:20:14 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjiNq-0004L8-Ib; Mon, 11 Mar 2024 16:20:14 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjiNq-0000JP-Dp; Mon, 11 Mar 2024 16:20:14 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjiNq-0002Hj-3C; Mon, 11 Mar 2024 16:20:14 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rjiNq-0000fJ-2h; Mon, 11 Mar 2024 16:20:14 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=GES3elDHKmcUbhacUW06b+bS7mSNz+ZT1vAf/8fuKxA=; b=56lrB1l3b4ruSTeDMlFaQMbCHv /aaZxQGy0sBRQpk/nrIuOyiKlGEmJTDXbnXzHr8WsJqkTdz6pabL5JqWXRxj7n0ckiTv8x/OOqwg/ ZSqR3/Ai9w1tkKhswlaCCf3NRtiDcD8ghZ7/aX7bIlGAUBK+YktqZCUnfoHJ1VzOOF6Q=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 184995: tolerable all pass - PUSHED X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=7c81558208de7858251b62f168a449be84305595 X-Osstest-Versions-That: xen=1396892d801cf148644cd5590be2f143648f9083 From: osstest service owner Date: Mon, 11 Mar 2024 16:20:14 +0000 flight 184995 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/184995/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass version targeted for testing: xen 7c81558208de7858251b62f168a449be84305595 baseline version: xen 1396892d801cf148644cd5590be2f143648f9083 Last test of basis 184993 2024-03-11 09:02:15 Z 0 days Testing same since 184995 2024-03-11 13:00:25 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Roger Pau Monne Roger Pau Monné 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-amd64 pass 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 1396892d80..7c81558208 7c81558208de7858251b62f168a449be84305595 -> smoke From xen-devel-bounces@lists.xenproject.org Mon Mar 11 16:54:13 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 16:54:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691546.1077601 (Exim 4.92) (envelope-from ) id 1rjiuV-0008OY-Ow; Mon, 11 Mar 2024 16:53:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691546.1077601; Mon, 11 Mar 2024 16:53:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjiuV-0008OR-MK; Mon, 11 Mar 2024 16:53:59 +0000 Received: by outflank-mailman (input) for mailman id 691546; Mon, 11 Mar 2024 16:53:57 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjiuT-0008OL-Nv for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 16:53:57 +0000 Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [2a00:1450:4864:20::62e]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id f29ded19-dfc7-11ee-afdc-a90da7624cb6; Mon, 11 Mar 2024 17:53:55 +0100 (CET) Received: by mail-ej1-x62e.google.com with SMTP id a640c23a62f3a-a3fb8b0b7acso362654266b.2 for ; Mon, 11 Mar 2024 09:53:55 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id d13-20020a170906370d00b00a44e180b9a5sm3018723ejc.1.2024.03.11.09.53.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Mar 2024 09:53:55 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f29ded19-dfc7-11ee-afdc-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1710176035; x=1710780835; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=KCuXvdGMlzHVbbFUP+iVfUemSQDFYHFbdrbEPZTW4Ac=; b=UcImCZQ3E0PSEydMGCdhtBAcS7ca04tR9farzbJQw188VIzourK7drlnm4Mjmeoco0 xoI2OlcPOwYroUcvXyit5piQiyqLABOvC0U0USwpI/XuHP+DPZDRMupPLx1pbCp5PvXV t3zU4UieXQGrcckpUv6WLw9VIkblQLGjL3oZ4OfuC4ZnberQNPcmi3Yg18Ky2l9iFRFH bK9LDAk9aAAg6Sp2swrHRzMNJMcvG7qe3UKmH8VDn4vTAkqfKzbcZYo08WTR0gQbadhN EztpQHbpuSbFMlvAgX8DumHj/RMR7aXHvy6ml+vkw/f3kkSM9XNms7ec3J4SN+NC7mqr m3Wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710176035; x=1710780835; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=KCuXvdGMlzHVbbFUP+iVfUemSQDFYHFbdrbEPZTW4Ac=; b=e1UJISGgIMhmOeEQn+EYI0KAWRU3aAGWHcmq0R2PRWR1GWrdf7EtCMZeYRjhPKMdMA ey9ieusFumCZrht3efy6yWQglPVqbOq/t6q/W7+2fXqUSm+oW2EKlQcJbiuW5f3SpQDL mBPMlAgeJ7D6l0O3drUnrqmWLh06eGfKHJKC4XMRjcLsTv20V1Ui2RCyYAFwaMNoL3Bj xEgasLf6iJUOCOqskYu8lIGoBpoTb4PnhtKvzEnHYwDYexJlCI+kEVAixM1febNDuD0J xvuIaewdlGllIFHXnxANv8wWRzCH7YVCTPm//WbXUBVlTRkzKQ47iZxR3S1kXfTD7s4X m9yw== X-Forwarded-Encrypted: i=1; AJvYcCWbPNCdAxM48mhbYHfrhchQj5RipKudAjGwqyIzBrlMhYyHaZQULPIERMPqJT5e1Ew9HZcycez2DItdzM/3tpipbAK13WTlmFdvYkg7HsY= X-Gm-Message-State: AOJu0YwXjvppnvBfv1FeWT/s9tMywnUZ/gBytaBumhQ6Fls+uwde0AMa 84jcq+Q0bGnAjsM2duDuFxachF4VWxralkDXOA97YlhqjI2AqLt7mrknxifxQw== X-Google-Smtp-Source: AGHT+IHgJzCMeVgLtTAY7EFtMZOfMxMQvPa/Fx3Wbc97SvJp+LUwUayqw1sqd2Bfl0DGcvfJXmkQ4g== X-Received: by 2002:a17:907:a0cc:b0:a45:f71e:9e49 with SMTP id hw12-20020a170907a0cc00b00a45f71e9e49mr4217287ejc.67.1710176035347; Mon, 11 Mar 2024 09:53:55 -0700 (PDT) Message-ID: <5b4054c0-a5ab-4fc0-9754-8253b12c849d@suse.com> Date: Mon, 11 Mar 2024 17:53:54 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 3/3] x86/PVH: Support relocatable dom0 kernels Content-Language: en-US To: Jason Andryuk Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu , George Dunlap , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20240306185032.103216-1-jason.andryuk@amd.com> <20240306185032.103216-4-jason.andryuk@amd.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20240306185032.103216-4-jason.andryuk@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 06.03.2024 19:50, Jason Andryuk wrote: > --- a/xen/arch/x86/hvm/dom0_build.c > +++ b/xen/arch/x86/hvm/dom0_build.c > @@ -537,6 +537,109 @@ static paddr_t __init find_memory( > return INVALID_PADDR; > } > > +static bool __init check_load_address( > + const struct domain *d, const struct elf_binary *elf) > +{ > + paddr_t kernel_start = (paddr_t)elf->dest_base & PAGE_MASK; > + paddr_t kernel_end = ROUNDUP((paddr_t)elf->dest_base + elf->dest_size, > + PAGE_SIZE); > + unsigned int i; > + > + /* > + * The memory map is sorted and all RAM regions starts and sizes are > + * aligned to page boundaries. > + */ > + for ( i = 0; i < d->arch.nr_e820; i++ ) > + { > + paddr_t start = d->arch.e820[i].addr; > + paddr_t end = d->arch.e820[i].addr + d->arch.e820[i].size; > + > + if ( start <= kernel_start && > + end >= kernel_end && > + d->arch.e820[i].type == E820_RAM ) > + return true; > + } > + > + return false; > +} > + > +/* > + * Find an e820 RAM region that fits the kernel at a suitable alignment. > + */ > +static paddr_t find_kernel_memory( __init ? Jan From xen-devel-bounces@lists.xenproject.org Mon Mar 11 16:58:11 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 16:58:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691549.1077611 (Exim 4.92) (envelope-from ) id 1rjiyY-0000Y4-8U; Mon, 11 Mar 2024 16:58:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691549.1077611; Mon, 11 Mar 2024 16:58:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjiyY-0000Xx-5I; Mon, 11 Mar 2024 16:58:10 +0000 Received: by outflank-mailman (input) for mailman id 691549; Mon, 11 Mar 2024 16:58:09 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjiyX-0000Xr-FG for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 16:58:09 +0000 Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [2a00:1450:4864:20::529]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 88a64ae6-dfc8-11ee-a1ee-f123f15fe8a2; Mon, 11 Mar 2024 17:58:07 +0100 (CET) Received: by mail-ed1-x529.google.com with SMTP id 4fb4d7f45d1cf-5658082d2c4so6009552a12.1 for ; Mon, 11 Mar 2024 09:58:07 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id n10-20020aa7d04a000000b0056826248468sm3106458edo.89.2024.03.11.09.58.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Mar 2024 09:58:06 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 88a64ae6-dfc8-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1710176287; x=1710781087; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=wWpKp7nCxFXHUhoAq4Q++ZBgt4mxrjKsMFSgtPCtRVo=; b=TEV76pKZ7yhEMuDrzJFVLeVLO3tPLe201eA86+QnTrmwyGzRxQkUx/pB5IUtLIgPCM W8qS4a7S84Wn+2fK9Cpys0hClLxfqqFkUAJJ7h7oSw7D6mjQAaGa5ygBkrP1PPH3M4Bx 4EDoMNiptJSqHuPlOjfHYJZ5HhKgiExyVbhvh2GfaHIEWWLj4CxQfYc21CAGvF4NUCHQ WECgz6gmCM9Te7ioJVo39qiPTQ/ol6knPNfbU20fXbKgRCkqolG9eX+x6iRcGzzpFvS4 6jV8FdbYsovvJmkj0VclyzSCklNLuXHVg2hOIXLOQmTaaGnF26Z9AbU/QbcX2IG/v+QT IwEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710176287; x=1710781087; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=wWpKp7nCxFXHUhoAq4Q++ZBgt4mxrjKsMFSgtPCtRVo=; b=by+ZACmZXfKNk3OZnorDN250wf8jyRMzGvq4JQBDC/pmQ2NlcvSosYPXMJpfiWJfuV 6elTmiejQhJHZmovt4t0zv1bXsfQavOPFUAwmkxc2ivVsvKlyvGwaNaVgb2yRp4dI5BO l/Svl+4S0VpKNsmJvQ7QOmuywSk/QFysZbB6ttTtzaTW7+L+x+CvLwuv5lt5pwTcSB0M iKaXxBEayUTC7WSKkK8F9ln8s4UHnV2j4Qs+ZVWtBb0xMC9wwYnBq/glJ8zXxeJUfWD+ bSRDn0vlJOs0ISJ0LbSE0wT8x+zvQosOZ4GuYCK6wW8LjfbhkYdXfDrsfPBUYg/a2O3V 5fPQ== X-Forwarded-Encrypted: i=1; AJvYcCXN29RPB0KMriqTA8VHLU7jPl4d9X8kyPxxKVo7HQjODfS87h2BEIhX5TJC7sljo7qtyKFuLUBuxjhukmx1Vr/r7HqFFVMBBjhQo1NtjGc= X-Gm-Message-State: AOJu0YwbHO/FLSey653rmw26kVuujCRJTppMhd25945KWzIGALLXNZji IFCA8/LWZDeN6/RnaHqWkJCzF16n14npj80CFVfrcDB6S3GxHvVksFrXp2zb/2Dtr6ETex7hjyE = X-Google-Smtp-Source: AGHT+IGmvvpQNvsF6SE3Z/Zct7cvyH6zvS91FpcKfvE+ByByx8N0/GP/o8FnS9zEWoRld0XJJGb91g== X-Received: by 2002:a50:d558:0:b0:568:1444:a828 with SMTP id f24-20020a50d558000000b005681444a828mr3616680edj.37.1710176287047; Mon, 11 Mar 2024 09:58:07 -0700 (PDT) Message-ID: Date: Mon, 11 Mar 2024 17:58:05 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 3/5] xen/domctl, tools: Introduce a new domctl to get guest memory map Content-Language: en-US To: Henry Wang Cc: Wei Liu , Anthony PERARD , Juergen Gross , Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Alec Kwapis , xen-devel@lists.xenproject.org References: <20240308015435.4044339-1-xin.wang2@amd.com> <20240308015435.4044339-4-xin.wang2@amd.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20240308015435.4044339-4-xin.wang2@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 08.03.2024 02:54, Henry Wang wrote: > --- a/xen/include/public/domctl.h > +++ b/xen/include/public/domctl.h > @@ -946,6 +946,25 @@ struct xen_domctl_paging_mempool { > uint64_aligned_t size; /* Size in bytes. */ > }; > > +#define XEN_MAX_MEM_REGIONS 1 > + > +struct xen_mem_region { > + uint64_t start; > + uint64_t size; uint64_aligned_t? > + unsigned int type; uint32_t and explicit padding (incl checking thereof) please. > +}; > +typedef struct xen_mem_region xen_mem_region_t; > +DEFINE_XEN_GUEST_HANDLE(xen_mem_region_t); > + > +struct xen_domctl_mem_map { > + /* IN & OUT */ > + uint32_t nr_mem_regions; > + /* OUT */ > + XEN_GUEST_HANDLE(xen_mem_region_t) buffer; XEN_GUEST_HANDLE_64() and explicit padding (+checking) again please. Jan From xen-devel-bounces@lists.xenproject.org Mon Mar 11 17:07:59 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 17:07:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691552.1077621 (Exim 4.92) (envelope-from ) id 1rjj7x-0002Q6-3e; Mon, 11 Mar 2024 17:07:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691552.1077621; Mon, 11 Mar 2024 17:07:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjj7x-0002Pz-0e; Mon, 11 Mar 2024 17:07:53 +0000 Received: by outflank-mailman (input) for mailman id 691552; Mon, 11 Mar 2024 17:07:52 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjj7w-0002Pq-2E for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 17:07:52 +0000 Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [2a00:1450:4864:20::62a]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id e3be83b4-dfc9-11ee-a1ee-f123f15fe8a2; Mon, 11 Mar 2024 18:07:49 +0100 (CET) Received: by mail-ej1-x62a.google.com with SMTP id a640c23a62f3a-a450bedffdfso603539066b.3 for ; Mon, 11 Mar 2024 10:07:49 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id bn23-20020a170906c0d700b00a462e4d7216sm820484ejb.76.2024.03.11.10.07.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Mar 2024 10:07:49 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e3be83b4-dfc9-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1710176869; x=1710781669; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=0Z3XRah5GvuTNyDs90MKA8ijOhgInolYoRz7oKLKBqE=; b=cnuYRIDs/J5N0Q/0m1OhevI9ewEXGriW6ZKkOF+Ntwr3fwl42xXS0sPc+ConAHr9Jj QkLe+C5gjga9OXCmf1MFEcaz+e03GkKLRXZwbdrRThIhAq8sxMPBM831gVMVAnSmwDNN eorChIcUwQt3Cu+reCKynjMm/jLDwrilBF/TM4mcFyrmy1opJ/p37dTZTxJFST2nb/Dm nXgHH67nDWGIfBNW8D1OkJzGZ/vHV/gxN27planjpEUTA+7e4xKUwt8Rf4LViObCtREy 5dbsfpwtD5bCzB6BP02qqQkGbbfhfrSMuw76y7TjRLCtukyNUb9QtSg1kwVhRJL/+LtW +B4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710176869; x=1710781669; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=0Z3XRah5GvuTNyDs90MKA8ijOhgInolYoRz7oKLKBqE=; b=OOZLnU5JNEM6KCZZPfCD1R7QQrVQpOgxSzQpntEKhRIiluZTKdu1G/IhZnLlrh167K msIjp03HMAtUxoUZi0VC0EbnfuVOCm8/ot1Br0ZuMLcttwaAB11wSAwkRgdio7g2htdi fO6GU9H4pTtokpHPkv3GpQ9iFoCaJI8EPwUmYtd1bsoXqPGA8YvFpIblxOahCz7RYZZE 6P0x2Jde2SQAeEUSbZK33YhtyNQV6SmdeIL5piuGhdGvKN+CF8Pl+uHJxpxLL60/WgBC ODqYzX4RgUo95ysTzoIQEBWc9Ld7It0ACXxS4wJHbhs4wFSn0waZ2yhSVU/2L9plZp0d BC5w== X-Forwarded-Encrypted: i=1; AJvYcCWupmbUZ8dcYBeSjjknaOfMG++OziEocCyRgjGo8L6KTQWjG40o+g+34g35gOoBPTaaTATVZiZAsSbIR/tXDmGmB0VZIndw4UTAS2ePi3E= X-Gm-Message-State: AOJu0Yz1pMUCYV5WmPWHBOV7EzinH2SmLalTboj7NDwxFwPLJc7WWoCE tK5fXl46G/zVUOKGYQUdHk7O3ZSbQl6BO2wcE1TO7KMIA+99uMqzoBEoyjpSng== X-Google-Smtp-Source: AGHT+IHF7CR9TPeZenlhRyg9jAdD1UVkXbjx0RMMgXIqaeTJT8V47cHhjX+Oajq8Viub2w2bFb+DBA== X-Received: by 2002:a17:907:c78f:b0:a44:e34a:792f with SMTP id tz15-20020a170907c78f00b00a44e34a792fmr5677425ejc.15.1710176869382; Mon, 11 Mar 2024 10:07:49 -0700 (PDT) Message-ID: <1cb8bca3-58b6-4a8d-ac46-8338ea5807e7@suse.com> Date: Mon, 11 Mar 2024 18:07:48 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 5/5] xen/memory, tools: Make init-dom0less consume XEN_DOMCTL_get_mem_map Content-Language: en-US To: Henry Wang Cc: Wei Liu , Anthony PERARD , Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Alec Kwapis , xen-devel@lists.xenproject.org References: <20240308015435.4044339-1-xin.wang2@amd.com> <20240308015435.4044339-6-xin.wang2@amd.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20240308015435.4044339-6-xin.wang2@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit I'm afraid the title doesn't really say what the patch actually means to achieve. On 08.03.2024 02:54, Henry Wang wrote: > Previous commits enable the toolstack to get the domain memory map, > therefore instead of hardcoding the guest magic pages region, use > the XEN_DOMCTL_get_mem_map domctl to get the start address of the > guest magic pages region. Add the (XEN)MEMF_force_heap_alloc memory > flags to force populate_physmap() to allocate page from domheap > instead of using 1:1 or static allocated pages to map the magic pages. A patch description wants to be (largely) self-contained. "Previous commits" shouldn't be mentioned; recall that the sequence in which patches go in is unknown to you up front. (In fact the terms "commit" or "patch" should be avoided altogether when describing what a patch does. The only valid use I can think of is when referring to commits already in the tree, and then typically by quoting their hash and title.) > --- a/xen/include/public/memory.h > +++ b/xen/include/public/memory.h > @@ -41,6 +41,11 @@ > #define XENMEMF_exact_node(n) (XENMEMF_node(n) | XENMEMF_exact_node_request) > /* Flag to indicate the node specified is virtual node */ > #define XENMEMF_vnode (1<<18) > +/* > + * Flag to force populate physmap to use pages from domheap instead of 1:1 > + * or static allocation. > + */ > +#define XENMEMF_force_heap_alloc (1<<19) > #endif If this is for populate_physmap only, then other sub-ops need to reject its use. I have to admit I'm a little wary of allocating another flag here and ... > --- a/xen/include/xen/mm.h > +++ b/xen/include/xen/mm.h > @@ -205,6 +205,8 @@ struct npfec { > #define MEMF_no_icache_flush (1U<<_MEMF_no_icache_flush) > #define _MEMF_no_scrub 8 > #define MEMF_no_scrub (1U<<_MEMF_no_scrub) > +#define _MEMF_force_heap_alloc 9 > +#define MEMF_force_heap_alloc (1U<<_MEMF_force_heap_alloc) > #define _MEMF_node 16 > #define MEMF_node_mask ((1U << (8 * sizeof(nodeid_t))) - 1) > #define MEMF_node(n) ((((n) + 1) & MEMF_node_mask) << _MEMF_node) ... here - we don't have that many left. Since other sub-ops aren't intended to support this flag, did you consider adding another (perhaps even arch-specific) sub-op instead? Jan From xen-devel-bounces@lists.xenproject.org Mon Mar 11 17:11:51 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 17:11:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691555.1077631 (Exim 4.92) (envelope-from ) id 1rjjBk-0004IX-Iz; Mon, 11 Mar 2024 17:11:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691555.1077631; Mon, 11 Mar 2024 17:11:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjjBk-0004IQ-G4; Mon, 11 Mar 2024 17:11:48 +0000 Received: by outflank-mailman (input) for mailman id 691555; Mon, 11 Mar 2024 17:11:47 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjjBj-0004I7-DQ for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 17:11:47 +0000 Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [2a00:1450:4864:20::432]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 70e6da1d-dfca-11ee-afdc-a90da7624cb6; Mon, 11 Mar 2024 18:11:46 +0100 (CET) Received: by mail-wr1-x432.google.com with SMTP id ffacd0b85a97d-33e285a33bdso2653041f8f.2 for ; Mon, 11 Mar 2024 10:11:46 -0700 (PDT) Received: from perard.uk.xensource.com (default-46-102-197-194.interdsl.co.uk. [46.102.197.194]) by smtp.gmail.com with ESMTPSA id bk15-20020a0560001d8f00b0033e3ce48ba1sm6929218wrb.16.2024.03.11.10.11.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 Mar 2024 10:11:45 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 70e6da1d-dfca-11ee-afdc-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1710177106; x=1710781906; darn=lists.xenproject.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=TbfT0KcT1M6xxN772/YoxmHDMjLUtwQdO+VOpR+uOQY=; b=G5UfIIAc9YaqISUu6Oe2ft+QDQDlm7kPix7uJRTwCKwVsQhdWHu1oPzFFi0w2/7yTk kc4rgVERQzXCPR8dBTnqj0E/ZbBTN8Y7X6mqKdsrDxG1Qnvw8bScluZV/hMEnuubatsj XxRaQyic60vVEjhYeOFr7LfVcrtlBx9BWGlaM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710177106; x=1710781906; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=TbfT0KcT1M6xxN772/YoxmHDMjLUtwQdO+VOpR+uOQY=; b=XHQTeOGBvEd0icDLBEfvagk1ADgEU+xtTunuFiKktCno3PiPBXldozSjU6/w7hJJbo lnzXlgn6/aOLfBEUUSwCQA+CfhQfiK2kbEi2tVaYSVQb+edvaCe4KRoiveULDm+R4Sku 0pvak+eDBbBaeYwJKT1tBoCxd+P1rHCT8dAiyhk7act6/DrIwkwo2Y/0FFJUCXSNwnqF jgtsy+NECVJsixPTONNg5Sbcd4/Kz+8I5tKWnbiljVejqrIMVqwQqDv4O09gl2pEOSF0 Dey4fuGQVr3feZVYC7+IhmYLdFjCKS4hbztmYBI4TL1FzTw5lVvAZZEDDGoqlZCsr253 DsLw== X-Gm-Message-State: AOJu0YwptMTV1B874i6mEwbRmQ3t1ER3NnrfE511yqAMiwt2VtJRayOv Qte32l9lwg7U3acjthUxO2yRy06Zq2Bi0iT4KvzPAdlHBWQ24jisx/laOaXRysV56SRIUmnAMMv D X-Google-Smtp-Source: AGHT+IETd7Qp368uuLTAl0Jzcs5nz0Nv1G/xWNsI/Px/+M3SZihuCh7KRQUhaDYMABL0/w/W8x2wNQ== X-Received: by 2002:adf:e9c7:0:b0:33d:284a:401 with SMTP id l7-20020adfe9c7000000b0033d284a0401mr4895232wrn.68.1710177105863; Mon, 11 Mar 2024 10:11:45 -0700 (PDT) Date: Mon, 11 Mar 2024 17:11:44 +0000 From: Anthony PERARD To: xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , Juergen Gross , Roger Pau Monne Subject: Re: [OSSTEST PATCH] ap-common: Switch to Linux 6.1 by default on x86 + drop dom0 i386 Message-ID: References: <20240306114741.14564-1-anthony.perard@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240306114741.14564-1-anthony.perard@citrix.com> On Wed, Mar 06, 2024 at 11:47:41AM +0000, Anthony PERARD wrote: > linux-4.19 branch in xenbits is outdated, it haven't been updated and > tested since 2020 as it has been disabled in osstest. Also, this 4.19 > branch doesn't build on Bookworm. > > So we will start to use a newer version of Linux. We switch to 6.1 for > the Arm* tests recently, so will use that same version for x86. > > Also, following commit 3a3089c94913 ("mfi-common: Drop Linux dom0 i386 > tests for newer Linux branches"), 32bit dom0 isn't tested on newer > Linux, so we need to drop all dom0 i386 tests wherever the default > linux branch is used. That is, this changes in jobs will apply to > "xen-unstable" branch but also all xen stable branches, seabios, qemu, > osstest, libvirt, so every branch that aren't "linux-*". > [...] > > In any case, the list of test would be the same as for the existing > branch "linux-linus" or "linux-6.1" branches. > > Signed-off-by: Anthony PERARD There hasn't been comment on this change, so I guess everyone is happy for this change to go in. :-) I'll push it later this week. Thanks, -- Anthony PERARD From xen-devel-bounces@lists.xenproject.org Mon Mar 11 17:28:08 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 17:28:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691561.1077641 (Exim 4.92) (envelope-from ) id 1rjjRQ-0006Qi-VI; Mon, 11 Mar 2024 17:28:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691561.1077641; Mon, 11 Mar 2024 17:28:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjjRQ-0006Qb-RQ; Mon, 11 Mar 2024 17:28:00 +0000 Received: by outflank-mailman (input) for mailman id 691561; Mon, 11 Mar 2024 17:27:59 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjjRP-0006QV-Rf for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 17:27:59 +0000 Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [2607:f8b0:4864:20::22d]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id b3c32fa8-dfcc-11ee-afdc-a90da7624cb6; Mon, 11 Mar 2024 18:27:58 +0100 (CET) Received: by mail-oi1-x22d.google.com with SMTP id 5614622812f47-3c1ea5b42e7so1942749b6e.2 for ; Mon, 11 Mar 2024 10:27:58 -0700 (PDT) Received: from localhost ([213.195.118.74]) by smtp.gmail.com with ESMTPSA id vv14-20020a05620a562e00b00788662eda89sm1837700qkn.15.2024.03.11.10.27.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 Mar 2024 10:27:55 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b3c32fa8-dfcc-11ee-afdc-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1710178077; x=1710782877; darn=lists.xenproject.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=N65cQcdg6uyPizXZCPwzdDvQhh5w9InmBIs0WXwkfl0=; b=vF2TeGruIMGKPcsjLFKKYxxcpTOaDWpOBGpcThEuM9jmu2Q+17YayV729oS6Wde/Ua zHxtuccIskShqD6uJYBNXRX+BcR7ozhFLIY8FhCpavWlcL9nhrfY5bdXsfeICytm01hL kyG9O2Jf1vnEvTDE2nUt2owrYrfHgAs8yxl8c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710178077; x=1710782877; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=N65cQcdg6uyPizXZCPwzdDvQhh5w9InmBIs0WXwkfl0=; b=Z/BKPLYwpWLu/oQCgEuJSmQZT8IliAzpiwzAqU2sYaNvnTn9WKC67L+OG36gNdFtLS yQUvIbt+8OB+qRuxom9WnErPi0Rq7WTO8fKnrIPag3VIclAe5CWOuwTxndrVlS/WnVdW 2wjTXEmd7V7oWHWkiyBSSlCb+DzaA10r4iEXXJIP+481Pys6wxhYkK0syHah9lzEfQSX uja08+WH25FHULsW3+QR+vn6l6Rp/N+eDHYq0z8HqOWV1FE25GfQiqS6UB84KjwA22VM nayR7gEqzd5tADXBGFwY6VJdchGJSJBlco+O0ZBIDHmRkjTkjinLzKGimw9hoSA0xpqK Fg5g== X-Gm-Message-State: AOJu0YywHSIavH/X0To57aDUBEl6vREpnlfZ3vLlHsFs5KRD7UIZ7+GN f63TXwG8xrR3kBImdVcpjqxXVW1ZbNB/DmPk5jqaQMADD3aL32cAR82auumcP/I= X-Google-Smtp-Source: AGHT+IHG6xMGHzeyv9S/JYSx4dG33eg2aA2qHBQ42wtSwJB9YbqyMgvv6WO8VWFbdiYRCG6BfrTI3g== X-Received: by 2002:a05:6870:f14a:b0:220:daa3:4800 with SMTP id l10-20020a056870f14a00b00220daa34800mr8499941oac.40.1710178077192; Mon, 11 Mar 2024 10:27:57 -0700 (PDT) Date: Mon, 11 Mar 2024 18:27:52 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Anthony PERARD Cc: xen-devel@lists.xenproject.org, Jan Beulich , Andrew Cooper , Juergen Gross Subject: Re: [OSSTEST PATCH] ap-common: Switch to Linux 6.1 by default on x86 + drop dom0 i386 Message-ID: References: <20240306114741.14564-1-anthony.perard@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20240306114741.14564-1-anthony.perard@citrix.com> On Wed, Mar 06, 2024 at 11:47:41AM +0000, Anthony PERARD wrote: > linux-4.19 branch in xenbits is outdated, it haven't been updated and > tested since 2020 as it has been disabled in osstest. Also, this 4.19 > branch doesn't build on Bookworm. > > So we will start to use a newer version of Linux. We switch to 6.1 for > the Arm* tests recently, so will use that same version for x86. > > Also, following commit 3a3089c94913 ("mfi-common: Drop Linux dom0 i386 > tests for newer Linux branches"), 32bit dom0 isn't tested on newer > Linux, so we need to drop all dom0 i386 tests wherever the default > linux branch is used. That is, this changes in jobs will apply to > "xen-unstable" branch but also all xen stable branches, seabios, qemu, > osstest, libvirt, so every branch that aren't "linux-*". > > Here is the list jobs that changes, and whether they are replace, or > have existing equivalents, on the "xen-unstable" branch. Changes > compared with: > OSSTEST_CONFIG=standalone-config-example nice eatmydata ./standalone-generate-dump-flight-runvars > > Gone, without exiting or new test-amd64-amd64-*: > - test-amd64-i386-freebsd10-amd64 > - test-amd64-i386-freebsd10-i386 I should have removed those long time ago, as FreeBSD has been EOL for ages. > - test-amd64-i386-qemut-rhel6hvm-amd > - test-amd64-i386-qemut-rhel6hvm-intel > - test-amd64-i386-qemuu-rhel6hvm-amd > - test-amd64-i386-qemuu-rhel6hvm-intel > > Gone, but with exiting test-amd64-amd64-* equivalent: > - test-amd64-coresched-i386-xl > - test-amd64-i386-examine > - test-amd64-i386-examine-bios > - test-amd64-i386-examine-uefi > - test-amd64-i386-libvirt > - test-amd64-i386-libvirt-pair > - test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm > - test-amd64-i386-libvirt-xsm > - test-amd64-i386-livepatch > - test-amd64-i386-migrupgrade > - test-amd64-i386-pair > - test-amd64-i386-xl > - test-amd64-i386-xl-pvshim > - test-amd64-i386-xl-qemut-debianhvm-amd64 > - test-amd64-i386-xl-qemut-debianhvm-i386-xsm > - test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm > - test-amd64-i386-xl-qemut-win7-amd64 > - test-amd64-i386-xl-qemut-ws16-amd64 > - test-amd64-i386-xl-qemuu-debianhvm-amd64 > - test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow > - test-amd64-i386-xl-qemuu-debianhvm-i386-xsm > - test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict > - test-amd64-i386-xl-qemuu-ovmf-amd64 > - test-amd64-i386-xl-qemuu-win7-amd64 > - test-amd64-i386-xl-qemuu-ws16-amd64 > - test-amd64-i386-xl-shadow > - test-amd64-i386-xl-simplat-amd64-buster > - test-amd64-i386-xl-xsm > > Gone, but replaced by a new test-amd64-amd64-*: > - test-amd64-i386-libvirt-raw > - test-amd64-i386-xl-vhd > > Some test-amd64-amd64-* are also changed: > - test-amd64-amd64-libvirt-vhd > - test-amd64-amd64-qemuu-freebsd11-amd64 > - test-amd64-amd64-qemuu-freebsd12-amd64 > - test-amd64-amd64-xl-qcow2 > + test-amd64-amd64-freebsd11-amd64 > + test-amd64-amd64-freebsd12-amd64 > + test-amd64-amd64-libvirt-qcow2 > + test-amd64-amd64-libvirt-raw > + test-amd64-amd64-xl-vhd Is this purely a name change, or there's some kind of functional change? I'm mostly worried whether this could lead to regressions getting in as osstest would detect those jobs as new instead of inheriting from the previous jobs. Also the "History for test ..." won't link to jobs prior to the rename? I guess I'm confused about what causes the qemuu to be dropped from the job names above. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Mon Mar 11 17:38:12 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 17:38:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691564.1077651 (Exim 4.92) (envelope-from ) id 1rjjbD-0008P8-Rs; Mon, 11 Mar 2024 17:38:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691564.1077651; Mon, 11 Mar 2024 17:38:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjjbD-0008P1-OB; Mon, 11 Mar 2024 17:38:07 +0000 Received: by outflank-mailman (input) for mailman id 691564; Mon, 11 Mar 2024 17:38:06 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjjbC-0008Oq-Gu; Mon, 11 Mar 2024 17:38:06 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjjbC-0001kM-D4; Mon, 11 Mar 2024 17:38:06 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjjbB-000443-WD; Mon, 11 Mar 2024 17:38:06 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rjjbB-0003Ga-Va; Mon, 11 Mar 2024 17:38:05 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=uILmACtTcDlfAOVDIGUWMtnsiAwQs8ZDrpPS+UzdGl4=; b=FmUD74pkYq/aj/k9ylgYTU/SJQ nkdm/qO0kVuyeeRUDA339ci+4mQe5wkgGFQUEUXn2dLJwNLcRcvfvD81BhN/s2/2p647mFsDywgr9 em5FZLS5xEtNsS+jT6Dqk5AMtHR6V8f/DZnug/vXQp2UGYF8azdFLuGHVKNcykVmZUp8=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable test] 184992: regressions - FAIL X-Osstest-Failures: xen-unstable:test-amd64-amd64-livepatch:livepatch-run:fail:regression xen-unstable:test-amd64-i386-livepatch:livepatch-run:fail:regression xen-unstable:test-amd64-amd64-xl-credit1:guest-localmigrate/x10:fail:heisenbug xen-unstable:test-amd64-i386-xl-qemut-debianhvm-i386-xsm:debian-hvm-install:fail:heisenbug xen-unstable:test-amd64-amd64-xl-qemut-debianhvm-i386-xsm:debian-hvm-install:fail:heisenbug xen-unstable:test-amd64-amd64-xl-qemut-debianhvm-amd64:guest-localmigrate/x10:fail:heisenbug xen-unstable:test-amd64-amd64-xl-xsm:guest-localmigrate:fail:heisenbug xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:windows-install:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: xen=ef31ffbc3dc124173fc9420988772fa96bc4bf12 X-Osstest-Versions-That: xen=66c8e9b76c61ff52cfc0b186a38208907845d093 From: osstest service owner Date: Mon, 11 Mar 2024 17:38:05 +0000 flight 184992 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/184992/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-livepatch 13 livepatch-run fail REGR. vs. 184927 test-amd64-i386-livepatch 13 livepatch-run fail REGR. vs. 184927 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-credit1 20 guest-localmigrate/x10 fail in 184986 pass in 184992 test-amd64-i386-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail in 184989 pass in 184992 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail in 184989 pass in 184992 test-amd64-amd64-xl-qemut-debianhvm-amd64 18 guest-localmigrate/x10 fail pass in 184986 test-amd64-amd64-xl-xsm 18 guest-localmigrate fail pass in 184989 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop fail in 184989 blocked in 184927 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop fail like 184927 test-armhf-armhf-libvirt 16 saverestore-support-check fail like 184927 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 184927 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop fail like 184927 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 184927 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 184927 test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail like 184927 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop fail like 184927 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 184927 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 184927 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184927 test-amd64-amd64-xl-qemuu-win7-amd64 12 windows-install fail like 184927 test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-amd64-i386-xl-pvshim 14 guest-start fail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-check fail never pass test-amd64-i386-libvirt 15 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-check fail never pass test-arm64-arm64-xl 15 migrate-support-check fail never pass test-arm64-arm64-xl 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 15 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-check fail never pass test-armhf-armhf-libvirt 15 migrate-support-check fail never pass test-amd64-i386-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-check fail never pass test-arm64-arm64-xl-vhd 14 migrate-support-check fail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-check fail never pass version targeted for testing: xen ef31ffbc3dc124173fc9420988772fa96bc4bf12 baseline version: xen 66c8e9b76c61ff52cfc0b186a38208907845d093 Last test of basis 184927 2024-03-07 00:10:52 Z 4 days Failing since 184940 2024-03-07 19:47:48 Z 3 days 7 attempts Testing same since 184974 2024-03-09 08:14:48 Z 2 days 5 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Anthony PERARD Federico Serafini Henry Wang Jan Beulich Juergen Gross Oleksii Kurochko jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm fail test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-dom0pvh-xl-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 fail test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-qemuu-freebsd11-amd64 pass test-amd64-amd64-qemuu-freebsd12-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-examine-bios pass test-amd64-i386-examine-bios pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-dom0pvh-xl-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch fail test-amd64-i386-livepatch fail test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-armhf-armhf-libvirt-qcow2 pass test-amd64-amd64-xl-qcow2 pass test-arm64-arm64-libvirt-raw pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-libvirt-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-examine-uefi pass test-amd64-i386-examine-uefi pass test-amd64-amd64-libvirt-vhd pass test-arm64-arm64-xl-vhd pass test-armhf-armhf-xl-vhd pass test-amd64-i386-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these 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 ef31ffbc3dc124173fc9420988772fa96bc4bf12 Author: Federico Serafini Date: Mon Mar 4 11:28:37 2024 +0100 automation/eclair: add deviation for MISRA C:2012 Rule 16.6 Update ECLAIR configuration to take into account the deviations agreed during MISRA meetings. Signed-off-by: Federico Serafini Reviewed-by: Stefano Stabellini commit 90173fc5a2a826bbcabde22af405d0a617818b70 Author: Henry Wang Date: Thu Mar 7 21:56:16 2024 +0800 tools/9pfsd: Fix build error caused by strerror_r Below error can be seen when doing Yocto build of the toolstack: | io.c: In function 'p9_error': | io.c:684:5: error: ignoring return value of 'strerror_r' declared with attribute 'warn_unused_result' [-Werror=unused-result] | 684 | strerror_r(err, ring->buffer, ring->ring_size); | | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | cc1: all warnings being treated as errors Using strerror_r() without special casing different build environments is impossible due to the different return types (int vs char *) depending on the environment. As p9_error() is not on a performance critical path, using strerror() with a mutex ought to be fine. So, fix the build by using strerror() to replace strerror_r(). The steps would then become: Acquire the mutex first, invoke strerror(), copy the string from strerror() to the designated buffer and then drop the mutex. Fixes: f4900d6d69b5 ("9pfsd: allow building with old glibc") Signed-off-by: Henry Wang Reviewed-by: Jan Beulich Reviewed-by: Juergen Gross Acked-by: Anthony PERARD commit b52c45b1bdf04469495dd046ba15dd35a8becfa5 Author: Juergen Gross Date: Wed Mar 6 12:16:31 2024 +0100 MAINTAINERS: add an entry for tools/9pfsd Add me as the maintainer for the tools/9pfsd directory. Signed-off-by: Juergen Gross Reviewed-by: Andrew Cooper commit b083b1c393dc8961acf0959b1d2e0ad459985ae3 Author: Andrew Cooper Date: Tue Mar 5 11:39:19 2024 +0000 x86/livepatch: Relax permissions on rodata too This reinstates the capability to patch .rodata in load/unload hooks, which was lost when we stopped using CR0.WP=0 to patch. This turns out to be rather less of a large TODO than I thought at the time. Fixes: 8676092a0f16 ("x86/livepatch: Fix livepatch application when CET is active") Signed-off-by: Andrew Cooper Reviewed-by: Roger Pau Monné Reviewed-by: Ross Lagerwall commit ef969144a425e39f5b214a875b5713d0ea8575fb Author: Andrew Cooper Date: Tue Mar 5 11:35:12 2024 +0000 xen/virtual-region: Include rodata pointers These are optional. .init doesn't distinguish types of data like this, and livepatches don't necesserily have any .rodata either. No functional change. Signed-off-by: Andrew Cooper Reviewed-by: Roger Pau Monné Reviewed-by: Ross Lagerwall commit 989556c6f8ca080f5f202417af97d1188b9ba52a Author: Andrew Cooper Date: Tue Mar 5 11:28:33 2024 +0000 xen/virtual-region: Rename the start/end fields ... to text_{start,end}. We're about to introduce another start/end pair. Despite it's name, struct virtual_region has always been a module-ish description. Call this out specifically. As minor cleanup, replace ROUNDUP(x, PAGE_SIZE) with the more concise PAGE_ALIGN() ahead of duplicating the example. No functional change. Signed-off-by: Andrew Cooper Reviewed-by: Roger Pau Monné Reviewed-by: Ross Lagerwall commit 08bb338f09a54d3b39f0d952bbd67461d8e5d0ed Author: Juergen Gross Date: Thu Mar 7 09:18:04 2024 +0100 SUPPORT.md: add xen-9pfsd Add a support statement for the new xen-9pfsd backend. Set it to "Experimental", as some functionality for Linux guests is missing (only tested to work with Xenstore-stubdom). Signed-off-by: Juergen Gross Acked-by: Jan Beulich commit 49b664f5bffa3a86734c66491d7dcdebbdecfb26 Author: Jan Beulich Date: Thu Mar 7 09:17:26 2024 +0100 x86/asm: add commas to further macros definitions/invocations In light of recent observations with how macros are handled by gas, let's play by what we informally set for ourselves as a guideline: Use commas to separate parameters/arguments. Requested-by: Andrew Cooper Signed-off-by: Jan Beulich Acked-by: Andrew Cooper commit 4ad4df0964aa374562fa574d4671d278f54f5d32 Author: Juergen Gross Date: Thu Mar 7 09:16:53 2024 +0100 CHANGELOG: add an entry for 9pfsd Add an entry to CHANGELOG.md regarding the new xen-9pfsd daemon. Signed-off-by: Juergen Gross Acked-by: Oleksii Kurochko commit 9249a441c98ff063c0c065538b419a3bf1dac24a Author: Jan Beulich Date: Thu Mar 7 09:16:13 2024 +0100 x86/asm: add commas to BUILD_BUG_ON In light of recent observations with how macros are handled by gas, let's play by what we informally set for ourselves as a guideline: Use commas to separate parameters/arguments. Signed-off-by: Jan Beulich Acked-by: Andrew Cooper commit 5daf46b439454921c19ca30840bb39424b36444b Author: Jan Beulich Date: Thu Mar 7 09:15:17 2024 +0100 Kbuild: simplify as-insn a little As of 732571959f17 ("xen/build: use new $(c_flags) and $(a_flags) instead of $(CFLAGS)") -M options aren't part of CFLAGS anymore, and c_flags isn't supposed to be passed to this macro. Drop the now dead part of filtering. Signed-off-by: Jan Beulich Reviewed-by: Anthony PERARD commit 2f7481d59255680c1de98f43467d3862453dd50a Author: Jan Beulich Date: Thu Mar 7 09:14:55 2024 +0100 x86/EFI: correct compiler probing Passing in $(CFLAGS) means also requesting inclusion of certain headers (via -include command line options). That's particularly xen/config.h, which in turn requires generated/autoconf.h. This has not caused any problems so far only because arch.mk is processed twice, and the missing header on the 1st pass would be there on the 2nd. Having added an inclusion of asm/asm-macros.h to x86'es asm/config.h, the 2nd pass then also fails on an initial, pristine build. As per dd40177c1bc8 ("x86-64/EFI: add CFLAGS to check compile") dropping the use of $(CFLAGS) altogether isn't an option, though. Hence remove the problematic options only. Signed-off-by: Jan Beulich Reviewed-by: Anthony PERARD (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Mon Mar 11 18:02:59 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 18:02:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691570.1077661 (Exim 4.92) (envelope-from ) id 1rjjz1-0006qn-S4; Mon, 11 Mar 2024 18:02:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691570.1077661; Mon, 11 Mar 2024 18:02:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjjz1-0006qd-PH; Mon, 11 Mar 2024 18:02:43 +0000 Received: by outflank-mailman (input) for mailman id 691570; Mon, 11 Mar 2024 18:02:42 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjjyz-0006pG-V8 for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 18:02:41 +0000 Received: from raptorengineering.com (mail.raptorengineering.com [23.155.224.40]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 8b9242a1-dfd1-11ee-afdc-a90da7624cb6; Mon, 11 Mar 2024 19:02:39 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.rptsys.com (Postfix) with ESMTP id 14222828555B; Mon, 11 Mar 2024 13:02:37 -0500 (CDT) Received: from mail.rptsys.com ([127.0.0.1]) by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id XCY9OihA2phG; Mon, 11 Mar 2024 13:02:35 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by mail.rptsys.com (Postfix) with ESMTP id 90A9B82857FB; Mon, 11 Mar 2024 13:02:35 -0500 (CDT) Received: from mail.rptsys.com ([127.0.0.1]) by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id gAJ6IiuuItoI; Mon, 11 Mar 2024 13:02:35 -0500 (CDT) Received: from [10.11.0.3] (5.edge.rptsys.com [23.155.224.38]) by mail.rptsys.com (Postfix) with ESMTPSA id A2F7D828555B; Mon, 11 Mar 2024 13:02:34 -0500 (CDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8b9242a1-dfd1-11ee-afdc-a90da7624cb6 DKIM-Filter: OpenDKIM Filter v2.10.3 mail.rptsys.com 90A9B82857FB DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raptorengineering.com; s=B8E824E6-0BE2-11E6-931D-288C65937AAD; t=1710180155; bh=dra6heGfKnsJ4Y78kpmM0pD+JnxX6oVuc9Jy0sTLO5I=; h=Message-ID:Date:MIME-Version:To:From; b=jRqWqZiUjaPLbzJfGTDrSc83S3aIHOF5L9W+5AAKqwunrFO5roB1MsEDHu1n8oyN1 WGtZlJXgYma7uKB/j6YvOM8ICJuMkprIiVSDW+JRktO/GpmD1wN1sExVSXuKlh3Jhi wWtbr5WhvIAOt+6l7E+GpnAyxJilpyr3m5cdJxYM= X-Virus-Scanned: amavisd-new at rptsys.com Message-ID: Date: Mon, 11 Mar 2024 13:02:33 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/5] xen/domain.h: Centrialize is_domain_direct_mapped() Content-Language: en-US To: Henry Wang , xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , George Dunlap , Jan Beulich , Wei Liu , Alistair Francis , Bob Eshleman , Connor Davis , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <20240308015435.4044339-1-xin.wang2@amd.com> <20240308015435.4044339-3-xin.wang2@amd.com> From: Shawn Anastasio In-Reply-To: <20240308015435.4044339-3-xin.wang2@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Henry, On 3/7/24 7:54 PM, Henry Wang wrote: > Currently direct mapped domain is only supported by the Arm > architecture at the domain creation time by setting the CDF_directmap > flag. There is not a need for every non-Arm architecture, i.e. x86, > RISC-V and PPC, to define a stub is_domain_direct_mapped() in arch > header. > > Move is_domain_direct_mapped() to a centralized place at xen/domain.h > and evaluate CDF_directmap for non-Arm architecture to 0. > > Signed-off-by: Henry Wang Regardless of whether or not you decide to go with the centralized ifdef approach suggested by Michal, consider the PPC parts: Acked-by: Shawn Anastasio Thanks, Shawn From xen-devel-bounces@lists.xenproject.org Mon Mar 11 19:56:52 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 19:56:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691573.1077671 (Exim 4.92) (envelope-from ) id 1rjllI-000512-TW; Mon, 11 Mar 2024 19:56:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691573.1077671; Mon, 11 Mar 2024 19:56:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjllI-00050v-Pe; Mon, 11 Mar 2024 19:56:40 +0000 Received: by outflank-mailman (input) for mailman id 691573; Mon, 11 Mar 2024 19:56:39 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjllH-00050p-Oz for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 19:56:39 +0000 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on20601.outbound.protection.outlook.com [2a01:111:f403:2415::601]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 774e8871-dfe1-11ee-a1ee-f123f15fe8a2; Mon, 11 Mar 2024 20:56:36 +0100 (CET) Received: from CY5PR19CA0070.namprd19.prod.outlook.com (2603:10b6:930:69::16) by SN7PR12MB8145.namprd12.prod.outlook.com (2603:10b6:806:350::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.36; Mon, 11 Mar 2024 19:56:33 +0000 Received: from CY4PEPF0000E9CF.namprd03.prod.outlook.com (2603:10b6:930:69:cafe::7d) by CY5PR19CA0070.outlook.office365.com (2603:10b6:930:69::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.35 via Frontend Transport; Mon, 11 Mar 2024 19:56:33 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by CY4PEPF0000E9CF.mail.protection.outlook.com (10.167.241.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7386.12 via Frontend Transport; Mon, 11 Mar 2024 19:56:33 +0000 Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Mon, 11 Mar 2024 14:56:32 -0500 Received: from [172.23.117.185] (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend Transport; Mon, 11 Mar 2024 14:56:31 -0500 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 774e8871-dfe1-11ee-a1ee-f123f15fe8a2 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=X5YLKXXJgzq8eVc+6P5XhmaOjbNzuCx9Gnkk1R4xkockCTrLVFyzsMPfluk33V7QSDSG5SEeJUUc94D847F+7xM1i53WnKSY4AngmSHM/nsvQ7X0h8JUcz+Vvb7sVvLeIrhdXy6zTczK2U8VYoF35B0OfhZZb7GKt09umxJT8gaaARYVF8QbXURDXhYO4ySQtGOLvzihooJrcM3hCmgv4DUFZXWVh6OVkDh3Nut0u6jw5s/Ev7/s8do9N0m4RKHD/1xVylKHS3eg9qy9TXmFj0wGKerhCStVAZ/FL1TFPehrHf3ecc8mKS/l3aPs1+JLjm0xw1gflg1U+KjELJ4LQw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=qdYnE55Z87IcnBbV1pH3qAtX8YOar8cnwFQFfFPfbBg=; b=OTqM98NpLqSCRlxJIj3fJjEK43LTDmfGjxC25FQZe8xosIOmgcSbEyEEZRuAqJkRhhuaeZH8JkWIc3CbXRyn/7/QQyMhARJ14ljrUhtbmY1NhsGHXAXf3Mf2QyhQCankkzW5HzKQbxFeRo6eAXQR4CJzb435M5yV5Cqs8a9bzqV+pLRvedgZYMeGoe55bSyYeE+TE848kdIb+1JDMG5NTlKNZMqukK1G1/YhuFEpMBn0L61LyIZ16YX2VDCo/KoEfyjG+8KWQ9XBulCZksDQQPoZJjvHI7FQ6pRXmeXdtTtfDJMgBbfHZhMIPLLlzB1YtysIgLPQFztND+sG+JUrkQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qdYnE55Z87IcnBbV1pH3qAtX8YOar8cnwFQFfFPfbBg=; b=mBPRNT0Dx4Z2BXglcyHW7Kg64tdBtp1gEipl1r+dBo/ZAIJB3EV+RqYq0laC5WZRNZ/RChaU2x6p56zqHheGziy+tdyZPTze4YWFVlKLGzstAD6QqwRg0WWE7ANElzvm2FJKH+fwuuYyQpM0j0C4Q/MtBeYFmoHAWW/NnI2AVhI= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C Message-ID: <61700ba8-fb15-4862-a12e-2d236ae4ef6b@amd.com> Date: Mon, 11 Mar 2024 15:53:24 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 3/3] x86/PVH: Support relocatable dom0 kernels Content-Language: en-US To: Jan Beulich CC: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu , George Dunlap , Julien Grall , Stefano Stabellini , References: <20240306185032.103216-1-jason.andryuk@amd.com> <20240306185032.103216-4-jason.andryuk@amd.com> <5b4054c0-a5ab-4fc0-9754-8253b12c849d@suse.com> From: Jason Andryuk In-Reply-To: <5b4054c0-a5ab-4fc0-9754-8253b12c849d@suse.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: None (SATLEXMB04.amd.com: jason.andryuk@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CY4PEPF0000E9CF:EE_|SN7PR12MB8145:EE_ X-MS-Office365-Filtering-Correlation-Id: 932aca1d-2ff6-4b20-ff01-08dc42055a2c X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: MFUl3t9IH+TRECaUM4lXpPeO4jGMhruIa7jl5kqww2Uu/2+tQYcvHEmngNVdrIxNNRuZm3vbyGedFW7Z2JzFBq5C8H3kJrbtpKdDb9qFQLXMoGIAIoqQA7hz3nmZp9P7QyAyycajjUGan5vfoYjsdeAVXDa3oIl6E8/svjpocDpim1xQNRQyW39/yB/oPGGNdwur27ENuKIh5S/uhbbcwOEvi7HuiyM54/vZVP3/Jl+N6QXPIlaFJzvthQoBiDaiAMtJ5xpfDoovOVSXbluQhMHoV9LVrNItEAfqVSd6WJ9lF9jQ8XyhHjh1WRasCOWcsU9N7mZwjuhG6us/Ebn3NdYsGmXNUYhfOsBfm/+/V9GaTadRLX7sdheQ80esVlAM707RDaDmbm30aUJ0bWKJKzJU+6WsRSiEg9LRxsADGzPSbB2Su/MUZg4bFYTg3s9U5uul9USCZLtuj/NKV6pPTS384Eo4KY3eVNu/ujAb0U9Oj/TlCEE5CpoxmKmT04lOG1chvpx8L4AqhDeSM01zwd6Zwnvb7FQH85d2z1jiTXrN4g0Cuzo9Bp16dbr1QBDhtQ6nEzQTDRAkyOXZqkNobNa9+fN4queGJXvYAS/b/nvDNQMZ2Yi7XOLQ2+w5DHPd1d24lwfHdXJlFDs50cvl9cUoe4CYNHIrXq2EH3wpet1b35kpH2d01n9xkovE35KReRfvDIqni6N6PgnDEI8m2yvViOEYxUK/KiBwoicKNB28fFNM39njK+Fp915SsmY6 X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(36860700004)(82310400014)(376005)(1800799015);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Mar 2024 19:56:33.3998 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 932aca1d-2ff6-4b20-ff01-08dc42055a2c X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CY4PEPF0000E9CF.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB8145 On 2024-03-11 12:53, Jan Beulich wrote: > On 06.03.2024 19:50, Jason Andryuk wrote: >> --- a/xen/arch/x86/hvm/dom0_build.c >> +++ b/xen/arch/x86/hvm/dom0_build.c >> @@ -537,6 +537,109 @@ static paddr_t __init find_memory( >> return INVALID_PADDR; >> } >> >> +static bool __init check_load_address( >> + const struct domain *d, const struct elf_binary *elf) >> +{ >> + paddr_t kernel_start = (paddr_t)elf->dest_base & PAGE_MASK; >> + paddr_t kernel_end = ROUNDUP((paddr_t)elf->dest_base + elf->dest_size, >> + PAGE_SIZE); >> + unsigned int i; >> + >> + /* >> + * The memory map is sorted and all RAM regions starts and sizes are >> + * aligned to page boundaries. >> + */ >> + for ( i = 0; i < d->arch.nr_e820; i++ ) >> + { >> + paddr_t start = d->arch.e820[i].addr; >> + paddr_t end = d->arch.e820[i].addr + d->arch.e820[i].size; >> + >> + if ( start <= kernel_start && >> + end >= kernel_end && >> + d->arch.e820[i].type == E820_RAM ) >> + return true; >> + } >> + >> + return false; >> +} >> + >> +/* >> + * Find an e820 RAM region that fits the kernel at a suitable alignment. >> + */ >> +static paddr_t find_kernel_memory( > > __init ? Yes, thanks for catching that. Regards, Jason From xen-devel-bounces@lists.xenproject.org Mon Mar 11 20:35:02 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2024 20:35:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691576.1077681 (Exim 4.92) (envelope-from ) id 1rjmMI-0001p9-Ot; Mon, 11 Mar 2024 20:34:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691576.1077681; Mon, 11 Mar 2024 20:34:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjmMI-0001p2-LD; Mon, 11 Mar 2024 20:34:54 +0000 Received: by outflank-mailman (input) for mailman id 691576; Mon, 11 Mar 2024 20:34:53 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjmMG-0001ow-SA for xen-devel@lists.xenproject.org; Mon, 11 Mar 2024 20:34:53 +0000 Received: from fout1-smtp.messagingengine.com (fout1-smtp.messagingengine.com [103.168.172.144]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id ce29361c-dfe6-11ee-afdc-a90da7624cb6; Mon, 11 Mar 2024 21:34:50 +0100 (CET) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailfout.nyi.internal (Postfix) with ESMTP id 81CDC13800E3; Mon, 11 Mar 2024 16:34:48 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Mon, 11 Mar 2024 16:34:48 -0400 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 11 Mar 2024 16:34:46 -0400 (EDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ce29361c-dfe6-11ee-afdc-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= invisiblethingslab.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:from:from:in-reply-to :message-id:mime-version:reply-to:subject:subject:to:to; s=fm1; t=1710189288; x=1710275688; bh=74vwePx3WEhU7l3h5g3gLZcoeZX9foYd q3QjMD24POI=; b=IYNsRgZMyfs9CcAFDynyjopk3xmKUTNOCVCOngFy7ToliwTN ZqSeAkl7X4+zrRlbPVn7HW5wKB8O8KRCq6fCu/hadTXPxwSqXRFZVo5t+IQoRfe9 /RC+eUJWKni0Ukx3Pc79K/R/e27QE9JzraYrgSn0Yc96KML7jDxUZiE4BDPtLtj9 HX/0j4ak2dTiTRXHDmcmWNC6+z4KWuXDEDg0s4h4XT6sb3MxrFBv4mUMzO3uvds2 YIyi/P0C1cxrWbiy+MGF9DvGnhRYXOAHFWCMTVIa/rQ6ye8uLujumqCXK7KikVIj JHY2tU9mNXSYladL2I/YRmaf2hPwQdd01CAn4w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:message-id:mime-version:reply-to:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; t=1710189288; x=1710275688; bh=74vwePx3WEhU7 l3h5g3gLZcoeZX9foYdq3QjMD24POI=; b=f7xSKMhDmdqFJMouWsnPOCVTUDcGM E2bJ3+GEkHCf43sL5GndPTuB6tEtg6ewr0ksNe8mhtPNRDbJxtJlzXumiN2QvdbB qv+GRrnW5BaWUFGqHJfUxGIa80jj29zxNuZsL4Vz3qM20K18t53aVll+1rh6zK0o rgRnA9nkdmo01BHy7Sy17R8mtGg9ry+wsdqi2CagNEKDcyGtMH1Dc83sPyXVjYHQ T68tcbXzuBI/a9GvMDSZf+fMWi0ZyNyhca/axC/RRo7II53X1YTDLFbz93/1C5ws 2ZXaSm7Z+yyaul3hBGBwDMp+2PLODs3QAvXTYbLJTdkugezr0Ie28XvbQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrjedugddufeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkofggtgfgsehtkeertdertdejnecuhfhrohhmpeforghrvghk ucforghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvh hishhisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpeelkefh udelteelleelteetveeffeetffekteetjeehlefggeekleeghefhtdehvdenucevlhhush htvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhes ihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhm X-ME-Proxy: Feedback-ID: i1568416f:Fastmail From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= To: xen-devel@lists.xenproject.org Cc: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Wei Liu , George Dunlap , Julien Grall , Stefano Stabellini Subject: [PATCH] drivers/char: mark XHCI DMA buffers reserved in memory map Date: Mon, 11 Mar 2024 21:33:11 +0100 Message-ID: <20240311203431.342530-1-marmarek@invisiblethingslab.com> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The IOMMU driver checks if RMRR/IVMD are marked as reserved in memory map. This should be true for addresses coming from the firmware, but when extra pages used by Xen itself are included in the mapping, those are taken from usable RAM used. Mark those pages as reserved too. Not marking the pages as reserved didn't caused issues before due to another a bug in IOMMU driver code, that was fixed in 83afa3135830 ("amd-vi: fix IVMD memory type checks"). Failing to reserve memory will lead to panic in IOMMU setup code. And not including the page in IOMMU mapping will lead to broken console (on due to IOMMU faults). Handling failure with panic() isn't the most user friendly thing, but at this stage the alternative would require undoing a lot of console init. Since the user can do it much easier - by simply not enabling xhci console next time, say that and panic. Fixes: 3a1a7b809ffa "drivers/char: mark DMA buffers as reserved for the XHCI" Signed-off-by: Marek Marczykowski-Górecki --- As an alternative implementation I have considered changing iommu_get_extra_reserved_device_memory() to modify memory map. But that may hide (or cause) some other issues when this API will gain some more users in the future. The reserve_e820_ram() is x86-specific. Is there some equivalent API for ARM, or maybe even some abstract one? That said, I have no way to test XHCI console on ARM, I don't know if such hardware even exists... --- xen/arch/x86/setup.c | 3 +++ xen/drivers/char/xhci-dbc.c | 22 ++++++++++++++++++++++ xen/include/xen/serial.h | 2 ++ 3 files changed, 27 insertions(+) diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c index a21984b1ccd8..8ab89b3710ed 100644 --- a/xen/arch/x86/setup.c +++ b/xen/arch/x86/setup.c @@ -1806,6 +1806,9 @@ void asmlinkage __init noreturn __start_xen(unsigned long mbi_p) mmio_ro_ranges = rangeset_new(NULL, "r/o mmio ranges", RANGESETF_prettyprint_hex); + /* Needs to happen after E820 processing but before IOMMU init */ + xhci_dbc_uart_reserve_ram(); + xsm_multiboot_init(module_map, mbi); /* diff --git a/xen/drivers/char/xhci-dbc.c b/xen/drivers/char/xhci-dbc.c index 3bf389be7d0b..e31f3cba7838 100644 --- a/xen/drivers/char/xhci-dbc.c +++ b/xen/drivers/char/xhci-dbc.c @@ -31,6 +31,9 @@ #include #include #include +#ifdef CONFIG_X86 +#include +#endif /* uncomment to have dbc_uart_dump() debug function */ /* #define DBC_DEBUG 1 */ @@ -1426,6 +1429,25 @@ void __init xhci_dbc_uart_init(void) } } +void __init xhci_dbc_uart_reserve_ram(void) +{ + struct dbc *dbc = &dbc_uart.dbc; + + if ( !dbc->enable ) + return; + +#ifdef CONFIG_X86 + if ( !reserve_e820_ram( + &e820, + virt_to_maddr(&dbc_dma_bufs), + virt_to_maddr(&dbc_dma_bufs) + sizeof(dbc_dma_bufs) - 1) ) + panic("Failed to reserve XHCI DMA buffers (%"PRIx64"-%"PRIx64"), " + "disable xhci console to work around\n", + virt_to_maddr(&dbc_dma_bufs), + virt_to_maddr(&dbc_dma_bufs) + sizeof(dbc_dma_bufs) - 1); +#endif +} + #ifdef DBC_DEBUG static void dbc_dump(struct dbc *dbc) { diff --git a/xen/include/xen/serial.h b/xen/include/xen/serial.h index 3d21207a3d7a..bb48eb8e8bd9 100644 --- a/xen/include/xen/serial.h +++ b/xen/include/xen/serial.h @@ -162,8 +162,10 @@ void ns16550_init(int index, struct ns16550_defaults *defaults); void ehci_dbgp_init(void); #ifdef CONFIG_XHCI void xhci_dbc_uart_init(void); +void xhci_dbc_uart_reserve_ram(void); #else static void inline xhci_dbc_uart_init(void) {} +static void inline xhci_dbc_uart_reserve_ram(void) {} #endif void arm_uart_init(void); -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Mar 12 01:37:12 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 01:37:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691613.1077787 (Exim 4.92) (envelope-from ) id 1rjr4d-0000JH-5z; Tue, 12 Mar 2024 01:36:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691613.1077787; Tue, 12 Mar 2024 01:36:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjr4d-0000JA-2Z; Tue, 12 Mar 2024 01:36:59 +0000 Received: by outflank-mailman (input) for mailman id 691613; Tue, 12 Mar 2024 01:36:57 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjr4b-0000If-Rp; Tue, 12 Mar 2024 01:36:57 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjr4b-0003rK-Pe; Tue, 12 Mar 2024 01:36:57 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjr4b-0000l9-4i; Tue, 12 Mar 2024 01:36:57 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rjr4b-00016u-3v; Tue, 12 Mar 2024 01:36:57 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=HptnlrHB8yXVUtmAd0s6qcKlBS80/cH+TskHtGOyk9I=; b=nbEZQf+BTwsmYudSXzONn40av+ J9lkU700aB5rBHenoizbYgggOCgGCsEy66XlcQW43L56E//vTTGOGlLizj8NO0OZPfpqM7H2qzM3J GgRdyIphSOr9MQsaY/WZM+b7RgkreO80L9n/9DsVoGJaVMmhhELxU0jHGBGu27UY7OCM=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable test] 184996: tolerable FAIL - PUSHED X-Osstest-Failures: xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: xen=7c81558208de7858251b62f168a449be84305595 X-Osstest-Versions-That: xen=66c8e9b76c61ff52cfc0b186a38208907845d093 From: osstest service owner Date: Tue, 12 Mar 2024 01:36:57 +0000 flight 184996 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/184996/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop fail blocked in 184927 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop fail like 184927 test-armhf-armhf-libvirt 16 saverestore-support-check fail like 184927 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 184927 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop fail like 184927 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 184927 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 184927 test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail like 184927 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop fail like 184927 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 184927 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 184927 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184927 test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-amd64-i386-xl-pvshim 14 guest-start fail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-check fail never pass test-amd64-i386-libvirt 15 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-check fail never pass test-arm64-arm64-xl 15 migrate-support-check fail never pass test-arm64-arm64-xl 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 15 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-check fail never pass test-armhf-armhf-libvirt 15 migrate-support-check fail never pass test-amd64-i386-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-check fail never pass test-arm64-arm64-xl-vhd 14 migrate-support-check fail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-check fail never pass version targeted for testing: xen 7c81558208de7858251b62f168a449be84305595 baseline version: xen 66c8e9b76c61ff52cfc0b186a38208907845d093 Last test of basis 184927 2024-03-07 00:10:52 Z 5 days Failing since 184940 2024-03-07 19:47:48 Z 4 days 8 attempts Testing same since 184996 2024-03-11 18:09:04 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Anthony PERARD Federico Serafini Henry Wang Jan Beulich Jason Andryuk Juergen Gross Julien Grall Kevin Tian Nicola Vetrini Oleksii Kurochko Roger Pau Monne Roger Pau Monné Shawn Anastasio Tamas K Lengyel jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-dom0pvh-xl-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-qemuu-freebsd11-amd64 pass test-amd64-amd64-qemuu-freebsd12-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-examine-bios pass test-amd64-i386-examine-bios pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-dom0pvh-xl-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-armhf-armhf-libvirt-qcow2 pass test-amd64-amd64-xl-qcow2 pass test-arm64-arm64-libvirt-raw pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-libvirt-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-examine-uefi pass test-amd64-i386-examine-uefi pass test-amd64-amd64-libvirt-vhd pass test-arm64-arm64-xl-vhd pass test-armhf-armhf-xl-vhd pass test-amd64-i386-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these 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 66c8e9b76c..7c81558208 7c81558208de7858251b62f168a449be84305595 -> master From xen-devel-bounces@lists.xenproject.org Tue Mar 12 02:33:43 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 02:33:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691621.1077805 (Exim 4.92) (envelope-from ) id 1rjrxO-0007OV-D9; Tue, 12 Mar 2024 02:33:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691621.1077805; Tue, 12 Mar 2024 02:33:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjrxO-0007OO-A7; Tue, 12 Mar 2024 02:33:34 +0000 Received: by outflank-mailman (input) for mailman id 691621; Tue, 12 Mar 2024 02:33:32 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjrxM-0007OI-Gi for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 02:33:32 +0000 Received: from wfhigh3-smtp.messagingengine.com (wfhigh3-smtp.messagingengine.com [64.147.123.154]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id e70f818f-e018-11ee-afdd-a90da7624cb6; Tue, 12 Mar 2024 03:33:29 +0100 (CET) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailfhigh.west.internal (Postfix) with ESMTP id 59DF018000B1 for ; Mon, 11 Mar 2024 22:33:24 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Mon, 11 Mar 2024 22:33:24 -0400 Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Mon, 11 Mar 2024 22:33:22 -0400 (EDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e70f818f-e018-11ee-afdd-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= invisiblethingslab.com; h=cc:content-type:content-type:date:date :from:from:in-reply-to:message-id:mime-version:reply-to:subject :subject:to:to; s=fm1; t=1710210803; x=1710297203; bh=BrpS3iRZms Wt2KXlgkMm+h/Ca4L1BiAjNrHJCHgaR+8=; b=NTZ7j3d7GwWPZvA5zCpQp0zXw4 7cxJWu5rqnfe85PVFSyHpgI51sqxR5CE7RfP7gZT2k6FwCryAlBa4jlU7f3huexS FmOLS7adrS6dpuJhP8LG7c61alqoJcDs3aI7wXdPmpbPCdE/7U3cknl0IqsOQf8M tRp9+krCOoiasDs/pOvJNRRrbo1vIiQI6NG/5q6tKFNPZ1VztLMvyEKFuED7zXI1 WH8HiIrEnEhDjRiQ5TLxdDW9vSVjhnfKoS45xKzkzdbjGYyZYs83ey45N2VhJIaF R7dTV24CjWAUSL981xIenTDbD1GNveuV4sGjBleSWrEkBZRUeNxWh6xHnXPA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:message-id :mime-version:reply-to:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1710210803; x=1710297203; bh=BrpS3iRZmsWt2KXlgkMm+h/Ca4L1BiAjNrH JCHgaR+8=; b=NvtiX3c7+sB5me222MW+63TEKBPQpMcqGZ0+W+/nzYUdQjJyyFX AImUM+QKmjWHSrEpySWDa1i0vyCKG8oLMT2dTDmfp0UpzcnuiAc84p8Hcjf0DGKY phbT8ggfn5KMqNlbGQ8gCLeS/sYv4UiVb6uYD0ylqMDrCWsVSySrbCeBLWAbSrxA c33JIegiaJecIg8TiwzdSGEAArl3mQ3yh4Ma/zELlUdpC6UuzqOeHT98DqO70y0n 2qBghQ7FibKsbyoa1vn5QIFjGkyvcgYoepUWBhnJXmy0jPd5nS6xeP63HlIdlKrQ RMnCrFkH66/TOFZ3ZW2IDUMhj2PRt5/Wafw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrjedvgdegkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfggtggusehgtderredttd ejnecuhfhrohhmpeforghrvghkucforghrtgiihihkohifshhkihdqifpkrhgvtghkihcu oehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmqeenuc ggtffrrghtthgvrhhnpeejffejudehgfegleejiedutedvudefhefgueeujeeikeehjeei fedtteethfeuvdenucffohhmrghinhepgigvnhhprhhojhgvtghtrdhorhhgnecuvehluh hsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghk sehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomh X-ME-Proxy: Feedback-ID: i1568416f:Fastmail Date: Tue, 12 Mar 2024 03:33:19 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: xen-devel Subject: 4.17.3 download is missing on the website Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5GMSWMzpDNhlgOXw" Content-Disposition: inline --5GMSWMzpDNhlgOXw Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Mar 2024 03:33:19 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: xen-devel Subject: 4.17.3 download is missing on the website Hi, https://xenproject.org/xen-project-archives/ doesn't include 4.17.3. --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab --5GMSWMzpDNhlgOXw Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmXvvvAACgkQ24/THMrX 1yzhugf+IuXpYXwZejfZ27n6Arh8BbziNGtD/PDWClZRx2J1m2WTBTStLpvtKzA6 8csSdfX9UTjlQ6NDeQQcaYiYNfxRFqMPTSmt5u7GONbcqu2HSbxpKZVtdKv92tH8 EH60L+CpHFbAlJPiLapgNuz2IupFxrgSJF80MoOjis+poMF2JZy7wLJ1U6xhI3Yg Z9fAyR3p/D3wd2B2aip8CqVD88I+lykyGDywjvi3KlooPLpZ0nTsD1wX1Kmehn7w wYMGjf3FvFbof+KO2fthtbhj5FJTiX/XAMgy7HKdEkxTzMf69sG9RU3HajB1+yiT Cts7mxETYU13YCy55AWwDyeHKsUCIg== =ie5y -----END PGP SIGNATURE----- --5GMSWMzpDNhlgOXw-- From xen-devel-bounces@lists.xenproject.org Tue Mar 12 02:41:23 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 02:41:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691624.1077815 (Exim 4.92) (envelope-from ) id 1rjs4n-0000WR-2d; Tue, 12 Mar 2024 02:41:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691624.1077815; Tue, 12 Mar 2024 02:41:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjs4n-0000WK-02; Tue, 12 Mar 2024 02:41:13 +0000 Received: by outflank-mailman (input) for mailman id 691624; Tue, 12 Mar 2024 02:41:12 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjs4l-0000WE-VT for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 02:41:11 +0000 Received: from wfhigh3-smtp.messagingengine.com (wfhigh3-smtp.messagingengine.com [64.147.123.154]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id fa785b49-e019-11ee-a1ee-f123f15fe8a2; Tue, 12 Mar 2024 03:41:09 +0100 (CET) Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailfhigh.west.internal (Postfix) with ESMTP id 7BC3018000A0 for ; Mon, 11 Mar 2024 22:41:06 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Mon, 11 Mar 2024 22:41:06 -0400 Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Mon, 11 Mar 2024 22:41:05 -0400 (EDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fa785b49-e019-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= invisiblethingslab.com; h=cc:content-type:content-type:date:date :from:from:in-reply-to:message-id:mime-version:reply-to:subject :subject:to:to; s=fm1; t=1710211266; x=1710297666; bh=m1Gc4Is1ww 9bODWNix52pJ/u1W+EkQ51yPoBPS1BQDk=; b=at1QJNfj2o5JJrPqokedvyQiDV vdHBra9RZ6YI11oTczNm6lR4BZe8n2croZFEknjfE2S2V8PpOsMIaZAjpDEKrm+G AoL+Lj0Jh+27rQ0u9h6ZESpYaKUW0arYO8QFXk1TJCSToiP+CC3VhWxi+egTf24j EvNnAA/t/HYdHR/c4HjN6cOHqj3+fhIoynvB7E4TSD2MQHtG6X3y1Gr1/dfNITOx h1raWXFy5qwceRkUsvs89+4WbMADY/w3kZ9DiNRcpAmL0KS7Uf/+r9+0K19gzn2L y7IF9dVvju626278QWO/q/2ivYj/g99CKrgiq4vsqEGgUPPHK38H648rHiQQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:message-id :mime-version:reply-to:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1710211266; x=1710297666; bh=m1Gc4Is1ww9bODWNix52pJ/u1W+EkQ51yPo BPS1BQDk=; b=FejIWH+ju0oflkkgdHgd/Htz7CxFP/G/lql28YsCCNAelycDXfg DIx8sz/2Pokrcq5LHvE1c03afragRTrvhB1uNidS0XFmMD7WfuaUVl/dAHxifcYZ R+/FOMluGki/Mcximoz7+lRmmGlgWNgHm3jR3xxD8vC4e98lJBKzwuKpg5ZBSwJv FNEINLQkdt0Y6q5OWyfxK8siYtPYB88Z1AdLiJLBsch3XQNfNxcunltpvPmVTzEu +TFvcGuGhxpwB+xssUGHsnpkUxXMkAUhkZ+lrQU1KdZWg1+uO0azxy1RAIDAJTWT gRkTVqHXoZmI9lknIJk/QcjAP8St1RN2CYw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrjedvgdehtdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfggtggusehgtderredttd ejnecuhfhrohhmpeforghrvghkucforghrtgiihihkohifshhkihdqifpkrhgvtghkihcu oehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmqeenuc ggtffrrghtthgvrhhnpeeggfelheekuddugeeugeeitdduieelieehudehffffgfefvdek udfhkeejudeggfenucffohhmrghinhepgigvnhdrohhrghenucevlhhushhtvghrufhiii gvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhesihhnvhhishhi sghlvghthhhinhhgshhlrggsrdgtohhm X-ME-Proxy: Feedback-ID: i1568416f:Fastmail Date: Tue, 12 Mar 2024 03:41:02 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: xen-devel Subject: Release signing key still uses SHA1 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Jb8WvudImkhuf+O4" Content-Disposition: inline --Jb8WvudImkhuf+O4 Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Mar 2024 03:41:02 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: xen-devel Subject: Release signing key still uses SHA1 Hi, The key used to sign release tarballs and git tags still uses SHA1 for its self-signature. Is updated key somewhere already? SHA1 is starting to be rejected by some tools already, for example sequoia-sq: $ sq inspect xen.pub xen.pub: OpenPGP Certificate. =20 Fingerprint: 23E3222C145F4475FA8060A783FE14C957E82BD9 Invalid: No binding signature at time 2024-03-12T02:37= :29Z Public-key algo: RSA Public-key size: 2048 bits Creation time: 2010-04-06 13:55:33 UTC =20 UserID: Xen.org Xen tree code signing (signatures on the xen h= ypervisor and tools) Invalid: Policy rejected non-revocation signature (Pos= itiveCertification) requiring second pre-image resistance because: SHA1 is not considered secure Certifications: 7, use --certifications to list --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab --Jb8WvudImkhuf+O4 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmXvwL8ACgkQ24/THMrX 1yzQvQf/cF5iFyMpUFoyBd8QutNo1AlCl9qxlZj+Sq+XU7iuH/r3DAs/g1YYxS8M rb9NDTgIqMkfH/du/R3LN2JjtkpRo3QgorY8q48sH7E01cGxGR/rBwuPCiGP3Oum JH8SEV4uXYVCDPvy4mekhNJ8HX7JBqa7o3RVsSbj1sO01BtTEf4Nr9DOsYhrODd5 UGvCh+sfwdjaf795+3Fviz8EfeaC+83aYyJtSs16XnRDJfaG/JOrtfIQAQkJxRds QJamZstXrAgBIpM9T1fa6dqe/tJMCU1M9CpnEy17phx7xTZ7D+ozgNHdPQxF1qrR +LgOuomrOZk8bwvVXBlX/iFcmbwmwA== =nDmJ -----END PGP SIGNATURE----- --Jb8WvudImkhuf+O4-- From xen-devel-bounces@lists.xenproject.org Tue Mar 12 03:06:53 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 03:06:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691627.1077825 (Exim 4.92) (envelope-from ) id 1rjsTX-0003Rn-1Q; Tue, 12 Mar 2024 03:06:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691627.1077825; Tue, 12 Mar 2024 03:06:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjsTW-0003Rg-TL; Tue, 12 Mar 2024 03:06:46 +0000 Received: by outflank-mailman (input) for mailman id 691627; Tue, 12 Mar 2024 03:06:45 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjsTV-0003Ra-MY for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 03:06:45 +0000 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on20601.outbound.protection.outlook.com [2a01:111:f403:2416::601]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 8d05a581-e01d-11ee-a1ee-f123f15fe8a2; Tue, 12 Mar 2024 04:06:43 +0100 (CET) Received: from MW4PR04CA0246.namprd04.prod.outlook.com (2603:10b6:303:88::11) by CH2PR12MB4103.namprd12.prod.outlook.com (2603:10b6:610:7e::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.36; Tue, 12 Mar 2024 03:06:38 +0000 Received: from CO1PEPF000044F2.namprd05.prod.outlook.com (2603:10b6:303:88:cafe::29) by MW4PR04CA0246.outlook.office365.com (2603:10b6:303:88::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.35 via Frontend Transport; Tue, 12 Mar 2024 03:06:38 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by CO1PEPF000044F2.mail.protection.outlook.com (10.167.241.72) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7386.12 via Frontend Transport; Tue, 12 Mar 2024 03:06:38 +0000 Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Mon, 11 Mar 2024 22:06:37 -0500 Received: from [10.65.148.173] (10.180.168.240) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.35 via Frontend Transport; Mon, 11 Mar 2024 22:06:34 -0500 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8d05a581-e01d-11ee-a1ee-f123f15fe8a2 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=n8BkrzFWZEd0o+tqV5FdVLfeJaMO4SEW1LIe03lanVK+nAt6cV3rsfQZRGLiy7n3VUCModkGLQyFB4T38FFHhh1QL2YrlVMgawbxfNYwcPPwPCeKR1kiXQf87Qwn5iE0y7O0j3pIGTsSiXWI1LQc7p9cCZw9OJ3HBX+TJlZPnBHEfNU3tNSJqrHyQJVLY2dWRtOSxSHjlab3LYxvVhFfpQJe1+qtANRBnmAdEp8Sqion2I3vZ8fl+J85zabde4E2LV6Tyzg5AJDPhI35MJjemLEsC4HhkKnpr2/4Uqdr67ukMG1G/iMj+blG+/K8/eM+Fp1C7batxzpAkRBGWc1gBg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Yr+6X7xSWaUnvmFFO5ZiabKYnnYNP0V6W0IAmustyf0=; b=iz/523KXuauK0OV9hNG32E1xlCtc6CRA05oSHeOC7oPm35JEz1kp2xPfy2G/i+ultvu9PmlMx1iq+2TdN5iRknGwFVtx1S17CwWznAcW9svIGsaP7Y4HfqL066IuSGUeU80oluY+KGIs7570RHywghA50iyV4EuemKnZmbNDDSUl6//L8xNrItrsqktv1kxuLXkpSW552ysc8zwJSlae3n2Y5Zt8WWO+L8TS36NdFo7DSR71VHg0zMajDSGo/ap3pmtsu/yycduy/zq7vQZJ0lMLaQz+xSDPFDTMosYnng4i2tDkEia3w9B34J0TcxUVJL/Eu8G7gUr+bJJX+97q7g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Yr+6X7xSWaUnvmFFO5ZiabKYnnYNP0V6W0IAmustyf0=; b=VR6cGT44B4HnQoYgeHydKmH+dZiJXPVShww7fysvIuIz+RpZJoTgEaWXZuhGYrMRWG2ESWCLbjnjqYE+xq2i/yH2BfpQ5JDoA6F4T/HgsO6oYO3SLd/kTelclvWth2KguAubANo6ywC8kkOy5YjRZdydqRDOHCuMXNdlUz1qglg= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C Message-ID: <76180f81-3969-4587-b91e-cf9bd7d2e888@amd.com> Date: Tue, 12 Mar 2024 11:06:33 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 3/5] xen/domctl, tools: Introduce a new domctl to get guest memory map To: Jan Beulich CC: Wei Liu , Anthony PERARD , "Juergen Gross" , Andrew Cooper , "George Dunlap" , Julien Grall , "Stefano Stabellini" , Bertrand Marquis , Michal Orzel , "Volodymyr Babchuk" , Alec Kwapis , References: <20240308015435.4044339-1-xin.wang2@amd.com> <20240308015435.4044339-4-xin.wang2@amd.com> Content-Language: en-US From: Henry Wang In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: None (SATLEXMB04.amd.com: xin.wang2@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CO1PEPF000044F2:EE_|CH2PR12MB4103:EE_ X-MS-Office365-Filtering-Correlation-Id: ab888f4a-7ce9-46e0-e9f2-08dc42416f1b X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: gSw7pWihXcP60cfNN96I4ptbQAMLt+jm/50D1gNwVnnAQDfHrpc1vYNfPjf/CQHbWBt3psnJrz1TNBeGuW3c/14ASh/WMgKY5jMIt2UCSkDCgF9q+BvzErXa87t+5tlwmj4vVoVMQUU1w857Bbvtkh6GiIZQf4+7DWBCGp2AZcdKCORcNY3HMbT4mIYhBMTX+8XJNQQRyT/S/nIXTqnemQn8TIjbvCRnln9eTdjQwxHmHx6RoucbpfSZ+HxZqkJbkC0ua8EJcUJaINE3wfGNRIeQGVBmBTH/435rAnK5kdX5IJpe1Nib78AVlcHHvvdMmGkzhZHFqsNvCZHqoUcg/lFHAro4tzgFgh3EZ2sfKiV+gm9hEoZi/r50GRl2rANUNQ0jE4+SK8yVCc0OF8p1XO5CrNzRH8KsYqGtVnzteXrcy//ZXrv954XG7t6W8EkySoaA/tRo+kcAYW1+tU2LCbV6+v9aaxssOoFZgdKqupnKTu9W+/peUCeone3Xdtg7+EubUYy28xW9CVbtrdqV/aTrm6ObMORBfbOFLoE5N47UrdMNCP0QY6dMtIOKuQTQH9Nkk2t/V5qaP/yc5KU90mvnHoldR6aIMRJXc6XYgAQTIMBoh98E4W00t5sShwQvL0uVMq+UqedzhSE/mZRgqrORUsBn6Ov3KHo19Q0KcNZO1r9NxVygnvFE0XCUYofG4uVHIprpEN5mCO83FOqG8MEvaDuCQS4UwPeqsQmD0NARuHKXl9EsjFDfFQYE9FDp X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(36860700004)(82310400014)(1800799015)(7416005)(376005);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Mar 2024 03:06:38.2769 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ab888f4a-7ce9-46e0-e9f2-08dc42416f1b X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CO1PEPF000044F2.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR12MB4103 Hi Jan, On 3/12/2024 12:58 AM, Jan Beulich wrote: > On 08.03.2024 02:54, Henry Wang wrote: >> --- a/xen/include/public/domctl.h >> +++ b/xen/include/public/domctl.h >> @@ -946,6 +946,25 @@ struct xen_domctl_paging_mempool { >> uint64_aligned_t size; /* Size in bytes. */ >> }; >> >> +#define XEN_MAX_MEM_REGIONS 1 >> + >> +struct xen_mem_region { >> + uint64_t start; >> + uint64_t size; > uint64_aligned_t? Yes this makes great sense, thanks for catching it here and ... >> + unsigned int type; > uint32_t and explicit padding (incl checking thereof) please. ...here and ... >> +}; >> +typedef struct xen_mem_region xen_mem_region_t; >> +DEFINE_XEN_GUEST_HANDLE(xen_mem_region_t); >> + >> +struct xen_domctl_mem_map { >> + /* IN & OUT */ >> + uint32_t nr_mem_regions; >> + /* OUT */ >> + XEN_GUEST_HANDLE(xen_mem_region_t) buffer; > XEN_GUEST_HANDLE_64() and explicit padding (+checking) again please. ...here. I will update the patch accordingly and add the padding + checking in v3. Kind regards, Henry > Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 12 03:25:45 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 03:25:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691630.1077835 (Exim 4.92) (envelope-from ) id 1rjslo-0006No-HY; Tue, 12 Mar 2024 03:25:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691630.1077835; Tue, 12 Mar 2024 03:25:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjslo-0006Nh-DY; Tue, 12 Mar 2024 03:25:40 +0000 Received: by outflank-mailman (input) for mailman id 691630; Tue, 12 Mar 2024 03:25:39 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjsln-0006NL-Ak for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 03:25:39 +0000 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on20601.outbound.protection.outlook.com [2a01:111:f403:2414::601]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 31654781-e020-11ee-afdd-a90da7624cb6; Tue, 12 Mar 2024 04:25:37 +0100 (CET) Received: from CH2PR08CA0006.namprd08.prod.outlook.com (2603:10b6:610:5a::16) by CY8PR12MB7684.namprd12.prod.outlook.com (2603:10b6:930:87::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.36; Tue, 12 Mar 2024 03:25:33 +0000 Received: from CH3PEPF00000018.namprd21.prod.outlook.com (2603:10b6:610:5a:cafe::b5) by CH2PR08CA0006.outlook.office365.com (2603:10b6:610:5a::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7292.49 via Frontend Transport; Tue, 12 Mar 2024 03:25:33 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by CH3PEPF00000018.mail.protection.outlook.com (10.167.244.123) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7409.0 via Frontend Transport; Tue, 12 Mar 2024 03:25:33 +0000 Received: from SATLEXMB08.amd.com (10.181.40.132) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Mon, 11 Mar 2024 22:25:31 -0500 Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB08.amd.com (10.181.40.132) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Mon, 11 Mar 2024 20:25:15 -0700 Received: from [10.65.148.173] (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend Transport; Mon, 11 Mar 2024 22:25:13 -0500 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 31654781-e020-11ee-afdd-a90da7624cb6 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=k0EXCHCIzKofh+bL8opTTCZS50GlUOhva2KJ/zj8Enj2B94LQKrAOPb+FWXGaghfRLqEre15HeJ/6l/Lkc12CuNZTN+d84qfH4j9jEKBdp8DSa/VUYJ0xLux1gN+/8Ey6dWKYX+DNYs5u6rsxYfCQYS0ahM2K5fh53WW1+5GjjjaCnYPX9kVFomSEAS1hp8F4KIMa3VFwXOG5jG2NInf9zATx1FwRA8ry4482gi/ycLV4KWOWHHzN56p4jH5OcIQQlrBu9wqIC/LHZJ0k2Lp6O+4roXzXKh5oYbj+vH+KKFXl3ttvFmZC073obs2QpT6JTqHdtVg8cQMMD9ZXLZw5g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=L6Bl6PBC4FkJYU4JrYrA1g5R3/1rnZdldtNvmWVMzVg=; b=gFUNiXstml1GznjOqxTfeu6PdkZS84uu/VA9eDKLGLHzbLvHJ6zgEmVNvhIKwQ0/CU26Q1ndLL4KeCVrg3kgWRZopaMY44GFXvK9HyN+ESyWXRBUIuqrqK+5rOXnIsMn2Tx6s+GuXoIWGGcYq8T1KD40TKR794sMbUCy35DK3TFOhjWOAq59u2NKs45PxRVf/OTcTC8OjHzt98ATArYVcVjS3Ox9xrSXA75xF8Q5GXjC5d7xL9jXId8axIDaqCJUIJNmtv4NBuanT1sVn2VmqvBgtRWuFngMCZEV1lHdoIRKMz3+0dWuM2qkXb5h9e+zSAGGn+TxwnDLu4MiNmS7Ww== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=L6Bl6PBC4FkJYU4JrYrA1g5R3/1rnZdldtNvmWVMzVg=; b=bKee4yG91tz1Lc5eB5Bs0SJB1qJrZt7LHhbiUen6lvKhGn4nVQM3Kkn19mK+xCE4yy9jyn7IckoeZP6WAIWsrzlqUL+pr7L7ViBhfI0OYAJN0bcSaqcvWImt9j/Y2nLazRbe+iC7XqHm9NYtsKyQCACoIxyBBe3/r2C+bbIZJG0= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C Message-ID: Date: Tue, 12 Mar 2024 11:25:12 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 4/5] xen/arm: Find unallocated spaces for magic pages of direct-mapped domU Content-Language: en-US To: Michal Orzel , CC: Stefano Stabellini , Julien Grall , Bertrand Marquis , "Volodymyr Babchuk" , Alec Kwapis , Carlo Nonato References: <20240308015435.4044339-1-xin.wang2@amd.com> <20240308015435.4044339-5-xin.wang2@amd.com> <4821f30b-94a6-4a2a-8c46-81a9d1e288a4@amd.com> From: Henry Wang In-Reply-To: <4821f30b-94a6-4a2a-8c46-81a9d1e288a4@amd.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH3PEPF00000018:EE_|CY8PR12MB7684:EE_ X-MS-Office365-Filtering-Correlation-Id: dbade508-fc71-4c0e-36cc-08dc4244136f X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: I6znPZ3dXaFVroWDdmtYivbY/41hI3HflQaCoA9pKx+b/2ET5q87zT7Jclg9vBnwoyk0rn8iibqMDcRfAH0o06wbVjY3NiO8k87exod1wVUmzrf4Ky+ZJ80v8duPJuT/lH5yfwkDp7mBpe10zGwTrr/tIlcjUVUpdKA4KGEGbJpOn0k9b2LgqTBGcsVAh4Yi4FVSMJvyJOdgQ+VZMGEsM8V3KE6n7NkPUNhopQM9yNMK9/xCQMiZ2zn9YzU9dW/8mIIRSQg0FqobCvzT5e4/vxCMJF+SGBtWiwRoSdU1amE/vugBNli7xAa0dZYtQwUdxSR5C/e2HLRHCA4J+NoZJ7HgU0TptGiDC9LB8QOwrVkkj4Ua3ySHVgDlKfUGNoF8jnRLZX7164pT5WGxYXbWDeaT62GX9hmq7h41EPfCq2wNtcEZDIUy7qRGY79id4deXxtzXdwSkik9PJ881RyONqPDzENLkI9s7bye3MiRXCMogePG2hAw/SRXpMOxQ6lzC51q8mYYvWjMN45rGNlbiDz06NW1oORY8szkJrThrb/8T8cEMn0jL11EMClDI0jgf3/kchlSBPP/9usNeDBu7ZkqqJ+L0aY0n9wP2PW9duRJJxhjbc0xeXkSYOzhxEwxHgI9FNk88T2iP0Nvy+72g/Hg+vTGsplmoo8ibw8reJHgtQr2/lkDc5lnipGOw5Eor3aqRIQdBO1l2vptx2i4sqPR2hm1SLKZvahvRFXeOYTH5YsXCASpSCYlSQ0dfMX6 X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(376005)(36860700004)(1800799015)(82310400014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Mar 2024 03:25:33.0251 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: dbade508-fc71-4c0e-36cc-08dc4244136f X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CH3PEPF00000018.namprd21.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB7684 Hi Michal, On 3/11/2024 9:46 PM, Michal Orzel wrote: > Hi Henry, > > diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c > index 1e1c8d83ae..99447bfb0c 100644 > --- a/xen/arch/arm/dom0less-build.c > +++ b/xen/arch/arm/dom0less-build.c > @@ -682,6 +682,49 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo) > > if ( kinfo->dom0less_feature & DOM0LESS_ENHANCED_NO_XS ) > { > + if ( is_domain_direct_mapped(d) ) > + { > This whole block is dependent on static memory feature that is compiled out by default. > Shouldn't you move it to static-memory.c ? This makes sense. I will convert this block to a function then move to static-memory.c in v3. >> + struct meminfo *avail_magic_regions = xzalloc(struct meminfo); > I can't see corresponding xfree(avail_magic_regions). It's not going to be used after unused memory > regions are retrieved. Hmmm I realized I've made a mess here and below. I will do the proper error handling in v3. >> + struct meminfo *rsrv_mem = &bootinfo.reserved_mem; >> + struct mem_map_domain *mem_map = &d->arch.mem_map; >> + uint64_t magic_region_start = INVALID_PADDR; > What's the purpose of this initialization? magic_region_start is going to be re-assigned before making use of this value. Personally for variables holding an address, I would like to init the local variable to a poison value before use. But you are right it does not make a difference here I think. I can drop the initialization if you prefer not having it, sure. >> + uint64_t magic_region_size = GUEST_MAGIC_SIZE; > Why not paddr_t? Good catch, I mixed struct meminfo with the newly added struct. Will use paddr_t. >> + >> + magic_region_start = avail_magic_regions->bank[0].start; >> + >> + /* >> + * Register the magic region as reserved mem to make sure this >> + * region will not be counted when allocating extended regions. > Well, this is only true in case find_unallocated_memory() is used to retrieve free regions. > What if our direct mapped domU used partial dtb and IOMMU is in use? In this case, > find_memory_holes() will be used and the behavior will be different. > > Also, I'm not sure if it is a good idea to call find_unused_memory twice (with lots of steps inside) > just to retrieve 16MB (btw. add_ext_regions will only return 64MB+ regions) region for magic pages. > I'll let other maintainers share their opinion. I agree with your point. Let's wait a bit longer for more ideas/comments. If no other inputs, I think I will drop the "adding to reserved_mem" part of logic and record the found unused memory in kinfo, then use rangeset_remove_range() to remove this range in both find_unallocated_memory() and find_memory_holes(). > Also, CCing Carlo since he was in a need of retrieving free memory regions as well for cache coloring with dom0. (+ Carlo) Any inputs from your side for this topic Carlo? Kind regards, Henry > ~Michal From xen-devel-bounces@lists.xenproject.org Tue Mar 12 03:44:58 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 03:44:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691634.1077844 (Exim 4.92) (envelope-from ) id 1rjt4H-0000xy-1K; Tue, 12 Mar 2024 03:44:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691634.1077844; Tue, 12 Mar 2024 03:44:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjt4G-0000xr-V5; Tue, 12 Mar 2024 03:44:44 +0000 Received: by outflank-mailman (input) for mailman id 691634; Tue, 12 Mar 2024 03:44:43 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjt4F-0000xl-Sc for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 03:44:43 +0000 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on20600.outbound.protection.outlook.com [2a01:111:f403:200a::600]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id d9b2ac30-e022-11ee-a1ee-f123f15fe8a2; Tue, 12 Mar 2024 04:44:39 +0100 (CET) Received: from DS7PR03CA0330.namprd03.prod.outlook.com (2603:10b6:8:2b::22) by MW4PR12MB6755.namprd12.prod.outlook.com (2603:10b6:303:1ea::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.34; Tue, 12 Mar 2024 03:44:35 +0000 Received: from DS3PEPF000099D3.namprd04.prod.outlook.com (2603:10b6:8:2b:cafe::e8) by DS7PR03CA0330.outlook.office365.com (2603:10b6:8:2b::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.36 via Frontend Transport; Tue, 12 Mar 2024 03:44:35 +0000 Received: from SATLEXMB03.amd.com (165.204.84.17) by DS3PEPF000099D3.mail.protection.outlook.com (10.167.17.4) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7386.12 via Frontend Transport; Tue, 12 Mar 2024 03:44:34 +0000 Received: from SATLEXMB06.amd.com (10.181.40.147) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Mon, 11 Mar 2024 22:44:34 -0500 Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB06.amd.com (10.181.40.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Mon, 11 Mar 2024 22:44:34 -0500 Received: from [10.65.148.173] (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend Transport; Mon, 11 Mar 2024 22:44:32 -0500 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d9b2ac30-e022-11ee-a1ee-f123f15fe8a2 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=io5p5dGsc6auCqhRClgUlW1hoi3493HSHs5hHs3aMLaHJhQ/TtF1FUoUKYft0ta86UDEjsBDmaSp/N8Jjt0FsA/rdFpd4MNdmU2/cFuLxUDWNrQGibOqslI49D2cwffNFpiYabjH3kczTT+DNryvw7EU4kwm6z5EoANLe/kGJSMaimxgXFC8BgxYsPbE0RLo1G5X887mqzbtCHyzK510DpJVK1Qhbd4I+St6BBacLJir5oPj8DyL0mYDMEx18dW1XSxND3YhmXLC5fhXneCK03QyYooWx66ITkl2tPWWBIIfsmwGNq2mfxwy3ak9irXho0NtCV4cWS+397+Pc86SWA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=HR421RGaH5R1i1LbuXUsNy0Y5fvdoCWT+n3WMAEeT/U=; b=h4udzrhZvIgP1TuYWSe+xtC34d8YsUC4MKDCz3asfno/gKye0oh+waMgjJ9XYlCZNJqDVF+1lR2Y1ueus/+VnZaRRnQQMffWh9tQQ2DibNWvr9G+OCzmYtvJiFJ3lxvN9xbAvv0YZYdGy5g9X7jqrcMtTfxEkkIDLrKP2MJcyvM6pBK8E/I3t8AIkKxmCR7C+rd7iViOwn++lNLPc14d6S4rE91r8gKbsbxigwlmYzQwwsjBc8b2Tnc8/aGxlTyeIt3TXK+xrQovakdWiN0A6fM0DZm7+PxhRiyR7TppBRbbU5N8VLg1faSvRv5JbcF6K9kfmeepb/TACD1h2fVP8Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HR421RGaH5R1i1LbuXUsNy0Y5fvdoCWT+n3WMAEeT/U=; b=FXuutLzWLNvizAF/wyX8Fi936huSvhyP0a5+G44EePkiXXFR7FsVSjGn7VtJL4C/Hd0wmXDk/mzyu41JueRKURT1u2W3NLhDd1ITL0BO7gV4p2Gxb1VWm12XjM2O4ceNj27O6NQHbBSy7tXn+MT3xvQo2hv94im5FGT6eU0un8g= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C Message-ID: <294ff8fb-825c-4950-857a-166b65474a53@amd.com> Date: Tue, 12 Mar 2024 11:44:13 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 5/5] xen/memory, tools: Make init-dom0less consume XEN_DOMCTL_get_mem_map To: Jan Beulich CC: Wei Liu , Anthony PERARD , "Andrew Cooper" , George Dunlap , Julien Grall , Stefano Stabellini , Alec Kwapis , References: <20240308015435.4044339-1-xin.wang2@amd.com> <20240308015435.4044339-6-xin.wang2@amd.com> <1cb8bca3-58b6-4a8d-ac46-8338ea5807e7@suse.com> Content-Language: en-US From: Henry Wang In-Reply-To: <1cb8bca3-58b6-4a8d-ac46-8338ea5807e7@suse.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS3PEPF000099D3:EE_|MW4PR12MB6755:EE_ X-MS-Office365-Filtering-Correlation-Id: f5418fff-bb7d-4cef-63ff-08dc4246bc18 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Jg3ac/8tpsN7UOvjH1zIa8omVli6JoNy0209H9EMFTVtkVkrwmnc9yuJNiG118jCy5q0OxlKNc3qizcvrrNJQ2ZMipQiEdblxCfSt3FI8GBkDSD48QibOyjjHy/ZFWuTssv9t6ioTqFpGLgT5JM1eyTplPEzNhhJcnoSJNmwV9cRF92rJ/N7a2U3y3E+MRKJEQKE5G3upKgy7zX2cqJxRb3wIe4N6V2sFQn9D0dXWYnq/rQznXyVwh+w94aYYGIJ3xpzudf+BybFTIVNU66Ma3xpoBW9NJyAeTayp4jpCMatPbHnh9cy127Ar0Dwh8khgFsMv1vJqc258Oqjxh8duWy1qCrLn0h9rML3pCo0ZSw8YdfGfYY3HPs2eWfaGbvozlcBCznnx/tSVNSA4hHKyXOBszV5GkwmCMb1AjwMAH0XMwmQExuyPgaeFcYYoG4aQJHzvQK2Vo+9lOOiUOccywp1//Y5ea3qGg9eKvMwdxJjE59JudpdkzK0mBj7taRMA6Q4ZgV5DVXNPZCq5R9gZvjRvNeEP5qWDgQKZqlbpSA2mCfOPVfsot00g7tHWo29sqZxbNXpOskhZS8soY/CWR3Oge3IZdfRfaxVL+35sYSRcWjChVmpYmOMVfcc9ttbNkrwUzJKC9NQFZzTbzcu1rNjbbNX6B0CszhcE7dbZCY0fB036EZJtGz6ZIgwvB66LVzS4Eo4atEBVVqyIcP09A== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(376005)(1800799015)(82310400014)(36860700004);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Mar 2024 03:44:34.9845 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f5418fff-bb7d-4cef-63ff-08dc4246bc18 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com] X-MS-Exchange-CrossTenant-AuthSource: DS3PEPF000099D3.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR12MB6755 Hi Jan, On 3/12/2024 1:07 AM, Jan Beulich wrote: > I'm afraid the title doesn't really say what the patch actually means > to achieve. > > On 08.03.2024 02:54, Henry Wang wrote: >> Previous commits enable the toolstack to get the domain memory map, >> therefore instead of hardcoding the guest magic pages region, use >> the XEN_DOMCTL_get_mem_map domctl to get the start address of the >> guest magic pages region. Add the (XEN)MEMF_force_heap_alloc memory >> flags to force populate_physmap() to allocate page from domheap >> instead of using 1:1 or static allocated pages to map the magic pages. > A patch description wants to be (largely) self-contained. "Previous > commits" shouldn't be mentioned; recall that the sequence in which > patches go in is unknown to you up front. (In fact the terms "commit" > or "patch" should be avoided altogether when describing what a patch > does. The only valid use I can think of is when referring to commits > already in the tree, and then typically by quoting their hash and > title.) Thanks for the detailed explanation. I will rewrite the title and part of the commit message in v3 to make it clear. >> --- a/xen/include/public/memory.h >> +++ b/xen/include/public/memory.h >> @@ -41,6 +41,11 @@ >> #define XENMEMF_exact_node(n) (XENMEMF_node(n) | XENMEMF_exact_node_request) >> /* Flag to indicate the node specified is virtual node */ >> #define XENMEMF_vnode (1<<18) >> +/* >> + * Flag to force populate physmap to use pages from domheap instead of 1:1 >> + * or static allocation. >> + */ >> +#define XENMEMF_force_heap_alloc (1<<19) >> #endif > If this is for populate_physmap only, then other sub-ops need to reject > its use. > > I have to admit I'm a little wary of allocating another flag here and ... > >> --- a/xen/include/xen/mm.h >> +++ b/xen/include/xen/mm.h >> @@ -205,6 +205,8 @@ struct npfec { >> #define MEMF_no_icache_flush (1U<<_MEMF_no_icache_flush) >> #define _MEMF_no_scrub 8 >> #define MEMF_no_scrub (1U<<_MEMF_no_scrub) >> +#define _MEMF_force_heap_alloc 9 >> +#define MEMF_force_heap_alloc (1U<<_MEMF_force_heap_alloc) >> #define _MEMF_node 16 >> #define MEMF_node_mask ((1U << (8 * sizeof(nodeid_t))) - 1) >> #define MEMF_node(n) ((((n) + 1) & MEMF_node_mask) << _MEMF_node) > ... here - we don't have that many left. Since other sub-ops aren't > intended to support this flag, did you consider adding another (perhaps > even arch-specific) sub-op instead? Not really, I basically followed the discussion from [1] to implement this patch. However I understand your concern. Just want to make sure if I understand your suggestion correctly, by "adding another sub-op" you mean adding a sub-op similar as "XENMEM_populate_physmap" but only with executing the "else" part I want, so we can drop the use of these two added flags? Thanks! [1] https://lore.kernel.org/xen-devel/3982ba47-6709-47e3-a9c2-e2d3b4a2d8e3@xen.org/ Kind regards, Henry > Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 12 06:28:19 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 06:28:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691641.1077854 (Exim 4.92) (envelope-from ) id 1rjvcL-0002S7-Af; Tue, 12 Mar 2024 06:28:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691641.1077854; Tue, 12 Mar 2024 06:28:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjvcL-0002S0-86; Tue, 12 Mar 2024 06:28:05 +0000 Received: by outflank-mailman (input) for mailman id 691641; Tue, 12 Mar 2024 06:28:04 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjvcK-0002Rq-6i; Tue, 12 Mar 2024 06:28:04 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjvcK-0001f4-2E; Tue, 12 Mar 2024 06:28:04 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjvcJ-0007Cj-Ky; Tue, 12 Mar 2024 06:28:03 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rjvcJ-0002so-KR; Tue, 12 Mar 2024 06:28:03 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=zNph0nZiKYwzglD2ZT1ZAa5h3nVNcKFLh7jENoSBkQk=; b=rjf9Ve4fu/Tg8pEmfOdjPqD9w3 4+eVI9kLANHcZ+8rZBoisbynEJ4KtQvQODJwah514JiJZhYrSkcXiY5DucSiFxzkfEX4vs9NAvgvk vaj1EtzdrQ2HzU67yBy1gYxkn09Qylzkq2Ic0zFLpxgcK3Oheiw1BbqgWhjk4xhBHwUM=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-linus test] 184997: tolerable FAIL - PUSHED X-Osstest-Failures: linux-linus:test-armhf-armhf-xl-credit2:host-ping-check-xen:fail:heisenbug linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: linux=0f1a876682f0979d6a1e5f86861dd562d1758936 X-Osstest-Versions-That: linux=e8f897f4afef0031fe618a8e94127a0934896aba From: osstest service owner Date: Tue, 12 Mar 2024 06:28:03 +0000 flight 184997 linux-linus real [real] flight 184999 linux-linus real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/184997/ http://logs.test-lab.xenproject.org/osstest/logs/184999/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-credit2 10 host-ping-check-xen fail pass in 184999-retest Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-credit2 15 migrate-support-check fail in 184999 never pass test-armhf-armhf-xl-credit2 16 saverestore-support-check fail in 184999 never pass test-armhf-armhf-libvirt 16 saverestore-support-check fail like 184991 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop fail like 184991 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop fail like 184991 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop fail like 184991 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 184991 test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail like 184991 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop fail like 184991 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184991 test-amd64-amd64-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl 15 migrate-support-check fail never pass test-arm64-arm64-xl 16 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 15 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 15 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-check fail never pass test-armhf-armhf-libvirt 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qcow2 14 migrate-support-check fail never pass test-amd64-amd64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-check fail never pass test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-arm64-arm64-xl-vhd 14 migrate-support-check fail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-check fail never pass version targeted for testing: linux 0f1a876682f0979d6a1e5f86861dd562d1758936 baseline version: linux e8f897f4afef0031fe618a8e94127a0934896aba Last test of basis 184991 2024-03-11 03:03:07 Z 1 days Testing same since 184997 2024-03-11 18:40:47 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Al Viro Alexander Gordeev Alexander Mikhalitsyn Alexandre Belloni Ali Zahraee Amir Goldstein Anders Larsen Andreas Gruenbacher Andrei Vagin Arnd Bergmann Baokun Li Baolin Wang Bart Van Assche Bill O'Donnell Chao Yu # for the F2FS part Chen Hanxiao Chengming Zhou Christian Brauner Christian König Christoph Hellwig Chuck Lever Colin Ian King Dave Chinner Dave Kleikamp David Disseldorp David Gow David Howells Davidlohr Bueso Dmitry Antipov Eric Sandeen Fenghua Yu Gabriel Krisman Bertazi Giuseppe Scrivano Guenter Roeck Hu Yadi Hu.Yadi Huang Xiaojia Ilpo Järvinen Jan Harkes Javier Carrasco Jay Jeff Layton Jens Axboe JonasZhou Kassey Li Kees Cook Kemeng Shi Kent Overstreet Kousik Sanagavarapu Kunwu Chan Laura Nao Li zeming Liam R. Howlett Linus Torvalds Lucas De Marchi Maciej Wieczor-Retman Marcos Paulo de Souza Marek Szyprowski Mark Brown Masami Hiramatsu (Google) Matthew Wilcox (Oracle) Maxime Ripard Mickaël Salaün Namjae Jeon Naveen N Rao NeilBrown Nguyen Dinh Phi Nikita Zhandarovich Nícolas F. R. A. Prado Oleg Nesterov Randy Dunlap Ricardo B. Marliere Rich Felker Rob Herring Sebastian Reichel SeongJae Park Shuah Khan Srikanth Aithal Stefan Berger Steven Rostedt (Google) Taylor Jackson Tetsuo Handa Theodore Ts'o Thomas Gleixner Thomas Hellström Tom Talpey Trond Myklebust Tycho Andersen Vincenzo Mezzela Wang Jinchao Wen Yang Zhang Yi jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-amd64-dom0pvh-xl-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-freebsd11-amd64 pass test-amd64-amd64-freebsd12-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-examine-bios pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 fail test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-amd64-dom0pvh-xl-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-amd64-xl-pvshim pass test-amd64-amd64-pygrub pass test-amd64-amd64-libvirt-qcow2 pass test-armhf-armhf-libvirt-qcow2 pass test-amd64-amd64-libvirt-raw pass test-arm64-arm64-libvirt-raw pass test-armhf-armhf-libvirt-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-examine-uefi pass test-amd64-amd64-xl-vhd pass test-arm64-arm64-xl-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these 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 : hint: The 'hooks/update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-receive' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. To xenbits.xen.org:/home/xen/git/linux-pvops.git e8f897f4afef0..0f1a876682f09 0f1a876682f0979d6a1e5f86861dd562d1758936 -> tested/linux-linus From xen-devel-bounces@lists.xenproject.org Tue Mar 12 07:34:20 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 07:34:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691669.1077872 (Exim 4.92) (envelope-from ) id 1rjweE-0001hy-Cb; Tue, 12 Mar 2024 07:34:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691669.1077872; Tue, 12 Mar 2024 07:34:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjweE-0001hr-A4; Tue, 12 Mar 2024 07:34:06 +0000 Received: by outflank-mailman (input) for mailman id 691669; Tue, 12 Mar 2024 07:34:05 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjweD-0001hl-Dr for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 07:34:05 +0000 Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [2a00:1450:4864:20::629]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id e66fd71d-e042-11ee-a1ee-f123f15fe8a2; Tue, 12 Mar 2024 08:34:03 +0100 (CET) Received: by mail-ej1-x629.google.com with SMTP id a640c23a62f3a-a4644bde1d4so38755266b.3 for ; Tue, 12 Mar 2024 00:34:03 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id m17-20020a170906721100b00a450b817705sm3532551ejk.154.2024.03.12.00.34.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 Mar 2024 00:34:02 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e66fd71d-e042-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1710228843; x=1710833643; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=yrNpcXD6eUIWdRESCtT423UkYapmLYv0TBI81BSSLpE=; b=KiUjnGZ1BWXrQMoz/dKJKywBs+DIsYRFZUic2Di+JwDXNz/zdtMcEM4hGck54NsPvO Jjhh+W7nBZ/5SviytmISL7XHwrZPY9p4p2jGoyTm3KJlgQdy3eAHDBjvINlWP2i7fQF2 rykKSqKLmfDkOCQesUNATQk/m6x3lpuuLmIluMvgOeiN5tNPtVf6EXwfy9YF6Uso2+wW zRwPm2m/+l8qwfDHnPJ2GpxfQor7j34YH6g3pFC9AY3FaYHbmT90CQUqjAd8v4Pr270N ATj5a2Csn8HHgI/z7JEy9/TX/PXRx7mJWTUNz7Q7wWFOHEfiD9Kow28+Hi0gbeF3ZDOg i7Vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710228843; x=1710833643; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=yrNpcXD6eUIWdRESCtT423UkYapmLYv0TBI81BSSLpE=; b=Rq/IE6ptRSCKvLq8WQzpwBRhCk4mZ9/1kmxR8rX2ATog95284FVYqrRCVdZ9+M8uKE n4ivtFmlVtiviYABr2ULN4wlvrVFfCeyZ5YcueuoLQnBKAPta6bLKI9c4RnaTos9ooU+ C1yO6L4w91A4bVeTbLwXt4qeP+M69ZLU4nlNQ0QhQFlEKJOEpe3MeeQUI3C/Wq2TnX4Y 6lgOneFsufMeAFIoqKp22u2CMDlXkjgEkm9fCufJs4PH4g/Gg2V94l8Z69Wm+dXWcjYw W6unBl2CKDU2xzW4oZPv2lFhdJdDPqrvNN5b71D4j1j9lUH2Ey9RWSQu6zCtUVrz/9/l vzmQ== X-Forwarded-Encrypted: i=1; AJvYcCUqqRFzOzwTnOQ1CvzLDvN5lQIWKX2sTRXgseO2Zun1JXMjH1zGglIzFwScxJWDX3vlg12DPb+3a0Y3E36YGz6p0nnA9hYeeuuB6vPwl7A= X-Gm-Message-State: AOJu0Yw3V44W4c2xL1OQ2tcyHX6ecFHDGSMqJBZbgoHuWopSxrdiZXkX WA8xBeT3PUYUx+X8BialsbKOl6f7Y4YRAc9UdlLi/2u/DYMPqgFgf6rQcUXFBw== X-Google-Smtp-Source: AGHT+IEFQ8QjUBbADZqCQgOjb0TFFo203/77NCNxrvg2+j0ifU4XDqxNpoSdxHhb/EjB72xf84Sxbw== X-Received: by 2002:a17:906:b18f:b0:a46:220c:a55 with SMTP id w15-20020a170906b18f00b00a46220c0a55mr3427898ejy.73.1710228842871; Tue, 12 Mar 2024 00:34:02 -0700 (PDT) Message-ID: <7b9f3e46-8a70-403f-a98c-e53bea04b389@suse.com> Date: Tue, 12 Mar 2024 08:34:01 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 5/5] xen/memory, tools: Make init-dom0less consume XEN_DOMCTL_get_mem_map Content-Language: en-US To: Henry Wang Cc: Wei Liu , Anthony PERARD , Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Alec Kwapis , xen-devel@lists.xenproject.org References: <20240308015435.4044339-1-xin.wang2@amd.com> <20240308015435.4044339-6-xin.wang2@amd.com> <1cb8bca3-58b6-4a8d-ac46-8338ea5807e7@suse.com> <294ff8fb-825c-4950-857a-166b65474a53@amd.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <294ff8fb-825c-4950-857a-166b65474a53@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 12.03.2024 04:44, Henry Wang wrote: > On 3/12/2024 1:07 AM, Jan Beulich wrote: >> On 08.03.2024 02:54, Henry Wang wrote: >>> --- a/xen/include/public/memory.h >>> +++ b/xen/include/public/memory.h >>> @@ -41,6 +41,11 @@ >>> #define XENMEMF_exact_node(n) (XENMEMF_node(n) | XENMEMF_exact_node_request) >>> /* Flag to indicate the node specified is virtual node */ >>> #define XENMEMF_vnode (1<<18) >>> +/* >>> + * Flag to force populate physmap to use pages from domheap instead of 1:1 >>> + * or static allocation. >>> + */ >>> +#define XENMEMF_force_heap_alloc (1<<19) >>> #endif >> If this is for populate_physmap only, then other sub-ops need to reject >> its use. >> >> I have to admit I'm a little wary of allocating another flag here and ... >> >>> --- a/xen/include/xen/mm.h >>> +++ b/xen/include/xen/mm.h >>> @@ -205,6 +205,8 @@ struct npfec { >>> #define MEMF_no_icache_flush (1U<<_MEMF_no_icache_flush) >>> #define _MEMF_no_scrub 8 >>> #define MEMF_no_scrub (1U<<_MEMF_no_scrub) >>> +#define _MEMF_force_heap_alloc 9 >>> +#define MEMF_force_heap_alloc (1U<<_MEMF_force_heap_alloc) >>> #define _MEMF_node 16 >>> #define MEMF_node_mask ((1U << (8 * sizeof(nodeid_t))) - 1) >>> #define MEMF_node(n) ((((n) + 1) & MEMF_node_mask) << _MEMF_node) >> ... here - we don't have that many left. Since other sub-ops aren't >> intended to support this flag, did you consider adding another (perhaps >> even arch-specific) sub-op instead? > > Not really, I basically followed the discussion from [1] to implement > this patch. However I understand your concern. Just want to make sure if > I understand your suggestion correctly, by "adding another sub-op" you > mean adding a sub-op similar as "XENMEM_populate_physmap" but only with > executing the "else" part I want, so we can drop the use of these two > added flags? Thanks! > > [1] > https://lore.kernel.org/xen-devel/3982ba47-6709-47e3-a9c2-e2d3b4a2d8e3@xen.org/ In which case please check with Julien (and perhaps other Arm maintainers) before deciding on whether to go this alternative route. Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 12 07:36:56 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 07:36:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691672.1077883 (Exim 4.92) (envelope-from ) id 1rjwgw-0002Eg-QX; Tue, 12 Mar 2024 07:36:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691672.1077883; Tue, 12 Mar 2024 07:36:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjwgw-0002EZ-NL; Tue, 12 Mar 2024 07:36:54 +0000 Received: by outflank-mailman (input) for mailman id 691672; Tue, 12 Mar 2024 07:36:53 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjwgv-0002ET-Mq for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 07:36:53 +0000 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on20600.outbound.protection.outlook.com [2a01:111:f403:2416::600]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 49a04de4-e043-11ee-a1ee-f123f15fe8a2; Tue, 12 Mar 2024 08:36:51 +0100 (CET) Received: from SN4PR0501CA0048.namprd05.prod.outlook.com (2603:10b6:803:41::25) by MW4PR12MB6708.namprd12.prod.outlook.com (2603:10b6:303:1ed::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.35; Tue, 12 Mar 2024 07:36:47 +0000 Received: from CY4PEPF0000E9D8.namprd05.prod.outlook.com (2603:10b6:803:41:cafe::9f) by SN4PR0501CA0048.outlook.office365.com (2603:10b6:803:41::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.18 via Frontend Transport; Tue, 12 Mar 2024 07:36:46 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by CY4PEPF0000E9D8.mail.protection.outlook.com (10.167.241.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7386.12 via Frontend Transport; Tue, 12 Mar 2024 07:36:46 +0000 Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Tue, 12 Mar 2024 02:36:45 -0500 Received: from [10.65.148.173] (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend Transport; Tue, 12 Mar 2024 02:36:43 -0500 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 49a04de4-e043-11ee-a1ee-f123f15fe8a2 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=C2qf4i8oXxXt+SccMk5O/6oQ7h04iPMGuXNW97y2CZmRBIrLz8/0SmSNdxXgWD7g4+h433RTzD2qIqpDIzTjTsQ3MIuh7BhrGo3n2Lq3BCmLRlwxhAzH/gsjIKnlp7pqcNbzFvxdm459u48vxsnFy7VgHTMO28/EwLmsbpAxhK3DI7RbxnYhU6m0q+qjF66PwomVIDCVd9WkA+7Q/2JvzkthFc44RZHNPYblqrEPwyFyNM/sRdCE/2sCp/C0nHH6yuLNdiOX4C0iXoORAULXQqTW5AImz9IHDnPoVdErLA7ky1DZwroHyZPFD/8G/5SvAdUbc/TW6AGmeXF5gU3u7w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=uXLRgGXa/GHyCQHgRtman8uGCjv6NBxjHbeCydiRMmY=; b=fpBbN9F/n2TOCbk+BP95aXjdSIrlnrDq+Wsn5Sjk6SquYFV467Hqe0zQppxNJ2TaVDsIIPNUZ9fhKvtbhMnVbqCy2qKG8CkOh7nmWu5EREURVMnRtsjj67ajaXBKFGf+eI3cxpJ3cyb4uX2pUNe5H9HmRvUA4CHGI5v0qRiQaufGUpLp9u2REjM4Wm+SgfUZRp9+p/jHxFTRPAuvUooaDbZ00xBZ2Tv5vg9r6ECM+7kLbD62uP4KYY8XJO8gyXXScOM821UhnTzLw/mu28mgKUWZabyZ172Z3Od7V3gg+NZknTMZzaCusL9VytDGnh0wTaJ+5rG032UwdQfUXPZ/zw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uXLRgGXa/GHyCQHgRtman8uGCjv6NBxjHbeCydiRMmY=; b=1lN6ye2IkoD166CG2eKisSau3ARxm3rzfZgvc8WplLMgTua/3qTd/oYn2xjRFiKhv9cpgKlWQbe2ovECBZBy1shA6fZL/umXj/ltQdF9B0WXMRnr1NQ/VXHb3wyuRSTa1F+IUkvUpHxNDn5jNahE08gNZxax45crIFGkD0Fn1Ls= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C Message-ID: <8a4da09f-b880-46f5-a2ad-b29b77f39108@amd.com> Date: Tue, 12 Mar 2024 15:36:42 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 5/5] xen/memory, tools: Make init-dom0less consume XEN_DOMCTL_get_mem_map To: Jan Beulich CC: Wei Liu , Anthony PERARD , Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Alec Kwapis , References: <20240308015435.4044339-1-xin.wang2@amd.com> <20240308015435.4044339-6-xin.wang2@amd.com> <1cb8bca3-58b6-4a8d-ac46-8338ea5807e7@suse.com> <294ff8fb-825c-4950-857a-166b65474a53@amd.com> <7b9f3e46-8a70-403f-a98c-e53bea04b389@suse.com> Content-Language: en-US From: Henry Wang In-Reply-To: <7b9f3e46-8a70-403f-a98c-e53bea04b389@suse.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: None (SATLEXMB04.amd.com: xin.wang2@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CY4PEPF0000E9D8:EE_|MW4PR12MB6708:EE_ X-MS-Office365-Filtering-Correlation-Id: cbb59859-b180-4c28-9e3c-08dc42672bc5 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: UYD8LGobvkutqWncPGvqec5miUOSnVnOgBvKq6AU4dzBMjtMEN6iwEtIQbWInn3UMZzqbujZiZulMWHHsRgo868EEqzBIBLXSjZlzQFfPpTsRybcySIcuSKjt5LN9GuXHeYGR4frFs/+npOy7K9tsJE3rhpzt+gvRIoVaLnP5fFDyQ2XEmBk4bPhnT796wd5a76/GURd5In9F7Fhgy8boXvQi7OA7XFJedQXtBmIaxlsDeI317nNfZAifcOo7dsVWWTKvdtIkWwX3k9DPmxh/NzM3+RO+id2hu4s3xpBTuvWPxXzBTDGU58OHSu2P2JoqeUWBAAUkuE9zrfR6pTtJr9Dczg2SHKd2z+KSH4KqtfcZAWa1X2Ts/6Sm8+bcZAjKTO4K/iOuhXbM5Ld15OWgMnO7FKUfiUNhK+1WHt2vSJAC0DQiM/nfwPDcv9+Mhcp7sb2S9ebm9VMTPIbKv9UdTi/7+UHBYMWL1Y6u66mrRhSVKg8/cHAfrk7d4wL8d1B8K915aYalBNKjjdYEYmUWUuCDREEU96mxWtnzxEIJeCxtsm1+PYqC3k7xyMuMws9RGJFnm2IP3yQzJqtQXFKlMz4QylLpl1T9aJwu2z2xJNgA16zQzIEKxyAg4Cm3fbySWcv8VD/gicoJ+Wnu/zg/IDeaN7Dd3DB/hKtuRflKDObkQVTtRHx5aDf5Abj8ZDuTfJflXM9visQsM4NIuZZHw== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(82310400014)(1800799015)(36860700004)(376005);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Mar 2024 07:36:46.2110 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: cbb59859-b180-4c28-9e3c-08dc42672bc5 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CY4PEPF0000E9D8.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR12MB6708 Hi Jan, On 3/12/2024 3:34 PM, Jan Beulich wrote: > On 12.03.2024 04:44, Henry Wang wrote: >> On 3/12/2024 1:07 AM, Jan Beulich wrote: >>> On 08.03.2024 02:54, Henry Wang wrote: >>>> --- a/xen/include/public/memory.h >>>> +++ b/xen/include/public/memory.h >>>> @@ -41,6 +41,11 @@ >>>> #define XENMEMF_exact_node(n) (XENMEMF_node(n) | XENMEMF_exact_node_request) >>>> /* Flag to indicate the node specified is virtual node */ >>>> #define XENMEMF_vnode (1<<18) >>>> +/* >>>> + * Flag to force populate physmap to use pages from domheap instead of 1:1 >>>> + * or static allocation. >>>> + */ >>>> +#define XENMEMF_force_heap_alloc (1<<19) >>>> #endif >>> If this is for populate_physmap only, then other sub-ops need to reject >>> its use. >>> >>> I have to admit I'm a little wary of allocating another flag here and ... >>> >>>> --- a/xen/include/xen/mm.h >>>> +++ b/xen/include/xen/mm.h >>>> @@ -205,6 +205,8 @@ struct npfec { >>>> #define MEMF_no_icache_flush (1U<<_MEMF_no_icache_flush) >>>> #define _MEMF_no_scrub 8 >>>> #define MEMF_no_scrub (1U<<_MEMF_no_scrub) >>>> +#define _MEMF_force_heap_alloc 9 >>>> +#define MEMF_force_heap_alloc (1U<<_MEMF_force_heap_alloc) >>>> #define _MEMF_node 16 >>>> #define MEMF_node_mask ((1U << (8 * sizeof(nodeid_t))) - 1) >>>> #define MEMF_node(n) ((((n) + 1) & MEMF_node_mask) << _MEMF_node) >>> ... here - we don't have that many left. Since other sub-ops aren't >>> intended to support this flag, did you consider adding another (perhaps >>> even arch-specific) sub-op instead? >> Not really, I basically followed the discussion from [1] to implement >> this patch. However I understand your concern. Just want to make sure if >> I understand your suggestion correctly, by "adding another sub-op" you >> mean adding a sub-op similar as "XENMEM_populate_physmap" but only with >> executing the "else" part I want, so we can drop the use of these two >> added flags? Thanks! >> >> [1] >> https://lore.kernel.org/xen-devel/3982ba47-6709-47e3-a9c2-e2d3b4a2d8e3@xen.org/ > In which case please check with Julien (and perhaps other Arm maintainers) > before deciding on whether to go this alternative route. Yes sure, I will wait a bit longer for the agreement of the discussion before implementing the code. Kind regards, Henry > Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 12 07:54:18 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 07:54:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691677.1077894 (Exim 4.92) (envelope-from ) id 1rjwxd-00051V-7r; Tue, 12 Mar 2024 07:54:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691677.1077894; Tue, 12 Mar 2024 07:54:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjwxd-00051O-3N; Tue, 12 Mar 2024 07:54:09 +0000 Received: by outflank-mailman (input) for mailman id 691677; Tue, 12 Mar 2024 07:54:07 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjwxb-00051I-T9 for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 07:54:07 +0000 Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [2a00:1450:4864:20::62a]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id b3007f0f-e045-11ee-a1ee-f123f15fe8a2; Tue, 12 Mar 2024 08:54:05 +0100 (CET) Received: by mail-ej1-x62a.google.com with SMTP id a640c23a62f3a-a4429c556efso421655666b.0 for ; Tue, 12 Mar 2024 00:54:05 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id uz17-20020a170907119100b00a45cac9ae6bsm3563382ejb.162.2024.03.12.00.54.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 Mar 2024 00:54:04 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b3007f0f-e045-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1710230045; x=1710834845; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=f3GK0cmtdDN2N9cAiwyNY1qd0hRMu+6vns3erC5jAMY=; b=I9RfMTP/dXdKGjhcfFjsz28R8/WZ9SJVOLo1Q4xocb77WWusaCtK5I4V/21iC8D4kY ENR3W1SdaZN9EL2zCeo5F+Ae2bw1Z6ZQwuuA0sh5LR0b4SdpUf8ogP65ZF7vkvvBwOkc sf0ix8Ie1ZJdM9z+y/X7K5r0WGy5wnK5rM6GzuXTuaIJQkYWQxBlazz8UX69Bot2myAg I/oY5tygBmV60rZrxW7Mfra0JFIy+5yb8KKRtrcT6TmO4mcCoX5Z1TJ31gn9OwKWvBzo OyFmGfWkltEHpzlnzsRdQQ0EcosY7740DWlUOq7Ahzrw5egwK4L9l9ra0OvQI1JI5RtG tqPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710230045; x=1710834845; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=f3GK0cmtdDN2N9cAiwyNY1qd0hRMu+6vns3erC5jAMY=; b=hAWFSNyUoKXBMKofwk4TL7YGWaQnn5rYe586sF5s12BXQLesUPNxYOYUF5dopf9JIj jm+N9ZL2WiAVb9vMWDwYn5jnq57PwgZ3u3g3+k7ovQ6gvAwYnVmP2E0zt1xJikpiJUnx Ga36C5Q8U+HOw3AUF1UeVtBRub6mtyun4J2vDnPuWwtrJIqC58Mhct3y0xdNC3E4XxTZ zCKoBjIR4Wr5TR4DHILWfctiF4jMU0wTEQQolYSEQ7nrnUdMv9CmrQGzTt6szqR0h8fD 8eVnxlRDNkRa4q5dJWDPfd1u829RR+K/z0Yi4QhBhRP5x30o6Y0ox8prPBgzNx8En9c9 M9HQ== X-Forwarded-Encrypted: i=1; AJvYcCWSnJ8+exZiHpGNRej2ujRA1p73ahSnn2XnA28Po/18DgSUYT/teAh5ZTE7Znp3FXv1C5N4wb1Q1KLHcdjyElWJ7/yKQy6malwUM/PPqlE= X-Gm-Message-State: AOJu0YzprM8DTcZWae+5+Z0piupQxP5NOAnAXvG0PcXavmuylZhViB+s stG05QBLIUP6SgRi7r8vCkpsj7qIVmz6xafe1v1P876PmbCUtBYXmoRkQIEQtw== X-Google-Smtp-Source: AGHT+IGkBlQ/4D51Icy0kE0Ssw3BxOn727nfGFJ4t1n1oObO5yDGmUllJgwhTN/jCg3lbK3LdwB4Vw== X-Received: by 2002:a17:906:3daa:b0:a3f:5144:ada2 with SMTP id y10-20020a1709063daa00b00a3f5144ada2mr5294718ejh.2.1710230045147; Tue, 12 Mar 2024 00:54:05 -0700 (PDT) Message-ID: <1c67a337-e9d5-4e4a-91d5-3c935c410cda@suse.com> Date: Tue, 12 Mar 2024 08:54:03 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/3] x86/svm: Drop the _enabled suffix from vmcb bits To: Vaishali Thakkar Cc: andrew.cooper3@citrix.com, roger.pau@citrix.com, wl@xen.org, xen-devel@lists.xenproject.org References: <8e6d8cac54ca05f1202580b574c548e08988d8f6.1710149462.git.vaishali.thakkar@vates.tech> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <8e6d8cac54ca05f1202580b574c548e08988d8f6.1710149462.git.vaishali.thakkar@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 11.03.2024 13:40, Vaishali Thakkar wrote: > --- a/xen/arch/x86/hvm/svm/nestedsvm.c > +++ b/xen/arch/x86/hvm/svm/nestedsvm.c > @@ -571,7 +571,7 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct cpu_user_regs *regs) > if ( nestedhvm_paging_mode_hap(v) ) > { > /* host nested paging + guest nested paging. */ > - n2vmcb->_np_enable = 1; > + n2vmcb->_np = true; > > nestedsvm_vmcb_set_nestedp2m(v, ns_vmcb, n2vmcb); > > @@ -585,7 +585,7 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct cpu_user_regs *regs) > else if ( paging_mode_hap(v->domain) ) > { > /* host nested paging + guest shadow paging. */ > - n2vmcb->_np_enable = 1; > + n2vmcb->_np = true; > /* Keep h_cr3 as it is. */ > n2vmcb->_h_cr3 = n1vmcb->_h_cr3; > /* When l1 guest does shadow paging > @@ -601,7 +601,7 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct cpu_user_regs *regs) > else > { > /* host shadow paging + guest shadow paging. */ > - n2vmcb->_np_enable = 0; > + n2vmcb->_np = false; > n2vmcb->_h_cr3 = 0x0; > > /* TODO: Once shadow-shadow paging is in place come back to here > @@ -706,7 +706,7 @@ nsvm_vcpu_vmentry(struct vcpu *v, struct cpu_user_regs *regs, > } > > /* nested paging for the guest */ > - svm->ns_hap_enabled = !!ns_vmcb->_np_enable; > + svm->ns_hap_enabled = ns_vmcb->_np; > > /* Remember the V_INTR_MASK in hostflags */ > svm->ns_hostflags.fields.vintrmask = !!ns_vmcb->_vintr.fields.intr_masking; > @@ -1084,7 +1084,7 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs) > if ( nestedhvm_paging_mode_hap(v) ) > { > /* host nested paging + guest nested paging. */ > - ns_vmcb->_np_enable = n2vmcb->_np_enable; > + ns_vmcb->_np = n2vmcb->_np; > ns_vmcb->_cr3 = n2vmcb->_cr3; > /* The vmcb->h_cr3 is the shadowed h_cr3. The original > * unshadowed guest h_cr3 is kept in ns_vmcb->h_cr3, > @@ -1093,7 +1093,7 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs) > else if ( paging_mode_hap(v->domain) ) > { > /* host nested paging + guest shadow paging. */ > - ns_vmcb->_np_enable = 0; > + ns_vmcb->_np = false; > /* Throw h_cr3 away. Guest is not allowed to set it or > * it can break out, otherwise (security hole!) */ > ns_vmcb->_h_cr3 = 0x0; > @@ -1104,7 +1104,7 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs) > else > { > /* host shadow paging + guest shadow paging. */ > - ns_vmcb->_np_enable = 0; > + ns_vmcb->_np = false; > ns_vmcb->_h_cr3 = 0x0; > /* The vmcb->_cr3 is the shadowed cr3. The original > * unshadowed guest cr3 is kept in ns_vmcb->_cr3, While spotting the small issue below it occurred to me: Why is it that vmcb_set_...() is open-coded everywhere here? I think this would be pretty nice to avoid at the same time (for lines touched anyway, or in a separate prereq patch, or alternatively [and only ideally] for all other instances in a follow-on patch). Thoughts? > --- a/xen/arch/x86/hvm/svm/svm.c > +++ b/xen/arch/x86/hvm/svm/svm.c > @@ -473,7 +473,7 @@ static int svm_vmcb_restore(struct vcpu *v, struct hvm_hw_cpu *c) > > if ( paging_mode_hap(v->domain) ) > { > - vmcb_set_np_enable(vmcb, 1); > + vmcb_set_np(vmcb, 1); No switching to "true" here? (If the answer to the other question is "No" for whatever reason, I'd nevertheless like to see this on adjusted, which could then be done while committing.) Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 12 07:59:55 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 07:59:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691681.1077902 (Exim 4.92) (envelope-from ) id 1rjx39-0005pk-PM; Tue, 12 Mar 2024 07:59:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691681.1077902; Tue, 12 Mar 2024 07:59:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjx39-0005pd-Mr; Tue, 12 Mar 2024 07:59:51 +0000 Received: by outflank-mailman (input) for mailman id 691681; Tue, 12 Mar 2024 07:59:50 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjx38-0005pW-9m for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 07:59:50 +0000 Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [2a00:1450:4864:20::534]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 7fb87237-e046-11ee-afdd-a90da7624cb6; Tue, 12 Mar 2024 08:59:49 +0100 (CET) Received: by mail-ed1-x534.google.com with SMTP id 4fb4d7f45d1cf-56878bb1abdso197156a12.1 for ; Tue, 12 Mar 2024 00:59:49 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id wy4-20020a170906fe0400b00a4354b9893csm3584697ejb.74.2024.03.12.00.59.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 Mar 2024 00:59:48 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 7fb87237-e046-11ee-afdd-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1710230388; x=1710835188; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=O5n7+IfRMpREeyf0dMDh/LNDToXH/s8vE+3L1Q1VXHo=; b=ZLXjXuXURt9OHDWaVFbcxQq1tX2Pp2Q3yEY/bYBF1Ve0L730N85q53aaWM41OknwCp VoBYnC79hq6jRnhVlkR80O9/rub8iyf+Bc34t7NQudpHbfnXpFbIYYr9vs4aKUzqIBFb +ITYZebUcP9K/AIqr+LIAJfwlBDAh3egm+2WFjaaYVGB7nWXbVex3o0dJ79JWvurwppC 7Evg07spJeEweNG5Crc7Yckdm8BzSGjIuxI+floqUbhpbjd+1mM5WE0xfI+WTmuv0jlP T7wTPU7jEafQpJS9/PJ0j+1S+h4Xiqv0krEGtaaycwwT6R/TzhrkDuiauISCs0pEsTzq FKzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710230388; x=1710835188; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=O5n7+IfRMpREeyf0dMDh/LNDToXH/s8vE+3L1Q1VXHo=; b=i2tUp22B4AvfvarMcLDaU4RPp4jtWRtOA82g2x0eEzMjjmY5GOjHHb98qhsEQ0aeqz wsqyxmtt7Z203lQS7uKXjduaPpID6Gr4lOaUAD8qjmXlQ8rdw0VQ1qIwx+TJAxkbomC6 YcHfbEwUcYk+BnaqU1EAAN7HtsaSMZ9CRk9nx3oAEHaSY9Epzn2/y4nt0FrCa7hrXdin U9ak4wJp5ad45BhsMWticGS94e5ZDfyTfSWzQqlXxynSa+Azr6rcKzBhY9fAte8M7OuX UKIwxYILH1qYNSYkcX56CCqfS1N0P06G5nGeyZ12z/pFwANjCX0QZi6T8bghKDLa1IeR 5Zwg== X-Forwarded-Encrypted: i=1; AJvYcCUOS6Hm/GdkL2/wXeQvH00vNtF/hB3WGSr9i765HPT9XItpNsfug7qKVH8caC1wnVsIXi+nzolJXR/EmnjwJl79/3ExlXygWeQYi2nHiPU= X-Gm-Message-State: AOJu0YxnrzGWBzT5/RunQF9h6Pz43RwnmyHaxRgSDxCCcXR667dhiyym kKWpKnedQkt4H3Ec+XVcMdpsWaV0n8HRwVwoxw9nv3Po5njl5i6rmNVMza+iVw== X-Google-Smtp-Source: AGHT+IFytpSheQwets1rd/gMDava4tzLwMZ/l3ojTiD458htyxLn16p5WYaVi2/zb1BELGiYED7qWg== X-Received: by 2002:a17:906:3e52:b0:a46:196d:d678 with SMTP id t18-20020a1709063e5200b00a46196dd678mr664732eji.36.1710230388545; Tue, 12 Mar 2024 00:59:48 -0700 (PDT) Message-ID: Date: Tue, 12 Mar 2024 08:59:47 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/3] x86/svm: Drop the suffix _guest from vmcb bit Content-Language: en-US To: Vaishali Thakkar Cc: andrew.cooper3@citrix.com, roger.pau@citrix.com, wl@xen.org, xen-devel@lists.xenproject.org References: From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 11.03.2024 13:40, Vaishali Thakkar wrote: > @@ -698,11 +698,11 @@ nsvm_vcpu_vmentry(struct vcpu *v, struct cpu_user_regs *regs, > /* Convert explicitely to boolean. Deals with l1 guests > * that use flush-by-asid w/o checking the cpuid bits */ > nv->nv_flushp2m = !!ns_vmcb->tlb_control; > - if ( svm->ns_guest_asid != ns_vmcb->_guest_asid ) > + if ( svm->ns_asid != ns_vmcb->_asid ) > { > nv->nv_flushp2m = 1; > hvm_asid_flush_vcpu_asid(&vcpu_nestedhvm(v).nv_n2asid); > - svm->ns_guest_asid = ns_vmcb->_guest_asid; > + svm->ns_asid = ns_vmcb->_asid; > } > > /* nested paging for the guest */ > @@ -1046,7 +1046,7 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs) > /* Keep it. It's maintainted by the l1 guest. */ > > /* ASID */ > - /* ns_vmcb->_guest_asid = n2vmcb->_guest_asid; */ > + /* ns_vmcb->_asid = n2vmcb->_asid; */ Unlike in the earlier patch, where I could accept the request to switch to using accessor functions as scope-creep-ish, here I'm pretty firm with my request to stop their open-coding at the same time. Unless of course there's a technical reason the accessors cannot be used here. Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 12 08:05:24 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 08:05:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691688.1077913 (Exim 4.92) (envelope-from ) id 1rjx8Q-0007ty-Uc; Tue, 12 Mar 2024 08:05:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691688.1077913; Tue, 12 Mar 2024 08:05:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjx8Q-0007tr-Qe; Tue, 12 Mar 2024 08:05:18 +0000 Received: by outflank-mailman (input) for mailman id 691688; Tue, 12 Mar 2024 08:05:18 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjx8Q-0007tl-5i for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 08:05:18 +0000 Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [2a00:1450:4864:20::52c]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 4291cccc-e047-11ee-a1ee-f123f15fe8a2; Tue, 12 Mar 2024 09:05:16 +0100 (CET) Received: by mail-ed1-x52c.google.com with SMTP id 4fb4d7f45d1cf-563c403719cso6316276a12.2 for ; Tue, 12 Mar 2024 01:05:16 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id sa38-20020a1709076d2600b00a453123b111sm3576776ejc.120.2024.03.12.01.05.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 Mar 2024 01:05:15 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 4291cccc-e047-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1710230715; x=1710835515; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=EfHZVO2BLVETERud7kLKfDOk+MoyZPE6ri6S0rdi9vc=; b=AkY5P5fU/w9I1k53HKdY8qpbKPqPH1GKDkWR7JZ01PzVzyjyyVeBjg2ZBzwNxR5B9Z Ice9DQJbnpWgEdKVnRl9m6lo8MLLLQtttyh8yPT0q10dd5NNKQlDLFcemC3bA4AgQlBj tb1/594JdrsHdNPZ2IzV3JkfrIv2JuXD4gr676Qwsd431+vDSH4SWdAgW/YRDE02TLaB J2Wnsbr6IwGVvfJwn8MoPGbTCi+xV9tGKJfvXUAnrZ0UzXFV/iTozNUL2me8w1q5Y0Wa bfSQurcGnVd9rmNJvhEWaX+dlu6i1ljMp3m+3JJ4FzXanGSb8pD3Ex4pZ8oCCJoZgfXb mVUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710230715; x=1710835515; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=EfHZVO2BLVETERud7kLKfDOk+MoyZPE6ri6S0rdi9vc=; b=quklJ3s5kZySJ7KnYAErJKhnmE3JjJMyY0cRPObT3BLS9PtHngrtN3MCmdRqoHy0Us nm7Vxv4yQcNO92ZfZHK3TPQqitx/EPLqw7oRnsjhHB3AJgV56P3HBvBvnYOZL0QtiSph bDI2nUfYWHQkzTlJdpDqiHgXWGlrp6Ps2CgmnPQaYsmTKpmbPi1fqVzFF+jHxk9sAMSC yjRN6i0jy9/aU8850cgRP8AFwNjbhex6INmOx0X3+b4oNK/m76/WBQhaXYfczFr04DqJ 414t6CwA6vRAY6Mc1a80DIrl0jFokku8x3IzJsys4NL3GMGKqMPx1bUIG3/nv9rcCfSZ 8Jsg== X-Forwarded-Encrypted: i=1; AJvYcCUImioe3PApWi6rGTUgSBgPHkPlqE50Ac1NQYvv4euyLWgdozpk3xpn5wdraTotTqizlwyEhF9ahvkSHDkhp1pt5juOcYOdBUYlrHHX7lg= X-Gm-Message-State: AOJu0YxNrtgcWCijsswg49DY8Bkr76j+SoHAfxzIeHeaw6b8GohzrdcZ g/KEwJCU378cGqvmGn2G7QA2wf+Ce52LysdiJyeF3z0VwPWbimdBskIxY5z37w== X-Google-Smtp-Source: AGHT+IFHyLgxPbLb790N0ChakzHvKQ3wnxeo5nLRvK+Yxc+rszRBYdCfPQF7kTSduKXoQ1C5Q5IMBw== X-Received: by 2002:a17:906:3ac9:b0:a46:2874:ecd5 with SMTP id z9-20020a1709063ac900b00a462874ecd5mr1866010ejd.55.1710230715547; Tue, 12 Mar 2024 01:05:15 -0700 (PDT) Message-ID: <708aad8c-cf06-4a1d-b2d2-d4405cc19213@suse.com> Date: Tue, 12 Mar 2024 09:05:14 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 3/3] x86/svmdebug: Print sev and sev_es vmcb bits Content-Language: en-US To: Vaishali Thakkar Cc: andrew.cooper3@citrix.com, roger.pau@citrix.com, wl@xen.org, xen-devel@lists.xenproject.org References: <0e688a18a97e495352e2b08cb7634abbc238da1b.1710149462.git.vaishali.thakkar@vates.tech> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <0e688a18a97e495352e2b08cb7634abbc238da1b.1710149462.git.vaishali.thakkar@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 11.03.2024 13:40, Vaishali Thakkar wrote: > While sev and sev_es bits are not yet enabled in xen, > including their status in the VMCB dump could be > informational.Therefore, print it via svmdebug. Yet there are more bits there. I'm okay with leaving off printing of them here, but it wants clarifying why some are printed and some are not. > --- a/xen/arch/x86/hvm/svm/svmdebug.c > +++ b/xen/arch/x86/hvm/svm/svmdebug.c > @@ -51,8 +51,11 @@ void svm_vmcb_dump(const char *from, const struct vmcb_struct *vmcb) > vmcb->exitcode, vmcb->exit_int_info.raw); > printk("exitinfo1 = %#"PRIx64" exitinfo2 = %#"PRIx64"\n", > vmcb->exitinfo1, vmcb->exitinfo2); > - printk("np_ctrl = %#"PRIx64" asid = %#x\n", > - vmcb_get_np_ctrl(vmcb), vmcb_get_asid(vmcb)); > + printk("asid = %#x np_ctrl = %#"PRIx64" - %s%s%s\n", > + vmcb_get_asid(vmcb), vmcb_get_np_ctrl(vmcb), > + vmcb_get_np(vmcb) ? "NP" : "", > + vmcb_get_sev(vmcb) ? "SEV" : "", > + vmcb_get_sev_es(vmcb) ? "SEV_ES" : ""); Each of these three string literals needs a leading blank as separator. In exchange the one in the format string immediately after '-' then will want dropping. That'll still lead to slightly odd output if none of the bits is set; imo it would be slightly less odd if you used printk("asid = %#x np_ctrl = %#"PRIx64":%s%s%s\n", instead. Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 12 08:14:02 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 08:14:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691693.1077923 (Exim 4.92) (envelope-from ) id 1rjxGm-0001L9-OE; Tue, 12 Mar 2024 08:13:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691693.1077923; Tue, 12 Mar 2024 08:13:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjxGm-0001L2-L1; Tue, 12 Mar 2024 08:13:56 +0000 Received: by outflank-mailman (input) for mailman id 691693; Tue, 12 Mar 2024 08:13:56 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjxGl-0001Ks-UZ; Tue, 12 Mar 2024 08:13:55 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjxGl-0004Pj-Pa; Tue, 12 Mar 2024 08:13:55 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjxGl-0005FT-DQ; Tue, 12 Mar 2024 08:13:55 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rjxGl-0002oA-Cn; Tue, 12 Mar 2024 08:13:55 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=+93vfX3yn9JEOp/CINDqsBzG4DwHUY7sXcDH9tPlzSA=; b=uldaBQ0Y689fw0j3CbeTVLadjL pgnwLI6tqfXdQJgywUq0QuX+3Qhp5tQz6d9LLcz+7lte6huhuqC7TI5bm9/RJDg9bvNIuiyVHly6m uFuKPQUDlViQXBegkRF5aY+a/xoInii3wRw+suzve5yby5eBUvqQxstyKAj7dmBPHRT4=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable test] 184998: regressions - FAIL X-Osstest-Failures: xen-unstable:build-arm64-pvops:kernel-build:fail:regression xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:windows-install:fail:heisenbug xen-unstable:test-arm64-arm64-examine:build-check(1):blocked:nonblocking xen-unstable:test-arm64-arm64-libvirt-raw:build-check(1):blocked:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking xen-unstable:test-arm64-arm64-xl:build-check(1):blocked:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:build-check(1):blocked:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:build-check(1):blocked:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:build-check(1):blocked:nonblocking xen-unstable:test-arm64-arm64-xl-vhd:build-check(1):blocked:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:build-check(1):blocked:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: xen=7c81558208de7858251b62f168a449be84305595 X-Osstest-Versions-That: xen=7c81558208de7858251b62f168a449be84305595 From: osstest service owner Date: Tue, 12 Mar 2024 08:13:55 +0000 flight 184998 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/184998/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-pvops 6 kernel-build fail REGR. vs. 184996 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 12 windows-install fail pass in 184996 Tests which did not succeed, but are not blocking: test-arm64-arm64-examine 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-raw 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit1 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-thunderx 1 build-check(1) blocked n/a test-arm64-arm64-xl-vhd 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop fail in 184996 blocked in 184998 test-arm64-arm64-xl-thunderx 15 migrate-support-check fail in 184996 never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-check fail in 184996 never pass test-arm64-arm64-xl 15 migrate-support-check fail in 184996 never pass test-arm64-arm64-xl 16 saverestore-support-check fail in 184996 never pass test-arm64-arm64-xl-credit2 15 migrate-support-check fail in 184996 never pass test-arm64-arm64-xl-credit2 16 saverestore-support-check fail in 184996 never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-check fail in 184996 never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-check fail in 184996 never pass test-arm64-arm64-xl-credit1 15 migrate-support-check fail in 184996 never pass test-arm64-arm64-xl-credit1 16 saverestore-support-check fail in 184996 never pass test-arm64-arm64-xl-xsm 15 migrate-support-check fail in 184996 never pass test-arm64-arm64-xl-xsm 16 saverestore-support-check fail in 184996 never pass test-arm64-arm64-libvirt-raw 14 migrate-support-check fail in 184996 never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-check fail in 184996 never pass test-arm64-arm64-xl-vhd 14 migrate-support-check fail in 184996 never pass test-arm64-arm64-xl-vhd 15 saverestore-support-check fail in 184996 never pass test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop fail like 184996 test-armhf-armhf-libvirt 16 saverestore-support-check fail like 184996 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 184996 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop fail like 184996 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 184996 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 184996 test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail like 184996 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop fail like 184996 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 184996 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 184996 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184996 test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-amd64-i386-xl-pvshim 14 guest-start fail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-check fail never pass test-amd64-i386-libvirt 15 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 15 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-check fail never pass test-armhf-armhf-libvirt 15 migrate-support-check fail never pass test-amd64-i386-libvirt-raw 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-check fail never pass version targeted for testing: xen 7c81558208de7858251b62f168a449be84305595 baseline version: xen 7c81558208de7858251b62f168a449be84305595 Last test of basis 184998 2024-03-12 01:55:48 Z 0 days Testing same since (not found) 0 attempts jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops fail build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl blocked test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm blocked test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm blocked test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-dom0pvh-xl-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-qemuu-freebsd11-amd64 pass test-amd64-amd64-qemuu-freebsd12-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-examine-bios pass test-amd64-i386-examine-bios pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 blocked test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 blocked test-armhf-armhf-xl-credit2 pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine blocked test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-dom0pvh-xl-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-armhf-armhf-libvirt-qcow2 pass test-amd64-amd64-xl-qcow2 pass test-arm64-arm64-libvirt-raw blocked test-armhf-armhf-libvirt-raw pass test-amd64-i386-libvirt-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx blocked test-amd64-amd64-examine-uefi pass test-amd64-i386-examine-uefi pass test-amd64-amd64-libvirt-vhd pass test-arm64-arm64-xl-vhd blocked test-armhf-armhf-xl-vhd pass test-amd64-i386-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these 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 Published tested tree is already up to date. From xen-devel-bounces@lists.xenproject.org Tue Mar 12 08:16:19 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 08:16:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691697.1077933 (Exim 4.92) (envelope-from ) id 1rjxJ3-0001rt-4I; Tue, 12 Mar 2024 08:16:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691697.1077933; Tue, 12 Mar 2024 08:16:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjxJ3-0001rm-16; Tue, 12 Mar 2024 08:16:17 +0000 Received: by outflank-mailman (input) for mailman id 691697; Tue, 12 Mar 2024 08:16:15 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjxJ1-0001rg-Qs for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 08:16:15 +0000 Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [2a00:1450:4864:20::631]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id cb337277-e048-11ee-afdd-a90da7624cb6; Tue, 12 Mar 2024 09:16:14 +0100 (CET) Received: by mail-ej1-x631.google.com with SMTP id a640c23a62f3a-a450bedffdfso675124366b.3 for ; Tue, 12 Mar 2024 01:16:14 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id bx4-20020a170906a1c400b00a4528658771sm3583024ejb.31.2024.03.12.01.16.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 Mar 2024 01:16:14 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: cb337277-e048-11ee-afdd-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1710231374; x=1710836174; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=zHUPVSZdHdGTzLpbsHNy6U5mXwZPXvdL9s1XdjkN5jQ=; b=HmQFMSixKpyQIxVG2IWL2v4gHISIjgXfV4/jrrQ5q8CZHeuPOHUA/7MqXSKStfc3Vq OKYxBw4Dl3dAQpf3uqfDE1kqew+SjWOXo6WuGC6Yttbr0sYiRCkz9gushd/Ae3CLtwp4 ipaiUMbF34BdeoIHBuRCrjoLUn6rfg+tw2b61k6gXL6v3btiQ7emMCCTtp3SUkXze8Re mQXNrv0bv7ARjjK5inmp+Yt5OxUsBo7y/5LoYX4j+hGsF0GcTU714w0lKjzgvkHzX4oj uI7H7W4gDESIr0Jrlq17kQZW85CCP17dKXUIGPtnSE1XN++3NhAE5Eh6+ilG4frFbFGU O2zA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710231374; x=1710836174; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=zHUPVSZdHdGTzLpbsHNy6U5mXwZPXvdL9s1XdjkN5jQ=; b=g+vlmkSKKKXcLuxG7lcyc0PE7z6C/KWOsUkE3DCUR0NEgaYRysaM0r430Byl5w4X6J Pkedp4NhjaNxKRS/D4iuA/6IrxbiYXRITfWuIJNEG3ScjYqT5n1aNNThG97dnR1bX3hM ZoRy9pzyQuGH5dcq/B29/THFSo4GxEjuVLGhuiVK0ZndSCYsUjUwnpJoZhpokMYwsniz dVLLV6UN2MfCcy7myVvM6WwXjPWxq9i466QADwo64Vjvp7MNY2q87XjG0MU5ZiMxxDN6 kx5ZkIXaHlALbc4D7hGj6kBriN9sST4G2ZrDHuuYiSZcBTOV2AT9riJOUkEPY3kAVez/ tBsA== X-Forwarded-Encrypted: i=1; AJvYcCXqx9vtGibbPDi20Nluh+/JSr8JKL5Fjs4lEFXXkR/eYpNFU3qZqJ1WgcmYGUddaTLwlZLTp3/twemTBGwhSSlyy452WtzXOTwjzs3mnRc= X-Gm-Message-State: AOJu0YzqIcZk1WgSSOywwJhRoVk5nhVIdO5vMLKAccp7tHRe2E656dUm uVE5esSGQwZVUep930waErvS2te3fRs4BCQ6U/Ze3uDab31SvBj/AdkcSRqtsw== X-Google-Smtp-Source: AGHT+IGs2MwUWq/GrdGiPqTwMy1+KOrNXuO+h8cw5hh9U+3JGieWPWXQlNtK80EZyxxw2dyA3ewx+A== X-Received: by 2002:a17:907:cb87:b0:a46:2692:a026 with SMTP id un7-20020a170907cb8700b00a462692a026mr3257769ejc.34.1710231374285; Tue, 12 Mar 2024 01:16:14 -0700 (PDT) Message-ID: Date: Tue, 12 Mar 2024 09:16:13 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH v3 05/16] xen/x86: address violations of MISRA C:2012 Directive 4.10 Content-Language: en-US To: Simone Ballarin Cc: consulting@bugseng.com, sstabellini@kernel.org, Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu , Maria Celeste Cesario , xen-devel@lists.xenproject.org References: From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 11.03.2024 09:59, Simone Ballarin wrote: > --- a/xen/arch/x86/Makefile > +++ b/xen/arch/x86/Makefile > @@ -258,18 +258,20 @@ $(obj)/asm-macros.i: CFLAGS-y += -P > $(objtree)/arch/x86/include/asm/asm-macros.h: $(obj)/asm-macros.i $(src)/Makefile > $(call filechk,asm-macros.h) > > +ARCHDIR = $(shell echo $(SRCARCH) | tr a-z A-Z) This wants to use :=, I think - there's no reason to invoke the shell ... > define filechk_asm-macros.h > + echo '#ifndef ASM_$(ARCHDIR)_ASM_MACROS_H'; \ > + echo '#define ASM_$(ARCHDIR)_ASM_MACROS_H'; \ > echo '#if 0'; \ > echo '.if 0'; \ > echo '#endif'; \ > - echo '#ifndef __ASM_MACROS_H__'; \ > - echo '#define __ASM_MACROS_H__'; \ > echo 'asm ( ".include \"$@\"" );'; \ > - echo '#endif /* __ASM_MACROS_H__ */'; \ > echo '#if 0'; \ > echo '.endif'; \ > cat $<; \ > - echo '#endif' > + echo '#endif'; \ > + echo '#endif /* ASM_$(ARCHDIR)_ASM_MACROS_H */' > endef ... three times while expanding this macro. Alternatively (to avoid an unnecessary shell invocation when this macro is never expanded at all) a shell variable inside the "define" above would want introducing. Whether this 2nd approach is better depends on whether we anticipate further uses of ARCHDIR. > --- a/xen/arch/x86/cpu/cpu.h > +++ b/xen/arch/x86/cpu/cpu.h > @@ -1,3 +1,6 @@ > +#ifndef XEN_ARCH_X86_CPU_CPU_H > +#define XEN_ARCH_X86_CPU_CPU_H > + > /* attempt to consolidate cpu attributes */ > struct cpu_dev { > void (*c_early_init)(struct cpuinfo_x86 *c); > @@ -24,3 +27,5 @@ void amd_init_lfence(struct cpuinfo_x86 *c); > void amd_init_ssbd(const struct cpuinfo_x86 *c); > void amd_init_spectral_chicken(void); > void detect_zen2_null_seg_behaviour(void); > + > +#endif /* XEN_ARCH_X86_CPU_CPU_H */ Leaving aside the earlier voiced request to get rid of the XEN_ prefixes here, ... > --- a/xen/arch/x86/x86_64/mmconfig.h > +++ b/xen/arch/x86/x86_64/mmconfig.h > @@ -5,6 +5,9 @@ > * Author: Allen Kay - adapted from linux > */ > > +#ifndef XEN_ARCH_X86_X86_64_MMCONFIG_H > +#define XEN_ARCH_X86_X86_64_MMCONFIG_H > + > #define PCI_DEVICE_ID_INTEL_E7520_MCH 0x3590 > #define PCI_DEVICE_ID_INTEL_82945G_HB 0x2770 > > @@ -72,3 +75,5 @@ int pci_mmcfg_reserved(uint64_t address, unsigned int segment, > int pci_mmcfg_arch_init(void); > int pci_mmcfg_arch_enable(unsigned int idx); > void pci_mmcfg_arch_disable(unsigned int idx); > + > +#endif /* XEN_ARCH_X86_X86_64_MMCONFIG_H */ ... in a case like this and maybe even ... > --- a/xen/arch/x86/x86_emulate/private.h > +++ b/xen/arch/x86/x86_emulate/private.h > @@ -6,6 +6,9 @@ > * Copyright (c) 2005-2007 XenSource Inc. > */ > > +#ifndef XEN_ARCH_X86_X86_EMULATE_PRIVATE_H > +#define XEN_ARCH_X86_X86_EMULATE_PRIVATE_H > + > #ifdef __XEN__ > > # include > @@ -836,3 +839,5 @@ static inline int read_ulong(enum x86_segment seg, > *val = 0; > return ops->read(seg, offset, val, bytes, ctxt); > } > + > +#endif /* XEN_ARCH_X86_X86_EMULATE_PRIVATE_H */ ... this I wonder whether they are too strictly sticking to the base scheme (or whether the base scheme itself isn't flexible enough): I'm not overly happy with the "_X86_X86_" in there. Especially in the former case, where it's the sub-arch path, like for arm/arm I'd like to see that folded to just "_X86_64_" here as well. Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 12 08:21:13 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 08:21:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691701.1077943 (Exim 4.92) (envelope-from ) id 1rjxNk-0003mC-PC; Tue, 12 Mar 2024 08:21:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691701.1077943; Tue, 12 Mar 2024 08:21:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjxNk-0003m5-Lz; Tue, 12 Mar 2024 08:21:08 +0000 Received: by outflank-mailman (input) for mailman id 691701; Tue, 12 Mar 2024 08:21:07 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjxNj-0003lz-70 for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 08:21:07 +0000 Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [2a00:1450:4864:20::234]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 78d2918f-e049-11ee-afdd-a90da7624cb6; Tue, 12 Mar 2024 09:21:06 +0100 (CET) Received: by mail-lj1-x234.google.com with SMTP id 38308e7fff4ca-2d40fe2181dso47340641fa.1 for ; Tue, 12 Mar 2024 01:21:06 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id cq15-20020a056402220f00b0056761c83bdesm3736461edb.93.2024.03.12.01.21.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 Mar 2024 01:21:05 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 78d2918f-e049-11ee-afdd-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1710231665; x=1710836465; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=M3ffPOtRcv9waHyVC3FI+fg9G66DrwjncSkxrL418Qc=; b=O7BiMrMdiLmJt6m179W2bn/Lycy7k2LvC5p94cLOaOh9OQ8JpnwENFKL1bG94uLGht Cz/k+PGBNShRTsb+SWH0ijUT6BoXXFZXaVm/2T6Ia0CPb5EHYH/qonbOlzgj3rLyUHXP Yc19q7O3EmR/XEyDtx5IWbl/FklPAFDBkGH+Qx7vmCvT0mlTjLSGP0Q7mDZyWNAJ3fwy I0sO6NnVMwrh7bMyCCqRR4cxr/TXxe23VT3TWbv0R1G3f+apfsBCpyeteT78hI5psdeO E1yRL1oV+8lNaRWXuL5zumwzXpvUpbimbh8NaOR62eY64wTifdOq8eB+IvG98E2GZ2gC ZxLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710231665; x=1710836465; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=M3ffPOtRcv9waHyVC3FI+fg9G66DrwjncSkxrL418Qc=; b=NewOHyPfkhTn3MqegbL2qBTp9/cjdUlHV+0l5bugZyvwjkD86zPCBj1gCCrymopVK0 OxMiMKlNt5VHNLVCO/dPLbYUR8sHciCvZaxs2cqSlqflkXCSIaSqC89ltMTWsIFIYlVw sWzk9x4B6dzthSy2X3mp0Wm6yhU3lU1wwqDbiHDmHpC6u5Z4lnLGZOHg7x4nQfNu62RD VreCsatEb69vvA8ESHAkl1sDsdgntY609aCKuTd9MXPxUv12opBINIENBFqCR2vMIwHs 61R94KKGWA+Hu92jo+i1foQUKCDKYq1fSIFO4wBJvvoS5NINQeVgtlWNHuq0LzbYWeqa GXOw== X-Forwarded-Encrypted: i=1; AJvYcCWZWCVgChrKpBUCme/vGHRbnB9+/5PX9Nh19KKznnmih/m7DrzctNFt0paT+6aGahrS33Jkhm+3bzjuA18qvPo2HUFJVYUVCH62UFQzSas= X-Gm-Message-State: AOJu0Ywlq6rR1XYQ9Z3gkxfX32kLfQYivTiZckQSKra37mcQjRBrvSZq vWGlIcn49xSc8vE7j3oI/1CtSUn3y2DQlKCUb+9c+jw0KJlNdxww1JNaSv6m2w== X-Google-Smtp-Source: AGHT+IH+s2A/J2VJbPM0DeuU1dBvlJN/Jku50XJd+mV8QWZKU/HXMEWLtu2m12T8I8t4gvyaqXaIVw== X-Received: by 2002:a2e:b8d4:0:b0:2d4:513d:7b34 with SMTP id s20-20020a2eb8d4000000b002d4513d7b34mr938448ljp.17.1710231665513; Tue, 12 Mar 2024 01:21:05 -0700 (PDT) Message-ID: Date: Tue, 12 Mar 2024 09:21:04 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH v3 09/16] xen: address violations of MISRA C:2012 Directive 4.10 Content-Language: en-US To: Simone Ballarin Cc: consulting@bugseng.com, sstabellini@kernel.org, Andrew Cooper , George Dunlap , Julien Grall , Wei Liu , Maria Celeste Cesario , xen-devel@lists.xenproject.org References: <504cdd2a0f27d28e0a87492f75476b123b68bbc0.1710145041.git.simone.ballarin@bugseng.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <504cdd2a0f27d28e0a87492f75476b123b68bbc0.1710145041.git.simone.ballarin@bugseng.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 11.03.2024 09:59, Simone Ballarin wrote: > Amend inclusion guards to address violations of > MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order > to prevent the contents of a header file being included more than > once"). > > Inclusion guards must appear at the beginning of the headers > (comments are permitted anywhere) and the #if directive cannot > be used for other checks. This latter restriction, even if just slightly, hampers readability > --- a/xen/include/xen/err.h > +++ b/xen/include/xen/err.h > @@ -1,5 +1,6 @@ > -#if !defined(__XEN_ERR_H__) && !defined(__ASSEMBLY__) > -#define __XEN_ERR_H__ > +#ifndef XEN_INCLUDE_XEN_ERR_H > +#define XEN_INCLUDE_XEN_ERR_H > +#ifndef __ASSEMBLY__ > > #include > #include > @@ -41,4 +42,5 @@ static inline int __must_check PTR_RET(const void *ptr) > return IS_ERR(ptr) ? PTR_ERR(ptr) : 0; > } > > -#endif /* __XEN_ERR_H__ */ > +#endif /* __ASSEMBLY__ */ > +#endif /* XEN_INCLUDE_XEN_ERR_H */ ... here, ... > --- a/xen/include/xen/softirq.h > +++ b/xen/include/xen/softirq.h > @@ -1,5 +1,6 @@ > -#if !defined(__XEN_SOFTIRQ_H__) && !defined(__ASSEMBLY__) > -#define __XEN_SOFTIRQ_H__ > +#ifndef XEN_INCLUDE_XEN_SOFTIRQ_H > +#define XEN_INCLUDE_XEN_SOFTIRQ_H > +#ifndef __ASSEMBLY__ > > /* Low-latency softirqs come first in the following list. */ > enum { > @@ -40,4 +41,5 @@ void cpu_raise_softirq_batch_finish(void); > */ > void process_pending_softirqs(void); > > -#endif /* __XEN_SOFTIRQ_H__ */ > +#endif /* __ASSEMBLY__ */ > +#endif /* XEN_INCLUDE_XEN_SOFTIRQ_H */ ... here, and ... > --- a/xen/include/xen/vmap.h > +++ b/xen/include/xen/vmap.h > @@ -1,5 +1,6 @@ > -#if !defined(__XEN_VMAP_H__) && defined(VMAP_VIRT_START) > -#define __XEN_VMAP_H__ > +#ifndef XEN_INCLUDE_XEN_VMAP_H > +#define XEN_INCLUDE_XEN_VMAP_H > +#ifdef VMAP_VIRT_START > > #include > #include > @@ -42,4 +43,5 @@ static inline void vm_init(void) > vm_init_type(VMAP_DEFAULT, (void *)VMAP_VIRT_START, arch_vmap_virt_end()); > } > > -#endif /* __XEN_VMAP_H__ */ > +#endif /* VMAP_VIRT_START */ > +#endif /* XEN_INCLUDE_XEN_VMAP_H */ ... here. Wasn't a goal of Misra to also not have negative effects on code readability? Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 12 08:33:08 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 08:33:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691706.1077955 (Exim 4.92) (envelope-from ) id 1rjxZF-0005nk-SH; Tue, 12 Mar 2024 08:33:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691706.1077955; Tue, 12 Mar 2024 08:33:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjxZF-0005nd-PT; Tue, 12 Mar 2024 08:33:01 +0000 Received: by outflank-mailman (input) for mailman id 691706; Tue, 12 Mar 2024 08:33:00 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjxZE-0005nX-IC for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 08:33:00 +0000 Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [2a00:1450:4864:20::62b]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 22086d77-e04b-11ee-afdd-a90da7624cb6; Tue, 12 Mar 2024 09:32:59 +0100 (CET) Received: by mail-ej1-x62b.google.com with SMTP id a640c23a62f3a-a45c006ab82so608221866b.3 for ; Tue, 12 Mar 2024 01:32:59 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id dv18-20020a170906b81200b00a456a97faaesm3587517ejb.86.2024.03.12.01.32.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 Mar 2024 01:32:58 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 22086d77-e04b-11ee-afdd-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1710232379; x=1710837179; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=nyEh0rQYJE6Jec/uxVqP64Ftm28yLZ08FcTzjd6KJ+M=; b=ZExSEvH7ntyB+UKAucN9E1n8StLXvrybQPTcqloJEELSnemWAe4w87geA4pM0eP+gE 2KCHIVieYYc6wTb1mOsF4kKReGuUFxj5riBRtLr2buEEZXe2a2psT9YYl/QyqY6xWRPL FjMJOiSUglAQUOo2MxoI8XZbBWC1pWxnd5OqpBbJysvfl3cgsGVd6onvwMFQrR1ehAOv P+43p5C6Y/r2JAWZcF93et8JqG7fFoZ3QvBHTki+37XO9y4P5lxp5z0kl6tkPz/XeuSV Vx3flC7jLTihsTZjzP7uQHLKNANMBk7B1xWG3lqZHOE5oSAWm+dCBA5ztLkySGrUvLrW EYcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710232379; x=1710837179; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=nyEh0rQYJE6Jec/uxVqP64Ftm28yLZ08FcTzjd6KJ+M=; b=M8rxFWvRf+S8d7QZXEA53dMij2hxA+dsdwbzw/l26KjhVG7vcG0mDqmEDgspEhIVmb 626ZxAfA1sqZaYtFUDr6BS1rK474oJ+2KOr99kgmdXXak7ej/FSk+fyn0zBwrAPE/Aft e/5zkreJUCZaoYTabf6/zqTLQyEwy2a7eeWoqCGACeSczazm3nwJQxqduauO18ioZiVZ 9xC8K/IFInhKXrFBJ6vG6+OhS1DUEsl85t4rCcVQDY5kSRH0DSVeC6GHQSurZSHaxFX0 GpYftIgBhiYOmwceVAHUH+3MxEqGr7NbIt+8vL8syygZ9Ex/cT/QaSyxwuM7fKzh/PQH lEXQ== X-Forwarded-Encrypted: i=1; AJvYcCU8tA+fzBPjyPluX7C4mkLDNWnLLERBhwHy+rSuKYRm2R4mll1PbpAvuyA7UkN32VNBJ2CNuOxPq07VCgZgHch+pPMImjG5rpzpqMfXddc= X-Gm-Message-State: AOJu0YzAgpQ5iYDC0dOwi9Rveia95AcfjfHfPCvTpz7JrJxnNdGKMW3N pqUEngmsf9Rk/nUrpmK6hClvjSLU1FpNzLrhHww4C4wAhKpstXcIQd3Fj/0lGQ== X-Google-Smtp-Source: AGHT+IFdZEXZ4dDepLONAj9MsyQZPoh/SWEdgXRy6Ic73JdAEwCJejRKx+gzCSWmKpzDHi5J66+PbQ== X-Received: by 2002:a17:907:c315:b0:a45:547a:49e1 with SMTP id tl21-20020a170907c31500b00a45547a49e1mr2460285ejc.3.1710232378975; Tue, 12 Mar 2024 01:32:58 -0700 (PDT) Message-ID: <40dffd72-0362-42bc-b4c8-9a26804fed68@suse.com> Date: Tue, 12 Mar 2024 09:32:57 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH v3 10/16] x86/asm: address violations of MISRA C:2012 Directive 4.10 Content-Language: en-US To: Simone Ballarin Cc: consulting@bugseng.com, sstabellini@kernel.org, Andrew Cooper , George Dunlap , Julien Grall , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Maria Celeste Cesario , xen-devel@lists.xenproject.org References: <1e44047e767431c32621ae44d3121bc2152b3cb5.1710145041.git.simone.ballarin@bugseng.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <1e44047e767431c32621ae44d3121bc2152b3cb5.1710145041.git.simone.ballarin@bugseng.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 11.03.2024 09:59, Simone Ballarin wrote: > --- a/docs/misra/safe.json > +++ b/docs/misra/safe.json > @@ -52,6 +52,14 @@ > }, > { > "id": "SAF-6-safe", > + "analyser": { > + "eclair": "MC3R1.D4.10" > + }, > + "name": "Dir 4.10: file intended for multiple inclusion", > + "text": "Files intended for multiple inclusion are not supposed to comply with D4.10." > + }, There's an overlap with SAF-3-safe as added by patch 01. What's the reason separate entries are needed? > --- a/xen/arch/x86/include/asm/compat.h > +++ b/xen/arch/x86/include/asm/compat.h > @@ -2,6 +2,9 @@ > * compat.h > */ > > +#ifndef ASM_X86_COMPAT_H > +#define ASM_X86_COMPAT_H > + > #ifdef CONFIG_COMPAT > > #define COMPAT_BITS_PER_LONG 32 > @@ -18,3 +21,5 @@ int switch_compat(struct domain *); > #include > static inline int switch_compat(struct domain *d) { return -EOPNOTSUPP; } > #endif > + > +#endif /* ASM_X86_COMPAT_H */ I'd be happy to ack this change; once again an indication that dissimilar changes would better not be munged in a single patch. Such a patch, btw, also shouldn't come with "x86/asm:" as a subject prefix - there's nothing assembly-ish here; asm/ as a directory name is Linux heritage, without that being a "component" in any way. > --- a/xen/arch/x86/include/asm/cpufeatures.h > +++ b/xen/arch/x86/include/asm/cpufeatures.h > @@ -1,7 +1,4 @@ > -/* > - * Explicitly intended for multiple inclusion. > - */ > - > +/* SAF-6-safe file intended for multiple inclusion */ > #include With the blank line removed the comment, by convention of how these comments are placed, applies to the #include directive, which is wrong. > --- a/xen/arch/x86/include/asm/efibind.h > +++ b/xen/arch/x86/include/asm/efibind.h > @@ -1,2 +1,7 @@ > +#ifndef ASM_X86_EFIBIND_H > +#define ASM_X86_EFIBIND_H > + > #include > #include > + > +#endif /* ASM_X86_EFIBIND_H */ This could go with the compat.h change above. > --- a/xen/include/Makefile > +++ b/xen/include/Makefile > @@ -104,10 +104,16 @@ $(obj)/compat/.xlat/%.lst: $(srcdir)/xlat.lst FORCE > xlat-y := $(shell sed -ne 's,@arch@,$(compat-arch-y),g' -re 's,^[?!][[:blank:]]+[^[:blank:]]+[[:blank:]]+,,p' $(srcdir)/xlat.lst | uniq) > xlat-y := $(filter $(patsubst compat/%,%,$(headers-y)),$(xlat-y)) > > +ARCHDIR = $(shell echo $(SRCARCH) | tr a-z A-Z) Didn't the earlier patch introduce ARCHDIR already, just elsewhere? This would better be done once in a central place then, maybe in scripts/Kbuild.include. > quiet_cmd_xlat_h = GEN $@ > -cmd_xlat_h = \ > - cat $(filter %.h,$^) >$@.new; \ > +define cmd_xlat_h > + echo "#ifndef ASM_$(ARCHDIR)_COMPAT_XLAT_H" > $@.new; \ > + echo "#define ASM_$(ARCHDIR)_COMPAT_XLAT_H" >> $@.new; \ > + cat $(filter %.h,$^) >> $@.new; \ > + echo "#endif /* ASM_$(ARCHDIR)_COMPAT_XLAT_H */" >> $@.new; \ > mv -f $@.new $@ > +endef I'm unclear about the move from "=" to "define". Readability isn't really helped, is it? Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 12 10:00:35 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 10:00:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691725.1077965 (Exim 4.92) (envelope-from ) id 1rjyve-00018J-Ql; Tue, 12 Mar 2024 10:00:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691725.1077965; Tue, 12 Mar 2024 10:00:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjyve-00018C-O5; Tue, 12 Mar 2024 10:00:14 +0000 Received: by outflank-mailman (input) for mailman id 691725; Tue, 12 Mar 2024 10:00:13 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjyvd-000186-4c for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 10:00:13 +0000 Received: from mail137-23.atl71.mandrillapp.com (mail137-23.atl71.mandrillapp.com [198.2.137.23]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 4fc65b14-e057-11ee-a1ee-f123f15fe8a2; Tue, 12 Mar 2024 11:00:10 +0100 (CET) Received: from pmta07.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail137-23.atl71.mandrillapp.com (Mailchimp) with ESMTP id 4Tv8Jk3fQMz1XLJMM for ; Tue, 12 Mar 2024 10:00:06 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id c951a183e47448219ca972096574c410; Tue, 12 Mar 2024 10:00:06 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 4fc65b14-e057-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1710237606; x=1710498106; bh=jamJqCRaVrxTDYTLaUvwcJ+2xZOIKW+B0yNDJy6preA=; h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=T1D0lQ25kMuY9LkuIU+Zh+AMkhIZ2B82YTk2JIy2HumytcRfkqBIudeWd2He+YwEW kjUQQdqpf8oTf55MLu91J1nkm/OY6LFMbmcJYHi2U2FfryhBZo3tJI9E79qBFoEUoD EBNI13f2icIyne+NjgmccI+55CJklJh5j2if/QSSjrB5JTEZ2cvNbliacxxw+z2BS9 DtqC+3/yQrzcyvzUMRhIEJ88G1RaNU9KWM0pRyztHljcjXqAIuiPt/UbmAfTIgl/34 Aq9/GiK+tvhckpdMQa6REMo2HBPvsVK0fE+ID69V/Y6WjlfVfKO40PTIlo4bPFLr54 6l2yoXt6vni5A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1710237606; x=1710498106; i=vaishali.thakkar@vates.tech; bh=jamJqCRaVrxTDYTLaUvwcJ+2xZOIKW+B0yNDJy6preA=; h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=Ts+0MkoKB/NyNOIPGbHbXAmgU6l1guYoSOFqowraCruPG3Dx5kbPI1wz+AuXEtJwy 0sAfC+9BDdcKdI2WV23pY5llG79IW9cFsHM7/G+Fg8pF7rElJ65fT3PeLiccFNAr6r pvz+O2OGMPW8cp9WLQKn5ASK7L2naKDLaelSGXiEXaEFesqajIZSjVnri5xCL5ket3 SW7Qdp2OEYHyfTcqfmN8VVZ7JnzGgjwR0hT6/pSOAnQmRUsMytxjJcUEqhakKd2zBM Tu+4YAbNWo75RXK+t16yO0HBxOM0FjFCulEiRCAdGWCIPYIXO/C0EytMIykJ0d0TJf yAX6gT/lTF0UQ== From: Vaishali Thakkar Subject: =?utf-8?Q?Re:=20[PATCH=20v2=201/3]=20x86/svm:=20Drop=20the=20=5Fenabled=20suffix=20from=20vmcb=20bits?= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1710237605414 Message-Id: <5dd4007d-f273-4e43-add6-a77f0459fc33@vates.tech> To: Jan Beulich Cc: andrew.cooper3@citrix.com, roger.pau@citrix.com, wl@xen.org, xen-devel@lists.xenproject.org References: <8e6d8cac54ca05f1202580b574c548e08988d8f6.1710149462.git.vaishali.thakkar@vates.tech> <1c67a337-e9d5-4e4a-91d5-3c935c410cda@suse.com> In-Reply-To: <1c67a337-e9d5-4e4a-91d5-3c935c410cda@suse.com> X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.c951a183e47448219ca972096574c410?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20240312:md Date: Tue, 12 Mar 2024 10:00:06 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 3/12/24 08:54, Jan Beulich wrote: > On 11.03.2024 13:40, Vaishali Thakkar wrote: >> --- a/xen/arch/x86/hvm/svm/nestedsvm.c >> +++ b/xen/arch/x86/hvm/svm/nestedsvm.c >> @@ -571,7 +571,7 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct cpu_user_regs *regs) >> if ( nestedhvm_paging_mode_hap(v) ) >> { >> /* host nested paging + guest nested paging. */ >> - n2vmcb->_np_enable = 1; >> + n2vmcb->_np = true; >> >> nestedsvm_vmcb_set_nestedp2m(v, ns_vmcb, n2vmcb); >> >> @@ -585,7 +585,7 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct cpu_user_regs *regs) >> else if ( paging_mode_hap(v->domain) ) >> { >> /* host nested paging + guest shadow paging. */ >> - n2vmcb->_np_enable = 1; >> + n2vmcb->_np = true; >> /* Keep h_cr3 as it is. */ >> n2vmcb->_h_cr3 = n1vmcb->_h_cr3; >> /* When l1 guest does shadow paging >> @@ -601,7 +601,7 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct cpu_user_regs *regs) >> else >> { >> /* host shadow paging + guest shadow paging. */ >> - n2vmcb->_np_enable = 0; >> + n2vmcb->_np = false; >> n2vmcb->_h_cr3 = 0x0; >> >> /* TODO: Once shadow-shadow paging is in place come back to here >> @@ -706,7 +706,7 @@ nsvm_vcpu_vmentry(struct vcpu *v, struct cpu_user_regs *regs, >> } >> >> /* nested paging for the guest */ >> - svm->ns_hap_enabled = !!ns_vmcb->_np_enable; >> + svm->ns_hap_enabled = ns_vmcb->_np; >> >> /* Remember the V_INTR_MASK in hostflags */ >> svm->ns_hostflags.fields.vintrmask = !!ns_vmcb->_vintr.fields.intr_masking; >> @@ -1084,7 +1084,7 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs) >> if ( nestedhvm_paging_mode_hap(v) ) >> { >> /* host nested paging + guest nested paging. */ >> - ns_vmcb->_np_enable = n2vmcb->_np_enable; >> + ns_vmcb->_np = n2vmcb->_np; >> ns_vmcb->_cr3 = n2vmcb->_cr3; >> /* The vmcb->h_cr3 is the shadowed h_cr3. The original >> * unshadowed guest h_cr3 is kept in ns_vmcb->h_cr3, >> @@ -1093,7 +1093,7 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs) >> else if ( paging_mode_hap(v->domain) ) >> { >> /* host nested paging + guest shadow paging. */ >> - ns_vmcb->_np_enable = 0; >> + ns_vmcb->_np = false; >> /* Throw h_cr3 away. Guest is not allowed to set it or >> * it can break out, otherwise (security hole!) */ >> ns_vmcb->_h_cr3 = 0x0; >> @@ -1104,7 +1104,7 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs) >> else >> { >> /* host shadow paging + guest shadow paging. */ >> - ns_vmcb->_np_enable = 0; >> + ns_vmcb->_np = false; >> ns_vmcb->_h_cr3 = 0x0; >> /* The vmcb->_cr3 is the shadowed cr3. The original >> * unshadowed guest cr3 is kept in ns_vmcb->_cr3, > > While spotting the small issue below it occurred to me: Why is it that > vmcb_set_...() is open-coded everywhere here? I think this would be > pretty nice to avoid at the same time (for lines touched anyway, or in > a separate prereq patch, or alternatively [and only ideally] for all > other instances in a follow-on patch). Thoughts? Yes, I noticed this too. My plan was to send a followup patch for fixing all the instances where vmcb_set/get_...() can be used. There are bunch of other vmcb bits (apart from the ones being handled in this patchset) in this file and in svm.c which can benefit from using VMCB accessors. >> --- a/xen/arch/x86/hvm/svm/svm.c >> +++ b/xen/arch/x86/hvm/svm/svm.c >> @@ -473,7 +473,7 @@ static int svm_vmcb_restore(struct vcpu *v, struct hvm_hw_cpu *c) >> >> if ( paging_mode_hap(v->domain) ) >> { >> - vmcb_set_np_enable(vmcb, 1); >> + vmcb_set_np(vmcb, 1); > > No switching to "true" here? (If the answer to the other question is > "No" for whatever reason, I'd nevertheless like to see this on adjusted, > which could then be done while committing.) Sorry, I missed this instance. I'll fix it if I'll need to send another revised patchset for some other fixes (based on review comments), else feel free to fix it while committing. Thanks. > Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 12 10:08:20 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 10:08:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691729.1077975 (Exim 4.92) (envelope-from ) id 1rjz3R-0001lM-FK; Tue, 12 Mar 2024 10:08:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691729.1077975; Tue, 12 Mar 2024 10:08:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjz3R-0001lF-Ck; Tue, 12 Mar 2024 10:08:17 +0000 Received: by outflank-mailman (input) for mailman id 691729; Tue, 12 Mar 2024 10:08:15 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjz3P-0001l9-Dq for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 10:08:15 +0000 Received: from mail133-16.atl131.mandrillapp.com (mail133-16.atl131.mandrillapp.com [198.2.133.16]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 6f4147fa-e058-11ee-a1ee-f123f15fe8a2; Tue, 12 Mar 2024 11:08:13 +0100 (CET) Received: from pmta13.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail133-16.atl131.mandrillapp.com (Mailchimp) with ESMTP id 4Tv8V33GY1zB5p4vG for ; Tue, 12 Mar 2024 10:08:11 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id e0264480b4df41e9934ae9d6d774cbc8; Tue, 12 Mar 2024 10:08:11 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6f4147fa-e058-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1710238091; x=1710498591; bh=F4s+Q7mYVMULGFUgbUAro53sgX2Q4nrhzoTwtJES9xA=; h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=l7kqq+PYylSEQ5e75EGCK7sbuQc79OwQedHMDMZsO400LeRAYod79mr9hvUeTytK4 eJUBUfH9so2SU5QnajkvZ7YpaZJdj2PAD6AyfKJkUZyTG3sjHnKk626UH57A7V54Mv cnCjEUFDSegi8x62JqHG2ayFFKNSX2yTwpzjr4pXBh082YD5uPQ7XJX8LDQl8ftrDM u4+QlkbKtgWyxlP8tcAYR0GaRd6CmfO1zVUQmLJfRJmRwIzog+0wXHQuY/uvEUFSoa 0wdJROFn2ZlXhAkUzNFzWYH+6iLxiO2i3zQRo7My7W5E++C2U+jtG48BUKGThFWta6 OqgEsELumIQeg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1710238091; x=1710498591; i=vaishali.thakkar@vates.tech; bh=F4s+Q7mYVMULGFUgbUAro53sgX2Q4nrhzoTwtJES9xA=; h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=J2T/4UKefmEOX0pBRd2Qp+7GjAGmKH+iLM0WRz4KsP2mDs4wZSUh0KI5wiI4HOXdi Tybxcf78YPnlWop3gUW2kGrCuxAkoOuQbyYSVFDDNWiW1VOMiZ7UnEEDafqQF1XPmN LyQFz/VomasjKU+3ImNpOJ4HSV8ErrvDGtjcr0SRv2LBE5jPXm/L7pkbJjw57xihkU qrHqdPwZ4sADHp8Ga9iJUMczVjgJXOeJfSojPC86xFZ3Kerq/l/3PzixXMJdIysQk9 NY3QOystv+BOjPRa/FbmLdmh7A1TIobhvkyjBWfgI/BWShOG1bzrawSiKHkOCygic1 zJBRxsukH3gAg== From: Vaishali Thakkar Subject: =?utf-8?Q?Re:=20[PATCH=20v2=202/3]=20x86/svm:=20Drop=20the=20suffix=20=5Fguest=20from=20vmcb=20bit?= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1710238090188 Message-Id: To: Jan Beulich Cc: andrew.cooper3@citrix.com, roger.pau@citrix.com, wl@xen.org, xen-devel@lists.xenproject.org References: In-Reply-To: X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.e0264480b4df41e9934ae9d6d774cbc8?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20240312:md Date: Tue, 12 Mar 2024 10:08:11 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 3/12/24 08:59, Jan Beulich wrote: > On 11.03.2024 13:40, Vaishali Thakkar wrote: >> @@ -698,11 +698,11 @@ nsvm_vcpu_vmentry(struct vcpu *v, struct cpu_user_regs *regs, >> /* Convert explicitely to boolean. Deals with l1 guests >> * that use flush-by-asid w/o checking the cpuid bits */ >> nv->nv_flushp2m = !!ns_vmcb->tlb_control; >> - if ( svm->ns_guest_asid != ns_vmcb->_guest_asid ) >> + if ( svm->ns_asid != ns_vmcb->_asid ) >> { >> nv->nv_flushp2m = 1; >> hvm_asid_flush_vcpu_asid(&vcpu_nestedhvm(v).nv_n2asid); >> - svm->ns_guest_asid = ns_vmcb->_guest_asid; >> + svm->ns_asid = ns_vmcb->_asid; >> } >> >> /* nested paging for the guest */ >> @@ -1046,7 +1046,7 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs) >> /* Keep it. It's maintainted by the l1 guest. */ >> >> /* ASID */ >> - /* ns_vmcb->_guest_asid = n2vmcb->_guest_asid; */ >> + /* ns_vmcb->_asid = n2vmcb->_asid; */ > > Unlike in the earlier patch, where I could accept the request to switch > to using accessor functions as scope-creep-ish, here I'm pretty firm > with my request to stop their open-coding at the same time. Unless of > course there's a technical reason the accessors cannot be used here. Yes, so as mentioned in the other patch's reply, I plan to tackle this instance too in the followup patchset along with others. So, if you're fine with it, I'll leave this one here for now. Unless you prefer otherwise. > Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 12 10:22:14 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 10:22:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691733.1077985 (Exim 4.92) (envelope-from ) id 1rjzGr-0004Wz-Ob; Tue, 12 Mar 2024 10:22:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691733.1077985; Tue, 12 Mar 2024 10:22:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjzGr-0004Ws-M1; Tue, 12 Mar 2024 10:22:09 +0000 Received: by outflank-mailman (input) for mailman id 691733; Tue, 12 Mar 2024 10:22:08 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjzGq-0004Wk-Iq for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 10:22:08 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjzGp-0006ct-TK; Tue, 12 Mar 2024 10:22:07 +0000 Received: from [15.248.3.90] (helo=[10.24.67.26]) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1rjzGp-0006kc-LH; Tue, 12 Mar 2024 10:22:07 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID; bh=OYPc1rI6cazjN4G1VMzOnQcjU4zsryqByt7pQaUumH8=; b=MWphzdiFpdLTMwqJ6CH4zfa57q ecKosglvz/MWQHCJROqxD7p+N1eP5tYXP59JrbPED5Nb0QFsvUcrwD2/XSePLzWflvQDfJwNvOsW8 nsZM8L/ta3yfaqu+EwLw97ZehgqsN6s2tucnG74TQKwC9ejOOcv4Momn1kzNdVHe1VxY=; Message-ID: <045b1170-56f1-4194-858a-9f4aecfd15ec@xen.org> Date: Tue, 12 Mar 2024 10:22:05 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH v3 09/16] xen: address violations of MISRA C:2012 Directive 4.10 Content-Language: en-GB To: Simone Ballarin , xen-devel@lists.xenproject.org Cc: consulting@bugseng.com, sstabellini@kernel.org, Andrew Cooper , George Dunlap , Jan Beulich , Wei Liu , Maria Celeste Cesario References: <504cdd2a0f27d28e0a87492f75476b123b68bbc0.1710145041.git.simone.ballarin@bugseng.com> From: Julien Grall In-Reply-To: <504cdd2a0f27d28e0a87492f75476b123b68bbc0.1710145041.git.simone.ballarin@bugseng.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Simone, On 11/03/2024 08:59, Simone Ballarin wrote: > Amend inclusion guards to address violations of > MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order > to prevent the contents of a header file being included more than > once"). > > Inclusion guards must appear at the beginning of the headers > (comments are permitted anywhere) and the #if directive cannot > be used for other checks. > > Mechanical change. > > Signed-off-by: Simone Ballarin > Signed-off-by: Maria Celeste Cesario Regarding Jan's comment, I don't have any strong opinion on whether this patch impair readability in this case. So: Acked-by: Julien Grall Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Tue Mar 12 10:24:50 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 10:24:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691735.1077995 (Exim 4.92) (envelope-from ) id 1rjzJS-00054d-4M; Tue, 12 Mar 2024 10:24:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691735.1077995; Tue, 12 Mar 2024 10:24:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjzJS-00054W-1n; Tue, 12 Mar 2024 10:24:50 +0000 Received: by outflank-mailman (input) for mailman id 691735; Tue, 12 Mar 2024 10:24:48 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjzJQ-00054Q-J0 for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 10:24:48 +0000 Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [2607:f8b0:4864:20::833]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id bf63d273-e05a-11ee-a1ee-f123f15fe8a2; Tue, 12 Mar 2024 11:24:46 +0100 (CET) Received: by mail-qt1-x833.google.com with SMTP id d75a77b69052e-42f2009e559so39169471cf.0 for ; Tue, 12 Mar 2024 03:24:46 -0700 (PDT) Received: from localhost ([213.195.118.74]) by smtp.gmail.com with ESMTPSA id v13-20020a05622a144d00b0042f09f01fc5sm3605042qtx.59.2024.03.12.03.24.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Mar 2024 03:24:44 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: bf63d273-e05a-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1710239085; x=1710843885; darn=lists.xenproject.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=g10mt9fmav6B3gWf5WI149xekOm7KtFu5UaQ24GsQBw=; b=uD3+0pqNYHEPaC82S7n/3Q7Lqu0srJjx5DkqLdSqToxhCJPJpk6lxIA0MPec/DJU73 1yDosnxwv10AS0r5Cs3b6Rp7539I7qj7CYW5Br8elvYktimB7plj7ZQWaXXtz/PErLcH vAh8SwsjyOszwDJyBRglKJGaQWEmKcaTpzH6E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710239085; x=1710843885; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=g10mt9fmav6B3gWf5WI149xekOm7KtFu5UaQ24GsQBw=; b=qalCHE9QT/oaZhWcTh8eaFgTuhq5P+zII/vVMvw4LGF2K2GPlc13RLLowSIovZMnVQ rR5yVMFPDX/RIeobDzzXyBkq+Yb0B00MMUr+5yYJEoHQsi3DfJ4/EBuXuEtWqQUDfI9w XLnGTDR+eTmrTAvJCmPED+piCc8D4PZqZzSLRlj9PfSYpzfYTl1s0KEYjmVLsrzRM9Us L+z4MeZ30fd7yujWK8P7b+0vCp5Teu5poBJt9UR/1q5gPyLq6HN52aiXlJnh/c2SnP5X PdJ5G355qgIAaJQShcK4hQT6drn5L3d1/7amdcErxH6I6IzlX8oGJbyPpKYYQQ0O6ush O2wQ== X-Gm-Message-State: AOJu0YyXeDe687QvnrTe/1kFPKjDcdDWtt50Lh/HleP9/fOqABeZv0qk tbP1bcPC/MUfkrrU9og0z9R5ccAoDf1Usu9X5IB7TTzPITzQvlxkNXNxD31o2tc= X-Google-Smtp-Source: AGHT+IFjUZa2g+oIG3wLAueq51RDtTCE+l7Oc6t/FV3WT6CSsP6dAm+9JZ+Xd2D5rECyFfTT060u5w== X-Received: by 2002:ac8:5c02:0:b0:42e:fa89:14b7 with SMTP id i2-20020ac85c02000000b0042efa8914b7mr14610904qti.15.1710239085226; Tue, 12 Mar 2024 03:24:45 -0700 (PDT) Date: Tue, 12 Mar 2024 11:24:42 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= Cc: xen-devel@lists.xenproject.org, Jan Beulich , Andrew Cooper , Wei Liu , George Dunlap , Julien Grall , Stefano Stabellini Subject: Re: [PATCH] drivers/char: mark XHCI DMA buffers reserved in memory map Message-ID: References: <20240311203431.342530-1-marmarek@invisiblethingslab.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20240311203431.342530-1-marmarek@invisiblethingslab.com> On Mon, Mar 11, 2024 at 09:33:11PM +0100, Marek Marczykowski-Górecki wrote: > The IOMMU driver checks if RMRR/IVMD are marked as reserved in memory > map. This should be true for addresses coming from the firmware, but > when extra pages used by Xen itself are included in the mapping, those > are taken from usable RAM used. Mark those pages as reserved too. > > Not marking the pages as reserved didn't caused issues before due to > another a bug in IOMMU driver code, that was fixed in 83afa3135830 > ("amd-vi: fix IVMD memory type checks"). > > Failing to reserve memory will lead to panic in IOMMU setup code. And > not including the page in IOMMU mapping will lead to broken console (on > due to IOMMU faults). Handling failure with panic() isn't the most user > friendly thing, but at this stage the alternative would require undoing > a lot of console init. Since the user can do it much easier - by simply > not enabling xhci console next time, say that and panic. > > Fixes: 3a1a7b809ffa "drivers/char: mark DMA buffers as reserved for the XHCI" > Signed-off-by: Marek Marczykowski-Górecki > --- > As an alternative implementation I have considered changing > iommu_get_extra_reserved_device_memory() to modify memory map. But that > may hide (or cause) some other issues when this API will gain some more > users in the future. > > The reserve_e820_ram() is x86-specific. Is there some equivalent API for > ARM, or maybe even some abstract one? That said, I have no way to test > XHCI console on ARM, I don't know if such hardware even exists... > --- > xen/arch/x86/setup.c | 3 +++ > xen/drivers/char/xhci-dbc.c | 22 ++++++++++++++++++++++ > xen/include/xen/serial.h | 2 ++ > 3 files changed, 27 insertions(+) > > diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c > index a21984b1ccd8..8ab89b3710ed 100644 > --- a/xen/arch/x86/setup.c > +++ b/xen/arch/x86/setup.c > @@ -1806,6 +1806,9 @@ void asmlinkage __init noreturn __start_xen(unsigned long mbi_p) > mmio_ro_ranges = rangeset_new(NULL, "r/o mmio ranges", > RANGESETF_prettyprint_hex); > > + /* Needs to happen after E820 processing but before IOMMU init */ > + xhci_dbc_uart_reserve_ram(); Overall it might be better if some generic solution for all users of iommu_add_extra_reserved_device_memory() could be implemented, but I'm unsure whether the intention is for the interface to always be used against RAM. > xsm_multiboot_init(module_map, mbi); > > /* > diff --git a/xen/drivers/char/xhci-dbc.c b/xen/drivers/char/xhci-dbc.c > index 3bf389be7d0b..e31f3cba7838 100644 > --- a/xen/drivers/char/xhci-dbc.c > +++ b/xen/drivers/char/xhci-dbc.c > @@ -31,6 +31,9 @@ > #include > #include > #include > +#ifdef CONFIG_X86 > +#include > +#endif > > /* uncomment to have dbc_uart_dump() debug function */ > /* #define DBC_DEBUG 1 */ > @@ -1426,6 +1429,25 @@ void __init xhci_dbc_uart_init(void) > } > } > > +void __init xhci_dbc_uart_reserve_ram(void) > +{ > + struct dbc *dbc = &dbc_uart.dbc; const. Or seeing as it's used only once you could just use dbc_uart.dbc.enable. > + > + if ( !dbc->enable ) > + return; > + > +#ifdef CONFIG_X86 > + if ( !reserve_e820_ram( > + &e820, > + virt_to_maddr(&dbc_dma_bufs), > + virt_to_maddr(&dbc_dma_bufs) + sizeof(dbc_dma_bufs) - 1) ) It would be best to align this up: PAGE_ALIGN(virt_to_maddr(&dbc_dma_bufs) + sizeof(dbc_dma_bufs)) The '- 1' is wrong, as reserve_e820_ram() expects a non-inclusive end parameter. > + panic("Failed to reserve XHCI DMA buffers (%"PRIx64"-%"PRIx64"), " We usually represent inclusive memory ranges as "[%lx, %lx]". > + "disable xhci console to work around\n", > + virt_to_maddr(&dbc_dma_bufs), > + virt_to_maddr(&dbc_dma_bufs) + sizeof(dbc_dma_bufs) - 1); > +#endif > +} Won't it be best to make the whole function guarded by CONFIG_X86? So that attempts to use it on !X86 will get a build failure and clearly notice some work is needed in order to use the function on other arches? Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Tue Mar 12 10:27:07 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 10:27:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691739.1078005 (Exim 4.92) (envelope-from ) id 1rjzLd-0005d3-FK; Tue, 12 Mar 2024 10:27:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691739.1078005; Tue, 12 Mar 2024 10:27:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjzLd-0005cw-CZ; Tue, 12 Mar 2024 10:27:05 +0000 Received: by outflank-mailman (input) for mailman id 691739; Tue, 12 Mar 2024 10:27:04 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjzLc-0005cq-MV for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 10:27:04 +0000 Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [2a00:1450:4864:20::52b]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 10f48ede-e05b-11ee-a1ee-f123f15fe8a2; Tue, 12 Mar 2024 11:27:02 +0100 (CET) Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-56829f41f81so5929090a12.2 for ; Tue, 12 Mar 2024 03:27:02 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id e20-20020a056402149400b00568229390f2sm3848964edv.70.2024.03.12.03.27.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 Mar 2024 03:27:01 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 10f48ede-e05b-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1710239222; x=1710844022; darn=lists.xenproject.org; h=content-transfer-encoding:autocrypt:content-language:cc:to:subject :from:user-agent:mime-version:date:message-id:from:to:cc:subject :date:message-id:reply-to; bh=QyyVWKQYvsrBwxAWlOdMNIERUxfrCBr902msAjkZoyE=; b=UgG4adGVT0j6UdhYfZAHPyl0AxdKkbaJXPnLbeo7WBEjBjD3LREiVx3ZdFOLiphIxr ZSVcTnpaf59UJxiIdp3NPZ9g04k3yZDngIoIO6qRSW0UPEos7YqT7faN6dR+VAio9G2U IPQ+SaSjSs2BMXuzatDN6RGM7mYE7B0wRwSNH5YFfl5UtVNmb/rJc1QYI3ouHSoOov/9 0/u0ElDtxljhLT2a25dXTnrp8S1FnAVqb/JhrXro0zEjnS7a5p1KnhLHgMlYiGB7P9Iv spGgEF0y+VnJh5i88ejZStFLrGafC1GOpwn2B+K94vkJ1QFHeX6CkmurJxv5NlU1pMBZ uc4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710239222; x=1710844022; h=content-transfer-encoding:autocrypt:content-language:cc:to:subject :from:user-agent:mime-version:date:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=QyyVWKQYvsrBwxAWlOdMNIERUxfrCBr902msAjkZoyE=; b=WM0rB9IkiuxSec6Ble5hAS1ZcDbISIDuxDs9DCyNLZS7NotW2MQ4y2OLuG1kD8Mi7H Rx/Dz+VXmf2iUepWHVBt/Wl5tO0ZX3ntGiLWOqhyw5NRrpyCDy0jz7eQYyp22925KZau W7Zbu7nBedIYM3Wz1VwME4QeenYMiNGScyTTZAT1sfusH7/j5ySCRA/pVSPWdM/fLS6P 6q1A0LmyjmTymFWj8jREhwA9bs4x+TbCgrEgUgjAfC3MyaZXsyhoWc+Dt3MSe30km7ws 2H2PXU2kIYXahS3VpgMxEtp2ZmxXImDjO3hvbzsdtHqPkNHlMNmdUahEF0zuuHMbRc4N 6glw== X-Gm-Message-State: AOJu0YxpICkaAoOQoaggxPlB80ZvFyr6lROC8S+ApLdlc/oLetUuMpjJ N6+SucbFhB6AZramEbG+vilvFdvN2k7cZjaljnlMMh8p+dJZvGhJkgafRbl2AtMX5XCE5pu5Bak = X-Google-Smtp-Source: AGHT+IG0Tzn0nErONZTRjvk4Jc/alLfKl3YZMvM2TgOr6agzJNzeTL7WOEouD3ZjP7DeWwQsh98z2w== X-Received: by 2002:a50:d6c2:0:b0:568:1445:c32b with SMTP id l2-20020a50d6c2000000b005681445c32bmr5953612edj.25.1710239222225; Tue, 12 Mar 2024 03:27:02 -0700 (PDT) Message-ID: Date: Tue, 12 Mar 2024 11:27:01 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Jan Beulich Subject: [PATCH v2] x86+Arm: drop (rename) __virt_to_maddr() / __maddr_to_virt() To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Julien Grall , Stefano Stabellini , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel , Oleksii Kurochko Content-Language: en-US Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit There's no use of them anymore except in the definitions of the non- underscore-prefixed aliases. On Arm convert the (renamed) inline function to a macro. On x86 rename the inline functions, adjust the virt_to_maddr() #define, and purge the maddr_to_virt() one, thus eliminating a bogus cast which would have allowed the passing of a pointer type variable into maddr_to_virt() to go silently. No functional change intended. Signed-off-by: Jan Beulich Reviewed-by: Oleksii Kurochko --- v2: Avoid aliasing macro on Arm. --- a/xen/arch/arm/include/asm/mm.h +++ b/xen/arch/arm/include/asm/mm.h @@ -256,12 +256,10 @@ static inline void __iomem *ioremap_wc(p /* Page-align address and convert to frame number format */ #define paddr_to_pfn_aligned(paddr) paddr_to_pfn(PAGE_ALIGN(paddr)) -static inline paddr_t __virt_to_maddr(vaddr_t va) -{ - uint64_t par = va_to_par(va); - return (par & PADDR_MASK & PAGE_MASK) | (va & ~PAGE_MASK); -} -#define virt_to_maddr(va) __virt_to_maddr((vaddr_t)(va)) +#define virt_to_maddr(va) ({ \ + vaddr_t va_ = (vaddr_t)(va); \ + (va_to_par(va_) & PADDR_MASK & PAGE_MASK) | (va_ & ~PAGE_MASK); \ +}) #ifdef CONFIG_ARM_32 /** --- a/xen/arch/x86/hvm/nestedhvm.c +++ b/xen/arch/x86/hvm/nestedhvm.c @@ -125,7 +125,7 @@ static int __init cf_check nestedhvm_set /* shadow_io_bitmaps can't be declared static because * they must fulfill hw requirements (page aligned section) * and doing so triggers the ASSERT(va >= XEN_VIRT_START) - * in __virt_to_maddr() + * in virt_to_maddr() * * So as a compromise pre-allocate them when xen boots. * This function must be called from within start_xen() when --- a/xen/arch/x86/include/asm/page.h +++ b/xen/arch/x86/include/asm/page.h @@ -269,8 +269,6 @@ void copy_page_sse2(void *to, const void #define mfn_valid(mfn) __mfn_valid(mfn_x(mfn)) #define virt_to_mfn(va) __virt_to_mfn(va) #define mfn_to_virt(mfn) __mfn_to_virt(mfn) -#define virt_to_maddr(va) __virt_to_maddr((unsigned long)(va)) -#define maddr_to_virt(ma) __maddr_to_virt((unsigned long)(ma)) #define maddr_to_page(ma) __maddr_to_page(ma) #define page_to_maddr(pg) __page_to_maddr(pg) #define virt_to_page(va) __virt_to_page(va) --- a/xen/arch/x86/include/asm/x86_64/page.h +++ b/xen/arch/x86/include/asm/x86_64/page.h @@ -34,7 +34,7 @@ static inline unsigned long canonicalise #define pdx_to_virt(pdx) ((void *)(DIRECTMAP_VIRT_START + \ ((unsigned long)(pdx) << PAGE_SHIFT))) -static inline unsigned long __virt_to_maddr(unsigned long va) +static inline unsigned long virt_to_maddr(unsigned long va) { ASSERT(va < DIRECTMAP_VIRT_END); if ( va >= DIRECTMAP_VIRT_START ) @@ -47,8 +47,9 @@ static inline unsigned long __virt_to_ma return xen_phys_start + va - XEN_VIRT_START; } +#define virt_to_maddr(va) virt_to_maddr((unsigned long)(va)) -static inline void *__maddr_to_virt(unsigned long ma) +static inline void *maddr_to_virt(unsigned long ma) { /* Offset in the direct map, accounting for pdx compression */ unsigned long va_offset = maddr_to_directmapoff(ma); From xen-devel-bounces@lists.xenproject.org Tue Mar 12 10:33:32 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 10:33:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691743.1078016 (Exim 4.92) (envelope-from ) id 1rjzRn-0007Oy-4C; Tue, 12 Mar 2024 10:33:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691743.1078016; Tue, 12 Mar 2024 10:33:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjzRn-0007Or-0F; Tue, 12 Mar 2024 10:33:27 +0000 Received: by outflank-mailman (input) for mailman id 691743; Tue, 12 Mar 2024 10:33:25 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjzRl-0007Ol-Bq for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 10:33:25 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjzRk-0006oS-EM; Tue, 12 Mar 2024 10:33:24 +0000 Received: from [15.248.3.90] (helo=[10.24.67.26]) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1rjzRk-0007HE-62; Tue, 12 Mar 2024 10:33:24 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID; bh=TSZP2P9gugiylnBmvjJq7kv8toSoLDfvd0y2KYSe3yk=; b=B4cZVF1KhTQJ2I3VgXCJdqFu6T uMPIX59JPzRzGFRIKXevALBxfuKgjjxyI6Wb3f893sAxXM3SqSRMHFj1CjgPwrV3HEI/uYy0QTHjc xFBTxN2/kLmvX7Z3uM9aI7B/N3YdVZfrTsYMYNmm6XMu2jKlqfnVoUm36TTHthNn7q6Y=; Message-ID: Date: Tue, 12 Mar 2024 10:33:21 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] x86+Arm: drop (rename) __virt_to_maddr() / __maddr_to_virt() Content-Language: en-GB To: Jan Beulich , "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel , Oleksii Kurochko References: From: Julien Grall In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Jan, On 12/03/2024 10:27, Jan Beulich wrote: > There's no use of them anymore except in the definitions of the non- > underscore-prefixed aliases. > > On Arm convert the (renamed) inline function to a macro. > > On x86 rename the inline functions, adjust the virt_to_maddr() #define, > and purge the maddr_to_virt() one, thus eliminating a bogus cast which > would have allowed the passing of a pointer type variable into > maddr_to_virt() to go silently. > > No functional change intended. > > Signed-off-by: Jan Beulich > Reviewed-by: Oleksii Kurochko > --- > v2: Avoid aliasing macro on Arm. Interesting, I was expecting x86 to follow the same approach. I don't quite understand the benefit of the aliasing here but at the same time I don't maintain it. So for Arm (only): Acked-by: Julien Grall Also, Oleksii, when you send a patch for RISC-V, can you please avoid the aliasing on RISC-V? I understand we want to prefer static inline (and in general I would prefer them), but we also need to balance with avoiding aliasing when there are zero benefits. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Tue Mar 12 10:38:24 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 10:38:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691747.1078026 (Exim 4.92) (envelope-from ) id 1rjzWY-0007zn-LN; Tue, 12 Mar 2024 10:38:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691747.1078026; Tue, 12 Mar 2024 10:38:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjzWY-0007zg-IR; Tue, 12 Mar 2024 10:38:22 +0000 Received: by outflank-mailman (input) for mailman id 691747; Tue, 12 Mar 2024 10:38:20 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjzWW-0007za-PR for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 10:38:20 +0000 Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [2607:f8b0:4864:20::12f]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id a439eae6-e05c-11ee-afdd-a90da7624cb6; Tue, 12 Mar 2024 11:38:19 +0100 (CET) Received: by mail-il1-x12f.google.com with SMTP id e9e14a558f8ab-36671d34b58so149245ab.3 for ; Tue, 12 Mar 2024 03:38:19 -0700 (PDT) Received: from [192.168.206.239] ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id x17-20020a92cc91000000b003664ef72ac6sm1246688ilo.68.2024.03.12.03.38.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Mar 2024 03:38:18 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a439eae6-e05c-11ee-afdd-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1710239898; x=1710844698; darn=lists.xenproject.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=BBb2cb85x2ye9vgFEXWP4NLtt5MavEsdzf3VT/F7YNM=; b=Aqj/bIuBnPt2XMuiFczNCCUGIx7ovSfre9cpL9C3m56+kdeWRncq2pN8Cm9sOvNFnd 3b/0l6Pv8ouxEGSCqblBsqNYxbqxwQAE2aVio/SluRAKIKmrkUKogL57umBv45dhFD3F cl0HFrrtOF4cFKnzkMJRxsmP/FxuCCMoxVuiSxRIx2qiNQMGPa0Ilzgh6z05Hgx470cZ WSBP3K89in7QUbgdApIbQbrujAVw7yNdHRxsP4zCrY8+5TxeLFdNgPCiTZUeWeoWV5Z/ kHIKsnkocsFd3FsU8CucjWgYfbsLWnyGALexWPwOBCsxjMfYm2NWukfgrfDXcYprCjub G0Xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710239898; x=1710844698; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=BBb2cb85x2ye9vgFEXWP4NLtt5MavEsdzf3VT/F7YNM=; b=KV7h/G2aDJ4qLcbyHaYuuuTtIMOdGvUl4A1COc5zxwCB1ovD54gx5bsv0W8xQJuwTl +PUaKHdmWArTwkrWTgey3UqKbxUpBa9K5x9nm4CxPAsCev2iomqKqs5Kdvegm8Dcr0Mt i+PquJEP1//Y9DV89By7e8NavAhEUUzFZSBEkib05lF5fDaa4GJa1TYH5fxCeZRpqzud OVJMmOe69klVR2cZnrXq8lWFG7A5NKNpsmTpOvMi6VMP9wy1EXogwrrAag7vS/D/m5s0 WjoGGBQSDc6S8EHIy806QvIht2P3Sj3z0x6PEvM9ix8P7+ZiCdLAS8SaSx5srY01hkWY r1Rw== X-Forwarded-Encrypted: i=1; AJvYcCUboCJYw5IDY6Z4Czcb99KU11XSpBeZjlUxH5AnVy7rIEdopWsQHh4zH/gI6XdSyLp9mgZgrlIgJbkBUo//+TGHp0C+huzXfReWx4vN9O0= X-Gm-Message-State: AOJu0YzwfrRAxCswygOsGf3ivPqngCHw9fY5UvtOPG8kNWBuJZuT+lfQ Czspnk7kU7pLqxQEEaGurPcISFdx6c1G7fQcdSzoCCObMWcX50vB X-Google-Smtp-Source: AGHT+IEKK6Yzleb+V2ZY6ZuKNOB6iewltzBdWyVVEMBnpSQ7qOaeNOeaKrnDcMgQTE1eQJCKQyDg7g== X-Received: by 2002:a05:6e02:168d:b0:366:6d12:8e3d with SMTP id f13-20020a056e02168d00b003666d128e3dmr1027067ila.22.1710239898564; Tue, 12 Mar 2024 03:38:18 -0700 (PDT) Message-ID: Subject: Re: [PATCH v2] x86+Arm: drop (rename) __virt_to_maddr() / __maddr_to_virt() From: Oleksii To: Julien Grall , "xen-devel@lists.xenproject.org" Cc: Jan Beulich , Andrew Cooper , Wei Liu , Roger Pau =?ISO-8859-1?Q?Monn=E9?= , Stefano Stabellini , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel Date: Tue, 12 Mar 2024 11:38:14 +0100 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.50.2 (3.50.2-1.fc39) MIME-Version: 1.0 Hi Julien, On Tue, 2024-03-12 at 10:33 +0000, Julien Grall wrote: > Hi Jan, >=20 > On 12/03/2024 10:27, Jan Beulich wrote: > > There's no use of them anymore except in the definitions of the > > non- > > underscore-prefixed aliases. > >=20 > > On Arm convert the (renamed) inline function to a macro. > >=20 > > On x86 rename the inline functions, adjust the virt_to_maddr() > > #define, > > and purge the maddr_to_virt() one, thus eliminating a bogus cast > > which > > would have allowed the passing of a pointer type variable into > > maddr_to_virt() to go silently. > >=20 > > No functional change intended. > >=20 > > Signed-off-by: Jan Beulich > > Reviewed-by: Oleksii Kurochko > > --- > > v2: Avoid aliasing macro on Arm. >=20 > Interesting, I was expecting x86 to follow the same approach. I don't > quite understand the benefit of the aliasing here but at the same > time I=20 > don't maintain it. So for Arm (only): >=20 > Acked-by: Julien Grall >=20 > Also, Oleksii, when you send a patch for RISC-V, can you please avoid > the aliasing on RISC-V? I understand we want to prefer static inline=20 > (and in general I would prefer them), but we also need to balance > with=20 > avoiding aliasing when there are zero benefits. Sure. I wanted to that in the same way after your comment for the first version of this patch. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Tue Mar 12 10:43:48 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 10:43:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691750.1078035 (Exim 4.92) (envelope-from ) id 1rjzbj-0001U5-Ao; Tue, 12 Mar 2024 10:43:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691750.1078035; Tue, 12 Mar 2024 10:43:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjzbj-0001Ty-8L; Tue, 12 Mar 2024 10:43:43 +0000 Received: by outflank-mailman (input) for mailman id 691750; Tue, 12 Mar 2024 10:43:42 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjzbi-0001Ts-GL for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 10:43:42 +0000 Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [2a00:1450:4864:20::529]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 6409958a-e05d-11ee-afdd-a90da7624cb6; Tue, 12 Mar 2024 11:43:41 +0100 (CET) Received: by mail-ed1-x529.google.com with SMTP id 4fb4d7f45d1cf-56829f41f81so5951562a12.2 for ; Tue, 12 Mar 2024 03:43:41 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id el9-20020a056402360900b005680901f82dsm3825076edb.64.2024.03.12.03.43.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 Mar 2024 03:43:40 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6409958a-e05d-11ee-afdd-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1710240220; x=1710845020; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=+akJXHpgWaKevayBSjDyJFXSNvF4Bj8a+Qoj4DJiGus=; b=FbGp70910pFNmJGSZYspIW7vT2Ewd8I7EW+gIA5ti1bEoTBETlQAWopxA2BCO3HxBX XVH4Z/Vsj/p0CwOVwaYh7bs0obSo06dXlFbm+UKY0VBF9d+7/DYboIRpSpFWGsCzrRCM yWavb5DUeG6OtTUNJrEr2m41yCYzB15T2QIk2f0s9ZC3FlUy9yRN2/1GrF1cWuwY7S2T pMrYXlijgWkS40R7m6I2YWL13DTiRFLT8tJ0QYgWijzJ0wdrjfuJ03/JAqhZjDltVVjY j8XQKMfpJBrUefc2yY8ktjrANvMQBbH5mTJs6d4ezmmML4IfNUpw5DDaSbI30alamYe2 gTcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710240220; x=1710845020; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=+akJXHpgWaKevayBSjDyJFXSNvF4Bj8a+Qoj4DJiGus=; b=KNelK5HlCRqBrB7tQMoWT0yai2hNvshE3Go1Yc1Td/KGJuRI+RJj+vESzZR9qjrOfM ISLNfSY/9yHbiGDseNS5/Ii+QLX4FRdJVGmhvQCtwRkUBYzSs22+7QrWuLLeyqO62dvk AYZcM10H9QrEbGH7+jFkB5vv43yfVcnI5xetGbi3N++oLxys8red8EaAX1ZVJQKasbx2 +ayO8Ev4vBBoqP3kAT/CLkM1LBgowbUpCf/u9Pj3fUk92Jy4UaRmunMXRsARPBXZ6Lam 77Vn8e0r4tePsZknuZx+dAEvvXkAxg4jHWGhCgq+Su1dBJkEkgZl5Abv7uv/pGupjFie DS8w== X-Forwarded-Encrypted: i=1; AJvYcCU7S7hvpOwyHwZwSyMKrWSce5XtA3LqNs4wUESG6jBPMJFVphbH+/vTR/7Jhd+Rv123dbQ/827JkHHaHh9rWClS6Q0M2BKXFWn2SqaeppA= X-Gm-Message-State: AOJu0YxYWiveYZQ7T2sVYGDOwe+ShChUClMqypID8nb4kYJ1MvOgUfPb IXVomQCa7GuZ48hmT4Dq/YA53MRsavw8wplXTkecJBOxrHKK/zwxJFd79WFG8w== X-Google-Smtp-Source: AGHT+IFU+mabnlHPmGw4W+UkuSwE+5wGPZYSlb6cSZ6q8wqMZ5ADXuapaYUPQpT5rF0pnmMrwGFyJw== X-Received: by 2002:a50:baa4:0:b0:564:71:ccf0 with SMTP id x33-20020a50baa4000000b005640071ccf0mr6084452ede.2.1710240220639; Tue, 12 Mar 2024 03:43:40 -0700 (PDT) Message-ID: <5bf4120f-3cc5-44b2-994f-fbdb85054a49@suse.com> Date: Tue, 12 Mar 2024 11:43:39 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] x86+Arm: drop (rename) __virt_to_maddr() / __maddr_to_virt() Content-Language: en-US To: Julien Grall Cc: Andrew Cooper , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel , Oleksii Kurochko , "xen-devel@lists.xenproject.org" References: From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 12.03.2024 11:33, Julien Grall wrote: > Hi Jan, > > On 12/03/2024 10:27, Jan Beulich wrote: >> There's no use of them anymore except in the definitions of the non- >> underscore-prefixed aliases. >> >> On Arm convert the (renamed) inline function to a macro. >> >> On x86 rename the inline functions, adjust the virt_to_maddr() #define, >> and purge the maddr_to_virt() one, thus eliminating a bogus cast which >> would have allowed the passing of a pointer type variable into >> maddr_to_virt() to go silently. >> >> No functional change intended. >> >> Signed-off-by: Jan Beulich >> Reviewed-by: Oleksii Kurochko >> --- >> v2: Avoid aliasing macro on Arm. > > Interesting, I was expecting x86 to follow the same approach. I don't > quite understand the benefit of the aliasing here but at the same time I > don't maintain it. In the absence of respective feedback from x86 maintainers I had to guess what would be preferred, and my guessing is that retaining inline functions where we can use them would be preferred. If that turned out wrong, I'd then switch to purely a macro on x86 too. > So for Arm (only): > > Acked-by: Julien Grall Thanks. Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 12 10:49:36 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 10:49:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691755.1078045 (Exim 4.92) (envelope-from ) id 1rjzhL-0002Kq-VT; Tue, 12 Mar 2024 10:49:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691755.1078045; Tue, 12 Mar 2024 10:49:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjzhL-0002Kj-SA; Tue, 12 Mar 2024 10:49:31 +0000 Received: by outflank-mailman (input) for mailman id 691755; Tue, 12 Mar 2024 10:49:31 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjzhL-0002Kd-4Y for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 10:49:31 +0000 Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [2a00:1450:4864:20::52d]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 340ce8a2-e05e-11ee-afdd-a90da7624cb6; Tue, 12 Mar 2024 11:49:30 +0100 (CET) Received: by mail-ed1-x52d.google.com with SMTP id 4fb4d7f45d1cf-563d56ee65cso5059161a12.2 for ; Tue, 12 Mar 2024 03:49:30 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id x11-20020a1709064bcb00b00a449b175d2fsm3729713ejv.222.2024.03.12.03.49.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 Mar 2024 03:49:29 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 340ce8a2-e05e-11ee-afdd-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1710240569; x=1710845369; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=0eddT43b0cixj39NRdFSIlHNPQrC0qMJIpWdS9ba1Tg=; b=BW1aGRDrZUfWHSJABoxXD/j8HHf6WTySfXcojKGgKiBzSPrbCDLIRm62MoJTagT1v4 fF66v+sQ8iKloBPNlZhTFX1j98VsH+ZxL4hfvlledKu5FpnSZMp59VtzsGzlZTRiLfFC G8I0dK7lKuka101n8gEO3eGuCe6T8CVElyHjd0xEE6Z8VT9PFi6bVkTNjnsqNpX4kFz1 /3yi4waDgEGbHEwJWd+X4Id3er9uzMZMWrBvFhS4jidU3CyD1Hgj32CUceVQbxnMosjU fxa+7HfeHdPUkxMieH1Dz+z2gr2QW/v0NKNh+t2L0CIC/wpfCuNec8hAsjDJnf1MJ7FG v8bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710240569; x=1710845369; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=0eddT43b0cixj39NRdFSIlHNPQrC0qMJIpWdS9ba1Tg=; b=GUfF1piokYYRLNN78oH2Mg+CiZ0Oo3ImycI4bB5U26sYdqtUfKGWcgszu59cUENsor L5sO29WBToJvZXwiTGGVEAKrzk0tkYdaZql6cv7P9mJ5Pd1VRm01esjkEWRp/mgMVGuK zMQSRnACpzhF4Ad4VPOa5E58VYl/PVXV1AeO1bQdNP2InrcjJysKO7uJX9MQdzDrJrsY P1rFNEKxVs3IN6y7ennWzA5u6T3kb+FwoQReB7MRpkns5X7Ky92DRMkzycvwTO+4MIf6 KvgeHL5CCwc4jv3LfG8hIA1N0xv8ALRJvZHdQDqXu7Qr+lbsBHTItibH9eBaquNFz54y hUYQ== X-Forwarded-Encrypted: i=1; AJvYcCUj/7OFJAi7+wPeaq00royoRtG8D42HXxyf2YkQsakTCP0R4J4Uzp8SXXC7lIlcapf0SaC3S6yzgpgVp2wGK6QAOw9yGlsdfYed5Csq1GI= X-Gm-Message-State: AOJu0Yyo1yhuyi1/HOfcksba/gph6SvgYi9bijPorqgEkkMYjBp+HEwB lLMy/lE553u7UPPtuzPsENJ9pwtU73fglKLmLOrtzO9IWvBM5n9/vyjusjXF1A== X-Google-Smtp-Source: AGHT+IFejxn1LQ7bTWRoWLUZxlzog1QK35KV8Z/M1F89xflZk5gZ1kDTfJmrSexzb8XnrXTFMGZcIA== X-Received: by 2002:a17:906:35ca:b0:a45:15d5:9267 with SMTP id p10-20020a17090635ca00b00a4515d59267mr5687281ejb.63.1710240569611; Tue, 12 Mar 2024 03:49:29 -0700 (PDT) Message-ID: <117de48d-0193-4b59-961b-33c80354726c@suse.com> Date: Tue, 12 Mar 2024 11:49:28 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/3] x86/svm: Drop the _enabled suffix from vmcb bits Content-Language: en-US To: Vaishali Thakkar Cc: andrew.cooper3@citrix.com, roger.pau@citrix.com, wl@xen.org, xen-devel@lists.xenproject.org References: <8e6d8cac54ca05f1202580b574c548e08988d8f6.1710149462.git.vaishali.thakkar@vates.tech> <1c67a337-e9d5-4e4a-91d5-3c935c410cda@suse.com> <5dd4007d-f273-4e43-add6-a77f0459fc33@vates.tech> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <5dd4007d-f273-4e43-add6-a77f0459fc33@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 12.03.2024 11:00, Vaishali Thakkar wrote: > On 3/12/24 08:54, Jan Beulich wrote: >> On 11.03.2024 13:40, Vaishali Thakkar wrote: >>> --- a/xen/arch/x86/hvm/svm/nestedsvm.c >>> +++ b/xen/arch/x86/hvm/svm/nestedsvm.c >>> @@ -571,7 +571,7 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct cpu_user_regs *regs) >>> if ( nestedhvm_paging_mode_hap(v) ) >>> { >>> /* host nested paging + guest nested paging. */ >>> - n2vmcb->_np_enable = 1; >>> + n2vmcb->_np = true; >>> >>> nestedsvm_vmcb_set_nestedp2m(v, ns_vmcb, n2vmcb); >>> >>> @@ -585,7 +585,7 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct cpu_user_regs *regs) >>> else if ( paging_mode_hap(v->domain) ) >>> { >>> /* host nested paging + guest shadow paging. */ >>> - n2vmcb->_np_enable = 1; >>> + n2vmcb->_np = true; >>> /* Keep h_cr3 as it is. */ >>> n2vmcb->_h_cr3 = n1vmcb->_h_cr3; >>> /* When l1 guest does shadow paging >>> @@ -601,7 +601,7 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct cpu_user_regs *regs) >>> else >>> { >>> /* host shadow paging + guest shadow paging. */ >>> - n2vmcb->_np_enable = 0; >>> + n2vmcb->_np = false; >>> n2vmcb->_h_cr3 = 0x0; >>> >>> /* TODO: Once shadow-shadow paging is in place come back to here >>> @@ -706,7 +706,7 @@ nsvm_vcpu_vmentry(struct vcpu *v, struct cpu_user_regs *regs, >>> } >>> >>> /* nested paging for the guest */ >>> - svm->ns_hap_enabled = !!ns_vmcb->_np_enable; >>> + svm->ns_hap_enabled = ns_vmcb->_np; >>> >>> /* Remember the V_INTR_MASK in hostflags */ >>> svm->ns_hostflags.fields.vintrmask = !!ns_vmcb->_vintr.fields.intr_masking; >>> @@ -1084,7 +1084,7 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs) >>> if ( nestedhvm_paging_mode_hap(v) ) >>> { >>> /* host nested paging + guest nested paging. */ >>> - ns_vmcb->_np_enable = n2vmcb->_np_enable; >>> + ns_vmcb->_np = n2vmcb->_np; >>> ns_vmcb->_cr3 = n2vmcb->_cr3; >>> /* The vmcb->h_cr3 is the shadowed h_cr3. The original >>> * unshadowed guest h_cr3 is kept in ns_vmcb->h_cr3, >>> @@ -1093,7 +1093,7 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs) >>> else if ( paging_mode_hap(v->domain) ) >>> { >>> /* host nested paging + guest shadow paging. */ >>> - ns_vmcb->_np_enable = 0; >>> + ns_vmcb->_np = false; >>> /* Throw h_cr3 away. Guest is not allowed to set it or >>> * it can break out, otherwise (security hole!) */ >>> ns_vmcb->_h_cr3 = 0x0; >>> @@ -1104,7 +1104,7 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs) >>> else >>> { >>> /* host shadow paging + guest shadow paging. */ >>> - ns_vmcb->_np_enable = 0; >>> + ns_vmcb->_np = false; >>> ns_vmcb->_h_cr3 = 0x0; >>> /* The vmcb->_cr3 is the shadowed cr3. The original >>> * unshadowed guest cr3 is kept in ns_vmcb->_cr3, >> >> While spotting the small issue below it occurred to me: Why is it that >> vmcb_set_...() is open-coded everywhere here? I think this would be >> pretty nice to avoid at the same time (for lines touched anyway, or in >> a separate prereq patch, or alternatively [and only ideally] for all >> other instances in a follow-on patch). Thoughts? > > Yes, I noticed this too. My plan was to send a followup patch for > fixing all the instances where vmcb_set/get_...() can be used. > There are bunch of other vmcb bits (apart from the ones being > handled in this patchset) in this file and in svm.c which can > benefit from using VMCB accessors. To keep churn as well as effort to find commits touching individual lines low, doing the conversion when touching lines anyway is imo preferable. A follow-on patch can then convert what's left. Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 12 10:50:47 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 10:50:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691757.1078056 (Exim 4.92) (envelope-from ) id 1rjziX-0003so-94; Tue, 12 Mar 2024 10:50:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691757.1078056; Tue, 12 Mar 2024 10:50:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjziX-0003sh-5x; Tue, 12 Mar 2024 10:50:45 +0000 Received: by outflank-mailman (input) for mailman id 691757; Tue, 12 Mar 2024 10:50:44 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjziW-0003sb-C5 for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 10:50:44 +0000 Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [2a00:1450:4864:20::62a]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 5fd0dd31-e05e-11ee-afdd-a90da7624cb6; Tue, 12 Mar 2024 11:50:43 +0100 (CET) Received: by mail-ej1-x62a.google.com with SMTP id a640c23a62f3a-a44665605f3so753046166b.2 for ; Tue, 12 Mar 2024 03:50:43 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id x11-20020a1709064bcb00b00a449b175d2fsm3729713ejv.222.2024.03.12.03.50.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 Mar 2024 03:50:42 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 5fd0dd31-e05e-11ee-afdd-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1710240643; x=1710845443; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=dYBA5ZRY3sMwHRTKUt/lRju6/j+m+2WI0qT9VSOvySE=; b=ACL20bEkRLf5qZARviwUH3COUKQ6W36sj0lzJKyLCXprVd/2te9lVw1Q8jjcB+B/jy V5hOtdF9+Ckxj7GCuo162PuLMN3CnPeFf2dHHRMdcis0HCZMEWu1jit/dSSt8e+vk+mB 8LdstAQ5ITcZmFyu3tvM8cThe8BSktkNYLE5JJbxMr5ayQ+x/pxWtOy8QwgtMg4A+fNT DHTdw3iUrzvB4iW3sU/CuLHW06iqUZCBrhsJYhgriq8W20/Nalqr/FfxYXq4+ok37Ew1 2imFEkjF2Cx63li7f+ZCL4ep4Q5i4Ym5adfmWvCfacoRHb31a/3WV08L2hrRUszfc3AW OOGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710240643; x=1710845443; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=dYBA5ZRY3sMwHRTKUt/lRju6/j+m+2WI0qT9VSOvySE=; b=NnM7TXZKWy/+mU+7XSdYF/V+3URsAywocx9APLqOzCs9KFZeCJJLF4o+YrJaOoSlN5 UrppC9MmFEIT/1LiB4K/CqblSqobZsU020IPqI9Zv05F+UyENcemku0f+ZQ7kXxiK8AB 7s3CeE4cqnsv4zGDfS3FUwEqIJ7TscGowcwgw8DTw5aKEQEKfzpN9WGow3rRY9vubH7s V38JxGT3mQ2mxYL9iBVRn9HYPr/TdmzKU9PP/VEwTLLLZCcgW/zvySYcOMt1o0Kkwf9V 1UGhnAUyK0sTt4Z2+Qn3tVV2GekLulUp7r1lGR0SYG9T8zS8ibjhXp/OK/s3d/KenS5a /QUA== X-Forwarded-Encrypted: i=1; AJvYcCWiC18jVFB4SuagQs8JTXFxgSP0UdVOR/vtbr+0Ll4izGzC5kVmHL4cx0bK3p+4S8L8WLybi2Myog+ldsFiNgDR5JWBGc46LbZAKnXWPPo= X-Gm-Message-State: AOJu0YxBIv7ivqJoFeVCBCbT4KV2m4MWT1BEmbSMXvaHBqcVePAcGTtl xtTPa7N9A8ff8RDtWdwl813YT/D4O06xl00OHDbP3BpvM/ylFIjtFXXMpqPKCA== X-Google-Smtp-Source: AGHT+IH5nZR5vvDN4qN+c89PhcPB2ebU/v35WNGv1h28RdKTbha0GZhT7FgsPZCFJY6E8KRYjz4KUQ== X-Received: by 2002:a17:906:19c5:b0:a46:2c22:7f4c with SMTP id h5-20020a17090619c500b00a462c227f4cmr3090292ejd.35.1710240642995; Tue, 12 Mar 2024 03:50:42 -0700 (PDT) Message-ID: Date: Tue, 12 Mar 2024 11:50:42 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/3] x86/svm: Drop the suffix _guest from vmcb bit Content-Language: en-US To: Vaishali Thakkar Cc: andrew.cooper3@citrix.com, roger.pau@citrix.com, wl@xen.org, xen-devel@lists.xenproject.org References: From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 12.03.2024 11:08, Vaishali Thakkar wrote: > On 3/12/24 08:59, Jan Beulich wrote: >> On 11.03.2024 13:40, Vaishali Thakkar wrote: >>> @@ -698,11 +698,11 @@ nsvm_vcpu_vmentry(struct vcpu *v, struct cpu_user_regs *regs, >>> /* Convert explicitely to boolean. Deals with l1 guests >>> * that use flush-by-asid w/o checking the cpuid bits */ >>> nv->nv_flushp2m = !!ns_vmcb->tlb_control; >>> - if ( svm->ns_guest_asid != ns_vmcb->_guest_asid ) >>> + if ( svm->ns_asid != ns_vmcb->_asid ) >>> { >>> nv->nv_flushp2m = 1; >>> hvm_asid_flush_vcpu_asid(&vcpu_nestedhvm(v).nv_n2asid); >>> - svm->ns_guest_asid = ns_vmcb->_guest_asid; >>> + svm->ns_asid = ns_vmcb->_asid; >>> } >>> >>> /* nested paging for the guest */ >>> @@ -1046,7 +1046,7 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs) >>> /* Keep it. It's maintainted by the l1 guest. */ >>> >>> /* ASID */ >>> - /* ns_vmcb->_guest_asid = n2vmcb->_guest_asid; */ >>> + /* ns_vmcb->_asid = n2vmcb->_asid; */ >> >> Unlike in the earlier patch, where I could accept the request to switch >> to using accessor functions as scope-creep-ish, here I'm pretty firm >> with my request to stop their open-coding at the same time. Unless of >> course there's a technical reason the accessors cannot be used here. > > Yes, so as mentioned in the other patch's reply, I plan to tackle this > instance too in the followup patchset along with others. So, if you're > fine with it, I'll leave this one here for now. Unless you prefer otherwise. I thought I said pretty clearly that here I'm stronger with my request than on the other patch. Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 12 10:53:55 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 10:53:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691760.1078066 (Exim 4.92) (envelope-from ) id 1rjzlY-0004TA-Nh; Tue, 12 Mar 2024 10:53:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691760.1078066; Tue, 12 Mar 2024 10:53:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjzlY-0004T3-JR; Tue, 12 Mar 2024 10:53:52 +0000 Received: by outflank-mailman (input) for mailman id 691760; Tue, 12 Mar 2024 10:53:50 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjzlW-0004Sx-Pl for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 10:53:50 +0000 Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [2a00:1450:4864:20::630]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id ce084821-e05e-11ee-a1ee-f123f15fe8a2; Tue, 12 Mar 2024 11:53:48 +0100 (CET) Received: by mail-ej1-x630.google.com with SMTP id a640c23a62f3a-a44ad785a44so511109066b.3 for ; Tue, 12 Mar 2024 03:53:48 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id f15-20020a170906048f00b00a42ee62b634sm3719489eja.106.2024.03.12.03.53.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 Mar 2024 03:53:47 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ce084821-e05e-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1710240828; x=1710845628; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=/rojXMfHXApf8EGOHWtgacoTXPjnXkQP6vbQTBrXJBA=; b=bN7uQc0DIlOFx6kpT/UUgT9ChvqPhBvQq1e2bQtUupHVtUurX6qTp9Ni76qHWkFtu5 l752pwVSWktLBToN6q7kxwnD0X/ya2OMRUHxjVoW2eZauc53L2AAK2OHEvdDqv3jePZe kp2P63/v5Q/2TvkuFwCM9Cbs9u87lyjKt1UUkmQjw+aDmbnZ0uATIO29Uenwkzwnxw6K Qy2wCjgJiDrL7QHMCmKYYq+HR/j60cT1RVVxFBsJOm/XFsIYMWDrXEsu7wgMtOkN0ome KZdugXa1Z5U9BJ43li4SwwGmMMvKivR/d/tIJZdTp0OptYWsWDtHP71YZw42Ebw/BAnk FXcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710240828; x=1710845628; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=/rojXMfHXApf8EGOHWtgacoTXPjnXkQP6vbQTBrXJBA=; b=MYd1qlxeM6GCC1r8VugdKBVD7MsCpcxwBYKUnqXIUICjdDPQqJBPO0W/YLoQtYpOQV HvkRICa0tR787iUVLPMP294Q0713ItmL/mvzt9Cc/lbdRJh2KFwhM3h4FsDsY9wPko9g nKVEof75xJiiN6DQrr3E+c4VIaz0gYfb0E9ThhCwkZe6NpKptakwNCq7kGMuGlbQfWGW oWnpPoMkJ//Ms99R5YyOuic8tGhmj2BgcuWgpnAaMSMmr8KNPMEMi1KU99cmL7yPEZ2a 8lYNgMakiX14gGwYYx901Ic5b23D52DpLcWirh8fQksiEv0JXpLHHri9JF6U300dRcXs hqPg== X-Gm-Message-State: AOJu0YzxN/Q3PGbqMc8COTPuNAK676SI5qje6hlWY4DlcQEu09tu7rBT VBsULO/iR5hC5BKJM8dmfzOjzr1fNbD8PERdHAdTlTJUq82iHzOqG7lAp0wI7A== X-Google-Smtp-Source: AGHT+IGgZQJ0JPYFoWVYHjujLovk/rKXJJzrgrqi4AFrfdCp9sNVKh8sFbV+Nd920ALC50PRV4tkHQ== X-Received: by 2002:a17:906:6d0e:b0:a46:2aa1:1d with SMTP id m14-20020a1709066d0e00b00a462aa1001dmr2950174ejr.8.1710240827983; Tue, 12 Mar 2024 03:53:47 -0700 (PDT) Message-ID: <6a80ceb6-cc2a-4d8f-9a66-70063923b0ea@suse.com> Date: Tue, 12 Mar 2024 11:53:46 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] drivers/char: mark XHCI DMA buffers reserved in memory map Content-Language: en-US To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Wei Liu , George Dunlap , Julien Grall , Stefano Stabellini References: <20240311203431.342530-1-marmarek@invisiblethingslab.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 12.03.2024 11:24, Roger Pau Monné wrote: >> --- a/xen/arch/x86/setup.c >> +++ b/xen/arch/x86/setup.c >> @@ -1806,6 +1806,9 @@ void asmlinkage __init noreturn __start_xen(unsigned long mbi_p) >> mmio_ro_ranges = rangeset_new(NULL, "r/o mmio ranges", >> RANGESETF_prettyprint_hex); >> >> + /* Needs to happen after E820 processing but before IOMMU init */ >> + xhci_dbc_uart_reserve_ram(); > > Overall it might be better if some generic solution for all users of > iommu_add_extra_reserved_device_memory() could be implemented, +1 > but I'm > unsure whether the intention is for the interface to always be used > against RAM. I think we can work from that assumption for now. Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 12 10:54:41 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 10:54:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691763.1078076 (Exim 4.92) (envelope-from ) id 1rjzmJ-000510-1y; Tue, 12 Mar 2024 10:54:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691763.1078076; Tue, 12 Mar 2024 10:54:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjzmI-00050r-Vd; Tue, 12 Mar 2024 10:54:38 +0000 Received: by outflank-mailman (input) for mailman id 691763; Tue, 12 Mar 2024 10:54:37 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjzmH-0004oA-8q for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 10:54:37 +0000 Received: from mail137-23.atl71.mandrillapp.com (mail137-23.atl71.mandrillapp.com [198.2.137.23]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id ea2a80a0-e05e-11ee-afdd-a90da7624cb6; Tue, 12 Mar 2024 11:54:36 +0100 (CET) Received: from pmta07.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail137-23.atl71.mandrillapp.com (Mailchimp) with ESMTP id 4Tv9WZ2MMWz1XLHZ5 for ; Tue, 12 Mar 2024 10:54:34 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 961122f0e583439a882819f01af904d9; Tue, 12 Mar 2024 10:54:34 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ea2a80a0-e05e-11ee-afdd-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1710240874; x=1710501374; bh=GPUGNz2EdLG3eEvQvpjnh9pHYV61KnZ992OYDytpauk=; h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=yp01VWKAmEUohjmWXnJYbq19Lng5USxZBShvvFm7oy64lOk4/m7uLiFo12IQUrmwZ I0WKy4BMx9PfHHD2cwHYjWHCt80nBhRlc4tB2z5YWbtC2u+NuchOH5fHa0ALrhOEoN vHHv5zIyuBvrYD7NAMJaTMhxFcmvjm/ylBaRKHUayEdqc/mUXGPuPxIUrR0cDdieos UuMoxzHXDWT80Itf6Zy3F86DvA0VFcwuBbkKvUl2GgrKdzLaBpURrIzoIYnLt5vY6k WhldQVckKQawLDUUB8VdPI/rItSvzbOYRa6/CS2JUJ+ESQUfvDAgnXsX/nDvC2mKRb HGTHY7VgVbC/g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1710240874; x=1710501374; i=vaishali.thakkar@vates.tech; bh=GPUGNz2EdLG3eEvQvpjnh9pHYV61KnZ992OYDytpauk=; h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=aY166ExxRJ1OdLD44rCMbVz7rWrv85o80JUiSefn2tFavdggDatS4NUqvznQ0apAV Sej1NaFSJK4/r2Efy5MPyXVAF8VawXPJ86afrmON2gsuDrNeSI0l3NWo7780YkglYM 80jnAceQnhMCc57YRRmvaS3jt6r4tc1xxM6Q2SEKh+SEu1rRRFTczjEPfucOz7w3zG ip7rqZfZltEZuTq6Ax0RovLmi6H5nQQGRkPs9zFMzNRhU3E6OkDJmTXeleo0dAYbKO zuueQCdpG2kC4E3IG/5tsZDnCTNbErOQF8dgMoDeORLVA0dl2bvGnugM1oPjPHSzSS kur/AIWOKoEaQ== From: Vaishali Thakkar Subject: =?utf-8?Q?Re:=20[PATCH=20v2=201/3]=20x86/svm:=20Drop=20the=20=5Fenabled=20suffix=20from=20vmcb=20bits?= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1710240873145 Message-Id: To: Jan Beulich Cc: andrew.cooper3@citrix.com, roger.pau@citrix.com, wl@xen.org, xen-devel@lists.xenproject.org References: <8e6d8cac54ca05f1202580b574c548e08988d8f6.1710149462.git.vaishali.thakkar@vates.tech> <1c67a337-e9d5-4e4a-91d5-3c935c410cda@suse.com> <5dd4007d-f273-4e43-add6-a77f0459fc33@vates.tech> <117de48d-0193-4b59-961b-33c80354726c@suse.com> In-Reply-To: <117de48d-0193-4b59-961b-33c80354726c@suse.com> X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.961122f0e583439a882819f01af904d9?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20240312:md Date: Tue, 12 Mar 2024 10:54:34 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 3/12/24 11:49, Jan Beulich wrote: > On 12.03.2024 11:00, Vaishali Thakkar wrote: >> On 3/12/24 08:54, Jan Beulich wrote: >>> On 11.03.2024 13:40, Vaishali Thakkar wrote: >>>> --- a/xen/arch/x86/hvm/svm/nestedsvm.c >>>> +++ b/xen/arch/x86/hvm/svm/nestedsvm.c >>>> @@ -571,7 +571,7 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct cpu_user_regs *regs) >>>> if ( nestedhvm_paging_mode_hap(v) ) >>>> { >>>> /* host nested paging + guest nested paging. */ >>>> - n2vmcb->_np_enable = 1; >>>> + n2vmcb->_np = true; >>>> >>>> nestedsvm_vmcb_set_nestedp2m(v, ns_vmcb, n2vmcb); >>>> >>>> @@ -585,7 +585,7 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct cpu_user_regs *regs) >>>> else if ( paging_mode_hap(v->domain) ) >>>> { >>>> /* host nested paging + guest shadow paging. */ >>>> - n2vmcb->_np_enable = 1; >>>> + n2vmcb->_np = true; >>>> /* Keep h_cr3 as it is. */ >>>> n2vmcb->_h_cr3 = n1vmcb->_h_cr3; >>>> /* When l1 guest does shadow paging >>>> @@ -601,7 +601,7 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct cpu_user_regs *regs) >>>> else >>>> { >>>> /* host shadow paging + guest shadow paging. */ >>>> - n2vmcb->_np_enable = 0; >>>> + n2vmcb->_np = false; >>>> n2vmcb->_h_cr3 = 0x0; >>>> >>>> /* TODO: Once shadow-shadow paging is in place come back to here >>>> @@ -706,7 +706,7 @@ nsvm_vcpu_vmentry(struct vcpu *v, struct cpu_user_regs *regs, >>>> } >>>> >>>> /* nested paging for the guest */ >>>> - svm->ns_hap_enabled = !!ns_vmcb->_np_enable; >>>> + svm->ns_hap_enabled = ns_vmcb->_np; >>>> >>>> /* Remember the V_INTR_MASK in hostflags */ >>>> svm->ns_hostflags.fields.vintrmask = !!ns_vmcb->_vintr.fields.intr_masking; >>>> @@ -1084,7 +1084,7 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs) >>>> if ( nestedhvm_paging_mode_hap(v) ) >>>> { >>>> /* host nested paging + guest nested paging. */ >>>> - ns_vmcb->_np_enable = n2vmcb->_np_enable; >>>> + ns_vmcb->_np = n2vmcb->_np; >>>> ns_vmcb->_cr3 = n2vmcb->_cr3; >>>> /* The vmcb->h_cr3 is the shadowed h_cr3. The original >>>> * unshadowed guest h_cr3 is kept in ns_vmcb->h_cr3, >>>> @@ -1093,7 +1093,7 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs) >>>> else if ( paging_mode_hap(v->domain) ) >>>> { >>>> /* host nested paging + guest shadow paging. */ >>>> - ns_vmcb->_np_enable = 0; >>>> + ns_vmcb->_np = false; >>>> /* Throw h_cr3 away. Guest is not allowed to set it or >>>> * it can break out, otherwise (security hole!) */ >>>> ns_vmcb->_h_cr3 = 0x0; >>>> @@ -1104,7 +1104,7 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs) >>>> else >>>> { >>>> /* host shadow paging + guest shadow paging. */ >>>> - ns_vmcb->_np_enable = 0; >>>> + ns_vmcb->_np = false; >>>> ns_vmcb->_h_cr3 = 0x0; >>>> /* The vmcb->_cr3 is the shadowed cr3. The original >>>> * unshadowed guest cr3 is kept in ns_vmcb->_cr3, >>> >>> While spotting the small issue below it occurred to me: Why is it that >>> vmcb_set_...() is open-coded everywhere here? I think this would be >>> pretty nice to avoid at the same time (for lines touched anyway, or in >>> a separate prereq patch, or alternatively [and only ideally] for all >>> other instances in a follow-on patch). Thoughts? >> >> Yes, I noticed this too. My plan was to send a followup patch for >> fixing all the instances where vmcb_set/get_...() can be used. >> There are bunch of other vmcb bits (apart from the ones being >> handled in this patchset) in this file and in svm.c which can >> benefit from using VMCB accessors. > > To keep churn as well as effort to find commits touching individual lines > low, doing the conversion when touching lines anyway is imo preferable. A > follow-on patch can then convert what's left. Alright, I'll replace open coding with VMCB accessors for the lines which are touched by this patchset. And others in a followup patchset. > Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 12 11:01:37 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 11:01:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691768.1078086 (Exim 4.92) (envelope-from ) id 1rjzsq-000705-Nv; Tue, 12 Mar 2024 11:01:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691768.1078086; Tue, 12 Mar 2024 11:01:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjzsq-0006zv-KW; Tue, 12 Mar 2024 11:01:24 +0000 Received: by outflank-mailman (input) for mailman id 691768; Tue, 12 Mar 2024 11:01:23 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rjzsp-0006zp-Jn for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 11:01:23 +0000 Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [2607:f8b0:4864:20::333]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id dc157419-e05f-11ee-afdd-a90da7624cb6; Tue, 12 Mar 2024 12:01:22 +0100 (CET) Received: by mail-ot1-x333.google.com with SMTP id 46e09a7af769-6e52b9234c0so918192a34.2 for ; Tue, 12 Mar 2024 04:01:22 -0700 (PDT) Received: from localhost ([213.195.118.74]) by smtp.gmail.com with ESMTPSA id x6-20020a05620a098600b0078835bfddb8sm3562169qkx.84.2024.03.12.04.01.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Mar 2024 04:01:20 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: dc157419-e05f-11ee-afdd-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1710241281; x=1710846081; darn=lists.xenproject.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=CkuD7/VKzR/42WmV9g0w5MfXQqoF0FZt+XVoxJxKCaQ=; b=BsK7Fn1JPYf0/zvjVDYk4Wz0CfGZewg5gkGR6j1yHRXA9m4nnYr1bH+qhtJLhQOpdD vsnVAVEcg4QeMXCtfkvQHql4hjPobsQtAE5/32Xc7QyggI9DLjv7jdiyyaiK6S3gceiL 3zPb0JzXLohWGGrXjD++tS+v/LH4w7L45uEnw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710241281; x=1710846081; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=CkuD7/VKzR/42WmV9g0w5MfXQqoF0FZt+XVoxJxKCaQ=; b=f08vMHy8jg92x5lkDwu0T7lidJZfMw5oSVljz5jOsCNIBbIODo21pjpQYRBXOHzegA o9p9BGtLaU79+5LrA4+1wAfq/4I8/m9O/2ouUVL29GrcebUEhfq4b1CMohErZYL3pD+9 Q1YPcMUcu+b0Zib5r8xgF6aBwpL/DoWZm/fZnhIxN7FoedIX4LL1Zru29wdLKWHko6y2 4BmWqQYvEvP04oSk4w6ZpxTek1iPoPvbcaRPZ40H5cuVvvK+u6+EpqEz3PPBV5EHA4Fu YovXPUhhhVMuDgF+LFztJ+cim7YbQjtSKZz1qrFZ8Fg2emXt/mDKmK5zGz51TQ7rK7Yg NOEA== X-Gm-Message-State: AOJu0YwZ9vAyqyEgDYI7iyAUhZBuzQPR2KuOZKeAkuoGANs70TuWRPIk /Z9Gy58cEf3L1PigRZM1LptJOzlW91uLRzS/vXkS/Owfk3w4zI1I7ZNQuUXU1HM= X-Google-Smtp-Source: AGHT+IHIVXpe5ZL0iQ5eq6zRiXO5qWk23xUawDTCs0iz1TSxjCtPDoDIDApJMAPnfVigz8stb9hlyA== X-Received: by 2002:a9d:7a92:0:b0:6e5:307b:fa70 with SMTP id l18-20020a9d7a92000000b006e5307bfa70mr5505560otn.29.1710241280790; Tue, 12 Mar 2024 04:01:20 -0700 (PDT) Date: Tue, 12 Mar 2024 12:01:18 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Simone Ballarin Cc: xen-devel@lists.xenproject.org, consulting@bugseng.com, Maria Celeste Cesario , Jan Beulich , Andrew Cooper , Wei Liu , Kevin Tian Subject: Re: [PATCH v2 1/2] x86/IOMMU: address violations of MISRA C:2012 Rule 14.4 Message-ID: References: <746a33fff1386b2e76657b5f7cfb31f3b117a1fe.1702310368.git.maria.celeste.cesario@bugseng.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <746a33fff1386b2e76657b5f7cfb31f3b117a1fe.1702310368.git.maria.celeste.cesario@bugseng.com> On Wed, Dec 13, 2023 at 05:10:50PM +0100, Simone Ballarin wrote: > From: Maria Celeste Cesario > > The xen sources contain violations of MISRA C:2012 Rule 14.4 whose > headline states: > "The controlling expression of an if statement and the controlling > expression of an iteration-statement shall have essentially Boolean type". > > Add comparisons to avoid using enum constants as controlling expressions > to comply with Rule 14.4. If we really want to go this route, we also need to amend the comment in iommu_intremap definition, as it's no longer valid: extern enum __packed iommu_intremap { /* * In order to allow traditional boolean uses of the iommu_intremap * variable, the "off" value has to come first (yielding a value of zero). */ iommu_intremap_off, We no longer allow traditional boolean uses of iommu_intremap. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Tue Mar 12 11:14:03 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 11:14:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691778.1078115 (Exim 4.92) (envelope-from ) id 1rk050-0001Eu-0q; Tue, 12 Mar 2024 11:13:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691778.1078115; Tue, 12 Mar 2024 11:13:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk04z-0001En-UC; Tue, 12 Mar 2024 11:13:57 +0000 Received: by outflank-mailman (input) for mailman id 691778; Tue, 12 Mar 2024 11:13:56 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk04y-0001Ef-RO for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 11:13:56 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 9d014617-e061-11ee-a1ee-f123f15fe8a2; Tue, 12 Mar 2024 12:13:54 +0100 (CET) Received: from nico.bugseng.com (unknown [46.228.253.194]) by support.bugseng.com (Postfix) with ESMTPSA id DDE774EE0C90; Tue, 12 Mar 2024 12:13:52 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 9d014617-e061-11ee-a1ee-f123f15fe8a2 From: Nicola Vetrini To: nicola.vetrini@bugseng.com, xen-devel@lists.xenproject.org Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, consulting@bugseng.com, bertrand.marquis@arm.com, julien@xen.org, Andrew Cooper , George Dunlap , Jan Beulich , Wei Liu Subject: [XEN PATCH v2] xen/compiler: deviate the inline macro for MISRA C Rule 20.4 Date: Tue, 12 Mar 2024 12:13:49 +0100 Message-Id: <0e48f35eaa95bbba6c2b8219e412bfd6d9c82b52.1710241987.git.nicola.vetrini@bugseng.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Rule 20.4 states: "A macro shall not be defined with the same name as a keyword". Defining this macro with the same name as the inline keyword allows for additionally checking that out-of-lined static inline functions end up in the correct section while minimizing churn and has a positive impact on the overall safety. See [1] for additional context on the motivation of this deviation. No functional change. [1] https://lore.kernel.org/xen-devel/adaa6d55-266d-4df8-8967-9340080d17e4@citrix.com/ Signed-off-by: Nicola Vetrini --- Changes in v2: - Rephrased SAF comment to be more general and added exact motivation for the redefinition of "inline" in deviation.rst. --- docs/misra/deviations.rst | 6 ++++++ docs/misra/safe.json | 8 ++++++++ xen/include/xen/compiler.h | 1 + 3 files changed, 15 insertions(+) diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst index 123c78e20a01..f8b40dd1e461 100644 --- a/docs/misra/deviations.rst +++ b/docs/misra/deviations.rst @@ -322,6 +322,12 @@ Deviations related to MISRA C:2012 Rules: - /\* Fallthrough \*/ - /\* Fallthrough. \*/ + * - R20.4 + - The override of the keyword \"inline\" in xen/compiler.h is present so + that section contents checks pass when the compiler chooses not to + inline a particular function. + - Comment-based deviation. + * - R20.7 - Code violating Rule 20.7 is safe when macro parameters are used: (1) as function arguments; diff --git a/docs/misra/safe.json b/docs/misra/safe.json index 952324f85cf9..d361d0e65ceb 100644 --- a/docs/misra/safe.json +++ b/docs/misra/safe.json @@ -28,6 +28,14 @@ }, { "id": "SAF-3-safe", + "analyser": { + "eclair": "MC3R1.R20.4" + }, + "name": "MC3R1.R20.4: allow the definition of a macro with the same name as a keyword in some special cases", + "text": "The definition of a macro with the same name as a keyword can be useful in certain configurations to improve the guarantees that can be provided by Xen. See docs/misra/deviations.rst for a precise rationale for all such cases." + }, + { + "id": "SAF-4-safe", "analyser": {}, "name": "Sentinel", "text": "Next ID to be used" diff --git a/xen/include/xen/compiler.h b/xen/include/xen/compiler.h index 16d554f2a593..fc87a2edad7f 100644 --- a/xen/include/xen/compiler.h +++ b/xen/include/xen/compiler.h @@ -82,6 +82,7 @@ * inline functions not expanded inline get placed in .init.text. */ #include +/* SAF-3-safe MISRA C Rule 20.4: allow section checks to pass when not inlined */ #define inline inline __init #endif -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Tue Mar 12 11:25:10 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 11:25:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691781.1078125 (Exim 4.92) (envelope-from ) id 1rk0Fi-0003K3-Uf; Tue, 12 Mar 2024 11:25:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691781.1078125; Tue, 12 Mar 2024 11:25:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk0Fi-0003Jw-Qj; Tue, 12 Mar 2024 11:25:02 +0000 Received: by outflank-mailman (input) for mailman id 691781; Tue, 12 Mar 2024 11:25:01 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk0Fh-0003Jq-T4 for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 11:25:01 +0000 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 293480ee-e063-11ee-afdd-a90da7624cb6; Tue, 12 Mar 2024 12:25:00 +0100 (CET) Received: from mail-qt1-f198.google.com (mail-qt1-f198.google.com [209.85.160.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-632-3h6p3-o2OzWdtojOZSd3WA-1; Tue, 12 Mar 2024 07:24:57 -0400 Received: by mail-qt1-f198.google.com with SMTP id d75a77b69052e-42ee0da398eso75267801cf.1 for ; Tue, 12 Mar 2024 04:24:57 -0700 (PDT) Received: from [192.168.0.9] (ip-109-43-177-86.web.vodafone.de. [109.43.177.86]) by smtp.gmail.com with ESMTPSA id l11-20020a05622a050b00b0042c7d11e280sm3608889qtx.90.2024.03.12.04.24.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 Mar 2024 04:24:56 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 293480ee-e063-11ee-afdd-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1710242699; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=gnBoAxc43PzxlzX8NgDw1FOToc09+ltM8010JBkSnys=; b=e9/3H3VMXf5v0Hyrk6ovKXcI9QUHW4RkLDr+ez+uLnmbk1Qx9EPoVGUqU0nOaF0sUtpyPi RdGhb5YyhYO3WPLpPPz6WAO9d2nEZAhZj600nHtyJL+G9mQvk7ASeUME1vXjw0WDqLvMPt uHTJsvYMTcGB/uM7sQPamVnWN4ZMgNU= X-MC-Unique: 3h6p3-o2OzWdtojOZSd3WA-1 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710242697; x=1710847497; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=gnBoAxc43PzxlzX8NgDw1FOToc09+ltM8010JBkSnys=; b=FBq7YG0DoZXiYuIwGqbligm6YSEONCUVuOUGLPQ/HBB5jj40YtkFBv9eDW7mNGyxZ3 //1vr5gmI04CUKEygZoouw155bnuHARRH+x8EDwd7Jo/BJFE1Eoh8go+LikC9DILgfU/ Ck+UnoMGplTzoH0E8uvGwApYbrB/AbvZjGbjdQGAlZx1H5q32XLOuYANJ5R2jv8cHzwr bZh4Ga89BtDQEWpM5ut10g6ZErMh5Boqb7SmdFgYX/C6mUkRClj4OVqwrYMhBH6LjTvQ qrg/eWI93Cf7LsFCHeA26u0b96R8s4+dkdChfC1tjAARHU6psI+tqIGbaPDEowh+5yHD iepw== X-Forwarded-Encrypted: i=1; AJvYcCUhtWX7bJOuK8dptbITkPzkUsmJ6sCdbOJ/rn8aMzI/nY798ZQY6N95Qs/RKgDzi+/Z3YihDKb1YPxjyothXlG1MHXVdnIFfa1oKp85n+k= X-Gm-Message-State: AOJu0YwtB+wRVaEfNHsYXPeM64TtUhTE8dskhyaxJUG2HPPoDHEgkIjw gHUwuNghl5KMEPOfwPVct2wk5jcWczgJaTMGp24NTILcSZ0zBD+Ly9p+eRB+VxTr82rZBqCiKyt P4MQ89DHt2l+080esPvXp0ax7saVTmKuBS0G5jXM2ZqaGD2ypTJQcwmitri7tLD53 X-Received: by 2002:a05:622a:1454:b0:42e:8beb:325 with SMTP id v20-20020a05622a145400b0042e8beb0325mr10339144qtx.31.1710242696623; Tue, 12 Mar 2024 04:24:56 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHOC3aOF+g4AMZA0grALUbHfxXPMcm4Ryayzppon2mawE44bRCtuTu2Z1s3VoohtkPfAdKV1g== X-Received: by 2002:a05:622a:1454:b0:42e:8beb:325 with SMTP id v20-20020a05622a145400b0042e8beb0325mr10339129qtx.31.1710242696303; Tue, 12 Mar 2024 04:24:56 -0700 (PDT) Message-ID: <96422cf0-30a8-4e2a-99c5-8388ec342e36@redhat.com> Date: Tue, 12 Mar 2024 12:24:49 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 14/29] target/i386: Prefer fast cpu_env() over slower CPU QOM cast macro To: Igor Mammedov , =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= Cc: qemu-devel@nongnu.org, qemu-riscv@nongnu.org, qemu-s390x@nongnu.org, Paolo Bonzini , kvm@vger.kernel.org, qemu-ppc@nongnu.org, qemu-arm@nongnu.org, Richard Henderson , "Michael S. Tsirkin" , Marcel Apfelbaum , Eduardo Habkost , Stefano Stabellini , Anthony Perard , Paul Durrant , Cameron Esfahani , Roman Bolshakov , Marcelo Tosatti , David Woodhouse , xen-devel@lists.xenproject.org References: <20240129164514.73104-1-philmd@linaro.org> <20240129164514.73104-15-philmd@linaro.org> <20240130140115.135f533d@imammedo.users.ipa.redhat.com> From: Thomas Huth Autocrypt: addr=thuth@redhat.com; keydata= xsFNBFH7eUwBEACzyOXKU+5Pcs6wNpKzrlJwzRl3VGZt95VCdb+FgoU9g11m7FWcOafrVRwU yYkTm9+7zBUc0sW5AuPGR/dp3pSLX/yFWsA/UB4nJsHqgDvDU7BImSeiTrnpMOTXb7Arw2a2 4CflIyFqjCpfDM4MuTmzTjXq4Uov1giGE9X6viNo1pxyEpd7PanlKNnf4PqEQp06X4IgUacW tSGj6Gcns1bCuHV8OPWLkf4hkRnu8hdL6i60Yxz4E6TqlrpxsfYwLXgEeswPHOA6Mn4Cso9O 0lewVYfFfsmokfAVMKWzOl1Sr0KGI5T9CpmRfAiSHpthhHWnECcJFwl72NTi6kUcUzG4se81 O6n9d/kTj7pzTmBdfwuOZ0YUSqcqs0W+l1NcASSYZQaDoD3/SLk+nqVeCBB4OnYOGhgmIHNW 0CwMRO/GK+20alxzk//V9GmIM2ACElbfF8+Uug3pqiHkVnKqM7W9/S1NH2qmxB6zMiJUHlTH gnVeZX0dgH27mzstcF786uPcdEqS0KJuxh2kk5IvUSL3Qn3ZgmgdxBMyCPciD/1cb7/Ahazr 3ThHQXSHXkH/aDXdfLsKVuwDzHLVSkdSnZdt5HHh75/NFHxwaTlydgfHmFFwodK8y/TjyiGZ zg2Kje38xnz8zKn9iesFBCcONXS7txENTzX0z80WKBhK+XSFJwARAQABzR5UaG9tYXMgSHV0 aCA8dGh1dGhAcmVkaGF0LmNvbT7CwXgEEwECACIFAlVgX6oCGwMGCwkIBwMCBhUIAgkKCwQW AgMBAh4BAheAAAoJEC7Z13T+cC21EbIP/ii9cvT2HHGbFRl8HqGT6+7Wkb+XLMqJBMAIGiQK QIP3xk1HPTsLfVG0ao4hy/oYkGNOP8+ubLnZen6Yq3zAFiMhQ44lvgigDYJo3Ve59gfe99KX EbtB+X95ODARkq0McR6OAsPNJ7gpEUzfkQUUJTXRDQXfG/FX303Gvk+YU0spm2tsIKPl6AmV 1CegDljzjycyfJbk418MQmMu2T82kjrkEofUO2a24ed3VGC0/Uz//XCR2ZTo+vBoBUQl41BD eFFtoCSrzo3yPFS+w5fkH9NT8ChdpSlbNS32NhYQhJtr9zjWyFRf0Zk+T/1P7ECn6gTEkp5k ofFIA4MFBc/fXbaDRtBmPB0N9pqTFApIUI4vuFPPO0JDrII9dLwZ6lO9EKiwuVlvr1wwzsgq zJTPBU3qHaUO4d/8G+gD7AL/6T4zi8Jo/GmjBsnYaTzbm94lf0CjXjsOX3seMhaE6WAZOQQG tZHAO1kAPWpaxne+wtgMKthyPLNwelLf+xzGvrIKvLX6QuLoWMnWldu22z2ICVnLQChlR9d6 WW8QFEpo/FK7omuS8KvvopFcOOdlbFMM8Y/8vBgVMSsK6fsYUhruny/PahprPbYGiNIhKqz7 UvgyZVl4pBFjTaz/SbimTk210vIlkDyy1WuS8Zsn0htv4+jQPgo9rqFE4mipJjy/iboDzsFN BFH7eUwBEAC2nzfUeeI8dv0C4qrfCPze6NkryUflEut9WwHhfXCLjtvCjnoGqFelH/PE9NF4 4VPSCdvD1SSmFVzu6T9qWdcwMSaC+e7G/z0/AhBfqTeosAF5XvKQlAb9ZPkdDr7YN0a1XDfa +NgA+JZB4ROyBZFFAwNHT+HCnyzy0v9Sh3BgJJwfpXHH2l3LfncvV8rgFv0bvdr70U+On2XH 5bApOyW1WpIG5KPJlDdzcQTyptOJ1dnEHfwnABEfzI3dNf63rlxsGouX/NFRRRNqkdClQR3K gCwciaXfZ7ir7fF0u1N2UuLsWA8Ei1JrNypk+MRxhbvdQC4tyZCZ8mVDk+QOK6pyK2f4rMf/ WmqxNTtAVmNuZIwnJdjRMMSs4W4w6N/bRvpqtykSqx7VXcgqtv6eqoDZrNuhGbekQA0sAnCJ VPArerAZGArm63o39me/bRUQeQVSxEBmg66yshF9HkcUPGVeC4B0TPwz+HFcVhheo6hoJjLq knFOPLRj+0h+ZL+D0GenyqD3CyuyeTT5dGcNU9qT74bdSr20k/CklvI7S9yoQje8BeQAHtdV cvO8XCLrpGuw9SgOS7OP5oI26a0548M4KldAY+kqX6XVphEw3/6U1KTf7WxW5zYLTtadjISB X9xsRWSU+Yqs3C7oN5TIPSoj9tXMoxZkCIHWvnqGwZ7JhwARAQABwsFfBBgBAgAJBQJR+3lM AhsMAAoJEC7Z13T+cC21hPAQAIsBL9MdGpdEpvXs9CYrBkd6tS9mbaSWj6XBDfA1AEdQkBOn ZH1Qt7HJesk+qNSnLv6+jP4VwqK5AFMrKJ6IjE7jqgzGxtcZnvSjeDGPF1h2CKZQPpTw890k fy18AvgFHkVk2Oylyexw3aOBsXg6ukN44vIFqPoc+YSU0+0QIdYJp/XFsgWxnFIMYwDpxSHS 5fdDxUjsk3UBHZx+IhFjs2siVZi5wnHIqM7eK9abr2cK2weInTBwXwqVWjsXZ4tq5+jQrwDK cvxIcwXdUTLGxc4/Z/VRH1PZSvfQxdxMGmNTGaXVNfdFZjm4fz0mz+OUi6AHC4CZpwnsliGV ODqwX8Y1zic9viSTbKS01ZNp175POyWViUk9qisPZB7ypfSIVSEULrL347qY/hm9ahhqmn17 Ng255syASv3ehvX7iwWDfzXbA0/TVaqwa1YIkec+/8miicV0zMP9siRcYQkyTqSzaTFBBmqD oiT+z+/E59qj/EKfyce3sbC9XLjXv3mHMrq1tKX4G7IJGnS989E/fg6crv6NHae9Ckm7+lSs IQu4bBP2GxiRQ+NV3iV/KU3ebMRzqIC//DCOxzQNFNJAKldPe/bKZMCxEqtVoRkuJtNdp/5a yXFZ6TfE1hGKrDBYAm4vrnZ4CXFSBDllL59cFFOJCkn4Xboj/aVxxJxF30bn In-Reply-To: <20240130140115.135f533d@imammedo.users.ipa.redhat.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 30/01/2024 14.01, Igor Mammedov wrote: > On Mon, 29 Jan 2024 17:44:56 +0100 > Philippe Mathieu-Daudé wrote: > >> Mechanical patch produced running the command documented >> in scripts/coccinelle/cpu_env.cocci_template header. > > > commenting here since, I'm not expert on coccinelle scripts. > > On negative side we are permanently loosing type checking in this area. Not really that much. Have a look at cpu_env(), it has a comment saying: "We validate that CPUArchState follows CPUState in cpu-all.h" So instead of run-time checking, the check should have already been done during compile time, i.e. when you have a valid CPUState pointer, it should be possible to derive a valid CPUArchState pointer from it without much further checking during runtime. > Is it worth it, what gains do we get with this series? It's a small optimization, but why not? > Side note, > QOM cast expenses you are replacing could be negated by disabling > CONFIG_QOM_CAST_DEBUG without killing type check code when it's enabled. > That way you will speed up not only cpuenv access but also all other casts > across the board. Yes, but that checking is enabled by default and does not have such compile-time checks that could be used instead, so I think Philippe's series here is still a good idea. >> Signed-off-by: Philippe Mathieu-Daudé >> --- > ... >> static inline void vmx_clear_nmi_blocking(CPUState *cpu) >> { >> - X86CPU *x86_cpu = X86_CPU(cpu); >> - CPUX86State *env = &x86_cpu->env; >> - >> - env->hflags2 &= ~HF2_NMI_MASK; > >> + cpu_env(cpu)->hflags2 &= ~HF2_NMI_MASK; > > this style of de-referencing return value of macro/function > was discouraged in past and preferred way was 'Foo f = CAST(me); f->some_access > > (it's just imprint speaking, I don't recall where it comes from) I agree, though the new code is perfectly valid, it looks nicer if we'd use a variable here instead. Thomas From xen-devel-bounces@lists.xenproject.org Tue Mar 12 11:25:28 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 11:25:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691783.1078135 (Exim 4.92) (envelope-from ) id 1rk0G8-0003k2-5R; Tue, 12 Mar 2024 11:25:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691783.1078135; Tue, 12 Mar 2024 11:25:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk0G8-0003jv-2m; Tue, 12 Mar 2024 11:25:28 +0000 Received: by outflank-mailman (input) for mailman id 691783; Tue, 12 Mar 2024 11:25:26 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk0G6-0003Jq-C7 for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 11:25:26 +0000 Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [2a00:1450:4864:20::630]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 38e644b2-e063-11ee-afdd-a90da7624cb6; Tue, 12 Mar 2024 12:25:25 +0100 (CET) Received: by mail-ej1-x630.google.com with SMTP id a640c23a62f3a-a4417fa396fso387025666b.1 for ; Tue, 12 Mar 2024 04:25:25 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id rn16-20020a170906d93000b00a441a7a75b5sm3737581ejb.209.2024.03.12.04.25.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 Mar 2024 04:25:25 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 38e644b2-e063-11ee-afdd-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1710242725; x=1710847525; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=x1f1hNNbAJyaikjmoaIR3ZKVQAUoGbmjEBi5wSEkNnc=; b=A1OGhHLs8EU3OVQ0GL2Y1h9ceqDBbEe++wZL9KhWwD2xY637rgyI7rc/IO3z0O3099 rPthkjoWWtw9jYd8Sjs5iUjLbeYj6WXuvnfGMSKKBPiS7BhHG6XvemzmsEvCf2ITuwmM 01FEX8/2yn1NQKD/1JY/TT/mVl/NW+kbZOzkjZTcCM5n43/GqtcGYI17JOaim6kgduUr qsMYqSpkQio5Nyeg2nIQFK12pHuiw3zp5/0uqn6u81yVmku7q+0kSb1zDfQOYIohah7C a3r0Onhr+kW9LSsqyY1BzK6UMrAm5AVVe/U/LpUo6Q6MypzS4EXB69uS2EXEVIS4GJCL YJ7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710242725; x=1710847525; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=x1f1hNNbAJyaikjmoaIR3ZKVQAUoGbmjEBi5wSEkNnc=; b=FQFz0gzINNEUtVArXTrRsiuBDFj5RbwmQd+c31otUNhqq9AFa5IuT/ruvk09zMsE1r RxlZS0Nf2b2EKum9QQ5t3b5bMNl0S+Amy7+LNnpI0+aBqZrcPc23OD+EpYRkyvUT1pG1 jk18ZYX2Lg6OovwS/OKCi1wQvpxOKxgmHHSmZ1jQhFL/GLNpUGtbnFmAmiP27V9WM1yy ipnY5mKVIBwGGLOU0nQZLklBENtMeJiLYO6mcLP86YzGCWuRCYVyz+iWELan6244x6aK LnbMih43H0oOHjfSif0U3gPS9vB6ABFbMCfh1Wkjr9+yw4HQ+a+WISEs/9R8nkKub+2Y gu6w== X-Forwarded-Encrypted: i=1; AJvYcCWarRvwfxCOTWBgpeeWJrRMrHS9m3w+dPaQY8XMBi9vhqFhjICRQ0qv8EcjUnd+SuQoxY+AUcifmaxaBoCVphPkVCSy+M/QvqKHDa0kuNA= X-Gm-Message-State: AOJu0YxGVD56vyNNPFrAHgF6w3pgDzZVDrJS39BJhEuVkH7CjBToVKQq q+YwP3dJ7GPy73/WGugEBvzJHDycaNs6domxqUCo0+sR3T9/ISymVYeOsNNxGg== X-Google-Smtp-Source: AGHT+IGussY1iV27BVX8rdhd4lzvwCNFhFWETP4Anw8wdT9W0o1rF0FFyQOaDACEdAFr++n9WLGjQw== X-Received: by 2002:a17:906:2616:b0:a45:b5a0:f3a with SMTP id h22-20020a170906261600b00a45b5a00f3amr5473258ejc.17.1710242725225; Tue, 12 Mar 2024 04:25:25 -0700 (PDT) Message-ID: Date: Tue, 12 Mar 2024 12:25:24 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH v2] xen/compiler: deviate the inline macro for MISRA C Rule 20.4 Content-Language: en-US To: Nicola Vetrini Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, consulting@bugseng.com, bertrand.marquis@arm.com, julien@xen.org, Andrew Cooper , George Dunlap , Wei Liu , xen-devel@lists.xenproject.org References: <0e48f35eaa95bbba6c2b8219e412bfd6d9c82b52.1710241987.git.nicola.vetrini@bugseng.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <0e48f35eaa95bbba6c2b8219e412bfd6d9c82b52.1710241987.git.nicola.vetrini@bugseng.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 12.03.2024 12:13, Nicola Vetrini wrote: > Rule 20.4 states: "A macro shall not be defined with the same name > as a keyword". > > Defining this macro with the same name as the inline keyword > allows for additionally checking that out-of-lined static inline > functions end up in the correct section while minimizing churn and > has a positive impact on the overall safety. See [1] for additional > context on the motivation of this deviation. > > No functional change. > > [1] https://lore.kernel.org/xen-devel/adaa6d55-266d-4df8-8967-9340080d17e4@citrix.com/ > > Signed-off-by: Nicola Vetrini Acked-by: Jan Beulich with ... > --- a/docs/misra/deviations.rst > +++ b/docs/misra/deviations.rst > @@ -322,6 +322,12 @@ Deviations related to MISRA C:2012 Rules: > - /\* Fallthrough \*/ > - /\* Fallthrough. \*/ > > + * - R20.4 > + - The override of the keyword \"inline\" in xen/compiler.h is present so > + that section contents checks pass when the compiler chooses not to > + inline a particular function. ... padding (1st line of this bullet point) and indentation (2nd and 3rd lines) adjusted to what's used elsewhere, including e.g ... > + - Comment-based deviation. > + > * - R20.7 > - Code violating Rule 20.7 is safe when macro parameters are used: > (1) as function arguments; ... here. Happy to do so while committing. Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 12 11:36:09 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 11:36:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691789.1078145 (Exim 4.92) (envelope-from ) id 1rk0QO-00062K-8M; Tue, 12 Mar 2024 11:36:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691789.1078145; Tue, 12 Mar 2024 11:36:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk0QO-00062D-4h; Tue, 12 Mar 2024 11:36:04 +0000 Received: by outflank-mailman (input) for mailman id 691789; Tue, 12 Mar 2024 11:36:03 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk0QN-000627-4W for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 11:36:03 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id b3a6b649-e064-11ee-a1ee-f123f15fe8a2; Tue, 12 Mar 2024 12:36:01 +0100 (CET) Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) by support.bugseng.com (Postfix) with ESMTPA id A34884EE0C90; Tue, 12 Mar 2024 12:36:00 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b3a6b649-e064-11ee-a1ee-f123f15fe8a2 MIME-Version: 1.0 Date: Tue, 12 Mar 2024 12:36:00 +0100 From: Nicola Vetrini To: Jan Beulich Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, consulting@bugseng.com, bertrand.marquis@arm.com, julien@xen.org, Andrew Cooper , George Dunlap , Wei Liu , xen-devel@lists.xenproject.org Subject: Re: [XEN PATCH v2] xen/compiler: deviate the inline macro for MISRA C Rule 20.4 In-Reply-To: References: <0e48f35eaa95bbba6c2b8219e412bfd6d9c82b52.1710241987.git.nicola.vetrini@bugseng.com> Message-ID: <8dca7b5f7fc564ddbd4a4e97bc9ae5ca@bugseng.com> X-Sender: nicola.vetrini@bugseng.com Organization: BUGSENG s.r.l. Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 2024-03-12 12:25, Jan Beulich wrote: > On 12.03.2024 12:13, Nicola Vetrini wrote: >> Rule 20.4 states: "A macro shall not be defined with the same name >> as a keyword". >> >> Defining this macro with the same name as the inline keyword >> allows for additionally checking that out-of-lined static inline >> functions end up in the correct section while minimizing churn and >> has a positive impact on the overall safety. See [1] for additional >> context on the motivation of this deviation. >> >> No functional change. >> >> [1] >> https://lore.kernel.org/xen-devel/adaa6d55-266d-4df8-8967-9340080d17e4@citrix.com/ >> >> Signed-off-by: Nicola Vetrini > > Acked-by: Jan Beulich > with ... > >> --- a/docs/misra/deviations.rst >> +++ b/docs/misra/deviations.rst >> @@ -322,6 +322,12 @@ Deviations related to MISRA C:2012 Rules: >> - /\* Fallthrough \*/ >> - /\* Fallthrough. \*/ >> >> + * - R20.4 >> + - The override of the keyword \"inline\" in xen/compiler.h is >> present so >> + that section contents checks pass when the compiler chooses >> not to >> + inline a particular function. > > ... padding (1st line of this bullet point) and indentation (2nd and > 3rd > lines) adjusted to what's used elsewhere, including e.g ... > Yeah, sorry. >> + - Comment-based deviation. >> + >> * - R20.7 >> - Code violating Rule 20.7 is safe when macro parameters are >> used: >> (1) as function arguments; > > ... here. Happy to do so while committing. > Thanks, -- Nicola Vetrini, BSc Software Engineer, BUGSENG srl (https://bugseng.com) From xen-devel-bounces@lists.xenproject.org Tue Mar 12 11:49:07 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 11:49:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691793.1078155 (Exim 4.92) (envelope-from ) id 1rk0ct-0008Us-AZ; Tue, 12 Mar 2024 11:48:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691793.1078155; Tue, 12 Mar 2024 11:48:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk0ct-0008Ul-5r; Tue, 12 Mar 2024 11:48:59 +0000 Received: by outflank-mailman (input) for mailman id 691793; Tue, 12 Mar 2024 11:48:58 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk0cs-0008TQ-18 for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 11:48:58 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 8190e005-e066-11ee-afdd-a90da7624cb6; Tue, 12 Mar 2024 12:48:56 +0100 (CET) Received: from truciolo.bugseng.com (unknown [37.162.53.177]) by support.bugseng.com (Postfix) with ESMTPSA id B1F964EE0C90; Tue, 12 Mar 2024 12:48:54 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8190e005-e066-11ee-afdd-a90da7624cb6 From: Federico Serafini To: xen-devel@lists.xenproject.org Cc: consulting@bugseng.com, Federico Serafini , Jan Beulich , Paul Durrant , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu Subject: [XEN RFC] xen: avoid grep fodder define and undef Date: Tue, 12 Mar 2024 12:48:42 +0100 Message-Id: <0002f3df03aac283fa3dc7365e9040ab7ffaee2e.1710242950.git.federico.serafini@bugseng.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Place an "#if 0" before grep fodder definitions and remove the "#undef". This addresses several violations of MISRA C:2012 Rule 5.5 ("Identifiers shall be distinct from macro names"). No functional change. Signed-off-by: Federico Serafini --- Hello, I would like to know what you think about this change. If you want to keep grep fodders as they are, an alternative could be to deviate violations of Rule 5.5 involving the TYPE_SAFE macro. --- xen/include/xen/iommu.h | 5 +---- xen/include/xen/mm-frame.h | 15 +++------------ 2 files changed, 4 insertions(+), 16 deletions(-) diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h index 9621459c63..ef57f31417 100644 --- a/xen/include/xen/iommu.h +++ b/xen/include/xen/iommu.h @@ -33,13 +33,10 @@ TYPE_SAFE(uint64_t, dfn); #define PRI_dfn PRIx64 #define INVALID_DFN _dfn(~0ULL) -#ifndef dfn_t +#if 0 #define dfn_t /* Grep fodder: dfn_t, _dfn() and dfn_x() are defined above */ #define _dfn #define dfn_x -#undef dfn_t -#undef _dfn -#undef dfn_x #endif static inline dfn_t __must_check dfn_add(dfn_t dfn, unsigned long i) diff --git a/xen/include/xen/mm-frame.h b/xen/include/xen/mm-frame.h index c25e836f25..d973aec901 100644 --- a/xen/include/xen/mm-frame.h +++ b/xen/include/xen/mm-frame.h @@ -14,13 +14,10 @@ TYPE_SAFE(unsigned long, mfn); */ #define INVALID_MFN_INITIALIZER { INVALID_MFN_RAW } -#ifndef mfn_t +#if 0 #define mfn_t /* Grep fodder: mfn_t, _mfn() and mfn_x() are defined above */ #define _mfn #define mfn_x -#undef mfn_t -#undef _mfn -#undef mfn_x #endif static inline mfn_t __must_check mfn_add(mfn_t mfn, unsigned long i) @@ -53,13 +50,10 @@ TYPE_SAFE(unsigned long, gfn); */ #define INVALID_GFN_INITIALIZER { INVALID_GFN_RAW } -#ifndef gfn_t +#if 0 #define gfn_t /* Grep fodder: gfn_t, _gfn() and gfn_x() are defined above */ #define _gfn #define gfn_x -#undef gfn_t -#undef _gfn -#undef gfn_x #endif static inline gfn_t __must_check gfn_add(gfn_t gfn, unsigned long i) @@ -85,13 +79,10 @@ static inline bool gfn_eq(gfn_t x, gfn_t y) TYPE_SAFE(unsigned long, pfn); #define PRI_pfn "05lx" -#ifndef pfn_t +#if 0 #define pfn_t /* Grep fodder: pfn_t, _pfn() and pfn_x() are defined above */ #define _pfn #define pfn_x -#undef pfn_t -#undef _pfn -#undef pfn_x #endif #endif /* __XEN_FRAME_NUM_H__ */ -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Tue Mar 12 12:02:41 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 12:02:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691798.1078168 (Exim 4.92) (envelope-from ) id 1rk0pw-0003LX-KJ; Tue, 12 Mar 2024 12:02:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691798.1078168; Tue, 12 Mar 2024 12:02:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk0pw-0003LQ-Gb; Tue, 12 Mar 2024 12:02:28 +0000 Received: by outflank-mailman (input) for mailman id 691798; Tue, 12 Mar 2024 12:02:27 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk0pu-0003LK-Nu for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 12:02:26 +0000 Received: from wfhigh1-smtp.messagingengine.com (wfhigh1-smtp.messagingengine.com [64.147.123.152]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 62775f14-e068-11ee-afdd-a90da7624cb6; Tue, 12 Mar 2024 13:02:24 +0100 (CET) Received: from compute7.internal (compute7.nyi.internal [10.202.2.48]) by mailfhigh.west.internal (Postfix) with ESMTP id AA3791800082; Tue, 12 Mar 2024 08:02:20 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Tue, 12 Mar 2024 08:02:21 -0400 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 12 Mar 2024 08:02:18 -0400 (EDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 62775f14-e068-11ee-afdd-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= invisiblethingslab.com; h=cc:cc:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1710244940; x=1710331340; bh=Ma+2LP1YhgBrzbXr0JBu0zyCAyWKPMM7lw3llKmFuH4=; b= eCh2wtGuB0TwHgnKRYz9qxoXA/1MZ3C2bGFy7TgziQjjA+Aq6i3w+YhNpzvoWVio S5PlijuCHhW7KQWsgR1P7mxdJuKew/TeYJhtCoY/LyNnpMCJbmSUw58FMJq0e9ZT HluKNoF4U+MGiVfYp/0p1skJohuiMhupQYTcknraaUH1SHUs/+erLjvl8WdAd4W8 FLhAcsL6oTPtje3ZUu0bHLVLe87fxw2CefcqEZmp9BAGXg/L8ccxpqJlyNzLjg7k hEJ0xI+OP4CmS9TTI32Kc10jRIuPgCRxBspgTMWWN0IBuwAOW1kbMw45wso9gNWx aKdYS7HJEhKfLEsSq912Hw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1710244940; x=1710331340; bh=Ma+2LP1YhgBrzbXr0JBu0zyCAyWK PMM7lw3llKmFuH4=; b=JOSxxWgQzj5K6P4kPCpETq5A++ufHgAEL6ukiibkGteh MgmQwxicTQSrKopNKyIOHg70tLKc3DQuUm9m7CNQNEFBi1usNBYefynR+OTaI+bB N+P05k1vzKUKqD7rn/JcNebqTKFtqdlFrkoKQBxfUa+LBW6UTnkCgZsh4aZZ2Eb2 sEvbibE8Pw+v/AXQIEZBOrt/d+fnB3r8C86QzUMSizlbu1s/8BWYIi5FIAtk35/w RUYWBUF+ieG2CkRDJ6Ja3+jXqBxbiM1J3oe7Jd0pzB90VAgu+y9WHsz1o2jNhd2n dLM16oxcpNR5uClu/3E9cZbT/XQuPeAWXwUuwx00bQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrjeefgdefhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvvefukfhfgggtuggjsehgtderredttdejnecuhfhrohhmpeforghrvghk ucforghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvh hishhisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpefgudel teefvefhfeehieetleeihfejhfeludevteetkeevtedtvdegueetfeejudenucevlhhush htvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhes ihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhm X-ME-Proxy: Feedback-ID: i1568416f:Fastmail Date: Tue, 12 Mar 2024 13:02:14 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Jan Beulich Cc: Roger Pau =?utf-8?B?TW9ubsOp?= , xen-devel@lists.xenproject.org, Andrew Cooper , Wei Liu , George Dunlap , Julien Grall , Stefano Stabellini Subject: Re: [PATCH] drivers/char: mark XHCI DMA buffers reserved in memory map Message-ID: References: <20240311203431.342530-1-marmarek@invisiblethingslab.com> <6a80ceb6-cc2a-4d8f-9a66-70063923b0ea@suse.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="IuHzY/XwPjfFrxcX" Content-Disposition: inline In-Reply-To: <6a80ceb6-cc2a-4d8f-9a66-70063923b0ea@suse.com> --IuHzY/XwPjfFrxcX Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Mar 2024 13:02:14 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Jan Beulich Cc: Roger Pau =?utf-8?B?TW9ubsOp?= , xen-devel@lists.xenproject.org, Andrew Cooper , Wei Liu , George Dunlap , Julien Grall , Stefano Stabellini Subject: Re: [PATCH] drivers/char: mark XHCI DMA buffers reserved in memory map On Tue, Mar 12, 2024 at 11:53:46AM +0100, Jan Beulich wrote: > On 12.03.2024 11:24, Roger Pau Monn=C3=A9 wrote: > >> --- a/xen/arch/x86/setup.c > >> +++ b/xen/arch/x86/setup.c > >> @@ -1806,6 +1806,9 @@ void asmlinkage __init noreturn __start_xen(unsi= gned long mbi_p) > >> mmio_ro_ranges =3D rangeset_new(NULL, "r/o mmio ranges", > >> RANGESETF_prettyprint_hex); > >> =20 > >> + /* Needs to happen after E820 processing but before IOMMU init */ > >> + xhci_dbc_uart_reserve_ram(); > >=20 > > Overall it might be better if some generic solution for all users of > > iommu_add_extra_reserved_device_memory() could be implemented, >=20 > +1 In that case, is the approach with iommu_get_extra_reserved_device_memory() okay (and a comment that it will have a side effect...) ? > > but I'm > > unsure whether the intention is for the interface to always be used > > against RAM. >=20 > I think we can work from that assumption for now. Ok, I'll add a comment about that. I guess, if needed in the future, iommu_add_extra_reserved_device_memory() can gain an extra parameter to distinguish RAM from non-RAM mappings. BTW should e820_change_range_type() return 1 in case of mapping already having the right type? Otherwise, if one wants to use iommu_add_extra_reserved_device_memory() on already reserved memory, the e820_change_range_type() would fail. --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab --IuHzY/XwPjfFrxcX Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmXwREcACgkQ24/THMrX 1yylzAf+MIXUacgkN2SoiRmIUZUpM7Moa2VIjwXJAzVwoXyoHKfBeJTWCCZ97LzZ sZSp6I0p9VcDNkQ1zFqzrRte0dtExSYK1gAXwZdPdNRnltRnaCuz4hksJG20jSVj nXS18EbPAU4XjgPtARozcCu6LyZpALW7LMzD33aqz2fDTRRRtUljEIDK9Z/4R8Me y2BdxO55JthfpD8eOFFGll+ZG4sP5fRnXbWCqOusf2edJ6B+OlPfSZYIUI4/cpps AG0HqAUYoA1mBFbMG83lHst8+JDZHAP9WmFjxjH+kqf8LDHrcMwuDqH4hvXdvDu8 DA1Jwdzsl0PvH30tvGDb301GWu+SDA== =9uWv -----END PGP SIGNATURE----- --IuHzY/XwPjfFrxcX-- From xen-devel-bounces@lists.xenproject.org Tue Mar 12 12:39:06 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 12:39:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691802.1078179 (Exim 4.92) (envelope-from ) id 1rk1PH-0008Gs-5r; Tue, 12 Mar 2024 12:38:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691802.1078179; Tue, 12 Mar 2024 12:38:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk1PH-0008Gl-1R; Tue, 12 Mar 2024 12:38:59 +0000 Received: by outflank-mailman (input) for mailman id 691802; Tue, 12 Mar 2024 12:38:57 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk1PF-0008Gf-En for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 12:38:57 +0000 Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [2a00:1450:4864:20::236]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 7d1cba2b-e06d-11ee-a1ee-f123f15fe8a2; Tue, 12 Mar 2024 13:38:55 +0100 (CET) Received: by mail-lj1-x236.google.com with SMTP id 38308e7fff4ca-2d4360ab3daso34361601fa.3 for ; Tue, 12 Mar 2024 05:38:55 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id e14-20020a50fb8e000000b00568554e368dsm2352494edq.3.2024.03.12.05.38.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 Mar 2024 05:38:54 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 7d1cba2b-e06d-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1710247134; x=1710851934; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=crhzudeg+owq12jfxhAg6gd30PuK4etyoOCUD402nQg=; b=HKhpsphbXAgWuvFgj27FNsXKmJS2CNQmo2M0fG/CTMYEr9ziA4/DCHDcmb4VMnTEIc /CWJXsgp34yoLJuQm5CqWhRgr/cEEXmB8MMv9LmAmeqCI25jEmAE5dLjlit+EHOXAhH7 bwUxpES5utHLjCqQWqYx3Z1x8bhBTMnLGrAJfPtOBUbh/dP5CEe8uiuH3n/+kvv7kKXj S9G4WJdu9QWHTyWz7pq8batZUPoKCpTrFY1q0hpUpsy4QICmFqVb7PGjbGU9nn8hA2HA 9jIIvblHTsbw75uSUPSnbHo5JeDpdDLCbSjcfN6P2JuyglVTbAELnMG6RiFdrCt3UPC1 z3Fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710247134; x=1710851934; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=crhzudeg+owq12jfxhAg6gd30PuK4etyoOCUD402nQg=; b=qWhwDONqGpA6aB3nwsB0jp+SgKz2KEUeseavYHeVD5odXp+J71Or91XCEbEcS0W9JJ nAFyG8OgzM9fMAGmnHErznGntGPEc7r14Tad/8+v31sJA6MaW7XARlKdjryEGZgtE8Sh EdV/2soO1e7uDBKGEqtgPoE3gzBIKjmSUwf46279KQhw9psO21DDPI8M2uDR2Wn+YdcA LVAQxApojE3BtvuxaBw0+LUUy1nBB1n1CCz1QGTxLHRd4lYj2JkewHpXL+Otm3FCtbtE aXnCZeoh+sC3Gzwc4xQYuf8RVhUQUIyo2mYNVEzwtw44G9AiUr6SF9c0zuKdkhgy+G6l ExUQ== X-Forwarded-Encrypted: i=1; AJvYcCXzfzwyuSwqc0dcXhepyoMae85NpJOo0QE5FxrMzm74HaKSyM3UqDFDHQg+DAV7hv/ppZDTYTigdBkp6JHo+B6UKr0Jh/ArID4x6PcLvo4= X-Gm-Message-State: AOJu0YzVivd184AXVUDjxKg/xFURd1LTVftUMg7+tO8/7a1zZYNh3LzV ttqBwzp3qgLxmSy9z6DTftWjaOu1EKdaDOmXxcAxmettFkAuZph1sPo3MGB9SQ== X-Google-Smtp-Source: AGHT+IE7CMuSKvsY6yJAOq6tRaLpQ2poDTaUNRYRebZp/PPz6PL8tqMYAKXhCcE9IDU1EF1I5bNf7w== X-Received: by 2002:a2e:9612:0:b0:2d4:4bec:3c1b with SMTP id v18-20020a2e9612000000b002d44bec3c1bmr1272333ljh.32.1710247134513; Tue, 12 Mar 2024 05:38:54 -0700 (PDT) Message-ID: <2a04315c-7bb8-4985-8aca-bece9d0d535e@suse.com> Date: Tue, 12 Mar 2024 13:38:53 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] drivers/char: mark XHCI DMA buffers reserved in memory map Content-Language: en-US To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org, Andrew Cooper , Wei Liu , George Dunlap , Julien Grall , Stefano Stabellini References: <20240311203431.342530-1-marmarek@invisiblethingslab.com> <6a80ceb6-cc2a-4d8f-9a66-70063923b0ea@suse.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 12.03.2024 13:02, Marek Marczykowski-Górecki wrote: > On Tue, Mar 12, 2024 at 11:53:46AM +0100, Jan Beulich wrote: >> On 12.03.2024 11:24, Roger Pau Monné wrote: >>>> --- a/xen/arch/x86/setup.c >>>> +++ b/xen/arch/x86/setup.c >>>> @@ -1806,6 +1806,9 @@ void asmlinkage __init noreturn __start_xen(unsigned long mbi_p) >>>> mmio_ro_ranges = rangeset_new(NULL, "r/o mmio ranges", >>>> RANGESETF_prettyprint_hex); >>>> >>>> + /* Needs to happen after E820 processing but before IOMMU init */ >>>> + xhci_dbc_uart_reserve_ram(); >>> >>> Overall it might be better if some generic solution for all users of >>> iommu_add_extra_reserved_device_memory() could be implemented, >> >> +1 > > In that case, is the approach with > iommu_get_extra_reserved_device_memory() okay (and a comment that it > will have a side effect...) ? Counter question: You not having gone that route despite our talking about it on Matrix must have a reason. When seeing this approach I concluded something got in the way. What's the deal? >>> but I'm >>> unsure whether the intention is for the interface to always be used >>> against RAM. >> >> I think we can work from that assumption for now. > > Ok, I'll add a comment about that. I guess, if needed in the future, > iommu_add_extra_reserved_device_memory() can gain an extra parameter to > distinguish RAM from non-RAM mappings. > > BTW should e820_change_range_type() return 1 in case of mapping already > having the right type? Otherwise, if one wants to use > iommu_add_extra_reserved_device_memory() on already reserved memory, the > e820_change_range_type() would fail. You raised that question on Matrix yesterday, iirc, and I left it unanswered there because it takes archeology to find the answer (or at least get closer to one). And, please don't get me wrong, you could as well do that yourself. (My vague recollection from having dealt with similar code in Linux is that yes, in the example given the function ought to indeed have failed back then. Depending on present uses etc it may well be that we could reconsider, though.) Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 12 12:59:04 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 12:59:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691807.1078187 (Exim 4.92) (envelope-from ) id 1rk1ic-0002yX-L4; Tue, 12 Mar 2024 12:58:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691807.1078187; Tue, 12 Mar 2024 12:58:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk1ic-0002yQ-IH; Tue, 12 Mar 2024 12:58:58 +0000 Received: by outflank-mailman (input) for mailman id 691807; Tue, 12 Mar 2024 12:58:57 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk1ib-0002yK-BR for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 12:58:57 +0000 Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [2a00:1450:4864:20::531]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 483bb404-e070-11ee-a1ee-f123f15fe8a2; Tue, 12 Mar 2024 13:58:54 +0100 (CET) Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-5683576ea18so5141667a12.3 for ; Tue, 12 Mar 2024 05:58:54 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id a26-20020aa7cf1a000000b005666465520dsm4013234edy.26.2024.03.12.05.58.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 Mar 2024 05:58:53 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 483bb404-e070-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1710248334; x=1710853134; darn=lists.xenproject.org; h=content-transfer-encoding:autocrypt:content-language:cc:to:subject :from:user-agent:mime-version:date:message-id:from:to:cc:subject :date:message-id:reply-to; bh=AWmWDrEJEcNjx63rF6lgczAz86xnCvV9Z4oBvib0A8Y=; b=RWhPi60hNAcDyUlYrcAt1EhdasOUAeCW63krFc/UHlZA4nnKm5S8FJeC4gT8/3Q4nB EXUSYSHdVa6gMTyIeJtznq+iXmyirwznDVZdmEOsWfu8+xaethkg6cVngIb3bdpqJ8lC s72mpkk/stl01aal+HNQnyY10BkxUe4AAJX3325Bpaj+ywjVSDisT86aHcUUyhe4wmee XMdNgEGkcwB2lAby/6LzXZc7J6uqtglYIppNY9L7zyvcYnh2hkx/L0nVrS/NejrOKmfe Egal7KK5N8uVposdUYew7+gmhfY6byEnGMtpk9RaUkYwHhkFy5Mgxg2OQta+ZHcpZ7A0 iB+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710248334; x=1710853134; h=content-transfer-encoding:autocrypt:content-language:cc:to:subject :from:user-agent:mime-version:date:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=AWmWDrEJEcNjx63rF6lgczAz86xnCvV9Z4oBvib0A8Y=; b=WNiKQiCU4DdE291ga3N9YG/LmGTqwlYzVBx6/7AwOFOEENijRmqZB4wv7jGTCAwCbk NUzt39e9W1IICdZ8xg6bjjf82EzX3T1bZfEwMdC63/g/fDLaEjP0EdPKPFBrVlAoKWaZ VfUFA1O4/rJUn2o/AwvWc3HTw/Sn5HHVsNQo6OAGxiKWSt5X18QHQ9BOc5OUflnikuK5 QkLjeYvPv3EMivhDD+2MuQi7IrlEJ95/2Mp7h3/WdfnpCSuRShg3X9Ets46MJVY8AkCB Qf1Ps2+KvN21jXvf6GOll4MBx0QdSvbOsq3yOTGIOEPm8UKz5fd/SrFKEkC/58tIO9xM GE5g== X-Gm-Message-State: AOJu0Yw+a+fTUC+2I7E5LHSqEJbtbdZg6TwAunagHwmxeTOFqx0DVn9c TFhna3zidWf40YFint8d+qh3ZGAR2vxRgNxYYPgf8qT/2PwE2dv9SNjasuoUQRoEiNF2hZgQRHw = X-Google-Smtp-Source: AGHT+IGNhlaXasu2Ahyc2DADJQLbF0elzGw+nUkj2GixXriUmgDs9vNqC/uoHtzJFjCk3Yomnm80lQ== X-Received: by 2002:a50:c30d:0:b0:565:cc2d:533 with SMTP id a13-20020a50c30d000000b00565cc2d0533mr6427491edb.1.1710248334409; Tue, 12 Mar 2024 05:58:54 -0700 (PDT) Message-ID: <8cfb88de-e0b9-41c3-bf74-e994aaf023d0@suse.com> Date: Tue, 12 Mar 2024 13:58:53 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Jan Beulich Subject: [PATCH v3] x86: amend 'n' debug-key output with SMI count To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Content-Language: en-US Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit ... if available only, of course. Signed-off-by: Jan Beulich --- I don't really like issuing an IPI (and having another cf_check function) here, yet then again this is issued only when the debug key is actually used, and given how simple the handling function is (including that it doesn't use its parameter) it also looks difficult to abuse. --- v3: Invert "verbose" dependency in early_cpu_init(). v2: Actually read each CPU's SMI count in do_nmi_stats(). --- a/xen/arch/x86/cpu/common.c +++ b/xen/arch/x86/cpu/common.c @@ -407,9 +407,15 @@ void __init early_cpu_init(bool verbose) paddr_bits -= (ebx >> 6) & 0x3f; } - if (!(c->x86_vendor & (X86_VENDOR_AMD | X86_VENDOR_HYGON))) + if (!(c->x86_vendor & (X86_VENDOR_AMD | X86_VENDOR_HYGON))) { + uint64_t smi_count; + park_offline_cpus = opt_mce; + if (verbose && !rdmsr_safe(MSR_SMI_COUNT, smi_count)) + setup_force_cpu_cap(X86_FEATURE_SMI_COUNT); + } + initialize_cpu_data(0); } --- a/xen/arch/x86/include/asm/cpufeatures.h +++ b/xen/arch/x86/include/asm/cpufeatures.h @@ -24,7 +24,7 @@ XEN_CPUFEATURE(APERFMPERF, X86_SY XEN_CPUFEATURE(MFENCE_RDTSC, X86_SYNTH( 9)) /* MFENCE synchronizes RDTSC */ XEN_CPUFEATURE(XEN_SMEP, X86_SYNTH(10)) /* SMEP gets used by Xen itself */ XEN_CPUFEATURE(XEN_SMAP, X86_SYNTH(11)) /* SMAP gets used by Xen itself */ -/* Bit 12 unused. */ +XEN_CPUFEATURE(SMI_COUNT, X86_SYNTH(12)) /* MSR_SMI_COUNT exists */ XEN_CPUFEATURE(IND_THUNK_LFENCE, X86_SYNTH(13)) /* Use IND_THUNK_LFENCE */ XEN_CPUFEATURE(IND_THUNK_JMP, X86_SYNTH(14)) /* Use IND_THUNK_JMP */ XEN_CPUFEATURE(SC_NO_BRANCH_HARDEN, X86_SYNTH(15)) /* (Disable) Conditional branch hardening */ --- a/xen/arch/x86/include/asm/msr-index.h +++ b/xen/arch/x86/include/asm/msr-index.h @@ -28,6 +28,8 @@ #define TEST_CTRL_SPLITLOCK_DETECT (_AC(1, ULL) << 29) #define TEST_CTRL_SPLITLOCK_DISABLE (_AC(1, ULL) << 31) +#define MSR_SMI_COUNT 0x00000034 + #define MSR_INTEL_CORE_THREAD_COUNT 0x00000035 #define MSR_CTC_THREAD_MASK 0x0000ffff #define MSR_CTC_CORE_MASK _AC(0xffff0000, U) --- a/xen/arch/x86/nmi.c +++ b/xen/arch/x86/nmi.c @@ -585,15 +585,34 @@ static void cf_check do_nmi_trigger(unsi self_nmi(); } +static DEFINE_PER_CPU(unsigned int, smi_count); + +static void cf_check read_smi_count(void *unused) +{ + unsigned int dummy; + + rdmsr(MSR_SMI_COUNT, this_cpu(smi_count), dummy); +} + static void cf_check do_nmi_stats(unsigned char key) { const struct vcpu *v; unsigned int cpu; bool pend, mask; - printk("CPU\tNMI\n"); + printk("CPU\tNMI%s\n", boot_cpu_has(X86_FEATURE_SMI_COUNT) ? "\tSMI" : ""); + + if ( boot_cpu_has(X86_FEATURE_SMI_COUNT) ) + on_each_cpu(read_smi_count, NULL, 1); + for_each_online_cpu ( cpu ) - printk("%3u\t%3u\n", cpu, per_cpu(nmi_count, cpu)); + { + printk("%3u\t%3u", cpu, per_cpu(nmi_count, cpu)); + if ( boot_cpu_has(X86_FEATURE_SMI_COUNT) ) + printk("\t%3u\n", per_cpu(smi_count, cpu)); + else + printk("\n"); + } if ( !hardware_domain || !(v = domain_vcpu(hardware_domain, 0)) ) return; From xen-devel-bounces@lists.xenproject.org Tue Mar 12 13:03:58 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 13:03:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691812.1078228 (Exim 4.92) (envelope-from ) id 1rk1nS-0005Gw-1W; Tue, 12 Mar 2024 13:03:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691812.1078228; Tue, 12 Mar 2024 13:03:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk1nR-0005Gj-Te; Tue, 12 Mar 2024 13:03:57 +0000 Received: by outflank-mailman (input) for mailman id 691812; Tue, 12 Mar 2024 13:03:56 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk1nP-0004Wa-QK for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 13:03:56 +0000 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by se1-gles-sth1.inumbo.com (Halon) with ESMTP id fa494afa-e070-11ee-afdd-a90da7624cb6; Tue, 12 Mar 2024 14:03:53 +0100 (CET) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 626761007; Tue, 12 Mar 2024 06:04:30 -0700 (PDT) Received: from e125770.cambridge.arm.com (e125770.arm.com [10.1.199.43]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B30EB3F762; Tue, 12 Mar 2024 06:03:51 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fa494afa-e070-11ee-afdd-a90da7624cb6 From: Luca Fancellu To: xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH 03/11] xen/arm: Introduce a generic way to access memory bank structures Date: Tue, 12 Mar 2024 13:03:23 +0000 Message-Id: <20240312130331.78418-4-luca.fancellu@arm.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240312130331.78418-1-luca.fancellu@arm.com> References: <20240312130331.78418-1-luca.fancellu@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Currently the 'stuct meminfo' is defining a static defined array of 'struct membank' of NR_MEM_BANKS elements, some feature like shared memory don't require such amount of memory allocation but might want to reuse existing code to manipulate this kind of structure that is just as 'struct meminfo' but less bulky. For this reason introduce a generic way to access this kind of structure using a new stucture 'struct membanks', which implements all the fields needed by a structure related to memory banks without the need to specify at build time the size of the 'struct membank' array. Modify 'struct meminfo' to implement the field related to the new introduced structure, given the change all usage of this structure are updated in this way: - code accessing bootinfo.{mem,reserved_mem,acpi} field now uses 3 new introduced static inline helpers to access the new field of 'struct meminfo' named 'common'. - code accessing 'struct kernel_info *' member 'mem' now use the new introduced macro 'kernel_info_get_mem(...)' to access the new field of 'struct meminfo' named 'common'. Constify pointers where needed. Suggested-by: Julien Grall Signed-off-by: Luca Fancellu --- xen/arch/arm/acpi/domain_build.c | 6 +- xen/arch/arm/arm32/mmu/mm.c | 44 +++++----- xen/arch/arm/arm64/mmu/mm.c | 2 +- xen/arch/arm/bootfdt.c | 27 +++--- xen/arch/arm/dom0less-build.c | 18 ++-- xen/arch/arm/domain_build.c | 106 +++++++++++++----------- xen/arch/arm/efi/efi-boot.h | 8 +- xen/arch/arm/efi/efi-dom0.c | 13 +-- xen/arch/arm/include/asm/domain_build.h | 2 +- xen/arch/arm/include/asm/kernel.h | 9 ++ xen/arch/arm/include/asm/setup.h | 40 ++++++++- xen/arch/arm/include/asm/static-shmem.h | 4 +- xen/arch/arm/kernel.c | 12 +-- xen/arch/arm/setup.c | 58 +++++++------ xen/arch/arm/static-memory.c | 27 +++--- xen/arch/arm/static-shmem.c | 34 ++++---- 16 files changed, 243 insertions(+), 167 deletions(-) diff --git a/xen/arch/arm/acpi/domain_build.c b/xen/arch/arm/acpi/domain_build.c index b58389ce9e9f..ed895dd8f926 100644 --- a/xen/arch/arm/acpi/domain_build.c +++ b/xen/arch/arm/acpi/domain_build.c @@ -444,14 +444,14 @@ static int __init acpi_create_fadt(struct domain *d, struct membank tbl_add[]) } static int __init estimate_acpi_efi_size(struct domain *d, - struct kernel_info *kinfo) + const struct kernel_info *kinfo) { size_t efi_size, acpi_size, madt_size; u64 addr; struct acpi_table_rsdp *rsdp_tbl; struct acpi_table_header *table; - efi_size = estimate_efi_size(kinfo->mem.nr_banks); + efi_size = estimate_efi_size(kernel_info_get_mem(kinfo)->nr_banks); acpi_size = ROUNDUP(sizeof(struct acpi_table_fadt), 8); acpi_size += ROUNDUP(sizeof(struct acpi_table_stao), 8); @@ -546,7 +546,7 @@ int __init prepare_acpi(struct domain *d, struct kernel_info *kinfo) acpi_map_other_tables(d); acpi_create_efi_system_table(d, tbl_add); - acpi_create_efi_mmap_table(d, &kinfo->mem, tbl_add); + acpi_create_efi_mmap_table(d, kernel_info_get_mem(kinfo), tbl_add); /* Map the EFI and ACPI tables to Dom0 */ rc = map_regions_p2mt(d, diff --git a/xen/arch/arm/arm32/mmu/mm.c b/xen/arch/arm/arm32/mmu/mm.c index cb441ca87c0d..e6bb5d934c16 100644 --- a/xen/arch/arm/arm32/mmu/mm.c +++ b/xen/arch/arm/arm32/mmu/mm.c @@ -41,6 +41,7 @@ static paddr_t __init consider_modules(paddr_t s, paddr_t e, uint32_t size, paddr_t align, int first_mod) { + const struct membanks *reserved_mem = bootinfo_get_reserved_mem(); const struct bootmodules *mi = &bootinfo.modules; int i; int nr; @@ -99,15 +100,14 @@ static paddr_t __init consider_modules(paddr_t s, paddr_t e, * possible kinds of bootmodules. * * When retrieving the corresponding reserved-memory addresses, we - * need to index the bootinfo.reserved_mem bank starting from 0, and - * only counting the reserved-memory modules. Hence, we need to use - * i - nr. + * need to index the reserved_mem bank starting from 0, and only counting + * the reserved-memory modules. Hence, we need to use i - nr. */ nr += mi->nr_mods; - for ( ; i - nr < bootinfo.reserved_mem.nr_banks; i++ ) + for ( ; i - nr < reserved_mem->nr_banks; i++ ) { - paddr_t r_s = bootinfo.reserved_mem.bank[i - nr].start; - paddr_t r_e = r_s + bootinfo.reserved_mem.bank[i - nr].size; + paddr_t r_s = reserved_mem->bank[i - nr].start; + paddr_t r_e = r_s + reserved_mem->bank[i - nr].size; if ( s < r_e && r_s < e ) { @@ -128,17 +128,18 @@ static paddr_t __init consider_modules(paddr_t s, paddr_t e, */ static paddr_t __init fit_xenheap_in_static_heap(uint32_t size, paddr_t align) { + const struct membanks *reserved_mem = bootinfo_get_reserved_mem(); unsigned int i; paddr_t end = 0, aligned_start, aligned_end; paddr_t bank_start, bank_size, bank_end; - for ( i = 0 ; i < bootinfo.reserved_mem.nr_banks; i++ ) + for ( i = 0 ; i < reserved_mem->nr_banks; i++ ) { - if ( bootinfo.reserved_mem.bank[i].type != MEMBANK_STATIC_HEAP ) + if ( reserved_mem->bank[i].type != MEMBANK_STATIC_HEAP ) continue; - bank_start = bootinfo.reserved_mem.bank[i].start; - bank_size = bootinfo.reserved_mem.bank[i].size; + bank_start = reserved_mem->bank[i].start; + bank_size = reserved_mem->bank[i].size; bank_end = bank_start + bank_size; if ( bank_size < size ) @@ -161,13 +162,14 @@ static paddr_t __init fit_xenheap_in_static_heap(uint32_t size, paddr_t align) void __init setup_mm(void) { + const struct membanks *mem = bootinfo_get_mem(); paddr_t ram_start, ram_end, ram_size, e, bank_start, bank_end, bank_size; paddr_t static_heap_end = 0, static_heap_size = 0; unsigned long heap_pages, xenheap_pages, domheap_pages; unsigned int i; const uint32_t ctr = READ_CP32(CTR); - if ( !bootinfo.mem.nr_banks ) + if ( !mem->nr_banks ) panic("No memory bank\n"); /* We only supports instruction caches implementing the IVIPT extension. */ @@ -176,14 +178,14 @@ void __init setup_mm(void) init_pdx(); - ram_start = bootinfo.mem.bank[0].start; - ram_size = bootinfo.mem.bank[0].size; + ram_start = mem->bank[0].start; + ram_size = mem->bank[0].size; ram_end = ram_start + ram_size; - for ( i = 1; i < bootinfo.mem.nr_banks; i++ ) + for ( i = 1; i < mem->nr_banks; i++ ) { - bank_start = bootinfo.mem.bank[i].start; - bank_size = bootinfo.mem.bank[i].size; + bank_start = mem->bank[i].start; + bank_size = mem->bank[i].size; bank_end = bank_start + bank_size; ram_size = ram_size + bank_size; @@ -195,13 +197,15 @@ void __init setup_mm(void) if ( bootinfo.static_heap ) { - for ( i = 0 ; i < bootinfo.reserved_mem.nr_banks; i++ ) + const struct membanks *reserved_mem = bootinfo_get_reserved_mem(); + + for ( i = 0 ; i < reserved_mem->nr_banks; i++ ) { - if ( bootinfo.reserved_mem.bank[i].type != MEMBANK_STATIC_HEAP ) + if ( reserved_mem->bank[i].type != MEMBANK_STATIC_HEAP ) continue; - bank_start = bootinfo.reserved_mem.bank[i].start; - bank_size = bootinfo.reserved_mem.bank[i].size; + bank_start = reserved_mem->bank[i].start; + bank_size = reserved_mem->bank[i].size; bank_end = bank_start + bank_size; static_heap_size += bank_size; diff --git a/xen/arch/arm/arm64/mmu/mm.c b/xen/arch/arm/arm64/mmu/mm.c index d2651c948698..f8aaf4ac18be 100644 --- a/xen/arch/arm/arm64/mmu/mm.c +++ b/xen/arch/arm/arm64/mmu/mm.c @@ -194,7 +194,7 @@ static void __init setup_directmap_mappings(unsigned long base_mfn, void __init setup_mm(void) { - const struct meminfo *banks = &bootinfo.mem; + const struct membanks *banks = bootinfo_get_mem(); paddr_t ram_start = INVALID_PADDR; paddr_t ram_end = 0; paddr_t ram_size = 0; diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c index 35dbdf3384cb..ecbc80d6a112 100644 --- a/xen/arch/arm/bootfdt.c +++ b/xen/arch/arm/bootfdt.c @@ -107,14 +107,14 @@ void __init device_tree_get_reg(const __be32 **cell, uint32_t address_cells, static int __init device_tree_get_meminfo(const void *fdt, int node, const char *prop_name, u32 address_cells, u32 size_cells, - void *data, enum membank_type type) + struct membanks *mem, + enum membank_type type) { const struct fdt_property *prop; unsigned int i, banks; const __be32 *cell; u32 reg_cells = address_cells + size_cells; paddr_t start, size; - struct meminfo *mem = data; if ( !device_tree_node_is_available(fdt, node) ) return 0; @@ -133,10 +133,10 @@ static int __init device_tree_get_meminfo(const void *fdt, int node, cell = (const __be32 *)prop->data; banks = fdt32_to_cpu(prop->len) / (reg_cells * sizeof (u32)); - for ( i = 0; i < banks && mem->nr_banks < NR_MEM_BANKS; i++ ) + for ( i = 0; i < banks && mem->nr_banks < mem->max_banks; i++ ) { device_tree_get_reg(&cell, address_cells, size_cells, &start, &size); - if ( mem == &bootinfo.reserved_mem && + if ( mem == bootinfo_get_reserved_mem() && check_reserved_regions_overlap(start, size) ) return -EINVAL; /* Some DT may describe empty bank, ignore them */ @@ -231,10 +231,10 @@ int __init device_tree_for_each_node(const void *fdt, int node, static int __init process_memory_node(const void *fdt, int node, const char *name, int depth, u32 address_cells, u32 size_cells, - void *data) + struct membanks *mem) { return device_tree_get_meminfo(fdt, node, "reg", address_cells, size_cells, - data, MEMBANK_DEFAULT); + mem, MEMBANK_DEFAULT); } static int __init process_reserved_memory_node(const void *fdt, int node, @@ -259,7 +259,7 @@ static int __init process_reserved_memory(const void *fdt, int node, { return device_tree_for_each_node(fdt, node, process_reserved_memory_node, - &bootinfo.reserved_mem); + bootinfo_get_reserved_mem()); } static void __init process_multiboot_node(const void *fdt, int node, @@ -358,7 +358,7 @@ static int __init process_chosen_node(const void *fdt, int node, rc = device_tree_get_meminfo(fdt, node, "xen,static-heap", address_cells, size_cells, - &bootinfo.reserved_mem, + bootinfo_get_reserved_mem(), MEMBANK_STATIC_HEAP); if ( rc ) return rc; @@ -420,7 +420,7 @@ static int __init process_domain_node(const void *fdt, int node, return 0; return device_tree_get_meminfo(fdt, node, "xen,static-mem", address_cells, - size_cells, &bootinfo.reserved_mem, + size_cells, bootinfo_get_reserved_mem(), MEMBANK_STATIC_DOMAIN); } @@ -438,7 +438,7 @@ static int __init early_scan_node(const void *fdt, if ( !efi_enabled(EFI_BOOT) && device_tree_node_matches(fdt, node, "memory") ) rc = process_memory_node(fdt, node, name, depth, - address_cells, size_cells, &bootinfo.mem); + address_cells, size_cells, bootinfo_get_mem()); else if ( depth == 1 && !dt_node_cmp(name, "reserved-memory") ) rc = process_reserved_memory(fdt, node, name, depth, address_cells, size_cells); @@ -459,8 +459,8 @@ static int __init early_scan_node(const void *fdt, static void __init early_print_info(void) { - struct meminfo *mi = &bootinfo.mem; - struct meminfo *mem_resv = &bootinfo.reserved_mem; + const struct membanks *mi = bootinfo_get_mem(); + const struct membanks *mem_resv = bootinfo_get_reserved_mem(); struct bootmodules *mods = &bootinfo.modules; struct bootcmdlines *cmds = &bootinfo.cmdlines; unsigned int i, j; @@ -537,6 +537,7 @@ static void __init swap_memory_node(void *_a, void *_b, size_t size) */ size_t __init boot_fdt_info(const void *fdt, paddr_t paddr) { + struct membanks *mem = bootinfo_get_mem(); int ret; ret = fdt_check_header(fdt); @@ -554,7 +555,7 @@ size_t __init boot_fdt_info(const void *fdt, paddr_t paddr) * bank in memory first. There is no requirement that the DT will provide * the banks sorted in ascending order. So sort them through. */ - sort(bootinfo.mem.bank, bootinfo.mem.nr_banks, sizeof(struct membank), + sort(mem->bank, mem->nr_banks, sizeof(struct membank), cmp_memory_node, swap_memory_node); early_print_info(); diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c index fb63ec6fd111..0165da6f2986 100644 --- a/xen/arch/arm/dom0less-build.c +++ b/xen/arch/arm/dom0less-build.c @@ -50,6 +50,7 @@ bool __init is_dom0less_mode(void) static void __init allocate_memory(struct domain *d, struct kernel_info *kinfo) { + struct membanks *mem = kernel_info_get_mem(kinfo); unsigned int i; paddr_t bank_size; @@ -57,7 +58,7 @@ static void __init allocate_memory(struct domain *d, struct kernel_info *kinfo) /* Don't want format this as PRIpaddr (16 digit hex) */ (unsigned long)(kinfo->unassigned_mem >> 20), d); - kinfo->mem.nr_banks = 0; + mem->nr_banks = 0; bank_size = MIN(GUEST_RAM0_SIZE, kinfo->unassigned_mem); if ( !allocate_bank_memory(d, kinfo, gaddr_to_gfn(GUEST_RAM0_BASE), bank_size) ) @@ -71,15 +72,15 @@ static void __init allocate_memory(struct domain *d, struct kernel_info *kinfo) if ( kinfo->unassigned_mem ) goto fail; - for( i = 0; i < kinfo->mem.nr_banks; i++ ) + for( i = 0; i < mem->nr_banks; i++ ) { printk(XENLOG_INFO "%pd BANK[%d] %#"PRIpaddr"-%#"PRIpaddr" (%ldMB)\n", d, i, - kinfo->mem.bank[i].start, - kinfo->mem.bank[i].start + kinfo->mem.bank[i].size, + mem->bank[i].start, + mem->bank[i].start + mem->bank[i].size, /* Don't want format this as PRIpaddr (16 digit hex) */ - (unsigned long)(kinfo->mem.bank[i].size >> 20)); + (unsigned long)(mem->bank[i].size >> 20)); } return; @@ -641,12 +642,13 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo) if ( ret ) goto err; - ret = make_memory_node(d, kinfo->fdt, addrcells, sizecells, &kinfo->mem); + ret = make_memory_node(d, kinfo->fdt, addrcells, sizecells, + kernel_info_get_mem(kinfo)); if ( ret ) goto err; ret = make_resv_memory_node(d, kinfo->fdt, addrcells, sizecells, - &kinfo->shm_mem); + &kinfo->shm_mem.common); if ( ret ) goto err; @@ -741,7 +743,7 @@ static int __init alloc_xenstore_evtchn(struct domain *d) static int __init construct_domU(struct domain *d, const struct dt_device_node *node) { - struct kernel_info kinfo = {}; + struct kernel_info kinfo = KERNEL_INFO_INIT; const char *dom0less_enhanced; int rc; u64 mem; diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c index 085d88671ebc..62fcdfbdaff2 100644 --- a/xen/arch/arm/domain_build.c +++ b/xen/arch/arm/domain_build.c @@ -142,6 +142,7 @@ static bool __init insert_11_bank(struct domain *d, struct page_info *pg, unsigned int order) { + struct membanks *mem = kernel_info_get_mem(kinfo); unsigned int i; int res; mfn_t smfn; @@ -158,9 +159,9 @@ static bool __init insert_11_bank(struct domain *d, (unsigned long)(kinfo->unassigned_mem >> 20), order); - if ( kinfo->mem.nr_banks > 0 && + if ( mem->nr_banks > 0 && size < MB(128) && - start + size < kinfo->mem.bank[0].start ) + start + size < mem->bank[0].start ) { D11PRINT("Allocation below bank 0 is too small, not using\n"); goto fail; @@ -172,17 +173,17 @@ static bool __init insert_11_bank(struct domain *d, kinfo->unassigned_mem -= size; - if ( kinfo->mem.nr_banks == 0 ) + if ( mem->nr_banks == 0 ) { - kinfo->mem.bank[0].start = start; - kinfo->mem.bank[0].size = size; - kinfo->mem.nr_banks = 1; + mem->bank[0].start = start; + mem->bank[0].size = size; + mem->nr_banks = 1; return true; } - for( i = 0; i < kinfo->mem.nr_banks; i++ ) + for( i = 0; i < mem->nr_banks; i++ ) { - struct membank *bank = &kinfo->mem.bank[i]; + struct membank *bank = &mem->bank[i]; /* If possible merge new memory into the start of the bank */ if ( bank->start == start+size ) @@ -205,24 +206,24 @@ static bool __init insert_11_bank(struct domain *d, * could have inserted the memory into/before we would already * have done so, so this must be the right place. */ - if ( start + size < bank->start && kinfo->mem.nr_banks < NR_MEM_BANKS ) + if ( start + size < bank->start && mem->nr_banks < mem->max_banks ) { memmove(bank + 1, bank, - sizeof(*bank) * (kinfo->mem.nr_banks - i)); - kinfo->mem.nr_banks++; + sizeof(*bank) * (mem->nr_banks - i)); + mem->nr_banks++; bank->start = start; bank->size = size; return true; } } - if ( i == kinfo->mem.nr_banks && kinfo->mem.nr_banks < NR_MEM_BANKS ) + if ( i == mem->nr_banks && mem->nr_banks < mem->max_banks ) { - struct membank *bank = &kinfo->mem.bank[kinfo->mem.nr_banks]; + struct membank *bank = &mem->bank[mem->nr_banks]; bank->start = start; bank->size = size; - kinfo->mem.nr_banks++; + mem->nr_banks++; return true; } @@ -294,6 +295,7 @@ static void __init allocate_memory_11(struct domain *d, const unsigned int min_low_order = get_order_from_bytes(min_t(paddr_t, dom0_mem, MB(128))); const unsigned int min_order = get_order_from_bytes(MB(4)); + struct membanks *mem = kernel_info_get_mem(kinfo); struct page_info *pg; unsigned int order = get_allocation_size(kinfo->unassigned_mem); unsigned int i; @@ -312,7 +314,7 @@ static void __init allocate_memory_11(struct domain *d, /* Don't want format this as PRIpaddr (16 digit hex) */ (unsigned long)(kinfo->unassigned_mem >> 20)); - kinfo->mem.nr_banks = 0; + mem->nr_banks = 0; /* * First try and allocate the largest thing we can as low as @@ -350,7 +352,7 @@ static void __init allocate_memory_11(struct domain *d, * continue allocating from above the lowmem and fill in banks. */ order = get_allocation_size(kinfo->unassigned_mem); - while ( kinfo->unassigned_mem && kinfo->mem.nr_banks < NR_MEM_BANKS ) + while ( kinfo->unassigned_mem && mem->nr_banks < mem->max_banks ) { pg = alloc_domheap_pages(d, order, lowmem ? MEMF_bits(lowmem_bitsize) : 0); @@ -374,7 +376,7 @@ static void __init allocate_memory_11(struct domain *d, if ( !insert_11_bank(d, kinfo, pg, order) ) { - if ( kinfo->mem.nr_banks == NR_MEM_BANKS ) + if ( mem->nr_banks == mem->max_banks ) /* Nothing more we can do. */ break; @@ -404,14 +406,14 @@ static void __init allocate_memory_11(struct domain *d, panic("Failed to allocate requested dom0 memory. %ldMB unallocated\n", (unsigned long)kinfo->unassigned_mem >> 20); - for( i = 0; i < kinfo->mem.nr_banks; i++ ) + for( i = 0; i < mem->nr_banks; i++ ) { printk("BANK[%d] %#"PRIpaddr"-%#"PRIpaddr" (%ldMB)\n", i, - kinfo->mem.bank[i].start, - kinfo->mem.bank[i].start + kinfo->mem.bank[i].size, + mem->bank[i].start, + mem->bank[i].start + mem->bank[i].size, /* Don't want format this as PRIpaddr (16 digit hex) */ - (unsigned long)(kinfo->mem.bank[i].size >> 20)); + (unsigned long)(mem->bank[i].size >> 20)); } } @@ -419,6 +421,7 @@ static void __init allocate_memory_11(struct domain *d, bool __init allocate_bank_memory(struct domain *d, struct kernel_info *kinfo, gfn_t sgfn, paddr_t tot_size) { + struct membanks *mem = kernel_info_get_mem(kinfo); int res; struct page_info *pg; struct membank *bank; @@ -432,7 +435,7 @@ bool __init allocate_bank_memory(struct domain *d, struct kernel_info *kinfo, if ( tot_size == 0 ) return true; - bank = &kinfo->mem.bank[kinfo->mem.nr_banks]; + bank = &mem->bank[mem->nr_banks]; bank->start = gfn_to_gaddr(sgfn); bank->size = tot_size; @@ -472,7 +475,7 @@ bool __init allocate_bank_memory(struct domain *d, struct kernel_info *kinfo, tot_size -= (1ULL << (PAGE_SHIFT + order)); } - kinfo->mem.nr_banks++; + mem->nr_banks++; kinfo->unassigned_mem -= bank->size; return true; @@ -757,7 +760,7 @@ int __init domain_fdt_begin_node(void *fdt, const char *name, uint64_t unit) int __init make_memory_node(const struct domain *d, void *fdt, int addrcells, int sizecells, - struct meminfo *mem) + const struct membanks *mem) { unsigned int i; int res, reg_size = addrcells + sizecells; @@ -817,12 +820,12 @@ int __init make_memory_node(const struct domain *d, static int __init add_ext_regions(unsigned long s_gfn, unsigned long e_gfn, void *data) { - struct meminfo *ext_regions = data; + struct membanks *ext_regions = data; paddr_t start, size; paddr_t s = pfn_to_paddr(s_gfn); paddr_t e = pfn_to_paddr(e_gfn); - if ( ext_regions->nr_banks >= ARRAY_SIZE(ext_regions->bank) ) + if ( ext_regions->nr_banks >= ext_regions->max_banks ) return 0; /* @@ -864,9 +867,11 @@ static int __init add_ext_regions(unsigned long s_gfn, unsigned long e_gfn, * - grant table space */ static int __init find_unallocated_memory(const struct kernel_info *kinfo, - struct meminfo *ext_regions) + struct membanks *ext_regions) { - const struct meminfo *assign_mem = &kinfo->mem; + const struct membanks *kinfo_mem = kernel_info_get_mem(kinfo); + const struct membanks *mem = bootinfo_get_mem(); + const struct membanks *reserved_mem = bootinfo_get_reserved_mem(); struct rangeset *unalloc_mem; paddr_t start, end; unsigned int i; @@ -879,10 +884,10 @@ static int __init find_unallocated_memory(const struct kernel_info *kinfo, return -ENOMEM; /* Start with all available RAM */ - for ( i = 0; i < bootinfo.mem.nr_banks; i++ ) + for ( i = 0; i < mem->nr_banks; i++ ) { - start = bootinfo.mem.bank[i].start; - end = bootinfo.mem.bank[i].start + bootinfo.mem.bank[i].size; + start = mem->bank[i].start; + end = mem->bank[i].start + mem->bank[i].size; res = rangeset_add_range(unalloc_mem, PFN_DOWN(start), PFN_DOWN(end - 1)); if ( res ) @@ -894,10 +899,10 @@ static int __init find_unallocated_memory(const struct kernel_info *kinfo, } /* Remove RAM assigned to Dom0 */ - for ( i = 0; i < assign_mem->nr_banks; i++ ) + for ( i = 0; i < kinfo_mem->nr_banks; i++ ) { - start = assign_mem->bank[i].start; - end = assign_mem->bank[i].start + assign_mem->bank[i].size; + start = kinfo_mem->bank[i].start; + end = kinfo_mem->bank[i].start + kinfo_mem->bank[i].size; res = rangeset_remove_range(unalloc_mem, PFN_DOWN(start), PFN_DOWN(end - 1)); if ( res ) @@ -909,11 +914,10 @@ static int __init find_unallocated_memory(const struct kernel_info *kinfo, } /* Remove reserved-memory regions */ - for ( i = 0; i < bootinfo.reserved_mem.nr_banks; i++ ) + for ( i = 0; i < reserved_mem->nr_banks; i++ ) { - start = bootinfo.reserved_mem.bank[i].start; - end = bootinfo.reserved_mem.bank[i].start + - bootinfo.reserved_mem.bank[i].size; + start = reserved_mem->bank[i].start; + end = reserved_mem->bank[i].start + reserved_mem->bank[i].size; res = rangeset_remove_range(unalloc_mem, PFN_DOWN(start), PFN_DOWN(end - 1)); if ( res ) @@ -991,7 +995,7 @@ static int __init handle_pci_range(const struct dt_device_node *dev, * - PCI aperture */ static int __init find_memory_holes(const struct kernel_info *kinfo, - struct meminfo *ext_regions) + struct membanks *ext_regions) { struct dt_device_node *np; struct rangeset *mem_holes; @@ -1081,7 +1085,7 @@ out: } static int __init find_domU_holes(const struct kernel_info *kinfo, - struct meminfo *ext_regions) + struct membanks *ext_regions) { unsigned int i; uint64_t bankend; @@ -1093,7 +1097,9 @@ static int __init find_domU_holes(const struct kernel_info *kinfo, { struct membank *ext_bank = &(ext_regions->bank[ext_regions->nr_banks]); - ext_bank->start = ROUNDUP(bankbase[i] + kinfo->mem.bank[i].size, SZ_2M); + ext_bank->start = ROUNDUP(bankbase[i] + + kernel_info_get_mem(kinfo)->bank[i].size, + SZ_2M); bankend = ~0ULL >> (64 - p2m_ipa_bits); bankend = min(bankend, bankbase[i] + banksize[i] - 1); @@ -1121,7 +1127,7 @@ int __init make_hypervisor_node(struct domain *d, gic_interrupt_t intr; int res; void *fdt = kinfo->fdt; - struct meminfo *ext_regions = NULL; + struct membanks *ext_regions = NULL; unsigned int i, nr_ext_regions; dt_dprintk("Create hypervisor node\n"); @@ -1157,10 +1163,12 @@ int __init make_hypervisor_node(struct domain *d, } else { - ext_regions = xzalloc(struct meminfo); + ext_regions = (struct membanks *)xzalloc(struct meminfo); if ( !ext_regions ) return -ENOMEM; + ext_regions->max_banks = NR_MEM_BANKS; + if ( is_domain_direct_mapped(d) ) { if ( !is_iommu_enabled(d) ) @@ -1729,6 +1737,7 @@ static int __init handle_node(struct domain *d, struct kernel_info *kinfo, if ( node == dt_host ) { + const struct membanks *reserved_mem = bootinfo_get_reserved_mem(); int addrcells = dt_child_n_addr_cells(node); int sizecells = dt_child_n_size_cells(node); @@ -1754,7 +1763,8 @@ static int __init handle_node(struct domain *d, struct kernel_info *kinfo, if ( res ) return res; - res = make_memory_node(d, kinfo->fdt, addrcells, sizecells, &kinfo->mem); + res = make_memory_node(d, kinfo->fdt, addrcells, sizecells, + kernel_info_get_mem(kinfo)); if ( res ) return res; @@ -1762,16 +1772,16 @@ static int __init handle_node(struct domain *d, struct kernel_info *kinfo, * Create a second memory node to store the ranges covering * reserved-memory regions. */ - if ( bootinfo.reserved_mem.nr_banks > 0 ) + if ( reserved_mem->nr_banks > 0 ) { res = make_memory_node(d, kinfo->fdt, addrcells, sizecells, - &bootinfo.reserved_mem); + reserved_mem); if ( res ) return res; } res = make_resv_memory_node(d, kinfo->fdt, addrcells, sizecells, - &kinfo->shm_mem); + &kinfo->shm_mem.common); if ( res ) return res; } @@ -2040,7 +2050,7 @@ int __init construct_domain(struct domain *d, struct kernel_info *kinfo) static int __init construct_dom0(struct domain *d) { - struct kernel_info kinfo = {}; + struct kernel_info kinfo = KERNEL_INFO_INIT; int rc; /* Sanity! */ diff --git a/xen/arch/arm/efi/efi-boot.h b/xen/arch/arm/efi/efi-boot.h index 0cb29f90a066..199f5260229d 100644 --- a/xen/arch/arm/efi/efi-boot.h +++ b/xen/arch/arm/efi/efi-boot.h @@ -157,14 +157,14 @@ static void __init *lookup_fdt_config_table(EFI_SYSTEM_TABLE *sys_table) return fdt; } -static bool __init meminfo_add_bank(struct meminfo *mem, +static bool __init meminfo_add_bank(struct membanks *mem, EFI_MEMORY_DESCRIPTOR *desc) { struct membank *bank; paddr_t start = desc->PhysicalStart; paddr_t size = desc->NumberOfPages * EFI_PAGE_SIZE; - if ( mem->nr_banks >= NR_MEM_BANKS ) + if ( mem->nr_banks >= mem->max_banks ) return false; #ifdef CONFIG_ACPI if ( check_reserved_regions_overlap(start, size) ) @@ -198,7 +198,7 @@ static EFI_STATUS __init efi_process_memory_map_bootinfo(EFI_MEMORY_DESCRIPTOR * (desc_ptr->Type == EfiBootServicesCode || desc_ptr->Type == EfiBootServicesData))) ) { - if ( !meminfo_add_bank(&bootinfo.mem, desc_ptr) ) + if ( !meminfo_add_bank(bootinfo_get_mem(), desc_ptr) ) { PrintStr(L"Warning: All " __stringify(NR_MEM_BANKS) " bootinfo mem banks exhausted.\r\n"); @@ -208,7 +208,7 @@ static EFI_STATUS __init efi_process_memory_map_bootinfo(EFI_MEMORY_DESCRIPTOR * #ifdef CONFIG_ACPI else if ( desc_ptr->Type == EfiACPIReclaimMemory ) { - if ( !meminfo_add_bank(&bootinfo.acpi, desc_ptr) ) + if ( !meminfo_add_bank(bootinfo_get_acpi(), desc_ptr) ) { PrintStr(L"Error: All " __stringify(NR_MEM_BANKS) " acpi meminfo mem banks exhausted.\r\n"); diff --git a/xen/arch/arm/efi/efi-dom0.c b/xen/arch/arm/efi/efi-dom0.c index aae0f979112a..baee8ab716cb 100644 --- a/xen/arch/arm/efi/efi-dom0.c +++ b/xen/arch/arm/efi/efi-dom0.c @@ -44,7 +44,7 @@ size_t __init estimate_efi_size(unsigned int mem_nr_banks) unsigned int acpi_mem_nr_banks = 0; if ( !acpi_disabled ) - acpi_mem_nr_banks = bootinfo.acpi.nr_banks; + acpi_mem_nr_banks = bootinfo_get_acpi()->nr_banks; size = ROUNDUP(est_size + ect_size + fw_vendor_size, 8); /* plus 1 for new created tables */ @@ -107,9 +107,10 @@ static void __init fill_efi_memory_descriptor(EFI_MEMORY_DESCRIPTOR *desc, } void __init acpi_create_efi_mmap_table(struct domain *d, - const struct meminfo *mem, + const struct membanks *mem, struct membank tbl_add[]) { + const struct membanks *acpi = bootinfo_get_acpi(); EFI_MEMORY_DESCRIPTOR *desc; unsigned int i; u8 *base_ptr; @@ -122,10 +123,10 @@ void __init acpi_create_efi_mmap_table(struct domain *d, fill_efi_memory_descriptor(desc, EfiConventionalMemory, mem->bank[i].start, mem->bank[i].size); - for ( i = 0; i < bootinfo.acpi.nr_banks; i++, desc++ ) + for ( i = 0; i < acpi->nr_banks; i++, desc++ ) fill_efi_memory_descriptor(desc, EfiACPIReclaimMemory, - bootinfo.acpi.bank[i].start, - bootinfo.acpi.bank[i].size); + acpi->bank[i].start, + acpi->bank[i].size); fill_efi_memory_descriptor(desc, EfiACPIReclaimMemory, d->arch.efi_acpi_gpa, d->arch.efi_acpi_len); @@ -133,7 +134,7 @@ void __init acpi_create_efi_mmap_table(struct domain *d, tbl_add[TBL_MMAP].start = d->arch.efi_acpi_gpa + acpi_get_table_offset(tbl_add, TBL_MMAP); tbl_add[TBL_MMAP].size = sizeof(EFI_MEMORY_DESCRIPTOR) - * (mem->nr_banks + bootinfo.acpi.nr_banks + 1); + * (mem->nr_banks + acpi->nr_banks + 1); } /* Create /hypervisor/uefi node for efi properties. */ diff --git a/xen/arch/arm/include/asm/domain_build.h b/xen/arch/arm/include/asm/domain_build.h index da9e6025f37c..a6f276cc4263 100644 --- a/xen/arch/arm/include/asm/domain_build.h +++ b/xen/arch/arm/include/asm/domain_build.h @@ -15,7 +15,7 @@ int make_cpus_node(const struct domain *d, void *fdt); int make_hypervisor_node(struct domain *d, const struct kernel_info *kinfo, int addrcells, int sizecells); int make_memory_node(const struct domain *d, void *fdt, int addrcells, - int sizecells, struct meminfo *mem); + int sizecells, const struct membanks *mem); int make_psci_node(void *fdt); int make_timer_node(const struct kernel_info *kinfo); void evtchn_allocate(struct domain *d); diff --git a/xen/arch/arm/include/asm/kernel.h b/xen/arch/arm/include/asm/kernel.h index 0a23e86c2d37..d28b843c01a9 100644 --- a/xen/arch/arm/include/asm/kernel.h +++ b/xen/arch/arm/include/asm/kernel.h @@ -78,6 +78,15 @@ struct kernel_info { }; }; +#define kernel_info_get_mem(kinfo) \ + (&(kinfo)->mem.common) + +#define KERNEL_INFO_INIT \ +{ \ + .mem.common.max_banks = NR_MEM_BANKS, \ + .shm_mem.common.max_banks = NR_MEM_BANKS, \ +} + /* * Probe the kernel to detemine its type and select a loader. * diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h index d15a88d2e0d1..a3e1dc8fdb6c 100644 --- a/xen/arch/arm/include/asm/setup.h +++ b/xen/arch/arm/include/asm/setup.h @@ -56,8 +56,14 @@ struct membank { #endif }; -struct meminfo { +struct membanks { unsigned int nr_banks; + unsigned int max_banks; + struct membank bank[]; +}; + +struct meminfo { + struct membanks common; struct membank bank[NR_MEM_BANKS]; }; @@ -107,6 +113,19 @@ struct bootinfo { bool static_heap; }; +#ifdef CONFIG_ACPI +#define BOOTINFO_ACPI_INIT .acpi.common.max_banks = NR_MEM_BANKS, +#else +#define BOOTINFO_ACPI_INIT +#endif + +#define BOOTINFO_INIT \ +{ \ + .mem.common.max_banks = NR_MEM_BANKS, \ + .reserved_mem.common.max_banks = NR_MEM_BANKS, \ + BOOTINFO_ACPI_INIT \ +} + struct map_range_data { struct domain *d; @@ -122,6 +141,23 @@ extern struct bootinfo bootinfo; extern domid_t max_init_domid; +static inline struct membanks *bootinfo_get_mem(void) +{ + return &bootinfo.mem.common; +} + +static inline struct membanks *bootinfo_get_reserved_mem(void) +{ + return &bootinfo.reserved_mem.common; +} + +#ifdef CONFIG_ACPI +static inline struct membanks *bootinfo_get_acpi(void) +{ + return &bootinfo.acpi.common; +} +#endif + void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len); size_t estimate_efi_size(unsigned int mem_nr_banks); @@ -130,7 +166,7 @@ void acpi_create_efi_system_table(struct domain *d, struct membank tbl_add[]); void acpi_create_efi_mmap_table(struct domain *d, - const struct meminfo *mem, + const struct membanks *mem, struct membank tbl_add[]); int acpi_make_efi_nodes(void *fdt, struct membank tbl_add[]); diff --git a/xen/arch/arm/include/asm/static-shmem.h b/xen/arch/arm/include/asm/static-shmem.h index 1536ff18b895..cc6b414ed79b 100644 --- a/xen/arch/arm/include/asm/static-shmem.h +++ b/xen/arch/arm/include/asm/static-shmem.h @@ -8,7 +8,7 @@ #ifdef CONFIG_STATIC_SHM int make_resv_memory_node(const struct domain *d, void *fdt, int addrcells, - int sizecells, const struct meminfo *mem); + int sizecells, const struct membanks *mem); int process_shm(struct domain *d, struct kernel_info *kinfo, const struct dt_device_node *node); @@ -28,7 +28,7 @@ int process_shm_node(const void *fdt, int node, uint32_t address_cells, static inline int make_resv_memory_node(const struct domain *d, void *fdt, int addrcells, int sizecells, - const struct meminfo *mem) + const struct membanks *mem) { return 0; } diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c index bc3e5bd6f940..674388fa11a2 100644 --- a/xen/arch/arm/kernel.c +++ b/xen/arch/arm/kernel.c @@ -45,13 +45,14 @@ static void __init place_modules(struct kernel_info *info, { /* Align DTB and initrd size to 2Mb. Linux only requires 4 byte alignment */ const struct bootmodule *mod = info->initrd_bootmodule; + const struct membanks *mem = kernel_info_get_mem(info); const paddr_t initrd_len = ROUNDUP(mod ? mod->size : 0, MB(2)); const paddr_t dtb_len = ROUNDUP(fdt_totalsize(info->fdt), MB(2)); const paddr_t modsize = initrd_len + dtb_len; /* Convenient */ - const paddr_t rambase = info->mem.bank[0].start; - const paddr_t ramsize = info->mem.bank[0].size; + const paddr_t rambase = mem->bank[0].start; + const paddr_t ramsize = mem->bank[0].size; const paddr_t ramend = rambase + ramsize; const paddr_t kernsize = ROUNDUP(kernend, MB(2)) - kernbase; const paddr_t ram128mb = rambase + MB(128); @@ -96,11 +97,12 @@ static void __init place_modules(struct kernel_info *info, static paddr_t __init kernel_zimage_place(struct kernel_info *info) { + const struct membanks *mem = kernel_info_get_mem(info); paddr_t load_addr; #ifdef CONFIG_ARM_64 if ( (info->type == DOMAIN_64BIT) && (info->zimage.start == 0) ) - return info->mem.bank[0].start + info->zimage.text_offset; + return mem->bank[0].start + info->zimage.text_offset; #endif /* @@ -113,8 +115,8 @@ static paddr_t __init kernel_zimage_place(struct kernel_info *info) { paddr_t load_end; - load_end = info->mem.bank[0].start + info->mem.bank[0].size; - load_end = MIN(info->mem.bank[0].start + MB(128), load_end); + load_end = mem->bank[0].start + mem->bank[0].size; + load_end = MIN(mem->bank[0].start + MB(128), load_end); load_addr = load_end - info->zimage.len; /* Align to 2MB */ diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c index 424744ad5e1a..02bd27eb0c69 100644 --- a/xen/arch/arm/setup.c +++ b/xen/arch/arm/setup.c @@ -48,7 +48,7 @@ #include #include -struct bootinfo __initdata bootinfo; +struct bootinfo __initdata bootinfo = BOOTINFO_INIT; /* * Sanitized version of cpuinfo containing only features available on all @@ -207,6 +207,7 @@ static void __init dt_unreserved_regions(paddr_t s, paddr_t e, void (*cb)(paddr_t ps, paddr_t pe), unsigned int first) { + const struct membanks *reserved_mem = bootinfo_get_reserved_mem(); unsigned int i, nr; int rc; @@ -240,14 +241,14 @@ static void __init dt_unreserved_regions(paddr_t s, paddr_t e, * kinds. * * When retrieving the corresponding reserved-memory addresses - * below, we need to index the bootinfo.reserved_mem bank starting + * below, we need to index the reserved_mem->bank starting * from 0, and only counting the reserved-memory modules. Hence, * we need to use i - nr. */ - for ( ; i - nr < bootinfo.reserved_mem.nr_banks; i++ ) + for ( ; i - nr < reserved_mem->nr_banks; i++ ) { - paddr_t r_s = bootinfo.reserved_mem.bank[i - nr].start; - paddr_t r_e = r_s + bootinfo.reserved_mem.bank[i - nr].size; + paddr_t r_s = reserved_mem->bank[i - nr].start; + paddr_t r_e = r_s + reserved_mem->bank[i - nr].size; if ( s < r_e && r_s < e ) { @@ -264,18 +265,18 @@ static void __init dt_unreserved_regions(paddr_t s, paddr_t e, * TODO: '*_end' could be 0 if the bank/region is at the end of the physical * address space. This is for now not handled as it requires more rework. */ -static bool __init meminfo_overlap_check(struct meminfo *meminfo, +static bool __init meminfo_overlap_check(const struct membanks *mem, paddr_t region_start, paddr_t region_size) { paddr_t bank_start = INVALID_PADDR, bank_end = 0; paddr_t region_end = region_start + region_size; - unsigned int i, bank_num = meminfo->nr_banks; + unsigned int i, bank_num = mem->nr_banks; for ( i = 0; i < bank_num; i++ ) { - bank_start = meminfo->bank[i].start; - bank_end = bank_start + meminfo->bank[i].size; + bank_start = mem->bank[i].start; + bank_end = bank_start + mem->bank[i].size; if ( region_end <= bank_start || region_start >= bank_end ) continue; @@ -339,8 +340,11 @@ void __init fw_unreserved_regions(paddr_t s, paddr_t e, bool __init check_reserved_regions_overlap(paddr_t region_start, paddr_t region_size) { - /* Check if input region is overlapping with bootinfo.reserved_mem banks */ - if ( meminfo_overlap_check(&bootinfo.reserved_mem, + /* + * Check if input region is overlapping with bootinfo_get_reserved_mem() + * banks + */ + if ( meminfo_overlap_check(bootinfo_get_reserved_mem(), region_start, region_size) ) return true; @@ -351,7 +355,7 @@ bool __init check_reserved_regions_overlap(paddr_t region_start, #ifdef CONFIG_ACPI /* Check if input region is overlapping with ACPI EfiACPIReclaimMemory */ - if ( meminfo_overlap_check(&bootinfo.acpi, region_start, region_size) ) + if ( meminfo_overlap_check(bootinfo_get_acpi(), region_start, region_size) ) return true; #endif @@ -580,6 +584,7 @@ static paddr_t __init next_module(paddr_t s, paddr_t *end) void __init init_pdx(void) { + const struct membanks *mem = bootinfo_get_mem(); paddr_t bank_start, bank_size, bank_end; /* @@ -592,18 +597,18 @@ void __init init_pdx(void) uint64_t mask = pdx_init_mask(0x0); int bank; - for ( bank = 0 ; bank < bootinfo.mem.nr_banks; bank++ ) + for ( bank = 0 ; bank < mem->nr_banks; bank++ ) { - bank_start = bootinfo.mem.bank[bank].start; - bank_size = bootinfo.mem.bank[bank].size; + bank_start = mem->bank[bank].start; + bank_size = mem->bank[bank].size; mask |= bank_start | pdx_region_mask(bank_start, bank_size); } - for ( bank = 0 ; bank < bootinfo.mem.nr_banks; bank++ ) + for ( bank = 0 ; bank < mem->nr_banks; bank++ ) { - bank_start = bootinfo.mem.bank[bank].start; - bank_size = bootinfo.mem.bank[bank].size; + bank_start = mem->bank[bank].start; + bank_size = mem->bank[bank].size; if (~mask & pdx_region_mask(bank_start, bank_size)) mask = 0; @@ -611,10 +616,10 @@ void __init init_pdx(void) pfn_pdx_hole_setup(mask >> PAGE_SHIFT); - for ( bank = 0 ; bank < bootinfo.mem.nr_banks; bank++ ) + for ( bank = 0 ; bank < mem->nr_banks; bank++ ) { - bank_start = bootinfo.mem.bank[bank].start; - bank_size = bootinfo.mem.bank[bank].size; + bank_start = mem->bank[bank].start; + bank_size = mem->bank[bank].size; bank_end = bank_start + bank_size; set_pdx_range(paddr_to_pfn(bank_start), @@ -636,18 +641,19 @@ void __init init_pdx(void) void __init populate_boot_allocator(void) { unsigned int i; - const struct meminfo *banks = &bootinfo.mem; + const struct membanks *banks = bootinfo_get_mem(); + const struct membanks *reserved_mem = bootinfo_get_reserved_mem(); paddr_t s, e; if ( bootinfo.static_heap ) { - for ( i = 0 ; i < bootinfo.reserved_mem.nr_banks; i++ ) + for ( i = 0 ; i < reserved_mem->nr_banks; i++ ) { - if ( bootinfo.reserved_mem.bank[i].type != MEMBANK_STATIC_HEAP ) + if ( reserved_mem->bank[i].type != MEMBANK_STATIC_HEAP ) continue; - s = bootinfo.reserved_mem.bank[i].start; - e = s + bootinfo.reserved_mem.bank[i].size; + s = reserved_mem->bank[i].start; + e = s + reserved_mem->bank[i].size; #ifdef CONFIG_ARM_32 /* Avoid the xenheap, note that the xenheap cannot across a bank */ if ( s <= mfn_to_maddr(directmap_mfn_start) && diff --git a/xen/arch/arm/static-memory.c b/xen/arch/arm/static-memory.c index cffbab7241b7..34bd12696a53 100644 --- a/xen/arch/arm/static-memory.c +++ b/xen/arch/arm/static-memory.c @@ -85,6 +85,7 @@ static int __init parse_static_mem_prop(const struct dt_device_node *node, void __init allocate_static_memory(struct domain *d, struct kernel_info *kinfo, const struct dt_device_node *node) { + struct membanks *mem = kernel_info_get_mem(kinfo); u32 addr_cells, size_cells, reg_cells; unsigned int nr_banks, gbank, bank = 0; const uint64_t rambase[] = GUEST_RAM_BANK_BASES; @@ -106,7 +107,7 @@ void __init allocate_static_memory(struct domain *d, struct kernel_info *kinfo, */ gbank = 0; gsize = ramsize[gbank]; - kinfo->mem.bank[gbank].start = rambase[gbank]; + mem->bank[gbank].start = rambase[gbank]; nr_banks = length / (reg_cells * sizeof (u32)); for ( ; bank < nr_banks; bank++ ) @@ -122,7 +123,7 @@ void __init allocate_static_memory(struct domain *d, struct kernel_info *kinfo, while ( 1 ) { /* Map as much as possible the static range to the guest bank */ - if ( !append_static_memory_to_bank(d, &kinfo->mem.bank[gbank], smfn, + if ( !append_static_memory_to_bank(d, &mem->bank[gbank], smfn, min(psize, gsize)) ) goto fail; @@ -153,14 +154,14 @@ void __init allocate_static_memory(struct domain *d, struct kernel_info *kinfo, /* Update to the next guest bank. */ gbank++; gsize = ramsize[gbank]; - kinfo->mem.bank[gbank].start = rambase[gbank]; + mem->bank[gbank].start = rambase[gbank]; } } tot_size += psize; } - kinfo->mem.nr_banks = ++gbank; + mem->nr_banks = ++gbank; kinfo->unassigned_mem -= tot_size; /* @@ -190,6 +191,7 @@ void __init allocate_static_memory(struct domain *d, struct kernel_info *kinfo, void __init assign_static_memory_11(struct domain *d, struct kernel_info *kinfo, const struct dt_device_node *node) { + struct membanks *mem = kernel_info_get_mem(kinfo); u32 addr_cells, size_cells, reg_cells; unsigned int nr_banks, bank = 0; const __be32 *cell; @@ -206,7 +208,7 @@ void __init assign_static_memory_11(struct domain *d, struct kernel_info *kinfo, reg_cells = addr_cells + size_cells; nr_banks = length / (reg_cells * sizeof(u32)); - if ( nr_banks > NR_MEM_BANKS ) + if ( nr_banks > mem->max_banks ) { printk(XENLOG_ERR "%pd: exceed max number of supported guest memory banks.\n", d); @@ -224,15 +226,15 @@ void __init assign_static_memory_11(struct domain *d, struct kernel_info *kinfo, d, bank, pbase, pbase + psize); /* One guest memory bank is matched with one physical memory bank. */ - kinfo->mem.bank[bank].start = pbase; - if ( !append_static_memory_to_bank(d, &kinfo->mem.bank[bank], + mem->bank[bank].start = pbase; + if ( !append_static_memory_to_bank(d, &mem->bank[bank], smfn, psize) ) goto fail; kinfo->unassigned_mem -= psize; } - kinfo->mem.nr_banks = nr_banks; + mem->nr_banks = nr_banks; /* * The property 'memory' should match the amount of memory given to @@ -257,14 +259,15 @@ void __init assign_static_memory_11(struct domain *d, struct kernel_info *kinfo, /* Static memory initialization */ void __init init_staticmem_pages(void) { + const struct membanks *reserved_mem = bootinfo_get_reserved_mem(); unsigned int bank; - for ( bank = 0 ; bank < bootinfo.reserved_mem.nr_banks; bank++ ) + for ( bank = 0 ; bank < reserved_mem->nr_banks; bank++ ) { - if ( bootinfo.reserved_mem.bank[bank].type == MEMBANK_STATIC_DOMAIN ) + if ( reserved_mem->bank[bank].type == MEMBANK_STATIC_DOMAIN ) { - mfn_t bank_start = _mfn(PFN_UP(bootinfo.reserved_mem.bank[bank].start)); - unsigned long bank_pages = PFN_DOWN(bootinfo.reserved_mem.bank[bank].size); + mfn_t bank_start = _mfn(PFN_UP(reserved_mem->bank[bank].start)); + unsigned long bank_pages = PFN_DOWN(reserved_mem->bank[bank].size); mfn_t bank_end = mfn_add(bank_start, bank_pages); if ( mfn_x(bank_end) <= mfn_x(bank_start) ) diff --git a/xen/arch/arm/static-shmem.c b/xen/arch/arm/static-shmem.c index 40a0e860c79d..fdc3bccde402 100644 --- a/xen/arch/arm/static-shmem.c +++ b/xen/arch/arm/static-shmem.c @@ -10,22 +10,23 @@ static int __init acquire_nr_borrower_domain(struct domain *d, paddr_t pbase, paddr_t psize, unsigned long *nr_borrowers) { + const struct membanks *reserved_mem = bootinfo_get_reserved_mem(); unsigned int bank; /* Iterate reserved memory to find requested shm bank. */ - for ( bank = 0 ; bank < bootinfo.reserved_mem.nr_banks; bank++ ) + for ( bank = 0 ; bank < reserved_mem->nr_banks; bank++ ) { - paddr_t bank_start = bootinfo.reserved_mem.bank[bank].start; - paddr_t bank_size = bootinfo.reserved_mem.bank[bank].size; + paddr_t bank_start = reserved_mem->bank[bank].start; + paddr_t bank_size = reserved_mem->bank[bank].size; if ( (pbase == bank_start) && (psize == bank_size) ) break; } - if ( bank == bootinfo.reserved_mem.nr_banks ) + if ( bank == reserved_mem->nr_banks ) return -ENOENT; - *nr_borrowers = bootinfo.reserved_mem.bank[bank].nr_shm_borrowers; + *nr_borrowers = reserved_mem->bank[bank].nr_shm_borrowers; return 0; } @@ -157,17 +158,17 @@ static int __init assign_shared_memory(struct domain *d, return ret; } -static int __init append_shm_bank_to_domain(struct kernel_info *kinfo, +static int __init append_shm_bank_to_domain(struct membanks *shm_mem, paddr_t start, paddr_t size, const char *shm_id) { - if ( kinfo->shm_mem.nr_banks >= NR_MEM_BANKS ) + if ( shm_mem->nr_banks >= shm_mem->max_banks ) return -ENOMEM; - kinfo->shm_mem.bank[kinfo->shm_mem.nr_banks].start = start; - kinfo->shm_mem.bank[kinfo->shm_mem.nr_banks].size = size; - safe_strcpy(kinfo->shm_mem.bank[kinfo->shm_mem.nr_banks].shm_id, shm_id); - kinfo->shm_mem.nr_banks++; + shm_mem->bank[shm_mem->nr_banks].start = start; + shm_mem->bank[shm_mem->nr_banks].size = size; + safe_strcpy(shm_mem->bank[shm_mem->nr_banks].shm_id, shm_id); + shm_mem->nr_banks++; return 0; } @@ -269,7 +270,8 @@ int __init process_shm(struct domain *d, struct kernel_info *kinfo, * Record static shared memory region info for later setting * up shm-node in guest device tree. */ - ret = append_shm_bank_to_domain(kinfo, gbase, psize, shm_id); + ret = append_shm_bank_to_domain(&kinfo->shm_mem.common, gbase, psize, + shm_id); if ( ret ) return ret; } @@ -279,7 +281,7 @@ int __init process_shm(struct domain *d, struct kernel_info *kinfo, static int __init make_shm_memory_node(const struct domain *d, void *fdt, int addrcells, int sizecells, - const struct meminfo *mem) + const struct membanks *mem) { unsigned int i = 0; int res = 0; @@ -350,7 +352,7 @@ int __init process_shm_node(const void *fdt, int node, uint32_t address_cells, const struct fdt_property *prop, *prop_id, *prop_role; const __be32 *cell; paddr_t paddr, gaddr, size, end; - struct meminfo *mem = &bootinfo.reserved_mem; + struct membanks *mem = bootinfo_get_reserved_mem(); unsigned int i; int len; bool owner = false; @@ -460,7 +462,7 @@ int __init process_shm_node(const void *fdt, int node, uint32_t address_cells, if ( i == mem->nr_banks ) { - if ( i < NR_MEM_BANKS ) + if (i < mem->max_banks) { if ( check_reserved_regions_overlap(paddr, size) ) return -EINVAL; @@ -490,7 +492,7 @@ int __init process_shm_node(const void *fdt, int node, uint32_t address_cells, int __init make_resv_memory_node(const struct domain *d, void *fdt, int addrcells, int sizecells, - const struct meminfo *mem) + const struct membanks *mem) { int res = 0; /* Placeholder for reserved-memory\0 */ -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Tue Mar 12 13:03:58 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 13:03:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691811.1078218 (Exim 4.92) (envelope-from ) id 1rk1nP-00050L-P7; Tue, 12 Mar 2024 13:03:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691811.1078218; Tue, 12 Mar 2024 13:03:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk1nP-00050E-LN; Tue, 12 Mar 2024 13:03:55 +0000 Received: by outflank-mailman (input) for mailman id 691811; Tue, 12 Mar 2024 13:03:54 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk1nN-0004WU-Un for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 13:03:53 +0000 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by se1-gles-flk1.inumbo.com (Halon) with ESMTP id f94e0066-e070-11ee-a1ee-f123f15fe8a2; Tue, 12 Mar 2024 14:03:52 +0100 (CET) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id AD98115A1; Tue, 12 Mar 2024 06:04:28 -0700 (PDT) Received: from e125770.cambridge.arm.com (e125770.arm.com [10.1.199.43]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 27FC83F762; Tue, 12 Mar 2024 06:03:50 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f94e0066-e070-11ee-a1ee-f123f15fe8a2 From: Luca Fancellu To: xen-devel@lists.xenproject.org Cc: Penny Zheng , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Penny Zheng Subject: [PATCH 02/11] xen/arm: avoid repetitive checking in process_shm_node Date: Tue, 12 Mar 2024 13:03:22 +0000 Message-Id: <20240312130331.78418-3-luca.fancellu@arm.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240312130331.78418-1-luca.fancellu@arm.com> References: <20240312130331.78418-1-luca.fancellu@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Penny Zheng Putting overlap and overflow checking in the loop is causing repetitive operation, so this commit extracts both checking outside the loop. Signed-off-by: Penny Zheng Signed-off-by: Luca Fancellu --- v1: - Rework of https://patchwork.kernel.org/project/xen-devel/patch/20231206090623.1932275-3-Penny.Zheng@arm.com/ - use strncmp to match the branch above - drop Michal R-by given the change --- xen/arch/arm/static-shmem.c | 39 +++++++++++++++---------------------- 1 file changed, 16 insertions(+), 23 deletions(-) diff --git a/xen/arch/arm/static-shmem.c b/xen/arch/arm/static-shmem.c index cb268cd2edf1..40a0e860c79d 100644 --- a/xen/arch/arm/static-shmem.c +++ b/xen/arch/arm/static-shmem.c @@ -349,7 +349,7 @@ int __init process_shm_node(const void *fdt, int node, uint32_t address_cells, { const struct fdt_property *prop, *prop_id, *prop_role; const __be32 *cell; - paddr_t paddr, gaddr, size; + paddr_t paddr, gaddr, size, end; struct meminfo *mem = &bootinfo.reserved_mem; unsigned int i; int len; @@ -422,6 +422,13 @@ int __init process_shm_node(const void *fdt, int node, uint32_t address_cells, return -EINVAL; } + end = paddr + size; + if ( end <= paddr ) + { + printk("fdt: static shared memory region %s overflow\n", shm_id); + return -EINVAL; + } + for ( i = 0; i < mem->nr_banks; i++ ) { /* @@ -441,30 +448,13 @@ int __init process_shm_node(const void *fdt, int node, uint32_t address_cells, return -EINVAL; } } + else if ( strncmp(shm_id, mem->bank[i].shm_id, MAX_SHM_ID_LENGTH) != 0 ) + continue; else { - paddr_t end = paddr + size; - paddr_t bank_end = mem->bank[i].start + mem->bank[i].size; - - if ( (end <= paddr) || (bank_end <= mem->bank[i].start) ) - { - printk("fdt: static shared memory region %s overflow\n", shm_id); - return -EINVAL; - } - - if ( check_reserved_regions_overlap(paddr, size) ) - return -EINVAL; - else - { - if ( strcmp(shm_id, mem->bank[i].shm_id) != 0 ) - continue; - else - { - printk("fdt: different shared memory region could not share the same shm ID %s\n", - shm_id); - return -EINVAL; - } - } + printk("fdt: different shared memory region could not share the same shm ID %s\n", + shm_id); + return -EINVAL; } } @@ -472,6 +462,9 @@ int __init process_shm_node(const void *fdt, int node, uint32_t address_cells, { if ( i < NR_MEM_BANKS ) { + if ( check_reserved_regions_overlap(paddr, size) ) + return -EINVAL; + /* Static shared memory shall be reserved from any other use. */ safe_strcpy(mem->bank[mem->nr_banks].shm_id, shm_id); mem->bank[mem->nr_banks].start = paddr; -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Tue Mar 12 13:03:58 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 13:03:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691813.1078232 (Exim 4.92) (envelope-from ) id 1rk1nS-0005JM-9Y; Tue, 12 Mar 2024 13:03:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691813.1078232; Tue, 12 Mar 2024 13:03:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk1nS-0005IX-5X; Tue, 12 Mar 2024 13:03:58 +0000 Received: by outflank-mailman (input) for mailman id 691813; Tue, 12 Mar 2024 13:03:56 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk1nQ-0004WU-MH for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 13:03:56 +0000 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by se1-gles-flk1.inumbo.com (Halon) with ESMTP id fafeec37-e070-11ee-a1ee-f123f15fe8a2; Tue, 12 Mar 2024 14:03:54 +0100 (CET) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id AC53F1570; Tue, 12 Mar 2024 06:04:31 -0700 (PDT) Received: from e125770.cambridge.arm.com (e125770.arm.com [10.1.199.43]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 679BE3F762; Tue, 12 Mar 2024 06:03:53 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fafeec37-e070-11ee-a1ee-f123f15fe8a2 From: Luca Fancellu To: xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH 04/11] xen/arm: Conditional compilation of kernel_info.shm_mem member Date: Tue, 12 Mar 2024 13:03:24 +0000 Message-Id: <20240312130331.78418-5-luca.fancellu@arm.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240312130331.78418-1-luca.fancellu@arm.com> References: <20240312130331.78418-1-luca.fancellu@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit The user of shm_mem member of the 'struct kernel_info' is only the code managing the static shared memory feature, which can be compiled out using CONFIG_STATIC_SHM, so in case the feature is not requested, that member won't be used and will waste memory space. To address this issue, protect the member with the Kconfig parameter and modify the signature of the only function using it to remove any reference to the member from outside the static-shmem module. Signed-off-by: Luca Fancellu --- xen/arch/arm/dom0less-build.c | 3 +-- xen/arch/arm/domain_build.c | 3 +-- xen/arch/arm/include/asm/kernel.h | 10 +++++++++- xen/arch/arm/include/asm/static-shmem.h | 11 ++++++----- xen/arch/arm/static-shmem.c | 8 +++++--- 5 files changed, 22 insertions(+), 13 deletions(-) diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c index 0165da6f2986..fe2a771d4984 100644 --- a/xen/arch/arm/dom0less-build.c +++ b/xen/arch/arm/dom0less-build.c @@ -647,8 +647,7 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo) if ( ret ) goto err; - ret = make_resv_memory_node(d, kinfo->fdt, addrcells, sizecells, - &kinfo->shm_mem.common); + ret = make_resv_memory_node(d, kinfo, addrcells, sizecells); if ( ret ) goto err; diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c index 62fcdfbdaff2..b254f252e7cb 100644 --- a/xen/arch/arm/domain_build.c +++ b/xen/arch/arm/domain_build.c @@ -1780,8 +1780,7 @@ static int __init handle_node(struct domain *d, struct kernel_info *kinfo, return res; } - res = make_resv_memory_node(d, kinfo->fdt, addrcells, sizecells, - &kinfo->shm_mem.common); + res = make_resv_memory_node(d, kinfo, addrcells, sizecells); if ( res ) return res; } diff --git a/xen/arch/arm/include/asm/kernel.h b/xen/arch/arm/include/asm/kernel.h index d28b843c01a9..5785da985ccf 100644 --- a/xen/arch/arm/include/asm/kernel.h +++ b/xen/arch/arm/include/asm/kernel.h @@ -39,7 +39,9 @@ struct kernel_info { void *fdt; /* flat device tree */ paddr_t unassigned_mem; /* RAM not (yet) assigned to a bank */ struct meminfo mem; +#ifdef CONFIG_STATIC_SHM struct meminfo shm_mem; +#endif /* kernel entry point */ paddr_t entry; @@ -81,10 +83,16 @@ struct kernel_info { #define kernel_info_get_mem(kinfo) \ (&(kinfo)->mem.common) +#ifdef CONFIG_STATIC_SHM +#define KERNEL_INFO_SHM_MEM_INIT .shm_mem.common.max_banks = NR_MEM_BANKS, +#else +#define KERNEL_INFO_SHM_MEM_INIT +#endif + #define KERNEL_INFO_INIT \ { \ .mem.common.max_banks = NR_MEM_BANKS, \ - .shm_mem.common.max_banks = NR_MEM_BANKS, \ + KERNEL_INFO_SHM_MEM_INIT \ } /* diff --git a/xen/arch/arm/include/asm/static-shmem.h b/xen/arch/arm/include/asm/static-shmem.h index cc6b414ed79b..108cedb55a9f 100644 --- a/xen/arch/arm/include/asm/static-shmem.h +++ b/xen/arch/arm/include/asm/static-shmem.h @@ -7,8 +7,9 @@ #ifdef CONFIG_STATIC_SHM -int make_resv_memory_node(const struct domain *d, void *fdt, int addrcells, - int sizecells, const struct membanks *mem); +int make_resv_memory_node(const struct domain *d, + const struct kernel_info *kinfo, int addrcells, + int sizecells); int process_shm(struct domain *d, struct kernel_info *kinfo, const struct dt_device_node *node); @@ -26,9 +27,9 @@ int process_shm_node(const void *fdt, int node, uint32_t address_cells, #else /* !CONFIG_STATIC_SHM */ -static inline int make_resv_memory_node(const struct domain *d, void *fdt, - int addrcells, int sizecells, - const struct membanks *mem) +static inline int make_resv_memory_node(const struct domain *d, + const struct kernel_info *kinfo, + int addrcells, int sizecells) { return 0; } diff --git a/xen/arch/arm/static-shmem.c b/xen/arch/arm/static-shmem.c index fdc3bccde402..8b7da952be6e 100644 --- a/xen/arch/arm/static-shmem.c +++ b/xen/arch/arm/static-shmem.c @@ -490,13 +490,15 @@ int __init process_shm_node(const void *fdt, int node, uint32_t address_cells, return 0; } -int __init make_resv_memory_node(const struct domain *d, void *fdt, - int addrcells, int sizecells, - const struct membanks *mem) +int __init make_resv_memory_node(const struct domain *d, + const struct kernel_info *kinfo, + int addrcells, int sizecells) { int res = 0; /* Placeholder for reserved-memory\0 */ const char resvbuf[16] = "reserved-memory"; + const struct membanks *mem = &kinfo->shm_mem.common; + void *fdt = kinfo->fdt; if ( mem->nr_banks == 0 ) /* No shared memory provided. */ -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Tue Mar 12 13:03:58 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 13:03:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691810.1078208 (Exim 4.92) (envelope-from ) id 1rk1nN-0004kv-Cm; Tue, 12 Mar 2024 13:03:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691810.1078208; Tue, 12 Mar 2024 13:03:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk1nN-0004ko-9W; Tue, 12 Mar 2024 13:03:53 +0000 Received: by outflank-mailman (input) for mailman id 691810; Tue, 12 Mar 2024 13:03:52 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk1nL-0004Wa-Vl for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 13:03:51 +0000 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by se1-gles-sth1.inumbo.com (Halon) with ESMTP id f8611b0f-e070-11ee-afdd-a90da7624cb6; Tue, 12 Mar 2024 14:03:50 +0100 (CET) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 225A01570; Tue, 12 Mar 2024 06:04:27 -0700 (PDT) Received: from e125770.cambridge.arm.com (e125770.arm.com [10.1.199.43]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 92F9D3F762; Tue, 12 Mar 2024 06:03:48 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f8611b0f-e070-11ee-afdd-a90da7624cb6 From: Luca Fancellu To: xen-devel@lists.xenproject.org Cc: Penny Zheng , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Penny Zheng Subject: [PATCH 01/11] xen/arm: remove stale addr_cells/size_cells in assign_shared_memory Date: Tue, 12 Mar 2024 13:03:21 +0000 Message-Id: <20240312130331.78418-2-luca.fancellu@arm.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240312130331.78418-1-luca.fancellu@arm.com> References: <20240312130331.78418-1-luca.fancellu@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Penny Zheng Function parameters {addr_cells,size_cells} are stale parameters in assign_shared_memory, so we shall remove them. Signed-off-by: Penny Zheng Signed-off-by: Luca Fancellu Reviewed-by: Michal Orzel --- v1: - This is this patch: https://patchwork.kernel.org/project/xen-devel/patch/20231206090623.1932275-2-Penny.Zheng@arm.com/ --- xen/arch/arm/static-shmem.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/xen/arch/arm/static-shmem.c b/xen/arch/arm/static-shmem.c index 9097bc8b1511..cb268cd2edf1 100644 --- a/xen/arch/arm/static-shmem.c +++ b/xen/arch/arm/static-shmem.c @@ -90,7 +90,6 @@ static mfn_t __init acquire_shared_memory_bank(struct domain *d, } static int __init assign_shared_memory(struct domain *d, - uint32_t addr_cells, uint32_t size_cells, paddr_t pbase, paddr_t psize, paddr_t gbase) { @@ -252,7 +251,6 @@ int __init process_shm(struct domain *d, struct kernel_info *kinfo, * specified, so they should be assigned to dom_io. */ ret = assign_shared_memory(owner_dom_io ? dom_io : d, - addr_cells, size_cells, pbase, psize, gbase); if ( ret ) return ret; -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Tue Mar 12 13:03:58 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 13:03:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691809.1078197 (Exim 4.92) (envelope-from ) id 1rk1nM-0004Wm-5r; Tue, 12 Mar 2024 13:03:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691809.1078197; Tue, 12 Mar 2024 13:03:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk1nM-0004Wf-2w; Tue, 12 Mar 2024 13:03:52 +0000 Received: by outflank-mailman (input) for mailman id 691809; Tue, 12 Mar 2024 13:03:51 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk1nL-0004WU-EE for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 13:03:51 +0000 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by se1-gles-flk1.inumbo.com (Halon) with ESMTP id f76ff84c-e070-11ee-a1ee-f123f15fe8a2; Tue, 12 Mar 2024 14:03:49 +0100 (CET) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 8E58A1007; Tue, 12 Mar 2024 06:04:25 -0700 (PDT) Received: from e125770.cambridge.arm.com (e125770.arm.com [10.1.199.43]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 487163F762; Tue, 12 Mar 2024 06:03:47 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f76ff84c-e070-11ee-a1ee-f123f15fe8a2 From: Luca Fancellu To: xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH 00/11] Static shared memory followup v2 - pt1 Date: Tue, 12 Mar 2024 13:03:20 +0000 Message-Id: <20240312130331.78418-1-luca.fancellu@arm.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit This serie is a partial rework of this other serie: https://patchwork.kernel.org/project/xen-devel/cover/20231206090623.1932275-1-Penny.Zheng@arm.com/ The original serie is addressing an issue of the static shared memory feature that impacts the memory footprint of other component when the feature is enabled, another issue impacts the device tree generation for the guests when the feature is enabled and used and the last one is a missing feature that is the option to have a static shared memory region that is not from the host address space. This serie is handling some comment on the original serie and it is splitting the rework in two part, this first part is addressing the memory footprint issue and the device tree generation, there will be a following serie addressing the last missing feature soon. Luca Fancellu (7): xen/arm: Introduce a generic way to access memory bank structures xen/arm: Conditional compilation of kernel_info.shm_mem member xen/arm: Introduce helper for static memory pages xen/arm: Avoid code duplication in find_unallocated_memory xen/arm: Avoid code duplication in check_reserved_regions_overlap xen/arm: Reduce struct membank size on static shared memory xen/arm: List static shared memory regions as /memory nodes Penny Zheng (4): xen/arm: remove stale addr_cells/size_cells in assign_shared_memory xen/arm: avoid repetitive checking in process_shm_node xen/arm: remove shm holes for extended regions xen/arm: fix duplicate /reserved-memory node in Dom0 xen/arch/arm/acpi/domain_build.c | 6 +- xen/arch/arm/arm32/mmu/mm.c | 68 ++++-- xen/arch/arm/arm64/mmu/mm.c | 4 +- xen/arch/arm/bootfdt.c | 28 +-- xen/arch/arm/dom0less-build.c | 24 +- xen/arch/arm/domain_build.c | 187 +++++++++------- xen/arch/arm/efi/efi-boot.h | 8 +- xen/arch/arm/efi/efi-dom0.c | 13 +- xen/arch/arm/include/asm/domain_build.h | 4 +- xen/arch/arm/include/asm/kernel.h | 19 +- xen/arch/arm/include/asm/setup.h | 81 ++++++- xen/arch/arm/include/asm/static-memory.h | 12 + xen/arch/arm/include/asm/static-shmem.h | 49 +++- xen/arch/arm/kernel.c | 12 +- xen/arch/arm/setup.c | 97 +++++--- xen/arch/arm/static-memory.c | 35 ++- xen/arch/arm/static-shmem.c | 270 +++++++++++++++++------ 17 files changed, 634 insertions(+), 283 deletions(-) -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Tue Mar 12 13:03:59 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 13:03:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691814.1078248 (Exim 4.92) (envelope-from ) id 1rk1nT-0005mp-Om; Tue, 12 Mar 2024 13:03:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691814.1078248; Tue, 12 Mar 2024 13:03:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk1nT-0005me-K8; Tue, 12 Mar 2024 13:03:59 +0000 Received: by outflank-mailman (input) for mailman id 691814; Tue, 12 Mar 2024 13:03:57 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk1nR-0004WU-TL for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 13:03:57 +0000 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by se1-gles-flk1.inumbo.com (Halon) with ESMTP id fbd26df8-e070-11ee-a1ee-f123f15fe8a2; Tue, 12 Mar 2024 14:03:56 +0100 (CET) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 01ADE15A1; Tue, 12 Mar 2024 06:04:33 -0700 (PDT) Received: from e125770.cambridge.arm.com (e125770.arm.com [10.1.199.43]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B16933F762; Tue, 12 Mar 2024 06:03:54 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fbd26df8-e070-11ee-a1ee-f123f15fe8a2 From: Luca Fancellu To: xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH 05/11] xen/arm: Introduce helper for static memory pages Date: Tue, 12 Mar 2024 13:03:25 +0000 Message-Id: <20240312130331.78418-6-luca.fancellu@arm.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240312130331.78418-1-luca.fancellu@arm.com> References: <20240312130331.78418-1-luca.fancellu@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Introduce a new helper function in the static-memory module that can be called to manage static memory banks, this is done to reuse the code when other modules would like to manage static memory banks that are not part of the reserved_mem structure. Signed-off-by: Luca Fancellu --- xen/arch/arm/include/asm/static-memory.h | 12 ++++++++++++ xen/arch/arm/static-memory.c | 12 +----------- 2 files changed, 13 insertions(+), 11 deletions(-) diff --git a/xen/arch/arm/include/asm/static-memory.h b/xen/arch/arm/include/asm/static-memory.h index 3e3efd70c38d..665d4df50eda 100644 --- a/xen/arch/arm/include/asm/static-memory.h +++ b/xen/arch/arm/include/asm/static-memory.h @@ -7,6 +7,18 @@ #ifdef CONFIG_STATIC_MEMORY +static inline void init_staticmem_bank(const struct membank *bank) +{ + mfn_t bank_start = _mfn(PFN_UP(bank->start)); + unsigned long bank_pages = PFN_DOWN(bank->size); + mfn_t bank_end = mfn_add(bank_start, bank_pages); + + if ( mfn_x(bank_end) <= mfn_x(bank_start) ) + return; + + unprepare_staticmem_pages(mfn_to_page(bank_start), bank_pages, false); +} + void allocate_static_memory(struct domain *d, struct kernel_info *kinfo, const struct dt_device_node *node); void assign_static_memory_11(struct domain *d, struct kernel_info *kinfo, diff --git a/xen/arch/arm/static-memory.c b/xen/arch/arm/static-memory.c index 34bd12696a53..d4585c5a0633 100644 --- a/xen/arch/arm/static-memory.c +++ b/xen/arch/arm/static-memory.c @@ -265,17 +265,7 @@ void __init init_staticmem_pages(void) for ( bank = 0 ; bank < reserved_mem->nr_banks; bank++ ) { if ( reserved_mem->bank[bank].type == MEMBANK_STATIC_DOMAIN ) - { - mfn_t bank_start = _mfn(PFN_UP(reserved_mem->bank[bank].start)); - unsigned long bank_pages = PFN_DOWN(reserved_mem->bank[bank].size); - mfn_t bank_end = mfn_add(bank_start, bank_pages); - - if ( mfn_x(bank_end) <= mfn_x(bank_start) ) - return; - - unprepare_staticmem_pages(mfn_to_page(bank_start), - bank_pages, false); - } + init_staticmem_bank(&reserved_mem->bank[bank]); } } -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Tue Mar 12 13:04:02 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 13:04:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691816.1078267 (Exim 4.92) (envelope-from ) id 1rk1nW-0006Kk-A2; Tue, 12 Mar 2024 13:04:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691816.1078267; Tue, 12 Mar 2024 13:04:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk1nW-0006KC-4L; Tue, 12 Mar 2024 13:04:02 +0000 Received: by outflank-mailman (input) for mailman id 691816; Tue, 12 Mar 2024 13:04:00 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk1nU-0004WU-8K for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 13:04:00 +0000 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by se1-gles-flk1.inumbo.com (Halon) with ESMTP id fd46804e-e070-11ee-a1ee-f123f15fe8a2; Tue, 12 Mar 2024 14:03:58 +0100 (CET) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 949DD1007; Tue, 12 Mar 2024 06:04:35 -0700 (PDT) Received: from e125770.cambridge.arm.com (e125770.arm.com [10.1.199.43]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 5044E3F762; Tue, 12 Mar 2024 06:03:57 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fd46804e-e070-11ee-a1ee-f123f15fe8a2 From: Luca Fancellu To: xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH 07/11] xen/arm: Avoid code duplication in check_reserved_regions_overlap Date: Tue, 12 Mar 2024 13:03:27 +0000 Message-Id: <20240312130331.78418-8-luca.fancellu@arm.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240312130331.78418-1-luca.fancellu@arm.com> References: <20240312130331.78418-1-luca.fancellu@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit The function check_reserved_regions_overlap is calling 'meminfo_overlap_check' on the same type of structure, this code can be written in a way to avoid code duplication, so rework the function to do that. Signed-off-by: Luca Fancellu --- xen/arch/arm/setup.c | 24 +++++++++++++----------- 1 file changed, 13 insertions(+), 11 deletions(-) diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c index 02bd27eb0c69..cc719d508d63 100644 --- a/xen/arch/arm/setup.c +++ b/xen/arch/arm/setup.c @@ -340,25 +340,27 @@ void __init fw_unreserved_regions(paddr_t s, paddr_t e, bool __init check_reserved_regions_overlap(paddr_t region_start, paddr_t region_size) { + const struct membanks *mem_banks[] = { + bootinfo_get_reserved_mem(), +#ifdef CONFIG_ACPI + bootinfo_get_acpi(), +#endif + }; + unsigned int i; + /* - * Check if input region is overlapping with bootinfo_get_reserved_mem() - * banks + * Check if input region is overlapping with reserved memory banks or + * ACPI EfiACPIReclaimMemory (when ACPI feature is enabled) */ - if ( meminfo_overlap_check(bootinfo_get_reserved_mem(), - region_start, region_size) ) - return true; + for ( i = 0; i < ARRAY_SIZE(mem_banks); i++ ) + if ( meminfo_overlap_check(mem_banks[i], region_start, region_size) ) + return true; /* Check if input region is overlapping with bootmodules */ if ( bootmodules_overlap_check(&bootinfo.modules, region_start, region_size) ) return true; -#ifdef CONFIG_ACPI - /* Check if input region is overlapping with ACPI EfiACPIReclaimMemory */ - if ( meminfo_overlap_check(bootinfo_get_acpi(), region_start, region_size) ) - return true; -#endif - return false; } -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Tue Mar 12 13:04:04 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 13:04:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691817.1078277 (Exim 4.92) (envelope-from ) id 1rk1nX-0006cV-KY; Tue, 12 Mar 2024 13:04:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691817.1078277; Tue, 12 Mar 2024 13:04:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk1nX-0006cL-HQ; Tue, 12 Mar 2024 13:04:03 +0000 Received: by outflank-mailman (input) for mailman id 691817; Tue, 12 Mar 2024 13:04:02 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk1nW-0004WU-5c for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 13:04:02 +0000 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by se1-gles-flk1.inumbo.com (Halon) with ESMTP id fe100bcb-e070-11ee-a1ee-f123f15fe8a2; Tue, 12 Mar 2024 14:03:59 +0100 (CET) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id DED511570; Tue, 12 Mar 2024 06:04:36 -0700 (PDT) Received: from e125770.cambridge.arm.com (e125770.arm.com [10.1.199.43]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 9A77D3F762; Tue, 12 Mar 2024 06:03:58 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fe100bcb-e070-11ee-a1ee-f123f15fe8a2 From: Luca Fancellu To: xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH 08/11] xen/arm: Reduce struct membank size on static shared memory Date: Tue, 12 Mar 2024 13:03:28 +0000 Message-Id: <20240312130331.78418-9-luca.fancellu@arm.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240312130331.78418-1-luca.fancellu@arm.com> References: <20240312130331.78418-1-luca.fancellu@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Currently the memory footprint of the static shared memory feature is impacting all the struct meminfo instances with memory space that is not going to be used. To solve this issue, rework the static shared memory extra information linked to the memory bank to another structure, struct shmem_membank_extra, and exploit the struct membank padding to host a pointer to that structure in a union with the enum membank_type, with this trick the 'struct membank' has the same size with or without the static shared memory, given that the 'type' and 'shmem_extra' are never used at the same time. Afterwards, create a new structure 'struct shared_meminfo' which has the same interface of 'struct meminfo', but requires less banks and hosts the extra information for the static shared memory. The fields 'bank' and 'extra' of this structure are meant to be linked by the index (e.g. extra[idx] will have the information for the bank[idx], for i=0..NR_SHMEM_BANKS), the convinient pointer 'shmem_extra' of 'struct membank' is then linked to the related 'extra' bank to ease the fruition when a function has access only to the 'struct membanks common' of 'struct shared_meminfo'. The last part of this work is to move the allocation of the static shared memory banks from the 'reserved_mem' to a new 'shmem' member of the 'struct bootinfo'. Change also the 'shm_mem' member type to be 'struct shared_meminfo' in order to match the above changes and allow a memory space reduction also in 'struct kernel_info'. Signed-off-by: Luca Fancellu --- xen/arch/arm/arm32/mmu/mm.c | 24 +++++++++ xen/arch/arm/arm64/mmu/mm.c | 2 + xen/arch/arm/bootfdt.c | 1 + xen/arch/arm/domain_build.c | 4 ++ xen/arch/arm/include/asm/kernel.h | 4 +- xen/arch/arm/include/asm/setup.h | 41 +++++++++++++-- xen/arch/arm/include/asm/static-shmem.h | 8 +++ xen/arch/arm/setup.c | 25 ++++++++- xen/arch/arm/static-shmem.c | 69 ++++++++++++++++++------- 9 files changed, 154 insertions(+), 24 deletions(-) diff --git a/xen/arch/arm/arm32/mmu/mm.c b/xen/arch/arm/arm32/mmu/mm.c index e6bb5d934c16..45e42b307e20 100644 --- a/xen/arch/arm/arm32/mmu/mm.c +++ b/xen/arch/arm/arm32/mmu/mm.c @@ -7,6 +7,7 @@ #include #include #include +#include static unsigned long opt_xenheap_megabytes __initdata; integer_param("xenheap_megabytes", opt_xenheap_megabytes); @@ -42,6 +43,9 @@ static paddr_t __init consider_modules(paddr_t s, paddr_t e, int first_mod) { const struct membanks *reserved_mem = bootinfo_get_reserved_mem(); +#ifdef CONFIG_STATIC_SHM + const struct membanks *shmem = bootinfo_get_shmem(); +#endif const struct bootmodules *mi = &bootinfo.modules; int i; int nr; @@ -118,6 +122,25 @@ static paddr_t __init consider_modules(paddr_t s, paddr_t e, return consider_modules(s, r_s, size, align, i + 1); } } + +#ifdef CONFIG_STATIC_SHM + nr += reserved_mem->nr_banks; + for ( ; i - nr < shmem->nr_banks; i++ ) + { + paddr_t r_s = shmem->bank[i - nr].start; + paddr_t r_e = r_s + shmem->bank[i - nr].size; + + if ( s < r_e && r_s < e ) + { + r_e = consider_modules(r_e, e, size, align, i + 1); + if ( r_e ) + return r_e; + + return consider_modules(s, r_s, size, align, i + 1); + } + } +#endif + return e; } @@ -294,6 +317,7 @@ void __init setup_mm(void) mfn_to_maddr(directmap_mfn_end)); init_staticmem_pages(); + init_sharedmem_pages(); } /* diff --git a/xen/arch/arm/arm64/mmu/mm.c b/xen/arch/arm/arm64/mmu/mm.c index f8aaf4ac18be..293acb67e09c 100644 --- a/xen/arch/arm/arm64/mmu/mm.c +++ b/xen/arch/arm/arm64/mmu/mm.c @@ -6,6 +6,7 @@ #include #include +#include /* Override macros from asm/page.h to make them work with mfn_t */ #undef virt_to_mfn @@ -236,6 +237,7 @@ void __init setup_mm(void) max_page = PFN_DOWN(ram_end); init_staticmem_pages(); + init_sharedmem_pages(); } /* diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c index ecbc80d6a112..f2344863062e 100644 --- a/xen/arch/arm/bootfdt.c +++ b/xen/arch/arm/bootfdt.c @@ -499,6 +499,7 @@ static void __init early_print_info(void) mem_resv->bank[j].start, mem_resv->bank[j].start + mem_resv->bank[j].size - 1); } + early_print_info_shmem(); printk("\n"); for ( i = 0 ; i < cmds->nr_mods; i++ ) printk("CMDLINE[%"PRIpaddr"]:%s %s\n", cmds->cmdline[i].start, diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c index d0f2ac6060eb..9fad9e8b2c40 100644 --- a/xen/arch/arm/domain_build.c +++ b/xen/arch/arm/domain_build.c @@ -864,6 +864,7 @@ static int __init add_ext_regions(unsigned long s_gfn, unsigned long e_gfn, * regions we exclude every region assigned to Dom0 from the Host RAM: * - domain RAM * - reserved-memory + * - static shared memory * - grant table space */ static int __init find_unallocated_memory(const struct kernel_info *kinfo, @@ -873,6 +874,9 @@ static int __init find_unallocated_memory(const struct kernel_info *kinfo, bootinfo_get_mem(), kernel_info_get_mem(kinfo), bootinfo_get_reserved_mem(), +#ifdef CONFIG_STATIC_SHM + bootinfo_get_shmem(), +#endif }; struct rangeset *unalloc_mem; paddr_t start, end; diff --git a/xen/arch/arm/include/asm/kernel.h b/xen/arch/arm/include/asm/kernel.h index 5785da985ccf..937ffcefc73f 100644 --- a/xen/arch/arm/include/asm/kernel.h +++ b/xen/arch/arm/include/asm/kernel.h @@ -40,7 +40,7 @@ struct kernel_info { paddr_t unassigned_mem; /* RAM not (yet) assigned to a bank */ struct meminfo mem; #ifdef CONFIG_STATIC_SHM - struct meminfo shm_mem; + struct shared_meminfo shm_mem; #endif /* kernel entry point */ @@ -84,7 +84,7 @@ struct kernel_info { (&(kinfo)->mem.common) #ifdef CONFIG_STATIC_SHM -#define KERNEL_INFO_SHM_MEM_INIT .shm_mem.common.max_banks = NR_MEM_BANKS, +#define KERNEL_INFO_SHM_MEM_INIT .shm_mem.common.max_banks = NR_SHMEM_BANKS, #else #define KERNEL_INFO_SHM_MEM_INIT #endif diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h index a3e1dc8fdb6c..07011bd776da 100644 --- a/xen/arch/arm/include/asm/setup.h +++ b/xen/arch/arm/include/asm/setup.h @@ -9,6 +9,7 @@ #define MAX_FDT_SIZE SZ_2M #define NR_MEM_BANKS 256 +#define NR_SHMEM_BANKS 32 #define MAX_MODULES 32 /* Current maximum useful modules */ @@ -46,14 +47,20 @@ enum membank_type { /* Indicates the maximum number of characters(\0 included) for shm_id */ #define MAX_SHM_ID_LENGTH 16 +struct shmem_membank_extra { + char shm_id[MAX_SHM_ID_LENGTH]; + unsigned int nr_shm_borrowers; +}; + struct membank { paddr_t start; paddr_t size; - enum membank_type type; + union { + enum membank_type type; #ifdef CONFIG_STATIC_SHM - char shm_id[MAX_SHM_ID_LENGTH]; - unsigned int nr_shm_borrowers; + struct shmem_membank_extra *shmem_extra; #endif + }; }; struct membanks { @@ -67,6 +74,12 @@ struct meminfo { struct membank bank[NR_MEM_BANKS]; }; +struct shared_meminfo { + struct membanks common; + struct membank bank[NR_SHMEM_BANKS]; + struct shmem_membank_extra extra[NR_SHMEM_BANKS]; +}; + /* * The domU flag is set for kernels and ramdisks of "xen,domain" nodes. * The purpose of the domU flag is to avoid getting confused in @@ -109,6 +122,9 @@ struct bootinfo { struct bootcmdlines cmdlines; #ifdef CONFIG_ACPI struct meminfo acpi; +#endif +#ifdef CONFIG_STATIC_SHM + struct shared_meminfo shmem; #endif bool static_heap; }; @@ -119,11 +135,18 @@ struct bootinfo { #define BOOTINFO_ACPI_INIT #endif +#ifdef CONFIG_STATIC_SHM +#define BOOTINFO_SHMEM_INIT .shmem.common.max_banks = NR_SHMEM_BANKS, +#else +#define BOOTINFO_SHMEM_INIT +#endif + #define BOOTINFO_INIT \ { \ .mem.common.max_banks = NR_MEM_BANKS, \ .reserved_mem.common.max_banks = NR_MEM_BANKS, \ BOOTINFO_ACPI_INIT \ + BOOTINFO_SHMEM_INIT \ } struct map_range_data @@ -158,6 +181,18 @@ static inline struct membanks *bootinfo_get_acpi(void) } #endif +#ifdef CONFIG_STATIC_SHM +static inline struct membanks *bootinfo_get_shmem(void) +{ + return &bootinfo.shmem.common; +} + +static inline struct shmem_membank_extra *bootinfo_get_shmem_extra(void) +{ + return bootinfo.shmem.extra; +} +#endif + void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len); size_t estimate_efi_size(unsigned int mem_nr_banks); diff --git a/xen/arch/arm/include/asm/static-shmem.h b/xen/arch/arm/include/asm/static-shmem.h index 108cedb55a9f..c6fac9906656 100644 --- a/xen/arch/arm/include/asm/static-shmem.h +++ b/xen/arch/arm/include/asm/static-shmem.h @@ -25,6 +25,10 @@ static inline int process_shm_chosen(struct domain *d, int process_shm_node(const void *fdt, int node, uint32_t address_cells, uint32_t size_cells); +void early_print_info_shmem(void); + +void init_sharedmem_pages(void); + #else /* !CONFIG_STATIC_SHM */ static inline int make_resv_memory_node(const struct domain *d, @@ -53,6 +57,10 @@ static inline int process_shm_node(const void *fdt, int node, return -EINVAL; } +static inline void early_print_info_shmem(void) {}; + +static inline void init_sharedmem_pages(void) {}; + #endif /* CONFIG_STATIC_SHM */ #endif /* __ASM_STATIC_SHMEM_H_ */ diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c index cc719d508d63..111172a8c4b1 100644 --- a/xen/arch/arm/setup.c +++ b/xen/arch/arm/setup.c @@ -208,6 +208,9 @@ static void __init dt_unreserved_regions(paddr_t s, paddr_t e, unsigned int first) { const struct membanks *reserved_mem = bootinfo_get_reserved_mem(); +#ifdef CONFIG_STATIC_SHM + const struct membanks *shmem = bootinfo_get_shmem(); +#endif unsigned int i, nr; int rc; @@ -258,6 +261,22 @@ static void __init dt_unreserved_regions(paddr_t s, paddr_t e, } } +#ifdef CONFIG_STATIC_SHM + nr += reserved_mem->nr_banks; + for ( ; i - nr < shmem->nr_banks; i++ ) + { + paddr_t r_s = shmem->bank[i - nr].start; + paddr_t r_e = r_s + shmem->bank[i - nr].size; + + if ( s < r_e && r_s < e ) + { + dt_unreserved_regions(r_e, e, cb, i + 1); + dt_unreserved_regions(s, r_s, cb, i + 1); + return; + } + } +#endif + cb(s, e); } @@ -344,13 +363,17 @@ bool __init check_reserved_regions_overlap(paddr_t region_start, bootinfo_get_reserved_mem(), #ifdef CONFIG_ACPI bootinfo_get_acpi(), +#endif +#ifdef CONFIG_STATIC_SHM + bootinfo_get_shmem(), #endif }; unsigned int i; /* * Check if input region is overlapping with reserved memory banks or - * ACPI EfiACPIReclaimMemory (when ACPI feature is enabled) + * ACPI EfiACPIReclaimMemory (when ACPI feature is enabled) or static + * shared memory banks (when static shared memory feature is enabled) */ for ( i = 0; i < ARRAY_SIZE(mem_banks); i++ ) if ( meminfo_overlap_check(mem_banks[i], region_start, region_size) ) diff --git a/xen/arch/arm/static-shmem.c b/xen/arch/arm/static-shmem.c index 8b7da952be6e..6143f52cb991 100644 --- a/xen/arch/arm/static-shmem.c +++ b/xen/arch/arm/static-shmem.c @@ -4,29 +4,30 @@ #include #include +#include #include static int __init acquire_nr_borrower_domain(struct domain *d, paddr_t pbase, paddr_t psize, unsigned long *nr_borrowers) { - const struct membanks *reserved_mem = bootinfo_get_reserved_mem(); + const struct membanks *shmem = bootinfo_get_shmem(); unsigned int bank; /* Iterate reserved memory to find requested shm bank. */ - for ( bank = 0 ; bank < reserved_mem->nr_banks; bank++ ) + for ( bank = 0 ; bank < shmem->nr_banks; bank++ ) { - paddr_t bank_start = reserved_mem->bank[bank].start; - paddr_t bank_size = reserved_mem->bank[bank].size; + paddr_t bank_start = shmem->bank[bank].start; + paddr_t bank_size = shmem->bank[bank].size; if ( (pbase == bank_start) && (psize == bank_size) ) break; } - if ( bank == reserved_mem->nr_banks ) + if ( bank == shmem->nr_banks ) return -ENOENT; - *nr_borrowers = reserved_mem->bank[bank].nr_shm_borrowers; + *nr_borrowers = shmem->bank[bank].shmem_extra->nr_shm_borrowers; return 0; } @@ -158,16 +159,22 @@ static int __init assign_shared_memory(struct domain *d, return ret; } -static int __init append_shm_bank_to_domain(struct membanks *shm_mem, - paddr_t start, paddr_t size, - const char *shm_id) +static int __init +append_shm_bank_to_domain(struct shared_meminfo *kinfo_shm_mem, paddr_t start, + paddr_t size, const char *shm_id) { + struct membanks *shm_mem = &kinfo_shm_mem->common; + struct shmem_membank_extra *shm_mem_extra; + if ( shm_mem->nr_banks >= shm_mem->max_banks ) return -ENOMEM; + shm_mem_extra = &kinfo_shm_mem->extra[shm_mem->nr_banks]; + shm_mem->bank[shm_mem->nr_banks].start = start; shm_mem->bank[shm_mem->nr_banks].size = size; - safe_strcpy(shm_mem->bank[shm_mem->nr_banks].shm_id, shm_id); + safe_strcpy(shm_mem_extra->shm_id, shm_id); + shm_mem->bank[shm_mem->nr_banks].shmem_extra = shm_mem_extra; shm_mem->nr_banks++; return 0; @@ -270,7 +277,7 @@ int __init process_shm(struct domain *d, struct kernel_info *kinfo, * Record static shared memory region info for later setting * up shm-node in guest device tree. */ - ret = append_shm_bank_to_domain(&kinfo->shm_mem.common, gbase, psize, + ret = append_shm_bank_to_domain(&kinfo->shm_mem, gbase, psize, shm_id); if ( ret ) return ret; @@ -324,7 +331,8 @@ static int __init make_shm_memory_node(const struct domain *d, void *fdt, dt_dprintk("Shared memory bank %u: %#"PRIx64"->%#"PRIx64"\n", i, start, start + size); - res = fdt_property_string(fdt, "xen,id", mem->bank[i].shm_id); + res = fdt_property_string(fdt, "xen,id", + mem->bank[i].shmem_extra->shm_id); if ( res ) return res; @@ -352,7 +360,8 @@ int __init process_shm_node(const void *fdt, int node, uint32_t address_cells, const struct fdt_property *prop, *prop_id, *prop_role; const __be32 *cell; paddr_t paddr, gaddr, size, end; - struct membanks *mem = bootinfo_get_reserved_mem(); + struct membanks *mem = bootinfo_get_shmem(); + struct shmem_membank_extra *shmem_extra = bootinfo_get_shmem_extra(); unsigned int i; int len; bool owner = false; @@ -441,7 +450,8 @@ int __init process_shm_node(const void *fdt, int node, uint32_t address_cells, */ if ( paddr == mem->bank[i].start && size == mem->bank[i].size ) { - if ( strncmp(shm_id, mem->bank[i].shm_id, MAX_SHM_ID_LENGTH) == 0 ) + if ( strncmp(shm_id, shmem_extra[i].shm_id, + MAX_SHM_ID_LENGTH) == 0 ) break; else { @@ -450,7 +460,8 @@ int __init process_shm_node(const void *fdt, int node, uint32_t address_cells, return -EINVAL; } } - else if ( strncmp(shm_id, mem->bank[i].shm_id, MAX_SHM_ID_LENGTH) != 0 ) + else if ( strncmp(shm_id, shmem_extra[i].shm_id, + MAX_SHM_ID_LENGTH) != 0 ) continue; else { @@ -468,10 +479,10 @@ int __init process_shm_node(const void *fdt, int node, uint32_t address_cells, return -EINVAL; /* Static shared memory shall be reserved from any other use. */ - safe_strcpy(mem->bank[mem->nr_banks].shm_id, shm_id); + safe_strcpy(shmem_extra[mem->nr_banks].shm_id, shm_id); mem->bank[mem->nr_banks].start = paddr; mem->bank[mem->nr_banks].size = size; - mem->bank[mem->nr_banks].type = MEMBANK_STATIC_DOMAIN; + mem->bank[mem->nr_banks].shmem_extra = &shmem_extra[mem->nr_banks]; mem->nr_banks++; } else @@ -485,7 +496,7 @@ int __init process_shm_node(const void *fdt, int node, uint32_t address_cells, * to calculate the reference count. */ if ( !owner ) - mem->bank[i].nr_shm_borrowers++; + shmem_extra[i].nr_shm_borrowers++; return 0; } @@ -531,6 +542,28 @@ int __init make_resv_memory_node(const struct domain *d, return res; } +void __init early_print_info_shmem(void) +{ + const struct membanks *shmem = bootinfo_get_shmem(); + unsigned int bank; + + for ( bank = 0; bank < shmem->nr_banks; bank++ ) + { + printk(" SHMEM[%u]: %"PRIpaddr" - %"PRIpaddr"\n", bank, + shmem->bank[bank].start, + shmem->bank[bank].start + shmem->bank[bank].size - 1); + } +} + +void __init init_sharedmem_pages(void) +{ + const struct membanks *shmem = bootinfo_get_shmem(); + unsigned int bank; + + for ( bank = 0 ; bank < shmem->nr_banks; bank++ ) + init_staticmem_bank(&shmem->bank[bank]); +} + /* * Local variables: * mode: C -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Tue Mar 12 13:04:04 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 13:04:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691815.1078258 (Exim 4.92) (envelope-from ) id 1rk1nU-00063g-Vp; Tue, 12 Mar 2024 13:04:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691815.1078258; Tue, 12 Mar 2024 13:04:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk1nU-00063V-Sv; Tue, 12 Mar 2024 13:04:00 +0000 Received: by outflank-mailman (input) for mailman id 691815; Tue, 12 Mar 2024 13:03:59 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk1nT-0004WU-6j for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 13:03:59 +0000 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by se1-gles-flk1.inumbo.com (Halon) with ESMTP id fc860517-e070-11ee-a1ee-f123f15fe8a2; Tue, 12 Mar 2024 14:03:57 +0100 (CET) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4B2821570; Tue, 12 Mar 2024 06:04:34 -0700 (PDT) Received: from e125770.cambridge.arm.com (e125770.arm.com [10.1.199.43]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 06C973F762; Tue, 12 Mar 2024 06:03:55 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fc860517-e070-11ee-a1ee-f123f15fe8a2 From: Luca Fancellu To: xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH 06/11] xen/arm: Avoid code duplication in find_unallocated_memory Date: Tue, 12 Mar 2024 13:03:26 +0000 Message-Id: <20240312130331.78418-7-luca.fancellu@arm.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240312130331.78418-1-luca.fancellu@arm.com> References: <20240312130331.78418-1-luca.fancellu@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit The function find_unallocated_memory is using the same code to loop through 3 structure of the same type, in order to avoid code duplication, rework the code to have only one loop that goes through all the structures. Signed-off-by: Luca Fancellu --- xen/arch/arm/domain_build.c | 62 ++++++++++--------------------------- 1 file changed, 17 insertions(+), 45 deletions(-) diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c index b254f252e7cb..d0f2ac6060eb 100644 --- a/xen/arch/arm/domain_build.c +++ b/xen/arch/arm/domain_build.c @@ -869,12 +869,14 @@ static int __init add_ext_regions(unsigned long s_gfn, unsigned long e_gfn, static int __init find_unallocated_memory(const struct kernel_info *kinfo, struct membanks *ext_regions) { - const struct membanks *kinfo_mem = kernel_info_get_mem(kinfo); - const struct membanks *mem = bootinfo_get_mem(); - const struct membanks *reserved_mem = bootinfo_get_reserved_mem(); + const struct membanks *mem_banks[] = { + bootinfo_get_mem(), + kernel_info_get_mem(kinfo), + bootinfo_get_reserved_mem(), + }; struct rangeset *unalloc_mem; paddr_t start, end; - unsigned int i; + unsigned int i, j; int res; dt_dprintk("Find unallocated memory for extended regions\n"); @@ -883,50 +885,20 @@ static int __init find_unallocated_memory(const struct kernel_info *kinfo, if ( !unalloc_mem ) return -ENOMEM; - /* Start with all available RAM */ - for ( i = 0; i < mem->nr_banks; i++ ) - { - start = mem->bank[i].start; - end = mem->bank[i].start + mem->bank[i].size; - res = rangeset_add_range(unalloc_mem, PFN_DOWN(start), - PFN_DOWN(end - 1)); - if ( res ) - { - printk(XENLOG_ERR "Failed to add: %#"PRIpaddr"->%#"PRIpaddr"\n", - start, end); - goto out; - } - } - - /* Remove RAM assigned to Dom0 */ - for ( i = 0; i < kinfo_mem->nr_banks; i++ ) - { - start = kinfo_mem->bank[i].start; - end = kinfo_mem->bank[i].start + kinfo_mem->bank[i].size; - res = rangeset_remove_range(unalloc_mem, PFN_DOWN(start), - PFN_DOWN(end - 1)); - if ( res ) + for ( i = 0; i < ARRAY_SIZE(mem_banks); i++ ) + for ( j = 0; j < mem_banks[i]->nr_banks; j++ ) { - printk(XENLOG_ERR "Failed to remove: %#"PRIpaddr"->%#"PRIpaddr"\n", - start, end); - goto out; - } - } - - /* Remove reserved-memory regions */ - for ( i = 0; i < reserved_mem->nr_banks; i++ ) - { - start = reserved_mem->bank[i].start; - end = reserved_mem->bank[i].start + reserved_mem->bank[i].size; - res = rangeset_remove_range(unalloc_mem, PFN_DOWN(start), + start = mem_banks[i]->bank[j].start; + end = mem_banks[i]->bank[j].start + mem_banks[i]->bank[j].size; + res = rangeset_add_range(unalloc_mem, PFN_DOWN(start), PFN_DOWN(end - 1)); - if ( res ) - { - printk(XENLOG_ERR "Failed to remove: %#"PRIpaddr"->%#"PRIpaddr"\n", - start, end); - goto out; + if ( res ) + { + printk(XENLOG_ERR "Failed to add: %#"PRIpaddr"->%#"PRIpaddr"\n", + start, end); + goto out; + } } - } /* Remove grant table region */ if ( kinfo->gnttab_size ) -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Tue Mar 12 13:04:05 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 13:04:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691818.1078287 (Exim 4.92) (envelope-from ) id 1rk1nZ-0006ue-A5; Tue, 12 Mar 2024 13:04:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691818.1078287; Tue, 12 Mar 2024 13:04:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk1nZ-0006tl-4T; Tue, 12 Mar 2024 13:04:05 +0000 Received: by outflank-mailman (input) for mailman id 691818; Tue, 12 Mar 2024 13:04:03 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk1nX-0004WU-Dj for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 13:04:03 +0000 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by se1-gles-flk1.inumbo.com (Halon) with ESMTP id ff012a35-e070-11ee-a1ee-f123f15fe8a2; Tue, 12 Mar 2024 14:04:01 +0100 (CET) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 7428715A1; Tue, 12 Mar 2024 06:04:38 -0700 (PDT) Received: from e125770.cambridge.arm.com (e125770.arm.com [10.1.199.43]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E4B2E3F762; Tue, 12 Mar 2024 06:03:59 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ff012a35-e070-11ee-a1ee-f123f15fe8a2 From: Luca Fancellu To: xen-devel@lists.xenproject.org Cc: Penny Zheng , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Penny Zheng Subject: [PATCH 09/11] xen/arm: remove shm holes for extended regions Date: Tue, 12 Mar 2024 13:03:29 +0000 Message-Id: <20240312130331.78418-10-luca.fancellu@arm.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240312130331.78418-1-luca.fancellu@arm.com> References: <20240312130331.78418-1-luca.fancellu@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Penny Zheng Static shared memory acts as reserved memory in guest, so it shall be excluded from extended regions. Extended regions are taken care of under three different scenarios: normal DomU, direct-map domain with iommu on, and direct-map domain with iommu off. For normal DomU, we create a new function "remove_shm_holes_for_domU", to firstly transfer original outputs into the format of "struct rangeset", then use "remove_shm_from_rangeset" to remove static shm from them. For direct-map domain with iommu on, after we get guest shm info from "kinfo", we use "remove_shm_from_rangeset" to remove static shm. For direct-map domain with iommu off, as static shm has already been taken care of through reserved memory banks, we do nothing. Signed-off-by: Penny Zheng Signed-off-by: Luca Fancellu --- v1: - Rework of https://patchwork.kernel.org/project/xen-devel/patch/20231206090623.1932275-8-Penny.Zheng@arm.com/ --- xen/arch/arm/domain_build.c | 16 ++++- xen/arch/arm/include/asm/domain_build.h | 2 + xen/arch/arm/include/asm/static-shmem.h | 18 ++++++ xen/arch/arm/static-shmem.c | 86 +++++++++++++++++++++++++ 4 files changed, 119 insertions(+), 3 deletions(-) diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c index 9fad9e8b2c40..740c483ea2db 100644 --- a/xen/arch/arm/domain_build.c +++ b/xen/arch/arm/domain_build.c @@ -817,8 +817,8 @@ int __init make_memory_node(const struct domain *d, return res; } -static int __init add_ext_regions(unsigned long s_gfn, unsigned long e_gfn, - void *data) +int __init add_ext_regions(unsigned long s_gfn, unsigned long e_gfn, + void *data) { struct membanks *ext_regions = data; paddr_t start, size; @@ -969,6 +969,8 @@ static int __init handle_pci_range(const struct dt_device_node *dev, * - MMIO * - Host RAM * - PCI aperture + * - Static shared memory regions, which are described by special property + * "xen,domain-shared-memory-v1" */ static int __init find_memory_holes(const struct kernel_info *kinfo, struct membanks *ext_regions) @@ -985,6 +987,11 @@ static int __init find_memory_holes(const struct kernel_info *kinfo, if ( !mem_holes ) return -ENOMEM; + /* Remove static shared memory regions */ + res = remove_shm_from_rangeset(kinfo, mem_holes); + if ( res ) + goto out; + /* Start with maximum possible addressable physical memory range */ start = 0; end = (1ULL << p2m_ipa_bits) - 1; @@ -1089,7 +1096,10 @@ static int __init find_domU_holes(const struct kernel_info *kinfo, res = 0; } - return res; + if ( res ) + return res; + + return remove_shm_holes_for_domU(kinfo, ext_regions); } int __init make_hypervisor_node(struct domain *d, diff --git a/xen/arch/arm/include/asm/domain_build.h b/xen/arch/arm/include/asm/domain_build.h index a6f276cc4263..026d975da28e 100644 --- a/xen/arch/arm/include/asm/domain_build.h +++ b/xen/arch/arm/include/asm/domain_build.h @@ -51,6 +51,8 @@ static inline int prepare_acpi(struct domain *d, struct kernel_info *kinfo) int prepare_acpi(struct domain *d, struct kernel_info *kinfo); #endif +int add_ext_regions(unsigned long s_gfn, unsigned long e_gfn, void *data); + #endif /* diff --git a/xen/arch/arm/include/asm/static-shmem.h b/xen/arch/arm/include/asm/static-shmem.h index c6fac9906656..2f70aed53ac7 100644 --- a/xen/arch/arm/include/asm/static-shmem.h +++ b/xen/arch/arm/include/asm/static-shmem.h @@ -29,6 +29,12 @@ void early_print_info_shmem(void); void init_sharedmem_pages(void); +int remove_shm_from_rangeset(const struct kernel_info *kinfo, + struct rangeset *rangeset); + +int remove_shm_holes_for_domU(const struct kernel_info *kinfo, + struct membanks *ext_regions); + #else /* !CONFIG_STATIC_SHM */ static inline int make_resv_memory_node(const struct domain *d, @@ -61,6 +67,18 @@ static inline void early_print_info_shmem(void) {}; static inline void init_sharedmem_pages(void) {}; +static inline int remove_shm_from_rangeset(const struct kernel_info *kinfo, + struct rangeset *rangeset) +{ + return 0; +} + +static inline int remove_shm_holes_for_domU(const struct kernel_info *kinfo, + struct membanks *ext_regions) +{ + return 0; +} + #endif /* CONFIG_STATIC_SHM */ #endif /* __ASM_STATIC_SHMEM_H_ */ diff --git a/xen/arch/arm/static-shmem.c b/xen/arch/arm/static-shmem.c index 6143f52cb991..b3e2105dd3f2 100644 --- a/xen/arch/arm/static-shmem.c +++ b/xen/arch/arm/static-shmem.c @@ -1,6 +1,7 @@ /* SPDX-License-Identifier: GPL-2.0-only */ #include +#include #include #include @@ -564,6 +565,91 @@ void __init init_sharedmem_pages(void) init_staticmem_bank(&shmem->bank[bank]); } +int __init remove_shm_from_rangeset(const struct kernel_info *kinfo, + struct rangeset *rangeset) +{ + const struct membanks *shm_mem = &kinfo->shm_mem.common; + unsigned int i; + + /* Remove static shared memory regions */ + for ( i = 0; i < shm_mem->nr_banks; i++ ) + { + paddr_t start, end; + int res; + + start = shm_mem->bank[i].start; + end = shm_mem->bank[i].start + shm_mem->bank[i].size - 1; + res = rangeset_remove_range(rangeset, start, end); + if ( res ) + { + printk(XENLOG_ERR "Failed to remove: %#"PRIpaddr"->%#"PRIpaddr"\n", + start, end); + return -EINVAL; + } + } + + return 0; +} + +int __init remove_shm_holes_for_domU(const struct kernel_info *kinfo, + struct membanks *ext_regions) +{ + const struct membanks *shm_mem = &kinfo->shm_mem.common; + struct rangeset *guest_holes; + unsigned int i; + paddr_t start; + paddr_t end; + int res; + + /* No static shared memory region. */ + if ( shm_mem->nr_banks == 0 ) + return 0; + + dt_dprintk("Remove static shared memory holes for extended regions of DomU\n"); + + guest_holes = rangeset_new(NULL, NULL, 0); + if ( !guest_holes ) + return -ENOMEM; + + /* Copy extended regions sets into the rangeset */ + for ( i = 0; i < ext_regions->nr_banks; i++ ) + { + start = ext_regions->bank[i].start; + end = start + ext_regions->bank[i].size - 1; + + res = rangeset_add_range(guest_holes, start, end); + if ( res ) + { + printk(XENLOG_ERR "Failed to add: %#"PRIpaddr"->%#"PRIpaddr"\n", + start, end); + goto out; + } + } + + /* Remove static shared memory regions */ + res = remove_shm_from_rangeset(kinfo, guest_holes); + if ( res ) + goto out; + + i = ext_regions->nr_banks - 1; + start = ext_regions->bank[0].start; + end = ext_regions->bank[i].start + ext_regions->bank[i].size - 1; + + /* Reset original extended regions to hold new value */ + ext_regions->nr_banks = 0; + res = rangeset_report_ranges(guest_holes, start, end, add_ext_regions, + ext_regions); + if ( res ) + ext_regions->nr_banks = 0; + else if ( !ext_regions->nr_banks ) + res = -ENOENT; + + out: + rangeset_destroy(guest_holes); + + return res; +} + /* * Local variables: * mode: C -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Tue Mar 12 13:04:06 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 13:04:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691819.1078292 (Exim 4.92) (envelope-from ) id 1rk1nZ-0006zu-Qm; Tue, 12 Mar 2024 13:04:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691819.1078292; Tue, 12 Mar 2024 13:04:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk1nZ-0006yp-HB; Tue, 12 Mar 2024 13:04:05 +0000 Received: by outflank-mailman (input) for mailman id 691819; Tue, 12 Mar 2024 13:04:05 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk1nY-0004WU-VI for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 13:04:04 +0000 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by se1-gles-flk1.inumbo.com (Halon) with ESMTP id fff54792-e070-11ee-a1ee-f123f15fe8a2; Tue, 12 Mar 2024 14:04:03 +0100 (CET) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 095E41570; Tue, 12 Mar 2024 06:04:40 -0700 (PDT) Received: from e125770.cambridge.arm.com (e125770.arm.com [10.1.199.43]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 79BFF3F762; Tue, 12 Mar 2024 06:04:01 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fff54792-e070-11ee-a1ee-f123f15fe8a2 From: Luca Fancellu To: xen-devel@lists.xenproject.org Cc: Penny Zheng , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Penny Zheng Subject: [PATCH 10/11] xen/arm: fix duplicate /reserved-memory node in Dom0 Date: Tue, 12 Mar 2024 13:03:30 +0000 Message-Id: <20240312130331.78418-11-luca.fancellu@arm.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240312130331.78418-1-luca.fancellu@arm.com> References: <20240312130331.78418-1-luca.fancellu@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Penny Zheng In case there is a /reserved-memory node already present in the host dtb, current Xen codes would create yet another /reserved-memory node when the static shared memory feature is enabled and static shared memory region are present, this would result in an incorrect device tree generation and guest would not be able to detect the static shared memory region. Avoid this issue checking the presence of the /reserved-memory node and appending the nodes instead of generating a duplicate /reserved-memory. Signed-off-by: Penny Zheng Signed-off-by: Luca Fancellu --- v1: - Rework of https://patchwork.kernel.org/project/xen-devel/patch/20231206090623.1932275-11-Penny.Zheng@arm.com/ --- xen/arch/arm/domain_build.c | 23 ++++++++++++++++++++--- xen/arch/arm/include/asm/static-shmem.h | 11 +++++++++++ xen/arch/arm/static-shmem.c | 12 +++++++----- 3 files changed, 38 insertions(+), 8 deletions(-) diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c index 740c483ea2db..575e906d81a6 100644 --- a/xen/arch/arm/domain_build.c +++ b/xen/arch/arm/domain_build.c @@ -1620,6 +1620,7 @@ static int __init handle_node(struct domain *d, struct kernel_info *kinfo, DT_MATCH_PATH("/hypervisor"), { /* sentinel */ }, }; + static __initdata bool res_mem_node_found = false; struct dt_device_node *child; int res, i, nirq, irq_id; const char *name; @@ -1714,6 +1715,19 @@ static int __init handle_node(struct domain *d, struct kernel_info *kinfo, if ( res ) return res; + if ( dt_node_path_is_equal(node, "/reserved-memory") ) + { + res_mem_node_found = true; + /* + * Avoid duplicate /reserved-memory nodes in Device Tree, so list the + * static shared memory nodes there. + */ + res = make_shm_memory_node(d, kinfo, dt_n_addr_cells(node), + dt_n_size_cells(node)); + if ( res ) + return res; + } + for ( child = node->child; child != NULL; child = child->sibling ) { res = handle_node(d, kinfo, child, p2mt); @@ -1766,9 +1780,12 @@ static int __init handle_node(struct domain *d, struct kernel_info *kinfo, return res; } - res = make_resv_memory_node(d, kinfo, addrcells, sizecells); - if ( res ) - return res; + if ( !res_mem_node_found ) + { + res = make_resv_memory_node(d, kinfo, addrcells, sizecells); + if ( res ) + return res; + } } res = fdt_end_node(kinfo->fdt); diff --git a/xen/arch/arm/include/asm/static-shmem.h b/xen/arch/arm/include/asm/static-shmem.h index 2f70aed53ac7..d28b9540d49b 100644 --- a/xen/arch/arm/include/asm/static-shmem.h +++ b/xen/arch/arm/include/asm/static-shmem.h @@ -35,6 +35,10 @@ int remove_shm_from_rangeset(const struct kernel_info *kinfo, int remove_shm_holes_for_domU(const struct kernel_info *kinfo, struct membanks *ext_regions); +int make_shm_memory_node(const struct domain *d, + const struct kernel_info *kinfo, int addrcells, + int sizecells); + #else /* !CONFIG_STATIC_SHM */ static inline int make_resv_memory_node(const struct domain *d, @@ -79,6 +83,13 @@ static inline int remove_shm_holes_for_domU(const struct kernel_info *kinfo, return 0; } +static inline int make_shm_memory_node(const struct domain *d, + const struct kernel_info *kinfo, + int addrcells, int sizecells) +{ + return 0; +} + #endif /* CONFIG_STATIC_SHM */ #endif /* __ASM_STATIC_SHMEM_H_ */ diff --git a/xen/arch/arm/static-shmem.c b/xen/arch/arm/static-shmem.c index b3e2105dd3f2..67d5fa3b5d25 100644 --- a/xen/arch/arm/static-shmem.c +++ b/xen/arch/arm/static-shmem.c @@ -287,15 +287,17 @@ int __init process_shm(struct domain *d, struct kernel_info *kinfo, return 0; } -static int __init make_shm_memory_node(const struct domain *d, void *fdt, - int addrcells, int sizecells, - const struct membanks *mem) +int __init make_shm_memory_node(const struct domain *d, + const struct kernel_info *kinfo, int addrcells, + int sizecells) { + const struct membanks *mem = &kinfo->shm_mem.common; + void *fdt = kinfo->fdt; unsigned int i = 0; int res = 0; if ( mem->nr_banks == 0 ) - return -ENOENT; + return 0; /* * For each shared memory region, a range is exposed under @@ -534,7 +536,7 @@ int __init make_resv_memory_node(const struct domain *d, if ( res ) return res; - res = make_shm_memory_node(d, fdt, addrcells, sizecells, mem); + res = make_shm_memory_node(d, kinfo, addrcells, sizecells); if ( res ) return res; -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Tue Mar 12 13:04:08 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 13:04:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691820.1078308 (Exim 4.92) (envelope-from ) id 1rk1nc-0007az-2B; Tue, 12 Mar 2024 13:04:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691820.1078308; Tue, 12 Mar 2024 13:04:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk1nb-0007ad-T0; Tue, 12 Mar 2024 13:04:07 +0000 Received: by outflank-mailman (input) for mailman id 691820; Tue, 12 Mar 2024 13:04:06 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk1na-0004WU-6H for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 13:04:06 +0000 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by se1-gles-flk1.inumbo.com (Halon) with ESMTP id 00a9ea6d-e071-11ee-a1ee-f123f15fe8a2; Tue, 12 Mar 2024 14:04:04 +0100 (CET) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 5327215A1; Tue, 12 Mar 2024 06:04:41 -0700 (PDT) Received: from e125770.cambridge.arm.com (e125770.arm.com [10.1.199.43]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0EB153F762; Tue, 12 Mar 2024 06:04:02 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 00a9ea6d-e071-11ee-a1ee-f123f15fe8a2 From: Luca Fancellu To: xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH 11/11] xen/arm: List static shared memory regions as /memory nodes Date: Tue, 12 Mar 2024 13:03:31 +0000 Message-Id: <20240312130331.78418-12-luca.fancellu@arm.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240312130331.78418-1-luca.fancellu@arm.com> References: <20240312130331.78418-1-luca.fancellu@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Currently Xen is not exporting the static shared memory regions to the device tree as /memory node, this commit is fixing this issue. Signed-off-by: Luca Fancellu --- xen/arch/arm/dom0less-build.c | 5 +++ xen/arch/arm/domain_build.c | 7 +++- xen/arch/arm/include/asm/static-shmem.h | 5 ++- xen/arch/arm/static-shmem.c | 54 +++++++++++++++---------- 4 files changed, 47 insertions(+), 24 deletions(-) diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c index fe2a771d4984..0892020f21a0 100644 --- a/xen/arch/arm/dom0less-build.c +++ b/xen/arch/arm/dom0less-build.c @@ -647,6 +647,11 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo) if ( ret ) goto err; + /* List static shared memory regions as /memory@
nodes */ + ret = make_shm_memory_node(d, kinfo, addrcells, sizecells, false); + if ( ret ) + return ret; + ret = make_resv_memory_node(d, kinfo, addrcells, sizecells); if ( ret ) goto err; diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c index 575e906d81a6..bd7716cd5829 100644 --- a/xen/arch/arm/domain_build.c +++ b/xen/arch/arm/domain_build.c @@ -1723,7 +1723,7 @@ static int __init handle_node(struct domain *d, struct kernel_info *kinfo, * static shared memory nodes there. */ res = make_shm_memory_node(d, kinfo, dt_n_addr_cells(node), - dt_n_size_cells(node)); + dt_n_size_cells(node), true); if ( res ) return res; } @@ -1780,6 +1780,11 @@ static int __init handle_node(struct domain *d, struct kernel_info *kinfo, return res; } + /* List static shared memory regions as /memory@
nodes */ + res = make_shm_memory_node(d, kinfo, addrcells, sizecells, false); + if ( res ) + return res; + if ( !res_mem_node_found ) { res = make_resv_memory_node(d, kinfo, addrcells, sizecells); diff --git a/xen/arch/arm/include/asm/static-shmem.h b/xen/arch/arm/include/asm/static-shmem.h index d28b9540d49b..c118bbb1c43b 100644 --- a/xen/arch/arm/include/asm/static-shmem.h +++ b/xen/arch/arm/include/asm/static-shmem.h @@ -37,7 +37,7 @@ int remove_shm_holes_for_domU(const struct kernel_info *kinfo, int make_shm_memory_node(const struct domain *d, const struct kernel_info *kinfo, int addrcells, - int sizecells); + int sizecells, bool is_resv_mem_node); #else /* !CONFIG_STATIC_SHM */ @@ -85,7 +85,8 @@ static inline int remove_shm_holes_for_domU(const struct kernel_info *kinfo, static inline int make_shm_memory_node(const struct domain *d, const struct kernel_info *kinfo, - int addrcells, int sizecells) + int addrcells, int sizecells, + bool is_resv_mem_node) { return 0; } diff --git a/xen/arch/arm/static-shmem.c b/xen/arch/arm/static-shmem.c index 67d5fa3b5d25..cdaf4485c934 100644 --- a/xen/arch/arm/static-shmem.c +++ b/xen/arch/arm/static-shmem.c @@ -289,7 +289,7 @@ int __init process_shm(struct domain *d, struct kernel_info *kinfo, int __init make_shm_memory_node(const struct domain *d, const struct kernel_info *kinfo, int addrcells, - int sizecells) + int sizecells, bool is_resv_mem_node) { const struct membanks *mem = &kinfo->shm_mem.common; void *fdt = kinfo->fdt; @@ -300,11 +300,15 @@ int __init make_shm_memory_node(const struct domain *d, return 0; /* - * For each shared memory region, a range is exposed under - * the /reserved-memory node as a child node. Each range sub-node is - * named xen-shmem@
. + * When is_resv_mem_node is true, it means this function is called to + * create nodes under /reserved-memory, so for each shared memory region, a + * range is exposed under the /reserved-memory node as a child node. Each + * range sub-node is named xen-shmem@
. + * Otherwise the function is called under / and will create + * /memory@
nodes for each static shared memory region. */ - dt_dprintk("Create xen-shmem node\n"); + dt_dprintk("Create static shared memory %s nodes\n", + is_resv_mem_node ? "/reserved-memory/xen-shmem" : "/memory"); for ( ; i < mem->nr_banks; i++ ) { @@ -316,11 +320,16 @@ int __init make_shm_memory_node(const struct domain *d, __be32 *cells; unsigned int len = (addrcells + sizecells) * sizeof(__be32); - res = domain_fdt_begin_node(fdt, "xen-shmem", mem->bank[i].start); + res = domain_fdt_begin_node(fdt, + is_resv_mem_node ? "xen-shmem" : "memory", + mem->bank[i].start); if ( res ) return res; - res = fdt_property(fdt, "compatible", compat, sizeof(compat)); + if ( is_resv_mem_node ) + res = fdt_property(fdt, "compatible", compat, sizeof(compat)); + else + res = fdt_property_string(fdt, "device_type", "memory"); if ( res ) return res; @@ -334,20 +343,23 @@ int __init make_shm_memory_node(const struct domain *d, dt_dprintk("Shared memory bank %u: %#"PRIx64"->%#"PRIx64"\n", i, start, start + size); - res = fdt_property_string(fdt, "xen,id", - mem->bank[i].shmem_extra->shm_id); - if ( res ) - return res; + if ( is_resv_mem_node ) + { + res = fdt_property_string(fdt, "xen,id", + mem->bank[i].shmem_extra->shm_id); + if ( res ) + return res; - /* - * TODO: - * - xen,offset: (borrower VMs only) - * 64 bit integer offset within the owner virtual machine's shared - * memory region used for the mapping in the borrower VM - */ - res = fdt_property_u64(fdt, "xen,offset", 0); - if ( res ) - return res; + /* + * TODO: + * - xen,offset: (borrower VMs only) + * 64 bit integer offset within the owner virtual machine's shared + * memory region used for the mapping in the borrower VM + */ + res = fdt_property_u64(fdt, "xen,offset", 0); + if ( res ) + return res; + } res = fdt_end_node(fdt); if ( res ) @@ -536,7 +548,7 @@ int __init make_resv_memory_node(const struct domain *d, if ( res ) return res; - res = make_shm_memory_node(d, kinfo, addrcells, sizecells); + res = make_shm_memory_node(d, kinfo, addrcells, sizecells, true); if ( res ) return res; -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Tue Mar 12 13:09:33 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 13:09:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691846.1078318 (Exim 4.92) (envelope-from ) id 1rk1sm-0002mu-J7; Tue, 12 Mar 2024 13:09:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691846.1078318; Tue, 12 Mar 2024 13:09:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk1sm-0002mn-G9; Tue, 12 Mar 2024 13:09:28 +0000 Received: by outflank-mailman (input) for mailman id 691846; Tue, 12 Mar 2024 13:09:26 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk1sk-0002mh-Kg for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 13:09:26 +0000 Received: from wfout1-smtp.messagingengine.com (wfout1-smtp.messagingengine.com [64.147.123.144]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id bde097a7-e071-11ee-a1ee-f123f15fe8a2; Tue, 12 Mar 2024 14:09:23 +0100 (CET) Received: from compute7.internal (compute7.nyi.internal [10.202.2.48]) by mailfout.west.internal (Postfix) with ESMTP id 7B4221C000CE; Tue, 12 Mar 2024 09:09:19 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Tue, 12 Mar 2024 09:09:20 -0400 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 12 Mar 2024 09:09:17 -0400 (EDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: bde097a7-e071-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= invisiblethingslab.com; h=cc:cc:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1710248959; x=1710335359; bh=hOUvcrBST3DiEsqfYi4i5If3YrOMAB7V91NZAHLgPZ8=; b= B31FrC5HddRmeVwhElG4ZfE2vOA2fCi4IjeUxEiNXkfMqukb2JMorMB/h+WN+xaQ ClsuXnAeBH3OK4LyI1XfcBDo2l26bvOEEvug4uuC7vb9+23UE4EdQNQj+gBFU5aE gm+arBuSz3pKHjLwhveTTzz9KNPb11EX0NrK/GDTpXaBxDGVmiOoWdm633SQG+kP zrC8ZZT9WpC5yfCILPraYPBqwriD6PjTU9WarTuM3hxyuAOCmQbIVULk26WANDOt 9Cy5OX44cpvWSALx6QErmS7MN+K4Xks9JatGxlHqixnXKBI/okPu8Rca6z8yeVXT 4qXM3Rl4a1Mlfzmw+v48nQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1710248959; x=1710335359; bh=hOUvcrBST3DiEsqfYi4i5If3YrOM AB7V91NZAHLgPZ8=; b=ahGXG1a0OnD5HFcfkyHYuByhxGWKDkcqj7VnRPN3vi9O MCUuwGQSEHyvbgVK4ORx3Uxi20sXho3xBJSWkFxOvtOG8qG3UsTkSrH1ZlflCV5j Rc6DptZyXAB/hIwpdS1P0Es86kyXFVaFOfbpQMT80F5YNkyQ8wtcu2OV84YXyPtw HsT2JfonWGwfwhkaItXYKvxEYfC/phlOkry4sfdnXOXUFIfZmybbswcq0QRueS+N GwO2lZwAHNMPnapUiN+907fOx4lbcLZqF1E4zY62efg3Z3WbgyLOXtpjlRECPO8h ++/xb41Na9/Hl8mhcZLMJOF7uv477bNYS+BMPwcEBg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrjeefgdegkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvvefukfhfgggtuggjsehgtderredttdejnecuhfhrohhmpeforghrvghk ucforghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvh hishhisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpefgudel teefvefhfeehieetleeihfejhfeludevteetkeevtedtvdegueetfeejudenucevlhhush htvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhes ihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhm X-ME-Proxy: Feedback-ID: i1568416f:Fastmail Date: Tue, 12 Mar 2024 14:09:14 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Jan Beulich Cc: Roger Pau =?utf-8?B?TW9ubsOp?= , xen-devel@lists.xenproject.org, Andrew Cooper , Wei Liu , George Dunlap , Julien Grall , Stefano Stabellini Subject: Re: [PATCH] drivers/char: mark XHCI DMA buffers reserved in memory map Message-ID: References: <20240311203431.342530-1-marmarek@invisiblethingslab.com> <6a80ceb6-cc2a-4d8f-9a66-70063923b0ea@suse.com> <2a04315c-7bb8-4985-8aca-bece9d0d535e@suse.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="MB7jhg/fn8N9WInN" Content-Disposition: inline In-Reply-To: <2a04315c-7bb8-4985-8aca-bece9d0d535e@suse.com> --MB7jhg/fn8N9WInN Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Mar 2024 14:09:14 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Jan Beulich Cc: Roger Pau =?utf-8?B?TW9ubsOp?= , xen-devel@lists.xenproject.org, Andrew Cooper , Wei Liu , George Dunlap , Julien Grall , Stefano Stabellini Subject: Re: [PATCH] drivers/char: mark XHCI DMA buffers reserved in memory map On Tue, Mar 12, 2024 at 01:38:53PM +0100, Jan Beulich wrote: > On 12.03.2024 13:02, Marek Marczykowski-G=C3=B3recki wrote: > > On Tue, Mar 12, 2024 at 11:53:46AM +0100, Jan Beulich wrote: > >> On 12.03.2024 11:24, Roger Pau Monn=C3=A9 wrote: > >>>> --- a/xen/arch/x86/setup.c > >>>> +++ b/xen/arch/x86/setup.c > >>>> @@ -1806,6 +1806,9 @@ void asmlinkage __init noreturn __start_xen(un= signed long mbi_p) > >>>> mmio_ro_ranges =3D rangeset_new(NULL, "r/o mmio ranges", > >>>> RANGESETF_prettyprint_hex); > >>>> =20 > >>>> + /* Needs to happen after E820 processing but before IOMMU init = */ > >>>> + xhci_dbc_uart_reserve_ram(); > >>> > >>> Overall it might be better if some generic solution for all users of > >>> iommu_add_extra_reserved_device_memory() could be implemented, > >> > >> +1 > >=20 > > In that case, is the approach with > > iommu_get_extra_reserved_device_memory() okay (and a comment that it > > will have a side effect...) ? >=20 > Counter question: You not having gone that route despite our talking > about it on Matrix must have a reason. When seeing this approach I > concluded something got in the way. What's the deal? I added a note about that in the patch (below commit message): > As an alternative implementation I have considered changing > iommu_get_extra_reserved_device_memory() to modify memory map. But that > may hide (or cause) some other issues when this API will gain some more > users in the future. More specifically, if some future use would be on a non-RAM area, or already reserved area. But if we can ignore those cases for now, I'm fine with that approach. > >>> but I'm > >>> unsure whether the intention is for the interface to always be used > >>> against RAM. > >> > >> I think we can work from that assumption for now. > >=20 > > Ok, I'll add a comment about that. I guess, if needed in the future, > > iommu_add_extra_reserved_device_memory() can gain an extra parameter to > > distinguish RAM from non-RAM mappings. > >=20 > > BTW should e820_change_range_type() return 1 in case of mapping already > > having the right type? Otherwise, if one wants to use > > iommu_add_extra_reserved_device_memory() on already reserved memory, the > > e820_change_range_type() would fail. >=20 > You raised that question on Matrix yesterday, iirc, and I left it > unanswered there because it takes archeology to find the answer (or at > least get closer to one). And, please don't get me wrong, you could as > well do that yourself. (My vague recollection from having dealt with > similar code in Linux is that yes, in the example given the function > ought to indeed have failed back then. Depending on present uses etc > it may well be that we could reconsider, though.) I sure can do some archaeology there, I was just hoping any of you would know the answer already. --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab --MB7jhg/fn8N9WInN Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmXwU/sACgkQ24/THMrX 1ywYNgf+KpFDyE2eKOTdY91SPxAEi+YcDQvKZaX5b01EbbT9pBVgOOOrcxCmIb05 uLGFU7mYjvbOT4SV6KmX/qFkTP9PcuPe2l8531P3QQKV6te5eA6qCQ5B9rxooxiS 6Ma/LZhWv7Dws9BdoXH/6xpoDw74AWD6EnyPHrNgbaO1glnIXo7k20PKtc0RMGrL +TPiLyYOgRIQQhW0UyNQyEa8KE1rpigSkTomtMWtaoEEUFDOUnsy6KGDDE8MZNyW hjlvzO4GlLTHYB7rVvZwfp7GPLdYW2CzcU5/Df1DPBeT0F6Q0r+Py5kfJkQhICDs WRbKuDWwHnMLYmNApfaiMOS/4a37xA== =v4V7 -----END PGP SIGNATURE----- --MB7jhg/fn8N9WInN-- From xen-devel-bounces@lists.xenproject.org Tue Mar 12 13:10:07 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 13:10:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691851.1078328 (Exim 4.92) (envelope-from ) id 1rk1tO-0004Bi-Vc; Tue, 12 Mar 2024 13:10:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691851.1078328; Tue, 12 Mar 2024 13:10:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk1tO-0004BJ-SG; Tue, 12 Mar 2024 13:10:06 +0000 Received: by outflank-mailman (input) for mailman id 691851; Tue, 12 Mar 2024 13:10:05 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk1tN-0003A9-8Y for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 13:10:05 +0000 Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [2a00:1450:4864:20::130]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id d7631c8c-e071-11ee-afdd-a90da7624cb6; Tue, 12 Mar 2024 14:10:04 +0100 (CET) Received: by mail-lf1-x130.google.com with SMTP id 2adb3069b0e04-5135486cfccso5221192e87.0 for ; Tue, 12 Mar 2024 06:10:04 -0700 (PDT) Received: from ?IPV6:2003:e5:873a:400:704b:6dbb:e7c0:786e? (p200300e5873a0400704b6dbbe7c0786e.dip0.t-ipconnect.de. [2003:e5:873a:400:704b:6dbb:e7c0:786e]) by smtp.gmail.com with ESMTPSA id p8-20020a05600c1d8800b004122b7a680dsm12630740wms.21.2024.03.12.06.10.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 Mar 2024 06:10:03 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d7631c8c-e071-11ee-afdd-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1710249004; x=1710853804; darn=lists.xenproject.org; h=in-reply-to:from:cc:references:to:content-language:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=D5Jpe3Etc2AopDApY4Bu83ODPEnzKL7QHyJBGT/EWZY=; b=XV1WYGTZS4Ea07KCEBkeuTegfH6NysCFDcr5RBO27/Z/g853SI3oBd/DOBl2SMJSYd lUsHOdPEw58ogbPO4rXcy0CblFegDVL385Ilwx70YAfXLjQx7VlPsAC0gTPkKtwqyL0E NUIlPmCSM/+3WFQLQViaPaqPqtFq65StO7+/NzGla6VKS4i+7qjwojb4dPWgLry6LMx8 NeLss50QvETI0tsnjoR2cegalTDc1tAnNfhsjlf/QIdjBWcK1HBy/mnJSGUlI55Da34N 1fsjNmFyTt00kH/spY+67BWTWVK//3day6TsXp0yJ9IGRJDjlDy9Pc+9w9UI4kyggyI4 ljQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710249004; x=1710853804; h=in-reply-to:from:cc:references:to:content-language:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=D5Jpe3Etc2AopDApY4Bu83ODPEnzKL7QHyJBGT/EWZY=; b=SwTtZElw5kBvJ4NKNHsVDf10mrZ9c/xR7JXgGCH2jm2ClgkLrnAO8Ji9fCYGMPLyfy zI7uH5GiCMvmTvZgB0PcXMnZtuAQrVa0RzDPj/GRP7buPao/25CJj3jUXWH+jymRO/4+ 44AobRHJ3VfCJ+6p4cp5UTg8t5MZm82HMVKgRcciIsw0HjGCyXBhxsWjcTRmddMafKP9 4jVKarGLfKpSfNCoHsBxxf+pTBEHJcIC1Xs2Lbhnfa3qFD0LasV99awFQsultc6sKRPY bkqT2SR+3XQlbT3yidtXbfYDgo74z7/RKdEF3rnetVtNFrZHgL+vEcI5A6w9KQQK9d3Q U8iQ== X-Forwarded-Encrypted: i=1; AJvYcCVUk8A0Ikzz5aNJtuIq62zrMH5jxyC+SCIK67XKbH2EMz+mop4MY7JH//EBAal8KG5qDhF+WS7zKznNcjh83qUpunB2WuI9wfKyb1oIz0E= X-Gm-Message-State: AOJu0YyxHaUWh4eP36CK+Wx5Ki4B99LcAQRsVo+cthrbhzZMaOyNS6Vm tIGc3ojmuasBQEF8oMJG7TGDl7nsYcPazD3UU+RB4jqGTt4A8D7ZCuskmfzHEtLl4SG8qOTiHfl 2 X-Google-Smtp-Source: AGHT+IH0xvVOOIMPgUmcmGCACV/mWPshDZr/SUpR/Y0Dom0W14EqeIodHlqwpDHvMjtzLo4kAdyiCg== X-Received: by 2002:a19:f809:0:b0:512:a9b7:c637 with SMTP id a9-20020a19f809000000b00512a9b7c637mr6217839lff.29.1710249003828; Tue, 12 Mar 2024 06:10:03 -0700 (PDT) Content-Type: multipart/mixed; boundary="------------K9LlK4neQ0MF6IEXhimBH0bQ" Message-ID: <644eda4c-ca1b-4a1b-bd13-c847df2f4c8e@suse.com> Date: Tue, 12 Mar 2024 14:10:02 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Linux 6.7-rc1+: WARNING at drivers/xen/evtchn.c:167 evtchn_interrupt Content-Language: en-US To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , xen-devel References: Cc: Demi Marie Obenour From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= In-Reply-To: This is a multi-part message in MIME format. --------------K9LlK4neQ0MF6IEXhimBH0bQ Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 30.11.23 03:34, Marek Marczykowski-Górecki wrote: > Hi, > > While testing 6.7-rc3 on Qubes OS I found several warning like in the > subject in dom0 log. I see them when running 6.7-rc1 too. I'm not sure > what exactly triggers the issue, but my guess would be unbinding an > event channel from userspace (closing vchan connection). > > Specific message: > > [ 83.973377] ------------[ cut here ]------------ > [ 83.975523] Interrupt for port 77, but apparently not enabled; per-user 00000000a0e9f1d1 Finally I think I have a fix (thanks to Demi for finding the problematic patch through bisecting). Could you please try the attached patch? It is based on current upstream, but I think it should apply to 6.7 or stable 6.6, too. Juergen --------------K9LlK4neQ0MF6IEXhimBH0bQ Content-Type: text/x-patch; charset=UTF-8; name="0001-xen-evtchn-avoid-WARN-when-unbinding-an-event-channe.patch" Content-Disposition: attachment; filename*0="0001-xen-evtchn-avoid-WARN-when-unbinding-an-event-channe.pa"; filename*1="tch" Content-Transfer-Encoding: base64 RnJvbSA5ZDY3M2MzN2IyZDBjOWFhMjc0YzUzZjYxOWM0ZTllNDNhNDE5ZjQxIE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBKdWVyZ2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+ ClRvOiBsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnCkNjOiBKdWVyZ2VuIEdyb3NzIDxq Z3Jvc3NAc3VzZS5jb20+CkNjOiBTdGVmYW5vIFN0YWJlbGxpbmkgPHNzdGFiZWxsaW5pQGtl cm5lbC5vcmc+CkNjOiBPbGVrc2FuZHIgVHlzaGNoZW5rbyA8b2xla3NhbmRyX3R5c2hjaGVu a29AZXBhbS5jb20+CkNjOiB4ZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcKRGF0ZTog VHVlLCAxMiBNYXIgMjAyNCAxMzo1MjoyNCArMDEwMApTdWJqZWN0OiBbUEFUQ0hdIHhlbi9l dnRjaG46IGF2b2lkIFdBUk4oKSB3aGVuIHVuYmluZGluZyBhbiBldmVudCBjaGFubmVsCgpX aGVuIHVuYmluZGluZyBhIHVzZXIgZXZlbnQgY2hhbm5lbCwgdGhlIHJlbGF0ZWQgaGFuZGxl ciBtaWdodCBiZQpjYWxsZWQgYSBsYXN0IHRpbWUgaW4gY2FzZSB0aGUga2VybmVsIHdhcyBi dWlsdCB3aXRoCkNPTkZJR19ERUJVR19TSElSUS4gVGhpcyBtaWdodCBjYXVzZSBhIFdBUk4o KSBpbiB0aGUgaGFuZGxlci4KCkF2b2lkIHRoYXQgYnkgYWRkaW5nIGFuICJ1bmJpbmRpbmci IGZsYWcgdG8gc3RydWN0IHVzZXJfZXZlbnQgd2hpY2gKd2lsbCBzaG9ydCBjaXJjdWl0IHRo ZSBoYW5kbGVyLgoKRml4ZXM6IDllOTBlNThjMTFiNyAoInhlbjogZXZ0Y2huOiBBbGxvdyBz aGFyZWQgcmVnaXN0cmF0aW9uIG9mIElSUSBoYW5kZXJzIikKU2lnbmVkLW9mZi1ieTogSnVl cmdlbiBHcm9zcyA8amdyb3NzQHN1c2UuY29tPgotLS0KIGRyaXZlcnMveGVuL2V2dGNobi5j IHwgNiArKysrKysKIDEgZmlsZSBjaGFuZ2VkLCA2IGluc2VydGlvbnMoKykKCmRpZmYgLS1n aXQgYS9kcml2ZXJzL3hlbi9ldnRjaG4uYyBiL2RyaXZlcnMveGVuL2V2dGNobi5jCmluZGV4 IDU5NzE3NjI4Y2E0Mi4uZjZhMjIxNmMyYzg3IDEwMDY0NAotLS0gYS9kcml2ZXJzL3hlbi9l dnRjaG4uYworKysgYi9kcml2ZXJzL3hlbi9ldnRjaG4uYwpAQCAtODUsNiArODUsNyBAQCBz dHJ1Y3QgdXNlcl9ldnRjaG4gewogCXN0cnVjdCBwZXJfdXNlcl9kYXRhICp1c2VyOwogCWV2 dGNobl9wb3J0X3QgcG9ydDsKIAlib29sIGVuYWJsZWQ7CisJYm9vbCB1bmJpbmRpbmc7CiB9 OwogCiBzdGF0aWMgdm9pZCBldnRjaG5fZnJlZV9yaW5nKGV2dGNobl9wb3J0X3QgKnJpbmcp CkBAIC0xNjQsNiArMTY1LDEwIEBAIHN0YXRpYyBpcnFyZXR1cm5fdCBldnRjaG5faW50ZXJy dXB0KGludCBpcnEsIHZvaWQgKmRhdGEpCiAJc3RydWN0IHBlcl91c2VyX2RhdGEgKnUgPSBl dnRjaG4tPnVzZXI7CiAJdW5zaWduZWQgaW50IHByb2QsIGNvbnM7CiAKKwkvKiBIYW5kbGVy IG1pZ2h0IGJlIGNhbGxlZCB3aGVuIHRlYXJpbmcgZG93biB0aGUgSVJRLiAqLworCWlmIChl dnRjaG4tPnVuYmluZGluZykKKwkJcmV0dXJuIElSUV9IQU5ETEVEOworCiAJV0FSTighZXZ0 Y2huLT5lbmFibGVkLAogCSAgICAgIkludGVycnVwdCBmb3IgcG9ydCAldSwgYnV0IGFwcGFy ZW50bHkgbm90IGVuYWJsZWQ7IHBlci11c2VyICVwXG4iLAogCSAgICAgZXZ0Y2huLT5wb3J0 LCB1KTsKQEAgLTQyMSw2ICs0MjYsNyBAQCBzdGF0aWMgdm9pZCBldnRjaG5fdW5iaW5kX2Zy b21fdXNlcihzdHJ1Y3QgcGVyX3VzZXJfZGF0YSAqdSwKIAogCUJVR19PTihpcnEgPCAwKTsK IAorCWV2dGNobi0+dW5iaW5kaW5nID0gdHJ1ZTsKIAl1bmJpbmRfZnJvbV9pcnFoYW5kbGVy KGlycSwgZXZ0Y2huKTsKIAogCWRlbF9ldnRjaG4odSwgZXZ0Y2huKTsKLS0gCjIuMzUuMwoK --------------K9LlK4neQ0MF6IEXhimBH0bQ-- From xen-devel-bounces@lists.xenproject.org Tue Mar 12 13:17:13 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 13:17:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691856.1078337 (Exim 4.92) (envelope-from ) id 1rk20D-0004uD-Lq; Tue, 12 Mar 2024 13:17:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691856.1078337; Tue, 12 Mar 2024 13:17:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk20D-0004u6-Is; Tue, 12 Mar 2024 13:17:09 +0000 Received: by outflank-mailman (input) for mailman id 691856; Tue, 12 Mar 2024 13:17:09 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk20D-0004tO-53 for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 13:17:09 +0000 Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [2a00:1450:4864:20::634]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id d419dd4f-e072-11ee-afdd-a90da7624cb6; Tue, 12 Mar 2024 14:17:08 +0100 (CET) Received: by mail-ej1-x634.google.com with SMTP id a640c23a62f3a-a4644bde1d4so89911366b.3 for ; Tue, 12 Mar 2024 06:17:08 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id b23-20020a170906039700b00a463a265b3bsm988113eja.220.2024.03.12.06.17.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 Mar 2024 06:17:07 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d419dd4f-e072-11ee-afdd-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1710249428; x=1710854228; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=PfLh6d5uT4EjKMiqAgSJefYC6srarOg0RB32K2RRr0c=; b=F879kuc6AWi+q4xHvD5YMIew8Nxf5WJwcyIq22ppV+3GZMB22xKdwVkd/NfFVGVM0d /juKS/JS6Wo1m+rcHW/ZHjNvZZY8Y051gYYTAEOqjcpU7A48c9W5pE0XYytCfJh134UX zgDR+iQgaQi+oSon7acu0cB9Bi/aorP5RUqcofWt7+2FkYJLtK/fUarBeV01qmRY1wnz rvws8V0KtR6IlaTfrSKY3FodWgZormMQ3/iw+1R+q3TkgOlLKqAxkPLge325KVDOh7Ch yY8Fa2HG/wpoYmj/7mcIXm/CSF/kPR4WiO9yPTTr4KU0oK+E1OF6RR366nO+/7mVGkb0 GEjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710249428; x=1710854228; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=PfLh6d5uT4EjKMiqAgSJefYC6srarOg0RB32K2RRr0c=; b=qmQqz6Y99iArmLQYK+h6cYT9TIUdMjUPZCn823qNq4/4GQEzzWJK8e0RzJZf8KcUXR FrkQQCJvhx2K34aLc5wSzubI+jtABNEg3/8HQji4h5EeG6i6T5SfUJSH27Z/o+HMdLbo awKVUHzF5ProHZOJpnwhPnuBqRfFe0wlAI+8BOgzibH0KTu6jBQVMYNg1eQ928ET1Rw5 2cHk6NLc5L+ePr2QELy8MNOD/g4LYfEPu9PY0uP/HaA3YPcvmt5XyVXbGJlOOhFl1aLC kd1sZX3ZE6QDNy3ha2Klgk7TQIeW7JAPCwEmA8Ke5TotQGvZmYsXmsUu9cSdK9HIbdUb SViw== X-Gm-Message-State: AOJu0YxyWaaK+EpY4xSp5PD2bTuJigcL6P86RfX7MxhcLYn5T1vP/131 +uRc5NQ4vmqoMHhu2I3FNW36BB5aXnTP0wbg/TWheCB6xvNjMoHbWc+mlY7qbQ== X-Google-Smtp-Source: AGHT+IE/d/lFiYcPWZxButJgHCiNQkXVQ0FNdbu4Zc7LdlIySBF2RXietz56/fkO/j3AlT3M6EXYnA== X-Received: by 2002:a17:906:c50:b0:a45:4ba5:2917 with SMTP id t16-20020a1709060c5000b00a454ba52917mr5619020ejf.75.1710249428034; Tue, 12 Mar 2024 06:17:08 -0700 (PDT) Message-ID: <6da353df-0954-4ca5-b8b1-2e7b5f98c901@suse.com> Date: Tue, 12 Mar 2024 14:17:06 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] x86/PoD: move increment of entry count Content-Language: en-US To: George Dunlap Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , George Dunlap References: <5b3f46f3-3c9f-57fb-00a5-94128f41e34a@suse.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 11.03.2024 17:04, George Dunlap wrote: > On Tue, Jan 4, 2022 at 10:58 AM Jan Beulich wrote: > >> When not holding the PoD lock across the entire region covering P2M >> update and stats update, the entry count should indicate too large a >> value in preference to a too small one, to avoid functions bailing early >> when they find the count is zero. Hence increments should happen ahead >> of P2M updates, while decrements should happen only after. Deal with the >> one place where this hasn't been the case yet. >> >> Signed-off-by: Jan Beulich >> --- >> v2: Add comments. >> --- >> While it might be possible to hold the PoD lock over the entire >> operation, I didn't want to chance introducing a lock order violation on >> a perhaps rarely taken code path. >> > > [No idea how I missed this 2 years ago, sorry for the delay] > > Actually I think just holding the lock is probably the right thing to do. > We already grab gfn_lock() over the entire operation, and p2m_set_entry() > ASSERTs gfn_locked_by_me(); and all we have to do to trigger the check is > boot any guest in PoD mode at all; surely we have osstest tests for that? The gfn (aka p2m) lock isn't of interest here. It's the locks whose lock level is between p2m and pod which are. Then again there are obviously other calls to p2m_set_entry() with the PoD lock held. So if there was a problem (e.g. with ept_set_entry() calling p2m_altp2m_propagate_change()), I wouldn't make things meaningfully worse by holding the PoD lock for longer here. So yes, let me switch to that and then hope ... Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 12 13:22:29 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 13:22:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691858.1078348 (Exim 4.92) (envelope-from ) id 1rk25H-0006qD-8b; Tue, 12 Mar 2024 13:22:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691858.1078348; Tue, 12 Mar 2024 13:22:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk25H-0006q6-4d; Tue, 12 Mar 2024 13:22:23 +0000 Received: by outflank-mailman (input) for mailman id 691858; Tue, 12 Mar 2024 13:22:22 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk25G-0006q0-4S for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 13:22:22 +0000 Received: from wfhigh2-smtp.messagingengine.com (wfhigh2-smtp.messagingengine.com [64.147.123.153]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 8d3281a9-e073-11ee-afdd-a90da7624cb6; Tue, 12 Mar 2024 14:22:20 +0100 (CET) Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailfhigh.west.internal (Postfix) with ESMTP id 3A1F518000AF; Tue, 12 Mar 2024 09:22:17 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Tue, 12 Mar 2024 09:22:17 -0400 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 12 Mar 2024 09:22:15 -0400 (EDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8d3281a9-e073-11ee-afdd-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= invisiblethingslab.com; h=cc:cc:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1710249736; x=1710336136; bh=gEUpmZ8QXwRRKcRI8dbsxxkQVkIJCAmX7zwzG25H+Bo=; b= K1Z94WzYyWUwoW+OdDNpCm6YiXLuWaoz0ZSPgCpX0jU/mo0yGu59j2wWbiWvBYMe oe1UB3y2DIKdUP5j3Yee8GXErNaJno2iPrpM/AD8ijmSko3bnbYrHxX3DfsRddgA jvbGFF5aJAdAsKnGcxjF1FU87/6Ojksx+3OwcJmo8U/ZZtLiCzdRIkG/8oAmuGPL QRNfLBzsde6YOHX+EESEmNOe1Abo3sBKldNnZQwQafAbASqF/IerkuToOoL7x26I 4sxs3iLgpgvZy5WP6Jw8GISgkth3ZrHWrsEcJ8R+bSIkXtK507blWBYMWoXeaFC1 W0bfcBOkRK879fQJasuS0g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1710249736; x=1710336136; bh=gEUpmZ8QXwRRKcRI8dbsxxkQVkIJ CAmX7zwzG25H+Bo=; b=ir2BkRUfSuXdDI4Etw217FqijVla88BN81si8CJTPHk2 vO1DHSQ1OFKXVVDTOCqTZVNQzJjCbgkrmBg/6WqYSFTKibh1Etct5vc1PsQe1Mcb UcJSgr3YLGb8s0BeqWdpKefO412foi+qsdlnJyx33wt0lZjp1GQKFkqtz0JdYHNg U6wrOCPVH85Dsfv52xIP24pm46ZCAGBgQ+nZhvRyG2HP8tiJGo+tCAd+GNxcaO7R KY29O9NWUdeHYwgAfa2Q8R7+2LzGD9gNzzKErEnPNTBIuk2cw1maq5a4ecYMIgap N8uvgCFkXKm1U9DqdokxNtb8wHwOXKBkUrknYa6LSw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrjeefgdehudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvvefukfhfgggtuggjsehgtderredttdejnecuhfhrohhmpeforghrvghk ucforghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvh hishhisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpefgudel teefvefhfeehieetleeihfejhfeludevteetkeevtedtvdegueetfeejudenucevlhhush htvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhes ihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhm X-ME-Proxy: Feedback-ID: i1568416f:Fastmail Date: Tue, 12 Mar 2024 14:22:12 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Jan Beulich Cc: Roger Pau =?utf-8?B?TW9ubsOp?= , xen-devel@lists.xenproject.org, Andrew Cooper , Wei Liu , George Dunlap , Julien Grall , Stefano Stabellini Subject: Re: [PATCH] drivers/char: mark XHCI DMA buffers reserved in memory map Message-ID: References: <20240311203431.342530-1-marmarek@invisiblethingslab.com> <6a80ceb6-cc2a-4d8f-9a66-70063923b0ea@suse.com> <2a04315c-7bb8-4985-8aca-bece9d0d535e@suse.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cyjgwSoPVYxGjkDn" Content-Disposition: inline In-Reply-To: --cyjgwSoPVYxGjkDn Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Mar 2024 14:22:12 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Jan Beulich Cc: Roger Pau =?utf-8?B?TW9ubsOp?= , xen-devel@lists.xenproject.org, Andrew Cooper , Wei Liu , George Dunlap , Julien Grall , Stefano Stabellini Subject: Re: [PATCH] drivers/char: mark XHCI DMA buffers reserved in memory map On Tue, Mar 12, 2024 at 02:09:14PM +0100, Marek Marczykowski-G=C3=B3recki w= rote: > On Tue, Mar 12, 2024 at 01:38:53PM +0100, Jan Beulich wrote: > > On 12.03.2024 13:02, Marek Marczykowski-G=C3=B3recki wrote: > > > BTW should e820_change_range_type() return 1 in case of mapping alrea= dy > > > having the right type? Otherwise, if one wants to use > > > iommu_add_extra_reserved_device_memory() on already reserved memory, = the > > > e820_change_range_type() would fail. > >=20 > > You raised that question on Matrix yesterday, iirc, and I left it > > unanswered there because it takes archeology to find the answer (or at > > least get closer to one). And, please don't get me wrong, you could as > > well do that yourself. (My vague recollection from having dealt with > > similar code in Linux is that yes, in the example given the function > > ought to indeed have failed back then. Depending on present uses etc > > it may well be that we could reconsider, though.) >=20 > I sure can do some archaeology there, I was just hoping any of you would > know the answer already. None of the commit messages touching that code give the answer. But looking around, most callers of reserve_e820_ram() ignore its return value. One exception is reserving memory for kexec. I guess in that case it may be intentional to fail if the area is reserved already, as it may indicate it cannot be used for kexec. Is that correct? There are also a couple of calls to e820_change_range_type() in tboot code where it changes E820_RESERVED to E820_UNUSABLE. There, I guess changing e820_change_range_type() behavior would be okay. Anyway, since we agree to focus on RAM in this API for now, it shouldn't matter anymore. --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab --cyjgwSoPVYxGjkDn Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmXwVwUACgkQ24/THMrX 1yym6wf9HeI3PgTlfO16rW2M3ziJEqtQ0DF2VMiXAy7/mFZrRwDYNWPPwUcyI6qZ eE8otU54p8BzUCqcqSe1XtpvAksmz6kN3WATgDd+aFhNmDuHmAmv6gPZs5STN3Pt fGjvpcgeeXRFab/nQMJxE5VtSmGRj+twEJO+VXyBa7orVZ46UXc6MSiZt4OCDSOW SxAMBL9yStQ3EajgG+Slkpt9ssGNgu/3dreODGumNHWbZLE0+EXfzM8HvSK9ghm9 mCUZbRA4fgg+8sLOXVUzcBJkqTZ5Wx0BE28EurDbCd6Y7awosAke1E5sGvlheRbS /vPRcvAAG25FxyAXTk10YkYB1Vmx9g== =VMdq -----END PGP SIGNATURE----- --cyjgwSoPVYxGjkDn-- From xen-devel-bounces@lists.xenproject.org Tue Mar 12 13:26:34 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 13:26:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691862.1078358 (Exim 4.92) (envelope-from ) id 1rk29J-0007QW-OQ; Tue, 12 Mar 2024 13:26:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691862.1078358; Tue, 12 Mar 2024 13:26:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk29J-0007QP-L1; Tue, 12 Mar 2024 13:26:33 +0000 Received: by outflank-mailman (input) for mailman id 691862; Tue, 12 Mar 2024 13:26:32 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk29I-0007QE-69; Tue, 12 Mar 2024 13:26:32 +0000 Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk29I-00027T-1E; Tue, 12 Mar 2024 13:26:32 +0000 Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk29H-0007AG-J6; Tue, 12 Mar 2024 13:26:31 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rk29H-0001qJ-Go; Tue, 12 Mar 2024 13:26:31 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To; bh=AORqiuEm7kxRPwwqqkJYS/XBXi+uVTGHWanjFwCi93A=; b=LvoP9sEPEP9y5mM8yaSsIkckeS a2jxF8mKf8V63ZegEGbEh2Yq3eOGr24PC3gQ/q5Uc09G7vKs12wolYZoMs9fE7Kxk5lg8JBwrBPHS Fo/6rEjNqiDw8fn9PqsvjwW1+JCx/zGt/3Se1UgOnS8V9OO/9bPCZxNdRXHNE923T+xw=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-linus test] 185000: regressions - FAIL X-Osstest-Failures: linux-linus:build-arm64-pvops:kernel-build:fail:regression linux-linus:test-arm64-arm64-examine:build-check(1):blocked:nonblocking linux-linus:test-arm64-arm64-libvirt-raw:build-check(1):blocked:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking linux-linus:test-arm64-arm64-xl:build-check(1):blocked:nonblocking linux-linus:test-arm64-arm64-xl-credit1:build-check(1):blocked:nonblocking linux-linus:test-arm64-arm64-xl-credit2:build-check(1):blocked:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:build-check(1):blocked:nonblocking linux-linus:test-arm64-arm64-xl-vhd:build-check(1):blocked:nonblocking linux-linus:test-arm64-arm64-xl-xsm:build-check(1):blocked:nonblocking linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: linux=855684c7d938c2442f07eabc154e7532b4c1fbf9 X-Osstest-Versions-That: linux=0f1a876682f0979d6a1e5f86861dd562d1758936 From: osstest service owner Date: Tue, 12 Mar 2024 13:26:31 +0000 flight 185000 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/185000/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-pvops 6 kernel-build fail REGR. vs. 184997 Tests which did not succeed, but are not blocking: test-arm64-arm64-examine 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-raw 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit1 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-thunderx 1 build-check(1) blocked n/a test-arm64-arm64-xl-vhd 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 16 saverestore-support-check fail like 184997 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop fail like 184997 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop fail like 184997 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop fail like 184997 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 184997 test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail like 184997 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop fail like 184997 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184997 test-amd64-amd64-libvirt-xsm 15 migrate-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 15 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-check fail never pass test-armhf-armhf-libvirt 15 migrate-support-check fail never pass test-amd64-amd64-libvirt-qcow2 14 migrate-support-check fail never pass test-amd64-amd64-libvirt-raw 14 migrate-support-check fail never pass test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-check fail never pass version targeted for testing: linux 855684c7d938c2442f07eabc154e7532b4c1fbf9 baseline version: linux 0f1a876682f0979d6a1e5f86861dd562d1758936 Last test of basis 184997 2024-03-11 18:40:47 Z 0 days Testing same since 185000 2024-03-12 06:31:53 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Alex Shi Alexander Mikhalitsyn Alexey Dobriyan Alexey Kardashevskiy Alice Ryhl Allen Pais Allen Pais Anders Roxell Andrea Righi Andy Shevchenko Anna-Maria Behnsen Anup Patel Ard Biesheuvel Arnd Bergmann Ashish Kalra Audra Mitchell Babu Moger Bartosz Golaszewski Bibo Mao Biju Das Björn Töpel Boqun Feng Borislav Petkov (AMD) Brendan Jackman Breno Leitao Brijesh Singh Carl Worth # arm64 Changbin Du Changhuang Liang Charalampos Mitrodimas Chen Zhongjin Chengming Zhou Chinmay Gameti Christoph Böhmwalder Christoph Hellwig Christophe JAILLET Chun-Yi Lee Colin Ian King Conor Dooley Costa Shulyupin Crystal Wood Damien Le Moal Dan Carpenter Daniel Micay Dave Hansen Dave Hansen David Gow David Vernet Dawei Li Dionna Glaze Dirk Behme Dmitry Baryshkov Erick Archer Feng Tang Frederic Weisbecker Gabriel Krisman Bertazi Geert Uytterhoeven Greg Edwards Greg Kroah-Hartman Gregory CLEMENT Gui-Dong Han <2045gemini@gmail.com> Guilherme Amadio Guixin Liu Guo Ren H. Peter Anvin (Intel) Hannes Reinecke Heiko Carstens Heming Zhao Huacai Chen Huqiang Qin Ingo Molnar Jack Wang Jakub Kicinski James Morse Jan Höppner Jarkko Sakkinen Jens Axboe Jin Wang Jiri Kosina Joel Fernandes (Google) Joerg Roedel Johannes Thumshirn John Garry John Stultz Josh Poimboeuf Juergen Gross Julia Lawall Juri Lelli K Prateek Nayak Kai Huang Kanchan Joshi Kees Cook Keisuke Nishimura Keith Busch Kevin Loughlin Kim Phillips Kirill A. Shutemov Kuniyuki Iwashima Kunwu Chan Lai Jiangshan Leonardo Bras Li kunyu Li Lingfeng Li Nan Li zeming Li Zhijian Lili Li Linus Torvalds Luc Van Oostenryck Maninder Singh Marc Orr Marc Zyngier Marcelo Tosatti Marek Szyprowski Mark Rutland Masahiro Yamada Masami Hiramatsu (Google) Matt Gilbride Max Gurtovoy Max Kellermann Michael Kelley Michael Roth Miguel Ojeda Mika Westerberg Mike Snitzer Ming Lei Miroslav Franc Muhammad Usama Anjum Muralidhara M K Nadav Amit Namhyung Kim Nathan Chancellor Navid Emamdoost Nikolay Borisov Nilay Shroff Obei Sideg Oleg Nesterov Onkarnath Paolo Bonzini Paul E. McKenney Paul Luse Pavel Begunkov Pawan Gupta Peng Liu Peter Hilber Peter Newman Peter Zijlstra (Intel) Peter Zijlstra (Intel) Qais Yousef (Google) Qais Yousef Qiuxu Zhuo Rafael J. Wysocki Randy Dunlap Ravi Bangoria Reinette Chatre Reinette Chatre # for resctrl dependency Ricardo B. Marliere Ricardo Neri Richard Cochran (linutronix GmbH) Rick Edgecombe Roger Pau Monné Roman Smirnov Sergey Senozhatsky Shan Kang Shaopeng Tan Shin'ichiro Kawasaki Shrikanth Hegde Shrikanth Hegde Shubhrajyoti Datta Sohil Mehta Song Liu Stefan Haberland Stefan Roesch Steven Rostedt (Google) Tang Yizhou Tejun Heo Thomas Bertschinger Thomas Gleixner Thomas Weißschuh Thomas Zimmermann Tom Lendacky Tony Battersby Tony Luck Tony Solomonik Ulf Hansson Uros Bizjak Uwe Kleine-König Valentin Obst Virgile Andreani Vlastimil Babka Waiman Long Wang Jinchao Wang Wendy Wedson Almeida Filho Xiao Ni Xiaobing Li Xiaochen Shen Xin Li (Intel) Xin Li Xinyu Li Xiongwei Song Xuewen Yan Yang Jihong Yangtao Li Yazen Ghannam Yu Chien Peter Lin Yu Kuai Yury Norov Yutaro Ohno Zhang Rui Zqiang jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops fail build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl blocked test-armhf-armhf-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm blocked test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm blocked test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-amd64-dom0pvh-xl-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-freebsd11-amd64 pass test-amd64-amd64-freebsd12-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-examine-bios pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 blocked test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 blocked test-armhf-armhf-xl-credit2 pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine blocked test-armhf-armhf-examine pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-amd64-dom0pvh-xl-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-amd64-xl-pvshim pass test-amd64-amd64-pygrub pass test-amd64-amd64-libvirt-qcow2 pass test-armhf-armhf-libvirt-qcow2 pass test-amd64-amd64-libvirt-raw pass test-arm64-arm64-libvirt-raw blocked test-armhf-armhf-libvirt-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-arm64-arm64-xl-thunderx blocked test-amd64-amd64-examine-uefi pass test-amd64-amd64-xl-vhd pass test-arm64-arm64-xl-vhd blocked test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these 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 20166 lines long.) From xen-devel-bounces@lists.xenproject.org Tue Mar 12 13:40:35 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 13:40:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691868.1078367 (Exim 4.92) (envelope-from ) id 1rk2Mn-0002Sf-1r; Tue, 12 Mar 2024 13:40:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691868.1078367; Tue, 12 Mar 2024 13:40:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk2Mm-0002SY-VZ; Tue, 12 Mar 2024 13:40:28 +0000 Received: by outflank-mailman (input) for mailman id 691868; Tue, 12 Mar 2024 13:40:28 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk2Ml-0002SS-Vj for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 13:40:27 +0000 Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [2a00:1450:4864:20::52e]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 14bb13c5-e076-11ee-a1ee-f123f15fe8a2; Tue, 12 Mar 2024 14:40:25 +0100 (CET) Received: by mail-ed1-x52e.google.com with SMTP id 4fb4d7f45d1cf-563bb51c36eso6230898a12.2 for ; Tue, 12 Mar 2024 06:40:25 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id v8-20020a1709067d8800b00a45aeaf9969sm3861203ejo.5.2024.03.12.06.40.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 Mar 2024 06:40:24 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 14bb13c5-e076-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1710250825; x=1710855625; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=3toOv0f7V7jxo5xnPAfLR8vQRIBGwow3QbvN91f8I3M=; b=YzwnBhAKFDo6QH++JIdO7Qy3p+r+spkRdkEmnsMT6fCvsB28bMDrJQBSAAqH68d2qZ jGExYUHBNz5S4VBOUrmLrW9B2vNJUzc1vjHXKg1S69mAwk/a/VE7LacCqfOw9vPOjAP3 XMo8Mo4T6FMWqqLy84Bgszr9nCAipM7HLZ9u73oQ8PDYE/xWkQxtiJy78IYXK4dKj3O+ Y3OYzWYC0w9e8mWxg3N9XOSWcukqA5W7/lkZIf7A+oXfY35YFrjUqg3ZVRYZ5ztKpKTf GKtpXcn0Z4YdDiMPLLKb5zLMFRMluKB5vFLTE+K0ibD9BEHVN/eNXiQvMbMb4tqV/iTi zy2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710250825; x=1710855625; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=3toOv0f7V7jxo5xnPAfLR8vQRIBGwow3QbvN91f8I3M=; b=v91A1JfUpHeAWeXxVZPxhhYhiD3q2UZr9hfqkx+tIwkIwUaoaQJDsmVHmYMNB2DSoI +Su3FhA79NpktbGd8lTAvMTF3jxmRGmJMcpuj7baUj+DK7P5ATwS+PfuGA4A+nIyFp4O VRIqvis6b0q4cCozyzxdzaYmdWVmcU5cq+V7yaze8IOxrreAOpmlQaOpnrcsjJa1Ucia Q0Ia13dlO0cmjT0ekldYJfWPl7RU/IERBqcg+3W/8WbpwJaNF0uqpRG7iONg7qUwqFTZ s5eKS1Oy32zMgGtRV0AeMmHzQlWNsFP76AgnDFfBCS30rBUOWQorUArJeGCudMmIcZe1 aesA== X-Forwarded-Encrypted: i=1; AJvYcCUBxtkj939Lc1lBLLJz5mkY7qiAEkYow2Xi6+od4wsvg0hPxXPR0CcAg3RjS9OFCafIpTlJ637LpeuJBMIVAugKDE2lHDGMcvQmUjaSai8= X-Gm-Message-State: AOJu0YySlbAqEYd0gS2pQ03hp0VkdLc/T6aif5ZfLV78yPwO689k7B25 uf1XK+NYOksSQlLQPKiAPiHYpCXdcryS008qPCS4B0QNobYUB7s+FN0ssH6AXkvvzkZE+NT4caQ = X-Google-Smtp-Source: AGHT+IF3zmQFlGhpVJZ3iUn8a4FGnT2CVp/HhAHnQ/aK6Y0sSSqdISk2K6HpAIQ/UdFA8jzEqqB9nw== X-Received: by 2002:a17:906:6815:b0:a45:98f3:997e with SMTP id k21-20020a170906681500b00a4598f3997emr5715553ejr.7.1710250825021; Tue, 12 Mar 2024 06:40:25 -0700 (PDT) Message-ID: <2f41ad83-6911-4838-905b-dfe44ccaf8cf@suse.com> Date: Tue, 12 Mar 2024 14:40:23 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] drivers/char: mark XHCI DMA buffers reserved in memory map Content-Language: en-US To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org, Andrew Cooper , Wei Liu , George Dunlap , Julien Grall , Stefano Stabellini References: <20240311203431.342530-1-marmarek@invisiblethingslab.com> <6a80ceb6-cc2a-4d8f-9a66-70063923b0ea@suse.com> <2a04315c-7bb8-4985-8aca-bece9d0d535e@suse.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 12.03.2024 14:22, Marek Marczykowski-Górecki wrote: > On Tue, Mar 12, 2024 at 02:09:14PM +0100, Marek Marczykowski-Górecki wrote: >> On Tue, Mar 12, 2024 at 01:38:53PM +0100, Jan Beulich wrote: >>> On 12.03.2024 13:02, Marek Marczykowski-Górecki wrote: >>>> BTW should e820_change_range_type() return 1 in case of mapping already >>>> having the right type? Otherwise, if one wants to use >>>> iommu_add_extra_reserved_device_memory() on already reserved memory, the >>>> e820_change_range_type() would fail. >>> >>> You raised that question on Matrix yesterday, iirc, and I left it >>> unanswered there because it takes archeology to find the answer (or at >>> least get closer to one). And, please don't get me wrong, you could as >>> well do that yourself. (My vague recollection from having dealt with >>> similar code in Linux is that yes, in the example given the function >>> ought to indeed have failed back then. Depending on present uses etc >>> it may well be that we could reconsider, though.) >> >> I sure can do some archaeology there, I was just hoping any of you would >> know the answer already. > > None of the commit messages touching that code give the answer. But > looking around, most callers of reserve_e820_ram() ignore its return > value. One exception is reserving memory for kexec. I guess in that case > it may be intentional to fail if the area is reserved already, as it may > indicate it cannot be used for kexec. Is that correct? I suppose so, yes. > There are also a couple of calls to e820_change_range_type() in tboot > code where it changes E820_RESERVED to E820_UNUSABLE. There, I guess > changing e820_change_range_type() behavior would be okay. Possibly, but please don't put much trust in the tboot code we have. Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 12 14:14:43 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 14:14:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691877.1078381 (Exim 4.92) (envelope-from ) id 1rk2th-0007AV-LZ; Tue, 12 Mar 2024 14:14:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691877.1078381; Tue, 12 Mar 2024 14:14:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk2th-0007AO-Ir; Tue, 12 Mar 2024 14:14:29 +0000 Received: by outflank-mailman (input) for mailman id 691877; Tue, 12 Mar 2024 14:14:28 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk2tg-0007AI-4N for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 14:14:28 +0000 Received: from 3.mo584.mail-out.ovh.net (3.mo584.mail-out.ovh.net [46.105.57.129]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id d554492f-e07a-11ee-afdd-a90da7624cb6; Tue, 12 Mar 2024 15:14:26 +0100 (CET) Received: from director1.ghost.mail-out.ovh.net (unknown [10.109.140.55]) by mo584.mail-out.ovh.net (Postfix) with ESMTP id 4TvFyB1b28z19YL for ; Tue, 12 Mar 2024 14:14:26 +0000 (UTC) Received: from ghost-submission-6684bf9d7b-zcqb6 (unknown [10.110.96.141]) by director1.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 670921FE8D; Tue, 12 Mar 2024 14:14:25 +0000 (UTC) Received: from 3mdeb.com ([37.59.142.107]) by ghost-submission-6684bf9d7b-zcqb6 with ESMTPSA id iGI1EEFj8GUrzwAABa7qdA (envelope-from ); Tue, 12 Mar 2024 14:14:25 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d554492f-e07a-11ee-afdd-a90da7624cb6 Authentication-Results:garm.ovh; auth=pass (GARM-107S001d43bc115-4bd6-465f-8f6d-b9d6973bfb82, 0B6B113C544506A41C6EB031E0F94F2E66B6AEBC) smtp.auth=krystian.hebel@3mdeb.com X-OVh-ClientIp:217.171.61.25 Message-ID: <387275c4-6a56-4400-97c6-a8cc1409547d@3mdeb.com> Date: Tue, 12 Mar 2024 15:14:24 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH 1/9] x86/boot: choose AP stack based on APIC ID To: Julien Grall , xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu References: <0e7dd957b6f26fa7b752bdce1ef6ebe97c825903.1699982111.git.krystian.hebel@3mdeb.com> <07660850-5b7a-4811-997e-8237e575f429@xen.org> Content-Language: en-US From: Krystian Hebel In-Reply-To: <07660850-5b7a-4811-997e-8237e575f429@xen.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Ovh-Tracer-Id: 7151997687513327984 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedvledrjeefgdeivdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefkffggfgfuvfevfhfhjggtgfesthekredttddvjeenucfhrhhomhepmfhrhihsthhirghnucfjvggsvghluceokhhrhihsthhirghnrdhhvggsvghlseefmhguvggsrdgtohhmqeenucggtffrrghtthgvrhhnpeeigeeifeeffeefhffffeehuedvheethfeuvdetffdtheefffeigfelleeuhfduvdenucffohhmrghinhepthhrrghmphholhhinhgvrdhssgdpgiekiegpieegrdhssgdpfehmuggvsgdrtghomhenucfkphepuddvjedrtddrtddruddpvddujedrudejuddriedurddvhedpfeejrdehledrudegvddruddtjeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeduvdejrddtrddtrddupdhmrghilhhfrhhomhepkhhrhihsthhirghnrdhhvggsvghlseefmhguvggsrdgtohhmpdhnsggprhgtphhtthhopedupdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhgpdfovfetjfhoshhtpehmohehkeegpdhmohguvgepshhmthhpohhuth Hi, On 26.01.2024 19:30, Julien Grall wrote: > Hi, > > I am not too familiary with the x86 boot code. But I will give a try > to review :). > > On 14/11/2023 17:49, Krystian Hebel wrote: >> This is made as first step of making parallel AP bring-up possible. It >> should be enough for pre-C code. >> >> Signed-off-by: Krystian Hebel >> --- >>   xen/arch/x86/boot/trampoline.S | 20 ++++++++++++++++++++ >>   xen/arch/x86/boot/x86_64.S     | 28 +++++++++++++++++++++++++++- >>   xen/arch/x86/setup.c           |  7 +++++++ >>   3 files changed, 54 insertions(+), 1 deletion(-) >> >> diff --git a/xen/arch/x86/boot/trampoline.S >> b/xen/arch/x86/boot/trampoline.S >> index b8ab0ffdcbb0..ec254125016d 100644 >> --- a/xen/arch/x86/boot/trampoline.S >> +++ b/xen/arch/x86/boot/trampoline.S >> @@ -72,6 +72,26 @@ trampoline_protmode_entry: >>           mov     $X86_CR4_PAE,%ecx >>           mov     %ecx,%cr4 >>   +        /* >> +         * Get APIC ID while we're in non-paged mode. Start by >> checking if >> +         * x2APIC is enabled. >> +         */ >> +        mov     $MSR_APIC_BASE, %ecx >> +        rdmsr >> +        and     $APIC_BASE_EXTD, %eax >> +        jnz     .Lx2apic >> + >> +        /* Not x2APIC, read from MMIO */ >> +        mov     0xfee00020, %esp >> +        shr     $24, %esp >> +        jmp     1f >> + >> +.Lx2apic: >> +        mov     $(MSR_X2APIC_FIRST + (0x20 >> 4)), %ecx >> +        rdmsr >> +        mov     %eax, %esp >> +1: >> + >>           /* Load pagetable base register. */ >>           mov     $sym_offs(idle_pg_table),%eax >>           add     bootsym_rel(trampoline_xen_phys_start,4,%eax) >> diff --git a/xen/arch/x86/boot/x86_64.S b/xen/arch/x86/boot/x86_64.S >> index 04bb62ae8680..b85b47b5c1a0 100644 >> --- a/xen/arch/x86/boot/x86_64.S >> +++ b/xen/arch/x86/boot/x86_64.S >> @@ -15,7 +15,33 @@ ENTRY(__high_start) >>           mov     $XEN_MINIMAL_CR4,%rcx >>           mov     %rcx,%cr4 >>   -        mov     stack_start(%rip),%rsp >> +        test    %ebx,%ebx >> +        cmovz   stack_start(%rip), %rsp >> +        jz      .L_stack_set >> + >> +        /* APs only: get stack base from APIC ID saved in %esp. */ >> +        mov     $-1, %rax >> +        lea     x86_cpu_to_apicid(%rip), %rcx > I would consider to move this patch after #2 and #3, so the logic is > not modified again. This would help the review. I agree, maybe even after #4 after that patch is modified according to other comments. > >> +1: >> +        add     $1, %rax >> +        cmp     $NR_CPUS, %eax >> +        jb      2f > I think we can get rid of this jump by reworking the loop so %eax is > tested as the end of the loop. But this is boot code, so it is > possibly not worth it. I will leave the x86 maintainers commenting. Not sure if I understood "end of the loop" correctly, but if I did, it would result in out-of-bounds read. Anyway, this is changed by further patches which I still have to reorder, I'll check if final form can be improved. > >> +        hlt >> +2: >> +        cmp     %esp, (%rcx, %rax, 4) >> +        jne     1b >> + >> +        /* %eax is now Xen CPU index. */ >> +        lea     stack_base(%rip), %rcx >> +        mov     (%rcx, %rax, 8), %rsp >> + >> +        test    %rsp,%rsp >> +        jnz     1f >> +        hlt >> +1: > NIT: Can you use 3? This makes the code easier to read and less prone > to error (you have two very close 1). Ack > >> +        add     $(STACK_SIZE - CPUINFO_sizeof), %rsp >> + >> +.L_stack_set: >>             /* Reset EFLAGS (subsumes CLI and CLD). */ >>           pushq   $0 >> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c >> index a3d3f797bb1e..1285969901e0 100644 >> --- a/xen/arch/x86/setup.c >> +++ b/xen/arch/x86/setup.c >> @@ -1951,6 +1951,7 @@ void __init noreturn __start_xen(unsigned long >> mbi_p) >>        */ >>       if ( !pv_shim ) >>       { >> +        /* Separate loop to make parallel AP bringup possible. */ > > The loop split seems to be unrelated to this patch. Actually, I was > expecting that only the assembly code would be modified. Fair point, I originally left it here so the code can be bisected if needed, but code changed significantly since then. In current form it should be safe to do this in the last commit. > >>           for_each_present_cpu ( i ) >>           { >>               /* Set up cpu_to_node[]. */ >> @@ -1958,6 +1959,12 @@ void __init noreturn __start_xen(unsigned long >> mbi_p) >>               /* Set up node_to_cpumask based on cpu_to_node[]. */ >>               numa_add_cpu(i); >>   +            if ( stack_base[i] == NULL ) >> +                stack_base[i] = cpu_alloc_stack(i); > > I don't quite understand this change at least in the context of this > patch. AFAICT the stack will be currently allocated in > cpu_smpboot_callback() which is called while the CPU is prepared. So > you should not need this allocation right now. > > Looking at the rest of the series, it seems you allocate the stack > earlier so you start the CPU bring-up earlier. But they will still be > held in assembly code until cpu_up() is called. > > So effectively, part of the C part of the CPUs bring-up is still > serialized. Did I understand the logic correctly? > > If so, I would suggest to clarify it in the series because this wasn't > obvious to me (I was expecting start_secondary() would also run in > parallell). start_secondary() is started in parallel, CPUs are not held in assembly. Calling C (almost) always requires stack, and most of this series comes to making stack available for all APs at once, just so APs can loop early in start_secondary(). You are correct, most of C part is serialized. I tried to make it parallel as well but quickly gave up. Some of the notifiers callbacks are resistant against any attempts at parallelization, and this set of patches already gave satisfactory improvements in boot time (and was enough to go through peculiar SMP bring-up used by Intel TXT dynamic launch, which is the reason why I had to do it in the first place). > > Regarding the change in setup.c, I think it would make more sense in > patch #9. > > Cheers, > Best regards, -- Krystian Hebel Firmware Engineer https://3mdeb.com | @3mdeb_com From xen-devel-bounces@lists.xenproject.org Tue Mar 12 14:24:39 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 14:24:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691880.1078391 (Exim 4.92) (envelope-from ) id 1rk33S-0000XY-I5; Tue, 12 Mar 2024 14:24:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691880.1078391; Tue, 12 Mar 2024 14:24:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk33S-0000XR-FE; Tue, 12 Mar 2024 14:24:34 +0000 Received: by outflank-mailman (input) for mailman id 691880; Tue, 12 Mar 2024 14:24:33 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk33R-0000XL-0J for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 14:24:33 +0000 Received: from wfout2-smtp.messagingengine.com (wfout2-smtp.messagingengine.com [64.147.123.145]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 3afb0523-e07c-11ee-a1ee-f123f15fe8a2; Tue, 12 Mar 2024 15:24:29 +0100 (CET) Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailfout.west.internal (Postfix) with ESMTP id 9F6971C000CE; Tue, 12 Mar 2024 10:24:24 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Tue, 12 Mar 2024 10:24:25 -0400 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 12 Mar 2024 10:24:22 -0400 (EDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3afb0523-e07c-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= invisiblethingslab.com; h=cc:cc:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1710253464; x=1710339864; bh=f+1Sd5rakQHLQAUUL89pur99xCcTCbbEFtOqLetdaHk=; b= ZGVNKXAXL2bYSKtNR7XyI2B7GI6jV5nt2RnS7DMHsHayPi4UtT+NKFo58z30G8sV Md8jQ9Ampc3ohZYemchLh+F7U8jt14xcYPc8sM+UwkrKghVcOkqYL++u8puJTshe I/Z2MZv5t+3fhDajPRvTT2r/wZjQIsMn07clsAZzNufCGrgbIaN5/+GO3z7NiQjG ITSrgszHAmt07L7El9wjUHB7ZYlZnqQHZeZnKOyK5d1kBgT5FneIVIx5WpNghTMk /0dqSCFRV1HEOYISTKxTCF8Vd3BsP3RS8VSp+i5vOOVu5r7U+cTIPwewj1mMM3YW f8jaczxH/ijSE5b2K4dlTQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1710253464; x=1710339864; bh=f+1Sd5rakQHLQAUUL89pur99xCcT CbbEFtOqLetdaHk=; b=VLWjdt2DntIhQqC7Oaotuwqv73G5Tpr9gagF2CWCEr7y tSZFl/41mAQ4AM5yUT5uKyt33ppyoZk1Y0RPE6DLVHqn23/mGuWZTHKE8eay8QPl ghtdPudcZTlwyl9noPmbdRwrrhgWg8Wz93H6yhR7rXoKK3vaYo5MCelOD3yYa5Vg aNsEfmqW8FlSQOp2dvtSHaQ8CcEhExCQdNRR2sc7JU0bLyyKvUqv0sAKZ5IpDbFn pANW20zfkeZlsEqc00mdpBng0daQfh1nQPkQ00NsUiO0dGLkxc2ptR7AgEjPKWg1 t+BjaO9QfRzd0gbb+HzaDD/qq71BgeCJW623yuBDTQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrjeefgdeifecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvvefukfhfgggtuggjsehgtderredttdejnecuhfhrohhmpeforghrvghk ucforghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvh hishhisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpefgudel teefvefhfeehieetleeihfejhfeludevteetkeevtedtvdegueetfeejudenucevlhhush htvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhes ihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhm X-ME-Proxy: Feedback-ID: i1568416f:Fastmail Date: Tue, 12 Mar 2024 15:24:18 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Jan Beulich Cc: Roger Pau =?utf-8?B?TW9ubsOp?= , xen-devel@lists.xenproject.org, Andrew Cooper , Wei Liu , George Dunlap , Julien Grall , Stefano Stabellini Subject: Re: [PATCH] drivers/char: mark XHCI DMA buffers reserved in memory map Message-ID: References: <20240311203431.342530-1-marmarek@invisiblethingslab.com> <6a80ceb6-cc2a-4d8f-9a66-70063923b0ea@suse.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="pf2dGQsCVO7SeNX+" Content-Disposition: inline In-Reply-To: <6a80ceb6-cc2a-4d8f-9a66-70063923b0ea@suse.com> --pf2dGQsCVO7SeNX+ Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Mar 2024 15:24:18 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Jan Beulich Cc: Roger Pau =?utf-8?B?TW9ubsOp?= , xen-devel@lists.xenproject.org, Andrew Cooper , Wei Liu , George Dunlap , Julien Grall , Stefano Stabellini Subject: Re: [PATCH] drivers/char: mark XHCI DMA buffers reserved in memory map On Tue, Mar 12, 2024 at 11:53:46AM +0100, Jan Beulich wrote: > On 12.03.2024 11:24, Roger Pau Monn=C3=A9 wrote: > >> --- a/xen/arch/x86/setup.c > >> +++ b/xen/arch/x86/setup.c > >> @@ -1806,6 +1806,9 @@ void asmlinkage __init noreturn __start_xen(unsi= gned long mbi_p) > >> mmio_ro_ranges =3D rangeset_new(NULL, "r/o mmio ranges", > >> RANGESETF_prettyprint_hex); > >> =20 > >> + /* Needs to happen after E820 processing but before IOMMU init */ > >> + xhci_dbc_uart_reserve_ram(); > >=20 > > Overall it might be better if some generic solution for all users of > > iommu_add_extra_reserved_device_memory() could be implemented, >=20 > +1 >=20 > > but I'm > > unsure whether the intention is for the interface to always be used > > against RAM. >=20 > I think we can work from that assumption for now. One more question - what should be the error handling in this case? At this stage, if reserving fails, I can still skip giving this range to the IOMMU driver, which (most likely) will result in IOMMU faults and in-operational device (xhci console). Since I don't know (theoretically) what driver requested the range, the error message can only contain an address and device, so will be a bit less actionable for the user (although it should be quite easy to notice the BDF being the XHCI one). Panic surely is safer option, but less user friendly, especially since (due to the above) I cannot give explicit hint to disable XHCI console. And kinda independently - I'm tempted to add another field to `struct extra_reserved_range` (and an argument to `iommu_add_extra_reserved_device_memory()`) - textual description, for the error reporting purpose. --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab --pf2dGQsCVO7SeNX+ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmXwZZIACgkQ24/THMrX 1yxamggAlTw0NYhy7YOtjj8akdBrQceWAEa45T4OD+izM7TGkqGDHSMEqzEpD1MM zatvrosBJJMPrCKarUohhNwQI70FNVxeyy3Mc5Fmhd8ytXIOVgWOKCZRTIwUWuHx SXua+1FVHru/1yIWZrIA3OBBIr+Mvxo3DWxYsPh3bZzeby037vy2jUsDW9pzQnZY OLzexEEuE8OjMM1GvuJyre6YHrrRSTMkKGROwOMaXvhzGEHkSvSMc8mn2LuXmUUs fuQ6u3eugMxTAqCP6KsUHVLYdwtDI9s3j20jaIj/JtS905w4Za+HbB7HdUD/2YTD H9vPWNCqLBPt9SG3yTG/LyWENl/n4Q== =jAwE -----END PGP SIGNATURE----- --pf2dGQsCVO7SeNX+-- From xen-devel-bounces@lists.xenproject.org Tue Mar 12 14:30:39 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 14:30:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691883.1078400 (Exim 4.92) (envelope-from ) id 1rk39E-0002KD-4e; Tue, 12 Mar 2024 14:30:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691883.1078400; Tue, 12 Mar 2024 14:30:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk39E-0002K6-29; Tue, 12 Mar 2024 14:30:32 +0000 Received: by outflank-mailman (input) for mailman id 691883; Tue, 12 Mar 2024 14:30:31 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk39D-0002K0-1u for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 14:30:31 +0000 Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [2a00:1450:4864:20::529]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 12f8d8f8-e07d-11ee-a1ee-f123f15fe8a2; Tue, 12 Mar 2024 15:30:29 +0100 (CET) Received: by mail-ed1-x529.google.com with SMTP id 4fb4d7f45d1cf-55a5e7fa471so5214490a12.1 for ; Tue, 12 Mar 2024 07:30:29 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id f13-20020a056402194d00b005687aae14c5sm370423edz.30.2024.03.12.07.30.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 Mar 2024 07:30:28 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 12f8d8f8-e07d-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1710253828; x=1710858628; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=hvvi9JZq3xKp7qaCKyEAWmIewp8HiF5rca+d2RmpviY=; b=CGX4fwIReAR6c3mQ+8EhH8PBwtLtYbnhFka2UD+JKAbVuN/4512AtfTWImzjAFLFes n4Nt1ZR1f8Nze7wWGTU0vtFfiYDCq2vSC1AJBcv1HOV4x0f0x7aV2mN7Uba7dYN4VFCM hPvvQ7NHSCTqkI/Kz7eTkJGMWLarV8+OqICPkjn0JPV5xffbzPaC+lg88nolLi+7edIR 684AQL8QKhH3VlNvsDB/+v7mgh17oiT4T/4+tPJgJF1O4nL/5igAy7d1jO/2ImAR1rOD lnA0AHxFJD15UV6DoVuGFb/I4dSrDymPS8AScPXJim/IMYOhvI669W+FrdQD682S3epe ZbbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710253828; x=1710858628; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=hvvi9JZq3xKp7qaCKyEAWmIewp8HiF5rca+d2RmpviY=; b=T9h5Krn39TEX8ZL6KDfOoa0+NwBnTZfTqHf4G4sB+N3waQ4Ur4ALHR91YG3GEMIt7Z 8JXb1nXe6w8VZYaR6WELqnqu5EQohL87hJRuoBDgVvHXLXK2mBGOOG8Ib4627jI9QiSM kAdpx7kAqAYK/WBw4H/TnfYR/0Lh4ZsNZllVRmpL282Om9IN41IOQd2csK2UU/HbYt22 jpdsge+coS9Be8K85Mq/R008ZyxSAgz+FWwNnp2TvFnz2LElh91m0U6rMoay7K6D5pWv LDanSSXx6nVpvf/Xoi+0TPyXKQ+uu5LBJmdDTfxC6P4kuFM/iMgfomKCdrrcobJtFv31 cHNQ== X-Forwarded-Encrypted: i=1; AJvYcCXHXFg3akbbNya1/B1dA731SPPCOMmdBCappjWQsyOgCtgWJvbwSZ+m1KsTmnHK2V4cylnJ4P7ODJcANGF9ifnPkG07IHWVXeuizWGCHlw= X-Gm-Message-State: AOJu0YzD5FPUbAbDzKU5HfaeEx34mO+chcS6q9AfNkY7Dv6rdjrCBgjK etkT2rLtaGYbM2RAoHIA5sw2Uk+DHqtBG8Rlf0m16vJb7Vq1UHbdUjVNU+R3UQ== X-Google-Smtp-Source: AGHT+IEd1hSPEgZbTGqBrJdd0N3Lk672BdlpNFwF/XhsCd8qcgqbUBFQ6v24H8a6p4HlQBny8LS4uw== X-Received: by 2002:a50:a694:0:b0:566:4d9:c3cd with SMTP id e20-20020a50a694000000b0056604d9c3cdmr6324353edc.41.1710253828535; Tue, 12 Mar 2024 07:30:28 -0700 (PDT) Message-ID: <338db1b9-54f1-4687-ba9a-2eec282db1d5@suse.com> Date: Tue, 12 Mar 2024 15:30:27 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN RFC] xen: avoid grep fodder define and undef Content-Language: en-US To: Federico Serafini Cc: consulting@bugseng.com, Paul Durrant , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu , xen-devel@lists.xenproject.org References: <0002f3df03aac283fa3dc7365e9040ab7ffaee2e.1710242950.git.federico.serafini@bugseng.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <0002f3df03aac283fa3dc7365e9040ab7ffaee2e.1710242950.git.federico.serafini@bugseng.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 12.03.2024 12:48, Federico Serafini wrote: > Place an "#if 0" before grep fodder definitions and remove the > "#undef". > > This addresses several violations of MISRA C:2012 Rule 5.5 > ("Identifiers shall be distinct from macro names"). > > No functional change. > > Signed-off-by: Federico Serafini > --- > Hello, I would like to know what you think about this change. > If you want to keep grep fodders as they are, an alternative could be to > deviate violations of Rule 5.5 involving the TYPE_SAFE macro. I think the original intention was to allow for some (arch?) override. But we have lived without for long enough that I think we could do as you suggest. One question though: Wasn't there also a rule against the use of #undef, violations of which would then be eliminate here as well? If so, I think that would want mentioning in the description. If not, I'd like to give it a couple of days before ack-ing, just in case other opinions would be voiced. > --- a/xen/include/xen/iommu.h > +++ b/xen/include/xen/iommu.h > @@ -33,13 +33,10 @@ TYPE_SAFE(uint64_t, dfn); > #define PRI_dfn PRIx64 > #define INVALID_DFN _dfn(~0ULL) > > -#ifndef dfn_t > +#if 0 > #define dfn_t /* Grep fodder: dfn_t, _dfn() and dfn_x() are defined above */ > #define _dfn > #define dfn_x > -#undef dfn_t > -#undef _dfn > -#undef dfn_x > #endif I have to admit that I'm a little surprised that Misra (Eclair) is happy with this: The #define-s are all still there, after all. Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 12 14:37:25 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 14:37:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691886.1078411 (Exim 4.92) (envelope-from ) id 1rk3Fn-0002zD-Uk; Tue, 12 Mar 2024 14:37:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691886.1078411; Tue, 12 Mar 2024 14:37:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk3Fn-0002z6-Rj; Tue, 12 Mar 2024 14:37:19 +0000 Received: by outflank-mailman (input) for mailman id 691886; Tue, 12 Mar 2024 14:37:19 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk3Fm-0002yy-Ve for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 14:37:18 +0000 Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [2a00:1450:4864:20::636]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 062a580f-e07e-11ee-a1ee-f123f15fe8a2; Tue, 12 Mar 2024 15:37:17 +0100 (CET) Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-a4645485da6so101287366b.1 for ; Tue, 12 Mar 2024 07:37:17 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id kk28-20020a170907767c00b00a4547925e3asm3986100ejc.141.2024.03.12.07.37.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 Mar 2024 07:37:16 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 062a580f-e07e-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1710254236; x=1710859036; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=KWaDcU0FZBzF9S4NRN/c7rzjyNYyjHXBflnxtbvx+Ac=; b=GXLBoLl8mkAqwA9NfAadGizFBMKE+On4hL/qU+UEUcqL5B4IygK2fLHJRSVecsxtbl NHo2uLULoYsV4pi3LXcXDDxamd8DtjpCgVmR1B1UXhcEvUJLpPthnAAPC+028InaMrot 5yqOFB1UvR+12sxD1vEjWeR3IdYfLPfJQIUvjOjeFXrNzLOJFq2JinT0QkLXrZ4arWme ErFzyLGMfrFVcQxWk1qVKLnJxn1fVRjhLp/wofhMSERvlz3hiuHTGySZBvTVWmx02CGE ZWH5TFOsfuTaz4LJfefAL5Seexf+jRMKxt0t1sN8pCZZSRuehbDvJ+sgcEMWyD9MTAIR uPtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710254236; x=1710859036; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=KWaDcU0FZBzF9S4NRN/c7rzjyNYyjHXBflnxtbvx+Ac=; b=ExKnnWCyjX0WI7JbALMhJ/PRH/hTuXJn24wX3AknCELzWFRnCdK3RDSvmUDOnX+3eU zlIcDgtG3ba6NlrV+3hXZxUVCd3igK8A3N6+MZDNkBDtm+T7IEC1JzCA/c8Sk3OR1bzc 2ULzE+k4iRktxNU5M3WEPwNU+5o0M29zWcuXwr/YJuxRCmF+4u2Hsjjymc/5SBHd6InA 7B2oHVlaH1wJfNT2kt1J+G/ESV1+Xw1MGirUo6Ah9dEU6A3vlnIHVfKOprbiAtuBwxbW CfZk36gL1o586THLcttECJUwxSQSUGFZlzPeqa98w8vn7v53y2uHACdchbYW5bl4vonq ODyw== X-Forwarded-Encrypted: i=1; AJvYcCVKTpijQCbWMy0BTr/dXbaas4W6evSuIy1sBjG4N2wn8u3yMHB0o0yWYsNhHMneoL/eXjLp+gogyQafVMotyzGS61mx6s6hd5KQCLqihMM= X-Gm-Message-State: AOJu0Yy3zlzFGzFYsJ/vuhgNXIOxVkoULppQCRqolVstDiMqa9BruD4E F4pCSuj65Zy3enZTQT/kr9UHWLeYyaaUNSgpAu91R7GtZpT+HfvnpTL0Y+RHDw== X-Google-Smtp-Source: AGHT+IGyT1N1ArT6wfbi4oBxSpAokhc2hzaioChczY5/FHl8YM7G9M2aFWMiBDCYmWBmklMKlqqHDA== X-Received: by 2002:a17:907:d30b:b0:a3e:b523:90b with SMTP id vg11-20020a170907d30b00b00a3eb523090bmr7594933ejc.14.1710254236414; Tue, 12 Mar 2024 07:37:16 -0700 (PDT) Message-ID: <6286d582-ef92-47c3-8bb1-b8f2d3270a4f@suse.com> Date: Tue, 12 Mar 2024 15:37:15 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] drivers/char: mark XHCI DMA buffers reserved in memory map Content-Language: en-US To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org, Andrew Cooper , Wei Liu , George Dunlap , Julien Grall , Stefano Stabellini References: <20240311203431.342530-1-marmarek@invisiblethingslab.com> <6a80ceb6-cc2a-4d8f-9a66-70063923b0ea@suse.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 12.03.2024 15:24, Marek Marczykowski-Górecki wrote: > On Tue, Mar 12, 2024 at 11:53:46AM +0100, Jan Beulich wrote: >> On 12.03.2024 11:24, Roger Pau Monné wrote: >>>> --- a/xen/arch/x86/setup.c >>>> +++ b/xen/arch/x86/setup.c >>>> @@ -1806,6 +1806,9 @@ void asmlinkage __init noreturn __start_xen(unsigned long mbi_p) >>>> mmio_ro_ranges = rangeset_new(NULL, "r/o mmio ranges", >>>> RANGESETF_prettyprint_hex); >>>> >>>> + /* Needs to happen after E820 processing but before IOMMU init */ >>>> + xhci_dbc_uart_reserve_ram(); >>> >>> Overall it might be better if some generic solution for all users of >>> iommu_add_extra_reserved_device_memory() could be implemented, >> >> +1 >> >>> but I'm >>> unsure whether the intention is for the interface to always be used >>> against RAM. >> >> I think we can work from that assumption for now. > > One more question - what should be the error handling in this case? My first reaction here is - please first propose something that's sensible from your perspective, and then we can go from there. That's generally easier that discussion without seeing involved code. However, ... > At > this stage, if reserving fails, I can still skip giving this range to > the IOMMU driver, which (most likely) will result in IOMMU faults and > in-operational device (xhci console). Since I don't know (theoretically) > what driver requested the range, the error message can only contain an > address and device, so will be a bit less actionable for the user > (although it should be quite easy to notice the BDF being the XHCI one). > > Panic surely is safer option, but less user friendly, especially since > (due to the above) I cannot give explicit hint to disable XHCI console. ... reading this I was meaning to ... > And kinda independently - I'm tempted to add another field to `struct > extra_reserved_range` (and an argument to > `iommu_add_extra_reserved_device_memory()`) - textual description, for > the error reporting purpose. ... suggest minimally this. We may want to go farther, though: The party registering the range could also supply a callback, to be invoked in case registration fails. That callback could then undo whatever is necessary in order to not use the memory range in question. That said - isn't all of this over-engineering, as the allocated memory range must have come from a valid RAM region? In which case a simple BUG_ON() may be all that's needed (and will never trigger in practice, unless we truly screwed up somewhere)? Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 12 14:45:01 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 14:45:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691889.1078420 (Exim 4.92) (envelope-from ) id 1rk3NA-0004ug-LQ; Tue, 12 Mar 2024 14:44:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691889.1078420; Tue, 12 Mar 2024 14:44:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk3NA-0004uZ-IO; Tue, 12 Mar 2024 14:44:56 +0000 Received: by outflank-mailman (input) for mailman id 691889; Tue, 12 Mar 2024 14:44:55 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk3N9-0004uR-F5 for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 14:44:55 +0000 Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [2a00:1450:4864:20::632]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 1622185a-e07f-11ee-a1ee-f123f15fe8a2; Tue, 12 Mar 2024 15:44:53 +0100 (CET) Received: by mail-ej1-x632.google.com with SMTP id a640c23a62f3a-a449c5411e1so5694566b.1 for ; Tue, 12 Mar 2024 07:44:53 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id wk8-20020a170907054800b00a46021ef90csm3646751ejb.107.2024.03.12.07.44.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 Mar 2024 07:44:52 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1622185a-e07f-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1710254693; x=1710859493; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=xz85V7dr+KazXifa+zWdglCjBgOJ02wy4vGnNj+JMG4=; b=dnZaz3eyMgXpyKJTZJbyAmX0O7e7iNiwh57ct3IVLCtfz6besni9NAsJR6UzqW8Dcb KN0RsCwuZlaa3LZsQX5GHjlEnnZ5OfWgwznD2NxYIcn8xblHdgmCyeFbQVEDcxVfNBw+ GSs+IuRld6mE31XWU+gc9QS6LylV6hsbqwO/CvQKSr5CjYnyZZ/hUhgzN0VOnNW6XuSe z+p7zSnl36N4lD5cljN5c3YgTJWbWuk58ogcJmi5Wh0Pq4N1fdB47nD8I1LtoSu5hVbv g60Z8Sh33H2muIAN0awsei6w5iLpp5lJ8wANosUfCWeuBxIkR9F5uLrizGcZm6lAxNJg pCkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710254693; x=1710859493; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=xz85V7dr+KazXifa+zWdglCjBgOJ02wy4vGnNj+JMG4=; b=UH8W5DtkYYAu9Ztu2yUQ96bz/BnJdOtc66E0gDgZWxzOz3CLVcpYee1NDFGePef9DQ oBYWkmmPcoNiGhgkKwQV70Y+O6iBedmw1wI/A6GkEYIRmkM6aT1KuK50HLWnrfgcKmLl 3U8hJxl403XcXyXiVxwbYNfOROL6VjCAH7Tc2rZHZ+JLxnWTxTVit/4mWiFqU3j5ZIGt /p2L8FiPSHj2NTKnW1GFWF3mk5Ba8qvq+nBETcWevr2Pf5RVuEvcN3SDUfrM/i8pighR CV0UzJr7uGr9G/s2klZvuqHDZ2wYW0CZo+bAWqROIj9Qg1+pncDrkfrHZ6b76OqK8OsB zbDw== X-Forwarded-Encrypted: i=1; AJvYcCU6sRyVe7/8GdFHgX5aOcBL1ytU6HksMyUldd12PevYZjmWsVixXdGBaeQKcqRNSYloJ6J63p0VwOmW6q8NeSvWwoqZ3DqucMnnp9CQVqQ= X-Gm-Message-State: AOJu0Yzgy8yeezWyl5TwV134pOeAdiRgiOorq46Lm0QnQoTSs/z1/WmL QxHRm4kbdugV1dV9DImOSeE3OgozhBPrT9Ft3MN8TCWZHeH6/iaJ0lUzIOsoIg== X-Google-Smtp-Source: AGHT+IEgx3RM07WB6h6B+eW+MMazojnoti3kW1+aojuxETf9wEGGKR8O9CYRmQe+bZdeIcalsJ43lg== X-Received: by 2002:a17:906:5a8c:b0:a43:3b2:bcf6 with SMTP id l12-20020a1709065a8c00b00a4303b2bcf6mr379447ejq.14.1710254692726; Tue, 12 Mar 2024 07:44:52 -0700 (PDT) Message-ID: Date: Tue, 12 Mar 2024 15:44:51 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH v3 12/16] xen: address violations of MISRA C:2012 Directive 4.10 Content-Language: en-US To: Simone Ballarin , Maria Celeste Cesario Cc: consulting@bugseng.com, sstabellini@kernel.org, Andrew Cooper , George Dunlap , Julien Grall , Wei Liu , xen-devel@lists.xenproject.org References: From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 11.03.2024 09:59, Simone Ballarin wrote: > --- a/xen/build.mk > +++ b/xen/build.mk > @@ -45,6 +45,8 @@ asm-offsets.s: arch/$(SRCARCH)/$(ARCH)/asm-offsets.c > $(CC) $(call cpp_flags,$(c_flags)) -S -g0 -o $@.new -MQ $@ $< > $(call move-if-changed,$@.new,$@) > > +ARCHDIR = $(shell echo $(SRCARCH) | tr a-z A-Z) Yet another instance? > --- a/xen/scripts/Makefile.asm-generic > +++ b/xen/scripts/Makefile.asm-generic > @@ -31,8 +31,22 @@ generated-y := $(addprefix $(obj)/, $(generated-y)) > old-headers := $(wildcard $(obj)/*.h) > unwanted := $(filter-out $(generic-y) $(generated-y),$(old-headers)) > > +define header_stub > +#ifndef ASM_GENERIC_$(3)_$(2)_H > +#define ASM_GENERIC_$(3)_$(2)_H > + > +#include > + > +#endif /* ASM_GENERIC_$(3)_$(2)_H */ > +endef > + > +arch = $(shell echo $(SRCARCH) | tr a-z A-Z) And one more, in disguise - why not ARCHDIR here? > +header_body = $(call header_stub,$*,$(shell echo "$*" | tr a-z A-Z),$(arch)) > +export header_body This ought to be doable without involving a shell variable, I'd hope. But - this is a lot of effort just to ... > quiet_cmd_wrap = WRAP $@ > - cmd_wrap = echo "\#include " > $@ > + cmd_wrap = echo "$$header_body" > $@ ... deal with an innocent header consisting of just a single #include. Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 12 14:49:16 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 14:49:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691892.1078430 (Exim 4.92) (envelope-from ) id 1rk3RJ-0005l5-5S; Tue, 12 Mar 2024 14:49:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691892.1078430; Tue, 12 Mar 2024 14:49:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk3RJ-0005ky-2P; Tue, 12 Mar 2024 14:49:13 +0000 Received: by outflank-mailman (input) for mailman id 691892; Tue, 12 Mar 2024 14:49:11 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk3RH-0005kp-Av for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 14:49:11 +0000 Received: from wfout2-smtp.messagingengine.com (wfout2-smtp.messagingengine.com [64.147.123.145]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id ae08bf3f-e07f-11ee-a1ee-f123f15fe8a2; Tue, 12 Mar 2024 15:49:09 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailfout.west.internal (Postfix) with ESMTP id 343261C000BB; Tue, 12 Mar 2024 10:49:06 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Tue, 12 Mar 2024 10:49:06 -0400 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 12 Mar 2024 10:49:04 -0400 (EDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ae08bf3f-e07f-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= invisiblethingslab.com; h=cc:cc:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1710254945; x=1710341345; bh=T2Q+WJNq02k8Pv37K1fkr0orQ6W/GMwWl8daG0xqNw8=; b= fqHiRT1T1moNt8HzPm5woPiHmtgdfSwlVf3ubddIu7Or98nHRyjVdOUgVk/BJoG8 aYZgBgerqrmh0ikPheM/lpZT4kzxWSZeos6dI2X8V7/pZgsYQMNgyfu6kLZxXVUs zBy0X/Yib6W/87xYMZFXx4E8RfiriaZlAOgIlKQ17S0R3ZxizNIDNWSOUuqzlgRf mgLPnks3JMEP+REHf++7feFG4xMHhx6LZIhtArZgyIRQ8+7UXdux0ctHY4ctjNCZ aQolwSluH4cnv7C/D0SF9BT1QzS9k3PQ/EAJ//icLXDEcCNNEI3V8ZzYGi4sKOCK gD9Bcok8zDaOyKl7lfyUpg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1710254945; x=1710341345; bh=T2Q+WJNq02k8Pv37K1fkr0orQ6W/ GMwWl8daG0xqNw8=; b=BduQHtMVqr5fHWrpefVzU34cYyn11fLtJjNQvbS6n+Lq /OeGekwTuM7NBJlgCDP5B540HDg3rYEvkw5cqAifFmknmSgGWRWsIw9yRoU2XHfI CxWUSlS26crrlJz1jOK7eSzfn9iDDj6wE9ty+gm3FrQwl1NGqoo15CmthRSkunTh hShn4nl8CwwqIXpAH/hq9yo4RgaO673lLpv2ltA8TBDqFYHNOS3+rjneQAE7wxZ9 NRDLx5Tg5IBbuPC9qwWp7jhOyfmxAsOrc7Sw2wDw7nG5nSCFzuUBPk2qiJFbdgCE LWEO8r2uYkOLpk+d5W4MAkhqfCHf0YVd8TslV/E4dQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrjeefgdeikecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvvefukfhfgggtuggjsehgtderredttdejnecuhfhrohhmpeforghrvghk ucforghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvh hishhisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpefgudel teefvefhfeehieetleeihfejhfeludevteetkeevtedtvdegueetfeejudenucevlhhush htvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhes ihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhm X-ME-Proxy: Feedback-ID: i1568416f:Fastmail Date: Tue, 12 Mar 2024 15:49:01 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Jan Beulich Cc: Roger Pau =?utf-8?B?TW9ubsOp?= , xen-devel@lists.xenproject.org, Andrew Cooper , Wei Liu , George Dunlap , Julien Grall , Stefano Stabellini Subject: Re: [PATCH] drivers/char: mark XHCI DMA buffers reserved in memory map Message-ID: References: <20240311203431.342530-1-marmarek@invisiblethingslab.com> <6a80ceb6-cc2a-4d8f-9a66-70063923b0ea@suse.com> <6286d582-ef92-47c3-8bb1-b8f2d3270a4f@suse.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="PnjxCYIQ+rRJIJpx" Content-Disposition: inline In-Reply-To: <6286d582-ef92-47c3-8bb1-b8f2d3270a4f@suse.com> --PnjxCYIQ+rRJIJpx Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Mar 2024 15:49:01 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Jan Beulich Cc: Roger Pau =?utf-8?B?TW9ubsOp?= , xen-devel@lists.xenproject.org, Andrew Cooper , Wei Liu , George Dunlap , Julien Grall , Stefano Stabellini Subject: Re: [PATCH] drivers/char: mark XHCI DMA buffers reserved in memory map On Tue, Mar 12, 2024 at 03:37:15PM +0100, Jan Beulich wrote: > On 12.03.2024 15:24, Marek Marczykowski-G=C3=B3recki wrote: > > On Tue, Mar 12, 2024 at 11:53:46AM +0100, Jan Beulich wrote: > >> On 12.03.2024 11:24, Roger Pau Monn=C3=A9 wrote: > >>>> --- a/xen/arch/x86/setup.c > >>>> +++ b/xen/arch/x86/setup.c > >>>> @@ -1806,6 +1806,9 @@ void asmlinkage __init noreturn __start_xen(un= signed long mbi_p) > >>>> mmio_ro_ranges =3D rangeset_new(NULL, "r/o mmio ranges", > >>>> RANGESETF_prettyprint_hex); > >>>> =20 > >>>> + /* Needs to happen after E820 processing but before IOMMU init = */ > >>>> + xhci_dbc_uart_reserve_ram(); > >>> > >>> Overall it might be better if some generic solution for all users of > >>> iommu_add_extra_reserved_device_memory() could be implemented, > >> > >> +1 > >> > >>> but I'm > >>> unsure whether the intention is for the interface to always be used > >>> against RAM. > >> > >> I think we can work from that assumption for now. > >=20 > > One more question - what should be the error handling in this case? >=20 > My first reaction here is - please first propose something that's > sensible from your perspective, and then we can go from there. That's > generally easier that discussion without seeing involved code. > However, ... >=20 > > At > > this stage, if reserving fails, I can still skip giving this range to > > the IOMMU driver, which (most likely) will result in IOMMU faults and > > in-operational device (xhci console). Since I don't know (theoretically) > > what driver requested the range, the error message can only contain an > > address and device, so will be a bit less actionable for the user > > (although it should be quite easy to notice the BDF being the XHCI one). > >=20 > > Panic surely is safer option, but less user friendly, especially since > > (due to the above) I cannot give explicit hint to disable XHCI console. >=20 > ... reading this I was meaning to ... >=20 > > And kinda independently - I'm tempted to add another field to `struct > > extra_reserved_range` (and an argument to > > `iommu_add_extra_reserved_device_memory()`) - textual description, for > > the error reporting purpose. >=20 > ... suggest minimally this. We may want to go farther, though: The party > registering the range could also supply a callback, to be invoked in > case registration fails. That callback could then undo whatever is > necessary in order to not use the memory range in question. >=20 > That said - isn't all of this over-engineering, as the allocated memory > range must have come from a valid RAM region? In which case a simple > BUG_ON() may be all that's needed (and will never trigger in practice, > unless we truly screwed up somewhere)? In this case (with a single use of iommu_add_extra_reserved_device_memory()), it will be valid RAM. But reserving may fail for other reasons too, for example overflow of the E820 map. Undoing things certainly is possible, but quite complicated (none of the involved serial console APIs support disabling/unregistering a console). Given the simplicity of the workaround user can do (not enabling xhci console), I don't think it's worth going this route. Anyway, I'll post v2 with some version of the above and we can continue discussion there. --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab --PnjxCYIQ+rRJIJpx Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmXwa14ACgkQ24/THMrX 1yyqAgf/R53YqHxmnYPijYE6YRdufBlcewDX5yJybHcZ2BMxy2hDSgLhngVQp1hS kBDJBYKPXPzr+F9DbRQq4ZHU1MdG3G80j0LS5niGiVYlpMhfE9dBJvg1QhC3zeTF Yy8QBH/FAtICCEE13X1dFIo+VFC5UFiTOQF8GsWSsFHcLpCdPIOaDTyfr8Kr0J3o B4Ap/W9Cz5FrWBDchKkl85DetONvxN7k0z+NpbkDNhqXZvOLpYSHiXB8JRcx4MEg yjCAHpJiAUbO5TYEtun2rWypfifAp3zJYCcf/LA19BsAvPaCb2E//C8ioOPVAfHp 3hrHcOPRF9ewFdzg91b0XcLZP9nOVQ== =wHrp -----END PGP SIGNATURE----- --PnjxCYIQ+rRJIJpx-- From xen-devel-bounces@lists.xenproject.org Tue Mar 12 14:58:49 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 14:58:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691896.1078440 (Exim 4.92) (envelope-from ) id 1rk3aV-0007Y6-0Z; Tue, 12 Mar 2024 14:58:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691896.1078440; Tue, 12 Mar 2024 14:58:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk3aU-0007Xz-Ty; Tue, 12 Mar 2024 14:58:42 +0000 Received: by outflank-mailman (input) for mailman id 691896; Tue, 12 Mar 2024 14:58:42 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk3aU-0007Xt-GN for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 14:58:42 +0000 Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [2a00:1450:4864:20::232]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 031b7454-e081-11ee-a1ee-f123f15fe8a2; Tue, 12 Mar 2024 15:58:40 +0100 (CET) Received: by mail-lj1-x232.google.com with SMTP id 38308e7fff4ca-2d109e82bd0so78151641fa.3 for ; Tue, 12 Mar 2024 07:58:40 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id fj10-20020a0564022b8a00b00565af2ea649sm3973699edb.14.2024.03.12.07.58.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 Mar 2024 07:58:39 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 031b7454-e081-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1710255520; x=1710860320; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=3HjKGRpfIuNggACzJB+28pH8IV0WC3Ki+EkzhoSBzjM=; b=fyfoL1HBwvjhu2lXHoBMm2+/eRpqhCqPTlFrri1it4LQHqNK6TnEcjBgROnUqtfd6S Z1qWCS0YxfHlWMvBng+oodXEoftbgphJcX+RJ3kZHwNEbZjq7q0qEVHFu1rSNE5fOx1y chbZtm45i1moAy0tiTwFDIT2BNa7fa2ldcOmRwK+0gqLXk1NJ2KNoRedVLJolKbM28Jt 9yznQ/3xUOP08K9q6DbZUkLCvXDR3G8M+qIKwizZOhQEaQZP6+uJqwtm6xdtqkFYt/QJ C0msWAfqHLJnWR4RalL9fatOM/bylCutiC4z/UOQ9BhaVDyCTXechBNAatcT68R8hSBa 4aow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710255520; x=1710860320; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=3HjKGRpfIuNggACzJB+28pH8IV0WC3Ki+EkzhoSBzjM=; b=cKiEHN53o+avBoqwXLLQ/4TYLn/Kl0YMhRZKeGUD8xcX9OFTEAi+TqkL8BrRX1zFWj Og1spiioufK9jusFyluTK9V+28hwMhhuJAgFitUGOKgdS4QjbuMx8uCsSy6ZhfOBA8JG RO+Ge4nkRysbtNmn04QS0sTycWZnylPNwWsBytG386J3MXOZHPStFhEC/FzuOKWXUaEq 3fCQctBQnTj21d7Bnfn376bv1jrpke+iehDBVz0dIMitKdptd6uze6/m+Q9xPeUKZVPr +ugJaLHCLTVg0IndKgCzC67cc6QQIlxjWl7+bOLzmTJkN/IX9IbsYnfj3bnKlQVrd2+V wrww== X-Forwarded-Encrypted: i=1; AJvYcCXtQZEYR6m+4mLlHyu/m9p7L15ksNxkyx5P1zdr6RQUIYROQVAyXGt6YDtHqfRBuFsEuRImBgQQVOjylt0auS58dbbzVfFg/dBwmhfU050= X-Gm-Message-State: AOJu0YwMRqHxdb4X90HxGOsmxWVShakRxI/ArozXPqIUEArRrSOjJSFL OR9Nq8WO0v2zrnwG/RCgi+pPXpbdlTXCkIMsB2pi8b9Fy0NFsHhcjQmVDBFw1g== X-Google-Smtp-Source: AGHT+IFHG3yO7+3ZkrAhRPtrWb/engaW6sYGVj7uyqEP07T4dGw0t61HAUq21WAmse+vhjrTXCDDjg== X-Received: by 2002:a05:651c:80d:b0:2d2:ccd2:3a9b with SMTP id r13-20020a05651c080d00b002d2ccd23a9bmr6036994ljb.28.1710255519791; Tue, 12 Mar 2024 07:58:39 -0700 (PDT) Message-ID: <9c4bbb6f-60d6-43b8-aa82-35fa6f393e23@suse.com> Date: Tue, 12 Mar 2024 15:58:38 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH v3 13/16] xen: add deviations for MISRA C.2012 Directive 4.10 Content-Language: en-US To: Simone Ballarin , Maria Celeste Cesario Cc: consulting@bugseng.com, sstabellini@kernel.org, Doug Goldstein , Andrew Cooper , George Dunlap , Julien Grall , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <787aa5a65135796c825d366b43e00ba018c0065b.1710145041.git.simone.ballarin@bugseng.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <787aa5a65135796c825d366b43e00ba018c0065b.1710145041.git.simone.ballarin@bugseng.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 11.03.2024 09:59, Simone Ballarin wrote: > From: Maria Celeste Cesario > > Add safe deviation for *.c files, as estabilished in past discussion. > Add SAF deviation for files that need an #include directive before guard. While similar topics, the two are technically entirely different, and hence would likely again better be split. In fact I think I might ack the former as is, while ... > --- a/xen/include/public/arch-x86/xen.h > +++ b/xen/include/public/arch-x86/xen.h > @@ -7,6 +7,7 @@ > * Copyright (c) 2004-2006, K A Fraser > */ > > +/* SAF-7-safe include before guard needed for correct code generation */ > #include "../xen.h" > > #ifndef __XEN_PUBLIC_ARCH_X86_XEN_H__ ... I fear I lack details about the need for this, not even taking into account my earlier remark regarding the insertion of such comments in public headers. Why is the #include needed for our own purposes (we can't easily (re)move it entirely, as external consumers may rely on it)? The common case is for this header to be included from ../xen.h. In that case, aiui, the #include above has no effect at all, due to the guard in ../xen.h. Which leaves direct inclusions of the header here. There I'd expect a change like the one here to be accompanied by clarification of why those few cases can't be switched to including public/xen.h instead. Because if that was possible, doing so would allow us to get away here without any deviation. Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 12 15:02:58 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 15:02:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691899.1078452 (Exim 4.92) (envelope-from ) id 1rk3eb-00017I-KF; Tue, 12 Mar 2024 15:02:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691899.1078452; Tue, 12 Mar 2024 15:02:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk3eb-00017B-Fw; Tue, 12 Mar 2024 15:02:57 +0000 Received: by outflank-mailman (input) for mailman id 691899; Tue, 12 Mar 2024 15:02:56 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk3ea-000173-4U for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 15:02:56 +0000 Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [2a00:1450:4864:20::631]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 9a5ee11d-e081-11ee-a1ee-f123f15fe8a2; Tue, 12 Mar 2024 16:02:54 +0100 (CET) Received: by mail-ej1-x631.google.com with SMTP id a640c23a62f3a-a4627a7233aso8620466b.1 for ; Tue, 12 Mar 2024 08:02:54 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id e27-20020a170906315b00b00a46220c3c39sm2426599eje.39.2024.03.12.08.02.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 Mar 2024 08:02:53 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 9a5ee11d-e081-11ee-a1ee-f123f15fe8a2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1710255773; x=1710860573; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=H3gCzu8ARyqrSY7VwQNo7wczR4eVQYg4J0ukImiGafs=; b=EGlVi4h3ruiNi8WlEGuQEEQsT9nJMHQ2cLMc8sK44Qmmyjyq3DpIVNR9yjge10KkPy mdHHULqmJeOLy51pdNtmLdflSSWx/srh/u75+qUQbP3Ne8SvOfUqD/WtBVwASe5Fyndd kUuRTS1GhOmgwBHSyQtx1KP8krFgn/0vQTm2RvqvHEXDdwAwK7Fz+LzhC5+e81r5v9mo La9YJwq60uYPmH7Lr4YHuFV+KC+aBeoAhiel8EHhSpHgDvl0ww6UyUyETjbzr5rOYRdj 5ognTSuYfagXMOkkdRuIxooS7t4SKFVFbohGLzAalUXzOBdnLHGhCK5NgrktHnLoWMCe MTyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710255773; x=1710860573; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=H3gCzu8ARyqrSY7VwQNo7wczR4eVQYg4J0ukImiGafs=; b=fr/Ud69GwgIpKAHsorn7+oUjpMxeg2AR46PfV/i5C0dljyqxYw5eX2ZUU5ExizfXmO VLRe5ca7nhwU7VtJtI///Q0MkaLVrAlJaqOj/9Kami2NaIsV+WJ8rRk375oiz9sVYj12 XX/ea0DBx0GnYO9UjMv+9UqyDbx/SlT+3k9GuRdh3fwzZBT4+fb6x0hxaMjBMr41lrbr TeZeBQdamSSbrbIcgX70cpXePCBvDBlz9PkhovqRzgbdjFNkTrsRWAtsIGN6Ml1ifNNu /2aK1d7KpnKKyqt6kVRXHZ24vxsfoww0NFsDljEQ5XVIbYqJhTk2dV6WQ+cxWFpieLvJ bLUw== X-Forwarded-Encrypted: i=1; AJvYcCWXEHUee8aIWLqlsLB8FXVtgUQWaW/bby9aKQSOSwn+v4reDDooBE10GXHsXpBWxbmkaCUl79ZrrgjyAfBAi3L1AIxP9kpHUo9F/YIB5FE= X-Gm-Message-State: AOJu0Yy/ilnykSVVRGp7puzdWdKcgfvab0H9Kg2WgjjwMNkkgyZWR3w7 uMlZTgoPYlJO9g0XObW02g9ZD94LLwLiCieb5Fzxq+9OjKSAiN2A/8LEcY3+Kg== X-Google-Smtp-Source: AGHT+IFHePa92tGkLK3FNGG1AH8RJXDMwqEqsyI1z1ia3ohmOSDqPivvlBtSEXG3YS4TG8zYtOwzmQ== X-Received: by 2002:a17:906:3e0c:b0:a43:cbed:950d with SMTP id k12-20020a1709063e0c00b00a43cbed950dmr7213635eji.38.1710255773609; Tue, 12 Mar 2024 08:02:53 -0700 (PDT) Message-ID: <6a3f66a7-bd5c-4355-8847-47bfc9033ab3@suse.com> Date: Tue, 12 Mar 2024 16:02:52 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] drivers/char: mark XHCI DMA buffers reserved in memory map Content-Language: en-US To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org, Andrew Cooper , Wei Liu , George Dunlap , Julien Grall , Stefano Stabellini References: <20240311203431.342530-1-marmarek@invisiblethingslab.com> <6a80ceb6-cc2a-4d8f-9a66-70063923b0ea@suse.com> <6286d582-ef92-47c3-8bb1-b8f2d3270a4f@suse.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 12.03.2024 15:49, Marek Marczykowski-Górecki wrote: > On Tue, Mar 12, 2024 at 03:37:15PM +0100, Jan Beulich wrote: >> On 12.03.2024 15:24, Marek Marczykowski-Górecki wrote: >>> On Tue, Mar 12, 2024 at 11:53:46AM +0100, Jan Beulich wrote: >>>> On 12.03.2024 11:24, Roger Pau Monné wrote: >>>>>> --- a/xen/arch/x86/setup.c >>>>>> +++ b/xen/arch/x86/setup.c >>>>>> @@ -1806,6 +1806,9 @@ void asmlinkage __init noreturn __start_xen(unsigned long mbi_p) >>>>>> mmio_ro_ranges = rangeset_new(NULL, "r/o mmio ranges", >>>>>> RANGESETF_prettyprint_hex); >>>>>> >>>>>> + /* Needs to happen after E820 processing but before IOMMU init */ >>>>>> + xhci_dbc_uart_reserve_ram(); >>>>> >>>>> Overall it might be better if some generic solution for all users of >>>>> iommu_add_extra_reserved_device_memory() could be implemented, >>>> >>>> +1 >>>> >>>>> but I'm >>>>> unsure whether the intention is for the interface to always be used >>>>> against RAM. >>>> >>>> I think we can work from that assumption for now. >>> >>> One more question - what should be the error handling in this case? >> >> My first reaction here is - please first propose something that's >> sensible from your perspective, and then we can go from there. That's >> generally easier that discussion without seeing involved code. >> However, ... >> >>> At >>> this stage, if reserving fails, I can still skip giving this range to >>> the IOMMU driver, which (most likely) will result in IOMMU faults and >>> in-operational device (xhci console). Since I don't know (theoretically) >>> what driver requested the range, the error message can only contain an >>> address and device, so will be a bit less actionable for the user >>> (although it should be quite easy to notice the BDF being the XHCI one). >>> >>> Panic surely is safer option, but less user friendly, especially since >>> (due to the above) I cannot give explicit hint to disable XHCI console. >> >> ... reading this I was meaning to ... >> >>> And kinda independently - I'm tempted to add another field to `struct >>> extra_reserved_range` (and an argument to >>> `iommu_add_extra_reserved_device_memory()`) - textual description, for >>> the error reporting purpose. >> >> ... suggest minimally this. We may want to go farther, though: The party >> registering the range could also supply a callback, to be invoked in >> case registration fails. That callback could then undo whatever is >> necessary in order to not use the memory range in question. >> >> That said - isn't all of this over-engineering, as the allocated memory >> range must have come from a valid RAM region? In which case a simple >> BUG_ON() may be all that's needed (and will never trigger in practice, >> unless we truly screwed up somewhere)? > > In this case (with a single use of > iommu_add_extra_reserved_device_memory()), it will be valid RAM. But > reserving may fail for other reasons too, for example overflow of the > E820 map. > > Undoing things certainly is possible, but quite complicated (none of the > involved serial console APIs support disabling/unregistering a console). True. I was rather thinking of disabling the actual I/O paths. Jan > Given the simplicity of the workaround user can do (not enabling xhci > console), I don't think it's worth going this route. > > Anyway, I'll post v2 with some version of the above and we can continue > discussion there. > From xen-devel-bounces@lists.xenproject.org Tue Mar 12 15:12:04 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2024 15:12:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.691903.1078461 (Exim 4.92) (envelope-from ) id 1rk3nM-0002pY-Cc; Tue, 12 Mar 2024 15:12:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 691903.1078461; Tue, 12 Mar 2024 15:12:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk3nM-0002pR-A5; Tue, 12 Mar 2024 15:12:00 +0000 Received: by outflank-mailman (input) for mailman id 691903; Tue, 12 Mar 2024 15:11:58 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rk3nK-0002pL-NA for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 15:11:58 +0000 Received: from 2.mo561.mail-out.ovh.net (2.mo561.mail-out.ovh.net [46.105.75.36]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id dd8a34af-e082-11ee-a1ee-f123f15fe8a2; Tue, 12 Mar 2024 16:11:56 +0100 (CET) Received: from director8.ghost.mail-out.ovh.net (unknown [10.108.9.127]) by mo561.mail-out.ovh.net (Postfix) with ESMTP id 4TvHDW6mX1z1Lv0 for ; Tue, 12 Mar 2024 15:11:55 +0000 (UTC) Received: from ghost-submission-6684bf9d7b-fvjjd (unknown [10.110.113.248]) by director8.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 513C61FEAE; Tue, 12 Mar 2024 15:11:54 +0000 (UTC) Received: from 3mdeb.com ([37.59.142.103]) by ghost-submission-6684bf9d7b-fvjjd with ESMTPSA id kberBrpw8GWC8wAAiou2OA (envelope-from ); Tue, 12 Mar 2024 15:11:54 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: dd8a34af-e082-11ee-a1ee-f123f15fe8a2 Authentication-Results:garm.ovh; auth=pass (GARM-103G00555f2a4c5-7213-4f8a-ace8-6da5233e50cd, 0B6B113C544506A41C6EB031E0F94F2E66B6AEBC) smtp.auth=krystian.hebel@3mdeb.com X-OVh-ClientIp:217.171.61.25 Content-Type: multipart/alternative; boundary="------------X4xXLmr0taTvN3dkBTqSXMLF" Message-ID: Date: Tue, 12 Mar 2024 16:11:51 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH 1/9] x86/boot: choose AP stack based on APIC ID Content-Language: en-US To: Jan Beulich Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org, Wei Liu References: <0e7dd957b6f26fa7b752bdce1ef6ebe97c825903.1699982111.git.krystian.hebel@3mdeb.com> From: Krystian Hebel In-Reply-To: X-Ovh-Tracer-Id: 8123086356890954096 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedvledrjeefgdejfecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpegtkfffgggfuffvvehfhfgjsegrtderredtvdejnecuhfhrohhmpefmrhihshhtihgrnhcujfgvsggvlhcuoehkrhihshhtihgrnhdrhhgvsggvlhesfehmuggvsgdrtghomheqnecuggftrfgrthhtvghrnhepjefftddvhfeljedujeelleegjeeiffeuvefgffeuieeuhfetleeuteefffevueeinecuffhomhgrihhnpehtrhgrmhhpohhlihhnvgdrshgspdigkeeipgeigedrshgspdefmhguvggsrdgtohhmnecukfhppeduvdejrddtrddtrddupddvudejrddujedurdeiuddrvdehpdefjedrheelrddugedvrddutdefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepuddvjedrtddrtddruddpmhgrihhlfhhrohhmpehkrhihshhtihgrnhdrhhgvsggvlhesfehmuggvsgdrtghomhdpnhgspghrtghpthhtohepuddprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdpoffvtefjohhsthepmhhoheeiuddpmhhouggvpehsmhhtphhouhht This is a multi-part message in MIME format. --------------X4xXLmr0taTvN3dkBTqSXMLF Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 7.02.2024 17:11, Jan Beulich wrote: > On 14.11.2023 18:49, Krystian Hebel wrote: >> --- a/xen/arch/x86/boot/trampoline.S >> +++ b/xen/arch/x86/boot/trampoline.S >> @@ -72,6 +72,26 @@ trampoline_protmode_entry: >> mov $X86_CR4_PAE,%ecx >> mov %ecx,%cr4 >> >> + /* >> + * Get APIC ID while we're in non-paged mode. Start by checking if >> + * x2APIC is enabled. >> + */ >> + mov $MSR_APIC_BASE, %ecx >> + rdmsr >> + and $APIC_BASE_EXTD, %eax > You don't use the result, in which case "test" is to be preferred over > "and". Ack > >> + jnz .Lx2apic >> + >> + /* Not x2APIC, read from MMIO */ >> + mov 0xfee00020, %esp > Please don't open-code existing constants (APIC_ID here and below, > APIC_DEFAULT_PHYS_BASE just here, and ... > >> + shr $24, %esp > ... a to-be-introduced constant here (for {G,S}ET_xAPIC_ID() to use as > well then). This is the only way of being able to easily identify all > pieces of code accessing the same piece of hardware. Yes, this was also caught in review done by Qubes OS team. New constant and {G,S}ET_xAPIC_ID() should be in separate patch, I presume? >> + jmp 1f >> + >> +.Lx2apic: >> + mov $(MSR_X2APIC_FIRST + (0x20 >> 4)), %ecx >> + rdmsr >> + mov %eax, %esp >> +1: > Overall I'm worried of the use of %esp throughout here. > >> --- a/xen/arch/x86/boot/x86_64.S >> +++ b/xen/arch/x86/boot/x86_64.S >> @@ -15,7 +15,33 @@ ENTRY(__high_start) >> mov $XEN_MINIMAL_CR4,%rcx >> mov %rcx,%cr4 >> >> - mov stack_start(%rip),%rsp >> + test %ebx,%ebx > Nit (style): Elsewhere you have blanks after the commas, just here > (and once again near the end of the hunk) you don't. Is either style preferred?This file has both. >> + cmovz stack_start(%rip), %rsp >> + jz .L_stack_set >> + >> + /* APs only: get stack base from APIC ID saved in %esp. */ >> + mov $-1, %rax > Why a 64-bit insn here and ... > >> + lea x86_cpu_to_apicid(%rip), %rcx >> +1: >> + add $1, %rax > ... here, when you only use (far less than) 32-bit values? Fair question, no idea what I had in mind, will change. >> + cmp $NR_CPUS, %eax >> + jb 2f >> + hlt >> +2: >> + cmp %esp, (%rcx, %rax, 4) >> + jne 1b > Aren't you open-coding REPNE SCASD here? Looks like I am, I missed that. I'm not sure if this will still apply after changes from further patches, but I'll keep that in mind. > >> + /* %eax is now Xen CPU index. */ >> + lea stack_base(%rip), %rcx >> + mov (%rcx, %rax, 8), %rsp >> + >> + test %rsp,%rsp >> + jnz 1f >> + hlt >> +1: >> + add $(STACK_SIZE - CPUINFO_sizeof), %rsp > Even this post-adjustment is worrying me. Imo the stack pointer is > better set exactly once, to its final value. Keeping it at its init > value of 0 until then yields more predictable results in case it > ends up being used somewhere. It really shouldn't be used anywhere, but I'll change it. >> --- a/xen/arch/x86/setup.c >> +++ b/xen/arch/x86/setup.c >> @@ -1951,6 +1951,7 @@ void __init noreturn __start_xen(unsigned long mbi_p) >> */ >> if ( !pv_shim ) >> { >> + /* Separate loop to make parallel AP bringup possible. */ >> for_each_present_cpu ( i ) >> { >> /* Set up cpu_to_node[]. */ >> @@ -1958,6 +1959,12 @@ void __init noreturn __start_xen(unsigned long mbi_p) >> /* Set up node_to_cpumask based on cpu_to_node[]. */ >> numa_add_cpu(i); >> >> + if ( stack_base[i] == NULL ) >> + stack_base[i] = cpu_alloc_stack(i); >> + } > Imo this wants accompanying by removal of the allocation in > cpu_smpboot_alloc(). Which would then make more visible that there's > error checking there, but not here (I realize there effectively is > error checking in assembly code, but that'll end in HLT with no > useful indication of what the problem is). Provided, as Julien has > pointed out, that the change is necessary in the first place. The allocation in cpu_smpboot_alloc() was left for hot-plug. This loops over present CPUs, not possible ones. > > Jan Best regards, -- Krystian Hebel Firmware Engineer https://3mdeb.com | @3mdeb_com --------------X4xXLmr0taTvN3dkBTqSXMLF Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit


On 7.02.2024 17:11, Jan Beulich wrote:
On 14.11.2023 18:49, Krystian Hebel wrote:

--- a/xen/arch/x86/boot/trampoline.S
+++ b/xen/arch/x86/boot/trampoline.S
@@ -72,6 +72,26 @@ trampoline_protmode_entry:
         mov     $X86_CR4_PAE,%ecx
         mov     %ecx,%cr4
 
+        /*
+         * Get APIC ID while we're in non-paged mode. Start by checking if
+         * x2APIC is enabled.
+         */
+        mov     $MSR_APIC_BASE, %ecx
+        rdmsr
+        and     $APIC_BASE_EXTD, %eax

You don't use the result, in which case "test" is to be preferred over
"and".
Ack


+        jnz     .Lx2apic
+
+        /* Not x2APIC, read from MMIO */
+        mov     0xfee00020, %esp

Please don't open-code existing constants (APIC_ID here and below,
APIC_DEFAULT_PHYS_BASE just here, and ...


+        shr     $24, %esp

... a to-be-introduced constant here (for {G,S}ET_xAPIC_ID() to use as
well then). This is the only way of being able to easily identify all
pieces of code accessing the same piece of hardware.

Yes, this was also caught in review done by Qubes OS team.

New constant and {G,S}ET_xAPIC_ID() should be in separate patch, I presume? 


      

        
+        jmp     1f
+
+.Lx2apic:
+        mov     $(MSR_X2APIC_FIRST + (0x20 >> 4)), %ecx
+        rdmsr
+        mov     %eax, %esp
+1:


      

      
Overall I'm worried of the use of %esp throughout here.



      

        
--- a/xen/arch/x86/boot/x86_64.S
+++ b/xen/arch/x86/boot/x86_64.S
@@ -15,7 +15,33 @@ ENTRY(__high_start)
         mov     $XEN_MINIMAL_CR4,%rcx
         mov     %rcx,%cr4
 
-        mov     stack_start(%rip),%rsp
+        test    %ebx,%ebx


      

      
Nit (style): Elsewhere you have blanks after the commas, just here
(and once again near the end of the hunk) you don't.

    

    Is either style preferred? This file has both.

    

      

      

        
+        cmovz   stack_start(%rip), %rsp
+        jz      .L_stack_set
+
+        /* APs only: get stack base from APIC ID saved in %esp. */
+        mov     $-1, %rax


      

      
Why a 64-bit insn here and ...



      

        
+        lea     x86_cpu_to_apicid(%rip), %rcx
+1:
+        add     $1, %rax


      

      
... here, when you only use (far less than) 32-bit values?

    

    Fair question, no idea what I had in mind, will change.

    

      

      

        
+        cmp     $NR_CPUS, %eax
+        jb      2f
+        hlt
+2:
+        cmp     %esp, (%rcx, %rax, 4)
+        jne     1b


      

      
Aren't you open-coding REPNE SCASD here?

    

    Looks like I am, I missed that. I'm not sure if this will still
    apply after

    changes from further patches, but I'll keep that in mind.

    

      



      

        
+        /* %eax is now Xen CPU index. */
+        lea     stack_base(%rip), %rcx
+        mov     (%rcx, %rax, 8), %rsp
+
+        test    %rsp,%rsp
+        jnz     1f
+        hlt
+1:
+        add     $(STACK_SIZE - CPUINFO_sizeof), %rsp


      

      
Even this post-adjustment is worrying me. Imo the stack pointer is
better set exactly once, to its final value. Keeping it at its init
value of 0 until then yields more predictable results in case it
ends up being used somewhere.

    

    It really shouldn't be used anywhere, but I'll change it.

    

      

      

        
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1951,6 +1951,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
      */
     if ( !pv_shim )
     {
+        /* Separate loop to make parallel AP bringup possible. */
         for_each_present_cpu ( i )
         {
             /* Set up cpu_to_node[]. */
@@ -1958,6 +1959,12 @@ void __init noreturn __start_xen(unsigned long mbi_p)
             /* Set up node_to_cpumask based on cpu_to_node[]. */
             numa_add_cpu(i);
 
+            if ( stack_base[i] == NULL )
+                stack_base[i] = cpu_alloc_stack(i);
+        }


      

      
Imo this wants accompanying by removal of the allocation in
cpu_smpboot_alloc(). Which would then make more visible that there's
error checking there, but not here (I realize there effectively is
error checking in assembly code, but that'll end in HLT with no
useful indication of what the problem is). Provided, as Julien has
pointed out, that the change is necessary in the first place.

    

    
The allocation in cpu_smpboot_alloc() was left for hot-plug. This
      loops

      over present CPUs, not possible ones.

    

      

Jan

    

    Best regards,

    
-- 
Krystian Hebel
Firmware Engineer
https://3mdeb.com | @3mdeb_com

  


--------------X4xXLmr0taTvN3dkBTqSXMLF--


From xen-devel-bounces@lists.xenproject.org Tue Mar 12 15:18:26 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Mar 2024 15:18:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.691907.1078470 (Exim 4.92)
	(envelope-from )
	id 1rk3tO-0003pr-1C; Tue, 12 Mar 2024 15:18:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 691907.1078470; Tue, 12 Mar 2024 15:18:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rk3tN-0003pk-Uu; Tue, 12 Mar 2024 15:18:13 +0000
Received: by outflank-mailman (input) for mailman id 691907;
 Tue, 12 Mar 2024 15:18:12 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rk3tM-0003oq-Q2
 for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 15:18:12 +0000
Received: from 17.mo583.mail-out.ovh.net (17.mo583.mail-out.ovh.net
 [46.105.56.132]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id bbe2e104-e083-11ee-a1ee-f123f15fe8a2;
 Tue, 12 Mar 2024 16:18:09 +0100 (CET)
Received: from director11.ghost.mail-out.ovh.net (unknown [10.108.9.56])
 by mo583.mail-out.ovh.net (Postfix) with ESMTP id 4TvHMh6sKrz1FHf
 for ; Tue, 12 Mar 2024 15:18:08 +0000 (UTC)
Received: from ghost-submission-6684bf9d7b-tbfnn (unknown [10.110.113.153])
 by director11.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 3C5EF1FEE2;
 Tue, 12 Mar 2024 15:18:08 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.99])
 by ghost-submission-6684bf9d7b-tbfnn with ESMTPSA
 id 0fW6CDBy8GUbuQAAEZrJMQ
 (envelope-from ); Tue, 12 Mar 2024 15:18:08 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: bbe2e104-e083-11ee-a1ee-f123f15fe8a2
Authentication-Results:garm.ovh; auth=pass (GARM-99G003ba63f0ec-b095-4aa9-bd73-0fd4d1b3a469,
                    0B6B113C544506A41C6EB031E0F94F2E66B6AEBC) smtp.auth=krystian.hebel@3mdeb.com
X-OVh-ClientIp:217.171.61.25
Content-Type: multipart/alternative;
 boundary="------------8naBNj30Wkav5P0Z3FbiTDV6"
Message-ID: 
Date: Tue, 12 Mar 2024 16:18:07 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 2/9] x86: don't access x86_cpu_to_apicid[] directly,
 use cpu_physical_id(cpu)
Content-Language: en-US
To: Jan Beulich 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu
 , xen-devel@lists.xenproject.org
References: 
 <705574ddb7f18bae9ed3f60ddf2e4bda02c70388.1699982111.git.krystian.hebel@3mdeb.com>
 <904f358b-c535-4de2-b31d-e593687af11b@suse.com>
From: Krystian Hebel 
In-Reply-To: <904f358b-c535-4de2-b31d-e593687af11b@suse.com>
X-Ovh-Tracer-Id: 8228076520021403993
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedvledrjeefgdejgecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpegtkfffgggfuffvvehfhfgjsegrtderredtvdejnecuhfhrohhmpefmrhihshhtihgrnhcujfgvsggvlhcuoehkrhihshhtihgrnhdrhhgvsggvlhesfehmuggvsgdrtghomheqnecuggftrfgrthhtvghrnheptddtledufedvgfettdevhffgtdegjeekveefgeelhfdvueegkeetueeuhfejgeetnecuffhomhgrihhnpeefmhguvggsrdgtohhmnecukfhppeduvdejrddtrddtrddupddvudejrddujedurdeiuddrvdehpdefjedrheelrddugedvrdelleenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeduvdejrddtrddtrddupdhmrghilhhfrhhomhepkhhrhihsthhirghnrdhhvggsvghlseefmhguvggsrdgtohhmpdhnsggprhgtphhtthhopedupdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhgpdfovfetjfhoshhtpehmohehkeefpdhmohguvgepshhmthhpohhuth

This is a multi-part message in MIME format.
--------------8naBNj30Wkav5P0Z3FbiTDV6
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 7.02.2024 17:28, Jan Beulich wrote:
> On 14.11.2023 18:49, Krystian Hebel wrote:
>> --- a/xen/arch/x86/apic.c
>> +++ b/xen/arch/x86/apic.c
>> @@ -950,7 +950,7 @@ __next:
>>        */
>>       if (boot_cpu_physical_apicid == -1U)
>>           boot_cpu_physical_apicid = get_apic_id();
>> -    x86_cpu_to_apicid[0] = get_apic_id();
>> +    cpu_physical_id(0) = get_apic_id();
> While personally I don't mind as much, I expect Andrew would not like
> this: Something that looks like a function call on the lhs is against
> what normal language structure would be.
This made me cringe as well, but I've seen something like this used in
other places (per_cpu() mostly) so I thought it was OK. I can change it.
>> --- a/xen/arch/x86/domain.c
>> +++ b/xen/arch/x86/domain.c
>> @@ -1615,7 +1615,7 @@ long do_vcpu_op(int cmd, unsigned int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg)
>>               break;
>>   
>>           cpu_id.phys_id =
>> -            (uint64_t)x86_cpu_to_apicid[v->vcpu_id] |
>> +            (uint64_t)cpu_physical_id(v->vcpu_id) |
>>               ((uint64_t)acpi_get_processor_id(v->vcpu_id) << 32);
> While the cast on the 2nd line is necessary, the one on the 2st isn't
> and would be nice to be dropped while touching the line anyway.
Ack
>
>> --- a/xen/arch/x86/numa.c
>> +++ b/xen/arch/x86/numa.c
>> @@ -70,7 +70,7 @@ void __init init_cpu_to_node(void)
>>   
>>       for ( i = 0; i < nr_cpu_ids; i++ )
>>       {
>> -        u32 apicid = x86_cpu_to_apicid[i];
>> +        u32 apicid = cpu_physical_id(i);
>>           if ( apicid == BAD_APICID )
>>               continue;
>>           node = apicid < MAX_LOCAL_APIC ? apicid_to_node[apicid] : NUMA_NO_NODE;
> We're in the process of phasing out u32 and friends, favoring uint32_t.
> Would be nice if in code being touched anyway (i.e. not just here) the
> conversion would be done right away. Then again fixed-width types are
> preferably avoided where not really needed (see ./CODING_STYLE), so
> quite likely it actually wants to be unsigned int here.
>
> Furthermore our style demands that declaration(s) and statement(s) are
> separated by a blank line. Inserting the missing one in cases like the
> one here would be very desirable as well.
Good to know, thanks.
> Jan
Best regards,

-- 
Krystian Hebel
Firmware Engineer
https://3mdeb.com  | @3mdeb_com

--------------8naBNj30Wkav5P0Z3FbiTDV6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  
    
  
  
    


    

    
On 7.02.2024 17:28, Jan Beulich wrote:

    

    

      
On 14.11.2023 18:49, Krystian Hebel wrote:


      

        
--- a/xen/arch/x86/apic.c
+++ b/xen/arch/x86/apic.c
@@ -950,7 +950,7 @@ __next:
      */
     if (boot_cpu_physical_apicid == -1U)
         boot_cpu_physical_apicid = get_apic_id();
-    x86_cpu_to_apicid[0] = get_apic_id();
+    cpu_physical_id(0) = get_apic_id();


      

      
While personally I don't mind as much, I expect Andrew would not like
this: Something that looks like a function call on the lhs is against
what normal language structure would be.

    

    This made me cringe as well, but I've seen something like this used
    in

    other places (per_cpu() mostly) so I thought it was OK. I can change
    it.

    

      

      

        
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1615,7 +1615,7 @@ long do_vcpu_op(int cmd, unsigned int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg)
             break;
 
         cpu_id.phys_id =
-            (uint64_t)x86_cpu_to_apicid[v->vcpu_id] |
+            (uint64_t)cpu_physical_id(v->vcpu_id) |
             ((uint64_t)acpi_get_processor_id(v->vcpu_id) << 32);


      

      
While the cast on the 2nd line is necessary, the one on the 2st isn't
and would be nice to be dropped while touching the line anyway.

    

    Ack

    

      



      

        
--- a/xen/arch/x86/numa.c
+++ b/xen/arch/x86/numa.c
@@ -70,7 +70,7 @@ void __init init_cpu_to_node(void)
 
     for ( i = 0; i < nr_cpu_ids; i++ )
     {
-        u32 apicid = x86_cpu_to_apicid[i];
+        u32 apicid = cpu_physical_id(i);
         if ( apicid == BAD_APICID )
             continue;
         node = apicid < MAX_LOCAL_APIC ? apicid_to_node[apicid] : NUMA_NO_NODE;


      

      
We're in the process of phasing out u32 and friends, favoring uint32_t.
Would be nice if in code being touched anyway (i.e. not just here) the
conversion would be done right away. Then again fixed-width types are
preferably avoided where not really needed (see ./CODING_STYLE), so
quite likely it actually wants to be unsigned int here.

Furthermore our style demands that declaration(s) and statement(s) are
separated by a blank line. Inserting the missing one in cases like the
one here would be very desirable as well.

    

    Good to know, thanks.

    

      
Jan


    

    Best regards,

    
-- 
Krystian Hebel
Firmware Engineer
https://3mdeb.com | @3mdeb_com

  


--------------8naBNj30Wkav5P0Z3FbiTDV6--


From xen-devel-bounces@lists.xenproject.org Tue Mar 12 15:22:54 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Mar 2024 15:22:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.691910.1078481 (Exim 4.92)
	(envelope-from )
	id 1rk3xq-0005l3-L6; Tue, 12 Mar 2024 15:22:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 691910.1078481; Tue, 12 Mar 2024 15:22:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rk3xq-0005kw-IT; Tue, 12 Mar 2024 15:22:50 +0000
Received: by outflank-mailman (input) for mailman id 691910;
 Tue, 12 Mar 2024 15:22:50 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rk3xq-0005kq-6v
 for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 15:22:50 +0000
Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com
 [2a00:1450:4864:20::236])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 62049562-e084-11ee-a1ee-f123f15fe8a2;
 Tue, 12 Mar 2024 16:22:48 +0100 (CET)
Received: by mail-lj1-x236.google.com with SMTP id
 38308e7fff4ca-2d2ab9c5e83so567781fa.2
 for ; Tue, 12 Mar 2024 08:22:48 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 h8-20020a0564020e0800b005653c441a20sm3568497edh.34.2024.03.12.08.22.47
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 12 Mar 2024 08:22:47 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 62049562-e084-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710256967; x=1710861767; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:subject:from:user-agent:mime-version:date
         :message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=eVS8NZ9xD+RsOm+qUk/upY9IPwTqTT6N6KGsJzYt9PM=;
        b=W+0OHNkdTf+ztfwSMDouznIS0hnk8Rfmcj3qreAYCI7nW+WKnjpbCCo7Jec8soGwRf
         zrpUGhPIgdoLothD0pVeEgcO1Cp+7qJ0CJhFr8eG9OrtT/rKOugteFc6UDehLVrha+Lc
         QbbGtAh3AfqhSVar5MM0j7zf21Q80kahPd3imWqLC9sB4EUnHPSoBZVX85szHZy+tlCb
         T+9kXw7h+tMel2oDrkHj8vPl7GnmcE8LoRuouEDMA6OLuhZoyDQb8yNDVniWi6GnvdOZ
         bSlGDF3qdFIyd4Nc8ay9lhM9zyLG9kj0OkjsH8zmw9e4BPxESLCbZQukTBm03Yx5yYxg
         7/ww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710256967; x=1710861767;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:subject:from:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=eVS8NZ9xD+RsOm+qUk/upY9IPwTqTT6N6KGsJzYt9PM=;
        b=Us5uc5ZCizgP9xLMV2QvwwdXKncreqCfXFFiTeEuCnLrfOuI5cBa8TB+unCyjM1Edi
         xpLsRdgM5a+15CTgENB1qcnNvqcwX+8TtmbNmcdgJWtengf6QIO9zl/JRfODxUQFdGus
         RgxQSo5+Jrddx49rttS1JPavtXJ4RconjpnsiURalS9fmokkdCKZmC1OG6dVOCTPQJ6+
         s54COM3WDJZq9/jrhPUMiu/qY+jeXminjy5an2zZDH+ejuSOIBIr+d5kE0n5qwyFjEED
         Mh9t46NGGK1NE2oG4zCC8QNgmCc+bXTGSj5/S7dKJcIvEGfkl4EAG5JkE2fj77S+/AQf
         6jrA==
X-Gm-Message-State: AOJu0YyuvklvNW08ntQvRrGQD5W/niOSv7qhzOq0iBvr7cXBAD+veWA2
	8Xf8bM8Di9QHXxo+oqjHos3YFWqfcTUhYp6Y1AEsIrwZOwkTvukcEFmDrjqSqdsSwhZAAxNW7T4
	=
X-Google-Smtp-Source: AGHT+IHAxhdifFTOqPCDZrEdwk2ND3FsHuBNsNyjx64p69BDCtH3I0dVYmK6ejEipOh2GgbMKU4TfQ==
X-Received: by 2002:a2e:be9c:0:b0:2d4:522e:62f3 with SMTP id a28-20020a2ebe9c000000b002d4522e62f3mr2434688ljr.44.1710256967547;
        Tue, 12 Mar 2024 08:22:47 -0700 (PDT)
Message-ID: <740404f0-3da9-4ae5-b4a5-b24cb2907e7d@suse.com>
Date: Tue, 12 Mar 2024 16:22:46 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Jan Beulich 
Subject: [PATCH v3] x86/PoD: tie together P2M update and increment of entry
 count
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper , Wei Liu ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 George Dunlap 
References: 
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

When not holding the PoD lock across the entire region covering P2M
update and stats update, the entry count - if to be incorrect at all -
should indicate too large a value in preference to a too small one, to
avoid functions bailing early when they find the count is zero. However,
instead of moving the increment ahead (and adjust back upon failure),
extend the PoD-locked region.

Fixes: 99af3cd40b6e ("x86/mm: Rework locking in the PoD layer")
Signed-off-by: Jan Beulich 
---
The locked region could be shrunk again, by having multiple unlock
calls. But I think both ioreq_request_mapcache_invalidate() and
domain_crash() are fair enough to call with the lock still held?
---
v3: Extend locked region instead. Add Fixes: tag.
v2: Add comments.

--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -1348,16 +1348,22 @@ mark_populate_on_demand(struct domain *d
         }
     }
 
+    /*
+     * P2M update and stats increment need to collectively be under PoD lock,
+     * to prevent code elsewhere observing PoD entry count being zero despite
+     * there actually still being PoD entries (created by the p2m_set_entry()
+     * invocation below).
+     */
+    pod_lock(p2m);
+
     /* Now, actually do the two-way mapping */
     rc = p2m_set_entry(p2m, gfn, INVALID_MFN, order,
                        p2m_populate_on_demand, p2m->default_access);
     if ( rc == 0 )
     {
-        pod_lock(p2m);
         p2m->pod.entry_count += 1UL << order;
         p2m->pod.entry_count -= pod_count;
         BUG_ON(p2m->pod.entry_count < 0);
-        pod_unlock(p2m);
 
         ioreq_request_mapcache_invalidate(d);
     }
@@ -1373,6 +1379,8 @@ mark_populate_on_demand(struct domain *d
         domain_crash(d);
     }
 
+    pod_unlock(p2m);
+
 out:
     gfn_unlock(p2m, gfn, order);
 


From xen-devel-bounces@lists.xenproject.org Tue Mar 12 15:29:49 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Mar 2024 15:29:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.691914.1078490 (Exim 4.92)
	(envelope-from )
	id 1rk44W-0006YA-9l; Tue, 12 Mar 2024 15:29:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 691914.1078490; Tue, 12 Mar 2024 15:29:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rk44W-0006Y3-7E; Tue, 12 Mar 2024 15:29:44 +0000
Received: by outflank-mailman (input) for mailman id 691914;
 Tue, 12 Mar 2024 15:29:43 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rk44V-0006Xx-3Y
 for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 15:29:43 +0000
Received: from 6.mo560.mail-out.ovh.net (6.mo560.mail-out.ovh.net
 [87.98.165.38]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 586a62f1-e085-11ee-afdd-a90da7624cb6;
 Tue, 12 Mar 2024 16:29:41 +0100 (CET)
Received: from director1.ghost.mail-out.ovh.net (unknown [10.108.2.160])
 by mo560.mail-out.ovh.net (Postfix) with ESMTP id 4TvHd101YSz1MM3
 for ; Tue, 12 Mar 2024 15:29:40 +0000 (UTC)
Received: from ghost-submission-6684bf9d7b-jtmlx (unknown [10.111.174.132])
 by director1.ghost.mail-out.ovh.net (Postfix) with ESMTPS id AABA91FDEF;
 Tue, 12 Mar 2024 15:29:39 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.101])
 by ghost-submission-6684bf9d7b-jtmlx with ESMTPSA
 id cyWVIuN08GV4KwEAiIGgIA
 (envelope-from ); Tue, 12 Mar 2024 15:29:39 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 586a62f1-e085-11ee-afdd-a90da7624cb6
Authentication-Results:garm.ovh; auth=pass (GARM-101G0040df681a7-86c7-4fd3-8bfb-ef3eef196769,
                    0B6B113C544506A41C6EB031E0F94F2E66B6AEBC) smtp.auth=krystian.hebel@3mdeb.com
X-OVh-ClientIp:217.171.61.25
Content-Type: multipart/alternative;
 boundary="------------juIWivVt0CzXpc1PTNT10FKB"
Message-ID: 
Date: Tue, 12 Mar 2024 16:29:38 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 3/9] x86/smp: drop x86_cpu_to_apicid, use
 cpu_data[cpu].apicid instead
Content-Language: en-US
To: Jan Beulich , Julien Grall 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org, Wei Liu 
References: 
 <8121d9b472b305be751158aa3af3fed98ff0572e.1699982111.git.krystian.hebel@3mdeb.com>
 
 <24dc1f13-3add-4b5f-9e2d-a18286b691eb@suse.com>
From: Krystian Hebel 
In-Reply-To: <24dc1f13-3add-4b5f-9e2d-a18286b691eb@suse.com>
X-Ovh-Tracer-Id: 8422857205134043504
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedvledrjeefgdejiecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpegtkfffgggfuffvvehfhfgjsegrtderredtvdejnecuhfhrohhmpefmrhihshhtihgrnhcujfgvsggvlhcuoehkrhihshhtihgrnhdrhhgvsggvlhesfehmuggvsgdrtghomheqnecuggftrfgrthhtvghrnhepkeevfeevudffvdelfeeuudegtdeggfegheegudegleefiedtffekgfeiheejjeegnecuffhomhgrihhnpeigkeeipgeigedrshgspdefmhguvggsrdgtohhmnecukfhppeduvdejrddtrddtrddupddvudejrddujedurdeiuddrvdehpdefjedrheelrddugedvrddutddunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepuddvjedrtddrtddruddpmhgrihhlfhhrohhmpehkrhihshhtihgrnhdrhhgvsggvlhesfehmuggvsgdrtghomhdpnhgspghrtghpthhtohepuddprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdpoffvtefjohhsthepmhhoheeitddpmhhouggvpehsmhhtphhouhht

This is a multi-part message in MIME format.
--------------juIWivVt0CzXpc1PTNT10FKB
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

On 7.02.2024 17:41, Jan Beulich wrote:
> On 02.02.2024 19:11, Julien Grall wrote:
>> Hi,
>>
>> On 14/11/2023 17:50, Krystian Hebel wrote:
>>> Both fields held the same data.
>>>
>>> Signed-off-by: Krystian Hebel
>>> ---
>>>    xen/arch/x86/boot/x86_64.S           |  8 +++++---
>>>    xen/arch/x86/include/asm/asm_defns.h |  2 +-
>>>    xen/arch/x86/include/asm/processor.h |  2 ++
>>>    xen/arch/x86/include/asm/smp.h       |  4 ----
>>>    xen/arch/x86/numa.c                  | 15 +++++++--------
>>>    xen/arch/x86/smpboot.c               |  8 ++++----
>>>    xen/arch/x86/x86_64/asm-offsets.c    |  4 +++-
>>>    7 files changed, 22 insertions(+), 21 deletions(-)
>>>
>>> diff --git a/xen/arch/x86/boot/x86_64.S b/xen/arch/x86/boot/x86_64.S
>>> index b85b47b5c1a0..195550b5c0ea 100644
>>> --- a/xen/arch/x86/boot/x86_64.S
>>> +++ b/xen/arch/x86/boot/x86_64.S
>>> @@ -20,15 +20,17 @@ ENTRY(__high_start)
>>>            jz      .L_stack_set
>>>    
>>>            /* APs only: get stack base from APIC ID saved in %esp. */
>>> -        mov     $-1, %rax
>>> -        lea     x86_cpu_to_apicid(%rip), %rcx
>>> +        mov     $0, %rax
>>> +        lea     cpu_data(%rip), %rcx
>>> +        /* cpu_data[0] is BSP, skip it. */
>>>    1:
>>>            add     $1, %rax
>>> +        add     $CPUINFO_X86_sizeof, %rcx
>>>            cmp     $NR_CPUS, %eax
>>>            jb      2f
>>>            hlt
>>>    2:
>>> -        cmp     %esp, (%rcx, %rax, 4)
>>> +        cmp     %esp, CPUINFO_X86_apicid(%rcx)
>>>            jne     1b
>>>    
>>>            /* %eax is now Xen CPU index. */
>> As mentioned in an earlier patch, I think you want to re-order the
>> patches. This will avoid to modify twice the same code within the same
>> series (it is best to avoid if you can).
> I second this request. Even more so that there's an unexplained move
> from starting at $-1 to starting at $0 (in which case you really want
> to use xor, not mov).
Will do. This may even result in squashing some patches together.
>>> --- a/xen/arch/x86/numa.c
>>> +++ b/xen/arch/x86/numa.c
>>> @@ -54,14 +54,13 @@ bool __init arch_numa_unavailable(void)
>>>    /*
>>>     * Setup early cpu_to_node.
>>>     *
>>> - * Populate cpu_to_node[] only if x86_cpu_to_apicid[],
>>> - * and apicid_to_node[] tables have valid entries for a CPU.
>>> - * This means we skip cpu_to_node[] initialisation for NUMA
>>> - * emulation and faking node case (when running a kernel compiled
>>> - * for NUMA on a non NUMA box), which is OK as cpu_to_node[]
>>> - * is already initialized in a round robin manner at numa_init_array,
>>> - * prior to this call, and this initialization is good enough
>>> - * for the fake NUMA cases.
>>> + * Populate cpu_to_node[] only if cpu_data[], and apicid_to_node[]
> You mean cpu_physical_id() here, and then this change wants doing when
> switching to that, imo.
You mean s/cpu_data[]/cpu_physical_id()/ or something else?
>>> + * tables have valid entries for a CPU. This means we skip
>>> + * cpu_to_node[] initialisation for NUMA emulation and faking node
>>> + * case (when running a kernel compiled for NUMA on a non NUMA box),
>>> + * which is OK as cpu_to_node[] is already initialized in a round
>>> + * robin manner at numa_init_array, prior to this call, and this
>>> + * initialization is good enough for the fake NUMA cases.
>>>     */
> Also if you're already re-wrapping this comment, please make better use
> of line width.
>
>>> --- a/xen/arch/x86/x86_64/asm-offsets.c
>>> +++ b/xen/arch/x86/x86_64/asm-offsets.c
>>> @@ -159,7 +159,9 @@ void __dummy__(void)
>>>        OFFSET(IRQSTAT_softirq_pending, irq_cpustat_t, __softirq_pending);
>>>        BLANK();
>>>    
>>> -    OFFSET(CPUINFO_features, struct cpuinfo_x86, x86_capability);
>>> +    OFFSET(CPUINFO_X86_features, struct cpuinfo_x86, x86_capability);
>> The rename seems to be unrelated to this patch. Can you clarify?
> I agree some renaming wants doing, but separately. That's because we
> use CPUINFO_ as a prefix for two entirely different structure's offsets
> right now. I'm not convinced of CPUINFO_X86_ as the new prefix though:
> Uses are against cpu_data[], so CPUDATA_ may be better. Might be good
> if Andrew and/or Roger could voice their view.
Yes, this was because after adding APIC ID to this structure I tried to use
CPUINFO_sizeof in the assembly, and bad things happened.
>
> Jan
>
>>> +    OFFSET(CPUINFO_X86_apicid, struct cpuinfo_x86, apicid);
>>> +    DEFINE(CPUINFO_X86_sizeof, sizeof(struct cpuinfo_x86));
>>>        BLANK();
>>>    
>>>        OFFSET(MB_flags, multiboot_info_t, flags);
>> Cheers,
>>
Best regards,

-- 
Krystian Hebel
Firmware Engineer
https://3mdeb.com  | @3mdeb_com

--------------juIWivVt0CzXpc1PTNT10FKB
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  
    
  
  
    
Hi,

    

    
On 7.02.2024 17:41, Jan Beulich wrote:

    

    

      
On 02.02.2024 19:11, Julien Grall wrote:


      

        
Hi,

On 14/11/2023 17:50, Krystian Hebel wrote:


        

          
Both fields held the same data.

Signed-off-by: Krystian Hebel <krystian.hebel@3mdeb.com>
---
  xen/arch/x86/boot/x86_64.S           |  8 +++++---
  xen/arch/x86/include/asm/asm_defns.h |  2 +-
  xen/arch/x86/include/asm/processor.h |  2 ++
  xen/arch/x86/include/asm/smp.h       |  4 ----
  xen/arch/x86/numa.c                  | 15 +++++++--------
  xen/arch/x86/smpboot.c               |  8 ++++----
  xen/arch/x86/x86_64/asm-offsets.c    |  4 +++-
  7 files changed, 22 insertions(+), 21 deletions(-)

diff --git a/xen/arch/x86/boot/x86_64.S b/xen/arch/x86/boot/x86_64.S
index b85b47b5c1a0..195550b5c0ea 100644
--- a/xen/arch/x86/boot/x86_64.S
+++ b/xen/arch/x86/boot/x86_64.S
@@ -20,15 +20,17 @@ ENTRY(__high_start)
          jz      .L_stack_set
  
          /* APs only: get stack base from APIC ID saved in %esp. */
-        mov     $-1, %rax
-        lea     x86_cpu_to_apicid(%rip), %rcx
+        mov     $0, %rax
+        lea     cpu_data(%rip), %rcx
+        /* cpu_data[0] is BSP, skip it. */
  1:
          add     $1, %rax
+        add     $CPUINFO_X86_sizeof, %rcx
          cmp     $NR_CPUS, %eax
          jb      2f
          hlt
  2:
-        cmp     %esp, (%rcx, %rax, 4)
+        cmp     %esp, CPUINFO_X86_apicid(%rcx)
          jne     1b
  
          /* %eax is now Xen CPU index. */


        

        
As mentioned in an earlier patch, I think you want to re-order the 
patches. This will avoid to modify twice the same code within the same 
series (it is best to avoid if you can).


      

      
I second this request. Even more so that there's an unexplained move
from starting at $-1 to starting at $0 (in which case you really want
to use xor, not mov).

    

    Will do. This may even result in squashing some patches together.


    

      

        

          
--- a/xen/arch/x86/numa.c
+++ b/xen/arch/x86/numa.c
@@ -54,14 +54,13 @@ bool __init arch_numa_unavailable(void)
  /*
   * Setup early cpu_to_node.
   *
- * Populate cpu_to_node[] only if x86_cpu_to_apicid[],
- * and apicid_to_node[] tables have valid entries for a CPU.
- * This means we skip cpu_to_node[] initialisation for NUMA
- * emulation and faking node case (when running a kernel compiled
- * for NUMA on a non NUMA box), which is OK as cpu_to_node[]
- * is already initialized in a round robin manner at numa_init_array,
- * prior to this call, and this initialization is good enough
- * for the fake NUMA cases.
+ * Populate cpu_to_node[] only if cpu_data[], and apicid_to_node[]


        

      

      
You mean cpu_physical_id() here, and then this change wants doing when
switching to that, imo.

    

    You mean s/cpu_data[]/cpu_physical_id()/ or something else?

    

      

      

        

          
+ * tables have valid entries for a CPU. This means we skip
+ * cpu_to_node[] initialisation for NUMA emulation and faking node
+ * case (when running a kernel compiled for NUMA on a non NUMA box),
+ * which is OK as cpu_to_node[] is already initialized in a round
+ * robin manner at numa_init_array, prior to this call, and this
+ * initialization is good enough for the fake NUMA cases.
   */


        

      

      
Also if you're already re-wrapping this comment, please make better use
of line width.



      

        

          
--- a/xen/arch/x86/x86_64/asm-offsets.c
+++ b/xen/arch/x86/x86_64/asm-offsets.c
@@ -159,7 +159,9 @@ void __dummy__(void)
      OFFSET(IRQSTAT_softirq_pending, irq_cpustat_t, __softirq_pending);
      BLANK();
  
-    OFFSET(CPUINFO_features, struct cpuinfo_x86, x86_capability);
+    OFFSET(CPUINFO_X86_features, struct cpuinfo_x86, x86_capability);


        

        
The rename seems to be unrelated to this patch. Can you clarify?


      

      
I agree some renaming wants doing, but separately. That's because we
use CPUINFO_ as a prefix for two entirely different structure's offsets
right now. I'm not convinced of CPUINFO_X86_ as the new prefix though:
Uses are against cpu_data[], so CPUDATA_ may be better. Might be good
if Andrew and/or Roger could voice their view.

    

    Yes, this was because after adding APIC ID to this structure I tried
    to use

    CPUINFO_sizeof in the assembly, and bad things happened.

    

      

Jan



      

        

          
+    OFFSET(CPUINFO_X86_apicid, struct cpuinfo_x86, apicid);
+    DEFINE(CPUINFO_X86_sizeof, sizeof(struct cpuinfo_x86));
      BLANK();
  
      OFFSET(MB_flags, multiboot_info_t, flags);


        

        
Cheers,



      

    

    Best regards,

    
-- 
Krystian Hebel
Firmware Engineer
https://3mdeb.com | @3mdeb_com

  


--------------juIWivVt0CzXpc1PTNT10FKB--


From xen-devel-bounces@lists.xenproject.org Tue Mar 12 15:35:54 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Mar 2024 15:35:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.691917.1078501 (Exim 4.92)
	(envelope-from )
	id 1rk4AO-0008Kv-US; Tue, 12 Mar 2024 15:35:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 691917.1078501; Tue, 12 Mar 2024 15:35:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rk4AO-0008Ko-R2; Tue, 12 Mar 2024 15:35:48 +0000
Received: by outflank-mailman (input) for mailman id 691917;
 Tue, 12 Mar 2024 15:35:48 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rk4AN-0008Ki-WD
 for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 15:35:48 +0000
Received: from 9.mo581.mail-out.ovh.net (9.mo581.mail-out.ovh.net
 [46.105.60.248]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 32304e37-e086-11ee-afdd-a90da7624cb6;
 Tue, 12 Mar 2024 16:35:46 +0100 (CET)
Received: from director5.ghost.mail-out.ovh.net (unknown [10.109.176.37])
 by mo581.mail-out.ovh.net (Postfix) with ESMTP id 4TvHm23SNgz1DHG
 for ; Tue, 12 Mar 2024 15:35:46 +0000 (UTC)
Received: from ghost-submission-6684bf9d7b-ksdnp (unknown [10.110.178.147])
 by director5.ghost.mail-out.ovh.net (Postfix) with ESMTPS id CE31A1FEA4;
 Tue, 12 Mar 2024 15:35:45 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.99])
 by ghost-submission-6684bf9d7b-ksdnp with ESMTPSA
 id pqqIKFF28GUh5AAA91y3uA
 (envelope-from ); Tue, 12 Mar 2024 15:35:45 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 32304e37-e086-11ee-afdd-a90da7624cb6
Authentication-Results:garm.ovh; auth=pass (GARM-99G0039d1a54e5-0c14-4bd0-8947-d484040bc86f,
                    0B6B113C544506A41C6EB031E0F94F2E66B6AEBC) smtp.auth=krystian.hebel@3mdeb.com
X-OVh-ClientIp:217.171.61.25
Message-ID: 
Date: Tue, 12 Mar 2024 16:35:45 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 3/9] x86/smp: drop x86_cpu_to_apicid, use
 cpu_data[cpu].apicid instead
Content-Language: en-US
To: Jan Beulich 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org, Wei Liu 
References: 
 <8121d9b472b305be751158aa3af3fed98ff0572e.1699982111.git.krystian.hebel@3mdeb.com>
 <0d776dcc-af14-436a-bf8b-9bfb39b787b8@suse.com>
From: Krystian Hebel 
In-Reply-To: <0d776dcc-af14-436a-bf8b-9bfb39b787b8@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Ovh-Tracer-Id: 8525877045417519472
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedvledrjeefgdejkecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefkffggfgfuvfevfhfhjggtgfesthejredttddvjeenucfhrhhomhepmfhrhihsthhirghnucfjvggsvghluceokhhrhihsthhirghnrdhhvggsvghlseefmhguvggsrdgtohhmqeenucggtffrrghtthgvrhhnpeejuedvffefvdeuvdeffeduuddtjeetgeefffdugfdvkeehtedutefghfdtteejieenucffohhmrghinhepfehmuggvsgdrtghomhenucfkphepuddvjedrtddrtddruddpvddujedrudejuddriedurddvhedpfeejrdehledrudegvddrleelnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepuddvjedrtddrtddruddpmhgrihhlfhhrohhmpehkrhihshhtihgrnhdrhhgvsggvlhesfehmuggvsgdrtghomhdpnhgspghrtghpthhtohepuddprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdpoffvtefjohhsthepmhhoheekuddpmhhouggvpehsmhhtphhouhht


On 8.02.2024 08:29, Jan Beulich wrote:
> On 14.11.2023 18:50, Krystian Hebel wrote:
>> Both fields held the same data.
> Supposedly the same data only. They come from different origins, and you're
> hiding this quite well by leaving all sites in place where the field is
> written. Both items are also used for entirely separate purposes. So you
> need to
> - explain why both sources of information necessarily provide the same
>    data,
> - especially if there's remaining concern from the above explanation that
>    the two values might end up different in corner cases (running
>    virtualized ourselves comes to mind as a possible example), explain why
>    nevertheless it is fine (risk free) to use the consolidated item for
>    all of the originally separate purposes,
> - either explain or do away with the multiple places setting this single
>    remaining field.
I missed those writes, thanks for pointing this out. I'll have to take
a closer look before deciding what to do with this.
>
>> --- a/xen/arch/x86/smpboot.c
>> +++ b/xen/arch/x86/smpboot.c
>> @@ -61,10 +61,8 @@ unsigned int __read_mostly nr_sockets;
>>   cpumask_t **__read_mostly socket_cpumask;
>>   static cpumask_t *secondary_socket_cpumask;
>>   
>> -struct cpuinfo_x86 cpu_data[NR_CPUS];
>> -
>> -u32 x86_cpu_to_apicid[NR_CPUS] __read_mostly =
>> -	{ [0 ... NR_CPUS-1] = BAD_APICID };
>> +struct cpuinfo_x86 cpu_data[NR_CPUS] =
>> +        { [0 ... NR_CPUS-1] .apicid = BAD_APICID };
> Nit: Stray blank after closing square bracket.
>
> Jan

-- 
Krystian Hebel
Firmware Engineer
https://3mdeb.com | @3mdeb_com



From xen-devel-bounces@lists.xenproject.org Tue Mar 12 15:41:09 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Mar 2024 15:41:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.691919.1078510 (Exim 4.92)
	(envelope-from )
	id 1rk4FS-0001mX-F7; Tue, 12 Mar 2024 15:41:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 691919.1078510; Tue, 12 Mar 2024 15:41:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rk4FS-0001mQ-CZ; Tue, 12 Mar 2024 15:41:02 +0000
Received: by outflank-mailman (input) for mailman id 691919;
 Tue, 12 Mar 2024 15:41:00 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rk4FQ-0001mK-NU
 for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 15:41:00 +0000
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com
 [2a00:1450:4864:20::52e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id eca16ec0-e086-11ee-afdd-a90da7624cb6;
 Tue, 12 Mar 2024 16:40:59 +0100 (CET)
Received: by mail-ed1-x52e.google.com with SMTP id
 4fb4d7f45d1cf-56840d872aeso4257625a12.0
 for ; Tue, 12 Mar 2024 08:40:59 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 cq15-20020a056402220f00b0056761c83bdesm4068487edb.93.2024.03.12.08.40.58
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 12 Mar 2024 08:40:58 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: eca16ec0-e086-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710258059; x=1710862859; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=NSMa9ltAFpDnZugHD70b4ResjpouQ80j9uB/02gDj7A=;
        b=QklFcbuXEwbXCTK074qsKE8T1fw7yUbgMYzpFGgBA7cXcU/Zz2mvB+oKJQIdoU2TqI
         UHIGJy7n7WVl8i2r707vObySgc+9Er6Ot6UmbMV2FgcEvog/WlBeUi78Mpy/WaCihRvT
         fhcHYNH8q9zIfaP8GPjdW4Ov/68fqxOE7s7OzLV6v+g4LfSj/TXWnoUkyxV5Vb0ZI2SV
         QY8b1gbzkZXKTy/m+lBHUbsGpvVfMrYful5wT56KFKiytnmDXz+W83/CPfusv724IxbS
         oGQgHBkvn7O2GYX9kpnzr4etMNw1ig1WYu2ZflYLFpwkDn/cFiGcwK1Q3NU+KcSuG9W4
         g5SA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710258059; x=1710862859;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=NSMa9ltAFpDnZugHD70b4ResjpouQ80j9uB/02gDj7A=;
        b=CQ0cAPqLDgjRU72UVymPtnWkWd9Kpzkhtk+2bSMuMOKP7bAO46/7BOvGFIFYqoWAGt
         hd7Zu2TF83332L/+19jjwyKx6uyimw2LtKmYI+Vt6wfVlAN0yMbEuJ0ngEvublC3hCAJ
         oefD5fx4ksZUOVAw6nnWX7UVyBQ/FqnCQ6AdpgC+u0VwGFTk1P0c08PoAdo9bnwu8e+7
         GlUQwo5bQ57W2VBZo+vQ3sjoOIGYZpI7sH+D/g/UBQ6J7zstoADpLEmsiL4M/M66RKvK
         Wp4lgaWEh957HxxZ6uEfvqUD2f4yRpdXIwe/gQ3ZjVlaY6tfkpK9TElwbNoffkbYrWLI
         rxOw==
X-Forwarded-Encrypted: i=1; AJvYcCXjvTHLo23q96mPMUW4lGZc5Zc+GOdskhvbEZubC/wHE4BNlxit0Q8+UWy1KgaJ7uK3aUQDH5XaDqhWUC+HcqqA1Z3Ozjp6iAq/iIyRHlI=
X-Gm-Message-State: AOJu0YyXrTIxJUZyW/iX4rA5dsLcJo1ptxqV7peZ5RBpcKMCPb3oaFFU
	8gJtGNeqptVPlPgF6B7uduy1yC0eygK9bTY6/ebjZyH6HNsbO736ufpiLyJt/w==
X-Google-Smtp-Source: AGHT+IGZ0d4/PgOIuxE27huHUmCLVBB9WAt7XpYvfWjxXmkX6H6yB7t/aKGxo24CAhQNRwG4GN8D4A==
X-Received: by 2002:a50:999e:0:b0:567:737f:e91f with SMTP id m30-20020a50999e000000b00567737fe91fmr6808805edb.27.1710258059161;
        Tue, 12 Mar 2024 08:40:59 -0700 (PDT)
Message-ID: 
Date: Tue, 12 Mar 2024 16:40:57 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 1/9] x86/boot: choose AP stack based on APIC ID
Content-Language: en-US
To: Krystian Hebel 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org, Wei Liu 
References: 
 <0e7dd957b6f26fa7b752bdce1ef6ebe97c825903.1699982111.git.krystian.hebel@3mdeb.com>
 
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 12.03.2024 16:11, Krystian Hebel wrote:
> On 7.02.2024 17:11, Jan Beulich wrote:
>> On 14.11.2023 18:49, Krystian Hebel wrote:
>>> --- a/xen/arch/x86/boot/trampoline.S
>>> +++ b/xen/arch/x86/boot/trampoline.S
>>> +        /* Not x2APIC, read from MMIO */
>>> +        mov     0xfee00020, %esp
>> Please don't open-code existing constants (APIC_ID here and below,
>> APIC_DEFAULT_PHYS_BASE just here, and ...
>>
>>> +        shr     $24, %esp
>> ... a to-be-introduced constant here (for {G,S}ET_xAPIC_ID() to use as
>> well then). This is the only way of being able to easily identify all
>> pieces of code accessing the same piece of hardware.
> 
> Yes, this was also caught in review done by Qubes OS team.
> 
> New constant and {G,S}ET_xAPIC_ID() should be in separate patch, I presume?

Preferably, yes.

>>> --- a/xen/arch/x86/boot/x86_64.S
>>> +++ b/xen/arch/x86/boot/x86_64.S
>>> @@ -15,7 +15,33 @@ ENTRY(__high_start)
>>>           mov     $XEN_MINIMAL_CR4,%rcx
>>>           mov     %rcx,%cr4
>>>   
>>> -        mov     stack_start(%rip),%rsp
>>> +        test    %ebx,%ebx
>> Nit (style): Elsewhere you have blanks after the commas, just here
>> (and once again near the end of the hunk) you don't.
> Is either style preferred?This file has both.

Conversion takes time, so in new code we aim at having those blanks.
Over time we hope to have them nearly everywhere, at which point it
may make sense to to a final cleanup sweep.

>>> --- a/xen/arch/x86/setup.c
>>> +++ b/xen/arch/x86/setup.c
>>> @@ -1951,6 +1951,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>>>        */
>>>       if ( !pv_shim )
>>>       {
>>> +        /* Separate loop to make parallel AP bringup possible. */
>>>           for_each_present_cpu ( i )
>>>           {
>>>               /* Set up cpu_to_node[]. */
>>> @@ -1958,6 +1959,12 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>>>               /* Set up node_to_cpumask based on cpu_to_node[]. */
>>>               numa_add_cpu(i);
>>>   
>>> +            if ( stack_base[i] == NULL )
>>> +                stack_base[i] = cpu_alloc_stack(i);
>>> +        }
>> Imo this wants accompanying by removal of the allocation in
>> cpu_smpboot_alloc(). Which would then make more visible that there's
>> error checking there, but not here (I realize there effectively is
>> error checking in assembly code, but that'll end in HLT with no
>> useful indication of what the problem is). Provided, as Julien has
>> pointed out, that the change is necessary in the first place.
> 
> The allocation in cpu_smpboot_alloc() was left for hot-plug. This loops
> over present CPUs, not possible ones.

Ah, right. Yet better error checking / reporting is going to be needed
anyway.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Mar 12 15:42:56 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Mar 2024 15:42:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.691922.1078520 (Exim 4.92)
	(envelope-from )
	id 1rk4HH-0002Mk-TZ; Tue, 12 Mar 2024 15:42:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 691922.1078520; Tue, 12 Mar 2024 15:42:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rk4HH-0002Md-Qs; Tue, 12 Mar 2024 15:42:55 +0000
Received: by outflank-mailman (input) for mailman id 691922;
 Tue, 12 Mar 2024 15:42:54 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rk4HG-0002MX-P0
 for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 15:42:54 +0000
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com
 [2a00:1450:4864:20::52a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 30126b19-e087-11ee-a1ee-f123f15fe8a2;
 Tue, 12 Mar 2024 16:42:52 +0100 (CET)
Received: by mail-ed1-x52a.google.com with SMTP id
 4fb4d7f45d1cf-563c403719cso6960036a12.2
 for ; Tue, 12 Mar 2024 08:42:52 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 e3-20020a170906314300b00a4558314ea0sm4025767eje.15.2024.03.12.08.42.51
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 12 Mar 2024 08:42:52 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 30126b19-e087-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710258172; x=1710862972; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=3bmYaFDpLFhm5Cgf4OSH5gVC6zXWCPjmzWGkAA68ISs=;
        b=JfLv+MkKN/ZlPc/u74aTrP/LbNc8axN5joB8f3QqONsWbEx9Pq5EXIRJojT5PzeuP/
         sq1AKfWboyzD8n9EfGCmdTwZ5QyJ9Ii7ElHMITbeqnNMZ4MTAiwhrs9/XbnL5BD2PA72
         VDG25y+IshyBtuvCNLO1afByXAtyzgkWFfxL/LiyMfpcB79jbHwQ51gP1Pv4WaGi1J8j
         TWJwVVtN8U4SGgY23GW5WCI+lCr3/ufEimWpUGlKKls4cuCkaosb7DkVrRCkQFXjvMBA
         /H9uFCKZW46LyaXEsLpk9HxDKkHtw5PcNqIf8A7WaGXBknVPJxY8VLAtH7EDQl5NAz++
         FhOQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710258172; x=1710862972;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=3bmYaFDpLFhm5Cgf4OSH5gVC6zXWCPjmzWGkAA68ISs=;
        b=sq97VsF2e98UlWvUPnH+xiR3OsF1B1JR2v9l+25q+6ePwK75mvBxEkGm9ncvNPCbJ0
         Lr9vQxqAFEF6RGDPQlA4rGkf1g8e89AXXpFTAFOgMiPBkAaAx7jCTMsjHXLnzbHyaVOB
         L9n7UMSodAZYLMbzQcGFDYKxulvup02JOwfNgaoV/tQ3BifMY4lhE/MRIDV3zOs6Vh/T
         hxEzuvwt3I28h5IN8lkk28TDjRh2AJWyexcwGLYZiVEU2kDYQ3tgpLUgmZKIYZxl7rTD
         GqpX1fAm2YuRAQz9eXarISEK4MQPe0963a0GL+apKagTqsmeqI5EmOxTdUgDyXv+MjO5
         nvJA==
X-Forwarded-Encrypted: i=1; AJvYcCVxRlkDikdwibF/PSEIwkuSGN+Fkx9nNyZi+urQI9eswRL8msUy81u1xa+3m744pqV0YRlULvZz9KzxKpUURwdRjlgvdw6zSBoAr7j37wo=
X-Gm-Message-State: AOJu0YxhrlaawGKbnN88yXK+BAYJBODxPyyDYNlxIPhMfu9yXewXpGIs
	jVDLvkhMNBFrhBnYiRPBmbQVcDlfWL3H/+FL19sl6FtGe5ooOolHD8I1DYfPLw==
X-Google-Smtp-Source: AGHT+IHUmKEpJBilIByF+OT6BofcD8ZtLvUIdOznrpzaCoYzusFFI1UckbHqFe0/vzS/Pn3oXMUZGQ==
X-Received: by 2002:a17:906:7d8:b0:a3f:5ad2:1ff0 with SMTP id m24-20020a17090607d800b00a3f5ad21ff0mr2603917ejc.46.1710258172303;
        Tue, 12 Mar 2024 08:42:52 -0700 (PDT)
Message-ID: 
Date: Tue, 12 Mar 2024 16:42:51 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 2/9] x86: don't access x86_cpu_to_apicid[] directly,
 use cpu_physical_id(cpu)
Content-Language: en-US
To: Krystian Hebel 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu
 , xen-devel@lists.xenproject.org
References: 
 <705574ddb7f18bae9ed3f60ddf2e4bda02c70388.1699982111.git.krystian.hebel@3mdeb.com>
 <904f358b-c535-4de2-b31d-e593687af11b@suse.com>
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 12.03.2024 16:18, Krystian Hebel wrote:
> On 7.02.2024 17:28, Jan Beulich wrote:
>> On 14.11.2023 18:49, Krystian Hebel wrote:
>>> --- a/xen/arch/x86/apic.c
>>> +++ b/xen/arch/x86/apic.c
>>> @@ -950,7 +950,7 @@ __next:
>>>        */
>>>       if (boot_cpu_physical_apicid == -1U)
>>>           boot_cpu_physical_apicid = get_apic_id();
>>> -    x86_cpu_to_apicid[0] = get_apic_id();
>>> +    cpu_physical_id(0) = get_apic_id();
>> While personally I don't mind as much, I expect Andrew would not like
>> this: Something that looks like a function call on the lhs is against
>> what normal language structure would be.
> This made me cringe as well, but I've seen something like this used in
> other places (per_cpu() mostly) so I thought it was OK. I can change it.

Please try to get in touch with Andrew, to see what he thinks (especially
with your pointing of per_cpu()'s similarity).

Jan


From xen-devel-bounces@lists.xenproject.org Tue Mar 12 15:49:15 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Mar 2024 15:49:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.691927.1078531 (Exim 4.92)
	(envelope-from )
	id 1rk4NK-0003B0-IT; Tue, 12 Mar 2024 15:49:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 691927.1078531; Tue, 12 Mar 2024 15:49:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rk4NK-0003At-FS; Tue, 12 Mar 2024 15:49:10 +0000
Received: by outflank-mailman (input) for mailman id 691927;
 Tue, 12 Mar 2024 15:49:09 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rk4NJ-0003An-Ar
 for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 15:49:09 +0000
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com
 [2a00:1450:4864:20::22a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0fd7bc02-e088-11ee-afdd-a90da7624cb6;
 Tue, 12 Mar 2024 16:49:08 +0100 (CET)
Received: by mail-lj1-x22a.google.com with SMTP id
 38308e7fff4ca-2d4360ab3daso37289441fa.3
 for ; Tue, 12 Mar 2024 08:49:08 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 e14-20020a50fb8e000000b00568554e368dsm2489947edq.3.2024.03.12.08.49.07
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 12 Mar 2024 08:49:07 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0fd7bc02-e088-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710258548; x=1710863348; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=FbRA83MiwO/+5AdVZxlBYF1GDk7OKCIaDODL9TPrMbw=;
        b=bkux6cow4wnZ6nwiLXEORd+OAy1/fUXYBA/+5vX3H7TjsOi5JbU/IoAceklyMZj4F9
         TKghUuKz/e2zgQyhLbvJrBJ50rdYy9pqppVFMsZmCj3PSqKGs9xbIahWCyACHbNtxr4H
         nUpHGqOBM36SOR3VAnbeT1mTI7wRcDJQl//DDuJ7Z7EmyhfZ+aACdo3W2QlFmGIMjkMu
         7wUH2PQGCCQo72czCP8kNoW+lhFWIU39oN+rAK+gKoEB4ZuGF1xa0ib00RzXqoBCA//B
         1D6XJXKjYmuKxoSLmYp5TnE6e75W/Xi5EMGxDHkKe4gUVlkBL9lNU0Q8MxSZnRX8HwVf
         UnAg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710258548; x=1710863348;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=FbRA83MiwO/+5AdVZxlBYF1GDk7OKCIaDODL9TPrMbw=;
        b=Ig+iOO9Jzgst7SSGBW0fA59Qgd95gCBmJpgOwWGkzUky+Ye4T6ijZUw/st9xM0ENa7
         K639Fa3rZJLlezYySOgBSWnuIRjcj1bcA8sNoWthYVrvD0AQVNDYl1pFYBFU6F/EvrnW
         lhUbHoYa5/rdVhrWFY823cvhK/S7+4yJP7in8x76Q5ECjD1t32IACkCyjGQMj9Mc5E/H
         NSw+DFoNJB+8+6IcMXSnDULwabP00mQ+23RQn3ntiYocgRv9vQ8vyCGjpyUHWLmDu2oj
         87TfApLOjRAN08igDbw2HF5A4MHZbQIkaK+QmWFGWxVNpgUQkIRaBkwwe5GF4foUfTTO
         fpsg==
X-Forwarded-Encrypted: i=1; AJvYcCVAhGy1Kd/fOmNePL0PN15DZUSPYq/awxH4ScRg3853bEJ4YyjuA6/zzC71ogp4SqmIL72emrz/vuO0bTPEfoGxWDpIeTX0myJDrcLWXvM=
X-Gm-Message-State: AOJu0YzIYZhIvNboFR1VttfgtK5EBV+bCf3c2CQvlKqQa40O0K89eJV3
	/yzpE4C8/FP6uIFXier/ZAwGIZz+gFkKM8t08t+3IZ2+i+UHaM9k/ac/HGmckA==
X-Google-Smtp-Source: AGHT+IHawHznR/QP16njJczhOJgq8uXLgCtKz/7BDOB2PlnQ5gcgiWD1V0nUWAeWtCjYsP9jSYebkg==
X-Received: by 2002:a2e:a9ac:0:b0:2d4:22d1:d96c with SMTP id x44-20020a2ea9ac000000b002d422d1d96cmr1837780ljq.25.1710258547704;
        Tue, 12 Mar 2024 08:49:07 -0700 (PDT)
Message-ID: 
Date: Tue, 12 Mar 2024 16:49:06 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 3/9] x86/smp: drop x86_cpu_to_apicid, use
 cpu_data[cpu].apicid instead
Content-Language: en-US
To: Krystian Hebel 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org, Wei Liu ,
 Julien Grall 
References: 
 <8121d9b472b305be751158aa3af3fed98ff0572e.1699982111.git.krystian.hebel@3mdeb.com>
 
 <24dc1f13-3add-4b5f-9e2d-a18286b691eb@suse.com>
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 12.03.2024 16:29, Krystian Hebel wrote:
> On 7.02.2024 17:41, Jan Beulich wrote:
>> On 02.02.2024 19:11, Julien Grall wrote:
>>> On 14/11/2023 17:50, Krystian Hebel wrote:
>>>> --- a/xen/arch/x86/numa.c
>>>> +++ b/xen/arch/x86/numa.c
>>>> @@ -54,14 +54,13 @@ bool __init arch_numa_unavailable(void)
>>>>    /*
>>>>     * Setup early cpu_to_node.
>>>>     *
>>>> - * Populate cpu_to_node[] only if x86_cpu_to_apicid[],
>>>> - * and apicid_to_node[] tables have valid entries for a CPU.
>>>> - * This means we skip cpu_to_node[] initialisation for NUMA
>>>> - * emulation and faking node case (when running a kernel compiled
>>>> - * for NUMA on a non NUMA box), which is OK as cpu_to_node[]
>>>> - * is already initialized in a round robin manner at numa_init_array,
>>>> - * prior to this call, and this initialization is good enough
>>>> - * for the fake NUMA cases.
>>>> + * Populate cpu_to_node[] only if cpu_data[], and apicid_to_node[]
>> You mean cpu_physical_id() here, and then this change wants doing when
>> switching to that, imo.
> You mean s/cpu_data[]/cpu_physical_id()/ or something else?

Well, in general terms - whatever the function in fact accesses. That's,
if I reconstruct it from patch 2, as you say then.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Mar 12 15:54:39 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Mar 2024 15:54:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.691931.1078541 (Exim 4.92)
	(envelope-from )
	id 1rk4SZ-0004rP-4k; Tue, 12 Mar 2024 15:54:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 691931.1078541; Tue, 12 Mar 2024 15:54:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rk4SZ-0004rI-2C; Tue, 12 Mar 2024 15:54:35 +0000
Received: by outflank-mailman (input) for mailman id 691931;
 Tue, 12 Mar 2024 15:54:33 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rk4SX-0004rC-UU
 for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 15:54:33 +0000
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com
 [2a00:1450:4864:20::631])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d0c4a689-e088-11ee-a1ee-f123f15fe8a2;
 Tue, 12 Mar 2024 16:54:31 +0100 (CET)
Received: by mail-ej1-x631.google.com with SMTP id
 a640c23a62f3a-a45ba1f8e89so624837466b.1
 for ; Tue, 12 Mar 2024 08:54:31 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ld1-20020a170906f94100b00a461c74bbbfsm2699283ejb.91.2024.03.12.08.54.30
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 12 Mar 2024 08:54:31 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d0c4a689-e088-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710258871; x=1710863671; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=jl6fEIgH2oglGYPVjMa6cx3/SPDIkeNV4c9GG1YmLTE=;
        b=bGOkx2pHDt13Gi9iSOWigKj+Whw4+jf3vWRPJQbf0ZG+kJ1VZOJ6MwGHfE+On0oj4O
         6Gtn2/xI7U3e0PBycztDZvb7nBSnnjFJecC4pjE0IHJrl3S6GVtrxoRTFDHwQKlZsk17
         aYkyBoOy52IxFsVz0ogtIezKMUYh2zCTR+aExgZkFSMPS7PVyhC8GxsMYnGylSTkPEEk
         eWcTEyGAeiF8ZzOwTOx9Fq1UzadVjLreldSTPsuGdJcmiKmp3qBPVFoFcOTLc1QJwdbD
         8nIS/12YCMpIW7px71w9i5MD8XARvnt6DVlkokpQT0JD2jHpdgpwgGwqaThgw2z0EyPO
         tJ2A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710258871; x=1710863671;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=jl6fEIgH2oglGYPVjMa6cx3/SPDIkeNV4c9GG1YmLTE=;
        b=eO1CZ3vOELwTtCIMlBt7GdTBLcN0o0Ju7GNO7yQk55nPbylHNFp7vE3U5cnqqHlsLC
         8IVNFpE4QnDF90c/8NDjlP1vP26dQCfKER6bwXAwmIuV8ztbQQDAKYZkmP2XxHqiKmuO
         CuBE6He6wNqP+68Ikvr3gH7nbmYBAHVRWipdke3T1iqHh18zCSVV4ktx6TW9jT1oFesN
         LwvrCstXfd0VROlNLf/DU97/QJ+tuZVlDYSXOckibEweU057TA9Dppr7yDdQ9BMFfmD8
         Rueo4pX++z/ZxqpmGLcJ2d6h9poiAyj5XGlmw81Px31eQWUmqA2WODgle05GnCQnirX1
         MiXA==
X-Forwarded-Encrypted: i=1; AJvYcCWOI/HmqkkatyA+GBa90XhQZHNmDLZF3LI4y87MuTyTNciHqV7mJdwPPavkj9uRctndR2QWYRkiZ6zkpVK1x/KUwZnIVrZPvkblBlRQTcY=
X-Gm-Message-State: AOJu0YyxNBk2iH/a/4bBOWlTNpFcsgE7gX4Mt0uI1rfbld1c0ai0+vRK
	HfBgK20Iwrsd/fcz2N21/0ip5NHQRVAcilLnfG9JtxchmTN2LiHilhlBdibtTg==
X-Google-Smtp-Source: AGHT+IHi3LXKzx6fHhr5HA+tii4DsLRmvVNoPYeVL0CTnMFFDgCHCQUtBX6Oi9vizj18eu6FgoegjQ==
X-Received: by 2002:a17:906:af83:b0:a44:55e8:53b6 with SMTP id mj3-20020a170906af8300b00a4455e853b6mr6776137ejb.32.1710258871400;
        Tue, 12 Mar 2024 08:54:31 -0700 (PDT)
Message-ID: <7a9d46bb-e231-4b1a-a60c-62905e6cc1cc@suse.com>
Date: Tue, 12 Mar 2024 16:54:30 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH v3 14/16] xen/x86: address violations of MISRA C:2012
 Directive 4.10
Content-Language: en-US
To: Simone Ballarin 
Cc: consulting@bugseng.com, sstabellini@kernel.org,
 xen-devel@lists.xenproject.org,
 Maria Celeste Cesario ,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu 
References: 
 <305d6474a84e16d44c193a93e2c2ca91d6dd0f7e.1710145041.git.simone.ballarin@bugseng.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <305d6474a84e16d44c193a93e2c2ca91d6dd0f7e.1710145041.git.simone.ballarin@bugseng.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 11.03.2024 09:59, Simone Ballarin wrote:
> From: Maria Celeste Cesario 
> 
> Edit inclusion guards to address violations of
> MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order to
> prevent the contents of a header file being included more than once").
> Mechanical change.

The changes all follow a single pattern, yet I'm afraid I can't bring
this pattern in line with this description. To take ...

> --- a/xen/arch/x86/include/asm/domain.h
> +++ b/xen/arch/x86/include/asm/domain.h
> @@ -1,5 +1,5 @@
> -#ifndef __ASM_DOMAIN_H__
> -#define __ASM_DOMAIN_H__
> +#ifndef ASM_X86_DOMAIN_H
> +#define ASM_X86_DOMAIN_H
>  
>  #include 
>  #include 
> @@ -780,7 +780,7 @@ struct arch_vcpu_io {
>  /* Maxphysaddr supportable by the paging infrastructure. */
>  unsigned int domain_max_paddr_bits(const struct domain *d);
>  
> -#endif /* __ASM_DOMAIN_H__ */
> +#endif /* ASM_X86_DOMAIN_H */

... this as example - what's the violation here? The existing symbol
provides the intended effect, doesn't it? What it does not is adhere
to the new naming scheme, but there's no mention of that in the
description.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Mar 12 15:55:23 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Mar 2024 15:55:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.691933.1078551 (Exim 4.92)
	(envelope-from )
	id 1rk4TL-0005Lm-DZ; Tue, 12 Mar 2024 15:55:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 691933.1078551; Tue, 12 Mar 2024 15:55:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rk4TL-0005Lf-9z; Tue, 12 Mar 2024 15:55:23 +0000
Received: by outflank-mailman (input) for mailman id 691933;
 Tue, 12 Mar 2024 15:55:22 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rk4TK-0005CN-0v
 for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 15:55:22 +0000
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com
 [2a00:1450:4864:20::635])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ee4d3727-e088-11ee-afdd-a90da7624cb6;
 Tue, 12 Mar 2024 16:55:21 +0100 (CET)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-a28a6cef709so640561766b.1
 for ; Tue, 12 Mar 2024 08:55:21 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ld1-20020a170906f94100b00a461c74bbbfsm2699283ejb.91.2024.03.12.08.55.20
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 12 Mar 2024 08:55:20 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ee4d3727-e088-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710258921; x=1710863721; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=bUAB7QbBrOuy75xiVNXmLPTl1p+19b/5Fs5tqFgq71A=;
        b=RbISJ+wGXXHOCmF6eJvSj+OkERih6uAMAPvgJCdzKt7rCybtirLH0/70Reu3RPSEpw
         kv7tMhzEyqhUtbdmWA2UQnSVNtz4dDunoisTkcLbUdhenZC5HxLKeUqhbsVUsLjoN15Z
         WqMn6TIcaSXC8iY4Nc56AwwUWhUdM/Q2mScokpcq0S2GYeqaW0MuS27r5E2/VvshhM4p
         /4TErUeRfR9xigVWz27LZR/9ZIq/Kcn2/3T0/sBSEkspC67W5cIvuwIOUdzH3mp+JOGb
         n94ydae8QN8Z8oxIn/2niGpu0kEzTLt6ocqIH/zs2pNOkNEu39tPSCJhS5XzUWQx56aY
         Uf3A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710258921; x=1710863721;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=bUAB7QbBrOuy75xiVNXmLPTl1p+19b/5Fs5tqFgq71A=;
        b=Du90hjtrkFVnqeoToCbapPuaeIGzw2hyhTVSWOhOmQdSUKUUiVD3xDyAsSpIAZ0Q/5
         dZwtKateB8T1cLPmcV6ixLUGTC62+7JRPwGlh/7co3zqQ5sgI9WProNh4/ir85N04676
         5mXDBSmjoThqAuyz7p0vPNv17fqFLs2sTxKpXyK0LpYsK2fzGujYfu5nzOpBTjAl80vK
         R0eEDMI2pY7eIALD9DOhb1vnJ8avr82OJp9lmRWkvq3DRt2hN/SBJRabxn/mtEcAJEjk
         V6OV4LDe/TLdlFVLE3m9jtbQ9T803hjaualYxe87jmmKZlqGpQr5Xi9dSD7uyTKOKe0A
         +bUQ==
X-Forwarded-Encrypted: i=1; AJvYcCXsng+k7HHuDTDTifhxq8B7tuo7eOs+AYYgRdYf+ldsTI7ItLGd7VDT1sSyXUkiWxBKemvLNrXjR7h3THaCCqK7XEsiKgS9Hik6DrBVv2Q=
X-Gm-Message-State: AOJu0YxjiP+/jtbPZXjxsI7eIJEUujIEYRE9PvFKQ9YFwAJk1YrZhx5j
	SVO5XxE2GFxj8iVLN/9PNpAda4uMleDjiNRUefUcQwXDtyCSk+i2ed3C/gwk4McYIHlO/12Ogcs
	=
X-Google-Smtp-Source: AGHT+IGWq3EAubyD3sdivTPr2QhuG4+z35NHCHejXN7B/+f1MJzxzD1cVVSfL7DhnQkdSMKJJT20Ng==
X-Received: by 2002:a17:906:bf4a:b0:a45:bf67:bab2 with SMTP id ps10-20020a170906bf4a00b00a45bf67bab2mr6682747ejb.59.1710258920914;
        Tue, 12 Mar 2024 08:55:20 -0700 (PDT)
Message-ID: 
Date: Tue, 12 Mar 2024 16:55:20 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH v3 15/16] x86/mtrr: address violations of MISRA C:2012
 Directive 4.10
Content-Language: en-US
To: Simone Ballarin 
Cc: consulting@bugseng.com, sstabellini@kernel.org,
 Maria Celeste Cesario ,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org, Wei Liu 
References: 
 <33413c877af70c8aed05ed1bc7b259c59087cb96.1710145041.git.simone.ballarin@bugseng.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <33413c877af70c8aed05ed1bc7b259c59087cb96.1710145041.git.simone.ballarin@bugseng.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 11.03.2024 09:59, Simone Ballarin wrote:
> From: Maria Celeste Cesario 
> 
> Add inclusion guard to address violations of
> MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order to
> prevent the contents of a header file being included more than once").
> Mechanical change.
> ---
> Commit introduced in v3
> 
> Signed-off-by: Maria Celeste Cesario  
> Signed-off-by: Simone Ballarin  

Somewhat reluctantly
Acked-by: Jan Beulich 

Jan


From xen-devel-bounces@lists.xenproject.org Tue Mar 12 15:56:14 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Mar 2024 15:56:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.691935.1078560 (Exim 4.92)
	(envelope-from )
	id 1rk4U8-0005sU-Kp; Tue, 12 Mar 2024 15:56:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 691935.1078560; Tue, 12 Mar 2024 15:56:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rk4U8-0005sN-II; Tue, 12 Mar 2024 15:56:12 +0000
Received: by outflank-mailman (input) for mailman id 691935;
 Tue, 12 Mar 2024 15:56:11 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rk4U7-0005sE-8V
 for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 15:56:11 +0000
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com
 [2a00:1450:4864:20::62a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0a8d6a0d-e089-11ee-afdd-a90da7624cb6;
 Tue, 12 Mar 2024 16:56:08 +0100 (CET)
Received: by mail-ej1-x62a.google.com with SMTP id
 a640c23a62f3a-a28a6cef709so640735966b.1
 for ; Tue, 12 Mar 2024 08:56:08 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ld1-20020a170906f94100b00a461c74bbbfsm2699283ejb.91.2024.03.12.08.56.07
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 12 Mar 2024 08:56:08 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0a8d6a0d-e089-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710258968; x=1710863768; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=0OsmxsGsmYAus/RH/y9PaIuXpWenHxAlXzle9HumqCw=;
        b=LbV502eKwnPTa13mPebpqoIVoJk+CxsV30NLxdyctnCN15OnAHHeoPB968mfiLjCy5
         XYqKy/dUgLEfh/bfcO7frWm/9s9AsEJnpYkSBfmcHeXmqAnrjSlQ8feFFZ1/SXzZqrnJ
         jpNQkFlAKr5zVA45PvFYgrHM5tvDcY62ZUYoGCMiHAiidoOO+PMwwKL8iHZ9n52Ib7dz
         Eyj+Cy0G8Pa7aO3VX9DnEMliHsvXaItbuLGGOneWrbHNTUAnNL9HdgKtaI0gMTV3HsB6
         qyFy4zoj1QdCMp8VQILYfH8QVvavtGOhSF/2kaoDOJE5M2lmxak8Yno3tQ9wL24IEsGS
         Rg0w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710258968; x=1710863768;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=0OsmxsGsmYAus/RH/y9PaIuXpWenHxAlXzle9HumqCw=;
        b=ndklUMxTIiE7OWIiCAcAKuep3hAEbwORbNNPwLC3x3SvoPXfTkQHMEPu13l8/RvIsz
         0IDj6JuY5jNCoooTGzQLx1SMoHgCr+HPTn3kceLBoBbyDNtoWDWcUvVNM9w2yc9/7VBD
         0e1RlYjK2DV4+/3IAmRpXfJBKxtomPuBReijTaMIVmRcLv2ywE8R0JBzK2ztdnB4bD2Z
         xGrSKyD/zrk5SC6JFXEJW5wNEy78C8w5aZPtUAo/0NBZbX+R9sKLy/+SWNusDMcd+LQ0
         hgGnfCDFxHE5TuMTAuCWk816Svoa3yNeiW9rwUOEW0C10slYboVwmYLNVbn9tix5wCwu
         GrtQ==
X-Forwarded-Encrypted: i=1; AJvYcCXr62yFFEnrsm+IhzbeWNBUiQ+kX+65dYVwe3JtP5D7fNvbXLSkU/DwI2aa8TJPxsDZ3hsoSX6OaZlSzJ2sasZAJ7K6JL40roPQXsKaGxQ=
X-Gm-Message-State: AOJu0YzOkFLyd4aFfYjQuyX1FpJ+JDCdZn+Ng+x3nrMY/J6VH3Oz1QHC
	i34X0ZPc1LiJFN3GumgN9IWNVyVKdqtmzLL7wZ5H608r80edAI/zxuDt2bEQ9A==
X-Google-Smtp-Source: AGHT+IFypSkTQJZ6eqLQ+AQNbzT8R8CJkS7az4UBwYNcTt0zg0N4WC+AP9zTJjHNath/SJy1FKjHJg==
X-Received: by 2002:a17:906:c793:b0:a46:3f18:957 with SMTP id cw19-20020a170906c79300b00a463f180957mr1658308ejb.36.1710258968475;
        Tue, 12 Mar 2024 08:56:08 -0700 (PDT)
Message-ID: 
Date: Tue, 12 Mar 2024 16:56:07 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH v3 16/16] xen/lz4: address violations of MISRA C:2012
 Directive 4.10
Content-Language: en-US
To: Simone Ballarin 
Cc: consulting@bugseng.com, sstabellini@kernel.org,
 Maria Celeste Cesario ,
 Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Wei Liu , xen-devel@lists.xenproject.org
References: 
 <1d02e429534b9b1c53fd3c5b82588e3803434c92.1710145041.git.simone.ballarin@bugseng.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <1d02e429534b9b1c53fd3c5b82588e3803434c92.1710145041.git.simone.ballarin@bugseng.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 11.03.2024 09:59, Simone Ballarin wrote:
> From: Maria Celeste Cesario 
> 
> Add inclusion guard to address violations of
> MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order to
> prevent the contents of a header file being included more than once").
> Mechanical change.
> ---
> Commit introduced in v3
> 
> Signed-off-by: Maria Celeste Cesario  
> Signed-off-by: Simone Ballarin  

Once again somewhat reluctantly
Acked-by: Jan Beulich 

Jan


From xen-devel-bounces@lists.xenproject.org Tue Mar 12 15:59:25 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Mar 2024 15:59:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.691940.1078571 (Exim 4.92)
	(envelope-from )
	id 1rk4XD-0006tm-6z; Tue, 12 Mar 2024 15:59:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 691940.1078571; Tue, 12 Mar 2024 15:59:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rk4XD-0006tf-43; Tue, 12 Mar 2024 15:59:23 +0000
Received: by outflank-mailman (input) for mailman id 691940;
 Tue, 12 Mar 2024 15:59:22 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rk4XC-0006tZ-7Y
 for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 15:59:22 +0000
Received: from 2.mo581.mail-out.ovh.net (2.mo581.mail-out.ovh.net
 [87.98.143.68]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7ce02049-e089-11ee-afdd-a90da7624cb6;
 Tue, 12 Mar 2024 16:59:20 +0100 (CET)
Received: from director1.ghost.mail-out.ovh.net (unknown [10.108.17.154])
 by mo581.mail-out.ovh.net (Postfix) with ESMTP id 4TvJHD1NkHz1Drq
 for ; Tue, 12 Mar 2024 15:59:20 +0000 (UTC)
Received: from ghost-submission-6684bf9d7b-dqcch (unknown [10.110.113.89])
 by director1.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 3A7E41FE91;
 Tue, 12 Mar 2024 15:59:18 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.102])
 by ghost-submission-6684bf9d7b-dqcch with ESMTPSA
 id or3LOtZ78GUmCgEAPdwMoA
 (envelope-from ); Tue, 12 Mar 2024 15:59:18 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7ce02049-e089-11ee-afdd-a90da7624cb6
Authentication-Results:garm.ovh; auth=pass (GARM-102R0040c942c0f-2bc0-4f3f-9004-f3dbd45a2912,
                    0B6B113C544506A41C6EB031E0F94F2E66B6AEBC) smtp.auth=krystian.hebel@3mdeb.com
X-OVh-ClientIp:217.171.61.25
Content-Type: multipart/alternative;
 boundary="------------fxxSrUaDYSHJhsFTScDE9qCt"
Message-ID: 
Date: Tue, 12 Mar 2024 16:59:17 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 4/9] x86/smp: move stack_base to cpu_data
Content-Language: en-US
To: Jan Beulich , Julien Grall 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu
 , George Dunlap ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: 
 <70e3b7c84a69a7ec52b3ed6314395165c281734c.1699982111.git.krystian.hebel@3mdeb.com>
 
 <52e2db77-88c4-47c5-85d7-34b0bb133b69@suse.com>
From: Krystian Hebel 
In-Reply-To: <52e2db77-88c4-47c5-85d7-34b0bb133b69@suse.com>
X-Ovh-Tracer-Id: 8923882662734768473
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedvledrjeefgdekfecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpegtkfffgggfuffvvehfhfgjsegrtderredtvdejnecuhfhrohhmpefmrhihshhtihgrnhcujfgvsggvlhcuoehkrhihshhtihgrnhdrhhgvsggvlhesfehmuggvsgdrtghomheqnecuggftrfgrthhtvghrnheptddtledufedvgfettdevhffgtdegjeekveefgeelhfdvueegkeetueeuhfejgeetnecuffhomhgrihhnpeefmhguvggsrdgtohhmnecukfhppeduvdejrddtrddtrddupddvudejrddujedurdeiuddrvdehpdefjedrheelrddugedvrddutddvnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepuddvjedrtddrtddruddpmhgrihhlfhhrohhmpehkrhihshhtihgrnhdrhhgvsggvlhesfehmuggvsgdrtghomhdpnhgspghrtghpthhtohepuddprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdpoffvtefjohhsthepmhhoheekuddpmhhouggvpehsmhhtphhouhht

This is a multi-part message in MIME format.
--------------fxxSrUaDYSHJhsFTScDE9qCt
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 5.02.2024 09:41, Jan Beulich wrote:
> On 02.02.2024 19:24, Julien Grall wrote:
>> On 14/11/2023 17:50, Krystian Hebel wrote:
>>> This location is easier to access from assembly. Having it close to
>>> other data required during initialization has also positive (although
>>> rather small) impact on prefetching data from RAM.
>> I understand your goal but...
>>
>>> --- a/xen/arch/x86/include/asm/cpufeature.h
>>> +++ b/xen/arch/x86/include/asm/cpufeature.h
>> ... cpufeature.h feels a rather odd place for storing the stack. I am
>> not entirely sure where else to place. Andrew, Jan, Roger?
> Well, without having looked at the patch/series itself yet, I can only
> say that if struct cpuinfo_x86 really is the place to put this
> information, then it's unavoidable to have the field added in this
> header. That said, it certainly feels like an abuse - there's nothing
> in common with other (collected) data in this structure. "Easier to
> access from assembly" may be a fair reason, but then I'd expect the
> downsides of alternatives to be discussed explicitly. For example, a
> simple new array might be as "easily" accessible from assembly.

Initially I thought I'll be using more fields from this structure a lot, 
like
booted_cores or apicid. I'll move this and cpu_state introduced in following
patch somewhere else.

>
>>> @@ -37,6 +37,7 @@ struct cpuinfo_x86 {
>>>        unsigned int phys_proc_id;         /* package ID of each logical CPU */
>>>        unsigned int cpu_core_id;          /* core ID of each logical CPU */
>>>        unsigned int compute_unit_id;      /* AMD compute unit ID of each logical CPU */
>>> +    void *stack_base;
>> AFAICT, this means there will be a padding before stack_base and ...
>>
>>>        unsigned short x86_clflush_size;
>> ... another one here. Is there any particular reason the new field
>> wasn't added at the end?
> With ...
>
>>>    } __cacheline_aligned;
> ... this I'm not exactly sure this is a problem right now (there may
> be ample padding space anyway, yet I didn't go count). But I agree
> with your comment in principle.
I've checked that the size didn't change after adding. I also think that
I checked that adding it there wouldn't add any padding, but maybe I
miscalculated something. In any way, this will be moved from here.
>>> --- a/xen/arch/x86/smpboot.c
>>> +++ b/xen/arch/x86/smpboot.c
>>> @@ -75,13 +75,15 @@ static enum cpu_state {
>>>    } cpu_state;
>>>    #define set_cpu_state(state) do { smp_mb(); cpu_state = (state); } while (0)
>>>    
>>> -void *stack_base[NR_CPUS];
>>> -
>>>    void initialize_cpu_data(unsigned int cpu)
>>>    {
>>>        uint32_t apicid = cpu_physical_id(cpu);
>>> +    void *stack = cpu_data[cpu].stack_base;
>>> +
>>>        cpu_data[cpu] = boot_cpu_data;
>>> +
>>>        cpu_physical_id(cpu) = apicid;
>>> +    cpu_data[cpu].stack_base = stack;
>>>    }
>>>    
>>>    static bool smp_store_cpu_info(unsigned int id)
>>> @@ -579,8 +581,6 @@ static int do_boot_cpu(int apicid, int cpu)
>>>            printk("Booting processor %d/%d eip %lx\n",
>>>                   cpu, apicid, start_eip);
>>>    
>>> -    stack_start = stack_base[cpu] + STACK_SIZE - sizeof(struct cpu_info);
>>> -
>> You remove this line because I can't quite figure out where stack_start
>> is now set. This is used...
> This line sets a global variable, which ...
>
>>> @@ -856,7 +856,7 @@ int setup_cpu_root_pgt(unsigned int cpu)
>>>    
>>>        /* Install direct map page table entries for stack, IDT, and TSS. */
>>>        for ( off = rc = 0; !rc && off < STACK_SIZE; off += PAGE_SIZE )
>>> -        rc = clone_mapping(__va(__pa(stack_base[cpu])) + off, rpt);
>>> +        rc = clone_mapping(__va(__pa(cpu_data[cpu].stack_base)) + off, rpt);
>>>    
>>>        if ( !rc )
>>>            rc = clone_mapping(idt_tables[cpu], rpt);
>>> @@ -1007,10 +1007,10 @@ static void cpu_smpboot_free(unsigned int cpu, bool remove)
>>>            FREE_XENHEAP_PAGE(per_cpu(gdt, cpu));
>>>            FREE_XENHEAP_PAGE(idt_tables[cpu]);
>>>    
>>> -        if ( stack_base[cpu] )
>>> +        if ( cpu_data[cpu].stack_base )
>>>            {
>>> -            memguard_unguard_stack(stack_base[cpu]);
>>> -            FREE_XENHEAP_PAGES(stack_base[cpu], STACK_ORDER);
>>> +            memguard_unguard_stack(cpu_data[cpu].stack_base);
>>> +            FREE_XENHEAP_PAGES(cpu_data[cpu].stack_base, STACK_ORDER);
>>>            }
>>>        }
>>>    }
>>> @@ -1044,11 +1044,11 @@ static int cpu_smpboot_alloc(unsigned int cpu)
>>>        if ( node != NUMA_NO_NODE )
>>>            memflags = MEMF_node(node);
>>>    
>>> -    if ( stack_base[cpu] == NULL &&
>>> -         (stack_base[cpu] = cpu_alloc_stack(cpu)) == NULL )
>>> +    if ( cpu_data[cpu].stack_base == NULL &&
>>> +         (cpu_data[cpu].stack_base = cpu_alloc_stack(cpu)) == NULL )
>>>                goto out;
>>>    
>>> -    info = get_cpu_info_from_stack((unsigned long)stack_base[cpu]);
>>> +    info = get_cpu_info_from_stack((unsigned long)cpu_data[cpu].stack_base);
>> ... here.
> ... pretty clearly is not used here (anymore). Instead I'd raise the
> question of what the remaining purpose of that variable then is.
> Looking through updates this patch alone makes to use sites of
> stack_start, it's unclear whether the use from assembly code has gone
> away already - brief checking suggests it hasn't.
BSP still uses it, but APs don't. That said, comment above declaration says
otherwise, I'll change it, or maybe this variable can be removed altogether
since it always points to the same place, and there are only two consumers,
both in assembly.
>
> Jan
Best regards,

-- 
Krystian Hebel
Firmware Engineer
https://3mdeb.com  | @3mdeb_com

--------------fxxSrUaDYSHJhsFTScDE9qCt
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  
    
  
  
    


    

    
On 5.02.2024 09:41, Jan Beulich wrote:

    

    

      
On 02.02.2024 19:24, Julien Grall wrote:


      

        
On 14/11/2023 17:50, Krystian Hebel wrote:


        

          
This location is easier to access from assembly. Having it close to
other data required during initialization has also positive (although
rather small) impact on prefetching data from RAM.


        

        
I understand your goal but...



        

          
--- a/xen/arch/x86/include/asm/cpufeature.h
+++ b/xen/arch/x86/include/asm/cpufeature.h


        

        
... cpufeature.h feels a rather odd place for storing the stack. I am 
not entirely sure where else to place. Andrew, Jan, Roger?


      

      
Well, without having looked at the patch/series itself yet, I can only
say that if struct cpuinfo_x86 really is the place to put this
information, then it's unavoidable to have the field added in this
header. That said, it certainly feels like an abuse - there's nothing
in common with other (collected) data in this structure. "Easier to
access from assembly" may be a fair reason, but then I'd expect the
downsides of alternatives to be discussed explicitly. For example, a
simple new array might be as "easily" accessible from assembly.

    

    
Initially I thought I'll be using more fields from this structure
      a lot, like

      booted_cores or apicid. I'll move this and cpu_state introduced in
      following

      patch somewhere else.

    

    

      



      

        

          
@@ -37,6 +37,7 @@ struct cpuinfo_x86 {
      unsigned int phys_proc_id;         /* package ID of each logical CPU */
      unsigned int cpu_core_id;          /* core ID of each logical CPU */
      unsigned int compute_unit_id;      /* AMD compute unit ID of each logical CPU */
+    void *stack_base;


        

        
AFAICT, this means there will be a padding before stack_base and ...



        

          
      unsigned short x86_clflush_size;


        

        
... another one here. Is there any particular reason the new field 
wasn't added at the end?


      

      
With ...



      

        

          
  } __cacheline_aligned;


        

      

      
... this I'm not exactly sure this is a problem right now (there may
be ample padding space anyway, yet I didn't go count). But I agree
with your comment in principle.

    

    I've checked that the size didn't change after adding. I also think
    that

    I checked that adding it there wouldn't add any padding, but maybe I

    miscalculated something. In any way, this will be moved from here.

    

      

        

          
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -75,13 +75,15 @@ static enum cpu_state {
  } cpu_state;
  #define set_cpu_state(state) do { smp_mb(); cpu_state = (state); } while (0)
  
-void *stack_base[NR_CPUS];
-
  void initialize_cpu_data(unsigned int cpu)
  {
      uint32_t apicid = cpu_physical_id(cpu);
+    void *stack = cpu_data[cpu].stack_base;
+
      cpu_data[cpu] = boot_cpu_data;
+
      cpu_physical_id(cpu) = apicid;
+    cpu_data[cpu].stack_base = stack;
  }
  
  static bool smp_store_cpu_info(unsigned int id)
@@ -579,8 +581,6 @@ static int do_boot_cpu(int apicid, int cpu)
          printk("Booting processor %d/%d eip %lx\n",
                 cpu, apicid, start_eip);
  
-    stack_start = stack_base[cpu] + STACK_SIZE - sizeof(struct cpu_info);
-


        

        
You remove this line because I can't quite figure out where stack_start 
is now set. This is used...


      

      
This line sets a global variable, which ...



      

        

          
@@ -856,7 +856,7 @@ int setup_cpu_root_pgt(unsigned int cpu)
  
      /* Install direct map page table entries for stack, IDT, and TSS. */
      for ( off = rc = 0; !rc && off < STACK_SIZE; off += PAGE_SIZE )
-        rc = clone_mapping(__va(__pa(stack_base[cpu])) + off, rpt);
+        rc = clone_mapping(__va(__pa(cpu_data[cpu].stack_base)) + off, rpt);
  
      if ( !rc )
          rc = clone_mapping(idt_tables[cpu], rpt);
@@ -1007,10 +1007,10 @@ static void cpu_smpboot_free(unsigned int cpu, bool remove)
          FREE_XENHEAP_PAGE(per_cpu(gdt, cpu));
          FREE_XENHEAP_PAGE(idt_tables[cpu]);
  
-        if ( stack_base[cpu] )
+        if ( cpu_data[cpu].stack_base )
          {
-            memguard_unguard_stack(stack_base[cpu]);
-            FREE_XENHEAP_PAGES(stack_base[cpu], STACK_ORDER);
+            memguard_unguard_stack(cpu_data[cpu].stack_base);
+            FREE_XENHEAP_PAGES(cpu_data[cpu].stack_base, STACK_ORDER);
          }
      }
  }
@@ -1044,11 +1044,11 @@ static int cpu_smpboot_alloc(unsigned int cpu)
      if ( node != NUMA_NO_NODE )
          memflags = MEMF_node(node);
  
-    if ( stack_base[cpu] == NULL &&
-         (stack_base[cpu] = cpu_alloc_stack(cpu)) == NULL )
+    if ( cpu_data[cpu].stack_base == NULL &&
+         (cpu_data[cpu].stack_base = cpu_alloc_stack(cpu)) == NULL )
              goto out;
  
-    info = get_cpu_info_from_stack((unsigned long)stack_base[cpu]);
+    info = get_cpu_info_from_stack((unsigned long)cpu_data[cpu].stack_base);


        

        
... here.


      

      
... pretty clearly is not used here (anymore). Instead I'd raise the
question of what the remaining purpose of that variable then is.
Looking through updates this patch alone makes to use sites of
stack_start, it's unclear whether the use from assembly code has gone
away already - brief checking suggests it hasn't.

    

    BSP still uses it, but APs don't. That said, comment above
    declaration says

    otherwise, I'll change it, or maybe this variable can be removed
    altogether

    since it always points to the same place, and there are only two
    consumers,

    both in assembly.

    

      

Jan


    

    Best regards,

    
-- 
Krystian Hebel
Firmware Engineer
https://3mdeb.com | @3mdeb_com

  


--------------fxxSrUaDYSHJhsFTScDE9qCt--


From xen-devel-bounces@lists.xenproject.org Tue Mar 12 16:02:51 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Mar 2024 16:02:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.691942.1078581 (Exim 4.92)
	(envelope-from )
	id 1rk4aV-0000l7-LL; Tue, 12 Mar 2024 16:02:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 691942.1078581; Tue, 12 Mar 2024 16:02:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rk4aV-0000l0-IE; Tue, 12 Mar 2024 16:02:47 +0000
Received: by outflank-mailman (input) for mailman id 691942;
 Tue, 12 Mar 2024 16:02:47 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rk4aV-0000kb-49
 for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 16:02:47 +0000
Received: from 10.mo583.mail-out.ovh.net (10.mo583.mail-out.ovh.net
 [46.105.52.148]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f6ad7b69-e089-11ee-a1ee-f123f15fe8a2;
 Tue, 12 Mar 2024 17:02:45 +0100 (CET)
Received: from director2.ghost.mail-out.ovh.net (unknown [10.109.139.201])
 by mo583.mail-out.ovh.net (Postfix) with ESMTP id 4TvJM84bKhz1Jpk
 for ; Tue, 12 Mar 2024 16:02:44 +0000 (UTC)
Received: from ghost-submission-6684bf9d7b-zrj5v (unknown [10.110.168.153])
 by director2.ghost.mail-out.ovh.net (Postfix) with ESMTPS id EBE101FD71;
 Tue, 12 Mar 2024 16:02:43 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.106])
 by ghost-submission-6684bf9d7b-zrj5v with ESMTPSA
 id 8T2QNaN88GV24AAAhIFWDg
 (envelope-from ); Tue, 12 Mar 2024 16:02:43 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f6ad7b69-e089-11ee-a1ee-f123f15fe8a2
Authentication-Results:garm.ovh; auth=pass (GARM-106R0061ef6d01a-5820-48e0-827f-ca8887385c86,
                    0B6B113C544506A41C6EB031E0F94F2E66B6AEBC) smtp.auth=krystian.hebel@3mdeb.com
X-OVh-ClientIp:217.171.61.25
Message-ID: 
Date: Tue, 12 Mar 2024 17:02:42 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 5/9] x86/smp: call x2apic_ap_setup() earlier
Content-Language: en-US
To: Jan Beulich , Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org, Wei Liu 
References: 
 <7c13554e60cc76516922992b7faf911b91f99a2a.1699982111.git.krystian.hebel@3mdeb.com>
 
From: Krystian Hebel 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Ovh-Tracer-Id: 8981303558268430704
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedvledrjeefgdekfecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefkffggfgfuvfevfhfhjggtgfesthejredttddvjeenucfhrhhomhepmfhrhihsthhirghnucfjvggsvghluceokhhrhihsthhirghnrdhhvggsvghlseefmhguvggsrdgtohhmqeenucggtffrrghtthgvrhhnpeejuedvffefvdeuvdeffeduuddtjeetgeefffdugfdvkeehtedutefghfdtteejieenucffohhmrghinhepfehmuggvsgdrtghomhenucfkphepuddvjedrtddrtddruddpvddujedrudejuddriedurddvhedpfeejrdehledrudegvddruddtieenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeduvdejrddtrddtrddupdhmrghilhhfrhhomhepkhhrhihsthhirghnrdhhvggsvghlseefmhguvggsrdgtohhmpdhnsggprhgtphhtthhopedupdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhgpdfovfetjfhoshhtpehmohehkeefpdhmohguvgepshhmthhpohhuth


On 7.02.2024 18:02, Jan Beulich wrote:
> On 14.11.2023 18:50, Krystian Hebel wrote:
>> It used to be called from smp_callin(), however BUG_ON() was invoked on
>> multiple occasions before that. It may end up calling machine_restart()
>> which tries to get APIC ID for CPU running this code. If BSP detected
>> that x2APIC is enabled, get_apic_id() will try to use it for all CPUs.
>> Enabling x2APIC on secondary CPUs earlier protects against an endless
>> loop of #GP exceptions caused by attempts to read IA32_X2APIC_APICID
>> MSR while x2APIC is disabled in IA32_APIC_BASE.
>>
>> Signed-off-by: Krystian Hebel 
>> ---
>>   xen/arch/x86/smpboot.c | 9 ++++++++-
>>   1 file changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
>> index 8ae65ab1769f..a3895dafa267 100644
>> --- a/xen/arch/x86/smpboot.c
>> +++ b/xen/arch/x86/smpboot.c
>> @@ -184,7 +184,6 @@ static void smp_callin(void)
>>        * update until we finish. We are free to set up this CPU: first the APIC.
>>        */
>>       Dprintk("CALLIN, before setup_local_APIC().\n");
>> -    x2apic_ap_setup();
>>       setup_local_APIC(false);
>>   
>>       /* Save our processor parameters. */
>> @@ -351,6 +350,14 @@ void start_secondary(void *unused)
>>       get_cpu_info()->xen_cr3 = 0;
>>       get_cpu_info()->pv_cr3 = 0;
>>   
>> +    /*
>> +     * BUG_ON() used in load_system_tables() and later code may end up calling
>> +     * machine_restart() which tries to get APIC ID for CPU running this code.
>> +     * If BSP detected that x2APIC is enabled, get_apic_id() will try to use it
>> +     * for _all_ CPUs. Enable x2APIC on secondary CPUs now so we won't end up
>> +     * with endless #GP loop.
>> +     */
>> +    x2apic_ap_setup();
>>       load_system_tables();
> While I find the argument convincing, I seem to recall that there was a
> firm plan to have load_system_tables() as early as possible. Andrew?
This is where the code failed for me during testing. How about moving
x2apic_ap_setup() into load_system_tables(), just before BUG_ON? Or maybe
move those BUG_ON one level higher, after load_system_tables() returns?
Either way some code will end up in place it doesn't belong, but I'd 
argue that
BUG_ON is only useful if it itself doesn't crash.
>
> Jan

-- 
Krystian Hebel
Firmware Engineer
https://3mdeb.com | @3mdeb_com



From xen-devel-bounces@lists.xenproject.org Tue Mar 12 16:06:00 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Mar 2024 16:06:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.691946.1078590 (Exim 4.92)
	(envelope-from )
	id 1rk4db-0001Kn-2K; Tue, 12 Mar 2024 16:05:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 691946.1078590; Tue, 12 Mar 2024 16:05:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rk4da-0001Kg-VU; Tue, 12 Mar 2024 16:05:58 +0000
Received: by outflank-mailman (input) for mailman id 691946;
 Tue, 12 Mar 2024 16:05:57 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rk4dZ-0001KZ-FB
 for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 16:05:57 +0000
Received: from 17.mo583.mail-out.ovh.net (17.mo583.mail-out.ovh.net
 [46.105.56.132]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 68c5d833-e08a-11ee-afdd-a90da7624cb6;
 Tue, 12 Mar 2024 17:05:56 +0100 (CET)
Received: from director7.ghost.mail-out.ovh.net (unknown [10.109.139.11])
 by mo583.mail-out.ovh.net (Postfix) with ESMTP id 4TvJQr0mMdz1FNt
 for ; Tue, 12 Mar 2024 16:05:56 +0000 (UTC)
Received: from ghost-submission-6684bf9d7b-ktqmh (unknown [10.111.182.20])
 by director7.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 24BA81FEA1;
 Tue, 12 Mar 2024 16:05:54 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.108])
 by ghost-submission-6684bf9d7b-ktqmh with ESMTPSA
 id l/0fNGJ98GX/+AEASnncPg
 (envelope-from ); Tue, 12 Mar 2024 16:05:54 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 68c5d833-e08a-11ee-afdd-a90da7624cb6
Authentication-Results:garm.ovh; auth=pass (GARM-108S0025fe8f4cf-b773-4400-aff0-01b1bbbd189c,
                    0B6B113C544506A41C6EB031E0F94F2E66B6AEBC) smtp.auth=krystian.hebel@3mdeb.com
X-OVh-ClientIp:217.171.61.25
Message-ID: <173cc1f7-d906-47ed-bba3-d43da219fd7b@3mdeb.com>
Date: Tue, 12 Mar 2024 17:05:51 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 6/9] x86/shutdown: protect against recurrent
 machine_restart()
Content-Language: en-US
To: Jan Beulich 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org, Wei Liu 
References: 
 <87b0e650f28038c2fb64c5eb607c8fdaa7b4db07.1699982111.git.krystian.hebel@3mdeb.com>
 <665c7f47-a218-4187-858d-562bb5b9513b@suse.com>
From: Krystian Hebel 
In-Reply-To: <665c7f47-a218-4187-858d-562bb5b9513b@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Ovh-Tracer-Id: 9035346755143379312
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedvledrjeefgdekgecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefkffggfgfuvfevfhfhjggtgfesthejredttddvjeenucfhrhhomhepmfhrhihsthhirghnucfjvggsvghluceokhhrhihsthhirghnrdhhvggsvghlseefmhguvggsrdgtohhmqeenucggtffrrghtthgvrhhnpeejuedvffefvdeuvdeffeduuddtjeetgeefffdugfdvkeehtedutefghfdtteejieenucffohhmrghinhepfehmuggvsgdrtghomhenucfkphepuddvjedrtddrtddruddpvddujedrudejuddriedurddvhedpfeejrdehledrudegvddruddtkeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeduvdejrddtrddtrddupdhmrghilhhfrhhomhepkhhrhihsthhirghnrdhhvggsvghlseefmhguvggsrdgtohhmpdhnsggprhgtphhtthhopedupdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhgpdfovfetjfhoshhtpehmohehkeefpdhmohguvgepshhmthhpohhuth


On 8.02.2024 12:30, Jan Beulich wrote:
> On 14.11.2023 18:50, Krystian Hebel wrote:
>> If multiple CPUs called machine_restart() before actual restart took
>> place, but after boot CPU declared itself not online,
> Can you help me please in identifying where this operation is? I can see
> two places where a CPU is removed from cpu_online_map, yet neither
> __stop_this_cpu() nor __cpu_disable() ought to be coming into play here.
> In fact I didn't think CPU0 was ever marked not-online. Except perhaps
> if we came through machine_crash_shutdown() -> nmi_shootdown_cpus(), but
> I'm sure you would have mentioned such a further dependency.
>
> Jan
BUG_ON() in cpu_notifier_call_chain() (I've been playing with some of
the notifiers and one of them eventually failed) resulted in panic()
around the same time AP did in pm_idle() due to inconsistent settings
between BSP and AP for MWAIT/MONITOR support after TXT dynamic
launch. There is 5s delay between smp_send_stop() and actual reboot,
during that time AP spammed the output so the original reason for
panic() was visible only after unreasonable amount of scrolling.

Adding TXT support is the reason why I even started making AP bring-up
parallel. Problem with MWAIT doesn't happen in current code or changes
in this patchset, but handling of such error is related to SMP so I've 
included it.

Best regards,

-- 
Krystian Hebel
Firmware Engineer
https://3mdeb.com | @3mdeb_com



From xen-devel-bounces@lists.xenproject.org Tue Mar 12 16:16:33 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Mar 2024 16:16:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.691951.1078601 (Exim 4.92)
	(envelope-from )
	id 1rk4ni-0003Pf-W2; Tue, 12 Mar 2024 16:16:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 691951.1078601; Tue, 12 Mar 2024 16:16:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rk4ni-0003PY-SU; Tue, 12 Mar 2024 16:16:26 +0000
Received: by outflank-mailman (input) for mailman id 691951;
 Tue, 12 Mar 2024 16:16:25 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rk4nh-0003PS-UE
 for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 16:16:25 +0000
Received: from 16.mo584.mail-out.ovh.net (16.mo584.mail-out.ovh.net
 [188.165.55.104]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id df04fce0-e08b-11ee-afdd-a90da7624cb6;
 Tue, 12 Mar 2024 17:16:24 +0100 (CET)
Received: from director6.ghost.mail-out.ovh.net (unknown [10.109.148.116])
 by mo584.mail-out.ovh.net (Postfix) with ESMTP id 4TvJfv6L7Cz1DQj
 for ; Tue, 12 Mar 2024 16:16:23 +0000 (UTC)
Received: from ghost-submission-6684bf9d7b-xqgc7 (unknown [10.110.113.13])
 by director6.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 265F11FE5A;
 Tue, 12 Mar 2024 16:16:23 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.102])
 by ghost-submission-6684bf9d7b-xqgc7 with ESMTPSA
 id XXIuBdd/8GXxCwEA52rYjQ
 (envelope-from ); Tue, 12 Mar 2024 16:16:23 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: df04fce0-e08b-11ee-afdd-a90da7624cb6
Authentication-Results:garm.ovh; auth=pass (GARM-102R004950cf0eb-3aa7-4695-9bc2-6ee31df4f5d9,
                    0B6B113C544506A41C6EB031E0F94F2E66B6AEBC) smtp.auth=krystian.hebel@3mdeb.com
X-OVh-ClientIp:217.171.61.25
Content-Type: multipart/alternative;
 boundary="------------v5bIFxATm5XUzPgaY5RAYWWB"
Message-ID: 
Date: Tue, 12 Mar 2024 17:16:21 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 7/9] x86/smp: drop booting_cpu variable
Content-Language: en-US
To: Jan Beulich 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu
 , xen-devel@lists.xenproject.org
References: 
 <22109ebd7edef1140cb438a6ec5fa1726cdf2c12.1699982111.git.krystian.hebel@3mdeb.com>
 <3df6b783-ff02-4ac9-ae76-843899fa2383@suse.com>
From: Krystian Hebel 
In-Reply-To: <3df6b783-ff02-4ac9-ae76-843899fa2383@suse.com>
X-Ovh-Tracer-Id: 9211831564845033817
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedvledrjeefgdekiecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpegtkfffgggfuffvvehfhfgjsegrtderredtvdejnecuhfhrohhmpefmrhihshhtihgrnhcujfgvsggvlhcuoehkrhihshhtihgrnhdrhhgvsggvlhesfehmuggvsgdrtghomheqnecuggftrfgrthhtvghrnhepkeevfeevudffvdelfeeuudegtdeggfegheegudegleefiedtffekgfeiheejjeegnecuffhomhgrihhnpeigkeeipgeigedrshgspdefmhguvggsrdgtohhmnecukfhppeduvdejrddtrddtrddupddvudejrddujedurdeiuddrvdehpdefjedrheelrddugedvrddutddvnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepuddvjedrtddrtddruddpmhgrihhlfhhrohhmpehkrhihshhtihgrnhdrhhgvsggvlhesfehmuggvsgdrtghomhdpnhgspghrtghpthhtohepuddprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdpoffvtefjohhsthepmhhoheekgedpmhhouggvpehsmhhtphhouhht

This is a multi-part message in MIME format.
--------------v5bIFxATm5XUzPgaY5RAYWWB
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 8.02.2024 12:39, Jan Beulich wrote:
> On 14.11.2023 18:50, Krystian Hebel wrote:
>> CPU id is obtained as a side effect of searching for appropriate
>> stack for AP. It can be used as a parameter to start_secondary().
>> Coincidentally this also makes further work on making AP bring-up
>> code parallel easier.
> It's not just "easier", but strictly a prereq I think? Such a global
> would get in the way of having multiple CPUs make it into
> start_secondary() in parallel.
start_secondary() could also repeat what was done in assembly to get
that ID. This was what I've done in one of first attempts, and the commit
messagewas about removing that lookup loop which was squashed along the 
way and no longer applies. I'll reword it a bit.
>> --- a/xen/arch/x86/boot/x86_64.S
>> +++ b/xen/arch/x86/boot/x86_64.S
>> @@ -20,20 +20,24 @@ ENTRY(__high_start)
>>           jz      .L_stack_set
>>   
>>           /* APs only: get stack base from APIC ID saved in %esp. */
>> -        mov     $0, %rax
>> +        mov     $0, %rbx
>>           lea     cpu_data(%rip), %rcx
>>           /* cpu_data[0] is BSP, skip it. */
>>   1:
>> -        add     $1, %rax
>> +        add     $1, %rbx
>>           add     $CPUINFO_X86_sizeof, %rcx
>> -        cmp     $NR_CPUS, %eax
>> +        cmp     $NR_CPUS, %rbx
>>           jb      2f
>>           hlt
>>   2:
>>           cmp     %esp, CPUINFO_X86_apicid(%rcx)
>>           jne     1b
> Once again this is code you introduced a few patches ago. Why not use
> %ebx right away for that purpose? (And yes, this explains why in the
> earlier patch you retained that code. Just that again suitably ordering
> the series would make this look natural. Otherwise it needs at least
> mentioning why dead pieces are kept around.)
Will do.
>
>> -        /* %rcx is now cpu_data[cpu], read stack base from it. */
>> +        /*
>> +         * At this point:
>> +         * - %rcx is cpu_data[cpu], read stack base from it,
>> +         * - %rbx (callee-save) is Xen cpu number, pass it to start_secondary().
>> +         */
>>           mov     CPUINFO_X86_stack_base(%rcx), %rsp
>>   
>>           test    %rsp,%rsp
>> @@ -101,6 +105,7 @@ ENTRY(__high_start)
>>   .L_ap_cet_done:
>>   #endif /* CONFIG_XEN_SHSTK || CONFIG_XEN_IBT */
>>   
>> +        mov     %rbx, %rdi
>>           tailcall start_secondary
> As alluded to above and as mentioned before - please stick to 32-bit
> operations when you deal with 32 (or less) bits of data.
Ack
>
>> --- a/xen/arch/x86/smpboot.c
>> +++ b/xen/arch/x86/smpboot.c
>> @@ -222,8 +222,6 @@ static void smp_callin(void)
>>           cpu_relax();
>>   }
>>   
>> -static int booting_cpu;
>> -
>>   /* CPUs for which sibling maps can be computed. */
>>   static cpumask_t cpu_sibling_setup_map;
>>   
>> @@ -311,15 +309,14 @@ static void set_cpu_sibling_map(unsigned int cpu)
>>       }
>>   }
>>   
>> -void start_secondary(void *unused)
>> +void start_secondary(unsigned int cpu)
>>   {
>>       struct cpu_info *info = get_cpu_info();
>>   
>>       /*
>> -     * Dont put anything before smp_callin(), SMP booting is so fragile that we
>> +     * Don't put anything before smp_callin(), SMP booting is so fragile that we
>>        * want to limit the things done here to the most necessary things.
>>        */
>> -    unsigned int cpu = booting_cpu;
>>   
>>       /* Critical region without IDT or TSS.  Any fault is deadly! */
>>   
>> @@ -346,9 +343,9 @@ void start_secondary(void *unused)
>>        */
>>       spin_debug_disable();
>>   
>> -    get_cpu_info()->use_pv_cr3 = false;
>> -    get_cpu_info()->xen_cr3 = 0;
>> -    get_cpu_info()->pv_cr3 = 0;
>> +    info->use_pv_cr3 = false;
>> +    info->xen_cr3 = 0;
>> +    info->pv_cr3 = 0;
> This hunk looks unrelated. While tidying next to what's changed anyway
> may be okay if suitably mentioned in the description, in this case I
> think it needs splitting off.
OK, I'll split it off.
>
> Jan
Best regards,

-- 
Krystian Hebel
Firmware Engineer
https://3mdeb.com  | @3mdeb_com

--------------v5bIFxATm5XUzPgaY5RAYWWB
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  
    
  
  
    


    

    
On 8.02.2024 12:39, Jan Beulich wrote:

    

    

      
On 14.11.2023 18:50, Krystian Hebel wrote:


      

        
CPU id is obtained as a side effect of searching for appropriate
stack for AP. It can be used as a parameter to start_secondary().
Coincidentally this also makes further work on making AP bring-up
code parallel easier.


      

      
It's not just "easier", but strictly a prereq I think? Such a global
would get in the way of having multiple CPUs make it into
start_secondary() in parallel.

    

    start_secondary() could also repeat what was done in assembly to get

    that ID. This was what I've done in one of first attempts, and the
    commit

    message was about removing that lookup loop which was squashed along
the way and no longer applies. I'll reword it a bit.

    

      

      

        
--- a/xen/arch/x86/boot/x86_64.S
+++ b/xen/arch/x86/boot/x86_64.S
@@ -20,20 +20,24 @@ ENTRY(__high_start)
         jz      .L_stack_set
 
         /* APs only: get stack base from APIC ID saved in %esp. */
-        mov     $0, %rax
+        mov     $0, %rbx
         lea     cpu_data(%rip), %rcx
         /* cpu_data[0] is BSP, skip it. */
 1:
-        add     $1, %rax
+        add     $1, %rbx
         add     $CPUINFO_X86_sizeof, %rcx
-        cmp     $NR_CPUS, %eax
+        cmp     $NR_CPUS, %rbx
         jb      2f
         hlt
 2:
         cmp     %esp, CPUINFO_X86_apicid(%rcx)
         jne     1b


      

      
Once again this is code you introduced a few patches ago. Why not use
%ebx right away for that purpose? (And yes, this explains why in the
earlier patch you retained that code. Just that again suitably ordering
the series would make this look natural. Otherwise it needs at least
mentioning why dead pieces are kept around.)

    

    Will do.

    

      



      

        
-        /* %rcx is now cpu_data[cpu], read stack base from it. */
+        /*
+         * At this point:
+         * - %rcx is cpu_data[cpu], read stack base from it,
+         * - %rbx (callee-save) is Xen cpu number, pass it to start_secondary().
+         */
         mov     CPUINFO_X86_stack_base(%rcx), %rsp
 
         test    %rsp,%rsp
@@ -101,6 +105,7 @@ ENTRY(__high_start)
 .L_ap_cet_done:
 #endif /* CONFIG_XEN_SHSTK || CONFIG_XEN_IBT */
 
+        mov     %rbx, %rdi
         tailcall start_secondary


      

      
As alluded to above and as mentioned before - please stick to 32-bit
operations when you deal with 32 (or less) bits of data.

    

    Ack

    

      



      

        
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -222,8 +222,6 @@ static void smp_callin(void)
         cpu_relax();
 }
 
-static int booting_cpu;
-
 /* CPUs for which sibling maps can be computed. */
 static cpumask_t cpu_sibling_setup_map;
 
@@ -311,15 +309,14 @@ static void set_cpu_sibling_map(unsigned int cpu)
     }
 }
 
-void start_secondary(void *unused)
+void start_secondary(unsigned int cpu)
 {
     struct cpu_info *info = get_cpu_info();
 
     /*
-     * Dont put anything before smp_callin(), SMP booting is so fragile that we
+     * Don't put anything before smp_callin(), SMP booting is so fragile that we
      * want to limit the things done here to the most necessary things.
      */
-    unsigned int cpu = booting_cpu;
 
     /* Critical region without IDT or TSS.  Any fault is deadly! */
 
@@ -346,9 +343,9 @@ void start_secondary(void *unused)
      */
     spin_debug_disable();
 
-    get_cpu_info()->use_pv_cr3 = false;
-    get_cpu_info()->xen_cr3 = 0;
-    get_cpu_info()->pv_cr3 = 0;
+    info->use_pv_cr3 = false;
+    info->xen_cr3 = 0;
+    info->pv_cr3 = 0;


      

      
This hunk looks unrelated. While tidying next to what's changed anyway
may be okay if suitably mentioned in the description, in this case I
think it needs splitting off.

    

    OK, I'll split it off.

    

      

Jan

    

    Best regards,

    
-- 
Krystian Hebel
Firmware Engineer
https://3mdeb.com | @3mdeb_com

  


--------------v5bIFxATm5XUzPgaY5RAYWWB--


From xen-devel-bounces@lists.xenproject.org Tue Mar 12 16:26:17 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Mar 2024 16:26:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.691956.1078621 (Exim 4.92)
	(envelope-from )
	id 1rk4x7-0005kx-6A; Tue, 12 Mar 2024 16:26:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 691956.1078621; Tue, 12 Mar 2024 16:26:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rk4x7-0005kq-3E; Tue, 12 Mar 2024 16:26:09 +0000
Received: by outflank-mailman (input) for mailman id 691956;
 Tue, 12 Mar 2024 16:26:08 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rk4x6-0005fl-Nx
 for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 16:26:08 +0000
Received: from wfhigh4-smtp.messagingengine.com
 (wfhigh4-smtp.messagingengine.com [64.147.123.155])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 35fadccc-e08d-11ee-afdd-a90da7624cb6;
 Tue, 12 Mar 2024 17:26:01 +0100 (CET)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.48])
 by mailfhigh.west.internal (Postfix) with ESMTP id B13131800098;
 Tue, 12 Mar 2024 12:25:58 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162])
 by compute7.internal (MEProxy); Tue, 12 Mar 2024 12:25:59 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 12 Mar 2024 12:25:56 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 35fadccc-e08d-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:from:from:in-reply-to
	:in-reply-to:message-id:mime-version:references:reply-to:subject
	:subject:to:to; s=fm1; t=1710260758; x=1710347158; bh=qF84mesdWl
	/lEGSQYlkmAm+QzNjClBgQx5p+iDQh+vg=; b=FfQK9LIzkOJqaMKwDtuRJehC+s
	4fHEDLOEMNUPfMWk0fdeiilK94BFmMhB13NNOh1mbzHFZd6TV2szJcZwYzRBtmzD
	0j4RwOwR+ulNKDZJXsQzsqgaqKLSkTPbtFFxBQPHwJZqrDKh6Hb6KkOIalY2wHb0
	GJmFK5LNdUJSdP4HkwjrOL2vZe+T7VLwy7rV59poei7o+jB6bdVNB3Njn1OLGy/i
	2//7tvUMTadqWkX1BUO41rLD0A+8HZNCQuvPZHESfmkZ2uA+zcqBICA0rF40uZ9u
	thBXjmNQNL2fWgGb6WZ8y9iYn5v35lEDduQJydtGEQHJfad3LBJoyPzx1DlA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:feedback-id:feedback-id
	:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy
	:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1710260758; x=
	1710347158; bh=qF84mesdWl/lEGSQYlkmAm+QzNjClBgQx5p+iDQh+vg=; b=o
	IdrArvWUvA6ePny+nor9rLKE/1485d1TMywDzezP8X7C8L51/p0nqoPErh9RIpgW
	f6FDy0dWEdKpcg9/prgHaSdfpHA9jkE6YKJrD9YlPVqA6dWMwXIv9hH2jGMbGB/9
	RmSmemXGZU5njVGh1jWRkJIA5vknCFx82sZwk51gZcBT2vDCL99Y4Euxtnhjg0bm
	/oIW0h+0aQHKXRyVUNqcMIFAxGXvqseuykiYISuY1veWF8dJhL7ylftoohz562Tf
	D5uCvEdvcChccMG/XHeIKcrl66iqSmizczNA1E8y4wh7jXSiicxtG4aPttHWzNT0
	1DwBzBz4hy3o/4WV0pdIA==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrjeefgdekkecutefuodetggdotefrodftvf
    curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
    uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc
    fjughrpefhvfevufffkffojghfgggtgfesthekredtredtjeenucfhrhhomhepofgrrhgv
    khcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinh
    hvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepgfeu
    udehgfdvfeehhedujeehfeduveeugefhkefhheelgeevudetueeiudfggfffnecuvehluh
    hsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghk
    sehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
To: xen-devel@lists.xenproject.org
Cc: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Jan Beulich ,
	Paul Durrant ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v2 2/2] drivers/char: mark extra reserved device memory in memory map
Date: Tue, 12 Mar 2024 17:25:15 +0100
Message-ID: <20240312162541.384793-2-marmarek@invisiblethingslab.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20240312162541.384793-1-marmarek@invisiblethingslab.com>
References: <20240312162541.384793-1-marmarek@invisiblethingslab.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The IOMMU driver checks if RMRR/IVMD are marked as reserved in memory
map. This should be true for addresses coming from the firmware, but
when extra pages used by Xen itself are included in the mapping, those
are taken from usable RAM used. Mark those pages as reserved too.

Not marking the pages as reserved didn't caused issues before due to
another a bug in IOMMU driver code, that was fixed in 83afa3135830
("amd-vi: fix IVMD memory type checks").

Failing to reserve memory will lead to panic in IOMMU setup code. And
not including the page in IOMMU mapping will lead to broken console (due
to IOMMU faults). The pages chosen by the XHCI console driver should
still be usable by the CPU though, and the console code already can deal
with too slow console by dropping characters (and console not printing
anything is a special case of "slow"). When reserving fails print an error
message showing which pages failed and who requested them. This should
be enough hint to find why XHCI console doesn't work.

Fixes: 3a1a7b809ffa "drivers/char: mark DMA buffers as reserved for the XHCI"
Signed-off-by: Marek Marczykowski-Górecki 
---
Alternative error handling could be a panic, but with this version I
think it can be avoided. And not panicing gives a better chance to
actually see the error message (from the hopefully started dom0),
especially as the affected driver is the console one.

The reserve_e820_ram() is x86-specific. Is there some equivalent API for
ARM, or maybe even some abstract one? That said, I have no way to test
XHCI console on ARM, I don't know if such hardware even exists...

Changes in v2:
- move reserving to iommu_get_extra_reserved_device_memory() to cover
  all users of iommu_add_extra_reserved_device_memory()
- change error handling to not panic, as in this code layout it can skip
  sending the pages to the IOMMU driver
---
 xen/drivers/passthrough/iommu.c | 19 +++++++++++++++++++
 xen/include/xen/iommu.h         |  5 ++++-
 2 files changed, 23 insertions(+), 1 deletion(-)

diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index 03587c0cd680..a311a37a2a03 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -21,6 +21,9 @@
 #include 
 #include 
 #include 
+#ifdef CONFIG_X86
+#include 
+#endif
 
 unsigned int __read_mostly iommu_dev_iotlb_timeout = 1000;
 integer_param("iommu_dev_iotlb_timeout", iommu_dev_iotlb_timeout);
@@ -715,6 +718,22 @@ int __init iommu_get_extra_reserved_device_memory(iommu_grdm_t *func,
 
     for ( idx = 0; idx < nr_extra_reserved_ranges; idx++ )
     {
+#ifdef CONFIG_X86
+        if ( !reserve_e820_ram(
+                &e820,
+                pfn_to_paddr(extra_reserved_ranges[idx].start),
+                pfn_to_paddr(extra_reserved_ranges[idx].start +
+                             extra_reserved_ranges[idx].nr)) )
+        {
+            printk(XENLOG_ERR "Failed to reserve [%"PRIx64"-%"PRIx64") for %s, "
+                   "skipping IOMMU mapping for it, some functionality may be broken\n",
+                   pfn_to_paddr(extra_reserved_ranges[idx].start),
+                   pfn_to_paddr(extra_reserved_ranges[idx].start +
+                                extra_reserved_ranges[idx].nr),
+                   extra_reserved_ranges[idx].name);
+            continue;
+        }
+#endif
         ret = func(extra_reserved_ranges[idx].start,
                    extra_reserved_ranges[idx].nr,
                    extra_reserved_ranges[idx].sbdf.sbdf,
diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
index b7829dff4588..875eaeb90167 100644
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -324,7 +324,8 @@ struct iommu_ops {
 };
 
 /*
- * To be called by Xen internally, to register extra RMRR/IVMD ranges.
+ * To be called by Xen internally, to register extra RMRR/IVMD ranges for RAM
+ * pages.
  * Needs to be called before IOMMU initialization.
  */
 extern int iommu_add_extra_reserved_device_memory(unsigned long start,
@@ -334,6 +335,8 @@ extern int iommu_add_extra_reserved_device_memory(unsigned long start,
 /*
  * To be called by specific IOMMU driver during initialization,
  * to fetch ranges registered with iommu_add_extra_reserved_device_memory().
+ * This has a side effect of marking requested ranges as "reserverd" in the
+ * memory map.
  */
 extern int iommu_get_extra_reserved_device_memory(iommu_grdm_t *func,
                                                   void *ctxt);
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Mar 12 16:26:17 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Mar 2024 16:26:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.691955.1078611 (Exim 4.92)
	(envelope-from )
	id 1rk4x5-0005Wj-VH; Tue, 12 Mar 2024 16:26:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 691955.1078611; Tue, 12 Mar 2024 16:26:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rk4x5-0005Wc-Rt; Tue, 12 Mar 2024 16:26:07 +0000
Received: by outflank-mailman (input) for mailman id 691955;
 Tue, 12 Mar 2024 16:26:06 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rk4x4-0005WW-0t
 for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 16:26:06 +0000
Received: from wfout3-smtp.messagingengine.com
 (wfout3-smtp.messagingengine.com [64.147.123.146])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 34ec0686-e08d-11ee-a1ee-f123f15fe8a2;
 Tue, 12 Mar 2024 17:26:01 +0100 (CET)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.47])
 by mailfout.west.internal (Postfix) with ESMTP id A04A81C00107;
 Tue, 12 Mar 2024 12:25:55 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162])
 by compute6.internal (MEProxy); Tue, 12 Mar 2024 12:25:56 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 12 Mar 2024 12:25:53 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 34ec0686-e08d-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:from:from:in-reply-to
	:message-id:mime-version:reply-to:subject:subject:to:to; s=fm1;
	 t=1710260755; x=1710347155; bh=NwcXswoAPzQCq70LrrXUbpoKQWinPR2b
	G2OYKwUeiIk=; b=NdyzPkKfBUnMCRDXJkCF5Efyra+fwbVJBjS+/qpCdrw8U8f4
	+QLm6/ZkLwx70P8eQzOuGrt0eDN2P0WiZTSCu+nBmgHa3x+cxhdIV3Dw82V5EwN5
	tuN9waxgYPY5ZacOoPegaKWcaD8D0iFaNPu+I3rFpu6wb5zGvkos1crhpmm2KxaA
	IqkLe6OvINtXHvoo1OUeGRtdGOc7cYV86meh19WtRPPjI1cqY85MJY4pOoDmnJQm
	iclMOetVya90OvHhsRRde+DHTkhLx0w1Z8t1wWOCjeJyVKAN66daSj8/xCpg0PSD
	2CBEvG903l17JqRsdh2LpNIafV8YjNRE8PrD+g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:feedback-id:feedback-id
	:from:from:in-reply-to:message-id:mime-version:reply-to:subject
	:subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender
	:x-sasl-enc; s=fm1; t=1710260755; x=1710347155; bh=NwcXswoAPzQCq
	70LrrXUbpoKQWinPR2bG2OYKwUeiIk=; b=TrL+78tDNL6FQSO6FRdSMc+tja5Ce
	x0VchrnpX1r/M+hLHObz1k07WF1XfmGPSu6bfXkRCckD1wUleXs+l1onRAZFzW/e
	vHkT6QPb394eblf2pbGctHlKLrmL74iHzr5Rw/AqqRX7tamdZgp4kBCd0u8IyP3P
	tJMMHYFbxZRqnj2G/3iUOhdBpZmACmGj+1OcUoZKRK7FMcd5jhKslxW1fedmQhFq
	YrLVU1LyYfVB7DJNBBSl8Z5Q9tQeyPGawwgz2mNP/w6+hxuUwpnwCk0MZsL8m26k
	8ud0irLwN5gTMemH5HREfiZRUN4zrwZhJZwOEXPwHTv5JbcoH2lhDVW4A==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrjeefgdekkecutefuodetggdotefrodftvf
    curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
    uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc
    fjughrpefhvfevufffkffogggtgfesthekredtredtjeenucfhrhhomhepofgrrhgvkhcu
    ofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinhhvih
    hsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepleekhfdu
    leetleelleetteevfeefteffkeetteejheelgfegkeelgeehhfdthedvnecuvehluhhsth
    gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghksehi
    nhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
To: xen-devel@lists.xenproject.org
Cc: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini ,
	Wei Liu ,
	Paul Durrant ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v2 1/2] IOMMU: store name for extra reserved device memory
Date: Tue, 12 Mar 2024 17:25:14 +0100
Message-ID: <20240312162541.384793-1-marmarek@invisiblethingslab.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

It will be useful for error reporting in a subsequent patch.

Signed-off-by: Marek Marczykowski-Górecki 
---
New in v2
---
 xen/drivers/char/xhci-dbc.c     | 3 ++-
 xen/drivers/passthrough/iommu.c | 5 ++++-
 xen/include/xen/iommu.h         | 3 ++-
 3 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/xen/drivers/char/xhci-dbc.c b/xen/drivers/char/xhci-dbc.c
index 3bf389be7d0b..8e2037f1a5f7 100644
--- a/xen/drivers/char/xhci-dbc.c
+++ b/xen/drivers/char/xhci-dbc.c
@@ -1421,7 +1421,8 @@ void __init xhci_dbc_uart_init(void)
         iommu_add_extra_reserved_device_memory(
                 PFN_DOWN(virt_to_maddr(&dbc_dma_bufs)),
                 PFN_UP(sizeof(dbc_dma_bufs)),
-                uart->dbc.sbdf);
+                uart->dbc.sbdf,
+                "XHCI console");
         serial_register_uart(SERHND_XHCI, &dbc_uart_driver, &dbc_uart);
     }
 }
diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index 996c31be1284..03587c0cd680 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -682,6 +682,7 @@ struct extra_reserved_range {
     unsigned long start;
     unsigned long nr;
     pci_sbdf_t sbdf;
+    const char *name;
 };
 static unsigned int __initdata nr_extra_reserved_ranges;
 static struct extra_reserved_range __initdata
@@ -689,7 +690,8 @@ static struct extra_reserved_range __initdata
 
 int __init iommu_add_extra_reserved_device_memory(unsigned long start,
                                                   unsigned long nr,
-                                                  pci_sbdf_t sbdf)
+                                                  pci_sbdf_t sbdf,
+                                                  const char *name)
 {
     unsigned int idx;
 
@@ -700,6 +702,7 @@ int __init iommu_add_extra_reserved_device_memory(unsigned long start,
     extra_reserved_ranges[idx].start = start;
     extra_reserved_ranges[idx].nr = nr;
     extra_reserved_ranges[idx].sbdf = sbdf;
+    extra_reserved_ranges[idx].name = name;
 
     return 0;
 }
diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
index 9621459c63ee..b7829dff4588 100644
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -329,7 +329,8 @@ struct iommu_ops {
  */
 extern int iommu_add_extra_reserved_device_memory(unsigned long start,
                                                   unsigned long nr,
-                                                  pci_sbdf_t sbdf);
+                                                  pci_sbdf_t sbdf,
+                                                  const char *name);
 /*
  * To be called by specific IOMMU driver during initialization,
  * to fetch ranges registered with iommu_add_extra_reserved_device_memory().
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Mar 12 16:38:47 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Mar 2024 16:38:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.691962.1078631 (Exim 4.92)
	(envelope-from )
	id 1rk59F-0008Ee-8h; Tue, 12 Mar 2024 16:38:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 691962.1078631; Tue, 12 Mar 2024 16:38:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rk59F-0008EX-4W; Tue, 12 Mar 2024 16:38:41 +0000
Received: by outflank-mailman (input) for mailman id 691962;
 Tue, 12 Mar 2024 16:38:39 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rk59D-0008DI-UR
 for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 16:38:39 +0000
Received: from 19.mo584.mail-out.ovh.net (19.mo584.mail-out.ovh.net
 [87.98.179.66]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f9c0b63c-e08e-11ee-a1ee-f123f15fe8a2;
 Tue, 12 Mar 2024 17:38:37 +0100 (CET)
Received: from director4.ghost.mail-out.ovh.net (unknown [10.108.25.249])
 by mo584.mail-out.ovh.net (Postfix) with ESMTP id 4TvK8Y1pfgz15cX
 for ; Tue, 12 Mar 2024 16:38:37 +0000 (UTC)
Received: from ghost-submission-6684bf9d7b-wbs9r (unknown [10.108.42.86])
 by director4.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 79AF91FEA8;
 Tue, 12 Mar 2024 16:38:36 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.110])
 by ghost-submission-6684bf9d7b-wbs9r with ESMTPSA
 id dxkYGQyF8GX4ogIALcx4mA
 (envelope-from ); Tue, 12 Mar 2024 16:38:36 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f9c0b63c-e08e-11ee-a1ee-f123f15fe8a2
Authentication-Results:garm.ovh; auth=pass (GARM-110S0040affcde0-4687-4333-9f01-cb83c8e8805c,
                    0B6B113C544506A41C6EB031E0F94F2E66B6AEBC) smtp.auth=krystian.hebel@3mdeb.com
X-OVh-ClientIp:217.171.61.25
Message-ID: <848c6735-c700-4feb-bc0c-259d00147564@3mdeb.com>
Date: Tue, 12 Mar 2024 17:38:34 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 8/9] x86/smp: make cpu_state per-CPU
Content-Language: en-US
To: Jan Beulich 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu
 , xen-devel@lists.xenproject.org
References: 
 <52083114d4cbbc75f021e8c61763ad0e166cf05b.1699982111.git.krystian.hebel@3mdeb.com>
 
From: Krystian Hebel 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Ovh-Tracer-Id: 9587319183475124569
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedvledrjeefgdeltdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefkffggfgfuvfevfhfhjggtgfesthejredttddvjeenucfhrhhomhepmfhrhihsthhirghnucfjvggsvghluceokhhrhihsthhirghnrdhhvggsvghlseefmhguvggsrdgtohhmqeenucggtffrrghtthgvrhhnpeejuedvffefvdeuvdeffeduuddtjeetgeefffdugfdvkeehtedutefghfdtteejieenucffohhmrghinhepfehmuggvsgdrtghomhenucfkphepuddvjedrtddrtddruddpvddujedrudejuddriedurddvhedpfeejrdehledrudegvddruddutdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeduvdejrddtrddtrddupdhmrghilhhfrhhomhepkhhrhihsthhirghnrdhhvggsvghlseefmhguvggsrdgtohhmpdhnsggprhgtphhtthhopedupdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhgpdfovfetjfhoshhtpehmohehkeegpdhmohguvgepshhmthhpohhuth


On 8.02.2024 13:13, Jan Beulich wrote:
> On 14.11.2023 18:50, Krystian Hebel wrote:
>> This will be used for parallel AP bring-up.
>>
>> CPU_STATE_INIT changed direction.
> Nit: I think you mean "changes" as you describe what the patch does, not
> what has happened before. But ...
>
>> It was previously set by BSP and never
>> consumed by AP. Now it signals that AP got through assembly part of
>> initialization and waits for BSP to call notifiers that set up data
>> structures required for further initialization.
> ... all of this is, afaict, independent of what the title says the
> purpose of this patch is. Since the correctness of the state change
> adjustments doesn't look straightforward to prove, please split the
> mechanical change from the change to the actual logic.
Ack
>
>> --- a/xen/arch/x86/include/asm/cpufeature.h
>> +++ b/xen/arch/x86/include/asm/cpufeature.h
>> @@ -38,6 +38,7 @@ struct cpuinfo_x86 {
>>       unsigned int cpu_core_id;          /* core ID of each logical CPU */
>>       unsigned int compute_unit_id;      /* AMD compute unit ID of each logical CPU */
>>       void *stack_base;
>> +    unsigned int cpu_state;
>>       unsigned short x86_clflush_size;
>>   } __cacheline_aligned;
> Is there any reason this cannot be ordinary per-CPU data?
Probably not, will move it away.
>
>> --- a/xen/arch/x86/smpboot.c
>> +++ b/xen/arch/x86/smpboot.c
>> @@ -65,15 +65,18 @@ struct cpuinfo_x86 cpu_data[NR_CPUS] =
>>           { [0 ... NR_CPUS-1] .apicid = BAD_APICID };
>>   
>>   static int cpu_error;
>> -static enum cpu_state {
>> +enum cpu_state {
>>       CPU_STATE_DYING,    /* slave -> master: I am dying */
>>       CPU_STATE_DEAD,     /* slave -> master: I am completely dead */
>> -    CPU_STATE_INIT,     /* master -> slave: Early bringup phase 1 */
>> -    CPU_STATE_CALLOUT,  /* master -> slave: Early bringup phase 2 */
>> +    CPU_STATE_INIT,     /* slave -> master: Early bringup phase 1 completed */
>> +    CPU_STATE_CALLOUT,  /* master -> slave: Start early bringup phase 2 */
> It's not really clear to me whether the adding of "Start" on the 2nd line
> really adds value.
Ack
>
>>       CPU_STATE_CALLIN,   /* slave -> master: Completed phase 2 */
>>       CPU_STATE_ONLINE    /* master -> slave: Go fully online now. */
>> -} cpu_state;
>> -#define set_cpu_state(state) do { smp_mb(); cpu_state = (state); } while (0)
>> +};
>> +#define set_cpu_state(cpu, state) do { \
>> +    smp_mb(); \
>> +    cpu_data[cpu].cpu_state = (state); \
>> +} while (0)
> While you merely re-arrange it, I'd still like to ask: Does this really
> need to be smp_mb(), not just smp_wmb()?
Probably not, but I didn't want to change it, assuming there was a reason
that it used smp_wmb() in the first place.
>
>> @@ -320,6 +317,10 @@ void start_secondary(unsigned int cpu)
>>   
>>       /* Critical region without IDT or TSS.  Any fault is deadly! */
>>   
>> +    /* Wait until data set up by CPU_UP_PREPARE notifiers is ready. */
>> +    while ( cpu_data[cpu].cpu_state != CPU_STATE_CALLOUT )
>> +        cpu_relax();
> I'm afraid I don't understand the comment (and hence whether this loop
> is actually needed here): __cpu_up() is called only after those
> notifiers completed.
Yes, but broadcasted INIT-SIPI-SIPI sequence added in next patch will be
sent before that call is made, and consequently APs potentially can get
to this point before that data is set up.
>
>> @@ -1161,6 +1171,12 @@ void __init smp_prepare_cpus(void)
>>       cpu_data[0].stack_base = (void *)
>>                ((unsigned long)stack_start & ~(STACK_SIZE - 1));
>>   
>> +    /* Set state as CALLOUT so APs won't change it in initialize_cpu_data() */
>> +    boot_cpu_data.cpu_state = CPU_STATE_CALLOUT;
> This is actually one of the reasons I don't like you putting the item
> as a new field in struct cpuinfo_x86. Otherwise imo initialize_cpu_data()
> ought to gain a respective assertion.
I'll move it out.
>
> Jan
Best regards,

-- 
Krystian Hebel
Firmware Engineer
https://3mdeb.com | @3mdeb_com



From xen-devel-bounces@lists.xenproject.org Tue Mar 12 17:06:47 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Mar 2024 17:06:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.691968.1078644 (Exim 4.92)
	(envelope-from )
	id 1rk5aN-0004ZM-Gg; Tue, 12 Mar 2024 17:06:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 691968.1078644; Tue, 12 Mar 2024 17:06:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rk5aN-0004ZF-Cu; Tue, 12 Mar 2024 17:06:43 +0000
Received: by outflank-mailman (input) for mailman id 691968;
 Tue, 12 Mar 2024 17:06:41 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rk5aL-0004XR-Lb
 for xen-devel@lists.xen.org; Tue, 12 Mar 2024 17:06:41 +0000
Received: from mail.xenproject.org (mail.xenproject.org [104.130.215.37])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e17d0999-e092-11ee-a1ee-f123f15fe8a2;
 Tue, 12 Mar 2024 18:06:35 +0100 (CET)
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rk5a4-00076p-82; Tue, 12 Mar 2024 17:06:24 +0000
Received: from andrewcoop by xenbits.xenproject.org with local (Exim 4.92)
 (envelope-from )
 id 1rk5a4-0008O4-3V; Tue, 12 Mar 2024 17:06:24 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e17d0999-e092-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Date:Message-Id:Subject:CC:From:To:MIME-Version:
	Content-Transfer-Encoding:Content-Type;
	bh=AfZo3XOcoAXJlEN9X2007kw8Sb6C5Wi4aSkOYm6IUOg=; b=PhDizB+/T6X1h7iavdhDHou+y2
	WEM7+lKsVTeXL9eEUaU359q5Eq0hbHSluKrHwYzi3PmypfTJWDtHGtXZNFmP6sAg70DxlbiAP57QT
	U22fB5uM4e7wm+76wpEGlWJkT7APFdpHxfuhgbKQH93d05zoQppJpPNeLBf+M1DtuQzY=;
Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.509 (Entity 5.509)
To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
 xen-users@lists.xen.org, oss-security@lists.openwall.com
From: Xen.org security team 
CC: Xen.org security team 
Subject: Xen Security Advisory 452 v1 (CVE-2023-28746) - x86: Register
 File Data Sampling
Message-Id: 
Date: Tue, 12 Mar 2024 17:06:24 +0000

--=separator
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

            Xen Security Advisory CVE-2023-28746 / XSA-452

                   x86: Register File Data Sampling

ISSUE DESCRIPTION
=================

Intel have disclosed RFDS, Register File Data Sampling, affecting some
Atom cores.

This came from internal validation work.  There is no information
provided about how an attacker might go about inferring data from the
register files.

For more details, see:
  https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/register-file-data-sampling.html

IMPACT
======

An attacker might be able to infer the contents of data held previously
in floating point, vector and/or integer register files on the same
logical processor, including data from a more privileged context.

Note: None of the vulnerable processors support HyperThreading, so there
      is no instantaneous exposure of data from other threads.

VULNERABLE SYSTEMS
==================

Systems running all versions of Xen are affected.

RFDS is only known to affect certain Atom processors from Intel.  Other
Intel CPUs, and CPUs from other hardware vendors are not known to be
affected.

RFDS affects Atom processors between the Goldmont and Gracemont
microarchitectures.  This includes Alder Lake and Raptor Lake hybrid
client systems which have a mix of Gracemont and other types of cores.

MITIGATION
==========

There is no mitigation.

RESOLUTION
==========

Intel are producing microcode update to address the issue for in-support
CPUs.  This is done by extending the VERW instruction with more
scrubbing side effects.  Consult your dom0 OS vendor and/or hardware
vendor for updated microcode.

In addition to the microcode, changes are required in Xen to reposition
the VERW scrubbing and to activate it when necessary, as well as to
inform guest kernels of when the extra side effect is present and/or
when the system is believed to be not vulnerable.  The appropriate set
of patches does this.

Note that patches for released versions are generally prepared to
apply to the stable branches, and may not apply cleanly to the most
recent release tarball.  Downstreams are encouraged to update to the
tip of the stable branch before applying these patches.

xsa452/xsa452-?.patch           xen-unstable
xsa452/xsa452-4.18-?.patch      Xen 4.18.x
xsa452/xsa452-4.17-?.patch      Xen 4.17.x
xsa452/xsa452-4.16-?.patch      Xen 4.16.x
xsa452/xsa452-4.15-?.patch      Xen 4.15.x

$ sha256sum xsa452*/*
9365456e85fc04947206075cdfe4a805c3d628d7c1f5b8020785d8fd84c93aa9  xsa452/xsa452-1.patch
89ce3001975352a1321dc1577d9d14273e6b383080900881603339e5a860e1fd  xsa452/xsa452-2.patch
775a2d57b7aa8e2522cce61b1ddebd267e36218ecdcc0f678db7ed0ed1f54c21  xsa452/xsa452-3.patch
0e56da437f3ea30b97f79fa1d247561815625e152c963dd504f11082863eaa32  xsa452/xsa452-4.15-1.patch
184f2fe90b614e3e5c7056669ea6c829242058f5c00407a3db1e34bcd4fb4aed  xsa452/xsa452-4.15-2.patch
237e9aa65122ef4a18f57e44f6841a80e967deac90e251ce629cba6ea2f66030  xsa452/xsa452-4.15-3.patch
59d5ec14b784b6c4f9ce2bb6258cb91ee6233fc01761f27c655f4582bdeb6830  xsa452/xsa452-4.15-4.patch
946a8d80f7c11a03a26a045eb2ba4e03be7e739f04df72e5e1f67279e374136e  xsa452/xsa452-4.15-5.patch
6eba7f56a67a101c39e2345b53530a4036b2fad50f4b745e39f8da1d0bffcbd5  xsa452/xsa452-4.15-6.patch
326571a214f358787bc4af8c71d96ae6455a9da80da4d43358af282eebb51e4d  xsa452/xsa452-4.15-7.patch
5aca7cf8ca97dd735769fc4c154dab576461da7ec1838ad152e90ceebb5af60d  xsa452/xsa452-4.16-1.patch
c7167c270a28cb639a9b94b898e656123767c21d0951fe48404bbbcf7d2be151  xsa452/xsa452-4.16-2.patch
55d61becc38663c6756baceb919645bc2cb4794b517cd067f9b452822fe11ecf  xsa452/xsa452-4.16-3.patch
6e7a93935d1a4df2dea5d9a6542127feb5d662b33cc766587a713746e4992841  xsa452/xsa452-4.16-4.patch
ee4bbf1988a05cc00c51512d5f258d310f3d5f21d23094d4a7b9ca3cf55ffcde  xsa452/xsa452-4.16-5.patch
f44dc3d957eca731834d13c1b7bf31cadfee5c4d354dbdb1e6aa317063c26420  xsa452/xsa452-4.16-6.patch
520188698c87ebfd42457b8f22d62e20e715d1bf28bfe43f93fbac4479485b15  xsa452/xsa452-4.16-7.patch
5ee4fffcb0418d34ec03605cf507d7c24d82355716fde250d3fd01308c40b29f  xsa452/xsa452-4.17-1.patch
a4081d6329c9ba7dd95b2f693ef6cfa61ef3a6148b0e4279f2cc8648be98b1ca  xsa452/xsa452-4.17-2.patch
bd6364569bb1d2841df6e9dad2d0c0d859b5cab5046141ba6c54a53ab7cbef76  xsa452/xsa452-4.17-3.patch
9c7aedd1a4f1e3dab344dd4ac0438de3ab25079f6aaa8d2f1b384b8f6f2df770  xsa452/xsa452-4.17-4.patch
7886b2da37de7c8bb0ed1bd9e8f001dbc46aa8802152c315fa1141f76e09dc77  xsa452/xsa452-4.17-5.patch
01dd485e5b2130b85905187ef6351d2fb6514cefb0096db3f710bff4345b8c29  xsa452/xsa452-4.17-6.patch
f64109a3e0a2237cc4fabc94f680c96a82e71d037e9d263ee7782fef0895fa32  xsa452/xsa452-4.17-7.patch
2fa4d889fc193e4ddd46e570e8c37d59e89fd667db52afb912d692d2775b25d6  xsa452/xsa452-4.18-1.patch
a4081d6329c9ba7dd95b2f693ef6cfa61ef3a6148b0e4279f2cc8648be98b1ca  xsa452/xsa452-4.18-2.patch
d4f61f50c9c6c17888ae6a371a2bde95cfad92d4e72c5e3ca54638fb4cc6fcfa  xsa452/xsa452-4.18-3.patch
7922255f39744c75fa2e84c3971a27432b1f1f177ddb40647bdc753eacea412c  xsa452/xsa452-4.18-4.patch
b262adff116cb00c371b45cffffb111c4ca359490a27a69ad7482a1ae92ac173  xsa452/xsa452-4.18-5.patch
0c0830b81f60b5a5b4d6bd339410ab6f512276491d30881587361b9c9fb7d0ff  xsa452/xsa452-4.18-6.patch
4ab5a0106c4ffdf713ebd3059eccd07ae8589e0d8348413685ecf0ff7d7b2a05  xsa452/xsa452-4.18-7.patch
51c1561026f32415cf69a362cca33a14aa361f34ddce3785667d99d25e922488  xsa452/xsa452-4.patch
518da7d12c295851a1ae3a03cc28b290bc0e9dee4c4446d20d341c88c9908961  xsa452/xsa452-5.patch
$
-----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmXwhmMMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZfzUIALkcXm6t44EmYio/o6hUaxtx/V13QAANeTVss/V/
jRblCgWLw5hb39IToDmoDaX46fIxNDjAzT6GqOB/rnLHj9vNv15zVEsiAxgKPQXs
YQyYZQxKB/4kb24JG/KhPLBc1iQOXWmK9BmNdgHgOlC1fqXzYHInZsm69BZhs6Dk
nScFOeCaT/zvLybhehRioHFpNKkiFXSxZnIuj7IB9zkVrbS0YzZX9+H56Rs/VAuF
wTqoCdqSZ0F5KnWsXsnWCYfz3Sd/mTiT5qvFROPCqbfNClEnU7NzCd4Mz2/QVjJJ
LXhN/CrllJKWcpAcFW6Bx250uDC3/oSBfHNL/D+AsC/abcM=
=N4gH
-----END PGP SIGNATURE-----

--=separator
Content-Type: application/octet-stream; name="xsa452/xsa452-1.patch"
Content-Disposition: attachment; filename="xsa452/xsa452-1.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L3ZteDogUGVyZm9ybSBWRVJXIGZsdXNoaW5nIGxh
dGVyIGluIHRoZSBWTUV4aXQgcGF0aAoKQnJva2VuIG91dCBvZiB0aGUgZm9s
bG93aW5nIHBhdGNoIGJlY2F1c2UgdGhpcyBjaGFuZ2UgaXMgc3VidGxlIGVu
b3VnaCBvbiBpdHMKb3duLiAgU2VlIGl0IGZvciB0aGUgcmF0aW9uYWwgb2Yg
d2h5IHdlJ3JlIG1vdmluZyBWRVJXLgoKQXMgZm9yIGhvdywgZXh0ZW5kIHRo
ZSB0cmljayBhbHJlYWR5IHVzZWQgdG8gaG9sZCBvbmUgY29uZGl0aW9uIGlu
CmZsYWdzIChSRVNVTUUgdnMgTEFVTkNIKSB0aHJvdWdoIHRoZSBQT1Bpbmcg
b2YgR1BScy4KCk1vdmUgdGhlIE1PViBDUiBlYXJsaWVyLiAgSW50ZWwgc3Bl
Y2lmeSBmbGFncyB0byBiZSB1bmRlZmluZWQgYWNyb3NzIGl0LgoKRW5jb2Rl
IHRoZSB0d28gY29uZGl0aW9ucyB3ZSB3YW50IHVzaW5nIFNGIGFuZCBQRi4g
IFNlZSB0aGUgY29kZSBjb21tZW50IGZvcgpleGFjdGx5IGhvdy4KCkxlYXZl
IGEgY29tbWVudCB0byBleHBsYWluIHRoZSBsYWNrIG9mIGFueSBjb250ZW50
IGFyb3VuZApTUEVDX0NUUkxfRVhJVF9UT19WTVgsIGJ1dCBsZWF2ZSB0aGUg
YmxvY2sgaW4gcGxhY2UuICBTb2RzIGxhdyBzYXlzIGlmIHdlCmRlbGV0ZSBp
dCwgd2UnbGwgbmVlZCB0byByZWludHJvZHVjZSBpdC4KClRoaXMgaXMgcGFy
dCBvZiBYU0EtNDUyIC8gQ1ZFLTIwMjMtMjg3NDYuCgpTaWduZWQtb2ZmLWJ5
OiBBbmRyZXcgQ29vcGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPgpS
ZXZpZXdlZC1ieTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgoK
ZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9odm0vdm14L2VudHJ5LlMgYi94
ZW4vYXJjaC94ODYvaHZtL3ZteC9lbnRyeS5TCmluZGV4IGUzZjYwZDVhODJm
Ny4uMWJlYWQ4MjZjYWEzIDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYvaHZt
L3ZteC9lbnRyeS5TCisrKyBiL3hlbi9hcmNoL3g4Ni9odm0vdm14L2VudHJ5
LlMKQEAgLTg3LDE3ICs4NywzOSBAQCBVTkxJS0VMWV9FTkQocmVhbG1vZGUp
CiAKICAgICAgICAgLyogV0FSTklORyEgYHJldGAsIGBjYWxsICpgLCBgam1w
ICpgIG5vdCBzYWZlIGJleW9uZCB0aGlzIHBvaW50LiAqLwogICAgICAgICAv
KiBTUEVDX0NUUkxfRVhJVF9UT19WTVggICBSZXE6ICVyc3A9cmVncy9jcHVp
bmZvICAgICAgICAgICAgICBDbG9iOiAgICAqLwotICAgICAgICBET19TUEVD
X0NUUkxfQ09ORF9WRVJXCisgICAgICAgIC8qCisgICAgICAgICAqIEFsbCBz
cGVjdWxhdGlvbiBzYWZldHkgd29yayBoYXBwZW5zIHRvIGJlIGVsc2V3aGVy
ZS4gIFZFUlcgaXMgYWZ0ZXIKKyAgICAgICAgICogcG9wcGluZyB0aGUgR1BS
cywgd2hpbGUgcmVzdG9yaW5nIHRoZSBndWVzdCBNU1JfU1BFQ19DVFJMIGlz
IGxlZnQKKyAgICAgICAgICogdG8gdGhlIE1TUiBsb2FkIGxpc3QuCisgICAg
ICAgICAqLwogCiAgICAgICAgIG1vdiAgVkNQVV9odm1fZ3Vlc3RfY3IyKCVy
YngpLCVyYXgKKyAgICAgICAgbW92ICAlcmF4LCAlY3IyCisKKyAgICAgICAg
LyoKKyAgICAgICAgICogV2UgbmVlZCB0byBwZXJmb3JtIHR3byBjb25kaXRp
b25hbCBhY3Rpb25zIChWRVJXLCBhbmQgUmVzdW1lIHZzCisgICAgICAgICAq
IExhdW5jaCkgYWZ0ZXIgcG9wcGluZyBHUFJzLiAgV2l0aCBzb21lIGN1bm5p
bmcsIHdlIGNhbiBlbmNvZGUgYm90aAorICAgICAgICAgKiBvZiB0aGVzZSBp
biBlZmxhZ3MgdG9nZXRoZXIuCisgICAgICAgICAqCisgICAgICAgICAqIFBh
cml0eSBpcyBvbmx5IGNhbGN1bGF0ZWQgb3ZlciB0aGUgYm90dG9tIGJ5dGUg
b2YgdGhlIGFuc3dlciwgd2hpbGUKKyAgICAgICAgICogU2lnbiBpcyBzaW1w
bHkgdGhlIHRvcCBiaXQuCisgICAgICAgICAqCisgICAgICAgICAqIFRoZXJl
Zm9yZSwgdGhlIGZpbmFsIE9SIGluc3RydWN0aW9uIGVuZHMgdXAgcHJvZHVj
aW5nOgorICAgICAgICAgKiAgIFNGID0gVkNQVV92bXhfbGF1bmNoZWQKKyAg
ICAgICAgICogICBQRiA9ICFTQ0ZfdmVydworICAgICAgICAgKi8KKyAgICAg
ICAgQlVJTERfQlVHX09OKFNDRl92ZXJ3ICYgfjB4ZmYpCisgICAgICAgIG1v
dnpibCBWQ1BVX3ZteF9sYXVuY2hlZCglcmJ4KSwgJWVjeAorICAgICAgICBz
aGwgICQzMSwgJWVjeAorICAgICAgICBtb3Z6YmwgQ1BVSU5GT19zcGVjX2N0
cmxfZmxhZ3MoJXJzcCksICVlYXgKKyAgICAgICAgYW5kICAkU0NGX3Zlcncs
ICVlYXgKKyAgICAgICAgb3IgICAlZWF4LCAlZWN4CiAKICAgICAgICAgcG9w
ICAlcjE1CiAgICAgICAgIHBvcCAgJXIxNAogICAgICAgICBwb3AgICVyMTMK
ICAgICAgICAgcG9wICAlcjEyCiAgICAgICAgIHBvcCAgJXJicAotICAgICAg
ICBtb3YgICVyYXgsJWNyMgotICAgICAgICBjbXBiICQwLFZDUFVfdm14X2xh
dW5jaGVkKCVyYngpCiAgICAgICAgIHBvcCAgJXJieAogICAgICAgICBwb3Ag
ICVyMTEKICAgICAgICAgcG9wICAlcjEwCkBAIC0xMDgsNyArMTMwLDEzIEBA
IFVOTElLRUxZX0VORChyZWFsbW9kZSkKICAgICAgICAgcG9wICAlcmR4CiAg
ICAgICAgIHBvcCAgJXJzaQogICAgICAgICBwb3AgICVyZGkKLSAgICAgICAg
amUgICAuTHZteF9sYXVuY2gKKworICAgICAgICBqcGUgIC5MX3NraXBfdmVy
dworICAgICAgICAvKiBWRVJXIGNsb2JiZXJzIFpGLCBidXQgcHJlc2VydmVz
IGFsbCBvdGhlcnMsIGluY2x1ZGluZyBTRi4gKi8KKyAgICAgICAgdmVydyBT
VEtfUkVMKENQVUlORk9fdmVyd19zZWwsIENQVUlORk9fZXJyb3JfY29kZSko
JXJzcCkKKy5MX3NraXBfdmVydzoKKworICAgICAgICBqbnMgIC5Mdm14X2xh
dW5jaAogCiAvKi5Mdm14X3Jlc3VtZToqLwogICAgICAgICBWTVJFU1VNRQpk
aWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL3NwZWNfY3Ry
bF9hc20uaCBiL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9zcGVjX2N0cmxf
YXNtLmgKaW5kZXggYWVjYjkxZDg0ODk5Li5iYThlMGFlMjhiMWEgMTAwNjQ0
Ci0tLSBhL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9zcGVjX2N0cmxfYXNt
LmgKKysrIGIveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL3NwZWNfY3RybF9h
c20uaApAQCAtMTUyLDYgKzE1MiwxMyBAQAogI2VuZGlmCiAuZW5kbQogCisv
KgorICogSGVscGVyIHRvIGltcHJvdmUgdGhlIHJlYWRpYmlsaXR5IG9mIHN0
YWNrIGRpc3BhY2VtZW50cyB3aXRoICVyc3AgaW4KKyAqIHVudXN1YWwgcG9z
aXRpb25zLiAgQm90aCBAZmllbGQgYW5kIEB0b3Bfb2Zfc3RhY2sgc2hvdWxk
IGJlIGNvbnN0YW50cyBmcm9tCisgKiB0aGUgc2FtZSBvYmplY3QuICBAdG9w
X29mX3N0YWNrIHNob3VsZCBiZSB3aGVyZSAlcnNwIGlzIGN1cnJlbnRseSBw
b2ludGluZy4KKyAqLworI2RlZmluZSBTVEtfUkVMKGZpZWxkLCB0b3Bfb2Zf
c3RrKSAoKGZpZWxkKSAtICh0b3Bfb2Zfc3RrKSkKKwogLm1hY3JvIERPX1NQ
RUNfQ1RSTF9DT05EX1ZFUlcKIC8qCiAgKiBSZXF1aXJlcyAlcnNwPWNwdWlu
Zm8KZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni94ODZfNjQvYXNtLW9mZnNl
dHMuYyBiL3hlbi9hcmNoL3g4Ni94ODZfNjQvYXNtLW9mZnNldHMuYwppbmRl
eCAwMjI0MmE5YjczNjMuLjg2OTc0MDRjZDAwNyAxMDA2NDQKLS0tIGEveGVu
L2FyY2gveDg2L3g4Nl82NC9hc20tb2Zmc2V0cy5jCisrKyBiL3hlbi9hcmNo
L3g4Ni94ODZfNjQvYXNtLW9mZnNldHMuYwpAQCAtMTM1LDYgKzEzNSw3IEBA
IHZvaWQgX19kdW1teV9fKHZvaWQpCiAjZW5kaWYKIAogICAgIE9GRlNFVChD
UFVJTkZPX2d1ZXN0X2NwdV91c2VyX3JlZ3MsIHN0cnVjdCBjcHVfaW5mbywg
Z3Vlc3RfY3B1X3VzZXJfcmVncyk7CisgICAgT0ZGU0VUKENQVUlORk9fZXJy
b3JfY29kZSwgc3RydWN0IGNwdV9pbmZvLCBndWVzdF9jcHVfdXNlcl9yZWdz
LmVycm9yX2NvZGUpOwogICAgIE9GRlNFVChDUFVJTkZPX3Byb2Nlc3Nvcl9p
ZCwgc3RydWN0IGNwdV9pbmZvLCBwcm9jZXNzb3JfaWQpOwogICAgIE9GRlNF
VChDUFVJTkZPX3Zlcndfc2VsLCBzdHJ1Y3QgY3B1X2luZm8sIHZlcndfc2Vs
KTsKICAgICBPRkZTRVQoQ1BVSU5GT19jdXJyZW50X3ZjcHUsIHN0cnVjdCBj
cHVfaW5mbywgY3VycmVudF92Y3B1KTsKCg==

--=separator
Content-Type: application/octet-stream; name="xsa452/xsa452-2.patch"
Content-Disposition: attachment; filename="xsa452/xsa452-2.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L3NwZWMtY3RybDogUGVyZm9ybSBWRVJXIGZsdXNo
aW5nIGxhdGVyIGluIGV4aXQgcGF0aHMKCk9uIHBhcnRzIHZ1bG5lcmFibGUg
dG8gUkZEUywgVkVSVydzIHNpZGUgZWZmZWN0cyBhcmUgZXh0ZW5kZWQgdG8g
c2NydWIgYWxsCm5vbi1hcmNoaXRlY3R1cmFsIGVudHJpZXMgaW4gdmFyaW91
cyBQaHlzaWNhbCBSZWdpc3RlciBGaWxlcy4gIFRvIHJlbW92ZSBhbGwKb2Yg
WGVuJ3MgdmFsdWVzLCB0aGUgVkVSVyBtdXN0IGJlIGFmdGVyIHBvcHBpbmcg
dGhlIEdQUnMuCgpSZXdvcmsgU1BFQ19DVFJMX0NPTkRfVkVSVyB0byBkZWZh
dWx0IHRvIGFuIENQVUlORk9fZXJyb3JfY29kZSAlcnNwIHBvc2l0aW9uLApi
dXQgd2l0aCBvdmVycmlkZXMgZm9yIG90aGVyIGNvbnRleHRzLiAgSWRlbnRp
ZnkgdGhhdCBpdCBjbG9iYmVycyBlZmxhZ3M7IHRoaXMKaXMgcGFydGljdWxh
cmx5IHJlbGV2YW50IGZvciB0aGUgU1lTUkVUIHBhdGguCgpGb3IgdGhlIElT
VCBleGl0IHJldHVybiB0byBYZW4sIGhhdmUgdGhlIG1haW4gU1BFQ19DVFJM
X0VYSVRfVE9fWEVOIHB1dCBhCnNoYWRvdyBjb3B5IG9mIHNwZWNfY3RybF9m
bGFncywgYXMgR1BScyBjYW4ndCBiZSB1c2VkIGF0IHRoZSBwb2ludCB3ZSB3
YW50IHRvCmlzc3VlIHRoZSBWRVJXLgoKVGhpcyBpcyBwYXJ0IG9mIFhTQS00
NTIgLyBDVkUtMjAyMy0yODc0Ni4KClNpZ25lZC1vZmYtYnk6IEFuZHJldyBD
b29wZXIgPGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+ClJldmlld2VkLWJ5
OiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+CgpkaWZmIC0tZ2l0
IGEveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL3NwZWNfY3RybF9hc20uaCBi
L3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9zcGVjX2N0cmxfYXNtLmgKaW5k
ZXggYmE4ZTBhZTI4YjFhLi42Mjk1MThjYzY5MjUgMTAwNjQ0Ci0tLSBhL3hl
bi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9zcGVjX2N0cmxfYXNtLmgKKysrIGIv
eGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL3NwZWNfY3RybF9hc20uaApAQCAt
MTU5LDE2ICsxNTksMjMgQEAKICAqLwogI2RlZmluZSBTVEtfUkVMKGZpZWxk
LCB0b3Bfb2Zfc3RrKSAoKGZpZWxkKSAtICh0b3Bfb2Zfc3RrKSkKIAotLm1h
Y3JvIERPX1NQRUNfQ1RSTF9DT05EX1ZFUlcKKy5tYWNybyBTUEVDX0NUUkxf
Q09ORF9WRVJXIFwKKyAgICBzY2Y9U1RLX1JFTChDUFVJTkZPX3NwZWNfY3Ry
bF9mbGFncywgQ1BVSU5GT19lcnJvcl9jb2RlKSwgXAorICAgIHNlbD1TVEtf
UkVMKENQVUlORk9fdmVyd19zZWwsICAgICAgICBDUFVJTkZPX2Vycm9yX2Nv
ZGUpCiAvKgotICogUmVxdWlyZXMgJXJzcD1jcHVpbmZvCisgKiBSZXF1aXJl
cyBcc2NmIGFuZCBcc2VsIGFzICVyc3AtcmVsYXRpdmUgZXhwcmVzc2lvbnMK
KyAqIENsb2JiZXJzIGVmbGFncworICoKKyAqIFZFUlcgbmVlZHMgdG8gcnVu
IGFmdGVyIGd1ZXN0IEdQUnMgaGF2ZSBiZWVuIHJlc3RvcmVkLCB3aGVyZSBv
bmx5ICVyc3AgaXMKKyAqIGdvb2QgdG8gdXNlLiAgRGVmYXVsdCB0byBleHBl
Y3RpbmcgJXJzcCBwb2ludGluZyBhdCBDUFVJTkZPX2Vycm9yX2NvZGUuCisg
KiBDb250ZXh0cyB3aGVyZSB0aGlzIGlzIG5vdCB0cnVlIG11c3QgcHJvdmlk
ZSBhbiBhbHRlcm5hdGl2ZSBcc2NmIGFuZCBcc2VsLgogICoKICAqIElzc3Vl
IGEgVkVSVyBmb3IgaXRzIGZsdXNoaW5nIHNpZGUgZWZmZWN0LCBpZiBpbmRp
Y2F0ZWQuICBUaGlzIGlzIGEgU3BlY3RyZQogICogdjEgZ2FkZ2V0LCBidXQg
dGhlIElSRVQvVk1FbnRyeSBpcyBzZXJpYWxpc2luZy4KICAqLwotICAgIHRl
c3RiICRTQ0ZfdmVydywgQ1BVSU5GT19zcGVjX2N0cmxfZmxhZ3MoJXJzcCkK
KyAgICB0ZXN0YiAkU0NGX3ZlcncsIFxzY2YoJXJzcCkKICAgICBqeiAuTFxA
X3Zlcndfc2tpcAotICAgIHZlcncgQ1BVSU5GT192ZXJ3X3NlbCglcnNwKQor
ICAgIHZlcncgXHNlbCglcnNwKQogLkxcQF92ZXJ3X3NraXA6CiAuZW5kbQog
CkBAIC0yODYsOCArMjkzLDYgQEAKICAqLwogICAgIEFMVEVSTkFUSVZFICIi
LCBET19TUEVDX0NUUkxfRVhJVF9UT19HVUVTVCwgWDg2X0ZFQVRVUkVfU0Nf
TVNSX1BWCiAKLSAgICBET19TUEVDX0NUUkxfQ09ORF9WRVJXCi0KICAgICBB
TFRFUk5BVElWRSAiIiwgRE9fU1BFQ19DVFJMX0RJViwgWDg2X0ZFQVRVUkVf
U0NfRElWCiAuZW5kbQogCkBAIC0zNjcsNyArMzcyLDcgQEAgVU5MSUtFTFlf
RElTUEFUQ0hfTEFCRUwoXEBfc2VyaWFsaXNlKToKICAqLwogLm1hY3JvIFNQ
RUNfQ1RSTF9FWElUX1RPX1hFTgogLyoKLSAqIFJlcXVpcmVzICVyMTI9aXN0
X2V4aXQsICVyMTQ9c3RhY2tfZW5kCisgKiBSZXF1aXJlcyAlcjEyPWlzdF9l
eGl0LCAlcjE0PXN0YWNrX2VuZCwgJXJzcD1yZWdzCiAgKiBDbG9iYmVycyAl
cmF4LCAlcmJ4LCAlcmN4LCAlcmR4CiAgKi8KICAgICBtb3Z6YmwgU1RBQ0tf
Q1BVSU5GT19GSUVMRChzcGVjX2N0cmxfZmxhZ3MpKCVyMTQpLCAlZWJ4CkBA
IC0zOTUsMTEgKzQwMCwxOCBAQCBVTkxJS0VMWV9ESVNQQVRDSF9MQUJFTChc
QF9zZXJpYWxpc2UpOgogICAgIHRlc3QgJXIxMiwgJXIxMgogICAgIGp6IC5M
XEBfc2tpcF9pc3RfZXhpdAogCi0gICAgLyogTG9naWNhbGx5IERPX1NQRUNf
Q1RSTF9DT05EX1ZFUlcgYnV0IHdpdGhvdXQgdGhlICVyc3A9Y3B1aW5mbyBk
ZXBlbmRlbmN5ICovCi0gICAgdGVzdGIgJFNDRl92ZXJ3LCAlYmwKLSAgICBq
eiAuTFxAX3NraXBfdmVydwotICAgIHZlcncgU1RBQ0tfQ1BVSU5GT19GSUVM
RCh2ZXJ3X3NlbCkoJXIxNCkKLS5MXEBfc2tpcF92ZXJ3OgorICAgIC8qCisg
ICAgICogU3Rhc2ggU0NGIGFuZCB2ZXJ3X3NlbCBhYm92ZSBlZmxhZ3MgaW4g
dGhlIGNhc2Ugb2YgYW4gSVNUX2V4aXQuICBUaGUKKyAgICAgKiBWRVJXIGxv
Z2ljIG5lZWRzIHRvIHJ1biBhZnRlciBndWVzdCBHUFJzIGhhdmUgYmVlbiBy
ZXN0b3JlZDsgaS5lLiB3aGVyZQorICAgICAqIHdlIGNhbm5vdCB1c2UgJXIx
MiBvciAlcjE0IGZvciB0aGUgcHVycG9zZXMgdGhleSBoYXZlIGhlcmUuCisg
ICAgICoKKyAgICAgKiBXaGVuIHRoZSBDUFUgcHVzaGVkIHRoaXMgZXhjZXB0
aW9uIGZyYW1lLCBpdCB6ZXJvLWV4dGVuZGVkIGVmbGFncy4KKyAgICAgKiBU
aGVyZWZvcmUgaXQgaXMgc2FmZSBmb3IgdGhlIFZFUlcgbG9naWMgdG8gbG9v
ayBhdCB0aGUgc3Rhc2hlZCBTQ0YKKyAgICAgKiBvdXRzaWRlIG9mIHRoZSBp
c3RfZXhpdCBjb25kaXRpb24uICBBbHNvLCB0aGlzIHN0YXNoaW5nIHdvbid0
IGluZmx1ZW5jZQorICAgICAqIGFueSBvdGhlciByZXN0b3JlX2FsbF9ndWVz
dCgpIHBhdGhzLgorICAgICAqLworICAgIG9yICQoX19IWVBFUlZJU09SX0RT
MzIgPDwgMTYpLCAlZWJ4CisgICAgbW92ICVlYngsIFVSRUdTX2VmbGFncyAr
IDQoJXJzcCkgLyogRUZSQU1FX3NoYWRvd19zY2Yvc2VsICovCiAKICAgICBB
TFRFUk5BVElWRSAiIiwgRE9fU1BFQ19DVFJMX0RJViwgWDg2X0ZFQVRVUkVf
U0NfRElWCiAKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni94ODZfNjQvYXNt
LW9mZnNldHMuYyBiL3hlbi9hcmNoL3g4Ni94ODZfNjQvYXNtLW9mZnNldHMu
YwppbmRleCA4Njk3NDA0Y2QwMDcuLmQ4OTAzYTNjZTljNyAxMDA2NDQKLS0t
IGEveGVuL2FyY2gveDg2L3g4Nl82NC9hc20tb2Zmc2V0cy5jCisrKyBiL3hl
bi9hcmNoL3g4Ni94ODZfNjQvYXNtLW9mZnNldHMuYwpAQCAtNTUsMTQgKzU1
LDIyIEBAIHZvaWQgX19kdW1teV9fKHZvaWQpCiAgICAgICogRUZSQU1FXyog
aXMgZm9yIHRoZSBlbnRyeS9leGl0IGxvZ2ljIHdoZXJlICVyc3AgaXMgcG9p
bnRpbmcgYXQKICAgICAgKiBVUkVHU19lcnJvcl9jb2RlIGFuZCBHUFJzIGFy
ZSBzdGlsbC9hbHJlYWR5IGd1ZXN0IHZhbHVlcy4KICAgICAgKi8KLSNkZWZp
bmUgT0ZGU0VUX0VGKHN5bSwgbWVtKSAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIFwKKyNkZWZpbmUgT0ZGU0VUX0VGKHN5
bSwgbWVtLCAuLi4pICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIFwKICAgICBERUZJTkUoc3ltLCBvZmZzZXRvZihzdHJ1Y3QgY3B1
X3VzZXJfcmVncywgbWVtKSAtICAgICAgICAgICAgICAgICAgIFwKLSAgICAg
ICAgICAgICAgICBvZmZzZXRvZihzdHJ1Y3QgY3B1X3VzZXJfcmVncywgZXJy
b3JfY29kZSkpCisgICAgICAgICAgICAgICAgb2Zmc2V0b2Yoc3RydWN0IGNw
dV91c2VyX3JlZ3MsIGVycm9yX2NvZGUpIF9fVkFfQVJHU19fKQogCiAgICAg
T0ZGU0VUX0VGKEVGUkFNRV9lbnRyeV92ZWN0b3IsICAgIGVudHJ5X3ZlY3Rv
cik7CiAgICAgT0ZGU0VUX0VGKEVGUkFNRV9yaXAsICAgICAgICAgICAgIHJp
cCk7CiAgICAgT0ZGU0VUX0VGKEVGUkFNRV9jcywgICAgICAgICAgICAgIGNz
KTsKICAgICBPRkZTRVRfRUYoRUZSQU1FX2VmbGFncywgICAgICAgICAgZWZs
YWdzKTsKKworICAgIC8qCisgICAgICogVGhlc2UgYXJlbid0IHJlYWwgZmll
bGRzLiAgVGhleSdyZSBzcGFyZSBzcGFjZSwgdXNlZCBieSB0aGUgSVNUCisg
ICAgICogZXhpdC10by14ZW4gcGF0aC4KKyAgICAgKi8KKyAgICBPRkZTRVRf
RUYoRUZSQU1FX3NoYWRvd19zY2YsICAgICAgZWZsYWdzLCArNCk7CisgICAg
T0ZGU0VUX0VGKEVGUkFNRV9zaGFkb3dfc2VsLCAgICAgIGVmbGFncywgKzYp
OworCiAgICAgT0ZGU0VUX0VGKEVGUkFNRV9yc3AsICAgICAgICAgICAgIHJz
cCk7CiAgICAgQkxBTksoKTsKIApAQCAtMTM2LDYgKzE0NCw3IEBAIHZvaWQg
X19kdW1teV9fKHZvaWQpCiAKICAgICBPRkZTRVQoQ1BVSU5GT19ndWVzdF9j
cHVfdXNlcl9yZWdzLCBzdHJ1Y3QgY3B1X2luZm8sIGd1ZXN0X2NwdV91c2Vy
X3JlZ3MpOwogICAgIE9GRlNFVChDUFVJTkZPX2Vycm9yX2NvZGUsIHN0cnVj
dCBjcHVfaW5mbywgZ3Vlc3RfY3B1X3VzZXJfcmVncy5lcnJvcl9jb2RlKTsK
KyAgICBPRkZTRVQoQ1BVSU5GT19yaXAsIHN0cnVjdCBjcHVfaW5mbywgZ3Vl
c3RfY3B1X3VzZXJfcmVncy5yaXApOwogICAgIE9GRlNFVChDUFVJTkZPX3By
b2Nlc3Nvcl9pZCwgc3RydWN0IGNwdV9pbmZvLCBwcm9jZXNzb3JfaWQpOwog
ICAgIE9GRlNFVChDUFVJTkZPX3Zlcndfc2VsLCBzdHJ1Y3QgY3B1X2luZm8s
IHZlcndfc2VsKTsKICAgICBPRkZTRVQoQ1BVSU5GT19jdXJyZW50X3ZjcHUs
IHN0cnVjdCBjcHVfaW5mbywgY3VycmVudF92Y3B1KTsKZGlmZiAtLWdpdCBh
L3hlbi9hcmNoL3g4Ni94ODZfNjQvY29tcGF0L2VudHJ5LlMgYi94ZW4vYXJj
aC94ODYveDg2XzY0L2NvbXBhdC9lbnRyeS5TCmluZGV4IDk5NTFiM2UzMjhm
MC4uNjMxZjRmMjcyYWMzIDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYveDg2
XzY0L2NvbXBhdC9lbnRyeS5TCisrKyBiL3hlbi9hcmNoL3g4Ni94ODZfNjQv
Y29tcGF0L2VudHJ5LlMKQEAgLTE1OSw2ICsxNTksMTIgQEAgRlVOQyhjb21w
YXRfcmVzdG9yZV9hbGxfZ3Vlc3QpCiAgICAgICAgIFNQRUNfQ1RSTF9FWElU
X1RPX1BWICAgIC8qIFJlcTogYT1zcGVjX2N0cmwgJXJzcD1yZWdzL2NwdWlu
Zm8sIENsb2I6IGNkICovCiAKICAgICAgICAgUkVTVE9SRV9BTEwgYWRqPTgs
IGNvbXBhdD0xCisKKyAgICAgICAgLyogQWNjb3VudCBmb3IgZXYvZWMgaGF2
aW5nIGFscmVhZHkgYmVlbiBwb3BwZWQgb2ZmIHRoZSBzdGFjay4gKi8KKyAg
ICAgICAgU1BFQ19DVFJMX0NPTkRfVkVSVyBcCisgICAgICAgICAgICBzY2Y9
U1RLX1JFTChDUFVJTkZPX3NwZWNfY3RybF9mbGFncywgQ1BVSU5GT19yaXAp
LCBcCisgICAgICAgICAgICBzZWw9U1RLX1JFTChDUFVJTkZPX3Zlcndfc2Vs
LCAgICAgICAgQ1BVSU5GT19yaXApCisKIC5MZnQwOiAgaXJldHEKICAgICAg
ICAgX0FTTV9QUkVfRVhUQUJMRSguTGZ0MCwgaGFuZGxlX2V4Y2VwdGlvbikK
IEVORChjb21wYXRfcmVzdG9yZV9hbGxfZ3Vlc3QpCmRpZmYgLS1naXQgYS94
ZW4vYXJjaC94ODYveDg2XzY0L2VudHJ5LlMgYi94ZW4vYXJjaC94ODYveDg2
XzY0L2VudHJ5LlMKaW5kZXggMWI4NDZmM2FhZmYwLi43ZDY4NmI3NjI4MDcg
MTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni94ODZfNjQvZW50cnkuUworKysg
Yi94ZW4vYXJjaC94ODYveDg2XzY0L2VudHJ5LlMKQEAgLTIxMiw2ICsyMTIs
OSBAQCBGVU5DX0xPQ0FMKHJlc3RvcmVfYWxsX2d1ZXN0KQogI2VuZGlmCiAK
ICAgICAgICAgbW92ICAgRUZSQU1FX3JpcCglcnNwKSwgJXJjeAorCisgICAg
ICAgIFNQRUNfQ1RSTF9DT05EX1ZFUlcgICAgIC8qIFJlcTogJXJzcD1lZnJh
bWUgICAgICAgICAgICAgICAgICAgIENsb2I6IGVmbCAqLworCiAgICAgICAg
IGNtcHcgICRGTEFUX1VTRVJfQ1MzMiwgRUZSQU1FX2NzKCVyc3ApCiAgICAg
ICAgIG1vdiAgIEVGUkFNRV9yc3AoJXJzcCksICVyc3AKICAgICAgICAgamUg
ICAgMWYKQEAgLTIyNCw2ICsyMjcsOSBAQCBMQUJFTF9MT0NBTCguTHJlc3Rv
cmVfcmN4X2lyZXRfZXhpdF90b19ndWVzdCkKIGlyZXRfZXhpdF90b19ndWVz
dDoKICAgICAgICAgYW5kbCAgJH4oWDg2X0VGTEFHU19JT1BMIHwgWDg2X0VG
TEFHU19WTSksIEVGUkFNRV9lZmxhZ3MoJXJzcCkKICAgICAgICAgb3JsICAg
JFg4Nl9FRkxBR1NfSUYsIEVGUkFNRV9lZmxhZ3MoJXJzcCkKKworICAgICAg
ICBTUEVDX0NUUkxfQ09ORF9WRVJXICAgICAvKiBSZXE6ICVyc3A9ZWZyYW1l
ICAgICAgICAgICAgICAgICAgICBDbG9iOiBlZmwgKi8KKwogICAgICAgICBh
ZGRxICAkOCwlcnNwCiAuTGZ0MDogIGlyZXRxCiAgICAgICAgIF9BU01fUFJF
X0VYVEFCTEUoLkxmdDAsIGhhbmRsZV9leGNlcHRpb24pCkBAIC02ODgsOSAr
Njk0LDIyIEBAIFVOTElLRUxZX1NUQVJUKG5lLCBleGl0X2NyMykKIFVOTElL
RUxZX0VORChleGl0X2NyMykKIAogICAgICAgICAvKiBXQVJOSU5HISBgcmV0
YCwgYGNhbGwgKmAsIGBqbXAgKmAgbm90IHNhZmUgYmV5b25kIHRoaXMgcG9p
bnQuICovCi0gICAgICAgIFNQRUNfQ1RSTF9FWElUX1RPX1hFTiAgICAgLyog
UmVxOiAlcjEyPWlzdF9leGl0ICVyMTQ9ZW5kLCBDbG9iOiBhYmNkICovCisg
ICAgICAgIFNQRUNfQ1RSTF9FWElUX1RPX1hFTiAvKiBSZXE6ICVyMTI9aXN0
X2V4aXQgJXIxND1lbmQgJXJzcD1yZWdzLCBDbG9iOiBhYmNkICovCiAKICAg
ICAgICAgUkVTVE9SRV9BTEwgYWRqPTgKKworICAgICAgICAvKgorICAgICAg
ICAgKiBXaGVuIHRoZSBDUFUgcHVzaGVkIHRoaXMgZXhjZXB0aW9uIGZyYW1l
LCBpdCB6ZXJvLWV4dGVuZGVkIGVmbGFncy4KKyAgICAgICAgICogRm9yIGFu
IElTVCBleGl0LCBTUEVDX0NUUkxfRVhJVF9UT19YRU4gc3Rhc2hlZCBzaGFk
b3cgY29waWVzIG9mCisgICAgICAgICAqIHNwZWNfY3RybF9mbGFncyBhbmQg
dmVyX3NlbCBhYm92ZSBlZmxhZ3MsIGFzIHdlIGNhbid0IHVzZSBhbnkgR1BS
cywKKyAgICAgICAgICogYW5kIHdlJ3JlIGF0IGEgcmFuZG9tIHBsYWNlIG9u
IHRoZSBzdGFjaywgbm90IGluIGEgQ1BVRklORk8gYmxvY2suCisgICAgICAg
ICAqCisgICAgICAgICAqIEFjY291bnQgZm9yIGV2L2VjIGhhdmluZyBhbHJl
YWR5IGJlZW4gcG9wcGVkIG9mZiB0aGUgc3RhY2suCisgICAgICAgICAqLwor
ICAgICAgICBTUEVDX0NUUkxfQ09ORF9WRVJXIFwKKyAgICAgICAgICAgIHNj
Zj1TVEtfUkVMKEVGUkFNRV9zaGFkb3dfc2NmLCBFRlJBTUVfcmlwKSwgXAor
ICAgICAgICAgICAgc2VsPVNUS19SRUwoRUZSQU1FX3NoYWRvd19zZWwsIEVG
UkFNRV9yaXApCisKICAgICAgICAgaXJldHEKIEVORChyZXN0b3JlX2FsbF94
ZW4pCiAK

--=separator
Content-Type: application/octet-stream; name="xsa452/xsa452-3.patch"
Content-Disposition: attachment; filename="xsa452/xsa452-3.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L3NwZWMtY3RybDogUmVuYW1lIFZFUlcgcmVsYXRl
ZCBvcHRpb25zCgpWRVJXIGlzIGdvaW5nIHRvIGJlIHVzZWQgZm9yIGEgM3Jk
IHB1cnBvc2UsIGFuZCB0aGUgZXhpc3Rpbmcgbm9tZW5jbGF0dXJlCmRpZG4n
dCBzdXJ2aXZlIHRoZSBTdGFsZSBNTUlPIGlzc3VlcyB0ZXJyaWJseSB3ZWxs
LgoKUmVuYW1lIHRoZSBjb21tYW5kIGxpbmUgb3B0aW9uIGZyb20gYG1kLWNs
ZWFyPWAgdG8gYHZlcnc9YC4gIFRoaXMgaXMgbW9yZQpjb25zaXN0ZW50IHdp
dGggb3RoZXIgb3B0aW9ucyB3aGljaCB0ZW5kIHRvIGJlIG5hbWVkIGJhc2Vk
IG9uIHdoYXQgdGhleSdyZQpkb2luZywgbm90IHdoaWNoIGZlYXR1cmUgZW51
bWVyYXRpb24gdGhleSB1c2UgYmVoaW5kIHRoZSBzY2VuZXMuICBSZXRhaW4K
YG1kLWNsZWFyPWAgYXMgYSBkZXByZWNhdGVkIGFsaWFzLgoKUmVuYW1lIG9w
dF9tZF9jbGVhcl97cHYsaHZtfSBhbmQgb3B0X2ZiX2NsZWFyX21taW8gdG8g
b3B0X3Zlcndfe3B2LGh2bSxtbWlvfSwKd2hpY2ggaGFzIGEgc2lkZSBlZmZl
Y3Qgb2YgbWFraW5nIHNwZWNfY3RybF9pbml0X2RvbWFpbigpIHJhdGhlciBj
bGVhcmVyIHRvCmZvbGxvdy4KCk5vIGZ1bmN0aW9uYWwgY2hhbmdlLgoKVGhp
cyBpcyBwYXJ0IG9mIFhTQS00NTIgLyBDVkUtMjAyMy0yODc0Ni4KClNpZ25l
ZC1vZmYtYnk6IEFuZHJldyBDb29wZXIgPGFuZHJldy5jb29wZXIzQGNpdHJp
eC5jb20+ClJldmlld2VkLWJ5OiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3Vz
ZS5jb20+CgpkaWZmIC0tZ2l0IGEvZG9jcy9taXNjL3hlbi1jb21tYW5kLWxp
bmUucGFuZG9jIGIvZG9jcy9taXNjL3hlbi1jb21tYW5kLWxpbmUucGFuZG9j
CmluZGV4IDAyODk2NTk4ZGY2Zi4uYTU0ZDc3NTI4YWU5IDEwMDY0NAotLS0g
YS9kb2NzL21pc2MveGVuLWNvbW1hbmQtbGluZS5wYW5kb2MKKysrIGIvZG9j
cy9taXNjL3hlbi1jb21tYW5kLWxpbmUucGFuZG9jCkBAIC0yMzYzLDcgKzIz
NjMsNyBAQCBCeSBkZWZhdWx0IFNTQkQgd2lsbCBiZSBtaXRpZ2F0ZWQgYXQg
cnVudGltZSAoaS5lIGBzc2JkPXJ1bnRpbWVgKS4KIAogIyMjIHNwZWMtY3Ry
bCAoeDg2KQogPiBgPSBMaXN0IG9mIFsgPGJvb2w+LCB4ZW49PGJvb2w+LCB7
cHYsaHZtfT08Ym9vbD4sCi0+ICAgICAgICAgICAgICB7bXNyLXNjLHJzYixt
ZC1jbGVhcixpYnBiLWVudHJ5fT08Ym9vbD58e3B2LGh2bX09PGJvb2w+LAor
PiAgICAgICAgICAgICAge21zci1zYyxyc2IsdmVydyxpYnBiLWVudHJ5fT08
Ym9vbD58e3B2LGh2bX09PGJvb2w+LAogPiAgICAgICAgICAgICAgYnRpLXRo
dW5rPXJldHBvbGluZXxsZmVuY2V8am1wLCB7aWJycyxpYnBiLHNzYmQscHNm
ZCwKID4gICAgICAgICAgICAgIGVhZ2VyLWZwdSxsMWQtZmx1c2gsYnJhbmNo
LWhhcmRlbixzcmItbG9jaywKID4gICAgICAgICAgICAgIHVucHJpdi1tbWlv
LGdkcy1taXQsZGl2LXNjcnVifT08Ym9vbD4gXWAKQEAgLTIzODgsNyArMjM4
OCw3IEBAIGluIHBsYWNlIGZvciBndWVzdHMgdG8gdXNlLgogCiBVc2Ugb2Yg
YSBwb3NpdGl2ZSBib29sZWFuIHZhbHVlIGZvciBlaXRoZXIgb2YgdGhlc2Ug
b3B0aW9ucyBpcyBpbnZhbGlkLgogCi1UaGUgYHB2PWAsIGBodm09YCwgYG1z
ci1zYz1gLCBgcnNiPWAsIGBtZC1jbGVhcj1gIGFuZCBgaWJwYi1lbnRyeT1g
IG9wdGlvbnMKK1RoZSBgcHY9YCwgYGh2bT1gLCBgbXNyLXNjPWAsIGByc2I9
YCwgYHZlcnc9YCBhbmQgYGlicGItZW50cnk9YCBvcHRpb25zCiBvZmZlciBm
aW5lIGdyYWluZWQgY29udHJvbCBvdmVyIHRoZSBwcmltaXRpdmVzIGJ5IFhl
bi4gIFRoZXNlIGltcGFjdCBYZW4ncwogYWJpbGl0eSB0byBwcm90ZWN0IGl0
c2VsZiwgYW5kL29yIFhlbidzIGFiaWxpdHkgdG8gdmlydHVhbGlzZSBzdXBw
b3J0IGZvcgogZ3Vlc3RzIHRvIHVzZS4KQEAgLTI0MDUsMTEgKzI0MDUsMTIg
QEAgZ3Vlc3RzIHRvIHVzZS4KICAgZ3Vlc3RzIGFuZCBpZiBkaXNhYmxlZCwg
Z3Vlc3RzIHdpbGwgYmUgdW5hYmxlIHRvIHVzZSBJQlJTL1NUSUJQL1NTQkQv
ZXRjLgogKiBgcnNiPWAgb2ZmZXJzIGNvbnRyb2wgb3ZlciB3aGV0aGVyIHRv
IG92ZXJ3cml0ZSB0aGUgUmV0dXJuIFN0YWNrIEJ1ZmZlciAvCiAgIFJldHVy
biBBZGRyZXNzIFN0YWNrIG9uIGVudHJ5IHRvIFhlbiBhbmQgb24gaWRsZS4K
LSogYG1kLWNsZWFyPWAgb2ZmZXJzIGNvbnRyb2wgb3ZlciB3aGV0aGVyIHRv
IHVzZSBWRVJXIHRvIGZsdXNoCi0gIG1pY3JvYXJjaGl0ZWN0dXJhbCBidWZm
ZXJzIG9uIGlkbGUgYW5kIGV4aXQgZnJvbSBYZW4uICAqTm90ZTogRm9yCi0g
IGNvbXBhdGliaWxpdHkgd2l0aCBkZXZlbG9wbWVudCB2ZXJzaW9ucyBvZiB0
aGlzIGZpeCwgYG1kcz1gIGlzIGFsc28gYWNjZXB0ZWQKLSAgb24gWGVuIDQu
MTIgYW5kIGVhcmxpZXIgYXMgYW4gYWxpYXMuICBDb25zdWx0IHZlbmRvciBk
b2N1bWVudGF0aW9uIGluCi0gIHByZWZlcmVuY2UgdG8gaGVyZS4qCisqIGB2
ZXJ3PWAgb2ZmZXJzIGNvbnRyb2wgb3ZlciB3aGV0aGVyIHRvIHVzZSBWRVJX
IGZvciBpdHMgc2NydWJiaW5nIHNpZGUKKyAgZWZmZWN0cyBhdCBhcHByb3By
aWF0ZSBwcml2aWxlZ2UgdHJhbnNpdGlvbnMuICBUaGUgZXhhY3Qgc2lkZSBl
ZmZlY3RzIGFyZQorICBtaWNyb2FyY2hpdGVjdHVyZSBhbmQgbWljcm9jb2Rl
IHNwZWNpZmljLiAgKk5vdGU6IGBtZC1jbGVhcj1gIGlzIGFjY2VwdGVkIGFz
CisgIGEgZGVwcmVjYXRlZCBhbGlhcy4gIEZvciBjb21wYXRpYmlsaXR5IHdp
dGggZGV2ZWxvcG1lbnQgdmVyc2lvbnMgb2YgWFNBLTI5NywKKyAgYG1kcz1g
IGlzIGFsc28gYWNjZXB0ZWQgb24gWGVuIDQuMTIgYW5kIGVhcmxpZXIgYXMg
YW4gYWxpYXMuICBDb25zdWx0IHZlbmRvcgorICBkb2N1bWVudGF0aW9uIGlu
IHByZWZlcmVuY2UgdG8gaGVyZS4qCiAqIGBpYnBiLWVudHJ5PWAgb2ZmZXJz
IGNvbnRyb2wgb3ZlciB3aGV0aGVyIElCUEIgKEluZGlyZWN0IEJyYW5jaCBQ
cmVkaWN0aW9uCiAgIEJhcnJpZXIpIGlzIHVzZWQgb24gZW50cnkgdG8gWGVu
LiAgVGhpcyBpcyB1c2VkIGJ5IGRlZmF1bHQgb24gaGFyZHdhcmUKICAgdnVs
bmVyYWJsZSB0byBCcmFuY2ggVHlwZSBDb25mdXNpb24sIGFuZCBoYXJkd2Fy
ZSB2dWxuZXJhYmxlIHRvIFNwZWN1bGF0aXZlCmRpZmYgLS1naXQgYS94ZW4v
YXJjaC94ODYvc3BlY19jdHJsLmMgYi94ZW4vYXJjaC94ODYvc3BlY19jdHJs
LmMKaW5kZXggNzUyMjI1ZmFhNjI3Li45Y2VkZTUzNjFkMTQgMTAwNjQ0Ci0t
LSBhL3hlbi9hcmNoL3g4Ni9zcGVjX2N0cmwuYworKysgYi94ZW4vYXJjaC94
ODYvc3BlY19jdHJsLmMKQEAgLTI1LDggKzI1LDggQEAgc3RhdGljIGJvb2wg
X19pbml0ZGF0YSBvcHRfbXNyX3NjX3B2ID0gdHJ1ZTsKIHN0YXRpYyBib29s
IF9faW5pdGRhdGEgb3B0X21zcl9zY19odm0gPSB0cnVlOwogc3RhdGljIGlu
dDhfdCBfX2luaXRkYXRhIG9wdF9yc2JfcHYgPSAtMTsKIHN0YXRpYyBib29s
IF9faW5pdGRhdGEgb3B0X3JzYl9odm0gPSB0cnVlOwotc3RhdGljIGludDhf
dCBfX3JvX2FmdGVyX2luaXQgb3B0X21kX2NsZWFyX3B2ID0gLTE7Ci1zdGF0
aWMgaW50OF90IF9fcm9fYWZ0ZXJfaW5pdCBvcHRfbWRfY2xlYXJfaHZtID0g
LTE7CitzdGF0aWMgaW50OF90IF9fcm9fYWZ0ZXJfaW5pdCBvcHRfdmVyd19w
diA9IC0xOworc3RhdGljIGludDhfdCBfX3JvX2FmdGVyX2luaXQgb3B0X3Zl
cndfaHZtID0gLTE7CiAKIHN0YXRpYyBpbnQ4X3QgX19yb19hZnRlcl9pbml0
IG9wdF9pYnBiX2VudHJ5X3B2ID0gLTE7CiBzdGF0aWMgaW50OF90IF9fcm9f
YWZ0ZXJfaW5pdCBvcHRfaWJwYl9lbnRyeV9odm0gPSAtMTsKQEAgLTY2LDcg
KzY2LDcgQEAgc3RhdGljIGJvb2wgX19pbml0ZGF0YSBjcHVfaGFzX2J1Z19t
ZHM7IC8qIEFueSBvdGhlciBNe0xQLFNCLEZCfURTIGNvbWJpbmF0aW9uLgog
CiBzdGF0aWMgaW50OF90IF9faW5pdGRhdGEgb3B0X3NyYl9sb2NrID0gLTE7
CiBzdGF0aWMgYm9vbCBfX2luaXRkYXRhIG9wdF91bnByaXZfbW1pbzsKLXN0
YXRpYyBib29sIF9fcm9fYWZ0ZXJfaW5pdCBvcHRfZmJfY2xlYXJfbW1pbzsK
K3N0YXRpYyBib29sIF9fcm9fYWZ0ZXJfaW5pdCBvcHRfdmVyd19tbWlvOwog
c3RhdGljIGludDhfdCBfX2luaXRkYXRhIG9wdF9nZHNfbWl0ID0gLTE7CiBz
dGF0aWMgaW50OF90IF9faW5pdGRhdGEgb3B0X2Rpdl9zY3J1YiA9IC0xOwog
CkBAIC0xMDgsOCArMTA4LDggQEAgc3RhdGljIGludCBfX2luaXQgY2ZfY2hl
Y2sgcGFyc2Vfc3BlY19jdHJsKGNvbnN0IGNoYXIgKnMpCiAgICAgICAgIGRp
c2FibGVfY29tbW9uOgogICAgICAgICAgICAgb3B0X3JzYl9wdiA9IGZhbHNl
OwogICAgICAgICAgICAgb3B0X3JzYl9odm0gPSBmYWxzZTsKLSAgICAgICAg
ICAgIG9wdF9tZF9jbGVhcl9wdiA9IDA7Ci0gICAgICAgICAgICBvcHRfbWRf
Y2xlYXJfaHZtID0gMDsKKyAgICAgICAgICAgIG9wdF92ZXJ3X3B2ID0gMDsK
KyAgICAgICAgICAgIG9wdF92ZXJ3X2h2bSA9IDA7CiAgICAgICAgICAgICBv
cHRfaWJwYl9lbnRyeV9wdiA9IDA7CiAgICAgICAgICAgICBvcHRfaWJwYl9l
bnRyeV9odm0gPSAwOwogICAgICAgICAgICAgb3B0X2licGJfZW50cnlfZG9t
MCA9IGZhbHNlOwpAQCAtMTQwLDE0ICsxNDAsMTQgQEAgc3RhdGljIGludCBf
X2luaXQgY2ZfY2hlY2sgcGFyc2Vfc3BlY19jdHJsKGNvbnN0IGNoYXIgKnMp
CiAgICAgICAgIHsKICAgICAgICAgICAgIG9wdF9tc3Jfc2NfcHYgPSB2YWw7
CiAgICAgICAgICAgICBvcHRfcnNiX3B2ID0gdmFsOwotICAgICAgICAgICAg
b3B0X21kX2NsZWFyX3B2ID0gdmFsOworICAgICAgICAgICAgb3B0X3Zlcndf
cHYgPSB2YWw7CiAgICAgICAgICAgICBvcHRfaWJwYl9lbnRyeV9wdiA9IHZh
bDsKICAgICAgICAgfQogICAgICAgICBlbHNlIGlmICggKHZhbCA9IHBhcnNl
X2Jvb2xlYW4oImh2bSIsIHMsIHNzKSkgPj0gMCApCiAgICAgICAgIHsKICAg
ICAgICAgICAgIG9wdF9tc3Jfc2NfaHZtID0gdmFsOwogICAgICAgICAgICAg
b3B0X3JzYl9odm0gPSB2YWw7Ci0gICAgICAgICAgICBvcHRfbWRfY2xlYXJf
aHZtID0gdmFsOworICAgICAgICAgICAgb3B0X3ZlcndfaHZtID0gdmFsOwog
ICAgICAgICAgICAgb3B0X2licGJfZW50cnlfaHZtID0gdmFsOwogICAgICAg
ICB9CiAgICAgICAgIGVsc2UgaWYgKCAodmFsID0gcGFyc2VfYm9vbGVhbigi
bXNyLXNjIiwgcywgc3MpKSAhPSAtMSApCkBAIC0xOTIsMjEgKzE5MiwyMiBA
QCBzdGF0aWMgaW50IF9faW5pdCBjZl9jaGVjayBwYXJzZV9zcGVjX2N0cmwo
Y29uc3QgY2hhciAqcykKICAgICAgICAgICAgICAgICBicmVhazsKICAgICAg
ICAgICAgIH0KICAgICAgICAgfQotICAgICAgICBlbHNlIGlmICggKHZhbCA9
IHBhcnNlX2Jvb2xlYW4oIm1kLWNsZWFyIiwgcywgc3MpKSAhPSAtMSApCisg
ICAgICAgIGVsc2UgaWYgKCAodmFsID0gcGFyc2VfYm9vbGVhbigidmVydyIs
IHMsIHNzKSkgIT0gLTEgfHwKKyAgICAgICAgICAgICAgICAgICh2YWwgPSBw
YXJzZV9ib29sZWFuKCJtZC1jbGVhciIsIHMsIHNzKSkgIT0gLTEgKQogICAg
ICAgICB7CiAgICAgICAgICAgICBzd2l0Y2ggKCB2YWwgKQogICAgICAgICAg
ICAgewogICAgICAgICAgICAgY2FzZSAwOgogICAgICAgICAgICAgY2FzZSAx
OgotICAgICAgICAgICAgICAgIG9wdF9tZF9jbGVhcl9wdiA9IG9wdF9tZF9j
bGVhcl9odm0gPSB2YWw7CisgICAgICAgICAgICAgICAgb3B0X3ZlcndfcHYg
PSBvcHRfdmVyd19odm0gPSB2YWw7CiAgICAgICAgICAgICAgICAgYnJlYWs7
CiAKICAgICAgICAgICAgIGNhc2UgLTI6Ci0gICAgICAgICAgICAgICAgcyAr
PSBzdHJsZW4oIm1kLWNsZWFyPSIpOworICAgICAgICAgICAgICAgIHMgKz0g
KCpzID09ICd2JykgPyBzdHJsZW4oInZlcnc9IikgOiBzdHJsZW4oIm1kLWNs
ZWFyPSIpOwogICAgICAgICAgICAgICAgIGlmICggKHZhbCA9IHBhcnNlX2Jv
b2xlYW4oInB2Iiwgcywgc3MpKSA+PSAwICkKLSAgICAgICAgICAgICAgICAg
ICAgb3B0X21kX2NsZWFyX3B2ID0gdmFsOworICAgICAgICAgICAgICAgICAg
ICBvcHRfdmVyd19wdiA9IHZhbDsKICAgICAgICAgICAgICAgICBlbHNlIGlm
ICggKHZhbCA9IHBhcnNlX2Jvb2xlYW4oImh2bSIsIHMsIHNzKSkgPj0gMCAp
Ci0gICAgICAgICAgICAgICAgICAgIG9wdF9tZF9jbGVhcl9odm0gPSB2YWw7
CisgICAgICAgICAgICAgICAgICAgIG9wdF92ZXJ3X2h2bSA9IHZhbDsKICAg
ICAgICAgICAgICAgICBlbHNlCiAgICAgICAgICAgICBkZWZhdWx0OgogICAg
ICAgICAgICAgICAgICAgICByYyA9IC1FSU5WQUw7CkBAIC01MjgsOCArNTI5
LDggQEAgc3RhdGljIHZvaWQgX19pbml0IHByaW50X2RldGFpbHMoZW51bSBp
bmRfdGh1bmsgdGh1bmspCiAgICAgICAgICAgIG9wdF9zcmJfbG9jayAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgID8gIiBTUkJfTE9DSysiIDogIiBT
UkJfTE9DSy0iLAogICAgICAgICAgICBvcHRfaWJwYl9jdHh0X3N3aXRjaCAg
ICAgICAgICAgICAgICAgICAgICA/ICIgSUJQQi1jdHh0IiA6ICIiLAogICAg
ICAgICAgICBvcHRfbDFkX2ZsdXNoICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICA/ICIgTDFEX0ZMVVNIIiA6ICIiLAotICAgICAgICAgICBvcHRfbWRf
Y2xlYXJfcHYgfHwgb3B0X21kX2NsZWFyX2h2bSB8fAotICAgICAgICAgICBv
cHRfZmJfY2xlYXJfbW1pbyAgICAgICAgICAgICAgICAgICAgICAgICA/ICIg
VkVSVyIgIDogIiIsCisgICAgICAgICAgIG9wdF92ZXJ3X3B2IHx8IG9wdF92
ZXJ3X2h2bSB8fAorICAgICAgICAgICBvcHRfdmVyd19tbWlvICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICA/ICIgVkVSVyIgIDogIiIsCiAgICAgICAg
ICAgIG9wdF9kaXZfc2NydWIgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ID8gIiBESVYiIDogIiIsCiAgICAgICAgICAgIG9wdF9icmFuY2hfaGFyZGVu
ICAgICAgICAgICAgICAgICAgICAgICAgID8gIiBCUkFOQ0hfSEFSREVOIiA6
ICIiKTsKIApAQCAtNTUwLDEzICs1NTEsMTMgQEAgc3RhdGljIHZvaWQgX19p
bml0IHByaW50X2RldGFpbHMoZW51bSBpbmRfdGh1bmsgdGh1bmspCiAgICAg
ICAgICAgICBib290X2NwdV9oYXMoWDg2X0ZFQVRVUkVfU0NfUlNCX0hWTSkg
fHwKICAgICAgICAgICAgIGJvb3RfY3B1X2hhcyhYODZfRkVBVFVSRV9JQlBC
X0VOVFJZX0hWTSkgfHwKICAgICAgICAgICAgIGFtZF92aXJ0X3NwZWNfY3Ry
bCB8fAotICAgICAgICAgICAgb3B0X2VhZ2VyX2ZwdSB8fCBvcHRfbWRfY2xl
YXJfaHZtKSAgICAgICA/ICIiICAgICAgICAgICAgICAgOiAiIE5vbmUiLAor
ICAgICAgICAgICAgb3B0X2VhZ2VyX2ZwdSB8fCBvcHRfdmVyd19odm0pICAg
ICAgICAgICA/ICIiICAgICAgICAgICAgICAgOiAiIE5vbmUiLAogICAgICAg
ICAgICBib290X2NwdV9oYXMoWDg2X0ZFQVRVUkVfU0NfTVNSX0hWTSkgICAg
ICA/ICIgTVNSX1NQRUNfQ1RSTCIgOiAiIiwKICAgICAgICAgICAgKGJvb3Rf
Y3B1X2hhcyhYODZfRkVBVFVSRV9TQ19NU1JfSFZNKSB8fAogICAgICAgICAg
ICAgYW1kX3ZpcnRfc3BlY19jdHJsKSAgICAgICAgICAgICAgICAgICAgICA/
ICIgTVNSX1ZJUlRfU1BFQ19DVFJMIiA6ICIiLAogICAgICAgICAgICBib290
X2NwdV9oYXMoWDg2X0ZFQVRVUkVfU0NfUlNCX0hWTSkgICAgICA/ICIgUlNC
IiAgICAgICAgICAgOiAiIiwKICAgICAgICAgICAgb3B0X2VhZ2VyX2ZwdSAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgPyAiIEVBR0VSX0ZQVSIgICAg
IDogIiIsCi0gICAgICAgICAgIG9wdF9tZF9jbGVhcl9odm0gICAgICAgICAg
ICAgICAgICAgICAgICAgID8gIiBNRF9DTEVBUiIgICAgICA6ICIiLAorICAg
ICAgICAgICBvcHRfdmVyd19odm0gICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICA/ICIgVkVSVyIgICAgICAgICAgOiAiIiwKICAgICAgICAgICAgYm9v
dF9jcHVfaGFzKFg4Nl9GRUFUVVJFX0lCUEJfRU5UUllfSFZNKSAgPyAiIElC
UEItZW50cnkiICAgIDogIiIpOwogCiAjZW5kaWYKQEAgLTU2NSwxMSArNTY2
LDExIEBAIHN0YXRpYyB2b2lkIF9faW5pdCBwcmludF9kZXRhaWxzKGVudW0g
aW5kX3RodW5rIHRodW5rKQogICAgICAgICAgICAoYm9vdF9jcHVfaGFzKFg4
Nl9GRUFUVVJFX1NDX01TUl9QVikgfHwKICAgICAgICAgICAgIGJvb3RfY3B1
X2hhcyhYODZfRkVBVFVSRV9TQ19SU0JfUFYpIHx8CiAgICAgICAgICAgICBi
b290X2NwdV9oYXMoWDg2X0ZFQVRVUkVfSUJQQl9FTlRSWV9QVikgfHwKLSAg
ICAgICAgICAgIG9wdF9lYWdlcl9mcHUgfHwgb3B0X21kX2NsZWFyX3B2KSAg
ICAgICAgPyAiIiAgICAgICAgICAgICAgIDogIiBOb25lIiwKKyAgICAgICAg
ICAgIG9wdF9lYWdlcl9mcHUgfHwgb3B0X3ZlcndfcHYpICAgICAgICAgICAg
PyAiIiAgICAgICAgICAgICAgIDogIiBOb25lIiwKICAgICAgICAgICAgYm9v
dF9jcHVfaGFzKFg4Nl9GRUFUVVJFX1NDX01TUl9QVikgICAgICAgPyAiIE1T
Ul9TUEVDX0NUUkwiIDogIiIsCiAgICAgICAgICAgIGJvb3RfY3B1X2hhcyhY
ODZfRkVBVFVSRV9TQ19SU0JfUFYpICAgICAgID8gIiBSU0IiICAgICAgICAg
ICA6ICIiLAogICAgICAgICAgICBvcHRfZWFnZXJfZnB1ICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICA/ICIgRUFHRVJfRlBVIiAgICAgOiAiIiwKLSAg
ICAgICAgICAgb3B0X21kX2NsZWFyX3B2ICAgICAgICAgICAgICAgICAgICAg
ICAgICAgPyAiIE1EX0NMRUFSIiAgICAgIDogIiIsCisgICAgICAgICAgIG9w
dF92ZXJ3X3B2ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgID8gIiBW
RVJXIiAgICAgICAgICA6ICIiLAogICAgICAgICAgICBib290X2NwdV9oYXMo
WDg2X0ZFQVRVUkVfSUJQQl9FTlRSWV9QVikgICA/ICIgSUJQQi1lbnRyeSIg
ICAgOiAiIik7CiAKICAgICBwcmludGsoIiAgWFBUSSAoNjQtYml0IFBWIG9u
bHkpOiBEb20wICVzLCBEb21VICVzICh3aXRoJXMgUENJRClcbiIsCkBAIC0x
NTAyLDggKzE1MDMsOCBAQCB2b2lkIHNwZWNfY3RybF9pbml0X2RvbWFpbihz
dHJ1Y3QgZG9tYWluICpkKQogewogICAgIGJvb2wgcHYgPSBpc19wdl9kb21h
aW4oZCk7CiAKLSAgICBib29sIHZlcncgPSAoKHB2ID8gb3B0X21kX2NsZWFy
X3B2IDogb3B0X21kX2NsZWFyX2h2bSkgfHwKLSAgICAgICAgICAgICAgICAg
KG9wdF9mYl9jbGVhcl9tbWlvICYmIGlzX2lvbW11X2VuYWJsZWQoZCkpKTsK
KyAgICBib29sIHZlcncgPSAoKHB2ID8gb3B0X3ZlcndfcHYgOiBvcHRfdmVy
d19odm0pIHx8CisgICAgICAgICAgICAgICAgIChvcHRfdmVyd19tbWlvICYm
IGlzX2lvbW11X2VuYWJsZWQoZCkpKTsKIAogICAgIGJvb2wgaWJwYiA9ICgo
cHYgPyBvcHRfaWJwYl9lbnRyeV9wdiA6IG9wdF9pYnBiX2VudHJ5X2h2bSkg
JiYKICAgICAgICAgICAgICAgICAgKGQtPmRvbWFpbl9pZCAhPSAwIHx8IG9w
dF9pYnBiX2VudHJ5X2RvbTApKTsKQEAgLTE4NjYsMTkgKzE4NjcsMjAgQEAg
dm9pZCBfX2luaXQgaW5pdF9zcGVjdWxhdGlvbl9taXRpZ2F0aW9ucyh2b2lk
KQogICAgICAqIHRoZSByZXR1cm4tdG8tZ3Vlc3QgcGF0aC4KICAgICAgKi8K
ICAgICBpZiAoIG9wdF91bnByaXZfbW1pbyApCi0gICAgICAgIG9wdF9mYl9j
bGVhcl9tbWlvID0gY3B1X2hhc19mYl9jbGVhcjsKKyAgICAgICAgb3B0X3Zl
cndfbW1pbyA9IGNwdV9oYXNfZmJfY2xlYXI7CiAKICAgICAvKgogICAgICAq
IEJ5IGRlZmF1bHQsIGVuYWJsZSBQViBhbmQgSFZNIG1pdGlnYXRpb25zIG9u
IE1EUy12dWxuZXJhYmxlIGhhcmR3YXJlLgogICAgICAqIFRoaXMgd2lsbCBv
bmx5IGJlIGEgdG9rZW4gZWZmb3J0IGZvciBNTFBEUy9NRkJEUyB3aGVuIEhU
IGlzIGVuYWJsZWQsCiAgICAgICogYnV0IGl0IGlzIHNvbWV3aGF0IGJldHRl
ciB0aGFuIG5vdGhpbmcuCiAgICAgICovCi0gICAgaWYgKCBvcHRfbWRfY2xl
YXJfcHYgPT0gLTEgKQotICAgICAgICBvcHRfbWRfY2xlYXJfcHYgPSAoKGNw
dV9oYXNfYnVnX21kcyB8fCBjcHVfaGFzX2J1Z19tc2Jkc19vbmx5KSAmJgot
ICAgICAgICAgICAgICAgICAgICAgICAgICAgYm9vdF9jcHVfaGFzKFg4Nl9G
RUFUVVJFX01EX0NMRUFSKSk7Ci0gICAgaWYgKCBvcHRfbWRfY2xlYXJfaHZt
ID09IC0xICkKLSAgICAgICAgb3B0X21kX2NsZWFyX2h2bSA9ICgoY3B1X2hh
c19idWdfbWRzIHx8IGNwdV9oYXNfYnVnX21zYmRzX29ubHkpICYmCi0gICAg
ICAgICAgICAgICAgICAgICAgICAgICAgYm9vdF9jcHVfaGFzKFg4Nl9GRUFU
VVJFX01EX0NMRUFSKSk7CisgICAgaWYgKCBvcHRfdmVyd19wdiA9PSAtMSAp
CisgICAgICAgIG9wdF92ZXJ3X3B2ID0gKChjcHVfaGFzX2J1Z19tZHMgfHwg
Y3B1X2hhc19idWdfbXNiZHNfb25seSkgJiYKKyAgICAgICAgICAgICAgICAg
ICAgICAgY3B1X2hhc19tZF9jbGVhcik7CisKKyAgICBpZiAoIG9wdF92ZXJ3
X2h2bSA9PSAtMSApCisgICAgICAgIG9wdF92ZXJ3X2h2bSA9ICgoY3B1X2hh
c19idWdfbWRzIHx8IGNwdV9oYXNfYnVnX21zYmRzX29ubHkpICYmCisgICAg
ICAgICAgICAgICAgICAgICAgICBjcHVfaGFzX21kX2NsZWFyKTsKIAogICAg
IC8qCiAgICAgICogRW5hYmxlIE1EUy9NTUlPIGRlZmVuY2VzIGFzIGFwcGxp
Y2FibGUuICBUaGUgSWRsZSBibG9ja3MgbmVlZCB1c2luZyBpZgpAQCAtMTg5
MSwxMiArMTg5MywxMiBAQCB2b2lkIF9faW5pdCBpbml0X3NwZWN1bGF0aW9u
X21pdGlnYXRpb25zKHZvaWQpCiAgICAgICogTURTIG1pdGlnYXRpb25zLiAg
TDFEX0ZMVVNIIGlzIG5vdCBzYWZlIGZvciBNTUlPIG1pdGlnYXRpb25zLikK
ICAgICAgKgogICAgICAqIEFmdGVyIGNhbGN1bGF0aW5nIHRoZSBhcHByb3By
aWF0ZSBpZGxlIHNldHRpbmcsIHNpbXBsaWZ5Ci0gICAgICogb3B0X21kX2Ns
ZWFyX2h2bSB0byBtZWFuIGp1c3QgInNob3VsZCB3ZSBWRVJXIG9uIHRoZSB3
YXkgaW50byBIVk0KKyAgICAgKiBvcHRfdmVyd19odm0gdG8gbWVhbiBqdXN0
ICJzaG91bGQgd2UgVkVSVyBvbiB0aGUgd2F5IGludG8gSFZNCiAgICAgICog
Z3Vlc3RzIiwgc28gc3BlY19jdHJsX2luaXRfZG9tYWluKCkgY2FuIGNhbGN1
bGF0ZSBzdWl0YWJsZSBzZXR0aW5ncy4KICAgICAgKi8KLSAgICBpZiAoIG9w
dF9tZF9jbGVhcl9wdiB8fCBvcHRfbWRfY2xlYXJfaHZtIHx8IG9wdF9mYl9j
bGVhcl9tbWlvICkKKyAgICBpZiAoIG9wdF92ZXJ3X3B2IHx8IG9wdF92ZXJ3
X2h2bSB8fCBvcHRfdmVyd19tbWlvICkKICAgICAgICAgc2V0dXBfZm9yY2Vf
Y3B1X2NhcChYODZfRkVBVFVSRV9TQ19WRVJXX0lETEUpOwotICAgIG9wdF9t
ZF9jbGVhcl9odm0gJj0gIWNwdV9oYXNfc2tpcF9sMWRmbCAmJiAhb3B0X2wx
ZF9mbHVzaDsKKyAgICBvcHRfdmVyd19odm0gJj0gIWNwdV9oYXNfc2tpcF9s
MWRmbCAmJiAhb3B0X2wxZF9mbHVzaDsKIAogICAgIC8qCiAgICAgICogV2Fy
biB0aGUgdXNlciBpZiB0aGV5IGFyZSBvbiBNTFBEUy9NRkJEUy12dWxuZXJh
YmxlIGhhcmR3YXJlIHdpdGggSFQK

--=separator
Content-Type: application/octet-stream; name="xsa452/xsa452-4.15-1.patch"
Content-Disposition: attachment; filename="xsa452/xsa452-4.15-1.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L2VudHJ5OiBJbnRyb2R1Y2UgRUZSQU1FXyogY29u
c3RhbnRzCgpyZXN0b3JlX2FsbF9ndWVzdCgpIGRvZXMgYSBsb3Qgb2YgbWFu
aXB1bGF0aW9uIG9mIHRoZSBzdGFjayBhZnRlciBwb3BwaW5nIHRoZQpHUFJz
LCBhbmQgdXNlcyByYXcgJXJzcCBkaXNwbGFjZW1lbnRzIHRvIGRvIHNvLiAg
QWxzbywgYWxtb3N0IGFsbCBlbnRyeXBhdGhzCnVzZSByYXcgJXJzcCBkaXNw
bGFjZW1lbnRzIHByaW9yIHRvIHB1c2hpbmcgR1BScy4KClByb3ZpZGUgYmV0
dGVyIG1uZW1vbmljcywgdG8gYWlkIHJlYWRhYmlsaXR5IGFuZCByZWR1Y2Ug
dGhlIGNoYW5jZSBvZiBlcnJvcnMKd2hlbiBlZGl0aW5nLgoKTm8gZnVuY3Rp
b25hbCBjaGFuZ2UuICBUaGUgcmVzdWx0aW5nIGJpbmFyeSBpcyBpZGVudGlj
YWwuCgpTaWduZWQtb2ZmLWJ5OiBBbmRyZXcgQ29vcGVyIDxhbmRyZXcuY29v
cGVyM0BjaXRyaXguY29tPgpSZXZpZXdlZC1ieTogSmFuIEJldWxpY2ggPGpi
ZXVsaWNoQHN1c2UuY29tPgooY2hlcnJ5IHBpY2tlZCBmcm9tIGNvbW1pdCAz
NzU0MTIwOGYxMTlhOWM1NTJjNmM2YzMyNDZlYTYxYmUwZDQ0MDM1KQoKZGlm
ZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni94ODZfNjQvYXNtLW9mZnNldHMuYyBi
L3hlbi9hcmNoL3g4Ni94ODZfNjQvYXNtLW9mZnNldHMuYwppbmRleCA2ZGJm
M2JmNjk3ZmUuLjlkMTA1MTYxZGI1OCAxMDA2NDQKLS0tIGEveGVuL2FyY2gv
eDg2L3g4Nl82NC9hc20tb2Zmc2V0cy5jCisrKyBiL3hlbi9hcmNoL3g4Ni94
ODZfNjQvYXNtLW9mZnNldHMuYwpAQCAtNTEsNiArNTEsMjMgQEAgdm9pZCBf
X2R1bW15X18odm9pZCkKICAgICBPRkZTRVQoVVJFR1Nfa2VybmVsX3NpemVv
Ziwgc3RydWN0IGNwdV91c2VyX3JlZ3MsIGVzKTsKICAgICBCTEFOSygpOwog
CisgICAgLyoKKyAgICAgKiBFRlJBTUVfKiBpcyBmb3IgdGhlIGVudHJ5L2V4
aXQgbG9naWMgd2hlcmUgJXJzcCBpcyBwb2ludGluZyBhdAorICAgICAqIFVS
RUdTX2Vycm9yX2NvZGUgYW5kIEdQUnMgYXJlIHN0aWxsL2FscmVhZHkgZ3Vl
c3QgdmFsdWVzLgorICAgICAqLworI2RlZmluZSBPRkZTRVRfRUYoc3ltLCBt
ZW0pICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgXAorICAgIERFRklORShzeW0sIG9mZnNldG9mKHN0cnVjdCBjcHVfdXNl
cl9yZWdzLCBtZW0pIC0gICAgICAgICAgICAgICAgICAgXAorICAgICAgICAg
ICAgICAgIG9mZnNldG9mKHN0cnVjdCBjcHVfdXNlcl9yZWdzLCBlcnJvcl9j
b2RlKSkKKworICAgIE9GRlNFVF9FRihFRlJBTUVfZW50cnlfdmVjdG9yLCAg
ICBlbnRyeV92ZWN0b3IpOworICAgIE9GRlNFVF9FRihFRlJBTUVfcmlwLCAg
ICAgICAgICAgICByaXApOworICAgIE9GRlNFVF9FRihFRlJBTUVfY3MsICAg
ICAgICAgICAgICBjcyk7CisgICAgT0ZGU0VUX0VGKEVGUkFNRV9lZmxhZ3Ms
ICAgICAgICAgIGVmbGFncyk7CisgICAgT0ZGU0VUX0VGKEVGUkFNRV9yc3As
ICAgICAgICAgICAgIHJzcCk7CisgICAgQkxBTksoKTsKKworI3VuZGVmIE9G
RlNFVF9FRgorCiAgICAgT0ZGU0VUKFZDUFVfcHJvY2Vzc29yLCBzdHJ1Y3Qg
dmNwdSwgcHJvY2Vzc29yKTsKICAgICBPRkZTRVQoVkNQVV9kb21haW4sIHN0
cnVjdCB2Y3B1LCBkb21haW4pOwogICAgIE9GRlNFVChWQ1BVX3ZjcHVfaW5m
bywgc3RydWN0IHZjcHUsIHZjcHVfaW5mbyk7CmRpZmYgLS1naXQgYS94ZW4v
YXJjaC94ODYveDg2XzY0L2NvbXBhdC9lbnRyeS5TIGIveGVuL2FyY2gveDg2
L3g4Nl82NC9jb21wYXQvZW50cnkuUwppbmRleCBjZGU3NzAyYjRjNjguLjIw
NjAzZWM0YWZjNyAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L3g4Nl82NC9j
b21wYXQvZW50cnkuUworKysgYi94ZW4vYXJjaC94ODYveDg2XzY0L2NvbXBh
dC9lbnRyeS5TCkBAIC0xNyw3ICsxNyw3IEBAIEVOVFJZKGVudHJ5X2ludDgy
KQogICAgICAgICBFTkRCUjY0CiAgICAgICAgIEFMVEVSTkFUSVZFICIiLCBj
bGFjLCBYODZfRkVBVFVSRV9YRU5fU01BUAogICAgICAgICBwdXNocSAkMAot
ICAgICAgICBtb3ZsICAkSFlQRVJDQUxMX1ZFQ1RPUiwgNCglcnNwKQorICAg
ICAgICBtb3ZsICAkSFlQRVJDQUxMX1ZFQ1RPUiwgRUZSQU1FX2VudHJ5X3Zl
Y3RvciglcnNwKQogICAgICAgICBTQVZFX0FMTCBjb21wYXQ9MSAvKiBEUEwx
IGdhdGUsIHJlc3RyaWN0ZWQgdG8gMzJiaXQgUFYgZ3Vlc3RzIG9ubHkuICov
CiAKICAgICAgICAgU1BFQ19DVFJMX0VOVFJZX0ZST01fUFYgLyogUmVxOiAl
cnNwPXJlZ3MvY3B1aW5mbywgJXJkeD0wLCBDbG9iOiBhY2QgKi8KQEAgLTIx
NCw3ICsyMTQsNyBAQCBFTlRSWShjc3Rhcl9lbnRlcikKICAgICAgICAgcHVz
aHEgJEZMQVRfVVNFUl9DUzMyCiAgICAgICAgIHB1c2hxICVyY3gKICAgICAg
ICAgcHVzaHEgJDAKLSAgICAgICAgbW92bCAgJFRSQVBfc3lzY2FsbCwgNCgl
cnNwKQorICAgICAgICBtb3ZsICAkVFJBUF9zeXNjYWxsLCBFRlJBTUVfZW50
cnlfdmVjdG9yKCVyc3ApCiAgICAgICAgIFNBVkVfQUxMCiAKICAgICAgICAg
U1BFQ19DVFJMX0VOVFJZX0ZST01fUFYgLyogUmVxOiAlcnNwPXJlZ3MvY3B1
aW5mbywgJXJkeD0wLCBDbG9iOiBhY2QgKi8KZGlmZiAtLWdpdCBhL3hlbi9h
cmNoL3g4Ni94ODZfNjQvZW50cnkuUyBiL3hlbi9hcmNoL3g4Ni94ODZfNjQv
ZW50cnkuUwppbmRleCBhMDg2MzQ5ODQxY2MuLmZlMDUyZDI3OTJlOSAxMDA2
NDQKLS0tIGEveGVuL2FyY2gveDg2L3g4Nl82NC9lbnRyeS5TCisrKyBiL3hl
bi9hcmNoL3g4Ni94ODZfNjQvZW50cnkuUwpAQCAtMTkwLDE1ICsxOTAsMTUg
QEAgcmVzdG9yZV9hbGxfZ3Vlc3Q6CiAgICAgICAgIFNQRUNfQ1RSTF9FWElU
X1RPX1BWICAgIC8qIFJlcTogYT1zcGVjX2N0cmwgJXJzcD1yZWdzL2NwdWlu
Zm8sIENsb2I6IGNkICovCiAKICAgICAgICAgUkVTVE9SRV9BTEwKLSAgICAg
ICAgdGVzdHcgJFRSQVBfc3lzY2FsbCw0KCVyc3ApCisgICAgICAgIHRlc3R3
ICRUUkFQX3N5c2NhbGwsIEVGUkFNRV9lbnRyeV92ZWN0b3IoJXJzcCkKICAg
ICAgICAganogICAgaXJldF9leGl0X3RvX2d1ZXN0CiAKLSAgICAgICAgbW92
cSAgMjQoJXJzcCksJXIxMSAgICAgICAgICAgIyBSRkxBR1MKKyAgICAgICAg
bW92ICAgRUZSQU1FX2VmbGFncyglcnNwKSwgJXIxMQogICAgICAgICBhbmRx
ICAkfihYODZfRUZMQUdTX0lPUEwgfCBYODZfRUZMQUdTX1ZNKSwgJXIxMQog
ICAgICAgICBvcnEgICAkWDg2X0VGTEFHU19JRiwlcjExCiAKICAgICAgICAg
LyogRG9uJ3QgdXNlIFNZU1JFVCBwYXRoIGlmIHRoZSByZXR1cm4gYWRkcmVz
cyBpcyBub3QgY2Fub25pY2FsLiAqLwotICAgICAgICBtb3ZxICA4KCVyc3Ap
LCVyY3gKKyAgICAgICAgbW92ICAgRUZSQU1FX3JpcCglcnNwKSwgJXJjeAog
ICAgICAgICBzYXJxICAkNDcsJXJjeAogICAgICAgICBpbmNsICAlZWN4CiAg
ICAgICAgIGNtcGwgICQxLCVlY3gKQEAgLTIxMywyMCArMjEzLDIwIEBAIHJl
c3RvcmVfYWxsX2d1ZXN0OgogICAgICAgICBBTFRFUk5BVElWRSAiIiwgcmFn
X2NscnNzYnN5LCBYODZfRkVBVFVSRV9YRU5fU0hTVEsKICNlbmRpZgogCi0g
ICAgICAgIG1vdnEgIDgoJXJzcCksICVyY3ggICAgICAgICAgICMgUklQCi0g
ICAgICAgIGNtcHcgICRGTEFUX1VTRVJfQ1MzMiwxNiglcnNwKSMgQ1MKLSAg
ICAgICAgbW92cSAgMzIoJXJzcCksJXJzcCAgICAgICAgICAgIyBSU1AKKyAg
ICAgICAgbW92ICAgRUZSQU1FX3JpcCglcnNwKSwgJXJjeAorICAgICAgICBj
bXB3ICAkRkxBVF9VU0VSX0NTMzIsIEVGUkFNRV9jcyglcnNwKQorICAgICAg
ICBtb3YgICBFRlJBTUVfcnNwKCVyc3ApLCAlcnNwCiAgICAgICAgIGplICAg
IDFmCiAgICAgICAgIHN5c3JldHEKIDE6ICAgICAgc3lzcmV0bAogCiAgICAg
ICAgIEFMSUdOCiAuTHJlc3RvcmVfcmN4X2lyZXRfZXhpdF90b19ndWVzdDoK
LSAgICAgICAgbW92cSAgOCglcnNwKSwgJXJjeCAgICAgICAgICAgIyBSSVAK
KyAgICAgICAgbW92ICAgRUZSQU1FX3JpcCglcnNwKSwgJXJjeAogLyogTm8g
c3BlY2lhbCByZWdpc3RlciBhc3N1bXB0aW9ucy4gKi8KIGlyZXRfZXhpdF90
b19ndWVzdDoKLSAgICAgICAgYW5kbCAgJH4oWDg2X0VGTEFHU19JT1BMIHwg
WDg2X0VGTEFHU19WTSksIDI0KCVyc3ApCi0gICAgICAgIG9ybCAgICRYODZf
RUZMQUdTX0lGLDI0KCVyc3ApCisgICAgICAgIGFuZGwgICR+KFg4Nl9FRkxB
R1NfSU9QTCB8IFg4Nl9FRkxBR1NfVk0pLCBFRlJBTUVfZWZsYWdzKCVyc3Ap
CisgICAgICAgIG9ybCAgICRYODZfRUZMQUdTX0lGLCBFRlJBTUVfZWZsYWdz
KCVyc3ApCiAgICAgICAgIGFkZHEgICQ4LCVyc3AKIC5MZnQwOiAgaXJldHEK
ICAgICAgICAgX0FTTV9QUkVfRVhUQUJMRSguTGZ0MCwgaGFuZGxlX2V4Y2Vw
dGlvbikKQEAgLTI1Nyw3ICsyNTcsNyBAQCBFTlRSWShsc3Rhcl9lbnRlcikK
ICAgICAgICAgcHVzaHEgJEZMQVRfS0VSTkVMX0NTNjQKICAgICAgICAgcHVz
aHEgJXJjeAogICAgICAgICBwdXNocSAkMAotICAgICAgICBtb3ZsICAkVFJB
UF9zeXNjYWxsLCA0KCVyc3ApCisgICAgICAgIG1vdmwgICRUUkFQX3N5c2Nh
bGwsIEVGUkFNRV9lbnRyeV92ZWN0b3IoJXJzcCkKICAgICAgICAgU0FWRV9B
TEwKIAogICAgICAgICBTUEVDX0NUUkxfRU5UUllfRlJPTV9QViAvKiBSZXE6
ICVyc3A9cmVncy9jcHVpbmZvLCAlcmR4PTAsIENsb2I6IGFjZCAqLwpAQCAt
Mjk1LDcgKzI5NSw3IEBAIEdMT0JBTChzeXNlbnRlcl9lZmxhZ3Nfc2F2ZWQp
CiAgICAgICAgIHB1c2hxICQzIC8qIHJpbmcgMyBudWxsIGNzICovCiAgICAg
ICAgIHB1c2hxICQwIC8qIG51bGwgcmlwICovCiAgICAgICAgIHB1c2hxICQw
Ci0gICAgICAgIG1vdmwgICRUUkFQX3N5c2NhbGwsIDQoJXJzcCkKKyAgICAg
ICAgbW92bCAgJFRSQVBfc3lzY2FsbCwgRUZSQU1FX2VudHJ5X3ZlY3Rvcigl
cnNwKQogICAgICAgICBTQVZFX0FMTAogCiAgICAgICAgIFNQRUNfQ1RSTF9F
TlRSWV9GUk9NX1BWIC8qIFJlcTogJXJzcD1yZWdzL2NwdWluZm8sICVyZHg9
MCwgQ2xvYjogYWNkICovCkBAIC0zNDcsNyArMzQ3LDcgQEAgRU5UUlkoaW50
ODBfZGlyZWN0X3RyYXApCiAgICAgICAgIEVOREJSNjQKICAgICAgICAgQUxU
RVJOQVRJVkUgIiIsIGNsYWMsIFg4Nl9GRUFUVVJFX1hFTl9TTUFQCiAgICAg
ICAgIHB1c2hxICQwCi0gICAgICAgIG1vdmwgICQweDgwLCA0KCVyc3ApCisg
ICAgICAgIG1vdmwgICQweDgwLCBFRlJBTUVfZW50cnlfdmVjdG9yKCVyc3Ap
CiAgICAgICAgIFNBVkVfQUxMCiAKICAgICAgICAgU1BFQ19DVFJMX0VOVFJZ
X0ZST01fUFYgLyogUmVxOiAlcnNwPXJlZ3MvY3B1aW5mbywgJXJkeD0wLCBD
bG9iOiBhY2QgKi8KQEAgLTY1MCw3ICs2NTAsNyBAQCBFTlRSWShjb21tb25f
aW50ZXJydXB0KQogCiBFTlRSWShwYWdlX2ZhdWx0KQogICAgICAgICBFTkRC
UjY0Ci0gICAgICAgIG1vdmwgICRUUkFQX3BhZ2VfZmF1bHQsNCglcnNwKQor
ICAgICAgICBtb3ZsICAkVFJBUF9wYWdlX2ZhdWx0LCBFRlJBTUVfZW50cnlf
dmVjdG9yKCVyc3ApCiAvKiBObyBzcGVjaWFsIHJlZ2lzdGVyIGFzc3VtcHRp
b25zLiAqLwogR0xPQkFMKGhhbmRsZV9leGNlcHRpb24pCiAgICAgICAgIEFM
VEVSTkFUSVZFICIiLCBjbGFjLCBYODZfRkVBVFVSRV9YRU5fU01BUApAQCAt
NzkwLDkwICs3OTAsOTAgQEAgRkFUQUxfZXhjZXB0aW9uX3dpdGhfaW50c19k
aXNhYmxlZDoKIEVOVFJZKGRpdmlkZV9lcnJvcikKICAgICAgICAgRU5EQlI2
NAogICAgICAgICBwdXNocSAkMAotICAgICAgICBtb3ZsICAkVFJBUF9kaXZp
ZGVfZXJyb3IsNCglcnNwKQorICAgICAgICBtb3ZsICAkVFJBUF9kaXZpZGVf
ZXJyb3IsIEVGUkFNRV9lbnRyeV92ZWN0b3IoJXJzcCkKICAgICAgICAgam1w
ICAgaGFuZGxlX2V4Y2VwdGlvbgogCiBFTlRSWShjb3Byb2Nlc3Nvcl9lcnJv
cikKICAgICAgICAgRU5EQlI2NAogICAgICAgICBwdXNocSAkMAotICAgICAg
ICBtb3ZsICAkVFJBUF9jb3Byb19lcnJvciw0KCVyc3ApCisgICAgICAgIG1v
dmwgICRUUkFQX2NvcHJvX2Vycm9yLCBFRlJBTUVfZW50cnlfdmVjdG9yKCVy
c3ApCiAgICAgICAgIGptcCAgIGhhbmRsZV9leGNlcHRpb24KIAogRU5UUlko
c2ltZF9jb3Byb2Nlc3Nvcl9lcnJvcikKICAgICAgICAgRU5EQlI2NAogICAg
ICAgICBwdXNocSAkMAotICAgICAgICBtb3ZsICAkVFJBUF9zaW1kX2Vycm9y
LDQoJXJzcCkKKyAgICAgICAgbW92bCAgJFRSQVBfc2ltZF9lcnJvciwgRUZS
QU1FX2VudHJ5X3ZlY3RvciglcnNwKQogICAgICAgICBqbXAgICBoYW5kbGVf
ZXhjZXB0aW9uCiAKIEVOVFJZKGRldmljZV9ub3RfYXZhaWxhYmxlKQogICAg
ICAgICBFTkRCUjY0CiAgICAgICAgIHB1c2hxICQwCi0gICAgICAgIG1vdmwg
ICRUUkFQX25vX2RldmljZSw0KCVyc3ApCisgICAgICAgIG1vdmwgICRUUkFQ
X25vX2RldmljZSwgRUZSQU1FX2VudHJ5X3ZlY3RvciglcnNwKQogICAgICAg
ICBqbXAgICBoYW5kbGVfZXhjZXB0aW9uCiAKIEVOVFJZKGRlYnVnKQogICAg
ICAgICBFTkRCUjY0CiAgICAgICAgIHB1c2hxICQwCi0gICAgICAgIG1vdmwg
ICRUUkFQX2RlYnVnLDQoJXJzcCkKKyAgICAgICAgbW92bCAgJFRSQVBfZGVi
dWcsIEVGUkFNRV9lbnRyeV92ZWN0b3IoJXJzcCkKICAgICAgICAgam1wICAg
aGFuZGxlX2lzdF9leGNlcHRpb24KIAogRU5UUlkoaW50MykKICAgICAgICAg
RU5EQlI2NAogICAgICAgICBwdXNocSAkMAotICAgICAgICBtb3ZsICAkVFJB
UF9pbnQzLDQoJXJzcCkKKyAgICAgICAgbW92bCAgJFRSQVBfaW50MywgRUZS
QU1FX2VudHJ5X3ZlY3RvciglcnNwKQogICAgICAgICBqbXAgICBoYW5kbGVf
ZXhjZXB0aW9uCiAKIEVOVFJZKG92ZXJmbG93KQogICAgICAgICBFTkRCUjY0
CiAgICAgICAgIHB1c2hxICQwCi0gICAgICAgIG1vdmwgICRUUkFQX292ZXJm
bG93LDQoJXJzcCkKKyAgICAgICAgbW92bCAgJFRSQVBfb3ZlcmZsb3csIEVG
UkFNRV9lbnRyeV92ZWN0b3IoJXJzcCkKICAgICAgICAgam1wICAgaGFuZGxl
X2V4Y2VwdGlvbgogCiBFTlRSWShib3VuZHMpCiAgICAgICAgIEVOREJSNjQK
ICAgICAgICAgcHVzaHEgJDAKLSAgICAgICAgbW92bCAgJFRSQVBfYm91bmRz
LDQoJXJzcCkKKyAgICAgICAgbW92bCAgJFRSQVBfYm91bmRzLCBFRlJBTUVf
ZW50cnlfdmVjdG9yKCVyc3ApCiAgICAgICAgIGptcCAgIGhhbmRsZV9leGNl
cHRpb24KIAogRU5UUlkoaW52YWxpZF9vcCkKICAgICAgICAgRU5EQlI2NAog
ICAgICAgICBwdXNocSAkMAotICAgICAgICBtb3ZsICAkVFJBUF9pbnZhbGlk
X29wLDQoJXJzcCkKKyAgICAgICAgbW92bCAgJFRSQVBfaW52YWxpZF9vcCwg
RUZSQU1FX2VudHJ5X3ZlY3RvciglcnNwKQogICAgICAgICBqbXAgICBoYW5k
bGVfZXhjZXB0aW9uCiAKIEVOVFJZKGludmFsaWRfVFNTKQogICAgICAgICBF
TkRCUjY0Ci0gICAgICAgIG1vdmwgICRUUkFQX2ludmFsaWRfdHNzLDQoJXJz
cCkKKyAgICAgICAgbW92bCAgJFRSQVBfaW52YWxpZF90c3MsIEVGUkFNRV9l
bnRyeV92ZWN0b3IoJXJzcCkKICAgICAgICAgam1wICAgaGFuZGxlX2V4Y2Vw
dGlvbgogCiBFTlRSWShzZWdtZW50X25vdF9wcmVzZW50KQogICAgICAgICBF
TkRCUjY0Ci0gICAgICAgIG1vdmwgICRUUkFQX25vX3NlZ21lbnQsNCglcnNw
KQorICAgICAgICBtb3ZsICAkVFJBUF9ub19zZWdtZW50LCBFRlJBTUVfZW50
cnlfdmVjdG9yKCVyc3ApCiAgICAgICAgIGptcCAgIGhhbmRsZV9leGNlcHRp
b24KIAogRU5UUlkoc3RhY2tfc2VnbWVudCkKICAgICAgICAgRU5EQlI2NAot
ICAgICAgICBtb3ZsICAkVFJBUF9zdGFja19lcnJvciw0KCVyc3ApCisgICAg
ICAgIG1vdmwgICRUUkFQX3N0YWNrX2Vycm9yLCBFRlJBTUVfZW50cnlfdmVj
dG9yKCVyc3ApCiAgICAgICAgIGptcCAgIGhhbmRsZV9leGNlcHRpb24KIAog
RU5UUlkoZ2VuZXJhbF9wcm90ZWN0aW9uKQogICAgICAgICBFTkRCUjY0Ci0g
ICAgICAgIG1vdmwgICRUUkFQX2dwX2ZhdWx0LDQoJXJzcCkKKyAgICAgICAg
bW92bCAgJFRSQVBfZ3BfZmF1bHQsIEVGUkFNRV9lbnRyeV92ZWN0b3IoJXJz
cCkKICAgICAgICAgam1wICAgaGFuZGxlX2V4Y2VwdGlvbgogCiBFTlRSWShh
bGlnbm1lbnRfY2hlY2spCiAgICAgICAgIEVOREJSNjQKLSAgICAgICAgbW92
bCAgJFRSQVBfYWxpZ25tZW50X2NoZWNrLDQoJXJzcCkKKyAgICAgICAgbW92
bCAgJFRSQVBfYWxpZ25tZW50X2NoZWNrLCBFRlJBTUVfZW50cnlfdmVjdG9y
KCVyc3ApCiAgICAgICAgIGptcCAgIGhhbmRsZV9leGNlcHRpb24KIAogRU5U
UlkoZW50cnlfQ1ApCiAgICAgICAgIEVOREJSNjQKLSAgICAgICAgbW92bCAg
JFg4Nl9FWENfQ1AsIDQoJXJzcCkKKyAgICAgICAgbW92bCAgJFg4Nl9FWENf
Q1AsIEVGUkFNRV9lbnRyeV92ZWN0b3IoJXJzcCkKICAgICAgICAgam1wICAg
aGFuZGxlX2V4Y2VwdGlvbgogCiBFTlRSWShkb3VibGVfZmF1bHQpCiAgICAg
ICAgIEVOREJSNjQKLSAgICAgICAgbW92bCAgJFRSQVBfZG91YmxlX2ZhdWx0
LDQoJXJzcCkKKyAgICAgICAgbW92bCAgJFRSQVBfZG91YmxlX2ZhdWx0LCBF
RlJBTUVfZW50cnlfdmVjdG9yKCVyc3ApCiAgICAgICAgIC8qIFNldCBBQyB0
byByZWR1Y2UgY2hhbmNlIG9mIGZ1cnRoZXIgU01BUCBmYXVsdHMgKi8KICAg
ICAgICAgQUxURVJOQVRJVkUgIiIsIHN0YWMsIFg4Nl9GRUFUVVJFX1hFTl9T
TUFQCiAgICAgICAgIFNBVkVfQUxMCkBAIC04OTksNyArODk5LDcgQEAgRU5U
UlkoZG91YmxlX2ZhdWx0KQogICAgICAgICAucHVzaHNlY3Rpb24gLmluaXQu
dGV4dCwgImF4IiwgQHByb2diaXRzCiBFTlRSWShlYXJseV9wYWdlX2ZhdWx0
KQogICAgICAgICBFTkRCUjY0Ci0gICAgICAgIG1vdmwgICRUUkFQX3BhZ2Vf
ZmF1bHQsNCglcnNwKQorICAgICAgICBtb3ZsICAkVFJBUF9wYWdlX2ZhdWx0
LCBFRlJBTUVfZW50cnlfdmVjdG9yKCVyc3ApCiAgICAgICAgIFNBVkVfQUxM
CiAgICAgICAgIG1vdnEgICVyc3AsJXJkaQogICAgICAgICBjYWxsICBkb19l
YXJseV9wYWdlX2ZhdWx0CkBAIC05MDksNyArOTA5LDcgQEAgRU5UUlkoZWFy
bHlfcGFnZV9mYXVsdCkKIEVOVFJZKG5taSkKICAgICAgICAgRU5EQlI2NAog
ICAgICAgICBwdXNocSAkMAotICAgICAgICBtb3ZsICAkVFJBUF9ubWksNCgl
cnNwKQorICAgICAgICBtb3ZsICAkVFJBUF9ubWksIEVGUkFNRV9lbnRyeV92
ZWN0b3IoJXJzcCkKIGhhbmRsZV9pc3RfZXhjZXB0aW9uOgogICAgICAgICBB
TFRFUk5BVElWRSAiIiwgY2xhYywgWDg2X0ZFQVRVUkVfWEVOX1NNQVAKICAg
ICAgICAgU0FWRV9BTEwKQEAgLTEwMTEsNyArMTAxMSw3IEBAIGhhbmRsZV9p
c3RfZXhjZXB0aW9uOgogRU5UUlkobWFjaGluZV9jaGVjaykKICAgICAgICAg
RU5EQlI2NAogICAgICAgICBwdXNocSAkMAotICAgICAgICBtb3ZsICAkVFJB
UF9tYWNoaW5lX2NoZWNrLDQoJXJzcCkKKyAgICAgICAgbW92bCAgJFRSQVBf
bWFjaGluZV9jaGVjaywgRUZSQU1FX2VudHJ5X3ZlY3RvciglcnNwKQogICAg
ICAgICBqbXAgICBoYW5kbGVfaXN0X2V4Y2VwdGlvbgogCiAvKiBObyBvcCB0
cmFwIGhhbmRsZXIuICBSZXF1aXJlZCBmb3Iga2V4ZWMgY3Jhc2ggcGF0aC4g
Ki8KQEAgLTEwNDgsNyArMTA0OCw3IEBAIGF1dG9nZW5fc3R1YnM6IC8qIEF1
dG9tYXRpY2FsbHkgZ2VuZXJhdGVkIHN0dWJzLiAqLwogMToKICAgICAgICAg
RU5EQlI2NAogICAgICAgICBwdXNocSAkMAotICAgICAgICBtb3ZiICAkdmVj
LDQoJXJzcCkKKyAgICAgICAgbW92YiAgJHZlYywgRUZSQU1FX2VudHJ5X3Zl
Y3RvciglcnNwKQogICAgICAgICBqbXAgICBjb21tb25faW50ZXJydXB0CiAK
ICAgICAgICAgZW50cnlwb2ludCAxYgpAQCAtMTA2Miw3ICsxMDYyLDcgQEAg
YXV0b2dlbl9zdHViczogLyogQXV0b21hdGljYWxseSBnZW5lcmF0ZWQgc3R1
YnMuICovCiAgICAgICAgIHRlc3QgICQ4LCVzcGwgICAgICAgIC8qIDY0Yml0
IGV4Y2VwdGlvbiBmcmFtZXMgYXJlIDE2IGJ5dGUgYWxpZ25lZCwgYnV0IHRo
ZSB3b3JkICovCiAgICAgICAgIGp6ICAgIDJmICAgICAgICAgICAgIC8qIHNp
emUgaXMgOCBieXRlcy4gIENoZWNrIHdoZXRoZXIgdGhlIHByb2Nlc3NvciBn
YXZlIHVzIGFuICovCiAgICAgICAgIHB1c2hxICQwICAgICAgICAgICAgIC8q
IGVycm9yIGNvZGUsIGFuZCBpbnNlcnQgYW4gZW1wdHkgb25lIGlmIG5vdC4g
ICAgICAgICAgICAgICovCi0yOiAgICAgIG1vdmIgICR2ZWMsNCglcnNwKQor
MjogICAgICBtb3ZiICAkdmVjLCBFRlJBTUVfZW50cnlfdmVjdG9yKCVyc3Ap
CiAgICAgICAgIGptcCAgIGhhbmRsZV9leGNlcHRpb24KIAogICAgICAgICBl
bnRyeXBvaW50IDFiCg==

--=separator
Content-Type: application/octet-stream; name="xsa452/xsa452-4.15-2.patch"
Content-Disposition: attachment; filename="xsa452/xsa452-4.15-2.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L2NwdS1wb2xpY3k6IEFsbG93IGZvciBsZXZlbGxp
bmcgb2YgVkVSVyBzaWRlIGVmZmVjdHMKCk1EX0NMRUFSIGFuZCBGQl9DTEVB
UiBuZWVkIE9SLWluZyBhY3Jvc3MgYSBtaWdyYXRlIHBvb2wuICBBbGxvdyB0
aGlzLCBieQpoYXZpbmcgdGhlbSB1bmNvbmRpdGluYWxseSBzZXQgaW4gbWF4
LCB3aXRoIHRoZSBob3N0IHZhbHVlcyByZWZsZWN0ZWQgaW4KZGVmYXVsdC4g
IEFubm90YXRlIHRoZSBiaXRzIGFzIGhhdmluZyBzcGVjaWFsIHByb3Blcmll
cy4KClNpZ25lZC1vZmYtYnk6IEFuZHJldyBDb29wZXIgPGFuZHJldy5jb29w
ZXIzQGNpdHJpeC5jb20+ClJldmlld2VkLWJ5OiBSb2dlciBQYXUgTW9ubsOp
IDxyb2dlci5wYXVAY2l0cml4LmNvbT4KKGNoZXJyeSBwaWNrZWQgZnJvbSBj
b21taXQgZGUxNzE2MmNhZmQyN2YyODY1YTMxMDJhMmVjMGYzODZhMDJlZDAz
ZCkKCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYvY3B1LXBvbGljeS5jIGIv
eGVuL2FyY2gveDg2L2NwdS1wb2xpY3kuYwppbmRleCA3OTI3MjRkYjZmNGUu
LmM2Y2Q5MWRiMGEwZiAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2NwdS1w
b2xpY3kuYworKysgYi94ZW4vYXJjaC94ODYvY3B1LXBvbGljeS5jCkBAIC00
MzQsNiArNDM0LDE2IEBAIHN0YXRpYyB2b2lkIF9faW5pdCBndWVzdF9jb21t
b25fbWF4X2ZlYXR1cmVfYWRqdXN0bWVudHModWludDMyX3QgKmZzKQogICAg
ICAgICBfX3NldF9iaXQoWDg2X0ZFQVRVUkVfUlNCQSwgZnMpOwogICAgICAg
ICBfX3NldF9iaXQoWDg2X0ZFQVRVUkVfUlJTQkEsIGZzKTsKIAorICAgICAg
ICAvKgorICAgICAgICAgKiBUaGVzZSBiaXRzIGluZGljYXRlIHRoYXQgdGhl
IFZFUlcgaW5zdHJ1Y3Rpb24gbWF5IGhhdmUgZ2FpbmVkCisgICAgICAgICAq
IHNjcnViYmluZyBzaWRlIGVmZmVjdHMuICBXaXRoIHBvb2xpbmcsIHRoZXkg
bWVhbiAieW91IG1pZ2h0IG1pZ3JhdGUKKyAgICAgICAgICogc29tZXdoZXJl
IHdoZXJlIHNjcnViYmluZyBpcyBuZWNlc3NhcnkiLCBhbmQgbWF5IG5lZWQg
ZXhwb3Npbmcgb24KKyAgICAgICAgICogdW5hZmZlY3RlZCBoYXJkd2FyZS4g
IFRoaXMgaXMgZmluZSwgYmVjYXVzZSB0aGUgVkVSVyBpbnN0cnVjdGlvbgor
ICAgICAgICAgKiBoYXMgYmVlbiBhcm91bmQgc2luY2UgdGhlIDI4Ni4KKyAg
ICAgICAgICovCisgICAgICAgIF9fc2V0X2JpdChYODZfRkVBVFVSRV9NRF9D
TEVBUiwgZnMpOworICAgICAgICBfX3NldF9iaXQoWDg2X0ZFQVRVUkVfRkJf
Q0xFQVIsIGZzKTsKKwogICAgICAgICAvKgogICAgICAgICAgKiBUaGUgR2F0
aGVyIERhdGEgU2FtcGxpbmcgbWljcm9jb2RlIG1pdGlnYXRpb24gKEF1Z3Vz
dCAyMDIzKSBoYXMgYW4KICAgICAgICAgICogYWR2ZXJzZSBwZXJmb3JtYW5j
ZSBpbXBhY3Qgb24gdGhlIENMV0IgaW5zdHJ1Y3Rpb24gb24gU0tYL0NMWC9D
UFguCkBAIC00NjgsNiArNDc4LDIwIEBAIHN0YXRpYyB2b2lkIF9faW5pdCBn
dWVzdF9jb21tb25fZGVmYXVsdF9mZWF0dXJlX2FkanVzdG1lbnRzKHVpbnQz
Ml90ICpmcykKICAgICAgICAgICAgICBjcHVfaGFzX3JkcmFuZCAmJiAhaXNf
Zm9yY2VkX2NwdV9jYXAoWDg2X0ZFQVRVUkVfUkRSQU5EKSApCiAgICAgICAg
ICAgICBfX2NsZWFyX2JpdChYODZfRkVBVFVSRV9SRFJBTkQsIGZzKTsKIAor
ICAgICAgICAvKgorICAgICAgICAgKiBUaGVzZSBiaXRzIGluZGljYXRlIHRo
YXQgdGhlIFZFUlcgaW5zdHJ1Y3Rpb24gbWF5IGhhdmUgZ2FpbmVkCisgICAg
ICAgICAqIHNjcnViYmluZyBzaWRlIGVmZmVjdHMuICBUaGUgbWF4IHBvbGlj
eSBoYXMgdGhlbSBzZXQgZm9yIG1pZ3JhdGlvbgorICAgICAgICAgKiByZWFz
b25zLCBzbyByZXNldCB0aGUgZGVmYXVsdCBwb2xpY3kgYmFjayB0byB0aGUg
aG9zdCB2YWx1ZXMgaW4KKyAgICAgICAgICogY2FzZSB3ZSdyZSB1bmFmZmVj
dGVkLgorICAgICAgICAgKi8KKyAgICAgICAgX19jbGVhcl9iaXQoWDg2X0ZF
QVRVUkVfTURfQ0xFQVIsIGZzKTsKKyAgICAgICAgaWYgKCBjcHVfaGFzX21k
X2NsZWFyICkKKyAgICAgICAgICAgIF9fc2V0X2JpdChYODZfRkVBVFVSRV9N
RF9DTEVBUiwgZnMpOworCisgICAgICAgIF9fY2xlYXJfYml0KFg4Nl9GRUFU
VVJFX0ZCX0NMRUFSLCBmcyk7CisgICAgICAgIGlmICggY3B1X2hhc19mYl9j
bGVhciApCisgICAgICAgICAgICBfX3NldF9iaXQoWDg2X0ZFQVRVUkVfRkJf
Q0xFQVIsIGZzKTsKKwogICAgICAgICAvKgogICAgICAgICAgKiBUaGUgR2F0
aGVyIERhdGEgU2FtcGxpbmcgbWljcm9jb2RlIG1pdGlnYXRpb24gKEF1Z3Vz
dCAyMDIzKSBoYXMgYW4KICAgICAgICAgICogYWR2ZXJzZSBwZXJmb3JtYW5j
ZSBpbXBhY3Qgb24gdGhlIENMV0IgaW5zdHJ1Y3Rpb24gb24gU0tYL0NMWC9D
UFguCmRpZmYgLS1naXQgYS94ZW4vaW5jbHVkZS9hc20teDg2L2NwdWZlYXR1
cmUuaCBiL3hlbi9pbmNsdWRlL2FzbS14ODYvY3B1ZmVhdHVyZS5oCmluZGV4
IGVjZGM3ZDliNzE3MS4uM2IxMTZjNmRkMzY0IDEwMDY0NAotLS0gYS94ZW4v
aW5jbHVkZS9hc20teDg2L2NwdWZlYXR1cmUuaAorKysgYi94ZW4vaW5jbHVk
ZS9hc20teDg2L2NwdWZlYXR1cmUuaApAQCAtMTM3LDYgKzEzNyw3IEBACiAj
ZGVmaW5lIGNwdV9oYXNfYXZ4NTEyXzRmbWFwcyAgIGJvb3RfY3B1X2hhcyhY
ODZfRkVBVFVSRV9BVlg1MTJfNEZNQVBTKQogI2RlZmluZSBjcHVfaGFzX2F2
eDUxMl92cDJpbnRlcnNlY3QgYm9vdF9jcHVfaGFzKFg4Nl9GRUFUVVJFX0FW
WDUxMl9WUDJJTlRFUlNFQ1QpCiAjZGVmaW5lIGNwdV9oYXNfc3JiZHNfY3Ry
bCAgICAgIGJvb3RfY3B1X2hhcyhYODZfRkVBVFVSRV9TUkJEU19DVFJMKQor
I2RlZmluZSBjcHVfaGFzX21kX2NsZWFyICAgICAgICBib290X2NwdV9oYXMo
WDg2X0ZFQVRVUkVfTURfQ0xFQVIpCiAjZGVmaW5lIGNwdV9oYXNfcnRtX2Fs
d2F5c19hYm9ydCBib290X2NwdV9oYXMoWDg2X0ZFQVRVUkVfUlRNX0FMV0FZ
U19BQk9SVCkKICNkZWZpbmUgY3B1X2hhc190c3hfZm9yY2VfYWJvcnQgYm9v
dF9jcHVfaGFzKFg4Nl9GRUFUVVJFX1RTWF9GT1JDRV9BQk9SVCkKICNkZWZp
bmUgY3B1X2hhc19zZXJpYWxpemUgICAgICAgYm9vdF9jcHVfaGFzKFg4Nl9G
RUFUVVJFX1NFUklBTElaRSkKZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL3B1
YmxpYy9hcmNoLXg4Ni9jcHVmZWF0dXJlc2V0LmggYi94ZW4vaW5jbHVkZS9w
dWJsaWMvYXJjaC14ODYvY3B1ZmVhdHVyZXNldC5oCmluZGV4IGU0MzRmYzli
YWUyMi4uYjRmNjhhNTliODU5IDEwMDY0NAotLS0gYS94ZW4vaW5jbHVkZS9w
dWJsaWMvYXJjaC14ODYvY3B1ZmVhdHVyZXNldC5oCisrKyBiL3hlbi9pbmNs
dWRlL3B1YmxpYy9hcmNoLXg4Ni9jcHVmZWF0dXJlc2V0LmgKQEAgLTI3Myw3
ICsyNzMsNyBAQCBYRU5fQ1BVRkVBVFVSRShBVlg1MTJfNFZOTklXLCA5KjMy
KyAyKSAvKkEgIEFWWDUxMiBOZXVyYWwgTmV0d29yayBJbnN0cnVjdGlvbnMg
KgogWEVOX0NQVUZFQVRVUkUoQVZYNTEyXzRGTUFQUywgOSozMisgMykgLypB
ICBBVlg1MTIgTXVsdGlwbHkgQWNjdW11bGF0aW9uIFNpbmdsZSBQcmVjaXNp
b24gKi8KIFhFTl9DUFVGRUFUVVJFKEFWWDUxMl9WUDJJTlRFUlNFQ1QsIDkq
MzIrOCkgLyphICBWUDJJTlRFUlNFQ1R7RCxRfSBpbnNucyAqLwogWEVOX0NQ
VUZFQVRVUkUoU1JCRFNfQ1RSTCwgICAgOSozMisgOSkgLyogICBNU1JfTUNV
X09QVF9DVFJMIGFuZCBSTkdEU19NSVRHX0RJUy4gKi8KLVhFTl9DUFVGRUFU
VVJFKE1EX0NMRUFSLCAgICAgIDkqMzIrMTApIC8qQSAgVkVSVyBjbGVhcnMg
bWljcm9hcmNoaXRlY3R1cmFsIGJ1ZmZlcnMgKi8KK1hFTl9DUFVGRUFUVVJF
KE1EX0NMRUFSLCAgICAgIDkqMzIrMTApIC8qIUEgVkVSVyBjbGVhcnMgbWlj
cm9hcmNoaXRlY3R1cmFsIGJ1ZmZlcnMgKi8KIFhFTl9DUFVGRUFUVVJFKFJU
TV9BTFdBWVNfQUJPUlQsIDkqMzIrMTEpIC8qISBKdW5lIDIwMjEgVFNYIGRl
ZmVhdHVyaW5nIGluIG1pY3JvY29kZS4gKi8KIFhFTl9DUFVGRUFUVVJFKFRT
WF9GT1JDRV9BQk9SVCwgOSozMisxMykgLyogTVNSX1RTWF9GT1JDRV9BQk9S
VC5SVE1fQUJPUlQgKi8KIFhFTl9DUFVGRUFUVVJFKFNFUklBTElaRSwgICAg
IDkqMzIrMTQpIC8qYSAgU0VSSUFMSVpFIGluc24gKi8KQEAgLTMyMiw3ICsz
MjIsNyBAQCBYRU5fQ1BVRkVBVFVSRShET0lUTSwgICAgICAgICAgICAgIDE2
KjMyKzEyKSAvKiAgIERhdGEgT3BlcmFuZCBJbnZhcmlhbnQgVGltaW5nCiBY
RU5fQ1BVRkVBVFVSRShTQkRSX1NTRFBfTk8sICAgICAgIDE2KjMyKzEzKSAv
KkEgIE5vIFNoYXJlZCBCdWZmZXIgRGF0YSBSZWFkIG9yIFNpZGViYW5kIFN0
YWxlIERhdGEgUHJvcGFnYXRpb24gKi8KIFhFTl9DUFVGRUFUVVJFKEZCU0RQ
X05PLCAgICAgICAgICAgMTYqMzIrMTQpIC8qQSAgTm8gRmlsbCBCdWZmZXIg
U3RhbGUgRGF0YSBQcm9wYWdhdGlvbiAqLwogWEVOX0NQVUZFQVRVUkUoUFNE
UF9OTywgICAgICAgICAgICAxNiozMisxNSkgLypBICBObyBQcmltYXJ5IFN0
YWxlIERhdGEgUHJvcGFnYXRpb24gKi8KLVhFTl9DUFVGRUFUVVJFKEZCX0NM
RUFSLCAgICAgICAgICAgMTYqMzIrMTcpIC8qQSAgRmlsbCBCdWZmZXJzIGNs
ZWFyZWQgYnkgVkVSVyAqLworWEVOX0NQVUZFQVRVUkUoRkJfQ0xFQVIsICAg
ICAgICAgICAxNiozMisxNykgLyohQSBGaWxsIEJ1ZmZlcnMgY2xlYXJlZCBi
eSBWRVJXICovCiBYRU5fQ1BVRkVBVFVSRShGQl9DTEVBUl9DVFJMLCAgICAg
IDE2KjMyKzE4KSAvKiAgIE1TUl9PUFRfQ1BVX0NUUkwuRkJfQ0xFQVJfRElT
ICovCiBYRU5fQ1BVRkVBVFVSRShSUlNCQSwgICAgICAgICAgICAgIDE2KjMy
KzE5KSAvKiEgIFJlc3RyaWN0ZWQgUlNCIEFsdGVybmF0aXZlICovCiBYRU5f
Q1BVRkVBVFVSRShCSElfTk8sICAgICAgICAgICAgIDE2KjMyKzIwKSAvKkEg
IE5vIEJyYW5jaCBIaXN0b3J5IEluamVjdGlvbiAgKi8K

--=separator
Content-Type: application/octet-stream; name="xsa452/xsa452-4.15-3.patch"
Content-Disposition: attachment; filename="xsa452/xsa452-4.15-3.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L3ZteDogUGVyZm9ybSBWRVJXIGZsdXNoaW5nIGxh
dGVyIGluIHRoZSBWTUV4aXQgcGF0aAoKQnJva2VuIG91dCBvZiB0aGUgZm9s
bG93aW5nIHBhdGNoIGJlY2F1c2UgdGhpcyBjaGFuZ2UgaXMgc3VidGxlIGVu
b3VnaCBvbiBpdHMKb3duLiAgU2VlIGl0IGZvciB0aGUgcmF0aW9uYWwgb2Yg
d2h5IHdlJ3JlIG1vdmluZyBWRVJXLgoKQXMgZm9yIGhvdywgZXh0ZW5kIHRo
ZSB0cmljayBhbHJlYWR5IHVzZWQgdG8gaG9sZCBvbmUgY29uZGl0aW9uIGlu
CmZsYWdzIChSRVNVTUUgdnMgTEFVTkNIKSB0aHJvdWdoIHRoZSBQT1Bpbmcg
b2YgR1BScy4KCk1vdmUgdGhlIE1PViBDUiBlYXJsaWVyLiAgSW50ZWwgc3Bl
Y2lmeSBmbGFncyB0byBiZSB1bmRlZmluZWQgYWNyb3NzIGl0LgoKRW5jb2Rl
IHRoZSB0d28gY29uZGl0aW9ucyB3ZSB3YW50IHVzaW5nIFNGIGFuZCBQRi4g
IFNlZSB0aGUgY29kZSBjb21tZW50IGZvcgpleGFjdGx5IGhvdy4KCkxlYXZl
IGEgY29tbWVudCB0byBleHBsYWluIHRoZSBsYWNrIG9mIGFueSBjb250ZW50
IGFyb3VuZApTUEVDX0NUUkxfRVhJVF9UT19WTVgsIGJ1dCBsZWF2ZSB0aGUg
YmxvY2sgaW4gcGxhY2UuICBTb2RzIGxhdyBzYXlzIGlmIHdlCmRlbGV0ZSBp
dCwgd2UnbGwgbmVlZCB0byByZWludHJvZHVjZSBpdC4KClRoaXMgaXMgcGFy
dCBvZiBYU0EtNDUyIC8gQ1ZFLTIwMjMtMjg3NDYuCgpTaWduZWQtb2ZmLWJ5
OiBBbmRyZXcgQ29vcGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPgpS
ZXZpZXdlZC1ieTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgoo
Y2hlcnJ5IHBpY2tlZCBmcm9tIGNvbW1pdCA0NzVmYTIwYjczODQ0NjQyMTBm
NDJiYWQ3MTk1Zjg3YmQ2ZjFjNjNmKQoKZGlmZiAtLWdpdCBhL3hlbi9hcmNo
L3g4Ni9odm0vdm14L2VudHJ5LlMgYi94ZW4vYXJjaC94ODYvaHZtL3ZteC9l
bnRyeS5TCmluZGV4IDVmNWRlNDVhMTMwOS4uY2RkZTc2ZTEzODkyIDEwMDY0
NAotLS0gYS94ZW4vYXJjaC94ODYvaHZtL3ZteC9lbnRyeS5TCisrKyBiL3hl
bi9hcmNoL3g4Ni9odm0vdm14L2VudHJ5LlMKQEAgLTg3LDE3ICs4NywzOSBA
QCBVTkxJS0VMWV9FTkQocmVhbG1vZGUpCiAKICAgICAgICAgLyogV0FSTklO
RyEgYHJldGAsIGBjYWxsICpgLCBgam1wICpgIG5vdCBzYWZlIGJleW9uZCB0
aGlzIHBvaW50LiAqLwogICAgICAgICAvKiBTUEVDX0NUUkxfRVhJVF9UT19W
TVggICBSZXE6ICVyc3A9cmVncy9jcHVpbmZvICAgICAgICAgICAgICBDbG9i
OiAgICAqLwotICAgICAgICBET19TUEVDX0NUUkxfQ09ORF9WRVJXCisgICAg
ICAgIC8qCisgICAgICAgICAqIEFsbCBzcGVjdWxhdGlvbiBzYWZldHkgd29y
ayBoYXBwZW5zIHRvIGJlIGVsc2V3aGVyZS4gIFZFUlcgaXMgYWZ0ZXIKKyAg
ICAgICAgICogcG9wcGluZyB0aGUgR1BScywgd2hpbGUgcmVzdG9yaW5nIHRo
ZSBndWVzdCBNU1JfU1BFQ19DVFJMIGlzIGxlZnQKKyAgICAgICAgICogdG8g
dGhlIE1TUiBsb2FkIGxpc3QuCisgICAgICAgICAqLwogCiAgICAgICAgIG1v
diAgVkNQVV9odm1fZ3Vlc3RfY3IyKCVyYngpLCVyYXgKKyAgICAgICAgbW92
ICAlcmF4LCAlY3IyCisKKyAgICAgICAgLyoKKyAgICAgICAgICogV2UgbmVl
ZCB0byBwZXJmb3JtIHR3byBjb25kaXRpb25hbCBhY3Rpb25zIChWRVJXLCBh
bmQgUmVzdW1lIHZzCisgICAgICAgICAqIExhdW5jaCkgYWZ0ZXIgcG9wcGlu
ZyBHUFJzLiAgV2l0aCBzb21lIGN1bm5pbmcsIHdlIGNhbiBlbmNvZGUgYm90
aAorICAgICAgICAgKiBvZiB0aGVzZSBpbiBlZmxhZ3MgdG9nZXRoZXIuCisg
ICAgICAgICAqCisgICAgICAgICAqIFBhcml0eSBpcyBvbmx5IGNhbGN1bGF0
ZWQgb3ZlciB0aGUgYm90dG9tIGJ5dGUgb2YgdGhlIGFuc3dlciwgd2hpbGUK
KyAgICAgICAgICogU2lnbiBpcyBzaW1wbHkgdGhlIHRvcCBiaXQuCisgICAg
ICAgICAqCisgICAgICAgICAqIFRoZXJlZm9yZSwgdGhlIGZpbmFsIE9SIGlu
c3RydWN0aW9uIGVuZHMgdXAgcHJvZHVjaW5nOgorICAgICAgICAgKiAgIFNG
ID0gVkNQVV92bXhfbGF1bmNoZWQKKyAgICAgICAgICogICBQRiA9ICFTQ0Zf
dmVydworICAgICAgICAgKi8KKyAgICAgICAgQlVJTERfQlVHX09OKFNDRl92
ZXJ3ICYgfjB4ZmYpCisgICAgICAgIG1vdnpibCBWQ1BVX3ZteF9sYXVuY2hl
ZCglcmJ4KSwgJWVjeAorICAgICAgICBzaGwgICQzMSwgJWVjeAorICAgICAg
ICBtb3Z6YmwgQ1BVSU5GT19zcGVjX2N0cmxfZmxhZ3MoJXJzcCksICVlYXgK
KyAgICAgICAgYW5kICAkU0NGX3ZlcncsICVlYXgKKyAgICAgICAgb3IgICAl
ZWF4LCAlZWN4CiAKICAgICAgICAgcG9wICAlcjE1CiAgICAgICAgIHBvcCAg
JXIxNAogICAgICAgICBwb3AgICVyMTMKICAgICAgICAgcG9wICAlcjEyCiAg
ICAgICAgIHBvcCAgJXJicAotICAgICAgICBtb3YgICVyYXgsJWNyMgotICAg
ICAgICBjbXBiICQwLFZDUFVfdm14X2xhdW5jaGVkKCVyYngpCiAgICAgICAg
IHBvcCAgJXJieAogICAgICAgICBwb3AgICVyMTEKICAgICAgICAgcG9wICAl
cjEwCkBAIC0xMDgsNyArMTMwLDEzIEBAIFVOTElLRUxZX0VORChyZWFsbW9k
ZSkKICAgICAgICAgcG9wICAlcmR4CiAgICAgICAgIHBvcCAgJXJzaQogICAg
ICAgICBwb3AgICVyZGkKLSAgICAgICAgamUgICAuTHZteF9sYXVuY2gKKwor
ICAgICAgICBqcGUgIC5MX3NraXBfdmVydworICAgICAgICAvKiBWRVJXIGNs
b2JiZXJzIFpGLCBidXQgcHJlc2VydmVzIGFsbCBvdGhlcnMsIGluY2x1ZGlu
ZyBTRi4gKi8KKyAgICAgICAgdmVydyBTVEtfUkVMKENQVUlORk9fdmVyd19z
ZWwsIENQVUlORk9fZXJyb3JfY29kZSkoJXJzcCkKKy5MX3NraXBfdmVydzoK
KworICAgICAgICBqbnMgIC5Mdm14X2xhdW5jaAogCiAvKi5Mdm14X3Jlc3Vt
ZToqLwogICAgICAgICBWTVJFU1VNRQpkaWZmIC0tZ2l0IGEveGVuL2FyY2gv
eDg2L3g4Nl82NC9hc20tb2Zmc2V0cy5jIGIveGVuL2FyY2gveDg2L3g4Nl82
NC9hc20tb2Zmc2V0cy5jCmluZGV4IDlkMTA1MTYxZGI1OC4uZWI0YTYxOTg5
MWNiIDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYveDg2XzY0L2FzbS1vZmZz
ZXRzLmMKKysrIGIveGVuL2FyY2gveDg2L3g4Nl82NC9hc20tb2Zmc2V0cy5j
CkBAIC0xMzMsNiArMTMzLDcgQEAgdm9pZCBfX2R1bW15X18odm9pZCkKICNl
bmRpZgogCiAgICAgT0ZGU0VUKENQVUlORk9fZ3Vlc3RfY3B1X3VzZXJfcmVn
cywgc3RydWN0IGNwdV9pbmZvLCBndWVzdF9jcHVfdXNlcl9yZWdzKTsKKyAg
ICBPRkZTRVQoQ1BVSU5GT19lcnJvcl9jb2RlLCBzdHJ1Y3QgY3B1X2luZm8s
IGd1ZXN0X2NwdV91c2VyX3JlZ3MuZXJyb3JfY29kZSk7CiAgICAgT0ZGU0VU
KENQVUlORk9fdmVyd19zZWwsIHN0cnVjdCBjcHVfaW5mbywgdmVyd19zZWwp
OwogICAgIE9GRlNFVChDUFVJTkZPX2N1cnJlbnRfdmNwdSwgc3RydWN0IGNw
dV9pbmZvLCBjdXJyZW50X3ZjcHUpOwogICAgIE9GRlNFVChDUFVJTkZPX3Bl
cl9jcHVfb2Zmc2V0LCBzdHJ1Y3QgY3B1X2luZm8sIHBlcl9jcHVfb2Zmc2V0
KTsKZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL2FzbS14ODYvYXNtX2RlZm5z
LmggYi94ZW4vaW5jbHVkZS9hc20teDg2L2FzbV9kZWZucy5oCmluZGV4IGQ0
ODBhNDQ2MWI4NC4uNGFiNTRmNDFjZjk2IDEwMDY0NAotLS0gYS94ZW4vaW5j
bHVkZS9hc20teDg2L2FzbV9kZWZucy5oCisrKyBiL3hlbi9pbmNsdWRlL2Fz
bS14ODYvYXNtX2RlZm5zLmgKQEAgLTgxLDYgKzgxLDE0IEBAIHJlZ2lzdGVy
IHVuc2lnbmVkIGxvbmcgY3VycmVudF9zdGFja19wb2ludGVyIGFzbSgicnNw
Iik7CiAKICNpZmRlZiBfX0FTU0VNQkxZX18KIAorLm1hY3JvIEJVSUxEX0JV
R19PTiBjb25kc3RyLCBjb25kOnZhcmFyZworICAgICAgICAuaWYgXGNvbmQK
KyAgICAgICAgLmVycm9yICJDb25kaXRpb24gXCJcY29uZHN0clwiIG5vdCBz
YXRpc2ZpZWQiCisgICAgICAgIC5lbmRpZgorLmVuZG0KKy8qIHByZXByb2Nl
c3NvciBtYWNybyB0byBtYWtlIGVycm9yIG1lc3NhZ2UgbW9yZSB1c2VyIGZy
aWVuZGx5ICovCisjZGVmaW5lIEJVSUxEX0JVR19PTihjb25kKSBCVUlMRF9C
VUdfT04gI2NvbmQsIGNvbmQKKwogI2lmZGVmIEhBVkVfQVNfUVVPVEVEX1NZ
TQogI2RlZmluZSBTVUJTRUNUSU9OX0xCTCh0YWcpICAgICAgICAgICAgICAg
ICAgICAgICAgXAogICAgICAgICAuaWZuZGVmIC5MLnRhZzsgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgXApkaWZmIC0tZ2l0IGEveGVuL2luY2x1ZGUv
YXNtLXg4Ni9zcGVjX2N0cmxfYXNtLmggYi94ZW4vaW5jbHVkZS9hc20teDg2
L3NwZWNfY3RybF9hc20uaAppbmRleCBjNDczOTlkYmYyNjEuLmI1ZTU2Njk0
MzYzMiAxMDA2NDQKLS0tIGEveGVuL2luY2x1ZGUvYXNtLXg4Ni9zcGVjX2N0
cmxfYXNtLmgKKysrIGIveGVuL2luY2x1ZGUvYXNtLXg4Ni9zcGVjX2N0cmxf
YXNtLmgKQEAgLTE2NCw2ICsxNjQsMTMgQEAKICNlbmRpZgogLmVuZG0KIAor
LyoKKyAqIEhlbHBlciB0byBpbXByb3ZlIHRoZSByZWFkaWJpbGl0eSBvZiBz
dGFjayBkaXNwYWNlbWVudHMgd2l0aCAlcnNwIGluCisgKiB1bnVzdWFsIHBv
c2l0aW9ucy4gIEJvdGggQGZpZWxkIGFuZCBAdG9wX29mX3N0YWNrIHNob3Vs
ZCBiZSBjb25zdGFudHMgZnJvbQorICogdGhlIHNhbWUgb2JqZWN0LiAgQHRv
cF9vZl9zdGFjayBzaG91bGQgYmUgd2hlcmUgJXJzcCBpcyBjdXJyZW50bHkg
cG9pbnRpbmcuCisgKi8KKyNkZWZpbmUgU1RLX1JFTChmaWVsZCwgdG9wX29m
X3N0aykgKChmaWVsZCkgLSAodG9wX29mX3N0aykpCisKIC5tYWNybyBET19T
UEVDX0NUUkxfQ09ORF9WRVJXCiAvKgogICogUmVxdWlyZXMgJXJzcD1jcHVp
bmZvCg==

--=separator
Content-Type: application/octet-stream; name="xsa452/xsa452-4.15-4.patch"
Content-Disposition: attachment; filename="xsa452/xsa452-4.15-4.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L3NwZWMtY3RybDogUGVyZm9ybSBWRVJXIGZsdXNo
aW5nIGxhdGVyIGluIGV4aXQgcGF0aHMKCk9uIHBhcnRzIHZ1bG5lcmFibGUg
dG8gUkZEUywgVkVSVydzIHNpZGUgZWZmZWN0cyBhcmUgZXh0ZW5kZWQgdG8g
c2NydWIgYWxsCm5vbi1hcmNoaXRlY3R1cmFsIGVudHJpZXMgaW4gdmFyaW91
cyBQaHlzaWNhbCBSZWdpc3RlciBGaWxlcy4gIFRvIHJlbW92ZSBhbGwKb2Yg
WGVuJ3MgdmFsdWVzLCB0aGUgVkVSVyBtdXN0IGJlIGFmdGVyIHBvcHBpbmcg
dGhlIEdQUnMuCgpSZXdvcmsgU1BFQ19DVFJMX0NPTkRfVkVSVyB0byBkZWZh
dWx0IHRvIGFuIENQVUlORk9fZXJyb3JfY29kZSAlcnNwIHBvc2l0aW9uLApi
dXQgd2l0aCBvdmVycmlkZXMgZm9yIG90aGVyIGNvbnRleHRzLiAgSWRlbnRp
ZnkgdGhhdCBpdCBjbG9iYmVycyBlZmxhZ3M7IHRoaXMKaXMgcGFydGljdWxh
cmx5IHJlbGV2YW50IGZvciB0aGUgU1lTUkVUIHBhdGguCgpGb3IgdGhlIElT
VCBleGl0IHJldHVybiB0byBYZW4sIGhhdmUgdGhlIG1haW4gU1BFQ19DVFJM
X0VYSVRfVE9fWEVOIHB1dCBhCnNoYWRvdyBjb3B5IG9mIHNwZWNfY3RybF9m
bGFncywgYXMgR1BScyBjYW4ndCBiZSB1c2VkIGF0IHRoZSBwb2ludCB3ZSB3
YW50IHRvCmlzc3VlIHRoZSBWRVJXLgoKVGhpcyBpcyBwYXJ0IG9mIFhTQS00
NTIgLyBDVkUtMjAyMy0yODc0Ni4KClNpZ25lZC1vZmYtYnk6IEFuZHJldyBD
b29wZXIgPGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+ClJldmlld2VkLWJ5
OiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+CihjaGVycnkgcGlj
a2VkIGZyb20gY29tbWl0IDBhNjY2Y2YyY2Q5OWRmNmZhZjNlZWJjODFhMWZj
Mjg2ZTRlY2E0YzcpCgpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L3g4Nl82
NC9hc20tb2Zmc2V0cy5jIGIveGVuL2FyY2gveDg2L3g4Nl82NC9hc20tb2Zm
c2V0cy5jCmluZGV4IGViNGE2MTk4OTFjYi4uZTNhMzhhZTk2NzQzIDEwMDY0
NAotLS0gYS94ZW4vYXJjaC94ODYveDg2XzY0L2FzbS1vZmZzZXRzLmMKKysr
IGIveGVuL2FyY2gveDg2L3g4Nl82NC9hc20tb2Zmc2V0cy5jCkBAIC01NSwx
NCArNTUsMjIgQEAgdm9pZCBfX2R1bW15X18odm9pZCkKICAgICAgKiBFRlJB
TUVfKiBpcyBmb3IgdGhlIGVudHJ5L2V4aXQgbG9naWMgd2hlcmUgJXJzcCBp
cyBwb2ludGluZyBhdAogICAgICAqIFVSRUdTX2Vycm9yX2NvZGUgYW5kIEdQ
UnMgYXJlIHN0aWxsL2FscmVhZHkgZ3Vlc3QgdmFsdWVzLgogICAgICAqLwot
I2RlZmluZSBPRkZTRVRfRUYoc3ltLCBtZW0pICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgXAorI2RlZmluZSBPRkZTRVRf
RUYoc3ltLCBtZW0sIC4uLikgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgXAogICAgIERFRklORShzeW0sIG9mZnNldG9mKHN0cnVj
dCBjcHVfdXNlcl9yZWdzLCBtZW0pIC0gICAgICAgICAgICAgICAgICAgXAot
ICAgICAgICAgICAgICAgIG9mZnNldG9mKHN0cnVjdCBjcHVfdXNlcl9yZWdz
LCBlcnJvcl9jb2RlKSkKKyAgICAgICAgICAgICAgICBvZmZzZXRvZihzdHJ1
Y3QgY3B1X3VzZXJfcmVncywgZXJyb3JfY29kZSkgX19WQV9BUkdTX18pCiAK
ICAgICBPRkZTRVRfRUYoRUZSQU1FX2VudHJ5X3ZlY3RvciwgICAgZW50cnlf
dmVjdG9yKTsKICAgICBPRkZTRVRfRUYoRUZSQU1FX3JpcCwgICAgICAgICAg
ICAgcmlwKTsKICAgICBPRkZTRVRfRUYoRUZSQU1FX2NzLCAgICAgICAgICAg
ICAgY3MpOwogICAgIE9GRlNFVF9FRihFRlJBTUVfZWZsYWdzLCAgICAgICAg
ICBlZmxhZ3MpOworCisgICAgLyoKKyAgICAgKiBUaGVzZSBhcmVuJ3QgcmVh
bCBmaWVsZHMuICBUaGV5J3JlIHNwYXJlIHNwYWNlLCB1c2VkIGJ5IHRoZSBJ
U1QKKyAgICAgKiBleGl0LXRvLXhlbiBwYXRoLgorICAgICAqLworICAgIE9G
RlNFVF9FRihFRlJBTUVfc2hhZG93X3NjZiwgICAgICBlZmxhZ3MsICs0KTsK
KyAgICBPRkZTRVRfRUYoRUZSQU1FX3NoYWRvd19zZWwsICAgICAgZWZsYWdz
LCArNik7CisKICAgICBPRkZTRVRfRUYoRUZSQU1FX3JzcCwgICAgICAgICAg
ICAgcnNwKTsKICAgICBCTEFOSygpOwogCkBAIC0xMzQsNiArMTQyLDcgQEAg
dm9pZCBfX2R1bW15X18odm9pZCkKIAogICAgIE9GRlNFVChDUFVJTkZPX2d1
ZXN0X2NwdV91c2VyX3JlZ3MsIHN0cnVjdCBjcHVfaW5mbywgZ3Vlc3RfY3B1
X3VzZXJfcmVncyk7CiAgICAgT0ZGU0VUKENQVUlORk9fZXJyb3JfY29kZSwg
c3RydWN0IGNwdV9pbmZvLCBndWVzdF9jcHVfdXNlcl9yZWdzLmVycm9yX2Nv
ZGUpOworICAgIE9GRlNFVChDUFVJTkZPX3JpcCwgc3RydWN0IGNwdV9pbmZv
LCBndWVzdF9jcHVfdXNlcl9yZWdzLnJpcCk7CiAgICAgT0ZGU0VUKENQVUlO
Rk9fdmVyd19zZWwsIHN0cnVjdCBjcHVfaW5mbywgdmVyd19zZWwpOwogICAg
IE9GRlNFVChDUFVJTkZPX2N1cnJlbnRfdmNwdSwgc3RydWN0IGNwdV9pbmZv
LCBjdXJyZW50X3ZjcHUpOwogICAgIE9GRlNFVChDUFVJTkZPX3Blcl9jcHVf
b2Zmc2V0LCBzdHJ1Y3QgY3B1X2luZm8sIHBlcl9jcHVfb2Zmc2V0KTsKZGlm
ZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni94ODZfNjQvY29tcGF0L2VudHJ5LlMg
Yi94ZW4vYXJjaC94ODYveDg2XzY0L2NvbXBhdC9lbnRyeS5TCmluZGV4IDIw
NjAzZWM0YWZjNy4uYmVjYzdmMWJiMmYzIDEwMDY0NAotLS0gYS94ZW4vYXJj
aC94ODYveDg2XzY0L2NvbXBhdC9lbnRyeS5TCisrKyBiL3hlbi9hcmNoL3g4
Ni94ODZfNjQvY29tcGF0L2VudHJ5LlMKQEAgLTE2NSw2ICsxNjUsMTIgQEAg
RU5UUlkoY29tcGF0X3Jlc3RvcmVfYWxsX2d1ZXN0KQogICAgICAgICBTUEVD
X0NUUkxfRVhJVF9UT19QViAgICAvKiBSZXE6IGE9c3BlY19jdHJsICVyc3A9
cmVncy9jcHVpbmZvLCBDbG9iOiBjZCAqLwogCiAgICAgICAgIFJFU1RPUkVf
QUxMIGFkaj04IGNvbXBhdD0xCisKKyAgICAgICAgLyogQWNjb3VudCBmb3Ig
ZXYvZWMgaGF2aW5nIGFscmVhZHkgYmVlbiBwb3BwZWQgb2ZmIHRoZSBzdGFj
ay4gKi8KKyAgICAgICAgU1BFQ19DVFJMX0NPTkRfVkVSVyBcCisgICAgICAg
ICAgICBzY2Y9U1RLX1JFTChDUFVJTkZPX3NwZWNfY3RybF9mbGFncywgQ1BV
SU5GT19yaXApLCBcCisgICAgICAgICAgICBzZWw9U1RLX1JFTChDUFVJTkZP
X3Zlcndfc2VsLCAgICAgICAgQ1BVSU5GT19yaXApCisKIC5MZnQwOiAgaXJl
dHEKICAgICAgICAgX0FTTV9QUkVfRVhUQUJMRSguTGZ0MCwgaGFuZGxlX2V4
Y2VwdGlvbikKIApkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L3g4Nl82NC9l
bnRyeS5TIGIveGVuL2FyY2gveDg2L3g4Nl82NC9lbnRyeS5TCmluZGV4IGZl
MDUyZDI3OTJlOS4uZDg1NWQ0ZDFkNzhlIDEwMDY0NAotLS0gYS94ZW4vYXJj
aC94ODYveDg2XzY0L2VudHJ5LlMKKysrIGIveGVuL2FyY2gveDg2L3g4Nl82
NC9lbnRyeS5TCkBAIC0yMTQsNiArMjE0LDkgQEAgcmVzdG9yZV9hbGxfZ3Vl
c3Q6CiAjZW5kaWYKIAogICAgICAgICBtb3YgICBFRlJBTUVfcmlwKCVyc3Ap
LCAlcmN4CisKKyAgICAgICAgU1BFQ19DVFJMX0NPTkRfVkVSVyAgICAgLyog
UmVxOiAlcnNwPWVmcmFtZSAgICAgICAgICAgICAgICAgICAgQ2xvYjogZWZs
ICovCisKICAgICAgICAgY21wdyAgJEZMQVRfVVNFUl9DUzMyLCBFRlJBTUVf
Y3MoJXJzcCkKICAgICAgICAgbW92ICAgRUZSQU1FX3JzcCglcnNwKSwgJXJz
cAogICAgICAgICBqZSAgICAxZgpAQCAtMjI3LDYgKzIzMCw5IEBAIHJlc3Rv
cmVfYWxsX2d1ZXN0OgogaXJldF9leGl0X3RvX2d1ZXN0OgogICAgICAgICBh
bmRsICAkfihYODZfRUZMQUdTX0lPUEwgfCBYODZfRUZMQUdTX1ZNKSwgRUZS
QU1FX2VmbGFncyglcnNwKQogICAgICAgICBvcmwgICAkWDg2X0VGTEFHU19J
RiwgRUZSQU1FX2VmbGFncyglcnNwKQorCisgICAgICAgIFNQRUNfQ1RSTF9D
T05EX1ZFUlcgICAgIC8qIFJlcTogJXJzcD1lZnJhbWUgICAgICAgICAgICAg
ICAgICAgIENsb2I6IGVmbCAqLworCiAgICAgICAgIGFkZHEgICQ4LCVyc3AK
IC5MZnQwOiAgaXJldHEKICAgICAgICAgX0FTTV9QUkVfRVhUQUJMRSguTGZ0
MCwgaGFuZGxlX2V4Y2VwdGlvbikKQEAgLTYxMyw5ICs2MTksMjIgQEAgVU5M
SUtFTFlfU1RBUlQobmUsIGV4aXRfY3IzKQogVU5MSUtFTFlfRU5EKGV4aXRf
Y3IzKQogCiAgICAgICAgIC8qIFdBUk5JTkchIGByZXRgLCBgY2FsbCAqYCwg
YGptcCAqYCBub3Qgc2FmZSBiZXlvbmQgdGhpcyBwb2ludC4gKi8KLSAgICAg
ICAgU1BFQ19DVFJMX0VYSVRfVE9fWEVOICAgICAvKiBSZXE6ICVyMTI9aXN0
X2V4aXQgJXIxND1lbmQsIENsb2I6IGFiY2QgKi8KKyAgICAgICAgU1BFQ19D
VFJMX0VYSVRfVE9fWEVOIC8qIFJlcTogJXIxMj1pc3RfZXhpdCAlcjE0PWVu
ZCAlcnNwPXJlZ3MsIENsb2I6IGFiY2QgKi8KIAogICAgICAgICBSRVNUT1JF
X0FMTCBhZGo9OAorCisgICAgICAgIC8qCisgICAgICAgICAqIFdoZW4gdGhl
IENQVSBwdXNoZWQgdGhpcyBleGNlcHRpb24gZnJhbWUsIGl0IHplcm8tZXh0
ZW5kZWQgZWZsYWdzLgorICAgICAgICAgKiBGb3IgYW4gSVNUIGV4aXQsIFNQ
RUNfQ1RSTF9FWElUX1RPX1hFTiBzdGFzaGVkIHNoYWRvdyBjb3BpZXMgb2YK
KyAgICAgICAgICogc3BlY19jdHJsX2ZsYWdzIGFuZCB2ZXJfc2VsIGFib3Zl
IGVmbGFncywgYXMgd2UgY2FuJ3QgdXNlIGFueSBHUFJzLAorICAgICAgICAg
KiBhbmQgd2UncmUgYXQgYSByYW5kb20gcGxhY2Ugb24gdGhlIHN0YWNrLCBu
b3QgaW4gYSBDUFVGSU5GTyBibG9jay4KKyAgICAgICAgICoKKyAgICAgICAg
ICogQWNjb3VudCBmb3IgZXYvZWMgaGF2aW5nIGFscmVhZHkgYmVlbiBwb3Bw
ZWQgb2ZmIHRoZSBzdGFjay4KKyAgICAgICAgICovCisgICAgICAgIFNQRUNf
Q1RSTF9DT05EX1ZFUlcgXAorICAgICAgICAgICAgc2NmPVNUS19SRUwoRUZS
QU1FX3NoYWRvd19zY2YsIEVGUkFNRV9yaXApLCBcCisgICAgICAgICAgICBz
ZWw9U1RLX1JFTChFRlJBTUVfc2hhZG93X3NlbCwgRUZSQU1FX3JpcCkKKwog
ICAgICAgICBpcmV0cQogCiBFTlRSWShjb21tb25faW50ZXJydXB0KQpkaWZm
IC0tZ2l0IGEveGVuL2luY2x1ZGUvYXNtLXg4Ni9zcGVjX2N0cmxfYXNtLmgg
Yi94ZW4vaW5jbHVkZS9hc20teDg2L3NwZWNfY3RybF9hc20uaAppbmRleCBi
NWU1NjY5NDM2MzIuLjk2NTBhM2FjYTdjMyAxMDA2NDQKLS0tIGEveGVuL2lu
Y2x1ZGUvYXNtLXg4Ni9zcGVjX2N0cmxfYXNtLmgKKysrIGIveGVuL2luY2x1
ZGUvYXNtLXg4Ni9zcGVjX2N0cmxfYXNtLmgKQEAgLTE3MSwxNiArMTcxLDIz
IEBACiAgKi8KICNkZWZpbmUgU1RLX1JFTChmaWVsZCwgdG9wX29mX3N0aykg
KChmaWVsZCkgLSAodG9wX29mX3N0aykpCiAKLS5tYWNybyBET19TUEVDX0NU
UkxfQ09ORF9WRVJXCisubWFjcm8gU1BFQ19DVFJMX0NPTkRfVkVSVyBcCisg
ICAgc2NmPVNUS19SRUwoQ1BVSU5GT19zcGVjX2N0cmxfZmxhZ3MsIENQVUlO
Rk9fZXJyb3JfY29kZSksIFwKKyAgICBzZWw9U1RLX1JFTChDUFVJTkZPX3Zl
cndfc2VsLCAgICAgICAgQ1BVSU5GT19lcnJvcl9jb2RlKQogLyoKLSAqIFJl
cXVpcmVzICVyc3A9Y3B1aW5mbworICogUmVxdWlyZXMgXHNjZiBhbmQgXHNl
bCBhcyAlcnNwLXJlbGF0aXZlIGV4cHJlc3Npb25zCisgKiBDbG9iYmVycyBl
ZmxhZ3MKKyAqCisgKiBWRVJXIG5lZWRzIHRvIHJ1biBhZnRlciBndWVzdCBH
UFJzIGhhdmUgYmVlbiByZXN0b3JlZCwgd2hlcmUgb25seSAlcnNwIGlzCisg
KiBnb29kIHRvIHVzZS4gIERlZmF1bHQgdG8gZXhwZWN0aW5nICVyc3AgcG9p
bnRpbmcgYXQgQ1BVSU5GT19lcnJvcl9jb2RlLgorICogQ29udGV4dHMgd2hl
cmUgdGhpcyBpcyBub3QgdHJ1ZSBtdXN0IHByb3ZpZGUgYW4gYWx0ZXJuYXRp
dmUgXHNjZiBhbmQgXHNlbC4KICAqCiAgKiBJc3N1ZSBhIFZFUlcgZm9yIGl0
cyBmbHVzaGluZyBzaWRlIGVmZmVjdCwgaWYgaW5kaWNhdGVkLiAgVGhpcyBp
cyBhIFNwZWN0cmUKICAqIHYxIGdhZGdldCwgYnV0IHRoZSBJUkVUL1ZNRW50
cnkgaXMgc2VyaWFsaXNpbmcuCiAgKi8KLSAgICB0ZXN0YiAkU0NGX3Zlcncs
IENQVUlORk9fc3BlY19jdHJsX2ZsYWdzKCVyc3ApCisgICAgdGVzdGIgJFND
Rl92ZXJ3LCBcc2NmKCVyc3ApCiAgICAganogLkxcQF92ZXJ3X3NraXAKLSAg
ICB2ZXJ3IENQVUlORk9fdmVyd19zZWwoJXJzcCkKKyAgICB2ZXJ3IFxzZWwo
JXJzcCkKIC5MXEBfdmVyd19za2lwOgogLmVuZG0KIApAQCAtMjk4LDggKzMw
NSw2IEBACiAgKi8KICAgICBBTFRFUk5BVElWRSAiIiwgRE9fU1BFQ19DVFJM
X0VYSVRfVE9fR1VFU1QsIFg4Nl9GRUFUVVJFX1NDX01TUl9QVgogCi0gICAg
RE9fU1BFQ19DVFJMX0NPTkRfVkVSVwotCiAgICAgQUxURVJOQVRJVkUgIiIs
IERPX1NQRUNfQ1RSTF9ESVYsIFg4Nl9GRUFUVVJFX1NDX0RJVgogLmVuZG0K
IApAQCAtMzc5LDcgKzM4NCw3IEBAIFVOTElLRUxZX0RJU1BBVENIX0xBQkVM
KFxAX3NlcmlhbGlzZSk6CiAgKi8KIC5tYWNybyBTUEVDX0NUUkxfRVhJVF9U
T19YRU4KIC8qCi0gKiBSZXF1aXJlcyAlcjEyPWlzdF9leGl0LCAlcjE0PXN0
YWNrX2VuZAorICogUmVxdWlyZXMgJXIxMj1pc3RfZXhpdCwgJXIxND1zdGFj
a19lbmQsICVyc3A9cmVncwogICogQ2xvYmJlcnMgJXJheCwgJXJieCwgJXJj
eCwgJXJkeAogICovCiAgICAgbW92emJsIFNUQUNLX0NQVUlORk9fRklFTEQo
c3BlY19jdHJsX2ZsYWdzKSglcjE0KSwgJWVieApAQCAtNDA3LDExICs0MTIs
MTggQEAgVU5MSUtFTFlfRElTUEFUQ0hfTEFCRUwoXEBfc2VyaWFsaXNlKToK
ICAgICB0ZXN0ICVyMTIsICVyMTIKICAgICBqeiAuTFxAX3NraXBfaXN0X2V4
aXQKIAotICAgIC8qIExvZ2ljYWxseSBET19TUEVDX0NUUkxfQ09ORF9WRVJX
IGJ1dCB3aXRob3V0IHRoZSAlcnNwPWNwdWluZm8gZGVwZW5kZW5jeSAqLwot
ICAgIHRlc3RiICRTQ0ZfdmVydywgJWJsCi0gICAganogLkxcQF9za2lwX3Zl
cncKLSAgICB2ZXJ3IFNUQUNLX0NQVUlORk9fRklFTEQodmVyd19zZWwpKCVy
MTQpCi0uTFxAX3NraXBfdmVydzoKKyAgICAvKgorICAgICAqIFN0YXNoIFND
RiBhbmQgdmVyd19zZWwgYWJvdmUgZWZsYWdzIGluIHRoZSBjYXNlIG9mIGFu
IElTVF9leGl0LiAgVGhlCisgICAgICogVkVSVyBsb2dpYyBuZWVkcyB0byBy
dW4gYWZ0ZXIgZ3Vlc3QgR1BScyBoYXZlIGJlZW4gcmVzdG9yZWQ7IGkuZS4g
d2hlcmUKKyAgICAgKiB3ZSBjYW5ub3QgdXNlICVyMTIgb3IgJXIxNCBmb3Ig
dGhlIHB1cnBvc2VzIHRoZXkgaGF2ZSBoZXJlLgorICAgICAqCisgICAgICog
V2hlbiB0aGUgQ1BVIHB1c2hlZCB0aGlzIGV4Y2VwdGlvbiBmcmFtZSwgaXQg
emVyby1leHRlbmRlZCBlZmxhZ3MuCisgICAgICogVGhlcmVmb3JlIGl0IGlz
IHNhZmUgZm9yIHRoZSBWRVJXIGxvZ2ljIHRvIGxvb2sgYXQgdGhlIHN0YXNo
ZWQgU0NGCisgICAgICogb3V0c2lkZSBvZiB0aGUgaXN0X2V4aXQgY29uZGl0
aW9uLiAgQWxzbywgdGhpcyBzdGFzaGluZyB3b24ndCBpbmZsdWVuY2UKKyAg
ICAgKiBhbnkgb3RoZXIgcmVzdG9yZV9hbGxfZ3Vlc3QoKSBwYXRocy4KKyAg
ICAgKi8KKyAgICBvciAkKF9fSFlQRVJWSVNPUl9EUzMyIDw8IDE2KSwgJWVi
eAorICAgIG1vdiAlZWJ4LCBVUkVHU19lZmxhZ3MgKyA0KCVyc3ApIC8qIEVG
UkFNRV9zaGFkb3dfc2NmL3NlbCAqLwogCiAgICAgQUxURVJOQVRJVkUgIiIs
IERPX1NQRUNfQ1RSTF9ESVYsIFg4Nl9GRUFUVVJFX1NDX0RJVgogCg==

--=separator
Content-Type: application/octet-stream; name="xsa452/xsa452-4.15-5.patch"
Content-Disposition: attachment; filename="xsa452/xsa452-4.15-5.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L3NwZWMtY3RybDogUmVuYW1lIFZFUlcgcmVsYXRl
ZCBvcHRpb25zCgpWRVJXIGlzIGdvaW5nIHRvIGJlIHVzZWQgZm9yIGEgM3Jk
IHB1cnBvc2UsIGFuZCB0aGUgZXhpc3Rpbmcgbm9tZW5jbGF0dXJlCmRpZG4n
dCBzdXJ2aXZlIHRoZSBTdGFsZSBNTUlPIGlzc3VlcyB0ZXJyaWJseSB3ZWxs
LgoKUmVuYW1lIHRoZSBjb21tYW5kIGxpbmUgb3B0aW9uIGZyb20gYG1kLWNs
ZWFyPWAgdG8gYHZlcnc9YC4gIFRoaXMgaXMgbW9yZQpjb25zaXN0ZW50IHdp
dGggb3RoZXIgb3B0aW9ucyB3aGljaCB0ZW5kIHRvIGJlIG5hbWVkIGJhc2Vk
IG9uIHdoYXQgdGhleSdyZQpkb2luZywgbm90IHdoaWNoIGZlYXR1cmUgZW51
bWVyYXRpb24gdGhleSB1c2UgYmVoaW5kIHRoZSBzY2VuZXMuICBSZXRhaW4K
YG1kLWNsZWFyPWAgYXMgYSBkZXByZWNhdGVkIGFsaWFzLgoKUmVuYW1lIG9w
dF9tZF9jbGVhcl97cHYsaHZtfSBhbmQgb3B0X2ZiX2NsZWFyX21taW8gdG8g
b3B0X3Zlcndfe3B2LGh2bSxtbWlvfSwKd2hpY2ggaGFzIGEgc2lkZSBlZmZl
Y3Qgb2YgbWFraW5nIHNwZWNfY3RybF9pbml0X2RvbWFpbigpIHJhdGhlciBj
bGVhcmVyIHRvCmZvbGxvdy4KCk5vIGZ1bmN0aW9uYWwgY2hhbmdlLgoKVGhp
cyBpcyBwYXJ0IG9mIFhTQS00NTIgLyBDVkUtMjAyMy0yODc0Ni4KClNpZ25l
ZC1vZmYtYnk6IEFuZHJldyBDb29wZXIgPGFuZHJldy5jb29wZXIzQGNpdHJp
eC5jb20+ClJldmlld2VkLWJ5OiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3Vz
ZS5jb20+CihjaGVycnkgcGlja2VkIGZyb20gY29tbWl0IGY3NjAzY2EyNTJl
NDIyNjczOWViMzEyOWE1MjkwZWUzZGEzZjhlYTQpCgpkaWZmIC0tZ2l0IGEv
ZG9jcy9taXNjL3hlbi1jb21tYW5kLWxpbmUucGFuZG9jIGIvZG9jcy9taXNj
L3hlbi1jb21tYW5kLWxpbmUucGFuZG9jCmluZGV4IGYzZDEwMDlmMmRhZi4u
ZDAyMGQ3OWRkZTI1IDEwMDY0NAotLS0gYS9kb2NzL21pc2MveGVuLWNvbW1h
bmQtbGluZS5wYW5kb2MKKysrIGIvZG9jcy9taXNjL3hlbi1jb21tYW5kLWxp
bmUucGFuZG9jCkBAIC0yMTg2LDcgKzIxODYsNyBAQCBCeSBkZWZhdWx0IFNT
QkQgd2lsbCBiZSBtaXRpZ2F0ZWQgYXQgcnVudGltZSAoaS5lIGBzc2JkPXJ1
bnRpbWVgKS4KIAogIyMjIHNwZWMtY3RybCAoeDg2KQogPiBgPSBMaXN0IG9m
IFsgPGJvb2w+LCB4ZW49PGJvb2w+LCB7cHYsaHZtfT08Ym9vbD4sCi0+ICAg
ICAgICAgICAgICB7bXNyLXNjLHJzYixtZC1jbGVhcixpYnBiLWVudHJ5fT08
Ym9vbD58e3B2LGh2bX09PGJvb2w+LAorPiAgICAgICAgICAgICAge21zci1z
Yyxyc2IsdmVydyxpYnBiLWVudHJ5fT08Ym9vbD58e3B2LGh2bX09PGJvb2w+
LAogPiAgICAgICAgICAgICAgYnRpLXRodW5rPXJldHBvbGluZXxsZmVuY2V8
am1wLCB7aWJycyxpYnBiLHNzYmQscHNmZCwKID4gICAgICAgICAgICAgIGVh
Z2VyLWZwdSxsMWQtZmx1c2gsYnJhbmNoLWhhcmRlbixzcmItbG9jaywKID4g
ICAgICAgICAgICAgIHVucHJpdi1tbWlvLGdkcy1taXQsZGl2LXNjcnVifT08
Ym9vbD4gXWAKQEAgLTIyMTEsNyArMjIxMSw3IEBAIGluIHBsYWNlIGZvciBn
dWVzdHMgdG8gdXNlLgogCiBVc2Ugb2YgYSBwb3NpdGl2ZSBib29sZWFuIHZh
bHVlIGZvciBlaXRoZXIgb2YgdGhlc2Ugb3B0aW9ucyBpcyBpbnZhbGlkLgog
Ci1UaGUgYHB2PWAsIGBodm09YCwgYG1zci1zYz1gLCBgcnNiPWAsIGBtZC1j
bGVhcj1gIGFuZCBgaWJwYi1lbnRyeT1gIG9wdGlvbnMKK1RoZSBgcHY9YCwg
YGh2bT1gLCBgbXNyLXNjPWAsIGByc2I9YCwgYHZlcnc9YCBhbmQgYGlicGIt
ZW50cnk9YCBvcHRpb25zCiBvZmZlciBmaW5lIGdyYWluZWQgY29udHJvbCBv
dmVyIHRoZSBwcmltaXRpdmVzIGJ5IFhlbi4gIFRoZXNlIGltcGFjdCBYZW4n
cwogYWJpbGl0eSB0byBwcm90ZWN0IGl0c2VsZiwgYW5kL29yIFhlbidzIGFi
aWxpdHkgdG8gdmlydHVhbGlzZSBzdXBwb3J0IGZvcgogZ3Vlc3RzIHRvIHVz
ZS4KQEAgLTIyMjgsMTEgKzIyMjgsMTIgQEAgZ3Vlc3RzIHRvIHVzZS4KICAg
Z3Vlc3RzIGFuZCBpZiBkaXNhYmxlZCwgZ3Vlc3RzIHdpbGwgYmUgdW5hYmxl
IHRvIHVzZSBJQlJTL1NUSUJQL1NTQkQvZXRjLgogKiBgcnNiPWAgb2ZmZXJz
IGNvbnRyb2wgb3ZlciB3aGV0aGVyIHRvIG92ZXJ3cml0ZSB0aGUgUmV0dXJu
IFN0YWNrIEJ1ZmZlciAvCiAgIFJldHVybiBBZGRyZXNzIFN0YWNrIG9uIGVu
dHJ5IHRvIFhlbi4KLSogYG1kLWNsZWFyPWAgb2ZmZXJzIGNvbnRyb2wgb3Zl
ciB3aGV0aGVyIHRvIHVzZSBWRVJXIHRvIGZsdXNoCi0gIG1pY3JvYXJjaGl0
ZWN0dXJhbCBidWZmZXJzIG9uIGlkbGUgYW5kIGV4aXQgZnJvbSBYZW4uICAq
Tm90ZTogRm9yCi0gIGNvbXBhdGliaWxpdHkgd2l0aCBkZXZlbG9wbWVudCB2
ZXJzaW9ucyBvZiB0aGlzIGZpeCwgYG1kcz1gIGlzIGFsc28gYWNjZXB0ZWQK
LSAgb24gWGVuIDQuMTIgYW5kIGVhcmxpZXIgYXMgYW4gYWxpYXMuICBDb25z
dWx0IHZlbmRvciBkb2N1bWVudGF0aW9uIGluCi0gIHByZWZlcmVuY2UgdG8g
aGVyZS4qCisqIGB2ZXJ3PWAgb2ZmZXJzIGNvbnRyb2wgb3ZlciB3aGV0aGVy
IHRvIHVzZSBWRVJXIGZvciBpdHMgc2NydWJiaW5nIHNpZGUKKyAgZWZmZWN0
cyBhdCBhcHByb3ByaWF0ZSBwcml2aWxlZ2UgdHJhbnNpdGlvbnMuICBUaGUg
ZXhhY3Qgc2lkZSBlZmZlY3RzIGFyZQorICBtaWNyb2FyY2hpdGVjdHVyZSBh
bmQgbWljcm9jb2RlIHNwZWNpZmljLiAgKk5vdGU6IGBtZC1jbGVhcj1gIGlz
IGFjY2VwdGVkIGFzCisgIGEgZGVwcmVjYXRlZCBhbGlhcy4gIEZvciBjb21w
YXRpYmlsaXR5IHdpdGggZGV2ZWxvcG1lbnQgdmVyc2lvbnMgb2YgWFNBLTI5
NywKKyAgYG1kcz1gIGlzIGFsc28gYWNjZXB0ZWQgb24gWGVuIDQuMTIgYW5k
IGVhcmxpZXIgYXMgYW4gYWxpYXMuICBDb25zdWx0IHZlbmRvcgorICBkb2N1
bWVudGF0aW9uIGluIHByZWZlcmVuY2UgdG8gaGVyZS4qCiAqIGBpYnBiLWVu
dHJ5PWAgb2ZmZXJzIGNvbnRyb2wgb3ZlciB3aGV0aGVyIElCUEIgKEluZGly
ZWN0IEJyYW5jaCBQcmVkaWN0aW9uCiAgIEJhcnJpZXIpIGlzIHVzZWQgb24g
ZW50cnkgdG8gWGVuLiAgVGhpcyBpcyB1c2VkIGJ5IGRlZmF1bHQgb24gaGFy
ZHdhcmUKICAgdnVsbmVyYWJsZSB0byBCcmFuY2ggVHlwZSBDb25mdXNpb24s
IGFuZCBoYXJkd2FyZSB2dWxuZXJhYmxlIHRvIFNwZWN1bGF0aXZlCmRpZmYg
LS1naXQgYS94ZW4vYXJjaC94ODYvc3BlY19jdHJsLmMgYi94ZW4vYXJjaC94
ODYvc3BlY19jdHJsLmMKaW5kZXggZjc1MTI0MTE3YjZkLi40MzQ0OWI0Yzdh
MTkgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9zcGVjX2N0cmwuYworKysg
Yi94ZW4vYXJjaC94ODYvc3BlY19jdHJsLmMKQEAgLTM3LDggKzM3LDggQEAg
c3RhdGljIGJvb2wgX19pbml0ZGF0YSBvcHRfbXNyX3NjX3B2ID0gdHJ1ZTsK
IHN0YXRpYyBib29sIF9faW5pdGRhdGEgb3B0X21zcl9zY19odm0gPSB0cnVl
Owogc3RhdGljIGJvb2wgX19pbml0ZGF0YSBvcHRfcnNiX3B2ID0gdHJ1ZTsK
IHN0YXRpYyBib29sIF9faW5pdGRhdGEgb3B0X3JzYl9odm0gPSB0cnVlOwot
c3RhdGljIGludDhfdCBfX3JlYWRfbW9zdGx5IG9wdF9tZF9jbGVhcl9wdiA9
IC0xOwotc3RhdGljIGludDhfdCBfX3JlYWRfbW9zdGx5IG9wdF9tZF9jbGVh
cl9odm0gPSAtMTsKK3N0YXRpYyBpbnQ4X3QgX19yZWFkX21vc3RseSBvcHRf
dmVyd19wdiA9IC0xOworc3RhdGljIGludDhfdCBfX3JlYWRfbW9zdGx5IG9w
dF92ZXJ3X2h2bSA9IC0xOwogCiBzdGF0aWMgaW50OF90IF9fcmVhZF9tb3N0
bHkgb3B0X2licGJfZW50cnlfcHYgPSAtMTsKIHN0YXRpYyBpbnQ4X3QgX19y
ZWFkX21vc3RseSBvcHRfaWJwYl9lbnRyeV9odm0gPSAtMTsKQEAgLTc3LDcg
Kzc3LDcgQEAgc3RhdGljIGJvb2wgX19pbml0ZGF0YSBjcHVfaGFzX2J1Z19t
ZHM7IC8qIEFueSBvdGhlciBNe0xQLFNCLEZCfURTIGNvbWJpbmF0aW9uLgog
CiBzdGF0aWMgaW50OF90IF9faW5pdGRhdGEgb3B0X3NyYl9sb2NrID0gLTE7
CiBzdGF0aWMgYm9vbCBfX2luaXRkYXRhIG9wdF91bnByaXZfbW1pbzsKLXN0
YXRpYyBib29sIF9fcmVhZF9tb3N0bHkgb3B0X2ZiX2NsZWFyX21taW87Citz
dGF0aWMgYm9vbCBfX3JlYWRfbW9zdGx5IG9wdF92ZXJ3X21taW87CiBzdGF0
aWMgaW50OF90IF9faW5pdGRhdGEgb3B0X2dkc19taXQgPSAtMTsKIHN0YXRp
YyBpbnQ4X3QgX19pbml0ZGF0YSBvcHRfZGl2X3NjcnViID0gLTE7CiAKQEAg
LTExOSw4ICsxMTksOCBAQCBzdGF0aWMgaW50IF9faW5pdCBwYXJzZV9zcGVj
X2N0cmwoY29uc3QgY2hhciAqcykKICAgICAgICAgZGlzYWJsZV9jb21tb246
CiAgICAgICAgICAgICBvcHRfcnNiX3B2ID0gZmFsc2U7CiAgICAgICAgICAg
ICBvcHRfcnNiX2h2bSA9IGZhbHNlOwotICAgICAgICAgICAgb3B0X21kX2Ns
ZWFyX3B2ID0gMDsKLSAgICAgICAgICAgIG9wdF9tZF9jbGVhcl9odm0gPSAw
OworICAgICAgICAgICAgb3B0X3ZlcndfcHYgPSAwOworICAgICAgICAgICAg
b3B0X3ZlcndfaHZtID0gMDsKICAgICAgICAgICAgIG9wdF9pYnBiX2VudHJ5
X3B2ID0gMDsKICAgICAgICAgICAgIG9wdF9pYnBiX2VudHJ5X2h2bSA9IDA7
CiAgICAgICAgICAgICBvcHRfaWJwYl9lbnRyeV9kb20wID0gZmFsc2U7CkBA
IC0xNTEsMTQgKzE1MSwxNCBAQCBzdGF0aWMgaW50IF9faW5pdCBwYXJzZV9z
cGVjX2N0cmwoY29uc3QgY2hhciAqcykKICAgICAgICAgewogICAgICAgICAg
ICAgb3B0X21zcl9zY19wdiA9IHZhbDsKICAgICAgICAgICAgIG9wdF9yc2Jf
cHYgPSB2YWw7Ci0gICAgICAgICAgICBvcHRfbWRfY2xlYXJfcHYgPSB2YWw7
CisgICAgICAgICAgICBvcHRfdmVyd19wdiA9IHZhbDsKICAgICAgICAgICAg
IG9wdF9pYnBiX2VudHJ5X3B2ID0gdmFsOwogICAgICAgICB9CiAgICAgICAg
IGVsc2UgaWYgKCAodmFsID0gcGFyc2VfYm9vbGVhbigiaHZtIiwgcywgc3Mp
KSA+PSAwICkKICAgICAgICAgewogICAgICAgICAgICAgb3B0X21zcl9zY19o
dm0gPSB2YWw7CiAgICAgICAgICAgICBvcHRfcnNiX2h2bSA9IHZhbDsKLSAg
ICAgICAgICAgIG9wdF9tZF9jbGVhcl9odm0gPSB2YWw7CisgICAgICAgICAg
ICBvcHRfdmVyd19odm0gPSB2YWw7CiAgICAgICAgICAgICBvcHRfaWJwYl9l
bnRyeV9odm0gPSB2YWw7CiAgICAgICAgIH0KICAgICAgICAgZWxzZSBpZiAo
ICh2YWwgPSBwYXJzZV9ib29sZWFuKCJtc3Itc2MiLCBzLCBzcykpICE9IC0x
ICkKQEAgLTIwMywyMSArMjAzLDIyIEBAIHN0YXRpYyBpbnQgX19pbml0IHBh
cnNlX3NwZWNfY3RybChjb25zdCBjaGFyICpzKQogICAgICAgICAgICAgICAg
IGJyZWFrOwogICAgICAgICAgICAgfQogICAgICAgICB9Ci0gICAgICAgIGVs
c2UgaWYgKCAodmFsID0gcGFyc2VfYm9vbGVhbigibWQtY2xlYXIiLCBzLCBz
cykpICE9IC0xICkKKyAgICAgICAgZWxzZSBpZiAoICh2YWwgPSBwYXJzZV9i
b29sZWFuKCJ2ZXJ3Iiwgcywgc3MpKSAhPSAtMSB8fAorICAgICAgICAgICAg
ICAgICAgKHZhbCA9IHBhcnNlX2Jvb2xlYW4oIm1kLWNsZWFyIiwgcywgc3Mp
KSAhPSAtMSApCiAgICAgICAgIHsKICAgICAgICAgICAgIHN3aXRjaCAoIHZh
bCApCiAgICAgICAgICAgICB7CiAgICAgICAgICAgICBjYXNlIDA6CiAgICAg
ICAgICAgICBjYXNlIDE6Ci0gICAgICAgICAgICAgICAgb3B0X21kX2NsZWFy
X3B2ID0gb3B0X21kX2NsZWFyX2h2bSA9IHZhbDsKKyAgICAgICAgICAgICAg
ICBvcHRfdmVyd19wdiA9IG9wdF92ZXJ3X2h2bSA9IHZhbDsKICAgICAgICAg
ICAgICAgICBicmVhazsKIAogICAgICAgICAgICAgY2FzZSAtMjoKLSAgICAg
ICAgICAgICAgICBzICs9IHN0cmxlbigibWQtY2xlYXI9Iik7CisgICAgICAg
ICAgICAgICAgcyArPSAoKnMgPT0gJ3YnKSA/IHN0cmxlbigidmVydz0iKSA6
IHN0cmxlbigibWQtY2xlYXI9Iik7CiAgICAgICAgICAgICAgICAgaWYgKCAo
dmFsID0gcGFyc2VfYm9vbGVhbigicHYiLCBzLCBzcykpID49IDAgKQotICAg
ICAgICAgICAgICAgICAgICBvcHRfbWRfY2xlYXJfcHYgPSB2YWw7CisgICAg
ICAgICAgICAgICAgICAgIG9wdF92ZXJ3X3B2ID0gdmFsOwogICAgICAgICAg
ICAgICAgIGVsc2UgaWYgKCAodmFsID0gcGFyc2VfYm9vbGVhbigiaHZtIiwg
cywgc3MpKSA+PSAwICkKLSAgICAgICAgICAgICAgICAgICAgb3B0X21kX2Ns
ZWFyX2h2bSA9IHZhbDsKKyAgICAgICAgICAgICAgICAgICAgb3B0X3Zlcndf
aHZtID0gdmFsOwogICAgICAgICAgICAgICAgIGVsc2UKICAgICAgICAgICAg
IGRlZmF1bHQ6CiAgICAgICAgICAgICAgICAgICAgIHJjID0gLUVJTlZBTDsK
QEAgLTUxMiw4ICs1MTMsOCBAQCBzdGF0aWMgdm9pZCBfX2luaXQgcHJpbnRf
ZGV0YWlscyhlbnVtIGluZF90aHVuayB0aHVuaykKICAgICAgICAgICAgb3B0
X3NyYl9sb2NrICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPyAiIFNS
Ql9MT0NLKyIgOiAiIFNSQl9MT0NLLSIsCiAgICAgICAgICAgIG9wdF9pYnBi
X2N0eHRfc3dpdGNoICAgICAgICAgICAgICAgICAgICAgID8gIiBJQlBCLWN0
eHQiIDogIiIsCiAgICAgICAgICAgIG9wdF9sMWRfZmx1c2ggICAgICAgICAg
ICAgICAgICAgICAgICAgICAgID8gIiBMMURfRkxVU0giIDogIiIsCi0gICAg
ICAgICAgIG9wdF9tZF9jbGVhcl9wdiB8fCBvcHRfbWRfY2xlYXJfaHZtIHx8
Ci0gICAgICAgICAgIG9wdF9mYl9jbGVhcl9tbWlvICAgICAgICAgICAgICAg
ICAgICAgICAgID8gIiBWRVJXIiAgOiAiIiwKKyAgICAgICAgICAgb3B0X3Zl
cndfcHYgfHwgb3B0X3ZlcndfaHZtIHx8CisgICAgICAgICAgIG9wdF92ZXJ3
X21taW8gICAgICAgICAgICAgICAgICAgICAgICAgICAgID8gIiBWRVJXIiAg
OiAiIiwKICAgICAgICAgICAgb3B0X2Rpdl9zY3J1YiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgPyAiIERJViIgOiAiIiwKICAgICAgICAgICAgb3B0
X2JyYW5jaF9oYXJkZW4gICAgICAgICAgICAgICAgICAgICAgICAgPyAiIEJS
QU5DSF9IQVJERU4iIDogIiIpOwogCkBAIC01MzMsMTEgKzUzNCwxMSBAQCBz
dGF0aWMgdm9pZCBfX2luaXQgcHJpbnRfZGV0YWlscyhlbnVtIGluZF90aHVu
ayB0aHVuaykKICAgICAgICAgICAgKGJvb3RfY3B1X2hhcyhYODZfRkVBVFVS
RV9TQ19NU1JfSFZNKSB8fAogICAgICAgICAgICAgYm9vdF9jcHVfaGFzKFg4
Nl9GRUFUVVJFX1NDX1JTQl9IVk0pIHx8CiAgICAgICAgICAgICBib290X2Nw
dV9oYXMoWDg2X0ZFQVRVUkVfSUJQQl9FTlRSWV9IVk0pIHx8Ci0gICAgICAg
ICAgICBvcHRfZWFnZXJfZnB1IHx8IG9wdF9tZF9jbGVhcl9odm0pICAgICAg
ID8gIiIgICAgICAgICAgICAgICA6ICIgTm9uZSIsCisgICAgICAgICAgICBv
cHRfZWFnZXJfZnB1IHx8IG9wdF92ZXJ3X2h2bSkgICAgICAgICAgID8gIiIg
ICAgICAgICAgICAgICA6ICIgTm9uZSIsCiAgICAgICAgICAgIGJvb3RfY3B1
X2hhcyhYODZfRkVBVFVSRV9TQ19NU1JfSFZNKSAgICAgID8gIiBNU1JfU1BF
Q19DVFJMIiA6ICIiLAogICAgICAgICAgICBib290X2NwdV9oYXMoWDg2X0ZF
QVRVUkVfU0NfUlNCX0hWTSkgICAgICA/ICIgUlNCIiAgICAgICAgICAgOiAi
IiwKICAgICAgICAgICAgb3B0X2VhZ2VyX2ZwdSAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgPyAiIEVBR0VSX0ZQVSIgICAgIDogIiIsCi0gICAgICAg
ICAgIG9wdF9tZF9jbGVhcl9odm0gICAgICAgICAgICAgICAgICAgICAgICAg
ID8gIiBNRF9DTEVBUiIgICAgICA6ICIiLAorICAgICAgICAgICBvcHRfdmVy
d19odm0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICA/ICIgVkVSVyIg
ICAgICAgICAgOiAiIiwKICAgICAgICAgICAgYm9vdF9jcHVfaGFzKFg4Nl9G
RUFUVVJFX0lCUEJfRU5UUllfSFZNKSAgPyAiIElCUEItZW50cnkiICAgIDog
IiIpOwogCiAjZW5kaWYKQEAgLTU0NiwxMSArNTQ3LDExIEBAIHN0YXRpYyB2
b2lkIF9faW5pdCBwcmludF9kZXRhaWxzKGVudW0gaW5kX3RodW5rIHRodW5r
KQogICAgICAgICAgICAoYm9vdF9jcHVfaGFzKFg4Nl9GRUFUVVJFX1NDX01T
Ul9QVikgfHwKICAgICAgICAgICAgIGJvb3RfY3B1X2hhcyhYODZfRkVBVFVS
RV9TQ19SU0JfUFYpIHx8CiAgICAgICAgICAgICBib290X2NwdV9oYXMoWDg2
X0ZFQVRVUkVfSUJQQl9FTlRSWV9QVikgfHwKLSAgICAgICAgICAgIG9wdF9l
YWdlcl9mcHUgfHwgb3B0X21kX2NsZWFyX3B2KSAgICAgICAgPyAiIiAgICAg
ICAgICAgICAgIDogIiBOb25lIiwKKyAgICAgICAgICAgIG9wdF9lYWdlcl9m
cHUgfHwgb3B0X3ZlcndfcHYpICAgICAgICAgICAgPyAiIiAgICAgICAgICAg
ICAgIDogIiBOb25lIiwKICAgICAgICAgICAgYm9vdF9jcHVfaGFzKFg4Nl9G
RUFUVVJFX1NDX01TUl9QVikgICAgICAgPyAiIE1TUl9TUEVDX0NUUkwiIDog
IiIsCiAgICAgICAgICAgIGJvb3RfY3B1X2hhcyhYODZfRkVBVFVSRV9TQ19S
U0JfUFYpICAgICAgID8gIiBSU0IiICAgICAgICAgICA6ICIiLAogICAgICAg
ICAgICBvcHRfZWFnZXJfZnB1ICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICA/ICIgRUFHRVJfRlBVIiAgICAgOiAiIiwKLSAgICAgICAgICAgb3B0X21k
X2NsZWFyX3B2ICAgICAgICAgICAgICAgICAgICAgICAgICAgPyAiIE1EX0NM
RUFSIiAgICAgIDogIiIsCisgICAgICAgICAgIG9wdF92ZXJ3X3B2ICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgID8gIiBWRVJXIiAgICAgICAgICA6
ICIiLAogICAgICAgICAgICBib290X2NwdV9oYXMoWDg2X0ZFQVRVUkVfSUJQ
Ql9FTlRSWV9QVikgICA/ICIgSUJQQi1lbnRyeSIgICAgOiAiIik7CiAKICAg
ICBwcmludGsoIiAgWFBUSSAoNjQtYml0IFBWIG9ubHkpOiBEb20wICVzLCBE
b21VICVzICh3aXRoJXMgUENJRClcbiIsCkBAIC0xNDUwLDggKzE0NTEsOCBA
QCB2b2lkIHNwZWNfY3RybF9pbml0X2RvbWFpbihzdHJ1Y3QgZG9tYWluICpk
KQogewogICAgIGJvb2wgcHYgPSBpc19wdl9kb21haW4oZCk7CiAKLSAgICBi
b29sIHZlcncgPSAoKHB2ID8gb3B0X21kX2NsZWFyX3B2IDogb3B0X21kX2Ns
ZWFyX2h2bSkgfHwKLSAgICAgICAgICAgICAgICAgKG9wdF9mYl9jbGVhcl9t
bWlvICYmIGlzX2lvbW11X2VuYWJsZWQoZCkpKTsKKyAgICBib29sIHZlcncg
PSAoKHB2ID8gb3B0X3ZlcndfcHYgOiBvcHRfdmVyd19odm0pIHx8CisgICAg
ICAgICAgICAgICAgIChvcHRfdmVyd19tbWlvICYmIGlzX2lvbW11X2VuYWJs
ZWQoZCkpKTsKIAogICAgIGJvb2wgaWJwYiA9ICgocHYgPyBvcHRfaWJwYl9l
bnRyeV9wdiA6IG9wdF9pYnBiX2VudHJ5X2h2bSkgJiYKICAgICAgICAgICAg
ICAgICAgKGQtPmRvbWFpbl9pZCAhPSAwIHx8IG9wdF9pYnBiX2VudHJ5X2Rv
bTApKTsKQEAgLTE3NjUsMTkgKzE3NjYsMjAgQEAgdm9pZCBfX2luaXQgaW5p
dF9zcGVjdWxhdGlvbl9taXRpZ2F0aW9ucyh2b2lkKQogICAgICAqIHRoZSBy
ZXR1cm4tdG8tZ3Vlc3QgcGF0aC4KICAgICAgKi8KICAgICBpZiAoIG9wdF91
bnByaXZfbW1pbyApCi0gICAgICAgIG9wdF9mYl9jbGVhcl9tbWlvID0gY3B1
X2hhc19mYl9jbGVhcjsKKyAgICAgICAgb3B0X3ZlcndfbW1pbyA9IGNwdV9o
YXNfZmJfY2xlYXI7CiAKICAgICAvKgogICAgICAqIEJ5IGRlZmF1bHQsIGVu
YWJsZSBQViBhbmQgSFZNIG1pdGlnYXRpb25zIG9uIE1EUy12dWxuZXJhYmxl
IGhhcmR3YXJlLgogICAgICAqIFRoaXMgd2lsbCBvbmx5IGJlIGEgdG9rZW4g
ZWZmb3J0IGZvciBNTFBEUy9NRkJEUyB3aGVuIEhUIGlzIGVuYWJsZWQsCiAg
ICAgICogYnV0IGl0IGlzIHNvbWV3aGF0IGJldHRlciB0aGFuIG5vdGhpbmcu
CiAgICAgICovCi0gICAgaWYgKCBvcHRfbWRfY2xlYXJfcHYgPT0gLTEgKQot
ICAgICAgICBvcHRfbWRfY2xlYXJfcHYgPSAoKGNwdV9oYXNfYnVnX21kcyB8
fCBjcHVfaGFzX2J1Z19tc2Jkc19vbmx5KSAmJgotICAgICAgICAgICAgICAg
ICAgICAgICAgICAgYm9vdF9jcHVfaGFzKFg4Nl9GRUFUVVJFX01EX0NMRUFS
KSk7Ci0gICAgaWYgKCBvcHRfbWRfY2xlYXJfaHZtID09IC0xICkKLSAgICAg
ICAgb3B0X21kX2NsZWFyX2h2bSA9ICgoY3B1X2hhc19idWdfbWRzIHx8IGNw
dV9oYXNfYnVnX21zYmRzX29ubHkpICYmCi0gICAgICAgICAgICAgICAgICAg
ICAgICAgICAgYm9vdF9jcHVfaGFzKFg4Nl9GRUFUVVJFX01EX0NMRUFSKSk7
CisgICAgaWYgKCBvcHRfdmVyd19wdiA9PSAtMSApCisgICAgICAgIG9wdF92
ZXJ3X3B2ID0gKChjcHVfaGFzX2J1Z19tZHMgfHwgY3B1X2hhc19idWdfbXNi
ZHNfb25seSkgJiYKKyAgICAgICAgICAgICAgICAgICAgICAgY3B1X2hhc19t
ZF9jbGVhcik7CisKKyAgICBpZiAoIG9wdF92ZXJ3X2h2bSA9PSAtMSApCisg
ICAgICAgIG9wdF92ZXJ3X2h2bSA9ICgoY3B1X2hhc19idWdfbWRzIHx8IGNw
dV9oYXNfYnVnX21zYmRzX29ubHkpICYmCisgICAgICAgICAgICAgICAgICAg
ICAgICBjcHVfaGFzX21kX2NsZWFyKTsKIAogICAgIC8qCiAgICAgICogRW5h
YmxlIE1EUy9NTUlPIGRlZmVuY2VzIGFzIGFwcGxpY2FibGUuICBUaGUgSWRs
ZSBibG9ja3MgbmVlZCB1c2luZyBpZgpAQCAtMTc5MCwxMiArMTc5MiwxMiBA
QCB2b2lkIF9faW5pdCBpbml0X3NwZWN1bGF0aW9uX21pdGlnYXRpb25zKHZv
aWQpCiAgICAgICogTURTIG1pdGlnYXRpb25zLiAgTDFEX0ZMVVNIIGlzIG5v
dCBzYWZlIGZvciBNTUlPIG1pdGlnYXRpb25zLikKICAgICAgKgogICAgICAq
IEFmdGVyIGNhbGN1bGF0aW5nIHRoZSBhcHByb3ByaWF0ZSBpZGxlIHNldHRp
bmcsIHNpbXBsaWZ5Ci0gICAgICogb3B0X21kX2NsZWFyX2h2bSB0byBtZWFu
IGp1c3QgInNob3VsZCB3ZSBWRVJXIG9uIHRoZSB3YXkgaW50byBIVk0KKyAg
ICAgKiBvcHRfdmVyd19odm0gdG8gbWVhbiBqdXN0ICJzaG91bGQgd2UgVkVS
VyBvbiB0aGUgd2F5IGludG8gSFZNCiAgICAgICogZ3Vlc3RzIiwgc28gc3Bl
Y19jdHJsX2luaXRfZG9tYWluKCkgY2FuIGNhbGN1bGF0ZSBzdWl0YWJsZSBz
ZXR0aW5ncy4KICAgICAgKi8KLSAgICBpZiAoIG9wdF9tZF9jbGVhcl9wdiB8
fCBvcHRfbWRfY2xlYXJfaHZtIHx8IG9wdF9mYl9jbGVhcl9tbWlvICkKKyAg
ICBpZiAoIG9wdF92ZXJ3X3B2IHx8IG9wdF92ZXJ3X2h2bSB8fCBvcHRfdmVy
d19tbWlvICkKICAgICAgICAgc2V0dXBfZm9yY2VfY3B1X2NhcChYODZfRkVB
VFVSRV9TQ19WRVJXX0lETEUpOwotICAgIG9wdF9tZF9jbGVhcl9odm0gJj0g
IWNwdV9oYXNfc2tpcF9sMWRmbCAmJiAhb3B0X2wxZF9mbHVzaDsKKyAgICBv
cHRfdmVyd19odm0gJj0gIWNwdV9oYXNfc2tpcF9sMWRmbCAmJiAhb3B0X2wx
ZF9mbHVzaDsKIAogICAgIC8qCiAgICAgICogV2FybiB0aGUgdXNlciBpZiB0
aGV5IGFyZSBvbiBNTFBEUy9NRkJEUy12dWxuZXJhYmxlIGhhcmR3YXJlIHdp
dGggSFQK

--=separator
Content-Type: application/octet-stream; name="xsa452/xsa452-4.15-6.patch"
Content-Disposition: attachment; filename="xsa452/xsa452-4.15-6.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L3NwZWMtY3RybDogVkVSVy1oYW5kbGluZyBhZGp1
c3RtZW50cwoKLi4uIGJlZm9yZSB3ZSBhZGQgeWV0IG1vcmUgY29tcGxleGl0
eSB0byB0aGlzIGxvZ2ljLiAgTW9zdGx5IGV4cGFuZGVkCmNvbW1lbnRzLCBi
dXQgd2l0aCB0aHJlZSBtaW5vciBjaGFuZ2VzLgoKMSkgSW50cm9kdWNlIGNw
dV9oYXNfdXNlZnVsX21kX2NsZWFyIHRvIHNpbXBsaWZ5IGxhdGVyIGxvZ2lj
IGluIHRoaXMgcGF0Y2ggYW5kCiAgIGZ1dHVyZSBvbmVzLgoKMikgV2Ugb25s
eSBldmVyIG5lZWQgU0NfVkVSV19JRExFIHdoZW4gU01UIGlzIGFjdGl2ZS4g
IElmIFNNVCBpc24ndCBhY3RpdmUsCiAgIHRoZW4gdGhlcmUncyBubyByZS1w
YXJ0aXRpb24gb2YgcGlwZWxpbmUgcmVzb3VyY2VzIGJhc2VkIG9uIHRocmVh
ZC1pZGxlbmVzcwogICB0byB3b3JyeSBhYm91dC4KCjMpIFRoZSBsb2dpYyB0
byBhZGp1c3QgSFZNIFZFUlcgYmFzZWQgb24gTDFEX0ZMVVNIIGlzIHVubWFp
bnRhaW5hYmxlIGFuZCwgYXMKICAgaXQgdHVybnMgb3V0LCB3cm9uZy4gIFNL
SVBfTDFERkwgaXMganVzdCBhIGhpbnQgYml0LCB3aGVyZWFzIG9wdF9sMWRf
Zmx1c2gKICAgaXMgdGhlIHJlbGV2YW50IGRlY2lzaW9uIG9mIHdoZXRoZXIg
dG8gdXNlIEwxRF9GTFVTSCBiYXNlZCBvbgogICBzdXNjZXB0aWJpbGl0eSBh
bmQgdXNlciBwcmVmZXJlbmNlLgoKICAgUmV3cml0ZSB0aGUgbG9naWMgc28g
aXQgY2FuIGJlIGZvbGxvd2VkLCBhbmQgaW5jb3Jwb3JhdGUgdGhlIGZhY3Qg
dGhhdCB3aGVuCiAgIEZCX0NMRUFSIGlzIHZpc2libGUsIEwxRF9GTFVTSCBp
c24ndCBhIHNhZmUgc3Vic3RpdHV0aW9uLgoKVGhpcyBpcyBwYXJ0IG9mIFhT
QS00NTIgLyBDVkUtMjAyMy0yODc0Ni4KClNpZ25lZC1vZmYtYnk6IEFuZHJl
dyBDb29wZXIgPGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+CkFja2VkLWJ5
OiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+CihjaGVycnkgcGlj
a2VkIGZyb20gY29tbWl0IDFlYjkxYThhMDYyMzBiNGI2NDIyOGM5YTM4MDE5
NGY4Y2ZlNmM1ZTIpCgpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L3NwZWNf
Y3RybC5jIGIveGVuL2FyY2gveDg2L3NwZWNfY3RybC5jCmluZGV4IDQzNDQ5
YjRjN2ExOS4uODRhMzgyNzgxYjE3IDEwMDY0NAotLS0gYS94ZW4vYXJjaC94
ODYvc3BlY19jdHJsLmMKKysrIGIveGVuL2FyY2gveDg2L3NwZWNfY3RybC5j
CkBAIC0xNDY3LDcgKzE0NjcsNyBAQCB2b2lkIF9faW5pdCBpbml0X3NwZWN1
bGF0aW9uX21pdGlnYXRpb25zKHZvaWQpCiB7CiAgICAgZW51bSBpbmRfdGh1
bmsgdGh1bmsgPSBUSFVOS19ERUZBVUxUOwogICAgIGJvb2wgaGFzX3NwZWNf
Y3RybCwgaWJycyA9IGZhbHNlLCBod19zbXRfZW5hYmxlZDsKLSAgICBib29s
IGNwdV9oYXNfYnVnX3RhYSwgcmV0cG9saW5lX3NhZmU7CisgICAgYm9vbCBj
cHVfaGFzX2J1Z190YWEsIGNwdV9oYXNfdXNlZnVsX21kX2NsZWFyLCByZXRw
b2xpbmVfc2FmZTsKIAogICAgIGh3X3NtdF9lbmFibGVkID0gY2hlY2tfc210
X2VuYWJsZWQoKTsKIApAQCAtMTc1NCw1MCArMTc1NCw5NyBAQCB2b2lkIF9f
aW5pdCBpbml0X3NwZWN1bGF0aW9uX21pdGlnYXRpb25zKHZvaWQpCiAgICAg
ICAgICAgICAiZW5hYmxlZC4gIFBsZWFzZSBhc3Nlc3MgeW91ciBjb25maWd1
cmF0aW9uIGFuZCBjaG9vc2UgYW5cbiIKICAgICAgICAgICAgICJleHBsaWNp
dCAnc210PTxib29sPicgc2V0dGluZy4gIFNlZSBYU0EtMjczLlxuIik7CiAK
KyAgICAvKgorICAgICAqIEEgYnJpZWYgc3VtbWFyeSBvZiBWRVJXLXJlbGF0
ZWQgY2hhbmdlcy4KKyAgICAgKgorICAgICAqIGh0dHBzOi8vd3d3LmludGVs
LmNvbS9jb250ZW50L3d3dy91cy9lbi9kZXZlbG9wZXIvYXJ0aWNsZXMvdGVj
aG5pY2FsL3NvZnR3YXJlLXNlY3VyaXR5LWd1aWRhbmNlL3RlY2huaWNhbC1k
b2N1bWVudGF0aW9uL2ludGVsLWFuYWx5c2lzLW1pY3JvYXJjaGl0ZWN0dXJh
bC1kYXRhLXNhbXBsaW5nLmh0bWwKKyAgICAgKiBodHRwczovL3d3dy5pbnRl
bC5jb20vY29udGVudC93d3cvdXMvZW4vZGV2ZWxvcGVyL2FydGljbGVzL3Rl
Y2huaWNhbC9zb2Z0d2FyZS1zZWN1cml0eS1ndWlkYW5jZS90ZWNobmljYWwt
ZG9jdW1lbnRhdGlvbi9wcm9jZXNzb3ItbW1pby1zdGFsZS1kYXRhLXZ1bG5l
cmFiaWxpdGllcy5odG1sCisgICAgICoKKyAgICAgKiBSZWxldmFudCB1Y29k
ZXM6CisgICAgICoKKyAgICAgKiAtIE1heSAyMDE5LCBmb3IgTURTLiAgSW50
cm9kdWNlcyB0aGUgTURfQ0xFQVIgQ1BVSUQgYml0IGFuZCBWRVJXIHNpZGUK
KyAgICAgKiAgIGVmZmVjdHMgdG8gc2NydWIgU3RvcmUvTG9hZC9GaWxsIGJ1
ZmZlcnMgYXMgYXBwbGljYWJsZS4gIE1EX0NMRUFSCisgICAgICogICBleGlz
dHMgYXJjaGl0ZWN0dXJhbGx5LCBldmVuIHdoZW4gdGhlIHNpZGUgZWZmZWN0
cyBoYXZlIGJlZW4gcmVtb3ZlZC4KKyAgICAgKgorICAgICAqICAgVXNlIFZF
UlcgdG8gc2NydWIgb24gcmV0dXJuLXRvLWd1ZXN0LiAgUGFydHMgd2l0aCBM
MURfRkxVU0ggdG8KKyAgICAgKiAgIG1pdGlnYXRlIEwxVEYgaGF2ZSB0aGUg
c2FtZSBzaWRlIGVmZmVjdCwgc28gbm8gbmVlZCB0byBkbyBib3RoLgorICAg
ICAqCisgICAgICogICBWYXJpb3VzIEF0b21zIHN1ZmZlciBmcm9tIFN0b3Jl
LWJ1ZmZlciBzYW1wbGluZyBvbmx5LiAgU3RvcmUgYnVmZmVycworICAgICAq
ICAgYXJlIHN0YXRpY2FsbHkgcGFydGl0aW9uZWQgYmV0d2VlbiBub24taWRs
ZSB0aHJlYWRzLCBzbyBzY3J1YmJpbmcgaXMKKyAgICAgKiAgIHdhbnRlZCB3
aGVuIGdvaW5nIGlkbGUgdG9vLgorICAgICAqCisgICAgICogICBMb2FkIHBv
cnRzIGFuZCBGaWxsIGJ1ZmZlcnMgYXJlIGNvbXBldGl0aXZlbHkgc2hhcmVk
IGJldHdlZW4gdGhyZWFkcy4KKyAgICAgKiAgIFNNVCBtdXN0IGJlIGRpc2Fi
bGVkIGZvciBWRVJXIHNjcnViYmluZyB0byBiZSBmdWxseSBlZmZlY3RpdmUu
CisgICAgICoKKyAgICAgKiAtIE5vdmVtYmVyIDIwMTksIGZvciBUQUEuICBF
eHRlbmRlZCBWRVJXIHNpZGUgZWZmZWN0cyB0byBUU1gtZW5hYmxlZAorICAg
ICAqICAgTURTX05PIHBhcnRzLgorICAgICAqCisgICAgICogLSBGZWJydWFy
eSAyMDIyLCBmb3IgQ2xpZW50IFRTWCBkZS1mZWF0dXJlLiAgUmVtb3ZlZCBW
RVJXIHNpZGUgZWZmZWN0cworICAgICAqICAgZnJvbSBDbGllbnQgQ1BVcyBv
bmx5LgorICAgICAqCisgICAgICogLSBNYXkgMjAyMiwgZm9yIE1NSU8gU3Rh
bGUgRGF0YS4gIChSZSlpbnRyb2R1Y2VkIEZpbGwgQnVmZmVyIHNjcnViYmlu
ZworICAgICAqICAgb24gYWxsIE1NSU8tYWZmZWN0ZWQgcGFydHMgd2hpY2gg
ZGlkbid0IGFscmVhZHkgaGF2ZSBpdCBmb3IgTURTCisgICAgICogICByZWFz
b25zLCBlbnVtZXJhdGluZyBGQl9DTEVBUiBvbiB0aG9zZSBwYXJ0cyBvbmx5
LgorICAgICAqCisgICAgICogICBJZiBGQl9DTEVBUiBpcyBlbnVtZXJhdGVk
LCBMMURfRkxVU0ggZG9lcyBub3QgaGF2ZSB0aGUgc2FtZSBzY3J1YmJpbmcK
KyAgICAgKiAgIHNpZGUgZWZmZWN0cyBhcyBWRVJXIGFuZCBjYW5ub3QgYmUg
dXNlZCBpbiBpdHMgcGxhY2UuCisgICAgICovCiAgICAgbWRzX2NhbGN1bGF0
aW9ucygpOwogCiAgICAgLyoKLSAgICAgKiBQYXJ0cyB3aGljaCBlbnVtZXJh
dGUgRkJfQ0xFQVIgYXJlIHRob3NlIHdoaWNoIGFyZSBwb3N0LU1EU19OTyBh
bmQgaGF2ZQotICAgICAqIHJlaW50cm9kdWNlZCB0aGUgVkVSVyBmaWxsIGJ1
ZmZlciBmbHVzaGluZyBzaWRlIGVmZmVjdCBiZWNhdXNlIG9mIGEKLSAgICAg
KiBzdXNjZXB0aWJpbGl0eSB0byBGQlNEUC4KKyAgICAgKiBQYXJ0cyB3aGlj
aCBlbnVtZXJhdGUgRkJfQ0xFQVIgYXJlIHRob3NlIHdpdGggbm93LXVwZGF0
ZWQgbWljcm9jb2RlCisgICAgICogd2hpY2ggd2VyZW4ndCBzdXNjZXB0aWJs
ZSB0byB0aGUgb3JpZ2luYWwgTUZCRFMgKGFuZCB0aGVyZWZvcmUgZGlkbid0
CisgICAgICogaGF2ZSBGaWxsIEJ1ZmZlciBzY3J1YmJpbmcgc2lkZSBlZmZl
Y3RzIHRvIGJlZ2luIHdpdGgsIG9yIHdlcmUgQ2xpZW50CisgICAgICogTURT
X05PIG5vbi1UQUFfTk8gcGFydHMgd2hlcmUgdGhlIHNjcnViYmluZyB3YXMg
cmVtb3ZlZCksIGJ1dCBoYXZlIGhhZAorICAgICAqIHRoZSBzY3J1YmJpbmcg
cmVpbnRyb2R1Y2VkIGJlY2F1c2Ugb2YgYSBzdXNjZXB0aWJpbGl0eSB0byBG
QlNEUC4KICAgICAgKgogICAgICAqIElmIHVucHJpdmlsZWdlZCBndWVzdHMg
aGF2ZSAob3Igd2lsbCBoYXZlKSBNTUlPIG1hcHBpbmdzLCB3ZSBjYW4KICAg
ICAgKiBtaXRpZ2F0ZSBjcm9zcy1kb21haW4gbGVha2FnZSBvZiBmaWxsIGJ1
ZmZlciBkYXRhIGJ5IGlzc3VpbmcgVkVSVyBvbgotICAgICAqIHRoZSByZXR1
cm4tdG8tZ3Vlc3QgcGF0aC4KKyAgICAgKiB0aGUgcmV0dXJuLXRvLWd1ZXN0
IHBhdGguICBUaGlzIGlzIG9ubHkgYSB0b2tlbiBlZmZvcnQgaWYgU01UIGlz
CisgICAgICogYWN0aXZlLgogICAgICAqLwogICAgIGlmICggb3B0X3VucHJp
dl9tbWlvICkKICAgICAgICAgb3B0X3ZlcndfbW1pbyA9IGNwdV9oYXNfZmJf
Y2xlYXI7CiAKICAgICAvKgotICAgICAqIEJ5IGRlZmF1bHQsIGVuYWJsZSBQ
ViBhbmQgSFZNIG1pdGlnYXRpb25zIG9uIE1EUy12dWxuZXJhYmxlIGhhcmR3
YXJlLgotICAgICAqIFRoaXMgd2lsbCBvbmx5IGJlIGEgdG9rZW4gZWZmb3J0
IGZvciBNTFBEUy9NRkJEUyB3aGVuIEhUIGlzIGVuYWJsZWQsCi0gICAgICog
YnV0IGl0IGlzIHNvbWV3aGF0IGJldHRlciB0aGFuIG5vdGhpbmcuCisgICAg
ICogTURfQ0xFQVIgaXMgZW51bWVyYXRlZCBhcmNoaXRlY3R1cmFsbHkgZm9y
ZXZlcm1vcmUsIGV2ZW4gYWZ0ZXIgdGhlCisgICAgICogc2NydWJiaW5nIHNp
ZGUgZWZmZWN0cyBoYXZlIGJlZW4gcmVtb3ZlZC4gIENyZWF0ZSBvdXJzZWx2
ZXMgYW4gdmVyc2lvbgorICAgICAqIHdoaWNoIGV4cHJlc3NlZCB3aGV0aGVy
IHdlIHRoaW5rIE1EX0NMRUFSIGlzIGhhdmluZyBhbnkgdXNlZnVsIHNpZGUK
KyAgICAgKiBlZmZlY3QuCisgICAgICovCisgICAgY3B1X2hhc191c2VmdWxf
bWRfY2xlYXIgPSAoY3B1X2hhc19tZF9jbGVhciAmJgorICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIChjcHVfaGFzX2J1Z19tZHMgfHwgY3B1X2hh
c19idWdfbXNiZHNfb25seSkpOworCisgICAgLyoKKyAgICAgKiBCeSBkZWZh
dWx0LCB1c2UgVkVSVyBzY3J1YmJpbmcgb24gYXBwbGljYWJsZSBoYXJkd2Fy
ZSwgaWYgd2UgdGhpbmsgaXQncworICAgICAqIGdvaW5nIHRvIGhhdmUgYW4g
ZWZmZWN0LiAgVGhpcyB3aWxsIG9ubHkgYmUgYSB0b2tlbiBlZmZvcnQgZm9y
CisgICAgICogTUxQRFMvTUZCRFMgd2hlbiBTTVQgaXMgZW5hYmxlZC4KICAg
ICAgKi8KICAgICBpZiAoIG9wdF92ZXJ3X3B2ID09IC0xICkKLSAgICAgICAg
b3B0X3ZlcndfcHYgPSAoKGNwdV9oYXNfYnVnX21kcyB8fCBjcHVfaGFzX2J1
Z19tc2Jkc19vbmx5KSAmJgotICAgICAgICAgICAgICAgICAgICAgICBjcHVf
aGFzX21kX2NsZWFyKTsKKyAgICAgICAgb3B0X3ZlcndfcHYgPSBjcHVfaGFz
X3VzZWZ1bF9tZF9jbGVhcjsKIAogICAgIGlmICggb3B0X3ZlcndfaHZtID09
IC0xICkKLSAgICAgICAgb3B0X3ZlcndfaHZtID0gKChjcHVfaGFzX2J1Z19t
ZHMgfHwgY3B1X2hhc19idWdfbXNiZHNfb25seSkgJiYKLSAgICAgICAgICAg
ICAgICAgICAgICAgIGNwdV9oYXNfbWRfY2xlYXIpOworICAgICAgICBvcHRf
dmVyd19odm0gPSBjcHVfaGFzX3VzZWZ1bF9tZF9jbGVhcjsKIAogICAgIC8q
Ci0gICAgICogRW5hYmxlIE1EUy9NTUlPIGRlZmVuY2VzIGFzIGFwcGxpY2Fi
bGUuICBUaGUgSWRsZSBibG9ja3MgbmVlZCB1c2luZyBpZgotICAgICAqIGVp
dGhlciB0aGUgUFYgb3IgSFZNIE1EUyBkZWZlbmNlcyBhcmUgdXNlZCwgb3Ig
aWYgd2UgbWF5IGdpdmUgTU1JTwotICAgICAqIGFjY2VzcyB0byB1bnRydXN0
ZWQgZ3Vlc3RzLgotICAgICAqCi0gICAgICogSFZNIGlzIG1vcmUgY29tcGxp
Y2F0ZWQuICBUaGUgTURfQ0xFQVIgbWljcm9jb2RlIGV4dGVuZHMgTDFEX0ZM
VVNIIHdpdGgKLSAgICAgKiBlcXVpdmFsZW50IHNlbWFudGljcyB0byBhdm9p
ZCBuZWVkaW5nIHRvIHBlcmZvcm0gYm90aCBmbHVzaGVzIG9uIHRoZQotICAg
ICAqIEhWTSBwYXRoLiAgVGhlcmVmb3JlLCB3ZSBkb24ndCBuZWVkIFZFUlcg
aW4gYWRkaXRpb24gdG8gTDFEX0ZMVVNIIChmb3IKLSAgICAgKiBNRFMgbWl0
aWdhdGlvbnMuICBMMURfRkxVU0ggaXMgbm90IHNhZmUgZm9yIE1NSU8gbWl0
aWdhdGlvbnMuKQotICAgICAqCi0gICAgICogQWZ0ZXIgY2FsY3VsYXRpbmcg
dGhlIGFwcHJvcHJpYXRlIGlkbGUgc2V0dGluZywgc2ltcGxpZnkKLSAgICAg
KiBvcHRfdmVyd19odm0gdG8gbWVhbiBqdXN0ICJzaG91bGQgd2UgVkVSVyBv
biB0aGUgd2F5IGludG8gSFZNCi0gICAgICogZ3Vlc3RzIiwgc28gc3BlY19j
dHJsX2luaXRfZG9tYWluKCkgY2FuIGNhbGN1bGF0ZSBzdWl0YWJsZSBzZXR0
aW5ncy4KKyAgICAgKiBJZiBTTVQgaXMgYWN0aXZlLCBhbmQgd2UncmUgcHJv
dGVjdGluZyBhZ2FpbnN0IE1EUyBvciBNTUlPIHN0YWxlIGRhdGEsCisgICAg
ICogd2UgbmVlZCB0byBzY3J1YiBiZWZvcmUgZ29pbmcgaWRsZSBhcyB3ZWxs
IGFzIG9uIHJldHVybiB0byBndWVzdC4KKyAgICAgKiBWYXJpb3VzIHBpcGVs
aW5lIHJlc291cmNlcyBhcmUgcmVwYXJ0aXRpb25lZCBhbW9uZ3N0IG5vbi1p
ZGxlIHRocmVhZHMuCiAgICAgICovCi0gICAgaWYgKCBvcHRfdmVyd19wdiB8
fCBvcHRfdmVyd19odm0gfHwgb3B0X3ZlcndfbW1pbyApCisgICAgaWYgKCAo
KGNwdV9oYXNfdXNlZnVsX21kX2NsZWFyICYmIChvcHRfdmVyd19wdiB8fCBv
cHRfdmVyd19odm0pKSB8fAorICAgICAgICAgIG9wdF92ZXJ3X21taW8pICYm
IGh3X3NtdF9lbmFibGVkICkKICAgICAgICAgc2V0dXBfZm9yY2VfY3B1X2Nh
cChYODZfRkVBVFVSRV9TQ19WRVJXX0lETEUpOwotICAgIG9wdF92ZXJ3X2h2
bSAmPSAhY3B1X2hhc19za2lwX2wxZGZsICYmICFvcHRfbDFkX2ZsdXNoOwor
CisgICAgLyoKKyAgICAgKiBBZnRlciBjYWxjdWxhdGluZyB0aGUgYXBwcm9w
cmlhdGUgaWRsZSBzZXR0aW5nLCBzaW1wbGlmeSBvcHRfdmVyd19odm0KKyAg
ICAgKiB0byBtZWFuIGp1c3QgInNob3VsZCB3ZSBWRVJXIG9uIHRoZSB3YXkg
aW50byBIVk0gZ3Vlc3RzIiwgc28KKyAgICAgKiBzcGVjX2N0cmxfaW5pdF9k
b21haW4oKSBjYW4gY2FsY3VsYXRlIHN1aXRhYmxlIHNldHRpbmdzLgorICAg
ICAqCisgICAgICogSXQgaXMgb25seSBzYWZlIHRvIHVzZSBMMURfRkxVU0gg
aW4gcGxhY2Ugb2YgVkVSVyB3aGVuIE1EX0NMRUFSIGlzIHRoZQorICAgICAq
IG9ubHkgKl9DTEVBUiB3ZSBjYW4gc2VlLgorICAgICAqLworICAgIGlmICgg
b3B0X2wxZF9mbHVzaCAmJiBjcHVfaGFzX21kX2NsZWFyICYmICFjcHVfaGFz
X2ZiX2NsZWFyICkKKyAgICAgICAgb3B0X3ZlcndfaHZtID0gZmFsc2U7CiAK
ICAgICAvKgogICAgICAqIFdhcm4gdGhlIHVzZXIgaWYgdGhleSBhcmUgb24g
TUxQRFMvTUZCRFMtdnVsbmVyYWJsZSBoYXJkd2FyZSB3aXRoIEhUCg==

--=separator
Content-Type: application/octet-stream; name="xsa452/xsa452-4.15-7.patch"
Content-Disposition: attachment; filename="xsa452/xsa452-4.15-7.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L3NwZWMtY3RybDogTWl0aWdhdGlvbiBSZWdpc3Rl
ciBGaWxlIERhdGEgU2FtcGxpbmcKClJGRFMgYWZmZWN0cyBBdG9tIGNvcmVz
LCBhbHNvIGJyYW5kZWQgRS1jb3JlcywgYmV0d2VlbiB0aGUgR29sZG1vbnQg
YW5kCkdyYWNlbW9udCBtaWNyb2FyY2hpdGVjdHVyZXMuICBUaGlzIGluY2x1
ZGVzIEFsZGVyIExha2UgYW5kIFJhcHRvciBMYWtlIGh5YnJpZApjbGllbiBz
eXN0ZW1zIHdoaWNoIGhhdmUgYSBtaXggb2YgR3JhY2Vtb250IGFuZCBvdGhl
ciB0eXBlcyBvZiBjb3Jlcy4KClR3byBuZXcgYml0cyBoYXZlIGJlZW4gZGVm
aW5lZDsgUkZEU19DTEVBUiB0byBpbmRpY2F0ZSBWRVJXIGhhcyBtb3JlIHNp
ZGUKZWZmZXRzLCBhbmQgUkZEU19OTyB0byBpbmNpZGF0ZSB0aGF0IHRoZSBz
eXN0ZW0gaXMgdW5hZmZlY3RlZC4gIFBsZW50eSBvZgp1bmFmZmVjdGVkIENQ
VXMgd29uJ3QgYmUgZ2V0dGluZyBSRkRTX05PIHJldHJvZml0dGVkIGluIG1p
Y3JvY29kZSwgc28gd2UKc3ludGhlc2lzZSBpdC4gIEFsZGVyIExha2UgYW5k
IFJhcHRvciBMYWtlIFhlb24tRSdzIGFyZSB1bmFmZmVjdGVkIGR1ZSB0bwp0
aGVpciBwbGF0Zm9ybSBjb25maWd1cmF0aW9uLCBhbmQgd2UgbXVzdCB1c2Ug
dGhlIEh5YnJpZCBDUFVJRCBiaXQgdG8KZGlzdGluZ3Vpc2ggdGhlbSBmcm9t
IHRoZWlyIG5vbi1YZW9uIGNvdW50ZXJwYXJ0cy4KCkxpa2UgTURfQ0xFQVIg
YW5kIEZCX0NMRUFSLCBSRkRTX0NMRUFSIG5lZWRzIE9SLWluZyBhY3Jvc3Mg
YSByZXNvdXJjZSBwb29sLCBzbwpzZXQgaXQgaW4gdGhlIG1heCBwb2xpY2ll
cyBhbmQgcmVmbGVjdCB0aGUgaG9zdCBzZXR0aW5nIGluIGRlZmF1bHQuCgpU
aGlzIGlzIHBhcnQgb2YgWFNBLTQ1MiAvIENWRS0yMDIzLTI4NzQ2LgoKU2ln
bmVkLW9mZi1ieTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0
cml4LmNvbT4KUmV2aWV3ZWQtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBz
dXNlLmNvbT4KKGNoZXJyeSBwaWNrZWQgZnJvbSBjb21taXQgZmI1YjZmNjc0
NDcxMzQxMGM3NGNmYzEyYjcxNzZjMTA4ZTNjOWEzMSkKCmRpZmYgLS1naXQg
YS90b29scy9taXNjL3hlbi1jcHVpZC5jIGIvdG9vbHMvbWlzYy94ZW4tY3B1
aWQuYwppbmRleCA4NjBlZjA3MzUyYzEuLjNmYWYxZTQzMDQ4NyAxMDA2NDQK
LS0tIGEvdG9vbHMvbWlzYy94ZW4tY3B1aWQuYworKysgYi90b29scy9taXNj
L3hlbi1jcHVpZC5jCkBAIC0xNjksNyArMTY5LDcgQEAgc3RhdGljIGNvbnN0
IGNoYXIgKmNvbnN0IHN0cl83ZDBbMzJdID0KICAgICBbIDhdID0gImF2eDUx
Mi12cDJpbnRlcnNlY3QiLCBbIDldID0gInNyYmRzLWN0cmwiLAogICAgIFsx
MF0gPSAibWQtY2xlYXIiLCAgICAgICAgICAgIFsxMV0gPSAicnRtLWFsd2F5
cy1hYm9ydCIsCiAgICAgLyogMTIgKi8gICAgICAgICAgICAgICAgWzEzXSA9
ICJ0c3gtZm9yY2UtYWJvcnQiLAotICAgIFsxNF0gPSAic2VyaWFsaXplIiwK
KyAgICBbMTRdID0gInNlcmlhbGl6ZSIsICAgICBbMTVdID0gImh5YnJpZCIs
CiAgICAgWzE2XSA9ICJ0c3hsZHRyayIsCiAgICAgWzE4XSA9ICJwY29uZmln
IiwKICAgICBbMjBdID0gImNldC1pYnQiLApAQCAtMjI0LDcgKzIyNCw4IEBA
IHN0YXRpYyBjb25zdCBjaGFyICpjb25zdCBzdHJfbTEwQWxbMzJdID0KICAg
ICBbMjBdID0gImJoaS1ubyIsICAgICAgICAgICAgICBbMjFdID0gInhhcGlj
LXN0YXR1cyIsCiAgICAgLyogMjIgKi8gICAgICAgICAgICAgICAgICAgICAg
WzIzXSA9ICJvdnJjbGstc3RhdHVzIiwKICAgICBbMjRdID0gInBicnNiLW5v
IiwgICAgICAgICAgICBbMjVdID0gImdkcy1jdHJsIiwKLSAgICBbMjZdID0g
Imdkcy1ubyIsCisgICAgWzI2XSA9ICJnZHMtbm8iLCAgICAgICAgICAgICAg
WzI3XSA9ICJyZmRzLW5vIiwKKyAgICBbMjhdID0gInJmZHMtY2xlYXIiLAog
fTsKIAogc3RhdGljIGNvbnN0IGNoYXIgKmNvbnN0IHN0cl9tMTBBaFszMl0g
PQpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2NwdS1wb2xpY3kuYyBiL3hl
bi9hcmNoL3g4Ni9jcHUtcG9saWN5LmMKaW5kZXggYzZjZDkxZGIwYTBmLi5j
OThiOGZjOTNhMDYgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9jcHUtcG9s
aWN5LmMKKysrIGIveGVuL2FyY2gveDg2L2NwdS1wb2xpY3kuYwpAQCAtNDQz
LDYgKzQ0Myw3IEBAIHN0YXRpYyB2b2lkIF9faW5pdCBndWVzdF9jb21tb25f
bWF4X2ZlYXR1cmVfYWRqdXN0bWVudHModWludDMyX3QgKmZzKQogICAgICAg
ICAgKi8KICAgICAgICAgX19zZXRfYml0KFg4Nl9GRUFUVVJFX01EX0NMRUFS
LCBmcyk7CiAgICAgICAgIF9fc2V0X2JpdChYODZfRkVBVFVSRV9GQl9DTEVB
UiwgZnMpOworICAgICAgICBfX3NldF9iaXQoWDg2X0ZFQVRVUkVfUkZEU19D
TEVBUiwgZnMpOwogCiAgICAgICAgIC8qCiAgICAgICAgICAqIFRoZSBHYXRo
ZXIgRGF0YSBTYW1wbGluZyBtaWNyb2NvZGUgbWl0aWdhdGlvbiAoQXVndXN0
IDIwMjMpIGhhcyBhbgpAQCAtNDkyLDYgKzQ5MywxMCBAQCBzdGF0aWMgdm9p
ZCBfX2luaXQgZ3Vlc3RfY29tbW9uX2RlZmF1bHRfZmVhdHVyZV9hZGp1c3Rt
ZW50cyh1aW50MzJfdCAqZnMpCiAgICAgICAgIGlmICggY3B1X2hhc19mYl9j
bGVhciApCiAgICAgICAgICAgICBfX3NldF9iaXQoWDg2X0ZFQVRVUkVfRkJf
Q0xFQVIsIGZzKTsKIAorICAgICAgICBfX2NsZWFyX2JpdChYODZfRkVBVFVS
RV9SRkRTX0NMRUFSLCBmcyk7CisgICAgICAgIGlmICggY3B1X2hhc19yZmRz
X2NsZWFyICkKKyAgICAgICAgICAgIF9fc2V0X2JpdChYODZfRkVBVFVSRV9S
RkRTX0NMRUFSLCBmcyk7CisKICAgICAgICAgLyoKICAgICAgICAgICogVGhl
IEdhdGhlciBEYXRhIFNhbXBsaW5nIG1pY3JvY29kZSBtaXRpZ2F0aW9uIChB
dWd1c3QgMjAyMykgaGFzIGFuCiAgICAgICAgICAqIGFkdmVyc2UgcGVyZm9y
bWFuY2UgaW1wYWN0IG9uIHRoZSBDTFdCIGluc3RydWN0aW9uIG9uIFNLWC9D
TFgvQ1BYLgpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L3NwZWNfY3RybC5j
IGIveGVuL2FyY2gveDg2L3NwZWNfY3RybC5jCmluZGV4IDg0YTM4Mjc4MWIx
Ny4uZGQ4NmI4OWJiMTUzIDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYvc3Bl
Y19jdHJsLmMKKysrIGIveGVuL2FyY2gveDg2L3NwZWNfY3RybC5jCkBAIC00
MzIsNyArNDMyLDcgQEAgc3RhdGljIHZvaWQgX19pbml0IHByaW50X2RldGFp
bHMoZW51bSBpbmRfdGh1bmsgdGh1bmspCiAgICAgICogSGFyZHdhcmUgcmVh
ZC1vbmx5IGluZm9ybWF0aW9uLCBzdGF0aW5nIGltbXVuaXR5IHRvIGNlcnRh
aW4gaXNzdWVzLCBvcgogICAgICAqIHN1Z2dlc3Rpb25zIG9mIHdoaWNoIG1p
dGlnYXRpb24gdG8gdXNlLgogICAgICAqLwotICAgIHByaW50aygiICBIYXJk
d2FyZSBoaW50czolcyVzJXMlcyVzJXMlcyVzJXMlcyVzJXMlcyVzJXMlcyVz
JXMlcyVzJXMlc1xuIiwKKyAgICBwcmludGsoIiAgSGFyZHdhcmUgaGludHM6
JXMlcyVzJXMlcyVzJXMlcyVzJXMlcyVzJXMlcyVzJXMlcyVzJXMlcyVzJXMl
c1xuIiwKICAgICAgICAgICAgKGNhcHMgJiBBUkNIX0NBUFNfUkRDTF9OTykg
ICAgICAgICAgICAgICAgICAgICAgICA/ICIgUkRDTF9OTyIgICAgICAgIDog
IiIsCiAgICAgICAgICAgIChjYXBzICYgQVJDSF9DQVBTX0VJQlJTKSAgICAg
ICAgICAgICAgICAgICAgICAgICAgPyAiIEVJQlJTIiAgICAgICAgICA6ICIi
LAogICAgICAgICAgICAoY2FwcyAmIEFSQ0hfQ0FQU19SU0JBKSAgICAgICAg
ICAgICAgICAgICAgICAgICAgID8gIiBSU0JBIiAgICAgICAgICAgOiAiIiwK
QEAgLTQ0OCw2ICs0NDgsNyBAQCBzdGF0aWMgdm9pZCBfX2luaXQgcHJpbnRf
ZGV0YWlscyhlbnVtIGluZF90aHVuayB0aHVuaykKICAgICAgICAgICAgKGNh
cHMgJiBBUkNIX0NBUFNfRkJfQ0xFQVIpICAgICAgICAgICAgICAgICAgICAg
ICA/ICIgRkJfQ0xFQVIiICAgICAgIDogIiIsCiAgICAgICAgICAgIChjYXBz
ICYgQVJDSF9DQVBTX1BCUlNCX05PKSAgICAgICAgICAgICAgICAgICAgICAg
PyAiIFBCUlNCX05PIiAgICAgICA6ICIiLAogICAgICAgICAgICAoY2FwcyAm
IEFSQ0hfQ0FQU19HRFNfTk8pICAgICAgICAgICAgICAgICAgICAgICAgID8g
IiBHRFNfTk8iICAgICAgICAgOiAiIiwKKyAgICAgICAgICAgKGNhcHMgJiBB
UkNIX0NBUFNfUkZEU19OTykgICAgICAgICAgICAgICAgICAgICAgICA/ICIg
UkZEU19OTyIgICAgICAgIDogIiIsCiAgICAgICAgICAgIChlOGIgICYgY3B1
ZmVhdF9tYXNrKFg4Nl9GRUFUVVJFX0lCUlNfQUxXQVlTKSkgICAgPyAiIElC
UlNfQUxXQVlTIiAgICA6ICIiLAogICAgICAgICAgICAoZThiICAmIGNwdWZl
YXRfbWFzayhYODZfRkVBVFVSRV9TVElCUF9BTFdBWVMpKSAgID8gIiBTVElC
UF9BTFdBWVMiICAgOiAiIiwKICAgICAgICAgICAgKGU4YiAgJiBjcHVmZWF0
X21hc2soWDg2X0ZFQVRVUkVfSUJSU19GQVNUKSkgICAgICA/ICIgSUJSU19G
QVNUIiAgICAgIDogIiIsCkBAIC00NTgsNyArNDU5LDcgQEAgc3RhdGljIHZv
aWQgX19pbml0IHByaW50X2RldGFpbHMoZW51bSBpbmRfdGh1bmsgdGh1bmsp
CiAgICAgICAgICAgIChlMjFhICYgY3B1ZmVhdF9tYXNrKFg4Nl9GRUFUVVJF
X1NSU09fTk8pKSAgICAgICAgPyAiIFNSU09fTk8iICAgICAgICA6ICIiKTsK
IAogICAgIC8qIEhhcmR3YXJlIGZlYXR1cmVzIHdoaWNoIG5lZWQgZHJpdmlu
ZyB0byBtaXRpZ2F0ZSBpc3N1ZXMuICovCi0gICAgcHJpbnRrKCIgIEhhcmR3
YXJlIGZlYXR1cmVzOiVzJXMlcyVzJXMlcyVzJXMlcyVzJXMlcyVzXG4iLAor
ICAgIHByaW50aygiICBIYXJkd2FyZSBmZWF0dXJlczolcyVzJXMlcyVzJXMl
cyVzJXMlcyVzJXMlcyVzXG4iLAogICAgICAgICAgICAoZThiICAmIGNwdWZl
YXRfbWFzayhYODZfRkVBVFVSRV9JQlBCKSkgfHwKICAgICAgICAgICAgKF83
ZDAgJiBjcHVmZWF0X21hc2soWDg2X0ZFQVRVUkVfSUJSU0IpKSAgICAgICAg
ICA/ICIgSUJQQiIgICAgICAgICAgIDogIiIsCiAgICAgICAgICAgIChlOGIg
ICYgY3B1ZmVhdF9tYXNrKFg4Nl9GRUFUVVJFX0lCUlMpKSB8fApAQCAtNDc2
LDYgKzQ3Nyw3IEBAIHN0YXRpYyB2b2lkIF9faW5pdCBwcmludF9kZXRhaWxz
KGVudW0gaW5kX3RodW5rIHRodW5rKQogICAgICAgICAgICAoY2FwcyAmIEFS
Q0hfQ0FQU19UU1hfQ1RSTCkgICAgICAgICAgICAgICAgICAgICAgID8gIiBU
U1hfQ1RSTCIgICAgICAgOiAiIiwKICAgICAgICAgICAgKGNhcHMgJiBBUkNI
X0NBUFNfRkJfQ0xFQVJfQ1RSTCkgICAgICAgICAgICAgICAgICA/ICIgRkJf
Q0xFQVJfQ1RSTCIgIDogIiIsCiAgICAgICAgICAgIChjYXBzICYgQVJDSF9D
QVBTX0dEU19DVFJMKSAgICAgICAgICAgICAgICAgICAgICAgPyAiIEdEU19D
VFJMIiAgICAgICA6ICIiLAorICAgICAgICAgICAoY2FwcyAmIEFSQ0hfQ0FQ
U19SRkRTX0NMRUFSKSAgICAgICAgICAgICAgICAgICAgID8gIiBSRkRTX0NM
RUFSIiAgICAgOiAiIiwKICAgICAgICAgICAgKGUyMWEgJiBjcHVmZWF0X21h
c2soWDg2X0ZFQVRVUkVfU0JQQikpICAgICAgICAgICA/ICIgU0JQQiIgICAg
ICAgICAgIDogIiIpOwogCiAgICAgLyogQ29tcGlsZWQtaW4gc3VwcG9ydCB3
aGljaCBwZXJ0YWlucyB0byBtaXRpZ2F0aW9ucy4gKi8KQEAgLTEyOTUsNiAr
MTI5Nyw4MyBAQCBzdGF0aWMgX19pbml0IHZvaWQgbWRzX2NhbGN1bGF0aW9u
cyh2b2lkKQogICAgIH0KIH0KIAorLyoKKyAqIFJlZ2lzdGVyIEZpbGUgRGF0
YSBTYW1wbGluZyBhZmZlY3RzIEF0b20gY29yZXMgZnJvbSB0aGUgR29sZG1v
bnQgdG8KKyAqIEdyYWNlbW9udCBtaWNyb2FyY2hpdGVjdHVyZXMuICBUaGUg
TWFyY2ggMjAyNCBtaWNyb2NvZGUgYWRkcyBSRkRTX05PIHRvCisgKiBzb21l
IGJ1dCBub3QgYWxsIHVuYWZmZWN0ZWQgcGFydHMsIGFuZCBSRkRTX0NMRUFS
IHRvIGFmZmVjdGVkIHBhcnRzIHN0aWxsCisgKiBpbiBzdXBwb3J0LgorICoK
KyAqIEFsZGVyIExha2UgYW5kIFJhcHRvciBMYWtlIGNsaWVudCBDUFVzIGhh
dmUgYSBtaXggb2YgUCBjb3JlcworICogKEdvbGRlbi9SYXB0b3IgQ292ZSwg
bm90IHZ1bG5lcmFibGUpIGFuZCBFIGNvcmVzIChHcmFjZW1vbnQsCisgKiB2
dWxuZXJhYmxlKSwgYW5kIGJvdGggZW51bWVyYXRlIFJGRFNfQ0xFQVIuCisg
KgorICogQm90aCBleGlzdCBpbiBhIFhlb24gU0tVLCB3aGljaCBoYXMgdGhl
IEUgY29yZXMgKEdyYWNlbW9udCkgZGlzYWJsZWQgYnkKKyAqIHBsYXRmb3Jt
IGNvbmZpZ3VyYXRpb24sIGFuZCBlbnVtZXJhdGUgUkZEU19OTy4KKyAqCisg
KiBXaXRoIG9sZGVyIHBhcnRzLCBvciB3aXRoIG91dC1vZi1kYXRlIG1pY3Jv
Y29kZSwgc3ludGhlc2lzZSBSRkRTX05PIHdoZW4KKyAqIHNhZmUgdG8gZG8g
c28uCisgKgorICogaHR0cHM6Ly93d3cuaW50ZWwuY29tL2NvbnRlbnQvd3d3
L3VzL2VuL2RldmVsb3Blci9hcnRpY2xlcy90ZWNobmljYWwvc29mdHdhcmUt
c2VjdXJpdHktZ3VpZGFuY2UvYWR2aXNvcnktZ3VpZGFuY2UvcmVnaXN0ZXIt
ZmlsZS1kYXRhLXNhbXBsaW5nLmh0bWwKKyAqLworc3RhdGljIHZvaWQgX19p
bml0IHJmZHNfY2FsY3VsYXRpb25zKHZvaWQpCit7CisgICAgLyogUkZEUyBp
cyBvbmx5IGtub3duIHRvIGFmZmVjdCBJbnRlbCBGYW1pbHkgNiBwcm9jZXNz
b3JzIGF0IHRoaXMgdGltZS4gKi8KKyAgICBpZiAoIGJvb3RfY3B1X2RhdGEu
eDg2X3ZlbmRvciAhPSBYODZfVkVORE9SX0lOVEVMIHx8CisgICAgICAgICBi
b290X2NwdV9kYXRhLng4NiAhPSA2ICkKKyAgICAgICAgcmV0dXJuOworCisg
ICAgLyoKKyAgICAgKiBJZiBSRkRTX05PIG9yIFJGRFNfQ0xFQVIgYXJlIHZp
c2libGUsIHdlJ3ZlIGVpdGhlciBnb3Qgc3VpdGFibGUKKyAgICAgKiBtaWNy
b2NvZGUsIG9yIGFuIFJGRFMtYXdhcmUgaHlwZXJ2aXNvciBpcyBsZXZlbGxp
bmcgdXMgaW4gYSBwb29sLgorICAgICAqLworICAgIGlmICggY3B1X2hhc19y
ZmRzX25vIHx8IGNwdV9oYXNfcmZkc19jbGVhciApCisgICAgICAgIHJldHVy
bjsKKworICAgIC8qIElmIHdlJ3JlIHZpcnR1YWxpc2VkLCBkb24ndCBhdHRl
bXB0IHRvIHN5bnRoZXNpc2UgUkZEU19OTy4gKi8KKyAgICBpZiAoIGNwdV9o
YXNfaHlwZXJ2aXNvciApCisgICAgICAgIHJldHVybjsKKworICAgIC8qCisg
ICAgICogTm90IGFsbCBDUFVzIGFyZSBleHBlY3RlZCB0byBnZXQgYSBtaWNy
b2NvZGUgdXBkYXRlIGVudW1lcmF0aW5nIG9uZSBvZgorICAgICAqIFJGRFNf
e05PLENMRUFSfSwgb3Igd2UgbWlnaHQgaGF2ZSBvdXQtb2YtZGF0ZSBtaWNy
b2NvZGUuCisgICAgICovCisgICAgc3dpdGNoICggYm9vdF9jcHVfZGF0YS54
ODZfbW9kZWwgKQorICAgIHsKKyAgICBjYXNlIDB4OTc6IC8qIElOVEVMX0ZB
TTZfQUxERVJMQUtFICovCisgICAgY2FzZSAweEI3OiAvKiBJTlRFTF9GQU02
X1JBUFRPUkxBS0UgKi8KKyAgICAgICAgLyoKKyAgICAgICAgICogQWxkZXIg
TGFrZSBhbmQgUmFwdG9yIExha2UgbWlnaHQgYmUgYSBjbGllbnQgU0tVICh3
aXRoIHRoZQorICAgICAgICAgKiBHcmFjZW1vbnQgY29yZXMgYWN0aXZlLCBh
bmQgdGhlcmVmb3JlIHZ1bG5lcmFibGUpIG9yIG1pZ2h0IGJlIGEKKyAgICAg
ICAgICogc2VydmVyIFNLVSAod2l0aCB0aGUgR3JhY2Vtb250IGNvcmVzIGRp
c2FibGVkLCBhbmQgdGhlcmVmb3JlIG5vdAorICAgICAgICAgKiB2dWxuZXJh
YmxlKS4KKyAgICAgICAgICoKKyAgICAgICAgICogU2VlIGlmIHRoZSBDUFUg
aWRlbnRpZmllcyBhcyBoeWJyaWQgdG8gZGlzdGluZ3Vpc2ggdGhlIHR3byBj
YXNlcy4KKyAgICAgICAgICovCisgICAgICAgIGlmICggIWNwdV9oYXNfaHli
cmlkICkKKyAgICAgICAgICAgIGJyZWFrOworICAgICAgICAvKiBmYWxsdGhy
b3VnaCAqLworICAgIGNhc2UgMHg5QTogLyogSU5URUxfRkFNNl9BTERFUkxB
S0VfTCAqLworICAgIGNhc2UgMHhCQTogLyogSU5URUxfRkFNNl9SQVBUT1JM
QUtFX1AgKi8KKyAgICBjYXNlIDB4QkY6IC8qIElOVEVMX0ZBTTZfUkFQVE9S
TEFLRV9TICovCisKKyAgICBjYXNlIDB4NUM6IC8qIElOVEVMX0ZBTTZfQVRP
TV9HT0xETU9OVCAqLyAgICAgIC8qIEFwb2xsbyBMYWtlICovCisgICAgY2Fz
ZSAweDVGOiAvKiBJTlRFTF9GQU02X0FUT01fR09MRE1PTlRfRCAqLyAgICAv
KiBEZW52ZXJ0b24gKi8KKyAgICBjYXNlIDB4N0E6IC8qIElOVEVMX0ZBTTZf
QVRPTV9HT0xETU9OVF9QTFVTICovIC8qIEdlbWluaSBMYWtlICovCisgICAg
Y2FzZSAweDg2OiAvKiBJTlRFTF9GQU02X0FUT01fVFJFTU9OVF9EICovICAg
ICAvKiBTbm93IFJpZGdlIC8gUGFya2VyIFJpZGdlICovCisgICAgY2FzZSAw
eDk2OiAvKiBJTlRFTF9GQU02X0FUT01fVFJFTU9OVCAqLyAgICAgICAvKiBF
bGtoYXJ0IExha2UgKi8KKyAgICBjYXNlIDB4OUM6IC8qIElOVEVMX0ZBTTZf
QVRPTV9UUkVNT05UX0wgKi8gICAgIC8qIEphc3BlciBMYWtlICovCisgICAg
Y2FzZSAweEJFOiAvKiBJTlRFTF9GQU02X0FUT01fR1JBQ0VNT05UICovICAg
ICAvKiBBbGRlciBMYWtlIE4gKi8KKyAgICAgICAgcmV0dXJuOworICAgIH0K
KworICAgIC8qCisgICAgICogV2UgYXBwZWFyIHRvIGJlIG9uIGFuIHVuYWZm
ZWN0ZWQgQ1BVIHdoaWNoIGRpZG4ndCBlbnVtZXJhdGUgUkZEU19OTywKKyAg
ICAgKiBwZXJoYXBzIGJlY2F1c2Ugb2YgaXQncyBhZ2Ugb3IgYmVjYXVzZSBv
ZiBvdXQtb2YtZGF0ZSBtaWNyb2NvZGUuCisgICAgICogU3ludGhlc2lzZSBp
dC4KKyAgICAgKi8KKyAgICBzZXR1cF9mb3JjZV9jcHVfY2FwKFg4Nl9GRUFU
VVJFX1JGRFNfTk8pOworfQorCiBzdGF0aWMgYm9vbCBfX2luaXQgY3B1X2hh
c19nZHModm9pZCkKIHsKICAgICAvKgpAQCAtMTc1OSw2ICsxODM4LDcgQEAg
dm9pZCBfX2luaXQgaW5pdF9zcGVjdWxhdGlvbl9taXRpZ2F0aW9ucyh2b2lk
KQogICAgICAqCiAgICAgICogaHR0cHM6Ly93d3cuaW50ZWwuY29tL2NvbnRl
bnQvd3d3L3VzL2VuL2RldmVsb3Blci9hcnRpY2xlcy90ZWNobmljYWwvc29m
dHdhcmUtc2VjdXJpdHktZ3VpZGFuY2UvdGVjaG5pY2FsLWRvY3VtZW50YXRp
b24vaW50ZWwtYW5hbHlzaXMtbWljcm9hcmNoaXRlY3R1cmFsLWRhdGEtc2Ft
cGxpbmcuaHRtbAogICAgICAqIGh0dHBzOi8vd3d3LmludGVsLmNvbS9jb250
ZW50L3d3dy91cy9lbi9kZXZlbG9wZXIvYXJ0aWNsZXMvdGVjaG5pY2FsL3Nv
ZnR3YXJlLXNlY3VyaXR5LWd1aWRhbmNlL3RlY2huaWNhbC1kb2N1bWVudGF0
aW9uL3Byb2Nlc3Nvci1tbWlvLXN0YWxlLWRhdGEtdnVsbmVyYWJpbGl0aWVz
Lmh0bWwKKyAgICAgKiBodHRwczovL3d3dy5pbnRlbC5jb20vY29udGVudC93
d3cvdXMvZW4vZGV2ZWxvcGVyL2FydGljbGVzL3RlY2huaWNhbC9zb2Z0d2Fy
ZS1zZWN1cml0eS1ndWlkYW5jZS9hZHZpc29yeS1ndWlkYW5jZS9yZWdpc3Rl
ci1maWxlLWRhdGEtc2FtcGxpbmcuaHRtbAogICAgICAqCiAgICAgICogUmVs
ZXZhbnQgdWNvZGVzOgogICAgICAqCkBAIC0xNzg4LDggKzE4NjgsMTIgQEAg
dm9pZCBfX2luaXQgaW5pdF9zcGVjdWxhdGlvbl9taXRpZ2F0aW9ucyh2b2lk
KQogICAgICAqCiAgICAgICogICBJZiBGQl9DTEVBUiBpcyBlbnVtZXJhdGVk
LCBMMURfRkxVU0ggZG9lcyBub3QgaGF2ZSB0aGUgc2FtZSBzY3J1YmJpbmcK
ICAgICAgKiAgIHNpZGUgZWZmZWN0cyBhcyBWRVJXIGFuZCBjYW5ub3QgYmUg
dXNlZCBpbiBpdHMgcGxhY2UuCisgICAgICoKKyAgICAgKiAtIE1hcmNoIDIw
MjMsIGZvciBSRkRTLiAgRW51bWVyYXRlIFJGRFNfQ0xFQVIgdG8gbWVhbiB0
aGF0IFZFUlcgbm93CisgICAgICogICBzY3J1YnMgbm9uLWFyY2hpdGVjdHVy
YWwgZW50cmllcyBmcm9tIGNlcnRhaW4gcmVnaXN0ZXIgZmlsZXMuCiAgICAg
ICovCiAgICAgbWRzX2NhbGN1bGF0aW9ucygpOworICAgIHJmZHNfY2FsY3Vs
YXRpb25zKCk7CiAKICAgICAvKgogICAgICAqIFBhcnRzIHdoaWNoIGVudW1l
cmF0ZSBGQl9DTEVBUiBhcmUgdGhvc2Ugd2l0aCBub3ctdXBkYXRlZCBtaWNy
b2NvZGUKQEAgLTE4MjEsMTUgKzE5MDUsMTkgQEAgdm9pZCBfX2luaXQgaW5p
dF9zcGVjdWxhdGlvbl9taXRpZ2F0aW9ucyh2b2lkKQogICAgICAqIE1MUERT
L01GQkRTIHdoZW4gU01UIGlzIGVuYWJsZWQuCiAgICAgICovCiAgICAgaWYg
KCBvcHRfdmVyd19wdiA9PSAtMSApCi0gICAgICAgIG9wdF92ZXJ3X3B2ID0g
Y3B1X2hhc191c2VmdWxfbWRfY2xlYXI7CisgICAgICAgIG9wdF92ZXJ3X3B2
ID0gY3B1X2hhc191c2VmdWxfbWRfY2xlYXIgfHwgY3B1X2hhc19yZmRzX2Ns
ZWFyOwogCiAgICAgaWYgKCBvcHRfdmVyd19odm0gPT0gLTEgKQotICAgICAg
ICBvcHRfdmVyd19odm0gPSBjcHVfaGFzX3VzZWZ1bF9tZF9jbGVhcjsKKyAg
ICAgICAgb3B0X3ZlcndfaHZtID0gY3B1X2hhc191c2VmdWxfbWRfY2xlYXIg
fHwgY3B1X2hhc19yZmRzX2NsZWFyOwogCiAgICAgLyoKICAgICAgKiBJZiBT
TVQgaXMgYWN0aXZlLCBhbmQgd2UncmUgcHJvdGVjdGluZyBhZ2FpbnN0IE1E
UyBvciBNTUlPIHN0YWxlIGRhdGEsCiAgICAgICogd2UgbmVlZCB0byBzY3J1
YiBiZWZvcmUgZ29pbmcgaWRsZSBhcyB3ZWxsIGFzIG9uIHJldHVybiB0byBn
dWVzdC4KICAgICAgKiBWYXJpb3VzIHBpcGVsaW5lIHJlc291cmNlcyBhcmUg
cmVwYXJ0aXRpb25lZCBhbW9uZ3N0IG5vbi1pZGxlIHRocmVhZHMuCisgICAg
ICoKKyAgICAgKiBXZSBkb24ndCBuZWVkIHRvIHNjcnViIG9uIGlkbGUgZm9y
IFJGRFMuICBUaGVyZSBhcmUgbm8gYWZmZWN0ZWQgY29yZXMKKyAgICAgKiB3
aGljaCBzdXBwb3J0IFNNVCwgZGVzcGl0ZSB0aGVyZSBiZWluZyBhZmZlY3Rl
ZCBjb3JlcyBpbiBoeWJyaWQgc3lzdGVtcworICAgICAqIHdoaWNoIGhhdmUg
U01UIGVsc2V3aGVyZSBpbiB0aGUgcGxhdGZvcm0uCiAgICAgICovCiAgICAg
aWYgKCAoKGNwdV9oYXNfdXNlZnVsX21kX2NsZWFyICYmIChvcHRfdmVyd19w
diB8fCBvcHRfdmVyd19odm0pKSB8fAogICAgICAgICAgIG9wdF92ZXJ3X21t
aW8pICYmIGh3X3NtdF9lbmFibGVkICkKQEAgLTE4NDMsNyArMTkzMSw4IEBA
IHZvaWQgX19pbml0IGluaXRfc3BlY3VsYXRpb25fbWl0aWdhdGlvbnModm9p
ZCkKICAgICAgKiBJdCBpcyBvbmx5IHNhZmUgdG8gdXNlIEwxRF9GTFVTSCBp
biBwbGFjZSBvZiBWRVJXIHdoZW4gTURfQ0xFQVIgaXMgdGhlCiAgICAgICog
b25seSAqX0NMRUFSIHdlIGNhbiBzZWUuCiAgICAgICovCi0gICAgaWYgKCBv
cHRfbDFkX2ZsdXNoICYmIGNwdV9oYXNfbWRfY2xlYXIgJiYgIWNwdV9oYXNf
ZmJfY2xlYXIgKQorICAgIGlmICggb3B0X2wxZF9mbHVzaCAmJiBjcHVfaGFz
X21kX2NsZWFyICYmICFjcHVfaGFzX2ZiX2NsZWFyICYmCisgICAgICAgICAh
Y3B1X2hhc19yZmRzX2NsZWFyICkKICAgICAgICAgb3B0X3ZlcndfaHZtID0g
ZmFsc2U7CiAKICAgICAvKgpkaWZmIC0tZ2l0IGEveGVuL2luY2x1ZGUvYXNt
LXg4Ni9jcHVmZWF0dXJlLmggYi94ZW4vaW5jbHVkZS9hc20teDg2L2NwdWZl
YXR1cmUuaAppbmRleCAzYjExNmM2ZGQzNjQuLjg5MmFmMTEzODQ5YSAxMDA2
NDQKLS0tIGEveGVuL2luY2x1ZGUvYXNtLXg4Ni9jcHVmZWF0dXJlLmgKKysr
IGIveGVuL2luY2x1ZGUvYXNtLXg4Ni9jcHVmZWF0dXJlLmgKQEAgLTE0MSw2
ICsxNDEsNyBAQAogI2RlZmluZSBjcHVfaGFzX3J0bV9hbHdheXNfYWJvcnQg
Ym9vdF9jcHVfaGFzKFg4Nl9GRUFUVVJFX1JUTV9BTFdBWVNfQUJPUlQpCiAj
ZGVmaW5lIGNwdV9oYXNfdHN4X2ZvcmNlX2Fib3J0IGJvb3RfY3B1X2hhcyhY
ODZfRkVBVFVSRV9UU1hfRk9SQ0VfQUJPUlQpCiAjZGVmaW5lIGNwdV9oYXNf
c2VyaWFsaXplICAgICAgIGJvb3RfY3B1X2hhcyhYODZfRkVBVFVSRV9TRVJJ
QUxJWkUpCisjZGVmaW5lIGNwdV9oYXNfaHlicmlkICAgICAgICAgIGJvb3Rf
Y3B1X2hhcyhYODZfRkVBVFVSRV9IWUJSSUQpCiAjZGVmaW5lIGNwdV9oYXNf
YXJjaF9jYXBzICAgICAgIGJvb3RfY3B1X2hhcyhYODZfRkVBVFVSRV9BUkNI
X0NBUFMpCiAKIC8qIENQVUlEIGxldmVsIDB4MDAwMDAwMDc6MS5lYXggKi8K
QEAgLTE2MCw2ICsxNjEsOCBAQAogI2RlZmluZSBjcHVfaGFzX3Jyc2JhICAg
ICAgICAgICBib290X2NwdV9oYXMoWDg2X0ZFQVRVUkVfUlJTQkEpCiAjZGVm
aW5lIGNwdV9oYXNfZ2RzX2N0cmwgICAgICAgIGJvb3RfY3B1X2hhcyhYODZf
RkVBVFVSRV9HRFNfQ1RSTCkKICNkZWZpbmUgY3B1X2hhc19nZHNfbm8gICAg
ICAgICAgYm9vdF9jcHVfaGFzKFg4Nl9GRUFUVVJFX0dEU19OTykKKyNkZWZp
bmUgY3B1X2hhc19yZmRzX25vICAgICAgICAgYm9vdF9jcHVfaGFzKFg4Nl9G
RUFUVVJFX1JGRFNfTk8pCisjZGVmaW5lIGNwdV9oYXNfcmZkc19jbGVhciAg
ICAgIGJvb3RfY3B1X2hhcyhYODZfRkVBVFVSRV9SRkRTX0NMRUFSKQogCiAv
KiBTeW50aGVzaXplZC4gKi8KICNkZWZpbmUgY3B1X2hhc19hcmNoX3BlcmZt
b24gICAgYm9vdF9jcHVfaGFzKFg4Nl9GRUFUVVJFX0FSQ0hfUEVSRk1PTikK
ZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL2FzbS14ODYvbXNyLWluZGV4Lmgg
Yi94ZW4vaW5jbHVkZS9hc20teDg2L21zci1pbmRleC5oCmluZGV4IDhiM2Fk
NTc1ZGJjMC4uMTdhYmZhMGU0YTJkIDEwMDY0NAotLS0gYS94ZW4vaW5jbHVk
ZS9hc20teDg2L21zci1pbmRleC5oCisrKyBiL3hlbi9pbmNsdWRlL2FzbS14
ODYvbXNyLWluZGV4LmgKQEAgLTcwLDYgKzcwLDggQEAKICNkZWZpbmUgIEFS
Q0hfQ0FQU19QQlJTQl9OTyAgICAgICAgICAgICAgICAgKF9BQygxLCBVTEwp
IDw8IDI0KQogI2RlZmluZSAgQVJDSF9DQVBTX0dEU19DVFJMICAgICAgICAg
ICAgICAgICAoX0FDKDEsIFVMTCkgPDwgMjUpCiAjZGVmaW5lICBBUkNIX0NB
UFNfR0RTX05PICAgICAgICAgICAgICAgICAgIChfQUMoMSwgVUxMKSA8PCAy
NikKKyNkZWZpbmUgIEFSQ0hfQ0FQU19SRkRTX05PICAgICAgICAgICAgICAg
ICAgKF9BQygxLCBVTEwpIDw8IDI3KQorI2RlZmluZSAgQVJDSF9DQVBTX1JG
RFNfQ0xFQVIgICAgICAgICAgICAgICAoX0FDKDEsIFVMTCkgPDwgMjgpCiAK
ICNkZWZpbmUgTVNSX0ZMVVNIX0NNRCAgICAgICAgICAgICAgICAgICAgICAg
MHgwMDAwMDEwYgogI2RlZmluZSAgRkxVU0hfQ01EX0wxRCAgICAgICAgICAg
ICAgICAgICAgICAoX0FDKDEsIFVMTCkgPDwgIDApCmRpZmYgLS1naXQgYS94
ZW4vaW5jbHVkZS9wdWJsaWMvYXJjaC14ODYvY3B1ZmVhdHVyZXNldC5oIGIv
eGVuL2luY2x1ZGUvcHVibGljL2FyY2gteDg2L2NwdWZlYXR1cmVzZXQuaApp
bmRleCBiNGY2OGE1OWI4NTkuLmUwMjdhMzFkNjdhYyAxMDA2NDQKLS0tIGEv
eGVuL2luY2x1ZGUvcHVibGljL2FyY2gteDg2L2NwdWZlYXR1cmVzZXQuaAor
KysgYi94ZW4vaW5jbHVkZS9wdWJsaWMvYXJjaC14ODYvY3B1ZmVhdHVyZXNl
dC5oCkBAIC0yNzcsNiArMjc3LDcgQEAgWEVOX0NQVUZFQVRVUkUoTURfQ0xF
QVIsICAgICAgOSozMisxMCkgLyohQSBWRVJXIGNsZWFycyBtaWNyb2FyY2hp
dGVjdHVyYWwgYnVmZmUKIFhFTl9DUFVGRUFUVVJFKFJUTV9BTFdBWVNfQUJP
UlQsIDkqMzIrMTEpIC8qISBKdW5lIDIwMjEgVFNYIGRlZmVhdHVyaW5nIGlu
IG1pY3JvY29kZS4gKi8KIFhFTl9DUFVGRUFUVVJFKFRTWF9GT1JDRV9BQk9S
VCwgOSozMisxMykgLyogTVNSX1RTWF9GT1JDRV9BQk9SVC5SVE1fQUJPUlQg
Ki8KIFhFTl9DUFVGRUFUVVJFKFNFUklBTElaRSwgICAgIDkqMzIrMTQpIC8q
YSAgU0VSSUFMSVpFIGluc24gKi8KK1hFTl9DUFVGRUFUVVJFKEhZQlJJRCwg
ICAgICAgIDkqMzIrMTUpIC8qICAgSGV0ZXJvZ2VuZW91cyBwbGF0Zm9ybSAq
LwogWEVOX0NQVUZFQVRVUkUoVFNYTERUUkssICAgICAgOSozMisxNikgLyph
ICBUU1ggbG9hZCB0cmFja2luZyBzdXNwZW5kL3Jlc3VtZSBpbnNucyAqLwog
WEVOX0NQVUZFQVRVUkUoQ0VUX0lCVCwgICAgICAgOSozMisyMCkgLyogICBD
RVQgLSBJbmRpcmVjdCBCcmFuY2ggVHJhY2tpbmcgKi8KIFhFTl9DUFVGRUFU
VVJFKElCUlNCLCAgICAgICAgIDkqMzIrMjYpIC8qQSAgSUJSUyBhbmQgSUJQ
QiBzdXBwb3J0ICh1c2VkIGJ5IEludGVsKSAqLwpAQCAtMzMxLDYgKzMzMiw4
IEBAIFhFTl9DUFVGRUFUVVJFKE9WUkNMS19TVEFUVVMsICAgICAgMTYqMzIr
MjMpIC8qICAgTVNSX09WRVJDTE9DS0lOR19TVEFUVVMgKi8KIFhFTl9DUFVG
RUFUVVJFKFBCUlNCX05PLCAgICAgICAgICAgMTYqMzIrMjQpIC8qQSAgTm8g
UG9zdC1CYXJyaWVyIFJTQiBwcmVkaWN0aW9ucyAqLwogWEVOX0NQVUZFQVRV
UkUoR0RTX0NUUkwsICAgICAgICAgICAxNiozMisyNSkgLyogICBNQ1VfT1BU
X0NUUkwuR0RTX01JVF97RElTLExPQ0t9ICovCiBYRU5fQ1BVRkVBVFVSRShH
RFNfTk8sICAgICAgICAgICAgIDE2KjMyKzI2KSAvKkEgIE5vIEdhdGhlciBE
YXRhIFNhbXBsaW5nICovCitYRU5fQ1BVRkVBVFVSRShSRkRTX05PLCAgICAg
ICAgICAgIDE2KjMyKzI3KSAvKkEgIE5vIFJlZ2lzdGVyIEZpbGUgRGF0YSBT
YW1wbGluZyAqLworWEVOX0NQVUZFQVRVUkUoUkZEU19DTEVBUiwgICAgICAg
ICAxNiozMisyOCkgLyohQSBSZWdpc3RlciBGaWxlKHMpIGNsZWFyZWQgYnkg
VkVSVyAqLwogCiAvKiBJbnRlbC1kZWZpbmVkIENQVSBmZWF0dXJlcywgTVNS
X0FSQ0hfQ0FQUyAweDEwYS5lZHgsIHdvcmQgMTcgKi8KIAo=

--=separator
Content-Type: application/octet-stream; name="xsa452/xsa452-4.16-1.patch"
Content-Disposition: attachment; filename="xsa452/xsa452-4.16-1.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L2VudHJ5OiBJbnRyb2R1Y2UgRUZSQU1FXyogY29u
c3RhbnRzCgpyZXN0b3JlX2FsbF9ndWVzdCgpIGRvZXMgYSBsb3Qgb2YgbWFu
aXB1bGF0aW9uIG9mIHRoZSBzdGFjayBhZnRlciBwb3BwaW5nIHRoZQpHUFJz
LCBhbmQgdXNlcyByYXcgJXJzcCBkaXNwbGFjZW1lbnRzIHRvIGRvIHNvLiAg
QWxzbywgYWxtb3N0IGFsbCBlbnRyeXBhdGhzCnVzZSByYXcgJXJzcCBkaXNw
bGFjZW1lbnRzIHByaW9yIHRvIHB1c2hpbmcgR1BScy4KClByb3ZpZGUgYmV0
dGVyIG1uZW1vbmljcywgdG8gYWlkIHJlYWRhYmlsaXR5IGFuZCByZWR1Y2Ug
dGhlIGNoYW5jZSBvZiBlcnJvcnMKd2hlbiBlZGl0aW5nLgoKTm8gZnVuY3Rp
b25hbCBjaGFuZ2UuICBUaGUgcmVzdWx0aW5nIGJpbmFyeSBpcyBpZGVudGlj
YWwuCgpTaWduZWQtb2ZmLWJ5OiBBbmRyZXcgQ29vcGVyIDxhbmRyZXcuY29v
cGVyM0BjaXRyaXguY29tPgpSZXZpZXdlZC1ieTogSmFuIEJldWxpY2ggPGpi
ZXVsaWNoQHN1c2UuY29tPgooY2hlcnJ5IHBpY2tlZCBmcm9tIGNvbW1pdCAz
NzU0MTIwOGYxMTlhOWM1NTJjNmM2YzMyNDZlYTYxYmUwZDQ0MDM1KQoKZGlm
ZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni94ODZfNjQvYXNtLW9mZnNldHMuYyBi
L3hlbi9hcmNoL3g4Ni94ODZfNjQvYXNtLW9mZnNldHMuYwppbmRleCAyODdk
YWMxMDFhZDQuLjMxZmE2M2I3N2ZkMSAxMDA2NDQKLS0tIGEveGVuL2FyY2gv
eDg2L3g4Nl82NC9hc20tb2Zmc2V0cy5jCisrKyBiL3hlbi9hcmNoL3g4Ni94
ODZfNjQvYXNtLW9mZnNldHMuYwpAQCAtNTEsNiArNTEsMjMgQEAgdm9pZCBf
X2R1bW15X18odm9pZCkKICAgICBPRkZTRVQoVVJFR1Nfa2VybmVsX3NpemVv
Ziwgc3RydWN0IGNwdV91c2VyX3JlZ3MsIGVzKTsKICAgICBCTEFOSygpOwog
CisgICAgLyoKKyAgICAgKiBFRlJBTUVfKiBpcyBmb3IgdGhlIGVudHJ5L2V4
aXQgbG9naWMgd2hlcmUgJXJzcCBpcyBwb2ludGluZyBhdAorICAgICAqIFVS
RUdTX2Vycm9yX2NvZGUgYW5kIEdQUnMgYXJlIHN0aWxsL2FscmVhZHkgZ3Vl
c3QgdmFsdWVzLgorICAgICAqLworI2RlZmluZSBPRkZTRVRfRUYoc3ltLCBt
ZW0pICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgXAorICAgIERFRklORShzeW0sIG9mZnNldG9mKHN0cnVjdCBjcHVfdXNl
cl9yZWdzLCBtZW0pIC0gICAgICAgICAgICAgICAgICAgXAorICAgICAgICAg
ICAgICAgIG9mZnNldG9mKHN0cnVjdCBjcHVfdXNlcl9yZWdzLCBlcnJvcl9j
b2RlKSkKKworICAgIE9GRlNFVF9FRihFRlJBTUVfZW50cnlfdmVjdG9yLCAg
ICBlbnRyeV92ZWN0b3IpOworICAgIE9GRlNFVF9FRihFRlJBTUVfcmlwLCAg
ICAgICAgICAgICByaXApOworICAgIE9GRlNFVF9FRihFRlJBTUVfY3MsICAg
ICAgICAgICAgICBjcyk7CisgICAgT0ZGU0VUX0VGKEVGUkFNRV9lZmxhZ3Ms
ICAgICAgICAgIGVmbGFncyk7CisgICAgT0ZGU0VUX0VGKEVGUkFNRV9yc3As
ICAgICAgICAgICAgIHJzcCk7CisgICAgQkxBTksoKTsKKworI3VuZGVmIE9G
RlNFVF9FRgorCiAgICAgT0ZGU0VUKFZDUFVfcHJvY2Vzc29yLCBzdHJ1Y3Qg
dmNwdSwgcHJvY2Vzc29yKTsKICAgICBPRkZTRVQoVkNQVV9kb21haW4sIHN0
cnVjdCB2Y3B1LCBkb21haW4pOwogICAgIE9GRlNFVChWQ1BVX3ZjcHVfaW5m
bywgc3RydWN0IHZjcHUsIHZjcHVfaW5mbyk7CmRpZmYgLS1naXQgYS94ZW4v
YXJjaC94ODYveDg2XzY0L2NvbXBhdC9lbnRyeS5TIGIveGVuL2FyY2gveDg2
L3g4Nl82NC9jb21wYXQvZW50cnkuUwppbmRleCAyNTNiYjE2ODhjNGYuLjdj
MjExMzE0ZDg4NSAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L3g4Nl82NC9j
b21wYXQvZW50cnkuUworKysgYi94ZW4vYXJjaC94ODYveDg2XzY0L2NvbXBh
dC9lbnRyeS5TCkBAIC0xNSw3ICsxNSw3IEBAIEVOVFJZKGVudHJ5X2ludDgy
KQogICAgICAgICBFTkRCUjY0CiAgICAgICAgIEFMVEVSTkFUSVZFICIiLCBj
bGFjLCBYODZfRkVBVFVSRV9YRU5fU01BUAogICAgICAgICBwdXNocSAkMAot
ICAgICAgICBtb3ZsICAkSFlQRVJDQUxMX1ZFQ1RPUiwgNCglcnNwKQorICAg
ICAgICBtb3ZsICAkSFlQRVJDQUxMX1ZFQ1RPUiwgRUZSQU1FX2VudHJ5X3Zl
Y3RvciglcnNwKQogICAgICAgICBTQVZFX0FMTCBjb21wYXQ9MSAvKiBEUEwx
IGdhdGUsIHJlc3RyaWN0ZWQgdG8gMzJiaXQgUFYgZ3Vlc3RzIG9ubHkuICov
CiAKICAgICAgICAgU1BFQ19DVFJMX0VOVFJZX0ZST01fUFYgLyogUmVxOiAl
cnNwPXJlZ3MvY3B1aW5mbywgJXJkeD0wLCBDbG9iOiBhY2QgKi8KZGlmZiAt
LWdpdCBhL3hlbi9hcmNoL3g4Ni94ODZfNjQvZW50cnkuUyBiL3hlbi9hcmNo
L3g4Ni94ODZfNjQvZW50cnkuUwppbmRleCA4MzdhMzFiNDA1MjQuLjEwZjEx
OTg2ZDhiOSAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L3g4Nl82NC9lbnRy
eS5TCisrKyBiL3hlbi9hcmNoL3g4Ni94ODZfNjQvZW50cnkuUwpAQCAtMTkw
LDE1ICsxOTAsMTUgQEAgcmVzdG9yZV9hbGxfZ3Vlc3Q6CiAgICAgICAgIFNQ
RUNfQ1RSTF9FWElUX1RPX1BWICAgIC8qIFJlcTogYT1zcGVjX2N0cmwgJXJz
cD1yZWdzL2NwdWluZm8sIENsb2I6IGNkICovCiAKICAgICAgICAgUkVTVE9S
RV9BTEwKLSAgICAgICAgdGVzdHcgJFRSQVBfc3lzY2FsbCw0KCVyc3ApCisg
ICAgICAgIHRlc3R3ICRUUkFQX3N5c2NhbGwsIEVGUkFNRV9lbnRyeV92ZWN0
b3IoJXJzcCkKICAgICAgICAganogICAgaXJldF9leGl0X3RvX2d1ZXN0CiAK
LSAgICAgICAgbW92cSAgMjQoJXJzcCksJXIxMSAgICAgICAgICAgIyBSRkxB
R1MKKyAgICAgICAgbW92ICAgRUZSQU1FX2VmbGFncyglcnNwKSwgJXIxMQog
ICAgICAgICBhbmRxICAkfihYODZfRUZMQUdTX0lPUEwgfCBYODZfRUZMQUdT
X1ZNKSwgJXIxMQogICAgICAgICBvcnEgICAkWDg2X0VGTEFHU19JRiwlcjEx
CiAKICAgICAgICAgLyogRG9uJ3QgdXNlIFNZU1JFVCBwYXRoIGlmIHRoZSBy
ZXR1cm4gYWRkcmVzcyBpcyBub3QgY2Fub25pY2FsLiAqLwotICAgICAgICBt
b3ZxICA4KCVyc3ApLCVyY3gKKyAgICAgICAgbW92ICAgRUZSQU1FX3JpcCgl
cnNwKSwgJXJjeAogICAgICAgICBzYXJxICAkNDcsJXJjeAogICAgICAgICBp
bmNsICAlZWN4CiAgICAgICAgIGNtcGwgICQxLCVlY3gKQEAgLTIxMywyMCAr
MjEzLDIwIEBAIHJlc3RvcmVfYWxsX2d1ZXN0OgogICAgICAgICBBTFRFUk5B
VElWRSAiIiwgcmFnX2NscnNzYnN5LCBYODZfRkVBVFVSRV9YRU5fU0hTVEsK
ICNlbmRpZgogCi0gICAgICAgIG1vdnEgIDgoJXJzcCksICVyY3ggICAgICAg
ICAgICMgUklQCi0gICAgICAgIGNtcHcgICRGTEFUX1VTRVJfQ1MzMiwxNigl
cnNwKSMgQ1MKLSAgICAgICAgbW92cSAgMzIoJXJzcCksJXJzcCAgICAgICAg
ICAgIyBSU1AKKyAgICAgICAgbW92ICAgRUZSQU1FX3JpcCglcnNwKSwgJXJj
eAorICAgICAgICBjbXB3ICAkRkxBVF9VU0VSX0NTMzIsIEVGUkFNRV9jcygl
cnNwKQorICAgICAgICBtb3YgICBFRlJBTUVfcnNwKCVyc3ApLCAlcnNwCiAg
ICAgICAgIGplICAgIDFmCiAgICAgICAgIHN5c3JldHEKIDE6ICAgICAgc3lz
cmV0bAogCiAgICAgICAgIEFMSUdOCiAuTHJlc3RvcmVfcmN4X2lyZXRfZXhp
dF90b19ndWVzdDoKLSAgICAgICAgbW92cSAgOCglcnNwKSwgJXJjeCAgICAg
ICAgICAgIyBSSVAKKyAgICAgICAgbW92ICAgRUZSQU1FX3JpcCglcnNwKSwg
JXJjeAogLyogTm8gc3BlY2lhbCByZWdpc3RlciBhc3N1bXB0aW9ucy4gKi8K
IGlyZXRfZXhpdF90b19ndWVzdDoKLSAgICAgICAgYW5kbCAgJH4oWDg2X0VG
TEFHU19JT1BMIHwgWDg2X0VGTEFHU19WTSksIDI0KCVyc3ApCi0gICAgICAg
IG9ybCAgICRYODZfRUZMQUdTX0lGLDI0KCVyc3ApCisgICAgICAgIGFuZGwg
ICR+KFg4Nl9FRkxBR1NfSU9QTCB8IFg4Nl9FRkxBR1NfVk0pLCBFRlJBTUVf
ZWZsYWdzKCVyc3ApCisgICAgICAgIG9ybCAgICRYODZfRUZMQUdTX0lGLCBF
RlJBTUVfZWZsYWdzKCVyc3ApCiAgICAgICAgIGFkZHEgICQ4LCVyc3AKIC5M
ZnQwOiAgaXJldHEKICAgICAgICAgX0FTTV9QUkVfRVhUQUJMRSguTGZ0MCwg
aGFuZGxlX2V4Y2VwdGlvbikKQEAgLTI1Nyw3ICsyNTcsNyBAQCBFTlRSWShs
c3Rhcl9lbnRlcikKICAgICAgICAgcHVzaHEgJEZMQVRfS0VSTkVMX0NTNjQK
ICAgICAgICAgcHVzaHEgJXJjeAogICAgICAgICBwdXNocSAkMAotICAgICAg
ICBtb3ZsICAkVFJBUF9zeXNjYWxsLCA0KCVyc3ApCisgICAgICAgIG1vdmwg
ICRUUkFQX3N5c2NhbGwsIEVGUkFNRV9lbnRyeV92ZWN0b3IoJXJzcCkKICAg
ICAgICAgU0FWRV9BTEwKIAogICAgICAgICBTUEVDX0NUUkxfRU5UUllfRlJP
TV9QViAvKiBSZXE6ICVyc3A9cmVncy9jcHVpbmZvLCAlcmR4PTAsIENsb2I6
IGFjZCAqLwpAQCAtMjk0LDcgKzI5NCw3IEBAIEVOVFJZKGNzdGFyX2VudGVy
KQogICAgICAgICBwdXNocSAkRkxBVF9VU0VSX0NTMzIKICAgICAgICAgcHVz
aHEgJXJjeAogICAgICAgICBwdXNocSAkMAotICAgICAgICBtb3ZsICAkVFJB
UF9zeXNjYWxsLCA0KCVyc3ApCisgICAgICAgIG1vdmwgICRUUkFQX3N5c2Nh
bGwsIEVGUkFNRV9lbnRyeV92ZWN0b3IoJXJzcCkKICAgICAgICAgU0FWRV9B
TEwKIAogICAgICAgICBTUEVDX0NUUkxfRU5UUllfRlJPTV9QViAvKiBSZXE6
ICVyc3A9cmVncy9jcHVpbmZvLCAlcmR4PTAsIENsb2I6IGFjZCAqLwpAQCAt
MzM1LDcgKzMzNSw3IEBAIEdMT0JBTChzeXNlbnRlcl9lZmxhZ3Nfc2F2ZWQp
CiAgICAgICAgIHB1c2hxICQzIC8qIHJpbmcgMyBudWxsIGNzICovCiAgICAg
ICAgIHB1c2hxICQwIC8qIG51bGwgcmlwICovCiAgICAgICAgIHB1c2hxICQw
Ci0gICAgICAgIG1vdmwgICRUUkFQX3N5c2NhbGwsIDQoJXJzcCkKKyAgICAg
ICAgbW92bCAgJFRSQVBfc3lzY2FsbCwgRUZSQU1FX2VudHJ5X3ZlY3Rvcigl
cnNwKQogICAgICAgICBTQVZFX0FMTAogCiAgICAgICAgIFNQRUNfQ1RSTF9F
TlRSWV9GUk9NX1BWIC8qIFJlcTogJXJzcD1yZWdzL2NwdWluZm8sICVyZHg9
MCwgQ2xvYjogYWNkICovCkBAIC0zODksNyArMzg5LDcgQEAgRU5UUlkoaW50
ODBfZGlyZWN0X3RyYXApCiAgICAgICAgIEVOREJSNjQKICAgICAgICAgQUxU
RVJOQVRJVkUgIiIsIGNsYWMsIFg4Nl9GRUFUVVJFX1hFTl9TTUFQCiAgICAg
ICAgIHB1c2hxICQwCi0gICAgICAgIG1vdmwgICQweDgwLCA0KCVyc3ApCisg
ICAgICAgIG1vdmwgICQweDgwLCBFRlJBTUVfZW50cnlfdmVjdG9yKCVyc3Ap
CiAgICAgICAgIFNBVkVfQUxMCiAKICAgICAgICAgU1BFQ19DVFJMX0VOVFJZ
X0ZST01fUFYgLyogUmVxOiAlcnNwPXJlZ3MvY3B1aW5mbywgJXJkeD0wLCBD
bG9iOiBhY2QgKi8KQEAgLTcwNyw3ICs3MDcsNyBAQCBFTlRSWShjb21tb25f
aW50ZXJydXB0KQogCiBFTlRSWShwYWdlX2ZhdWx0KQogICAgICAgICBFTkRC
UjY0Ci0gICAgICAgIG1vdmwgICRUUkFQX3BhZ2VfZmF1bHQsNCglcnNwKQor
ICAgICAgICBtb3ZsICAkVFJBUF9wYWdlX2ZhdWx0LCBFRlJBTUVfZW50cnlf
dmVjdG9yKCVyc3ApCiAvKiBObyBzcGVjaWFsIHJlZ2lzdGVyIGFzc3VtcHRp
b25zLiAqLwogR0xPQkFMKGhhbmRsZV9leGNlcHRpb24pCiAgICAgICAgIEFM
VEVSTkFUSVZFICIiLCBjbGFjLCBYODZfRkVBVFVSRV9YRU5fU01BUApAQCAt
ODQ5LDkwICs4NDksOTAgQEAgRkFUQUxfZXhjZXB0aW9uX3dpdGhfaW50c19k
aXNhYmxlZDoKIEVOVFJZKGRpdmlkZV9lcnJvcikKICAgICAgICAgRU5EQlI2
NAogICAgICAgICBwdXNocSAkMAotICAgICAgICBtb3ZsICAkVFJBUF9kaXZp
ZGVfZXJyb3IsNCglcnNwKQorICAgICAgICBtb3ZsICAkVFJBUF9kaXZpZGVf
ZXJyb3IsIEVGUkFNRV9lbnRyeV92ZWN0b3IoJXJzcCkKICAgICAgICAgam1w
ICAgaGFuZGxlX2V4Y2VwdGlvbgogCiBFTlRSWShjb3Byb2Nlc3Nvcl9lcnJv
cikKICAgICAgICAgRU5EQlI2NAogICAgICAgICBwdXNocSAkMAotICAgICAg
ICBtb3ZsICAkVFJBUF9jb3Byb19lcnJvciw0KCVyc3ApCisgICAgICAgIG1v
dmwgICRUUkFQX2NvcHJvX2Vycm9yLCBFRlJBTUVfZW50cnlfdmVjdG9yKCVy
c3ApCiAgICAgICAgIGptcCAgIGhhbmRsZV9leGNlcHRpb24KIAogRU5UUlko
c2ltZF9jb3Byb2Nlc3Nvcl9lcnJvcikKICAgICAgICAgRU5EQlI2NAogICAg
ICAgICBwdXNocSAkMAotICAgICAgICBtb3ZsICAkVFJBUF9zaW1kX2Vycm9y
LDQoJXJzcCkKKyAgICAgICAgbW92bCAgJFRSQVBfc2ltZF9lcnJvciwgRUZS
QU1FX2VudHJ5X3ZlY3RvciglcnNwKQogICAgICAgICBqbXAgICBoYW5kbGVf
ZXhjZXB0aW9uCiAKIEVOVFJZKGRldmljZV9ub3RfYXZhaWxhYmxlKQogICAg
ICAgICBFTkRCUjY0CiAgICAgICAgIHB1c2hxICQwCi0gICAgICAgIG1vdmwg
ICRUUkFQX25vX2RldmljZSw0KCVyc3ApCisgICAgICAgIG1vdmwgICRUUkFQ
X25vX2RldmljZSwgRUZSQU1FX2VudHJ5X3ZlY3RvciglcnNwKQogICAgICAg
ICBqbXAgICBoYW5kbGVfZXhjZXB0aW9uCiAKIEVOVFJZKGRlYnVnKQogICAg
ICAgICBFTkRCUjY0CiAgICAgICAgIHB1c2hxICQwCi0gICAgICAgIG1vdmwg
ICRUUkFQX2RlYnVnLDQoJXJzcCkKKyAgICAgICAgbW92bCAgJFRSQVBfZGVi
dWcsIEVGUkFNRV9lbnRyeV92ZWN0b3IoJXJzcCkKICAgICAgICAgam1wICAg
aGFuZGxlX2lzdF9leGNlcHRpb24KIAogRU5UUlkoaW50MykKICAgICAgICAg
RU5EQlI2NAogICAgICAgICBwdXNocSAkMAotICAgICAgICBtb3ZsICAkVFJB
UF9pbnQzLDQoJXJzcCkKKyAgICAgICAgbW92bCAgJFRSQVBfaW50MywgRUZS
QU1FX2VudHJ5X3ZlY3RvciglcnNwKQogICAgICAgICBqbXAgICBoYW5kbGVf
ZXhjZXB0aW9uCiAKIEVOVFJZKG92ZXJmbG93KQogICAgICAgICBFTkRCUjY0
CiAgICAgICAgIHB1c2hxICQwCi0gICAgICAgIG1vdmwgICRUUkFQX292ZXJm
bG93LDQoJXJzcCkKKyAgICAgICAgbW92bCAgJFRSQVBfb3ZlcmZsb3csIEVG
UkFNRV9lbnRyeV92ZWN0b3IoJXJzcCkKICAgICAgICAgam1wICAgaGFuZGxl
X2V4Y2VwdGlvbgogCiBFTlRSWShib3VuZHMpCiAgICAgICAgIEVOREJSNjQK
ICAgICAgICAgcHVzaHEgJDAKLSAgICAgICAgbW92bCAgJFRSQVBfYm91bmRz
LDQoJXJzcCkKKyAgICAgICAgbW92bCAgJFRSQVBfYm91bmRzLCBFRlJBTUVf
ZW50cnlfdmVjdG9yKCVyc3ApCiAgICAgICAgIGptcCAgIGhhbmRsZV9leGNl
cHRpb24KIAogRU5UUlkoaW52YWxpZF9vcCkKICAgICAgICAgRU5EQlI2NAog
ICAgICAgICBwdXNocSAkMAotICAgICAgICBtb3ZsICAkVFJBUF9pbnZhbGlk
X29wLDQoJXJzcCkKKyAgICAgICAgbW92bCAgJFRSQVBfaW52YWxpZF9vcCwg
RUZSQU1FX2VudHJ5X3ZlY3RvciglcnNwKQogICAgICAgICBqbXAgICBoYW5k
bGVfZXhjZXB0aW9uCiAKIEVOVFJZKGludmFsaWRfVFNTKQogICAgICAgICBF
TkRCUjY0Ci0gICAgICAgIG1vdmwgICRUUkFQX2ludmFsaWRfdHNzLDQoJXJz
cCkKKyAgICAgICAgbW92bCAgJFRSQVBfaW52YWxpZF90c3MsIEVGUkFNRV9l
bnRyeV92ZWN0b3IoJXJzcCkKICAgICAgICAgam1wICAgaGFuZGxlX2V4Y2Vw
dGlvbgogCiBFTlRSWShzZWdtZW50X25vdF9wcmVzZW50KQogICAgICAgICBF
TkRCUjY0Ci0gICAgICAgIG1vdmwgICRUUkFQX25vX3NlZ21lbnQsNCglcnNw
KQorICAgICAgICBtb3ZsICAkVFJBUF9ub19zZWdtZW50LCBFRlJBTUVfZW50
cnlfdmVjdG9yKCVyc3ApCiAgICAgICAgIGptcCAgIGhhbmRsZV9leGNlcHRp
b24KIAogRU5UUlkoc3RhY2tfc2VnbWVudCkKICAgICAgICAgRU5EQlI2NAot
ICAgICAgICBtb3ZsICAkVFJBUF9zdGFja19lcnJvciw0KCVyc3ApCisgICAg
ICAgIG1vdmwgICRUUkFQX3N0YWNrX2Vycm9yLCBFRlJBTUVfZW50cnlfdmVj
dG9yKCVyc3ApCiAgICAgICAgIGptcCAgIGhhbmRsZV9leGNlcHRpb24KIAog
RU5UUlkoZ2VuZXJhbF9wcm90ZWN0aW9uKQogICAgICAgICBFTkRCUjY0Ci0g
ICAgICAgIG1vdmwgICRUUkFQX2dwX2ZhdWx0LDQoJXJzcCkKKyAgICAgICAg
bW92bCAgJFRSQVBfZ3BfZmF1bHQsIEVGUkFNRV9lbnRyeV92ZWN0b3IoJXJz
cCkKICAgICAgICAgam1wICAgaGFuZGxlX2V4Y2VwdGlvbgogCiBFTlRSWShh
bGlnbm1lbnRfY2hlY2spCiAgICAgICAgIEVOREJSNjQKLSAgICAgICAgbW92
bCAgJFRSQVBfYWxpZ25tZW50X2NoZWNrLDQoJXJzcCkKKyAgICAgICAgbW92
bCAgJFRSQVBfYWxpZ25tZW50X2NoZWNrLCBFRlJBTUVfZW50cnlfdmVjdG9y
KCVyc3ApCiAgICAgICAgIGptcCAgIGhhbmRsZV9leGNlcHRpb24KIAogRU5U
UlkoZW50cnlfQ1ApCiAgICAgICAgIEVOREJSNjQKLSAgICAgICAgbW92bCAg
JFg4Nl9FWENfQ1AsIDQoJXJzcCkKKyAgICAgICAgbW92bCAgJFg4Nl9FWENf
Q1AsIEVGUkFNRV9lbnRyeV92ZWN0b3IoJXJzcCkKICAgICAgICAgam1wICAg
aGFuZGxlX2V4Y2VwdGlvbgogCiBFTlRSWShkb3VibGVfZmF1bHQpCiAgICAg
ICAgIEVOREJSNjQKLSAgICAgICAgbW92bCAgJFRSQVBfZG91YmxlX2ZhdWx0
LDQoJXJzcCkKKyAgICAgICAgbW92bCAgJFRSQVBfZG91YmxlX2ZhdWx0LCBF
RlJBTUVfZW50cnlfdmVjdG9yKCVyc3ApCiAgICAgICAgIC8qIFNldCBBQyB0
byByZWR1Y2UgY2hhbmNlIG9mIGZ1cnRoZXIgU01BUCBmYXVsdHMgKi8KICAg
ICAgICAgQUxURVJOQVRJVkUgIiIsIHN0YWMsIFg4Nl9GRUFUVVJFX1hFTl9T
TUFQCiAgICAgICAgIFNBVkVfQUxMCkBAIC05NTgsNyArOTU4LDcgQEAgRU5U
UlkoZG91YmxlX2ZhdWx0KQogICAgICAgICAucHVzaHNlY3Rpb24gLmluaXQu
dGV4dCwgImF4IiwgQHByb2diaXRzCiBFTlRSWShlYXJseV9wYWdlX2ZhdWx0
KQogICAgICAgICBFTkRCUjY0Ci0gICAgICAgIG1vdmwgICRUUkFQX3BhZ2Vf
ZmF1bHQsNCglcnNwKQorICAgICAgICBtb3ZsICAkVFJBUF9wYWdlX2ZhdWx0
LCBFRlJBTUVfZW50cnlfdmVjdG9yKCVyc3ApCiAgICAgICAgIFNBVkVfQUxM
CiAgICAgICAgIG1vdnEgICVyc3AsJXJkaQogICAgICAgICBjYWxsICBkb19l
YXJseV9wYWdlX2ZhdWx0CkBAIC05NjgsNyArOTY4LDcgQEAgRU5UUlkoZWFy
bHlfcGFnZV9mYXVsdCkKIEVOVFJZKG5taSkKICAgICAgICAgRU5EQlI2NAog
ICAgICAgICBwdXNocSAkMAotICAgICAgICBtb3ZsICAkVFJBUF9ubWksNCgl
cnNwKQorICAgICAgICBtb3ZsICAkVFJBUF9ubWksIEVGUkFNRV9lbnRyeV92
ZWN0b3IoJXJzcCkKIGhhbmRsZV9pc3RfZXhjZXB0aW9uOgogICAgICAgICBB
TFRFUk5BVElWRSAiIiwgY2xhYywgWDg2X0ZFQVRVUkVfWEVOX1NNQVAKICAg
ICAgICAgU0FWRV9BTEwKQEAgLTEwNzUsNyArMTA3NSw3IEBAIGhhbmRsZV9p
c3RfZXhjZXB0aW9uOgogRU5UUlkobWFjaGluZV9jaGVjaykKICAgICAgICAg
RU5EQlI2NAogICAgICAgICBwdXNocSAkMAotICAgICAgICBtb3ZsICAkVFJB
UF9tYWNoaW5lX2NoZWNrLDQoJXJzcCkKKyAgICAgICAgbW92bCAgJFRSQVBf
bWFjaGluZV9jaGVjaywgRUZSQU1FX2VudHJ5X3ZlY3RvciglcnNwKQogICAg
ICAgICBqbXAgICBoYW5kbGVfaXN0X2V4Y2VwdGlvbgogCiAvKiBObyBvcCB0
cmFwIGhhbmRsZXIuICBSZXF1aXJlZCBmb3Iga2V4ZWMgY3Jhc2ggcGF0aC4g
Ki8KQEAgLTExMTIsNyArMTExMiw3IEBAIGF1dG9nZW5fc3R1YnM6IC8qIEF1
dG9tYXRpY2FsbHkgZ2VuZXJhdGVkIHN0dWJzLiAqLwogMToKICAgICAgICAg
RU5EQlI2NAogICAgICAgICBwdXNocSAkMAotICAgICAgICBtb3ZiICAkdmVj
LDQoJXJzcCkKKyAgICAgICAgbW92YiAgJHZlYywgRUZSQU1FX2VudHJ5X3Zl
Y3RvciglcnNwKQogICAgICAgICBqbXAgICBjb21tb25faW50ZXJydXB0CiAK
ICAgICAgICAgZW50cnlwb2ludCAxYgpAQCAtMTEyNiw3ICsxMTI2LDcgQEAg
YXV0b2dlbl9zdHViczogLyogQXV0b21hdGljYWxseSBnZW5lcmF0ZWQgc3R1
YnMuICovCiAgICAgICAgIHRlc3QgICQ4LCVzcGwgICAgICAgIC8qIDY0Yml0
IGV4Y2VwdGlvbiBmcmFtZXMgYXJlIDE2IGJ5dGUgYWxpZ25lZCwgYnV0IHRo
ZSB3b3JkICovCiAgICAgICAgIGp6ICAgIDJmICAgICAgICAgICAgIC8qIHNp
emUgaXMgOCBieXRlcy4gIENoZWNrIHdoZXRoZXIgdGhlIHByb2Nlc3NvciBn
YXZlIHVzIGFuICovCiAgICAgICAgIHB1c2hxICQwICAgICAgICAgICAgIC8q
IGVycm9yIGNvZGUsIGFuZCBpbnNlcnQgYW4gZW1wdHkgb25lIGlmIG5vdC4g
ICAgICAgICAgICAgICovCi0yOiAgICAgIG1vdmIgICR2ZWMsNCglcnNwKQor
MjogICAgICBtb3ZiICAkdmVjLCBFRlJBTUVfZW50cnlfdmVjdG9yKCVyc3Ap
CiAgICAgICAgIGptcCAgIGhhbmRsZV9leGNlcHRpb24KIAogICAgICAgICBl
bnRyeXBvaW50IDFiCg==

--=separator
Content-Type: application/octet-stream; name="xsa452/xsa452-4.16-2.patch"
Content-Disposition: attachment; filename="xsa452/xsa452-4.16-2.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L2NwdS1wb2xpY3k6IEFsbG93IGZvciBsZXZlbGxp
bmcgb2YgVkVSVyBzaWRlIGVmZmVjdHMKCk1EX0NMRUFSIGFuZCBGQl9DTEVB
UiBuZWVkIE9SLWluZyBhY3Jvc3MgYSBtaWdyYXRlIHBvb2wuICBBbGxvdyB0
aGlzLCBieQpoYXZpbmcgdGhlbSB1bmNvbmRpdGluYWxseSBzZXQgaW4gbWF4
LCB3aXRoIHRoZSBob3N0IHZhbHVlcyByZWZsZWN0ZWQgaW4KZGVmYXVsdC4g
IEFubm90YXRlIHRoZSBiaXRzIGFzIGhhdmluZyBzcGVjaWFsIHByb3Blcmll
cy4KClNpZ25lZC1vZmYtYnk6IEFuZHJldyBDb29wZXIgPGFuZHJldy5jb29w
ZXIzQGNpdHJpeC5jb20+ClJldmlld2VkLWJ5OiBSb2dlciBQYXUgTW9ubsOp
IDxyb2dlci5wYXVAY2l0cml4LmNvbT4KKGNoZXJyeSBwaWNrZWQgZnJvbSBj
b21taXQgZGUxNzE2MmNhZmQyN2YyODY1YTMxMDJhMmVjMGYzODZhMDJlZDAz
ZCkKCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYvY3B1LXBvbGljeS5jIGIv
eGVuL2FyY2gveDg2L2NwdS1wb2xpY3kuYwppbmRleCBmMzgwNjNiNjY3YjAu
LjM0Zjc3OGRiYWZiYiAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2NwdS1w
b2xpY3kuYworKysgYi94ZW4vYXJjaC94ODYvY3B1LXBvbGljeS5jCkBAIC00
MzQsNiArNDM0LDE2IEBAIHN0YXRpYyB2b2lkIF9faW5pdCBndWVzdF9jb21t
b25fbWF4X2ZlYXR1cmVfYWRqdXN0bWVudHModWludDMyX3QgKmZzKQogICAg
ICAgICBfX3NldF9iaXQoWDg2X0ZFQVRVUkVfUlNCQSwgZnMpOwogICAgICAg
ICBfX3NldF9iaXQoWDg2X0ZFQVRVUkVfUlJTQkEsIGZzKTsKIAorICAgICAg
ICAvKgorICAgICAgICAgKiBUaGVzZSBiaXRzIGluZGljYXRlIHRoYXQgdGhl
IFZFUlcgaW5zdHJ1Y3Rpb24gbWF5IGhhdmUgZ2FpbmVkCisgICAgICAgICAq
IHNjcnViYmluZyBzaWRlIGVmZmVjdHMuICBXaXRoIHBvb2xpbmcsIHRoZXkg
bWVhbiAieW91IG1pZ2h0IG1pZ3JhdGUKKyAgICAgICAgICogc29tZXdoZXJl
IHdoZXJlIHNjcnViYmluZyBpcyBuZWNlc3NhcnkiLCBhbmQgbWF5IG5lZWQg
ZXhwb3Npbmcgb24KKyAgICAgICAgICogdW5hZmZlY3RlZCBoYXJkd2FyZS4g
IFRoaXMgaXMgZmluZSwgYmVjYXVzZSB0aGUgVkVSVyBpbnN0cnVjdGlvbgor
ICAgICAgICAgKiBoYXMgYmVlbiBhcm91bmQgc2luY2UgdGhlIDI4Ni4KKyAg
ICAgICAgICovCisgICAgICAgIF9fc2V0X2JpdChYODZfRkVBVFVSRV9NRF9D
TEVBUiwgZnMpOworICAgICAgICBfX3NldF9iaXQoWDg2X0ZFQVRVUkVfRkJf
Q0xFQVIsIGZzKTsKKwogICAgICAgICAvKgogICAgICAgICAgKiBUaGUgR2F0
aGVyIERhdGEgU2FtcGxpbmcgbWljcm9jb2RlIG1pdGlnYXRpb24gKEF1Z3Vz
dCAyMDIzKSBoYXMgYW4KICAgICAgICAgICogYWR2ZXJzZSBwZXJmb3JtYW5j
ZSBpbXBhY3Qgb24gdGhlIENMV0IgaW5zdHJ1Y3Rpb24gb24gU0tYL0NMWC9D
UFguCkBAIC00NjgsNiArNDc4LDIwIEBAIHN0YXRpYyB2b2lkIF9faW5pdCBn
dWVzdF9jb21tb25fZGVmYXVsdF9mZWF0dXJlX2FkanVzdG1lbnRzKHVpbnQz
Ml90ICpmcykKICAgICAgICAgICAgICBjcHVfaGFzX3JkcmFuZCAmJiAhaXNf
Zm9yY2VkX2NwdV9jYXAoWDg2X0ZFQVRVUkVfUkRSQU5EKSApCiAgICAgICAg
ICAgICBfX2NsZWFyX2JpdChYODZfRkVBVFVSRV9SRFJBTkQsIGZzKTsKIAor
ICAgICAgICAvKgorICAgICAgICAgKiBUaGVzZSBiaXRzIGluZGljYXRlIHRo
YXQgdGhlIFZFUlcgaW5zdHJ1Y3Rpb24gbWF5IGhhdmUgZ2FpbmVkCisgICAg
ICAgICAqIHNjcnViYmluZyBzaWRlIGVmZmVjdHMuICBUaGUgbWF4IHBvbGlj
eSBoYXMgdGhlbSBzZXQgZm9yIG1pZ3JhdGlvbgorICAgICAgICAgKiByZWFz
b25zLCBzbyByZXNldCB0aGUgZGVmYXVsdCBwb2xpY3kgYmFjayB0byB0aGUg
aG9zdCB2YWx1ZXMgaW4KKyAgICAgICAgICogY2FzZSB3ZSdyZSB1bmFmZmVj
dGVkLgorICAgICAgICAgKi8KKyAgICAgICAgX19jbGVhcl9iaXQoWDg2X0ZF
QVRVUkVfTURfQ0xFQVIsIGZzKTsKKyAgICAgICAgaWYgKCBjcHVfaGFzX21k
X2NsZWFyICkKKyAgICAgICAgICAgIF9fc2V0X2JpdChYODZfRkVBVFVSRV9N
RF9DTEVBUiwgZnMpOworCisgICAgICAgIF9fY2xlYXJfYml0KFg4Nl9GRUFU
VVJFX0ZCX0NMRUFSLCBmcyk7CisgICAgICAgIGlmICggY3B1X2hhc19mYl9j
bGVhciApCisgICAgICAgICAgICBfX3NldF9iaXQoWDg2X0ZFQVRVUkVfRkJf
Q0xFQVIsIGZzKTsKKwogICAgICAgICAvKgogICAgICAgICAgKiBUaGUgR2F0
aGVyIERhdGEgU2FtcGxpbmcgbWljcm9jb2RlIG1pdGlnYXRpb24gKEF1Z3Vz
dCAyMDIzKSBoYXMgYW4KICAgICAgICAgICogYWR2ZXJzZSBwZXJmb3JtYW5j
ZSBpbXBhY3Qgb24gdGhlIENMV0IgaW5zdHJ1Y3Rpb24gb24gU0tYL0NMWC9D
UFguCmRpZmYgLS1naXQgYS94ZW4vaW5jbHVkZS9hc20teDg2L2NwdWZlYXR1
cmUuaCBiL3hlbi9pbmNsdWRlL2FzbS14ODYvY3B1ZmVhdHVyZS5oCmluZGV4
IDFhYzNkM2ExZjk0Ni4uODFhYzRkNzZlZWE2IDEwMDY0NAotLS0gYS94ZW4v
aW5jbHVkZS9hc20teDg2L2NwdWZlYXR1cmUuaAorKysgYi94ZW4vaW5jbHVk
ZS9hc20teDg2L2NwdWZlYXR1cmUuaApAQCAtMTM0LDYgKzEzNCw3IEBACiAj
ZGVmaW5lIGNwdV9oYXNfYXZ4NTEyXzRmbWFwcyAgIGJvb3RfY3B1X2hhcyhY
ODZfRkVBVFVSRV9BVlg1MTJfNEZNQVBTKQogI2RlZmluZSBjcHVfaGFzX2F2
eDUxMl92cDJpbnRlcnNlY3QgYm9vdF9jcHVfaGFzKFg4Nl9GRUFUVVJFX0FW
WDUxMl9WUDJJTlRFUlNFQ1QpCiAjZGVmaW5lIGNwdV9oYXNfc3JiZHNfY3Ry
bCAgICAgIGJvb3RfY3B1X2hhcyhYODZfRkVBVFVSRV9TUkJEU19DVFJMKQor
I2RlZmluZSBjcHVfaGFzX21kX2NsZWFyICAgICAgICBib290X2NwdV9oYXMo
WDg2X0ZFQVRVUkVfTURfQ0xFQVIpCiAjZGVmaW5lIGNwdV9oYXNfcnRtX2Fs
d2F5c19hYm9ydCBib290X2NwdV9oYXMoWDg2X0ZFQVRVUkVfUlRNX0FMV0FZ
U19BQk9SVCkKICNkZWZpbmUgY3B1X2hhc190c3hfZm9yY2VfYWJvcnQgYm9v
dF9jcHVfaGFzKFg4Nl9GRUFUVVJFX1RTWF9GT1JDRV9BQk9SVCkKICNkZWZp
bmUgY3B1X2hhc19zZXJpYWxpemUgICAgICAgYm9vdF9jcHVfaGFzKFg4Nl9G
RUFUVVJFX1NFUklBTElaRSkKZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL3B1
YmxpYy9hcmNoLXg4Ni9jcHVmZWF0dXJlc2V0LmggYi94ZW4vaW5jbHVkZS9w
dWJsaWMvYXJjaC14ODYvY3B1ZmVhdHVyZXNldC5oCmluZGV4IDBlZTFkMWQ5
MDMzMC4uMjkwNmVhYTZjMjkwIDEwMDY0NAotLS0gYS94ZW4vaW5jbHVkZS9w
dWJsaWMvYXJjaC14ODYvY3B1ZmVhdHVyZXNldC5oCisrKyBiL3hlbi9pbmNs
dWRlL3B1YmxpYy9hcmNoLXg4Ni9jcHVmZWF0dXJlc2V0LmgKQEAgLTI3NSw3
ICsyNzUsNyBAQCBYRU5fQ1BVRkVBVFVSRShBVlg1MTJfNEZNQVBTLCA5KjMy
KyAzKSAvKkEgIEFWWDUxMiBNdWx0aXBseSBBY2N1bXVsYXRpb24gU2luZ2xl
CiBYRU5fQ1BVRkVBVFVSRShGU1JNLCAgICAgICAgICA5KjMyKyA0KSAvKkEg
IEZhc3QgU2hvcnQgUkVQIE1PVlMgKi8KIFhFTl9DUFVGRUFUVVJFKEFWWDUx
Ml9WUDJJTlRFUlNFQ1QsIDkqMzIrOCkgLyphICBWUDJJTlRFUlNFQ1R7RCxR
fSBpbnNucyAqLwogWEVOX0NQVUZFQVRVUkUoU1JCRFNfQ1RSTCwgICAgOSoz
MisgOSkgLyogICBNU1JfTUNVX09QVF9DVFJMIGFuZCBSTkdEU19NSVRHX0RJ
Uy4gKi8KLVhFTl9DUFVGRUFUVVJFKE1EX0NMRUFSLCAgICAgIDkqMzIrMTAp
IC8qQSAgVkVSVyBjbGVhcnMgbWljcm9hcmNoaXRlY3R1cmFsIGJ1ZmZlcnMg
Ki8KK1hFTl9DUFVGRUFUVVJFKE1EX0NMRUFSLCAgICAgIDkqMzIrMTApIC8q
IUEgVkVSVyBjbGVhcnMgbWljcm9hcmNoaXRlY3R1cmFsIGJ1ZmZlcnMgKi8K
IFhFTl9DUFVGRUFUVVJFKFJUTV9BTFdBWVNfQUJPUlQsIDkqMzIrMTEpIC8q
ISBKdW5lIDIwMjEgVFNYIGRlZmVhdHVyaW5nIGluIG1pY3JvY29kZS4gKi8K
IFhFTl9DUFVGRUFUVVJFKFRTWF9GT1JDRV9BQk9SVCwgOSozMisxMykgLyog
TVNSX1RTWF9GT1JDRV9BQk9SVC5SVE1fQUJPUlQgKi8KIFhFTl9DUFVGRUFU
VVJFKFNFUklBTElaRSwgICAgIDkqMzIrMTQpIC8qYSAgU0VSSUFMSVpFIGlu
c24gKi8KQEAgLTMyOSw3ICszMjksNyBAQCBYRU5fQ1BVRkVBVFVSRShET0lU
TSwgICAgICAgICAgICAgIDE2KjMyKzEyKSAvKiAgIERhdGEgT3BlcmFuZCBJ
bnZhcmlhbnQgVGltaW5nCiBYRU5fQ1BVRkVBVFVSRShTQkRSX1NTRFBfTk8s
ICAgICAgIDE2KjMyKzEzKSAvKkEgIE5vIFNoYXJlZCBCdWZmZXIgRGF0YSBS
ZWFkIG9yIFNpZGViYW5kIFN0YWxlIERhdGEgUHJvcGFnYXRpb24gKi8KIFhF
Tl9DUFVGRUFUVVJFKEZCU0RQX05PLCAgICAgICAgICAgMTYqMzIrMTQpIC8q
QSAgTm8gRmlsbCBCdWZmZXIgU3RhbGUgRGF0YSBQcm9wYWdhdGlvbiAqLwog
WEVOX0NQVUZFQVRVUkUoUFNEUF9OTywgICAgICAgICAgICAxNiozMisxNSkg
LypBICBObyBQcmltYXJ5IFN0YWxlIERhdGEgUHJvcGFnYXRpb24gKi8KLVhF
Tl9DUFVGRUFUVVJFKEZCX0NMRUFSLCAgICAgICAgICAgMTYqMzIrMTcpIC8q
QSAgRmlsbCBCdWZmZXJzIGNsZWFyZWQgYnkgVkVSVyAqLworWEVOX0NQVUZF
QVRVUkUoRkJfQ0xFQVIsICAgICAgICAgICAxNiozMisxNykgLyohQSBGaWxs
IEJ1ZmZlcnMgY2xlYXJlZCBieSBWRVJXICovCiBYRU5fQ1BVRkVBVFVSRShG
Ql9DTEVBUl9DVFJMLCAgICAgIDE2KjMyKzE4KSAvKiAgIE1TUl9PUFRfQ1BV
X0NUUkwuRkJfQ0xFQVJfRElTICovCiBYRU5fQ1BVRkVBVFVSRShSUlNCQSwg
ICAgICAgICAgICAgIDE2KjMyKzE5KSAvKiEgIFJlc3RyaWN0ZWQgUlNCIEFs
dGVybmF0aXZlICovCiBYRU5fQ1BVRkVBVFVSRShCSElfTk8sICAgICAgICAg
ICAgIDE2KjMyKzIwKSAvKkEgIE5vIEJyYW5jaCBIaXN0b3J5IEluamVjdGlv
biAgKi8K

--=separator
Content-Type: application/octet-stream; name="xsa452/xsa452-4.16-3.patch"
Content-Disposition: attachment; filename="xsa452/xsa452-4.16-3.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L3ZteDogUGVyZm9ybSBWRVJXIGZsdXNoaW5nIGxh
dGVyIGluIHRoZSBWTUV4aXQgcGF0aAoKQnJva2VuIG91dCBvZiB0aGUgZm9s
bG93aW5nIHBhdGNoIGJlY2F1c2UgdGhpcyBjaGFuZ2UgaXMgc3VidGxlIGVu
b3VnaCBvbiBpdHMKb3duLiAgU2VlIGl0IGZvciB0aGUgcmF0aW9uYWwgb2Yg
d2h5IHdlJ3JlIG1vdmluZyBWRVJXLgoKQXMgZm9yIGhvdywgZXh0ZW5kIHRo
ZSB0cmljayBhbHJlYWR5IHVzZWQgdG8gaG9sZCBvbmUgY29uZGl0aW9uIGlu
CmZsYWdzIChSRVNVTUUgdnMgTEFVTkNIKSB0aHJvdWdoIHRoZSBQT1Bpbmcg
b2YgR1BScy4KCk1vdmUgdGhlIE1PViBDUiBlYXJsaWVyLiAgSW50ZWwgc3Bl
Y2lmeSBmbGFncyB0byBiZSB1bmRlZmluZWQgYWNyb3NzIGl0LgoKRW5jb2Rl
IHRoZSB0d28gY29uZGl0aW9ucyB3ZSB3YW50IHVzaW5nIFNGIGFuZCBQRi4g
IFNlZSB0aGUgY29kZSBjb21tZW50IGZvcgpleGFjdGx5IGhvdy4KCkxlYXZl
IGEgY29tbWVudCB0byBleHBsYWluIHRoZSBsYWNrIG9mIGFueSBjb250ZW50
IGFyb3VuZApTUEVDX0NUUkxfRVhJVF9UT19WTVgsIGJ1dCBsZWF2ZSB0aGUg
YmxvY2sgaW4gcGxhY2UuICBTb2RzIGxhdyBzYXlzIGlmIHdlCmRlbGV0ZSBp
dCwgd2UnbGwgbmVlZCB0byByZWludHJvZHVjZSBpdC4KClRoaXMgaXMgcGFy
dCBvZiBYU0EtNDUyIC8gQ1ZFLTIwMjMtMjg3NDYuCgpTaWduZWQtb2ZmLWJ5
OiBBbmRyZXcgQ29vcGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPgpS
ZXZpZXdlZC1ieTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgoo
Y2hlcnJ5IHBpY2tlZCBmcm9tIGNvbW1pdCA0NzVmYTIwYjczODQ0NjQyMTBm
NDJiYWQ3MTk1Zjg3YmQ2ZjFjNjNmKQoKZGlmZiAtLWdpdCBhL3hlbi9hcmNo
L3g4Ni9odm0vdm14L2VudHJ5LlMgYi94ZW4vYXJjaC94ODYvaHZtL3ZteC9l
bnRyeS5TCmluZGV4IDVmNWRlNDVhMTMwOS4uY2RkZTc2ZTEzODkyIDEwMDY0
NAotLS0gYS94ZW4vYXJjaC94ODYvaHZtL3ZteC9lbnRyeS5TCisrKyBiL3hl
bi9hcmNoL3g4Ni9odm0vdm14L2VudHJ5LlMKQEAgLTg3LDE3ICs4NywzOSBA
QCBVTkxJS0VMWV9FTkQocmVhbG1vZGUpCiAKICAgICAgICAgLyogV0FSTklO
RyEgYHJldGAsIGBjYWxsICpgLCBgam1wICpgIG5vdCBzYWZlIGJleW9uZCB0
aGlzIHBvaW50LiAqLwogICAgICAgICAvKiBTUEVDX0NUUkxfRVhJVF9UT19W
TVggICBSZXE6ICVyc3A9cmVncy9jcHVpbmZvICAgICAgICAgICAgICBDbG9i
OiAgICAqLwotICAgICAgICBET19TUEVDX0NUUkxfQ09ORF9WRVJXCisgICAg
ICAgIC8qCisgICAgICAgICAqIEFsbCBzcGVjdWxhdGlvbiBzYWZldHkgd29y
ayBoYXBwZW5zIHRvIGJlIGVsc2V3aGVyZS4gIFZFUlcgaXMgYWZ0ZXIKKyAg
ICAgICAgICogcG9wcGluZyB0aGUgR1BScywgd2hpbGUgcmVzdG9yaW5nIHRo
ZSBndWVzdCBNU1JfU1BFQ19DVFJMIGlzIGxlZnQKKyAgICAgICAgICogdG8g
dGhlIE1TUiBsb2FkIGxpc3QuCisgICAgICAgICAqLwogCiAgICAgICAgIG1v
diAgVkNQVV9odm1fZ3Vlc3RfY3IyKCVyYngpLCVyYXgKKyAgICAgICAgbW92
ICAlcmF4LCAlY3IyCisKKyAgICAgICAgLyoKKyAgICAgICAgICogV2UgbmVl
ZCB0byBwZXJmb3JtIHR3byBjb25kaXRpb25hbCBhY3Rpb25zIChWRVJXLCBh
bmQgUmVzdW1lIHZzCisgICAgICAgICAqIExhdW5jaCkgYWZ0ZXIgcG9wcGlu
ZyBHUFJzLiAgV2l0aCBzb21lIGN1bm5pbmcsIHdlIGNhbiBlbmNvZGUgYm90
aAorICAgICAgICAgKiBvZiB0aGVzZSBpbiBlZmxhZ3MgdG9nZXRoZXIuCisg
ICAgICAgICAqCisgICAgICAgICAqIFBhcml0eSBpcyBvbmx5IGNhbGN1bGF0
ZWQgb3ZlciB0aGUgYm90dG9tIGJ5dGUgb2YgdGhlIGFuc3dlciwgd2hpbGUK
KyAgICAgICAgICogU2lnbiBpcyBzaW1wbHkgdGhlIHRvcCBiaXQuCisgICAg
ICAgICAqCisgICAgICAgICAqIFRoZXJlZm9yZSwgdGhlIGZpbmFsIE9SIGlu
c3RydWN0aW9uIGVuZHMgdXAgcHJvZHVjaW5nOgorICAgICAgICAgKiAgIFNG
ID0gVkNQVV92bXhfbGF1bmNoZWQKKyAgICAgICAgICogICBQRiA9ICFTQ0Zf
dmVydworICAgICAgICAgKi8KKyAgICAgICAgQlVJTERfQlVHX09OKFNDRl92
ZXJ3ICYgfjB4ZmYpCisgICAgICAgIG1vdnpibCBWQ1BVX3ZteF9sYXVuY2hl
ZCglcmJ4KSwgJWVjeAorICAgICAgICBzaGwgICQzMSwgJWVjeAorICAgICAg
ICBtb3Z6YmwgQ1BVSU5GT19zcGVjX2N0cmxfZmxhZ3MoJXJzcCksICVlYXgK
KyAgICAgICAgYW5kICAkU0NGX3ZlcncsICVlYXgKKyAgICAgICAgb3IgICAl
ZWF4LCAlZWN4CiAKICAgICAgICAgcG9wICAlcjE1CiAgICAgICAgIHBvcCAg
JXIxNAogICAgICAgICBwb3AgICVyMTMKICAgICAgICAgcG9wICAlcjEyCiAg
ICAgICAgIHBvcCAgJXJicAotICAgICAgICBtb3YgICVyYXgsJWNyMgotICAg
ICAgICBjbXBiICQwLFZDUFVfdm14X2xhdW5jaGVkKCVyYngpCiAgICAgICAg
IHBvcCAgJXJieAogICAgICAgICBwb3AgICVyMTEKICAgICAgICAgcG9wICAl
cjEwCkBAIC0xMDgsNyArMTMwLDEzIEBAIFVOTElLRUxZX0VORChyZWFsbW9k
ZSkKICAgICAgICAgcG9wICAlcmR4CiAgICAgICAgIHBvcCAgJXJzaQogICAg
ICAgICBwb3AgICVyZGkKLSAgICAgICAgamUgICAuTHZteF9sYXVuY2gKKwor
ICAgICAgICBqcGUgIC5MX3NraXBfdmVydworICAgICAgICAvKiBWRVJXIGNs
b2JiZXJzIFpGLCBidXQgcHJlc2VydmVzIGFsbCBvdGhlcnMsIGluY2x1ZGlu
ZyBTRi4gKi8KKyAgICAgICAgdmVydyBTVEtfUkVMKENQVUlORk9fdmVyd19z
ZWwsIENQVUlORk9fZXJyb3JfY29kZSkoJXJzcCkKKy5MX3NraXBfdmVydzoK
KworICAgICAgICBqbnMgIC5Mdm14X2xhdW5jaAogCiAvKi5Mdm14X3Jlc3Vt
ZToqLwogICAgICAgICBWTVJFU1VNRQpkaWZmIC0tZ2l0IGEveGVuL2FyY2gv
eDg2L3g4Nl82NC9hc20tb2Zmc2V0cy5jIGIveGVuL2FyY2gveDg2L3g4Nl82
NC9hc20tb2Zmc2V0cy5jCmluZGV4IDMxZmE2M2I3N2ZkMS4uYTRlOTRkNjkz
MDI0IDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYveDg2XzY0L2FzbS1vZmZz
ZXRzLmMKKysrIGIveGVuL2FyY2gveDg2L3g4Nl82NC9hc20tb2Zmc2V0cy5j
CkBAIC0xMzUsNiArMTM1LDcgQEAgdm9pZCBfX2R1bW15X18odm9pZCkKICNl
bmRpZgogCiAgICAgT0ZGU0VUKENQVUlORk9fZ3Vlc3RfY3B1X3VzZXJfcmVn
cywgc3RydWN0IGNwdV9pbmZvLCBndWVzdF9jcHVfdXNlcl9yZWdzKTsKKyAg
ICBPRkZTRVQoQ1BVSU5GT19lcnJvcl9jb2RlLCBzdHJ1Y3QgY3B1X2luZm8s
IGd1ZXN0X2NwdV91c2VyX3JlZ3MuZXJyb3JfY29kZSk7CiAgICAgT0ZGU0VU
KENQVUlORk9fdmVyd19zZWwsIHN0cnVjdCBjcHVfaW5mbywgdmVyd19zZWwp
OwogICAgIE9GRlNFVChDUFVJTkZPX2N1cnJlbnRfdmNwdSwgc3RydWN0IGNw
dV9pbmZvLCBjdXJyZW50X3ZjcHUpOwogICAgIE9GRlNFVChDUFVJTkZPX3Bl
cl9jcHVfb2Zmc2V0LCBzdHJ1Y3QgY3B1X2luZm8sIHBlcl9jcHVfb2Zmc2V0
KTsKZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL2FzbS14ODYvYXNtX2RlZm5z
LmggYi94ZW4vaW5jbHVkZS9hc20teDg2L2FzbV9kZWZucy5oCmluZGV4IGQ5
NDMxMTgwY2ZiYS4uYWJjNjgyMmIwOGM4IDEwMDY0NAotLS0gYS94ZW4vaW5j
bHVkZS9hc20teDg2L2FzbV9kZWZucy5oCisrKyBiL3hlbi9pbmNsdWRlL2Fz
bS14ODYvYXNtX2RlZm5zLmgKQEAgLTgxLDYgKzgxLDE0IEBAIHJlZ2lzdGVy
IHVuc2lnbmVkIGxvbmcgY3VycmVudF9zdGFja19wb2ludGVyIGFzbSgicnNw
Iik7CiAKICNpZmRlZiBfX0FTU0VNQkxZX18KIAorLm1hY3JvIEJVSUxEX0JV
R19PTiBjb25kc3RyLCBjb25kOnZhcmFyZworICAgICAgICAuaWYgXGNvbmQK
KyAgICAgICAgLmVycm9yICJDb25kaXRpb24gXCJcY29uZHN0clwiIG5vdCBz
YXRpc2ZpZWQiCisgICAgICAgIC5lbmRpZgorLmVuZG0KKy8qIHByZXByb2Nl
c3NvciBtYWNybyB0byBtYWtlIGVycm9yIG1lc3NhZ2UgbW9yZSB1c2VyIGZy
aWVuZGx5ICovCisjZGVmaW5lIEJVSUxEX0JVR19PTihjb25kKSBCVUlMRF9C
VUdfT04gI2NvbmQsIGNvbmQKKwogI2lmZGVmIEhBVkVfQVNfUVVPVEVEX1NZ
TQogI2RlZmluZSBTVUJTRUNUSU9OX0xCTCh0YWcpICAgICAgICAgICAgICAg
ICAgICAgICAgXAogICAgICAgICAuaWZuZGVmIC5MLnRhZzsgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgXApkaWZmIC0tZ2l0IGEveGVuL2luY2x1ZGUv
YXNtLXg4Ni9zcGVjX2N0cmxfYXNtLmggYi94ZW4vaW5jbHVkZS9hc20teDg2
L3NwZWNfY3RybF9hc20uaAppbmRleCAwZTY5OTcxZjY2M2YuLmU4MDdmZjZk
MWRiMiAxMDA2NDQKLS0tIGEveGVuL2luY2x1ZGUvYXNtLXg4Ni9zcGVjX2N0
cmxfYXNtLmgKKysrIGIveGVuL2luY2x1ZGUvYXNtLXg4Ni9zcGVjX2N0cmxf
YXNtLmgKQEAgLTE2OSw2ICsxNjksMTMgQEAKICNlbmRpZgogLmVuZG0KIAor
LyoKKyAqIEhlbHBlciB0byBpbXByb3ZlIHRoZSByZWFkaWJpbGl0eSBvZiBz
dGFjayBkaXNwYWNlbWVudHMgd2l0aCAlcnNwIGluCisgKiB1bnVzdWFsIHBv
c2l0aW9ucy4gIEJvdGggQGZpZWxkIGFuZCBAdG9wX29mX3N0YWNrIHNob3Vs
ZCBiZSBjb25zdGFudHMgZnJvbQorICogdGhlIHNhbWUgb2JqZWN0LiAgQHRv
cF9vZl9zdGFjayBzaG91bGQgYmUgd2hlcmUgJXJzcCBpcyBjdXJyZW50bHkg
cG9pbnRpbmcuCisgKi8KKyNkZWZpbmUgU1RLX1JFTChmaWVsZCwgdG9wX29m
X3N0aykgKChmaWVsZCkgLSAodG9wX29mX3N0aykpCisKIC5tYWNybyBET19T
UEVDX0NUUkxfQ09ORF9WRVJXCiAvKgogICogUmVxdWlyZXMgJXJzcD1jcHVp
bmZvCg==

--=separator
Content-Type: application/octet-stream; name="xsa452/xsa452-4.16-4.patch"
Content-Disposition: attachment; filename="xsa452/xsa452-4.16-4.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L3NwZWMtY3RybDogUGVyZm9ybSBWRVJXIGZsdXNo
aW5nIGxhdGVyIGluIGV4aXQgcGF0aHMKCk9uIHBhcnRzIHZ1bG5lcmFibGUg
dG8gUkZEUywgVkVSVydzIHNpZGUgZWZmZWN0cyBhcmUgZXh0ZW5kZWQgdG8g
c2NydWIgYWxsCm5vbi1hcmNoaXRlY3R1cmFsIGVudHJpZXMgaW4gdmFyaW91
cyBQaHlzaWNhbCBSZWdpc3RlciBGaWxlcy4gIFRvIHJlbW92ZSBhbGwKb2Yg
WGVuJ3MgdmFsdWVzLCB0aGUgVkVSVyBtdXN0IGJlIGFmdGVyIHBvcHBpbmcg
dGhlIEdQUnMuCgpSZXdvcmsgU1BFQ19DVFJMX0NPTkRfVkVSVyB0byBkZWZh
dWx0IHRvIGFuIENQVUlORk9fZXJyb3JfY29kZSAlcnNwIHBvc2l0aW9uLApi
dXQgd2l0aCBvdmVycmlkZXMgZm9yIG90aGVyIGNvbnRleHRzLiAgSWRlbnRp
ZnkgdGhhdCBpdCBjbG9iYmVycyBlZmxhZ3M7IHRoaXMKaXMgcGFydGljdWxh
cmx5IHJlbGV2YW50IGZvciB0aGUgU1lTUkVUIHBhdGguCgpGb3IgdGhlIElT
VCBleGl0IHJldHVybiB0byBYZW4sIGhhdmUgdGhlIG1haW4gU1BFQ19DVFJM
X0VYSVRfVE9fWEVOIHB1dCBhCnNoYWRvdyBjb3B5IG9mIHNwZWNfY3RybF9m
bGFncywgYXMgR1BScyBjYW4ndCBiZSB1c2VkIGF0IHRoZSBwb2ludCB3ZSB3
YW50IHRvCmlzc3VlIHRoZSBWRVJXLgoKVGhpcyBpcyBwYXJ0IG9mIFhTQS00
NTIgLyBDVkUtMjAyMy0yODc0Ni4KClNpZ25lZC1vZmYtYnk6IEFuZHJldyBD
b29wZXIgPGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+ClJldmlld2VkLWJ5
OiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+CihjaGVycnkgcGlj
a2VkIGZyb20gY29tbWl0IDBhNjY2Y2YyY2Q5OWRmNmZhZjNlZWJjODFhMWZj
Mjg2ZTRlY2E0YzcpCgpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L3g4Nl82
NC9hc20tb2Zmc2V0cy5jIGIveGVuL2FyY2gveDg2L3g4Nl82NC9hc20tb2Zm
c2V0cy5jCmluZGV4IGE0ZTk0ZDY5MzAyNC4uNGNkNTkzOGQ3YjlkIDEwMDY0
NAotLS0gYS94ZW4vYXJjaC94ODYveDg2XzY0L2FzbS1vZmZzZXRzLmMKKysr
IGIveGVuL2FyY2gveDg2L3g4Nl82NC9hc20tb2Zmc2V0cy5jCkBAIC01NSwx
NCArNTUsMjIgQEAgdm9pZCBfX2R1bW15X18odm9pZCkKICAgICAgKiBFRlJB
TUVfKiBpcyBmb3IgdGhlIGVudHJ5L2V4aXQgbG9naWMgd2hlcmUgJXJzcCBp
cyBwb2ludGluZyBhdAogICAgICAqIFVSRUdTX2Vycm9yX2NvZGUgYW5kIEdQ
UnMgYXJlIHN0aWxsL2FscmVhZHkgZ3Vlc3QgdmFsdWVzLgogICAgICAqLwot
I2RlZmluZSBPRkZTRVRfRUYoc3ltLCBtZW0pICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgXAorI2RlZmluZSBPRkZTRVRf
RUYoc3ltLCBtZW0sIC4uLikgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgXAogICAgIERFRklORShzeW0sIG9mZnNldG9mKHN0cnVj
dCBjcHVfdXNlcl9yZWdzLCBtZW0pIC0gICAgICAgICAgICAgICAgICAgXAot
ICAgICAgICAgICAgICAgIG9mZnNldG9mKHN0cnVjdCBjcHVfdXNlcl9yZWdz
LCBlcnJvcl9jb2RlKSkKKyAgICAgICAgICAgICAgICBvZmZzZXRvZihzdHJ1
Y3QgY3B1X3VzZXJfcmVncywgZXJyb3JfY29kZSkgX19WQV9BUkdTX18pCiAK
ICAgICBPRkZTRVRfRUYoRUZSQU1FX2VudHJ5X3ZlY3RvciwgICAgZW50cnlf
dmVjdG9yKTsKICAgICBPRkZTRVRfRUYoRUZSQU1FX3JpcCwgICAgICAgICAg
ICAgcmlwKTsKICAgICBPRkZTRVRfRUYoRUZSQU1FX2NzLCAgICAgICAgICAg
ICAgY3MpOwogICAgIE9GRlNFVF9FRihFRlJBTUVfZWZsYWdzLCAgICAgICAg
ICBlZmxhZ3MpOworCisgICAgLyoKKyAgICAgKiBUaGVzZSBhcmVuJ3QgcmVh
bCBmaWVsZHMuICBUaGV5J3JlIHNwYXJlIHNwYWNlLCB1c2VkIGJ5IHRoZSBJ
U1QKKyAgICAgKiBleGl0LXRvLXhlbiBwYXRoLgorICAgICAqLworICAgIE9G
RlNFVF9FRihFRlJBTUVfc2hhZG93X3NjZiwgICAgICBlZmxhZ3MsICs0KTsK
KyAgICBPRkZTRVRfRUYoRUZSQU1FX3NoYWRvd19zZWwsICAgICAgZWZsYWdz
LCArNik7CisKICAgICBPRkZTRVRfRUYoRUZSQU1FX3JzcCwgICAgICAgICAg
ICAgcnNwKTsKICAgICBCTEFOSygpOwogCkBAIC0xMzYsNiArMTQ0LDcgQEAg
dm9pZCBfX2R1bW15X18odm9pZCkKIAogICAgIE9GRlNFVChDUFVJTkZPX2d1
ZXN0X2NwdV91c2VyX3JlZ3MsIHN0cnVjdCBjcHVfaW5mbywgZ3Vlc3RfY3B1
X3VzZXJfcmVncyk7CiAgICAgT0ZGU0VUKENQVUlORk9fZXJyb3JfY29kZSwg
c3RydWN0IGNwdV9pbmZvLCBndWVzdF9jcHVfdXNlcl9yZWdzLmVycm9yX2Nv
ZGUpOworICAgIE9GRlNFVChDUFVJTkZPX3JpcCwgc3RydWN0IGNwdV9pbmZv
LCBndWVzdF9jcHVfdXNlcl9yZWdzLnJpcCk7CiAgICAgT0ZGU0VUKENQVUlO
Rk9fdmVyd19zZWwsIHN0cnVjdCBjcHVfaW5mbywgdmVyd19zZWwpOwogICAg
IE9GRlNFVChDUFVJTkZPX2N1cnJlbnRfdmNwdSwgc3RydWN0IGNwdV9pbmZv
LCBjdXJyZW50X3ZjcHUpOwogICAgIE9GRlNFVChDUFVJTkZPX3Blcl9jcHVf
b2Zmc2V0LCBzdHJ1Y3QgY3B1X2luZm8sIHBlcl9jcHVfb2Zmc2V0KTsKZGlm
ZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni94ODZfNjQvY29tcGF0L2VudHJ5LlMg
Yi94ZW4vYXJjaC94ODYveDg2XzY0L2NvbXBhdC9lbnRyeS5TCmluZGV4IDdj
MjExMzE0ZDg4NS4uM2IyZmJjZDg3MzNhIDEwMDY0NAotLS0gYS94ZW4vYXJj
aC94ODYveDg2XzY0L2NvbXBhdC9lbnRyeS5TCisrKyBiL3hlbi9hcmNoL3g4
Ni94ODZfNjQvY29tcGF0L2VudHJ5LlMKQEAgLTE2MSw2ICsxNjEsMTIgQEAg
RU5UUlkoY29tcGF0X3Jlc3RvcmVfYWxsX2d1ZXN0KQogICAgICAgICBTUEVD
X0NUUkxfRVhJVF9UT19QViAgICAvKiBSZXE6IGE9c3BlY19jdHJsICVyc3A9
cmVncy9jcHVpbmZvLCBDbG9iOiBjZCAqLwogCiAgICAgICAgIFJFU1RPUkVf
QUxMIGFkaj04IGNvbXBhdD0xCisKKyAgICAgICAgLyogQWNjb3VudCBmb3Ig
ZXYvZWMgaGF2aW5nIGFscmVhZHkgYmVlbiBwb3BwZWQgb2ZmIHRoZSBzdGFj
ay4gKi8KKyAgICAgICAgU1BFQ19DVFJMX0NPTkRfVkVSVyBcCisgICAgICAg
ICAgICBzY2Y9U1RLX1JFTChDUFVJTkZPX3NwZWNfY3RybF9mbGFncywgQ1BV
SU5GT19yaXApLCBcCisgICAgICAgICAgICBzZWw9U1RLX1JFTChDUFVJTkZP
X3Zlcndfc2VsLCAgICAgICAgQ1BVSU5GT19yaXApCisKIC5MZnQwOiAgaXJl
dHEKICAgICAgICAgX0FTTV9QUkVfRVhUQUJMRSguTGZ0MCwgaGFuZGxlX2V4
Y2VwdGlvbikKIApkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L3g4Nl82NC9l
bnRyeS5TIGIveGVuL2FyY2gveDg2L3g4Nl82NC9lbnRyeS5TCmluZGV4IDEw
ZjExOTg2ZDhiOS4uOWIxZmE5ZWQxOTJmIDEwMDY0NAotLS0gYS94ZW4vYXJj
aC94ODYveDg2XzY0L2VudHJ5LlMKKysrIGIveGVuL2FyY2gveDg2L3g4Nl82
NC9lbnRyeS5TCkBAIC0yMTQsNiArMjE0LDkgQEAgcmVzdG9yZV9hbGxfZ3Vl
c3Q6CiAjZW5kaWYKIAogICAgICAgICBtb3YgICBFRlJBTUVfcmlwKCVyc3Ap
LCAlcmN4CisKKyAgICAgICAgU1BFQ19DVFJMX0NPTkRfVkVSVyAgICAgLyog
UmVxOiAlcnNwPWVmcmFtZSAgICAgICAgICAgICAgICAgICAgQ2xvYjogZWZs
ICovCisKICAgICAgICAgY21wdyAgJEZMQVRfVVNFUl9DUzMyLCBFRlJBTUVf
Y3MoJXJzcCkKICAgICAgICAgbW92ICAgRUZSQU1FX3JzcCglcnNwKSwgJXJz
cAogICAgICAgICBqZSAgICAxZgpAQCAtMjI3LDYgKzIzMCw5IEBAIHJlc3Rv
cmVfYWxsX2d1ZXN0OgogaXJldF9leGl0X3RvX2d1ZXN0OgogICAgICAgICBh
bmRsICAkfihYODZfRUZMQUdTX0lPUEwgfCBYODZfRUZMQUdTX1ZNKSwgRUZS
QU1FX2VmbGFncyglcnNwKQogICAgICAgICBvcmwgICAkWDg2X0VGTEFHU19J
RiwgRUZSQU1FX2VmbGFncyglcnNwKQorCisgICAgICAgIFNQRUNfQ1RSTF9D
T05EX1ZFUlcgICAgIC8qIFJlcTogJXJzcD1lZnJhbWUgICAgICAgICAgICAg
ICAgICAgIENsb2I6IGVmbCAqLworCiAgICAgICAgIGFkZHEgICQ4LCVyc3AK
IC5MZnQwOiAgaXJldHEKICAgICAgICAgX0FTTV9QUkVfRVhUQUJMRSguTGZ0
MCwgaGFuZGxlX2V4Y2VwdGlvbikKQEAgLTY3MCw5ICs2NzYsMjIgQEAgVU5M
SUtFTFlfU1RBUlQobmUsIGV4aXRfY3IzKQogVU5MSUtFTFlfRU5EKGV4aXRf
Y3IzKQogCiAgICAgICAgIC8qIFdBUk5JTkchIGByZXRgLCBgY2FsbCAqYCwg
YGptcCAqYCBub3Qgc2FmZSBiZXlvbmQgdGhpcyBwb2ludC4gKi8KLSAgICAg
ICAgU1BFQ19DVFJMX0VYSVRfVE9fWEVOICAgICAvKiBSZXE6ICVyMTI9aXN0
X2V4aXQgJXIxND1lbmQsIENsb2I6IGFiY2QgKi8KKyAgICAgICAgU1BFQ19D
VFJMX0VYSVRfVE9fWEVOIC8qIFJlcTogJXIxMj1pc3RfZXhpdCAlcjE0PWVu
ZCAlcnNwPXJlZ3MsIENsb2I6IGFiY2QgKi8KIAogICAgICAgICBSRVNUT1JF
X0FMTCBhZGo9OAorCisgICAgICAgIC8qCisgICAgICAgICAqIFdoZW4gdGhl
IENQVSBwdXNoZWQgdGhpcyBleGNlcHRpb24gZnJhbWUsIGl0IHplcm8tZXh0
ZW5kZWQgZWZsYWdzLgorICAgICAgICAgKiBGb3IgYW4gSVNUIGV4aXQsIFNQ
RUNfQ1RSTF9FWElUX1RPX1hFTiBzdGFzaGVkIHNoYWRvdyBjb3BpZXMgb2YK
KyAgICAgICAgICogc3BlY19jdHJsX2ZsYWdzIGFuZCB2ZXJfc2VsIGFib3Zl
IGVmbGFncywgYXMgd2UgY2FuJ3QgdXNlIGFueSBHUFJzLAorICAgICAgICAg
KiBhbmQgd2UncmUgYXQgYSByYW5kb20gcGxhY2Ugb24gdGhlIHN0YWNrLCBu
b3QgaW4gYSBDUFVGSU5GTyBibG9jay4KKyAgICAgICAgICoKKyAgICAgICAg
ICogQWNjb3VudCBmb3IgZXYvZWMgaGF2aW5nIGFscmVhZHkgYmVlbiBwb3Bw
ZWQgb2ZmIHRoZSBzdGFjay4KKyAgICAgICAgICovCisgICAgICAgIFNQRUNf
Q1RSTF9DT05EX1ZFUlcgXAorICAgICAgICAgICAgc2NmPVNUS19SRUwoRUZS
QU1FX3NoYWRvd19zY2YsIEVGUkFNRV9yaXApLCBcCisgICAgICAgICAgICBz
ZWw9U1RLX1JFTChFRlJBTUVfc2hhZG93X3NlbCwgRUZSQU1FX3JpcCkKKwog
ICAgICAgICBpcmV0cQogCiBFTlRSWShjb21tb25faW50ZXJydXB0KQpkaWZm
IC0tZ2l0IGEveGVuL2luY2x1ZGUvYXNtLXg4Ni9zcGVjX2N0cmxfYXNtLmgg
Yi94ZW4vaW5jbHVkZS9hc20teDg2L3NwZWNfY3RybF9hc20uaAppbmRleCBl
ODA3ZmY2ZDFkYjIuLjZlNzcyNWMxMWYzYSAxMDA2NDQKLS0tIGEveGVuL2lu
Y2x1ZGUvYXNtLXg4Ni9zcGVjX2N0cmxfYXNtLmgKKysrIGIveGVuL2luY2x1
ZGUvYXNtLXg4Ni9zcGVjX2N0cmxfYXNtLmgKQEAgLTE3NiwxNiArMTc2LDIz
IEBACiAgKi8KICNkZWZpbmUgU1RLX1JFTChmaWVsZCwgdG9wX29mX3N0aykg
KChmaWVsZCkgLSAodG9wX29mX3N0aykpCiAKLS5tYWNybyBET19TUEVDX0NU
UkxfQ09ORF9WRVJXCisubWFjcm8gU1BFQ19DVFJMX0NPTkRfVkVSVyBcCisg
ICAgc2NmPVNUS19SRUwoQ1BVSU5GT19zcGVjX2N0cmxfZmxhZ3MsIENQVUlO
Rk9fZXJyb3JfY29kZSksIFwKKyAgICBzZWw9U1RLX1JFTChDUFVJTkZPX3Zl
cndfc2VsLCAgICAgICAgQ1BVSU5GT19lcnJvcl9jb2RlKQogLyoKLSAqIFJl
cXVpcmVzICVyc3A9Y3B1aW5mbworICogUmVxdWlyZXMgXHNjZiBhbmQgXHNl
bCBhcyAlcnNwLXJlbGF0aXZlIGV4cHJlc3Npb25zCisgKiBDbG9iYmVycyBl
ZmxhZ3MKKyAqCisgKiBWRVJXIG5lZWRzIHRvIHJ1biBhZnRlciBndWVzdCBH
UFJzIGhhdmUgYmVlbiByZXN0b3JlZCwgd2hlcmUgb25seSAlcnNwIGlzCisg
KiBnb29kIHRvIHVzZS4gIERlZmF1bHQgdG8gZXhwZWN0aW5nICVyc3AgcG9p
bnRpbmcgYXQgQ1BVSU5GT19lcnJvcl9jb2RlLgorICogQ29udGV4dHMgd2hl
cmUgdGhpcyBpcyBub3QgdHJ1ZSBtdXN0IHByb3ZpZGUgYW4gYWx0ZXJuYXRp
dmUgXHNjZiBhbmQgXHNlbC4KICAqCiAgKiBJc3N1ZSBhIFZFUlcgZm9yIGl0
cyBmbHVzaGluZyBzaWRlIGVmZmVjdCwgaWYgaW5kaWNhdGVkLiAgVGhpcyBp
cyBhIFNwZWN0cmUKICAqIHYxIGdhZGdldCwgYnV0IHRoZSBJUkVUL1ZNRW50
cnkgaXMgc2VyaWFsaXNpbmcuCiAgKi8KLSAgICB0ZXN0YiAkU0NGX3Zlcncs
IENQVUlORk9fc3BlY19jdHJsX2ZsYWdzKCVyc3ApCisgICAgdGVzdGIgJFND
Rl92ZXJ3LCBcc2NmKCVyc3ApCiAgICAganogLkxcQF92ZXJ3X3NraXAKLSAg
ICB2ZXJ3IENQVUlORk9fdmVyd19zZWwoJXJzcCkKKyAgICB2ZXJ3IFxzZWwo
JXJzcCkKIC5MXEBfdmVyd19za2lwOgogLmVuZG0KIApAQCAtMzAzLDggKzMx
MCw2IEBACiAgKi8KICAgICBBTFRFUk5BVElWRSAiIiwgRE9fU1BFQ19DVFJM
X0VYSVRfVE9fR1VFU1QsIFg4Nl9GRUFUVVJFX1NDX01TUl9QVgogCi0gICAg
RE9fU1BFQ19DVFJMX0NPTkRfVkVSVwotCiAgICAgQUxURVJOQVRJVkUgIiIs
IERPX1NQRUNfQ1RSTF9ESVYsIFg4Nl9GRUFUVVJFX1NDX0RJVgogLmVuZG0K
IApAQCAtMzg0LDcgKzM4OSw3IEBAIFVOTElLRUxZX0RJU1BBVENIX0xBQkVM
KFxAX3NlcmlhbGlzZSk6CiAgKi8KIC5tYWNybyBTUEVDX0NUUkxfRVhJVF9U
T19YRU4KIC8qCi0gKiBSZXF1aXJlcyAlcjEyPWlzdF9leGl0LCAlcjE0PXN0
YWNrX2VuZAorICogUmVxdWlyZXMgJXIxMj1pc3RfZXhpdCwgJXIxND1zdGFj
a19lbmQsICVyc3A9cmVncwogICogQ2xvYmJlcnMgJXJheCwgJXJieCwgJXJj
eCwgJXJkeAogICovCiAgICAgbW92emJsIFNUQUNLX0NQVUlORk9fRklFTEQo
c3BlY19jdHJsX2ZsYWdzKSglcjE0KSwgJWVieApAQCAtNDEyLDExICs0MTcs
MTggQEAgVU5MSUtFTFlfRElTUEFUQ0hfTEFCRUwoXEBfc2VyaWFsaXNlKToK
ICAgICB0ZXN0ICVyMTIsICVyMTIKICAgICBqeiAuTFxAX3NraXBfaXN0X2V4
aXQKIAotICAgIC8qIExvZ2ljYWxseSBET19TUEVDX0NUUkxfQ09ORF9WRVJX
IGJ1dCB3aXRob3V0IHRoZSAlcnNwPWNwdWluZm8gZGVwZW5kZW5jeSAqLwot
ICAgIHRlc3RiICRTQ0ZfdmVydywgJWJsCi0gICAganogLkxcQF9za2lwX3Zl
cncKLSAgICB2ZXJ3IFNUQUNLX0NQVUlORk9fRklFTEQodmVyd19zZWwpKCVy
MTQpCi0uTFxAX3NraXBfdmVydzoKKyAgICAvKgorICAgICAqIFN0YXNoIFND
RiBhbmQgdmVyd19zZWwgYWJvdmUgZWZsYWdzIGluIHRoZSBjYXNlIG9mIGFu
IElTVF9leGl0LiAgVGhlCisgICAgICogVkVSVyBsb2dpYyBuZWVkcyB0byBy
dW4gYWZ0ZXIgZ3Vlc3QgR1BScyBoYXZlIGJlZW4gcmVzdG9yZWQ7IGkuZS4g
d2hlcmUKKyAgICAgKiB3ZSBjYW5ub3QgdXNlICVyMTIgb3IgJXIxNCBmb3Ig
dGhlIHB1cnBvc2VzIHRoZXkgaGF2ZSBoZXJlLgorICAgICAqCisgICAgICog
V2hlbiB0aGUgQ1BVIHB1c2hlZCB0aGlzIGV4Y2VwdGlvbiBmcmFtZSwgaXQg
emVyby1leHRlbmRlZCBlZmxhZ3MuCisgICAgICogVGhlcmVmb3JlIGl0IGlz
IHNhZmUgZm9yIHRoZSBWRVJXIGxvZ2ljIHRvIGxvb2sgYXQgdGhlIHN0YXNo
ZWQgU0NGCisgICAgICogb3V0c2lkZSBvZiB0aGUgaXN0X2V4aXQgY29uZGl0
aW9uLiAgQWxzbywgdGhpcyBzdGFzaGluZyB3b24ndCBpbmZsdWVuY2UKKyAg
ICAgKiBhbnkgb3RoZXIgcmVzdG9yZV9hbGxfZ3Vlc3QoKSBwYXRocy4KKyAg
ICAgKi8KKyAgICBvciAkKF9fSFlQRVJWSVNPUl9EUzMyIDw8IDE2KSwgJWVi
eAorICAgIG1vdiAlZWJ4LCBVUkVHU19lZmxhZ3MgKyA0KCVyc3ApIC8qIEVG
UkFNRV9zaGFkb3dfc2NmL3NlbCAqLwogCiAgICAgQUxURVJOQVRJVkUgIiIs
IERPX1NQRUNfQ1RSTF9ESVYsIFg4Nl9GRUFUVVJFX1NDX0RJVgogCg==

--=separator
Content-Type: application/octet-stream; name="xsa452/xsa452-4.16-5.patch"
Content-Disposition: attachment; filename="xsa452/xsa452-4.16-5.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L3NwZWMtY3RybDogUmVuYW1lIFZFUlcgcmVsYXRl
ZCBvcHRpb25zCgpWRVJXIGlzIGdvaW5nIHRvIGJlIHVzZWQgZm9yIGEgM3Jk
IHB1cnBvc2UsIGFuZCB0aGUgZXhpc3Rpbmcgbm9tZW5jbGF0dXJlCmRpZG4n
dCBzdXJ2aXZlIHRoZSBTdGFsZSBNTUlPIGlzc3VlcyB0ZXJyaWJseSB3ZWxs
LgoKUmVuYW1lIHRoZSBjb21tYW5kIGxpbmUgb3B0aW9uIGZyb20gYG1kLWNs
ZWFyPWAgdG8gYHZlcnc9YC4gIFRoaXMgaXMgbW9yZQpjb25zaXN0ZW50IHdp
dGggb3RoZXIgb3B0aW9ucyB3aGljaCB0ZW5kIHRvIGJlIG5hbWVkIGJhc2Vk
IG9uIHdoYXQgdGhleSdyZQpkb2luZywgbm90IHdoaWNoIGZlYXR1cmUgZW51
bWVyYXRpb24gdGhleSB1c2UgYmVoaW5kIHRoZSBzY2VuZXMuICBSZXRhaW4K
YG1kLWNsZWFyPWAgYXMgYSBkZXByZWNhdGVkIGFsaWFzLgoKUmVuYW1lIG9w
dF9tZF9jbGVhcl97cHYsaHZtfSBhbmQgb3B0X2ZiX2NsZWFyX21taW8gdG8g
b3B0X3Zlcndfe3B2LGh2bSxtbWlvfSwKd2hpY2ggaGFzIGEgc2lkZSBlZmZl
Y3Qgb2YgbWFraW5nIHNwZWNfY3RybF9pbml0X2RvbWFpbigpIHJhdGhlciBj
bGVhcmVyIHRvCmZvbGxvdy4KCk5vIGZ1bmN0aW9uYWwgY2hhbmdlLgoKVGhp
cyBpcyBwYXJ0IG9mIFhTQS00NTIgLyBDVkUtMjAyMy0yODc0Ni4KClNpZ25l
ZC1vZmYtYnk6IEFuZHJldyBDb29wZXIgPGFuZHJldy5jb29wZXIzQGNpdHJp
eC5jb20+ClJldmlld2VkLWJ5OiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3Vz
ZS5jb20+CihjaGVycnkgcGlja2VkIGZyb20gY29tbWl0IGY3NjAzY2EyNTJl
NDIyNjczOWViMzEyOWE1MjkwZWUzZGEzZjhlYTQpCgpkaWZmIC0tZ2l0IGEv
ZG9jcy9taXNjL3hlbi1jb21tYW5kLWxpbmUucGFuZG9jIGIvZG9jcy9taXNj
L3hlbi1jb21tYW5kLWxpbmUucGFuZG9jCmluZGV4IGE3YTEzNjJiYWMyOC4u
MDI5MDAyZmE4MmQ2IDEwMDY0NAotLS0gYS9kb2NzL21pc2MveGVuLWNvbW1h
bmQtbGluZS5wYW5kb2MKKysrIGIvZG9jcy9taXNjL3hlbi1jb21tYW5kLWxp
bmUucGFuZG9jCkBAIC0yMjYwLDcgKzIyNjAsNyBAQCBCeSBkZWZhdWx0IFNT
QkQgd2lsbCBiZSBtaXRpZ2F0ZWQgYXQgcnVudGltZSAoaS5lIGBzc2JkPXJ1
bnRpbWVgKS4KIAogIyMjIHNwZWMtY3RybCAoeDg2KQogPiBgPSBMaXN0IG9m
IFsgPGJvb2w+LCB4ZW49PGJvb2w+LCB7cHYsaHZtfT08Ym9vbD4sCi0+ICAg
ICAgICAgICAgICB7bXNyLXNjLHJzYixtZC1jbGVhcixpYnBiLWVudHJ5fT08
Ym9vbD58e3B2LGh2bX09PGJvb2w+LAorPiAgICAgICAgICAgICAge21zci1z
Yyxyc2IsdmVydyxpYnBiLWVudHJ5fT08Ym9vbD58e3B2LGh2bX09PGJvb2w+
LAogPiAgICAgICAgICAgICAgYnRpLXRodW5rPXJldHBvbGluZXxsZmVuY2V8
am1wLCB7aWJycyxpYnBiLHNzYmQscHNmZCwKID4gICAgICAgICAgICAgIGVh
Z2VyLWZwdSxsMWQtZmx1c2gsYnJhbmNoLWhhcmRlbixzcmItbG9jaywKID4g
ICAgICAgICAgICAgIHVucHJpdi1tbWlvLGdkcy1taXQsZGl2LXNjcnVifT08
Ym9vbD4gXWAKQEAgLTIyODUsNyArMjI4NSw3IEBAIGluIHBsYWNlIGZvciBn
dWVzdHMgdG8gdXNlLgogCiBVc2Ugb2YgYSBwb3NpdGl2ZSBib29sZWFuIHZh
bHVlIGZvciBlaXRoZXIgb2YgdGhlc2Ugb3B0aW9ucyBpcyBpbnZhbGlkLgog
Ci1UaGUgYHB2PWAsIGBodm09YCwgYG1zci1zYz1gLCBgcnNiPWAsIGBtZC1j
bGVhcj1gIGFuZCBgaWJwYi1lbnRyeT1gIG9wdGlvbnMKK1RoZSBgcHY9YCwg
YGh2bT1gLCBgbXNyLXNjPWAsIGByc2I9YCwgYHZlcnc9YCBhbmQgYGlicGIt
ZW50cnk9YCBvcHRpb25zCiBvZmZlciBmaW5lIGdyYWluZWQgY29udHJvbCBv
dmVyIHRoZSBwcmltaXRpdmVzIGJ5IFhlbi4gIFRoZXNlIGltcGFjdCBYZW4n
cwogYWJpbGl0eSB0byBwcm90ZWN0IGl0c2VsZiwgYW5kL29yIFhlbidzIGFi
aWxpdHkgdG8gdmlydHVhbGlzZSBzdXBwb3J0IGZvcgogZ3Vlc3RzIHRvIHVz
ZS4KQEAgLTIzMDIsMTEgKzIzMDIsMTIgQEAgZ3Vlc3RzIHRvIHVzZS4KICAg
Z3Vlc3RzIGFuZCBpZiBkaXNhYmxlZCwgZ3Vlc3RzIHdpbGwgYmUgdW5hYmxl
IHRvIHVzZSBJQlJTL1NUSUJQL1NTQkQvZXRjLgogKiBgcnNiPWAgb2ZmZXJz
IGNvbnRyb2wgb3ZlciB3aGV0aGVyIHRvIG92ZXJ3cml0ZSB0aGUgUmV0dXJu
IFN0YWNrIEJ1ZmZlciAvCiAgIFJldHVybiBBZGRyZXNzIFN0YWNrIG9uIGVu
dHJ5IHRvIFhlbiBhbmQgb24gaWRsZS4KLSogYG1kLWNsZWFyPWAgb2ZmZXJz
IGNvbnRyb2wgb3ZlciB3aGV0aGVyIHRvIHVzZSBWRVJXIHRvIGZsdXNoCi0g
IG1pY3JvYXJjaGl0ZWN0dXJhbCBidWZmZXJzIG9uIGlkbGUgYW5kIGV4aXQg
ZnJvbSBYZW4uICAqTm90ZTogRm9yCi0gIGNvbXBhdGliaWxpdHkgd2l0aCBk
ZXZlbG9wbWVudCB2ZXJzaW9ucyBvZiB0aGlzIGZpeCwgYG1kcz1gIGlzIGFs
c28gYWNjZXB0ZWQKLSAgb24gWGVuIDQuMTIgYW5kIGVhcmxpZXIgYXMgYW4g
YWxpYXMuICBDb25zdWx0IHZlbmRvciBkb2N1bWVudGF0aW9uIGluCi0gIHBy
ZWZlcmVuY2UgdG8gaGVyZS4qCisqIGB2ZXJ3PWAgb2ZmZXJzIGNvbnRyb2wg
b3ZlciB3aGV0aGVyIHRvIHVzZSBWRVJXIGZvciBpdHMgc2NydWJiaW5nIHNp
ZGUKKyAgZWZmZWN0cyBhdCBhcHByb3ByaWF0ZSBwcml2aWxlZ2UgdHJhbnNp
dGlvbnMuICBUaGUgZXhhY3Qgc2lkZSBlZmZlY3RzIGFyZQorICBtaWNyb2Fy
Y2hpdGVjdHVyZSBhbmQgbWljcm9jb2RlIHNwZWNpZmljLiAgKk5vdGU6IGBt
ZC1jbGVhcj1gIGlzIGFjY2VwdGVkIGFzCisgIGEgZGVwcmVjYXRlZCBhbGlh
cy4gIEZvciBjb21wYXRpYmlsaXR5IHdpdGggZGV2ZWxvcG1lbnQgdmVyc2lv
bnMgb2YgWFNBLTI5NywKKyAgYG1kcz1gIGlzIGFsc28gYWNjZXB0ZWQgb24g
WGVuIDQuMTIgYW5kIGVhcmxpZXIgYXMgYW4gYWxpYXMuICBDb25zdWx0IHZl
bmRvcgorICBkb2N1bWVudGF0aW9uIGluIHByZWZlcmVuY2UgdG8gaGVyZS4q
CiAqIGBpYnBiLWVudHJ5PWAgb2ZmZXJzIGNvbnRyb2wgb3ZlciB3aGV0aGVy
IElCUEIgKEluZGlyZWN0IEJyYW5jaCBQcmVkaWN0aW9uCiAgIEJhcnJpZXIp
IGlzIHVzZWQgb24gZW50cnkgdG8gWGVuLiAgVGhpcyBpcyB1c2VkIGJ5IGRl
ZmF1bHQgb24gaGFyZHdhcmUKICAgdnVsbmVyYWJsZSB0byBCcmFuY2ggVHlw
ZSBDb25mdXNpb24sIGFuZCBoYXJkd2FyZSB2dWxuZXJhYmxlIHRvIFNwZWN1
bGF0aXZlCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYvc3BlY19jdHJsLmMg
Yi94ZW4vYXJjaC94ODYvc3BlY19jdHJsLmMKaW5kZXggNmU4MmExMjZhM2Uy
Li4yOTJiNWIxYzdiYTEgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9zcGVj
X2N0cmwuYworKysgYi94ZW4vYXJjaC94ODYvc3BlY19jdHJsLmMKQEAgLTM3
LDggKzM3LDggQEAgc3RhdGljIGJvb2wgX19pbml0ZGF0YSBvcHRfbXNyX3Nj
X3B2ID0gdHJ1ZTsKIHN0YXRpYyBib29sIF9faW5pdGRhdGEgb3B0X21zcl9z
Y19odm0gPSB0cnVlOwogc3RhdGljIGludDhfdCBfX2luaXRkYXRhIG9wdF9y
c2JfcHYgPSAtMTsKIHN0YXRpYyBib29sIF9faW5pdGRhdGEgb3B0X3JzYl9o
dm0gPSB0cnVlOwotc3RhdGljIGludDhfdCBfX3JlYWRfbW9zdGx5IG9wdF9t
ZF9jbGVhcl9wdiA9IC0xOwotc3RhdGljIGludDhfdCBfX3JlYWRfbW9zdGx5
IG9wdF9tZF9jbGVhcl9odm0gPSAtMTsKK3N0YXRpYyBpbnQ4X3QgX19yZWFk
X21vc3RseSBvcHRfdmVyd19wdiA9IC0xOworc3RhdGljIGludDhfdCBfX3Jl
YWRfbW9zdGx5IG9wdF92ZXJ3X2h2bSA9IC0xOwogCiBzdGF0aWMgaW50OF90
IF9fcmVhZF9tb3N0bHkgb3B0X2licGJfZW50cnlfcHYgPSAtMTsKIHN0YXRp
YyBpbnQ4X3QgX19yZWFkX21vc3RseSBvcHRfaWJwYl9lbnRyeV9odm0gPSAt
MTsKQEAgLTc3LDcgKzc3LDcgQEAgc3RhdGljIGJvb2wgX19pbml0ZGF0YSBj
cHVfaGFzX2J1Z19tZHM7IC8qIEFueSBvdGhlciBNe0xQLFNCLEZCfURTIGNv
bWJpbmF0aW9uLgogCiBzdGF0aWMgaW50OF90IF9faW5pdGRhdGEgb3B0X3Ny
Yl9sb2NrID0gLTE7CiBzdGF0aWMgYm9vbCBfX2luaXRkYXRhIG9wdF91bnBy
aXZfbW1pbzsKLXN0YXRpYyBib29sIF9fcmVhZF9tb3N0bHkgb3B0X2ZiX2Ns
ZWFyX21taW87CitzdGF0aWMgYm9vbCBfX3JlYWRfbW9zdGx5IG9wdF92ZXJ3
X21taW87CiBzdGF0aWMgaW50OF90IF9faW5pdGRhdGEgb3B0X2dkc19taXQg
PSAtMTsKIHN0YXRpYyBpbnQ4X3QgX19pbml0ZGF0YSBvcHRfZGl2X3NjcnVi
ID0gLTE7CiAKQEAgLTExOSw4ICsxMTksOCBAQCBzdGF0aWMgaW50IF9faW5p
dCBwYXJzZV9zcGVjX2N0cmwoY29uc3QgY2hhciAqcykKICAgICAgICAgZGlz
YWJsZV9jb21tb246CiAgICAgICAgICAgICBvcHRfcnNiX3B2ID0gZmFsc2U7
CiAgICAgICAgICAgICBvcHRfcnNiX2h2bSA9IGZhbHNlOwotICAgICAgICAg
ICAgb3B0X21kX2NsZWFyX3B2ID0gMDsKLSAgICAgICAgICAgIG9wdF9tZF9j
bGVhcl9odm0gPSAwOworICAgICAgICAgICAgb3B0X3ZlcndfcHYgPSAwOwor
ICAgICAgICAgICAgb3B0X3ZlcndfaHZtID0gMDsKICAgICAgICAgICAgIG9w
dF9pYnBiX2VudHJ5X3B2ID0gMDsKICAgICAgICAgICAgIG9wdF9pYnBiX2Vu
dHJ5X2h2bSA9IDA7CiAgICAgICAgICAgICBvcHRfaWJwYl9lbnRyeV9kb20w
ID0gZmFsc2U7CkBAIC0xNTEsMTQgKzE1MSwxNCBAQCBzdGF0aWMgaW50IF9f
aW5pdCBwYXJzZV9zcGVjX2N0cmwoY29uc3QgY2hhciAqcykKICAgICAgICAg
ewogICAgICAgICAgICAgb3B0X21zcl9zY19wdiA9IHZhbDsKICAgICAgICAg
ICAgIG9wdF9yc2JfcHYgPSB2YWw7Ci0gICAgICAgICAgICBvcHRfbWRfY2xl
YXJfcHYgPSB2YWw7CisgICAgICAgICAgICBvcHRfdmVyd19wdiA9IHZhbDsK
ICAgICAgICAgICAgIG9wdF9pYnBiX2VudHJ5X3B2ID0gdmFsOwogICAgICAg
ICB9CiAgICAgICAgIGVsc2UgaWYgKCAodmFsID0gcGFyc2VfYm9vbGVhbigi
aHZtIiwgcywgc3MpKSA+PSAwICkKICAgICAgICAgewogICAgICAgICAgICAg
b3B0X21zcl9zY19odm0gPSB2YWw7CiAgICAgICAgICAgICBvcHRfcnNiX2h2
bSA9IHZhbDsKLSAgICAgICAgICAgIG9wdF9tZF9jbGVhcl9odm0gPSB2YWw7
CisgICAgICAgICAgICBvcHRfdmVyd19odm0gPSB2YWw7CiAgICAgICAgICAg
ICBvcHRfaWJwYl9lbnRyeV9odm0gPSB2YWw7CiAgICAgICAgIH0KICAgICAg
ICAgZWxzZSBpZiAoICh2YWwgPSBwYXJzZV9ib29sZWFuKCJtc3Itc2MiLCBz
LCBzcykpICE9IC0xICkKQEAgLTIwMywyMSArMjAzLDIyIEBAIHN0YXRpYyBp
bnQgX19pbml0IHBhcnNlX3NwZWNfY3RybChjb25zdCBjaGFyICpzKQogICAg
ICAgICAgICAgICAgIGJyZWFrOwogICAgICAgICAgICAgfQogICAgICAgICB9
Ci0gICAgICAgIGVsc2UgaWYgKCAodmFsID0gcGFyc2VfYm9vbGVhbigibWQt
Y2xlYXIiLCBzLCBzcykpICE9IC0xICkKKyAgICAgICAgZWxzZSBpZiAoICh2
YWwgPSBwYXJzZV9ib29sZWFuKCJ2ZXJ3Iiwgcywgc3MpKSAhPSAtMSB8fAor
ICAgICAgICAgICAgICAgICAgKHZhbCA9IHBhcnNlX2Jvb2xlYW4oIm1kLWNs
ZWFyIiwgcywgc3MpKSAhPSAtMSApCiAgICAgICAgIHsKICAgICAgICAgICAg
IHN3aXRjaCAoIHZhbCApCiAgICAgICAgICAgICB7CiAgICAgICAgICAgICBj
YXNlIDA6CiAgICAgICAgICAgICBjYXNlIDE6Ci0gICAgICAgICAgICAgICAg
b3B0X21kX2NsZWFyX3B2ID0gb3B0X21kX2NsZWFyX2h2bSA9IHZhbDsKKyAg
ICAgICAgICAgICAgICBvcHRfdmVyd19wdiA9IG9wdF92ZXJ3X2h2bSA9IHZh
bDsKICAgICAgICAgICAgICAgICBicmVhazsKIAogICAgICAgICAgICAgY2Fz
ZSAtMjoKLSAgICAgICAgICAgICAgICBzICs9IHN0cmxlbigibWQtY2xlYXI9
Iik7CisgICAgICAgICAgICAgICAgcyArPSAoKnMgPT0gJ3YnKSA/IHN0cmxl
bigidmVydz0iKSA6IHN0cmxlbigibWQtY2xlYXI9Iik7CiAgICAgICAgICAg
ICAgICAgaWYgKCAodmFsID0gcGFyc2VfYm9vbGVhbigicHYiLCBzLCBzcykp
ID49IDAgKQotICAgICAgICAgICAgICAgICAgICBvcHRfbWRfY2xlYXJfcHYg
PSB2YWw7CisgICAgICAgICAgICAgICAgICAgIG9wdF92ZXJ3X3B2ID0gdmFs
OwogICAgICAgICAgICAgICAgIGVsc2UgaWYgKCAodmFsID0gcGFyc2VfYm9v
bGVhbigiaHZtIiwgcywgc3MpKSA+PSAwICkKLSAgICAgICAgICAgICAgICAg
ICAgb3B0X21kX2NsZWFyX2h2bSA9IHZhbDsKKyAgICAgICAgICAgICAgICAg
ICAgb3B0X3ZlcndfaHZtID0gdmFsOwogICAgICAgICAgICAgICAgIGVsc2UK
ICAgICAgICAgICAgIGRlZmF1bHQ6CiAgICAgICAgICAgICAgICAgICAgIHJj
ID0gLUVJTlZBTDsKQEAgLTUxMiw4ICs1MTMsOCBAQCBzdGF0aWMgdm9pZCBf
X2luaXQgcHJpbnRfZGV0YWlscyhlbnVtIGluZF90aHVuayB0aHVuaykKICAg
ICAgICAgICAgb3B0X3NyYl9sb2NrICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgPyAiIFNSQl9MT0NLKyIgOiAiIFNSQl9MT0NLLSIsCiAgICAgICAg
ICAgIG9wdF9pYnBiX2N0eHRfc3dpdGNoICAgICAgICAgICAgICAgICAgICAg
ID8gIiBJQlBCLWN0eHQiIDogIiIsCiAgICAgICAgICAgIG9wdF9sMWRfZmx1
c2ggICAgICAgICAgICAgICAgICAgICAgICAgICAgID8gIiBMMURfRkxVU0gi
IDogIiIsCi0gICAgICAgICAgIG9wdF9tZF9jbGVhcl9wdiB8fCBvcHRfbWRf
Y2xlYXJfaHZtIHx8Ci0gICAgICAgICAgIG9wdF9mYl9jbGVhcl9tbWlvICAg
ICAgICAgICAgICAgICAgICAgICAgID8gIiBWRVJXIiAgOiAiIiwKKyAgICAg
ICAgICAgb3B0X3ZlcndfcHYgfHwgb3B0X3ZlcndfaHZtIHx8CisgICAgICAg
ICAgIG9wdF92ZXJ3X21taW8gICAgICAgICAgICAgICAgICAgICAgICAgICAg
ID8gIiBWRVJXIiAgOiAiIiwKICAgICAgICAgICAgb3B0X2Rpdl9zY3J1YiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgPyAiIERJViIgOiAiIiwKICAg
ICAgICAgICAgb3B0X2JyYW5jaF9oYXJkZW4gICAgICAgICAgICAgICAgICAg
ICAgICAgPyAiIEJSQU5DSF9IQVJERU4iIDogIiIpOwogCkBAIC01MzMsMTEg
KzUzNCwxMSBAQCBzdGF0aWMgdm9pZCBfX2luaXQgcHJpbnRfZGV0YWlscyhl
bnVtIGluZF90aHVuayB0aHVuaykKICAgICAgICAgICAgKGJvb3RfY3B1X2hh
cyhYODZfRkVBVFVSRV9TQ19NU1JfSFZNKSB8fAogICAgICAgICAgICAgYm9v
dF9jcHVfaGFzKFg4Nl9GRUFUVVJFX1NDX1JTQl9IVk0pIHx8CiAgICAgICAg
ICAgICBib290X2NwdV9oYXMoWDg2X0ZFQVRVUkVfSUJQQl9FTlRSWV9IVk0p
IHx8Ci0gICAgICAgICAgICBvcHRfZWFnZXJfZnB1IHx8IG9wdF9tZF9jbGVh
cl9odm0pICAgICAgID8gIiIgICAgICAgICAgICAgICA6ICIgTm9uZSIsCisg
ICAgICAgICAgICBvcHRfZWFnZXJfZnB1IHx8IG9wdF92ZXJ3X2h2bSkgICAg
ICAgICAgID8gIiIgICAgICAgICAgICAgICA6ICIgTm9uZSIsCiAgICAgICAg
ICAgIGJvb3RfY3B1X2hhcyhYODZfRkVBVFVSRV9TQ19NU1JfSFZNKSAgICAg
ID8gIiBNU1JfU1BFQ19DVFJMIiA6ICIiLAogICAgICAgICAgICBib290X2Nw
dV9oYXMoWDg2X0ZFQVRVUkVfU0NfUlNCX0hWTSkgICAgICA/ICIgUlNCIiAg
ICAgICAgICAgOiAiIiwKICAgICAgICAgICAgb3B0X2VhZ2VyX2ZwdSAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgPyAiIEVBR0VSX0ZQVSIgICAgIDog
IiIsCi0gICAgICAgICAgIG9wdF9tZF9jbGVhcl9odm0gICAgICAgICAgICAg
ICAgICAgICAgICAgID8gIiBNRF9DTEVBUiIgICAgICA6ICIiLAorICAgICAg
ICAgICBvcHRfdmVyd19odm0gICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICA/ICIgVkVSVyIgICAgICAgICAgOiAiIiwKICAgICAgICAgICAgYm9vdF9j
cHVfaGFzKFg4Nl9GRUFUVVJFX0lCUEJfRU5UUllfSFZNKSAgPyAiIElCUEIt
ZW50cnkiICAgIDogIiIpOwogCiAjZW5kaWYKQEAgLTU0NiwxMSArNTQ3LDEx
IEBAIHN0YXRpYyB2b2lkIF9faW5pdCBwcmludF9kZXRhaWxzKGVudW0gaW5k
X3RodW5rIHRodW5rKQogICAgICAgICAgICAoYm9vdF9jcHVfaGFzKFg4Nl9G
RUFUVVJFX1NDX01TUl9QVikgfHwKICAgICAgICAgICAgIGJvb3RfY3B1X2hh
cyhYODZfRkVBVFVSRV9TQ19SU0JfUFYpIHx8CiAgICAgICAgICAgICBib290
X2NwdV9oYXMoWDg2X0ZFQVRVUkVfSUJQQl9FTlRSWV9QVikgfHwKLSAgICAg
ICAgICAgIG9wdF9lYWdlcl9mcHUgfHwgb3B0X21kX2NsZWFyX3B2KSAgICAg
ICAgPyAiIiAgICAgICAgICAgICAgIDogIiBOb25lIiwKKyAgICAgICAgICAg
IG9wdF9lYWdlcl9mcHUgfHwgb3B0X3ZlcndfcHYpICAgICAgICAgICAgPyAi
IiAgICAgICAgICAgICAgIDogIiBOb25lIiwKICAgICAgICAgICAgYm9vdF9j
cHVfaGFzKFg4Nl9GRUFUVVJFX1NDX01TUl9QVikgICAgICAgPyAiIE1TUl9T
UEVDX0NUUkwiIDogIiIsCiAgICAgICAgICAgIGJvb3RfY3B1X2hhcyhYODZf
RkVBVFVSRV9TQ19SU0JfUFYpICAgICAgID8gIiBSU0IiICAgICAgICAgICA6
ICIiLAogICAgICAgICAgICBvcHRfZWFnZXJfZnB1ICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICA/ICIgRUFHRVJfRlBVIiAgICAgOiAiIiwKLSAgICAg
ICAgICAgb3B0X21kX2NsZWFyX3B2ICAgICAgICAgICAgICAgICAgICAgICAg
ICAgPyAiIE1EX0NMRUFSIiAgICAgIDogIiIsCisgICAgICAgICAgIG9wdF92
ZXJ3X3B2ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgID8gIiBWRVJX
IiAgICAgICAgICA6ICIiLAogICAgICAgICAgICBib290X2NwdV9oYXMoWDg2
X0ZFQVRVUkVfSUJQQl9FTlRSWV9QVikgICA/ICIgSUJQQi1lbnRyeSIgICAg
OiAiIik7CiAKICAgICBwcmludGsoIiAgWFBUSSAoNjQtYml0IFBWIG9ubHkp
OiBEb20wICVzLCBEb21VICVzICh3aXRoJXMgUENJRClcbiIsCkBAIC0xNDc5
LDggKzE0ODAsOCBAQCB2b2lkIHNwZWNfY3RybF9pbml0X2RvbWFpbihzdHJ1
Y3QgZG9tYWluICpkKQogewogICAgIGJvb2wgcHYgPSBpc19wdl9kb21haW4o
ZCk7CiAKLSAgICBib29sIHZlcncgPSAoKHB2ID8gb3B0X21kX2NsZWFyX3B2
IDogb3B0X21kX2NsZWFyX2h2bSkgfHwKLSAgICAgICAgICAgICAgICAgKG9w
dF9mYl9jbGVhcl9tbWlvICYmIGlzX2lvbW11X2VuYWJsZWQoZCkpKTsKKyAg
ICBib29sIHZlcncgPSAoKHB2ID8gb3B0X3ZlcndfcHYgOiBvcHRfdmVyd19o
dm0pIHx8CisgICAgICAgICAgICAgICAgIChvcHRfdmVyd19tbWlvICYmIGlz
X2lvbW11X2VuYWJsZWQoZCkpKTsKIAogICAgIGJvb2wgaWJwYiA9ICgocHYg
PyBvcHRfaWJwYl9lbnRyeV9wdiA6IG9wdF9pYnBiX2VudHJ5X2h2bSkgJiYK
ICAgICAgICAgICAgICAgICAgKGQtPmRvbWFpbl9pZCAhPSAwIHx8IG9wdF9p
YnBiX2VudHJ5X2RvbTApKTsKQEAgLTE4MzgsMTkgKzE4MzksMjAgQEAgdm9p
ZCBfX2luaXQgaW5pdF9zcGVjdWxhdGlvbl9taXRpZ2F0aW9ucyh2b2lkKQog
ICAgICAqIHRoZSByZXR1cm4tdG8tZ3Vlc3QgcGF0aC4KICAgICAgKi8KICAg
ICBpZiAoIG9wdF91bnByaXZfbW1pbyApCi0gICAgICAgIG9wdF9mYl9jbGVh
cl9tbWlvID0gY3B1X2hhc19mYl9jbGVhcjsKKyAgICAgICAgb3B0X3Zlcndf
bW1pbyA9IGNwdV9oYXNfZmJfY2xlYXI7CiAKICAgICAvKgogICAgICAqIEJ5
IGRlZmF1bHQsIGVuYWJsZSBQViBhbmQgSFZNIG1pdGlnYXRpb25zIG9uIE1E
Uy12dWxuZXJhYmxlIGhhcmR3YXJlLgogICAgICAqIFRoaXMgd2lsbCBvbmx5
IGJlIGEgdG9rZW4gZWZmb3J0IGZvciBNTFBEUy9NRkJEUyB3aGVuIEhUIGlz
IGVuYWJsZWQsCiAgICAgICogYnV0IGl0IGlzIHNvbWV3aGF0IGJldHRlciB0
aGFuIG5vdGhpbmcuCiAgICAgICovCi0gICAgaWYgKCBvcHRfbWRfY2xlYXJf
cHYgPT0gLTEgKQotICAgICAgICBvcHRfbWRfY2xlYXJfcHYgPSAoKGNwdV9o
YXNfYnVnX21kcyB8fCBjcHVfaGFzX2J1Z19tc2Jkc19vbmx5KSAmJgotICAg
ICAgICAgICAgICAgICAgICAgICAgICAgYm9vdF9jcHVfaGFzKFg4Nl9GRUFU
VVJFX01EX0NMRUFSKSk7Ci0gICAgaWYgKCBvcHRfbWRfY2xlYXJfaHZtID09
IC0xICkKLSAgICAgICAgb3B0X21kX2NsZWFyX2h2bSA9ICgoY3B1X2hhc19i
dWdfbWRzIHx8IGNwdV9oYXNfYnVnX21zYmRzX29ubHkpICYmCi0gICAgICAg
ICAgICAgICAgICAgICAgICAgICAgYm9vdF9jcHVfaGFzKFg4Nl9GRUFUVVJF
X01EX0NMRUFSKSk7CisgICAgaWYgKCBvcHRfdmVyd19wdiA9PSAtMSApCisg
ICAgICAgIG9wdF92ZXJ3X3B2ID0gKChjcHVfaGFzX2J1Z19tZHMgfHwgY3B1
X2hhc19idWdfbXNiZHNfb25seSkgJiYKKyAgICAgICAgICAgICAgICAgICAg
ICAgY3B1X2hhc19tZF9jbGVhcik7CisKKyAgICBpZiAoIG9wdF92ZXJ3X2h2
bSA9PSAtMSApCisgICAgICAgIG9wdF92ZXJ3X2h2bSA9ICgoY3B1X2hhc19i
dWdfbWRzIHx8IGNwdV9oYXNfYnVnX21zYmRzX29ubHkpICYmCisgICAgICAg
ICAgICAgICAgICAgICAgICBjcHVfaGFzX21kX2NsZWFyKTsKIAogICAgIC8q
CiAgICAgICogRW5hYmxlIE1EUy9NTUlPIGRlZmVuY2VzIGFzIGFwcGxpY2Fi
bGUuICBUaGUgSWRsZSBibG9ja3MgbmVlZCB1c2luZyBpZgpAQCAtMTg2Mywx
MiArMTg2NSwxMiBAQCB2b2lkIF9faW5pdCBpbml0X3NwZWN1bGF0aW9uX21p
dGlnYXRpb25zKHZvaWQpCiAgICAgICogTURTIG1pdGlnYXRpb25zLiAgTDFE
X0ZMVVNIIGlzIG5vdCBzYWZlIGZvciBNTUlPIG1pdGlnYXRpb25zLikKICAg
ICAgKgogICAgICAqIEFmdGVyIGNhbGN1bGF0aW5nIHRoZSBhcHByb3ByaWF0
ZSBpZGxlIHNldHRpbmcsIHNpbXBsaWZ5Ci0gICAgICogb3B0X21kX2NsZWFy
X2h2bSB0byBtZWFuIGp1c3QgInNob3VsZCB3ZSBWRVJXIG9uIHRoZSB3YXkg
aW50byBIVk0KKyAgICAgKiBvcHRfdmVyd19odm0gdG8gbWVhbiBqdXN0ICJz
aG91bGQgd2UgVkVSVyBvbiB0aGUgd2F5IGludG8gSFZNCiAgICAgICogZ3Vl
c3RzIiwgc28gc3BlY19jdHJsX2luaXRfZG9tYWluKCkgY2FuIGNhbGN1bGF0
ZSBzdWl0YWJsZSBzZXR0aW5ncy4KICAgICAgKi8KLSAgICBpZiAoIG9wdF9t
ZF9jbGVhcl9wdiB8fCBvcHRfbWRfY2xlYXJfaHZtIHx8IG9wdF9mYl9jbGVh
cl9tbWlvICkKKyAgICBpZiAoIG9wdF92ZXJ3X3B2IHx8IG9wdF92ZXJ3X2h2
bSB8fCBvcHRfdmVyd19tbWlvICkKICAgICAgICAgc2V0dXBfZm9yY2VfY3B1
X2NhcChYODZfRkVBVFVSRV9TQ19WRVJXX0lETEUpOwotICAgIG9wdF9tZF9j
bGVhcl9odm0gJj0gIWNwdV9oYXNfc2tpcF9sMWRmbCAmJiAhb3B0X2wxZF9m
bHVzaDsKKyAgICBvcHRfdmVyd19odm0gJj0gIWNwdV9oYXNfc2tpcF9sMWRm
bCAmJiAhb3B0X2wxZF9mbHVzaDsKIAogICAgIC8qCiAgICAgICogV2FybiB0
aGUgdXNlciBpZiB0aGV5IGFyZSBvbiBNTFBEUy9NRkJEUy12dWxuZXJhYmxl
IGhhcmR3YXJlIHdpdGggSFQK

--=separator
Content-Type: application/octet-stream; name="xsa452/xsa452-4.16-6.patch"
Content-Disposition: attachment; filename="xsa452/xsa452-4.16-6.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L3NwZWMtY3RybDogVkVSVy1oYW5kbGluZyBhZGp1
c3RtZW50cwoKLi4uIGJlZm9yZSB3ZSBhZGQgeWV0IG1vcmUgY29tcGxleGl0
eSB0byB0aGlzIGxvZ2ljLiAgTW9zdGx5IGV4cGFuZGVkCmNvbW1lbnRzLCBi
dXQgd2l0aCB0aHJlZSBtaW5vciBjaGFuZ2VzLgoKMSkgSW50cm9kdWNlIGNw
dV9oYXNfdXNlZnVsX21kX2NsZWFyIHRvIHNpbXBsaWZ5IGxhdGVyIGxvZ2lj
IGluIHRoaXMgcGF0Y2ggYW5kCiAgIGZ1dHVyZSBvbmVzLgoKMikgV2Ugb25s
eSBldmVyIG5lZWQgU0NfVkVSV19JRExFIHdoZW4gU01UIGlzIGFjdGl2ZS4g
IElmIFNNVCBpc24ndCBhY3RpdmUsCiAgIHRoZW4gdGhlcmUncyBubyByZS1w
YXJ0aXRpb24gb2YgcGlwZWxpbmUgcmVzb3VyY2VzIGJhc2VkIG9uIHRocmVh
ZC1pZGxlbmVzcwogICB0byB3b3JyeSBhYm91dC4KCjMpIFRoZSBsb2dpYyB0
byBhZGp1c3QgSFZNIFZFUlcgYmFzZWQgb24gTDFEX0ZMVVNIIGlzIHVubWFp
bnRhaW5hYmxlIGFuZCwgYXMKICAgaXQgdHVybnMgb3V0LCB3cm9uZy4gIFNL
SVBfTDFERkwgaXMganVzdCBhIGhpbnQgYml0LCB3aGVyZWFzIG9wdF9sMWRf
Zmx1c2gKICAgaXMgdGhlIHJlbGV2YW50IGRlY2lzaW9uIG9mIHdoZXRoZXIg
dG8gdXNlIEwxRF9GTFVTSCBiYXNlZCBvbgogICBzdXNjZXB0aWJpbGl0eSBh
bmQgdXNlciBwcmVmZXJlbmNlLgoKICAgUmV3cml0ZSB0aGUgbG9naWMgc28g
aXQgY2FuIGJlIGZvbGxvd2VkLCBhbmQgaW5jb3Jwb3JhdGUgdGhlIGZhY3Qg
dGhhdCB3aGVuCiAgIEZCX0NMRUFSIGlzIHZpc2libGUsIEwxRF9GTFVTSCBp
c24ndCBhIHNhZmUgc3Vic3RpdHV0aW9uLgoKVGhpcyBpcyBwYXJ0IG9mIFhT
QS00NTIgLyBDVkUtMjAyMy0yODc0Ni4KClNpZ25lZC1vZmYtYnk6IEFuZHJl
dyBDb29wZXIgPGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+CkFja2VkLWJ5
OiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+CihjaGVycnkgcGlj
a2VkIGZyb20gY29tbWl0IDFlYjkxYThhMDYyMzBiNGI2NDIyOGM5YTM4MDE5
NGY4Y2ZlNmM1ZTIpCgpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L3NwZWNf
Y3RybC5jIGIveGVuL2FyY2gveDg2L3NwZWNfY3RybC5jCmluZGV4IDI5MmI1
YjFjN2JhMS4uMmU4MGUwODcxNjQyIDEwMDY0NAotLS0gYS94ZW4vYXJjaC94
ODYvc3BlY19jdHJsLmMKKysrIGIveGVuL2FyY2gveDg2L3NwZWNfY3RybC5j
CkBAIC0xNDk2LDcgKzE0OTYsNyBAQCB2b2lkIF9faW5pdCBpbml0X3NwZWN1
bGF0aW9uX21pdGlnYXRpb25zKHZvaWQpCiB7CiAgICAgZW51bSBpbmRfdGh1
bmsgdGh1bmsgPSBUSFVOS19ERUZBVUxUOwogICAgIGJvb2wgaGFzX3NwZWNf
Y3RybCwgaWJycyA9IGZhbHNlLCBod19zbXRfZW5hYmxlZDsKLSAgICBib29s
IGNwdV9oYXNfYnVnX3RhYSwgcmV0cG9saW5lX3NhZmU7CisgICAgYm9vbCBj
cHVfaGFzX2J1Z190YWEsIGNwdV9oYXNfdXNlZnVsX21kX2NsZWFyLCByZXRw
b2xpbmVfc2FmZTsKIAogICAgIGh3X3NtdF9lbmFibGVkID0gY2hlY2tfc210
X2VuYWJsZWQoKTsKIApAQCAtMTgyNyw1MCArMTgyNyw5NyBAQCB2b2lkIF9f
aW5pdCBpbml0X3NwZWN1bGF0aW9uX21pdGlnYXRpb25zKHZvaWQpCiAgICAg
ICAgICAgICAiZW5hYmxlZC4gIFBsZWFzZSBhc3Nlc3MgeW91ciBjb25maWd1
cmF0aW9uIGFuZCBjaG9vc2UgYW5cbiIKICAgICAgICAgICAgICJleHBsaWNp
dCAnc210PTxib29sPicgc2V0dGluZy4gIFNlZSBYU0EtMjczLlxuIik7CiAK
KyAgICAvKgorICAgICAqIEEgYnJpZWYgc3VtbWFyeSBvZiBWRVJXLXJlbGF0
ZWQgY2hhbmdlcy4KKyAgICAgKgorICAgICAqIGh0dHBzOi8vd3d3LmludGVs
LmNvbS9jb250ZW50L3d3dy91cy9lbi9kZXZlbG9wZXIvYXJ0aWNsZXMvdGVj
aG5pY2FsL3NvZnR3YXJlLXNlY3VyaXR5LWd1aWRhbmNlL3RlY2huaWNhbC1k
b2N1bWVudGF0aW9uL2ludGVsLWFuYWx5c2lzLW1pY3JvYXJjaGl0ZWN0dXJh
bC1kYXRhLXNhbXBsaW5nLmh0bWwKKyAgICAgKiBodHRwczovL3d3dy5pbnRl
bC5jb20vY29udGVudC93d3cvdXMvZW4vZGV2ZWxvcGVyL2FydGljbGVzL3Rl
Y2huaWNhbC9zb2Z0d2FyZS1zZWN1cml0eS1ndWlkYW5jZS90ZWNobmljYWwt
ZG9jdW1lbnRhdGlvbi9wcm9jZXNzb3ItbW1pby1zdGFsZS1kYXRhLXZ1bG5l
cmFiaWxpdGllcy5odG1sCisgICAgICoKKyAgICAgKiBSZWxldmFudCB1Y29k
ZXM6CisgICAgICoKKyAgICAgKiAtIE1heSAyMDE5LCBmb3IgTURTLiAgSW50
cm9kdWNlcyB0aGUgTURfQ0xFQVIgQ1BVSUQgYml0IGFuZCBWRVJXIHNpZGUK
KyAgICAgKiAgIGVmZmVjdHMgdG8gc2NydWIgU3RvcmUvTG9hZC9GaWxsIGJ1
ZmZlcnMgYXMgYXBwbGljYWJsZS4gIE1EX0NMRUFSCisgICAgICogICBleGlz
dHMgYXJjaGl0ZWN0dXJhbGx5LCBldmVuIHdoZW4gdGhlIHNpZGUgZWZmZWN0
cyBoYXZlIGJlZW4gcmVtb3ZlZC4KKyAgICAgKgorICAgICAqICAgVXNlIFZF
UlcgdG8gc2NydWIgb24gcmV0dXJuLXRvLWd1ZXN0LiAgUGFydHMgd2l0aCBM
MURfRkxVU0ggdG8KKyAgICAgKiAgIG1pdGlnYXRlIEwxVEYgaGF2ZSB0aGUg
c2FtZSBzaWRlIGVmZmVjdCwgc28gbm8gbmVlZCB0byBkbyBib3RoLgorICAg
ICAqCisgICAgICogICBWYXJpb3VzIEF0b21zIHN1ZmZlciBmcm9tIFN0b3Jl
LWJ1ZmZlciBzYW1wbGluZyBvbmx5LiAgU3RvcmUgYnVmZmVycworICAgICAq
ICAgYXJlIHN0YXRpY2FsbHkgcGFydGl0aW9uZWQgYmV0d2VlbiBub24taWRs
ZSB0aHJlYWRzLCBzbyBzY3J1YmJpbmcgaXMKKyAgICAgKiAgIHdhbnRlZCB3
aGVuIGdvaW5nIGlkbGUgdG9vLgorICAgICAqCisgICAgICogICBMb2FkIHBv
cnRzIGFuZCBGaWxsIGJ1ZmZlcnMgYXJlIGNvbXBldGl0aXZlbHkgc2hhcmVk
IGJldHdlZW4gdGhyZWFkcy4KKyAgICAgKiAgIFNNVCBtdXN0IGJlIGRpc2Fi
bGVkIGZvciBWRVJXIHNjcnViYmluZyB0byBiZSBmdWxseSBlZmZlY3RpdmUu
CisgICAgICoKKyAgICAgKiAtIE5vdmVtYmVyIDIwMTksIGZvciBUQUEuICBF
eHRlbmRlZCBWRVJXIHNpZGUgZWZmZWN0cyB0byBUU1gtZW5hYmxlZAorICAg
ICAqICAgTURTX05PIHBhcnRzLgorICAgICAqCisgICAgICogLSBGZWJydWFy
eSAyMDIyLCBmb3IgQ2xpZW50IFRTWCBkZS1mZWF0dXJlLiAgUmVtb3ZlZCBW
RVJXIHNpZGUgZWZmZWN0cworICAgICAqICAgZnJvbSBDbGllbnQgQ1BVcyBv
bmx5LgorICAgICAqCisgICAgICogLSBNYXkgMjAyMiwgZm9yIE1NSU8gU3Rh
bGUgRGF0YS4gIChSZSlpbnRyb2R1Y2VkIEZpbGwgQnVmZmVyIHNjcnViYmlu
ZworICAgICAqICAgb24gYWxsIE1NSU8tYWZmZWN0ZWQgcGFydHMgd2hpY2gg
ZGlkbid0IGFscmVhZHkgaGF2ZSBpdCBmb3IgTURTCisgICAgICogICByZWFz
b25zLCBlbnVtZXJhdGluZyBGQl9DTEVBUiBvbiB0aG9zZSBwYXJ0cyBvbmx5
LgorICAgICAqCisgICAgICogICBJZiBGQl9DTEVBUiBpcyBlbnVtZXJhdGVk
LCBMMURfRkxVU0ggZG9lcyBub3QgaGF2ZSB0aGUgc2FtZSBzY3J1YmJpbmcK
KyAgICAgKiAgIHNpZGUgZWZmZWN0cyBhcyBWRVJXIGFuZCBjYW5ub3QgYmUg
dXNlZCBpbiBpdHMgcGxhY2UuCisgICAgICovCiAgICAgbWRzX2NhbGN1bGF0
aW9ucygpOwogCiAgICAgLyoKLSAgICAgKiBQYXJ0cyB3aGljaCBlbnVtZXJh
dGUgRkJfQ0xFQVIgYXJlIHRob3NlIHdoaWNoIGFyZSBwb3N0LU1EU19OTyBh
bmQgaGF2ZQotICAgICAqIHJlaW50cm9kdWNlZCB0aGUgVkVSVyBmaWxsIGJ1
ZmZlciBmbHVzaGluZyBzaWRlIGVmZmVjdCBiZWNhdXNlIG9mIGEKLSAgICAg
KiBzdXNjZXB0aWJpbGl0eSB0byBGQlNEUC4KKyAgICAgKiBQYXJ0cyB3aGlj
aCBlbnVtZXJhdGUgRkJfQ0xFQVIgYXJlIHRob3NlIHdpdGggbm93LXVwZGF0
ZWQgbWljcm9jb2RlCisgICAgICogd2hpY2ggd2VyZW4ndCBzdXNjZXB0aWJs
ZSB0byB0aGUgb3JpZ2luYWwgTUZCRFMgKGFuZCB0aGVyZWZvcmUgZGlkbid0
CisgICAgICogaGF2ZSBGaWxsIEJ1ZmZlciBzY3J1YmJpbmcgc2lkZSBlZmZl
Y3RzIHRvIGJlZ2luIHdpdGgsIG9yIHdlcmUgQ2xpZW50CisgICAgICogTURT
X05PIG5vbi1UQUFfTk8gcGFydHMgd2hlcmUgdGhlIHNjcnViYmluZyB3YXMg
cmVtb3ZlZCksIGJ1dCBoYXZlIGhhZAorICAgICAqIHRoZSBzY3J1YmJpbmcg
cmVpbnRyb2R1Y2VkIGJlY2F1c2Ugb2YgYSBzdXNjZXB0aWJpbGl0eSB0byBG
QlNEUC4KICAgICAgKgogICAgICAqIElmIHVucHJpdmlsZWdlZCBndWVzdHMg
aGF2ZSAob3Igd2lsbCBoYXZlKSBNTUlPIG1hcHBpbmdzLCB3ZSBjYW4KICAg
ICAgKiBtaXRpZ2F0ZSBjcm9zcy1kb21haW4gbGVha2FnZSBvZiBmaWxsIGJ1
ZmZlciBkYXRhIGJ5IGlzc3VpbmcgVkVSVyBvbgotICAgICAqIHRoZSByZXR1
cm4tdG8tZ3Vlc3QgcGF0aC4KKyAgICAgKiB0aGUgcmV0dXJuLXRvLWd1ZXN0
IHBhdGguICBUaGlzIGlzIG9ubHkgYSB0b2tlbiBlZmZvcnQgaWYgU01UIGlz
CisgICAgICogYWN0aXZlLgogICAgICAqLwogICAgIGlmICggb3B0X3VucHJp
dl9tbWlvICkKICAgICAgICAgb3B0X3ZlcndfbW1pbyA9IGNwdV9oYXNfZmJf
Y2xlYXI7CiAKICAgICAvKgotICAgICAqIEJ5IGRlZmF1bHQsIGVuYWJsZSBQ
ViBhbmQgSFZNIG1pdGlnYXRpb25zIG9uIE1EUy12dWxuZXJhYmxlIGhhcmR3
YXJlLgotICAgICAqIFRoaXMgd2lsbCBvbmx5IGJlIGEgdG9rZW4gZWZmb3J0
IGZvciBNTFBEUy9NRkJEUyB3aGVuIEhUIGlzIGVuYWJsZWQsCi0gICAgICog
YnV0IGl0IGlzIHNvbWV3aGF0IGJldHRlciB0aGFuIG5vdGhpbmcuCisgICAg
ICogTURfQ0xFQVIgaXMgZW51bWVyYXRlZCBhcmNoaXRlY3R1cmFsbHkgZm9y
ZXZlcm1vcmUsIGV2ZW4gYWZ0ZXIgdGhlCisgICAgICogc2NydWJiaW5nIHNp
ZGUgZWZmZWN0cyBoYXZlIGJlZW4gcmVtb3ZlZC4gIENyZWF0ZSBvdXJzZWx2
ZXMgYW4gdmVyc2lvbgorICAgICAqIHdoaWNoIGV4cHJlc3NlZCB3aGV0aGVy
IHdlIHRoaW5rIE1EX0NMRUFSIGlzIGhhdmluZyBhbnkgdXNlZnVsIHNpZGUK
KyAgICAgKiBlZmZlY3QuCisgICAgICovCisgICAgY3B1X2hhc191c2VmdWxf
bWRfY2xlYXIgPSAoY3B1X2hhc19tZF9jbGVhciAmJgorICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIChjcHVfaGFzX2J1Z19tZHMgfHwgY3B1X2hh
c19idWdfbXNiZHNfb25seSkpOworCisgICAgLyoKKyAgICAgKiBCeSBkZWZh
dWx0LCB1c2UgVkVSVyBzY3J1YmJpbmcgb24gYXBwbGljYWJsZSBoYXJkd2Fy
ZSwgaWYgd2UgdGhpbmsgaXQncworICAgICAqIGdvaW5nIHRvIGhhdmUgYW4g
ZWZmZWN0LiAgVGhpcyB3aWxsIG9ubHkgYmUgYSB0b2tlbiBlZmZvcnQgZm9y
CisgICAgICogTUxQRFMvTUZCRFMgd2hlbiBTTVQgaXMgZW5hYmxlZC4KICAg
ICAgKi8KICAgICBpZiAoIG9wdF92ZXJ3X3B2ID09IC0xICkKLSAgICAgICAg
b3B0X3ZlcndfcHYgPSAoKGNwdV9oYXNfYnVnX21kcyB8fCBjcHVfaGFzX2J1
Z19tc2Jkc19vbmx5KSAmJgotICAgICAgICAgICAgICAgICAgICAgICBjcHVf
aGFzX21kX2NsZWFyKTsKKyAgICAgICAgb3B0X3ZlcndfcHYgPSBjcHVfaGFz
X3VzZWZ1bF9tZF9jbGVhcjsKIAogICAgIGlmICggb3B0X3ZlcndfaHZtID09
IC0xICkKLSAgICAgICAgb3B0X3ZlcndfaHZtID0gKChjcHVfaGFzX2J1Z19t
ZHMgfHwgY3B1X2hhc19idWdfbXNiZHNfb25seSkgJiYKLSAgICAgICAgICAg
ICAgICAgICAgICAgIGNwdV9oYXNfbWRfY2xlYXIpOworICAgICAgICBvcHRf
dmVyd19odm0gPSBjcHVfaGFzX3VzZWZ1bF9tZF9jbGVhcjsKIAogICAgIC8q
Ci0gICAgICogRW5hYmxlIE1EUy9NTUlPIGRlZmVuY2VzIGFzIGFwcGxpY2Fi
bGUuICBUaGUgSWRsZSBibG9ja3MgbmVlZCB1c2luZyBpZgotICAgICAqIGVp
dGhlciB0aGUgUFYgb3IgSFZNIE1EUyBkZWZlbmNlcyBhcmUgdXNlZCwgb3Ig
aWYgd2UgbWF5IGdpdmUgTU1JTwotICAgICAqIGFjY2VzcyB0byB1bnRydXN0
ZWQgZ3Vlc3RzLgotICAgICAqCi0gICAgICogSFZNIGlzIG1vcmUgY29tcGxp
Y2F0ZWQuICBUaGUgTURfQ0xFQVIgbWljcm9jb2RlIGV4dGVuZHMgTDFEX0ZM
VVNIIHdpdGgKLSAgICAgKiBlcXVpdmFsZW50IHNlbWFudGljcyB0byBhdm9p
ZCBuZWVkaW5nIHRvIHBlcmZvcm0gYm90aCBmbHVzaGVzIG9uIHRoZQotICAg
ICAqIEhWTSBwYXRoLiAgVGhlcmVmb3JlLCB3ZSBkb24ndCBuZWVkIFZFUlcg
aW4gYWRkaXRpb24gdG8gTDFEX0ZMVVNIIChmb3IKLSAgICAgKiBNRFMgbWl0
aWdhdGlvbnMuICBMMURfRkxVU0ggaXMgbm90IHNhZmUgZm9yIE1NSU8gbWl0
aWdhdGlvbnMuKQotICAgICAqCi0gICAgICogQWZ0ZXIgY2FsY3VsYXRpbmcg
dGhlIGFwcHJvcHJpYXRlIGlkbGUgc2V0dGluZywgc2ltcGxpZnkKLSAgICAg
KiBvcHRfdmVyd19odm0gdG8gbWVhbiBqdXN0ICJzaG91bGQgd2UgVkVSVyBv
biB0aGUgd2F5IGludG8gSFZNCi0gICAgICogZ3Vlc3RzIiwgc28gc3BlY19j
dHJsX2luaXRfZG9tYWluKCkgY2FuIGNhbGN1bGF0ZSBzdWl0YWJsZSBzZXR0
aW5ncy4KKyAgICAgKiBJZiBTTVQgaXMgYWN0aXZlLCBhbmQgd2UncmUgcHJv
dGVjdGluZyBhZ2FpbnN0IE1EUyBvciBNTUlPIHN0YWxlIGRhdGEsCisgICAg
ICogd2UgbmVlZCB0byBzY3J1YiBiZWZvcmUgZ29pbmcgaWRsZSBhcyB3ZWxs
IGFzIG9uIHJldHVybiB0byBndWVzdC4KKyAgICAgKiBWYXJpb3VzIHBpcGVs
aW5lIHJlc291cmNlcyBhcmUgcmVwYXJ0aXRpb25lZCBhbW9uZ3N0IG5vbi1p
ZGxlIHRocmVhZHMuCiAgICAgICovCi0gICAgaWYgKCBvcHRfdmVyd19wdiB8
fCBvcHRfdmVyd19odm0gfHwgb3B0X3ZlcndfbW1pbyApCisgICAgaWYgKCAo
KGNwdV9oYXNfdXNlZnVsX21kX2NsZWFyICYmIChvcHRfdmVyd19wdiB8fCBv
cHRfdmVyd19odm0pKSB8fAorICAgICAgICAgIG9wdF92ZXJ3X21taW8pICYm
IGh3X3NtdF9lbmFibGVkICkKICAgICAgICAgc2V0dXBfZm9yY2VfY3B1X2Nh
cChYODZfRkVBVFVSRV9TQ19WRVJXX0lETEUpOwotICAgIG9wdF92ZXJ3X2h2
bSAmPSAhY3B1X2hhc19za2lwX2wxZGZsICYmICFvcHRfbDFkX2ZsdXNoOwor
CisgICAgLyoKKyAgICAgKiBBZnRlciBjYWxjdWxhdGluZyB0aGUgYXBwcm9w
cmlhdGUgaWRsZSBzZXR0aW5nLCBzaW1wbGlmeSBvcHRfdmVyd19odm0KKyAg
ICAgKiB0byBtZWFuIGp1c3QgInNob3VsZCB3ZSBWRVJXIG9uIHRoZSB3YXkg
aW50byBIVk0gZ3Vlc3RzIiwgc28KKyAgICAgKiBzcGVjX2N0cmxfaW5pdF9k
b21haW4oKSBjYW4gY2FsY3VsYXRlIHN1aXRhYmxlIHNldHRpbmdzLgorICAg
ICAqCisgICAgICogSXQgaXMgb25seSBzYWZlIHRvIHVzZSBMMURfRkxVU0gg
aW4gcGxhY2Ugb2YgVkVSVyB3aGVuIE1EX0NMRUFSIGlzIHRoZQorICAgICAq
IG9ubHkgKl9DTEVBUiB3ZSBjYW4gc2VlLgorICAgICAqLworICAgIGlmICgg
b3B0X2wxZF9mbHVzaCAmJiBjcHVfaGFzX21kX2NsZWFyICYmICFjcHVfaGFz
X2ZiX2NsZWFyICkKKyAgICAgICAgb3B0X3ZlcndfaHZtID0gZmFsc2U7CiAK
ICAgICAvKgogICAgICAqIFdhcm4gdGhlIHVzZXIgaWYgdGhleSBhcmUgb24g
TUxQRFMvTUZCRFMtdnVsbmVyYWJsZSBoYXJkd2FyZSB3aXRoIEhUCg==

--=separator
Content-Type: application/octet-stream; name="xsa452/xsa452-4.16-7.patch"
Content-Disposition: attachment; filename="xsa452/xsa452-4.16-7.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L3NwZWMtY3RybDogTWl0aWdhdGlvbiBSZWdpc3Rl
ciBGaWxlIERhdGEgU2FtcGxpbmcKClJGRFMgYWZmZWN0cyBBdG9tIGNvcmVz
LCBhbHNvIGJyYW5kZWQgRS1jb3JlcywgYmV0d2VlbiB0aGUgR29sZG1vbnQg
YW5kCkdyYWNlbW9udCBtaWNyb2FyY2hpdGVjdHVyZXMuICBUaGlzIGluY2x1
ZGVzIEFsZGVyIExha2UgYW5kIFJhcHRvciBMYWtlIGh5YnJpZApjbGllbiBz
eXN0ZW1zIHdoaWNoIGhhdmUgYSBtaXggb2YgR3JhY2Vtb250IGFuZCBvdGhl
ciB0eXBlcyBvZiBjb3Jlcy4KClR3byBuZXcgYml0cyBoYXZlIGJlZW4gZGVm
aW5lZDsgUkZEU19DTEVBUiB0byBpbmRpY2F0ZSBWRVJXIGhhcyBtb3JlIHNp
ZGUKZWZmZXRzLCBhbmQgUkZEU19OTyB0byBpbmNpZGF0ZSB0aGF0IHRoZSBz
eXN0ZW0gaXMgdW5hZmZlY3RlZC4gIFBsZW50eSBvZgp1bmFmZmVjdGVkIENQ
VXMgd29uJ3QgYmUgZ2V0dGluZyBSRkRTX05PIHJldHJvZml0dGVkIGluIG1p
Y3JvY29kZSwgc28gd2UKc3ludGhlc2lzZSBpdC4gIEFsZGVyIExha2UgYW5k
IFJhcHRvciBMYWtlIFhlb24tRSdzIGFyZSB1bmFmZmVjdGVkIGR1ZSB0bwp0
aGVpciBwbGF0Zm9ybSBjb25maWd1cmF0aW9uLCBhbmQgd2UgbXVzdCB1c2Ug
dGhlIEh5YnJpZCBDUFVJRCBiaXQgdG8KZGlzdGluZ3Vpc2ggdGhlbSBmcm9t
IHRoZWlyIG5vbi1YZW9uIGNvdW50ZXJwYXJ0cy4KCkxpa2UgTURfQ0xFQVIg
YW5kIEZCX0NMRUFSLCBSRkRTX0NMRUFSIG5lZWRzIE9SLWluZyBhY3Jvc3Mg
YSByZXNvdXJjZSBwb29sLCBzbwpzZXQgaXQgaW4gdGhlIG1heCBwb2xpY2ll
cyBhbmQgcmVmbGVjdCB0aGUgaG9zdCBzZXR0aW5nIGluIGRlZmF1bHQuCgpU
aGlzIGlzIHBhcnQgb2YgWFNBLTQ1MiAvIENWRS0yMDIzLTI4NzQ2LgoKU2ln
bmVkLW9mZi1ieTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0
cml4LmNvbT4KUmV2aWV3ZWQtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBz
dXNlLmNvbT4KKGNoZXJyeSBwaWNrZWQgZnJvbSBjb21taXQgZmI1YjZmNjc0
NDcxMzQxMGM3NGNmYzEyYjcxNzZjMTA4ZTNjOWEzMSkKCmRpZmYgLS1naXQg
YS90b29scy9taXNjL3hlbi1jcHVpZC5jIGIvdG9vbHMvbWlzYy94ZW4tY3B1
aWQuYwppbmRleCBjNTVhNmU3Njc4MDkuLjBjNzkyNjc5ZTU5NCAxMDA2NDQK
LS0tIGEvdG9vbHMvbWlzYy94ZW4tY3B1aWQuYworKysgYi90b29scy9taXNj
L3hlbi1jcHVpZC5jCkBAIC0xNzAsNyArMTcwLDcgQEAgc3RhdGljIGNvbnN0
IGNoYXIgKmNvbnN0IHN0cl83ZDBbMzJdID0KICAgICBbIDhdID0gImF2eDUx
Mi12cDJpbnRlcnNlY3QiLCBbIDldID0gInNyYmRzLWN0cmwiLAogICAgIFsx
MF0gPSAibWQtY2xlYXIiLCAgICAgICAgICAgIFsxMV0gPSAicnRtLWFsd2F5
cy1hYm9ydCIsCiAgICAgLyogMTIgKi8gICAgICAgICAgICAgICAgWzEzXSA9
ICJ0c3gtZm9yY2UtYWJvcnQiLAotICAgIFsxNF0gPSAic2VyaWFsaXplIiwK
KyAgICBbMTRdID0gInNlcmlhbGl6ZSIsICAgICBbMTVdID0gImh5YnJpZCIs
CiAgICAgWzE2XSA9ICJ0c3hsZHRyayIsCiAgICAgWzE4XSA9ICJwY29uZmln
IiwKICAgICBbMjBdID0gImNldC1pYnQiLApAQCAtMjMwLDcgKzIzMCw4IEBA
IHN0YXRpYyBjb25zdCBjaGFyICpjb25zdCBzdHJfbTEwQWxbMzJdID0KICAg
ICBbMjBdID0gImJoaS1ubyIsICAgICAgICAgICAgICBbMjFdID0gInhhcGlj
LXN0YXR1cyIsCiAgICAgLyogMjIgKi8gICAgICAgICAgICAgICAgICAgICAg
WzIzXSA9ICJvdnJjbGstc3RhdHVzIiwKICAgICBbMjRdID0gInBicnNiLW5v
IiwgICAgICAgICAgICBbMjVdID0gImdkcy1jdHJsIiwKLSAgICBbMjZdID0g
Imdkcy1ubyIsCisgICAgWzI2XSA9ICJnZHMtbm8iLCAgICAgICAgICAgICAg
WzI3XSA9ICJyZmRzLW5vIiwKKyAgICBbMjhdID0gInJmZHMtY2xlYXIiLAog
fTsKIAogc3RhdGljIGNvbnN0IGNoYXIgKmNvbnN0IHN0cl9tMTBBaFszMl0g
PQpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2NwdS1wb2xpY3kuYyBiL3hl
bi9hcmNoL3g4Ni9jcHUtcG9saWN5LmMKaW5kZXggMzRmNzc4ZGJhZmJiLi5j
ODcyYWZkYTNlMmIgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9jcHUtcG9s
aWN5LmMKKysrIGIveGVuL2FyY2gveDg2L2NwdS1wb2xpY3kuYwpAQCAtNDQz
LDYgKzQ0Myw3IEBAIHN0YXRpYyB2b2lkIF9faW5pdCBndWVzdF9jb21tb25f
bWF4X2ZlYXR1cmVfYWRqdXN0bWVudHModWludDMyX3QgKmZzKQogICAgICAg
ICAgKi8KICAgICAgICAgX19zZXRfYml0KFg4Nl9GRUFUVVJFX01EX0NMRUFS
LCBmcyk7CiAgICAgICAgIF9fc2V0X2JpdChYODZfRkVBVFVSRV9GQl9DTEVB
UiwgZnMpOworICAgICAgICBfX3NldF9iaXQoWDg2X0ZFQVRVUkVfUkZEU19D
TEVBUiwgZnMpOwogCiAgICAgICAgIC8qCiAgICAgICAgICAqIFRoZSBHYXRo
ZXIgRGF0YSBTYW1wbGluZyBtaWNyb2NvZGUgbWl0aWdhdGlvbiAoQXVndXN0
IDIwMjMpIGhhcyBhbgpAQCAtNDkyLDYgKzQ5MywxMCBAQCBzdGF0aWMgdm9p
ZCBfX2luaXQgZ3Vlc3RfY29tbW9uX2RlZmF1bHRfZmVhdHVyZV9hZGp1c3Rt
ZW50cyh1aW50MzJfdCAqZnMpCiAgICAgICAgIGlmICggY3B1X2hhc19mYl9j
bGVhciApCiAgICAgICAgICAgICBfX3NldF9iaXQoWDg2X0ZFQVRVUkVfRkJf
Q0xFQVIsIGZzKTsKIAorICAgICAgICBfX2NsZWFyX2JpdChYODZfRkVBVFVS
RV9SRkRTX0NMRUFSLCBmcyk7CisgICAgICAgIGlmICggY3B1X2hhc19yZmRz
X2NsZWFyICkKKyAgICAgICAgICAgIF9fc2V0X2JpdChYODZfRkVBVFVSRV9S
RkRTX0NMRUFSLCBmcyk7CisKICAgICAgICAgLyoKICAgICAgICAgICogVGhl
IEdhdGhlciBEYXRhIFNhbXBsaW5nIG1pY3JvY29kZSBtaXRpZ2F0aW9uIChB
dWd1c3QgMjAyMykgaGFzIGFuCiAgICAgICAgICAqIGFkdmVyc2UgcGVyZm9y
bWFuY2UgaW1wYWN0IG9uIHRoZSBDTFdCIGluc3RydWN0aW9uIG9uIFNLWC9D
TFgvQ1BYLgpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L3NwZWNfY3RybC5j
IGIveGVuL2FyY2gveDg2L3NwZWNfY3RybC5jCmluZGV4IDJlODBlMDg3MTY0
Mi4uMjRiZjk4YTAxOGEwIDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYvc3Bl
Y19jdHJsLmMKKysrIGIveGVuL2FyY2gveDg2L3NwZWNfY3RybC5jCkBAIC00
MzIsNyArNDMyLDcgQEAgc3RhdGljIHZvaWQgX19pbml0IHByaW50X2RldGFp
bHMoZW51bSBpbmRfdGh1bmsgdGh1bmspCiAgICAgICogSGFyZHdhcmUgcmVh
ZC1vbmx5IGluZm9ybWF0aW9uLCBzdGF0aW5nIGltbXVuaXR5IHRvIGNlcnRh
aW4gaXNzdWVzLCBvcgogICAgICAqIHN1Z2dlc3Rpb25zIG9mIHdoaWNoIG1p
dGlnYXRpb24gdG8gdXNlLgogICAgICAqLwotICAgIHByaW50aygiICBIYXJk
d2FyZSBoaW50czolcyVzJXMlcyVzJXMlcyVzJXMlcyVzJXMlcyVzJXMlcyVz
JXMlcyVzJXMlc1xuIiwKKyAgICBwcmludGsoIiAgSGFyZHdhcmUgaGludHM6
JXMlcyVzJXMlcyVzJXMlcyVzJXMlcyVzJXMlcyVzJXMlcyVzJXMlcyVzJXMl
c1xuIiwKICAgICAgICAgICAgKGNhcHMgJiBBUkNIX0NBUFNfUkRDTF9OTykg
ICAgICAgICAgICAgICAgICAgICAgICA/ICIgUkRDTF9OTyIgICAgICAgIDog
IiIsCiAgICAgICAgICAgIChjYXBzICYgQVJDSF9DQVBTX0VJQlJTKSAgICAg
ICAgICAgICAgICAgICAgICAgICAgPyAiIEVJQlJTIiAgICAgICAgICA6ICIi
LAogICAgICAgICAgICAoY2FwcyAmIEFSQ0hfQ0FQU19SU0JBKSAgICAgICAg
ICAgICAgICAgICAgICAgICAgID8gIiBSU0JBIiAgICAgICAgICAgOiAiIiwK
QEAgLTQ0OCw2ICs0NDgsNyBAQCBzdGF0aWMgdm9pZCBfX2luaXQgcHJpbnRf
ZGV0YWlscyhlbnVtIGluZF90aHVuayB0aHVuaykKICAgICAgICAgICAgKGNh
cHMgJiBBUkNIX0NBUFNfRkJfQ0xFQVIpICAgICAgICAgICAgICAgICAgICAg
ICA/ICIgRkJfQ0xFQVIiICAgICAgIDogIiIsCiAgICAgICAgICAgIChjYXBz
ICYgQVJDSF9DQVBTX1BCUlNCX05PKSAgICAgICAgICAgICAgICAgICAgICAg
PyAiIFBCUlNCX05PIiAgICAgICA6ICIiLAogICAgICAgICAgICAoY2FwcyAm
IEFSQ0hfQ0FQU19HRFNfTk8pICAgICAgICAgICAgICAgICAgICAgICAgID8g
IiBHRFNfTk8iICAgICAgICAgOiAiIiwKKyAgICAgICAgICAgKGNhcHMgJiBB
UkNIX0NBUFNfUkZEU19OTykgICAgICAgICAgICAgICAgICAgICAgICA/ICIg
UkZEU19OTyIgICAgICAgIDogIiIsCiAgICAgICAgICAgIChlOGIgICYgY3B1
ZmVhdF9tYXNrKFg4Nl9GRUFUVVJFX0lCUlNfQUxXQVlTKSkgICAgPyAiIElC
UlNfQUxXQVlTIiAgICA6ICIiLAogICAgICAgICAgICAoZThiICAmIGNwdWZl
YXRfbWFzayhYODZfRkVBVFVSRV9TVElCUF9BTFdBWVMpKSAgID8gIiBTVElC
UF9BTFdBWVMiICAgOiAiIiwKICAgICAgICAgICAgKGU4YiAgJiBjcHVmZWF0
X21hc2soWDg2X0ZFQVRVUkVfSUJSU19GQVNUKSkgICAgICA/ICIgSUJSU19G
QVNUIiAgICAgIDogIiIsCkBAIC00NTgsNyArNDU5LDcgQEAgc3RhdGljIHZv
aWQgX19pbml0IHByaW50X2RldGFpbHMoZW51bSBpbmRfdGh1bmsgdGh1bmsp
CiAgICAgICAgICAgIChlMjFhICYgY3B1ZmVhdF9tYXNrKFg4Nl9GRUFUVVJF
X1NSU09fTk8pKSAgICAgICAgPyAiIFNSU09fTk8iICAgICAgICA6ICIiKTsK
IAogICAgIC8qIEhhcmR3YXJlIGZlYXR1cmVzIHdoaWNoIG5lZWQgZHJpdmlu
ZyB0byBtaXRpZ2F0ZSBpc3N1ZXMuICovCi0gICAgcHJpbnRrKCIgIEhhcmR3
YXJlIGZlYXR1cmVzOiVzJXMlcyVzJXMlcyVzJXMlcyVzJXMlcyVzXG4iLAor
ICAgIHByaW50aygiICBIYXJkd2FyZSBmZWF0dXJlczolcyVzJXMlcyVzJXMl
cyVzJXMlcyVzJXMlcyVzXG4iLAogICAgICAgICAgICAoZThiICAmIGNwdWZl
YXRfbWFzayhYODZfRkVBVFVSRV9JQlBCKSkgfHwKICAgICAgICAgICAgKF83
ZDAgJiBjcHVmZWF0X21hc2soWDg2X0ZFQVRVUkVfSUJSU0IpKSAgICAgICAg
ICA/ICIgSUJQQiIgICAgICAgICAgIDogIiIsCiAgICAgICAgICAgIChlOGIg
ICYgY3B1ZmVhdF9tYXNrKFg4Nl9GRUFUVVJFX0lCUlMpKSB8fApAQCAtNDc2
LDYgKzQ3Nyw3IEBAIHN0YXRpYyB2b2lkIF9faW5pdCBwcmludF9kZXRhaWxz
KGVudW0gaW5kX3RodW5rIHRodW5rKQogICAgICAgICAgICAoY2FwcyAmIEFS
Q0hfQ0FQU19UU1hfQ1RSTCkgICAgICAgICAgICAgICAgICAgICAgID8gIiBU
U1hfQ1RSTCIgICAgICAgOiAiIiwKICAgICAgICAgICAgKGNhcHMgJiBBUkNI
X0NBUFNfRkJfQ0xFQVJfQ1RSTCkgICAgICAgICAgICAgICAgICA/ICIgRkJf
Q0xFQVJfQ1RSTCIgIDogIiIsCiAgICAgICAgICAgIChjYXBzICYgQVJDSF9D
QVBTX0dEU19DVFJMKSAgICAgICAgICAgICAgICAgICAgICAgPyAiIEdEU19D
VFJMIiAgICAgICA6ICIiLAorICAgICAgICAgICAoY2FwcyAmIEFSQ0hfQ0FQ
U19SRkRTX0NMRUFSKSAgICAgICAgICAgICAgICAgICAgID8gIiBSRkRTX0NM
RUFSIiAgICAgOiAiIiwKICAgICAgICAgICAgKGUyMWEgJiBjcHVmZWF0X21h
c2soWDg2X0ZFQVRVUkVfU0JQQikpICAgICAgICAgICA/ICIgU0JQQiIgICAg
ICAgICAgIDogIiIpOwogCiAgICAgLyogQ29tcGlsZWQtaW4gc3VwcG9ydCB3
aGljaCBwZXJ0YWlucyB0byBtaXRpZ2F0aW9ucy4gKi8KQEAgLTEzMjQsNiAr
MTMyNiw4MyBAQCBzdGF0aWMgX19pbml0IHZvaWQgbWRzX2NhbGN1bGF0aW9u
cyh2b2lkKQogICAgIH0KIH0KIAorLyoKKyAqIFJlZ2lzdGVyIEZpbGUgRGF0
YSBTYW1wbGluZyBhZmZlY3RzIEF0b20gY29yZXMgZnJvbSB0aGUgR29sZG1v
bnQgdG8KKyAqIEdyYWNlbW9udCBtaWNyb2FyY2hpdGVjdHVyZXMuICBUaGUg
TWFyY2ggMjAyNCBtaWNyb2NvZGUgYWRkcyBSRkRTX05PIHRvCisgKiBzb21l
IGJ1dCBub3QgYWxsIHVuYWZmZWN0ZWQgcGFydHMsIGFuZCBSRkRTX0NMRUFS
IHRvIGFmZmVjdGVkIHBhcnRzIHN0aWxsCisgKiBpbiBzdXBwb3J0LgorICoK
KyAqIEFsZGVyIExha2UgYW5kIFJhcHRvciBMYWtlIGNsaWVudCBDUFVzIGhh
dmUgYSBtaXggb2YgUCBjb3JlcworICogKEdvbGRlbi9SYXB0b3IgQ292ZSwg
bm90IHZ1bG5lcmFibGUpIGFuZCBFIGNvcmVzIChHcmFjZW1vbnQsCisgKiB2
dWxuZXJhYmxlKSwgYW5kIGJvdGggZW51bWVyYXRlIFJGRFNfQ0xFQVIuCisg
KgorICogQm90aCBleGlzdCBpbiBhIFhlb24gU0tVLCB3aGljaCBoYXMgdGhl
IEUgY29yZXMgKEdyYWNlbW9udCkgZGlzYWJsZWQgYnkKKyAqIHBsYXRmb3Jt
IGNvbmZpZ3VyYXRpb24sIGFuZCBlbnVtZXJhdGUgUkZEU19OTy4KKyAqCisg
KiBXaXRoIG9sZGVyIHBhcnRzLCBvciB3aXRoIG91dC1vZi1kYXRlIG1pY3Jv
Y29kZSwgc3ludGhlc2lzZSBSRkRTX05PIHdoZW4KKyAqIHNhZmUgdG8gZG8g
c28uCisgKgorICogaHR0cHM6Ly93d3cuaW50ZWwuY29tL2NvbnRlbnQvd3d3
L3VzL2VuL2RldmVsb3Blci9hcnRpY2xlcy90ZWNobmljYWwvc29mdHdhcmUt
c2VjdXJpdHktZ3VpZGFuY2UvYWR2aXNvcnktZ3VpZGFuY2UvcmVnaXN0ZXIt
ZmlsZS1kYXRhLXNhbXBsaW5nLmh0bWwKKyAqLworc3RhdGljIHZvaWQgX19p
bml0IHJmZHNfY2FsY3VsYXRpb25zKHZvaWQpCit7CisgICAgLyogUkZEUyBp
cyBvbmx5IGtub3duIHRvIGFmZmVjdCBJbnRlbCBGYW1pbHkgNiBwcm9jZXNz
b3JzIGF0IHRoaXMgdGltZS4gKi8KKyAgICBpZiAoIGJvb3RfY3B1X2RhdGEu
eDg2X3ZlbmRvciAhPSBYODZfVkVORE9SX0lOVEVMIHx8CisgICAgICAgICBi
b290X2NwdV9kYXRhLng4NiAhPSA2ICkKKyAgICAgICAgcmV0dXJuOworCisg
ICAgLyoKKyAgICAgKiBJZiBSRkRTX05PIG9yIFJGRFNfQ0xFQVIgYXJlIHZp
c2libGUsIHdlJ3ZlIGVpdGhlciBnb3Qgc3VpdGFibGUKKyAgICAgKiBtaWNy
b2NvZGUsIG9yIGFuIFJGRFMtYXdhcmUgaHlwZXJ2aXNvciBpcyBsZXZlbGxp
bmcgdXMgaW4gYSBwb29sLgorICAgICAqLworICAgIGlmICggY3B1X2hhc19y
ZmRzX25vIHx8IGNwdV9oYXNfcmZkc19jbGVhciApCisgICAgICAgIHJldHVy
bjsKKworICAgIC8qIElmIHdlJ3JlIHZpcnR1YWxpc2VkLCBkb24ndCBhdHRl
bXB0IHRvIHN5bnRoZXNpc2UgUkZEU19OTy4gKi8KKyAgICBpZiAoIGNwdV9o
YXNfaHlwZXJ2aXNvciApCisgICAgICAgIHJldHVybjsKKworICAgIC8qCisg
ICAgICogTm90IGFsbCBDUFVzIGFyZSBleHBlY3RlZCB0byBnZXQgYSBtaWNy
b2NvZGUgdXBkYXRlIGVudW1lcmF0aW5nIG9uZSBvZgorICAgICAqIFJGRFNf
e05PLENMRUFSfSwgb3Igd2UgbWlnaHQgaGF2ZSBvdXQtb2YtZGF0ZSBtaWNy
b2NvZGUuCisgICAgICovCisgICAgc3dpdGNoICggYm9vdF9jcHVfZGF0YS54
ODZfbW9kZWwgKQorICAgIHsKKyAgICBjYXNlIDB4OTc6IC8qIElOVEVMX0ZB
TTZfQUxERVJMQUtFICovCisgICAgY2FzZSAweEI3OiAvKiBJTlRFTF9GQU02
X1JBUFRPUkxBS0UgKi8KKyAgICAgICAgLyoKKyAgICAgICAgICogQWxkZXIg
TGFrZSBhbmQgUmFwdG9yIExha2UgbWlnaHQgYmUgYSBjbGllbnQgU0tVICh3
aXRoIHRoZQorICAgICAgICAgKiBHcmFjZW1vbnQgY29yZXMgYWN0aXZlLCBh
bmQgdGhlcmVmb3JlIHZ1bG5lcmFibGUpIG9yIG1pZ2h0IGJlIGEKKyAgICAg
ICAgICogc2VydmVyIFNLVSAod2l0aCB0aGUgR3JhY2Vtb250IGNvcmVzIGRp
c2FibGVkLCBhbmQgdGhlcmVmb3JlIG5vdAorICAgICAgICAgKiB2dWxuZXJh
YmxlKS4KKyAgICAgICAgICoKKyAgICAgICAgICogU2VlIGlmIHRoZSBDUFUg
aWRlbnRpZmllcyBhcyBoeWJyaWQgdG8gZGlzdGluZ3Vpc2ggdGhlIHR3byBj
YXNlcy4KKyAgICAgICAgICovCisgICAgICAgIGlmICggIWNwdV9oYXNfaHli
cmlkICkKKyAgICAgICAgICAgIGJyZWFrOworICAgICAgICAvKiBmYWxsdGhy
b3VnaCAqLworICAgIGNhc2UgMHg5QTogLyogSU5URUxfRkFNNl9BTERFUkxB
S0VfTCAqLworICAgIGNhc2UgMHhCQTogLyogSU5URUxfRkFNNl9SQVBUT1JM
QUtFX1AgKi8KKyAgICBjYXNlIDB4QkY6IC8qIElOVEVMX0ZBTTZfUkFQVE9S
TEFLRV9TICovCisKKyAgICBjYXNlIDB4NUM6IC8qIElOVEVMX0ZBTTZfQVRP
TV9HT0xETU9OVCAqLyAgICAgIC8qIEFwb2xsbyBMYWtlICovCisgICAgY2Fz
ZSAweDVGOiAvKiBJTlRFTF9GQU02X0FUT01fR09MRE1PTlRfRCAqLyAgICAv
KiBEZW52ZXJ0b24gKi8KKyAgICBjYXNlIDB4N0E6IC8qIElOVEVMX0ZBTTZf
QVRPTV9HT0xETU9OVF9QTFVTICovIC8qIEdlbWluaSBMYWtlICovCisgICAg
Y2FzZSAweDg2OiAvKiBJTlRFTF9GQU02X0FUT01fVFJFTU9OVF9EICovICAg
ICAvKiBTbm93IFJpZGdlIC8gUGFya2VyIFJpZGdlICovCisgICAgY2FzZSAw
eDk2OiAvKiBJTlRFTF9GQU02X0FUT01fVFJFTU9OVCAqLyAgICAgICAvKiBF
bGtoYXJ0IExha2UgKi8KKyAgICBjYXNlIDB4OUM6IC8qIElOVEVMX0ZBTTZf
QVRPTV9UUkVNT05UX0wgKi8gICAgIC8qIEphc3BlciBMYWtlICovCisgICAg
Y2FzZSAweEJFOiAvKiBJTlRFTF9GQU02X0FUT01fR1JBQ0VNT05UICovICAg
ICAvKiBBbGRlciBMYWtlIE4gKi8KKyAgICAgICAgcmV0dXJuOworICAgIH0K
KworICAgIC8qCisgICAgICogV2UgYXBwZWFyIHRvIGJlIG9uIGFuIHVuYWZm
ZWN0ZWQgQ1BVIHdoaWNoIGRpZG4ndCBlbnVtZXJhdGUgUkZEU19OTywKKyAg
ICAgKiBwZXJoYXBzIGJlY2F1c2Ugb2YgaXQncyBhZ2Ugb3IgYmVjYXVzZSBv
ZiBvdXQtb2YtZGF0ZSBtaWNyb2NvZGUuCisgICAgICogU3ludGhlc2lzZSBp
dC4KKyAgICAgKi8KKyAgICBzZXR1cF9mb3JjZV9jcHVfY2FwKFg4Nl9GRUFU
VVJFX1JGRFNfTk8pOworfQorCiBzdGF0aWMgYm9vbCBfX2luaXQgY3B1X2hh
c19nZHModm9pZCkKIHsKICAgICAvKgpAQCAtMTgzMiw2ICsxOTExLDcgQEAg
dm9pZCBfX2luaXQgaW5pdF9zcGVjdWxhdGlvbl9taXRpZ2F0aW9ucyh2b2lk
KQogICAgICAqCiAgICAgICogaHR0cHM6Ly93d3cuaW50ZWwuY29tL2NvbnRl
bnQvd3d3L3VzL2VuL2RldmVsb3Blci9hcnRpY2xlcy90ZWNobmljYWwvc29m
dHdhcmUtc2VjdXJpdHktZ3VpZGFuY2UvdGVjaG5pY2FsLWRvY3VtZW50YXRp
b24vaW50ZWwtYW5hbHlzaXMtbWljcm9hcmNoaXRlY3R1cmFsLWRhdGEtc2Ft
cGxpbmcuaHRtbAogICAgICAqIGh0dHBzOi8vd3d3LmludGVsLmNvbS9jb250
ZW50L3d3dy91cy9lbi9kZXZlbG9wZXIvYXJ0aWNsZXMvdGVjaG5pY2FsL3Nv
ZnR3YXJlLXNlY3VyaXR5LWd1aWRhbmNlL3RlY2huaWNhbC1kb2N1bWVudGF0
aW9uL3Byb2Nlc3Nvci1tbWlvLXN0YWxlLWRhdGEtdnVsbmVyYWJpbGl0aWVz
Lmh0bWwKKyAgICAgKiBodHRwczovL3d3dy5pbnRlbC5jb20vY29udGVudC93
d3cvdXMvZW4vZGV2ZWxvcGVyL2FydGljbGVzL3RlY2huaWNhbC9zb2Z0d2Fy
ZS1zZWN1cml0eS1ndWlkYW5jZS9hZHZpc29yeS1ndWlkYW5jZS9yZWdpc3Rl
ci1maWxlLWRhdGEtc2FtcGxpbmcuaHRtbAogICAgICAqCiAgICAgICogUmVs
ZXZhbnQgdWNvZGVzOgogICAgICAqCkBAIC0xODYxLDggKzE5NDEsMTIgQEAg
dm9pZCBfX2luaXQgaW5pdF9zcGVjdWxhdGlvbl9taXRpZ2F0aW9ucyh2b2lk
KQogICAgICAqCiAgICAgICogICBJZiBGQl9DTEVBUiBpcyBlbnVtZXJhdGVk
LCBMMURfRkxVU0ggZG9lcyBub3QgaGF2ZSB0aGUgc2FtZSBzY3J1YmJpbmcK
ICAgICAgKiAgIHNpZGUgZWZmZWN0cyBhcyBWRVJXIGFuZCBjYW5ub3QgYmUg
dXNlZCBpbiBpdHMgcGxhY2UuCisgICAgICoKKyAgICAgKiAtIE1hcmNoIDIw
MjMsIGZvciBSRkRTLiAgRW51bWVyYXRlIFJGRFNfQ0xFQVIgdG8gbWVhbiB0
aGF0IFZFUlcgbm93CisgICAgICogICBzY3J1YnMgbm9uLWFyY2hpdGVjdHVy
YWwgZW50cmllcyBmcm9tIGNlcnRhaW4gcmVnaXN0ZXIgZmlsZXMuCiAgICAg
ICovCiAgICAgbWRzX2NhbGN1bGF0aW9ucygpOworICAgIHJmZHNfY2FsY3Vs
YXRpb25zKCk7CiAKICAgICAvKgogICAgICAqIFBhcnRzIHdoaWNoIGVudW1l
cmF0ZSBGQl9DTEVBUiBhcmUgdGhvc2Ugd2l0aCBub3ctdXBkYXRlZCBtaWNy
b2NvZGUKQEAgLTE4OTQsMTUgKzE5NzgsMTkgQEAgdm9pZCBfX2luaXQgaW5p
dF9zcGVjdWxhdGlvbl9taXRpZ2F0aW9ucyh2b2lkKQogICAgICAqIE1MUERT
L01GQkRTIHdoZW4gU01UIGlzIGVuYWJsZWQuCiAgICAgICovCiAgICAgaWYg
KCBvcHRfdmVyd19wdiA9PSAtMSApCi0gICAgICAgIG9wdF92ZXJ3X3B2ID0g
Y3B1X2hhc191c2VmdWxfbWRfY2xlYXI7CisgICAgICAgIG9wdF92ZXJ3X3B2
ID0gY3B1X2hhc191c2VmdWxfbWRfY2xlYXIgfHwgY3B1X2hhc19yZmRzX2Ns
ZWFyOwogCiAgICAgaWYgKCBvcHRfdmVyd19odm0gPT0gLTEgKQotICAgICAg
ICBvcHRfdmVyd19odm0gPSBjcHVfaGFzX3VzZWZ1bF9tZF9jbGVhcjsKKyAg
ICAgICAgb3B0X3ZlcndfaHZtID0gY3B1X2hhc191c2VmdWxfbWRfY2xlYXIg
fHwgY3B1X2hhc19yZmRzX2NsZWFyOwogCiAgICAgLyoKICAgICAgKiBJZiBT
TVQgaXMgYWN0aXZlLCBhbmQgd2UncmUgcHJvdGVjdGluZyBhZ2FpbnN0IE1E
UyBvciBNTUlPIHN0YWxlIGRhdGEsCiAgICAgICogd2UgbmVlZCB0byBzY3J1
YiBiZWZvcmUgZ29pbmcgaWRsZSBhcyB3ZWxsIGFzIG9uIHJldHVybiB0byBn
dWVzdC4KICAgICAgKiBWYXJpb3VzIHBpcGVsaW5lIHJlc291cmNlcyBhcmUg
cmVwYXJ0aXRpb25lZCBhbW9uZ3N0IG5vbi1pZGxlIHRocmVhZHMuCisgICAg
ICoKKyAgICAgKiBXZSBkb24ndCBuZWVkIHRvIHNjcnViIG9uIGlkbGUgZm9y
IFJGRFMuICBUaGVyZSBhcmUgbm8gYWZmZWN0ZWQgY29yZXMKKyAgICAgKiB3
aGljaCBzdXBwb3J0IFNNVCwgZGVzcGl0ZSB0aGVyZSBiZWluZyBhZmZlY3Rl
ZCBjb3JlcyBpbiBoeWJyaWQgc3lzdGVtcworICAgICAqIHdoaWNoIGhhdmUg
U01UIGVsc2V3aGVyZSBpbiB0aGUgcGxhdGZvcm0uCiAgICAgICovCiAgICAg
aWYgKCAoKGNwdV9oYXNfdXNlZnVsX21kX2NsZWFyICYmIChvcHRfdmVyd19w
diB8fCBvcHRfdmVyd19odm0pKSB8fAogICAgICAgICAgIG9wdF92ZXJ3X21t
aW8pICYmIGh3X3NtdF9lbmFibGVkICkKQEAgLTE5MTYsNyArMjAwNCw4IEBA
IHZvaWQgX19pbml0IGluaXRfc3BlY3VsYXRpb25fbWl0aWdhdGlvbnModm9p
ZCkKICAgICAgKiBJdCBpcyBvbmx5IHNhZmUgdG8gdXNlIEwxRF9GTFVTSCBp
biBwbGFjZSBvZiBWRVJXIHdoZW4gTURfQ0xFQVIgaXMgdGhlCiAgICAgICog
b25seSAqX0NMRUFSIHdlIGNhbiBzZWUuCiAgICAgICovCi0gICAgaWYgKCBv
cHRfbDFkX2ZsdXNoICYmIGNwdV9oYXNfbWRfY2xlYXIgJiYgIWNwdV9oYXNf
ZmJfY2xlYXIgKQorICAgIGlmICggb3B0X2wxZF9mbHVzaCAmJiBjcHVfaGFz
X21kX2NsZWFyICYmICFjcHVfaGFzX2ZiX2NsZWFyICYmCisgICAgICAgICAh
Y3B1X2hhc19yZmRzX2NsZWFyICkKICAgICAgICAgb3B0X3ZlcndfaHZtID0g
ZmFsc2U7CiAKICAgICAvKgpkaWZmIC0tZ2l0IGEveGVuL2luY2x1ZGUvYXNt
LXg4Ni9jcHVmZWF0dXJlLmggYi94ZW4vaW5jbHVkZS9hc20teDg2L2NwdWZl
YXR1cmUuaAppbmRleCA4MWFjNGQ3NmVlYTYuLjE4Njk3MzJiY2I5YiAxMDA2
NDQKLS0tIGEveGVuL2luY2x1ZGUvYXNtLXg4Ni9jcHVmZWF0dXJlLmgKKysr
IGIveGVuL2luY2x1ZGUvYXNtLXg4Ni9jcHVmZWF0dXJlLmgKQEAgLTEzOCw2
ICsxMzgsNyBAQAogI2RlZmluZSBjcHVfaGFzX3J0bV9hbHdheXNfYWJvcnQg
Ym9vdF9jcHVfaGFzKFg4Nl9GRUFUVVJFX1JUTV9BTFdBWVNfQUJPUlQpCiAj
ZGVmaW5lIGNwdV9oYXNfdHN4X2ZvcmNlX2Fib3J0IGJvb3RfY3B1X2hhcyhY
ODZfRkVBVFVSRV9UU1hfRk9SQ0VfQUJPUlQpCiAjZGVmaW5lIGNwdV9oYXNf
c2VyaWFsaXplICAgICAgIGJvb3RfY3B1X2hhcyhYODZfRkVBVFVSRV9TRVJJ
QUxJWkUpCisjZGVmaW5lIGNwdV9oYXNfaHlicmlkICAgICAgICAgIGJvb3Rf
Y3B1X2hhcyhYODZfRkVBVFVSRV9IWUJSSUQpCiAjZGVmaW5lIGNwdV9oYXNf
YXJjaF9jYXBzICAgICAgIGJvb3RfY3B1X2hhcyhYODZfRkVBVFVSRV9BUkNI
X0NBUFMpCiAKIC8qIENQVUlEIGxldmVsIDB4MDAwMDAwMDc6MS5lYXggKi8K
QEAgLTE1Nyw2ICsxNTgsOCBAQAogI2RlZmluZSBjcHVfaGFzX3Jyc2JhICAg
ICAgICAgICBib290X2NwdV9oYXMoWDg2X0ZFQVRVUkVfUlJTQkEpCiAjZGVm
aW5lIGNwdV9oYXNfZ2RzX2N0cmwgICAgICAgIGJvb3RfY3B1X2hhcyhYODZf
RkVBVFVSRV9HRFNfQ1RSTCkKICNkZWZpbmUgY3B1X2hhc19nZHNfbm8gICAg
ICAgICAgYm9vdF9jcHVfaGFzKFg4Nl9GRUFUVVJFX0dEU19OTykKKyNkZWZp
bmUgY3B1X2hhc19yZmRzX25vICAgICAgICAgYm9vdF9jcHVfaGFzKFg4Nl9G
RUFUVVJFX1JGRFNfTk8pCisjZGVmaW5lIGNwdV9oYXNfcmZkc19jbGVhciAg
ICAgIGJvb3RfY3B1X2hhcyhYODZfRkVBVFVSRV9SRkRTX0NMRUFSKQogCiAv
KiBTeW50aGVzaXplZC4gKi8KICNkZWZpbmUgY3B1X2hhc19hcmNoX3BlcmZt
b24gICAgYm9vdF9jcHVfaGFzKFg4Nl9GRUFUVVJFX0FSQ0hfUEVSRk1PTikK
ZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL2FzbS14ODYvbXNyLWluZGV4Lmgg
Yi94ZW4vaW5jbHVkZS9hc20teDg2L21zci1pbmRleC5oCmluZGV4IDgyNTFi
ODI1OGI3OS4uZWI2Mjk1ZDhhN2E0IDEwMDY0NAotLS0gYS94ZW4vaW5jbHVk
ZS9hc20teDg2L21zci1pbmRleC5oCisrKyBiL3hlbi9pbmNsdWRlL2FzbS14
ODYvbXNyLWluZGV4LmgKQEAgLTc3LDYgKzc3LDggQEAKICNkZWZpbmUgIEFS
Q0hfQ0FQU19QQlJTQl9OTyAgICAgICAgICAgICAgICAgKF9BQygxLCBVTEwp
IDw8IDI0KQogI2RlZmluZSAgQVJDSF9DQVBTX0dEU19DVFJMICAgICAgICAg
ICAgICAgICAoX0FDKDEsIFVMTCkgPDwgMjUpCiAjZGVmaW5lICBBUkNIX0NB
UFNfR0RTX05PICAgICAgICAgICAgICAgICAgIChfQUMoMSwgVUxMKSA8PCAy
NikKKyNkZWZpbmUgIEFSQ0hfQ0FQU19SRkRTX05PICAgICAgICAgICAgICAg
ICAgKF9BQygxLCBVTEwpIDw8IDI3KQorI2RlZmluZSAgQVJDSF9DQVBTX1JG
RFNfQ0xFQVIgICAgICAgICAgICAgICAoX0FDKDEsIFVMTCkgPDwgMjgpCiAK
ICNkZWZpbmUgTVNSX0ZMVVNIX0NNRCAgICAgICAgICAgICAgICAgICAgICAg
MHgwMDAwMDEwYgogI2RlZmluZSAgRkxVU0hfQ01EX0wxRCAgICAgICAgICAg
ICAgICAgICAgICAoX0FDKDEsIFVMTCkgPDwgIDApCmRpZmYgLS1naXQgYS94
ZW4vaW5jbHVkZS9wdWJsaWMvYXJjaC14ODYvY3B1ZmVhdHVyZXNldC5oIGIv
eGVuL2luY2x1ZGUvcHVibGljL2FyY2gteDg2L2NwdWZlYXR1cmVzZXQuaApp
bmRleCAyOTA2ZWFhNmMyOTAuLjdhOWQ4ZDA1ZDNmYiAxMDA2NDQKLS0tIGEv
eGVuL2luY2x1ZGUvcHVibGljL2FyY2gteDg2L2NwdWZlYXR1cmVzZXQuaAor
KysgYi94ZW4vaW5jbHVkZS9wdWJsaWMvYXJjaC14ODYvY3B1ZmVhdHVyZXNl
dC5oCkBAIC0yNzksNiArMjc5LDcgQEAgWEVOX0NQVUZFQVRVUkUoTURfQ0xF
QVIsICAgICAgOSozMisxMCkgLyohQSBWRVJXIGNsZWFycyBtaWNyb2FyY2hp
dGVjdHVyYWwgYnVmZmUKIFhFTl9DUFVGRUFUVVJFKFJUTV9BTFdBWVNfQUJP
UlQsIDkqMzIrMTEpIC8qISBKdW5lIDIwMjEgVFNYIGRlZmVhdHVyaW5nIGlu
IG1pY3JvY29kZS4gKi8KIFhFTl9DUFVGRUFUVVJFKFRTWF9GT1JDRV9BQk9S
VCwgOSozMisxMykgLyogTVNSX1RTWF9GT1JDRV9BQk9SVC5SVE1fQUJPUlQg
Ki8KIFhFTl9DUFVGRUFUVVJFKFNFUklBTElaRSwgICAgIDkqMzIrMTQpIC8q
YSAgU0VSSUFMSVpFIGluc24gKi8KK1hFTl9DUFVGRUFUVVJFKEhZQlJJRCwg
ICAgICAgIDkqMzIrMTUpIC8qICAgSGV0ZXJvZ2VuZW91cyBwbGF0Zm9ybSAq
LwogWEVOX0NQVUZFQVRVUkUoVFNYTERUUkssICAgICAgOSozMisxNikgLyph
ICBUU1ggbG9hZCB0cmFja2luZyBzdXNwZW5kL3Jlc3VtZSBpbnNucyAqLwog
WEVOX0NQVUZFQVRVUkUoQ0VUX0lCVCwgICAgICAgOSozMisyMCkgLyogICBD
RVQgLSBJbmRpcmVjdCBCcmFuY2ggVHJhY2tpbmcgKi8KIFhFTl9DUFVGRUFU
VVJFKElCUlNCLCAgICAgICAgIDkqMzIrMjYpIC8qQSAgSUJSUyBhbmQgSUJQ
QiBzdXBwb3J0ICh1c2VkIGJ5IEludGVsKSAqLwpAQCAtMzM4LDYgKzMzOSw4
IEBAIFhFTl9DUFVGRUFUVVJFKE9WUkNMS19TVEFUVVMsICAgICAgMTYqMzIr
MjMpIC8qICAgTVNSX09WRVJDTE9DS0lOR19TVEFUVVMgKi8KIFhFTl9DUFVG
RUFUVVJFKFBCUlNCX05PLCAgICAgICAgICAgMTYqMzIrMjQpIC8qQSAgTm8g
UG9zdC1CYXJyaWVyIFJTQiBwcmVkaWN0aW9ucyAqLwogWEVOX0NQVUZFQVRV
UkUoR0RTX0NUUkwsICAgICAgICAgICAxNiozMisyNSkgLyogICBNQ1VfT1BU
X0NUUkwuR0RTX01JVF97RElTLExPQ0t9ICovCiBYRU5fQ1BVRkVBVFVSRShH
RFNfTk8sICAgICAgICAgICAgIDE2KjMyKzI2KSAvKkEgIE5vIEdhdGhlciBE
YXRhIFNhbXBsaW5nICovCitYRU5fQ1BVRkVBVFVSRShSRkRTX05PLCAgICAg
ICAgICAgIDE2KjMyKzI3KSAvKkEgIE5vIFJlZ2lzdGVyIEZpbGUgRGF0YSBT
YW1wbGluZyAqLworWEVOX0NQVUZFQVRVUkUoUkZEU19DTEVBUiwgICAgICAg
ICAxNiozMisyOCkgLyohQSBSZWdpc3RlciBGaWxlKHMpIGNsZWFyZWQgYnkg
VkVSVyAqLwogCiAvKiBJbnRlbC1kZWZpbmVkIENQVSBmZWF0dXJlcywgTVNS
X0FSQ0hfQ0FQUyAweDEwYS5lZHgsIHdvcmQgMTcgKi8KIAo=

--=separator
Content-Type: application/octet-stream; name="xsa452/xsa452-4.17-1.patch"
Content-Disposition: attachment; filename="xsa452/xsa452-4.17-1.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L2VudHJ5OiBJbnRyb2R1Y2UgRUZSQU1FXyogY29u
c3RhbnRzCgpyZXN0b3JlX2FsbF9ndWVzdCgpIGRvZXMgYSBsb3Qgb2YgbWFu
aXB1bGF0aW9uIG9mIHRoZSBzdGFjayBhZnRlciBwb3BwaW5nIHRoZQpHUFJz
LCBhbmQgdXNlcyByYXcgJXJzcCBkaXNwbGFjZW1lbnRzIHRvIGRvIHNvLiAg
QWxzbywgYWxtb3N0IGFsbCBlbnRyeXBhdGhzCnVzZSByYXcgJXJzcCBkaXNw
bGFjZW1lbnRzIHByaW9yIHRvIHB1c2hpbmcgR1BScy4KClByb3ZpZGUgYmV0
dGVyIG1uZW1vbmljcywgdG8gYWlkIHJlYWRhYmlsaXR5IGFuZCByZWR1Y2Ug
dGhlIGNoYW5jZSBvZiBlcnJvcnMKd2hlbiBlZGl0aW5nLgoKTm8gZnVuY3Rp
b25hbCBjaGFuZ2UuICBUaGUgcmVzdWx0aW5nIGJpbmFyeSBpcyBpZGVudGlj
YWwuCgpTaWduZWQtb2ZmLWJ5OiBBbmRyZXcgQ29vcGVyIDxhbmRyZXcuY29v
cGVyM0BjaXRyaXguY29tPgpSZXZpZXdlZC1ieTogSmFuIEJldWxpY2ggPGpi
ZXVsaWNoQHN1c2UuY29tPgooY2hlcnJ5IHBpY2tlZCBmcm9tIGNvbW1pdCAz
NzU0MTIwOGYxMTlhOWM1NTJjNmM2YzMyNDZlYTYxYmUwZDQ0MDM1KQoKZGlm
ZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni94ODZfNjQvYXNtLW9mZnNldHMuYyBi
L3hlbi9hcmNoL3g4Ni94ODZfNjQvYXNtLW9mZnNldHMuYwppbmRleCAyODdk
YWMxMDFhZDQuLjMxZmE2M2I3N2ZkMSAxMDA2NDQKLS0tIGEveGVuL2FyY2gv
eDg2L3g4Nl82NC9hc20tb2Zmc2V0cy5jCisrKyBiL3hlbi9hcmNoL3g4Ni94
ODZfNjQvYXNtLW9mZnNldHMuYwpAQCAtNTEsNiArNTEsMjMgQEAgdm9pZCBf
X2R1bW15X18odm9pZCkKICAgICBPRkZTRVQoVVJFR1Nfa2VybmVsX3NpemVv
Ziwgc3RydWN0IGNwdV91c2VyX3JlZ3MsIGVzKTsKICAgICBCTEFOSygpOwog
CisgICAgLyoKKyAgICAgKiBFRlJBTUVfKiBpcyBmb3IgdGhlIGVudHJ5L2V4
aXQgbG9naWMgd2hlcmUgJXJzcCBpcyBwb2ludGluZyBhdAorICAgICAqIFVS
RUdTX2Vycm9yX2NvZGUgYW5kIEdQUnMgYXJlIHN0aWxsL2FscmVhZHkgZ3Vl
c3QgdmFsdWVzLgorICAgICAqLworI2RlZmluZSBPRkZTRVRfRUYoc3ltLCBt
ZW0pICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgXAorICAgIERFRklORShzeW0sIG9mZnNldG9mKHN0cnVjdCBjcHVfdXNl
cl9yZWdzLCBtZW0pIC0gICAgICAgICAgICAgICAgICAgXAorICAgICAgICAg
ICAgICAgIG9mZnNldG9mKHN0cnVjdCBjcHVfdXNlcl9yZWdzLCBlcnJvcl9j
b2RlKSkKKworICAgIE9GRlNFVF9FRihFRlJBTUVfZW50cnlfdmVjdG9yLCAg
ICBlbnRyeV92ZWN0b3IpOworICAgIE9GRlNFVF9FRihFRlJBTUVfcmlwLCAg
ICAgICAgICAgICByaXApOworICAgIE9GRlNFVF9FRihFRlJBTUVfY3MsICAg
ICAgICAgICAgICBjcyk7CisgICAgT0ZGU0VUX0VGKEVGUkFNRV9lZmxhZ3Ms
ICAgICAgICAgIGVmbGFncyk7CisgICAgT0ZGU0VUX0VGKEVGUkFNRV9yc3As
ICAgICAgICAgICAgIHJzcCk7CisgICAgQkxBTksoKTsKKworI3VuZGVmIE9G
RlNFVF9FRgorCiAgICAgT0ZGU0VUKFZDUFVfcHJvY2Vzc29yLCBzdHJ1Y3Qg
dmNwdSwgcHJvY2Vzc29yKTsKICAgICBPRkZTRVQoVkNQVV9kb21haW4sIHN0
cnVjdCB2Y3B1LCBkb21haW4pOwogICAgIE9GRlNFVChWQ1BVX3ZjcHVfaW5m
bywgc3RydWN0IHZjcHUsIHZjcHVfaW5mbyk7CmRpZmYgLS1naXQgYS94ZW4v
YXJjaC94ODYveDg2XzY0L2NvbXBhdC9lbnRyeS5TIGIveGVuL2FyY2gveDg2
L3g4Nl82NC9jb21wYXQvZW50cnkuUwppbmRleCAyNTNiYjE2ODhjNGYuLjdj
MjExMzE0ZDg4NSAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L3g4Nl82NC9j
b21wYXQvZW50cnkuUworKysgYi94ZW4vYXJjaC94ODYveDg2XzY0L2NvbXBh
dC9lbnRyeS5TCkBAIC0xNSw3ICsxNSw3IEBAIEVOVFJZKGVudHJ5X2ludDgy
KQogICAgICAgICBFTkRCUjY0CiAgICAgICAgIEFMVEVSTkFUSVZFICIiLCBj
bGFjLCBYODZfRkVBVFVSRV9YRU5fU01BUAogICAgICAgICBwdXNocSAkMAot
ICAgICAgICBtb3ZsICAkSFlQRVJDQUxMX1ZFQ1RPUiwgNCglcnNwKQorICAg
ICAgICBtb3ZsICAkSFlQRVJDQUxMX1ZFQ1RPUiwgRUZSQU1FX2VudHJ5X3Zl
Y3RvciglcnNwKQogICAgICAgICBTQVZFX0FMTCBjb21wYXQ9MSAvKiBEUEwx
IGdhdGUsIHJlc3RyaWN0ZWQgdG8gMzJiaXQgUFYgZ3Vlc3RzIG9ubHkuICov
CiAKICAgICAgICAgU1BFQ19DVFJMX0VOVFJZX0ZST01fUFYgLyogUmVxOiAl
cnNwPXJlZ3MvY3B1aW5mbywgJXJkeD0wLCBDbG9iOiBhY2QgKi8KZGlmZiAt
LWdpdCBhL3hlbi9hcmNoL3g4Ni94ODZfNjQvZW50cnkuUyBiL3hlbi9hcmNo
L3g4Ni94ODZfNjQvZW50cnkuUwppbmRleCA1ODViMGM5NTUxOTEuLjQxMmNi
ZWIzZWNhNCAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L3g4Nl82NC9lbnRy
eS5TCisrKyBiL3hlbi9hcmNoL3g4Ni94ODZfNjQvZW50cnkuUwpAQCAtMTkw
LDE1ICsxOTAsMTUgQEAgcmVzdG9yZV9hbGxfZ3Vlc3Q6CiAgICAgICAgIFNQ
RUNfQ1RSTF9FWElUX1RPX1BWICAgIC8qIFJlcTogYT1zcGVjX2N0cmwgJXJz
cD1yZWdzL2NwdWluZm8sIENsb2I6IGNkICovCiAKICAgICAgICAgUkVTVE9S
RV9BTEwKLSAgICAgICAgdGVzdHcgJFRSQVBfc3lzY2FsbCw0KCVyc3ApCisg
ICAgICAgIHRlc3R3ICRUUkFQX3N5c2NhbGwsIEVGUkFNRV9lbnRyeV92ZWN0
b3IoJXJzcCkKICAgICAgICAganogICAgaXJldF9leGl0X3RvX2d1ZXN0CiAK
LSAgICAgICAgbW92cSAgMjQoJXJzcCksJXIxMSAgICAgICAgICAgIyBSRkxB
R1MKKyAgICAgICAgbW92ICAgRUZSQU1FX2VmbGFncyglcnNwKSwgJXIxMQog
ICAgICAgICBhbmRxICAkfihYODZfRUZMQUdTX0lPUEwgfCBYODZfRUZMQUdT
X1ZNKSwgJXIxMQogICAgICAgICBvcnEgICAkWDg2X0VGTEFHU19JRiwlcjEx
CiAKICAgICAgICAgLyogRG9uJ3QgdXNlIFNZU1JFVCBwYXRoIGlmIHRoZSBy
ZXR1cm4gYWRkcmVzcyBpcyBub3QgY2Fub25pY2FsLiAqLwotICAgICAgICBt
b3ZxICA4KCVyc3ApLCVyY3gKKyAgICAgICAgbW92ICAgRUZSQU1FX3JpcCgl
cnNwKSwgJXJjeAogICAgICAgICBzYXJxICAkNDcsJXJjeAogICAgICAgICBp
bmNsICAlZWN4CiAgICAgICAgIGNtcGwgICQxLCVlY3gKQEAgLTIxMywyMCAr
MjEzLDIwIEBAIHJlc3RvcmVfYWxsX2d1ZXN0OgogICAgICAgICBBTFRFUk5B
VElWRSAiIiwgcmFnX2NscnNzYnN5LCBYODZfRkVBVFVSRV9YRU5fU0hTVEsK
ICNlbmRpZgogCi0gICAgICAgIG1vdnEgIDgoJXJzcCksICVyY3ggICAgICAg
ICAgICMgUklQCi0gICAgICAgIGNtcHcgICRGTEFUX1VTRVJfQ1MzMiwxNigl
cnNwKSMgQ1MKLSAgICAgICAgbW92cSAgMzIoJXJzcCksJXJzcCAgICAgICAg
ICAgIyBSU1AKKyAgICAgICAgbW92ICAgRUZSQU1FX3JpcCglcnNwKSwgJXJj
eAorICAgICAgICBjbXB3ICAkRkxBVF9VU0VSX0NTMzIsIEVGUkFNRV9jcygl
cnNwKQorICAgICAgICBtb3YgICBFRlJBTUVfcnNwKCVyc3ApLCAlcnNwCiAg
ICAgICAgIGplICAgIDFmCiAgICAgICAgIHN5c3JldHEKIDE6ICAgICAgc3lz
cmV0bAogCiAgICAgICAgIEFMSUdOCiAuTHJlc3RvcmVfcmN4X2lyZXRfZXhp
dF90b19ndWVzdDoKLSAgICAgICAgbW92cSAgOCglcnNwKSwgJXJjeCAgICAg
ICAgICAgIyBSSVAKKyAgICAgICAgbW92ICAgRUZSQU1FX3JpcCglcnNwKSwg
JXJjeAogLyogTm8gc3BlY2lhbCByZWdpc3RlciBhc3N1bXB0aW9ucy4gKi8K
IGlyZXRfZXhpdF90b19ndWVzdDoKLSAgICAgICAgYW5kbCAgJH4oWDg2X0VG
TEFHU19JT1BMIHwgWDg2X0VGTEFHU19WTSksIDI0KCVyc3ApCi0gICAgICAg
IG9ybCAgICRYODZfRUZMQUdTX0lGLDI0KCVyc3ApCisgICAgICAgIGFuZGwg
ICR+KFg4Nl9FRkxBR1NfSU9QTCB8IFg4Nl9FRkxBR1NfVk0pLCBFRlJBTUVf
ZWZsYWdzKCVyc3ApCisgICAgICAgIG9ybCAgICRYODZfRUZMQUdTX0lGLCBF
RlJBTUVfZWZsYWdzKCVyc3ApCiAgICAgICAgIGFkZHEgICQ4LCVyc3AKIC5M
ZnQwOiAgaXJldHEKICAgICAgICAgX0FTTV9QUkVfRVhUQUJMRSguTGZ0MCwg
aGFuZGxlX2V4Y2VwdGlvbikKQEAgLTI1Nyw3ICsyNTcsNyBAQCBFTlRSWShs
c3Rhcl9lbnRlcikKICAgICAgICAgcHVzaHEgJEZMQVRfS0VSTkVMX0NTNjQK
ICAgICAgICAgcHVzaHEgJXJjeAogICAgICAgICBwdXNocSAkMAotICAgICAg
ICBtb3ZsICAkVFJBUF9zeXNjYWxsLCA0KCVyc3ApCisgICAgICAgIG1vdmwg
ICRUUkFQX3N5c2NhbGwsIEVGUkFNRV9lbnRyeV92ZWN0b3IoJXJzcCkKICAg
ICAgICAgU0FWRV9BTEwKIAogICAgICAgICBTUEVDX0NUUkxfRU5UUllfRlJP
TV9QViAvKiBSZXE6ICVyc3A9cmVncy9jcHVpbmZvLCAlcmR4PTAsIENsb2I6
IGFjZCAqLwpAQCAtMjk0LDcgKzI5NCw3IEBAIEVOVFJZKGNzdGFyX2VudGVy
KQogICAgICAgICBwdXNocSAkRkxBVF9VU0VSX0NTMzIKICAgICAgICAgcHVz
aHEgJXJjeAogICAgICAgICBwdXNocSAkMAotICAgICAgICBtb3ZsICAkVFJB
UF9zeXNjYWxsLCA0KCVyc3ApCisgICAgICAgIG1vdmwgICRUUkFQX3N5c2Nh
bGwsIEVGUkFNRV9lbnRyeV92ZWN0b3IoJXJzcCkKICAgICAgICAgU0FWRV9B
TEwKIAogICAgICAgICBTUEVDX0NUUkxfRU5UUllfRlJPTV9QViAvKiBSZXE6
ICVyc3A9cmVncy9jcHVpbmZvLCAlcmR4PTAsIENsb2I6IGFjZCAqLwpAQCAt
MzM1LDcgKzMzNSw3IEBAIEdMT0JBTChzeXNlbnRlcl9lZmxhZ3Nfc2F2ZWQp
CiAgICAgICAgIHB1c2hxICQzIC8qIHJpbmcgMyBudWxsIGNzICovCiAgICAg
ICAgIHB1c2hxICQwIC8qIG51bGwgcmlwICovCiAgICAgICAgIHB1c2hxICQw
Ci0gICAgICAgIG1vdmwgICRUUkFQX3N5c2NhbGwsIDQoJXJzcCkKKyAgICAg
ICAgbW92bCAgJFRSQVBfc3lzY2FsbCwgRUZSQU1FX2VudHJ5X3ZlY3Rvcigl
cnNwKQogICAgICAgICBTQVZFX0FMTAogCiAgICAgICAgIFNQRUNfQ1RSTF9F
TlRSWV9GUk9NX1BWIC8qIFJlcTogJXJzcD1yZWdzL2NwdWluZm8sICVyZHg9
MCwgQ2xvYjogYWNkICovCkBAIC0zODksNyArMzg5LDcgQEAgRU5UUlkoaW50
ODBfZGlyZWN0X3RyYXApCiAgICAgICAgIEVOREJSNjQKICAgICAgICAgQUxU
RVJOQVRJVkUgIiIsIGNsYWMsIFg4Nl9GRUFUVVJFX1hFTl9TTUFQCiAgICAg
ICAgIHB1c2hxICQwCi0gICAgICAgIG1vdmwgICQweDgwLCA0KCVyc3ApCisg
ICAgICAgIG1vdmwgICQweDgwLCBFRlJBTUVfZW50cnlfdmVjdG9yKCVyc3Ap
CiAgICAgICAgIFNBVkVfQUxMCiAKICAgICAgICAgU1BFQ19DVFJMX0VOVFJZ
X0ZST01fUFYgLyogUmVxOiAlcnNwPXJlZ3MvY3B1aW5mbywgJXJkeD0wLCBD
bG9iOiBhY2QgKi8KQEAgLTY0OSw3ICs2NDksNyBAQCByZXRfZnJvbV9pbnRy
OgogICAgICAgICAuc2VjdGlvbiAuaW5pdC50ZXh0LCAiYXgiLCBAcHJvZ2Jp
dHMKIEVOVFJZKGVhcmx5X3BhZ2VfZmF1bHQpCiAgICAgICAgIEVOREJSNjQK
LSAgICAgICAgbW92bCAgJFRSQVBfcGFnZV9mYXVsdCwgNCglcnNwKQorICAg
ICAgICBtb3ZsICAkVFJBUF9wYWdlX2ZhdWx0LCBFRlJBTUVfZW50cnlfdmVj
dG9yKCVyc3ApCiAgICAgICAgIFNBVkVfQUxMCiAgICAgICAgIG1vdnEgICVy
c3AsICVyZGkKICAgICAgICAgY2FsbCAgZG9fZWFybHlfcGFnZV9mYXVsdApA
QCAtNzE2LDcgKzcxNiw3IEBAIEVOVFJZKGNvbW1vbl9pbnRlcnJ1cHQpCiAK
IEVOVFJZKHBhZ2VfZmF1bHQpCiAgICAgICAgIEVOREJSNjQKLSAgICAgICAg
bW92bCAgJFRSQVBfcGFnZV9mYXVsdCw0KCVyc3ApCisgICAgICAgIG1vdmwg
ICRUUkFQX3BhZ2VfZmF1bHQsIEVGUkFNRV9lbnRyeV92ZWN0b3IoJXJzcCkK
IC8qIE5vIHNwZWNpYWwgcmVnaXN0ZXIgYXNzdW1wdGlvbnMuICovCiBHTE9C
QUwoaGFuZGxlX2V4Y2VwdGlvbikKICAgICAgICAgQUxURVJOQVRJVkUgIiIs
IGNsYWMsIFg4Nl9GRUFUVVJFX1hFTl9TTUFQCkBAIC04OTIsOTAgKzg5Miw5
MCBAQCBGQVRBTF9leGNlcHRpb25fd2l0aF9pbnRzX2Rpc2FibGVkOgogRU5U
UlkoZGl2aWRlX2Vycm9yKQogICAgICAgICBFTkRCUjY0CiAgICAgICAgIHB1
c2hxICQwCi0gICAgICAgIG1vdmwgICRUUkFQX2RpdmlkZV9lcnJvciw0KCVy
c3ApCisgICAgICAgIG1vdmwgICRUUkFQX2RpdmlkZV9lcnJvciwgRUZSQU1F
X2VudHJ5X3ZlY3RvciglcnNwKQogICAgICAgICBqbXAgICBoYW5kbGVfZXhj
ZXB0aW9uCiAKIEVOVFJZKGNvcHJvY2Vzc29yX2Vycm9yKQogICAgICAgICBF
TkRCUjY0CiAgICAgICAgIHB1c2hxICQwCi0gICAgICAgIG1vdmwgICRUUkFQ
X2NvcHJvX2Vycm9yLDQoJXJzcCkKKyAgICAgICAgbW92bCAgJFRSQVBfY29w
cm9fZXJyb3IsIEVGUkFNRV9lbnRyeV92ZWN0b3IoJXJzcCkKICAgICAgICAg
am1wICAgaGFuZGxlX2V4Y2VwdGlvbgogCiBFTlRSWShzaW1kX2NvcHJvY2Vz
c29yX2Vycm9yKQogICAgICAgICBFTkRCUjY0CiAgICAgICAgIHB1c2hxICQw
Ci0gICAgICAgIG1vdmwgICRUUkFQX3NpbWRfZXJyb3IsNCglcnNwKQorICAg
ICAgICBtb3ZsICAkVFJBUF9zaW1kX2Vycm9yLCBFRlJBTUVfZW50cnlfdmVj
dG9yKCVyc3ApCiAgICAgICAgIGptcCAgIGhhbmRsZV9leGNlcHRpb24KIAog
RU5UUlkoZGV2aWNlX25vdF9hdmFpbGFibGUpCiAgICAgICAgIEVOREJSNjQK
ICAgICAgICAgcHVzaHEgJDAKLSAgICAgICAgbW92bCAgJFRSQVBfbm9fZGV2
aWNlLDQoJXJzcCkKKyAgICAgICAgbW92bCAgJFRSQVBfbm9fZGV2aWNlLCBF
RlJBTUVfZW50cnlfdmVjdG9yKCVyc3ApCiAgICAgICAgIGptcCAgIGhhbmRs
ZV9leGNlcHRpb24KIAogRU5UUlkoZGVidWcpCiAgICAgICAgIEVOREJSNjQK
ICAgICAgICAgcHVzaHEgJDAKLSAgICAgICAgbW92bCAgJFRSQVBfZGVidWcs
NCglcnNwKQorICAgICAgICBtb3ZsICAkVFJBUF9kZWJ1ZywgRUZSQU1FX2Vu
dHJ5X3ZlY3RvciglcnNwKQogICAgICAgICBqbXAgICBoYW5kbGVfaXN0X2V4
Y2VwdGlvbgogCiBFTlRSWShpbnQzKQogICAgICAgICBFTkRCUjY0CiAgICAg
ICAgIHB1c2hxICQwCi0gICAgICAgIG1vdmwgICRUUkFQX2ludDMsNCglcnNw
KQorICAgICAgICBtb3ZsICAkVFJBUF9pbnQzLCBFRlJBTUVfZW50cnlfdmVj
dG9yKCVyc3ApCiAgICAgICAgIGptcCAgIGhhbmRsZV9leGNlcHRpb24KIAog
RU5UUlkob3ZlcmZsb3cpCiAgICAgICAgIEVOREJSNjQKICAgICAgICAgcHVz
aHEgJDAKLSAgICAgICAgbW92bCAgJFRSQVBfb3ZlcmZsb3csNCglcnNwKQor
ICAgICAgICBtb3ZsICAkVFJBUF9vdmVyZmxvdywgRUZSQU1FX2VudHJ5X3Zl
Y3RvciglcnNwKQogICAgICAgICBqbXAgICBoYW5kbGVfZXhjZXB0aW9uCiAK
IEVOVFJZKGJvdW5kcykKICAgICAgICAgRU5EQlI2NAogICAgICAgICBwdXNo
cSAkMAotICAgICAgICBtb3ZsICAkVFJBUF9ib3VuZHMsNCglcnNwKQorICAg
ICAgICBtb3ZsICAkVFJBUF9ib3VuZHMsIEVGUkFNRV9lbnRyeV92ZWN0b3Io
JXJzcCkKICAgICAgICAgam1wICAgaGFuZGxlX2V4Y2VwdGlvbgogCiBFTlRS
WShpbnZhbGlkX29wKQogICAgICAgICBFTkRCUjY0CiAgICAgICAgIHB1c2hx
ICQwCi0gICAgICAgIG1vdmwgICRUUkFQX2ludmFsaWRfb3AsNCglcnNwKQor
ICAgICAgICBtb3ZsICAkVFJBUF9pbnZhbGlkX29wLCBFRlJBTUVfZW50cnlf
dmVjdG9yKCVyc3ApCiAgICAgICAgIGptcCAgIGhhbmRsZV9leGNlcHRpb24K
IAogRU5UUlkoaW52YWxpZF9UU1MpCiAgICAgICAgIEVOREJSNjQKLSAgICAg
ICAgbW92bCAgJFRSQVBfaW52YWxpZF90c3MsNCglcnNwKQorICAgICAgICBt
b3ZsICAkVFJBUF9pbnZhbGlkX3RzcywgRUZSQU1FX2VudHJ5X3ZlY3Rvcigl
cnNwKQogICAgICAgICBqbXAgICBoYW5kbGVfZXhjZXB0aW9uCiAKIEVOVFJZ
KHNlZ21lbnRfbm90X3ByZXNlbnQpCiAgICAgICAgIEVOREJSNjQKLSAgICAg
ICAgbW92bCAgJFRSQVBfbm9fc2VnbWVudCw0KCVyc3ApCisgICAgICAgIG1v
dmwgICRUUkFQX25vX3NlZ21lbnQsIEVGUkFNRV9lbnRyeV92ZWN0b3IoJXJz
cCkKICAgICAgICAgam1wICAgaGFuZGxlX2V4Y2VwdGlvbgogCiBFTlRSWShz
dGFja19zZWdtZW50KQogICAgICAgICBFTkRCUjY0Ci0gICAgICAgIG1vdmwg
ICRUUkFQX3N0YWNrX2Vycm9yLDQoJXJzcCkKKyAgICAgICAgbW92bCAgJFRS
QVBfc3RhY2tfZXJyb3IsIEVGUkFNRV9lbnRyeV92ZWN0b3IoJXJzcCkKICAg
ICAgICAgam1wICAgaGFuZGxlX2V4Y2VwdGlvbgogCiBFTlRSWShnZW5lcmFs
X3Byb3RlY3Rpb24pCiAgICAgICAgIEVOREJSNjQKLSAgICAgICAgbW92bCAg
JFRSQVBfZ3BfZmF1bHQsNCglcnNwKQorICAgICAgICBtb3ZsICAkVFJBUF9n
cF9mYXVsdCwgRUZSQU1FX2VudHJ5X3ZlY3RvciglcnNwKQogICAgICAgICBq
bXAgICBoYW5kbGVfZXhjZXB0aW9uCiAKIEVOVFJZKGFsaWdubWVudF9jaGVj
aykKICAgICAgICAgRU5EQlI2NAotICAgICAgICBtb3ZsICAkVFJBUF9hbGln
bm1lbnRfY2hlY2ssNCglcnNwKQorICAgICAgICBtb3ZsICAkVFJBUF9hbGln
bm1lbnRfY2hlY2ssIEVGUkFNRV9lbnRyeV92ZWN0b3IoJXJzcCkKICAgICAg
ICAgam1wICAgaGFuZGxlX2V4Y2VwdGlvbgogCiBFTlRSWShlbnRyeV9DUCkK
ICAgICAgICAgRU5EQlI2NAotICAgICAgICBtb3ZsICAkWDg2X0VYQ19DUCwg
NCglcnNwKQorICAgICAgICBtb3ZsICAkWDg2X0VYQ19DUCwgRUZSQU1FX2Vu
dHJ5X3ZlY3RvciglcnNwKQogICAgICAgICBqbXAgICBoYW5kbGVfZXhjZXB0
aW9uCiAKIEVOVFJZKGRvdWJsZV9mYXVsdCkKICAgICAgICAgRU5EQlI2NAot
ICAgICAgICBtb3ZsICAkVFJBUF9kb3VibGVfZmF1bHQsNCglcnNwKQorICAg
ICAgICBtb3ZsICAkVFJBUF9kb3VibGVfZmF1bHQsIEVGUkFNRV9lbnRyeV92
ZWN0b3IoJXJzcCkKICAgICAgICAgLyogU2V0IEFDIHRvIHJlZHVjZSBjaGFu
Y2Ugb2YgZnVydGhlciBTTUFQIGZhdWx0cyAqLwogICAgICAgICBBTFRFUk5B
VElWRSAiIiwgc3RhYywgWDg2X0ZFQVRVUkVfWEVOX1NNQVAKICAgICAgICAg
U0FWRV9BTEwKQEAgLTEwMDEsNyArMTAwMSw3IEBAIEVOVFJZKGRvdWJsZV9m
YXVsdCkKIEVOVFJZKG5taSkKICAgICAgICAgRU5EQlI2NAogICAgICAgICBw
dXNocSAkMAotICAgICAgICBtb3ZsICAkVFJBUF9ubWksNCglcnNwKQorICAg
ICAgICBtb3ZsICAkVFJBUF9ubWksIEVGUkFNRV9lbnRyeV92ZWN0b3IoJXJz
cCkKIGhhbmRsZV9pc3RfZXhjZXB0aW9uOgogICAgICAgICBBTFRFUk5BVElW
RSAiIiwgY2xhYywgWDg2X0ZFQVRVUkVfWEVOX1NNQVAKICAgICAgICAgU0FW
RV9BTEwKQEAgLTExMzQsNyArMTEzNCw3IEBAIGhhbmRsZV9pc3RfZXhjZXB0
aW9uOgogRU5UUlkobWFjaGluZV9jaGVjaykKICAgICAgICAgRU5EQlI2NAog
ICAgICAgICBwdXNocSAkMAotICAgICAgICBtb3ZsICAkVFJBUF9tYWNoaW5l
X2NoZWNrLDQoJXJzcCkKKyAgICAgICAgbW92bCAgJFRSQVBfbWFjaGluZV9j
aGVjaywgRUZSQU1FX2VudHJ5X3ZlY3RvciglcnNwKQogICAgICAgICBqbXAg
ICBoYW5kbGVfaXN0X2V4Y2VwdGlvbgogCiAvKiBObyBvcCB0cmFwIGhhbmRs
ZXIuICBSZXF1aXJlZCBmb3Iga2V4ZWMgY3Jhc2ggcGF0aC4gKi8KQEAgLTEx
NzEsNyArMTE3MSw3IEBAIGF1dG9nZW5fc3R1YnM6IC8qIEF1dG9tYXRpY2Fs
bHkgZ2VuZXJhdGVkIHN0dWJzLiAqLwogMToKICAgICAgICAgRU5EQlI2NAog
ICAgICAgICBwdXNocSAkMAotICAgICAgICBtb3ZiICAkdmVjLDQoJXJzcCkK
KyAgICAgICAgbW92YiAgJHZlYywgRUZSQU1FX2VudHJ5X3ZlY3RvciglcnNw
KQogICAgICAgICBqbXAgICBjb21tb25faW50ZXJydXB0CiAKICAgICAgICAg
ZW50cnlwb2ludCAxYgpAQCAtMTE4NSw3ICsxMTg1LDcgQEAgYXV0b2dlbl9z
dHViczogLyogQXV0b21hdGljYWxseSBnZW5lcmF0ZWQgc3R1YnMuICovCiAg
ICAgICAgIHRlc3QgICQ4LCVzcGwgICAgICAgIC8qIDY0Yml0IGV4Y2VwdGlv
biBmcmFtZXMgYXJlIDE2IGJ5dGUgYWxpZ25lZCwgYnV0IHRoZSB3b3JkICov
CiAgICAgICAgIGp6ICAgIDJmICAgICAgICAgICAgIC8qIHNpemUgaXMgOCBi
eXRlcy4gIENoZWNrIHdoZXRoZXIgdGhlIHByb2Nlc3NvciBnYXZlIHVzIGFu
ICovCiAgICAgICAgIHB1c2hxICQwICAgICAgICAgICAgIC8qIGVycm9yIGNv
ZGUsIGFuZCBpbnNlcnQgYW4gZW1wdHkgb25lIGlmIG5vdC4gICAgICAgICAg
ICAgICovCi0yOiAgICAgIG1vdmIgICR2ZWMsNCglcnNwKQorMjogICAgICBt
b3ZiICAkdmVjLCBFRlJBTUVfZW50cnlfdmVjdG9yKCVyc3ApCiAgICAgICAg
IGptcCAgIGhhbmRsZV9leGNlcHRpb24KIAogICAgICAgICBlbnRyeXBvaW50
IDFiCg==

--=separator
Content-Type: application/octet-stream; name="xsa452/xsa452-4.17-2.patch"
Content-Disposition: attachment; filename="xsa452/xsa452-4.17-2.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2OiBSZXN5bmMgaW50ZWwtZmFtaWx5LmggZnJvbSBM
aW51eAoKRnJvbSB2Ni44LXJjNgoKU2lnbmVkLW9mZi1ieTogQW5kcmV3IENv
b3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4KQWNrZWQtYnk6IEph
biBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4KKGNoZXJyeSBwaWNrZWQg
ZnJvbSBjb21taXQgMTk1ZTc1MzcxYjEzYzRmN2VjZGY3YjVjNTBhZWQwZDAy
ZjJkN2NlOCkKCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYvaW5jbHVkZS9h
c20vaW50ZWwtZmFtaWx5LmggYi94ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20v
aW50ZWwtZmFtaWx5LmgKaW5kZXggZmZjNDkxNTFiZWZlLi5iNjVlOWM0NmI5
MjIgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9pbnRl
bC1mYW1pbHkuaAorKysgYi94ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vaW50
ZWwtZmFtaWx5LmgKQEAgLTI2LDYgKzI2LDkgQEAKICAqCQlfRwktIHBhcnRz
IHdpdGggZXh0cmEgZ3JhcGhpY3Mgb24KICAqCQlfWAktIHJlZ3VsYXIgc2Vy
dmVyIHBhcnRzCiAgKgkJX0QJLSBtaWNybyBzZXJ2ZXIgcGFydHMKKyAqCQlf
TixfUAktIG90aGVyIG1vYmlsZSBwYXJ0cworICoJCV9ICS0gcHJlbWl1bSBt
b2JpbGUgcGFydHMKKyAqCQlfUwktIG90aGVyIGNsaWVudCBwYXJ0cwogICoK
ICAqCQlIaXN0b3JpY2FsIE9QVERJRkZzOgogICoKQEAgLTM3LDYgKzQwLDkg
QEAKICAqIHRoZWlyIG93biBuYW1lcyA6LSgKICAqLwogCisvKiBXaWxkY2Fy
ZCBtYXRjaCBmb3IgRkFNNiBzbyBYODZfTUFUQ0hfSU5URUxfRkFNNl9NT0RF
TChBTlkpIHdvcmtzICovCisjZGVmaW5lIElOVEVMX0ZBTTZfQU5ZCQkJWDg2
X01PREVMX0FOWQorCiAjZGVmaW5lIElOVEVMX0ZBTTZfQ09SRV9ZT05BSAkJ
MHgwRQogCiAjZGVmaW5lIElOVEVMX0ZBTTZfQ09SRTJfTUVST00JCTB4MEYK
QEAgLTkzLDggKzk5LDYgQEAKICNkZWZpbmUgSU5URUxfRkFNNl9JQ0VMQUtF
X0wJCTB4N0UJLyogU3VubnkgQ292ZSAqLwogI2RlZmluZSBJTlRFTF9GQU02
X0lDRUxBS0VfTk5QSQkJMHg5RAkvKiBTdW5ueSBDb3ZlICovCiAKLSNkZWZp
bmUgSU5URUxfRkFNNl9MQUtFRklFTEQJCTB4OEEJLyogU3VubnkgQ292ZSAv
IFRyZW1vbnQgKi8KLQogI2RlZmluZSBJTlRFTF9GQU02X1JPQ0tFVExBS0UJ
CTB4QTcJLyogQ3lwcmVzcyBDb3ZlICovCiAKICNkZWZpbmUgSU5URUxfRkFN
Nl9USUdFUkxBS0VfTAkJMHg4QwkvKiBXaWxsb3cgQ292ZSAqLwpAQCAtMTAy
LDEyICsxMDYsMzEgQEAKIAogI2RlZmluZSBJTlRFTF9GQU02X1NBUFBISVJF
UkFQSURTX1gJMHg4RgkvKiBHb2xkZW4gQ292ZSAqLwogCisjZGVmaW5lIElO
VEVMX0ZBTTZfRU1FUkFMRFJBUElEU19YCTB4Q0YKKworI2RlZmluZSBJTlRF
TF9GQU02X0dSQU5JVEVSQVBJRFNfWAkweEFECisjZGVmaW5lIElOVEVMX0ZB
TTZfR1JBTklURVJBUElEU19ECTB4QUUKKworLyogIkh5YnJpZCIgUHJvY2Vz
c29ycyAoUC1Db3JlL0UtQ29yZSkgKi8KKworI2RlZmluZSBJTlRFTF9GQU02
X0xBS0VGSUVMRAkJMHg4QQkvKiBTdW5ueSBDb3ZlIC8gVHJlbW9udCAqLwor
CiAjZGVmaW5lIElOVEVMX0ZBTTZfQUxERVJMQUtFCQkweDk3CS8qIEdvbGRl
biBDb3ZlIC8gR3JhY2Vtb250ICovCiAjZGVmaW5lIElOVEVMX0ZBTTZfQUxE
RVJMQUtFX0wJCTB4OUEJLyogR29sZGVuIENvdmUgLyBHcmFjZW1vbnQgKi8K
IAotI2RlZmluZSBJTlRFTF9GQU02X1JBUFRPUkxBS0UJCTB4QjcKKyNkZWZp
bmUgSU5URUxfRkFNNl9SQVBUT1JMQUtFCQkweEI3CS8qIFJhcHRvciBDb3Zl
IC8gRW5oYW5jZWQgR3JhY2Vtb250ICovCisjZGVmaW5lIElOVEVMX0ZBTTZf
UkFQVE9STEFLRV9QCQkweEJBCisjZGVmaW5lIElOVEVMX0ZBTTZfUkFQVE9S
TEFLRV9TCQkweEJGCisKKyNkZWZpbmUgSU5URUxfRkFNNl9NRVRFT1JMQUtF
CQkweEFDCisjZGVmaW5lIElOVEVMX0ZBTTZfTUVURU9STEFLRV9MCQkweEFB
CisKKyNkZWZpbmUgSU5URUxfRkFNNl9BUlJPV0xBS0VfSAkJMHhDNQorI2Rl
ZmluZSBJTlRFTF9GQU02X0FSUk9XTEFLRQkJMHhDNgorCisjZGVmaW5lIElO
VEVMX0ZBTTZfTFVOQVJMQUtFX00JCTB4QkQKIAotLyogIlNtYWxsIENvcmUi
IFByb2Nlc3NvcnMgKEF0b20pICovCisvKiAiU21hbGwgQ29yZSIgUHJvY2Vz
c29ycyAoQXRvbS9FLUNvcmUpICovCiAKICNkZWZpbmUgSU5URUxfRkFNNl9B
VE9NX0JPTk5FTEwJCTB4MUMgLyogRGlhbW9uZHZpbGxlLCBQaW5ldmlldyAq
LwogI2RlZmluZSBJTlRFTF9GQU02X0FUT01fQk9OTkVMTF9NSUQJMHgyNiAv
KiBTaWx2ZXJ0aG9ybmUsIExpbmNyb2Z0ICovCkBAIC0xMzQsNiArMTU3LDEz
IEBACiAjZGVmaW5lIElOVEVMX0ZBTTZfQVRPTV9UUkVNT05UCQkweDk2IC8q
IEVsa2hhcnQgTGFrZSAqLwogI2RlZmluZSBJTlRFTF9GQU02X0FUT01fVFJF
TU9OVF9MCTB4OUMgLyogSmFzcGVyIExha2UgKi8KIAorI2RlZmluZSBJTlRF
TF9GQU02X0FUT01fR1JBQ0VNT05UCTB4QkUgLyogQWxkZXJsYWtlIE4gKi8K
KworI2RlZmluZSBJTlRFTF9GQU02X0FUT01fQ1JFU1RNT05UX1gJMHhBRiAv
KiBTaWVycmEgRm9yZXN0ICovCisjZGVmaW5lIElOVEVMX0ZBTTZfQVRPTV9D
UkVTVE1PTlQJMHhCNiAvKiBHcmFuZCBSaWRnZSAqLworCisjZGVmaW5lIElO
VEVMX0ZBTTZfQVRPTV9EQVJLTU9OVF9YCTB4REQgLyogQ2xlYXJ3YXRlciBG
b3Jlc3QgKi8KKwogLyogWGVvbiBQaGkgKi8KIAogI2RlZmluZSBJTlRFTF9G
QU02X1hFT05fUEhJX0tOTAkJMHg1NyAvKiBLbmlnaHRzIExhbmRpbmcgKi8K

--=separator
Content-Type: application/octet-stream; name="xsa452/xsa452-4.17-3.patch"
Content-Disposition: attachment; filename="xsa452/xsa452-4.17-3.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L3ZteDogUGVyZm9ybSBWRVJXIGZsdXNoaW5nIGxh
dGVyIGluIHRoZSBWTUV4aXQgcGF0aAoKQnJva2VuIG91dCBvZiB0aGUgZm9s
bG93aW5nIHBhdGNoIGJlY2F1c2UgdGhpcyBjaGFuZ2UgaXMgc3VidGxlIGVu
b3VnaCBvbiBpdHMKb3duLiAgU2VlIGl0IGZvciB0aGUgcmF0aW9uYWwgb2Yg
d2h5IHdlJ3JlIG1vdmluZyBWRVJXLgoKQXMgZm9yIGhvdywgZXh0ZW5kIHRo
ZSB0cmljayBhbHJlYWR5IHVzZWQgdG8gaG9sZCBvbmUgY29uZGl0aW9uIGlu
CmZsYWdzIChSRVNVTUUgdnMgTEFVTkNIKSB0aHJvdWdoIHRoZSBQT1Bpbmcg
b2YgR1BScy4KCk1vdmUgdGhlIE1PViBDUiBlYXJsaWVyLiAgSW50ZWwgc3Bl
Y2lmeSBmbGFncyB0byBiZSB1bmRlZmluZWQgYWNyb3NzIGl0LgoKRW5jb2Rl
IHRoZSB0d28gY29uZGl0aW9ucyB3ZSB3YW50IHVzaW5nIFNGIGFuZCBQRi4g
IFNlZSB0aGUgY29kZSBjb21tZW50IGZvcgpleGFjdGx5IGhvdy4KCkxlYXZl
IGEgY29tbWVudCB0byBleHBsYWluIHRoZSBsYWNrIG9mIGFueSBjb250ZW50
IGFyb3VuZApTUEVDX0NUUkxfRVhJVF9UT19WTVgsIGJ1dCBsZWF2ZSB0aGUg
YmxvY2sgaW4gcGxhY2UuICBTb2RzIGxhdyBzYXlzIGlmIHdlCmRlbGV0ZSBp
dCwgd2UnbGwgbmVlZCB0byByZWludHJvZHVjZSBpdC4KClRoaXMgaXMgcGFy
dCBvZiBYU0EtNDUyIC8gQ1ZFLTIwMjMtMjg3NDYuCgpTaWduZWQtb2ZmLWJ5
OiBBbmRyZXcgQ29vcGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPgpS
ZXZpZXdlZC1ieTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgoo
Y2hlcnJ5IHBpY2tlZCBmcm9tIGNvbW1pdCA0NzVmYTIwYjczODQ0NjQyMTBm
NDJiYWQ3MTk1Zjg3YmQ2ZjFjNjNmKQoKZGlmZiAtLWdpdCBhL3hlbi9hcmNo
L3g4Ni9odm0vdm14L2VudHJ5LlMgYi94ZW4vYXJjaC94ODYvaHZtL3ZteC9l
bnRyeS5TCmluZGV4IDVmNWRlNDVhMTMwOS4uY2RkZTc2ZTEzODkyIDEwMDY0
NAotLS0gYS94ZW4vYXJjaC94ODYvaHZtL3ZteC9lbnRyeS5TCisrKyBiL3hl
bi9hcmNoL3g4Ni9odm0vdm14L2VudHJ5LlMKQEAgLTg3LDE3ICs4NywzOSBA
QCBVTkxJS0VMWV9FTkQocmVhbG1vZGUpCiAKICAgICAgICAgLyogV0FSTklO
RyEgYHJldGAsIGBjYWxsICpgLCBgam1wICpgIG5vdCBzYWZlIGJleW9uZCB0
aGlzIHBvaW50LiAqLwogICAgICAgICAvKiBTUEVDX0NUUkxfRVhJVF9UT19W
TVggICBSZXE6ICVyc3A9cmVncy9jcHVpbmZvICAgICAgICAgICAgICBDbG9i
OiAgICAqLwotICAgICAgICBET19TUEVDX0NUUkxfQ09ORF9WRVJXCisgICAg
ICAgIC8qCisgICAgICAgICAqIEFsbCBzcGVjdWxhdGlvbiBzYWZldHkgd29y
ayBoYXBwZW5zIHRvIGJlIGVsc2V3aGVyZS4gIFZFUlcgaXMgYWZ0ZXIKKyAg
ICAgICAgICogcG9wcGluZyB0aGUgR1BScywgd2hpbGUgcmVzdG9yaW5nIHRo
ZSBndWVzdCBNU1JfU1BFQ19DVFJMIGlzIGxlZnQKKyAgICAgICAgICogdG8g
dGhlIE1TUiBsb2FkIGxpc3QuCisgICAgICAgICAqLwogCiAgICAgICAgIG1v
diAgVkNQVV9odm1fZ3Vlc3RfY3IyKCVyYngpLCVyYXgKKyAgICAgICAgbW92
ICAlcmF4LCAlY3IyCisKKyAgICAgICAgLyoKKyAgICAgICAgICogV2UgbmVl
ZCB0byBwZXJmb3JtIHR3byBjb25kaXRpb25hbCBhY3Rpb25zIChWRVJXLCBh
bmQgUmVzdW1lIHZzCisgICAgICAgICAqIExhdW5jaCkgYWZ0ZXIgcG9wcGlu
ZyBHUFJzLiAgV2l0aCBzb21lIGN1bm5pbmcsIHdlIGNhbiBlbmNvZGUgYm90
aAorICAgICAgICAgKiBvZiB0aGVzZSBpbiBlZmxhZ3MgdG9nZXRoZXIuCisg
ICAgICAgICAqCisgICAgICAgICAqIFBhcml0eSBpcyBvbmx5IGNhbGN1bGF0
ZWQgb3ZlciB0aGUgYm90dG9tIGJ5dGUgb2YgdGhlIGFuc3dlciwgd2hpbGUK
KyAgICAgICAgICogU2lnbiBpcyBzaW1wbHkgdGhlIHRvcCBiaXQuCisgICAg
ICAgICAqCisgICAgICAgICAqIFRoZXJlZm9yZSwgdGhlIGZpbmFsIE9SIGlu
c3RydWN0aW9uIGVuZHMgdXAgcHJvZHVjaW5nOgorICAgICAgICAgKiAgIFNG
ID0gVkNQVV92bXhfbGF1bmNoZWQKKyAgICAgICAgICogICBQRiA9ICFTQ0Zf
dmVydworICAgICAgICAgKi8KKyAgICAgICAgQlVJTERfQlVHX09OKFNDRl92
ZXJ3ICYgfjB4ZmYpCisgICAgICAgIG1vdnpibCBWQ1BVX3ZteF9sYXVuY2hl
ZCglcmJ4KSwgJWVjeAorICAgICAgICBzaGwgICQzMSwgJWVjeAorICAgICAg
ICBtb3Z6YmwgQ1BVSU5GT19zcGVjX2N0cmxfZmxhZ3MoJXJzcCksICVlYXgK
KyAgICAgICAgYW5kICAkU0NGX3ZlcncsICVlYXgKKyAgICAgICAgb3IgICAl
ZWF4LCAlZWN4CiAKICAgICAgICAgcG9wICAlcjE1CiAgICAgICAgIHBvcCAg
JXIxNAogICAgICAgICBwb3AgICVyMTMKICAgICAgICAgcG9wICAlcjEyCiAg
ICAgICAgIHBvcCAgJXJicAotICAgICAgICBtb3YgICVyYXgsJWNyMgotICAg
ICAgICBjbXBiICQwLFZDUFVfdm14X2xhdW5jaGVkKCVyYngpCiAgICAgICAg
IHBvcCAgJXJieAogICAgICAgICBwb3AgICVyMTEKICAgICAgICAgcG9wICAl
cjEwCkBAIC0xMDgsNyArMTMwLDEzIEBAIFVOTElLRUxZX0VORChyZWFsbW9k
ZSkKICAgICAgICAgcG9wICAlcmR4CiAgICAgICAgIHBvcCAgJXJzaQogICAg
ICAgICBwb3AgICVyZGkKLSAgICAgICAgamUgICAuTHZteF9sYXVuY2gKKwor
ICAgICAgICBqcGUgIC5MX3NraXBfdmVydworICAgICAgICAvKiBWRVJXIGNs
b2JiZXJzIFpGLCBidXQgcHJlc2VydmVzIGFsbCBvdGhlcnMsIGluY2x1ZGlu
ZyBTRi4gKi8KKyAgICAgICAgdmVydyBTVEtfUkVMKENQVUlORk9fdmVyd19z
ZWwsIENQVUlORk9fZXJyb3JfY29kZSkoJXJzcCkKKy5MX3NraXBfdmVydzoK
KworICAgICAgICBqbnMgIC5Mdm14X2xhdW5jaAogCiAvKi5Mdm14X3Jlc3Vt
ZToqLwogICAgICAgICBWTVJFU1VNRQpkaWZmIC0tZ2l0IGEveGVuL2FyY2gv
eDg2L2luY2x1ZGUvYXNtL2FzbV9kZWZucy5oIGIveGVuL2FyY2gveDg2L2lu
Y2x1ZGUvYXNtL2FzbV9kZWZucy5oCmluZGV4IGQ5NDMxMTgwY2ZiYS4uYWJj
NjgyMmIwOGM4IDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYvaW5jbHVkZS9h
c20vYXNtX2RlZm5zLmgKKysrIGIveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNt
L2FzbV9kZWZucy5oCkBAIC04MSw2ICs4MSwxNCBAQCByZWdpc3RlciB1bnNp
Z25lZCBsb25nIGN1cnJlbnRfc3RhY2tfcG9pbnRlciBhc20oInJzcCIpOwog
CiAjaWZkZWYgX19BU1NFTUJMWV9fCiAKKy5tYWNybyBCVUlMRF9CVUdfT04g
Y29uZHN0ciwgY29uZDp2YXJhcmcKKyAgICAgICAgLmlmIFxjb25kCisgICAg
ICAgIC5lcnJvciAiQ29uZGl0aW9uIFwiXGNvbmRzdHJcIiBub3Qgc2F0aXNm
aWVkIgorICAgICAgICAuZW5kaWYKKy5lbmRtCisvKiBwcmVwcm9jZXNzb3Ig
bWFjcm8gdG8gbWFrZSBlcnJvciBtZXNzYWdlIG1vcmUgdXNlciBmcmllbmRs
eSAqLworI2RlZmluZSBCVUlMRF9CVUdfT04oY29uZCkgQlVJTERfQlVHX09O
ICNjb25kLCBjb25kCisKICNpZmRlZiBIQVZFX0FTX1FVT1RFRF9TWU0KICNk
ZWZpbmUgU1VCU0VDVElPTl9MQkwodGFnKSAgICAgICAgICAgICAgICAgICAg
ICAgIFwKICAgICAgICAgLmlmbmRlZiAuTC50YWc7ICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIFwKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9pbmNs
dWRlL2FzbS9zcGVjX2N0cmxfYXNtLmggYi94ZW4vYXJjaC94ODYvaW5jbHVk
ZS9hc20vc3BlY19jdHJsX2FzbS5oCmluZGV4IGY0YjhiOWQ5NTYxYy4uY2E5
Y2IwZjVkZDFkIDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYvaW5jbHVkZS9h
c20vc3BlY19jdHJsX2FzbS5oCisrKyBiL3hlbi9hcmNoL3g4Ni9pbmNsdWRl
L2FzbS9zcGVjX2N0cmxfYXNtLmgKQEAgLTE2NCw2ICsxNjQsMTMgQEAKICNl
bmRpZgogLmVuZG0KIAorLyoKKyAqIEhlbHBlciB0byBpbXByb3ZlIHRoZSBy
ZWFkaWJpbGl0eSBvZiBzdGFjayBkaXNwYWNlbWVudHMgd2l0aCAlcnNwIGlu
CisgKiB1bnVzdWFsIHBvc2l0aW9ucy4gIEJvdGggQGZpZWxkIGFuZCBAdG9w
X29mX3N0YWNrIHNob3VsZCBiZSBjb25zdGFudHMgZnJvbQorICogdGhlIHNh
bWUgb2JqZWN0LiAgQHRvcF9vZl9zdGFjayBzaG91bGQgYmUgd2hlcmUgJXJz
cCBpcyBjdXJyZW50bHkgcG9pbnRpbmcuCisgKi8KKyNkZWZpbmUgU1RLX1JF
TChmaWVsZCwgdG9wX29mX3N0aykgKChmaWVsZCkgLSAodG9wX29mX3N0aykp
CisKIC5tYWNybyBET19TUEVDX0NUUkxfQ09ORF9WRVJXCiAvKgogICogUmVx
dWlyZXMgJXJzcD1jcHVpbmZvCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYv
eDg2XzY0L2FzbS1vZmZzZXRzLmMgYi94ZW4vYXJjaC94ODYveDg2XzY0L2Fz
bS1vZmZzZXRzLmMKaW5kZXggMzFmYTYzYjc3ZmQxLi5hNGU5NGQ2OTMwMjQg
MTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni94ODZfNjQvYXNtLW9mZnNldHMu
YworKysgYi94ZW4vYXJjaC94ODYveDg2XzY0L2FzbS1vZmZzZXRzLmMKQEAg
LTEzNSw2ICsxMzUsNyBAQCB2b2lkIF9fZHVtbXlfXyh2b2lkKQogI2VuZGlm
CiAKICAgICBPRkZTRVQoQ1BVSU5GT19ndWVzdF9jcHVfdXNlcl9yZWdzLCBz
dHJ1Y3QgY3B1X2luZm8sIGd1ZXN0X2NwdV91c2VyX3JlZ3MpOworICAgIE9G
RlNFVChDUFVJTkZPX2Vycm9yX2NvZGUsIHN0cnVjdCBjcHVfaW5mbywgZ3Vl
c3RfY3B1X3VzZXJfcmVncy5lcnJvcl9jb2RlKTsKICAgICBPRkZTRVQoQ1BV
SU5GT192ZXJ3X3NlbCwgc3RydWN0IGNwdV9pbmZvLCB2ZXJ3X3NlbCk7CiAg
ICAgT0ZGU0VUKENQVUlORk9fY3VycmVudF92Y3B1LCBzdHJ1Y3QgY3B1X2lu
Zm8sIGN1cnJlbnRfdmNwdSk7CiAgICAgT0ZGU0VUKENQVUlORk9fcGVyX2Nw
dV9vZmZzZXQsIHN0cnVjdCBjcHVfaW5mbywgcGVyX2NwdV9vZmZzZXQpOwo=

--=separator
Content-Type: application/octet-stream; name="xsa452/xsa452-4.17-4.patch"
Content-Disposition: attachment; filename="xsa452/xsa452-4.17-4.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L3NwZWMtY3RybDogUGVyZm9ybSBWRVJXIGZsdXNo
aW5nIGxhdGVyIGluIGV4aXQgcGF0aHMKCk9uIHBhcnRzIHZ1bG5lcmFibGUg
dG8gUkZEUywgVkVSVydzIHNpZGUgZWZmZWN0cyBhcmUgZXh0ZW5kZWQgdG8g
c2NydWIgYWxsCm5vbi1hcmNoaXRlY3R1cmFsIGVudHJpZXMgaW4gdmFyaW91
cyBQaHlzaWNhbCBSZWdpc3RlciBGaWxlcy4gIFRvIHJlbW92ZSBhbGwKb2Yg
WGVuJ3MgdmFsdWVzLCB0aGUgVkVSVyBtdXN0IGJlIGFmdGVyIHBvcHBpbmcg
dGhlIEdQUnMuCgpSZXdvcmsgU1BFQ19DVFJMX0NPTkRfVkVSVyB0byBkZWZh
dWx0IHRvIGFuIENQVUlORk9fZXJyb3JfY29kZSAlcnNwIHBvc2l0aW9uLApi
dXQgd2l0aCBvdmVycmlkZXMgZm9yIG90aGVyIGNvbnRleHRzLiAgSWRlbnRp
ZnkgdGhhdCBpdCBjbG9iYmVycyBlZmxhZ3M7IHRoaXMKaXMgcGFydGljdWxh
cmx5IHJlbGV2YW50IGZvciB0aGUgU1lTUkVUIHBhdGguCgpGb3IgdGhlIElT
VCBleGl0IHJldHVybiB0byBYZW4sIGhhdmUgdGhlIG1haW4gU1BFQ19DVFJM
X0VYSVRfVE9fWEVOIHB1dCBhCnNoYWRvdyBjb3B5IG9mIHNwZWNfY3RybF9m
bGFncywgYXMgR1BScyBjYW4ndCBiZSB1c2VkIGF0IHRoZSBwb2ludCB3ZSB3
YW50IHRvCmlzc3VlIHRoZSBWRVJXLgoKVGhpcyBpcyBwYXJ0IG9mIFhTQS00
NTIgLyBDVkUtMjAyMy0yODc0Ni4KClNpZ25lZC1vZmYtYnk6IEFuZHJldyBD
b29wZXIgPGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+ClJldmlld2VkLWJ5
OiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+CihjaGVycnkgcGlj
a2VkIGZyb20gY29tbWl0IDBhNjY2Y2YyY2Q5OWRmNmZhZjNlZWJjODFhMWZj
Mjg2ZTRlY2E0YzcpCgpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2luY2x1
ZGUvYXNtL3NwZWNfY3RybF9hc20uaCBiL3hlbi9hcmNoL3g4Ni9pbmNsdWRl
L2FzbS9zcGVjX2N0cmxfYXNtLmgKaW5kZXggY2E5Y2IwZjVkZDFkLi45N2E5
N2IyYjgyYzkgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2Fz
bS9zcGVjX2N0cmxfYXNtLmgKKysrIGIveGVuL2FyY2gveDg2L2luY2x1ZGUv
YXNtL3NwZWNfY3RybF9hc20uaApAQCAtMTcxLDE2ICsxNzEsMjMgQEAKICAq
LwogI2RlZmluZSBTVEtfUkVMKGZpZWxkLCB0b3Bfb2Zfc3RrKSAoKGZpZWxk
KSAtICh0b3Bfb2Zfc3RrKSkKIAotLm1hY3JvIERPX1NQRUNfQ1RSTF9DT05E
X1ZFUlcKKy5tYWNybyBTUEVDX0NUUkxfQ09ORF9WRVJXIFwKKyAgICBzY2Y9
U1RLX1JFTChDUFVJTkZPX3NwZWNfY3RybF9mbGFncywgQ1BVSU5GT19lcnJv
cl9jb2RlKSwgXAorICAgIHNlbD1TVEtfUkVMKENQVUlORk9fdmVyd19zZWws
ICAgICAgICBDUFVJTkZPX2Vycm9yX2NvZGUpCiAvKgotICogUmVxdWlyZXMg
JXJzcD1jcHVpbmZvCisgKiBSZXF1aXJlcyBcc2NmIGFuZCBcc2VsIGFzICVy
c3AtcmVsYXRpdmUgZXhwcmVzc2lvbnMKKyAqIENsb2JiZXJzIGVmbGFncwor
ICoKKyAqIFZFUlcgbmVlZHMgdG8gcnVuIGFmdGVyIGd1ZXN0IEdQUnMgaGF2
ZSBiZWVuIHJlc3RvcmVkLCB3aGVyZSBvbmx5ICVyc3AgaXMKKyAqIGdvb2Qg
dG8gdXNlLiAgRGVmYXVsdCB0byBleHBlY3RpbmcgJXJzcCBwb2ludGluZyBh
dCBDUFVJTkZPX2Vycm9yX2NvZGUuCisgKiBDb250ZXh0cyB3aGVyZSB0aGlz
IGlzIG5vdCB0cnVlIG11c3QgcHJvdmlkZSBhbiBhbHRlcm5hdGl2ZSBcc2Nm
IGFuZCBcc2VsLgogICoKICAqIElzc3VlIGEgVkVSVyBmb3IgaXRzIGZsdXNo
aW5nIHNpZGUgZWZmZWN0LCBpZiBpbmRpY2F0ZWQuICBUaGlzIGlzIGEgU3Bl
Y3RyZQogICogdjEgZ2FkZ2V0LCBidXQgdGhlIElSRVQvVk1FbnRyeSBpcyBz
ZXJpYWxpc2luZy4KICAqLwotICAgIHRlc3RiICRTQ0ZfdmVydywgQ1BVSU5G
T19zcGVjX2N0cmxfZmxhZ3MoJXJzcCkKKyAgICB0ZXN0YiAkU0NGX3Zlcncs
IFxzY2YoJXJzcCkKICAgICBqeiAuTFxAX3Zlcndfc2tpcAotICAgIHZlcncg
Q1BVSU5GT192ZXJ3X3NlbCglcnNwKQorICAgIHZlcncgXHNlbCglcnNwKQog
LkxcQF92ZXJ3X3NraXA6CiAuZW5kbQogCkBAIC0yOTgsOCArMzA1LDYgQEAK
ICAqLwogICAgIEFMVEVSTkFUSVZFICIiLCBET19TUEVDX0NUUkxfRVhJVF9U
T19HVUVTVCwgWDg2X0ZFQVRVUkVfU0NfTVNSX1BWCiAKLSAgICBET19TUEVD
X0NUUkxfQ09ORF9WRVJXCi0KICAgICBBTFRFUk5BVElWRSAiIiwgRE9fU1BF
Q19DVFJMX0RJViwgWDg2X0ZFQVRVUkVfU0NfRElWCiAuZW5kbQogCkBAIC0z
NzksNyArMzg0LDcgQEAgVU5MSUtFTFlfRElTUEFUQ0hfTEFCRUwoXEBfc2Vy
aWFsaXNlKToKICAqLwogLm1hY3JvIFNQRUNfQ1RSTF9FWElUX1RPX1hFTgog
LyoKLSAqIFJlcXVpcmVzICVyMTI9aXN0X2V4aXQsICVyMTQ9c3RhY2tfZW5k
CisgKiBSZXF1aXJlcyAlcjEyPWlzdF9leGl0LCAlcjE0PXN0YWNrX2VuZCwg
JXJzcD1yZWdzCiAgKiBDbG9iYmVycyAlcmF4LCAlcmJ4LCAlcmN4LCAlcmR4
CiAgKi8KICAgICBtb3Z6YmwgU1RBQ0tfQ1BVSU5GT19GSUVMRChzcGVjX2N0
cmxfZmxhZ3MpKCVyMTQpLCAlZWJ4CkBAIC00MDcsMTEgKzQxMiwxOCBAQCBV
TkxJS0VMWV9ESVNQQVRDSF9MQUJFTChcQF9zZXJpYWxpc2UpOgogICAgIHRl
c3QgJXIxMiwgJXIxMgogICAgIGp6IC5MXEBfc2tpcF9pc3RfZXhpdAogCi0g
ICAgLyogTG9naWNhbGx5IERPX1NQRUNfQ1RSTF9DT05EX1ZFUlcgYnV0IHdp
dGhvdXQgdGhlICVyc3A9Y3B1aW5mbyBkZXBlbmRlbmN5ICovCi0gICAgdGVz
dGIgJFNDRl92ZXJ3LCAlYmwKLSAgICBqeiAuTFxAX3NraXBfdmVydwotICAg
IHZlcncgU1RBQ0tfQ1BVSU5GT19GSUVMRCh2ZXJ3X3NlbCkoJXIxNCkKLS5M
XEBfc2tpcF92ZXJ3OgorICAgIC8qCisgICAgICogU3Rhc2ggU0NGIGFuZCB2
ZXJ3X3NlbCBhYm92ZSBlZmxhZ3MgaW4gdGhlIGNhc2Ugb2YgYW4gSVNUX2V4
aXQuICBUaGUKKyAgICAgKiBWRVJXIGxvZ2ljIG5lZWRzIHRvIHJ1biBhZnRl
ciBndWVzdCBHUFJzIGhhdmUgYmVlbiByZXN0b3JlZDsgaS5lLiB3aGVyZQor
ICAgICAqIHdlIGNhbm5vdCB1c2UgJXIxMiBvciAlcjE0IGZvciB0aGUgcHVy
cG9zZXMgdGhleSBoYXZlIGhlcmUuCisgICAgICoKKyAgICAgKiBXaGVuIHRo
ZSBDUFUgcHVzaGVkIHRoaXMgZXhjZXB0aW9uIGZyYW1lLCBpdCB6ZXJvLWV4
dGVuZGVkIGVmbGFncy4KKyAgICAgKiBUaGVyZWZvcmUgaXQgaXMgc2FmZSBm
b3IgdGhlIFZFUlcgbG9naWMgdG8gbG9vayBhdCB0aGUgc3Rhc2hlZCBTQ0YK
KyAgICAgKiBvdXRzaWRlIG9mIHRoZSBpc3RfZXhpdCBjb25kaXRpb24uICBB
bHNvLCB0aGlzIHN0YXNoaW5nIHdvbid0IGluZmx1ZW5jZQorICAgICAqIGFu
eSBvdGhlciByZXN0b3JlX2FsbF9ndWVzdCgpIHBhdGhzLgorICAgICAqLwor
ICAgIG9yICQoX19IWVBFUlZJU09SX0RTMzIgPDwgMTYpLCAlZWJ4CisgICAg
bW92ICVlYngsIFVSRUdTX2VmbGFncyArIDQoJXJzcCkgLyogRUZSQU1FX3No
YWRvd19zY2Yvc2VsICovCiAKICAgICBBTFRFUk5BVElWRSAiIiwgRE9fU1BF
Q19DVFJMX0RJViwgWDg2X0ZFQVRVUkVfU0NfRElWCiAKZGlmZiAtLWdpdCBh
L3hlbi9hcmNoL3g4Ni94ODZfNjQvYXNtLW9mZnNldHMuYyBiL3hlbi9hcmNo
L3g4Ni94ODZfNjQvYXNtLW9mZnNldHMuYwppbmRleCBhNGU5NGQ2OTMwMjQu
LjRjZDU5MzhkN2I5ZCAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L3g4Nl82
NC9hc20tb2Zmc2V0cy5jCisrKyBiL3hlbi9hcmNoL3g4Ni94ODZfNjQvYXNt
LW9mZnNldHMuYwpAQCAtNTUsMTQgKzU1LDIyIEBAIHZvaWQgX19kdW1teV9f
KHZvaWQpCiAgICAgICogRUZSQU1FXyogaXMgZm9yIHRoZSBlbnRyeS9leGl0
IGxvZ2ljIHdoZXJlICVyc3AgaXMgcG9pbnRpbmcgYXQKICAgICAgKiBVUkVH
U19lcnJvcl9jb2RlIGFuZCBHUFJzIGFyZSBzdGlsbC9hbHJlYWR5IGd1ZXN0
IHZhbHVlcy4KICAgICAgKi8KLSNkZWZpbmUgT0ZGU0VUX0VGKHN5bSwgbWVt
KSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IFwKKyNkZWZpbmUgT0ZGU0VUX0VGKHN5bSwgbWVtLCAuLi4pICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKICAgICBERUZJTkUo
c3ltLCBvZmZzZXRvZihzdHJ1Y3QgY3B1X3VzZXJfcmVncywgbWVtKSAtICAg
ICAgICAgICAgICAgICAgIFwKLSAgICAgICAgICAgICAgICBvZmZzZXRvZihz
dHJ1Y3QgY3B1X3VzZXJfcmVncywgZXJyb3JfY29kZSkpCisgICAgICAgICAg
ICAgICAgb2Zmc2V0b2Yoc3RydWN0IGNwdV91c2VyX3JlZ3MsIGVycm9yX2Nv
ZGUpIF9fVkFfQVJHU19fKQogCiAgICAgT0ZGU0VUX0VGKEVGUkFNRV9lbnRy
eV92ZWN0b3IsICAgIGVudHJ5X3ZlY3Rvcik7CiAgICAgT0ZGU0VUX0VGKEVG
UkFNRV9yaXAsICAgICAgICAgICAgIHJpcCk7CiAgICAgT0ZGU0VUX0VGKEVG
UkFNRV9jcywgICAgICAgICAgICAgIGNzKTsKICAgICBPRkZTRVRfRUYoRUZS
QU1FX2VmbGFncywgICAgICAgICAgZWZsYWdzKTsKKworICAgIC8qCisgICAg
ICogVGhlc2UgYXJlbid0IHJlYWwgZmllbGRzLiAgVGhleSdyZSBzcGFyZSBz
cGFjZSwgdXNlZCBieSB0aGUgSVNUCisgICAgICogZXhpdC10by14ZW4gcGF0
aC4KKyAgICAgKi8KKyAgICBPRkZTRVRfRUYoRUZSQU1FX3NoYWRvd19zY2Ys
ICAgICAgZWZsYWdzLCArNCk7CisgICAgT0ZGU0VUX0VGKEVGUkFNRV9zaGFk
b3dfc2VsLCAgICAgIGVmbGFncywgKzYpOworCiAgICAgT0ZGU0VUX0VGKEVG
UkFNRV9yc3AsICAgICAgICAgICAgIHJzcCk7CiAgICAgQkxBTksoKTsKIApA
QCAtMTM2LDYgKzE0NCw3IEBAIHZvaWQgX19kdW1teV9fKHZvaWQpCiAKICAg
ICBPRkZTRVQoQ1BVSU5GT19ndWVzdF9jcHVfdXNlcl9yZWdzLCBzdHJ1Y3Qg
Y3B1X2luZm8sIGd1ZXN0X2NwdV91c2VyX3JlZ3MpOwogICAgIE9GRlNFVChD
UFVJTkZPX2Vycm9yX2NvZGUsIHN0cnVjdCBjcHVfaW5mbywgZ3Vlc3RfY3B1
X3VzZXJfcmVncy5lcnJvcl9jb2RlKTsKKyAgICBPRkZTRVQoQ1BVSU5GT19y
aXAsIHN0cnVjdCBjcHVfaW5mbywgZ3Vlc3RfY3B1X3VzZXJfcmVncy5yaXAp
OwogICAgIE9GRlNFVChDUFVJTkZPX3Zlcndfc2VsLCBzdHJ1Y3QgY3B1X2lu
Zm8sIHZlcndfc2VsKTsKICAgICBPRkZTRVQoQ1BVSU5GT19jdXJyZW50X3Zj
cHUsIHN0cnVjdCBjcHVfaW5mbywgY3VycmVudF92Y3B1KTsKICAgICBPRkZT
RVQoQ1BVSU5GT19wZXJfY3B1X29mZnNldCwgc3RydWN0IGNwdV9pbmZvLCBw
ZXJfY3B1X29mZnNldCk7CmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYveDg2
XzY0L2NvbXBhdC9lbnRyeS5TIGIveGVuL2FyY2gveDg2L3g4Nl82NC9jb21w
YXQvZW50cnkuUwppbmRleCA3YzIxMTMxNGQ4ODUuLjNiMmZiY2Q4NzMzYSAx
MDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L3g4Nl82NC9jb21wYXQvZW50cnku
UworKysgYi94ZW4vYXJjaC94ODYveDg2XzY0L2NvbXBhdC9lbnRyeS5TCkBA
IC0xNjEsNiArMTYxLDEyIEBAIEVOVFJZKGNvbXBhdF9yZXN0b3JlX2FsbF9n
dWVzdCkKICAgICAgICAgU1BFQ19DVFJMX0VYSVRfVE9fUFYgICAgLyogUmVx
OiBhPXNwZWNfY3RybCAlcnNwPXJlZ3MvY3B1aW5mbywgQ2xvYjogY2QgKi8K
IAogICAgICAgICBSRVNUT1JFX0FMTCBhZGo9OCBjb21wYXQ9MQorCisgICAg
ICAgIC8qIEFjY291bnQgZm9yIGV2L2VjIGhhdmluZyBhbHJlYWR5IGJlZW4g
cG9wcGVkIG9mZiB0aGUgc3RhY2suICovCisgICAgICAgIFNQRUNfQ1RSTF9D
T05EX1ZFUlcgXAorICAgICAgICAgICAgc2NmPVNUS19SRUwoQ1BVSU5GT19z
cGVjX2N0cmxfZmxhZ3MsIENQVUlORk9fcmlwKSwgXAorICAgICAgICAgICAg
c2VsPVNUS19SRUwoQ1BVSU5GT192ZXJ3X3NlbCwgICAgICAgIENQVUlORk9f
cmlwKQorCiAuTGZ0MDogIGlyZXRxCiAgICAgICAgIF9BU01fUFJFX0VYVEFC
TEUoLkxmdDAsIGhhbmRsZV9leGNlcHRpb24pCiAKZGlmZiAtLWdpdCBhL3hl
bi9hcmNoL3g4Ni94ODZfNjQvZW50cnkuUyBiL3hlbi9hcmNoL3g4Ni94ODZf
NjQvZW50cnkuUwppbmRleCA0MTJjYmViM2VjYTQuLmVmNTE3ZTI5NDViMCAx
MDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L3g4Nl82NC9lbnRyeS5TCisrKyBi
L3hlbi9hcmNoL3g4Ni94ODZfNjQvZW50cnkuUwpAQCAtMjE0LDYgKzIxNCw5
IEBAIHJlc3RvcmVfYWxsX2d1ZXN0OgogI2VuZGlmCiAKICAgICAgICAgbW92
ICAgRUZSQU1FX3JpcCglcnNwKSwgJXJjeAorCisgICAgICAgIFNQRUNfQ1RS
TF9DT05EX1ZFUlcgICAgIC8qIFJlcTogJXJzcD1lZnJhbWUgICAgICAgICAg
ICAgICAgICAgIENsb2I6IGVmbCAqLworCiAgICAgICAgIGNtcHcgICRGTEFU
X1VTRVJfQ1MzMiwgRUZSQU1FX2NzKCVyc3ApCiAgICAgICAgIG1vdiAgIEVG
UkFNRV9yc3AoJXJzcCksICVyc3AKICAgICAgICAgamUgICAgMWYKQEAgLTIy
Nyw2ICsyMzAsOSBAQCByZXN0b3JlX2FsbF9ndWVzdDoKIGlyZXRfZXhpdF90
b19ndWVzdDoKICAgICAgICAgYW5kbCAgJH4oWDg2X0VGTEFHU19JT1BMIHwg
WDg2X0VGTEFHU19WTSksIEVGUkFNRV9lZmxhZ3MoJXJzcCkKICAgICAgICAg
b3JsICAgJFg4Nl9FRkxBR1NfSUYsIEVGUkFNRV9lZmxhZ3MoJXJzcCkKKwor
ICAgICAgICBTUEVDX0NUUkxfQ09ORF9WRVJXICAgICAvKiBSZXE6ICVyc3A9
ZWZyYW1lICAgICAgICAgICAgICAgICAgICBDbG9iOiBlZmwgKi8KKwogICAg
ICAgICBhZGRxICAkOCwlcnNwCiAuTGZ0MDogIGlyZXRxCiAgICAgICAgIF9B
U01fUFJFX0VYVEFCTEUoLkxmdDAsIGhhbmRsZV9leGNlcHRpb24pCkBAIC02
NzksOSArNjg1LDIyIEBAIFVOTElLRUxZX1NUQVJUKG5lLCBleGl0X2NyMykK
IFVOTElLRUxZX0VORChleGl0X2NyMykKIAogICAgICAgICAvKiBXQVJOSU5H
ISBgcmV0YCwgYGNhbGwgKmAsIGBqbXAgKmAgbm90IHNhZmUgYmV5b25kIHRo
aXMgcG9pbnQuICovCi0gICAgICAgIFNQRUNfQ1RSTF9FWElUX1RPX1hFTiAg
ICAgLyogUmVxOiAlcjEyPWlzdF9leGl0ICVyMTQ9ZW5kLCBDbG9iOiBhYmNk
ICovCisgICAgICAgIFNQRUNfQ1RSTF9FWElUX1RPX1hFTiAvKiBSZXE6ICVy
MTI9aXN0X2V4aXQgJXIxND1lbmQgJXJzcD1yZWdzLCBDbG9iOiBhYmNkICov
CiAKICAgICAgICAgUkVTVE9SRV9BTEwgYWRqPTgKKworICAgICAgICAvKgor
ICAgICAgICAgKiBXaGVuIHRoZSBDUFUgcHVzaGVkIHRoaXMgZXhjZXB0aW9u
IGZyYW1lLCBpdCB6ZXJvLWV4dGVuZGVkIGVmbGFncy4KKyAgICAgICAgICog
Rm9yIGFuIElTVCBleGl0LCBTUEVDX0NUUkxfRVhJVF9UT19YRU4gc3Rhc2hl
ZCBzaGFkb3cgY29waWVzIG9mCisgICAgICAgICAqIHNwZWNfY3RybF9mbGFn
cyBhbmQgdmVyX3NlbCBhYm92ZSBlZmxhZ3MsIGFzIHdlIGNhbid0IHVzZSBh
bnkgR1BScywKKyAgICAgICAgICogYW5kIHdlJ3JlIGF0IGEgcmFuZG9tIHBs
YWNlIG9uIHRoZSBzdGFjaywgbm90IGluIGEgQ1BVRklORk8gYmxvY2suCisg
ICAgICAgICAqCisgICAgICAgICAqIEFjY291bnQgZm9yIGV2L2VjIGhhdmlu
ZyBhbHJlYWR5IGJlZW4gcG9wcGVkIG9mZiB0aGUgc3RhY2suCisgICAgICAg
ICAqLworICAgICAgICBTUEVDX0NUUkxfQ09ORF9WRVJXIFwKKyAgICAgICAg
ICAgIHNjZj1TVEtfUkVMKEVGUkFNRV9zaGFkb3dfc2NmLCBFRlJBTUVfcmlw
KSwgXAorICAgICAgICAgICAgc2VsPVNUS19SRUwoRUZSQU1FX3NoYWRvd19z
ZWwsIEVGUkFNRV9yaXApCisKICAgICAgICAgaXJldHEKIAogRU5UUlkoY29t
bW9uX2ludGVycnVwdCkK

--=separator
Content-Type: application/octet-stream; name="xsa452/xsa452-4.17-5.patch"
Content-Disposition: attachment; filename="xsa452/xsa452-4.17-5.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L3NwZWMtY3RybDogUmVuYW1lIFZFUlcgcmVsYXRl
ZCBvcHRpb25zCgpWRVJXIGlzIGdvaW5nIHRvIGJlIHVzZWQgZm9yIGEgM3Jk
IHB1cnBvc2UsIGFuZCB0aGUgZXhpc3Rpbmcgbm9tZW5jbGF0dXJlCmRpZG4n
dCBzdXJ2aXZlIHRoZSBTdGFsZSBNTUlPIGlzc3VlcyB0ZXJyaWJseSB3ZWxs
LgoKUmVuYW1lIHRoZSBjb21tYW5kIGxpbmUgb3B0aW9uIGZyb20gYG1kLWNs
ZWFyPWAgdG8gYHZlcnc9YC4gIFRoaXMgaXMgbW9yZQpjb25zaXN0ZW50IHdp
dGggb3RoZXIgb3B0aW9ucyB3aGljaCB0ZW5kIHRvIGJlIG5hbWVkIGJhc2Vk
IG9uIHdoYXQgdGhleSdyZQpkb2luZywgbm90IHdoaWNoIGZlYXR1cmUgZW51
bWVyYXRpb24gdGhleSB1c2UgYmVoaW5kIHRoZSBzY2VuZXMuICBSZXRhaW4K
YG1kLWNsZWFyPWAgYXMgYSBkZXByZWNhdGVkIGFsaWFzLgoKUmVuYW1lIG9w
dF9tZF9jbGVhcl97cHYsaHZtfSBhbmQgb3B0X2ZiX2NsZWFyX21taW8gdG8g
b3B0X3Zlcndfe3B2LGh2bSxtbWlvfSwKd2hpY2ggaGFzIGEgc2lkZSBlZmZl
Y3Qgb2YgbWFraW5nIHNwZWNfY3RybF9pbml0X2RvbWFpbigpIHJhdGhlciBj
bGVhcmVyIHRvCmZvbGxvdy4KCk5vIGZ1bmN0aW9uYWwgY2hhbmdlLgoKVGhp
cyBpcyBwYXJ0IG9mIFhTQS00NTIgLyBDVkUtMjAyMy0yODc0Ni4KClNpZ25l
ZC1vZmYtYnk6IEFuZHJldyBDb29wZXIgPGFuZHJldy5jb29wZXIzQGNpdHJp
eC5jb20+ClJldmlld2VkLWJ5OiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3Vz
ZS5jb20+CihjaGVycnkgcGlja2VkIGZyb20gY29tbWl0IGY3NjAzY2EyNTJl
NDIyNjczOWViMzEyOWE1MjkwZWUzZGEzZjhlYTQpCgpkaWZmIC0tZ2l0IGEv
ZG9jcy9taXNjL3hlbi1jb21tYW5kLWxpbmUucGFuZG9jIGIvZG9jcy9taXNj
L3hlbi1jb21tYW5kLWxpbmUucGFuZG9jCmluZGV4IDIwMDY2OTcyMjZkZS4u
ZDkwOWVjOTRmZTdjIDEwMDY0NAotLS0gYS9kb2NzL21pc2MveGVuLWNvbW1h
bmQtbGluZS5wYW5kb2MKKysrIGIvZG9jcy9taXNjL3hlbi1jb21tYW5kLWxp
bmUucGFuZG9jCkBAIC0yMzI0LDcgKzIzMjQsNyBAQCBCeSBkZWZhdWx0IFNT
QkQgd2lsbCBiZSBtaXRpZ2F0ZWQgYXQgcnVudGltZSAoaS5lIGBzc2JkPXJ1
bnRpbWVgKS4KIAogIyMjIHNwZWMtY3RybCAoeDg2KQogPiBgPSBMaXN0IG9m
IFsgPGJvb2w+LCB4ZW49PGJvb2w+LCB7cHYsaHZtfT08Ym9vbD4sCi0+ICAg
ICAgICAgICAgICB7bXNyLXNjLHJzYixtZC1jbGVhcixpYnBiLWVudHJ5fT08
Ym9vbD58e3B2LGh2bX09PGJvb2w+LAorPiAgICAgICAgICAgICAge21zci1z
Yyxyc2IsdmVydyxpYnBiLWVudHJ5fT08Ym9vbD58e3B2LGh2bX09PGJvb2w+
LAogPiAgICAgICAgICAgICAgYnRpLXRodW5rPXJldHBvbGluZXxsZmVuY2V8
am1wLCB7aWJycyxpYnBiLHNzYmQscHNmZCwKID4gICAgICAgICAgICAgIGVh
Z2VyLWZwdSxsMWQtZmx1c2gsYnJhbmNoLWhhcmRlbixzcmItbG9jaywKID4g
ICAgICAgICAgICAgIHVucHJpdi1tbWlvLGdkcy1taXQsZGl2LXNjcnVifT08
Ym9vbD4gXWAKQEAgLTIzNDksNyArMjM0OSw3IEBAIGluIHBsYWNlIGZvciBn
dWVzdHMgdG8gdXNlLgogCiBVc2Ugb2YgYSBwb3NpdGl2ZSBib29sZWFuIHZh
bHVlIGZvciBlaXRoZXIgb2YgdGhlc2Ugb3B0aW9ucyBpcyBpbnZhbGlkLgog
Ci1UaGUgYHB2PWAsIGBodm09YCwgYG1zci1zYz1gLCBgcnNiPWAsIGBtZC1j
bGVhcj1gIGFuZCBgaWJwYi1lbnRyeT1gIG9wdGlvbnMKK1RoZSBgcHY9YCwg
YGh2bT1gLCBgbXNyLXNjPWAsIGByc2I9YCwgYHZlcnc9YCBhbmQgYGlicGIt
ZW50cnk9YCBvcHRpb25zCiBvZmZlciBmaW5lIGdyYWluZWQgY29udHJvbCBv
dmVyIHRoZSBwcmltaXRpdmVzIGJ5IFhlbi4gIFRoZXNlIGltcGFjdCBYZW4n
cwogYWJpbGl0eSB0byBwcm90ZWN0IGl0c2VsZiwgYW5kL29yIFhlbidzIGFi
aWxpdHkgdG8gdmlydHVhbGlzZSBzdXBwb3J0IGZvcgogZ3Vlc3RzIHRvIHVz
ZS4KQEAgLTIzNjYsMTEgKzIzNjYsMTIgQEAgZ3Vlc3RzIHRvIHVzZS4KICAg
Z3Vlc3RzIGFuZCBpZiBkaXNhYmxlZCwgZ3Vlc3RzIHdpbGwgYmUgdW5hYmxl
IHRvIHVzZSBJQlJTL1NUSUJQL1NTQkQvZXRjLgogKiBgcnNiPWAgb2ZmZXJz
IGNvbnRyb2wgb3ZlciB3aGV0aGVyIHRvIG92ZXJ3cml0ZSB0aGUgUmV0dXJu
IFN0YWNrIEJ1ZmZlciAvCiAgIFJldHVybiBBZGRyZXNzIFN0YWNrIG9uIGVu
dHJ5IHRvIFhlbiBhbmQgb24gaWRsZS4KLSogYG1kLWNsZWFyPWAgb2ZmZXJz
IGNvbnRyb2wgb3ZlciB3aGV0aGVyIHRvIHVzZSBWRVJXIHRvIGZsdXNoCi0g
IG1pY3JvYXJjaGl0ZWN0dXJhbCBidWZmZXJzIG9uIGlkbGUgYW5kIGV4aXQg
ZnJvbSBYZW4uICAqTm90ZTogRm9yCi0gIGNvbXBhdGliaWxpdHkgd2l0aCBk
ZXZlbG9wbWVudCB2ZXJzaW9ucyBvZiB0aGlzIGZpeCwgYG1kcz1gIGlzIGFs
c28gYWNjZXB0ZWQKLSAgb24gWGVuIDQuMTIgYW5kIGVhcmxpZXIgYXMgYW4g
YWxpYXMuICBDb25zdWx0IHZlbmRvciBkb2N1bWVudGF0aW9uIGluCi0gIHBy
ZWZlcmVuY2UgdG8gaGVyZS4qCisqIGB2ZXJ3PWAgb2ZmZXJzIGNvbnRyb2wg
b3ZlciB3aGV0aGVyIHRvIHVzZSBWRVJXIGZvciBpdHMgc2NydWJiaW5nIHNp
ZGUKKyAgZWZmZWN0cyBhdCBhcHByb3ByaWF0ZSBwcml2aWxlZ2UgdHJhbnNp
dGlvbnMuICBUaGUgZXhhY3Qgc2lkZSBlZmZlY3RzIGFyZQorICBtaWNyb2Fy
Y2hpdGVjdHVyZSBhbmQgbWljcm9jb2RlIHNwZWNpZmljLiAgKk5vdGU6IGBt
ZC1jbGVhcj1gIGlzIGFjY2VwdGVkIGFzCisgIGEgZGVwcmVjYXRlZCBhbGlh
cy4gIEZvciBjb21wYXRpYmlsaXR5IHdpdGggZGV2ZWxvcG1lbnQgdmVyc2lv
bnMgb2YgWFNBLTI5NywKKyAgYG1kcz1gIGlzIGFsc28gYWNjZXB0ZWQgb24g
WGVuIDQuMTIgYW5kIGVhcmxpZXIgYXMgYW4gYWxpYXMuICBDb25zdWx0IHZl
bmRvcgorICBkb2N1bWVudGF0aW9uIGluIHByZWZlcmVuY2UgdG8gaGVyZS4q
CiAqIGBpYnBiLWVudHJ5PWAgb2ZmZXJzIGNvbnRyb2wgb3ZlciB3aGV0aGVy
IElCUEIgKEluZGlyZWN0IEJyYW5jaCBQcmVkaWN0aW9uCiAgIEJhcnJpZXIp
IGlzIHVzZWQgb24gZW50cnkgdG8gWGVuLiAgVGhpcyBpcyB1c2VkIGJ5IGRl
ZmF1bHQgb24gaGFyZHdhcmUKICAgdnVsbmVyYWJsZSB0byBCcmFuY2ggVHlw
ZSBDb25mdXNpb24sIGFuZCBoYXJkd2FyZSB2dWxuZXJhYmxlIHRvIFNwZWN1
bGF0aXZlCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYvc3BlY19jdHJsLmMg
Yi94ZW4vYXJjaC94ODYvc3BlY19jdHJsLmMKaW5kZXggMjVhMThhYzU5OGZh
Li5lMTJlYzk5MzBjZjcgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9zcGVj
X2N0cmwuYworKysgYi94ZW4vYXJjaC94ODYvc3BlY19jdHJsLmMKQEAgLTM3
LDggKzM3LDggQEAgc3RhdGljIGJvb2wgX19pbml0ZGF0YSBvcHRfbXNyX3Nj
X3B2ID0gdHJ1ZTsKIHN0YXRpYyBib29sIF9faW5pdGRhdGEgb3B0X21zcl9z
Y19odm0gPSB0cnVlOwogc3RhdGljIGludDhfdCBfX2luaXRkYXRhIG9wdF9y
c2JfcHYgPSAtMTsKIHN0YXRpYyBib29sIF9faW5pdGRhdGEgb3B0X3JzYl9o
dm0gPSB0cnVlOwotc3RhdGljIGludDhfdCBfX3JvX2FmdGVyX2luaXQgb3B0
X21kX2NsZWFyX3B2ID0gLTE7Ci1zdGF0aWMgaW50OF90IF9fcm9fYWZ0ZXJf
aW5pdCBvcHRfbWRfY2xlYXJfaHZtID0gLTE7CitzdGF0aWMgaW50OF90IF9f
cm9fYWZ0ZXJfaW5pdCBvcHRfdmVyd19wdiA9IC0xOworc3RhdGljIGludDhf
dCBfX3JvX2FmdGVyX2luaXQgb3B0X3ZlcndfaHZtID0gLTE7CiAKIHN0YXRp
YyBpbnQ4X3QgX19yb19hZnRlcl9pbml0IG9wdF9pYnBiX2VudHJ5X3B2ID0g
LTE7CiBzdGF0aWMgaW50OF90IF9fcm9fYWZ0ZXJfaW5pdCBvcHRfaWJwYl9l
bnRyeV9odm0gPSAtMTsKQEAgLTc4LDcgKzc4LDcgQEAgc3RhdGljIGJvb2wg
X19pbml0ZGF0YSBjcHVfaGFzX2J1Z19tZHM7IC8qIEFueSBvdGhlciBNe0xQ
LFNCLEZCfURTIGNvbWJpbmF0aW9uLgogCiBzdGF0aWMgaW50OF90IF9faW5p
dGRhdGEgb3B0X3NyYl9sb2NrID0gLTE7CiBzdGF0aWMgYm9vbCBfX2luaXRk
YXRhIG9wdF91bnByaXZfbW1pbzsKLXN0YXRpYyBib29sIF9fcm9fYWZ0ZXJf
aW5pdCBvcHRfZmJfY2xlYXJfbW1pbzsKK3N0YXRpYyBib29sIF9fcm9fYWZ0
ZXJfaW5pdCBvcHRfdmVyd19tbWlvOwogc3RhdGljIGludDhfdCBfX2luaXRk
YXRhIG9wdF9nZHNfbWl0ID0gLTE7CiBzdGF0aWMgaW50OF90IF9faW5pdGRh
dGEgb3B0X2Rpdl9zY3J1YiA9IC0xOwogCkBAIC0xMjAsOCArMTIwLDggQEAg
c3RhdGljIGludCBfX2luaXQgY2ZfY2hlY2sgcGFyc2Vfc3BlY19jdHJsKGNv
bnN0IGNoYXIgKnMpCiAgICAgICAgIGRpc2FibGVfY29tbW9uOgogICAgICAg
ICAgICAgb3B0X3JzYl9wdiA9IGZhbHNlOwogICAgICAgICAgICAgb3B0X3Jz
Yl9odm0gPSBmYWxzZTsKLSAgICAgICAgICAgIG9wdF9tZF9jbGVhcl9wdiA9
IDA7Ci0gICAgICAgICAgICBvcHRfbWRfY2xlYXJfaHZtID0gMDsKKyAgICAg
ICAgICAgIG9wdF92ZXJ3X3B2ID0gMDsKKyAgICAgICAgICAgIG9wdF92ZXJ3
X2h2bSA9IDA7CiAgICAgICAgICAgICBvcHRfaWJwYl9lbnRyeV9wdiA9IDA7
CiAgICAgICAgICAgICBvcHRfaWJwYl9lbnRyeV9odm0gPSAwOwogICAgICAg
ICAgICAgb3B0X2licGJfZW50cnlfZG9tMCA9IGZhbHNlOwpAQCAtMTUyLDE0
ICsxNTIsMTQgQEAgc3RhdGljIGludCBfX2luaXQgY2ZfY2hlY2sgcGFyc2Vf
c3BlY19jdHJsKGNvbnN0IGNoYXIgKnMpCiAgICAgICAgIHsKICAgICAgICAg
ICAgIG9wdF9tc3Jfc2NfcHYgPSB2YWw7CiAgICAgICAgICAgICBvcHRfcnNi
X3B2ID0gdmFsOwotICAgICAgICAgICAgb3B0X21kX2NsZWFyX3B2ID0gdmFs
OworICAgICAgICAgICAgb3B0X3ZlcndfcHYgPSB2YWw7CiAgICAgICAgICAg
ICBvcHRfaWJwYl9lbnRyeV9wdiA9IHZhbDsKICAgICAgICAgfQogICAgICAg
ICBlbHNlIGlmICggKHZhbCA9IHBhcnNlX2Jvb2xlYW4oImh2bSIsIHMsIHNz
KSkgPj0gMCApCiAgICAgICAgIHsKICAgICAgICAgICAgIG9wdF9tc3Jfc2Nf
aHZtID0gdmFsOwogICAgICAgICAgICAgb3B0X3JzYl9odm0gPSB2YWw7Ci0g
ICAgICAgICAgICBvcHRfbWRfY2xlYXJfaHZtID0gdmFsOworICAgICAgICAg
ICAgb3B0X3ZlcndfaHZtID0gdmFsOwogICAgICAgICAgICAgb3B0X2licGJf
ZW50cnlfaHZtID0gdmFsOwogICAgICAgICB9CiAgICAgICAgIGVsc2UgaWYg
KCAodmFsID0gcGFyc2VfYm9vbGVhbigibXNyLXNjIiwgcywgc3MpKSAhPSAt
MSApCkBAIC0yMDQsMjEgKzIwNCwyMiBAQCBzdGF0aWMgaW50IF9faW5pdCBj
Zl9jaGVjayBwYXJzZV9zcGVjX2N0cmwoY29uc3QgY2hhciAqcykKICAgICAg
ICAgICAgICAgICBicmVhazsKICAgICAgICAgICAgIH0KICAgICAgICAgfQot
ICAgICAgICBlbHNlIGlmICggKHZhbCA9IHBhcnNlX2Jvb2xlYW4oIm1kLWNs
ZWFyIiwgcywgc3MpKSAhPSAtMSApCisgICAgICAgIGVsc2UgaWYgKCAodmFs
ID0gcGFyc2VfYm9vbGVhbigidmVydyIsIHMsIHNzKSkgIT0gLTEgfHwKKyAg
ICAgICAgICAgICAgICAgICh2YWwgPSBwYXJzZV9ib29sZWFuKCJtZC1jbGVh
ciIsIHMsIHNzKSkgIT0gLTEgKQogICAgICAgICB7CiAgICAgICAgICAgICBz
d2l0Y2ggKCB2YWwgKQogICAgICAgICAgICAgewogICAgICAgICAgICAgY2Fz
ZSAwOgogICAgICAgICAgICAgY2FzZSAxOgotICAgICAgICAgICAgICAgIG9w
dF9tZF9jbGVhcl9wdiA9IG9wdF9tZF9jbGVhcl9odm0gPSB2YWw7CisgICAg
ICAgICAgICAgICAgb3B0X3ZlcndfcHYgPSBvcHRfdmVyd19odm0gPSB2YWw7
CiAgICAgICAgICAgICAgICAgYnJlYWs7CiAKICAgICAgICAgICAgIGNhc2Ug
LTI6Ci0gICAgICAgICAgICAgICAgcyArPSBzdHJsZW4oIm1kLWNsZWFyPSIp
OworICAgICAgICAgICAgICAgIHMgKz0gKCpzID09ICd2JykgPyBzdHJsZW4o
InZlcnc9IikgOiBzdHJsZW4oIm1kLWNsZWFyPSIpOwogICAgICAgICAgICAg
ICAgIGlmICggKHZhbCA9IHBhcnNlX2Jvb2xlYW4oInB2Iiwgcywgc3MpKSA+
PSAwICkKLSAgICAgICAgICAgICAgICAgICAgb3B0X21kX2NsZWFyX3B2ID0g
dmFsOworICAgICAgICAgICAgICAgICAgICBvcHRfdmVyd19wdiA9IHZhbDsK
ICAgICAgICAgICAgICAgICBlbHNlIGlmICggKHZhbCA9IHBhcnNlX2Jvb2xl
YW4oImh2bSIsIHMsIHNzKSkgPj0gMCApCi0gICAgICAgICAgICAgICAgICAg
IG9wdF9tZF9jbGVhcl9odm0gPSB2YWw7CisgICAgICAgICAgICAgICAgICAg
IG9wdF92ZXJ3X2h2bSA9IHZhbDsKICAgICAgICAgICAgICAgICBlbHNlCiAg
ICAgICAgICAgICBkZWZhdWx0OgogICAgICAgICAgICAgICAgICAgICByYyA9
IC1FSU5WQUw7CkBAIC01NDAsOCArNTQxLDggQEAgc3RhdGljIHZvaWQgX19p
bml0IHByaW50X2RldGFpbHMoZW51bSBpbmRfdGh1bmsgdGh1bmspCiAgICAg
ICAgICAgIG9wdF9zcmJfbG9jayAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgID8gIiBTUkJfTE9DSysiIDogIiBTUkJfTE9DSy0iLAogICAgICAgICAg
ICBvcHRfaWJwYl9jdHh0X3N3aXRjaCAgICAgICAgICAgICAgICAgICAgICA/
ICIgSUJQQi1jdHh0IiA6ICIiLAogICAgICAgICAgICBvcHRfbDFkX2ZsdXNo
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA/ICIgTDFEX0ZMVVNIIiA6
ICIiLAotICAgICAgICAgICBvcHRfbWRfY2xlYXJfcHYgfHwgb3B0X21kX2Ns
ZWFyX2h2bSB8fAotICAgICAgICAgICBvcHRfZmJfY2xlYXJfbW1pbyAgICAg
ICAgICAgICAgICAgICAgICAgICA/ICIgVkVSVyIgIDogIiIsCisgICAgICAg
ICAgIG9wdF92ZXJ3X3B2IHx8IG9wdF92ZXJ3X2h2bSB8fAorICAgICAgICAg
ICBvcHRfdmVyd19tbWlvICAgICAgICAgICAgICAgICAgICAgICAgICAgICA/
ICIgVkVSVyIgIDogIiIsCiAgICAgICAgICAgIG9wdF9kaXZfc2NydWIgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgID8gIiBESVYiIDogIiIsCiAgICAg
ICAgICAgIG9wdF9icmFuY2hfaGFyZGVuICAgICAgICAgICAgICAgICAgICAg
ICAgID8gIiBCUkFOQ0hfSEFSREVOIiA6ICIiKTsKIApAQCAtNTYyLDEzICs1
NjMsMTMgQEAgc3RhdGljIHZvaWQgX19pbml0IHByaW50X2RldGFpbHMoZW51
bSBpbmRfdGh1bmsgdGh1bmspCiAgICAgICAgICAgICBib290X2NwdV9oYXMo
WDg2X0ZFQVRVUkVfU0NfUlNCX0hWTSkgfHwKICAgICAgICAgICAgIGJvb3Rf
Y3B1X2hhcyhYODZfRkVBVFVSRV9JQlBCX0VOVFJZX0hWTSkgfHwKICAgICAg
ICAgICAgIGFtZF92aXJ0X3NwZWNfY3RybCB8fAotICAgICAgICAgICAgb3B0
X2VhZ2VyX2ZwdSB8fCBvcHRfbWRfY2xlYXJfaHZtKSAgICAgICA/ICIiICAg
ICAgICAgICAgICAgOiAiIE5vbmUiLAorICAgICAgICAgICAgb3B0X2VhZ2Vy
X2ZwdSB8fCBvcHRfdmVyd19odm0pICAgICAgICAgICA/ICIiICAgICAgICAg
ICAgICAgOiAiIE5vbmUiLAogICAgICAgICAgICBib290X2NwdV9oYXMoWDg2
X0ZFQVRVUkVfU0NfTVNSX0hWTSkgICAgICA/ICIgTVNSX1NQRUNfQ1RSTCIg
OiAiIiwKICAgICAgICAgICAgKGJvb3RfY3B1X2hhcyhYODZfRkVBVFVSRV9T
Q19NU1JfSFZNKSB8fAogICAgICAgICAgICAgYW1kX3ZpcnRfc3BlY19jdHJs
KSAgICAgICAgICAgICAgICAgICAgICA/ICIgTVNSX1ZJUlRfU1BFQ19DVFJM
IiA6ICIiLAogICAgICAgICAgICBib290X2NwdV9oYXMoWDg2X0ZFQVRVUkVf
U0NfUlNCX0hWTSkgICAgICA/ICIgUlNCIiAgICAgICAgICAgOiAiIiwKICAg
ICAgICAgICAgb3B0X2VhZ2VyX2ZwdSAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgPyAiIEVBR0VSX0ZQVSIgICAgIDogIiIsCi0gICAgICAgICAgIG9w
dF9tZF9jbGVhcl9odm0gICAgICAgICAgICAgICAgICAgICAgICAgID8gIiBN
RF9DTEVBUiIgICAgICA6ICIiLAorICAgICAgICAgICBvcHRfdmVyd19odm0g
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA/ICIgVkVSVyIgICAgICAg
ICAgOiAiIiwKICAgICAgICAgICAgYm9vdF9jcHVfaGFzKFg4Nl9GRUFUVVJF
X0lCUEJfRU5UUllfSFZNKSAgPyAiIElCUEItZW50cnkiICAgIDogIiIpOwog
CiAjZW5kaWYKQEAgLTU3NywxMSArNTc4LDExIEBAIHN0YXRpYyB2b2lkIF9f
aW5pdCBwcmludF9kZXRhaWxzKGVudW0gaW5kX3RodW5rIHRodW5rKQogICAg
ICAgICAgICAoYm9vdF9jcHVfaGFzKFg4Nl9GRUFUVVJFX1NDX01TUl9QVikg
fHwKICAgICAgICAgICAgIGJvb3RfY3B1X2hhcyhYODZfRkVBVFVSRV9TQ19S
U0JfUFYpIHx8CiAgICAgICAgICAgICBib290X2NwdV9oYXMoWDg2X0ZFQVRV
UkVfSUJQQl9FTlRSWV9QVikgfHwKLSAgICAgICAgICAgIG9wdF9lYWdlcl9m
cHUgfHwgb3B0X21kX2NsZWFyX3B2KSAgICAgICAgPyAiIiAgICAgICAgICAg
ICAgIDogIiBOb25lIiwKKyAgICAgICAgICAgIG9wdF9lYWdlcl9mcHUgfHwg
b3B0X3ZlcndfcHYpICAgICAgICAgICAgPyAiIiAgICAgICAgICAgICAgIDog
IiBOb25lIiwKICAgICAgICAgICAgYm9vdF9jcHVfaGFzKFg4Nl9GRUFUVVJF
X1NDX01TUl9QVikgICAgICAgPyAiIE1TUl9TUEVDX0NUUkwiIDogIiIsCiAg
ICAgICAgICAgIGJvb3RfY3B1X2hhcyhYODZfRkVBVFVSRV9TQ19SU0JfUFYp
ICAgICAgID8gIiBSU0IiICAgICAgICAgICA6ICIiLAogICAgICAgICAgICBv
cHRfZWFnZXJfZnB1ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA/ICIg
RUFHRVJfRlBVIiAgICAgOiAiIiwKLSAgICAgICAgICAgb3B0X21kX2NsZWFy
X3B2ICAgICAgICAgICAgICAgICAgICAgICAgICAgPyAiIE1EX0NMRUFSIiAg
ICAgIDogIiIsCisgICAgICAgICAgIG9wdF92ZXJ3X3B2ICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgID8gIiBWRVJXIiAgICAgICAgICA6ICIiLAog
ICAgICAgICAgICBib290X2NwdV9oYXMoWDg2X0ZFQVRVUkVfSUJQQl9FTlRS
WV9QVikgICA/ICIgSUJQQi1lbnRyeSIgICAgOiAiIik7CiAKICAgICBwcmlu
dGsoIiAgWFBUSSAoNjQtYml0IFBWIG9ubHkpOiBEb20wICVzLCBEb21VICVz
ICh3aXRoJXMgUENJRClcbiIsCkBAIC0xNTE0LDggKzE1MTUsOCBAQCB2b2lk
IHNwZWNfY3RybF9pbml0X2RvbWFpbihzdHJ1Y3QgZG9tYWluICpkKQogewog
ICAgIGJvb2wgcHYgPSBpc19wdl9kb21haW4oZCk7CiAKLSAgICBib29sIHZl
cncgPSAoKHB2ID8gb3B0X21kX2NsZWFyX3B2IDogb3B0X21kX2NsZWFyX2h2
bSkgfHwKLSAgICAgICAgICAgICAgICAgKG9wdF9mYl9jbGVhcl9tbWlvICYm
IGlzX2lvbW11X2VuYWJsZWQoZCkpKTsKKyAgICBib29sIHZlcncgPSAoKHB2
ID8gb3B0X3ZlcndfcHYgOiBvcHRfdmVyd19odm0pIHx8CisgICAgICAgICAg
ICAgICAgIChvcHRfdmVyd19tbWlvICYmIGlzX2lvbW11X2VuYWJsZWQoZCkp
KTsKIAogICAgIGJvb2wgaWJwYiA9ICgocHYgPyBvcHRfaWJwYl9lbnRyeV9w
diA6IG9wdF9pYnBiX2VudHJ5X2h2bSkgJiYKICAgICAgICAgICAgICAgICAg
KGQtPmRvbWFpbl9pZCAhPSAwIHx8IG9wdF9pYnBiX2VudHJ5X2RvbTApKTsK
QEAgLTE4NzgsMTkgKzE4NzksMjAgQEAgdm9pZCBfX2luaXQgaW5pdF9zcGVj
dWxhdGlvbl9taXRpZ2F0aW9ucyh2b2lkKQogICAgICAqIHRoZSByZXR1cm4t
dG8tZ3Vlc3QgcGF0aC4KICAgICAgKi8KICAgICBpZiAoIG9wdF91bnByaXZf
bW1pbyApCi0gICAgICAgIG9wdF9mYl9jbGVhcl9tbWlvID0gY3B1X2hhc19m
Yl9jbGVhcjsKKyAgICAgICAgb3B0X3ZlcndfbW1pbyA9IGNwdV9oYXNfZmJf
Y2xlYXI7CiAKICAgICAvKgogICAgICAqIEJ5IGRlZmF1bHQsIGVuYWJsZSBQ
ViBhbmQgSFZNIG1pdGlnYXRpb25zIG9uIE1EUy12dWxuZXJhYmxlIGhhcmR3
YXJlLgogICAgICAqIFRoaXMgd2lsbCBvbmx5IGJlIGEgdG9rZW4gZWZmb3J0
IGZvciBNTFBEUy9NRkJEUyB3aGVuIEhUIGlzIGVuYWJsZWQsCiAgICAgICog
YnV0IGl0IGlzIHNvbWV3aGF0IGJldHRlciB0aGFuIG5vdGhpbmcuCiAgICAg
ICovCi0gICAgaWYgKCBvcHRfbWRfY2xlYXJfcHYgPT0gLTEgKQotICAgICAg
ICBvcHRfbWRfY2xlYXJfcHYgPSAoKGNwdV9oYXNfYnVnX21kcyB8fCBjcHVf
aGFzX2J1Z19tc2Jkc19vbmx5KSAmJgotICAgICAgICAgICAgICAgICAgICAg
ICAgICAgYm9vdF9jcHVfaGFzKFg4Nl9GRUFUVVJFX01EX0NMRUFSKSk7Ci0g
ICAgaWYgKCBvcHRfbWRfY2xlYXJfaHZtID09IC0xICkKLSAgICAgICAgb3B0
X21kX2NsZWFyX2h2bSA9ICgoY3B1X2hhc19idWdfbWRzIHx8IGNwdV9oYXNf
YnVnX21zYmRzX29ubHkpICYmCi0gICAgICAgICAgICAgICAgICAgICAgICAg
ICAgYm9vdF9jcHVfaGFzKFg4Nl9GRUFUVVJFX01EX0NMRUFSKSk7CisgICAg
aWYgKCBvcHRfdmVyd19wdiA9PSAtMSApCisgICAgICAgIG9wdF92ZXJ3X3B2
ID0gKChjcHVfaGFzX2J1Z19tZHMgfHwgY3B1X2hhc19idWdfbXNiZHNfb25s
eSkgJiYKKyAgICAgICAgICAgICAgICAgICAgICAgY3B1X2hhc19tZF9jbGVh
cik7CisKKyAgICBpZiAoIG9wdF92ZXJ3X2h2bSA9PSAtMSApCisgICAgICAg
IG9wdF92ZXJ3X2h2bSA9ICgoY3B1X2hhc19idWdfbWRzIHx8IGNwdV9oYXNf
YnVnX21zYmRzX29ubHkpICYmCisgICAgICAgICAgICAgICAgICAgICAgICBj
cHVfaGFzX21kX2NsZWFyKTsKIAogICAgIC8qCiAgICAgICogRW5hYmxlIE1E
Uy9NTUlPIGRlZmVuY2VzIGFzIGFwcGxpY2FibGUuICBUaGUgSWRsZSBibG9j
a3MgbmVlZCB1c2luZyBpZgpAQCAtMTkwMywxMiArMTkwNSwxMiBAQCB2b2lk
IF9faW5pdCBpbml0X3NwZWN1bGF0aW9uX21pdGlnYXRpb25zKHZvaWQpCiAg
ICAgICogTURTIG1pdGlnYXRpb25zLiAgTDFEX0ZMVVNIIGlzIG5vdCBzYWZl
IGZvciBNTUlPIG1pdGlnYXRpb25zLikKICAgICAgKgogICAgICAqIEFmdGVy
IGNhbGN1bGF0aW5nIHRoZSBhcHByb3ByaWF0ZSBpZGxlIHNldHRpbmcsIHNp
bXBsaWZ5Ci0gICAgICogb3B0X21kX2NsZWFyX2h2bSB0byBtZWFuIGp1c3Qg
InNob3VsZCB3ZSBWRVJXIG9uIHRoZSB3YXkgaW50byBIVk0KKyAgICAgKiBv
cHRfdmVyd19odm0gdG8gbWVhbiBqdXN0ICJzaG91bGQgd2UgVkVSVyBvbiB0
aGUgd2F5IGludG8gSFZNCiAgICAgICogZ3Vlc3RzIiwgc28gc3BlY19jdHJs
X2luaXRfZG9tYWluKCkgY2FuIGNhbGN1bGF0ZSBzdWl0YWJsZSBzZXR0aW5n
cy4KICAgICAgKi8KLSAgICBpZiAoIG9wdF9tZF9jbGVhcl9wdiB8fCBvcHRf
bWRfY2xlYXJfaHZtIHx8IG9wdF9mYl9jbGVhcl9tbWlvICkKKyAgICBpZiAo
IG9wdF92ZXJ3X3B2IHx8IG9wdF92ZXJ3X2h2bSB8fCBvcHRfdmVyd19tbWlv
ICkKICAgICAgICAgc2V0dXBfZm9yY2VfY3B1X2NhcChYODZfRkVBVFVSRV9T
Q19WRVJXX0lETEUpOwotICAgIG9wdF9tZF9jbGVhcl9odm0gJj0gIWNwdV9o
YXNfc2tpcF9sMWRmbCAmJiAhb3B0X2wxZF9mbHVzaDsKKyAgICBvcHRfdmVy
d19odm0gJj0gIWNwdV9oYXNfc2tpcF9sMWRmbCAmJiAhb3B0X2wxZF9mbHVz
aDsKIAogICAgIC8qCiAgICAgICogV2FybiB0aGUgdXNlciBpZiB0aGV5IGFy
ZSBvbiBNTFBEUy9NRkJEUy12dWxuZXJhYmxlIGhhcmR3YXJlIHdpdGggSFQK

--=separator
Content-Type: application/octet-stream; name="xsa452/xsa452-4.17-6.patch"
Content-Disposition: attachment; filename="xsa452/xsa452-4.17-6.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L3NwZWMtY3RybDogVkVSVy1oYW5kbGluZyBhZGp1
c3RtZW50cwoKLi4uIGJlZm9yZSB3ZSBhZGQgeWV0IG1vcmUgY29tcGxleGl0
eSB0byB0aGlzIGxvZ2ljLiAgTW9zdGx5IGV4cGFuZGVkCmNvbW1lbnRzLCBi
dXQgd2l0aCB0aHJlZSBtaW5vciBjaGFuZ2VzLgoKMSkgSW50cm9kdWNlIGNw
dV9oYXNfdXNlZnVsX21kX2NsZWFyIHRvIHNpbXBsaWZ5IGxhdGVyIGxvZ2lj
IGluIHRoaXMgcGF0Y2ggYW5kCiAgIGZ1dHVyZSBvbmVzLgoKMikgV2Ugb25s
eSBldmVyIG5lZWQgU0NfVkVSV19JRExFIHdoZW4gU01UIGlzIGFjdGl2ZS4g
IElmIFNNVCBpc24ndCBhY3RpdmUsCiAgIHRoZW4gdGhlcmUncyBubyByZS1w
YXJ0aXRpb24gb2YgcGlwZWxpbmUgcmVzb3VyY2VzIGJhc2VkIG9uIHRocmVh
ZC1pZGxlbmVzcwogICB0byB3b3JyeSBhYm91dC4KCjMpIFRoZSBsb2dpYyB0
byBhZGp1c3QgSFZNIFZFUlcgYmFzZWQgb24gTDFEX0ZMVVNIIGlzIHVubWFp
bnRhaW5hYmxlIGFuZCwgYXMKICAgaXQgdHVybnMgb3V0LCB3cm9uZy4gIFNL
SVBfTDFERkwgaXMganVzdCBhIGhpbnQgYml0LCB3aGVyZWFzIG9wdF9sMWRf
Zmx1c2gKICAgaXMgdGhlIHJlbGV2YW50IGRlY2lzaW9uIG9mIHdoZXRoZXIg
dG8gdXNlIEwxRF9GTFVTSCBiYXNlZCBvbgogICBzdXNjZXB0aWJpbGl0eSBh
bmQgdXNlciBwcmVmZXJlbmNlLgoKICAgUmV3cml0ZSB0aGUgbG9naWMgc28g
aXQgY2FuIGJlIGZvbGxvd2VkLCBhbmQgaW5jb3Jwb3JhdGUgdGhlIGZhY3Qg
dGhhdCB3aGVuCiAgIEZCX0NMRUFSIGlzIHZpc2libGUsIEwxRF9GTFVTSCBp
c24ndCBhIHNhZmUgc3Vic3RpdHV0aW9uLgoKVGhpcyBpcyBwYXJ0IG9mIFhT
QS00NTIgLyBDVkUtMjAyMy0yODc0Ni4KClNpZ25lZC1vZmYtYnk6IEFuZHJl
dyBDb29wZXIgPGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+CkFja2VkLWJ5
OiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+CihjaGVycnkgcGlj
a2VkIGZyb20gY29tbWl0IDFlYjkxYThhMDYyMzBiNGI2NDIyOGM5YTM4MDE5
NGY4Y2ZlNmM1ZTIpCgpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L3NwZWNf
Y3RybC5jIGIveGVuL2FyY2gveDg2L3NwZWNfY3RybC5jCmluZGV4IGUxMmVj
OTkzMGNmNy4uYWRiNmJjNzRlOGU2IDEwMDY0NAotLS0gYS94ZW4vYXJjaC94
ODYvc3BlY19jdHJsLmMKKysrIGIveGVuL2FyY2gveDg2L3NwZWNfY3RybC5j
CkBAIC0xNTMxLDcgKzE1MzEsNyBAQCB2b2lkIF9faW5pdCBpbml0X3NwZWN1
bGF0aW9uX21pdGlnYXRpb25zKHZvaWQpCiB7CiAgICAgZW51bSBpbmRfdGh1
bmsgdGh1bmsgPSBUSFVOS19ERUZBVUxUOwogICAgIGJvb2wgaGFzX3NwZWNf
Y3RybCwgaWJycyA9IGZhbHNlLCBod19zbXRfZW5hYmxlZDsKLSAgICBib29s
IGNwdV9oYXNfYnVnX3RhYSwgcmV0cG9saW5lX3NhZmU7CisgICAgYm9vbCBj
cHVfaGFzX2J1Z190YWEsIGNwdV9oYXNfdXNlZnVsX21kX2NsZWFyLCByZXRw
b2xpbmVfc2FmZTsKIAogICAgIGh3X3NtdF9lbmFibGVkID0gY2hlY2tfc210
X2VuYWJsZWQoKTsKIApAQCAtMTg2Nyw1MCArMTg2Nyw5NyBAQCB2b2lkIF9f
aW5pdCBpbml0X3NwZWN1bGF0aW9uX21pdGlnYXRpb25zKHZvaWQpCiAgICAg
ICAgICAgICAiZW5hYmxlZC4gIFBsZWFzZSBhc3Nlc3MgeW91ciBjb25maWd1
cmF0aW9uIGFuZCBjaG9vc2UgYW5cbiIKICAgICAgICAgICAgICJleHBsaWNp
dCAnc210PTxib29sPicgc2V0dGluZy4gIFNlZSBYU0EtMjczLlxuIik7CiAK
KyAgICAvKgorICAgICAqIEEgYnJpZWYgc3VtbWFyeSBvZiBWRVJXLXJlbGF0
ZWQgY2hhbmdlcy4KKyAgICAgKgorICAgICAqIGh0dHBzOi8vd3d3LmludGVs
LmNvbS9jb250ZW50L3d3dy91cy9lbi9kZXZlbG9wZXIvYXJ0aWNsZXMvdGVj
aG5pY2FsL3NvZnR3YXJlLXNlY3VyaXR5LWd1aWRhbmNlL3RlY2huaWNhbC1k
b2N1bWVudGF0aW9uL2ludGVsLWFuYWx5c2lzLW1pY3JvYXJjaGl0ZWN0dXJh
bC1kYXRhLXNhbXBsaW5nLmh0bWwKKyAgICAgKiBodHRwczovL3d3dy5pbnRl
bC5jb20vY29udGVudC93d3cvdXMvZW4vZGV2ZWxvcGVyL2FydGljbGVzL3Rl
Y2huaWNhbC9zb2Z0d2FyZS1zZWN1cml0eS1ndWlkYW5jZS90ZWNobmljYWwt
ZG9jdW1lbnRhdGlvbi9wcm9jZXNzb3ItbW1pby1zdGFsZS1kYXRhLXZ1bG5l
cmFiaWxpdGllcy5odG1sCisgICAgICoKKyAgICAgKiBSZWxldmFudCB1Y29k
ZXM6CisgICAgICoKKyAgICAgKiAtIE1heSAyMDE5LCBmb3IgTURTLiAgSW50
cm9kdWNlcyB0aGUgTURfQ0xFQVIgQ1BVSUQgYml0IGFuZCBWRVJXIHNpZGUK
KyAgICAgKiAgIGVmZmVjdHMgdG8gc2NydWIgU3RvcmUvTG9hZC9GaWxsIGJ1
ZmZlcnMgYXMgYXBwbGljYWJsZS4gIE1EX0NMRUFSCisgICAgICogICBleGlz
dHMgYXJjaGl0ZWN0dXJhbGx5LCBldmVuIHdoZW4gdGhlIHNpZGUgZWZmZWN0
cyBoYXZlIGJlZW4gcmVtb3ZlZC4KKyAgICAgKgorICAgICAqICAgVXNlIFZF
UlcgdG8gc2NydWIgb24gcmV0dXJuLXRvLWd1ZXN0LiAgUGFydHMgd2l0aCBM
MURfRkxVU0ggdG8KKyAgICAgKiAgIG1pdGlnYXRlIEwxVEYgaGF2ZSB0aGUg
c2FtZSBzaWRlIGVmZmVjdCwgc28gbm8gbmVlZCB0byBkbyBib3RoLgorICAg
ICAqCisgICAgICogICBWYXJpb3VzIEF0b21zIHN1ZmZlciBmcm9tIFN0b3Jl
LWJ1ZmZlciBzYW1wbGluZyBvbmx5LiAgU3RvcmUgYnVmZmVycworICAgICAq
ICAgYXJlIHN0YXRpY2FsbHkgcGFydGl0aW9uZWQgYmV0d2VlbiBub24taWRs
ZSB0aHJlYWRzLCBzbyBzY3J1YmJpbmcgaXMKKyAgICAgKiAgIHdhbnRlZCB3
aGVuIGdvaW5nIGlkbGUgdG9vLgorICAgICAqCisgICAgICogICBMb2FkIHBv
cnRzIGFuZCBGaWxsIGJ1ZmZlcnMgYXJlIGNvbXBldGl0aXZlbHkgc2hhcmVk
IGJldHdlZW4gdGhyZWFkcy4KKyAgICAgKiAgIFNNVCBtdXN0IGJlIGRpc2Fi
bGVkIGZvciBWRVJXIHNjcnViYmluZyB0byBiZSBmdWxseSBlZmZlY3RpdmUu
CisgICAgICoKKyAgICAgKiAtIE5vdmVtYmVyIDIwMTksIGZvciBUQUEuICBF
eHRlbmRlZCBWRVJXIHNpZGUgZWZmZWN0cyB0byBUU1gtZW5hYmxlZAorICAg
ICAqICAgTURTX05PIHBhcnRzLgorICAgICAqCisgICAgICogLSBGZWJydWFy
eSAyMDIyLCBmb3IgQ2xpZW50IFRTWCBkZS1mZWF0dXJlLiAgUmVtb3ZlZCBW
RVJXIHNpZGUgZWZmZWN0cworICAgICAqICAgZnJvbSBDbGllbnQgQ1BVcyBv
bmx5LgorICAgICAqCisgICAgICogLSBNYXkgMjAyMiwgZm9yIE1NSU8gU3Rh
bGUgRGF0YS4gIChSZSlpbnRyb2R1Y2VkIEZpbGwgQnVmZmVyIHNjcnViYmlu
ZworICAgICAqICAgb24gYWxsIE1NSU8tYWZmZWN0ZWQgcGFydHMgd2hpY2gg
ZGlkbid0IGFscmVhZHkgaGF2ZSBpdCBmb3IgTURTCisgICAgICogICByZWFz
b25zLCBlbnVtZXJhdGluZyBGQl9DTEVBUiBvbiB0aG9zZSBwYXJ0cyBvbmx5
LgorICAgICAqCisgICAgICogICBJZiBGQl9DTEVBUiBpcyBlbnVtZXJhdGVk
LCBMMURfRkxVU0ggZG9lcyBub3QgaGF2ZSB0aGUgc2FtZSBzY3J1YmJpbmcK
KyAgICAgKiAgIHNpZGUgZWZmZWN0cyBhcyBWRVJXIGFuZCBjYW5ub3QgYmUg
dXNlZCBpbiBpdHMgcGxhY2UuCisgICAgICovCiAgICAgbWRzX2NhbGN1bGF0
aW9ucygpOwogCiAgICAgLyoKLSAgICAgKiBQYXJ0cyB3aGljaCBlbnVtZXJh
dGUgRkJfQ0xFQVIgYXJlIHRob3NlIHdoaWNoIGFyZSBwb3N0LU1EU19OTyBh
bmQgaGF2ZQotICAgICAqIHJlaW50cm9kdWNlZCB0aGUgVkVSVyBmaWxsIGJ1
ZmZlciBmbHVzaGluZyBzaWRlIGVmZmVjdCBiZWNhdXNlIG9mIGEKLSAgICAg
KiBzdXNjZXB0aWJpbGl0eSB0byBGQlNEUC4KKyAgICAgKiBQYXJ0cyB3aGlj
aCBlbnVtZXJhdGUgRkJfQ0xFQVIgYXJlIHRob3NlIHdpdGggbm93LXVwZGF0
ZWQgbWljcm9jb2RlCisgICAgICogd2hpY2ggd2VyZW4ndCBzdXNjZXB0aWJs
ZSB0byB0aGUgb3JpZ2luYWwgTUZCRFMgKGFuZCB0aGVyZWZvcmUgZGlkbid0
CisgICAgICogaGF2ZSBGaWxsIEJ1ZmZlciBzY3J1YmJpbmcgc2lkZSBlZmZl
Y3RzIHRvIGJlZ2luIHdpdGgsIG9yIHdlcmUgQ2xpZW50CisgICAgICogTURT
X05PIG5vbi1UQUFfTk8gcGFydHMgd2hlcmUgdGhlIHNjcnViYmluZyB3YXMg
cmVtb3ZlZCksIGJ1dCBoYXZlIGhhZAorICAgICAqIHRoZSBzY3J1YmJpbmcg
cmVpbnRyb2R1Y2VkIGJlY2F1c2Ugb2YgYSBzdXNjZXB0aWJpbGl0eSB0byBG
QlNEUC4KICAgICAgKgogICAgICAqIElmIHVucHJpdmlsZWdlZCBndWVzdHMg
aGF2ZSAob3Igd2lsbCBoYXZlKSBNTUlPIG1hcHBpbmdzLCB3ZSBjYW4KICAg
ICAgKiBtaXRpZ2F0ZSBjcm9zcy1kb21haW4gbGVha2FnZSBvZiBmaWxsIGJ1
ZmZlciBkYXRhIGJ5IGlzc3VpbmcgVkVSVyBvbgotICAgICAqIHRoZSByZXR1
cm4tdG8tZ3Vlc3QgcGF0aC4KKyAgICAgKiB0aGUgcmV0dXJuLXRvLWd1ZXN0
IHBhdGguICBUaGlzIGlzIG9ubHkgYSB0b2tlbiBlZmZvcnQgaWYgU01UIGlz
CisgICAgICogYWN0aXZlLgogICAgICAqLwogICAgIGlmICggb3B0X3VucHJp
dl9tbWlvICkKICAgICAgICAgb3B0X3ZlcndfbW1pbyA9IGNwdV9oYXNfZmJf
Y2xlYXI7CiAKICAgICAvKgotICAgICAqIEJ5IGRlZmF1bHQsIGVuYWJsZSBQ
ViBhbmQgSFZNIG1pdGlnYXRpb25zIG9uIE1EUy12dWxuZXJhYmxlIGhhcmR3
YXJlLgotICAgICAqIFRoaXMgd2lsbCBvbmx5IGJlIGEgdG9rZW4gZWZmb3J0
IGZvciBNTFBEUy9NRkJEUyB3aGVuIEhUIGlzIGVuYWJsZWQsCi0gICAgICog
YnV0IGl0IGlzIHNvbWV3aGF0IGJldHRlciB0aGFuIG5vdGhpbmcuCisgICAg
ICogTURfQ0xFQVIgaXMgZW51bWVyYXRlZCBhcmNoaXRlY3R1cmFsbHkgZm9y
ZXZlcm1vcmUsIGV2ZW4gYWZ0ZXIgdGhlCisgICAgICogc2NydWJiaW5nIHNp
ZGUgZWZmZWN0cyBoYXZlIGJlZW4gcmVtb3ZlZC4gIENyZWF0ZSBvdXJzZWx2
ZXMgYW4gdmVyc2lvbgorICAgICAqIHdoaWNoIGV4cHJlc3NlZCB3aGV0aGVy
IHdlIHRoaW5rIE1EX0NMRUFSIGlzIGhhdmluZyBhbnkgdXNlZnVsIHNpZGUK
KyAgICAgKiBlZmZlY3QuCisgICAgICovCisgICAgY3B1X2hhc191c2VmdWxf
bWRfY2xlYXIgPSAoY3B1X2hhc19tZF9jbGVhciAmJgorICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIChjcHVfaGFzX2J1Z19tZHMgfHwgY3B1X2hh
c19idWdfbXNiZHNfb25seSkpOworCisgICAgLyoKKyAgICAgKiBCeSBkZWZh
dWx0LCB1c2UgVkVSVyBzY3J1YmJpbmcgb24gYXBwbGljYWJsZSBoYXJkd2Fy
ZSwgaWYgd2UgdGhpbmsgaXQncworICAgICAqIGdvaW5nIHRvIGhhdmUgYW4g
ZWZmZWN0LiAgVGhpcyB3aWxsIG9ubHkgYmUgYSB0b2tlbiBlZmZvcnQgZm9y
CisgICAgICogTUxQRFMvTUZCRFMgd2hlbiBTTVQgaXMgZW5hYmxlZC4KICAg
ICAgKi8KICAgICBpZiAoIG9wdF92ZXJ3X3B2ID09IC0xICkKLSAgICAgICAg
b3B0X3ZlcndfcHYgPSAoKGNwdV9oYXNfYnVnX21kcyB8fCBjcHVfaGFzX2J1
Z19tc2Jkc19vbmx5KSAmJgotICAgICAgICAgICAgICAgICAgICAgICBjcHVf
aGFzX21kX2NsZWFyKTsKKyAgICAgICAgb3B0X3ZlcndfcHYgPSBjcHVfaGFz
X3VzZWZ1bF9tZF9jbGVhcjsKIAogICAgIGlmICggb3B0X3ZlcndfaHZtID09
IC0xICkKLSAgICAgICAgb3B0X3ZlcndfaHZtID0gKChjcHVfaGFzX2J1Z19t
ZHMgfHwgY3B1X2hhc19idWdfbXNiZHNfb25seSkgJiYKLSAgICAgICAgICAg
ICAgICAgICAgICAgIGNwdV9oYXNfbWRfY2xlYXIpOworICAgICAgICBvcHRf
dmVyd19odm0gPSBjcHVfaGFzX3VzZWZ1bF9tZF9jbGVhcjsKIAogICAgIC8q
Ci0gICAgICogRW5hYmxlIE1EUy9NTUlPIGRlZmVuY2VzIGFzIGFwcGxpY2Fi
bGUuICBUaGUgSWRsZSBibG9ja3MgbmVlZCB1c2luZyBpZgotICAgICAqIGVp
dGhlciB0aGUgUFYgb3IgSFZNIE1EUyBkZWZlbmNlcyBhcmUgdXNlZCwgb3Ig
aWYgd2UgbWF5IGdpdmUgTU1JTwotICAgICAqIGFjY2VzcyB0byB1bnRydXN0
ZWQgZ3Vlc3RzLgotICAgICAqCi0gICAgICogSFZNIGlzIG1vcmUgY29tcGxp
Y2F0ZWQuICBUaGUgTURfQ0xFQVIgbWljcm9jb2RlIGV4dGVuZHMgTDFEX0ZM
VVNIIHdpdGgKLSAgICAgKiBlcXVpdmFsZW50IHNlbWFudGljcyB0byBhdm9p
ZCBuZWVkaW5nIHRvIHBlcmZvcm0gYm90aCBmbHVzaGVzIG9uIHRoZQotICAg
ICAqIEhWTSBwYXRoLiAgVGhlcmVmb3JlLCB3ZSBkb24ndCBuZWVkIFZFUlcg
aW4gYWRkaXRpb24gdG8gTDFEX0ZMVVNIIChmb3IKLSAgICAgKiBNRFMgbWl0
aWdhdGlvbnMuICBMMURfRkxVU0ggaXMgbm90IHNhZmUgZm9yIE1NSU8gbWl0
aWdhdGlvbnMuKQotICAgICAqCi0gICAgICogQWZ0ZXIgY2FsY3VsYXRpbmcg
dGhlIGFwcHJvcHJpYXRlIGlkbGUgc2V0dGluZywgc2ltcGxpZnkKLSAgICAg
KiBvcHRfdmVyd19odm0gdG8gbWVhbiBqdXN0ICJzaG91bGQgd2UgVkVSVyBv
biB0aGUgd2F5IGludG8gSFZNCi0gICAgICogZ3Vlc3RzIiwgc28gc3BlY19j
dHJsX2luaXRfZG9tYWluKCkgY2FuIGNhbGN1bGF0ZSBzdWl0YWJsZSBzZXR0
aW5ncy4KKyAgICAgKiBJZiBTTVQgaXMgYWN0aXZlLCBhbmQgd2UncmUgcHJv
dGVjdGluZyBhZ2FpbnN0IE1EUyBvciBNTUlPIHN0YWxlIGRhdGEsCisgICAg
ICogd2UgbmVlZCB0byBzY3J1YiBiZWZvcmUgZ29pbmcgaWRsZSBhcyB3ZWxs
IGFzIG9uIHJldHVybiB0byBndWVzdC4KKyAgICAgKiBWYXJpb3VzIHBpcGVs
aW5lIHJlc291cmNlcyBhcmUgcmVwYXJ0aXRpb25lZCBhbW9uZ3N0IG5vbi1p
ZGxlIHRocmVhZHMuCiAgICAgICovCi0gICAgaWYgKCBvcHRfdmVyd19wdiB8
fCBvcHRfdmVyd19odm0gfHwgb3B0X3ZlcndfbW1pbyApCisgICAgaWYgKCAo
KGNwdV9oYXNfdXNlZnVsX21kX2NsZWFyICYmIChvcHRfdmVyd19wdiB8fCBv
cHRfdmVyd19odm0pKSB8fAorICAgICAgICAgIG9wdF92ZXJ3X21taW8pICYm
IGh3X3NtdF9lbmFibGVkICkKICAgICAgICAgc2V0dXBfZm9yY2VfY3B1X2Nh
cChYODZfRkVBVFVSRV9TQ19WRVJXX0lETEUpOwotICAgIG9wdF92ZXJ3X2h2
bSAmPSAhY3B1X2hhc19za2lwX2wxZGZsICYmICFvcHRfbDFkX2ZsdXNoOwor
CisgICAgLyoKKyAgICAgKiBBZnRlciBjYWxjdWxhdGluZyB0aGUgYXBwcm9w
cmlhdGUgaWRsZSBzZXR0aW5nLCBzaW1wbGlmeSBvcHRfdmVyd19odm0KKyAg
ICAgKiB0byBtZWFuIGp1c3QgInNob3VsZCB3ZSBWRVJXIG9uIHRoZSB3YXkg
aW50byBIVk0gZ3Vlc3RzIiwgc28KKyAgICAgKiBzcGVjX2N0cmxfaW5pdF9k
b21haW4oKSBjYW4gY2FsY3VsYXRlIHN1aXRhYmxlIHNldHRpbmdzLgorICAg
ICAqCisgICAgICogSXQgaXMgb25seSBzYWZlIHRvIHVzZSBMMURfRkxVU0gg
aW4gcGxhY2Ugb2YgVkVSVyB3aGVuIE1EX0NMRUFSIGlzIHRoZQorICAgICAq
IG9ubHkgKl9DTEVBUiB3ZSBjYW4gc2VlLgorICAgICAqLworICAgIGlmICgg
b3B0X2wxZF9mbHVzaCAmJiBjcHVfaGFzX21kX2NsZWFyICYmICFjcHVfaGFz
X2ZiX2NsZWFyICkKKyAgICAgICAgb3B0X3ZlcndfaHZtID0gZmFsc2U7CiAK
ICAgICAvKgogICAgICAqIFdhcm4gdGhlIHVzZXIgaWYgdGhleSBhcmUgb24g
TUxQRFMvTUZCRFMtdnVsbmVyYWJsZSBoYXJkd2FyZSB3aXRoIEhUCg==

--=separator
Content-Type: application/octet-stream; name="xsa452/xsa452-4.17-7.patch"
Content-Disposition: attachment; filename="xsa452/xsa452-4.17-7.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L3NwZWMtY3RybDogTWl0aWdhdGlvbiBSZWdpc3Rl
ciBGaWxlIERhdGEgU2FtcGxpbmcKClJGRFMgYWZmZWN0cyBBdG9tIGNvcmVz
LCBhbHNvIGJyYW5kZWQgRS1jb3JlcywgYmV0d2VlbiB0aGUgR29sZG1vbnQg
YW5kCkdyYWNlbW9udCBtaWNyb2FyY2hpdGVjdHVyZXMuICBUaGlzIGluY2x1
ZGVzIEFsZGVyIExha2UgYW5kIFJhcHRvciBMYWtlIGh5YnJpZApjbGllbiBz
eXN0ZW1zIHdoaWNoIGhhdmUgYSBtaXggb2YgR3JhY2Vtb250IGFuZCBvdGhl
ciB0eXBlcyBvZiBjb3Jlcy4KClR3byBuZXcgYml0cyBoYXZlIGJlZW4gZGVm
aW5lZDsgUkZEU19DTEVBUiB0byBpbmRpY2F0ZSBWRVJXIGhhcyBtb3JlIHNp
ZGUKZWZmZXRzLCBhbmQgUkZEU19OTyB0byBpbmNpZGF0ZSB0aGF0IHRoZSBz
eXN0ZW0gaXMgdW5hZmZlY3RlZC4gIFBsZW50eSBvZgp1bmFmZmVjdGVkIENQ
VXMgd29uJ3QgYmUgZ2V0dGluZyBSRkRTX05PIHJldHJvZml0dGVkIGluIG1p
Y3JvY29kZSwgc28gd2UKc3ludGhlc2lzZSBpdC4gIEFsZGVyIExha2UgYW5k
IFJhcHRvciBMYWtlIFhlb24tRSdzIGFyZSB1bmFmZmVjdGVkIGR1ZSB0bwp0
aGVpciBwbGF0Zm9ybSBjb25maWd1cmF0aW9uLCBhbmQgd2UgbXVzdCB1c2Ug
dGhlIEh5YnJpZCBDUFVJRCBiaXQgdG8KZGlzdGluZ3Vpc2ggdGhlbSBmcm9t
IHRoZWlyIG5vbi1YZW9uIGNvdW50ZXJwYXJ0cy4KCkxpa2UgTURfQ0xFQVIg
YW5kIEZCX0NMRUFSLCBSRkRTX0NMRUFSIG5lZWRzIE9SLWluZyBhY3Jvc3Mg
YSByZXNvdXJjZSBwb29sLCBzbwpzZXQgaXQgaW4gdGhlIG1heCBwb2xpY2ll
cyBhbmQgcmVmbGVjdCB0aGUgaG9zdCBzZXR0aW5nIGluIGRlZmF1bHQuCgpU
aGlzIGlzIHBhcnQgb2YgWFNBLTQ1MiAvIENWRS0yMDIzLTI4NzQ2LgoKU2ln
bmVkLW9mZi1ieTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0
cml4LmNvbT4KUmV2aWV3ZWQtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBz
dXNlLmNvbT4KKGNoZXJyeSBwaWNrZWQgZnJvbSBjb21taXQgZmI1YjZmNjc0
NDcxMzQxMGM3NGNmYzEyYjcxNzZjMTA4ZTNjOWEzMSkKCmRpZmYgLS1naXQg
YS90b29scy9taXNjL3hlbi1jcHVpZC5jIGIvdG9vbHMvbWlzYy94ZW4tY3B1
aWQuYwppbmRleCBhZWZjMTQwZDY2NTEuLjVjZWVhOGJlMDczYiAxMDA2NDQK
LS0tIGEvdG9vbHMvbWlzYy94ZW4tY3B1aWQuYworKysgYi90b29scy9taXNj
L3hlbi1jcHVpZC5jCkBAIC0xNzIsNyArMTcyLDcgQEAgc3RhdGljIGNvbnN0
IGNoYXIgKmNvbnN0IHN0cl83ZDBbMzJdID0KICAgICBbIDhdID0gImF2eDUx
Mi12cDJpbnRlcnNlY3QiLCBbIDldID0gInNyYmRzLWN0cmwiLAogICAgIFsx
MF0gPSAibWQtY2xlYXIiLCAgICAgICAgICAgIFsxMV0gPSAicnRtLWFsd2F5
cy1hYm9ydCIsCiAgICAgLyogMTIgKi8gICAgICAgICAgICAgICAgWzEzXSA9
ICJ0c3gtZm9yY2UtYWJvcnQiLAotICAgIFsxNF0gPSAic2VyaWFsaXplIiwK
KyAgICBbMTRdID0gInNlcmlhbGl6ZSIsICAgICBbMTVdID0gImh5YnJpZCIs
CiAgICAgWzE2XSA9ICJ0c3hsZHRyayIsCiAgICAgWzE4XSA9ICJwY29uZmln
IiwKICAgICBbMjBdID0gImNldC1pYnQiLApAQCAtMjM3LDcgKzIzNyw4IEBA
IHN0YXRpYyBjb25zdCBjaGFyICpjb25zdCBzdHJfbTEwQWxbMzJdID0KICAg
ICBbMjBdID0gImJoaS1ubyIsICAgICAgICAgICAgICBbMjFdID0gInhhcGlj
LXN0YXR1cyIsCiAgICAgLyogMjIgKi8gICAgICAgICAgICAgICAgICAgICAg
WzIzXSA9ICJvdnJjbGstc3RhdHVzIiwKICAgICBbMjRdID0gInBicnNiLW5v
IiwgICAgICAgICAgICBbMjVdID0gImdkcy1jdHJsIiwKLSAgICBbMjZdID0g
Imdkcy1ubyIsCisgICAgWzI2XSA9ICJnZHMtbm8iLCAgICAgICAgICAgICAg
WzI3XSA9ICJyZmRzLW5vIiwKKyAgICBbMjhdID0gInJmZHMtY2xlYXIiLAog
fTsKIAogc3RhdGljIGNvbnN0IGNoYXIgKmNvbnN0IHN0cl9tMTBBaFszMl0g
PQpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2NwdS1wb2xpY3kuYyBiL3hl
bi9hcmNoL3g4Ni9jcHUtcG9saWN5LmMKaW5kZXggN2I4NzVhNzIyMTQyLi45
NmMyY2VlMWE4NTcgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9jcHUtcG9s
aWN5LmMKKysrIGIveGVuL2FyY2gveDg2L2NwdS1wb2xpY3kuYwpAQCAtNDQ0
LDYgKzQ0NCw3IEBAIHN0YXRpYyB2b2lkIF9faW5pdCBndWVzdF9jb21tb25f
bWF4X2ZlYXR1cmVfYWRqdXN0bWVudHModWludDMyX3QgKmZzKQogICAgICAg
ICAgKi8KICAgICAgICAgX19zZXRfYml0KFg4Nl9GRUFUVVJFX01EX0NMRUFS
LCBmcyk7CiAgICAgICAgIF9fc2V0X2JpdChYODZfRkVBVFVSRV9GQl9DTEVB
UiwgZnMpOworICAgICAgICBfX3NldF9iaXQoWDg2X0ZFQVRVUkVfUkZEU19D
TEVBUiwgZnMpOwogCiAgICAgICAgIC8qCiAgICAgICAgICAqIFRoZSBHYXRo
ZXIgRGF0YSBTYW1wbGluZyBtaWNyb2NvZGUgbWl0aWdhdGlvbiAoQXVndXN0
IDIwMjMpIGhhcyBhbgpAQCAtNDkzLDYgKzQ5NCwxMCBAQCBzdGF0aWMgdm9p
ZCBfX2luaXQgZ3Vlc3RfY29tbW9uX2RlZmF1bHRfZmVhdHVyZV9hZGp1c3Rt
ZW50cyh1aW50MzJfdCAqZnMpCiAgICAgICAgIGlmICggY3B1X2hhc19mYl9j
bGVhciApCiAgICAgICAgICAgICBfX3NldF9iaXQoWDg2X0ZFQVRVUkVfRkJf
Q0xFQVIsIGZzKTsKIAorICAgICAgICBfX2NsZWFyX2JpdChYODZfRkVBVFVS
RV9SRkRTX0NMRUFSLCBmcyk7CisgICAgICAgIGlmICggY3B1X2hhc19yZmRz
X2NsZWFyICkKKyAgICAgICAgICAgIF9fc2V0X2JpdChYODZfRkVBVFVSRV9S
RkRTX0NMRUFSLCBmcyk7CisKICAgICAgICAgLyoKICAgICAgICAgICogVGhl
IEdhdGhlciBEYXRhIFNhbXBsaW5nIG1pY3JvY29kZSBtaXRpZ2F0aW9uIChB
dWd1c3QgMjAyMykgaGFzIGFuCiAgICAgICAgICAqIGFkdmVyc2UgcGVyZm9y
bWFuY2UgaW1wYWN0IG9uIHRoZSBDTFdCIGluc3RydWN0aW9uIG9uIFNLWC9D
TFgvQ1BYLgpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNt
L2NwdWZlYXR1cmUuaCBiL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9jcHVm
ZWF0dXJlLmgKaW5kZXggZWM4MjRlODk1NDk4Li5hNmI4YWYxMjk2NGMgMTAw
NjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9jcHVmZWF0dXJl
LmgKKysrIGIveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2NwdWZlYXR1cmUu
aApAQCAtMTQwLDYgKzE0MCw3IEBACiAjZGVmaW5lIGNwdV9oYXNfcnRtX2Fs
d2F5c19hYm9ydCBib290X2NwdV9oYXMoWDg2X0ZFQVRVUkVfUlRNX0FMV0FZ
U19BQk9SVCkKICNkZWZpbmUgY3B1X2hhc190c3hfZm9yY2VfYWJvcnQgYm9v
dF9jcHVfaGFzKFg4Nl9GRUFUVVJFX1RTWF9GT1JDRV9BQk9SVCkKICNkZWZp
bmUgY3B1X2hhc19zZXJpYWxpemUgICAgICAgYm9vdF9jcHVfaGFzKFg4Nl9G
RUFUVVJFX1NFUklBTElaRSkKKyNkZWZpbmUgY3B1X2hhc19oeWJyaWQgICAg
ICAgICAgYm9vdF9jcHVfaGFzKFg4Nl9GRUFUVVJFX0hZQlJJRCkKICNkZWZp
bmUgY3B1X2hhc19hdng1MTJfZnAxNiAgICAgYm9vdF9jcHVfaGFzKFg4Nl9G
RUFUVVJFX0FWWDUxMl9GUDE2KQogI2RlZmluZSBjcHVfaGFzX2FyY2hfY2Fw
cyAgICAgICBib290X2NwdV9oYXMoWDg2X0ZFQVRVUkVfQVJDSF9DQVBTKQog
CkBAIC0xNjEsNiArMTYyLDggQEAKICNkZWZpbmUgY3B1X2hhc19ycnNiYSAg
ICAgICAgICAgYm9vdF9jcHVfaGFzKFg4Nl9GRUFUVVJFX1JSU0JBKQogI2Rl
ZmluZSBjcHVfaGFzX2dkc19jdHJsICAgICAgICBib290X2NwdV9oYXMoWDg2
X0ZFQVRVUkVfR0RTX0NUUkwpCiAjZGVmaW5lIGNwdV9oYXNfZ2RzX25vICAg
ICAgICAgIGJvb3RfY3B1X2hhcyhYODZfRkVBVFVSRV9HRFNfTk8pCisjZGVm
aW5lIGNwdV9oYXNfcmZkc19ubyAgICAgICAgIGJvb3RfY3B1X2hhcyhYODZf
RkVBVFVSRV9SRkRTX05PKQorI2RlZmluZSBjcHVfaGFzX3JmZHNfY2xlYXIg
ICAgICBib290X2NwdV9oYXMoWDg2X0ZFQVRVUkVfUkZEU19DTEVBUikKIAog
LyogU3ludGhlc2l6ZWQuICovCiAjZGVmaW5lIGNwdV9oYXNfYXJjaF9wZXJm
bW9uICAgIGJvb3RfY3B1X2hhcyhYODZfRkVBVFVSRV9BUkNIX1BFUkZNT04p
CmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vbXNyLWlu
ZGV4LmggYi94ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vbXNyLWluZGV4LmgK
aW5kZXggNmFiZjdiYzM0YTRmLi45YjVmNjc3MTFmMGMgMTAwNjQ0Ci0tLSBh
L3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9tc3ItaW5kZXguaAorKysgYi94
ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vbXNyLWluZGV4LmgKQEAgLTg4LDYg
Kzg4LDggQEAKICNkZWZpbmUgIEFSQ0hfQ0FQU19QQlJTQl9OTyAgICAgICAg
ICAgICAgICAgKF9BQygxLCBVTEwpIDw8IDI0KQogI2RlZmluZSAgQVJDSF9D
QVBTX0dEU19DVFJMICAgICAgICAgICAgICAgICAoX0FDKDEsIFVMTCkgPDwg
MjUpCiAjZGVmaW5lICBBUkNIX0NBUFNfR0RTX05PICAgICAgICAgICAgICAg
ICAgIChfQUMoMSwgVUxMKSA8PCAyNikKKyNkZWZpbmUgIEFSQ0hfQ0FQU19S
RkRTX05PICAgICAgICAgICAgICAgICAgKF9BQygxLCBVTEwpIDw8IDI3KQor
I2RlZmluZSAgQVJDSF9DQVBTX1JGRFNfQ0xFQVIgICAgICAgICAgICAgICAo
X0FDKDEsIFVMTCkgPDwgMjgpCiAKICNkZWZpbmUgTVNSX0ZMVVNIX0NNRCAg
ICAgICAgICAgICAgICAgICAgICAgMHgwMDAwMDEwYgogI2RlZmluZSAgRkxV
U0hfQ01EX0wxRCAgICAgICAgICAgICAgICAgICAgICAoX0FDKDEsIFVMTCkg
PDwgIDApCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYvc3BlY19jdHJsLmMg
Yi94ZW4vYXJjaC94ODYvc3BlY19jdHJsLmMKaW5kZXggYWRiNmJjNzRlOGU2
Li4xZWU4MWUyZGZlNzkgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9zcGVj
X2N0cmwuYworKysgYi94ZW4vYXJjaC94ODYvc3BlY19jdHJsLmMKQEAgLTI0
LDYgKzI0LDcgQEAKIAogI2luY2x1ZGUgPGFzbS9hbWQuaD4KICNpbmNsdWRl
IDxhc20vaHZtL3N2bS9zdm0uaD4KKyNpbmNsdWRlIDxhc20vaW50ZWwtZmFt
aWx5Lmg+CiAjaW5jbHVkZSA8YXNtL21pY3JvY29kZS5oPgogI2luY2x1ZGUg
PGFzbS9tc3IuaD4KICNpbmNsdWRlIDxhc20vcHYvZG9tYWluLmg+CkBAIC00
NDcsNyArNDQ4LDcgQEAgc3RhdGljIHZvaWQgX19pbml0IHByaW50X2RldGFp
bHMoZW51bSBpbmRfdGh1bmsgdGh1bmspCiAgICAgICogSGFyZHdhcmUgcmVh
ZC1vbmx5IGluZm9ybWF0aW9uLCBzdGF0aW5nIGltbXVuaXR5IHRvIGNlcnRh
aW4gaXNzdWVzLCBvcgogICAgICAqIHN1Z2dlc3Rpb25zIG9mIHdoaWNoIG1p
dGlnYXRpb24gdG8gdXNlLgogICAgICAqLwotICAgIHByaW50aygiICBIYXJk
d2FyZSBoaW50czolcyVzJXMlcyVzJXMlcyVzJXMlcyVzJXMlcyVzJXMlcyVz
JXMlcyVzJXMlc1xuIiwKKyAgICBwcmludGsoIiAgSGFyZHdhcmUgaGludHM6
JXMlcyVzJXMlcyVzJXMlcyVzJXMlcyVzJXMlcyVzJXMlcyVzJXMlcyVzJXMl
c1xuIiwKICAgICAgICAgICAgKGNhcHMgJiBBUkNIX0NBUFNfUkRDTF9OTykg
ICAgICAgICAgICAgICAgICAgICAgICA/ICIgUkRDTF9OTyIgICAgICAgIDog
IiIsCiAgICAgICAgICAgIChjYXBzICYgQVJDSF9DQVBTX0VJQlJTKSAgICAg
ICAgICAgICAgICAgICAgICAgICAgPyAiIEVJQlJTIiAgICAgICAgICA6ICIi
LAogICAgICAgICAgICAoY2FwcyAmIEFSQ0hfQ0FQU19SU0JBKSAgICAgICAg
ICAgICAgICAgICAgICAgICAgID8gIiBSU0JBIiAgICAgICAgICAgOiAiIiwK
QEAgLTQ2Myw2ICs0NjQsNyBAQCBzdGF0aWMgdm9pZCBfX2luaXQgcHJpbnRf
ZGV0YWlscyhlbnVtIGluZF90aHVuayB0aHVuaykKICAgICAgICAgICAgKGNh
cHMgJiBBUkNIX0NBUFNfRkJfQ0xFQVIpICAgICAgICAgICAgICAgICAgICAg
ICA/ICIgRkJfQ0xFQVIiICAgICAgIDogIiIsCiAgICAgICAgICAgIChjYXBz
ICYgQVJDSF9DQVBTX1BCUlNCX05PKSAgICAgICAgICAgICAgICAgICAgICAg
PyAiIFBCUlNCX05PIiAgICAgICA6ICIiLAogICAgICAgICAgICAoY2FwcyAm
IEFSQ0hfQ0FQU19HRFNfTk8pICAgICAgICAgICAgICAgICAgICAgICAgID8g
IiBHRFNfTk8iICAgICAgICAgOiAiIiwKKyAgICAgICAgICAgKGNhcHMgJiBB
UkNIX0NBUFNfUkZEU19OTykgICAgICAgICAgICAgICAgICAgICAgICA/ICIg
UkZEU19OTyIgICAgICAgIDogIiIsCiAgICAgICAgICAgIChlOGIgICYgY3B1
ZmVhdF9tYXNrKFg4Nl9GRUFUVVJFX0lCUlNfQUxXQVlTKSkgICAgPyAiIElC
UlNfQUxXQVlTIiAgICA6ICIiLAogICAgICAgICAgICAoZThiICAmIGNwdWZl
YXRfbWFzayhYODZfRkVBVFVSRV9TVElCUF9BTFdBWVMpKSAgID8gIiBTVElC
UF9BTFdBWVMiICAgOiAiIiwKICAgICAgICAgICAgKGU4YiAgJiBjcHVmZWF0
X21hc2soWDg2X0ZFQVRVUkVfSUJSU19GQVNUKSkgICAgICA/ICIgSUJSU19G
QVNUIiAgICAgIDogIiIsCkBAIC00NzMsNyArNDc1LDcgQEAgc3RhdGljIHZv
aWQgX19pbml0IHByaW50X2RldGFpbHMoZW51bSBpbmRfdGh1bmsgdGh1bmsp
CiAgICAgICAgICAgIChlMjFhICYgY3B1ZmVhdF9tYXNrKFg4Nl9GRUFUVVJF
X1NSU09fTk8pKSAgICAgICAgPyAiIFNSU09fTk8iICAgICAgICA6ICIiKTsK
IAogICAgIC8qIEhhcmR3YXJlIGZlYXR1cmVzIHdoaWNoIG5lZWQgZHJpdmlu
ZyB0byBtaXRpZ2F0ZSBpc3N1ZXMuICovCi0gICAgcHJpbnRrKCIgIEhhcmR3
YXJlIGZlYXR1cmVzOiVzJXMlcyVzJXMlcyVzJXMlcyVzJXMlcyVzXG4iLAor
ICAgIHByaW50aygiICBIYXJkd2FyZSBmZWF0dXJlczolcyVzJXMlcyVzJXMl
cyVzJXMlcyVzJXMlcyVzXG4iLAogICAgICAgICAgICAoZThiICAmIGNwdWZl
YXRfbWFzayhYODZfRkVBVFVSRV9JQlBCKSkgfHwKICAgICAgICAgICAgKF83
ZDAgJiBjcHVmZWF0X21hc2soWDg2X0ZFQVRVUkVfSUJSU0IpKSAgICAgICAg
ICA/ICIgSUJQQiIgICAgICAgICAgIDogIiIsCiAgICAgICAgICAgIChlOGIg
ICYgY3B1ZmVhdF9tYXNrKFg4Nl9GRUFUVVJFX0lCUlMpKSB8fApAQCAtNDkx
LDYgKzQ5Myw3IEBAIHN0YXRpYyB2b2lkIF9faW5pdCBwcmludF9kZXRhaWxz
KGVudW0gaW5kX3RodW5rIHRodW5rKQogICAgICAgICAgICAoY2FwcyAmIEFS
Q0hfQ0FQU19UU1hfQ1RSTCkgICAgICAgICAgICAgICAgICAgICAgID8gIiBU
U1hfQ1RSTCIgICAgICAgOiAiIiwKICAgICAgICAgICAgKGNhcHMgJiBBUkNI
X0NBUFNfRkJfQ0xFQVJfQ1RSTCkgICAgICAgICAgICAgICAgICA/ICIgRkJf
Q0xFQVJfQ1RSTCIgIDogIiIsCiAgICAgICAgICAgIChjYXBzICYgQVJDSF9D
QVBTX0dEU19DVFJMKSAgICAgICAgICAgICAgICAgICAgICAgPyAiIEdEU19D
VFJMIiAgICAgICA6ICIiLAorICAgICAgICAgICAoY2FwcyAmIEFSQ0hfQ0FQ
U19SRkRTX0NMRUFSKSAgICAgICAgICAgICAgICAgICAgID8gIiBSRkRTX0NM
RUFSIiAgICAgOiAiIiwKICAgICAgICAgICAgKGUyMWEgJiBjcHVmZWF0X21h
c2soWDg2X0ZFQVRVUkVfU0JQQikpICAgICAgICAgICA/ICIgU0JQQiIgICAg
ICAgICAgIDogIiIpOwogCiAgICAgLyogQ29tcGlsZWQtaW4gc3VwcG9ydCB3
aGljaCBwZXJ0YWlucyB0byBtaXRpZ2F0aW9ucy4gKi8KQEAgLTEzNTksNiAr
MTM2Miw4MyBAQCBzdGF0aWMgX19pbml0IHZvaWQgbWRzX2NhbGN1bGF0aW9u
cyh2b2lkKQogICAgIH0KIH0KIAorLyoKKyAqIFJlZ2lzdGVyIEZpbGUgRGF0
YSBTYW1wbGluZyBhZmZlY3RzIEF0b20gY29yZXMgZnJvbSB0aGUgR29sZG1v
bnQgdG8KKyAqIEdyYWNlbW9udCBtaWNyb2FyY2hpdGVjdHVyZXMuICBUaGUg
TWFyY2ggMjAyNCBtaWNyb2NvZGUgYWRkcyBSRkRTX05PIHRvCisgKiBzb21l
IGJ1dCBub3QgYWxsIHVuYWZmZWN0ZWQgcGFydHMsIGFuZCBSRkRTX0NMRUFS
IHRvIGFmZmVjdGVkIHBhcnRzIHN0aWxsCisgKiBpbiBzdXBwb3J0LgorICoK
KyAqIEFsZGVyIExha2UgYW5kIFJhcHRvciBMYWtlIGNsaWVudCBDUFVzIGhh
dmUgYSBtaXggb2YgUCBjb3JlcworICogKEdvbGRlbi9SYXB0b3IgQ292ZSwg
bm90IHZ1bG5lcmFibGUpIGFuZCBFIGNvcmVzIChHcmFjZW1vbnQsCisgKiB2
dWxuZXJhYmxlKSwgYW5kIGJvdGggZW51bWVyYXRlIFJGRFNfQ0xFQVIuCisg
KgorICogQm90aCBleGlzdCBpbiBhIFhlb24gU0tVLCB3aGljaCBoYXMgdGhl
IEUgY29yZXMgKEdyYWNlbW9udCkgZGlzYWJsZWQgYnkKKyAqIHBsYXRmb3Jt
IGNvbmZpZ3VyYXRpb24sIGFuZCBlbnVtZXJhdGUgUkZEU19OTy4KKyAqCisg
KiBXaXRoIG9sZGVyIHBhcnRzLCBvciB3aXRoIG91dC1vZi1kYXRlIG1pY3Jv
Y29kZSwgc3ludGhlc2lzZSBSRkRTX05PIHdoZW4KKyAqIHNhZmUgdG8gZG8g
c28uCisgKgorICogaHR0cHM6Ly93d3cuaW50ZWwuY29tL2NvbnRlbnQvd3d3
L3VzL2VuL2RldmVsb3Blci9hcnRpY2xlcy90ZWNobmljYWwvc29mdHdhcmUt
c2VjdXJpdHktZ3VpZGFuY2UvYWR2aXNvcnktZ3VpZGFuY2UvcmVnaXN0ZXIt
ZmlsZS1kYXRhLXNhbXBsaW5nLmh0bWwKKyAqLworc3RhdGljIHZvaWQgX19p
bml0IHJmZHNfY2FsY3VsYXRpb25zKHZvaWQpCit7CisgICAgLyogUkZEUyBp
cyBvbmx5IGtub3duIHRvIGFmZmVjdCBJbnRlbCBGYW1pbHkgNiBwcm9jZXNz
b3JzIGF0IHRoaXMgdGltZS4gKi8KKyAgICBpZiAoIGJvb3RfY3B1X2RhdGEu
eDg2X3ZlbmRvciAhPSBYODZfVkVORE9SX0lOVEVMIHx8CisgICAgICAgICBi
b290X2NwdV9kYXRhLng4NiAhPSA2ICkKKyAgICAgICAgcmV0dXJuOworCisg
ICAgLyoKKyAgICAgKiBJZiBSRkRTX05PIG9yIFJGRFNfQ0xFQVIgYXJlIHZp
c2libGUsIHdlJ3ZlIGVpdGhlciBnb3Qgc3VpdGFibGUKKyAgICAgKiBtaWNy
b2NvZGUsIG9yIGFuIFJGRFMtYXdhcmUgaHlwZXJ2aXNvciBpcyBsZXZlbGxp
bmcgdXMgaW4gYSBwb29sLgorICAgICAqLworICAgIGlmICggY3B1X2hhc19y
ZmRzX25vIHx8IGNwdV9oYXNfcmZkc19jbGVhciApCisgICAgICAgIHJldHVy
bjsKKworICAgIC8qIElmIHdlJ3JlIHZpcnR1YWxpc2VkLCBkb24ndCBhdHRl
bXB0IHRvIHN5bnRoZXNpc2UgUkZEU19OTy4gKi8KKyAgICBpZiAoIGNwdV9o
YXNfaHlwZXJ2aXNvciApCisgICAgICAgIHJldHVybjsKKworICAgIC8qCisg
ICAgICogTm90IGFsbCBDUFVzIGFyZSBleHBlY3RlZCB0byBnZXQgYSBtaWNy
b2NvZGUgdXBkYXRlIGVudW1lcmF0aW5nIG9uZSBvZgorICAgICAqIFJGRFNf
e05PLENMRUFSfSwgb3Igd2UgbWlnaHQgaGF2ZSBvdXQtb2YtZGF0ZSBtaWNy
b2NvZGUuCisgICAgICovCisgICAgc3dpdGNoICggYm9vdF9jcHVfZGF0YS54
ODZfbW9kZWwgKQorICAgIHsKKyAgICBjYXNlIElOVEVMX0ZBTTZfQUxERVJM
QUtFOgorICAgIGNhc2UgSU5URUxfRkFNNl9SQVBUT1JMQUtFOgorICAgICAg
ICAvKgorICAgICAgICAgKiBBbGRlciBMYWtlIGFuZCBSYXB0b3IgTGFrZSBt
aWdodCBiZSBhIGNsaWVudCBTS1UgKHdpdGggdGhlCisgICAgICAgICAqIEdy
YWNlbW9udCBjb3JlcyBhY3RpdmUsIGFuZCB0aGVyZWZvcmUgdnVsbmVyYWJs
ZSkgb3IgbWlnaHQgYmUgYQorICAgICAgICAgKiBzZXJ2ZXIgU0tVICh3aXRo
IHRoZSBHcmFjZW1vbnQgY29yZXMgZGlzYWJsZWQsIGFuZCB0aGVyZWZvcmUg
bm90CisgICAgICAgICAqIHZ1bG5lcmFibGUpLgorICAgICAgICAgKgorICAg
ICAgICAgKiBTZWUgaWYgdGhlIENQVSBpZGVudGlmaWVzIGFzIGh5YnJpZCB0
byBkaXN0aW5ndWlzaCB0aGUgdHdvIGNhc2VzLgorICAgICAgICAgKi8KKyAg
ICAgICAgaWYgKCAhY3B1X2hhc19oeWJyaWQgKQorICAgICAgICAgICAgYnJl
YWs7CisgICAgICAgIGZhbGx0aHJvdWdoOworICAgIGNhc2UgSU5URUxfRkFN
Nl9BTERFUkxBS0VfTDoKKyAgICBjYXNlIElOVEVMX0ZBTTZfUkFQVE9STEFL
RV9QOgorICAgIGNhc2UgSU5URUxfRkFNNl9SQVBUT1JMQUtFX1M6CisKKyAg
ICBjYXNlIElOVEVMX0ZBTTZfQVRPTV9HT0xETU9OVDogICAgICAvKiBBcG9s
bG8gTGFrZSAqLworICAgIGNhc2UgSU5URUxfRkFNNl9BVE9NX0dPTERNT05U
X0Q6ICAgIC8qIERlbnZlcnRvbiAqLworICAgIGNhc2UgSU5URUxfRkFNNl9B
VE9NX0dPTERNT05UX1BMVVM6IC8qIEdlbWluaSBMYWtlICovCisgICAgY2Fz
ZSBJTlRFTF9GQU02X0FUT01fVFJFTU9OVF9EOiAgICAgLyogU25vdyBSaWRn
ZSAvIFBhcmtlciBSaWRnZSAqLworICAgIGNhc2UgSU5URUxfRkFNNl9BVE9N
X1RSRU1PTlQ6ICAgICAgIC8qIEVsa2hhcnQgTGFrZSAqLworICAgIGNhc2Ug
SU5URUxfRkFNNl9BVE9NX1RSRU1PTlRfTDogICAgIC8qIEphc3BlciBMYWtl
ICovCisgICAgY2FzZSBJTlRFTF9GQU02X0FUT01fR1JBQ0VNT05UOiAgICAg
LyogQWxkZXIgTGFrZSBOICovCisgICAgICAgIHJldHVybjsKKyAgICB9CisK
KyAgICAvKgorICAgICAqIFdlIGFwcGVhciB0byBiZSBvbiBhbiB1bmFmZmVj
dGVkIENQVSB3aGljaCBkaWRuJ3QgZW51bWVyYXRlIFJGRFNfTk8sCisgICAg
ICogcGVyaGFwcyBiZWNhdXNlIG9mIGl0J3MgYWdlIG9yIGJlY2F1c2Ugb2Yg
b3V0LW9mLWRhdGUgbWljcm9jb2RlLgorICAgICAqIFN5bnRoZXNpc2UgaXQu
CisgICAgICovCisgICAgc2V0dXBfZm9yY2VfY3B1X2NhcChYODZfRkVBVFVS
RV9SRkRTX05PKTsKK30KKwogc3RhdGljIGJvb2wgX19pbml0IGNwdV9oYXNf
Z2RzKHZvaWQpCiB7CiAgICAgLyoKQEAgLTE4NzIsNiArMTk1Miw3IEBAIHZv
aWQgX19pbml0IGluaXRfc3BlY3VsYXRpb25fbWl0aWdhdGlvbnModm9pZCkK
ICAgICAgKgogICAgICAqIGh0dHBzOi8vd3d3LmludGVsLmNvbS9jb250ZW50
L3d3dy91cy9lbi9kZXZlbG9wZXIvYXJ0aWNsZXMvdGVjaG5pY2FsL3NvZnR3
YXJlLXNlY3VyaXR5LWd1aWRhbmNlL3RlY2huaWNhbC1kb2N1bWVudGF0aW9u
L2ludGVsLWFuYWx5c2lzLW1pY3JvYXJjaGl0ZWN0dXJhbC1kYXRhLXNhbXBs
aW5nLmh0bWwKICAgICAgKiBodHRwczovL3d3dy5pbnRlbC5jb20vY29udGVu
dC93d3cvdXMvZW4vZGV2ZWxvcGVyL2FydGljbGVzL3RlY2huaWNhbC9zb2Z0
d2FyZS1zZWN1cml0eS1ndWlkYW5jZS90ZWNobmljYWwtZG9jdW1lbnRhdGlv
bi9wcm9jZXNzb3ItbW1pby1zdGFsZS1kYXRhLXZ1bG5lcmFiaWxpdGllcy5o
dG1sCisgICAgICogaHR0cHM6Ly93d3cuaW50ZWwuY29tL2NvbnRlbnQvd3d3
L3VzL2VuL2RldmVsb3Blci9hcnRpY2xlcy90ZWNobmljYWwvc29mdHdhcmUt
c2VjdXJpdHktZ3VpZGFuY2UvYWR2aXNvcnktZ3VpZGFuY2UvcmVnaXN0ZXIt
ZmlsZS1kYXRhLXNhbXBsaW5nLmh0bWwKICAgICAgKgogICAgICAqIFJlbGV2
YW50IHVjb2RlczoKICAgICAgKgpAQCAtMTkwMSw4ICsxOTgyLDEyIEBAIHZv
aWQgX19pbml0IGluaXRfc3BlY3VsYXRpb25fbWl0aWdhdGlvbnModm9pZCkK
ICAgICAgKgogICAgICAqICAgSWYgRkJfQ0xFQVIgaXMgZW51bWVyYXRlZCwg
TDFEX0ZMVVNIIGRvZXMgbm90IGhhdmUgdGhlIHNhbWUgc2NydWJiaW5nCiAg
ICAgICogICBzaWRlIGVmZmVjdHMgYXMgVkVSVyBhbmQgY2Fubm90IGJlIHVz
ZWQgaW4gaXRzIHBsYWNlLgorICAgICAqCisgICAgICogLSBNYXJjaCAyMDIz
LCBmb3IgUkZEUy4gIEVudW1lcmF0ZSBSRkRTX0NMRUFSIHRvIG1lYW4gdGhh
dCBWRVJXIG5vdworICAgICAqICAgc2NydWJzIG5vbi1hcmNoaXRlY3R1cmFs
IGVudHJpZXMgZnJvbSBjZXJ0YWluIHJlZ2lzdGVyIGZpbGVzLgogICAgICAq
LwogICAgIG1kc19jYWxjdWxhdGlvbnMoKTsKKyAgICByZmRzX2NhbGN1bGF0
aW9ucygpOwogCiAgICAgLyoKICAgICAgKiBQYXJ0cyB3aGljaCBlbnVtZXJh
dGUgRkJfQ0xFQVIgYXJlIHRob3NlIHdpdGggbm93LXVwZGF0ZWQgbWljcm9j
b2RlCkBAIC0xOTM0LDE1ICsyMDE5LDE5IEBAIHZvaWQgX19pbml0IGluaXRf
c3BlY3VsYXRpb25fbWl0aWdhdGlvbnModm9pZCkKICAgICAgKiBNTFBEUy9N
RkJEUyB3aGVuIFNNVCBpcyBlbmFibGVkLgogICAgICAqLwogICAgIGlmICgg
b3B0X3ZlcndfcHYgPT0gLTEgKQotICAgICAgICBvcHRfdmVyd19wdiA9IGNw
dV9oYXNfdXNlZnVsX21kX2NsZWFyOworICAgICAgICBvcHRfdmVyd19wdiA9
IGNwdV9oYXNfdXNlZnVsX21kX2NsZWFyIHx8IGNwdV9oYXNfcmZkc19jbGVh
cjsKIAogICAgIGlmICggb3B0X3ZlcndfaHZtID09IC0xICkKLSAgICAgICAg
b3B0X3ZlcndfaHZtID0gY3B1X2hhc191c2VmdWxfbWRfY2xlYXI7CisgICAg
ICAgIG9wdF92ZXJ3X2h2bSA9IGNwdV9oYXNfdXNlZnVsX21kX2NsZWFyIHx8
IGNwdV9oYXNfcmZkc19jbGVhcjsKIAogICAgIC8qCiAgICAgICogSWYgU01U
IGlzIGFjdGl2ZSwgYW5kIHdlJ3JlIHByb3RlY3RpbmcgYWdhaW5zdCBNRFMg
b3IgTU1JTyBzdGFsZSBkYXRhLAogICAgICAqIHdlIG5lZWQgdG8gc2NydWIg
YmVmb3JlIGdvaW5nIGlkbGUgYXMgd2VsbCBhcyBvbiByZXR1cm4gdG8gZ3Vl
c3QuCiAgICAgICogVmFyaW91cyBwaXBlbGluZSByZXNvdXJjZXMgYXJlIHJl
cGFydGl0aW9uZWQgYW1vbmdzdCBub24taWRsZSB0aHJlYWRzLgorICAgICAq
CisgICAgICogV2UgZG9uJ3QgbmVlZCB0byBzY3J1YiBvbiBpZGxlIGZvciBS
RkRTLiAgVGhlcmUgYXJlIG5vIGFmZmVjdGVkIGNvcmVzCisgICAgICogd2hp
Y2ggc3VwcG9ydCBTTVQsIGRlc3BpdGUgdGhlcmUgYmVpbmcgYWZmZWN0ZWQg
Y29yZXMgaW4gaHlicmlkIHN5c3RlbXMKKyAgICAgKiB3aGljaCBoYXZlIFNN
VCBlbHNld2hlcmUgaW4gdGhlIHBsYXRmb3JtLgogICAgICAqLwogICAgIGlm
ICggKChjcHVfaGFzX3VzZWZ1bF9tZF9jbGVhciAmJiAob3B0X3ZlcndfcHYg
fHwgb3B0X3ZlcndfaHZtKSkgfHwKICAgICAgICAgICBvcHRfdmVyd19tbWlv
KSAmJiBod19zbXRfZW5hYmxlZCApCkBAIC0xOTU2LDcgKzIwNDUsOCBAQCB2
b2lkIF9faW5pdCBpbml0X3NwZWN1bGF0aW9uX21pdGlnYXRpb25zKHZvaWQp
CiAgICAgICogSXQgaXMgb25seSBzYWZlIHRvIHVzZSBMMURfRkxVU0ggaW4g
cGxhY2Ugb2YgVkVSVyB3aGVuIE1EX0NMRUFSIGlzIHRoZQogICAgICAqIG9u
bHkgKl9DTEVBUiB3ZSBjYW4gc2VlLgogICAgICAqLwotICAgIGlmICggb3B0
X2wxZF9mbHVzaCAmJiBjcHVfaGFzX21kX2NsZWFyICYmICFjcHVfaGFzX2Zi
X2NsZWFyICkKKyAgICBpZiAoIG9wdF9sMWRfZmx1c2ggJiYgY3B1X2hhc19t
ZF9jbGVhciAmJiAhY3B1X2hhc19mYl9jbGVhciAmJgorICAgICAgICAgIWNw
dV9oYXNfcmZkc19jbGVhciApCiAgICAgICAgIG9wdF92ZXJ3X2h2bSA9IGZh
bHNlOwogCiAgICAgLyoKZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL3B1Ymxp
Yy9hcmNoLXg4Ni9jcHVmZWF0dXJlc2V0LmggYi94ZW4vaW5jbHVkZS9wdWJs
aWMvYXJjaC14ODYvY3B1ZmVhdHVyZXNldC5oCmluZGV4IGFlYzE0MDc2MTNj
My4uMTEzZTZjYWRjMTdkIDEwMDY0NAotLS0gYS94ZW4vaW5jbHVkZS9wdWJs
aWMvYXJjaC14ODYvY3B1ZmVhdHVyZXNldC5oCisrKyBiL3hlbi9pbmNsdWRl
L3B1YmxpYy9hcmNoLXg4Ni9jcHVmZWF0dXJlc2V0LmgKQEAgLTI2NCw2ICsy
NjQsNyBAQCBYRU5fQ1BVRkVBVFVSRShNRF9DTEVBUiwgICAgICA5KjMyKzEw
KSAvKiFBIFZFUlcgY2xlYXJzIG1pY3JvYXJjaGl0ZWN0dXJhbCBidWZmZQog
WEVOX0NQVUZFQVRVUkUoUlRNX0FMV0FZU19BQk9SVCwgOSozMisxMSkgLyoh
IEp1bmUgMjAyMSBUU1ggZGVmZWF0dXJpbmcgaW4gbWljcm9jb2RlLiAqLwog
WEVOX0NQVUZFQVRVUkUoVFNYX0ZPUkNFX0FCT1JULCA5KjMyKzEzKSAvKiBN
U1JfVFNYX0ZPUkNFX0FCT1JULlJUTV9BQk9SVCAqLwogWEVOX0NQVUZFQVRV
UkUoU0VSSUFMSVpFLCAgICAgOSozMisxNCkgLypBICBTRVJJQUxJWkUgaW5z
biAqLworWEVOX0NQVUZFQVRVUkUoSFlCUklELCAgICAgICAgOSozMisxNSkg
LyogICBIZXRlcm9nZW5lb3VzIHBsYXRmb3JtICovCiBYRU5fQ1BVRkVBVFVS
RShUU1hMRFRSSywgICAgICA5KjMyKzE2KSAvKmEgIFRTWCBsb2FkIHRyYWNr
aW5nIHN1c3BlbmQvcmVzdW1lIGluc25zICovCiBYRU5fQ1BVRkVBVFVSRShD
RVRfSUJULCAgICAgICA5KjMyKzIwKSAvKiAgIENFVCAtIEluZGlyZWN0IEJy
YW5jaCBUcmFja2luZyAqLwogWEVOX0NQVUZFQVRVUkUoQVZYNTEyX0ZQMTYs
ICAgOSozMisyMykgLyogICBBVlg1MTIgRlAxNiBpbnN0cnVjdGlvbnMgKi8K
QEAgLTMzMCw2ICszMzEsOCBAQCBYRU5fQ1BVRkVBVFVSRShPVlJDTEtfU1RB
VFVTLCAgICAgIDE2KjMyKzIzKSAvKiAgIE1TUl9PVkVSQ0xPQ0tJTkdfU1RB
VFVTICovCiBYRU5fQ1BVRkVBVFVSRShQQlJTQl9OTywgICAgICAgICAgIDE2
KjMyKzI0KSAvKkEgIE5vIFBvc3QtQmFycmllciBSU0IgcHJlZGljdGlvbnMg
Ki8KIFhFTl9DUFVGRUFUVVJFKEdEU19DVFJMLCAgICAgICAgICAgMTYqMzIr
MjUpIC8qICAgTUNVX09QVF9DVFJMLkdEU19NSVRfe0RJUyxMT0NLfSAqLwog
WEVOX0NQVUZFQVRVUkUoR0RTX05PLCAgICAgICAgICAgICAxNiozMisyNikg
LypBICBObyBHYXRoZXIgRGF0YSBTYW1wbGluZyAqLworWEVOX0NQVUZFQVRV
UkUoUkZEU19OTywgICAgICAgICAgICAxNiozMisyNykgLypBICBObyBSZWdp
c3RlciBGaWxlIERhdGEgU2FtcGxpbmcgKi8KK1hFTl9DUFVGRUFUVVJFKFJG
RFNfQ0xFQVIsICAgICAgICAgMTYqMzIrMjgpIC8qIUEgUmVnaXN0ZXIgRmls
ZShzKSBjbGVhcmVkIGJ5IFZFUlcgKi8KIAogLyogSW50ZWwtZGVmaW5lZCBD
UFUgZmVhdHVyZXMsIE1TUl9BUkNIX0NBUFMgMHgxMGEuZWR4LCB3b3JkIDE3
ICovCiAK

--=separator
Content-Type: application/octet-stream; name="xsa452/xsa452-4.18-1.patch"
Content-Disposition: attachment; filename="xsa452/xsa452-4.18-1.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L2VudHJ5OiBJbnRyb2R1Y2UgRUZSQU1FXyogY29u
c3RhbnRzCgpyZXN0b3JlX2FsbF9ndWVzdCgpIGRvZXMgYSBsb3Qgb2YgbWFu
aXB1bGF0aW9uIG9mIHRoZSBzdGFjayBhZnRlciBwb3BwaW5nIHRoZQpHUFJz
LCBhbmQgdXNlcyByYXcgJXJzcCBkaXNwbGFjZW1lbnRzIHRvIGRvIHNvLiAg
QWxzbywgYWxtb3N0IGFsbCBlbnRyeXBhdGhzCnVzZSByYXcgJXJzcCBkaXNw
bGFjZW1lbnRzIHByaW9yIHRvIHB1c2hpbmcgR1BScy4KClByb3ZpZGUgYmV0
dGVyIG1uZW1vbmljcywgdG8gYWlkIHJlYWRhYmlsaXR5IGFuZCByZWR1Y2Ug
dGhlIGNoYW5jZSBvZiBlcnJvcnMKd2hlbiBlZGl0aW5nLgoKTm8gZnVuY3Rp
b25hbCBjaGFuZ2UuICBUaGUgcmVzdWx0aW5nIGJpbmFyeSBpcyBpZGVudGlj
YWwuCgpTaWduZWQtb2ZmLWJ5OiBBbmRyZXcgQ29vcGVyIDxhbmRyZXcuY29v
cGVyM0BjaXRyaXguY29tPgpSZXZpZXdlZC1ieTogSmFuIEJldWxpY2ggPGpi
ZXVsaWNoQHN1c2UuY29tPgooY2hlcnJ5IHBpY2tlZCBmcm9tIGNvbW1pdCAz
NzU0MTIwOGYxMTlhOWM1NTJjNmM2YzMyNDZlYTYxYmUwZDQ0MDM1KQoKZGlm
ZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni94ODZfNjQvYXNtLW9mZnNldHMuYyBi
L3hlbi9hcmNoL3g4Ni94ODZfNjQvYXNtLW9mZnNldHMuYwppbmRleCA1N2I3
M2E0ZTYyMTQuLjJmYzRkOTEzMGE0ZCAxMDA2NDQKLS0tIGEveGVuL2FyY2gv
eDg2L3g4Nl82NC9hc20tb2Zmc2V0cy5jCisrKyBiL3hlbi9hcmNoL3g4Ni94
ODZfNjQvYXNtLW9mZnNldHMuYwpAQCAtNTEsNiArNTEsMjMgQEAgdm9pZCBf
X2R1bW15X18odm9pZCkKICAgICBPRkZTRVQoVVJFR1Nfa2VybmVsX3NpemVv
Ziwgc3RydWN0IGNwdV91c2VyX3JlZ3MsIGVzKTsKICAgICBCTEFOSygpOwog
CisgICAgLyoKKyAgICAgKiBFRlJBTUVfKiBpcyBmb3IgdGhlIGVudHJ5L2V4
aXQgbG9naWMgd2hlcmUgJXJzcCBpcyBwb2ludGluZyBhdAorICAgICAqIFVS
RUdTX2Vycm9yX2NvZGUgYW5kIEdQUnMgYXJlIHN0aWxsL2FscmVhZHkgZ3Vl
c3QgdmFsdWVzLgorICAgICAqLworI2RlZmluZSBPRkZTRVRfRUYoc3ltLCBt
ZW0pICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgXAorICAgIERFRklORShzeW0sIG9mZnNldG9mKHN0cnVjdCBjcHVfdXNl
cl9yZWdzLCBtZW0pIC0gICAgICAgICAgICAgICAgICAgXAorICAgICAgICAg
ICAgICAgIG9mZnNldG9mKHN0cnVjdCBjcHVfdXNlcl9yZWdzLCBlcnJvcl9j
b2RlKSkKKworICAgIE9GRlNFVF9FRihFRlJBTUVfZW50cnlfdmVjdG9yLCAg
ICBlbnRyeV92ZWN0b3IpOworICAgIE9GRlNFVF9FRihFRlJBTUVfcmlwLCAg
ICAgICAgICAgICByaXApOworICAgIE9GRlNFVF9FRihFRlJBTUVfY3MsICAg
ICAgICAgICAgICBjcyk7CisgICAgT0ZGU0VUX0VGKEVGUkFNRV9lZmxhZ3Ms
ICAgICAgICAgIGVmbGFncyk7CisgICAgT0ZGU0VUX0VGKEVGUkFNRV9yc3As
ICAgICAgICAgICAgIHJzcCk7CisgICAgQkxBTksoKTsKKworI3VuZGVmIE9G
RlNFVF9FRgorCiAgICAgT0ZGU0VUKFZDUFVfcHJvY2Vzc29yLCBzdHJ1Y3Qg
dmNwdSwgcHJvY2Vzc29yKTsKICAgICBPRkZTRVQoVkNQVV9kb21haW4sIHN0
cnVjdCB2Y3B1LCBkb21haW4pOwogICAgIE9GRlNFVChWQ1BVX3ZjcHVfaW5m
bywgc3RydWN0IHZjcHUsIHZjcHVfaW5mb19hcmVhLm1hcCk7CmRpZmYgLS1n
aXQgYS94ZW4vYXJjaC94ODYveDg2XzY0L2NvbXBhdC9lbnRyeS5TIGIveGVu
L2FyY2gveDg2L3g4Nl82NC9jb21wYXQvZW50cnkuUwppbmRleCBmY2MzYTcy
MWYxNDcuLmNiNDczZjA4ZWViZCAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2
L3g4Nl82NC9jb21wYXQvZW50cnkuUworKysgYi94ZW4vYXJjaC94ODYveDg2
XzY0L2NvbXBhdC9lbnRyeS5TCkBAIC0xNSw3ICsxNSw3IEBAIEVOVFJZKGVu
dHJ5X2ludDgyKQogICAgICAgICBFTkRCUjY0CiAgICAgICAgIEFMVEVSTkFU
SVZFICIiLCBjbGFjLCBYODZfRkVBVFVSRV9YRU5fU01BUAogICAgICAgICBw
dXNocSAkMAotICAgICAgICBtb3ZsICAkSFlQRVJDQUxMX1ZFQ1RPUiwgNCgl
cnNwKQorICAgICAgICBtb3ZsICAkSFlQRVJDQUxMX1ZFQ1RPUiwgRUZSQU1F
X2VudHJ5X3ZlY3RvciglcnNwKQogICAgICAgICBTQVZFX0FMTCBjb21wYXQ9
MSAvKiBEUEwxIGdhdGUsIHJlc3RyaWN0ZWQgdG8gMzJiaXQgUFYgZ3Vlc3Rz
IG9ubHkuICovCiAKICAgICAgICAgU1BFQ19DVFJMX0VOVFJZX0ZST01fUFYg
LyogUmVxOiAlcnNwPXJlZ3MvY3B1aW5mbywgJXJkeD0wLCBDbG9iOiBhY2Qg
Ki8KZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni94ODZfNjQvZW50cnkuUyBi
L3hlbi9hcmNoL3g4Ni94ODZfNjQvZW50cnkuUwppbmRleCA5YTdiMTI5YWE3
ZTQuLjk2OGRhOWQ3MjdiMSAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L3g4
Nl82NC9lbnRyeS5TCisrKyBiL3hlbi9hcmNoL3g4Ni94ODZfNjQvZW50cnku
UwpAQCAtMTkwLDE1ICsxOTAsMTUgQEAgcmVzdG9yZV9hbGxfZ3Vlc3Q6CiAg
ICAgICAgIFNQRUNfQ1RSTF9FWElUX1RPX1BWICAgIC8qIFJlcTogYT1zcGVj
X2N0cmwgJXJzcD1yZWdzL2NwdWluZm8sIENsb2I6IGNkICovCiAKICAgICAg
ICAgUkVTVE9SRV9BTEwKLSAgICAgICAgdGVzdHcgJFRSQVBfc3lzY2FsbCw0
KCVyc3ApCisgICAgICAgIHRlc3R3ICRUUkFQX3N5c2NhbGwsIEVGUkFNRV9l
bnRyeV92ZWN0b3IoJXJzcCkKICAgICAgICAganogICAgaXJldF9leGl0X3Rv
X2d1ZXN0CiAKLSAgICAgICAgbW92cSAgMjQoJXJzcCksJXIxMSAgICAgICAg
ICAgIyBSRkxBR1MKKyAgICAgICAgbW92ICAgRUZSQU1FX2VmbGFncyglcnNw
KSwgJXIxMQogICAgICAgICBhbmRxICAkfihYODZfRUZMQUdTX0lPUEwgfCBY
ODZfRUZMQUdTX1ZNKSwgJXIxMQogICAgICAgICBvcnEgICAkWDg2X0VGTEFH
U19JRiwlcjExCiAKICAgICAgICAgLyogRG9uJ3QgdXNlIFNZU1JFVCBwYXRo
IGlmIHRoZSByZXR1cm4gYWRkcmVzcyBpcyBub3QgY2Fub25pY2FsLiAqLwot
ICAgICAgICBtb3ZxICA4KCVyc3ApLCVyY3gKKyAgICAgICAgbW92ICAgRUZS
QU1FX3JpcCglcnNwKSwgJXJjeAogICAgICAgICBzYXJxICAkNDcsJXJjeAog
ICAgICAgICBpbmNsICAlZWN4CiAgICAgICAgIGNtcGwgICQxLCVlY3gKQEAg
LTIxMywyMCArMjEzLDIwIEBAIHJlc3RvcmVfYWxsX2d1ZXN0OgogICAgICAg
ICBBTFRFUk5BVElWRSAiIiwgcmFnX2NscnNzYnN5LCBYODZfRkVBVFVSRV9Y
RU5fU0hTVEsKICNlbmRpZgogCi0gICAgICAgIG1vdnEgIDgoJXJzcCksICVy
Y3ggICAgICAgICAgICMgUklQCi0gICAgICAgIGNtcHcgICRGTEFUX1VTRVJf
Q1MzMiwxNiglcnNwKSMgQ1MKLSAgICAgICAgbW92cSAgMzIoJXJzcCksJXJz
cCAgICAgICAgICAgIyBSU1AKKyAgICAgICAgbW92ICAgRUZSQU1FX3JpcCgl
cnNwKSwgJXJjeAorICAgICAgICBjbXB3ICAkRkxBVF9VU0VSX0NTMzIsIEVG
UkFNRV9jcyglcnNwKQorICAgICAgICBtb3YgICBFRlJBTUVfcnNwKCVyc3Ap
LCAlcnNwCiAgICAgICAgIGplICAgIDFmCiAgICAgICAgIHN5c3JldHEKIDE6
ICAgICAgc3lzcmV0bAogCiAgICAgICAgIEFMSUdOCiAuTHJlc3RvcmVfcmN4
X2lyZXRfZXhpdF90b19ndWVzdDoKLSAgICAgICAgbW92cSAgOCglcnNwKSwg
JXJjeCAgICAgICAgICAgIyBSSVAKKyAgICAgICAgbW92ICAgRUZSQU1FX3Jp
cCglcnNwKSwgJXJjeAogLyogTm8gc3BlY2lhbCByZWdpc3RlciBhc3N1bXB0
aW9ucy4gKi8KIGlyZXRfZXhpdF90b19ndWVzdDoKLSAgICAgICAgYW5kbCAg
JH4oWDg2X0VGTEFHU19JT1BMIHwgWDg2X0VGTEFHU19WTSksIDI0KCVyc3Ap
Ci0gICAgICAgIG9ybCAgICRYODZfRUZMQUdTX0lGLDI0KCVyc3ApCisgICAg
ICAgIGFuZGwgICR+KFg4Nl9FRkxBR1NfSU9QTCB8IFg4Nl9FRkxBR1NfVk0p
LCBFRlJBTUVfZWZsYWdzKCVyc3ApCisgICAgICAgIG9ybCAgICRYODZfRUZM
QUdTX0lGLCBFRlJBTUVfZWZsYWdzKCVyc3ApCiAgICAgICAgIGFkZHEgICQ4
LCVyc3AKIC5MZnQwOiAgaXJldHEKICAgICAgICAgX0FTTV9QUkVfRVhUQUJM
RSguTGZ0MCwgaGFuZGxlX2V4Y2VwdGlvbikKQEAgLTI1Nyw3ICsyNTcsNyBA
QCBFTlRSWShsc3Rhcl9lbnRlcikKICAgICAgICAgcHVzaHEgJEZMQVRfS0VS
TkVMX0NTNjQKICAgICAgICAgcHVzaHEgJXJjeAogICAgICAgICBwdXNocSAk
MAotICAgICAgICBtb3ZsICAkVFJBUF9zeXNjYWxsLCA0KCVyc3ApCisgICAg
ICAgIG1vdmwgICRUUkFQX3N5c2NhbGwsIEVGUkFNRV9lbnRyeV92ZWN0b3Io
JXJzcCkKICAgICAgICAgU0FWRV9BTEwKIAogICAgICAgICBTUEVDX0NUUkxf
RU5UUllfRlJPTV9QViAvKiBSZXE6ICVyc3A9cmVncy9jcHVpbmZvLCAlcmR4
PTAsIENsb2I6IGFjZCAqLwpAQCAtMjk0LDcgKzI5NCw3IEBAIEVOVFJZKGNz
dGFyX2VudGVyKQogICAgICAgICBwdXNocSAkRkxBVF9VU0VSX0NTMzIKICAg
ICAgICAgcHVzaHEgJXJjeAogICAgICAgICBwdXNocSAkMAotICAgICAgICBt
b3ZsICAkVFJBUF9zeXNjYWxsLCA0KCVyc3ApCisgICAgICAgIG1vdmwgICRU
UkFQX3N5c2NhbGwsIEVGUkFNRV9lbnRyeV92ZWN0b3IoJXJzcCkKICAgICAg
ICAgU0FWRV9BTEwKIAogICAgICAgICBTUEVDX0NUUkxfRU5UUllfRlJPTV9Q
ViAvKiBSZXE6ICVyc3A9cmVncy9jcHVpbmZvLCAlcmR4PTAsIENsb2I6IGFj
ZCAqLwpAQCAtMzM1LDcgKzMzNSw3IEBAIEdMT0JBTChzeXNlbnRlcl9lZmxh
Z3Nfc2F2ZWQpCiAgICAgICAgIHB1c2hxICQzIC8qIHJpbmcgMyBudWxsIGNz
ICovCiAgICAgICAgIHB1c2hxICQwIC8qIG51bGwgcmlwICovCiAgICAgICAg
IHB1c2hxICQwCi0gICAgICAgIG1vdmwgICRUUkFQX3N5c2NhbGwsIDQoJXJz
cCkKKyAgICAgICAgbW92bCAgJFRSQVBfc3lzY2FsbCwgRUZSQU1FX2VudHJ5
X3ZlY3RvciglcnNwKQogICAgICAgICBTQVZFX0FMTAogCiAgICAgICAgIFNQ
RUNfQ1RSTF9FTlRSWV9GUk9NX1BWIC8qIFJlcTogJXJzcD1yZWdzL2NwdWlu
Zm8sICVyZHg9MCwgQ2xvYjogYWNkICovCkBAIC0zODksNyArMzg5LDcgQEAg
RU5UUlkoaW50ODBfZGlyZWN0X3RyYXApCiAgICAgICAgIEVOREJSNjQKICAg
ICAgICAgQUxURVJOQVRJVkUgIiIsIGNsYWMsIFg4Nl9GRUFUVVJFX1hFTl9T
TUFQCiAgICAgICAgIHB1c2hxICQwCi0gICAgICAgIG1vdmwgICQweDgwLCA0
KCVyc3ApCisgICAgICAgIG1vdmwgICQweDgwLCBFRlJBTUVfZW50cnlfdmVj
dG9yKCVyc3ApCiAgICAgICAgIFNBVkVfQUxMCiAKICAgICAgICAgU1BFQ19D
VFJMX0VOVFJZX0ZST01fUFYgLyogUmVxOiAlcnNwPXJlZ3MvY3B1aW5mbywg
JXJkeD0wLCBDbG9iOiBhY2QgKi8KQEAgLTY0OSw3ICs2NDksNyBAQCByZXRf
ZnJvbV9pbnRyOgogICAgICAgICAuc2VjdGlvbiAuaW5pdC50ZXh0LCAiYXgi
LCBAcHJvZ2JpdHMKIEVOVFJZKGVhcmx5X3BhZ2VfZmF1bHQpCiAgICAgICAg
IEVOREJSNjQKLSAgICAgICAgbW92bCAgJFg4Nl9FWENfUEYsIDQoJXJzcCkK
KyAgICAgICAgbW92bCAgJFg4Nl9FWENfUEYsIEVGUkFNRV9lbnRyeV92ZWN0
b3IoJXJzcCkKICAgICAgICAgU0FWRV9BTEwKICAgICAgICAgbW92cSAgJXJz
cCwgJXJkaQogICAgICAgICBjYWxsICBkb19lYXJseV9wYWdlX2ZhdWx0CkBA
IC03MTYsNyArNzE2LDcgQEAgRU5UUlkoY29tbW9uX2ludGVycnVwdCkKIAog
RU5UUlkoZW50cnlfUEYpCiAgICAgICAgIEVOREJSNjQKLSAgICAgICAgbW92
bCAgJFg4Nl9FWENfUEYsIDQoJXJzcCkKKyAgICAgICAgbW92bCAgJFg4Nl9F
WENfUEYsIEVGUkFNRV9lbnRyeV92ZWN0b3IoJXJzcCkKIC8qIE5vIHNwZWNp
YWwgcmVnaXN0ZXIgYXNzdW1wdGlvbnMuICovCiBHTE9CQUwoaGFuZGxlX2V4
Y2VwdGlvbikKICAgICAgICAgQUxURVJOQVRJVkUgIiIsIGNsYWMsIFg4Nl9G
RUFUVVJFX1hFTl9TTUFQCkBAIC04OTAsOTAgKzg5MCw5MCBAQCBGQVRBTF9l
eGNlcHRpb25fd2l0aF9pbnRzX2Rpc2FibGVkOgogRU5UUlkoZW50cnlfREUp
CiAgICAgICAgIEVOREJSNjQKICAgICAgICAgcHVzaHEgJDAKLSAgICAgICAg
bW92bCAgJFg4Nl9FWENfREUsIDQoJXJzcCkKKyAgICAgICAgbW92bCAgJFg4
Nl9FWENfREUsIEVGUkFNRV9lbnRyeV92ZWN0b3IoJXJzcCkKICAgICAgICAg
am1wICAgaGFuZGxlX2V4Y2VwdGlvbgogCiBFTlRSWShlbnRyeV9NRikKICAg
ICAgICAgRU5EQlI2NAogICAgICAgICBwdXNocSAkMAotICAgICAgICBtb3Zs
ICAkWDg2X0VYQ19NRiwgNCglcnNwKQorICAgICAgICBtb3ZsICAkWDg2X0VY
Q19NRiwgRUZSQU1FX2VudHJ5X3ZlY3RvciglcnNwKQogICAgICAgICBqbXAg
ICBoYW5kbGVfZXhjZXB0aW9uCiAKIEVOVFJZKGVudHJ5X1hNKQogICAgICAg
ICBFTkRCUjY0CiAgICAgICAgIHB1c2hxICQwCi0gICAgICAgIG1vdmwgICRY
ODZfRVhDX1hNLCA0KCVyc3ApCisgICAgICAgIG1vdmwgICRYODZfRVhDX1hN
LCBFRlJBTUVfZW50cnlfdmVjdG9yKCVyc3ApCiAgICAgICAgIGptcCAgIGhh
bmRsZV9leGNlcHRpb24KIAogRU5UUlkoZW50cnlfTk0pCiAgICAgICAgIEVO
REJSNjQKICAgICAgICAgcHVzaHEgJDAKLSAgICAgICAgbW92bCAgJFg4Nl9F
WENfTk0sIDQoJXJzcCkKKyAgICAgICAgbW92bCAgJFg4Nl9FWENfTk0sIEVG
UkFNRV9lbnRyeV92ZWN0b3IoJXJzcCkKICAgICAgICAgam1wICAgaGFuZGxl
X2V4Y2VwdGlvbgogCiBFTlRSWShlbnRyeV9EQikKICAgICAgICAgRU5EQlI2
NAogICAgICAgICBwdXNocSAkMAotICAgICAgICBtb3ZsICAkWDg2X0VYQ19E
QiwgNCglcnNwKQorICAgICAgICBtb3ZsICAkWDg2X0VYQ19EQiwgRUZSQU1F
X2VudHJ5X3ZlY3RvciglcnNwKQogICAgICAgICBqbXAgICBoYW5kbGVfaXN0
X2V4Y2VwdGlvbgogCiBFTlRSWShlbnRyeV9CUCkKICAgICAgICAgRU5EQlI2
NAogICAgICAgICBwdXNocSAkMAotICAgICAgICBtb3ZsICAkWDg2X0VYQ19C
UCwgNCglcnNwKQorICAgICAgICBtb3ZsICAkWDg2X0VYQ19CUCwgRUZSQU1F
X2VudHJ5X3ZlY3RvciglcnNwKQogICAgICAgICBqbXAgICBoYW5kbGVfZXhj
ZXB0aW9uCiAKIEVOVFJZKGVudHJ5X09GKQogICAgICAgICBFTkRCUjY0CiAg
ICAgICAgIHB1c2hxICQwCi0gICAgICAgIG1vdmwgICRYODZfRVhDX09GLCA0
KCVyc3ApCisgICAgICAgIG1vdmwgICRYODZfRVhDX09GLCBFRlJBTUVfZW50
cnlfdmVjdG9yKCVyc3ApCiAgICAgICAgIGptcCAgIGhhbmRsZV9leGNlcHRp
b24KIAogRU5UUlkoZW50cnlfQlIpCiAgICAgICAgIEVOREJSNjQKICAgICAg
ICAgcHVzaHEgJDAKLSAgICAgICAgbW92bCAgJFg4Nl9FWENfQlIsIDQoJXJz
cCkKKyAgICAgICAgbW92bCAgJFg4Nl9FWENfQlIsIEVGUkFNRV9lbnRyeV92
ZWN0b3IoJXJzcCkKICAgICAgICAgam1wICAgaGFuZGxlX2V4Y2VwdGlvbgog
CiBFTlRSWShlbnRyeV9VRCkKICAgICAgICAgRU5EQlI2NAogICAgICAgICBw
dXNocSAkMAotICAgICAgICBtb3ZsICAkWDg2X0VYQ19VRCwgNCglcnNwKQor
ICAgICAgICBtb3ZsICAkWDg2X0VYQ19VRCwgRUZSQU1FX2VudHJ5X3ZlY3Rv
ciglcnNwKQogICAgICAgICBqbXAgICBoYW5kbGVfZXhjZXB0aW9uCiAKIEVO
VFJZKGVudHJ5X1RTKQogICAgICAgICBFTkRCUjY0Ci0gICAgICAgIG1vdmwg
ICRYODZfRVhDX1RTLCA0KCVyc3ApCisgICAgICAgIG1vdmwgICRYODZfRVhD
X1RTLCBFRlJBTUVfZW50cnlfdmVjdG9yKCVyc3ApCiAgICAgICAgIGptcCAg
IGhhbmRsZV9leGNlcHRpb24KIAogRU5UUlkoZW50cnlfTlApCiAgICAgICAg
IEVOREJSNjQKLSAgICAgICAgbW92bCAgJFg4Nl9FWENfTlAsIDQoJXJzcCkK
KyAgICAgICAgbW92bCAgJFg4Nl9FWENfTlAsIEVGUkFNRV9lbnRyeV92ZWN0
b3IoJXJzcCkKICAgICAgICAgam1wICAgaGFuZGxlX2V4Y2VwdGlvbgogCiBF
TlRSWShlbnRyeV9TUykKICAgICAgICAgRU5EQlI2NAotICAgICAgICBtb3Zs
ICAkWDg2X0VYQ19TUywgNCglcnNwKQorICAgICAgICBtb3ZsICAkWDg2X0VY
Q19TUywgRUZSQU1FX2VudHJ5X3ZlY3RvciglcnNwKQogICAgICAgICBqbXAg
ICBoYW5kbGVfZXhjZXB0aW9uCiAKIEVOVFJZKGVudHJ5X0dQKQogICAgICAg
ICBFTkRCUjY0Ci0gICAgICAgIG1vdmwgICRYODZfRVhDX0dQLCA0KCVyc3Ap
CisgICAgICAgIG1vdmwgICRYODZfRVhDX0dQLCBFRlJBTUVfZW50cnlfdmVj
dG9yKCVyc3ApCiAgICAgICAgIGptcCAgIGhhbmRsZV9leGNlcHRpb24KIAog
RU5UUlkoZW50cnlfQUMpCiAgICAgICAgIEVOREJSNjQKLSAgICAgICAgbW92
bCAgJFg4Nl9FWENfQUMsIDQoJXJzcCkKKyAgICAgICAgbW92bCAgJFg4Nl9F
WENfQUMsIEVGUkFNRV9lbnRyeV92ZWN0b3IoJXJzcCkKICAgICAgICAgam1w
ICAgaGFuZGxlX2V4Y2VwdGlvbgogCiBFTlRSWShlbnRyeV9DUCkKICAgICAg
ICAgRU5EQlI2NAotICAgICAgICBtb3ZsICAkWDg2X0VYQ19DUCwgNCglcnNw
KQorICAgICAgICBtb3ZsICAkWDg2X0VYQ19DUCwgRUZSQU1FX2VudHJ5X3Zl
Y3RvciglcnNwKQogICAgICAgICBqbXAgICBoYW5kbGVfZXhjZXB0aW9uCiAK
IEVOVFJZKGVudHJ5X0RGKQogICAgICAgICBFTkRCUjY0Ci0gICAgICAgIG1v
dmwgICRYODZfRVhDX0RGLCA0KCVyc3ApCisgICAgICAgIG1vdmwgICRYODZf
RVhDX0RGLCBFRlJBTUVfZW50cnlfdmVjdG9yKCVyc3ApCiAgICAgICAgIC8q
IFNldCBBQyB0byByZWR1Y2UgY2hhbmNlIG9mIGZ1cnRoZXIgU01BUCBmYXVs
dHMgKi8KICAgICAgICAgQUxURVJOQVRJVkUgIiIsIHN0YWMsIFg4Nl9GRUFU
VVJFX1hFTl9TTUFQCiAgICAgICAgIFNBVkVfQUxMCkBAIC05OTgsNyArOTk4
LDcgQEAgRU5UUlkoZW50cnlfREYpCiBFTlRSWShlbnRyeV9OTUkpCiAgICAg
ICAgIEVOREJSNjQKICAgICAgICAgcHVzaHEgJDAKLSAgICAgICAgbW92bCAg
JFg4Nl9FWENfTk1JLCA0KCVyc3ApCisgICAgICAgIG1vdmwgICRYODZfRVhD
X05NSSwgRUZSQU1FX2VudHJ5X3ZlY3RvciglcnNwKQogaGFuZGxlX2lzdF9l
eGNlcHRpb246CiAgICAgICAgIEFMVEVSTkFUSVZFICIiLCBjbGFjLCBYODZf
RkVBVFVSRV9YRU5fU01BUAogICAgICAgICBTQVZFX0FMTApAQCAtMTEzMCw3
ICsxMTMwLDcgQEAgaGFuZGxlX2lzdF9leGNlcHRpb246CiBFTlRSWShlbnRy
eV9NQykKICAgICAgICAgRU5EQlI2NAogICAgICAgICBwdXNocSAkMAotICAg
ICAgICBtb3ZsICAkWDg2X0VYQ19NQywgNCglcnNwKQorICAgICAgICBtb3Zs
ICAkWDg2X0VYQ19NQywgRUZSQU1FX2VudHJ5X3ZlY3RvciglcnNwKQogICAg
ICAgICBqbXAgICBoYW5kbGVfaXN0X2V4Y2VwdGlvbgogCiAvKiBObyBvcCB0
cmFwIGhhbmRsZXIuICBSZXF1aXJlZCBmb3Iga2V4ZWMgY3Jhc2ggcGF0aC4g
Ki8KQEAgLTExNjcsNyArMTE2Nyw3IEBAIGF1dG9nZW5fc3R1YnM6IC8qIEF1
dG9tYXRpY2FsbHkgZ2VuZXJhdGVkIHN0dWJzLiAqLwogMToKICAgICAgICAg
RU5EQlI2NAogICAgICAgICBwdXNocSAkMAotICAgICAgICBtb3ZiICAkdmVj
LDQoJXJzcCkKKyAgICAgICAgbW92YiAgJHZlYywgRUZSQU1FX2VudHJ5X3Zl
Y3RvciglcnNwKQogICAgICAgICBqbXAgICBjb21tb25faW50ZXJydXB0CiAK
ICAgICAgICAgZW50cnlwb2ludCAxYgpAQCAtMTE4MSw3ICsxMTgxLDcgQEAg
YXV0b2dlbl9zdHViczogLyogQXV0b21hdGljYWxseSBnZW5lcmF0ZWQgc3R1
YnMuICovCiAgICAgICAgIHRlc3QgICQ4LCVzcGwgICAgICAgIC8qIDY0Yml0
IGV4Y2VwdGlvbiBmcmFtZXMgYXJlIDE2IGJ5dGUgYWxpZ25lZCwgYnV0IHRo
ZSB3b3JkICovCiAgICAgICAgIGp6ICAgIDJmICAgICAgICAgICAgIC8qIHNp
emUgaXMgOCBieXRlcy4gIENoZWNrIHdoZXRoZXIgdGhlIHByb2Nlc3NvciBn
YXZlIHVzIGFuICovCiAgICAgICAgIHB1c2hxICQwICAgICAgICAgICAgIC8q
IGVycm9yIGNvZGUsIGFuZCBpbnNlcnQgYW4gZW1wdHkgb25lIGlmIG5vdC4g
ICAgICAgICAgICAgICovCi0yOiAgICAgIG1vdmIgICR2ZWMsNCglcnNwKQor
MjogICAgICBtb3ZiICAkdmVjLCBFRlJBTUVfZW50cnlfdmVjdG9yKCVyc3Ap
CiAgICAgICAgIGptcCAgIGhhbmRsZV9leGNlcHRpb24KIAogICAgICAgICBl
bnRyeXBvaW50IDFiCg==

--=separator
Content-Type: application/octet-stream; name="xsa452/xsa452-4.18-2.patch"
Content-Disposition: attachment; filename="xsa452/xsa452-4.18-2.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2OiBSZXN5bmMgaW50ZWwtZmFtaWx5LmggZnJvbSBM
aW51eAoKRnJvbSB2Ni44LXJjNgoKU2lnbmVkLW9mZi1ieTogQW5kcmV3IENv
b3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4KQWNrZWQtYnk6IEph
biBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4KKGNoZXJyeSBwaWNrZWQg
ZnJvbSBjb21taXQgMTk1ZTc1MzcxYjEzYzRmN2VjZGY3YjVjNTBhZWQwZDAy
ZjJkN2NlOCkKCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYvaW5jbHVkZS9h
c20vaW50ZWwtZmFtaWx5LmggYi94ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20v
aW50ZWwtZmFtaWx5LmgKaW5kZXggZmZjNDkxNTFiZWZlLi5iNjVlOWM0NmI5
MjIgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9pbnRl
bC1mYW1pbHkuaAorKysgYi94ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vaW50
ZWwtZmFtaWx5LmgKQEAgLTI2LDYgKzI2LDkgQEAKICAqCQlfRwktIHBhcnRz
IHdpdGggZXh0cmEgZ3JhcGhpY3Mgb24KICAqCQlfWAktIHJlZ3VsYXIgc2Vy
dmVyIHBhcnRzCiAgKgkJX0QJLSBtaWNybyBzZXJ2ZXIgcGFydHMKKyAqCQlf
TixfUAktIG90aGVyIG1vYmlsZSBwYXJ0cworICoJCV9ICS0gcHJlbWl1bSBt
b2JpbGUgcGFydHMKKyAqCQlfUwktIG90aGVyIGNsaWVudCBwYXJ0cwogICoK
ICAqCQlIaXN0b3JpY2FsIE9QVERJRkZzOgogICoKQEAgLTM3LDYgKzQwLDkg
QEAKICAqIHRoZWlyIG93biBuYW1lcyA6LSgKICAqLwogCisvKiBXaWxkY2Fy
ZCBtYXRjaCBmb3IgRkFNNiBzbyBYODZfTUFUQ0hfSU5URUxfRkFNNl9NT0RF
TChBTlkpIHdvcmtzICovCisjZGVmaW5lIElOVEVMX0ZBTTZfQU5ZCQkJWDg2
X01PREVMX0FOWQorCiAjZGVmaW5lIElOVEVMX0ZBTTZfQ09SRV9ZT05BSAkJ
MHgwRQogCiAjZGVmaW5lIElOVEVMX0ZBTTZfQ09SRTJfTUVST00JCTB4MEYK
QEAgLTkzLDggKzk5LDYgQEAKICNkZWZpbmUgSU5URUxfRkFNNl9JQ0VMQUtF
X0wJCTB4N0UJLyogU3VubnkgQ292ZSAqLwogI2RlZmluZSBJTlRFTF9GQU02
X0lDRUxBS0VfTk5QSQkJMHg5RAkvKiBTdW5ueSBDb3ZlICovCiAKLSNkZWZp
bmUgSU5URUxfRkFNNl9MQUtFRklFTEQJCTB4OEEJLyogU3VubnkgQ292ZSAv
IFRyZW1vbnQgKi8KLQogI2RlZmluZSBJTlRFTF9GQU02X1JPQ0tFVExBS0UJ
CTB4QTcJLyogQ3lwcmVzcyBDb3ZlICovCiAKICNkZWZpbmUgSU5URUxfRkFN
Nl9USUdFUkxBS0VfTAkJMHg4QwkvKiBXaWxsb3cgQ292ZSAqLwpAQCAtMTAy
LDEyICsxMDYsMzEgQEAKIAogI2RlZmluZSBJTlRFTF9GQU02X1NBUFBISVJF
UkFQSURTX1gJMHg4RgkvKiBHb2xkZW4gQ292ZSAqLwogCisjZGVmaW5lIElO
VEVMX0ZBTTZfRU1FUkFMRFJBUElEU19YCTB4Q0YKKworI2RlZmluZSBJTlRF
TF9GQU02X0dSQU5JVEVSQVBJRFNfWAkweEFECisjZGVmaW5lIElOVEVMX0ZB
TTZfR1JBTklURVJBUElEU19ECTB4QUUKKworLyogIkh5YnJpZCIgUHJvY2Vz
c29ycyAoUC1Db3JlL0UtQ29yZSkgKi8KKworI2RlZmluZSBJTlRFTF9GQU02
X0xBS0VGSUVMRAkJMHg4QQkvKiBTdW5ueSBDb3ZlIC8gVHJlbW9udCAqLwor
CiAjZGVmaW5lIElOVEVMX0ZBTTZfQUxERVJMQUtFCQkweDk3CS8qIEdvbGRl
biBDb3ZlIC8gR3JhY2Vtb250ICovCiAjZGVmaW5lIElOVEVMX0ZBTTZfQUxE
RVJMQUtFX0wJCTB4OUEJLyogR29sZGVuIENvdmUgLyBHcmFjZW1vbnQgKi8K
IAotI2RlZmluZSBJTlRFTF9GQU02X1JBUFRPUkxBS0UJCTB4QjcKKyNkZWZp
bmUgSU5URUxfRkFNNl9SQVBUT1JMQUtFCQkweEI3CS8qIFJhcHRvciBDb3Zl
IC8gRW5oYW5jZWQgR3JhY2Vtb250ICovCisjZGVmaW5lIElOVEVMX0ZBTTZf
UkFQVE9STEFLRV9QCQkweEJBCisjZGVmaW5lIElOVEVMX0ZBTTZfUkFQVE9S
TEFLRV9TCQkweEJGCisKKyNkZWZpbmUgSU5URUxfRkFNNl9NRVRFT1JMQUtF
CQkweEFDCisjZGVmaW5lIElOVEVMX0ZBTTZfTUVURU9STEFLRV9MCQkweEFB
CisKKyNkZWZpbmUgSU5URUxfRkFNNl9BUlJPV0xBS0VfSAkJMHhDNQorI2Rl
ZmluZSBJTlRFTF9GQU02X0FSUk9XTEFLRQkJMHhDNgorCisjZGVmaW5lIElO
VEVMX0ZBTTZfTFVOQVJMQUtFX00JCTB4QkQKIAotLyogIlNtYWxsIENvcmUi
IFByb2Nlc3NvcnMgKEF0b20pICovCisvKiAiU21hbGwgQ29yZSIgUHJvY2Vz
c29ycyAoQXRvbS9FLUNvcmUpICovCiAKICNkZWZpbmUgSU5URUxfRkFNNl9B
VE9NX0JPTk5FTEwJCTB4MUMgLyogRGlhbW9uZHZpbGxlLCBQaW5ldmlldyAq
LwogI2RlZmluZSBJTlRFTF9GQU02X0FUT01fQk9OTkVMTF9NSUQJMHgyNiAv
KiBTaWx2ZXJ0aG9ybmUsIExpbmNyb2Z0ICovCkBAIC0xMzQsNiArMTU3LDEz
IEBACiAjZGVmaW5lIElOVEVMX0ZBTTZfQVRPTV9UUkVNT05UCQkweDk2IC8q
IEVsa2hhcnQgTGFrZSAqLwogI2RlZmluZSBJTlRFTF9GQU02X0FUT01fVFJF
TU9OVF9MCTB4OUMgLyogSmFzcGVyIExha2UgKi8KIAorI2RlZmluZSBJTlRF
TF9GQU02X0FUT01fR1JBQ0VNT05UCTB4QkUgLyogQWxkZXJsYWtlIE4gKi8K
KworI2RlZmluZSBJTlRFTF9GQU02X0FUT01fQ1JFU1RNT05UX1gJMHhBRiAv
KiBTaWVycmEgRm9yZXN0ICovCisjZGVmaW5lIElOVEVMX0ZBTTZfQVRPTV9D
UkVTVE1PTlQJMHhCNiAvKiBHcmFuZCBSaWRnZSAqLworCisjZGVmaW5lIElO
VEVMX0ZBTTZfQVRPTV9EQVJLTU9OVF9YCTB4REQgLyogQ2xlYXJ3YXRlciBG
b3Jlc3QgKi8KKwogLyogWGVvbiBQaGkgKi8KIAogI2RlZmluZSBJTlRFTF9G
QU02X1hFT05fUEhJX0tOTAkJMHg1NyAvKiBLbmlnaHRzIExhbmRpbmcgKi8K

--=separator
Content-Type: application/octet-stream; name="xsa452/xsa452-4.18-3.patch"
Content-Disposition: attachment; filename="xsa452/xsa452-4.18-3.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L3ZteDogUGVyZm9ybSBWRVJXIGZsdXNoaW5nIGxh
dGVyIGluIHRoZSBWTUV4aXQgcGF0aAoKQnJva2VuIG91dCBvZiB0aGUgZm9s
bG93aW5nIHBhdGNoIGJlY2F1c2UgdGhpcyBjaGFuZ2UgaXMgc3VidGxlIGVu
b3VnaCBvbiBpdHMKb3duLiAgU2VlIGl0IGZvciB0aGUgcmF0aW9uYWwgb2Yg
d2h5IHdlJ3JlIG1vdmluZyBWRVJXLgoKQXMgZm9yIGhvdywgZXh0ZW5kIHRo
ZSB0cmljayBhbHJlYWR5IHVzZWQgdG8gaG9sZCBvbmUgY29uZGl0aW9uIGlu
CmZsYWdzIChSRVNVTUUgdnMgTEFVTkNIKSB0aHJvdWdoIHRoZSBQT1Bpbmcg
b2YgR1BScy4KCk1vdmUgdGhlIE1PViBDUiBlYXJsaWVyLiAgSW50ZWwgc3Bl
Y2lmeSBmbGFncyB0byBiZSB1bmRlZmluZWQgYWNyb3NzIGl0LgoKRW5jb2Rl
IHRoZSB0d28gY29uZGl0aW9ucyB3ZSB3YW50IHVzaW5nIFNGIGFuZCBQRi4g
IFNlZSB0aGUgY29kZSBjb21tZW50IGZvcgpleGFjdGx5IGhvdy4KCkxlYXZl
IGEgY29tbWVudCB0byBleHBsYWluIHRoZSBsYWNrIG9mIGFueSBjb250ZW50
IGFyb3VuZApTUEVDX0NUUkxfRVhJVF9UT19WTVgsIGJ1dCBsZWF2ZSB0aGUg
YmxvY2sgaW4gcGxhY2UuICBTb2RzIGxhdyBzYXlzIGlmIHdlCmRlbGV0ZSBp
dCwgd2UnbGwgbmVlZCB0byByZWludHJvZHVjZSBpdC4KClRoaXMgaXMgcGFy
dCBvZiBYU0EtNDUyIC8gQ1ZFLTIwMjMtMjg3NDYuCgpTaWduZWQtb2ZmLWJ5
OiBBbmRyZXcgQ29vcGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPgpS
ZXZpZXdlZC1ieTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgoo
Y2hlcnJ5IHBpY2tlZCBmcm9tIGNvbW1pdCA0NzVmYTIwYjczODQ0NjQyMTBm
NDJiYWQ3MTk1Zjg3YmQ2ZjFjNjNmKQoKZGlmZiAtLWdpdCBhL3hlbi9hcmNo
L3g4Ni9odm0vdm14L2VudHJ5LlMgYi94ZW4vYXJjaC94ODYvaHZtL3ZteC9l
bnRyeS5TCmluZGV4IGUzZjYwZDVhODJmNy4uMWJlYWQ4MjZjYWEzIDEwMDY0
NAotLS0gYS94ZW4vYXJjaC94ODYvaHZtL3ZteC9lbnRyeS5TCisrKyBiL3hl
bi9hcmNoL3g4Ni9odm0vdm14L2VudHJ5LlMKQEAgLTg3LDE3ICs4NywzOSBA
QCBVTkxJS0VMWV9FTkQocmVhbG1vZGUpCiAKICAgICAgICAgLyogV0FSTklO
RyEgYHJldGAsIGBjYWxsICpgLCBgam1wICpgIG5vdCBzYWZlIGJleW9uZCB0
aGlzIHBvaW50LiAqLwogICAgICAgICAvKiBTUEVDX0NUUkxfRVhJVF9UT19W
TVggICBSZXE6ICVyc3A9cmVncy9jcHVpbmZvICAgICAgICAgICAgICBDbG9i
OiAgICAqLwotICAgICAgICBET19TUEVDX0NUUkxfQ09ORF9WRVJXCisgICAg
ICAgIC8qCisgICAgICAgICAqIEFsbCBzcGVjdWxhdGlvbiBzYWZldHkgd29y
ayBoYXBwZW5zIHRvIGJlIGVsc2V3aGVyZS4gIFZFUlcgaXMgYWZ0ZXIKKyAg
ICAgICAgICogcG9wcGluZyB0aGUgR1BScywgd2hpbGUgcmVzdG9yaW5nIHRo
ZSBndWVzdCBNU1JfU1BFQ19DVFJMIGlzIGxlZnQKKyAgICAgICAgICogdG8g
dGhlIE1TUiBsb2FkIGxpc3QuCisgICAgICAgICAqLwogCiAgICAgICAgIG1v
diAgVkNQVV9odm1fZ3Vlc3RfY3IyKCVyYngpLCVyYXgKKyAgICAgICAgbW92
ICAlcmF4LCAlY3IyCisKKyAgICAgICAgLyoKKyAgICAgICAgICogV2UgbmVl
ZCB0byBwZXJmb3JtIHR3byBjb25kaXRpb25hbCBhY3Rpb25zIChWRVJXLCBh
bmQgUmVzdW1lIHZzCisgICAgICAgICAqIExhdW5jaCkgYWZ0ZXIgcG9wcGlu
ZyBHUFJzLiAgV2l0aCBzb21lIGN1bm5pbmcsIHdlIGNhbiBlbmNvZGUgYm90
aAorICAgICAgICAgKiBvZiB0aGVzZSBpbiBlZmxhZ3MgdG9nZXRoZXIuCisg
ICAgICAgICAqCisgICAgICAgICAqIFBhcml0eSBpcyBvbmx5IGNhbGN1bGF0
ZWQgb3ZlciB0aGUgYm90dG9tIGJ5dGUgb2YgdGhlIGFuc3dlciwgd2hpbGUK
KyAgICAgICAgICogU2lnbiBpcyBzaW1wbHkgdGhlIHRvcCBiaXQuCisgICAg
ICAgICAqCisgICAgICAgICAqIFRoZXJlZm9yZSwgdGhlIGZpbmFsIE9SIGlu
c3RydWN0aW9uIGVuZHMgdXAgcHJvZHVjaW5nOgorICAgICAgICAgKiAgIFNG
ID0gVkNQVV92bXhfbGF1bmNoZWQKKyAgICAgICAgICogICBQRiA9ICFTQ0Zf
dmVydworICAgICAgICAgKi8KKyAgICAgICAgQlVJTERfQlVHX09OKFNDRl92
ZXJ3ICYgfjB4ZmYpCisgICAgICAgIG1vdnpibCBWQ1BVX3ZteF9sYXVuY2hl
ZCglcmJ4KSwgJWVjeAorICAgICAgICBzaGwgICQzMSwgJWVjeAorICAgICAg
ICBtb3Z6YmwgQ1BVSU5GT19zcGVjX2N0cmxfZmxhZ3MoJXJzcCksICVlYXgK
KyAgICAgICAgYW5kICAkU0NGX3ZlcncsICVlYXgKKyAgICAgICAgb3IgICAl
ZWF4LCAlZWN4CiAKICAgICAgICAgcG9wICAlcjE1CiAgICAgICAgIHBvcCAg
JXIxNAogICAgICAgICBwb3AgICVyMTMKICAgICAgICAgcG9wICAlcjEyCiAg
ICAgICAgIHBvcCAgJXJicAotICAgICAgICBtb3YgICVyYXgsJWNyMgotICAg
ICAgICBjbXBiICQwLFZDUFVfdm14X2xhdW5jaGVkKCVyYngpCiAgICAgICAg
IHBvcCAgJXJieAogICAgICAgICBwb3AgICVyMTEKICAgICAgICAgcG9wICAl
cjEwCkBAIC0xMDgsNyArMTMwLDEzIEBAIFVOTElLRUxZX0VORChyZWFsbW9k
ZSkKICAgICAgICAgcG9wICAlcmR4CiAgICAgICAgIHBvcCAgJXJzaQogICAg
ICAgICBwb3AgICVyZGkKLSAgICAgICAgamUgICAuTHZteF9sYXVuY2gKKwor
ICAgICAgICBqcGUgIC5MX3NraXBfdmVydworICAgICAgICAvKiBWRVJXIGNs
b2JiZXJzIFpGLCBidXQgcHJlc2VydmVzIGFsbCBvdGhlcnMsIGluY2x1ZGlu
ZyBTRi4gKi8KKyAgICAgICAgdmVydyBTVEtfUkVMKENQVUlORk9fdmVyd19z
ZWwsIENQVUlORk9fZXJyb3JfY29kZSkoJXJzcCkKKy5MX3NraXBfdmVydzoK
KworICAgICAgICBqbnMgIC5Mdm14X2xhdW5jaAogCiAvKi5Mdm14X3Jlc3Vt
ZToqLwogICAgICAgICBWTVJFU1VNRQpkaWZmIC0tZ2l0IGEveGVuL2FyY2gv
eDg2L2luY2x1ZGUvYXNtL2FzbV9kZWZucy5oIGIveGVuL2FyY2gveDg2L2lu
Y2x1ZGUvYXNtL2FzbV9kZWZucy5oCmluZGV4IGJhYWFjY2IyNmUxNy4uNTZh
ZTI2ZTU0MjY1IDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYvaW5jbHVkZS9h
c20vYXNtX2RlZm5zLmgKKysrIGIveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNt
L2FzbV9kZWZucy5oCkBAIC04MSw2ICs4MSwxNCBAQCByZWdpc3RlciB1bnNp
Z25lZCBsb25nIGN1cnJlbnRfc3RhY2tfcG9pbnRlciBhc20oInJzcCIpOwog
CiAjaWZkZWYgX19BU1NFTUJMWV9fCiAKKy5tYWNybyBCVUlMRF9CVUdfT04g
Y29uZHN0ciwgY29uZDp2YXJhcmcKKyAgICAgICAgLmlmIFxjb25kCisgICAg
ICAgIC5lcnJvciAiQ29uZGl0aW9uIFwiXGNvbmRzdHJcIiBub3Qgc2F0aXNm
aWVkIgorICAgICAgICAuZW5kaWYKKy5lbmRtCisvKiBwcmVwcm9jZXNzb3Ig
bWFjcm8gdG8gbWFrZSBlcnJvciBtZXNzYWdlIG1vcmUgdXNlciBmcmllbmRs
eSAqLworI2RlZmluZSBCVUlMRF9CVUdfT04oY29uZCkgQlVJTERfQlVHX09O
ICNjb25kLCBjb25kCisKICNpZmRlZiBIQVZFX0FTX1FVT1RFRF9TWU0KICNk
ZWZpbmUgU1VCU0VDVElPTl9MQkwodGFnKSAgICAgICAgICAgICAgICAgICAg
ICAgIFwKICAgICAgICAgLmlmbmRlZiAuTC50YWc7ICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIFwKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9pbmNs
dWRlL2FzbS9zcGVjX2N0cmxfYXNtLmggYi94ZW4vYXJjaC94ODYvaW5jbHVk
ZS9hc20vc3BlY19jdHJsX2FzbS5oCmluZGV4IDZjYjdjMWI5NDkxZS4uNTI1
NzQ1YTA2NjA4IDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYvaW5jbHVkZS9h
c20vc3BlY19jdHJsX2FzbS5oCisrKyBiL3hlbi9hcmNoL3g4Ni9pbmNsdWRl
L2FzbS9zcGVjX2N0cmxfYXNtLmgKQEAgLTE1Miw2ICsxNTIsMTMgQEAKICNl
bmRpZgogLmVuZG0KIAorLyoKKyAqIEhlbHBlciB0byBpbXByb3ZlIHRoZSBy
ZWFkaWJpbGl0eSBvZiBzdGFjayBkaXNwYWNlbWVudHMgd2l0aCAlcnNwIGlu
CisgKiB1bnVzdWFsIHBvc2l0aW9ucy4gIEJvdGggQGZpZWxkIGFuZCBAdG9w
X29mX3N0YWNrIHNob3VsZCBiZSBjb25zdGFudHMgZnJvbQorICogdGhlIHNh
bWUgb2JqZWN0LiAgQHRvcF9vZl9zdGFjayBzaG91bGQgYmUgd2hlcmUgJXJz
cCBpcyBjdXJyZW50bHkgcG9pbnRpbmcuCisgKi8KKyNkZWZpbmUgU1RLX1JF
TChmaWVsZCwgdG9wX29mX3N0aykgKChmaWVsZCkgLSAodG9wX29mX3N0aykp
CisKIC5tYWNybyBET19TUEVDX0NUUkxfQ09ORF9WRVJXCiAvKgogICogUmVx
dWlyZXMgJXJzcD1jcHVpbmZvCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYv
eDg2XzY0L2FzbS1vZmZzZXRzLmMgYi94ZW4vYXJjaC94ODYveDg2XzY0L2Fz
bS1vZmZzZXRzLmMKaW5kZXggMmZjNGQ5MTMwYTRkLi4wZDMzNjc4ODk4OWYg
MTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni94ODZfNjQvYXNtLW9mZnNldHMu
YworKysgYi94ZW4vYXJjaC94ODYveDg2XzY0L2FzbS1vZmZzZXRzLmMKQEAg
LTEzNSw2ICsxMzUsNyBAQCB2b2lkIF9fZHVtbXlfXyh2b2lkKQogI2VuZGlm
CiAKICAgICBPRkZTRVQoQ1BVSU5GT19ndWVzdF9jcHVfdXNlcl9yZWdzLCBz
dHJ1Y3QgY3B1X2luZm8sIGd1ZXN0X2NwdV91c2VyX3JlZ3MpOworICAgIE9G
RlNFVChDUFVJTkZPX2Vycm9yX2NvZGUsIHN0cnVjdCBjcHVfaW5mbywgZ3Vl
c3RfY3B1X3VzZXJfcmVncy5lcnJvcl9jb2RlKTsKICAgICBPRkZTRVQoQ1BV
SU5GT192ZXJ3X3NlbCwgc3RydWN0IGNwdV9pbmZvLCB2ZXJ3X3NlbCk7CiAg
ICAgT0ZGU0VUKENQVUlORk9fY3VycmVudF92Y3B1LCBzdHJ1Y3QgY3B1X2lu
Zm8sIGN1cnJlbnRfdmNwdSk7CiAgICAgT0ZGU0VUKENQVUlORk9fcGVyX2Nw
dV9vZmZzZXQsIHN0cnVjdCBjcHVfaW5mbywgcGVyX2NwdV9vZmZzZXQpOwo=

--=separator
Content-Type: application/octet-stream; name="xsa452/xsa452-4.18-4.patch"
Content-Disposition: attachment; filename="xsa452/xsa452-4.18-4.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L3NwZWMtY3RybDogUGVyZm9ybSBWRVJXIGZsdXNo
aW5nIGxhdGVyIGluIGV4aXQgcGF0aHMKCk9uIHBhcnRzIHZ1bG5lcmFibGUg
dG8gUkZEUywgVkVSVydzIHNpZGUgZWZmZWN0cyBhcmUgZXh0ZW5kZWQgdG8g
c2NydWIgYWxsCm5vbi1hcmNoaXRlY3R1cmFsIGVudHJpZXMgaW4gdmFyaW91
cyBQaHlzaWNhbCBSZWdpc3RlciBGaWxlcy4gIFRvIHJlbW92ZSBhbGwKb2Yg
WGVuJ3MgdmFsdWVzLCB0aGUgVkVSVyBtdXN0IGJlIGFmdGVyIHBvcHBpbmcg
dGhlIEdQUnMuCgpSZXdvcmsgU1BFQ19DVFJMX0NPTkRfVkVSVyB0byBkZWZh
dWx0IHRvIGFuIENQVUlORk9fZXJyb3JfY29kZSAlcnNwIHBvc2l0aW9uLApi
dXQgd2l0aCBvdmVycmlkZXMgZm9yIG90aGVyIGNvbnRleHRzLiAgSWRlbnRp
ZnkgdGhhdCBpdCBjbG9iYmVycyBlZmxhZ3M7IHRoaXMKaXMgcGFydGljdWxh
cmx5IHJlbGV2YW50IGZvciB0aGUgU1lTUkVUIHBhdGguCgpGb3IgdGhlIElT
VCBleGl0IHJldHVybiB0byBYZW4sIGhhdmUgdGhlIG1haW4gU1BFQ19DVFJM
X0VYSVRfVE9fWEVOIHB1dCBhCnNoYWRvdyBjb3B5IG9mIHNwZWNfY3RybF9m
bGFncywgYXMgR1BScyBjYW4ndCBiZSB1c2VkIGF0IHRoZSBwb2ludCB3ZSB3
YW50IHRvCmlzc3VlIHRoZSBWRVJXLgoKVGhpcyBpcyBwYXJ0IG9mIFhTQS00
NTIgLyBDVkUtMjAyMy0yODc0Ni4KClNpZ25lZC1vZmYtYnk6IEFuZHJldyBD
b29wZXIgPGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+ClJldmlld2VkLWJ5
OiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+CihjaGVycnkgcGlj
a2VkIGZyb20gY29tbWl0IDBhNjY2Y2YyY2Q5OWRmNmZhZjNlZWJjODFhMWZj
Mjg2ZTRlY2E0YzcpCgpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2luY2x1
ZGUvYXNtL3NwZWNfY3RybF9hc20uaCBiL3hlbi9hcmNoL3g4Ni9pbmNsdWRl
L2FzbS9zcGVjX2N0cmxfYXNtLmgKaW5kZXggNTI1NzQ1YTA2NjA4Li4xM2Fj
ZWJjNzVkZmYgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2Fz
bS9zcGVjX2N0cmxfYXNtLmgKKysrIGIveGVuL2FyY2gveDg2L2luY2x1ZGUv
YXNtL3NwZWNfY3RybF9hc20uaApAQCAtMTU5LDE2ICsxNTksMjMgQEAKICAq
LwogI2RlZmluZSBTVEtfUkVMKGZpZWxkLCB0b3Bfb2Zfc3RrKSAoKGZpZWxk
KSAtICh0b3Bfb2Zfc3RrKSkKIAotLm1hY3JvIERPX1NQRUNfQ1RSTF9DT05E
X1ZFUlcKKy5tYWNybyBTUEVDX0NUUkxfQ09ORF9WRVJXIFwKKyAgICBzY2Y9
U1RLX1JFTChDUFVJTkZPX3NwZWNfY3RybF9mbGFncywgQ1BVSU5GT19lcnJv
cl9jb2RlKSwgXAorICAgIHNlbD1TVEtfUkVMKENQVUlORk9fdmVyd19zZWws
ICAgICAgICBDUFVJTkZPX2Vycm9yX2NvZGUpCiAvKgotICogUmVxdWlyZXMg
JXJzcD1jcHVpbmZvCisgKiBSZXF1aXJlcyBcc2NmIGFuZCBcc2VsIGFzICVy
c3AtcmVsYXRpdmUgZXhwcmVzc2lvbnMKKyAqIENsb2JiZXJzIGVmbGFncwor
ICoKKyAqIFZFUlcgbmVlZHMgdG8gcnVuIGFmdGVyIGd1ZXN0IEdQUnMgaGF2
ZSBiZWVuIHJlc3RvcmVkLCB3aGVyZSBvbmx5ICVyc3AgaXMKKyAqIGdvb2Qg
dG8gdXNlLiAgRGVmYXVsdCB0byBleHBlY3RpbmcgJXJzcCBwb2ludGluZyBh
dCBDUFVJTkZPX2Vycm9yX2NvZGUuCisgKiBDb250ZXh0cyB3aGVyZSB0aGlz
IGlzIG5vdCB0cnVlIG11c3QgcHJvdmlkZSBhbiBhbHRlcm5hdGl2ZSBcc2Nm
IGFuZCBcc2VsLgogICoKICAqIElzc3VlIGEgVkVSVyBmb3IgaXRzIGZsdXNo
aW5nIHNpZGUgZWZmZWN0LCBpZiBpbmRpY2F0ZWQuICBUaGlzIGlzIGEgU3Bl
Y3RyZQogICogdjEgZ2FkZ2V0LCBidXQgdGhlIElSRVQvVk1FbnRyeSBpcyBz
ZXJpYWxpc2luZy4KICAqLwotICAgIHRlc3RiICRTQ0ZfdmVydywgQ1BVSU5G
T19zcGVjX2N0cmxfZmxhZ3MoJXJzcCkKKyAgICB0ZXN0YiAkU0NGX3Zlcncs
IFxzY2YoJXJzcCkKICAgICBqeiAuTFxAX3Zlcndfc2tpcAotICAgIHZlcncg
Q1BVSU5GT192ZXJ3X3NlbCglcnNwKQorICAgIHZlcncgXHNlbCglcnNwKQog
LkxcQF92ZXJ3X3NraXA6CiAuZW5kbQogCkBAIC0yODYsOCArMjkzLDYgQEAK
ICAqLwogICAgIEFMVEVSTkFUSVZFICIiLCBET19TUEVDX0NUUkxfRVhJVF9U
T19HVUVTVCwgWDg2X0ZFQVRVUkVfU0NfTVNSX1BWCiAKLSAgICBET19TUEVD
X0NUUkxfQ09ORF9WRVJXCi0KICAgICBBTFRFUk5BVElWRSAiIiwgRE9fU1BF
Q19DVFJMX0RJViwgWDg2X0ZFQVRVUkVfU0NfRElWCiAuZW5kbQogCkBAIC0z
NjcsNyArMzcyLDcgQEAgVU5MSUtFTFlfRElTUEFUQ0hfTEFCRUwoXEBfc2Vy
aWFsaXNlKToKICAqLwogLm1hY3JvIFNQRUNfQ1RSTF9FWElUX1RPX1hFTgog
LyoKLSAqIFJlcXVpcmVzICVyMTI9aXN0X2V4aXQsICVyMTQ9c3RhY2tfZW5k
CisgKiBSZXF1aXJlcyAlcjEyPWlzdF9leGl0LCAlcjE0PXN0YWNrX2VuZCwg
JXJzcD1yZWdzCiAgKiBDbG9iYmVycyAlcmF4LCAlcmJ4LCAlcmN4LCAlcmR4
CiAgKi8KICAgICBtb3Z6YmwgU1RBQ0tfQ1BVSU5GT19GSUVMRChzcGVjX2N0
cmxfZmxhZ3MpKCVyMTQpLCAlZWJ4CkBAIC0zOTUsMTEgKzQwMCwxOCBAQCBV
TkxJS0VMWV9ESVNQQVRDSF9MQUJFTChcQF9zZXJpYWxpc2UpOgogICAgIHRl
c3QgJXIxMiwgJXIxMgogICAgIGp6IC5MXEBfc2tpcF9pc3RfZXhpdAogCi0g
ICAgLyogTG9naWNhbGx5IERPX1NQRUNfQ1RSTF9DT05EX1ZFUlcgYnV0IHdp
dGhvdXQgdGhlICVyc3A9Y3B1aW5mbyBkZXBlbmRlbmN5ICovCi0gICAgdGVz
dGIgJFNDRl92ZXJ3LCAlYmwKLSAgICBqeiAuTFxAX3NraXBfdmVydwotICAg
IHZlcncgU1RBQ0tfQ1BVSU5GT19GSUVMRCh2ZXJ3X3NlbCkoJXIxNCkKLS5M
XEBfc2tpcF92ZXJ3OgorICAgIC8qCisgICAgICogU3Rhc2ggU0NGIGFuZCB2
ZXJ3X3NlbCBhYm92ZSBlZmxhZ3MgaW4gdGhlIGNhc2Ugb2YgYW4gSVNUX2V4
aXQuICBUaGUKKyAgICAgKiBWRVJXIGxvZ2ljIG5lZWRzIHRvIHJ1biBhZnRl
ciBndWVzdCBHUFJzIGhhdmUgYmVlbiByZXN0b3JlZDsgaS5lLiB3aGVyZQor
ICAgICAqIHdlIGNhbm5vdCB1c2UgJXIxMiBvciAlcjE0IGZvciB0aGUgcHVy
cG9zZXMgdGhleSBoYXZlIGhlcmUuCisgICAgICoKKyAgICAgKiBXaGVuIHRo
ZSBDUFUgcHVzaGVkIHRoaXMgZXhjZXB0aW9uIGZyYW1lLCBpdCB6ZXJvLWV4
dGVuZGVkIGVmbGFncy4KKyAgICAgKiBUaGVyZWZvcmUgaXQgaXMgc2FmZSBm
b3IgdGhlIFZFUlcgbG9naWMgdG8gbG9vayBhdCB0aGUgc3Rhc2hlZCBTQ0YK
KyAgICAgKiBvdXRzaWRlIG9mIHRoZSBpc3RfZXhpdCBjb25kaXRpb24uICBB
bHNvLCB0aGlzIHN0YXNoaW5nIHdvbid0IGluZmx1ZW5jZQorICAgICAqIGFu
eSBvdGhlciByZXN0b3JlX2FsbF9ndWVzdCgpIHBhdGhzLgorICAgICAqLwor
ICAgIG9yICQoX19IWVBFUlZJU09SX0RTMzIgPDwgMTYpLCAlZWJ4CisgICAg
bW92ICVlYngsIFVSRUdTX2VmbGFncyArIDQoJXJzcCkgLyogRUZSQU1FX3No
YWRvd19zY2Yvc2VsICovCiAKICAgICBBTFRFUk5BVElWRSAiIiwgRE9fU1BF
Q19DVFJMX0RJViwgWDg2X0ZFQVRVUkVfU0NfRElWCiAKZGlmZiAtLWdpdCBh
L3hlbi9hcmNoL3g4Ni94ODZfNjQvYXNtLW9mZnNldHMuYyBiL3hlbi9hcmNo
L3g4Ni94ODZfNjQvYXNtLW9mZnNldHMuYwppbmRleCAwZDMzNjc4ODk4OWYu
Ljg1YzdkMGM5ODk2NyAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L3g4Nl82
NC9hc20tb2Zmc2V0cy5jCisrKyBiL3hlbi9hcmNoL3g4Ni94ODZfNjQvYXNt
LW9mZnNldHMuYwpAQCAtNTUsMTQgKzU1LDIyIEBAIHZvaWQgX19kdW1teV9f
KHZvaWQpCiAgICAgICogRUZSQU1FXyogaXMgZm9yIHRoZSBlbnRyeS9leGl0
IGxvZ2ljIHdoZXJlICVyc3AgaXMgcG9pbnRpbmcgYXQKICAgICAgKiBVUkVH
U19lcnJvcl9jb2RlIGFuZCBHUFJzIGFyZSBzdGlsbC9hbHJlYWR5IGd1ZXN0
IHZhbHVlcy4KICAgICAgKi8KLSNkZWZpbmUgT0ZGU0VUX0VGKHN5bSwgbWVt
KSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IFwKKyNkZWZpbmUgT0ZGU0VUX0VGKHN5bSwgbWVtLCAuLi4pICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKICAgICBERUZJTkUo
c3ltLCBvZmZzZXRvZihzdHJ1Y3QgY3B1X3VzZXJfcmVncywgbWVtKSAtICAg
ICAgICAgICAgICAgICAgIFwKLSAgICAgICAgICAgICAgICBvZmZzZXRvZihz
dHJ1Y3QgY3B1X3VzZXJfcmVncywgZXJyb3JfY29kZSkpCisgICAgICAgICAg
ICAgICAgb2Zmc2V0b2Yoc3RydWN0IGNwdV91c2VyX3JlZ3MsIGVycm9yX2Nv
ZGUpIF9fVkFfQVJHU19fKQogCiAgICAgT0ZGU0VUX0VGKEVGUkFNRV9lbnRy
eV92ZWN0b3IsICAgIGVudHJ5X3ZlY3Rvcik7CiAgICAgT0ZGU0VUX0VGKEVG
UkFNRV9yaXAsICAgICAgICAgICAgIHJpcCk7CiAgICAgT0ZGU0VUX0VGKEVG
UkFNRV9jcywgICAgICAgICAgICAgIGNzKTsKICAgICBPRkZTRVRfRUYoRUZS
QU1FX2VmbGFncywgICAgICAgICAgZWZsYWdzKTsKKworICAgIC8qCisgICAg
ICogVGhlc2UgYXJlbid0IHJlYWwgZmllbGRzLiAgVGhleSdyZSBzcGFyZSBz
cGFjZSwgdXNlZCBieSB0aGUgSVNUCisgICAgICogZXhpdC10by14ZW4gcGF0
aC4KKyAgICAgKi8KKyAgICBPRkZTRVRfRUYoRUZSQU1FX3NoYWRvd19zY2Ys
ICAgICAgZWZsYWdzLCArNCk7CisgICAgT0ZGU0VUX0VGKEVGUkFNRV9zaGFk
b3dfc2VsLCAgICAgIGVmbGFncywgKzYpOworCiAgICAgT0ZGU0VUX0VGKEVG
UkFNRV9yc3AsICAgICAgICAgICAgIHJzcCk7CiAgICAgQkxBTksoKTsKIApA
QCAtMTM2LDYgKzE0NCw3IEBAIHZvaWQgX19kdW1teV9fKHZvaWQpCiAKICAg
ICBPRkZTRVQoQ1BVSU5GT19ndWVzdF9jcHVfdXNlcl9yZWdzLCBzdHJ1Y3Qg
Y3B1X2luZm8sIGd1ZXN0X2NwdV91c2VyX3JlZ3MpOwogICAgIE9GRlNFVChD
UFVJTkZPX2Vycm9yX2NvZGUsIHN0cnVjdCBjcHVfaW5mbywgZ3Vlc3RfY3B1
X3VzZXJfcmVncy5lcnJvcl9jb2RlKTsKKyAgICBPRkZTRVQoQ1BVSU5GT19y
aXAsIHN0cnVjdCBjcHVfaW5mbywgZ3Vlc3RfY3B1X3VzZXJfcmVncy5yaXAp
OwogICAgIE9GRlNFVChDUFVJTkZPX3Zlcndfc2VsLCBzdHJ1Y3QgY3B1X2lu
Zm8sIHZlcndfc2VsKTsKICAgICBPRkZTRVQoQ1BVSU5GT19jdXJyZW50X3Zj
cHUsIHN0cnVjdCBjcHVfaW5mbywgY3VycmVudF92Y3B1KTsKICAgICBPRkZT
RVQoQ1BVSU5GT19wZXJfY3B1X29mZnNldCwgc3RydWN0IGNwdV9pbmZvLCBw
ZXJfY3B1X29mZnNldCk7CmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYveDg2
XzY0L2NvbXBhdC9lbnRyeS5TIGIveGVuL2FyY2gveDg2L3g4Nl82NC9jb21w
YXQvZW50cnkuUwppbmRleCBjYjQ3M2YwOGVlYmQuLjNiYmUzYTc5YTViNyAx
MDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L3g4Nl82NC9jb21wYXQvZW50cnku
UworKysgYi94ZW4vYXJjaC94ODYveDg2XzY0L2NvbXBhdC9lbnRyeS5TCkBA
IC0xNjEsNiArMTYxLDEyIEBAIEVOVFJZKGNvbXBhdF9yZXN0b3JlX2FsbF9n
dWVzdCkKICAgICAgICAgU1BFQ19DVFJMX0VYSVRfVE9fUFYgICAgLyogUmVx
OiBhPXNwZWNfY3RybCAlcnNwPXJlZ3MvY3B1aW5mbywgQ2xvYjogY2QgKi8K
IAogICAgICAgICBSRVNUT1JFX0FMTCBhZGo9OCBjb21wYXQ9MQorCisgICAg
ICAgIC8qIEFjY291bnQgZm9yIGV2L2VjIGhhdmluZyBhbHJlYWR5IGJlZW4g
cG9wcGVkIG9mZiB0aGUgc3RhY2suICovCisgICAgICAgIFNQRUNfQ1RSTF9D
T05EX1ZFUlcgXAorICAgICAgICAgICAgc2NmPVNUS19SRUwoQ1BVSU5GT19z
cGVjX2N0cmxfZmxhZ3MsIENQVUlORk9fcmlwKSwgXAorICAgICAgICAgICAg
c2VsPVNUS19SRUwoQ1BVSU5GT192ZXJ3X3NlbCwgICAgICAgIENQVUlORk9f
cmlwKQorCiAuTGZ0MDogIGlyZXRxCiAgICAgICAgIF9BU01fUFJFX0VYVEFC
TEUoLkxmdDAsIGhhbmRsZV9leGNlcHRpb24pCiAKZGlmZiAtLWdpdCBhL3hl
bi9hcmNoL3g4Ni94ODZfNjQvZW50cnkuUyBiL3hlbi9hcmNoL3g4Ni94ODZf
NjQvZW50cnkuUwppbmRleCA5NjhkYTlkNzI3YjEuLjJjNzUxMjEzMGY0OSAx
MDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L3g4Nl82NC9lbnRyeS5TCisrKyBi
L3hlbi9hcmNoL3g4Ni94ODZfNjQvZW50cnkuUwpAQCAtMjE0LDYgKzIxNCw5
IEBAIHJlc3RvcmVfYWxsX2d1ZXN0OgogI2VuZGlmCiAKICAgICAgICAgbW92
ICAgRUZSQU1FX3JpcCglcnNwKSwgJXJjeAorCisgICAgICAgIFNQRUNfQ1RS
TF9DT05EX1ZFUlcgICAgIC8qIFJlcTogJXJzcD1lZnJhbWUgICAgICAgICAg
ICAgICAgICAgIENsb2I6IGVmbCAqLworCiAgICAgICAgIGNtcHcgICRGTEFU
X1VTRVJfQ1MzMiwgRUZSQU1FX2NzKCVyc3ApCiAgICAgICAgIG1vdiAgIEVG
UkFNRV9yc3AoJXJzcCksICVyc3AKICAgICAgICAgamUgICAgMWYKQEAgLTIy
Nyw2ICsyMzAsOSBAQCByZXN0b3JlX2FsbF9ndWVzdDoKIGlyZXRfZXhpdF90
b19ndWVzdDoKICAgICAgICAgYW5kbCAgJH4oWDg2X0VGTEFHU19JT1BMIHwg
WDg2X0VGTEFHU19WTSksIEVGUkFNRV9lZmxhZ3MoJXJzcCkKICAgICAgICAg
b3JsICAgJFg4Nl9FRkxBR1NfSUYsIEVGUkFNRV9lZmxhZ3MoJXJzcCkKKwor
ICAgICAgICBTUEVDX0NUUkxfQ09ORF9WRVJXICAgICAvKiBSZXE6ICVyc3A9
ZWZyYW1lICAgICAgICAgICAgICAgICAgICBDbG9iOiBlZmwgKi8KKwogICAg
ICAgICBhZGRxICAkOCwlcnNwCiAuTGZ0MDogIGlyZXRxCiAgICAgICAgIF9B
U01fUFJFX0VYVEFCTEUoLkxmdDAsIGhhbmRsZV9leGNlcHRpb24pCkBAIC02
NzksOSArNjg1LDIyIEBAIFVOTElLRUxZX1NUQVJUKG5lLCBleGl0X2NyMykK
IFVOTElLRUxZX0VORChleGl0X2NyMykKIAogICAgICAgICAvKiBXQVJOSU5H
ISBgcmV0YCwgYGNhbGwgKmAsIGBqbXAgKmAgbm90IHNhZmUgYmV5b25kIHRo
aXMgcG9pbnQuICovCi0gICAgICAgIFNQRUNfQ1RSTF9FWElUX1RPX1hFTiAg
ICAgLyogUmVxOiAlcjEyPWlzdF9leGl0ICVyMTQ9ZW5kLCBDbG9iOiBhYmNk
ICovCisgICAgICAgIFNQRUNfQ1RSTF9FWElUX1RPX1hFTiAvKiBSZXE6ICVy
MTI9aXN0X2V4aXQgJXIxND1lbmQgJXJzcD1yZWdzLCBDbG9iOiBhYmNkICov
CiAKICAgICAgICAgUkVTVE9SRV9BTEwgYWRqPTgKKworICAgICAgICAvKgor
ICAgICAgICAgKiBXaGVuIHRoZSBDUFUgcHVzaGVkIHRoaXMgZXhjZXB0aW9u
IGZyYW1lLCBpdCB6ZXJvLWV4dGVuZGVkIGVmbGFncy4KKyAgICAgICAgICog
Rm9yIGFuIElTVCBleGl0LCBTUEVDX0NUUkxfRVhJVF9UT19YRU4gc3Rhc2hl
ZCBzaGFkb3cgY29waWVzIG9mCisgICAgICAgICAqIHNwZWNfY3RybF9mbGFn
cyBhbmQgdmVyX3NlbCBhYm92ZSBlZmxhZ3MsIGFzIHdlIGNhbid0IHVzZSBh
bnkgR1BScywKKyAgICAgICAgICogYW5kIHdlJ3JlIGF0IGEgcmFuZG9tIHBs
YWNlIG9uIHRoZSBzdGFjaywgbm90IGluIGEgQ1BVRklORk8gYmxvY2suCisg
ICAgICAgICAqCisgICAgICAgICAqIEFjY291bnQgZm9yIGV2L2VjIGhhdmlu
ZyBhbHJlYWR5IGJlZW4gcG9wcGVkIG9mZiB0aGUgc3RhY2suCisgICAgICAg
ICAqLworICAgICAgICBTUEVDX0NUUkxfQ09ORF9WRVJXIFwKKyAgICAgICAg
ICAgIHNjZj1TVEtfUkVMKEVGUkFNRV9zaGFkb3dfc2NmLCBFRlJBTUVfcmlw
KSwgXAorICAgICAgICAgICAgc2VsPVNUS19SRUwoRUZSQU1FX3NoYWRvd19z
ZWwsIEVGUkFNRV9yaXApCisKICAgICAgICAgaXJldHEKIAogRU5UUlkoY29t
bW9uX2ludGVycnVwdCkK

--=separator
Content-Type: application/octet-stream; name="xsa452/xsa452-4.18-5.patch"
Content-Disposition: attachment; filename="xsa452/xsa452-4.18-5.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L3NwZWMtY3RybDogUmVuYW1lIFZFUlcgcmVsYXRl
ZCBvcHRpb25zCgpWRVJXIGlzIGdvaW5nIHRvIGJlIHVzZWQgZm9yIGEgM3Jk
IHB1cnBvc2UsIGFuZCB0aGUgZXhpc3Rpbmcgbm9tZW5jbGF0dXJlCmRpZG4n
dCBzdXJ2aXZlIHRoZSBTdGFsZSBNTUlPIGlzc3VlcyB0ZXJyaWJseSB3ZWxs
LgoKUmVuYW1lIHRoZSBjb21tYW5kIGxpbmUgb3B0aW9uIGZyb20gYG1kLWNs
ZWFyPWAgdG8gYHZlcnc9YC4gIFRoaXMgaXMgbW9yZQpjb25zaXN0ZW50IHdp
dGggb3RoZXIgb3B0aW9ucyB3aGljaCB0ZW5kIHRvIGJlIG5hbWVkIGJhc2Vk
IG9uIHdoYXQgdGhleSdyZQpkb2luZywgbm90IHdoaWNoIGZlYXR1cmUgZW51
bWVyYXRpb24gdGhleSB1c2UgYmVoaW5kIHRoZSBzY2VuZXMuICBSZXRhaW4K
YG1kLWNsZWFyPWAgYXMgYSBkZXByZWNhdGVkIGFsaWFzLgoKUmVuYW1lIG9w
dF9tZF9jbGVhcl97cHYsaHZtfSBhbmQgb3B0X2ZiX2NsZWFyX21taW8gdG8g
b3B0X3Zlcndfe3B2LGh2bSxtbWlvfSwKd2hpY2ggaGFzIGEgc2lkZSBlZmZl
Y3Qgb2YgbWFraW5nIHNwZWNfY3RybF9pbml0X2RvbWFpbigpIHJhdGhlciBj
bGVhcmVyIHRvCmZvbGxvdy4KCk5vIGZ1bmN0aW9uYWwgY2hhbmdlLgoKVGhp
cyBpcyBwYXJ0IG9mIFhTQS00NTIgLyBDVkUtMjAyMy0yODc0Ni4KClNpZ25l
ZC1vZmYtYnk6IEFuZHJldyBDb29wZXIgPGFuZHJldy5jb29wZXIzQGNpdHJp
eC5jb20+ClJldmlld2VkLWJ5OiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3Vz
ZS5jb20+CihjaGVycnkgcGlja2VkIGZyb20gY29tbWl0IGY3NjAzY2EyNTJl
NDIyNjczOWViMzEyOWE1MjkwZWUzZGEzZjhlYTQpCgpkaWZmIC0tZ2l0IGEv
ZG9jcy9taXNjL3hlbi1jb21tYW5kLWxpbmUucGFuZG9jIGIvZG9jcy9taXNj
L3hlbi1jb21tYW5kLWxpbmUucGFuZG9jCmluZGV4IDU4MmQ2NzQxZDE4Mi4u
ZmJmMTY4MzkyNDlhIDEwMDY0NAotLS0gYS9kb2NzL21pc2MveGVuLWNvbW1h
bmQtbGluZS5wYW5kb2MKKysrIGIvZG9jcy9taXNjL3hlbi1jb21tYW5kLWxp
bmUucGFuZG9jCkBAIC0yMzcwLDcgKzIzNzAsNyBAQCBCeSBkZWZhdWx0IFNT
QkQgd2lsbCBiZSBtaXRpZ2F0ZWQgYXQgcnVudGltZSAoaS5lIGBzc2JkPXJ1
bnRpbWVgKS4KIAogIyMjIHNwZWMtY3RybCAoeDg2KQogPiBgPSBMaXN0IG9m
IFsgPGJvb2w+LCB4ZW49PGJvb2w+LCB7cHYsaHZtfT08Ym9vbD4sCi0+ICAg
ICAgICAgICAgICB7bXNyLXNjLHJzYixtZC1jbGVhcixpYnBiLWVudHJ5fT08
Ym9vbD58e3B2LGh2bX09PGJvb2w+LAorPiAgICAgICAgICAgICAge21zci1z
Yyxyc2IsdmVydyxpYnBiLWVudHJ5fT08Ym9vbD58e3B2LGh2bX09PGJvb2w+
LAogPiAgICAgICAgICAgICAgYnRpLXRodW5rPXJldHBvbGluZXxsZmVuY2V8
am1wLCB7aWJycyxpYnBiLHNzYmQscHNmZCwKID4gICAgICAgICAgICAgIGVh
Z2VyLWZwdSxsMWQtZmx1c2gsYnJhbmNoLWhhcmRlbixzcmItbG9jaywKID4g
ICAgICAgICAgICAgIHVucHJpdi1tbWlvLGdkcy1taXQsZGl2LXNjcnVifT08
Ym9vbD4gXWAKQEAgLTIzOTUsNyArMjM5NSw3IEBAIGluIHBsYWNlIGZvciBn
dWVzdHMgdG8gdXNlLgogCiBVc2Ugb2YgYSBwb3NpdGl2ZSBib29sZWFuIHZh
bHVlIGZvciBlaXRoZXIgb2YgdGhlc2Ugb3B0aW9ucyBpcyBpbnZhbGlkLgog
Ci1UaGUgYHB2PWAsIGBodm09YCwgYG1zci1zYz1gLCBgcnNiPWAsIGBtZC1j
bGVhcj1gIGFuZCBgaWJwYi1lbnRyeT1gIG9wdGlvbnMKK1RoZSBgcHY9YCwg
YGh2bT1gLCBgbXNyLXNjPWAsIGByc2I9YCwgYHZlcnc9YCBhbmQgYGlicGIt
ZW50cnk9YCBvcHRpb25zCiBvZmZlciBmaW5lIGdyYWluZWQgY29udHJvbCBv
dmVyIHRoZSBwcmltaXRpdmVzIGJ5IFhlbi4gIFRoZXNlIGltcGFjdCBYZW4n
cwogYWJpbGl0eSB0byBwcm90ZWN0IGl0c2VsZiwgYW5kL29yIFhlbidzIGFi
aWxpdHkgdG8gdmlydHVhbGlzZSBzdXBwb3J0IGZvcgogZ3Vlc3RzIHRvIHVz
ZS4KQEAgLTI0MTIsMTEgKzI0MTIsMTIgQEAgZ3Vlc3RzIHRvIHVzZS4KICAg
Z3Vlc3RzIGFuZCBpZiBkaXNhYmxlZCwgZ3Vlc3RzIHdpbGwgYmUgdW5hYmxl
IHRvIHVzZSBJQlJTL1NUSUJQL1NTQkQvZXRjLgogKiBgcnNiPWAgb2ZmZXJz
IGNvbnRyb2wgb3ZlciB3aGV0aGVyIHRvIG92ZXJ3cml0ZSB0aGUgUmV0dXJu
IFN0YWNrIEJ1ZmZlciAvCiAgIFJldHVybiBBZGRyZXNzIFN0YWNrIG9uIGVu
dHJ5IHRvIFhlbiBhbmQgb24gaWRsZS4KLSogYG1kLWNsZWFyPWAgb2ZmZXJz
IGNvbnRyb2wgb3ZlciB3aGV0aGVyIHRvIHVzZSBWRVJXIHRvIGZsdXNoCi0g
IG1pY3JvYXJjaGl0ZWN0dXJhbCBidWZmZXJzIG9uIGlkbGUgYW5kIGV4aXQg
ZnJvbSBYZW4uICAqTm90ZTogRm9yCi0gIGNvbXBhdGliaWxpdHkgd2l0aCBk
ZXZlbG9wbWVudCB2ZXJzaW9ucyBvZiB0aGlzIGZpeCwgYG1kcz1gIGlzIGFs
c28gYWNjZXB0ZWQKLSAgb24gWGVuIDQuMTIgYW5kIGVhcmxpZXIgYXMgYW4g
YWxpYXMuICBDb25zdWx0IHZlbmRvciBkb2N1bWVudGF0aW9uIGluCi0gIHBy
ZWZlcmVuY2UgdG8gaGVyZS4qCisqIGB2ZXJ3PWAgb2ZmZXJzIGNvbnRyb2wg
b3ZlciB3aGV0aGVyIHRvIHVzZSBWRVJXIGZvciBpdHMgc2NydWJiaW5nIHNp
ZGUKKyAgZWZmZWN0cyBhdCBhcHByb3ByaWF0ZSBwcml2aWxlZ2UgdHJhbnNp
dGlvbnMuICBUaGUgZXhhY3Qgc2lkZSBlZmZlY3RzIGFyZQorICBtaWNyb2Fy
Y2hpdGVjdHVyZSBhbmQgbWljcm9jb2RlIHNwZWNpZmljLiAgKk5vdGU6IGBt
ZC1jbGVhcj1gIGlzIGFjY2VwdGVkIGFzCisgIGEgZGVwcmVjYXRlZCBhbGlh
cy4gIEZvciBjb21wYXRpYmlsaXR5IHdpdGggZGV2ZWxvcG1lbnQgdmVyc2lv
bnMgb2YgWFNBLTI5NywKKyAgYG1kcz1gIGlzIGFsc28gYWNjZXB0ZWQgb24g
WGVuIDQuMTIgYW5kIGVhcmxpZXIgYXMgYW4gYWxpYXMuICBDb25zdWx0IHZl
bmRvcgorICBkb2N1bWVudGF0aW9uIGluIHByZWZlcmVuY2UgdG8gaGVyZS4q
CiAqIGBpYnBiLWVudHJ5PWAgb2ZmZXJzIGNvbnRyb2wgb3ZlciB3aGV0aGVy
IElCUEIgKEluZGlyZWN0IEJyYW5jaCBQcmVkaWN0aW9uCiAgIEJhcnJpZXIp
IGlzIHVzZWQgb24gZW50cnkgdG8gWGVuLiAgVGhpcyBpcyB1c2VkIGJ5IGRl
ZmF1bHQgb24gaGFyZHdhcmUKICAgdnVsbmVyYWJsZSB0byBCcmFuY2ggVHlw
ZSBDb25mdXNpb24sIGFuZCBoYXJkd2FyZSB2dWxuZXJhYmxlIHRvIFNwZWN1
bGF0aXZlCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYvc3BlY19jdHJsLmMg
Yi94ZW4vYXJjaC94ODYvc3BlY19jdHJsLmMKaW5kZXggYTk2NWI2ZGIyOGJh
Li5jNDJkOGNkYzIyZDYgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9zcGVj
X2N0cmwuYworKysgYi94ZW4vYXJjaC94ODYvc3BlY19jdHJsLmMKQEAgLTI1
LDggKzI1LDggQEAgc3RhdGljIGJvb2wgX19pbml0ZGF0YSBvcHRfbXNyX3Nj
X3B2ID0gdHJ1ZTsKIHN0YXRpYyBib29sIF9faW5pdGRhdGEgb3B0X21zcl9z
Y19odm0gPSB0cnVlOwogc3RhdGljIGludDhfdCBfX2luaXRkYXRhIG9wdF9y
c2JfcHYgPSAtMTsKIHN0YXRpYyBib29sIF9faW5pdGRhdGEgb3B0X3JzYl9o
dm0gPSB0cnVlOwotc3RhdGljIGludDhfdCBfX3JvX2FmdGVyX2luaXQgb3B0
X21kX2NsZWFyX3B2ID0gLTE7Ci1zdGF0aWMgaW50OF90IF9fcm9fYWZ0ZXJf
aW5pdCBvcHRfbWRfY2xlYXJfaHZtID0gLTE7CitzdGF0aWMgaW50OF90IF9f
cm9fYWZ0ZXJfaW5pdCBvcHRfdmVyd19wdiA9IC0xOworc3RhdGljIGludDhf
dCBfX3JvX2FmdGVyX2luaXQgb3B0X3ZlcndfaHZtID0gLTE7CiAKIHN0YXRp
YyBpbnQ4X3QgX19yb19hZnRlcl9pbml0IG9wdF9pYnBiX2VudHJ5X3B2ID0g
LTE7CiBzdGF0aWMgaW50OF90IF9fcm9fYWZ0ZXJfaW5pdCBvcHRfaWJwYl9l
bnRyeV9odm0gPSAtMTsKQEAgLTY2LDcgKzY2LDcgQEAgc3RhdGljIGJvb2wg
X19pbml0ZGF0YSBjcHVfaGFzX2J1Z19tZHM7IC8qIEFueSBvdGhlciBNe0xQ
LFNCLEZCfURTIGNvbWJpbmF0aW9uLgogCiBzdGF0aWMgaW50OF90IF9faW5p
dGRhdGEgb3B0X3NyYl9sb2NrID0gLTE7CiBzdGF0aWMgYm9vbCBfX2luaXRk
YXRhIG9wdF91bnByaXZfbW1pbzsKLXN0YXRpYyBib29sIF9fcm9fYWZ0ZXJf
aW5pdCBvcHRfZmJfY2xlYXJfbW1pbzsKK3N0YXRpYyBib29sIF9fcm9fYWZ0
ZXJfaW5pdCBvcHRfdmVyd19tbWlvOwogc3RhdGljIGludDhfdCBfX2luaXRk
YXRhIG9wdF9nZHNfbWl0ID0gLTE7CiBzdGF0aWMgaW50OF90IF9faW5pdGRh
dGEgb3B0X2Rpdl9zY3J1YiA9IC0xOwogCkBAIC0xMDgsOCArMTA4LDggQEAg
c3RhdGljIGludCBfX2luaXQgY2ZfY2hlY2sgcGFyc2Vfc3BlY19jdHJsKGNv
bnN0IGNoYXIgKnMpCiAgICAgICAgIGRpc2FibGVfY29tbW9uOgogICAgICAg
ICAgICAgb3B0X3JzYl9wdiA9IGZhbHNlOwogICAgICAgICAgICAgb3B0X3Jz
Yl9odm0gPSBmYWxzZTsKLSAgICAgICAgICAgIG9wdF9tZF9jbGVhcl9wdiA9
IDA7Ci0gICAgICAgICAgICBvcHRfbWRfY2xlYXJfaHZtID0gMDsKKyAgICAg
ICAgICAgIG9wdF92ZXJ3X3B2ID0gMDsKKyAgICAgICAgICAgIG9wdF92ZXJ3
X2h2bSA9IDA7CiAgICAgICAgICAgICBvcHRfaWJwYl9lbnRyeV9wdiA9IDA7
CiAgICAgICAgICAgICBvcHRfaWJwYl9lbnRyeV9odm0gPSAwOwogICAgICAg
ICAgICAgb3B0X2licGJfZW50cnlfZG9tMCA9IGZhbHNlOwpAQCAtMTQwLDE0
ICsxNDAsMTQgQEAgc3RhdGljIGludCBfX2luaXQgY2ZfY2hlY2sgcGFyc2Vf
c3BlY19jdHJsKGNvbnN0IGNoYXIgKnMpCiAgICAgICAgIHsKICAgICAgICAg
ICAgIG9wdF9tc3Jfc2NfcHYgPSB2YWw7CiAgICAgICAgICAgICBvcHRfcnNi
X3B2ID0gdmFsOwotICAgICAgICAgICAgb3B0X21kX2NsZWFyX3B2ID0gdmFs
OworICAgICAgICAgICAgb3B0X3ZlcndfcHYgPSB2YWw7CiAgICAgICAgICAg
ICBvcHRfaWJwYl9lbnRyeV9wdiA9IHZhbDsKICAgICAgICAgfQogICAgICAg
ICBlbHNlIGlmICggKHZhbCA9IHBhcnNlX2Jvb2xlYW4oImh2bSIsIHMsIHNz
KSkgPj0gMCApCiAgICAgICAgIHsKICAgICAgICAgICAgIG9wdF9tc3Jfc2Nf
aHZtID0gdmFsOwogICAgICAgICAgICAgb3B0X3JzYl9odm0gPSB2YWw7Ci0g
ICAgICAgICAgICBvcHRfbWRfY2xlYXJfaHZtID0gdmFsOworICAgICAgICAg
ICAgb3B0X3ZlcndfaHZtID0gdmFsOwogICAgICAgICAgICAgb3B0X2licGJf
ZW50cnlfaHZtID0gdmFsOwogICAgICAgICB9CiAgICAgICAgIGVsc2UgaWYg
KCAodmFsID0gcGFyc2VfYm9vbGVhbigibXNyLXNjIiwgcywgc3MpKSAhPSAt
MSApCkBAIC0xOTIsMjEgKzE5MiwyMiBAQCBzdGF0aWMgaW50IF9faW5pdCBj
Zl9jaGVjayBwYXJzZV9zcGVjX2N0cmwoY29uc3QgY2hhciAqcykKICAgICAg
ICAgICAgICAgICBicmVhazsKICAgICAgICAgICAgIH0KICAgICAgICAgfQot
ICAgICAgICBlbHNlIGlmICggKHZhbCA9IHBhcnNlX2Jvb2xlYW4oIm1kLWNs
ZWFyIiwgcywgc3MpKSAhPSAtMSApCisgICAgICAgIGVsc2UgaWYgKCAodmFs
ID0gcGFyc2VfYm9vbGVhbigidmVydyIsIHMsIHNzKSkgIT0gLTEgfHwKKyAg
ICAgICAgICAgICAgICAgICh2YWwgPSBwYXJzZV9ib29sZWFuKCJtZC1jbGVh
ciIsIHMsIHNzKSkgIT0gLTEgKQogICAgICAgICB7CiAgICAgICAgICAgICBz
d2l0Y2ggKCB2YWwgKQogICAgICAgICAgICAgewogICAgICAgICAgICAgY2Fz
ZSAwOgogICAgICAgICAgICAgY2FzZSAxOgotICAgICAgICAgICAgICAgIG9w
dF9tZF9jbGVhcl9wdiA9IG9wdF9tZF9jbGVhcl9odm0gPSB2YWw7CisgICAg
ICAgICAgICAgICAgb3B0X3ZlcndfcHYgPSBvcHRfdmVyd19odm0gPSB2YWw7
CiAgICAgICAgICAgICAgICAgYnJlYWs7CiAKICAgICAgICAgICAgIGNhc2Ug
LTI6Ci0gICAgICAgICAgICAgICAgcyArPSBzdHJsZW4oIm1kLWNsZWFyPSIp
OworICAgICAgICAgICAgICAgIHMgKz0gKCpzID09ICd2JykgPyBzdHJsZW4o
InZlcnc9IikgOiBzdHJsZW4oIm1kLWNsZWFyPSIpOwogICAgICAgICAgICAg
ICAgIGlmICggKHZhbCA9IHBhcnNlX2Jvb2xlYW4oInB2Iiwgcywgc3MpKSA+
PSAwICkKLSAgICAgICAgICAgICAgICAgICAgb3B0X21kX2NsZWFyX3B2ID0g
dmFsOworICAgICAgICAgICAgICAgICAgICBvcHRfdmVyd19wdiA9IHZhbDsK
ICAgICAgICAgICAgICAgICBlbHNlIGlmICggKHZhbCA9IHBhcnNlX2Jvb2xl
YW4oImh2bSIsIHMsIHNzKSkgPj0gMCApCi0gICAgICAgICAgICAgICAgICAg
IG9wdF9tZF9jbGVhcl9odm0gPSB2YWw7CisgICAgICAgICAgICAgICAgICAg
IG9wdF92ZXJ3X2h2bSA9IHZhbDsKICAgICAgICAgICAgICAgICBlbHNlCiAg
ICAgICAgICAgICBkZWZhdWx0OgogICAgICAgICAgICAgICAgICAgICByYyA9
IC1FSU5WQUw7CkBAIC01MjgsOCArNTI5LDggQEAgc3RhdGljIHZvaWQgX19p
bml0IHByaW50X2RldGFpbHMoZW51bSBpbmRfdGh1bmsgdGh1bmspCiAgICAg
ICAgICAgIG9wdF9zcmJfbG9jayAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgID8gIiBTUkJfTE9DSysiIDogIiBTUkJfTE9DSy0iLAogICAgICAgICAg
ICBvcHRfaWJwYl9jdHh0X3N3aXRjaCAgICAgICAgICAgICAgICAgICAgICA/
ICIgSUJQQi1jdHh0IiA6ICIiLAogICAgICAgICAgICBvcHRfbDFkX2ZsdXNo
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA/ICIgTDFEX0ZMVVNIIiA6
ICIiLAotICAgICAgICAgICBvcHRfbWRfY2xlYXJfcHYgfHwgb3B0X21kX2Ns
ZWFyX2h2bSB8fAotICAgICAgICAgICBvcHRfZmJfY2xlYXJfbW1pbyAgICAg
ICAgICAgICAgICAgICAgICAgICA/ICIgVkVSVyIgIDogIiIsCisgICAgICAg
ICAgIG9wdF92ZXJ3X3B2IHx8IG9wdF92ZXJ3X2h2bSB8fAorICAgICAgICAg
ICBvcHRfdmVyd19tbWlvICAgICAgICAgICAgICAgICAgICAgICAgICAgICA/
ICIgVkVSVyIgIDogIiIsCiAgICAgICAgICAgIG9wdF9kaXZfc2NydWIgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgID8gIiBESVYiIDogIiIsCiAgICAg
ICAgICAgIG9wdF9icmFuY2hfaGFyZGVuICAgICAgICAgICAgICAgICAgICAg
ICAgID8gIiBCUkFOQ0hfSEFSREVOIiA6ICIiKTsKIApAQCAtNTUwLDEzICs1
NTEsMTMgQEAgc3RhdGljIHZvaWQgX19pbml0IHByaW50X2RldGFpbHMoZW51
bSBpbmRfdGh1bmsgdGh1bmspCiAgICAgICAgICAgICBib290X2NwdV9oYXMo
WDg2X0ZFQVRVUkVfU0NfUlNCX0hWTSkgfHwKICAgICAgICAgICAgIGJvb3Rf
Y3B1X2hhcyhYODZfRkVBVFVSRV9JQlBCX0VOVFJZX0hWTSkgfHwKICAgICAg
ICAgICAgIGFtZF92aXJ0X3NwZWNfY3RybCB8fAotICAgICAgICAgICAgb3B0
X2VhZ2VyX2ZwdSB8fCBvcHRfbWRfY2xlYXJfaHZtKSAgICAgICA/ICIiICAg
ICAgICAgICAgICAgOiAiIE5vbmUiLAorICAgICAgICAgICAgb3B0X2VhZ2Vy
X2ZwdSB8fCBvcHRfdmVyd19odm0pICAgICAgICAgICA/ICIiICAgICAgICAg
ICAgICAgOiAiIE5vbmUiLAogICAgICAgICAgICBib290X2NwdV9oYXMoWDg2
X0ZFQVRVUkVfU0NfTVNSX0hWTSkgICAgICA/ICIgTVNSX1NQRUNfQ1RSTCIg
OiAiIiwKICAgICAgICAgICAgKGJvb3RfY3B1X2hhcyhYODZfRkVBVFVSRV9T
Q19NU1JfSFZNKSB8fAogICAgICAgICAgICAgYW1kX3ZpcnRfc3BlY19jdHJs
KSAgICAgICAgICAgICAgICAgICAgICA/ICIgTVNSX1ZJUlRfU1BFQ19DVFJM
IiA6ICIiLAogICAgICAgICAgICBib290X2NwdV9oYXMoWDg2X0ZFQVRVUkVf
U0NfUlNCX0hWTSkgICAgICA/ICIgUlNCIiAgICAgICAgICAgOiAiIiwKICAg
ICAgICAgICAgb3B0X2VhZ2VyX2ZwdSAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgPyAiIEVBR0VSX0ZQVSIgICAgIDogIiIsCi0gICAgICAgICAgIG9w
dF9tZF9jbGVhcl9odm0gICAgICAgICAgICAgICAgICAgICAgICAgID8gIiBN
RF9DTEVBUiIgICAgICA6ICIiLAorICAgICAgICAgICBvcHRfdmVyd19odm0g
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA/ICIgVkVSVyIgICAgICAg
ICAgOiAiIiwKICAgICAgICAgICAgYm9vdF9jcHVfaGFzKFg4Nl9GRUFUVVJF
X0lCUEJfRU5UUllfSFZNKSAgPyAiIElCUEItZW50cnkiICAgIDogIiIpOwog
CiAjZW5kaWYKQEAgLTU2NSwxMSArNTY2LDExIEBAIHN0YXRpYyB2b2lkIF9f
aW5pdCBwcmludF9kZXRhaWxzKGVudW0gaW5kX3RodW5rIHRodW5rKQogICAg
ICAgICAgICAoYm9vdF9jcHVfaGFzKFg4Nl9GRUFUVVJFX1NDX01TUl9QVikg
fHwKICAgICAgICAgICAgIGJvb3RfY3B1X2hhcyhYODZfRkVBVFVSRV9TQ19S
U0JfUFYpIHx8CiAgICAgICAgICAgICBib290X2NwdV9oYXMoWDg2X0ZFQVRV
UkVfSUJQQl9FTlRSWV9QVikgfHwKLSAgICAgICAgICAgIG9wdF9lYWdlcl9m
cHUgfHwgb3B0X21kX2NsZWFyX3B2KSAgICAgICAgPyAiIiAgICAgICAgICAg
ICAgIDogIiBOb25lIiwKKyAgICAgICAgICAgIG9wdF9lYWdlcl9mcHUgfHwg
b3B0X3ZlcndfcHYpICAgICAgICAgICAgPyAiIiAgICAgICAgICAgICAgIDog
IiBOb25lIiwKICAgICAgICAgICAgYm9vdF9jcHVfaGFzKFg4Nl9GRUFUVVJF
X1NDX01TUl9QVikgICAgICAgPyAiIE1TUl9TUEVDX0NUUkwiIDogIiIsCiAg
ICAgICAgICAgIGJvb3RfY3B1X2hhcyhYODZfRkVBVFVSRV9TQ19SU0JfUFYp
ICAgICAgID8gIiBSU0IiICAgICAgICAgICA6ICIiLAogICAgICAgICAgICBv
cHRfZWFnZXJfZnB1ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA/ICIg
RUFHRVJfRlBVIiAgICAgOiAiIiwKLSAgICAgICAgICAgb3B0X21kX2NsZWFy
X3B2ICAgICAgICAgICAgICAgICAgICAgICAgICAgPyAiIE1EX0NMRUFSIiAg
ICAgIDogIiIsCisgICAgICAgICAgIG9wdF92ZXJ3X3B2ICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgID8gIiBWRVJXIiAgICAgICAgICA6ICIiLAog
ICAgICAgICAgICBib290X2NwdV9oYXMoWDg2X0ZFQVRVUkVfSUJQQl9FTlRS
WV9QVikgICA/ICIgSUJQQi1lbnRyeSIgICAgOiAiIik7CiAKICAgICBwcmlu
dGsoIiAgWFBUSSAoNjQtYml0IFBWIG9ubHkpOiBEb20wICVzLCBEb21VICVz
ICh3aXRoJXMgUENJRClcbiIsCkBAIC0xNTAyLDggKzE1MDMsOCBAQCB2b2lk
IHNwZWNfY3RybF9pbml0X2RvbWFpbihzdHJ1Y3QgZG9tYWluICpkKQogewog
ICAgIGJvb2wgcHYgPSBpc19wdl9kb21haW4oZCk7CiAKLSAgICBib29sIHZl
cncgPSAoKHB2ID8gb3B0X21kX2NsZWFyX3B2IDogb3B0X21kX2NsZWFyX2h2
bSkgfHwKLSAgICAgICAgICAgICAgICAgKG9wdF9mYl9jbGVhcl9tbWlvICYm
IGlzX2lvbW11X2VuYWJsZWQoZCkpKTsKKyAgICBib29sIHZlcncgPSAoKHB2
ID8gb3B0X3ZlcndfcHYgOiBvcHRfdmVyd19odm0pIHx8CisgICAgICAgICAg
ICAgICAgIChvcHRfdmVyd19tbWlvICYmIGlzX2lvbW11X2VuYWJsZWQoZCkp
KTsKIAogICAgIGJvb2wgaWJwYiA9ICgocHYgPyBvcHRfaWJwYl9lbnRyeV9w
diA6IG9wdF9pYnBiX2VudHJ5X2h2bSkgJiYKICAgICAgICAgICAgICAgICAg
KGQtPmRvbWFpbl9pZCAhPSAwIHx8IG9wdF9pYnBiX2VudHJ5X2RvbTApKTsK
QEAgLTE4NjYsMTkgKzE4NjcsMjAgQEAgdm9pZCBfX2luaXQgaW5pdF9zcGVj
dWxhdGlvbl9taXRpZ2F0aW9ucyh2b2lkKQogICAgICAqIHRoZSByZXR1cm4t
dG8tZ3Vlc3QgcGF0aC4KICAgICAgKi8KICAgICBpZiAoIG9wdF91bnByaXZf
bW1pbyApCi0gICAgICAgIG9wdF9mYl9jbGVhcl9tbWlvID0gY3B1X2hhc19m
Yl9jbGVhcjsKKyAgICAgICAgb3B0X3ZlcndfbW1pbyA9IGNwdV9oYXNfZmJf
Y2xlYXI7CiAKICAgICAvKgogICAgICAqIEJ5IGRlZmF1bHQsIGVuYWJsZSBQ
ViBhbmQgSFZNIG1pdGlnYXRpb25zIG9uIE1EUy12dWxuZXJhYmxlIGhhcmR3
YXJlLgogICAgICAqIFRoaXMgd2lsbCBvbmx5IGJlIGEgdG9rZW4gZWZmb3J0
IGZvciBNTFBEUy9NRkJEUyB3aGVuIEhUIGlzIGVuYWJsZWQsCiAgICAgICog
YnV0IGl0IGlzIHNvbWV3aGF0IGJldHRlciB0aGFuIG5vdGhpbmcuCiAgICAg
ICovCi0gICAgaWYgKCBvcHRfbWRfY2xlYXJfcHYgPT0gLTEgKQotICAgICAg
ICBvcHRfbWRfY2xlYXJfcHYgPSAoKGNwdV9oYXNfYnVnX21kcyB8fCBjcHVf
aGFzX2J1Z19tc2Jkc19vbmx5KSAmJgotICAgICAgICAgICAgICAgICAgICAg
ICAgICAgYm9vdF9jcHVfaGFzKFg4Nl9GRUFUVVJFX01EX0NMRUFSKSk7Ci0g
ICAgaWYgKCBvcHRfbWRfY2xlYXJfaHZtID09IC0xICkKLSAgICAgICAgb3B0
X21kX2NsZWFyX2h2bSA9ICgoY3B1X2hhc19idWdfbWRzIHx8IGNwdV9oYXNf
YnVnX21zYmRzX29ubHkpICYmCi0gICAgICAgICAgICAgICAgICAgICAgICAg
ICAgYm9vdF9jcHVfaGFzKFg4Nl9GRUFUVVJFX01EX0NMRUFSKSk7CisgICAg
aWYgKCBvcHRfdmVyd19wdiA9PSAtMSApCisgICAgICAgIG9wdF92ZXJ3X3B2
ID0gKChjcHVfaGFzX2J1Z19tZHMgfHwgY3B1X2hhc19idWdfbXNiZHNfb25s
eSkgJiYKKyAgICAgICAgICAgICAgICAgICAgICAgY3B1X2hhc19tZF9jbGVh
cik7CisKKyAgICBpZiAoIG9wdF92ZXJ3X2h2bSA9PSAtMSApCisgICAgICAg
IG9wdF92ZXJ3X2h2bSA9ICgoY3B1X2hhc19idWdfbWRzIHx8IGNwdV9oYXNf
YnVnX21zYmRzX29ubHkpICYmCisgICAgICAgICAgICAgICAgICAgICAgICBj
cHVfaGFzX21kX2NsZWFyKTsKIAogICAgIC8qCiAgICAgICogRW5hYmxlIE1E
Uy9NTUlPIGRlZmVuY2VzIGFzIGFwcGxpY2FibGUuICBUaGUgSWRsZSBibG9j
a3MgbmVlZCB1c2luZyBpZgpAQCAtMTg5MSwxMiArMTg5MywxMiBAQCB2b2lk
IF9faW5pdCBpbml0X3NwZWN1bGF0aW9uX21pdGlnYXRpb25zKHZvaWQpCiAg
ICAgICogTURTIG1pdGlnYXRpb25zLiAgTDFEX0ZMVVNIIGlzIG5vdCBzYWZl
IGZvciBNTUlPIG1pdGlnYXRpb25zLikKICAgICAgKgogICAgICAqIEFmdGVy
IGNhbGN1bGF0aW5nIHRoZSBhcHByb3ByaWF0ZSBpZGxlIHNldHRpbmcsIHNp
bXBsaWZ5Ci0gICAgICogb3B0X21kX2NsZWFyX2h2bSB0byBtZWFuIGp1c3Qg
InNob3VsZCB3ZSBWRVJXIG9uIHRoZSB3YXkgaW50byBIVk0KKyAgICAgKiBv
cHRfdmVyd19odm0gdG8gbWVhbiBqdXN0ICJzaG91bGQgd2UgVkVSVyBvbiB0
aGUgd2F5IGludG8gSFZNCiAgICAgICogZ3Vlc3RzIiwgc28gc3BlY19jdHJs
X2luaXRfZG9tYWluKCkgY2FuIGNhbGN1bGF0ZSBzdWl0YWJsZSBzZXR0aW5n
cy4KICAgICAgKi8KLSAgICBpZiAoIG9wdF9tZF9jbGVhcl9wdiB8fCBvcHRf
bWRfY2xlYXJfaHZtIHx8IG9wdF9mYl9jbGVhcl9tbWlvICkKKyAgICBpZiAo
IG9wdF92ZXJ3X3B2IHx8IG9wdF92ZXJ3X2h2bSB8fCBvcHRfdmVyd19tbWlv
ICkKICAgICAgICAgc2V0dXBfZm9yY2VfY3B1X2NhcChYODZfRkVBVFVSRV9T
Q19WRVJXX0lETEUpOwotICAgIG9wdF9tZF9jbGVhcl9odm0gJj0gIWNwdV9o
YXNfc2tpcF9sMWRmbCAmJiAhb3B0X2wxZF9mbHVzaDsKKyAgICBvcHRfdmVy
d19odm0gJj0gIWNwdV9oYXNfc2tpcF9sMWRmbCAmJiAhb3B0X2wxZF9mbHVz
aDsKIAogICAgIC8qCiAgICAgICogV2FybiB0aGUgdXNlciBpZiB0aGV5IGFy
ZSBvbiBNTFBEUy9NRkJEUy12dWxuZXJhYmxlIGhhcmR3YXJlIHdpdGggSFQK

--=separator
Content-Type: application/octet-stream; name="xsa452/xsa452-4.18-6.patch"
Content-Disposition: attachment; filename="xsa452/xsa452-4.18-6.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L3NwZWMtY3RybDogVkVSVy1oYW5kbGluZyBhZGp1
c3RtZW50cwoKLi4uIGJlZm9yZSB3ZSBhZGQgeWV0IG1vcmUgY29tcGxleGl0
eSB0byB0aGlzIGxvZ2ljLiAgTW9zdGx5IGV4cGFuZGVkCmNvbW1lbnRzLCBi
dXQgd2l0aCB0aHJlZSBtaW5vciBjaGFuZ2VzLgoKMSkgSW50cm9kdWNlIGNw
dV9oYXNfdXNlZnVsX21kX2NsZWFyIHRvIHNpbXBsaWZ5IGxhdGVyIGxvZ2lj
IGluIHRoaXMgcGF0Y2ggYW5kCiAgIGZ1dHVyZSBvbmVzLgoKMikgV2Ugb25s
eSBldmVyIG5lZWQgU0NfVkVSV19JRExFIHdoZW4gU01UIGlzIGFjdGl2ZS4g
IElmIFNNVCBpc24ndCBhY3RpdmUsCiAgIHRoZW4gdGhlcmUncyBubyByZS1w
YXJ0aXRpb24gb2YgcGlwZWxpbmUgcmVzb3VyY2VzIGJhc2VkIG9uIHRocmVh
ZC1pZGxlbmVzcwogICB0byB3b3JyeSBhYm91dC4KCjMpIFRoZSBsb2dpYyB0
byBhZGp1c3QgSFZNIFZFUlcgYmFzZWQgb24gTDFEX0ZMVVNIIGlzIHVubWFp
bnRhaW5hYmxlIGFuZCwgYXMKICAgaXQgdHVybnMgb3V0LCB3cm9uZy4gIFNL
SVBfTDFERkwgaXMganVzdCBhIGhpbnQgYml0LCB3aGVyZWFzIG9wdF9sMWRf
Zmx1c2gKICAgaXMgdGhlIHJlbGV2YW50IGRlY2lzaW9uIG9mIHdoZXRoZXIg
dG8gdXNlIEwxRF9GTFVTSCBiYXNlZCBvbgogICBzdXNjZXB0aWJpbGl0eSBh
bmQgdXNlciBwcmVmZXJlbmNlLgoKICAgUmV3cml0ZSB0aGUgbG9naWMgc28g
aXQgY2FuIGJlIGZvbGxvd2VkLCBhbmQgaW5jb3Jwb3JhdGUgdGhlIGZhY3Qg
dGhhdCB3aGVuCiAgIEZCX0NMRUFSIGlzIHZpc2libGUsIEwxRF9GTFVTSCBp
c24ndCBhIHNhZmUgc3Vic3RpdHV0aW9uLgoKVGhpcyBpcyBwYXJ0IG9mIFhT
QS00NTIgLyBDVkUtMjAyMy0yODc0Ni4KClNpZ25lZC1vZmYtYnk6IEFuZHJl
dyBDb29wZXIgPGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+CkFja2VkLWJ5
OiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+CihjaGVycnkgcGlj
a2VkIGZyb20gY29tbWl0IDFlYjkxYThhMDYyMzBiNGI2NDIyOGM5YTM4MDE5
NGY4Y2ZlNmM1ZTIpCgpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L3NwZWNf
Y3RybC5jIGIveGVuL2FyY2gveDg2L3NwZWNfY3RybC5jCmluZGV4IGM0MmQ4
Y2RjMjJkNi4uYTRhZmNkODU3MGUyIDEwMDY0NAotLS0gYS94ZW4vYXJjaC94
ODYvc3BlY19jdHJsLmMKKysrIGIveGVuL2FyY2gveDg2L3NwZWNfY3RybC5j
CkBAIC0xNTE5LDcgKzE1MTksNyBAQCB2b2lkIF9faW5pdCBpbml0X3NwZWN1
bGF0aW9uX21pdGlnYXRpb25zKHZvaWQpCiB7CiAgICAgZW51bSBpbmRfdGh1
bmsgdGh1bmsgPSBUSFVOS19ERUZBVUxUOwogICAgIGJvb2wgaGFzX3NwZWNf
Y3RybCwgaWJycyA9IGZhbHNlLCBod19zbXRfZW5hYmxlZDsKLSAgICBib29s
IGNwdV9oYXNfYnVnX3RhYSwgcmV0cG9saW5lX3NhZmU7CisgICAgYm9vbCBj
cHVfaGFzX2J1Z190YWEsIGNwdV9oYXNfdXNlZnVsX21kX2NsZWFyLCByZXRw
b2xpbmVfc2FmZTsKIAogICAgIGh3X3NtdF9lbmFibGVkID0gY2hlY2tfc210
X2VuYWJsZWQoKTsKIApAQCAtMTg1NSw1MCArMTg1NSw5NyBAQCB2b2lkIF9f
aW5pdCBpbml0X3NwZWN1bGF0aW9uX21pdGlnYXRpb25zKHZvaWQpCiAgICAg
ICAgICAgICAiZW5hYmxlZC4gIFBsZWFzZSBhc3Nlc3MgeW91ciBjb25maWd1
cmF0aW9uIGFuZCBjaG9vc2UgYW5cbiIKICAgICAgICAgICAgICJleHBsaWNp
dCAnc210PTxib29sPicgc2V0dGluZy4gIFNlZSBYU0EtMjczLlxuIik7CiAK
KyAgICAvKgorICAgICAqIEEgYnJpZWYgc3VtbWFyeSBvZiBWRVJXLXJlbGF0
ZWQgY2hhbmdlcy4KKyAgICAgKgorICAgICAqIGh0dHBzOi8vd3d3LmludGVs
LmNvbS9jb250ZW50L3d3dy91cy9lbi9kZXZlbG9wZXIvYXJ0aWNsZXMvdGVj
aG5pY2FsL3NvZnR3YXJlLXNlY3VyaXR5LWd1aWRhbmNlL3RlY2huaWNhbC1k
b2N1bWVudGF0aW9uL2ludGVsLWFuYWx5c2lzLW1pY3JvYXJjaGl0ZWN0dXJh
bC1kYXRhLXNhbXBsaW5nLmh0bWwKKyAgICAgKiBodHRwczovL3d3dy5pbnRl
bC5jb20vY29udGVudC93d3cvdXMvZW4vZGV2ZWxvcGVyL2FydGljbGVzL3Rl
Y2huaWNhbC9zb2Z0d2FyZS1zZWN1cml0eS1ndWlkYW5jZS90ZWNobmljYWwt
ZG9jdW1lbnRhdGlvbi9wcm9jZXNzb3ItbW1pby1zdGFsZS1kYXRhLXZ1bG5l
cmFiaWxpdGllcy5odG1sCisgICAgICoKKyAgICAgKiBSZWxldmFudCB1Y29k
ZXM6CisgICAgICoKKyAgICAgKiAtIE1heSAyMDE5LCBmb3IgTURTLiAgSW50
cm9kdWNlcyB0aGUgTURfQ0xFQVIgQ1BVSUQgYml0IGFuZCBWRVJXIHNpZGUK
KyAgICAgKiAgIGVmZmVjdHMgdG8gc2NydWIgU3RvcmUvTG9hZC9GaWxsIGJ1
ZmZlcnMgYXMgYXBwbGljYWJsZS4gIE1EX0NMRUFSCisgICAgICogICBleGlz
dHMgYXJjaGl0ZWN0dXJhbGx5LCBldmVuIHdoZW4gdGhlIHNpZGUgZWZmZWN0
cyBoYXZlIGJlZW4gcmVtb3ZlZC4KKyAgICAgKgorICAgICAqICAgVXNlIFZF
UlcgdG8gc2NydWIgb24gcmV0dXJuLXRvLWd1ZXN0LiAgUGFydHMgd2l0aCBM
MURfRkxVU0ggdG8KKyAgICAgKiAgIG1pdGlnYXRlIEwxVEYgaGF2ZSB0aGUg
c2FtZSBzaWRlIGVmZmVjdCwgc28gbm8gbmVlZCB0byBkbyBib3RoLgorICAg
ICAqCisgICAgICogICBWYXJpb3VzIEF0b21zIHN1ZmZlciBmcm9tIFN0b3Jl
LWJ1ZmZlciBzYW1wbGluZyBvbmx5LiAgU3RvcmUgYnVmZmVycworICAgICAq
ICAgYXJlIHN0YXRpY2FsbHkgcGFydGl0aW9uZWQgYmV0d2VlbiBub24taWRs
ZSB0aHJlYWRzLCBzbyBzY3J1YmJpbmcgaXMKKyAgICAgKiAgIHdhbnRlZCB3
aGVuIGdvaW5nIGlkbGUgdG9vLgorICAgICAqCisgICAgICogICBMb2FkIHBv
cnRzIGFuZCBGaWxsIGJ1ZmZlcnMgYXJlIGNvbXBldGl0aXZlbHkgc2hhcmVk
IGJldHdlZW4gdGhyZWFkcy4KKyAgICAgKiAgIFNNVCBtdXN0IGJlIGRpc2Fi
bGVkIGZvciBWRVJXIHNjcnViYmluZyB0byBiZSBmdWxseSBlZmZlY3RpdmUu
CisgICAgICoKKyAgICAgKiAtIE5vdmVtYmVyIDIwMTksIGZvciBUQUEuICBF
eHRlbmRlZCBWRVJXIHNpZGUgZWZmZWN0cyB0byBUU1gtZW5hYmxlZAorICAg
ICAqICAgTURTX05PIHBhcnRzLgorICAgICAqCisgICAgICogLSBGZWJydWFy
eSAyMDIyLCBmb3IgQ2xpZW50IFRTWCBkZS1mZWF0dXJlLiAgUmVtb3ZlZCBW
RVJXIHNpZGUgZWZmZWN0cworICAgICAqICAgZnJvbSBDbGllbnQgQ1BVcyBv
bmx5LgorICAgICAqCisgICAgICogLSBNYXkgMjAyMiwgZm9yIE1NSU8gU3Rh
bGUgRGF0YS4gIChSZSlpbnRyb2R1Y2VkIEZpbGwgQnVmZmVyIHNjcnViYmlu
ZworICAgICAqICAgb24gYWxsIE1NSU8tYWZmZWN0ZWQgcGFydHMgd2hpY2gg
ZGlkbid0IGFscmVhZHkgaGF2ZSBpdCBmb3IgTURTCisgICAgICogICByZWFz
b25zLCBlbnVtZXJhdGluZyBGQl9DTEVBUiBvbiB0aG9zZSBwYXJ0cyBvbmx5
LgorICAgICAqCisgICAgICogICBJZiBGQl9DTEVBUiBpcyBlbnVtZXJhdGVk
LCBMMURfRkxVU0ggZG9lcyBub3QgaGF2ZSB0aGUgc2FtZSBzY3J1YmJpbmcK
KyAgICAgKiAgIHNpZGUgZWZmZWN0cyBhcyBWRVJXIGFuZCBjYW5ub3QgYmUg
dXNlZCBpbiBpdHMgcGxhY2UuCisgICAgICovCiAgICAgbWRzX2NhbGN1bGF0
aW9ucygpOwogCiAgICAgLyoKLSAgICAgKiBQYXJ0cyB3aGljaCBlbnVtZXJh
dGUgRkJfQ0xFQVIgYXJlIHRob3NlIHdoaWNoIGFyZSBwb3N0LU1EU19OTyBh
bmQgaGF2ZQotICAgICAqIHJlaW50cm9kdWNlZCB0aGUgVkVSVyBmaWxsIGJ1
ZmZlciBmbHVzaGluZyBzaWRlIGVmZmVjdCBiZWNhdXNlIG9mIGEKLSAgICAg
KiBzdXNjZXB0aWJpbGl0eSB0byBGQlNEUC4KKyAgICAgKiBQYXJ0cyB3aGlj
aCBlbnVtZXJhdGUgRkJfQ0xFQVIgYXJlIHRob3NlIHdpdGggbm93LXVwZGF0
ZWQgbWljcm9jb2RlCisgICAgICogd2hpY2ggd2VyZW4ndCBzdXNjZXB0aWJs
ZSB0byB0aGUgb3JpZ2luYWwgTUZCRFMgKGFuZCB0aGVyZWZvcmUgZGlkbid0
CisgICAgICogaGF2ZSBGaWxsIEJ1ZmZlciBzY3J1YmJpbmcgc2lkZSBlZmZl
Y3RzIHRvIGJlZ2luIHdpdGgsIG9yIHdlcmUgQ2xpZW50CisgICAgICogTURT
X05PIG5vbi1UQUFfTk8gcGFydHMgd2hlcmUgdGhlIHNjcnViYmluZyB3YXMg
cmVtb3ZlZCksIGJ1dCBoYXZlIGhhZAorICAgICAqIHRoZSBzY3J1YmJpbmcg
cmVpbnRyb2R1Y2VkIGJlY2F1c2Ugb2YgYSBzdXNjZXB0aWJpbGl0eSB0byBG
QlNEUC4KICAgICAgKgogICAgICAqIElmIHVucHJpdmlsZWdlZCBndWVzdHMg
aGF2ZSAob3Igd2lsbCBoYXZlKSBNTUlPIG1hcHBpbmdzLCB3ZSBjYW4KICAg
ICAgKiBtaXRpZ2F0ZSBjcm9zcy1kb21haW4gbGVha2FnZSBvZiBmaWxsIGJ1
ZmZlciBkYXRhIGJ5IGlzc3VpbmcgVkVSVyBvbgotICAgICAqIHRoZSByZXR1
cm4tdG8tZ3Vlc3QgcGF0aC4KKyAgICAgKiB0aGUgcmV0dXJuLXRvLWd1ZXN0
IHBhdGguICBUaGlzIGlzIG9ubHkgYSB0b2tlbiBlZmZvcnQgaWYgU01UIGlz
CisgICAgICogYWN0aXZlLgogICAgICAqLwogICAgIGlmICggb3B0X3VucHJp
dl9tbWlvICkKICAgICAgICAgb3B0X3ZlcndfbW1pbyA9IGNwdV9oYXNfZmJf
Y2xlYXI7CiAKICAgICAvKgotICAgICAqIEJ5IGRlZmF1bHQsIGVuYWJsZSBQ
ViBhbmQgSFZNIG1pdGlnYXRpb25zIG9uIE1EUy12dWxuZXJhYmxlIGhhcmR3
YXJlLgotICAgICAqIFRoaXMgd2lsbCBvbmx5IGJlIGEgdG9rZW4gZWZmb3J0
IGZvciBNTFBEUy9NRkJEUyB3aGVuIEhUIGlzIGVuYWJsZWQsCi0gICAgICog
YnV0IGl0IGlzIHNvbWV3aGF0IGJldHRlciB0aGFuIG5vdGhpbmcuCisgICAg
ICogTURfQ0xFQVIgaXMgZW51bWVyYXRlZCBhcmNoaXRlY3R1cmFsbHkgZm9y
ZXZlcm1vcmUsIGV2ZW4gYWZ0ZXIgdGhlCisgICAgICogc2NydWJiaW5nIHNp
ZGUgZWZmZWN0cyBoYXZlIGJlZW4gcmVtb3ZlZC4gIENyZWF0ZSBvdXJzZWx2
ZXMgYW4gdmVyc2lvbgorICAgICAqIHdoaWNoIGV4cHJlc3NlZCB3aGV0aGVy
IHdlIHRoaW5rIE1EX0NMRUFSIGlzIGhhdmluZyBhbnkgdXNlZnVsIHNpZGUK
KyAgICAgKiBlZmZlY3QuCisgICAgICovCisgICAgY3B1X2hhc191c2VmdWxf
bWRfY2xlYXIgPSAoY3B1X2hhc19tZF9jbGVhciAmJgorICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIChjcHVfaGFzX2J1Z19tZHMgfHwgY3B1X2hh
c19idWdfbXNiZHNfb25seSkpOworCisgICAgLyoKKyAgICAgKiBCeSBkZWZh
dWx0LCB1c2UgVkVSVyBzY3J1YmJpbmcgb24gYXBwbGljYWJsZSBoYXJkd2Fy
ZSwgaWYgd2UgdGhpbmsgaXQncworICAgICAqIGdvaW5nIHRvIGhhdmUgYW4g
ZWZmZWN0LiAgVGhpcyB3aWxsIG9ubHkgYmUgYSB0b2tlbiBlZmZvcnQgZm9y
CisgICAgICogTUxQRFMvTUZCRFMgd2hlbiBTTVQgaXMgZW5hYmxlZC4KICAg
ICAgKi8KICAgICBpZiAoIG9wdF92ZXJ3X3B2ID09IC0xICkKLSAgICAgICAg
b3B0X3ZlcndfcHYgPSAoKGNwdV9oYXNfYnVnX21kcyB8fCBjcHVfaGFzX2J1
Z19tc2Jkc19vbmx5KSAmJgotICAgICAgICAgICAgICAgICAgICAgICBjcHVf
aGFzX21kX2NsZWFyKTsKKyAgICAgICAgb3B0X3ZlcndfcHYgPSBjcHVfaGFz
X3VzZWZ1bF9tZF9jbGVhcjsKIAogICAgIGlmICggb3B0X3ZlcndfaHZtID09
IC0xICkKLSAgICAgICAgb3B0X3ZlcndfaHZtID0gKChjcHVfaGFzX2J1Z19t
ZHMgfHwgY3B1X2hhc19idWdfbXNiZHNfb25seSkgJiYKLSAgICAgICAgICAg
ICAgICAgICAgICAgIGNwdV9oYXNfbWRfY2xlYXIpOworICAgICAgICBvcHRf
dmVyd19odm0gPSBjcHVfaGFzX3VzZWZ1bF9tZF9jbGVhcjsKIAogICAgIC8q
Ci0gICAgICogRW5hYmxlIE1EUy9NTUlPIGRlZmVuY2VzIGFzIGFwcGxpY2Fi
bGUuICBUaGUgSWRsZSBibG9ja3MgbmVlZCB1c2luZyBpZgotICAgICAqIGVp
dGhlciB0aGUgUFYgb3IgSFZNIE1EUyBkZWZlbmNlcyBhcmUgdXNlZCwgb3Ig
aWYgd2UgbWF5IGdpdmUgTU1JTwotICAgICAqIGFjY2VzcyB0byB1bnRydXN0
ZWQgZ3Vlc3RzLgotICAgICAqCi0gICAgICogSFZNIGlzIG1vcmUgY29tcGxp
Y2F0ZWQuICBUaGUgTURfQ0xFQVIgbWljcm9jb2RlIGV4dGVuZHMgTDFEX0ZM
VVNIIHdpdGgKLSAgICAgKiBlcXVpdmFsZW50IHNlbWFudGljcyB0byBhdm9p
ZCBuZWVkaW5nIHRvIHBlcmZvcm0gYm90aCBmbHVzaGVzIG9uIHRoZQotICAg
ICAqIEhWTSBwYXRoLiAgVGhlcmVmb3JlLCB3ZSBkb24ndCBuZWVkIFZFUlcg
aW4gYWRkaXRpb24gdG8gTDFEX0ZMVVNIIChmb3IKLSAgICAgKiBNRFMgbWl0
aWdhdGlvbnMuICBMMURfRkxVU0ggaXMgbm90IHNhZmUgZm9yIE1NSU8gbWl0
aWdhdGlvbnMuKQotICAgICAqCi0gICAgICogQWZ0ZXIgY2FsY3VsYXRpbmcg
dGhlIGFwcHJvcHJpYXRlIGlkbGUgc2V0dGluZywgc2ltcGxpZnkKLSAgICAg
KiBvcHRfdmVyd19odm0gdG8gbWVhbiBqdXN0ICJzaG91bGQgd2UgVkVSVyBv
biB0aGUgd2F5IGludG8gSFZNCi0gICAgICogZ3Vlc3RzIiwgc28gc3BlY19j
dHJsX2luaXRfZG9tYWluKCkgY2FuIGNhbGN1bGF0ZSBzdWl0YWJsZSBzZXR0
aW5ncy4KKyAgICAgKiBJZiBTTVQgaXMgYWN0aXZlLCBhbmQgd2UncmUgcHJv
dGVjdGluZyBhZ2FpbnN0IE1EUyBvciBNTUlPIHN0YWxlIGRhdGEsCisgICAg
ICogd2UgbmVlZCB0byBzY3J1YiBiZWZvcmUgZ29pbmcgaWRsZSBhcyB3ZWxs
IGFzIG9uIHJldHVybiB0byBndWVzdC4KKyAgICAgKiBWYXJpb3VzIHBpcGVs
aW5lIHJlc291cmNlcyBhcmUgcmVwYXJ0aXRpb25lZCBhbW9uZ3N0IG5vbi1p
ZGxlIHRocmVhZHMuCiAgICAgICovCi0gICAgaWYgKCBvcHRfdmVyd19wdiB8
fCBvcHRfdmVyd19odm0gfHwgb3B0X3ZlcndfbW1pbyApCisgICAgaWYgKCAo
KGNwdV9oYXNfdXNlZnVsX21kX2NsZWFyICYmIChvcHRfdmVyd19wdiB8fCBv
cHRfdmVyd19odm0pKSB8fAorICAgICAgICAgIG9wdF92ZXJ3X21taW8pICYm
IGh3X3NtdF9lbmFibGVkICkKICAgICAgICAgc2V0dXBfZm9yY2VfY3B1X2Nh
cChYODZfRkVBVFVSRV9TQ19WRVJXX0lETEUpOwotICAgIG9wdF92ZXJ3X2h2
bSAmPSAhY3B1X2hhc19za2lwX2wxZGZsICYmICFvcHRfbDFkX2ZsdXNoOwor
CisgICAgLyoKKyAgICAgKiBBZnRlciBjYWxjdWxhdGluZyB0aGUgYXBwcm9w
cmlhdGUgaWRsZSBzZXR0aW5nLCBzaW1wbGlmeSBvcHRfdmVyd19odm0KKyAg
ICAgKiB0byBtZWFuIGp1c3QgInNob3VsZCB3ZSBWRVJXIG9uIHRoZSB3YXkg
aW50byBIVk0gZ3Vlc3RzIiwgc28KKyAgICAgKiBzcGVjX2N0cmxfaW5pdF9k
b21haW4oKSBjYW4gY2FsY3VsYXRlIHN1aXRhYmxlIHNldHRpbmdzLgorICAg
ICAqCisgICAgICogSXQgaXMgb25seSBzYWZlIHRvIHVzZSBMMURfRkxVU0gg
aW4gcGxhY2Ugb2YgVkVSVyB3aGVuIE1EX0NMRUFSIGlzIHRoZQorICAgICAq
IG9ubHkgKl9DTEVBUiB3ZSBjYW4gc2VlLgorICAgICAqLworICAgIGlmICgg
b3B0X2wxZF9mbHVzaCAmJiBjcHVfaGFzX21kX2NsZWFyICYmICFjcHVfaGFz
X2ZiX2NsZWFyICkKKyAgICAgICAgb3B0X3ZlcndfaHZtID0gZmFsc2U7CiAK
ICAgICAvKgogICAgICAqIFdhcm4gdGhlIHVzZXIgaWYgdGhleSBhcmUgb24g
TUxQRFMvTUZCRFMtdnVsbmVyYWJsZSBoYXJkd2FyZSB3aXRoIEhUCg==

--=separator
Content-Type: application/octet-stream; name="xsa452/xsa452-4.18-7.patch"
Content-Disposition: attachment; filename="xsa452/xsa452-4.18-7.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L3NwZWMtY3RybDogTWl0aWdhdGlvbiBSZWdpc3Rl
ciBGaWxlIERhdGEgU2FtcGxpbmcKClJGRFMgYWZmZWN0cyBBdG9tIGNvcmVz
LCBhbHNvIGJyYW5kZWQgRS1jb3JlcywgYmV0d2VlbiB0aGUgR29sZG1vbnQg
YW5kCkdyYWNlbW9udCBtaWNyb2FyY2hpdGVjdHVyZXMuICBUaGlzIGluY2x1
ZGVzIEFsZGVyIExha2UgYW5kIFJhcHRvciBMYWtlIGh5YnJpZApjbGllbiBz
eXN0ZW1zIHdoaWNoIGhhdmUgYSBtaXggb2YgR3JhY2Vtb250IGFuZCBvdGhl
ciB0eXBlcyBvZiBjb3Jlcy4KClR3byBuZXcgYml0cyBoYXZlIGJlZW4gZGVm
aW5lZDsgUkZEU19DTEVBUiB0byBpbmRpY2F0ZSBWRVJXIGhhcyBtb3JlIHNp
ZGUKZWZmZXRzLCBhbmQgUkZEU19OTyB0byBpbmNpZGF0ZSB0aGF0IHRoZSBz
eXN0ZW0gaXMgdW5hZmZlY3RlZC4gIFBsZW50eSBvZgp1bmFmZmVjdGVkIENQ
VXMgd29uJ3QgYmUgZ2V0dGluZyBSRkRTX05PIHJldHJvZml0dGVkIGluIG1p
Y3JvY29kZSwgc28gd2UKc3ludGhlc2lzZSBpdC4gIEFsZGVyIExha2UgYW5k
IFJhcHRvciBMYWtlIFhlb24tRSdzIGFyZSB1bmFmZmVjdGVkIGR1ZSB0bwp0
aGVpciBwbGF0Zm9ybSBjb25maWd1cmF0aW9uLCBhbmQgd2UgbXVzdCB1c2Ug
dGhlIEh5YnJpZCBDUFVJRCBiaXQgdG8KZGlzdGluZ3Vpc2ggdGhlbSBmcm9t
IHRoZWlyIG5vbi1YZW9uIGNvdW50ZXJwYXJ0cy4KCkxpa2UgTURfQ0xFQVIg
YW5kIEZCX0NMRUFSLCBSRkRTX0NMRUFSIG5lZWRzIE9SLWluZyBhY3Jvc3Mg
YSByZXNvdXJjZSBwb29sLCBzbwpzZXQgaXQgaW4gdGhlIG1heCBwb2xpY2ll
cyBhbmQgcmVmbGVjdCB0aGUgaG9zdCBzZXR0aW5nIGluIGRlZmF1bHQuCgpU
aGlzIGlzIHBhcnQgb2YgWFNBLTQ1MiAvIENWRS0yMDIzLTI4NzQ2LgoKU2ln
bmVkLW9mZi1ieTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0
cml4LmNvbT4KUmV2aWV3ZWQtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBz
dXNlLmNvbT4KKGNoZXJyeSBwaWNrZWQgZnJvbSBjb21taXQgZmI1YjZmNjc0
NDcxMzQxMGM3NGNmYzEyYjcxNzZjMTA4ZTNjOWEzMSkKCmRpZmYgLS1naXQg
YS90b29scy9taXNjL3hlbi1jcHVpZC5jIGIvdG9vbHMvbWlzYy94ZW4tY3B1
aWQuYwppbmRleCA3MzcwZjFiNTZlZjkuLjUyZTQ1MWE4MDZjMSAxMDA2NDQK
LS0tIGEvdG9vbHMvbWlzYy94ZW4tY3B1aWQuYworKysgYi90b29scy9taXNj
L3hlbi1jcHVpZC5jCkBAIC0xNzIsNyArMTcyLDcgQEAgc3RhdGljIGNvbnN0
IGNoYXIgKmNvbnN0IHN0cl83ZDBbMzJdID0KICAgICBbIDhdID0gImF2eDUx
Mi12cDJpbnRlcnNlY3QiLCBbIDldID0gInNyYmRzLWN0cmwiLAogICAgIFsx
MF0gPSAibWQtY2xlYXIiLCAgICAgICAgICAgIFsxMV0gPSAicnRtLWFsd2F5
cy1hYm9ydCIsCiAgICAgLyogMTIgKi8gICAgICAgICAgICAgICAgWzEzXSA9
ICJ0c3gtZm9yY2UtYWJvcnQiLAotICAgIFsxNF0gPSAic2VyaWFsaXplIiwK
KyAgICBbMTRdID0gInNlcmlhbGl6ZSIsICAgICBbMTVdID0gImh5YnJpZCIs
CiAgICAgWzE2XSA9ICJ0c3hsZHRyayIsCiAgICAgWzE4XSA9ICJwY29uZmln
IiwKICAgICBbMjBdID0gImNldC1pYnQiLApAQCAtMjQ1LDcgKzI0NSw4IEBA
IHN0YXRpYyBjb25zdCBjaGFyICpjb25zdCBzdHJfbTEwQWxbMzJdID0KICAg
ICBbMjBdID0gImJoaS1ubyIsICAgICAgICAgICAgICBbMjFdID0gInhhcGlj
LXN0YXR1cyIsCiAgICAgLyogMjIgKi8gICAgICAgICAgICAgICAgICAgICAg
WzIzXSA9ICJvdnJjbGstc3RhdHVzIiwKICAgICBbMjRdID0gInBicnNiLW5v
IiwgICAgICAgICAgICBbMjVdID0gImdkcy1jdHJsIiwKLSAgICBbMjZdID0g
Imdkcy1ubyIsCisgICAgWzI2XSA9ICJnZHMtbm8iLCAgICAgICAgICAgICAg
WzI3XSA9ICJyZmRzLW5vIiwKKyAgICBbMjhdID0gInJmZHMtY2xlYXIiLAog
fTsKIAogc3RhdGljIGNvbnN0IGNoYXIgKmNvbnN0IHN0cl9tMTBBaFszMl0g
PQpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2NwdS1wb2xpY3kuYyBiL3hl
bi9hcmNoL3g4Ni9jcHUtcG9saWN5LmMKaW5kZXggYzdjNWU5OWI3YjRjLi4x
MmU2MjFiOTdkZTYgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9jcHUtcG9s
aWN5LmMKKysrIGIveGVuL2FyY2gveDg2L2NwdS1wb2xpY3kuYwpAQCAtNDUx
LDYgKzQ1MSw3IEBAIHN0YXRpYyB2b2lkIF9faW5pdCBndWVzdF9jb21tb25f
bWF4X2ZlYXR1cmVfYWRqdXN0bWVudHModWludDMyX3QgKmZzKQogICAgICAg
ICAgKi8KICAgICAgICAgX19zZXRfYml0KFg4Nl9GRUFUVVJFX01EX0NMRUFS
LCBmcyk7CiAgICAgICAgIF9fc2V0X2JpdChYODZfRkVBVFVSRV9GQl9DTEVB
UiwgZnMpOworICAgICAgICBfX3NldF9iaXQoWDg2X0ZFQVRVUkVfUkZEU19D
TEVBUiwgZnMpOwogCiAgICAgICAgIC8qCiAgICAgICAgICAqIFRoZSBHYXRo
ZXIgRGF0YSBTYW1wbGluZyBtaWNyb2NvZGUgbWl0aWdhdGlvbiAoQXVndXN0
IDIwMjMpIGhhcyBhbgpAQCAtNTAwLDYgKzUwMSwxMCBAQCBzdGF0aWMgdm9p
ZCBfX2luaXQgZ3Vlc3RfY29tbW9uX2RlZmF1bHRfZmVhdHVyZV9hZGp1c3Rt
ZW50cyh1aW50MzJfdCAqZnMpCiAgICAgICAgIGlmICggY3B1X2hhc19mYl9j
bGVhciApCiAgICAgICAgICAgICBfX3NldF9iaXQoWDg2X0ZFQVRVUkVfRkJf
Q0xFQVIsIGZzKTsKIAorICAgICAgICBfX2NsZWFyX2JpdChYODZfRkVBVFVS
RV9SRkRTX0NMRUFSLCBmcyk7CisgICAgICAgIGlmICggY3B1X2hhc19yZmRz
X2NsZWFyICkKKyAgICAgICAgICAgIF9fc2V0X2JpdChYODZfRkVBVFVSRV9S
RkRTX0NMRUFSLCBmcyk7CisKICAgICAgICAgLyoKICAgICAgICAgICogVGhl
IEdhdGhlciBEYXRhIFNhbXBsaW5nIG1pY3JvY29kZSBtaXRpZ2F0aW9uIChB
dWd1c3QgMjAyMykgaGFzIGFuCiAgICAgICAgICAqIGFkdmVyc2UgcGVyZm9y
bWFuY2UgaW1wYWN0IG9uIHRoZSBDTFdCIGluc3RydWN0aW9uIG9uIFNLWC9D
TFgvQ1BYLgpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNt
L2NwdWZlYXR1cmUuaCBiL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9jcHVm
ZWF0dXJlLmgKaW5kZXggNzZlZjJhZWIxZGU2Li4zYzU3ZjU1ZGUwNzUgMTAw
NjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9jcHVmZWF0dXJl
LmgKKysrIGIveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2NwdWZlYXR1cmUu
aApAQCAtMTgxLDYgKzE4MSw3IEBAIHN0YXRpYyBpbmxpbmUgYm9vbCBib290
X2NwdV9oYXModW5zaWduZWQgaW50IGZlYXQpCiAjZGVmaW5lIGNwdV9oYXNf
cnRtX2Fsd2F5c19hYm9ydCBib290X2NwdV9oYXMoWDg2X0ZFQVRVUkVfUlRN
X0FMV0FZU19BQk9SVCkKICNkZWZpbmUgY3B1X2hhc190c3hfZm9yY2VfYWJv
cnQgYm9vdF9jcHVfaGFzKFg4Nl9GRUFUVVJFX1RTWF9GT1JDRV9BQk9SVCkK
ICNkZWZpbmUgY3B1X2hhc19zZXJpYWxpemUgICAgICAgYm9vdF9jcHVfaGFz
KFg4Nl9GRUFUVVJFX1NFUklBTElaRSkKKyNkZWZpbmUgY3B1X2hhc19oeWJy
aWQgICAgICAgICAgYm9vdF9jcHVfaGFzKFg4Nl9GRUFUVVJFX0hZQlJJRCkK
ICNkZWZpbmUgY3B1X2hhc19hdng1MTJfZnAxNiAgICAgYm9vdF9jcHVfaGFz
KFg4Nl9GRUFUVVJFX0FWWDUxMl9GUDE2KQogI2RlZmluZSBjcHVfaGFzX2Fy
Y2hfY2FwcyAgICAgICBib290X2NwdV9oYXMoWDg2X0ZFQVRVUkVfQVJDSF9D
QVBTKQogCkBAIC0yMDgsNiArMjA5LDggQEAgc3RhdGljIGlubGluZSBib29s
IGJvb3RfY3B1X2hhcyh1bnNpZ25lZCBpbnQgZmVhdCkKICNkZWZpbmUgY3B1
X2hhc19ycnNiYSAgICAgICAgICAgYm9vdF9jcHVfaGFzKFg4Nl9GRUFUVVJF
X1JSU0JBKQogI2RlZmluZSBjcHVfaGFzX2dkc19jdHJsICAgICAgICBib290
X2NwdV9oYXMoWDg2X0ZFQVRVUkVfR0RTX0NUUkwpCiAjZGVmaW5lIGNwdV9o
YXNfZ2RzX25vICAgICAgICAgIGJvb3RfY3B1X2hhcyhYODZfRkVBVFVSRV9H
RFNfTk8pCisjZGVmaW5lIGNwdV9oYXNfcmZkc19ubyAgICAgICAgIGJvb3Rf
Y3B1X2hhcyhYODZfRkVBVFVSRV9SRkRTX05PKQorI2RlZmluZSBjcHVfaGFz
X3JmZHNfY2xlYXIgICAgICBib290X2NwdV9oYXMoWDg2X0ZFQVRVUkVfUkZE
U19DTEVBUikKIAogLyogU3ludGhlc2l6ZWQuICovCiAjZGVmaW5lIGNwdV9o
YXNfYXJjaF9wZXJmbW9uICAgIGJvb3RfY3B1X2hhcyhYODZfRkVBVFVSRV9B
UkNIX1BFUkZNT04pCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYvaW5jbHVk
ZS9hc20vbXNyLWluZGV4LmggYi94ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20v
bXNyLWluZGV4LmgKaW5kZXggODJhODFiZDBhMjMyLi44NWVmMjhhNjEyZTAg
MTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9tc3ItaW5k
ZXguaAorKysgYi94ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vbXNyLWluZGV4
LmgKQEAgLTg5LDYgKzg5LDggQEAKICNkZWZpbmUgIEFSQ0hfQ0FQU19QQlJT
Ql9OTyAgICAgICAgICAgICAgICAgKF9BQygxLCBVTEwpIDw8IDI0KQogI2Rl
ZmluZSAgQVJDSF9DQVBTX0dEU19DVFJMICAgICAgICAgICAgICAgICAoX0FD
KDEsIFVMTCkgPDwgMjUpCiAjZGVmaW5lICBBUkNIX0NBUFNfR0RTX05PICAg
ICAgICAgICAgICAgICAgIChfQUMoMSwgVUxMKSA8PCAyNikKKyNkZWZpbmUg
IEFSQ0hfQ0FQU19SRkRTX05PICAgICAgICAgICAgICAgICAgKF9BQygxLCBV
TEwpIDw8IDI3KQorI2RlZmluZSAgQVJDSF9DQVBTX1JGRFNfQ0xFQVIgICAg
ICAgICAgICAgICAoX0FDKDEsIFVMTCkgPDwgMjgpCiAKICNkZWZpbmUgTVNS
X0ZMVVNIX0NNRCAgICAgICAgICAgICAgICAgICAgICAgMHgwMDAwMDEwYgog
I2RlZmluZSAgRkxVU0hfQ01EX0wxRCAgICAgICAgICAgICAgICAgICAgICAo
X0FDKDEsIFVMTCkgPDwgIDApCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYv
c3BlY19jdHJsLmMgYi94ZW4vYXJjaC94ODYvc3BlY19jdHJsLmMKaW5kZXgg
YTRhZmNkODU3MGUyLi44MTY1Mzc5ZmVkOTQgMTAwNjQ0Ci0tLSBhL3hlbi9h
cmNoL3g4Ni9zcGVjX2N0cmwuYworKysgYi94ZW4vYXJjaC94ODYvc3BlY19j
dHJsLmMKQEAgLTEyLDYgKzEyLDcgQEAKIAogI2luY2x1ZGUgPGFzbS9hbWQu
aD4KICNpbmNsdWRlIDxhc20vaHZtL3N2bS9zdm0uaD4KKyNpbmNsdWRlIDxh
c20vaW50ZWwtZmFtaWx5Lmg+CiAjaW5jbHVkZSA8YXNtL21pY3JvY29kZS5o
PgogI2luY2x1ZGUgPGFzbS9tc3IuaD4KICNpbmNsdWRlIDxhc20vcHYvZG9t
YWluLmg+CkBAIC00MzUsNyArNDM2LDcgQEAgc3RhdGljIHZvaWQgX19pbml0
IHByaW50X2RldGFpbHMoZW51bSBpbmRfdGh1bmsgdGh1bmspCiAgICAgICog
SGFyZHdhcmUgcmVhZC1vbmx5IGluZm9ybWF0aW9uLCBzdGF0aW5nIGltbXVu
aXR5IHRvIGNlcnRhaW4gaXNzdWVzLCBvcgogICAgICAqIHN1Z2dlc3Rpb25z
IG9mIHdoaWNoIG1pdGlnYXRpb24gdG8gdXNlLgogICAgICAqLwotICAgIHBy
aW50aygiICBIYXJkd2FyZSBoaW50czolcyVzJXMlcyVzJXMlcyVzJXMlcyVz
JXMlcyVzJXMlcyVzJXMlcyVzJXMlc1xuIiwKKyAgICBwcmludGsoIiAgSGFy
ZHdhcmUgaGludHM6JXMlcyVzJXMlcyVzJXMlcyVzJXMlcyVzJXMlcyVzJXMl
cyVzJXMlcyVzJXMlc1xuIiwKICAgICAgICAgICAgKGNhcHMgJiBBUkNIX0NB
UFNfUkRDTF9OTykgICAgICAgICAgICAgICAgICAgICAgICA/ICIgUkRDTF9O
TyIgICAgICAgIDogIiIsCiAgICAgICAgICAgIChjYXBzICYgQVJDSF9DQVBT
X0VJQlJTKSAgICAgICAgICAgICAgICAgICAgICAgICAgPyAiIEVJQlJTIiAg
ICAgICAgICA6ICIiLAogICAgICAgICAgICAoY2FwcyAmIEFSQ0hfQ0FQU19S
U0JBKSAgICAgICAgICAgICAgICAgICAgICAgICAgID8gIiBSU0JBIiAgICAg
ICAgICAgOiAiIiwKQEAgLTQ1MSw2ICs0NTIsNyBAQCBzdGF0aWMgdm9pZCBf
X2luaXQgcHJpbnRfZGV0YWlscyhlbnVtIGluZF90aHVuayB0aHVuaykKICAg
ICAgICAgICAgKGNhcHMgJiBBUkNIX0NBUFNfRkJfQ0xFQVIpICAgICAgICAg
ICAgICAgICAgICAgICA/ICIgRkJfQ0xFQVIiICAgICAgIDogIiIsCiAgICAg
ICAgICAgIChjYXBzICYgQVJDSF9DQVBTX1BCUlNCX05PKSAgICAgICAgICAg
ICAgICAgICAgICAgPyAiIFBCUlNCX05PIiAgICAgICA6ICIiLAogICAgICAg
ICAgICAoY2FwcyAmIEFSQ0hfQ0FQU19HRFNfTk8pICAgICAgICAgICAgICAg
ICAgICAgICAgID8gIiBHRFNfTk8iICAgICAgICAgOiAiIiwKKyAgICAgICAg
ICAgKGNhcHMgJiBBUkNIX0NBUFNfUkZEU19OTykgICAgICAgICAgICAgICAg
ICAgICAgICA/ICIgUkZEU19OTyIgICAgICAgIDogIiIsCiAgICAgICAgICAg
IChlOGIgICYgY3B1ZmVhdF9tYXNrKFg4Nl9GRUFUVVJFX0lCUlNfQUxXQVlT
KSkgICAgPyAiIElCUlNfQUxXQVlTIiAgICA6ICIiLAogICAgICAgICAgICAo
ZThiICAmIGNwdWZlYXRfbWFzayhYODZfRkVBVFVSRV9TVElCUF9BTFdBWVMp
KSAgID8gIiBTVElCUF9BTFdBWVMiICAgOiAiIiwKICAgICAgICAgICAgKGU4
YiAgJiBjcHVmZWF0X21hc2soWDg2X0ZFQVRVUkVfSUJSU19GQVNUKSkgICAg
ICA/ICIgSUJSU19GQVNUIiAgICAgIDogIiIsCkBAIC00NjEsNyArNDYzLDcg
QEAgc3RhdGljIHZvaWQgX19pbml0IHByaW50X2RldGFpbHMoZW51bSBpbmRf
dGh1bmsgdGh1bmspCiAgICAgICAgICAgIChlMjFhICYgY3B1ZmVhdF9tYXNr
KFg4Nl9GRUFUVVJFX1NSU09fTk8pKSAgICAgICAgPyAiIFNSU09fTk8iICAg
ICAgICA6ICIiKTsKIAogICAgIC8qIEhhcmR3YXJlIGZlYXR1cmVzIHdoaWNo
IG5lZWQgZHJpdmluZyB0byBtaXRpZ2F0ZSBpc3N1ZXMuICovCi0gICAgcHJp
bnRrKCIgIEhhcmR3YXJlIGZlYXR1cmVzOiVzJXMlcyVzJXMlcyVzJXMlcyVz
JXMlcyVzXG4iLAorICAgIHByaW50aygiICBIYXJkd2FyZSBmZWF0dXJlczol
cyVzJXMlcyVzJXMlcyVzJXMlcyVzJXMlcyVzXG4iLAogICAgICAgICAgICAo
ZThiICAmIGNwdWZlYXRfbWFzayhYODZfRkVBVFVSRV9JQlBCKSkgfHwKICAg
ICAgICAgICAgKF83ZDAgJiBjcHVmZWF0X21hc2soWDg2X0ZFQVRVUkVfSUJS
U0IpKSAgICAgICAgICA/ICIgSUJQQiIgICAgICAgICAgIDogIiIsCiAgICAg
ICAgICAgIChlOGIgICYgY3B1ZmVhdF9tYXNrKFg4Nl9GRUFUVVJFX0lCUlMp
KSB8fApAQCAtNDc5LDYgKzQ4MSw3IEBAIHN0YXRpYyB2b2lkIF9faW5pdCBw
cmludF9kZXRhaWxzKGVudW0gaW5kX3RodW5rIHRodW5rKQogICAgICAgICAg
ICAoY2FwcyAmIEFSQ0hfQ0FQU19UU1hfQ1RSTCkgICAgICAgICAgICAgICAg
ICAgICAgID8gIiBUU1hfQ1RSTCIgICAgICAgOiAiIiwKICAgICAgICAgICAg
KGNhcHMgJiBBUkNIX0NBUFNfRkJfQ0xFQVJfQ1RSTCkgICAgICAgICAgICAg
ICAgICA/ICIgRkJfQ0xFQVJfQ1RSTCIgIDogIiIsCiAgICAgICAgICAgIChj
YXBzICYgQVJDSF9DQVBTX0dEU19DVFJMKSAgICAgICAgICAgICAgICAgICAg
ICAgPyAiIEdEU19DVFJMIiAgICAgICA6ICIiLAorICAgICAgICAgICAoY2Fw
cyAmIEFSQ0hfQ0FQU19SRkRTX0NMRUFSKSAgICAgICAgICAgICAgICAgICAg
ID8gIiBSRkRTX0NMRUFSIiAgICAgOiAiIiwKICAgICAgICAgICAgKGUyMWEg
JiBjcHVmZWF0X21hc2soWDg2X0ZFQVRVUkVfU0JQQikpICAgICAgICAgICA/
ICIgU0JQQiIgICAgICAgICAgIDogIiIpOwogCiAgICAgLyogQ29tcGlsZWQt
aW4gc3VwcG9ydCB3aGljaCBwZXJ0YWlucyB0byBtaXRpZ2F0aW9ucy4gKi8K
QEAgLTEzNDcsNiArMTM1MCw4MyBAQCBzdGF0aWMgX19pbml0IHZvaWQgbWRz
X2NhbGN1bGF0aW9ucyh2b2lkKQogICAgIH0KIH0KIAorLyoKKyAqIFJlZ2lz
dGVyIEZpbGUgRGF0YSBTYW1wbGluZyBhZmZlY3RzIEF0b20gY29yZXMgZnJv
bSB0aGUgR29sZG1vbnQgdG8KKyAqIEdyYWNlbW9udCBtaWNyb2FyY2hpdGVj
dHVyZXMuICBUaGUgTWFyY2ggMjAyNCBtaWNyb2NvZGUgYWRkcyBSRkRTX05P
IHRvCisgKiBzb21lIGJ1dCBub3QgYWxsIHVuYWZmZWN0ZWQgcGFydHMsIGFu
ZCBSRkRTX0NMRUFSIHRvIGFmZmVjdGVkIHBhcnRzIHN0aWxsCisgKiBpbiBz
dXBwb3J0LgorICoKKyAqIEFsZGVyIExha2UgYW5kIFJhcHRvciBMYWtlIGNs
aWVudCBDUFVzIGhhdmUgYSBtaXggb2YgUCBjb3JlcworICogKEdvbGRlbi9S
YXB0b3IgQ292ZSwgbm90IHZ1bG5lcmFibGUpIGFuZCBFIGNvcmVzIChHcmFj
ZW1vbnQsCisgKiB2dWxuZXJhYmxlKSwgYW5kIGJvdGggZW51bWVyYXRlIFJG
RFNfQ0xFQVIuCisgKgorICogQm90aCBleGlzdCBpbiBhIFhlb24gU0tVLCB3
aGljaCBoYXMgdGhlIEUgY29yZXMgKEdyYWNlbW9udCkgZGlzYWJsZWQgYnkK
KyAqIHBsYXRmb3JtIGNvbmZpZ3VyYXRpb24sIGFuZCBlbnVtZXJhdGUgUkZE
U19OTy4KKyAqCisgKiBXaXRoIG9sZGVyIHBhcnRzLCBvciB3aXRoIG91dC1v
Zi1kYXRlIG1pY3JvY29kZSwgc3ludGhlc2lzZSBSRkRTX05PIHdoZW4KKyAq
IHNhZmUgdG8gZG8gc28uCisgKgorICogaHR0cHM6Ly93d3cuaW50ZWwuY29t
L2NvbnRlbnQvd3d3L3VzL2VuL2RldmVsb3Blci9hcnRpY2xlcy90ZWNobmlj
YWwvc29mdHdhcmUtc2VjdXJpdHktZ3VpZGFuY2UvYWR2aXNvcnktZ3VpZGFu
Y2UvcmVnaXN0ZXItZmlsZS1kYXRhLXNhbXBsaW5nLmh0bWwKKyAqLworc3Rh
dGljIHZvaWQgX19pbml0IHJmZHNfY2FsY3VsYXRpb25zKHZvaWQpCit7Cisg
ICAgLyogUkZEUyBpcyBvbmx5IGtub3duIHRvIGFmZmVjdCBJbnRlbCBGYW1p
bHkgNiBwcm9jZXNzb3JzIGF0IHRoaXMgdGltZS4gKi8KKyAgICBpZiAoIGJv
b3RfY3B1X2RhdGEueDg2X3ZlbmRvciAhPSBYODZfVkVORE9SX0lOVEVMIHx8
CisgICAgICAgICBib290X2NwdV9kYXRhLng4NiAhPSA2ICkKKyAgICAgICAg
cmV0dXJuOworCisgICAgLyoKKyAgICAgKiBJZiBSRkRTX05PIG9yIFJGRFNf
Q0xFQVIgYXJlIHZpc2libGUsIHdlJ3ZlIGVpdGhlciBnb3Qgc3VpdGFibGUK
KyAgICAgKiBtaWNyb2NvZGUsIG9yIGFuIFJGRFMtYXdhcmUgaHlwZXJ2aXNv
ciBpcyBsZXZlbGxpbmcgdXMgaW4gYSBwb29sLgorICAgICAqLworICAgIGlm
ICggY3B1X2hhc19yZmRzX25vIHx8IGNwdV9oYXNfcmZkc19jbGVhciApCisg
ICAgICAgIHJldHVybjsKKworICAgIC8qIElmIHdlJ3JlIHZpcnR1YWxpc2Vk
LCBkb24ndCBhdHRlbXB0IHRvIHN5bnRoZXNpc2UgUkZEU19OTy4gKi8KKyAg
ICBpZiAoIGNwdV9oYXNfaHlwZXJ2aXNvciApCisgICAgICAgIHJldHVybjsK
KworICAgIC8qCisgICAgICogTm90IGFsbCBDUFVzIGFyZSBleHBlY3RlZCB0
byBnZXQgYSBtaWNyb2NvZGUgdXBkYXRlIGVudW1lcmF0aW5nIG9uZSBvZgor
ICAgICAqIFJGRFNfe05PLENMRUFSfSwgb3Igd2UgbWlnaHQgaGF2ZSBvdXQt
b2YtZGF0ZSBtaWNyb2NvZGUuCisgICAgICovCisgICAgc3dpdGNoICggYm9v
dF9jcHVfZGF0YS54ODZfbW9kZWwgKQorICAgIHsKKyAgICBjYXNlIElOVEVM
X0ZBTTZfQUxERVJMQUtFOgorICAgIGNhc2UgSU5URUxfRkFNNl9SQVBUT1JM
QUtFOgorICAgICAgICAvKgorICAgICAgICAgKiBBbGRlciBMYWtlIGFuZCBS
YXB0b3IgTGFrZSBtaWdodCBiZSBhIGNsaWVudCBTS1UgKHdpdGggdGhlCisg
ICAgICAgICAqIEdyYWNlbW9udCBjb3JlcyBhY3RpdmUsIGFuZCB0aGVyZWZv
cmUgdnVsbmVyYWJsZSkgb3IgbWlnaHQgYmUgYQorICAgICAgICAgKiBzZXJ2
ZXIgU0tVICh3aXRoIHRoZSBHcmFjZW1vbnQgY29yZXMgZGlzYWJsZWQsIGFu
ZCB0aGVyZWZvcmUgbm90CisgICAgICAgICAqIHZ1bG5lcmFibGUpLgorICAg
ICAgICAgKgorICAgICAgICAgKiBTZWUgaWYgdGhlIENQVSBpZGVudGlmaWVz
IGFzIGh5YnJpZCB0byBkaXN0aW5ndWlzaCB0aGUgdHdvIGNhc2VzLgorICAg
ICAgICAgKi8KKyAgICAgICAgaWYgKCAhY3B1X2hhc19oeWJyaWQgKQorICAg
ICAgICAgICAgYnJlYWs7CisgICAgICAgIGZhbGx0aHJvdWdoOworICAgIGNh
c2UgSU5URUxfRkFNNl9BTERFUkxBS0VfTDoKKyAgICBjYXNlIElOVEVMX0ZB
TTZfUkFQVE9STEFLRV9QOgorICAgIGNhc2UgSU5URUxfRkFNNl9SQVBUT1JM
QUtFX1M6CisKKyAgICBjYXNlIElOVEVMX0ZBTTZfQVRPTV9HT0xETU9OVDog
ICAgICAvKiBBcG9sbG8gTGFrZSAqLworICAgIGNhc2UgSU5URUxfRkFNNl9B
VE9NX0dPTERNT05UX0Q6ICAgIC8qIERlbnZlcnRvbiAqLworICAgIGNhc2Ug
SU5URUxfRkFNNl9BVE9NX0dPTERNT05UX1BMVVM6IC8qIEdlbWluaSBMYWtl
ICovCisgICAgY2FzZSBJTlRFTF9GQU02X0FUT01fVFJFTU9OVF9EOiAgICAg
LyogU25vdyBSaWRnZSAvIFBhcmtlciBSaWRnZSAqLworICAgIGNhc2UgSU5U
RUxfRkFNNl9BVE9NX1RSRU1PTlQ6ICAgICAgIC8qIEVsa2hhcnQgTGFrZSAq
LworICAgIGNhc2UgSU5URUxfRkFNNl9BVE9NX1RSRU1PTlRfTDogICAgIC8q
IEphc3BlciBMYWtlICovCisgICAgY2FzZSBJTlRFTF9GQU02X0FUT01fR1JB
Q0VNT05UOiAgICAgLyogQWxkZXIgTGFrZSBOICovCisgICAgICAgIHJldHVy
bjsKKyAgICB9CisKKyAgICAvKgorICAgICAqIFdlIGFwcGVhciB0byBiZSBv
biBhbiB1bmFmZmVjdGVkIENQVSB3aGljaCBkaWRuJ3QgZW51bWVyYXRlIFJG
RFNfTk8sCisgICAgICogcGVyaGFwcyBiZWNhdXNlIG9mIGl0J3MgYWdlIG9y
IGJlY2F1c2Ugb2Ygb3V0LW9mLWRhdGUgbWljcm9jb2RlLgorICAgICAqIFN5
bnRoZXNpc2UgaXQuCisgICAgICovCisgICAgc2V0dXBfZm9yY2VfY3B1X2Nh
cChYODZfRkVBVFVSRV9SRkRTX05PKTsKK30KKwogc3RhdGljIGJvb2wgX19p
bml0IGNwdV9oYXNfZ2RzKHZvaWQpCiB7CiAgICAgLyoKQEAgLTE4NjAsNiAr
MTk0MCw3IEBAIHZvaWQgX19pbml0IGluaXRfc3BlY3VsYXRpb25fbWl0aWdh
dGlvbnModm9pZCkKICAgICAgKgogICAgICAqIGh0dHBzOi8vd3d3LmludGVs
LmNvbS9jb250ZW50L3d3dy91cy9lbi9kZXZlbG9wZXIvYXJ0aWNsZXMvdGVj
aG5pY2FsL3NvZnR3YXJlLXNlY3VyaXR5LWd1aWRhbmNlL3RlY2huaWNhbC1k
b2N1bWVudGF0aW9uL2ludGVsLWFuYWx5c2lzLW1pY3JvYXJjaGl0ZWN0dXJh
bC1kYXRhLXNhbXBsaW5nLmh0bWwKICAgICAgKiBodHRwczovL3d3dy5pbnRl
bC5jb20vY29udGVudC93d3cvdXMvZW4vZGV2ZWxvcGVyL2FydGljbGVzL3Rl
Y2huaWNhbC9zb2Z0d2FyZS1zZWN1cml0eS1ndWlkYW5jZS90ZWNobmljYWwt
ZG9jdW1lbnRhdGlvbi9wcm9jZXNzb3ItbW1pby1zdGFsZS1kYXRhLXZ1bG5l
cmFiaWxpdGllcy5odG1sCisgICAgICogaHR0cHM6Ly93d3cuaW50ZWwuY29t
L2NvbnRlbnQvd3d3L3VzL2VuL2RldmVsb3Blci9hcnRpY2xlcy90ZWNobmlj
YWwvc29mdHdhcmUtc2VjdXJpdHktZ3VpZGFuY2UvYWR2aXNvcnktZ3VpZGFu
Y2UvcmVnaXN0ZXItZmlsZS1kYXRhLXNhbXBsaW5nLmh0bWwKICAgICAgKgog
ICAgICAqIFJlbGV2YW50IHVjb2RlczoKICAgICAgKgpAQCAtMTg4OSw4ICsx
OTcwLDEyIEBAIHZvaWQgX19pbml0IGluaXRfc3BlY3VsYXRpb25fbWl0aWdh
dGlvbnModm9pZCkKICAgICAgKgogICAgICAqICAgSWYgRkJfQ0xFQVIgaXMg
ZW51bWVyYXRlZCwgTDFEX0ZMVVNIIGRvZXMgbm90IGhhdmUgdGhlIHNhbWUg
c2NydWJiaW5nCiAgICAgICogICBzaWRlIGVmZmVjdHMgYXMgVkVSVyBhbmQg
Y2Fubm90IGJlIHVzZWQgaW4gaXRzIHBsYWNlLgorICAgICAqCisgICAgICog
LSBNYXJjaCAyMDIzLCBmb3IgUkZEUy4gIEVudW1lcmF0ZSBSRkRTX0NMRUFS
IHRvIG1lYW4gdGhhdCBWRVJXIG5vdworICAgICAqICAgc2NydWJzIG5vbi1h
cmNoaXRlY3R1cmFsIGVudHJpZXMgZnJvbSBjZXJ0YWluIHJlZ2lzdGVyIGZp
bGVzLgogICAgICAqLwogICAgIG1kc19jYWxjdWxhdGlvbnMoKTsKKyAgICBy
ZmRzX2NhbGN1bGF0aW9ucygpOwogCiAgICAgLyoKICAgICAgKiBQYXJ0cyB3
aGljaCBlbnVtZXJhdGUgRkJfQ0xFQVIgYXJlIHRob3NlIHdpdGggbm93LXVw
ZGF0ZWQgbWljcm9jb2RlCkBAIC0xOTIyLDE1ICsyMDA3LDE5IEBAIHZvaWQg
X19pbml0IGluaXRfc3BlY3VsYXRpb25fbWl0aWdhdGlvbnModm9pZCkKICAg
ICAgKiBNTFBEUy9NRkJEUyB3aGVuIFNNVCBpcyBlbmFibGVkLgogICAgICAq
LwogICAgIGlmICggb3B0X3ZlcndfcHYgPT0gLTEgKQotICAgICAgICBvcHRf
dmVyd19wdiA9IGNwdV9oYXNfdXNlZnVsX21kX2NsZWFyOworICAgICAgICBv
cHRfdmVyd19wdiA9IGNwdV9oYXNfdXNlZnVsX21kX2NsZWFyIHx8IGNwdV9o
YXNfcmZkc19jbGVhcjsKIAogICAgIGlmICggb3B0X3ZlcndfaHZtID09IC0x
ICkKLSAgICAgICAgb3B0X3ZlcndfaHZtID0gY3B1X2hhc191c2VmdWxfbWRf
Y2xlYXI7CisgICAgICAgIG9wdF92ZXJ3X2h2bSA9IGNwdV9oYXNfdXNlZnVs
X21kX2NsZWFyIHx8IGNwdV9oYXNfcmZkc19jbGVhcjsKIAogICAgIC8qCiAg
ICAgICogSWYgU01UIGlzIGFjdGl2ZSwgYW5kIHdlJ3JlIHByb3RlY3Rpbmcg
YWdhaW5zdCBNRFMgb3IgTU1JTyBzdGFsZSBkYXRhLAogICAgICAqIHdlIG5l
ZWQgdG8gc2NydWIgYmVmb3JlIGdvaW5nIGlkbGUgYXMgd2VsbCBhcyBvbiBy
ZXR1cm4gdG8gZ3Vlc3QuCiAgICAgICogVmFyaW91cyBwaXBlbGluZSByZXNv
dXJjZXMgYXJlIHJlcGFydGl0aW9uZWQgYW1vbmdzdCBub24taWRsZSB0aHJl
YWRzLgorICAgICAqCisgICAgICogV2UgZG9uJ3QgbmVlZCB0byBzY3J1YiBv
biBpZGxlIGZvciBSRkRTLiAgVGhlcmUgYXJlIG5vIGFmZmVjdGVkIGNvcmVz
CisgICAgICogd2hpY2ggc3VwcG9ydCBTTVQsIGRlc3BpdGUgdGhlcmUgYmVp
bmcgYWZmZWN0ZWQgY29yZXMgaW4gaHlicmlkIHN5c3RlbXMKKyAgICAgKiB3
aGljaCBoYXZlIFNNVCBlbHNld2hlcmUgaW4gdGhlIHBsYXRmb3JtLgogICAg
ICAqLwogICAgIGlmICggKChjcHVfaGFzX3VzZWZ1bF9tZF9jbGVhciAmJiAo
b3B0X3ZlcndfcHYgfHwgb3B0X3ZlcndfaHZtKSkgfHwKICAgICAgICAgICBv
cHRfdmVyd19tbWlvKSAmJiBod19zbXRfZW5hYmxlZCApCkBAIC0xOTQ0LDcg
KzIwMzMsOCBAQCB2b2lkIF9faW5pdCBpbml0X3NwZWN1bGF0aW9uX21pdGln
YXRpb25zKHZvaWQpCiAgICAgICogSXQgaXMgb25seSBzYWZlIHRvIHVzZSBM
MURfRkxVU0ggaW4gcGxhY2Ugb2YgVkVSVyB3aGVuIE1EX0NMRUFSIGlzIHRo
ZQogICAgICAqIG9ubHkgKl9DTEVBUiB3ZSBjYW4gc2VlLgogICAgICAqLwot
ICAgIGlmICggb3B0X2wxZF9mbHVzaCAmJiBjcHVfaGFzX21kX2NsZWFyICYm
ICFjcHVfaGFzX2ZiX2NsZWFyICkKKyAgICBpZiAoIG9wdF9sMWRfZmx1c2gg
JiYgY3B1X2hhc19tZF9jbGVhciAmJiAhY3B1X2hhc19mYl9jbGVhciAmJgor
ICAgICAgICAgIWNwdV9oYXNfcmZkc19jbGVhciApCiAgICAgICAgIG9wdF92
ZXJ3X2h2bSA9IGZhbHNlOwogCiAgICAgLyoKZGlmZiAtLWdpdCBhL3hlbi9p
bmNsdWRlL3B1YmxpYy9hcmNoLXg4Ni9jcHVmZWF0dXJlc2V0LmggYi94ZW4v
aW5jbHVkZS9wdWJsaWMvYXJjaC14ODYvY3B1ZmVhdHVyZXNldC5oCmluZGV4
IDMzN2FhYTljNzcwYi4uOGUxN2VmNjcwZmZmIDEwMDY0NAotLS0gYS94ZW4v
aW5jbHVkZS9wdWJsaWMvYXJjaC14ODYvY3B1ZmVhdHVyZXNldC5oCisrKyBi
L3hlbi9pbmNsdWRlL3B1YmxpYy9hcmNoLXg4Ni9jcHVmZWF0dXJlc2V0LmgK
QEAgLTI2Niw2ICsyNjYsNyBAQCBYRU5fQ1BVRkVBVFVSRShNRF9DTEVBUiwg
ICAgICA5KjMyKzEwKSAvKiFBIFZFUlcgY2xlYXJzIG1pY3JvYXJjaGl0ZWN0
dXJhbCBidWZmZQogWEVOX0NQVUZFQVRVUkUoUlRNX0FMV0FZU19BQk9SVCwg
OSozMisxMSkgLyohIEp1bmUgMjAyMSBUU1ggZGVmZWF0dXJpbmcgaW4gbWlj
cm9jb2RlLiAqLwogWEVOX0NQVUZFQVRVUkUoVFNYX0ZPUkNFX0FCT1JULCA5
KjMyKzEzKSAvKiBNU1JfVFNYX0ZPUkNFX0FCT1JULlJUTV9BQk9SVCAqLwog
WEVOX0NQVUZFQVRVUkUoU0VSSUFMSVpFLCAgICAgOSozMisxNCkgLypBICBT
RVJJQUxJWkUgaW5zbiAqLworWEVOX0NQVUZFQVRVUkUoSFlCUklELCAgICAg
ICAgOSozMisxNSkgLyogICBIZXRlcm9nZW5lb3VzIHBsYXRmb3JtICovCiBY
RU5fQ1BVRkVBVFVSRShUU1hMRFRSSywgICAgICA5KjMyKzE2KSAvKmEgIFRT
WCBsb2FkIHRyYWNraW5nIHN1c3BlbmQvcmVzdW1lIGluc25zICovCiBYRU5f
Q1BVRkVBVFVSRShDRVRfSUJULCAgICAgICA5KjMyKzIwKSAvKiAgIENFVCAt
IEluZGlyZWN0IEJyYW5jaCBUcmFja2luZyAqLwogWEVOX0NQVUZFQVRVUkUo
QVZYNTEyX0ZQMTYsICAgOSozMisyMykgLypBICBBVlg1MTIgRlAxNiBpbnN0
cnVjdGlvbnMgKi8KQEAgLTMzOCw2ICszMzksOCBAQCBYRU5fQ1BVRkVBVFVS
RShPVlJDTEtfU1RBVFVTLCAgICAgIDE2KjMyKzIzKSAvKiAgIE1TUl9PVkVS
Q0xPQ0tJTkdfU1RBVFVTICovCiBYRU5fQ1BVRkVBVFVSRShQQlJTQl9OTywg
ICAgICAgICAgIDE2KjMyKzI0KSAvKkEgIE5vIFBvc3QtQmFycmllciBSU0Ig
cHJlZGljdGlvbnMgKi8KIFhFTl9DUFVGRUFUVVJFKEdEU19DVFJMLCAgICAg
ICAgICAgMTYqMzIrMjUpIC8qICAgTUNVX09QVF9DVFJMLkdEU19NSVRfe0RJ
UyxMT0NLfSAqLwogWEVOX0NQVUZFQVRVUkUoR0RTX05PLCAgICAgICAgICAg
ICAxNiozMisyNikgLypBICBObyBHYXRoZXIgRGF0YSBTYW1wbGluZyAqLwor
WEVOX0NQVUZFQVRVUkUoUkZEU19OTywgICAgICAgICAgICAxNiozMisyNykg
LypBICBObyBSZWdpc3RlciBGaWxlIERhdGEgU2FtcGxpbmcgKi8KK1hFTl9D
UFVGRUFUVVJFKFJGRFNfQ0xFQVIsICAgICAgICAgMTYqMzIrMjgpIC8qIUEg
UmVnaXN0ZXIgRmlsZShzKSBjbGVhcmVkIGJ5IFZFUlcgKi8KIAogLyogSW50
ZWwtZGVmaW5lZCBDUFUgZmVhdHVyZXMsIE1TUl9BUkNIX0NBUFMgMHgxMGEu
ZWR4LCB3b3JkIDE3ICovCiAK

--=separator
Content-Type: application/octet-stream; name="xsa452/xsa452-4.patch"
Content-Disposition: attachment; filename="xsa452/xsa452-4.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L3NwZWMtY3RybDogVkVSVy1oYW5kbGluZyBhZGp1
c3RtZW50cwoKLi4uIGJlZm9yZSB3ZSBhZGQgeWV0IG1vcmUgY29tcGxleGl0
eSB0byB0aGlzIGxvZ2ljLiAgTW9zdGx5IGV4cGFuZGVkCmNvbW1lbnRzLCBi
dXQgd2l0aCB0aHJlZSBtaW5vciBjaGFuZ2VzLgoKMSkgSW50cm9kdWNlIGNw
dV9oYXNfdXNlZnVsX21kX2NsZWFyIHRvIHNpbXBsaWZ5IGxhdGVyIGxvZ2lj
IGluIHRoaXMgcGF0Y2ggYW5kCiAgIGZ1dHVyZSBvbmVzLgoKMikgV2Ugb25s
eSBldmVyIG5lZWQgU0NfVkVSV19JRExFIHdoZW4gU01UIGlzIGFjdGl2ZS4g
IElmIFNNVCBpc24ndCBhY3RpdmUsCiAgIHRoZW4gdGhlcmUncyBubyByZS1w
YXJ0aXRpb24gb2YgcGlwZWxpbmUgcmVzb3VyY2VzIGJhc2VkIG9uIHRocmVh
ZC1pZGxlbmVzcwogICB0byB3b3JyeSBhYm91dC4KCjMpIFRoZSBsb2dpYyB0
byBhZGp1c3QgSFZNIFZFUlcgYmFzZWQgb24gTDFEX0ZMVVNIIGlzIHVubWFp
bnRhaW5hYmxlIGFuZCwgYXMKICAgaXQgdHVybnMgb3V0LCB3cm9uZy4gIFNL
SVBfTDFERkwgaXMganVzdCBhIGhpbnQgYml0LCB3aGVyZWFzIG9wdF9sMWRf
Zmx1c2gKICAgaXMgdGhlIHJlbGV2YW50IGRlY2lzaW9uIG9mIHdoZXRoZXIg
dG8gdXNlIEwxRF9GTFVTSCBiYXNlZCBvbgogICBzdXNjZXB0aWJpbGl0eSBh
bmQgdXNlciBwcmVmZXJlbmNlLgoKICAgUmV3cml0ZSB0aGUgbG9naWMgc28g
aXQgY2FuIGJlIGZvbGxvd2VkLCBhbmQgaW5jb3Jwb3JhdGUgdGhlIGZhY3Qg
dGhhdCB3aGVuCiAgIEZCX0NMRUFSIGlzIHZpc2libGUsIEwxRF9GTFVTSCBp
c24ndCBhIHNhZmUgc3Vic3RpdHV0aW9uLgoKVGhpcyBpcyBwYXJ0IG9mIFhT
QS00NTIgLyBDVkUtMjAyMy0yODc0Ni4KClNpZ25lZC1vZmYtYnk6IEFuZHJl
dyBDb29wZXIgPGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+CkFja2VkLWJ5
OiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+CgpkaWZmIC0tZ2l0
IGEveGVuL2FyY2gveDg2L3NwZWNfY3RybC5jIGIveGVuL2FyY2gveDg2L3Nw
ZWNfY3RybC5jCmluZGV4IDljZWRlNTM2MWQxNC4uYjMxYjEzMTQ2ZmIxIDEw
MDY0NAotLS0gYS94ZW4vYXJjaC94ODYvc3BlY19jdHJsLmMKKysrIGIveGVu
L2FyY2gveDg2L3NwZWNfY3RybC5jCkBAIC0xNTE5LDcgKzE1MTksNyBAQCB2
b2lkIF9faW5pdCBpbml0X3NwZWN1bGF0aW9uX21pdGlnYXRpb25zKHZvaWQp
CiB7CiAgICAgZW51bSBpbmRfdGh1bmsgdGh1bmsgPSBUSFVOS19ERUZBVUxU
OwogICAgIGJvb2wgaGFzX3NwZWNfY3RybCwgaWJycyA9IGZhbHNlLCBod19z
bXRfZW5hYmxlZDsKLSAgICBib29sIGNwdV9oYXNfYnVnX3RhYSwgcmV0cG9s
aW5lX3NhZmU7CisgICAgYm9vbCBjcHVfaGFzX2J1Z190YWEsIGNwdV9oYXNf
dXNlZnVsX21kX2NsZWFyLCByZXRwb2xpbmVfc2FmZTsKIAogICAgIGh3X3Nt
dF9lbmFibGVkID0gY2hlY2tfc210X2VuYWJsZWQoKTsKIApAQCAtMTg1NSw1
MCArMTg1NSw5NyBAQCB2b2lkIF9faW5pdCBpbml0X3NwZWN1bGF0aW9uX21p
dGlnYXRpb25zKHZvaWQpCiAgICAgICAgICAgICAiZW5hYmxlZC4gIFBsZWFz
ZSBhc3Nlc3MgeW91ciBjb25maWd1cmF0aW9uIGFuZCBjaG9vc2UgYW5cbiIK
ICAgICAgICAgICAgICJleHBsaWNpdCAnc210PTxib29sPicgc2V0dGluZy4g
IFNlZSBYU0EtMjczLlxuIik7CiAKKyAgICAvKgorICAgICAqIEEgYnJpZWYg
c3VtbWFyeSBvZiBWRVJXLXJlbGF0ZWQgY2hhbmdlcy4KKyAgICAgKgorICAg
ICAqIGh0dHBzOi8vd3d3LmludGVsLmNvbS9jb250ZW50L3d3dy91cy9lbi9k
ZXZlbG9wZXIvYXJ0aWNsZXMvdGVjaG5pY2FsL3NvZnR3YXJlLXNlY3VyaXR5
LWd1aWRhbmNlL3RlY2huaWNhbC1kb2N1bWVudGF0aW9uL2ludGVsLWFuYWx5
c2lzLW1pY3JvYXJjaGl0ZWN0dXJhbC1kYXRhLXNhbXBsaW5nLmh0bWwKKyAg
ICAgKiBodHRwczovL3d3dy5pbnRlbC5jb20vY29udGVudC93d3cvdXMvZW4v
ZGV2ZWxvcGVyL2FydGljbGVzL3RlY2huaWNhbC9zb2Z0d2FyZS1zZWN1cml0
eS1ndWlkYW5jZS90ZWNobmljYWwtZG9jdW1lbnRhdGlvbi9wcm9jZXNzb3It
bW1pby1zdGFsZS1kYXRhLXZ1bG5lcmFiaWxpdGllcy5odG1sCisgICAgICoK
KyAgICAgKiBSZWxldmFudCB1Y29kZXM6CisgICAgICoKKyAgICAgKiAtIE1h
eSAyMDE5LCBmb3IgTURTLiAgSW50cm9kdWNlcyB0aGUgTURfQ0xFQVIgQ1BV
SUQgYml0IGFuZCBWRVJXIHNpZGUKKyAgICAgKiAgIGVmZmVjdHMgdG8gc2Ny
dWIgU3RvcmUvTG9hZC9GaWxsIGJ1ZmZlcnMgYXMgYXBwbGljYWJsZS4gIE1E
X0NMRUFSCisgICAgICogICBleGlzdHMgYXJjaGl0ZWN0dXJhbGx5LCBldmVu
IHdoZW4gdGhlIHNpZGUgZWZmZWN0cyBoYXZlIGJlZW4gcmVtb3ZlZC4KKyAg
ICAgKgorICAgICAqICAgVXNlIFZFUlcgdG8gc2NydWIgb24gcmV0dXJuLXRv
LWd1ZXN0LiAgUGFydHMgd2l0aCBMMURfRkxVU0ggdG8KKyAgICAgKiAgIG1p
dGlnYXRlIEwxVEYgaGF2ZSB0aGUgc2FtZSBzaWRlIGVmZmVjdCwgc28gbm8g
bmVlZCB0byBkbyBib3RoLgorICAgICAqCisgICAgICogICBWYXJpb3VzIEF0
b21zIHN1ZmZlciBmcm9tIFN0b3JlLWJ1ZmZlciBzYW1wbGluZyBvbmx5LiAg
U3RvcmUgYnVmZmVycworICAgICAqICAgYXJlIHN0YXRpY2FsbHkgcGFydGl0
aW9uZWQgYmV0d2VlbiBub24taWRsZSB0aHJlYWRzLCBzbyBzY3J1YmJpbmcg
aXMKKyAgICAgKiAgIHdhbnRlZCB3aGVuIGdvaW5nIGlkbGUgdG9vLgorICAg
ICAqCisgICAgICogICBMb2FkIHBvcnRzIGFuZCBGaWxsIGJ1ZmZlcnMgYXJl
IGNvbXBldGl0aXZlbHkgc2hhcmVkIGJldHdlZW4gdGhyZWFkcy4KKyAgICAg
KiAgIFNNVCBtdXN0IGJlIGRpc2FibGVkIGZvciBWRVJXIHNjcnViYmluZyB0
byBiZSBmdWxseSBlZmZlY3RpdmUuCisgICAgICoKKyAgICAgKiAtIE5vdmVt
YmVyIDIwMTksIGZvciBUQUEuICBFeHRlbmRlZCBWRVJXIHNpZGUgZWZmZWN0
cyB0byBUU1gtZW5hYmxlZAorICAgICAqICAgTURTX05PIHBhcnRzLgorICAg
ICAqCisgICAgICogLSBGZWJydWFyeSAyMDIyLCBmb3IgQ2xpZW50IFRTWCBk
ZS1mZWF0dXJlLiAgUmVtb3ZlZCBWRVJXIHNpZGUgZWZmZWN0cworICAgICAq
ICAgZnJvbSBDbGllbnQgQ1BVcyBvbmx5LgorICAgICAqCisgICAgICogLSBN
YXkgMjAyMiwgZm9yIE1NSU8gU3RhbGUgRGF0YS4gIChSZSlpbnRyb2R1Y2Vk
IEZpbGwgQnVmZmVyIHNjcnViYmluZworICAgICAqICAgb24gYWxsIE1NSU8t
YWZmZWN0ZWQgcGFydHMgd2hpY2ggZGlkbid0IGFscmVhZHkgaGF2ZSBpdCBm
b3IgTURTCisgICAgICogICByZWFzb25zLCBlbnVtZXJhdGluZyBGQl9DTEVB
UiBvbiB0aG9zZSBwYXJ0cyBvbmx5LgorICAgICAqCisgICAgICogICBJZiBG
Ql9DTEVBUiBpcyBlbnVtZXJhdGVkLCBMMURfRkxVU0ggZG9lcyBub3QgaGF2
ZSB0aGUgc2FtZSBzY3J1YmJpbmcKKyAgICAgKiAgIHNpZGUgZWZmZWN0cyBh
cyBWRVJXIGFuZCBjYW5ub3QgYmUgdXNlZCBpbiBpdHMgcGxhY2UuCisgICAg
ICovCiAgICAgbWRzX2NhbGN1bGF0aW9ucygpOwogCiAgICAgLyoKLSAgICAg
KiBQYXJ0cyB3aGljaCBlbnVtZXJhdGUgRkJfQ0xFQVIgYXJlIHRob3NlIHdo
aWNoIGFyZSBwb3N0LU1EU19OTyBhbmQgaGF2ZQotICAgICAqIHJlaW50cm9k
dWNlZCB0aGUgVkVSVyBmaWxsIGJ1ZmZlciBmbHVzaGluZyBzaWRlIGVmZmVj
dCBiZWNhdXNlIG9mIGEKLSAgICAgKiBzdXNjZXB0aWJpbGl0eSB0byBGQlNE
UC4KKyAgICAgKiBQYXJ0cyB3aGljaCBlbnVtZXJhdGUgRkJfQ0xFQVIgYXJl
IHRob3NlIHdpdGggbm93LXVwZGF0ZWQgbWljcm9jb2RlCisgICAgICogd2hp
Y2ggd2VyZW4ndCBzdXNjZXB0aWJsZSB0byB0aGUgb3JpZ2luYWwgTUZCRFMg
KGFuZCB0aGVyZWZvcmUgZGlkbid0CisgICAgICogaGF2ZSBGaWxsIEJ1ZmZl
ciBzY3J1YmJpbmcgc2lkZSBlZmZlY3RzIHRvIGJlZ2luIHdpdGgsIG9yIHdl
cmUgQ2xpZW50CisgICAgICogTURTX05PIG5vbi1UQUFfTk8gcGFydHMgd2hl
cmUgdGhlIHNjcnViYmluZyB3YXMgcmVtb3ZlZCksIGJ1dCBoYXZlIGhhZAor
ICAgICAqIHRoZSBzY3J1YmJpbmcgcmVpbnRyb2R1Y2VkIGJlY2F1c2Ugb2Yg
YSBzdXNjZXB0aWJpbGl0eSB0byBGQlNEUC4KICAgICAgKgogICAgICAqIElm
IHVucHJpdmlsZWdlZCBndWVzdHMgaGF2ZSAob3Igd2lsbCBoYXZlKSBNTUlP
IG1hcHBpbmdzLCB3ZSBjYW4KICAgICAgKiBtaXRpZ2F0ZSBjcm9zcy1kb21h
aW4gbGVha2FnZSBvZiBmaWxsIGJ1ZmZlciBkYXRhIGJ5IGlzc3VpbmcgVkVS
VyBvbgotICAgICAqIHRoZSByZXR1cm4tdG8tZ3Vlc3QgcGF0aC4KKyAgICAg
KiB0aGUgcmV0dXJuLXRvLWd1ZXN0IHBhdGguICBUaGlzIGlzIG9ubHkgYSB0
b2tlbiBlZmZvcnQgaWYgU01UIGlzCisgICAgICogYWN0aXZlLgogICAgICAq
LwogICAgIGlmICggb3B0X3VucHJpdl9tbWlvICkKICAgICAgICAgb3B0X3Zl
cndfbW1pbyA9IGNwdV9oYXNfZmJfY2xlYXI7CiAKICAgICAvKgotICAgICAq
IEJ5IGRlZmF1bHQsIGVuYWJsZSBQViBhbmQgSFZNIG1pdGlnYXRpb25zIG9u
IE1EUy12dWxuZXJhYmxlIGhhcmR3YXJlLgotICAgICAqIFRoaXMgd2lsbCBv
bmx5IGJlIGEgdG9rZW4gZWZmb3J0IGZvciBNTFBEUy9NRkJEUyB3aGVuIEhU
IGlzIGVuYWJsZWQsCi0gICAgICogYnV0IGl0IGlzIHNvbWV3aGF0IGJldHRl
ciB0aGFuIG5vdGhpbmcuCisgICAgICogTURfQ0xFQVIgaXMgZW51bWVyYXRl
ZCBhcmNoaXRlY3R1cmFsbHkgZm9yZXZlcm1vcmUsIGV2ZW4gYWZ0ZXIgdGhl
CisgICAgICogc2NydWJiaW5nIHNpZGUgZWZmZWN0cyBoYXZlIGJlZW4gcmVt
b3ZlZC4gIENyZWF0ZSBvdXJzZWx2ZXMgYW4gdmVyc2lvbgorICAgICAqIHdo
aWNoIGV4cHJlc3NlZCB3aGV0aGVyIHdlIHRoaW5rIE1EX0NMRUFSIGlzIGhh
dmluZyBhbnkgdXNlZnVsIHNpZGUKKyAgICAgKiBlZmZlY3QuCisgICAgICov
CisgICAgY3B1X2hhc191c2VmdWxfbWRfY2xlYXIgPSAoY3B1X2hhc19tZF9j
bGVhciAmJgorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChjcHVf
aGFzX2J1Z19tZHMgfHwgY3B1X2hhc19idWdfbXNiZHNfb25seSkpOworCisg
ICAgLyoKKyAgICAgKiBCeSBkZWZhdWx0LCB1c2UgVkVSVyBzY3J1YmJpbmcg
b24gYXBwbGljYWJsZSBoYXJkd2FyZSwgaWYgd2UgdGhpbmsgaXQncworICAg
ICAqIGdvaW5nIHRvIGhhdmUgYW4gZWZmZWN0LiAgVGhpcyB3aWxsIG9ubHkg
YmUgYSB0b2tlbiBlZmZvcnQgZm9yCisgICAgICogTUxQRFMvTUZCRFMgd2hl
biBTTVQgaXMgZW5hYmxlZC4KICAgICAgKi8KICAgICBpZiAoIG9wdF92ZXJ3
X3B2ID09IC0xICkKLSAgICAgICAgb3B0X3ZlcndfcHYgPSAoKGNwdV9oYXNf
YnVnX21kcyB8fCBjcHVfaGFzX2J1Z19tc2Jkc19vbmx5KSAmJgotICAgICAg
ICAgICAgICAgICAgICAgICBjcHVfaGFzX21kX2NsZWFyKTsKKyAgICAgICAg
b3B0X3ZlcndfcHYgPSBjcHVfaGFzX3VzZWZ1bF9tZF9jbGVhcjsKIAogICAg
IGlmICggb3B0X3ZlcndfaHZtID09IC0xICkKLSAgICAgICAgb3B0X3Zlcndf
aHZtID0gKChjcHVfaGFzX2J1Z19tZHMgfHwgY3B1X2hhc19idWdfbXNiZHNf
b25seSkgJiYKLSAgICAgICAgICAgICAgICAgICAgICAgIGNwdV9oYXNfbWRf
Y2xlYXIpOworICAgICAgICBvcHRfdmVyd19odm0gPSBjcHVfaGFzX3VzZWZ1
bF9tZF9jbGVhcjsKIAogICAgIC8qCi0gICAgICogRW5hYmxlIE1EUy9NTUlP
IGRlZmVuY2VzIGFzIGFwcGxpY2FibGUuICBUaGUgSWRsZSBibG9ja3MgbmVl
ZCB1c2luZyBpZgotICAgICAqIGVpdGhlciB0aGUgUFYgb3IgSFZNIE1EUyBk
ZWZlbmNlcyBhcmUgdXNlZCwgb3IgaWYgd2UgbWF5IGdpdmUgTU1JTwotICAg
ICAqIGFjY2VzcyB0byB1bnRydXN0ZWQgZ3Vlc3RzLgotICAgICAqCi0gICAg
ICogSFZNIGlzIG1vcmUgY29tcGxpY2F0ZWQuICBUaGUgTURfQ0xFQVIgbWlj
cm9jb2RlIGV4dGVuZHMgTDFEX0ZMVVNIIHdpdGgKLSAgICAgKiBlcXVpdmFs
ZW50IHNlbWFudGljcyB0byBhdm9pZCBuZWVkaW5nIHRvIHBlcmZvcm0gYm90
aCBmbHVzaGVzIG9uIHRoZQotICAgICAqIEhWTSBwYXRoLiAgVGhlcmVmb3Jl
LCB3ZSBkb24ndCBuZWVkIFZFUlcgaW4gYWRkaXRpb24gdG8gTDFEX0ZMVVNI
IChmb3IKLSAgICAgKiBNRFMgbWl0aWdhdGlvbnMuICBMMURfRkxVU0ggaXMg
bm90IHNhZmUgZm9yIE1NSU8gbWl0aWdhdGlvbnMuKQotICAgICAqCi0gICAg
ICogQWZ0ZXIgY2FsY3VsYXRpbmcgdGhlIGFwcHJvcHJpYXRlIGlkbGUgc2V0
dGluZywgc2ltcGxpZnkKLSAgICAgKiBvcHRfdmVyd19odm0gdG8gbWVhbiBq
dXN0ICJzaG91bGQgd2UgVkVSVyBvbiB0aGUgd2F5IGludG8gSFZNCi0gICAg
ICogZ3Vlc3RzIiwgc28gc3BlY19jdHJsX2luaXRfZG9tYWluKCkgY2FuIGNh
bGN1bGF0ZSBzdWl0YWJsZSBzZXR0aW5ncy4KKyAgICAgKiBJZiBTTVQgaXMg
YWN0aXZlLCBhbmQgd2UncmUgcHJvdGVjdGluZyBhZ2FpbnN0IE1EUyBvciBN
TUlPIHN0YWxlIGRhdGEsCisgICAgICogd2UgbmVlZCB0byBzY3J1YiBiZWZv
cmUgZ29pbmcgaWRsZSBhcyB3ZWxsIGFzIG9uIHJldHVybiB0byBndWVzdC4K
KyAgICAgKiBWYXJpb3VzIHBpcGVsaW5lIHJlc291cmNlcyBhcmUgcmVwYXJ0
aXRpb25lZCBhbW9uZ3N0IG5vbi1pZGxlIHRocmVhZHMuCiAgICAgICovCi0g
ICAgaWYgKCBvcHRfdmVyd19wdiB8fCBvcHRfdmVyd19odm0gfHwgb3B0X3Zl
cndfbW1pbyApCisgICAgaWYgKCAoKGNwdV9oYXNfdXNlZnVsX21kX2NsZWFy
ICYmIChvcHRfdmVyd19wdiB8fCBvcHRfdmVyd19odm0pKSB8fAorICAgICAg
ICAgIG9wdF92ZXJ3X21taW8pICYmIGh3X3NtdF9lbmFibGVkICkKICAgICAg
ICAgc2V0dXBfZm9yY2VfY3B1X2NhcChYODZfRkVBVFVSRV9TQ19WRVJXX0lE
TEUpOwotICAgIG9wdF92ZXJ3X2h2bSAmPSAhY3B1X2hhc19za2lwX2wxZGZs
ICYmICFvcHRfbDFkX2ZsdXNoOworCisgICAgLyoKKyAgICAgKiBBZnRlciBj
YWxjdWxhdGluZyB0aGUgYXBwcm9wcmlhdGUgaWRsZSBzZXR0aW5nLCBzaW1w
bGlmeSBvcHRfdmVyd19odm0KKyAgICAgKiB0byBtZWFuIGp1c3QgInNob3Vs
ZCB3ZSBWRVJXIG9uIHRoZSB3YXkgaW50byBIVk0gZ3Vlc3RzIiwgc28KKyAg
ICAgKiBzcGVjX2N0cmxfaW5pdF9kb21haW4oKSBjYW4gY2FsY3VsYXRlIHN1
aXRhYmxlIHNldHRpbmdzLgorICAgICAqCisgICAgICogSXQgaXMgb25seSBz
YWZlIHRvIHVzZSBMMURfRkxVU0ggaW4gcGxhY2Ugb2YgVkVSVyB3aGVuIE1E
X0NMRUFSIGlzIHRoZQorICAgICAqIG9ubHkgKl9DTEVBUiB3ZSBjYW4gc2Vl
LgorICAgICAqLworICAgIGlmICggb3B0X2wxZF9mbHVzaCAmJiBjcHVfaGFz
X21kX2NsZWFyICYmICFjcHVfaGFzX2ZiX2NsZWFyICkKKyAgICAgICAgb3B0
X3ZlcndfaHZtID0gZmFsc2U7CiAKICAgICAvKgogICAgICAqIFdhcm4gdGhl
IHVzZXIgaWYgdGhleSBhcmUgb24gTUxQRFMvTUZCRFMtdnVsbmVyYWJsZSBo
YXJkd2FyZSB3aXRoIEhUCg==

--=separator
Content-Type: application/octet-stream; name="xsa452/xsa452-5.patch"
Content-Disposition: attachment; filename="xsa452/xsa452-5.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L3NwZWMtY3RybDogTWl0aWdhdGlvbiBSZWdpc3Rl
ciBGaWxlIERhdGEgU2FtcGxpbmcKClJGRFMgYWZmZWN0cyBBdG9tIGNvcmVz
LCBhbHNvIGJyYW5kZWQgRS1jb3JlcywgYmV0d2VlbiB0aGUgR29sZG1vbnQg
YW5kCkdyYWNlbW9udCBtaWNyb2FyY2hpdGVjdHVyZXMuICBUaGlzIGluY2x1
ZGVzIEFsZGVyIExha2UgYW5kIFJhcHRvciBMYWtlIGh5YnJpZApjbGllbiBz
eXN0ZW1zIHdoaWNoIGhhdmUgYSBtaXggb2YgR3JhY2Vtb250IGFuZCBvdGhl
ciB0eXBlcyBvZiBjb3Jlcy4KClR3byBuZXcgYml0cyBoYXZlIGJlZW4gZGVm
aW5lZDsgUkZEU19DTEVBUiB0byBpbmRpY2F0ZSBWRVJXIGhhcyBtb3JlIHNp
ZGUKZWZmZXRzLCBhbmQgUkZEU19OTyB0byBpbmNpZGF0ZSB0aGF0IHRoZSBz
eXN0ZW0gaXMgdW5hZmZlY3RlZC4gIFBsZW50eSBvZgp1bmFmZmVjdGVkIENQ
VXMgd29uJ3QgYmUgZ2V0dGluZyBSRkRTX05PIHJldHJvZml0dGVkIGluIG1p
Y3JvY29kZSwgc28gd2UKc3ludGhlc2lzZSBpdC4gIEFsZGVyIExha2UgYW5k
IFJhcHRvciBMYWtlIFhlb24tRSdzIGFyZSB1bmFmZmVjdGVkIGR1ZSB0bwp0
aGVpciBwbGF0Zm9ybSBjb25maWd1cmF0aW9uLCBhbmQgd2UgbXVzdCB1c2Ug
dGhlIEh5YnJpZCBDUFVJRCBiaXQgdG8KZGlzdGluZ3Vpc2ggdGhlbSBmcm9t
IHRoZWlyIG5vbi1YZW9uIGNvdW50ZXJwYXJ0cy4KCkxpa2UgTURfQ0xFQVIg
YW5kIEZCX0NMRUFSLCBSRkRTX0NMRUFSIG5lZWRzIE9SLWluZyBhY3Jvc3Mg
YSByZXNvdXJjZSBwb29sLCBzbwpzZXQgaXQgaW4gdGhlIG1heCBwb2xpY2ll
cyBhbmQgcmVmbGVjdCB0aGUgaG9zdCBzZXR0aW5nIGluIGRlZmF1bHQuCgpU
aGlzIGlzIHBhcnQgb2YgWFNBLTQ1MiAvIENWRS0yMDIzLTI4NzQ2LgoKU2ln
bmVkLW9mZi1ieTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0
cml4LmNvbT4KUmV2aWV3ZWQtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBz
dXNlLmNvbT4KCmRpZmYgLS1naXQgYS90b29scy9taXNjL3hlbi1jcHVpZC5j
IGIvdG9vbHMvbWlzYy94ZW4tY3B1aWQuYwppbmRleCA0NmFiZGI5MTQwOTIu
LjUxZWZiZmY1NzllNiAxMDA2NDQKLS0tIGEvdG9vbHMvbWlzYy94ZW4tY3B1
aWQuYworKysgYi90b29scy9taXNjL3hlbi1jcHVpZC5jCkBAIC0xNzIsNyAr
MTcyLDcgQEAgc3RhdGljIGNvbnN0IGNoYXIgKmNvbnN0IHN0cl83ZDBbMzJd
ID0KICAgICBbIDhdID0gImF2eDUxMi12cDJpbnRlcnNlY3QiLCBbIDldID0g
InNyYmRzLWN0cmwiLAogICAgIFsxMF0gPSAibWQtY2xlYXIiLCAgICAgICAg
ICAgIFsxMV0gPSAicnRtLWFsd2F5cy1hYm9ydCIsCiAgICAgLyogMTIgKi8g
ICAgICAgICAgICAgICAgWzEzXSA9ICJ0c3gtZm9yY2UtYWJvcnQiLAotICAg
IFsxNF0gPSAic2VyaWFsaXplIiwKKyAgICBbMTRdID0gInNlcmlhbGl6ZSIs
ICAgICBbMTVdID0gImh5YnJpZCIsCiAgICAgWzE2XSA9ICJ0c3hsZHRyayIs
CiAgICAgWzE4XSA9ICJwY29uZmlnIiwKICAgICBbMjBdID0gImNldC1pYnQi
LApAQCAtMjUxLDcgKzI1MSw4IEBAIHN0YXRpYyBjb25zdCBjaGFyICpjb25z
dCBzdHJfbTEwQWxbMzJdID0KICAgICBbMjBdID0gImJoaS1ubyIsICAgICAg
ICAgICAgICBbMjFdID0gInhhcGljLXN0YXR1cyIsCiAgICAgLyogMjIgKi8g
ICAgICAgICAgICAgICAgICAgICAgWzIzXSA9ICJvdnJjbGstc3RhdHVzIiwK
ICAgICBbMjRdID0gInBicnNiLW5vIiwgICAgICAgICAgICBbMjVdID0gImdk
cy1jdHJsIiwKLSAgICBbMjZdID0gImdkcy1ubyIsCisgICAgWzI2XSA9ICJn
ZHMtbm8iLCAgICAgICAgICAgICAgWzI3XSA9ICJyZmRzLW5vIiwKKyAgICBb
MjhdID0gInJmZHMtY2xlYXIiLAogfTsKIAogc3RhdGljIGNvbnN0IGNoYXIg
KmNvbnN0IHN0cl9tMTBBaFszMl0gPQpkaWZmIC0tZ2l0IGEveGVuL2FyY2gv
eDg2L2NwdS1wb2xpY3kuYyBiL3hlbi9hcmNoL3g4Ni9jcHUtcG9saWN5LmMK
aW5kZXggMmM2ZjAzMDU3YjQzLi4yYWNjMjc2MzJmOWEgMTAwNjQ0Ci0tLSBh
L3hlbi9hcmNoL3g4Ni9jcHUtcG9saWN5LmMKKysrIGIveGVuL2FyY2gveDg2
L2NwdS1wb2xpY3kuYwpAQCAtNDUxLDYgKzQ1MSw3IEBAIHN0YXRpYyB2b2lk
IF9faW5pdCBndWVzdF9jb21tb25fbWF4X2ZlYXR1cmVfYWRqdXN0bWVudHMo
dWludDMyX3QgKmZzKQogICAgICAgICAgKi8KICAgICAgICAgX19zZXRfYml0
KFg4Nl9GRUFUVVJFX01EX0NMRUFSLCBmcyk7CiAgICAgICAgIF9fc2V0X2Jp
dChYODZfRkVBVFVSRV9GQl9DTEVBUiwgZnMpOworICAgICAgICBfX3NldF9i
aXQoWDg2X0ZFQVRVUkVfUkZEU19DTEVBUiwgZnMpOwogCiAgICAgICAgIC8q
CiAgICAgICAgICAqIFRoZSBHYXRoZXIgRGF0YSBTYW1wbGluZyBtaWNyb2Nv
ZGUgbWl0aWdhdGlvbiAoQXVndXN0IDIwMjMpIGhhcyBhbgpAQCAtNTEwLDYg
KzUxMSwxMCBAQCBzdGF0aWMgdm9pZCBfX2luaXQgZ3Vlc3RfY29tbW9uX2Rl
ZmF1bHRfZmVhdHVyZV9hZGp1c3RtZW50cyh1aW50MzJfdCAqZnMpCiAgICAg
ICAgIGlmICggY3B1X2hhc19mYl9jbGVhciApCiAgICAgICAgICAgICBfX3Nl
dF9iaXQoWDg2X0ZFQVRVUkVfRkJfQ0xFQVIsIGZzKTsKIAorICAgICAgICBf
X2NsZWFyX2JpdChYODZfRkVBVFVSRV9SRkRTX0NMRUFSLCBmcyk7CisgICAg
ICAgIGlmICggY3B1X2hhc19yZmRzX2NsZWFyICkKKyAgICAgICAgICAgIF9f
c2V0X2JpdChYODZfRkVBVFVSRV9SRkRTX0NMRUFSLCBmcyk7CisKICAgICAg
ICAgLyoKICAgICAgICAgICogVGhlIEdhdGhlciBEYXRhIFNhbXBsaW5nIG1p
Y3JvY29kZSBtaXRpZ2F0aW9uIChBdWd1c3QgMjAyMykgaGFzIGFuCiAgICAg
ICAgICAqIGFkdmVyc2UgcGVyZm9ybWFuY2UgaW1wYWN0IG9uIHRoZSBDTFdC
IGluc3RydWN0aW9uIG9uIFNLWC9DTFgvQ1BYLgpkaWZmIC0tZ2l0IGEveGVu
L2FyY2gveDg2L2luY2x1ZGUvYXNtL2NwdWZlYXR1cmUuaCBiL3hlbi9hcmNo
L3g4Ni9pbmNsdWRlL2FzbS9jcHVmZWF0dXJlLmgKaW5kZXggYWQyNGQwZmE4
ODhiLi45YmM1NTM2ODFmNGEgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9p
bmNsdWRlL2FzbS9jcHVmZWF0dXJlLmgKKysrIGIveGVuL2FyY2gveDg2L2lu
Y2x1ZGUvYXNtL2NwdWZlYXR1cmUuaApAQCAtMTgyLDYgKzE4Miw3IEBAIHN0
YXRpYyBpbmxpbmUgYm9vbCBib290X2NwdV9oYXModW5zaWduZWQgaW50IGZl
YXQpCiAjZGVmaW5lIGNwdV9oYXNfcnRtX2Fsd2F5c19hYm9ydCBib290X2Nw
dV9oYXMoWDg2X0ZFQVRVUkVfUlRNX0FMV0FZU19BQk9SVCkKICNkZWZpbmUg
Y3B1X2hhc190c3hfZm9yY2VfYWJvcnQgYm9vdF9jcHVfaGFzKFg4Nl9GRUFU
VVJFX1RTWF9GT1JDRV9BQk9SVCkKICNkZWZpbmUgY3B1X2hhc19zZXJpYWxp
emUgICAgICAgYm9vdF9jcHVfaGFzKFg4Nl9GRUFUVVJFX1NFUklBTElaRSkK
KyNkZWZpbmUgY3B1X2hhc19oeWJyaWQgICAgICAgICAgYm9vdF9jcHVfaGFz
KFg4Nl9GRUFUVVJFX0hZQlJJRCkKICNkZWZpbmUgY3B1X2hhc19hdng1MTJf
ZnAxNiAgICAgYm9vdF9jcHVfaGFzKFg4Nl9GRUFUVVJFX0FWWDUxMl9GUDE2
KQogI2RlZmluZSBjcHVfaGFzX2FyY2hfY2FwcyAgICAgICBib290X2NwdV9o
YXMoWDg2X0ZFQVRVUkVfQVJDSF9DQVBTKQogCkBAIC0yMTMsNiArMjE0LDgg
QEAgc3RhdGljIGlubGluZSBib29sIGJvb3RfY3B1X2hhcyh1bnNpZ25lZCBp
bnQgZmVhdCkKICNkZWZpbmUgY3B1X2hhc19ycnNiYSAgICAgICAgICAgYm9v
dF9jcHVfaGFzKFg4Nl9GRUFUVVJFX1JSU0JBKQogI2RlZmluZSBjcHVfaGFz
X2dkc19jdHJsICAgICAgICBib290X2NwdV9oYXMoWDg2X0ZFQVRVUkVfR0RT
X0NUUkwpCiAjZGVmaW5lIGNwdV9oYXNfZ2RzX25vICAgICAgICAgIGJvb3Rf
Y3B1X2hhcyhYODZfRkVBVFVSRV9HRFNfTk8pCisjZGVmaW5lIGNwdV9oYXNf
cmZkc19ubyAgICAgICAgIGJvb3RfY3B1X2hhcyhYODZfRkVBVFVSRV9SRkRT
X05PKQorI2RlZmluZSBjcHVfaGFzX3JmZHNfY2xlYXIgICAgICBib290X2Nw
dV9oYXMoWDg2X0ZFQVRVUkVfUkZEU19DTEVBUikKIAogLyogU3ludGhlc2l6
ZWQuICovCiAjZGVmaW5lIGNwdV9oYXNfYXJjaF9wZXJmbW9uICAgIGJvb3Rf
Y3B1X2hhcyhYODZfRkVBVFVSRV9BUkNIX1BFUkZNT04pCmRpZmYgLS1naXQg
YS94ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vbXNyLWluZGV4LmggYi94ZW4v
YXJjaC94ODYvaW5jbHVkZS9hc20vbXNyLWluZGV4LmgKaW5kZXggZmM4MmFm
YzI0NmZhLi45MmRkOWZhNDk2MmMgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4
Ni9pbmNsdWRlL2FzbS9tc3ItaW5kZXguaAorKysgYi94ZW4vYXJjaC94ODYv
aW5jbHVkZS9hc20vbXNyLWluZGV4LmgKQEAgLTg5LDYgKzg5LDggQEAKICNk
ZWZpbmUgIEFSQ0hfQ0FQU19QQlJTQl9OTyAgICAgICAgICAgICAgICAgKF9B
QygxLCBVTEwpIDw8IDI0KQogI2RlZmluZSAgQVJDSF9DQVBTX0dEU19DVFJM
ICAgICAgICAgICAgICAgICAoX0FDKDEsIFVMTCkgPDwgMjUpCiAjZGVmaW5l
ICBBUkNIX0NBUFNfR0RTX05PICAgICAgICAgICAgICAgICAgIChfQUMoMSwg
VUxMKSA8PCAyNikKKyNkZWZpbmUgIEFSQ0hfQ0FQU19SRkRTX05PICAgICAg
ICAgICAgICAgICAgKF9BQygxLCBVTEwpIDw8IDI3KQorI2RlZmluZSAgQVJD
SF9DQVBTX1JGRFNfQ0xFQVIgICAgICAgICAgICAgICAoX0FDKDEsIFVMTCkg
PDwgMjgpCiAKICNkZWZpbmUgTVNSX0ZMVVNIX0NNRCAgICAgICAgICAgICAg
ICAgICAgICAgMHgwMDAwMDEwYgogI2RlZmluZSAgRkxVU0hfQ01EX0wxRCAg
ICAgICAgICAgICAgICAgICAgICAoX0FDKDEsIFVMTCkgPDwgIDApCmRpZmYg
LS1naXQgYS94ZW4vYXJjaC94ODYvc3BlY19jdHJsLmMgYi94ZW4vYXJjaC94
ODYvc3BlY19jdHJsLmMKaW5kZXggYjMxYjEzMTQ2ZmIxLi4wNjM4ZDk5ODBh
NjEgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9zcGVjX2N0cmwuYworKysg
Yi94ZW4vYXJjaC94ODYvc3BlY19jdHJsLmMKQEAgLTEyLDYgKzEyLDcgQEAK
IAogI2luY2x1ZGUgPGFzbS9hbWQuaD4KICNpbmNsdWRlIDxhc20vaHZtL3N2
bS9zdm0uaD4KKyNpbmNsdWRlIDxhc20vaW50ZWwtZmFtaWx5Lmg+CiAjaW5j
bHVkZSA8YXNtL21pY3JvY29kZS5oPgogI2luY2x1ZGUgPGFzbS9tc3IuaD4K
ICNpbmNsdWRlIDxhc20vcHYvZG9tYWluLmg+CkBAIC00MzUsNyArNDM2LDcg
QEAgc3RhdGljIHZvaWQgX19pbml0IHByaW50X2RldGFpbHMoZW51bSBpbmRf
dGh1bmsgdGh1bmspCiAgICAgICogSGFyZHdhcmUgcmVhZC1vbmx5IGluZm9y
bWF0aW9uLCBzdGF0aW5nIGltbXVuaXR5IHRvIGNlcnRhaW4gaXNzdWVzLCBv
cgogICAgICAqIHN1Z2dlc3Rpb25zIG9mIHdoaWNoIG1pdGlnYXRpb24gdG8g
dXNlLgogICAgICAqLwotICAgIHByaW50aygiICBIYXJkd2FyZSBoaW50czol
cyVzJXMlcyVzJXMlcyVzJXMlcyVzJXMlcyVzJXMlcyVzJXMlcyVzJXMlc1xu
IiwKKyAgICBwcmludGsoIiAgSGFyZHdhcmUgaGludHM6JXMlcyVzJXMlcyVz
JXMlcyVzJXMlcyVzJXMlcyVzJXMlcyVzJXMlcyVzJXMlc1xuIiwKICAgICAg
ICAgICAgKGNhcHMgJiBBUkNIX0NBUFNfUkRDTF9OTykgICAgICAgICAgICAg
ICAgICAgICAgICA/ICIgUkRDTF9OTyIgICAgICAgIDogIiIsCiAgICAgICAg
ICAgIChjYXBzICYgQVJDSF9DQVBTX0VJQlJTKSAgICAgICAgICAgICAgICAg
ICAgICAgICAgPyAiIEVJQlJTIiAgICAgICAgICA6ICIiLAogICAgICAgICAg
ICAoY2FwcyAmIEFSQ0hfQ0FQU19SU0JBKSAgICAgICAgICAgICAgICAgICAg
ICAgICAgID8gIiBSU0JBIiAgICAgICAgICAgOiAiIiwKQEAgLTQ1MSw2ICs0
NTIsNyBAQCBzdGF0aWMgdm9pZCBfX2luaXQgcHJpbnRfZGV0YWlscyhlbnVt
IGluZF90aHVuayB0aHVuaykKICAgICAgICAgICAgKGNhcHMgJiBBUkNIX0NB
UFNfRkJfQ0xFQVIpICAgICAgICAgICAgICAgICAgICAgICA/ICIgRkJfQ0xF
QVIiICAgICAgIDogIiIsCiAgICAgICAgICAgIChjYXBzICYgQVJDSF9DQVBT
X1BCUlNCX05PKSAgICAgICAgICAgICAgICAgICAgICAgPyAiIFBCUlNCX05P
IiAgICAgICA6ICIiLAogICAgICAgICAgICAoY2FwcyAmIEFSQ0hfQ0FQU19H
RFNfTk8pICAgICAgICAgICAgICAgICAgICAgICAgID8gIiBHRFNfTk8iICAg
ICAgICAgOiAiIiwKKyAgICAgICAgICAgKGNhcHMgJiBBUkNIX0NBUFNfUkZE
U19OTykgICAgICAgICAgICAgICAgICAgICAgICA/ICIgUkZEU19OTyIgICAg
ICAgIDogIiIsCiAgICAgICAgICAgIChlOGIgICYgY3B1ZmVhdF9tYXNrKFg4
Nl9GRUFUVVJFX0lCUlNfQUxXQVlTKSkgICAgPyAiIElCUlNfQUxXQVlTIiAg
ICA6ICIiLAogICAgICAgICAgICAoZThiICAmIGNwdWZlYXRfbWFzayhYODZf
RkVBVFVSRV9TVElCUF9BTFdBWVMpKSAgID8gIiBTVElCUF9BTFdBWVMiICAg
OiAiIiwKICAgICAgICAgICAgKGU4YiAgJiBjcHVmZWF0X21hc2soWDg2X0ZF
QVRVUkVfSUJSU19GQVNUKSkgICAgICA/ICIgSUJSU19GQVNUIiAgICAgIDog
IiIsCkBAIC00NjEsNyArNDYzLDcgQEAgc3RhdGljIHZvaWQgX19pbml0IHBy
aW50X2RldGFpbHMoZW51bSBpbmRfdGh1bmsgdGh1bmspCiAgICAgICAgICAg
IChlMjFhICYgY3B1ZmVhdF9tYXNrKFg4Nl9GRUFUVVJFX1NSU09fTk8pKSAg
ICAgICAgPyAiIFNSU09fTk8iICAgICAgICA6ICIiKTsKIAogICAgIC8qIEhh
cmR3YXJlIGZlYXR1cmVzIHdoaWNoIG5lZWQgZHJpdmluZyB0byBtaXRpZ2F0
ZSBpc3N1ZXMuICovCi0gICAgcHJpbnRrKCIgIEhhcmR3YXJlIGZlYXR1cmVz
OiVzJXMlcyVzJXMlcyVzJXMlcyVzJXMlcyVzXG4iLAorICAgIHByaW50aygi
ICBIYXJkd2FyZSBmZWF0dXJlczolcyVzJXMlcyVzJXMlcyVzJXMlcyVzJXMl
cyVzXG4iLAogICAgICAgICAgICAoZThiICAmIGNwdWZlYXRfbWFzayhYODZf
RkVBVFVSRV9JQlBCKSkgfHwKICAgICAgICAgICAgKF83ZDAgJiBjcHVmZWF0
X21hc2soWDg2X0ZFQVRVUkVfSUJSU0IpKSAgICAgICAgICA/ICIgSUJQQiIg
ICAgICAgICAgIDogIiIsCiAgICAgICAgICAgIChlOGIgICYgY3B1ZmVhdF9t
YXNrKFg4Nl9GRUFUVVJFX0lCUlMpKSB8fApAQCAtNDc5LDYgKzQ4MSw3IEBA
IHN0YXRpYyB2b2lkIF9faW5pdCBwcmludF9kZXRhaWxzKGVudW0gaW5kX3Ro
dW5rIHRodW5rKQogICAgICAgICAgICAoY2FwcyAmIEFSQ0hfQ0FQU19UU1hf
Q1RSTCkgICAgICAgICAgICAgICAgICAgICAgID8gIiBUU1hfQ1RSTCIgICAg
ICAgOiAiIiwKICAgICAgICAgICAgKGNhcHMgJiBBUkNIX0NBUFNfRkJfQ0xF
QVJfQ1RSTCkgICAgICAgICAgICAgICAgICA/ICIgRkJfQ0xFQVJfQ1RSTCIg
IDogIiIsCiAgICAgICAgICAgIChjYXBzICYgQVJDSF9DQVBTX0dEU19DVFJM
KSAgICAgICAgICAgICAgICAgICAgICAgPyAiIEdEU19DVFJMIiAgICAgICA6
ICIiLAorICAgICAgICAgICAoY2FwcyAmIEFSQ0hfQ0FQU19SRkRTX0NMRUFS
KSAgICAgICAgICAgICAgICAgICAgID8gIiBSRkRTX0NMRUFSIiAgICAgOiAi
IiwKICAgICAgICAgICAgKGUyMWEgJiBjcHVmZWF0X21hc2soWDg2X0ZFQVRV
UkVfU0JQQikpICAgICAgICAgICA/ICIgU0JQQiIgICAgICAgICAgIDogIiIp
OwogCiAgICAgLyogQ29tcGlsZWQtaW4gc3VwcG9ydCB3aGljaCBwZXJ0YWlu
cyB0byBtaXRpZ2F0aW9ucy4gKi8KQEAgLTEzNDcsNiArMTM1MCw4MyBAQCBz
dGF0aWMgX19pbml0IHZvaWQgbWRzX2NhbGN1bGF0aW9ucyh2b2lkKQogICAg
IH0KIH0KIAorLyoKKyAqIFJlZ2lzdGVyIEZpbGUgRGF0YSBTYW1wbGluZyBh
ZmZlY3RzIEF0b20gY29yZXMgZnJvbSB0aGUgR29sZG1vbnQgdG8KKyAqIEdy
YWNlbW9udCBtaWNyb2FyY2hpdGVjdHVyZXMuICBUaGUgTWFyY2ggMjAyNCBt
aWNyb2NvZGUgYWRkcyBSRkRTX05PIHRvCisgKiBzb21lIGJ1dCBub3QgYWxs
IHVuYWZmZWN0ZWQgcGFydHMsIGFuZCBSRkRTX0NMRUFSIHRvIGFmZmVjdGVk
IHBhcnRzIHN0aWxsCisgKiBpbiBzdXBwb3J0LgorICoKKyAqIEFsZGVyIExh
a2UgYW5kIFJhcHRvciBMYWtlIGNsaWVudCBDUFVzIGhhdmUgYSBtaXggb2Yg
UCBjb3JlcworICogKEdvbGRlbi9SYXB0b3IgQ292ZSwgbm90IHZ1bG5lcmFi
bGUpIGFuZCBFIGNvcmVzIChHcmFjZW1vbnQsCisgKiB2dWxuZXJhYmxlKSwg
YW5kIGJvdGggZW51bWVyYXRlIFJGRFNfQ0xFQVIuCisgKgorICogQm90aCBl
eGlzdCBpbiBhIFhlb24gU0tVLCB3aGljaCBoYXMgdGhlIEUgY29yZXMgKEdy
YWNlbW9udCkgZGlzYWJsZWQgYnkKKyAqIHBsYXRmb3JtIGNvbmZpZ3VyYXRp
b24sIGFuZCBlbnVtZXJhdGUgUkZEU19OTy4KKyAqCisgKiBXaXRoIG9sZGVy
IHBhcnRzLCBvciB3aXRoIG91dC1vZi1kYXRlIG1pY3JvY29kZSwgc3ludGhl
c2lzZSBSRkRTX05PIHdoZW4KKyAqIHNhZmUgdG8gZG8gc28uCisgKgorICog
aHR0cHM6Ly93d3cuaW50ZWwuY29tL2NvbnRlbnQvd3d3L3VzL2VuL2RldmVs
b3Blci9hcnRpY2xlcy90ZWNobmljYWwvc29mdHdhcmUtc2VjdXJpdHktZ3Vp
ZGFuY2UvYWR2aXNvcnktZ3VpZGFuY2UvcmVnaXN0ZXItZmlsZS1kYXRhLXNh
bXBsaW5nLmh0bWwKKyAqLworc3RhdGljIHZvaWQgX19pbml0IHJmZHNfY2Fs
Y3VsYXRpb25zKHZvaWQpCit7CisgICAgLyogUkZEUyBpcyBvbmx5IGtub3du
IHRvIGFmZmVjdCBJbnRlbCBGYW1pbHkgNiBwcm9jZXNzb3JzIGF0IHRoaXMg
dGltZS4gKi8KKyAgICBpZiAoIGJvb3RfY3B1X2RhdGEueDg2X3ZlbmRvciAh
PSBYODZfVkVORE9SX0lOVEVMIHx8CisgICAgICAgICBib290X2NwdV9kYXRh
Lng4NiAhPSA2ICkKKyAgICAgICAgcmV0dXJuOworCisgICAgLyoKKyAgICAg
KiBJZiBSRkRTX05PIG9yIFJGRFNfQ0xFQVIgYXJlIHZpc2libGUsIHdlJ3Zl
IGVpdGhlciBnb3Qgc3VpdGFibGUKKyAgICAgKiBtaWNyb2NvZGUsIG9yIGFu
IFJGRFMtYXdhcmUgaHlwZXJ2aXNvciBpcyBsZXZlbGxpbmcgdXMgaW4gYSBw
b29sLgorICAgICAqLworICAgIGlmICggY3B1X2hhc19yZmRzX25vIHx8IGNw
dV9oYXNfcmZkc19jbGVhciApCisgICAgICAgIHJldHVybjsKKworICAgIC8q
IElmIHdlJ3JlIHZpcnR1YWxpc2VkLCBkb24ndCBhdHRlbXB0IHRvIHN5bnRo
ZXNpc2UgUkZEU19OTy4gKi8KKyAgICBpZiAoIGNwdV9oYXNfaHlwZXJ2aXNv
ciApCisgICAgICAgIHJldHVybjsKKworICAgIC8qCisgICAgICogTm90IGFs
bCBDUFVzIGFyZSBleHBlY3RlZCB0byBnZXQgYSBtaWNyb2NvZGUgdXBkYXRl
IGVudW1lcmF0aW5nIG9uZSBvZgorICAgICAqIFJGRFNfe05PLENMRUFSfSwg
b3Igd2UgbWlnaHQgaGF2ZSBvdXQtb2YtZGF0ZSBtaWNyb2NvZGUuCisgICAg
ICovCisgICAgc3dpdGNoICggYm9vdF9jcHVfZGF0YS54ODZfbW9kZWwgKQor
ICAgIHsKKyAgICBjYXNlIElOVEVMX0ZBTTZfQUxERVJMQUtFOgorICAgIGNh
c2UgSU5URUxfRkFNNl9SQVBUT1JMQUtFOgorICAgICAgICAvKgorICAgICAg
ICAgKiBBbGRlciBMYWtlIGFuZCBSYXB0b3IgTGFrZSBtaWdodCBiZSBhIGNs
aWVudCBTS1UgKHdpdGggdGhlCisgICAgICAgICAqIEdyYWNlbW9udCBjb3Jl
cyBhY3RpdmUsIGFuZCB0aGVyZWZvcmUgdnVsbmVyYWJsZSkgb3IgbWlnaHQg
YmUgYQorICAgICAgICAgKiBzZXJ2ZXIgU0tVICh3aXRoIHRoZSBHcmFjZW1v
bnQgY29yZXMgZGlzYWJsZWQsIGFuZCB0aGVyZWZvcmUgbm90CisgICAgICAg
ICAqIHZ1bG5lcmFibGUpLgorICAgICAgICAgKgorICAgICAgICAgKiBTZWUg
aWYgdGhlIENQVSBpZGVudGlmaWVzIGFzIGh5YnJpZCB0byBkaXN0aW5ndWlz
aCB0aGUgdHdvIGNhc2VzLgorICAgICAgICAgKi8KKyAgICAgICAgaWYgKCAh
Y3B1X2hhc19oeWJyaWQgKQorICAgICAgICAgICAgYnJlYWs7CisgICAgICAg
IGZhbGx0aHJvdWdoOworICAgIGNhc2UgSU5URUxfRkFNNl9BTERFUkxBS0Vf
TDoKKyAgICBjYXNlIElOVEVMX0ZBTTZfUkFQVE9STEFLRV9QOgorICAgIGNh
c2UgSU5URUxfRkFNNl9SQVBUT1JMQUtFX1M6CisKKyAgICBjYXNlIElOVEVM
X0ZBTTZfQVRPTV9HT0xETU9OVDogICAgICAvKiBBcG9sbG8gTGFrZSAqLwor
ICAgIGNhc2UgSU5URUxfRkFNNl9BVE9NX0dPTERNT05UX0Q6ICAgIC8qIERl
bnZlcnRvbiAqLworICAgIGNhc2UgSU5URUxfRkFNNl9BVE9NX0dPTERNT05U
X1BMVVM6IC8qIEdlbWluaSBMYWtlICovCisgICAgY2FzZSBJTlRFTF9GQU02
X0FUT01fVFJFTU9OVF9EOiAgICAgLyogU25vdyBSaWRnZSAvIFBhcmtlciBS
aWRnZSAqLworICAgIGNhc2UgSU5URUxfRkFNNl9BVE9NX1RSRU1PTlQ6ICAg
ICAgIC8qIEVsa2hhcnQgTGFrZSAqLworICAgIGNhc2UgSU5URUxfRkFNNl9B
VE9NX1RSRU1PTlRfTDogICAgIC8qIEphc3BlciBMYWtlICovCisgICAgY2Fz
ZSBJTlRFTF9GQU02X0FUT01fR1JBQ0VNT05UOiAgICAgLyogQWxkZXIgTGFr
ZSBOICovCisgICAgICAgIHJldHVybjsKKyAgICB9CisKKyAgICAvKgorICAg
ICAqIFdlIGFwcGVhciB0byBiZSBvbiBhbiB1bmFmZmVjdGVkIENQVSB3aGlj
aCBkaWRuJ3QgZW51bWVyYXRlIFJGRFNfTk8sCisgICAgICogcGVyaGFwcyBi
ZWNhdXNlIG9mIGl0J3MgYWdlIG9yIGJlY2F1c2Ugb2Ygb3V0LW9mLWRhdGUg
bWljcm9jb2RlLgorICAgICAqIFN5bnRoZXNpc2UgaXQuCisgICAgICovCisg
ICAgc2V0dXBfZm9yY2VfY3B1X2NhcChYODZfRkVBVFVSRV9SRkRTX05PKTsK
K30KKwogc3RhdGljIGJvb2wgX19pbml0IGNwdV9oYXNfZ2RzKHZvaWQpCiB7
CiAgICAgLyoKQEAgLTE4NjAsNiArMTk0MCw3IEBAIHZvaWQgX19pbml0IGlu
aXRfc3BlY3VsYXRpb25fbWl0aWdhdGlvbnModm9pZCkKICAgICAgKgogICAg
ICAqIGh0dHBzOi8vd3d3LmludGVsLmNvbS9jb250ZW50L3d3dy91cy9lbi9k
ZXZlbG9wZXIvYXJ0aWNsZXMvdGVjaG5pY2FsL3NvZnR3YXJlLXNlY3VyaXR5
LWd1aWRhbmNlL3RlY2huaWNhbC1kb2N1bWVudGF0aW9uL2ludGVsLWFuYWx5
c2lzLW1pY3JvYXJjaGl0ZWN0dXJhbC1kYXRhLXNhbXBsaW5nLmh0bWwKICAg
ICAgKiBodHRwczovL3d3dy5pbnRlbC5jb20vY29udGVudC93d3cvdXMvZW4v
ZGV2ZWxvcGVyL2FydGljbGVzL3RlY2huaWNhbC9zb2Z0d2FyZS1zZWN1cml0
eS1ndWlkYW5jZS90ZWNobmljYWwtZG9jdW1lbnRhdGlvbi9wcm9jZXNzb3It
bW1pby1zdGFsZS1kYXRhLXZ1bG5lcmFiaWxpdGllcy5odG1sCisgICAgICog
aHR0cHM6Ly93d3cuaW50ZWwuY29tL2NvbnRlbnQvd3d3L3VzL2VuL2RldmVs
b3Blci9hcnRpY2xlcy90ZWNobmljYWwvc29mdHdhcmUtc2VjdXJpdHktZ3Vp
ZGFuY2UvYWR2aXNvcnktZ3VpZGFuY2UvcmVnaXN0ZXItZmlsZS1kYXRhLXNh
bXBsaW5nLmh0bWwKICAgICAgKgogICAgICAqIFJlbGV2YW50IHVjb2RlczoK
ICAgICAgKgpAQCAtMTg4OSw4ICsxOTcwLDEyIEBAIHZvaWQgX19pbml0IGlu
aXRfc3BlY3VsYXRpb25fbWl0aWdhdGlvbnModm9pZCkKICAgICAgKgogICAg
ICAqICAgSWYgRkJfQ0xFQVIgaXMgZW51bWVyYXRlZCwgTDFEX0ZMVVNIIGRv
ZXMgbm90IGhhdmUgdGhlIHNhbWUgc2NydWJiaW5nCiAgICAgICogICBzaWRl
IGVmZmVjdHMgYXMgVkVSVyBhbmQgY2Fubm90IGJlIHVzZWQgaW4gaXRzIHBs
YWNlLgorICAgICAqCisgICAgICogLSBNYXJjaCAyMDIzLCBmb3IgUkZEUy4g
IEVudW1lcmF0ZSBSRkRTX0NMRUFSIHRvIG1lYW4gdGhhdCBWRVJXIG5vdwor
ICAgICAqICAgc2NydWJzIG5vbi1hcmNoaXRlY3R1cmFsIGVudHJpZXMgZnJv
bSBjZXJ0YWluIHJlZ2lzdGVyIGZpbGVzLgogICAgICAqLwogICAgIG1kc19j
YWxjdWxhdGlvbnMoKTsKKyAgICByZmRzX2NhbGN1bGF0aW9ucygpOwogCiAg
ICAgLyoKICAgICAgKiBQYXJ0cyB3aGljaCBlbnVtZXJhdGUgRkJfQ0xFQVIg
YXJlIHRob3NlIHdpdGggbm93LXVwZGF0ZWQgbWljcm9jb2RlCkBAIC0xOTIy
LDE1ICsyMDA3LDE5IEBAIHZvaWQgX19pbml0IGluaXRfc3BlY3VsYXRpb25f
bWl0aWdhdGlvbnModm9pZCkKICAgICAgKiBNTFBEUy9NRkJEUyB3aGVuIFNN
VCBpcyBlbmFibGVkLgogICAgICAqLwogICAgIGlmICggb3B0X3ZlcndfcHYg
PT0gLTEgKQotICAgICAgICBvcHRfdmVyd19wdiA9IGNwdV9oYXNfdXNlZnVs
X21kX2NsZWFyOworICAgICAgICBvcHRfdmVyd19wdiA9IGNwdV9oYXNfdXNl
ZnVsX21kX2NsZWFyIHx8IGNwdV9oYXNfcmZkc19jbGVhcjsKIAogICAgIGlm
ICggb3B0X3ZlcndfaHZtID09IC0xICkKLSAgICAgICAgb3B0X3ZlcndfaHZt
ID0gY3B1X2hhc191c2VmdWxfbWRfY2xlYXI7CisgICAgICAgIG9wdF92ZXJ3
X2h2bSA9IGNwdV9oYXNfdXNlZnVsX21kX2NsZWFyIHx8IGNwdV9oYXNfcmZk
c19jbGVhcjsKIAogICAgIC8qCiAgICAgICogSWYgU01UIGlzIGFjdGl2ZSwg
YW5kIHdlJ3JlIHByb3RlY3RpbmcgYWdhaW5zdCBNRFMgb3IgTU1JTyBzdGFs
ZSBkYXRhLAogICAgICAqIHdlIG5lZWQgdG8gc2NydWIgYmVmb3JlIGdvaW5n
IGlkbGUgYXMgd2VsbCBhcyBvbiByZXR1cm4gdG8gZ3Vlc3QuCiAgICAgICog
VmFyaW91cyBwaXBlbGluZSByZXNvdXJjZXMgYXJlIHJlcGFydGl0aW9uZWQg
YW1vbmdzdCBub24taWRsZSB0aHJlYWRzLgorICAgICAqCisgICAgICogV2Ug
ZG9uJ3QgbmVlZCB0byBzY3J1YiBvbiBpZGxlIGZvciBSRkRTLiAgVGhlcmUg
YXJlIG5vIGFmZmVjdGVkIGNvcmVzCisgICAgICogd2hpY2ggc3VwcG9ydCBT
TVQsIGRlc3BpdGUgdGhlcmUgYmVpbmcgYWZmZWN0ZWQgY29yZXMgaW4gaHli
cmlkIHN5c3RlbXMKKyAgICAgKiB3aGljaCBoYXZlIFNNVCBlbHNld2hlcmUg
aW4gdGhlIHBsYXRmb3JtLgogICAgICAqLwogICAgIGlmICggKChjcHVfaGFz
X3VzZWZ1bF9tZF9jbGVhciAmJiAob3B0X3ZlcndfcHYgfHwgb3B0X3Zlcndf
aHZtKSkgfHwKICAgICAgICAgICBvcHRfdmVyd19tbWlvKSAmJiBod19zbXRf
ZW5hYmxlZCApCkBAIC0xOTQ0LDcgKzIwMzMsOCBAQCB2b2lkIF9faW5pdCBp
bml0X3NwZWN1bGF0aW9uX21pdGlnYXRpb25zKHZvaWQpCiAgICAgICogSXQg
aXMgb25seSBzYWZlIHRvIHVzZSBMMURfRkxVU0ggaW4gcGxhY2Ugb2YgVkVS
VyB3aGVuIE1EX0NMRUFSIGlzIHRoZQogICAgICAqIG9ubHkgKl9DTEVBUiB3
ZSBjYW4gc2VlLgogICAgICAqLwotICAgIGlmICggb3B0X2wxZF9mbHVzaCAm
JiBjcHVfaGFzX21kX2NsZWFyICYmICFjcHVfaGFzX2ZiX2NsZWFyICkKKyAg
ICBpZiAoIG9wdF9sMWRfZmx1c2ggJiYgY3B1X2hhc19tZF9jbGVhciAmJiAh
Y3B1X2hhc19mYl9jbGVhciAmJgorICAgICAgICAgIWNwdV9oYXNfcmZkc19j
bGVhciApCiAgICAgICAgIG9wdF92ZXJ3X2h2bSA9IGZhbHNlOwogCiAgICAg
LyoKZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL3B1YmxpYy9hcmNoLXg4Ni9j
cHVmZWF0dXJlc2V0LmggYi94ZW4vaW5jbHVkZS9wdWJsaWMvYXJjaC14ODYv
Y3B1ZmVhdHVyZXNldC5oCmluZGV4IDAzNzRjZWMzYTJhZi4uZWI5ZjU1Mjk0
OGJlIDEwMDY0NAotLS0gYS94ZW4vaW5jbHVkZS9wdWJsaWMvYXJjaC14ODYv
Y3B1ZmVhdHVyZXNldC5oCisrKyBiL3hlbi9pbmNsdWRlL3B1YmxpYy9hcmNo
LXg4Ni9jcHVmZWF0dXJlc2V0LmgKQEAgLTI2Niw2ICsyNjYsNyBAQCBYRU5f
Q1BVRkVBVFVSRShNRF9DTEVBUiwgICAgICA5KjMyKzEwKSAvKiFBIFZFUlcg
Y2xlYXJzIG1pY3JvYXJjaGl0ZWN0dXJhbCBidWZmZQogWEVOX0NQVUZFQVRV
UkUoUlRNX0FMV0FZU19BQk9SVCwgOSozMisxMSkgLyohIEp1bmUgMjAyMSBU
U1ggZGVmZWF0dXJpbmcgaW4gbWljcm9jb2RlLiAqLwogWEVOX0NQVUZFQVRV
UkUoVFNYX0ZPUkNFX0FCT1JULCA5KjMyKzEzKSAvKiBNU1JfVFNYX0ZPUkNF
X0FCT1JULlJUTV9BQk9SVCAqLwogWEVOX0NQVUZFQVRVUkUoU0VSSUFMSVpF
LCAgICAgOSozMisxNCkgLypBICBTRVJJQUxJWkUgaW5zbiAqLworWEVOX0NQ
VUZFQVRVUkUoSFlCUklELCAgICAgICAgOSozMisxNSkgLyogICBIZXRlcm9n
ZW5lb3VzIHBsYXRmb3JtICovCiBYRU5fQ1BVRkVBVFVSRShUU1hMRFRSSywg
ICAgICA5KjMyKzE2KSAvKmEgIFRTWCBsb2FkIHRyYWNraW5nIHN1c3BlbmQv
cmVzdW1lIGluc25zICovCiBYRU5fQ1BVRkVBVFVSRShDRVRfSUJULCAgICAg
ICA5KjMyKzIwKSAvKiAgIENFVCAtIEluZGlyZWN0IEJyYW5jaCBUcmFja2lu
ZyAqLwogWEVOX0NQVUZFQVRVUkUoQVZYNTEyX0ZQMTYsICAgOSozMisyMykg
LypBICBBVlg1MTIgRlAxNiBpbnN0cnVjdGlvbnMgKi8KQEAgLTM0Myw2ICsz
NDQsOCBAQCBYRU5fQ1BVRkVBVFVSRShPVlJDTEtfU1RBVFVTLCAgICAgIDE2
KjMyKzIzKSAvKiAgIE1TUl9PVkVSQ0xPQ0tJTkdfU1RBVFVTICovCiBYRU5f
Q1BVRkVBVFVSRShQQlJTQl9OTywgICAgICAgICAgIDE2KjMyKzI0KSAvKkEg
IE5vIFBvc3QtQmFycmllciBSU0IgcHJlZGljdGlvbnMgKi8KIFhFTl9DUFVG
RUFUVVJFKEdEU19DVFJMLCAgICAgICAgICAgMTYqMzIrMjUpIC8qICAgTUNV
X09QVF9DVFJMLkdEU19NSVRfe0RJUyxMT0NLfSAqLwogWEVOX0NQVUZFQVRV
UkUoR0RTX05PLCAgICAgICAgICAgICAxNiozMisyNikgLypBICBObyBHYXRo
ZXIgRGF0YSBTYW1wbGluZyAqLworWEVOX0NQVUZFQVRVUkUoUkZEU19OTywg
ICAgICAgICAgICAxNiozMisyNykgLypBICBObyBSZWdpc3RlciBGaWxlIERh
dGEgU2FtcGxpbmcgKi8KK1hFTl9DUFVGRUFUVVJFKFJGRFNfQ0xFQVIsICAg
ICAgICAgMTYqMzIrMjgpIC8qIUEgUmVnaXN0ZXIgRmlsZShzKSBjbGVhcmVk
IGJ5IFZFUlcgKi8KIAogLyogSW50ZWwtZGVmaW5lZCBDUFUgZmVhdHVyZXMs
IE1TUl9BUkNIX0NBUFMgMHgxMGEuZWR4LCB3b3JkIDE3ICovCiAK

--=separator--


From xen-devel-bounces@lists.xenproject.org Tue Mar 12 17:06:48 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Mar 2024 17:06:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.691970.1078651 (Exim 4.92)
	(envelope-from )
	id 1rk5aO-0004id-CH; Tue, 12 Mar 2024 17:06:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 691970.1078651; Tue, 12 Mar 2024 17:06:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rk5aO-0004hQ-6d; Tue, 12 Mar 2024 17:06:44 +0000
Received: by outflank-mailman (input) for mailman id 691970;
 Tue, 12 Mar 2024 17:06:43 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rk5aL-0004Yy-TR
 for xen-devel@lists.xen.org; Tue, 12 Mar 2024 17:06:42 +0000
Received: from mail.xenproject.org (mail.xenproject.org [104.130.215.37])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e2f3c2fc-e092-11ee-afdd-a90da7624cb6;
 Tue, 12 Mar 2024 18:06:39 +0100 (CET)
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rk5a7-00077D-R5; Tue, 12 Mar 2024 17:06:27 +0000
Received: from andrewcoop by xenbits.xenproject.org with local (Exim 4.92)
 (envelope-from )
 id 1rk5a7-0008Qz-OY; Tue, 12 Mar 2024 17:06:27 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e2f3c2fc-e092-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Date:Message-Id:Subject:CC:From:To:MIME-Version:
	Content-Transfer-Encoding:Content-Type;
	bh=8ASE/QZGxd28DjJDHcatIXXcGH1fKcZbhPHKN/iJTZ4=; b=tqV6/UvUnXhlYrsuz/GkaXoc+X
	lr3Fkmb8XKBE2pWVd9IucW7WlyitwxJtI8CvyhB/DIWN7OyQG+Smgblc7pyStYjo4aGxir6yaXnyZ
	SUACbSNliMceXMd5MbE90C1nUWIIE135g9v9b9bK2C6hR/yphI8XEDoQHSMyEKi9p1UM=;
Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.509 (Entity 5.509)
To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
 xen-users@lists.xen.org, oss-security@lists.openwall.com
From: Xen.org security team 
CC: Xen.org security team 
Subject: Xen Security Advisory 453 v1 (CVE-2024-2193) - GhostRace:
 Speculative Race Conditions
Message-Id: 
Date: Tue, 12 Mar 2024 17:06:27 +0000

--=separator
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

            Xen Security Advisory CVE-2024-2193 / XSA-453

                GhostRace: Speculative Race Conditions

ISSUE DESCRIPTION
=================

Researchers at VU Amsterdam and IBM Research have discovered GhostRace;
an analysis of the behaviour of synchronisation primitives under
speculative execution.

Synchronisation primitives are typically formed as an unbounded loop
which waits until a resource is available to be accessed.  This means
there is a conditional branch which can be microarchitecturally bypassed
using Spectre-v1 techniques, allowing an attacker to speculatively
execute critical regions.

Therefore, while a critical region might be safe architecturally, it can
still suffer from data races under speculation with unsafe consequences.

The GhostRace paper focuses on Speculative Concurrent Use-After-Free
issues, but notes that there are many other types of speculative data
hazard to be explored.

For more details, see:
  https://vusec.net/projects/ghostrace

IMPACT
======

An attacker might be able to infer the contents of arbitrary host
memory, including memory assigned to other guests.

VULNERABLE SYSTEMS
==================

Systems running all versions of Xen are affected.

GhostRace is a variation of Spectre-v1, and Spectre-v1 is known to
affect a wide range of CPU architectures and designs.  Consult your
hardware vendor.

However, Xen does not have any known gadgets vulnerable to GhostRace at
the time of writing.

Furthermore, even with the vulnerable instance found in Linux, the
researchers had to insert an artificial syscall to make the instance
more accessible to a userspace attacker.

Therefore, The Xen Security Team does not believe that immediate action
is required.

MITIGATION
==========

There are no mitigations.

RESOLUTION
==========

Out of caution, the Xen Security Team have provided hardening patches
including the addition of a new LOCK_HARDEN mechanism on x86 similar to
the existing BRANCH_HARDEN.

LOCK_HARDEN is off by default, owing to the uncertainty of there being a
vulnerability under Xen, and uncertainty over the performance impact.

However, we expect more research to happen in this area, and feel it is
prudent to have a mitigation in place.

Note that patches for released versions are generally prepared to
apply to the stable branches, and may not apply cleanly to the most
recent release tarball.  Downstreams are encouraged to update to the
tip of the stable branch before applying these patches.

xsa453/xsa453-?.patch           xen-unstable
xsa453/xsa453-4.18-?.patch      Xen 4.18.x
xsa453/xsa453-4.17-?.patch      Xen 4.17.x
xsa453/xsa453-4.16-?.patch      Xen 4.16.x
xsa453/xsa453-4.15-?.patch      Xen 4.15.x

$ sha256sum xsa453*/*
5487c6595b114187191e09bc5d7510d228a018ca98bc43ef58f8225fbd843636  xsa453/xsa453-1.patch
1d4ae5ce07f6869dbc20342289d8a00937868014b1c8a69054815cce7a836761  xsa453/xsa453-2.patch
a873074149a74ce1f6252cdaa20e5432930f77caf59cf328ce6c2e0b000e1f3b  xsa453/xsa453-3.patch
12b3e60005f50df1b7050984f0b7545eadc5e99425dae3b4d186c67a4caaeee4  xsa453/xsa453-4.15-1.patch
0b242be1d3fa0c4bcbb3e7755c0267ec6d307c75eec2e7348d8405017af0ab06  xsa453/xsa453-4.15-2.patch
2d17d1586e4b20a5c7677c3ab4553971251c123570c05d1adfede671f5e1d501  xsa453/xsa453-4.15-3.patch
8d209d1c9d3585bd190f9c97d866ff30ef18514ebf874869e5881b5856d3b81e  xsa453/xsa453-4.15-4.patch
350dbcb1f22874f5545936c307a69ae8acd8eef5f24dfccfe2ba2d1e8997c14d  xsa453/xsa453-4.15-5.patch
334fe9512a90c84210a010d9aff82b96eac00d9beb8291a243339e5ca9fb69c2  xsa453/xsa453-4.15-6.patch
bc3781df298eba4b306b742a8b06869eb83c5619a4dd3ae0ddd746a96708e3ea  xsa453/xsa453-4.15-7.patch
b8f0798863f70c65b20809f6749ef17e098f74e944386a7c8199396a7aab7295  xsa453/xsa453-4.15-8.patch
85c66b0f6fad0df2a705a48f75506142cacdf39bab1b68bb22ce4924d3ddae1c  xsa453/xsa453-4.16-1.patch
35416e86df8b55e0d165edef33557d3232c6c7b56ea36fb12278242134279fae  xsa453/xsa453-4.16-2.patch
1f6f09b860d7dc4add0356dd544d85faab6750a5dc72d15438e77322498c0d39  xsa453/xsa453-4.16-3.patch
8d209d1c9d3585bd190f9c97d866ff30ef18514ebf874869e5881b5856d3b81e  xsa453/xsa453-4.16-4.patch
350dbcb1f22874f5545936c307a69ae8acd8eef5f24dfccfe2ba2d1e8997c14d  xsa453/xsa453-4.16-5.patch
f03fba4192ec375220557c6488986c4bb0acb130fcdc61c0a3fe7bb48ffeaf98  xsa453/xsa453-4.16-6.patch
702330fe49015e174fac88cc290cc4ba78af97cc27ca6ac6d612a7f3de264ca1  xsa453/xsa453-4.16-7.patch
cc25536abac03b92a3486df8db4a89aecb8447aa1d31870def4ebf90782017df  xsa453/xsa453-4.16-8.patch
9b0e67756cb0f98721f748f76b767da88cad22969bf32052f9171e0260c8c596  xsa453/xsa453-4.17-1.patch
1cde6cae3738a380d35b769d44344d8e92585d9f4f8bccff1cae933b3d7dd5c8  xsa453/xsa453-4.17-2.patch
dbd117b3482ff24b146ee4936a691ed796ae073abd1c66db5cb5b5ede04c82ea  xsa453/xsa453-4.17-3.patch
00f78778eb392aeda13803bb321d255335fea27abd3beb8fcc70a49ce81fcb3c  xsa453/xsa453-4.17-4.patch
9bad3d96b74ceb9ce6232d4b4e434f7a023ad6ed31f6ff074869e037f6b296c6  xsa453/xsa453-4.17-5.patch
d62b1014347fcb7b6575fe0a1145b358719154655afd007a36739f6fe10cb4d6  xsa453/xsa453-4.17-6.patch
ba6597f3bf859ae38eef675e3540fc8f79dd2a672486c0fbe31a5740cafeffcd  xsa453/xsa453-4.17-7.patch
eb92c317c367689e401d20ce9ff2e5e5b5c551bc8f36424012ccc71c3df240e3  xsa453/xsa453-4.17-8.patch
70334588834939d8e06f0ec3edec2f0e10c1fc5af11aac01a71e6c78075f7352  xsa453/xsa453-4.18-1.patch
7960863a4917ae994a20c5dcd93f080b328749ef24108a5ec436b4a32ff12f07  xsa453/xsa453-4.18-2.patch
57306cbd89f4dc6c65ad89f3a7fedf3b84ebd28f423b54de8a18d8bc247bfbc5  xsa453/xsa453-4.18-3.patch
6280c40626e8d190e4c7216d7574be2bcf5a8143509640a6241706c21fdc3336  xsa453/xsa453-4.18-4.patch
cc9206b7bde3748b3ac58c338f1b233aae25be91fa1a56442e54030037188509  xsa453/xsa453-4.18-5.patch
12ddaedad54794bf7f64b4954e167dca92bfa53a658f3eeec9bd93ce282eee65  xsa453/xsa453-4.18-6.patch
86d1972ca5a01167d4f8da28256e2183227e7d1d0e5245dc85521b260299c64e  xsa453/xsa453-4.18-7.patch
0feec9819a74ab61664e31fff1a0df4b1fe4145fd62fcd5ca7dfc6566f9f938c  xsa453/xsa453-4.patch
9c22f02fe450fc5a05121040f8137b2755c2d196b0a777643587a166ab29a5e6  xsa453/xsa453-5.patch
ef4312c837f6e295796c1bc9a70f5ae27ac846e7149694c9c1f13b10e2b92945  xsa453/xsa453-6.patch
e7b8750f00c9d2018b4c43cceaf931837ea84ee2a8bf40aaf694e1f2f13c7ef1  xsa453/xsa453-7.patch
$

NOTE ABOUT IPI LIVELOCK
=======================

A observation from the GhostRace paper, unrelated to speculation, is the
ability of userspace to livelock the kernel with IPIs.  While the
GhostRace paper is specific to Linux, similar primitives exist for guest
kernels.

However, after analysis and experimentation, The Xen Security Team are
not aware of a way for a guest kernel to mount a similar attack against
Xen.
-----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmXwhb8MHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZWrEH/jb7eEkcdFGvVFvuBbU4dNrEx61eql7LdHjbvLg+
8PkdhjRafl3h766tqilbZiF+ZhM/HmV3i+5t7x6+HhsO59eMuWLghVC1woy0H6VI
QSVAio918183Z7HogcSBw1Z1dFup7rTX3aX9hi/TLARN0VY1mxH3hmxJ7iNYsBHw
mLjgcRXj+aM7iRmIMveWAJD39UU9KVV4F2jDaJl+ay2vH5dwrtlKMdI7Yv9lY45P
USAZxWQJ35ifpZtVTN6C38LzkHPJRvpZib7K+DnfIAaZIwWr10ZSjS+LxK+UMaYJ
fejYte+ki40uS0E7AhlesBSQb7C6qDM8GJbMtwj6en5LN14=
=V/0y
-----END PGP SIGNATURE-----

--=separator
Content-Type: application/octet-stream; name="xsa453/xsa453-1.patch"
Content-Disposition: attachment; filename="xsa453/xsa453-1.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeGVuOiBTd2FwIG9yZGVyIG9mIGFjdGlvbnMgaW4gdGhl
IEZSRUUqKCkgbWFjcm9zCgpXaGVyZXZlciBwb3NzaWJsZSwgaXQgaXMgYSBn
b29kIGlkZWEgdG8gTlVMTCBvdXQgdGhlIHZpc2libGUgcmVmZXJlbmNlIHRv
IGFuCm9iamVjdCBwcmlvciB0byBmcmVlaW5nIGl0LiAgVGhlIEZSRUUqKCkg
bWFjcm9zIGFscmVhZHkgY29sbGVjdCB0b2dldGhlciBib3RoCnBhcnRzLCBt
YWtpbmcgaXQgZWFzeSB0byBhZGp1c3QuCgpUaGlzIGhhcyBhIG1hcmdpbmFs
IGNvZGUgZ2VuZXJhdGlvbiBpbXByb3ZlbWVudCwgYXMgc29tZSBvZiB0aGUg
Y2FsbHMgdG8gdGhlCmZyZWUoKSBmdW5jdGlvbiBjYW4gYmUgdGFpbGNhbGwg
b3B0aW1pc2VkLgoKTm8gZnVuY3Rpb25hbCBjaGFuZ2UuCgpTaWduZWQtb2Zm
LWJ5OiBBbmRyZXcgQ29vcGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29t
PgpBY2tlZC1ieTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgoK
ZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL3hlbi9tbS5oIGIveGVuL2luY2x1
ZGUveGVuL21tLmgKaW5kZXggYmIyOWIzNTJlYzA2Li4zZTg0OTYwYTM2NWYg
MTAwNjQ0Ci0tLSBhL3hlbi9pbmNsdWRlL3hlbi9tbS5oCisrKyBiL3hlbi9p
bmNsdWRlL3hlbi9tbS5oCkBAIC05Myw4ICs5Myw5IEBAIGJvb2wgc2NydWJf
ZnJlZV9wYWdlcyh2b2lkKTsKIAogLyogRnJlZSBhbiBhbGxvY2F0aW9uLCBh
bmQgemVybyB0aGUgcG9pbnRlciB0byBpdC4gKi8KICNkZWZpbmUgRlJFRV9Y
RU5IRUFQX1BBR0VTKHAsIG8pIGRvIHsgXAotICAgIGZyZWVfeGVuaGVhcF9w
YWdlcyhwLCBvKTsgICAgICAgICBcCisgICAgdm9pZCAqX3B0cl8gPSAocCk7
ICAgICAgICAgICAgICAgIFwKICAgICAocCkgPSBOVUxMOyAgICAgICAgICAg
ICAgICAgICAgICAgXAorICAgIGZyZWVfeGVuaGVhcF9wYWdlcyhfcHRyXywg
byk7ICAgICBcCiB9IHdoaWxlICggZmFsc2UgKQogI2RlZmluZSBGUkVFX1hF
TkhFQVBfUEFHRShwKSBGUkVFX1hFTkhFQVBfUEFHRVMocCwgMCkKIApkaWZm
IC0tZ2l0IGEveGVuL2luY2x1ZGUveGVuL3htYWxsb2MuaCBiL3hlbi9pbmNs
dWRlL3hlbi94bWFsbG9jLmgKaW5kZXggOWVjZGRiZmY1ZTAwLi4xYjg4YTgz
YmU4NzkgMTAwNjQ0Ci0tLSBhL3hlbi9pbmNsdWRlL3hlbi94bWFsbG9jLmgK
KysrIGIveGVuL2luY2x1ZGUveGVuL3htYWxsb2MuaApAQCAtNjYsOSArNjYs
MTAgQEAKIGV4dGVybiB2b2lkIHhmcmVlKHZvaWQgKnApOwogCiAvKiBGcmVl
IGFuIGFsbG9jYXRpb24sIGFuZCB6ZXJvIHRoZSBwb2ludGVyIHRvIGl0LiAq
LwotI2RlZmluZSBYRlJFRShwKSBkbyB7IFwKLSAgICB4ZnJlZShwKTsgICAg
ICAgICBcCi0gICAgKHApID0gTlVMTDsgICAgICAgXAorI2RlZmluZSBYRlJF
RShwKSBkbyB7ICAgICAgICAgICAgICAgICAgICAgICBcCisgICAgdm9pZCAq
X3B0cl8gPSAocCk7ICAgICAgICAgICAgICAgICAgICAgIFwKKyAgICAocCkg
PSBOVUxMOyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAorICAgIHhm
cmVlKF9wdHJfKTsgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiB9IHdo
aWxlICggZmFsc2UgKQogCiAvKiBVbmRlcmx5aW5nIGZ1bmN0aW9ucyAqLwoK

--=separator
Content-Type: application/octet-stream; name="xsa453/xsa453-2.patch"
Content-Disposition: attachment; filename="xsa453/xsa453-2.patch"
Content-Transfer-Encoding: base64

RnJvbTogPT9VVEYtOD9xP1JvZ2VyPTIwUGF1PTIwTW9ubj1DMz1BOT89IDxy
b2dlci5wYXVAY2l0cml4LmNvbT4KU3ViamVjdDogeDg2L3NwaW5sb2NrOiBp
bnRyb2R1Y2Ugc3VwcG9ydCBmb3IgYmxvY2tpbmcgc3BlY3VsYXRpb24gaW50
bwogY3JpdGljYWwgcmVnaW9ucwoKSW50cm9kdWNlIGEgbmV3IEtjb25maWcg
b3B0aW9uIHRvIGJsb2NrIHNwZWN1bGF0aW9uIGludG8gbG9jayBwcm90ZWN0
ZWQKY3JpdGljYWwgcmVnaW9ucy4gIFRoZSBLY29uZmlnIG9wdGlvbiBpcyBl
bmFibGVkIGJ5IGRlZmF1bHQsIGJ1dCB0aGUgbWl0aWdhdGlvbgp3b24ndCBi
ZSBlbmdhZ2VkIHVubGVzcyBpdCdzIGV4cGxpY2l0bHkgZW5hYmxlZCBpbiB0
aGUgY29tbWFuZCBsaW5lIHVzaW5nCmBzcGVjLWN0cmw9bG9jay1oYXJkZW5g
LgoKQ29udmVydCB0aGUgc3BpbmxvY2sgYWNxdWlyZSBtYWNyb3MgaW50byBh
bHdheXMtaW5saW5lIGZ1bmN0aW9ucywgYW5kIGludHJvZHVjZQphIHNwZWN1
bGF0aW9uIGJhcnJpZXIgYWZ0ZXIgdGhlIGxvY2sgaGFzIGJlZW4gdGFrZW4u
ICBOb3RlIHRoZSBzcGVjdWxhdGlvbgpiYXJyaWVyIGlzIG5vdCBwbGFjZWQg
aW5zaWRlIHRoZSBpbXBsZW1lbnRhdGlvbiBvZiB0aGUgc3BpbiBsb2NrIGZ1
bmN0aW9ucywgYXMKdG8gcHJldmVudCBzcGVjdWxhdGlvbiBmcm9tIGZhbGxp
bmcgdGhyb3VnaCB0aGUgY2FsbCB0byB0aGUgbG9jayBmdW5jdGlvbnMKcmVz
dWx0aW5nIGluIHRoZSBiYXJyaWVyIGFsc28gYmVpbmcgc2tpcHBlZC4KCnRy
eWxvY2sgdmFyaWFudHMgYXJlIHByb3RlY3RlZCB1c2luZyBhIGNvbnN0cnVj
dCBha2luIHRvIHRoZSBleGlzdGluZwpldmFsdWF0ZV9ub3NwZWMoKS4KClRo
aXMgcGF0Y2ggb25seSBpbXBsZW1lbnRzIHRoZSBzcGVjdWxhdGlvbiBiYXJy
aWVyIGZvciB4ODYuCgpOb3RlIHNwaW4gbG9ja3MgYXJlIHRoZSBvbmx5IGxv
Y2tpbmcgcHJpbWl0aXZlIHRha2VuIGNhcmUgaW4gdGhpcyBjaGFuZ2UsCmZ1
cnRoZXIgbG9ja2luZyBwcmltaXRpdmVzIHdpbGwgYmUgYWRqdXN0ZWQgYnkg
c2VwYXJhdGUgY2hhbmdlcy4KClRoaXMgaXMgcGFydCBvZiBYU0EtNDUzIC8g
Q1ZFLTIwMjQtMjE5MwoKU2lnbmVkLW9mZi1ieTogUm9nZXIgUGF1IE1vbm7D
qSA8cm9nZXIucGF1QGNpdHJpeC5jb20+ClJldmlld2VkLWJ5OiBKYW4gQmV1
bGljaCA8amJldWxpY2hAc3VzZS5jb20+CgpkaWZmIC0tZ2l0IGEvZG9jcy9t
aXNjL3hlbi1jb21tYW5kLWxpbmUucGFuZG9jIGIvZG9jcy9taXNjL3hlbi1j
b21tYW5kLWxpbmUucGFuZG9jCmluZGV4IGE1NGQ3NzUyOGFlOS4uNTRlZGJj
MGZiYzFhIDEwMDY0NAotLS0gYS9kb2NzL21pc2MveGVuLWNvbW1hbmQtbGlu
ZS5wYW5kb2MKKysrIGIvZG9jcy9taXNjL3hlbi1jb21tYW5kLWxpbmUucGFu
ZG9jCkBAIC0yMzY2LDcgKzIzNjYsNyBAQCBCeSBkZWZhdWx0IFNTQkQgd2ls
bCBiZSBtaXRpZ2F0ZWQgYXQgcnVudGltZSAoaS5lIGBzc2JkPXJ1bnRpbWVg
KS4KID4gICAgICAgICAgICAgIHttc3Itc2MscnNiLHZlcncsaWJwYi1lbnRy
eX09PGJvb2w+fHtwdixodm19PTxib29sPiwKID4gICAgICAgICAgICAgIGJ0
aS10aHVuaz1yZXRwb2xpbmV8bGZlbmNlfGptcCwge2licnMsaWJwYixzc2Jk
LHBzZmQsCiA+ICAgICAgICAgICAgICBlYWdlci1mcHUsbDFkLWZsdXNoLGJy
YW5jaC1oYXJkZW4sc3JiLWxvY2ssCi0+ICAgICAgICAgICAgICB1bnByaXYt
bW1pbyxnZHMtbWl0LGRpdi1zY3J1Yn09PGJvb2w+IF1gCis+ICAgICAgICAg
ICAgICB1bnByaXYtbW1pbyxnZHMtbWl0LGRpdi1zY3J1Yixsb2NrLWhhcmRl
bn09PGJvb2w+IF1gCiAKIENvbnRyb2xzIGZvciBzcGVjdWxhdGl2ZSBleGVj
dXRpb24gc2lkZWNoYW5uZWwgbWl0aWdhdGlvbnMuICBCeSBkZWZhdWx0LCBY
ZW4KIHdpbGwgcGljayB0aGUgbW9zdCBhcHByb3ByaWF0ZSBtaXRpZ2F0aW9u
cyBiYXNlZCBvbiBjb21waWxlZCBpbiBzdXBwb3J0LApAQCAtMjQ5Myw2ICsy
NDkzLDExIEBAIE9uIGFsbCBoYXJkd2FyZSwgdGhlIGBkaXYtc2NydWI9YCBv
cHRpb24gY2FuIGJlIHVzZWQgdG8gZm9yY2Ugb3IgcHJldmVudCBYZW4KIGZy
b20gbWl0aWdhdGluZyB0aGUgRElWLWxlYWthZ2UgdnVsbmVyYWJpbGl0eS4g
IEJ5IGRlZmF1bHQsIFhlbiB3aWxsIG1pdGlnYXRlCiBESVYtbGVha2FnZSBv
biBoYXJkd2FyZSBiZWxpZXZlZCB0byBiZSB2dWxuZXJhYmxlLgogCitJZiBY
ZW4gaXMgY29tcGlsZWQgd2l0aCBgQ09ORklHX1NQRUNVTEFUSVZFX0hBUkRF
Tl9MT0NLYCwgdGhlIGBsb2NrLWhhcmRlbj1gCitib29sZWFuIGNhbiBiZSB1
c2VkIHRvIGZvcmNlIG9yIHByZXZlbnQgWGVuIGZyb20gdXNpbmcgc3BlY3Vs
YXRpb24gYmFycmllcnMgdG8KK3Byb3RlY3QgbG9jayBjcml0aWNhbCByZWdp
b25zLiAgVGhpcyBtaXRpZ2F0aW9uIHdvbid0IGJlIGVuZ2FnZWQgYnkgZGVm
YXVsdCwKK2FuZCBuZWVkcyB0byBiZSBleHBsaWNpdGx5IGVuYWJsZWQgb24g
dGhlIGNvbW1hbmQgbGluZS4KKwogIyMjIHN5bmNfY29uc29sZQogPiBgPSA8
Ym9vbGVhbj5gCiAKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9pbmNsdWRl
L2FzbS9jcHVmZWF0dXJlcy5oIGIveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNt
L2NwdWZlYXR1cmVzLmgKaW5kZXggYzNhYWQyMWMzYjQzLi43ZTgyMjFmZDg1
ZGQgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9jcHVm
ZWF0dXJlcy5oCisrKyBiL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9jcHVm
ZWF0dXJlcy5oCkBAIC0yNCw3ICsyNCw3IEBAIFhFTl9DUFVGRUFUVVJFKEFQ
RVJGTVBFUkYsICAgICAgICBYODZfU1lOVEgoIDgpKSAvKiBBUEVSRk1QRVJG
ICovCiBYRU5fQ1BVRkVBVFVSRShNRkVOQ0VfUkRUU0MsICAgICAgWDg2X1NZ
TlRIKCA5KSkgLyogTUZFTkNFIHN5bmNocm9uaXplcyBSRFRTQyAqLwogWEVO
X0NQVUZFQVRVUkUoWEVOX1NNRVAsICAgICAgICAgIFg4Nl9TWU5USCgxMCkp
IC8qIFNNRVAgZ2V0cyB1c2VkIGJ5IFhlbiBpdHNlbGYgKi8KIFhFTl9DUFVG
RUFUVVJFKFhFTl9TTUFQLCAgICAgICAgICBYODZfU1lOVEgoMTEpKSAvKiBT
TUFQIGdldHMgdXNlZCBieSBYZW4gaXRzZWxmICovCi0vKiBCaXQgMTIgdW51
c2VkLiAqLworWEVOX0NQVUZFQVRVUkUoU0NfTk9fTE9DS19IQVJERU4sIFg4
Nl9TWU5USCgxMikpIC8qIChEaXNhYmxlKSBMb2NrIGNyaXRpY2FsIHJlZ2lv
biBoYXJkZW5pbmcgKi8KIFhFTl9DUFVGRUFUVVJFKElORF9USFVOS19MRkVO
Q0UsICBYODZfU1lOVEgoMTMpKSAvKiBVc2UgSU5EX1RIVU5LX0xGRU5DRSAq
LwogWEVOX0NQVUZFQVRVUkUoSU5EX1RIVU5LX0pNUCwgICAgIFg4Nl9TWU5U
SCgxNCkpIC8qIFVzZSBJTkRfVEhVTktfSk1QICovCiBYRU5fQ1BVRkVBVFVS
RShTQ19OT19CUkFOQ0hfSEFSREVOLCBYODZfU1lOVEgoMTUpKSAvKiAoRGlz
YWJsZSkgQ29uZGl0aW9uYWwgYnJhbmNoIGhhcmRlbmluZyAqLwpkaWZmIC0t
Z2l0IGEveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL25vc3BlYy5oIGIveGVu
L2FyY2gveDg2L2luY2x1ZGUvYXNtL25vc3BlYy5oCmluZGV4IDA3NjA2ODM0
YzRjOS4uZTA1OGEzYmIwZTYxIDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYv
aW5jbHVkZS9hc20vbm9zcGVjLmgKKysrIGIveGVuL2FyY2gveDg2L2luY2x1
ZGUvYXNtL25vc3BlYy5oCkBAIC02Miw2ICs2MiwzMiBAQCBzdGF0aWMgaW5s
aW5lIHVuc2lnbmVkIGxvbmcgYXJyYXlfaW5kZXhfbWFza19ub3NwZWModW5z
aWduZWQgbG9uZyBpbmRleCwKIC8qIE92ZXJyaWRlIGRlZmF1bHQgaW1wbGVt
ZW50YXRpb24gaW4gbm9zcGVjLmguICovCiAjZGVmaW5lIGFycmF5X2luZGV4
X21hc2tfbm9zcGVjIGFycmF5X2luZGV4X21hc2tfbm9zcGVjCiAKK3N0YXRp
YyBhbHdheXNfaW5saW5lIHZvaWQgYXJjaF9ibG9ja19sb2NrX3NwZWN1bGF0
aW9uKHZvaWQpCit7CisgICAgYWx0ZXJuYXRpdmUoImxmZW5jZSIsICIiLCBY
ODZfRkVBVFVSRV9TQ19OT19MT0NLX0hBUkRFTik7Cit9CisKKy8qIEFsbG93
IHRvIGluc2VydCBhIHJlYWQgbWVtb3J5IGJhcnJpZXIgaW50byBjb25kaXRp
b25hbHMgKi8KK3N0YXRpYyBhbHdheXNfaW5saW5lIGJvb2wgYmFycmllcl9s
b2NrX3RydWUodm9pZCkKK3sKKyAgICBhbHRlcm5hdGl2ZSgibGZlbmNlICNu
b3NwZWMtdHJ1ZSIsICIiLCBYODZfRkVBVFVSRV9TQ19OT19MT0NLX0hBUkRF
Tik7CisgICAgcmV0dXJuIHRydWU7Cit9CisKK3N0YXRpYyBhbHdheXNfaW5s
aW5lIGJvb2wgYmFycmllcl9sb2NrX2ZhbHNlKHZvaWQpCit7CisgICAgYWx0
ZXJuYXRpdmUoImxmZW5jZSAjbm9zcGVjLWZhbHNlIiwgIiIsIFg4Nl9GRUFU
VVJFX1NDX05PX0xPQ0tfSEFSREVOKTsKKyAgICByZXR1cm4gZmFsc2U7Cit9
CisKK3N0YXRpYyBhbHdheXNfaW5saW5lIGJvb2wgYXJjaF9sb2NrX2V2YWx1
YXRlX25vc3BlYyhib29sIGNvbmRpdGlvbikKK3sKKyAgICBpZiAoIGNvbmRp
dGlvbiApCisgICAgICAgIHJldHVybiBiYXJyaWVyX2xvY2tfdHJ1ZSgpOwor
ICAgIGVsc2UKKyAgICAgICAgcmV0dXJuIGJhcnJpZXJfbG9ja19mYWxzZSgp
OworfQorCiAjZW5kaWYgLyogX0FTTV9YODZfTk9TUEVDX0ggKi8KIAogLyoK
ZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9zcGVjX2N0cmwuYyBiL3hlbi9h
cmNoL3g4Ni9zcGVjX2N0cmwuYwppbmRleCAwNjM4ZDk5ODBhNjEuLjBiNjcw
YzNjYTc1MyAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L3NwZWNfY3RybC5j
CisrKyBiL3hlbi9hcmNoL3g4Ni9zcGVjX2N0cmwuYwpAQCAtNTMsNiArNTMs
NyBAQCBpbnQ4X3QgX19yZWFkX21vc3RseSBvcHRfZWFnZXJfZnB1ID0gLTE7
CiBpbnQ4X3QgX19yZWFkX21vc3RseSBvcHRfbDFkX2ZsdXNoID0gLTE7CiBz
dGF0aWMgYm9vbCBfX2luaXRkYXRhIG9wdF9icmFuY2hfaGFyZGVuID0KICAg
ICBJU19FTkFCTEVEKENPTkZJR19TUEVDVUxBVElWRV9IQVJERU5fQlJBTkNI
KTsKK3N0YXRpYyBib29sIF9faW5pdGRhdGEgb3B0X2xvY2tfaGFyZGVuOwog
CiBib29sIF9faW5pdGRhdGEgYnNwX2RlbGF5X3NwZWNfY3RybDsKIHVpbnQ4
X3QgX19yZWFkX21vc3RseSBkZWZhdWx0X3hlbl9zcGVjX2N0cmw7CkBAIC0x
MjEsNiArMTIyLDcgQEAgc3RhdGljIGludCBfX2luaXQgY2ZfY2hlY2sgcGFy
c2Vfc3BlY19jdHJsKGNvbnN0IGNoYXIgKnMpCiAgICAgICAgICAgICBvcHRf
c3NiZCA9IGZhbHNlOwogICAgICAgICAgICAgb3B0X2wxZF9mbHVzaCA9IDA7
CiAgICAgICAgICAgICBvcHRfYnJhbmNoX2hhcmRlbiA9IGZhbHNlOworICAg
ICAgICAgICAgb3B0X2xvY2tfaGFyZGVuID0gZmFsc2U7CiAgICAgICAgICAg
ICBvcHRfc3JiX2xvY2sgPSAwOwogICAgICAgICAgICAgb3B0X3VucHJpdl9t
bWlvID0gZmFsc2U7CiAgICAgICAgICAgICBvcHRfZ2RzX21pdCA9IDA7CkBA
IC0yODYsNiArMjg4LDE2IEBAIHN0YXRpYyBpbnQgX19pbml0IGNmX2NoZWNr
IHBhcnNlX3NwZWNfY3RybChjb25zdCBjaGFyICpzKQogICAgICAgICAgICAg
ICAgIHJjID0gLUVJTlZBTDsKICAgICAgICAgICAgIH0KICAgICAgICAgfQor
ICAgICAgICBlbHNlIGlmICggKHZhbCA9IHBhcnNlX2Jvb2xlYW4oImxvY2st
aGFyZGVuIiwgcywgc3MpKSA+PSAwICkKKyAgICAgICAgeworICAgICAgICAg
ICAgaWYgKCBJU19FTkFCTEVEKENPTkZJR19TUEVDVUxBVElWRV9IQVJERU5f
TE9DSykgKQorICAgICAgICAgICAgICAgIG9wdF9sb2NrX2hhcmRlbiA9IHZh
bDsKKyAgICAgICAgICAgIGVsc2UKKyAgICAgICAgICAgIHsKKyAgICAgICAg
ICAgICAgICBub19jb25maWdfcGFyYW0oIlNQRUNVTEFUSVZFX0hBUkRFTl9M
T0NLIiwgInNwZWMtY3RybCIsIHMsIHNzKTsKKyAgICAgICAgICAgICAgICBy
YyA9IC1FSU5WQUw7CisgICAgICAgICAgICB9CisgICAgICAgIH0KICAgICAg
ICAgZWxzZSBpZiAoICh2YWwgPSBwYXJzZV9ib29sZWFuKCJzcmItbG9jayIs
IHMsIHNzKSkgPj0gMCApCiAgICAgICAgICAgICBvcHRfc3JiX2xvY2sgPSB2
YWw7CiAgICAgICAgIGVsc2UgaWYgKCAodmFsID0gcGFyc2VfYm9vbGVhbigi
dW5wcml2LW1taW8iLCBzLCBzcykpID49IDAgKQpAQCAtNDg4LDcgKzUwMCw4
IEBAIHN0YXRpYyB2b2lkIF9faW5pdCBwcmludF9kZXRhaWxzKGVudW0gaW5k
X3RodW5rIHRodW5rKQogICAgIGlmICggSVNfRU5BQkxFRChDT05GSUdfSU5E
SVJFQ1RfVEhVTkspIHx8IElTX0VOQUJMRUQoQ09ORklHX1NIQURPV19QQUdJ
TkcpIHx8CiAgICAgICAgICBJU19FTkFCTEVEKENPTkZJR19TUEVDVUxBVElW
RV9IQVJERU5fQVJSQVkpIHx8CiAgICAgICAgICBJU19FTkFCTEVEKENPTkZJ
R19TUEVDVUxBVElWRV9IQVJERU5fQlJBTkNIKSB8fAotICAgICAgICAgSVNf
RU5BQkxFRChDT05GSUdfU1BFQ1VMQVRJVkVfSEFSREVOX0dVRVNUX0FDQ0VT
UykgKQorICAgICAgICAgSVNfRU5BQkxFRChDT05GSUdfU1BFQ1VMQVRJVkVf
SEFSREVOX0dVRVNUX0FDQ0VTUykgfHwKKyAgICAgICAgIElTX0VOQUJMRUQo
Q09ORklHX1NQRUNVTEFUSVZFX0hBUkRFTl9MT0NLKSApCiAgICAgICAgIHBy
aW50aygiICBDb21waWxlZC1pbiBzdXBwb3J0OiIKICNpZmRlZiBDT05GSUdf
SU5ESVJFQ1RfVEhVTksKICAgICAgICAgICAgICAgICIgSU5ESVJFQ1RfVEhV
TksiCkBAIC01MDQsMTEgKzUxNywxNCBAQCBzdGF0aWMgdm9pZCBfX2luaXQg
cHJpbnRfZGV0YWlscyhlbnVtIGluZF90aHVuayB0aHVuaykKICNlbmRpZgog
I2lmZGVmIENPTkZJR19TUEVDVUxBVElWRV9IQVJERU5fR1VFU1RfQUNDRVNT
CiAgICAgICAgICAgICAgICAiIEhBUkRFTl9HVUVTVF9BQ0NFU1MiCisjZW5k
aWYKKyNpZmRlZiBDT05GSUdfU1BFQ1VMQVRJVkVfSEFSREVOX0xPQ0sKKyAg
ICAgICAgICAgICAgICIgSEFSREVOX0xPQ0siCiAjZW5kaWYKICAgICAgICAg
ICAgICAgICJcbiIpOwogCiAgICAgLyogU2V0dGluZ3MgZm9yIFhlbidzIHBy
b3RlY3Rpb24sIGlycmVzcGVjdGl2ZSBvZiBndWVzdHMuICovCi0gICAgcHJp
bnRrKCIgIFhlbiBzZXR0aW5nczogJXMlc1NQRUNfQ1RSTDogJXMlcyVzJXMl
cywgT3RoZXI6JXMlcyVzJXMlcyVzXG4iLAorICAgIHByaW50aygiICBYZW4g
c2V0dGluZ3M6ICVzJXNTUEVDX0NUUkw6ICVzJXMlcyVzJXMsIE90aGVyOiVz
JXMlcyVzJXMlcyVzXG4iLAogICAgICAgICAgICB0aHVuayAhPSBUSFVOS19O
T05FICAgICAgPyAiQlRJLVRodW5rOiAiIDogIiIsCiAgICAgICAgICAgIHRo
dW5rID09IFRIVU5LX05PTkUgICAgICA/ICIiIDoKICAgICAgICAgICAgdGh1
bmsgPT0gVEhVTktfUkVUUE9MSU5FID8gIlJFVFBPTElORSwgIiA6CkBAIC01
MzUsNyArNTUxLDggQEAgc3RhdGljIHZvaWQgX19pbml0IHByaW50X2RldGFp
bHMoZW51bSBpbmRfdGh1bmsgdGh1bmspCiAgICAgICAgICAgIG9wdF92ZXJ3
X3B2IHx8IG9wdF92ZXJ3X2h2bSB8fAogICAgICAgICAgICBvcHRfdmVyd19t
bWlvICAgICAgICAgICAgICAgICAgICAgICAgICAgICA/ICIgVkVSVyIgIDog
IiIsCiAgICAgICAgICAgIG9wdF9kaXZfc2NydWIgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgID8gIiBESVYiIDogIiIsCi0gICAgICAgICAgIG9wdF9i
cmFuY2hfaGFyZGVuICAgICAgICAgICAgICAgICAgICAgICAgID8gIiBCUkFO
Q0hfSEFSREVOIiA6ICIiKTsKKyAgICAgICAgICAgb3B0X2JyYW5jaF9oYXJk
ZW4gICAgICAgICAgICAgICAgICAgICAgICAgPyAiIEJSQU5DSF9IQVJERU4i
IDogIiIsCisgICAgICAgICAgIG9wdF9sb2NrX2hhcmRlbiAgICAgICAgICAg
ICAgICAgICAgICAgICAgID8gIiBMT0NLX0hBUkRFTiIgOiAiIik7CiAKICAg
ICAvKiBMMVRGIGRpYWdub3N0aWNzLCBwcmludGVkIGlmIHZ1bG5lcmFibGUg
b3IgUFYgc2hhZG93aW5nIGlzIGluIHVzZS4gKi8KICAgICBpZiAoIGNwdV9o
YXNfYnVnX2wxdGYgfHwgb3B0X3B2X2wxdGZfaHdkb20gfHwgb3B0X3B2X2wx
dGZfZG9tdSApCkBAIC0xOTE4LDYgKzE5MzUsOSBAQCB2b2lkIF9faW5pdCBp
bml0X3NwZWN1bGF0aW9uX21pdGlnYXRpb25zKHZvaWQpCiAgICAgaWYgKCAh
b3B0X2JyYW5jaF9oYXJkZW4gKQogICAgICAgICBzZXR1cF9mb3JjZV9jcHVf
Y2FwKFg4Nl9GRUFUVVJFX1NDX05PX0JSQU5DSF9IQVJERU4pOwogCisgICAg
aWYgKCAhb3B0X2xvY2tfaGFyZGVuICkKKyAgICAgICAgc2V0dXBfZm9yY2Vf
Y3B1X2NhcChYODZfRkVBVFVSRV9TQ19OT19MT0NLX0hBUkRFTik7CisKICAg
ICAvKgogICAgICAqIFdlIGRvIG5vdCBkaXNhYmxlIEhUIGJ5IGRlZmF1bHQg
b24gYWZmZWN0ZWQgaGFyZHdhcmUuCiAgICAgICoKZGlmZiAtLWdpdCBhL3hl
bi9jb21tb24vS2NvbmZpZyBiL3hlbi9jb21tb24vS2NvbmZpZwppbmRleCAz
MTBhZDQyMjljZGYuLmE1YzNkNWE2YmYyZiAxMDA2NDQKLS0tIGEveGVuL2Nv
bW1vbi9LY29uZmlnCisrKyBiL3hlbi9jb21tb24vS2NvbmZpZwpAQCAtMTg4
LDYgKzE4OCwyMyBAQCBjb25maWcgU1BFQ1VMQVRJVkVfSEFSREVOX0dVRVNU
X0FDQ0VTUwogCiAJICBJZiB1bnN1cmUsIHNheSBZLgogCitjb25maWcgU1BF
Q1VMQVRJVkVfSEFSREVOX0xPQ0sKKwlib29sICJTcGVjdWxhdGl2ZSBsb2Nr
IGNvbnRleHQgaGFyZGVuaW5nIgorCWRlZmF1bHQgeQorCWRlcGVuZHMgb24g
WDg2CisJaGVscAorCSAgQ29udGVtcG9yYXJ5IHByb2Nlc3NvcnMgbWF5IHVz
ZSBzcGVjdWxhdGl2ZSBleGVjdXRpb24gYXMgYQorCSAgcGVyZm9ybWFuY2Ug
b3B0aW1pc2F0aW9uLCBidXQgdGhpcyBjYW4gcG90ZW50aWFsbHkgYmUgYWJ1
c2VkIGJ5IGFuCisJICBhdHRhY2tlciB0byBsZWFrIGRhdGEgdmlhIHNwZWN1
bGF0aXZlIHNpZGVjaGFubmVscy4KKworCSAgT25lIHNvdXJjZSBvZiBkYXRh
IGxlYWthZ2UgaXMgdmlhIHNwZWN1bGF0aXZlIGFjY2Vzc2VzIHRvIGxvY2sK
KwkgIGNyaXRpY2FsIHJlZ2lvbnMuCisKKwkgIFRoaXMgb3B0aW9uIGlzIGRp
c2FibGVkIGJ5IGRlZmF1bHQgYXQgcnVuIHRpbWUsIGFuZCBuZWVkcyB0byBi
ZQorCSAgZW5hYmxlZCBvbiB0aGUgY29tbWFuZCBsaW5lLgorCisJICBJZiB1
bnN1cmUsIHNheSBZLgorCiBlbmRtZW51CiAKIGNvbmZpZyBESVRfREVGQVVM
VApkaWZmIC0tZ2l0IGEveGVuL2luY2x1ZGUveGVuL25vc3BlYy5oIGIveGVu
L2luY2x1ZGUveGVuL25vc3BlYy5oCmluZGV4IDRjMjUwZWJiZDY2My4uZThk
NzNmOTUzOGU1IDEwMDY0NAotLS0gYS94ZW4vaW5jbHVkZS94ZW4vbm9zcGVj
LmgKKysrIGIveGVuL2luY2x1ZGUveGVuL25vc3BlYy5oCkBAIC02OSw2ICs2
OSwyMSBAQCBzdGF0aWMgaW5saW5lIHVuc2lnbmVkIGxvbmcgYXJyYXlfaW5k
ZXhfbWFza19ub3NwZWModW5zaWduZWQgbG9uZyBpbmRleCwKICNkZWZpbmUg
YXJyYXlfYWNjZXNzX25vc3BlYyhhcnJheSwgaW5kZXgpICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIFwKICAgICAoYXJyYXkpW2FycmF5X2luZGV4
X25vc3BlYyhpbmRleCwgQVJSQVlfU0laRShhcnJheSkpXQogCitzdGF0aWMg
YWx3YXlzX2lubGluZSB2b2lkIGJsb2NrX2xvY2tfc3BlY3VsYXRpb24odm9p
ZCkKK3sKKyNpZmRlZiBDT05GSUdfU1BFQ1VMQVRJVkVfSEFSREVOX0xPQ0sK
KyAgICBhcmNoX2Jsb2NrX2xvY2tfc3BlY3VsYXRpb24oKTsKKyNlbmRpZgor
fQorCitzdGF0aWMgYWx3YXlzX2lubGluZSBib29sIGxvY2tfZXZhbHVhdGVf
bm9zcGVjKGJvb2wgY29uZGl0aW9uKQoreworI2lmZGVmIENPTkZJR19TUEVD
VUxBVElWRV9IQVJERU5fTE9DSworICAgIHJldHVybiBhcmNoX2xvY2tfZXZh
bHVhdGVfbm9zcGVjKGNvbmRpdGlvbik7CisjZW5kaWYKKyAgICByZXR1cm4g
Y29uZGl0aW9uOworfQorCiAjZW5kaWYgLyogWEVOX05PU1BFQ19IICovCiAK
IC8qCmRpZmYgLS1naXQgYS94ZW4vaW5jbHVkZS94ZW4vc3BpbmxvY2suaCBi
L3hlbi9pbmNsdWRlL3hlbi9zcGlubG9jay5oCmluZGV4IDBlNmEwODNkZmI5
ZS4uODQzMGE4ODhhOGNhIDEwMDY0NAotLS0gYS94ZW4vaW5jbHVkZS94ZW4v
c3BpbmxvY2suaAorKysgYi94ZW4vaW5jbHVkZS94ZW4vc3BpbmxvY2suaApA
QCAtMSw2ICsxLDcgQEAKICNpZm5kZWYgX19TUElOTE9DS19IX18KICNkZWZp
bmUgX19TUElOTE9DS19IX18KIAorI2luY2x1ZGUgPHhlbi9ub3NwZWMuaD4K
ICNpbmNsdWRlIDx4ZW4vdGltZS5oPgogI2luY2x1ZGUgPHhlbi90eXBlcy5o
PgogCkBAIC0yMDIsMTMgKzIwMywzMCBAQCBpbnQgX3NwaW5fdHJ5bG9ja19y
ZWN1cnNpdmUoc3BpbmxvY2tfdCAqbG9jayk7CiB2b2lkIF9zcGluX2xvY2tf
cmVjdXJzaXZlKHNwaW5sb2NrX3QgKmxvY2spOwogdm9pZCBfc3Bpbl91bmxv
Y2tfcmVjdXJzaXZlKHNwaW5sb2NrX3QgKmxvY2spOwogCi0jZGVmaW5lIHNw
aW5fbG9jayhsKSAgICAgICAgICAgICAgICAgIF9zcGluX2xvY2sobCkKLSNk
ZWZpbmUgc3Bpbl9sb2NrX2NiKGwsIGMsIGQpICAgICAgICAgX3NwaW5fbG9j
a19jYihsLCBjLCBkKQotI2RlZmluZSBzcGluX2xvY2tfaXJxKGwpICAgICAg
ICAgICAgICBfc3Bpbl9sb2NrX2lycShsKQorc3RhdGljIGFsd2F5c19pbmxp
bmUgdm9pZCBzcGluX2xvY2soc3BpbmxvY2tfdCAqbCkKK3sKKyAgICBfc3Bp
bl9sb2NrKGwpOworICAgIGJsb2NrX2xvY2tfc3BlY3VsYXRpb24oKTsKK30K
Kworc3RhdGljIGFsd2F5c19pbmxpbmUgdm9pZCBzcGluX2xvY2tfY2Ioc3Bp
bmxvY2tfdCAqbCwgdm9pZCAoKmMpKHZvaWQgKmRhdGEpLAorICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdm9pZCAqZCkKK3sKKyAg
ICBfc3Bpbl9sb2NrX2NiKGwsIGMsIGQpOworICAgIGJsb2NrX2xvY2tfc3Bl
Y3VsYXRpb24oKTsKK30KKworc3RhdGljIGFsd2F5c19pbmxpbmUgdm9pZCBz
cGluX2xvY2tfaXJxKHNwaW5sb2NrX3QgKmwpCit7CisgICAgX3NwaW5fbG9j
a19pcnEobCk7CisgICAgYmxvY2tfbG9ja19zcGVjdWxhdGlvbigpOworfQor
CiAjZGVmaW5lIHNwaW5fbG9ja19pcnFzYXZlKGwsIGYpICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgXAogICAgICh7ICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwK
ICAgICAgICAgQlVJTERfQlVHX09OKHNpemVvZihmKSAhPSBzaXplb2YodW5z
aWduZWQgbG9uZykpOyAgICAgICBcCiAgICAgICAgICgoZikgPSBfc3Bpbl9s
b2NrX2lycXNhdmUobCkpOyAgICAgICAgICAgICAgICAgICAgICAgICAgXAor
ICAgICAgICBibG9ja19sb2NrX3NwZWN1bGF0aW9uKCk7ICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIFwKICAgICB9KQogCiAjZGVmaW5lIHNwaW5f
dW5sb2NrKGwpICAgICAgICAgICAgICAgIF9zcGluX3VubG9jayhsKQpAQCAt
MjE2LDcgKzIzNCw3IEBAIHZvaWQgX3NwaW5fdW5sb2NrX3JlY3Vyc2l2ZShz
cGlubG9ja190ICpsb2NrKTsKICNkZWZpbmUgc3Bpbl91bmxvY2tfaXJxcmVz
dG9yZShsLCBmKSAgX3NwaW5fdW5sb2NrX2lycXJlc3RvcmUobCwgZikKIAog
I2RlZmluZSBzcGluX2lzX2xvY2tlZChsKSAgICAgICAgICAgICBfc3Bpbl9p
c19sb2NrZWQobCkKLSNkZWZpbmUgc3Bpbl90cnlsb2NrKGwpICAgICAgICAg
ICAgICAgX3NwaW5fdHJ5bG9jayhsKQorI2RlZmluZSBzcGluX3RyeWxvY2so
bCkgICAgICAgICAgICAgICBsb2NrX2V2YWx1YXRlX25vc3BlYyhfc3Bpbl90
cnlsb2NrKGwpKQogCiAjZGVmaW5lIHNwaW5fdHJ5bG9ja19pcnFzYXZlKGxv
Y2ssIGZsYWdzKSAgICAgICBcCiAoeyAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBcCkBAIC0yMzcsOCArMjU1LDE1IEBA
IHZvaWQgX3NwaW5fdW5sb2NrX3JlY3Vyc2l2ZShzcGlubG9ja190ICpsb2Nr
KTsKICAqIGFyZSBhbnkgY3JpdGljYWwgcmVnaW9ucyB0aGF0IGNhbm5vdCBm
b3JtIHBhcnQgb2Ygc3VjaCBhIHNldCwgdGhleSBjYW4gdXNlCiAgKiBzdGFu
ZGFyZCBzcGluX1t1bl1sb2NrKCkuCiAgKi8KLSNkZWZpbmUgc3Bpbl90cnls
b2NrX3JlY3Vyc2l2ZShsKSAgICAgX3NwaW5fdHJ5bG9ja19yZWN1cnNpdmUo
bCkKLSNkZWZpbmUgc3Bpbl9sb2NrX3JlY3Vyc2l2ZShsKSAgICAgICAgX3Nw
aW5fbG9ja19yZWN1cnNpdmUobCkKKyNkZWZpbmUgc3Bpbl90cnlsb2NrX3Jl
Y3Vyc2l2ZShsKSBcCisgICAgbG9ja19ldmFsdWF0ZV9ub3NwZWMoX3NwaW5f
dHJ5bG9ja19yZWN1cnNpdmUobCkpCisKK3N0YXRpYyBhbHdheXNfaW5saW5l
IHZvaWQgc3Bpbl9sb2NrX3JlY3Vyc2l2ZShzcGlubG9ja190ICpsKQorewor
ICAgIF9zcGluX2xvY2tfcmVjdXJzaXZlKGwpOworICAgIGJsb2NrX2xvY2tf
c3BlY3VsYXRpb24oKTsKK30KKwogI2RlZmluZSBzcGluX3VubG9ja19yZWN1
cnNpdmUobCkgICAgICBfc3Bpbl91bmxvY2tfcmVjdXJzaXZlKGwpCiAKICNl
bmRpZiAvKiBfX1NQSU5MT0NLX0hfXyAqLwo=

--=separator
Content-Type: application/octet-stream; name="xsa453/xsa453-3.patch"
Content-Disposition: attachment; filename="xsa453/xsa453-3.patch"
Content-Transfer-Encoding: base64

RnJvbTogPT9VVEYtOD9xP1JvZ2VyPTIwUGF1PTIwTW9ubj1DMz1BOT89IDxy
b2dlci5wYXVAY2l0cml4LmNvbT4KU3ViamVjdDogcndsb2NrOiBpbnRyb2R1
Y2Ugc3VwcG9ydCBmb3IgYmxvY2tpbmcgc3BlY3VsYXRpb24gaW50byBjcml0
aWNhbAogcmVnaW9ucwoKSW50cm9kdWNlIGlubGluZSB3cmFwcGVycyBhcyBy
ZXF1aXJlZCBhbmQgYWRkIGRpcmVjdCBjYWxscyB0bwpibG9ja19sb2NrX3Nw
ZWN1bGF0aW9uKCkgaW4gb3JkZXIgdG8gcHJldmVudCBzcGVjdWxhdGlvbiBp
bnRvIHRoZSByd2xvY2sKcHJvdGVjdGVkIGNyaXRpY2FsIHJlZ2lvbnMuCgpO
b3RlIHRoZSByd2xvY2sgcHJpbWl0aXZlcyBhcmUgYWRqdXN0ZWQgdG8gdXNl
IHRoZSBub24gc3BlY3VsYXRpb24gc2FmZSB2YXJpYW50cwpvZiB0aGUgc3Bp
bmxvY2sgaGFuZGxlcnMsIGFzIGEgc3BlY3VsYXRpb24gYmFycmllciBpcyBh
ZGRlZCBpbiB0aGUgcndsb2NrCmNhbGxpbmcgd3JhcHBlcnMuCgp0cnlsb2Nr
IHZhcmlhbnRzIGFyZSBwcm90ZWN0ZWQgYnkgdXNpbmcgbG9ja19ldmFsdWF0
ZV9ub3NwZWMoKS4KClRoaXMgaXMgcGFydCBvZiBYU0EtNDUzIC8gQ1ZFLTIw
MjQtMjE5MwoKU2lnbmVkLW9mZi1ieTogUm9nZXIgUGF1IE1vbm7DqSA8cm9n
ZXIucGF1QGNpdHJpeC5jb20+ClJldmlld2VkLWJ5OiBKYW4gQmV1bGljaCA8
amJldWxpY2hAc3VzZS5jb20+CgpkaWZmIC0tZ2l0IGEveGVuL2NvbW1vbi9y
d2xvY2suYyBiL3hlbi9jb21tb24vcndsb2NrLmMKaW5kZXggMTgyMjRhNGJi
NWQ2Li4yOTA2MDI5MzZkZjYgMTAwNjQ0Ci0tLSBhL3hlbi9jb21tb24vcnds
b2NrLmMKKysrIGIveGVuL2NvbW1vbi9yd2xvY2suYwpAQCAtMzQsOCArMzQs
MTEgQEAgdm9pZCBxdWV1ZV9yZWFkX2xvY2tfc2xvd3BhdGgocndsb2NrX3Qg
KmxvY2spCiAKICAgICAvKgogICAgICAqIFB1dCB0aGUgcmVhZGVyIGludG8g
dGhlIHdhaXQgcXVldWUuCisgICAgICoKKyAgICAgKiBVc2UgdGhlIHNwZWN1
bGF0aW9uIHVuc2FmZSBoZWxwZXIsIGFzIGl0J3MgdGhlIGNhbGxlciByZXNw
b25zaWJpbGl0eSB0bworICAgICAqIGlzc3VlIGEgc3BlY3VsYXRpb24gYmFy
cmllciBpZiByZXF1aXJlZC4KICAgICAgKi8KLSAgICBzcGluX2xvY2soJmxv
Y2stPmxvY2spOworICAgIF9zcGluX2xvY2soJmxvY2stPmxvY2spOwogCiAg
ICAgLyoKICAgICAgKiBBdCB0aGUgaGVhZCBvZiB0aGUgd2FpdCBxdWV1ZSBu
b3csIHdhaXQgdW50aWwgdGhlIHdyaXRlciBzdGF0ZQpAQCAtNjYsOCArNjks
MTMgQEAgdm9pZCBxdWV1ZV93cml0ZV9sb2NrX3Nsb3dwYXRoKHJ3bG9ja190
ICpsb2NrKQogewogICAgIHUzMiBjbnRzOwogCi0gICAgLyogUHV0IHRoZSB3
cml0ZXIgaW50byB0aGUgd2FpdCBxdWV1ZS4gKi8KLSAgICBzcGluX2xvY2so
JmxvY2stPmxvY2spOworICAgIC8qCisgICAgICogUHV0IHRoZSB3cml0ZXIg
aW50byB0aGUgd2FpdCBxdWV1ZS4KKyAgICAgKgorICAgICAqIFVzZSB0aGUg
c3BlY3VsYXRpb24gdW5zYWZlIGhlbHBlciwgYXMgaXQncyB0aGUgY2FsbGVy
IHJlc3BvbnNpYmlsaXR5IHRvCisgICAgICogaXNzdWUgYSBzcGVjdWxhdGlv
biBiYXJyaWVyIGlmIHJlcXVpcmVkLgorICAgICAqLworICAgIF9zcGluX2xv
Y2soJmxvY2stPmxvY2spOwogCiAgICAgLyogVHJ5IHRvIGFjcXVpcmUgdGhl
IGxvY2sgZGlyZWN0bHkgaWYgbm8gcmVhZGVyIGlzIHByZXNlbnQuICovCiAg
ICAgaWYgKCAhYXRvbWljX3JlYWQoJmxvY2stPmNudHMpICYmCmRpZmYgLS1n
aXQgYS94ZW4vaW5jbHVkZS94ZW4vcndsb2NrLmggYi94ZW4vaW5jbHVkZS94
ZW4vcndsb2NrLmgKaW5kZXggMDhiYTQ2ZGUxNTUyLi5mZmZmMGZhZDQ1YTcg
MTAwNjQ0Ci0tLSBhL3hlbi9pbmNsdWRlL3hlbi9yd2xvY2suaAorKysgYi94
ZW4vaW5jbHVkZS94ZW4vcndsb2NrLmgKQEAgLTI1OSwyNyArMjU5LDQ5IEBA
IHN0YXRpYyBpbmxpbmUgaW50IF9yd19pc193cml0ZV9sb2NrZWQoY29uc3Qg
cndsb2NrX3QgKmxvY2spCiAgICAgcmV0dXJuIChhdG9taWNfcmVhZCgmbG9j
ay0+Y250cykgJiBfUVdfV01BU0spID09IF9RV19MT0NLRUQ7CiB9CiAKLSNk
ZWZpbmUgcmVhZF9sb2NrKGwpICAgICAgICAgICAgICAgICAgX3JlYWRfbG9j
ayhsKQotI2RlZmluZSByZWFkX2xvY2tfaXJxKGwpICAgICAgICAgICAgICBf
cmVhZF9sb2NrX2lycShsKQorc3RhdGljIGFsd2F5c19pbmxpbmUgdm9pZCBy
ZWFkX2xvY2socndsb2NrX3QgKmwpCit7CisgICAgX3JlYWRfbG9jayhsKTsK
KyAgICBibG9ja19sb2NrX3NwZWN1bGF0aW9uKCk7Cit9CisKK3N0YXRpYyBh
bHdheXNfaW5saW5lIHZvaWQgcmVhZF9sb2NrX2lycShyd2xvY2tfdCAqbCkK
K3sKKyAgICBfcmVhZF9sb2NrX2lycShsKTsKKyAgICBibG9ja19sb2NrX3Nw
ZWN1bGF0aW9uKCk7Cit9CisKICNkZWZpbmUgcmVhZF9sb2NrX2lycXNhdmUo
bCwgZikgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAg
KHsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgXAogICAgICAgICBCVUlMRF9CVUdfT04oc2l6ZW9m
KGYpICE9IHNpemVvZih1bnNpZ25lZCBsb25nKSk7ICAgICAgIFwKICAgICAg
ICAgKChmKSA9IF9yZWFkX2xvY2tfaXJxc2F2ZShsKSk7ICAgICAgICAgICAg
ICAgICAgICAgICAgICBcCisgICAgICAgIGJsb2NrX2xvY2tfc3BlY3VsYXRp
b24oKTsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAogICAgIH0p
CiAKICNkZWZpbmUgcmVhZF91bmxvY2sobCkgICAgICAgICAgICAgICAgX3Jl
YWRfdW5sb2NrKGwpCiAjZGVmaW5lIHJlYWRfdW5sb2NrX2lycShsKSAgICAg
ICAgICAgIF9yZWFkX3VubG9ja19pcnEobCkKICNkZWZpbmUgcmVhZF91bmxv
Y2tfaXJxcmVzdG9yZShsLCBmKSAgX3JlYWRfdW5sb2NrX2lycXJlc3RvcmUo
bCwgZikKLSNkZWZpbmUgcmVhZF90cnlsb2NrKGwpICAgICAgICAgICAgICAg
X3JlYWRfdHJ5bG9jayhsKQorI2RlZmluZSByZWFkX3RyeWxvY2sobCkgICAg
ICAgICAgICAgICBsb2NrX2V2YWx1YXRlX25vc3BlYyhfcmVhZF90cnlsb2Nr
KGwpKQorCitzdGF0aWMgYWx3YXlzX2lubGluZSB2b2lkIHdyaXRlX2xvY2so
cndsb2NrX3QgKmwpCit7CisgICAgX3dyaXRlX2xvY2sobCk7CisgICAgYmxv
Y2tfbG9ja19zcGVjdWxhdGlvbigpOworfQorCitzdGF0aWMgYWx3YXlzX2lu
bGluZSB2b2lkIHdyaXRlX2xvY2tfaXJxKHJ3bG9ja190ICpsKQoreworICAg
IF93cml0ZV9sb2NrX2lycShsKTsKKyAgICBibG9ja19sb2NrX3NwZWN1bGF0
aW9uKCk7Cit9CiAKLSNkZWZpbmUgd3JpdGVfbG9jayhsKSAgICAgICAgICAg
ICAgICAgX3dyaXRlX2xvY2sobCkKLSNkZWZpbmUgd3JpdGVfbG9ja19pcnEo
bCkgICAgICAgICAgICAgX3dyaXRlX2xvY2tfaXJxKGwpCiAjZGVmaW5lIHdy
aXRlX2xvY2tfaXJxc2F2ZShsLCBmKSAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgXAogICAgICh7ICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKICAgICAgICAgQlVJ
TERfQlVHX09OKHNpemVvZihmKSAhPSBzaXplb2YodW5zaWduZWQgbG9uZykp
OyAgICAgICBcCiAgICAgICAgICgoZikgPSBfd3JpdGVfbG9ja19pcnFzYXZl
KGwpKTsgICAgICAgICAgICAgICAgICAgICAgICAgXAorICAgICAgICBibG9j
a19sb2NrX3NwZWN1bGF0aW9uKCk7ICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIFwKICAgICB9KQotI2RlZmluZSB3cml0ZV90cnlsb2NrKGwpICAg
ICAgICAgICAgICBfd3JpdGVfdHJ5bG9jayhsKQorI2RlZmluZSB3cml0ZV90
cnlsb2NrKGwpICAgICAgICAgICAgICBsb2NrX2V2YWx1YXRlX25vc3BlYyhf
d3JpdGVfdHJ5bG9jayhsKSkKIAogI2RlZmluZSB3cml0ZV91bmxvY2sobCkg
ICAgICAgICAgICAgICBfd3JpdGVfdW5sb2NrKGwpCiAjZGVmaW5lIHdyaXRl
X3VubG9ja19pcnEobCkgICAgICAgICAgIF93cml0ZV91bmxvY2tfaXJxKGwp
Cg==

--=separator
Content-Type: application/octet-stream; name="xsa453/xsa453-4.15-1.patch"
Content-Disposition: attachment; filename="xsa453/xsa453-4.15-1.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L3BhZ2luZzogRGVsZXRlIHVwZGF0ZV9jcjMoKSdz
IGRvX2xvY2tpbmcgcGFyYW1ldGVyCgpOaWNvbGEgcmVwb3J0cyB0aGF0IHRo
ZSBYU0EtNDM4IGZpeCBpbnRyb2R1Y2VkIG5ldyBNSVNSQSB2aW9sYXRpb25z
IGJlY2F1c2Ugb2YKc29tZSBpbmNpZGVudGFsIHRpZHlpbmcgaXQgdHJpZWQg
dG8gZG8uICBUaGUgcGFyYW1ldGVyIGlzIHVzZWxlc3MsIHNvIHJlc29sdmUK
dGhlIE1JU1JBIHJlZ3Jlc3Npb24gYnkgcmVtb3ZpbmcgaXQuCgpoYXBfdXBk
YXRlX2NyMygpIGRpc2NhcmRzIHRoZSBwYXJhbWV0ZXIgZW50aXJlbHksIHdo
aWxlIHNoX3VwZGF0ZV9jcjMoKSB1c2VzCml0IHRvIGRpc3Rpbmd1aXNoIGlu
dGVybmFsIGFuZCBleHRlcm5hbCBjYWxsZXJzIGFuZCB0aGVyZWZvcmUgd2hl
dGhlciB0aGUKcGFnaW5nIGxvY2sgc2hvdWxkIGJlIHRha2VuLgoKSG93ZXZl
ciwgd2UgaGF2ZSBwYWdpbmdfbG9ja19yZWN1cnNpdmUoKSBmb3IgdGhpcyBw
dXJwb3NlLCB3aGljaCBhbHNvIGF2b2lkcwp0aGUgYWJpbGl0eSBmb3IgdGhl
IHNoYWRvdyBpbnRlcm5hbCBjYWxsZXJzIHRvIGFjY2lkZW50YWxseSBub3Qg
aG9sZCB0aGUgbG9jay4KCkZpeGVzOiBmYjBmZjQ5ZmU5ZjcgKCJ4ODYvc2hh
ZG93OiBkZWZlciByZWxlYXNpbmcgb2YgUFYncyB0b3AtbGV2ZWwgc2hhZG93
IHJlZmVyZW5jZSIpClJlcG9ydGVkLWJ5OiBOaWNvbGEgVmV0cmluaSA8bmlj
b2xhLnZldHJpbmlAYnVnc2VuZy5jb20+ClNpZ25lZC1vZmYtYnk6IEFuZHJl
dyBDb29wZXIgPGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+ClJldmlld2Vk
LWJ5OiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+ClJlbGVhc2Ut
YWNrZWQtYnk6IEhlbnJ5IFdhbmcgPEhlbnJ5LldhbmdAYXJtLmNvbT4KKGNo
ZXJyeSBwaWNrZWQgZnJvbSBjb21taXQgZTcxMTU3ZDFhYzJhN2ZiZjQxMzEz
MDY2M2NmMGE5M2ZmOWZiY2Y3ZSkKCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94
ODYvbW0vaGFwL2hhcC5jIGIveGVuL2FyY2gveDg2L21tL2hhcC9oYXAuYwpp
bmRleCBmYTQ3OWQzZDk3YjMuLjYzYzI5ZGE2OTZkZCAxMDA2NDQKLS0tIGEv
eGVuL2FyY2gveDg2L21tL2hhcC9oYXAuYworKysgYi94ZW4vYXJjaC94ODYv
bW0vaGFwL2hhcC5jCkBAIC03MjgsNyArNzI4LDcgQEAgc3RhdGljIGJvb2xf
dCBoYXBfaW52bHBnKHN0cnVjdCB2Y3B1ICp2LCB1bnNpZ25lZCBsb25nIGxp
bmVhcikKICAgICByZXR1cm4gMTsKIH0KIAotc3RhdGljIHBhZ2V0YWJsZV90
IGhhcF91cGRhdGVfY3IzKHN0cnVjdCB2Y3B1ICp2LCBib29sIGRvX2xvY2tp
bmcsIGJvb2wgbm9mbHVzaCkKK3N0YXRpYyBwYWdldGFibGVfdCBoYXBfdXBk
YXRlX2NyMyhzdHJ1Y3QgdmNwdSAqdiwgYm9vbCBub2ZsdXNoKQogewogICAg
IHYtPmFyY2guaHZtLmh3X2NyWzNdID0gdi0+YXJjaC5odm0uZ3Vlc3RfY3Jb
M107CiAgICAgaHZtX3VwZGF0ZV9ndWVzdF9jcjModiwgbm9mbHVzaCk7CkBA
IC04MTgsNyArODE4LDcgQEAgc3RhdGljIHZvaWQgaGFwX3VwZGF0ZV9wYWdp
bmdfbW9kZXMoc3RydWN0IHZjcHUgKnYpCiAgICAgfQogCiAgICAgLyogQ1Iz
IGlzIGVmZmVjdGl2ZWx5IHVwZGF0ZWQgYnkgYSBtb2RlIGNoYW5nZS4gRmx1
c2ggQVNJRHMsIGV0Yy4gKi8KLSAgICBoYXBfdXBkYXRlX2NyMyh2LCAwLCBm
YWxzZSk7CisgICAgaGFwX3VwZGF0ZV9jcjModiwgZmFsc2UpOwogCiAgdW5s
b2NrOgogICAgIHBhZ2luZ191bmxvY2soZCk7CmRpZmYgLS1naXQgYS94ZW4v
YXJjaC94ODYvbW0vc2hhZG93L2NvbW1vbi5jIGIveGVuL2FyY2gveDg2L21t
L3NoYWRvdy9jb21tb24uYwppbmRleCAwNGNlY2E0YTUyYjAuLjM2NGQ3NGY1
OTVjYyAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L21tL3NoYWRvdy9jb21t
b24uYworKysgYi94ZW4vYXJjaC94ODYvbW0vc2hhZG93L2NvbW1vbi5jCkBA
IC0yNjMwLDcgKzI2MzAsNyBAQCBzdGF0aWMgdm9pZCBzaF91cGRhdGVfcGFn
aW5nX21vZGVzKHN0cnVjdCB2Y3B1ICp2KQogICAgIH0KICNlbmRpZiAvKiBP
T1MgKi8KIAotICAgIHYtPmFyY2gucGFnaW5nLm1vZGUtPnVwZGF0ZV9jcjMo
diwgMCwgZmFsc2UpOworICAgIHYtPmFyY2gucGFnaW5nLm1vZGUtPnVwZGF0
ZV9jcjModiwgZmFsc2UpOwogfQogCiB2b2lkIHNoYWRvd191cGRhdGVfcGFn
aW5nX21vZGVzKHN0cnVjdCB2Y3B1ICp2KQpkaWZmIC0tZ2l0IGEveGVuL2Fy
Y2gveDg2L21tL3NoYWRvdy9tdWx0aS5jIGIveGVuL2FyY2gveDg2L21tL3No
YWRvdy9tdWx0aS5jCmluZGV4IDM1ZDQ3ZDZmYmIzZC4uNWY3M2JiYTQxYmZi
IDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYvbW0vc2hhZG93L211bHRpLmMK
KysrIGIveGVuL2FyY2gveDg2L21tL3NoYWRvdy9tdWx0aS5jCkBAIC0yODg0
LDcgKzI4ODQsNyBAQCBzdGF0aWMgaW50IHNoX3BhZ2VfZmF1bHQoc3RydWN0
IHZjcHUgKnYsCiAgICAgICAgICAqIEluIGFueSBjYXNlLCBpbiB0aGUgUEFF
IGNhc2UsIHRoZSBBU1NFUlQgaXMgbm90IHRydWU7IGl0IGNhbgogICAgICAg
ICAgKiBoYXBwZW4gYmVjYXVzZSBvZiBhY3Rpb25zIHRoZSBndWVzdCBpcyB0
YWtpbmcuICovCiAjaWYgR1VFU1RfUEFHSU5HX0xFVkVMUyA9PSAzCi0gICAg
ICAgIHYtPmFyY2gucGFnaW5nLm1vZGUtPnVwZGF0ZV9jcjModiwgMCwgZmFs
c2UpOworICAgICAgICB2LT5hcmNoLnBhZ2luZy5tb2RlLT51cGRhdGVfY3Iz
KHYsIGZhbHNlKTsKICNlbHNlCiAgICAgICAgIEFTU0VSVChkLT5pc19zaHV0
dGluZ19kb3duKTsKICNlbmRpZgpAQCAtMzYwNCwxNyArMzYwNCwxMyBAQCBz
aF9kZXRhY2hfb2xkX3RhYmxlcyhzdHJ1Y3QgdmNwdSAqdikKICAgICB9CiB9
CiAKLXN0YXRpYyBwYWdldGFibGVfdAotc2hfdXBkYXRlX2NyMyhzdHJ1Y3Qg
dmNwdSAqdiwgYm9vbCBkb19sb2NraW5nLCBib29sIG5vZmx1c2gpCitzdGF0
aWMgcGFnZXRhYmxlX3Qgc2hfdXBkYXRlX2NyMyhzdHJ1Y3QgdmNwdSAqdiwg
Ym9vbCBub2ZsdXNoKQogLyogVXBkYXRlcyB2Y3B1LT5hcmNoLmNyMyBhZnRl
ciB0aGUgZ3Vlc3QgaGFzIGNoYW5nZWQgQ1IzLgogICogUGFyYXZpcnR1YWwg
Z3Vlc3RzIHNob3VsZCBzZXQgdi0+YXJjaC5ndWVzdF90YWJsZSAoYW5kIGd1
ZXN0X3RhYmxlX3VzZXIsCiAgKiBpZiBhcHByb3ByaWF0ZSkuCiAgKiBIVk0g
Z3Vlc3RzIHNob3VsZCBhbHNvIG1ha2Ugc3VyZSBodm1fZ2V0X2d1ZXN0X2Nu
dGxfcmVnKHYsIDMpIHdvcmtzOwogICogdGhpcyBmdW5jdGlvbiB3aWxsIGNh
bGwgaHZtX3VwZGF0ZV9ndWVzdF9jcih2LCAzKSB0byB0ZWxsIHRoZW0gd2hl
cmUgdGhlCiAgKiBzaGFkb3cgdGFibGVzIGFyZS4KLSAqIElmIGRvX2xvY2tp
bmcgIT0gMCwgYXNzdW1lIHdlIGFyZSBiZWluZyBjYWxsZWQgZnJvbSBvdXRz
aWRlIHRoZQotICogc2hhZG93IGNvZGUsIGFuZCBtdXN0IHRha2UgYW5kIHJl
bGVhc2UgdGhlIHBhZ2luZyBsb2NrOyBvdGhlcndpc2UKLSAqIHRoYXQgaXMg
dGhlIGNhbGxlcidzIHJlc3BvbnNpYmlsaXR5LgogICovCiB7CiAgICAgc3Ry
dWN0IGRvbWFpbiAqZCA9IHYtPmRvbWFpbjsKQEAgLTM2MzIsNyArMzYyOCwx
MSBAQCBzaF91cGRhdGVfY3IzKHN0cnVjdCB2Y3B1ICp2LCBib29sIGRvX2xv
Y2tpbmcsIGJvb2wgbm9mbHVzaCkKICAgICAgICAgcmV0dXJuIG9sZF9lbnRy
eTsKICAgICB9CiAKLSAgICBpZiAoIGRvX2xvY2tpbmcgKSBwYWdpbmdfbG9j
ayh2LT5kb21haW4pOworICAgIC8qCisgICAgICogVGhpcyBpcyB1c2VkIGV4
dGVybmFsbHkgKHdpdGggdGhlIHBhZ2luZyBsb2NrIG5vdCB0YWtlbikgYW5k
IGludGVybmFsbHkKKyAgICAgKiBieSB0aGUgc2hhZG93IGNvZGUgKHdpdGgg
dGhlIGxvY2sgYWxyZWFkeSB0YWtlbikuCisgICAgICovCisgICAgcGFnaW5n
X2xvY2tfcmVjdXJzaXZlKHYtPmRvbWFpbik7CiAKICNpZiAoU0hBRE9XX09Q
VElNSVpBVElPTlMgJiBTSE9QVF9PVVRfT0ZfU1lOQykKICAgICAvKiBOZWVk
IHRvIHJlc3luYyBhbGwgdGhlIHNoYWRvdyBlbnRyaWVzIG9uIGEgVExCIGZs
dXNoLiAgUmVzeW5jCkBAIC0zODcwLDggKzM4NzAsNyBAQCBzaF91cGRhdGVf
Y3IzKHN0cnVjdCB2Y3B1ICp2LCBib29sIGRvX2xvY2tpbmcsIGJvb2wgbm9m
bHVzaCkKICAgICBzaGFkb3dfc3luY19vdGhlcl92Y3B1cyh2KTsKICNlbmRp
ZgogCi0gICAgLyogUmVsZWFzZSB0aGUgbG9jaywgaWYgd2UgdG9vayBpdCAo
b3RoZXJ3aXNlIGl0J3MgdGhlIGNhbGxlcidzIHByb2JsZW0pICovCi0gICAg
aWYgKCBkb19sb2NraW5nICkgcGFnaW5nX3VubG9jayh2LT5kb21haW4pOwor
ICAgIHBhZ2luZ191bmxvY2sodi0+ZG9tYWluKTsKIAogICAgIHJldHVybiBv
bGRfZW50cnk7CiB9CmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYvbW0vc2hh
ZG93L25vbmUuYyBiL3hlbi9hcmNoL3g4Ni9tbS9zaGFkb3cvbm9uZS5jCmlu
ZGV4IDliOWMwM2NlN2UxYy4uZjgwYTJiYTBmM2UwIDEwMDY0NAotLS0gYS94
ZW4vYXJjaC94ODYvbW0vc2hhZG93L25vbmUuYworKysgYi94ZW4vYXJjaC94
ODYvbW0vc2hhZG93L25vbmUuYwpAQCAtNTAsNyArNTAsNyBAQCBzdGF0aWMg
dW5zaWduZWQgbG9uZyBfZ3ZhX3RvX2dmbihzdHJ1Y3QgdmNwdSAqdiwgc3Ry
dWN0IHAybV9kb21haW4gKnAybSwKICAgICByZXR1cm4gZ2ZuX3goSU5WQUxJ
RF9HRk4pOwogfQogCi1zdGF0aWMgcGFnZXRhYmxlX3QgX3VwZGF0ZV9jcjMo
c3RydWN0IHZjcHUgKnYsIGJvb2wgZG9fbG9ja2luZywgYm9vbCBub2ZsdXNo
KQorc3RhdGljIHBhZ2V0YWJsZV90IF91cGRhdGVfY3IzKHN0cnVjdCB2Y3B1
ICp2LCBib29sIG5vZmx1c2gpCiB7CiAgICAgQVNTRVJUX1VOUkVBQ0hBQkxF
KCk7CiAgICAgcmV0dXJuIHBhZ2V0YWJsZV9udWxsKCk7CmRpZmYgLS1naXQg
YS94ZW4vaW5jbHVkZS9hc20teDg2L3BhZ2luZy5oIGIveGVuL2luY2x1ZGUv
YXNtLXg4Ni9wYWdpbmcuaAppbmRleCA1YmNkYmY5M2E3NzAuLjNhZDhhYWI0
NzEzNSAxMDA2NDQKLS0tIGEveGVuL2luY2x1ZGUvYXNtLXg4Ni9wYWdpbmcu
aAorKysgYi94ZW4vaW5jbHVkZS9hc20teDg2L3BhZ2luZy5oCkBAIC0xMzYs
OCArMTM2LDcgQEAgc3RydWN0IHBhZ2luZ19tb2RlIHsKICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdW5zaWduZWQgbG9u
ZyBjcjMsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIHBhZGRyX3QgZ2EsIHVpbnQzMl90ICpwZmVjLAogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1bnNpZ25lZCBp
bnQgKnBhZ2Vfb3JkZXIpOwotICAgIHBhZ2V0YWJsZV90ICAgKCp1cGRhdGVf
Y3IzICAgICAgICAgICAgKShzdHJ1Y3QgdmNwdSAqdiwgYm9vbCBkb19sb2Nr
aW5nLAotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBib29sIG5vZmx1c2gpOworICAgIHBhZ2V0YWJsZV90ICAgKCp1cGRh
dGVfY3IzICAgICAgICAgICAgKShzdHJ1Y3QgdmNwdSAqdiwgYm9vbCBub2Zs
dXNoKTsKICAgICB2b2lkICAgICAgICAgICgqdXBkYXRlX3BhZ2luZ19tb2Rl
cyAgICkoc3RydWN0IHZjcHUgKnYpOwogICAgIGJvb2wgICAgICAgICAgKCpm
bHVzaF90bGIgICAgICAgICAgICAgKShib29sICgqZmx1c2hfdmNwdSkodm9p
ZCAqY3R4dCwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0cnVjdCB2Y3B1ICp2KSwK
QEAgLTMxMSw3ICszMTAsNyBAQCBzdGF0aWMgaW5saW5lIHVuc2lnbmVkIGxv
bmcgcGFnaW5nX2dhX3RvX2dmbl9jcjMoc3RydWN0IHZjcHUgKnYsCiAgKiBh
cyB0aGUgdmFsdWUgdG8gbG9hZCBpbnRvIHRoZSBob3N0IENSMyB0byBzY2hl
ZHVsZSB0aGlzIHZjcHUgKi8KIHN0YXRpYyBpbmxpbmUgcGFnZXRhYmxlX3Qg
cGFnaW5nX3VwZGF0ZV9jcjMoc3RydWN0IHZjcHUgKnYsIGJvb2wgbm9mbHVz
aCkKIHsKLSAgICByZXR1cm4gcGFnaW5nX2dldF9ob3N0bW9kZSh2KS0+dXBk
YXRlX2NyMyh2LCAxLCBub2ZsdXNoKTsKKyAgICByZXR1cm4gcGFnaW5nX2dl
dF9ob3N0bW9kZSh2KS0+dXBkYXRlX2NyMyh2LCBub2ZsdXNoKTsKIH0KIAog
LyogVXBkYXRlIGFsbCB0aGUgdGhpbmdzIHRoYXQgYXJlIGRlcml2ZWQgZnJv
bSB0aGUgZ3Vlc3QncyBDUjAvQ1IzL0NSNC4KCg==

--=separator
Content-Type: application/octet-stream; name="xsa453/xsa453-4.15-2.patch"
Content-Disposition: attachment; filename="xsa453/xsa453-4.15-2.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeGVuOiBTd2FwIG9yZGVyIG9mIGFjdGlvbnMgaW4gdGhl
IEZSRUUqKCkgbWFjcm9zCgpXaGVyZXZlciBwb3NzaWJsZSwgaXQgaXMgYSBn
b29kIGlkZWEgdG8gTlVMTCBvdXQgdGhlIHZpc2libGUgcmVmZXJlbmNlIHRv
IGFuCm9iamVjdCBwcmlvciB0byBmcmVlaW5nIGl0LiAgVGhlIEZSRUUqKCkg
bWFjcm9zIGFscmVhZHkgY29sbGVjdCB0b2dldGhlciBib3RoCnBhcnRzLCBt
YWtpbmcgaXQgZWFzeSB0byBhZGp1c3QuCgpUaGlzIGhhcyBhIG1hcmdpbmFs
IGNvZGUgZ2VuZXJhdGlvbiBpbXByb3ZlbWVudCwgYXMgc29tZSBvZiB0aGUg
Y2FsbHMgdG8gdGhlCmZyZWUoKSBmdW5jdGlvbiBjYW4gYmUgdGFpbGNhbGwg
b3B0aW1pc2VkLgoKTm8gZnVuY3Rpb25hbCBjaGFuZ2UuCgpTaWduZWQtb2Zm
LWJ5OiBBbmRyZXcgQ29vcGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29t
PgpBY2tlZC1ieTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgoo
Y2hlcnJ5IHBpY2tlZCBmcm9tIGNvbW1pdCBjNGY0MjdlYzg3OWU3YzBkZjZk
NDRkMDI1NjFlOGJlZTgzOGEyOTNlKQoKZGlmZiAtLWdpdCBhL3hlbi9pbmNs
dWRlL3hlbi9tbS5oIGIveGVuL2luY2x1ZGUveGVuL21tLmgKaW5kZXggNjY3
ZjlkYWM4M2E0Li43ZmM4YTg4OThhZmIgMTAwNjQ0Ci0tLSBhL3hlbi9pbmNs
dWRlL3hlbi9tbS5oCisrKyBiL3hlbi9pbmNsdWRlL3hlbi9tbS5oCkBAIC04
MCw4ICs4MCw5IEBAIGJvb2wgc2NydWJfZnJlZV9wYWdlcyh2b2lkKTsKIAog
LyogRnJlZSBhbiBhbGxvY2F0aW9uLCBhbmQgemVybyB0aGUgcG9pbnRlciB0
byBpdC4gKi8KICNkZWZpbmUgRlJFRV9YRU5IRUFQX1BBR0VTKHAsIG8pIGRv
IHsgXAotICAgIGZyZWVfeGVuaGVhcF9wYWdlcyhwLCBvKTsgICAgICAgICBc
CisgICAgdm9pZCAqX3B0cl8gPSAocCk7ICAgICAgICAgICAgICAgIFwKICAg
ICAocCkgPSBOVUxMOyAgICAgICAgICAgICAgICAgICAgICAgXAorICAgIGZy
ZWVfeGVuaGVhcF9wYWdlcyhfcHRyXywgbyk7ICAgICBcCiB9IHdoaWxlICgg
ZmFsc2UgKQogI2RlZmluZSBGUkVFX1hFTkhFQVBfUEFHRShwKSBGUkVFX1hF
TkhFQVBfUEFHRVMocCwgMCkKIApkaWZmIC0tZ2l0IGEveGVuL2luY2x1ZGUv
eGVuL3htYWxsb2MuaCBiL3hlbi9pbmNsdWRlL3hlbi94bWFsbG9jLmgKaW5k
ZXggMTY5NzlhMTE3YzZhLi5kODU3Mjk4MDExYzEgMTAwNjQ0Ci0tLSBhL3hl
bi9pbmNsdWRlL3hlbi94bWFsbG9jLmgKKysrIGIveGVuL2luY2x1ZGUveGVu
L3htYWxsb2MuaApAQCAtNjYsOSArNjYsMTAgQEAKIGV4dGVybiB2b2lkIHhm
cmVlKHZvaWQgKik7CiAKIC8qIEZyZWUgYW4gYWxsb2NhdGlvbiwgYW5kIHpl
cm8gdGhlIHBvaW50ZXIgdG8gaXQuICovCi0jZGVmaW5lIFhGUkVFKHApIGRv
IHsgXAotICAgIHhmcmVlKHApOyAgICAgICAgIFwKLSAgICAocCkgPSBOVUxM
OyAgICAgICBcCisjZGVmaW5lIFhGUkVFKHApIGRvIHsgICAgICAgICAgICAg
ICAgICAgICAgIFwKKyAgICB2b2lkICpfcHRyXyA9IChwKTsgICAgICAgICAg
ICAgICAgICAgICAgXAorICAgIChwKSA9IE5VTEw7ICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBcCisgICAgeGZyZWUoX3B0cl8pOyAgICAgICAgICAg
ICAgICAgICAgICAgICAgIFwKIH0gd2hpbGUgKCBmYWxzZSApCiAKIC8qIFVu
ZGVybHlpbmcgZnVuY3Rpb25zICovCg==

--=separator
Content-Type: application/octet-stream; name="xsa453/xsa453-4.15-3.patch"
Content-Disposition: attachment; filename="xsa453/xsa453-4.15-3.patch"
Content-Transfer-Encoding: base64

RnJvbTogPT9VVEYtOD9xP1JvZ2VyPTIwUGF1PTIwTW9ubj1DMz1BOT89IDxy
b2dlci5wYXVAY2l0cml4LmNvbT4KU3ViamVjdDogeDg2L3NwaW5sb2NrOiBp
bnRyb2R1Y2Ugc3VwcG9ydCBmb3IgYmxvY2tpbmcgc3BlY3VsYXRpb24gaW50
bwogY3JpdGljYWwgcmVnaW9ucwoKSW50cm9kdWNlIGEgbmV3IEtjb25maWcg
b3B0aW9uIHRvIGJsb2NrIHNwZWN1bGF0aW9uIGludG8gbG9jayBwcm90ZWN0
ZWQKY3JpdGljYWwgcmVnaW9ucy4gIFRoZSBLY29uZmlnIG9wdGlvbiBpcyBl
bmFibGVkIGJ5IGRlZmF1bHQsIGJ1dCB0aGUgbWl0aWdhdGlvbgp3b24ndCBi
ZSBlbmdhZ2VkIHVubGVzcyBpdCdzIGV4cGxpY2l0bHkgZW5hYmxlZCBpbiB0
aGUgY29tbWFuZCBsaW5lIHVzaW5nCmBzcGVjLWN0cmw9bG9jay1oYXJkZW5g
LgoKQ29udmVydCB0aGUgc3BpbmxvY2sgYWNxdWlyZSBtYWNyb3MgaW50byBh
bHdheXMtaW5saW5lIGZ1bmN0aW9ucywgYW5kIGludHJvZHVjZQphIHNwZWN1
bGF0aW9uIGJhcnJpZXIgYWZ0ZXIgdGhlIGxvY2sgaGFzIGJlZW4gdGFrZW4u
ICBOb3RlIHRoZSBzcGVjdWxhdGlvbgpiYXJyaWVyIGlzIG5vdCBwbGFjZWQg
aW5zaWRlIHRoZSBpbXBsZW1lbnRhdGlvbiBvZiB0aGUgc3BpbiBsb2NrIGZ1
bmN0aW9ucywgYXMKdG8gcHJldmVudCBzcGVjdWxhdGlvbiBmcm9tIGZhbGxp
bmcgdGhyb3VnaCB0aGUgY2FsbCB0byB0aGUgbG9jayBmdW5jdGlvbnMKcmVz
dWx0aW5nIGluIHRoZSBiYXJyaWVyIGFsc28gYmVpbmcgc2tpcHBlZC4KCnRy
eWxvY2sgdmFyaWFudHMgYXJlIHByb3RlY3RlZCB1c2luZyBhIGNvbnN0cnVj
dCBha2luIHRvIHRoZSBleGlzdGluZwpldmFsdWF0ZV9ub3NwZWMoKS4KClRo
aXMgcGF0Y2ggb25seSBpbXBsZW1lbnRzIHRoZSBzcGVjdWxhdGlvbiBiYXJy
aWVyIGZvciB4ODYuCgpOb3RlIHNwaW4gbG9ja3MgYXJlIHRoZSBvbmx5IGxv
Y2tpbmcgcHJpbWl0aXZlIHRha2VuIGNhcmUgaW4gdGhpcyBjaGFuZ2UsCmZ1
cnRoZXIgbG9ja2luZyBwcmltaXRpdmVzIHdpbGwgYmUgYWRqdXN0ZWQgYnkg
c2VwYXJhdGUgY2hhbmdlcy4KClRoaXMgaXMgcGFydCBvZiBYU0EtNDUzIC8g
Q1ZFLTIwMjQtMjE5MwoKU2lnbmVkLW9mZi1ieTogUm9nZXIgUGF1IE1vbm7D
qSA8cm9nZXIucGF1QGNpdHJpeC5jb20+ClJldmlld2VkLWJ5OiBKYW4gQmV1
bGljaCA8amJldWxpY2hAc3VzZS5jb20+CihjaGVycnkgcGlja2VkIGZyb20g
Y29tbWl0IDdlZjAwODQ0MThlMTg4ZDA1ZjMzOGMzZTAyOGZiYmU4YjY5MjRh
ZmEpCgpkaWZmIC0tZ2l0IGEvZG9jcy9taXNjL3hlbi1jb21tYW5kLWxpbmUu
cGFuZG9jIGIvZG9jcy9taXNjL3hlbi1jb21tYW5kLWxpbmUucGFuZG9jCmlu
ZGV4IGQwMjBkNzlkZGUyNS4uNWU2M2UzZDgyMjRlIDEwMDY0NAotLS0gYS9k
b2NzL21pc2MveGVuLWNvbW1hbmQtbGluZS5wYW5kb2MKKysrIGIvZG9jcy9t
aXNjL3hlbi1jb21tYW5kLWxpbmUucGFuZG9jCkBAIC0yMTg5LDcgKzIxODks
NyBAQCBCeSBkZWZhdWx0IFNTQkQgd2lsbCBiZSBtaXRpZ2F0ZWQgYXQgcnVu
dGltZSAoaS5lIGBzc2JkPXJ1bnRpbWVgKS4KID4gICAgICAgICAgICAgIHtt
c3Itc2MscnNiLHZlcncsaWJwYi1lbnRyeX09PGJvb2w+fHtwdixodm19PTxi
b29sPiwKID4gICAgICAgICAgICAgIGJ0aS10aHVuaz1yZXRwb2xpbmV8bGZl
bmNlfGptcCwge2licnMsaWJwYixzc2JkLHBzZmQsCiA+ICAgICAgICAgICAg
ICBlYWdlci1mcHUsbDFkLWZsdXNoLGJyYW5jaC1oYXJkZW4sc3JiLWxvY2ss
Ci0+ICAgICAgICAgICAgICB1bnByaXYtbW1pbyxnZHMtbWl0LGRpdi1zY3J1
Yn09PGJvb2w+IF1gCis+ICAgICAgICAgICAgICB1bnByaXYtbW1pbyxnZHMt
bWl0LGRpdi1zY3J1Yixsb2NrLWhhcmRlbn09PGJvb2w+IF1gCiAKIENvbnRy
b2xzIGZvciBzcGVjdWxhdGl2ZSBleGVjdXRpb24gc2lkZWNoYW5uZWwgbWl0
aWdhdGlvbnMuICBCeSBkZWZhdWx0LCBYZW4KIHdpbGwgcGljayB0aGUgbW9z
dCBhcHByb3ByaWF0ZSBtaXRpZ2F0aW9ucyBiYXNlZCBvbiBjb21waWxlZCBp
biBzdXBwb3J0LApAQCAtMjMxNCw2ICsyMzE0LDExIEBAIE9uIGFsbCBoYXJk
d2FyZSwgdGhlIGBkaXYtc2NydWI9YCBvcHRpb24gY2FuIGJlIHVzZWQgdG8g
Zm9yY2Ugb3IgcHJldmVudCBYZW4KIGZyb20gbWl0aWdhdGluZyB0aGUgRElW
LWxlYWthZ2UgdnVsbmVyYWJpbGl0eS4gIEJ5IGRlZmF1bHQsIFhlbiB3aWxs
IG1pdGlnYXRlCiBESVYtbGVha2FnZSBvbiBoYXJkd2FyZSBiZWxpZXZlZCB0
byBiZSB2dWxuZXJhYmxlLgogCitJZiBYZW4gaXMgY29tcGlsZWQgd2l0aCBg
Q09ORklHX1NQRUNVTEFUSVZFX0hBUkRFTl9MT0NLYCwgdGhlIGBsb2NrLWhh
cmRlbj1gCitib29sZWFuIGNhbiBiZSB1c2VkIHRvIGZvcmNlIG9yIHByZXZl
bnQgWGVuIGZyb20gdXNpbmcgc3BlY3VsYXRpb24gYmFycmllcnMgdG8KK3By
b3RlY3QgbG9jayBjcml0aWNhbCByZWdpb25zLiAgVGhpcyBtaXRpZ2F0aW9u
IHdvbid0IGJlIGVuZ2FnZWQgYnkgZGVmYXVsdCwKK2FuZCBuZWVkcyB0byBi
ZSBleHBsaWNpdGx5IGVuYWJsZWQgb24gdGhlIGNvbW1hbmQgbGluZS4KKwog
IyMjIHN5bmNfY29uc29sZQogPiBgPSA8Ym9vbGVhbj5gCiAKZGlmZiAtLWdp
dCBhL3hlbi9hcmNoL3g4Ni9zcGVjX2N0cmwuYyBiL3hlbi9hcmNoL3g4Ni9z
cGVjX2N0cmwuYwppbmRleCBkZDg2Yjg5YmIxNTMuLmIyNGMzNmM5OWU2ZiAx
MDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L3NwZWNfY3RybC5jCisrKyBiL3hl
bi9hcmNoL3g4Ni9zcGVjX2N0cmwuYwpAQCAtNjMsNiArNjMsNyBAQCBpbnQ4
X3QgX19yZWFkX21vc3RseSBvcHRfaWJwYl9jdHh0X3N3aXRjaCA9IC0xOwog
aW50OF90IF9fcmVhZF9tb3N0bHkgb3B0X2VhZ2VyX2ZwdSA9IC0xOwogaW50
OF90IF9fcmVhZF9tb3N0bHkgb3B0X2wxZF9mbHVzaCA9IC0xOwogYm9vbCBf
X3JlYWRfbW9zdGx5IG9wdF9icmFuY2hfaGFyZGVuID0gdHJ1ZTsKK3N0YXRp
YyBib29sIF9faW5pdGRhdGEgb3B0X2xvY2tfaGFyZGVuOwogCiBib29sIF9f
aW5pdGRhdGEgYnNwX2RlbGF5X3NwZWNfY3RybDsKIHVpbnQ4X3QgX19yZWFk
X21vc3RseSBkZWZhdWx0X3hlbl9zcGVjX2N0cmw7CkBAIC0xMzEsNiArMTMy
LDcgQEAgc3RhdGljIGludCBfX2luaXQgcGFyc2Vfc3BlY19jdHJsKGNvbnN0
IGNoYXIgKnMpCiAgICAgICAgICAgICBvcHRfc3NiZCA9IGZhbHNlOwogICAg
ICAgICAgICAgb3B0X2wxZF9mbHVzaCA9IDA7CiAgICAgICAgICAgICBvcHRf
YnJhbmNoX2hhcmRlbiA9IGZhbHNlOworICAgICAgICAgICAgb3B0X2xvY2tf
aGFyZGVuID0gZmFsc2U7CiAgICAgICAgICAgICBvcHRfc3JiX2xvY2sgPSAw
OwogICAgICAgICAgICAgb3B0X3VucHJpdl9tbWlvID0gZmFsc2U7CiAgICAg
ICAgICAgICBvcHRfZ2RzX21pdCA9IDA7CkBAIC0yODIsNiArMjg0LDE2IEBA
IHN0YXRpYyBpbnQgX19pbml0IHBhcnNlX3NwZWNfY3RybChjb25zdCBjaGFy
ICpzKQogICAgICAgICAgICAgb3B0X2wxZF9mbHVzaCA9IHZhbDsKICAgICAg
ICAgZWxzZSBpZiAoICh2YWwgPSBwYXJzZV9ib29sZWFuKCJicmFuY2gtaGFy
ZGVuIiwgcywgc3MpKSA+PSAwICkKICAgICAgICAgICAgIG9wdF9icmFuY2hf
aGFyZGVuID0gdmFsOworICAgICAgICBlbHNlIGlmICggKHZhbCA9IHBhcnNl
X2Jvb2xlYW4oImxvY2staGFyZGVuIiwgcywgc3MpKSA+PSAwICkKKyAgICAg
ICAgeworICAgICAgICAgICAgaWYgKCBJU19FTkFCTEVEKENPTkZJR19TUEVD
VUxBVElWRV9IQVJERU5fTE9DSykgKQorICAgICAgICAgICAgICAgIG9wdF9s
b2NrX2hhcmRlbiA9IHZhbDsKKyAgICAgICAgICAgIGVsc2UKKyAgICAgICAg
ICAgIHsKKyAgICAgICAgICAgICAgICBub19jb25maWdfcGFyYW0oIlNQRUNV
TEFUSVZFX0hBUkRFTl9MT0NLIiwgInNwZWMtY3RybCIsIHMsIHNzKTsKKyAg
ICAgICAgICAgICAgICByYyA9IC1FSU5WQUw7CisgICAgICAgICAgICB9Cisg
ICAgICAgIH0KICAgICAgICAgZWxzZSBpZiAoICh2YWwgPSBwYXJzZV9ib29s
ZWFuKCJzcmItbG9jayIsIHMsIHNzKSkgPj0gMCApCiAgICAgICAgICAgICBv
cHRfc3JiX2xvY2sgPSB2YWw7CiAgICAgICAgIGVsc2UgaWYgKCAodmFsID0g
cGFyc2VfYm9vbGVhbigidW5wcml2LW1taW8iLCBzLCBzcykpID49IDAgKQpA
QCAtNDgxLDE4ICs0OTMsMjIgQEAgc3RhdGljIHZvaWQgX19pbml0IHByaW50
X2RldGFpbHMoZW51bSBpbmRfdGh1bmsgdGh1bmspCiAgICAgICAgICAgIChl
MjFhICYgY3B1ZmVhdF9tYXNrKFg4Nl9GRUFUVVJFX1NCUEIpKSAgICAgICAg
ICAgPyAiIFNCUEIiICAgICAgICAgICA6ICIiKTsKIAogICAgIC8qIENvbXBp
bGVkLWluIHN1cHBvcnQgd2hpY2ggcGVydGFpbnMgdG8gbWl0aWdhdGlvbnMu
ICovCi0gICAgaWYgKCBJU19FTkFCTEVEKENPTkZJR19JTkRJUkVDVF9USFVO
SykgfHwgSVNfRU5BQkxFRChDT05GSUdfU0hBRE9XX1BBR0lORykgKQorICAg
IGlmICggSVNfRU5BQkxFRChDT05GSUdfSU5ESVJFQ1RfVEhVTkspIHx8IElT
X0VOQUJMRUQoQ09ORklHX1NIQURPV19QQUdJTkcpIHx8CisgICAgICAgICBJ
U19FTkFCTEVEKENPTkZJR19TUEVDVUxBVElWRV9IQVJERU5fTE9DSykgKQog
ICAgICAgICBwcmludGsoIiAgQ29tcGlsZWQtaW4gc3VwcG9ydDoiCiAjaWZk
ZWYgQ09ORklHX0lORElSRUNUX1RIVU5LCiAgICAgICAgICAgICAgICAiIElO
RElSRUNUX1RIVU5LIgogI2VuZGlmCiAjaWZkZWYgQ09ORklHX1NIQURPV19Q
QUdJTkcKICAgICAgICAgICAgICAgICIgU0hBRE9XX1BBR0lORyIKKyNlbmRp
ZgorI2lmZGVmIENPTkZJR19TUEVDVUxBVElWRV9IQVJERU5fTE9DSworICAg
ICAgICAgICAgICAgIiBIQVJERU5fTE9DSyIKICNlbmRpZgogICAgICAgICAg
ICAgICAgIlxuIik7CiAKICAgICAvKiBTZXR0aW5ncyBmb3IgWGVuJ3MgcHJv
dGVjdGlvbiwgaXJyZXNwZWN0aXZlIG9mIGd1ZXN0cy4gKi8KLSAgICBwcmlu
dGsoIiAgWGVuIHNldHRpbmdzOiBCVEktVGh1bmsgJXMsIFNQRUNfQ1RSTDog
JXMlcyVzJXMlcywgT3RoZXI6JXMlcyVzJXMlcyVzXG4iLAorICAgIHByaW50
aygiICBYZW4gc2V0dGluZ3M6IEJUSS1UaHVuayAlcywgU1BFQ19DVFJMOiAl
cyVzJXMlcyVzLCBPdGhlcjolcyVzJXMlcyVzJXMlc1xuIiwKICAgICAgICAg
ICAgdGh1bmsgPT0gVEhVTktfTk9ORSAgICAgID8gIk4vQSIgOgogICAgICAg
ICAgICB0aHVuayA9PSBUSFVOS19SRVRQT0xJTkUgPyAiUkVUUE9MSU5FIiA6
CiAgICAgICAgICAgIHRodW5rID09IFRIVU5LX0xGRU5DRSAgICA/ICJMRkVO
Q0UiIDoKQEAgLTUxOCw3ICs1MzQsOCBAQCBzdGF0aWMgdm9pZCBfX2luaXQg
cHJpbnRfZGV0YWlscyhlbnVtIGluZF90aHVuayB0aHVuaykKICAgICAgICAg
ICAgb3B0X3ZlcndfcHYgfHwgb3B0X3ZlcndfaHZtIHx8CiAgICAgICAgICAg
IG9wdF92ZXJ3X21taW8gICAgICAgICAgICAgICAgICAgICAgICAgICAgID8g
IiBWRVJXIiAgOiAiIiwKICAgICAgICAgICAgb3B0X2Rpdl9zY3J1YiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgPyAiIERJViIgOiAiIiwKLSAgICAg
ICAgICAgb3B0X2JyYW5jaF9oYXJkZW4gICAgICAgICAgICAgICAgICAgICAg
ICAgPyAiIEJSQU5DSF9IQVJERU4iIDogIiIpOworICAgICAgICAgICBvcHRf
YnJhbmNoX2hhcmRlbiAgICAgICAgICAgICAgICAgICAgICAgICA/ICIgQlJB
TkNIX0hBUkRFTiIgOiAiIiwKKyAgICAgICAgICAgb3B0X2xvY2tfaGFyZGVu
ICAgICAgICAgICAgICAgICAgICAgICAgICAgPyAiIExPQ0tfSEFSREVOIiA6
ICIiKTsKIAogICAgIC8qIEwxVEYgZGlhZ25vc3RpY3MsIHByaW50ZWQgaWYg
dnVsbmVyYWJsZSBvciBQViBzaGFkb3dpbmcgaXMgaW4gdXNlLiAqLwogICAg
IGlmICggY3B1X2hhc19idWdfbDF0ZiB8fCBvcHRfcHZfbDF0Zl9od2RvbSB8
fCBvcHRfcHZfbDF0Zl9kb211ICkKQEAgLTE4MTYsNiArMTgzMyw5IEBAIHZv
aWQgX19pbml0IGluaXRfc3BlY3VsYXRpb25fbWl0aWdhdGlvbnModm9pZCkK
ICAgICBpZiAoIG9wdF9icmFuY2hfaGFyZGVuICkKICAgICAgICAgc2V0dXBf
Zm9yY2VfY3B1X2NhcChYODZfRkVBVFVSRV9TQ19CUkFOQ0hfSEFSREVOKTsK
IAorICAgIGlmICggIW9wdF9sb2NrX2hhcmRlbiApCisgICAgICAgIHNldHVw
X2ZvcmNlX2NwdV9jYXAoWDg2X0ZFQVRVUkVfU0NfTk9fTE9DS19IQVJERU4p
OworCiAgICAgLyoKICAgICAgKiBXZSBkbyBub3QgZGlzYWJsZSBIVCBieSBk
ZWZhdWx0IG9uIGFmZmVjdGVkIGhhcmR3YXJlLgogICAgICAqCmRpZmYgLS1n
aXQgYS94ZW4vY29tbW9uL0tjb25maWcgYi94ZW4vY29tbW9uL0tjb25maWcK
aW5kZXggZWI5NTNkMTcxZWIyLi5hYTE4ZDQyM2IyM2MgMTAwNjQ0Ci0tLSBh
L3hlbi9jb21tb24vS2NvbmZpZworKysgYi94ZW4vY29tbW9uL0tjb25maWcK
QEAgLTEyOSw2ICsxMjksMjMgQEAgY29uZmlnIFNQRUNVTEFUSVZFX0hBUkRF
Tl9HVUVTVF9BQ0NFU1MKIAogCSAgSWYgdW5zdXJlLCBzYXkgWS4KIAorY29u
ZmlnIFNQRUNVTEFUSVZFX0hBUkRFTl9MT0NLCisJYm9vbCAiU3BlY3VsYXRp
dmUgbG9jayBjb250ZXh0IGhhcmRlbmluZyIKKwlkZWZhdWx0IHkKKwlkZXBl
bmRzIG9uIFg4NgorCWhlbHAKKwkgIENvbnRlbXBvcmFyeSBwcm9jZXNzb3Jz
IG1heSB1c2Ugc3BlY3VsYXRpdmUgZXhlY3V0aW9uIGFzIGEKKwkgIHBlcmZv
cm1hbmNlIG9wdGltaXNhdGlvbiwgYnV0IHRoaXMgY2FuIHBvdGVudGlhbGx5
IGJlIGFidXNlZCBieSBhbgorCSAgYXR0YWNrZXIgdG8gbGVhayBkYXRhIHZp
YSBzcGVjdWxhdGl2ZSBzaWRlY2hhbm5lbHMuCisKKwkgIE9uZSBzb3VyY2Ug
b2YgZGF0YSBsZWFrYWdlIGlzIHZpYSBzcGVjdWxhdGl2ZSBhY2Nlc3NlcyB0
byBsb2NrCisJICBjcml0aWNhbCByZWdpb25zLgorCisJICBUaGlzIG9wdGlv
biBpcyBkaXNhYmxlZCBieSBkZWZhdWx0IGF0IHJ1biB0aW1lLCBhbmQgbmVl
ZHMgdG8gYmUKKwkgIGVuYWJsZWQgb24gdGhlIGNvbW1hbmQgbGluZS4KKwor
CSAgSWYgdW5zdXJlLCBzYXkgWS4KKwogZW5kbWVudQogCiBjb25maWcgSFlQ
RlMKZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL2FzbS14ODYvY3B1ZmVhdHVy
ZXMuaCBiL3hlbi9pbmNsdWRlL2FzbS14ODYvY3B1ZmVhdHVyZXMuaAppbmRl
eCBkOTkzZTA2ZTRjZTguLjI0YTE4MmQzN2YyMSAxMDA2NDQKLS0tIGEveGVu
L2luY2x1ZGUvYXNtLXg4Ni9jcHVmZWF0dXJlcy5oCisrKyBiL3hlbi9pbmNs
dWRlL2FzbS14ODYvY3B1ZmVhdHVyZXMuaApAQCAtMjQsNyArMjQsNyBAQCBY
RU5fQ1BVRkVBVFVSRShBUEVSRk1QRVJGLCAgICAgICAgWDg2X1NZTlRIKCA4
KSkgLyogQVBFUkZNUEVSRiAqLwogWEVOX0NQVUZFQVRVUkUoTUZFTkNFX1JE
VFNDLCAgICAgIFg4Nl9TWU5USCggOSkpIC8qIE1GRU5DRSBzeW5jaHJvbml6
ZXMgUkRUU0MgKi8KIFhFTl9DUFVGRUFUVVJFKFhFTl9TTUVQLCAgICAgICAg
ICBYODZfU1lOVEgoMTApKSAvKiBTTUVQIGdldHMgdXNlZCBieSBYZW4gaXRz
ZWxmICovCiBYRU5fQ1BVRkVBVFVSRShYRU5fU01BUCwgICAgICAgICAgWDg2
X1NZTlRIKDExKSkgLyogU01BUCBnZXRzIHVzZWQgYnkgWGVuIGl0c2VsZiAq
LwotLyogQml0IDEyIC0gdW51c2VkLiAqLworWEVOX0NQVUZFQVRVUkUoU0Nf
Tk9fTE9DS19IQVJERU4sIFg4Nl9TWU5USCgxMikpIC8qIChEaXNhYmxlKSBM
b2NrIGNyaXRpY2FsIHJlZ2lvbiBoYXJkZW5pbmcgKi8KIFhFTl9DUFVGRUFU
VVJFKElORF9USFVOS19MRkVOQ0UsICBYODZfU1lOVEgoMTMpKSAvKiBVc2Ug
SU5EX1RIVU5LX0xGRU5DRSAqLwogWEVOX0NQVUZFQVRVUkUoSU5EX1RIVU5L
X0pNUCwgICAgIFg4Nl9TWU5USCgxNCkpIC8qIFVzZSBJTkRfVEhVTktfSk1Q
ICovCiBYRU5fQ1BVRkVBVFVSRShTQ19CUkFOQ0hfSEFSREVOLCAgWDg2X1NZ
TlRIKDE1KSkgLyogQ29uZGl0aW9uYWwgQnJhbmNoIEhhcmRlbmluZyAqLwpk
aWZmIC0tZ2l0IGEveGVuL2luY2x1ZGUvYXNtLXg4Ni9ub3NwZWMuaCBiL3hl
bi9pbmNsdWRlL2FzbS14ODYvbm9zcGVjLmgKaW5kZXggZjZlYjg0ZWVlNTU0
Li5lMzhmNTZjYmU4ZjQgMTAwNjQ0Ci0tLSBhL3hlbi9pbmNsdWRlL2FzbS14
ODYvbm9zcGVjLmgKKysrIGIveGVuL2luY2x1ZGUvYXNtLXg4Ni9ub3NwZWMu
aApAQCAtMjcsNiArMjcsMzIgQEAgc3RhdGljIGFsd2F5c19pbmxpbmUgdm9p
ZCBibG9ja19zcGVjdWxhdGlvbih2b2lkKQogICAgIGJhcnJpZXJfbm9zcGVj
X3RydWUoKTsKIH0KIAorc3RhdGljIGFsd2F5c19pbmxpbmUgdm9pZCBhcmNo
X2Jsb2NrX2xvY2tfc3BlY3VsYXRpb24odm9pZCkKK3sKKyAgICBhbHRlcm5h
dGl2ZSgibGZlbmNlIiwgIiIsIFg4Nl9GRUFUVVJFX1NDX05PX0xPQ0tfSEFS
REVOKTsKK30KKworLyogQWxsb3cgdG8gaW5zZXJ0IGEgcmVhZCBtZW1vcnkg
YmFycmllciBpbnRvIGNvbmRpdGlvbmFscyAqLworc3RhdGljIGFsd2F5c19p
bmxpbmUgYm9vbCBiYXJyaWVyX2xvY2tfdHJ1ZSh2b2lkKQoreworICAgIGFs
dGVybmF0aXZlKCJsZmVuY2UgI25vc3BlYy10cnVlIiwgIiIsIFg4Nl9GRUFU
VVJFX1NDX05PX0xPQ0tfSEFSREVOKTsKKyAgICByZXR1cm4gdHJ1ZTsKK30K
Kworc3RhdGljIGFsd2F5c19pbmxpbmUgYm9vbCBiYXJyaWVyX2xvY2tfZmFs
c2Uodm9pZCkKK3sKKyAgICBhbHRlcm5hdGl2ZSgibGZlbmNlICNub3NwZWMt
ZmFsc2UiLCAiIiwgWDg2X0ZFQVRVUkVfU0NfTk9fTE9DS19IQVJERU4pOwor
ICAgIHJldHVybiBmYWxzZTsKK30KKworc3RhdGljIGFsd2F5c19pbmxpbmUg
Ym9vbCBhcmNoX2xvY2tfZXZhbHVhdGVfbm9zcGVjKGJvb2wgY29uZGl0aW9u
KQoreworICAgIGlmICggY29uZGl0aW9uICkKKyAgICAgICAgcmV0dXJuIGJh
cnJpZXJfbG9ja190cnVlKCk7CisgICAgZWxzZQorICAgICAgICByZXR1cm4g
YmFycmllcl9sb2NrX2ZhbHNlKCk7Cit9CisKICNlbmRpZiAvKiBfQVNNX1g4
Nl9OT1NQRUNfSCAqLwogCiAvKgpkaWZmIC0tZ2l0IGEveGVuL2luY2x1ZGUv
eGVuL25vc3BlYy5oIGIveGVuL2luY2x1ZGUveGVuL25vc3BlYy5oCmluZGV4
IDc2MjU1YmM0NmVmZS4uNDU1Mjg0NjQwMzk2IDEwMDY0NAotLS0gYS94ZW4v
aW5jbHVkZS94ZW4vbm9zcGVjLmgKKysrIGIveGVuL2luY2x1ZGUveGVuL25v
c3BlYy5oCkBAIC03MCw2ICs3MCwyMSBAQCBzdGF0aWMgaW5saW5lIHVuc2ln
bmVkIGxvbmcgYXJyYXlfaW5kZXhfbWFza19ub3NwZWModW5zaWduZWQgbG9u
ZyBpbmRleCwKICNkZWZpbmUgYXJyYXlfYWNjZXNzX25vc3BlYyhhcnJheSwg
aW5kZXgpICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKICAgICAo
YXJyYXkpW2FycmF5X2luZGV4X25vc3BlYyhpbmRleCwgQVJSQVlfU0laRShh
cnJheSkpXQogCitzdGF0aWMgYWx3YXlzX2lubGluZSB2b2lkIGJsb2NrX2xv
Y2tfc3BlY3VsYXRpb24odm9pZCkKK3sKKyNpZmRlZiBDT05GSUdfU1BFQ1VM
QVRJVkVfSEFSREVOX0xPQ0sKKyAgICBhcmNoX2Jsb2NrX2xvY2tfc3BlY3Vs
YXRpb24oKTsKKyNlbmRpZgorfQorCitzdGF0aWMgYWx3YXlzX2lubGluZSBi
b29sIGxvY2tfZXZhbHVhdGVfbm9zcGVjKGJvb2wgY29uZGl0aW9uKQorewor
I2lmZGVmIENPTkZJR19TUEVDVUxBVElWRV9IQVJERU5fTE9DSworICAgIHJl
dHVybiBhcmNoX2xvY2tfZXZhbHVhdGVfbm9zcGVjKGNvbmRpdGlvbik7Cisj
ZW5kaWYKKyAgICByZXR1cm4gY29uZGl0aW9uOworfQorCiAjZW5kaWYgLyog
WEVOX05PU1BFQ19IICovCiAKIC8qCmRpZmYgLS1naXQgYS94ZW4vaW5jbHVk
ZS94ZW4vc3BpbmxvY2suaCBiL3hlbi9pbmNsdWRlL3hlbi9zcGlubG9jay5o
CmluZGV4IDlmYTRlNjAwYzFmNy4uZWZkYjIxZWE5MDcyIDEwMDY0NAotLS0g
YS94ZW4vaW5jbHVkZS94ZW4vc3BpbmxvY2suaAorKysgYi94ZW4vaW5jbHVk
ZS94ZW4vc3BpbmxvY2suaApAQCAtMSw2ICsxLDcgQEAKICNpZm5kZWYgX19T
UElOTE9DS19IX18KICNkZWZpbmUgX19TUElOTE9DS19IX18KIAorI2luY2x1
ZGUgPHhlbi9ub3NwZWMuaD4KICNpbmNsdWRlIDx4ZW4vdGltZS5oPgogI2lu
Y2x1ZGUgPGFzbS9zeXN0ZW0uaD4KICNpbmNsdWRlIDxhc20vc3BpbmxvY2su
aD4KQEAgLTE4OSwxMyArMTkwLDMwIEBAIGludCBfc3Bpbl90cnlsb2NrX3Jl
Y3Vyc2l2ZShzcGlubG9ja190ICpsb2NrKTsKIHZvaWQgX3NwaW5fbG9ja19y
ZWN1cnNpdmUoc3BpbmxvY2tfdCAqbG9jayk7CiB2b2lkIF9zcGluX3VubG9j
a19yZWN1cnNpdmUoc3BpbmxvY2tfdCAqbG9jayk7CiAKLSNkZWZpbmUgc3Bp
bl9sb2NrKGwpICAgICAgICAgICAgICAgICAgX3NwaW5fbG9jayhsKQotI2Rl
ZmluZSBzcGluX2xvY2tfY2IobCwgYywgZCkgICAgICAgICBfc3Bpbl9sb2Nr
X2NiKGwsIGMsIGQpCi0jZGVmaW5lIHNwaW5fbG9ja19pcnEobCkgICAgICAg
ICAgICAgIF9zcGluX2xvY2tfaXJxKGwpCitzdGF0aWMgYWx3YXlzX2lubGlu
ZSB2b2lkIHNwaW5fbG9jayhzcGlubG9ja190ICpsKQoreworICAgIF9zcGlu
X2xvY2sobCk7CisgICAgYmxvY2tfbG9ja19zcGVjdWxhdGlvbigpOworfQor
CitzdGF0aWMgYWx3YXlzX2lubGluZSB2b2lkIHNwaW5fbG9ja19jYihzcGlu
bG9ja190ICpsLCB2b2lkICgqYykodm9pZCAqZGF0YSksCisgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB2b2lkICpkKQoreworICAg
IF9zcGluX2xvY2tfY2IobCwgYywgZCk7CisgICAgYmxvY2tfbG9ja19zcGVj
dWxhdGlvbigpOworfQorCitzdGF0aWMgYWx3YXlzX2lubGluZSB2b2lkIHNw
aW5fbG9ja19pcnEoc3BpbmxvY2tfdCAqbCkKK3sKKyAgICBfc3Bpbl9sb2Nr
X2lycShsKTsKKyAgICBibG9ja19sb2NrX3NwZWN1bGF0aW9uKCk7Cit9CisK
ICNkZWZpbmUgc3Bpbl9sb2NrX2lycXNhdmUobCwgZikgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBcCiAgICAgKHsgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAog
ICAgICAgICBCVUlMRF9CVUdfT04oc2l6ZW9mKGYpICE9IHNpemVvZih1bnNp
Z25lZCBsb25nKSk7ICAgICAgIFwKICAgICAgICAgKChmKSA9IF9zcGluX2xv
Y2tfaXJxc2F2ZShsKSk7ICAgICAgICAgICAgICAgICAgICAgICAgICBcCisg
ICAgICAgIGJsb2NrX2xvY2tfc3BlY3VsYXRpb24oKTsgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgXAogICAgIH0pCiAKICNkZWZpbmUgc3Bpbl91
bmxvY2sobCkgICAgICAgICAgICAgICAgX3NwaW5fdW5sb2NrKGwpCkBAIC0y
MDMsNyArMjIxLDcgQEAgdm9pZCBfc3Bpbl91bmxvY2tfcmVjdXJzaXZlKHNw
aW5sb2NrX3QgKmxvY2spOwogI2RlZmluZSBzcGluX3VubG9ja19pcnFyZXN0
b3JlKGwsIGYpICBfc3Bpbl91bmxvY2tfaXJxcmVzdG9yZShsLCBmKQogCiAj
ZGVmaW5lIHNwaW5faXNfbG9ja2VkKGwpICAgICAgICAgICAgIF9zcGluX2lz
X2xvY2tlZChsKQotI2RlZmluZSBzcGluX3RyeWxvY2sobCkgICAgICAgICAg
ICAgICBfc3Bpbl90cnlsb2NrKGwpCisjZGVmaW5lIHNwaW5fdHJ5bG9jayhs
KSAgICAgICAgICAgICAgIGxvY2tfZXZhbHVhdGVfbm9zcGVjKF9zcGluX3Ry
eWxvY2sobCkpCiAKICNkZWZpbmUgc3Bpbl90cnlsb2NrX2lycXNhdmUobG9j
aywgZmxhZ3MpICAgICAgIFwKICh7ICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIFwKQEAgLTIyNCw4ICsyNDIsMTUgQEAg
dm9pZCBfc3Bpbl91bmxvY2tfcmVjdXJzaXZlKHNwaW5sb2NrX3QgKmxvY2sp
OwogICogYXJlIGFueSBjcml0aWNhbCByZWdpb25zIHRoYXQgY2Fubm90IGZv
cm0gcGFydCBvZiBzdWNoIGEgc2V0LCB0aGV5IGNhbiB1c2UKICAqIHN0YW5k
YXJkIHNwaW5fW3VuXWxvY2soKS4KICAqLwotI2RlZmluZSBzcGluX3RyeWxv
Y2tfcmVjdXJzaXZlKGwpICAgICBfc3Bpbl90cnlsb2NrX3JlY3Vyc2l2ZShs
KQotI2RlZmluZSBzcGluX2xvY2tfcmVjdXJzaXZlKGwpICAgICAgICBfc3Bp
bl9sb2NrX3JlY3Vyc2l2ZShsKQorI2RlZmluZSBzcGluX3RyeWxvY2tfcmVj
dXJzaXZlKGwpIFwKKyAgICBsb2NrX2V2YWx1YXRlX25vc3BlYyhfc3Bpbl90
cnlsb2NrX3JlY3Vyc2l2ZShsKSkKKworc3RhdGljIGFsd2F5c19pbmxpbmUg
dm9pZCBzcGluX2xvY2tfcmVjdXJzaXZlKHNwaW5sb2NrX3QgKmwpCit7Cisg
ICAgX3NwaW5fbG9ja19yZWN1cnNpdmUobCk7CisgICAgYmxvY2tfbG9ja19z
cGVjdWxhdGlvbigpOworfQorCiAjZGVmaW5lIHNwaW5fdW5sb2NrX3JlY3Vy
c2l2ZShsKSAgICAgIF9zcGluX3VubG9ja19yZWN1cnNpdmUobCkKIAogI2Vu
ZGlmIC8qIF9fU1BJTkxPQ0tfSF9fICovCg==

--=separator
Content-Type: application/octet-stream; name="xsa453/xsa453-4.15-4.patch"
Content-Disposition: attachment; filename="xsa453/xsa453-4.15-4.patch"
Content-Transfer-Encoding: base64

RnJvbTogPT9VVEYtOD9xP1JvZ2VyPTIwUGF1PTIwTW9ubj1DMz1BOT89IDxy
b2dlci5wYXVAY2l0cml4LmNvbT4KU3ViamVjdDogcndsb2NrOiBpbnRyb2R1
Y2Ugc3VwcG9ydCBmb3IgYmxvY2tpbmcgc3BlY3VsYXRpb24gaW50byBjcml0
aWNhbAogcmVnaW9ucwoKSW50cm9kdWNlIGlubGluZSB3cmFwcGVycyBhcyBy
ZXF1aXJlZCBhbmQgYWRkIGRpcmVjdCBjYWxscyB0bwpibG9ja19sb2NrX3Nw
ZWN1bGF0aW9uKCkgaW4gb3JkZXIgdG8gcHJldmVudCBzcGVjdWxhdGlvbiBp
bnRvIHRoZSByd2xvY2sKcHJvdGVjdGVkIGNyaXRpY2FsIHJlZ2lvbnMuCgpO
b3RlIHRoZSByd2xvY2sgcHJpbWl0aXZlcyBhcmUgYWRqdXN0ZWQgdG8gdXNl
IHRoZSBub24gc3BlY3VsYXRpb24gc2FmZSB2YXJpYW50cwpvZiB0aGUgc3Bp
bmxvY2sgaGFuZGxlcnMsIGFzIGEgc3BlY3VsYXRpb24gYmFycmllciBpcyBh
ZGRlZCBpbiB0aGUgcndsb2NrCmNhbGxpbmcgd3JhcHBlcnMuCgp0cnlsb2Nr
IHZhcmlhbnRzIGFyZSBwcm90ZWN0ZWQgYnkgdXNpbmcgbG9ja19ldmFsdWF0
ZV9ub3NwZWMoKS4KClRoaXMgaXMgcGFydCBvZiBYU0EtNDUzIC8gQ1ZFLTIw
MjQtMjE5MwoKU2lnbmVkLW9mZi1ieTogUm9nZXIgUGF1IE1vbm7DqSA8cm9n
ZXIucGF1QGNpdHJpeC5jb20+ClJldmlld2VkLWJ5OiBKYW4gQmV1bGljaCA8
amJldWxpY2hAc3VzZS5jb20+CihjaGVycnkgcGlja2VkIGZyb20gY29tbWl0
IGExZmIxNWY2MTY5MmIxZmE5OTQ1ZmM1MWY1NTQ3MWFjZTQ5Y2RkNTkpCgpk
aWZmIC0tZ2l0IGEveGVuL2NvbW1vbi9yd2xvY2suYyBiL3hlbi9jb21tb24v
cndsb2NrLmMKaW5kZXggZGFkYWIzNzJiNWUxLi4yNDY0Zjc0NTQ4NWQgMTAw
NjQ0Ci0tLSBhL3hlbi9jb21tb24vcndsb2NrLmMKKysrIGIveGVuL2NvbW1v
bi9yd2xvY2suYwpAQCAtMzQsOCArMzQsMTEgQEAgdm9pZCBxdWV1ZV9yZWFk
X2xvY2tfc2xvd3BhdGgocndsb2NrX3QgKmxvY2spCiAKICAgICAvKgogICAg
ICAqIFB1dCB0aGUgcmVhZGVyIGludG8gdGhlIHdhaXQgcXVldWUuCisgICAg
ICoKKyAgICAgKiBVc2UgdGhlIHNwZWN1bGF0aW9uIHVuc2FmZSBoZWxwZXIs
IGFzIGl0J3MgdGhlIGNhbGxlciByZXNwb25zaWJpbGl0eSB0bworICAgICAq
IGlzc3VlIGEgc3BlY3VsYXRpb24gYmFycmllciBpZiByZXF1aXJlZC4KICAg
ICAgKi8KLSAgICBzcGluX2xvY2soJmxvY2stPmxvY2spOworICAgIF9zcGlu
X2xvY2soJmxvY2stPmxvY2spOwogCiAgICAgLyoKICAgICAgKiBBdCB0aGUg
aGVhZCBvZiB0aGUgd2FpdCBxdWV1ZSBub3csIHdhaXQgdW50aWwgdGhlIHdy
aXRlciBzdGF0ZQpAQCAtNjQsOCArNjcsMTMgQEAgdm9pZCBxdWV1ZV93cml0
ZV9sb2NrX3Nsb3dwYXRoKHJ3bG9ja190ICpsb2NrKQogewogICAgIHUzMiBj
bnRzOwogCi0gICAgLyogUHV0IHRoZSB3cml0ZXIgaW50byB0aGUgd2FpdCBx
dWV1ZS4gKi8KLSAgICBzcGluX2xvY2soJmxvY2stPmxvY2spOworICAgIC8q
CisgICAgICogUHV0IHRoZSB3cml0ZXIgaW50byB0aGUgd2FpdCBxdWV1ZS4K
KyAgICAgKgorICAgICAqIFVzZSB0aGUgc3BlY3VsYXRpb24gdW5zYWZlIGhl
bHBlciwgYXMgaXQncyB0aGUgY2FsbGVyIHJlc3BvbnNpYmlsaXR5IHRvCisg
ICAgICogaXNzdWUgYSBzcGVjdWxhdGlvbiBiYXJyaWVyIGlmIHJlcXVpcmVk
LgorICAgICAqLworICAgIF9zcGluX2xvY2soJmxvY2stPmxvY2spOwogCiAg
ICAgLyogVHJ5IHRvIGFjcXVpcmUgdGhlIGxvY2sgZGlyZWN0bHkgaWYgbm8g
cmVhZGVyIGlzIHByZXNlbnQuICovCiAgICAgaWYgKCAhYXRvbWljX3JlYWQo
JmxvY2stPmNudHMpICYmCmRpZmYgLS1naXQgYS94ZW4vaW5jbHVkZS94ZW4v
cndsb2NrLmggYi94ZW4vaW5jbHVkZS94ZW4vcndsb2NrLmgKaW5kZXggMGNj
OTE2NzcxNWIzLi5mZDA0NThiZTk0YWUgMTAwNjQ0Ci0tLSBhL3hlbi9pbmNs
dWRlL3hlbi9yd2xvY2suaAorKysgYi94ZW4vaW5jbHVkZS94ZW4vcndsb2Nr
LmgKQEAgLTI0NywyNyArMjQ3LDQ5IEBAIHN0YXRpYyBpbmxpbmUgaW50IF9y
d19pc193cml0ZV9sb2NrZWQocndsb2NrX3QgKmxvY2spCiAgICAgcmV0dXJu
IChhdG9taWNfcmVhZCgmbG9jay0+Y250cykgJiBfUVdfV01BU0spID09IF9R
V19MT0NLRUQ7CiB9CiAKLSNkZWZpbmUgcmVhZF9sb2NrKGwpICAgICAgICAg
ICAgICAgICAgX3JlYWRfbG9jayhsKQotI2RlZmluZSByZWFkX2xvY2tfaXJx
KGwpICAgICAgICAgICAgICBfcmVhZF9sb2NrX2lycShsKQorc3RhdGljIGFs
d2F5c19pbmxpbmUgdm9pZCByZWFkX2xvY2socndsb2NrX3QgKmwpCit7Cisg
ICAgX3JlYWRfbG9jayhsKTsKKyAgICBibG9ja19sb2NrX3NwZWN1bGF0aW9u
KCk7Cit9CisKK3N0YXRpYyBhbHdheXNfaW5saW5lIHZvaWQgcmVhZF9sb2Nr
X2lycShyd2xvY2tfdCAqbCkKK3sKKyAgICBfcmVhZF9sb2NrX2lycShsKTsK
KyAgICBibG9ja19sb2NrX3NwZWN1bGF0aW9uKCk7Cit9CisKICNkZWZpbmUg
cmVhZF9sb2NrX2lycXNhdmUobCwgZikgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBcCiAgICAgKHsgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAogICAgICAgICBC
VUlMRF9CVUdfT04oc2l6ZW9mKGYpICE9IHNpemVvZih1bnNpZ25lZCBsb25n
KSk7ICAgICAgIFwKICAgICAgICAgKChmKSA9IF9yZWFkX2xvY2tfaXJxc2F2
ZShsKSk7ICAgICAgICAgICAgICAgICAgICAgICAgICBcCisgICAgICAgIGJs
b2NrX2xvY2tfc3BlY3VsYXRpb24oKTsgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgXAogICAgIH0pCiAKICNkZWZpbmUgcmVhZF91bmxvY2sobCkg
ICAgICAgICAgICAgICAgX3JlYWRfdW5sb2NrKGwpCiAjZGVmaW5lIHJlYWRf
dW5sb2NrX2lycShsKSAgICAgICAgICAgIF9yZWFkX3VubG9ja19pcnEobCkK
ICNkZWZpbmUgcmVhZF91bmxvY2tfaXJxcmVzdG9yZShsLCBmKSAgX3JlYWRf
dW5sb2NrX2lycXJlc3RvcmUobCwgZikKLSNkZWZpbmUgcmVhZF90cnlsb2Nr
KGwpICAgICAgICAgICAgICAgX3JlYWRfdHJ5bG9jayhsKQorI2RlZmluZSBy
ZWFkX3RyeWxvY2sobCkgICAgICAgICAgICAgICBsb2NrX2V2YWx1YXRlX25v
c3BlYyhfcmVhZF90cnlsb2NrKGwpKQorCitzdGF0aWMgYWx3YXlzX2lubGlu
ZSB2b2lkIHdyaXRlX2xvY2socndsb2NrX3QgKmwpCit7CisgICAgX3dyaXRl
X2xvY2sobCk7CisgICAgYmxvY2tfbG9ja19zcGVjdWxhdGlvbigpOworfQor
CitzdGF0aWMgYWx3YXlzX2lubGluZSB2b2lkIHdyaXRlX2xvY2tfaXJxKHJ3
bG9ja190ICpsKQoreworICAgIF93cml0ZV9sb2NrX2lycShsKTsKKyAgICBi
bG9ja19sb2NrX3NwZWN1bGF0aW9uKCk7Cit9CiAKLSNkZWZpbmUgd3JpdGVf
bG9jayhsKSAgICAgICAgICAgICAgICAgX3dyaXRlX2xvY2sobCkKLSNkZWZp
bmUgd3JpdGVfbG9ja19pcnEobCkgICAgICAgICAgICAgX3dyaXRlX2xvY2tf
aXJxKGwpCiAjZGVmaW5lIHdyaXRlX2xvY2tfaXJxc2F2ZShsLCBmKSAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgXAogICAgICh7ICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIFwKICAgICAgICAgQlVJTERfQlVHX09OKHNpemVvZihmKSAhPSBzaXpl
b2YodW5zaWduZWQgbG9uZykpOyAgICAgICBcCiAgICAgICAgICgoZikgPSBf
d3JpdGVfbG9ja19pcnFzYXZlKGwpKTsgICAgICAgICAgICAgICAgICAgICAg
ICAgXAorICAgICAgICBibG9ja19sb2NrX3NwZWN1bGF0aW9uKCk7ICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIFwKICAgICB9KQotI2RlZmluZSB3
cml0ZV90cnlsb2NrKGwpICAgICAgICAgICAgICBfd3JpdGVfdHJ5bG9jayhs
KQorI2RlZmluZSB3cml0ZV90cnlsb2NrKGwpICAgICAgICAgICAgICBsb2Nr
X2V2YWx1YXRlX25vc3BlYyhfd3JpdGVfdHJ5bG9jayhsKSkKIAogI2RlZmlu
ZSB3cml0ZV91bmxvY2sobCkgICAgICAgICAgICAgICBfd3JpdGVfdW5sb2Nr
KGwpCiAjZGVmaW5lIHdyaXRlX3VubG9ja19pcnEobCkgICAgICAgICAgIF93
cml0ZV91bmxvY2tfaXJxKGwpCg==

--=separator
Content-Type: application/octet-stream; name="xsa453/xsa453-4.15-5.patch"
Content-Disposition: attachment; filename="xsa453/xsa453-4.15-5.patch"
Content-Transfer-Encoding: base64

RnJvbTogPT9VVEYtOD9xP1JvZ2VyPTIwUGF1PTIwTW9ubj1DMz1BOT89IDxy
b2dlci5wYXVAY2l0cml4LmNvbT4KU3ViamVjdDogcGVyY3B1LXJ3bG9jazog
aW50cm9kdWNlIHN1cHBvcnQgZm9yIGJsb2NraW5nIHNwZWN1bGF0aW9uIGlu
dG8KIGNyaXRpY2FsIHJlZ2lvbnMKCkFkZCBkaXJlY3QgY2FsbHMgdG8gYmxv
Y2tfbG9ja19zcGVjdWxhdGlvbigpIHdoZXJlIHJlcXVpcmVkIGluIG9yZGVy
IHRvIHByZXZlbnQKc3BlY3VsYXRpb24gaW50byB0aGUgbG9jayBwcm90ZWN0
ZWQgY3JpdGljYWwgcmVnaW9ucy4gIEFsc28gY29udmVydApfcGVyY3B1X3Jl
YWRfbG9jaygpIGZyb20gaW5saW5lIHRvIGFsd2F5c19pbmxpbmUuCgpOb3Rl
IHRoYXQgX3BlcmNwdV93cml0ZV9sb2NrKCkgaGFzIGJlZW4gbW9kaWZpZWQg
dGhlIHVzZSB0aGUgbm9uIHNwZWN1bGF0aW9uCnNhZmUgb2YgdGhlIGxvY2tp
bmcgcHJpbWl0ZXMsIGFzIGEgc3BlY3VsYXRpb24gaXMgYWRkZWQgdW5jb25k
aXRpb25hbGx5IGJ5IHRoZQpjYWxsaW5nIHdyYXBwZXIuCgpUaGlzIGlzIHBh
cnQgb2YgWFNBLTQ1MyAvIENWRS0yMDI0LTIxOTMKClNpZ25lZC1vZmYtYnk6
IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXguY29tPgpSZXZp
ZXdlZC1ieTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgooY2hl
cnJ5IHBpY2tlZCBmcm9tIGNvbW1pdCBmMjE4ZGFmNmQzYTNiODQ3NzM2ZDM3
YzZhNmI3NjAzMWEwZDA4NDQxKQoKZGlmZiAtLWdpdCBhL3hlbi9jb21tb24v
cndsb2NrLmMgYi94ZW4vY29tbW9uL3J3bG9jay5jCmluZGV4IDI0NjRmNzQ1
NDg1ZC4uNzAzMjc2ZjRhYTYzIDEwMDY0NAotLS0gYS94ZW4vY29tbW9uL3J3
bG9jay5jCisrKyBiL3hlbi9jb21tb24vcndsb2NrLmMKQEAgLTEyNSw4ICsx
MjUsMTIgQEAgdm9pZCBfcGVyY3B1X3dyaXRlX2xvY2socGVyY3B1X3J3bG9j
a190ICoqcGVyX2NwdWRhdGEsCiAgICAgLyoKICAgICAgKiBGaXJzdCB0YWtl
IHRoZSB3cml0ZSBsb2NrIHRvIHByb3RlY3QgYWdhaW5zdCBvdGhlciB3cml0
ZXJzIG9yIHNsb3cKICAgICAgKiBwYXRoIHJlYWRlcnMuCisgICAgICoKKyAg
ICAgKiBOb3RlIHdlIHVzZSB0aGUgc3BlY3VsYXRpb24gdW5zYWZlIHZhcmlh
bnQgb2Ygd3JpdGVfbG9jaygpLCBhcyB0aGUKKyAgICAgKiBjYWxsaW5nIHdy
YXBwZXIgYWxyZWFkeSBhZGRzIGEgc3BlY3VsYXRpb24gYmFycmllciBhZnRl
ciB0aGUgbG9jayBoYXMKKyAgICAgKiBiZWVuIHRha2VuLgogICAgICAqLwot
ICAgIHdyaXRlX2xvY2soJnBlcmNwdV9yd2xvY2stPnJ3bG9jayk7CisgICAg
X3dyaXRlX2xvY2soJnBlcmNwdV9yd2xvY2stPnJ3bG9jayk7CiAKICAgICAv
KiBOb3cgc2V0IHRoZSBnbG9iYWwgdmFyaWFibGUgc28gdGhhdCByZWFkZXJz
IHN0YXJ0IHVzaW5nIHJlYWRfbG9jay4gKi8KICAgICBwZXJjcHVfcndsb2Nr
LT53cml0ZXJfYWN0aXZhdGluZyA9IDE7CmRpZmYgLS1naXQgYS94ZW4vaW5j
bHVkZS94ZW4vcndsb2NrLmggYi94ZW4vaW5jbHVkZS94ZW4vcndsb2NrLmgK
aW5kZXggZmQwNDU4YmU5NGFlLi5hYmUwODA0YmY3ZDUgMTAwNjQ0Ci0tLSBh
L3hlbi9pbmNsdWRlL3hlbi9yd2xvY2suaAorKysgYi94ZW4vaW5jbHVkZS94
ZW4vcndsb2NrLmgKQEAgLTMyNiw4ICszMjYsOCBAQCBzdGF0aWMgaW5saW5l
IHZvaWQgX3BlcmNwdV9yd2xvY2tfb3duZXJfY2hlY2socGVyY3B1X3J3bG9j
a190ICoqcGVyX2NwdWRhdGEsCiAjZGVmaW5lIHBlcmNwdV9yd2xvY2tfcmVz
b3VyY2VfaW5pdChsLCBvd25lcikgXAogICAgICgqKGwpID0gKHBlcmNwdV9y
d2xvY2tfdClQRVJDUFVfUldfTE9DS19VTkxPQ0tFRCgmZ2V0X3Blcl9jcHVf
dmFyKG93bmVyKSkpCiAKLXN0YXRpYyBpbmxpbmUgdm9pZCBfcGVyY3B1X3Jl
YWRfbG9jayhwZXJjcHVfcndsb2NrX3QgKipwZXJfY3B1ZGF0YSwKLSAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcGVyY3B1X3J3
bG9ja190ICpwZXJjcHVfcndsb2NrKQorc3RhdGljIGFsd2F5c19pbmxpbmUg
dm9pZCBfcGVyY3B1X3JlYWRfbG9jayhwZXJjcHVfcndsb2NrX3QgKipwZXJf
Y3B1ZGF0YSwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgcGVyY3B1X3J3bG9ja190ICpwZXJjcHVfcndsb2NrKQogewog
ICAgIC8qIFZhbGlkYXRlIHRoZSBjb3JyZWN0IHBlcl9jcHVkYXRhIHZhcmlh
YmxlIGhhcyBiZWVuIHByb3ZpZGVkLiAqLwogICAgIF9wZXJjcHVfcndsb2Nr
X293bmVyX2NoZWNrKHBlcl9jcHVkYXRhLCBwZXJjcHVfcndsb2NrKTsKQEAg
LTM2Miw2ICszNjIsOCBAQCBzdGF0aWMgaW5saW5lIHZvaWQgX3BlcmNwdV9y
ZWFkX2xvY2socGVyY3B1X3J3bG9ja190ICoqcGVyX2NwdWRhdGEsCiAgICAg
fQogICAgIGVsc2UKICAgICB7CisgICAgICAgIC8qIE90aGVyIGJyYW5jaCBh
bHJlYWR5IGhhcyBhIHNwZWN1bGF0aW9uIGJhcnJpZXIgaW4gcmVhZF9sb2Nr
KCkuICovCisgICAgICAgIGJsb2NrX2xvY2tfc3BlY3VsYXRpb24oKTsKICAg
ICAgICAgLyogQWxsIG90aGVyIHBhdGhzIGhhdmUgaW1wbGljaXQgY2hlY2tf
bG9jaygpIGNhbGxzIHZpYSByZWFkX2xvY2soKS4gKi8KICAgICAgICAgY2hl
Y2tfbG9jaygmcGVyY3B1X3J3bG9jay0+cndsb2NrLmxvY2suZGVidWcsIGZh
bHNlKTsKICAgICB9CkBAIC00MTAsOCArNDEyLDEyIEBAIHN0YXRpYyBpbmxp
bmUgdm9pZCBfcGVyY3B1X3dyaXRlX3VubG9jayhwZXJjcHVfcndsb2NrX3Qg
KipwZXJfY3B1ZGF0YSwKICAgICBfcGVyY3B1X3JlYWRfbG9jaygmZ2V0X3Bl
cl9jcHVfdmFyKHBlcmNwdSksIGxvY2spCiAjZGVmaW5lIHBlcmNwdV9yZWFk
X3VubG9jayhwZXJjcHUsIGxvY2spIFwKICAgICBfcGVyY3B1X3JlYWRfdW5s
b2NrKCZnZXRfcGVyX2NwdV92YXIocGVyY3B1KSwgbG9jaykKLSNkZWZpbmUg
cGVyY3B1X3dyaXRlX2xvY2socGVyY3B1LCBsb2NrKSBcCi0gICAgX3BlcmNw
dV93cml0ZV9sb2NrKCZnZXRfcGVyX2NwdV92YXIocGVyY3B1KSwgbG9jaykK
KworI2RlZmluZSBwZXJjcHVfd3JpdGVfbG9jayhwZXJjcHUsIGxvY2spICAg
ICAgICAgICAgICAgICBcCisoeyAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKKyAgICBfcGVyY3B1X3dy
aXRlX2xvY2soJmdldF9wZXJfY3B1X3ZhcihwZXJjcHUpLCBsb2NrKTsgXAor
ICAgIGJsb2NrX2xvY2tfc3BlY3VsYXRpb24oKTsgICAgICAgICAgICAgICAg
ICAgICAgICAgICBcCit9KQogI2RlZmluZSBwZXJjcHVfd3JpdGVfdW5sb2Nr
KHBlcmNwdSwgbG9jaykgXAogICAgIF9wZXJjcHVfd3JpdGVfdW5sb2NrKCZn
ZXRfcGVyX2NwdV92YXIocGVyY3B1KSwgbG9jaykKIAo=

--=separator
Content-Type: application/octet-stream; name="xsa453/xsa453-4.15-6.patch"
Content-Disposition: attachment; filename="xsa453/xsa453-4.15-6.patch"
Content-Transfer-Encoding: base64

RnJvbTogPT9VVEYtOD9xP1JvZ2VyPTIwUGF1PTIwTW9ubj1DMz1BOT89IDxy
b2dlci5wYXVAY2l0cml4LmNvbT4KU3ViamVjdDogbG9ja2luZzogYXR0ZW1w
dCB0byBlbnN1cmUgbG9jayB3cmFwcGVycyBhcmUgYWx3YXlzIGlubGluZQoK
SW4gb3JkZXIgdG8gcHJldmVudCB0aGUgbG9ja2luZyBzcGVjdWxhdGlvbiBi
YXJyaWVycyBmcm9tIGJlaW5nIGluc2lkZSBvZgpgY2FsbGBlZCBmdW5jdGlv
bnMgdGhhdCBjb3VsZCBiZSBzcGVjdWxhdGl2ZWx5IGJ5cGFzc2VkLgoKV2hp
bGUgdGhlcmUgYWxzbyBhZGQgYW4gZXh0cmEgbG9ja2luZyBiYXJyaWVyIHRv
IF9tbV93cml0ZV9sb2NrKCkgaW4gdGhlIGJyYW5jaAp0YWtlbiB3aGVuIHRo
ZSBsb2NrIGlzIGFscmVhZHkgaGVsZC4KCk5vdGUgc29tZSBmdW5jdGlvbnMg
YXJlIHN3aXRjaGVkIHRvIHVzZSB0aGUgdW5zYWZlIHZhcmlhbnRzICh3aXRo
b3V0IHNwZWN1bGF0aW9uCmJhcnJpZXIpIG9mIHRoZSBsb2NraW5nIHByaW1p
dGl2ZXMsIGJ1dCBhIHNwZWN1bGF0aW9uIGJhcnJpZXIgaXMgYWx3YXlzIGFk
ZGVkCnRvIHRoZSBleHBvc2VkIHB1YmxpYyBsb2NrIHdyYXBwaW5nIGhlbHBl
ci4gIFRoYXQncyB0aGUgY2FzZSB3aXRoCnNjaGVkX3NwaW5fbG9ja19kb3Vi
bGUoKSBvciBwY2lkZXZzX2xvY2soKSBmb3IgZXhhbXBsZS4KClRoaXMgaXMg
cGFydCBvZiBYU0EtNDUzIC8gQ1ZFLTIwMjQtMjE5MwoKU2lnbmVkLW9mZi1i
eTogUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5jb20+ClJl
dmlld2VkLWJ5OiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+Cihj
aGVycnkgcGlja2VkIGZyb20gY29tbWl0IDE5N2VjZDgzOGEyYWFmOTU5YTQ2
OWRmMzY5NmQ0NTU5YzRmOGI3NjIpCgpkaWZmIC0tZ2l0IGEveGVuL2FyY2gv
eDg2L2h2bS92cHQuYyBiL3hlbi9hcmNoL3g4Ni9odm0vdnB0LmMKaW5kZXgg
NGQ0ZDIyYjBlNzJiLi42YzA5MjNhNDJlMjEgMTAwNjQ0Ci0tLSBhL3hlbi9h
cmNoL3g4Ni9odm0vdnB0LmMKKysrIGIveGVuL2FyY2gveDg2L2h2bS92cHQu
YwpAQCAtMTYxLDcgKzE2MSw3IEBAIHN0YXRpYyBpbnQgcHRfaXJxX21hc2tl
ZChzdHJ1Y3QgcGVyaW9kaWNfdGltZSAqcHQpCiAgKiBwdC0+dmNwdSBmaWVs
ZCwgYmVjYXVzZSBhbm90aGVyIHRocmVhZCBob2xkaW5nIHRoZSBwdF9taWdy
YXRlIGxvY2sKICAqIG1heSBhbHJlYWR5IGJlIHNwaW5uaW5nIHdhaXRpbmcg
Zm9yIHlvdXIgdmNwdSBsb2NrLgogICovCi1zdGF0aWMgdm9pZCBwdF92Y3B1
X2xvY2soc3RydWN0IHZjcHUgKnYpCitzdGF0aWMgYWx3YXlzX2lubGluZSB2
b2lkIHB0X3ZjcHVfbG9jayhzdHJ1Y3QgdmNwdSAqdikKIHsKICAgICBzcGlu
X2xvY2soJnYtPmFyY2guaHZtLnRtX2xvY2spOwogfQpAQCAtMTgwLDkgKzE4
MCwxMyBAQCBzdGF0aWMgdm9pZCBwdF92Y3B1X3VubG9jayhzdHJ1Y3QgdmNw
dSAqdikKICAqIG5lZWQgdG8gdGFrZSBhbiBhZGRpdGlvbmFsIGxvY2sgdGhh
dCBwcm90ZWN0cyBhZ2FpbnN0IHB0LT52Y3B1CiAgKiBjaGFuZ2luZy4KICAq
Lwotc3RhdGljIHZvaWQgcHRfbG9jayhzdHJ1Y3QgcGVyaW9kaWNfdGltZSAq
cHQpCitzdGF0aWMgYWx3YXlzX2lubGluZSB2b2lkIHB0X2xvY2soc3RydWN0
IHBlcmlvZGljX3RpbWUgKnB0KQogewotICAgIHJlYWRfbG9jaygmcHQtPnZj
cHUtPmRvbWFpbi0+YXJjaC5odm0ucGxfdGltZS0+cHRfbWlncmF0ZSk7Cisg
ICAgLyoKKyAgICAgKiBVc2UgdGhlIHNwZWN1bGF0aW9uIHVuc2FmZSB2YXJp
YW50IGZvciB0aGUgZmlyc3QgbG9jaywgYXMgdGhlIGZvbGxvd2luZworICAg
ICAqIGxvY2sgdGFraW5nIGhlbHBlciBhbHJlYWR5IGluY2x1ZGVzIGEgc3Bl
Y3VsYXRpb24gYmFycmllci4KKyAgICAgKi8KKyAgICBfcmVhZF9sb2NrKCZw
dC0+dmNwdS0+ZG9tYWluLT5hcmNoLmh2bS5wbF90aW1lLT5wdF9taWdyYXRl
KTsKICAgICBzcGluX2xvY2soJnB0LT52Y3B1LT5hcmNoLmh2bS50bV9sb2Nr
KTsKIH0KIApkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L21tL21tLWxvY2tz
LmggYi94ZW4vYXJjaC94ODYvbW0vbW0tbG9ja3MuaAppbmRleCBkNmMwNzNk
YzVjZjUuLmNjNjM1YTQ0MDU3MSAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2
L21tL21tLWxvY2tzLmgKKysrIGIveGVuL2FyY2gveDg2L21tL21tLWxvY2tz
LmgKQEAgLTg4LDggKzg4LDggQEAgc3RhdGljIGlubGluZSB2b2lkIF9zZXRf
bG9ja19sZXZlbChpbnQgbCkKICAgICB0aGlzX2NwdShtbV9sb2NrX2xldmVs
KSA9IGw7CiB9CiAKLXN0YXRpYyBpbmxpbmUgdm9pZCBfbW1fbG9jayhjb25z
dCBzdHJ1Y3QgZG9tYWluICpkLCBtbV9sb2NrX3QgKmwsCi0gICAgICAgICAg
ICAgICAgICAgICAgICAgICAgY29uc3QgY2hhciAqZnVuYywgaW50IGxldmVs
LCBpbnQgcmVjKQorc3RhdGljIGFsd2F5c19pbmxpbmUgdm9pZCBfbW1fbG9j
ayhjb25zdCBzdHJ1Y3QgZG9tYWluICpkLCBtbV9sb2NrX3QgKmwsCisgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IGNoYXIgKmZ1
bmMsIGludCBsZXZlbCwgaW50IHJlYykKIHsKICAgICBpZiAoICEoKG1tX2xv
Y2tlZF9ieV9tZShsKSkgJiYgcmVjKSApCiAgICAgICAgIF9jaGVja19sb2Nr
X2xldmVsKGQsIGxldmVsKTsKQEAgLTEzOSw4ICsxMzksOCBAQCBzdGF0aWMg
aW5saW5lIGludCBtbV93cml0ZV9sb2NrZWRfYnlfbWUobW1fcndsb2NrX3Qg
KmwpCiAgICAgcmV0dXJuIChsLT5sb2NrZXIgPT0gZ2V0X3Byb2Nlc3Nvcl9p
ZCgpKTsKIH0KIAotc3RhdGljIGlubGluZSB2b2lkIF9tbV93cml0ZV9sb2Nr
KGNvbnN0IHN0cnVjdCBkb21haW4gKmQsIG1tX3J3bG9ja190ICpsLAotICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IGNoYXIgKmZ1
bmMsIGludCBsZXZlbCkKK3N0YXRpYyBhbHdheXNfaW5saW5lIHZvaWQgX21t
X3dyaXRlX2xvY2soY29uc3Qgc3RydWN0IGRvbWFpbiAqZCwgbW1fcndsb2Nr
X3QgKmwsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIGNvbnN0IGNoYXIgKmZ1bmMsIGludCBsZXZlbCkKIHsKICAgICBpZiAo
ICFtbV93cml0ZV9sb2NrZWRfYnlfbWUobCkgKQogICAgIHsKQEAgLTE1MSw2
ICsxNTEsOCBAQCBzdGF0aWMgaW5saW5lIHZvaWQgX21tX3dyaXRlX2xvY2so
Y29uc3Qgc3RydWN0IGRvbWFpbiAqZCwgbW1fcndsb2NrX3QgKmwsCiAgICAg
ICAgIGwtPnVubG9ja19sZXZlbCA9IF9nZXRfbG9ja19sZXZlbCgpOwogICAg
ICAgICBfc2V0X2xvY2tfbGV2ZWwoX2xvY2tfbGV2ZWwoZCwgbGV2ZWwpKTsK
ICAgICB9CisgICAgZWxzZQorICAgICAgICBibG9ja19zcGVjdWxhdGlvbigp
OwogICAgIGwtPnJlY3Vyc2VfY291bnQrKzsKIH0KIApAQCAtMTY0LDggKzE2
Niw4IEBAIHN0YXRpYyBpbmxpbmUgdm9pZCBtbV93cml0ZV91bmxvY2sobW1f
cndsb2NrX3QgKmwpCiAgICAgcGVyY3B1X3dyaXRlX3VubG9jayhwMm1fcGVy
Y3B1X3J3bG9jaywgJmwtPmxvY2spOwogfQogCi1zdGF0aWMgaW5saW5lIHZv
aWQgX21tX3JlYWRfbG9jayhjb25zdCBzdHJ1Y3QgZG9tYWluICpkLCBtbV9y
d2xvY2tfdCAqbCwKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IGludCBsZXZlbCkKK3N0YXRpYyBhbHdheXNfaW5saW5lIHZvaWQgX21tX3Jl
YWRfbG9jayhjb25zdCBzdHJ1Y3QgZG9tYWluICpkLCBtbV9yd2xvY2tfdCAq
bCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBp
bnQgbGV2ZWwpCiB7CiAgICAgX2NoZWNrX2xvY2tfbGV2ZWwoZCwgbGV2ZWwp
OwogICAgIHBlcmNwdV9yZWFkX2xvY2socDJtX3BlcmNwdV9yd2xvY2ssICZs
LT5sb2NrKTsKQEAgLTE4MCwxNSArMTgyLDE1IEBAIHN0YXRpYyBpbmxpbmUg
dm9pZCBtbV9yZWFkX3VubG9jayhtbV9yd2xvY2tfdCAqbCkKIAogLyogVGhp
cyB3cmFwcGVyIHVzZXMgdGhlIGxpbmUgbnVtYmVyIHRvIGV4cHJlc3MgdGhl
IGxvY2tpbmcgb3JkZXIgYmVsb3cgKi8KICNkZWZpbmUgZGVjbGFyZV9tbV9s
b2NrKG5hbWUpICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIFwKLSAgICBzdGF0aWMgaW5saW5lIHZvaWQgbW1fbG9j
a18jI25hbWUoY29uc3Qgc3RydWN0IGRvbWFpbiAqZCwgbW1fbG9ja190ICps
LCAgIFwKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
Y29uc3QgY2hhciAqZnVuYywgaW50IHJlYykgICAgICAgICAgICAgIFwKKyAg
ICBzdGF0aWMgYWx3YXlzX2lubGluZSB2b2lkIG1tX2xvY2tfIyNuYW1lKCAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKKyAgICAgICAgY29u
c3Qgc3RydWN0IGRvbWFpbiAqZCwgbW1fbG9ja190ICpsLCBjb25zdCBjaGFy
ICpmdW5jLCBpbnQgcmVjKSAgICAgIFwKICAgICB7IF9tbV9sb2NrKGQsIGws
IGZ1bmMsIE1NX0xPQ0tfT1JERVJfIyNuYW1lLCByZWMpOyB9CiAjZGVmaW5l
IGRlY2xhcmVfbW1fcndsb2NrKG5hbWUpICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBcCi0gICAgc3RhdGljIGlubGlu
ZSB2b2lkIG1tX3dyaXRlX2xvY2tfIyNuYW1lKGNvbnN0IHN0cnVjdCBkb21h
aW4gKmQsICAgICAgICAgICBcCi0gICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIG1tX3J3bG9ja190ICpsLCBjb25zdCBjaGFy
ICpmdW5jKSBcCisgICAgc3RhdGljIGFsd2F5c19pbmxpbmUgdm9pZCBtbV93
cml0ZV9sb2NrXyMjbmFtZSggICAgICAgICAgICAgICAgICAgICAgICAgICBc
CisgICAgICAgIGNvbnN0IHN0cnVjdCBkb21haW4gKmQsIG1tX3J3bG9ja190
ICpsLCBjb25zdCBjaGFyICpmdW5jKSAgICAgICAgICAgICBcCiAgICAgeyBf
bW1fd3JpdGVfbG9jayhkLCBsLCBmdW5jLCBNTV9MT0NLX09SREVSXyMjbmFt
ZSk7IH0gICAgICAgICAgICAgICAgICAgICBcCi0gICAgc3RhdGljIGlubGlu
ZSB2b2lkIG1tX3JlYWRfbG9ja18jI25hbWUoY29uc3Qgc3RydWN0IGRvbWFp
biAqZCwgICAgICAgICAgICBcCi0gICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgbW1fcndsb2NrX3QgKmwpICAgICAgICAgICAg
ICAgICAgICBcCisgICAgc3RhdGljIGFsd2F5c19pbmxpbmUgdm9pZCBtbV9y
ZWFkX2xvY2tfIyNuYW1lKGNvbnN0IHN0cnVjdCBkb21haW4gKmQsICAgICBc
CisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIG1tX3J3bG9ja190ICpsKSAgICAgICAgICAgICBcCiAgICAgeyBf
bW1fcmVhZF9sb2NrKGQsIGwsIE1NX0xPQ0tfT1JERVJfIyNuYW1lKTsgfQog
LyogVGhlc2UgY2FwdHVyZSB0aGUgbmFtZSBvZiB0aGUgY2FsbGluZyBmdW5j
dGlvbiAqLwogI2RlZmluZSBtbV9sb2NrKG5hbWUsIGQsIGwpIG1tX2xvY2tf
IyNuYW1lKGQsIGwsIF9fZnVuY19fLCAwKQpAQCAtMzIxLDcgKzMyMyw3IEBA
IGRlY2xhcmVfbW1fbG9jayhhbHRwMm1saXN0KQogI2RlZmluZSBNTV9MT0NL
X09SREVSX2FsdHAybSAgICAgICAgICAgICAgICAgNDAKIGRlY2xhcmVfbW1f
cndsb2NrKGFsdHAybSk7CiAKLXN0YXRpYyBpbmxpbmUgdm9pZCBwMm1fbG9j
ayhzdHJ1Y3QgcDJtX2RvbWFpbiAqcCkKK3N0YXRpYyBhbHdheXNfaW5saW5l
IHZvaWQgcDJtX2xvY2soc3RydWN0IHAybV9kb21haW4gKnApCiB7CiAgICAg
aWYgKCBwMm1faXNfYWx0cDJtKHApICkKICAgICAgICAgbW1fd3JpdGVfbG9j
ayhhbHRwMm0sIHAtPmRvbWFpbiwgJnAtPmxvY2spOwpkaWZmIC0tZ2l0IGEv
eGVuL2FyY2gveDg2L21tL3AybS1wb2QuYyBiL3hlbi9hcmNoL3g4Ni9tbS9w
Mm0tcG9kLmMKaW5kZXggYzFkMjY5MzY4MzFjLi5mOWE4MzBmYjIwYjMgMTAw
NjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9tbS9wMm0tcG9kLmMKKysrIGIveGVu
L2FyY2gveDg2L21tL3AybS1wb2QuYwpAQCAtMzQsNyArMzQsNyBAQAogI2Rl
ZmluZSBzdXBlcnBhZ2VfYWxpZ25lZChfeCkgICgoKF94KSYoU1VQRVJQQUdF
X1BBR0VTLTEpKT09MCkKIAogLyogRW5mb3JjZSBsb2NrIG9yZGVyaW5nIHdo
ZW4gZ3JhYmJpbmcgdGhlICJleHRlcm5hbCIgcGFnZV9hbGxvYyBsb2NrICov
Ci1zdGF0aWMgaW5saW5lIHZvaWQgbG9ja19wYWdlX2FsbG9jKHN0cnVjdCBw
Mm1fZG9tYWluICpwMm0pCitzdGF0aWMgYWx3YXlzX2lubGluZSB2b2lkIGxv
Y2tfcGFnZV9hbGxvYyhzdHJ1Y3QgcDJtX2RvbWFpbiAqcDJtKQogewogICAg
IHBhZ2VfYWxsb2NfbW1fcHJlX2xvY2socDJtLT5kb21haW4pOwogICAgIHNw
aW5fbG9jaygmKHAybS0+ZG9tYWluLT5wYWdlX2FsbG9jX2xvY2spKTsKZGlm
ZiAtLWdpdCBhL3hlbi9jb21tb24vZXZlbnRfY2hhbm5lbC5jIGIveGVuL2Nv
bW1vbi9ldmVudF9jaGFubmVsLmMKaW5kZXggYzk0ZWE3NGIxMjFlLi4yOWUx
ZTQxZWJhMTkgMTAwNjQ0Ci0tLSBhL3hlbi9jb21tb24vZXZlbnRfY2hhbm5l
bC5jCisrKyBiL3hlbi9jb21tb24vZXZlbnRfY2hhbm5lbC5jCkBAIC01Nyw3
ICs1Nyw3IEBACiAgKiBqdXN0IGFzc3VtZSB0aGUgZXZlbnQgY2hhbm5lbCBp
cyBmcmVlIG9yIHVuYm91bmQgYXQgdGhlIG1vbWVudCB3aGVuIHRoZQogICog
ZXZ0Y2huX3JlYWRfdHJ5bG9jaygpIHJldHVybnMgZmFsc2UuCiAgKi8KLXN0
YXRpYyBpbmxpbmUgdm9pZCBldnRjaG5fd3JpdGVfbG9jayhzdHJ1Y3QgZXZ0
Y2huICpldnRjaG4pCitzdGF0aWMgYWx3YXlzX2lubGluZSB2b2lkIGV2dGNo
bl93cml0ZV9sb2NrKHN0cnVjdCBldnRjaG4gKmV2dGNobikKIHsKICAgICB3
cml0ZV9sb2NrKCZldnRjaG4tPmxvY2spOwogCkBAIC0zMjMsOCArMzIzLDgg
QEAgc3RhdGljIGxvbmcgZXZ0Y2huX2FsbG9jX3VuYm91bmQoZXZ0Y2huX2Fs
bG9jX3VuYm91bmRfdCAqYWxsb2MpCiAgICAgcmV0dXJuIHJjOwogfQogCi0K
LXN0YXRpYyB2b2lkIGRvdWJsZV9ldnRjaG5fbG9jayhzdHJ1Y3QgZXZ0Y2hu
ICpsY2huLCBzdHJ1Y3QgZXZ0Y2huICpyY2huKQorc3RhdGljIGFsd2F5c19p
bmxpbmUgdm9pZCBkb3VibGVfZXZ0Y2huX2xvY2soc3RydWN0IGV2dGNobiAq
bGNobiwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIHN0cnVjdCBldnRjaG4gKnJjaG4pCiB7CiAgICAgQVNTRVJUKGxj
aG4gIT0gcmNobik7CiAKZGlmZiAtLWdpdCBhL3hlbi9jb21tb24vZ3JhbnRf
dGFibGUuYyBiL3hlbi9jb21tb24vZ3JhbnRfdGFibGUuYwppbmRleCAwMWU0
MjZjNjdmYjYuLjYwZDhjYTNkZGZmNCAxMDA2NDQKLS0tIGEveGVuL2NvbW1v
bi9ncmFudF90YWJsZS5jCisrKyBiL3hlbi9jb21tb24vZ3JhbnRfdGFibGUu
YwpAQCAtMzk3LDcgKzM5Nyw3IEBAIHN0YXRpYyBpbmxpbmUgdm9pZCBhY3Rf
c2V0X2dmbihzdHJ1Y3QgYWN0aXZlX2dyYW50X2VudHJ5ICphY3QsIGdmbl90
IGdmbikKIAogc3RhdGljIERFRklORV9QRVJDUFVfUldMT0NLX0dMT0JBTChn
cmFudF9yd2xvY2spOwogCi1zdGF0aWMgaW5saW5lIHZvaWQgZ3JhbnRfcmVh
ZF9sb2NrKHN0cnVjdCBncmFudF90YWJsZSAqZ3QpCitzdGF0aWMgYWx3YXlz
X2lubGluZSB2b2lkIGdyYW50X3JlYWRfbG9jayhzdHJ1Y3QgZ3JhbnRfdGFi
bGUgKmd0KQogewogICAgIHBlcmNwdV9yZWFkX2xvY2soZ3JhbnRfcndsb2Nr
LCAmZ3QtPmxvY2spOwogfQpAQCAtNDA3LDcgKzQwNyw3IEBAIHN0YXRpYyBp
bmxpbmUgdm9pZCBncmFudF9yZWFkX3VubG9jayhzdHJ1Y3QgZ3JhbnRfdGFi
bGUgKmd0KQogICAgIHBlcmNwdV9yZWFkX3VubG9jayhncmFudF9yd2xvY2ss
ICZndC0+bG9jayk7CiB9CiAKLXN0YXRpYyBpbmxpbmUgdm9pZCBncmFudF93
cml0ZV9sb2NrKHN0cnVjdCBncmFudF90YWJsZSAqZ3QpCitzdGF0aWMgYWx3
YXlzX2lubGluZSB2b2lkIGdyYW50X3dyaXRlX2xvY2soc3RydWN0IGdyYW50
X3RhYmxlICpndCkKIHsKICAgICBwZXJjcHVfd3JpdGVfbG9jayhncmFudF9y
d2xvY2ssICZndC0+bG9jayk7CiB9CkBAIC00NDQsNyArNDQ0LDcgQEAgbnJf
YWN0aXZlX2dyYW50X2ZyYW1lcyhzdHJ1Y3QgZ3JhbnRfdGFibGUgKmd0KQog
ICAgIHJldHVybiBudW1fYWN0X2ZyYW1lc19mcm9tX3NoYV9mcmFtZXMobnJf
Z3JhbnRfZnJhbWVzKGd0KSk7CiB9CiAKLXN0YXRpYyBpbmxpbmUgc3RydWN0
IGFjdGl2ZV9ncmFudF9lbnRyeSAqCitzdGF0aWMgYWx3YXlzX2lubGluZSBz
dHJ1Y3QgYWN0aXZlX2dyYW50X2VudHJ5ICoKIGFjdGl2ZV9lbnRyeV9hY3F1
aXJlKHN0cnVjdCBncmFudF90YWJsZSAqdCwgZ3JhbnRfcmVmX3QgZSkKIHsK
ICAgICBzdHJ1Y3QgYWN0aXZlX2dyYW50X2VudHJ5ICphY3Q7CmRpZmYgLS1n
aXQgYS94ZW4vY29tbW9uL3NjaGVkL2NvcmUuYyBiL3hlbi9jb21tb24vc2No
ZWQvY29yZS5jCmluZGV4IDAzYWNlNDE1NDBkNi4uOWU4MGFkNGM3NDYzIDEw
MDY0NAotLS0gYS94ZW4vY29tbW9uL3NjaGVkL2NvcmUuYworKysgYi94ZW4v
Y29tbW9uL3NjaGVkL2NvcmUuYwpAQCAtMzQ4LDIzICszNDgsMjggQEAgdWlu
dDY0X3QgZ2V0X2NwdV9pZGxlX3RpbWUodW5zaWduZWQgaW50IGNwdSkKICAq
IFRoaXMgYXZvaWRzIGRlYWQtIG9yIGxpdmUtbG9ja3Mgd2hlbiB0aGlzIGNv
ZGUgaXMgcnVubmluZyBvbiBib3RoCiAgKiBjcHVzIGF0IHRoZSBzYW1lIHRp
bWUuCiAgKi8KLXN0YXRpYyB2b2lkIHNjaGVkX3NwaW5fbG9ja19kb3VibGUo
c3BpbmxvY2tfdCAqbG9jazEsIHNwaW5sb2NrX3QgKmxvY2syLAotICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1bnNpZ25lZCBsb25nICpm
bGFncykKK3N0YXRpYyBhbHdheXNfaW5saW5lIHZvaWQgc2NoZWRfc3Bpbl9s
b2NrX2RvdWJsZSgKKyAgICBzcGlubG9ja190ICpsb2NrMSwgc3BpbmxvY2tf
dCAqbG9jazIsIHVuc2lnbmVkIGxvbmcgKmZsYWdzKQogeworICAgIC8qCisg
ICAgICogSW4gb3JkZXIgdG8gYXZvaWQgZXh0cmEgb3ZlcmhlYWQsIHVzZSB0
aGUgbG9ja2luZyBwcmltaXRpdmVzIHdpdGhvdXQgdGhlCisgICAgICogc3Bl
Y3VsYXRpb24gYmFycmllciwgYW5kIGludHJvZHVjZSBhIHNpbmdsZSBiYXJy
aWVyIGhlcmUuCisgICAgICovCiAgICAgaWYgKCBsb2NrMSA9PSBsb2NrMiAp
CiAgICAgewotICAgICAgICBzcGluX2xvY2tfaXJxc2F2ZShsb2NrMSwgKmZs
YWdzKTsKKyAgICAgICAgKmZsYWdzID0gX3NwaW5fbG9ja19pcnFzYXZlKGxv
Y2sxKTsKICAgICB9CiAgICAgZWxzZSBpZiAoIGxvY2sxIDwgbG9jazIgKQog
ICAgIHsKLSAgICAgICAgc3Bpbl9sb2NrX2lycXNhdmUobG9jazEsICpmbGFn
cyk7Ci0gICAgICAgIHNwaW5fbG9jayhsb2NrMik7CisgICAgICAgICpmbGFn
cyA9IF9zcGluX2xvY2tfaXJxc2F2ZShsb2NrMSk7CisgICAgICAgIF9zcGlu
X2xvY2sobG9jazIpOwogICAgIH0KICAgICBlbHNlCiAgICAgewotICAgICAg
ICBzcGluX2xvY2tfaXJxc2F2ZShsb2NrMiwgKmZsYWdzKTsKLSAgICAgICAg
c3Bpbl9sb2NrKGxvY2sxKTsKKyAgICAgICAgKmZsYWdzID0gX3NwaW5fbG9j
a19pcnFzYXZlKGxvY2syKTsKKyAgICAgICAgX3NwaW5fbG9jayhsb2NrMSk7
CiAgICAgfQorICAgIGJsb2NrX2xvY2tfc3BlY3VsYXRpb24oKTsKIH0KIAog
c3RhdGljIHZvaWQgc2NoZWRfc3Bpbl91bmxvY2tfZG91YmxlKHNwaW5sb2Nr
X3QgKmxvY2sxLCBzcGlubG9ja190ICpsb2NrMiwKZGlmZiAtLWdpdCBhL3hl
bi9jb21tb24vc2NoZWQvcHJpdmF0ZS5oIGIveGVuL2NvbW1vbi9zY2hlZC9w
cml2YXRlLmgKaW5kZXggOGMwN2YwMzNkM2IwLi4zYWMzZWFjNTRhNDEgMTAw
NjQ0Ci0tLSBhL3hlbi9jb21tb24vc2NoZWQvcHJpdmF0ZS5oCisrKyBiL3hl
bi9jb21tb24vc2NoZWQvcHJpdmF0ZS5oCkBAIC0yMDcsOCArMjA3LDI0IEBA
IERFQ0xBUkVfUEVSX0NQVShjcHVtYXNrX3QsIGNwdW1hc2tfc2NyYXRjaCk7
CiAjZGVmaW5lIGNwdW1hc2tfc2NyYXRjaCAgICAgICAgKCZ0aGlzX2NwdShj
cHVtYXNrX3NjcmF0Y2gpKQogI2RlZmluZSBjcHVtYXNrX3NjcmF0Y2hfY3B1
KGMpICgmcGVyX2NwdShjcHVtYXNrX3NjcmF0Y2gsIGMpKQogCisvKgorICog
RGVhbCB3aXRoIF9zcGluX2xvY2tfaXJxc2F2ZSgpIHJldHVybmluZyB0aGUg
ZmxhZ3MgdmFsdWUgaW5zdGVhZCBvZiBzdG9yaW5nCisgKiBpdCBpbiBhIHBh
c3NlZCBwYXJhbWV0ZXIuCisgKi8KKyNkZWZpbmUgX3NjaGVkX3NwaW5sb2Nr
MChsb2NrLCBpcnEpIF9zcGluX2xvY2sjI2lycShsb2NrKQorI2RlZmluZSBf
c2NoZWRfc3BpbmxvY2sxKGxvY2ssIGlycSwgYXJnKSAoeyBcCisgICAgQlVJ
TERfQlVHX09OKHNpemVvZihhcmcpICE9IHNpemVvZih1bnNpZ25lZCBsb25n
KSk7IFwKKyAgICAoYXJnKSA9IF9zcGluX2xvY2sjI2lycShsb2NrKTsgXAor
fSkKKworI2RlZmluZSBfc2NoZWRfc3BpbmxvY2tfXyhucikgX3NjaGVkX3Nw
aW5sb2NrICMjIG5yCisjZGVmaW5lIF9zY2hlZF9zcGlubG9ja18obnIpICBf
c2NoZWRfc3BpbmxvY2tfXyhucikKKyNkZWZpbmUgX3NjaGVkX3NwaW5sb2Nr
KGxvY2ssIGlycSwgYXJncy4uLikgXAorICAgIF9zY2hlZF9zcGlubG9ja18o
Y291bnRfYXJncyhhcmdzKSkobG9jaywgaXJxLCAjIyBhcmdzKQorCiAjZGVm
aW5lIHNjaGVkX2xvY2soa2luZCwgcGFyYW0sIGNwdSwgaXJxLCBhcmcuLi4p
IFwKLXN0YXRpYyBpbmxpbmUgc3BpbmxvY2tfdCAqa2luZCMjX3NjaGVkdWxl
X2xvY2sjI2lycShwYXJhbSBFWFRSQV9UWVBFKGFyZykpIFwKK3N0YXRpYyBh
bHdheXNfaW5saW5lIHNwaW5sb2NrX3QgXAorKmtpbmQjI19zY2hlZHVsZV9s
b2NrIyNpcnEocGFyYW0gRVhUUkFfVFlQRShhcmcpKSBcCiB7IFwKICAgICBm
b3IgKCA7IDsgKSBcCiAgICAgeyBcCkBAIC0yMjAsMTAgKzIzNiwxNiBAQCBz
dGF0aWMgaW5saW5lIHNwaW5sb2NrX3QgKmtpbmQjI19zY2hlZHVsZV9sb2Nr
IyNpcnEocGFyYW0gRVhUUkFfVFlQRShhcmcpKSBcCiAgICAgICAgICAqIFwK
ICAgICAgICAgICogSXQgbWF5IGFsc28gYmUgdGhlIGNhc2UgdGhhdCB2LT5w
cm9jZXNzb3IgbWF5IGNoYW5nZSBidXQgdGhlIFwKICAgICAgICAgICogbG9j
ayBtYXkgYmUgdGhlIHNhbWU7IHRoaXMgd2lsbCBzdWNjZWVkIGluIHRoYXQg
Y2FzZS4gXAorICAgICAgICAgKiBcCisgICAgICAgICAqIFVzZSB0aGUgc3Bl
Y3VsYXRpb24gdW5zYWZlIGxvY2tpbmcgaGVscGVyLCB0aGVyZSdzIGEgc3Bl
Y3VsYXRpb24gXAorICAgICAgICAgKiBiYXJyaWVyIGJlZm9yZSByZXR1cm5p
bmcgdG8gdGhlIGNhbGxlci4gXAogICAgICAgICAgKi8gXAotICAgICAgICBz
cGluX2xvY2sjI2lycShsb2NrLCAjIyBhcmcpOyBcCisgICAgICAgIF9zY2hl
ZF9zcGlubG9jayhsb2NrLCBpcnEsICMjIGFyZyk7IFwKICAgICAgICAgaWYg
KCBsaWtlbHkobG9jayA9PSBnZXRfc2NoZWRfcmVzKGNwdSktPnNjaGVkdWxl
X2xvY2spICkgXAorICAgICAgICB7IFwKKyAgICAgICAgICAgIGJsb2NrX2xv
Y2tfc3BlY3VsYXRpb24oKTsgXAogICAgICAgICAgICAgcmV0dXJuIGxvY2s7
IFwKKyAgICAgICAgfSBcCiAgICAgICAgIHNwaW5fdW5sb2NrIyNpcnEobG9j
aywgIyMgYXJnKTsgXAogICAgIH0gXAogfQpkaWZmIC0tZ2l0IGEveGVuL2Nv
bW1vbi90aW1lci5jIGIveGVuL2NvbW1vbi90aW1lci5jCmluZGV4IDFiYjI2
NWNlZWEwZS4uZGM4MzFlZmM3OWU1IDEwMDY0NAotLS0gYS94ZW4vY29tbW9u
L3RpbWVyLmMKKysrIGIveGVuL2NvbW1vbi90aW1lci5jCkBAIC0yNDAsNyAr
MjQwLDcgQEAgc3RhdGljIGlubGluZSB2b2lkIGRlYWN0aXZhdGVfdGltZXIo
c3RydWN0IHRpbWVyICp0aW1lcikKICAgICBsaXN0X2FkZCgmdGltZXItPmlu
YWN0aXZlLCAmcGVyX2NwdSh0aW1lcnMsIHRpbWVyLT5jcHUpLmluYWN0aXZl
KTsKIH0KIAotc3RhdGljIGlubGluZSBib29sX3QgdGltZXJfbG9jayhzdHJ1
Y3QgdGltZXIgKnRpbWVyKQorc3RhdGljIGlubGluZSBib29sX3QgdGltZXJf
bG9ja191bnNhZmUoc3RydWN0IHRpbWVyICp0aW1lcikKIHsKICAgICB1bnNp
Z25lZCBpbnQgY3B1OwogCkBAIC0yNTQsNyArMjU0LDggQEAgc3RhdGljIGlu
bGluZSBib29sX3QgdGltZXJfbG9jayhzdHJ1Y3QgdGltZXIgKnRpbWVyKQog
ICAgICAgICAgICAgcmN1X3JlYWRfdW5sb2NrKCZ0aW1lcl9jcHVfcmVhZF9s
b2NrKTsKICAgICAgICAgICAgIHJldHVybiAwOwogICAgICAgICB9Ci0gICAg
ICAgIHNwaW5fbG9jaygmcGVyX2NwdSh0aW1lcnMsIGNwdSkubG9jayk7Cisg
ICAgICAgIC8qIFVzZSB0aGUgc3BlY3VsYXRpb24gdW5zYWZlIHZhcmlhbnQs
IHRoZSB3cmFwcGVyIGhhcyB0aGUgYmFycmllci4gKi8KKyAgICAgICAgX3Nw
aW5fbG9jaygmcGVyX2NwdSh0aW1lcnMsIGNwdSkubG9jayk7CiAgICAgICAg
IGlmICggbGlrZWx5KHRpbWVyLT5jcHUgPT0gY3B1KSApCiAgICAgICAgICAg
ICBicmVhazsKICAgICAgICAgc3Bpbl91bmxvY2soJnBlcl9jcHUodGltZXJz
LCBjcHUpLmxvY2spOwpAQCAtMjY3LDggKzI2OCw5IEBAIHN0YXRpYyBpbmxp
bmUgYm9vbF90IHRpbWVyX2xvY2soc3RydWN0IHRpbWVyICp0aW1lcikKICNk
ZWZpbmUgdGltZXJfbG9ja19pcnFzYXZlKHQsIGZsYWdzKSAoeyAgICAgICAg
IFwKICAgICBib29sX3QgX194OyAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIFwKICAgICBsb2NhbF9pcnFfc2F2ZShmbGFncyk7ICAgICAgICAg
ICAgICAgICAgICAgIFwKLSAgICBpZiAoICEoX194ID0gdGltZXJfbG9jayh0
KSkgKSAgICAgICAgICAgICAgIFwKKyAgICBpZiAoICEoX194ID0gdGltZXJf
bG9ja191bnNhZmUodCkpICkgICAgICAgIFwKICAgICAgICAgbG9jYWxfaXJx
X3Jlc3RvcmUoZmxhZ3MpOyAgICAgICAgICAgICAgIFwKKyAgICBibG9ja19s
b2NrX3NwZWN1bGF0aW9uKCk7ICAgICAgICAgICAgICAgICAgIFwKICAgICBf
X3g7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwK
IH0pCiAKZGlmZiAtLWdpdCBhL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL3Bj
aS5jIGIveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvcGNpLmMKaW5kZXggODRk
MGQyZmJhYjk0Li4wMzRiMzZmYzIzMmIgMTAwNjQ0Ci0tLSBhL3hlbi9kcml2
ZXJzL3Bhc3N0aHJvdWdoL3BjaS5jCisrKyBiL3hlbi9kcml2ZXJzL3Bhc3N0
aHJvdWdoL3BjaS5jCkBAIC01Miw5ICs1MiwxMCBAQCBzdHJ1Y3QgcGNpX3Nl
ZyB7CiAKIHN0YXRpYyBzcGlubG9ja190IF9wY2lkZXZzX2xvY2sgPSBTUElO
X0xPQ0tfVU5MT0NLRUQ7CiAKLXZvaWQgcGNpZGV2c19sb2NrKHZvaWQpCisv
KiBEbyBub3QgdXNlLCBhcyBpdCBoYXMgbm8gc3BlY3VsYXRpb24gYmFycmll
ciwgdXNlIHBjaWRldnNfbG9jaygpIGluc3RlYWQuICovCit2b2lkIHBjaWRl
dnNfbG9ja191bnNhZmUodm9pZCkKIHsKLSAgICBzcGluX2xvY2tfcmVjdXJz
aXZlKCZfcGNpZGV2c19sb2NrKTsKKyAgICBfc3Bpbl9sb2NrX3JlY3Vyc2l2
ZSgmX3BjaWRldnNfbG9jayk7CiB9CiAKIHZvaWQgcGNpZGV2c191bmxvY2so
dm9pZCkKZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL2FzbS14ODYvaXJxLmgg
Yi94ZW4vaW5jbHVkZS9hc20teDg2L2lycS5oCmluZGV4IDdjODI1ZTlkOWMw
YS4uZDRiMmJlZGE3OThkIDEwMDY0NAotLS0gYS94ZW4vaW5jbHVkZS9hc20t
eDg2L2lycS5oCisrKyBiL3hlbi9pbmNsdWRlL2FzbS14ODYvaXJxLmgKQEAg
LTE3Nyw2ICsxNzcsNyBAQCBleHRlcm4gdm9pZCBpcnFfY29tcGxldGVfbW92
ZShzdHJ1Y3QgaXJxX2Rlc2MgKik7CiAKIGV4dGVybiBzdHJ1Y3QgaXJxX2Rl
c2MgKmlycV9kZXNjOwogCisvKiBOb3Qgc3BlY3VsYXRpb24gc2FmZSwgb25s
eSB1c2VkIGZvciBBUCBicmluZ3VwLiAqLwogdm9pZCBsb2NrX3ZlY3Rvcl9s
b2NrKHZvaWQpOwogdm9pZCB1bmxvY2tfdmVjdG9yX2xvY2sodm9pZCk7CiAK
ZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL3hlbi9ldmVudC5oIGIveGVuL2lu
Y2x1ZGUveGVuL2V2ZW50LmgKaW5kZXggYTBhODVjZGRhODk5Li5jZGZhM2Rm
NmY5ZmIgMTAwNjQ0Ci0tLSBhL3hlbi9pbmNsdWRlL3hlbi9ldmVudC5oCisr
KyBiL3hlbi9pbmNsdWRlL3hlbi9ldmVudC5oCkBAIC0xMDUsMTIgKzEwNSwx
MiBAQCB2b2lkIG5vdGlmeV92aWFfeGVuX2V2ZW50X2NoYW5uZWwoc3RydWN0
IGRvbWFpbiAqbGQsIGludCBscG9ydCk7CiAjZGVmaW5lIGJ1Y2tldF9mcm9t
X3BvcnQoZCwgcCkgXAogICAgICgoZ3JvdXBfZnJvbV9wb3J0KGQsIHApKVso
KHApICUgRVZUQ0hOU19QRVJfR1JPVVApIC8gRVZUQ0hOU19QRVJfQlVDS0VU
XSkKIAotc3RhdGljIGlubGluZSB2b2lkIGV2dGNobl9yZWFkX2xvY2soc3Ry
dWN0IGV2dGNobiAqZXZ0Y2huKQorc3RhdGljIGFsd2F5c19pbmxpbmUgdm9p
ZCBldnRjaG5fcmVhZF9sb2NrKHN0cnVjdCBldnRjaG4gKmV2dGNobikKIHsK
ICAgICByZWFkX2xvY2soJmV2dGNobi0+bG9jayk7CiB9CiAKLXN0YXRpYyBp
bmxpbmUgYm9vbCBldnRjaG5fcmVhZF90cnlsb2NrKHN0cnVjdCBldnRjaG4g
KmV2dGNobikKK3N0YXRpYyBhbHdheXNfaW5saW5lIGJvb2wgZXZ0Y2huX3Jl
YWRfdHJ5bG9jayhzdHJ1Y3QgZXZ0Y2huICpldnRjaG4pCiB7CiAgICAgcmV0
dXJuIHJlYWRfdHJ5bG9jaygmZXZ0Y2huLT5sb2NrKTsKIH0KZGlmZiAtLWdp
dCBhL3hlbi9pbmNsdWRlL3hlbi9wY2kuaCBiL3hlbi9pbmNsdWRlL3hlbi9w
Y2kuaAppbmRleCBjZDIzOGFlODUyYjAuLjVlYjgyODdhMzFmOSAxMDA2NDQK
LS0tIGEveGVuL2luY2x1ZGUveGVuL3BjaS5oCisrKyBiL3hlbi9pbmNsdWRl
L3hlbi9wY2kuaApAQCAtMTQ0LDggKzE0NCwxMiBAQCBzdHJ1Y3QgcGNpX2Rl
diB7CiAgKiBkZXZpY2VzLCBpdCBhbHNvIHN5bmMgdGhlIGFjY2VzcyB0byB0
aGUgbXNpIGNhcGFiaWxpdHkgdGhhdCBpcyBub3QKICAqIGludGVycnVwdCBo
YW5kbGluZyByZWxhdGVkICh0aGUgbWFzayBiaXQgcmVnaXN0ZXIpLgogICov
Ci0KLXZvaWQgcGNpZGV2c19sb2NrKHZvaWQpOwordm9pZCBwY2lkZXZzX2xv
Y2tfdW5zYWZlKHZvaWQpOworc3RhdGljIGFsd2F5c19pbmxpbmUgdm9pZCBw
Y2lkZXZzX2xvY2sodm9pZCkKK3sKKyAgICBwY2lkZXZzX2xvY2tfdW5zYWZl
KCk7CisgICAgYmxvY2tfbG9ja19zcGVjdWxhdGlvbigpOworfQogdm9pZCBw
Y2lkZXZzX3VubG9jayh2b2lkKTsKIGJvb2xfdCBfX211c3RfY2hlY2sgcGNp
ZGV2c19sb2NrZWQodm9pZCk7CiAK

--=separator
Content-Type: application/octet-stream; name="xsa453/xsa453-4.15-7.patch"
Content-Disposition: attachment; filename="xsa453/xsa453-4.15-7.patch"
Content-Transfer-Encoding: base64

RnJvbTogPT9VVEYtOD9xP1JvZ2VyPTIwUGF1PTIwTW9ubj1DMz1BOT89IDxy
b2dlci5wYXVAY2l0cml4LmNvbT4KU3ViamVjdDogeDg2L21tOiBhZGQgc3Bl
Y3VsYXRpb24gYmFycmllcnMgdG8gb3BlbiBjb2RlZCBsb2NrcwoKQWRkIGEg
c3BlY3VsYXRpb24gYmFycmllciB0byB0aGUgY2xlYXJseSBpZGVudGlmaWVk
IG9wZW4tY29kZWQgbG9jayB0YWtpbmcKZnVuY3Rpb25zLgoKTm90ZSB0aGF0
IHRoZSBtZW1vcnkgc2hhcmluZyBwYWdlX2xvY2soKSByZXBsYWNlbWVudCAo
X3BhZ2VfbG9jaygpKSBpcyBsZWZ0CmFzLWlzLCBhcyB0aGUgY29kZSBpcyBl
eHBlcmltZW50YWwgYW5kIG5vdCBzZWN1cml0eSBzdXBwb3J0ZWQuCgpUaGlz
IGlzIHBhcnQgb2YgWFNBLTQ1MyAvIENWRS0yMDI0LTIxOTMKClNpZ25lZC1v
ZmYtYnk6IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXguY29t
PgpSZXZpZXdlZC1ieTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29t
PgooY2hlcnJ5IHBpY2tlZCBmcm9tIGNvbW1pdCA0MmE1NzJhMzhlMjJhOTdk
ODZhNGI2NDhhMjI1OTc2MjhkNWI0MmU0KQoKZGlmZiAtLWdpdCBhL3hlbi9h
cmNoL3g4Ni9tbS5jIGIveGVuL2FyY2gveDg2L21tLmMKaW5kZXggNDRhYzhj
YWU3NmExLi5hZDIyNTQzZDFiODggMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4
Ni9tbS5jCisrKyBiL3hlbi9hcmNoL3g4Ni9tbS5jCkBAIC0yMDA0LDcgKzIw
MDQsNyBAQCBzdGF0aWMgaW5saW5lIGJvb2wgY3VycmVudF9sb2NrZWRfcGFn
ZV9uZV9jaGVjayhzdHJ1Y3QgcGFnZV9pbmZvICpwYWdlKSB7CiAjZGVmaW5l
IGN1cnJlbnRfbG9ja2VkX3BhZ2VfbmVfY2hlY2soeCkgdHJ1ZQogI2VuZGlm
CiAKLWludCBwYWdlX2xvY2soc3RydWN0IHBhZ2VfaW5mbyAqcGFnZSkKK2lu
dCBwYWdlX2xvY2tfdW5zYWZlKHN0cnVjdCBwYWdlX2luZm8gKnBhZ2UpCiB7
CiAgICAgdW5zaWduZWQgbG9uZyB4LCBueDsKIApAQCAtMjA2NSw3ICsyMDY1
LDcgQEAgdm9pZCBwYWdlX3VubG9jayhzdHJ1Y3QgcGFnZV9pbmZvICpwYWdl
KQogICogbDN0X2xvY2soKSwgc28gdG8gYXZvaWQgZGVhZGxvY2sgd2UgbXVz
dCBhdm9pZCBncmFiYmluZyB0aGVtIGluCiAgKiByZXZlcnNlIG9yZGVyLgog
ICovCi1zdGF0aWMgdm9pZCBsM3RfbG9jayhzdHJ1Y3QgcGFnZV9pbmZvICpw
YWdlKQorc3RhdGljIGFsd2F5c19pbmxpbmUgdm9pZCBsM3RfbG9jayhzdHJ1
Y3QgcGFnZV9pbmZvICpwYWdlKQogewogICAgIHVuc2lnbmVkIGxvbmcgeCwg
bng7CiAKQEAgLTIwNzQsNiArMjA3NCw4IEBAIHN0YXRpYyB2b2lkIGwzdF9s
b2NrKHN0cnVjdCBwYWdlX2luZm8gKnBhZ2UpCiAgICAgICAgICAgICBjcHVf
cmVsYXgoKTsKICAgICAgICAgbnggPSB4IHwgUEdUX2xvY2tlZDsKICAgICB9
IHdoaWxlICggY21weGNoZygmcGFnZS0+dS5pbnVzZS50eXBlX2luZm8sIHgs
IG54KSAhPSB4ICk7CisKKyAgICBibG9ja19sb2NrX3NwZWN1bGF0aW9uKCk7
CiB9CiAKIHN0YXRpYyB2b2lkIGwzdF91bmxvY2soc3RydWN0IHBhZ2VfaW5m
byAqcGFnZSkKZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL2FzbS14ODYvbW0u
aCBiL3hlbi9pbmNsdWRlL2FzbS14ODYvbW0uaAppbmRleCBjZmZkMGQ2NDI1
MzQuLjkxN2ZiZTI5YmI5NiAxMDA2NDQKLS0tIGEveGVuL2luY2x1ZGUvYXNt
LXg4Ni9tbS5oCisrKyBiL3hlbi9pbmNsdWRlL2FzbS14ODYvbW0uaApAQCAt
MzkzLDcgKzM5Myw5IEBAIGNvbnN0IHN0cnVjdCBwbGF0Zm9ybV9iYWRfcGFn
ZSAqZ2V0X3BsYXRmb3JtX2JhZHBhZ2VzKHVuc2lnbmVkIGludCAqYXJyYXlf
c2l6ZSk7CiAgKiBUaGUgdXNlIG9mIFBHVF9sb2NrZWQgaW4gbWVtX3NoYXJp
bmcgZG9lcyBub3QgY29sbGlkZSwgc2luY2UgbWVtX3NoYXJpbmcgaXMKICAq
IG9ubHkgc3VwcG9ydGVkIGZvciBodm0gZ3Vlc3RzLCB3aGljaCBkbyBub3Qg
aGF2ZSBQViBQVEVzIHVwZGF0ZWQuCiAgKi8KLWludCBwYWdlX2xvY2soc3Ry
dWN0IHBhZ2VfaW5mbyAqcGFnZSk7CitpbnQgcGFnZV9sb2NrX3Vuc2FmZShz
dHJ1Y3QgcGFnZV9pbmZvICpwYWdlKTsKKyNkZWZpbmUgcGFnZV9sb2NrKHBn
KSAgIGxvY2tfZXZhbHVhdGVfbm9zcGVjKHBhZ2VfbG9ja191bnNhZmUocGcp
KQorCiB2b2lkIHBhZ2VfdW5sb2NrKHN0cnVjdCBwYWdlX2luZm8gKnBhZ2Up
OwogCiB2b2lkIHB1dF9wYWdlX3R5cGUoc3RydWN0IHBhZ2VfaW5mbyAqcGFn
ZSk7Cg==

--=separator
Content-Type: application/octet-stream; name="xsa453/xsa453-4.15-8.patch"
Content-Disposition: attachment; filename="xsa453/xsa453-4.15-8.patch"
Content-Transfer-Encoding: base64

RnJvbTogPT9VVEYtOD9xP1JvZ2VyPTIwUGF1PTIwTW9ubj1DMz1BOT89IDxy
b2dlci5wYXVAY2l0cml4LmNvbT4KU3ViamVjdDogeDg2OiBwcm90ZWN0IGNv
bmRpdGlvbmFsIGxvY2sgdGFraW5nIGZyb20gc3BlY3VsYXRpdmUgZXhlY3V0
aW9uCgpDb25kaXRpb25hbGx5IHRha2VuIGxvY2tzIHRoYXQgdXNlIHRoZSBw
YXR0ZXJuOgoKaWYgKCBsb2NrICkKICAgIHNwaW5fbG9jayguLi4pOwoKTmVl
ZCBhbiBlbHNlIGJyYW5jaCBpbiBvcmRlciB0byBpc3N1ZSBhbiBzcGVjdWxh
dGlvbiBiYXJyaWVyIGluIHRoZSBlbHNlIGNhc2UsCmp1c3QgbGlrZSBpdCdz
IGRvbmUgaW4gY2FzZSB0aGUgbG9jayBuZWVkcyB0byBiZSBhY3F1aXJlZC4K
CmV2YWxfbm9zcGVjKCkgY291bGQgYmUgdXNlZCBvbiB0aGUgY29uZGl0aW9u
IGl0c2VsZiwgYnV0IHRoYXQgd291bGQgcmVzdWx0IGluIGEKZG91YmxlIGJh
cnJpZXIgb24gdGhlIGJyYW5jaCB3aGVyZSB0aGUgbG9jayBpcyB0YWtlbi4K
CkludHJvZHVjZSBhIG5ldyBwYWlyIG9mIGhlbHBlcnMsIHtnZm4sc3Bpbn1f
bG9ja19pZigpIHRoYXQgY2FuIGJlIHVzZWQgdG8KY29uZGl0aW9uYWxseSB0
YWtlIGEgbG9jayBpbiBhIHNwZWN1bGF0aW9uIHNhZmUgd2F5LgoKVGhpcyBp
cyBwYXJ0IG9mIFhTQS00NTMgLyBDVkUtMjAyNC0yMTkzCgpTaWduZWQtb2Zm
LWJ5OiBSb2dlciBQYXUgTW9ubsOpIDxyb2dlci5wYXVAY2l0cml4LmNvbT4K
UmV2aWV3ZWQtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4K
KGNoZXJyeSBwaWNrZWQgZnJvbSBjb21taXQgMDNjZjdjYTIzZTBlODc2MDc1
OTU0YzU1ODQ4NWIyNjdiN2QwMjQwNikKCmRpZmYgLS1naXQgYS94ZW4vYXJj
aC94ODYvbW0uYyBiL3hlbi9hcmNoL3g4Ni9tbS5jCmluZGV4IGFkMjI1NDNk
MWI4OC4uZmZlZTFjNmJkMTkxIDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYv
bW0uYworKysgYi94ZW4vYXJjaC94ODYvbW0uYwpAQCAtNDk3OCw4ICs0OTc4
LDcgQEAgc3RhdGljIGwzX3BnZW50cnlfdCAqdmlydF90b194ZW5fbDNlKHVu
c2lnbmVkIGxvbmcgdikKICAgICAgICAgaWYgKCAhbDN0ICkKICAgICAgICAg
ICAgIHJldHVybiBOVUxMOwogICAgICAgICBjbGVhcl9wYWdlKGwzdCk7Ci0g
ICAgICAgIGlmICggbG9ja2luZyApCi0gICAgICAgICAgICBzcGluX2xvY2so
Jm1hcF9wZ2Rpcl9sb2NrKTsKKyAgICAgICAgc3Bpbl9sb2NrX2lmKGxvY2tp
bmcsICZtYXBfcGdkaXJfbG9jayk7CiAgICAgICAgIGlmICggIShsNGVfZ2V0
X2ZsYWdzKCpwbDRlKSAmIF9QQUdFX1BSRVNFTlQpICkKICAgICAgICAgewog
ICAgICAgICAgICAgbDRfcGdlbnRyeV90IGw0ZSA9IGw0ZV9mcm9tX3BhZGRy
KF9fcGEobDN0KSwgX19QQUdFX0hZUEVSVklTT1IpOwpAQCAtNTAxMyw4ICs1
MDEyLDcgQEAgc3RhdGljIGwyX3BnZW50cnlfdCAqdmlydF90b194ZW5fbDJl
KHVuc2lnbmVkIGxvbmcgdikKICAgICAgICAgaWYgKCAhbDJ0ICkKICAgICAg
ICAgICAgIHJldHVybiBOVUxMOwogICAgICAgICBjbGVhcl9wYWdlKGwydCk7
Ci0gICAgICAgIGlmICggbG9ja2luZyApCi0gICAgICAgICAgICBzcGluX2xv
Y2soJm1hcF9wZ2Rpcl9sb2NrKTsKKyAgICAgICAgc3Bpbl9sb2NrX2lmKGxv
Y2tpbmcsICZtYXBfcGdkaXJfbG9jayk7CiAgICAgICAgIGlmICggIShsM2Vf
Z2V0X2ZsYWdzKCpwbDNlKSAmIF9QQUdFX1BSRVNFTlQpICkKICAgICAgICAg
ewogICAgICAgICAgICAgbDNlX3dyaXRlKHBsM2UsIGwzZV9mcm9tX3BhZGRy
KF9fcGEobDJ0KSwgX19QQUdFX0hZUEVSVklTT1IpKTsKQEAgLTUwNDYsOCAr
NTA0NCw3IEBAIGwxX3BnZW50cnlfdCAqdmlydF90b194ZW5fbDFlKHVuc2ln
bmVkIGxvbmcgdikKICAgICAgICAgaWYgKCAhbDF0ICkKICAgICAgICAgICAg
IHJldHVybiBOVUxMOwogICAgICAgICBjbGVhcl9wYWdlKGwxdCk7Ci0gICAg
ICAgIGlmICggbG9ja2luZyApCi0gICAgICAgICAgICBzcGluX2xvY2soJm1h
cF9wZ2Rpcl9sb2NrKTsKKyAgICAgICAgc3Bpbl9sb2NrX2lmKGxvY2tpbmcs
ICZtYXBfcGdkaXJfbG9jayk7CiAgICAgICAgIGlmICggIShsMmVfZ2V0X2Zs
YWdzKCpwbDJlKSAmIF9QQUdFX1BSRVNFTlQpICkKICAgICAgICAgewogICAg
ICAgICAgICAgbDJlX3dyaXRlKHBsMmUsIGwyZV9mcm9tX3BhZGRyKF9fcGEo
bDF0KSwgX19QQUdFX0hZUEVSVklTT1IpKTsKQEAgLTUwNzYsNiArNTA3Myw4
IEBAIGwxX3BnZW50cnlfdCAqdmlydF90b194ZW5fbDFlKHVuc2lnbmVkIGxv
bmcgdikKICAgICBkbyB7ICAgICAgICAgICAgICAgICAgICAgIFwKICAgICAg
ICAgaWYgKCBsb2NraW5nICkgICAgICAgIFwKICAgICAgICAgICAgIGwzdF9s
b2NrKHBhZ2UpOyAgIFwKKyAgICAgICAgZWxzZSAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBcCisgICAgICAgICAgICBibG9ja19sb2NrX3NwZWN1bGF0
aW9uKCk7ICAgXAogICAgIH0gd2hpbGUgKCBmYWxzZSApCiAKICNkZWZpbmUg
TDNUX1VOTE9DSyhwYWdlKSAgICAgICAgICAgICAgICAgICAgICAgICAgIFwK
QEAgLTUyODQsOCArNTI4Myw3IEBAIGludCBtYXBfcGFnZXNfdG9feGVuKAog
ICAgICAgICAgICAgaWYgKCBsM2VfZ2V0X2ZsYWdzKG9sM2UpICYgX1BBR0Vf
R0xPQkFMICkKICAgICAgICAgICAgICAgICBmbHVzaF9mbGFncyB8PSBGTFVT
SF9UTEJfR0xPQkFMOwogCi0gICAgICAgICAgICBpZiAoIGxvY2tpbmcgKQot
ICAgICAgICAgICAgICAgIHNwaW5fbG9jaygmbWFwX3BnZGlyX2xvY2spOwor
ICAgICAgICAgICAgc3Bpbl9sb2NrX2lmKGxvY2tpbmcsICZtYXBfcGdkaXJf
bG9jayk7CiAgICAgICAgICAgICBpZiAoIChsM2VfZ2V0X2ZsYWdzKCpwbDNl
KSAmIF9QQUdFX1BSRVNFTlQpICYmCiAgICAgICAgICAgICAgICAgIChsM2Vf
Z2V0X2ZsYWdzKCpwbDNlKSAmIF9QQUdFX1BTRSkgKQogICAgICAgICAgICAg
ewpAQCAtNTM4NCw4ICs1MzgyLDcgQEAgaW50IG1hcF9wYWdlc190b194ZW4o
CiAgICAgICAgICAgICAgICAgaWYgKCBsMmVfZ2V0X2ZsYWdzKCpwbDJlKSAm
IF9QQUdFX0dMT0JBTCApCiAgICAgICAgICAgICAgICAgICAgIGZsdXNoX2Zs
YWdzIHw9IEZMVVNIX1RMQl9HTE9CQUw7CiAKLSAgICAgICAgICAgICAgICBp
ZiAoIGxvY2tpbmcgKQotICAgICAgICAgICAgICAgICAgICBzcGluX2xvY2so
Jm1hcF9wZ2Rpcl9sb2NrKTsKKyAgICAgICAgICAgICAgICBzcGluX2xvY2tf
aWYobG9ja2luZywgJm1hcF9wZ2Rpcl9sb2NrKTsKICAgICAgICAgICAgICAg
ICBpZiAoIChsMmVfZ2V0X2ZsYWdzKCpwbDJlKSAmIF9QQUdFX1BSRVNFTlQp
ICYmCiAgICAgICAgICAgICAgICAgICAgICAobDJlX2dldF9mbGFncygqcGwy
ZSkgJiBfUEFHRV9QU0UpICkKICAgICAgICAgICAgICAgICB7CkBAIC01NDI0
LDggKzU0MjEsNyBAQCBpbnQgbWFwX3BhZ2VzX3RvX3hlbigKICAgICAgICAg
ICAgICAgICB1bnNpZ25lZCBsb25nIGJhc2VfbWZuOwogICAgICAgICAgICAg
ICAgIGNvbnN0IGwxX3BnZW50cnlfdCAqbDF0OwogCi0gICAgICAgICAgICAg
ICAgaWYgKCBsb2NraW5nICkKLSAgICAgICAgICAgICAgICAgICAgc3Bpbl9s
b2NrKCZtYXBfcGdkaXJfbG9jayk7CisgICAgICAgICAgICAgICAgc3Bpbl9s
b2NrX2lmKGxvY2tpbmcsICZtYXBfcGdkaXJfbG9jayk7CiAKICAgICAgICAg
ICAgICAgICBvbDJlID0gKnBsMmU7CiAgICAgICAgICAgICAgICAgLyoKQEAg
LTU0NzgsOCArNTQ3NCw3IEBAIGludCBtYXBfcGFnZXNfdG9feGVuKAogICAg
ICAgICAgICAgdW5zaWduZWQgbG9uZyBiYXNlX21mbjsKICAgICAgICAgICAg
IGNvbnN0IGwyX3BnZW50cnlfdCAqbDJ0OwogCi0gICAgICAgICAgICBpZiAo
IGxvY2tpbmcgKQotICAgICAgICAgICAgICAgIHNwaW5fbG9jaygmbWFwX3Bn
ZGlyX2xvY2spOworICAgICAgICAgICAgc3Bpbl9sb2NrX2lmKGxvY2tpbmcs
ICZtYXBfcGdkaXJfbG9jayk7CiAKICAgICAgICAgICAgIG9sM2UgPSAqcGwz
ZTsKICAgICAgICAgICAgIC8qCkBAIC01NjE0LDggKzU2MDksOCBAQCBpbnQg
bW9kaWZ5X3hlbl9tYXBwaW5ncyh1bnNpZ25lZCBsb25nIHMsIHVuc2lnbmVk
IGxvbmcgZSwgdW5zaWduZWQgaW50IG5mKQogICAgICAgICAgICAgICAgICAg
ICAgICAgICBsMmVfZnJvbV9wZm4obDNlX2dldF9wZm4oKnBsM2UpICsKICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChpIDw8IFBB
R0VUQUJMRV9PUkRFUiksCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBsM2VfZ2V0X2ZsYWdzKCpwbDNlKSkpOwotICAgICAgICAg
ICAgaWYgKCBsb2NraW5nICkKLSAgICAgICAgICAgICAgICBzcGluX2xvY2so
Jm1hcF9wZ2Rpcl9sb2NrKTsKKworICAgICAgICAgICAgc3Bpbl9sb2NrX2lm
KGxvY2tpbmcsICZtYXBfcGdkaXJfbG9jayk7CiAgICAgICAgICAgICBpZiAo
IChsM2VfZ2V0X2ZsYWdzKCpwbDNlKSAmIF9QQUdFX1BSRVNFTlQpICYmCiAg
ICAgICAgICAgICAgICAgIChsM2VfZ2V0X2ZsYWdzKCpwbDNlKSAmIF9QQUdF
X1BTRSkgKQogICAgICAgICAgICAgewpAQCAtNTY3MSw4ICs1NjY2LDggQEAg
aW50IG1vZGlmeV94ZW5fbWFwcGluZ3ModW5zaWduZWQgbG9uZyBzLCB1bnNp
Z25lZCBsb25nIGUsIHVuc2lnbmVkIGludCBuZikKICAgICAgICAgICAgICAg
ICAgICAgbDFlX3dyaXRlKCZsMXRbaV0sCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBsMWVfZnJvbV9wZm4obDJlX2dldF9wZm4oKnBsMmUpICsg
aSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBsMmVfZ2V0X2ZsYWdzKCpwbDJlKSAmIH5fUEFHRV9QU0UpKTsKLSAgICAg
ICAgICAgICAgICBpZiAoIGxvY2tpbmcgKQotICAgICAgICAgICAgICAgICAg
ICBzcGluX2xvY2soJm1hcF9wZ2Rpcl9sb2NrKTsKKworICAgICAgICAgICAg
ICAgIHNwaW5fbG9ja19pZihsb2NraW5nLCAmbWFwX3BnZGlyX2xvY2spOwog
ICAgICAgICAgICAgICAgIGlmICggKGwyZV9nZXRfZmxhZ3MoKnBsMmUpICYg
X1BBR0VfUFJFU0VOVCkgJiYKICAgICAgICAgICAgICAgICAgICAgIChsMmVf
Z2V0X2ZsYWdzKCpwbDJlKSAmIF9QQUdFX1BTRSkgKQogICAgICAgICAgICAg
ICAgIHsKQEAgLTU3MTQsOCArNTcwOSw3IEBAIGludCBtb2RpZnlfeGVuX21h
cHBpbmdzKHVuc2lnbmVkIGxvbmcgcywgdW5zaWduZWQgbG9uZyBlLCB1bnNp
Z25lZCBpbnQgbmYpCiAgICAgICAgICAgICAgKi8KICAgICAgICAgICAgIGlm
ICggKG5mICYgX1BBR0VfUFJFU0VOVCkgfHwgKCh2ICE9IGUpICYmIChsMV90
YWJsZV9vZmZzZXQodikgIT0gMCkpICkKICAgICAgICAgICAgICAgICBjb250
aW51ZTsKLSAgICAgICAgICAgIGlmICggbG9ja2luZyApCi0gICAgICAgICAg
ICAgICAgc3Bpbl9sb2NrKCZtYXBfcGdkaXJfbG9jayk7CisgICAgICAgICAg
ICBzcGluX2xvY2tfaWYobG9ja2luZywgJm1hcF9wZ2Rpcl9sb2NrKTsKIAog
ICAgICAgICAgICAgLyoKICAgICAgICAgICAgICAqIEwyRSBtYXkgYmUgYWxy
ZWFkeSBjbGVhcmVkLCBvciBzZXQgdG8gYSBzdXBlcnBhZ2UsIGJ5CkBAIC01
NzYwLDggKzU3NTQsNyBAQCBpbnQgbW9kaWZ5X3hlbl9tYXBwaW5ncyh1bnNp
Z25lZCBsb25nIHMsIHVuc2lnbmVkIGxvbmcgZSwgdW5zaWduZWQgaW50IG5m
KQogICAgICAgICBpZiAoIChuZiAmIF9QQUdFX1BSRVNFTlQpIHx8CiAgICAg
ICAgICAgICAgKCh2ICE9IGUpICYmIChsMl90YWJsZV9vZmZzZXQodikgKyBs
MV90YWJsZV9vZmZzZXQodikgIT0gMCkpICkKICAgICAgICAgICAgIGNvbnRp
bnVlOwotICAgICAgICBpZiAoIGxvY2tpbmcgKQotICAgICAgICAgICAgc3Bp
bl9sb2NrKCZtYXBfcGdkaXJfbG9jayk7CisgICAgICAgIHNwaW5fbG9ja19p
Zihsb2NraW5nLCAmbWFwX3BnZGlyX2xvY2spOwogCiAgICAgICAgIC8qCiAg
ICAgICAgICAqIEwzRSBtYXkgYmUgYWxyZWFkeSBjbGVhcmVkLCBvciBzZXQg
dG8gYSBzdXBlcnBhZ2UsIGJ5CmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYv
bW0vbW0tbG9ja3MuaCBiL3hlbi9hcmNoL3g4Ni9tbS9tbS1sb2Nrcy5oCmlu
ZGV4IGNjNjM1YTQ0MDU3MS4uN2VlZTIzM2I0Y2VmIDEwMDY0NAotLS0gYS94
ZW4vYXJjaC94ODYvbW0vbW0tbG9ja3MuaAorKysgYi94ZW4vYXJjaC94ODYv
bW0vbW0tbG9ja3MuaApAQCAtMzQ3LDYgKzM0NywxNSBAQCBzdGF0aWMgaW5s
aW5lIHZvaWQgcDJtX3VubG9jayhzdHJ1Y3QgcDJtX2RvbWFpbiAqcCkKICNk
ZWZpbmUgcDJtX2xvY2tlZF9ieV9tZShwKSAgIG1tX3dyaXRlX2xvY2tlZF9i
eV9tZSgmKHApLT5sb2NrKQogI2RlZmluZSBnZm5fbG9ja2VkX2J5X21lKHAs
ZykgcDJtX2xvY2tlZF9ieV9tZShwKQogCitzdGF0aWMgYWx3YXlzX2lubGlu
ZSB2b2lkIGdmbl9sb2NrX2lmKGJvb2wgY29uZGl0aW9uLCBzdHJ1Y3QgcDJt
X2RvbWFpbiAqcDJtLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBnZm5fdCBnZm4sIHVuc2lnbmVkIGludCBvcmRlcikKK3sKKyAg
ICBpZiAoIGNvbmRpdGlvbiApCisgICAgICAgIGdmbl9sb2NrKHAybSwgZ2Zu
LCBvcmRlcik7CisgICAgZWxzZQorICAgICAgICBibG9ja19sb2NrX3NwZWN1
bGF0aW9uKCk7Cit9CisKIC8qIFBvRCBsb2NrIChwZXItcDJtLXRhYmxlKQog
ICoKICAqIFByb3RlY3RzIHByaXZhdGUgUG9EIGRhdGEgc3RydWN0czogZW50
cnkgYW5kIGNhY2hlCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYvbW0vcDJt
LmMgYi94ZW4vYXJjaC94ODYvbW0vcDJtLmMKaW5kZXggMTA3ZjY3NzhhNmUx
Li41OTY5MjhlMDgzZmIgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9tbS9w
Mm0uYworKysgYi94ZW4vYXJjaC94ODYvbW0vcDJtLmMKQEAgLTUwOSw5ICs1
MDksOCBAQCBtZm5fdCBfX2dldF9nZm5fdHlwZV9hY2Nlc3Moc3RydWN0IHAy
bV9kb21haW4gKnAybSwgdW5zaWduZWQgbG9uZyBnZm5fbCwKICAgICAgICAg
cmV0dXJuIF9tZm4oZ2ZuX2wpOwogICAgIH0KIAotICAgIGlmICggbG9ja2Vk
ICkKLSAgICAgICAgLyogR3JhYiB0aGUgbG9jayBoZXJlLCBkb24ndCByZWxl
YXNlIHVudGlsIHB1dF9nZm4gKi8KLSAgICAgICAgZ2ZuX2xvY2socDJtLCBn
Zm4sIDApOworICAgIC8qIEdyYWIgdGhlIGxvY2sgaGVyZSwgZG9uJ3QgcmVs
ZWFzZSB1bnRpbCBwdXRfZ2ZuICovCisgICAgZ2ZuX2xvY2tfaWYobG9ja2Vk
LCBwMm0sIGdmbiwgMCk7CiAKICAgICBtZm4gPSBwMm0tPmdldF9lbnRyeShw
Mm0sIGdmbiwgdCwgYSwgcSwgcGFnZV9vcmRlciwgTlVMTCk7CiAKZGlmZiAt
LWdpdCBhL3hlbi9pbmNsdWRlL3hlbi9zcGlubG9jay5oIGIveGVuL2luY2x1
ZGUveGVuL3NwaW5sb2NrLmgKaW5kZXggZWZkYjIxZWE5MDcyLi44YmZmYjNm
NGI2MTAgMTAwNjQ0Ci0tLSBhL3hlbi9pbmNsdWRlL3hlbi9zcGlubG9jay5o
CisrKyBiL3hlbi9pbmNsdWRlL3hlbi9zcGlubG9jay5oCkBAIC0yMTYsNiAr
MjE2LDE0IEBAIHN0YXRpYyBhbHdheXNfaW5saW5lIHZvaWQgc3Bpbl9sb2Nr
X2lycShzcGlubG9ja190ICpsKQogICAgICAgICBibG9ja19sb2NrX3NwZWN1
bGF0aW9uKCk7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKICAg
ICB9KQogCisvKiBDb25kaXRpb25hbGx5IHRha2UgYSBzcGlubG9jayBpbiBh
IHNwZWN1bGF0aW9uIHNhZmUgd2F5LiAqLworc3RhdGljIGFsd2F5c19pbmxp
bmUgdm9pZCBzcGluX2xvY2tfaWYoYm9vbCBjb25kaXRpb24sIHNwaW5sb2Nr
X3QgKmwpCit7CisgICAgaWYgKCBjb25kaXRpb24gKQorICAgICAgICBfc3Bp
bl9sb2NrKGwpOworICAgIGJsb2NrX2xvY2tfc3BlY3VsYXRpb24oKTsKK30K
KwogI2RlZmluZSBzcGluX3VubG9jayhsKSAgICAgICAgICAgICAgICBfc3Bp
bl91bmxvY2sobCkKICNkZWZpbmUgc3Bpbl91bmxvY2tfaXJxKGwpICAgICAg
ICAgICAgX3NwaW5fdW5sb2NrX2lycShsKQogI2RlZmluZSBzcGluX3VubG9j
a19pcnFyZXN0b3JlKGwsIGYpICBfc3Bpbl91bmxvY2tfaXJxcmVzdG9yZShs
LCBmKQo=

--=separator
Content-Type: application/octet-stream; name="xsa453/xsa453-4.16-1.patch"
Content-Disposition: attachment; filename="xsa453/xsa453-4.16-1.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L3BhZ2luZzogRGVsZXRlIHVwZGF0ZV9jcjMoKSdz
IGRvX2xvY2tpbmcgcGFyYW1ldGVyCgpOaWNvbGEgcmVwb3J0cyB0aGF0IHRo
ZSBYU0EtNDM4IGZpeCBpbnRyb2R1Y2VkIG5ldyBNSVNSQSB2aW9sYXRpb25z
IGJlY2F1c2Ugb2YKc29tZSBpbmNpZGVudGFsIHRpZHlpbmcgaXQgdHJpZWQg
dG8gZG8uICBUaGUgcGFyYW1ldGVyIGlzIHVzZWxlc3MsIHNvIHJlc29sdmUK
dGhlIE1JU1JBIHJlZ3Jlc3Npb24gYnkgcmVtb3ZpbmcgaXQuCgpoYXBfdXBk
YXRlX2NyMygpIGRpc2NhcmRzIHRoZSBwYXJhbWV0ZXIgZW50aXJlbHksIHdo
aWxlIHNoX3VwZGF0ZV9jcjMoKSB1c2VzCml0IHRvIGRpc3Rpbmd1aXNoIGlu
dGVybmFsIGFuZCBleHRlcm5hbCBjYWxsZXJzIGFuZCB0aGVyZWZvcmUgd2hl
dGhlciB0aGUKcGFnaW5nIGxvY2sgc2hvdWxkIGJlIHRha2VuLgoKSG93ZXZl
ciwgd2UgaGF2ZSBwYWdpbmdfbG9ja19yZWN1cnNpdmUoKSBmb3IgdGhpcyBw
dXJwb3NlLCB3aGljaCBhbHNvIGF2b2lkcwp0aGUgYWJpbGl0eSBmb3IgdGhl
IHNoYWRvdyBpbnRlcm5hbCBjYWxsZXJzIHRvIGFjY2lkZW50YWxseSBub3Qg
aG9sZCB0aGUgbG9jay4KCkZpeGVzOiBmYjBmZjQ5ZmU5ZjcgKCJ4ODYvc2hh
ZG93OiBkZWZlciByZWxlYXNpbmcgb2YgUFYncyB0b3AtbGV2ZWwgc2hhZG93
IHJlZmVyZW5jZSIpClJlcG9ydGVkLWJ5OiBOaWNvbGEgVmV0cmluaSA8bmlj
b2xhLnZldHJpbmlAYnVnc2VuZy5jb20+ClNpZ25lZC1vZmYtYnk6IEFuZHJl
dyBDb29wZXIgPGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+ClJldmlld2Vk
LWJ5OiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+ClJlbGVhc2Ut
YWNrZWQtYnk6IEhlbnJ5IFdhbmcgPEhlbnJ5LldhbmdAYXJtLmNvbT4KKGNo
ZXJyeSBwaWNrZWQgZnJvbSBjb21taXQgZTcxMTU3ZDFhYzJhN2ZiZjQxMzEz
MDY2M2NmMGE5M2ZmOWZiY2Y3ZSkKCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94
ODYvbW0vaGFwL2hhcC5jIGIveGVuL2FyY2gveDg2L21tL2hhcC9oYXAuYwpp
bmRleCBmYTQ3OWQzZDk3YjMuLjYzYzI5ZGE2OTZkZCAxMDA2NDQKLS0tIGEv
eGVuL2FyY2gveDg2L21tL2hhcC9oYXAuYworKysgYi94ZW4vYXJjaC94ODYv
bW0vaGFwL2hhcC5jCkBAIC03MjgsNyArNzI4LDcgQEAgc3RhdGljIGJvb2xf
dCBoYXBfaW52bHBnKHN0cnVjdCB2Y3B1ICp2LCB1bnNpZ25lZCBsb25nIGxp
bmVhcikKICAgICByZXR1cm4gMTsKIH0KIAotc3RhdGljIHBhZ2V0YWJsZV90
IGhhcF91cGRhdGVfY3IzKHN0cnVjdCB2Y3B1ICp2LCBib29sIGRvX2xvY2tp
bmcsIGJvb2wgbm9mbHVzaCkKK3N0YXRpYyBwYWdldGFibGVfdCBoYXBfdXBk
YXRlX2NyMyhzdHJ1Y3QgdmNwdSAqdiwgYm9vbCBub2ZsdXNoKQogewogICAg
IHYtPmFyY2guaHZtLmh3X2NyWzNdID0gdi0+YXJjaC5odm0uZ3Vlc3RfY3Jb
M107CiAgICAgaHZtX3VwZGF0ZV9ndWVzdF9jcjModiwgbm9mbHVzaCk7CkBA
IC04MTgsNyArODE4LDcgQEAgc3RhdGljIHZvaWQgaGFwX3VwZGF0ZV9wYWdp
bmdfbW9kZXMoc3RydWN0IHZjcHUgKnYpCiAgICAgfQogCiAgICAgLyogQ1Iz
IGlzIGVmZmVjdGl2ZWx5IHVwZGF0ZWQgYnkgYSBtb2RlIGNoYW5nZS4gRmx1
c2ggQVNJRHMsIGV0Yy4gKi8KLSAgICBoYXBfdXBkYXRlX2NyMyh2LCAwLCBm
YWxzZSk7CisgICAgaGFwX3VwZGF0ZV9jcjModiwgZmFsc2UpOwogCiAgdW5s
b2NrOgogICAgIHBhZ2luZ191bmxvY2soZCk7CmRpZmYgLS1naXQgYS94ZW4v
YXJjaC94ODYvbW0vc2hhZG93L2NvbW1vbi5jIGIveGVuL2FyY2gveDg2L21t
L3NoYWRvdy9jb21tb24uYwppbmRleCAyNDJiOTM1MzdmOWEuLmE4ODY5YTNm
YjdlYiAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L21tL3NoYWRvdy9jb21t
b24uYworKysgYi94ZW4vYXJjaC94ODYvbW0vc2hhZG93L2NvbW1vbi5jCkBA
IC0yNTYzLDcgKzI1NjMsNyBAQCBzdGF0aWMgdm9pZCBzaF91cGRhdGVfcGFn
aW5nX21vZGVzKHN0cnVjdCB2Y3B1ICp2KQogICAgIH0KICNlbmRpZiAvKiBP
T1MgKi8KIAotICAgIHYtPmFyY2gucGFnaW5nLm1vZGUtPnVwZGF0ZV9jcjMo
diwgMCwgZmFsc2UpOworICAgIHYtPmFyY2gucGFnaW5nLm1vZGUtPnVwZGF0
ZV9jcjModiwgZmFsc2UpOwogfQogCiB2b2lkIHNoYWRvd191cGRhdGVfcGFn
aW5nX21vZGVzKHN0cnVjdCB2Y3B1ICp2KQpkaWZmIC0tZ2l0IGEveGVuL2Fy
Y2gveDg2L21tL3NoYWRvdy9tdWx0aS5jIGIveGVuL2FyY2gveDg2L21tL3No
YWRvdy9tdWx0aS5jCmluZGV4IGNmM2RlZDcwZTc1ZS4uNzhiYjg5ZjFlZTA0
IDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYvbW0vc2hhZG93L211bHRpLmMK
KysrIGIveGVuL2FyY2gveDg2L21tL3NoYWRvdy9tdWx0aS5jCkBAIC0yNDk5
LDcgKzI0OTksNyBAQCBzdGF0aWMgaW50IHNoX3BhZ2VfZmF1bHQoc3RydWN0
IHZjcHUgKnYsCiAgICAgICAgICAqIEluIGFueSBjYXNlLCBpbiB0aGUgUEFF
IGNhc2UsIHRoZSBBU1NFUlQgaXMgbm90IHRydWU7IGl0IGNhbgogICAgICAg
ICAgKiBoYXBwZW4gYmVjYXVzZSBvZiBhY3Rpb25zIHRoZSBndWVzdCBpcyB0
YWtpbmcuICovCiAjaWYgR1VFU1RfUEFHSU5HX0xFVkVMUyA9PSAzCi0gICAg
ICAgIHYtPmFyY2gucGFnaW5nLm1vZGUtPnVwZGF0ZV9jcjModiwgMCwgZmFs
c2UpOworICAgICAgICB2LT5hcmNoLnBhZ2luZy5tb2RlLT51cGRhdGVfY3Iz
KHYsIGZhbHNlKTsKICNlbHNlCiAgICAgICAgIEFTU0VSVChkLT5pc19zaHV0
dGluZ19kb3duKTsKICNlbmRpZgpAQCAtMzIxOSwxNyArMzIxOSwxMyBAQCBz
aF9kZXRhY2hfb2xkX3RhYmxlcyhzdHJ1Y3QgdmNwdSAqdikKICAgICB9CiB9
CiAKLXN0YXRpYyBwYWdldGFibGVfdAotc2hfdXBkYXRlX2NyMyhzdHJ1Y3Qg
dmNwdSAqdiwgYm9vbCBkb19sb2NraW5nLCBib29sIG5vZmx1c2gpCitzdGF0
aWMgcGFnZXRhYmxlX3Qgc2hfdXBkYXRlX2NyMyhzdHJ1Y3QgdmNwdSAqdiwg
Ym9vbCBub2ZsdXNoKQogLyogVXBkYXRlcyB2Y3B1LT5hcmNoLmNyMyBhZnRl
ciB0aGUgZ3Vlc3QgaGFzIGNoYW5nZWQgQ1IzLgogICogUGFyYXZpcnR1YWwg
Z3Vlc3RzIHNob3VsZCBzZXQgdi0+YXJjaC5ndWVzdF90YWJsZSAoYW5kIGd1
ZXN0X3RhYmxlX3VzZXIsCiAgKiBpZiBhcHByb3ByaWF0ZSkuCiAgKiBIVk0g
Z3Vlc3RzIHNob3VsZCBhbHNvIG1ha2Ugc3VyZSBodm1fZ2V0X2d1ZXN0X2Nu
dGxfcmVnKHYsIDMpIHdvcmtzOwogICogdGhpcyBmdW5jdGlvbiB3aWxsIGNh
bGwgaHZtX3VwZGF0ZV9ndWVzdF9jcih2LCAzKSB0byB0ZWxsIHRoZW0gd2hl
cmUgdGhlCiAgKiBzaGFkb3cgdGFibGVzIGFyZS4KLSAqIElmIGRvX2xvY2tp
bmcgIT0gMCwgYXNzdW1lIHdlIGFyZSBiZWluZyBjYWxsZWQgZnJvbSBvdXRz
aWRlIHRoZQotICogc2hhZG93IGNvZGUsIGFuZCBtdXN0IHRha2UgYW5kIHJl
bGVhc2UgdGhlIHBhZ2luZyBsb2NrOyBvdGhlcndpc2UKLSAqIHRoYXQgaXMg
dGhlIGNhbGxlcidzIHJlc3BvbnNpYmlsaXR5LgogICovCiB7CiAgICAgc3Ry
dWN0IGRvbWFpbiAqZCA9IHYtPmRvbWFpbjsKQEAgLTMyNDcsNyArMzI0Mywx
MSBAQCBzaF91cGRhdGVfY3IzKHN0cnVjdCB2Y3B1ICp2LCBib29sIGRvX2xv
Y2tpbmcsIGJvb2wgbm9mbHVzaCkKICAgICAgICAgcmV0dXJuIG9sZF9lbnRy
eTsKICAgICB9CiAKLSAgICBpZiAoIGRvX2xvY2tpbmcgKSBwYWdpbmdfbG9j
ayh2LT5kb21haW4pOworICAgIC8qCisgICAgICogVGhpcyBpcyB1c2VkIGV4
dGVybmFsbHkgKHdpdGggdGhlIHBhZ2luZyBsb2NrIG5vdCB0YWtlbikgYW5k
IGludGVybmFsbHkKKyAgICAgKiBieSB0aGUgc2hhZG93IGNvZGUgKHdpdGgg
dGhlIGxvY2sgYWxyZWFkeSB0YWtlbikuCisgICAgICovCisgICAgcGFnaW5n
X2xvY2tfcmVjdXJzaXZlKHYtPmRvbWFpbik7CiAKICNpZiAoU0hBRE9XX09Q
VElNSVpBVElPTlMgJiBTSE9QVF9PVVRfT0ZfU1lOQykKICAgICAvKiBOZWVk
IHRvIHJlc3luYyBhbGwgdGhlIHNoYWRvdyBlbnRyaWVzIG9uIGEgVExCIGZs
dXNoLiAgUmVzeW5jCkBAIC0zNDgzLDggKzM0ODMsNyBAQCBzaF91cGRhdGVf
Y3IzKHN0cnVjdCB2Y3B1ICp2LCBib29sIGRvX2xvY2tpbmcsIGJvb2wgbm9m
bHVzaCkKICAgICBzaGFkb3dfc3luY19vdGhlcl92Y3B1cyh2KTsKICNlbmRp
ZgogCi0gICAgLyogUmVsZWFzZSB0aGUgbG9jaywgaWYgd2UgdG9vayBpdCAo
b3RoZXJ3aXNlIGl0J3MgdGhlIGNhbGxlcidzIHByb2JsZW0pICovCi0gICAg
aWYgKCBkb19sb2NraW5nICkgcGFnaW5nX3VubG9jayh2LT5kb21haW4pOwor
ICAgIHBhZ2luZ191bmxvY2sodi0+ZG9tYWluKTsKIAogICAgIHJldHVybiBv
bGRfZW50cnk7CiB9CmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYvbW0vc2hh
ZG93L25vbmUuYyBiL3hlbi9hcmNoL3g4Ni9tbS9zaGFkb3cvbm9uZS5jCmlu
ZGV4IDJhNWZkNDA5YjJkOC4uMDAzNTM2OTgwODAzIDEwMDY0NAotLS0gYS94
ZW4vYXJjaC94ODYvbW0vc2hhZG93L25vbmUuYworKysgYi94ZW4vYXJjaC94
ODYvbW0vc2hhZG93L25vbmUuYwpAQCAtNTIsNyArNTIsNyBAQCBzdGF0aWMg
dW5zaWduZWQgbG9uZyBfZ3ZhX3RvX2dmbihzdHJ1Y3QgdmNwdSAqdiwgc3Ry
dWN0IHAybV9kb21haW4gKnAybSwKIH0KICNlbmRpZgogCi1zdGF0aWMgcGFn
ZXRhYmxlX3QgX3VwZGF0ZV9jcjMoc3RydWN0IHZjcHUgKnYsIGJvb2wgZG9f
bG9ja2luZywgYm9vbCBub2ZsdXNoKQorc3RhdGljIHBhZ2V0YWJsZV90IF91
cGRhdGVfY3IzKHN0cnVjdCB2Y3B1ICp2LCBib29sIG5vZmx1c2gpCiB7CiAg
ICAgQVNTRVJUX1VOUkVBQ0hBQkxFKCk7CiAgICAgcmV0dXJuIHBhZ2V0YWJs
ZV9udWxsKCk7CmRpZmYgLS1naXQgYS94ZW4vaW5jbHVkZS9hc20teDg2L3Bh
Z2luZy5oIGIveGVuL2luY2x1ZGUvYXNtLXg4Ni9wYWdpbmcuaAppbmRleCBm
Y2ViMjA4ZDM2NzEuLmJkN2M3MDA4YWU3OSAxMDA2NDQKLS0tIGEveGVuL2lu
Y2x1ZGUvYXNtLXg4Ni9wYWdpbmcuaAorKysgYi94ZW4vaW5jbHVkZS9hc20t
eDg2L3BhZ2luZy5oCkBAIC0xMzgsOCArMTM4LDcgQEAgc3RydWN0IHBhZ2lu
Z19tb2RlIHsKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgcGFkZHJfdCBnYSwgdWludDMyX3QgKnBmZWMsCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVuc2lnbmVk
IGludCAqcGFnZV9vcmRlcik7CiAjZW5kaWYKLSAgICBwYWdldGFibGVfdCAg
ICgqdXBkYXRlX2NyMyAgICAgICAgICAgICkoc3RydWN0IHZjcHUgKnYsIGJv
b2wgZG9fbG9ja2luZywKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgYm9vbCBub2ZsdXNoKTsKKyAgICBwYWdldGFibGVf
dCAgICgqdXBkYXRlX2NyMyAgICAgICAgICAgICkoc3RydWN0IHZjcHUgKnYs
IGJvb2wgbm9mbHVzaCk7CiAgICAgdm9pZCAgICAgICAgICAoKnVwZGF0ZV9w
YWdpbmdfbW9kZXMgICApKHN0cnVjdCB2Y3B1ICp2KTsKICAgICBib29sICAg
ICAgICAgICgqZmx1c2hfdGxiICAgICAgICAgICAgICkoYm9vbCAoKmZsdXNo
X3ZjcHUpKHZvaWQgKmN0eHQsCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHJ1Y3Qg
dmNwdSAqdiksCkBAIC0zMTcsNyArMzE2LDcgQEAgc3RhdGljIGlubGluZSB1
bnNpZ25lZCBsb25nIHBhZ2luZ19nYV90b19nZm5fY3IzKHN0cnVjdCB2Y3B1
ICp2LAogICogYXMgdGhlIHZhbHVlIHRvIGxvYWQgaW50byB0aGUgaG9zdCBD
UjMgdG8gc2NoZWR1bGUgdGhpcyB2Y3B1ICovCiBzdGF0aWMgaW5saW5lIHBh
Z2V0YWJsZV90IHBhZ2luZ191cGRhdGVfY3IzKHN0cnVjdCB2Y3B1ICp2LCBi
b29sIG5vZmx1c2gpCiB7Ci0gICAgcmV0dXJuIHBhZ2luZ19nZXRfaG9zdG1v
ZGUodiktPnVwZGF0ZV9jcjModiwgMSwgbm9mbHVzaCk7CisgICAgcmV0dXJu
IHBhZ2luZ19nZXRfaG9zdG1vZGUodiktPnVwZGF0ZV9jcjModiwgbm9mbHVz
aCk7CiB9CiAKIC8qIFVwZGF0ZSBhbGwgdGhlIHRoaW5ncyB0aGF0IGFyZSBk
ZXJpdmVkIGZyb20gdGhlIGd1ZXN0J3MgQ1IwL0NSMy9DUjQuCgo=

--=separator
Content-Type: application/octet-stream; name="xsa453/xsa453-4.16-2.patch"
Content-Disposition: attachment; filename="xsa453/xsa453-4.16-2.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeGVuOiBTd2FwIG9yZGVyIG9mIGFjdGlvbnMgaW4gdGhl
IEZSRUUqKCkgbWFjcm9zCgpXaGVyZXZlciBwb3NzaWJsZSwgaXQgaXMgYSBn
b29kIGlkZWEgdG8gTlVMTCBvdXQgdGhlIHZpc2libGUgcmVmZXJlbmNlIHRv
IGFuCm9iamVjdCBwcmlvciB0byBmcmVlaW5nIGl0LiAgVGhlIEZSRUUqKCkg
bWFjcm9zIGFscmVhZHkgY29sbGVjdCB0b2dldGhlciBib3RoCnBhcnRzLCBt
YWtpbmcgaXQgZWFzeSB0byBhZGp1c3QuCgpUaGlzIGhhcyBhIG1hcmdpbmFs
IGNvZGUgZ2VuZXJhdGlvbiBpbXByb3ZlbWVudCwgYXMgc29tZSBvZiB0aGUg
Y2FsbHMgdG8gdGhlCmZyZWUoKSBmdW5jdGlvbiBjYW4gYmUgdGFpbGNhbGwg
b3B0aW1pc2VkLgoKTm8gZnVuY3Rpb25hbCBjaGFuZ2UuCgpTaWduZWQtb2Zm
LWJ5OiBBbmRyZXcgQ29vcGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29t
PgpBY2tlZC1ieTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgoo
Y2hlcnJ5IHBpY2tlZCBmcm9tIGNvbW1pdCBjNGY0MjdlYzg3OWU3YzBkZjZk
NDRkMDI1NjFlOGJlZTgzOGEyOTNlKQoKZGlmZiAtLWdpdCBhL3hlbi9pbmNs
dWRlL3hlbi9tbS5oIGIveGVuL2luY2x1ZGUveGVuL21tLmgKaW5kZXggM2Y1
YzI5NjEzOGNmLi5jMGI3N2Q1NjNkODAgMTAwNjQ0Ci0tLSBhL3hlbi9pbmNs
dWRlL3hlbi9tbS5oCisrKyBiL3hlbi9pbmNsdWRlL3hlbi9tbS5oCkBAIC04
MCw4ICs4MCw5IEBAIGJvb2wgc2NydWJfZnJlZV9wYWdlcyh2b2lkKTsKIAog
LyogRnJlZSBhbiBhbGxvY2F0aW9uLCBhbmQgemVybyB0aGUgcG9pbnRlciB0
byBpdC4gKi8KICNkZWZpbmUgRlJFRV9YRU5IRUFQX1BBR0VTKHAsIG8pIGRv
IHsgXAotICAgIGZyZWVfeGVuaGVhcF9wYWdlcyhwLCBvKTsgICAgICAgICBc
CisgICAgdm9pZCAqX3B0cl8gPSAocCk7ICAgICAgICAgICAgICAgIFwKICAg
ICAocCkgPSBOVUxMOyAgICAgICAgICAgICAgICAgICAgICAgXAorICAgIGZy
ZWVfeGVuaGVhcF9wYWdlcyhfcHRyXywgbyk7ICAgICBcCiB9IHdoaWxlICgg
ZmFsc2UgKQogI2RlZmluZSBGUkVFX1hFTkhFQVBfUEFHRShwKSBGUkVFX1hF
TkhFQVBfUEFHRVMocCwgMCkKIApkaWZmIC0tZ2l0IGEveGVuL2luY2x1ZGUv
eGVuL3htYWxsb2MuaCBiL3hlbi9pbmNsdWRlL3hlbi94bWFsbG9jLmgKaW5k
ZXggMTY5NzlhMTE3YzZhLi5kODU3Mjk4MDExYzEgMTAwNjQ0Ci0tLSBhL3hl
bi9pbmNsdWRlL3hlbi94bWFsbG9jLmgKKysrIGIveGVuL2luY2x1ZGUveGVu
L3htYWxsb2MuaApAQCAtNjYsOSArNjYsMTAgQEAKIGV4dGVybiB2b2lkIHhm
cmVlKHZvaWQgKik7CiAKIC8qIEZyZWUgYW4gYWxsb2NhdGlvbiwgYW5kIHpl
cm8gdGhlIHBvaW50ZXIgdG8gaXQuICovCi0jZGVmaW5lIFhGUkVFKHApIGRv
IHsgXAotICAgIHhmcmVlKHApOyAgICAgICAgIFwKLSAgICAocCkgPSBOVUxM
OyAgICAgICBcCisjZGVmaW5lIFhGUkVFKHApIGRvIHsgICAgICAgICAgICAg
ICAgICAgICAgIFwKKyAgICB2b2lkICpfcHRyXyA9IChwKTsgICAgICAgICAg
ICAgICAgICAgICAgXAorICAgIChwKSA9IE5VTEw7ICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBcCisgICAgeGZyZWUoX3B0cl8pOyAgICAgICAgICAg
ICAgICAgICAgICAgICAgIFwKIH0gd2hpbGUgKCBmYWxzZSApCiAKIC8qIFVu
ZGVybHlpbmcgZnVuY3Rpb25zICovCg==

--=separator
Content-Type: application/octet-stream; name="xsa453/xsa453-4.16-3.patch"
Content-Disposition: attachment; filename="xsa453/xsa453-4.16-3.patch"
Content-Transfer-Encoding: base64

RnJvbTogPT9VVEYtOD9xP1JvZ2VyPTIwUGF1PTIwTW9ubj1DMz1BOT89IDxy
b2dlci5wYXVAY2l0cml4LmNvbT4KU3ViamVjdDogeDg2L3NwaW5sb2NrOiBp
bnRyb2R1Y2Ugc3VwcG9ydCBmb3IgYmxvY2tpbmcgc3BlY3VsYXRpb24gaW50
bwogY3JpdGljYWwgcmVnaW9ucwoKSW50cm9kdWNlIGEgbmV3IEtjb25maWcg
b3B0aW9uIHRvIGJsb2NrIHNwZWN1bGF0aW9uIGludG8gbG9jayBwcm90ZWN0
ZWQKY3JpdGljYWwgcmVnaW9ucy4gIFRoZSBLY29uZmlnIG9wdGlvbiBpcyBl
bmFibGVkIGJ5IGRlZmF1bHQsIGJ1dCB0aGUgbWl0aWdhdGlvbgp3b24ndCBi
ZSBlbmdhZ2VkIHVubGVzcyBpdCdzIGV4cGxpY2l0bHkgZW5hYmxlZCBpbiB0
aGUgY29tbWFuZCBsaW5lIHVzaW5nCmBzcGVjLWN0cmw9bG9jay1oYXJkZW5g
LgoKQ29udmVydCB0aGUgc3BpbmxvY2sgYWNxdWlyZSBtYWNyb3MgaW50byBh
bHdheXMtaW5saW5lIGZ1bmN0aW9ucywgYW5kIGludHJvZHVjZQphIHNwZWN1
bGF0aW9uIGJhcnJpZXIgYWZ0ZXIgdGhlIGxvY2sgaGFzIGJlZW4gdGFrZW4u
ICBOb3RlIHRoZSBzcGVjdWxhdGlvbgpiYXJyaWVyIGlzIG5vdCBwbGFjZWQg
aW5zaWRlIHRoZSBpbXBsZW1lbnRhdGlvbiBvZiB0aGUgc3BpbiBsb2NrIGZ1
bmN0aW9ucywgYXMKdG8gcHJldmVudCBzcGVjdWxhdGlvbiBmcm9tIGZhbGxp
bmcgdGhyb3VnaCB0aGUgY2FsbCB0byB0aGUgbG9jayBmdW5jdGlvbnMKcmVz
dWx0aW5nIGluIHRoZSBiYXJyaWVyIGFsc28gYmVpbmcgc2tpcHBlZC4KCnRy
eWxvY2sgdmFyaWFudHMgYXJlIHByb3RlY3RlZCB1c2luZyBhIGNvbnN0cnVj
dCBha2luIHRvIHRoZSBleGlzdGluZwpldmFsdWF0ZV9ub3NwZWMoKS4KClRo
aXMgcGF0Y2ggb25seSBpbXBsZW1lbnRzIHRoZSBzcGVjdWxhdGlvbiBiYXJy
aWVyIGZvciB4ODYuCgpOb3RlIHNwaW4gbG9ja3MgYXJlIHRoZSBvbmx5IGxv
Y2tpbmcgcHJpbWl0aXZlIHRha2VuIGNhcmUgaW4gdGhpcyBjaGFuZ2UsCmZ1
cnRoZXIgbG9ja2luZyBwcmltaXRpdmVzIHdpbGwgYmUgYWRqdXN0ZWQgYnkg
c2VwYXJhdGUgY2hhbmdlcy4KClRoaXMgaXMgcGFydCBvZiBYU0EtNDUzIC8g
Q1ZFLTIwMjQtMjE5MwoKU2lnbmVkLW9mZi1ieTogUm9nZXIgUGF1IE1vbm7D
qSA8cm9nZXIucGF1QGNpdHJpeC5jb20+ClJldmlld2VkLWJ5OiBKYW4gQmV1
bGljaCA8amJldWxpY2hAc3VzZS5jb20+CihjaGVycnkgcGlja2VkIGZyb20g
Y29tbWl0IDdlZjAwODQ0MThlMTg4ZDA1ZjMzOGMzZTAyOGZiYmU4YjY5MjRh
ZmEpCgpkaWZmIC0tZ2l0IGEvZG9jcy9taXNjL3hlbi1jb21tYW5kLWxpbmUu
cGFuZG9jIGIvZG9jcy9taXNjL3hlbi1jb21tYW5kLWxpbmUucGFuZG9jCmlu
ZGV4IDAyOTAwMmZhODJkNi4uMzNjMzJjZmMxY2JjIDEwMDY0NAotLS0gYS9k
b2NzL21pc2MveGVuLWNvbW1hbmQtbGluZS5wYW5kb2MKKysrIGIvZG9jcy9t
aXNjL3hlbi1jb21tYW5kLWxpbmUucGFuZG9jCkBAIC0yMjYzLDcgKzIyNjMs
NyBAQCBCeSBkZWZhdWx0IFNTQkQgd2lsbCBiZSBtaXRpZ2F0ZWQgYXQgcnVu
dGltZSAoaS5lIGBzc2JkPXJ1bnRpbWVgKS4KID4gICAgICAgICAgICAgIHtt
c3Itc2MscnNiLHZlcncsaWJwYi1lbnRyeX09PGJvb2w+fHtwdixodm19PTxi
b29sPiwKID4gICAgICAgICAgICAgIGJ0aS10aHVuaz1yZXRwb2xpbmV8bGZl
bmNlfGptcCwge2licnMsaWJwYixzc2JkLHBzZmQsCiA+ICAgICAgICAgICAg
ICBlYWdlci1mcHUsbDFkLWZsdXNoLGJyYW5jaC1oYXJkZW4sc3JiLWxvY2ss
Ci0+ICAgICAgICAgICAgICB1bnByaXYtbW1pbyxnZHMtbWl0LGRpdi1zY3J1
Yn09PGJvb2w+IF1gCis+ICAgICAgICAgICAgICB1bnByaXYtbW1pbyxnZHMt
bWl0LGRpdi1zY3J1Yixsb2NrLWhhcmRlbn09PGJvb2w+IF1gCiAKIENvbnRy
b2xzIGZvciBzcGVjdWxhdGl2ZSBleGVjdXRpb24gc2lkZWNoYW5uZWwgbWl0
aWdhdGlvbnMuICBCeSBkZWZhdWx0LCBYZW4KIHdpbGwgcGljayB0aGUgbW9z
dCBhcHByb3ByaWF0ZSBtaXRpZ2F0aW9ucyBiYXNlZCBvbiBjb21waWxlZCBp
biBzdXBwb3J0LApAQCAtMjM4OCw2ICsyMzg4LDExIEBAIE9uIGFsbCBoYXJk
d2FyZSwgdGhlIGBkaXYtc2NydWI9YCBvcHRpb24gY2FuIGJlIHVzZWQgdG8g
Zm9yY2Ugb3IgcHJldmVudCBYZW4KIGZyb20gbWl0aWdhdGluZyB0aGUgRElW
LWxlYWthZ2UgdnVsbmVyYWJpbGl0eS4gIEJ5IGRlZmF1bHQsIFhlbiB3aWxs
IG1pdGlnYXRlCiBESVYtbGVha2FnZSBvbiBoYXJkd2FyZSBiZWxpZXZlZCB0
byBiZSB2dWxuZXJhYmxlLgogCitJZiBYZW4gaXMgY29tcGlsZWQgd2l0aCBg
Q09ORklHX1NQRUNVTEFUSVZFX0hBUkRFTl9MT0NLYCwgdGhlIGBsb2NrLWhh
cmRlbj1gCitib29sZWFuIGNhbiBiZSB1c2VkIHRvIGZvcmNlIG9yIHByZXZl
bnQgWGVuIGZyb20gdXNpbmcgc3BlY3VsYXRpb24gYmFycmllcnMgdG8KK3By
b3RlY3QgbG9jayBjcml0aWNhbCByZWdpb25zLiAgVGhpcyBtaXRpZ2F0aW9u
IHdvbid0IGJlIGVuZ2FnZWQgYnkgZGVmYXVsdCwKK2FuZCBuZWVkcyB0byBi
ZSBleHBsaWNpdGx5IGVuYWJsZWQgb24gdGhlIGNvbW1hbmQgbGluZS4KKwog
IyMjIHN5bmNfY29uc29sZQogPiBgPSA8Ym9vbGVhbj5gCiAKZGlmZiAtLWdp
dCBhL3hlbi9hcmNoL3g4Ni9zcGVjX2N0cmwuYyBiL3hlbi9hcmNoL3g4Ni9z
cGVjX2N0cmwuYwppbmRleCAyNGJmOThhMDE4YTAuLjBhN2FmMjJhOWIzYyAx
MDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L3NwZWNfY3RybC5jCisrKyBiL3hl
bi9hcmNoL3g4Ni9zcGVjX2N0cmwuYwpAQCAtNjMsNiArNjMsNyBAQCBpbnQ4
X3QgX19yZWFkX21vc3RseSBvcHRfaWJwYl9jdHh0X3N3aXRjaCA9IC0xOwog
aW50OF90IF9fcmVhZF9tb3N0bHkgb3B0X2VhZ2VyX2ZwdSA9IC0xOwogaW50
OF90IF9fcmVhZF9tb3N0bHkgb3B0X2wxZF9mbHVzaCA9IC0xOwogc3RhdGlj
IGJvb2wgX19pbml0ZGF0YSBvcHRfYnJhbmNoX2hhcmRlbiA9IHRydWU7Citz
dGF0aWMgYm9vbCBfX2luaXRkYXRhIG9wdF9sb2NrX2hhcmRlbjsKIAogYm9v
bCBfX2luaXRkYXRhIGJzcF9kZWxheV9zcGVjX2N0cmw7CiB1aW50OF90IF9f
cmVhZF9tb3N0bHkgZGVmYXVsdF94ZW5fc3BlY19jdHJsOwpAQCAtMTMxLDYg
KzEzMiw3IEBAIHN0YXRpYyBpbnQgX19pbml0IHBhcnNlX3NwZWNfY3RybChj
b25zdCBjaGFyICpzKQogICAgICAgICAgICAgb3B0X3NzYmQgPSBmYWxzZTsK
ICAgICAgICAgICAgIG9wdF9sMWRfZmx1c2ggPSAwOwogICAgICAgICAgICAg
b3B0X2JyYW5jaF9oYXJkZW4gPSBmYWxzZTsKKyAgICAgICAgICAgIG9wdF9s
b2NrX2hhcmRlbiA9IGZhbHNlOwogICAgICAgICAgICAgb3B0X3NyYl9sb2Nr
ID0gMDsKICAgICAgICAgICAgIG9wdF91bnByaXZfbW1pbyA9IGZhbHNlOwog
ICAgICAgICAgICAgb3B0X2dkc19taXQgPSAwOwpAQCAtMjgyLDYgKzI4NCwx
NiBAQCBzdGF0aWMgaW50IF9faW5pdCBwYXJzZV9zcGVjX2N0cmwoY29uc3Qg
Y2hhciAqcykKICAgICAgICAgICAgIG9wdF9sMWRfZmx1c2ggPSB2YWw7CiAg
ICAgICAgIGVsc2UgaWYgKCAodmFsID0gcGFyc2VfYm9vbGVhbigiYnJhbmNo
LWhhcmRlbiIsIHMsIHNzKSkgPj0gMCApCiAgICAgICAgICAgICBvcHRfYnJh
bmNoX2hhcmRlbiA9IHZhbDsKKyAgICAgICAgZWxzZSBpZiAoICh2YWwgPSBw
YXJzZV9ib29sZWFuKCJsb2NrLWhhcmRlbiIsIHMsIHNzKSkgPj0gMCApCisg
ICAgICAgIHsKKyAgICAgICAgICAgIGlmICggSVNfRU5BQkxFRChDT05GSUdf
U1BFQ1VMQVRJVkVfSEFSREVOX0xPQ0spICkKKyAgICAgICAgICAgICAgICBv
cHRfbG9ja19oYXJkZW4gPSB2YWw7CisgICAgICAgICAgICBlbHNlCisgICAg
ICAgICAgICB7CisgICAgICAgICAgICAgICAgbm9fY29uZmlnX3BhcmFtKCJT
UEVDVUxBVElWRV9IQVJERU5fTE9DSyIsICJzcGVjLWN0cmwiLCBzLCBzcyk7
CisgICAgICAgICAgICAgICAgcmMgPSAtRUlOVkFMOworICAgICAgICAgICAg
fQorICAgICAgICB9CiAgICAgICAgIGVsc2UgaWYgKCAodmFsID0gcGFyc2Vf
Ym9vbGVhbigic3JiLWxvY2siLCBzLCBzcykpID49IDAgKQogICAgICAgICAg
ICAgb3B0X3NyYl9sb2NrID0gdmFsOwogICAgICAgICBlbHNlIGlmICggKHZh
bCA9IHBhcnNlX2Jvb2xlYW4oInVucHJpdi1tbWlvIiwgcywgc3MpKSA+PSAw
ICkKQEAgLTQ4MSwxOCArNDkzLDIyIEBAIHN0YXRpYyB2b2lkIF9faW5pdCBw
cmludF9kZXRhaWxzKGVudW0gaW5kX3RodW5rIHRodW5rKQogICAgICAgICAg
ICAoZTIxYSAmIGNwdWZlYXRfbWFzayhYODZfRkVBVFVSRV9TQlBCKSkgICAg
ICAgICAgID8gIiBTQlBCIiAgICAgICAgICAgOiAiIik7CiAKICAgICAvKiBD
b21waWxlZC1pbiBzdXBwb3J0IHdoaWNoIHBlcnRhaW5zIHRvIG1pdGlnYXRp
b25zLiAqLwotICAgIGlmICggSVNfRU5BQkxFRChDT05GSUdfSU5ESVJFQ1Rf
VEhVTkspIHx8IElTX0VOQUJMRUQoQ09ORklHX1NIQURPV19QQUdJTkcpICkK
KyAgICBpZiAoIElTX0VOQUJMRUQoQ09ORklHX0lORElSRUNUX1RIVU5LKSB8
fCBJU19FTkFCTEVEKENPTkZJR19TSEFET1dfUEFHSU5HKSB8fAorICAgICAg
ICAgSVNfRU5BQkxFRChDT05GSUdfU1BFQ1VMQVRJVkVfSEFSREVOX0xPQ0sp
ICkKICAgICAgICAgcHJpbnRrKCIgIENvbXBpbGVkLWluIHN1cHBvcnQ6Igog
I2lmZGVmIENPTkZJR19JTkRJUkVDVF9USFVOSwogICAgICAgICAgICAgICAg
IiBJTkRJUkVDVF9USFVOSyIKICNlbmRpZgogI2lmZGVmIENPTkZJR19TSEFE
T1dfUEFHSU5HCiAgICAgICAgICAgICAgICAiIFNIQURPV19QQUdJTkciCisj
ZW5kaWYKKyNpZmRlZiBDT05GSUdfU1BFQ1VMQVRJVkVfSEFSREVOX0xPQ0sK
KyAgICAgICAgICAgICAgICIgSEFSREVOX0xPQ0siCiAjZW5kaWYKICAgICAg
ICAgICAgICAgICJcbiIpOwogCiAgICAgLyogU2V0dGluZ3MgZm9yIFhlbidz
IHByb3RlY3Rpb24sIGlycmVzcGVjdGl2ZSBvZiBndWVzdHMuICovCi0gICAg
cHJpbnRrKCIgIFhlbiBzZXR0aW5nczogQlRJLVRodW5rICVzLCBTUEVDX0NU
Ukw6ICVzJXMlcyVzJXMsIE90aGVyOiVzJXMlcyVzJXMlc1xuIiwKKyAgICBw
cmludGsoIiAgWGVuIHNldHRpbmdzOiBCVEktVGh1bmsgJXMsIFNQRUNfQ1RS
TDogJXMlcyVzJXMlcywgT3RoZXI6JXMlcyVzJXMlcyVzJXNcbiIsCiAgICAg
ICAgICAgIHRodW5rID09IFRIVU5LX05PTkUgICAgICA/ICJOL0EiIDoKICAg
ICAgICAgICAgdGh1bmsgPT0gVEhVTktfUkVUUE9MSU5FID8gIlJFVFBPTElO
RSIgOgogICAgICAgICAgICB0aHVuayA9PSBUSFVOS19MRkVOQ0UgICAgPyAi
TEZFTkNFIiA6CkBAIC01MTgsNyArNTM0LDggQEAgc3RhdGljIHZvaWQgX19p
bml0IHByaW50X2RldGFpbHMoZW51bSBpbmRfdGh1bmsgdGh1bmspCiAgICAg
ICAgICAgIG9wdF92ZXJ3X3B2IHx8IG9wdF92ZXJ3X2h2bSB8fAogICAgICAg
ICAgICBvcHRfdmVyd19tbWlvICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICA/ICIgVkVSVyIgIDogIiIsCiAgICAgICAgICAgIG9wdF9kaXZfc2NydWIg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgID8gIiBESVYiIDogIiIsCi0g
ICAgICAgICAgIG9wdF9icmFuY2hfaGFyZGVuICAgICAgICAgICAgICAgICAg
ICAgICAgID8gIiBCUkFOQ0hfSEFSREVOIiA6ICIiKTsKKyAgICAgICAgICAg
b3B0X2JyYW5jaF9oYXJkZW4gICAgICAgICAgICAgICAgICAgICAgICAgPyAi
IEJSQU5DSF9IQVJERU4iIDogIiIsCisgICAgICAgICAgIG9wdF9sb2NrX2hh
cmRlbiAgICAgICAgICAgICAgICAgICAgICAgICAgID8gIiBMT0NLX0hBUkRF
TiIgOiAiIik7CiAKICAgICAvKiBMMVRGIGRpYWdub3N0aWNzLCBwcmludGVk
IGlmIHZ1bG5lcmFibGUgb3IgUFYgc2hhZG93aW5nIGlzIGluIHVzZS4gKi8K
ICAgICBpZiAoIGNwdV9oYXNfYnVnX2wxdGYgfHwgb3B0X3B2X2wxdGZfaHdk
b20gfHwgb3B0X3B2X2wxdGZfZG9tdSApCkBAIC0xODg5LDYgKzE5MDYsOSBA
QCB2b2lkIF9faW5pdCBpbml0X3NwZWN1bGF0aW9uX21pdGlnYXRpb25zKHZv
aWQpCiAgICAgaWYgKCAhb3B0X2JyYW5jaF9oYXJkZW4gKQogICAgICAgICBz
ZXR1cF9mb3JjZV9jcHVfY2FwKFg4Nl9GRUFUVVJFX1NDX05PX0JSQU5DSF9I
QVJERU4pOwogCisgICAgaWYgKCAhb3B0X2xvY2tfaGFyZGVuICkKKyAgICAg
ICAgc2V0dXBfZm9yY2VfY3B1X2NhcChYODZfRkVBVFVSRV9TQ19OT19MT0NL
X0hBUkRFTik7CisKICAgICAvKgogICAgICAqIFdlIGRvIG5vdCBkaXNhYmxl
IEhUIGJ5IGRlZmF1bHQgb24gYWZmZWN0ZWQgaGFyZHdhcmUuCiAgICAgICoK
ZGlmZiAtLWdpdCBhL3hlbi9jb21tb24vS2NvbmZpZyBiL3hlbi9jb21tb24v
S2NvbmZpZwppbmRleCBjOWY0YjdmNDkyNDAuLjAxYzcwMTA5ZjUzOSAxMDA2
NDQKLS0tIGEveGVuL2NvbW1vbi9LY29uZmlnCisrKyBiL3hlbi9jb21tb24v
S2NvbmZpZwpAQCAtMTYxLDYgKzE2MSwyMyBAQCBjb25maWcgU1BFQ1VMQVRJ
VkVfSEFSREVOX0dVRVNUX0FDQ0VTUwogCiAJICBJZiB1bnN1cmUsIHNheSBZ
LgogCitjb25maWcgU1BFQ1VMQVRJVkVfSEFSREVOX0xPQ0sKKwlib29sICJT
cGVjdWxhdGl2ZSBsb2NrIGNvbnRleHQgaGFyZGVuaW5nIgorCWRlZmF1bHQg
eQorCWRlcGVuZHMgb24gWDg2CisJaGVscAorCSAgQ29udGVtcG9yYXJ5IHBy
b2Nlc3NvcnMgbWF5IHVzZSBzcGVjdWxhdGl2ZSBleGVjdXRpb24gYXMgYQor
CSAgcGVyZm9ybWFuY2Ugb3B0aW1pc2F0aW9uLCBidXQgdGhpcyBjYW4gcG90
ZW50aWFsbHkgYmUgYWJ1c2VkIGJ5IGFuCisJICBhdHRhY2tlciB0byBsZWFr
IGRhdGEgdmlhIHNwZWN1bGF0aXZlIHNpZGVjaGFubmVscy4KKworCSAgT25l
IHNvdXJjZSBvZiBkYXRhIGxlYWthZ2UgaXMgdmlhIHNwZWN1bGF0aXZlIGFj
Y2Vzc2VzIHRvIGxvY2sKKwkgIGNyaXRpY2FsIHJlZ2lvbnMuCisKKwkgIFRo
aXMgb3B0aW9uIGlzIGRpc2FibGVkIGJ5IGRlZmF1bHQgYXQgcnVuIHRpbWUs
IGFuZCBuZWVkcyB0byBiZQorCSAgZW5hYmxlZCBvbiB0aGUgY29tbWFuZCBs
aW5lLgorCisJICBJZiB1bnN1cmUsIHNheSBZLgorCiBlbmRtZW51CiAKIGNv
bmZpZyBIWVBGUwpkaWZmIC0tZ2l0IGEveGVuL2luY2x1ZGUvYXNtLXg4Ni9j
cHVmZWF0dXJlcy5oIGIveGVuL2luY2x1ZGUvYXNtLXg4Ni9jcHVmZWF0dXJl
cy5oCmluZGV4IDcwYjkzYjZiNDQzZi4uN2U4MjIxZmQ4NWRkIDEwMDY0NAot
LS0gYS94ZW4vaW5jbHVkZS9hc20teDg2L2NwdWZlYXR1cmVzLmgKKysrIGIv
eGVuL2luY2x1ZGUvYXNtLXg4Ni9jcHVmZWF0dXJlcy5oCkBAIC0yNCw3ICsy
NCw3IEBAIFhFTl9DUFVGRUFUVVJFKEFQRVJGTVBFUkYsICAgICAgICBYODZf
U1lOVEgoIDgpKSAvKiBBUEVSRk1QRVJGICovCiBYRU5fQ1BVRkVBVFVSRShN
RkVOQ0VfUkRUU0MsICAgICAgWDg2X1NZTlRIKCA5KSkgLyogTUZFTkNFIHN5
bmNocm9uaXplcyBSRFRTQyAqLwogWEVOX0NQVUZFQVRVUkUoWEVOX1NNRVAs
ICAgICAgICAgIFg4Nl9TWU5USCgxMCkpIC8qIFNNRVAgZ2V0cyB1c2VkIGJ5
IFhlbiBpdHNlbGYgKi8KIFhFTl9DUFVGRUFUVVJFKFhFTl9TTUFQLCAgICAg
ICAgICBYODZfU1lOVEgoMTEpKSAvKiBTTUFQIGdldHMgdXNlZCBieSBYZW4g
aXRzZWxmICovCi0vKiBCaXQgMTIgLSB1bnVzZWQuICovCitYRU5fQ1BVRkVB
VFVSRShTQ19OT19MT0NLX0hBUkRFTiwgWDg2X1NZTlRIKDEyKSkgLyogKERp
c2FibGUpIExvY2sgY3JpdGljYWwgcmVnaW9uIGhhcmRlbmluZyAqLwogWEVO
X0NQVUZFQVRVUkUoSU5EX1RIVU5LX0xGRU5DRSwgIFg4Nl9TWU5USCgxMykp
IC8qIFVzZSBJTkRfVEhVTktfTEZFTkNFICovCiBYRU5fQ1BVRkVBVFVSRShJ
TkRfVEhVTktfSk1QLCAgICAgWDg2X1NZTlRIKDE0KSkgLyogVXNlIElORF9U
SFVOS19KTVAgKi8KIFhFTl9DUFVGRUFUVVJFKFNDX05PX0JSQU5DSF9IQVJE
RU4sIFg4Nl9TWU5USCgxNSkpIC8qIChEaXNhYmxlKSBDb25kaXRpb25hbCBi
cmFuY2ggaGFyZGVuaW5nICovCmRpZmYgLS1naXQgYS94ZW4vaW5jbHVkZS9h
c20teDg2L25vc3BlYy5oIGIveGVuL2luY2x1ZGUvYXNtLXg4Ni9ub3NwZWMu
aAppbmRleCA3MTUwZTc2Yjg3ZmIuLjA3MjU4MzllMTk4MiAxMDA2NDQKLS0t
IGEveGVuL2luY2x1ZGUvYXNtLXg4Ni9ub3NwZWMuaAorKysgYi94ZW4vaW5j
bHVkZS9hc20teDg2L25vc3BlYy5oCkBAIC0zOCw2ICszOCwzMiBAQCBzdGF0
aWMgYWx3YXlzX2lubGluZSB2b2lkIGJsb2NrX3NwZWN1bGF0aW9uKHZvaWQp
CiAgICAgYmFycmllcl9ub3NwZWNfdHJ1ZSgpOwogfQogCitzdGF0aWMgYWx3
YXlzX2lubGluZSB2b2lkIGFyY2hfYmxvY2tfbG9ja19zcGVjdWxhdGlvbih2
b2lkKQoreworICAgIGFsdGVybmF0aXZlKCJsZmVuY2UiLCAiIiwgWDg2X0ZF
QVRVUkVfU0NfTk9fTE9DS19IQVJERU4pOworfQorCisvKiBBbGxvdyB0byBp
bnNlcnQgYSByZWFkIG1lbW9yeSBiYXJyaWVyIGludG8gY29uZGl0aW9uYWxz
ICovCitzdGF0aWMgYWx3YXlzX2lubGluZSBib29sIGJhcnJpZXJfbG9ja190
cnVlKHZvaWQpCit7CisgICAgYWx0ZXJuYXRpdmUoImxmZW5jZSAjbm9zcGVj
LXRydWUiLCAiIiwgWDg2X0ZFQVRVUkVfU0NfTk9fTE9DS19IQVJERU4pOwor
ICAgIHJldHVybiB0cnVlOworfQorCitzdGF0aWMgYWx3YXlzX2lubGluZSBi
b29sIGJhcnJpZXJfbG9ja19mYWxzZSh2b2lkKQoreworICAgIGFsdGVybmF0
aXZlKCJsZmVuY2UgI25vc3BlYy1mYWxzZSIsICIiLCBYODZfRkVBVFVSRV9T
Q19OT19MT0NLX0hBUkRFTik7CisgICAgcmV0dXJuIGZhbHNlOworfQorCitz
dGF0aWMgYWx3YXlzX2lubGluZSBib29sIGFyY2hfbG9ja19ldmFsdWF0ZV9u
b3NwZWMoYm9vbCBjb25kaXRpb24pCit7CisgICAgaWYgKCBjb25kaXRpb24g
KQorICAgICAgICByZXR1cm4gYmFycmllcl9sb2NrX3RydWUoKTsKKyAgICBl
bHNlCisgICAgICAgIHJldHVybiBiYXJyaWVyX2xvY2tfZmFsc2UoKTsKK30K
KwogI2VuZGlmIC8qIF9BU01fWDg2X05PU1BFQ19IICovCiAKIC8qCmRpZmYg
LS1naXQgYS94ZW4vaW5jbHVkZS94ZW4vbm9zcGVjLmggYi94ZW4vaW5jbHVk
ZS94ZW4vbm9zcGVjLmgKaW5kZXggNzYyNTViYzQ2ZWZlLi40NTUyODQ2NDAz
OTYgMTAwNjQ0Ci0tLSBhL3hlbi9pbmNsdWRlL3hlbi9ub3NwZWMuaAorKysg
Yi94ZW4vaW5jbHVkZS94ZW4vbm9zcGVjLmgKQEAgLTcwLDYgKzcwLDIxIEBA
IHN0YXRpYyBpbmxpbmUgdW5zaWduZWQgbG9uZyBhcnJheV9pbmRleF9tYXNr
X25vc3BlYyh1bnNpZ25lZCBsb25nIGluZGV4LAogI2RlZmluZSBhcnJheV9h
Y2Nlc3Nfbm9zcGVjKGFycmF5LCBpbmRleCkgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgXAogICAgIChhcnJheSlbYXJyYXlfaW5kZXhfbm9zcGVj
KGluZGV4LCBBUlJBWV9TSVpFKGFycmF5KSldCiAKK3N0YXRpYyBhbHdheXNf
aW5saW5lIHZvaWQgYmxvY2tfbG9ja19zcGVjdWxhdGlvbih2b2lkKQorewor
I2lmZGVmIENPTkZJR19TUEVDVUxBVElWRV9IQVJERU5fTE9DSworICAgIGFy
Y2hfYmxvY2tfbG9ja19zcGVjdWxhdGlvbigpOworI2VuZGlmCit9CisKK3N0
YXRpYyBhbHdheXNfaW5saW5lIGJvb2wgbG9ja19ldmFsdWF0ZV9ub3NwZWMo
Ym9vbCBjb25kaXRpb24pCit7CisjaWZkZWYgQ09ORklHX1NQRUNVTEFUSVZF
X0hBUkRFTl9MT0NLCisgICAgcmV0dXJuIGFyY2hfbG9ja19ldmFsdWF0ZV9u
b3NwZWMoY29uZGl0aW9uKTsKKyNlbmRpZgorICAgIHJldHVybiBjb25kaXRp
b247Cit9CisKICNlbmRpZiAvKiBYRU5fTk9TUEVDX0ggKi8KIAogLyoKZGlm
ZiAtLWdpdCBhL3hlbi9pbmNsdWRlL3hlbi9zcGlubG9jay5oIGIveGVuL2lu
Y2x1ZGUveGVuL3NwaW5sb2NrLmgKaW5kZXggOWZhNGU2MDBjMWY3Li5lZmRi
MjFlYTkwNzIgMTAwNjQ0Ci0tLSBhL3hlbi9pbmNsdWRlL3hlbi9zcGlubG9j
ay5oCisrKyBiL3hlbi9pbmNsdWRlL3hlbi9zcGlubG9jay5oCkBAIC0xLDYg
KzEsNyBAQAogI2lmbmRlZiBfX1NQSU5MT0NLX0hfXwogI2RlZmluZSBfX1NQ
SU5MT0NLX0hfXwogCisjaW5jbHVkZSA8eGVuL25vc3BlYy5oPgogI2luY2x1
ZGUgPHhlbi90aW1lLmg+CiAjaW5jbHVkZSA8YXNtL3N5c3RlbS5oPgogI2lu
Y2x1ZGUgPGFzbS9zcGlubG9jay5oPgpAQCAtMTg5LDEzICsxOTAsMzAgQEAg
aW50IF9zcGluX3RyeWxvY2tfcmVjdXJzaXZlKHNwaW5sb2NrX3QgKmxvY2sp
Owogdm9pZCBfc3Bpbl9sb2NrX3JlY3Vyc2l2ZShzcGlubG9ja190ICpsb2Nr
KTsKIHZvaWQgX3NwaW5fdW5sb2NrX3JlY3Vyc2l2ZShzcGlubG9ja190ICps
b2NrKTsKIAotI2RlZmluZSBzcGluX2xvY2sobCkgICAgICAgICAgICAgICAg
ICBfc3Bpbl9sb2NrKGwpCi0jZGVmaW5lIHNwaW5fbG9ja19jYihsLCBjLCBk
KSAgICAgICAgIF9zcGluX2xvY2tfY2IobCwgYywgZCkKLSNkZWZpbmUgc3Bp
bl9sb2NrX2lycShsKSAgICAgICAgICAgICAgX3NwaW5fbG9ja19pcnEobCkK
K3N0YXRpYyBhbHdheXNfaW5saW5lIHZvaWQgc3Bpbl9sb2NrKHNwaW5sb2Nr
X3QgKmwpCit7CisgICAgX3NwaW5fbG9jayhsKTsKKyAgICBibG9ja19sb2Nr
X3NwZWN1bGF0aW9uKCk7Cit9CisKK3N0YXRpYyBhbHdheXNfaW5saW5lIHZv
aWQgc3Bpbl9sb2NrX2NiKHNwaW5sb2NrX3QgKmwsIHZvaWQgKCpjKSh2b2lk
ICpkYXRhKSwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIHZvaWQgKmQpCit7CisgICAgX3NwaW5fbG9ja19jYihsLCBjLCBkKTsK
KyAgICBibG9ja19sb2NrX3NwZWN1bGF0aW9uKCk7Cit9CisKK3N0YXRpYyBh
bHdheXNfaW5saW5lIHZvaWQgc3Bpbl9sb2NrX2lycShzcGlubG9ja190ICps
KQoreworICAgIF9zcGluX2xvY2tfaXJxKGwpOworICAgIGJsb2NrX2xvY2tf
c3BlY3VsYXRpb24oKTsKK30KKwogI2RlZmluZSBzcGluX2xvY2tfaXJxc2F2
ZShsLCBmKSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKICAg
ICAoeyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBcCiAgICAgICAgIEJVSUxEX0JVR19PTihzaXpl
b2YoZikgIT0gc2l6ZW9mKHVuc2lnbmVkIGxvbmcpKTsgICAgICAgXAogICAg
ICAgICAoKGYpID0gX3NwaW5fbG9ja19pcnFzYXZlKGwpKTsgICAgICAgICAg
ICAgICAgICAgICAgICAgIFwKKyAgICAgICAgYmxvY2tfbG9ja19zcGVjdWxh
dGlvbigpOyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAg
fSkKIAogI2RlZmluZSBzcGluX3VubG9jayhsKSAgICAgICAgICAgICAgICBf
c3Bpbl91bmxvY2sobCkKQEAgLTIwMyw3ICsyMjEsNyBAQCB2b2lkIF9zcGlu
X3VubG9ja19yZWN1cnNpdmUoc3BpbmxvY2tfdCAqbG9jayk7CiAjZGVmaW5l
IHNwaW5fdW5sb2NrX2lycXJlc3RvcmUobCwgZikgIF9zcGluX3VubG9ja19p
cnFyZXN0b3JlKGwsIGYpCiAKICNkZWZpbmUgc3Bpbl9pc19sb2NrZWQobCkg
ICAgICAgICAgICAgX3NwaW5faXNfbG9ja2VkKGwpCi0jZGVmaW5lIHNwaW5f
dHJ5bG9jayhsKSAgICAgICAgICAgICAgIF9zcGluX3RyeWxvY2sobCkKKyNk
ZWZpbmUgc3Bpbl90cnlsb2NrKGwpICAgICAgICAgICAgICAgbG9ja19ldmFs
dWF0ZV9ub3NwZWMoX3NwaW5fdHJ5bG9jayhsKSkKIAogI2RlZmluZSBzcGlu
X3RyeWxvY2tfaXJxc2F2ZShsb2NrLCBmbGFncykgICAgICAgXAogKHsgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXApA
QCAtMjI0LDggKzI0MiwxNSBAQCB2b2lkIF9zcGluX3VubG9ja19yZWN1cnNp
dmUoc3BpbmxvY2tfdCAqbG9jayk7CiAgKiBhcmUgYW55IGNyaXRpY2FsIHJl
Z2lvbnMgdGhhdCBjYW5ub3QgZm9ybSBwYXJ0IG9mIHN1Y2ggYSBzZXQsIHRo
ZXkgY2FuIHVzZQogICogc3RhbmRhcmQgc3Bpbl9bdW5dbG9jaygpLgogICov
Ci0jZGVmaW5lIHNwaW5fdHJ5bG9ja19yZWN1cnNpdmUobCkgICAgIF9zcGlu
X3RyeWxvY2tfcmVjdXJzaXZlKGwpCi0jZGVmaW5lIHNwaW5fbG9ja19yZWN1
cnNpdmUobCkgICAgICAgIF9zcGluX2xvY2tfcmVjdXJzaXZlKGwpCisjZGVm
aW5lIHNwaW5fdHJ5bG9ja19yZWN1cnNpdmUobCkgXAorICAgIGxvY2tfZXZh
bHVhdGVfbm9zcGVjKF9zcGluX3RyeWxvY2tfcmVjdXJzaXZlKGwpKQorCitz
dGF0aWMgYWx3YXlzX2lubGluZSB2b2lkIHNwaW5fbG9ja19yZWN1cnNpdmUo
c3BpbmxvY2tfdCAqbCkKK3sKKyAgICBfc3Bpbl9sb2NrX3JlY3Vyc2l2ZShs
KTsKKyAgICBibG9ja19sb2NrX3NwZWN1bGF0aW9uKCk7Cit9CisKICNkZWZp
bmUgc3Bpbl91bmxvY2tfcmVjdXJzaXZlKGwpICAgICAgX3NwaW5fdW5sb2Nr
X3JlY3Vyc2l2ZShsKQogCiAjZW5kaWYgLyogX19TUElOTE9DS19IX18gKi8K

--=separator
Content-Type: application/octet-stream; name="xsa453/xsa453-4.16-4.patch"
Content-Disposition: attachment; filename="xsa453/xsa453-4.16-4.patch"
Content-Transfer-Encoding: base64

RnJvbTogPT9VVEYtOD9xP1JvZ2VyPTIwUGF1PTIwTW9ubj1DMz1BOT89IDxy
b2dlci5wYXVAY2l0cml4LmNvbT4KU3ViamVjdDogcndsb2NrOiBpbnRyb2R1
Y2Ugc3VwcG9ydCBmb3IgYmxvY2tpbmcgc3BlY3VsYXRpb24gaW50byBjcml0
aWNhbAogcmVnaW9ucwoKSW50cm9kdWNlIGlubGluZSB3cmFwcGVycyBhcyBy
ZXF1aXJlZCBhbmQgYWRkIGRpcmVjdCBjYWxscyB0bwpibG9ja19sb2NrX3Nw
ZWN1bGF0aW9uKCkgaW4gb3JkZXIgdG8gcHJldmVudCBzcGVjdWxhdGlvbiBp
bnRvIHRoZSByd2xvY2sKcHJvdGVjdGVkIGNyaXRpY2FsIHJlZ2lvbnMuCgpO
b3RlIHRoZSByd2xvY2sgcHJpbWl0aXZlcyBhcmUgYWRqdXN0ZWQgdG8gdXNl
IHRoZSBub24gc3BlY3VsYXRpb24gc2FmZSB2YXJpYW50cwpvZiB0aGUgc3Bp
bmxvY2sgaGFuZGxlcnMsIGFzIGEgc3BlY3VsYXRpb24gYmFycmllciBpcyBh
ZGRlZCBpbiB0aGUgcndsb2NrCmNhbGxpbmcgd3JhcHBlcnMuCgp0cnlsb2Nr
IHZhcmlhbnRzIGFyZSBwcm90ZWN0ZWQgYnkgdXNpbmcgbG9ja19ldmFsdWF0
ZV9ub3NwZWMoKS4KClRoaXMgaXMgcGFydCBvZiBYU0EtNDUzIC8gQ1ZFLTIw
MjQtMjE5MwoKU2lnbmVkLW9mZi1ieTogUm9nZXIgUGF1IE1vbm7DqSA8cm9n
ZXIucGF1QGNpdHJpeC5jb20+ClJldmlld2VkLWJ5OiBKYW4gQmV1bGljaCA8
amJldWxpY2hAc3VzZS5jb20+CihjaGVycnkgcGlja2VkIGZyb20gY29tbWl0
IGExZmIxNWY2MTY5MmIxZmE5OTQ1ZmM1MWY1NTQ3MWFjZTQ5Y2RkNTkpCgpk
aWZmIC0tZ2l0IGEveGVuL2NvbW1vbi9yd2xvY2suYyBiL3hlbi9jb21tb24v
cndsb2NrLmMKaW5kZXggZGFkYWIzNzJiNWUxLi4yNDY0Zjc0NTQ4NWQgMTAw
NjQ0Ci0tLSBhL3hlbi9jb21tb24vcndsb2NrLmMKKysrIGIveGVuL2NvbW1v
bi9yd2xvY2suYwpAQCAtMzQsOCArMzQsMTEgQEAgdm9pZCBxdWV1ZV9yZWFk
X2xvY2tfc2xvd3BhdGgocndsb2NrX3QgKmxvY2spCiAKICAgICAvKgogICAg
ICAqIFB1dCB0aGUgcmVhZGVyIGludG8gdGhlIHdhaXQgcXVldWUuCisgICAg
ICoKKyAgICAgKiBVc2UgdGhlIHNwZWN1bGF0aW9uIHVuc2FmZSBoZWxwZXIs
IGFzIGl0J3MgdGhlIGNhbGxlciByZXNwb25zaWJpbGl0eSB0bworICAgICAq
IGlzc3VlIGEgc3BlY3VsYXRpb24gYmFycmllciBpZiByZXF1aXJlZC4KICAg
ICAgKi8KLSAgICBzcGluX2xvY2soJmxvY2stPmxvY2spOworICAgIF9zcGlu
X2xvY2soJmxvY2stPmxvY2spOwogCiAgICAgLyoKICAgICAgKiBBdCB0aGUg
aGVhZCBvZiB0aGUgd2FpdCBxdWV1ZSBub3csIHdhaXQgdW50aWwgdGhlIHdy
aXRlciBzdGF0ZQpAQCAtNjQsOCArNjcsMTMgQEAgdm9pZCBxdWV1ZV93cml0
ZV9sb2NrX3Nsb3dwYXRoKHJ3bG9ja190ICpsb2NrKQogewogICAgIHUzMiBj
bnRzOwogCi0gICAgLyogUHV0IHRoZSB3cml0ZXIgaW50byB0aGUgd2FpdCBx
dWV1ZS4gKi8KLSAgICBzcGluX2xvY2soJmxvY2stPmxvY2spOworICAgIC8q
CisgICAgICogUHV0IHRoZSB3cml0ZXIgaW50byB0aGUgd2FpdCBxdWV1ZS4K
KyAgICAgKgorICAgICAqIFVzZSB0aGUgc3BlY3VsYXRpb24gdW5zYWZlIGhl
bHBlciwgYXMgaXQncyB0aGUgY2FsbGVyIHJlc3BvbnNpYmlsaXR5IHRvCisg
ICAgICogaXNzdWUgYSBzcGVjdWxhdGlvbiBiYXJyaWVyIGlmIHJlcXVpcmVk
LgorICAgICAqLworICAgIF9zcGluX2xvY2soJmxvY2stPmxvY2spOwogCiAg
ICAgLyogVHJ5IHRvIGFjcXVpcmUgdGhlIGxvY2sgZGlyZWN0bHkgaWYgbm8g
cmVhZGVyIGlzIHByZXNlbnQuICovCiAgICAgaWYgKCAhYXRvbWljX3JlYWQo
JmxvY2stPmNudHMpICYmCmRpZmYgLS1naXQgYS94ZW4vaW5jbHVkZS94ZW4v
cndsb2NrLmggYi94ZW4vaW5jbHVkZS94ZW4vcndsb2NrLmgKaW5kZXggMGNj
OTE2NzcxNWIzLi5mZDA0NThiZTk0YWUgMTAwNjQ0Ci0tLSBhL3hlbi9pbmNs
dWRlL3hlbi9yd2xvY2suaAorKysgYi94ZW4vaW5jbHVkZS94ZW4vcndsb2Nr
LmgKQEAgLTI0NywyNyArMjQ3LDQ5IEBAIHN0YXRpYyBpbmxpbmUgaW50IF9y
d19pc193cml0ZV9sb2NrZWQocndsb2NrX3QgKmxvY2spCiAgICAgcmV0dXJu
IChhdG9taWNfcmVhZCgmbG9jay0+Y250cykgJiBfUVdfV01BU0spID09IF9R
V19MT0NLRUQ7CiB9CiAKLSNkZWZpbmUgcmVhZF9sb2NrKGwpICAgICAgICAg
ICAgICAgICAgX3JlYWRfbG9jayhsKQotI2RlZmluZSByZWFkX2xvY2tfaXJx
KGwpICAgICAgICAgICAgICBfcmVhZF9sb2NrX2lycShsKQorc3RhdGljIGFs
d2F5c19pbmxpbmUgdm9pZCByZWFkX2xvY2socndsb2NrX3QgKmwpCit7Cisg
ICAgX3JlYWRfbG9jayhsKTsKKyAgICBibG9ja19sb2NrX3NwZWN1bGF0aW9u
KCk7Cit9CisKK3N0YXRpYyBhbHdheXNfaW5saW5lIHZvaWQgcmVhZF9sb2Nr
X2lycShyd2xvY2tfdCAqbCkKK3sKKyAgICBfcmVhZF9sb2NrX2lycShsKTsK
KyAgICBibG9ja19sb2NrX3NwZWN1bGF0aW9uKCk7Cit9CisKICNkZWZpbmUg
cmVhZF9sb2NrX2lycXNhdmUobCwgZikgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBcCiAgICAgKHsgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAogICAgICAgICBC
VUlMRF9CVUdfT04oc2l6ZW9mKGYpICE9IHNpemVvZih1bnNpZ25lZCBsb25n
KSk7ICAgICAgIFwKICAgICAgICAgKChmKSA9IF9yZWFkX2xvY2tfaXJxc2F2
ZShsKSk7ICAgICAgICAgICAgICAgICAgICAgICAgICBcCisgICAgICAgIGJs
b2NrX2xvY2tfc3BlY3VsYXRpb24oKTsgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgXAogICAgIH0pCiAKICNkZWZpbmUgcmVhZF91bmxvY2sobCkg
ICAgICAgICAgICAgICAgX3JlYWRfdW5sb2NrKGwpCiAjZGVmaW5lIHJlYWRf
dW5sb2NrX2lycShsKSAgICAgICAgICAgIF9yZWFkX3VubG9ja19pcnEobCkK
ICNkZWZpbmUgcmVhZF91bmxvY2tfaXJxcmVzdG9yZShsLCBmKSAgX3JlYWRf
dW5sb2NrX2lycXJlc3RvcmUobCwgZikKLSNkZWZpbmUgcmVhZF90cnlsb2Nr
KGwpICAgICAgICAgICAgICAgX3JlYWRfdHJ5bG9jayhsKQorI2RlZmluZSBy
ZWFkX3RyeWxvY2sobCkgICAgICAgICAgICAgICBsb2NrX2V2YWx1YXRlX25v
c3BlYyhfcmVhZF90cnlsb2NrKGwpKQorCitzdGF0aWMgYWx3YXlzX2lubGlu
ZSB2b2lkIHdyaXRlX2xvY2socndsb2NrX3QgKmwpCit7CisgICAgX3dyaXRl
X2xvY2sobCk7CisgICAgYmxvY2tfbG9ja19zcGVjdWxhdGlvbigpOworfQor
CitzdGF0aWMgYWx3YXlzX2lubGluZSB2b2lkIHdyaXRlX2xvY2tfaXJxKHJ3
bG9ja190ICpsKQoreworICAgIF93cml0ZV9sb2NrX2lycShsKTsKKyAgICBi
bG9ja19sb2NrX3NwZWN1bGF0aW9uKCk7Cit9CiAKLSNkZWZpbmUgd3JpdGVf
bG9jayhsKSAgICAgICAgICAgICAgICAgX3dyaXRlX2xvY2sobCkKLSNkZWZp
bmUgd3JpdGVfbG9ja19pcnEobCkgICAgICAgICAgICAgX3dyaXRlX2xvY2tf
aXJxKGwpCiAjZGVmaW5lIHdyaXRlX2xvY2tfaXJxc2F2ZShsLCBmKSAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgXAogICAgICh7ICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIFwKICAgICAgICAgQlVJTERfQlVHX09OKHNpemVvZihmKSAhPSBzaXpl
b2YodW5zaWduZWQgbG9uZykpOyAgICAgICBcCiAgICAgICAgICgoZikgPSBf
d3JpdGVfbG9ja19pcnFzYXZlKGwpKTsgICAgICAgICAgICAgICAgICAgICAg
ICAgXAorICAgICAgICBibG9ja19sb2NrX3NwZWN1bGF0aW9uKCk7ICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIFwKICAgICB9KQotI2RlZmluZSB3
cml0ZV90cnlsb2NrKGwpICAgICAgICAgICAgICBfd3JpdGVfdHJ5bG9jayhs
KQorI2RlZmluZSB3cml0ZV90cnlsb2NrKGwpICAgICAgICAgICAgICBsb2Nr
X2V2YWx1YXRlX25vc3BlYyhfd3JpdGVfdHJ5bG9jayhsKSkKIAogI2RlZmlu
ZSB3cml0ZV91bmxvY2sobCkgICAgICAgICAgICAgICBfd3JpdGVfdW5sb2Nr
KGwpCiAjZGVmaW5lIHdyaXRlX3VubG9ja19pcnEobCkgICAgICAgICAgIF93
cml0ZV91bmxvY2tfaXJxKGwpCg==

--=separator
Content-Type: application/octet-stream; name="xsa453/xsa453-4.16-5.patch"
Content-Disposition: attachment; filename="xsa453/xsa453-4.16-5.patch"
Content-Transfer-Encoding: base64

RnJvbTogPT9VVEYtOD9xP1JvZ2VyPTIwUGF1PTIwTW9ubj1DMz1BOT89IDxy
b2dlci5wYXVAY2l0cml4LmNvbT4KU3ViamVjdDogcGVyY3B1LXJ3bG9jazog
aW50cm9kdWNlIHN1cHBvcnQgZm9yIGJsb2NraW5nIHNwZWN1bGF0aW9uIGlu
dG8KIGNyaXRpY2FsIHJlZ2lvbnMKCkFkZCBkaXJlY3QgY2FsbHMgdG8gYmxv
Y2tfbG9ja19zcGVjdWxhdGlvbigpIHdoZXJlIHJlcXVpcmVkIGluIG9yZGVy
IHRvIHByZXZlbnQKc3BlY3VsYXRpb24gaW50byB0aGUgbG9jayBwcm90ZWN0
ZWQgY3JpdGljYWwgcmVnaW9ucy4gIEFsc28gY29udmVydApfcGVyY3B1X3Jl
YWRfbG9jaygpIGZyb20gaW5saW5lIHRvIGFsd2F5c19pbmxpbmUuCgpOb3Rl
IHRoYXQgX3BlcmNwdV93cml0ZV9sb2NrKCkgaGFzIGJlZW4gbW9kaWZpZWQg
dGhlIHVzZSB0aGUgbm9uIHNwZWN1bGF0aW9uCnNhZmUgb2YgdGhlIGxvY2tp
bmcgcHJpbWl0ZXMsIGFzIGEgc3BlY3VsYXRpb24gaXMgYWRkZWQgdW5jb25k
aXRpb25hbGx5IGJ5IHRoZQpjYWxsaW5nIHdyYXBwZXIuCgpUaGlzIGlzIHBh
cnQgb2YgWFNBLTQ1MyAvIENWRS0yMDI0LTIxOTMKClNpZ25lZC1vZmYtYnk6
IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXguY29tPgpSZXZp
ZXdlZC1ieTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgooY2hl
cnJ5IHBpY2tlZCBmcm9tIGNvbW1pdCBmMjE4ZGFmNmQzYTNiODQ3NzM2ZDM3
YzZhNmI3NjAzMWEwZDA4NDQxKQoKZGlmZiAtLWdpdCBhL3hlbi9jb21tb24v
cndsb2NrLmMgYi94ZW4vY29tbW9uL3J3bG9jay5jCmluZGV4IDI0NjRmNzQ1
NDg1ZC4uNzAzMjc2ZjRhYTYzIDEwMDY0NAotLS0gYS94ZW4vY29tbW9uL3J3
bG9jay5jCisrKyBiL3hlbi9jb21tb24vcndsb2NrLmMKQEAgLTEyNSw4ICsx
MjUsMTIgQEAgdm9pZCBfcGVyY3B1X3dyaXRlX2xvY2socGVyY3B1X3J3bG9j
a190ICoqcGVyX2NwdWRhdGEsCiAgICAgLyoKICAgICAgKiBGaXJzdCB0YWtl
IHRoZSB3cml0ZSBsb2NrIHRvIHByb3RlY3QgYWdhaW5zdCBvdGhlciB3cml0
ZXJzIG9yIHNsb3cKICAgICAgKiBwYXRoIHJlYWRlcnMuCisgICAgICoKKyAg
ICAgKiBOb3RlIHdlIHVzZSB0aGUgc3BlY3VsYXRpb24gdW5zYWZlIHZhcmlh
bnQgb2Ygd3JpdGVfbG9jaygpLCBhcyB0aGUKKyAgICAgKiBjYWxsaW5nIHdy
YXBwZXIgYWxyZWFkeSBhZGRzIGEgc3BlY3VsYXRpb24gYmFycmllciBhZnRl
ciB0aGUgbG9jayBoYXMKKyAgICAgKiBiZWVuIHRha2VuLgogICAgICAqLwot
ICAgIHdyaXRlX2xvY2soJnBlcmNwdV9yd2xvY2stPnJ3bG9jayk7CisgICAg
X3dyaXRlX2xvY2soJnBlcmNwdV9yd2xvY2stPnJ3bG9jayk7CiAKICAgICAv
KiBOb3cgc2V0IHRoZSBnbG9iYWwgdmFyaWFibGUgc28gdGhhdCByZWFkZXJz
IHN0YXJ0IHVzaW5nIHJlYWRfbG9jay4gKi8KICAgICBwZXJjcHVfcndsb2Nr
LT53cml0ZXJfYWN0aXZhdGluZyA9IDE7CmRpZmYgLS1naXQgYS94ZW4vaW5j
bHVkZS94ZW4vcndsb2NrLmggYi94ZW4vaW5jbHVkZS94ZW4vcndsb2NrLmgK
aW5kZXggZmQwNDU4YmU5NGFlLi5hYmUwODA0YmY3ZDUgMTAwNjQ0Ci0tLSBh
L3hlbi9pbmNsdWRlL3hlbi9yd2xvY2suaAorKysgYi94ZW4vaW5jbHVkZS94
ZW4vcndsb2NrLmgKQEAgLTMyNiw4ICszMjYsOCBAQCBzdGF0aWMgaW5saW5l
IHZvaWQgX3BlcmNwdV9yd2xvY2tfb3duZXJfY2hlY2socGVyY3B1X3J3bG9j
a190ICoqcGVyX2NwdWRhdGEsCiAjZGVmaW5lIHBlcmNwdV9yd2xvY2tfcmVz
b3VyY2VfaW5pdChsLCBvd25lcikgXAogICAgICgqKGwpID0gKHBlcmNwdV9y
d2xvY2tfdClQRVJDUFVfUldfTE9DS19VTkxPQ0tFRCgmZ2V0X3Blcl9jcHVf
dmFyKG93bmVyKSkpCiAKLXN0YXRpYyBpbmxpbmUgdm9pZCBfcGVyY3B1X3Jl
YWRfbG9jayhwZXJjcHVfcndsb2NrX3QgKipwZXJfY3B1ZGF0YSwKLSAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcGVyY3B1X3J3
bG9ja190ICpwZXJjcHVfcndsb2NrKQorc3RhdGljIGFsd2F5c19pbmxpbmUg
dm9pZCBfcGVyY3B1X3JlYWRfbG9jayhwZXJjcHVfcndsb2NrX3QgKipwZXJf
Y3B1ZGF0YSwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgcGVyY3B1X3J3bG9ja190ICpwZXJjcHVfcndsb2NrKQogewog
ICAgIC8qIFZhbGlkYXRlIHRoZSBjb3JyZWN0IHBlcl9jcHVkYXRhIHZhcmlh
YmxlIGhhcyBiZWVuIHByb3ZpZGVkLiAqLwogICAgIF9wZXJjcHVfcndsb2Nr
X293bmVyX2NoZWNrKHBlcl9jcHVkYXRhLCBwZXJjcHVfcndsb2NrKTsKQEAg
LTM2Miw2ICszNjIsOCBAQCBzdGF0aWMgaW5saW5lIHZvaWQgX3BlcmNwdV9y
ZWFkX2xvY2socGVyY3B1X3J3bG9ja190ICoqcGVyX2NwdWRhdGEsCiAgICAg
fQogICAgIGVsc2UKICAgICB7CisgICAgICAgIC8qIE90aGVyIGJyYW5jaCBh
bHJlYWR5IGhhcyBhIHNwZWN1bGF0aW9uIGJhcnJpZXIgaW4gcmVhZF9sb2Nr
KCkuICovCisgICAgICAgIGJsb2NrX2xvY2tfc3BlY3VsYXRpb24oKTsKICAg
ICAgICAgLyogQWxsIG90aGVyIHBhdGhzIGhhdmUgaW1wbGljaXQgY2hlY2tf
bG9jaygpIGNhbGxzIHZpYSByZWFkX2xvY2soKS4gKi8KICAgICAgICAgY2hl
Y2tfbG9jaygmcGVyY3B1X3J3bG9jay0+cndsb2NrLmxvY2suZGVidWcsIGZh
bHNlKTsKICAgICB9CkBAIC00MTAsOCArNDEyLDEyIEBAIHN0YXRpYyBpbmxp
bmUgdm9pZCBfcGVyY3B1X3dyaXRlX3VubG9jayhwZXJjcHVfcndsb2NrX3Qg
KipwZXJfY3B1ZGF0YSwKICAgICBfcGVyY3B1X3JlYWRfbG9jaygmZ2V0X3Bl
cl9jcHVfdmFyKHBlcmNwdSksIGxvY2spCiAjZGVmaW5lIHBlcmNwdV9yZWFk
X3VubG9jayhwZXJjcHUsIGxvY2spIFwKICAgICBfcGVyY3B1X3JlYWRfdW5s
b2NrKCZnZXRfcGVyX2NwdV92YXIocGVyY3B1KSwgbG9jaykKLSNkZWZpbmUg
cGVyY3B1X3dyaXRlX2xvY2socGVyY3B1LCBsb2NrKSBcCi0gICAgX3BlcmNw
dV93cml0ZV9sb2NrKCZnZXRfcGVyX2NwdV92YXIocGVyY3B1KSwgbG9jaykK
KworI2RlZmluZSBwZXJjcHVfd3JpdGVfbG9jayhwZXJjcHUsIGxvY2spICAg
ICAgICAgICAgICAgICBcCisoeyAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKKyAgICBfcGVyY3B1X3dy
aXRlX2xvY2soJmdldF9wZXJfY3B1X3ZhcihwZXJjcHUpLCBsb2NrKTsgXAor
ICAgIGJsb2NrX2xvY2tfc3BlY3VsYXRpb24oKTsgICAgICAgICAgICAgICAg
ICAgICAgICAgICBcCit9KQogI2RlZmluZSBwZXJjcHVfd3JpdGVfdW5sb2Nr
KHBlcmNwdSwgbG9jaykgXAogICAgIF9wZXJjcHVfd3JpdGVfdW5sb2NrKCZn
ZXRfcGVyX2NwdV92YXIocGVyY3B1KSwgbG9jaykKIAo=

--=separator
Content-Type: application/octet-stream; name="xsa453/xsa453-4.16-6.patch"
Content-Disposition: attachment; filename="xsa453/xsa453-4.16-6.patch"
Content-Transfer-Encoding: base64

RnJvbTogPT9VVEYtOD9xP1JvZ2VyPTIwUGF1PTIwTW9ubj1DMz1BOT89IDxy
b2dlci5wYXVAY2l0cml4LmNvbT4KU3ViamVjdDogbG9ja2luZzogYXR0ZW1w
dCB0byBlbnN1cmUgbG9jayB3cmFwcGVycyBhcmUgYWx3YXlzIGlubGluZQoK
SW4gb3JkZXIgdG8gcHJldmVudCB0aGUgbG9ja2luZyBzcGVjdWxhdGlvbiBi
YXJyaWVycyBmcm9tIGJlaW5nIGluc2lkZSBvZgpgY2FsbGBlZCBmdW5jdGlv
bnMgdGhhdCBjb3VsZCBiZSBzcGVjdWxhdGl2ZWx5IGJ5cGFzc2VkLgoKV2hp
bGUgdGhlcmUgYWxzbyBhZGQgYW4gZXh0cmEgbG9ja2luZyBiYXJyaWVyIHRv
IF9tbV93cml0ZV9sb2NrKCkgaW4gdGhlIGJyYW5jaAp0YWtlbiB3aGVuIHRo
ZSBsb2NrIGlzIGFscmVhZHkgaGVsZC4KCk5vdGUgc29tZSBmdW5jdGlvbnMg
YXJlIHN3aXRjaGVkIHRvIHVzZSB0aGUgdW5zYWZlIHZhcmlhbnRzICh3aXRo
b3V0IHNwZWN1bGF0aW9uCmJhcnJpZXIpIG9mIHRoZSBsb2NraW5nIHByaW1p
dGl2ZXMsIGJ1dCBhIHNwZWN1bGF0aW9uIGJhcnJpZXIgaXMgYWx3YXlzIGFk
ZGVkCnRvIHRoZSBleHBvc2VkIHB1YmxpYyBsb2NrIHdyYXBwaW5nIGhlbHBl
ci4gIFRoYXQncyB0aGUgY2FzZSB3aXRoCnNjaGVkX3NwaW5fbG9ja19kb3Vi
bGUoKSBvciBwY2lkZXZzX2xvY2soKSBmb3IgZXhhbXBsZS4KClRoaXMgaXMg
cGFydCBvZiBYU0EtNDUzIC8gQ1ZFLTIwMjQtMjE5MwoKU2lnbmVkLW9mZi1i
eTogUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5jb20+ClJl
dmlld2VkLWJ5OiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+Cihj
aGVycnkgcGlja2VkIGZyb20gY29tbWl0IDE5N2VjZDgzOGEyYWFmOTU5YTQ2
OWRmMzY5NmQ0NTU5YzRmOGI3NjIpCgpkaWZmIC0tZ2l0IGEveGVuL2FyY2gv
eDg2L2h2bS92cHQuYyBiL3hlbi9hcmNoL3g4Ni9odm0vdnB0LmMKaW5kZXgg
NmZkYzNlMTlmZThjLi5kZDJkZTU3NGNmMTggMTAwNjQ0Ci0tLSBhL3hlbi9h
cmNoL3g4Ni9odm0vdnB0LmMKKysrIGIveGVuL2FyY2gveDg2L2h2bS92cHQu
YwpAQCAtMTYxLDcgKzE2MSw3IEBAIHN0YXRpYyBpbnQgcHRfaXJxX21hc2tl
ZChzdHJ1Y3QgcGVyaW9kaWNfdGltZSAqcHQpCiAgKiBwdC0+dmNwdSBmaWVs
ZCwgYmVjYXVzZSBhbm90aGVyIHRocmVhZCBob2xkaW5nIHRoZSBwdF9taWdy
YXRlIGxvY2sKICAqIG1heSBhbHJlYWR5IGJlIHNwaW5uaW5nIHdhaXRpbmcg
Zm9yIHlvdXIgdmNwdSBsb2NrLgogICovCi1zdGF0aWMgdm9pZCBwdF92Y3B1
X2xvY2soc3RydWN0IHZjcHUgKnYpCitzdGF0aWMgYWx3YXlzX2lubGluZSB2
b2lkIHB0X3ZjcHVfbG9jayhzdHJ1Y3QgdmNwdSAqdikKIHsKICAgICBzcGlu
X2xvY2soJnYtPmFyY2guaHZtLnRtX2xvY2spOwogfQpAQCAtMTgwLDkgKzE4
MCwxMyBAQCBzdGF0aWMgdm9pZCBwdF92Y3B1X3VubG9jayhzdHJ1Y3QgdmNw
dSAqdikKICAqIG5lZWQgdG8gdGFrZSBhbiBhZGRpdGlvbmFsIGxvY2sgdGhh
dCBwcm90ZWN0cyBhZ2FpbnN0IHB0LT52Y3B1CiAgKiBjaGFuZ2luZy4KICAq
Lwotc3RhdGljIHZvaWQgcHRfbG9jayhzdHJ1Y3QgcGVyaW9kaWNfdGltZSAq
cHQpCitzdGF0aWMgYWx3YXlzX2lubGluZSB2b2lkIHB0X2xvY2soc3RydWN0
IHBlcmlvZGljX3RpbWUgKnB0KQogewotICAgIHJlYWRfbG9jaygmcHQtPnZj
cHUtPmRvbWFpbi0+YXJjaC5odm0ucGxfdGltZS0+cHRfbWlncmF0ZSk7Cisg
ICAgLyoKKyAgICAgKiBVc2UgdGhlIHNwZWN1bGF0aW9uIHVuc2FmZSB2YXJp
YW50IGZvciB0aGUgZmlyc3QgbG9jaywgYXMgdGhlIGZvbGxvd2luZworICAg
ICAqIGxvY2sgdGFraW5nIGhlbHBlciBhbHJlYWR5IGluY2x1ZGVzIGEgc3Bl
Y3VsYXRpb24gYmFycmllci4KKyAgICAgKi8KKyAgICBfcmVhZF9sb2NrKCZw
dC0+dmNwdS0+ZG9tYWluLT5hcmNoLmh2bS5wbF90aW1lLT5wdF9taWdyYXRl
KTsKICAgICBzcGluX2xvY2soJnB0LT52Y3B1LT5hcmNoLmh2bS50bV9sb2Nr
KTsKIH0KIApkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L21tL21tLWxvY2tz
LmggYi94ZW4vYXJjaC94ODYvbW0vbW0tbG9ja3MuaAppbmRleCBkNmMwNzNk
YzVjZjUuLmNjNjM1YTQ0MDU3MSAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2
L21tL21tLWxvY2tzLmgKKysrIGIveGVuL2FyY2gveDg2L21tL21tLWxvY2tz
LmgKQEAgLTg4LDggKzg4LDggQEAgc3RhdGljIGlubGluZSB2b2lkIF9zZXRf
bG9ja19sZXZlbChpbnQgbCkKICAgICB0aGlzX2NwdShtbV9sb2NrX2xldmVs
KSA9IGw7CiB9CiAKLXN0YXRpYyBpbmxpbmUgdm9pZCBfbW1fbG9jayhjb25z
dCBzdHJ1Y3QgZG9tYWluICpkLCBtbV9sb2NrX3QgKmwsCi0gICAgICAgICAg
ICAgICAgICAgICAgICAgICAgY29uc3QgY2hhciAqZnVuYywgaW50IGxldmVs
LCBpbnQgcmVjKQorc3RhdGljIGFsd2F5c19pbmxpbmUgdm9pZCBfbW1fbG9j
ayhjb25zdCBzdHJ1Y3QgZG9tYWluICpkLCBtbV9sb2NrX3QgKmwsCisgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IGNoYXIgKmZ1
bmMsIGludCBsZXZlbCwgaW50IHJlYykKIHsKICAgICBpZiAoICEoKG1tX2xv
Y2tlZF9ieV9tZShsKSkgJiYgcmVjKSApCiAgICAgICAgIF9jaGVja19sb2Nr
X2xldmVsKGQsIGxldmVsKTsKQEAgLTEzOSw4ICsxMzksOCBAQCBzdGF0aWMg
aW5saW5lIGludCBtbV93cml0ZV9sb2NrZWRfYnlfbWUobW1fcndsb2NrX3Qg
KmwpCiAgICAgcmV0dXJuIChsLT5sb2NrZXIgPT0gZ2V0X3Byb2Nlc3Nvcl9p
ZCgpKTsKIH0KIAotc3RhdGljIGlubGluZSB2b2lkIF9tbV93cml0ZV9sb2Nr
KGNvbnN0IHN0cnVjdCBkb21haW4gKmQsIG1tX3J3bG9ja190ICpsLAotICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IGNoYXIgKmZ1
bmMsIGludCBsZXZlbCkKK3N0YXRpYyBhbHdheXNfaW5saW5lIHZvaWQgX21t
X3dyaXRlX2xvY2soY29uc3Qgc3RydWN0IGRvbWFpbiAqZCwgbW1fcndsb2Nr
X3QgKmwsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIGNvbnN0IGNoYXIgKmZ1bmMsIGludCBsZXZlbCkKIHsKICAgICBpZiAo
ICFtbV93cml0ZV9sb2NrZWRfYnlfbWUobCkgKQogICAgIHsKQEAgLTE1MSw2
ICsxNTEsOCBAQCBzdGF0aWMgaW5saW5lIHZvaWQgX21tX3dyaXRlX2xvY2so
Y29uc3Qgc3RydWN0IGRvbWFpbiAqZCwgbW1fcndsb2NrX3QgKmwsCiAgICAg
ICAgIGwtPnVubG9ja19sZXZlbCA9IF9nZXRfbG9ja19sZXZlbCgpOwogICAg
ICAgICBfc2V0X2xvY2tfbGV2ZWwoX2xvY2tfbGV2ZWwoZCwgbGV2ZWwpKTsK
ICAgICB9CisgICAgZWxzZQorICAgICAgICBibG9ja19zcGVjdWxhdGlvbigp
OwogICAgIGwtPnJlY3Vyc2VfY291bnQrKzsKIH0KIApAQCAtMTY0LDggKzE2
Niw4IEBAIHN0YXRpYyBpbmxpbmUgdm9pZCBtbV93cml0ZV91bmxvY2sobW1f
cndsb2NrX3QgKmwpCiAgICAgcGVyY3B1X3dyaXRlX3VubG9jayhwMm1fcGVy
Y3B1X3J3bG9jaywgJmwtPmxvY2spOwogfQogCi1zdGF0aWMgaW5saW5lIHZv
aWQgX21tX3JlYWRfbG9jayhjb25zdCBzdHJ1Y3QgZG9tYWluICpkLCBtbV9y
d2xvY2tfdCAqbCwKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IGludCBsZXZlbCkKK3N0YXRpYyBhbHdheXNfaW5saW5lIHZvaWQgX21tX3Jl
YWRfbG9jayhjb25zdCBzdHJ1Y3QgZG9tYWluICpkLCBtbV9yd2xvY2tfdCAq
bCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBp
bnQgbGV2ZWwpCiB7CiAgICAgX2NoZWNrX2xvY2tfbGV2ZWwoZCwgbGV2ZWwp
OwogICAgIHBlcmNwdV9yZWFkX2xvY2socDJtX3BlcmNwdV9yd2xvY2ssICZs
LT5sb2NrKTsKQEAgLTE4MCwxNSArMTgyLDE1IEBAIHN0YXRpYyBpbmxpbmUg
dm9pZCBtbV9yZWFkX3VubG9jayhtbV9yd2xvY2tfdCAqbCkKIAogLyogVGhp
cyB3cmFwcGVyIHVzZXMgdGhlIGxpbmUgbnVtYmVyIHRvIGV4cHJlc3MgdGhl
IGxvY2tpbmcgb3JkZXIgYmVsb3cgKi8KICNkZWZpbmUgZGVjbGFyZV9tbV9s
b2NrKG5hbWUpICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIFwKLSAgICBzdGF0aWMgaW5saW5lIHZvaWQgbW1fbG9j
a18jI25hbWUoY29uc3Qgc3RydWN0IGRvbWFpbiAqZCwgbW1fbG9ja190ICps
LCAgIFwKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
Y29uc3QgY2hhciAqZnVuYywgaW50IHJlYykgICAgICAgICAgICAgIFwKKyAg
ICBzdGF0aWMgYWx3YXlzX2lubGluZSB2b2lkIG1tX2xvY2tfIyNuYW1lKCAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKKyAgICAgICAgY29u
c3Qgc3RydWN0IGRvbWFpbiAqZCwgbW1fbG9ja190ICpsLCBjb25zdCBjaGFy
ICpmdW5jLCBpbnQgcmVjKSAgICAgIFwKICAgICB7IF9tbV9sb2NrKGQsIGws
IGZ1bmMsIE1NX0xPQ0tfT1JERVJfIyNuYW1lLCByZWMpOyB9CiAjZGVmaW5l
IGRlY2xhcmVfbW1fcndsb2NrKG5hbWUpICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBcCi0gICAgc3RhdGljIGlubGlu
ZSB2b2lkIG1tX3dyaXRlX2xvY2tfIyNuYW1lKGNvbnN0IHN0cnVjdCBkb21h
aW4gKmQsICAgICAgICAgICBcCi0gICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIG1tX3J3bG9ja190ICpsLCBjb25zdCBjaGFy
ICpmdW5jKSBcCisgICAgc3RhdGljIGFsd2F5c19pbmxpbmUgdm9pZCBtbV93
cml0ZV9sb2NrXyMjbmFtZSggICAgICAgICAgICAgICAgICAgICAgICAgICBc
CisgICAgICAgIGNvbnN0IHN0cnVjdCBkb21haW4gKmQsIG1tX3J3bG9ja190
ICpsLCBjb25zdCBjaGFyICpmdW5jKSAgICAgICAgICAgICBcCiAgICAgeyBf
bW1fd3JpdGVfbG9jayhkLCBsLCBmdW5jLCBNTV9MT0NLX09SREVSXyMjbmFt
ZSk7IH0gICAgICAgICAgICAgICAgICAgICBcCi0gICAgc3RhdGljIGlubGlu
ZSB2b2lkIG1tX3JlYWRfbG9ja18jI25hbWUoY29uc3Qgc3RydWN0IGRvbWFp
biAqZCwgICAgICAgICAgICBcCi0gICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgbW1fcndsb2NrX3QgKmwpICAgICAgICAgICAg
ICAgICAgICBcCisgICAgc3RhdGljIGFsd2F5c19pbmxpbmUgdm9pZCBtbV9y
ZWFkX2xvY2tfIyNuYW1lKGNvbnN0IHN0cnVjdCBkb21haW4gKmQsICAgICBc
CisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIG1tX3J3bG9ja190ICpsKSAgICAgICAgICAgICBcCiAgICAgeyBf
bW1fcmVhZF9sb2NrKGQsIGwsIE1NX0xPQ0tfT1JERVJfIyNuYW1lKTsgfQog
LyogVGhlc2UgY2FwdHVyZSB0aGUgbmFtZSBvZiB0aGUgY2FsbGluZyBmdW5j
dGlvbiAqLwogI2RlZmluZSBtbV9sb2NrKG5hbWUsIGQsIGwpIG1tX2xvY2tf
IyNuYW1lKGQsIGwsIF9fZnVuY19fLCAwKQpAQCAtMzIxLDcgKzMyMyw3IEBA
IGRlY2xhcmVfbW1fbG9jayhhbHRwMm1saXN0KQogI2RlZmluZSBNTV9MT0NL
X09SREVSX2FsdHAybSAgICAgICAgICAgICAgICAgNDAKIGRlY2xhcmVfbW1f
cndsb2NrKGFsdHAybSk7CiAKLXN0YXRpYyBpbmxpbmUgdm9pZCBwMm1fbG9j
ayhzdHJ1Y3QgcDJtX2RvbWFpbiAqcCkKK3N0YXRpYyBhbHdheXNfaW5saW5l
IHZvaWQgcDJtX2xvY2soc3RydWN0IHAybV9kb21haW4gKnApCiB7CiAgICAg
aWYgKCBwMm1faXNfYWx0cDJtKHApICkKICAgICAgICAgbW1fd3JpdGVfbG9j
ayhhbHRwMm0sIHAtPmRvbWFpbiwgJnAtPmxvY2spOwpkaWZmIC0tZ2l0IGEv
eGVuL2FyY2gveDg2L21tL3AybS1wb2QuYyBiL3hlbi9hcmNoL3g4Ni9tbS9w
Mm0tcG9kLmMKaW5kZXggYTNjOWQ4YTk3NDIzLi5jODI2Mjg4NDA4NjQgMTAw
NjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9tbS9wMm0tcG9kLmMKKysrIGIveGVu
L2FyY2gveDg2L21tL3AybS1wb2QuYwpAQCAtMzUsNyArMzUsNyBAQAogI2Rl
ZmluZSBzdXBlcnBhZ2VfYWxpZ25lZChfeCkgICgoKF94KSYoU1VQRVJQQUdF
X1BBR0VTLTEpKT09MCkKIAogLyogRW5mb3JjZSBsb2NrIG9yZGVyaW5nIHdo
ZW4gZ3JhYmJpbmcgdGhlICJleHRlcm5hbCIgcGFnZV9hbGxvYyBsb2NrICov
Ci1zdGF0aWMgaW5saW5lIHZvaWQgbG9ja19wYWdlX2FsbG9jKHN0cnVjdCBw
Mm1fZG9tYWluICpwMm0pCitzdGF0aWMgYWx3YXlzX2lubGluZSB2b2lkIGxv
Y2tfcGFnZV9hbGxvYyhzdHJ1Y3QgcDJtX2RvbWFpbiAqcDJtKQogewogICAg
IHBhZ2VfYWxsb2NfbW1fcHJlX2xvY2socDJtLT5kb21haW4pOwogICAgIHNw
aW5fbG9jaygmKHAybS0+ZG9tYWluLT5wYWdlX2FsbG9jX2xvY2spKTsKZGlm
ZiAtLWdpdCBhL3hlbi9jb21tb24vZXZlbnRfY2hhbm5lbC5jIGIveGVuL2Nv
bW1vbi9ldmVudF9jaGFubmVsLmMKaW5kZXggZGE4OGFkMTQxYTY5Li5lNWY0
ZTY4Yjg4MTkgMTAwNjQ0Ci0tLSBhL3hlbi9jb21tb24vZXZlbnRfY2hhbm5l
bC5jCisrKyBiL3hlbi9jb21tb24vZXZlbnRfY2hhbm5lbC5jCkBAIC01Nyw3
ICs1Nyw3IEBACiAgKiBqdXN0IGFzc3VtZSB0aGUgZXZlbnQgY2hhbm5lbCBp
cyBmcmVlIG9yIHVuYm91bmQgYXQgdGhlIG1vbWVudCB3aGVuIHRoZQogICog
ZXZ0Y2huX3JlYWRfdHJ5bG9jaygpIHJldHVybnMgZmFsc2UuCiAgKi8KLXN0
YXRpYyBpbmxpbmUgdm9pZCBldnRjaG5fd3JpdGVfbG9jayhzdHJ1Y3QgZXZ0
Y2huICpldnRjaG4pCitzdGF0aWMgYWx3YXlzX2lubGluZSB2b2lkIGV2dGNo
bl93cml0ZV9sb2NrKHN0cnVjdCBldnRjaG4gKmV2dGNobikKIHsKICAgICB3
cml0ZV9sb2NrKCZldnRjaG4tPmxvY2spOwogCkBAIC0zMjQsNyArMzI0LDgg
QEAgc3RhdGljIGludCBldnRjaG5fYWxsb2NfdW5ib3VuZChldnRjaG5fYWxs
b2NfdW5ib3VuZF90ICphbGxvYykKICAgICByZXR1cm4gcmM7CiB9CiAKLXN0
YXRpYyB2b2lkIGRvdWJsZV9ldnRjaG5fbG9jayhzdHJ1Y3QgZXZ0Y2huICps
Y2huLCBzdHJ1Y3QgZXZ0Y2huICpyY2huKQorc3RhdGljIGFsd2F5c19pbmxp
bmUgdm9pZCBkb3VibGVfZXZ0Y2huX2xvY2soc3RydWN0IGV2dGNobiAqbGNo
biwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIHN0cnVjdCBldnRjaG4gKnJjaG4pCiB7CiAgICAgQVNTRVJUKGxjaG4g
IT0gcmNobik7CiAKZGlmZiAtLWdpdCBhL3hlbi9jb21tb24vZ3JhbnRfdGFi
bGUuYyBiL3hlbi9jb21tb24vZ3JhbnRfdGFibGUuYwppbmRleCA3NjI3MmIz
YzhhZGQuLjk0NjRjZWJkZDZlNCAxMDA2NDQKLS0tIGEveGVuL2NvbW1vbi9n
cmFudF90YWJsZS5jCisrKyBiL3hlbi9jb21tb24vZ3JhbnRfdGFibGUuYwpA
QCAtMzk4LDcgKzM5OCw3IEBAIHN0YXRpYyBpbmxpbmUgdm9pZCBhY3Rfc2V0
X2dmbihzdHJ1Y3QgYWN0aXZlX2dyYW50X2VudHJ5ICphY3QsIGdmbl90IGdm
bikKIAogc3RhdGljIERFRklORV9QRVJDUFVfUldMT0NLX0dMT0JBTChncmFu
dF9yd2xvY2spOwogCi1zdGF0aWMgaW5saW5lIHZvaWQgZ3JhbnRfcmVhZF9s
b2NrKHN0cnVjdCBncmFudF90YWJsZSAqZ3QpCitzdGF0aWMgYWx3YXlzX2lu
bGluZSB2b2lkIGdyYW50X3JlYWRfbG9jayhzdHJ1Y3QgZ3JhbnRfdGFibGUg
Kmd0KQogewogICAgIHBlcmNwdV9yZWFkX2xvY2soZ3JhbnRfcndsb2NrLCAm
Z3QtPmxvY2spOwogfQpAQCAtNDA4LDcgKzQwOCw3IEBAIHN0YXRpYyBpbmxp
bmUgdm9pZCBncmFudF9yZWFkX3VubG9jayhzdHJ1Y3QgZ3JhbnRfdGFibGUg
Kmd0KQogICAgIHBlcmNwdV9yZWFkX3VubG9jayhncmFudF9yd2xvY2ssICZn
dC0+bG9jayk7CiB9CiAKLXN0YXRpYyBpbmxpbmUgdm9pZCBncmFudF93cml0
ZV9sb2NrKHN0cnVjdCBncmFudF90YWJsZSAqZ3QpCitzdGF0aWMgYWx3YXlz
X2lubGluZSB2b2lkIGdyYW50X3dyaXRlX2xvY2soc3RydWN0IGdyYW50X3Rh
YmxlICpndCkKIHsKICAgICBwZXJjcHVfd3JpdGVfbG9jayhncmFudF9yd2xv
Y2ssICZndC0+bG9jayk7CiB9CkBAIC00NDUsNyArNDQ1LDcgQEAgbnJfYWN0
aXZlX2dyYW50X2ZyYW1lcyhzdHJ1Y3QgZ3JhbnRfdGFibGUgKmd0KQogICAg
IHJldHVybiBudW1fYWN0X2ZyYW1lc19mcm9tX3NoYV9mcmFtZXMobnJfZ3Jh
bnRfZnJhbWVzKGd0KSk7CiB9CiAKLXN0YXRpYyBpbmxpbmUgc3RydWN0IGFj
dGl2ZV9ncmFudF9lbnRyeSAqCitzdGF0aWMgYWx3YXlzX2lubGluZSBzdHJ1
Y3QgYWN0aXZlX2dyYW50X2VudHJ5ICoKIGFjdGl2ZV9lbnRyeV9hY3F1aXJl
KHN0cnVjdCBncmFudF90YWJsZSAqdCwgZ3JhbnRfcmVmX3QgZSkKIHsKICAg
ICBzdHJ1Y3QgYWN0aXZlX2dyYW50X2VudHJ5ICphY3Q7CmRpZmYgLS1naXQg
YS94ZW4vY29tbW9uL3NjaGVkL2NvcmUuYyBiL3hlbi9jb21tb24vc2NoZWQv
Y29yZS5jCmluZGV4IDAzYWNlNDE1NDBkNi4uOWU4MGFkNGM3NDYzIDEwMDY0
NAotLS0gYS94ZW4vY29tbW9uL3NjaGVkL2NvcmUuYworKysgYi94ZW4vY29t
bW9uL3NjaGVkL2NvcmUuYwpAQCAtMzQ4LDIzICszNDgsMjggQEAgdWludDY0
X3QgZ2V0X2NwdV9pZGxlX3RpbWUodW5zaWduZWQgaW50IGNwdSkKICAqIFRo
aXMgYXZvaWRzIGRlYWQtIG9yIGxpdmUtbG9ja3Mgd2hlbiB0aGlzIGNvZGUg
aXMgcnVubmluZyBvbiBib3RoCiAgKiBjcHVzIGF0IHRoZSBzYW1lIHRpbWUu
CiAgKi8KLXN0YXRpYyB2b2lkIHNjaGVkX3NwaW5fbG9ja19kb3VibGUoc3Bp
bmxvY2tfdCAqbG9jazEsIHNwaW5sb2NrX3QgKmxvY2syLAotICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICB1bnNpZ25lZCBsb25nICpmbGFn
cykKK3N0YXRpYyBhbHdheXNfaW5saW5lIHZvaWQgc2NoZWRfc3Bpbl9sb2Nr
X2RvdWJsZSgKKyAgICBzcGlubG9ja190ICpsb2NrMSwgc3BpbmxvY2tfdCAq
bG9jazIsIHVuc2lnbmVkIGxvbmcgKmZsYWdzKQogeworICAgIC8qCisgICAg
ICogSW4gb3JkZXIgdG8gYXZvaWQgZXh0cmEgb3ZlcmhlYWQsIHVzZSB0aGUg
bG9ja2luZyBwcmltaXRpdmVzIHdpdGhvdXQgdGhlCisgICAgICogc3BlY3Vs
YXRpb24gYmFycmllciwgYW5kIGludHJvZHVjZSBhIHNpbmdsZSBiYXJyaWVy
IGhlcmUuCisgICAgICovCiAgICAgaWYgKCBsb2NrMSA9PSBsb2NrMiApCiAg
ICAgewotICAgICAgICBzcGluX2xvY2tfaXJxc2F2ZShsb2NrMSwgKmZsYWdz
KTsKKyAgICAgICAgKmZsYWdzID0gX3NwaW5fbG9ja19pcnFzYXZlKGxvY2sx
KTsKICAgICB9CiAgICAgZWxzZSBpZiAoIGxvY2sxIDwgbG9jazIgKQogICAg
IHsKLSAgICAgICAgc3Bpbl9sb2NrX2lycXNhdmUobG9jazEsICpmbGFncyk7
Ci0gICAgICAgIHNwaW5fbG9jayhsb2NrMik7CisgICAgICAgICpmbGFncyA9
IF9zcGluX2xvY2tfaXJxc2F2ZShsb2NrMSk7CisgICAgICAgIF9zcGluX2xv
Y2sobG9jazIpOwogICAgIH0KICAgICBlbHNlCiAgICAgewotICAgICAgICBz
cGluX2xvY2tfaXJxc2F2ZShsb2NrMiwgKmZsYWdzKTsKLSAgICAgICAgc3Bp
bl9sb2NrKGxvY2sxKTsKKyAgICAgICAgKmZsYWdzID0gX3NwaW5fbG9ja19p
cnFzYXZlKGxvY2syKTsKKyAgICAgICAgX3NwaW5fbG9jayhsb2NrMSk7CiAg
ICAgfQorICAgIGJsb2NrX2xvY2tfc3BlY3VsYXRpb24oKTsKIH0KIAogc3Rh
dGljIHZvaWQgc2NoZWRfc3Bpbl91bmxvY2tfZG91YmxlKHNwaW5sb2NrX3Qg
KmxvY2sxLCBzcGlubG9ja190ICpsb2NrMiwKZGlmZiAtLWdpdCBhL3hlbi9j
b21tb24vc2NoZWQvcHJpdmF0ZS5oIGIveGVuL2NvbW1vbi9zY2hlZC9wcml2
YXRlLmgKaW5kZXggMDUyN2E4YzcwZDFjLi4yNGE5M2RkMGMxMjMgMTAwNjQ0
Ci0tLSBhL3hlbi9jb21tb24vc2NoZWQvcHJpdmF0ZS5oCisrKyBiL3hlbi9j
b21tb24vc2NoZWQvcHJpdmF0ZS5oCkBAIC0yMDcsOCArMjA3LDI0IEBAIERF
Q0xBUkVfUEVSX0NQVShjcHVtYXNrX3QsIGNwdW1hc2tfc2NyYXRjaCk7CiAj
ZGVmaW5lIGNwdW1hc2tfc2NyYXRjaCAgICAgICAgKCZ0aGlzX2NwdShjcHVt
YXNrX3NjcmF0Y2gpKQogI2RlZmluZSBjcHVtYXNrX3NjcmF0Y2hfY3B1KGMp
ICgmcGVyX2NwdShjcHVtYXNrX3NjcmF0Y2gsIGMpKQogCisvKgorICogRGVh
bCB3aXRoIF9zcGluX2xvY2tfaXJxc2F2ZSgpIHJldHVybmluZyB0aGUgZmxh
Z3MgdmFsdWUgaW5zdGVhZCBvZiBzdG9yaW5nCisgKiBpdCBpbiBhIHBhc3Nl
ZCBwYXJhbWV0ZXIuCisgKi8KKyNkZWZpbmUgX3NjaGVkX3NwaW5sb2NrMChs
b2NrLCBpcnEpIF9zcGluX2xvY2sjI2lycShsb2NrKQorI2RlZmluZSBfc2No
ZWRfc3BpbmxvY2sxKGxvY2ssIGlycSwgYXJnKSAoeyBcCisgICAgQlVJTERf
QlVHX09OKHNpemVvZihhcmcpICE9IHNpemVvZih1bnNpZ25lZCBsb25nKSk7
IFwKKyAgICAoYXJnKSA9IF9zcGluX2xvY2sjI2lycShsb2NrKTsgXAorfSkK
KworI2RlZmluZSBfc2NoZWRfc3BpbmxvY2tfXyhucikgX3NjaGVkX3NwaW5s
b2NrICMjIG5yCisjZGVmaW5lIF9zY2hlZF9zcGlubG9ja18obnIpICBfc2No
ZWRfc3BpbmxvY2tfXyhucikKKyNkZWZpbmUgX3NjaGVkX3NwaW5sb2NrKGxv
Y2ssIGlycSwgYXJncy4uLikgXAorICAgIF9zY2hlZF9zcGlubG9ja18oY291
bnRfYXJncyhhcmdzKSkobG9jaywgaXJxLCAjIyBhcmdzKQorCiAjZGVmaW5l
IHNjaGVkX2xvY2soa2luZCwgcGFyYW0sIGNwdSwgaXJxLCBhcmcuLi4pIFwK
LXN0YXRpYyBpbmxpbmUgc3BpbmxvY2tfdCAqa2luZCMjX3NjaGVkdWxlX2xv
Y2sjI2lycShwYXJhbSBFWFRSQV9UWVBFKGFyZykpIFwKK3N0YXRpYyBhbHdh
eXNfaW5saW5lIHNwaW5sb2NrX3QgXAorKmtpbmQjI19zY2hlZHVsZV9sb2Nr
IyNpcnEocGFyYW0gRVhUUkFfVFlQRShhcmcpKSBcCiB7IFwKICAgICBmb3Ig
KCA7IDsgKSBcCiAgICAgeyBcCkBAIC0yMjAsMTAgKzIzNiwxNiBAQCBzdGF0
aWMgaW5saW5lIHNwaW5sb2NrX3QgKmtpbmQjI19zY2hlZHVsZV9sb2NrIyNp
cnEocGFyYW0gRVhUUkFfVFlQRShhcmcpKSBcCiAgICAgICAgICAqIFwKICAg
ICAgICAgICogSXQgbWF5IGFsc28gYmUgdGhlIGNhc2UgdGhhdCB2LT5wcm9j
ZXNzb3IgbWF5IGNoYW5nZSBidXQgdGhlIFwKICAgICAgICAgICogbG9jayBt
YXkgYmUgdGhlIHNhbWU7IHRoaXMgd2lsbCBzdWNjZWVkIGluIHRoYXQgY2Fz
ZS4gXAorICAgICAgICAgKiBcCisgICAgICAgICAqIFVzZSB0aGUgc3BlY3Vs
YXRpb24gdW5zYWZlIGxvY2tpbmcgaGVscGVyLCB0aGVyZSdzIGEgc3BlY3Vs
YXRpb24gXAorICAgICAgICAgKiBiYXJyaWVyIGJlZm9yZSByZXR1cm5pbmcg
dG8gdGhlIGNhbGxlci4gXAogICAgICAgICAgKi8gXAotICAgICAgICBzcGlu
X2xvY2sjI2lycShsb2NrLCAjIyBhcmcpOyBcCisgICAgICAgIF9zY2hlZF9z
cGlubG9jayhsb2NrLCBpcnEsICMjIGFyZyk7IFwKICAgICAgICAgaWYgKCBs
aWtlbHkobG9jayA9PSBnZXRfc2NoZWRfcmVzKGNwdSktPnNjaGVkdWxlX2xv
Y2spICkgXAorICAgICAgICB7IFwKKyAgICAgICAgICAgIGJsb2NrX2xvY2tf
c3BlY3VsYXRpb24oKTsgXAogICAgICAgICAgICAgcmV0dXJuIGxvY2s7IFwK
KyAgICAgICAgfSBcCiAgICAgICAgIHNwaW5fdW5sb2NrIyNpcnEobG9jaywg
IyMgYXJnKTsgXAogICAgIH0gXAogfQpkaWZmIC0tZ2l0IGEveGVuL2NvbW1v
bi90aW1lci5jIGIveGVuL2NvbW1vbi90aW1lci5jCmluZGV4IDFiYjI2NWNl
ZWEwZS4uZGM4MzFlZmM3OWU1IDEwMDY0NAotLS0gYS94ZW4vY29tbW9uL3Rp
bWVyLmMKKysrIGIveGVuL2NvbW1vbi90aW1lci5jCkBAIC0yNDAsNyArMjQw
LDcgQEAgc3RhdGljIGlubGluZSB2b2lkIGRlYWN0aXZhdGVfdGltZXIoc3Ry
dWN0IHRpbWVyICp0aW1lcikKICAgICBsaXN0X2FkZCgmdGltZXItPmluYWN0
aXZlLCAmcGVyX2NwdSh0aW1lcnMsIHRpbWVyLT5jcHUpLmluYWN0aXZlKTsK
IH0KIAotc3RhdGljIGlubGluZSBib29sX3QgdGltZXJfbG9jayhzdHJ1Y3Qg
dGltZXIgKnRpbWVyKQorc3RhdGljIGlubGluZSBib29sX3QgdGltZXJfbG9j
a191bnNhZmUoc3RydWN0IHRpbWVyICp0aW1lcikKIHsKICAgICB1bnNpZ25l
ZCBpbnQgY3B1OwogCkBAIC0yNTQsNyArMjU0LDggQEAgc3RhdGljIGlubGlu
ZSBib29sX3QgdGltZXJfbG9jayhzdHJ1Y3QgdGltZXIgKnRpbWVyKQogICAg
ICAgICAgICAgcmN1X3JlYWRfdW5sb2NrKCZ0aW1lcl9jcHVfcmVhZF9sb2Nr
KTsKICAgICAgICAgICAgIHJldHVybiAwOwogICAgICAgICB9Ci0gICAgICAg
IHNwaW5fbG9jaygmcGVyX2NwdSh0aW1lcnMsIGNwdSkubG9jayk7CisgICAg
ICAgIC8qIFVzZSB0aGUgc3BlY3VsYXRpb24gdW5zYWZlIHZhcmlhbnQsIHRo
ZSB3cmFwcGVyIGhhcyB0aGUgYmFycmllci4gKi8KKyAgICAgICAgX3NwaW5f
bG9jaygmcGVyX2NwdSh0aW1lcnMsIGNwdSkubG9jayk7CiAgICAgICAgIGlm
ICggbGlrZWx5KHRpbWVyLT5jcHUgPT0gY3B1KSApCiAgICAgICAgICAgICBi
cmVhazsKICAgICAgICAgc3Bpbl91bmxvY2soJnBlcl9jcHUodGltZXJzLCBj
cHUpLmxvY2spOwpAQCAtMjY3LDggKzI2OCw5IEBAIHN0YXRpYyBpbmxpbmUg
Ym9vbF90IHRpbWVyX2xvY2soc3RydWN0IHRpbWVyICp0aW1lcikKICNkZWZp
bmUgdGltZXJfbG9ja19pcnFzYXZlKHQsIGZsYWdzKSAoeyAgICAgICAgIFwK
ICAgICBib29sX3QgX194OyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIFwKICAgICBsb2NhbF9pcnFfc2F2ZShmbGFncyk7ICAgICAgICAgICAg
ICAgICAgICAgIFwKLSAgICBpZiAoICEoX194ID0gdGltZXJfbG9jayh0KSkg
KSAgICAgICAgICAgICAgIFwKKyAgICBpZiAoICEoX194ID0gdGltZXJfbG9j
a191bnNhZmUodCkpICkgICAgICAgIFwKICAgICAgICAgbG9jYWxfaXJxX3Jl
c3RvcmUoZmxhZ3MpOyAgICAgICAgICAgICAgIFwKKyAgICBibG9ja19sb2Nr
X3NwZWN1bGF0aW9uKCk7ICAgICAgICAgICAgICAgICAgIFwKICAgICBfX3g7
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKIH0p
CiAKZGlmZiAtLWdpdCBhL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL3BjaS5j
IGIveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvcGNpLmMKaW5kZXggNmZjMjdl
N2VkZTQwLi4yZmQ2NjMwNjJhZDUgMTAwNjQ0Ci0tLSBhL3hlbi9kcml2ZXJz
L3Bhc3N0aHJvdWdoL3BjaS5jCisrKyBiL3hlbi9kcml2ZXJzL3Bhc3N0aHJv
dWdoL3BjaS5jCkBAIC01Miw5ICs1MiwxMCBAQCBzdHJ1Y3QgcGNpX3NlZyB7
CiAKIHN0YXRpYyBzcGlubG9ja190IF9wY2lkZXZzX2xvY2sgPSBTUElOX0xP
Q0tfVU5MT0NLRUQ7CiAKLXZvaWQgcGNpZGV2c19sb2NrKHZvaWQpCisvKiBE
byBub3QgdXNlLCBhcyBpdCBoYXMgbm8gc3BlY3VsYXRpb24gYmFycmllciwg
dXNlIHBjaWRldnNfbG9jaygpIGluc3RlYWQuICovCit2b2lkIHBjaWRldnNf
bG9ja191bnNhZmUodm9pZCkKIHsKLSAgICBzcGluX2xvY2tfcmVjdXJzaXZl
KCZfcGNpZGV2c19sb2NrKTsKKyAgICBfc3Bpbl9sb2NrX3JlY3Vyc2l2ZSgm
X3BjaWRldnNfbG9jayk7CiB9CiAKIHZvaWQgcGNpZGV2c191bmxvY2sodm9p
ZCkKZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL2FzbS14ODYvaXJxLmggYi94
ZW4vaW5jbHVkZS9hc20teDg2L2lycS5oCmluZGV4IDdjODI1ZTlkOWMwYS4u
ZDRiMmJlZGE3OThkIDEwMDY0NAotLS0gYS94ZW4vaW5jbHVkZS9hc20teDg2
L2lycS5oCisrKyBiL3hlbi9pbmNsdWRlL2FzbS14ODYvaXJxLmgKQEAgLTE3
Nyw2ICsxNzcsNyBAQCBleHRlcm4gdm9pZCBpcnFfY29tcGxldGVfbW92ZShz
dHJ1Y3QgaXJxX2Rlc2MgKik7CiAKIGV4dGVybiBzdHJ1Y3QgaXJxX2Rlc2Mg
KmlycV9kZXNjOwogCisvKiBOb3Qgc3BlY3VsYXRpb24gc2FmZSwgb25seSB1
c2VkIGZvciBBUCBicmluZ3VwLiAqLwogdm9pZCBsb2NrX3ZlY3Rvcl9sb2Nr
KHZvaWQpOwogdm9pZCB1bmxvY2tfdmVjdG9yX2xvY2sodm9pZCk7CiAKZGlm
ZiAtLWdpdCBhL3hlbi9pbmNsdWRlL3hlbi9ldmVudC5oIGIveGVuL2luY2x1
ZGUveGVuL2V2ZW50LmgKaW5kZXggMjFjOTVlMTRmZDZhLi4xODkyNGU2OWU3
ZDAgMTAwNjQ0Ci0tLSBhL3hlbi9pbmNsdWRlL3hlbi9ldmVudC5oCisrKyBi
L3hlbi9pbmNsdWRlL3hlbi9ldmVudC5oCkBAIC0xMDUsMTIgKzEwNSwxMiBA
QCB2b2lkIG5vdGlmeV92aWFfeGVuX2V2ZW50X2NoYW5uZWwoc3RydWN0IGRv
bWFpbiAqbGQsIGludCBscG9ydCk7CiAjZGVmaW5lIGJ1Y2tldF9mcm9tX3Bv
cnQoZCwgcCkgXAogICAgICgoZ3JvdXBfZnJvbV9wb3J0KGQsIHApKVsoKHAp
ICUgRVZUQ0hOU19QRVJfR1JPVVApIC8gRVZUQ0hOU19QRVJfQlVDS0VUXSkK
IAotc3RhdGljIGlubGluZSB2b2lkIGV2dGNobl9yZWFkX2xvY2soc3RydWN0
IGV2dGNobiAqZXZ0Y2huKQorc3RhdGljIGFsd2F5c19pbmxpbmUgdm9pZCBl
dnRjaG5fcmVhZF9sb2NrKHN0cnVjdCBldnRjaG4gKmV2dGNobikKIHsKICAg
ICByZWFkX2xvY2soJmV2dGNobi0+bG9jayk7CiB9CiAKLXN0YXRpYyBpbmxp
bmUgYm9vbCBldnRjaG5fcmVhZF90cnlsb2NrKHN0cnVjdCBldnRjaG4gKmV2
dGNobikKK3N0YXRpYyBhbHdheXNfaW5saW5lIGJvb2wgZXZ0Y2huX3JlYWRf
dHJ5bG9jayhzdHJ1Y3QgZXZ0Y2huICpldnRjaG4pCiB7CiAgICAgcmV0dXJu
IHJlYWRfdHJ5bG9jaygmZXZ0Y2huLT5sb2NrKTsKIH0KZGlmZiAtLWdpdCBh
L3hlbi9pbmNsdWRlL3hlbi9wY2kuaCBiL3hlbi9pbmNsdWRlL3hlbi9wY2ku
aAppbmRleCBhYzM4ODBlNjg2ZjguLjNmMTMyNGU1ZGU5MiAxMDA2NDQKLS0t
IGEveGVuL2luY2x1ZGUveGVuL3BjaS5oCisrKyBiL3hlbi9pbmNsdWRlL3hl
bi9wY2kuaApAQCAtMTQ3LDggKzE0NywxMiBAQCBzdHJ1Y3QgcGNpX2RldiB7
CiAgKiBkZXZpY2VzLCBpdCBhbHNvIHN5bmMgdGhlIGFjY2VzcyB0byB0aGUg
bXNpIGNhcGFiaWxpdHkgdGhhdCBpcyBub3QKICAqIGludGVycnVwdCBoYW5k
bGluZyByZWxhdGVkICh0aGUgbWFzayBiaXQgcmVnaXN0ZXIpLgogICovCi0K
LXZvaWQgcGNpZGV2c19sb2NrKHZvaWQpOwordm9pZCBwY2lkZXZzX2xvY2tf
dW5zYWZlKHZvaWQpOworc3RhdGljIGFsd2F5c19pbmxpbmUgdm9pZCBwY2lk
ZXZzX2xvY2sodm9pZCkKK3sKKyAgICBwY2lkZXZzX2xvY2tfdW5zYWZlKCk7
CisgICAgYmxvY2tfbG9ja19zcGVjdWxhdGlvbigpOworfQogdm9pZCBwY2lk
ZXZzX3VubG9jayh2b2lkKTsKIGJvb2xfdCBfX211c3RfY2hlY2sgcGNpZGV2
c19sb2NrZWQodm9pZCk7CiAK

--=separator
Content-Type: application/octet-stream; name="xsa453/xsa453-4.16-7.patch"
Content-Disposition: attachment; filename="xsa453/xsa453-4.16-7.patch"
Content-Transfer-Encoding: base64

RnJvbTogPT9VVEYtOD9xP1JvZ2VyPTIwUGF1PTIwTW9ubj1DMz1BOT89IDxy
b2dlci5wYXVAY2l0cml4LmNvbT4KU3ViamVjdDogeDg2L21tOiBhZGQgc3Bl
Y3VsYXRpb24gYmFycmllcnMgdG8gb3BlbiBjb2RlZCBsb2NrcwoKQWRkIGEg
c3BlY3VsYXRpb24gYmFycmllciB0byB0aGUgY2xlYXJseSBpZGVudGlmaWVk
IG9wZW4tY29kZWQgbG9jayB0YWtpbmcKZnVuY3Rpb25zLgoKTm90ZSB0aGF0
IHRoZSBtZW1vcnkgc2hhcmluZyBwYWdlX2xvY2soKSByZXBsYWNlbWVudCAo
X3BhZ2VfbG9jaygpKSBpcyBsZWZ0CmFzLWlzLCBhcyB0aGUgY29kZSBpcyBl
eHBlcmltZW50YWwgYW5kIG5vdCBzZWN1cml0eSBzdXBwb3J0ZWQuCgpUaGlz
IGlzIHBhcnQgb2YgWFNBLTQ1MyAvIENWRS0yMDI0LTIxOTMKClNpZ25lZC1v
ZmYtYnk6IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXguY29t
PgpSZXZpZXdlZC1ieTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29t
PgooY2hlcnJ5IHBpY2tlZCBmcm9tIGNvbW1pdCA0MmE1NzJhMzhlMjJhOTdk
ODZhNGI2NDhhMjI1OTc2MjhkNWI0MmU0KQoKZGlmZiAtLWdpdCBhL3hlbi9h
cmNoL3g4Ni9tbS5jIGIveGVuL2FyY2gveDg2L21tLmMKaW5kZXggZWEwMjRj
MTQ1MDM0Li4yYmYxYjcwOTg1MWEgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4
Ni9tbS5jCisrKyBiL3hlbi9hcmNoL3g4Ni9tbS5jCkBAIC0yMDA1LDcgKzIw
MDUsNyBAQCBzdGF0aWMgaW5saW5lIGJvb2wgY3VycmVudF9sb2NrZWRfcGFn
ZV9uZV9jaGVjayhzdHJ1Y3QgcGFnZV9pbmZvICpwYWdlKSB7CiAjZGVmaW5l
IGN1cnJlbnRfbG9ja2VkX3BhZ2VfbmVfY2hlY2soeCkgdHJ1ZQogI2VuZGlm
CiAKLWludCBwYWdlX2xvY2soc3RydWN0IHBhZ2VfaW5mbyAqcGFnZSkKK2lu
dCBwYWdlX2xvY2tfdW5zYWZlKHN0cnVjdCBwYWdlX2luZm8gKnBhZ2UpCiB7
CiAgICAgdW5zaWduZWQgbG9uZyB4LCBueDsKIApAQCAtMjA2Niw3ICsyMDY2
LDcgQEAgdm9pZCBwYWdlX3VubG9jayhzdHJ1Y3QgcGFnZV9pbmZvICpwYWdl
KQogICogbDN0X2xvY2soKSwgc28gdG8gYXZvaWQgZGVhZGxvY2sgd2UgbXVz
dCBhdm9pZCBncmFiYmluZyB0aGVtIGluCiAgKiByZXZlcnNlIG9yZGVyLgog
ICovCi1zdGF0aWMgdm9pZCBsM3RfbG9jayhzdHJ1Y3QgcGFnZV9pbmZvICpw
YWdlKQorc3RhdGljIGFsd2F5c19pbmxpbmUgdm9pZCBsM3RfbG9jayhzdHJ1
Y3QgcGFnZV9pbmZvICpwYWdlKQogewogICAgIHVuc2lnbmVkIGxvbmcgeCwg
bng7CiAKQEAgLTIwNzUsNiArMjA3NSw4IEBAIHN0YXRpYyB2b2lkIGwzdF9s
b2NrKHN0cnVjdCBwYWdlX2luZm8gKnBhZ2UpCiAgICAgICAgICAgICBjcHVf
cmVsYXgoKTsKICAgICAgICAgbnggPSB4IHwgUEdUX2xvY2tlZDsKICAgICB9
IHdoaWxlICggY21weGNoZygmcGFnZS0+dS5pbnVzZS50eXBlX2luZm8sIHgs
IG54KSAhPSB4ICk7CisKKyAgICBibG9ja19sb2NrX3NwZWN1bGF0aW9uKCk7
CiB9CiAKIHN0YXRpYyB2b2lkIGwzdF91bmxvY2soc3RydWN0IHBhZ2VfaW5m
byAqcGFnZSkKZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL2FzbS14ODYvbW0u
aCBiL3hlbi9pbmNsdWRlL2FzbS14ODYvbW0uaAppbmRleCBjY2NlZjg1MmI0
ZGUuLjczZDVhOThiZWM3ZSAxMDA2NDQKLS0tIGEveGVuL2luY2x1ZGUvYXNt
LXg4Ni9tbS5oCisrKyBiL3hlbi9pbmNsdWRlL2FzbS14ODYvbW0uaApAQCAt
MzkzLDcgKzM5Myw5IEBAIGNvbnN0IHN0cnVjdCBwbGF0Zm9ybV9iYWRfcGFn
ZSAqZ2V0X3BsYXRmb3JtX2JhZHBhZ2VzKHVuc2lnbmVkIGludCAqYXJyYXlf
c2l6ZSk7CiAgKiBUaGUgdXNlIG9mIFBHVF9sb2NrZWQgaW4gbWVtX3NoYXJp
bmcgZG9lcyBub3QgY29sbGlkZSwgc2luY2UgbWVtX3NoYXJpbmcgaXMKICAq
IG9ubHkgc3VwcG9ydGVkIGZvciBodm0gZ3Vlc3RzLCB3aGljaCBkbyBub3Qg
aGF2ZSBQViBQVEVzIHVwZGF0ZWQuCiAgKi8KLWludCBwYWdlX2xvY2soc3Ry
dWN0IHBhZ2VfaW5mbyAqcGFnZSk7CitpbnQgcGFnZV9sb2NrX3Vuc2FmZShz
dHJ1Y3QgcGFnZV9pbmZvICpwYWdlKTsKKyNkZWZpbmUgcGFnZV9sb2NrKHBn
KSAgIGxvY2tfZXZhbHVhdGVfbm9zcGVjKHBhZ2VfbG9ja191bnNhZmUocGcp
KQorCiB2b2lkIHBhZ2VfdW5sb2NrKHN0cnVjdCBwYWdlX2luZm8gKnBhZ2Up
OwogCiB2b2lkIHB1dF9wYWdlX3R5cGUoc3RydWN0IHBhZ2VfaW5mbyAqcGFn
ZSk7Cg==

--=separator
Content-Type: application/octet-stream; name="xsa453/xsa453-4.16-8.patch"
Content-Disposition: attachment; filename="xsa453/xsa453-4.16-8.patch"
Content-Transfer-Encoding: base64

RnJvbTogPT9VVEYtOD9xP1JvZ2VyPTIwUGF1PTIwTW9ubj1DMz1BOT89IDxy
b2dlci5wYXVAY2l0cml4LmNvbT4KU3ViamVjdDogeDg2OiBwcm90ZWN0IGNv
bmRpdGlvbmFsIGxvY2sgdGFraW5nIGZyb20gc3BlY3VsYXRpdmUgZXhlY3V0
aW9uCgpDb25kaXRpb25hbGx5IHRha2VuIGxvY2tzIHRoYXQgdXNlIHRoZSBw
YXR0ZXJuOgoKaWYgKCBsb2NrICkKICAgIHNwaW5fbG9jayguLi4pOwoKTmVl
ZCBhbiBlbHNlIGJyYW5jaCBpbiBvcmRlciB0byBpc3N1ZSBhbiBzcGVjdWxh
dGlvbiBiYXJyaWVyIGluIHRoZSBlbHNlIGNhc2UsCmp1c3QgbGlrZSBpdCdz
IGRvbmUgaW4gY2FzZSB0aGUgbG9jayBuZWVkcyB0byBiZSBhY3F1aXJlZC4K
CmV2YWxfbm9zcGVjKCkgY291bGQgYmUgdXNlZCBvbiB0aGUgY29uZGl0aW9u
IGl0c2VsZiwgYnV0IHRoYXQgd291bGQgcmVzdWx0IGluIGEKZG91YmxlIGJh
cnJpZXIgb24gdGhlIGJyYW5jaCB3aGVyZSB0aGUgbG9jayBpcyB0YWtlbi4K
CkludHJvZHVjZSBhIG5ldyBwYWlyIG9mIGhlbHBlcnMsIHtnZm4sc3Bpbn1f
bG9ja19pZigpIHRoYXQgY2FuIGJlIHVzZWQgdG8KY29uZGl0aW9uYWxseSB0
YWtlIGEgbG9jayBpbiBhIHNwZWN1bGF0aW9uIHNhZmUgd2F5LgoKVGhpcyBp
cyBwYXJ0IG9mIFhTQS00NTMgLyBDVkUtMjAyNC0yMTkzCgpTaWduZWQtb2Zm
LWJ5OiBSb2dlciBQYXUgTW9ubsOpIDxyb2dlci5wYXVAY2l0cml4LmNvbT4K
UmV2aWV3ZWQtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4K
KGNoZXJyeSBwaWNrZWQgZnJvbSBjb21taXQgMDNjZjdjYTIzZTBlODc2MDc1
OTU0YzU1ODQ4NWIyNjdiN2QwMjQwNikKCmRpZmYgLS1naXQgYS94ZW4vYXJj
aC94ODYvbW0uYyBiL3hlbi9hcmNoL3g4Ni9tbS5jCmluZGV4IDJiZjFiNzA5
ODUxYS4uMTYyODdlNjJhZjIzIDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYv
bW0uYworKysgYi94ZW4vYXJjaC94ODYvbW0uYwpAQCAtNTAwMCw4ICs1MDAw
LDcgQEAgc3RhdGljIGwzX3BnZW50cnlfdCAqdmlydF90b194ZW5fbDNlKHVu
c2lnbmVkIGxvbmcgdikKICAgICAgICAgaWYgKCAhbDN0ICkKICAgICAgICAg
ICAgIHJldHVybiBOVUxMOwogICAgICAgICBVTk1BUF9ET01BSU5fUEFHRShs
M3QpOwotICAgICAgICBpZiAoIGxvY2tpbmcgKQotICAgICAgICAgICAgc3Bp
bl9sb2NrKCZtYXBfcGdkaXJfbG9jayk7CisgICAgICAgIHNwaW5fbG9ja19p
Zihsb2NraW5nLCAmbWFwX3BnZGlyX2xvY2spOwogICAgICAgICBpZiAoICEo
bDRlX2dldF9mbGFncygqcGw0ZSkgJiBfUEFHRV9QUkVTRU5UKSApCiAgICAg
ICAgIHsKICAgICAgICAgICAgIGw0X3BnZW50cnlfdCBsNGUgPSBsNGVfZnJv
bV9tZm4obDNtZm4sIF9fUEFHRV9IWVBFUlZJU09SKTsKQEAgLTUwMzgsOCAr
NTAzNyw3IEBAIHN0YXRpYyBsMl9wZ2VudHJ5X3QgKnZpcnRfdG9feGVuX2wy
ZSh1bnNpZ25lZCBsb25nIHYpCiAgICAgICAgICAgICByZXR1cm4gTlVMTDsK
ICAgICAgICAgfQogICAgICAgICBVTk1BUF9ET01BSU5fUEFHRShsMnQpOwot
ICAgICAgICBpZiAoIGxvY2tpbmcgKQotICAgICAgICAgICAgc3Bpbl9sb2Nr
KCZtYXBfcGdkaXJfbG9jayk7CisgICAgICAgIHNwaW5fbG9ja19pZihsb2Nr
aW5nLCAmbWFwX3BnZGlyX2xvY2spOwogICAgICAgICBpZiAoICEobDNlX2dl
dF9mbGFncygqcGwzZSkgJiBfUEFHRV9QUkVTRU5UKSApCiAgICAgICAgIHsK
ICAgICAgICAgICAgIGwzZV93cml0ZShwbDNlLCBsM2VfZnJvbV9tZm4obDJt
Zm4sIF9fUEFHRV9IWVBFUlZJU09SKSk7CkBAIC01MDc3LDggKzUwNzUsNyBA
QCBsMV9wZ2VudHJ5X3QgKnZpcnRfdG9feGVuX2wxZSh1bnNpZ25lZCBsb25n
IHYpCiAgICAgICAgICAgICByZXR1cm4gTlVMTDsKICAgICAgICAgfQogICAg
ICAgICBVTk1BUF9ET01BSU5fUEFHRShsMXQpOwotICAgICAgICBpZiAoIGxv
Y2tpbmcgKQotICAgICAgICAgICAgc3Bpbl9sb2NrKCZtYXBfcGdkaXJfbG9j
ayk7CisgICAgICAgIHNwaW5fbG9ja19pZihsb2NraW5nLCAmbWFwX3BnZGly
X2xvY2spOwogICAgICAgICBpZiAoICEobDJlX2dldF9mbGFncygqcGwyZSkg
JiBfUEFHRV9QUkVTRU5UKSApCiAgICAgICAgIHsKICAgICAgICAgICAgIGwy
ZV93cml0ZShwbDJlLCBsMmVfZnJvbV9tZm4obDFtZm4sIF9fUEFHRV9IWVBF
UlZJU09SKSk7CkBAIC01MTA5LDYgKzUxMDYsOCBAQCBsMV9wZ2VudHJ5X3Qg
KnZpcnRfdG9feGVuX2wxZSh1bnNpZ25lZCBsb25nIHYpCiAgICAgZG8geyAg
ICAgICAgICAgICAgICAgICAgICBcCiAgICAgICAgIGlmICggbG9ja2luZyAp
ICAgICAgICBcCiAgICAgICAgICAgICBsM3RfbG9jayhwYWdlKTsgICBcCisg
ICAgICAgIGVsc2UgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAorICAg
ICAgICAgICAgYmxvY2tfbG9ja19zcGVjdWxhdGlvbigpOyAgIFwKICAgICB9
IHdoaWxlICggZmFsc2UgKQogCiAjZGVmaW5lIEwzVF9VTkxPQ0socGFnZSkg
ICAgICAgICAgICAgICAgICAgICAgICAgICBcCkBAIC01MzI0LDggKzUzMjMs
NyBAQCBpbnQgbWFwX3BhZ2VzX3RvX3hlbigKICAgICAgICAgICAgIGlmICgg
bDNlX2dldF9mbGFncyhvbDNlKSAmIF9QQUdFX0dMT0JBTCApCiAgICAgICAg
ICAgICAgICAgZmx1c2hfZmxhZ3MgfD0gRkxVU0hfVExCX0dMT0JBTDsKIAot
ICAgICAgICAgICAgaWYgKCBsb2NraW5nICkKLSAgICAgICAgICAgICAgICBz
cGluX2xvY2soJm1hcF9wZ2Rpcl9sb2NrKTsKKyAgICAgICAgICAgIHNwaW5f
bG9ja19pZihsb2NraW5nLCAmbWFwX3BnZGlyX2xvY2spOwogICAgICAgICAg
ICAgaWYgKCAobDNlX2dldF9mbGFncygqcGwzZSkgJiBfUEFHRV9QUkVTRU5U
KSAmJgogICAgICAgICAgICAgICAgICAobDNlX2dldF9mbGFncygqcGwzZSkg
JiBfUEFHRV9QU0UpICkKICAgICAgICAgICAgIHsKQEAgLTU0MjksOCArNTQy
Nyw3IEBAIGludCBtYXBfcGFnZXNfdG9feGVuKAogICAgICAgICAgICAgICAg
IGlmICggbDJlX2dldF9mbGFncygqcGwyZSkgJiBfUEFHRV9HTE9CQUwgKQog
ICAgICAgICAgICAgICAgICAgICBmbHVzaF9mbGFncyB8PSBGTFVTSF9UTEJf
R0xPQkFMOwogCi0gICAgICAgICAgICAgICAgaWYgKCBsb2NraW5nICkKLSAg
ICAgICAgICAgICAgICAgICAgc3Bpbl9sb2NrKCZtYXBfcGdkaXJfbG9jayk7
CisgICAgICAgICAgICAgICAgc3Bpbl9sb2NrX2lmKGxvY2tpbmcsICZtYXBf
cGdkaXJfbG9jayk7CiAgICAgICAgICAgICAgICAgaWYgKCAobDJlX2dldF9m
bGFncygqcGwyZSkgJiBfUEFHRV9QUkVTRU5UKSAmJgogICAgICAgICAgICAg
ICAgICAgICAgKGwyZV9nZXRfZmxhZ3MoKnBsMmUpICYgX1BBR0VfUFNFKSAp
CiAgICAgICAgICAgICAgICAgewpAQCAtNTQ3MSw4ICs1NDY4LDcgQEAgaW50
IG1hcF9wYWdlc190b194ZW4oCiAgICAgICAgICAgICAgICAgdW5zaWduZWQg
bG9uZyBiYXNlX21mbjsKICAgICAgICAgICAgICAgICBjb25zdCBsMV9wZ2Vu
dHJ5X3QgKmwxdDsKIAotICAgICAgICAgICAgICAgIGlmICggbG9ja2luZyAp
Ci0gICAgICAgICAgICAgICAgICAgIHNwaW5fbG9jaygmbWFwX3BnZGlyX2xv
Y2spOworICAgICAgICAgICAgICAgIHNwaW5fbG9ja19pZihsb2NraW5nLCAm
bWFwX3BnZGlyX2xvY2spOwogCiAgICAgICAgICAgICAgICAgb2wyZSA9ICpw
bDJlOwogICAgICAgICAgICAgICAgIC8qCkBAIC01NTI2LDggKzU1MjIsNyBA
QCBpbnQgbWFwX3BhZ2VzX3RvX3hlbigKICAgICAgICAgICAgIHVuc2lnbmVk
IGxvbmcgYmFzZV9tZm47CiAgICAgICAgICAgICBjb25zdCBsMl9wZ2VudHJ5
X3QgKmwydDsKIAotICAgICAgICAgICAgaWYgKCBsb2NraW5nICkKLSAgICAg
ICAgICAgICAgICBzcGluX2xvY2soJm1hcF9wZ2Rpcl9sb2NrKTsKKyAgICAg
ICAgICAgIHNwaW5fbG9ja19pZihsb2NraW5nLCAmbWFwX3BnZGlyX2xvY2sp
OwogCiAgICAgICAgICAgICBvbDNlID0gKnBsM2U7CiAgICAgICAgICAgICAv
KgpAQCAtNTY3MSw4ICs1NjY2LDcgQEAgaW50IG1vZGlmeV94ZW5fbWFwcGlu
Z3ModW5zaWduZWQgbG9uZyBzLCB1bnNpZ25lZCBsb25nIGUsIHVuc2lnbmVk
IGludCBuZikKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIGwzZV9nZXRfZmxhZ3MoKnBsM2UpKSk7CiAgICAgICAgICAgICBVTk1B
UF9ET01BSU5fUEFHRShsMnQpOwogCi0gICAgICAgICAgICBpZiAoIGxvY2tp
bmcgKQotICAgICAgICAgICAgICAgIHNwaW5fbG9jaygmbWFwX3BnZGlyX2xv
Y2spOworICAgICAgICAgICAgc3Bpbl9sb2NrX2lmKGxvY2tpbmcsICZtYXBf
cGdkaXJfbG9jayk7CiAgICAgICAgICAgICBpZiAoIChsM2VfZ2V0X2ZsYWdz
KCpwbDNlKSAmIF9QQUdFX1BSRVNFTlQpICYmCiAgICAgICAgICAgICAgICAg
IChsM2VfZ2V0X2ZsYWdzKCpwbDNlKSAmIF9QQUdFX1BTRSkgKQogICAgICAg
ICAgICAgewpAQCAtNTczMSw4ICs1NzI1LDcgQEAgaW50IG1vZGlmeV94ZW5f
bWFwcGluZ3ModW5zaWduZWQgbG9uZyBzLCB1bnNpZ25lZCBsb25nIGUsIHVu
c2lnbmVkIGludCBuZikKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBsMmVfZ2V0X2ZsYWdzKCpwbDJlKSAmIH5fUEFHRV9Q
U0UpKTsKICAgICAgICAgICAgICAgICBVTk1BUF9ET01BSU5fUEFHRShsMXQp
OwogCi0gICAgICAgICAgICAgICAgaWYgKCBsb2NraW5nICkKLSAgICAgICAg
ICAgICAgICAgICAgc3Bpbl9sb2NrKCZtYXBfcGdkaXJfbG9jayk7CisgICAg
ICAgICAgICAgICAgc3Bpbl9sb2NrX2lmKGxvY2tpbmcsICZtYXBfcGdkaXJf
bG9jayk7CiAgICAgICAgICAgICAgICAgaWYgKCAobDJlX2dldF9mbGFncygq
cGwyZSkgJiBfUEFHRV9QUkVTRU5UKSAmJgogICAgICAgICAgICAgICAgICAg
ICAgKGwyZV9nZXRfZmxhZ3MoKnBsMmUpICYgX1BBR0VfUFNFKSApCiAgICAg
ICAgICAgICAgICAgewpAQCAtNTc3Niw4ICs1NzY5LDcgQEAgaW50IG1vZGlm
eV94ZW5fbWFwcGluZ3ModW5zaWduZWQgbG9uZyBzLCB1bnNpZ25lZCBsb25n
IGUsIHVuc2lnbmVkIGludCBuZikKICAgICAgICAgICAgICAqLwogICAgICAg
ICAgICAgaWYgKCAobmYgJiBfUEFHRV9QUkVTRU5UKSB8fCAoKHYgIT0gZSkg
JiYgKGwxX3RhYmxlX29mZnNldCh2KSAhPSAwKSkgKQogICAgICAgICAgICAg
ICAgIGNvbnRpbnVlOwotICAgICAgICAgICAgaWYgKCBsb2NraW5nICkKLSAg
ICAgICAgICAgICAgICBzcGluX2xvY2soJm1hcF9wZ2Rpcl9sb2NrKTsKKyAg
ICAgICAgICAgIHNwaW5fbG9ja19pZihsb2NraW5nLCAmbWFwX3BnZGlyX2xv
Y2spOwogCiAgICAgICAgICAgICAvKgogICAgICAgICAgICAgICogTDJFIG1h
eSBiZSBhbHJlYWR5IGNsZWFyZWQsIG9yIHNldCB0byBhIHN1cGVycGFnZSwg
YnkKQEAgLTU4MjQsOCArNTgxNiw3IEBAIGludCBtb2RpZnlfeGVuX21hcHBp
bmdzKHVuc2lnbmVkIGxvbmcgcywgdW5zaWduZWQgbG9uZyBlLCB1bnNpZ25l
ZCBpbnQgbmYpCiAgICAgICAgIGlmICggKG5mICYgX1BBR0VfUFJFU0VOVCkg
fHwKICAgICAgICAgICAgICAoKHYgIT0gZSkgJiYgKGwyX3RhYmxlX29mZnNl
dCh2KSArIGwxX3RhYmxlX29mZnNldCh2KSAhPSAwKSkgKQogICAgICAgICAg
ICAgY29udGludWU7Ci0gICAgICAgIGlmICggbG9ja2luZyApCi0gICAgICAg
ICAgICBzcGluX2xvY2soJm1hcF9wZ2Rpcl9sb2NrKTsKKyAgICAgICAgc3Bp
bl9sb2NrX2lmKGxvY2tpbmcsICZtYXBfcGdkaXJfbG9jayk7CiAKICAgICAg
ICAgLyoKICAgICAgICAgICogTDNFIG1heSBiZSBhbHJlYWR5IGNsZWFyZWQs
IG9yIHNldCB0byBhIHN1cGVycGFnZSwgYnkKZGlmZiAtLWdpdCBhL3hlbi9h
cmNoL3g4Ni9tbS9tbS1sb2Nrcy5oIGIveGVuL2FyY2gveDg2L21tL21tLWxv
Y2tzLmgKaW5kZXggY2M2MzVhNDQwNTcxLi43ZWVlMjMzYjRjZWYgMTAwNjQ0
Ci0tLSBhL3hlbi9hcmNoL3g4Ni9tbS9tbS1sb2Nrcy5oCisrKyBiL3hlbi9h
cmNoL3g4Ni9tbS9tbS1sb2Nrcy5oCkBAIC0zNDcsNiArMzQ3LDE1IEBAIHN0
YXRpYyBpbmxpbmUgdm9pZCBwMm1fdW5sb2NrKHN0cnVjdCBwMm1fZG9tYWlu
ICpwKQogI2RlZmluZSBwMm1fbG9ja2VkX2J5X21lKHApICAgbW1fd3JpdGVf
bG9ja2VkX2J5X21lKCYocCktPmxvY2spCiAjZGVmaW5lIGdmbl9sb2NrZWRf
YnlfbWUocCxnKSBwMm1fbG9ja2VkX2J5X21lKHApCiAKK3N0YXRpYyBhbHdh
eXNfaW5saW5lIHZvaWQgZ2ZuX2xvY2tfaWYoYm9vbCBjb25kaXRpb24sIHN0
cnVjdCBwMm1fZG9tYWluICpwMm0sCisgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIGdmbl90IGdmbiwgdW5zaWduZWQgaW50IG9yZGVy
KQoreworICAgIGlmICggY29uZGl0aW9uICkKKyAgICAgICAgZ2ZuX2xvY2so
cDJtLCBnZm4sIG9yZGVyKTsKKyAgICBlbHNlCisgICAgICAgIGJsb2NrX2xv
Y2tfc3BlY3VsYXRpb24oKTsKK30KKwogLyogUG9EIGxvY2sgKHBlci1wMm0t
dGFibGUpCiAgKgogICogUHJvdGVjdHMgcHJpdmF0ZSBQb0QgZGF0YSBzdHJ1
Y3RzOiBlbnRyeSBhbmQgY2FjaGUKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4
Ni9tbS9wMm0uYyBiL3hlbi9hcmNoL3g4Ni9tbS9wMm0uYwppbmRleCAyZDQx
NDQ2YTY5MDIuLmRkZDJmODYxYzNjNyAxMDA2NDQKLS0tIGEveGVuL2FyY2gv
eDg2L21tL3AybS5jCisrKyBiL3hlbi9hcmNoL3g4Ni9tbS9wMm0uYwpAQCAt
NTE0LDkgKzUxNCw4IEBAIG1mbl90IF9fZ2V0X2dmbl90eXBlX2FjY2Vzcyhz
dHJ1Y3QgcDJtX2RvbWFpbiAqcDJtLCB1bnNpZ25lZCBsb25nIGdmbl9sLAog
ICAgIGlmICggcSAmIFAyTV9VTlNIQVJFICkKICAgICAgICAgcSB8PSBQMk1f
QUxMT0M7CiAKLSAgICBpZiAoIGxvY2tlZCApCi0gICAgICAgIC8qIEdyYWIg
dGhlIGxvY2sgaGVyZSwgZG9uJ3QgcmVsZWFzZSB1bnRpbCBwdXRfZ2ZuICov
Ci0gICAgICAgIGdmbl9sb2NrKHAybSwgZ2ZuLCAwKTsKKyAgICAvKiBHcmFi
IHRoZSBsb2NrIGhlcmUsIGRvbid0IHJlbGVhc2UgdW50aWwgcHV0X2dmbiAq
LworICAgIGdmbl9sb2NrX2lmKGxvY2tlZCwgcDJtLCBnZm4sIDApOwogCiAg
ICAgbWZuID0gcDJtLT5nZXRfZW50cnkocDJtLCBnZm4sIHQsIGEsIHEsIHBh
Z2Vfb3JkZXIsIE5VTEwpOwogCmRpZmYgLS1naXQgYS94ZW4vaW5jbHVkZS94
ZW4vc3BpbmxvY2suaCBiL3hlbi9pbmNsdWRlL3hlbi9zcGlubG9jay5oCmlu
ZGV4IGVmZGIyMWVhOTA3Mi4uOGJmZmIzZjRiNjEwIDEwMDY0NAotLS0gYS94
ZW4vaW5jbHVkZS94ZW4vc3BpbmxvY2suaAorKysgYi94ZW4vaW5jbHVkZS94
ZW4vc3BpbmxvY2suaApAQCAtMjE2LDYgKzIxNiwxNCBAQCBzdGF0aWMgYWx3
YXlzX2lubGluZSB2b2lkIHNwaW5fbG9ja19pcnEoc3BpbmxvY2tfdCAqbCkK
ICAgICAgICAgYmxvY2tfbG9ja19zcGVjdWxhdGlvbigpOyAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBcCiAgICAgfSkKIAorLyogQ29uZGl0aW9u
YWxseSB0YWtlIGEgc3BpbmxvY2sgaW4gYSBzcGVjdWxhdGlvbiBzYWZlIHdh
eS4gKi8KK3N0YXRpYyBhbHdheXNfaW5saW5lIHZvaWQgc3Bpbl9sb2NrX2lm
KGJvb2wgY29uZGl0aW9uLCBzcGlubG9ja190ICpsKQoreworICAgIGlmICgg
Y29uZGl0aW9uICkKKyAgICAgICAgX3NwaW5fbG9jayhsKTsKKyAgICBibG9j
a19sb2NrX3NwZWN1bGF0aW9uKCk7Cit9CisKICNkZWZpbmUgc3Bpbl91bmxv
Y2sobCkgICAgICAgICAgICAgICAgX3NwaW5fdW5sb2NrKGwpCiAjZGVmaW5l
IHNwaW5fdW5sb2NrX2lycShsKSAgICAgICAgICAgIF9zcGluX3VubG9ja19p
cnEobCkKICNkZWZpbmUgc3Bpbl91bmxvY2tfaXJxcmVzdG9yZShsLCBmKSAg
X3NwaW5fdW5sb2NrX2lycXJlc3RvcmUobCwgZikK

--=separator
Content-Type: application/octet-stream; name="xsa453/xsa453-4.17-1.patch"
Content-Disposition: attachment; filename="xsa453/xsa453-4.17-1.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L3BhZ2luZzogRGVsZXRlIHVwZGF0ZV9jcjMoKSdz
IGRvX2xvY2tpbmcgcGFyYW1ldGVyCgpOaWNvbGEgcmVwb3J0cyB0aGF0IHRo
ZSBYU0EtNDM4IGZpeCBpbnRyb2R1Y2VkIG5ldyBNSVNSQSB2aW9sYXRpb25z
IGJlY2F1c2Ugb2YKc29tZSBpbmNpZGVudGFsIHRpZHlpbmcgaXQgdHJpZWQg
dG8gZG8uICBUaGUgcGFyYW1ldGVyIGlzIHVzZWxlc3MsIHNvIHJlc29sdmUK
dGhlIE1JU1JBIHJlZ3Jlc3Npb24gYnkgcmVtb3ZpbmcgaXQuCgpoYXBfdXBk
YXRlX2NyMygpIGRpc2NhcmRzIHRoZSBwYXJhbWV0ZXIgZW50aXJlbHksIHdo
aWxlIHNoX3VwZGF0ZV9jcjMoKSB1c2VzCml0IHRvIGRpc3Rpbmd1aXNoIGlu
dGVybmFsIGFuZCBleHRlcm5hbCBjYWxsZXJzIGFuZCB0aGVyZWZvcmUgd2hl
dGhlciB0aGUKcGFnaW5nIGxvY2sgc2hvdWxkIGJlIHRha2VuLgoKSG93ZXZl
ciwgd2UgaGF2ZSBwYWdpbmdfbG9ja19yZWN1cnNpdmUoKSBmb3IgdGhpcyBw
dXJwb3NlLCB3aGljaCBhbHNvIGF2b2lkcwp0aGUgYWJpbGl0eSBmb3IgdGhl
IHNoYWRvdyBpbnRlcm5hbCBjYWxsZXJzIHRvIGFjY2lkZW50YWxseSBub3Qg
aG9sZCB0aGUgbG9jay4KCkZpeGVzOiBmYjBmZjQ5ZmU5ZjcgKCJ4ODYvc2hh
ZG93OiBkZWZlciByZWxlYXNpbmcgb2YgUFYncyB0b3AtbGV2ZWwgc2hhZG93
IHJlZmVyZW5jZSIpClJlcG9ydGVkLWJ5OiBOaWNvbGEgVmV0cmluaSA8bmlj
b2xhLnZldHJpbmlAYnVnc2VuZy5jb20+ClNpZ25lZC1vZmYtYnk6IEFuZHJl
dyBDb29wZXIgPGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+ClJldmlld2Vk
LWJ5OiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+ClJlbGVhc2Ut
YWNrZWQtYnk6IEhlbnJ5IFdhbmcgPEhlbnJ5LldhbmdAYXJtLmNvbT4KKGNo
ZXJyeSBwaWNrZWQgZnJvbSBjb21taXQgZTcxMTU3ZDFhYzJhN2ZiZjQxMzEz
MDY2M2NmMGE5M2ZmOWZiY2Y3ZSkKCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94
ODYvaW5jbHVkZS9hc20vcGFnaW5nLmggYi94ZW4vYXJjaC94ODYvaW5jbHVk
ZS9hc20vcGFnaW5nLmgKaW5kZXggOTRjNTkwZjMxYWE4Li44MDlmZjM1ZDlh
MGQgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9wYWdp
bmcuaAorKysgYi94ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vcGFnaW5nLmgK
QEAgLTEzOCw4ICsxMzgsNyBAQCBzdHJ1Y3QgcGFnaW5nX21vZGUgewogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwYWRk
cl90IGdhLCB1aW50MzJfdCAqcGZlYywKICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgdW5zaWduZWQgaW50ICpwYWdlX29y
ZGVyKTsKICNlbmRpZgotICAgIHBhZ2V0YWJsZV90ICAgKCp1cGRhdGVfY3Iz
ICAgICAgICAgICAgKShzdHJ1Y3QgdmNwdSAqdiwgYm9vbCBkb19sb2NraW5n
LAotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBib29sIG5vZmx1c2gpOworICAgIHBhZ2V0YWJsZV90ICAgKCp1cGRhdGVf
Y3IzICAgICAgICAgICAgKShzdHJ1Y3QgdmNwdSAqdiwgYm9vbCBub2ZsdXNo
KTsKICAgICB2b2lkICAgICAgICAgICgqdXBkYXRlX3BhZ2luZ19tb2RlcyAg
ICkoc3RydWN0IHZjcHUgKnYpOwogICAgIGJvb2wgICAgICAgICAgKCpmbHVz
aF90bGIgICAgICAgICAgICAgKShjb25zdCB1bnNpZ25lZCBsb25nICp2Y3B1
X2JpdG1hcCk7CiAKQEAgLTMxMiw3ICszMTEsNyBAQCBzdGF0aWMgaW5saW5l
IHVuc2lnbmVkIGxvbmcgcGFnaW5nX2dhX3RvX2dmbl9jcjMoc3RydWN0IHZj
cHUgKnYsCiAgKiBhcyB0aGUgdmFsdWUgdG8gbG9hZCBpbnRvIHRoZSBob3N0
IENSMyB0byBzY2hlZHVsZSB0aGlzIHZjcHUgKi8KIHN0YXRpYyBpbmxpbmUg
cGFnZXRhYmxlX3QgcGFnaW5nX3VwZGF0ZV9jcjMoc3RydWN0IHZjcHUgKnYs
IGJvb2wgbm9mbHVzaCkKIHsKLSAgICByZXR1cm4gcGFnaW5nX2dldF9ob3N0
bW9kZSh2KS0+dXBkYXRlX2NyMyh2LCAxLCBub2ZsdXNoKTsKKyAgICByZXR1
cm4gcGFnaW5nX2dldF9ob3N0bW9kZSh2KS0+dXBkYXRlX2NyMyh2LCBub2Zs
dXNoKTsKIH0KIAogLyogVXBkYXRlIGFsbCB0aGUgdGhpbmdzIHRoYXQgYXJl
IGRlcml2ZWQgZnJvbSB0aGUgZ3Vlc3QncyBDUjAvQ1IzL0NSNC4KZGlmZiAt
LWdpdCBhL3hlbi9hcmNoL3g4Ni9tbS9oYXAvaGFwLmMgYi94ZW4vYXJjaC94
ODYvbW0vaGFwL2hhcC5jCmluZGV4IDU3YTE5YzNkNTlkMS4uM2FkMzlhN2Rk
NzgxIDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYvbW0vaGFwL2hhcC5jCisr
KyBiL3hlbi9hcmNoL3g4Ni9tbS9oYXAvaGFwLmMKQEAgLTczOSw4ICs3Mzks
NyBAQCBzdGF0aWMgYm9vbCBjZl9jaGVjayBoYXBfaW52bHBnKHN0cnVjdCB2
Y3B1ICp2LCB1bnNpZ25lZCBsb25nIGxpbmVhcikKICAgICByZXR1cm4gMTsK
IH0KIAotc3RhdGljIHBhZ2V0YWJsZV90IGNmX2NoZWNrIGhhcF91cGRhdGVf
Y3IzKAotICAgIHN0cnVjdCB2Y3B1ICp2LCBib29sIGRvX2xvY2tpbmcsIGJv
b2wgbm9mbHVzaCkKK3N0YXRpYyBwYWdldGFibGVfdCBjZl9jaGVjayBoYXBf
dXBkYXRlX2NyMyhzdHJ1Y3QgdmNwdSAqdiwgYm9vbCBub2ZsdXNoKQogewog
ICAgIHYtPmFyY2guaHZtLmh3X2NyWzNdID0gdi0+YXJjaC5odm0uZ3Vlc3Rf
Y3JbM107CiAgICAgaHZtX3VwZGF0ZV9ndWVzdF9jcjModiwgbm9mbHVzaCk7
CkBAIC04MjYsNyArODI1LDcgQEAgc3RhdGljIHZvaWQgY2ZfY2hlY2sgaGFw
X3VwZGF0ZV9wYWdpbmdfbW9kZXMoc3RydWN0IHZjcHUgKnYpCiAgICAgfQog
CiAgICAgLyogQ1IzIGlzIGVmZmVjdGl2ZWx5IHVwZGF0ZWQgYnkgYSBtb2Rl
IGNoYW5nZS4gRmx1c2ggQVNJRHMsIGV0Yy4gKi8KLSAgICBoYXBfdXBkYXRl
X2NyMyh2LCAwLCBmYWxzZSk7CisgICAgaGFwX3VwZGF0ZV9jcjModiwgZmFs
c2UpOwogCiAgdW5sb2NrOgogICAgIHBhZ2luZ191bmxvY2soZCk7CmRpZmYg
LS1naXQgYS94ZW4vYXJjaC94ODYvbW0vc2hhZG93L2NvbW1vbi5jIGIveGVu
L2FyY2gveDg2L21tL3NoYWRvdy9jb21tb24uYwppbmRleCBjMDk0MGY5Mzll
ZjAuLjE4NzE0ZGJkMDJhYiAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L21t
L3NoYWRvdy9jb21tb24uYworKysgYi94ZW4vYXJjaC94ODYvbW0vc2hhZG93
L2NvbW1vbi5jCkBAIC0yNTc5LDcgKzI1NzksNyBAQCBzdGF0aWMgdm9pZCBz
aF91cGRhdGVfcGFnaW5nX21vZGVzKHN0cnVjdCB2Y3B1ICp2KQogICAgIH0K
ICNlbmRpZiAvKiBPT1MgKi8KIAotICAgIHYtPmFyY2gucGFnaW5nLm1vZGUt
PnVwZGF0ZV9jcjModiwgMCwgZmFsc2UpOworICAgIHYtPmFyY2gucGFnaW5n
Lm1vZGUtPnVwZGF0ZV9jcjModiwgZmFsc2UpOwogfQogCiB2b2lkIGNmX2No
ZWNrIHNoYWRvd191cGRhdGVfcGFnaW5nX21vZGVzKHN0cnVjdCB2Y3B1ICp2
KQpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L21tL3NoYWRvdy9tdWx0aS5j
IGIveGVuL2FyY2gveDg2L21tL3NoYWRvdy9tdWx0aS5jCmluZGV4IGM5MmIz
NTRhNzgxNS4uZTU0YTUwN2I1NGY2IDEwMDY0NAotLS0gYS94ZW4vYXJjaC94
ODYvbW0vc2hhZG93L211bHRpLmMKKysrIGIveGVuL2FyY2gveDg2L21tL3No
YWRvdy9tdWx0aS5jCkBAIC0yNTA2LDcgKzI1MDYsNyBAQCBzdGF0aWMgaW50
IGNmX2NoZWNrIHNoX3BhZ2VfZmF1bHQoCiAgICAgICAgICAqIEluIGFueSBj
YXNlLCBpbiB0aGUgUEFFIGNhc2UsIHRoZSBBU1NFUlQgaXMgbm90IHRydWU7
IGl0IGNhbgogICAgICAgICAgKiBoYXBwZW4gYmVjYXVzZSBvZiBhY3Rpb25z
IHRoZSBndWVzdCBpcyB0YWtpbmcuICovCiAjaWYgR1VFU1RfUEFHSU5HX0xF
VkVMUyA9PSAzCi0gICAgICAgIHYtPmFyY2gucGFnaW5nLm1vZGUtPnVwZGF0
ZV9jcjModiwgMCwgZmFsc2UpOworICAgICAgICB2LT5hcmNoLnBhZ2luZy5t
b2RlLT51cGRhdGVfY3IzKHYsIGZhbHNlKTsKICNlbHNlCiAgICAgICAgIEFT
U0VSVChkLT5pc19zaHV0dGluZ19kb3duKTsKICNlbmRpZgpAQCAtMzIyNCwx
NyArMzIyNCwxMyBAQCBzdGF0aWMgdm9pZCBjZl9jaGVjayBzaF9kZXRhY2hf
b2xkX3RhYmxlcyhzdHJ1Y3QgdmNwdSAqdikKICAgICB9CiB9CiAKLXN0YXRp
YyBwYWdldGFibGVfdCBjZl9jaGVjayBzaF91cGRhdGVfY3IzKHN0cnVjdCB2
Y3B1ICp2LCBib29sIGRvX2xvY2tpbmcsCi0gICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBib29sIG5vZmx1c2gpCitzdGF0aWMg
cGFnZXRhYmxlX3QgY2ZfY2hlY2sgc2hfdXBkYXRlX2NyMyhzdHJ1Y3QgdmNw
dSAqdiwgYm9vbCBub2ZsdXNoKQogLyogVXBkYXRlcyB2Y3B1LT5hcmNoLmNy
MyBhZnRlciB0aGUgZ3Vlc3QgaGFzIGNoYW5nZWQgQ1IzLgogICogUGFyYXZp
cnR1YWwgZ3Vlc3RzIHNob3VsZCBzZXQgdi0+YXJjaC5ndWVzdF90YWJsZSAo
YW5kIGd1ZXN0X3RhYmxlX3VzZXIsCiAgKiBpZiBhcHByb3ByaWF0ZSkuCiAg
KiBIVk0gZ3Vlc3RzIHNob3VsZCBhbHNvIG1ha2Ugc3VyZSBodm1fZ2V0X2d1
ZXN0X2NudGxfcmVnKHYsIDMpIHdvcmtzOwogICogdGhpcyBmdW5jdGlvbiB3
aWxsIGNhbGwgaHZtX3VwZGF0ZV9ndWVzdF9jcih2LCAzKSB0byB0ZWxsIHRo
ZW0gd2hlcmUgdGhlCiAgKiBzaGFkb3cgdGFibGVzIGFyZS4KLSAqIElmIGRv
X2xvY2tpbmcgIT0gMCwgYXNzdW1lIHdlIGFyZSBiZWluZyBjYWxsZWQgZnJv
bSBvdXRzaWRlIHRoZQotICogc2hhZG93IGNvZGUsIGFuZCBtdXN0IHRha2Ug
YW5kIHJlbGVhc2UgdGhlIHBhZ2luZyBsb2NrOyBvdGhlcndpc2UKLSAqIHRo
YXQgaXMgdGhlIGNhbGxlcidzIHJlc3BvbnNpYmlsaXR5LgogICovCiB7CiAg
ICAgc3RydWN0IGRvbWFpbiAqZCA9IHYtPmRvbWFpbjsKQEAgLTMyNTIsNyAr
MzI0OCwxMSBAQCBzdGF0aWMgcGFnZXRhYmxlX3QgY2ZfY2hlY2sgc2hfdXBk
YXRlX2NyMyhzdHJ1Y3QgdmNwdSAqdiwgYm9vbCBkb19sb2NraW5nLAogICAg
ICAgICByZXR1cm4gb2xkX2VudHJ5OwogICAgIH0KIAotICAgIGlmICggZG9f
bG9ja2luZyApIHBhZ2luZ19sb2NrKHYtPmRvbWFpbik7CisgICAgLyoKKyAg
ICAgKiBUaGlzIGlzIHVzZWQgZXh0ZXJuYWxseSAod2l0aCB0aGUgcGFnaW5n
IGxvY2sgbm90IHRha2VuKSBhbmQgaW50ZXJuYWxseQorICAgICAqIGJ5IHRo
ZSBzaGFkb3cgY29kZSAod2l0aCB0aGUgbG9jayBhbHJlYWR5IHRha2VuKS4K
KyAgICAgKi8KKyAgICBwYWdpbmdfbG9ja19yZWN1cnNpdmUodi0+ZG9tYWlu
KTsKIAogI2lmIChTSEFET1dfT1BUSU1JWkFUSU9OUyAmIFNIT1BUX09VVF9P
Rl9TWU5DKQogICAgIC8qIE5lZWQgdG8gcmVzeW5jIGFsbCB0aGUgc2hhZG93
IGVudHJpZXMgb24gYSBUTEIgZmx1c2guICBSZXN5bmMKQEAgLTM0ODAsOCAr
MzQ4MCw3IEBAIHN0YXRpYyBwYWdldGFibGVfdCBjZl9jaGVjayBzaF91cGRh
dGVfY3IzKHN0cnVjdCB2Y3B1ICp2LCBib29sIGRvX2xvY2tpbmcsCiAgICAg
c2hhZG93X3N5bmNfb3RoZXJfdmNwdXModik7CiAjZW5kaWYKIAotICAgIC8q
IFJlbGVhc2UgdGhlIGxvY2ssIGlmIHdlIHRvb2sgaXQgKG90aGVyd2lzZSBp
dCdzIHRoZSBjYWxsZXIncyBwcm9ibGVtKSAqLwotICAgIGlmICggZG9fbG9j
a2luZyApIHBhZ2luZ191bmxvY2sodi0+ZG9tYWluKTsKKyAgICBwYWdpbmdf
dW5sb2NrKHYtPmRvbWFpbik7CiAKICAgICByZXR1cm4gb2xkX2VudHJ5Owog
fQpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L21tL3NoYWRvdy9ub25lLmMg
Yi94ZW4vYXJjaC94ODYvbW0vc2hhZG93L25vbmUuYwppbmRleCA3NDNjMGZm
Yjg1MTQuLjdlNGUzODZjZDAzMCAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2
L21tL3NoYWRvdy9ub25lLmMKKysrIGIveGVuL2FyY2gveDg2L21tL3NoYWRv
dy9ub25lLmMKQEAgLTUyLDggKzUyLDcgQEAgc3RhdGljIHVuc2lnbmVkIGxv
bmcgY2ZfY2hlY2sgX2d2YV90b19nZm4oCiB9CiAjZW5kaWYKIAotc3RhdGlj
IHBhZ2V0YWJsZV90IGNmX2NoZWNrIF91cGRhdGVfY3IzKHN0cnVjdCB2Y3B1
ICp2LCBib29sIGRvX2xvY2tpbmcsCi0gICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgYm9vbCBub2ZsdXNoKQorc3RhdGljIHBhZ2V0
YWJsZV90IGNmX2NoZWNrIF91cGRhdGVfY3IzKHN0cnVjdCB2Y3B1ICp2LCBi
b29sIG5vZmx1c2gpCiB7CiAgICAgQVNTRVJUX1VOUkVBQ0hBQkxFKCk7CiAg
ICAgcmV0dXJuIHBhZ2V0YWJsZV9udWxsKCk7Cgo=

--=separator
Content-Type: application/octet-stream; name="xsa453/xsa453-4.17-2.patch"
Content-Disposition: attachment; filename="xsa453/xsa453-4.17-2.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeGVuOiBTd2FwIG9yZGVyIG9mIGFjdGlvbnMgaW4gdGhl
IEZSRUUqKCkgbWFjcm9zCgpXaGVyZXZlciBwb3NzaWJsZSwgaXQgaXMgYSBn
b29kIGlkZWEgdG8gTlVMTCBvdXQgdGhlIHZpc2libGUgcmVmZXJlbmNlIHRv
IGFuCm9iamVjdCBwcmlvciB0byBmcmVlaW5nIGl0LiAgVGhlIEZSRUUqKCkg
bWFjcm9zIGFscmVhZHkgY29sbGVjdCB0b2dldGhlciBib3RoCnBhcnRzLCBt
YWtpbmcgaXQgZWFzeSB0byBhZGp1c3QuCgpUaGlzIGhhcyBhIG1hcmdpbmFs
IGNvZGUgZ2VuZXJhdGlvbiBpbXByb3ZlbWVudCwgYXMgc29tZSBvZiB0aGUg
Y2FsbHMgdG8gdGhlCmZyZWUoKSBmdW5jdGlvbiBjYW4gYmUgdGFpbGNhbGwg
b3B0aW1pc2VkLgoKTm8gZnVuY3Rpb25hbCBjaGFuZ2UuCgpTaWduZWQtb2Zm
LWJ5OiBBbmRyZXcgQ29vcGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29t
PgpBY2tlZC1ieTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgoo
Y2hlcnJ5IHBpY2tlZCBmcm9tIGNvbW1pdCBjNGY0MjdlYzg3OWU3YzBkZjZk
NDRkMDI1NjFlOGJlZTgzOGEyOTNlKQoKZGlmZiAtLWdpdCBhL3hlbi9pbmNs
dWRlL3hlbi9tbS5oIGIveGVuL2luY2x1ZGUveGVuL21tLmgKaW5kZXggM2Rj
NjFiY2MzYzA3Li4yMTE2ODVhNWQyOWMgMTAwNjQ0Ci0tLSBhL3hlbi9pbmNs
dWRlL3hlbi9tbS5oCisrKyBiL3hlbi9pbmNsdWRlL3hlbi9tbS5oCkBAIC04
MCw4ICs4MCw5IEBAIGJvb2wgc2NydWJfZnJlZV9wYWdlcyh2b2lkKTsKIAog
LyogRnJlZSBhbiBhbGxvY2F0aW9uLCBhbmQgemVybyB0aGUgcG9pbnRlciB0
byBpdC4gKi8KICNkZWZpbmUgRlJFRV9YRU5IRUFQX1BBR0VTKHAsIG8pIGRv
IHsgXAotICAgIGZyZWVfeGVuaGVhcF9wYWdlcyhwLCBvKTsgICAgICAgICBc
CisgICAgdm9pZCAqX3B0cl8gPSAocCk7ICAgICAgICAgICAgICAgIFwKICAg
ICAocCkgPSBOVUxMOyAgICAgICAgICAgICAgICAgICAgICAgXAorICAgIGZy
ZWVfeGVuaGVhcF9wYWdlcyhfcHRyXywgbyk7ICAgICBcCiB9IHdoaWxlICgg
ZmFsc2UgKQogI2RlZmluZSBGUkVFX1hFTkhFQVBfUEFHRShwKSBGUkVFX1hF
TkhFQVBfUEFHRVMocCwgMCkKIApkaWZmIC0tZ2l0IGEveGVuL2luY2x1ZGUv
eGVuL3htYWxsb2MuaCBiL3hlbi9pbmNsdWRlL3hlbi94bWFsbG9jLmgKaW5k
ZXggMTY5NzlhMTE3YzZhLi5kODU3Mjk4MDExYzEgMTAwNjQ0Ci0tLSBhL3hl
bi9pbmNsdWRlL3hlbi94bWFsbG9jLmgKKysrIGIveGVuL2luY2x1ZGUveGVu
L3htYWxsb2MuaApAQCAtNjYsOSArNjYsMTAgQEAKIGV4dGVybiB2b2lkIHhm
cmVlKHZvaWQgKik7CiAKIC8qIEZyZWUgYW4gYWxsb2NhdGlvbiwgYW5kIHpl
cm8gdGhlIHBvaW50ZXIgdG8gaXQuICovCi0jZGVmaW5lIFhGUkVFKHApIGRv
IHsgXAotICAgIHhmcmVlKHApOyAgICAgICAgIFwKLSAgICAocCkgPSBOVUxM
OyAgICAgICBcCisjZGVmaW5lIFhGUkVFKHApIGRvIHsgICAgICAgICAgICAg
ICAgICAgICAgIFwKKyAgICB2b2lkICpfcHRyXyA9IChwKTsgICAgICAgICAg
ICAgICAgICAgICAgXAorICAgIChwKSA9IE5VTEw7ICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBcCisgICAgeGZyZWUoX3B0cl8pOyAgICAgICAgICAg
ICAgICAgICAgICAgICAgIFwKIH0gd2hpbGUgKCBmYWxzZSApCiAKIC8qIFVu
ZGVybHlpbmcgZnVuY3Rpb25zICovCg==

--=separator
Content-Type: application/octet-stream; name="xsa453/xsa453-4.17-3.patch"
Content-Disposition: attachment; filename="xsa453/xsa453-4.17-3.patch"
Content-Transfer-Encoding: base64

RnJvbTogPT9VVEYtOD9xP1JvZ2VyPTIwUGF1PTIwTW9ubj1DMz1BOT89IDxy
b2dlci5wYXVAY2l0cml4LmNvbT4KU3ViamVjdDogeDg2L3NwaW5sb2NrOiBp
bnRyb2R1Y2Ugc3VwcG9ydCBmb3IgYmxvY2tpbmcgc3BlY3VsYXRpb24gaW50
bwogY3JpdGljYWwgcmVnaW9ucwoKSW50cm9kdWNlIGEgbmV3IEtjb25maWcg
b3B0aW9uIHRvIGJsb2NrIHNwZWN1bGF0aW9uIGludG8gbG9jayBwcm90ZWN0
ZWQKY3JpdGljYWwgcmVnaW9ucy4gIFRoZSBLY29uZmlnIG9wdGlvbiBpcyBl
bmFibGVkIGJ5IGRlZmF1bHQsIGJ1dCB0aGUgbWl0aWdhdGlvbgp3b24ndCBi
ZSBlbmdhZ2VkIHVubGVzcyBpdCdzIGV4cGxpY2l0bHkgZW5hYmxlZCBpbiB0
aGUgY29tbWFuZCBsaW5lIHVzaW5nCmBzcGVjLWN0cmw9bG9jay1oYXJkZW5g
LgoKQ29udmVydCB0aGUgc3BpbmxvY2sgYWNxdWlyZSBtYWNyb3MgaW50byBh
bHdheXMtaW5saW5lIGZ1bmN0aW9ucywgYW5kIGludHJvZHVjZQphIHNwZWN1
bGF0aW9uIGJhcnJpZXIgYWZ0ZXIgdGhlIGxvY2sgaGFzIGJlZW4gdGFrZW4u
ICBOb3RlIHRoZSBzcGVjdWxhdGlvbgpiYXJyaWVyIGlzIG5vdCBwbGFjZWQg
aW5zaWRlIHRoZSBpbXBsZW1lbnRhdGlvbiBvZiB0aGUgc3BpbiBsb2NrIGZ1
bmN0aW9ucywgYXMKdG8gcHJldmVudCBzcGVjdWxhdGlvbiBmcm9tIGZhbGxp
bmcgdGhyb3VnaCB0aGUgY2FsbCB0byB0aGUgbG9jayBmdW5jdGlvbnMKcmVz
dWx0aW5nIGluIHRoZSBiYXJyaWVyIGFsc28gYmVpbmcgc2tpcHBlZC4KCnRy
eWxvY2sgdmFyaWFudHMgYXJlIHByb3RlY3RlZCB1c2luZyBhIGNvbnN0cnVj
dCBha2luIHRvIHRoZSBleGlzdGluZwpldmFsdWF0ZV9ub3NwZWMoKS4KClRo
aXMgcGF0Y2ggb25seSBpbXBsZW1lbnRzIHRoZSBzcGVjdWxhdGlvbiBiYXJy
aWVyIGZvciB4ODYuCgpOb3RlIHNwaW4gbG9ja3MgYXJlIHRoZSBvbmx5IGxv
Y2tpbmcgcHJpbWl0aXZlIHRha2VuIGNhcmUgaW4gdGhpcyBjaGFuZ2UsCmZ1
cnRoZXIgbG9ja2luZyBwcmltaXRpdmVzIHdpbGwgYmUgYWRqdXN0ZWQgYnkg
c2VwYXJhdGUgY2hhbmdlcy4KClRoaXMgaXMgcGFydCBvZiBYU0EtNDUzIC8g
Q1ZFLTIwMjQtMjE5MwoKU2lnbmVkLW9mZi1ieTogUm9nZXIgUGF1IE1vbm7D
qSA8cm9nZXIucGF1QGNpdHJpeC5jb20+ClJldmlld2VkLWJ5OiBKYW4gQmV1
bGljaCA8amJldWxpY2hAc3VzZS5jb20+CihjaGVycnkgcGlja2VkIGZyb20g
Y29tbWl0IDdlZjAwODQ0MThlMTg4ZDA1ZjMzOGMzZTAyOGZiYmU4YjY5MjRh
ZmEpCgpkaWZmIC0tZ2l0IGEvZG9jcy9taXNjL3hlbi1jb21tYW5kLWxpbmUu
cGFuZG9jIGIvZG9jcy9taXNjL3hlbi1jb21tYW5kLWxpbmUucGFuZG9jCmlu
ZGV4IGQ5MDllYzk0ZmU3Yy4uZTFkNTY0MDdkZDg4IDEwMDY0NAotLS0gYS9k
b2NzL21pc2MveGVuLWNvbW1hbmQtbGluZS5wYW5kb2MKKysrIGIvZG9jcy9t
aXNjL3hlbi1jb21tYW5kLWxpbmUucGFuZG9jCkBAIC0yMzI3LDcgKzIzMjcs
NyBAQCBCeSBkZWZhdWx0IFNTQkQgd2lsbCBiZSBtaXRpZ2F0ZWQgYXQgcnVu
dGltZSAoaS5lIGBzc2JkPXJ1bnRpbWVgKS4KID4gICAgICAgICAgICAgIHtt
c3Itc2MscnNiLHZlcncsaWJwYi1lbnRyeX09PGJvb2w+fHtwdixodm19PTxi
b29sPiwKID4gICAgICAgICAgICAgIGJ0aS10aHVuaz1yZXRwb2xpbmV8bGZl
bmNlfGptcCwge2licnMsaWJwYixzc2JkLHBzZmQsCiA+ICAgICAgICAgICAg
ICBlYWdlci1mcHUsbDFkLWZsdXNoLGJyYW5jaC1oYXJkZW4sc3JiLWxvY2ss
Ci0+ICAgICAgICAgICAgICB1bnByaXYtbW1pbyxnZHMtbWl0LGRpdi1zY3J1
Yn09PGJvb2w+IF1gCis+ICAgICAgICAgICAgICB1bnByaXYtbW1pbyxnZHMt
bWl0LGRpdi1zY3J1Yixsb2NrLWhhcmRlbn09PGJvb2w+IF1gCiAKIENvbnRy
b2xzIGZvciBzcGVjdWxhdGl2ZSBleGVjdXRpb24gc2lkZWNoYW5uZWwgbWl0
aWdhdGlvbnMuICBCeSBkZWZhdWx0LCBYZW4KIHdpbGwgcGljayB0aGUgbW9z
dCBhcHByb3ByaWF0ZSBtaXRpZ2F0aW9ucyBiYXNlZCBvbiBjb21waWxlZCBp
biBzdXBwb3J0LApAQCAtMjQ1NCw2ICsyNDU0LDExIEBAIE9uIGFsbCBoYXJk
d2FyZSwgdGhlIGBkaXYtc2NydWI9YCBvcHRpb24gY2FuIGJlIHVzZWQgdG8g
Zm9yY2Ugb3IgcHJldmVudCBYZW4KIGZyb20gbWl0aWdhdGluZyB0aGUgRElW
LWxlYWthZ2UgdnVsbmVyYWJpbGl0eS4gIEJ5IGRlZmF1bHQsIFhlbiB3aWxs
IG1pdGlnYXRlCiBESVYtbGVha2FnZSBvbiBoYXJkd2FyZSBiZWxpZXZlZCB0
byBiZSB2dWxuZXJhYmxlLgogCitJZiBYZW4gaXMgY29tcGlsZWQgd2l0aCBg
Q09ORklHX1NQRUNVTEFUSVZFX0hBUkRFTl9MT0NLYCwgdGhlIGBsb2NrLWhh
cmRlbj1gCitib29sZWFuIGNhbiBiZSB1c2VkIHRvIGZvcmNlIG9yIHByZXZl
bnQgWGVuIGZyb20gdXNpbmcgc3BlY3VsYXRpb24gYmFycmllcnMgdG8KK3By
b3RlY3QgbG9jayBjcml0aWNhbCByZWdpb25zLiAgVGhpcyBtaXRpZ2F0aW9u
IHdvbid0IGJlIGVuZ2FnZWQgYnkgZGVmYXVsdCwKK2FuZCBuZWVkcyB0byBi
ZSBleHBsaWNpdGx5IGVuYWJsZWQgb24gdGhlIGNvbW1hbmQgbGluZS4KKwog
IyMjIHN5bmNfY29uc29sZQogPiBgPSA8Ym9vbGVhbj5gCiAKZGlmZiAtLWdp
dCBhL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9jcHVmZWF0dXJlcy5oIGIv
eGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2NwdWZlYXR1cmVzLmgKaW5kZXgg
YzNhYWQyMWMzYjQzLi43ZTgyMjFmZDg1ZGQgMTAwNjQ0Ci0tLSBhL3hlbi9h
cmNoL3g4Ni9pbmNsdWRlL2FzbS9jcHVmZWF0dXJlcy5oCisrKyBiL3hlbi9h
cmNoL3g4Ni9pbmNsdWRlL2FzbS9jcHVmZWF0dXJlcy5oCkBAIC0yNCw3ICsy
NCw3IEBAIFhFTl9DUFVGRUFUVVJFKEFQRVJGTVBFUkYsICAgICAgICBYODZf
U1lOVEgoIDgpKSAvKiBBUEVSRk1QRVJGICovCiBYRU5fQ1BVRkVBVFVSRShN
RkVOQ0VfUkRUU0MsICAgICAgWDg2X1NZTlRIKCA5KSkgLyogTUZFTkNFIHN5
bmNocm9uaXplcyBSRFRTQyAqLwogWEVOX0NQVUZFQVRVUkUoWEVOX1NNRVAs
ICAgICAgICAgIFg4Nl9TWU5USCgxMCkpIC8qIFNNRVAgZ2V0cyB1c2VkIGJ5
IFhlbiBpdHNlbGYgKi8KIFhFTl9DUFVGRUFUVVJFKFhFTl9TTUFQLCAgICAg
ICAgICBYODZfU1lOVEgoMTEpKSAvKiBTTUFQIGdldHMgdXNlZCBieSBYZW4g
aXRzZWxmICovCi0vKiBCaXQgMTIgdW51c2VkLiAqLworWEVOX0NQVUZFQVRV
UkUoU0NfTk9fTE9DS19IQVJERU4sIFg4Nl9TWU5USCgxMikpIC8qIChEaXNh
YmxlKSBMb2NrIGNyaXRpY2FsIHJlZ2lvbiBoYXJkZW5pbmcgKi8KIFhFTl9D
UFVGRUFUVVJFKElORF9USFVOS19MRkVOQ0UsICBYODZfU1lOVEgoMTMpKSAv
KiBVc2UgSU5EX1RIVU5LX0xGRU5DRSAqLwogWEVOX0NQVUZFQVRVUkUoSU5E
X1RIVU5LX0pNUCwgICAgIFg4Nl9TWU5USCgxNCkpIC8qIFVzZSBJTkRfVEhV
TktfSk1QICovCiBYRU5fQ1BVRkVBVFVSRShTQ19OT19CUkFOQ0hfSEFSREVO
LCBYODZfU1lOVEgoMTUpKSAvKiAoRGlzYWJsZSkgQ29uZGl0aW9uYWwgYnJh
bmNoIGhhcmRlbmluZyAqLwpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2lu
Y2x1ZGUvYXNtL25vc3BlYy5oIGIveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNt
L25vc3BlYy5oCmluZGV4IDcxNTBlNzZiODdmYi4uMDcyNTgzOWUxOTgyIDEw
MDY0NAotLS0gYS94ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vbm9zcGVjLmgK
KysrIGIveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL25vc3BlYy5oCkBAIC0z
OCw2ICszOCwzMiBAQCBzdGF0aWMgYWx3YXlzX2lubGluZSB2b2lkIGJsb2Nr
X3NwZWN1bGF0aW9uKHZvaWQpCiAgICAgYmFycmllcl9ub3NwZWNfdHJ1ZSgp
OwogfQogCitzdGF0aWMgYWx3YXlzX2lubGluZSB2b2lkIGFyY2hfYmxvY2tf
bG9ja19zcGVjdWxhdGlvbih2b2lkKQoreworICAgIGFsdGVybmF0aXZlKCJs
ZmVuY2UiLCAiIiwgWDg2X0ZFQVRVUkVfU0NfTk9fTE9DS19IQVJERU4pOwor
fQorCisvKiBBbGxvdyB0byBpbnNlcnQgYSByZWFkIG1lbW9yeSBiYXJyaWVy
IGludG8gY29uZGl0aW9uYWxzICovCitzdGF0aWMgYWx3YXlzX2lubGluZSBi
b29sIGJhcnJpZXJfbG9ja190cnVlKHZvaWQpCit7CisgICAgYWx0ZXJuYXRp
dmUoImxmZW5jZSAjbm9zcGVjLXRydWUiLCAiIiwgWDg2X0ZFQVRVUkVfU0Nf
Tk9fTE9DS19IQVJERU4pOworICAgIHJldHVybiB0cnVlOworfQorCitzdGF0
aWMgYWx3YXlzX2lubGluZSBib29sIGJhcnJpZXJfbG9ja19mYWxzZSh2b2lk
KQoreworICAgIGFsdGVybmF0aXZlKCJsZmVuY2UgI25vc3BlYy1mYWxzZSIs
ICIiLCBYODZfRkVBVFVSRV9TQ19OT19MT0NLX0hBUkRFTik7CisgICAgcmV0
dXJuIGZhbHNlOworfQorCitzdGF0aWMgYWx3YXlzX2lubGluZSBib29sIGFy
Y2hfbG9ja19ldmFsdWF0ZV9ub3NwZWMoYm9vbCBjb25kaXRpb24pCit7Cisg
ICAgaWYgKCBjb25kaXRpb24gKQorICAgICAgICByZXR1cm4gYmFycmllcl9s
b2NrX3RydWUoKTsKKyAgICBlbHNlCisgICAgICAgIHJldHVybiBiYXJyaWVy
X2xvY2tfZmFsc2UoKTsKK30KKwogI2VuZGlmIC8qIF9BU01fWDg2X05PU1BF
Q19IICovCiAKIC8qCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYvc3BlY19j
dHJsLmMgYi94ZW4vYXJjaC94ODYvc3BlY19jdHJsLmMKaW5kZXggMWVlODFl
MmRmZTc5Li5hYzIxYWYyYzVjMGYgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4
Ni9zcGVjX2N0cmwuYworKysgYi94ZW4vYXJjaC94ODYvc3BlY19jdHJsLmMK
QEAgLTY1LDYgKzY1LDcgQEAgaW50OF90IF9fcmVhZF9tb3N0bHkgb3B0X2Vh
Z2VyX2ZwdSA9IC0xOwogaW50OF90IF9fcmVhZF9tb3N0bHkgb3B0X2wxZF9m
bHVzaCA9IC0xOwogc3RhdGljIGJvb2wgX19pbml0ZGF0YSBvcHRfYnJhbmNo
X2hhcmRlbiA9CiAgICAgSVNfRU5BQkxFRChDT05GSUdfU1BFQ1VMQVRJVkVf
SEFSREVOX0JSQU5DSCk7CitzdGF0aWMgYm9vbCBfX2luaXRkYXRhIG9wdF9s
b2NrX2hhcmRlbjsKIAogYm9vbCBfX2luaXRkYXRhIGJzcF9kZWxheV9zcGVj
X2N0cmw7CiB1aW50OF90IF9fcmVhZF9tb3N0bHkgZGVmYXVsdF94ZW5fc3Bl
Y19jdHJsOwpAQCAtMTMzLDYgKzEzNCw3IEBAIHN0YXRpYyBpbnQgX19pbml0
IGNmX2NoZWNrIHBhcnNlX3NwZWNfY3RybChjb25zdCBjaGFyICpzKQogICAg
ICAgICAgICAgb3B0X3NzYmQgPSBmYWxzZTsKICAgICAgICAgICAgIG9wdF9s
MWRfZmx1c2ggPSAwOwogICAgICAgICAgICAgb3B0X2JyYW5jaF9oYXJkZW4g
PSBmYWxzZTsKKyAgICAgICAgICAgIG9wdF9sb2NrX2hhcmRlbiA9IGZhbHNl
OwogICAgICAgICAgICAgb3B0X3NyYl9sb2NrID0gMDsKICAgICAgICAgICAg
IG9wdF91bnByaXZfbW1pbyA9IGZhbHNlOwogICAgICAgICAgICAgb3B0X2dk
c19taXQgPSAwOwpAQCAtMjk4LDYgKzMwMCwxNiBAQCBzdGF0aWMgaW50IF9f
aW5pdCBjZl9jaGVjayBwYXJzZV9zcGVjX2N0cmwoY29uc3QgY2hhciAqcykK
ICAgICAgICAgICAgICAgICByYyA9IC1FSU5WQUw7CiAgICAgICAgICAgICB9
CiAgICAgICAgIH0KKyAgICAgICAgZWxzZSBpZiAoICh2YWwgPSBwYXJzZV9i
b29sZWFuKCJsb2NrLWhhcmRlbiIsIHMsIHNzKSkgPj0gMCApCisgICAgICAg
IHsKKyAgICAgICAgICAgIGlmICggSVNfRU5BQkxFRChDT05GSUdfU1BFQ1VM
QVRJVkVfSEFSREVOX0xPQ0spICkKKyAgICAgICAgICAgICAgICBvcHRfbG9j
a19oYXJkZW4gPSB2YWw7CisgICAgICAgICAgICBlbHNlCisgICAgICAgICAg
ICB7CisgICAgICAgICAgICAgICAgbm9fY29uZmlnX3BhcmFtKCJTUEVDVUxB
VElWRV9IQVJERU5fTE9DSyIsICJzcGVjLWN0cmwiLCBzLCBzcyk7CisgICAg
ICAgICAgICAgICAgcmMgPSAtRUlOVkFMOworICAgICAgICAgICAgfQorICAg
ICAgICB9CiAgICAgICAgIGVsc2UgaWYgKCAodmFsID0gcGFyc2VfYm9vbGVh
bigic3JiLWxvY2siLCBzLCBzcykpID49IDAgKQogICAgICAgICAgICAgb3B0
X3NyYl9sb2NrID0gdmFsOwogICAgICAgICBlbHNlIGlmICggKHZhbCA9IHBh
cnNlX2Jvb2xlYW4oInVucHJpdi1tbWlvIiwgcywgc3MpKSA+PSAwICkKQEAg
LTUwMCw3ICs1MTIsOCBAQCBzdGF0aWMgdm9pZCBfX2luaXQgcHJpbnRfZGV0
YWlscyhlbnVtIGluZF90aHVuayB0aHVuaykKICAgICBpZiAoIElTX0VOQUJM
RUQoQ09ORklHX0lORElSRUNUX1RIVU5LKSB8fCBJU19FTkFCTEVEKENPTkZJ
R19TSEFET1dfUEFHSU5HKSB8fAogICAgICAgICAgSVNfRU5BQkxFRChDT05G
SUdfU1BFQ1VMQVRJVkVfSEFSREVOX0FSUkFZKSB8fAogICAgICAgICAgSVNf
RU5BQkxFRChDT05GSUdfU1BFQ1VMQVRJVkVfSEFSREVOX0JSQU5DSCkgfHwK
LSAgICAgICAgIElTX0VOQUJMRUQoQ09ORklHX1NQRUNVTEFUSVZFX0hBUkRF
Tl9HVUVTVF9BQ0NFU1MpICkKKyAgICAgICAgIElTX0VOQUJMRUQoQ09ORklH
X1NQRUNVTEFUSVZFX0hBUkRFTl9HVUVTVF9BQ0NFU1MpIHx8CisgICAgICAg
ICBJU19FTkFCTEVEKENPTkZJR19TUEVDVUxBVElWRV9IQVJERU5fTE9DSykg
KQogICAgICAgICBwcmludGsoIiAgQ29tcGlsZWQtaW4gc3VwcG9ydDoiCiAj
aWZkZWYgQ09ORklHX0lORElSRUNUX1RIVU5LCiAgICAgICAgICAgICAgICAi
IElORElSRUNUX1RIVU5LIgpAQCAtNTE2LDExICs1MjksMTQgQEAgc3RhdGlj
IHZvaWQgX19pbml0IHByaW50X2RldGFpbHMoZW51bSBpbmRfdGh1bmsgdGh1
bmspCiAjZW5kaWYKICNpZmRlZiBDT05GSUdfU1BFQ1VMQVRJVkVfSEFSREVO
X0dVRVNUX0FDQ0VTUwogICAgICAgICAgICAgICAgIiBIQVJERU5fR1VFU1Rf
QUNDRVNTIgorI2VuZGlmCisjaWZkZWYgQ09ORklHX1NQRUNVTEFUSVZFX0hB
UkRFTl9MT0NLCisgICAgICAgICAgICAgICAiIEhBUkRFTl9MT0NLIgogI2Vu
ZGlmCiAgICAgICAgICAgICAgICAiXG4iKTsKIAogICAgIC8qIFNldHRpbmdz
IGZvciBYZW4ncyBwcm90ZWN0aW9uLCBpcnJlc3BlY3RpdmUgb2YgZ3Vlc3Rz
LiAqLwotICAgIHByaW50aygiICBYZW4gc2V0dGluZ3M6ICVzJXNTUEVDX0NU
Ukw6ICVzJXMlcyVzJXMsIE90aGVyOiVzJXMlcyVzJXMlc1xuIiwKKyAgICBw
cmludGsoIiAgWGVuIHNldHRpbmdzOiAlcyVzU1BFQ19DVFJMOiAlcyVzJXMl
cyVzLCBPdGhlcjolcyVzJXMlcyVzJXMlc1xuIiwKICAgICAgICAgICAgdGh1
bmsgIT0gVEhVTktfTk9ORSAgICAgID8gIkJUSS1UaHVuazogIiA6ICIiLAog
ICAgICAgICAgICB0aHVuayA9PSBUSFVOS19OT05FICAgICAgPyAiIiA6CiAg
ICAgICAgICAgIHRodW5rID09IFRIVU5LX1JFVFBPTElORSA/ICJSRVRQT0xJ
TkUsICIgOgpAQCAtNTQ3LDcgKzU2Myw4IEBAIHN0YXRpYyB2b2lkIF9faW5p
dCBwcmludF9kZXRhaWxzKGVudW0gaW5kX3RodW5rIHRodW5rKQogICAgICAg
ICAgICBvcHRfdmVyd19wdiB8fCBvcHRfdmVyd19odm0gfHwKICAgICAgICAg
ICAgb3B0X3ZlcndfbW1pbyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
PyAiIFZFUlciICA6ICIiLAogICAgICAgICAgICBvcHRfZGl2X3NjcnViICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICA/ICIgRElWIiA6ICIiLAotICAg
ICAgICAgICBvcHRfYnJhbmNoX2hhcmRlbiAgICAgICAgICAgICAgICAgICAg
ICAgICA/ICIgQlJBTkNIX0hBUkRFTiIgOiAiIik7CisgICAgICAgICAgIG9w
dF9icmFuY2hfaGFyZGVuICAgICAgICAgICAgICAgICAgICAgICAgID8gIiBC
UkFOQ0hfSEFSREVOIiA6ICIiLAorICAgICAgICAgICBvcHRfbG9ja19oYXJk
ZW4gICAgICAgICAgICAgICAgICAgICAgICAgICA/ICIgTE9DS19IQVJERU4i
IDogIiIpOwogCiAgICAgLyogTDFURiBkaWFnbm9zdGljcywgcHJpbnRlZCBp
ZiB2dWxuZXJhYmxlIG9yIFBWIHNoYWRvd2luZyBpcyBpbiB1c2UuICovCiAg
ICAgaWYgKCBjcHVfaGFzX2J1Z19sMXRmIHx8IG9wdF9wdl9sMXRmX2h3ZG9t
IHx8IG9wdF9wdl9sMXRmX2RvbXUgKQpAQCAtMTkzMCw2ICsxOTQ3LDkgQEAg
dm9pZCBfX2luaXQgaW5pdF9zcGVjdWxhdGlvbl9taXRpZ2F0aW9ucyh2b2lk
KQogICAgIGlmICggIW9wdF9icmFuY2hfaGFyZGVuICkKICAgICAgICAgc2V0
dXBfZm9yY2VfY3B1X2NhcChYODZfRkVBVFVSRV9TQ19OT19CUkFOQ0hfSEFS
REVOKTsKIAorICAgIGlmICggIW9wdF9sb2NrX2hhcmRlbiApCisgICAgICAg
IHNldHVwX2ZvcmNlX2NwdV9jYXAoWDg2X0ZFQVRVUkVfU0NfTk9fTE9DS19I
QVJERU4pOworCiAgICAgLyoKICAgICAgKiBXZSBkbyBub3QgZGlzYWJsZSBI
VCBieSBkZWZhdWx0IG9uIGFmZmVjdGVkIGhhcmR3YXJlLgogICAgICAqCmRp
ZmYgLS1naXQgYS94ZW4vY29tbW9uL0tjb25maWcgYi94ZW4vY29tbW9uL0tj
b25maWcKaW5kZXggZTc3OTRjYjdmNjgxLi5jZDczODUxNTM4MjMgMTAwNjQ0
Ci0tLSBhL3hlbi9jb21tb24vS2NvbmZpZworKysgYi94ZW4vY29tbW9uL0tj
b25maWcKQEAgLTE3Myw2ICsxNzMsMjMgQEAgY29uZmlnIFNQRUNVTEFUSVZF
X0hBUkRFTl9HVUVTVF9BQ0NFU1MKIAogCSAgSWYgdW5zdXJlLCBzYXkgWS4K
IAorY29uZmlnIFNQRUNVTEFUSVZFX0hBUkRFTl9MT0NLCisJYm9vbCAiU3Bl
Y3VsYXRpdmUgbG9jayBjb250ZXh0IGhhcmRlbmluZyIKKwlkZWZhdWx0IHkK
KwlkZXBlbmRzIG9uIFg4NgorCWhlbHAKKwkgIENvbnRlbXBvcmFyeSBwcm9j
ZXNzb3JzIG1heSB1c2Ugc3BlY3VsYXRpdmUgZXhlY3V0aW9uIGFzIGEKKwkg
IHBlcmZvcm1hbmNlIG9wdGltaXNhdGlvbiwgYnV0IHRoaXMgY2FuIHBvdGVu
dGlhbGx5IGJlIGFidXNlZCBieSBhbgorCSAgYXR0YWNrZXIgdG8gbGVhayBk
YXRhIHZpYSBzcGVjdWxhdGl2ZSBzaWRlY2hhbm5lbHMuCisKKwkgIE9uZSBz
b3VyY2Ugb2YgZGF0YSBsZWFrYWdlIGlzIHZpYSBzcGVjdWxhdGl2ZSBhY2Nl
c3NlcyB0byBsb2NrCisJICBjcml0aWNhbCByZWdpb25zLgorCisJICBUaGlz
IG9wdGlvbiBpcyBkaXNhYmxlZCBieSBkZWZhdWx0IGF0IHJ1biB0aW1lLCBh
bmQgbmVlZHMgdG8gYmUKKwkgIGVuYWJsZWQgb24gdGhlIGNvbW1hbmQgbGlu
ZS4KKworCSAgSWYgdW5zdXJlLCBzYXkgWS4KKwogZW5kbWVudQogCiBjb25m
aWcgRElUX0RFRkFVTFQKZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL3hlbi9u
b3NwZWMuaCBiL3hlbi9pbmNsdWRlL3hlbi9ub3NwZWMuaAppbmRleCA3NjI1
NWJjNDZlZmUuLjQ1NTI4NDY0MDM5NiAxMDA2NDQKLS0tIGEveGVuL2luY2x1
ZGUveGVuL25vc3BlYy5oCisrKyBiL3hlbi9pbmNsdWRlL3hlbi9ub3NwZWMu
aApAQCAtNzAsNiArNzAsMjEgQEAgc3RhdGljIGlubGluZSB1bnNpZ25lZCBs
b25nIGFycmF5X2luZGV4X21hc2tfbm9zcGVjKHVuc2lnbmVkIGxvbmcgaW5k
ZXgsCiAjZGVmaW5lIGFycmF5X2FjY2Vzc19ub3NwZWMoYXJyYXksIGluZGV4
KSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgKGFycmF5
KVthcnJheV9pbmRleF9ub3NwZWMoaW5kZXgsIEFSUkFZX1NJWkUoYXJyYXkp
KV0KIAorc3RhdGljIGFsd2F5c19pbmxpbmUgdm9pZCBibG9ja19sb2NrX3Nw
ZWN1bGF0aW9uKHZvaWQpCit7CisjaWZkZWYgQ09ORklHX1NQRUNVTEFUSVZF
X0hBUkRFTl9MT0NLCisgICAgYXJjaF9ibG9ja19sb2NrX3NwZWN1bGF0aW9u
KCk7CisjZW5kaWYKK30KKworc3RhdGljIGFsd2F5c19pbmxpbmUgYm9vbCBs
b2NrX2V2YWx1YXRlX25vc3BlYyhib29sIGNvbmRpdGlvbikKK3sKKyNpZmRl
ZiBDT05GSUdfU1BFQ1VMQVRJVkVfSEFSREVOX0xPQ0sKKyAgICByZXR1cm4g
YXJjaF9sb2NrX2V2YWx1YXRlX25vc3BlYyhjb25kaXRpb24pOworI2VuZGlm
CisgICAgcmV0dXJuIGNvbmRpdGlvbjsKK30KKwogI2VuZGlmIC8qIFhFTl9O
T1NQRUNfSCAqLwogCiAvKgpkaWZmIC0tZ2l0IGEveGVuL2luY2x1ZGUveGVu
L3NwaW5sb2NrLmggYi94ZW4vaW5jbHVkZS94ZW4vc3BpbmxvY2suaAppbmRl
eCA5NjE4OTFiZWE0ZDUuLmRhZjQ4ZmRlYTcwOSAxMDA2NDQKLS0tIGEveGVu
L2luY2x1ZGUveGVuL3NwaW5sb2NrLmgKKysrIGIveGVuL2luY2x1ZGUveGVu
L3NwaW5sb2NrLmgKQEAgLTEsNiArMSw3IEBACiAjaWZuZGVmIF9fU1BJTkxP
Q0tfSF9fCiAjZGVmaW5lIF9fU1BJTkxPQ0tfSF9fCiAKKyNpbmNsdWRlIDx4
ZW4vbm9zcGVjLmg+CiAjaW5jbHVkZSA8eGVuL3RpbWUuaD4KICNpbmNsdWRl
IDxhc20vc3lzdGVtLmg+CiAjaW5jbHVkZSA8YXNtL3NwaW5sb2NrLmg+CkBA
IC0xODksMTMgKzE5MCwzMCBAQCBpbnQgX3NwaW5fdHJ5bG9ja19yZWN1cnNp
dmUoc3BpbmxvY2tfdCAqbG9jayk7CiB2b2lkIF9zcGluX2xvY2tfcmVjdXJz
aXZlKHNwaW5sb2NrX3QgKmxvY2spOwogdm9pZCBfc3Bpbl91bmxvY2tfcmVj
dXJzaXZlKHNwaW5sb2NrX3QgKmxvY2spOwogCi0jZGVmaW5lIHNwaW5fbG9j
ayhsKSAgICAgICAgICAgICAgICAgIF9zcGluX2xvY2sobCkKLSNkZWZpbmUg
c3Bpbl9sb2NrX2NiKGwsIGMsIGQpICAgICAgICAgX3NwaW5fbG9ja19jYihs
LCBjLCBkKQotI2RlZmluZSBzcGluX2xvY2tfaXJxKGwpICAgICAgICAgICAg
ICBfc3Bpbl9sb2NrX2lycShsKQorc3RhdGljIGFsd2F5c19pbmxpbmUgdm9p
ZCBzcGluX2xvY2soc3BpbmxvY2tfdCAqbCkKK3sKKyAgICBfc3Bpbl9sb2Nr
KGwpOworICAgIGJsb2NrX2xvY2tfc3BlY3VsYXRpb24oKTsKK30KKworc3Rh
dGljIGFsd2F5c19pbmxpbmUgdm9pZCBzcGluX2xvY2tfY2Ioc3BpbmxvY2tf
dCAqbCwgdm9pZCAoKmMpKHZvaWQgKmRhdGEpLAorICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgdm9pZCAqZCkKK3sKKyAgICBfc3Bp
bl9sb2NrX2NiKGwsIGMsIGQpOworICAgIGJsb2NrX2xvY2tfc3BlY3VsYXRp
b24oKTsKK30KKworc3RhdGljIGFsd2F5c19pbmxpbmUgdm9pZCBzcGluX2xv
Y2tfaXJxKHNwaW5sb2NrX3QgKmwpCit7CisgICAgX3NwaW5fbG9ja19pcnEo
bCk7CisgICAgYmxvY2tfbG9ja19zcGVjdWxhdGlvbigpOworfQorCiAjZGVm
aW5lIHNwaW5fbG9ja19pcnFzYXZlKGwsIGYpICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgXAogICAgICh7ICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKICAgICAg
ICAgQlVJTERfQlVHX09OKHNpemVvZihmKSAhPSBzaXplb2YodW5zaWduZWQg
bG9uZykpOyAgICAgICBcCiAgICAgICAgICgoZikgPSBfc3Bpbl9sb2NrX2ly
cXNhdmUobCkpOyAgICAgICAgICAgICAgICAgICAgICAgICAgXAorICAgICAg
ICBibG9ja19sb2NrX3NwZWN1bGF0aW9uKCk7ICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIFwKICAgICB9KQogCiAjZGVmaW5lIHNwaW5fdW5sb2Nr
KGwpICAgICAgICAgICAgICAgIF9zcGluX3VubG9jayhsKQpAQCAtMjAzLDcg
KzIyMSw3IEBAIHZvaWQgX3NwaW5fdW5sb2NrX3JlY3Vyc2l2ZShzcGlubG9j
a190ICpsb2NrKTsKICNkZWZpbmUgc3Bpbl91bmxvY2tfaXJxcmVzdG9yZShs
LCBmKSAgX3NwaW5fdW5sb2NrX2lycXJlc3RvcmUobCwgZikKIAogI2RlZmlu
ZSBzcGluX2lzX2xvY2tlZChsKSAgICAgICAgICAgICBfc3Bpbl9pc19sb2Nr
ZWQobCkKLSNkZWZpbmUgc3Bpbl90cnlsb2NrKGwpICAgICAgICAgICAgICAg
X3NwaW5fdHJ5bG9jayhsKQorI2RlZmluZSBzcGluX3RyeWxvY2sobCkgICAg
ICAgICAgICAgICBsb2NrX2V2YWx1YXRlX25vc3BlYyhfc3Bpbl90cnlsb2Nr
KGwpKQogCiAjZGVmaW5lIHNwaW5fdHJ5bG9ja19pcnFzYXZlKGxvY2ssIGZs
YWdzKSAgICAgICBcCiAoeyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBcCkBAIC0yMjQsOCArMjQyLDE1IEBAIHZvaWQg
X3NwaW5fdW5sb2NrX3JlY3Vyc2l2ZShzcGlubG9ja190ICpsb2NrKTsKICAq
IGFyZSBhbnkgY3JpdGljYWwgcmVnaW9ucyB0aGF0IGNhbm5vdCBmb3JtIHBh
cnQgb2Ygc3VjaCBhIHNldCwgdGhleSBjYW4gdXNlCiAgKiBzdGFuZGFyZCBz
cGluX1t1bl1sb2NrKCkuCiAgKi8KLSNkZWZpbmUgc3Bpbl90cnlsb2NrX3Jl
Y3Vyc2l2ZShsKSAgICAgX3NwaW5fdHJ5bG9ja19yZWN1cnNpdmUobCkKLSNk
ZWZpbmUgc3Bpbl9sb2NrX3JlY3Vyc2l2ZShsKSAgICAgICAgX3NwaW5fbG9j
a19yZWN1cnNpdmUobCkKKyNkZWZpbmUgc3Bpbl90cnlsb2NrX3JlY3Vyc2l2
ZShsKSBcCisgICAgbG9ja19ldmFsdWF0ZV9ub3NwZWMoX3NwaW5fdHJ5bG9j
a19yZWN1cnNpdmUobCkpCisKK3N0YXRpYyBhbHdheXNfaW5saW5lIHZvaWQg
c3Bpbl9sb2NrX3JlY3Vyc2l2ZShzcGlubG9ja190ICpsKQoreworICAgIF9z
cGluX2xvY2tfcmVjdXJzaXZlKGwpOworICAgIGJsb2NrX2xvY2tfc3BlY3Vs
YXRpb24oKTsKK30KKwogI2RlZmluZSBzcGluX3VubG9ja19yZWN1cnNpdmUo
bCkgICAgICBfc3Bpbl91bmxvY2tfcmVjdXJzaXZlKGwpCiAKICNlbmRpZiAv
KiBfX1NQSU5MT0NLX0hfXyAqLwo=

--=separator
Content-Type: application/octet-stream; name="xsa453/xsa453-4.17-4.patch"
Content-Disposition: attachment; filename="xsa453/xsa453-4.17-4.patch"
Content-Transfer-Encoding: base64

RnJvbTogPT9VVEYtOD9xP1JvZ2VyPTIwUGF1PTIwTW9ubj1DMz1BOT89IDxy
b2dlci5wYXVAY2l0cml4LmNvbT4KU3ViamVjdDogcndsb2NrOiBpbnRyb2R1
Y2Ugc3VwcG9ydCBmb3IgYmxvY2tpbmcgc3BlY3VsYXRpb24gaW50byBjcml0
aWNhbAogcmVnaW9ucwoKSW50cm9kdWNlIGlubGluZSB3cmFwcGVycyBhcyBy
ZXF1aXJlZCBhbmQgYWRkIGRpcmVjdCBjYWxscyB0bwpibG9ja19sb2NrX3Nw
ZWN1bGF0aW9uKCkgaW4gb3JkZXIgdG8gcHJldmVudCBzcGVjdWxhdGlvbiBp
bnRvIHRoZSByd2xvY2sKcHJvdGVjdGVkIGNyaXRpY2FsIHJlZ2lvbnMuCgpO
b3RlIHRoZSByd2xvY2sgcHJpbWl0aXZlcyBhcmUgYWRqdXN0ZWQgdG8gdXNl
IHRoZSBub24gc3BlY3VsYXRpb24gc2FmZSB2YXJpYW50cwpvZiB0aGUgc3Bp
bmxvY2sgaGFuZGxlcnMsIGFzIGEgc3BlY3VsYXRpb24gYmFycmllciBpcyBh
ZGRlZCBpbiB0aGUgcndsb2NrCmNhbGxpbmcgd3JhcHBlcnMuCgp0cnlsb2Nr
IHZhcmlhbnRzIGFyZSBwcm90ZWN0ZWQgYnkgdXNpbmcgbG9ja19ldmFsdWF0
ZV9ub3NwZWMoKS4KClRoaXMgaXMgcGFydCBvZiBYU0EtNDUzIC8gQ1ZFLTIw
MjQtMjE5MwoKU2lnbmVkLW9mZi1ieTogUm9nZXIgUGF1IE1vbm7DqSA8cm9n
ZXIucGF1QGNpdHJpeC5jb20+ClJldmlld2VkLWJ5OiBKYW4gQmV1bGljaCA8
amJldWxpY2hAc3VzZS5jb20+CihjaGVycnkgcGlja2VkIGZyb20gY29tbWl0
IGExZmIxNWY2MTY5MmIxZmE5OTQ1ZmM1MWY1NTQ3MWFjZTQ5Y2RkNTkpCgpk
aWZmIC0tZ2l0IGEveGVuL2NvbW1vbi9yd2xvY2suYyBiL3hlbi9jb21tb24v
cndsb2NrLmMKaW5kZXggYWExNTUyOWJiZThjLi5jZGEwNmI5ZDZlY2UgMTAw
NjQ0Ci0tLSBhL3hlbi9jb21tb24vcndsb2NrLmMKKysrIGIveGVuL2NvbW1v
bi9yd2xvY2suYwpAQCAtMzQsOCArMzQsMTEgQEAgdm9pZCBxdWV1ZV9yZWFk
X2xvY2tfc2xvd3BhdGgocndsb2NrX3QgKmxvY2spCiAKICAgICAvKgogICAg
ICAqIFB1dCB0aGUgcmVhZGVyIGludG8gdGhlIHdhaXQgcXVldWUuCisgICAg
ICoKKyAgICAgKiBVc2UgdGhlIHNwZWN1bGF0aW9uIHVuc2FmZSBoZWxwZXIs
IGFzIGl0J3MgdGhlIGNhbGxlciByZXNwb25zaWJpbGl0eSB0bworICAgICAq
IGlzc3VlIGEgc3BlY3VsYXRpb24gYmFycmllciBpZiByZXF1aXJlZC4KICAg
ICAgKi8KLSAgICBzcGluX2xvY2soJmxvY2stPmxvY2spOworICAgIF9zcGlu
X2xvY2soJmxvY2stPmxvY2spOwogCiAgICAgLyoKICAgICAgKiBBdCB0aGUg
aGVhZCBvZiB0aGUgd2FpdCBxdWV1ZSBub3csIHdhaXQgdW50aWwgdGhlIHdy
aXRlciBzdGF0ZQpAQCAtNjQsOCArNjcsMTMgQEAgdm9pZCBxdWV1ZV93cml0
ZV9sb2NrX3Nsb3dwYXRoKHJ3bG9ja190ICpsb2NrKQogewogICAgIHUzMiBj
bnRzOwogCi0gICAgLyogUHV0IHRoZSB3cml0ZXIgaW50byB0aGUgd2FpdCBx
dWV1ZS4gKi8KLSAgICBzcGluX2xvY2soJmxvY2stPmxvY2spOworICAgIC8q
CisgICAgICogUHV0IHRoZSB3cml0ZXIgaW50byB0aGUgd2FpdCBxdWV1ZS4K
KyAgICAgKgorICAgICAqIFVzZSB0aGUgc3BlY3VsYXRpb24gdW5zYWZlIGhl
bHBlciwgYXMgaXQncyB0aGUgY2FsbGVyIHJlc3BvbnNpYmlsaXR5IHRvCisg
ICAgICogaXNzdWUgYSBzcGVjdWxhdGlvbiBiYXJyaWVyIGlmIHJlcXVpcmVk
LgorICAgICAqLworICAgIF9zcGluX2xvY2soJmxvY2stPmxvY2spOwogCiAg
ICAgLyogVHJ5IHRvIGFjcXVpcmUgdGhlIGxvY2sgZGlyZWN0bHkgaWYgbm8g
cmVhZGVyIGlzIHByZXNlbnQuICovCiAgICAgaWYgKCAhYXRvbWljX3JlYWQo
JmxvY2stPmNudHMpICYmCmRpZmYgLS1naXQgYS94ZW4vaW5jbHVkZS94ZW4v
cndsb2NrLmggYi94ZW4vaW5jbHVkZS94ZW4vcndsb2NrLmgKaW5kZXggMGNj
OTE2NzcxNWIzLi5mZDA0NThiZTk0YWUgMTAwNjQ0Ci0tLSBhL3hlbi9pbmNs
dWRlL3hlbi9yd2xvY2suaAorKysgYi94ZW4vaW5jbHVkZS94ZW4vcndsb2Nr
LmgKQEAgLTI0NywyNyArMjQ3LDQ5IEBAIHN0YXRpYyBpbmxpbmUgaW50IF9y
d19pc193cml0ZV9sb2NrZWQocndsb2NrX3QgKmxvY2spCiAgICAgcmV0dXJu
IChhdG9taWNfcmVhZCgmbG9jay0+Y250cykgJiBfUVdfV01BU0spID09IF9R
V19MT0NLRUQ7CiB9CiAKLSNkZWZpbmUgcmVhZF9sb2NrKGwpICAgICAgICAg
ICAgICAgICAgX3JlYWRfbG9jayhsKQotI2RlZmluZSByZWFkX2xvY2tfaXJx
KGwpICAgICAgICAgICAgICBfcmVhZF9sb2NrX2lycShsKQorc3RhdGljIGFs
d2F5c19pbmxpbmUgdm9pZCByZWFkX2xvY2socndsb2NrX3QgKmwpCit7Cisg
ICAgX3JlYWRfbG9jayhsKTsKKyAgICBibG9ja19sb2NrX3NwZWN1bGF0aW9u
KCk7Cit9CisKK3N0YXRpYyBhbHdheXNfaW5saW5lIHZvaWQgcmVhZF9sb2Nr
X2lycShyd2xvY2tfdCAqbCkKK3sKKyAgICBfcmVhZF9sb2NrX2lycShsKTsK
KyAgICBibG9ja19sb2NrX3NwZWN1bGF0aW9uKCk7Cit9CisKICNkZWZpbmUg
cmVhZF9sb2NrX2lycXNhdmUobCwgZikgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBcCiAgICAgKHsgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAogICAgICAgICBC
VUlMRF9CVUdfT04oc2l6ZW9mKGYpICE9IHNpemVvZih1bnNpZ25lZCBsb25n
KSk7ICAgICAgIFwKICAgICAgICAgKChmKSA9IF9yZWFkX2xvY2tfaXJxc2F2
ZShsKSk7ICAgICAgICAgICAgICAgICAgICAgICAgICBcCisgICAgICAgIGJs
b2NrX2xvY2tfc3BlY3VsYXRpb24oKTsgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgXAogICAgIH0pCiAKICNkZWZpbmUgcmVhZF91bmxvY2sobCkg
ICAgICAgICAgICAgICAgX3JlYWRfdW5sb2NrKGwpCiAjZGVmaW5lIHJlYWRf
dW5sb2NrX2lycShsKSAgICAgICAgICAgIF9yZWFkX3VubG9ja19pcnEobCkK
ICNkZWZpbmUgcmVhZF91bmxvY2tfaXJxcmVzdG9yZShsLCBmKSAgX3JlYWRf
dW5sb2NrX2lycXJlc3RvcmUobCwgZikKLSNkZWZpbmUgcmVhZF90cnlsb2Nr
KGwpICAgICAgICAgICAgICAgX3JlYWRfdHJ5bG9jayhsKQorI2RlZmluZSBy
ZWFkX3RyeWxvY2sobCkgICAgICAgICAgICAgICBsb2NrX2V2YWx1YXRlX25v
c3BlYyhfcmVhZF90cnlsb2NrKGwpKQorCitzdGF0aWMgYWx3YXlzX2lubGlu
ZSB2b2lkIHdyaXRlX2xvY2socndsb2NrX3QgKmwpCit7CisgICAgX3dyaXRl
X2xvY2sobCk7CisgICAgYmxvY2tfbG9ja19zcGVjdWxhdGlvbigpOworfQor
CitzdGF0aWMgYWx3YXlzX2lubGluZSB2b2lkIHdyaXRlX2xvY2tfaXJxKHJ3
bG9ja190ICpsKQoreworICAgIF93cml0ZV9sb2NrX2lycShsKTsKKyAgICBi
bG9ja19sb2NrX3NwZWN1bGF0aW9uKCk7Cit9CiAKLSNkZWZpbmUgd3JpdGVf
bG9jayhsKSAgICAgICAgICAgICAgICAgX3dyaXRlX2xvY2sobCkKLSNkZWZp
bmUgd3JpdGVfbG9ja19pcnEobCkgICAgICAgICAgICAgX3dyaXRlX2xvY2tf
aXJxKGwpCiAjZGVmaW5lIHdyaXRlX2xvY2tfaXJxc2F2ZShsLCBmKSAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgXAogICAgICh7ICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIFwKICAgICAgICAgQlVJTERfQlVHX09OKHNpemVvZihmKSAhPSBzaXpl
b2YodW5zaWduZWQgbG9uZykpOyAgICAgICBcCiAgICAgICAgICgoZikgPSBf
d3JpdGVfbG9ja19pcnFzYXZlKGwpKTsgICAgICAgICAgICAgICAgICAgICAg
ICAgXAorICAgICAgICBibG9ja19sb2NrX3NwZWN1bGF0aW9uKCk7ICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIFwKICAgICB9KQotI2RlZmluZSB3
cml0ZV90cnlsb2NrKGwpICAgICAgICAgICAgICBfd3JpdGVfdHJ5bG9jayhs
KQorI2RlZmluZSB3cml0ZV90cnlsb2NrKGwpICAgICAgICAgICAgICBsb2Nr
X2V2YWx1YXRlX25vc3BlYyhfd3JpdGVfdHJ5bG9jayhsKSkKIAogI2RlZmlu
ZSB3cml0ZV91bmxvY2sobCkgICAgICAgICAgICAgICBfd3JpdGVfdW5sb2Nr
KGwpCiAjZGVmaW5lIHdyaXRlX3VubG9ja19pcnEobCkgICAgICAgICAgIF93
cml0ZV91bmxvY2tfaXJxKGwpCg==

--=separator
Content-Type: application/octet-stream; name="xsa453/xsa453-4.17-5.patch"
Content-Disposition: attachment; filename="xsa453/xsa453-4.17-5.patch"
Content-Transfer-Encoding: base64

RnJvbTogPT9VVEYtOD9xP1JvZ2VyPTIwUGF1PTIwTW9ubj1DMz1BOT89IDxy
b2dlci5wYXVAY2l0cml4LmNvbT4KU3ViamVjdDogcGVyY3B1LXJ3bG9jazog
aW50cm9kdWNlIHN1cHBvcnQgZm9yIGJsb2NraW5nIHNwZWN1bGF0aW9uIGlu
dG8KIGNyaXRpY2FsIHJlZ2lvbnMKCkFkZCBkaXJlY3QgY2FsbHMgdG8gYmxv
Y2tfbG9ja19zcGVjdWxhdGlvbigpIHdoZXJlIHJlcXVpcmVkIGluIG9yZGVy
IHRvIHByZXZlbnQKc3BlY3VsYXRpb24gaW50byB0aGUgbG9jayBwcm90ZWN0
ZWQgY3JpdGljYWwgcmVnaW9ucy4gIEFsc28gY29udmVydApfcGVyY3B1X3Jl
YWRfbG9jaygpIGZyb20gaW5saW5lIHRvIGFsd2F5c19pbmxpbmUuCgpOb3Rl
IHRoYXQgX3BlcmNwdV93cml0ZV9sb2NrKCkgaGFzIGJlZW4gbW9kaWZpZWQg
dGhlIHVzZSB0aGUgbm9uIHNwZWN1bGF0aW9uCnNhZmUgb2YgdGhlIGxvY2tp
bmcgcHJpbWl0ZXMsIGFzIGEgc3BlY3VsYXRpb24gaXMgYWRkZWQgdW5jb25k
aXRpb25hbGx5IGJ5IHRoZQpjYWxsaW5nIHdyYXBwZXIuCgpUaGlzIGlzIHBh
cnQgb2YgWFNBLTQ1MyAvIENWRS0yMDI0LTIxOTMKClNpZ25lZC1vZmYtYnk6
IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXguY29tPgpSZXZp
ZXdlZC1ieTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgooY2hl
cnJ5IHBpY2tlZCBmcm9tIGNvbW1pdCBmMjE4ZGFmNmQzYTNiODQ3NzM2ZDM3
YzZhNmI3NjAzMWEwZDA4NDQxKQoKZGlmZiAtLWdpdCBhL3hlbi9jb21tb24v
cndsb2NrLmMgYi94ZW4vY29tbW9uL3J3bG9jay5jCmluZGV4IGNkYTA2Yjlk
NmVjZS4uNGRhMGVkOGZhZGIwIDEwMDY0NAotLS0gYS94ZW4vY29tbW9uL3J3
bG9jay5jCisrKyBiL3hlbi9jb21tb24vcndsb2NrLmMKQEAgLTEyNSw4ICsx
MjUsMTIgQEAgdm9pZCBfcGVyY3B1X3dyaXRlX2xvY2socGVyY3B1X3J3bG9j
a190ICoqcGVyX2NwdWRhdGEsCiAgICAgLyoKICAgICAgKiBGaXJzdCB0YWtl
IHRoZSB3cml0ZSBsb2NrIHRvIHByb3RlY3QgYWdhaW5zdCBvdGhlciB3cml0
ZXJzIG9yIHNsb3cKICAgICAgKiBwYXRoIHJlYWRlcnMuCisgICAgICoKKyAg
ICAgKiBOb3RlIHdlIHVzZSB0aGUgc3BlY3VsYXRpb24gdW5zYWZlIHZhcmlh
bnQgb2Ygd3JpdGVfbG9jaygpLCBhcyB0aGUKKyAgICAgKiBjYWxsaW5nIHdy
YXBwZXIgYWxyZWFkeSBhZGRzIGEgc3BlY3VsYXRpb24gYmFycmllciBhZnRl
ciB0aGUgbG9jayBoYXMKKyAgICAgKiBiZWVuIHRha2VuLgogICAgICAqLwot
ICAgIHdyaXRlX2xvY2soJnBlcmNwdV9yd2xvY2stPnJ3bG9jayk7CisgICAg
X3dyaXRlX2xvY2soJnBlcmNwdV9yd2xvY2stPnJ3bG9jayk7CiAKICAgICAv
KiBOb3cgc2V0IHRoZSBnbG9iYWwgdmFyaWFibGUgc28gdGhhdCByZWFkZXJz
IHN0YXJ0IHVzaW5nIHJlYWRfbG9jay4gKi8KICAgICBwZXJjcHVfcndsb2Nr
LT53cml0ZXJfYWN0aXZhdGluZyA9IDE7CmRpZmYgLS1naXQgYS94ZW4vaW5j
bHVkZS94ZW4vcndsb2NrLmggYi94ZW4vaW5jbHVkZS94ZW4vcndsb2NrLmgK
aW5kZXggZmQwNDU4YmU5NGFlLi5hYmUwODA0YmY3ZDUgMTAwNjQ0Ci0tLSBh
L3hlbi9pbmNsdWRlL3hlbi9yd2xvY2suaAorKysgYi94ZW4vaW5jbHVkZS94
ZW4vcndsb2NrLmgKQEAgLTMyNiw4ICszMjYsOCBAQCBzdGF0aWMgaW5saW5l
IHZvaWQgX3BlcmNwdV9yd2xvY2tfb3duZXJfY2hlY2socGVyY3B1X3J3bG9j
a190ICoqcGVyX2NwdWRhdGEsCiAjZGVmaW5lIHBlcmNwdV9yd2xvY2tfcmVz
b3VyY2VfaW5pdChsLCBvd25lcikgXAogICAgICgqKGwpID0gKHBlcmNwdV9y
d2xvY2tfdClQRVJDUFVfUldfTE9DS19VTkxPQ0tFRCgmZ2V0X3Blcl9jcHVf
dmFyKG93bmVyKSkpCiAKLXN0YXRpYyBpbmxpbmUgdm9pZCBfcGVyY3B1X3Jl
YWRfbG9jayhwZXJjcHVfcndsb2NrX3QgKipwZXJfY3B1ZGF0YSwKLSAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcGVyY3B1X3J3
bG9ja190ICpwZXJjcHVfcndsb2NrKQorc3RhdGljIGFsd2F5c19pbmxpbmUg
dm9pZCBfcGVyY3B1X3JlYWRfbG9jayhwZXJjcHVfcndsb2NrX3QgKipwZXJf
Y3B1ZGF0YSwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgcGVyY3B1X3J3bG9ja190ICpwZXJjcHVfcndsb2NrKQogewog
ICAgIC8qIFZhbGlkYXRlIHRoZSBjb3JyZWN0IHBlcl9jcHVkYXRhIHZhcmlh
YmxlIGhhcyBiZWVuIHByb3ZpZGVkLiAqLwogICAgIF9wZXJjcHVfcndsb2Nr
X293bmVyX2NoZWNrKHBlcl9jcHVkYXRhLCBwZXJjcHVfcndsb2NrKTsKQEAg
LTM2Miw2ICszNjIsOCBAQCBzdGF0aWMgaW5saW5lIHZvaWQgX3BlcmNwdV9y
ZWFkX2xvY2socGVyY3B1X3J3bG9ja190ICoqcGVyX2NwdWRhdGEsCiAgICAg
fQogICAgIGVsc2UKICAgICB7CisgICAgICAgIC8qIE90aGVyIGJyYW5jaCBh
bHJlYWR5IGhhcyBhIHNwZWN1bGF0aW9uIGJhcnJpZXIgaW4gcmVhZF9sb2Nr
KCkuICovCisgICAgICAgIGJsb2NrX2xvY2tfc3BlY3VsYXRpb24oKTsKICAg
ICAgICAgLyogQWxsIG90aGVyIHBhdGhzIGhhdmUgaW1wbGljaXQgY2hlY2tf
bG9jaygpIGNhbGxzIHZpYSByZWFkX2xvY2soKS4gKi8KICAgICAgICAgY2hl
Y2tfbG9jaygmcGVyY3B1X3J3bG9jay0+cndsb2NrLmxvY2suZGVidWcsIGZh
bHNlKTsKICAgICB9CkBAIC00MTAsOCArNDEyLDEyIEBAIHN0YXRpYyBpbmxp
bmUgdm9pZCBfcGVyY3B1X3dyaXRlX3VubG9jayhwZXJjcHVfcndsb2NrX3Qg
KipwZXJfY3B1ZGF0YSwKICAgICBfcGVyY3B1X3JlYWRfbG9jaygmZ2V0X3Bl
cl9jcHVfdmFyKHBlcmNwdSksIGxvY2spCiAjZGVmaW5lIHBlcmNwdV9yZWFk
X3VubG9jayhwZXJjcHUsIGxvY2spIFwKICAgICBfcGVyY3B1X3JlYWRfdW5s
b2NrKCZnZXRfcGVyX2NwdV92YXIocGVyY3B1KSwgbG9jaykKLSNkZWZpbmUg
cGVyY3B1X3dyaXRlX2xvY2socGVyY3B1LCBsb2NrKSBcCi0gICAgX3BlcmNw
dV93cml0ZV9sb2NrKCZnZXRfcGVyX2NwdV92YXIocGVyY3B1KSwgbG9jaykK
KworI2RlZmluZSBwZXJjcHVfd3JpdGVfbG9jayhwZXJjcHUsIGxvY2spICAg
ICAgICAgICAgICAgICBcCisoeyAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKKyAgICBfcGVyY3B1X3dy
aXRlX2xvY2soJmdldF9wZXJfY3B1X3ZhcihwZXJjcHUpLCBsb2NrKTsgXAor
ICAgIGJsb2NrX2xvY2tfc3BlY3VsYXRpb24oKTsgICAgICAgICAgICAgICAg
ICAgICAgICAgICBcCit9KQogI2RlZmluZSBwZXJjcHVfd3JpdGVfdW5sb2Nr
KHBlcmNwdSwgbG9jaykgXAogICAgIF9wZXJjcHVfd3JpdGVfdW5sb2NrKCZn
ZXRfcGVyX2NwdV92YXIocGVyY3B1KSwgbG9jaykKIAo=

--=separator
Content-Type: application/octet-stream; name="xsa453/xsa453-4.17-6.patch"
Content-Disposition: attachment; filename="xsa453/xsa453-4.17-6.patch"
Content-Transfer-Encoding: base64

RnJvbTogPT9VVEYtOD9xP1JvZ2VyPTIwUGF1PTIwTW9ubj1DMz1BOT89IDxy
b2dlci5wYXVAY2l0cml4LmNvbT4KU3ViamVjdDogbG9ja2luZzogYXR0ZW1w
dCB0byBlbnN1cmUgbG9jayB3cmFwcGVycyBhcmUgYWx3YXlzIGlubGluZQoK
SW4gb3JkZXIgdG8gcHJldmVudCB0aGUgbG9ja2luZyBzcGVjdWxhdGlvbiBi
YXJyaWVycyBmcm9tIGJlaW5nIGluc2lkZSBvZgpgY2FsbGBlZCBmdW5jdGlv
bnMgdGhhdCBjb3VsZCBiZSBzcGVjdWxhdGl2ZWx5IGJ5cGFzc2VkLgoKV2hp
bGUgdGhlcmUgYWxzbyBhZGQgYW4gZXh0cmEgbG9ja2luZyBiYXJyaWVyIHRv
IF9tbV93cml0ZV9sb2NrKCkgaW4gdGhlIGJyYW5jaAp0YWtlbiB3aGVuIHRo
ZSBsb2NrIGlzIGFscmVhZHkgaGVsZC4KCk5vdGUgc29tZSBmdW5jdGlvbnMg
YXJlIHN3aXRjaGVkIHRvIHVzZSB0aGUgdW5zYWZlIHZhcmlhbnRzICh3aXRo
b3V0IHNwZWN1bGF0aW9uCmJhcnJpZXIpIG9mIHRoZSBsb2NraW5nIHByaW1p
dGl2ZXMsIGJ1dCBhIHNwZWN1bGF0aW9uIGJhcnJpZXIgaXMgYWx3YXlzIGFk
ZGVkCnRvIHRoZSBleHBvc2VkIHB1YmxpYyBsb2NrIHdyYXBwaW5nIGhlbHBl
ci4gIFRoYXQncyB0aGUgY2FzZSB3aXRoCnNjaGVkX3NwaW5fbG9ja19kb3Vi
bGUoKSBvciBwY2lkZXZzX2xvY2soKSBmb3IgZXhhbXBsZS4KClRoaXMgaXMg
cGFydCBvZiBYU0EtNDUzIC8gQ1ZFLTIwMjQtMjE5MwoKU2lnbmVkLW9mZi1i
eTogUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5jb20+ClJl
dmlld2VkLWJ5OiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+Cihj
aGVycnkgcGlja2VkIGZyb20gY29tbWl0IDE5N2VjZDgzOGEyYWFmOTU5YTQ2
OWRmMzY5NmQ0NTU5YzRmOGI3NjIpCgpkaWZmIC0tZ2l0IGEveGVuL2FyY2gv
eDg2L2h2bS92cHQuYyBiL3hlbi9hcmNoL3g4Ni9odm0vdnB0LmMKaW5kZXgg
Y2IxZDgxYmY5ZTgyLi42NmYxMDk1MjQ1NmIgMTAwNjQ0Ci0tLSBhL3hlbi9h
cmNoL3g4Ni9odm0vdnB0LmMKKysrIGIveGVuL2FyY2gveDg2L2h2bS92cHQu
YwpAQCAtMTYxLDcgKzE2MSw3IEBAIHN0YXRpYyBpbnQgcHRfaXJxX21hc2tl
ZChzdHJ1Y3QgcGVyaW9kaWNfdGltZSAqcHQpCiAgKiBwdC0+dmNwdSBmaWVs
ZCwgYmVjYXVzZSBhbm90aGVyIHRocmVhZCBob2xkaW5nIHRoZSBwdF9taWdy
YXRlIGxvY2sKICAqIG1heSBhbHJlYWR5IGJlIHNwaW5uaW5nIHdhaXRpbmcg
Zm9yIHlvdXIgdmNwdSBsb2NrLgogICovCi1zdGF0aWMgdm9pZCBwdF92Y3B1
X2xvY2soc3RydWN0IHZjcHUgKnYpCitzdGF0aWMgYWx3YXlzX2lubGluZSB2
b2lkIHB0X3ZjcHVfbG9jayhzdHJ1Y3QgdmNwdSAqdikKIHsKICAgICBzcGlu
X2xvY2soJnYtPmFyY2guaHZtLnRtX2xvY2spOwogfQpAQCAtMTgwLDkgKzE4
MCwxMyBAQCBzdGF0aWMgdm9pZCBwdF92Y3B1X3VubG9jayhzdHJ1Y3QgdmNw
dSAqdikKICAqIG5lZWQgdG8gdGFrZSBhbiBhZGRpdGlvbmFsIGxvY2sgdGhh
dCBwcm90ZWN0cyBhZ2FpbnN0IHB0LT52Y3B1CiAgKiBjaGFuZ2luZy4KICAq
Lwotc3RhdGljIHZvaWQgcHRfbG9jayhzdHJ1Y3QgcGVyaW9kaWNfdGltZSAq
cHQpCitzdGF0aWMgYWx3YXlzX2lubGluZSB2b2lkIHB0X2xvY2soc3RydWN0
IHBlcmlvZGljX3RpbWUgKnB0KQogewotICAgIHJlYWRfbG9jaygmcHQtPnZj
cHUtPmRvbWFpbi0+YXJjaC5odm0ucGxfdGltZS0+cHRfbWlncmF0ZSk7Cisg
ICAgLyoKKyAgICAgKiBVc2UgdGhlIHNwZWN1bGF0aW9uIHVuc2FmZSB2YXJp
YW50IGZvciB0aGUgZmlyc3QgbG9jaywgYXMgdGhlIGZvbGxvd2luZworICAg
ICAqIGxvY2sgdGFraW5nIGhlbHBlciBhbHJlYWR5IGluY2x1ZGVzIGEgc3Bl
Y3VsYXRpb24gYmFycmllci4KKyAgICAgKi8KKyAgICBfcmVhZF9sb2NrKCZw
dC0+dmNwdS0+ZG9tYWluLT5hcmNoLmh2bS5wbF90aW1lLT5wdF9taWdyYXRl
KTsKICAgICBzcGluX2xvY2soJnB0LT52Y3B1LT5hcmNoLmh2bS50bV9sb2Nr
KTsKIH0KIApkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNt
L2lycS5oIGIveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2lycS5oCmluZGV4
IGY2YTAyMDdhODA4Ny4uODIzZDYyN2ZkMDAxIDEwMDY0NAotLS0gYS94ZW4v
YXJjaC94ODYvaW5jbHVkZS9hc20vaXJxLmgKKysrIGIveGVuL2FyY2gveDg2
L2luY2x1ZGUvYXNtL2lycS5oCkBAIC0xNzgsNiArMTc4LDcgQEAgdm9pZCBj
Zl9jaGVjayBpcnFfY29tcGxldGVfbW92ZShzdHJ1Y3QgaXJxX2Rlc2MgKik7
CiAKIGV4dGVybiBzdHJ1Y3QgaXJxX2Rlc2MgKmlycV9kZXNjOwogCisvKiBO
b3Qgc3BlY3VsYXRpb24gc2FmZSwgb25seSB1c2VkIGZvciBBUCBicmluZ3Vw
LiAqLwogdm9pZCBsb2NrX3ZlY3Rvcl9sb2NrKHZvaWQpOwogdm9pZCB1bmxv
Y2tfdmVjdG9yX2xvY2sodm9pZCk7CiAKZGlmZiAtLWdpdCBhL3hlbi9hcmNo
L3g4Ni9tbS9tbS1sb2Nrcy5oIGIveGVuL2FyY2gveDg2L21tL21tLWxvY2tz
LmgKaW5kZXggYzE1MjNhZWNjZjk5Li4yNjUyMzljNDlmMzkgMTAwNjQ0Ci0t
LSBhL3hlbi9hcmNoL3g4Ni9tbS9tbS1sb2Nrcy5oCisrKyBiL3hlbi9hcmNo
L3g4Ni9tbS9tbS1sb2Nrcy5oCkBAIC04Niw4ICs4Niw4IEBAIHN0YXRpYyBp
bmxpbmUgdm9pZCBfc2V0X2xvY2tfbGV2ZWwoaW50IGwpCiAgICAgdGhpc19j
cHUobW1fbG9ja19sZXZlbCkgPSBsOwogfQogCi1zdGF0aWMgaW5saW5lIHZv
aWQgX21tX2xvY2soY29uc3Qgc3RydWN0IGRvbWFpbiAqZCwgbW1fbG9ja190
ICpsLAotICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IGNoYXIg
KmZ1bmMsIGludCBsZXZlbCwgaW50IHJlYykKK3N0YXRpYyBhbHdheXNfaW5s
aW5lIHZvaWQgX21tX2xvY2soY29uc3Qgc3RydWN0IGRvbWFpbiAqZCwgbW1f
bG9ja190ICpsLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBjb25zdCBjaGFyICpmdW5jLCBpbnQgbGV2ZWwsIGludCByZWMpCiB7CiAg
ICAgaWYgKCAhKChtbV9sb2NrZWRfYnlfbWUobCkpICYmIHJlYykgKQogICAg
ICAgICBfY2hlY2tfbG9ja19sZXZlbChkLCBsZXZlbCk7CkBAIC0xMzcsOCAr
MTM3LDggQEAgc3RhdGljIGlubGluZSBpbnQgbW1fd3JpdGVfbG9ja2VkX2J5
X21lKG1tX3J3bG9ja190ICpsKQogICAgIHJldHVybiAobC0+bG9ja2VyID09
IGdldF9wcm9jZXNzb3JfaWQoKSk7CiB9CiAKLXN0YXRpYyBpbmxpbmUgdm9p
ZCBfbW1fd3JpdGVfbG9jayhjb25zdCBzdHJ1Y3QgZG9tYWluICpkLCBtbV9y
d2xvY2tfdCAqbCwKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBjb25zdCBjaGFyICpmdW5jLCBpbnQgbGV2ZWwpCitzdGF0aWMgYWx3YXlz
X2lubGluZSB2b2lkIF9tbV93cml0ZV9sb2NrKGNvbnN0IHN0cnVjdCBkb21h
aW4gKmQsIG1tX3J3bG9ja190ICpsLAorICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBjb25zdCBjaGFyICpmdW5jLCBpbnQgbGV2
ZWwpCiB7CiAgICAgaWYgKCAhbW1fd3JpdGVfbG9ja2VkX2J5X21lKGwpICkK
ICAgICB7CkBAIC0xNDksNiArMTQ5LDggQEAgc3RhdGljIGlubGluZSB2b2lk
IF9tbV93cml0ZV9sb2NrKGNvbnN0IHN0cnVjdCBkb21haW4gKmQsIG1tX3J3
bG9ja190ICpsLAogICAgICAgICBsLT51bmxvY2tfbGV2ZWwgPSBfZ2V0X2xv
Y2tfbGV2ZWwoKTsKICAgICAgICAgX3NldF9sb2NrX2xldmVsKF9sb2NrX2xl
dmVsKGQsIGxldmVsKSk7CiAgICAgfQorICAgIGVsc2UKKyAgICAgICAgYmxv
Y2tfc3BlY3VsYXRpb24oKTsKICAgICBsLT5yZWN1cnNlX2NvdW50Kys7CiB9
CiAKQEAgLTE2Miw4ICsxNjQsOCBAQCBzdGF0aWMgaW5saW5lIHZvaWQgbW1f
d3JpdGVfdW5sb2NrKG1tX3J3bG9ja190ICpsKQogICAgIHBlcmNwdV93cml0
ZV91bmxvY2socDJtX3BlcmNwdV9yd2xvY2ssICZsLT5sb2NrKTsKIH0KIAot
c3RhdGljIGlubGluZSB2b2lkIF9tbV9yZWFkX2xvY2soY29uc3Qgc3RydWN0
IGRvbWFpbiAqZCwgbW1fcndsb2NrX3QgKmwsCi0gICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBpbnQgbGV2ZWwpCitzdGF0aWMgYWx3YXlzX2lu
bGluZSB2b2lkIF9tbV9yZWFkX2xvY2soY29uc3Qgc3RydWN0IGRvbWFpbiAq
ZCwgbW1fcndsb2NrX3QgKmwsCisgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgaW50IGxldmVsKQogewogICAgIF9jaGVja19sb2Nr
X2xldmVsKGQsIGxldmVsKTsKICAgICBwZXJjcHVfcmVhZF9sb2NrKHAybV9w
ZXJjcHVfcndsb2NrLCAmbC0+bG9jayk7CkBAIC0xNzgsMTUgKzE4MCwxNSBA
QCBzdGF0aWMgaW5saW5lIHZvaWQgbW1fcmVhZF91bmxvY2sobW1fcndsb2Nr
X3QgKmwpCiAKIC8qIFRoaXMgd3JhcHBlciB1c2VzIHRoZSBsaW5lIG51bWJl
ciB0byBleHByZXNzIHRoZSBsb2NraW5nIG9yZGVyIGJlbG93ICovCiAjZGVm
aW5lIGRlY2xhcmVfbW1fbG9jayhuYW1lKSAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCi0gICAgc3RhdGljIGlu
bGluZSB2b2lkIG1tX2xvY2tfIyNuYW1lKGNvbnN0IHN0cnVjdCBkb21haW4g
KmQsIG1tX2xvY2tfdCAqbCwgICBcCi0gICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIGNvbnN0IGNoYXIgKmZ1bmMsIGludCByZWMpICAg
ICAgICAgICAgICBcCisgICAgc3RhdGljIGFsd2F5c19pbmxpbmUgdm9pZCBt
bV9sb2NrXyMjbmFtZSggICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBcCisgICAgICAgIGNvbnN0IHN0cnVjdCBkb21haW4gKmQsIG1tX2xvY2tf
dCAqbCwgY29uc3QgY2hhciAqZnVuYywgaW50IHJlYykgICAgICBcCiAgICAg
eyBfbW1fbG9jayhkLCBsLCBmdW5jLCBNTV9MT0NLX09SREVSXyMjbmFtZSwg
cmVjKTsgfQogI2RlZmluZSBkZWNsYXJlX21tX3J3bG9jayhuYW1lKSAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAot
ICAgIHN0YXRpYyBpbmxpbmUgdm9pZCBtbV93cml0ZV9sb2NrXyMjbmFtZShj
b25zdCBzdHJ1Y3QgZG9tYWluICpkLCAgICAgICAgICAgXAotICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtbV9yd2xvY2tf
dCAqbCwgY29uc3QgY2hhciAqZnVuYykgXAorICAgIHN0YXRpYyBhbHdheXNf
aW5saW5lIHZvaWQgbW1fd3JpdGVfbG9ja18jI25hbWUoICAgICAgICAgICAg
ICAgICAgICAgICAgICAgXAorICAgICAgICBjb25zdCBzdHJ1Y3QgZG9tYWlu
ICpkLCBtbV9yd2xvY2tfdCAqbCwgY29uc3QgY2hhciAqZnVuYykgICAgICAg
ICAgICAgXAogICAgIHsgX21tX3dyaXRlX2xvY2soZCwgbCwgZnVuYywgTU1f
TE9DS19PUkRFUl8jI25hbWUpOyB9ICAgICAgICAgICAgICAgICAgICAgXAot
ICAgIHN0YXRpYyBpbmxpbmUgdm9pZCBtbV9yZWFkX2xvY2tfIyNuYW1lKGNv
bnN0IHN0cnVjdCBkb21haW4gKmQsICAgICAgICAgICAgXAotICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1tX3J3bG9ja190
ICpsKSAgICAgICAgICAgICAgICAgICAgXAorICAgIHN0YXRpYyBhbHdheXNf
aW5saW5lIHZvaWQgbW1fcmVhZF9sb2NrXyMjbmFtZShjb25zdCBzdHJ1Y3Qg
ZG9tYWluICpkLCAgICAgXAorICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBtbV9yd2xvY2tfdCAqbCkgICAgICAg
ICAgICAgXAogICAgIHsgX21tX3JlYWRfbG9jayhkLCBsLCBNTV9MT0NLX09S
REVSXyMjbmFtZSk7IH0KIC8qIFRoZXNlIGNhcHR1cmUgdGhlIG5hbWUgb2Yg
dGhlIGNhbGxpbmcgZnVuY3Rpb24gKi8KICNkZWZpbmUgbW1fbG9jayhuYW1l
LCBkLCBsKSBtbV9sb2NrXyMjbmFtZShkLCBsLCBfX2Z1bmNfXywgMCkKQEAg
LTMyMSw3ICszMjMsNyBAQCBkZWNsYXJlX21tX2xvY2soYWx0cDJtbGlzdCkK
ICNkZWZpbmUgTU1fTE9DS19PUkRFUl9hbHRwMm0gICAgICAgICAgICAgICAg
IDQwCiBkZWNsYXJlX21tX3J3bG9jayhhbHRwMm0pOwogCi1zdGF0aWMgaW5s
aW5lIHZvaWQgcDJtX2xvY2soc3RydWN0IHAybV9kb21haW4gKnApCitzdGF0
aWMgYWx3YXlzX2lubGluZSB2b2lkIHAybV9sb2NrKHN0cnVjdCBwMm1fZG9t
YWluICpwKQogewogICAgIGlmICggcDJtX2lzX2FsdHAybShwKSApCiAgICAg
ICAgIG1tX3dyaXRlX2xvY2soYWx0cDJtLCBwLT5kb21haW4sICZwLT5sb2Nr
KTsKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9tbS9wMm0tcG9kLmMgYi94
ZW4vYXJjaC94ODYvbW0vcDJtLXBvZC5jCmluZGV4IGZjMTEwNTA2ZGNlMi4u
OTlkYmNiMzEwMWUyIDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYvbW0vcDJt
LXBvZC5jCisrKyBiL3hlbi9hcmNoL3g4Ni9tbS9wMm0tcG9kLmMKQEAgLTM2
LDcgKzM2LDcgQEAKICNkZWZpbmUgc3VwZXJwYWdlX2FsaWduZWQoX3gpICAo
KChfeCkmKFNVUEVSUEFHRV9QQUdFUy0xKSk9PTApCiAKIC8qIEVuZm9yY2Ug
bG9jayBvcmRlcmluZyB3aGVuIGdyYWJiaW5nIHRoZSAiZXh0ZXJuYWwiIHBh
Z2VfYWxsb2MgbG9jayAqLwotc3RhdGljIGlubGluZSB2b2lkIGxvY2tfcGFn
ZV9hbGxvYyhzdHJ1Y3QgcDJtX2RvbWFpbiAqcDJtKQorc3RhdGljIGFsd2F5
c19pbmxpbmUgdm9pZCBsb2NrX3BhZ2VfYWxsb2Moc3RydWN0IHAybV9kb21h
aW4gKnAybSkKIHsKICAgICBwYWdlX2FsbG9jX21tX3ByZV9sb2NrKHAybS0+
ZG9tYWluKTsKICAgICBzcGluX2xvY2soJihwMm0tPmRvbWFpbi0+cGFnZV9h
bGxvY19sb2NrKSk7CmRpZmYgLS1naXQgYS94ZW4vY29tbW9uL2V2ZW50X2No
YW5uZWwuYyBiL3hlbi9jb21tb24vZXZlbnRfY2hhbm5lbC5jCmluZGV4IGY1
ZTBiMTJkMTUyMC4uZGFkYTlmMTVmNTc0IDEwMDY0NAotLS0gYS94ZW4vY29t
bW9uL2V2ZW50X2NoYW5uZWwuYworKysgYi94ZW4vY29tbW9uL2V2ZW50X2No
YW5uZWwuYwpAQCAtNjIsNyArNjIsNyBAQAogICoganVzdCBhc3N1bWUgdGhl
IGV2ZW50IGNoYW5uZWwgaXMgZnJlZSBvciB1bmJvdW5kIGF0IHRoZSBtb21l
bnQgd2hlbiB0aGUKICAqIGV2dGNobl9yZWFkX3RyeWxvY2soKSByZXR1cm5z
IGZhbHNlLgogICovCi1zdGF0aWMgaW5saW5lIHZvaWQgZXZ0Y2huX3dyaXRl
X2xvY2soc3RydWN0IGV2dGNobiAqZXZ0Y2huKQorc3RhdGljIGFsd2F5c19p
bmxpbmUgdm9pZCBldnRjaG5fd3JpdGVfbG9jayhzdHJ1Y3QgZXZ0Y2huICpl
dnRjaG4pCiB7CiAgICAgd3JpdGVfbG9jaygmZXZ0Y2huLT5sb2NrKTsKIApA
QCAtMzY0LDcgKzM2NCw4IEBAIGludCBldnRjaG5fYWxsb2NfdW5ib3VuZChl
dnRjaG5fYWxsb2NfdW5ib3VuZF90ICphbGxvYywgZXZ0Y2huX3BvcnRfdCBw
b3J0KQogICAgIHJldHVybiByYzsKIH0KIAotc3RhdGljIHZvaWQgZG91Ymxl
X2V2dGNobl9sb2NrKHN0cnVjdCBldnRjaG4gKmxjaG4sIHN0cnVjdCBldnRj
aG4gKnJjaG4pCitzdGF0aWMgYWx3YXlzX2lubGluZSB2b2lkIGRvdWJsZV9l
dnRjaG5fbG9jayhzdHJ1Y3QgZXZ0Y2huICpsY2huLAorICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3RydWN0IGV2dGNo
biAqcmNobikKIHsKICAgICBBU1NFUlQobGNobiAhPSByY2huKTsKIApkaWZm
IC0tZ2l0IGEveGVuL2NvbW1vbi9ncmFudF90YWJsZS5jIGIveGVuL2NvbW1v
bi9ncmFudF90YWJsZS5jCmluZGV4IGVlN2NjNDk2YjhjYi4uNjJhODY4NWNk
NTE0IDEwMDY0NAotLS0gYS94ZW4vY29tbW9uL2dyYW50X3RhYmxlLmMKKysr
IGIveGVuL2NvbW1vbi9ncmFudF90YWJsZS5jCkBAIC00MTAsNyArNDEwLDcg
QEAgc3RhdGljIGlubGluZSB2b2lkIGFjdF9zZXRfZ2ZuKHN0cnVjdCBhY3Rp
dmVfZ3JhbnRfZW50cnkgKmFjdCwgZ2ZuX3QgZ2ZuKQogCiBzdGF0aWMgREVG
SU5FX1BFUkNQVV9SV0xPQ0tfR0xPQkFMKGdyYW50X3J3bG9jayk7CiAKLXN0
YXRpYyBpbmxpbmUgdm9pZCBncmFudF9yZWFkX2xvY2soc3RydWN0IGdyYW50
X3RhYmxlICpndCkKK3N0YXRpYyBhbHdheXNfaW5saW5lIHZvaWQgZ3JhbnRf
cmVhZF9sb2NrKHN0cnVjdCBncmFudF90YWJsZSAqZ3QpCiB7CiAgICAgcGVy
Y3B1X3JlYWRfbG9jayhncmFudF9yd2xvY2ssICZndC0+bG9jayk7CiB9CkBA
IC00MjAsNyArNDIwLDcgQEAgc3RhdGljIGlubGluZSB2b2lkIGdyYW50X3Jl
YWRfdW5sb2NrKHN0cnVjdCBncmFudF90YWJsZSAqZ3QpCiAgICAgcGVyY3B1
X3JlYWRfdW5sb2NrKGdyYW50X3J3bG9jaywgJmd0LT5sb2NrKTsKIH0KIAot
c3RhdGljIGlubGluZSB2b2lkIGdyYW50X3dyaXRlX2xvY2soc3RydWN0IGdy
YW50X3RhYmxlICpndCkKK3N0YXRpYyBhbHdheXNfaW5saW5lIHZvaWQgZ3Jh
bnRfd3JpdGVfbG9jayhzdHJ1Y3QgZ3JhbnRfdGFibGUgKmd0KQogewogICAg
IHBlcmNwdV93cml0ZV9sb2NrKGdyYW50X3J3bG9jaywgJmd0LT5sb2NrKTsK
IH0KQEAgLTQ1Nyw3ICs0NTcsNyBAQCBucl9hY3RpdmVfZ3JhbnRfZnJhbWVz
KHN0cnVjdCBncmFudF90YWJsZSAqZ3QpCiAgICAgcmV0dXJuIG51bV9hY3Rf
ZnJhbWVzX2Zyb21fc2hhX2ZyYW1lcyhucl9ncmFudF9mcmFtZXMoZ3QpKTsK
IH0KIAotc3RhdGljIGlubGluZSBzdHJ1Y3QgYWN0aXZlX2dyYW50X2VudHJ5
ICoKK3N0YXRpYyBhbHdheXNfaW5saW5lIHN0cnVjdCBhY3RpdmVfZ3JhbnRf
ZW50cnkgKgogYWN0aXZlX2VudHJ5X2FjcXVpcmUoc3RydWN0IGdyYW50X3Rh
YmxlICp0LCBncmFudF9yZWZfdCBlKQogewogICAgIHN0cnVjdCBhY3RpdmVf
Z3JhbnRfZW50cnkgKmFjdDsKZGlmZiAtLWdpdCBhL3hlbi9jb21tb24vc2No
ZWQvY29yZS5jIGIveGVuL2NvbW1vbi9zY2hlZC9jb3JlLmMKaW5kZXggMDc4
YmViMWFkYmJkLi4yOWJiYWI1YWM2ZmQgMTAwNjQ0Ci0tLSBhL3hlbi9jb21t
b24vc2NoZWQvY29yZS5jCisrKyBiL3hlbi9jb21tb24vc2NoZWQvY29yZS5j
CkBAIC0zNDgsMjMgKzM0OCwyOCBAQCB1aW50NjRfdCBnZXRfY3B1X2lkbGVf
dGltZSh1bnNpZ25lZCBpbnQgY3B1KQogICogVGhpcyBhdm9pZHMgZGVhZC0g
b3IgbGl2ZS1sb2NrcyB3aGVuIHRoaXMgY29kZSBpcyBydW5uaW5nIG9uIGJv
dGgKICAqIGNwdXMgYXQgdGhlIHNhbWUgdGltZS4KICAqLwotc3RhdGljIHZv
aWQgc2NoZWRfc3Bpbl9sb2NrX2RvdWJsZShzcGlubG9ja190ICpsb2NrMSwg
c3BpbmxvY2tfdCAqbG9jazIsCi0gICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIHVuc2lnbmVkIGxvbmcgKmZsYWdzKQorc3RhdGljIGFsd2F5
c19pbmxpbmUgdm9pZCBzY2hlZF9zcGluX2xvY2tfZG91YmxlKAorICAgIHNw
aW5sb2NrX3QgKmxvY2sxLCBzcGlubG9ja190ICpsb2NrMiwgdW5zaWduZWQg
bG9uZyAqZmxhZ3MpCiB7CisgICAgLyoKKyAgICAgKiBJbiBvcmRlciB0byBh
dm9pZCBleHRyYSBvdmVyaGVhZCwgdXNlIHRoZSBsb2NraW5nIHByaW1pdGl2
ZXMgd2l0aG91dCB0aGUKKyAgICAgKiBzcGVjdWxhdGlvbiBiYXJyaWVyLCBh
bmQgaW50cm9kdWNlIGEgc2luZ2xlIGJhcnJpZXIgaGVyZS4KKyAgICAgKi8K
ICAgICBpZiAoIGxvY2sxID09IGxvY2syICkKICAgICB7Ci0gICAgICAgIHNw
aW5fbG9ja19pcnFzYXZlKGxvY2sxLCAqZmxhZ3MpOworICAgICAgICAqZmxh
Z3MgPSBfc3Bpbl9sb2NrX2lycXNhdmUobG9jazEpOwogICAgIH0KICAgICBl
bHNlIGlmICggbG9jazEgPCBsb2NrMiApCiAgICAgewotICAgICAgICBzcGlu
X2xvY2tfaXJxc2F2ZShsb2NrMSwgKmZsYWdzKTsKLSAgICAgICAgc3Bpbl9s
b2NrKGxvY2syKTsKKyAgICAgICAgKmZsYWdzID0gX3NwaW5fbG9ja19pcnFz
YXZlKGxvY2sxKTsKKyAgICAgICAgX3NwaW5fbG9jayhsb2NrMik7CiAgICAg
fQogICAgIGVsc2UKICAgICB7Ci0gICAgICAgIHNwaW5fbG9ja19pcnFzYXZl
KGxvY2syLCAqZmxhZ3MpOwotICAgICAgICBzcGluX2xvY2sobG9jazEpOwor
ICAgICAgICAqZmxhZ3MgPSBfc3Bpbl9sb2NrX2lycXNhdmUobG9jazIpOwor
ICAgICAgICBfc3Bpbl9sb2NrKGxvY2sxKTsKICAgICB9CisgICAgYmxvY2tf
bG9ja19zcGVjdWxhdGlvbigpOwogfQogCiBzdGF0aWMgdm9pZCBzY2hlZF9z
cGluX3VubG9ja19kb3VibGUoc3BpbmxvY2tfdCAqbG9jazEsIHNwaW5sb2Nr
X3QgKmxvY2syLApkaWZmIC0tZ2l0IGEveGVuL2NvbW1vbi9zY2hlZC9wcml2
YXRlLmggYi94ZW4vY29tbW9uL3NjaGVkL3ByaXZhdGUuaAppbmRleCAwNTI3
YThjNzBkMWMuLjI0YTkzZGQwYzEyMyAxMDA2NDQKLS0tIGEveGVuL2NvbW1v
bi9zY2hlZC9wcml2YXRlLmgKKysrIGIveGVuL2NvbW1vbi9zY2hlZC9wcml2
YXRlLmgKQEAgLTIwNyw4ICsyMDcsMjQgQEAgREVDTEFSRV9QRVJfQ1BVKGNw
dW1hc2tfdCwgY3B1bWFza19zY3JhdGNoKTsKICNkZWZpbmUgY3B1bWFza19z
Y3JhdGNoICAgICAgICAoJnRoaXNfY3B1KGNwdW1hc2tfc2NyYXRjaCkpCiAj
ZGVmaW5lIGNwdW1hc2tfc2NyYXRjaF9jcHUoYykgKCZwZXJfY3B1KGNwdW1h
c2tfc2NyYXRjaCwgYykpCiAKKy8qCisgKiBEZWFsIHdpdGggX3NwaW5fbG9j
a19pcnFzYXZlKCkgcmV0dXJuaW5nIHRoZSBmbGFncyB2YWx1ZSBpbnN0ZWFk
IG9mIHN0b3JpbmcKKyAqIGl0IGluIGEgcGFzc2VkIHBhcmFtZXRlci4KKyAq
LworI2RlZmluZSBfc2NoZWRfc3BpbmxvY2swKGxvY2ssIGlycSkgX3NwaW5f
bG9jayMjaXJxKGxvY2spCisjZGVmaW5lIF9zY2hlZF9zcGlubG9jazEobG9j
aywgaXJxLCBhcmcpICh7IFwKKyAgICBCVUlMRF9CVUdfT04oc2l6ZW9mKGFy
ZykgIT0gc2l6ZW9mKHVuc2lnbmVkIGxvbmcpKTsgXAorICAgIChhcmcpID0g
X3NwaW5fbG9jayMjaXJxKGxvY2spOyBcCit9KQorCisjZGVmaW5lIF9zY2hl
ZF9zcGlubG9ja19fKG5yKSBfc2NoZWRfc3BpbmxvY2sgIyMgbnIKKyNkZWZp
bmUgX3NjaGVkX3NwaW5sb2NrXyhucikgIF9zY2hlZF9zcGlubG9ja19fKG5y
KQorI2RlZmluZSBfc2NoZWRfc3BpbmxvY2sobG9jaywgaXJxLCBhcmdzLi4u
KSBcCisgICAgX3NjaGVkX3NwaW5sb2NrXyhjb3VudF9hcmdzKGFyZ3MpKShs
b2NrLCBpcnEsICMjIGFyZ3MpCisKICNkZWZpbmUgc2NoZWRfbG9jayhraW5k
LCBwYXJhbSwgY3B1LCBpcnEsIGFyZy4uLikgXAotc3RhdGljIGlubGluZSBz
cGlubG9ja190ICpraW5kIyNfc2NoZWR1bGVfbG9jayMjaXJxKHBhcmFtIEVY
VFJBX1RZUEUoYXJnKSkgXAorc3RhdGljIGFsd2F5c19pbmxpbmUgc3Bpbmxv
Y2tfdCBcCisqa2luZCMjX3NjaGVkdWxlX2xvY2sjI2lycShwYXJhbSBFWFRS
QV9UWVBFKGFyZykpIFwKIHsgXAogICAgIGZvciAoIDsgOyApIFwKICAgICB7
IFwKQEAgLTIyMCwxMCArMjM2LDE2IEBAIHN0YXRpYyBpbmxpbmUgc3Bpbmxv
Y2tfdCAqa2luZCMjX3NjaGVkdWxlX2xvY2sjI2lycShwYXJhbSBFWFRSQV9U
WVBFKGFyZykpIFwKICAgICAgICAgICogXAogICAgICAgICAgKiBJdCBtYXkg
YWxzbyBiZSB0aGUgY2FzZSB0aGF0IHYtPnByb2Nlc3NvciBtYXkgY2hhbmdl
IGJ1dCB0aGUgXAogICAgICAgICAgKiBsb2NrIG1heSBiZSB0aGUgc2FtZTsg
dGhpcyB3aWxsIHN1Y2NlZWQgaW4gdGhhdCBjYXNlLiBcCisgICAgICAgICAq
IFwKKyAgICAgICAgICogVXNlIHRoZSBzcGVjdWxhdGlvbiB1bnNhZmUgbG9j
a2luZyBoZWxwZXIsIHRoZXJlJ3MgYSBzcGVjdWxhdGlvbiBcCisgICAgICAg
ICAqIGJhcnJpZXIgYmVmb3JlIHJldHVybmluZyB0byB0aGUgY2FsbGVyLiBc
CiAgICAgICAgICAqLyBcCi0gICAgICAgIHNwaW5fbG9jayMjaXJxKGxvY2ss
ICMjIGFyZyk7IFwKKyAgICAgICAgX3NjaGVkX3NwaW5sb2NrKGxvY2ssIGly
cSwgIyMgYXJnKTsgXAogICAgICAgICBpZiAoIGxpa2VseShsb2NrID09IGdl
dF9zY2hlZF9yZXMoY3B1KS0+c2NoZWR1bGVfbG9jaykgKSBcCisgICAgICAg
IHsgXAorICAgICAgICAgICAgYmxvY2tfbG9ja19zcGVjdWxhdGlvbigpOyBc
CiAgICAgICAgICAgICByZXR1cm4gbG9jazsgXAorICAgICAgICB9IFwKICAg
ICAgICAgc3Bpbl91bmxvY2sjI2lycShsb2NrLCAjIyBhcmcpOyBcCiAgICAg
fSBcCiB9CmRpZmYgLS1naXQgYS94ZW4vY29tbW9uL3RpbWVyLmMgYi94ZW4v
Y29tbW9uL3RpbWVyLmMKaW5kZXggOWI1MDE2ZDVlZDgyLi40NTk2NjhkNDE3
ZjQgMTAwNjQ0Ci0tLSBhL3hlbi9jb21tb24vdGltZXIuYworKysgYi94ZW4v
Y29tbW9uL3RpbWVyLmMKQEAgLTI0MCw3ICsyNDAsNyBAQCBzdGF0aWMgaW5s
aW5lIHZvaWQgZGVhY3RpdmF0ZV90aW1lcihzdHJ1Y3QgdGltZXIgKnRpbWVy
KQogICAgIGxpc3RfYWRkKCZ0aW1lci0+aW5hY3RpdmUsICZwZXJfY3B1KHRp
bWVycywgdGltZXItPmNwdSkuaW5hY3RpdmUpOwogfQogCi1zdGF0aWMgaW5s
aW5lIGJvb2xfdCB0aW1lcl9sb2NrKHN0cnVjdCB0aW1lciAqdGltZXIpCitz
dGF0aWMgaW5saW5lIGJvb2xfdCB0aW1lcl9sb2NrX3Vuc2FmZShzdHJ1Y3Qg
dGltZXIgKnRpbWVyKQogewogICAgIHVuc2lnbmVkIGludCBjcHU7CiAKQEAg
LTI1NCw3ICsyNTQsOCBAQCBzdGF0aWMgaW5saW5lIGJvb2xfdCB0aW1lcl9s
b2NrKHN0cnVjdCB0aW1lciAqdGltZXIpCiAgICAgICAgICAgICByY3VfcmVh
ZF91bmxvY2soJnRpbWVyX2NwdV9yZWFkX2xvY2spOwogICAgICAgICAgICAg
cmV0dXJuIDA7CiAgICAgICAgIH0KLSAgICAgICAgc3Bpbl9sb2NrKCZwZXJf
Y3B1KHRpbWVycywgY3B1KS5sb2NrKTsKKyAgICAgICAgLyogVXNlIHRoZSBz
cGVjdWxhdGlvbiB1bnNhZmUgdmFyaWFudCwgdGhlIHdyYXBwZXIgaGFzIHRo
ZSBiYXJyaWVyLiAqLworICAgICAgICBfc3Bpbl9sb2NrKCZwZXJfY3B1KHRp
bWVycywgY3B1KS5sb2NrKTsKICAgICAgICAgaWYgKCBsaWtlbHkodGltZXIt
PmNwdSA9PSBjcHUpICkKICAgICAgICAgICAgIGJyZWFrOwogICAgICAgICBz
cGluX3VubG9jaygmcGVyX2NwdSh0aW1lcnMsIGNwdSkubG9jayk7CkBAIC0y
NjcsOCArMjY4LDkgQEAgc3RhdGljIGlubGluZSBib29sX3QgdGltZXJfbG9j
ayhzdHJ1Y3QgdGltZXIgKnRpbWVyKQogI2RlZmluZSB0aW1lcl9sb2NrX2ly
cXNhdmUodCwgZmxhZ3MpICh7ICAgICAgICAgXAogICAgIGJvb2xfdCBfX3g7
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAogICAgIGxvY2Fs
X2lycV9zYXZlKGZsYWdzKTsgICAgICAgICAgICAgICAgICAgICAgXAotICAg
IGlmICggIShfX3ggPSB0aW1lcl9sb2NrKHQpKSApICAgICAgICAgICAgICAg
XAorICAgIGlmICggIShfX3ggPSB0aW1lcl9sb2NrX3Vuc2FmZSh0KSkgKSAg
ICAgICAgXAogICAgICAgICBsb2NhbF9pcnFfcmVzdG9yZShmbGFncyk7ICAg
ICAgICAgICAgICAgXAorICAgIGJsb2NrX2xvY2tfc3BlY3VsYXRpb24oKTsg
ICAgICAgICAgICAgICAgICAgXAogICAgIF9feDsgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgXAogfSkKIApkaWZmIC0tZ2l0IGEv
eGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvcGNpLmMgYi94ZW4vZHJpdmVycy9w
YXNzdGhyb3VnaC9wY2kuYwppbmRleCA4YzYyYjE0ZDE5YzEuLjFiM2QyODUx
NjY0MyAxMDA2NDQKLS0tIGEveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvcGNp
LmMKKysrIGIveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvcGNpLmMKQEAgLTUy
LDkgKzUyLDEwIEBAIHN0cnVjdCBwY2lfc2VnIHsKIAogc3RhdGljIHNwaW5s
b2NrX3QgX3BjaWRldnNfbG9jayA9IFNQSU5fTE9DS19VTkxPQ0tFRDsKIAot
dm9pZCBwY2lkZXZzX2xvY2sodm9pZCkKKy8qIERvIG5vdCB1c2UsIGFzIGl0
IGhhcyBubyBzcGVjdWxhdGlvbiBiYXJyaWVyLCB1c2UgcGNpZGV2c19sb2Nr
KCkgaW5zdGVhZC4gKi8KK3ZvaWQgcGNpZGV2c19sb2NrX3Vuc2FmZSh2b2lk
KQogewotICAgIHNwaW5fbG9ja19yZWN1cnNpdmUoJl9wY2lkZXZzX2xvY2sp
OworICAgIF9zcGluX2xvY2tfcmVjdXJzaXZlKCZfcGNpZGV2c19sb2NrKTsK
IH0KIAogdm9pZCBwY2lkZXZzX3VubG9jayh2b2lkKQpkaWZmIC0tZ2l0IGEv
eGVuL2luY2x1ZGUveGVuL2V2ZW50LmggYi94ZW4vaW5jbHVkZS94ZW4vZXZl
bnQuaAppbmRleCA4ZWFlOTk4NGE5ZjEuLmRkOTZlODRjNjk1NiAxMDA2NDQK
LS0tIGEveGVuL2luY2x1ZGUveGVuL2V2ZW50LmgKKysrIGIveGVuL2luY2x1
ZGUveGVuL2V2ZW50LmgKQEAgLTExNCwxMiArMTE0LDEyIEBAIHZvaWQgbm90
aWZ5X3ZpYV94ZW5fZXZlbnRfY2hhbm5lbChzdHJ1Y3QgZG9tYWluICpsZCwg
aW50IGxwb3J0KTsKICNkZWZpbmUgYnVja2V0X2Zyb21fcG9ydChkLCBwKSBc
CiAgICAgKChncm91cF9mcm9tX3BvcnQoZCwgcCkpWygocCkgJSBFVlRDSE5T
X1BFUl9HUk9VUCkgLyBFVlRDSE5TX1BFUl9CVUNLRVRdKQogCi1zdGF0aWMg
aW5saW5lIHZvaWQgZXZ0Y2huX3JlYWRfbG9jayhzdHJ1Y3QgZXZ0Y2huICpl
dnRjaG4pCitzdGF0aWMgYWx3YXlzX2lubGluZSB2b2lkIGV2dGNobl9yZWFk
X2xvY2soc3RydWN0IGV2dGNobiAqZXZ0Y2huKQogewogICAgIHJlYWRfbG9j
aygmZXZ0Y2huLT5sb2NrKTsKIH0KIAotc3RhdGljIGlubGluZSBib29sIGV2
dGNobl9yZWFkX3RyeWxvY2soc3RydWN0IGV2dGNobiAqZXZ0Y2huKQorc3Rh
dGljIGFsd2F5c19pbmxpbmUgYm9vbCBldnRjaG5fcmVhZF90cnlsb2NrKHN0
cnVjdCBldnRjaG4gKmV2dGNobikKIHsKICAgICByZXR1cm4gcmVhZF90cnls
b2NrKCZldnRjaG4tPmxvY2spOwogfQpkaWZmIC0tZ2l0IGEveGVuL2luY2x1
ZGUveGVuL3BjaS5oIGIveGVuL2luY2x1ZGUveGVuL3BjaS5oCmluZGV4IDU5
NzVjYTJmMzAzMi4uYjM3M2YxMzlkMTM2IDEwMDY0NAotLS0gYS94ZW4vaW5j
bHVkZS94ZW4vcGNpLmgKKysrIGIveGVuL2luY2x1ZGUveGVuL3BjaS5oCkBA
IC0xNTUsOCArMTU1LDEyIEBAIHN0cnVjdCBwY2lfZGV2IHsKICAqIGRldmlj
ZXMsIGl0IGFsc28gc3luYyB0aGUgYWNjZXNzIHRvIHRoZSBtc2kgY2FwYWJp
bGl0eSB0aGF0IGlzIG5vdAogICogaW50ZXJydXB0IGhhbmRsaW5nIHJlbGF0
ZWQgKHRoZSBtYXNrIGJpdCByZWdpc3RlcikuCiAgKi8KLQotdm9pZCBwY2lk
ZXZzX2xvY2sodm9pZCk7Cit2b2lkIHBjaWRldnNfbG9ja191bnNhZmUodm9p
ZCk7CitzdGF0aWMgYWx3YXlzX2lubGluZSB2b2lkIHBjaWRldnNfbG9jayh2
b2lkKQoreworICAgIHBjaWRldnNfbG9ja191bnNhZmUoKTsKKyAgICBibG9j
a19sb2NrX3NwZWN1bGF0aW9uKCk7Cit9CiB2b2lkIHBjaWRldnNfdW5sb2Nr
KHZvaWQpOwogYm9vbF90IF9fbXVzdF9jaGVjayBwY2lkZXZzX2xvY2tlZCh2
b2lkKTsKIAo=

--=separator
Content-Type: application/octet-stream; name="xsa453/xsa453-4.17-7.patch"
Content-Disposition: attachment; filename="xsa453/xsa453-4.17-7.patch"
Content-Transfer-Encoding: base64

RnJvbTogPT9VVEYtOD9xP1JvZ2VyPTIwUGF1PTIwTW9ubj1DMz1BOT89IDxy
b2dlci5wYXVAY2l0cml4LmNvbT4KU3ViamVjdDogeDg2L21tOiBhZGQgc3Bl
Y3VsYXRpb24gYmFycmllcnMgdG8gb3BlbiBjb2RlZCBsb2NrcwoKQWRkIGEg
c3BlY3VsYXRpb24gYmFycmllciB0byB0aGUgY2xlYXJseSBpZGVudGlmaWVk
IG9wZW4tY29kZWQgbG9jayB0YWtpbmcKZnVuY3Rpb25zLgoKTm90ZSB0aGF0
IHRoZSBtZW1vcnkgc2hhcmluZyBwYWdlX2xvY2soKSByZXBsYWNlbWVudCAo
X3BhZ2VfbG9jaygpKSBpcyBsZWZ0CmFzLWlzLCBhcyB0aGUgY29kZSBpcyBl
eHBlcmltZW50YWwgYW5kIG5vdCBzZWN1cml0eSBzdXBwb3J0ZWQuCgpUaGlz
IGlzIHBhcnQgb2YgWFNBLTQ1MyAvIENWRS0yMDI0LTIxOTMKClNpZ25lZC1v
ZmYtYnk6IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXguY29t
PgpSZXZpZXdlZC1ieTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29t
PgooY2hlcnJ5IHBpY2tlZCBmcm9tIGNvbW1pdCA0MmE1NzJhMzhlMjJhOTdk
ODZhNGI2NDhhMjI1OTc2MjhkNWI0MmU0KQoKZGlmZiAtLWdpdCBhL3hlbi9h
cmNoL3g4Ni9pbmNsdWRlL2FzbS9tbS5oIGIveGVuL2FyY2gveDg2L2luY2x1
ZGUvYXNtL21tLmgKaW5kZXggYTVkN2ZkZDMyZWE3Li41ODQ1YjcyOWMzZjcg
MTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9tbS5oCisr
KyBiL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9tbS5oCkBAIC0zOTMsNyAr
MzkzLDkgQEAgY29uc3Qgc3RydWN0IHBsYXRmb3JtX2JhZF9wYWdlICpnZXRf
cGxhdGZvcm1fYmFkcGFnZXModW5zaWduZWQgaW50ICphcnJheV9zaXplKTsK
ICAqIFRoZSB1c2Ugb2YgUEdUX2xvY2tlZCBpbiBtZW1fc2hhcmluZyBkb2Vz
IG5vdCBjb2xsaWRlLCBzaW5jZSBtZW1fc2hhcmluZyBpcwogICogb25seSBz
dXBwb3J0ZWQgZm9yIGh2bSBndWVzdHMsIHdoaWNoIGRvIG5vdCBoYXZlIFBW
IFBURXMgdXBkYXRlZC4KICAqLwotaW50IHBhZ2VfbG9jayhzdHJ1Y3QgcGFn
ZV9pbmZvICpwYWdlKTsKK2ludCBwYWdlX2xvY2tfdW5zYWZlKHN0cnVjdCBw
YWdlX2luZm8gKnBhZ2UpOworI2RlZmluZSBwYWdlX2xvY2socGcpICAgbG9j
a19ldmFsdWF0ZV9ub3NwZWMocGFnZV9sb2NrX3Vuc2FmZShwZykpCisKIHZv
aWQgcGFnZV91bmxvY2soc3RydWN0IHBhZ2VfaW5mbyAqcGFnZSk7CiAKIHZv
aWQgcHV0X3BhZ2VfdHlwZShzdHJ1Y3QgcGFnZV9pbmZvICpwYWdlKTsKZGlm
ZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9tbS5jIGIveGVuL2FyY2gveDg2L21t
LmMKaW5kZXggMzMwYzRhYmNkMTBlLi44ZDE5ZDcxOWJkMTYgMTAwNjQ0Ci0t
LSBhL3hlbi9hcmNoL3g4Ni9tbS5jCisrKyBiL3hlbi9hcmNoL3g4Ni9tbS5j
CkBAIC0yMDMzLDcgKzIwMzMsNyBAQCBzdGF0aWMgaW5saW5lIGJvb2wgY3Vy
cmVudF9sb2NrZWRfcGFnZV9uZV9jaGVjayhzdHJ1Y3QgcGFnZV9pbmZvICpw
YWdlKSB7CiAjZGVmaW5lIGN1cnJlbnRfbG9ja2VkX3BhZ2VfbmVfY2hlY2so
eCkgdHJ1ZQogI2VuZGlmCiAKLWludCBwYWdlX2xvY2soc3RydWN0IHBhZ2Vf
aW5mbyAqcGFnZSkKK2ludCBwYWdlX2xvY2tfdW5zYWZlKHN0cnVjdCBwYWdl
X2luZm8gKnBhZ2UpCiB7CiAgICAgdW5zaWduZWQgbG9uZyB4LCBueDsKIApA
QCAtMjA5NCw3ICsyMDk0LDcgQEAgdm9pZCBwYWdlX3VubG9jayhzdHJ1Y3Qg
cGFnZV9pbmZvICpwYWdlKQogICogbDN0X2xvY2soKSwgc28gdG8gYXZvaWQg
ZGVhZGxvY2sgd2UgbXVzdCBhdm9pZCBncmFiYmluZyB0aGVtIGluCiAgKiBy
ZXZlcnNlIG9yZGVyLgogICovCi1zdGF0aWMgdm9pZCBsM3RfbG9jayhzdHJ1
Y3QgcGFnZV9pbmZvICpwYWdlKQorc3RhdGljIGFsd2F5c19pbmxpbmUgdm9p
ZCBsM3RfbG9jayhzdHJ1Y3QgcGFnZV9pbmZvICpwYWdlKQogewogICAgIHVu
c2lnbmVkIGxvbmcgeCwgbng7CiAKQEAgLTIxMDMsNiArMjEwMyw4IEBAIHN0
YXRpYyB2b2lkIGwzdF9sb2NrKHN0cnVjdCBwYWdlX2luZm8gKnBhZ2UpCiAg
ICAgICAgICAgICBjcHVfcmVsYXgoKTsKICAgICAgICAgbnggPSB4IHwgUEdU
X2xvY2tlZDsKICAgICB9IHdoaWxlICggY21weGNoZygmcGFnZS0+dS5pbnVz
ZS50eXBlX2luZm8sIHgsIG54KSAhPSB4ICk7CisKKyAgICBibG9ja19sb2Nr
X3NwZWN1bGF0aW9uKCk7CiB9CiAKIHN0YXRpYyB2b2lkIGwzdF91bmxvY2so
c3RydWN0IHBhZ2VfaW5mbyAqcGFnZSkK

--=separator
Content-Type: application/octet-stream; name="xsa453/xsa453-4.17-8.patch"
Content-Disposition: attachment; filename="xsa453/xsa453-4.17-8.patch"
Content-Transfer-Encoding: base64

RnJvbTogPT9VVEYtOD9xP1JvZ2VyPTIwUGF1PTIwTW9ubj1DMz1BOT89IDxy
b2dlci5wYXVAY2l0cml4LmNvbT4KU3ViamVjdDogeDg2OiBwcm90ZWN0IGNv
bmRpdGlvbmFsIGxvY2sgdGFraW5nIGZyb20gc3BlY3VsYXRpdmUgZXhlY3V0
aW9uCgpDb25kaXRpb25hbGx5IHRha2VuIGxvY2tzIHRoYXQgdXNlIHRoZSBw
YXR0ZXJuOgoKaWYgKCBsb2NrICkKICAgIHNwaW5fbG9jayguLi4pOwoKTmVl
ZCBhbiBlbHNlIGJyYW5jaCBpbiBvcmRlciB0byBpc3N1ZSBhbiBzcGVjdWxh
dGlvbiBiYXJyaWVyIGluIHRoZSBlbHNlIGNhc2UsCmp1c3QgbGlrZSBpdCdz
IGRvbmUgaW4gY2FzZSB0aGUgbG9jayBuZWVkcyB0byBiZSBhY3F1aXJlZC4K
CmV2YWxfbm9zcGVjKCkgY291bGQgYmUgdXNlZCBvbiB0aGUgY29uZGl0aW9u
IGl0c2VsZiwgYnV0IHRoYXQgd291bGQgcmVzdWx0IGluIGEKZG91YmxlIGJh
cnJpZXIgb24gdGhlIGJyYW5jaCB3aGVyZSB0aGUgbG9jayBpcyB0YWtlbi4K
CkludHJvZHVjZSBhIG5ldyBwYWlyIG9mIGhlbHBlcnMsIHtnZm4sc3Bpbn1f
bG9ja19pZigpIHRoYXQgY2FuIGJlIHVzZWQgdG8KY29uZGl0aW9uYWxseSB0
YWtlIGEgbG9jayBpbiBhIHNwZWN1bGF0aW9uIHNhZmUgd2F5LgoKVGhpcyBp
cyBwYXJ0IG9mIFhTQS00NTMgLyBDVkUtMjAyNC0yMTkzCgpTaWduZWQtb2Zm
LWJ5OiBSb2dlciBQYXUgTW9ubsOpIDxyb2dlci5wYXVAY2l0cml4LmNvbT4K
UmV2aWV3ZWQtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4K
KGNoZXJyeSBwaWNrZWQgZnJvbSBjb21taXQgMDNjZjdjYTIzZTBlODc2MDc1
OTU0YzU1ODQ4NWIyNjdiN2QwMjQwNikKCmRpZmYgLS1naXQgYS94ZW4vYXJj
aC94ODYvbW0uYyBiL3hlbi9hcmNoL3g4Ni9tbS5jCmluZGV4IDhkMTlkNzE5
YmQxNi4uZDMxYjhkNTZmZmJjIDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYv
bW0uYworKysgYi94ZW4vYXJjaC94ODYvbW0uYwpAQCAtNTAyMyw4ICs1MDIz
LDcgQEAgc3RhdGljIGwzX3BnZW50cnlfdCAqdmlydF90b194ZW5fbDNlKHVu
c2lnbmVkIGxvbmcgdikKICAgICAgICAgaWYgKCAhbDN0ICkKICAgICAgICAg
ICAgIHJldHVybiBOVUxMOwogICAgICAgICBVTk1BUF9ET01BSU5fUEFHRShs
M3QpOwotICAgICAgICBpZiAoIGxvY2tpbmcgKQotICAgICAgICAgICAgc3Bp
bl9sb2NrKCZtYXBfcGdkaXJfbG9jayk7CisgICAgICAgIHNwaW5fbG9ja19p
Zihsb2NraW5nLCAmbWFwX3BnZGlyX2xvY2spOwogICAgICAgICBpZiAoICEo
bDRlX2dldF9mbGFncygqcGw0ZSkgJiBfUEFHRV9QUkVTRU5UKSApCiAgICAg
ICAgIHsKICAgICAgICAgICAgIGw0X3BnZW50cnlfdCBsNGUgPSBsNGVfZnJv
bV9tZm4obDNtZm4sIF9fUEFHRV9IWVBFUlZJU09SKTsKQEAgLTUwNjEsOCAr
NTA2MCw3IEBAIHN0YXRpYyBsMl9wZ2VudHJ5X3QgKnZpcnRfdG9feGVuX2wy
ZSh1bnNpZ25lZCBsb25nIHYpCiAgICAgICAgICAgICByZXR1cm4gTlVMTDsK
ICAgICAgICAgfQogICAgICAgICBVTk1BUF9ET01BSU5fUEFHRShsMnQpOwot
ICAgICAgICBpZiAoIGxvY2tpbmcgKQotICAgICAgICAgICAgc3Bpbl9sb2Nr
KCZtYXBfcGdkaXJfbG9jayk7CisgICAgICAgIHNwaW5fbG9ja19pZihsb2Nr
aW5nLCAmbWFwX3BnZGlyX2xvY2spOwogICAgICAgICBpZiAoICEobDNlX2dl
dF9mbGFncygqcGwzZSkgJiBfUEFHRV9QUkVTRU5UKSApCiAgICAgICAgIHsK
ICAgICAgICAgICAgIGwzZV93cml0ZShwbDNlLCBsM2VfZnJvbV9tZm4obDJt
Zm4sIF9fUEFHRV9IWVBFUlZJU09SKSk7CkBAIC01MTAwLDggKzUwOTgsNyBA
QCBsMV9wZ2VudHJ5X3QgKnZpcnRfdG9feGVuX2wxZSh1bnNpZ25lZCBsb25n
IHYpCiAgICAgICAgICAgICByZXR1cm4gTlVMTDsKICAgICAgICAgfQogICAg
ICAgICBVTk1BUF9ET01BSU5fUEFHRShsMXQpOwotICAgICAgICBpZiAoIGxv
Y2tpbmcgKQotICAgICAgICAgICAgc3Bpbl9sb2NrKCZtYXBfcGdkaXJfbG9j
ayk7CisgICAgICAgIHNwaW5fbG9ja19pZihsb2NraW5nLCAmbWFwX3BnZGly
X2xvY2spOwogICAgICAgICBpZiAoICEobDJlX2dldF9mbGFncygqcGwyZSkg
JiBfUEFHRV9QUkVTRU5UKSApCiAgICAgICAgIHsKICAgICAgICAgICAgIGwy
ZV93cml0ZShwbDJlLCBsMmVfZnJvbV9tZm4obDFtZm4sIF9fUEFHRV9IWVBF
UlZJU09SKSk7CkBAIC01MTMyLDYgKzUxMjksOCBAQCBsMV9wZ2VudHJ5X3Qg
KnZpcnRfdG9feGVuX2wxZSh1bnNpZ25lZCBsb25nIHYpCiAgICAgZG8geyAg
ICAgICAgICAgICAgICAgICAgICBcCiAgICAgICAgIGlmICggbG9ja2luZyAp
ICAgICAgICBcCiAgICAgICAgICAgICBsM3RfbG9jayhwYWdlKTsgICBcCisg
ICAgICAgIGVsc2UgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAorICAg
ICAgICAgICAgYmxvY2tfbG9ja19zcGVjdWxhdGlvbigpOyAgIFwKICAgICB9
IHdoaWxlICggZmFsc2UgKQogCiAjZGVmaW5lIEwzVF9VTkxPQ0socGFnZSkg
ICAgICAgICAgICAgICAgICAgICAgICAgICBcCkBAIC01MzQ3LDggKzUzNDYs
NyBAQCBpbnQgbWFwX3BhZ2VzX3RvX3hlbigKICAgICAgICAgICAgIGlmICgg
bDNlX2dldF9mbGFncyhvbDNlKSAmIF9QQUdFX0dMT0JBTCApCiAgICAgICAg
ICAgICAgICAgZmx1c2hfZmxhZ3MgfD0gRkxVU0hfVExCX0dMT0JBTDsKIAot
ICAgICAgICAgICAgaWYgKCBsb2NraW5nICkKLSAgICAgICAgICAgICAgICBz
cGluX2xvY2soJm1hcF9wZ2Rpcl9sb2NrKTsKKyAgICAgICAgICAgIHNwaW5f
bG9ja19pZihsb2NraW5nLCAmbWFwX3BnZGlyX2xvY2spOwogICAgICAgICAg
ICAgaWYgKCAobDNlX2dldF9mbGFncygqcGwzZSkgJiBfUEFHRV9QUkVTRU5U
KSAmJgogICAgICAgICAgICAgICAgICAobDNlX2dldF9mbGFncygqcGwzZSkg
JiBfUEFHRV9QU0UpICkKICAgICAgICAgICAgIHsKQEAgLTU0NTIsOCArNTQ1
MCw3IEBAIGludCBtYXBfcGFnZXNfdG9feGVuKAogICAgICAgICAgICAgICAg
IGlmICggbDJlX2dldF9mbGFncygqcGwyZSkgJiBfUEFHRV9HTE9CQUwgKQog
ICAgICAgICAgICAgICAgICAgICBmbHVzaF9mbGFncyB8PSBGTFVTSF9UTEJf
R0xPQkFMOwogCi0gICAgICAgICAgICAgICAgaWYgKCBsb2NraW5nICkKLSAg
ICAgICAgICAgICAgICAgICAgc3Bpbl9sb2NrKCZtYXBfcGdkaXJfbG9jayk7
CisgICAgICAgICAgICAgICAgc3Bpbl9sb2NrX2lmKGxvY2tpbmcsICZtYXBf
cGdkaXJfbG9jayk7CiAgICAgICAgICAgICAgICAgaWYgKCAobDJlX2dldF9m
bGFncygqcGwyZSkgJiBfUEFHRV9QUkVTRU5UKSAmJgogICAgICAgICAgICAg
ICAgICAgICAgKGwyZV9nZXRfZmxhZ3MoKnBsMmUpICYgX1BBR0VfUFNFKSAp
CiAgICAgICAgICAgICAgICAgewpAQCAtNTQ5NCw4ICs1NDkxLDcgQEAgaW50
IG1hcF9wYWdlc190b194ZW4oCiAgICAgICAgICAgICAgICAgdW5zaWduZWQg
bG9uZyBiYXNlX21mbjsKICAgICAgICAgICAgICAgICBjb25zdCBsMV9wZ2Vu
dHJ5X3QgKmwxdDsKIAotICAgICAgICAgICAgICAgIGlmICggbG9ja2luZyAp
Ci0gICAgICAgICAgICAgICAgICAgIHNwaW5fbG9jaygmbWFwX3BnZGlyX2xv
Y2spOworICAgICAgICAgICAgICAgIHNwaW5fbG9ja19pZihsb2NraW5nLCAm
bWFwX3BnZGlyX2xvY2spOwogCiAgICAgICAgICAgICAgICAgb2wyZSA9ICpw
bDJlOwogICAgICAgICAgICAgICAgIC8qCkBAIC01NTQ5LDggKzU1NDUsNyBA
QCBpbnQgbWFwX3BhZ2VzX3RvX3hlbigKICAgICAgICAgICAgIHVuc2lnbmVk
IGxvbmcgYmFzZV9tZm47CiAgICAgICAgICAgICBjb25zdCBsMl9wZ2VudHJ5
X3QgKmwydDsKIAotICAgICAgICAgICAgaWYgKCBsb2NraW5nICkKLSAgICAg
ICAgICAgICAgICBzcGluX2xvY2soJm1hcF9wZ2Rpcl9sb2NrKTsKKyAgICAg
ICAgICAgIHNwaW5fbG9ja19pZihsb2NraW5nLCAmbWFwX3BnZGlyX2xvY2sp
OwogCiAgICAgICAgICAgICBvbDNlID0gKnBsM2U7CiAgICAgICAgICAgICAv
KgpAQCAtNTY5NCw4ICs1Njg5LDcgQEAgaW50IG1vZGlmeV94ZW5fbWFwcGlu
Z3ModW5zaWduZWQgbG9uZyBzLCB1bnNpZ25lZCBsb25nIGUsIHVuc2lnbmVk
IGludCBuZikKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIGwzZV9nZXRfZmxhZ3MoKnBsM2UpKSk7CiAgICAgICAgICAgICBVTk1B
UF9ET01BSU5fUEFHRShsMnQpOwogCi0gICAgICAgICAgICBpZiAoIGxvY2tp
bmcgKQotICAgICAgICAgICAgICAgIHNwaW5fbG9jaygmbWFwX3BnZGlyX2xv
Y2spOworICAgICAgICAgICAgc3Bpbl9sb2NrX2lmKGxvY2tpbmcsICZtYXBf
cGdkaXJfbG9jayk7CiAgICAgICAgICAgICBpZiAoIChsM2VfZ2V0X2ZsYWdz
KCpwbDNlKSAmIF9QQUdFX1BSRVNFTlQpICYmCiAgICAgICAgICAgICAgICAg
IChsM2VfZ2V0X2ZsYWdzKCpwbDNlKSAmIF9QQUdFX1BTRSkgKQogICAgICAg
ICAgICAgewpAQCAtNTc1NCw4ICs1NzQ4LDcgQEAgaW50IG1vZGlmeV94ZW5f
bWFwcGluZ3ModW5zaWduZWQgbG9uZyBzLCB1bnNpZ25lZCBsb25nIGUsIHVu
c2lnbmVkIGludCBuZikKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBsMmVfZ2V0X2ZsYWdzKCpwbDJlKSAmIH5fUEFHRV9Q
U0UpKTsKICAgICAgICAgICAgICAgICBVTk1BUF9ET01BSU5fUEFHRShsMXQp
OwogCi0gICAgICAgICAgICAgICAgaWYgKCBsb2NraW5nICkKLSAgICAgICAg
ICAgICAgICAgICAgc3Bpbl9sb2NrKCZtYXBfcGdkaXJfbG9jayk7CisgICAg
ICAgICAgICAgICAgc3Bpbl9sb2NrX2lmKGxvY2tpbmcsICZtYXBfcGdkaXJf
bG9jayk7CiAgICAgICAgICAgICAgICAgaWYgKCAobDJlX2dldF9mbGFncygq
cGwyZSkgJiBfUEFHRV9QUkVTRU5UKSAmJgogICAgICAgICAgICAgICAgICAg
ICAgKGwyZV9nZXRfZmxhZ3MoKnBsMmUpICYgX1BBR0VfUFNFKSApCiAgICAg
ICAgICAgICAgICAgewpAQCAtNTc5OSw4ICs1NzkyLDcgQEAgaW50IG1vZGlm
eV94ZW5fbWFwcGluZ3ModW5zaWduZWQgbG9uZyBzLCB1bnNpZ25lZCBsb25n
IGUsIHVuc2lnbmVkIGludCBuZikKICAgICAgICAgICAgICAqLwogICAgICAg
ICAgICAgaWYgKCAobmYgJiBfUEFHRV9QUkVTRU5UKSB8fCAoKHYgIT0gZSkg
JiYgKGwxX3RhYmxlX29mZnNldCh2KSAhPSAwKSkgKQogICAgICAgICAgICAg
ICAgIGNvbnRpbnVlOwotICAgICAgICAgICAgaWYgKCBsb2NraW5nICkKLSAg
ICAgICAgICAgICAgICBzcGluX2xvY2soJm1hcF9wZ2Rpcl9sb2NrKTsKKyAg
ICAgICAgICAgIHNwaW5fbG9ja19pZihsb2NraW5nLCAmbWFwX3BnZGlyX2xv
Y2spOwogCiAgICAgICAgICAgICAvKgogICAgICAgICAgICAgICogTDJFIG1h
eSBiZSBhbHJlYWR5IGNsZWFyZWQsIG9yIHNldCB0byBhIHN1cGVycGFnZSwg
YnkKQEAgLTU4NDcsOCArNTgzOSw3IEBAIGludCBtb2RpZnlfeGVuX21hcHBp
bmdzKHVuc2lnbmVkIGxvbmcgcywgdW5zaWduZWQgbG9uZyBlLCB1bnNpZ25l
ZCBpbnQgbmYpCiAgICAgICAgIGlmICggKG5mICYgX1BBR0VfUFJFU0VOVCkg
fHwKICAgICAgICAgICAgICAoKHYgIT0gZSkgJiYgKGwyX3RhYmxlX29mZnNl
dCh2KSArIGwxX3RhYmxlX29mZnNldCh2KSAhPSAwKSkgKQogICAgICAgICAg
ICAgY29udGludWU7Ci0gICAgICAgIGlmICggbG9ja2luZyApCi0gICAgICAg
ICAgICBzcGluX2xvY2soJm1hcF9wZ2Rpcl9sb2NrKTsKKyAgICAgICAgc3Bp
bl9sb2NrX2lmKGxvY2tpbmcsICZtYXBfcGdkaXJfbG9jayk7CiAKICAgICAg
ICAgLyoKICAgICAgICAgICogTDNFIG1heSBiZSBhbHJlYWR5IGNsZWFyZWQs
IG9yIHNldCB0byBhIHN1cGVycGFnZSwgYnkKZGlmZiAtLWdpdCBhL3hlbi9h
cmNoL3g4Ni9tbS9tbS1sb2Nrcy5oIGIveGVuL2FyY2gveDg2L21tL21tLWxv
Y2tzLmgKaW5kZXggMjY1MjM5YzQ5ZjM5Li4zZWEyZDhlYjAzMmMgMTAwNjQ0
Ci0tLSBhL3hlbi9hcmNoL3g4Ni9tbS9tbS1sb2Nrcy5oCisrKyBiL3hlbi9h
cmNoL3g4Ni9tbS9tbS1sb2Nrcy5oCkBAIC0zNDcsNiArMzQ3LDE1IEBAIHN0
YXRpYyBpbmxpbmUgdm9pZCBwMm1fdW5sb2NrKHN0cnVjdCBwMm1fZG9tYWlu
ICpwKQogI2RlZmluZSBwMm1fbG9ja2VkX2J5X21lKHApICAgbW1fd3JpdGVf
bG9ja2VkX2J5X21lKCYocCktPmxvY2spCiAjZGVmaW5lIGdmbl9sb2NrZWRf
YnlfbWUocCxnKSBwMm1fbG9ja2VkX2J5X21lKHApCiAKK3N0YXRpYyBhbHdh
eXNfaW5saW5lIHZvaWQgZ2ZuX2xvY2tfaWYoYm9vbCBjb25kaXRpb24sIHN0
cnVjdCBwMm1fZG9tYWluICpwMm0sCisgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIGdmbl90IGdmbiwgdW5zaWduZWQgaW50IG9yZGVy
KQoreworICAgIGlmICggY29uZGl0aW9uICkKKyAgICAgICAgZ2ZuX2xvY2so
cDJtLCBnZm4sIG9yZGVyKTsKKyAgICBlbHNlCisgICAgICAgIGJsb2NrX2xv
Y2tfc3BlY3VsYXRpb24oKTsKK30KKwogLyogUG9EIGxvY2sgKHBlci1wMm0t
dGFibGUpCiAgKgogICogUHJvdGVjdHMgcHJpdmF0ZSBQb0QgZGF0YSBzdHJ1
Y3RzOiBlbnRyeSBhbmQgY2FjaGUKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4
Ni9tbS9wMm0uYyBiL3hlbi9hcmNoL3g4Ni9tbS9wMm0uYwppbmRleCBiMjhj
ODk5YjVlYTcuLjFmYTllMDEwMTJhMiAxMDA2NDQKLS0tIGEveGVuL2FyY2gv
eDg2L21tL3AybS5jCisrKyBiL3hlbi9hcmNoL3g4Ni9tbS9wMm0uYwpAQCAt
MjkyLDkgKzI5Miw4IEBAIG1mbl90IHAybV9nZXRfZ2ZuX3R5cGVfYWNjZXNz
KHN0cnVjdCBwMm1fZG9tYWluICpwMm0sIGdmbl90IGdmbiwKICAgICBpZiAo
IHEgJiBQMk1fVU5TSEFSRSApCiAgICAgICAgIHEgfD0gUDJNX0FMTE9DOwog
Ci0gICAgaWYgKCBsb2NrZWQgKQotICAgICAgICAvKiBHcmFiIHRoZSBsb2Nr
IGhlcmUsIGRvbid0IHJlbGVhc2UgdW50aWwgcHV0X2dmbiAqLwotICAgICAg
ICBnZm5fbG9jayhwMm0sIGdmbiwgMCk7CisgICAgLyogR3JhYiB0aGUgbG9j
ayBoZXJlLCBkb24ndCByZWxlYXNlIHVudGlsIHB1dF9nZm4gKi8KKyAgICBn
Zm5fbG9ja19pZihsb2NrZWQsIHAybSwgZ2ZuLCAwKTsKIAogICAgIG1mbiA9
IHAybS0+Z2V0X2VudHJ5KHAybSwgZ2ZuLCB0LCBhLCBxLCBwYWdlX29yZGVy
LCBOVUxMKTsKIApkaWZmIC0tZ2l0IGEveGVuL2luY2x1ZGUveGVuL3NwaW5s
b2NrLmggYi94ZW4vaW5jbHVkZS94ZW4vc3BpbmxvY2suaAppbmRleCBkYWY0
OGZkZWE3MDkuLjdlNzVkMGUyZTdmYiAxMDA2NDQKLS0tIGEveGVuL2luY2x1
ZGUveGVuL3NwaW5sb2NrLmgKKysrIGIveGVuL2luY2x1ZGUveGVuL3NwaW5s
b2NrLmgKQEAgLTIxNiw2ICsyMTYsMTQgQEAgc3RhdGljIGFsd2F5c19pbmxp
bmUgdm9pZCBzcGluX2xvY2tfaXJxKHNwaW5sb2NrX3QgKmwpCiAgICAgICAg
IGJsb2NrX2xvY2tfc3BlY3VsYXRpb24oKTsgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgXAogICAgIH0pCiAKKy8qIENvbmRpdGlvbmFsbHkgdGFr
ZSBhIHNwaW5sb2NrIGluIGEgc3BlY3VsYXRpb24gc2FmZSB3YXkuICovCitz
dGF0aWMgYWx3YXlzX2lubGluZSB2b2lkIHNwaW5fbG9ja19pZihib29sIGNv
bmRpdGlvbiwgc3BpbmxvY2tfdCAqbCkKK3sKKyAgICBpZiAoIGNvbmRpdGlv
biApCisgICAgICAgIF9zcGluX2xvY2sobCk7CisgICAgYmxvY2tfbG9ja19z
cGVjdWxhdGlvbigpOworfQorCiAjZGVmaW5lIHNwaW5fdW5sb2NrKGwpICAg
ICAgICAgICAgICAgIF9zcGluX3VubG9jayhsKQogI2RlZmluZSBzcGluX3Vu
bG9ja19pcnEobCkgICAgICAgICAgICBfc3Bpbl91bmxvY2tfaXJxKGwpCiAj
ZGVmaW5lIHNwaW5fdW5sb2NrX2lycXJlc3RvcmUobCwgZikgIF9zcGluX3Vu
bG9ja19pcnFyZXN0b3JlKGwsIGYpCg==

--=separator
Content-Type: application/octet-stream; name="xsa453/xsa453-4.18-1.patch"
Content-Disposition: attachment; filename="xsa453/xsa453-4.18-1.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeGVuOiBTd2FwIG9yZGVyIG9mIGFjdGlvbnMgaW4gdGhl
IEZSRUUqKCkgbWFjcm9zCgpXaGVyZXZlciBwb3NzaWJsZSwgaXQgaXMgYSBn
b29kIGlkZWEgdG8gTlVMTCBvdXQgdGhlIHZpc2libGUgcmVmZXJlbmNlIHRv
IGFuCm9iamVjdCBwcmlvciB0byBmcmVlaW5nIGl0LiAgVGhlIEZSRUUqKCkg
bWFjcm9zIGFscmVhZHkgY29sbGVjdCB0b2dldGhlciBib3RoCnBhcnRzLCBt
YWtpbmcgaXQgZWFzeSB0byBhZGp1c3QuCgpUaGlzIGhhcyBhIG1hcmdpbmFs
IGNvZGUgZ2VuZXJhdGlvbiBpbXByb3ZlbWVudCwgYXMgc29tZSBvZiB0aGUg
Y2FsbHMgdG8gdGhlCmZyZWUoKSBmdW5jdGlvbiBjYW4gYmUgdGFpbGNhbGwg
b3B0aW1pc2VkLgoKTm8gZnVuY3Rpb25hbCBjaGFuZ2UuCgpTaWduZWQtb2Zm
LWJ5OiBBbmRyZXcgQ29vcGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29t
PgpBY2tlZC1ieTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgoo
Y2hlcnJ5IHBpY2tlZCBmcm9tIGNvbW1pdCBjNGY0MjdlYzg3OWU3YzBkZjZk
NDRkMDI1NjFlOGJlZTgzOGEyOTNlKQoKZGlmZiAtLWdpdCBhL3hlbi9pbmNs
dWRlL3hlbi9tbS5oIGIveGVuL2luY2x1ZGUveGVuL21tLmgKaW5kZXggOGI5
NjE4NjA5Zjc3Li44YmM1ZjQyNDlkMWIgMTAwNjQ0Ci0tLSBhL3hlbi9pbmNs
dWRlL3hlbi9tbS5oCisrKyBiL3hlbi9pbmNsdWRlL3hlbi9tbS5oCkBAIC05
MSw4ICs5MSw5IEBAIGJvb2wgc2NydWJfZnJlZV9wYWdlcyh2b2lkKTsKIAog
LyogRnJlZSBhbiBhbGxvY2F0aW9uLCBhbmQgemVybyB0aGUgcG9pbnRlciB0
byBpdC4gKi8KICNkZWZpbmUgRlJFRV9YRU5IRUFQX1BBR0VTKHAsIG8pIGRv
IHsgXAotICAgIGZyZWVfeGVuaGVhcF9wYWdlcyhwLCBvKTsgICAgICAgICBc
CisgICAgdm9pZCAqX3B0cl8gPSAocCk7ICAgICAgICAgICAgICAgIFwKICAg
ICAocCkgPSBOVUxMOyAgICAgICAgICAgICAgICAgICAgICAgXAorICAgIGZy
ZWVfeGVuaGVhcF9wYWdlcyhfcHRyXywgbyk7ICAgICBcCiB9IHdoaWxlICgg
ZmFsc2UgKQogI2RlZmluZSBGUkVFX1hFTkhFQVBfUEFHRShwKSBGUkVFX1hF
TkhFQVBfUEFHRVMocCwgMCkKIApkaWZmIC0tZ2l0IGEveGVuL2luY2x1ZGUv
eGVuL3htYWxsb2MuaCBiL3hlbi9pbmNsdWRlL3hlbi94bWFsbG9jLmgKaW5k
ZXggMTY5NzlhMTE3YzZhLi5kODU3Mjk4MDExYzEgMTAwNjQ0Ci0tLSBhL3hl
bi9pbmNsdWRlL3hlbi94bWFsbG9jLmgKKysrIGIveGVuL2luY2x1ZGUveGVu
L3htYWxsb2MuaApAQCAtNjYsOSArNjYsMTAgQEAKIGV4dGVybiB2b2lkIHhm
cmVlKHZvaWQgKik7CiAKIC8qIEZyZWUgYW4gYWxsb2NhdGlvbiwgYW5kIHpl
cm8gdGhlIHBvaW50ZXIgdG8gaXQuICovCi0jZGVmaW5lIFhGUkVFKHApIGRv
IHsgXAotICAgIHhmcmVlKHApOyAgICAgICAgIFwKLSAgICAocCkgPSBOVUxM
OyAgICAgICBcCisjZGVmaW5lIFhGUkVFKHApIGRvIHsgICAgICAgICAgICAg
ICAgICAgICAgIFwKKyAgICB2b2lkICpfcHRyXyA9IChwKTsgICAgICAgICAg
ICAgICAgICAgICAgXAorICAgIChwKSA9IE5VTEw7ICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBcCisgICAgeGZyZWUoX3B0cl8pOyAgICAgICAgICAg
ICAgICAgICAgICAgICAgIFwKIH0gd2hpbGUgKCBmYWxzZSApCiAKIC8qIFVu
ZGVybHlpbmcgZnVuY3Rpb25zICovCgo=

--=separator
Content-Type: application/octet-stream; name="xsa453/xsa453-4.18-2.patch"
Content-Disposition: attachment; filename="xsa453/xsa453-4.18-2.patch"
Content-Transfer-Encoding: base64

RnJvbTogPT9VVEYtOD9xP1JvZ2VyPTIwUGF1PTIwTW9ubj1DMz1BOT89IDxy
b2dlci5wYXVAY2l0cml4LmNvbT4KU3ViamVjdDogeDg2L3NwaW5sb2NrOiBp
bnRyb2R1Y2Ugc3VwcG9ydCBmb3IgYmxvY2tpbmcgc3BlY3VsYXRpb24gaW50
bwogY3JpdGljYWwgcmVnaW9ucwoKSW50cm9kdWNlIGEgbmV3IEtjb25maWcg
b3B0aW9uIHRvIGJsb2NrIHNwZWN1bGF0aW9uIGludG8gbG9jayBwcm90ZWN0
ZWQKY3JpdGljYWwgcmVnaW9ucy4gIFRoZSBLY29uZmlnIG9wdGlvbiBpcyBl
bmFibGVkIGJ5IGRlZmF1bHQsIGJ1dCB0aGUgbWl0aWdhdGlvbgp3b24ndCBi
ZSBlbmdhZ2VkIHVubGVzcyBpdCdzIGV4cGxpY2l0bHkgZW5hYmxlZCBpbiB0
aGUgY29tbWFuZCBsaW5lIHVzaW5nCmBzcGVjLWN0cmw9bG9jay1oYXJkZW5g
LgoKQ29udmVydCB0aGUgc3BpbmxvY2sgYWNxdWlyZSBtYWNyb3MgaW50byBh
bHdheXMtaW5saW5lIGZ1bmN0aW9ucywgYW5kIGludHJvZHVjZQphIHNwZWN1
bGF0aW9uIGJhcnJpZXIgYWZ0ZXIgdGhlIGxvY2sgaGFzIGJlZW4gdGFrZW4u
ICBOb3RlIHRoZSBzcGVjdWxhdGlvbgpiYXJyaWVyIGlzIG5vdCBwbGFjZWQg
aW5zaWRlIHRoZSBpbXBsZW1lbnRhdGlvbiBvZiB0aGUgc3BpbiBsb2NrIGZ1
bmN0aW9ucywgYXMKdG8gcHJldmVudCBzcGVjdWxhdGlvbiBmcm9tIGZhbGxp
bmcgdGhyb3VnaCB0aGUgY2FsbCB0byB0aGUgbG9jayBmdW5jdGlvbnMKcmVz
dWx0aW5nIGluIHRoZSBiYXJyaWVyIGFsc28gYmVpbmcgc2tpcHBlZC4KCnRy
eWxvY2sgdmFyaWFudHMgYXJlIHByb3RlY3RlZCB1c2luZyBhIGNvbnN0cnVj
dCBha2luIHRvIHRoZSBleGlzdGluZwpldmFsdWF0ZV9ub3NwZWMoKS4KClRo
aXMgcGF0Y2ggb25seSBpbXBsZW1lbnRzIHRoZSBzcGVjdWxhdGlvbiBiYXJy
aWVyIGZvciB4ODYuCgpOb3RlIHNwaW4gbG9ja3MgYXJlIHRoZSBvbmx5IGxv
Y2tpbmcgcHJpbWl0aXZlIHRha2VuIGNhcmUgaW4gdGhpcyBjaGFuZ2UsCmZ1
cnRoZXIgbG9ja2luZyBwcmltaXRpdmVzIHdpbGwgYmUgYWRqdXN0ZWQgYnkg
c2VwYXJhdGUgY2hhbmdlcy4KClRoaXMgaXMgcGFydCBvZiBYU0EtNDUzIC8g
Q1ZFLTIwMjQtMjE5MwoKU2lnbmVkLW9mZi1ieTogUm9nZXIgUGF1IE1vbm7D
qSA8cm9nZXIucGF1QGNpdHJpeC5jb20+ClJldmlld2VkLWJ5OiBKYW4gQmV1
bGljaCA8amJldWxpY2hAc3VzZS5jb20+CihjaGVycnkgcGlja2VkIGZyb20g
Y29tbWl0IDdlZjAwODQ0MThlMTg4ZDA1ZjMzOGMzZTAyOGZiYmU4YjY5MjRh
ZmEpCgpkaWZmIC0tZ2l0IGEvZG9jcy9taXNjL3hlbi1jb21tYW5kLWxpbmUu
cGFuZG9jIGIvZG9jcy9taXNjL3hlbi1jb21tYW5kLWxpbmUucGFuZG9jCmlu
ZGV4IGZiZjE2ODM5MjQ5YS4uM2Y5ZjkxNjcxODJmIDEwMDY0NAotLS0gYS9k
b2NzL21pc2MveGVuLWNvbW1hbmQtbGluZS5wYW5kb2MKKysrIGIvZG9jcy9t
aXNjL3hlbi1jb21tYW5kLWxpbmUucGFuZG9jCkBAIC0yMzczLDcgKzIzNzMs
NyBAQCBCeSBkZWZhdWx0IFNTQkQgd2lsbCBiZSBtaXRpZ2F0ZWQgYXQgcnVu
dGltZSAoaS5lIGBzc2JkPXJ1bnRpbWVgKS4KID4gICAgICAgICAgICAgIHtt
c3Itc2MscnNiLHZlcncsaWJwYi1lbnRyeX09PGJvb2w+fHtwdixodm19PTxi
b29sPiwKID4gICAgICAgICAgICAgIGJ0aS10aHVuaz1yZXRwb2xpbmV8bGZl
bmNlfGptcCwge2licnMsaWJwYixzc2JkLHBzZmQsCiA+ICAgICAgICAgICAg
ICBlYWdlci1mcHUsbDFkLWZsdXNoLGJyYW5jaC1oYXJkZW4sc3JiLWxvY2ss
Ci0+ICAgICAgICAgICAgICB1bnByaXYtbW1pbyxnZHMtbWl0LGRpdi1zY3J1
Yn09PGJvb2w+IF1gCis+ICAgICAgICAgICAgICB1bnByaXYtbW1pbyxnZHMt
bWl0LGRpdi1zY3J1Yixsb2NrLWhhcmRlbn09PGJvb2w+IF1gCiAKIENvbnRy
b2xzIGZvciBzcGVjdWxhdGl2ZSBleGVjdXRpb24gc2lkZWNoYW5uZWwgbWl0
aWdhdGlvbnMuICBCeSBkZWZhdWx0LCBYZW4KIHdpbGwgcGljayB0aGUgbW9z
dCBhcHByb3ByaWF0ZSBtaXRpZ2F0aW9ucyBiYXNlZCBvbiBjb21waWxlZCBp
biBzdXBwb3J0LApAQCAtMjUwMCw2ICsyNTAwLDExIEBAIE9uIGFsbCBoYXJk
d2FyZSwgdGhlIGBkaXYtc2NydWI9YCBvcHRpb24gY2FuIGJlIHVzZWQgdG8g
Zm9yY2Ugb3IgcHJldmVudCBYZW4KIGZyb20gbWl0aWdhdGluZyB0aGUgRElW
LWxlYWthZ2UgdnVsbmVyYWJpbGl0eS4gIEJ5IGRlZmF1bHQsIFhlbiB3aWxs
IG1pdGlnYXRlCiBESVYtbGVha2FnZSBvbiBoYXJkd2FyZSBiZWxpZXZlZCB0
byBiZSB2dWxuZXJhYmxlLgogCitJZiBYZW4gaXMgY29tcGlsZWQgd2l0aCBg
Q09ORklHX1NQRUNVTEFUSVZFX0hBUkRFTl9MT0NLYCwgdGhlIGBsb2NrLWhh
cmRlbj1gCitib29sZWFuIGNhbiBiZSB1c2VkIHRvIGZvcmNlIG9yIHByZXZl
bnQgWGVuIGZyb20gdXNpbmcgc3BlY3VsYXRpb24gYmFycmllcnMgdG8KK3By
b3RlY3QgbG9jayBjcml0aWNhbCByZWdpb25zLiAgVGhpcyBtaXRpZ2F0aW9u
IHdvbid0IGJlIGVuZ2FnZWQgYnkgZGVmYXVsdCwKK2FuZCBuZWVkcyB0byBi
ZSBleHBsaWNpdGx5IGVuYWJsZWQgb24gdGhlIGNvbW1hbmQgbGluZS4KKwog
IyMjIHN5bmNfY29uc29sZQogPiBgPSA8Ym9vbGVhbj5gCiAKZGlmZiAtLWdp
dCBhL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9jcHVmZWF0dXJlcy5oIGIv
eGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2NwdWZlYXR1cmVzLmgKaW5kZXgg
YzNhYWQyMWMzYjQzLi43ZTgyMjFmZDg1ZGQgMTAwNjQ0Ci0tLSBhL3hlbi9h
cmNoL3g4Ni9pbmNsdWRlL2FzbS9jcHVmZWF0dXJlcy5oCisrKyBiL3hlbi9h
cmNoL3g4Ni9pbmNsdWRlL2FzbS9jcHVmZWF0dXJlcy5oCkBAIC0yNCw3ICsy
NCw3IEBAIFhFTl9DUFVGRUFUVVJFKEFQRVJGTVBFUkYsICAgICAgICBYODZf
U1lOVEgoIDgpKSAvKiBBUEVSRk1QRVJGICovCiBYRU5fQ1BVRkVBVFVSRShN
RkVOQ0VfUkRUU0MsICAgICAgWDg2X1NZTlRIKCA5KSkgLyogTUZFTkNFIHN5
bmNocm9uaXplcyBSRFRTQyAqLwogWEVOX0NQVUZFQVRVUkUoWEVOX1NNRVAs
ICAgICAgICAgIFg4Nl9TWU5USCgxMCkpIC8qIFNNRVAgZ2V0cyB1c2VkIGJ5
IFhlbiBpdHNlbGYgKi8KIFhFTl9DUFVGRUFUVVJFKFhFTl9TTUFQLCAgICAg
ICAgICBYODZfU1lOVEgoMTEpKSAvKiBTTUFQIGdldHMgdXNlZCBieSBYZW4g
aXRzZWxmICovCi0vKiBCaXQgMTIgdW51c2VkLiAqLworWEVOX0NQVUZFQVRV
UkUoU0NfTk9fTE9DS19IQVJERU4sIFg4Nl9TWU5USCgxMikpIC8qIChEaXNh
YmxlKSBMb2NrIGNyaXRpY2FsIHJlZ2lvbiBoYXJkZW5pbmcgKi8KIFhFTl9D
UFVGRUFUVVJFKElORF9USFVOS19MRkVOQ0UsICBYODZfU1lOVEgoMTMpKSAv
KiBVc2UgSU5EX1RIVU5LX0xGRU5DRSAqLwogWEVOX0NQVUZFQVRVUkUoSU5E
X1RIVU5LX0pNUCwgICAgIFg4Nl9TWU5USCgxNCkpIC8qIFVzZSBJTkRfVEhV
TktfSk1QICovCiBYRU5fQ1BVRkVBVFVSRShTQ19OT19CUkFOQ0hfSEFSREVO
LCBYODZfU1lOVEgoMTUpKSAvKiAoRGlzYWJsZSkgQ29uZGl0aW9uYWwgYnJh
bmNoIGhhcmRlbmluZyAqLwpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2lu
Y2x1ZGUvYXNtL25vc3BlYy5oIGIveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNt
L25vc3BlYy5oCmluZGV4IDcxNTBlNzZiODdmYi4uMDcyNTgzOWUxOTgyIDEw
MDY0NAotLS0gYS94ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vbm9zcGVjLmgK
KysrIGIveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL25vc3BlYy5oCkBAIC0z
OCw2ICszOCwzMiBAQCBzdGF0aWMgYWx3YXlzX2lubGluZSB2b2lkIGJsb2Nr
X3NwZWN1bGF0aW9uKHZvaWQpCiAgICAgYmFycmllcl9ub3NwZWNfdHJ1ZSgp
OwogfQogCitzdGF0aWMgYWx3YXlzX2lubGluZSB2b2lkIGFyY2hfYmxvY2tf
bG9ja19zcGVjdWxhdGlvbih2b2lkKQoreworICAgIGFsdGVybmF0aXZlKCJs
ZmVuY2UiLCAiIiwgWDg2X0ZFQVRVUkVfU0NfTk9fTE9DS19IQVJERU4pOwor
fQorCisvKiBBbGxvdyB0byBpbnNlcnQgYSByZWFkIG1lbW9yeSBiYXJyaWVy
IGludG8gY29uZGl0aW9uYWxzICovCitzdGF0aWMgYWx3YXlzX2lubGluZSBi
b29sIGJhcnJpZXJfbG9ja190cnVlKHZvaWQpCit7CisgICAgYWx0ZXJuYXRp
dmUoImxmZW5jZSAjbm9zcGVjLXRydWUiLCAiIiwgWDg2X0ZFQVRVUkVfU0Nf
Tk9fTE9DS19IQVJERU4pOworICAgIHJldHVybiB0cnVlOworfQorCitzdGF0
aWMgYWx3YXlzX2lubGluZSBib29sIGJhcnJpZXJfbG9ja19mYWxzZSh2b2lk
KQoreworICAgIGFsdGVybmF0aXZlKCJsZmVuY2UgI25vc3BlYy1mYWxzZSIs
ICIiLCBYODZfRkVBVFVSRV9TQ19OT19MT0NLX0hBUkRFTik7CisgICAgcmV0
dXJuIGZhbHNlOworfQorCitzdGF0aWMgYWx3YXlzX2lubGluZSBib29sIGFy
Y2hfbG9ja19ldmFsdWF0ZV9ub3NwZWMoYm9vbCBjb25kaXRpb24pCit7Cisg
ICAgaWYgKCBjb25kaXRpb24gKQorICAgICAgICByZXR1cm4gYmFycmllcl9s
b2NrX3RydWUoKTsKKyAgICBlbHNlCisgICAgICAgIHJldHVybiBiYXJyaWVy
X2xvY2tfZmFsc2UoKTsKK30KKwogI2VuZGlmIC8qIF9BU01fWDg2X05PU1BF
Q19IICovCiAKIC8qCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYvc3BlY19j
dHJsLmMgYi94ZW4vYXJjaC94ODYvc3BlY19jdHJsLmMKaW5kZXggODE2NTM3
OWZlZDk0Li41ZGZjNGVkNjllYzUgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4
Ni9zcGVjX2N0cmwuYworKysgYi94ZW4vYXJjaC94ODYvc3BlY19jdHJsLmMK
QEAgLTUzLDYgKzUzLDcgQEAgaW50OF90IF9fcmVhZF9tb3N0bHkgb3B0X2Vh
Z2VyX2ZwdSA9IC0xOwogaW50OF90IF9fcmVhZF9tb3N0bHkgb3B0X2wxZF9m
bHVzaCA9IC0xOwogc3RhdGljIGJvb2wgX19pbml0ZGF0YSBvcHRfYnJhbmNo
X2hhcmRlbiA9CiAgICAgSVNfRU5BQkxFRChDT05GSUdfU1BFQ1VMQVRJVkVf
SEFSREVOX0JSQU5DSCk7CitzdGF0aWMgYm9vbCBfX2luaXRkYXRhIG9wdF9s
b2NrX2hhcmRlbjsKIAogYm9vbCBfX2luaXRkYXRhIGJzcF9kZWxheV9zcGVj
X2N0cmw7CiB1aW50OF90IF9fcmVhZF9tb3N0bHkgZGVmYXVsdF94ZW5fc3Bl
Y19jdHJsOwpAQCAtMTIxLDYgKzEyMiw3IEBAIHN0YXRpYyBpbnQgX19pbml0
IGNmX2NoZWNrIHBhcnNlX3NwZWNfY3RybChjb25zdCBjaGFyICpzKQogICAg
ICAgICAgICAgb3B0X3NzYmQgPSBmYWxzZTsKICAgICAgICAgICAgIG9wdF9s
MWRfZmx1c2ggPSAwOwogICAgICAgICAgICAgb3B0X2JyYW5jaF9oYXJkZW4g
PSBmYWxzZTsKKyAgICAgICAgICAgIG9wdF9sb2NrX2hhcmRlbiA9IGZhbHNl
OwogICAgICAgICAgICAgb3B0X3NyYl9sb2NrID0gMDsKICAgICAgICAgICAg
IG9wdF91bnByaXZfbW1pbyA9IGZhbHNlOwogICAgICAgICAgICAgb3B0X2dk
c19taXQgPSAwOwpAQCAtMjg2LDYgKzI4OCwxNiBAQCBzdGF0aWMgaW50IF9f
aW5pdCBjZl9jaGVjayBwYXJzZV9zcGVjX2N0cmwoY29uc3QgY2hhciAqcykK
ICAgICAgICAgICAgICAgICByYyA9IC1FSU5WQUw7CiAgICAgICAgICAgICB9
CiAgICAgICAgIH0KKyAgICAgICAgZWxzZSBpZiAoICh2YWwgPSBwYXJzZV9i
b29sZWFuKCJsb2NrLWhhcmRlbiIsIHMsIHNzKSkgPj0gMCApCisgICAgICAg
IHsKKyAgICAgICAgICAgIGlmICggSVNfRU5BQkxFRChDT05GSUdfU1BFQ1VM
QVRJVkVfSEFSREVOX0xPQ0spICkKKyAgICAgICAgICAgICAgICBvcHRfbG9j
a19oYXJkZW4gPSB2YWw7CisgICAgICAgICAgICBlbHNlCisgICAgICAgICAg
ICB7CisgICAgICAgICAgICAgICAgbm9fY29uZmlnX3BhcmFtKCJTUEVDVUxB
VElWRV9IQVJERU5fTE9DSyIsICJzcGVjLWN0cmwiLCBzLCBzcyk7CisgICAg
ICAgICAgICAgICAgcmMgPSAtRUlOVkFMOworICAgICAgICAgICAgfQorICAg
ICAgICB9CiAgICAgICAgIGVsc2UgaWYgKCAodmFsID0gcGFyc2VfYm9vbGVh
bigic3JiLWxvY2siLCBzLCBzcykpID49IDAgKQogICAgICAgICAgICAgb3B0
X3NyYl9sb2NrID0gdmFsOwogICAgICAgICBlbHNlIGlmICggKHZhbCA9IHBh
cnNlX2Jvb2xlYW4oInVucHJpdi1tbWlvIiwgcywgc3MpKSA+PSAwICkKQEAg
LTQ4OCw3ICs1MDAsOCBAQCBzdGF0aWMgdm9pZCBfX2luaXQgcHJpbnRfZGV0
YWlscyhlbnVtIGluZF90aHVuayB0aHVuaykKICAgICBpZiAoIElTX0VOQUJM
RUQoQ09ORklHX0lORElSRUNUX1RIVU5LKSB8fCBJU19FTkFCTEVEKENPTkZJ
R19TSEFET1dfUEFHSU5HKSB8fAogICAgICAgICAgSVNfRU5BQkxFRChDT05G
SUdfU1BFQ1VMQVRJVkVfSEFSREVOX0FSUkFZKSB8fAogICAgICAgICAgSVNf
RU5BQkxFRChDT05GSUdfU1BFQ1VMQVRJVkVfSEFSREVOX0JSQU5DSCkgfHwK
LSAgICAgICAgIElTX0VOQUJMRUQoQ09ORklHX1NQRUNVTEFUSVZFX0hBUkRF
Tl9HVUVTVF9BQ0NFU1MpICkKKyAgICAgICAgIElTX0VOQUJMRUQoQ09ORklH
X1NQRUNVTEFUSVZFX0hBUkRFTl9HVUVTVF9BQ0NFU1MpIHx8CisgICAgICAg
ICBJU19FTkFCTEVEKENPTkZJR19TUEVDVUxBVElWRV9IQVJERU5fTE9DSykg
KQogICAgICAgICBwcmludGsoIiAgQ29tcGlsZWQtaW4gc3VwcG9ydDoiCiAj
aWZkZWYgQ09ORklHX0lORElSRUNUX1RIVU5LCiAgICAgICAgICAgICAgICAi
IElORElSRUNUX1RIVU5LIgpAQCAtNTA0LDExICs1MTcsMTQgQEAgc3RhdGlj
IHZvaWQgX19pbml0IHByaW50X2RldGFpbHMoZW51bSBpbmRfdGh1bmsgdGh1
bmspCiAjZW5kaWYKICNpZmRlZiBDT05GSUdfU1BFQ1VMQVRJVkVfSEFSREVO
X0dVRVNUX0FDQ0VTUwogICAgICAgICAgICAgICAgIiBIQVJERU5fR1VFU1Rf
QUNDRVNTIgorI2VuZGlmCisjaWZkZWYgQ09ORklHX1NQRUNVTEFUSVZFX0hB
UkRFTl9MT0NLCisgICAgICAgICAgICAgICAiIEhBUkRFTl9MT0NLIgogI2Vu
ZGlmCiAgICAgICAgICAgICAgICAiXG4iKTsKIAogICAgIC8qIFNldHRpbmdz
IGZvciBYZW4ncyBwcm90ZWN0aW9uLCBpcnJlc3BlY3RpdmUgb2YgZ3Vlc3Rz
LiAqLwotICAgIHByaW50aygiICBYZW4gc2V0dGluZ3M6ICVzJXNTUEVDX0NU
Ukw6ICVzJXMlcyVzJXMsIE90aGVyOiVzJXMlcyVzJXMlc1xuIiwKKyAgICBw
cmludGsoIiAgWGVuIHNldHRpbmdzOiAlcyVzU1BFQ19DVFJMOiAlcyVzJXMl
cyVzLCBPdGhlcjolcyVzJXMlcyVzJXMlc1xuIiwKICAgICAgICAgICAgdGh1
bmsgIT0gVEhVTktfTk9ORSAgICAgID8gIkJUSS1UaHVuazogIiA6ICIiLAog
ICAgICAgICAgICB0aHVuayA9PSBUSFVOS19OT05FICAgICAgPyAiIiA6CiAg
ICAgICAgICAgIHRodW5rID09IFRIVU5LX1JFVFBPTElORSA/ICJSRVRQT0xJ
TkUsICIgOgpAQCAtNTM1LDcgKzU1MSw4IEBAIHN0YXRpYyB2b2lkIF9faW5p
dCBwcmludF9kZXRhaWxzKGVudW0gaW5kX3RodW5rIHRodW5rKQogICAgICAg
ICAgICBvcHRfdmVyd19wdiB8fCBvcHRfdmVyd19odm0gfHwKICAgICAgICAg
ICAgb3B0X3ZlcndfbW1pbyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
PyAiIFZFUlciICA6ICIiLAogICAgICAgICAgICBvcHRfZGl2X3NjcnViICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICA/ICIgRElWIiA6ICIiLAotICAg
ICAgICAgICBvcHRfYnJhbmNoX2hhcmRlbiAgICAgICAgICAgICAgICAgICAg
ICAgICA/ICIgQlJBTkNIX0hBUkRFTiIgOiAiIik7CisgICAgICAgICAgIG9w
dF9icmFuY2hfaGFyZGVuICAgICAgICAgICAgICAgICAgICAgICAgID8gIiBC
UkFOQ0hfSEFSREVOIiA6ICIiLAorICAgICAgICAgICBvcHRfbG9ja19oYXJk
ZW4gICAgICAgICAgICAgICAgICAgICAgICAgICA/ICIgTE9DS19IQVJERU4i
IDogIiIpOwogCiAgICAgLyogTDFURiBkaWFnbm9zdGljcywgcHJpbnRlZCBp
ZiB2dWxuZXJhYmxlIG9yIFBWIHNoYWRvd2luZyBpcyBpbiB1c2UuICovCiAg
ICAgaWYgKCBjcHVfaGFzX2J1Z19sMXRmIHx8IG9wdF9wdl9sMXRmX2h3ZG9t
IHx8IG9wdF9wdl9sMXRmX2RvbXUgKQpAQCAtMTkxOCw2ICsxOTM1LDkgQEAg
dm9pZCBfX2luaXQgaW5pdF9zcGVjdWxhdGlvbl9taXRpZ2F0aW9ucyh2b2lk
KQogICAgIGlmICggIW9wdF9icmFuY2hfaGFyZGVuICkKICAgICAgICAgc2V0
dXBfZm9yY2VfY3B1X2NhcChYODZfRkVBVFVSRV9TQ19OT19CUkFOQ0hfSEFS
REVOKTsKIAorICAgIGlmICggIW9wdF9sb2NrX2hhcmRlbiApCisgICAgICAg
IHNldHVwX2ZvcmNlX2NwdV9jYXAoWDg2X0ZFQVRVUkVfU0NfTk9fTE9DS19I
QVJERU4pOworCiAgICAgLyoKICAgICAgKiBXZSBkbyBub3QgZGlzYWJsZSBI
VCBieSBkZWZhdWx0IG9uIGFmZmVjdGVkIGhhcmR3YXJlLgogICAgICAqCmRp
ZmYgLS1naXQgYS94ZW4vY29tbW9uL0tjb25maWcgYi94ZW4vY29tbW9uL0tj
b25maWcKaW5kZXggNGQ2ZmUwNTE2NDFkLi4zMzYxYTZkODkyNTcgMTAwNjQ0
Ci0tLSBhL3hlbi9jb21tb24vS2NvbmZpZworKysgYi94ZW4vY29tbW9uL0tj
b25maWcKQEAgLTE4OCw2ICsxODgsMjMgQEAgY29uZmlnIFNQRUNVTEFUSVZF
X0hBUkRFTl9HVUVTVF9BQ0NFU1MKIAogCSAgSWYgdW5zdXJlLCBzYXkgWS4K
IAorY29uZmlnIFNQRUNVTEFUSVZFX0hBUkRFTl9MT0NLCisJYm9vbCAiU3Bl
Y3VsYXRpdmUgbG9jayBjb250ZXh0IGhhcmRlbmluZyIKKwlkZWZhdWx0IHkK
KwlkZXBlbmRzIG9uIFg4NgorCWhlbHAKKwkgIENvbnRlbXBvcmFyeSBwcm9j
ZXNzb3JzIG1heSB1c2Ugc3BlY3VsYXRpdmUgZXhlY3V0aW9uIGFzIGEKKwkg
IHBlcmZvcm1hbmNlIG9wdGltaXNhdGlvbiwgYnV0IHRoaXMgY2FuIHBvdGVu
dGlhbGx5IGJlIGFidXNlZCBieSBhbgorCSAgYXR0YWNrZXIgdG8gbGVhayBk
YXRhIHZpYSBzcGVjdWxhdGl2ZSBzaWRlY2hhbm5lbHMuCisKKwkgIE9uZSBz
b3VyY2Ugb2YgZGF0YSBsZWFrYWdlIGlzIHZpYSBzcGVjdWxhdGl2ZSBhY2Nl
c3NlcyB0byBsb2NrCisJICBjcml0aWNhbCByZWdpb25zLgorCisJICBUaGlz
IG9wdGlvbiBpcyBkaXNhYmxlZCBieSBkZWZhdWx0IGF0IHJ1biB0aW1lLCBh
bmQgbmVlZHMgdG8gYmUKKwkgIGVuYWJsZWQgb24gdGhlIGNvbW1hbmQgbGlu
ZS4KKworCSAgSWYgdW5zdXJlLCBzYXkgWS4KKwogZW5kbWVudQogCiBjb25m
aWcgRElUX0RFRkFVTFQKZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL3hlbi9u
b3NwZWMuaCBiL3hlbi9pbmNsdWRlL3hlbi9ub3NwZWMuaAppbmRleCA3NjI1
NWJjNDZlZmUuLjQ1NTI4NDY0MDM5NiAxMDA2NDQKLS0tIGEveGVuL2luY2x1
ZGUveGVuL25vc3BlYy5oCisrKyBiL3hlbi9pbmNsdWRlL3hlbi9ub3NwZWMu
aApAQCAtNzAsNiArNzAsMjEgQEAgc3RhdGljIGlubGluZSB1bnNpZ25lZCBs
b25nIGFycmF5X2luZGV4X21hc2tfbm9zcGVjKHVuc2lnbmVkIGxvbmcgaW5k
ZXgsCiAjZGVmaW5lIGFycmF5X2FjY2Vzc19ub3NwZWMoYXJyYXksIGluZGV4
KSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgKGFycmF5
KVthcnJheV9pbmRleF9ub3NwZWMoaW5kZXgsIEFSUkFZX1NJWkUoYXJyYXkp
KV0KIAorc3RhdGljIGFsd2F5c19pbmxpbmUgdm9pZCBibG9ja19sb2NrX3Nw
ZWN1bGF0aW9uKHZvaWQpCit7CisjaWZkZWYgQ09ORklHX1NQRUNVTEFUSVZF
X0hBUkRFTl9MT0NLCisgICAgYXJjaF9ibG9ja19sb2NrX3NwZWN1bGF0aW9u
KCk7CisjZW5kaWYKK30KKworc3RhdGljIGFsd2F5c19pbmxpbmUgYm9vbCBs
b2NrX2V2YWx1YXRlX25vc3BlYyhib29sIGNvbmRpdGlvbikKK3sKKyNpZmRl
ZiBDT05GSUdfU1BFQ1VMQVRJVkVfSEFSREVOX0xPQ0sKKyAgICByZXR1cm4g
YXJjaF9sb2NrX2V2YWx1YXRlX25vc3BlYyhjb25kaXRpb24pOworI2VuZGlm
CisgICAgcmV0dXJuIGNvbmRpdGlvbjsKK30KKwogI2VuZGlmIC8qIFhFTl9O
T1NQRUNfSCAqLwogCiAvKgpkaWZmIC0tZ2l0IGEveGVuL2luY2x1ZGUveGVu
L3NwaW5sb2NrLmggYi94ZW4vaW5jbHVkZS94ZW4vc3BpbmxvY2suaAppbmRl
eCBlN2ExYzFhYTg5ODguLjI4ZmNlNTYxNWU1YyAxMDA2NDQKLS0tIGEveGVu
L2luY2x1ZGUveGVuL3NwaW5sb2NrLmgKKysrIGIveGVuL2luY2x1ZGUveGVu
L3NwaW5sb2NrLmgKQEAgLTEsNiArMSw3IEBACiAjaWZuZGVmIF9fU1BJTkxP
Q0tfSF9fCiAjZGVmaW5lIF9fU1BJTkxPQ0tfSF9fCiAKKyNpbmNsdWRlIDx4
ZW4vbm9zcGVjLmg+CiAjaW5jbHVkZSA8eGVuL3RpbWUuaD4KICNpbmNsdWRl
IDx4ZW4vdHlwZXMuaD4KIApAQCAtMTk1LDEzICsxOTYsMzAgQEAgaW50IF9z
cGluX3RyeWxvY2tfcmVjdXJzaXZlKHNwaW5sb2NrX3QgKmxvY2spOwogdm9p
ZCBfc3Bpbl9sb2NrX3JlY3Vyc2l2ZShzcGlubG9ja190ICpsb2NrKTsKIHZv
aWQgX3NwaW5fdW5sb2NrX3JlY3Vyc2l2ZShzcGlubG9ja190ICpsb2NrKTsK
IAotI2RlZmluZSBzcGluX2xvY2sobCkgICAgICAgICAgICAgICAgICBfc3Bp
bl9sb2NrKGwpCi0jZGVmaW5lIHNwaW5fbG9ja19jYihsLCBjLCBkKSAgICAg
ICAgIF9zcGluX2xvY2tfY2IobCwgYywgZCkKLSNkZWZpbmUgc3Bpbl9sb2Nr
X2lycShsKSAgICAgICAgICAgICAgX3NwaW5fbG9ja19pcnEobCkKK3N0YXRp
YyBhbHdheXNfaW5saW5lIHZvaWQgc3Bpbl9sb2NrKHNwaW5sb2NrX3QgKmwp
Cit7CisgICAgX3NwaW5fbG9jayhsKTsKKyAgICBibG9ja19sb2NrX3NwZWN1
bGF0aW9uKCk7Cit9CisKK3N0YXRpYyBhbHdheXNfaW5saW5lIHZvaWQgc3Bp
bl9sb2NrX2NiKHNwaW5sb2NrX3QgKmwsIHZvaWQgKCpjKSh2b2lkICpkYXRh
KSwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHZv
aWQgKmQpCit7CisgICAgX3NwaW5fbG9ja19jYihsLCBjLCBkKTsKKyAgICBi
bG9ja19sb2NrX3NwZWN1bGF0aW9uKCk7Cit9CisKK3N0YXRpYyBhbHdheXNf
aW5saW5lIHZvaWQgc3Bpbl9sb2NrX2lycShzcGlubG9ja190ICpsKQorewor
ICAgIF9zcGluX2xvY2tfaXJxKGwpOworICAgIGJsb2NrX2xvY2tfc3BlY3Vs
YXRpb24oKTsKK30KKwogI2RlZmluZSBzcGluX2xvY2tfaXJxc2F2ZShsLCBm
KSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKICAgICAoeyAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBcCiAgICAgICAgIEJVSUxEX0JVR19PTihzaXplb2YoZikg
IT0gc2l6ZW9mKHVuc2lnbmVkIGxvbmcpKTsgICAgICAgXAogICAgICAgICAo
KGYpID0gX3NwaW5fbG9ja19pcnFzYXZlKGwpKTsgICAgICAgICAgICAgICAg
ICAgICAgICAgIFwKKyAgICAgICAgYmxvY2tfbG9ja19zcGVjdWxhdGlvbigp
OyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgfSkKIAog
I2RlZmluZSBzcGluX3VubG9jayhsKSAgICAgICAgICAgICAgICBfc3Bpbl91
bmxvY2sobCkKQEAgLTIwOSw3ICsyMjcsNyBAQCB2b2lkIF9zcGluX3VubG9j
a19yZWN1cnNpdmUoc3BpbmxvY2tfdCAqbG9jayk7CiAjZGVmaW5lIHNwaW5f
dW5sb2NrX2lycXJlc3RvcmUobCwgZikgIF9zcGluX3VubG9ja19pcnFyZXN0
b3JlKGwsIGYpCiAKICNkZWZpbmUgc3Bpbl9pc19sb2NrZWQobCkgICAgICAg
ICAgICAgX3NwaW5faXNfbG9ja2VkKGwpCi0jZGVmaW5lIHNwaW5fdHJ5bG9j
ayhsKSAgICAgICAgICAgICAgIF9zcGluX3RyeWxvY2sobCkKKyNkZWZpbmUg
c3Bpbl90cnlsb2NrKGwpICAgICAgICAgICAgICAgbG9ja19ldmFsdWF0ZV9u
b3NwZWMoX3NwaW5fdHJ5bG9jayhsKSkKIAogI2RlZmluZSBzcGluX3RyeWxv
Y2tfaXJxc2F2ZShsb2NrLCBmbGFncykgICAgICAgXAogKHsgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXApAQCAtMjMw
LDggKzI0OCwxNSBAQCB2b2lkIF9zcGluX3VubG9ja19yZWN1cnNpdmUoc3Bp
bmxvY2tfdCAqbG9jayk7CiAgKiBhcmUgYW55IGNyaXRpY2FsIHJlZ2lvbnMg
dGhhdCBjYW5ub3QgZm9ybSBwYXJ0IG9mIHN1Y2ggYSBzZXQsIHRoZXkgY2Fu
IHVzZQogICogc3RhbmRhcmQgc3Bpbl9bdW5dbG9jaygpLgogICovCi0jZGVm
aW5lIHNwaW5fdHJ5bG9ja19yZWN1cnNpdmUobCkgICAgIF9zcGluX3RyeWxv
Y2tfcmVjdXJzaXZlKGwpCi0jZGVmaW5lIHNwaW5fbG9ja19yZWN1cnNpdmUo
bCkgICAgICAgIF9zcGluX2xvY2tfcmVjdXJzaXZlKGwpCisjZGVmaW5lIHNw
aW5fdHJ5bG9ja19yZWN1cnNpdmUobCkgXAorICAgIGxvY2tfZXZhbHVhdGVf
bm9zcGVjKF9zcGluX3RyeWxvY2tfcmVjdXJzaXZlKGwpKQorCitzdGF0aWMg
YWx3YXlzX2lubGluZSB2b2lkIHNwaW5fbG9ja19yZWN1cnNpdmUoc3Bpbmxv
Y2tfdCAqbCkKK3sKKyAgICBfc3Bpbl9sb2NrX3JlY3Vyc2l2ZShsKTsKKyAg
ICBibG9ja19sb2NrX3NwZWN1bGF0aW9uKCk7Cit9CisKICNkZWZpbmUgc3Bp
bl91bmxvY2tfcmVjdXJzaXZlKGwpICAgICAgX3NwaW5fdW5sb2NrX3JlY3Vy
c2l2ZShsKQogCiAjZW5kaWYgLyogX19TUElOTE9DS19IX18gKi8K

--=separator
Content-Type: application/octet-stream; name="xsa453/xsa453-4.18-3.patch"
Content-Disposition: attachment; filename="xsa453/xsa453-4.18-3.patch"
Content-Transfer-Encoding: base64

RnJvbTogPT9VVEYtOD9xP1JvZ2VyPTIwUGF1PTIwTW9ubj1DMz1BOT89IDxy
b2dlci5wYXVAY2l0cml4LmNvbT4KU3ViamVjdDogcndsb2NrOiBpbnRyb2R1
Y2Ugc3VwcG9ydCBmb3IgYmxvY2tpbmcgc3BlY3VsYXRpb24gaW50byBjcml0
aWNhbAogcmVnaW9ucwoKSW50cm9kdWNlIGlubGluZSB3cmFwcGVycyBhcyBy
ZXF1aXJlZCBhbmQgYWRkIGRpcmVjdCBjYWxscyB0bwpibG9ja19sb2NrX3Nw
ZWN1bGF0aW9uKCkgaW4gb3JkZXIgdG8gcHJldmVudCBzcGVjdWxhdGlvbiBp
bnRvIHRoZSByd2xvY2sKcHJvdGVjdGVkIGNyaXRpY2FsIHJlZ2lvbnMuCgpO
b3RlIHRoZSByd2xvY2sgcHJpbWl0aXZlcyBhcmUgYWRqdXN0ZWQgdG8gdXNl
IHRoZSBub24gc3BlY3VsYXRpb24gc2FmZSB2YXJpYW50cwpvZiB0aGUgc3Bp
bmxvY2sgaGFuZGxlcnMsIGFzIGEgc3BlY3VsYXRpb24gYmFycmllciBpcyBh
ZGRlZCBpbiB0aGUgcndsb2NrCmNhbGxpbmcgd3JhcHBlcnMuCgp0cnlsb2Nr
IHZhcmlhbnRzIGFyZSBwcm90ZWN0ZWQgYnkgdXNpbmcgbG9ja19ldmFsdWF0
ZV9ub3NwZWMoKS4KClRoaXMgaXMgcGFydCBvZiBYU0EtNDUzIC8gQ1ZFLTIw
MjQtMjE5MwoKU2lnbmVkLW9mZi1ieTogUm9nZXIgUGF1IE1vbm7DqSA8cm9n
ZXIucGF1QGNpdHJpeC5jb20+ClJldmlld2VkLWJ5OiBKYW4gQmV1bGljaCA8
amJldWxpY2hAc3VzZS5jb20+CihjaGVycnkgcGlja2VkIGZyb20gY29tbWl0
IGExZmIxNWY2MTY5MmIxZmE5OTQ1ZmM1MWY1NTQ3MWFjZTQ5Y2RkNTkpCgpk
aWZmIC0tZ2l0IGEveGVuL2NvbW1vbi9yd2xvY2suYyBiL3hlbi9jb21tb24v
cndsb2NrLmMKaW5kZXggMTgyMjRhNGJiNWQ2Li4yOTA2MDI5MzZkZjYgMTAw
NjQ0Ci0tLSBhL3hlbi9jb21tb24vcndsb2NrLmMKKysrIGIveGVuL2NvbW1v
bi9yd2xvY2suYwpAQCAtMzQsOCArMzQsMTEgQEAgdm9pZCBxdWV1ZV9yZWFk
X2xvY2tfc2xvd3BhdGgocndsb2NrX3QgKmxvY2spCiAKICAgICAvKgogICAg
ICAqIFB1dCB0aGUgcmVhZGVyIGludG8gdGhlIHdhaXQgcXVldWUuCisgICAg
ICoKKyAgICAgKiBVc2UgdGhlIHNwZWN1bGF0aW9uIHVuc2FmZSBoZWxwZXIs
IGFzIGl0J3MgdGhlIGNhbGxlciByZXNwb25zaWJpbGl0eSB0bworICAgICAq
IGlzc3VlIGEgc3BlY3VsYXRpb24gYmFycmllciBpZiByZXF1aXJlZC4KICAg
ICAgKi8KLSAgICBzcGluX2xvY2soJmxvY2stPmxvY2spOworICAgIF9zcGlu
X2xvY2soJmxvY2stPmxvY2spOwogCiAgICAgLyoKICAgICAgKiBBdCB0aGUg
aGVhZCBvZiB0aGUgd2FpdCBxdWV1ZSBub3csIHdhaXQgdW50aWwgdGhlIHdy
aXRlciBzdGF0ZQpAQCAtNjYsOCArNjksMTMgQEAgdm9pZCBxdWV1ZV93cml0
ZV9sb2NrX3Nsb3dwYXRoKHJ3bG9ja190ICpsb2NrKQogewogICAgIHUzMiBj
bnRzOwogCi0gICAgLyogUHV0IHRoZSB3cml0ZXIgaW50byB0aGUgd2FpdCBx
dWV1ZS4gKi8KLSAgICBzcGluX2xvY2soJmxvY2stPmxvY2spOworICAgIC8q
CisgICAgICogUHV0IHRoZSB3cml0ZXIgaW50byB0aGUgd2FpdCBxdWV1ZS4K
KyAgICAgKgorICAgICAqIFVzZSB0aGUgc3BlY3VsYXRpb24gdW5zYWZlIGhl
bHBlciwgYXMgaXQncyB0aGUgY2FsbGVyIHJlc3BvbnNpYmlsaXR5IHRvCisg
ICAgICogaXNzdWUgYSBzcGVjdWxhdGlvbiBiYXJyaWVyIGlmIHJlcXVpcmVk
LgorICAgICAqLworICAgIF9zcGluX2xvY2soJmxvY2stPmxvY2spOwogCiAg
ICAgLyogVHJ5IHRvIGFjcXVpcmUgdGhlIGxvY2sgZGlyZWN0bHkgaWYgbm8g
cmVhZGVyIGlzIHByZXNlbnQuICovCiAgICAgaWYgKCAhYXRvbWljX3JlYWQo
JmxvY2stPmNudHMpICYmCmRpZmYgLS1naXQgYS94ZW4vaW5jbHVkZS94ZW4v
cndsb2NrLmggYi94ZW4vaW5jbHVkZS94ZW4vcndsb2NrLmgKaW5kZXggZTBk
MmI0MWM1YzdlLi45YTBkM2VjMjM4NDcgMTAwNjQ0Ci0tLSBhL3hlbi9pbmNs
dWRlL3hlbi9yd2xvY2suaAorKysgYi94ZW4vaW5jbHVkZS94ZW4vcndsb2Nr
LmgKQEAgLTI1OSwyNyArMjU5LDQ5IEBAIHN0YXRpYyBpbmxpbmUgaW50IF9y
d19pc193cml0ZV9sb2NrZWQoY29uc3Qgcndsb2NrX3QgKmxvY2spCiAgICAg
cmV0dXJuIChhdG9taWNfcmVhZCgmbG9jay0+Y250cykgJiBfUVdfV01BU0sp
ID09IF9RV19MT0NLRUQ7CiB9CiAKLSNkZWZpbmUgcmVhZF9sb2NrKGwpICAg
ICAgICAgICAgICAgICAgX3JlYWRfbG9jayhsKQotI2RlZmluZSByZWFkX2xv
Y2tfaXJxKGwpICAgICAgICAgICAgICBfcmVhZF9sb2NrX2lycShsKQorc3Rh
dGljIGFsd2F5c19pbmxpbmUgdm9pZCByZWFkX2xvY2socndsb2NrX3QgKmwp
Cit7CisgICAgX3JlYWRfbG9jayhsKTsKKyAgICBibG9ja19sb2NrX3NwZWN1
bGF0aW9uKCk7Cit9CisKK3N0YXRpYyBhbHdheXNfaW5saW5lIHZvaWQgcmVh
ZF9sb2NrX2lycShyd2xvY2tfdCAqbCkKK3sKKyAgICBfcmVhZF9sb2NrX2ly
cShsKTsKKyAgICBibG9ja19sb2NrX3NwZWN1bGF0aW9uKCk7Cit9CisKICNk
ZWZpbmUgcmVhZF9sb2NrX2lycXNhdmUobCwgZikgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBcCiAgICAgKHsgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAogICAg
ICAgICBCVUlMRF9CVUdfT04oc2l6ZW9mKGYpICE9IHNpemVvZih1bnNpZ25l
ZCBsb25nKSk7ICAgICAgIFwKICAgICAgICAgKChmKSA9IF9yZWFkX2xvY2tf
aXJxc2F2ZShsKSk7ICAgICAgICAgICAgICAgICAgICAgICAgICBcCisgICAg
ICAgIGJsb2NrX2xvY2tfc3BlY3VsYXRpb24oKTsgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgXAogICAgIH0pCiAKICNkZWZpbmUgcmVhZF91bmxv
Y2sobCkgICAgICAgICAgICAgICAgX3JlYWRfdW5sb2NrKGwpCiAjZGVmaW5l
IHJlYWRfdW5sb2NrX2lycShsKSAgICAgICAgICAgIF9yZWFkX3VubG9ja19p
cnEobCkKICNkZWZpbmUgcmVhZF91bmxvY2tfaXJxcmVzdG9yZShsLCBmKSAg
X3JlYWRfdW5sb2NrX2lycXJlc3RvcmUobCwgZikKLSNkZWZpbmUgcmVhZF90
cnlsb2NrKGwpICAgICAgICAgICAgICAgX3JlYWRfdHJ5bG9jayhsKQorI2Rl
ZmluZSByZWFkX3RyeWxvY2sobCkgICAgICAgICAgICAgICBsb2NrX2V2YWx1
YXRlX25vc3BlYyhfcmVhZF90cnlsb2NrKGwpKQorCitzdGF0aWMgYWx3YXlz
X2lubGluZSB2b2lkIHdyaXRlX2xvY2socndsb2NrX3QgKmwpCit7CisgICAg
X3dyaXRlX2xvY2sobCk7CisgICAgYmxvY2tfbG9ja19zcGVjdWxhdGlvbigp
OworfQorCitzdGF0aWMgYWx3YXlzX2lubGluZSB2b2lkIHdyaXRlX2xvY2tf
aXJxKHJ3bG9ja190ICpsKQoreworICAgIF93cml0ZV9sb2NrX2lycShsKTsK
KyAgICBibG9ja19sb2NrX3NwZWN1bGF0aW9uKCk7Cit9CiAKLSNkZWZpbmUg
d3JpdGVfbG9jayhsKSAgICAgICAgICAgICAgICAgX3dyaXRlX2xvY2sobCkK
LSNkZWZpbmUgd3JpdGVfbG9ja19pcnEobCkgICAgICAgICAgICAgX3dyaXRl
X2xvY2tfaXJxKGwpCiAjZGVmaW5lIHdyaXRlX2xvY2tfaXJxc2F2ZShsLCBm
KSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAogICAgICh7ICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIFwKICAgICAgICAgQlVJTERfQlVHX09OKHNpemVvZihmKSAh
PSBzaXplb2YodW5zaWduZWQgbG9uZykpOyAgICAgICBcCiAgICAgICAgICgo
ZikgPSBfd3JpdGVfbG9ja19pcnFzYXZlKGwpKTsgICAgICAgICAgICAgICAg
ICAgICAgICAgXAorICAgICAgICBibG9ja19sb2NrX3NwZWN1bGF0aW9uKCk7
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKICAgICB9KQotI2Rl
ZmluZSB3cml0ZV90cnlsb2NrKGwpICAgICAgICAgICAgICBfd3JpdGVfdHJ5
bG9jayhsKQorI2RlZmluZSB3cml0ZV90cnlsb2NrKGwpICAgICAgICAgICAg
ICBsb2NrX2V2YWx1YXRlX25vc3BlYyhfd3JpdGVfdHJ5bG9jayhsKSkKIAog
I2RlZmluZSB3cml0ZV91bmxvY2sobCkgICAgICAgICAgICAgICBfd3JpdGVf
dW5sb2NrKGwpCiAjZGVmaW5lIHdyaXRlX3VubG9ja19pcnEobCkgICAgICAg
ICAgIF93cml0ZV91bmxvY2tfaXJxKGwpCg==

--=separator
Content-Type: application/octet-stream; name="xsa453/xsa453-4.18-4.patch"
Content-Disposition: attachment; filename="xsa453/xsa453-4.18-4.patch"
Content-Transfer-Encoding: base64

RnJvbTogPT9VVEYtOD9xP1JvZ2VyPTIwUGF1PTIwTW9ubj1DMz1BOT89IDxy
b2dlci5wYXVAY2l0cml4LmNvbT4KU3ViamVjdDogcGVyY3B1LXJ3bG9jazog
aW50cm9kdWNlIHN1cHBvcnQgZm9yIGJsb2NraW5nIHNwZWN1bGF0aW9uIGlu
dG8KIGNyaXRpY2FsIHJlZ2lvbnMKCkFkZCBkaXJlY3QgY2FsbHMgdG8gYmxv
Y2tfbG9ja19zcGVjdWxhdGlvbigpIHdoZXJlIHJlcXVpcmVkIGluIG9yZGVy
IHRvIHByZXZlbnQKc3BlY3VsYXRpb24gaW50byB0aGUgbG9jayBwcm90ZWN0
ZWQgY3JpdGljYWwgcmVnaW9ucy4gIEFsc28gY29udmVydApfcGVyY3B1X3Jl
YWRfbG9jaygpIGZyb20gaW5saW5lIHRvIGFsd2F5c19pbmxpbmUuCgpOb3Rl
IHRoYXQgX3BlcmNwdV93cml0ZV9sb2NrKCkgaGFzIGJlZW4gbW9kaWZpZWQg
dGhlIHVzZSB0aGUgbm9uIHNwZWN1bGF0aW9uCnNhZmUgb2YgdGhlIGxvY2tp
bmcgcHJpbWl0ZXMsIGFzIGEgc3BlY3VsYXRpb24gaXMgYWRkZWQgdW5jb25k
aXRpb25hbGx5IGJ5IHRoZQpjYWxsaW5nIHdyYXBwZXIuCgpUaGlzIGlzIHBh
cnQgb2YgWFNBLTQ1MyAvIENWRS0yMDI0LTIxOTMKClNpZ25lZC1vZmYtYnk6
IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXguY29tPgpSZXZp
ZXdlZC1ieTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgooY2hl
cnJ5IHBpY2tlZCBmcm9tIGNvbW1pdCBmMjE4ZGFmNmQzYTNiODQ3NzM2ZDM3
YzZhNmI3NjAzMWEwZDA4NDQxKQoKZGlmZiAtLWdpdCBhL3hlbi9jb21tb24v
cndsb2NrLmMgYi94ZW4vY29tbW9uL3J3bG9jay5jCmluZGV4IDI5MDYwMjkz
NmRmNi4uZjVhMjQ5YmNjMjQwIDEwMDY0NAotLS0gYS94ZW4vY29tbW9uL3J3
bG9jay5jCisrKyBiL3hlbi9jb21tb24vcndsb2NrLmMKQEAgLTEyOSw4ICsx
MjksMTIgQEAgdm9pZCBfcGVyY3B1X3dyaXRlX2xvY2socGVyY3B1X3J3bG9j
a190ICoqcGVyX2NwdWRhdGEsCiAgICAgLyoKICAgICAgKiBGaXJzdCB0YWtl
IHRoZSB3cml0ZSBsb2NrIHRvIHByb3RlY3QgYWdhaW5zdCBvdGhlciB3cml0
ZXJzIG9yIHNsb3cKICAgICAgKiBwYXRoIHJlYWRlcnMuCisgICAgICoKKyAg
ICAgKiBOb3RlIHdlIHVzZSB0aGUgc3BlY3VsYXRpb24gdW5zYWZlIHZhcmlh
bnQgb2Ygd3JpdGVfbG9jaygpLCBhcyB0aGUKKyAgICAgKiBjYWxsaW5nIHdy
YXBwZXIgYWxyZWFkeSBhZGRzIGEgc3BlY3VsYXRpb24gYmFycmllciBhZnRl
ciB0aGUgbG9jayBoYXMKKyAgICAgKiBiZWVuIHRha2VuLgogICAgICAqLwot
ICAgIHdyaXRlX2xvY2soJnBlcmNwdV9yd2xvY2stPnJ3bG9jayk7CisgICAg
X3dyaXRlX2xvY2soJnBlcmNwdV9yd2xvY2stPnJ3bG9jayk7CiAKICAgICAv
KiBOb3cgc2V0IHRoZSBnbG9iYWwgdmFyaWFibGUgc28gdGhhdCByZWFkZXJz
IHN0YXJ0IHVzaW5nIHJlYWRfbG9jay4gKi8KICAgICBwZXJjcHVfcndsb2Nr
LT53cml0ZXJfYWN0aXZhdGluZyA9IDE7CmRpZmYgLS1naXQgYS94ZW4vaW5j
bHVkZS94ZW4vcndsb2NrLmggYi94ZW4vaW5jbHVkZS94ZW4vcndsb2NrLmgK
aW5kZXggOWEwZDNlYzIzODQ3Li45ZTM1ZWUyZWRmOGYgMTAwNjQ0Ci0tLSBh
L3hlbi9pbmNsdWRlL3hlbi9yd2xvY2suaAorKysgYi94ZW4vaW5jbHVkZS94
ZW4vcndsb2NrLmgKQEAgLTMzOCw4ICszMzgsOCBAQCBzdGF0aWMgaW5saW5l
IHZvaWQgX3BlcmNwdV9yd2xvY2tfb3duZXJfY2hlY2socGVyY3B1X3J3bG9j
a190ICoqcGVyX2NwdWRhdGEsCiAjZGVmaW5lIHBlcmNwdV9yd2xvY2tfcmVz
b3VyY2VfaW5pdChsLCBvd25lcikgXAogICAgICgqKGwpID0gKHBlcmNwdV9y
d2xvY2tfdClQRVJDUFVfUldfTE9DS19VTkxPQ0tFRCgmZ2V0X3Blcl9jcHVf
dmFyKG93bmVyKSkpCiAKLXN0YXRpYyBpbmxpbmUgdm9pZCBfcGVyY3B1X3Jl
YWRfbG9jayhwZXJjcHVfcndsb2NrX3QgKipwZXJfY3B1ZGF0YSwKLSAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcGVyY3B1X3J3
bG9ja190ICpwZXJjcHVfcndsb2NrKQorc3RhdGljIGFsd2F5c19pbmxpbmUg
dm9pZCBfcGVyY3B1X3JlYWRfbG9jayhwZXJjcHVfcndsb2NrX3QgKipwZXJf
Y3B1ZGF0YSwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgcGVyY3B1X3J3bG9ja190ICpwZXJjcHVfcndsb2NrKQogewog
ICAgIC8qIFZhbGlkYXRlIHRoZSBjb3JyZWN0IHBlcl9jcHVkYXRhIHZhcmlh
YmxlIGhhcyBiZWVuIHByb3ZpZGVkLiAqLwogICAgIF9wZXJjcHVfcndsb2Nr
X293bmVyX2NoZWNrKHBlcl9jcHVkYXRhLCBwZXJjcHVfcndsb2NrKTsKQEAg
LTM3NCw2ICszNzQsOCBAQCBzdGF0aWMgaW5saW5lIHZvaWQgX3BlcmNwdV9y
ZWFkX2xvY2socGVyY3B1X3J3bG9ja190ICoqcGVyX2NwdWRhdGEsCiAgICAg
fQogICAgIGVsc2UKICAgICB7CisgICAgICAgIC8qIE90aGVyIGJyYW5jaCBh
bHJlYWR5IGhhcyBhIHNwZWN1bGF0aW9uIGJhcnJpZXIgaW4gcmVhZF9sb2Nr
KCkuICovCisgICAgICAgIGJsb2NrX2xvY2tfc3BlY3VsYXRpb24oKTsKICAg
ICAgICAgLyogQWxsIG90aGVyIHBhdGhzIGhhdmUgaW1wbGljaXQgY2hlY2tf
bG9jaygpIGNhbGxzIHZpYSByZWFkX2xvY2soKS4gKi8KICAgICAgICAgY2hl
Y2tfbG9jaygmcGVyY3B1X3J3bG9jay0+cndsb2NrLmxvY2suZGVidWcsIGZh
bHNlKTsKICAgICB9CkBAIC00MzAsOCArNDMyLDEyIEBAIHN0YXRpYyBpbmxp
bmUgdm9pZCBfcGVyY3B1X3dyaXRlX3VubG9jayhwZXJjcHVfcndsb2NrX3Qg
KipwZXJfY3B1ZGF0YSwKICAgICBfcGVyY3B1X3JlYWRfbG9jaygmZ2V0X3Bl
cl9jcHVfdmFyKHBlcmNwdSksIGxvY2spCiAjZGVmaW5lIHBlcmNwdV9yZWFk
X3VubG9jayhwZXJjcHUsIGxvY2spIFwKICAgICBfcGVyY3B1X3JlYWRfdW5s
b2NrKCZnZXRfcGVyX2NwdV92YXIocGVyY3B1KSwgbG9jaykKLSNkZWZpbmUg
cGVyY3B1X3dyaXRlX2xvY2socGVyY3B1LCBsb2NrKSBcCi0gICAgX3BlcmNw
dV93cml0ZV9sb2NrKCZnZXRfcGVyX2NwdV92YXIocGVyY3B1KSwgbG9jaykK
KworI2RlZmluZSBwZXJjcHVfd3JpdGVfbG9jayhwZXJjcHUsIGxvY2spICAg
ICAgICAgICAgICAgICBcCisoeyAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKKyAgICBfcGVyY3B1X3dy
aXRlX2xvY2soJmdldF9wZXJfY3B1X3ZhcihwZXJjcHUpLCBsb2NrKTsgXAor
ICAgIGJsb2NrX2xvY2tfc3BlY3VsYXRpb24oKTsgICAgICAgICAgICAgICAg
ICAgICAgICAgICBcCit9KQogI2RlZmluZSBwZXJjcHVfd3JpdGVfdW5sb2Nr
KHBlcmNwdSwgbG9jaykgXAogICAgIF9wZXJjcHVfd3JpdGVfdW5sb2NrKCZn
ZXRfcGVyX2NwdV92YXIocGVyY3B1KSwgbG9jaykKIAo=

--=separator
Content-Type: application/octet-stream; name="xsa453/xsa453-4.18-5.patch"
Content-Disposition: attachment; filename="xsa453/xsa453-4.18-5.patch"
Content-Transfer-Encoding: base64

RnJvbTogPT9VVEYtOD9xP1JvZ2VyPTIwUGF1PTIwTW9ubj1DMz1BOT89IDxy
b2dlci5wYXVAY2l0cml4LmNvbT4KU3ViamVjdDogbG9ja2luZzogYXR0ZW1w
dCB0byBlbnN1cmUgbG9jayB3cmFwcGVycyBhcmUgYWx3YXlzIGlubGluZQoK
SW4gb3JkZXIgdG8gcHJldmVudCB0aGUgbG9ja2luZyBzcGVjdWxhdGlvbiBi
YXJyaWVycyBmcm9tIGJlaW5nIGluc2lkZSBvZgpgY2FsbGBlZCBmdW5jdGlv
bnMgdGhhdCBjb3VsZCBiZSBzcGVjdWxhdGl2ZWx5IGJ5cGFzc2VkLgoKV2hp
bGUgdGhlcmUgYWxzbyBhZGQgYW4gZXh0cmEgbG9ja2luZyBiYXJyaWVyIHRv
IF9tbV93cml0ZV9sb2NrKCkgaW4gdGhlIGJyYW5jaAp0YWtlbiB3aGVuIHRo
ZSBsb2NrIGlzIGFscmVhZHkgaGVsZC4KCk5vdGUgc29tZSBmdW5jdGlvbnMg
YXJlIHN3aXRjaGVkIHRvIHVzZSB0aGUgdW5zYWZlIHZhcmlhbnRzICh3aXRo
b3V0IHNwZWN1bGF0aW9uCmJhcnJpZXIpIG9mIHRoZSBsb2NraW5nIHByaW1p
dGl2ZXMsIGJ1dCBhIHNwZWN1bGF0aW9uIGJhcnJpZXIgaXMgYWx3YXlzIGFk
ZGVkCnRvIHRoZSBleHBvc2VkIHB1YmxpYyBsb2NrIHdyYXBwaW5nIGhlbHBl
ci4gIFRoYXQncyB0aGUgY2FzZSB3aXRoCnNjaGVkX3NwaW5fbG9ja19kb3Vi
bGUoKSBvciBwY2lkZXZzX2xvY2soKSBmb3IgZXhhbXBsZS4KClRoaXMgaXMg
cGFydCBvZiBYU0EtNDUzIC8gQ1ZFLTIwMjQtMjE5MwoKU2lnbmVkLW9mZi1i
eTogUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5jb20+ClJl
dmlld2VkLWJ5OiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+Cihj
aGVycnkgcGlja2VkIGZyb20gY29tbWl0IDE5N2VjZDgzOGEyYWFmOTU5YTQ2
OWRmMzY5NmQ0NTU5YzRmOGI3NjIpCgpkaWZmIC0tZ2l0IGEveGVuL2FyY2gv
eDg2L2h2bS92cHQuYyBiL3hlbi9hcmNoL3g4Ni9odm0vdnB0LmMKaW5kZXgg
OGY1M2U4OGQ2NzA2Li5lMWQ2ODQ1YTI4NDQgMTAwNjQ0Ci0tLSBhL3hlbi9h
cmNoL3g4Ni9odm0vdnB0LmMKKysrIGIveGVuL2FyY2gveDg2L2h2bS92cHQu
YwpAQCAtMTUwLDcgKzE1MCw3IEBAIHN0YXRpYyBpbnQgcHRfaXJxX21hc2tl
ZChzdHJ1Y3QgcGVyaW9kaWNfdGltZSAqcHQpCiAgKiBwdC0+dmNwdSBmaWVs
ZCwgYmVjYXVzZSBhbm90aGVyIHRocmVhZCBob2xkaW5nIHRoZSBwdF9taWdy
YXRlIGxvY2sKICAqIG1heSBhbHJlYWR5IGJlIHNwaW5uaW5nIHdhaXRpbmcg
Zm9yIHlvdXIgdmNwdSBsb2NrLgogICovCi1zdGF0aWMgdm9pZCBwdF92Y3B1
X2xvY2soc3RydWN0IHZjcHUgKnYpCitzdGF0aWMgYWx3YXlzX2lubGluZSB2
b2lkIHB0X3ZjcHVfbG9jayhzdHJ1Y3QgdmNwdSAqdikKIHsKICAgICBzcGlu
X2xvY2soJnYtPmFyY2guaHZtLnRtX2xvY2spOwogfQpAQCAtMTY5LDkgKzE2
OSwxMyBAQCBzdGF0aWMgdm9pZCBwdF92Y3B1X3VubG9jayhzdHJ1Y3QgdmNw
dSAqdikKICAqIG5lZWQgdG8gdGFrZSBhbiBhZGRpdGlvbmFsIGxvY2sgdGhh
dCBwcm90ZWN0cyBhZ2FpbnN0IHB0LT52Y3B1CiAgKiBjaGFuZ2luZy4KICAq
Lwotc3RhdGljIHZvaWQgcHRfbG9jayhzdHJ1Y3QgcGVyaW9kaWNfdGltZSAq
cHQpCitzdGF0aWMgYWx3YXlzX2lubGluZSB2b2lkIHB0X2xvY2soc3RydWN0
IHBlcmlvZGljX3RpbWUgKnB0KQogewotICAgIHJlYWRfbG9jaygmcHQtPnZj
cHUtPmRvbWFpbi0+YXJjaC5odm0ucGxfdGltZS0+cHRfbWlncmF0ZSk7Cisg
ICAgLyoKKyAgICAgKiBVc2UgdGhlIHNwZWN1bGF0aW9uIHVuc2FmZSB2YXJp
YW50IGZvciB0aGUgZmlyc3QgbG9jaywgYXMgdGhlIGZvbGxvd2luZworICAg
ICAqIGxvY2sgdGFraW5nIGhlbHBlciBhbHJlYWR5IGluY2x1ZGVzIGEgc3Bl
Y3VsYXRpb24gYmFycmllci4KKyAgICAgKi8KKyAgICBfcmVhZF9sb2NrKCZw
dC0+dmNwdS0+ZG9tYWluLT5hcmNoLmh2bS5wbF90aW1lLT5wdF9taWdyYXRl
KTsKICAgICBzcGluX2xvY2soJnB0LT52Y3B1LT5hcmNoLmh2bS50bV9sb2Nr
KTsKIH0KIApkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNt
L2lycS5oIGIveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2lycS5oCmluZGV4
IGE4N2FmNDdlY2UyMi4uNDY1YWIzOWJiMDQxIDEwMDY0NAotLS0gYS94ZW4v
YXJjaC94ODYvaW5jbHVkZS9hc20vaXJxLmgKKysrIGIveGVuL2FyY2gveDg2
L2luY2x1ZGUvYXNtL2lycS5oCkBAIC0xNzQsNiArMTc0LDcgQEAgdm9pZCBj
Zl9jaGVjayBpcnFfY29tcGxldGVfbW92ZShzdHJ1Y3QgaXJxX2Rlc2MgKmRl
c2MpOwogCiBleHRlcm4gc3RydWN0IGlycV9kZXNjICppcnFfZGVzYzsKIAor
LyogTm90IHNwZWN1bGF0aW9uIHNhZmUsIG9ubHkgdXNlZCBmb3IgQVAgYnJp
bmd1cC4gKi8KIHZvaWQgbG9ja192ZWN0b3JfbG9jayh2b2lkKTsKIHZvaWQg
dW5sb2NrX3ZlY3Rvcl9sb2NrKHZvaWQpOwogCmRpZmYgLS1naXQgYS94ZW4v
YXJjaC94ODYvbW0vbW0tbG9ja3MuaCBiL3hlbi9hcmNoL3g4Ni9tbS9tbS1s
b2Nrcy5oCmluZGV4IDVhM2Y5NmZiYWFkZC4uNWVjMDgwYzAyZmQ4IDEwMDY0
NAotLS0gYS94ZW4vYXJjaC94ODYvbW0vbW0tbG9ja3MuaAorKysgYi94ZW4v
YXJjaC94ODYvbW0vbW0tbG9ja3MuaApAQCAtNzQsOCArNzQsOCBAQCBzdGF0
aWMgaW5saW5lIHZvaWQgX3NldF9sb2NrX2xldmVsKGludCBsKQogICAgIHRo
aXNfY3B1KG1tX2xvY2tfbGV2ZWwpID0gbDsKIH0KIAotc3RhdGljIGlubGlu
ZSB2b2lkIF9tbV9sb2NrKGNvbnN0IHN0cnVjdCBkb21haW4gKmQsIG1tX2xv
Y2tfdCAqbCwKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCBj
aGFyICpmdW5jLCBpbnQgbGV2ZWwsIGludCByZWMpCitzdGF0aWMgYWx3YXlz
X2lubGluZSB2b2lkIF9tbV9sb2NrKGNvbnN0IHN0cnVjdCBkb21haW4gKmQs
IG1tX2xvY2tfdCAqbCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgY29uc3QgY2hhciAqZnVuYywgaW50IGxldmVsLCBpbnQgcmVjKQog
ewogICAgIGlmICggISgobW1fbG9ja2VkX2J5X21lKGwpKSAmJiByZWMpICkK
ICAgICAgICAgX2NoZWNrX2xvY2tfbGV2ZWwoZCwgbGV2ZWwpOwpAQCAtMTI1
LDggKzEyNSw4IEBAIHN0YXRpYyBpbmxpbmUgaW50IG1tX3dyaXRlX2xvY2tl
ZF9ieV9tZShtbV9yd2xvY2tfdCAqbCkKICAgICByZXR1cm4gKGwtPmxvY2tl
ciA9PSBnZXRfcHJvY2Vzc29yX2lkKCkpOwogfQogCi1zdGF0aWMgaW5saW5l
IHZvaWQgX21tX3dyaXRlX2xvY2soY29uc3Qgc3RydWN0IGRvbWFpbiAqZCwg
bW1fcndsb2NrX3QgKmwsCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgY29uc3QgY2hhciAqZnVuYywgaW50IGxldmVsKQorc3RhdGljIGFs
d2F5c19pbmxpbmUgdm9pZCBfbW1fd3JpdGVfbG9jayhjb25zdCBzdHJ1Y3Qg
ZG9tYWluICpkLCBtbV9yd2xvY2tfdCAqbCwKKyAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgY29uc3QgY2hhciAqZnVuYywgaW50
IGxldmVsKQogewogICAgIGlmICggIW1tX3dyaXRlX2xvY2tlZF9ieV9tZShs
KSApCiAgICAgewpAQCAtMTM3LDYgKzEzNyw4IEBAIHN0YXRpYyBpbmxpbmUg
dm9pZCBfbW1fd3JpdGVfbG9jayhjb25zdCBzdHJ1Y3QgZG9tYWluICpkLCBt
bV9yd2xvY2tfdCAqbCwKICAgICAgICAgbC0+dW5sb2NrX2xldmVsID0gX2dl
dF9sb2NrX2xldmVsKCk7CiAgICAgICAgIF9zZXRfbG9ja19sZXZlbChfbG9j
a19sZXZlbChkLCBsZXZlbCkpOwogICAgIH0KKyAgICBlbHNlCisgICAgICAg
IGJsb2NrX3NwZWN1bGF0aW9uKCk7CiAgICAgbC0+cmVjdXJzZV9jb3VudCsr
OwogfQogCkBAIC0xNTAsOCArMTUyLDggQEAgc3RhdGljIGlubGluZSB2b2lk
IG1tX3dyaXRlX3VubG9jayhtbV9yd2xvY2tfdCAqbCkKICAgICBwZXJjcHVf
d3JpdGVfdW5sb2NrKHAybV9wZXJjcHVfcndsb2NrLCAmbC0+bG9jayk7CiB9
CiAKLXN0YXRpYyBpbmxpbmUgdm9pZCBfbW1fcmVhZF9sb2NrKGNvbnN0IHN0
cnVjdCBkb21haW4gKmQsIG1tX3J3bG9ja190ICpsLAotICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgaW50IGxldmVsKQorc3RhdGljIGFsd2F5
c19pbmxpbmUgdm9pZCBfbW1fcmVhZF9sb2NrKGNvbnN0IHN0cnVjdCBkb21h
aW4gKmQsIG1tX3J3bG9ja190ICpsLAorICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIGludCBsZXZlbCkKIHsKICAgICBfY2hlY2tf
bG9ja19sZXZlbChkLCBsZXZlbCk7CiAgICAgcGVyY3B1X3JlYWRfbG9jayhw
Mm1fcGVyY3B1X3J3bG9jaywgJmwtPmxvY2spOwpAQCAtMTY2LDE1ICsxNjgs
MTUgQEAgc3RhdGljIGlubGluZSB2b2lkIG1tX3JlYWRfdW5sb2NrKG1tX3J3
bG9ja190ICpsKQogCiAvKiBUaGlzIHdyYXBwZXIgdXNlcyB0aGUgbGluZSBu
dW1iZXIgdG8gZXhwcmVzcyB0aGUgbG9ja2luZyBvcmRlciBiZWxvdyAqLwog
I2RlZmluZSBkZWNsYXJlX21tX2xvY2sobmFtZSkgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAotICAgIHN0YXRp
YyBpbmxpbmUgdm9pZCBtbV9sb2NrXyMjbmFtZShjb25zdCBzdHJ1Y3QgZG9t
YWluICpkLCBtbV9sb2NrX3QgKmwsICAgXAotICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBjb25zdCBjaGFyICpmdW5jLCBpbnQgcmVj
KSAgICAgICAgICAgICAgXAorICAgIHN0YXRpYyBhbHdheXNfaW5saW5lIHZv
aWQgbW1fbG9ja18jI25hbWUoICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgXAorICAgICAgICBjb25zdCBzdHJ1Y3QgZG9tYWluICpkLCBtbV9s
b2NrX3QgKmwsIGNvbnN0IGNoYXIgKmZ1bmMsIGludCByZWMpICAgICAgXAog
ICAgIHsgX21tX2xvY2soZCwgbCwgZnVuYywgTU1fTE9DS19PUkRFUl8jI25h
bWUsIHJlYyk7IH0KICNkZWZpbmUgZGVjbGFyZV9tbV9yd2xvY2sobmFtZSkg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IFwKLSAgICBzdGF0aWMgaW5saW5lIHZvaWQgbW1fd3JpdGVfbG9ja18jI25h
bWUoY29uc3Qgc3RydWN0IGRvbWFpbiAqZCwgICAgICAgICAgIFwKLSAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbW1fcnds
b2NrX3QgKmwsIGNvbnN0IGNoYXIgKmZ1bmMpIFwKKyAgICBzdGF0aWMgYWx3
YXlzX2lubGluZSB2b2lkIG1tX3dyaXRlX2xvY2tfIyNuYW1lKCAgICAgICAg
ICAgICAgICAgICAgICAgICAgIFwKKyAgICAgICAgY29uc3Qgc3RydWN0IGRv
bWFpbiAqZCwgbW1fcndsb2NrX3QgKmwsIGNvbnN0IGNoYXIgKmZ1bmMpICAg
ICAgICAgICAgIFwKICAgICB7IF9tbV93cml0ZV9sb2NrKGQsIGwsIGZ1bmMs
IE1NX0xPQ0tfT1JERVJfIyNuYW1lKTsgfSAgICAgICAgICAgICAgICAgICAg
IFwKLSAgICBzdGF0aWMgaW5saW5lIHZvaWQgbW1fcmVhZF9sb2NrXyMjbmFt
ZShjb25zdCBzdHJ1Y3QgZG9tYWluICpkLCAgICAgICAgICAgIFwKLSAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtbV9yd2xv
Y2tfdCAqbCkgICAgICAgICAgICAgICAgICAgIFwKKyAgICBzdGF0aWMgYWx3
YXlzX2lubGluZSB2b2lkIG1tX3JlYWRfbG9ja18jI25hbWUoY29uc3Qgc3Ry
dWN0IGRvbWFpbiAqZCwgICAgIFwKKyAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgbW1fcndsb2NrX3QgKmwpICAg
ICAgICAgICAgIFwKICAgICB7IF9tbV9yZWFkX2xvY2soZCwgbCwgTU1fTE9D
S19PUkRFUl8jI25hbWUpOyB9CiAvKiBUaGVzZSBjYXB0dXJlIHRoZSBuYW1l
IG9mIHRoZSBjYWxsaW5nIGZ1bmN0aW9uICovCiAjZGVmaW5lIG1tX2xvY2so
bmFtZSwgZCwgbCkgbW1fbG9ja18jI25hbWUoZCwgbCwgX19mdW5jX18sIDAp
CkBAIC0zMDksNyArMzExLDcgQEAgZGVjbGFyZV9tbV9sb2NrKGFsdHAybWxp
c3QpCiAjZGVmaW5lIE1NX0xPQ0tfT1JERVJfYWx0cDJtICAgICAgICAgICAg
ICAgICA0MAogZGVjbGFyZV9tbV9yd2xvY2soYWx0cDJtKTsKIAotc3RhdGlj
IGlubGluZSB2b2lkIHAybV9sb2NrKHN0cnVjdCBwMm1fZG9tYWluICpwKQor
c3RhdGljIGFsd2F5c19pbmxpbmUgdm9pZCBwMm1fbG9jayhzdHJ1Y3QgcDJt
X2RvbWFpbiAqcCkKIHsKICAgICBpZiAoIHAybV9pc19hbHRwMm0ocCkgKQog
ICAgICAgICBtbV93cml0ZV9sb2NrKGFsdHAybSwgcC0+ZG9tYWluLCAmcC0+
bG9jayk7CmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYvbW0vcDJtLXBvZC5j
IGIveGVuL2FyY2gveDg2L21tL3AybS1wb2QuYwppbmRleCA5OTY5ZWI0NWZh
OGMuLjliZTY3YjYzY2UzZSAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L21t
L3AybS1wb2QuYworKysgYi94ZW4vYXJjaC94ODYvbW0vcDJtLXBvZC5jCkBA
IC0yNCw3ICsyNCw3IEBACiAjZGVmaW5lIHN1cGVycGFnZV9hbGlnbmVkKF94
KSAgKCgoX3gpJihTVVBFUlBBR0VfUEFHRVMtMSkpPT0wKQogCiAvKiBFbmZv
cmNlIGxvY2sgb3JkZXJpbmcgd2hlbiBncmFiYmluZyB0aGUgImV4dGVybmFs
IiBwYWdlX2FsbG9jIGxvY2sgKi8KLXN0YXRpYyBpbmxpbmUgdm9pZCBsb2Nr
X3BhZ2VfYWxsb2Moc3RydWN0IHAybV9kb21haW4gKnAybSkKK3N0YXRpYyBh
bHdheXNfaW5saW5lIHZvaWQgbG9ja19wYWdlX2FsbG9jKHN0cnVjdCBwMm1f
ZG9tYWluICpwMm0pCiB7CiAgICAgcGFnZV9hbGxvY19tbV9wcmVfbG9jayhw
Mm0tPmRvbWFpbik7CiAgICAgc3Bpbl9sb2NrKCYocDJtLT5kb21haW4tPnBh
Z2VfYWxsb2NfbG9jaykpOwpkaWZmIC0tZ2l0IGEveGVuL2NvbW1vbi9ldmVu
dF9jaGFubmVsLmMgYi94ZW4vY29tbW9uL2V2ZW50X2NoYW5uZWwuYwppbmRl
eCBhN2EwMDRhMDg0MjkuLjY2ZjkyNGE3YjA5MSAxMDA2NDQKLS0tIGEveGVu
L2NvbW1vbi9ldmVudF9jaGFubmVsLmMKKysrIGIveGVuL2NvbW1vbi9ldmVu
dF9jaGFubmVsLmMKQEAgLTQ1LDcgKzQ1LDcgQEAKICAqIGp1c3QgYXNzdW1l
IHRoZSBldmVudCBjaGFubmVsIGlzIGZyZWUgb3IgdW5ib3VuZCBhdCB0aGUg
bW9tZW50IHdoZW4gdGhlCiAgKiBldnRjaG5fcmVhZF90cnlsb2NrKCkgcmV0
dXJucyBmYWxzZS4KICAqLwotc3RhdGljIGlubGluZSB2b2lkIGV2dGNobl93
cml0ZV9sb2NrKHN0cnVjdCBldnRjaG4gKmV2dGNobikKK3N0YXRpYyBhbHdh
eXNfaW5saW5lIHZvaWQgZXZ0Y2huX3dyaXRlX2xvY2soc3RydWN0IGV2dGNo
biAqZXZ0Y2huKQogewogICAgIHdyaXRlX2xvY2soJmV2dGNobi0+bG9jayk7
CiAKQEAgLTM1MSw3ICszNTEsOCBAQCBpbnQgZXZ0Y2huX2FsbG9jX3VuYm91
bmQoZXZ0Y2huX2FsbG9jX3VuYm91bmRfdCAqYWxsb2MsIGV2dGNobl9wb3J0
X3QgcG9ydCkKICAgICByZXR1cm4gcmM7CiB9CiAKLXN0YXRpYyB2b2lkIGRv
dWJsZV9ldnRjaG5fbG9jayhzdHJ1Y3QgZXZ0Y2huICpsY2huLCBzdHJ1Y3Qg
ZXZ0Y2huICpyY2huKQorc3RhdGljIGFsd2F5c19pbmxpbmUgdm9pZCBkb3Vi
bGVfZXZ0Y2huX2xvY2soc3RydWN0IGV2dGNobiAqbGNobiwKKyAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0cnVjdCBl
dnRjaG4gKnJjaG4pCiB7CiAgICAgQVNTRVJUKGxjaG4gIT0gcmNobik7CiAK
ZGlmZiAtLWdpdCBhL3hlbi9jb21tb24vZ3JhbnRfdGFibGUuYyBiL3hlbi9j
b21tb24vZ3JhbnRfdGFibGUuYwppbmRleCA4OWI3ODExYzUxYzMuLjkzNDky
NGNiZGE2NiAxMDA2NDQKLS0tIGEveGVuL2NvbW1vbi9ncmFudF90YWJsZS5j
CisrKyBiL3hlbi9jb21tb24vZ3JhbnRfdGFibGUuYwpAQCAtNDAzLDcgKzQw
Myw3IEBAIHN0YXRpYyBpbmxpbmUgdm9pZCBhY3Rfc2V0X2dmbihzdHJ1Y3Qg
YWN0aXZlX2dyYW50X2VudHJ5ICphY3QsIGdmbl90IGdmbikKIAogc3RhdGlj
IERFRklORV9QRVJDUFVfUldMT0NLX0dMT0JBTChncmFudF9yd2xvY2spOwog
Ci1zdGF0aWMgaW5saW5lIHZvaWQgZ3JhbnRfcmVhZF9sb2NrKHN0cnVjdCBn
cmFudF90YWJsZSAqZ3QpCitzdGF0aWMgYWx3YXlzX2lubGluZSB2b2lkIGdy
YW50X3JlYWRfbG9jayhzdHJ1Y3QgZ3JhbnRfdGFibGUgKmd0KQogewogICAg
IHBlcmNwdV9yZWFkX2xvY2soZ3JhbnRfcndsb2NrLCAmZ3QtPmxvY2spOwog
fQpAQCAtNDEzLDcgKzQxMyw3IEBAIHN0YXRpYyBpbmxpbmUgdm9pZCBncmFu
dF9yZWFkX3VubG9jayhzdHJ1Y3QgZ3JhbnRfdGFibGUgKmd0KQogICAgIHBl
cmNwdV9yZWFkX3VubG9jayhncmFudF9yd2xvY2ssICZndC0+bG9jayk7CiB9
CiAKLXN0YXRpYyBpbmxpbmUgdm9pZCBncmFudF93cml0ZV9sb2NrKHN0cnVj
dCBncmFudF90YWJsZSAqZ3QpCitzdGF0aWMgYWx3YXlzX2lubGluZSB2b2lk
IGdyYW50X3dyaXRlX2xvY2soc3RydWN0IGdyYW50X3RhYmxlICpndCkKIHsK
ICAgICBwZXJjcHVfd3JpdGVfbG9jayhncmFudF9yd2xvY2ssICZndC0+bG9j
ayk7CiB9CkBAIC00NTAsNyArNDUwLDcgQEAgbnJfYWN0aXZlX2dyYW50X2Zy
YW1lcyhzdHJ1Y3QgZ3JhbnRfdGFibGUgKmd0KQogICAgIHJldHVybiBudW1f
YWN0X2ZyYW1lc19mcm9tX3NoYV9mcmFtZXMobnJfZ3JhbnRfZnJhbWVzKGd0
KSk7CiB9CiAKLXN0YXRpYyBpbmxpbmUgc3RydWN0IGFjdGl2ZV9ncmFudF9l
bnRyeSAqCitzdGF0aWMgYWx3YXlzX2lubGluZSBzdHJ1Y3QgYWN0aXZlX2dy
YW50X2VudHJ5ICoKIGFjdGl2ZV9lbnRyeV9hY3F1aXJlKHN0cnVjdCBncmFu
dF90YWJsZSAqdCwgZ3JhbnRfcmVmX3QgZSkKIHsKICAgICBzdHJ1Y3QgYWN0
aXZlX2dyYW50X2VudHJ5ICphY3Q7CmRpZmYgLS1naXQgYS94ZW4vY29tbW9u
L3NjaGVkL2NvcmUuYyBiL3hlbi9jb21tb24vc2NoZWQvY29yZS5jCmluZGV4
IDkwMTc4MmJiYjQxNi4uMzRhZDM5YjlhZDBiIDEwMDY0NAotLS0gYS94ZW4v
Y29tbW9uL3NjaGVkL2NvcmUuYworKysgYi94ZW4vY29tbW9uL3NjaGVkL2Nv
cmUuYwpAQCAtMzQ4LDIzICszNDgsMjggQEAgdWludDY0X3QgZ2V0X2NwdV9p
ZGxlX3RpbWUodW5zaWduZWQgaW50IGNwdSkKICAqIFRoaXMgYXZvaWRzIGRl
YWQtIG9yIGxpdmUtbG9ja3Mgd2hlbiB0aGlzIGNvZGUgaXMgcnVubmluZyBv
biBib3RoCiAgKiBjcHVzIGF0IHRoZSBzYW1lIHRpbWUuCiAgKi8KLXN0YXRp
YyB2b2lkIHNjaGVkX3NwaW5fbG9ja19kb3VibGUoc3BpbmxvY2tfdCAqbG9j
azEsIHNwaW5sb2NrX3QgKmxvY2syLAotICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICB1bnNpZ25lZCBsb25nICpmbGFncykKK3N0YXRpYyBh
bHdheXNfaW5saW5lIHZvaWQgc2NoZWRfc3Bpbl9sb2NrX2RvdWJsZSgKKyAg
ICBzcGlubG9ja190ICpsb2NrMSwgc3BpbmxvY2tfdCAqbG9jazIsIHVuc2ln
bmVkIGxvbmcgKmZsYWdzKQogeworICAgIC8qCisgICAgICogSW4gb3JkZXIg
dG8gYXZvaWQgZXh0cmEgb3ZlcmhlYWQsIHVzZSB0aGUgbG9ja2luZyBwcmlt
aXRpdmVzIHdpdGhvdXQgdGhlCisgICAgICogc3BlY3VsYXRpb24gYmFycmll
ciwgYW5kIGludHJvZHVjZSBhIHNpbmdsZSBiYXJyaWVyIGhlcmUuCisgICAg
ICovCiAgICAgaWYgKCBsb2NrMSA9PSBsb2NrMiApCiAgICAgewotICAgICAg
ICBzcGluX2xvY2tfaXJxc2F2ZShsb2NrMSwgKmZsYWdzKTsKKyAgICAgICAg
KmZsYWdzID0gX3NwaW5fbG9ja19pcnFzYXZlKGxvY2sxKTsKICAgICB9CiAg
ICAgZWxzZSBpZiAoIGxvY2sxIDwgbG9jazIgKQogICAgIHsKLSAgICAgICAg
c3Bpbl9sb2NrX2lycXNhdmUobG9jazEsICpmbGFncyk7Ci0gICAgICAgIHNw
aW5fbG9jayhsb2NrMik7CisgICAgICAgICpmbGFncyA9IF9zcGluX2xvY2tf
aXJxc2F2ZShsb2NrMSk7CisgICAgICAgIF9zcGluX2xvY2sobG9jazIpOwog
ICAgIH0KICAgICBlbHNlCiAgICAgewotICAgICAgICBzcGluX2xvY2tfaXJx
c2F2ZShsb2NrMiwgKmZsYWdzKTsKLSAgICAgICAgc3Bpbl9sb2NrKGxvY2sx
KTsKKyAgICAgICAgKmZsYWdzID0gX3NwaW5fbG9ja19pcnFzYXZlKGxvY2sy
KTsKKyAgICAgICAgX3NwaW5fbG9jayhsb2NrMSk7CiAgICAgfQorICAgIGJs
b2NrX2xvY2tfc3BlY3VsYXRpb24oKTsKIH0KIAogc3RhdGljIHZvaWQgc2No
ZWRfc3Bpbl91bmxvY2tfZG91YmxlKHNwaW5sb2NrX3QgKmxvY2sxLCBzcGlu
bG9ja190ICpsb2NrMiwKZGlmZiAtLWdpdCBhL3hlbi9jb21tb24vc2NoZWQv
cHJpdmF0ZS5oIGIveGVuL2NvbW1vbi9zY2hlZC9wcml2YXRlLmgKaW5kZXgg
YzUxNjk3NmMzNzQwLi4zYjk3ZjE1NzY3ODIgMTAwNjQ0Ci0tLSBhL3hlbi9j
b21tb24vc2NoZWQvcHJpdmF0ZS5oCisrKyBiL3hlbi9jb21tb24vc2NoZWQv
cHJpdmF0ZS5oCkBAIC0yMDcsOCArMjA3LDI0IEBAIERFQ0xBUkVfUEVSX0NQ
VShjcHVtYXNrX3QsIGNwdW1hc2tfc2NyYXRjaCk7CiAjZGVmaW5lIGNwdW1h
c2tfc2NyYXRjaCAgICAgICAgKCZ0aGlzX2NwdShjcHVtYXNrX3NjcmF0Y2gp
KQogI2RlZmluZSBjcHVtYXNrX3NjcmF0Y2hfY3B1KGMpICgmcGVyX2NwdShj
cHVtYXNrX3NjcmF0Y2gsIGMpKQogCisvKgorICogRGVhbCB3aXRoIF9zcGlu
X2xvY2tfaXJxc2F2ZSgpIHJldHVybmluZyB0aGUgZmxhZ3MgdmFsdWUgaW5z
dGVhZCBvZiBzdG9yaW5nCisgKiBpdCBpbiBhIHBhc3NlZCBwYXJhbWV0ZXIu
CisgKi8KKyNkZWZpbmUgX3NjaGVkX3NwaW5sb2NrMChsb2NrLCBpcnEpIF9z
cGluX2xvY2sjI2lycShsb2NrKQorI2RlZmluZSBfc2NoZWRfc3BpbmxvY2sx
KGxvY2ssIGlycSwgYXJnKSAoeyBcCisgICAgQlVJTERfQlVHX09OKHNpemVv
ZihhcmcpICE9IHNpemVvZih1bnNpZ25lZCBsb25nKSk7IFwKKyAgICAoYXJn
KSA9IF9zcGluX2xvY2sjI2lycShsb2NrKTsgXAorfSkKKworI2RlZmluZSBf
c2NoZWRfc3BpbmxvY2tfXyhucikgX3NjaGVkX3NwaW5sb2NrICMjIG5yCisj
ZGVmaW5lIF9zY2hlZF9zcGlubG9ja18obnIpICBfc2NoZWRfc3BpbmxvY2tf
XyhucikKKyNkZWZpbmUgX3NjaGVkX3NwaW5sb2NrKGxvY2ssIGlycSwgYXJn
cy4uLikgXAorICAgIF9zY2hlZF9zcGlubG9ja18oY291bnRfYXJncyhhcmdz
KSkobG9jaywgaXJxLCAjIyBhcmdzKQorCiAjZGVmaW5lIHNjaGVkX2xvY2so
a2luZCwgcGFyYW0sIGNwdSwgaXJxLCBhcmcuLi4pIFwKLXN0YXRpYyBpbmxp
bmUgc3BpbmxvY2tfdCAqa2luZCMjX3NjaGVkdWxlX2xvY2sjI2lycShwYXJh
bSBFWFRSQV9UWVBFKGFyZykpIFwKK3N0YXRpYyBhbHdheXNfaW5saW5lIHNw
aW5sb2NrX3QgXAorKmtpbmQjI19zY2hlZHVsZV9sb2NrIyNpcnEocGFyYW0g
RVhUUkFfVFlQRShhcmcpKSBcCiB7IFwKICAgICBmb3IgKCA7IDsgKSBcCiAg
ICAgeyBcCkBAIC0yMjAsMTAgKzIzNiwxNiBAQCBzdGF0aWMgaW5saW5lIHNw
aW5sb2NrX3QgKmtpbmQjI19zY2hlZHVsZV9sb2NrIyNpcnEocGFyYW0gRVhU
UkFfVFlQRShhcmcpKSBcCiAgICAgICAgICAqIFwKICAgICAgICAgICogSXQg
bWF5IGFsc28gYmUgdGhlIGNhc2UgdGhhdCB2LT5wcm9jZXNzb3IgbWF5IGNo
YW5nZSBidXQgdGhlIFwKICAgICAgICAgICogbG9jayBtYXkgYmUgdGhlIHNh
bWU7IHRoaXMgd2lsbCBzdWNjZWVkIGluIHRoYXQgY2FzZS4gXAorICAgICAg
ICAgKiBcCisgICAgICAgICAqIFVzZSB0aGUgc3BlY3VsYXRpb24gdW5zYWZl
IGxvY2tpbmcgaGVscGVyLCB0aGVyZSdzIGEgc3BlY3VsYXRpb24gXAorICAg
ICAgICAgKiBiYXJyaWVyIGJlZm9yZSByZXR1cm5pbmcgdG8gdGhlIGNhbGxl
ci4gXAogICAgICAgICAgKi8gXAotICAgICAgICBzcGluX2xvY2sjI2lycShs
b2NrLCAjIyBhcmcpOyBcCisgICAgICAgIF9zY2hlZF9zcGlubG9jayhsb2Nr
LCBpcnEsICMjIGFyZyk7IFwKICAgICAgICAgaWYgKCBsaWtlbHkobG9jayA9
PSBnZXRfc2NoZWRfcmVzKGNwdSktPnNjaGVkdWxlX2xvY2spICkgXAorICAg
ICAgICB7IFwKKyAgICAgICAgICAgIGJsb2NrX2xvY2tfc3BlY3VsYXRpb24o
KTsgXAogICAgICAgICAgICAgcmV0dXJuIGxvY2s7IFwKKyAgICAgICAgfSBc
CiAgICAgICAgIHNwaW5fdW5sb2NrIyNpcnEobG9jaywgIyMgYXJnKTsgXAog
ICAgIH0gXAogfQpkaWZmIC0tZ2l0IGEveGVuL2NvbW1vbi90aW1lci5jIGIv
eGVuL2NvbW1vbi90aW1lci5jCmluZGV4IDBmZGRmYTc0ODc5ZS4uMzhlYjVm
ZDIwZDM2IDEwMDY0NAotLS0gYS94ZW4vY29tbW9uL3RpbWVyLmMKKysrIGIv
eGVuL2NvbW1vbi90aW1lci5jCkBAIC0yMzksNyArMjM5LDcgQEAgc3RhdGlj
IGlubGluZSB2b2lkIGRlYWN0aXZhdGVfdGltZXIoc3RydWN0IHRpbWVyICp0
aW1lcikKICAgICBsaXN0X2FkZCgmdGltZXItPmluYWN0aXZlLCAmcGVyX2Nw
dSh0aW1lcnMsIHRpbWVyLT5jcHUpLmluYWN0aXZlKTsKIH0KIAotc3RhdGlj
IGlubGluZSBib29sX3QgdGltZXJfbG9jayhzdHJ1Y3QgdGltZXIgKnRpbWVy
KQorc3RhdGljIGlubGluZSBib29sX3QgdGltZXJfbG9ja191bnNhZmUoc3Ry
dWN0IHRpbWVyICp0aW1lcikKIHsKICAgICB1bnNpZ25lZCBpbnQgY3B1Owog
CkBAIC0yNTMsNyArMjUzLDggQEAgc3RhdGljIGlubGluZSBib29sX3QgdGlt
ZXJfbG9jayhzdHJ1Y3QgdGltZXIgKnRpbWVyKQogICAgICAgICAgICAgcmN1
X3JlYWRfdW5sb2NrKCZ0aW1lcl9jcHVfcmVhZF9sb2NrKTsKICAgICAgICAg
ICAgIHJldHVybiAwOwogICAgICAgICB9Ci0gICAgICAgIHNwaW5fbG9jaygm
cGVyX2NwdSh0aW1lcnMsIGNwdSkubG9jayk7CisgICAgICAgIC8qIFVzZSB0
aGUgc3BlY3VsYXRpb24gdW5zYWZlIHZhcmlhbnQsIHRoZSB3cmFwcGVyIGhh
cyB0aGUgYmFycmllci4gKi8KKyAgICAgICAgX3NwaW5fbG9jaygmcGVyX2Nw
dSh0aW1lcnMsIGNwdSkubG9jayk7CiAgICAgICAgIGlmICggbGlrZWx5KHRp
bWVyLT5jcHUgPT0gY3B1KSApCiAgICAgICAgICAgICBicmVhazsKICAgICAg
ICAgc3Bpbl91bmxvY2soJnBlcl9jcHUodGltZXJzLCBjcHUpLmxvY2spOwpA
QCAtMjY2LDggKzI2Nyw5IEBAIHN0YXRpYyBpbmxpbmUgYm9vbF90IHRpbWVy
X2xvY2soc3RydWN0IHRpbWVyICp0aW1lcikKICNkZWZpbmUgdGltZXJfbG9j
a19pcnFzYXZlKHQsIGZsYWdzKSAoeyAgICAgICAgIFwKICAgICBib29sX3Qg
X194OyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKICAgICBs
b2NhbF9pcnFfc2F2ZShmbGFncyk7ICAgICAgICAgICAgICAgICAgICAgIFwK
LSAgICBpZiAoICEoX194ID0gdGltZXJfbG9jayh0KSkgKSAgICAgICAgICAg
ICAgIFwKKyAgICBpZiAoICEoX194ID0gdGltZXJfbG9ja191bnNhZmUodCkp
ICkgICAgICAgIFwKICAgICAgICAgbG9jYWxfaXJxX3Jlc3RvcmUoZmxhZ3Mp
OyAgICAgICAgICAgICAgIFwKKyAgICBibG9ja19sb2NrX3NwZWN1bGF0aW9u
KCk7ICAgICAgICAgICAgICAgICAgIFwKICAgICBfX3g7ICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKIH0pCiAKZGlmZiAtLWdp
dCBhL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL3BjaS5jIGIveGVuL2RyaXZl
cnMvcGFzc3Rocm91Z2gvcGNpLmMKaW5kZXggZTk5ODM3YjZlMTQxLi4yYTFl
N2VlODlhNWQgMTAwNjQ0Ci0tLSBhL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdo
L3BjaS5jCisrKyBiL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL3BjaS5jCkBA
IC01Miw5ICs1MiwxMCBAQCBzdHJ1Y3QgcGNpX3NlZyB7CiAKIHN0YXRpYyBz
cGlubG9ja190IF9wY2lkZXZzX2xvY2sgPSBTUElOX0xPQ0tfVU5MT0NLRUQ7
CiAKLXZvaWQgcGNpZGV2c19sb2NrKHZvaWQpCisvKiBEbyBub3QgdXNlLCBh
cyBpdCBoYXMgbm8gc3BlY3VsYXRpb24gYmFycmllciwgdXNlIHBjaWRldnNf
bG9jaygpIGluc3RlYWQuICovCit2b2lkIHBjaWRldnNfbG9ja191bnNhZmUo
dm9pZCkKIHsKLSAgICBzcGluX2xvY2tfcmVjdXJzaXZlKCZfcGNpZGV2c19s
b2NrKTsKKyAgICBfc3Bpbl9sb2NrX3JlY3Vyc2l2ZSgmX3BjaWRldnNfbG9j
ayk7CiB9CiAKIHZvaWQgcGNpZGV2c191bmxvY2sodm9pZCkKZGlmZiAtLWdp
dCBhL3hlbi9pbmNsdWRlL3hlbi9ldmVudC5oIGIveGVuL2luY2x1ZGUveGVu
L2V2ZW50LmgKaW5kZXggOGU1MDllMDc4NDc1Li5mMTQ3MmVhMWViZTUgMTAw
NjQ0Ci0tLSBhL3hlbi9pbmNsdWRlL3hlbi9ldmVudC5oCisrKyBiL3hlbi9p
bmNsdWRlL3hlbi9ldmVudC5oCkBAIC0xMTQsMTIgKzExNCwxMiBAQCB2b2lk
IG5vdGlmeV92aWFfeGVuX2V2ZW50X2NoYW5uZWwoc3RydWN0IGRvbWFpbiAq
bGQsIGludCBscG9ydCk7CiAjZGVmaW5lIGJ1Y2tldF9mcm9tX3BvcnQoZCwg
cCkgXAogICAgICgoZ3JvdXBfZnJvbV9wb3J0KGQsIHApKVsoKHApICUgRVZU
Q0hOU19QRVJfR1JPVVApIC8gRVZUQ0hOU19QRVJfQlVDS0VUXSkKIAotc3Rh
dGljIGlubGluZSB2b2lkIGV2dGNobl9yZWFkX2xvY2soc3RydWN0IGV2dGNo
biAqZXZ0Y2huKQorc3RhdGljIGFsd2F5c19pbmxpbmUgdm9pZCBldnRjaG5f
cmVhZF9sb2NrKHN0cnVjdCBldnRjaG4gKmV2dGNobikKIHsKICAgICByZWFk
X2xvY2soJmV2dGNobi0+bG9jayk7CiB9CiAKLXN0YXRpYyBpbmxpbmUgYm9v
bCBldnRjaG5fcmVhZF90cnlsb2NrKHN0cnVjdCBldnRjaG4gKmV2dGNobikK
K3N0YXRpYyBhbHdheXNfaW5saW5lIGJvb2wgZXZ0Y2huX3JlYWRfdHJ5bG9j
ayhzdHJ1Y3QgZXZ0Y2huICpldnRjaG4pCiB7CiAgICAgcmV0dXJuIHJlYWRf
dHJ5bG9jaygmZXZ0Y2huLT5sb2NrKTsKIH0KZGlmZiAtLWdpdCBhL3hlbi9p
bmNsdWRlL3hlbi9wY2kuaCBiL3hlbi9pbmNsdWRlL3hlbi9wY2kuaAppbmRl
eCAyNTFiODc2MWE4ZTkuLmE3MWJlZDM2YmUyOSAxMDA2NDQKLS0tIGEveGVu
L2luY2x1ZGUveGVuL3BjaS5oCisrKyBiL3hlbi9pbmNsdWRlL3hlbi9wY2ku
aApAQCAtMTU1LDggKzE1NSwxMiBAQCBzdHJ1Y3QgcGNpX2RldiB7CiAgKiBk
ZXZpY2VzLCBpdCBhbHNvIHN5bmMgdGhlIGFjY2VzcyB0byB0aGUgbXNpIGNh
cGFiaWxpdHkgdGhhdCBpcyBub3QKICAqIGludGVycnVwdCBoYW5kbGluZyBy
ZWxhdGVkICh0aGUgbWFzayBiaXQgcmVnaXN0ZXIpLgogICovCi0KLXZvaWQg
cGNpZGV2c19sb2NrKHZvaWQpOwordm9pZCBwY2lkZXZzX2xvY2tfdW5zYWZl
KHZvaWQpOworc3RhdGljIGFsd2F5c19pbmxpbmUgdm9pZCBwY2lkZXZzX2xv
Y2sodm9pZCkKK3sKKyAgICBwY2lkZXZzX2xvY2tfdW5zYWZlKCk7CisgICAg
YmxvY2tfbG9ja19zcGVjdWxhdGlvbigpOworfQogdm9pZCBwY2lkZXZzX3Vu
bG9jayh2b2lkKTsKIGJvb2wgX19tdXN0X2NoZWNrIHBjaWRldnNfbG9ja2Vk
KHZvaWQpOwogCg==

--=separator
Content-Type: application/octet-stream; name="xsa453/xsa453-4.18-6.patch"
Content-Disposition: attachment; filename="xsa453/xsa453-4.18-6.patch"
Content-Transfer-Encoding: base64

RnJvbTogPT9VVEYtOD9xP1JvZ2VyPTIwUGF1PTIwTW9ubj1DMz1BOT89IDxy
b2dlci5wYXVAY2l0cml4LmNvbT4KU3ViamVjdDogeDg2L21tOiBhZGQgc3Bl
Y3VsYXRpb24gYmFycmllcnMgdG8gb3BlbiBjb2RlZCBsb2NrcwoKQWRkIGEg
c3BlY3VsYXRpb24gYmFycmllciB0byB0aGUgY2xlYXJseSBpZGVudGlmaWVk
IG9wZW4tY29kZWQgbG9jayB0YWtpbmcKZnVuY3Rpb25zLgoKTm90ZSB0aGF0
IHRoZSBtZW1vcnkgc2hhcmluZyBwYWdlX2xvY2soKSByZXBsYWNlbWVudCAo
X3BhZ2VfbG9jaygpKSBpcyBsZWZ0CmFzLWlzLCBhcyB0aGUgY29kZSBpcyBl
eHBlcmltZW50YWwgYW5kIG5vdCBzZWN1cml0eSBzdXBwb3J0ZWQuCgpUaGlz
IGlzIHBhcnQgb2YgWFNBLTQ1MyAvIENWRS0yMDI0LTIxOTMKClNpZ25lZC1v
ZmYtYnk6IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXguY29t
PgpSZXZpZXdlZC1ieTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29t
PgooY2hlcnJ5IHBpY2tlZCBmcm9tIGNvbW1pdCA0MmE1NzJhMzhlMjJhOTdk
ODZhNGI2NDhhMjI1OTc2MjhkNWI0MmU0KQoKZGlmZiAtLWdpdCBhL3hlbi9h
cmNoL3g4Ni9pbmNsdWRlL2FzbS9tbS5oIGIveGVuL2FyY2gveDg2L2luY2x1
ZGUvYXNtL21tLmgKaW5kZXggMDVkZmUzNTUwMmM4Li5kMWIxZmVlOTliN2Qg
MTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9tbS5oCisr
KyBiL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9tbS5oCkBAIC0zOTksNyAr
Mzk5LDkgQEAgY29uc3Qgc3RydWN0IHBsYXRmb3JtX2JhZF9wYWdlICpnZXRf
cGxhdGZvcm1fYmFkcGFnZXModW5zaWduZWQgaW50ICphcnJheV9zaXplKTsK
ICAqIFRoZSB1c2Ugb2YgUEdUX2xvY2tlZCBpbiBtZW1fc2hhcmluZyBkb2Vz
IG5vdCBjb2xsaWRlLCBzaW5jZSBtZW1fc2hhcmluZyBpcwogICogb25seSBz
dXBwb3J0ZWQgZm9yIGh2bSBndWVzdHMsIHdoaWNoIGRvIG5vdCBoYXZlIFBW
IFBURXMgdXBkYXRlZC4KICAqLwotaW50IHBhZ2VfbG9jayhzdHJ1Y3QgcGFn
ZV9pbmZvICpwYWdlKTsKK2ludCBwYWdlX2xvY2tfdW5zYWZlKHN0cnVjdCBw
YWdlX2luZm8gKnBhZ2UpOworI2RlZmluZSBwYWdlX2xvY2socGcpICAgbG9j
a19ldmFsdWF0ZV9ub3NwZWMocGFnZV9sb2NrX3Vuc2FmZShwZykpCisKIHZv
aWQgcGFnZV91bmxvY2soc3RydWN0IHBhZ2VfaW5mbyAqcGFnZSk7CiAKIHZv
aWQgcHV0X3BhZ2VfdHlwZShzdHJ1Y3QgcGFnZV9pbmZvICpwYWdlKTsKZGlm
ZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9tbS5jIGIveGVuL2FyY2gveDg2L21t
LmMKaW5kZXggYWIwYWNiZmVhNmU1Li4wMDBmZDBmYjU1OGIgMTAwNjQ0Ci0t
LSBhL3hlbi9hcmNoL3g4Ni9tbS5jCisrKyBiL3hlbi9hcmNoL3g4Ni9tbS5j
CkBAIC0yMDE3LDcgKzIwMTcsNyBAQCBzdGF0aWMgaW5saW5lIGJvb2wgY3Vy
cmVudF9sb2NrZWRfcGFnZV9uZV9jaGVjayhzdHJ1Y3QgcGFnZV9pbmZvICpw
YWdlKSB7CiAjZGVmaW5lIGN1cnJlbnRfbG9ja2VkX3BhZ2VfbmVfY2hlY2so
eCkgdHJ1ZQogI2VuZGlmCiAKLWludCBwYWdlX2xvY2soc3RydWN0IHBhZ2Vf
aW5mbyAqcGFnZSkKK2ludCBwYWdlX2xvY2tfdW5zYWZlKHN0cnVjdCBwYWdl
X2luZm8gKnBhZ2UpCiB7CiAgICAgdW5zaWduZWQgbG9uZyB4LCBueDsKIApA
QCAtMjA3OCw3ICsyMDc4LDcgQEAgdm9pZCBwYWdlX3VubG9jayhzdHJ1Y3Qg
cGFnZV9pbmZvICpwYWdlKQogICogbDN0X2xvY2soKSwgc28gdG8gYXZvaWQg
ZGVhZGxvY2sgd2UgbXVzdCBhdm9pZCBncmFiYmluZyB0aGVtIGluCiAgKiBy
ZXZlcnNlIG9yZGVyLgogICovCi1zdGF0aWMgdm9pZCBsM3RfbG9jayhzdHJ1
Y3QgcGFnZV9pbmZvICpwYWdlKQorc3RhdGljIGFsd2F5c19pbmxpbmUgdm9p
ZCBsM3RfbG9jayhzdHJ1Y3QgcGFnZV9pbmZvICpwYWdlKQogewogICAgIHVu
c2lnbmVkIGxvbmcgeCwgbng7CiAKQEAgLTIwODcsNiArMjA4Nyw4IEBAIHN0
YXRpYyB2b2lkIGwzdF9sb2NrKHN0cnVjdCBwYWdlX2luZm8gKnBhZ2UpCiAg
ICAgICAgICAgICBjcHVfcmVsYXgoKTsKICAgICAgICAgbnggPSB4IHwgUEdU
X2xvY2tlZDsKICAgICB9IHdoaWxlICggY21weGNoZygmcGFnZS0+dS5pbnVz
ZS50eXBlX2luZm8sIHgsIG54KSAhPSB4ICk7CisKKyAgICBibG9ja19sb2Nr
X3NwZWN1bGF0aW9uKCk7CiB9CiAKIHN0YXRpYyB2b2lkIGwzdF91bmxvY2so
c3RydWN0IHBhZ2VfaW5mbyAqcGFnZSkK

--=separator
Content-Type: application/octet-stream; name="xsa453/xsa453-4.18-7.patch"
Content-Disposition: attachment; filename="xsa453/xsa453-4.18-7.patch"
Content-Transfer-Encoding: base64

RnJvbTogPT9VVEYtOD9xP1JvZ2VyPTIwUGF1PTIwTW9ubj1DMz1BOT89IDxy
b2dlci5wYXVAY2l0cml4LmNvbT4KU3ViamVjdDogeDg2OiBwcm90ZWN0IGNv
bmRpdGlvbmFsIGxvY2sgdGFraW5nIGZyb20gc3BlY3VsYXRpdmUgZXhlY3V0
aW9uCgpDb25kaXRpb25hbGx5IHRha2VuIGxvY2tzIHRoYXQgdXNlIHRoZSBw
YXR0ZXJuOgoKaWYgKCBsb2NrICkKICAgIHNwaW5fbG9jayguLi4pOwoKTmVl
ZCBhbiBlbHNlIGJyYW5jaCBpbiBvcmRlciB0byBpc3N1ZSBhbiBzcGVjdWxh
dGlvbiBiYXJyaWVyIGluIHRoZSBlbHNlIGNhc2UsCmp1c3QgbGlrZSBpdCdz
IGRvbmUgaW4gY2FzZSB0aGUgbG9jayBuZWVkcyB0byBiZSBhY3F1aXJlZC4K
CmV2YWxfbm9zcGVjKCkgY291bGQgYmUgdXNlZCBvbiB0aGUgY29uZGl0aW9u
IGl0c2VsZiwgYnV0IHRoYXQgd291bGQgcmVzdWx0IGluIGEKZG91YmxlIGJh
cnJpZXIgb24gdGhlIGJyYW5jaCB3aGVyZSB0aGUgbG9jayBpcyB0YWtlbi4K
CkludHJvZHVjZSBhIG5ldyBwYWlyIG9mIGhlbHBlcnMsIHtnZm4sc3Bpbn1f
bG9ja19pZigpIHRoYXQgY2FuIGJlIHVzZWQgdG8KY29uZGl0aW9uYWxseSB0
YWtlIGEgbG9jayBpbiBhIHNwZWN1bGF0aW9uIHNhZmUgd2F5LgoKVGhpcyBp
cyBwYXJ0IG9mIFhTQS00NTMgLyBDVkUtMjAyNC0yMTkzCgpTaWduZWQtb2Zm
LWJ5OiBSb2dlciBQYXUgTW9ubsOpIDxyb2dlci5wYXVAY2l0cml4LmNvbT4K
UmV2aWV3ZWQtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4K
KGNoZXJyeSBwaWNrZWQgZnJvbSBjb21taXQgMDNjZjdjYTIzZTBlODc2MDc1
OTU0YzU1ODQ4NWIyNjdiN2QwMjQwNikKCmRpZmYgLS1naXQgYS94ZW4vYXJj
aC94ODYvbW0uYyBiL3hlbi9hcmNoL3g4Ni9tbS5jCmluZGV4IDAwMGZkMGZi
NTU4Yi4uNDViZmJjMjUyMmY3IDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYv
bW0uYworKysgYi94ZW4vYXJjaC94ODYvbW0uYwpAQCAtNTAwNyw4ICs1MDA3
LDcgQEAgc3RhdGljIGwzX3BnZW50cnlfdCAqdmlydF90b194ZW5fbDNlKHVu
c2lnbmVkIGxvbmcgdikKICAgICAgICAgaWYgKCAhbDN0ICkKICAgICAgICAg
ICAgIHJldHVybiBOVUxMOwogICAgICAgICBVTk1BUF9ET01BSU5fUEFHRShs
M3QpOwotICAgICAgICBpZiAoIGxvY2tpbmcgKQotICAgICAgICAgICAgc3Bp
bl9sb2NrKCZtYXBfcGdkaXJfbG9jayk7CisgICAgICAgIHNwaW5fbG9ja19p
Zihsb2NraW5nLCAmbWFwX3BnZGlyX2xvY2spOwogICAgICAgICBpZiAoICEo
bDRlX2dldF9mbGFncygqcGw0ZSkgJiBfUEFHRV9QUkVTRU5UKSApCiAgICAg
ICAgIHsKICAgICAgICAgICAgIGw0X3BnZW50cnlfdCBsNGUgPSBsNGVfZnJv
bV9tZm4obDNtZm4sIF9fUEFHRV9IWVBFUlZJU09SKTsKQEAgLTUwNDUsOCAr
NTA0NCw3IEBAIHN0YXRpYyBsMl9wZ2VudHJ5X3QgKnZpcnRfdG9feGVuX2wy
ZSh1bnNpZ25lZCBsb25nIHYpCiAgICAgICAgICAgICByZXR1cm4gTlVMTDsK
ICAgICAgICAgfQogICAgICAgICBVTk1BUF9ET01BSU5fUEFHRShsMnQpOwot
ICAgICAgICBpZiAoIGxvY2tpbmcgKQotICAgICAgICAgICAgc3Bpbl9sb2Nr
KCZtYXBfcGdkaXJfbG9jayk7CisgICAgICAgIHNwaW5fbG9ja19pZihsb2Nr
aW5nLCAmbWFwX3BnZGlyX2xvY2spOwogICAgICAgICBpZiAoICEobDNlX2dl
dF9mbGFncygqcGwzZSkgJiBfUEFHRV9QUkVTRU5UKSApCiAgICAgICAgIHsK
ICAgICAgICAgICAgIGwzZV93cml0ZShwbDNlLCBsM2VfZnJvbV9tZm4obDJt
Zm4sIF9fUEFHRV9IWVBFUlZJU09SKSk7CkBAIC01MDg0LDggKzUwODIsNyBA
QCBsMV9wZ2VudHJ5X3QgKnZpcnRfdG9feGVuX2wxZSh1bnNpZ25lZCBsb25n
IHYpCiAgICAgICAgICAgICByZXR1cm4gTlVMTDsKICAgICAgICAgfQogICAg
ICAgICBVTk1BUF9ET01BSU5fUEFHRShsMXQpOwotICAgICAgICBpZiAoIGxv
Y2tpbmcgKQotICAgICAgICAgICAgc3Bpbl9sb2NrKCZtYXBfcGdkaXJfbG9j
ayk7CisgICAgICAgIHNwaW5fbG9ja19pZihsb2NraW5nLCAmbWFwX3BnZGly
X2xvY2spOwogICAgICAgICBpZiAoICEobDJlX2dldF9mbGFncygqcGwyZSkg
JiBfUEFHRV9QUkVTRU5UKSApCiAgICAgICAgIHsKICAgICAgICAgICAgIGwy
ZV93cml0ZShwbDJlLCBsMmVfZnJvbV9tZm4obDFtZm4sIF9fUEFHRV9IWVBF
UlZJU09SKSk7CkBAIC01MTE2LDYgKzUxMTMsOCBAQCBsMV9wZ2VudHJ5X3Qg
KnZpcnRfdG9feGVuX2wxZSh1bnNpZ25lZCBsb25nIHYpCiAgICAgZG8geyAg
ICAgICAgICAgICAgICAgICAgICBcCiAgICAgICAgIGlmICggbG9ja2luZyAp
ICAgICAgICBcCiAgICAgICAgICAgICBsM3RfbG9jayhwYWdlKTsgICBcCisg
ICAgICAgIGVsc2UgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAorICAg
ICAgICAgICAgYmxvY2tfbG9ja19zcGVjdWxhdGlvbigpOyAgIFwKICAgICB9
IHdoaWxlICggZmFsc2UgKQogCiAjZGVmaW5lIEwzVF9VTkxPQ0socGFnZSkg
ICAgICAgICAgICAgICAgICAgICAgICAgICBcCkBAIC01MzMxLDggKzUzMzAs
NyBAQCBpbnQgbWFwX3BhZ2VzX3RvX3hlbigKICAgICAgICAgICAgIGlmICgg
bDNlX2dldF9mbGFncyhvbDNlKSAmIF9QQUdFX0dMT0JBTCApCiAgICAgICAg
ICAgICAgICAgZmx1c2hfZmxhZ3MgfD0gRkxVU0hfVExCX0dMT0JBTDsKIAot
ICAgICAgICAgICAgaWYgKCBsb2NraW5nICkKLSAgICAgICAgICAgICAgICBz
cGluX2xvY2soJm1hcF9wZ2Rpcl9sb2NrKTsKKyAgICAgICAgICAgIHNwaW5f
bG9ja19pZihsb2NraW5nLCAmbWFwX3BnZGlyX2xvY2spOwogICAgICAgICAg
ICAgaWYgKCAobDNlX2dldF9mbGFncygqcGwzZSkgJiBfUEFHRV9QUkVTRU5U
KSAmJgogICAgICAgICAgICAgICAgICAobDNlX2dldF9mbGFncygqcGwzZSkg
JiBfUEFHRV9QU0UpICkKICAgICAgICAgICAgIHsKQEAgLTU0MzYsOCArNTQz
NCw3IEBAIGludCBtYXBfcGFnZXNfdG9feGVuKAogICAgICAgICAgICAgICAg
IGlmICggbDJlX2dldF9mbGFncygqcGwyZSkgJiBfUEFHRV9HTE9CQUwgKQog
ICAgICAgICAgICAgICAgICAgICBmbHVzaF9mbGFncyB8PSBGTFVTSF9UTEJf
R0xPQkFMOwogCi0gICAgICAgICAgICAgICAgaWYgKCBsb2NraW5nICkKLSAg
ICAgICAgICAgICAgICAgICAgc3Bpbl9sb2NrKCZtYXBfcGdkaXJfbG9jayk7
CisgICAgICAgICAgICAgICAgc3Bpbl9sb2NrX2lmKGxvY2tpbmcsICZtYXBf
cGdkaXJfbG9jayk7CiAgICAgICAgICAgICAgICAgaWYgKCAobDJlX2dldF9m
bGFncygqcGwyZSkgJiBfUEFHRV9QUkVTRU5UKSAmJgogICAgICAgICAgICAg
ICAgICAgICAgKGwyZV9nZXRfZmxhZ3MoKnBsMmUpICYgX1BBR0VfUFNFKSAp
CiAgICAgICAgICAgICAgICAgewpAQCAtNTQ3OCw4ICs1NDc1LDcgQEAgaW50
IG1hcF9wYWdlc190b194ZW4oCiAgICAgICAgICAgICAgICAgdW5zaWduZWQg
bG9uZyBiYXNlX21mbjsKICAgICAgICAgICAgICAgICBjb25zdCBsMV9wZ2Vu
dHJ5X3QgKmwxdDsKIAotICAgICAgICAgICAgICAgIGlmICggbG9ja2luZyAp
Ci0gICAgICAgICAgICAgICAgICAgIHNwaW5fbG9jaygmbWFwX3BnZGlyX2xv
Y2spOworICAgICAgICAgICAgICAgIHNwaW5fbG9ja19pZihsb2NraW5nLCAm
bWFwX3BnZGlyX2xvY2spOwogCiAgICAgICAgICAgICAgICAgb2wyZSA9ICpw
bDJlOwogICAgICAgICAgICAgICAgIC8qCkBAIC01NTMzLDggKzU1MjksNyBA
QCBpbnQgbWFwX3BhZ2VzX3RvX3hlbigKICAgICAgICAgICAgIHVuc2lnbmVk
IGxvbmcgYmFzZV9tZm47CiAgICAgICAgICAgICBjb25zdCBsMl9wZ2VudHJ5
X3QgKmwydDsKIAotICAgICAgICAgICAgaWYgKCBsb2NraW5nICkKLSAgICAg
ICAgICAgICAgICBzcGluX2xvY2soJm1hcF9wZ2Rpcl9sb2NrKTsKKyAgICAg
ICAgICAgIHNwaW5fbG9ja19pZihsb2NraW5nLCAmbWFwX3BnZGlyX2xvY2sp
OwogCiAgICAgICAgICAgICBvbDNlID0gKnBsM2U7CiAgICAgICAgICAgICAv
KgpAQCAtNTY3OCw4ICs1NjczLDcgQEAgaW50IG1vZGlmeV94ZW5fbWFwcGlu
Z3ModW5zaWduZWQgbG9uZyBzLCB1bnNpZ25lZCBsb25nIGUsIHVuc2lnbmVk
IGludCBuZikKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIGwzZV9nZXRfZmxhZ3MoKnBsM2UpKSk7CiAgICAgICAgICAgICBVTk1B
UF9ET01BSU5fUEFHRShsMnQpOwogCi0gICAgICAgICAgICBpZiAoIGxvY2tp
bmcgKQotICAgICAgICAgICAgICAgIHNwaW5fbG9jaygmbWFwX3BnZGlyX2xv
Y2spOworICAgICAgICAgICAgc3Bpbl9sb2NrX2lmKGxvY2tpbmcsICZtYXBf
cGdkaXJfbG9jayk7CiAgICAgICAgICAgICBpZiAoIChsM2VfZ2V0X2ZsYWdz
KCpwbDNlKSAmIF9QQUdFX1BSRVNFTlQpICYmCiAgICAgICAgICAgICAgICAg
IChsM2VfZ2V0X2ZsYWdzKCpwbDNlKSAmIF9QQUdFX1BTRSkgKQogICAgICAg
ICAgICAgewpAQCAtNTczOCw4ICs1NzMyLDcgQEAgaW50IG1vZGlmeV94ZW5f
bWFwcGluZ3ModW5zaWduZWQgbG9uZyBzLCB1bnNpZ25lZCBsb25nIGUsIHVu
c2lnbmVkIGludCBuZikKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBsMmVfZ2V0X2ZsYWdzKCpwbDJlKSAmIH5fUEFHRV9Q
U0UpKTsKICAgICAgICAgICAgICAgICBVTk1BUF9ET01BSU5fUEFHRShsMXQp
OwogCi0gICAgICAgICAgICAgICAgaWYgKCBsb2NraW5nICkKLSAgICAgICAg
ICAgICAgICAgICAgc3Bpbl9sb2NrKCZtYXBfcGdkaXJfbG9jayk7CisgICAg
ICAgICAgICAgICAgc3Bpbl9sb2NrX2lmKGxvY2tpbmcsICZtYXBfcGdkaXJf
bG9jayk7CiAgICAgICAgICAgICAgICAgaWYgKCAobDJlX2dldF9mbGFncygq
cGwyZSkgJiBfUEFHRV9QUkVTRU5UKSAmJgogICAgICAgICAgICAgICAgICAg
ICAgKGwyZV9nZXRfZmxhZ3MoKnBsMmUpICYgX1BBR0VfUFNFKSApCiAgICAg
ICAgICAgICAgICAgewpAQCAtNTc4Myw4ICs1Nzc2LDcgQEAgaW50IG1vZGlm
eV94ZW5fbWFwcGluZ3ModW5zaWduZWQgbG9uZyBzLCB1bnNpZ25lZCBsb25n
IGUsIHVuc2lnbmVkIGludCBuZikKICAgICAgICAgICAgICAqLwogICAgICAg
ICAgICAgaWYgKCAobmYgJiBfUEFHRV9QUkVTRU5UKSB8fCAoKHYgIT0gZSkg
JiYgKGwxX3RhYmxlX29mZnNldCh2KSAhPSAwKSkgKQogICAgICAgICAgICAg
ICAgIGNvbnRpbnVlOwotICAgICAgICAgICAgaWYgKCBsb2NraW5nICkKLSAg
ICAgICAgICAgICAgICBzcGluX2xvY2soJm1hcF9wZ2Rpcl9sb2NrKTsKKyAg
ICAgICAgICAgIHNwaW5fbG9ja19pZihsb2NraW5nLCAmbWFwX3BnZGlyX2xv
Y2spOwogCiAgICAgICAgICAgICAvKgogICAgICAgICAgICAgICogTDJFIG1h
eSBiZSBhbHJlYWR5IGNsZWFyZWQsIG9yIHNldCB0byBhIHN1cGVycGFnZSwg
YnkKQEAgLTU4MzEsOCArNTgyMyw3IEBAIGludCBtb2RpZnlfeGVuX21hcHBp
bmdzKHVuc2lnbmVkIGxvbmcgcywgdW5zaWduZWQgbG9uZyBlLCB1bnNpZ25l
ZCBpbnQgbmYpCiAgICAgICAgIGlmICggKG5mICYgX1BBR0VfUFJFU0VOVCkg
fHwKICAgICAgICAgICAgICAoKHYgIT0gZSkgJiYgKGwyX3RhYmxlX29mZnNl
dCh2KSArIGwxX3RhYmxlX29mZnNldCh2KSAhPSAwKSkgKQogICAgICAgICAg
ICAgY29udGludWU7Ci0gICAgICAgIGlmICggbG9ja2luZyApCi0gICAgICAg
ICAgICBzcGluX2xvY2soJm1hcF9wZ2Rpcl9sb2NrKTsKKyAgICAgICAgc3Bp
bl9sb2NrX2lmKGxvY2tpbmcsICZtYXBfcGdkaXJfbG9jayk7CiAKICAgICAg
ICAgLyoKICAgICAgICAgICogTDNFIG1heSBiZSBhbHJlYWR5IGNsZWFyZWQs
IG9yIHNldCB0byBhIHN1cGVycGFnZSwgYnkKZGlmZiAtLWdpdCBhL3hlbi9h
cmNoL3g4Ni9tbS9tbS1sb2Nrcy5oIGIveGVuL2FyY2gveDg2L21tL21tLWxv
Y2tzLmgKaW5kZXggNWVjMDgwYzAyZmQ4Li5iNDk2MGZiOTBlZmYgMTAwNjQ0
Ci0tLSBhL3hlbi9hcmNoL3g4Ni9tbS9tbS1sb2Nrcy5oCisrKyBiL3hlbi9h
cmNoL3g4Ni9tbS9tbS1sb2Nrcy5oCkBAIC0zMzUsNiArMzM1LDE1IEBAIHN0
YXRpYyBpbmxpbmUgdm9pZCBwMm1fdW5sb2NrKHN0cnVjdCBwMm1fZG9tYWlu
ICpwKQogI2RlZmluZSBwMm1fbG9ja2VkX2J5X21lKHApICAgbW1fd3JpdGVf
bG9ja2VkX2J5X21lKCYocCktPmxvY2spCiAjZGVmaW5lIGdmbl9sb2NrZWRf
YnlfbWUocCxnKSBwMm1fbG9ja2VkX2J5X21lKHApCiAKK3N0YXRpYyBhbHdh
eXNfaW5saW5lIHZvaWQgZ2ZuX2xvY2tfaWYoYm9vbCBjb25kaXRpb24sIHN0
cnVjdCBwMm1fZG9tYWluICpwMm0sCisgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIGdmbl90IGdmbiwgdW5zaWduZWQgaW50IG9yZGVy
KQoreworICAgIGlmICggY29uZGl0aW9uICkKKyAgICAgICAgZ2ZuX2xvY2so
cDJtLCBnZm4sIG9yZGVyKTsKKyAgICBlbHNlCisgICAgICAgIGJsb2NrX2xv
Y2tfc3BlY3VsYXRpb24oKTsKK30KKwogLyogUG9EIGxvY2sgKHBlci1wMm0t
dGFibGUpCiAgKgogICogUHJvdGVjdHMgcHJpdmF0ZSBQb0QgZGF0YSBzdHJ1
Y3RzOiBlbnRyeSBhbmQgY2FjaGUKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4
Ni9tbS9wMm0uYyBiL3hlbi9hcmNoL3g4Ni9tbS9wMm0uYwppbmRleCAwOTgz
YmQ3MWQ5YTkuLjIyYWIxZDYwNmU4YSAxMDA2NDQKLS0tIGEveGVuL2FyY2gv
eDg2L21tL3AybS5jCisrKyBiL3hlbi9hcmNoL3g4Ni9tbS9wMm0uYwpAQCAt
MjgwLDkgKzI4MCw4IEBAIG1mbl90IHAybV9nZXRfZ2ZuX3R5cGVfYWNjZXNz
KHN0cnVjdCBwMm1fZG9tYWluICpwMm0sIGdmbl90IGdmbiwKICAgICBpZiAo
IHEgJiBQMk1fVU5TSEFSRSApCiAgICAgICAgIHEgfD0gUDJNX0FMTE9DOwog
Ci0gICAgaWYgKCBsb2NrZWQgKQotICAgICAgICAvKiBHcmFiIHRoZSBsb2Nr
IGhlcmUsIGRvbid0IHJlbGVhc2UgdW50aWwgcHV0X2dmbiAqLwotICAgICAg
ICBnZm5fbG9jayhwMm0sIGdmbiwgMCk7CisgICAgLyogR3JhYiB0aGUgbG9j
ayBoZXJlLCBkb24ndCByZWxlYXNlIHVudGlsIHB1dF9nZm4gKi8KKyAgICBn
Zm5fbG9ja19pZihsb2NrZWQsIHAybSwgZ2ZuLCAwKTsKIAogICAgIG1mbiA9
IHAybS0+Z2V0X2VudHJ5KHAybSwgZ2ZuLCB0LCBhLCBxLCBwYWdlX29yZGVy
LCBOVUxMKTsKIApkaWZmIC0tZ2l0IGEveGVuL2luY2x1ZGUveGVuL3NwaW5s
b2NrLmggYi94ZW4vaW5jbHVkZS94ZW4vc3BpbmxvY2suaAppbmRleCAyOGZj
ZTU2MTVlNWMuLmM4MzBkZjM0MzBhMyAxMDA2NDQKLS0tIGEveGVuL2luY2x1
ZGUveGVuL3NwaW5sb2NrLmgKKysrIGIveGVuL2luY2x1ZGUveGVuL3NwaW5s
b2NrLmgKQEAgLTIyMiw2ICsyMjIsMTQgQEAgc3RhdGljIGFsd2F5c19pbmxp
bmUgdm9pZCBzcGluX2xvY2tfaXJxKHNwaW5sb2NrX3QgKmwpCiAgICAgICAg
IGJsb2NrX2xvY2tfc3BlY3VsYXRpb24oKTsgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgXAogICAgIH0pCiAKKy8qIENvbmRpdGlvbmFsbHkgdGFr
ZSBhIHNwaW5sb2NrIGluIGEgc3BlY3VsYXRpb24gc2FmZSB3YXkuICovCitz
dGF0aWMgYWx3YXlzX2lubGluZSB2b2lkIHNwaW5fbG9ja19pZihib29sIGNv
bmRpdGlvbiwgc3BpbmxvY2tfdCAqbCkKK3sKKyAgICBpZiAoIGNvbmRpdGlv
biApCisgICAgICAgIF9zcGluX2xvY2sobCk7CisgICAgYmxvY2tfbG9ja19z
cGVjdWxhdGlvbigpOworfQorCiAjZGVmaW5lIHNwaW5fdW5sb2NrKGwpICAg
ICAgICAgICAgICAgIF9zcGluX3VubG9jayhsKQogI2RlZmluZSBzcGluX3Vu
bG9ja19pcnEobCkgICAgICAgICAgICBfc3Bpbl91bmxvY2tfaXJxKGwpCiAj
ZGVmaW5lIHNwaW5fdW5sb2NrX2lycXJlc3RvcmUobCwgZikgIF9zcGluX3Vu
bG9ja19pcnFyZXN0b3JlKGwsIGYpCg==

--=separator
Content-Type: application/octet-stream; name="xsa453/xsa453-4.patch"
Content-Disposition: attachment; filename="xsa453/xsa453-4.patch"
Content-Transfer-Encoding: base64

RnJvbTogPT9VVEYtOD9xP1JvZ2VyPTIwUGF1PTIwTW9ubj1DMz1BOT89IDxy
b2dlci5wYXVAY2l0cml4LmNvbT4KU3ViamVjdDogcGVyY3B1LXJ3bG9jazog
aW50cm9kdWNlIHN1cHBvcnQgZm9yIGJsb2NraW5nIHNwZWN1bGF0aW9uIGlu
dG8KIGNyaXRpY2FsIHJlZ2lvbnMKCkFkZCBkaXJlY3QgY2FsbHMgdG8gYmxv
Y2tfbG9ja19zcGVjdWxhdGlvbigpIHdoZXJlIHJlcXVpcmVkIGluIG9yZGVy
IHRvIHByZXZlbnQKc3BlY3VsYXRpb24gaW50byB0aGUgbG9jayBwcm90ZWN0
ZWQgY3JpdGljYWwgcmVnaW9ucy4gIEFsc28gY29udmVydApfcGVyY3B1X3Jl
YWRfbG9jaygpIGZyb20gaW5saW5lIHRvIGFsd2F5c19pbmxpbmUuCgpOb3Rl
IHRoYXQgX3BlcmNwdV93cml0ZV9sb2NrKCkgaGFzIGJlZW4gbW9kaWZpZWQg
dGhlIHVzZSB0aGUgbm9uIHNwZWN1bGF0aW9uCnNhZmUgb2YgdGhlIGxvY2tp
bmcgcHJpbWl0ZXMsIGFzIGEgc3BlY3VsYXRpb24gaXMgYWRkZWQgdW5jb25k
aXRpb25hbGx5IGJ5IHRoZQpjYWxsaW5nIHdyYXBwZXIuCgpUaGlzIGlzIHBh
cnQgb2YgWFNBLTQ1MyAvIENWRS0yMDI0LTIxOTMKClNpZ25lZC1vZmYtYnk6
IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXguY29tPgpSZXZp
ZXdlZC1ieTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgoKZGlm
ZiAtLWdpdCBhL3hlbi9jb21tb24vcndsb2NrLmMgYi94ZW4vY29tbW9uL3J3
bG9jay5jCmluZGV4IDI5MDYwMjkzNmRmNi4uZjVhMjQ5YmNjMjQwIDEwMDY0
NAotLS0gYS94ZW4vY29tbW9uL3J3bG9jay5jCisrKyBiL3hlbi9jb21tb24v
cndsb2NrLmMKQEAgLTEyOSw4ICsxMjksMTIgQEAgdm9pZCBfcGVyY3B1X3dy
aXRlX2xvY2socGVyY3B1X3J3bG9ja190ICoqcGVyX2NwdWRhdGEsCiAgICAg
LyoKICAgICAgKiBGaXJzdCB0YWtlIHRoZSB3cml0ZSBsb2NrIHRvIHByb3Rl
Y3QgYWdhaW5zdCBvdGhlciB3cml0ZXJzIG9yIHNsb3cKICAgICAgKiBwYXRo
IHJlYWRlcnMuCisgICAgICoKKyAgICAgKiBOb3RlIHdlIHVzZSB0aGUgc3Bl
Y3VsYXRpb24gdW5zYWZlIHZhcmlhbnQgb2Ygd3JpdGVfbG9jaygpLCBhcyB0
aGUKKyAgICAgKiBjYWxsaW5nIHdyYXBwZXIgYWxyZWFkeSBhZGRzIGEgc3Bl
Y3VsYXRpb24gYmFycmllciBhZnRlciB0aGUgbG9jayBoYXMKKyAgICAgKiBi
ZWVuIHRha2VuLgogICAgICAqLwotICAgIHdyaXRlX2xvY2soJnBlcmNwdV9y
d2xvY2stPnJ3bG9jayk7CisgICAgX3dyaXRlX2xvY2soJnBlcmNwdV9yd2xv
Y2stPnJ3bG9jayk7CiAKICAgICAvKiBOb3cgc2V0IHRoZSBnbG9iYWwgdmFy
aWFibGUgc28gdGhhdCByZWFkZXJzIHN0YXJ0IHVzaW5nIHJlYWRfbG9jay4g
Ki8KICAgICBwZXJjcHVfcndsb2NrLT53cml0ZXJfYWN0aXZhdGluZyA9IDE7
CmRpZmYgLS1naXQgYS94ZW4vaW5jbHVkZS94ZW4vcndsb2NrLmggYi94ZW4v
aW5jbHVkZS94ZW4vcndsb2NrLmgKaW5kZXggZmZmZjBmYWQ0NWE3Li42NWQ4
OGIwZWY0NWQgMTAwNjQ0Ci0tLSBhL3hlbi9pbmNsdWRlL3hlbi9yd2xvY2su
aAorKysgYi94ZW4vaW5jbHVkZS94ZW4vcndsb2NrLmgKQEAgLTMzOCw4ICsz
MzgsOCBAQCBzdGF0aWMgaW5saW5lIHZvaWQgX3BlcmNwdV9yd2xvY2tfb3du
ZXJfY2hlY2socGVyY3B1X3J3bG9ja190ICoqcGVyX2NwdWRhdGEsCiAjZGVm
aW5lIHBlcmNwdV9yd2xvY2tfcmVzb3VyY2VfaW5pdChsLCBvd25lcikgXAog
ICAgICgqKGwpID0gKHBlcmNwdV9yd2xvY2tfdClQRVJDUFVfUldfTE9DS19V
TkxPQ0tFRCgmZ2V0X3Blcl9jcHVfdmFyKG93bmVyKSkpCiAKLXN0YXRpYyBp
bmxpbmUgdm9pZCBfcGVyY3B1X3JlYWRfbG9jayhwZXJjcHVfcndsb2NrX3Qg
KipwZXJfY3B1ZGF0YSwKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgcGVyY3B1X3J3bG9ja190ICpwZXJjcHVfcndsb2NrKQor
c3RhdGljIGFsd2F5c19pbmxpbmUgdm9pZCBfcGVyY3B1X3JlYWRfbG9jayhw
ZXJjcHVfcndsb2NrX3QgKipwZXJfY3B1ZGF0YSwKKyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcGVyY3B1X3J3bG9ja190
ICpwZXJjcHVfcndsb2NrKQogewogICAgIC8qIFZhbGlkYXRlIHRoZSBjb3Jy
ZWN0IHBlcl9jcHVkYXRhIHZhcmlhYmxlIGhhcyBiZWVuIHByb3ZpZGVkLiAq
LwogICAgIF9wZXJjcHVfcndsb2NrX293bmVyX2NoZWNrKHBlcl9jcHVkYXRh
LCBwZXJjcHVfcndsb2NrKTsKQEAgLTM3NCw2ICszNzQsOCBAQCBzdGF0aWMg
aW5saW5lIHZvaWQgX3BlcmNwdV9yZWFkX2xvY2socGVyY3B1X3J3bG9ja190
ICoqcGVyX2NwdWRhdGEsCiAgICAgfQogICAgIGVsc2UKICAgICB7CisgICAg
ICAgIC8qIE90aGVyIGJyYW5jaCBhbHJlYWR5IGhhcyBhIHNwZWN1bGF0aW9u
IGJhcnJpZXIgaW4gcmVhZF9sb2NrKCkuICovCisgICAgICAgIGJsb2NrX2xv
Y2tfc3BlY3VsYXRpb24oKTsKICAgICAgICAgLyogQWxsIG90aGVyIHBhdGhz
IGhhdmUgaW1wbGljaXQgY2hlY2tfbG9jaygpIGNhbGxzIHZpYSByZWFkX2xv
Y2soKS4gKi8KICAgICAgICAgY2hlY2tfbG9jaygmcGVyY3B1X3J3bG9jay0+
cndsb2NrLmxvY2suZGVidWcsIGZhbHNlKTsKICAgICB9CkBAIC00MzAsOCAr
NDMyLDEyIEBAIHN0YXRpYyBpbmxpbmUgdm9pZCBfcGVyY3B1X3dyaXRlX3Vu
bG9jayhwZXJjcHVfcndsb2NrX3QgKipwZXJfY3B1ZGF0YSwKICAgICBfcGVy
Y3B1X3JlYWRfbG9jaygmZ2V0X3Blcl9jcHVfdmFyKHBlcmNwdSksIGxvY2sp
CiAjZGVmaW5lIHBlcmNwdV9yZWFkX3VubG9jayhwZXJjcHUsIGxvY2spIFwK
ICAgICBfcGVyY3B1X3JlYWRfdW5sb2NrKCZnZXRfcGVyX2NwdV92YXIocGVy
Y3B1KSwgbG9jaykKLSNkZWZpbmUgcGVyY3B1X3dyaXRlX2xvY2socGVyY3B1
LCBsb2NrKSBcCi0gICAgX3BlcmNwdV93cml0ZV9sb2NrKCZnZXRfcGVyX2Nw
dV92YXIocGVyY3B1KSwgbG9jaykKKworI2RlZmluZSBwZXJjcHVfd3JpdGVf
bG9jayhwZXJjcHUsIGxvY2spICAgICAgICAgICAgICAgICBcCisoeyAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIFwKKyAgICBfcGVyY3B1X3dyaXRlX2xvY2soJmdldF9wZXJfY3B1X3Zh
cihwZXJjcHUpLCBsb2NrKTsgXAorICAgIGJsb2NrX2xvY2tfc3BlY3VsYXRp
b24oKTsgICAgICAgICAgICAgICAgICAgICAgICAgICBcCit9KQogI2RlZmlu
ZSBwZXJjcHVfd3JpdGVfdW5sb2NrKHBlcmNwdSwgbG9jaykgXAogICAgIF9w
ZXJjcHVfd3JpdGVfdW5sb2NrKCZnZXRfcGVyX2NwdV92YXIocGVyY3B1KSwg
bG9jaykKIAo=

--=separator
Content-Type: application/octet-stream; name="xsa453/xsa453-5.patch"
Content-Disposition: attachment; filename="xsa453/xsa453-5.patch"
Content-Transfer-Encoding: base64

RnJvbTogPT9VVEYtOD9xP1JvZ2VyPTIwUGF1PTIwTW9ubj1DMz1BOT89IDxy
b2dlci5wYXVAY2l0cml4LmNvbT4KU3ViamVjdDogbG9ja2luZzogYXR0ZW1w
dCB0byBlbnN1cmUgbG9jayB3cmFwcGVycyBhcmUgYWx3YXlzIGlubGluZQoK
SW4gb3JkZXIgdG8gcHJldmVudCB0aGUgbG9ja2luZyBzcGVjdWxhdGlvbiBi
YXJyaWVycyBmcm9tIGJlaW5nIGluc2lkZSBvZgpgY2FsbGBlZCBmdW5jdGlv
bnMgdGhhdCBjb3VsZCBiZSBzcGVjdWxhdGl2ZWx5IGJ5cGFzc2VkLgoKV2hp
bGUgdGhlcmUgYWxzbyBhZGQgYW4gZXh0cmEgbG9ja2luZyBiYXJyaWVyIHRv
IF9tbV93cml0ZV9sb2NrKCkgaW4gdGhlIGJyYW5jaAp0YWtlbiB3aGVuIHRo
ZSBsb2NrIGlzIGFscmVhZHkgaGVsZC4KCk5vdGUgc29tZSBmdW5jdGlvbnMg
YXJlIHN3aXRjaGVkIHRvIHVzZSB0aGUgdW5zYWZlIHZhcmlhbnRzICh3aXRo
b3V0IHNwZWN1bGF0aW9uCmJhcnJpZXIpIG9mIHRoZSBsb2NraW5nIHByaW1p
dGl2ZXMsIGJ1dCBhIHNwZWN1bGF0aW9uIGJhcnJpZXIgaXMgYWx3YXlzIGFk
ZGVkCnRvIHRoZSBleHBvc2VkIHB1YmxpYyBsb2NrIHdyYXBwaW5nIGhlbHBl
ci4gIFRoYXQncyB0aGUgY2FzZSB3aXRoCnNjaGVkX3NwaW5fbG9ja19kb3Vi
bGUoKSBvciBwY2lkZXZzX2xvY2soKSBmb3IgZXhhbXBsZS4KClRoaXMgaXMg
cGFydCBvZiBYU0EtNDUzIC8gQ1ZFLTIwMjQtMjE5MwoKU2lnbmVkLW9mZi1i
eTogUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5jb20+ClJl
dmlld2VkLWJ5OiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+Cgpk
aWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2h2bS92cHQuYyBiL3hlbi9hcmNo
L3g4Ni9odm0vdnB0LmMKaW5kZXggOGY1M2U4OGQ2NzA2Li5lMWQ2ODQ1YTI4
NDQgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9odm0vdnB0LmMKKysrIGIv
eGVuL2FyY2gveDg2L2h2bS92cHQuYwpAQCAtMTUwLDcgKzE1MCw3IEBAIHN0
YXRpYyBpbnQgcHRfaXJxX21hc2tlZChzdHJ1Y3QgcGVyaW9kaWNfdGltZSAq
cHQpCiAgKiBwdC0+dmNwdSBmaWVsZCwgYmVjYXVzZSBhbm90aGVyIHRocmVh
ZCBob2xkaW5nIHRoZSBwdF9taWdyYXRlIGxvY2sKICAqIG1heSBhbHJlYWR5
IGJlIHNwaW5uaW5nIHdhaXRpbmcgZm9yIHlvdXIgdmNwdSBsb2NrLgogICov
Ci1zdGF0aWMgdm9pZCBwdF92Y3B1X2xvY2soc3RydWN0IHZjcHUgKnYpCitz
dGF0aWMgYWx3YXlzX2lubGluZSB2b2lkIHB0X3ZjcHVfbG9jayhzdHJ1Y3Qg
dmNwdSAqdikKIHsKICAgICBzcGluX2xvY2soJnYtPmFyY2guaHZtLnRtX2xv
Y2spOwogfQpAQCAtMTY5LDkgKzE2OSwxMyBAQCBzdGF0aWMgdm9pZCBwdF92
Y3B1X3VubG9jayhzdHJ1Y3QgdmNwdSAqdikKICAqIG5lZWQgdG8gdGFrZSBh
biBhZGRpdGlvbmFsIGxvY2sgdGhhdCBwcm90ZWN0cyBhZ2FpbnN0IHB0LT52
Y3B1CiAgKiBjaGFuZ2luZy4KICAqLwotc3RhdGljIHZvaWQgcHRfbG9jayhz
dHJ1Y3QgcGVyaW9kaWNfdGltZSAqcHQpCitzdGF0aWMgYWx3YXlzX2lubGlu
ZSB2b2lkIHB0X2xvY2soc3RydWN0IHBlcmlvZGljX3RpbWUgKnB0KQogewot
ICAgIHJlYWRfbG9jaygmcHQtPnZjcHUtPmRvbWFpbi0+YXJjaC5odm0ucGxf
dGltZS0+cHRfbWlncmF0ZSk7CisgICAgLyoKKyAgICAgKiBVc2UgdGhlIHNw
ZWN1bGF0aW9uIHVuc2FmZSB2YXJpYW50IGZvciB0aGUgZmlyc3QgbG9jaywg
YXMgdGhlIGZvbGxvd2luZworICAgICAqIGxvY2sgdGFraW5nIGhlbHBlciBh
bHJlYWR5IGluY2x1ZGVzIGEgc3BlY3VsYXRpb24gYmFycmllci4KKyAgICAg
Ki8KKyAgICBfcmVhZF9sb2NrKCZwdC0+dmNwdS0+ZG9tYWluLT5hcmNoLmh2
bS5wbF90aW1lLT5wdF9taWdyYXRlKTsKICAgICBzcGluX2xvY2soJnB0LT52
Y3B1LT5hcmNoLmh2bS50bV9sb2NrKTsKIH0KIApkaWZmIC0tZ2l0IGEveGVu
L2FyY2gveDg2L2luY2x1ZGUvYXNtL2lycS5oIGIveGVuL2FyY2gveDg2L2lu
Y2x1ZGUvYXNtL2lycS5oCmluZGV4IDdkNDlmM2MxOTA0YS4uNDEzOTk0ZDIx
MzNiIDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vaXJx
LmgKKysrIGIveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2lycS5oCkBAIC0x
NTEsNiArMTUxLDcgQEAgdm9pZCBjZl9jaGVjayBpcnFfY29tcGxldGVfbW92
ZShzdHJ1Y3QgaXJxX2Rlc2MgKmRlc2MpOwogCiBleHRlcm4gc3RydWN0IGly
cV9kZXNjICppcnFfZGVzYzsKIAorLyogTm90IHNwZWN1bGF0aW9uIHNhZmUs
IG9ubHkgdXNlZCBmb3IgQVAgYnJpbmd1cC4gKi8KIHZvaWQgbG9ja192ZWN0
b3JfbG9jayh2b2lkKTsKIHZvaWQgdW5sb2NrX3ZlY3Rvcl9sb2NrKHZvaWQp
OwogCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYvbW0vbW0tbG9ja3MuaCBi
L3hlbi9hcmNoL3g4Ni9tbS9tbS1sb2Nrcy5oCmluZGV4IDAwYjFiYzQwMmQ2
ZC4uMjczZmZmODZiYWE0IDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYvbW0v
bW0tbG9ja3MuaAorKysgYi94ZW4vYXJjaC94ODYvbW0vbW0tbG9ja3MuaApA
QCAtNzQsOCArNzQsOCBAQCBzdGF0aWMgaW5saW5lIHZvaWQgX3NldF9sb2Nr
X2xldmVsKGludCBsKQogICAgIHRoaXNfY3B1KG1tX2xvY2tfbGV2ZWwpID0g
bDsKIH0KIAotc3RhdGljIGlubGluZSB2b2lkIF9tbV9sb2NrKGNvbnN0IHN0
cnVjdCBkb21haW4gKmQsIG1tX2xvY2tfdCAqbCwKLSAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBjb25zdCBjaGFyICpmdW5jLCBpbnQgbGV2ZWwsIGlu
dCByZWMpCitzdGF0aWMgYWx3YXlzX2lubGluZSB2b2lkIF9tbV9sb2NrKGNv
bnN0IHN0cnVjdCBkb21haW4gKmQsIG1tX2xvY2tfdCAqbCwKKyAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3QgY2hhciAqZnVuYywg
aW50IGxldmVsLCBpbnQgcmVjKQogewogICAgIGlmICggISgobW1fbG9ja2Vk
X2J5X21lKGwpKSAmJiByZWMpICkKICAgICAgICAgX2NoZWNrX2xvY2tfbGV2
ZWwoZCwgbGV2ZWwpOwpAQCAtMTI1LDggKzEyNSw4IEBAIHN0YXRpYyBpbmxp
bmUgaW50IG1tX3dyaXRlX2xvY2tlZF9ieV9tZShtbV9yd2xvY2tfdCAqbCkK
ICAgICByZXR1cm4gKGwtPmxvY2tlciA9PSBzbXBfcHJvY2Vzc29yX2lkKCkp
OwogfQogCi1zdGF0aWMgaW5saW5lIHZvaWQgX21tX3dyaXRlX2xvY2soY29u
c3Qgc3RydWN0IGRvbWFpbiAqZCwgbW1fcndsb2NrX3QgKmwsCi0gICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3QgY2hhciAqZnVuYywg
aW50IGxldmVsKQorc3RhdGljIGFsd2F5c19pbmxpbmUgdm9pZCBfbW1fd3Jp
dGVfbG9jayhjb25zdCBzdHJ1Y3QgZG9tYWluICpkLCBtbV9yd2xvY2tfdCAq
bCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
Y29uc3QgY2hhciAqZnVuYywgaW50IGxldmVsKQogewogICAgIGlmICggIW1t
X3dyaXRlX2xvY2tlZF9ieV9tZShsKSApCiAgICAgewpAQCAtMTM3LDYgKzEz
Nyw4IEBAIHN0YXRpYyBpbmxpbmUgdm9pZCBfbW1fd3JpdGVfbG9jayhjb25z
dCBzdHJ1Y3QgZG9tYWluICpkLCBtbV9yd2xvY2tfdCAqbCwKICAgICAgICAg
bC0+dW5sb2NrX2xldmVsID0gX2dldF9sb2NrX2xldmVsKCk7CiAgICAgICAg
IF9zZXRfbG9ja19sZXZlbChfbG9ja19sZXZlbChkLCBsZXZlbCkpOwogICAg
IH0KKyAgICBlbHNlCisgICAgICAgIGJsb2NrX3NwZWN1bGF0aW9uKCk7CiAg
ICAgbC0+cmVjdXJzZV9jb3VudCsrOwogfQogCkBAIC0xNTAsOCArMTUyLDgg
QEAgc3RhdGljIGlubGluZSB2b2lkIG1tX3dyaXRlX3VubG9jayhtbV9yd2xv
Y2tfdCAqbCkKICAgICBwZXJjcHVfd3JpdGVfdW5sb2NrKHAybV9wZXJjcHVf
cndsb2NrLCAmbC0+bG9jayk7CiB9CiAKLXN0YXRpYyBpbmxpbmUgdm9pZCBf
bW1fcmVhZF9sb2NrKGNvbnN0IHN0cnVjdCBkb21haW4gKmQsIG1tX3J3bG9j
a190ICpsLAotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaW50
IGxldmVsKQorc3RhdGljIGFsd2F5c19pbmxpbmUgdm9pZCBfbW1fcmVhZF9s
b2NrKGNvbnN0IHN0cnVjdCBkb21haW4gKmQsIG1tX3J3bG9ja190ICpsLAor
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGludCBs
ZXZlbCkKIHsKICAgICBfY2hlY2tfbG9ja19sZXZlbChkLCBsZXZlbCk7CiAg
ICAgcGVyY3B1X3JlYWRfbG9jayhwMm1fcGVyY3B1X3J3bG9jaywgJmwtPmxv
Y2spOwpAQCAtMTY2LDE1ICsxNjgsMTUgQEAgc3RhdGljIGlubGluZSB2b2lk
IG1tX3JlYWRfdW5sb2NrKG1tX3J3bG9ja190ICpsKQogCiAvKiBUaGlzIHdy
YXBwZXIgdXNlcyB0aGUgbGluZSBudW1iZXIgdG8gZXhwcmVzcyB0aGUgbG9j
a2luZyBvcmRlciBiZWxvdyAqLwogI2RlZmluZSBkZWNsYXJlX21tX2xvY2so
bmFtZSkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgXAotICAgIHN0YXRpYyBpbmxpbmUgdm9pZCBtbV9sb2NrXyMj
bmFtZShjb25zdCBzdHJ1Y3QgZG9tYWluICpkLCBtbV9sb2NrX3QgKmwsICAg
XAotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25z
dCBjaGFyICpmdW5jLCBpbnQgcmVjKSAgICAgICAgICAgICAgXAorICAgIHN0
YXRpYyBhbHdheXNfaW5saW5lIHZvaWQgbW1fbG9ja18jI25hbWUoICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgXAorICAgICAgICBjb25zdCBz
dHJ1Y3QgZG9tYWluICpkLCBtbV9sb2NrX3QgKmwsIGNvbnN0IGNoYXIgKmZ1
bmMsIGludCByZWMpICAgICAgXAogICAgIHsgX21tX2xvY2soZCwgbCwgZnVu
YywgTU1fTE9DS19PUkRFUl8jI25hbWUsIHJlYyk7IH0KICNkZWZpbmUgZGVj
bGFyZV9tbV9yd2xvY2sobmFtZSkgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIFwKLSAgICBzdGF0aWMgaW5saW5lIHZv
aWQgbW1fd3JpdGVfbG9ja18jI25hbWUoY29uc3Qgc3RydWN0IGRvbWFpbiAq
ZCwgICAgICAgICAgIFwKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgbW1fcndsb2NrX3QgKmwsIGNvbnN0IGNoYXIgKmZ1
bmMpIFwKKyAgICBzdGF0aWMgYWx3YXlzX2lubGluZSB2b2lkIG1tX3dyaXRl
X2xvY2tfIyNuYW1lKCAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKKyAg
ICAgICAgY29uc3Qgc3RydWN0IGRvbWFpbiAqZCwgbW1fcndsb2NrX3QgKmws
IGNvbnN0IGNoYXIgKmZ1bmMpICAgICAgICAgICAgIFwKICAgICB7IF9tbV93
cml0ZV9sb2NrKGQsIGwsIGZ1bmMsIE1NX0xPQ0tfT1JERVJfIyNuYW1lKTsg
fSAgICAgICAgICAgICAgICAgICAgIFwKLSAgICBzdGF0aWMgaW5saW5lIHZv
aWQgbW1fcmVhZF9sb2NrXyMjbmFtZShjb25zdCBzdHJ1Y3QgZG9tYWluICpk
LCAgICAgICAgICAgIFwKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBtbV9yd2xvY2tfdCAqbCkgICAgICAgICAgICAgICAg
ICAgIFwKKyAgICBzdGF0aWMgYWx3YXlzX2lubGluZSB2b2lkIG1tX3JlYWRf
bG9ja18jI25hbWUoY29uc3Qgc3RydWN0IGRvbWFpbiAqZCwgICAgIFwKKyAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgbW1fcndsb2NrX3QgKmwpICAgICAgICAgICAgIFwKICAgICB7IF9tbV9y
ZWFkX2xvY2soZCwgbCwgTU1fTE9DS19PUkRFUl8jI25hbWUpOyB9CiAvKiBU
aGVzZSBjYXB0dXJlIHRoZSBuYW1lIG9mIHRoZSBjYWxsaW5nIGZ1bmN0aW9u
ICovCiAjZGVmaW5lIG1tX2xvY2sobmFtZSwgZCwgbCkgbW1fbG9ja18jI25h
bWUoZCwgbCwgX19mdW5jX18sIDApCkBAIC0zMDksNyArMzExLDcgQEAgZGVj
bGFyZV9tbV9sb2NrKGFsdHAybWxpc3QpCiAjZGVmaW5lIE1NX0xPQ0tfT1JE
RVJfYWx0cDJtICAgICAgICAgICAgICAgICA0MAogZGVjbGFyZV9tbV9yd2xv
Y2soYWx0cDJtKTsKIAotc3RhdGljIGlubGluZSB2b2lkIHAybV9sb2NrKHN0
cnVjdCBwMm1fZG9tYWluICpwKQorc3RhdGljIGFsd2F5c19pbmxpbmUgdm9p
ZCBwMm1fbG9jayhzdHJ1Y3QgcDJtX2RvbWFpbiAqcCkKIHsKICAgICBpZiAo
IHAybV9pc19hbHRwMm0ocCkgKQogICAgICAgICBtbV93cml0ZV9sb2NrKGFs
dHAybSwgcC0+ZG9tYWluLCAmcC0+bG9jayk7CmRpZmYgLS1naXQgYS94ZW4v
YXJjaC94ODYvbW0vcDJtLXBvZC5jIGIveGVuL2FyY2gveDg2L21tL3AybS1w
b2QuYwppbmRleCBiYzc4YzYxMDYyYjQuLjY1ZDMxZTU1MjMwNSAxMDA2NDQK
LS0tIGEveGVuL2FyY2gveDg2L21tL3AybS1wb2QuYworKysgYi94ZW4vYXJj
aC94ODYvbW0vcDJtLXBvZC5jCkBAIC0yNCw3ICsyNCw3IEBACiAjZGVmaW5l
IHN1cGVycGFnZV9hbGlnbmVkKF94KSAgKCgoX3gpJihTVVBFUlBBR0VfUEFH
RVMtMSkpPT0wKQogCiAvKiBFbmZvcmNlIGxvY2sgb3JkZXJpbmcgd2hlbiBn
cmFiYmluZyB0aGUgImV4dGVybmFsIiBwYWdlX2FsbG9jIGxvY2sgKi8KLXN0
YXRpYyBpbmxpbmUgdm9pZCBsb2NrX3BhZ2VfYWxsb2Moc3RydWN0IHAybV9k
b21haW4gKnAybSkKK3N0YXRpYyBhbHdheXNfaW5saW5lIHZvaWQgbG9ja19w
YWdlX2FsbG9jKHN0cnVjdCBwMm1fZG9tYWluICpwMm0pCiB7CiAgICAgcGFn
ZV9hbGxvY19tbV9wcmVfbG9jayhwMm0tPmRvbWFpbik7CiAgICAgc3Bpbl9s
b2NrKCYocDJtLT5kb21haW4tPnBhZ2VfYWxsb2NfbG9jaykpOwpkaWZmIC0t
Z2l0IGEveGVuL2NvbW1vbi9ldmVudF9jaGFubmVsLmMgYi94ZW4vY29tbW9u
L2V2ZW50X2NoYW5uZWwuYwppbmRleCAxNWFlYzVkY2JiZGEuLmJiZmRhMjUz
OGU4YSAxMDA2NDQKLS0tIGEveGVuL2NvbW1vbi9ldmVudF9jaGFubmVsLmMK
KysrIGIveGVuL2NvbW1vbi9ldmVudF9jaGFubmVsLmMKQEAgLTQ1LDcgKzQ1
LDcgQEAKICAqIGp1c3QgYXNzdW1lIHRoZSBldmVudCBjaGFubmVsIGlzIGZy
ZWUgb3IgdW5ib3VuZCBhdCB0aGUgbW9tZW50IHdoZW4gdGhlCiAgKiBldnRj
aG5fcmVhZF90cnlsb2NrKCkgcmV0dXJucyBmYWxzZS4KICAqLwotc3RhdGlj
IGlubGluZSB2b2lkIGV2dGNobl93cml0ZV9sb2NrKHN0cnVjdCBldnRjaG4g
KmV2dGNobikKK3N0YXRpYyBhbHdheXNfaW5saW5lIHZvaWQgZXZ0Y2huX3dy
aXRlX2xvY2soc3RydWN0IGV2dGNobiAqZXZ0Y2huKQogewogICAgIHdyaXRl
X2xvY2soJmV2dGNobi0+bG9jayk7CiAKQEAgLTM0OSw3ICszNDksOCBAQCBp
bnQgZXZ0Y2huX2FsbG9jX3VuYm91bmQoZXZ0Y2huX2FsbG9jX3VuYm91bmRf
dCAqYWxsb2MsIGV2dGNobl9wb3J0X3QgcG9ydCkKICAgICByZXR1cm4gcmM7
CiB9CiAKLXN0YXRpYyB2b2lkIGRvdWJsZV9ldnRjaG5fbG9jayhzdHJ1Y3Qg
ZXZ0Y2huICpsY2huLCBzdHJ1Y3QgZXZ0Y2huICpyY2huKQorc3RhdGljIGFs
d2F5c19pbmxpbmUgdm9pZCBkb3VibGVfZXZ0Y2huX2xvY2soc3RydWN0IGV2
dGNobiAqbGNobiwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIHN0cnVjdCBldnRjaG4gKnJjaG4pCiB7CiAgICAgQVNT
RVJUKGxjaG4gIT0gcmNobik7CiAKZGlmZiAtLWdpdCBhL3hlbi9jb21tb24v
Z3JhbnRfdGFibGUuYyBiL3hlbi9jb21tb24vZ3JhbnRfdGFibGUuYwppbmRl
eCAzN2IxNzhhNjdiZjcuLjc3MDg5MzA4ODI5YiAxMDA2NDQKLS0tIGEveGVu
L2NvbW1vbi9ncmFudF90YWJsZS5jCisrKyBiL3hlbi9jb21tb24vZ3JhbnRf
dGFibGUuYwpAQCAtNDAzLDcgKzQwMyw3IEBAIHN0YXRpYyBpbmxpbmUgdm9p
ZCBhY3Rfc2V0X2dmbihzdHJ1Y3QgYWN0aXZlX2dyYW50X2VudHJ5ICphY3Qs
IGdmbl90IGdmbikKIAogc3RhdGljIERFRklORV9QRVJDUFVfUldMT0NLX0dM
T0JBTChncmFudF9yd2xvY2spOwogCi1zdGF0aWMgaW5saW5lIHZvaWQgZ3Jh
bnRfcmVhZF9sb2NrKHN0cnVjdCBncmFudF90YWJsZSAqZ3QpCitzdGF0aWMg
YWx3YXlzX2lubGluZSB2b2lkIGdyYW50X3JlYWRfbG9jayhzdHJ1Y3QgZ3Jh
bnRfdGFibGUgKmd0KQogewogICAgIHBlcmNwdV9yZWFkX2xvY2soZ3JhbnRf
cndsb2NrLCAmZ3QtPmxvY2spOwogfQpAQCAtNDEzLDcgKzQxMyw3IEBAIHN0
YXRpYyBpbmxpbmUgdm9pZCBncmFudF9yZWFkX3VubG9jayhzdHJ1Y3QgZ3Jh
bnRfdGFibGUgKmd0KQogICAgIHBlcmNwdV9yZWFkX3VubG9jayhncmFudF9y
d2xvY2ssICZndC0+bG9jayk7CiB9CiAKLXN0YXRpYyBpbmxpbmUgdm9pZCBn
cmFudF93cml0ZV9sb2NrKHN0cnVjdCBncmFudF90YWJsZSAqZ3QpCitzdGF0
aWMgYWx3YXlzX2lubGluZSB2b2lkIGdyYW50X3dyaXRlX2xvY2soc3RydWN0
IGdyYW50X3RhYmxlICpndCkKIHsKICAgICBwZXJjcHVfd3JpdGVfbG9jayhn
cmFudF9yd2xvY2ssICZndC0+bG9jayk7CiB9CkBAIC00NTAsNyArNDUwLDcg
QEAgbnJfYWN0aXZlX2dyYW50X2ZyYW1lcyhzdHJ1Y3QgZ3JhbnRfdGFibGUg
Kmd0KQogICAgIHJldHVybiBudW1fYWN0X2ZyYW1lc19mcm9tX3NoYV9mcmFt
ZXMobnJfZ3JhbnRfZnJhbWVzKGd0KSk7CiB9CiAKLXN0YXRpYyBpbmxpbmUg
c3RydWN0IGFjdGl2ZV9ncmFudF9lbnRyeSAqCitzdGF0aWMgYWx3YXlzX2lu
bGluZSBzdHJ1Y3QgYWN0aXZlX2dyYW50X2VudHJ5ICoKIGFjdGl2ZV9lbnRy
eV9hY3F1aXJlKHN0cnVjdCBncmFudF90YWJsZSAqdCwgZ3JhbnRfcmVmX3Qg
ZSkKIHsKICAgICBzdHJ1Y3QgYWN0aXZlX2dyYW50X2VudHJ5ICphY3Q7CmRp
ZmYgLS1naXQgYS94ZW4vY29tbW9uL3NjaGVkL2NvcmUuYyBiL3hlbi9jb21t
b24vc2NoZWQvY29yZS5jCmluZGV4IGM1ZGIzNzM5NzI3ZC4uM2U0OGRhMWNk
ZDRlIDEwMDY0NAotLS0gYS94ZW4vY29tbW9uL3NjaGVkL2NvcmUuYworKysg
Yi94ZW4vY29tbW9uL3NjaGVkL2NvcmUuYwpAQCAtMzQ4LDIzICszNDgsMjgg
QEAgdWludDY0X3QgZ2V0X2NwdV9pZGxlX3RpbWUodW5zaWduZWQgaW50IGNw
dSkKICAqIFRoaXMgYXZvaWRzIGRlYWQtIG9yIGxpdmUtbG9ja3Mgd2hlbiB0
aGlzIGNvZGUgaXMgcnVubmluZyBvbiBib3RoCiAgKiBjcHVzIGF0IHRoZSBz
YW1lIHRpbWUuCiAgKi8KLXN0YXRpYyB2b2lkIHNjaGVkX3NwaW5fbG9ja19k
b3VibGUoc3BpbmxvY2tfdCAqbG9jazEsIHNwaW5sb2NrX3QgKmxvY2syLAot
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1bnNpZ25lZCBs
b25nICpmbGFncykKK3N0YXRpYyBhbHdheXNfaW5saW5lIHZvaWQgc2NoZWRf
c3Bpbl9sb2NrX2RvdWJsZSgKKyAgICBzcGlubG9ja190ICpsb2NrMSwgc3Bp
bmxvY2tfdCAqbG9jazIsIHVuc2lnbmVkIGxvbmcgKmZsYWdzKQogeworICAg
IC8qCisgICAgICogSW4gb3JkZXIgdG8gYXZvaWQgZXh0cmEgb3ZlcmhlYWQs
IHVzZSB0aGUgbG9ja2luZyBwcmltaXRpdmVzIHdpdGhvdXQgdGhlCisgICAg
ICogc3BlY3VsYXRpb24gYmFycmllciwgYW5kIGludHJvZHVjZSBhIHNpbmds
ZSBiYXJyaWVyIGhlcmUuCisgICAgICovCiAgICAgaWYgKCBsb2NrMSA9PSBs
b2NrMiApCiAgICAgewotICAgICAgICBzcGluX2xvY2tfaXJxc2F2ZShsb2Nr
MSwgKmZsYWdzKTsKKyAgICAgICAgKmZsYWdzID0gX3NwaW5fbG9ja19pcnFz
YXZlKGxvY2sxKTsKICAgICB9CiAgICAgZWxzZSBpZiAoIGxvY2sxIDwgbG9j
azIgKQogICAgIHsKLSAgICAgICAgc3Bpbl9sb2NrX2lycXNhdmUobG9jazEs
ICpmbGFncyk7Ci0gICAgICAgIHNwaW5fbG9jayhsb2NrMik7CisgICAgICAg
ICpmbGFncyA9IF9zcGluX2xvY2tfaXJxc2F2ZShsb2NrMSk7CisgICAgICAg
IF9zcGluX2xvY2sobG9jazIpOwogICAgIH0KICAgICBlbHNlCiAgICAgewot
ICAgICAgICBzcGluX2xvY2tfaXJxc2F2ZShsb2NrMiwgKmZsYWdzKTsKLSAg
ICAgICAgc3Bpbl9sb2NrKGxvY2sxKTsKKyAgICAgICAgKmZsYWdzID0gX3Nw
aW5fbG9ja19pcnFzYXZlKGxvY2syKTsKKyAgICAgICAgX3NwaW5fbG9jayhs
b2NrMSk7CiAgICAgfQorICAgIGJsb2NrX2xvY2tfc3BlY3VsYXRpb24oKTsK
IH0KIAogc3RhdGljIHZvaWQgc2NoZWRfc3Bpbl91bmxvY2tfZG91YmxlKHNw
aW5sb2NrX3QgKmxvY2sxLCBzcGlubG9ja190ICpsb2NrMiwKZGlmZiAtLWdp
dCBhL3hlbi9jb21tb24vc2NoZWQvcHJpdmF0ZS5oIGIveGVuL2NvbW1vbi9z
Y2hlZC9wcml2YXRlLmgKaW5kZXggMjZhMTk2ZjQyODNiLi40NTlkMWRmYjEx
YTUgMTAwNjQ0Ci0tLSBhL3hlbi9jb21tb24vc2NoZWQvcHJpdmF0ZS5oCisr
KyBiL3hlbi9jb21tb24vc2NoZWQvcHJpdmF0ZS5oCkBAIC0yMDgsOCArMjA4
LDI0IEBAIERFQ0xBUkVfUEVSX0NQVShjcHVtYXNrX3QsIGNwdW1hc2tfc2Ny
YXRjaCk7CiAjZGVmaW5lIGNwdW1hc2tfc2NyYXRjaCAgICAgICAgKCZ0aGlz
X2NwdShjcHVtYXNrX3NjcmF0Y2gpKQogI2RlZmluZSBjcHVtYXNrX3NjcmF0
Y2hfY3B1KGMpICgmcGVyX2NwdShjcHVtYXNrX3NjcmF0Y2gsIGMpKQogCisv
KgorICogRGVhbCB3aXRoIF9zcGluX2xvY2tfaXJxc2F2ZSgpIHJldHVybmlu
ZyB0aGUgZmxhZ3MgdmFsdWUgaW5zdGVhZCBvZiBzdG9yaW5nCisgKiBpdCBp
biBhIHBhc3NlZCBwYXJhbWV0ZXIuCisgKi8KKyNkZWZpbmUgX3NjaGVkX3Nw
aW5sb2NrMChsb2NrLCBpcnEpIF9zcGluX2xvY2sjI2lycShsb2NrKQorI2Rl
ZmluZSBfc2NoZWRfc3BpbmxvY2sxKGxvY2ssIGlycSwgYXJnKSAoeyBcCisg
ICAgQlVJTERfQlVHX09OKHNpemVvZihhcmcpICE9IHNpemVvZih1bnNpZ25l
ZCBsb25nKSk7IFwKKyAgICAoYXJnKSA9IF9zcGluX2xvY2sjI2lycShsb2Nr
KTsgXAorfSkKKworI2RlZmluZSBfc2NoZWRfc3BpbmxvY2tfXyhucikgX3Nj
aGVkX3NwaW5sb2NrICMjIG5yCisjZGVmaW5lIF9zY2hlZF9zcGlubG9ja18o
bnIpICBfc2NoZWRfc3BpbmxvY2tfXyhucikKKyNkZWZpbmUgX3NjaGVkX3Nw
aW5sb2NrKGxvY2ssIGlycSwgYXJncy4uLikgXAorICAgIF9zY2hlZF9zcGlu
bG9ja18oY291bnRfYXJncyhhcmdzKSkobG9jaywgaXJxLCAjIyBhcmdzKQor
CiAjZGVmaW5lIHNjaGVkX2xvY2soa2luZCwgcGFyYW0sIGNwdSwgaXJxLCBh
cmcuLi4pIFwKLXN0YXRpYyBpbmxpbmUgc3BpbmxvY2tfdCAqa2luZCMjX3Nj
aGVkdWxlX2xvY2sjI2lycShwYXJhbSBFWFRSQV9UWVBFKGFyZykpIFwKK3N0
YXRpYyBhbHdheXNfaW5saW5lIHNwaW5sb2NrX3QgXAorKmtpbmQjI19zY2hl
ZHVsZV9sb2NrIyNpcnEocGFyYW0gRVhUUkFfVFlQRShhcmcpKSBcCiB7IFwK
ICAgICBmb3IgKCA7IDsgKSBcCiAgICAgeyBcCkBAIC0yMjEsMTAgKzIzNywx
NiBAQCBzdGF0aWMgaW5saW5lIHNwaW5sb2NrX3QgKmtpbmQjI19zY2hlZHVs
ZV9sb2NrIyNpcnEocGFyYW0gRVhUUkFfVFlQRShhcmcpKSBcCiAgICAgICAg
ICAqIFwKICAgICAgICAgICogSXQgbWF5IGFsc28gYmUgdGhlIGNhc2UgdGhh
dCB2LT5wcm9jZXNzb3IgbWF5IGNoYW5nZSBidXQgdGhlIFwKICAgICAgICAg
ICogbG9jayBtYXkgYmUgdGhlIHNhbWU7IHRoaXMgd2lsbCBzdWNjZWVkIGlu
IHRoYXQgY2FzZS4gXAorICAgICAgICAgKiBcCisgICAgICAgICAqIFVzZSB0
aGUgc3BlY3VsYXRpb24gdW5zYWZlIGxvY2tpbmcgaGVscGVyLCB0aGVyZSdz
IGEgc3BlY3VsYXRpb24gXAorICAgICAgICAgKiBiYXJyaWVyIGJlZm9yZSBy
ZXR1cm5pbmcgdG8gdGhlIGNhbGxlci4gXAogICAgICAgICAgKi8gXAotICAg
ICAgICBzcGluX2xvY2sjI2lycShsb2NrLCAjIyBhcmcpOyBcCisgICAgICAg
IF9zY2hlZF9zcGlubG9jayhsb2NrLCBpcnEsICMjIGFyZyk7IFwKICAgICAg
ICAgaWYgKCBsaWtlbHkobG9jayA9PSBnZXRfc2NoZWRfcmVzKGNwdSktPnNj
aGVkdWxlX2xvY2spICkgXAorICAgICAgICB7IFwKKyAgICAgICAgICAgIGJs
b2NrX2xvY2tfc3BlY3VsYXRpb24oKTsgXAogICAgICAgICAgICAgcmV0dXJu
IGxvY2s7IFwKKyAgICAgICAgfSBcCiAgICAgICAgIHNwaW5fdW5sb2NrIyNp
cnEobG9jaywgIyMgYXJnKTsgXAogICAgIH0gXAogfQpkaWZmIC0tZ2l0IGEv
eGVuL2NvbW1vbi90aW1lci5jIGIveGVuL2NvbW1vbi90aW1lci5jCmluZGV4
IDc4NTE3N2U3ZmE0Ny4uYTIxNzk4Yjc2ZjM4IDEwMDY0NAotLS0gYS94ZW4v
Y29tbW9uL3RpbWVyLmMKKysrIGIveGVuL2NvbW1vbi90aW1lci5jCkBAIC0y
MzksNyArMjM5LDcgQEAgc3RhdGljIGlubGluZSB2b2lkIGRlYWN0aXZhdGVf
dGltZXIoc3RydWN0IHRpbWVyICp0aW1lcikKICAgICBsaXN0X2FkZCgmdGlt
ZXItPmluYWN0aXZlLCAmcGVyX2NwdSh0aW1lcnMsIHRpbWVyLT5jcHUpLmlu
YWN0aXZlKTsKIH0KIAotc3RhdGljIGlubGluZSBib29sIHRpbWVyX2xvY2so
c3RydWN0IHRpbWVyICp0aW1lcikKK3N0YXRpYyBpbmxpbmUgYm9vbCB0aW1l
cl9sb2NrX3Vuc2FmZShzdHJ1Y3QgdGltZXIgKnRpbWVyKQogewogICAgIHVu
c2lnbmVkIGludCBjcHU7CiAKQEAgLTI1Myw3ICsyNTMsOCBAQCBzdGF0aWMg
aW5saW5lIGJvb2wgdGltZXJfbG9jayhzdHJ1Y3QgdGltZXIgKnRpbWVyKQog
ICAgICAgICAgICAgcmN1X3JlYWRfdW5sb2NrKCZ0aW1lcl9jcHVfcmVhZF9s
b2NrKTsKICAgICAgICAgICAgIHJldHVybiAwOwogICAgICAgICB9Ci0gICAg
ICAgIHNwaW5fbG9jaygmcGVyX2NwdSh0aW1lcnMsIGNwdSkubG9jayk7Cisg
ICAgICAgIC8qIFVzZSB0aGUgc3BlY3VsYXRpb24gdW5zYWZlIHZhcmlhbnQs
IHRoZSB3cmFwcGVyIGhhcyB0aGUgYmFycmllci4gKi8KKyAgICAgICAgX3Nw
aW5fbG9jaygmcGVyX2NwdSh0aW1lcnMsIGNwdSkubG9jayk7CiAgICAgICAg
IGlmICggbGlrZWx5KHRpbWVyLT5jcHUgPT0gY3B1KSApCiAgICAgICAgICAg
ICBicmVhazsKICAgICAgICAgc3Bpbl91bmxvY2soJnBlcl9jcHUodGltZXJz
LCBjcHUpLmxvY2spOwpAQCAtMjY2LDggKzI2Nyw5IEBAIHN0YXRpYyBpbmxp
bmUgYm9vbCB0aW1lcl9sb2NrKHN0cnVjdCB0aW1lciAqdGltZXIpCiAjZGVm
aW5lIHRpbWVyX2xvY2tfaXJxc2F2ZSh0LCBmbGFncykgKHsgICAgICAgICBc
CiAgICAgYm9vbCBfX3g7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBcCiAgICAgbG9jYWxfaXJxX3NhdmUoZmxhZ3MpOyAgICAgICAgICAg
ICAgICAgICAgICBcCi0gICAgaWYgKCAhKF9feCA9IHRpbWVyX2xvY2sodCkp
ICkgICAgICAgICAgICAgICBcCisgICAgaWYgKCAhKF9feCA9IHRpbWVyX2xv
Y2tfdW5zYWZlKHQpKSApICAgICAgICBcCiAgICAgICAgIGxvY2FsX2lycV9y
ZXN0b3JlKGZsYWdzKTsgICAgICAgICAgICAgICBcCisgICAgYmxvY2tfbG9j
a19zcGVjdWxhdGlvbigpOyAgICAgICAgICAgICAgICAgICBcCiAgICAgX194
OyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiB9
KQogCmRpZmYgLS1naXQgYS94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9wY2ku
YyBiL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL3BjaS5jCmluZGV4IDE5NDcw
MWM5MTM3ZC4uNmExZWRhNjc1ZGNjIDEwMDY0NAotLS0gYS94ZW4vZHJpdmVy
cy9wYXNzdGhyb3VnaC9wY2kuYworKysgYi94ZW4vZHJpdmVycy9wYXNzdGhy
b3VnaC9wY2kuYwpAQCAtNTIsOSArNTIsMTAgQEAgc3RydWN0IHBjaV9zZWcg
ewogCiBzdGF0aWMgc3BpbmxvY2tfdCBfcGNpZGV2c19sb2NrID0gU1BJTl9M
T0NLX1VOTE9DS0VEOwogCi12b2lkIHBjaWRldnNfbG9jayh2b2lkKQorLyog
RG8gbm90IHVzZSwgYXMgaXQgaGFzIG5vIHNwZWN1bGF0aW9uIGJhcnJpZXIs
IHVzZSBwY2lkZXZzX2xvY2soKSBpbnN0ZWFkLiAqLwordm9pZCBwY2lkZXZz
X2xvY2tfdW5zYWZlKHZvaWQpCiB7Ci0gICAgc3Bpbl9sb2NrX3JlY3Vyc2l2
ZSgmX3BjaWRldnNfbG9jayk7CisgICAgX3NwaW5fbG9ja19yZWN1cnNpdmUo
Jl9wY2lkZXZzX2xvY2spOwogfQogCiB2b2lkIHBjaWRldnNfdW5sb2NrKHZv
aWQpCmRpZmYgLS1naXQgYS94ZW4vaW5jbHVkZS94ZW4vZXZlbnQuaCBiL3hl
bi9pbmNsdWRlL3hlbi9ldmVudC5oCmluZGV4IDhlNTA5ZTA3ODQ3NS4uZjE0
NzJlYTFlYmU1IDEwMDY0NAotLS0gYS94ZW4vaW5jbHVkZS94ZW4vZXZlbnQu
aAorKysgYi94ZW4vaW5jbHVkZS94ZW4vZXZlbnQuaApAQCAtMTE0LDEyICsx
MTQsMTIgQEAgdm9pZCBub3RpZnlfdmlhX3hlbl9ldmVudF9jaGFubmVsKHN0
cnVjdCBkb21haW4gKmxkLCBpbnQgbHBvcnQpOwogI2RlZmluZSBidWNrZXRf
ZnJvbV9wb3J0KGQsIHApIFwKICAgICAoKGdyb3VwX2Zyb21fcG9ydChkLCBw
KSlbKChwKSAlIEVWVENITlNfUEVSX0dST1VQKSAvIEVWVENITlNfUEVSX0JV
Q0tFVF0pCiAKLXN0YXRpYyBpbmxpbmUgdm9pZCBldnRjaG5fcmVhZF9sb2Nr
KHN0cnVjdCBldnRjaG4gKmV2dGNobikKK3N0YXRpYyBhbHdheXNfaW5saW5l
IHZvaWQgZXZ0Y2huX3JlYWRfbG9jayhzdHJ1Y3QgZXZ0Y2huICpldnRjaG4p
CiB7CiAgICAgcmVhZF9sb2NrKCZldnRjaG4tPmxvY2spOwogfQogCi1zdGF0
aWMgaW5saW5lIGJvb2wgZXZ0Y2huX3JlYWRfdHJ5bG9jayhzdHJ1Y3QgZXZ0
Y2huICpldnRjaG4pCitzdGF0aWMgYWx3YXlzX2lubGluZSBib29sIGV2dGNo
bl9yZWFkX3RyeWxvY2soc3RydWN0IGV2dGNobiAqZXZ0Y2huKQogewogICAg
IHJldHVybiByZWFkX3RyeWxvY2soJmV2dGNobi0+bG9jayk7CiB9CmRpZmYg
LS1naXQgYS94ZW4vaW5jbHVkZS94ZW4vcGNpLmggYi94ZW4vaW5jbHVkZS94
ZW4vcGNpLmgKaW5kZXggMWRmMTg2M2IxMzMxLi42M2U0OWYwMTE3ZTkgMTAw
NjQ0Ci0tLSBhL3hlbi9pbmNsdWRlL3hlbi9wY2kuaAorKysgYi94ZW4vaW5j
bHVkZS94ZW4vcGNpLmgKQEAgLTE2Niw4ICsxNjYsMTIgQEAgc3RydWN0IHBj
aV9kZXYgewogICogZGV2aWNlcywgaXQgYWxzbyBzeW5jIHRoZSBhY2Nlc3Mg
dG8gdGhlIG1zaSBjYXBhYmlsaXR5IHRoYXQgaXMgbm90CiAgKiBpbnRlcnJ1
cHQgaGFuZGxpbmcgcmVsYXRlZCAodGhlIG1hc2sgYml0IHJlZ2lzdGVyKS4K
ICAqLwotCi12b2lkIHBjaWRldnNfbG9jayh2b2lkKTsKK3ZvaWQgcGNpZGV2
c19sb2NrX3Vuc2FmZSh2b2lkKTsKK3N0YXRpYyBhbHdheXNfaW5saW5lIHZv
aWQgcGNpZGV2c19sb2NrKHZvaWQpCit7CisgICAgcGNpZGV2c19sb2NrX3Vu
c2FmZSgpOworICAgIGJsb2NrX2xvY2tfc3BlY3VsYXRpb24oKTsKK30KIHZv
aWQgcGNpZGV2c191bmxvY2sodm9pZCk7CiBib29sIF9fbXVzdF9jaGVjayBw
Y2lkZXZzX2xvY2tlZCh2b2lkKTsKIAo=

--=separator
Content-Type: application/octet-stream; name="xsa453/xsa453-6.patch"
Content-Disposition: attachment; filename="xsa453/xsa453-6.patch"
Content-Transfer-Encoding: base64

RnJvbTogPT9VVEYtOD9xP1JvZ2VyPTIwUGF1PTIwTW9ubj1DMz1BOT89IDxy
b2dlci5wYXVAY2l0cml4LmNvbT4KU3ViamVjdDogeDg2L21tOiBhZGQgc3Bl
Y3VsYXRpb24gYmFycmllcnMgdG8gb3BlbiBjb2RlZCBsb2NrcwoKQWRkIGEg
c3BlY3VsYXRpb24gYmFycmllciB0byB0aGUgY2xlYXJseSBpZGVudGlmaWVk
IG9wZW4tY29kZWQgbG9jayB0YWtpbmcKZnVuY3Rpb25zLgoKTm90ZSB0aGF0
IHRoZSBtZW1vcnkgc2hhcmluZyBwYWdlX2xvY2soKSByZXBsYWNlbWVudCAo
X3BhZ2VfbG9jaygpKSBpcyBsZWZ0CmFzLWlzLCBhcyB0aGUgY29kZSBpcyBl
eHBlcmltZW50YWwgYW5kIG5vdCBzZWN1cml0eSBzdXBwb3J0ZWQuCgpUaGlz
IGlzIHBhcnQgb2YgWFNBLTQ1MyAvIENWRS0yMDI0LTIxOTMKClNpZ25lZC1v
ZmYtYnk6IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXguY29t
PgpSZXZpZXdlZC1ieTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29t
PgoKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9tbS5o
IGIveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL21tLmgKaW5kZXggN2QyNmQ5
Y2QyZmMwLi42NWQyMDlkNWZmZjQgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4
Ni9pbmNsdWRlL2FzbS9tbS5oCisrKyBiL3hlbi9hcmNoL3g4Ni9pbmNsdWRl
L2FzbS9tbS5oCkBAIC0zOTksNyArMzk5LDkgQEAgY29uc3Qgc3RydWN0IHBs
YXRmb3JtX2JhZF9wYWdlICpnZXRfcGxhdGZvcm1fYmFkcGFnZXModW5zaWdu
ZWQgaW50ICphcnJheV9zaXplKTsKICAqIFRoZSB1c2Ugb2YgUEdUX2xvY2tl
ZCBpbiBtZW1fc2hhcmluZyBkb2VzIG5vdCBjb2xsaWRlLCBzaW5jZSBtZW1f
c2hhcmluZyBpcwogICogb25seSBzdXBwb3J0ZWQgZm9yIGh2bSBndWVzdHMs
IHdoaWNoIGRvIG5vdCBoYXZlIFBWIFBURXMgdXBkYXRlZC4KICAqLwotaW50
IHBhZ2VfbG9jayhzdHJ1Y3QgcGFnZV9pbmZvICpwYWdlKTsKK2ludCBwYWdl
X2xvY2tfdW5zYWZlKHN0cnVjdCBwYWdlX2luZm8gKnBhZ2UpOworI2RlZmlu
ZSBwYWdlX2xvY2socGcpICAgbG9ja19ldmFsdWF0ZV9ub3NwZWMocGFnZV9s
b2NrX3Vuc2FmZShwZykpCisKIHZvaWQgcGFnZV91bmxvY2soc3RydWN0IHBh
Z2VfaW5mbyAqcGFnZSk7CiAKIHZvaWQgcHV0X3BhZ2VfdHlwZShzdHJ1Y3Qg
cGFnZV9pbmZvICpwYWdlKTsKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9t
bS5jIGIveGVuL2FyY2gveDg2L21tLmMKaW5kZXggMGM2NjU4Mjk4ZGUyLi4y
YmE0YzI2NDAxNDkgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9tbS5jCisr
KyBiL3hlbi9hcmNoL3g4Ni9tbS5jCkBAIC0yMDM0LDcgKzIwMzQsNyBAQCBz
dGF0aWMgaW5saW5lIGJvb2wgY3VycmVudF9sb2NrZWRfcGFnZV9uZV9jaGVj
ayhzdHJ1Y3QgcGFnZV9pbmZvICpwYWdlKSB7CiAjZGVmaW5lIGN1cnJlbnRf
bG9ja2VkX3BhZ2VfbmVfY2hlY2soeCkgdHJ1ZQogI2VuZGlmCiAKLWludCBw
YWdlX2xvY2soc3RydWN0IHBhZ2VfaW5mbyAqcGFnZSkKK2ludCBwYWdlX2xv
Y2tfdW5zYWZlKHN0cnVjdCBwYWdlX2luZm8gKnBhZ2UpCiB7CiAgICAgdW5z
aWduZWQgbG9uZyB4LCBueDsKIApAQCAtMjA5NSw3ICsyMDk1LDcgQEAgdm9p
ZCBwYWdlX3VubG9jayhzdHJ1Y3QgcGFnZV9pbmZvICpwYWdlKQogICogbDN0
X2xvY2soKSwgc28gdG8gYXZvaWQgZGVhZGxvY2sgd2UgbXVzdCBhdm9pZCBn
cmFiYmluZyB0aGVtIGluCiAgKiByZXZlcnNlIG9yZGVyLgogICovCi1zdGF0
aWMgdm9pZCBsM3RfbG9jayhzdHJ1Y3QgcGFnZV9pbmZvICpwYWdlKQorc3Rh
dGljIGFsd2F5c19pbmxpbmUgdm9pZCBsM3RfbG9jayhzdHJ1Y3QgcGFnZV9p
bmZvICpwYWdlKQogewogICAgIHVuc2lnbmVkIGxvbmcgeCwgbng7CiAKQEAg
LTIxMDQsNiArMjEwNCw4IEBAIHN0YXRpYyB2b2lkIGwzdF9sb2NrKHN0cnVj
dCBwYWdlX2luZm8gKnBhZ2UpCiAgICAgICAgICAgICBjcHVfcmVsYXgoKTsK
ICAgICAgICAgbnggPSB4IHwgUEdUX2xvY2tlZDsKICAgICB9IHdoaWxlICgg
Y21weGNoZygmcGFnZS0+dS5pbnVzZS50eXBlX2luZm8sIHgsIG54KSAhPSB4
ICk7CisKKyAgICBibG9ja19sb2NrX3NwZWN1bGF0aW9uKCk7CiB9CiAKIHN0
YXRpYyB2b2lkIGwzdF91bmxvY2soc3RydWN0IHBhZ2VfaW5mbyAqcGFnZSkK

--=separator
Content-Type: application/octet-stream; name="xsa453/xsa453-7.patch"
Content-Disposition: attachment; filename="xsa453/xsa453-7.patch"
Content-Transfer-Encoding: base64

RnJvbTogPT9VVEYtOD9xP1JvZ2VyPTIwUGF1PTIwTW9ubj1DMz1BOT89IDxy
b2dlci5wYXVAY2l0cml4LmNvbT4KU3ViamVjdDogeDg2OiBwcm90ZWN0IGNv
bmRpdGlvbmFsIGxvY2sgdGFraW5nIGZyb20gc3BlY3VsYXRpdmUgZXhlY3V0
aW9uCgpDb25kaXRpb25hbGx5IHRha2VuIGxvY2tzIHRoYXQgdXNlIHRoZSBw
YXR0ZXJuOgoKaWYgKCBsb2NrICkKICAgIHNwaW5fbG9jayguLi4pOwoKTmVl
ZCBhbiBlbHNlIGJyYW5jaCBpbiBvcmRlciB0byBpc3N1ZSBhbiBzcGVjdWxh
dGlvbiBiYXJyaWVyIGluIHRoZSBlbHNlIGNhc2UsCmp1c3QgbGlrZSBpdCdz
IGRvbmUgaW4gY2FzZSB0aGUgbG9jayBuZWVkcyB0byBiZSBhY3F1aXJlZC4K
CmV2YWxfbm9zcGVjKCkgY291bGQgYmUgdXNlZCBvbiB0aGUgY29uZGl0aW9u
IGl0c2VsZiwgYnV0IHRoYXQgd291bGQgcmVzdWx0IGluIGEKZG91YmxlIGJh
cnJpZXIgb24gdGhlIGJyYW5jaCB3aGVyZSB0aGUgbG9jayBpcyB0YWtlbi4K
CkludHJvZHVjZSBhIG5ldyBwYWlyIG9mIGhlbHBlcnMsIHtnZm4sc3Bpbn1f
bG9ja19pZigpIHRoYXQgY2FuIGJlIHVzZWQgdG8KY29uZGl0aW9uYWxseSB0
YWtlIGEgbG9jayBpbiBhIHNwZWN1bGF0aW9uIHNhZmUgd2F5LgoKVGhpcyBp
cyBwYXJ0IG9mIFhTQS00NTMgLyBDVkUtMjAyNC0yMTkzCgpTaWduZWQtb2Zm
LWJ5OiBSb2dlciBQYXUgTW9ubsOpIDxyb2dlci5wYXVAY2l0cml4LmNvbT4K
UmV2aWV3ZWQtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4K
CmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYvbW0uYyBiL3hlbi9hcmNoL3g4
Ni9tbS5jCmluZGV4IDJiYTRjMjY0MDE0OS4uNjJmNWI4MTFiYmU4IDEwMDY0
NAotLS0gYS94ZW4vYXJjaC94ODYvbW0uYworKysgYi94ZW4vYXJjaC94ODYv
bW0uYwpAQCAtNTAxOCw4ICs1MDE4LDcgQEAgc3RhdGljIGwzX3BnZW50cnlf
dCAqdmlydF90b194ZW5fbDNlKHVuc2lnbmVkIGxvbmcgdikKICAgICAgICAg
aWYgKCAhbDN0ICkKICAgICAgICAgICAgIHJldHVybiBOVUxMOwogICAgICAg
ICBVTk1BUF9ET01BSU5fUEFHRShsM3QpOwotICAgICAgICBpZiAoIGxvY2tp
bmcgKQotICAgICAgICAgICAgc3Bpbl9sb2NrKCZtYXBfcGdkaXJfbG9jayk7
CisgICAgICAgIHNwaW5fbG9ja19pZihsb2NraW5nLCAmbWFwX3BnZGlyX2xv
Y2spOwogICAgICAgICBpZiAoICEobDRlX2dldF9mbGFncygqcGw0ZSkgJiBf
UEFHRV9QUkVTRU5UKSApCiAgICAgICAgIHsKICAgICAgICAgICAgIGw0X3Bn
ZW50cnlfdCBsNGUgPSBsNGVfZnJvbV9tZm4obDNtZm4sIF9fUEFHRV9IWVBF
UlZJU09SKTsKQEAgLTUwNTYsOCArNTA1NSw3IEBAIHN0YXRpYyBsMl9wZ2Vu
dHJ5X3QgKnZpcnRfdG9feGVuX2wyZSh1bnNpZ25lZCBsb25nIHYpCiAgICAg
ICAgICAgICByZXR1cm4gTlVMTDsKICAgICAgICAgfQogICAgICAgICBVTk1B
UF9ET01BSU5fUEFHRShsMnQpOwotICAgICAgICBpZiAoIGxvY2tpbmcgKQot
ICAgICAgICAgICAgc3Bpbl9sb2NrKCZtYXBfcGdkaXJfbG9jayk7CisgICAg
ICAgIHNwaW5fbG9ja19pZihsb2NraW5nLCAmbWFwX3BnZGlyX2xvY2spOwog
ICAgICAgICBpZiAoICEobDNlX2dldF9mbGFncygqcGwzZSkgJiBfUEFHRV9Q
UkVTRU5UKSApCiAgICAgICAgIHsKICAgICAgICAgICAgIGwzZV93cml0ZShw
bDNlLCBsM2VfZnJvbV9tZm4obDJtZm4sIF9fUEFHRV9IWVBFUlZJU09SKSk7
CkBAIC01MDk1LDggKzUwOTMsNyBAQCBsMV9wZ2VudHJ5X3QgKnZpcnRfdG9f
eGVuX2wxZSh1bnNpZ25lZCBsb25nIHYpCiAgICAgICAgICAgICByZXR1cm4g
TlVMTDsKICAgICAgICAgfQogICAgICAgICBVTk1BUF9ET01BSU5fUEFHRShs
MXQpOwotICAgICAgICBpZiAoIGxvY2tpbmcgKQotICAgICAgICAgICAgc3Bp
bl9sb2NrKCZtYXBfcGdkaXJfbG9jayk7CisgICAgICAgIHNwaW5fbG9ja19p
Zihsb2NraW5nLCAmbWFwX3BnZGlyX2xvY2spOwogICAgICAgICBpZiAoICEo
bDJlX2dldF9mbGFncygqcGwyZSkgJiBfUEFHRV9QUkVTRU5UKSApCiAgICAg
ICAgIHsKICAgICAgICAgICAgIGwyZV93cml0ZShwbDJlLCBsMmVfZnJvbV9t
Zm4obDFtZm4sIF9fUEFHRV9IWVBFUlZJU09SKSk7CkBAIC01MTI3LDYgKzUx
MjQsOCBAQCBsMV9wZ2VudHJ5X3QgKnZpcnRfdG9feGVuX2wxZSh1bnNpZ25l
ZCBsb25nIHYpCiAgICAgZG8geyAgICAgICAgICAgICAgICAgICAgICBcCiAg
ICAgICAgIGlmICggbG9ja2luZyApICAgICAgICBcCiAgICAgICAgICAgICBs
M3RfbG9jayhwYWdlKTsgICBcCisgICAgICAgIGVsc2UgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgXAorICAgICAgICAgICAgYmxvY2tfbG9ja19zcGVj
dWxhdGlvbigpOyAgIFwKICAgICB9IHdoaWxlICggZmFsc2UgKQogCiAjZGVm
aW5lIEwzVF9VTkxPQ0socGFnZSkgICAgICAgICAgICAgICAgICAgICAgICAg
ICBcCkBAIC01MzQyLDggKzUzNDEsNyBAQCBpbnQgbWFwX3BhZ2VzX3RvX3hl
bigKICAgICAgICAgICAgIGlmICggbDNlX2dldF9mbGFncyhvbDNlKSAmIF9Q
QUdFX0dMT0JBTCApCiAgICAgICAgICAgICAgICAgZmx1c2hfZmxhZ3MgfD0g
RkxVU0hfVExCX0dMT0JBTDsKIAotICAgICAgICAgICAgaWYgKCBsb2NraW5n
ICkKLSAgICAgICAgICAgICAgICBzcGluX2xvY2soJm1hcF9wZ2Rpcl9sb2Nr
KTsKKyAgICAgICAgICAgIHNwaW5fbG9ja19pZihsb2NraW5nLCAmbWFwX3Bn
ZGlyX2xvY2spOwogICAgICAgICAgICAgaWYgKCAobDNlX2dldF9mbGFncygq
cGwzZSkgJiBfUEFHRV9QUkVTRU5UKSAmJgogICAgICAgICAgICAgICAgICAo
bDNlX2dldF9mbGFncygqcGwzZSkgJiBfUEFHRV9QU0UpICkKICAgICAgICAg
ICAgIHsKQEAgLTU0NDcsOCArNTQ0NSw3IEBAIGludCBtYXBfcGFnZXNfdG9f
eGVuKAogICAgICAgICAgICAgICAgIGlmICggbDJlX2dldF9mbGFncygqcGwy
ZSkgJiBfUEFHRV9HTE9CQUwgKQogICAgICAgICAgICAgICAgICAgICBmbHVz
aF9mbGFncyB8PSBGTFVTSF9UTEJfR0xPQkFMOwogCi0gICAgICAgICAgICAg
ICAgaWYgKCBsb2NraW5nICkKLSAgICAgICAgICAgICAgICAgICAgc3Bpbl9s
b2NrKCZtYXBfcGdkaXJfbG9jayk7CisgICAgICAgICAgICAgICAgc3Bpbl9s
b2NrX2lmKGxvY2tpbmcsICZtYXBfcGdkaXJfbG9jayk7CiAgICAgICAgICAg
ICAgICAgaWYgKCAobDJlX2dldF9mbGFncygqcGwyZSkgJiBfUEFHRV9QUkVT
RU5UKSAmJgogICAgICAgICAgICAgICAgICAgICAgKGwyZV9nZXRfZmxhZ3Mo
KnBsMmUpICYgX1BBR0VfUFNFKSApCiAgICAgICAgICAgICAgICAgewpAQCAt
NTQ4OSw4ICs1NDg2LDcgQEAgaW50IG1hcF9wYWdlc190b194ZW4oCiAgICAg
ICAgICAgICAgICAgdW5zaWduZWQgbG9uZyBiYXNlX21mbjsKICAgICAgICAg
ICAgICAgICBjb25zdCBsMV9wZ2VudHJ5X3QgKmwxdDsKIAotICAgICAgICAg
ICAgICAgIGlmICggbG9ja2luZyApCi0gICAgICAgICAgICAgICAgICAgIHNw
aW5fbG9jaygmbWFwX3BnZGlyX2xvY2spOworICAgICAgICAgICAgICAgIHNw
aW5fbG9ja19pZihsb2NraW5nLCAmbWFwX3BnZGlyX2xvY2spOwogCiAgICAg
ICAgICAgICAgICAgb2wyZSA9ICpwbDJlOwogICAgICAgICAgICAgICAgIC8q
CkBAIC01NTQ0LDggKzU1NDAsNyBAQCBpbnQgbWFwX3BhZ2VzX3RvX3hlbigK
ICAgICAgICAgICAgIHVuc2lnbmVkIGxvbmcgYmFzZV9tZm47CiAgICAgICAg
ICAgICBjb25zdCBsMl9wZ2VudHJ5X3QgKmwydDsKIAotICAgICAgICAgICAg
aWYgKCBsb2NraW5nICkKLSAgICAgICAgICAgICAgICBzcGluX2xvY2soJm1h
cF9wZ2Rpcl9sb2NrKTsKKyAgICAgICAgICAgIHNwaW5fbG9ja19pZihsb2Nr
aW5nLCAmbWFwX3BnZGlyX2xvY2spOwogCiAgICAgICAgICAgICBvbDNlID0g
KnBsM2U7CiAgICAgICAgICAgICAvKgpAQCAtNTY4OSw4ICs1Njg0LDcgQEAg
aW50IG1vZGlmeV94ZW5fbWFwcGluZ3ModW5zaWduZWQgbG9uZyBzLCB1bnNp
Z25lZCBsb25nIGUsIHVuc2lnbmVkIGludCBuZikKICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIGwzZV9nZXRfZmxhZ3MoKnBsM2Up
KSk7CiAgICAgICAgICAgICBVTk1BUF9ET01BSU5fUEFHRShsMnQpOwogCi0g
ICAgICAgICAgICBpZiAoIGxvY2tpbmcgKQotICAgICAgICAgICAgICAgIHNw
aW5fbG9jaygmbWFwX3BnZGlyX2xvY2spOworICAgICAgICAgICAgc3Bpbl9s
b2NrX2lmKGxvY2tpbmcsICZtYXBfcGdkaXJfbG9jayk7CiAgICAgICAgICAg
ICBpZiAoIChsM2VfZ2V0X2ZsYWdzKCpwbDNlKSAmIF9QQUdFX1BSRVNFTlQp
ICYmCiAgICAgICAgICAgICAgICAgIChsM2VfZ2V0X2ZsYWdzKCpwbDNlKSAm
IF9QQUdFX1BTRSkgKQogICAgICAgICAgICAgewpAQCAtNTc0OSw4ICs1NzQz
LDcgQEAgaW50IG1vZGlmeV94ZW5fbWFwcGluZ3ModW5zaWduZWQgbG9uZyBz
LCB1bnNpZ25lZCBsb25nIGUsIHVuc2lnbmVkIGludCBuZikKICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBsMmVfZ2V0X2Zs
YWdzKCpwbDJlKSAmIH5fUEFHRV9QU0UpKTsKICAgICAgICAgICAgICAgICBV
Tk1BUF9ET01BSU5fUEFHRShsMXQpOwogCi0gICAgICAgICAgICAgICAgaWYg
KCBsb2NraW5nICkKLSAgICAgICAgICAgICAgICAgICAgc3Bpbl9sb2NrKCZt
YXBfcGdkaXJfbG9jayk7CisgICAgICAgICAgICAgICAgc3Bpbl9sb2NrX2lm
KGxvY2tpbmcsICZtYXBfcGdkaXJfbG9jayk7CiAgICAgICAgICAgICAgICAg
aWYgKCAobDJlX2dldF9mbGFncygqcGwyZSkgJiBfUEFHRV9QUkVTRU5UKSAm
JgogICAgICAgICAgICAgICAgICAgICAgKGwyZV9nZXRfZmxhZ3MoKnBsMmUp
ICYgX1BBR0VfUFNFKSApCiAgICAgICAgICAgICAgICAgewpAQCAtNTc5NCw4
ICs1Nzg3LDcgQEAgaW50IG1vZGlmeV94ZW5fbWFwcGluZ3ModW5zaWduZWQg
bG9uZyBzLCB1bnNpZ25lZCBsb25nIGUsIHVuc2lnbmVkIGludCBuZikKICAg
ICAgICAgICAgICAqLwogICAgICAgICAgICAgaWYgKCAobmYgJiBfUEFHRV9Q
UkVTRU5UKSB8fCAoKHYgIT0gZSkgJiYgKGwxX3RhYmxlX29mZnNldCh2KSAh
PSAwKSkgKQogICAgICAgICAgICAgICAgIGNvbnRpbnVlOwotICAgICAgICAg
ICAgaWYgKCBsb2NraW5nICkKLSAgICAgICAgICAgICAgICBzcGluX2xvY2so
Jm1hcF9wZ2Rpcl9sb2NrKTsKKyAgICAgICAgICAgIHNwaW5fbG9ja19pZihs
b2NraW5nLCAmbWFwX3BnZGlyX2xvY2spOwogCiAgICAgICAgICAgICAvKgog
ICAgICAgICAgICAgICogTDJFIG1heSBiZSBhbHJlYWR5IGNsZWFyZWQsIG9y
IHNldCB0byBhIHN1cGVycGFnZSwgYnkKQEAgLTU4NDIsOCArNTgzNCw3IEBA
IGludCBtb2RpZnlfeGVuX21hcHBpbmdzKHVuc2lnbmVkIGxvbmcgcywgdW5z
aWduZWQgbG9uZyBlLCB1bnNpZ25lZCBpbnQgbmYpCiAgICAgICAgIGlmICgg
KG5mICYgX1BBR0VfUFJFU0VOVCkgfHwKICAgICAgICAgICAgICAoKHYgIT0g
ZSkgJiYgKGwyX3RhYmxlX29mZnNldCh2KSArIGwxX3RhYmxlX29mZnNldCh2
KSAhPSAwKSkgKQogICAgICAgICAgICAgY29udGludWU7Ci0gICAgICAgIGlm
ICggbG9ja2luZyApCi0gICAgICAgICAgICBzcGluX2xvY2soJm1hcF9wZ2Rp
cl9sb2NrKTsKKyAgICAgICAgc3Bpbl9sb2NrX2lmKGxvY2tpbmcsICZtYXBf
cGdkaXJfbG9jayk7CiAKICAgICAgICAgLyoKICAgICAgICAgICogTDNFIG1h
eSBiZSBhbHJlYWR5IGNsZWFyZWQsIG9yIHNldCB0byBhIHN1cGVycGFnZSwg
YnkKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9tbS9tbS1sb2Nrcy5oIGIv
eGVuL2FyY2gveDg2L21tL21tLWxvY2tzLmgKaW5kZXggMjczZmZmODZiYWE0
Li4yZWFlNzNhYzY4ZDEgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9tbS9t
bS1sb2Nrcy5oCisrKyBiL3hlbi9hcmNoL3g4Ni9tbS9tbS1sb2Nrcy5oCkBA
IC0zMzUsNiArMzM1LDE1IEBAIHN0YXRpYyBpbmxpbmUgdm9pZCBwMm1fdW5s
b2NrKHN0cnVjdCBwMm1fZG9tYWluICpwKQogI2RlZmluZSBwMm1fbG9ja2Vk
X2J5X21lKHApICAgbW1fd3JpdGVfbG9ja2VkX2J5X21lKCYocCktPmxvY2sp
CiAjZGVmaW5lIGdmbl9sb2NrZWRfYnlfbWUocCxnKSBwMm1fbG9ja2VkX2J5
X21lKHApCiAKK3N0YXRpYyBhbHdheXNfaW5saW5lIHZvaWQgZ2ZuX2xvY2tf
aWYoYm9vbCBjb25kaXRpb24sIHN0cnVjdCBwMm1fZG9tYWluICpwMm0sCisg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGdmbl90IGdm
biwgdW5zaWduZWQgaW50IG9yZGVyKQoreworICAgIGlmICggY29uZGl0aW9u
ICkKKyAgICAgICAgZ2ZuX2xvY2socDJtLCBnZm4sIG9yZGVyKTsKKyAgICBl
bHNlCisgICAgICAgIGJsb2NrX2xvY2tfc3BlY3VsYXRpb24oKTsKK30KKwog
LyogUG9EIGxvY2sgKHBlci1wMm0tdGFibGUpCiAgKgogICogUHJvdGVjdHMg
cHJpdmF0ZSBQb0QgZGF0YSBzdHJ1Y3RzOiBlbnRyeSBhbmQgY2FjaGUKZGlm
ZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9tbS9wMm0uYyBiL3hlbi9hcmNoL3g4
Ni9tbS9wMm0uYwppbmRleCA0ZGQ0MTE5M2Y1MzguLmNhMjRjZDRhNjdkYSAx
MDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L21tL3AybS5jCisrKyBiL3hlbi9h
cmNoL3g4Ni9tbS9wMm0uYwpAQCAtMjgxLDkgKzI4MSw4IEBAIG1mbl90IHAy
bV9nZXRfZ2ZuX3R5cGVfYWNjZXNzKHN0cnVjdCBwMm1fZG9tYWluICpwMm0s
IGdmbl90IGdmbiwKICAgICBpZiAoIHEgJiBQMk1fVU5TSEFSRSApCiAgICAg
ICAgIHEgfD0gUDJNX0FMTE9DOwogCi0gICAgaWYgKCBsb2NrZWQgKQotICAg
ICAgICAvKiBHcmFiIHRoZSBsb2NrIGhlcmUsIGRvbid0IHJlbGVhc2UgdW50
aWwgcHV0X2dmbiAqLwotICAgICAgICBnZm5fbG9jayhwMm0sIGdmbiwgMCk7
CisgICAgLyogR3JhYiB0aGUgbG9jayBoZXJlLCBkb24ndCByZWxlYXNlIHVu
dGlsIHB1dF9nZm4gKi8KKyAgICBnZm5fbG9ja19pZihsb2NrZWQsIHAybSwg
Z2ZuLCAwKTsKIAogICAgIG1mbiA9IHAybS0+Z2V0X2VudHJ5KHAybSwgZ2Zu
LCB0LCBhLCBxLCBwYWdlX29yZGVyLCBOVUxMKTsKIApkaWZmIC0tZ2l0IGEv
eGVuL2luY2x1ZGUveGVuL3NwaW5sb2NrLmggYi94ZW4vaW5jbHVkZS94ZW4v
c3BpbmxvY2suaAppbmRleCA4NDMwYTg4OGE4Y2EuLmUzNTFmYzk5OTVmNiAx
MDA2NDQKLS0tIGEveGVuL2luY2x1ZGUveGVuL3NwaW5sb2NrLmgKKysrIGIv
eGVuL2luY2x1ZGUveGVuL3NwaW5sb2NrLmgKQEAgLTIyOSw2ICsyMjksMTQg
QEAgc3RhdGljIGFsd2F5c19pbmxpbmUgdm9pZCBzcGluX2xvY2tfaXJxKHNw
aW5sb2NrX3QgKmwpCiAgICAgICAgIGJsb2NrX2xvY2tfc3BlY3VsYXRpb24o
KTsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAogICAgIH0pCiAK
Ky8qIENvbmRpdGlvbmFsbHkgdGFrZSBhIHNwaW5sb2NrIGluIGEgc3BlY3Vs
YXRpb24gc2FmZSB3YXkuICovCitzdGF0aWMgYWx3YXlzX2lubGluZSB2b2lk
IHNwaW5fbG9ja19pZihib29sIGNvbmRpdGlvbiwgc3BpbmxvY2tfdCAqbCkK
K3sKKyAgICBpZiAoIGNvbmRpdGlvbiApCisgICAgICAgIF9zcGluX2xvY2so
bCk7CisgICAgYmxvY2tfbG9ja19zcGVjdWxhdGlvbigpOworfQorCiAjZGVm
aW5lIHNwaW5fdW5sb2NrKGwpICAgICAgICAgICAgICAgIF9zcGluX3VubG9j
ayhsKQogI2RlZmluZSBzcGluX3VubG9ja19pcnEobCkgICAgICAgICAgICBf
c3Bpbl91bmxvY2tfaXJxKGwpCiAjZGVmaW5lIHNwaW5fdW5sb2NrX2lycXJl
c3RvcmUobCwgZikgIF9zcGluX3VubG9ja19pcnFyZXN0b3JlKGwsIGYpCg==

--=separator--


From xen-devel-bounces@lists.xenproject.org Tue Mar 12 17:13:29 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Mar 2024 17:13:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692003.1078723 (Exim 4.92)
	(envelope-from )
	id 1rk5gq-0007tu-NB; Tue, 12 Mar 2024 17:13:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692003.1078723; Tue, 12 Mar 2024 17:13:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rk5gq-0007tn-JQ; Tue, 12 Mar 2024 17:13:24 +0000
Received: by outflank-mailman (input) for mailman id 692003;
 Tue, 12 Mar 2024 17:13:23 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rk5gp-0007tM-0A
 for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 17:13:23 +0000
Received: from 10.mo561.mail-out.ovh.net (10.mo561.mail-out.ovh.net
 [87.98.165.232]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d35dd5dc-e093-11ee-a1ee-f123f15fe8a2;
 Tue, 12 Mar 2024 18:13:20 +0100 (CET)
Received: from director2.ghost.mail-out.ovh.net (unknown [10.109.139.154])
 by mo561.mail-out.ovh.net (Postfix) with ESMTP id 4TvKwc2Qk6z1Bj5
 for ; Tue, 12 Mar 2024 17:13:20 +0000 (UTC)
Received: from ghost-submission-6684bf9d7b-4hrmg (unknown [10.110.96.204])
 by director2.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 8D2ED1FDF1;
 Tue, 12 Mar 2024 17:13:19 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.99])
 by ghost-submission-6684bf9d7b-4hrmg with ESMTPSA
 id V/m4HS+N8GXxGQIA/is83g
 (envelope-from ); Tue, 12 Mar 2024 17:13:19 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d35dd5dc-e093-11ee-a1ee-f123f15fe8a2
Authentication-Results:garm.ovh; auth=pass (GARM-99G003d29cd4e1-61e3-4af7-82ad-29f88b641790,
                    0B6B113C544506A41C6EB031E0F94F2E66B6AEBC) smtp.auth=krystian.hebel@3mdeb.com
X-OVh-ClientIp:217.171.61.25
Message-ID: 
Date: Tue, 12 Mar 2024 18:13:17 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 9/9] x86/smp: start APs in parallel during boot
Content-Language: en-US
To: Jan Beulich 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org, Wei Liu 
References: 
 <77c9199eabf3a30ebcf89356b2dd35abd611a3a9.1699982111.git.krystian.hebel@3mdeb.com>
 
From: Krystian Hebel 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Ovh-Tracer-Id: 10173631559693281648
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedvledrjeefgdeljecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefkffggfgfuvfevfhfhjggtgfesthejredttddvjeenucfhrhhomhepmfhrhihsthhirghnucfjvggsvghluceokhhrhihsthhirghnrdhhvggsvghlseefmhguvggsrdgtohhmqeenucggtffrrghtthgvrhhnpeejuedvffefvdeuvdeffeduuddtjeetgeefffdugfdvkeehtedutefghfdtteejieenucffohhmrghinhepfehmuggvsgdrtghomhenucfkphepuddvjedrtddrtddruddpvddujedrudejuddriedurddvhedpfeejrdehledrudegvddrleelnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepuddvjedrtddrtddruddpmhgrihhlfhhrohhmpehkrhihshhtihgrnhdrhhgvsggvlhesfehmuggvsgdrtghomhdpnhgspghrtghpthhtohepuddprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdpoffvtefjohhsthepmhhoheeiuddpmhhouggvpehsmhhtphhouhht


On 8.02.2024 13:37, Jan Beulich wrote:
> On 14.11.2023 18:50, Krystian Hebel wrote:
>> Multiple delays are required when sending IPIs and waiting for
>> responses. During boot, 4 such IPIs were sent per each AP. With this
>> change, only one set of broadcast IPIs is sent. This reduces boot time,
>> especially for platforms with large number of cores.
> Yet APs do their startup work in parallel only for a brief period of
> time, if I'm not mistaken. Othwerwise I can't see why you'd still have
> cpu_up() in __start_xen().
cpu_up() is left because multiple notifiers aren't easy to convert to work
in parallel. In terms of lines of code it looks like a brief period, but all
the delays along the way were taking much more time than the actual
work. As the gain was already more than what I hoped for, I decided
against spending too much time trying to fix the notifiers' code for
minimal profit.
>
>> --- a/xen/arch/x86/setup.c
>> +++ b/xen/arch/x86/setup.c
>> @@ -1963,6 +1963,8 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>>                   cpu_data[i].stack_base = cpu_alloc_stack(i);
>>           }
>>   
>> +        smp_send_init_sipi_sipi_allbutself();
>> +
>>           for_each_present_cpu ( i )
>>           {
>>               if ( (park_offline_cpus || num_online_cpus() < max_cpus) &&
> So what about constraints on the number of CPUs to use? In such a case
> you shouldn't send the IPI to all of them, at least if they're not
> meant to be parked.
Fair point, such check can be easily added before broadcasting and the
rest of the code should already be able to handle this.
>
>> --- a/xen/arch/x86/smpboot.c
>> +++ b/xen/arch/x86/smpboot.c
>> @@ -425,7 +425,7 @@ void start_secondary(unsigned int cpu)
>>   
>>   static int wakeup_secondary_cpu(int phys_apicid, unsigned long start_eip)
>>   {
>> -    unsigned long send_status = 0, accept_status = 0;
>> +    unsigned long send_status = 0, accept_status = 0, sh = 0;
> sh doesn't need to be 64 bits wide, does it?
No, will change.
>
>>       int maxlvt, timeout, i;
>>   
>>       /*
>> @@ -445,6 +445,12 @@ static int wakeup_secondary_cpu(int phys_apicid, unsigned long start_eip)
>>       if ( tboot_in_measured_env() && !tboot_wake_ap(phys_apicid, start_eip) )
>>           return 0;
>>   
>> +    /*
>> +     * Use destination shorthand for broadcasting IPIs during boot.
>> +     */
> Nit (style): This is a single line comment.
Ack
>
>> +    if ( phys_apicid == BAD_APICID )
>> +        sh = APIC_DEST_ALLBUT;
> I think the latest for this the function parameter wants changing to
> unsigned int (in another prereq patch).
What do you mean, phys_apicid in wakeup_secondary_cpu()? It is passed
as signed int since __cpu_up(), should I change all of those to unsigned?
>
>> @@ -573,21 +578,31 @@ static int do_boot_cpu(int apicid, int cpu)
>>        */
>>       mtrr_save_state();
>>   
>> -    start_eip = bootsym_phys(trampoline_realmode_entry);
>> +    /* Check if AP is already up. */
>> +    if ( cpu_data[cpu].cpu_state != CPU_STATE_INIT )
>> +    {
>> +        /* This grunge runs the startup process for the targeted processor. */
>> +        unsigned long start_eip;
>> +        start_eip = bootsym_phys(trampoline_realmode_entry);
>>   
>> -    /* start_eip needs be page aligned, and below the 1M boundary. */
>> -    if ( start_eip & ~0xff000 )
>> -        panic("AP trampoline %#lx not suitably positioned\n", start_eip);
>> +        /* start_eip needs be page aligned, and below the 1M boundary. */
>> +        if ( start_eip & ~0xff000 )
>> +            panic("AP trampoline %#lx not suitably positioned\n", start_eip);
> Isn't this redundant now with the panic() in
> smp_send_init_sipi_sipi_allbutself(), at least as long as that runs
> unconditionally.
Won't be running unconditionally, but it also wouldn't be redundant in case
of hot-plugging.
>
>> -    /* So we see what's up   */
>> -    if ( opt_cpu_info )
>> -        printk("Booting processor %d/%d eip %lx\n",
>> -               cpu, apicid, start_eip);
>> +        /* So we see what's up   */
>> +        if ( opt_cpu_info )
>> +            printk("AP trampoline at %lx\n", start_eip);
> Why this change in log message? It makes messages for individual CPUs
> indistinguishable. And like above it's redundant with what
> smp_send_init_sipi_sipi_allbutself() logs.
>
>> -    /* This grunge runs the startup process for the targeted processor. */
>> +        /* mark "stuck" area as not stuck */
>> +        bootsym(trampoline_cpu_started) = 0;
>> +        smp_mb();
>>   
>> -    /* Starting actual IPI sequence... */
>> -    boot_error = wakeup_secondary_cpu(apicid, start_eip);
>> +        /* Starting actual IPI sequence... */
>> +        boot_error = wakeup_secondary_cpu(apicid, start_eip);
>> +    }
>> +
>> +    if ( opt_cpu_info )
>> +        printk("Booting processor %d/%d\n", cpu, apicid);
> Oh, here's the other half. Yet for above it still doesn't make sense
> to issue the same message for all CPUs.
I'll undo it. It was important at one point for debugging, but I agree
that it doesn't make sense now.
>
>> @@ -646,10 +661,6 @@ static int do_boot_cpu(int apicid, int cpu)
>>           rc = -EIO;
>>       }
>>   
>> -    /* mark "stuck" area as not stuck */
>> -    bootsym(trampoline_cpu_started) = 0;
>> -    smp_mb();
> While you move this up, it's not clear to me how you would now
> identify individual stuck CPUs. I would have expected that this is
> another global that needs converting up front, to be per-CPU.
In the existing code this is set very early, in 16b code, and the variable
is located within the first page of trampoline. With this change it is
impossible to identify individual stuck CPUs.

I was considering removing this variable altogether. Another option
would be to make this an array with NR_CPUS elements, but this may
get too big. It would be possible to fill this relatively early, after 
CPU ID
is obtained, before paging is enabled, but after loading IDT, GDT and
jumping to protected mode. Those are things that can break due to error
in the code, but it may be better than not having that info at all.

It could also be set from 64b code, that way simple per-CPU data would
work. It is a bit late, but this would probably be easiest and cleanest to
write.

>
>> @@ -1155,6 +1166,23 @@ static struct notifier_block cpu_smpboot_nfb = {
>>       .notifier_call = cpu_smpboot_callback
>>   };
>>   
>> +void smp_send_init_sipi_sipi_allbutself(void)
> __init?
Ack
>
>> +{
>> +    unsigned long start_eip;
>> +    start_eip = bootsym_phys(trampoline_realmode_entry);
> This can be the initializer of the variable, which would then save
> me from complaining about the missing blank line between declaration
> and statement(s). (Actually, as I notice only now - same for code you
> move around in do_boot_cpu().)
Will do. It may still be split due to line length, but at least that will
follow code style.
>
> Jan
Best regards,

-- 
Krystian Hebel
Firmware Engineer
https://3mdeb.com | @3mdeb_com



From xen-devel-bounces@lists.xenproject.org Tue Mar 12 17:19:55 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Mar 2024 17:19:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692045.1078887 (Exim 4.92)
	(envelope-from )
	id 1rk5n5-000270-8L; Tue, 12 Mar 2024 17:19:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692045.1078887; Tue, 12 Mar 2024 17:19:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rk5n5-00026q-5H; Tue, 12 Mar 2024 17:19:51 +0000
Received: by outflank-mailman (input) for mailman id 692045;
 Tue, 12 Mar 2024 17:19:50 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rk5n4-00026P-MV
 for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 17:19:50 +0000
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com
 [2a00:1450:4864:20::431])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id baa06ab7-e094-11ee-a1ee-f123f15fe8a2;
 Tue, 12 Mar 2024 18:19:48 +0100 (CET)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-33e796cc90dso3858949f8f.1
 for ; Tue, 12 Mar 2024 10:19:48 -0700 (PDT)
Received: from perard.uk.xensource.com (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 q11-20020adff94b000000b0033e95bf4796sm5989383wrr.27.2024.03.12.10.19.47
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 12 Mar 2024 10:19:47 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: baa06ab7-e094-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1710263988; x=1710868788; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=Hq8LWSB3qSsVNYgo0a/9Z9B/117exxE3zbam1vD/XCA=;
        b=IbRyXdQdQfDzTArKeg4CVV+H6E80aunrkNhE7GY3tv8zCqAau13C1OJzkLlBBzhduC
         n+ZR3cTGr3uqOVcBO9JBDgkQibmBkaANjl89TBgiaXe0/8/Lx6x3bkuCXzfD4w4u+u1j
         7cnFEwsKyLmfN2v0b/iJnXbZmjmMOT7OlDbec=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710263988; x=1710868788;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=Hq8LWSB3qSsVNYgo0a/9Z9B/117exxE3zbam1vD/XCA=;
        b=vGJGu1n36XATU280MwDs49h1nhZYLVznCeMEQqLdBj4OyyI3xjracHhzIJoET2Xi5z
         YAePj/2Q4IJUC5wCx/xhF+iaLk4s2EH83Y1sjGpVjHRfQQuxFdUavQYmJkRVHcTeWWY8
         bsrAy+pWEZNkYeo1Z9Tg/h85ZDC6N4+NGZrx5OnmEbIAswvFx+aLkb7oxj3T7hPxDCA5
         +1xiV0V3PavpRcKHcEaicmq6G0vg9qGYDjsONZjfUV0xZsDLAgLqi3jc+Ornhy67a6Rv
         q9kf/oMs2xX+8QWGGAzlDI0F/VIVX40CfKKbFV9q57Pdk7WliZ9PbTtw/RHJZIO1vBWp
         avEg==
X-Gm-Message-State: AOJu0YzelAYdmM+3bTYFk0TqhfeELSkTaxxuo4xMfR6eYBlnzLivoJfh
	mFis8i8z5zYCA8yxY70AkZOZHiQ7OGAfAwDdZ+D9yE7Akv8pYR1tUC9qV0vEHYk=
X-Google-Smtp-Source: AGHT+IGqgO5bPlvg9N959fq3DxWe7mHFozhK9DxZCbsVgn25el31N1p9dO6wD0B0WQX/suvwYob2GQ==
X-Received: by 2002:adf:fa0d:0:b0:33e:69db:bf9e with SMTP id m13-20020adffa0d000000b0033e69dbbf9emr59255wrr.67.1710263988174;
        Tue, 12 Mar 2024 10:19:48 -0700 (PDT)
Date: Tue, 12 Mar 2024 17:19:46 +0000
From: Anthony PERARD 
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= 
Cc: xen-devel@lists.xenproject.org, Jan Beulich ,
	Andrew Cooper ,
	Juergen Gross 
Subject: Re: [OSSTEST PATCH] ap-common: Switch to Linux 6.1 by default on x86
 + drop dom0 i386
Message-ID: 
References: <20240306114741.14564-1-anthony.perard@citrix.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Mon, Mar 11, 2024 at 06:27:52PM +0100, Roger Pau Monn wrote:
> On Wed, Mar 06, 2024 at 11:47:41AM +0000, Anthony PERARD wrote:
> > Gone, but replaced by a new test-amd64-amd64-*:
> > - test-amd64-i386-libvirt-raw
> > - test-amd64-i386-xl-vhd
> > 
> > Some test-amd64-amd64-* are also changed:
> > - test-amd64-amd64-libvirt-vhd
> > - test-amd64-amd64-qemuu-freebsd11-amd64
> > - test-amd64-amd64-qemuu-freebsd12-amd64
> > - test-amd64-amd64-xl-qcow2
> > + test-amd64-amd64-freebsd11-amd64
> > + test-amd64-amd64-freebsd12-amd64
> > + test-amd64-amd64-libvirt-qcow2
> > + test-amd64-amd64-libvirt-raw
> > + test-amd64-amd64-xl-vhd
> 
> Is this purely a name change, or there's some kind of functional
> change?

For test-amd64-amd64-qemuu-freebsd1{1,2}-amd64, it looks like the
"-qemuu" is a bug. The freebsd jobs shouldn't have used $qemuu_suffix,
as it doesn't use $qemuu_runvar. So I'm guessing $qemuu_suffix was just
the value left from a previous call of test_matrix_do_one() with
dom0arch==i386. The new name is already used by "linux-linus" branch.

As for the few changes in {xl,libvirt}-{raw,vhd,qcow2} tests, this is
because of
- f536e834f673 ("make-flight: Trim the matrix of disk format flights")
- 5c70735f177f ("fmtarches: Use dom0arches, not hardcoded arch list")
   > It's not ideal because it means tests jumping about across arches and
   > might let regressions go through but it's better than just dropping
   > them, and doing a better approach is complex.

So, for those, yes, it's different tests. It adds one "-raw" test, and
otherwise changes the toolstack used for the two other disk formats.

> I'm mostly worried whether this could lead to regressions getting in
> as osstest would detect those jobs as new instead of inheriting from
> the previous jobs.  Also the "History for test ..." won't link to jobs
> prior to the rename?

Well, those tests are already in the "linux-linus" branch and the new
"linux-6.1" branch, so we can already check manually if there's a
regression or not. So if they pass in linux-6.1, regression will be
detected, at least in the linux branch.

The rename of the freebsd jobs is unfortunate, but at least, it's going
to be the correct name, instead of having a spurious "-qemuu" suffix.

As for "history of tests " pages, no I don't think we can easly link to
to the previous job name. But that only apply to both freebsd* jobs.

We could keep the -qemuu in freebsd* jobs even if it's misleading to
someone who know what it should mean, that would keep the job name to
all branches and rename it in "linux-linus" branch. I don't know which
one is better.

> I guess I'm confused about what causes the qemuu to be dropped from
> the job names above.

It just shell script having variable been global by default.

Cheers,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Tue Mar 12 19:54:30 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Mar 2024 19:54:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692187.1079027 (Exim 4.92)
	(envelope-from )
	id 1rk8CT-0005io-Tq; Tue, 12 Mar 2024 19:54:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692187.1079027; Tue, 12 Mar 2024 19:54:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rk8CT-0005ih-QQ; Tue, 12 Mar 2024 19:54:13 +0000
Received: by outflank-mailman (input) for mailman id 692187;
 Tue, 12 Mar 2024 19:54:12 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rk8CS-0005ib-29
 for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 19:54:12 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4a35eb77-e0aa-11ee-a1ee-f123f15fe8a2;
 Tue, 12 Mar 2024 20:54:09 +0100 (CET)
Received: from [192.168.1.113] (93-36-220-117.ip62.fastwebnet.it
 [93.36.220.117])
 by support.bugseng.com (Postfix) with ESMTPSA id 670134EE073E;
 Tue, 12 Mar 2024 20:54:08 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4a35eb77-e0aa-11ee-a1ee-f123f15fe8a2
Message-ID: <4b62c3e6-0851-4cfe-87ca-06a22d6b8243@bugseng.com>
Date: Tue, 12 Mar 2024 20:54:06 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN RFC] xen: avoid grep fodder define and undef
Content-Language: en-US, it
To: Jan Beulich 
Cc: consulting@bugseng.com, Paul Durrant ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 xen-devel@lists.xenproject.org
References: <0002f3df03aac283fa3dc7365e9040ab7ffaee2e.1710242950.git.federico.serafini@bugseng.com>
 <338db1b9-54f1-4687-ba9a-2eec282db1d5@suse.com>
From: Federico Serafini 
Organization: BUGSENG srl
In-Reply-To: <338db1b9-54f1-4687-ba9a-2eec282db1d5@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 12/03/24 15:30, Jan Beulich wrote:
> On 12.03.2024 12:48, Federico Serafini wrote:
>> Place an "#if 0" before grep fodder definitions and remove the
>> "#undef".
>>
>> This addresses several violations of MISRA C:2012 Rule 5.5
>> ("Identifiers shall be distinct from macro names").
>>
>> No functional change.
>>
>> Signed-off-by: Federico Serafini 
>> ---
>> Hello, I would like to know what you think about this change.
>> If you want to keep grep fodders as they are, an alternative could be to
>> deviate violations of Rule 5.5 involving the TYPE_SAFE macro.
> 
> I think the original intention was to allow for some (arch?) override.
> But we have lived without for long enough that I think we could do as
> you suggest. One question though: Wasn't there also a rule against the
> use of #undef, violations of which would then be eliminate here as well? > If so, I think that would want mentioning in the description. If not,
> I'd like to give it a couple of days before ack-ing, just in case other
> opinions would be voiced.

Yes, it is advisory Rule 20.5.

> 
>> --- a/xen/include/xen/iommu.h
>> +++ b/xen/include/xen/iommu.h
>> @@ -33,13 +33,10 @@ TYPE_SAFE(uint64_t, dfn);
>>   #define PRI_dfn     PRIx64
>>   #define INVALID_DFN _dfn(~0ULL)
>>   
>> -#ifndef dfn_t
>> +#if 0
>>   #define dfn_t /* Grep fodder: dfn_t, _dfn() and dfn_x() are defined above */
>>   #define _dfn
>>   #define dfn_x
>> -#undef dfn_t
>> -#undef _dfn
>> -#undef dfn_x
>>   #endif
> 
> I have to admit that I'm a little surprised that Misra (Eclair) is
> happy with this: The #define-s are all still there, after all.

The #define-s after the #if 0 are skipped by the preprocessor and this
is something that MISRA takes into account.

As an example, Directive 4.4 states that code should not be commented
out and explicitly cites the use of #if and #ifdef to exclude code from
the compilation.

-- 
Federico Serafini, M.Sc.

Software Engineer, BUGSENG (http://bugseng.com)


From xen-devel-bounces@lists.xenproject.org Tue Mar 12 21:04:33 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Mar 2024 21:04:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692190.1079038 (Exim 4.92)
	(envelope-from )
	id 1rk9IH-0007dz-U3; Tue, 12 Mar 2024 21:04:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692190.1079038; Tue, 12 Mar 2024 21:04:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rk9IH-0007ds-Pr; Tue, 12 Mar 2024 21:04:17 +0000
Received: by outflank-mailman (input) for mailman id 692190;
 Tue, 12 Mar 2024 21:04:16 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rk9IG-0007di-62; Tue, 12 Mar 2024 21:04:16 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rk9IG-0003uG-2v; Tue, 12 Mar 2024 21:04:16 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rk9IF-0003lv-Pm; Tue, 12 Mar 2024 21:04:15 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rk9IF-0002u9-NN; Tue, 12 Mar 2024 21:04:15 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=CAH3iQ1JWZQXB1Vq8NSczCvWf1wmLNDRMQ/4ZmROeps=; b=DAiNiKjIxXhvfaL5RLmA4zZRV4
	zNhl6cIL1WO9nVhHqAsjxam9pOS8QDV+okGukQfXpsQqCq48c93XYSd8wMcvn5//q7BBsC2A93JtL
	XoIXieAj9sfQiBIEUpgVGZl8jGPwQBIUlaYbU/kyJ4gqxhxa8CU+mQKd0GlczHqFS60M=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 185009: tolerable all pass - PUSHED
X-Osstest-Failures:
    xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    xen=03cf7ca23e0e876075954c558485b267b7d02406
X-Osstest-Versions-That:
    xen=7c81558208de7858251b62f168a449be84305595
From: osstest service owner 
Date: Tue, 12 Mar 2024 21:04:15 +0000

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          16 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  03cf7ca23e0e876075954c558485b267b7d02406
baseline version:
 xen                  7c81558208de7858251b62f168a449be84305595

Last test of basis   184995  2024-03-11 13:00:25 Z    1 days
Testing same since   185009  2024-03-12 18:00:27 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Roger Pau Monné 

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-amd64                    pass    
 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
   7c81558208..03cf7ca23e  03cf7ca23e0e876075954c558485b267b7d02406 -> smoke


From xen-devel-bounces@lists.xenproject.org Tue Mar 12 21:07:24 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Mar 2024 21:07:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692194.1079047 (Exim 4.92)
	(envelope-from )
	id 1rk9LH-0008BX-B4; Tue, 12 Mar 2024 21:07:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692194.1079047; Tue, 12 Mar 2024 21:07:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rk9LH-0008BQ-7x; Tue, 12 Mar 2024 21:07:23 +0000
Received: by outflank-mailman (input) for mailman id 692194;
 Tue, 12 Mar 2024 21:07:21 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rk9LF-0008BK-9x
 for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 21:07:21 +0000
Received: from NAM04-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam04on20600.outbound.protection.outlook.com
 [2a01:111:f403:2408::600])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8229b3f0-e0b4-11ee-a1ee-f123f15fe8a2;
 Tue, 12 Mar 2024 22:07:18 +0100 (CET)
Received: from BN9PR03CA0358.namprd03.prod.outlook.com (2603:10b6:408:f6::33)
 by BY5PR12MB4290.namprd12.prod.outlook.com (2603:10b6:a03:20e::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.35; Tue, 12 Mar
 2024 21:07:14 +0000
Received: from BN2PEPF000044A8.namprd04.prod.outlook.com
 (2603:10b6:408:f6:cafe::3) by BN9PR03CA0358.outlook.office365.com
 (2603:10b6:408:f6::33) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.34 via Frontend
 Transport; Tue, 12 Mar 2024 21:07:14 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 BN2PEPF000044A8.mail.protection.outlook.com (10.167.243.102) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7386.12 via Frontend Transport; Tue, 12 Mar 2024 21:07:14 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Tue, 12 Mar
 2024 16:07:13 -0500
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB05.amd.com
 (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Tue, 12 Mar
 2024 16:07:13 -0500
Received: from [172.27.105.181] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Tue, 12 Mar 2024 16:07:12 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8229b3f0-e0b4-11ee-a1ee-f123f15fe8a2
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=fPb7m4Z9is1mUzTYYV78kYLQfOZfn9hkJMkUtd5vDDQcDFLm2pTSeGUCD3JJeEA0QAtaCGQ3Mod3xa5JZom6ytZNg7qbMzHOUKXGvCXG7S8+5GRAGNB5C0NtCCBitqWcavH6IzzhTgO8fFHsy2iQUMZzDFuflDWR8lm6UHmFv12SPYRKuqsKk7GrgnURp+8I92ITX5UhAW7j8tSAjmHHVVMvW2hzg+bAeh85eptSCrTvnSiLNbaHyLwAy8ifTKVgYJP9XEEC0PTaaM/U5tRL8/TEwVgujhIshCDfBy8TUECG9E9mJUC+iUGjB9+Y27J+3maiA8k79G5hoMZ354/lXA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Kmh5UqZ5R5kQnbVbB8JNHjk/o5Wo9fYO0iZUT8Ma4f8=;
 b=dQTyCN9/ivjyazlkCae6+agr/ru/aFI2gDGUMcmJijeqVuVzQvnpNjZ2QwFf8m5tJdQVAw1MI7hTsQdoZKdpcjFwX7MoipYxYccmrEBeGwVjnOH28HTyOm2Iy4teauxpF8Ha7aOCLK1OGQ6fDMY+XzbliKzib20sg8AoYhBfnxef7uY9DVTSMXPudgM12YA9At/jhnNtog0915NoSGyIc9JeMj4PUtxPqT6S+cw7fbgNNmuthINQwiimjebYtqWsZ12rkG3i+ff0ur0sYsVALCrLrdRLCY1IVrycM72CoyCX8GVu+FrjKn7AHvOAPYXV1fT7Vq9Zd5bPR09debUX7A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=invisiblethingslab.com
 smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100)
 action=none header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=Kmh5UqZ5R5kQnbVbB8JNHjk/o5Wo9fYO0iZUT8Ma4f8=;
 b=lHqZrI++k/X/w/+7pLeuxz6wMk20odao4VsZN7u8waERONpsLz+R7tTF9EKoWmMLJ0UaI1CuQrpjwdbZewXa659XlZjgvXbewhoPkEARRuqHoJ0VIjI5+voVoMe35pKeWZSKG7LPAcReZf6PyCU/wMscSsRA5hwOghWQjFkGigI=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
Message-ID: <9207a620-2998-49dc-992f-5d756d3f6524@amd.com>
Date: Tue, 12 Mar 2024 17:07:12 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: E820 memory allocation issue on Threadripper platforms
Content-Language: en-US
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
	, Jan Beulich , "Juergen
 Gross" , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
	
CC: Patrick Plenefisch ,
	, Jason Andryuk 
References: 
 <1708c3d7-662a-44bc-b9b3-4ab9f8642d7b@suse.com>
 
 
 
 
 
 
  
From: Jason Andryuk 
In-Reply-To: 
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
Received-SPF: None (SATLEXMB05.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN2PEPF000044A8:EE_|BY5PR12MB4290:EE_
X-MS-Office365-Filtering-Correlation-Id: 3b0946d5-9004-491f-353e-08dc42d8642e
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	KbDvYFQ3ovh1Zzt1ePn0mmmA1YmBuFuOycvd9wdFk0cF/bS52uyxfAdBT3CqfzYVV+1PCZXzp0O70+MLoAve7CK+VfdXg387dsTWCf+VOroJpYOFftbDNhMjtjDR+dyDezbEpVJrAHyDzguYRuCfd/mhoTxQA5xWwlrbOTmh6v+2aY+H79towgvto+lsxezqlXKkN84Potx0YvW3We4AZl53slBAeN7DdfEO0jxknSBara913LgDtHFPsHTPO131IPTEkA3VJ+pxv/oveSQAgR83gwHqsJvJHX9Dd36IMyXsGxQoOp4EDc5aw22LGZ1hDWyGkrL6zhmtustjK6wwaEXpDtWIWmVs5f6F9/pxZzN/VHc2bMJdgLe0X0aAigaYss5dKXOR3/+Fhwu9SwinffA8+I96/VdbNMxSbXk8VAFcDt46hzF5+UsVeYFu+NRZVkwVhdNZTsbgbk9RVV0ks6ghl9vJCCM20uI+9TXPVnjhk0RCUeFpAQEqRSWQ18BYR3EX/wRWJNDUcXOVHPWmXpsMVH8efzqQQMjla1Qp+FvJq7Xras0NkVwFWfNgAaUM3Sjof447eoL2IGnRsg/8e8Q8IlQ5IQdVQqjVqG6P+moRtNzVUmyqPyCMpaGLbWLhfyeYYvUXR2w4z4rQph0NKUTcQ3W704dba53Lf7EDfBrCiKiEKWVAP7xKAiOoeiml6O+D/E6HewTtUg80NWOSFuuiE9J+yDq+FWJmqLgU49fV/ZBGObRFxncDF0S2Vv3h
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(376005)(36860700004)(1800799015)(82310400014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Mar 2024 21:07:14.0574
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 3b0946d5-9004-491f-353e-08dc42d8642e
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN2PEPF000044A8.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR12MB4290

On 2024-03-10 10:06, Marek Marczykowski-Górecki wrote:
> On Fri, Jan 19, 2024 at 02:40:06PM +0100, Marek Marczykowski-Górecki wrote:
>> On Thu, Jan 18, 2024 at 01:23:56AM -0500, Patrick Plenefisch wrote:
>>> On Wed, Jan 17, 2024 at 3:46 AM Jan Beulich  wrote:
>>>> On 17.01.2024 07:12, Patrick Plenefisch wrote:
>>>>> As someone who hasn't built a kernel in over a decade, should I figure
>>>> out
>>>>> how to do a kernel build with CONFIG_PHYSICAL_START=0x2000000 and report
>>>>> back?
>>>>
>>>> That was largely a suggestion to perhaps allow you to gain some
>>>> workable setup. It would be of interest to us largely for completeness.
>>>>
>>>
>>> Typo aside, setting the boot to 2MiB works! It works better for PV
>>
>> Are there any downsides of running kernel with
>> CONFIG_PHYSICAL_START=0x200000? I can confirm it fixes the issue on
>> another affected system, and if there aren't any practical downsides,
>> I'm tempted to change it the default kernel in Qubes OS.
> 
> I have the answer here: CONFIG_PHYSICAL_START=0x200000 breaks booting
> Xen in KVM with OVMF. There, the memory map has:
> (XEN)  0000000100000-00000007fffff type=7 attr=000000000000000f
> (XEN)  0000000800000-0000000807fff type=10 attr=000000000000000f
> (XEN)  0000000808000-000000080afff type=7 attr=000000000000000f
> (XEN)  000000080b000-000000080bfff type=10 attr=000000000000000f
> (XEN)  000000080c000-000000080ffff type=7 attr=000000000000000f
> (XEN)  0000000810000-00000008fffff type=10 attr=000000000000000f
> (XEN)  0000000900000-00000015fffff type=4 attr=000000000000000f
> 
> So, starting at 0x1000000 worked since type=4 (boot service data) is
> available at that time already, but with 0x200000 it conflicts with
> those AcpiNvs areas around 0x800000.
> 
> I'm cc-ing Jason since I see he claimed relevant gitlab issue. This
> conflict at least gives easy test environment with console logged to a
> file.

Thanks.  I actually hacked Xen to reserve memory ranges in the e820 to 
repro.

I claimed the *PVH* Dom0 gitlab issue.  PV is outside of my scope :(

Regards,
Jason


From xen-devel-bounces@lists.xenproject.org Tue Mar 12 22:00:29 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Mar 2024 22:00:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692199.1079056 (Exim 4.92)
	(envelope-from )
	id 1rkAAX-0007yV-Ar; Tue, 12 Mar 2024 22:00:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692199.1079056; Tue, 12 Mar 2024 22:00:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkAAX-0007yO-8J; Tue, 12 Mar 2024 22:00:21 +0000
Received: by outflank-mailman (input) for mailman id 692199;
 Tue, 12 Mar 2024 22:00:20 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkAAW-0007yI-J3
 for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 22:00:20 +0000
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com
 [66.111.4.29]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e816584a-e0bb-11ee-afdd-a90da7624cb6;
 Tue, 12 Mar 2024 23:00:18 +0100 (CET)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.48])
 by mailout.nyi.internal (Postfix) with ESMTP id B05C15C0086;
 Tue, 12 Mar 2024 18:00:14 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163])
 by compute7.internal (MEProxy); Tue, 12 Mar 2024 18:00:14 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 12 Mar 2024 18:00:12 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e816584a-e0bb-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-type:content-type:date
	:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to; s=fm1; t=1710280814;
	 x=1710367214; bh=6D5/LLqXdsYWMYX8yW9HXHbC3p01jO2T7c0aof4XfOM=; b=
	AUECVd+xGNQEQXoFII1I4vPF3ajvgDOEk436r9wcTFYs6Glil7zKePJpyLIU5aUT
	dVQmWHSIwUrQdrL+/FUM0fbX91qEUgqIcNrW+S9PswMIxfqdeumfZb1+XUo+tst8
	ilbyi999u9Xxm5oYTHxfYmU0cGj+tpFZBQ8jhm1KU7GfV1qMLixYxjITYYMA7PHx
	dIb4WVq3qjaetmviN9ultWIvMCahuS0y5Z810X7mwgyUxsxYyHUWlk+dAfeeojRf
	7835Sx8EqbEiCVALOM419n47h0F2ycNJn6rxcElnApk59m/kXZApMcrsM7GPbh0v
	C5VWWtB3RHYKXvkEqnEVbw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-type:content-type:date:date
	:feedback-id:feedback-id:from:from:in-reply-to:in-reply-to
	:message-id:mime-version:references:reply-to:subject:subject:to
	:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=
	fm1; t=1710280814; x=1710367214; bh=6D5/LLqXdsYWMYX8yW9HXHbC3p01
	jO2T7c0aof4XfOM=; b=KaM4Nf4PhoWL4F6PYj11ahyRwaZuPWtBQ18XxW+ip6Wz
	s2X1OBieOqMOEgsrXkVyonMPWS1A1g0LbA2YdSFXTsECChoBmlIfIhJ65NMhauWX
	uJ66ZWVDj7QvCWQZEc9lltt4UlrI9E6u089F7OPWix2nke6YFf43C34wOfYNcdMH
	741fJZML4bhNoowsljfhM3xqjH0eyMUCEyNy0rL8bf/STyhilN4TI0JrD2lweF6R
	IErnfjXCr4rxKd8RpWU7Y9qATaGCq2JiZ+677ZoWpglpTr6UYbhQENYAOu944k6T
	ZYptUu01t57jS+L3Uxq5FahgJeN1fhM5ROl904GOPQ==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrjeefgdduheehucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
    uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
    cujfgurhepfffhvfevuffkfhggtggujgesghdtreertddtjeenucfhrhhomhepofgrrhgv
    khcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinh
    hvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepgfdu
    leetfeevhfefheeiteeliefhjefhleduveetteekveettddvgeeuteefjedunecuvehluh
    hsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghk
    sehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Tue, 12 Mar 2024 23:00:09 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Jason Andryuk 
Cc: Jan Beulich , Juergen Gross ,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	Patrick Plenefisch ,
	xen-devel@lists.xenproject.org, Jason Andryuk 
Subject: Re: E820 memory allocation issue on Threadripper platforms
Message-ID: 
References: <1708c3d7-662a-44bc-b9b3-4ab9f8642d7b@suse.com>
 
 
 
 
 
 
 
 
 <9207a620-2998-49dc-992f-5d756d3f6524@amd.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="TOyaDT5Pyb2A8YcA"
Content-Disposition: inline
In-Reply-To: <9207a620-2998-49dc-992f-5d756d3f6524@amd.com>


--TOyaDT5Pyb2A8YcA
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Tue, 12 Mar 2024 23:00:09 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Jason Andryuk 
Cc: Jan Beulich , Juergen Gross ,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	Patrick Plenefisch ,
	xen-devel@lists.xenproject.org, Jason Andryuk 
Subject: Re: E820 memory allocation issue on Threadripper platforms

On Tue, Mar 12, 2024 at 05:07:12PM -0400, Jason Andryuk wrote:
> On 2024-03-10 10:06, Marek Marczykowski-G=C3=B3recki wrote:
> > On Fri, Jan 19, 2024 at 02:40:06PM +0100, Marek Marczykowski-G=C3=B3rec=
ki wrote:
> > > On Thu, Jan 18, 2024 at 01:23:56AM -0500, Patrick Plenefisch wrote:
> > > > On Wed, Jan 17, 2024 at 3:46=E2=80=AFAM Jan Beulich  wrote:
> > > > > On 17.01.2024 07:12, Patrick Plenefisch wrote:
> > > > > > As someone who hasn't built a kernel in over a decade, should I=
 figure
> > > > > out
> > > > > > how to do a kernel build with CONFIG_PHYSICAL_START=3D0x2000000=
 and report
> > > > > > back?
> > > > >=20
> > > > > That was largely a suggestion to perhaps allow you to gain some
> > > > > workable setup. It would be of interest to us largely for complet=
eness.
> > > > >=20
> > > >=20
> > > > Typo aside, setting the boot to 2MiB works! It works better for PV
> > >=20
> > > Are there any downsides of running kernel with
> > > CONFIG_PHYSICAL_START=3D0x200000? I can confirm it fixes the issue on
> > > another affected system, and if there aren't any practical downsides,
> > > I'm tempted to change it the default kernel in Qubes OS.
> >=20
> > I have the answer here: CONFIG_PHYSICAL_START=3D0x200000 breaks booting
> > Xen in KVM with OVMF. There, the memory map has:
> > (XEN)  0000000100000-00000007fffff type=3D7 attr=3D000000000000000f
> > (XEN)  0000000800000-0000000807fff type=3D10 attr=3D000000000000000f
> > (XEN)  0000000808000-000000080afff type=3D7 attr=3D000000000000000f
> > (XEN)  000000080b000-000000080bfff type=3D10 attr=3D000000000000000f
> > (XEN)  000000080c000-000000080ffff type=3D7 attr=3D000000000000000f
> > (XEN)  0000000810000-00000008fffff type=3D10 attr=3D000000000000000f
> > (XEN)  0000000900000-00000015fffff type=3D4 attr=3D000000000000000f
> >=20
> > So, starting at 0x1000000 worked since type=3D4 (boot service data) is
> > available at that time already, but with 0x200000 it conflicts with
> > those AcpiNvs areas around 0x800000.
> >=20
> > I'm cc-ing Jason since I see he claimed relevant gitlab issue. This
> > conflict at least gives easy test environment with console logged to a
> > file.
>=20
> Thanks.  I actually hacked Xen to reserve memory ranges in the e820 to
> repro.
>=20
> I claimed the *PVH* Dom0 gitlab issue.  PV is outside of my scope :(

That's not bad either, it means we're getting closer to usable PVH dom0
:)

--=20
Best Regards,
Marek Marczykowski-G=C3=B3recki
Invisible Things Lab

--TOyaDT5Pyb2A8YcA
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmXw0GoACgkQ24/THMrX
1yypLgf5AZRwhRFiM87Nuk24tv2H3Xhdxk2BfkcZ1NF4tqqXiileISW9XtYW241D
OQJb7Wd802Ynh/zX84QbJ9BF/FmaQ6pmHN5X2EJzdWkBWzdQ1PJqbBgpyMijpBvw
FufBj8BFFna+TwI2fiumMNlUdd6aLIKUevB9Gpyy+8w6na1EIDBbt+GdE86eTL/a
oRihxPahjQjNJqnmHoBuqgzByRmR46tL6lAtjVQKoEfNfgOUnpF7vlY8uBdJ2+aU
u31KOznD7AJ5rSrt7S2qShM0jlTJcm+S2e6Mx2aqhG9qTa/9SpOpztfzRCU2+DBi
biuY561P6xylxImiJUhs2ZonDeReEQ==
=Nrvi
-----END PGP SIGNATURE-----

--TOyaDT5Pyb2A8YcA--


From xen-devel-bounces@lists.xenproject.org Tue Mar 12 22:25:47 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Mar 2024 22:25:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692202.1079067 (Exim 4.92)
	(envelope-from )
	id 1rkAYv-0002eQ-8P; Tue, 12 Mar 2024 22:25:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692202.1079067; Tue, 12 Mar 2024 22:25:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkAYv-0002eJ-5x; Tue, 12 Mar 2024 22:25:33 +0000
Received: by outflank-mailman (input) for mailman id 692202;
 Tue, 12 Mar 2024 22:25:32 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1rkAYu-0002eD-AU
 for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 22:25:32 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkAYt-0005DF-Uv; Tue, 12 Mar 2024 22:25:31 +0000
Received: from gw1.octic.net ([88.97.20.152] helo=[10.0.1.154])
 by xenbits.xenproject.org with esmtpsa
 (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92)
 (envelope-from )
 id 1rkAYt-00007Y-ND; Tue, 12 Mar 2024 22:25:31 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=DNwqCg0GGxDtiDmugP+jNfX9AiORp/9MrBQGtaKlE2g=; b=RbddF8P0iLDekAlUzRm/vv1q64
	QGL9tLnl3MH8S+OLckfysDK/TIfeEf6Xuh8D+dv8CDnGWqr4L6YD/TOb7U0OtXU5x7oxgwpkcEaNt
	OO/VwbOkdA7wXZugIUFikVkKNb7lr3I1/HW+8WhFHhJcyxBLPyjbIvVroVmob80y2nN8=;
Message-ID: <20531f63-d342-4ce5-88fb-01b7431ebd96@xen.org>
Date: Tue, 12 Mar 2024 22:25:29 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN v6 1/3] xen/arm: Introduce CONFIG_PARTIAL_EMULATION and
 "partial-emulation" cmd option
To: Ayan Kumar Halder ,
 xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org, stefano.stabellini@amd.com,
 Volodymyr_Babchuk@epam.com, bertrand.marquis@arm.com, michal.orzel@amd.com
References: <20240307123943.1991755-1-ayan.kumar.halder@amd.com>
 <20240307123943.1991755-2-ayan.kumar.halder@amd.com>
Content-Language: en-GB
From: Julien Grall 
In-Reply-To: <20240307123943.1991755-2-ayan.kumar.halder@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

On 07/03/2024 12:39, Ayan Kumar Halder wrote:
> diff --git a/SUPPORT.md b/SUPPORT.md
> index 7eb6875cfa..b49da114ab 100644
> --- a/SUPPORT.md
> +++ b/SUPPORT.md
> @@ -102,6 +102,15 @@ Extension to the GICv3 interrupt controller to support MSI.
>   
>       Status: Experimental
>   
> +### ARM/Partial Emulation
> +
> +Enable partial emulation of registers, otherwise considered unimplemented,
> +that would normally trigger a fault injection.
> +
> +    Status: Supported, with caveats
> +
> +Only the following system registers are security supported:

This reads slightly odd. I would have have expected a few more registers 
afterwards. I would have considered to move this sentence to patch #2 or 
maybe N/A. Anyway, that's not too important (the patch doesn't make 
sense without the next one). So:

Acked-by: Julien Grall 

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Tue Mar 12 22:27:58 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Mar 2024 22:27:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692204.1079077 (Exim 4.92)
	(envelope-from )
	id 1rkAbF-0003BC-LB; Tue, 12 Mar 2024 22:27:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692204.1079077; Tue, 12 Mar 2024 22:27:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkAbF-0003B5-Hv; Tue, 12 Mar 2024 22:27:57 +0000
Received: by outflank-mailman (input) for mailman id 692204;
 Tue, 12 Mar 2024 22:27:56 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1rkAbD-0003Ax-Vr
 for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 22:27:55 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkAbD-0005Gt-NP; Tue, 12 Mar 2024 22:27:55 +0000
Received: from gw1.octic.net ([88.97.20.152] helo=[10.0.1.154])
 by xenbits.xenproject.org with esmtpsa
 (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92)
 (envelope-from )
 id 1rkAbD-0000C1-GY; Tue, 12 Mar 2024 22:27:55 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=wx58u5A4dqH0TFASEF8vCfseQWDddu8UgJ4sVMAUW0Y=; b=hW7mg9nxE6iU21lYxctot0duvY
	of0NzY2xP//e9/LMUJ+hgNfHbbtV480GtGwlaDPVKnNwNJGsBqPwrJflmdBrb1P/BEgJw+iZx4+TF
	M6pQ3SZXC/jNmJTWIKN2zXe376RSWWG43xRyfVcUrcaabiMI7Hg3gFUR2CJWGyt/0EPM=;
Message-ID: 
Date: Tue, 12 Mar 2024 22:27:53 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN v6 2/3] xen/arm: arm64: Add emulation of Debug Data Transfer
 Registers
Content-Language: en-GB
To: Ayan Kumar Halder ,
 xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org, stefano.stabellini@amd.com,
 Volodymyr_Babchuk@epam.com, bertrand.marquis@arm.com, michal.orzel@amd.com
References: <20240307123943.1991755-1-ayan.kumar.halder@amd.com>
 <20240307123943.1991755-3-ayan.kumar.halder@amd.com>
From: Julien Grall 
In-Reply-To: <20240307123943.1991755-3-ayan.kumar.halder@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Ayan,

On 07/03/2024 12:39, Ayan Kumar Halder wrote:
> From: Michal Orzel 
> 
> Currently, if user enables HVC_DCC config option in Linux, it invokes access
> to debug data transfer registers (i.e. DBGDTRTX_EL0 on arm64, DBGDTRTXINT on
> arm32). As these registers are not emulated, Xen injects an undefined
> exception to the guest and Linux crashes.
> 
> To prevent this crash, introduce a partial emulation of DBGDTR[TR]X_EL0
> (these registers share the same encoding) as RAZ/WI and MDCCSR_EL0 as TXfull.
> 
> Refer ARM DDI 0487J.a ID042523, D19.3.8, DBGDTRTX_EL0
> "If TXfull is set to 1, set DTRRX and DTRTX to UNKNOWN".
> 
> Thus, any OS is expected to read MDCCSR_EL0 and check for TXfull before
> using DBGDTRTX_EL0. Linux does it via hvc_dcc_init() ---> hvc_dcc_check(),
> and returns -ENODEV in case TXfull bit is still set after writing a test
> character. This way we prevent the guest from making use of HVC DCC as a
> console.
> 
> Signed-off-by: Michal Orzel 
> Signed-off-by: Ayan Kumar Halder 

Acked-by: Julien Grall 

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Tue Mar 12 22:34:02 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Mar 2024 22:34:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692208.1079087 (Exim 4.92)
	(envelope-from )
	id 1rkAh2-00054W-8u; Tue, 12 Mar 2024 22:33:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692208.1079087; Tue, 12 Mar 2024 22:33:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkAh2-00054P-5m; Tue, 12 Mar 2024 22:33:56 +0000
Received: by outflank-mailman (input) for mailman id 692208;
 Tue, 12 Mar 2024 22:33:55 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1rkAh1-00054J-6F
 for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 22:33:55 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkAh0-0005Ml-PI; Tue, 12 Mar 2024 22:33:54 +0000
Received: from gw1.octic.net ([88.97.20.152] helo=[10.0.1.154])
 by xenbits.xenproject.org with esmtpsa
 (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92)
 (envelope-from )
 id 1rkAh0-0000WU-Hp; Tue, 12 Mar 2024 22:33:54 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=Xuqs4VS19SCppjtBHqwvkqmRQwOhWsFXBhEAXtiEhf0=; b=63yNCjM3XFWBczoNSxA7VgrUi6
	tzuVLw+ZNRVxFOh6J2LuKEMhKpgsYjAcgdpi7kLo8ui4eifKOLKnjHkUoxXFqs33R5zIWwOp5XzB4
	hBhekkT7LxRwDBO0YdlAajcIWdWa4WxlR0u8jLpreJJ3/0LTOW7VeI+v3MPszr99TgRE=;
Message-ID: 
Date: Tue, 12 Mar 2024 22:33:52 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN v6 3/3] xen/arm: arm32: Add emulation of Debug Data Transfer
 Registers
Content-Language: en-GB
To: Ayan Kumar Halder ,
 xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org, stefano.stabellini@amd.com,
 Volodymyr_Babchuk@epam.com, bertrand.marquis@arm.com, michal.orzel@amd.com
References: <20240307123943.1991755-1-ayan.kumar.halder@amd.com>
 <20240307123943.1991755-4-ayan.kumar.halder@amd.com>
From: Julien Grall 
In-Reply-To: <20240307123943.1991755-4-ayan.kumar.halder@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Ayan,

On 07/03/2024 12:39, Ayan Kumar Halder wrote:
> When user enables HVC_DCC config option in Linux, it invokes access to debug
> transfer register (i.e. DBGDTRTXINT). As this register is not emulated, Xen
> injects an undefined exception to the guest and Linux crashes.
> 
> To prevent this crash, introduce a partial emulation of DBGDTR[TR]XINT (these
> registers share the same encoding) as RAZ/WI and DBGDSCRINT as TXfull.
> 
> Refer ARM DDI 0487J.a ID042523, G8.3.19, DBGDTRTXint:
> "If TXfull is set to 1, set DTRTX to UNKNOWN".
> 
> As a pre-requisite, DBGOSLSR should be emulated in the same way as its AArch64
> variant (i.e. OSLSR_EL1). This is to ensure that DBGOSLSR.OSLK is 0, which
> allows us to skip the emulation of DBGDSCREXT (TXfull is treated as UNK/SBZP)
> and focus on DBGDSCRINT. DBGOSLSR.OSLM[1] is set to 1 to mantain consistency
> with Arm64.
> 
> Take the opportunity to fix the minimum EL for DBGDSCRINT, which should be 0.

NIT: Strictly speaking Arm32 is using PL (Priviledge) rather than EL 
(Exception Level) to describe each level :).

Anyway,

> 
> Signed-off-by: Ayan Kumar Halder 
> Signed-off-by: Michal Orzel 

Acked-by: Julien Grall 

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Tue Mar 12 22:45:44 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Mar 2024 22:45:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692211.1079097 (Exim 4.92)
	(envelope-from )
	id 1rkAsN-00071n-A3; Tue, 12 Mar 2024 22:45:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692211.1079097; Tue, 12 Mar 2024 22:45:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkAsN-00071g-6E; Tue, 12 Mar 2024 22:45:39 +0000
Received: by outflank-mailman (input) for mailman id 692211;
 Tue, 12 Mar 2024 22:45:37 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1rkAsL-00071a-IR
 for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 22:45:37 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkAsL-0005Y9-AZ; Tue, 12 Mar 2024 22:45:37 +0000
Received: from gw1.octic.net ([88.97.20.152] helo=[10.0.1.154])
 by xenbits.xenproject.org with esmtpsa
 (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92)
 (envelope-from )
 id 1rkAsL-00018u-5O; Tue, 12 Mar 2024 22:45:37 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=gYwp3dnViVB/eN1qzGIIYwSY09T0ajrbpV/Yuj2C0j4=; b=7BBzk+JEWpxjLzHbWCcnluqFfL
	U+wUslOX+NpHlDFal5i/0TNojZXAhxDXiYizxMRMJvtbcWyx9lYf779TiifSW3AJ13WHE71Np4Gu1
	oJHENB+Qh70oAnkrfhK0qLDhcWby3sxx3ljMyzRpsP1SjboJpV6GitJA+ZjTxbYUnemM=;
Message-ID: <30b70df5-a53f-4faa-b15a-1673cceec022@xen.org>
Date: Tue, 12 Mar 2024 22:45:35 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/2] README: bump minimum required clang/llvm version
Content-Language: en-GB
To: Roger Pau Monne , xen-devel@lists.xenproject.org
Cc: Andrew Cooper ,
 George Dunlap , Jan Beulich ,
 Stefano Stabellini , Wei Liu ,
 Doug Goldstein 
References: <20240229095529.17723-1-roger.pau@citrix.com>
 <20240229095529.17723-2-roger.pau@citrix.com>
From: Julien Grall 
In-Reply-To: <20240229095529.17723-2-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Roger,

On 29/02/2024 09:55, Roger Pau Monne wrote:
> We no longer have a way to build with the minimum required clang/llvm version
> stated in the README on the gitlab CI loop, since we dropped the Debian Jessie
> container that had Clang 3.5.0.
> 
> Bump the minimum required Clang/LLVM to the one used in the oldest production
> FreeBSD version (13.2 currently), as that's the main reason I care to maintain
> Clang/LLVM support, and as far as I know FreeBSD is the only production
> deployment of Xen built with Clang/LLVM.
> 
> Purge the build jobs for non-supported Clang versions from Gitlab CI.  Note the
> .dockerfiles for the respective distros are explicitly not adjusted to drop the
> install of the clang packages, or else those jobs would start to fail on older
> Xen branches.
> 
> Signed-off-by: Roger Pau Monné 
> ---
> I'm willing to consider older versions, but there needs to be a reason (iow:
> use-case) for considering those, as maintaining support for older toolchains is
> a burden.

It makes sense. On another thread I mentioned that QEMU also took the 
approach to only support compilers from currently (security?) supported 
distros.

Acked-by: Julien Grall 

This could always be relaxed.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Tue Mar 12 22:45:45 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Mar 2024 22:45:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692212.1079107 (Exim 4.92)
	(envelope-from )
	id 1rkAsQ-0007GO-GJ; Tue, 12 Mar 2024 22:45:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692212.1079107; Tue, 12 Mar 2024 22:45:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkAsQ-0007GH-D0; Tue, 12 Mar 2024 22:45:42 +0000
Received: by outflank-mailman (input) for mailman id 692212;
 Tue, 12 Mar 2024 22:45:41 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkAsP-0007Fz-PU; Tue, 12 Mar 2024 22:45:41 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkAsP-0005YQ-Oh; Tue, 12 Mar 2024 22:45:41 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkAsP-00016l-D1; Tue, 12 Mar 2024 22:45:41 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rkAsP-00014e-C5; Tue, 12 Mar 2024 22:45:41 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=7qhJDPUK5yjzi/azzWfoKjyyOG0AvuODKVwotPZvE28=; b=13+2fFdEctfebV/EUcPQjSp7ba
	hgnEJhcDE6Vi8GotHcO/kHZ2PFxoGRQQYsmh5tBPwamqS3b8daFCETXigjtBXfWSXq0MIlgCHdpBm
	t/J9/dmLazdxvPjXWVUIcmwHiNyI8KKt/KoZTWYCNrgF96nHkZlQp5BXzmcs505bLKo0=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [seabios test] 185005: tolerable FAIL - PUSHED
X-Osstest-Failures:
    seabios:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    seabios:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    seabios:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    seabios:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    seabios:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    seabios:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    seabios:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
X-Osstest-Versions-This:
    seabios=3722c21de19ba64de56495502c0c025b913a9b15
X-Osstest-Versions-That:
    seabios=5d87ff2542c1116e07ae74ba84197a0013e08db1
From: osstest service owner 
Date: Tue, 12 Mar 2024 22:45:41 +0000

flight 185005 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185005/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop            fail like 184988
 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop             fail like 184988
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184988
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop            fail like 184988
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop             fail like 184988
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass

version targeted for testing:
 seabios              3722c21de19ba64de56495502c0c025b913a9b15
baseline version:
 seabios              5d87ff2542c1116e07ae74ba84197a0013e08db1

Last test of basis   184988  2024-03-10 17:11:02 Z    2 days
Testing same since   185005  2024-03-12 14:43:08 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Daniel Verkamp 

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-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/seabios.git
   5d87ff2..3722c21  3722c21de19ba64de56495502c0c025b913a9b15 -> xen-tested-master


From xen-devel-bounces@lists.xenproject.org Tue Mar 12 22:54:59 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Mar 2024 22:54:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692220.1079117 (Exim 4.92)
	(envelope-from )
	id 1rkB1L-00018Y-Fe; Tue, 12 Mar 2024 22:54:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692220.1079117; Tue, 12 Mar 2024 22:54:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkB1L-00018R-Ce; Tue, 12 Mar 2024 22:54:55 +0000
Received: by outflank-mailman (input) for mailman id 692220;
 Tue, 12 Mar 2024 22:54:53 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1rkB1J-00018L-F8
 for xen-devel@lists.xenproject.org; Tue, 12 Mar 2024 22:54:53 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkB1I-0005hm-3K; Tue, 12 Mar 2024 22:54:52 +0000
Received: from gw1.octic.net ([88.97.20.152] helo=[10.0.1.154])
 by xenbits.xenproject.org with esmtpsa
 (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92)
 (envelope-from )
 id 1rkB1H-0001L0-Rs; Tue, 12 Mar 2024 22:54:51 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=+3Plp8OivpTp8tfi0wGJHpcxyXU3r+blrkCifIiIQj4=; b=QacMagjAYTvooNkal8TbaDEWYh
	VxCMKgtIV/4X34c4bMP4Brb6MhosYiIqUF5RM2kVdooGV+HW/WimKtZPdLWDRGwjvI+01eEUFGuWu
	cgwniUQmkMo3N96VFyDUoEYXSFcjjSId3Xnfnt6g0HMBX2vHVpMvqMYMkZKsgkaBsVVM=;
Message-ID: <319d8ffb-624f-43b7-8475-0a8ac93f2f83@xen.org>
Date: Tue, 12 Mar 2024 22:54:50 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 1/3] restrict concept of pIRQ to x86
Content-Language: en-GB
To: Jan Beulich ,
 "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 George Dunlap ,
 Stefano Stabellini , Wei Liu ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Bertrand Marquis ,
 Volodymyr Babchuk 
References: <7cb0d24e-2bda-dcda-4874-2c01ba179947@suse.com>
 
From: Julien Grall 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Jan,

On 27/07/2023 08:38, Jan Beulich wrote:
> ... by way of a new arch-selectable Kconfig control.
> 
> Note that some smaller pieces of code are left without #ifdef, to keep
> things better readable. Hence items like ECS_PIRQ, nr_static_irqs, or
> domain_pirq_to_irq() remain uniformly.
> 
> As to XEN_DOMCTL_irq_permission - this, despite having a uniformly
> available wrapper in libxc, is unused on Arm: libxl bypasses those
> calls, and the Python and OCamL bindings have no users at all.
> 
> Signed-off-by: Jan Beulich 

Sorry for the late reply:

Acked-by: Julien Grall 

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Tue Mar 12 23:41:48 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Mar 2024 23:41:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692224.1079129 (Exim 4.92)
	(envelope-from )
	id 1rkBkU-00083B-QE; Tue, 12 Mar 2024 23:41:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692224.1079129; Tue, 12 Mar 2024 23:41:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkBkU-000834-NM; Tue, 12 Mar 2024 23:41:34 +0000
Received: by outflank-mailman (input) for mailman id 692224;
 Tue, 12 Mar 2024 23:41:34 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkBkU-00082u-1Z; Tue, 12 Mar 2024 23:41:34 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkBkT-0006WB-Sf; Tue, 12 Mar 2024 23:41:33 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkBkT-0005cy-F5; Tue, 12 Mar 2024 23:41:33 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rkBkT-0007QH-EP; Tue, 12 Mar 2024 23:41:33 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=Ms1v3lGK23wbT3KLmJCH+TSjlbX5j5Kor/UV6JaidVw=; b=1u50Z274kNlWE7h85i+wp0F65D
	kVJAsHHVlwJZTAdPejGSawwwRPqyKnJZTsW67tHWwgXHtUgODE584CM6f4VhzRGKbkqDaZ+iKXb0Q
	hAnQAG6AeGBsdc0xXa3AIEHz3PAvXhwx9xI6Om8p7RwDJNbTNVECgleX1BbT/rmksaes=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-4.17-testing test] 185002: tolerable FAIL - PUSHED
X-Osstest-Failures:
    xen-4.17-testing:test-armhf-armhf-xl-credit1:xen-boot:fail:heisenbug
    xen-4.17-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    xen-4.17-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    xen-4.17-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    xen-4.17-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    xen-4.17-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    xen-4.17-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    xen-4.17-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    xen-4.17-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    xen-4.17-testing:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
    xen-4.17-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-amd64-i386-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    xen=1f94117bec55a7b934fed3dfd3529db624eb441f
X-Osstest-Versions-That:
    xen=54dacb5c02cba4676879ed077765734326b78e39
From: osstest service owner 
Date: Tue, 12 Mar 2024 23:41:33 +0000

flight 185002 xen-4.17-testing real [real]
flight 185011 xen-4.17-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/185002/
http://logs.test-lab.xenproject.org/osstest/logs/185011/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-credit1   8 xen-boot            fail pass in 185011-retest

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-credit1 15 migrate-support-check fail in 185011 never pass
 test-armhf-armhf-xl-credit1 16 saverestore-support-check fail in 185011 never pass
 test-armhf-armhf-libvirt     16 saverestore-support-check    fail  like 184909
 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop             fail like 184909
 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop             fail like 184909
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop            fail like 184909
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop            fail like 184909
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop             fail like 184909
 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check   fail like 184909
 test-armhf-armhf-libvirt-raw 15 saverestore-support-check    fail  like 184909
 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop             fail like 184909
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop            fail like 184909
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop            fail like 184909
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184909
 test-amd64-i386-xl-pvshim    14 guest-start                  fail   never pass
 test-amd64-i386-libvirt-xsm  15 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     15 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      15 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass
 test-arm64-arm64-xl          15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      16 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 15 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-multivcpu 15 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-arndale  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  16 saverestore-support-check    fail   never pass
 test-amd64-i386-libvirt-raw  14 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-raw 14 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-raw 15 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-vhd      14 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-vhd      15 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-qcow2 14 migrate-support-check        fail never pass
 test-armhf-armhf-libvirt-raw 14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      15 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  1f94117bec55a7b934fed3dfd3529db624eb441f
baseline version:
 xen                  54dacb5c02cba4676879ed077765734326b78e39

Last test of basis   184909  2024-03-05 11:07:12 Z    7 days
Testing same since   185002  2024-03-12 11:40:22 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich 
  Roger Pau Monné 

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  fail    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-armhf-armhf-libvirt-qcow2                               pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-libvirt-raw                                  pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-arm64-arm64-xl-vhd                                      pass    
 test-armhf-armhf-xl-vhd                                      pass    
 test-amd64-i386-xl-vhd                                       pass    


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

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

Explanation of these 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
   54dacb5c02..1f94117bec  1f94117bec55a7b934fed3dfd3529db624eb441f -> stable-4.17


From xen-devel-bounces@lists.xenproject.org Wed Mar 13 00:28:47 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 00:28:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692231.1079147 (Exim 4.92)
	(envelope-from )
	id 1rkCU4-0005Si-Oj; Wed, 13 Mar 2024 00:28:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692231.1079147; Wed, 13 Mar 2024 00:28:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkCU4-0005Sb-M5; Wed, 13 Mar 2024 00:28:40 +0000
Received: by outflank-mailman (input) for mailman id 692231;
 Wed, 13 Mar 2024 00:28:39 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkCU2-0005SV-Qj
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 00:28:39 +0000
Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a0584eec-e0d0-11ee-a1ee-f123f15fe8a2;
 Wed, 13 Mar 2024 01:28:36 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sin.source.kernel.org (Postfix) with ESMTP id E422CCE172D;
 Wed, 13 Mar 2024 00:28:30 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2A4C1C433C7;
 Wed, 13 Mar 2024 00:28:29 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a0584eec-e0d0-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1710289710;
	bh=VETAQc7mohf8kIx42D/f98f55cEIgZLe8uhKx+/HHMk=;
	h=Date:From:To:cc:Subject:From;
	b=B0S1cAJdjnFAxW73IAjHgtdAiSeXAC8PHzmDsXfh1Nbi5/OF8kFsUrqsYg5PLQwF5
	 1rA7jL57OMStyzXvVeDPa5lrYe1iUH+NGtpOocXtHfgWhx9fI8fvPnD5K+KDshl6Go
	 FF1Go2kIS+kc9aWGpCzqHAcsrTxfBLCl4jjSEnfeTOHXig3dgqBL+9VpEHRWarJr+T
	 JWCBrd88Ao4le+c9/n6/LSKApmgk+7pvzXHE/tdpmOFpk4HPHHKnxIh9+kgPfWAMot
	 AjYUTQrNIEQdBPgtnMyT6D+RFwDsQMBGCvAQbsADstNs8VGSrFZ0nMf/58KFyx8Wfn
	 /xyEpOhOlMmvg==
Date: Tue, 12 Mar 2024 17:28:27 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: xen-devel@lists.xenproject.org
cc: andrew.cooper3@citrix.com, bertrand.marquis@arm.com, jbeulich@suse.com, 
    julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, 
    sstabellini@kernel.org
Subject: [PATCH] docs/misra: add Rule 16.4
Message-ID: 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

Signed-off-by: Stefano Stabellini 
---
I tested the rendered output and it is correct both on the gitlab UI as
well as with tools like rst2html.
---
 docs/misra/rules.rst | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst
index 1e134ccebc..5e9367f11c 100644
--- a/docs/misra/rules.rst
+++ b/docs/misra/rules.rst
@@ -478,6 +478,30 @@ maintainers if you want to suggest a change.
      - In addition to break, also other unconditional flow control statements
        such as continue, return, goto are allowed.
 
+   * - `Rule 16.4 `_
+     - Required
+     - Every switch statement shall have a default label
+     - Switch statements with enums as controlling expression don't need
+       a default label as gcc -Wall enables -Wswitch which warns (and
+       breaks the build) if one of the enum labels is missing from the
+       switch.
+
+       Switch statements with integer types as controlling expression
+       should have a default label:
+
+       - if the switch is expected to handle all possible cases
+         explicitly, then a default label shall be added to handle
+         unexpected error conditions, using BUG(), ASSERT(), WARN(),
+         domain_crash(), or other appropriate methods;
+
+       - if the switch is expected to handle a subset of all
+         possible cases, then a default label shall be added with an
+         in-code comment as follows::
+
+             /* only handle a subset of the possible cases */
+             default:
+                 break;
+
    * - `Rule 16.2 `_
      - Required
      - A switch label shall only be used when the most closely-enclosing
-- 
2.25.1


From xen-devel-bounces@lists.xenproject.org Wed Mar 13 02:34:41 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 02:34:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692244.1079158 (Exim 4.92)
	(envelope-from )
	id 1rkERk-0001O8-9E; Wed, 13 Mar 2024 02:34:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692244.1079158; Wed, 13 Mar 2024 02:34:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkERk-0001O1-4d; Wed, 13 Mar 2024 02:34:24 +0000
Received: by outflank-mailman (input) for mailman id 692244;
 Wed, 13 Mar 2024 02:34:23 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkERj-0001Nr-37; Wed, 13 Mar 2024 02:34:23 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkERi-0000St-Nh; Wed, 13 Mar 2024 02:34:22 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkERi-0000lz-Be; Wed, 13 Mar 2024 02:34:22 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rkERi-00005k-9t; Wed, 13 Mar 2024 02:34:22 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=xaTE/iyBNVRb9eONytJzp0KHrDLcgtexqRCJpQQ2Pqw=; b=2NoUi5PWTvrlUkdIM50qUpzIXd
	3OTk6kzqb+7JERFlPPKMNkIJl2gLwjggQ+hRsIRPPjzZJBQFxC37yc7nDDSybc2Hwlxnh526k+TaY
	fSA8EcFndVc4ckYTQPkTQ76Dds5RpVGqm/4IVb/vHITuc97zfI5sma58qvZ3B2TvYOm8=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [ovmf test] 185008: all pass - PUSHED
X-Osstest-Versions-This:
    ovmf=ddaf39263a1ed84e60238622dfed83ff14ecc50a
X-Osstest-Versions-That:
    ovmf=ccf91b518f22102d446f26320110d30ea0fc1fa9
From: osstest service owner 
Date: Wed, 13 Mar 2024 02:34:22 +0000

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

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

Last test of basis   184943  2024-03-08 09:11:25 Z    4 days
Testing same since   185008  2024-03-12 17:41:21 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Ard Biesheuvel 

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-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   ccf91b518f..ddaf39263a  ddaf39263a1ed84e60238622dfed83ff14ecc50a -> xen-tested-master


From xen-devel-bounces@lists.xenproject.org Wed Mar 13 02:44:24 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 02:44:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692252.1079177 (Exim 4.92)
	(envelope-from )
	id 1rkEbM-00034i-Bb; Wed, 13 Mar 2024 02:44:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692252.1079177; Wed, 13 Mar 2024 02:44:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkEbM-00034b-6t; Wed, 13 Mar 2024 02:44:20 +0000
Received: by outflank-mailman (input) for mailman id 692252;
 Wed, 13 Mar 2024 02:44:19 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkEbL-00034P-6n
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 02:44:19 +0000
Received: from fhigh6-smtp.messagingengine.com
 (fhigh6-smtp.messagingengine.com [103.168.172.157])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 94fe4cff-e0e3-11ee-a1ee-f123f15fe8a2;
 Wed, 13 Mar 2024 03:44:16 +0100 (CET)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.47])
 by mailfhigh.nyi.internal (Postfix) with ESMTP id 47D2511400FD;
 Tue, 12 Mar 2024 22:44:15 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163])
 by compute6.internal (MEProxy); Tue, 12 Mar 2024 22:44:15 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 12 Mar 2024 22:44:14 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 94fe4cff-e0e3-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:content-type:content-type:date:date
	:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to; s=fm1; t=1710297855;
	 x=1710384255; bh=GYRJqn4KcCLAurk+uRzEiVbVlEzim2rxDqmQhCSXp/g=; b=
	VaGCdqb/GObr7WitHItIIUzVUEBR7M9NBf6HrsPOoNKhWH+HmchRBhRTSyvpFc8q
	Gdh3TBH5h5D4DdokskzYnQFUaqIOlsKVlMyPkMEBBHrr7CmZ0bJ4yqd+QMuiRvIG
	Vh0Sq02fRyULoJ2rfIAPhMzNXk15pReWZ4em1NGA8AQBzkW+7I/SxH0yJiqANH7V
	W8V2sGGHP9nd7xBLKay0Dfux+epG8Jkuyy3PpvWQlfwuEZrx8gTraHSbPf3Bw/Kf
	N13Y47onWpE9IrQNnNJcWDM6+6DfZRsfyaaDkUyjv8SURmKntXo5qVHl8qmMTY6r
	8vaOqYaLtrvLsNtjputFWA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:content-type:content-type:date:date
	:feedback-id:feedback-id:from:from:in-reply-to:in-reply-to
	:message-id:mime-version:references:reply-to:subject:subject:to
	:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=
	fm1; t=1710297855; x=1710384255; bh=GYRJqn4KcCLAurk+uRzEiVbVlEzi
	m2rxDqmQhCSXp/g=; b=mkoKLWefoEJIvbcv4FuLjTYq0gAIfk02MOcNiGa4Nsgv
	bGUISszENXOg/3T5OZ8gxKj2Yardx3zCwWEslnz1RdaPRVUwbRLBd1fGLYBq5bdB
	bIsCcFz1OYaWXDRlJCbH2zduXNPQI+SDX8uLv9cZye0F/CqazVheUgjtogEtaQNy
	T/pRYSrWSb3QTYUNg3gsl9wVyoQNwNOnD+UZdcwEAYWAROt6rLmYG1hqk9crdkM4
	V0Q75itz/1Tq//IJUllWGVB20SVNzGsNTczEWdBy86CVEjcGkrsljshZWqDGx19Y
	g4EzQq7QrBHNbu6jVHVP6tkeLu0PUfpYcQRBpW0izA==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrjeeggdehtdcutefuodetggdotefrodftvf
    curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
    uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc
    fjughrpeffhffvuffkfhggtggujgesghdtreertddtjeenucfhrhhomhepffgvmhhiucfo
    rghrihgvucfqsggvnhhouhhruceouggvmhhisehinhhvihhsihgslhgvthhhihhnghhslh
    grsgdrtghomheqnecuggftrfgrthhtvghrnheptdettdeuiedvfeeiudfgjedtuedtleef
    vdeukeeltddugeejvdeiudekfefhueetnecuvehluhhsthgvrhfuihiivgeptdenucfrrg
    hrrghmpehmrghilhhfrhhomhepuggvmhhisehinhhvihhsihgslhgvthhhihhnghhslhgr
    sgdrtghomh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: iac594737:Fastmail
Date: Tue, 12 Mar 2024 22:43:59 -0400
From: Demi Marie Obenour 
To: =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= ,
	Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= ,
	xen-devel 
Subject: Re: Linux 6.7-rc1+: WARNING at drivers/xen/evtchn.c:167
 evtchn_interrupt
Message-ID: 
References: 
 <644eda4c-ca1b-4a1b-bd13-c847df2f4c8e@suse.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="M/79ak0UuVLDckIn"
Content-Disposition: inline
In-Reply-To: <644eda4c-ca1b-4a1b-bd13-c847df2f4c8e@suse.com>


--M/79ak0UuVLDckIn
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Tue, 12 Mar 2024 22:43:59 -0400
From: Demi Marie Obenour 
To: =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= ,
	Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= ,
	xen-devel 
Subject: Re: Linux 6.7-rc1+: WARNING at drivers/xen/evtchn.c:167
 evtchn_interrupt

On Tue, Mar 12, 2024 at 02:10:02PM +0100, Juergen Gross wrote:
> On 30.11.23 03:34, Marek Marczykowski-G=C3=B3recki wrote:
> > Hi,
> >=20
> > While testing 6.7-rc3 on Qubes OS I found several warning like in the
> > subject in dom0 log. I see them when running 6.7-rc1 too. I'm not sure
> > what exactly triggers the issue, but my guess would be unbinding an
> > event channel from userspace (closing vchan connection).
> >=20
> > Specific message:
> >=20
> > [   83.973377] ------------[ cut here ]------------
> > [   83.975523] Interrupt for port 77, but apparently not enabled; per-u=
ser 00000000a0e9f1d1
>=20
> Finally I think I have a fix (thanks to Demi for finding the problematic =
patch
> through bisecting).
>=20
> Could you please try the attached patch? It is based on current upstream,=
 but
> I think it should apply to 6.7 or stable 6.6, too.
>=20
>=20
> Juergen

> From 9d673c37b2d0c9aa274c53f619c4e9e43a419f41 Mon Sep 17 00:00:00 2001
> From: Juergen Gross 
> To: linux-kernel@vger.kernel.org
> Cc: Juergen Gross 
> Cc: Stefano Stabellini 
> Cc: Oleksandr Tyshchenko 
> Cc: xen-devel@lists.xenproject.org
> Date: Tue, 12 Mar 2024 13:52:24 +0100
> Subject: [PATCH] xen/evtchn: avoid WARN() when unbinding an event channel
>=20
> When unbinding a user event channel, the related handler might be
> called a last time in case the kernel was built with
> CONFIG_DEBUG_SHIRQ. This might cause a WARN() in the handler.
>=20
> Avoid that by adding an "unbinding" flag to struct user_event which
> will short circuit the handler.
>=20
> Fixes: 9e90e58c11b7 ("xen: evtchn: Allow shared registration of IRQ hande=
rs")
> Signed-off-by: Juergen Gross 
> ---
>  drivers/xen/evtchn.c | 6 ++++++
>  1 file changed, 6 insertions(+)
>=20
> diff --git a/drivers/xen/evtchn.c b/drivers/xen/evtchn.c
> index 59717628ca42..f6a2216c2c87 100644
> --- a/drivers/xen/evtchn.c
> +++ b/drivers/xen/evtchn.c
> @@ -85,6 +85,7 @@ struct user_evtchn {
>  	struct per_user_data *user;
>  	evtchn_port_t port;
>  	bool enabled;
> +	bool unbinding;
>  };
> =20
>  static void evtchn_free_ring(evtchn_port_t *ring)
> @@ -164,6 +165,10 @@ static irqreturn_t evtchn_interrupt(int irq, void *d=
ata)
>  	struct per_user_data *u =3D evtchn->user;
>  	unsigned int prod, cons;
> =20
> +	/* Handler might be called when tearing down the IRQ. */
> +	if (evtchn->unbinding)
> +		return IRQ_HANDLED;
> +
>  	WARN(!evtchn->enabled,
>  	     "Interrupt for port %u, but apparently not enabled; per-user %p\n",
>  	     evtchn->port, u);
> @@ -421,6 +426,7 @@ static void evtchn_unbind_from_user(struct per_user_d=
ata *u,
> =20
>  	BUG_ON(irq < 0);
> =20
> +	evtchn->unbinding =3D true;
>  	unbind_from_irqhandler(irq, evtchn);
> =20
>  	del_evtchn(u, evtchn);
> --=20
> 2.35.3

That fixes the problem, thanks!  Code looks good to me.

Reported-by: Demi Marie Obenour 
Tested-by: Demi Marie Obenour 
--=20
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab

--M/79ak0UuVLDckIn
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmXxEvwACgkQsoi1X/+c
IsEtYxAA0m0IK++qZ9W5goz39fvkwpoUlZ152rvGM/FEffgXsKIKzWs8vmaqD3tI
+flfjc0daq7ZxBqkRkqpL0J19pKsp7ih6lZc9/Av60v4YLHfNzMky+j4LiwpAgpf
swIDruBY43aqnI0ma0DxJY00nsAn30rGvn/h+45ulGN7VVXFborXEwPF1RnWxtWj
wBCAEVIEY6AMP06QmzeFp/sHlhlf0+K9kSeilAj/mb3yYRrWP//2ANJ8a9W0+LUc
O/g7iFuzj7nm6swCuMUe6fuFj0+x+yGTNgsa28gGusDw7jaExfYUnMJZzcfix7Uv
FkzcVggyf9T1HuKlvkTQItZbvVdj4EIrXnj7tRtNlIZBgshqENQ+2bGk5FYwQcs5
QswpDRg2aFrksHBnwRgSmzh/6SOsoSpvnGBMCRVl1df2w8BF47zEGo0vezHAghiA
c1QkKb2dtyLrX5fOzC7M/KE5zoRevO5Ka3WkzQZQcKAI7qW+XYydj6hGAuxxNbZv
URrZUZtzTocvGUeybEdMptkMukqGPFMkMuULKWHLOymfNwrW9R2pHN6gkVkp5DQO
g+o888tk/i8DlJUw59N+ctk48gP2FpPCyeENviGif/5MJGMj/fReZDNBHXmMH2uq
OGn8LiWbyK9CPK5Fjs7MxE9LQZtJc5ra6iBJgtozw8eyPtKGwCg=
=Qwf8
-----END PGP SIGNATURE-----

--M/79ak0UuVLDckIn--


From xen-devel-bounces@lists.xenproject.org Wed Mar 13 02:49:46 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 02:49:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692254.1079186 (Exim 4.92)
	(envelope-from )
	id 1rkEgV-0003mJ-TL; Wed, 13 Mar 2024 02:49:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692254.1079186; Wed, 13 Mar 2024 02:49:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkEgV-0003mC-QY; Wed, 13 Mar 2024 02:49:39 +0000
Received: by outflank-mailman (input) for mailman id 692254;
 Wed, 13 Mar 2024 02:49:38 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkEgU-0003m2-M8; Wed, 13 Mar 2024 02:49:38 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkEgU-0000iQ-FK; Wed, 13 Mar 2024 02:49:38 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkEgU-0001Qm-3V; Wed, 13 Mar 2024 02:49:38 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rkEgU-0000YG-35; Wed, 13 Mar 2024 02:49:38 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=f98Vv9VxUV2atEo99VqwWr372uKG2guGscISvKXHGW8=; b=TFJX9NfKZLWIZP/TtyYiW7IquH
	fM6EN7Tch7em6jKc/TIGs7pyFvdoeyiEb8hXuO74pwrMxDs8C3uuUFvXyk2YKJGunwY70cwISaqOO
	D4HujuBEt2bpkWTrbSu3B23trFDl9K9IdiRtg8Cr08Ah06eZ4dv9hSIQeQlwTQv8+pjs=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-4.18-testing test] 185003: tolerable FAIL - PUSHED
X-Osstest-Failures:
    xen-4.18-testing:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:heisenbug
    xen-4.18-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    xen-4.18-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    xen-4.18-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    xen-4.18-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-i386-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    xen=a96d2d4355d85fc82abd0a3799978db04ee8cff3
X-Osstest-Versions-That:
    xen=fd7cb7a1d0433049d8fc59444d0e91b71728763e
From: osstest service owner 
Date: Wed, 13 Mar 2024 02:49:38 +0000

flight 185003 xen-4.18-testing real [real]
flight 185013 xen-4.18-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/185003/
http://logs.test-lab.xenproject.org/osstest/logs/185013/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 12 debian-hvm-install fail pass in 185013-retest

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

version targeted for testing:
 xen                  a96d2d4355d85fc82abd0a3799978db04ee8cff3
baseline version:
 xen                  fd7cb7a1d0433049d8fc59444d0e91b71728763e

Last test of basis   184910  2024-03-05 11:07:13 Z    7 days
Testing same since   185003  2024-03-12 11:40:22 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich 
  Roger Pau Monné 

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  fail    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-armhf-armhf-libvirt-qcow2                               pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-libvirt-raw                                  pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-arm64-arm64-xl-vhd                                      pass    
 test-armhf-armhf-xl-vhd                                      pass    
 test-amd64-i386-xl-vhd                                       pass    


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

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

Explanation of these 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
   fd7cb7a1d0..a96d2d4355  a96d2d4355d85fc82abd0a3799978db04ee8cff3 -> stable-4.18


From xen-devel-bounces@lists.xenproject.org Wed Mar 13 04:20:21 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 04:20:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692264.1079197 (Exim 4.92)
	(envelope-from )
	id 1rkG62-0006Mi-IJ; Wed, 13 Mar 2024 04:20:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692264.1079197; Wed, 13 Mar 2024 04:20:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkG62-0006Mb-Cn; Wed, 13 Mar 2024 04:20:06 +0000
Received: by outflank-mailman (input) for mailman id 692264;
 Wed, 13 Mar 2024 04:20:05 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkG61-0006Db-9A; Wed, 13 Mar 2024 04:20:05 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkG61-0002UZ-4A; Wed, 13 Mar 2024 04:20:05 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkG60-0007WR-Px; Wed, 13 Mar 2024 04:20:04 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rkG60-0007Bn-PH; Wed, 13 Mar 2024 04:20:04 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=dEMPjD3WgqPxQ9Zp857Y5giueahLNPKg0sQdV8N2uXg=; b=noExbsEC42Ygb0MnCQas8OvY1p
	82E88E7oNSB2HB1ivPrTvdGF72zNVrYE8gUzFB8dPoePAdAAb4ZmOAdM28RRV3h1lIB0pj3YA6Awj
	z4TIb582IfkiIRTKqd1aPHbek8iVw+j9GJHJz3V/5ySSTBcqZT/yy0hBFFZYjtTQvRnk=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 185004: tolerable FAIL - PUSHED
X-Osstest-Failures:
    linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    linux=855684c7d938c2442f07eabc154e7532b4c1fbf9
X-Osstest-Versions-That:
    linux=0f1a876682f0979d6a1e5f86861dd562d1758936
From: osstest service owner 
Date: Wed, 13 Mar 2024 04:20:04 +0000

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

Failures :-/ but no regressions.

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

version targeted for testing:
 linux                855684c7d938c2442f07eabc154e7532b4c1fbf9
baseline version:
 linux                0f1a876682f0979d6a1e5f86861dd562d1758936

Last test of basis   184997  2024-03-11 18:40:47 Z    1 days
Testing same since   185000  2024-03-12 06:31:53 Z    0 days    2 attempts

------------------------------------------------------------
People who touched revisions under test:
  
  
  
  Alex Shi 
  Alexander Mikhalitsyn 
  Alexey Dobriyan 
  Alexey Kardashevskiy 
  Alice Ryhl 
  Allen Pais 
  Allen Pais 
  Anders Roxell 
  Andrea Righi 
  Andy Shevchenko 
  Anna-Maria Behnsen 
  Anup Patel 
  Ard Biesheuvel 
  Arnd Bergmann 
  Ashish Kalra 
  Audra Mitchell 
  Babu Moger 
  Bartosz Golaszewski 
  Bibo Mao 
  Biju Das 
  Björn Töpel 
  Boqun Feng 
  Borislav Petkov (AMD) 
  Brendan Jackman 
  Breno Leitao 
  Brijesh Singh 
  Carl Worth  # arm64
  Changbin Du 
  Changhuang Liang 
  Charalampos Mitrodimas 
  Chen Zhongjin 
  Chengming Zhou 
  Chinmay Gameti 
  Christoph Böhmwalder 
  Christoph Hellwig 
  Christophe JAILLET 
  Chun-Yi Lee 
  Colin Ian King 
  Conor Dooley 
  Costa Shulyupin 
  Crystal Wood 
  Damien Le Moal 
  Dan Carpenter 
  Daniel Micay 
  Dave Hansen 
  Dave Hansen 
  David Gow 
  David Vernet 
  Dawei Li 
  Dionna Glaze 
  Dirk Behme 
  Dmitry Baryshkov 
  Erick Archer 
  Feng Tang 
  Frederic Weisbecker 
  Gabriel Krisman Bertazi 
  Geert Uytterhoeven 
  Greg Edwards 
  Greg Kroah-Hartman 
  Gregory CLEMENT 
  Gui-Dong Han <2045gemini@gmail.com>
  Guilherme Amadio 
  Guixin Liu 
  Guo Ren 
  H. Peter Anvin (Intel) 
  Hannes Reinecke 
  Heiko Carstens 
  Heming Zhao 
  Huacai Chen 
  Huqiang Qin 
  Ingo Molnar 
  Jack Wang 
  Jakub Kicinski 
  James Morse 
  Jan Höppner 
  Jarkko Sakkinen 
  Jens Axboe 
  Jin Wang 
  Jiri Kosina 
  Joel Fernandes (Google) 
  Joerg Roedel 
  Johannes Thumshirn 
  John Garry 
  John Stultz 
  Josh Poimboeuf 
  Juergen Gross 
  Julia Lawall 
  Juri Lelli 
  K Prateek Nayak 
  Kai Huang 
  Kanchan Joshi 
  Kees Cook 
  Keisuke Nishimura 
  Keith Busch 
  Kevin Loughlin 
  Kim Phillips 
  Kirill A. Shutemov 
  Kuniyuki Iwashima 
  Kunwu Chan 
  Lai Jiangshan 
  Leonardo Bras 
  Li kunyu 
  Li Lingfeng 
  Li Nan 
  Li zeming 
  Li Zhijian 
  Lili Li 
  Linus Torvalds 
  Luc Van Oostenryck 
  Maninder Singh 
  Marc Orr 
  Marc Zyngier 
  Marcelo Tosatti 
  Marek Szyprowski 
  Mark Rutland 
  Masahiro Yamada 
  Masami Hiramatsu (Google) 
  Matt Gilbride 
  Max Gurtovoy 
  Max Kellermann 
  Michael Kelley 
  Michael Roth 
  Miguel Ojeda 
  Mika Westerberg 
  Mike Snitzer 
  Ming Lei 
  Miroslav Franc 
  Muhammad Usama Anjum 
  Muralidhara M K 
  Nadav Amit 
  Namhyung Kim 
  Nathan Chancellor 
  Navid Emamdoost 
  Nikolay Borisov 
  Nilay Shroff 
  Obei Sideg 
  Oleg Nesterov 
  Onkarnath 
  Paolo Bonzini 
  Paul E. McKenney 
  Paul Luse 
  Pavel Begunkov 
  Pawan Gupta 
  Peng Liu 
  Peter Hilber 
  Peter Newman 
  Peter Zijlstra (Intel) 
  Peter Zijlstra (Intel) 
  Qais Yousef (Google) 
  Qais Yousef 
  Qiuxu Zhuo 
  Rafael J. Wysocki 
  Randy Dunlap 
  Ravi Bangoria 
  Reinette Chatre 
  Reinette Chatre  # for resctrl dependency
  Ricardo B. Marliere 
  Ricardo Neri 
  Richard Cochran (linutronix GmbH) 
  Rick Edgecombe 
  Roger Pau Monné 
  Roman Smirnov 
  Sergey Senozhatsky 
  Shan Kang 
  Shaopeng Tan 
  Shin'ichiro Kawasaki 
  Shrikanth Hegde 
  Shrikanth Hegde 
  Shubhrajyoti Datta 
  Sohil Mehta 
  Song Liu 
  Stefan Haberland 
  Stefan Roesch 
  Steven Rostedt (Google) 
  Tang Yizhou 
  Tejun Heo 
  Thomas Bertschinger 
  Thomas Gleixner 
  Thomas Weißschuh 
  Thomas Zimmermann 
  Tom Lendacky 
  Tony Battersby 
  Tony Luck 
  Tony Solomonik 
  Ulf Hansson 
  Uros Bizjak 
  Uwe Kleine-König 
  Valentin Obst 
  Virgile Andreani 
  Vlastimil Babka 
  Waiman Long 
  Wang Jinchao 
  Wang Wendy 
  Wedson Almeida Filho 
  Xiao Ni 
  Xiaobing Li 
  Xiaochen Shen 
  Xin Li (Intel) 
  Xin Li 
  Xinyu Li 
  Xiongwei Song 
  Xuewen Yan 
  Yang Jihong 
  Yangtao Li 
  Yazen Ghannam 
  Yu Chien Peter Lin 
  Yu Kuai 
  Yury Norov 
  Yutaro Ohno 
  Zhang Rui 
  Zqiang 

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-freebsd11-amd64                             pass    
 test-amd64-amd64-freebsd12-amd64                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-libvirt-qcow2                               pass    
 test-armhf-armhf-libvirt-qcow2                               pass    
 test-amd64-amd64-libvirt-raw                                 pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-amd64-xl-vhd                                      pass    
 test-arm64-arm64-xl-vhd                                      pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

Explanation of these 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 :

hint: The 'hooks/update' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
hint: The 'hooks/post-receive' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
hint: The 'hooks/post-update' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
To xenbits.xen.org:/home/xen/git/linux-pvops.git
   0f1a876682f09..855684c7d938c  855684c7d938c2442f07eabc154e7532b4c1fbf9 -> tested/linux-linus


From xen-devel-bounces@lists.xenproject.org Wed Mar 13 06:07:00 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 06:07:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692269.1079205 (Exim 4.92)
	(envelope-from )
	id 1rkHlE-0000jE-04; Wed, 13 Mar 2024 06:06:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692269.1079205; Wed, 13 Mar 2024 06:06:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkHlD-0000j7-TD; Wed, 13 Mar 2024 06:06:43 +0000
Received: by outflank-mailman (input) for mailman id 692269;
 Wed, 13 Mar 2024 06:06:42 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkHlC-0000j1-KC
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 06:06:42 +0000
Received: from mail.zytor.com (unknown [2607:7c80:54:3::138])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d9c364c9-e0ff-11ee-afdd-a90da7624cb6;
 Wed, 13 Mar 2024 07:06:39 +0100 (CET)
Received: from terminus.zytor.com (terminus.zytor.com
 [IPv6:2607:7c80:54:3:0:0:0:136]) (authenticated bits=0)
 by mail.zytor.com (8.17.2/8.17.1) with ESMTPSA id 42D65lI31952906
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
 Tue, 12 Mar 2024 23:05:52 -0700
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d9c364c9-e0ff-11ee-afdd-a90da7624cb6
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 42D65lI31952906
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com;
	s=2024021201; t=1710309953;
	bh=6cPXc90ChYXIeVgs/NUEWiqMXh5ugp4gEBYa/cJtbTY=;
	h=From:To:Cc:Subject:Date:From;
	b=iOsC/GAT/90KVoDQdNzwFM/vBtWWFweJld8q6upxGorAIhuGrZGjPkh5rCiNTiHUz
	 jQfUcQuAdvSskKyMe7Vm2RmxGSUYDhGyTzwRsbhnHdDGJ6/fBfj7oV182UkFV9GAMZ
	 WrWwSTSqhzWI/9n27k8LXMIqrH2+E+pQV7T3ygeWLiqsDN2f9xSJI/WXlkeP1KkAEP
	 L8mgFf9t2SXEoUYtO7oCXNhFcNvlmMlnrDNNLLjMMa2l37w+vf/Ze6ttP8g3y5BOQy
	 eY6iDzE0cuOGIjwkr1FRDyq5wTj+MFW7bBSBbi5MRSdVhycB8bZwyoPP1G1OwHICNt
	 ZUOSYxZJduBLg==
From: "Xin Li (Intel)" 
To: linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
        linux-arch@vger.kernel.org
Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de,
        dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com,
        jgross@suse.com, boris.ostrovsky@oracle.com, arnd@arndb.de
Subject: [PATCH v1 1/1] x86: Rename __{start,end}_init_task to __{start,end}_init_stack
Date: Tue, 12 Mar 2024 23:05:46 -0700
Message-ID: <20240313060546.1952893-1-xin@zytor.com>
X-Mailer: git-send-email 2.44.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

The stack of a task has been separated from the memory of a task_struct
struture for a long time on x86, as a result __{start,end}_init_task no
longer mark the start and end of the init_task structure, but its stack
only.

Rename __{start,end}_init_task to __{start,end}_init_stack.

Note other architectures are not affected because __{start,end}_init_task
are used on x86 only.

Signed-off-by: Xin Li (Intel) 
---
 arch/x86/include/asm/processor.h  | 4 ++--
 arch/x86/kernel/head_64.S         | 2 +-
 arch/x86/xen/xen-head.S           | 2 +-
 include/asm-generic/vmlinux.lds.h | 8 ++++----
 4 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 811548f131f4..8b3a3f3bb859 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -636,10 +636,10 @@ static __always_inline void prefetchw(const void *x)
 #define KSTK_ESP(task)		(task_pt_regs(task)->sp)
 
 #else
-extern unsigned long __end_init_task[];
+extern unsigned long __end_init_stack[];
 
 #define INIT_THREAD {							\
-	.sp	= (unsigned long)&__end_init_task -			\
+	.sp	= (unsigned long)&__end_init_stack -			\
 		  TOP_OF_KERNEL_STACK_PADDING -				\
 		  sizeof(struct pt_regs),				\
 }
diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
index d8198fbd70e5..c7babd7ebb0f 100644
--- a/arch/x86/kernel/head_64.S
+++ b/arch/x86/kernel/head_64.S
@@ -66,7 +66,7 @@ SYM_CODE_START_NOALIGN(startup_64)
 	mov	%rsi, %r15
 
 	/* Set up the stack for verify_cpu() */
-	leaq	(__end_init_task - TOP_OF_KERNEL_STACK_PADDING - PTREGS_SIZE)(%rip), %rsp
+	leaq	(__end_init_stack - TOP_OF_KERNEL_STACK_PADDING - PTREGS_SIZE)(%rip), %rsp
 
 	/* Setup GSBASE to allow stack canary access for C code */
 	movl	$MSR_GS_BASE, %ecx
diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
index 04101b984f24..43eadf03f46d 100644
--- a/arch/x86/xen/xen-head.S
+++ b/arch/x86/xen/xen-head.S
@@ -49,7 +49,7 @@ SYM_CODE_START(startup_xen)
 	ANNOTATE_NOENDBR
 	cld
 
-	leaq	(__end_init_task - TOP_OF_KERNEL_STACK_PADDING - PTREGS_SIZE)(%rip), %rsp
+	leaq	(__end_init_stack - TOP_OF_KERNEL_STACK_PADDING - PTREGS_SIZE)(%rip), %rsp
 
 	/* Set up %gs.
 	 *
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 5dd3a61d673d..a168be99d522 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -399,13 +399,13 @@
 
 #define INIT_TASK_DATA(align)						\
 	. = ALIGN(align);						\
-	__start_init_task = .;						\
+	__start_init_stack = .;						\
 	init_thread_union = .;						\
 	init_stack = .;							\
-	KEEP(*(.data..init_task))					\
+	KEEP(*(.data..init_stack))					\
 	KEEP(*(.data..init_thread_info))				\
-	. = __start_init_task + THREAD_SIZE;				\
-	__end_init_task = .;
+	. = __start_init_stack + THREAD_SIZE;				\
+	__end_init_stack = .;
 
 #define JUMP_TABLE_DATA							\
 	. = ALIGN(8);							\

base-commit: 626856ae97054963e7b8c35335d4418271c8d0c4
-- 
2.44.0



From xen-devel-bounces@lists.xenproject.org Wed Mar 13 07:10:16 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 07:10:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692274.1079216 (Exim 4.92)
	(envelope-from )
	id 1rkIkS-0007xD-FL; Wed, 13 Mar 2024 07:10:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692274.1079216; Wed, 13 Mar 2024 07:10:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkIkS-0007x6-Ch; Wed, 13 Mar 2024 07:10:00 +0000
Received: by outflank-mailman (input) for mailman id 692274;
 Wed, 13 Mar 2024 07:09:59 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkIkR-0007x0-3x
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 07:09:59 +0000
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com
 [2a00:1450:4864:20::529])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b2f619f1-e108-11ee-afdd-a90da7624cb6;
 Wed, 13 Mar 2024 08:09:57 +0100 (CET)
Received: by mail-ed1-x529.google.com with SMTP id
 4fb4d7f45d1cf-5684073ab38so1021343a12.0
 for ; Wed, 13 Mar 2024 00:09:57 -0700 (PDT)
Received: from ?IPV6:2003:e5:873a:400:704b:6dbb:e7c0:786e?
 (p200300e5873a0400704b6dbbe7c0786e.dip0.t-ipconnect.de.
 [2003:e5:873a:400:704b:6dbb:e7c0:786e])
 by smtp.gmail.com with ESMTPSA id
 n21-20020a05640205d500b0056884feacd4sm381463edx.39.2024.03.13.00.09.55
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 13 Mar 2024 00:09:56 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b2f619f1-e108-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710313797; x=1710918597; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:references:cc:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=VFM7NHjFeiFIkXrKy4Ve+I5tMlDvoiqgvY2hf19yC/M=;
        b=Qa/A+0EkjhEyWhDvIGJlYI1yqPnhbXvmVBuXpW2IMmmWEPdKCd7FbuWt5qLSk6MRYl
         mP6vIcAPVQAw7sPjRmvAJMsc44b/1Rja9FoY5qodtc28gEdXOutFdfQV1jiURGUvHwOk
         zoAbuhLAYNZ2K4dKAvMovIFCTmab3OQV6iCrO/HxSHRYrABKmcxnzMtRs32/jAvC+dfh
         auhg/NmnkgL6pjFnK2vtXNoN3N5gwceuGjFPrdRdt/ee2jKXtazM6QNeTRAQZMVLofbS
         oxpNW3K9RUz4uW1leGLOgaa7RCQA83qfS4OPccezUDRp1ozdinbbA28d3JspgxkAPrhZ
         NnGg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710313797; x=1710918597;
        h=content-transfer-encoding:in-reply-to:from:references:cc:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=VFM7NHjFeiFIkXrKy4Ve+I5tMlDvoiqgvY2hf19yC/M=;
        b=OYC3foD9KzfBOPkV8Ufw5CLoH/ZsjAsVJmCqp2buqphuFsBBrMoPFeVm8S3RdcIWTv
         5BwCoXnmmWTwcjGWmszflvsTzY8o/2OaYWVicrDp12/eveK4zhj17wdMDpCIottdaNfP
         JjML4Kvt083U+zWgNUuU85hJqdPCIytmNAGMdhqCCtdnheMsQ9IoQfSd3YddTCOs2607
         cI1+RbYHU1GqTvMg1svSNhtoH7US8D/By31mJRMiuy6WGQkmhBkV5pIuPBTTewHglYTB
         96ldzpcTPCN2DSez0tUI05rQ22xnVtKP2r/xYK4WyqXpME9T3wpGMuSh0Zah1J9oUzgj
         J22A==
X-Forwarded-Encrypted: i=1; AJvYcCUoeAf/UNFt4B4YTVRXx39SyJAoGPKCqp667/2ub39Nd5KkPL4OObMYtl2VRHHfdBiieZry8gMsZpRo4AuNkgFUbGbs8WcV+0K4kAKFSgE=
X-Gm-Message-State: AOJu0Yx6UIFemsjZ1gmt71EtXxEW/4IMXlTVxglI5tzTJcDZgjB2WG3A
	W1Smi6IjYy2e3NJKMcXw7/Z847KTOeRFU4ZF7C5nhTS+ZRAw5dqhzhR7DAWYLdk=
X-Google-Smtp-Source: AGHT+IFe/fyuKeyjO4QV1x01xdRBrc72d4UA/whVUFl6wfKoaLR7gJ9oQQHnXlmLUa47VVYaHB/K8g==
X-Received: by 2002:a50:9b58:0:b0:567:e0e:dda5 with SMTP id a24-20020a509b58000000b005670e0edda5mr1632316edj.17.1710313796845;
        Wed, 13 Mar 2024 00:09:56 -0700 (PDT)
Message-ID: 
Date: Wed, 13 Mar 2024 08:09:55 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 1/1] x86: Rename __{start,end}_init_task to
 __{start,end}_init_stack
Content-Language: en-US
To: "Xin Li (Intel)" , linux-kernel@vger.kernel.org,
 xen-devel@lists.xenproject.org, linux-arch@vger.kernel.org
Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de,
 dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com,
 boris.ostrovsky@oracle.com, arnd@arndb.de
References: <20240313060546.1952893-1-xin@zytor.com>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
In-Reply-To: <20240313060546.1952893-1-xin@zytor.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 13.03.24 07:05, Xin Li (Intel) wrote:
> The stack of a task has been separated from the memory of a task_struct
> struture for a long time on x86, as a result __{start,end}_init_task no
> longer mark the start and end of the init_task structure, but its stack
> only.
> 
> Rename __{start,end}_init_task to __{start,end}_init_stack.
> 
> Note other architectures are not affected because __{start,end}_init_task
> are used on x86 only.
> 
> Signed-off-by: Xin Li (Intel) 
> ---
>   arch/x86/include/asm/processor.h  | 4 ++--
>   arch/x86/kernel/head_64.S         | 2 +-
>   arch/x86/xen/xen-head.S           | 2 +-
>   include/asm-generic/vmlinux.lds.h | 8 ++++----
>   4 files changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
> index 811548f131f4..8b3a3f3bb859 100644
> --- a/arch/x86/include/asm/processor.h
> +++ b/arch/x86/include/asm/processor.h
> @@ -636,10 +636,10 @@ static __always_inline void prefetchw(const void *x)
>   #define KSTK_ESP(task)		(task_pt_regs(task)->sp)
>   
>   #else
> -extern unsigned long __end_init_task[];
> +extern unsigned long __end_init_stack[];
>   
>   #define INIT_THREAD {							\
> -	.sp	= (unsigned long)&__end_init_task -			\
> +	.sp	= (unsigned long)&__end_init_stack -			\
>   		  TOP_OF_KERNEL_STACK_PADDING -				\
>   		  sizeof(struct pt_regs),				\
>   }
> diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
> index d8198fbd70e5..c7babd7ebb0f 100644
> --- a/arch/x86/kernel/head_64.S
> +++ b/arch/x86/kernel/head_64.S
> @@ -66,7 +66,7 @@ SYM_CODE_START_NOALIGN(startup_64)
>   	mov	%rsi, %r15
>   
>   	/* Set up the stack for verify_cpu() */
> -	leaq	(__end_init_task - TOP_OF_KERNEL_STACK_PADDING - PTREGS_SIZE)(%rip), %rsp
> +	leaq	(__end_init_stack - TOP_OF_KERNEL_STACK_PADDING - PTREGS_SIZE)(%rip), %rsp
>   
>   	/* Setup GSBASE to allow stack canary access for C code */
>   	movl	$MSR_GS_BASE, %ecx
> diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
> index 04101b984f24..43eadf03f46d 100644
> --- a/arch/x86/xen/xen-head.S
> +++ b/arch/x86/xen/xen-head.S
> @@ -49,7 +49,7 @@ SYM_CODE_START(startup_xen)
>   	ANNOTATE_NOENDBR
>   	cld
>   
> -	leaq	(__end_init_task - TOP_OF_KERNEL_STACK_PADDING - PTREGS_SIZE)(%rip), %rsp
> +	leaq	(__end_init_stack - TOP_OF_KERNEL_STACK_PADDING - PTREGS_SIZE)(%rip), %rsp
>   
>   	/* Set up %gs.
>   	 *
> diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
> index 5dd3a61d673d..a168be99d522 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -399,13 +399,13 @@
>   
>   #define INIT_TASK_DATA(align)						\
>   	. = ALIGN(align);						\
> -	__start_init_task = .;						\
> +	__start_init_stack = .;						\
>   	init_thread_union = .;						\
>   	init_stack = .;							\
> -	KEEP(*(.data..init_task))					\
> +	KEEP(*(.data..init_stack))					\

Is this modification really correct?

>   	KEEP(*(.data..init_thread_info))				\
> -	. = __start_init_task + THREAD_SIZE;				\
> -	__end_init_task = .;
> +	. = __start_init_stack + THREAD_SIZE;				\
> +	__end_init_stack = .;
>   
>   #define JUMP_TABLE_DATA							\
>   	. = ALIGN(8);							\
> 
> base-commit: 626856ae97054963e7b8c35335d4418271c8d0c4


Juergen



From xen-devel-bounces@lists.xenproject.org Wed Mar 13 07:14:16 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 07:14:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692277.1079226 (Exim 4.92)
	(envelope-from )
	id 1rkIoa-0000xy-0W; Wed, 13 Mar 2024 07:14:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692277.1079226; Wed, 13 Mar 2024 07:14:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkIoZ-0000xr-TN; Wed, 13 Mar 2024 07:14:15 +0000
Received: by outflank-mailman (input) for mailman id 692277;
 Wed, 13 Mar 2024 07:14:15 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkIoY-0000xl-Vk
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 07:14:15 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4bc73979-e109-11ee-afdd-a90da7624cb6;
 Wed, 13 Mar 2024 08:14:14 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org
 [IPv6:2a07:de40:b281:104:10:150:64:97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id 0A64F21B98;
 Wed, 13 Mar 2024 07:14:13 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id BAFCB13977;
 Wed, 13 Mar 2024 07:14:12 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id kyWaK0RS8WWlSAAAD6G6ig
 (envelope-from ); Wed, 13 Mar 2024 07:14:12 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4bc73979-e109-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1710314053; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:  content-transfer-encoding:content-transfer-encoding;
	bh=kxMz5wRYRts6SEKGqAGBVkV0rkhnV3B7oQVvSfAgUd8=;
	b=nj8Bne9hJ+j5/yvQm/rexgklUlFOuMukRu3zd6VSc+1L5d3a/L4osnKJ3W0+g8SaTHiXNH
	Rs7oux9FA9GDxamk3jtETc2hlMzVyZ6gZY31Hs0C/csnKfO5xrkmYdU7vbrVDljMiogmiu
	TPzwDSOY9Q5oJO4d+VI2AVn8pBh6lIw=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1710314053; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:  content-transfer-encoding:content-transfer-encoding;
	bh=kxMz5wRYRts6SEKGqAGBVkV0rkhnV3B7oQVvSfAgUd8=;
	b=nj8Bne9hJ+j5/yvQm/rexgklUlFOuMukRu3zd6VSc+1L5d3a/L4osnKJ3W0+g8SaTHiXNH
	Rs7oux9FA9GDxamk3jtETc2hlMzVyZ6gZY31Hs0C/csnKfO5xrkmYdU7vbrVDljMiogmiu
	TPzwDSOY9Q5oJO4d+VI2AVn8pBh6lIw=
From: Juergen Gross 
To: linux-kernel@vger.kernel.org
Cc: Juergen Gross ,
	Stefano Stabellini ,
	Oleksandr Tyshchenko ,
	xen-devel@lists.xenproject.org
Subject: [PATCH 0/2] xen: two fixes related to event channels
Date: Wed, 13 Mar 2024 08:14:07 +0100
Message-Id: <20240313071409.25913-1-jgross@suse.com>
X-Mailer: git-send-email 2.35.3
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spamd-Bar: ++++
Authentication-Results: smtp-out1.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b=nj8Bne9h
X-Spamd-Result: default: False [4.66 / 50.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_MISSING_CHARSET(2.50)[];
	 BROKEN_CONTENT_TYPE(1.50)[];
	 RCPT_COUNT_FIVE(0.00)[5];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_TRACE(0.00)[suse.com:+];
	 MX_GOOD(-0.01)[];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 BAYES_HAM(-0.03)[56.12%];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[suse.com:s=susede1];
	 URIBL_BLOCKED(0.00)[suse.com:dkim];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 DKIM_SIGNED(0.00)[suse.com:s=susede1];
	 MID_CONTAINS_FROM(1.00)[];
	 DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:dkim];
	 FUZZY_BLOCKED(0.00)[rspamd.com];
	 RCVD_TLS_ALL(0.00)[];
	 RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:104:10:150:64:97:from]
X-Spam-Score: 4.66
X-Spam-Level: ****
X-Rspamd-Queue-Id: 0A64F21B98
X-Spam-Flag: NO
X-Rspamd-Server: rspamd1.dmz-prg2.suse.org

Two patches fixing one seen problem and another potential one. Both
have been introduced in the 6.7 kernel.

Juergen Gross (2):
  xen/evtchn: avoid WARN() when unbinding an event channel
  xen/events: increment refcnt only if event channel is refcounted

 drivers/xen/events/events_base.c | 22 +++++++++++++---------
 drivers/xen/evtchn.c             |  6 ++++++
 2 files changed, 19 insertions(+), 9 deletions(-)

-- 
2.35.3



From xen-devel-bounces@lists.xenproject.org Wed Mar 13 07:14:21 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 07:14:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692278.1079235 (Exim 4.92)
	(envelope-from )
	id 1rkIof-0001E4-5t; Wed, 13 Mar 2024 07:14:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692278.1079235; Wed, 13 Mar 2024 07:14:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkIof-0001Dx-3Q; Wed, 13 Mar 2024 07:14:21 +0000
Received: by outflank-mailman (input) for mailman id 692278;
 Wed, 13 Mar 2024 07:14:19 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkIod-0000xl-R7
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 07:14:19 +0000
Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4ef42c99-e109-11ee-afdd-a90da7624cb6;
 Wed, 13 Mar 2024 08:14:19 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org
 [IPv6:2a07:de40:b281:104:10:150:64:97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out2.suse.de (Postfix) with ESMTPS id A14D61F7A4;
 Wed, 13 Mar 2024 07:14:18 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 6A3CF13977;
 Wed, 13 Mar 2024 07:14:18 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id i4BMGEpS8WWtSAAAD6G6ig
 (envelope-from ); Wed, 13 Mar 2024 07:14:18 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4ef42c99-e109-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1710314058; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=pOrIQxEHvyyL2+vnTct/YehpC03sIRKTsXlKpP1po1Y=;
	b=rdFQ6nU0hMG5OoHLPrOIQAHfUkxhtZt0ph2a1H8aFLDj9OPEQzCRc3LkMIMw//1AcSV+IP
	iyD+rfzi1cV43KLqpVhnklc7ySFYXh9bH5bKokJR0jo9CoVEuuyFy4iT0PN3I+pJZADBK/
	SkPc6iMRPcobbOQ7U6Ginn1pqF9Es34=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1710314058; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=pOrIQxEHvyyL2+vnTct/YehpC03sIRKTsXlKpP1po1Y=;
	b=rdFQ6nU0hMG5OoHLPrOIQAHfUkxhtZt0ph2a1H8aFLDj9OPEQzCRc3LkMIMw//1AcSV+IP
	iyD+rfzi1cV43KLqpVhnklc7ySFYXh9bH5bKokJR0jo9CoVEuuyFy4iT0PN3I+pJZADBK/
	SkPc6iMRPcobbOQ7U6Ginn1pqF9Es34=
From: Juergen Gross 
To: linux-kernel@vger.kernel.org
Cc: Juergen Gross ,
	Stefano Stabellini ,
	Oleksandr Tyshchenko ,
	xen-devel@lists.xenproject.org,
	Demi Marie Obenour 
Subject: [PATCH 1/2] xen/evtchn: avoid WARN() when unbinding an event channel
Date: Wed, 13 Mar 2024 08:14:08 +0100
Message-Id: <20240313071409.25913-2-jgross@suse.com>
X-Mailer: git-send-email 2.35.3
In-Reply-To: <20240313071409.25913-1-jgross@suse.com>
References: <20240313071409.25913-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spamd-Bar: ++++
Authentication-Results: smtp-out2.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b=rdFQ6nU0
X-Spamd-Result: default: False [4.69 / 50.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_MISSING_CHARSET(2.50)[];
	 BROKEN_CONTENT_TYPE(1.50)[];
	 RCPT_COUNT_FIVE(0.00)[6];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_TRACE(0.00)[suse.com:+];
	 MX_GOOD(-0.01)[];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 BAYES_HAM(-0.00)[27.98%];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[suse.com:s=susede1];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 DKIM_SIGNED(0.00)[suse.com:s=susede1];
	 MID_CONTAINS_FROM(1.00)[];
	 DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:email,suse.com:dkim];
	 FUZZY_BLOCKED(0.00)[rspamd.com];
	 RCVD_TLS_ALL(0.00)[];
	 RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:104:10:150:64:97:from]
X-Spam-Score: 4.69
X-Spam-Level: ****
X-Rspamd-Queue-Id: A14D61F7A4
X-Spam-Flag: NO
X-Rspamd-Server: rspamd1.dmz-prg2.suse.org

When unbinding a user event channel, the related handler might be
called a last time in case the kernel was built with
CONFIG_DEBUG_SHIRQ. This might cause a WARN() in the handler.

Avoid that by adding an "unbinding" flag to struct user_event which
will short circuit the handler.

Fixes: 9e90e58c11b7 ("xen: evtchn: Allow shared registration of IRQ handers")
Reported-by: Demi Marie Obenour 
Tested-by: Demi Marie Obenour 
Signed-off-by: Juergen Gross 
---
 drivers/xen/evtchn.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/xen/evtchn.c b/drivers/xen/evtchn.c
index 59717628ca42..f6a2216c2c87 100644
--- a/drivers/xen/evtchn.c
+++ b/drivers/xen/evtchn.c
@@ -85,6 +85,7 @@ struct user_evtchn {
 	struct per_user_data *user;
 	evtchn_port_t port;
 	bool enabled;
+	bool unbinding;
 };
 
 static void evtchn_free_ring(evtchn_port_t *ring)
@@ -164,6 +165,10 @@ static irqreturn_t evtchn_interrupt(int irq, void *data)
 	struct per_user_data *u = evtchn->user;
 	unsigned int prod, cons;
 
+	/* Handler might be called when tearing down the IRQ. */
+	if (evtchn->unbinding)
+		return IRQ_HANDLED;
+
 	WARN(!evtchn->enabled,
 	     "Interrupt for port %u, but apparently not enabled; per-user %p\n",
 	     evtchn->port, u);
@@ -421,6 +426,7 @@ static void evtchn_unbind_from_user(struct per_user_data *u,
 
 	BUG_ON(irq < 0);
 
+	evtchn->unbinding = true;
 	unbind_from_irqhandler(irq, evtchn);
 
 	del_evtchn(u, evtchn);
-- 
2.35.3



From xen-devel-bounces@lists.xenproject.org Wed Mar 13 07:14:27 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 07:14:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692279.1079246 (Exim 4.92)
	(envelope-from )
	id 1rkIol-0001XF-EL; Wed, 13 Mar 2024 07:14:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692279.1079246; Wed, 13 Mar 2024 07:14:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkIol-0001X6-9o; Wed, 13 Mar 2024 07:14:27 +0000
Received: by outflank-mailman (input) for mailman id 692279;
 Wed, 13 Mar 2024 07:14:25 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkIoj-0000xl-BV
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 07:14:25 +0000
Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5235f45e-e109-11ee-afdd-a90da7624cb6;
 Wed, 13 Mar 2024 08:14:24 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org
 [IPv6:2a07:de40:b281:104:10:150:64:97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out2.suse.de (Postfix) with ESMTPS id 4C52E1F7A4;
 Wed, 13 Mar 2024 07:14:24 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 11D2313977;
 Wed, 13 Mar 2024 07:14:24 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id dM3kAlBS8WWySAAAD6G6ig
 (envelope-from ); Wed, 13 Mar 2024 07:14:24 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5235f45e-e109-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1710314064; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=WaNFizuX+HpD4/5IgMI1rgARw+12/nL76PmtgllkKJ0=;
	b=UoywMclp7TJYR91IhMV5U07zPMiTVrKqIXuCdOeYZZI4+snSxSOAmhNgkwR1+9eNhqvEHJ
	oJkI5PAD0SyxktGTNUtz1B+bwPyMQ89NaDpemlhVcEzwvYw8POk8o8qaa3cDOEYxo1LT1f
	Pr/hjgxHYfcfMh7WaiitQ3QSY3awRy0=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1710314064; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=WaNFizuX+HpD4/5IgMI1rgARw+12/nL76PmtgllkKJ0=;
	b=UoywMclp7TJYR91IhMV5U07zPMiTVrKqIXuCdOeYZZI4+snSxSOAmhNgkwR1+9eNhqvEHJ
	oJkI5PAD0SyxktGTNUtz1B+bwPyMQ89NaDpemlhVcEzwvYw8POk8o8qaa3cDOEYxo1LT1f
	Pr/hjgxHYfcfMh7WaiitQ3QSY3awRy0=
From: Juergen Gross 
To: linux-kernel@vger.kernel.org
Cc: Juergen Gross ,
	Stefano Stabellini ,
	Oleksandr Tyshchenko ,
	xen-devel@lists.xenproject.org
Subject: [PATCH 2/2] xen/events: increment refcnt only if event channel is refcounted
Date: Wed, 13 Mar 2024 08:14:09 +0100
Message-Id: <20240313071409.25913-3-jgross@suse.com>
X-Mailer: git-send-email 2.35.3
In-Reply-To: <20240313071409.25913-1-jgross@suse.com>
References: <20240313071409.25913-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Level: ***
X-Spamd-Bar: +++
Authentication-Results: smtp-out2.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b=UoywMclp
X-Rspamd-Server: rspamd2.dmz-prg2.suse.org
X-Spamd-Result: default: False [3.49 / 50.00];
	 ARC_NA(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 R_DKIM_ALLOW(-0.20)[suse.com:s=susede1];
	 SPAMHAUS_XBL(0.00)[2a07:de40:b281:104:10:150:64:97:from];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_MISSING_CHARSET(2.50)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 BROKEN_CONTENT_TYPE(1.50)[];
	 RCPT_COUNT_FIVE(0.00)[5];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_SIGNED(0.00)[suse.com:s=susede1];
	 DKIM_TRACE(0.00)[suse.com:+];
	 MX_GOOD(-0.01)[];
	 MID_CONTAINS_FROM(1.00)[];
	 DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:dkim,suse.com:email];
	 FUZZY_BLOCKED(0.00)[rspamd.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 NEURAL_HAM_SHORT(-0.20)[-0.995];
	 RCVD_TLS_ALL(0.00)[]
X-Spam-Score: 3.49
X-Rspamd-Queue-Id: 4C52E1F7A4
X-Spam-Flag: NO

In bind_evtchn_to_irq_chip() don't increment the refcnt of the event
channel blindly. In case the event channel is NOT refcounted, issue a
warning instead.

Add an additional safety net by doing the refcnt increment only if the
caller has specified IRQF_SHARED in the irqflags parameter.

Fixes: 9e90e58c11b7 ("xen: evtchn: Allow shared registration of IRQ handers")
Signed-off-by: Juergen Gross 
---
 drivers/xen/events/events_base.c | 22 +++++++++++++---------
 1 file changed, 13 insertions(+), 9 deletions(-)

diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c
index 2faa4bf78c7a..81effbd53dc5 100644
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -1190,7 +1190,7 @@ int xen_pirq_from_irq(unsigned irq)
 EXPORT_SYMBOL_GPL(xen_pirq_from_irq);
 
 static int bind_evtchn_to_irq_chip(evtchn_port_t evtchn, struct irq_chip *chip,
-				   struct xenbus_device *dev)
+				   struct xenbus_device *dev, bool shared)
 {
 	int ret = -ENOMEM;
 	struct irq_info *info;
@@ -1224,7 +1224,8 @@ static int bind_evtchn_to_irq_chip(evtchn_port_t evtchn, struct irq_chip *chip,
 		 */
 		bind_evtchn_to_cpu(info, 0, false);
 	} else if (!WARN_ON(info->type != IRQT_EVTCHN)) {
-		info->refcnt++;
+		if (shared && !WARN_ON(info->refcnt < 0))
+			info->refcnt++;
 	}
 
 	ret = info->irq;
@@ -1237,13 +1238,13 @@ static int bind_evtchn_to_irq_chip(evtchn_port_t evtchn, struct irq_chip *chip,
 
 int bind_evtchn_to_irq(evtchn_port_t evtchn)
 {
-	return bind_evtchn_to_irq_chip(evtchn, &xen_dynamic_chip, NULL);
+	return bind_evtchn_to_irq_chip(evtchn, &xen_dynamic_chip, NULL, false);
 }
 EXPORT_SYMBOL_GPL(bind_evtchn_to_irq);
 
 int bind_evtchn_to_irq_lateeoi(evtchn_port_t evtchn)
 {
-	return bind_evtchn_to_irq_chip(evtchn, &xen_lateeoi_chip, NULL);
+	return bind_evtchn_to_irq_chip(evtchn, &xen_lateeoi_chip, NULL, false);
 }
 EXPORT_SYMBOL_GPL(bind_evtchn_to_irq_lateeoi);
 
@@ -1295,7 +1296,8 @@ static int bind_ipi_to_irq(unsigned int ipi, unsigned int cpu)
 
 static int bind_interdomain_evtchn_to_irq_chip(struct xenbus_device *dev,
 					       evtchn_port_t remote_port,
-					       struct irq_chip *chip)
+					       struct irq_chip *chip,
+					       bool shared)
 {
 	struct evtchn_bind_interdomain bind_interdomain;
 	int err;
@@ -1307,14 +1309,14 @@ static int bind_interdomain_evtchn_to_irq_chip(struct xenbus_device *dev,
 					  &bind_interdomain);
 
 	return err ? : bind_evtchn_to_irq_chip(bind_interdomain.local_port,
-					       chip, dev);
+					       chip, dev, shared);
 }
 
 int bind_interdomain_evtchn_to_irq_lateeoi(struct xenbus_device *dev,
 					   evtchn_port_t remote_port)
 {
 	return bind_interdomain_evtchn_to_irq_chip(dev, remote_port,
-						   &xen_lateeoi_chip);
+						   &xen_lateeoi_chip, false);
 }
 EXPORT_SYMBOL_GPL(bind_interdomain_evtchn_to_irq_lateeoi);
 
@@ -1430,7 +1432,8 @@ static int bind_evtchn_to_irqhandler_chip(evtchn_port_t evtchn,
 {
 	int irq, retval;
 
-	irq = bind_evtchn_to_irq_chip(evtchn, chip, NULL);
+	irq = bind_evtchn_to_irq_chip(evtchn, chip, NULL,
+				      irqflags & IRQF_SHARED);
 	if (irq < 0)
 		return irq;
 	retval = request_irq(irq, handler, irqflags, devname, dev_id);
@@ -1471,7 +1474,8 @@ static int bind_interdomain_evtchn_to_irqhandler_chip(
 {
 	int irq, retval;
 
-	irq = bind_interdomain_evtchn_to_irq_chip(dev, remote_port, chip);
+	irq = bind_interdomain_evtchn_to_irq_chip(dev, remote_port, chip,
+						  irqflags & IRQF_SHARED);
 	if (irq < 0)
 		return irq;
 
-- 
2.35.3



From xen-devel-bounces@lists.xenproject.org Wed Mar 13 07:48:16 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 07:48:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692287.1079257 (Exim 4.92)
	(envelope-from )
	id 1rkJLO-0006Ot-26; Wed, 13 Mar 2024 07:48:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692287.1079257; Wed, 13 Mar 2024 07:48:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkJLN-0006Om-Tl; Wed, 13 Mar 2024 07:48:09 +0000
Received: by outflank-mailman (input) for mailman id 692287;
 Wed, 13 Mar 2024 07:48:09 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkJLN-0006Og-7s
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 07:48:09 +0000
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com
 [2a00:1450:4864:20::634])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 072af430-e10e-11ee-a1ee-f123f15fe8a2;
 Wed, 13 Mar 2024 08:48:07 +0100 (CET)
Received: by mail-ej1-x634.google.com with SMTP id
 a640c23a62f3a-a36126ee41eso836441966b.2
 for ; Wed, 13 Mar 2024 00:48:06 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 j26-20020a170906475a00b00a4588098c5esm4580980ejs.132.2024.03.13.00.48.05
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 13 Mar 2024 00:48:05 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 072af430-e10e-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710316086; x=1710920886; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=H2X6AdwEEOjZsYAQBEPXFQYf+g6L/BnTu9raS2RCbc0=;
        b=LZ0/C3l0iHJrIr6yjBdAPq86JDrriLg94PFJGy81UON39v2wwgy9yr+eqIprljtNEo
         +S7v1lyY9U7tb9tsFI/1jNDwReh55Aa7FUCi2pLhZue3B1FprfN5R2Gzxr/wcyugYwnf
         5l3GKQlQvJZ7WV6pPeSxGMychDMMTxoaGQB/2g8fNhHMvt47yRGGpviKRi27Vtszow9y
         M9kDof6XBXoDfu3A25rWMWu4g/XANgMBiqwT8G1Z5ogSRZsvfTZGQhH3G4YW4QGXaFT+
         hU4p+D7A42gDEhPi2+sayxzg0QNti27NTxpFB9IJHoeUlmHHsVSzCSrY5pdJFrT5DdvY
         9EqQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710316086; x=1710920886;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=H2X6AdwEEOjZsYAQBEPXFQYf+g6L/BnTu9raS2RCbc0=;
        b=oYvnmVnisYkwQxVXyUrLMT7eiHh64SaA6PCoAMCFIF2AKvgv/kP+hGaHsKLzlqsdHO
         xqtLd+BY8k4+3EJRYQBqld3pNbWHv6Htfo1InKtKFMnlmPd4bkDUhRZC52HYAYkTENGN
         oHiQF1aLLserekXCfjrFVLimgRS3QpJMaBrwr0xQvl0eO0yn00v8QXF8ma77gFol63yO
         +9LJ7E6h9IXSlcYn2SiNBZzbVX9vfaFq0DP9Gp1IEVf2FGbP1ore9bwF5cUn79mrxhbG
         MvbHgPTI7Q4PPAswN/sQtF5lBzAQHhoK/3JAtZx+rEhNs0e8fFl8fDTjl2fgG8NeBrop
         nCsA==
X-Forwarded-Encrypted: i=1; AJvYcCXXzA7klSKU2Nv5R4XVE7eJ/PUiwSMAI8HbF+RZSezMxSWyLiNoKpfPEYBBeTcNh/N+9vIL+XfkIAonUyACRLFHBHoLPtVfitn7Tmdrq9g=
X-Gm-Message-State: AOJu0YxTwM/KSlqwcB5cJfZWIhYhgpMfBRZFu1mtiurcQf/yXUnmkyWt
	t/yLNAAAyaF4l1tDns0Wcbp9oFUyBnpmWAybossYdkofA+/g7OwwL3tUAe6sKw==
X-Google-Smtp-Source: AGHT+IEzmxFlRTQxnKsrZWx4raMgmlpPPLi+zeDgah9wBnQpVYS7Yzss9bVJdnPCSNoarGPVdYCsyA==
X-Received: by 2002:a17:906:6a11:b0:a46:1538:9279 with SMTP id qw17-20020a1709066a1100b00a4615389279mr7325497ejc.16.1710316085676;
        Wed, 13 Mar 2024 00:48:05 -0700 (PDT)
Message-ID: <136e4667-8c6d-45ec-b652-b6b690a16f34@suse.com>
Date: Wed, 13 Mar 2024 08:48:04 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] docs/misra: add Rule 16.4
Content-Language: en-US
To: Stefano Stabellini 
Cc: andrew.cooper3@citrix.com, bertrand.marquis@arm.com, julien@xen.org,
 michal.orzel@amd.com, roger.pau@citrix.com, xen-devel@lists.xenproject.org
References: 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 13.03.2024 01:28, Stefano Stabellini wrote:
> --- a/docs/misra/rules.rst
> +++ b/docs/misra/rules.rst
> @@ -478,6 +478,30 @@ maintainers if you want to suggest a change.
>       - In addition to break, also other unconditional flow control statements
>         such as continue, return, goto are allowed.
>  
> +   * - `Rule 16.4 `_
> +     - Required
> +     - Every switch statement shall have a default label
> +     - Switch statements with enums as controlling expression don't need
> +       a default label as gcc -Wall enables -Wswitch which warns (and
> +       breaks the build)

I think this could do with mentioning -Werror.

> if one of the enum labels is missing from the
> +       switch.
> +
> +       Switch statements with integer types as controlling expression
> +       should have a default label:
> +
> +       - if the switch is expected to handle all possible cases
> +         explicitly, then a default label shall be added to handle
> +         unexpected error conditions, using BUG(), ASSERT(), WARN(),
> +         domain_crash(), or other appropriate methods;
> +
> +       - if the switch is expected to handle a subset of all
> +         possible cases, then a default label shall be added with an
> +         in-code comment as follows::
> +
> +             /* only handle a subset of the possible cases */
> +             default:
> +                 break;

Unless it being made crystal clear that mechanically reproducing this
comment isn't going to do, I'm going to have a hard time picking
between actively vetoing or just accepting if someone else acks this.
At the very least, though, the suggested (or, as requested, example)
comment should match ./CODING_STYLE. And it may need placing
differently if I understood correctly what Misra / Eclair demand
(between default: and break; rather than ahead of both).

The only place I'd accept a pre-cooked comment is to cover the
"notifier pattern".

Jan


From xen-devel-bounces@lists.xenproject.org Wed Mar 13 10:00:26 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 10:00:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692322.1079330 (Exim 4.92)
	(envelope-from )
	id 1rkLPD-0000yT-Oy; Wed, 13 Mar 2024 10:00:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692322.1079330; Wed, 13 Mar 2024 10:00:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkLPD-0000yM-Kw; Wed, 13 Mar 2024 10:00:15 +0000
Received: by outflank-mailman (input) for mailman id 692322;
 Wed, 13 Mar 2024 10:00:13 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkLPB-0000yC-RB; Wed, 13 Mar 2024 10:00:13 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkLPB-0001Zd-O8; Wed, 13 Mar 2024 10:00:13 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkLPB-0003mh-Bw; Wed, 13 Mar 2024 10:00:13 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rkLPB-0001VZ-Ac; Wed, 13 Mar 2024 10:00:13 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=uUfX6YItpocK8x6/zHPtSZ2vM0oZgeH2+RYPTpoyieY=; b=TNIfbLmKS/ca3LQuFRhjICdPiz
	z9Owo1m2Y+HLNN/T4WjQG3mdy4MWLE6iFHheye98gsh8hMWT7H03yt6coCvTA9einl+TZdu0RoSEg
	JeREWqkI8OvwZxr3LFj4qay7Hvz9IciuL4wkxu7zuxN41WzBmraS3p+8MxVy/GpHsPJw=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-4.15-testing test] 185006: tolerable FAIL - PUSHED
X-Osstest-Failures:
    xen-4.15-testing:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:heisenbug
    xen-4.15-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    xen-4.15-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    xen-4.15-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    xen-4.15-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    xen-4.15-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    xen-4.15-testing:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking
    xen-4.15-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    xen-4.15-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    xen-4.15-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    xen-4.15-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
    xen-4.15-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    xen-4.15-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    xen-4.15-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    xen-4.15-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    xen-4.15-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-4.15-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    xen-4.15-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    xen-4.15-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
    xen-4.15-testing:test-amd64-i386-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-4.15-testing:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
    xen-4.15-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-4.15-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    xen-4.15-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    xen-4.15-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-4.15-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    xen-4.15-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-4.15-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-4.15-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    xen-4.15-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    xen-4.15-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    xen-4.15-testing:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    xen-4.15-testing:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    xen-4.15-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
    xen-4.15-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
    xen-4.15-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    xen-4.15-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
    xen-4.15-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    xen-4.15-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    xen-4.15-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-4.15-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-4.15-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    xen-4.15-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    xen-4.15-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    xen-4.15-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    xen-4.15-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    xen-4.15-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    xen-4.15-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    xen-4.15-testing:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-4.15-testing:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    xen-4.15-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    xen-4.15-testing:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    xen-4.15-testing:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    xen-4.15-testing:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking
    xen-4.15-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
X-Osstest-Versions-This:
    xen=0fb100a94d0127910fe1dfa253cb759f6bc11174
X-Osstest-Versions-That:
    xen=2484803074fc1f93942912a82e4906f9e441bf4e
From: osstest service owner 
Date: Wed, 13 Mar 2024 10:00:13 +0000

flight 185006 xen-4.15-testing real [real]
flight 185017 xen-4.15-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/185006/
http://logs.test-lab.xenproject.org/osstest/logs/185017/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 12 debian-hvm-install fail pass in 185017-retest

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

version targeted for testing:
 xen                  0fb100a94d0127910fe1dfa253cb759f6bc11174
baseline version:
 xen                  2484803074fc1f93942912a82e4906f9e441bf4e

Last test of basis   184784  2024-02-27 13:36:49 Z   14 days
Testing same since   185006  2024-03-12 17:36:59 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Roger Pau Monné 

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 fail    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-armhf-armhf-libvirt-qcow2                               pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-libvirt-raw                                  pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-arm64-arm64-xl-vhd                                      pass    
 test-armhf-armhf-xl-vhd                                      pass    
 test-amd64-i386-xl-vhd                                       pass    


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

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

Explanation of these 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
   2484803074..0fb100a94d  0fb100a94d0127910fe1dfa253cb759f6bc11174 -> stable-4.15


From xen-devel-bounces@lists.xenproject.org Wed Mar 13 10:08:26 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 10:08:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692327.1079340 (Exim 4.92)
	(envelope-from )
	id 1rkLX3-0001cY-IP; Wed, 13 Mar 2024 10:08:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692327.1079340; Wed, 13 Mar 2024 10:08:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkLX3-0001cR-FB; Wed, 13 Mar 2024 10:08:21 +0000
Received: by outflank-mailman (input) for mailman id 692327;
 Wed, 13 Mar 2024 10:08:20 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkLX2-0001cL-CX
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 10:08:20 +0000
Received: from EUR04-DB3-obe.outbound.protection.outlook.com
 (mail-db3eur04on0609.outbound.protection.outlook.com
 [2a01:111:f400:fe0c::609])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9ca038b3-e121-11ee-a1ee-f123f15fe8a2;
 Wed, 13 Mar 2024 11:08:17 +0100 (CET)
Received: from DU7P250CA0020.EURP250.PROD.OUTLOOK.COM (2603:10a6:10:54f::7) by
 DU0PR08MB10357.eurprd08.prod.outlook.com (2603:10a6:10:414::22) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.36; Wed, 13 Mar
 2024 10:08:08 +0000
Received: from DU6PEPF0000A7E1.eurprd02.prod.outlook.com
 (2603:10a6:10:54f:cafe::7f) by DU7P250CA0020.outlook.office365.com
 (2603:10a6:10:54f::7) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.19 via Frontend
 Transport; Wed, 13 Mar 2024 10:08:08 +0000
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by
 DU6PEPF0000A7E1.mail.protection.outlook.com (10.167.8.45) with
 Microsoft SMTP
 Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.7386.12 via Frontend Transport; Wed, 13 Mar 2024 10:08:08 +0000
Received: ("Tessian outbound 7b0d57313a48:v276");
 Wed, 13 Mar 2024 10:08:08 +0000
Received: from a83ffcad1a2c.1
 by 64aa7808-outbound-1.mta.getcheckrecipient.com id
 45186660-E173-4D11-9AC1-119630FD7BBF.1; 
 Wed, 13 Mar 2024 10:08:01 +0000
Received: from EUR05-VI1-obe.outbound.protection.outlook.com
 by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id a83ffcad1a2c.1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384);
 Wed, 13 Mar 2024 10:08:01 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com (2603:10a6:10:25a::24)
 by AS8PR08MB6662.eurprd08.prod.outlook.com (2603:10a6:20b:397::19)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.19; Wed, 13 Mar
 2024 10:07:58 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::7fb0:6621:56b:22d5]) by DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::7fb0:6621:56b:22d5%3]) with mapi id 15.20.7362.035; Wed, 13 Mar 2024
 10:07:58 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9ca038b3-e121-11ee-a1ee-f123f15fe8a2
ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass;
 b=hV5RfcllN/BUofXVX4Vs/7JVL+UMmPxyj9VdZIOELxc7j8fh7GbrK1BVNQfULY0ryCIeJegvzMQ/9xQ2itRn+5AOlpK/8r6hZEEPljDLTrOMdGEktptdIIYNt1pEaIaT0AZ9CF3jydxq5Vi51PHIErnX6fkVyDuHlLx91kGgHghH+LrgS1iJ2wsdEAnfBSLsx/dnjfSijJzbOWTI8v1FzycLtVBts5/W9frLxehN1HyGxOAkHaUIeozEbFE3qN1ZT3QjsF+aWSeiojkJveom91whl58goLH4jugdVzYzwKnDo8DUD0KXdeBBRCq5ye+CWs4TPWZAxGIkWl0On9pGjA==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=tN7r9mIZHEPOlNH367+zhhdBwovKJXuQKqZam/V0Q9s=;
 b=csTAXBAQvG0FNQlMRAqgt8bwJWebXpN5bv6365NlI4IHKzWumKWqN6FW5b70X0e/H6EXKnfWL+mo0fOkeDDyt9qXgFt93ycf9TnTPWp2mzMG+rt0L1jIYfhS2rfYD+YWAy0lkesfEud9yrjngKOREyaBege3IwnBC565vUNIB1w42Yz2Blm1a8w3vxgcDVU9B8gtAyyAOkfqtzCcuyvIqHpI1X3QpJnIp77c8PpRIsz3YTG9eljBWKR48hM5Jux0Uf+DcjgCnUXQb1ddcaMMkK8gOUMNe64M8gGV6ssPmExmPhZnuWfQx8qIuEoBCFPb/C6ETiVkEJT2/UDrknL2/Q==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 63.35.35.123) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=arm.com;
 dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com;
 dkim=pass (signature was verified) header.d=armh.onmicrosoft.com; arc=pass (0
 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com]
 dmarc=[1,1,header.from=arm.com])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com;
 s=selector2-armh-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=tN7r9mIZHEPOlNH367+zhhdBwovKJXuQKqZam/V0Q9s=;
 b=9ZgB9d/8kVj2/uHfskzGOIIeLBoiozA4nOfTmcA/aaIxDnB+d7H//lTeYoR6AMGNL3XdK16yzQQ2whVFSiNPhB5gyZekeVCvSs9T0peTpGUN3CEfXE3jCwrCy6I3wcWiV2cCqK+yfVeZT3PW6s86LJhNLmHeejVCQp8aEU2vehE=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=armh.onmicrosoft.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 63.35.35.123 as permitted sender) receiver=protection.outlook.com;
 client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
 pr=C
X-CheckRecipientChecked: true
X-CR-MTA-CID: 82f1ecd6626dd7f7
X-CR-MTA-TID: 64aa7808
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=aJQtzryGiINhu+UuUwOjJ9/xDIFjBDx+tc3KLonsKZ9+pUdEfG4Wo4fy26lBK0wYOi8rPRlnNrL9FgmFchMd4pFpXukxbbHPBP0nYMMyPV60awCimH46xeXjyLWNJF+eBZW7SxY9+AQXDT4gaNZFWrvGVK25F3eSUmJVWZmTikSVTYLZDEcotKaZhW/w28HoHLXnaDKlyhtQU9K/Zfy+dcOGFoMsjbPK10PsA0xQwyBjYN3f7yy5hZtwoKayQg9ZNuc/NCn41nwZDTerDD4RVqMli9cOi7/56KjSbIIL2v3j6pHtTM5AkMGMIb7VgyY5vOaVHwl/5likLDObaa8VHA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=tN7r9mIZHEPOlNH367+zhhdBwovKJXuQKqZam/V0Q9s=;
 b=LUzmOYD51jJ9RSX91dHEr5083EKA20hAXrn2aF41L+xdqXvNYLwXqAj8DjGlpDO5Ls/gPjrSez//FacvXM2j/Rzr+2Ph5umgCT0aIx/iZfoHRpTuo1HA2qZrY9QSfJlzsYWo1AoXuB6+1yye7qtXdPwk4r42fMA9G/IFBmLdfwjt/oBtIjvsBKNW0Jg/YgRgkOZ0ycI7KkQFpP1wUJz+2ejISWBj8ne9yKeFkowMr05AN+YsJf8DNbVhGoNlWUuKcChWVFrk3aAFTI9SE/lTanOSLX1rX85QNjYqWaq3W0L6TSMa+/v47oOH6sYba+c7Z+nbP8WIvbqP+SjzU0XSPA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass
 header.d=arm.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com;
 s=selector2-armh-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=tN7r9mIZHEPOlNH367+zhhdBwovKJXuQKqZam/V0Q9s=;
 b=9ZgB9d/8kVj2/uHfskzGOIIeLBoiozA4nOfTmcA/aaIxDnB+d7H//lTeYoR6AMGNL3XdK16yzQQ2whVFSiNPhB5gyZekeVCvSs9T0peTpGUN3CEfXE3jCwrCy6I3wcWiV2cCqK+yfVeZT3PW6s86LJhNLmHeejVCQp8aEU2vehE=
From: Bertrand Marquis 
To: Julien Grall 
CC: John Ernberg , Peng Fan , Stefano
 Stabellini , Michal Orzel ,
	Volodymyr Babchuk , Jonas Blixt
	, "xen-devel@lists.xenproject.org"
	
Subject: Re: [PATCH 1/2] xen/arm: Add imx8q{m,x} platform glue
Thread-Topic: [PATCH 1/2] xen/arm: Add imx8q{m,x} platform glue
Thread-Index:
 AQHaVDuqVQ/kgxLZgUK/m8/hE0ez5bDz198AgAA1LICAAVx4AIAAQjaAgAEdtQCAAynKwIABnCuAgAZ8E4CAKNxCgIAApf0AgAKGQwCAAAbHgIAHmWEA
Date: Wed, 13 Mar 2024 10:07:58 +0000
Message-ID: <967020E7-3D03-416A-8BFC-6F4E4BD9D7B5@arm.com>
References: <20240131114952.305805-1-john.ernberg@actia.se>
 <20240131114952.305805-2-john.ernberg@actia.se>
 
 <494d4961-ad8a-4d1d-aaa6-d1bfb9d6a137@actia.se>
 <167f0c7a-e037-446c-82f8-2584e35a7af1@xen.org>
 
 <012b5f83-2f9b-4477-965e-07b8506c0052@xen.org>
 
 <5a0c8f09-4f01-45e9-892c-86342c0d0ec5@xen.org>
 <08ae764c-3490-4dd1-ab70-7a855a98d16d@actia.se>
 <911ec1bb-3733-4f37-839e-673a88e408ff@actia.se>
 
 <848794f3-a337-49d9-84db-a969970f071b@actia.se>
 <48038c7f-d7cd-4100-a41b-8042bcb93208@xen.org>
In-Reply-To: <48038c7f-d7cd-4100-a41b-8042bcb93208@xen.org>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3774.200.91.1.1)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DB9PR08MB6588:EE_|AS8PR08MB6662:EE_|DU6PEPF0000A7E1:EE_|DU0PR08MB10357:EE_
X-MS-Office365-Filtering-Correlation-Id: 3835d7dc-0746-42f3-6b30-08dc43457b5a
x-checkrecipientrouted: true
nodisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted: BCL:0;
X-Microsoft-Antispam-Message-Info-Original:
 hN9jQo0VkVZuUmu+Q5DxRZm0LcSwCbxi85pxQ0/3U3XTfL0XfoYH9HhCNLQR7V0XKL93C8aGUmEzuUcJ1a2jpnLanZtR+DcMHJmsqDtu0g+XgtqO+yM9sLrbqdQdcop8scvmpJhX/WbRR8+6QbH4At9bBaE8o2vWvrkeJ+Uv65nNFplJKBsqg1B854H/3IXQwmwCkXxOhiIBhUvnjNmvKGz4+Pf5f3gThkdDlp0i7djPE8z9P0nlJQL5QMyKP/etQfw8/+wPbW6NdW6P9XsIVGmLQ124wSbgc+Htfg5Zhn8U1dxV3gQK3n33qzLy7uED4W+c3Or3gDf26UBUMdfem4Do2bkDmQvD7cpEZijPLTGhwfUEOsNWqrYTWyXjMaJifxqmokbp5x+gx4OGFsRLI7BTkjcHxFvmw8WO7I0mY134wHSHjVNqpEHcOWF9Za3djMtng2oNHLQHT8jJoiZIeUsceLq5HSD1WnOoiHyKW+vTR4aJ3/HmGGqVOVEQLjJnp1Kpviu6XUQw3m9XAffSGztT0Gyr8aQgZqEhPZFtNYGXg3sFD3zt2fmr9dFVAC6b8QUefTxe7jYpnGT9X/dDSV5y6YFiDlWxYSRa9NCTLKJ+IO8mX3CnT83rrbDwQDqOm0+/AlMa3g0bU8Nnta0NceQoxaBNlZ+ccAyJEdBQ+6z/2ugfuqVcVLGx/G+AX2k0+vTlbdA5pEESAC8+u5ScMRIiUB6+qgmuk6Ns8v3qSic=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB9PR08MB6588.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(1800799015)(376005)(38070700009);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="us-ascii"
Content-ID: <6D4DA68D0B49374D8BDEE55D1442CB3E@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB6662
Original-Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 DU6PEPF0000A7E1.eurprd02.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	e81294cd-a37e-4272-bf44-08dc434575ba
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	mM4cwfB40crauwoa2pDkGQdVwPFZU+8UnzjM7EpmbbUR4OGH6aRPGww1rA0o62R4skE8y1eWnlTG2mznkJim1LkeKTA66zzw8OQ8eDMSLXl3vifmN9lV4jE7aWVkWm+dmv5fmtrPsXWj//txwF9a/hNa0h91X1Sqd+EXzkmpCCXNmRhY//owNKiuHlms2GfWaxB8uUHC7DoqZT97Ii44e/2wENvxDZN09v6MmPW2Zwl9j5/Ax6rZwDPPPtPbj1b85fKpq4zdGJXRvOJ9qTU4Vq/PZNQSrkvRIcMNO/dGtvbQ5Ut69DsBz2rssd7QXHqD5Ym0Gq325ZQIyOhw/7KYQpcfGv3Q75h4B7kXulPJjVGaIb8ZLZgr8ek+/SAActgREuSIUZGO8dPd+NRfEnFqR9dWmxJEbpfRa3Xi7TrrcZeaayoi6N9yuTdozMQxUcvf3Ibbt5FBjQDUtFC2n4+Kh7fORw84aCQCasQSZLUG38prNTrE6BztO1iCihyF6OfFuBpGkc/IqgHg/WmKEANbEfVV3J8kFCU2FaK1VmjRalV2nZkZHWoxAa7TBpHNJ65IVyGtJ+DEee/81E7D1nw47jDMAPs4uH8b9UX+m2Q9+8KACBqHpo0WtFj7Yf2jTJl2GoovEucRasgPsxPr3uPHm8gnzK3hyi/dOfWAJWdThDJ2Cs9EQ97IL7y7z/PgAIPk+lq7AeKV4yFNVDDMmWO2E9GWLPE73RvqRgkrqv4a5dtkGFS872rxCmOMMMdLmCMX
X-Forefront-Antispam-Report:
	CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com;CAT:NONE;SFS:(13230031)(376005)(1800799015)(36860700004)(82310400014);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Mar 2024 10:08:08.1095
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 3835d7dc-0746-42f3-6b30-08dc43457b5a
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DU6PEPF0000A7E1.eurprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR08MB10357

Hi,

> On 8 Mar 2024, at 15:04, Julien Grall  wrote:
>=20
> Hi John,
>=20
> Thank you for the reply.
>=20
> On 08/03/2024 13:40, John Ernberg wrote:
>> On 3/7/24 00:07, Julien Grall wrote:
>>>  > Ping on the watchdog discussion bits.
>>>=20
>>> Sorry for the late reply.
>>>=20
>>> On 06/03/2024 13:13, John Ernberg wrote:
>>>> On 2/9/24 14:14, John Ernberg wrote:
>>>>>=20
>>>>>>     * IMX_SIP_TIMER_*:  This seems to be related to the watchdog.
>>>>>> Shouldn't dom0 rely on the watchdog provided by Xen instead? So thos=
e
>>>>>> call will be used by Xen.
>>>>>=20
>>>>> That is indeed a watchdog SIP, and also for setting the SoC internal =
RTC
>>>>> if it is being used.
>>>>>=20
>>>>> I looked around if there was previous discussion and only really
>>>>> found [3].
>>>>> Is the xen/xen/include/watchdog.h header meant to be for this kind of
>>>>> watchdog support or is that more for the VM watchdog? Looking at the =
x86
>>>>> ACPI NMI watchdog it seems like the former, but I have never worked w=
ith
>>>>> x86 nor ACPI.
>>>=20
>>> include/watchdog.h contains helper to configure the watchdog for Xen. W=
e
>>> also have per-VM watchdog and this is configured by the hypercall
>>> SCHEDOP_watchdog.
>>>=20
>>>>>=20
>>>>> Currently forwarding it to Dom0 has not caused any watchdog resets wi=
th
>>>>> our watchdog timeout settings, our specific Dom0 setup and VM count.
>>>=20
>>> IIUC, the SMC API for the watchdog would be similar to the ACPI NMI
>>> watchdog. So I think it would make more sense if this is not exposed to
>>> dom0 (even if Xen is doing nothing with it).
>>>=20
>>> Can you try to hide the SMCs and check if dom0 still behave properly?
>>>=20
>>> Cheers,
>>>=20
>> This SMC manages a hardware watchdog, if it's not pinged within a
>> specific interval the entire board resets.
>=20
> Do you know what's the default interval? Is it large enough so Xen + dom0=
 can boot (at least up to when the watchdog driver is initialized)?
>=20
>> If I block the SMCs the watchdog driver in Dom0 will fail to ping the
>> watchdog, triggering a board reset because the system looks to have
>> become unresponsive. The reason this patch set started is because we
>> couldn't ping the watchdog when running with Xen.
>> In our specific system the bootloader enables the watchdog as early as
>> possible so that we can get watchdog protection for as much of the boot
>> as we possibly can.
>> So, if we are to block the SMC from Dom0, then Xen needs to take over
>> the pinging. It could be implemented similarly to the NMI watchdog,
>> except that the system will reset if the ping is missed rather than
>> backtrace.
>> It would also mean that Xen will get a whole watchdog driver-category
>> due to the watchdog being vendor and sometimes even SoC specific when it
>> comes to Arm.
>> My understanding of the domain watchdog code is that today the domain
>> needs to call SCHEDOP_watchdog at least once to start the watchdog
>> timer. Since watchdog protection through the whole boot process is
>> desirable we'd need some core changes, such as an option to start the
>> domain watchdog on init. >
>> It's quite a big change to make
>=20
> For clarification, above you seem to mention two changes:
>=20
> 1) Allow Xen to use the HW watchdog
> 2) Allow the domain to use the watchdog early
>=20
> I am assuming by big change, you are referring to 2?
>=20
> , while I am not against doing it if it
>> makes sense, I now wonder if Xen should manage hardware watchdogs.
>> Looking at the domain watchdog code it looks like if a domain does not
>> get enough execution time, the watchdog will not be pinged enough and
>> the guest will be reset. So either watchdog approach requires Dom0 to
>> get execution time. Dom0 also needs to service all the PV backends it's
>> responsible for. I'm not sure it's valuable to add another layer of
>> watchdog for this scenario as the end result (checking that the entire
>> system works) is achieved without it as well.
>> So, before I try to find the time to make a proposal for moving the
>> hardware watchdog bit to Xen, do we really want it?
>=20
> Thanks for the details. Given that the watchdog is enabled by the bootloa=
der, I think we want Xen to drive the watchdog for two reasons:
> 1) In true dom0less environment, dom0 would not exist
> 2) You are relying on Xen + Dom0 to boot (or at least enough to get the w=
atchdog working) within the watchdog interval.

Definitely we need to consider the case where there is no Dom0.

I think there are in fact 3 different use cases here:
- watchdog fully driven in a domain (dom0 or another): would work if it is =
expected
  that Xen + Domain boot time is under the watchdog initial refresh rate. I=
 think this
  could make sense on some applications where your system depends on a spec=
ific
  domain to be properly booted to work. This would require an initial refre=
sh time
  configurable in the boot loader probably.
- watchdog fully driven by Xen. One might want to just make sure the hyperv=
isor is alive.
- hybrid model where the watchdog is driven by Xen until a domain comes up =
to drive it.
  This could make sense to relax the stress on boot time but would raise th=
e question of
   what should be done if the domain dies. This is also kind of complex as =
Xen should stop
   refreshing the watchdog when a domain starts doing it (might require a t=
rap and emulate
   initially that is then mapped directly to a domain). I am not completely=
 sure this makes sense.

Regards
Bertrand


>=20
> Let see what the other Arm maintainer thinks.
>=20
> --=20
> Julien Grall



From xen-devel-bounces@lists.xenproject.org Wed Mar 13 10:48:23 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 10:48:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692332.1079349 (Exim 4.92)
	(envelope-from )
	id 1rkM9h-0006L5-Kg; Wed, 13 Mar 2024 10:48:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692332.1079349; Wed, 13 Mar 2024 10:48:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkM9h-0006Ky-I2; Wed, 13 Mar 2024 10:48:17 +0000
Received: by outflank-mailman (input) for mailman id 692332;
 Wed, 13 Mar 2024 10:48:15 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkM9f-0006Ks-Po
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 10:48:15 +0000
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com
 [2a00:1450:4864:20::335])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 30d2aebe-e127-11ee-a1ee-f123f15fe8a2;
 Wed, 13 Mar 2024 11:48:13 +0100 (CET)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-413ea3219feso2673645e9.3
 for ; Wed, 13 Mar 2024 03:48:13 -0700 (PDT)
Received: from localhost ([85.31.135.62]) by smtp.gmail.com with ESMTPSA id
 j15-20020a05600c190f00b0041312855081sm1945081wmq.5.2024.03.13.03.48.12
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 13 Mar 2024 03:48:12 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 30d2aebe-e127-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710326893; x=1710931693; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=1MHZBsMKC4KZU3HjGb0NPMsXzwK+B0aYwVLuhPmsPWQ=;
        b=VGP7EQ0QtsFdvgnH1JUd/Bdw7fqDpWwFTg1OuMgtOzUtYgzxGSDkXI4FN54/Y6juxE
         2ayJ8P+iKUZqKYo7aOjdYT3agcEyuUCY4N3vGi6P7QQuZS/No7z4uExTPyqKpXW97CDU
         AHCM2RJWbCd5AucBKsbOuYJ/df23BdiM6Xvec=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710326893; x=1710931693;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=1MHZBsMKC4KZU3HjGb0NPMsXzwK+B0aYwVLuhPmsPWQ=;
        b=XtvN5eXRRbuF5POyCwMRLdb+56z3MNt6VlINA1ISnm5DCYH0sbeMUt80JUwcHCaZVd
         S8vGyMqMEu6MK+MqIxzZ6kLPnSSxJ1ThX4th/Uo+5aOjj9FWcS16zbL3S7syygauRMm1
         3NrA3LQvPObeN1SlvME/mok1/UD+rKdtR4rfaDPU9KRVl4IcmtqJjJfNlLiTb1dBGvTR
         flCD6qCYBT94ouV5hqTeqjJxGXPRUFnRH8/3t/Qf6dVSa51ruDSqXwaE8s+PXtLAJdOz
         14l6zNGYCNqi1cEnnL/PJSo0IQvoRAY2c/fcb295EQMRVEs20uaDMejGOkWbuDgc0nhE
         AuWg==
X-Gm-Message-State: AOJu0YwSuDmhLebSwBYtCqDvZl88FqZ511pyAHqOCZwQ8wiMzaqa6jzA
	CMSTs79vmKw0V4jWuaKxWutYQlH1nNOMmg8bP2bhovqoTfDaJsT+Flw/lT+7bC6+eJwSKuKLuzP
	M
X-Google-Smtp-Source: AGHT+IH21KididVvla4PA1cq+3YqlLYuVZYqeMv4AJZ1Doisls1KtzHi/APVr7k56w66pLNZeLupzg==
X-Received: by 2002:a05:600c:1ca4:b0:412:e70a:ab8a with SMTP id k36-20020a05600c1ca400b00412e70aab8amr9465851wms.25.1710326892900;
        Wed, 13 Mar 2024 03:48:12 -0700 (PDT)
Date: Wed, 13 Mar 2024 11:48:11 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Anthony PERARD 
Cc: xen-devel@lists.xenproject.org, Jan Beulich ,
	Andrew Cooper ,
	Juergen Gross 
Subject: Re: [OSSTEST PATCH] ap-common: Switch to Linux 6.1 by default on x86
 + drop dom0 i386
Message-ID: 
References: <20240306114741.14564-1-anthony.perard@citrix.com>
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Tue, Mar 12, 2024 at 05:19:46PM +0000, Anthony PERARD wrote:
> On Mon, Mar 11, 2024 at 06:27:52PM +0100, Roger Pau Monné wrote:
> > On Wed, Mar 06, 2024 at 11:47:41AM +0000, Anthony PERARD wrote:
> > > Gone, but replaced by a new test-amd64-amd64-*:
> > > - test-amd64-i386-libvirt-raw
> > > - test-amd64-i386-xl-vhd
> > > 
> > > Some test-amd64-amd64-* are also changed:
> > > - test-amd64-amd64-libvirt-vhd
> > > - test-amd64-amd64-qemuu-freebsd11-amd64
> > > - test-amd64-amd64-qemuu-freebsd12-amd64
> > > - test-amd64-amd64-xl-qcow2
> > > + test-amd64-amd64-freebsd11-amd64
> > > + test-amd64-amd64-freebsd12-amd64
> > > + test-amd64-amd64-libvirt-qcow2
> > > + test-amd64-amd64-libvirt-raw
> > > + test-amd64-amd64-xl-vhd
> > 
> > Is this purely a name change, or there's some kind of functional
> > change?
> 
> For test-amd64-amd64-qemuu-freebsd1{1,2}-amd64, it looks like the
> "-qemuu" is a bug. The freebsd jobs shouldn't have used $qemuu_suffix,
> as it doesn't use $qemuu_runvar. So I'm guessing $qemuu_suffix was just
> the value left from a previous call of test_matrix_do_one() with
> dom0arch==i386. The new name is already used by "linux-linus" branch.

FTAOD, could you mention this in the commit message?

FreeBSD doesn't use `$qemuu_runvar` because it was always using QEMU
upstream (when the FreeBSD test was added we decided to only test with
QEMU upstream).  So there's indeed no `-qemut` variant, but by
dropping the -qemuu prefix it could be confused with a PV guest
based test.

> As for the few changes in {xl,libvirt}-{raw,vhd,qcow2} tests, this is
> because of
> - f536e834f673 ("make-flight: Trim the matrix of disk format flights")
> - 5c70735f177f ("fmtarches: Use dom0arches, not hardcoded arch list")

Probably a dummy question, but why haven't those commits changed the
output of make-flight earlier?  I'm fine with the change, but I don't
really get why we are seeing it only now.

>    > It's not ideal because it means tests jumping about across arches and
>    > might let regressions go through but it's better than just dropping
>    > them, and doing a better approach is complex.
> 
> So, for those, yes, it's different tests. It adds one "-raw" test, and
> otherwise changes the toolstack used for the two other disk formats.
> 
> > I'm mostly worried whether this could lead to regressions getting in
> > as osstest would detect those jobs as new instead of inheriting from
> > the previous jobs.  Also the "History for test ..." won't link to jobs
> > prior to the rename?
> 
> Well, those tests are already in the "linux-linus" branch and the new
> "linux-6.1" branch, so we can already check manually if there's a
> regression or not. So if they pass in linux-6.1, regression will be
> detected, at least in the linux branch.
> 
> The rename of the freebsd jobs is unfortunate, but at least, it's going
> to be the correct name, instead of having a spurious "-qemuu" suffix.
> 
> As for "history of tests " pages, no I don't think we can easly link to
> to the previous job name. But that only apply to both freebsd* jobs.
> 
> We could keep the -qemuu in freebsd* jobs even if it's misleading to
> someone who know what it should mean, that would keep the job name to
> all branches and rename it in "linux-linus" branch. I don't know which
> one is better.
> 
> > I guess I'm confused about what causes the qemuu to be dropped from
> > the job names above.
> 
> It just shell script having variable been global by default.

Thanks for the clarification.

Roger.


From xen-devel-bounces@lists.xenproject.org Wed Mar 13 10:58:48 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 10:58:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692336.1079360 (Exim 4.92)
	(envelope-from )
	id 1rkMJm-00081B-Ib; Wed, 13 Mar 2024 10:58:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692336.1079360; Wed, 13 Mar 2024 10:58:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkMJm-000814-Fz; Wed, 13 Mar 2024 10:58:42 +0000
Received: by outflank-mailman (input) for mailman id 692336;
 Wed, 13 Mar 2024 10:58:41 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkMJl-00080y-TD
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 10:58:41 +0000
Received: from mail-oa1-x36.google.com (mail-oa1-x36.google.com
 [2001:4860:4864:20::36])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a656da33-e128-11ee-afdd-a90da7624cb6;
 Wed, 13 Mar 2024 11:58:40 +0100 (CET)
Received: by mail-oa1-x36.google.com with SMTP id
 586e51a60fabf-2218a0f55e1so531285fac.1
 for ; Wed, 13 Mar 2024 03:58:40 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a656da33-e128-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1710327519; x=1710932319; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=q5h9JwJAKrV4OE/L09HHTEZ8FYrOOBIqAvzIDW+sn1Y=;
        b=EC5oBRYWQqsvS0fy2Q1ytmt99PJJQP4sj+jaDZTElq6wEw2OUpymEjZtM0WgpEulfl
         bTEslykKRfF1sBfdWBr6aZyhSz6X2G2L1nmtNkiJU5v8/HVgyA91YACKoIDHppcQ/y0Y
         5c/RNFe+uhHn2RIuacxfDfZqSYaa65yQtn744=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710327519; x=1710932319;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=q5h9JwJAKrV4OE/L09HHTEZ8FYrOOBIqAvzIDW+sn1Y=;
        b=Iqx+8HcdG+xoiNCSF2v764Bz/mV7c9GhLxQkG616ebeDaCdggCD+/EeWgfdJbDYejQ
         LVlxcDuppODwU2m+xrsPbTQ2zheBhzm/Ay7yazNzFvyRo0n3Z3BIc+gyXMLDIL5kj69f
         /sGzVjb4x8PeKIBjyRcJdYCKKm3LQP8WAD/dyYxY4JChdteFW2XMXIMWw4WPFf1fR6Ym
         cVR1Y/5wVPXs0vR65kBx2Vwtr3KuBL8w4wdT5eYILX/cRl8y2JmqjQ6dMN31zK1yQWpP
         N7YGWbKcOrNmmU3kEAYqzn0bgyuZVAksU3vjy9N0oUzB6IJykkSlPh0D643Jo+yP7WCj
         ofmg==
X-Gm-Message-State: AOJu0Yw0eO3BlAHi68GEdyqUFcoimHzXXr2PCewu8f6ZVrDsPenT1BL7
	HnQ6gN1lBNvDKKz80dRCeQbQGACcBY+KwoREA9WaT7UBFYsNbuBvzlkdy2ppOnX4BRrW5avxsOT
	/YDEiHzZ4MhPh5AdTyvKUaBpBeR9KZaGTz38uew==
X-Google-Smtp-Source: AGHT+IFwN+KcWgiSvPIDHUYaMDdjJwtT2a4f+bAC7tBEpCxDHPe22SKKV9K0Emq901kSYQbtkKeEBfo5Yx8Krm+jfOo=
X-Received: by 2002:a05:6871:28a5:b0:21e:7a1d:b4ec with SMTP id
 bq37-20020a05687128a500b0021e7a1db4ecmr6632395oac.7.1710327519556; Wed, 13
 Mar 2024 03:58:39 -0700 (PDT)
MIME-Version: 1.0
References:  <740404f0-3da9-4ae5-b4a5-b24cb2907e7d@suse.com>
In-Reply-To: <740404f0-3da9-4ae5-b4a5-b24cb2907e7d@suse.com>
From: George Dunlap 
Date: Wed, 13 Mar 2024 10:58:28 +0000
Message-ID: 
Subject: Re: [PATCH v3] x86/PoD: tie together P2M update and increment of
 entry count
To: Jan Beulich 
Cc: "xen-devel@lists.xenproject.org" , 
	Andrew Cooper , Wei Liu , 
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Mar 12, 2024 at 3:22=E2=80=AFPM Jan Beulich  wro=
te:
>
> When not holding the PoD lock across the entire region covering P2M
> update and stats update, the entry count - if to be incorrect at all -
> should indicate too large a value in preference to a too small one, to
> avoid functions bailing early when they find the count is zero. However,
> instead of moving the increment ahead (and adjust back upon failure),
> extend the PoD-locked region.
>
> Fixes: 99af3cd40b6e ("x86/mm: Rework locking in the PoD layer")
> Signed-off-by: Jan Beulich 
> ---
> The locked region could be shrunk again, by having multiple unlock
> calls. But I think both ioreq_request_mapcache_invalidate() and
> domain_crash() are fair enough to call with the lock still held?
> ---
> v3: Extend locked region instead. Add Fixes: tag.
> v2: Add comments.
>
> --- a/xen/arch/x86/mm/p2m-pod.c
> +++ b/xen/arch/x86/mm/p2m-pod.c
> @@ -1348,16 +1348,22 @@ mark_populate_on_demand(struct domain *d
>          }
>      }
>
> +    /*
> +     * P2M update and stats increment need to collectively be under PoD =
lock,
> +     * to prevent code elsewhere observing PoD entry count being zero de=
spite
> +     * there actually still being PoD entries (created by the p2m_set_en=
try()
> +     * invocation below).
> +     */
> +    pod_lock(p2m);
> +
>      /* Now, actually do the two-way mapping */
>      rc =3D p2m_set_entry(p2m, gfn, INVALID_MFN, order,
>                         p2m_populate_on_demand, p2m->default_access);
>      if ( rc =3D=3D 0 )
>      {
> -        pod_lock(p2m);
>          p2m->pod.entry_count +=3D 1UL << order;
>          p2m->pod.entry_count -=3D pod_count;
>          BUG_ON(p2m->pod.entry_count < 0);
> -        pod_unlock(p2m);
>
>          ioreq_request_mapcache_invalidate(d);
>      }
> @@ -1373,6 +1379,8 @@ mark_populate_on_demand(struct domain *d
>          domain_crash(d);
>      }
>
> +    pod_unlock(p2m);

We're confident that neither domain_crash() nor
ioreq_request_mapcache_invalidate() will grab any of the p2m locks?

If so,

Reviewed-by: George Dunlap 


From xen-devel-bounces@lists.xenproject.org Wed Mar 13 11:10:13 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 11:10:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692340.1079369 (Exim 4.92)
	(envelope-from )
	id 1rkMUl-0001gz-HC; Wed, 13 Mar 2024 11:10:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692340.1079369; Wed, 13 Mar 2024 11:10:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkMUl-0001gs-EO; Wed, 13 Mar 2024 11:10:03 +0000
Received: by outflank-mailman (input) for mailman id 692340;
 Wed, 13 Mar 2024 11:10:02 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkMUk-0001Qg-8R
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 11:10:02 +0000
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com
 [2a00:1450:4864:20::62c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3c1175e2-e12a-11ee-afdd-a90da7624cb6;
 Wed, 13 Mar 2024 12:10:00 +0100 (CET)
Received: by mail-ej1-x62c.google.com with SMTP id
 a640c23a62f3a-a4429c556efso567259366b.0
 for ; Wed, 13 Mar 2024 04:10:00 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3c1175e2-e12a-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1710328200; x=1710933000; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=lCEfcPMbpAIZ2d04Rpa0MWk0/RT7zQUK5ESphtcAzUo=;
        b=N5rvwBU4uBfvAbJAe+ea6wSX+R5QCeb2lqP3f3mbS2kuv3OzyfuuV51oBT0VYz4dyp
         HZHER/i/TdsBOBvtODuNCdbHSV2wF+kYk0aKBiP4/0POIt0g9q575QU9ZSwARGtyclUU
         vQ7jjHj7+AZD/ahxqcPOJNQiZbpUKjsrpWQgm1d5YokoU/uTjRPFMbUrzyMEAiP3Ez+B
         x2PQ54WQytD8dXdR9W9efIuQqVfkmFRPjU+mCqgCzUEnT7y1E4dYRGCyHPtDGWU1GPls
         XqeFNEpfutpuvynBjvHk2vuSXKMR/khlUHJ20M1u3cbi/sNBiSCGvJAQ/vfaRq8MMTye
         hWrg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710328200; x=1710933000;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=lCEfcPMbpAIZ2d04Rpa0MWk0/RT7zQUK5ESphtcAzUo=;
        b=q8eatQ6j/6w+BNOq4lW9LhJ6l76hCeRAi0synN2gCOOl6z+oyLqEuatvZ89ac4/r9R
         od1O/ih5B6bVHcFMFUg1enqlExXiuW6ppaWsHlb352dzm6wpxLOk8e0F5uKHGD0KO+zk
         T4TruYmC7lfqQgSiqufR+onoS4p/Pn8a3EpE82bVhnEw4D+hoWBhQ0r0jIznCuOTDcjG
         oEJ7BAG3Ugye9nV8OOQzY8gM1to6uwY14YewE+cDeVM8vUSb68yyl02za4l7h7hVwjou
         IIx3ypuG3U43FPCb4dYtqO19vM521/ItueB7VbLEv6xqlMe730D1+YHA/Y15xFvWG93T
         78YQ==
X-Forwarded-Encrypted: i=1; AJvYcCXBCNDlHEGgxE2XJVnGod0QVjSLhLeBNu9I71dx08yoma5GIKsHJ0Tth9uhPQ6pJo3/h6h/oRd+Yumfb5tYuA7pVMXrhquI7wmqJ+RLOyY=
X-Gm-Message-State: AOJu0YzQAI22jBKDTG4Yd8VM+sLHK/DgkIHqoPPpLK/ZzFUoFGbMs5kq
	kRhoyBy4GYjuW9QyHNV9dSRy/+U9rZF+tQEm1Pw4Ba7BfyxXu7v15/eLW2LqOs7vK/SE/y7W4RJ
	a7IeU94wXk8m5VX7dtqG/UCNLr8ePDhM/3sI3HQ==
X-Google-Smtp-Source: AGHT+IFP5/pzUK7eFJw0FxEzkbEWBgf7gHGrwHLZTpIVYGm8fiT8ODsS12VkxnilnRRqD7j42yy6k/oL49OGElQIb9M=
X-Received: by 2002:a17:906:ba82:b0:a46:1a14:3563 with SMTP id
 cu2-20020a170906ba8200b00a461a143563mr2500782ejd.50.1710328200323; Wed, 13
 Mar 2024 04:10:00 -0700 (PDT)
MIME-Version: 1.0
References: <20240308015435.4044339-1-xin.wang2@amd.com> <20240308015435.4044339-5-xin.wang2@amd.com>
 <4821f30b-94a6-4a2a-8c46-81a9d1e288a4@amd.com> 
In-Reply-To: 
From: Carlo Nonato 
Date: Wed, 13 Mar 2024 12:09:49 +0100
Message-ID: 
Subject: Re: [PATCH v2 4/5] xen/arm: Find unallocated spaces for magic pages
 of direct-mapped domU
To: Henry Wang 
Cc: Michal Orzel , xen-devel@lists.xenproject.org, 
	Stefano Stabellini , Julien Grall , 
	Bertrand Marquis , Volodymyr Babchuk , 
	Alec Kwapis 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Henry,

On Tue, Mar 12, 2024 at 4:25=E2=80=AFAM Henry Wang  wrot=
e:
>
> Hi Michal,
>
> On 3/11/2024 9:46 PM, Michal Orzel wrote:
> > Hi Henry,
> >
> > diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-buil=
d.c
> > index 1e1c8d83ae..99447bfb0c 100644
> > --- a/xen/arch/arm/dom0less-build.c
> > +++ b/xen/arch/arm/dom0less-build.c
> > @@ -682,6 +682,49 @@ static int __init prepare_dtb_domU(struct domain *=
d, struct kernel_info *kinfo)
> >
> >       if ( kinfo->dom0less_feature & DOM0LESS_ENHANCED_NO_XS )
> >       {
> > +        if ( is_domain_direct_mapped(d) )
> > +        {
> > This whole block is dependent on static memory feature that is compiled=
 out by default.
> > Shouldn't you move it to static-memory.c ?
>
> This makes sense. I will convert this block to a function then move to
> static-memory.c in v3.
>
> >> +            struct meminfo *avail_magic_regions =3D xzalloc(struct me=
minfo);
> > I can't see corresponding xfree(avail_magic_regions). It's not going to=
 be used after unused memory
> > regions are retrieved.
>
> Hmmm I realized I've made a mess here and below. I will do the proper
> error handling in v3.
>
> >> +            struct meminfo *rsrv_mem =3D &bootinfo.reserved_mem;
> >> +            struct mem_map_domain *mem_map =3D &d->arch.mem_map;
> >> +            uint64_t magic_region_start =3D INVALID_PADDR;
> > What's the purpose of this initialization? magic_region_start is going =
to be re-assigned before making use of this value.
>
> Personally for variables holding an address, I would like to init the
> local variable to a poison value before use. But you are right it does
> not make a difference here I think. I can drop the initialization if you
> prefer not having it, sure.
>
> >> +            uint64_t magic_region_size =3D GUEST_MAGIC_SIZE;
> > Why not paddr_t?
>
> Good catch, I mixed struct meminfo with the newly added struct. Will use
> paddr_t.
> >> +
> >> +            magic_region_start =3D avail_magic_regions->bank[0].start=
;
> >> +
> >> +            /*
> >> +             * Register the magic region as reserved mem to make sure=
 this
> >> +             * region will not be counted when allocating extended re=
gions.
> > Well, this is only true in case find_unallocated_memory() is used to re=
trieve free regions.
> > What if our direct mapped domU used partial dtb and IOMMU is in use? In=
 this case,
> > find_memory_holes() will be used and the behavior will be different.
> >
> > Also, I'm not sure if it is a good idea to call find_unused_memory twic=
e (with lots of steps inside)
> > just to retrieve 16MB (btw. add_ext_regions will only return 64MB+ regi=
ons) region for magic pages.
> > I'll let other maintainers share their opinion.
>
> I agree with your point. Let's wait a bit longer for more
> ideas/comments. If no other inputs, I think I will drop the
> "adding to reserved_mem" part of logic and record the found unused
> memory in kinfo, then use rangeset_remove_range() to remove this range
> in both
>
> find_unallocated_memory() and find_memory_holes().
>
> > Also, CCing Carlo since he was in a need of retrieving free memory regi=
ons as well for cache coloring with dom0.
>
> (+ Carlo)
> Any inputs from your side for this topic Carlo?

Nothing at the moment.

Thanks.

> Kind regards,
> Henry
> > ~Michal
>


From xen-devel-bounces@lists.xenproject.org Wed Mar 13 11:20:33 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 11:20:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692345.1079379 (Exim 4.92)
	(envelope-from )
	id 1rkMep-0003xm-Ep; Wed, 13 Mar 2024 11:20:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692345.1079379; Wed, 13 Mar 2024 11:20:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkMep-0003xf-Bm; Wed, 13 Mar 2024 11:20:27 +0000
Received: by outflank-mailman (input) for mailman id 692345;
 Wed, 13 Mar 2024 11:20:26 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkMeo-0003xV-Jy; Wed, 13 Mar 2024 11:20:26 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkMeo-00035B-FY; Wed, 13 Mar 2024 11:20:26 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkMeo-0001fV-4m; Wed, 13 Mar 2024 11:20:26 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rkMeo-0007Fh-4F; Wed, 13 Mar 2024 11:20:26 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=Q2R5WnOyB6jzyyXZ1lvYkgD3YAA1O1agoBE7IevUeHs=; b=4qK609ErPbxVKZxJW5BgTOPZpk
	xJfL7AsmOSw3dZo3Vlve9EDSw6RKQTY+iDhUearuwiAPAhLzD3SoU0QNs2Slx16XthK+m2hkq5aW4
	wvS5i1+0CRZYlRk9Z2Qr4/mSivrvnNaftJPuHF7a6cocDSUR6LBRXH+O4MISt3vzTY+0=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [ovmf test] 185015: all pass - PUSHED
X-Osstest-Versions-This:
    ovmf=6b3a512149ddadb1891f0f96c63eba5dc65c7c69
X-Osstest-Versions-That:
    ovmf=ddaf39263a1ed84e60238622dfed83ff14ecc50a
From: osstest service owner 
Date: Wed, 13 Mar 2024 11:20:26 +0000

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf                 6b3a512149ddadb1891f0f96c63eba5dc65c7c69
baseline version:
 ovmf                 ddaf39263a1ed84e60238622dfed83ff14ecc50a

Last test of basis   185008  2024-03-12 17:41:21 Z    0 days
Testing same since   185015  2024-03-13 03:16:08 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Qingyu Shang 

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-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   ddaf39263a..6b3a512149  6b3a512149ddadb1891f0f96c63eba5dc65c7c69 -> xen-tested-master


From xen-devel-bounces@lists.xenproject.org Wed Mar 13 12:15:41 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 12:15:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692387.1079450 (Exim 4.92)
	(envelope-from )
	id 1rkNW2-0002Pu-Ey; Wed, 13 Mar 2024 12:15:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692387.1079450; Wed, 13 Mar 2024 12:15:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkNW2-0002Pn-BE; Wed, 13 Mar 2024 12:15:26 +0000
Received: by outflank-mailman (input) for mailman id 692387;
 Wed, 13 Mar 2024 12:15:24 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkNW0-0002Pd-Id; Wed, 13 Mar 2024 12:15:24 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkNW0-0004F8-HB; Wed, 13 Mar 2024 12:15:24 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkNW0-0005Y9-5C; Wed, 13 Mar 2024 12:15:24 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rkNW0-0006Hg-4i; Wed, 13 Mar 2024 12:15:24 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=VM1VyX4GNkHTzdfF1/6WPdxYTz47vLQ645egJleED1E=; b=KD/atwtt2UZ32qcU5pkOLmeTD5
	BowVlr6nPx6QdrGvhMFakRx8u8NHWCvmXZfVcNLQVRemcGR/UP/3bwMVmoTTojMqfOASEutmKKYBu
	8Gbuma5CY7TzfjfdXRjvVTn7BU+4UUMDyOu/7D+/v0duwCBmYsItsH+BD33vrmly4+5o=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-4.16-testing test] 185007: tolerable FAIL - PUSHED
X-Osstest-Failures:
    xen-4.16-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    xen-4.16-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    xen-4.16-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    xen-4.16-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    xen-4.16-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    xen-4.16-testing:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking
    xen-4.16-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
    xen-4.16-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    xen-4.16-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    xen-4.16-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    xen-4.16-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    xen-4.16-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    xen-4.16-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    xen-4.16-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    xen-4.16-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    xen-4.16-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    xen-4.16-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
    xen-4.16-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-4.16-testing:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
    xen-4.16-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-4.16-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    xen-4.16-testing:test-amd64-i386-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-4.16-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-4.16-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    xen-4.16-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    xen-4.16-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-4.16-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    xen-4.16-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-4.16-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    xen-4.16-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    xen-4.16-testing:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    xen-4.16-testing:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    xen-4.16-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
    xen-4.16-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
    xen-4.16-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    xen-4.16-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
    xen-4.16-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    xen-4.16-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    xen-4.16-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-4.16-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    xen-4.16-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-4.16-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    xen-4.16-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    xen-4.16-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    xen-4.16-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    xen-4.16-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    xen-4.16-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    xen-4.16-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    xen-4.16-testing:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-4.16-testing:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    xen-4.16-testing:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    xen-4.16-testing:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    xen-4.16-testing:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking
    xen-4.16-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
X-Osstest-Versions-This:
    xen=ea1da2ba8ea7c76a8a3a08d11f7de5acb8b17801
X-Osstest-Versions-That:
    xen=ffd75b161de76e43fd54d751ab70d2fdf6e2e87d
From: osstest service owner 
Date: Wed, 13 Mar 2024 12:15:24 +0000

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen                  ea1da2ba8ea7c76a8a3a08d11f7de5acb8b17801
baseline version:
 xen                  ffd75b161de76e43fd54d751ab70d2fdf6e2e87d

Last test of basis   184804  2024-02-28 06:43:49 Z   14 days
Testing same since   185007  2024-03-12 17:37:05 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Roger Pau Monné 

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-armhf-armhf-libvirt-qcow2                               pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-libvirt-raw                                  pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-arm64-arm64-xl-vhd                                      pass    
 test-armhf-armhf-xl-vhd                                      pass    
 test-amd64-i386-xl-vhd                                       pass    


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

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

Explanation of these 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
   ffd75b161d..ea1da2ba8e  ea1da2ba8ea7c76a8a3a08d11f7de5acb8b17801 -> stable-4.16


From xen-devel-bounces@lists.xenproject.org Wed Mar 13 12:19:37 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 12:19:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692391.1079460 (Exim 4.92)
	(envelope-from )
	id 1rkNa3-00032o-Us; Wed, 13 Mar 2024 12:19:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692391.1079460; Wed, 13 Mar 2024 12:19:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkNa3-00032h-SA; Wed, 13 Mar 2024 12:19:35 +0000
Received: by outflank-mailman (input) for mailman id 692391;
 Wed, 13 Mar 2024 12:19:34 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkNa2-00032b-Bh
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 12:19:34 +0000
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com
 [2a00:1450:4864:20::631])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f2720fbe-e133-11ee-a1ee-f123f15fe8a2;
 Wed, 13 Mar 2024 13:19:32 +0100 (CET)
Received: by mail-ej1-x631.google.com with SMTP id
 a640c23a62f3a-a45ecef71deso615167866b.2
 for ; Wed, 13 Mar 2024 05:19:32 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 p27-20020a17090628db00b00a465b6c9a67sm562955ejd.6.2024.03.13.05.19.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 13 Mar 2024 05:19:31 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f2720fbe-e133-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710332372; x=1710937172; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=YaCYrtmOr2uKYn2hAmsXIWQpm/Q2ypOYfRTxP7WXYJk=;
        b=NpPmZ6JGmwQdqVQ9dudgVQQUP/ZaNnQ+U0sdyxqY/X+qpJGldhA1hJG2gF+YguEGW/
         wmlPK8QscWh4NuAv/2L3L6ix2H/jnGJmgs9u9ZKgs2Vm/6mdpHO9HP0N2RY9cbygCMMt
         XeFyr30WMoNcPBoZjaeqMJ7ERzZO7wc7tBjLp+3Kne5XFk8j+S0V0jkXzEx9ydyV/8+a
         0us6iDND3vRQCG3a0wttINxrMAPU4Sebau3JG7phXpW3Mibbf+ALCTbYFdgRWyWDBp+w
         POb+lhyH8hK47dgdw1IyIluA+mPRLriba9aO25zcTLVmk7KCnUm2IH+Gh1OBQUoKPY91
         lgwQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710332372; x=1710937172;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=YaCYrtmOr2uKYn2hAmsXIWQpm/Q2ypOYfRTxP7WXYJk=;
        b=aOE4LcVcAYfxqg75wSXtm1cUYayP4suZby8bz/62YZHTrABm/cXzPf7xlRQ6j1HZ/N
         CDf+scdtvF+yjx9OWMIIvWIlNujwBJIJ2UG9sqR7/f9dUy5prodLLFALsvyzeh2FX76z
         XfrFeQrdnKxu9geGYsxZX9vc2Snmat/UHCi2EXJHyZxzB/3+5tJ8FjC+C7Gv9K2Xz6sK
         gtAhKoTjkJBNYseEP3k0QM8qrcokg5FL1pTWR8hP61FBO4BvDrd8ChlbeXgzCpcaWSLJ
         uPhpPsVVkcH1uBqaFr+ww0myTq+zzNiqsMaOx3fWH9s/hZjnUP4Ffv/xn9d5JT+AuVZM
         UV8A==
X-Gm-Message-State: AOJu0YyACZ3dSPFVSr0kLQXmIiXSMxcgF/WBzgJKbtE7Us9oBFsodpJf
	2e4WiwkekBNqxuWFQTn8UpDsm4JLkfp5xWEZS//MEs+i5Osd/3kxUEtm4Fbliw==
X-Google-Smtp-Source: AGHT+IH9VoLcmawr8UbzJ6KQZ5tV0irQywRcFvOZwdTcROFV17n4dyGdEplEHcRZxGH3BuKWJZY4Rw==
X-Received: by 2002:a17:906:cb08:b0:a44:48db:9060 with SMTP id lk8-20020a170906cb0800b00a4448db9060mr2967797ejb.19.1710332371823;
        Wed, 13 Mar 2024 05:19:31 -0700 (PDT)
Message-ID: <064ec76a-4957-448b-9afe-1bd264fd81c7@suse.com>
Date: Wed, 13 Mar 2024 13:19:30 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3] x86/PoD: tie together P2M update and increment of
 entry count
Content-Language: en-US
To: George Dunlap 
Cc: "xen-devel@lists.xenproject.org" ,
 Andrew Cooper , Wei Liu ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: 
 <740404f0-3da9-4ae5-b4a5-b24cb2907e7d@suse.com>
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 13.03.2024 11:58, George Dunlap wrote:
> On Tue, Mar 12, 2024 at 3:22 PM Jan Beulich  wrote:
>>
>> When not holding the PoD lock across the entire region covering P2M
>> update and stats update, the entry count - if to be incorrect at all -
>> should indicate too large a value in preference to a too small one, to
>> avoid functions bailing early when they find the count is zero. However,
>> instead of moving the increment ahead (and adjust back upon failure),
>> extend the PoD-locked region.
>>
>> Fixes: 99af3cd40b6e ("x86/mm: Rework locking in the PoD layer")
>> Signed-off-by: Jan Beulich 
>> ---
>> The locked region could be shrunk again, by having multiple unlock
>> calls. But I think both ioreq_request_mapcache_invalidate() and
>> domain_crash() are fair enough to call with the lock still held?
>> ---
>> v3: Extend locked region instead. Add Fixes: tag.
>> v2: Add comments.
>>
>> --- a/xen/arch/x86/mm/p2m-pod.c
>> +++ b/xen/arch/x86/mm/p2m-pod.c
>> @@ -1348,16 +1348,22 @@ mark_populate_on_demand(struct domain *d
>>          }
>>      }
>>
>> +    /*
>> +     * P2M update and stats increment need to collectively be under PoD lock,
>> +     * to prevent code elsewhere observing PoD entry count being zero despite
>> +     * there actually still being PoD entries (created by the p2m_set_entry()
>> +     * invocation below).
>> +     */
>> +    pod_lock(p2m);
>> +
>>      /* Now, actually do the two-way mapping */
>>      rc = p2m_set_entry(p2m, gfn, INVALID_MFN, order,
>>                         p2m_populate_on_demand, p2m->default_access);
>>      if ( rc == 0 )
>>      {
>> -        pod_lock(p2m);
>>          p2m->pod.entry_count += 1UL << order;
>>          p2m->pod.entry_count -= pod_count;
>>          BUG_ON(p2m->pod.entry_count < 0);
>> -        pod_unlock(p2m);
>>
>>          ioreq_request_mapcache_invalidate(d);
>>      }
>> @@ -1373,6 +1379,8 @@ mark_populate_on_demand(struct domain *d
>>          domain_crash(d);
>>      }
>>
>> +    pod_unlock(p2m);
> 
> We're confident that neither domain_crash() nor
> ioreq_request_mapcache_invalidate() will grab any of the p2m locks?

There's no doubt about ioreq_request_mapcache_invalidate(). domain_crash(),
otoh, invokes show_execution_state(), which in principle would be nice to
dump the guest stack among other things. My patch doing so was reverted, so
right now there's no issue there. Plus any attempt to do so would need to
be careful anyway regarding locks. But as you see it is not a clear cut no,
so ...

> If so,
> 
> Reviewed-by: George Dunlap 

... rather than taking this (thanks), maybe I indeed better follow the
alternative outlined in the post-commit-message remark?

Jan


From xen-devel-bounces@lists.xenproject.org Wed Mar 13 12:25:24 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 12:25:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692394.1079470 (Exim 4.92)
	(envelope-from )
	id 1rkNfa-0004UN-Hq; Wed, 13 Mar 2024 12:25:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692394.1079470; Wed, 13 Mar 2024 12:25:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkNfa-0004UG-F9; Wed, 13 Mar 2024 12:25:18 +0000
Received: by outflank-mailman (input) for mailman id 692394;
 Wed, 13 Mar 2024 12:25:17 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkNfZ-0004UA-6m
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 12:25:17 +0000
Received: from mail-oa1-x33.google.com (mail-oa1-x33.google.com
 [2001:4860:4864:20::33])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id beca3865-e134-11ee-afdd-a90da7624cb6;
 Wed, 13 Mar 2024 13:25:15 +0100 (CET)
Received: by mail-oa1-x33.google.com with SMTP id
 586e51a60fabf-221a9e5484aso3247481fac.0
 for ; Wed, 13 Mar 2024 05:25:15 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: beca3865-e134-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1710332715; x=1710937515; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=kZwwsxIGGvx7y/8uSvbnz2X5UzkKD3PBAoYlJ4YPNWg=;
        b=Sk4R5MSnXhKPgUiLoeG9+xHvl+zfl1y5XHpEKC6rJJajtUwlbGLV44V7QniJI2thPx
         l+5852TCkXBZ356uCgrU2yorqb0b7wPxVZAAaNJbFeW7/g3FIhGhmSvTojRdWwm4vQr1
         2Je9wufc1ad1DCcgzk7ocBYJu8Ronh6t9YK8k=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710332715; x=1710937515;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=kZwwsxIGGvx7y/8uSvbnz2X5UzkKD3PBAoYlJ4YPNWg=;
        b=DNZsKVY7deRyGrr8Kqg4laFzKGh+Dm3mwD5T7XVZraZnsyVGwayF+PSY+ajE4asMNl
         y38oM2yns3RM4WVeDYhTl43iS/apR6mcD5ZPKzh5oMzP4fkHHq2Me6JTQyWTJgRB3h1F
         L3x6nqC56Or80c7NH/4l4orcd0ij12Jb43vdcu9C76m0DG6c3x9zhdKD/LhxOfuJzNG4
         NMoc3c9z/rSgq7fync1UutDLkxGPBGYjGlGq9gwYIHQSNi9p1a4A4seNC7z+MEEtwFRA
         hdKZlIWHxXtcPG9wyXxEEyqNtLqnVUdZIYdRh4S2h2oLnB5VzV4YPjFLv/7A4uR8qk6G
         NGzw==
X-Gm-Message-State: AOJu0YyxDKZKNxeZeVPb/LlvkHS0v5uODKvQp+GOzboav8MKcTKwaRj4
	+PYVv+HQ9puzAJvyWAo/V9dqU8Dn00qAKPk0O5fhhmw6gD6hri+lI7XdOKtwz9Ll3dFEfbUEc5L
	XU2Dp9rsmvNVzfcxd4bjLQ39z79PvN1rrUlD/dw==
X-Google-Smtp-Source: AGHT+IH7+gkPaks9rkACXNVly1XFyNOGnag2kVWLuQ5YYsO0BzkQW6rjNoO2spwKCEqagaICzlI+zixwIFXamH4azlo=
X-Received: by 2002:a05:6870:b492:b0:21e:be10:f39d with SMTP id
 y18-20020a056870b49200b0021ebe10f39dmr3146320oap.46.1710332714758; Wed, 13
 Mar 2024 05:25:14 -0700 (PDT)
MIME-Version: 1.0
References: 
 <740404f0-3da9-4ae5-b4a5-b24cb2907e7d@suse.com> 
 <064ec76a-4957-448b-9afe-1bd264fd81c7@suse.com>
In-Reply-To: <064ec76a-4957-448b-9afe-1bd264fd81c7@suse.com>
From: George Dunlap 
Date: Wed, 13 Mar 2024 12:25:03 +0000
Message-ID: 
Subject: Re: [PATCH v3] x86/PoD: tie together P2M update and increment of
 entry count
To: Jan Beulich 
Cc: "xen-devel@lists.xenproject.org" , 
	Andrew Cooper , Wei Liu , 
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Mar 13, 2024 at 12:19=E2=80=AFPM Jan Beulich  wr=
ote:
>
> On 13.03.2024 11:58, George Dunlap wrote:
> > On Tue, Mar 12, 2024 at 3:22=E2=80=AFPM Jan Beulich =
 wrote:
> >>
> >> When not holding the PoD lock across the entire region covering P2M
> >> update and stats update, the entry count - if to be incorrect at all -
> >> should indicate too large a value in preference to a too small one, to
> >> avoid functions bailing early when they find the count is zero. Howeve=
r,
> >> instead of moving the increment ahead (and adjust back upon failure),
> >> extend the PoD-locked region.
> >>
> >> Fixes: 99af3cd40b6e ("x86/mm: Rework locking in the PoD layer")
> >> Signed-off-by: Jan Beulich 
> >> ---
> >> The locked region could be shrunk again, by having multiple unlock
> >> calls. But I think both ioreq_request_mapcache_invalidate() and
> >> domain_crash() are fair enough to call with the lock still held?
> >> ---
> >> v3: Extend locked region instead. Add Fixes: tag.
> >> v2: Add comments.
> >>
> >> --- a/xen/arch/x86/mm/p2m-pod.c
> >> +++ b/xen/arch/x86/mm/p2m-pod.c
> >> @@ -1348,16 +1348,22 @@ mark_populate_on_demand(struct domain *d
> >>          }
> >>      }
> >>
> >> +    /*
> >> +     * P2M update and stats increment need to collectively be under P=
oD lock,
> >> +     * to prevent code elsewhere observing PoD entry count being zero=
 despite
> >> +     * there actually still being PoD entries (created by the p2m_set=
_entry()
> >> +     * invocation below).
> >> +     */
> >> +    pod_lock(p2m);
> >> +
> >>      /* Now, actually do the two-way mapping */
> >>      rc =3D p2m_set_entry(p2m, gfn, INVALID_MFN, order,
> >>                         p2m_populate_on_demand, p2m->default_access);
> >>      if ( rc =3D=3D 0 )
> >>      {
> >> -        pod_lock(p2m);
> >>          p2m->pod.entry_count +=3D 1UL << order;
> >>          p2m->pod.entry_count -=3D pod_count;
> >>          BUG_ON(p2m->pod.entry_count < 0);
> >> -        pod_unlock(p2m);
> >>
> >>          ioreq_request_mapcache_invalidate(d);
> >>      }
> >> @@ -1373,6 +1379,8 @@ mark_populate_on_demand(struct domain *d
> >>          domain_crash(d);
> >>      }
> >>
> >> +    pod_unlock(p2m);
> >
> > We're confident that neither domain_crash() nor
> > ioreq_request_mapcache_invalidate() will grab any of the p2m locks?
>
> There's no doubt about ioreq_request_mapcache_invalidate(). domain_crash(=
),
> otoh, invokes show_execution_state(), which in principle would be nice to
> dump the guest stack among other things. My patch doing so was reverted, =
so
> right now there's no issue there. Plus any attempt to do so would need to
> be careful anyway regarding locks. But as you see it is not a clear cut n=
o,
> so ...
>
> > If so,
> >
> > Reviewed-by: George Dunlap 
>
> ... rather than taking this (thanks), maybe I indeed better follow the
> alternative outlined in the post-commit-message remark?

I keep missing your post-commit-message remarks due to the way I'm
applying your series.  Yes, that had occurred to me as well -- I don't
think this is a hot path, and I do think it would be good to avoid
laying a trap for future people wanting to change domain_crash(); in
particular as that would change a domain crash into either a host
crash or a potential deadlock.

I think I would go with multiple if statements, rather than multiple
unlock calls though.

 -George


From xen-devel-bounces@lists.xenproject.org Wed Mar 13 12:26:09 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 12:26:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692398.1079479 (Exim 4.92)
	(envelope-from )
	id 1rkNgN-000530-UR; Wed, 13 Mar 2024 12:26:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692398.1079479; Wed, 13 Mar 2024 12:26:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkNgN-00052t-Rw; Wed, 13 Mar 2024 12:26:07 +0000
Received: by outflank-mailman (input) for mailman id 692398;
 Wed, 13 Mar 2024 12:26:06 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkNgM-00052f-FY
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 12:26:06 +0000
Received: from mail-oa1-x34.google.com (mail-oa1-x34.google.com
 [2001:4860:4864:20::34])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id dc2edde8-e134-11ee-afdd-a90da7624cb6;
 Wed, 13 Mar 2024 13:26:05 +0100 (CET)
Received: by mail-oa1-x34.google.com with SMTP id
 586e51a60fabf-221e1910c3bso2018342fac.1
 for ; Wed, 13 Mar 2024 05:26:05 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: dc2edde8-e134-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1710332764; x=1710937564; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=x9JCDC61iNKYNQIve/QaGBY5AdoE81HbyRknOAkalEo=;
        b=lyY2Ofn94lTGmZDSc8QEvqlV4qfLezeMM5ByF5aebBcGxtG2vHww6K0fdOr1Ow/Ivt
         9Q41YwLqMCWEzbbweXJKdoEYRvRyBDDN6X0V1wpusu+v09IXOa3jdg5CRYutt1/1hGoe
         HEyz+sup1OuudPAzkDJWUWE9ZmFdHaH0SE8q8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710332764; x=1710937564;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=x9JCDC61iNKYNQIve/QaGBY5AdoE81HbyRknOAkalEo=;
        b=pPZdWnAKEZ//NbCZNGqXLP8tx+MbpGLUE1gkXMHs30XWYxEOShtyr/cFkHwKUM8qip
         9uluSfZXMT3ThszHpqQriL1g4zabJDgo7ZouTPdwQsTBUEYorC93wyTZB7C5RWl3RHm4
         lyPw+51NqpRdILHIX+j8foFSibbJL6sizI0XvhsxHMOk80PTfdZSOI57yTgzIxpux+DJ
         O0i+RUQvzR9ww48bRC4mDGhC84dGjzQY7fGeKX6Wi7aeF6FWCSdldVqa+EsedueSEI5B
         T5nENfPW8YA0foUdDVkMn9hpXfimOES5j9AytDcajplpgYQmFprZNadfZX124MPD5++1
         2OBw==
X-Gm-Message-State: AOJu0Yzts+lRI9FlfHfno1HZyZ/Jd9WPNtrbKcDivMujDCJYPgB35IjC
	2FfzB7pRLo4nwIjWxiPinL/JVfpVq8B65hjQw2dVl8E4m+REZTQT8dppMStDlddOaFh17tZUUq8
	7denO4B0mx1p2S3mW5NO2I0e+We2b1EaC0QERLoybw/cf6Jd+
X-Google-Smtp-Source: AGHT+IHi4KV+JtS0Yup9YLsW4GC+ypeG73864X60BTfpHdywmbKBm8ywDW8L461FCSiJw7YnCk6vpvBnOXWQokByAkE=
X-Received: by 2002:a05:6870:1197:b0:220:fffc:e085 with SMTP id
 23-20020a056870119700b00220fffce085mr10399622oau.18.1710332764089; Wed, 13
 Mar 2024 05:26:04 -0700 (PDT)
MIME-Version: 1.0
References: 
 <740404f0-3da9-4ae5-b4a5-b24cb2907e7d@suse.com> 
 <064ec76a-4957-448b-9afe-1bd264fd81c7@suse.com> 
In-Reply-To: 
From: George Dunlap 
Date: Wed, 13 Mar 2024 12:25:53 +0000
Message-ID: 
Subject: Re: [PATCH v3] x86/PoD: tie together P2M update and increment of
 entry count
To: Jan Beulich 
Cc: "xen-devel@lists.xenproject.org" , 
	Andrew Cooper , Wei Liu , 
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Mar 13, 2024 at 12:25=E2=80=AFPM George Dunlap  wrote:
> I keep missing your post-commit-message remarks due to the way I'm
> applying your series.

Er, just to be clear, this is a problem with my workflow, not with
your patches...

 -George


From xen-devel-bounces@lists.xenproject.org Wed Mar 13 12:28:35 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 12:28:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692402.1079489 (Exim 4.92)
	(envelope-from )
	id 1rkNik-0005eN-BB; Wed, 13 Mar 2024 12:28:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692402.1079489; Wed, 13 Mar 2024 12:28:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkNik-0005eG-8Z; Wed, 13 Mar 2024 12:28:34 +0000
Received: by outflank-mailman (input) for mailman id 692402;
 Wed, 13 Mar 2024 12:28:33 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkNii-0005e0-WB
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 12:28:32 +0000
Received: from mail-ua1-x92f.google.com (mail-ua1-x92f.google.com
 [2607:f8b0:4864:20::92f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 33b6ac3f-e135-11ee-afdd-a90da7624cb6;
 Wed, 13 Mar 2024 13:28:31 +0100 (CET)
Received: by mail-ua1-x92f.google.com with SMTP id
 a1e0cc1a2514c-7dc3a92c4b8so226409241.0
 for ; Wed, 13 Mar 2024 05:28:32 -0700 (PDT)
Received: from georged-x-u.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 ne7-20020a056214424700b00690dbc390dcsm2283874qvb.89.2024.03.13.05.28.29
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 13 Mar 2024 05:28:30 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 33b6ac3f-e135-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1710332910; x=1710937710; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:from:to:cc:subject:date:message-id:reply-to;
        bh=N/gG4e04OlvTPcRsxemRlv/QFnImY3oZ7Z0GxspCzBQ=;
        b=A7gdLSso5xAH3KuOhcnIpho9ibounN9Ex1OKU07/NTofKZ+w/uHgx5OiWTIMtyoqJM
         LrfwUkoqomiscqF1OJaCf36D+VSa0JY07LOk1vNpydhpqB8PfvqB7SAgIhS97+AxwEU6
         W2qd2cpr3BI3cjGGRF+enD56qrb8mN+XZm0f8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710332910; x=1710937710;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=N/gG4e04OlvTPcRsxemRlv/QFnImY3oZ7Z0GxspCzBQ=;
        b=FoPEVw66IuCOhS/fSx9oxnBIDFPKd6ykY427YifwvIRRPH3B1CRqMJpKel6limobkr
         uGC2BeuHHB8hQQ36VqcUQrUXP99wV48LUtY7Zgdmxvo95Ulzsnf5hh1xXVZmbK4CnKeZ
         FYA//Kyw6fCi9B1HTjiJl5x+mshHwSvkXynpoI6iZRexANzWEXVFbfUvMAW704WDeSLH
         rRgxsZaGf+e5hLJrd4SvYp5ZHUVVA/WTQpZP6CpKoniZWqkN6myxSt/3gYmi53RHnr2R
         cLvXkN6jdvGrCoUZ1BwSEMgavkUTYpQrcGz3sYGuOHyfMtG/bGaZ4bDXkZRZcMaQZdEm
         TIAQ==
X-Gm-Message-State: AOJu0Yz1i388ac383EgN7PrungB58j5hQ2Cizjp7XI9BDuCTYQ/xyIgy
	uQMKfmSpqsPNQNZBcENOHbzwNdeU8tkGdDzfXw4SZJ6b7XjERgO18LKBVjnQDzRNbDaCX8ilKKb
	0
X-Google-Smtp-Source: AGHT+IEVZ9jkA8cU8kiKfUtF/Gmqt5BEut+6B6N+5C5V/HiOCOmTvf2aM7XtgkHVehpP3uSBg3dFPA==
X-Received: by 2002:a05:6102:32ca:b0:473:44f2:caae with SMTP id o10-20020a05610232ca00b0047344f2caaemr8385482vss.21.1710332910659;
        Wed, 13 Mar 2024 05:28:30 -0700 (PDT)
From: George Dunlap 
To: xen-devel@lists.xenproject.org
Cc: George Dunlap 
Subject: [PATCH v2 0/3] AMD Nested Virt Preparation
Date: Wed, 13 Mar 2024 12:24:51 +0000
Message-Id: <20240313122454.965566-1-george.dunlap@cloud.com>
X-Mailer: git-send-email 2.25.1
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This series lays the groundwork for revamp of the AMD nested virt
functionality.  The first two patches are clean-ups or reorganizations
of existing code.  The final patch is the first major step towards making
the feature supportable: allowing Xen to refuse nested virt support if certain
hardware features are not present.

George Dunlap (3):
  x86: Move SVM features exposed to guest into hvm_max_cpu_policy
  nestedsvm: Disable TscRateMSR
  svm/nestedsvm: Introduce nested capabilities bit

 docs/designs/nested-svm-cpu-features.md      | 111 +++++++++++++++++++
 xen/arch/x86/cpu-policy.c                    |  29 ++---
 xen/arch/x86/domain.c                        |   6 +
 xen/arch/x86/hvm/nestedhvm.c                 |  10 ++
 xen/arch/x86/hvm/svm/nestedsvm.c             |  16 ++-
 xen/arch/x86/hvm/svm/svm.c                   |  57 ----------
 xen/arch/x86/hvm/vmx/vvmx.c                  |   8 ++
 xen/arch/x86/include/asm/hvm/hvm.h           |  16 ++-
 xen/arch/x86/include/asm/hvm/nestedhvm.h     |   4 +
 xen/arch/x86/include/asm/hvm/svm/nestedsvm.h |   5 -
 10 files changed, 184 insertions(+), 78 deletions(-)
 create mode 100644 docs/designs/nested-svm-cpu-features.md

-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Wed Mar 13 12:28:35 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 12:28:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692403.1079499 (Exim 4.92)
	(envelope-from )
	id 1rkNil-0005vL-If; Wed, 13 Mar 2024 12:28:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692403.1079499; Wed, 13 Mar 2024 12:28:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkNil-0005vE-Ft; Wed, 13 Mar 2024 12:28:35 +0000
Received: by outflank-mailman (input) for mailman id 692403;
 Wed, 13 Mar 2024 12:28:33 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkNij-0005e0-Ls
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 12:28:33 +0000
Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com
 [2607:f8b0:4864:20::22f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 34356dca-e135-11ee-afdd-a90da7624cb6;
 Wed, 13 Mar 2024 13:28:32 +0100 (CET)
Received: by mail-oi1-x22f.google.com with SMTP id
 5614622812f47-3c21a3120feso2612387b6e.3
 for ; Wed, 13 Mar 2024 05:28:32 -0700 (PDT)
Received: from georged-x-u.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 ne7-20020a056214424700b00690dbc390dcsm2283874qvb.89.2024.03.13.05.28.30
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 13 Mar 2024 05:28:31 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 34356dca-e135-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1710332911; x=1710937711; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=GCwOpLYs0LxuV2LN5cgSdDy/7vlzfUoEPoHbwcZNVf0=;
        b=XG/MOe8ajsSjz5XAY63g5SIBTY3OkiyOXV/VXim/kI1Kl4M6Vs37ywG5Sr8d3v77xi
         Bil4WOv/6hdbh2gqmtj+N2PFVEPpdpmi7/VlbH898HXSRWp9DwyqkbH/0U/eThpJmt5K
         C6Cr48dNj3zP6nPDIkT0wOFXAiwgtIG5m2OsU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710332911; x=1710937711;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=GCwOpLYs0LxuV2LN5cgSdDy/7vlzfUoEPoHbwcZNVf0=;
        b=USOMqE3OJB216yc1cueE3q1Ec9T092w6BB7L57hOIlgF4KmlKbyBTD4v4eaOCQWhfe
         +ALshh9taJCcaPmZZGFyWwcBeuZPdou8nt9LErnekkB1nTlOr3C0DPvVYm90ygdSNyAN
         fesgDor5xp0wjuy8nMV74/kP2+n7Ph5O6MD4hCpgJWTag3onquEXm9LdTW1wLO7l+XuA
         RJSQ5n+Oc1lSS2YFvQEMc02a3NDmc2nEyiR9gD1krXP9mcwFl77UE80oasI98nodeoWZ
         z1cjXPf69c/eM/x0nD9MF6SB3fKgjHp2ZyQEud6k6yrf95pKw4T5yHB6wuhtA0JhtFJL
         Soyg==
X-Gm-Message-State: AOJu0YzO4TUUOmZ4r9xDBfBkasMKchsWkC12ft7d+apqaTT0ho4Ud4L2
	8HVV6Mgqa+UEUFN1X2tpbSA+H4WewD+Smj2XamWsp9sMd3p8sKa4giFRmuWRJBEKNsHSK+5kZxU
	/
X-Google-Smtp-Source: AGHT+IHR9DN+7lcvO4/7WeenkBKRhBNcXU7Vg81kDU+bivxwGjowDiMk22Rx8pE3AMmCbhgbrwU/wg==
X-Received: by 2002:a05:6808:3021:b0:3c2:1881:f015 with SMTP id ay33-20020a056808302100b003c21881f015mr14877332oib.15.1710332911502;
        Wed, 13 Mar 2024 05:28:31 -0700 (PDT)
From: George Dunlap 
To: xen-devel@lists.xenproject.org
Cc: George Dunlap 
Subject: [PATCH v2 1/3] x86: Move SVM features exposed to guest into hvm_max_cpu_policy
Date: Wed, 13 Mar 2024 12:24:52 +0000
Message-Id: <20240313122454.965566-2-george.dunlap@cloud.com>
X-Mailer: git-send-email 2.25.1
In-Reply-To: <20240313122454.965566-1-george.dunlap@cloud.com>
References: <20240313122454.965566-1-george.dunlap@cloud.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Currently (nested) SVM features we're willing to expose to the guest
are defined in calculate_host_policy, and stored in host_cpu_policy.
This is the wrong place for this; move it into
calculate_hvm_max_policy(), and store it in hvm_max_cpu_policy.

Signed-off-by: George Dunlap 
---
v2:
- New
---
 xen/arch/x86/cpu-policy.c | 30 +++++++++++++++++-------------
 1 file changed, 17 insertions(+), 13 deletions(-)

diff --git a/xen/arch/x86/cpu-policy.c b/xen/arch/x86/cpu-policy.c
index 2acc27632f..bd047456eb 100644
--- a/xen/arch/x86/cpu-policy.c
+++ b/xen/arch/x86/cpu-policy.c
@@ -398,19 +398,6 @@ static void __init calculate_host_policy(void)
     if ( vpmu_mode == XENPMU_MODE_OFF )
         p->basic.raw[0xa] = EMPTY_LEAF;
 
-    if ( p->extd.svm )
-    {
-        /* Clamp to implemented features which require hardware support. */
-        p->extd.raw[0xa].d &= ((1u << SVM_FEATURE_NPT) |
-                               (1u << SVM_FEATURE_LBRV) |
-                               (1u << SVM_FEATURE_NRIPS) |
-                               (1u << SVM_FEATURE_PAUSEFILTER) |
-                               (1u << SVM_FEATURE_DECODEASSISTS));
-        /* Enable features which are always emulated. */
-        p->extd.raw[0xa].d |= ((1u << SVM_FEATURE_VMCBCLEAN) |
-                               (1u << SVM_FEATURE_TSCRATEMSR));
-    }
-
     /* 0x000000ce  MSR_INTEL_PLATFORM_INFO */
     /* probe_cpuid_faulting() sanity checks presence of MISC_FEATURES_ENABLES */
     p->platform_info.cpuid_faulting = cpu_has_cpuid_faulting;
@@ -741,6 +728,23 @@ static void __init calculate_hvm_max_policy(void)
     if ( !cpu_has_vmx )
         __clear_bit(X86_FEATURE_PKS, fs);
 
+    /* 
+     * Make adjustments to possible (nested) virtualization features exposed
+     * to the guest
+     */
+    if ( p->extd.svm )
+    {
+        /* Clamp to implemented features which require hardware support. */
+        p->extd.raw[0xa].d &= ((1u << SVM_FEATURE_NPT) |
+                               (1u << SVM_FEATURE_LBRV) |
+                               (1u << SVM_FEATURE_NRIPS) |
+                               (1u << SVM_FEATURE_PAUSEFILTER) |
+                               (1u << SVM_FEATURE_DECODEASSISTS));
+        /* Enable features which are always emulated. */
+        p->extd.raw[0xa].d |= ((1u << SVM_FEATURE_VMCBCLEAN) |
+                               (1u << SVM_FEATURE_TSCRATEMSR));
+    }
+    
     guest_common_max_feature_adjustments(fs);
     guest_common_feature_adjustments(fs);
 
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Wed Mar 13 12:28:37 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 12:28:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692404.1079510 (Exim 4.92)
	(envelope-from )
	id 1rkNin-0006BN-Qn; Wed, 13 Mar 2024 12:28:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692404.1079510; Wed, 13 Mar 2024 12:28:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkNin-0006BE-Lu; Wed, 13 Mar 2024 12:28:37 +0000
Received: by outflank-mailman (input) for mailman id 692404;
 Wed, 13 Mar 2024 12:28:36 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkNim-0005zY-34
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 12:28:36 +0000
Received: from mail-qv1-xf29.google.com (mail-qv1-xf29.google.com
 [2607:f8b0:4864:20::f29])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3509b218-e135-11ee-a1ee-f123f15fe8a2;
 Wed, 13 Mar 2024 13:28:34 +0100 (CET)
Received: by mail-qv1-xf29.google.com with SMTP id
 6a1803df08f44-690d75c73f4so5508506d6.2
 for ; Wed, 13 Mar 2024 05:28:34 -0700 (PDT)
Received: from georged-x-u.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 ne7-20020a056214424700b00690dbc390dcsm2283874qvb.89.2024.03.13.05.28.31
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 13 Mar 2024 05:28:32 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3509b218-e135-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1710332912; x=1710937712; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=VNtvCvVKyRw4GXggSPhElrHebwhUc61/SMy+94lsSrg=;
        b=dHIjsfKcg8niSCouyr/rIMw2kLu9EY3SgnNfAI/8UJZ4Y9eAtHeCXtDv8Jg5CkyaJD
         Qk5VszEuBpCJunEd0ZPDrkihiLlY+q/Ya+zi9udgDIV41kS8mL97FzyhDmWV4sIShWOd
         YZXZeTsf9lFiYhHwLNOO9FPtYUP4NUrKKzarg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710332912; x=1710937712;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=VNtvCvVKyRw4GXggSPhElrHebwhUc61/SMy+94lsSrg=;
        b=Qtz9EieZypo4Z5XiV9lOfAP3yuqwOypZ9deQHHtD+mnzoPCqmw3U0ISA7jFL6Jmqda
         Q7cTi1OsyyovJAwZ3BHorpNcI7o5RfGwG2BCGpZOyvgv4B5pJoCLHRZGQIQ/yNwDt3e2
         /3r/I+qcFr0ceHC9kN58JQLsslNc/gPdQ4gQ2eaMZHc+otlgET33uevh6tyEkJnvVbts
         qK++jcAZMm1Z614lSaz1xXdFZ83Dw0QRCnrfvDMa7pE/iZ4tSbZ7xGIIDZg8DFz93IW8
         puhFeXmfGBSrznsjlx0T8djz3H4oDdHJ1Fte77mEwGUVbxliLfjIzBweagPYlw2P/NiB
         CZgg==
X-Gm-Message-State: AOJu0YytvrMmfqVhkFNDgxIl0TrXnjDpSWrKYfjdXAVDehme4P+jwPyr
	AxKeIZ96etva1HdiNy83db0U8xP8/PJr1lluhseZ8oTgDOOlgKkKmwRVDCRl9hN8+O3Li13CV2H
	3
X-Google-Smtp-Source: AGHT+IF/KdWvuyDqVymLJAycdU5FsQxKLPPFfWzpL/H+tkCtimySwSD88mtlTNd7GStPiVdACuS6kQ==
X-Received: by 2002:a0c:c304:0:b0:691:1ca9:7e56 with SMTP id f4-20020a0cc304000000b006911ca97e56mr1344540qvi.0.1710332912693;
        Wed, 13 Mar 2024 05:28:32 -0700 (PDT)
From: George Dunlap 
To: xen-devel@lists.xenproject.org
Cc: George Dunlap ,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Wei Liu 
Subject: [PATCH v2 2/3] nestedsvm: Disable TscRateMSR
Date: Wed, 13 Mar 2024 12:24:53 +0000
Message-Id: <20240313122454.965566-3-george.dunlap@cloud.com>
X-Mailer: git-send-email 2.25.1
In-Reply-To: <20240313122454.965566-1-george.dunlap@cloud.com>
References: <20240313122454.965566-1-george.dunlap@cloud.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The primary purpose of TSC scaling, from our perspective, is to
maintain the fiction of an "invariant TSC" across migrates between
platforms with different clock speeds.

On AMD, the TscRateMSR CPUID bit is unconditionally enabled in the
"host cpuid", even if the hardware doesn't actually support it.
According to c/s fd14a1943c4 ("nestedsvm: Support TSC Rate MSR"),
testing showed that emulating TSC scaling in an L1 was more expensive
than emulating TSC scaling on an L0 (due to extra sets of vmexit /
vmenter).

However, the current implementation seems to be broken.

First of all, the final L2 scaling ratio should be a composition of
the L0 scaling ratio and the L1 scaling ratio; there's no indication
this is being done anywhere.

Secondly, it's not clear that the L1 tsc scaling ratio actually
affects the L0 tsc scaling ratio.  The stored value (ns_tscratio) is
used to affect the tsc *offset*, but doesn't seem to actually be
factored into d->hvm.tsc_scaling_ratio.  (Which shouldn't be
per-domain anyway, but per-vcpu.)  Having the *offset* scaled
according to the nested scaling without the actual RDTSC itself also
being scaled has got to produce inconsistent results.

For now, just disable the functionality entirely until we can
implement it properly:

- Don't set TSCRATEMSR in the host CPUID policy

- Remove MSR_AMD64_TSC_RATIO emulation handling, so that the guest
  guests a #GP if it tries to access them (as it should when
  TSCRATEMSR is clear)

- Remove ns_tscratio from struct nestedhvm, and all code that touches
  it

Unfortunately this means ripping out the scaling calculation stuff as
well, since it's only used in the nested case; it's there in the git
tree if we need it for reference when we re-introduce it.

Signed-off-by: George Dunlap 
---
v2:
- Port over move to hvm_max_cpu_policy

CC: Jan Beulich 
CC: Andrew Cooper 
CC: "Roger Pau Monné" 
CC: Wei Liu 
---
 xen/arch/x86/cpu-policy.c                    |  3 +-
 xen/arch/x86/hvm/svm/nestedsvm.c             |  2 -
 xen/arch/x86/hvm/svm/svm.c                   | 57 --------------------
 xen/arch/x86/include/asm/hvm/svm/nestedsvm.h |  5 --
 4 files changed, 1 insertion(+), 66 deletions(-)

diff --git a/xen/arch/x86/cpu-policy.c b/xen/arch/x86/cpu-policy.c
index bd047456eb..5952ff20e6 100644
--- a/xen/arch/x86/cpu-policy.c
+++ b/xen/arch/x86/cpu-policy.c
@@ -741,8 +741,7 @@ static void __init calculate_hvm_max_policy(void)
                                (1u << SVM_FEATURE_PAUSEFILTER) |
                                (1u << SVM_FEATURE_DECODEASSISTS));
         /* Enable features which are always emulated. */
-        p->extd.raw[0xa].d |= ((1u << SVM_FEATURE_VMCBCLEAN) |
-                               (1u << SVM_FEATURE_TSCRATEMSR));
+        p->extd.raw[0xa].d |= (1u << SVM_FEATURE_VMCBCLEAN);
     }
     
     guest_common_max_feature_adjustments(fs);
diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c
index e4e01add8c..a5319ab729 100644
--- a/xen/arch/x86/hvm/svm/nestedsvm.c
+++ b/xen/arch/x86/hvm/svm/nestedsvm.c
@@ -146,8 +146,6 @@ int cf_check nsvm_vcpu_reset(struct vcpu *v)
     svm->ns_msr_hsavepa = INVALID_PADDR;
     svm->ns_ovvmcb_pa = INVALID_PADDR;
 
-    svm->ns_tscratio = DEFAULT_TSC_RATIO;
-
     svm->ns_cr_intercepts = 0;
     svm->ns_dr_intercepts = 0;
     svm->ns_exception_intercepts = 0;
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index b551eac807..34b9f603bc 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -777,43 +777,6 @@ static int cf_check svm_get_guest_pat(struct vcpu *v, u64 *gpat)
     return 1;
 }
 
-static uint64_t scale_tsc(uint64_t host_tsc, uint64_t ratio)
-{
-    uint64_t mult, frac, scaled_host_tsc;
-
-    if ( ratio == DEFAULT_TSC_RATIO )
-        return host_tsc;
-
-    /*
-     * Suppose the most significant 32 bits of host_tsc and ratio are
-     * tsc_h and mult, and the least 32 bits of them are tsc_l and frac,
-     * then
-     *     host_tsc * ratio * 2^-32
-     *     = host_tsc * (mult * 2^32 + frac) * 2^-32
-     *     = host_tsc * mult + (tsc_h * 2^32 + tsc_l) * frac * 2^-32
-     *     = host_tsc * mult + tsc_h * frac + ((tsc_l * frac) >> 32)
-     *
-     * Multiplications in the last two terms are between 32-bit integers,
-     * so both of them can fit in 64-bit integers.
-     *
-     * Because mult is usually less than 10 in practice, it's very rare
-     * that host_tsc * mult can overflow a 64-bit integer.
-     */
-    mult = ratio >> 32;
-    frac = ratio & ((1ULL << 32) - 1);
-    scaled_host_tsc  = host_tsc * mult;
-    scaled_host_tsc += (host_tsc >> 32) * frac;
-    scaled_host_tsc += ((host_tsc & ((1ULL << 32) - 1)) * frac) >> 32;
-
-    return scaled_host_tsc;
-}
-
-static uint64_t svm_get_tsc_offset(uint64_t host_tsc, uint64_t guest_tsc,
-    uint64_t ratio)
-{
-    return guest_tsc - scale_tsc(host_tsc, ratio);
-}
-
 static void cf_check svm_set_tsc_offset(struct vcpu *v, u64 offset, u64 at_tsc)
 {
     struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb;
@@ -832,18 +795,8 @@ static void cf_check svm_set_tsc_offset(struct vcpu *v, u64 offset, u64 at_tsc)
 
     if ( nestedhvm_vcpu_in_guestmode(v) )
     {
-        struct nestedsvm *svm = &vcpu_nestedsvm(v);
-
         n2_tsc_offset = vmcb_get_tsc_offset(n2vmcb) -
                         vmcb_get_tsc_offset(n1vmcb);
-        if ( svm->ns_tscratio != DEFAULT_TSC_RATIO )
-        {
-            uint64_t guest_tsc = hvm_get_guest_tsc_fixed(v, at_tsc);
-
-            n2_tsc_offset = svm_get_tsc_offset(guest_tsc,
-                                               guest_tsc + n2_tsc_offset,
-                                               svm->ns_tscratio);
-        }
         vmcb_set_tsc_offset(n1vmcb, offset);
     }
 
@@ -1921,10 +1874,6 @@ static int cf_check svm_msr_read_intercept(
         *msr_content = nsvm->ns_msr_hsavepa;
         break;
 
-    case MSR_AMD64_TSC_RATIO:
-        *msr_content = nsvm->ns_tscratio;
-        break;
-
     case MSR_AMD_OSVW_ID_LENGTH:
     case MSR_AMD_OSVW_STATUS:
         if ( !d->arch.cpuid->extd.osvw )
@@ -2103,12 +2052,6 @@ static int cf_check svm_msr_write_intercept(
             goto gpf;
         break;
 
-    case MSR_AMD64_TSC_RATIO:
-        if ( msr_content & TSC_RATIO_RSVD_BITS )
-            goto gpf;
-        nsvm->ns_tscratio = msr_content;
-        break;
-
     case MSR_IA32_MCx_MISC(4): /* Threshold register */
     case MSR_F10_MC4_MISC1 ... MSR_F10_MC4_MISC3:
         /*
diff --git a/xen/arch/x86/include/asm/hvm/svm/nestedsvm.h b/xen/arch/x86/include/asm/hvm/svm/nestedsvm.h
index 406fc082b1..45d658ad01 100644
--- a/xen/arch/x86/include/asm/hvm/svm/nestedsvm.h
+++ b/xen/arch/x86/include/asm/hvm/svm/nestedsvm.h
@@ -18,11 +18,6 @@ struct nestedsvm {
      */
     uint64_t ns_ovvmcb_pa;
 
-    /* virtual tscratio holding the value l1 guest writes to the
-     * MSR_AMD64_TSC_RATIO MSR.
-     */
-    uint64_t ns_tscratio;
-
     /* Cached real intercepts of the l2 guest */
     uint32_t ns_cr_intercepts;
     uint32_t ns_dr_intercepts;
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Wed Mar 13 12:28:40 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 12:28:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692405.1079520 (Exim 4.92)
	(envelope-from )
	id 1rkNiq-0006Xv-2f; Wed, 13 Mar 2024 12:28:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692405.1079520; Wed, 13 Mar 2024 12:28:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkNip-0006Xm-UD; Wed, 13 Mar 2024 12:28:39 +0000
Received: by outflank-mailman (input) for mailman id 692405;
 Wed, 13 Mar 2024 12:28:39 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkNip-0005zY-33
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 12:28:39 +0000
Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com
 [2607:f8b0:4864:20::e30])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 36e6b213-e135-11ee-a1ee-f123f15fe8a2;
 Wed, 13 Mar 2024 13:28:37 +0100 (CET)
Received: by mail-vs1-xe30.google.com with SMTP id
 ada2fe7eead31-4726c259cc9so202522137.0
 for ; Wed, 13 Mar 2024 05:28:37 -0700 (PDT)
Received: from georged-x-u.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 ne7-20020a056214424700b00690dbc390dcsm2283874qvb.89.2024.03.13.05.28.32
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 13 Mar 2024 05:28:34 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 36e6b213-e135-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1710332916; x=1710937716; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=NhL6carBpJAEJcZDaFIRwTP2onUiQlD3W4fFGQ9k40Q=;
        b=dVL7WNClQmrDcfAxtyI++4r5yeaLaZwINuGIy4KawlKNo4x7feTK7l8gf/2hOHhsuB
         KwdNBPOeu0bIfVBKSx/gvahNVbP6nY4fCeM5/Mym7darsfb1qanzIa9clf2lFSubskoH
         lUMVJevvqVATb4wrbPzqTw6zF0Nf2o4KlS6kQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710332916; x=1710937716;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=NhL6carBpJAEJcZDaFIRwTP2onUiQlD3W4fFGQ9k40Q=;
        b=gB5xk5wCc+xQxvZr4Ake+cBPqQDoAv5B0wl2e1oWh23LqsIppK6k8MhISavnG+6+p7
         R9XSoPYoQta0enreol7yxz91p+Kumfg7ZYqVQcvYrLNWsP9YgMX7duZ7j7NYAn/hnb0g
         ilD7NIH89FRLaanBR41UUU+yGfP/r/2RBFrQ2PRMHhBm6QCBKo5fk/NvJ4SbES+Oqa8k
         Y93/DWkToTfN65wTUnKIjuB9irXeGEeErp1oAdHpLyCZisWPuH0T0ZWEWCDEeeER4+V6
         IbpiCZa+c7thiU/2QBev39oHNMKWY3FiWaRXHJFcp5AtmfFQYE9p6xNx6n/UaQ000/BJ
         zvkw==
X-Gm-Message-State: AOJu0Yzw4VMbkZxoeSGVH/PdgkHbm4nM5C6QHN7v8DEH0yAOUj+tWIkP
	apULcm2G2gJdQl6iTefzqWuG45C3YUmmJ0kaBiKD6cEcmM5IgV/vJFzIf4TkltJXSmmXrLwtYsU
	l
X-Google-Smtp-Source: AGHT+IFFv7kFFTxdBKMJcSkfT8J6KHRXut4JimbWmQW5uk6S+fSYjizgtJgRKE7DIltJJDUa9uQdtQ==
X-Received: by 2002:a05:6102:11ed:b0:473:4d73:5e1c with SMTP id e13-20020a05610211ed00b004734d735e1cmr3528715vsg.9.1710332914410;
        Wed, 13 Mar 2024 05:28:34 -0700 (PDT)
From: George Dunlap 
To: xen-devel@lists.xenproject.org
Cc: George Dunlap ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini ,
	Wei Liu ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Jun Nakajima ,
	Kevin Tian 
Subject: [PATCH v2 3/3] svm/nestedsvm: Introduce nested capabilities bit
Date: Wed, 13 Mar 2024 12:24:54 +0000
Message-Id: <20240313122454.965566-4-george.dunlap@cloud.com>
X-Mailer: git-send-email 2.25.1
In-Reply-To: <20240313122454.965566-1-george.dunlap@cloud.com>
References: <20240313122454.965566-1-george.dunlap@cloud.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

In order to make implementation and testing tractable, we will require
specific host functionality.  Add a nested_virt bit to hvm_funcs.caps,
and return an error if a domain is created with nested virt and this
bit isn't set.  Create VMX and SVM callbacks to be executed from
start_nested_svm(), which is guaranteed to execute after all
command-line options have been procesed.

For VMX, start with always enabling it if HAP is present; this
shouldn't change current behvior.

For SVM, require some basic functionality, adding a document
explaining the rationale.

NB that only SVM CPUID bits 0-7 have been considered.  Bits 10-16 may
be considered in a follow-up patch.

Signed-off-by: George Dunlap 
---
v2:
 - Fixed typo in title
 - Added hvm_nested_virt_supported() def for !CONFIG_HVM
 - Rebased over previous changes
 - Tweak some wording in document
 - Require npt rather than nrips twice
 - Remove stray __init from header
 - Set caps.nested_virt from callback from nestedhvm_setup()

CC: Andrew Cooper 
CC: George Dunlap 
CC: Jan Beulich 
CC: Julien Grall 
CC: Stefano Stabellini 
CC: Wei Liu 
CC: "Roger Pau Monné" 
CC: Jun Nakajima 
CC: Kevin Tian 
---
 docs/designs/nested-svm-cpu-features.md  | 111 +++++++++++++++++++++++
 xen/arch/x86/domain.c                    |   6 ++
 xen/arch/x86/hvm/nestedhvm.c             |  10 ++
 xen/arch/x86/hvm/svm/nestedsvm.c         |  14 +++
 xen/arch/x86/hvm/vmx/vvmx.c              |   8 ++
 xen/arch/x86/include/asm/hvm/hvm.h       |  16 +++-
 xen/arch/x86/include/asm/hvm/nestedhvm.h |   4 +
 7 files changed, 168 insertions(+), 1 deletion(-)

diff --git a/docs/designs/nested-svm-cpu-features.md b/docs/designs/nested-svm-cpu-features.md
new file mode 100644
index 0000000000..837a96df05
--- /dev/null
+++ b/docs/designs/nested-svm-cpu-features.md
@@ -0,0 +1,111 @@
+# Nested SVM (AMD) CPUID requirements
+
+The first step in making nested SVM production-ready is to make sure
+that all features are implemented and well-tested.  To make this
+tractable, we will initially be limiting the "supported" range of
+nested virt to a specific subset of host and guest features.  This
+document describes the criteria for deciding on features, and the
+rationale behind each feature.
+
+For AMD, all virtualization-related features can be found in CPUID
+leaf 8000000A:edx
+
+# Criteria
+
+- Processor support: At a minimum we want to support processors from
+  the last 5 years.  All things being equal, we'd prefer to cover
+  older processors than not.  Bits 0:7 were available in the very
+  earliest processors; and even through bit 15 we should be pretty
+  good support-wise.
+
+- Faithfulness to hardware: We need the behavior of the "virtual cpu"
+  from the L1 hypervisor's perspective to be as close as possible to
+  the original hardware.  In particular, the behavior of the hardware
+  on error paths 1) is not easy to understand or test, 2) can be the
+  source of surprising vulnerabiliies.  (See XSA-7 for an example of a
+  case where subtle error-handling differences can open up a privilege
+  escalation.)  We should avoid emulating any bit of the hardware with
+  complex error paths if we can at all help it.
+
+- Cost of implementation: We want to minimize the cost of
+  implementation (where this includes bringing an existing sub-par
+  implementation up to speed).  All things being equal, we'll favor a
+  configuration which does not require any new implementation.
+
+- Performance: All things being equal, we'd prefer to choose a set of
+  L0 / L1 CPUID bits that are faster than slower.
+
+
+# Bits
+
+- 0 `NP` *Nested Paging*: Required both for L0 and L1.
+
+  Based primarily on faithfulness and performance, as well as
+  potential cost of implementation.  Available on earliest hardware,
+  so no compatibility issues.
+
+- 1 `LbrVirt` *LBR / debugging virtualization*: Require for L0 and L1.
+
+  For L0 this is required for performance: There's no way to tell the
+  guests not to use the LBR-related registers; and if the guest does,
+  then you have to save and restore all LBR-related registers on
+  context switch, which is prohibitive.  Furthermore, the additional
+  emulation risks a security-relevant difference to come up.
+
+  Providing it to L1 when we have it in L0 is basically free, and
+  already implemented.
+
+  Just require it and provide it.
+
+- 2 `SVML` *SVM Lock*: Not required for L0, not provided to L1
+
+  Seems to be aboult enabling an operating system to prevent "blue
+  pill" attacks against itself.
+
+  Xen doesn't use it, nor provide it; so it would need to be
+  implementend.  The best way to protect a guest OS is to leave nested
+  virt disabled in the tools.
+
+- 3 `NRIPS` NRIP Save: Require for both L0 and L1
+
+  If NRIPS is not present, the software interrupt injection
+  functionality can't be used; and Xen has to emulate it.  That's
+  another source of potential security issues.  If hardware supports
+  it, then providing it to guest is basically free.
+
+- 4 `TscRateMsr`: Not required by L0, not provided to L1
+
+  The main putative use for this would be trying to maintain an
+  invariant TSC across cores with different clock speeds, or after a
+  migrate.  Unlike others, this doesn't have an error path to worry
+  about compatibility-wise; and according to tests done when nestedSVM
+  was first implemented, it's actually faster to emliate TscRateMSR in
+  the L0 hypervisor than for L1 to attempt to emulate it itself.
+
+  However, using this properly in L0 will take some implementation
+  effort; and composing it properly with L1 will take even more
+  effort.  Just leave it off for now.
+
+ - 5 `VmcbClean`: VMCB Clean Bits: Not required by L0, provide to L1
+
+  This is a pure optimization, both on the side of the L0 and L1.  The
+  implementaiton for L1 is entirely Xen-side, so can be provided even
+  on hardware that doesn't provide it.  And it's purely an
+  optimization, so could be "implemented" by ignoring the bits
+  entirely.
+
+  As such, we don't need to require it for L0; and as it's already
+  implemented, no reason not to provide it to L1.  Before this feature
+  was available those bits were marked SBZ ("should be zero"); setting
+  them was already advertised to cause unpredictable behavior.
+
+- 6 `FlushByAsid`: Require for L0, provide to L1
+
+  This is cheap and easy to use for L0 and to provide to the L1;
+  there's no reson not to just pass it through.
+
+- 7 `DecodeAssists`: Require for L0, provide to L1
+
+  Using it in L0 reduces the chance that we'll make some sort of error
+  in the decode path.  And if hardware supports it, it's easy enough
+  to provide to the L1.
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index bda853e3c9..a25f498265 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -673,6 +673,12 @@ int arch_sanitise_domain_config(struct xen_domctl_createdomain *config)
          */
         config->flags |= XEN_DOMCTL_CDF_oos_off;
 
+    if ( nested_virt && !hvm_nested_virt_supported() )
+    {
+        dprintk(XENLOG_INFO, "Nested virt requested but not available\n");
+        return -EINVAL;        
+    }
+
     if ( nested_virt && !hap )
     {
         dprintk(XENLOG_INFO, "Nested virt not supported without HAP\n");
diff --git a/xen/arch/x86/hvm/nestedhvm.c b/xen/arch/x86/hvm/nestedhvm.c
index 12bf7172b8..451c4da6d4 100644
--- a/xen/arch/x86/hvm/nestedhvm.c
+++ b/xen/arch/x86/hvm/nestedhvm.c
@@ -150,6 +150,16 @@ static int __init cf_check nestedhvm_setup(void)
     __clear_bit(0x80, shadow_io_bitmap[0]);
     __clear_bit(0xed, shadow_io_bitmap[1]);
 
+    /* 
+     * NB this must be called after all command-line processing has been
+     * done, so that if (for example) HAP is disabled, nested virt is
+     * disabled as well.
+     */
+    if ( cpu_has_vmx )
+        start_nested_vmx(&hvm_funcs);
+    else if ( cpu_has_svm )
+        start_nested_svm(&hvm_funcs);
+
     return 0;
 }
 __initcall(nestedhvm_setup);
diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c
index a5319ab729..ad2e9f5c35 100644
--- a/xen/arch/x86/hvm/svm/nestedsvm.c
+++ b/xen/arch/x86/hvm/svm/nestedsvm.c
@@ -1666,3 +1666,17 @@ void svm_nested_features_on_efer_update(struct vcpu *v)
         }
     }
 }
+
+void __init start_nested_svm(struct hvm_function_table *hvm_function_table)
+{
+    /* 
+     * Required host functionality to support nested virt.  See
+     * docs/designs/nested-svm-cpu-features.md for rationale.
+     */
+    hvm_function_table->caps.nested_virt =
+        hvm_function_table->caps.hap && 
+        cpu_has_svm_lbrv &&
+        cpu_has_svm_nrips &&
+        cpu_has_svm_flushbyasid &&
+        cpu_has_svm_decode;
+}
diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index ece0aa243a..ed058d9d2b 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -2816,6 +2816,14 @@ void nvmx_set_cr_read_shadow(struct vcpu *v, unsigned int cr)
     __vmwrite(read_shadow_field, v->arch.hvm.nvcpu.guest_cr[cr]);
 }
 
+void __init start_nested_vmx(struct hvm_function_table *hvm_function_table)
+{
+    /* TODO: Require hardware support before enabling nested virt */
+    hvm_function_table->caps.nested_virt =
+        hvm_function_table->caps.hap;
+}
+
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/include/asm/hvm/hvm.h b/xen/arch/x86/include/asm/hvm/hvm.h
index 87a6935d97..e6f937fed7 100644
--- a/xen/arch/x86/include/asm/hvm/hvm.h
+++ b/xen/arch/x86/include/asm/hvm/hvm.h
@@ -97,7 +97,10 @@ struct hvm_function_table {
              singlestep:1,
             
              /* Hardware virtual interrupt delivery enable? */
-             virtual_intr_delivery:1;
+             virtual_intr_delivery:1,
+
+             /* Nested virt capabilities */
+             nested_virt:1;
     } caps;
 
     /*
@@ -654,6 +657,12 @@ static inline bool hvm_altp2m_supported(void)
     return hvm_funcs.caps.altp2m;
 }
 
+/* Returns true if we have the minimum hardware requirements for nested virt */
+static inline bool hvm_nested_virt_supported(void)
+{
+    return hvm_funcs.caps.nested_virt;
+}
+
 /* updates the current hardware p2m */
 static inline void altp2m_vcpu_update_p2m(struct vcpu *v)
 {
@@ -797,6 +806,11 @@ static inline bool hvm_hap_supported(void)
     return false;
 }
 
+static inline bool hvm_nested_virt_supported(void)
+{
+    return false;
+}
+
 static inline bool nhvm_vmcx_hap_enabled(const struct vcpu *v)
 {
     ASSERT_UNREACHABLE();
diff --git a/xen/arch/x86/include/asm/hvm/nestedhvm.h b/xen/arch/x86/include/asm/hvm/nestedhvm.h
index 56a2019e1b..0568acb25f 100644
--- a/xen/arch/x86/include/asm/hvm/nestedhvm.h
+++ b/xen/arch/x86/include/asm/hvm/nestedhvm.h
@@ -82,4 +82,8 @@ static inline bool vvmcx_valid(const struct vcpu *v)
     return vcpu_nestedhvm(v).nv_vvmcxaddr != INVALID_PADDR;
 }
 
+
+void start_nested_svm(struct hvm_function_table *);
+void start_nested_vmx(struct hvm_function_table *);
+
 #endif /* _HVM_NESTEDHVM_H */
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Wed Mar 13 13:06:06 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 13:06:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692426.1079529 (Exim 4.92)
	(envelope-from )
	id 1rkOIx-0004kk-Ty; Wed, 13 Mar 2024 13:05:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692426.1079529; Wed, 13 Mar 2024 13:05:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkOIx-0004kd-RD; Wed, 13 Mar 2024 13:05:59 +0000
Received: by outflank-mailman (input) for mailman id 692426;
 Wed, 13 Mar 2024 13:05:58 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkOIw-0004kX-Qs
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 13:05:58 +0000
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com
 [2a00:1450:4864:20::631])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6e13c694-e13a-11ee-a1ee-f123f15fe8a2;
 Wed, 13 Mar 2024 14:05:56 +0100 (CET)
Received: by mail-ej1-x631.google.com with SMTP id
 a640c23a62f3a-a4663b29334so49924066b.0
 for ; Wed, 13 Mar 2024 06:05:56 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 qw14-20020a170906fcae00b00a46647b6496sm216421ejb.155.2024.03.13.06.05.54
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 13 Mar 2024 06:05:55 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6e13c694-e13a-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710335156; x=1710939956; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=PG9X11rAKz0pdL4PSeFP3B9ILmrSKoHnHWalOxkEruY=;
        b=G3dpIAfMJf4q17muPSyuer7i4Kky7O+nrRfb8i8YBcidsgdLe27aNj6oDvv6ProDBo
         Z9IUDNtSwBArYlyYSXEG8AzymyUrFkGZ9Fck17X8rZrqQ0Y0nh0nbVOf7MWFkUYBBOnA
         bpHRGoNTNLD+T7xN/vJwUqKdYCqUOivqRbsw7TV+At5D7a20wTBWPH3/RodJtPcr+SZ8
         PoV4SJ2/5gjHypXQf5ntZ7qIHW95zbPuCt4AivkIef9natxBdqWBTJqvA4EjfJMhFUh7
         +3J9xX2ec7Xm+OhynfOwbL6Vb42aMUFou3nVMc+tB11zITA2W53t79uIcQp9ll8GfizP
         FLUg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710335156; x=1710939956;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=PG9X11rAKz0pdL4PSeFP3B9ILmrSKoHnHWalOxkEruY=;
        b=LbYXscX5JYvVYu4ct6IHXHtBHnezu8EoJD++9tW/RprjgjJGKlAYFJfqnLYFNaxmuH
         BdmndGErJvI4M7MV8lH5ZeeKQDk6ioeVp2Vk3azNUnuaB35IS3BrIsgyqf5JgY7K7vMe
         gSxXyEXSYfMqOmclcdpz19QI1MUAzki+pI2CnYSVb6M008e+caHUkSxh6/wdUYnOt90Z
         CXNzBMqiLY38gv3gKaLDv8oqbb1gnYN4Edpfmh2DEZE/oN0QKStUefAdM5gBiLtM5g8M
         e2YeXJkcj3gJUkNYYqjQvdeV3uU0Yg43J0viQoNBtrkPLoqvk9pcxvE2y5/cjuiMz8vv
         lmSg==
X-Forwarded-Encrypted: i=1; AJvYcCU0MZajachFBWqwO1LjtOLPPuElP9If26h0HT3uvbDjFC1ey+A+Ni8X+4PpSYfkEioML6pmWZSFhMr7QieW7nlAvToarxczVn6ZudBFPE8=
X-Gm-Message-State: AOJu0Yz9puQOFt7zT8TqK5J/z27o1/Yz6kYBf+mKQboQ92A4FKORp2X1
	gHp9QgYX0iHLO0WvWAQFqA+AWVqSCFvtLUOwu/GT1oOA5euYpE1HZox1PVHiSA==
X-Google-Smtp-Source: AGHT+IFkPMIZPIjhqYKbN/rjm5UbUFqyY38iqfvwMq0FV0MP1LKRlOeUm5DaFRmKkA+18ctxNHZVsw==
X-Received: by 2002:a17:907:367:b0:a46:637c:db67 with SMTP id rs7-20020a170907036700b00a46637cdb67mr547853ejb.5.1710335156115;
        Wed, 13 Mar 2024 06:05:56 -0700 (PDT)
Message-ID: <84ae44c0-7812-4532-a367-4763d9b44198@suse.com>
Date: Wed, 13 Mar 2024 14:05:54 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 5/9] x86/smp: call x2apic_ap_setup() earlier
Content-Language: en-US
To: Krystian Hebel 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org, Wei Liu ,
 Andrew Cooper 
References: 
 <7c13554e60cc76516922992b7faf911b91f99a2a.1699982111.git.krystian.hebel@3mdeb.com>
 
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 12.03.2024 17:02, Krystian Hebel wrote:
> 
> On 7.02.2024 18:02, Jan Beulich wrote:
>> On 14.11.2023 18:50, Krystian Hebel wrote:
>>> It used to be called from smp_callin(), however BUG_ON() was invoked on
>>> multiple occasions before that. It may end up calling machine_restart()
>>> which tries to get APIC ID for CPU running this code. If BSP detected
>>> that x2APIC is enabled, get_apic_id() will try to use it for all CPUs.
>>> Enabling x2APIC on secondary CPUs earlier protects against an endless
>>> loop of #GP exceptions caused by attempts to read IA32_X2APIC_APICID
>>> MSR while x2APIC is disabled in IA32_APIC_BASE.
>>>
>>> Signed-off-by: Krystian Hebel 
>>> ---
>>>   xen/arch/x86/smpboot.c | 9 ++++++++-
>>>   1 file changed, 8 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
>>> index 8ae65ab1769f..a3895dafa267 100644
>>> --- a/xen/arch/x86/smpboot.c
>>> +++ b/xen/arch/x86/smpboot.c
>>> @@ -184,7 +184,6 @@ static void smp_callin(void)
>>>        * update until we finish. We are free to set up this CPU: first the APIC.
>>>        */
>>>       Dprintk("CALLIN, before setup_local_APIC().\n");
>>> -    x2apic_ap_setup();
>>>       setup_local_APIC(false);
>>>   
>>>       /* Save our processor parameters. */
>>> @@ -351,6 +350,14 @@ void start_secondary(void *unused)
>>>       get_cpu_info()->xen_cr3 = 0;
>>>       get_cpu_info()->pv_cr3 = 0;
>>>   
>>> +    /*
>>> +     * BUG_ON() used in load_system_tables() and later code may end up calling
>>> +     * machine_restart() which tries to get APIC ID for CPU running this code.
>>> +     * If BSP detected that x2APIC is enabled, get_apic_id() will try to use it
>>> +     * for _all_ CPUs. Enable x2APIC on secondary CPUs now so we won't end up
>>> +     * with endless #GP loop.
>>> +     */
>>> +    x2apic_ap_setup();
>>>       load_system_tables();
>> While I find the argument convincing, I seem to recall that there was a
>> firm plan to have load_system_tables() as early as possible. Andrew?
> This is where the code failed for me during testing. How about moving
> x2apic_ap_setup() into load_system_tables(),

How does a call to x2apic_ap_setup() fit in a function named
load_system_tables()?

> just before BUG_ON? Or maybe
> move those BUG_ON one level higher, after load_system_tables() returns?

But they're there for a reason.

> Either way some code will end up in place it doesn't belong, but I'd 
> argue that
> BUG_ON is only useful if it itself doesn't crash.

I guess I don't understand this: That BUG_ON() is already guarded by a
system_state check, to prevent it uselessly hanging the system.

In any event - besides you still wanting to get input from Andrew, it
ought to be clear that anything unusual / unexpected will require extra
justification in the description.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Mar 13 13:11:34 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 13:11:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692429.1079539 (Exim 4.92)
	(envelope-from )
	id 1rkOOH-0006Xo-Fu; Wed, 13 Mar 2024 13:11:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692429.1079539; Wed, 13 Mar 2024 13:11:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkOOH-0006Xh-DQ; Wed, 13 Mar 2024 13:11:29 +0000
Received: by outflank-mailman (input) for mailman id 692429;
 Wed, 13 Mar 2024 13:11:28 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkOOG-0006Xb-CR
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 13:11:28 +0000
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com
 [2a00:1450:4864:20::531])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 331fdf1d-e13b-11ee-afdd-a90da7624cb6;
 Wed, 13 Mar 2024 14:11:27 +0100 (CET)
Received: by mail-ed1-x531.google.com with SMTP id
 4fb4d7f45d1cf-56845954ffeso5252543a12.2
 for ; Wed, 13 Mar 2024 06:11:27 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ef9-20020a05640228c900b00566a461e1ecsm4942944edb.73.2024.03.13.06.11.26
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 13 Mar 2024 06:11:26 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 331fdf1d-e13b-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710335487; x=1710940287; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=Ukep3jUkH4sPmqfRTOcW0WYTM94o9OLOjax8bs8jJRo=;
        b=AZQAOJLy150kymBl7E9zvqlnDR99N3FcmJRdCXJvtsGx0R4nUwHVUb+Sk31gaX7JHf
         Wx0sX4E3QyhdUI79ppuPZhSFVVhHMeg/mqGwMYSovuJUHCdACBrRSGJ9Sa8FP3AY98/1
         eWJUkl/bMpOY6V2PxgkmaHYj1Lvp0Kfe7l67zYq6TPRzFBOt6rgf1fDLvTJhe8Eb2ALZ
         RypMRYhqcpatkmHOF/eF24jQUi7KqkqWaVY1em3F7PUyPQE6p4XXoi72km77xqmcfxRb
         HWv0ycDzBJpVG12jkdfMOO4eVn3amuWlJEAD33Isq8RfhQeMrO14HW5WG42Bl//vokB3
         X7lQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710335487; x=1710940287;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=Ukep3jUkH4sPmqfRTOcW0WYTM94o9OLOjax8bs8jJRo=;
        b=M7a+CuIVR7Ks0sLLWFNKxMesVhY/BGoxjskniED9vlVM/8lLhvu1QjlVWgvISuNUBs
         a7N860stQUd9az8GBnQ7CufcuKmUygfDopCkFBgu354q9DZRGfH8dghR6/Hs3P5NWp9w
         PIyZMqpLLg9EealBLVGjO15e3MvYiGXbcXr7hvKvJC47xyJaV0hQO8f6fvl2/V5Rs3I8
         GYUkjshnQQWjFhTmLpNxi+d3u4sb9hJq7hhUMITdR5QJMSLfavDpbqXz3XFhQFH4rX0E
         KhaQ4/gxOCtie4dWqpm49n3P8vtUO7qTABJMg63dyRzce6x1N5/sb1G92Zv6fS2eRepp
         VG+Q==
X-Forwarded-Encrypted: i=1; AJvYcCWEnI2VpKHmNoqaAx/GECZ6iSPC3QjRncnzPdJWi0nrElTPbWsZw/18IvOlwfQwxtC4Iua6N2ryTrH3p7DDPwoWJOoV83kx4kYIPiUc9RI=
X-Gm-Message-State: AOJu0Yx1Hsf/BXQkjyuXjjgnZ2rwD7Z+CTX999Fu4Z7OhYFTgKQLhKYy
	kOsx0c3m6EK/Gg2HWB4HtPAzmYW10bPW1QYlpfWobgoduW5rtE5YCo+3E10Twg==
X-Google-Smtp-Source: AGHT+IHr6RfFoRkwPirHm2TaTZhSKY3iT4ZC4eMs4MD9pxkEA/3R2vQKyWhNqQVPzTxC7WXvUs6/Lw==
X-Received: by 2002:a50:c048:0:b0:566:aba4:7209 with SMTP id u8-20020a50c048000000b00566aba47209mr3572857edd.13.1710335486804;
        Wed, 13 Mar 2024 06:11:26 -0700 (PDT)
Message-ID: <746d063c-c5ef-4a16-a9b1-30215045573e@suse.com>
Date: Wed, 13 Mar 2024 14:11:11 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 6/9] x86/shutdown: protect against recurrent
 machine_restart()
Content-Language: en-US
To: Krystian Hebel 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org, Wei Liu 
References: 
 <87b0e650f28038c2fb64c5eb607c8fdaa7b4db07.1699982111.git.krystian.hebel@3mdeb.com>
 <665c7f47-a218-4187-858d-562bb5b9513b@suse.com>
 <173cc1f7-d906-47ed-bba3-d43da219fd7b@3mdeb.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <173cc1f7-d906-47ed-bba3-d43da219fd7b@3mdeb.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 12.03.2024 17:05, Krystian Hebel wrote:
> 
> On 8.02.2024 12:30, Jan Beulich wrote:
>> On 14.11.2023 18:50, Krystian Hebel wrote:
>>> If multiple CPUs called machine_restart() before actual restart took
>>> place, but after boot CPU declared itself not online,
>> Can you help me please in identifying where this operation is? I can see
>> two places where a CPU is removed from cpu_online_map, yet neither
>> __stop_this_cpu() nor __cpu_disable() ought to be coming into play here.
>> In fact I didn't think CPU0 was ever marked not-online. Except perhaps
>> if we came through machine_crash_shutdown() -> nmi_shootdown_cpus(), but
>> I'm sure you would have mentioned such a further dependency.
>>
> BUG_ON() in cpu_notifier_call_chain() (I've been playing with some of
> the notifiers and one of them eventually failed) resulted in panic()
> around the same time AP did in pm_idle() due to inconsistent settings
> between BSP and AP for MWAIT/MONITOR support after TXT dynamic
> launch. There is 5s delay between smp_send_stop() and actual reboot,
> during that time AP spammed the output so the original reason for
> panic() was visible only after unreasonable amount of scrolling.
> 
> Adding TXT support is the reason why I even started making AP bring-up
> parallel. Problem with MWAIT doesn't happen in current code or changes
> in this patchset, but handling of such error is related to SMP so I've 
> included it.

If you mean to address a latent problem, then you want to say so and you
want to make sure you include enough detail on the (future) conditions
under which the problem may happen. Otherwise anything you say wants to
match present code / behavior.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Mar 13 13:21:25 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 13:21:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692432.1079550 (Exim 4.92)
	(envelope-from )
	id 1rkOXi-0008Aj-Cb; Wed, 13 Mar 2024 13:21:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692432.1079550; Wed, 13 Mar 2024 13:21:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkOXi-0008Ac-91; Wed, 13 Mar 2024 13:21:14 +0000
Received: by outflank-mailman (input) for mailman id 692432;
 Wed, 13 Mar 2024 13:21:12 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkOXg-0008AW-FP
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 13:21:12 +0000
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com
 [2a00:1450:4864:20::62b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8f44786f-e13c-11ee-afdd-a90da7624cb6;
 Wed, 13 Mar 2024 14:21:11 +0100 (CET)
Received: by mail-ej1-x62b.google.com with SMTP id
 a640c23a62f3a-a450bedffdfso131149366b.3
 for ; Wed, 13 Mar 2024 06:21:11 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 qw14-20020a170906fcae00b00a46647b6496sm226510ejb.155.2024.03.13.06.21.10
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 13 Mar 2024 06:21:10 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8f44786f-e13c-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710336071; x=1710940871; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=8NOnulto4mHXTGIK1YPxftEbHfrfAN5ZyCaTfuQAlFU=;
        b=QojkelqBZBpuQ8yEPI/z3pljqp5nUyiN2FJU1+K5hiEDKFEsFPzi7VDp53ZCLYCf85
         bOdu3tyXCJir1CcXcPWSIsf2S1Vrl45yRwDR81HX8ZuwkE5tMv+udWu9JxOn2mMN/Bb7
         TIP5RPMcO/2IBy++686iA6SIq8iyKn9+tX8a11pmVkpYP0MoTVOFCLG7SXoUp6LiEFZ1
         fO/UP0HJ8fU82ZfTlMZ2Lyd8tXSqbFH3AkzFGhsA3LHSoeoQqL9m+zpGUHTVW9m5dHXF
         3DB3zuQZJuhOPS3fr1bhDMHZq5hLjtvvxe8ZGNq6EKfzn1fPWqYceMdfW5fvpL1uZYfx
         ux3g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710336071; x=1710940871;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=8NOnulto4mHXTGIK1YPxftEbHfrfAN5ZyCaTfuQAlFU=;
        b=FCSA/LSdntehRI5VuB9/B2dO8b2pAx02PWzSjxfpZ6ZkggRfHsSxGEepMlrt3MMqHx
         c/CcYOavqcg6FXxdZT8BlwwVtTwF5uEPwQAlXXUNNRJx9z9z8DxWzxozxF+Fylm4TbPi
         VUu+xIJR0f3ZC25hhI3HZgvjvdL1Y/xinqkkVIgDhZ21tGhViZLmOk/HSdVsamwj6aY/
         bfi0Z2adlbaZDg3mgc7UCOJV4E8tJ1hxctiqbNwXXdwWlXugEIoyEHcNGnVoP3Os+nAj
         eN217P9ePH4nY2Ywc1zuCme9eE6mwrA+C02JWblpRKg8/soKRD9ReQM0yNLcg6IBQnQe
         AS9w==
X-Forwarded-Encrypted: i=1; AJvYcCVQVNK2bnSYY+55OEM0gaa+9klgsprhIbLzWIGBhzCzTDvo6QqKsd2jfqPcOZopOgf52rG48Bec7337f2YrE1V4XYekQ0C9YqSrJL4Cqb8=
X-Gm-Message-State: AOJu0YwP5SBniIVS04MZ7QoEbLNvpbCyWMAY5jRY7uXKfReyxrzcHSBE
	6v/WOpCUeFQ7fI08TOC2krY01CuGLgxe+vsMyYVEsEIBiQHzJRjdqNh+jxVeNw==
X-Google-Smtp-Source: AGHT+IHRm90eFCHbE29SVeSOxCuo9s6xD3+IoZIwlc/7pNVLGrCIhDDtZHbv9Pwt4+Rk4KoFt1a57w==
X-Received: by 2002:a17:907:d311:b0:a3e:b263:d769 with SMTP id vg17-20020a170907d31100b00a3eb263d769mr2622677ejc.4.1710336070950;
        Wed, 13 Mar 2024 06:21:10 -0700 (PDT)
Message-ID: <86d27aa3-4ac7-4717-bafd-598b1201faf1@suse.com>
Date: Wed, 13 Mar 2024 14:21:09 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 8/9] x86/smp: make cpu_state per-CPU
Content-Language: en-US
To: Krystian Hebel 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu
 , xen-devel@lists.xenproject.org
References: 
 <52083114d4cbbc75f021e8c61763ad0e166cf05b.1699982111.git.krystian.hebel@3mdeb.com>
 
 <848c6735-c700-4feb-bc0c-259d00147564@3mdeb.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <848c6735-c700-4feb-bc0c-259d00147564@3mdeb.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 12.03.2024 17:38, Krystian Hebel wrote:
> On 8.02.2024 13:13, Jan Beulich wrote:
>> On 14.11.2023 18:50, Krystian Hebel wrote:
>>> @@ -320,6 +317,10 @@ void start_secondary(unsigned int cpu)
>>>   
>>>       /* Critical region without IDT or TSS.  Any fault is deadly! */
>>>   
>>> +    /* Wait until data set up by CPU_UP_PREPARE notifiers is ready. */
>>> +    while ( cpu_data[cpu].cpu_state != CPU_STATE_CALLOUT )
>>> +        cpu_relax();
>> I'm afraid I don't understand the comment (and hence whether this loop
>> is actually needed here): __cpu_up() is called only after those
>> notifiers completed.
> Yes, but broadcasted INIT-SIPI-SIPI sequence added in next patch will be
> sent before that call is made, and consequently APs potentially can get
> to this point before that data is set up.

That's fine, and I was able to conclude this once having read that following
patch. But the patch here, including its description, wants to the self-
contained.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Mar 13 13:30:44 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 13:30:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692437.1079561 (Exim 4.92)
	(envelope-from )
	id 1rkOgp-000213-8u; Wed, 13 Mar 2024 13:30:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692437.1079561; Wed, 13 Mar 2024 13:30:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkOgp-00020w-4Q; Wed, 13 Mar 2024 13:30:39 +0000
Received: by outflank-mailman (input) for mailman id 692437;
 Wed, 13 Mar 2024 13:30:37 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkOgn-00020q-AB
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 13:30:37 +0000
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com
 [2a00:1450:4864:20::52d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id df5cd675-e13d-11ee-a1ee-f123f15fe8a2;
 Wed, 13 Mar 2024 14:30:35 +0100 (CET)
Received: by mail-ed1-x52d.google.com with SMTP id
 4fb4d7f45d1cf-5687e7662a5so1666743a12.0
 for ; Wed, 13 Mar 2024 06:30:35 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 k13-20020a1709065fcd00b00a44f0d99d58sm4830378ejv.208.2024.03.13.06.30.34
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 13 Mar 2024 06:30:34 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: df5cd675-e13d-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710336635; x=1710941435; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=wBel3iki8J8meyGhrbnmktI8MvSLySCO1UlPcxjldeY=;
        b=D/kjJonaCJ+pKVlU0Z5T6n/aQI/44VsCAcv7ui37xllwWUYtoxMRbY8CQOA2Wixsv5
         yzRTz/gpy+QdDw5TScs58/zw8oaFgINc9hbwLW4GyRInBPUSI4yGdeaqF7pkx+SkJlO0
         cd+yxbsFZgtZgTBMt+f51BnypaaemNqpcPs9ztJHF/bDcNfnsPaTbV8lKBm3QJJCckqw
         P79UasWivXEc77q2l8NS2tdW5Gztycdh0CWNL1kDoS2vuc/6nR6L30eWbukKMAvykrDs
         VbZee5bdbgp05Y483GhVCBidXzP7iAODfxB9EY6cmKd2z1scJ5ZWqkaZiN0D3HMxTm0q
         LaAg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710336635; x=1710941435;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=wBel3iki8J8meyGhrbnmktI8MvSLySCO1UlPcxjldeY=;
        b=KacdQm+lr2M6XM7iJ4Ca+/1yI7RyLAk4mSx9G0a5hJL4Z9njK2cEEBSO2QtfFymN8r
         azo5QPFIv6oHd672WRQA0/EGpalKf6DF6XNnPdfjrrCH9UnrCeFlg9ZJ73yo5ZyWGriF
         BPIrGGyXMd0Jbto+XblpXOlB5HIqIS4HEsDi1n+oJR3jQoOcSxmef3+dul4Yri7gYBs5
         aw4Tc+ZOdqFbWJTvafGZ902tSYHZeEpPgoG70HP1x09K7CO05sHdFCnxEal6qJfCytC8
         Syq6VwFEsP5gmOIN9+SOjT3Rc+kJdmlmiTNFzWNygH2mkiyFuraEIEccd1ErUSlnb1Q5
         SrHg==
X-Forwarded-Encrypted: i=1; AJvYcCW3YkYdMuKyRQ/swz5NU+ALYvU3eAdzu41B3YGBC60yXPtuZ3FCJ88bQk/uQHE33PfzU8iUASq0Ypzj0mY9CglMRU3vh2ybOFi8Dm/H4gc=
X-Gm-Message-State: AOJu0YzQGAnu+a0hrF/HHgUd0Uj2Mn5l2dzTQiR6IVngP1l2QaX6Pj3q
	WzFCTKxLAVHrVX7E624K3MGQ6L1Rm2GVgfVbkv1jfiR9eDZWmKETGt36LFTEeg==
X-Google-Smtp-Source: AGHT+IEr8RFvXfC/j6y52Lr/LbUgPUggoo4OrGIog/WZgRzB4G5UbZ4C8E9/tLMMYLpLYJjPGeHiRQ==
X-Received: by 2002:a17:906:2b17:b0:a46:5f74:f0b8 with SMTP id a23-20020a1709062b1700b00a465f74f0b8mr946165ejg.26.1710336634696;
        Wed, 13 Mar 2024 06:30:34 -0700 (PDT)
Message-ID: 
Date: Wed, 13 Mar 2024 14:30:33 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 9/9] x86/smp: start APs in parallel during boot
Content-Language: en-US
To: Krystian Hebel 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org, Wei Liu 
References: 
 <77c9199eabf3a30ebcf89356b2dd35abd611a3a9.1699982111.git.krystian.hebel@3mdeb.com>
 
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 12.03.2024 18:13, Krystian Hebel wrote:
> 
> On 8.02.2024 13:37, Jan Beulich wrote:
>> On 14.11.2023 18:50, Krystian Hebel wrote:
>>> Multiple delays are required when sending IPIs and waiting for
>>> responses. During boot, 4 such IPIs were sent per each AP. With this
>>> change, only one set of broadcast IPIs is sent. This reduces boot time,
>>> especially for platforms with large number of cores.
>> Yet APs do their startup work in parallel only for a brief period of
>> time, if I'm not mistaken. Othwerwise I can't see why you'd still have
>> cpu_up() in __start_xen().
> cpu_up() is left because multiple notifiers aren't easy to convert to work
> in parallel. In terms of lines of code it looks like a brief period, but all
> the delays along the way were taking much more time than the actual
> work. As the gain was already more than what I hoped for, I decided
> against spending too much time trying to fix the notifiers' code for
> minimal profit.

Which is all fine. Just that by title of this patch and the cover letter
I expected more. Adding "partly" or some such in both places may help.

>>> --- a/xen/arch/x86/smpboot.c
>>> +++ b/xen/arch/x86/smpboot.c
>>> @@ -425,7 +425,7 @@ void start_secondary(unsigned int cpu)
>>>   
>>>   static int wakeup_secondary_cpu(int phys_apicid, unsigned long start_eip)
>>>   {
>>> -    unsigned long send_status = 0, accept_status = 0;
>>> +    unsigned long send_status = 0, accept_status = 0, sh = 0;
>> sh doesn't need to be 64 bits wide, does it?
> No, will change.
>>
>>>       int maxlvt, timeout, i;
>>>   
>>>       /*
>>> @@ -445,6 +445,12 @@ static int wakeup_secondary_cpu(int phys_apicid, unsigned long start_eip)
>>>       if ( tboot_in_measured_env() && !tboot_wake_ap(phys_apicid, start_eip) )
>>>           return 0;
>>>   
>>> +    /*
>>> +     * Use destination shorthand for broadcasting IPIs during boot.
>>> +     */
>> Nit (style): This is a single line comment.
> Ack
>>
>>> +    if ( phys_apicid == BAD_APICID )
>>> +        sh = APIC_DEST_ALLBUT;
>> I think the latest for this the function parameter wants changing to
>> unsigned int (in another prereq patch).
> What do you mean, phys_apicid in wakeup_secondary_cpu()? It is passed
> as signed int since __cpu_up(), should I change all of those to unsigned?

That would be best, yes. BAD_APICID, after all, is an unsigned constant
(no matter that its definition involves a unary minus operator).

Jan


From xen-devel-bounces@lists.xenproject.org Wed Mar 13 13:54:15 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 13:54:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692441.1079570 (Exim 4.92)
	(envelope-from )
	id 1rkP3Z-0005aV-5p; Wed, 13 Mar 2024 13:54:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692441.1079570; Wed, 13 Mar 2024 13:54:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkP3Z-0005aO-2r; Wed, 13 Mar 2024 13:54:09 +0000
Received: by outflank-mailman (input) for mailman id 692441;
 Wed, 13 Mar 2024 13:54:07 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkP3X-0005aI-Jy
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 13:54:07 +0000
Received: from mail133-16.atl131.mandrillapp.com
 (mail133-16.atl131.mandrillapp.com [198.2.133.16])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 276d3f65-e141-11ee-a1ee-f123f15fe8a2;
 Wed, 13 Mar 2024 14:54:05 +0100 (CET)
Received: from pmta13.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1])
 by mail133-16.atl131.mandrillapp.com (Mailchimp) with ESMTP id
 4TvsSC0wGdzB5p4x5
 for ; Wed, 13 Mar 2024 13:54:03 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 2dd9f1f997894d55b7f668cd4a9fc651; Wed, 13 Mar 2024 13:54:03 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 276d3f65-e141-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1710338043; x=1710598543;
	bh=psve3gBLj3dQSMIfovgUuJgDvkc6PpGa0A4J3Xz7F8M=;
	h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=WBVMp/K1V9z7Ko/Nb9vFOgJvO0VZyZU38x8kNmB+4FLL1u+xMuhnL4Ac0zngxEiG4
	 3fXfh9HTwsWuRmtguFf3OWKxT3iR4LI+vKTtcAb7monFrk0F+nkLveIBMwG4flYvtR
	 Di/QdIbQJxn2Cp4Qx7ODI4/PvYiMwurejdw6KjZlVo+v4tQ1n9uFXRWbWJC6GEmrui
	 agDGmwJ5JQiOAumpjWwq4nsJJcQLH1KENjq8sN+6x1evZKsWC3cnXB4m/iMN7Fcr6j
	 GiKf44kj0U/MAFxK7dvp4oH2gpGVsY+46Kt79FW37zD8pXpLUGrECAHx6RoCRggUvA
	 g1pw3jT1kcmBw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1710338043; x=1710598543; i=vaishali.thakkar@vates.tech;
	bh=psve3gBLj3dQSMIfovgUuJgDvkc6PpGa0A4J3Xz7F8M=;
	h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=JQTB5cdqvptB9FkX859F6OV+9SY96bhRMCQUn4me6W9ia/cujUx+vKaZQKiQ8lFdR
	 rWI0K0M5Rd9l1rNPpS2qHBiKzPsA5cTKzZUXQmOfhK5KfIyBKkwv3ByLhzkTIjXJRl
	 BmCyl1omtWgu9FXryfESrbBO9zbvGp/aSSntmh3Ji6H42tfkGkatCNBDclNuA2DHNF
	 6OPPPtaLkJuG111omyG+fPiw9GYXY8rT9FTpHattM3lwM6AF8VXW0SSTrhnXcYxpep
	 nvWFlnv6PoDjWO9GUETd4knqC8qthLWl4vQEEhartfaydGhySvpIfEAXKVfMWEQFdl
	 ItfuuvQ416guw==
From: Vaishali Thakkar 
Subject: =?utf-8?Q?Re:=20[PATCH=20v2=203/3]=20x86/svmdebug:=20Print=20sev=20and=20sev=5Fes=20vmcb=20bits?=
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1710338041482
Message-Id: <04e6cbd2-4235-4972-9f14-dd96ca3a3515@vates.tech>
To: Jan Beulich 
Cc: andrew.cooper3@citrix.com, roger.pau@citrix.com, wl@xen.org, xen-devel@lists.xenproject.org
References:  <0e688a18a97e495352e2b08cb7634abbc238da1b.1710149462.git.vaishali.thakkar@vates.tech> <708aad8c-cf06-4a1d-b2d2-d4405cc19213@suse.com>
In-Reply-To: <708aad8c-cf06-4a1d-b2d2-d4405cc19213@suse.com>
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.2dd9f1f997894d55b7f668cd4a9fc651?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20240313:md
Date: Wed, 13 Mar 2024 13:54:03 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

On 3/12/24 09:05, Jan Beulich wrote:
> On 11.03.2024 13:40, Vaishali Thakkar wrote:
>> While sev and sev_es bits are not yet enabled in xen,
>> including their status in the VMCB dump could be
>> informational.Therefore, print it via svmdebug.
> 
> Yet there are more bits there. I'm okay with leaving off printing of
> them here, but it wants clarifying why some are printed and some are
> not.

Well, the idea is to print the bits that are either enabled or has WIP
to enable them. (e.g. sev and sev_es) I didn't include other bits as
I'm not sure if there is any WIP to enable them. Particularly including
sev and sev_es is useful for us while working on the enablement of it.

Does a commit log like the following makes it clear for you?

" Currently only raw _np_ctrl is being printed. It can
   be informational to know about which particular bits
   are enabled. So, this commit adds the bit-by-bit decode
   for np, sev and sev_es bits.

   Note that while only np is enabled in certain scenarios
   at the moment, work for enabling sev and sev_es is in
   progress. And it's useful to have this information as
   part of svmdebug. "

I'm also fine with including other bits here if that's preferred.

>> --- a/xen/arch/x86/hvm/svm/svmdebug.c
>> +++ b/xen/arch/x86/hvm/svm/svmdebug.c
>> @@ -51,8 +51,11 @@ void svm_vmcb_dump(const char *from, const struct vmcb_struct *vmcb)
>>              vmcb->exitcode, vmcb->exit_int_info.raw);
>>       printk("exitinfo1 = %#"PRIx64" exitinfo2 = %#"PRIx64"\n",
>>              vmcb->exitinfo1, vmcb->exitinfo2);
>> -    printk("np_ctrl = %#"PRIx64" asid = %#x\n",
>> -           vmcb_get_np_ctrl(vmcb), vmcb_get_asid(vmcb));
>> +    printk("asid = %#x np_ctrl = %#"PRIx64" - %s%s%s\n",
>> +           vmcb_get_asid(vmcb), vmcb_get_np_ctrl(vmcb),
>> +           vmcb_get_np(vmcb)     ? "NP"     : "",
>> +           vmcb_get_sev(vmcb)    ? "SEV"    : "",
>> +           vmcb_get_sev_es(vmcb) ? "SEV_ES" : "");
> 
> Each of these three string literals needs a leading blank as separator.
> In exchange the one in the format string immediately after '-' then
> will want dropping. That'll still lead to slightly odd output if none
> of the bits is set; imo it would be slightly less odd if you used
> 
>      printk("asid = %#x np_ctrl = %#"PRIx64":%s%s%s\n",
> 
> instead.
> 
> Jan


From xen-devel-bounces@lists.xenproject.org Wed Mar 13 13:56:21 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 13:56:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692443.1079580 (Exim 4.92)
	(envelope-from )
	id 1rkP5g-00066q-GT; Wed, 13 Mar 2024 13:56:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692443.1079580; Wed, 13 Mar 2024 13:56:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkP5g-00066j-DK; Wed, 13 Mar 2024 13:56:20 +0000
Received: by outflank-mailman (input) for mailman id 692443;
 Wed, 13 Mar 2024 13:56:19 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkP5f-00066b-AZ
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 13:56:19 +0000
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com
 [2a00:1450:4864:20::529])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7672833a-e141-11ee-a1ee-f123f15fe8a2;
 Wed, 13 Mar 2024 14:56:17 +0100 (CET)
Received: by mail-ed1-x529.google.com with SMTP id
 4fb4d7f45d1cf-568107a9ff2so1212088a12.3
 for ; Wed, 13 Mar 2024 06:56:17 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ef9-20020a05640228c900b00566a461e1ecsm4971924edb.73.2024.03.13.06.56.16
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 13 Mar 2024 06:56:16 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7672833a-e141-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710338177; x=1710942977; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=EsHsFym6fkccRe/hxHv3bP5aNLujxgCmX+9+DffSdb4=;
        b=PfSC5f2pYT+C996lJpLFU6Heo8GaGATzit3M4Ev20PbVss8TQsyhRo7RP24U3Jd7fO
         m9nyA9Q4FTvBkfhPV9ciWYnoUXAFROJrQMyDOLID1ofFfXZn3py50D1sbAyvpFSV3F2r
         OEPLHqCpf+AkcFXHmT8TWAzZQSQUxV8gM9HleYX998RQAZHcSFHGsBPjtADu09+MOYH9
         mXuuhzW5ih1Vr6siet/bFyR9D0K9UiQrCmajQFvM2px0wgJtJyIibkxJB/+Cebk+YXiV
         7BbmSx7MxWAQt+Jw5Dn4YQLpiRwnInx+76WF+i+hFtvNMgtGsu449ix/UzqLF0EvXz27
         2AaQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710338177; x=1710942977;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=EsHsFym6fkccRe/hxHv3bP5aNLujxgCmX+9+DffSdb4=;
        b=N5bZkgUH8lZHrFem5clOutuTOfW21InDvX2s6WcalU6lwBCa3hAjsMQWvafoKMk5/C
         tftvtV5Go5wex+NvCnbi6o8NyRGbPAIMNlDhMNi2AFGrg/llVSlCVk0+fQcGcRnHAbSa
         oDOL5AnjTYwfF8gUi0rlkFUa5+H9ksx+LJfg5OUkJRvNUz5kILOiycKi0dlB++D40+kR
         YW3ImAXYjbb0P7MlrqleX5jUF0tK8dq5TUtFBoN1vOcXOqU2VjymI6aVT1CUBLsQ1eP9
         hb01LI87+xvHlbm8cyLApgnaCd5iCKr23IKs7p27ycHbWUpSWyqAxqTxUTknE/akUHw+
         ZQ2w==
X-Forwarded-Encrypted: i=1; AJvYcCXXW30UfHI9vQp8sDyMJ9Pl+zzpeoCPEHMvmdEKku+8FWHlIyAiEeoUqfIWUoPxG9G/q3ilu9/B03wGX/0CWfbpEBA/FGYQTZbXfULc4uE=
X-Gm-Message-State: AOJu0YypTJlwpp6nroSspJtgxez4kfjL9GFgnZ80Lb2SAOpGETcp8IBl
	MlJR1MaAMMId4uE8UBVDxwkm+7iJE0DwtxA6fcMWQr39E4rfE0aLJ6Q2no1zC/aw1Y64Eocvulc
	=
X-Google-Smtp-Source: AGHT+IFCvPH9+bvQH/5BsXvw+GeVsbVJ+omncdx+lQFMJuRZhdF+DstzC+zfbU6frmuFANkWw3j8RA==
X-Received: by 2002:a50:a457:0:b0:566:47dc:47e3 with SMTP id v23-20020a50a457000000b0056647dc47e3mr2263545edb.15.1710338176694;
        Wed, 13 Mar 2024 06:56:16 -0700 (PDT)
Message-ID: <02ff2b83-524c-497d-8042-afddaf684401@suse.com>
Date: Wed, 13 Mar 2024 14:56:15 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 3/3] x86/svmdebug: Print sev and sev_es vmcb bits
Content-Language: en-US
To: Vaishali Thakkar 
Cc: andrew.cooper3@citrix.com, roger.pau@citrix.com, wl@xen.org,
 xen-devel@lists.xenproject.org
References: 
 <0e688a18a97e495352e2b08cb7634abbc238da1b.1710149462.git.vaishali.thakkar@vates.tech>
 <708aad8c-cf06-4a1d-b2d2-d4405cc19213@suse.com>
 <04e6cbd2-4235-4972-9f14-dd96ca3a3515@vates.tech>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <04e6cbd2-4235-4972-9f14-dd96ca3a3515@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 13.03.2024 14:54, Vaishali Thakkar wrote:
> On 3/12/24 09:05, Jan Beulich wrote:
>> On 11.03.2024 13:40, Vaishali Thakkar wrote:
>>> While sev and sev_es bits are not yet enabled in xen,
>>> including their status in the VMCB dump could be
>>> informational.Therefore, print it via svmdebug.
>>
>> Yet there are more bits there. I'm okay with leaving off printing of
>> them here, but it wants clarifying why some are printed and some are
>> not.
> 
> Well, the idea is to print the bits that are either enabled or has WIP
> to enable them. (e.g. sev and sev_es) I didn't include other bits as
> I'm not sure if there is any WIP to enable them. Particularly including
> sev and sev_es is useful for us while working on the enablement of it.
> 
> Does a commit log like the following makes it clear for you?
> 
> " Currently only raw _np_ctrl is being printed. It can
>    be informational to know about which particular bits
>    are enabled. So, this commit adds the bit-by-bit decode
>    for np, sev and sev_es bits.
> 
>    Note that while only np is enabled in certain scenarios
>    at the moment, work for enabling sev and sev_es is in
>    progress. And it's useful to have this information as
>    part of svmdebug. "

I think that's sufficient, yes.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Mar 13 14:00:36 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 14:00:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692445.1079590 (Exim 4.92)
	(envelope-from )
	id 1rkP9k-00087s-0n; Wed, 13 Mar 2024 14:00:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692445.1079590; Wed, 13 Mar 2024 14:00:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkP9j-00087l-UL; Wed, 13 Mar 2024 14:00:31 +0000
Received: by outflank-mailman (input) for mailman id 692445;
 Wed, 13 Mar 2024 14:00:30 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkP9i-00087f-Dn
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 14:00:30 +0000
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com
 [2a00:1450:4864:20::52e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0c9f83a3-e142-11ee-afdd-a90da7624cb6;
 Wed, 13 Mar 2024 15:00:29 +0100 (CET)
Received: by mail-ed1-x52e.google.com with SMTP id
 4fb4d7f45d1cf-55a179f5fa1so8961870a12.0
 for ; Wed, 13 Mar 2024 07:00:29 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 hg13-20020a1709072ccd00b00a45fefe4fc5sm4816032ejc.135.2024.03.13.07.00.28
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 13 Mar 2024 07:00:28 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0c9f83a3-e142-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710338429; x=1710943229; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:subject:from:user-agent:mime-version:date
         :message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=ZqVblptFSYqrUaUw2YhIZpKb+B+OQXgBxRb0Ru7EDt0=;
        b=FVQRpjSz0Cv95fkMb8COxxiCDJWTc57M9GrpMYq4bDLCJ/Lm1/7tGDhi+kxzCD4q9e
         rEgdD/TidGUVMO6tUuScXJbfS/olsHns6AR4/C3pUljhaMbrzoKBcLmKLie3HnlM22hR
         khOhaEkK7m1z4zdikTU06Up1rKWmI/z9nrDrA+TRQvXw0lCffkeS98MdTovXlxGaC/DJ
         Bd37/+9TCb+GJ0V6jOJJbNAOqspG6PxJl+tku/8C7Rqkt+iR/hwwJd48U7vpX1F01o6a
         d8S8pJcs9IiO0N5hfRrmLH2FaoiAaoV/WobLocy0yISP+1q9ajwhU7vbu58u7jC9mz9X
         YqCw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710338429; x=1710943229;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:subject:from:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=ZqVblptFSYqrUaUw2YhIZpKb+B+OQXgBxRb0Ru7EDt0=;
        b=gvGIw9sTzroJLvk4Vqypt9MLiZcDWBhf4HmiuwlhZp/F0D/hWQ477+cGqdiSts6UI5
         LLpzMg745r6OXYlbqkuuiNMOvXVHb0zY3OCy+lD3PRHS/XK79j+VW9pOF9HPpKuLAqn2
         nOX1+xAhvXTUFknJfknZV9K94x0Ya/qbmk7cWtTzQ7c18iQjTnqtqflcUqEawwIf/WZ5
         dum1Ks1F6oy6rKIjEaU8fcHvP46EE/x0v9Tew093u9WbEYgQht777Fm3+MrDRQYLKp+9
         VR1apNoAfDPW+x1EecFgZUiVYH7l4zyioaI3HwPeXa3qkSbhnN5ZBHQ8h4XhdNkvjJQ4
         Tpww==
X-Gm-Message-State: AOJu0YxL7Q0B9mTtotNryAzAUUuk4Odd5O5BFuBUEjtyD/8eb70ZBgUu
	yll4MprtGQQku+tY1+haCnsAWBZ6jcNm+wBYWrar3k3V6eqkSeQw1BiO767gk2YXJG5mf2/QvGw
	=
X-Google-Smtp-Source: AGHT+IGfZUYgv0LBZI7ynmBibYHGydGzTJEVXyDq9KBWg4ePpew7ngHM3nni36MeEenbTSu/ZgtW6g==
X-Received: by 2002:a17:906:2b8c:b0:a46:13d5:46fe with SMTP id m12-20020a1709062b8c00b00a4613d546femr6612028ejg.11.1710338428583;
        Wed, 13 Mar 2024 07:00:28 -0700 (PDT)
Message-ID: <3daef84c-47dd-4a6b-9984-402e997598dc@suse.com>
Date: Wed, 13 Mar 2024 15:00:27 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Jan Beulich 
Subject: [PATCH v4] x86/PoD: tie together P2M update and increment of entry
 count
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper , Wei Liu ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 George Dunlap 
References: 
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

When not holding the PoD lock across the entire region covering P2M
update and stats update, the entry count - if to be incorrect at all -
should indicate too large a value in preference to a too small one, to
avoid functions bailing early when they find the count is zero. However,
instead of moving the increment ahead (and adjust back upon failure),
extend the PoD-locked region.

Fixes: 99af3cd40b6e ("x86/mm: Rework locking in the PoD layer")
Signed-off-by: Jan Beulich 
---
v4: Shrink locked region a little again, where possible.
v3: Extend locked region instead. Add Fixes: tag.
v2: Add comments.

--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -1348,12 +1348,19 @@ mark_populate_on_demand(struct domain *d
         }
     }
 
+    /*
+     * P2M update and stats increment need to collectively be under PoD lock,
+     * to prevent code elsewhere observing PoD entry count being zero despite
+     * there actually still being PoD entries (created by the p2m_set_entry()
+     * invocation below).
+     */
+    pod_lock(p2m);
+
     /* Now, actually do the two-way mapping */
     rc = p2m_set_entry(p2m, gfn, INVALID_MFN, order,
                        p2m_populate_on_demand, p2m->default_access);
     if ( rc == 0 )
     {
-        pod_lock(p2m);
         p2m->pod.entry_count += 1UL << order;
         p2m->pod.entry_count -= pod_count;
         BUG_ON(p2m->pod.entry_count < 0);
@@ -1363,6 +1370,8 @@ mark_populate_on_demand(struct domain *d
     }
     else if ( order )
     {
+        pod_unlock(p2m);
+
         /*
          * If this failed, we can't tell how much of the range was changed.
          * Best to crash the domain.
@@ -1372,6 +1381,8 @@ mark_populate_on_demand(struct domain *d
                d, gfn_l, order, rc);
         domain_crash(d);
     }
+    else
+        pod_unlock(p2m);
 
 out:
     gfn_unlock(p2m, gfn, order);


From xen-devel-bounces@lists.xenproject.org Wed Mar 13 14:11:17 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 14:11:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692450.1079600 (Exim 4.92)
	(envelope-from )
	id 1rkPK1-0001WR-Ud; Wed, 13 Mar 2024 14:11:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692450.1079600; Wed, 13 Mar 2024 14:11:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkPK1-0001WK-S2; Wed, 13 Mar 2024 14:11:09 +0000
Received: by outflank-mailman (input) for mailman id 692450;
 Wed, 13 Mar 2024 14:11:08 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkPK0-0001WA-Pp; Wed, 13 Mar 2024 14:11:08 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkPK0-0006bK-K7; Wed, 13 Mar 2024 14:11:08 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkPK0-0001l8-94; Wed, 13 Mar 2024 14:11:08 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rkPK0-0000w8-8e; Wed, 13 Mar 2024 14:11:08 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=YWM3OfH76wwP4st7K6cw3r8mpP/uOjEJQRf0NGUQOMI=; b=Ad8+KY8ym21bbvRrkRXWSpGbNG
	5ytMkqO1RNoJrZ/if0+8G91M//EwCkx+97aPuRoPdFZ8v+k3QkZImcgzdYzKdOljmJv7ziFGt8A6Z
	78MyY4LtMXL1QHOKk0DF2YaL5HSCKChm8sbdy9bmJ9qicQ5zRnQVoinEPNn+JoVQ4/uw=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [ovmf test] 185018: all pass - PUSHED
X-Osstest-Versions-This:
    ovmf=5572b43c6767f7cc46b074ae1fc288f6eccdc65d
X-Osstest-Versions-That:
    ovmf=6b3a512149ddadb1891f0f96c63eba5dc65c7c69
From: osstest service owner 
Date: Wed, 13 Mar 2024 14:11:08 +0000

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf                 5572b43c6767f7cc46b074ae1fc288f6eccdc65d
baseline version:
 ovmf                 6b3a512149ddadb1891f0f96c63eba5dc65c7c69

Last test of basis   185015  2024-03-13 03:16:08 Z    0 days
Testing same since   185018  2024-03-13 11:45:09 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Igniculus Fu 
  Jeshua Smith 

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-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   6b3a512149..5572b43c67  5572b43c6767f7cc46b074ae1fc288f6eccdc65d -> xen-tested-master


From xen-devel-bounces@lists.xenproject.org Wed Mar 13 14:27:00 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 14:27:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692457.1079626 (Exim 4.92)
	(envelope-from )
	id 1rkPZC-00040P-Ub; Wed, 13 Mar 2024 14:26:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692457.1079626; Wed, 13 Mar 2024 14:26:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkPZC-0003zw-Nd; Wed, 13 Mar 2024 14:26:50 +0000
Received: by outflank-mailman (input) for mailman id 692457;
 Wed, 13 Mar 2024 14:26:50 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkPZC-0003iO-17
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 14:26:50 +0000
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com
 [2a00:1450:4864:20::62c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b9ec5274-e145-11ee-a1ee-f123f15fe8a2;
 Wed, 13 Mar 2024 15:26:48 +0100 (CET)
Received: by mail-ej1-x62c.google.com with SMTP id
 a640c23a62f3a-a46606e82d9so80520066b.1
 for ; Wed, 13 Mar 2024 07:26:48 -0700 (PDT)
Received: from andrewcoop.citrite.net (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 b15-20020a170906194f00b00a4665f829a9sm159681eje.90.2024.03.13.07.26.45
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 13 Mar 2024 07:26:45 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b9ec5274-e145-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710340007; x=1710944807; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=FFFSR65pFy7tOFY4mdTf2IheoUS7iU2c+aO/Mn060yc=;
        b=QLMjrBYC2lzd6v4GSEUcYkCBC7N1YxN9KvrdD4ApwGJBlfHXksWFYuPxyJ3XHSn3UI
         QTfs46ll7xvaCb85uOSTVX0BihQyP3ZOxY0BYpS5RUD8VJFjiVWYmm0V8L7zrNNV1Drk
         zfVwmkPIHUlE9aV0cndoZgHFJ+y44Kq7k5nug=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710340007; x=1710944807;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=FFFSR65pFy7tOFY4mdTf2IheoUS7iU2c+aO/Mn060yc=;
        b=AuuM3Zsjpy9bvdE8SciiOvW0QgneuRDik5E9Yh4m2HJyiesYGh3Mg1Yv/ZlZEL5B7i
         3muzHdfTZwy2AAdZKXWK/UP169+No145kiPh8jrU2cfWNxPNtIzi5ATQp+a5iYu/roFS
         EWdU1jptXnRKUaiEVXvFPa/AmfDgy2ef/VhN+UOj+GX5jDKHbhrTueQCyackjhwjDTv+
         YOV09DCC/tJIxZBoxu1iM/FEsMHpbDeSFZBU4Ir6GXNOeX5nxtZyWGg2RuWhstjxz7SJ
         6M/OzwL1IktQb+ZvEkivpP0MoO2HQC2uJm6R0NO1BgU9vdVIgebXerAxy40quqN5gPek
         GMzw==
X-Gm-Message-State: AOJu0Yzu9B71IVvqzopokW51FU5JfSALUWLx0AjNBZ4nWqmWJXGjLvPM
	6BOceBCsKN5L5fK0bjLmuIwXukYEWmX29pbLMJhcMo/swv1qy5LrN/0NuR3Vqbrwf8yQWdY9J9h
	E
X-Google-Smtp-Source: AGHT+IFQgd3CUalZN182faAGInMvRYTR0xKahx3W96taLmSn6lWmik67/EpgCGI52YhhCJ1IjpFOjg==
X-Received: by 2002:a17:906:6a22:b0:a46:2a79:6425 with SMTP id qw34-20020a1709066a2200b00a462a796425mr7357023ejc.22.1710340007107;
        Wed, 13 Mar 2024 07:26:47 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Wei Liu 
Subject: [PATCH 2/2] x86/entry: Delete RESTORE_ALL
Date: Wed, 13 Mar 2024 14:26:41 +0000
Message-Id: <20240313142641.2150302-3-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20240313142641.2150302-1-andrew.cooper3@citrix.com>
References: <20240313142641.2150302-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

There is only a single user now, and it's the one odd case.  Inline and
simplify it to just the compat case.

No functional change.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
CC: Wei Liu 

In principle we want to delay the %rsp adjustment until after VERW, but that
turns disp8's into disp32's, making the overall code size larger.  This path
is only for 32bit PV guests anyway, which are well on their way to fully
obsolete.
---
 xen/arch/x86/include/asm/asm_defns.h | 48 ----------------------------
 xen/arch/x86/x86_64/compat/entry.S   | 18 ++++++++++-
 2 files changed, 17 insertions(+), 49 deletions(-)

diff --git a/xen/arch/x86/include/asm/asm_defns.h b/xen/arch/x86/include/asm/asm_defns.h
index ec10a8e1dfc6..524ed05d87f6 100644
--- a/xen/arch/x86/include/asm/asm_defns.h
+++ b/xen/arch/x86/include/asm/asm_defns.h
@@ -266,54 +266,6 @@ static always_inline void stac(void)
         xor   %r15d, %r15d
 .endm
 
-#define LOAD_ONE_REG(reg, compat) \
-.if !(compat); \
-        movq  UREGS_r##reg(%rsp),%r##reg; \
-.else; \
-        movl  UREGS_r##reg(%rsp),%e##reg; \
-.endif
-
-/*
- * Restore all previously saved registers.
- *
- * @adj: extra stack pointer adjustment to be folded into the adjustment done
- *       anyway at the end of the macro
- * @compat: R8-R15 don't need reloading, but they are clobbered for added
- *          safety against information leaks.
- */
-.macro RESTORE_ALL adj=0, compat=0
-.if !\compat
-        movq  UREGS_r15(%rsp), %r15
-        movq  UREGS_r14(%rsp), %r14
-        movq  UREGS_r13(%rsp), %r13
-        movq  UREGS_r12(%rsp), %r12
-.else
-        xor %r15d, %r15d
-        xor %r14d, %r14d
-        xor %r13d, %r13d
-        xor %r12d, %r12d
-.endif
-        LOAD_ONE_REG(bp, \compat)
-        LOAD_ONE_REG(bx, \compat)
-.if !\compat
-        movq  UREGS_r11(%rsp),%r11
-        movq  UREGS_r10(%rsp),%r10
-        movq  UREGS_r9(%rsp),%r9
-        movq  UREGS_r8(%rsp),%r8
-.else
-        xor %r11d, %r11d
-        xor %r10d, %r10d
-        xor %r9d, %r9d
-        xor %r8d, %r8d
-.endif
-        LOAD_ONE_REG(ax, \compat)
-        LOAD_ONE_REG(cx, \compat)
-        LOAD_ONE_REG(dx, \compat)
-        LOAD_ONE_REG(si, \compat)
-        LOAD_ONE_REG(di, \compat)
-        subq  $-(UREGS_error_code-UREGS_r15+\adj), %rsp
-.endm
-
 /*
  * POP GPRs from a UREGS_* frame on the stack.  Does not modify flags.
  *
diff --git a/xen/arch/x86/x86_64/compat/entry.S b/xen/arch/x86/x86_64/compat/entry.S
index 631f4f272ac3..99d6dec296c6 100644
--- a/xen/arch/x86/x86_64/compat/entry.S
+++ b/xen/arch/x86/x86_64/compat/entry.S
@@ -158,7 +158,23 @@ FUNC(compat_restore_all_guest)
         /* WARNING! `ret`, `call *`, `jmp *` not safe beyond this point. */
         SPEC_CTRL_EXIT_TO_PV    /* Req: a=spec_ctrl %rsp=regs/cpuinfo, Clob: cd */
 
-        RESTORE_ALL adj=8, compat=1
+        /* Opencoded POP_GPRS, restoring only the 32bit registers. */
+        xor   %r15d, %r15d
+        xor   %r14d, %r14d
+        xor   %r13d, %r13d
+        xor   %r12d, %r12d
+        mov   UREGS_rbp(%rsp), %ebp
+        mov   UREGS_rbx(%rsp), %ebx
+        xor   %r11d, %r11d
+        xor   %r10d, %r10d
+        xor   %r9d,  %r9d
+        xor   %r8d,  %r8d
+        mov   UREGS_rax(%rsp), %eax
+        mov   UREGS_rcx(%rsp), %ecx
+        mov   UREGS_rdx(%rsp), %edx
+        mov   UREGS_rsi(%rsp), %esi
+        mov   UREGS_rdi(%rsp), %edi
+        sub   $-(UREGS_rip-UREGS_r15), %rsp
 
         /* Account for ev/ec having already been popped off the stack. */
         SPEC_CTRL_COND_VERW \
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Wed Mar 13 14:27:00 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 14:27:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692456.1079619 (Exim 4.92)
	(envelope-from )
	id 1rkPZC-0003xB-JP; Wed, 13 Mar 2024 14:26:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692456.1079619; Wed, 13 Mar 2024 14:26:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkPZC-0003x4-Ga; Wed, 13 Mar 2024 14:26:50 +0000
Received: by outflank-mailman (input) for mailman id 692456;
 Wed, 13 Mar 2024 14:26:48 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkPZA-0003iP-GP
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 14:26:48 +0000
Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com
 [2a00:1450:4864:20::133])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b8fa6dd5-e145-11ee-afdd-a90da7624cb6;
 Wed, 13 Mar 2024 15:26:47 +0100 (CET)
Received: by mail-lf1-x133.google.com with SMTP id
 2adb3069b0e04-512bde3d197so5790762e87.0
 for ; Wed, 13 Mar 2024 07:26:46 -0700 (PDT)
Received: from andrewcoop.citrite.net (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 b15-20020a170906194f00b00a4665f829a9sm159681eje.90.2024.03.13.07.26.44
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 13 Mar 2024 07:26:44 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b8fa6dd5-e145-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710340005; x=1710944805; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=nXVQ+Dqyc78LR6Ra+wwAzbMl89ontQsPF8SkdAS3z1w=;
        b=t51o/givEajLPkvwof0HL6ErCeyMP9BmTW7/P6FgX47PLkos1Hs+M0sVihzoVmpD13
         GtPvwkEDyRrUhUj1j+PQc/3x/PoBGl6kJHAMaDEp9MZZhubQR4HdT1HJv5tXObsAYSde
         hUjBRbW9nUzWMsmkUBoxK36Vkwp3AkdslwkHw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710340005; x=1710944805;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=nXVQ+Dqyc78LR6Ra+wwAzbMl89ontQsPF8SkdAS3z1w=;
        b=B00/vCdmMqpMjh+X9SL7wU+Edo4WMMMvIQf5GvhG2Nfw1aIM0YvFUAUgDcDTO+8U6s
         N7bmSXqKQX9KBK4zy3mQze2CaDDbqjDbQjqipERIDzI9AQmjV3WjmCl20b2EeBod/X+R
         PIbY1k96/ANXRHEY3ZcGX05coEtASrDb7p3v86RcyfFP00QdY/JvydKdn7uH1SV6FW4l
         MGddQYvPgzP/kO7ueFWvfUHI9vBvn0fhrHbpaKiF/5zjUnLuLlmESKIJ58nQuIGJiYPz
         55zzpFWGlar8ung4RoWiIZug60M5GSy3uVtWPyiufTFNdPXc7CmpT6OEYFSupQmo8ztA
         l37A==
X-Gm-Message-State: AOJu0YzIGqyfJV5ugqFIFDYolAsvsue1N02QS9e5zK7LIqnt59LNNC+N
	ighOTv1mrPJOuo3vsGP0F8aheSO8jhbN/DMBliOBA9CboMC2TcgOGywPLM2doAQpPckxJHdLkDS
	i
X-Google-Smtp-Source: AGHT+IFEPQpjfCqBquDUOKQ25b+Y0k4nn9j6cItZnIX349LqilO1ebgxQxDtOd7IeiVurWP0nATcNA==
X-Received: by 2002:a19:7715:0:b0:513:a2b1:6291 with SMTP id s21-20020a197715000000b00513a2b16291mr6760022lfc.7.1710340005393;
        Wed, 13 Mar 2024 07:26:45 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Wei Liu 
Subject: [PATCH 1/2] x86/entry: Introduce POP_GPRS
Date: Wed, 13 Mar 2024 14:26:40 +0000
Message-Id: <20240313142641.2150302-2-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20240313142641.2150302-1-andrew.cooper3@citrix.com>
References: <20240313142641.2150302-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The macro named RESTORE_ALL has several problems.  It adjusts the stack
pointer despite this not being clear to the caller.  It also goes against
recommendations in the optimisation guides because of trying to do too many
things at once.  (i.e. there's a reason why compilers don't emit code looking
like this.)

Introduce a new POP_GPRS macro which only POPs GPRs.  Use it for the HVM paths
which are already using POPs.

Also use it for restore_all_{xen,guest}().  This saves most of a cacheline
worth of code from two fastpaths:

  add/remove: 0/0 grow/shrink: 0/2 up/down: 0/-99 (-99)
  Function                                     old     new   delta
  restore_all_guest                            378     330     -48
  restore_all_xen                              165     114     -51

but it also avoids having an explicit modification to the stack pointer
between %rsp-relative accesses, which avoids stalls in the stack-engine
optimisations in some microarchitectures.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
CC: Wei Liu 
---
 xen/arch/x86/hvm/svm/entry.S         | 17 ++---------------
 xen/arch/x86/hvm/vmx/entry.S         | 16 +---------------
 xen/arch/x86/include/asm/asm_defns.h | 23 +++++++++++++++++++++++
 xen/arch/x86/x86_64/asm-offsets.c    |  1 +
 xen/arch/x86/x86_64/entry.S          | 12 ++++++------
 5 files changed, 33 insertions(+), 36 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/entry.S b/xen/arch/x86/hvm/svm/entry.S
index 60b0b00ed0af..305f9466096a 100644
--- a/xen/arch/x86/hvm/svm/entry.S
+++ b/xen/arch/x86/hvm/svm/entry.S
@@ -74,22 +74,9 @@ __UNLIKELY_END(nsvm_hap)
         ALTERNATIVE "", svm_vmentry_spec_ctrl, X86_FEATURE_SC_MSR_HVM
         ALTERNATIVE "", DO_SPEC_CTRL_DIV, X86_FEATURE_SC_DIV
 
-        pop  %r15
-        pop  %r14
-        pop  %r13
-        pop  %r12
-        pop  %rbp
         mov  VCPU_svm_vmcb_pa(%rbx),%rax
-        pop  %rbx
-        pop  %r11
-        pop  %r10
-        pop  %r9
-        pop  %r8
-        pop  %rcx /* Skip %rax: restored by VMRUN. */
-        pop  %rcx
-        pop  %rdx
-        pop  %rsi
-        pop  %rdi
+
+        POP_GPRS rax=%rcx /* Skip %rax.  It's restored by VMRUN. */
 
         sti
         vmrun
diff --git a/xen/arch/x86/hvm/vmx/entry.S b/xen/arch/x86/hvm/vmx/entry.S
index 1bead826caa3..92d8b919198c 100644
--- a/xen/arch/x86/hvm/vmx/entry.S
+++ b/xen/arch/x86/hvm/vmx/entry.S
@@ -115,21 +115,7 @@ UNLIKELY_END(realmode)
         and  $SCF_verw, %eax
         or   %eax, %ecx
 
-        pop  %r15
-        pop  %r14
-        pop  %r13
-        pop  %r12
-        pop  %rbp
-        pop  %rbx
-        pop  %r11
-        pop  %r10
-        pop  %r9
-        pop  %r8
-        pop  %rax
-        pop  %rcx
-        pop  %rdx
-        pop  %rsi
-        pop  %rdi
+        POP_GPRS
 
         jpe  .L_skip_verw
         /* VERW clobbers ZF, but preserves all others, including SF. */
diff --git a/xen/arch/x86/include/asm/asm_defns.h b/xen/arch/x86/include/asm/asm_defns.h
index a69fae78b123..ec10a8e1dfc6 100644
--- a/xen/arch/x86/include/asm/asm_defns.h
+++ b/xen/arch/x86/include/asm/asm_defns.h
@@ -314,6 +314,29 @@ static always_inline void stac(void)
         subq  $-(UREGS_error_code-UREGS_r15+\adj), %rsp
 .endm
 
+/*
+ * POP GPRs from a UREGS_* frame on the stack.  Does not modify flags.
+ *
+ * @rax: Alternative destination for the %rax value on the stack.
+ */
+.macro POP_GPRS rax=%rax
+        pop   %r15
+        pop   %r14
+        pop   %r13
+        pop   %r12
+        pop   %rbp
+        pop   %rbx
+        pop   %r11
+        pop   %r10
+        pop   %r9
+        pop   %r8
+        pop   \rax
+        pop   %rcx
+        pop   %rdx
+        pop   %rsi
+        pop   %rdi
+.endm
+
 #ifdef CONFIG_PV32
 #define CR4_PV32_RESTORE                               \
     ALTERNATIVE_2 "",                                  \
diff --git a/xen/arch/x86/x86_64/asm-offsets.c b/xen/arch/x86/x86_64/asm-offsets.c
index d8903a3ce9c7..944f49a82171 100644
--- a/xen/arch/x86/x86_64/asm-offsets.c
+++ b/xen/arch/x86/x86_64/asm-offsets.c
@@ -59,6 +59,7 @@ void __dummy__(void)
     DEFINE(sym, offsetof(struct cpu_user_regs, mem) -                   \
                 offsetof(struct cpu_user_regs, error_code) __VA_ARGS__)
 
+    OFFSET_EF(EFRAME_error_code,      error_code);
     OFFSET_EF(EFRAME_entry_vector,    entry_vector);
     OFFSET_EF(EFRAME_rip,             rip);
     OFFSET_EF(EFRAME_cs,              cs);
diff --git a/xen/arch/x86/x86_64/entry.S b/xen/arch/x86/x86_64/entry.S
index 7d686b762807..9280216a5436 100644
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -186,7 +186,8 @@ FUNC_LOCAL(restore_all_guest)
         /* WARNING! `ret`, `call *`, `jmp *` not safe beyond this point. */
         SPEC_CTRL_EXIT_TO_PV    /* Req: a=spec_ctrl %rsp=regs/cpuinfo, Clob: cd */
 
-        RESTORE_ALL
+        POP_GPRS
+
         BUILD_BUG_ON(TRAP_syscall & 0xff)
         testb $TRAP_syscall >> 8, EFRAME_entry_vector + 1(%rsp)
         jz    iret_exit_to_guest
@@ -696,20 +697,19 @@ UNLIKELY_END(exit_cr3)
         /* WARNING! `ret`, `call *`, `jmp *` not safe beyond this point. */
         SPEC_CTRL_EXIT_TO_XEN /* Req: %r12=ist_exit %r14=end %rsp=regs, Clob: abcd */
 
-        RESTORE_ALL adj=8
+        POP_GPRS
 
         /*
          * When the CPU pushed this exception frame, it zero-extended eflags.
          * For an IST exit, SPEC_CTRL_EXIT_TO_XEN stashed shadow copies of
          * spec_ctrl_flags and ver_sel above eflags, as we can't use any GPRs,
          * and we're at a random place on the stack, not in a CPUFINFO block.
-         *
-         * Account for ev/ec having already been popped off the stack.
          */
         SPEC_CTRL_COND_VERW \
-            scf=STK_REL(EFRAME_shadow_scf, EFRAME_rip), \
-            sel=STK_REL(EFRAME_shadow_sel, EFRAME_rip)
+            scf=STK_REL(EFRAME_shadow_scf, EFRAME_error_code), \
+            sel=STK_REL(EFRAME_shadow_sel, EFRAME_error_code)
 
+        add   $8, %rsp
         iretq
 END(restore_all_xen)
 
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Wed Mar 13 14:27:00 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 14:27:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692455.1079610 (Exim 4.92)
	(envelope-from )
	id 1rkPZB-0003ih-AC; Wed, 13 Mar 2024 14:26:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692455.1079610; Wed, 13 Mar 2024 14:26:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkPZB-0003ia-6A; Wed, 13 Mar 2024 14:26:49 +0000
Received: by outflank-mailman (input) for mailman id 692455;
 Wed, 13 Mar 2024 14:26:48 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkPZ9-0003iO-UX
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 14:26:47 +0000
Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com
 [2a00:1450:4864:20::129])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b8799735-e145-11ee-a1ee-f123f15fe8a2;
 Wed, 13 Mar 2024 15:26:46 +0100 (CET)
Received: by mail-lf1-x129.google.com with SMTP id
 2adb3069b0e04-513cc23b93aso366208e87.2
 for ; Wed, 13 Mar 2024 07:26:46 -0700 (PDT)
Received: from andrewcoop.citrite.net (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 b15-20020a170906194f00b00a4665f829a9sm159681eje.90.2024.03.13.07.26.43
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 13 Mar 2024 07:26:43 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b8799735-e145-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710340004; x=1710944804; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:from:to:cc:subject:date:message-id:reply-to;
        bh=193rvYSSKodpIAC6i1jd+HzBZDvqj718olv+uomGpNY=;
        b=AvhenZEfHE+Oi1S1ELdscmapf68znRt/ii3fuc+2MsUFvtpX26uU17/VgyBwaXeoOT
         BtxhfzkNMmiDFI1j71QZ06Ndwk1qTHgmAFp16KwZTfBpKReT/NLxzglzvjSPrq4dFYmJ
         Y1rif4rYFqr6xI1mV9PFIMcVSJjUmEEit6VJM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710340004; x=1710944804;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=193rvYSSKodpIAC6i1jd+HzBZDvqj718olv+uomGpNY=;
        b=SOjn7GfhD+SbjIJ7INxANqAid5FMGpb/+e49yX38f/hDSfaYFuqFcnWOOBB49y1Aoo
         FR1+GX6eQDPxAD2fke1s5KFd6LDewRmkVaxIzTc5twp/KDISwTdCP/4BHomoByH4aqci
         8cQ7VMwpru5pSNXFwyzLGUoB0ikGUlgQMw5tCebqAOmBOL7wjG4JW8gbM4CneEk2bOJJ
         zhkMveDdj/of1eDbd8msazASHHaBqOu7HO7/p/58E3duuoX6eVLvQbzfXISmsEyB42Am
         vNkNhIcGHZyI6JC1Bow2Ti94ysY7ogza3mGMS+PiQMsx8B1g3or4Eok/EL9NuKe6tC5s
         oluQ==
X-Gm-Message-State: AOJu0Yz83gfNZgAXVLyg3ThN0jHPwpwNIRqONKDqUdQb9JTRM0EychNY
	pvebrJXJCVMaIHLLj28GTX98LarHYCHy+VaexbDScz2hhC535SEoCe28j89aTvGIqYcw4l6CDEW
	a
X-Google-Smtp-Source: AGHT+IGg7vsWaY8WgkBUj8WlmBqx1lG/SxD7L2crqPeaJKlne//xXf2sXIYZigHYCkHgPzqLBPB6Rg==
X-Received: by 2002:ac2:57c6:0:b0:513:a39e:ae45 with SMTP id k6-20020ac257c6000000b00513a39eae45mr2363688lfo.62.1710340004500;
        Wed, 13 Mar 2024 07:26:44 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Wei Liu 
Subject: [PATCH 0/2] x86/entry: Post-XSA-453 cleanup, part 1
Date: Wed, 13 Mar 2024 14:26:39 +0000
Message-Id: <20240313142641.2150302-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.30.2
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The start of making Xen's entry code conform better to the recommendations in
the vendor Optimisation Guides.

Part 1 (this series) swaps RESTORE_ALL for POP_GPRs.  Part 2 is the SAVE_ALL
side of things which is more complicated because of flags handling.

Andrew Cooper (2):
  x86/entry: Introduce POP_GPRS
  x86/entry: Delete RESTORE_ALL

 xen/arch/x86/hvm/svm/entry.S         | 17 +-------
 xen/arch/x86/hvm/vmx/entry.S         | 16 +-------
 xen/arch/x86/include/asm/asm_defns.h | 61 ++++++++--------------------
 xen/arch/x86/x86_64/asm-offsets.c    |  1 +
 xen/arch/x86/x86_64/compat/entry.S   | 18 +++++++-
 xen/arch/x86/x86_64/entry.S          | 12 +++---
 6 files changed, 45 insertions(+), 80 deletions(-)


base-commit: 03cf7ca23e0e876075954c558485b267b7d02406
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Wed Mar 13 14:59:34 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 14:59:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692470.1079640 (Exim 4.92)
	(envelope-from )
	id 1rkQ4m-0001QG-6w; Wed, 13 Mar 2024 14:59:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692470.1079640; Wed, 13 Mar 2024 14:59:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkQ4m-0001Q9-47; Wed, 13 Mar 2024 14:59:28 +0000
Received: by outflank-mailman (input) for mailman id 692470;
 Wed, 13 Mar 2024 14:59:27 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkQ4l-0001Oo-Aq
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 14:59:27 +0000
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com
 [2a00:1450:4864:20::534])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 48ce857b-e14a-11ee-afdd-a90da7624cb6;
 Wed, 13 Mar 2024 15:59:26 +0100 (CET)
Received: by mail-ed1-x534.google.com with SMTP id
 4fb4d7f45d1cf-5683089d4bbso7271764a12.2
 for ; Wed, 13 Mar 2024 07:59:26 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 48ce857b-e14a-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1710341965; x=1710946765; darn=lists.xenproject.org;
        h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject
         :date:message-id:reply-to;
        bh=hCinrcfC+9irVXRne3N2PTAFGdJZMBrm1hz95sPNsWY=;
        b=W5ub9HYSo5V1MgW+Gq0c55BiOqEFLnXg0ob+r/tJ8N/+qfohELtBhPH60HVnHLwzXI
         +IuPVl58/tTXpQew/dWLNaVV3jjOj93wgpYZjVw5LNwtAwzUhtA6p9C0/hdKkmuP6CR+
         QMaxxLs7JQfs0dF+mIeYM5tNQB5wghhCxuG/I=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710341965; x=1710946765;
        h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=hCinrcfC+9irVXRne3N2PTAFGdJZMBrm1hz95sPNsWY=;
        b=PypJUG2U6RzXN5ieXAB04YNASkZPjmnz14PVxanKvc2fCR3/llcVv88BPmT46ovkbZ
         lSMWf4x+RX0PkrM1YsUY8CKDyfUPf5zm6lvIW4LVJmJkH4/jYgiZpslhEg45CstXa6fK
         u37PFLm9INsD6/hhy7HwveDrjA2JeoUIOuvtObVZEEgdjrWBQ0EM1KwOYC9tKtU/o5do
         IfUFEsmVbC3/tVsVRKt4ZFbUhg4ljx+s2xlQivOyPiv20aOE+VNScxoPIJ0qNJWFW5ks
         0gXqbnE2oMeyCLujiwY+sBzHBb/Kz3gCNyxgtL9YXrObBKMfT7jDfTwQDW0wuDPM6nNJ
         yOaw==
X-Gm-Message-State: AOJu0YySCL+gkN0CjfCAJaHsA8MFybQ/x9qcd4VKBKfASqMVrUywhacH
	4PvWhw9Xx/16Rw9b0z7tasMoTU2yW805I7zF39yOIbKiG5rrQ54X7Zdj6rD2lsy8tYTveLKquad
	Ce5L4K+VjM1dmjFNw2gMz9wOj2K1v2riB03PaUfHWYhiiDONjBXY=
X-Google-Smtp-Source: AGHT+IHXpaLhuRlbbe0xRr3WNGSKgzdHHBq7QsmFWYXfAarQgLZuOI9iJptwCB2G6Xfl4uPiBhgHb/XBn5aSv+9Mtzk=
X-Received: by 2002:a50:8d55:0:b0:568:3362:ccdb with SMTP id
 t21-20020a508d55000000b005683362ccdbmr8734973edt.10.1710341965326; Wed, 13
 Mar 2024 07:59:25 -0700 (PDT)
MIME-Version: 1.0
From: Kelly Choi 
Date: Wed, 13 Mar 2024 14:58:49 +0000
Message-ID: 
Subject: Mailing list changes
To: xen-devel , xen-users@lists.xenproject.org
Cc: advisory-board@lists.xenproject.org, committers@xenproject.org
Content-Type: multipart/alternative; boundary="00000000000049cf6406138c05af"

--00000000000049cf6406138c05af
Content-Type: text/plain; charset="UTF-8"

Hi everyone,

We recently discussed some mailing list changes in our last community call.

*Issue:*

   - Lists.xenproject.org software is outdated, DKIM, DMARC, ARC is no
   longer sufficient, and there's no clear update path from Mailman2 to
   Mailman3.

*Potential solution:*

   - Host them at https://subspace.kernel.org/ due to us being part of the
   Linux Foundation
   - No additional cost to the project

There was no objection to this during the call. For everyone else who was
not present, please feel free to give your feedback here on the
mailing list (should you have any).

Many thanks,
Kelly Choi

Community Manager
Xen Project

--00000000000049cf6406138c05af
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi everyone,

We recently discussed some=
 mailing list changes in our last community call.=C2=A0

Issue:
  • Lists.xenproject.org software is outdated, DKIM, DMARC, ARC is no lo=
nger sufficient, and there's no clear update path from Mailman2 to Mail=
man3.=C2=A0
Potential solution:
There was no objection to this durin=
g the call. For everyone else who was not present, please feel free to give=
 your feedback here on the mailing=C2=A0list (should you have any).

Many thanks,
=

Kelly Choi

Community Manager
Xen Projec=
t=C2=A0


--00000000000049cf6406138c05af--


From xen-devel-bounces@lists.xenproject.org Wed Mar 13 15:03:36 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 15:03:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692491.1079668 (Exim 4.92)
	(envelope-from )
	id 1rkQ8l-0003tT-1B; Wed, 13 Mar 2024 15:03:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692491.1079668; Wed, 13 Mar 2024 15:03:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkQ8k-0003tM-Ut; Wed, 13 Mar 2024 15:03:34 +0000
Received: by outflank-mailman (input) for mailman id 692491;
 Wed, 13 Mar 2024 15:03:33 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkQ8j-0003t5-Cn
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 15:03:33 +0000
Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com
 [2607:f8b0:4864:20::830])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id dafe30e7-e14a-11ee-afdd-a90da7624cb6;
 Wed, 13 Mar 2024 16:03:32 +0100 (CET)
Received: by mail-qt1-x830.google.com with SMTP id
 d75a77b69052e-43091ff5ff2so3355791cf.0
 for ; Wed, 13 Mar 2024 08:03:32 -0700 (PDT)
Received: from rossla-lxenia.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 s9-20020ac85ec9000000b0042ef4b5f4fbsm4930034qtx.38.2024.03.13.08.03.28
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 13 Mar 2024 08:03:29 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: dafe30e7-e14a-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710342210; x=1710947010; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:from:to:cc:subject:date:message-id:reply-to;
        bh=gyMo0vp7Ia8GOxu6JetmxFN6a0wgE8s9nbiG4XTX1oM=;
        b=QpPs91DCuKaur+GetAaSBLaQ5cv6kQ0whGB/DSs4KzhMo741mdfDaBZcxMQJxu5eru
         pnndm1oyaOjPoog9umTVgTp1+NZA3bcQsFzfjY1/nVfhiJ9KQqqi+sbDikwpUpbemNNY
         3hF5aqKOPONKNc6h8KpjHvjdKBOsRTbRkpOZA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710342210; x=1710947010;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=gyMo0vp7Ia8GOxu6JetmxFN6a0wgE8s9nbiG4XTX1oM=;
        b=ECbOd5ZmUx3ga7xOnZNgRrySFbn8Pxv4Cm/6PKhFE0kI0Ak4FwZ6fURhwG8w4/8vF5
         8sGAeVFTkK+Va2jPw4ZzMDaEzlaP16GOP6lJv+O1Qz/E5/lnbNEW8cbsmt/ro4KNZ1Br
         d4dCW1WwBBuAvg6zVahE/SHvsJxr+yjr+PtBubMPDoox6czetPkqES6+4C5sZg4cqBKH
         7YD6FS6pz3DGeg0bgLkGLSsbwGMN7fzZ1Z43d13sWlWWDLFOiZlGIu+u5Eh1o+BJO8Aw
         DYNdT1cSooxDwg5Bk5UYyL3CbgCAc9EhiG0U0zbBLs+e3AOQyxPr5Pbx1ZSdjmMPHi06
         HdfQ==
X-Gm-Message-State: AOJu0YyxzuBt/cgoRqA+Ee/2rMm4/9riSoC1kxNjYFrLcDm9Vy6Co3WL
	QkOziv8E87kqmgFDrqi3tlRdGurzIFCoAlSfrEchnQ9+g/8uLKRSQk8MjjLAJg3XB2+3fJGUIyT
	wxEq+
X-Google-Smtp-Source: AGHT+IGq88QEvIT5QVAmqYyi6OtMdPviJhS9zNFLE+BDu9sGsWgW321ehOXkJ7ssIk/mwNN0AE9CYA==
X-Received: by 2002:ac8:7d55:0:b0:42e:7a9a:f13b with SMTP id h21-20020ac87d55000000b0042e7a9af13bmr17157139qtb.58.1710342210257;
        Wed, 13 Mar 2024 08:03:30 -0700 (PDT)
From: Ross Lagerwall 
To: xen-devel@lists.xenproject.org
Cc: Ross Lagerwall ,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Wei Liu ,
	George Dunlap ,
	Julien Grall ,
	Stefano Stabellini 
Subject: [PATCH 0/4] x86: Multiboot PE support
Date: Wed, 13 Mar 2024 15:04:35 +0000
Message-ID: <20240313150439.791213-1-ross.lagerwall@citrix.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Hi,

This patches series implements support for xen.gz being a gzipped
multiboot-capable PE binary rather than an ELF binary. The purpose of
this is to allow the same xen.gz to be booted using BIOS, UEFI, and UEFI
with Secure Boot verification just like it can be done with a Linux
kernel. It also means that it is possible to enable Secure Boot while
still retaining the flexibility of a full bootloader like GRUB2 - not
currently possible when using xen.efi.

This requires some (backwards-compatible) extensions to the multiboot2
protocol which will be sent in a separate series along with the GRUB
changes which implement the extensions.

Ross

Ross Lagerwall (4):
  multiboot2: Advertise the load type
  x86: Add support for building a multiboot2 PE binary
  x86: Hand-edit coff flags to remove RELOCS_STRIPPED flag
  x86: Call Shim Verify in the multiboot2 path

 .gitignore                        |  1 +
 xen/Makefile                      |  1 +
 xen/arch/x86/Kconfig              |  6 +++
 xen/arch/x86/Makefile             | 50 +++++++++++++++++++
 xen/arch/x86/boot/head.S          | 40 ++++++++++++++-
 xen/arch/x86/efi/efi-boot.h       | 65 +++++++++++++++++++++++-
 xen/arch/x86/efi/set-coff-flags.c | 83 +++++++++++++++++++++++++++++++
 xen/include/xen/multiboot2.h      |  6 +++
 8 files changed, 250 insertions(+), 2 deletions(-)
 create mode 100644 xen/arch/x86/efi/set-coff-flags.c

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Wed Mar 13 15:03:36 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 15:03:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692492.1079679 (Exim 4.92)
	(envelope-from )
	id 1rkQ8m-00047o-8d; Wed, 13 Mar 2024 15:03:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692492.1079679; Wed, 13 Mar 2024 15:03:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkQ8m-00047h-5X; Wed, 13 Mar 2024 15:03:36 +0000
Received: by outflank-mailman (input) for mailman id 692492;
 Wed, 13 Mar 2024 15:03:34 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkQ8k-0003t5-G2
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 15:03:34 +0000
Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com
 [2607:f8b0:4864:20::833])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id dc24ee1f-e14a-11ee-afdd-a90da7624cb6;
 Wed, 13 Mar 2024 16:03:33 +0100 (CET)
Received: by mail-qt1-x833.google.com with SMTP id
 d75a77b69052e-42ee2012bf0so7411361cf.0
 for ; Wed, 13 Mar 2024 08:03:33 -0700 (PDT)
Received: from rossla-lxenia.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 s9-20020ac85ec9000000b0042ef4b5f4fbsm4930034qtx.38.2024.03.13.08.03.30
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 13 Mar 2024 08:03:31 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: dc24ee1f-e14a-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710342212; x=1710947012; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=KJKga3Jbhc7qlCdB+WV/kg/qjOpqTD+5g9NcykZuAm8=;
        b=FVVDsBzVFxMhkmBUDu2MqXEqQhJo1KdtIJQzhh7ZlzG5B/Rk1zIXD6wPB2J4S3UheI
         vW61+Xo4vO9v8NhFxa22hqxhq/AXalQtklF8UaAAorsIqqORtg4T1gUvS/5X+6bvgD97
         kKUprfpor0tegUcCdaBGjAK0ZSeDz4LIdYgO4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710342212; x=1710947012;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=KJKga3Jbhc7qlCdB+WV/kg/qjOpqTD+5g9NcykZuAm8=;
        b=t8xOoMMEnsueTjHqFs1Jmi6dry5ivoX3EvLxNOdxN0PlQCfeNTPWi+p2z0ED1+EMSr
         8KE628NCF1gqhpNvY/yN/mzlaqK4/9dQU5ZvtdqDk6G14pSFcJl2FDP0EPH28+zWONfp
         z6iqInpLNo7eSofWgZ7/7OkfD8QcnOTWlGELuqPZKQVohMpx+zt7Dnp5qpnLyZiHkmEm
         3wklIHwnDNocvnLmqlSrQHOUaWWtqgdiBIp184enV5CDihTXtRxa2jqrO3MIUam0I+Kb
         oXvN8O8PDMVHR9hqOV3gmiiXJZf8lWjMpqxyMQv1fnfwdAYzKnMBlMRbtpxKhnl18LZ3
         bh5g==
X-Gm-Message-State: AOJu0YygZAf5R5OTwl37mr3ivQfhsnsRgQOBvjWPiBYfdZZGy1iAinLm
	7c8CTom17tUV9ftcN3Z2Tomo0zW7LvxcIhrFZaySv5Qs2pXyPqF30u4QFrmZccDQ5wLfRyb8N13
	VQzod
X-Google-Smtp-Source: AGHT+IGo8AkCBVzP0kyZcIGdUmtVpb90lnSabmGU5U+tadHMUWKiWyOYVllW9juZC1PIxcMNKHVXfQ==
X-Received: by 2002:a05:622a:245:b0:42e:dea0:f4b6 with SMTP id c5-20020a05622a024500b0042edea0f4b6mr3224282qtx.2.1710342212202;
        Wed, 13 Mar 2024 08:03:32 -0700 (PDT)
From: Ross Lagerwall 
To: xen-devel@lists.xenproject.org
Cc: Ross Lagerwall ,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Wei Liu ,
	George Dunlap ,
	Julien Grall ,
	Stefano Stabellini 
Subject: [PATCH 1/4] multiboot2: Advertise the load type
Date: Wed, 13 Mar 2024 15:04:36 +0000
Message-ID: <20240313150439.791213-2-ross.lagerwall@citrix.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20240313150439.791213-1-ross.lagerwall@citrix.com>
References: <20240313150439.791213-1-ross.lagerwall@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Advertise the type of the multiboot2 binary we're building. For now,
it's always ELF.

Signed-off-by: Ross Lagerwall 
---
 xen/arch/x86/boot/head.S     | 3 +++
 xen/include/xen/multiboot2.h | 6 ++++++
 2 files changed, 9 insertions(+)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index d8ac0f0494db..015023915a72 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -90,6 +90,9 @@ multiboot2_header:
                    0x200000, /* Load address alignment (2 MiB). */ \
                    MULTIBOOT2_LOAD_PREFERENCE_HIGH
 
+        mb2ht_init MB2_HT(LOAD_TYPE), MB2_HT(OPTIONAL), \
+                   MULTIBOOT2_LOAD_TYPE_ELF
+
         /* Console flags tag. */
         mb2ht_init MB2_HT(CONSOLE_FLAGS), MB2_HT(OPTIONAL), \
                    MULTIBOOT2_CONSOLE_FLAGS_EGA_TEXT_SUPPORTED
diff --git a/xen/include/xen/multiboot2.h b/xen/include/xen/multiboot2.h
index f79204020535..c3a46ad66184 100644
--- a/xen/include/xen/multiboot2.h
+++ b/xen/include/xen/multiboot2.h
@@ -60,6 +60,7 @@
 #define MULTIBOOT2_HEADER_TAG_ENTRY_ADDRESS_EFI32       8
 #define MULTIBOOT2_HEADER_TAG_ENTRY_ADDRESS_EFI64       9
 #define MULTIBOOT2_HEADER_TAG_RELOCATABLE               10
+#define MULTIBOOT2_HEADER_TAG_LOAD_TYPE                 11
 
 /* Header tag flags. */
 #define MULTIBOOT2_HEADER_TAG_REQUIRED                  0
@@ -113,6 +114,11 @@
 #define MULTIBOOT2_FRAMEBUFFER_TYPE_RGB                 1
 #define MULTIBOOT2_FRAMEBUFFER_TYPE_EGA_TEXT            2
 
+/* Load types. */
+#define MULTIBOOT2_LOAD_TYPE_ADDRESS                    0
+#define MULTIBOOT2_LOAD_TYPE_ELF                        1
+#define MULTIBOOT2_LOAD_TYPE_PE                         2
+
 #ifndef __ASSEMBLY__
 typedef struct {
     u32 total_size;
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Wed Mar 13 15:03:37 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 15:03:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692493.1079689 (Exim 4.92)
	(envelope-from )
	id 1rkQ8n-0004NX-KI; Wed, 13 Mar 2024 15:03:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692493.1079689; Wed, 13 Mar 2024 15:03:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkQ8n-0004NQ-HH; Wed, 13 Mar 2024 15:03:37 +0000
Received: by outflank-mailman (input) for mailman id 692493;
 Wed, 13 Mar 2024 15:03:36 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkQ8m-0003t5-Km
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 15:03:36 +0000
Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com
 [2607:f8b0:4864:20::834])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id dd576bb4-e14a-11ee-afdd-a90da7624cb6;
 Wed, 13 Mar 2024 16:03:35 +0100 (CET)
Received: by mail-qt1-x834.google.com with SMTP id
 d75a77b69052e-42f0df98361so31246061cf.0
 for ; Wed, 13 Mar 2024 08:03:36 -0700 (PDT)
Received: from rossla-lxenia.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 s9-20020ac85ec9000000b0042ef4b5f4fbsm4930034qtx.38.2024.03.13.08.03.32
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 13 Mar 2024 08:03:33 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: dd576bb4-e14a-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710342214; x=1710947014; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=ms+OeqOZX4404kFqNdRZ2zfEW4WAGHmhK2r80eh4xas=;
        b=UHYa7BABn5ne2EdclbcNl7t1JLBOk66YsiJeVxsRa4PmKy3hU2/jJ3iRpfAIRGbvET
         t2kfxaBm92gQSJSqwpm/v/i2IMOrA/IH7i0zptMrGLAU8S9IYhCypSWJUD0xy4LrXfJq
         dRkpD/UdihRfml3uEyjsGsMcsPeacomP3+lMg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710342214; x=1710947014;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=ms+OeqOZX4404kFqNdRZ2zfEW4WAGHmhK2r80eh4xas=;
        b=kfDcW6F4xCtAV+fkZonEYO/1rQZPfMPY4a9HcReSDIQwjpHoUEKbRDIEQXph0CU52F
         hlJkoyXanKKPTbXTcP6kCsgpyfxs7CrMaj9UHStCSBJgpuERglrJ9fAmQU7QGezSpzY4
         Pc2QhZNGNu51PCk57YhBtonu0fl2kyzkVHYAw04riYgRgs//gffP3Z0+kG8qV9hv5Qwl
         zxE4il/w2PpCsrZ9ZFf21wywTq8YViKeI0lZpPOsjrTu32ym/ew9cpXPaZ++Yi5mqR03
         loJlcN3iL3vrfgoOAiHI6Ft1ye+faKlByISlo6Eo1UbD4sXUZVd5j6xAq4rAynuKBUYk
         Ws9A==
X-Gm-Message-State: AOJu0YxltmYtELxr24DRls3QoO4N5+iYN5YenbrRXrcO72uhuQf0w3ez
	GGP1iS+XpYMMBoM99R5sMNmNFhYbCAIQyfbYyA3NrHkb3QxBsgNFUcxqOcJYFrFhRIKntrK1kxC
	98LX6
X-Google-Smtp-Source: AGHT+IGD5WDqlGcDnqTFuq88+hJrcAzyIpQImYLYjVAc/i0xiKxZ/uOtj6CH1d9E36pCo1ma3X619A==
X-Received: by 2002:ac8:5f84:0:b0:42e:eb34:5ba5 with SMTP id j4-20020ac85f84000000b0042eeb345ba5mr3769978qta.28.1710342214086;
        Wed, 13 Mar 2024 08:03:34 -0700 (PDT)
From: Ross Lagerwall 
To: xen-devel@lists.xenproject.org
Cc: Ross Lagerwall ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini ,
	Wei Liu ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH 2/4] x86: Add support for building a multiboot2 PE binary
Date: Wed, 13 Mar 2024 15:04:37 +0000
Message-ID: <20240313150439.791213-3-ross.lagerwall@citrix.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20240313150439.791213-1-ross.lagerwall@citrix.com>
References: <20240313150439.791213-1-ross.lagerwall@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Add a new config option, CONFIG_MULTIBOOT_PE, that when set changes
xen.gz to be a compressed PE binary instead of a compressed ELF binary.
This requires use with a multiboot2 loader that supports the PE load
type.

Using this option allows the binary to be signed and verified by Shim.
This means the same xen.gz can then be used for BIOS boot, UEFI Boot and
UEFI boot with Secure Boot verification (all with the convenience of
GRUB2 as a bootloader).

Signed-off-by: Ross Lagerwall 
---
 xen/Makefile             |  1 +
 xen/arch/x86/Kconfig     |  6 +++++
 xen/arch/x86/Makefile    | 48 ++++++++++++++++++++++++++++++++++++++++
 xen/arch/x86/boot/head.S | 33 +++++++++++++++++++++++++++
 4 files changed, 88 insertions(+)

diff --git a/xen/Makefile b/xen/Makefile
index 21832d640225..c9461c9778cc 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -581,6 +581,7 @@ _clean:
 		-o -name ".*.cmd" -o -name "lib.a" \) -exec rm -f {} \;
 	rm -f include/asm $(TARGET) $(TARGET).gz $(TARGET)-syms $(TARGET)-syms.map
 	rm -f $(TARGET).efi $(TARGET).efi.map $(TARGET).efi.elf $(TARGET).efi.stripped
+	rm -f $(TARGET).elf $(TARGET).map
 	rm -f asm-offsets.s arch/*/include/asm/asm-offsets.h
 	rm -f .banner .allconfig.tmp include/xen/compile.h
 	rm -rf $(objtree)/arch/*/include/generated
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 1acdffc51c22..2d8f6e687e58 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -348,6 +348,12 @@ config REQUIRE_NX
 	  was unavailable. However, if enabled, Xen will no longer boot on
 	  any CPU which is lacking NX support.
 
+config MULTIBOOT_PE
+	bool "Build the multiboot binary as PE"
+	help
+	  Build the multiboot xen.gz binary as a PE binary rather than ELF.
+	  This allows it to be signed and verified when using Secure Boot
+	  with Shim and a bootloader.
 endmenu
 
 source "common/Kconfig"
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 26d87405297b..e26b1cb35036 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -123,6 +123,53 @@ syms-warn-dup-$(CONFIG_ENFORCE_UNIQUE_SYMBOLS) := --error-dup
 
 orphan-handling-$(call ld-option,--orphan-handling=warn) += --orphan-handling=warn
 
+ifeq ($(CONFIG_MULTIBOOT_PE),y)
+ifneq ($(XEN_BUILD_PE),y)
+$(TARGET): FORCE
+	rm -f $@
+	echo 'PE build not supported'
+else
+$(TARGET): VIRT_BASE = 0x$(shell $(NM) $(obj)/efi/relocs-dummy.o | sed -n 's, A VIRT_START$$,,p')
+$(TARGET): $(objtree)/prelink.o $(note_file) $(obj)/efi.lds \
+           $(obj)/efi/relocs-dummy.o $(obj)/efi/set-coff-flags $(TARGET)-syms $(efi-y)
+ifeq ($(CONFIG_DEBUG_INFO),y)
+	$(if $(filter --strip-debug,$(EFI_LDFLAGS)),echo,:) "Will strip debug info from $(@F)"
+endif
+	$(LD) $(call EFI_LDFLAGS,$(VIRT_BASE)) --disable-reloc-section \
+	      -T $(obj)/efi.lds -N $< $(relocs-dummy) \
+	      $(objtree)/common/symbols-dummy.o $(note_file_option) \
+	      -o $(dot-target).$(VIRT_BASE).0
+	$(NM) -pa --format=sysv $(dot-target).$(VIRT_BASE).0 \
+		| $(objtree)/tools/symbols $(all_symbols) --sysv --sort \
+		> $(dot-target).0s.S
+	$(MAKE) $(build)=$(@D) .$(@F).0s.o
+	$(LD) $(call EFI_LDFLAGS,$(VIRT_BASE)) --disable-reloc-section \
+	      -T $(obj)/efi.lds -N $< $(dot-target).0s.o $(note_file_option) \
+	      -o $(dot-target).$(VIRT_BASE).1
+	$(NM) -pa --format=sysv $(dot-target).$(VIRT_BASE).1 \
+		| $(objtree)/tools/symbols $(all_symbols) --sysv --sort \
+		> $(dot-target).1s.S
+	$(MAKE) $(build)=$(@D) .$(@F).1s.o
+	$(LD) $(call EFI_LDFLAGS,$(VIRT_BASE)) --disable-reloc-section \
+	      -T $(obj)/efi.lds -N $< $(dot-target).1s.o $(orphan-handling-y) \
+	      $(note_file_option) -o $@.tmp
+	od -t x4 -N 8192 $@.tmp  | grep 1badb002 > /dev/null || \
+		{ echo "No Multiboot1 header found" >&2; false; }
+	od -t x4 -N 32768 $@.tmp | grep e85250d6 > /dev/null || \
+		{ echo "No Multiboot2 header found" >&2; false; }
+	mv $@.tmp $(TARGET)
+	$(NM) -pa --format=sysv $@ \
+		| $(objtree)/tools/symbols --all-symbols --xensyms --sysv --sort \
+		> $@.map
+ifeq ($(CONFIG_DEBUG_INFO),y)
+	$(if $(filter --strip-debug,$(EFI_LDFLAGS)),:$(space))$(OBJCOPY) -O elf64-x86-64 $@ $@.elf
+endif
+	rm -f $(dot-target).[0-9]* $(@D)/..$(@F).[0-9]*
+ifeq ($(CONFIG_XEN_IBT),y)
+	$(SHELL) $(srctree)/tools/check-endbr.sh $@
+endif
+endif
+else
 $(TARGET): TMP = $(dot-target).elf32
 $(TARGET): $(TARGET)-syms $(efi-y) $(obj)/boot/mkelf32
 	$(obj)/boot/mkelf32 $(notes_phdrs) $(TARGET)-syms $(TMP) $(XEN_IMG_OFFSET) \
@@ -132,6 +179,7 @@ $(TARGET): $(TARGET)-syms $(efi-y) $(obj)/boot/mkelf32
 	od -t x4 -N 32768 $(TMP) | grep e85250d6 > /dev/null || \
 		{ echo "No Multiboot2 header found" >&2; false; }
 	mv $(TMP) $(TARGET)
+endif
 
 CFLAGS-$(XEN_BUILD_EFI) += -DXEN_BUILD_EFI
 
diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 015023915a72..84dc8b76b61d 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -44,6 +44,25 @@
 .Lmb2ht_init_end\@:
         .endm
 
+        .macro mb2ht_qargs arg:req, args:vararg
+        .quad \arg
+        .ifnb \args
+        mb2ht_args \args
+        .endif
+        .endm
+
+        .macro mb2ht_qinit type:req, req:req, args:vararg
+        .balign MULTIBOOT2_TAG_ALIGN, 0xc2 /* Avoid padding with long nops. */
+.Lmb2ht_init_start\@:
+        .short \type
+        .short \req
+        .long .Lmb2ht_init_end\@ - .Lmb2ht_init_start\@
+        .ifnb \args
+        mb2ht_qargs \args
+        .endif
+.Lmb2ht_init_end\@:
+        .endm
+
 ENTRY(start)
         jmp     __start
 
@@ -90,8 +109,14 @@ multiboot2_header:
                    0x200000, /* Load address alignment (2 MiB). */ \
                    MULTIBOOT2_LOAD_PREFERENCE_HIGH
 
+        /* Load type */
+#ifdef CONFIG_MULTIBOOT_PE
+        mb2ht_init MB2_HT(LOAD_TYPE), MB2_HT(OPTIONAL), \
+                   MULTIBOOT2_LOAD_TYPE_PE
+#else
         mb2ht_init MB2_HT(LOAD_TYPE), MB2_HT(OPTIONAL), \
                    MULTIBOOT2_LOAD_TYPE_ELF
+#endif
 
         /* Console flags tag. */
         mb2ht_init MB2_HT(CONSOLE_FLAGS), MB2_HT(OPTIONAL), \
@@ -107,8 +132,16 @@ multiboot2_header:
         mb2ht_init MB2_HT(EFI_BS), MB2_HT(OPTIONAL)
 
         /* EFI64 Multiboot2 entry point. */
+#ifdef CONFIG_MULTIBOOT_PE
+        mb2ht_qinit MB2_HT(ENTRY_ADDRESS_EFI64), MB2_HT(OPTIONAL), \
+                   __efi64_mb2_start
+
+        mb2ht_qinit MB2_HT(ENTRY_ADDRESS), MB2_HT(OPTIONAL), \
+                   start
+#else
         mb2ht_init MB2_HT(ENTRY_ADDRESS_EFI64), MB2_HT(OPTIONAL), \
                    sym_offs(__efi64_mb2_start)
+#endif
 
         /* Multiboot2 header end tag. */
         mb2ht_init MB2_HT(END), MB2_HT(REQUIRED)
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Wed Mar 13 15:03:39 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 15:03:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692494.1079699 (Exim 4.92)
	(envelope-from )
	id 1rkQ8p-0004eh-Sn; Wed, 13 Mar 2024 15:03:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692494.1079699; Wed, 13 Mar 2024 15:03:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkQ8p-0004eY-PI; Wed, 13 Mar 2024 15:03:39 +0000
Received: by outflank-mailman (input) for mailman id 692494;
 Wed, 13 Mar 2024 15:03:39 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkQ8p-0003t5-2J
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 15:03:39 +0000
Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com
 [2607:f8b0:4864:20::734])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ded11ed3-e14a-11ee-afdd-a90da7624cb6;
 Wed, 13 Mar 2024 16:03:38 +0100 (CET)
Received: by mail-qk1-x734.google.com with SMTP id
 af79cd13be357-7882e94d408so541337985a.0
 for ; Wed, 13 Mar 2024 08:03:38 -0700 (PDT)
Received: from rossla-lxenia.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 s9-20020ac85ec9000000b0042ef4b5f4fbsm4930034qtx.38.2024.03.13.08.03.34
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 13 Mar 2024 08:03:35 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ded11ed3-e14a-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710342216; x=1710947016; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=U4TeTAtNjsqWwlrctsZmN5LB4TEkMI5eFT9ZNBGXubI=;
        b=QXv1Ogx7cB5RsixhnMvChPv95kZ4LAXWT7izmloYZE4YqONv2wv2tDL+ftCgdwnd6a
         v9ddVubasZrGmm6qWWuf9qcOXPLhjYGreFyqjHrrnLPdhwGlXtTwVlhyrxGUnHEkExoJ
         zk1MgaZsZQ2cu9z2ep0OTxddCHTKvJFzQewi4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710342216; x=1710947016;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=U4TeTAtNjsqWwlrctsZmN5LB4TEkMI5eFT9ZNBGXubI=;
        b=erm0ZfNIvFgYlJX2N5NPzEd78ZjlQfnSKthAVTCwdVvn73aSosd5ONj0NTil0P72IA
         aJYq9FTpDNH0VTd9t/mut3KM5KrpY/oMpuW4C7PTGqJxhrX+e2idLEX82Opbls/przDj
         WDcmWjzu/ubKFn1CzNQxm/bFehMpWlA3+IJxYCLzJAKuwH5cZMHMubySOG8r4B5IfwFO
         t1L0PgIv/BTVPJlAllqcBk3hA0xfi2vbx8Fzgj8HcNXlOKVodtqU46MGqAv/yVVzQUaL
         OLr58ohtswVj/w2YaNJJ/jFg432BCsaduZkOq5JSX2+FS8475/vSfogdN+wV25t3/wyR
         Mlug==
X-Gm-Message-State: AOJu0Yyuwq0Y4YgNh15ZWmtCItwWioqFN4V1Ko6oBTor4x3DpXR/ayXe
	q5LOr1vOgoz5F4rDGz1Ec2Ou73NobPU5KeQibl8rBq/5XcoXnkhQWk7NkXQQyLp7Jr/z+dFA/4B
	lSy2h
X-Google-Smtp-Source: AGHT+IE7eJh239NUg3LLwlY/kx4HoJml6ruPsHnqzezPRVHpl1dImCS7EL5JGXJT9DvImYTHuGiuAQ==
X-Received: by 2002:a05:622a:251:b0:42e:f101:952 with SMTP id c17-20020a05622a025100b0042ef1010952mr17139115qtx.11.1710342216119;
        Wed, 13 Mar 2024 08:03:36 -0700 (PDT)
From: Ross Lagerwall 
To: xen-devel@lists.xenproject.org
Cc: Ross Lagerwall ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini ,
	Wei Liu ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH 3/4] x86: Hand-edit coff flags to remove RELOCS_STRIPPED flag
Date: Wed, 13 Mar 2024 15:04:38 +0000
Message-ID: <20240313150439.791213-4-ross.lagerwall@citrix.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20240313150439.791213-1-ross.lagerwall@citrix.com>
References: <20240313150439.791213-1-ross.lagerwall@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

The generated PE binary is generated without relocations since it does
not need them. However, the linker sets the IMAGE_FILE_RELOCS_STRIPPED
flag which implies the binary is not relocatable and this causes some
tools to refuse to handle the binary (e.g. Shim). As there is no option
to remove this flag using the linker, post-process the binary to do it.

Signed-off-by: Ross Lagerwall 
---
 .gitignore                        |  1 +
 xen/arch/x86/Makefile             |  2 +
 xen/arch/x86/efi/set-coff-flags.c | 83 +++++++++++++++++++++++++++++++
 3 files changed, 86 insertions(+)
 create mode 100644 xen/arch/x86/efi/set-coff-flags.c

diff --git a/.gitignore b/.gitignore
index d8b57e32f888..ab0b18352a0f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -256,6 +256,7 @@ xen/arch/x86/boot/*.lnk
 xen/arch/x86/efi.lds
 xen/arch/x86/efi/check.efi
 xen/arch/x86/efi/mkreloc
+xen/arch/x86/efi/set-coff-flags
 xen/arch/x86/include/asm/asm-macros.h
 xen/arch/*/xen.lds
 xen/arch/*/efi/boot.c
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index e26b1cb35036..73b16ddeb976 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -86,6 +86,7 @@ extra-y += xen.lds
 
 hostprogs-y += boot/mkelf32
 hostprogs-y += efi/mkreloc
+hostprogs-y += efi/set-coff-flags
 
 # Allows usercopy.c to include itself
 $(obj)/usercopy.o: CFLAGS-y += -iquote .
@@ -157,6 +158,7 @@ endif
 		{ echo "No Multiboot1 header found" >&2; false; }
 	od -t x4 -N 32768 $@.tmp | grep e85250d6 > /dev/null || \
 		{ echo "No Multiboot2 header found" >&2; false; }
+	$(obj)/efi/set-coff-flags $@.tmp
 	mv $@.tmp $(TARGET)
 	$(NM) -pa --format=sysv $@ \
 		| $(objtree)/tools/symbols --all-symbols --xensyms --sysv --sort \
diff --git a/xen/arch/x86/efi/set-coff-flags.c b/xen/arch/x86/efi/set-coff-flags.c
new file mode 100644
index 000000000000..a99415e6bcbf
--- /dev/null
+++ b/xen/arch/x86/efi/set-coff-flags.c
@@ -0,0 +1,83 @@
+#include 
+#include 
+#include 
+#include 
+
+struct mz_hdr {
+    uint16_t signature;
+#define MZ_SIGNATURE 0x5a4d
+    uint16_t last_page_size;
+    uint16_t page_count;
+    uint16_t relocation_count;
+    uint16_t header_paras;
+    uint16_t min_paras;
+    uint16_t max_paras;
+    uint16_t entry_ss;
+    uint16_t entry_sp;
+    uint16_t checksum;
+    uint16_t entry_ip;
+    uint16_t entry_cs;
+    uint16_t relocations;
+    uint16_t overlay;
+    uint8_t reserved[32];
+    uint32_t extended_header_base;
+};
+
+struct coff_hdr {
+    uint32_t signature;
+    uint16_t cpu;
+    uint16_t section_count;
+    int32_t timestamp;
+    uint32_t symbols_file_offset;
+    uint32_t symbol_count;
+    uint16_t opt_hdr_size;
+    uint16_t flags;
+};
+
+int main(int argc, char **argv)
+{
+    int fd;
+    struct mz_hdr mz_hdr;
+    struct coff_hdr coff_hdr;
+
+    if ( argc != 2 )
+    {
+        fprintf(stderr, "usage: %s \n", argv[0]);
+        return 1;
+    }
+
+    fd = open(argv[1], O_RDWR);
+    if ( fd < 0 ||
+         read(fd, &mz_hdr, sizeof(mz_hdr)) != sizeof(mz_hdr) )
+    {
+        perror(argv[1]);
+        return 2;
+    }
+
+    if ( mz_hdr.signature != MZ_SIGNATURE ||
+         !mz_hdr.extended_header_base )
+    {
+        fprintf(stderr, "%s: Wrong DOS file format\n", argv[1]);
+        return 2;
+    }
+
+    if ( lseek(fd, mz_hdr.extended_header_base, SEEK_SET) < 0 ||
+         read(fd, &coff_hdr, sizeof(coff_hdr)) != sizeof(coff_hdr) )
+    {
+        perror(argv[1]);
+        return 2;
+    }
+
+    coff_hdr.flags &= ~0x1;
+
+    if ( lseek(fd, mz_hdr.extended_header_base, SEEK_SET) < 0 ||
+         write(fd, &coff_hdr, sizeof(coff_hdr)) != sizeof(coff_hdr) )
+    {
+        perror(argv[1]);
+        return 3;
+    }
+
+    close(fd);
+
+    return 0;
+}
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Wed Mar 13 15:03:42 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 15:03:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692495.1079709 (Exim 4.92)
	(envelope-from )
	id 1rkQ8s-0004wN-3g; Wed, 13 Mar 2024 15:03:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692495.1079709; Wed, 13 Mar 2024 15:03:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkQ8s-0004wA-10; Wed, 13 Mar 2024 15:03:42 +0000
Received: by outflank-mailman (input) for mailman id 692495;
 Wed, 13 Mar 2024 15:03:40 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkQ8q-0003t5-HB
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 15:03:40 +0000
Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com
 [2607:f8b0:4864:20::832])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id dfbba345-e14a-11ee-afdd-a90da7624cb6;
 Wed, 13 Mar 2024 16:03:39 +0100 (CET)
Received: by mail-qt1-x832.google.com with SMTP id
 d75a77b69052e-42f468b62f1so18609091cf.1
 for ; Wed, 13 Mar 2024 08:03:39 -0700 (PDT)
Received: from rossla-lxenia.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 s9-20020ac85ec9000000b0042ef4b5f4fbsm4930034qtx.38.2024.03.13.08.03.36
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 13 Mar 2024 08:03:37 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: dfbba345-e14a-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710342218; x=1710947018; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=QiEx2+FLzW3zGCVQrA43mi0ECENchTli/sSUjekg7XE=;
        b=qZwyMYL1mLpk7EdfkdjdqZKanWej+vjsND+QOl/Rao1w9ewDq+Qn9aBraHZpn9EOpK
         tf6nbrUsMk6SVhbmyVu9e6yhf5u2tYQeooMZT15XeHKQxZKeGTIfaIoGiFKe+CNxtbkA
         AOiSjWaVKUe7i+2gFK4zAX59HhFWuvZlx6N0k=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710342218; x=1710947018;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=QiEx2+FLzW3zGCVQrA43mi0ECENchTli/sSUjekg7XE=;
        b=c0EiK4mA/pA3NxeKq5YPN37COjddCA2eDgfemKd8B2aIoqgIBTgI237oslq+whDec8
         oBtv2AWtDg3RzUveUuksAKhLeLTgZc75blavj6s6HIPakrXlxm5TMR2vySQe3BAbi5Tb
         QMiRl9KWg7FQPSi3juLjwk+5x0wORjcR4qCC8eOYPO5o0zwEb+S7eVOpEhgq377ci20R
         +8CTORlRFhTd3Qt7LFtYtY/k+K/unNAkcuYGYOVkEt5JW5fwXFeQWVCKJevnh0j/IG+G
         HlCFH5nJ3XBAgVc1cx+5OjU7zxja196iMwDFhhspVTpp3JJ9fxqpmOtIvueZ9mq6qmu6
         98ZQ==
X-Gm-Message-State: AOJu0YzN/s8fbMgfxn/zNQzNBV4+3GDx+1Gs7Qzbl9FOY0fSBo/7fYrG
	hJNpoIKDKAL06Io8t3oEqMpV4N5h/95MjCTTyuomYXlh/lVkYwNmOG6fGb0Ud7IA+jEdt0bJbrf
	ltQ==
X-Google-Smtp-Source: AGHT+IEY4iMUpxcQkqaJtj9BZiqXpcRfn1PNNn7j6IsH2RqYkSF7CFfot+XPRvFlXjpahBC8IR10pQ==
X-Received: by 2002:a05:622a:653:b0:42e:eb7d:1ab3 with SMTP id a19-20020a05622a065300b0042eeb7d1ab3mr5774242qtb.65.1710342218284;
        Wed, 13 Mar 2024 08:03:38 -0700 (PDT)
From: Ross Lagerwall 
To: xen-devel@lists.xenproject.org
Cc: Ross Lagerwall ,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Wei Liu 
Subject: [PATCH 4/4] x86: Call Shim Verify in the multiboot2 path
Date: Wed, 13 Mar 2024 15:04:39 +0000
Message-ID: <20240313150439.791213-5-ross.lagerwall@citrix.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20240313150439.791213-1-ross.lagerwall@citrix.com>
References: <20240313150439.791213-1-ross.lagerwall@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Now that the multiboot2 binary can be verified by Shim, ensure that the
dom0 kernel is verified when using the multiboot2 path. If the Shim
protocol is not available and the SecureBoot variable is not set to 0
(or the state cannot be determined), abort the boot.

Signed-off-by: Ross Lagerwall 
---
 xen/arch/x86/boot/head.S    |  4 ++-
 xen/arch/x86/efi/efi-boot.h | 65 ++++++++++++++++++++++++++++++++++++-
 2 files changed, 67 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 84dc8b76b61d..7b6e5d3882ad 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -385,10 +385,12 @@ __efi64_mb2_start:
         /* Keep the stack aligned. Do not pop a single item off it. */
         mov     (%rsp),%rdi
 
+        mov     %rbx, %rcx
+
         /*
          * efi_multiboot2() is called according to System V AMD64 ABI:
          *   - IN:  %rdi - EFI ImageHandle, %rsi - EFI SystemTable,
-         *          %rdx - MB2 cmdline
+         *          %rdx - MB2 cmdline, %rcx - Multiboot information.
          */
         call    efi_multiboot2
 
diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h
index 8ea64e31cdc2..a9569e150e08 100644
--- a/xen/arch/x86/efi/efi-boot.h
+++ b/xen/arch/x86/efi/efi-boot.h
@@ -3,6 +3,7 @@
  * is intended to be included by common/efi/boot.c _only_, and
  * therefore can define arch specific global variables.
  */
+#include 
 #include 
 #include 
 #include 
@@ -808,9 +809,69 @@ static const char *__init get_option(const char *cmd, const char *opt)
     return o;
 }
 
+#define ALIGN_UP(arg, align) \
+                (((arg) + (align) - 1) & ~((typeof(arg))(align) - 1))
+
+static void __init efi_verify_dom0(uint64_t mbi_in)
+{
+    uint64_t ptr;
+    const multiboot2_tag_t *tag;
+    EFI_SHIM_LOCK_PROTOCOL *shim_lock;
+    EFI_STATUS status;
+    const multiboot2_tag_module_t *kernel = NULL;
+    const multiboot2_fixed_t *mbi_fix = _p(mbi_in);
+    static EFI_GUID __initdata shim_lock_guid = SHIM_LOCK_PROTOCOL_GUID;
+    static EFI_GUID __initdata global_variable_guid = EFI_GLOBAL_VARIABLE;
+
+    ptr = ALIGN_UP(mbi_in + sizeof(*mbi_fix), MULTIBOOT2_TAG_ALIGN);
+
+    for ( tag = _p(ptr); (uint64_t)tag - mbi_in < mbi_fix->total_size;
+          tag = _p(ALIGN_UP((uint64_t)tag + tag->size, MULTIBOOT2_TAG_ALIGN)) )
+    {
+        if ( tag->type == MULTIBOOT2_TAG_TYPE_MODULE )
+        {
+            kernel = (const multiboot2_tag_module_t *)tag;
+            break;
+        }
+        else if ( tag->type == MULTIBOOT2_TAG_TYPE_END )
+            break;
+    }
+
+    if ( !kernel )
+        return;
+
+    if ( (status = efi_bs->LocateProtocol(&shim_lock_guid, NULL,
+                                          (void **)&shim_lock)) != EFI_SUCCESS )
+    {
+        UINT32 attr;
+        UINT8 data;
+        UINTN size = sizeof(data);
+
+        status = efi_rs->GetVariable((CHAR16 *)L"SecureBoot", &global_variable_guid,
+                                     &attr, &size, &data);
+        if ( status == EFI_NOT_FOUND )
+            return;
+
+        if ( EFI_ERROR(status) )
+            PrintErrMesg(L"Could not get SecureBoot variable", status);
+
+        if ( attr != (EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_RUNTIME_ACCESS) )
+            PrintErrMesg(L"Unexpected SecureBoot attributes", attr);
+
+        if ( size == 1 && data == 0 )
+            return;
+
+        blexit(L"Could not locate shim but Secure Boot is enabled");
+    }
+
+    if ( (status = shim_lock->Verify(_p(kernel->mod_start),
+                                     kernel->mod_end - kernel->mod_start)) != EFI_SUCCESS )
+        PrintErrMesg(L"Dom0 kernel image could not be verified", status);
+}
+
 void asmlinkage __init efi_multiboot2(EFI_HANDLE ImageHandle,
                                       EFI_SYSTEM_TABLE *SystemTable,
-                                      const char *cmdline)
+                                      const char *cmdline, uint64_t mbi_in)
 {
     EFI_GRAPHICS_OUTPUT_PROTOCOL *gop;
     EFI_HANDLE gop_handle;
@@ -902,6 +963,8 @@ void asmlinkage __init efi_multiboot2(EFI_HANDLE ImageHandle,
 
     efi_relocate_esrt(SystemTable);
 
+    efi_verify_dom0(mbi_in);
+
     efi_exit_boot(ImageHandle, SystemTable);
 }
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Wed Mar 13 15:04:35 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 15:04:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692509.1079718 (Exim 4.92)
	(envelope-from )
	id 1rkQ9g-0006Sh-Bp; Wed, 13 Mar 2024 15:04:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692509.1079718; Wed, 13 Mar 2024 15:04:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkQ9g-0006Sa-9H; Wed, 13 Mar 2024 15:04:32 +0000
Received: by outflank-mailman (input) for mailman id 692509;
 Wed, 13 Mar 2024 15:04:31 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkQ9e-0005W8-Sp
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 15:04:31 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id fd55cbe6-e14a-11ee-a1ee-f123f15fe8a2;
 Wed, 13 Mar 2024 16:04:29 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org
 [IPv6:2a07:de40:b281:104:10:150:64:97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id 5343821CA0;
 Wed, 13 Mar 2024 15:04:26 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id D09C913977;
 Wed, 13 Mar 2024 15:04:25 +0000 (UTC)
Received: from dovecot-director2.suse.de ([10.150.64.162])
 by imap1.dmz-prg2.suse.org with ESMTPSA id qUokMXnA8WUhbgAAD6G6ig
 (envelope-from ); Wed, 13 Mar 2024 15:04:25 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: fd55cbe6-e14a-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1710342268; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=MJquF6KXXTJLVkkxo2hBLD1sqths3pcvQILfxZXYAOE=;
	b=CpzvDyexgSTwApHe2RAPfz7nuX5V657R1GRWfjFNuVu74d2nDbjya4EdPNxIMoaBosON9Q
	eSP7mqOOUzQUY4YCSX0PB5u8zeiV3SldNBMiAtxfYQIi7SEiMwIPBNBxcsfIMemQH9fqzm
	FQwsBTdLcA9zhsa5/TfomCS6GO23QpA=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1710342266; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=MJquF6KXXTJLVkkxo2hBLD1sqths3pcvQILfxZXYAOE=;
	b=Pak2riYkdE6IMcOExxtUMKT11ANKq+/aWQOdyBybLls995Z6LA9mryzSv0qK3sho+IqT9L
	EXSYrhMp/pfzGl9tA0FCRirIKdjYWYm3ghW4SJR8Q4BtJsZcjZJaWwdUuTxz/Un91wJLzy
	y2onpTAXfzRqYRsMJ/XAuspXUvMQphQ=
Message-ID: <48f416e8-bc9a-40ba-b2d6-80c047ba26e4@suse.com>
Date: Wed, 13 Mar 2024 16:04:25 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH RFC] x86/xen: attempt to inflate the memory balloon on PVH
Content-Language: en-US
To: Roger Pau Monne , xen-devel@lists.xenproject.org
Cc: Boris Ostrovsky ,
 Thomas Gleixner , Ingo Molnar ,
 Borislav Petkov , Dave Hansen ,
 x86@kernel.org, "H. Peter Anvin" ,
 Stefano Stabellini ,
 Oleksandr Tyshchenko ,
 linux-kernel@vger.kernel.org, Jan Beulich ,
 Andrew Cooper 
References: <20240220174341.56131-1-roger.pau@citrix.com>
From: Juergen Gross 
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <20240220174341.56131-1-roger.pau@citrix.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------lukQeqLpao50sQ58EegVaSWD"
X-Spam-Level: 
Authentication-Results: smtp-out1.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b=Pak2riYk
X-Rspamd-Server: rspamd2.dmz-prg2.suse.org
X-Spamd-Result: default: False [-4.40 / 50.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 XM_UA_NO_VERSION(0.01)[];
	 SPAMHAUS_XBL(0.00)[2a07:de40:b281:104:10:150:64:97:from];
	 TO_DN_SOME(0.00)[];
	 HAS_ATTACHMENT(0.00)[];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_TRACE(0.00)[suse.com:+];
	 MIME_BASE64_TEXT(0.10)[];
	 MX_GOOD(-0.01)[];
	 SIGNED_PGP(-2.00)[];
	 NEURAL_HAM_SHORT(-0.20)[-0.999];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~];
	 BAYES_HAM(-1.00)[87.20%];
	 MID_RHS_MATCH_FROM(0.00)[];
	 MIME_UNKNOWN(0.10)[application/pgp-keys];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[suse.com:s=susede1];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain];
	 DKIM_SIGNED(0.00)[suse.com:s=susede1];
	 RCPT_COUNT_TWELVE(0.00)[14];
	 DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:dkim,suse.com:email,citrix.com:email];
	 FUZZY_BLOCKED(0.00)[rspamd.com];
	 RCVD_TLS_ALL(0.00)[]
X-Spam-Score: -4.40
X-Rspamd-Queue-Id: 5343821CA0
X-Spam-Flag: NO

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------lukQeqLpao50sQ58EegVaSWD
Content-Type: multipart/mixed; boundary="------------V701cGJoEdBL7EIPCxDj2p33";
 protected-headers="v1"
From: Juergen Gross 
To: Roger Pau Monne , xen-devel@lists.xenproject.org
Cc: Boris Ostrovsky ,
 Thomas Gleixner , Ingo Molnar ,
 Borislav Petkov , Dave Hansen ,
 x86@kernel.org, "H. Peter Anvin" ,
 Stefano Stabellini ,
 Oleksandr Tyshchenko ,
 linux-kernel@vger.kernel.org, Jan Beulich ,
 Andrew Cooper 
Message-ID: <48f416e8-bc9a-40ba-b2d6-80c047ba26e4@suse.com>
Subject: Re: [PATCH RFC] x86/xen: attempt to inflate the memory balloon on PVH
References: <20240220174341.56131-1-roger.pau@citrix.com>
In-Reply-To: <20240220174341.56131-1-roger.pau@citrix.com>
Autocrypt-Gossip: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE
 ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2
 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd
 pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ
 tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf
 OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C
 v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou
 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU
 jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z
 DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP
 Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ
 dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef
 AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs=

--------------V701cGJoEdBL7EIPCxDj2p33
Content-Type: multipart/mixed; boundary="------------02WoOvt4w3SI1E4n08d3csqt"

--------------02WoOvt4w3SI1E4n08d3csqt
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMjAuMDIuMjQgMTg6NDMsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToNCj4gV2hlbiBydW5u
aW5nIGFzIFBWSCBvciBIVk0gTGludXggd2lsbCB1c2UgaG9sZXMgaW4gdGhlIG1lbW9yeSBt
YXAgYXMgc2NyYXRjaA0KPiBzcGFjZSB0byBtYXAgZ3JhbnRzLCBmb3JlaWduIGRvbWFpbiBw
YWdlcyBhbmQgcG9zc2libHkgbWlzY2VsbGFuZW91cyBvdGhlcg0KPiBzdHVmZi4gIEhvd2V2
ZXIgdGhlIHVzYWdlIG9mIHN1Y2ggbWVtb3J5IG1hcCBob2xlcyBmb3IgWGVuIHB1cnBvc2Vz
IGNhbiBiZQ0KPiBwcm9ibGVtYXRpYy4gIFRoZSByZXF1ZXN0IG9mIGhvbGVzYnkgWGVuIGhh
cHBlbiBxdWl0ZSBlYXJseSBpbiB0aGUga2VybmVsIGJvb3QNCj4gcHJvY2VzcyAoZ3JhbnQg
dGFibGUgc2V0dXAgYWxyZWFkeSB1c2VzIHNjcmF0Y2ggbWFwIHNwYWNlKSwgYW5kIGl0J3Mg
cG9zc2libGUNCj4gdGhhdCBieSB0aGVuIG5vdCBhbGwgZGV2aWNlcyBoYXZlIHJlY2xhaW1l
ZCB0aGVpciBNTUlPIHNwYWNlLiAgSXQncyBub3QNCj4gdW5saWtlbHkgZm9yIGNodW5rcyBv
ZiBYZW4gc2NyYXRjaCBtYXAgc3BhY2UgdG8gZW5kIHVwIHVzaW5nIFBDSSBicmlkZ2UgTU1J
Tw0KPiB3aW5kb3cgbWVtb3J5LCB3aGljaCAoYXMgZXhwZWN0ZWQpIGNhdXNlcyBxdWl0ZSBh
IGxvdCBvZiBpc3N1ZXMgaW4gdGhlIHN5c3RlbS4NCj4gDQo+IEF0IGxlYXN0IGZvciBQVkgg
ZG9tMCB3ZSBoYXZlIHRoZSBwb3NzaWJpbGl0eSBvZiB1c2luZyByZWdpb25zIG1hcmtlZCBh
cw0KPiBVTlVTQUJMRSBpbiB0aGUgZTgyMCBtZW1vcnkgbWFwLiAgRWl0aGVyIGlmIHRoZSBy
ZWdpb24gaXMgVU5VU0FCTEUgaW4gdGhlDQo+IG5hdGl2ZSBtZW1vcnkgbWFwLCBvciBpdCBo
YXMgYmVlbiBjb252ZXJ0ZWQgaW50byBVTlVTQUJMRSBpbiBvcmRlciB0byBoaWRlIFJBTQ0K
PiByZWdpb25zIGZyb20gZG9tMCwgdGhlIHNlY29uZCBzdGFnZSB0cmFuc2xhdGlvbiBwYWdl
LXRhYmxlcyBjYW4gcG9wdWxhdGUgdGhvc2UNCj4gYXJlYXMgd2l0aG91dCBpc3N1ZXMuDQo+
IA0KPiBQViBhbHJlYWR5IGhhcyB0aGlzIGtpbmQgb2YgbG9naWMsIHdoZXJlIHRoZSBiYWxs
b29uIGRyaXZlciBpcyBpbmZsYXRlZCBhdA0KPiBib290LiAgUmUtdXNlIHRoZSBjdXJyZW50
IGxvZ2ljIGluIG9yZGVyIHRvIGFsc28gaW5mbGF0ZSBpdCB3aGVuIHJ1bm5pbmcgYXMNCj4g
UFZILiAgb252ZXJ0IFVOVVNBQkxFIHJlZ2lvbnMgdXAgdG8gdGhlIHJhdGlvIHNwZWNpZmll
ZCBpbiBFWFRSQV9NRU1fUkFUSU8gdG8NCj4gUkFNLCB3aGlsZSByZXNlcnZpbmcgdGhlbSB1
c2luZyB4ZW5fYWRkX2V4dHJhX21lbSgpICh3aGljaCBpcyBhbHNvIG1vdmVkIHNvDQo+IGl0
J3Mgbm8gbG9uZ2VyIHRpZWQgdG8gQ09ORklHX1BWKS4NCj4gDQo+IFNpZ25lZC1vZmYtYnk6
IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXguY29tPg0KDQpSZXZpZXdlZC1i
eTogSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1c2UuY29tPg0KDQoNCkp1ZXJnZW4NCg0K
--------------02WoOvt4w3SI1E4n08d3csqt
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri
oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2
kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i
1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B
BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK
N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg
PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE
FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F
UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye
vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u
+6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq
qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP
tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy
Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ
CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4
RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7
8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T
BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ
SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK
7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM
nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB
AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/
Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN
hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi
w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf
VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP
OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK
/1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1
c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC
F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4
k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ
wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu
5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB
TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io
N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6
AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr
0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x
Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF
LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm
we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I
v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv
Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD
534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH
b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT
yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc
suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B
jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W
KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge
gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422
bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN
aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay
7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF
RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn
g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib
4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX
kt+z4drzFUyEjLM1vVvIMjkUoJs=3D
=3DeeAB
-----END PGP PUBLIC KEY BLOCK-----

--------------02WoOvt4w3SI1E4n08d3csqt--

--------------V701cGJoEdBL7EIPCxDj2p33--

--------------lukQeqLpao50sQ58EegVaSWD
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmXxwHkFAwAAAAAACgkQsN6d1ii/Ey9L
jQgAmuIosn7pT/hYhqzPSqLI14Im8vIgpWJolOg2bQ+shYwpFmsOkHNJsUmlX65sYS4hS5gtMBsu
frY6DC0PJ8ASSIwOCkJtPCI1ZN3MPHwoi0t8Kh8YbDQKsqk3DIOrdT2WKPp6O5z2IkiMBPRkh38R
5XPY8358w/1oqrCPmdnQKodktEIEeTZH75JnFS9wtmB1v0HRSjM0KC+kQ47Uj4LeVnQ1zja1nFSC
VgbYYUhpejAYi1pHoEXvead1WJ5WzbM0oKJi2LMxv4F4Zx+2InHr824Cq6lta10tMY0JX7E9EUtS
2T/PiZOJ9LNRZeyKhdnklL5ZV3WFaQ3EPvMAXNfKqQ==
=ibOz
-----END PGP SIGNATURE-----

--------------lukQeqLpao50sQ58EegVaSWD--


From xen-devel-bounces@lists.xenproject.org Wed Mar 13 15:06:42 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 15:06:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692516.1079729 (Exim 4.92)
	(envelope-from )
	id 1rkQBl-0007EH-S7; Wed, 13 Mar 2024 15:06:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692516.1079729; Wed, 13 Mar 2024 15:06:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkQBl-0007EA-PT; Wed, 13 Mar 2024 15:06:41 +0000
Received: by outflank-mailman (input) for mailman id 692516;
 Wed, 13 Mar 2024 15:06:41 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkQBl-0007E2-36
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 15:06:41 +0000
Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com
 [2607:f8b0:4864:20::72f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4aa96ae8-e14b-11ee-a1ee-f123f15fe8a2;
 Wed, 13 Mar 2024 16:06:39 +0100 (CET)
Received: by mail-qk1-x72f.google.com with SMTP id
 af79cd13be357-7810827e54eso499590585a.2
 for ; Wed, 13 Mar 2024 08:06:39 -0700 (PDT)
Received: from rossla-lxenia.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 p10-20020a0ccb8a000000b0068fba49ae81sm4786811qvk.57.2024.03.13.08.06.36
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 13 Mar 2024 08:06:37 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4aa96ae8-e14b-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710342398; x=1710947198; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:from:to:cc:subject:date:message-id:reply-to;
        bh=7dNacejZJRMQu9t2c+pDCXl+dVVU+S1TMISMGfwPh5c=;
        b=fBk9saJOu0U5/qgHpI4jL832doMC1WcFlUOVINcA+uodwu/XXalWWWQ8svxK5deug8
         azm9ykTuxehdavkbareWpGLRgLPgvEKyVjM9jmkUre0IWYTbJFGean/kEXQpks5IaCgk
         v2dEYmoQwu8msLkR10QwhsgxcSX1oGzd2q+9E=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710342398; x=1710947198;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=7dNacejZJRMQu9t2c+pDCXl+dVVU+S1TMISMGfwPh5c=;
        b=dErGe+BQikU2/MsJZZ/20eF0jpjyxTUdzwit0r22ygtQw2xCmSn5eHUdYFTN4mGKmN
         k2Rg5DIVXnZv9Y7QmF5ujJiw6bTqTAWHV+e7/RqmiSMMcPmrT8rDk7kqg4cXPQH8ReQ5
         NXC25r6/9SYdjHn2Hch2q6VOf7TWyWwiSqXpjlX1wMbnk/lwECKI0NHCpc/r0Rjiiwos
         +ZOJMDcNeYJnHjOZpjrx47B9cJt67sHF4q4Muv6GaYM0NxkN/NbJhaf1APo79C188xfo
         mZf/HuiIvJ/tVsQgmbk4k/pA33Oi9QjkGOSEIDqP916o0XRyLwcRweCQ4doA/yqS52ki
         dWlA==
X-Gm-Message-State: AOJu0YzQSZPQZkW1dNjqdubVCOjRAAsv4YR0yQia7RVxK3vcUXyDsDbo
	I3yf1gsvfN8ELYxPAATjpMX0mdPyZnKMACfCmshTsn+3bVlWaUjQdARA+RknyA==
X-Google-Smtp-Source: AGHT+IFhMt8DXtazFgVZd/4MjyU0qWHW0Ln8qk4yZbgM72DpJVggRE7M2YW+oFuMogX6QJsGiBk0wQ==
X-Received: by 2002:a0c:ee8a:0:b0:690:e65d:4b26 with SMTP id u10-20020a0cee8a000000b00690e65d4b26mr109507qvr.31.1710342397898;
        Wed, 13 Mar 2024 08:06:37 -0700 (PDT)
From: Ross Lagerwall 
To: grub-devel@gnu.org
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Daniel Kiper ,
	Ross Lagerwall 
Subject: [PATCH 0/7] GRUB: Supporting Secure Boot of xen.gz
Date: Wed, 13 Mar 2024 15:07:41 +0000
Message-ID: <20240313150748.791236-1-ross.lagerwall@citrix.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

This patch series implements support for loading and verifying a signed
xen.gz binary. This would allow the same xen.gz binary to be used for
BIOS boot, UEFI boot, and UEFI boot with Secure Boot verification.
There is an accompanying Xen patch series.

The first two patches update the multiboot2 specification with the
necessary changes.

Patches 3 through 5 implement the spec changes.
Patches 6 and 7 are a couple of small changes to allow the Secure Boot
verification to happen.

Ross

Diff stat for 0001 and 0002 (to be applied to  the "multiboot2" branch)
Ross Lagerwall (2):
  multiboot2: Add load type header and support for the PE binary type
  multiboot2: Allow 64-bit entry tags

 doc/multiboot.texi | 71 ++++++++++++++++++++++++++++++++++------------
 doc/multiboot2.h   | 19 ++++++++++++-
 2 files changed, 71 insertions(+), 19 deletions(-)

Diff stat for 0003 to 0007 (to be applied to the "master" branch)
Ross Lagerwall (5):
  multiboot2: Add support for the load type header tag
  multiboot2: Add PE load support
  multiboot2: Add support for 64-bit entry addresses
  efi: Allow loading multiboot modules without verification
  verifiers: Verify after decompression

 grub-core/Makefile.core.def       |   1 +
 grub-core/kern/efi/sb.c           |   1 +
 grub-core/loader/multiboot_mbi2.c |  66 ++-
 grub-core/loader/multiboot_pe.c   | 694 ++++++++++++++++++++++++++++++
 include/grub/efi/pe32.h           |  64 +++
 include/grub/file.h               |   2 +-
 include/grub/multiboot2.h         |   4 +
 include/multiboot2.h              |  19 +-
 8 files changed, 844 insertions(+), 7 deletions(-)
 create mode 100644 grub-core/loader/multiboot_pe.c

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Wed Mar 13 15:06:44 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 15:06:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692517.1079738 (Exim 4.92)
	(envelope-from )
	id 1rkQBo-0007T7-20; Wed, 13 Mar 2024 15:06:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692517.1079738; Wed, 13 Mar 2024 15:06:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkQBn-0007T0-Vb; Wed, 13 Mar 2024 15:06:43 +0000
Received: by outflank-mailman (input) for mailman id 692517;
 Wed, 13 Mar 2024 15:06:42 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkQBm-0007E2-OD
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 15:06:42 +0000
Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com
 [2607:f8b0:4864:20::734])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4bc200d4-e14b-11ee-a1ee-f123f15fe8a2;
 Wed, 13 Mar 2024 16:06:41 +0100 (CET)
Received: by mail-qk1-x734.google.com with SMTP id
 af79cd13be357-789cd0c402dso28402885a.2
 for ; Wed, 13 Mar 2024 08:06:41 -0700 (PDT)
Received: from rossla-lxenia.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 p10-20020a0ccb8a000000b0068fba49ae81sm4786811qvk.57.2024.03.13.08.06.38
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 13 Mar 2024 08:06:38 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4bc200d4-e14b-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710342400; x=1710947200; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=KAyEylEkZ+K2w5SdFVwnvdxOdsHKUOMCQVTI6rsesLI=;
        b=A3nMThb6X9zfnpKvr/5hGP8Z5RPtr8PlieTMZ4RqzgDUxeza9L/uzxZJmp5hagIcfa
         Ufl1YULVEAIkziSzAdh/OAf2xs4de5YubDI7z5B64VL4Ws/jm36+TJ8lKqjevYdLNLS9
         oKnpwhedMo7fwLsRiQ0vdUc3U/i0HEjFDjNFs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710342400; x=1710947200;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=KAyEylEkZ+K2w5SdFVwnvdxOdsHKUOMCQVTI6rsesLI=;
        b=vQLnsqTgt/PSiWX4ATZTn3neD+QhgoQyxY6QuKhSCLKX7Bc0pAGF2SZzxnCc0cMnIG
         wk6yL0Gk3osJpZJAd4+wI+XVvNehNBF4woxL5zhAZOAJXqXUhk16xewLRYpcvHqRHLbq
         5X+/6Zxy3gzjxbzHl8V4VYpnfR10gPHYZGS7AQWWvmKJiNjAlDktp7HTDiuXFS47ptoZ
         DKpCTp3L1hQ4W8DXfllBpOjDl3YpSYIYBoIwyAe++BMCPZDgyMOBCmeXlsUxrKQDJPrL
         SxDKVLtVUkLoz9HlMR2uHZHWjse35VWCPD05Ji58cdZRD9NYbsjlsMHJXly/UtcKyfX7
         0a9A==
X-Gm-Message-State: AOJu0YzBOWgIXaBWrEGMCxYYZ8Y1VySfrWTchVdxxlb/tj66OKmBEnJS
	dIUhpxR27oADd6SSfSivEcBRIJ3sMp36gsAEWiRLtSfg4hI0ckhGt0Wf8ebBN8xn7tIX71cOJNU
	OwTyt
X-Google-Smtp-Source: AGHT+IHAOg2qe/MwH4SNZCYldAKrSK+zeLn7ifIh3S+CftY7/WCiBtrBu5n7dA3H67+lyXstuf2NLA==
X-Received: by 2002:a0c:d687:0:b0:691:1cde:e19f with SMTP id k7-20020a0cd687000000b006911cdee19fmr89340qvi.17.1710342399919;
        Wed, 13 Mar 2024 08:06:39 -0700 (PDT)
From: Ross Lagerwall 
To: grub-devel@gnu.org
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Daniel Kiper ,
	Ross Lagerwall 
Subject: [PATCH 1/7] multiboot2: Add load type header and support for the PE binary type
Date: Wed, 13 Mar 2024 15:07:42 +0000
Message-ID: <20240313150748.791236-2-ross.lagerwall@citrix.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20240313150748.791236-1-ross.lagerwall@citrix.com>
References: <20240313150748.791236-1-ross.lagerwall@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Currently, multiboot2-compatible bootloaders can load ELF binaries and
a.out binaries. The presence of the address header tag determines
how the bootloader tries to interpret the binary (a.out if the address
tag is present else ELF).

Add a new load type header tag that explicitly states the type of the
binary. Bootloaders should use the binary type specified in the load
type tag. If the load type tag is not present, the bootloader should
fall back to the previous heuristics.

In addition to the existing address and ELF load types, specify a new
optional PE binary load type. This new type is a useful addition since
PE binaries can be signed and verified (i.e. used with Secure Boot).

Signed-off-by: Ross Lagerwall 
---
 doc/multiboot.texi | 39 ++++++++++++++++++++++++++++++++++-----
 doc/multiboot2.h   | 13 +++++++++++++
 2 files changed, 47 insertions(+), 5 deletions(-)

diff --git a/doc/multiboot.texi b/doc/multiboot.texi
index df8a0d056e76..d12719c744eb 100644
--- a/doc/multiboot.texi
+++ b/doc/multiboot.texi
@@ -511,11 +511,12 @@ assumes that no bss segment is present.
 
 Note: This information does not need to be provided if the kernel image
 is in @sc{elf} format, but it must be provided if the image is in a.out
-format or in some other format. When the address tag is present it must
-be used in order to load the image, regardless of whether an @sc{elf}
-header is also present. Compliant boot loaders must be able to load
-images that are either in @sc{elf} format or contain the address tag
-embedded in the Multiboot2 header.
+format or in some other format. If the load type tag is not specified
+and the address tag is present it must be used in order to load the
+image, regardless of whether an @sc{elf} header is also present.
+Compliant boot loaders must be able to load images that are either in
+@sc{elf} format or contain the address tag embedded in the Multiboot2
+header.
 
 @subsection The entry address tag of Multiboot2 header
 
@@ -732,6 +733,34 @@ and @samp{2} means load image at highest possible address but not
 higher than max_addr.
 @end table
 
+@node Load type tag
+@subsection Load type tag
+
+@example
+@group
+        +-------------------+
+u16     | type = 11         |
+u16     | flags             |
+u32     | size = 12         |
+u32     | load_type         |
+        +-------------------+
+@end group
+@end example
+
+This tag indicates the type of the payload and how the boot loader
+should load it.
+
+The meaning of each field is as follows:
+
+@table @code
+@item load_type
+Recognized load types are @samp{0} for address (i.e. load a.out using
+the address tag), @samp{1} for ELF, and @samp{2} for PE. Compliant
+bootloaders should implement support for a.out and ELF as a minimum.  If
+this tag is not specified, the boot loader should attempt to load the
+payload using the information specified in the address tag if present,
+else it should load the payload as an ELF binary.  @end table
+
 @node Machine state
 @section MIPS machine state
 
diff --git a/doc/multiboot2.h b/doc/multiboot2.h
index b181607075b2..d4cae05706e4 100644
--- a/doc/multiboot2.h
+++ b/doc/multiboot2.h
@@ -75,6 +75,7 @@
 #define MULTIBOOT_HEADER_TAG_ENTRY_ADDRESS_EFI32  8
 #define MULTIBOOT_HEADER_TAG_ENTRY_ADDRESS_EFI64  9
 #define MULTIBOOT_HEADER_TAG_RELOCATABLE  10
+#define MULTIBOOT_HEADER_TAG_LOAD_TYPE  11
 
 #define MULTIBOOT_ARCHITECTURE_I386  0
 #define MULTIBOOT_ARCHITECTURE_MIPS32  4
@@ -179,6 +180,18 @@ struct multiboot_header_tag_relocatable
   multiboot_uint32_t preference;
 };
 
+struct multiboot_header_tag_load_type
+{
+  multiboot_uint16_t type;
+  multiboot_uint16_t flags;
+  multiboot_uint32_t size;
+#define MULTIBOOT_LOAD_TYPE_ADDRESS     0
+#define MULTIBOOT_LOAD_TYPE_ELF         1
+#define MULTIBOOT_LOAD_TYPE_PE          2
+#define MULTIBOOT_LOAD_TYPE_TOTAL       3
+  multiboot_uint32_t load_type;
+};
+
 struct multiboot_color
 {
   multiboot_uint8_t red;
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Wed Mar 13 15:06:45 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 15:06:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692518.1079748 (Exim 4.92)
	(envelope-from )
	id 1rkQBp-0007iF-8H; Wed, 13 Mar 2024 15:06:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692518.1079748; Wed, 13 Mar 2024 15:06:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkQBp-0007i6-5W; Wed, 13 Mar 2024 15:06:45 +0000
Received: by outflank-mailman (input) for mailman id 692518;
 Wed, 13 Mar 2024 15:06:44 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkQBo-0007E2-HQ
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 15:06:44 +0000
Received: from mail-qv1-xf2c.google.com (mail-qv1-xf2c.google.com
 [2607:f8b0:4864:20::f2c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4cbb0028-e14b-11ee-a1ee-f123f15fe8a2;
 Wed, 13 Mar 2024 16:06:42 +0100 (CET)
Received: by mail-qv1-xf2c.google.com with SMTP id
 6a1803df08f44-690ca2d2c5bso24721776d6.2
 for ; Wed, 13 Mar 2024 08:06:42 -0700 (PDT)
Received: from rossla-lxenia.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 p10-20020a0ccb8a000000b0068fba49ae81sm4786811qvk.57.2024.03.13.08.06.40
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 13 Mar 2024 08:06:40 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4cbb0028-e14b-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710342401; x=1710947201; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=vzi7gexZvWQMljijVlDNbWhNKDms1QxVcPrC/wEDf/o=;
        b=gsWUT/FF4FT6Ape+kidsf/9F6+xWleVUxMvN/8JxfiNidnrjfKqKy4ylBmHC0VWI/9
         4JLy/g+Tu0vprr09BW9ZuGDeVSVXsXjxyLVm2sgPnnuQPVWutLpsJ8rvEWg5F9LFJN03
         VxL4nV+NtVEVaqiyqTq79OuwgN35Skb74iDBE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710342401; x=1710947201;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=vzi7gexZvWQMljijVlDNbWhNKDms1QxVcPrC/wEDf/o=;
        b=BdXcQeNxWCtNot8q7RqyCHO3pDZuAjnC5dy/Zj6aQbAfKerPecbQxfabBvjyyL9fcK
         hlHiqEJ3qX5fC+WMq24a4C67xlo8X4nxgjC/s5cuOKgbd3UFVPPXsm2gVoak72robC77
         20DBAi1VHilYvzEg8a9/Fo71aPJHD+piyUZWcBqbjrowLfQ77w8fMt6Mq/VWHuGYrcbT
         Hu0XZBo4F6hYTu+GWYLf84MRgf42C1Xm+h31RlDC/h8RZEKM1TNTJXW2nRSWMVu8AqoZ
         MGE+DNTTQnH4tt8gLYiMEhSdL5jJ5sERn/ELrnCFcladAwf6+ipAr9x08wKsZWM17f3A
         HpJg==
X-Gm-Message-State: AOJu0YynjNJ2udcjijZ8QBENL+eD6hqDaj3hqXaDNr5Yx6FDQH7jwX+x
	iRTrI+GM0xoCtbPGA3muzgBA8afM2Qw4iep5Lhp8AluwW7Zzm7iblRw+u1mbCeNraXuwUIViCZJ
	XlOLN
X-Google-Smtp-Source: AGHT+IH9fmrW3gMuuJAfjFbZjjqE4vpclj5uYDw95WuKdz/9FlbDNxdI+xMFfZNCxETx42Aw/ybjQA==
X-Received: by 2002:a05:6214:9c7:b0:690:c863:f06d with SMTP id dp7-20020a05621409c700b00690c863f06dmr68485qvb.40.1710342401639;
        Wed, 13 Mar 2024 08:06:41 -0700 (PDT)
From: Ross Lagerwall 
To: grub-devel@gnu.org
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Daniel Kiper ,
	Ross Lagerwall 
Subject: [PATCH 2/7] multiboot2: Allow 64-bit entry tags
Date: Wed, 13 Mar 2024 15:07:43 +0000
Message-ID: <20240313150748.791236-3-ross.lagerwall@citrix.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20240313150748.791236-1-ross.lagerwall@citrix.com>
References: <20240313150748.791236-1-ross.lagerwall@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Binaries may be built with entry points above 4G. While bootloaders may
relocate them below 4G, it should be possible for the binary to specify
those entry points. Therefore, extend the multiboot2 protocol such that
64 bit addresses are allowed for entry points. The extension is done in
a backwards-compatible way.

Signed-off-by: Ross Lagerwall 
---
 doc/multiboot.texi | 32 +++++++++++++++++++-------------
 doc/multiboot2.h   |  6 +++++-
 2 files changed, 24 insertions(+), 14 deletions(-)

diff --git a/doc/multiboot.texi b/doc/multiboot.texi
index d12719c744eb..049afab53c1f 100644
--- a/doc/multiboot.texi
+++ b/doc/multiboot.texi
@@ -522,12 +522,12 @@ header.
 
 @example
 @group
-        +-------------------+
-u16     | type = 3          |
-u16     | flags             |
-u32     | size              |
-u32     | entry_addr        |
-        +-------------------+
+          +-------------------+
+u16       | type = 3          |
+u16       | flags             |
+u32       | size              |
+u32 / u64 | entry_addr        |
+          +-------------------+
 @end group
 @end example
 
@@ -538,7 +538,10 @@ The meaning of each is as follows:
 
 @item entry_addr
 The physical address to which the boot loader should jump in order to
-start running the operating system.
+start running the operating system. @samp{entry_addr} may be specified
+either as a @samp{u32} or @samp{u64}. The bootloader should use the
+header size to determine the size of @samp{entry_addr}.
+
 @end table
 
 @subsection EFI i386 entry address tag of Multiboot2 header
@@ -573,12 +576,12 @@ tag of Multiboot2 header are ignored.
 
 @example
 @group
-        +-------------------+
-u16     | type = 9          |
-u16     | flags             |
-u32     | size              |
-u32     | entry_addr        |
-        +-------------------+
+          +-------------------+
+u16       | type = 9          |
+u16       | flags             |
+u32       | size              |
+u32 / u64 | entry_addr        |
+          +-------------------+
 @end group
 @end example
 
@@ -594,6 +597,9 @@ is as follows:
 @item entry_addr
 The physical address to which the boot loader should jump in order to
 start running EFI amd64 compatible operating system code.
+@samp{entry_addr} may be specified either as a @samp{u32} or @samp{u64}.
+The bootloader should use the header size to determine the size of
+@samp{entry_addr}.
 @end table
 
 This tag is taken into account only on EFI amd64 platforms
diff --git a/doc/multiboot2.h b/doc/multiboot2.h
index d4cae05706e4..a994a7b28b02 100644
--- a/doc/multiboot2.h
+++ b/doc/multiboot2.h
@@ -141,7 +141,11 @@ struct multiboot_header_tag_entry_address
   multiboot_uint16_t type;
   multiboot_uint16_t flags;
   multiboot_uint32_t size;
-  multiboot_uint32_t entry_addr;
+  union
+  {
+    multiboot_uint32_t entry_addr32;
+    multiboot_uint64_t entry_addr64;
+  };
 };
 
 struct multiboot_header_tag_console_flags
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Wed Mar 13 15:06:46 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 15:06:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692519.1079759 (Exim 4.92)
	(envelope-from )
	id 1rkQBq-0007xv-GW; Wed, 13 Mar 2024 15:06:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692519.1079759; Wed, 13 Mar 2024 15:06:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkQBq-0007xk-Cr; Wed, 13 Mar 2024 15:06:46 +0000
Received: by outflank-mailman (input) for mailman id 692519;
 Wed, 13 Mar 2024 15:06:45 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkQBp-0007DJ-6s
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 15:06:45 +0000
Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com
 [2607:f8b0:4864:20::730])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4dbf5a7f-e14b-11ee-afdd-a90da7624cb6;
 Wed, 13 Mar 2024 16:06:44 +0100 (CET)
Received: by mail-qk1-x730.google.com with SMTP id
 af79cd13be357-7882b1e87c4so265648985a.1
 for ; Wed, 13 Mar 2024 08:06:44 -0700 (PDT)
Received: from rossla-lxenia.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 p10-20020a0ccb8a000000b0068fba49ae81sm4786811qvk.57.2024.03.13.08.06.41
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 13 Mar 2024 08:06:42 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4dbf5a7f-e14b-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710342403; x=1710947203; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=aZp28TJaho7bmYkQTjxVyJZGgKr3RuW+VThi/ld76Pc=;
        b=UBhZVWkdwAY5EIGqr5C+0vGeM9DCHRE98Gok0s57e2NnoFu8fPnyVav7c3zmuFQBs4
         TcAxlMdyYIznoAr+se7PnRoFaTomy3vq+LAW0ZNdYhKqS7my9YiRCsEtnYCXPCoqom6I
         Jh2J2U4j/bqfg25Te+n/hgGHIidhYgVwkhZ3g=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710342403; x=1710947203;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=aZp28TJaho7bmYkQTjxVyJZGgKr3RuW+VThi/ld76Pc=;
        b=AhRLAAqGcIJ1wjlg3L+kPabU+FICX+5EhF60EtXcLGhNDVgf3TuJVzTortbKxdKVjX
         8H055d44/K7WA40a4AUY1ynYrOlYHZ7TrHkC7wubp+MfTGAOYQ5kiVqF/aSqjyNamKML
         gVfGJc3PtJ4pF6cdYzK2iKuRi7yzYi/mbwNF3HfL5FyZkwi0M0Say0EmG1JeFhh5hLgY
         3E2XidAhdsISZ3agBKF3lOaIe1M3HkuxEtyhVYpZAL/qDWeDAnMFdeJM5bhuSVaDpZVb
         gDz0ciyYqp/I3YYFNk9EYHhnKa7//3TfgsR4E0SaHXuYnDIo1REGO4+yj0TdoGJ9iWGX
         RvIQ==
X-Gm-Message-State: AOJu0Yzu5y/gKza3/dixrSm90RHQaE4DFMkCiVGSYHSa8OMf6O8sFOLg
	T2+jLg06HgteOEQ8fjXvAcmcvZh20SAyDjU9rwunGgVtHqYFfI/4i4eFEcM9ag==
X-Google-Smtp-Source: AGHT+IFC1t3oGaIaWTD7qAvoHPvFddvbbLTuvdcaC4WasfMYFmVyprTkfSeTUbh1nwaatINz4YBo+Q==
X-Received: by 2002:a0c:9c8c:0:b0:690:e2b5:9219 with SMTP id i12-20020a0c9c8c000000b00690e2b59219mr119040qvf.22.1710342403310;
        Wed, 13 Mar 2024 08:06:43 -0700 (PDT)
From: Ross Lagerwall 
To: grub-devel@gnu.org
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Daniel Kiper ,
	Ross Lagerwall 
Subject: [PATCH 3/7] multiboot2: Add support for the load type header tag
Date: Wed, 13 Mar 2024 15:07:44 +0000
Message-ID: <20240313150748.791236-4-ross.lagerwall@citrix.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20240313150748.791236-1-ross.lagerwall@citrix.com>
References: <20240313150748.791236-1-ross.lagerwall@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

The binary may expose its type using the load type header tag. Implement
it according to the specification.

Signed-off-by: Ross Lagerwall 
---
 grub-core/loader/multiboot_mbi2.c | 45 ++++++++++++++++++++++++++++---
 include/grub/multiboot2.h         |  1 +
 include/multiboot2.h              | 13 +++++++++
 3 files changed, 56 insertions(+), 3 deletions(-)

diff --git a/grub-core/loader/multiboot_mbi2.c b/grub-core/loader/multiboot_mbi2.c
index 00a48413c013..6ef4f265070a 100644
--- a/grub-core/loader/multiboot_mbi2.c
+++ b/grub-core/loader/multiboot_mbi2.c
@@ -119,10 +119,12 @@ grub_multiboot2_load (grub_file_t file, const char *filename)
   grub_uint32_t console_required = 0;
   struct multiboot_header_tag_framebuffer *fbtag = NULL;
   int accepted_consoles = GRUB_MULTIBOOT2_CONSOLE_EGA_TEXT;
+  struct multiboot_header_tag_load_type *load_type_tag;
   mbi_load_data_t mld;
 
   mld.mbi_ver = 2;
   mld.relocatable = 0;
+  mld.load_type = MULTIBOOT_LOAD_TYPE_TOTAL;
 
   mld.buffer = grub_malloc (MULTIBOOT_SEARCH);
   if (!mld.buffer)
@@ -258,6 +260,17 @@ grub_multiboot2_load (grub_file_t file, const char *filename)
 #endif
 	break;
 
+      case MULTIBOOT_HEADER_TAG_LOAD_TYPE:
+        load_type_tag = (struct multiboot_header_tag_load_type *) tag;
+        mld.load_type = load_type_tag->load_type;
+        if (mld.load_type >= MULTIBOOT_LOAD_TYPE_TOTAL)
+          {
+              grub_free (mld.buffer);
+              return grub_error (GRUB_ERR_UNKNOWN_OS,
+                                 "unsupported load type: %u", load_type_tag->load_type);
+          }
+        break;
+
       default:
 	if (! (tag->flags & MULTIBOOT_HEADER_TAG_OPTIONAL))
 	  {
@@ -268,14 +281,32 @@ grub_multiboot2_load (grub_file_t file, const char *filename)
 	break;
       }
 
-  if (addr_tag && !entry_specified && !(keep_bs && efi_entry_specified))
+  if (mld.load_type == MULTIBOOT_LOAD_TYPE_ADDRESS && !addr_tag)
+    {
+      grub_free (mld.buffer);
+      return grub_error (GRUB_ERR_UNKNOWN_OS,
+                         "load type address without address tag");
+    }
+  if (mld.load_type < MULTIBOOT_LOAD_TYPE_TOTAL &&
+      mld.load_type != MULTIBOOT_LOAD_TYPE_ADDRESS && addr_tag)
+    {
+      grub_free (mld.buffer);
+      return grub_error (GRUB_ERR_UNKNOWN_OS,
+                         "address tag specified but load type doesn't match");
+    }
+  if (mld.load_type == MULTIBOOT_LOAD_TYPE_TOTAL)
+    mld.load_type = addr_tag ? MULTIBOOT_LOAD_TYPE_ADDRESS : MULTIBOOT_LOAD_TYPE_ELF;
+
+  if (mld.load_type == MULTIBOOT_LOAD_TYPE_ADDRESS && !entry_specified &&
+      !(keep_bs && efi_entry_specified))
     {
       grub_free (mld.buffer);
       return grub_error (GRUB_ERR_UNKNOWN_OS,
 			 "load address tag without entry address tag");
     }
 
-  if (addr_tag)
+  switch (mld.load_type) {
+  case MULTIBOOT_LOAD_TYPE_ADDRESS:
     {
       grub_uint64_t load_addr = (addr_tag->load_addr + 1)
 	? addr_tag->load_addr : (addr_tag->header_addr
@@ -343,8 +374,9 @@ grub_multiboot2_load (grub_file_t file, const char *filename)
       if (addr_tag->bss_end_addr)
 	grub_memset ((grub_uint8_t *) source + load_size, 0,
 		     addr_tag->bss_end_addr - load_addr - load_size);
+      break;
     }
-  else
+  case MULTIBOOT_LOAD_TYPE_ELF:
     {
       mld.file = file;
       mld.filename = filename;
@@ -355,7 +387,14 @@ grub_multiboot2_load (grub_file_t file, const char *filename)
 	  grub_free (mld.buffer);
 	  return err;
 	}
+      break;
     }
+  case MULTIBOOT_LOAD_TYPE_PE:
+      grub_fatal ("Unsupported load type: %u\n", mld.load_type);
+  default:
+    /* should be impossible */
+    grub_fatal ("Unknown load type: %u\n", mld.load_type);
+  }
 
   load_base_addr = mld.load_base_addr;
 
diff --git a/include/grub/multiboot2.h b/include/grub/multiboot2.h
index b90aa6989674..1f6d4fc9e336 100644
--- a/include/grub/multiboot2.h
+++ b/include/grub/multiboot2.h
@@ -89,6 +89,7 @@ struct mbi_load_data
   grub_uint32_t link_base_addr;
   grub_uint32_t load_base_addr;
   int avoid_efi_boot_services;
+  grub_uint32_t load_type;
 };
 typedef struct mbi_load_data mbi_load_data_t;
 
diff --git a/include/multiboot2.h b/include/multiboot2.h
index a039aa0439aa..f4377bf7b394 100644
--- a/include/multiboot2.h
+++ b/include/multiboot2.h
@@ -74,6 +74,7 @@
 #define MULTIBOOT_HEADER_TAG_EFI_BS  7
 #define MULTIBOOT_HEADER_TAG_ENTRY_ADDRESS_EFI64  9
 #define MULTIBOOT_HEADER_TAG_RELOCATABLE  10
+#define MULTIBOOT_HEADER_TAG_LOAD_TYPE  11
 
 #define MULTIBOOT2_ARCHITECTURE_I386  0
 #define MULTIBOOT2_ARCHITECTURE_MIPS32  4
@@ -178,6 +179,18 @@ struct multiboot_header_tag_relocatable
   multiboot_uint32_t preference;
 };
 
+struct multiboot_header_tag_load_type
+{
+  multiboot_uint16_t type;
+  multiboot_uint16_t flags;
+  multiboot_uint32_t size;
+#define MULTIBOOT_LOAD_TYPE_ADDRESS     0
+#define MULTIBOOT_LOAD_TYPE_ELF         1
+#define MULTIBOOT_LOAD_TYPE_PE          2
+#define MULTIBOOT_LOAD_TYPE_TOTAL       3
+  multiboot_uint32_t load_type;
+};
+
 struct multiboot_color
 {
   multiboot_uint8_t red;
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Wed Mar 13 15:06:50 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 15:06:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692520.1079768 (Exim 4.92)
	(envelope-from )
	id 1rkQBu-0008IG-OH; Wed, 13 Mar 2024 15:06:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692520.1079768; Wed, 13 Mar 2024 15:06:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkQBu-0008I9-LM; Wed, 13 Mar 2024 15:06:50 +0000
Received: by outflank-mailman (input) for mailman id 692520;
 Wed, 13 Mar 2024 15:06:48 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkQBs-0007DJ-Nd
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 15:06:48 +0000
Received: from mail-qv1-xf2a.google.com (mail-qv1-xf2a.google.com
 [2607:f8b0:4864:20::f2a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4fe8adc5-e14b-11ee-afdd-a90da7624cb6;
 Wed, 13 Mar 2024 16:06:48 +0100 (CET)
Received: by mail-qv1-xf2a.google.com with SMTP id
 6a1803df08f44-68f571be9ddso53971826d6.0
 for ; Wed, 13 Mar 2024 08:06:48 -0700 (PDT)
Received: from rossla-lxenia.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 p10-20020a0ccb8a000000b0068fba49ae81sm4786811qvk.57.2024.03.13.08.06.45
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 13 Mar 2024 08:06:46 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4fe8adc5-e14b-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710342407; x=1710947207; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=kpYcDsI+M6briD4qjQYG+D2zD6DLXgwh1H3IqVNt/RM=;
        b=BigxsrG+Ozj/kCSgpXM618RVYXFnWY37FCTmX1rXMFaDaS9Gm6AcZelBo9XkcLeAoa
         OVo3ypZCETcE72FJj1Js7GIGEOzDeRxREu17g1ETpOAu/nfKJqc97cXRmIozwglJJpAL
         dgKvMoZGJuaHZ07hgn0Swjbk6X3yV47bZGAhU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710342407; x=1710947207;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=kpYcDsI+M6briD4qjQYG+D2zD6DLXgwh1H3IqVNt/RM=;
        b=VIlr6mgxi1bC8ieDt658BXXQc4AmO6CEtof3yUl8ADexNKdgW1pq49aSznyfz18xa7
         i6rtsh0lRqvTstxjd906XLLSR0BvoYgTA5q7rQW7WGW1yuXj13ncavMZ50S0b1JQGcbi
         KUrSTkzmQDbF/j2Ypwb3Ddpg6CUtXfwBAJ+BT0IEEpMH5ZNeGwSQSDLvVMYbvK4WVvoc
         LX8+1nwS1MS8kU8Ep8nfyCyOrsDc2ZdyJB9CGHBOcTQy7Qu+lvKiDxZB4R5XTsujKv7f
         dycSbAiogRMGfG8AqcRGdUHfg2X3/g/lRtcce1HjcQKyYvbOwRs9GkWKFg1ac0QHpyji
         bg+Q==
X-Gm-Message-State: AOJu0Ywp5fWlXTtcoliZse0YW2z3vf4bYBW1Sq+YiuqUku82cL/daqHb
	go83p/b1YSjZQx9lo9Sf2cmE0XdbopLqciGXlb8AcS5yTZhQukmNDLrvMjSVaw==
X-Google-Smtp-Source: AGHT+IFKcbExg32xHCfDC0TqWfQFSuyDOMhILY/iB+QL677shqOJeZILRaYMT4dW0UohQCma6B2uYQ==
X-Received: by 2002:ad4:4bad:0:b0:690:cb91:80d9 with SMTP id i13-20020ad44bad000000b00690cb9180d9mr90900qvw.48.1710342407050;
        Wed, 13 Mar 2024 08:06:47 -0700 (PDT)
From: Ross Lagerwall 
To: grub-devel@gnu.org
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Daniel Kiper ,
	Ross Lagerwall 
Subject: [PATCH 5/7] multiboot2: Add support for 64-bit entry addresses
Date: Wed, 13 Mar 2024 15:07:46 +0000
Message-ID: <20240313150748.791236-6-ross.lagerwall@citrix.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20240313150748.791236-1-ross.lagerwall@citrix.com>
References: <20240313150748.791236-1-ross.lagerwall@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Add support for entry addresses that may be either 32 bits or 64 bits in
size. This may be necessary if the binary is built with an entry address
above 4G.

Signed-off-by: Ross Lagerwall 
---
 grub-core/loader/multiboot_mbi2.c | 10 ++++++++--
 include/multiboot2.h              |  6 +++++-
 2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/grub-core/loader/multiboot_mbi2.c b/grub-core/loader/multiboot_mbi2.c
index 3ec96e2f29b9..c268aa614284 100644
--- a/grub-core/loader/multiboot_mbi2.c
+++ b/grub-core/loader/multiboot_mbi2.c
@@ -205,13 +205,19 @@ grub_multiboot2_load (grub_file_t file, const char *filename)
 
       case MULTIBOOT_HEADER_TAG_ENTRY_ADDRESS:
 	entry_specified = 1;
-	entry = ((struct multiboot_header_tag_entry_address *) tag)->entry_addr;
+	if ((tag->size - sizeof(struct multiboot_header_tag)) == sizeof(multiboot_uint64_t))
+	  entry = ((struct multiboot_header_tag_entry_address *) tag)->entry_addr64;
+	else
+	  entry = ((struct multiboot_header_tag_entry_address *) tag)->entry_addr32;
 	break;
 
       case MULTIBOOT_HEADER_TAG_ENTRY_ADDRESS_EFI64:
 #if defined (GRUB_MACHINE_EFI) && defined (__x86_64__)
 	efi_entry_specified = 1;
-	efi_entry = ((struct multiboot_header_tag_entry_address *) tag)->entry_addr;
+	if ((tag->size - sizeof(struct multiboot_header_tag)) == sizeof(multiboot_uint64_t))
+	  efi_entry = ((struct multiboot_header_tag_entry_address *) tag)->entry_addr64;
+	else
+	  efi_entry = ((struct multiboot_header_tag_entry_address *) tag)->entry_addr32;
 #endif
 	break;
 
diff --git a/include/multiboot2.h b/include/multiboot2.h
index f4377bf7b394..e4798bfef937 100644
--- a/include/multiboot2.h
+++ b/include/multiboot2.h
@@ -140,7 +140,11 @@ struct multiboot_header_tag_entry_address
   multiboot_uint16_t type;
   multiboot_uint16_t flags;
   multiboot_uint32_t size;
-  multiboot_uint32_t entry_addr;
+  union
+  {
+    multiboot_uint32_t entry_addr32;
+    multiboot_uint64_t entry_addr64;
+  };
 };
 
 struct multiboot_header_tag_console_flags
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Wed Mar 13 15:06:51 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 15:06:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692521.1079774 (Exim 4.92)
	(envelope-from )
	id 1rkQBv-0008Lg-4J; Wed, 13 Mar 2024 15:06:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692521.1079774; Wed, 13 Mar 2024 15:06:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkQBu-0008Kj-Uw; Wed, 13 Mar 2024 15:06:50 +0000
Received: by outflank-mailman (input) for mailman id 692521;
 Wed, 13 Mar 2024 15:06:49 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkQBt-0007E2-3u
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 15:06:49 +0000
Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com
 [2607:f8b0:4864:20::732])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4efe53db-e14b-11ee-a1ee-f123f15fe8a2;
 Wed, 13 Mar 2024 16:06:46 +0100 (CET)
Received: by mail-qk1-x732.google.com with SMTP id
 af79cd13be357-7885bb1b760so52683685a.0
 for ; Wed, 13 Mar 2024 08:06:46 -0700 (PDT)
Received: from rossla-lxenia.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 p10-20020a0ccb8a000000b0068fba49ae81sm4786811qvk.57.2024.03.13.08.06.43
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 13 Mar 2024 08:06:44 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4efe53db-e14b-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710342405; x=1710947205; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=fnCQ6iGEQlGDwp0KgZ7SdE2CyEyUyRyRTqUnAJN4R94=;
        b=p0Q3IN0r0VAcp9VMU56fx808dfWqDJzY2o7qhjk57+TKAKazXNwsTOp/g7IuzXe8LR
         VED4feMAUpfywv1OpqVS61kT/3sTnhGfbzkJjBx9av30U3oFWcDBg1lp55VMucuh6lLN
         njmVXmX3T3NDWZVJ1cDpO2YhdcDN+mvqFMpEM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710342405; x=1710947205;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=fnCQ6iGEQlGDwp0KgZ7SdE2CyEyUyRyRTqUnAJN4R94=;
        b=BY5Mrus7BsEhKzDahT6hgAsg335Ae5tmWR1aJwp84MBXnx+znTDqxy7m0H8dis9vKZ
         /9HIbvqFgs/X7FkBeo2FnU8yUG6x1NdBSaNeWFowzaChU4i1JJm5FJ08AdDkpGPyKYdx
         bfUsXHNpoUvnqdoCWFhebbHkOSYYdv99UonyQaUb2YOHLFCQk609LHCBrgV439L8kiiO
         iqIoolUeTNPpZucrxd5yWKo7m7lzSsrBUbU8Ra/SeOK8vOPSnPnGKeucPRRR/YI+BmUM
         wn4eOzUag6CxCJNy8FR801WkwWqRrUMI6KGCNAREe6QiW7DMl+BsZoFo/RNPLIkYHWdo
         zR6Q==
X-Gm-Message-State: AOJu0Yw21eT30ccE7MG2N2L2q0Ye9IhQ4qQ7JjefH5HOH4T9m54RAMCx
	lYs9L6N7YWHopH+Q4s63isXi6AtYkw7UKU9Xw4cBMTd3MSC8LO1cf8+xXP0Swgy6VBYWZ4KORNt
	6rQ==
X-Google-Smtp-Source: AGHT+IFtTSlpAbXFsRrwJaGE4XLyNfpqFwXS0lTUp2QVeXs6Lh+rmtvs+mnKLVyFDIP0W8U3Vm+FmQ==
X-Received: by 2002:a0c:fa87:0:b0:690:d102:a6a8 with SMTP id o7-20020a0cfa87000000b00690d102a6a8mr64516qvn.42.1710342405258;
        Wed, 13 Mar 2024 08:06:45 -0700 (PDT)
From: Ross Lagerwall 
To: grub-devel@gnu.org
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Daniel Kiper ,
	Ross Lagerwall 
Subject: [PATCH 4/7] multiboot2: Add PE load support
Date: Wed, 13 Mar 2024 15:07:45 +0000
Message-ID: <20240313150748.791236-5-ross.lagerwall@citrix.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20240313150748.791236-1-ross.lagerwall@citrix.com>
References: <20240313150748.791236-1-ross.lagerwall@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Add the ability to load multiboot binaries in PE format. This allows the
binaries to be signed and verified.

Signed-off-by: Ross Lagerwall 
---
 grub-core/Makefile.core.def       |   1 +
 grub-core/loader/multiboot_mbi2.c |  15 +-
 grub-core/loader/multiboot_pe.c   | 694 ++++++++++++++++++++++++++++++
 include/grub/efi/pe32.h           |  64 +++
 include/grub/multiboot2.h         |   3 +
 5 files changed, 775 insertions(+), 2 deletions(-)
 create mode 100644 grub-core/loader/multiboot_pe.c

diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
index 1571421d7e84..34697ba58171 100644
--- a/grub-core/Makefile.core.def
+++ b/grub-core/Makefile.core.def
@@ -1815,6 +1815,7 @@ module = {
 
   common = loader/multiboot.c;
   common = loader/multiboot_mbi2.c;
+  common = loader/multiboot_pe.c;
   enable = x86;
   enable = i386_xen_pvh;
   enable = mips;
diff --git a/grub-core/loader/multiboot_mbi2.c b/grub-core/loader/multiboot_mbi2.c
index 6ef4f265070a..3ec96e2f29b9 100644
--- a/grub-core/loader/multiboot_mbi2.c
+++ b/grub-core/loader/multiboot_mbi2.c
@@ -389,8 +389,19 @@ grub_multiboot2_load (grub_file_t file, const char *filename)
 	}
       break;
     }
-  case MULTIBOOT_LOAD_TYPE_PE:
-      grub_fatal ("Unsupported load type: %u\n", mld.load_type);
+ case MULTIBOOT_LOAD_TYPE_PE:
+    {
+      mld.file = file;
+      mld.filename = filename;
+      mld.avoid_efi_boot_services = keep_bs;
+      err = grub_multiboot2_load_pe (&mld);
+      if (err)
+        {
+          grub_free (mld.buffer);
+          return err;
+        }
+      break;
+    }
   default:
     /* should be impossible */
     grub_fatal ("Unknown load type: %u\n", mld.load_type);
diff --git a/grub-core/loader/multiboot_pe.c b/grub-core/loader/multiboot_pe.c
new file mode 100644
index 000000000000..7f418348ac70
--- /dev/null
+++ b/grub-core/loader/multiboot_pe.c
@@ -0,0 +1,694 @@
+/*
+ * Significant portions of this code are derived from the Fedora GRUB patch
+ * "0007-Add-secureboot-support-on-efi-chainloader.patch" which is in turn
+ * derived from the PE loading code in Shim. The license is reproduced below:
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ *
+ * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the
+ * distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
+ * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
+ * COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
+ * INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
+ * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
+ * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
+ * OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * Copyright Peter Jones 
+ *
+ * Modifications:
+ *
+ * Copyright (c) 2024. Cloud Software Group, Inc.
+ */
+
+#include 
+#include 
+#include 
+
+static int
+image_is_64_bit (grub_pe_header_t *pe_hdr)
+{
+  /* .Magic is the same offset in all cases */
+  return pe_hdr->pe32plus.optional_header.magic == GRUB_PE32_PE64_MAGIC;
+}
+
+static const grub_uint16_t machine_type __attribute__((__unused__)) =
+#if defined(__x86_64__)
+  GRUB_PE32_MACHINE_X86_64;
+#elif defined(__aarch64__)
+  GRUB_PE32_MACHINE_ARM64;
+#elif defined(__arm__)
+  GRUB_PE32_MACHINE_ARMTHUMB_MIXED;
+#elif defined(__i386__) || defined(__i486__) || defined(__i686__)
+  GRUB_PE32_MACHINE_I386;
+#elif defined(__ia64__)
+  GRUB_PE32_MACHINE_IA64;
+#elif defined(__riscv) && (__riscv_xlen == 32)
+  GRUB_PE32_MACHINE_RISCV32;
+#elif defined(__riscv) && (__riscv_xlen == 64)
+  GRUB_PE32_MACHINE_RISCV64;
+#else
+#error this architecture is not supported by grub2
+#endif
+
+static int
+image_is_loadable(grub_pe_header_t *pe_hdr)
+{
+  /*
+   * Check the machine type matches the binary and that we recognize
+   * the magic number.
+   */
+    return (pe_hdr->pe32.coff_header.machine == machine_type ||
+            (pe_hdr->pe32.coff_header.machine == GRUB_PE32_MACHINE_X86_64 &&
+             machine_type == GRUB_PE32_MACHINE_I386)) &&
+           (pe_hdr->pe32plus.optional_header.magic == GRUB_PE32_PE32_MAGIC ||
+            pe_hdr->pe32plus.optional_header.magic == GRUB_PE32_PE64_MAGIC);
+}
+
+/*
+ * Read the binary header and grab appropriate information from it
+ */
+static grub_err_t
+read_header(void *data, unsigned int datasize,
+            pe_coff_loader_image_context_t *context)
+{
+  grub_pe32_msdos_header_t *dos_hdr = data;
+  grub_pe_header_t *pe_hdr = data;
+  unsigned long header_without_data_dir, section_header_offset, opt_header_size;
+  unsigned long file_alignment = 0;
+
+  if (datasize < sizeof (pe_hdr->pe32))
+    {
+      grub_error (GRUB_ERR_OUT_OF_RANGE, "Invalid image");
+      return GRUB_ERR_OUT_OF_RANGE;
+    }
+
+  if (dos_hdr->e_magic == GRUB_PE32_MAGIC)
+    pe_hdr = (grub_pe_header_t *)((char *)data + dos_hdr->e_lfanew);
+
+  if (!image_is_loadable(pe_hdr))
+    {
+      grub_error (GRUB_ERR_NOT_IMPLEMENTED_YET, "Platform does not support this image");
+      return GRUB_ERR_NOT_IMPLEMENTED_YET;
+    }
+
+  if (image_is_64_bit(pe_hdr))
+    {
+      context->number_of_rva_and_sizes = pe_hdr->pe32plus.optional_header.num_data_directories;
+      context->size_of_headers = pe_hdr->pe32plus.optional_header.header_size;
+      context->image_size = pe_hdr->pe32plus.optional_header.image_size;
+      context->section_alignment = pe_hdr->pe32plus.optional_header.section_alignment;
+      file_alignment = pe_hdr->pe32plus.optional_header.file_alignment;
+      opt_header_size = sizeof(struct grub_pe64_optional_header);
+    }
+  else
+    {
+      context->number_of_rva_and_sizes = pe_hdr->pe32.optional_header.num_data_directories;
+      context->size_of_headers = pe_hdr->pe32.optional_header.header_size;
+      context->image_size = (grub_uint64_t)pe_hdr->pe32.optional_header.image_size;
+      context->section_alignment = pe_hdr->pe32.optional_header.section_alignment;
+      file_alignment = pe_hdr->pe32.optional_header.file_alignment;
+      opt_header_size = sizeof(struct grub_pe32_optional_header);
+    }
+
+  if (file_alignment % 2 != 0)
+    {
+      grub_error (GRUB_ERR_OUT_OF_RANGE, "File Alignment is invalid (%ld)", file_alignment);
+      return GRUB_ERR_OUT_OF_RANGE;
+    }
+  if (file_alignment == 0)
+    file_alignment = 0x200;
+  if (context->section_alignment == 0)
+    context->section_alignment = GRUB_EFI_PAGE_SIZE;
+  if (context->section_alignment < file_alignment)
+    context->section_alignment = file_alignment;
+
+  context->number_of_sections = pe_hdr->pe32.coff_header.num_sections;
+
+  if (EFI_IMAGE_NUMBER_OF_DIRECTORY_ENTRIES < context->number_of_rva_and_sizes)
+    {
+      grub_error (GRUB_ERR_OUT_OF_RANGE, "Image header too small");
+      return GRUB_ERR_OUT_OF_RANGE;
+    }
+
+  header_without_data_dir = opt_header_size
+                  - sizeof (struct grub_pe32_data_directory) * EFI_IMAGE_NUMBER_OF_DIRECTORY_ENTRIES;
+  if (((grub_uint32_t)pe_hdr->pe32.coff_header.optional_header_size - header_without_data_dir) !=
+                  context->number_of_rva_and_sizes * sizeof (struct grub_pe32_data_directory))
+    {
+      grub_error (GRUB_ERR_OUT_OF_RANGE, "Image header overflows data directory");
+      return GRUB_ERR_OUT_OF_RANGE;
+    }
+
+  section_header_offset = dos_hdr->e_lfanew
+                          + sizeof (grub_uint32_t)
+                          + sizeof (struct grub_pe32_coff_header)
+                          + pe_hdr->pe32.coff_header.optional_header_size;
+  if (((grub_uint32_t)context->image_size - section_header_offset) / sizeof(struct grub_pe32_section_table)
+                  <= context->number_of_sections)
+    {
+      grub_error (GRUB_ERR_OUT_OF_RANGE, "Image sections overflow image size");
+      return GRUB_ERR_OUT_OF_RANGE;
+    }
+
+  if ((context->size_of_headers - section_header_offset) / sizeof(struct grub_pe32_section_table)
+                  < (grub_uint32_t)context->number_of_sections)
+    {
+      grub_error (GRUB_ERR_OUT_OF_RANGE, "Image sections overflow section headers");
+      return GRUB_ERR_OUT_OF_RANGE;
+    }
+
+  if ((((grub_uint8_t *)pe_hdr - (grub_uint8_t *)data) + sizeof(grub_pe_header_t)) > datasize)
+    {
+      grub_error (GRUB_ERR_OUT_OF_RANGE, "Invalid image");
+      return GRUB_ERR_OUT_OF_RANGE;
+    }
+
+  if (pe_hdr->pe32.signature[0] != 'P' ||
+              pe_hdr->pe32.signature[1] != 'E' ||
+              pe_hdr->pe32.signature[2] != 0x00 ||
+              pe_hdr->pe32.signature[3] != 0x00)
+    {
+      grub_error (GRUB_ERR_NOT_IMPLEMENTED_YET, "Unsupported image type");
+      return GRUB_ERR_NOT_IMPLEMENTED_YET;
+    }
+
+  context->pe_hdr = pe_hdr;
+
+  if (image_is_64_bit(pe_hdr))
+    {
+      context->image_address = pe_hdr->pe32plus.optional_header.image_base;
+      context->entry_point = pe_hdr->pe32plus.optional_header.entry_addr;
+      context->reloc_dir = &pe_hdr->pe32plus.optional_header.base_relocation_table;
+      context->sec_dir = &pe_hdr->pe32plus.optional_header.certificate_table;
+    }
+  else
+    {
+      context->image_address = pe_hdr->pe32.optional_header.image_base;
+      context->entry_point = pe_hdr->pe32.optional_header.entry_addr;
+      context->reloc_dir = &pe_hdr->pe32.optional_header.base_relocation_table;
+      context->sec_dir = &pe_hdr->pe32.optional_header.certificate_table;
+    }
+
+  context->first_section = (struct grub_pe32_section_table *)((char *)pe_hdr +
+          pe_hdr->pe32.coff_header.optional_header_size +
+          sizeof(grub_uint32_t) + sizeof(struct grub_pe32_coff_header));
+
+  if (context->image_size < context->size_of_headers)
+    {
+      grub_error (GRUB_ERR_OUT_OF_RANGE, "Invalid image");
+      return GRUB_ERR_OUT_OF_RANGE;
+    }
+
+  if ((unsigned long)((grub_uint8_t *)context->sec_dir - (grub_uint8_t *)data) >
+      (datasize - sizeof(struct grub_pe32_data_directory)))
+    {
+      grub_error (GRUB_ERR_OUT_OF_RANGE, "Invalid image");
+      return GRUB_ERR_OUT_OF_RANGE;
+    }
+  return GRUB_ERR_NONE;
+}
+
+static grub_phys_addr_t
+image_address (grub_phys_addr_t image, grub_uint64_t sz, grub_uint64_t addr)
+{
+  if (addr > sz)
+    return 0;
+
+  return image + addr;
+}
+
+static grub_err_t
+relocate_coff (pe_coff_loader_image_context_t *context,
+               struct grub_pe32_section_table *section,
+               grub_phys_addr_t phys_addr, grub_uint8_t *virt_addr,
+               mbi_load_data_t *mld)
+{
+  struct grub_pe32_data_directory *reloc_base, *reloc_base_end;
+  grub_uint8_t *reloc_buffer;
+  grub_uint64_t adjust;
+  struct grub_pe32_fixup_block *reloc, *reloc_end;
+  grub_uint8_t *fixup, *fixup_base;
+  grub_uint16_t *fixup_16;
+  grub_uint32_t *fixup_32;
+  grub_uint64_t *fixup_64;
+  int n = 0;
+  grub_err_t ret = GRUB_ERR_NONE;
+
+  if (image_is_64_bit (context->pe_hdr))
+    context->pe_hdr->pe32plus.optional_header.image_base =
+      (grub_uint64_t)(unsigned long)phys_addr;
+  else
+    context->pe_hdr->pe32.optional_header.image_base =
+      (grub_uint32_t)(unsigned long)phys_addr;
+
+  /* Alright, so here's how this works:
+   *
+   * context->reloc_dir gives us two things:
+   * - the VA the table of base relocation blocks are (maybe) to be
+   *   mapped at (reloc_dir->rva)
+   * - the virtual size (reloc_dir->size)
+   *
+   * The .reloc section (section here) gives us some other things:
+   * - the name! kind of. (section->name)
+   * - the virtual size (section->virtual_size), which should be the same
+   *   as RelocDir->Size
+   * - the virtual address (section->virtual_address)
+   * - the file section size (section->raw_data_size), which is
+   *   a multiple of optional_header->file_alignment.  Only useful for image
+   *   validation, not really useful for iteration bounds.
+   * - the file address (section->raw_data_offset)
+   * - a bunch of stuff we don't use that's 0 in our binaries usually
+   * - Flags (section->characteristics)
+   *
+   * and then the thing that's actually at the file address is an array
+   * of struct grub_pe32_fixup_block structs with some values packed behind
+   * them.  The block_size field of this structure includes the
+   * structure itself, and adding it to that structure's address will
+   * yield the next entry in the array.
+   */
+
+  reloc_buffer = grub_malloc (section->virtual_size);
+  if (!reloc_buffer)
+      return grub_errno;
+
+  if (grub_file_seek (mld->file, section->raw_data_offset) == (grub_off_t) -1)
+    {
+      ret = grub_errno;
+      goto out;
+    }
+
+  if (grub_file_read (mld->file, reloc_buffer, section->virtual_size)
+      != (grub_ssize_t) section->virtual_size)
+    {
+      if (!grub_errno)
+        {
+          grub_error (GRUB_ERR_FILE_READ_ERROR, "premature end of file %s",
+                      mld->filename);
+          ret = GRUB_ERR_FILE_READ_ERROR;
+        }
+      else
+          ret = grub_errno;
+      goto out;
+    }
+
+  reloc_base = (struct grub_pe32_data_directory *)reloc_buffer;
+  reloc_base_end = (struct grub_pe32_data_directory *)(reloc_buffer + section->virtual_size);
+
+  grub_dprintf ("multiboot_loader", "relocate_coff(): reloc_base %p reloc_base_end %p\n",
+                reloc_base, reloc_base_end);
+
+  if (!reloc_base && !reloc_base_end)
+    return GRUB_ERR_NONE;
+
+  if (!reloc_base || !reloc_base_end)
+    {
+      grub_error (GRUB_ERR_BAD_ARGUMENT, "Reloc table overflows binary");
+      return GRUB_ERR_BAD_ARGUMENT;
+    }
+
+  adjust = (grub_uint64_t)(grub_efi_uintn_t)phys_addr - context->image_address;
+  if (adjust == 0)
+    return GRUB_ERR_NONE;
+
+  while (reloc_base < reloc_base_end)
+    {
+      grub_uint16_t *entry;
+      reloc = (struct grub_pe32_fixup_block *)((char*)reloc_base);
+
+      if ((reloc_base->size == 0) ||
+          (reloc_base->size > context->reloc_dir->size))
+        {
+          grub_error (GRUB_ERR_BAD_ARGUMENT,
+                      "Reloc %d block size %d is invalid\n", n,
+                      reloc_base->size);
+          ret = GRUB_ERR_BAD_ARGUMENT;
+          goto out;
+        }
+
+      entry = &reloc->entries[0];
+      reloc_end = (struct grub_pe32_fixup_block *)
+        ((char *)reloc_base + reloc_base->size);
+
+      if ((grub_uint8_t *)reloc_end < reloc_buffer ||
+          (grub_uint8_t *)reloc_end > (reloc_buffer + section->virtual_size))
+        {
+          grub_error (GRUB_ERR_BAD_ARGUMENT, "Reloc entry %d overflows binary",
+                      n);
+          return GRUB_ERR_BAD_ARGUMENT;
+        }
+
+      fixup_base = virt_addr + reloc_base->rva;
+      if (!fixup_base)
+        {
+          grub_error (GRUB_ERR_BAD_ARGUMENT, "Reloc %d Invalid fixupbase", n);
+          ret = GRUB_ERR_BAD_ARGUMENT;
+          goto out;
+        }
+
+      while ((void *)entry < (void *)reloc_end)
+        {
+          fixup = fixup_base + (*entry & 0xFFF);
+          switch ((*entry) >> 12)
+            {
+              case GRUB_PE32_REL_BASED_ABSOLUTE:
+                break;
+              case GRUB_PE32_REL_BASED_HIGH:
+                fixup_16 = (grub_uint16_t *)fixup;
+                *fixup_16 = (grub_uint16_t)
+                  (*fixup_16 + ((grub_uint16_t)((grub_uint32_t)adjust >> 16)));
+                break;
+              case GRUB_PE32_REL_BASED_LOW:
+                fixup_16 = (grub_uint16_t *)fixup;
+                *fixup_16 = (grub_uint16_t) (*fixup_16 + (grub_uint16_t)adjust);
+                break;
+              case GRUB_PE32_REL_BASED_HIGHLOW:
+                fixup_32 = (grub_uint32_t *)fixup;
+                *fixup_32 = *fixup_32 + (grub_uint32_t)adjust;
+                break;
+              case GRUB_PE32_REL_BASED_DIR64:
+                fixup_64 = (grub_uint64_t *)fixup;
+                *fixup_64 = *fixup_64 + (grub_uint64_t)adjust;
+                break;
+              default:
+                grub_error (GRUB_ERR_BAD_ARGUMENT,
+                            "Reloc %d unknown relocation type %d",
+                            n, (*entry) >> 12);
+                ret = GRUB_ERR_BAD_ARGUMENT;
+                goto out;
+            }
+          entry += 1;
+        }
+      reloc_base = (struct grub_pe32_data_directory *)reloc_end;
+      n++;
+    }
+
+out:
+  grub_free(reloc_buffer);
+
+  return ret;
+}
+
+grub_err_t
+grub_multiboot2_load_pe (mbi_load_data_t *mld)
+{
+  int i;
+  grub_uint8_t *virt_addr;
+  grub_phys_addr_t phys_addr, reloc_base, reloc_base_end, base, end;
+  struct grub_pe32_section_table *reloc_section = NULL, fake_reloc_section;
+  struct grub_pe32_section_table *section;
+  grub_relocator_chunk_t ch;
+  pe_coff_loader_image_context_t context;
+  grub_err_t ret = GRUB_ERR_NONE;
+  grub_uint32_t section_alignment;
+  int found_entry_point = 0;
+
+  ret = read_header(mld->buffer, MULTIBOOT_SEARCH, &context);
+  if (ret)
+      return ret;
+
+  /*
+   * The spec says, uselessly, of SectionAlignment:
+   * =====
+   * The alignment (in bytes) of sections when they are loaded into
+   * memory. It must be greater than or equal to FileAlignment. The
+   * default is the page size for the architecture.
+   * =====
+   * Which doesn't tell you whose responsibility it is to enforce the
+   * "default", or when.  It implies that the value in the field must
+   * be > FileAlignment (also poorly defined), but it appears visual
+   * studio will happily write 512 for FileAlignment (its default) and
+   * 0 for SectionAlignment, intending to imply PAGE_SIZE.
+   *
+   * We only support one page size, so if it's zero, nerf it to 4096.
+   */
+  section_alignment = context.section_alignment;
+  if (section_alignment == 0)
+    section_alignment = 4096;
+
+  section_alignment = grub_max(section_alignment, mld->align);
+
+  ret = grub_relocator_alloc_chunk_align_safe (grub_multiboot2_relocator, &ch,
+                                               mld->min_addr, mld->max_addr,
+                                               context.image_size, section_alignment,
+                                               mld->preference, mld->avoid_efi_boot_services);
+
+  if (ret)
+    {
+      grub_dprintf ("multiboot_loader", "Cannot allocate memory for OS image\n");
+      return ret;
+    }
+
+  virt_addr = get_virtual_current_address (ch);
+  phys_addr = get_physical_target_address (ch);
+
+  if (grub_file_seek (mld->file, 0) == (grub_off_t) -1) {
+      ret = grub_errno;
+      goto out;
+  }
+
+  if (grub_file_read (mld->file, virt_addr, context.size_of_headers)
+      != (grub_ssize_t) context.size_of_headers)
+    {
+      if (!grub_errno)
+        {
+          grub_error (GRUB_ERR_FILE_READ_ERROR, "premature end of file %s",
+                      mld->filename);
+          ret = GRUB_ERR_FILE_READ_ERROR;
+        }
+      else
+          ret = grub_errno;
+      goto out;
+    }
+
+  mld->load_base_addr = phys_addr;
+  mld->link_base_addr = context.image_address;
+
+  grub_dprintf ("multiboot_loader", "load_base_addr: 0x%08x link_base_addr 0x%08x\n",
+                mld->load_base_addr, mld->link_base_addr);
+
+  grub_multiboot2_payload_eip = context.entry_point;
+  grub_dprintf ("multiboot_loader", "entry_point: 0x%08x\n", grub_multiboot2_payload_eip);
+  if (!grub_multiboot2_payload_eip)
+    {
+      grub_error (GRUB_ERR_BAD_ARGUMENT, "invalid entry point");
+      ret = GRUB_ERR_BAD_ARGUMENT;
+      goto out;
+    }
+
+  grub_dprintf ("multiboot_loader", "reloc_dir: %p reloc_size: 0x%08x\n",
+                (void *)(unsigned long)context.reloc_dir->rva,
+                context.reloc_dir->size);
+  reloc_base = image_address (phys_addr, context.image_size,
+                              context.reloc_dir->rva);
+  /* RelocBaseEnd here is the address of the last byte of the table */
+  reloc_base_end = image_address (phys_addr, context.image_size,
+                                  context.reloc_dir->rva
+                                  + context.reloc_dir->size - 1);
+  grub_dprintf ("multiboot_loader", "reloc_base: 0x%016lx reloc_base_end: 0x%016lx\n",
+                reloc_base, reloc_base_end);
+
+  section = context.first_section;
+  for (i = 0; i < context.number_of_sections; i++, section++)
+    {
+      char name[9];
+
+      base = image_address (phys_addr, context.image_size,
+                            section->virtual_address);
+      end = image_address (phys_addr, context.image_size,
+                           section->virtual_address + section->virtual_size -1);
+
+      grub_strncpy(name, section->name, 9);
+      name[8] = '\0';
+      grub_dprintf ("multiboot_loader", "Section %d \"%s\" at 0x%016lx..0x%016lx\n", i,
+                   name, base, end);
+
+      if (end < base)
+        {
+          grub_dprintf ("multiboot_loader", " base is 0x%016lx but end is 0x%016lx... bad.\n",
+                       base, end);
+          grub_error (GRUB_ERR_BAD_ARGUMENT,
+                      "Image has invalid negative size");
+          ret = GRUB_ERR_BAD_ARGUMENT;
+          goto out;
+        }
+
+      if (section->virtual_address <= context.entry_point &&
+          (section->virtual_address + section->raw_data_size - 1)
+          > context.entry_point)
+        {
+          found_entry_point++;
+          grub_dprintf ("multiboot_loader", " section contains entry point\n");
+        }
+
+      /* We do want to process .reloc, but it's often marked
+       * discardable, so we don't want to memcpy it. */
+      if (grub_memcmp (section->name, ".reloc\0\0", 8) == 0)
+        {
+          if (reloc_section)
+            {
+              grub_error (GRUB_ERR_BAD_ARGUMENT,
+                          "Image has multiple relocation sections");
+              ret = GRUB_ERR_BAD_ARGUMENT;
+              goto out;
+            }
+
+          /* If it has nonzero sizes, and our bounds check
+           * made sense, and the VA and size match RelocDir's
+           * versions, then we believe in this section table. */
+          if (section->raw_data_size && section->virtual_size &&
+              base && end && reloc_base == base)
+            {
+              if (reloc_base_end == end)
+                {
+                  grub_dprintf ("multiboot_loader", " section is relocation section\n");
+                  reloc_section = section;
+                }
+              else if (reloc_base_end && reloc_base_end < end)
+                {
+                  /* Bogus virtual size in the reloc section -- RelocDir
+                   * reported a smaller Base Relocation Directory. Decrease
+                   * the section's virtual size so that it equal RelocDir's
+                   * idea, but only for the purposes of relocate_coff(). */
+                  grub_dprintf ("multiboot_loader",
+                                " section is (overlong) relocation section\n");
+                  grub_memcpy (&fake_reloc_section, section, sizeof *section);
+                  fake_reloc_section.virtual_size -= (end - reloc_base_end);
+                  reloc_section = &fake_reloc_section;
+                }
+            }
+
+          if (!reloc_section)
+            {
+              grub_dprintf ("multiboot_loader", " section is not reloc section?\n");
+              grub_dprintf ("multiboot_loader", " rds: 0x%08x, vs: %08x\n",
+                            section->raw_data_size, section->virtual_size);
+              grub_dprintf ("multiboot_loader", " base: 0x%016lx end: 0x%016lx\n", base, end);
+              grub_dprintf ("multiboot_loader", " reloc_base: 0x%016lx reloc_base_end: 0x%016lx\n",
+                            reloc_base, reloc_base_end);
+            }
+        }
+
+      grub_dprintf ("multiboot_loader", " Section characteristics are %08x\n",
+                   section->characteristics);
+      grub_dprintf ("multiboot_loader", " Section virtual size: %08x\n",
+                   section->virtual_size);
+      grub_dprintf ("multiboot_loader", " Section raw_data size: %08x\n",
+                   section->raw_data_size);
+      if (section->characteristics & GRUB_PE32_SCN_MEM_DISCARDABLE)
+        {
+          grub_dprintf ("multiboot_loader", " Discarding section\n");
+          continue;
+        }
+
+      if (!base || !end)
+        {
+          grub_dprintf ("multiboot_loader", " section is invalid\n");
+          grub_error (GRUB_ERR_BAD_ARGUMENT, "Invalid section size");
+          ret = GRUB_ERR_BAD_ARGUMENT;
+          goto out;
+        }
+
+      if (section->characteristics & GRUB_PE32_SCN_CNT_UNINITIALIZED_DATA)
+        {
+          if (section->raw_data_size != 0)
+            grub_dprintf ("multiboot_loader", " UNINITIALIZED_DATA section has data?\n");
+        }
+      else if (section->virtual_address < context.size_of_headers ||
+               section->raw_data_offset < context.size_of_headers)
+        {
+          grub_error (GRUB_ERR_BAD_ARGUMENT,
+                      "Section %d is inside image headers", i);
+          ret = GRUB_ERR_BAD_ARGUMENT;
+          goto out;
+        }
+
+      if (section->raw_data_size > 0)
+        {
+          grub_dprintf ("multiboot_loader", " copying 0x%08x bytes to 0x%016lx\n",
+                        section->raw_data_size, base);
+
+          if (grub_file_seek (mld->file, section->raw_data_offset) == (grub_off_t) -1)
+            {
+              ret = grub_errno;
+              goto out;
+            }
+
+          if (grub_file_read (mld->file, virt_addr + (base - phys_addr), section->raw_data_size)
+              != (grub_ssize_t) section->raw_data_size)
+            {
+              if (!grub_errno)
+                {
+                  grub_error (GRUB_ERR_FILE_READ_ERROR, "premature end of file %s",
+                              mld->filename);
+                  ret = GRUB_ERR_FILE_READ_ERROR;
+                }
+              else
+                  ret = grub_errno;
+              goto out;
+            }
+        }
+
+      if (section->raw_data_size < section->virtual_size)
+        {
+          grub_dprintf ("multiboot_loader", " padding with 0x%08x bytes at 0x%016lx\n",
+                        section->virtual_size - section->raw_data_size,
+                        base + section->raw_data_size);
+          grub_memset (virt_addr + (base - phys_addr) + section->raw_data_size, 0,
+                       section->virtual_size - section->raw_data_size);
+        }
+
+      grub_dprintf ("multiboot_loader", " finished section %s\n", name);
+    }
+
+  /* 5 == EFI_IMAGE_DIRECTORY_ENTRY_BASERELOC */
+  if (context.number_of_rva_and_sizes <= 5)
+    {
+      grub_error (GRUB_ERR_BAD_ARGUMENT, "image has no relocation entry\n");
+      ret = GRUB_ERR_BAD_ARGUMENT;
+      goto out;
+    }
+
+  if (context.reloc_dir->size && reloc_section)
+    {
+      /* run the relocation fixups */
+      ret = relocate_coff (&context, reloc_section, phys_addr, virt_addr, mld);
+
+      if (ret)
+        {
+          grub_error (GRUB_ERR_BAD_ARGUMENT, "relocation failed");
+          goto out;
+        }
+    }
+
+  if (!found_entry_point)
+    {
+      grub_error (GRUB_ERR_BAD_ARGUMENT, "entry point is not within sections");
+      ret = GRUB_ERR_BAD_ARGUMENT;
+      goto out;
+    }
+  if (found_entry_point > 1)
+    {
+      grub_error (GRUB_ERR_BAD_ARGUMENT, "%d sections contain entry point",
+                  found_entry_point);
+      ret = GRUB_ERR_BAD_ARGUMENT;
+      goto out;
+    }
+
+out:
+  return ret;
+}
diff --git a/include/grub/efi/pe32.h b/include/grub/efi/pe32.h
index 4e6e9d254bd3..94435d758b46 100644
--- a/include/grub/efi/pe32.h
+++ b/include/grub/efi/pe32.h
@@ -20,6 +20,7 @@
 #define GRUB_EFI_PE32_HEADER	1
 
 #include 
+#include 
 #include 
 
 /* The MSDOS compatibility stub. This was copied from the output of
@@ -46,6 +47,28 @@
 
 #define GRUB_PE32_MSDOS_STUB_SIZE	0x80
 
+typedef struct {
+  grub_uint16_t  e_magic;    ///< Magic number.
+  grub_uint16_t  e_cblp;     ///< Bytes on last page of file.
+  grub_uint16_t  e_cp;       ///< Pages in file.
+  grub_uint16_t  e_crlc;     ///< Relocations.
+  grub_uint16_t  e_cparhdr;  ///< Size of header in paragraphs.
+  grub_uint16_t  e_minalloc; ///< Minimum extra paragraphs needed.
+  grub_uint16_t  e_maxalloc; ///< Maximum extra paragraphs needed.
+  grub_uint16_t  e_ss;       ///< Initial (relative) SS value.
+  grub_uint16_t  e_sp;       ///< Initial SP value.
+  grub_uint16_t  e_csum;     ///< Checksum.
+  grub_uint16_t  e_ip;       ///< Initial IP value.
+  grub_uint16_t  e_cs;       ///< Initial (relative) CS value.
+  grub_uint16_t  e_lfarlc;   ///< File address of relocation table.
+  grub_uint16_t  e_ovno;     ///< Overlay number.
+  grub_uint16_t  e_res[4];   ///< Reserved words.
+  grub_uint16_t  e_oemid;    ///< OEM identifier (for e_oeminfo).
+  grub_uint16_t  e_oeminfo;  ///< OEM information; e_oemid specific.
+  grub_uint16_t  e_res2[10]; ///< Reserved words.
+  grub_uint32_t  e_lfanew;   ///< File address of new exe header.
+} grub_pe32_msdos_header_t;
+
 #define GRUB_PE32_MAGIC			0x5a4d
 
 struct grub_msdos_image_header
@@ -249,6 +272,7 @@ struct grub_pe32_section_table
 
 #define GRUB_PE32_SCN_CNT_CODE			0x00000020
 #define GRUB_PE32_SCN_CNT_INITIALIZED_DATA	0x00000040
+#define GRUB_PE32_SCN_CNT_UNINITIALIZED_DATA    0x00000080
 #define GRUB_PE32_SCN_MEM_DISCARDABLE		0x02000000
 #define GRUB_PE32_SCN_MEM_EXECUTE		0x20000000
 #define GRUB_PE32_SCN_MEM_READ			0x40000000
@@ -349,4 +373,44 @@ struct grub_pe32_reloc
 #define GRUB_PE32_REL_I386_DIR32	0x6
 #define GRUB_PE32_REL_I386_REL32	0x14
 
+struct grub_pe32_header_32
+{
+  char signature[GRUB_PE32_SIGNATURE_SIZE];
+  struct grub_pe32_coff_header coff_header;
+  struct grub_pe32_optional_header optional_header;
+};
+
+struct grub_pe32_header_64
+{
+  char signature[GRUB_PE32_SIGNATURE_SIZE];
+  struct grub_pe32_coff_header coff_header;
+  struct grub_pe64_optional_header optional_header;
+};
+
+typedef union
+{
+  struct grub_pe32_header_32 pe32;
+  struct grub_pe32_header_64 pe32plus;
+} grub_pe_header_t;
+
+struct pe_coff_loader_image_context
+{
+  grub_efi_uint64_t image_address;
+  grub_efi_uint64_t image_size;
+  grub_efi_uint64_t entry_point;
+  grub_efi_uintn_t size_of_headers;
+  grub_efi_uint16_t image_type;
+  grub_efi_uint16_t number_of_sections;
+  grub_efi_uint32_t section_alignment;
+  struct grub_pe32_section_table *first_section;
+  struct grub_pe32_data_directory *reloc_dir;
+  struct grub_pe32_data_directory *sec_dir;
+  grub_efi_uint64_t number_of_rva_and_sizes;
+  grub_pe_header_t *pe_hdr;
+};
+
+typedef struct pe_coff_loader_image_context pe_coff_loader_image_context_t;
+
+#define EFI_IMAGE_NUMBER_OF_DIRECTORY_ENTRIES 16
+
 #endif /* ! GRUB_EFI_PE32_HEADER */
diff --git a/include/grub/multiboot2.h b/include/grub/multiboot2.h
index 1f6d4fc9e336..01e2b11755c2 100644
--- a/include/grub/multiboot2.h
+++ b/include/grub/multiboot2.h
@@ -97,6 +97,9 @@ typedef struct mbi_load_data mbi_load_data_t;
 grub_err_t
 grub_multiboot2_load_elf (mbi_load_data_t *mld);
 
+grub_err_t
+grub_multiboot2_load_pe (mbi_load_data_t *mld);
+
 extern grub_size_t grub_multiboot2_pure_size;
 extern grub_size_t grub_multiboot2_alloc_mbi;
 extern grub_uint32_t grub_multiboot2_payload_eip;
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Wed Mar 13 15:06:52 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 15:06:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692522.1079789 (Exim 4.92)
	(envelope-from )
	id 1rkQBw-0000Oy-PX; Wed, 13 Mar 2024 15:06:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692522.1079789; Wed, 13 Mar 2024 15:06:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkQBw-0000Nr-JH; Wed, 13 Mar 2024 15:06:52 +0000
Received: by outflank-mailman (input) for mailman id 692522;
 Wed, 13 Mar 2024 15:06:51 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkQBv-0007E2-IA
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 15:06:51 +0000
Received: from mail-qv1-xf2d.google.com (mail-qv1-xf2d.google.com
 [2607:f8b0:4864:20::f2d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 51169e27-e14b-11ee-a1ee-f123f15fe8a2;
 Wed, 13 Mar 2024 16:06:50 +0100 (CET)
Received: by mail-qv1-xf2d.google.com with SMTP id
 6a1803df08f44-690cd7f83cdso8532866d6.3
 for ; Wed, 13 Mar 2024 08:06:50 -0700 (PDT)
Received: from rossla-lxenia.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 p10-20020a0ccb8a000000b0068fba49ae81sm4786811qvk.57.2024.03.13.08.06.47
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 13 Mar 2024 08:06:48 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 51169e27-e14b-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710342409; x=1710947209; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=U2qmXAF7kH+Xo7dcYPNWV07zKXcD5akVAYdTNUPm5Ak=;
        b=tVB1GiHpXnQcD2V5b25BTuVUuKyMOyyTq4RDppna8VBmkXhb3uXtaysPMNa+YrYxG4
         dN7nhhA0RMx+epSBl4Djp4B3fbe0cinqAxEPzXvk5n2sA0m2tScKNd0DhagRCptSa7ou
         y2OkTda3cC934cNnUfR+fJLROfrvg4jW0sLk8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710342409; x=1710947209;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=U2qmXAF7kH+Xo7dcYPNWV07zKXcD5akVAYdTNUPm5Ak=;
        b=FHzoKKNIVhhMb01MeZEFn3BF1DpW4qNyd36xNQLQB922CMmjm0/ISN+HxmBEIVeM1M
         gXE5Nn/qV1yFVmG/zPhjVQKrXJY9He6MWZDtm8u98Vs9YJB5Dae201G+BxvD7rKkBVk8
         dS6EapDPd+Ok4sOtFuzFjvagL6zegya+8m0kFxFswTH2F3Q4fGSDvrbUWOxyM1ewwVun
         qMXcAHjTID3uTdqdG/pMZ2kV7xSAqHKIq83HiRO05ZtdXd3Kt9j2+MgPOtUACL+dB7+n
         AFj4mDDYC0pxYQ0eI+gjzauof3/u65pSKI0Pj30dwYeJWVvRqUnJdNJaTewAeS4Q7MFJ
         yGrg==
X-Gm-Message-State: AOJu0Yz4PIbcoiXHPm8cpWVhDdkg2GdepPEODpLiDUw6HC+aa5CZAuLK
	YnKwCB57v0v9oFwfyq3Txolquvr0s7KESxj2ymKjkhGe0Wv5wZprjkdPXPUHpw==
X-Google-Smtp-Source: AGHT+IGQZ+RUgmwNMglkrjL/bMqOBHmzI4m56/rX8h6MM0HjI4O+cM+TZ42/QjkUrbzW3oCnXKu05Q==
X-Received: by 2002:ad4:4e14:0:b0:690:b40b:8084 with SMTP id dl20-20020ad44e14000000b00690b40b8084mr74464qvb.40.1710342408924;
        Wed, 13 Mar 2024 08:06:48 -0700 (PDT)
From: Ross Lagerwall 
To: grub-devel@gnu.org
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Daniel Kiper ,
	Ross Lagerwall 
Subject: [PATCH 6/7] efi: Allow loading multiboot modules without verification
Date: Wed, 13 Mar 2024 15:07:47 +0000
Message-ID: <20240313150748.791236-7-ross.lagerwall@citrix.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20240313150748.791236-1-ross.lagerwall@citrix.com>
References: <20240313150748.791236-1-ross.lagerwall@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

GRUB doesn't do anything with multiboot modules except loading them and
passing a pointer to the multiboot kernel. Therefore GRUB itself doesn't
need to verify the module. Multiboot modules may contain code that needs
to be verified. If this is the case, the expectation is that the
multiboot kernel verifies the modules. For example, with Xen, the first
multiboot module contains the dom0 kernel binary and Xen verifies it
before starting it.

Signed-off-by: Ross Lagerwall 
---
 grub-core/kern/efi/sb.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/grub-core/kern/efi/sb.c b/grub-core/kern/efi/sb.c
index 8d3e413608bb..f76290d65e9f 100644
--- a/grub-core/kern/efi/sb.c
+++ b/grub-core/kern/efi/sb.c
@@ -171,6 +171,7 @@ shim_lock_verifier_init (grub_file_t io __attribute__ ((unused)),
     case GRUB_FILE_TYPE_LOADENV:
     case GRUB_FILE_TYPE_SAVEENV:
     case GRUB_FILE_TYPE_VERIFY_SIGNATURE:
+    case GRUB_FILE_TYPE_MULTIBOOT_MODULE:
       *flags = GRUB_VERIFY_FLAGS_SKIP_VERIFICATION;
       return GRUB_ERR_NONE;
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Wed Mar 13 15:06:55 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 15:06:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692523.1079799 (Exim 4.92)
	(envelope-from )
	id 1rkQBy-0000jy-Vg; Wed, 13 Mar 2024 15:06:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692523.1079799; Wed, 13 Mar 2024 15:06:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkQBy-0000jl-SP; Wed, 13 Mar 2024 15:06:54 +0000
Received: by outflank-mailman (input) for mailman id 692523;
 Wed, 13 Mar 2024 15:06:53 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkQBx-0007E2-1i
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 15:06:53 +0000
Received: from mail-qv1-xf2e.google.com (mail-qv1-xf2e.google.com
 [2607:f8b0:4864:20::f2e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 51f6b447-e14b-11ee-a1ee-f123f15fe8a2;
 Wed, 13 Mar 2024 16:06:51 +0100 (CET)
Received: by mail-qv1-xf2e.google.com with SMTP id
 6a1803df08f44-690cbf99143so21178816d6.3
 for ; Wed, 13 Mar 2024 08:06:51 -0700 (PDT)
Received: from rossla-lxenia.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 p10-20020a0ccb8a000000b0068fba49ae81sm4786811qvk.57.2024.03.13.08.06.49
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 13 Mar 2024 08:06:49 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 51f6b447-e14b-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710342410; x=1710947210; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=uqR8dKNf2s+DB1oba15Jm7Zlu18CJES9pn/IS/ryqIY=;
        b=hKMWjp32zbDDbRUzLQVOmaD7ECertCm6lXOmmi6FBOwsQHJRYypJmcIPkAMjIYGyy/
         6Qs/+ULmuo0S5fapTQASWavQ7rE8RmRHueuOZkr9uEqtn5JXndvMhUMTsVUV9yvR8Itk
         2hdSELXFheaQCwpOlpc4fKNIOr5xyKF6uIB+8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710342410; x=1710947210;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=uqR8dKNf2s+DB1oba15Jm7Zlu18CJES9pn/IS/ryqIY=;
        b=u7fm9E7mREUAZ9YfcQbtk+EcecKg2wBi944YxPDdpRr3PP9WZhQzu66AUmrBCmYeFf
         VOiRw9mCaX54D2itcqdv90DhVz/mmMoqzlphdQuftyD5yj6j0v3hef5oHjziE+2RzMDB
         moEP8zHiIIWK3xQZ16baj9yxS0wljX53FzBh3mXfJfFhwW4E0kJQLMWAtCZmLrrcl4ur
         zx0WywoNMILlJiZ36G2VcV2IIT2PU7ERDcHWfpdKGybPF9C1O3up6VJBEbsOg0zp7184
         Wt5V8wGIOiCIUpHo3Jkl5VFfuhbT02Y0RXPTujCaYYOxDEf6x+xLD2dljid5RocrjNJv
         IlhA==
X-Gm-Message-State: AOJu0YyCp+yFzFXHqbCVmgNvEJIJ6Kmlbbi+ljcSyZXEUSduYGFKOxQe
	rIh2foQKetdBTqEfTXjY0xea9VmS7032fnGFGoiRUNSbHrQ6vt9vgR2/Pjq5GQ==
X-Google-Smtp-Source: AGHT+IHxT3dfA7sDvc0ZsxxYeT08+PpGu6wmIj3vwZ/i++W2G2MrBTw/4jrp+2lKPO2k1A6hnNmZVQ==
X-Received: by 2002:a0c:ea43:0:b0:690:df46:3949 with SMTP id u3-20020a0cea43000000b00690df463949mr116341qvp.35.1710342410458;
        Wed, 13 Mar 2024 08:06:50 -0700 (PDT)
From: Ross Lagerwall 
To: grub-devel@gnu.org
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Daniel Kiper ,
	Ross Lagerwall 
Subject: [PATCH 7/7] verifiers: Verify after decompression
Date: Wed, 13 Mar 2024 15:07:48 +0000
Message-ID: <20240313150748.791236-8-ross.lagerwall@citrix.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20240313150748.791236-1-ross.lagerwall@citrix.com>
References: <20240313150748.791236-1-ross.lagerwall@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

It is convenient and common to have binaries stored in gzip archives
(e.g. xen.gz). Verification should be run after decompression rather
than before so reorder the file filter list as appropriate.

Signed-off-by: Ross Lagerwall 
---
 include/grub/file.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/grub/file.h b/include/grub/file.h
index a5bf3a792d6f..a1ef3582bc7b 100644
--- a/include/grub/file.h
+++ b/include/grub/file.h
@@ -182,10 +182,10 @@ extern grub_disk_read_hook_t EXPORT_VAR(grub_file_progress_hook);
 /* Filters with lower ID are executed first.  */
 typedef enum grub_file_filter_id
   {
-    GRUB_FILE_FILTER_VERIFY,
     GRUB_FILE_FILTER_GZIO,
     GRUB_FILE_FILTER_XZIO,
     GRUB_FILE_FILTER_LZOPIO,
+    GRUB_FILE_FILTER_VERIFY,
     GRUB_FILE_FILTER_MAX,
     GRUB_FILE_FILTER_COMPRESSION_FIRST = GRUB_FILE_FILTER_GZIO,
     GRUB_FILE_FILTER_COMPRESSION_LAST = GRUB_FILE_FILTER_LZOPIO,
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Wed Mar 13 15:17:04 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 15:17:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692559.1079839 (Exim 4.92)
	(envelope-from )
	id 1rkQLn-0006Mi-SU; Wed, 13 Mar 2024 15:17:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692559.1079839; Wed, 13 Mar 2024 15:17:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkQLn-0006MX-Ny; Wed, 13 Mar 2024 15:17:03 +0000
Received: by outflank-mailman (input) for mailman id 692559;
 Wed, 13 Mar 2024 15:17:02 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkQLm-00064u-3S
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 15:17:02 +0000
Received: from fout3-smtp.messagingengine.com (fout3-smtp.messagingengine.com
 [103.168.172.146]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id bcd7d46c-e14c-11ee-afdd-a90da7624cb6;
 Wed, 13 Mar 2024 16:17:00 +0100 (CET)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43])
 by mailfout.nyi.internal (Postfix) with ESMTP id ADF1013800C4;
 Wed, 13 Mar 2024 11:16:59 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163])
 by compute3.internal (MEProxy); Wed, 13 Mar 2024 11:16:59 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed,
 13 Mar 2024 11:16:58 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: bcd7d46c-e14c-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:from:from:in-reply-to
	:in-reply-to:message-id:mime-version:references:reply-to:subject
	:subject:to:to; s=fm1; t=1710343019; x=1710429419; bh=4SwFKvimJV
	RlV6iERPovdY29XXOSNZstQLCDxtr3mlE=; b=G74MjXFlPZBP9p7g4lW9LhU1+H
	xjzTZ8N8s4SSAF9i8X+4EpGmD/skZDBgDyeIuWJzLpqG8k0qhUBjVWtOTW+BcHzY
	XOQxs4GJPaloWLu9QaaVyXgp78y3UpqVx0wfpy6nqoZep3f53vz/AwVqOrrSvXl7
	bMvPMTNwQHJQ39/KHLlaEbhWXpj0uHfDu0M/mzPxZmuYgsp1gxxhHHFcqCGBU3aZ
	Lf//v7f1YHNwuXGDWaDBx9kOvXxWIlkHevAOwCOYtEnpQcmVkBuhU0v3eRY8NPd5
	A2+53E6GvLARsOP26Cc9Oef8vVe2/4+nF4uif92RnxvwugKrardUxkgD5LHQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:feedback-id:feedback-id
	:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy
	:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1710343019; x=
	1710429419; bh=4SwFKvimJVRlV6iERPovdY29XXOSNZstQLCDxtr3mlE=; b=j
	I2YjelrTFhvLfurwxrmdoOHCP+0/g3rkhjFOlcCniQdXZI6uaLM9NKWo3WAu9rAj
	Vgm7Eu1LTaXAVv/wyH2WjIbKxJ2lVA2vefD418QIq3SsJWuKRcXY5MTuGTR19YFf
	AsqKNHUnlvbGR43Aaq8d8DYwaFsSPB7NrBvBXF7WpquZTDD5jGIkGzKK/83lFTWP
	C9Io87D7Xq5rnx16zzYkYeyI3vEfzc3pwRepwa1y3ivFBoB2AvixibvQ1HbOSxzq
	JiMqSpgBXCjAORB6V8N/nK8Q2z4L26mEcSflNfN7W3ijQwrtRFgzzgiWoUIZRv3q
	H7Jy4yEcQv7Qb/ub/RFpw==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrjeehgdejgecutefuodetggdotefrodftvf
    curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
    uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc
    fjughrpefhvfevufffkffojghfgggtgfesthekredtredtjeenucfhrhhomhepofgrrhgv
    khcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinh
    hvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhephfei
    hffghefgkeetiefgtdeivdfgvefhhfefvdduleetvdfggedtkeetfeefgeehnecuffhomh
    grihhnpehmshhigihtsghlpghlihhsthdrnhgvgihtnecuvehluhhsthgvrhfuihiivgep
    tdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghksehinhhvihhsihgslh
    gvthhhihhnghhslhgrsgdrtghomh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
To: xen-devel@lists.xenproject.org
Cc: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Wei Liu 
Subject: [PATCH v5 3/7] x86/hvm: Allow access to registers on the same page as MSI-X table
Date: Wed, 13 Mar 2024 16:16:08 +0100
Message-ID: 
X-Mailer: git-send-email 2.43.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Some devices (notably Intel Wifi 6 AX210 card) keep auxiliary registers
on the same page as MSI-X table. Device model (especially one in
stubdomain) cannot really handle those, as direct writes to that page is
refused (page is on the mmio_ro_ranges list). Instead, extend
msixtbl_mmio_ops to handle such accesses too.

Doing this, requires correlating read/write location with guest
of MSI-X table address. Since QEMU doesn't map MSI-X table to the guest,
it requires msixtbl_entry->gtable, which is HVM-only. Similar feature
for PV would need to be done separately.

This will be also used to read Pending Bit Array, if it lives on the same
page, making QEMU not needing /dev/mem access at all (especially helpful
with lockdown enabled in dom0). If PBA lives on another page, QEMU will
map it to the guest directly.
If PBA lives on the same page, discard writes and log a message.
Technically, writes outside of PBA could be allowed, but at this moment
the precise location of PBA isn't saved, and also no known device abuses
the spec in this way (at least yet).

To access those registers, msixtbl_mmio_ops need the relevant page
mapped. MSI handling already has infrastructure for that, using fixmap,
so try to map first/last page of the MSI-X table (if necessary) and save
their fixmap indexes. Note that msix_get_fixmap() does reference
counting and reuses existing mapping, so just call it directly, even if
the page was mapped before. Also, it uses a specific range of fixmap
indexes which doesn't include 0, so use 0 as default ("not mapped")
value - which simplifies code a bit.

GCC 12.2.1 gets confused about 'desc' variable:

    arch/x86/hvm/vmsi.c: In function ‘msixtbl_range’:
    arch/x86/hvm/vmsi.c:553:8: error: ‘desc’ may be used uninitialized [-Werror=maybe-uninitialized]
      553 |     if ( desc )
          |        ^
    arch/x86/hvm/vmsi.c:537:28: note: ‘desc’ was declared here
      537 |     const struct msi_desc *desc;
          |                            ^~~~

It's conditional initialization is actually correct (in the case where
it isn't initialized, function returns early), but to avoid
build failure initialize it explicitly to NULL anyway.

Signed-off-by: Marek Marczykowski-Górecki 
---
Changes in v5:
- style fixes
- include GCC version in the commit message
- warn only once (per domain, per device) about failed adjacent access
Changes in v4:
- drop same_page parameter of msixtbl_find_entry(), distinguish two
  cases in relevant callers
- rename adj_access_table_idx to adj_access_idx
- code style fixes
- drop alignment check in adjacent_{read,write}() - all callers already
  have it earlier
- delay mapping first/last MSI-X pages until preparing device for a
  passthrough
v3:
 - merge handling into msixtbl_mmio_ops
 - extend commit message
v2:
 - adjust commit message
 - pass struct domain to msixtbl_page_handler_get_hwaddr()
 - reduce local variables used only once
 - log a warning if write is forbidden if MSI-X and PBA lives on the same
   page
 - do not passthrough unaligned accesses
 - handle accesses both before and after MSI-X table
---
 xen/arch/x86/hvm/vmsi.c        | 209 ++++++++++++++++++++++++++++++++--
 xen/arch/x86/include/asm/msi.h |   7 +-
 xen/arch/x86/msi.c             |  41 +++++++-
 3 files changed, 247 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/hvm/vmsi.c b/xen/arch/x86/hvm/vmsi.c
index 999917983789..5ac3d9d9b4cf 100644
--- a/xen/arch/x86/hvm/vmsi.c
+++ b/xen/arch/x86/hvm/vmsi.c
@@ -180,6 +180,10 @@ static bool msixtbl_initialised(const struct domain *d)
     return d->arch.hvm.msixtbl_list.next;
 }
 
+/*
+ * Lookup an msixtbl_entry on the same page as given addr. It's up to the
+ * caller to check if address is strictly part of the table - if relevant.
+ */
 static struct msixtbl_entry *msixtbl_find_entry(
     struct vcpu *v, unsigned long addr)
 {
@@ -187,8 +191,8 @@ static struct msixtbl_entry *msixtbl_find_entry(
     struct domain *d = v->domain;
 
     list_for_each_entry( entry, &d->arch.hvm.msixtbl_list, list )
-        if ( addr >= entry->gtable &&
-             addr < entry->gtable + entry->table_len )
+        if ( PFN_DOWN(addr) >= PFN_DOWN(entry->gtable) &&
+             PFN_DOWN(addr) <= PFN_DOWN(entry->gtable + entry->table_len - 1) )
             return entry;
 
     return NULL;
@@ -213,6 +217,148 @@ static struct msi_desc *msixtbl_addr_to_desc(
     return NULL;
 }
 
+/*
+ * Returns:
+ *  - ADJACENT_DONT_HANDLE if no handling should be done
+ *  - ADJACENT_DISCARD_WRITE if write should be discarded
+ *  - a fixmap idx to use for handling
+ */
+#define ADJACENT_DONT_HANDLE UINT_MAX
+#define ADJACENT_DISCARD_WRITE (UINT_MAX - 1)
+static unsigned int adjacent_handle(
+    const struct msixtbl_entry *entry, unsigned long addr, bool write)
+{
+    unsigned int adj_type;
+    struct arch_msix *msix;
+
+    if ( !entry || !entry->pdev )
+        return ADJACENT_DONT_HANDLE;
+
+    if ( PFN_DOWN(addr) == PFN_DOWN(entry->gtable) && addr < entry->gtable )
+        adj_type = ADJ_IDX_FIRST;
+    else if ( PFN_DOWN(addr) == PFN_DOWN(entry->gtable + entry->table_len - 1) &&
+              addr >= entry->gtable + entry->table_len )
+        adj_type = ADJ_IDX_LAST;
+    else
+        return ADJACENT_DONT_HANDLE;
+
+    msix = entry->pdev->msix;
+    ASSERT(msix);
+
+    if ( !msix->adj_access_idx[adj_type] )
+    {
+        if ( msix->warned_domid != entry->pdev->domain->domain_id )
+        {
+            msix->warned_domid = entry->pdev->domain->domain_id;
+            msix->warned_kind.all = 0;
+        }
+        if ( !msix->warned_kind.u.adjacent_not_initialized )
+        {
+            msix->warned_kind.u.adjacent_not_initialized = true;
+            gprintk(XENLOG_WARNING,
+                    "Page for adjacent(%d) MSI-X table access not initialized for %pp (addr %#lx, gtable %#lx\n",
+                    adj_type, &entry->pdev->sbdf, addr, entry->gtable);
+        }
+        return ADJACENT_DONT_HANDLE;
+    }
+
+    /* If PBA lives on the same page too, discard writes. */
+    if ( write &&
+         ((adj_type == ADJ_IDX_LAST &&
+           msix->table.last == msix->pba.first) ||
+          (adj_type == ADJ_IDX_FIRST &&
+           msix->table.first == msix->pba.last)) )
+    {
+        if ( msix->warned_domid != entry->pdev->domain->domain_id )
+        {
+            msix->warned_domid = entry->pdev->domain->domain_id;
+            msix->warned_kind.all = 0;
+        }
+        if ( !msix->warned_kind.u.adjacent_pba )
+        {
+            msix->warned_kind.u.adjacent_pba = true;
+            gprintk(XENLOG_WARNING,
+                    "MSI-X table and PBA of %pp live on the same page, "
+                    "writing to other registers there is not implemented\n",
+                    &entry->pdev->sbdf);
+        }
+        return ADJACENT_DISCARD_WRITE;
+    }
+
+    return msix->adj_access_idx[adj_type];
+}
+
+static int adjacent_read(
+    unsigned int fixmap_idx,
+    paddr_t address, unsigned int len, uint64_t *pval)
+{
+    const void __iomem *hwaddr;
+
+    *pval = ~0UL;
+
+    ASSERT(fixmap_idx != ADJACENT_DISCARD_WRITE);
+
+    hwaddr = fix_to_virt(fixmap_idx) + PAGE_OFFSET(address);
+
+    switch ( len )
+    {
+    case 1:
+        *pval = readb(hwaddr);
+        break;
+
+    case 2:
+        *pval = readw(hwaddr);
+        break;
+
+    case 4:
+        *pval = readl(hwaddr);
+        break;
+
+    case 8:
+        *pval = readq(hwaddr);
+        break;
+
+    default:
+        ASSERT_UNREACHABLE();
+    }
+    return X86EMUL_OKAY;
+}
+
+static int adjacent_write(
+    unsigned int fixmap_idx,
+    paddr_t address, unsigned int len, uint64_t val)
+{
+    void __iomem *hwaddr;
+
+    if ( fixmap_idx == ADJACENT_DISCARD_WRITE )
+        return X86EMUL_OKAY;
+
+    hwaddr = fix_to_virt(fixmap_idx) + PAGE_OFFSET(address);
+
+    switch ( len )
+    {
+    case 1:
+        writeb(val, hwaddr);
+        break;
+
+    case 2:
+        writew(val, hwaddr);
+        break;
+
+    case 4:
+        writel(val, hwaddr);
+        break;
+
+    case 8:
+        writeq(val, hwaddr);
+        break;
+
+    default:
+        ASSERT_UNREACHABLE();
+    }
+    return X86EMUL_OKAY;
+}
+
 static int cf_check msixtbl_read(
     const struct hvm_io_handler *handler, uint64_t address, uint32_t len,
     uint64_t *pval)
@@ -220,9 +366,10 @@ static int cf_check msixtbl_read(
     unsigned long offset;
     struct msixtbl_entry *entry;
     unsigned int nr_entry, index;
+    unsigned int adjacent_fixmap;
     int r = X86EMUL_UNHANDLEABLE;
 
-    if ( (len != 4 && len != 8) || (address & (len - 1)) )
+    if ( !IS_ALIGNED(address, len) )
         return r;
 
     rcu_read_lock(&msixtbl_rcu_lock);
@@ -230,6 +377,21 @@ static int cf_check msixtbl_read(
     entry = msixtbl_find_entry(current, address);
     if ( !entry )
         goto out;
+
+    adjacent_fixmap = adjacent_handle(entry, address, false);
+    if ( adjacent_fixmap != ADJACENT_DONT_HANDLE )
+    {
+        r = adjacent_read(adjacent_fixmap, address, len, pval);
+        goto out;
+    }
+
+    if ( address < entry->gtable ||
+         address >= entry->gtable + entry->table_len )
+        goto out;
+
+    if ( len != 4 && len != 8 )
+        goto out;
+
     offset = address & (PCI_MSIX_ENTRY_SIZE - 1);
 
     if ( offset != PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET )
@@ -282,6 +444,7 @@ static int msixtbl_write(struct vcpu *v, unsigned long address,
     int r = X86EMUL_UNHANDLEABLE;
     unsigned long flags;
     struct irq_desc *desc;
+    unsigned int adjacent_fixmap;
 
     if ( !IS_ALIGNED(address, len) )
         return X86EMUL_OKAY;
@@ -291,6 +454,21 @@ static int msixtbl_write(struct vcpu *v, unsigned long address,
     entry = msixtbl_find_entry(v, address);
     if ( !entry )
         goto out;
+
+    adjacent_fixmap = adjacent_handle(entry, address, true);
+    if ( adjacent_fixmap != ADJACENT_DONT_HANDLE )
+    {
+        r = adjacent_write(adjacent_fixmap, address, len, val);
+        goto out;
+    }
+
+    if ( address < entry->gtable ||
+         address >= entry->gtable + entry->table_len )
+        goto out;
+
+    if ( len != 4 && len != 8 )
+        goto out;
+
     nr_entry = array_index_nospec(((address - entry->gtable) /
                                    PCI_MSIX_ENTRY_SIZE),
                                   MAX_MSIX_TABLE_ENTRIES);
@@ -356,8 +534,8 @@ static int cf_check _msixtbl_write(
     const struct hvm_io_handler *handler, uint64_t address, uint32_t len,
     uint64_t val)
 {
-    /* Ignore invalid length or unaligned writes. */
-    if ( (len != 4 && len != 8) || !IS_ALIGNED(address, len) )
+    /* Ignore unaligned writes. */
+    if ( !IS_ALIGNED(address, len) )
         return X86EMUL_OKAY;
 
     /*
@@ -374,14 +552,22 @@ static bool cf_check msixtbl_range(
 {
     struct vcpu *curr = current;
     unsigned long addr = r->addr;
-    const struct msi_desc *desc;
+    const struct msixtbl_entry *entry;
+    const struct msi_desc *desc = NULL;
+    unsigned int adjacent_fixmap;
 
     ASSERT(r->type == IOREQ_TYPE_COPY);
 
     rcu_read_lock(&msixtbl_rcu_lock);
-    desc = msixtbl_addr_to_desc(msixtbl_find_entry(curr, addr), addr);
+    entry = msixtbl_find_entry(curr, addr);
+    adjacent_fixmap = adjacent_handle(entry, addr, false);
+    if ( adjacent_fixmap == ADJACENT_DONT_HANDLE )
+        desc = msixtbl_addr_to_desc(entry, addr);
     rcu_read_unlock(&msixtbl_rcu_lock);
 
+    if ( adjacent_fixmap != ADJACENT_DONT_HANDLE )
+        return 1;
+
     if ( desc )
         return 1;
 
@@ -622,12 +808,15 @@ void msix_write_completion(struct vcpu *v)
          v->arch.hvm.hvm_io.msix_snoop_gpa )
     {
         unsigned int token = hvmemul_cache_disable(v);
-        const struct msi_desc *desc;
+        const struct msi_desc *desc = NULL;
+        const struct msixtbl_entry *entry;
         uint32_t data;
 
         rcu_read_lock(&msixtbl_rcu_lock);
-        desc = msixtbl_addr_to_desc(msixtbl_find_entry(v, snoop_addr),
-                                    snoop_addr);
+        entry = msixtbl_find_entry(v, snoop_addr);
+        if ( entry && snoop_addr >= entry->gtable &&
+                      snoop_addr < entry->gtable + entry->table_len )
+            desc = msixtbl_addr_to_desc(entry, snoop_addr);
         rcu_read_unlock(&msixtbl_rcu_lock);
 
         if ( desc &&
diff --git a/xen/arch/x86/include/asm/msi.h b/xen/arch/x86/include/asm/msi.h
index 19b1e6631fdf..400944682b17 100644
--- a/xen/arch/x86/include/asm/msi.h
+++ b/xen/arch/x86/include/asm/msi.h
@@ -208,6 +208,10 @@ struct msg_address {
                                        PCI_MSIX_ENTRY_SIZE + \
                                        (~PCI_MSIX_BIRMASK & (PAGE_SIZE - 1)))
 
+/* Indexes in adj_access_idx[] below */
+#define ADJ_IDX_FIRST 0
+#define ADJ_IDX_LAST  1
+
 struct arch_msix {
     unsigned int nr_entries, used_entries;
     struct {
@@ -215,6 +219,7 @@ struct arch_msix {
     } table, pba;
     int table_refcnt[MAX_MSIX_TABLE_PAGES];
     int table_idx[MAX_MSIX_TABLE_PAGES];
+    unsigned int adj_access_idx[2];
     spinlock_t table_lock;
     bool host_maskall, guest_maskall;
     domid_t warned_domid;
@@ -222,6 +227,8 @@ struct arch_msix {
         uint8_t all;
         struct {
             bool maskall                   : 1;
+            bool adjacent_not_initialized  : 1;
+            bool adjacent_pba              : 1;
         } u;
     } warned_kind;
 };
diff --git a/xen/arch/x86/msi.c b/xen/arch/x86/msi.c
index 6433df30bd60..b4aa0e53be2c 100644
--- a/xen/arch/x86/msi.c
+++ b/xen/arch/x86/msi.c
@@ -921,6 +921,36 @@ static int msix_capability_init(struct pci_dev *dev,
         list_add_tail(&entry->list, &dev->msi_list);
         *desc = entry;
     }
+    else
+    {
+        /*
+         * If the MSI-X table doesn't start at the page boundary, map the first page for
+         * passthrough accesses.
+         */
+        if ( PAGE_OFFSET(table_paddr) )
+        {
+            int idx = msix_get_fixmap(msix, table_paddr, table_paddr);
+
+            if ( idx > 0 )
+                msix->adj_access_idx[ADJ_IDX_FIRST] = idx;
+            else
+                gprintk(XENLOG_ERR, "Failed to map first MSI-X table page: %d\n", idx);
+        }
+        /*
+         * If the MSI-X table doesn't end on the page boundary, map the last page
+         * for passthrough accesses.
+         */
+        if ( PAGE_OFFSET(table_paddr + msix->nr_entries * PCI_MSIX_ENTRY_SIZE) )
+        {
+            uint64_t entry_paddr = table_paddr + msix->nr_entries * PCI_MSIX_ENTRY_SIZE;
+            int idx = msix_get_fixmap(msix, table_paddr, entry_paddr);
+
+            if ( idx > 0 )
+                msix->adj_access_idx[ADJ_IDX_LAST] = idx;
+            else
+                gprintk(XENLOG_ERR, "Failed to map last MSI-X table page: %d\n", idx);
+        }
+    }
 
     if ( !msix->used_entries )
     {
@@ -1087,6 +1117,17 @@ static void _pci_cleanup_msix(struct arch_msix *msix)
         msix->table.first = 0;
         msix->table.last = 0;
 
+        if ( msix->adj_access_idx[ADJ_IDX_FIRST] )
+        {
+            msix_put_fixmap(msix, msix->adj_access_idx[ADJ_IDX_FIRST]);
+            msix->adj_access_idx[ADJ_IDX_FIRST] = 0;
+        }
+        if ( msix->adj_access_idx[ADJ_IDX_LAST] )
+        {
+            msix_put_fixmap(msix, msix->adj_access_idx[ADJ_IDX_LAST]);
+            msix->adj_access_idx[ADJ_IDX_LAST] = 0;
+        }
+
         if ( rangeset_remove_range(mmio_ro_ranges, msix->pba.first,
                                    msix->pba.last) )
             WARN();
-- 
git-series 0.9.1


From xen-devel-bounces@lists.xenproject.org Wed Mar 13 15:17:04 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 15:17:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692557.1079815 (Exim 4.92)
	(envelope-from )
	id 1rkQLk-0005hU-9Y; Wed, 13 Mar 2024 15:17:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692557.1079815; Wed, 13 Mar 2024 15:17:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkQLk-0005gx-5V; Wed, 13 Mar 2024 15:17:00 +0000
Received: by outflank-mailman (input) for mailman id 692557;
 Wed, 13 Mar 2024 15:16:59 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkQLj-0005e0-8l
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 15:16:59 +0000
Received: from fout3-smtp.messagingengine.com (fout3-smtp.messagingengine.com
 [103.168.172.146]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id bb051b42-e14c-11ee-a1ee-f123f15fe8a2;
 Wed, 13 Mar 2024 16:16:57 +0100 (CET)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.48])
 by mailfout.nyi.internal (Postfix) with ESMTP id 74D8513800A7;
 Wed, 13 Mar 2024 11:16:56 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163])
 by compute7.internal (MEProxy); Wed, 13 Mar 2024 11:16:56 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed,
 13 Mar 2024 11:16:54 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: bb051b42-e14c-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:from:from:in-reply-to
	:in-reply-to:message-id:mime-version:references:reply-to:subject
	:subject:to:to; s=fm1; t=1710343016; x=1710429416; bh=G9GKN9B8dH
	TGd4PXNPHUeKZSdjSUiY5pvs4yUwY572k=; b=THMohA7j8GCuaUm4OWNqJ5qAIr
	SXO34opW77Frm+pxeTW1cCtAzJzFnTbuDH7gT9NfZFj+HnIjEKOeHzQMxHRdDJzY
	6WKM/VKkvfnymn3rwX2XDnowvXKgXw1VSlYeGL0qzjBVvPJ/3kcjqX+RpgPrfWpO
	53pCjlREs6rB5CxWcvKJFYGWl6ioeaH/JdXH6ufHtEmR/8idKYURJSLggVVgjegZ
	b6q7rrZg4FqLyhE9D/fCIi/LAekJCjBcGnAfFouqtNRc127+aEPSYjAQcIJyBY4m
	gWaS6fLPAHGRS1L/XCcVo0PAXTuewCdkgQr6HlOoCVQmPnxg/koDmUEe2VXg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:feedback-id:feedback-id
	:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy
	:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1710343016; x=
	1710429416; bh=G9GKN9B8dHTGd4PXNPHUeKZSdjSUiY5pvs4yUwY572k=; b=Y
	jNN8vNAoZxGkodc9tFNvuGk/xsa6iFmhUdjCk+f89GqBVHtN38gBq/39lGMJnAU2
	2A2NUZOKjYvTpqcNYzXvKauNjxl92Lr8ETfExGTQRLu1PAseutIJLDfteUqWxvVX
	0IqRmljTxclqjhgaVGaU66Tk98rZ71O6KvVXMqqnvFVaqMDOhDd1BZc9o3SbWEn5
	GbqauV7lfC4SlpkpGgjqpnG+iWTt/JmXj6Mt4jyh9k7GbiTQifIpT2Nafmgc9qu8
	iPW0WimKaWdlbGe6gnyDwdBW7eiLu99X8StfXznuL8RRY/gs05iOQnd7bRkCu/wL
	t/q/2PY2NgjUJek/T3K/A==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrjeehgdejgecutefuodetggdotefrodftvf
    curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
    uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc
    fjughrpefhvfevufffkffojghfgggtgfesthekredtredtjeenucfhrhhomhepofgrrhgv
    khcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinh
    hvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepgfeu
    udehgfdvfeehhedujeehfeduveeugefhkefhheelgeevudetueeiudfggfffnecuvehluh
    hsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghk
    sehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
To: xen-devel@lists.xenproject.org
Cc: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Wei Liu ,
	George Dunlap ,
	Julien Grall ,
	Stefano Stabellini 
Subject: [PATCH v5 1/7] x86/msi: passthrough all MSI-X vector ctrl writes to device model
Date: Wed, 13 Mar 2024 16:16:06 +0100
Message-ID: <3e1150560a41bd567049627d684cd4e754530869.1710342968.git-series.marmarek@invisiblethingslab.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

QEMU needs to know whether clearing maskbit of a vector is really
clearing, or was already cleared before. Currently Xen sends only
clearing that bit to the device model, but not setting it, so QEMU
cannot detect it. Because of that, QEMU is working this around by
checking via /dev/mem, but that isn't the proper approach.

Give all necessary information to QEMU by passing all ctrl writes,
including masking a vector. Advertise the new behavior via
XENVER_get_features, so QEMU can know it doesn't need to access /dev/mem
anymore.

While this commit doesn't move the whole maskbit handling to QEMU (as
discussed on xen-devel as one of the possibilities), it is a necessary
first step anyway. Including telling QEMU it will get all the required
information to do so. The actual implementation would need to include:
 - a hypercall for QEMU to control just maskbit (without (re)binding the
   interrupt again
 - a methor for QEMU to tell Xen it will actually do the work
Those are not part of this series.

Signed-off-by: Marek Marczykowski-Górecki 
---
I did not added any control to enable/disable this new behavior (as
Roger have suggested for possible non-QEMU ioreqs). I don't see how the
new behavior could be problematic for some existing ioreq server (they
already received writes to those addresses, just not all of them),
but if that's really necessary, I can probably add a command line option
to restore previous behavior system-wide.

Changes in v5:
- announce the feature only on x86
- style fixes

Changes in v4:
- ignore unaligned writes with X86EMUL_OKAY
- restructure the code to forward all writes in _msixtbl_write() instead
  of manipulating return value of msixtbl_write() - this makes
  WRITE_LEN4_COMPLETION special case unnecessary
- advertise the changed behavior via XENVER_get_features instead of DMOP
v3:
 - advertise changed behavior in XEN_DMOP_get_ioreq_server_info - make
   "flags" parameter IN/OUT
 - move len check back to msixtbl_write() - will be needed there anyway
   in a later patch
v2:
 - passthrough quad writes to emulator too (Jan)
 - (ab)use len==0 for write len=4 completion (Jan), but add descriptive
   #define for this magic value
---
 xen/arch/x86/hvm/vmsi.c       | 19 ++++++++++++++-----
 xen/common/kernel.c           |  1 +
 xen/include/public/features.h |  8 ++++++++
 3 files changed, 23 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/hvm/vmsi.c b/xen/arch/x86/hvm/vmsi.c
index adbac965f9f7..999917983789 100644
--- a/xen/arch/x86/hvm/vmsi.c
+++ b/xen/arch/x86/hvm/vmsi.c
@@ -283,8 +283,8 @@ static int msixtbl_write(struct vcpu *v, unsigned long address,
     unsigned long flags;
     struct irq_desc *desc;
 
-    if ( (len != 4 && len != 8) || (address & (len - 1)) )
-        return r;
+    if ( !IS_ALIGNED(address, len) )
+        return X86EMUL_OKAY;
 
     rcu_read_lock(&msixtbl_rcu_lock);
 
@@ -345,8 +345,7 @@ static int msixtbl_write(struct vcpu *v, unsigned long address,
 
 unlock:
     spin_unlock_irqrestore(&desc->lock, flags);
-    if ( len == 4 )
-        r = X86EMUL_OKAY;
+    r = X86EMUL_OKAY;
 
 out:
     rcu_read_unlock(&msixtbl_rcu_lock);
@@ -357,7 +356,17 @@ static int cf_check _msixtbl_write(
     const struct hvm_io_handler *handler, uint64_t address, uint32_t len,
     uint64_t val)
 {
-    return msixtbl_write(current, address, len, val);
+    /* Ignore invalid length or unaligned writes. */
+    if ( (len != 4 && len != 8) || !IS_ALIGNED(address, len) )
+        return X86EMUL_OKAY;
+
+    /*
+     * This function returns X86EMUL_UNHANDLEABLE even if write is properly
+     * handled, to propagate it to the device model (so it can keep its
+     * internal state in sync).
+     */
+    msixtbl_write(current, address, len, val);
+    return X86EMUL_UNHANDLEABLE;
 }
 
 static bool cf_check msixtbl_range(
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index 08dbaa2a054c..b44b2439ca8e 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -637,6 +637,7 @@ long do_xen_version(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
                 fi.submap |= (1U << XENFEAT_hvm_safe_pvclock) |
                              (1U << XENFEAT_hvm_callback_vector) |
                              (has_pirq(d) ? (1U << XENFEAT_hvm_pirqs) : 0);
+            fi.submap |= (1U << XENFEAT_dm_msix_all_writes);
 #endif
             if ( !paging_mode_translate(d) || is_domain_direct_mapped(d) )
                 fi.submap |= (1U << XENFEAT_direct_mapped);
diff --git a/xen/include/public/features.h b/xen/include/public/features.h
index 4437f25d2532..880193094713 100644
--- a/xen/include/public/features.h
+++ b/xen/include/public/features.h
@@ -120,6 +120,14 @@
 #define XENFEAT_runstate_phys_area        18
 #define XENFEAT_vcpu_time_phys_area       19
 
+/*
+ * If set, Xen will passthrough all MSI-X vector ctrl writes to device model,
+ * not only those unmasking an entry. This allows device model to properly keep
+ * track of the MSI-X table without having to read it from the device behind
+ * Xen's backs. This information is relevant only for device models.
+ */
+#define XENFEAT_dm_msix_all_writes        20
+
 #define XENFEAT_NR_SUBMAPS 1
 
 #endif /* __XEN_PUBLIC_FEATURES_H__ */
-- 
git-series 0.9.1


From xen-devel-bounces@lists.xenproject.org Wed Mar 13 15:17:04 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 15:17:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692556.1079809 (Exim 4.92)
	(envelope-from )
	id 1rkQLk-0005eI-1o; Wed, 13 Mar 2024 15:17:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692556.1079809; Wed, 13 Mar 2024 15:17:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkQLj-0005eB-Tp; Wed, 13 Mar 2024 15:16:59 +0000
Received: by outflank-mailman (input) for mailman id 692556;
 Wed, 13 Mar 2024 15:16:58 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkQLi-0005e0-Il
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 15:16:58 +0000
Received: from fout3-smtp.messagingengine.com (fout3-smtp.messagingengine.com
 [103.168.172.146]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b9e527e8-e14c-11ee-a1ee-f123f15fe8a2;
 Wed, 13 Mar 2024 16:16:55 +0100 (CET)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45])
 by mailfout.nyi.internal (Postfix) with ESMTP id 3DC1913800C0;
 Wed, 13 Mar 2024 11:16:54 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163])
 by compute5.internal (MEProxy); Wed, 13 Mar 2024 11:16:54 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed,
 13 Mar 2024 11:16:53 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b9e527e8-e14c-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:from:from:in-reply-to
	:message-id:mime-version:reply-to:subject:subject:to:to; s=fm1;
	 t=1710343014; x=1710429414; bh=BP+7EIoBKRdbq+Ev2RuxCdiIUEfgqf3z
	DO6wWX+cFDI=; b=XR9qauVYjkcJjulKk/faRpU+7/FsDePS+Azs5bd/JLvVh9B8
	nJp+YlLZKlHKFapwNaCg1JEFAho3MUtdHuq6yn+CwFLJxj2U4JpacN4HPZMk2VdS
	rGipEIBs0rgRMgPbHYwy7CAKTMSIxbZbkOtaVP4+g++dwNweJynz3WddofqUk1Iz
	6hrT/LEfp5rxARIJuCV/WT6A3v6jTunELwXqTfQ6exDioCpzlSIRGP7JzT5dFsbc
	Dp6MGujVHJRFlRGlKo1HXjH1zzr2ek114lxfCGMdEEvmM/wYIAZ6yb7WBDZiy78u
	O79xiB21BryhfnUTqt16b1s0rPMIZqt9WrnTnQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:feedback-id:feedback-id
	:from:from:in-reply-to:message-id:mime-version:reply-to:subject
	:subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender
	:x-sasl-enc; s=fm1; t=1710343014; x=1710429414; bh=BP+7EIoBKRdbq
	+Ev2RuxCdiIUEfgqf3zDO6wWX+cFDI=; b=VOAG0iU2RMlD23E2FFIXTr48lIM1m
	CyMtyW7hambarOoZYUzNAwrgV9YDR04PnoxyOisTNmhdzxTn+hqMpCcpdJT6dkx+
	jnIMh7KZraff3CSmXu9aSH2TNTMZHv0es4QA3Q3WUSGr64dB+0ieBxcPTaqbm1IH
	9VAsQ2bh/fNfDy16ljyP6+z9qWlefXqSXZtb3z3m42yM0pWi4s7qtGvcDShhtLB8
	YucqAkqgVeT024ll7pgKWGA2fwJDT6W6veWtkwk3jqrJ+sVLl7ZLIpRtDJlfoE+b
	kh6lSNS+z8u9rW6Cqh9m/OVPvyoWyS14XHtR3Qg4qKyOmf45bnKTjL68Q==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrjeehgdejgecutefuodetggdotefrodftvf
    curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
    uegrihhlohhuthemuceftddtnecunecujfgurhephffvvefufffkofggtgfgsehtkeertd
    ertdejnecuhfhrohhmpeforghrvghkucforghrtgiihihkohifshhkihdqifpkrhgvtghk
    ihcuoehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmqe
    enucggtffrrghtthgvrhhnpefhfedvkedtiedvgfeiveetffevfefgtdehveettdevjedu
    ffevteehhfevgefhheenucffohhmrghinhepghhithhhuhgsrdgtohhmpdhgihhtlhgrsg
    drtghomhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhm
    pehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhm
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
To: xen-devel@lists.xenproject.org
Cc: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
Subject: [PATCH v5 0/7] MSI-X support with qemu in stubdomain, and other related changes
Date: Wed, 13 Mar 2024 16:16:05 +0100
Message-ID: 
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This series includes changes to make MSI-X working with Linux stubdomain and
especially Intel Wifi 6 AX210 card. This takes care of remaining reasons for
QEMU to access /dev/mem, but also the Intel Wifi card violating spec by putting
some registers on the same page as the MSI-X table.
Besides the stubdomain case (of which I care more), this is also necessary for
PCI-passthrough to work with lockdown enabled in dom0 (when QEMU runs in dom0).

See individual patches for details.

This series include also tests for MSI-X using new approach (by preventing QEMU
access to /dev/mem). But for it to work, it needs QEMU change that
makes use of the changes introduced here. It can be seen at
https://github.com/marmarek/qemu/commits/msix

Here is the pipeline that used the QEMU fork above:
https://gitlab.com/xen-project/people/marmarek/xen/-/pipelines/1211237368

Marek Marczykowski-Górecki (7):
  x86/msi: passthrough all MSI-X vector ctrl writes to device model
  x86/msi: Extend per-domain/device warning mechanism
  x86/hvm: Allow access to registers on the same page as MSI-X table
  automation: prevent QEMU access to /dev/mem in PCI passthrough tests
  automation: switch to a wifi card on ADL system
  [DO NOT APPLY] switch to qemu fork
  [DO NOT APPLY] switch to alternative artifact repo

 Config.mk                                           |   4 +-
 automation/gitlab-ci/build.yaml                     |   4 +-
 automation/gitlab-ci/test.yaml                      |   4 +-
 automation/scripts/qubes-x86-64.sh                  |   9 +-
 automation/tests-artifacts/alpine/3.18.dockerfile   |   7 +-
 automation/tests-artifacts/kernel/6.1.19.dockerfile |   2 +-
 xen/arch/x86/hvm/vmsi.c                             | 224 ++++++++++++-
 xen/arch/x86/include/asm/msi.h                      |  15 +-
 xen/arch/x86/msi.c                                  |  50 ++-
 xen/common/kernel.c                                 |   1 +-
 xen/include/public/features.h                       |   8 +-
 11 files changed, 308 insertions(+), 20 deletions(-)

base-commit: 03cf7ca23e0e876075954c558485b267b7d02406
-- 
git-series 0.9.1


From xen-devel-bounces@lists.xenproject.org Wed Mar 13 15:17:04 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 15:17:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692558.1079829 (Exim 4.92)
	(envelope-from )
	id 1rkQLm-000677-FB; Wed, 13 Mar 2024 15:17:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692558.1079829; Wed, 13 Mar 2024 15:17:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkQLm-00066z-C1; Wed, 13 Mar 2024 15:17:02 +0000
Received: by outflank-mailman (input) for mailman id 692558;
 Wed, 13 Mar 2024 15:17:01 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkQLl-00064u-ES
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 15:17:01 +0000
Received: from fout3-smtp.messagingengine.com (fout3-smtp.messagingengine.com
 [103.168.172.146]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id bbe0fe38-e14c-11ee-afdd-a90da7624cb6;
 Wed, 13 Mar 2024 16:16:59 +0100 (CET)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43])
 by mailfout.nyi.internal (Postfix) with ESMTP id 10DB9138009A;
 Wed, 13 Mar 2024 11:16:58 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163])
 by compute3.internal (MEProxy); Wed, 13 Mar 2024 11:16:58 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed,
 13 Mar 2024 11:16:56 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: bbe0fe38-e14c-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:from:from:in-reply-to
	:in-reply-to:message-id:mime-version:references:reply-to:subject
	:subject:to:to; s=fm1; t=1710343018; x=1710429418; bh=pRnc2ONRL/
	09dyz6m9s7vlkjBE0IxmuPAPPs7bOI7J0=; b=MQkO2ZK8/TD2NSfb5m2EqpQM06
	FsdmkCKynqUItmdWnUKk9aj2lCd+jfm5tyFVMw119Dxuo+ZB3znWigiZa8PkVGRg
	HxNH8LIA6yrUEiSlRg8sDHM+xLLqmdeTV61txYxkx6MUlN1/z/wcAHuNKApILYGO
	ZxehVKCO4EI8p9xqItOC0XBHdh5C/49GzMk2b32uZltRTI2nQckxKRbJujFKir9O
	uQS+vUjV63RdkqK9/XxN6vyvvtkovjdXsK2nZ/3ysnHADQRZuaQyzp98ZTiEcsR7
	UqTfDyK98WcpQf8R/Gs4e7iCx8txoXxSv/DWhFKddTgmmzkL/rh8xmPz2ogA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:feedback-id:feedback-id
	:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy
	:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1710343018; x=
	1710429418; bh=pRnc2ONRL/09dyz6m9s7vlkjBE0IxmuPAPPs7bOI7J0=; b=N
	JPOhODajrRVYHIX4XAvRhvndUabjXWg/OfWz+LMH99uTPd37VOajgv5NIS3jQgln
	G06p7jvwh+rl/eRW4s0A9tC5ucCJyJIh02DAvFnpLxRZLQ1h6gSW9AfLZYFaVL/y
	mFIiTvn3D3w2JYT8JJqrF5U1z3lPqQ7nRiWsnpuncYLil8moN4VwyLhQVU6mPGYn
	cwvRT4rePAxsEoOvaIZQNUPnp8gL7fKqr0/76TX37wVjQ/tzJRQY1cE69Ec1FnnF
	wBsVRr+Vnp+rKcNaT0KZXXMMuB+HEBvX03BHyPGThd2Evbu9pmohEODYidRGqdvh
	U+BMvKibR7aXesuhD7QGA==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrjeehgdejgecutefuodetggdotefrodftvf
    curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
    uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc
    fjughrpefhvfevufffkffojghfgggtgfesthekredtredtjeenucfhrhhomhepofgrrhgv
    khcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinh
    hvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepgfeu
    udehgfdvfeehhedujeehfeduveeugefhkefhheelgeevudetueeiudfggfffnecuvehluh
    hsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghk
    sehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
To: xen-devel@lists.xenproject.org
Cc: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Wei Liu 
Subject: [PATCH v5 2/7] x86/msi: Extend per-domain/device warning mechanism
Date: Wed, 13 Mar 2024 16:16:07 +0100
Message-ID: 
X-Mailer: git-send-email 2.43.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The arch_msix struct had a single "warned" field with a domid for which
warning was issued. Upcoming patch will need similar mechanism for few
more warnings, so change it to save a bit field of issued warnings.

Signed-off-by: Marek Marczykowski-Górecki 
---
Should I add also some helper for the boilerplate the handling requires
now? I tried some macro that also sets the bit field, but I couldn't get
it working. I guess I could make it working with a bitmask in a single
uint8_t - would that be preferred?

New in v5
---
 xen/arch/x86/include/asm/msi.h |  8 +++++++-
 xen/arch/x86/msi.c             |  9 +++++++--
 2 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/include/asm/msi.h b/xen/arch/x86/include/asm/msi.h
index 997ccb87be0c..19b1e6631fdf 100644
--- a/xen/arch/x86/include/asm/msi.h
+++ b/xen/arch/x86/include/asm/msi.h
@@ -217,7 +217,13 @@ struct arch_msix {
     int table_idx[MAX_MSIX_TABLE_PAGES];
     spinlock_t table_lock;
     bool host_maskall, guest_maskall;
-    domid_t warned;
+    domid_t warned_domid;
+    union {
+        uint8_t all;
+        struct {
+            bool maskall                   : 1;
+        } u;
+    } warned_kind;
 };
 
 void early_msi_init(void);
diff --git a/xen/arch/x86/msi.c b/xen/arch/x86/msi.c
index e721aaf5c001..6433df30bd60 100644
--- a/xen/arch/x86/msi.c
+++ b/xen/arch/x86/msi.c
@@ -364,9 +364,14 @@ static bool msi_set_mask_bit(struct irq_desc *desc, bool host, bool guest)
             domid_t domid = pdev->domain->domain_id;
 
             maskall = true;
-            if ( pdev->msix->warned != domid )
+            if ( pdev->msix->warned_domid != domid )
             {
-                pdev->msix->warned = domid;
+                pdev->msix->warned_domid = domid;
+                pdev->msix->warned_kind.all = 0;
+            }
+            if ( !pdev->msix->warned_kind.u.maskall )
+            {
+                pdev->msix->warned_kind.u.maskall = true;
                 printk(XENLOG_G_WARNING
                        "cannot mask IRQ %d: masking MSI-X on Dom%d's %pp\n",
                        desc->irq, domid, &pdev->sbdf);
-- 
git-series 0.9.1


From xen-devel-bounces@lists.xenproject.org Wed Mar 13 15:17:06 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 15:17:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692560.1079848 (Exim 4.92)
	(envelope-from )
	id 1rkQLq-0006eK-2b; Wed, 13 Mar 2024 15:17:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692560.1079848; Wed, 13 Mar 2024 15:17:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkQLp-0006e2-VZ; Wed, 13 Mar 2024 15:17:05 +0000
Received: by outflank-mailman (input) for mailman id 692560;
 Wed, 13 Mar 2024 15:17:03 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkQLn-0005e0-QN
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 15:17:03 +0000
Received: from fhigh6-smtp.messagingengine.com
 (fhigh6-smtp.messagingengine.com [103.168.172.157])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id bdc0fcfa-e14c-11ee-a1ee-f123f15fe8a2;
 Wed, 13 Mar 2024 16:17:02 +0100 (CET)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45])
 by mailfhigh.nyi.internal (Postfix) with ESMTP id 103E411400FA;
 Wed, 13 Mar 2024 11:17:01 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163])
 by compute5.internal (MEProxy); Wed, 13 Mar 2024 11:17:01 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed,
 13 Mar 2024 11:16:59 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: bdc0fcfa-e14c-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:from:from:in-reply-to
	:in-reply-to:message-id:mime-version:references:reply-to:subject
	:subject:to:to; s=fm1; t=1710343021; x=1710429421; bh=hZ6VYL08E0
	Yxr0n/W2twXlHVhmqK+fKxAH0QY/uH+Wo=; b=DtCO9B0Weh6roG52LY1gbplx+E
	pOHVHU3cIwZxGbAk67lMYRoZqPOKa5HpnoX0+DOkBBOXXqAuj1JEYNtJ8nAwkrGf
	MtQbKFbsA5vG4n4uczfKmbqco5URvdWXnnlrHB7dGUEbN1+gc34kmkD+6eVztq9l
	jqf5F27Q6V/8gwk1ciC6r+idj4LKELarJnGrBC7hKS9cOngLl1XtHVbjKdk25IoD
	HIgdk5tdVq6FHiN0eLYQTGH2qSwXjKq7t1usUiKK1X9Z80L0mEGW6T8svBfFkfcB
	GB5+Z84X/xZ08dcq+sDj+o7bSRz5PEdEeBX/70n+AgGzJz9mAK8PRQpkwxNQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:feedback-id:feedback-id
	:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy
	:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1710343021; x=
	1710429421; bh=hZ6VYL08E0Yxr0n/W2twXlHVhmqK+fKxAH0QY/uH+Wo=; b=X
	ip+AMW2NM5y535jgAklSMHFg8JKlfSPzv51c0gaL6qnf/pxO/4p7D9LcvBP/pF8m
	V6DbccH1hLj01GXmdELnpv5CjZ5vGH2oyRLqrRM5phBW/S6QJLQo1XrUTURxQTfA
	m/dNjfvOjdyViLq/6Z75zkvKgtgfBnq198JfWBLhAeKYEBOD1JIA9KRzUI7+S6Mn
	J+c353aAXSAolhZH0Q62h/oK3bX0SuI3s7GtT1Zh4IzSVXtVKMHHlsGKP9kAKRPl
	g9r9+FrWca1amYbE4afeQlgjlVYPA2VslWHQREK/ZFmgpZoIaQnkmELXJGaGRhmF
	BFxQ7ZTE6SrTclzRFwswg==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrjeehgdejgecutefuodetggdotefrodftvf
    curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
    uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc
    fjughrpefhvfevufffkffojghfgggtgfesthekredtredtjeenucfhrhhomhepofgrrhgv
    khcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinh
    hvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepgfeu
    udehgfdvfeehhedujeehfeduveeugefhkefhheelgeevudetueeiudfggfffnecuvehluh
    hsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghk
    sehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
To: xen-devel@lists.xenproject.org
Cc: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Stefano Stabellini ,
	Doug Goldstein 
Subject: [PATCH v5 4/7] automation: prevent QEMU access to /dev/mem in PCI passthrough tests
Date: Wed, 13 Mar 2024 16:16:09 +0100
Message-ID: <2ba54ff3f9021d5790a3bfccb27468c18fadc6bf.1710342968.git-series.marmarek@invisiblethingslab.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

/dev/mem access doesn't work in dom0 in lockdown and in stubdomain.
Simulate this environment with removing /dev/mem device node. Full test
for lockdown and stubdomain will come later, when all requirements will
be in place.

Signed-off-by: Marek Marczykowski-Górecki 
Acked-by: Stefano Stabellini 
---
This can be applied only after QEMU change is committed. Otherwise the
test will fail.
---
 automation/scripts/qubes-x86-64.sh | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/automation/scripts/qubes-x86-64.sh b/automation/scripts/qubes-x86-64.sh
index d81ed7b931cf..7eabc1bd6ad4 100755
--- a/automation/scripts/qubes-x86-64.sh
+++ b/automation/scripts/qubes-x86-64.sh
@@ -163,6 +163,8 @@ ifconfig eth0 up
 ifconfig xenbr0 up
 ifconfig xenbr0 192.168.0.1
 
+# ensure QEMU wont have access /dev/mem
+rm -f /dev/mem
 # get domU console content into test log
 tail -F /var/log/xen/console/guest-domU.log 2>/dev/null | sed -e \"s/^/(domU) /\" &
 xl create /etc/xen/domU.cfg
-- 
git-series 0.9.1


From xen-devel-bounces@lists.xenproject.org Wed Mar 13 15:17:06 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 15:17:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692561.1079856 (Exim 4.92)
	(envelope-from )
	id 1rkQLq-0006hd-GC; Wed, 13 Mar 2024 15:17:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692561.1079856; Wed, 13 Mar 2024 15:17:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkQLq-0006ga-7f; Wed, 13 Mar 2024 15:17:06 +0000
Received: by outflank-mailman (input) for mailman id 692561;
 Wed, 13 Mar 2024 15:17:04 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkQLo-0005e0-QW
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 15:17:04 +0000
Received: from fhigh6-smtp.messagingengine.com
 (fhigh6-smtp.messagingengine.com [103.168.172.157])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id be8de75e-e14c-11ee-a1ee-f123f15fe8a2;
 Wed, 13 Mar 2024 16:17:03 +0100 (CET)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.48])
 by mailfhigh.nyi.internal (Postfix) with ESMTP id 6CC4E11400FF;
 Wed, 13 Mar 2024 11:17:02 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163])
 by compute7.internal (MEProxy); Wed, 13 Mar 2024 11:17:02 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed,
 13 Mar 2024 11:17:01 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: be8de75e-e14c-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:from:from:in-reply-to
	:in-reply-to:message-id:mime-version:references:reply-to:subject
	:subject:to:to; s=fm1; t=1710343022; x=1710429422; bh=i5H8JidWWb
	TxxhBJM5jd/OPNyDg2YLsGie249e88IWE=; b=UKvjsY1vxQCEsNgn1NvSASZJoX
	pC8aLwCl5sLjzxT4OQ9Dg17DN2aJXfyEym/U2Kxndo4u7HtrzwzDPjedgB+qrNu5
	3E1JODtwBLtCb8h99WBxL32dvSYLfQjFLGpFSzzkAzp9EgunpsMaYbTVP7VUh4VE
	vLIur6Gbo9E8yz/lnlSzkSKNaj24DdYopTlgD8OHPHAZEbM3LPr1e1N/vKfu6V88
	swr0+L6LQPYMVwcL5Kq+9nmjoe9c7wojGI0PTfdLCUGGUPyZthsHnqx/rRO/kgtv
	Ll64MMjn4YG3ZkVHDxc4eLSm1W2YzXZcbAJLDHhOQum1xwtemkI8M+XrFU0A==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:feedback-id:feedback-id
	:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy
	:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1710343022; x=
	1710429422; bh=i5H8JidWWbTxxhBJM5jd/OPNyDg2YLsGie249e88IWE=; b=B
	Ryd5Gz71E/xqjdh+hLpHF1s6usSvZ7wmu8PgBUnfhM4MPSbUg7316DtNRP8cVTSl
	Oxut5vsoQBIohFQr0tDayu95L19ilUXuT2ZkL+eY869urylBE8h5apVFVOwsxQ9E
	Ek5F3My6NFkGVrobko4Soem7jEkmk0Tp7sAcK1wtMzVD+Mh1ghUOXH/ev3gd+RG9
	Lb3jqQptdiKGH4f568DgHnl3OcsiDQ7kDia4KzV8Kcfk0aVogblyZdRQXJXQVmrA
	MWLOt0/Fo+MIoCV1E/VJykslsIjFm4+nTkXX7KK6rkxnlYeNJJUgjk3BVeooZ50t
	QzcOz3w4NhgdKyECS99og==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrjeehgdejgecutefuodetggdotefrodftvf
    curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
    uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc
    fjughrpefhvfevufffkffojghfgggtgfesthekredtredtjeenucfhrhhomhepofgrrhgv
    khcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinh
    hvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepffei
    tdegveffteelvdeghffhvefghfefkeelheeujeejgedvvdfgffejuedtvdelnecuffhomh
    grihhnpehkvghrnhgvlhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgr
    mhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgsh
    hlrggsrdgtohhm
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
To: xen-devel@lists.xenproject.org
Cc: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Stefano Stabellini ,
	Doug Goldstein 
Subject: [PATCH v5 5/7] automation: switch to a wifi card on ADL system
Date: Wed, 13 Mar 2024 16:16:10 +0100
Message-ID: <30d445332e4cd70ce1d53a71d878107e43f128c5.1710342968.git-series.marmarek@invisiblethingslab.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Switch to a wifi card that has registers on a MSI-X page. This tests the
"x86/hvm: Allow writes to registers on the same page as MSI-X table"
feature. Switch it only for HVM test, because MSI-X adjacent write is
not supported on PV.

This requires also including drivers and firmware in system for tests.
Remove firmware unrelated to the test, to not increase initrd size too
much (all firmware takes over 100MB compressed).
And finally adjusts test script to handle not only eth0 as a test device,
but also wlan0 and connect it to the wifi network.

Signed-off-by: Marek Marczykowski-Górecki 
Reviewed-by: Stefano Stabellini 
---
This needs two new gitlab variables: WIFI_HW2_SSID and WIFI_HW2_PSK. I'll
provide them in private.

This change requires rebuilding test containers.

This can be applied only after QEMU change is committed. Otherwise the
test will fail.
---
 automation/gitlab-ci/test.yaml                      | 4 ++++
 automation/scripts/qubes-x86-64.sh                  | 7 +++++++
 automation/tests-artifacts/alpine/3.18.dockerfile   | 7 +++++++
 automation/tests-artifacts/kernel/6.1.19.dockerfile | 2 ++
 4 files changed, 20 insertions(+)

diff --git a/automation/gitlab-ci/test.yaml b/automation/gitlab-ci/test.yaml
index 8b7b2e4da92d..23a183fad967 100644
--- a/automation/gitlab-ci/test.yaml
+++ b/automation/gitlab-ci/test.yaml
@@ -193,6 +193,10 @@ adl-pci-pv-x86-64-gcc-debug:
 
 adl-pci-hvm-x86-64-gcc-debug:
   extends: .adl-x86-64
+  variables:
+    PCIDEV: "00:14.3"
+    WIFI_SSID: "$WIFI_HW2_SSID"
+    WIFI_PSK: "$WIFI_HW2_PSK"
   script:
     - ./automation/scripts/qubes-x86-64.sh pci-hvm 2>&1 | tee ${LOGFILE}
   needs:
diff --git a/automation/scripts/qubes-x86-64.sh b/automation/scripts/qubes-x86-64.sh
index 7eabc1bd6ad4..60498ef1e89a 100755
--- a/automation/scripts/qubes-x86-64.sh
+++ b/automation/scripts/qubes-x86-64.sh
@@ -94,6 +94,13 @@ on_reboot = "destroy"
     domU_check="
 set -x -e
 interface=eth0
+if [ -e /sys/class/net/wlan0 ]; then
+    interface=wlan0
+    set +x
+    wpa_passphrase "$WIFI_SSID" "$WIFI_PSK" > /etc/wpa_supplicant.conf
+    set -x
+    wpa_supplicant -B -iwlan0 -c /etc/wpa_supplicant.conf
+fi
 ip link set \"\$interface\" up
 timeout 30s udhcpc -i \"\$interface\"
 pingip=\$(ip -o -4 r show default|cut -f 3 -d ' ')
diff --git a/automation/tests-artifacts/alpine/3.18.dockerfile b/automation/tests-artifacts/alpine/3.18.dockerfile
index 9cde6c9ad4da..c323e266c7da 100644
--- a/automation/tests-artifacts/alpine/3.18.dockerfile
+++ b/automation/tests-artifacts/alpine/3.18.dockerfile
@@ -34,6 +34,13 @@ RUN \
   apk add udev && \
   apk add pciutils && \
   apk add libelf && \
+  apk add wpa_supplicant && \
+  # Select firmware for hardware tests
+  apk add linux-firmware-other && \
+  mkdir /lib/firmware-preserve && \
+  mv /lib/firmware/iwlwifi-so-a0-gf-a0* /lib/firmware-preserve/ && \
+  rm -rf /lib/firmware && \
+  mv /lib/firmware-preserve /lib/firmware && \
   \
   # Xen
   cd / && \
diff --git a/automation/tests-artifacts/kernel/6.1.19.dockerfile b/automation/tests-artifacts/kernel/6.1.19.dockerfile
index 3a4096780d20..84ed5dff23ae 100644
--- a/automation/tests-artifacts/kernel/6.1.19.dockerfile
+++ b/automation/tests-artifacts/kernel/6.1.19.dockerfile
@@ -32,6 +32,8 @@ RUN curl -fsSLO https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-"$LINUX_VERSI
     make xen.config && \
     scripts/config --enable BRIDGE && \
     scripts/config --enable IGC && \
+    scripts/config --enable IWLWIFI && \
+    scripts/config --enable IWLMVM && \
     cp .config .config.orig && \
     cat .config.orig | grep XEN | grep =m |sed 's/=m/=y/g' >> .config && \
     make -j$(nproc) bzImage && \
-- 
git-series 0.9.1


From xen-devel-bounces@lists.xenproject.org Wed Mar 13 15:17:08 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 15:17:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692562.1079869 (Exim 4.92)
	(envelope-from )
	id 1rkQLs-0007CF-QE; Wed, 13 Mar 2024 15:17:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692562.1079869; Wed, 13 Mar 2024 15:17:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkQLs-0007C2-Lv; Wed, 13 Mar 2024 15:17:08 +0000
Received: by outflank-mailman (input) for mailman id 692562;
 Wed, 13 Mar 2024 15:17:07 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkQLr-0005e0-1h
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 15:17:07 +0000
Received: from fhigh6-smtp.messagingengine.com
 (fhigh6-smtp.messagingengine.com [103.168.172.157])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id bff73287-e14c-11ee-a1ee-f123f15fe8a2;
 Wed, 13 Mar 2024 16:17:05 +0100 (CET)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44])
 by mailfhigh.nyi.internal (Postfix) with ESMTP id C60E311400DD;
 Wed, 13 Mar 2024 11:17:04 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163])
 by compute4.internal (MEProxy); Wed, 13 Mar 2024 11:17:04 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed,
 13 Mar 2024 11:17:02 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: bff73287-e14c-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-transfer-encoding
	:content-type:date:date:from:from:in-reply-to:in-reply-to
	:message-id:mime-version:references:reply-to:subject:subject:to
	:to; s=fm1; t=1710343024; x=1710429424; bh=EAaNxhwX2Xjwv3rkR/3PC
	xXHxt3VIaaNGAHnw+G6qes=; b=acADtP9QRyyn8PJwbdwhm88aXtQqPHU12Fbbj
	N8frPzd8tdm/OhDuIgUQtsKehufgu9wixeyCya6oEkPL3txyGY2dTMU3uot46Xbk
	0Hg/MJEjfZB6L49seBY9knk9daX33ysIdzcI/0LaG/c9jeShzZrsj6j4jsTccEpX
	LwEt39OltxmF3Sve1UcSsdpD1SA2LdtfE2iLlmk3NP8DYolmugiG37ssjGL4VSDA
	Z/J/SgEQOZKU93htoIs8yXLHDLD4zD39lRskI2hHsHCXf6ZsUMszSeE9JlBmCIEm
	Ox05/eyqS+sbhkAZ1MMmddWzWjq+0fzQ9mvBCKkOEdA27nZaQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-transfer-encoding
	:content-type:date:date:feedback-id:feedback-id:from:from
	:in-reply-to:in-reply-to:message-id:mime-version:references
	:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy
	:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1710343024; x=
	1710429424; bh=EAaNxhwX2Xjwv3rkR/3PCxXHxt3VIaaNGAHnw+G6qes=; b=U
	S59gh9E6ezjwJybiFwfZyFajpPZ+WRq5lP68XP4idnLSc5mCKqg0A5VVAuR2BK79
	SuCqxi6ZDC4MkaYYbP6eUFbZw32J/BTHJszVgaf+72cck0NZGMps3qi1peD7Txkc
	Ka6CU+55Kkv4wrTntfFTcJykXqXNfg9A5qRwMrazk0vG6pPPLiDQsTHIKmkdL4Cz
	cXt0TAO4tFLGaP2K/Lm06TDcs9Gy7NbK0pzkveauX0sqkdU9OJMMSRiP2YRf88lp
	nkHmVBlIQIrk58s9aeskEA3EvtqYdPNH74Ku9DUg+FVYcI0UvpLrJ0TwLbWss+0Y
	JxIhyMC/FopTPrAL6noIg==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrjeehgdejgecutefuodetggdotefrodftvf
    curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
    uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc
    fjughrpefhvfevufffkffojghfggfgsedtkeertdertdejnecuhfhrohhmpeforghrvghk
    ucforghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvh
    hishhisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpeegtedt
    ieeghfekhfefgedvueeivddtffekledtiedvgfetleeuuefhteelveeugeenucffohhmrg
    hinhepgigvnhdrohhrghdpghhithhhuhgsrdgtohhmnecuvehluhhsthgvrhfuihiivgep
    tdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghksehinhhvihhsihgslh
    gvthhhihhnghhslhgrsgdrtghomh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
To: xen-devel@lists.xenproject.org
Cc: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini ,
	Wei Liu 
Subject: [PATCH v5 6/7] [DO NOT APPLY] switch to qemu fork
Date: Wed, 13 Mar 2024 16:16:11 +0100
Message-ID: 
X-Mailer: git-send-email 2.43.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

This makes tests to use patched QEMU, to actually test the new behavior.
---
 Config.mk | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Config.mk b/Config.mk
index a962f095ca16..5e220a1284e4 100644
--- a/Config.mk
+++ b/Config.mk
@@ -220,8 +220,8 @@ endif
 OVMF_UPSTREAM_URL ?= https://xenbits.xen.org/git-http/ovmf.git
 OVMF_UPSTREAM_REVISION ?= ba91d0292e593df8528b66f99c1b0b14fadc8e16
 
-QEMU_UPSTREAM_URL ?= https://xenbits.xen.org/git-http/qemu-xen.git
-QEMU_UPSTREAM_REVISION ?= master
+QEMU_UPSTREAM_URL ?= https://github.com/marmarek/qemu
+QEMU_UPSTREAM_REVISION ?= origin/msix
 
 MINIOS_UPSTREAM_URL ?= https://xenbits.xen.org/git-http/mini-os.git
 MINIOS_UPSTREAM_REVISION ?= b6a5b4d72b88e5c4faed01f5a44505de022860fc
-- 
git-series 0.9.1


From xen-devel-bounces@lists.xenproject.org Wed Mar 13 15:17:11 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 15:17:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692563.1079879 (Exim 4.92)
	(envelope-from )
	id 1rkQLv-0007WP-4r; Wed, 13 Mar 2024 15:17:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692563.1079879; Wed, 13 Mar 2024 15:17:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkQLu-0007W9-Vz; Wed, 13 Mar 2024 15:17:10 +0000
Received: by outflank-mailman (input) for mailman id 692563;
 Wed, 13 Mar 2024 15:17:08 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkQLs-0005e0-Ro
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 15:17:08 +0000
Received: from fout3-smtp.messagingengine.com (fout3-smtp.messagingengine.com
 [103.168.172.146]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c10a0061-e14c-11ee-a1ee-f123f15fe8a2;
 Wed, 13 Mar 2024 16:17:07 +0100 (CET)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.47])
 by mailfout.nyi.internal (Postfix) with ESMTP id 961B41380063;
 Wed, 13 Mar 2024 11:17:06 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163])
 by compute6.internal (MEProxy); Wed, 13 Mar 2024 11:17:06 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed,
 13 Mar 2024 11:17:04 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c10a0061-e14c-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-transfer-encoding
	:content-type:date:date:from:from:in-reply-to:in-reply-to
	:message-id:mime-version:references:reply-to:subject:subject:to
	:to; s=fm1; t=1710343026; x=1710429426; bh=rqAlWJ788XGq8tNuFWR/8
	CwesBByjaWaSAP4BkMnyEs=; b=KmXybWfqPZ5FXd7uhqw9z5UweMLZ+OASdIDdd
	2CAloPqIaW5uyVPavfKwG9NJqYo6q3FIW4GQL1yvFmdkeB6nhGHp06QLV60UtBiG
	fkcdVQmAysQO/suw1eNMaWsDATj+FMWwa2OZvQS3cWSYwRGCSWNkr+a+J1crgkYM
	NSTIVOdykSMhM8nStI7iNfvKaEAiunUE/1kfRiuEykZnO3B18zlvhe7o+Z5NOBbj
	p5HuzYR0Fg/nMNXaf2Ex1Vdz8/Pm6eEnU9XUybk+++LJDRwyVSey6MWr6aVkQ19Z
	9nxyjMCan//Pd//C36ilSrJmGlnPNbdO+FRNxFMwNhhk8q5TQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-transfer-encoding
	:content-type:date:date:feedback-id:feedback-id:from:from
	:in-reply-to:in-reply-to:message-id:mime-version:references
	:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy
	:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1710343026; x=
	1710429426; bh=rqAlWJ788XGq8tNuFWR/8CwesBByjaWaSAP4BkMnyEs=; b=I
	EpOTZre72V/R9KM4M3B5tt+XtrdmVc5AMZGW5iUIfjy/o/loE4wInAV6+Sjf/9Jg
	W8Uv0oY9A1DyNneY7JP8HYQlcCHQ0xqMcutK2L5JF8IHsgB3i+rGC9Wb3CD+FcU/
	RSZNV5LgBs1j0Pk+Q08O6PGF8aIaIfnXMb6+WVw1HcY4nekZln414ijY1/e7we+H
	LNL9cda5nreRVoUTlv5Ia37Ptd1zwzOuaAsxm1qo72s2UGL7Urjms1NHAZ2F8s+f
	QUD4Xjj5/s82QiECZjMv/LhHpUo35Y807YIBiTYANc1yQAQh1q9TigGEla7pjEGg
	wkox0OjTJOVsLSho0jmFw==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrjeehgdejgecutefuodetggdotefrodftvf
    curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
    uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc
    fjughrpefhvfevufffkffojghfggfgsedtkeertdertdejnecuhfhrohhmpeforghrvghk
    ucforghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvh
    hishhisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpeeuteeh
    gfeiheehfedtueeludfhgfeileeujefhgffgieeiveethfeffffffedtheenucffohhmrg
    hinhepghhithhlrggsrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghm
    pehmrghilhhfrhhomhepmhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslh
    grsgdrtghomh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
To: xen-devel@lists.xenproject.org
Cc: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Doug Goldstein ,
	Stefano Stabellini 
Subject: [PATCH v5 7/7] [DO NOT APPLY] switch to alternative artifact repo
Date: Wed, 13 Mar 2024 16:16:12 +0100
Message-ID: <6e8f9bd56b241e101b014f748888010adf280da5.1710342968.git-series.marmarek@invisiblethingslab.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

For testing, switch to my containers registry that includes containers
rebuilt with changes in this series.
---
 automation/gitlab-ci/build.yaml | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-ci/build.yaml
index 6d2cb18b8883..7dafbf144494 100644
--- a/automation/gitlab-ci/build.yaml
+++ b/automation/gitlab-ci/build.yaml
@@ -320,7 +320,7 @@ qemu-system-ppc64-8.1.0-ppc64-export:
 
 alpine-3.18-rootfs-export:
   extends: .test-jobs-artifact-common
-  image: registry.gitlab.com/xen-project/xen/tests-artifacts/alpine:3.18
+  image: registry.gitlab.com/xen-project/people/marmarek/xen/tests-artifacts/alpine:3.18
   script:
     - mkdir binaries && cp /initrd.tar.gz binaries/initrd.tar.gz
   artifacts:
@@ -331,7 +331,7 @@ alpine-3.18-rootfs-export:
 
 kernel-6.1.19-export:
   extends: .test-jobs-artifact-common
-  image: registry.gitlab.com/xen-project/xen/tests-artifacts/kernel:6.1.19
+  image: registry.gitlab.com/xen-project/people/marmarek/xen/tests-artifacts/kernel:6.1.19
   script:
     - mkdir binaries && cp /bzImage binaries/bzImage
   artifacts:
-- 
git-series 0.9.1


From xen-devel-bounces@lists.xenproject.org Wed Mar 13 15:47:16 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 15:47:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692584.1079889 (Exim 4.92)
	(envelope-from )
	id 1rkQon-0001Oj-Br; Wed, 13 Mar 2024 15:47:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692584.1079889; Wed, 13 Mar 2024 15:47:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkQon-0001Oc-8v; Wed, 13 Mar 2024 15:47:01 +0000
Received: by outflank-mailman (input) for mailman id 692584;
 Wed, 13 Mar 2024 15:35:16 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkQdQ-0007MK-Ms
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 15:35:16 +0000
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com
 [2a00:1450:4864:20::630])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 49d8cea8-e14f-11ee-afdd-a90da7624cb6;
 Wed, 13 Mar 2024 16:35:15 +0100 (CET)
Received: by mail-ej1-x630.google.com with SMTP id
 a640c23a62f3a-a466a256726so11207066b.1
 for ; Wed, 13 Mar 2024 08:35:15 -0700 (PDT)
Received: from EMEAENGAAD91498.citrite.net ([217.156.233.157])
 by smtp.gmail.com with ESMTPSA id
 lt9-20020a170906fa8900b00a45c4d3ee11sm4930248ejb.123.2024.03.13.08.35.13
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 13 Mar 2024 08:35:14 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 49d8cea8-e14f-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1710344114; x=1710948914; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:from:to:cc:subject:date:message-id:reply-to;
        bh=hRQqdzncpSGt6fbxgjyMV5po9/h6eRl9V9eIxuTQ6WM=;
        b=bl4Dt/huZinBzY2e1nMqXFh7DdwOewEBuT3hRQdi2P3QH/LxBQFO/Os6gyzcLtfZP7
         RTJ2k2f3D+KLb0lxPhBNE592gL7WDQGY+AjVyjaEcdNsvkOjZTSVRtlsLETJzcFSCcS2
         niGyuvdEHK3IthqumxO0IKJpGzLXmJJSWEUPM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710344114; x=1710948914;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=hRQqdzncpSGt6fbxgjyMV5po9/h6eRl9V9eIxuTQ6WM=;
        b=J18TOK0ThQhkE1F8AIpTlIi8md+PMPz/+KAIgfSqA2xqA0BuNTdoSOgbLWd2LpCJgZ
         haGxT0fi+unuNv2FVl4W8G0ss6lK1aIWeu60ffF3rn4s96OU+ybTsqqGHnFVJcGn5k6/
         7xN1vuwhiI7uR+2JN6qFlapVePvBlL8sHJ0tMvnbLKMRSQSX9BPBLisieCwBHUunh8oV
         eEXZ3PsPjscN3wkZt2irhwfRAVZv7GP9pbfTMlZKcfeZaUzWVoBR9G2TM3kH57Apw6Qv
         t+Mkpmyf/B10FAl5w2I+P3w2+6tj2yOHVhZQ9gGNBXHvUSBvp56FHOE0+N4hCnJFwEEI
         7F4A==
X-Gm-Message-State: AOJu0YymwlMxOyRp7tQ7jbm67OjQagGdHQO58kTDgWXhcci7Qx0M4G6R
	TLyCZKHQ1ndb/fyhaKDwuJneL/NA/gjONJ1snTtb6XyNiA3wxx28hK5fwetetx9c5oc3Jwdk1Fg
	LjSY=
X-Google-Smtp-Source: AGHT+IEwiuP76hhoS6jiTUnmlM0RhWgGzAerXqT9OvHGPPKxYJR3T319S28euVfQtzUbbgmooWxizQ==
X-Received: by 2002:a17:907:2da2:b0:a46:4bd4:df86 with SMTP id gt34-20020a1709072da200b00a464bd4df86mr3359956ejc.3.1710344114354;
        Wed, 13 Mar 2024 08:35:14 -0700 (PDT)
From: Matthew Barnes 
To: Xen-devel 
Cc: Matthew Barnes ,
	Jan Beulich ,
	Wei Liu ,
	Anthony PERARD 
Subject: [XEN PATCH] tools: add x2APIC entries in MADT based on APIC ID
Date: Wed, 13 Mar 2024 15:35:11 +0000
Message-Id: 
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

libacpi is a tool that is used by libxl (for PVH guests) and hvmloader
(for HVM guests) to construct ACPI tables for guests.

Currently, libacpi only uses APIC entries to enumerate processors for
guests in the MADT.

The APIC ID field in APIC entries is an octet big, which is fine for
xAPIC IDs, but not so for sufficiently large x2APIC IDs.

This patch scans each APIC ID before constructing the MADT, and uses the
x2APIC entry for each vCPU whose APIC ID exceeds the size limit imposed
by regular APIC entries.

Signed-off-by: Matthew Barnes 
---
 tools/libacpi/acpi2_0.h | 13 +++++++
 tools/libacpi/build.c   | 75 ++++++++++++++++++++++++++++++-----------
 2 files changed, 68 insertions(+), 20 deletions(-)

diff --git a/tools/libacpi/acpi2_0.h b/tools/libacpi/acpi2_0.h
index 6dfa939a8c0c..10e567686fe6 100644
--- a/tools/libacpi/acpi2_0.h
+++ b/tools/libacpi/acpi2_0.h
@@ -344,6 +344,7 @@ struct acpi_20_waet {
 #define ACPI_IO_SAPIC                       0x06
 #define ACPI_PROCESSOR_LOCAL_SAPIC          0x07
 #define ACPI_PLATFORM_INTERRUPT_SOURCES     0x08
+#define ACPI_PROCESSOR_LOCAL_X2APIC         0x09
 
 /*
  * APIC Structure Definitions.
@@ -360,6 +361,18 @@ struct acpi_20_madt_lapic {
     uint32_t flags;
 };
 
+/*
+ * Processor Local x2APIC Structure Definition.
+ */
+struct acpi_20_madt_x2apic {
+    uint8_t  type;              /* Must refer to x2APIC type (0x09) */
+    uint8_t  length;            /* Must be length of x2APIC struct in bytes (0x10) */
+    uint16_t reserved;          /* Must be zero */
+    uint32_t apic_id;           /* Processor's local x2APIC ID */
+    uint32_t flags;             /* Same as Local APIC flags */
+    uint32_t acpi_processor_id; /* Refers to a processor device used to associate the X2APIC structure with */
+};
+
 /*
  * Local APIC Flags.  All other bits are reserved and must be 0.
  */
diff --git a/tools/libacpi/build.c b/tools/libacpi/build.c
index 2f29863db154..5b0fd6584b30 100644
--- a/tools/libacpi/build.c
+++ b/tools/libacpi/build.c
@@ -63,6 +63,27 @@ static void set_checksum(
     p[checksum_offset] = -sum;
 }
 
+static unsigned calculate_madt_size(const struct acpi_config *config)
+{
+    uint32_t apic_id;
+    unsigned i, size;
+
+    size  = sizeof(struct acpi_20_madt);
+    size += sizeof(struct acpi_20_madt_intsrcovr) * 16;
+    size += sizeof(struct acpi_20_madt_ioapic);
+
+    for ( i = 0; i < config->hvminfo->nr_vcpus; i++ )
+    {
+        apic_id = config->lapic_id(i);
+        if ( apic_id < 255 )
+            size += sizeof(struct acpi_20_madt_lapic);
+        else
+            size += sizeof(struct acpi_20_madt_x2apic);
+    }
+
+    return size;
+}
+
 static struct acpi_20_madt *construct_madt(struct acpi_ctxt *ctxt,
                                            const struct acpi_config *config,
                                            struct acpi_info *info)
@@ -70,18 +91,14 @@ static struct acpi_20_madt *construct_madt(struct acpi_ctxt *ctxt,
     struct acpi_20_madt           *madt;
     struct acpi_20_madt_intsrcovr *intsrcovr;
     struct acpi_20_madt_ioapic    *io_apic;
-    struct acpi_20_madt_lapic     *lapic;
+    void                          *apicid_entry;
     const struct hvm_info_table   *hvminfo = config->hvminfo;
-    int i, sz;
+    unsigned i, sz;
 
     if ( config->lapic_id == NULL )
         return NULL;
 
-    sz  = sizeof(struct acpi_20_madt);
-    sz += sizeof(struct acpi_20_madt_intsrcovr) * 16;
-    sz += sizeof(struct acpi_20_madt_ioapic);
-    sz += sizeof(struct acpi_20_madt_lapic) * hvminfo->nr_vcpus;
-
+    sz = calculate_madt_size(config);
     madt = ctxt->mem_ops.alloc(ctxt, sz, 16);
     if (!madt) return NULL;
 
@@ -134,27 +151,45 @@ static struct acpi_20_madt *construct_madt(struct acpi_ctxt *ctxt,
         io_apic->ioapic_id   = config->ioapic_id;
         io_apic->ioapic_addr = config->ioapic_base_address;
 
-        lapic = (struct acpi_20_madt_lapic *)(io_apic + 1);
+        apicid_entry = io_apic + 1;
     }
     else
-        lapic = (struct acpi_20_madt_lapic *)(madt + 1);
+        apicid_entry = madt + 1;
 
     info->nr_cpus = hvminfo->nr_vcpus;
-    info->madt_lapic0_addr = ctxt->mem_ops.v2p(ctxt, lapic);
+    info->madt_lapic0_addr = ctxt->mem_ops.v2p(ctxt, apicid_entry);
     for ( i = 0; i < hvminfo->nr_vcpus; i++ )
     {
-        memset(lapic, 0, sizeof(*lapic));
-        lapic->type    = ACPI_PROCESSOR_LOCAL_APIC;
-        lapic->length  = sizeof(*lapic);
-        /* Processor ID must match processor-object IDs in the DSDT. */
-        lapic->acpi_processor_id = i;
-        lapic->apic_id = config->lapic_id(i);
-        lapic->flags = (test_bit(i, hvminfo->vcpu_online)
-                        ? ACPI_LOCAL_APIC_ENABLED : 0);
-        lapic++;
+        uint32_t apic_id = config->lapic_id(i);
+        if ( apic_id < 255 )
+        {
+            struct acpi_20_madt_lapic *lapic = apicid_entry;
+            memset(lapic, 0, sizeof(*lapic));
+            lapic->type    = ACPI_PROCESSOR_LOCAL_APIC;
+            lapic->length  = sizeof(*lapic);
+            /* Processor ID must match processor-object IDs in the DSDT. */
+            lapic->acpi_processor_id = i;
+            lapic->apic_id = apic_id;
+            lapic->flags = (test_bit(i, hvminfo->vcpu_online)
+                            ? ACPI_LOCAL_APIC_ENABLED : 0);
+            apicid_entry = lapic + 1;
+        }
+        else
+        {
+            struct acpi_20_madt_x2apic *x2apic = apicid_entry;
+            memset(x2apic, 0, sizeof(*x2apic));
+            x2apic->type    = ACPI_PROCESSOR_LOCAL_X2APIC;
+            x2apic->length  = sizeof(*x2apic);
+            x2apic->apic_id = apic_id;
+            x2apic->flags   = (test_bit(i, hvminfo->vcpu_online)
+                                ? ACPI_LOCAL_APIC_ENABLED : 0);
+            /* Processor ID must match processor-object IDs in the DSDT. */
+            x2apic->acpi_processor_id = i;
+            apicid_entry = x2apic + 1;
+        }
     }
 
-    madt->header.length = (unsigned char *)lapic - (unsigned char *)madt;
+    madt->header.length = (unsigned char *)apicid_entry - (unsigned char *)madt;
     set_checksum(madt, offsetof(struct acpi_header, checksum),
                  madt->header.length);
     info->madt_csum_addr =
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed Mar 13 15:53:31 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 15:53:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692589.1079899 (Exim 4.92)
	(envelope-from )
	id 1rkQv1-00049M-WC; Wed, 13 Mar 2024 15:53:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692589.1079899; Wed, 13 Mar 2024 15:53:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkQv1-00049F-Ta; Wed, 13 Mar 2024 15:53:27 +0000
Received: by outflank-mailman (input) for mailman id 692589;
 Wed, 13 Mar 2024 15:53:27 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkQv1-000499-Ai
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 15:53:27 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d2f91c53-e151-11ee-a1ee-f123f15fe8a2;
 Wed, 13 Mar 2024 16:53:25 +0100 (CET)
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 by support.bugseng.com (Postfix) with ESMTPA id D24314EE0738;
 Wed, 13 Mar 2024 16:53:23 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d2f91c53-e151-11ee-a1ee-f123f15fe8a2
MIME-Version: 1.0
Date: Wed, 13 Mar 2024 16:53:23 +0100
From: Nicola Vetrini 
To: xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com,
 ayan.kumar.halder@amd.com, consulting@bugseng.com, jbeulich@suse.com,
 andrew.cooper3@citrix.com, roger.pau@citrix.com, bertrand.marquis@arm.com,
 julien@xen.org, Simone Ballarin , Doug
 Goldstein , George Dunlap , Wei
 Liu 
Subject: Re: [XEN PATCH v2] automation/eclair_analysis: deviate certain macros
 for Rule 20.12
In-Reply-To: <7bc72f6ccd858e0405d62d49c32449e3b5abd790.1707996317.git.nicola.vetrini@bugseng.com>
References: <7bc72f6ccd858e0405d62d49c32449e3b5abd790.1707996317.git.nicola.vetrini@bugseng.com>
Message-ID: <265e5e357db58916774f42265f39ce4a@bugseng.com>
X-Sender: nicola.vetrini@bugseng.com
Organization: BUGSENG s.r.l.
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit

On 2024-02-15 14:06, Nicola Vetrini wrote:
> Certain macros are allowed to violate the Rule, since their meaning and
> intended use is well-known to all Xen developers.
> 
> Variadic macros that rely on the GCC extension for removing a trailing
> comma when token pasting the variable argument are similarly
> well-understood and therefore allowed.
> 
> No functional change.
> 
> Signed-off-by: Nicola Vetrini 
> ---
> Changes in v2:
> - Restrict deviation for GENERATE_CASE to vcpreg.c.
> - Improve deviation justifications.
> ---
>  .../eclair_analysis/ECLAIR/deviations.ecl     | 20 +++++++++++++++++
>  docs/misra/deviations.rst                     | 22 +++++++++++++++++++
>  2 files changed, 42 insertions(+)
> 

Hi,

this patch has an R-by from Stefano. Is there something preventing this 
from being committed?

-- 
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)


From xen-devel-bounces@lists.xenproject.org Wed Mar 13 16:11:33 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 16:11:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692593.1079914 (Exim 4.92)
	(envelope-from )
	id 1rkRCQ-0000Ya-Q1; Wed, 13 Mar 2024 16:11:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692593.1079914; Wed, 13 Mar 2024 16:11:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkRCQ-0000Xj-Mm; Wed, 13 Mar 2024 16:11:26 +0000
Received: by outflank-mailman (input) for mailman id 692593;
 Wed, 13 Mar 2024 16:11:25 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkRCP-0000UR-Cd
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 16:11:25 +0000
Received: from mail-oa1-x2b.google.com (mail-oa1-x2b.google.com
 [2001:4860:4864:20::2b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 557e58db-e154-11ee-a1ee-f123f15fe8a2;
 Wed, 13 Mar 2024 17:11:23 +0100 (CET)
Received: by mail-oa1-x2b.google.com with SMTP id
 586e51a60fabf-221ce6cac3aso32427fac.2
 for ; Wed, 13 Mar 2024 09:11:23 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 557e58db-e154-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1710346282; x=1710951082; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=qa+JtwuG1/muOjjdLS6ORMUHx5CqOTSRnGW/7l8J48k=;
        b=SiIDJooFeq3c9V4CUpY2PXxLF6bOaHbVQF47sKcrKiB+qVQjKCr7xc4IGhzUmHUg2r
         g763kgQc5Y+aEJRWA4phDWOMKqCUf3XCi95dkreYFL69qmmAy2hS7wXcGh6VREaRmjQa
         hD0oSEJYnjZ9S0HwbTf4rHZiwPcAjzdEpCyTs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710346282; x=1710951082;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=qa+JtwuG1/muOjjdLS6ORMUHx5CqOTSRnGW/7l8J48k=;
        b=OIuHJ+CRJR/bNjVsiAEekJFunJ12ay1E6eaf/30mWqvo7r2BZ1KSt5OjMAW04bqQbE
         DWjkKSnEC93MYOa/1sbtbVBShrBv+nhAefICnAChQwfzcGWEiimRTonwYGH5MjC0HWo4
         k8Q9Og60OyWLTLuaQbj1TXjhIRLyfhukJG+MU2qLCX9Rh/anVCWMKkEQvjHWSqPhoQoV
         e7x9mjkh9r7+5KNKzEOYwPUsDGeH5kk/UW80LF5c/LqDVqoe+zADGHT2ICQfxM+fz57O
         nymXpY+bgcye2wYZLeez6lCn5GnLKwseXs5w0a/jtvflsiDuRoCAf9D9SFdnKEXxYuB7
         ePlQ==
X-Gm-Message-State: AOJu0Yyxil87J3geaNMoaHTrefY7QtsxDbVhIjX+UtrwynGlxNEdDVeo
	aSa3ZPUgwOddKO+sT8RaCiqgLeY18hSboKvuma/dFvrkbplo+5y/CLma8QlaSjKMgAQGcHsbndW
	q9Z3sczKcZxgurGbL0cte7qrknDCTIR84eoHX9RA/QOjGr96A
X-Google-Smtp-Source: AGHT+IEa1XtG3OA1SjJ9vvTyYsS0bqy3yGjFPEnoQs3oKWDkme/oM1HsKBJ3UJ06kfKoEaqU6oOT7MsGPVbyr6dJBAI=
X-Received: by 2002:a05:6871:687:b0:221:42a1:9457 with SMTP id
 l7-20020a056871068700b0022142a19457mr12657581oao.9.1710346281915; Wed, 13 Mar
 2024 09:11:21 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: George Dunlap 
Date: Wed, 13 Mar 2024 16:11:11 +0000
Message-ID: 
Subject: Re: Mailing list changes
To: Kelly Choi 
Cc: xen-devel , xen-users@lists.xenproject.org, 
	advisory-board@lists.xenproject.org, committers@xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Mar 13, 2024 at 2:59=E2=80=AFPM Kelly Choi  w=
rote:
>
> Hi everyone,
>
> We recently discussed some mailing list changes in our last community cal=
l.
>
> Issue:
>
> Lists.xenproject.org software is outdated, DKIM, DMARC, ARC is no longer =
sufficient, and there's no clear update path from Mailman2 to Mailman3.
>
> Potential solution:
>
> Host them at https://subspace.kernel.org/ due to us being part of the Lin=
ux Foundation
> No additional cost to the project

It should also be pointed out that the list address wouldn't change;
on our end we'd point the MX for lists.xenproject.org to kernel.org's
mail servers (or something like that).

 -George


From xen-devel-bounces@lists.xenproject.org Wed Mar 13 16:31:43 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 16:31:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692623.1079938 (Exim 4.92)
	(envelope-from )
	id 1rkRVv-0005bb-Jy; Wed, 13 Mar 2024 16:31:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692623.1079938; Wed, 13 Mar 2024 16:31:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkRVv-0005bU-Gx; Wed, 13 Mar 2024 16:31:35 +0000
Received: by outflank-mailman (input) for mailman id 692623;
 Wed, 13 Mar 2024 16:31:34 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkRVu-0005bO-6S
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 16:31:34 +0000
Received: from mail-oo1-xc30.google.com (mail-oo1-xc30.google.com
 [2607:f8b0:4864:20::c30])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 266263c9-e157-11ee-afdd-a90da7624cb6;
 Wed, 13 Mar 2024 17:31:32 +0100 (CET)
Received: by mail-oo1-xc30.google.com with SMTP id
 006d021491bc7-5a21859a4b8so1432974eaf.0
 for ; Wed, 13 Mar 2024 09:31:32 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 266263c9-e157-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1710347491; x=1710952291; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=umgvJmcBaleLQI+t61eBfjeJyu3f6nhm74M4JR/otFc=;
        b=VJhp1/BGAmH/9nQ0DAP1OajFZ0WM9O12SSnRaZiMZY6fsJHhHmkAkdGjIZz9GcqkIG
         U8cYnKUX9QrupmWx7JKqfLOLWmr0svHuQbrnG5hHqeqXRawXhSQXvIl/0KJOupIETmwx
         SHVnIVd+hWptc5XSHqdqwfRjJmSKAz3uhm8tg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710347491; x=1710952291;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=umgvJmcBaleLQI+t61eBfjeJyu3f6nhm74M4JR/otFc=;
        b=OxVFI1wAXWEZ24CYQK0w0zzBUyVb5RGBIbC6hywqIKXSE65Bi0Xs776ZGSA5b4LiDS
         0CEylNkd8wI8hWVjHBXF8HaoCUoBTiTZwL3Xi8Rn9w7k2GIxeShzO1AwcbTDA+bWWS0V
         5Pgi4A1Nj/zf+dW88ft0oZFA7TYN0E9LVTGZTo6IfcQoOlYGWlxH7ks7lSNA8rYQ7ZS+
         4Jz5MT+gKjNn6DMa/VBygCMRbgGR4Kcge4rOyYGkXPQsebpDCKVx7K0PDcX+uE/+G1Hl
         LcCv0fxWQuWtcgwwxqzwe8L2ogz0uVGPe89i9GX7Tv+apczdb5xZlJWnycKRP7NaLacH
         sHhg==
X-Gm-Message-State: AOJu0YwaDXtv8/oJ1Zr3UPW//Qq+lBEJvcyEhRTCOnemnI5USAORFmG3
	AzUaVBPVLuw8cLcl1XZBuamsbIBxDRLTTEDPZKM7bCDlSMcQeVidMlsIzhMV8TGEVJZRMSngXJL
	BAt+bRIfe30pQh9rTUaPjWdbujEtuSa0XJGKg5w==
X-Google-Smtp-Source: AGHT+IEH2gZXJs2GYm9YIzznaX9/VCtR9VxyDnXjn8f48/KO/KwdpvpJI7e2unbFpW4Eq8/kv/xqtdumDvLgiYEmSfg=
X-Received: by 2002:a05:6870:f14e:b0:221:8fd9:284c with SMTP id
 l14-20020a056870f14e00b002218fd9284cmr3956496oac.1.1710347491259; Wed, 13 Mar
 2024 09:31:31 -0700 (PDT)
MIME-Version: 1.0
References:  <3daef84c-47dd-4a6b-9984-402e997598dc@suse.com>
In-Reply-To: <3daef84c-47dd-4a6b-9984-402e997598dc@suse.com>
From: George Dunlap 
Date: Wed, 13 Mar 2024 16:31:20 +0000
Message-ID: 
Subject: Re: [PATCH v4] x86/PoD: tie together P2M update and increment of
 entry count
To: Jan Beulich 
Cc: "xen-devel@lists.xenproject.org" , 
	Andrew Cooper , Wei Liu , 
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Mar 13, 2024 at 2:00=E2=80=AFPM Jan Beulich  wro=
te:
>
> When not holding the PoD lock across the entire region covering P2M
> update and stats update, the entry count - if to be incorrect at all -
> should indicate too large a value in preference to a too small one, to
> avoid functions bailing early when they find the count is zero. However,
> instead of moving the increment ahead (and adjust back upon failure),
> extend the PoD-locked region.
>
> Fixes: 99af3cd40b6e ("x86/mm: Rework locking in the PoD layer")
> Signed-off-by: Jan Beulich 

Would you mind commenting on why you went with multiple unlocks,
rather than multiple if statements?

e.g.,

```
rc =3D p2m_set_entry(...);

/* Do the pod entry adjustment while holding the lock on success */
if ( rc =3D=3D 0 ) {
 /* adjust pod entries */
}

pod_unlock(p2m);

/* Do the rest of the clean-up and error handling */
if (rc =3D=3D 0 ) {
```

Just right now the multiple unlocks makes me worry that we may forget
one at some point.

 -George


From xen-devel-bounces@lists.xenproject.org Wed Mar 13 16:41:27 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 16:41:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692627.1079948 (Exim 4.92)
	(envelope-from )
	id 1rkRfP-0008E3-Gh; Wed, 13 Mar 2024 16:41:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692627.1079948; Wed, 13 Mar 2024 16:41:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkRfP-0008Dw-DU; Wed, 13 Mar 2024 16:41:23 +0000
Received: by outflank-mailman (input) for mailman id 692627;
 Wed, 13 Mar 2024 16:41:22 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkRfO-0008Dq-LH
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 16:41:22 +0000
Received: from mail137-23.atl71.mandrillapp.com
 (mail137-23.atl71.mandrillapp.com [198.2.137.23])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8523251d-e158-11ee-afdd-a90da7624cb6;
 Wed, 13 Mar 2024 17:41:21 +0100 (CET)
Received: from pmta07.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1])
 by mail137-23.atl71.mandrillapp.com (Mailchimp) with ESMTP id
 4Tvx9B1V3Nz1XLJlY
 for ; Wed, 13 Mar 2024 16:41:18 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 955815554105470d8cc16439a67cb507; Wed, 13 Mar 2024 16:41:18 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8523251d-e158-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1710348078; x=1710608578;
	bh=0bduU8vi4qUwaEqWeiDsH+4vvViTADvEp8YdEFXN0zs=;
	h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version:
	 Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From;
	b=MluqUJDd7QgnBCO9/UmrxW33FMqUiNfTqLr7KDVXO9oFpVTXXMGWWwI8I3ZFQ6DjT
	 L+8Sz80efk9pwxDIS2Kj733wTzhhuquHHTNzU5wmWAZ9L6EYnBCk8yU1Z2kpEHQCPI
	 IaHc2x+OVOy9QbJIiop7rYTzeFv3evCEEy0ZBiS+aPX4qDSo+j5PXb2VKG8HRPAM7H
	 OoXLPCfIhk+6O58QR3eMO4ZchhK5OOtDeQEwn5ofKd55ESwVjMDd5k60VYbMB4KLW7
	 imfHjqt60ntECTEme7eWEmpTxUHoX+tkvHb1T4NvC/v4hoMoKxgXEnPhE3Mo5nSn55
	 6uY7wO7Lv1MmQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1710348078; x=1710608578; i=vaishali.thakkar@vates.tech;
	bh=0bduU8vi4qUwaEqWeiDsH+4vvViTADvEp8YdEFXN0zs=;
	h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version:
	 Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From;
	b=V1oXK6CpbTdLnLGjfdAAeMN8Tt0z9s1i+ooCxzex9e2b9de8YxAQ6BkhXwOvQ7j43
	 /AWsZgC6KBcZsA7kOKO/BURXuyuTL0GmzAzDb3XCKm4f8iGM1mQ8PnXn5zKFIcKMWd
	 4W+BenjUFtah49jJM1u/jkhSEuw2vPDvueqcyDO2BxI3hP5LUJkdnN/c090SxZbGkM
	 6KOK3TqY67wn1LBS4zYhdYXOuY7nat7FqiR28eLrTc4aRxAyW1/KiBvi1Wi34FRzjO
	 dq068MK+2UT9n/mS56PAK37Hpy5/Hmrpgm/AHSGTZfBCwVZEyJcJNW0VlrePVqgViZ
	 jocT5hEYy7wmA==
From: Vaishali Thakkar 
Subject: =?utf-8?Q?[PATCH=20v3=200/3]=20Misc=20changes=20for=20few=20VMCB=20bits?=
X-Mailer: git-send-email 2.44.0
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1710348077128
To: xen-devel@lists.xenproject.org
Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger.pau@citrix.com, wl@xen.org, Vaishali Thakkar 
Message-Id: 
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.955815554105470d8cc16439a67cb507?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20240313:md
Date: Wed, 13 Mar 2024 16:41:18 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Hi,

In this patchset, first & second patch removes the unnecessary
suffix from a bunch of vmcb bits. Third patch is about printing
the status of sev and sev-es bits while dumping VMCB.

Changes since v1:
  - Address comments from Andrew and Jan
  - Add extrapatch to drop the suffix _guest as per Andrew's
    suggestion in one of the reviews
  - Address Andrew's comment with respect to pretty printing

Changes since v2:
  - Use VMCB accessors instead of open coding in patch 1 & 2
  - Fix one remaining instance of using false/true instead of
    0/1 in patch 2
  - Improve the pretty printing in svm-debug based on Jan's
    comments
  - Improve commit logs and the subject of patch 3 to include
    the changes done in v3

Vaishali Thakkar (3):
  x86/svm: Drop the _enabled suffix from vmcb bits
  x86/svm: Drop the suffix _guest from vmcb bit
  x86/svmdebug: Print np, sev and sev_es vmcb bits

 xen/arch/x86/hvm/svm/asid.c                  |  6 ++---
 xen/arch/x86/hvm/svm/nestedsvm.c             | 22 ++++++++---------
 xen/arch/x86/hvm/svm/svm.c                   |  2 +-
 xen/arch/x86/hvm/svm/svmdebug.c              |  7 ++++--
 xen/arch/x86/hvm/svm/vmcb.c                  |  2 +-
 xen/arch/x86/include/asm/hvm/svm/nestedsvm.h |  2 +-
 xen/arch/x86/include/asm/hvm/svm/vmcb.h      | 26 ++++++++++----------
 7 files changed, 35 insertions(+), 32 deletions(-)

-- 
2.44.0


From xen-devel-bounces@lists.xenproject.org Wed Mar 13 16:41:30 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 16:41:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692628.1079958 (Exim 4.92)
	(envelope-from )
	id 1rkRfW-0008UF-ML; Wed, 13 Mar 2024 16:41:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692628.1079958; Wed, 13 Mar 2024 16:41:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkRfW-0008U8-Jb; Wed, 13 Mar 2024 16:41:30 +0000
Received: by outflank-mailman (input) for mailman id 692628;
 Wed, 13 Mar 2024 16:41:28 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkRfU-0008TO-Ud
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 16:41:28 +0000
Received: from mail137-23.atl71.mandrillapp.com
 (mail137-23.atl71.mandrillapp.com [198.2.137.23])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 887fec5c-e158-11ee-a1ee-f123f15fe8a2;
 Wed, 13 Mar 2024 17:41:26 +0100 (CET)
Received: from pmta07.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1])
 by mail137-23.atl71.mandrillapp.com (Mailchimp) with ESMTP id
 4Tvx9K4d6Cz1XLJlW
 for ; Wed, 13 Mar 2024 16:41:25 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 f8f7fb8bad3e41d192062b60b34287b4; Wed, 13 Mar 2024 16:41:25 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 887fec5c-e158-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1710348085; x=1710608585;
	bh=Zy65FkuCvNCvRgOvJCYiFpYTdL1M/+sk4RyW/gW0XNw=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=dcCRpZdN/62ZxP+p09/Tr+Ta5Ud27/2rmiCFV3nkC/76X/GWzK6dLLQrwCq1OPu8l
	 qy/dQn6hRGYcKItbXp/XPH45ejpf6vW1NtS8fnVPJQriGHaB90oMuq2OQoeQt5M0qV
	 BjxfeB9AKJx6XLmS4JjkzB3Fml/cKOxBjSsbLDTIhjulyCmQwC70pXXIGmKi4R/Diy
	 YPBK4ZsWV67ZAOC/ckEtD+ZZEFupTE8NStGr/d8qX4X4oTDpvXmcuycMBbONPd+TH2
	 03F8zeKkP1Pg1byrxIS/RfqeIQ8UJXqhJFuHgydTEnsdjkwyJJVnMt/WCFDMUuEZqC
	 U/Ff/MSIGv63w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1710348085; x=1710608585; i=vaishali.thakkar@vates.tech;
	bh=Zy65FkuCvNCvRgOvJCYiFpYTdL1M/+sk4RyW/gW0XNw=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=KLtXYWwV30uVfAgwBvYw5asP4U3O9E4iku42+JWVrl8h2t7LGjorhTa6iDNkuJHEP
	 OZ4cCTTCWfhrid/tYUSu1b1DZR892MXbsE9BjX0FciCU8hwxnXZf31sThgB0gvFKka
	 5KK/w9hU/AJ6pJFQMdVs6W7jmZcyxB2i/KfkdCskYxwI+WfsDBIl2bq1jA57cKA6Gk
	 hj3ol6HGSndbPC94AstaOMgWQEfabYTRp/D1flapBJavYg7mB2QOH3SkWztwvqOR4q
	 6AOn1Qx6HU0n+C7O5wi52yMWh/5A2n/BJ0z8zj0i+jrzAZ6jEqa66bD4PftB9iCbz4
	 7IcIeniDsY3KA==
From: Vaishali Thakkar 
Subject: =?utf-8?Q?[PATCH=20v3=201/3]=20x86/svm:=20Drop=20the=20=5Fenabled=20suffix=20from=20vmcb=20bits?=
X-Mailer: git-send-email 2.44.0
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1710348084444
To: xen-devel@lists.xenproject.org
Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger.pau@citrix.com, wl@xen.org, Vaishali Thakkar 
Message-Id: 
In-Reply-To: 
References: 
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.f8f7fb8bad3e41d192062b60b34287b4?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20240313:md
Date: Wed, 13 Mar 2024 16:41:25 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

The suffix is redundant for np/sev/sev-es bits. Drop it
to avoid adding extra code volume.

Also, while we're here, drop the double negations in one
of the instances of _np bit, replace 0/1 with false/true
in the use cases of _np and use VMCB accessors instead
of open coding.

Suggested-by: Andrew Cooper 
Signed-off-by: Vaishali Thakkar 
Reviewed-by: Andrew Cooper 
---
Changes since v1:
        - Address Andrew and Jan's reviews related to dropping
          double negation and replacing 0/1 with false/true
        - Fix the typo around signed-off-by
Changes since v2:
        - Use VMCB accessors instead of open coding for the
          code that's touched by this commit
---
 xen/arch/x86/hvm/svm/nestedsvm.c        | 14 +++++++-------
 xen/arch/x86/hvm/svm/svm.c              |  2 +-
 xen/arch/x86/hvm/svm/vmcb.c             |  2 +-
 xen/arch/x86/include/asm/hvm/svm/vmcb.h | 20 ++++++++++----------
 4 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c
index e4e01add8c..07630d74d3 100644
--- a/xen/arch/x86/hvm/svm/nestedsvm.c
+++ b/xen/arch/x86/hvm/svm/nestedsvm.c
@@ -571,7 +571,7 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct cpu_user_regs *regs)
     if ( nestedhvm_paging_mode_hap(v) )
     {
         /* host nested paging + guest nested paging. */
-        n2vmcb->_np_enable = 1;
+        vmcb_set_np(n2vmcb, true);
 
         nestedsvm_vmcb_set_nestedp2m(v, ns_vmcb, n2vmcb);
 
@@ -585,7 +585,7 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct cpu_user_regs *regs)
     else if ( paging_mode_hap(v->domain) )
     {
         /* host nested paging + guest shadow paging. */
-        n2vmcb->_np_enable = 1;
+        vmcb_set_np(n2vmcb, true);
         /* Keep h_cr3 as it is. */
         n2vmcb->_h_cr3 = n1vmcb->_h_cr3;
         /* When l1 guest does shadow paging
@@ -601,7 +601,7 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct cpu_user_regs *regs)
     else
     {
         /* host shadow paging + guest shadow paging. */
-        n2vmcb->_np_enable = 0;
+        vmcb_set_np(n2vmcb, false);
         n2vmcb->_h_cr3 = 0x0;
 
         /* TODO: Once shadow-shadow paging is in place come back to here
@@ -706,7 +706,7 @@ nsvm_vcpu_vmentry(struct vcpu *v, struct cpu_user_regs *regs,
     }
 
     /* nested paging for the guest */
-    svm->ns_hap_enabled = !!ns_vmcb->_np_enable;
+    svm->ns_hap_enabled = vmcb_get_np(ns_vmcb);
 
     /* Remember the V_INTR_MASK in hostflags */
     svm->ns_hostflags.fields.vintrmask = !!ns_vmcb->_vintr.fields.intr_masking;
@@ -1084,7 +1084,7 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs)
     if ( nestedhvm_paging_mode_hap(v) )
     {
         /* host nested paging + guest nested paging. */
-        ns_vmcb->_np_enable = n2vmcb->_np_enable;
+        vmcb_set_np(ns_vmcb, vmcb_get_np(n2vmcb));
         ns_vmcb->_cr3 = n2vmcb->_cr3;
         /* The vmcb->h_cr3 is the shadowed h_cr3. The original
          * unshadowed guest h_cr3 is kept in ns_vmcb->h_cr3,
@@ -1093,7 +1093,7 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs)
     else if ( paging_mode_hap(v->domain) )
     {
         /* host nested paging + guest shadow paging. */
-        ns_vmcb->_np_enable = 0;
+        vmcb_set_np(ns_vmcb, false);
         /* Throw h_cr3 away. Guest is not allowed to set it or
          * it can break out, otherwise (security hole!) */
         ns_vmcb->_h_cr3 = 0x0;
@@ -1104,7 +1104,7 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs)
     else
     {
         /* host shadow paging + guest shadow paging. */
-        ns_vmcb->_np_enable = 0;
+        vmcb_set_np(ns_vmcb, false);
         ns_vmcb->_h_cr3 = 0x0;
         /* The vmcb->_cr3 is the shadowed cr3. The original
          * unshadowed guest cr3 is kept in ns_vmcb->_cr3,
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index b551eac807..b1ab0b568b 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -473,7 +473,7 @@ static int svm_vmcb_restore(struct vcpu *v, struct hvm_hw_cpu *c)
 
     if ( paging_mode_hap(v->domain) )
     {
-        vmcb_set_np_enable(vmcb, 1);
+        vmcb_set_np(vmcb, true);
         vmcb_set_g_pat(vmcb, MSR_IA32_CR_PAT_RESET /* guest PAT */);
         vmcb_set_h_cr3(vmcb, pagetable_get_paddr(p2m_get_pagetable(p2m)));
     }
diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c
index 282fe7cdbe..4e1f61dbe0 100644
--- a/xen/arch/x86/hvm/svm/vmcb.c
+++ b/xen/arch/x86/hvm/svm/vmcb.c
@@ -133,7 +133,7 @@ static int construct_vmcb(struct vcpu *v)
 
     if ( paging_mode_hap(v->domain) )
     {
-        vmcb->_np_enable = 1; /* enable nested paging */
+        vmcb_set_np(vmcb, true); /* enable nested paging */
         vmcb->_g_pat = MSR_IA32_CR_PAT_RESET; /* guest PAT */
         vmcb->_h_cr3 = pagetable_get_paddr(
             p2m_get_pagetable(p2m_get_hostp2m(v->domain)));
diff --git a/xen/arch/x86/include/asm/hvm/svm/vmcb.h b/xen/arch/x86/include/asm/hvm/svm/vmcb.h
index 91221ff4e2..bf2b8d9a94 100644
--- a/xen/arch/x86/include/asm/hvm/svm/vmcb.h
+++ b/xen/arch/x86/include/asm/hvm/svm/vmcb.h
@@ -385,7 +385,7 @@ typedef union
         bool iopm:1;       /* 1:  iopm_base_pa, msrpm_base_pa */
         bool asid:1;       /* 2:  guest_asid */
         bool tpr:1;        /* 3:  vintr */
-        bool np:1;         /* 4:  np_enable, h_cr3, g_pat */
+        bool np:1;         /* 4:  np, h_cr3, g_pat */
         bool cr:1;         /* 5:  cr0, cr3, cr4, efer */
         bool dr:1;         /* 6:  dr6, dr7 */
         bool dt:1;         /* 7:  gdtr, idtr */
@@ -473,12 +473,12 @@ struct vmcb_struct {
     intinfo_t exit_int_info;    /* offset 0x88 */
     union {                     /* offset 0x90 - cleanbit 4 */
         struct {
-            bool _np_enable     :1;
-            bool _sev_enable    :1;
-            bool _sev_es_enable :1;
-            bool _gmet          :1;
-            bool _np_sss        :1;
-            bool _vte           :1;
+            bool _np        :1;
+            bool _sev       :1;
+            bool _sev_es    :1;
+            bool _gmet      :1;
+            bool _np_sss    :1;
+            bool _vte       :1;
         };
         uint64_t _np_ctrl;
     };
@@ -645,9 +645,9 @@ VMCB_ACCESSORS(msrpm_base_pa, iopm)
 VMCB_ACCESSORS(guest_asid, asid)
 VMCB_ACCESSORS(vintr, tpr)
 VMCB_ACCESSORS(np_ctrl, np)
-VMCB_ACCESSORS_(np_enable, bool, np)
-VMCB_ACCESSORS_(sev_enable, bool, np)
-VMCB_ACCESSORS_(sev_es_enable, bool, np)
+VMCB_ACCESSORS_(np, bool, np)
+VMCB_ACCESSORS_(sev, bool, np)
+VMCB_ACCESSORS_(sev_es, bool, np)
 VMCB_ACCESSORS_(gmet, bool, np)
 VMCB_ACCESSORS_(vte, bool, np)
 VMCB_ACCESSORS(h_cr3, np)
-- 
2.44.0


From xen-devel-bounces@lists.xenproject.org Wed Mar 13 16:41:32 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 16:41:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692629.1079968 (Exim 4.92)
	(envelope-from )
	id 1rkRfX-0000J0-Tg; Wed, 13 Mar 2024 16:41:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692629.1079968; Wed, 13 Mar 2024 16:41:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkRfX-0000Ip-Qp; Wed, 13 Mar 2024 16:41:31 +0000
Received: by outflank-mailman (input) for mailman id 692629;
 Wed, 13 Mar 2024 16:41:30 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkRfW-0008Dq-8R
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 16:41:30 +0000
Received: from mail133-16.atl131.mandrillapp.com
 (mail133-16.atl131.mandrillapp.com [198.2.133.16])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8a198dd9-e158-11ee-afdd-a90da7624cb6;
 Wed, 13 Mar 2024 17:41:29 +0100 (CET)
Received: from pmta13.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1])
 by mail133-16.atl131.mandrillapp.com (Mailchimp) with ESMTP id
 4Tvx9N0CKwzB5p521
 for ; Wed, 13 Mar 2024 16:41:28 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 0a50c5bf78884ac4b4c33705b6ebd394; Wed, 13 Mar 2024 16:41:27 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8a198dd9-e158-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1710348088; x=1710608588;
	bh=rr1EGVf91eM8PfB9T0UeBppnRI+2X6vdx2ec2oXZ69o=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=EOIJGJy7/QVasU3fTPRh0emzLkv6sf8W3xrRO7PYQWVjPZYyXAJmDnWP9xhYTEpGV
	 rKXoN9RvtKizA4/gvsFNXPvFUgiRXk4RtTK4EkEn/Wh/6rYzL7jreWs+zuYOoniydv
	 LeOLQwhfNvEaAspKkDxGns8NxsPrIa9HcMDAjZsGjH/toLaxH0oIaHRDbjpnZXfEcO
	 IBsYCCv8mIKXqM/73TdYr8UfwXxPJEqYB38NY/uoTAeNt2eJRLGrcayfr8gzPyE/Fg
	 X8asq2pWxHTNnJsM5MiFehXY0RUeiXfecaI5cuGaVkybI+2mIHMZyzEFbeb7Tos8Jx
	 bzpNG+95h/f4A==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1710348088; x=1710608588; i=vaishali.thakkar@vates.tech;
	bh=rr1EGVf91eM8PfB9T0UeBppnRI+2X6vdx2ec2oXZ69o=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=RNBnBA3yGqFMtOLYKHUafmF4i+JZa7dos4w2FB8q5V8ndCTV/c0fQQU6RrUwQ72Cr
	 GlKZ5/SIRZTZx7c+YKYrF4e0MGNOjBEGO/UF64SSXIbuhr3wSUXPdeP6AnnYDu46WA
	 kn1ewZZkoiHTGUTj58TgO3Mk86f8xmoyZPUh4AnHB9Rv+24cfgFJ8kPiu5Nnhk8xNB
	 z9VsnYRciKVF4EM0Kr07FcjiqxndffNnke1JxsZ4+a0UMhtabwAhX/gK5osyPlQW7F
	 s0/xTwIu3dDUz7j5e83Gy64wqhvyZuO3U7BPxdfHRunNbVVPKfP5BFqmVtzg3y2d0H
	 hrc/06dHAstgg==
From: Vaishali Thakkar 
Subject: =?utf-8?Q?[PATCH=20v3=202/3]=20x86/svm:=20Drop=20the=20suffix=20=5Fguest=20from=20vmcb=20bit?=
X-Mailer: git-send-email 2.44.0
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1710348086853
To: xen-devel@lists.xenproject.org
Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger.pau@citrix.com, wl@xen.org, Vaishali Thakkar 
Message-Id: <88d5a0ce6745428120ebc37369d3d75358d5c582.1710347950.git.vaishali.thakkar@vates.tech>
In-Reply-To: 
References: 
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.0a50c5bf78884ac4b4c33705b6ebd394?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20240313:md
Date: Wed, 13 Mar 2024 16:41:27 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

The suffix _guest is redundant for asid bit. Drop it
to avoid adding extra code volume.

While we're here, replace 0/1 with false/true and use
VMCB accessors instead of open coding.

Suggested-by: Andrew Cooper 
Signed-off-by: Vaishali Thakkar 
---
Changes since v1:
        - This patch wasn't part of v1. It's been added to
          address Andrew's suggestion.
Changes since v2:
        - replace 0/1 with false/true in one of the instance
        - Use VMCB accessors instead of open coding
---
 xen/arch/x86/hvm/svm/asid.c                  | 6 +++---
 xen/arch/x86/hvm/svm/nestedsvm.c             | 8 ++++----
 xen/arch/x86/hvm/svm/svmdebug.c              | 4 ++--
 xen/arch/x86/include/asm/hvm/svm/nestedsvm.h | 2 +-
 xen/arch/x86/include/asm/hvm/svm/vmcb.h      | 6 +++---
 5 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/asid.c b/xen/arch/x86/hvm/svm/asid.c
index 28e0dbc176..39e3c56919 100644
--- a/xen/arch/x86/hvm/svm/asid.c
+++ b/xen/arch/x86/hvm/svm/asid.c
@@ -37,14 +37,14 @@ void svm_asid_handle_vmrun(void)
     /* ASID 0 indicates that ASIDs are disabled. */
     if ( p_asid->asid == 0 )
     {
-        vmcb_set_guest_asid(vmcb, 1);
+        vmcb_set_asid(vmcb,true);
         vmcb->tlb_control =
             cpu_has_svm_flushbyasid ? TLB_CTRL_FLUSH_ASID : TLB_CTRL_FLUSH_ALL;
         return;
     }
 
-    if ( vmcb_get_guest_asid(vmcb) != p_asid->asid )
-        vmcb_set_guest_asid(vmcb, p_asid->asid);
+    if ( vmcb_get_asid(vmcb) != p_asid->asid )
+        vmcb_set_asid(vmcb, p_asid->asid);
 
     vmcb->tlb_control =
         !need_flush ? TLB_CTRL_NO_FLUSH :
diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c
index 07630d74d3..a8d5f4ee95 100644
--- a/xen/arch/x86/hvm/svm/nestedsvm.c
+++ b/xen/arch/x86/hvm/svm/nestedsvm.c
@@ -157,7 +157,7 @@ int cf_check nsvm_vcpu_reset(struct vcpu *v)
     svm->ns_hap_enabled = 0;
     svm->ns_vmcb_guestcr3 = 0;
     svm->ns_vmcb_hostcr3 = 0;
-    svm->ns_guest_asid = 0;
+    svm->ns_asid = 0;
     svm->ns_hostflags.bytes = 0;
     svm->ns_vmexit.exitinfo1 = 0;
     svm->ns_vmexit.exitinfo2 = 0;
@@ -698,11 +698,11 @@ nsvm_vcpu_vmentry(struct vcpu *v, struct cpu_user_regs *regs,
     /* Convert explicitely to boolean. Deals with l1 guests
      * that use flush-by-asid w/o checking the cpuid bits */
     nv->nv_flushp2m = !!ns_vmcb->tlb_control;
-    if ( svm->ns_guest_asid != ns_vmcb->_guest_asid )
+    if ( svm->ns_asid != vmcb_get_asid(ns_vmcb))
     {
         nv->nv_flushp2m = 1;
         hvm_asid_flush_vcpu_asid(&vcpu_nestedhvm(v).nv_n2asid);
-        svm->ns_guest_asid = ns_vmcb->_guest_asid;
+        svm->ns_asid = vmcb_get_asid(ns_vmcb);
     }
 
     /* nested paging for the guest */
@@ -1046,7 +1046,7 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs)
     /* Keep it. It's maintainted by the l1 guest. */
 
     /* ASID */
-    /* ns_vmcb->_guest_asid = n2vmcb->_guest_asid; */
+    /* vmcb_set_asid(ns_vmcb, vmcb_get_asid(n2vmcb)); */
 
     /* TLB control */
     ns_vmcb->tlb_control = 0;
diff --git a/xen/arch/x86/hvm/svm/svmdebug.c b/xen/arch/x86/hvm/svm/svmdebug.c
index 24358c6eea..0d714c728c 100644
--- a/xen/arch/x86/hvm/svm/svmdebug.c
+++ b/xen/arch/x86/hvm/svm/svmdebug.c
@@ -51,8 +51,8 @@ void svm_vmcb_dump(const char *from, const struct vmcb_struct *vmcb)
            vmcb->exitcode, vmcb->exit_int_info.raw);
     printk("exitinfo1 = %#"PRIx64" exitinfo2 = %#"PRIx64"\n",
            vmcb->exitinfo1, vmcb->exitinfo2);
-    printk("np_ctrl = %#"PRIx64" guest_asid = %#x\n",
-           vmcb_get_np_ctrl(vmcb), vmcb_get_guest_asid(vmcb));
+    printk("np_ctrl = %#"PRIx64" asid = %#x\n",
+           vmcb_get_np_ctrl(vmcb), vmcb_get_asid(vmcb));
     printk("virtual vmload/vmsave = %d, virt_ext = %#"PRIx64"\n",
            vmcb->virt_ext.fields.vloadsave_enable, vmcb->virt_ext.bytes);
     printk("cpl = %d efer = %#"PRIx64" star = %#"PRIx64" lstar = %#"PRIx64"\n",
diff --git a/xen/arch/x86/include/asm/hvm/svm/nestedsvm.h b/xen/arch/x86/include/asm/hvm/svm/nestedsvm.h
index 406fc082b1..7767cd6080 100644
--- a/xen/arch/x86/include/asm/hvm/svm/nestedsvm.h
+++ b/xen/arch/x86/include/asm/hvm/svm/nestedsvm.h
@@ -51,7 +51,7 @@ struct nestedsvm {
      *     the l1 guest nested page table
      */
     uint64_t ns_vmcb_guestcr3, ns_vmcb_hostcr3;
-    uint32_t ns_guest_asid;
+    uint32_t ns_asid;
 
     bool ns_hap_enabled;
 
diff --git a/xen/arch/x86/include/asm/hvm/svm/vmcb.h b/xen/arch/x86/include/asm/hvm/svm/vmcb.h
index bf2b8d9a94..0396d10b90 100644
--- a/xen/arch/x86/include/asm/hvm/svm/vmcb.h
+++ b/xen/arch/x86/include/asm/hvm/svm/vmcb.h
@@ -383,7 +383,7 @@ typedef union
         bool intercepts:1; /* 0:  cr/dr/exception/general intercepts,
                             *     pause_filter_count, tsc_offset */
         bool iopm:1;       /* 1:  iopm_base_pa, msrpm_base_pa */
-        bool asid:1;       /* 2:  guest_asid */
+        bool asid:1;       /* 2:  asid */
         bool tpr:1;        /* 3:  vintr */
         bool np:1;         /* 4:  np, h_cr3, g_pat */
         bool cr:1;         /* 5:  cr0, cr3, cr4, efer */
@@ -413,7 +413,7 @@ struct vmcb_struct {
     u64 _iopm_base_pa;          /* offset 0x40 - cleanbit 1 */
     u64 _msrpm_base_pa;         /* offset 0x48 - cleanbit 1 */
     u64 _tsc_offset;            /* offset 0x50 - cleanbit 0 */
-    u32 _guest_asid;            /* offset 0x58 - cleanbit 2 */
+    u32 _asid;                  /* offset 0x58 - cleanbit 2 */
     u8  tlb_control;            /* offset 0x5C - TLB_CTRL_* */
     u8  res07[3];
     vintr_t _vintr;             /* offset 0x60 - cleanbit 3 */
@@ -642,7 +642,7 @@ VMCB_ACCESSORS(pause_filter_thresh, intercepts)
 VMCB_ACCESSORS(tsc_offset, intercepts)
 VMCB_ACCESSORS(iopm_base_pa, iopm)
 VMCB_ACCESSORS(msrpm_base_pa, iopm)
-VMCB_ACCESSORS(guest_asid, asid)
+VMCB_ACCESSORS(asid, asid)
 VMCB_ACCESSORS(vintr, tpr)
 VMCB_ACCESSORS(np_ctrl, np)
 VMCB_ACCESSORS_(np, bool, np)
-- 
2.44.0


From xen-devel-bounces@lists.xenproject.org Wed Mar 13 16:41:33 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 16:41:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692630.1079978 (Exim 4.92)
	(envelope-from )
	id 1rkRfZ-0000Yi-8p; Wed, 13 Mar 2024 16:41:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692630.1079978; Wed, 13 Mar 2024 16:41:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkRfZ-0000YY-5I; Wed, 13 Mar 2024 16:41:33 +0000
Received: by outflank-mailman (input) for mailman id 692630;
 Wed, 13 Mar 2024 16:41:31 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkRfX-0008Dq-8h
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 16:41:31 +0000
Received: from mail133-16.atl131.mandrillapp.com
 (mail133-16.atl131.mandrillapp.com [198.2.133.16])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8b1cb283-e158-11ee-afdd-a90da7624cb6;
 Wed, 13 Mar 2024 17:41:30 +0100 (CET)
Received: from pmta13.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1])
 by mail133-16.atl131.mandrillapp.com (Mailchimp) with ESMTP id
 4Tvx9Q14d0zB5p8C3
 for ; Wed, 13 Mar 2024 16:41:30 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 02c8ef692cf34864b336a41beefd05b2; Wed, 13 Mar 2024 16:41:30 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8b1cb283-e158-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1710348090; x=1710608590;
	bh=FMitaZpjptJvXQpvaxxHZ/aFZkkeDw8TY9xvhcTGIUY=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=NO1+mgHmuB344VkLQH3vs3M/sf9zVdMkXS3QvrvUEe8PmF3CnoqMWI+nSm6U0P0UK
	 jA0YXSdhIbIVxDtAZRBx0Qu2zpqxsQBHg1yPPA/GvGn2yfT5EtPKYx2vFwyXxDs0QR
	 4ADyf893c7HoLOzTw5Kq46oKQ7VqX8zBc3DCoSCFI/EoJgpNW/i6FSL7cxUpiAB2N4
	 uIS3ejWHNAZGJxOcg27hCjrcnP9uzgRaTRVWt9dxXDq08JnKDoP/q2LUHHP94I56hQ
	 KwA4EygUDkKE3VPF7BxSRzfBPODe6I3LLaQBLGKTTAIRv/XvEUbsY25QY8Vsfmvu1A
	 CnSyhULIQN9cg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1710348090; x=1710608590; i=vaishali.thakkar@vates.tech;
	bh=FMitaZpjptJvXQpvaxxHZ/aFZkkeDw8TY9xvhcTGIUY=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=VBN6sibtXiH+TGClEeQQ3pqVM2hAo59ljZXcskj8Jkqux+uFWpvwmDmt+La4+y7oc
	 YH83TUYMtJfCnoW2VeCf2vhifyKCUj45mWCHE3djhI+nWyNXcROj2mIciDWdXctTVE
	 nfe1V58e1ZK6xkIjPRZAH4sNQU/uthsOH+ZCNBKBkft/7zY3t3ci1FqWtGSBDrOIRS
	 G8JvAjfMk416jVBc7jKIryxggD8xNAmqfl9hLI4XYU/DUmPXuNhApcNPwl8Pv3jyiH
	 e4+e0ojS/QyLUci6tkwW+26avYtzttuJOs0IqaARLmXoMzl3NwD7a4htSrEP5C9Z6w
	 0dkrNKcRGWD2Q==
From: Vaishali Thakkar 
Subject: =?utf-8?Q?[PATCH=20v3=203/3]=20x86/svmdebug:=20Print=20np,=20sev=20and=20sev=5Fes=20vmcb=20bits?=
X-Mailer: git-send-email 2.44.0
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1710348088991
To: xen-devel@lists.xenproject.org
Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger.pau@citrix.com, wl@xen.org, Vaishali Thakkar 
Message-Id: 
In-Reply-To: 
References: 
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.02c8ef692cf34864b336a41beefd05b2?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20240313:md
Date: Wed, 13 Mar 2024 16:41:30 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Currently only raw _np_ctrl is being printed. It can
be informational to know about which particular bits
are enabled. So, this commit adds the bit-by-bit decode
for np, sev and sev_es bits.

Note that while, only np is enabled in certain scenarios
at the moment, work for enabling sev and sev_es is in
progress. And it'll be useful to have this information as
part of svmdebug.

Signed-off-by: Vaishali Thakkar 
---
Changes since v1:
        - Pretty printing
Changes since v2:
        - Minor changes in pretty printing to make information
          clear
        - Improve commit log and subject to include _np bit
---
 xen/arch/x86/hvm/svm/svmdebug.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/svmdebug.c b/xen/arch/x86/hvm/svm/svmdebug.c
index 0d714c728c..9d3badcf5d 100644
--- a/xen/arch/x86/hvm/svm/svmdebug.c
+++ b/xen/arch/x86/hvm/svm/svmdebug.c
@@ -51,8 +51,11 @@ void svm_vmcb_dump(const char *from, const struct vmcb_struct *vmcb)
            vmcb->exitcode, vmcb->exit_int_info.raw);
     printk("exitinfo1 = %#"PRIx64" exitinfo2 = %#"PRIx64"\n",
            vmcb->exitinfo1, vmcb->exitinfo2);
-    printk("np_ctrl = %#"PRIx64" asid = %#x\n",
-           vmcb_get_np_ctrl(vmcb), vmcb_get_asid(vmcb));
+    printk("asid = %#x np_ctrl = %#"PRIx64":%s%s%s\n",
+           vmcb_get_asid(vmcb), vmcb_get_np_ctrl(vmcb),
+           vmcb_get_np(vmcb)     ? " NP"     : "",
+           vmcb_get_sev(vmcb)    ? " SEV"    : "",
+           vmcb_get_sev_es(vmcb) ? " SEV_ES" : "");
     printk("virtual vmload/vmsave = %d, virt_ext = %#"PRIx64"\n",
            vmcb->virt_ext.fields.vloadsave_enable, vmcb->virt_ext.bytes);
     printk("cpl = %d efer = %#"PRIx64" star = %#"PRIx64" lstar = %#"PRIx64"\n",
-- 
2.44.0


From xen-devel-bounces@lists.xenproject.org Wed Mar 13 16:51:22 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 16:51:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692640.1079988 (Exim 4.92)
	(envelope-from )
	id 1rkRos-0002vq-6E; Wed, 13 Mar 2024 16:51:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692640.1079988; Wed, 13 Mar 2024 16:51:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkRos-0002vj-38; Wed, 13 Mar 2024 16:51:10 +0000
Received: by outflank-mailman (input) for mailman id 692640;
 Wed, 13 Mar 2024 16:51:09 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkRor-0002vd-Ks
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 16:51:09 +0000
Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com
 [2a00:1450:4864:20::32e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e322ebf2-e159-11ee-a1ee-f123f15fe8a2;
 Wed, 13 Mar 2024 17:51:07 +0100 (CET)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-413ebcf1315so402235e9.2
 for ; Wed, 13 Mar 2024 09:51:07 -0700 (PDT)
Received: from perard.uk.xensource.com (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 l5-20020a05600c1d0500b00412ea52b102sm2881155wms.34.2024.03.13.09.51.06
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 13 Mar 2024 09:51:06 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e322ebf2-e159-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1710348667; x=1710953467; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=a48IgrpPJ/Rmc3kWvVNrrLx58qYK0IkJ0bjzeqBQ4lM=;
        b=cOkvf6nru4iuuR8C66Oi7zp1tEe/pQfZhTHzhfu1w6o7s/OeopADGJWegK3U7d7TDi
         ULKS4bpzA9BNqJZZjSQR0HMcGJ6/W5vVzGw/wUJ/LjxrgPTDXT5BGXXyfSpwvonpXud3
         PAddkfBk3gS6oOJcKCb3jgwcS/oEN7NdckFOU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710348667; x=1710953467;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=a48IgrpPJ/Rmc3kWvVNrrLx58qYK0IkJ0bjzeqBQ4lM=;
        b=O4UepK3T6Pu3VBmYEPyZF8cx3t/pFDrJQu9E2CHDD1cW4VWxDtehqg4pM9WKbRdqop
         jN6dDCuJd9cpP5KiBlibew0WAP4isazsdAg4WY496GNjgmS9cPuhx2K1jn0uqz2PwbBi
         cFtz5UEPKY9X2LkHHmPJslvSsGUWjFjzHDZNjCcGp6dMlwNa3F8fXDT/TcvRCrvC1WG4
         cAZMF9rrvDg/VF2Rbis84SqmkFkioL6tzdlkeiJtZFcFjFm2jdD/HXf/cDp46xjMnxvl
         +DpA08rLvnz+mh/GYa7W28/buwCGAsWO+9ohWxw8feh9IwtqDiwctG6uD0rLNarMWItF
         pMeA==
X-Gm-Message-State: AOJu0YxLzxrj17axH+Topw1fuQUkgLpD05afkVnmOKfWZinebTO1tfCy
	nMX4uNDACE1Iq5DL8TjVQdN5BzOb4pV8ZiatWlsCwaH59QPSnMlR11XpT0DBiMo=
X-Google-Smtp-Source: AGHT+IGHjkhoGd+u+DjD0/B/AmrhjOejn066tx3QHGsOxJyXFXgPSrrkIi7rNHthrbg1ncQigDa1zw==
X-Received: by 2002:a05:600c:4e91:b0:413:1810:4a48 with SMTP id f17-20020a05600c4e9100b0041318104a48mr360661wmq.22.1710348666900;
        Wed, 13 Mar 2024 09:51:06 -0700 (PDT)
Date: Wed, 13 Mar 2024 16:51:05 +0000
From: Anthony PERARD 
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= 
Cc: xen-devel@lists.xenproject.org, Jan Beulich ,
	Andrew Cooper ,
	Juergen Gross 
Subject: Re: [OSSTEST PATCH] ap-common: Switch to Linux 6.1 by default on x86
 + drop dom0 i386
Message-ID: 
References: <20240306114741.14564-1-anthony.perard@citrix.com>
 
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Wed, Mar 13, 2024 at 11:48:11AM +0100, Roger Pau Monn wrote:
> On Tue, Mar 12, 2024 at 05:19:46PM +0000, Anthony PERARD wrote:
> > On Mon, Mar 11, 2024 at 06:27:52PM +0100, Roger Pau Monn wrote:
> > > On Wed, Mar 06, 2024 at 11:47:41AM +0000, Anthony PERARD wrote:
> > > > Gone, but replaced by a new test-amd64-amd64-*:
> > > > - test-amd64-i386-libvirt-raw
> > > > - test-amd64-i386-xl-vhd
> > > > 
> > > > Some test-amd64-amd64-* are also changed:
> > > > - test-amd64-amd64-libvirt-vhd
> > > > - test-amd64-amd64-qemuu-freebsd11-amd64
> > > > - test-amd64-amd64-qemuu-freebsd12-amd64
> > > > - test-amd64-amd64-xl-qcow2
> > > > + test-amd64-amd64-freebsd11-amd64
> > > > + test-amd64-amd64-freebsd12-amd64
> > > > + test-amd64-amd64-libvirt-qcow2
> > > > + test-amd64-amd64-libvirt-raw
> > > > + test-amd64-amd64-xl-vhd
> > > 
> > > Is this purely a name change, or there's some kind of functional
> > > change?
> > 
> > For test-amd64-amd64-qemuu-freebsd1{1,2}-amd64, it looks like the
> > "-qemuu" is a bug. The freebsd jobs shouldn't have used $qemuu_suffix,
> > as it doesn't use $qemuu_runvar. So I'm guessing $qemuu_suffix was just
> > the value left from a previous call of test_matrix_do_one() with
> > dom0arch==i386. The new name is already used by "linux-linus" branch.
> 
> FTAOD, could you mention this in the commit message?
> 
> FreeBSD doesn't use `$qemuu_runvar` because it was always using QEMU
> upstream (when the FreeBSD test was added we decided to only test with
> QEMU upstream).  So there's indeed no `-qemut` variant, but by
> dropping the -qemuu prefix it could be confused with a PV guest
> based test.

I thought "-qemuu" just meant we were using the qemu-upstream as
device-model instead of the default one, but it seems that instead no
jobs are generated with "$qemuu_suffix==''", (or only for Xen 4.2 and
older). So now I guess that all HVM tests have either -qemut or -qemuu.

We that, I guess it makes sense to keep "-qemuu" for freebsd tests. That
would just change branch "linux-linus" and "linux-6.1". I'll prepare a
new patch with that.

> > As for the few changes in {xl,libvirt}-{raw,vhd,qcow2} tests, this is
> > because of
> > - f536e834f673 ("make-flight: Trim the matrix of disk format flights")
> > - 5c70735f177f ("fmtarches: Use dom0arches, not hardcoded arch list")
> 
> Probably a dummy question, but why haven't those commits changed the
> output of make-flight earlier?  I'm fine with the change, but I don't
> really get why we are seeing it only now.

Looking at the commit message, they did some changes.

But the second commit might have made changes in a way that wasn't
intended. For example, "xl-raw" test disappear.

First commit intended to have exactly 6 jobs spread across all arches.
It used as input "i386 armhf amd64 armhf" and just check that the arch
corresponded to the current "$dom0arch". The function is called several
time with different $dom0arch.

The second mention commit changes to use $dom0arches which takes
different values " i386 amd64", then " armhf" and " arm64". The extra
space at the beginning of the string is why there's no more "xl-raw"
tests, because now '' became one of the possible dom0arch which of course
it doesn't exist. Then we have the same exact list of 3 test on armhf
and arm64, which defeat the original intention of the first mention
commit.

So, now I feel like I need to rework do_pv_debian_tests() to at least
re-add "xl-raw" test, and maybe keep only 6 toolstack-disk_format tests
spread across all arches? That could maybe reduce the number of tests on
arm64 which is the current bottleneck.

Cheers,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Wed Mar 13 17:27:29 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 17:27:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692672.1080038 (Exim 4.92)
	(envelope-from )
	id 1rkSO0-0002j7-3K; Wed, 13 Mar 2024 17:27:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692672.1080038; Wed, 13 Mar 2024 17:27:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkSNz-0002j0-W1; Wed, 13 Mar 2024 17:27:27 +0000
Received: by outflank-mailman (input) for mailman id 692672;
 Wed, 13 Mar 2024 17:27:26 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkSNy-00023P-LF
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 17:27:26 +0000
Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com
 [2a00:1450:4864:20::12d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f5b98a74-e15e-11ee-afdd-a90da7624cb6;
 Wed, 13 Mar 2024 18:27:26 +0100 (CET)
Received: by mail-lf1-x12d.google.com with SMTP id
 2adb3069b0e04-513173e8191so163351e87.1
 for ; Wed, 13 Mar 2024 10:27:26 -0700 (PDT)
Received: from andrewcoop.citrite.net (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 f15-20020a170906048f00b00a42ee62b634sm5005732eja.106.2024.03.13.10.27.24
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 13 Mar 2024 10:27:24 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f5b98a74-e15e-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710350845; x=1710955645; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=mpSUgnXdBHSAZ/JHJssOPkagB6hKViTaNFdB8Xxbxeo=;
        b=jup611V9n936X50ItOtQ+kutj8v0i4d45mzKYThumoTM/qDp+2SklQJOcbsTXy0fBC
         fbUOX05OEqllNd3bt09xr5XjygSRR/ZV8KbwbBXSjI/oaAmgj17nZOrL9ZwLQnQOKyPG
         hT7Hlq52yOhSRdJNt43j2SEnH9WtnhO9UxCbI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710350845; x=1710955645;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=mpSUgnXdBHSAZ/JHJssOPkagB6hKViTaNFdB8Xxbxeo=;
        b=jHPA9HSw2GqnxJul/U94nxdhNNVJQSaCQF0WXWPwjjpe3wp5GbZRU3OzROWJ4DrMXM
         fXqzqZavS6QL+5ExMHFBlZyuHVpYZ4Pk8Rxjrt0ZTM0oFIYdHLitks9UXYQPfYE9ajyS
         7BX1gPc4F7eDlwI2sTAMvcThZJO+DLyjhbCNCvcOV/Wbk3j9OXDCvV6QGgRme71uIG+r
         7qqUpDzqZ47mvSTasMUtDjMg1mc4JrggAWWVd55b+cUL6mNitUoWpAb3Ajo7WB4k5D3a
         Xe8XwtZMWVyTXooxsNAq6x0W7UfNvmbyY/5D6US7zzsg5vOgdpquf9/EjQNA3daSA5ya
         NTNQ==
X-Gm-Message-State: AOJu0YxxteFCekwyfCbMoLNQJjNaQwUcWDijReibM2TkASBd8coADFMg
	OTkNgdlMF3uL16ETsWkh+tntwOYa+Ulk/Y+d7g34QvmpNc/nppkHeg28PovSH8CaBUyvoiWZQNN
	M
X-Google-Smtp-Source: AGHT+IHHS2BbxMFp3fPdXZlAelFUvd7kXhHTdQ6kdTtsszbGnCM2NvEXDlSzwIEv0B4ltQUsCO1dZA==
X-Received: by 2002:a05:6512:3e20:b0:513:acc5:47e with SMTP id i32-20020a0565123e2000b00513acc5047emr3211066lfv.22.1710350845342;
        Wed, 13 Mar 2024 10:27:25 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Wei Liu ,
	Stefano Stabellini ,
	Julien Grall ,
	Volodymyr Babchuk ,
	Bertrand Marquis ,
	Michal Orzel ,
	Oleksii Kurochko ,
	Shawn Anastasio ,
	"consulting @ bugseng . com" ,
	Simone Ballarin ,
	Federico Serafini ,
	Nicola Vetrini 
Subject: [PATCH 4/7] xen/bitops: Delete generic_ffs{,l}()
Date: Wed, 13 Mar 2024 17:27:13 +0000
Message-Id: <20240313172716.2325427-5-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20240313172716.2325427-1-andrew.cooper3@citrix.com>
References: <20240313172716.2325427-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

No more users.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
CC: Wei Liu 
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Volodymyr Babchuk 
CC: Bertrand Marquis 
CC: Michal Orzel 
CC: Oleksii Kurochko 
CC: Shawn Anastasio 
CC: consulting@bugseng.com 
CC: Simone Ballarin 
CC: Federico Serafini 
CC: Nicola Vetrini 
---
 xen/include/xen/bitops.h | 41 ----------------------------------------
 1 file changed, 41 deletions(-)

diff --git a/xen/include/xen/bitops.h b/xen/include/xen/bitops.h
index a37b42342bc5..b85b35c40781 100644
--- a/xen/include/xen/bitops.h
+++ b/xen/include/xen/bitops.h
@@ -14,41 +14,6 @@
 #define GENMASK_ULL(h, l) \
     (((~0ULL) << (l)) & (~0ULL >> (BITS_PER_LLONG - 1 - (h))))
 
-/*
- * ffs: find first bit set. This is defined the same way as
- * the libc and compiler builtin ffs routines, therefore
- * differs in spirit from the above ffz (man ffs).
- */
-
-static inline int generic_ffs(unsigned int x)
-{
-    int r = 1;
-
-    if (!x)
-        return 0;
-    if (!(x & 0xffff)) {
-        x >>= 16;
-        r += 16;
-    }
-    if (!(x & 0xff)) {
-        x >>= 8;
-        r += 8;
-    }
-    if (!(x & 0xf)) {
-        x >>= 4;
-        r += 4;
-    }
-    if (!(x & 3)) {
-        x >>= 2;
-        r += 2;
-    }
-    if (!(x & 1)) {
-        x >>= 1;
-        r += 1;
-    }
-    return r;
-}
-
 /*
  * fls: find last bit set.
  */
@@ -84,11 +49,6 @@ static inline int generic_fls(unsigned int x)
 
 #if BITS_PER_LONG == 64
 
-static inline int generic_ffsl(unsigned long x)
-{
-    return !x || (u32)x ? generic_ffs(x) : generic_ffs(x >> 32) + 32;
-}
-
 static inline int generic_flsl(unsigned long x)
 {
     u32 h = x >> 32;
@@ -97,7 +57,6 @@ static inline int generic_flsl(unsigned long x)
 }
 
 #else
-# define generic_ffsl generic_ffs
 # define generic_flsl generic_fls
 #endif
 
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Wed Mar 13 17:27:29 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 17:27:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692670.1080017 (Exim 4.92)
	(envelope-from )
	id 1rkSNy-0002EH-BZ; Wed, 13 Mar 2024 17:27:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692670.1080017; Wed, 13 Mar 2024 17:27:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkSNy-0002EA-8j; Wed, 13 Mar 2024 17:27:26 +0000
Received: by outflank-mailman (input) for mailman id 692670;
 Wed, 13 Mar 2024 17:27:24 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkSNw-0001lR-LF
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 17:27:24 +0000
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com
 [2a00:1450:4864:20::632])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f3d14d5f-e15e-11ee-a1ee-f123f15fe8a2;
 Wed, 13 Mar 2024 18:27:23 +0100 (CET)
Received: by mail-ej1-x632.google.com with SMTP id
 a640c23a62f3a-a450615d1c4so24687366b.0
 for ; Wed, 13 Mar 2024 10:27:23 -0700 (PDT)
Received: from andrewcoop.citrite.net (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 f15-20020a170906048f00b00a42ee62b634sm5005732eja.106.2024.03.13.10.27.20
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 13 Mar 2024 10:27:21 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f3d14d5f-e15e-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710350842; x=1710955642; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=k2oya0isulzFAqiR2Y4bOr7KNgkZIK98TBQV1YHRgn0=;
        b=tgN3u5Rl4VBjVMYFfH665xVPT01FrfQ26DouBvPsUIp6/IEpYZHe67CTfWwzTMDDgE
         GKTWbszIJA+rXPqCv84CSN5rKscOiGd2vjIAx31MEdRvylichcslzc2ny5I0Lm7OXt+b
         5URllXOM0AmYh6pJjYOT1uJ6opYp+xaC0zCMI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710350842; x=1710955642;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=k2oya0isulzFAqiR2Y4bOr7KNgkZIK98TBQV1YHRgn0=;
        b=bzGWniYsk53HGq4U8N94gAFlV6jLk9ltByn2ZlqXyTp+Y0fEm1JF2XwNC6Et+bOB7k
         /RuF1lQ8wRSfsmiFQZOv1yF8YhLw2UrONjPn82v4ELSqMHt3tondTNCufIGtrtdRyqxR
         LxEriIah61QRj+PqKXSorSmM7ciKRAGCdr50xjegCfI3neLnoRpJMMSh0Po9IGcSje2p
         Eynq5tTo88p0/P+bN4ppLSJfn+EWeOFLjkmgPEzw7hbHLAKdtBDhZflGePngZB649kNc
         IrMvoxNXBbw29Cr/b4WT5DL9RHevBSBN1MbaEZ8eM7VsltZ8XeRCIHYrjXe4exa0jdWO
         vH4g==
X-Gm-Message-State: AOJu0YxTESqZqPOSklFzmgv8PAEfY5KIiA3Gqeh+xFSLvYs6ZiB0/U2q
	i0ZofzQC/PLPYVDHJHwyZ4ws1ZexsNzRrbfnzYxA+dUQpvfDGFRU4YMSduF8Cch9wV1YndpnvuP
	c
X-Google-Smtp-Source: AGHT+IHOjqUYc+9/WYFvjA5tif1UP2IANWkp92gtxXAy0+hCRxUW7p1lSXmMlZsvtX+23e1kctw02A==
X-Received: by 2002:a17:906:7d50:b0:a45:f1fa:a17d with SMTP id l16-20020a1709067d5000b00a45f1faa17dmr2704000ejp.25.1710350842139;
        Wed, 13 Mar 2024 10:27:22 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Wei Liu ,
	Stefano Stabellini ,
	Julien Grall ,
	Volodymyr Babchuk ,
	Bertrand Marquis ,
	Michal Orzel ,
	Oleksii Kurochko ,
	Shawn Anastasio ,
	"consulting @ bugseng . com" ,
	Simone Ballarin ,
	Federico Serafini ,
	Nicola Vetrini 
Subject: [PATCH 2/7] xen/bitops: Implement ffs() in common logic
Date: Wed, 13 Mar 2024 17:27:11 +0000
Message-Id: <20240313172716.2325427-3-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20240313172716.2325427-1-andrew.cooper3@citrix.com>
References: <20240313172716.2325427-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Allow the optimiser to elimiate the call completely, and use the compiler
builtin by default.  Architectures should only proide arch_ffs() if they think
they can do better than the compiler.

Confirm the expected behaviour with compile time and boot time tests.

For x86, correct the prototype, and simplify the asm() with the statement
given by the Intel architects to Linux about the behaviour on processors newer
than the 486.

For PPC, __builtin_ffs() is 1/3 of the size of size of the transform to
generic_fls().  Drop the definition entirely.

For ARM, simply rename ffs() to arch_ffs().  It appears that the
transformation to __builtin_clz() still makes better code than
__builtin_ffs().

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
CC: Wei Liu 
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Volodymyr Babchuk 
CC: Bertrand Marquis 
CC: Michal Orzel 
CC: Oleksii Kurochko 
CC: Shawn Anastasio 
CC: consulting@bugseng.com 
CC: Simone Ballarin 
CC: Federico Serafini 
CC: Nicola Vetrini 
---
 xen/arch/arm/include/asm/bitops.h |  2 +-
 xen/arch/ppc/include/asm/bitops.h |  1 -
 xen/arch/x86/include/asm/bitops.h | 19 +++++++++++++------
 xen/common/bitops.c               | 10 ++++++++++
 xen/include/xen/bitops.h          | 15 +++++++++++++++
 5 files changed, 39 insertions(+), 8 deletions(-)

diff --git a/xen/arch/arm/include/asm/bitops.h b/xen/arch/arm/include/asm/bitops.h
index ab030b6cb032..09c6064274a7 100644
--- a/xen/arch/arm/include/asm/bitops.h
+++ b/xen/arch/arm/include/asm/bitops.h
@@ -157,7 +157,7 @@ static inline int fls(unsigned int x)
 }
 
 
-#define ffs(x) ({ unsigned int __t = (x); fls(ISOLATE_LSB(__t)); })
+#define arch_ffs(x) ({ unsigned int __t = (x); fls(ISOLATE_LSB(__t)); })
 #define ffsl(x) ({ unsigned long __t = (x); flsl(ISOLATE_LSB(__t)); })
 
 /**
diff --git a/xen/arch/ppc/include/asm/bitops.h b/xen/arch/ppc/include/asm/bitops.h
index 5820b9ce7bb5..635a3b4e3e33 100644
--- a/xen/arch/ppc/include/asm/bitops.h
+++ b/xen/arch/ppc/include/asm/bitops.h
@@ -173,7 +173,6 @@ static inline int __test_and_clear_bit(int nr, volatile void *addr)
 
 #define flsl(x) generic_flsl(x)
 #define fls(x) generic_fls(x)
-#define ffs(x) ({ unsigned int t_ = (x); fls(t_ & -t_); })
 #define ffsl(x) ({ unsigned long t_ = (x); flsl(t_ & -t_); })
 
 /* Based on linux/include/asm-generic/bitops/ffz.h */
diff --git a/xen/arch/x86/include/asm/bitops.h b/xen/arch/x86/include/asm/bitops.h
index 5a71afbc89d5..2c5b103cbbd9 100644
--- a/xen/arch/x86/include/asm/bitops.h
+++ b/xen/arch/x86/include/asm/bitops.h
@@ -430,16 +430,23 @@ static inline int ffsl(unsigned long x)
     return (int)r+1;
 }
 
-static inline int ffs(unsigned int x)
+static inline unsigned int arch_ffs(unsigned int x)
 {
-    int r;
+    int r = -1;
+
+    /*
+     * The AMD manual states that BSF won't modify the destination register if
+     * x=0.  The Intel manual states that the result is undefined, but the
+     * architects have said that the register is written back with it's old
+     * value, possibly zero extended above 32 bits.
+     */
+    asm ( "bsf %[val], %[res]"
+          : [res] "+r" (r)
+          : [val] "rm" (x) );
 
-    asm ( "bsf %1,%0\n\t"
-          "jnz 1f\n\t"
-          "mov $-1,%0\n"
-          "1:" : "=r" (r) : "rm" (x));
     return r + 1;
 }
+#define arch_ffs arch_ffs
 
 /**
  * fls - find last bit set
diff --git a/xen/common/bitops.c b/xen/common/bitops.c
index 4c07191b4030..484df68768ad 100644
--- a/xen/common/bitops.c
+++ b/xen/common/bitops.c
@@ -34,8 +34,18 @@
         RUNTIME_CHECK(fn, val, res);            \
     } while ( 0 )
 
+static void test_ffs(void)
+{
+    /* unsigned int ffs(unsigned int) */
+    CHECK(ffs, 0, 0);
+    CHECK(ffs, 1, 1);
+    CHECK(ffs, 0x80000000U, 32);
+}
+
 static int __init cf_check test_bitops(void)
 {
+    test_ffs();
+
     return 0;
 }
 __initcall(test_bitops);
diff --git a/xen/include/xen/bitops.h b/xen/include/xen/bitops.h
index 9b40f20381a2..fb3645d9cf87 100644
--- a/xen/include/xen/bitops.h
+++ b/xen/include/xen/bitops.h
@@ -110,6 +110,21 @@ static inline int generic_flsl(unsigned long x)
 
 #include 
 
+/*
+ * Find First Set bit.  Bits are labelled from 1.
+ */
+static always_inline __pure unsigned int ffs(unsigned int x)
+{
+    if ( __builtin_constant_p(x) )
+        return __builtin_ffs(x);
+
+#ifndef arch_ffs
+#define arch_ffs __builtin_ffs
+#endif
+
+    return arch_ffs(x);
+}
+
 /* --------------------- Please tidy below here --------------------- */
 
 #ifndef find_next_bit
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Wed Mar 13 17:27:29 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 17:27:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692668.1079998 (Exim 4.92)
	(envelope-from )
	id 1rkSNw-0001lo-SE; Wed, 13 Mar 2024 17:27:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692668.1079998; Wed, 13 Mar 2024 17:27:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkSNw-0001lg-Pf; Wed, 13 Mar 2024 17:27:24 +0000
Received: by outflank-mailman (input) for mailman id 692668;
 Wed, 13 Mar 2024 17:27:23 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkSNv-0001lR-PM
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 17:27:23 +0000
Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com
 [2a00:1450:4864:20::132])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f234f549-e15e-11ee-a1ee-f123f15fe8a2;
 Wed, 13 Mar 2024 18:27:20 +0100 (CET)
Received: by mail-lf1-x132.google.com with SMTP id
 2adb3069b0e04-513af1a29b1so131831e87.1
 for ; Wed, 13 Mar 2024 10:27:20 -0700 (PDT)
Received: from andrewcoop.citrite.net (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 f15-20020a170906048f00b00a42ee62b634sm5005732eja.106.2024.03.13.10.27.17
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 13 Mar 2024 10:27:18 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f234f549-e15e-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710350839; x=1710955639; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:from:to:cc:subject:date:message-id:reply-to;
        bh=pyLwwVFgBnHc3nFQowSZW9Ad/7H+CSvbIhdAvxdTYsw=;
        b=GlHoAD3iso2LNjQ+hcrnJGYqAANPWb3PYb6VQ0UNuMtUzZeOnzsUpHaKdTuFUBvhpx
         b7Y4E8GH9nJwyxHrGZpYfBLu7+GlPmdhjWJth+6q2zXNawSU4IbQjfiLMhGX9wnOXK/8
         C7TqLr3+HeQi/JXZckRr4YaGtqFfcIx3rNqDA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710350839; x=1710955639;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=pyLwwVFgBnHc3nFQowSZW9Ad/7H+CSvbIhdAvxdTYsw=;
        b=D3YQaUh9hEKIehNqP92AFbgoeZURrN/WYLWOdiIHof1HerhrfPHabrhFb/zjwvCwm2
         T/Hk0ikJdHwsTnglTcs7AImoLGQ8XwfTiYKnCjPTaO3y0Jac56m4uJ4YD1EE5Bq/uJEl
         9KULkMGeqkuED9hE9apF2cWnW28TpbN/TpWuMxDQKzsNiwEnUVnL+4ycmWknin6UsX5i
         yhDCFuxsvJGzqnrxWqfU1RgKCmzWi1rGUe0l+wWwY3VcGcLoX94Jze+OiExV3K61fvgD
         7WDL5MgYnECU6IiN9bEfjtMPsUOymlE0YCRf48obMRxglZmmJH/WBxEQn9gsraj4fZ0x
         qThg==
X-Gm-Message-State: AOJu0YzTFP2LwZlsM1Tjr+aDk3R7UvdIWEzH5qBcNwx4g1RpOQqJcDWq
	YyKzPZlY36kcqQUBF12W82P/k6s6GhKz9vLTZ5+2YC5kw2tpTjmudjk3LrojbiJMPqBegv03NDn
	H
X-Google-Smtp-Source: AGHT+IEDKPvTYZ7XDnessGq8xmW9ZOY5dodKLoW5fce8u1aLcMsw6ykbZTFo5kj61Z9Xuhn9yVhX6g==
X-Received: by 2002:a05:6512:3baa:b0:513:b102:7d93 with SMTP id g42-20020a0565123baa00b00513b1027d93mr8028462lfv.24.1710350839245;
        Wed, 13 Mar 2024 10:27:19 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Wei Liu ,
	Stefano Stabellini ,
	Julien Grall ,
	Volodymyr Babchuk ,
	Bertrand Marquis ,
	Michal Orzel ,
	Oleksii Kurochko ,
	Shawn Anastasio ,
	"consulting @ bugseng . com" ,
	Simone Ballarin ,
	Federico Serafini ,
	Nicola Vetrini 
Subject: [PATCH 0/7] xen/bitops: Reduce the mess, starting with ffs()
Date: Wed, 13 Mar 2024 17:27:09 +0000
Message-Id: <20240313172716.2325427-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.30.2
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

bitops.h is a mess.  It has grown organtically over many years, and forces
unreasonable repsonsibilities out into the per-arch stubs.

Start cleaning it up with ffs() and friends.  Across the board, this adds:

 * Functioning bitops without arch-specific asm
 * An option for arches to provide more optimal code generation
 * Compile-time constant folding
 * Testing at both compile time and during init that the basic operations
   behave according to spec.

and the only reason this series isn't a net reduction in code alone is the
because of the testing infrastructure in patch 1.

This form is superior in many ways, including getting RISC-V support for free.

Testing:
  https://gitlab.com/xen-project/people/andyhhp/xen/-/pipelines/1212269924
  https://cirrus-ci.com/build/4939856296542208

Andrew Cooper (7):
  xen/bitops: Cleanup ahead of rearrangements
  xen/bitops: Implement ffs() in common logic
  xen/bitops: Implement ffsl() in common logic
  xen/bitops: Delete generic_ffs{,l}()
  xen/bitops: Implement ffs64() in common logic
  xen: Swap find_first_set_bit() for ffsl() - 1
  xen/bitops: Delete find_first_set_bit()

 xen/arch/arm/include/asm/bitops.h            | 16 +---
 xen/arch/ppc/include/asm/bitops.h            | 11 ---
 xen/arch/x86/guest/xen/xen.c                 |  4 +-
 xen/arch/x86/hvm/dom0_build.c                |  2 +-
 xen/arch/x86/hvm/hpet.c                      |  8 +-
 xen/arch/x86/include/asm/bitops.h            | 53 +++++------
 xen/arch/x86/include/asm/pt-contig-markers.h |  2 +-
 xen/arch/x86/mm.c                            |  2 +-
 xen/arch/x86/mm/p2m-pod.c                    |  4 +-
 xen/common/Makefile                          |  1 +
 xen/common/bitops.c                          | 70 ++++++++++++++
 xen/common/page_alloc.c                      |  2 +-
 xen/common/softirq.c                         |  2 +-
 xen/drivers/passthrough/amd/iommu_map.c      |  2 +-
 xen/drivers/passthrough/iommu.c              |  4 +-
 xen/drivers/passthrough/x86/iommu.c          |  4 +-
 xen/include/xen/bitops.h                     | 97 +++++++++-----------
 xen/include/xen/compiler.h                   |  3 +-
 18 files changed, 160 insertions(+), 127 deletions(-)
 create mode 100644 xen/common/bitops.c


base-commit: 03cf7ca23e0e876075954c558485b267b7d02406
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Wed Mar 13 17:27:29 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 17:27:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692671.1080025 (Exim 4.92)
	(envelope-from )
	id 1rkSNy-0002LX-SK; Wed, 13 Mar 2024 17:27:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692671.1080025; Wed, 13 Mar 2024 17:27:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkSNy-0002JF-Mw; Wed, 13 Mar 2024 17:27:26 +0000
Received: by outflank-mailman (input) for mailman id 692671;
 Wed, 13 Mar 2024 17:27:25 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkSNx-00023P-SW
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 17:27:25 +0000
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com
 [2a00:1450:4864:20::634])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f4f4daec-e15e-11ee-afdd-a90da7624cb6;
 Wed, 13 Mar 2024 18:27:24 +0100 (CET)
Received: by mail-ej1-x634.google.com with SMTP id
 a640c23a62f3a-a28a6cef709so11269366b.1
 for ; Wed, 13 Mar 2024 10:27:24 -0700 (PDT)
Received: from andrewcoop.citrite.net (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 f15-20020a170906048f00b00a42ee62b634sm5005732eja.106.2024.03.13.10.27.22
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 13 Mar 2024 10:27:22 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f4f4daec-e15e-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710350844; x=1710955644; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=wlFjhhn3RPAHKYuNj8Ur+L4ReTenR22KzyO8QJjXINY=;
        b=GJeeMxi+KKJqEGwVMksOZSo3oH6lFTcjQL9pAIs7VESJnWBZ76YvozGPLTxn9Ainf3
         vwSUWdfuXponQlsTw11Uis+6Scr0hEIhYgnKv7mwdln/JhK0K6JVluYCHjcupC+eNryd
         LAXYzoZhAlvkRJDWwhNrD+xgRq4FmNSWkDJtQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710350844; x=1710955644;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=wlFjhhn3RPAHKYuNj8Ur+L4ReTenR22KzyO8QJjXINY=;
        b=iqDB5oK5IJgHTDFvijlxzOnTH87QxXCnzi+BVxovy/361EvLHPhZhFFymRQYFqYa+0
         xlY43Rt6i1z/QfysywIKgIf/PtsHqDrWj/fXXBH96h//lXNj+UtBx/10Z2D2HWPJW1ew
         whWQaJCIkNFcrJmOiXY8j706f9m6DVzhAAoX+qaJmuhvgi2yesU44q69bRSDAmf9mY+z
         e9lVyohUWelVPSQgED94YHsieymIz6B6zEyvqrCg/zDxk1N4L8pyL2ENhQeR6jH5MFJ7
         eG7zXmyUpN3KW4A0Sa0e4iZj8mHwiMWOfaoJVCLVqMghonG8wVo0N/NN7rZ182yHeTLD
         GLBA==
X-Gm-Message-State: AOJu0YzSh06GChDqQvEXzEZ4ugWqLebxNBRBuS8smz1VziY5f3itZZYw
	DUJZ0J028PS9COEPGTzjtbAQXPBrijt1njIg5W/9Dojq2Y0d6Ns//PoVgy1b8fK2QEH/rAe7gqb
	q
X-Google-Smtp-Source: AGHT+IGyRscQkGqeocdnAjLem4S/ovvLA2xS7fr6bR6SxeaGoAp/cZ5SJUKwtSqtY3P3ypAv9a2rLA==
X-Received: by 2002:a17:907:1681:b0:a46:1e16:317c with SMTP id cx1-20020a170907168100b00a461e16317cmr8639997ejd.55.1710350844192;
        Wed, 13 Mar 2024 10:27:24 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Wei Liu ,
	Stefano Stabellini ,
	Julien Grall ,
	Volodymyr Babchuk ,
	Bertrand Marquis ,
	Michal Orzel ,
	Oleksii Kurochko ,
	Shawn Anastasio ,
	"consulting @ bugseng . com" ,
	Simone Ballarin ,
	Federico Serafini ,
	Nicola Vetrini 
Subject: [PATCH 3/7] xen/bitops: Implement ffsl() in common logic
Date: Wed, 13 Mar 2024 17:27:12 +0000
Message-Id: <20240313172716.2325427-4-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20240313172716.2325427-1-andrew.cooper3@citrix.com>
References: <20240313172716.2325427-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Exactly as per ffs() in the previous patch.  Express the upper bound of the
testing in terms of BITS_PER_LONG as it varies between architectures.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
CC: Wei Liu 
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Volodymyr Babchuk 
CC: Bertrand Marquis 
CC: Michal Orzel 
CC: Oleksii Kurochko 
CC: Shawn Anastasio 
CC: consulting@bugseng.com 
CC: Simone Ballarin 
CC: Federico Serafini 
CC: Nicola Vetrini 
---
 xen/arch/arm/include/asm/bitops.h |  2 +-
 xen/arch/ppc/include/asm/bitops.h |  1 -
 xen/arch/x86/include/asm/bitops.h | 30 +++++++++++++-----------------
 xen/common/bitops.c               |  7 +++++++
 xen/include/xen/bitops.h          | 12 ++++++++++++
 5 files changed, 33 insertions(+), 19 deletions(-)

diff --git a/xen/arch/arm/include/asm/bitops.h b/xen/arch/arm/include/asm/bitops.h
index 09c6064274a7..59ae8ed150b6 100644
--- a/xen/arch/arm/include/asm/bitops.h
+++ b/xen/arch/arm/include/asm/bitops.h
@@ -158,7 +158,7 @@ static inline int fls(unsigned int x)
 
 
 #define arch_ffs(x) ({ unsigned int __t = (x); fls(ISOLATE_LSB(__t)); })
-#define ffsl(x) ({ unsigned long __t = (x); flsl(ISOLATE_LSB(__t)); })
+#define arch_ffsl(x) ({ unsigned long __t = (x); flsl(ISOLATE_LSB(__t)); })
 
 /**
  * find_first_set_bit - find the first set bit in @word
diff --git a/xen/arch/ppc/include/asm/bitops.h b/xen/arch/ppc/include/asm/bitops.h
index 635a3b4e3e33..ecec2a826660 100644
--- a/xen/arch/ppc/include/asm/bitops.h
+++ b/xen/arch/ppc/include/asm/bitops.h
@@ -173,7 +173,6 @@ static inline int __test_and_clear_bit(int nr, volatile void *addr)
 
 #define flsl(x) generic_flsl(x)
 #define fls(x) generic_fls(x)
-#define ffsl(x) ({ unsigned long t_ = (x); flsl(t_ & -t_); })
 
 /* Based on linux/include/asm-generic/bitops/ffz.h */
 /*
diff --git a/xen/arch/x86/include/asm/bitops.h b/xen/arch/x86/include/asm/bitops.h
index 2c5b103cbbd9..99342877e32f 100644
--- a/xen/arch/x86/include/asm/bitops.h
+++ b/xen/arch/x86/include/asm/bitops.h
@@ -413,23 +413,6 @@ static inline unsigned int find_first_set_bit(unsigned long word)
     return (unsigned int)word;
 }
 
-/**
- * ffs - find first bit set
- * @x: the word to search
- *
- * This is defined the same way as the libc and compiler builtin ffs routines.
- */
-static inline int ffsl(unsigned long x)
-{
-    long r;
-
-    asm ( "bsf %1,%0\n\t"
-          "jnz 1f\n\t"
-          "mov $-1,%0\n"
-          "1:" : "=r" (r) : "rm" (x));
-    return (int)r+1;
-}
-
 static inline unsigned int arch_ffs(unsigned int x)
 {
     int r = -1;
@@ -448,6 +431,19 @@ static inline unsigned int arch_ffs(unsigned int x)
 }
 #define arch_ffs arch_ffs
 
+static inline unsigned int arch_ffsl(unsigned long x)
+{
+    long r = -1;
+
+    /* See arch_ffs() for safety discussion. */
+    asm ( "bsf %[val], %[res]"
+          : [res] "+r" (r)
+          : [val] "rm" (x) );
+
+    return r + 1;
+}
+#define arch_ffsl arch_ffsl
+
 /**
  * fls - find last bit set
  * @x: the word to search
diff --git a/xen/common/bitops.c b/xen/common/bitops.c
index 484df68768ad..eceffe5029d6 100644
--- a/xen/common/bitops.c
+++ b/xen/common/bitops.c
@@ -40,6 +40,13 @@ static void test_ffs(void)
     CHECK(ffs, 0, 0);
     CHECK(ffs, 1, 1);
     CHECK(ffs, 0x80000000U, 32);
+
+    /* unsigned int ffsl(unsigned long) */
+    CHECK(ffsl, 0, 0);
+    CHECK(ffsl, 1, 1);
+    CHECK(ffsl, 1UL << (BITS_PER_LONG - 1), BITS_PER_LONG);
+    if ( BITS_PER_LONG > 32 )
+        CHECK(ffsl, 1UL << 32, 33);
 }
 
 static int __init cf_check test_bitops(void)
diff --git a/xen/include/xen/bitops.h b/xen/include/xen/bitops.h
index fb3645d9cf87..a37b42342bc5 100644
--- a/xen/include/xen/bitops.h
+++ b/xen/include/xen/bitops.h
@@ -125,6 +125,18 @@ static always_inline __pure unsigned int ffs(unsigned int x)
     return arch_ffs(x);
 }
 
+static always_inline __pure unsigned int ffsl(unsigned long x)
+{
+    if ( __builtin_constant_p(x) )
+        return __builtin_ffsl(x);
+
+#ifndef arch_ffsl
+#define arch_ffsl __builtin_ffsl
+#endif
+
+    return arch_ffsl(x);
+}
+
 /* --------------------- Please tidy below here --------------------- */
 
 #ifndef find_next_bit
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Wed Mar 13 17:27:29 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 17:27:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692669.1080002 (Exim 4.92)
	(envelope-from )
	id 1rkSNx-0001p5-4b; Wed, 13 Mar 2024 17:27:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692669.1080002; Wed, 13 Mar 2024 17:27:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkSNx-0001oL-0g; Wed, 13 Mar 2024 17:27:25 +0000
Received: by outflank-mailman (input) for mailman id 692669;
 Wed, 13 Mar 2024 17:27:24 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkSNw-0001lR-0k
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 17:27:24 +0000
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com
 [2a00:1450:4864:20::62d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f3206778-e15e-11ee-a1ee-f123f15fe8a2;
 Wed, 13 Mar 2024 18:27:21 +0100 (CET)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-a466a1f9ea0so11607266b.1
 for ; Wed, 13 Mar 2024 10:27:21 -0700 (PDT)
Received: from andrewcoop.citrite.net (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 f15-20020a170906048f00b00a42ee62b634sm5005732eja.106.2024.03.13.10.27.19
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 13 Mar 2024 10:27:19 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f3206778-e15e-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710350840; x=1710955640; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=z/bXHNWyZkTLicGysMRuS+mhbdjAEJwJyFIm3Wfcg6A=;
        b=PBaPTIjeHQfhYt3S01T0O1dQwOA9fFVtYeF7mirFDdDbl43ITmtKXPmepfXq/r5WWX
         Ydc3cWAEeTV8F0ItQ2GE2N6Hz3bFKKjLed9sb29Ps92ERQZiQ4fOccrg+jDT6sN55Jgv
         9LHfdoX5gccWmqJFLvkrNyhWtrhhmjBDiPo4I=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710350840; x=1710955640;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=z/bXHNWyZkTLicGysMRuS+mhbdjAEJwJyFIm3Wfcg6A=;
        b=n9ocQOz6S+kYUcy0wRHUGawr3L9WcdAnaLXDLPdZFvmKGmCsAIUm3/TVNOXp5d00bH
         0Uu5JsO5QyJRwzi4HdhiM/KUJfKeXYLCcM/2YrlceIn1fOgR2m56IQRR5VMqtjftWKOl
         n1lwefK7+q7A1hmAvCZ0cS6TjvQLlnZUBJ2Eku6u/PJAT7j9jLFchvWF5NqqfTV/Xhbk
         p/mQMf6+oe3yHvuULVO74TsK9WCzoYr7m11X7ZMc4eZ/fQiKHtXPTgb0PXTX9sZD8QA4
         jyPfk/+283Ov9aC7ef1flRX7QOeFRmTRQXf/iXBNtyVP4jcGnWCsydvRx0dBlFNGMCzt
         fE1w==
X-Gm-Message-State: AOJu0Yx+6/LKWuhOOARTlfS3v7qeRN+buJcIG3XFeQfeYnjLmMqQ1sLD
	G1Hl7Ybmfw6LO53rHMoI0Z/+OYHPl6QdMmb3yeSJhIVB8HBR4iNTK6e6WhEWLeK/c2AYWEhBBtn
	l
X-Google-Smtp-Source: AGHT+IG5eOM/N8WPQ+tLKnromzM4xSu+1XcAJsvPgdf1Zalb2TQYPjNhcC8YFhYbXe6S0A8CFLD9yw==
X-Received: by 2002:a17:907:a093:b0:a45:54f3:b44d with SMTP id hu19-20020a170907a09300b00a4554f3b44dmr9508916ejc.8.1710350840553;
        Wed, 13 Mar 2024 10:27:20 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Wei Liu ,
	Stefano Stabellini ,
	Julien Grall ,
	Volodymyr Babchuk ,
	Bertrand Marquis ,
	Michal Orzel ,
	Oleksii Kurochko ,
	Shawn Anastasio ,
	"consulting @ bugseng . com" ,
	Simone Ballarin ,
	Federico Serafini ,
	Nicola Vetrini 
Subject: [PATCH 1/7] xen/bitops: Cleanup ahead of rearrangements
Date: Wed, 13 Mar 2024 17:27:10 +0000
Message-Id: <20240313172716.2325427-2-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20240313172716.2325427-1-andrew.cooper3@citrix.com>
References: <20240313172716.2325427-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

 * Rename __attribute_pure__ to just __pure before it gains users.
 * Identify the areas of xen/bitops.h which are a mess.
 * Create common/bitops.c for compile and runtime testing.  This provides a
   statement of the ABI, and a confirmation that arch-specific implementations
   behave as expected.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
CC: Wei Liu 
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Volodymyr Babchuk 
CC: Bertrand Marquis 
CC: Michal Orzel 
CC: Oleksii Kurochko 
CC: Shawn Anastasio 
CC: consulting@bugseng.com 
CC: Simone Ballarin 
CC: Federico Serafini 
CC: Nicola Vetrini 

I expect MISRA will have something to say about the macros here, but they are
in aid of better testing.
---
 xen/common/Makefile        |  1 +
 xen/common/bitops.c        | 41 ++++++++++++++++++++++++++++++++++++++
 xen/include/xen/bitops.h   | 13 +++++++++---
 xen/include/xen/compiler.h |  3 ++-
 4 files changed, 54 insertions(+), 4 deletions(-)
 create mode 100644 xen/common/bitops.c

diff --git a/xen/common/Makefile b/xen/common/Makefile
index e5eee19a8537..1f8ca9a2f4f8 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -1,5 +1,6 @@
 obj-$(CONFIG_ARGO) += argo.o
 obj-y += bitmap.o
+obj-y += bitops.o
 obj-$(CONFIG_GENERIC_BUG_FRAME) += bug.o
 obj-$(CONFIG_HYPFS_CONFIG) += config_data.o
 obj-$(CONFIG_CORE_PARKING) += core_parking.o
diff --git a/xen/common/bitops.c b/xen/common/bitops.c
new file mode 100644
index 000000000000..4c07191b4030
--- /dev/null
+++ b/xen/common/bitops.c
@@ -0,0 +1,41 @@
+#include 
+#include 
+#include 
+
+/* Hide a value from the optimiser. */
+#define HIDE(x) ({ typeof(x) _x = x; asm volatile ( "" : "+r" (_x) ); _x; })
+
+/*
+ * Check that fn(val) can be calcuated by the compiler, and that it gives the
+ * expected answer.
+ */
+#define COMPILE_CHECK(fn, val, res)                                     \
+    do {                                                                \
+        if ( fn(val) != res )                                           \
+            asm (".error \"Compile time check '" STR(fn(val) == res) "' failed\""); \
+    } while ( 0 )
+
+/*
+ * Check that Xen's runtime logic for fn(val) gives the expected answer.  This
+ * requires using HIDE() to prevent the optimiser from emitting the full
+ * calculation.
+ */
+#define RUNTIME_CHECK(fn, val, res)             \
+    do {                                        \
+        BUG_ON(fn(HIDE(val)) != res);           \
+    } while ( 0 )
+
+/*
+ * Perform compiletime and runtime checks for fn(val) == res.
+ */
+#define CHECK(fn, val, res)                     \
+    do {                                        \
+        COMPILE_CHECK(fn, val, res);            \
+        RUNTIME_CHECK(fn, val, res);            \
+    } while ( 0 )
+
+static int __init cf_check test_bitops(void)
+{
+    return 0;
+}
+__initcall(test_bitops);
diff --git a/xen/include/xen/bitops.h b/xen/include/xen/bitops.h
index e3c5a4ccf321..9b40f20381a2 100644
--- a/xen/include/xen/bitops.h
+++ b/xen/include/xen/bitops.h
@@ -1,5 +1,7 @@
-#ifndef _LINUX_BITOPS_H
-#define _LINUX_BITOPS_H
+#ifndef XEN_BITOPS_H
+#define XEN_BITOPS_H
+
+#include 
 #include 
 
 /*
@@ -103,8 +105,13 @@ static inline int generic_flsl(unsigned long x)
  * Include this here because some architectures need generic_ffs/fls in
  * scope
  */
+
+/* --------------------- Please tidy above here --------------------- */
+
 #include 
 
+/* --------------------- Please tidy below here --------------------- */
+
 #ifndef find_next_bit
 /**
  * find_next_bit - find the next set bit in a memory region
@@ -294,4 +301,4 @@ static inline __u32 ror32(__u32 word, unsigned int shift)
 
 #define BIT_WORD(nr) ((nr) / BITS_PER_LONG)
 
-#endif
+#endif /* XEN_BITOPS_H */
diff --git a/xen/include/xen/compiler.h b/xen/include/xen/compiler.h
index 16d554f2a593..972719df55b3 100644
--- a/xen/include/xen/compiler.h
+++ b/xen/include/xen/compiler.h
@@ -85,7 +85,8 @@
 #define inline inline __init
 #endif
 
-#define __attribute_pure__  __attribute__((__pure__))
+#define __pure  __attribute__((__pure__))
+
 #define __attribute_const__ __attribute__((__const__))
 #define __transparent__     __attribute__((__transparent_union__))
 
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Wed Mar 13 17:27:30 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 17:27:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692673.1080048 (Exim 4.92)
	(envelope-from )
	id 1rkSO2-00031b-Cc; Wed, 13 Mar 2024 17:27:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692673.1080048; Wed, 13 Mar 2024 17:27:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkSO2-00031M-9I; Wed, 13 Mar 2024 17:27:30 +0000
Received: by outflank-mailman (input) for mailman id 692673;
 Wed, 13 Mar 2024 17:27:29 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkSO1-0001lR-2a
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 17:27:29 +0000
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com
 [2a00:1450:4864:20::52a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f68109f2-e15e-11ee-a1ee-f123f15fe8a2;
 Wed, 13 Mar 2024 18:27:27 +0100 (CET)
Received: by mail-ed1-x52a.google.com with SMTP id
 4fb4d7f45d1cf-5686677bda1so2152011a12.0
 for ; Wed, 13 Mar 2024 10:27:27 -0700 (PDT)
Received: from andrewcoop.citrite.net (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 f15-20020a170906048f00b00a42ee62b634sm5005732eja.106.2024.03.13.10.27.25
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 13 Mar 2024 10:27:25 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f68109f2-e15e-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710350846; x=1710955646; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=bHB0TnvHPBNz/eBFlKRD6r+XgGXUhXiQaqNnXVkmHEM=;
        b=HdiEIEtty4EKP+6iQXwJ7Bt+loJ55OXEBPtpvmCYFUqN3Zef/4qEwlbqVl4y+sErbQ
         C5d1l+r2Hlloip+TdwNAW+s7lmnLgWbuC85Mpxppq+Q3SMeECWlQ+w72D/VQUlp85RBh
         YxFOAn7A0or7U7VSza9aFX2gqhvX3Wj0SRnzo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710350846; x=1710955646;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=bHB0TnvHPBNz/eBFlKRD6r+XgGXUhXiQaqNnXVkmHEM=;
        b=Wm22WpHdZS+NjEkcb5Wi90FSbSDCp2Tu8h9JQzWvVkxLPiwDE+Ni11EpEDp822n/0W
         sPxLNq/kmtVKrATSZaCOj5IxEDXLLRnPOtVWaHcqpeo7G6do12XAdhcKisI+JMlp4o84
         xWul3qLDQ7PPbXjjLHAIFeXirNHa5hXrYbTjKOxEdsg8UjcKYqWfYWD7NPzw0LwR73+b
         yeSJlYuMhbPnpiTHrpqT9it/0jfqlAhHuE0Ds/5CogU3RY9sHWsqdspJ3i7hzSfdqhgr
         tbUg1Fl4TeYA4gluIAsWtVxIkVjEJ3PZRPrmd3WeBTebKZ8MozQCJcmhKNLUj64S7pKM
         DoKg==
X-Gm-Message-State: AOJu0YxI7yVkuGgvUNwM9/GZH0ccwjvVT/OxIv9JBGprZkpe8oTzfQht
	tHBQOMBP7jbsNbjVJScMVEYsU8klwSdyv3ywcvBVuFlLnEsQAvAcBtP6fdOak0uxoRVZftGBIUt
	S
X-Google-Smtp-Source: AGHT+IGIO5zs05MQAfaMrOvXvlJvj/CQCBKQvepFuzD0oSVa3+Yg0TZEOonx3qZaJ0qsoNzwif8sQw==
X-Received: by 2002:a17:906:b00f:b0:a44:806f:ad56 with SMTP id v15-20020a170906b00f00b00a44806fad56mr2736937ejy.11.1710350846637;
        Wed, 13 Mar 2024 10:27:26 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Wei Liu ,
	Stefano Stabellini ,
	Julien Grall ,
	Volodymyr Babchuk ,
	Bertrand Marquis ,
	Michal Orzel ,
	Oleksii Kurochko ,
	Shawn Anastasio ,
	"consulting @ bugseng . com" ,
	Simone Ballarin ,
	Federico Serafini ,
	Nicola Vetrini 
Subject: [PATCH 5/7] xen/bitops: Implement ffs64() in common logic
Date: Wed, 13 Mar 2024 17:27:14 +0000
Message-Id: <20240313172716.2325427-6-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20240313172716.2325427-1-andrew.cooper3@citrix.com>
References: <20240313172716.2325427-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

As per ffs()/ffsl() in previous patches.  Add tests for all interesting bit
positions at 32bit boundaries.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
CC: Wei Liu 
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Volodymyr Babchuk 
CC: Bertrand Marquis 
CC: Michal Orzel 
CC: Oleksii Kurochko 
CC: Shawn Anastasio 
CC: consulting@bugseng.com 
CC: Simone Ballarin 
CC: Federico Serafini 
CC: Nicola Vetrini 
---
 xen/common/bitops.c      | 12 ++++++++++++
 xen/include/xen/bitops.h | 16 ++++++++--------
 2 files changed, 20 insertions(+), 8 deletions(-)

diff --git a/xen/common/bitops.c b/xen/common/bitops.c
index eceffe5029d6..cd194fe672b7 100644
--- a/xen/common/bitops.c
+++ b/xen/common/bitops.c
@@ -47,6 +47,18 @@ static void test_ffs(void)
     CHECK(ffsl, 1UL << (BITS_PER_LONG - 1), BITS_PER_LONG);
     if ( BITS_PER_LONG > 32 )
         CHECK(ffsl, 1UL << 32, 33);
+
+    /*
+     * unsigned int ffs64(uint64_t)
+     *
+     * 32-bit builds of Xen have to split this into two adjacent operations,
+     * so test all interesting bit positions.
+     */
+    CHECK(ffs64, 0, 0);
+    CHECK(ffs64, 1, 1);
+    CHECK(ffs64, (uint64_t)0x0000000080000000, 32);
+    CHECK(ffs64, (uint64_t)0x0000000100000000, 33);
+    CHECK(ffs64, (uint64_t)0x8000000000000000, 64);
 }
 
 static int __init cf_check test_bitops(void)
diff --git a/xen/include/xen/bitops.h b/xen/include/xen/bitops.h
index b85b35c40781..f14ad0d33aa3 100644
--- a/xen/include/xen/bitops.h
+++ b/xen/include/xen/bitops.h
@@ -96,6 +96,14 @@ static always_inline __pure unsigned int ffsl(unsigned long x)
     return arch_ffsl(x);
 }
 
+static always_inline __pure unsigned int ffs64(uint64_t x)
+{
+    if ( BITS_PER_LONG == 64 )
+        return ffsl(x);
+    else
+        return !x || (uint32_t)x ? ffs(x) : ffs(x >> 32) + 32;
+}
+
 /* --------------------- Please tidy below here --------------------- */
 
 #ifndef find_next_bit
@@ -148,15 +156,7 @@ extern unsigned long find_first_zero_bit(const unsigned long *addr,
 
 #if BITS_PER_LONG == 64
 # define fls64 flsl
-# define ffs64 ffsl
 #else
-# ifndef ffs64
-static inline int generic_ffs64(__u64 x)
-{
-    return !x || (__u32)x ? ffs(x) : ffs(x >> 32) + 32;
-}
-#  define ffs64 generic_ffs64
-# endif
 # ifndef fls64
 static inline int generic_fls64(__u64 x)
 {
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Wed Mar 13 17:27:33 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 17:27:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692674.1080058 (Exim 4.92)
	(envelope-from )
	id 1rkSO4-0003KC-NK; Wed, 13 Mar 2024 17:27:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692674.1080058; Wed, 13 Mar 2024 17:27:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkSO4-0003K3-KE; Wed, 13 Mar 2024 17:27:32 +0000
Received: by outflank-mailman (input) for mailman id 692674;
 Wed, 13 Mar 2024 17:27:30 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkSO2-0001lR-EE
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 17:27:30 +0000
Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com
 [2a00:1450:4864:20::636])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f738e570-e15e-11ee-a1ee-f123f15fe8a2;
 Wed, 13 Mar 2024 18:27:28 +0100 (CET)
Received: by mail-ej1-x636.google.com with SMTP id
 a640c23a62f3a-a46682e71a9so9111466b.3
 for ; Wed, 13 Mar 2024 10:27:28 -0700 (PDT)
Received: from andrewcoop.citrite.net (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 f15-20020a170906048f00b00a42ee62b634sm5005732eja.106.2024.03.13.10.27.26
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 13 Mar 2024 10:27:27 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f738e570-e15e-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710350848; x=1710955648; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=42OziT0p0S95gIbK7k1NI+z53JEbfaX+0bPN+VqyNws=;
        b=NLpoAP1pmRjhQeTgPHFob4IXM4K69d91fLRP41wKjX8WysAXj4kZL0vM96vnQ+z1qV
         RaDsM8kEfO7IVaTz9pVqkr2+1Lo7mWo2/JB6LpJjuywQQ8ZU2rruXSsjeYI7k3PnyPNc
         Vu5/9sGuMKo1LShOrJRfCGAB3f1YOQwjoDAIk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710350848; x=1710955648;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=42OziT0p0S95gIbK7k1NI+z53JEbfaX+0bPN+VqyNws=;
        b=GBwY1cv47zhZ5iocf4BPCYspFyaWRP9sOY6jMJeLQUqvExqvcB1duPfURMeH9uoM/T
         li7WuPzTR0I9wB+PkDOXh+Awhj1ajWhqrDCzgJ1QRO/Iz5pMp1fEJw9HqMEncjM17IWE
         PtQCwuQmHULv6KM6rnU3yV6289hVO0j/sGF82Emu7WvCGRViYERvDSRcrHfhMRMtI0EJ
         LBpDe4Efb4HjWHGACGq8zxW996/jIQnPqp8Vt/xU3b5ycAhEU691odoJNpRQScXu3nyL
         Htgn6O71T13nbUPYzUcU/ZyDBZN5pnYJqDScrpqkDJdaUflNj9HTdfbjN5vA8IOvIlFl
         +HGQ==
X-Gm-Message-State: AOJu0Yws3/bs8krlmaBv68J4QoTLquOrc/nKfOq1HrL92R+nTWkIC8sQ
	2eXxFWXXS7cnh0yDqDuW0WxvZmSbzvWgj3yXRgnl8KuHgjzNzHgBkFZHxtUe2rm+qXpYmTT6Fha
	Q
X-Google-Smtp-Source: AGHT+IHDA9kAwEE71Zrgue/ZSZqfSO4un1kmimxgYrjALg0+zIY9/UH8mGWH25XVKZ8g/4LSy1rdDA==
X-Received: by 2002:a17:907:104b:b0:a45:bcac:c7e0 with SMTP id oy11-20020a170907104b00b00a45bcacc7e0mr8414663ejb.65.1710350847919;
        Wed, 13 Mar 2024 10:27:27 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Wei Liu ,
	Stefano Stabellini ,
	Julien Grall ,
	Volodymyr Babchuk ,
	Bertrand Marquis ,
	Michal Orzel ,
	Oleksii Kurochko ,
	Shawn Anastasio ,
	"consulting @ bugseng . com" ,
	Simone Ballarin ,
	Federico Serafini ,
	Nicola Vetrini 
Subject: [PATCH 6/7] xen: Swap find_first_set_bit() for ffsl() - 1
Date: Wed, 13 Mar 2024 17:27:15 +0000
Message-Id: <20240313172716.2325427-7-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20240313172716.2325427-1-andrew.cooper3@citrix.com>
References: <20240313172716.2325427-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

find_first_set_bit() is a Xen-ism which has undefined behaviour with a 0
input.  The latter is well defined with an input of 0, and is a found outside
of Xen too.

_init_heap_pages() is the one special case here, comparing the LSB of two
different addresses.  The -1 cancels off both sides of the expression.

No functional change.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
CC: Wei Liu 
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Volodymyr Babchuk 
CC: Bertrand Marquis 
CC: Michal Orzel 
CC: Oleksii Kurochko 
CC: Shawn Anastasio 
CC: consulting@bugseng.com 
CC: Simone Ballarin 
CC: Federico Serafini 
CC: Nicola Vetrini 
---
 xen/arch/x86/guest/xen/xen.c                 | 4 ++--
 xen/arch/x86/hvm/dom0_build.c                | 2 +-
 xen/arch/x86/hvm/hpet.c                      | 8 ++++----
 xen/arch/x86/include/asm/pt-contig-markers.h | 2 +-
 xen/arch/x86/mm.c                            | 2 +-
 xen/arch/x86/mm/p2m-pod.c                    | 4 ++--
 xen/common/page_alloc.c                      | 2 +-
 xen/common/softirq.c                         | 2 +-
 xen/drivers/passthrough/amd/iommu_map.c      | 2 +-
 xen/drivers/passthrough/iommu.c              | 4 ++--
 xen/drivers/passthrough/x86/iommu.c          | 4 ++--
 11 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/xen/arch/x86/guest/xen/xen.c b/xen/arch/x86/guest/xen/xen.c
index d9768cc9527d..7484b3f73ad3 100644
--- a/xen/arch/x86/guest/xen/xen.c
+++ b/xen/arch/x86/guest/xen/xen.c
@@ -168,14 +168,14 @@ static void cf_check xen_evtchn_upcall(void)
 
     while ( pending )
     {
-        unsigned int l1 = find_first_set_bit(pending);
+        unsigned int l1 = ffsl(pending) - 1;
         unsigned long evtchn = xchg(&XEN_shared_info->evtchn_pending[l1], 0);
 
         __clear_bit(l1, &pending);
         evtchn &= ~XEN_shared_info->evtchn_mask[l1];
         while ( evtchn )
         {
-            unsigned int port = find_first_set_bit(evtchn);
+            unsigned int port = ffsl(evtchn) - 1;
 
             __clear_bit(port, &evtchn);
             port += l1 * BITS_PER_LONG;
diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index bbae8a564522..7bc092675628 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -139,7 +139,7 @@ static int __init pvh_populate_memory_range(struct domain *d,
         order = get_order_from_pages(end - start + 1);
         order = min(order ? order - 1 : 0, max_order);
         /* The order allocated and populated must be aligned to the address. */
-        order = min(order, start ? find_first_set_bit(start) : MAX_ORDER);
+        order = min(order, start ? ffsl(start) - 1 : MAX_ORDER);
         page = alloc_domheap_pages(d, order, dom0_memflags | MEMF_no_scrub);
         if ( page == NULL )
         {
diff --git a/xen/arch/x86/hvm/hpet.c b/xen/arch/x86/hvm/hpet.c
index 1db9c0b60ee0..30ec14b24110 100644
--- a/xen/arch/x86/hvm/hpet.c
+++ b/xen/arch/x86/hvm/hpet.c
@@ -336,7 +336,7 @@ static void timer_sanitize_int_route(HPETState *h, unsigned int tn)
      * enabled pick the first irq.
      */
     timer_config(h, tn) |=
-        MASK_INSR(find_first_set_bit(timer_int_route_cap(h, tn)),
+        MASK_INSR(ffsl(timer_int_route_cap(h, tn)) - 1,
                   HPET_TN_ROUTE);
 }
 
@@ -410,7 +410,7 @@ static int cf_check hpet_write(
         {
             bool active;
 
-            i = find_first_set_bit(new_val);
+            i = ffsl(new_val) - 1;
             if ( i >= HPET_TIMER_NUM )
                 break;
             __clear_bit(i, &new_val);
@@ -536,14 +536,14 @@ static int cf_check hpet_write(
     /* stop/start timers whos state was changed by this write. */
     while (stop_timers)
     {
-        i = find_first_set_bit(stop_timers);
+        i = ffsl(stop_timers) - 1;
         __clear_bit(i, &stop_timers);
         hpet_stop_timer(h, i, guest_time);
     }
 
     while (start_timers)
     {
-        i = find_first_set_bit(start_timers);
+        i = ffsl(start_timers) - 1;
         __clear_bit(i, &start_timers);
         hpet_set_timer(h, i, guest_time);
     }
diff --git a/xen/arch/x86/include/asm/pt-contig-markers.h b/xen/arch/x86/include/asm/pt-contig-markers.h
index b3c1fe803534..e8c8157d605f 100644
--- a/xen/arch/x86/include/asm/pt-contig-markers.h
+++ b/xen/arch/x86/include/asm/pt-contig-markers.h
@@ -60,7 +60,7 @@ static bool pt_update_contig_markers(uint64_t *pt, unsigned int idx,
     /* Step 1: Reduce markers in lower numbered entries. */
     while ( i )
     {
-        b = find_first_set_bit(i);
+        b = ffsl(i) - 1;
         i &= ~(1U << b);
         if ( GET_MARKER(pt[i]) <= b )
             break;
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 62f5b811bbe8..28e9a159b577 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -3418,7 +3418,7 @@ static int vcpumask_to_pcpumask(
         {
             unsigned int cpu;
 
-            vcpu_id = find_first_set_bit(vmask);
+            vcpu_id = ffsl(vmask) - 1;
             vmask &= ~(1UL << vcpu_id);
             vcpu_id += vcpu_bias;
             if ( (vcpu_id >= d->max_vcpus) )
diff --git a/xen/arch/x86/mm/p2m-pod.c b/xen/arch/x86/mm/p2m-pod.c
index 65d31e552305..e0ad934d2e30 100644
--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -684,7 +684,7 @@ unsigned long
 p2m_pod_decrease_reservation(struct domain *d, gfn_t gfn, unsigned int order)
 {
     unsigned long left = 1UL << order, ret = 0;
-    unsigned int chunk_order = find_first_set_bit(gfn_x(gfn) | left);
+    unsigned int chunk_order = ffsl(gfn_x(gfn) | left) - 1;
 
     do {
         ret += decrease_reservation(d, gfn, chunk_order);
@@ -1384,7 +1384,7 @@ guest_physmap_mark_populate_on_demand(struct domain *d, unsigned long gfn,
                                       unsigned int order)
 {
     unsigned long left = 1UL << order;
-    unsigned int chunk_order = find_first_set_bit(gfn | left);
+    unsigned int chunk_order = ffsl(gfn | left) - 1;
     int rc;
 
     if ( !paging_mode_translate(d) )
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 2ec17df9b420..812eac51ea0d 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -1817,7 +1817,7 @@ static void _init_heap_pages(const struct page_info *pg,
     if ( unlikely(!avail[nid]) )
     {
         bool use_tail = IS_ALIGNED(s, 1UL << MAX_ORDER) &&
-                        (find_first_set_bit(e) <= find_first_set_bit(s));
+                        (ffsl(e) <= ffsl(s));
         unsigned long n;
 
         n = init_node_heap(nid, s, nr_pages, &use_tail);
diff --git a/xen/common/softirq.c b/xen/common/softirq.c
index 321d26902d37..bee4a82009c3 100644
--- a/xen/common/softirq.c
+++ b/xen/common/softirq.c
@@ -48,7 +48,7 @@ static void __do_softirq(unsigned long ignore_mask)
              || cpu_is_offline(cpu) )
             break;
 
-        i = find_first_set_bit(pending);
+        i = ffsl(pending) - 1;
         clear_bit(i, &softirq_pending(cpu));
         (*softirq_handlers[i])();
     }
diff --git a/xen/drivers/passthrough/amd/iommu_map.c b/xen/drivers/passthrough/amd/iommu_map.c
index e0f4fe736a8d..f1061bfc798c 100644
--- a/xen/drivers/passthrough/amd/iommu_map.c
+++ b/xen/drivers/passthrough/amd/iommu_map.c
@@ -137,7 +137,7 @@ static void set_iommu_ptes_present(unsigned long pt_mfn,
         ASSERT(!pde->u);
 
         if ( pde > table )
-            ASSERT(pde->ign0 == find_first_set_bit(pde - table));
+            ASSERT(pde->ign0 == ffsl(pde - table) - 1);
         else
             ASSERT(pde->ign0 == CONTIG_LEVEL_SHIFT);
 
diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index 996c31be1284..67dd8e5cd9e1 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -301,7 +301,7 @@ static unsigned int mapping_order(const struct domain_iommu *hd,
 {
     unsigned long res = dfn_x(dfn) | mfn_x(mfn);
     unsigned long sizes = hd->platform_ops->page_sizes;
-    unsigned int bit = find_first_set_bit(sizes), order = 0;
+    unsigned int bit = ffsl(sizes) - 1, order = 0;
 
     ASSERT(bit == PAGE_SHIFT);
 
@@ -309,7 +309,7 @@ static unsigned int mapping_order(const struct domain_iommu *hd,
     {
         unsigned long mask;
 
-        bit = find_first_set_bit(sizes);
+        bit = ffsl(sizes) - 1;
         mask = (1UL << bit) - 1;
         if ( nr <= mask || (res & mask) )
             break;
diff --git a/xen/drivers/passthrough/x86/iommu.c b/xen/drivers/passthrough/x86/iommu.c
index a3fa0aef7c37..d721ea27a033 100644
--- a/xen/drivers/passthrough/x86/iommu.c
+++ b/xen/drivers/passthrough/x86/iommu.c
@@ -641,7 +641,7 @@ struct page_info *iommu_alloc_pgtable(struct domain_iommu *hd,
     if ( contig_mask )
     {
         /* See pt-contig-markers.h for a description of the marker scheme. */
-        unsigned int i, shift = find_first_set_bit(contig_mask);
+        unsigned int i, shift = ffsl(contig_mask) - 1;
 
         ASSERT((CONTIG_LEVEL_SHIFT & (contig_mask >> shift)) == CONTIG_LEVEL_SHIFT);
 
@@ -652,7 +652,7 @@ struct page_info *iommu_alloc_pgtable(struct domain_iommu *hd,
 
         for ( i = 4; i < PAGE_SIZE / sizeof(*p); i += 4 )
         {
-            p[i + 0] = (find_first_set_bit(i) + 0ULL) << shift;
+            p[i + 0] = (ffsl(i) - 1ULL) << shift;
             p[i + 1] = 0;
             p[i + 2] = 1ULL << shift;
             p[i + 3] = 0;
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Wed Mar 13 17:27:33 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 17:27:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692675.1080062 (Exim 4.92)
	(envelope-from )
	id 1rkSO5-0003NP-1g; Wed, 13 Mar 2024 17:27:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692675.1080062; Wed, 13 Mar 2024 17:27:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkSO4-0003MV-Rh; Wed, 13 Mar 2024 17:27:32 +0000
Received: by outflank-mailman (input) for mailman id 692675;
 Wed, 13 Mar 2024 17:27:30 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkSO2-00023P-Se
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 17:27:30 +0000
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com
 [2a00:1450:4864:20::12a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f8401d88-e15e-11ee-afdd-a90da7624cb6;
 Wed, 13 Mar 2024 18:27:30 +0100 (CET)
Received: by mail-lf1-x12a.google.com with SMTP id
 2adb3069b0e04-513cc23b93aso134352e87.2
 for ; Wed, 13 Mar 2024 10:27:30 -0700 (PDT)
Received: from andrewcoop.citrite.net (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 f15-20020a170906048f00b00a42ee62b634sm5005732eja.106.2024.03.13.10.27.28
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 13 Mar 2024 10:27:28 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f8401d88-e15e-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710350849; x=1710955649; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=33TXDSAxPDO8bnXw5DlUbCOINftbDhFb4uNtskElrXY=;
        b=GQDGzq70NgXh8q66UCQMVnMT511HyPobC7cKbWr7LRG7LUyTtuOIGe4JUrdclFzeCr
         HjS2wRh9DvXQZKzgNCfbAmtx1X1tfMwyFn7DKcEmkXCKjMJYfIxMFY3LMdhxSl/1tCfM
         qkyTiQgr447cwrJDYlCt8nj0aktwFfmcUGZTc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710350849; x=1710955649;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=33TXDSAxPDO8bnXw5DlUbCOINftbDhFb4uNtskElrXY=;
        b=v0jz6G5XE+Fgj3mJKismko8oY4a+v7uTCtKGd7o8+bGtbS2omd09yawy/TIZwU6Zhg
         SrHXl65PgUS8B9pzMiXsnVLaO0SFCDdV1BjNnaBJv6/pfMSbGvA5Xp6AiRqVPLyq2rmU
         QNDlkXm+MKGa7Cag0g9OnQ/sxJYxDWm+T8JVBrjiRPJZrYdfgMLhb7LBEhKfyRdoykyE
         SQAo81vOfnLFKauNNjHbMq/4bEXTns3P6Mkl1BqF5Z5eKza7oXXBOVTLLfAOtU3wGkv6
         fJrmapDvP7/OJ7IlhdRw8vRL4c8VSMy9+z9c6e2ztSyli0FImnj81h7wpBoVXR4IG1NU
         +HIw==
X-Gm-Message-State: AOJu0YwmQrUQ25pxf008pYpjHwGnLYPdiy2UEDxofqwJ1coMxTHyWs+G
	xxywgzzPP74WKUjr/a0hn1CKO7cVX/UuMJqAMHu2T3VQVrm6XXuVfqic3F+NCwuIhgP3oAOlSi4
	i
X-Google-Smtp-Source: AGHT+IH+wJrXbeahOJLqrDjcYaBZ9zU2I/cXRNPjMfx4C/xQoBg042rLDW5ZSKpV7udLszZCL7H5+w==
X-Received: by 2002:a05:6512:239f:b0:513:b8c7:7ecc with SMTP id c31-20020a056512239f00b00513b8c77eccmr3385947lfv.60.1710350849218;
        Wed, 13 Mar 2024 10:27:29 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Wei Liu ,
	Stefano Stabellini ,
	Julien Grall ,
	Volodymyr Babchuk ,
	Bertrand Marquis ,
	Michal Orzel ,
	Oleksii Kurochko ,
	Shawn Anastasio ,
	"consulting @ bugseng . com" ,
	Simone Ballarin ,
	Federico Serafini ,
	Nicola Vetrini 
Subject: [PATCH 7/7] xen/bitops: Delete find_first_set_bit()
Date: Wed, 13 Mar 2024 17:27:16 +0000
Message-Id: <20240313172716.2325427-8-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20240313172716.2325427-1-andrew.cooper3@citrix.com>
References: <20240313172716.2325427-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

No more users.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
CC: Wei Liu 
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Volodymyr Babchuk 
CC: Bertrand Marquis 
CC: Michal Orzel 
CC: Oleksii Kurochko 
CC: Shawn Anastasio 
CC: consulting@bugseng.com 
CC: Simone Ballarin 
CC: Federico Serafini 
CC: Nicola Vetrini 
---
 xen/arch/arm/include/asm/bitops.h | 12 ------------
 xen/arch/ppc/include/asm/bitops.h |  9 ---------
 xen/arch/x86/include/asm/bitops.h | 12 ------------
 3 files changed, 33 deletions(-)

diff --git a/xen/arch/arm/include/asm/bitops.h b/xen/arch/arm/include/asm/bitops.h
index 59ae8ed150b6..5104334e4874 100644
--- a/xen/arch/arm/include/asm/bitops.h
+++ b/xen/arch/arm/include/asm/bitops.h
@@ -160,18 +160,6 @@ static inline int fls(unsigned int x)
 #define arch_ffs(x) ({ unsigned int __t = (x); fls(ISOLATE_LSB(__t)); })
 #define arch_ffsl(x) ({ unsigned long __t = (x); flsl(ISOLATE_LSB(__t)); })
 
-/**
- * find_first_set_bit - find the first set bit in @word
- * @word: the word to search
- *
- * Returns the bit-number of the first set bit (first bit being 0).
- * The input must *not* be zero.
- */
-static inline unsigned int find_first_set_bit(unsigned long word)
-{
-        return ffsl(word) - 1;
-}
-
 /**
  * hweightN - returns the hamming weight of a N-bit word
  * @x: the word to weigh
diff --git a/xen/arch/ppc/include/asm/bitops.h b/xen/arch/ppc/include/asm/bitops.h
index ecec2a826660..989d341a44c7 100644
--- a/xen/arch/ppc/include/asm/bitops.h
+++ b/xen/arch/ppc/include/asm/bitops.h
@@ -206,13 +206,4 @@ static always_inline unsigned long __ffs(unsigned long word)
     return __builtin_ctzl(word);
 }
 
-/**
- * find_first_set_bit - find the first set bit in @word
- * @word: the word to search
- *
- * Returns the bit-number of the first set bit (first bit being 0).
- * The input must *not* be zero.
- */
-#define find_first_set_bit(x) (ffsl(x) - 1)
-
 #endif /* _ASM_PPC_BITOPS_H */
diff --git a/xen/arch/x86/include/asm/bitops.h b/xen/arch/x86/include/asm/bitops.h
index 99342877e32f..2835bb6814d5 100644
--- a/xen/arch/x86/include/asm/bitops.h
+++ b/xen/arch/x86/include/asm/bitops.h
@@ -401,18 +401,6 @@ static always_inline unsigned int __scanbit(unsigned long val, unsigned int max)
     r__;                                                                    \
 })
 
-/**
- * find_first_set_bit - find the first set bit in @word
- * @word: the word to search
- * 
- * Returns the bit-number of the first set bit. The input must *not* be zero.
- */
-static inline unsigned int find_first_set_bit(unsigned long word)
-{
-    asm ( "rep; bsf %1,%0" : "=r" (word) : "rm" (word) );
-    return (unsigned int)word;
-}
-
 static inline unsigned int arch_ffs(unsigned int x)
 {
     int r = -1;
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Wed Mar 13 17:46:29 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 17:46:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692711.1080078 (Exim 4.92)
	(envelope-from )
	id 1rkSgF-00024A-Nu; Wed, 13 Mar 2024 17:46:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692711.1080078; Wed, 13 Mar 2024 17:46:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkSgF-000243-Kw; Wed, 13 Mar 2024 17:46:19 +0000
Received: by outflank-mailman (input) for mailman id 692711;
 Wed, 13 Mar 2024 17:46:18 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkSgD-00023x-Ub
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 17:46:18 +0000
Received: from mail.zytor.com (unknown [2607:7c80:54:3::138])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 95649226-e161-11ee-a1ee-f123f15fe8a2;
 Wed, 13 Mar 2024 18:46:15 +0100 (CET)
Received: from [192.168.7.187] ([71.202.166.45]) (authenticated bits=0)
 by mail.zytor.com (8.17.2/8.17.1) with ESMTPSA id 42DHjT8d2268621
 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO);
 Wed, 13 Mar 2024 10:45:30 -0700
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 95649226-e161-11ee-a1ee-f123f15fe8a2
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 42DHjT8d2268621
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com;
	s=2024021201; t=1710351931;
	bh=rzerA9hoGeFJCAIOx2/2/GsCWjUYIzB/Laek7drkNa4=;
	h=Date:Subject:To:Cc:References:From:In-Reply-To:From;
	b=ogrRRkDg6g2i+51nEZwh9h/klWPjU6VT0YpdSjqNtKHbej6934YuPe2MOtK0YAjPU
	 g6B9xVG7HpfPwMAV+y+SjUi9T7PXbALMMdZjs+bGDqoFcO0y2UfuRhUHxQOh/rYIZF
	 eiR+V1PLMEBe+4hUpPfWv4WwY+zQ7S85vBIdkJHYorGddUTm3gHFdlE4shNhOVBpVE
	 uzR3u7AHEufSQ0GfzQS2KAZ9NvJ0zn/tDRAFZ31CmSusC/V1CCRo4wKxP/KNUg6VFE
	 HLjdjzcrE4FZWZc7zUlp6Kb+ANl9GE7HB1Kd2u8Wsm/F9LXBPUNM2+LpNLUEGskYXW
	 ocDaMHmI9oDfg==
Message-ID: 
Date: Wed, 13 Mar 2024 10:45:26 -0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 1/1] x86: Rename __{start,end}_init_task to
 __{start,end}_init_stack
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= ,
        linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
        linux-arch@vger.kernel.org
Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de,
        dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com,
        boris.ostrovsky@oracle.com, arnd@arndb.de
References: <20240313060546.1952893-1-xin@zytor.com>
 
Content-Language: en-US
From: Xin Li 
Autocrypt: addr=xin@zytor.com; keydata=
 xsDNBGUPz1cBDACS/9yOJGojBFPxFt0OfTWuMl0uSgpwk37uRrFPTTLw4BaxhlFL0bjs6q+0
 2OfG34R+a0ZCuj5c9vggUMoOLdDyA7yPVAJU0OX6lqpg6z/kyQg3t4jvajG6aCgwSDx5Kzg5
 Rj3AXl8k2wb0jdqRB4RvaOPFiHNGgXCs5Pkux/qr0laeFIpzMKMootGa4kfURgPhRzUaM1vy
 bsMsL8vpJtGUmitrSqe5dVNBH00whLtPFM7IbzKURPUOkRRiusFAsw0a1ztCgoFczq6VfAVu
 raTye0L/VXwZd+aGi401V2tLsAHxxckRi9p3mc0jExPc60joK+aZPy6amwSCy5kAJ/AboYtY
 VmKIGKx1yx8POy6m+1lZ8C0q9b8eJ8kWPAR78PgT37FQWKYS1uAroG2wLdK7FiIEpPhCD+zH
 wlslo2ETbdKjrLIPNehQCOWrT32k8vFNEMLP5G/mmjfNj5sEf3IOKgMTMVl9AFjsINLHcxEQ
 6T8nGbX/n3msP6A36FDfdSEAEQEAAc0WWGluIExpIDx4aW5Aenl0b3IuY29tPsLBDQQTAQgA
 NxYhBIUq/WFSDTiOvUIqv2u9DlcdrjdRBQJlD89XBQkFo5qAAhsDBAsJCAcFFQgJCgsFFgID
 AQAACgkQa70OVx2uN1HUpgv/cM2fsFCQodLArMTX5nt9yqAWgA5t1srri6EgS8W3F+3Kitge
 tYTBKu6j5BXuXaX3vyfCm+zajDJN77JHuYnpcKKr13VcZi1Swv6Jx1u0II8DOmoDYLb1Q2ZW
 v83W55fOWJ2g72x/UjVJBQ0sVjAngazU3ckc0TeNQlkcpSVGa/qBIHLfZraWtdrNAQT4A1fa
 sWGuJrChBFhtKbYXbUCu9AoYmmbQnsx2EWoJy3h7OjtfFapJbPZql+no5AJ3Mk9eE5oWyLH+
 QWqtOeJM7kKvn/dBudokFSNhDUw06e7EoVPSJyUIMbYtUO7g2+Atu44G/EPP0yV0J4lRO6EA
 wYRXff7+I1jIWEHpj5EFVYO6SmBg7zF2illHEW31JAPtdDLDHYcZDfS41caEKOQIPsdzQkaQ
 oW2hchcjcMPAfyhhRzUpVHLPxLCetP8vrVhTvnaZUo0xaVYb3+wjP+D5j/3+hwblu2agPsaE
 vgVbZ8Fx3TUxUPCAdr/p73DGg57oHjgezsDNBGUPz1gBDAD4Mg7hMFRQqlzotcNSxatlAQNL
 MadLfUTFz8wUUa21LPLrHBkUwm8RujehJrzcVbPYwPXIO0uyL/F///CogMNx7Iwo6by43KOy
 g89wVFhyy237EY76j1lVfLzcMYmjBoTH95fJC/lVb5Whxil6KjSN/R/y3jfG1dPXfwAuZ/4N
 cMoOslWkfZKJeEut5aZTRepKKF54T5r49H9F7OFLyxrC/uI9UDttWqMxcWyCkHh0v1Di8176
 jjYRNTrGEfYfGxSp+3jYL3PoNceIMkqM9haXjjGl0W1B4BidK1LVYBNov0rTEzyr0a1riUrp
 Qk+6z/LHxCM9lFFXnqH7KWeToTOPQebD2B/Ah5CZlft41i8L6LOF/LCuDBuYlu/fI2nuCc8d
 m4wwtkou1Y/kIwbEsE/6RQwRXUZhzO6llfoN96Fczr/RwvPIK5SVMixqWq4QGFAyK0m/1ap4
 bhIRrdCLVQcgU4glo17vqfEaRcTW5SgX+pGs4KIPPBE5J/ABD6pBnUUAEQEAAcLA/AQYAQgA
 JhYhBIUq/WFSDTiOvUIqv2u9DlcdrjdRBQJlD89ZBQkFo5qAAhsMAAoJEGu9DlcdrjdR4C0L
 /RcjolEjoZW8VsyxWtXazQPnaRvzZ4vhmGOsCPr2BPtMlSwDzTlri8BBG1/3t/DNK4JLuwEj
 OAIE3fkkm+UG4Kjud6aNeraDI52DRVCSx6xff3bjmJsJJMb12mWglN6LjdF6K+PE+OTJUh2F
 dOhslN5C2kgl0dvUuevwMgQF3IljLmi/6APKYJHjkJpu1E6luZec/lRbetHuNFtbh3xgFIJx
 2RpgVDP4xB3f8r0I+y6ua+p7fgOjDLyoFjubRGed0Be45JJQEn7A3CSb6Xu7NYobnxfkwAGZ
 Q81a2XtvNS7Aj6NWVoOQB5KbM4yosO5+Me1V1SkX2jlnn26JPEvbV3KRFcwV5RnDxm4OQTSk
 PYbAkjBbm+tuJ/Sm+5Yp5T/BnKz21FoCS8uvTiziHj2H7Cuekn6F8EYhegONm+RVg3vikOpn
 gao85i4HwQTK9/D1wgJIQkdwWXVMZ6q/OALaBp82vQ2U9sjTyFXgDjglgh00VRAHP7u1Rcu4
 l75w1xInsg==
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 3/13/2024 12:09 AM, Jürgen Groß wrote:
> On 13.03.24 07:05, Xin Li (Intel) wrote:
>> The stack of a task has been separated from the memory of a task_struct
>> struture for a long time on x86, as a result __{start,end}_init_task no
>> longer mark the start and end of the init_task structure, but its stack
>> only.
>>
>> Rename __{start,end}_init_task to __{start,end}_init_stack.
>>
>> Note other architectures are not affected because __{start,end}_init_task
>> are used on x86 only.
>>

>> diff --git a/include/asm-generic/vmlinux.lds.h 
>> b/include/asm-generic/vmlinux.lds.h
>> index 5dd3a61d673d..a168be99d522 100644
>> --- a/include/asm-generic/vmlinux.lds.h
>> +++ b/include/asm-generic/vmlinux.lds.h
>> @@ -399,13 +399,13 @@
>>   #define INIT_TASK_DATA(align)                        \
>>       . = ALIGN(align);                        \
>> -    __start_init_task = .;                        \
>> +    __start_init_stack = .;                        \
>>       init_thread_union = .;                        \
>>       init_stack = .;                            \
>> -    KEEP(*(.data..init_task))                    \
>> +    KEEP(*(.data..init_stack))                    \
> 
> Is this modification really correct?
> 

Good catch, I should not change it.

Thanks!
     Xin



From xen-devel-bounces@lists.xenproject.org Wed Mar 13 17:48:13 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 17:48:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692713.1080088 (Exim 4.92)
	(envelope-from )
	id 1rkSi4-0002bp-3a; Wed, 13 Mar 2024 17:48:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692713.1080088; Wed, 13 Mar 2024 17:48:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkSi3-0002bi-VP; Wed, 13 Mar 2024 17:48:11 +0000
Received: by outflank-mailman (input) for mailman id 692713;
 Wed, 13 Mar 2024 17:48:10 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkSi2-0002ar-FS
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 17:48:10 +0000
Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com
 [2607:f8b0:4864:20::82a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d9edf626-e161-11ee-a1ee-f123f15fe8a2;
 Wed, 13 Mar 2024 18:48:08 +0100 (CET)
Received: by mail-qt1-x82a.google.com with SMTP id
 d75a77b69052e-4308c87f6faso191051cf.3
 for ; Wed, 13 Mar 2024 10:48:08 -0700 (PDT)
Received: from [10.80.67.149] (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 s12-20020ac8758c000000b0043096801173sm457536qtq.88.2024.03.13.10.48.03
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 13 Mar 2024 10:48:05 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d9edf626-e161-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710352086; x=1710956886; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=iPMAMpD1gm9uztDgbh0tGfyJ0XhNKqmbjIwHhct2ubE=;
        b=F97Cd78ztuB544MYXoVvhBXfB/tJUBJ2t3ALnNpUrgScOjWZ7HtPCLX5+dwvBd95KG
         G73jH+JBqw2wScwaRGb4ZSoT7as8F/1q6D0VwlFcQE2jUf5mBxam95e1O90CLx0vTXko
         7qWHVY5LPgLit251p0bw1kUJjoswIfCpryY6c=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710352086; x=1710956886;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=iPMAMpD1gm9uztDgbh0tGfyJ0XhNKqmbjIwHhct2ubE=;
        b=RPFo6qRMZzu+lL8ABVmNs759GNT1cD01liXRn0aa5LSxuyZJFrJRLwum5RbkxWS6J+
         qkhjpSXI6t1U2NhtASMwok0mr1rNo9J6XzBk4Xg9ySh7gDVOHFs1IDIeqwmrwgoibElU
         mlJsO0R6CBitq8ReL8sZKHwf4x622Tu8+wCUI8RKBFbualAzf2kZuAgQvqehfoCuJyUZ
         e3lR3FlzPte7BoYvb0baPPW7riJeNnd1kWtFvxt2fy3MuqB1wMojUAYPL4+KIDFknudA
         VLpPaBaEUZN7sk85JlgDkd5wskSt14kmMIc62P/NDCregogYSgVKoGj013gV7goFslUx
         Kmww==
X-Gm-Message-State: AOJu0YwljVyivq7EQdWX0TnklMP4trDXjxP/dn0EGSzNMaYBUk5W2fLU
	PCfFEIhD/Q4KdaUedSnnd37pNqp0u9sUm0NENsmm5wuT4o8ixqs+e/K2Jl22mvm6we5sKT8azvF
	9
X-Google-Smtp-Source: AGHT+IEXvzE5SX2GElD+rvpMOU3suRmnfUi8FSgJp3A8DgSyn/3wHItRfBGZVO0OCKBl32PQtemoQA==
X-Received: by 2002:ac8:5f09:0:b0:42f:309e:5ce2 with SMTP id x9-20020ac85f09000000b0042f309e5ce2mr14754897qta.29.1710352086221;
        Wed, 13 Mar 2024 10:48:06 -0700 (PDT)
Message-ID: <04b7bed5-ef60-4d21-90f2-2eea05397fb3@citrix.com>
Date: Wed, 13 Mar 2024 17:48:02 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 3/7] xen/bitops: Implement ffsl() in common logic
Content-Language: en-GB
To: Xen-devel 
Cc: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Wei Liu ,
 Stefano Stabellini , Julien Grall ,
 Volodymyr Babchuk ,
 Bertrand Marquis ,
 Michal Orzel ,
 Oleksii Kurochko ,
 Shawn Anastasio ,
 "consulting @ bugseng . com" ,
 Simone Ballarin ,
 Federico Serafini ,
 Nicola Vetrini 
References: <20240313172716.2325427-1-andrew.cooper3@citrix.com>
 <20240313172716.2325427-4-andrew.cooper3@citrix.com>
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <20240313172716.2325427-4-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 13/03/2024 5:27 pm, Andrew Cooper wrote:
>  xen/arch/arm/include/asm/bitops.h |  2 +-
>  xen/arch/ppc/include/asm/bitops.h |  1 -
>  xen/arch/x86/include/asm/bitops.h | 30 +++++++++++++-----------------
>  xen/common/bitops.c               |  7 +++++++
>  xen/include/xen/bitops.h          | 12 ++++++++++++
>  5 files changed, 33 insertions(+), 19 deletions(-)
>
> diff --git a/xen/arch/arm/include/asm/bitops.h b/xen/arch/arm/include/asm/bitops.h
> index 09c6064274a7..59ae8ed150b6 100644
> --- a/xen/arch/arm/include/asm/bitops.h
> +++ b/xen/arch/arm/include/asm/bitops.h
> @@ -158,7 +158,7 @@ static inline int fls(unsigned int x)
>  
>  
>  #define arch_ffs(x) ({ unsigned int __t = (x); fls(ISOLATE_LSB(__t)); })
> -#define ffsl(x) ({ unsigned long __t = (x); flsl(ISOLATE_LSB(__t)); })
> +#define arch_ffsl(x) ({ unsigned long __t = (x); flsl(ISOLATE_LSB(__t)); })
>  
>  /**
>   * find_first_set_bit - find the first set bit in @word

It turns out this change isn't bisectable on ARM, but it is by the end
of the series.

Reordering patches 6+7 to be ahead of this one resolves the bisection
problem.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Mar 13 18:17:24 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 18:17:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692718.1080098 (Exim 4.92)
	(envelope-from )
	id 1rkTA5-0000hU-9F; Wed, 13 Mar 2024 18:17:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692718.1080098; Wed, 13 Mar 2024 18:17:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkTA5-0000hN-5A; Wed, 13 Mar 2024 18:17:09 +0000
Received: by outflank-mailman (input) for mailman id 692718;
 Wed, 13 Mar 2024 18:17:07 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkTA3-0000hF-M7
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 18:17:07 +0000
Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com
 [2607:f8b0:4864:20::731])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e553b527-e165-11ee-a1ee-f123f15fe8a2;
 Wed, 13 Mar 2024 19:17:05 +0100 (CET)
Received: by mail-qk1-x731.google.com with SMTP id
 af79cd13be357-78822adc835so5512185a.3
 for ; Wed, 13 Mar 2024 11:17:05 -0700 (PDT)
Received: from [10.80.67.149] (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 b23-20020a05620a127700b007885cd1c058sm4949553qkl.103.2024.03.13.11.17.00
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 13 Mar 2024 11:17:02 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e553b527-e165-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710353823; x=1710958623; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=BNmCiAOWb71HcisPNuwclr9VmMOrpEOdYu4AXP25DtE=;
        b=lM2qf51f1kWaFn/Z5mM9LLTR2oxh/BeN8fs8rDaUeQvERWQ2RNbUTrN/P4TVXGo31q
         Ljk7g8OvjfBO9jnZZoq+B/2OYXoM4REfdLdZoVgf5/NpeAIrh1W2H5MvQw3gWhqSARyc
         HwCUKVj+Mt5UwzMghpsA9jt09Tu0cJvWATHeA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710353823; x=1710958623;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=BNmCiAOWb71HcisPNuwclr9VmMOrpEOdYu4AXP25DtE=;
        b=chn9ITootKnVH/znx2YDkupxYH1YIGzYecelljhCWFVHvLRHHueTHkSo3qDLEvz0vN
         a93ULJr7BwiiAW+UU6P7xTProNoa4AqRoCsJ25W24QuA0Sj4D6RkrplfHzJnPDWckfNe
         C6e0zfvnnxa6wlq37EUJdolUGTuDZ0wgtMTUcBICf94hzNgBGpHiy04SeMJkwgRYN0y+
         WOFu6nXWoX/RKhcrN0OqCme+N9xJQpQR7LOV+wXH+mftu+p+eVHiyxRoEgZOmRFvTFza
         5BmG6lAqkEYpxOWpw/rS6nE98LHbEARUY6ZZAM1VMJx1gu26f1xGoq1kJr7HdlGYlyp5
         THrQ==
X-Gm-Message-State: AOJu0YzOVHhvzKThI0mJ/RIsVLHjWrdpBm5TXy+vb/9JKEaPF1d9Tbhy
	6cpal2X1l/Tw0VDnwg1Z4dZ/HZyil8AcrFQjrNA8m4c//b7rsjEhdCahLFpLEHfyo+szrnC4a2D
	T
X-Google-Smtp-Source: AGHT+IEl1fFA9remQKXuEYS0Iwe1nWaLn/L/sSnsWeg9AweiS6Nhhe2q1TONGVnwvJMJRcvFJ8G9Ww==
X-Received: by 2002:a05:620a:201c:b0:788:1f98:14b8 with SMTP id c28-20020a05620a201c00b007881f9814b8mr632888qka.39.1710353823724;
        Wed, 13 Mar 2024 11:17:03 -0700 (PDT)
Message-ID: <29db9ea8-0312-4261-92a2-55f868572a4d@citrix.com>
Date: Wed, 13 Mar 2024 18:16:59 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 3/7] xen/bitops: Implement ffsl() in common logic
Content-Language: en-GB
To: Xen-devel 
Cc: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Wei Liu ,
 Stefano Stabellini , Julien Grall ,
 Volodymyr Babchuk ,
 Bertrand Marquis ,
 Michal Orzel ,
 Oleksii Kurochko ,
 Shawn Anastasio ,
 "consulting @ bugseng . com" ,
 Simone Ballarin ,
 Federico Serafini ,
 Nicola Vetrini 
References: <20240313172716.2325427-1-andrew.cooper3@citrix.com>
 <20240313172716.2325427-4-andrew.cooper3@citrix.com>
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <20240313172716.2325427-4-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 13/03/2024 5:27 pm, Andrew Cooper wrote:
> diff --git a/xen/common/bitops.c b/xen/common/bitops.c
> index 484df68768ad..eceffe5029d6 100644
> --- a/xen/common/bitops.c
> +++ b/xen/common/bitops.c
> @@ -40,6 +40,13 @@ static void test_ffs(void)
>      CHECK(ffs, 0, 0);
>      CHECK(ffs, 1, 1);
>      CHECK(ffs, 0x80000000U, 32);
> +
> +    /* unsigned int ffsl(unsigned long) */
> +    CHECK(ffsl, 0, 0);
> +    CHECK(ffsl, 1, 1);
> +    CHECK(ffsl, 1UL << (BITS_PER_LONG - 1), BITS_PER_LONG);
> +    if ( BITS_PER_LONG > 32 )
> +        CHECK(ffsl, 1UL << 32, 33);
>  }

This if() needs to be an #if to compile on arm32.

Otherwise, I've managed to make the series fully bisectable on all
architectures.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Mar 13 18:40:12 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 18:40:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692724.1080107 (Exim 4.92)
	(envelope-from )
	id 1rkTWI-0005el-5U; Wed, 13 Mar 2024 18:40:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692724.1080107; Wed, 13 Mar 2024 18:40:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkTWI-0005ee-2P; Wed, 13 Mar 2024 18:40:06 +0000
Received: by outflank-mailman (input) for mailman id 692724;
 Wed, 13 Mar 2024 18:40:04 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkTWG-0005HF-Ik
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 18:40:04 +0000
Received: from raptorengineering.com (mail.raptorengineering.com
 [23.155.224.40]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 192ac599-e169-11ee-afdd-a90da7624cb6;
 Wed, 13 Mar 2024 19:40:02 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
 by mail.rptsys.com (Postfix) with ESMTP id DD7368285572;
 Wed, 13 Mar 2024 13:39:59 -0500 (CDT)
Received: from mail.rptsys.com ([127.0.0.1])
 by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10032)
 with ESMTP id 7zmn-BWPuRC4; Wed, 13 Mar 2024 13:39:59 -0500 (CDT)
Received: from localhost (localhost [127.0.0.1])
 by mail.rptsys.com (Postfix) with ESMTP id 498D982855AB;
 Wed, 13 Mar 2024 13:39:59 -0500 (CDT)
Received: from mail.rptsys.com ([127.0.0.1])
 by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10026)
 with ESMTP id X2Yxv9AQY8aF; Wed, 13 Mar 2024 13:39:59 -0500 (CDT)
Received: from [10.11.0.3] (5.edge.rptsys.com [23.155.224.38])
 by mail.rptsys.com (Postfix) with ESMTPSA id 954578285572;
 Wed, 13 Mar 2024 13:39:58 -0500 (CDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 192ac599-e169-11ee-afdd-a90da7624cb6
DKIM-Filter: OpenDKIM Filter v2.10.3 mail.rptsys.com 498D982855AB
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=raptorengineering.com; s=B8E824E6-0BE2-11E6-931D-288C65937AAD;
	t=1710355199; bh=vw3MDCIIKHd5BbVDxKjOW+av2xjw5+az38KnDYXRv/Q=;
	h=Message-ID:Date:MIME-Version:To:From;
	b=mCfkWrMtFKJscjITJz12OSowB5MuRQIYg/Lz2tKz/WouqStoHCtNXl4Zoq3LqQ2VT
	 YNAJ043wyOnCpxeDBXbFpRnONc09G3ahPsjTmQqwz8AQ33lwALnCzH6CLBrSfw8pe5
	 6HwwlptPRu3LaL8WcRBObJqHhcgwH48MJzUbFKpI=
X-Virus-Scanned: amavisd-new at rptsys.com
Message-ID: <642f7eb8-3a44-4462-a199-4ee4bd24887e@raptorengineering.com>
Date: Wed, 13 Mar 2024 13:39:57 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/7] xen/bitops: Cleanup ahead of rearrangements
To: Andrew Cooper ,
 Xen-devel 
Cc: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Wei Liu ,
 Stefano Stabellini , Julien Grall ,
 Volodymyr Babchuk ,
 Bertrand Marquis ,
 Michal Orzel ,
 Oleksii Kurochko ,
 "consulting @ bugseng . com" ,
 Simone Ballarin ,
 Federico Serafini ,
 Nicola Vetrini 
References: <20240313172716.2325427-1-andrew.cooper3@citrix.com>
 <20240313172716.2325427-2-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Shawn Anastasio 
In-Reply-To: <20240313172716.2325427-2-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Hi Andrew,

On 3/13/24 12:27 PM, Andrew Cooper wrote:
> diff --git a/xen/common/bitops.c b/xen/common/bitops.c
> new file mode 100644
> index 000000000000..4c07191b4030
> --- /dev/null
> +++ b/xen/common/bitops.c
> @@ -0,0 +1,41 @@
> +#include 
> +#include 
> +#include 
> +
> +/* Hide a value from the optimiser. */
> +#define HIDE(x) ({ typeof(x) _x = x; asm volatile ( "" : "+r" (_x) ); _x; })
> +
> +/*
> + * Check that fn(val) can be calcuated by the compiler, and that it gives the
> + * expected answer.
> + */
> +#define COMPILE_CHECK(fn, val, res)                                     \
> +    do {                                                                \
> +        if ( fn(val) != res )                                           \
> +            asm (".error \"Compile time check '" STR(fn(val) == res) "' failed\""); \
> +    } while ( 0 )
> +

For improved diagnostics, I think it might make sense to explicitly
check if the expression can be evaluated at compile time and emit a
different error if not. Perhaps something like the following:

#define COMPILE_CHECK(fn, val, res)                                     \
    do {                                                                \
        __typeof__(fn(val)) actual = fn(val);                           \
        if ( !__builtin_constant_p(actual) )                            \
            asm (".error \"Unable to evaluate '" STR(fn(val)) "' at
compile time\"\n"); \
        else if ( actual != res )                                       \
            asm (".error \"Compile time check '" STR(fn(val) == res) "'
failed\""); \
    } while ( 0 )



From xen-devel-bounces@lists.xenproject.org Wed Mar 13 18:41:38 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 18:41:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692726.1080118 (Exim 4.92)
	(envelope-from )
	id 1rkTXl-0006NN-Gc; Wed, 13 Mar 2024 18:41:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692726.1080118; Wed, 13 Mar 2024 18:41:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkTXl-0006NG-DC; Wed, 13 Mar 2024 18:41:37 +0000
Received: by outflank-mailman (input) for mailman id 692726;
 Wed, 13 Mar 2024 18:41:36 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1rkTXk-0006N8-2C
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 18:41:36 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkTXj-0004uH-Us; Wed, 13 Mar 2024 18:41:35 +0000
Received: from ec2-63-33-11-17.eu-west-1.compute.amazonaws.com ([63.33.11.17]
 helo=REM-PW02S00X.ant.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92)
 (envelope-from )
 id 1rkTXj-0002Ct-Hp; Wed, 13 Mar 2024 18:41:35 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:MIME-Version:
	Message-Id:Date:Subject:Cc:To:From;
	bh=N9fRCgST6Y0xZgmCssbdnEf4QwnDWFyNxFJ9at5808g=; b=eP/fvdhG/fEQXgzkEhzn5A6z+c
	h1qNDJopJyJnCtrjxh6SpgTK7XVpuY/byHAdVHB/EBgxpYGvtm0toBBeijEUBi3a3MNZ4opjb1bFP
	E24PiY4GU0WG/GFWxhPwTV1WMzZRZp3q8b/0GlN4jzdOyI9yXM3pu0RYX4NEEDEMmJnE=;
From: Paul Durrant 
To: xen-devel@lists.xenproject.org
Cc: Paul Durrant ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini ,
	Wei Liu 
Subject: [PATCH] MAINTAINERS: Remove myself from several subsystems
Date: Wed, 13 Mar 2024 18:41:25 +0000
Message-Id: <20240313184125.39185-1-paul@xen.org>
X-Mailer: git-send-email 2.39.2
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

From: Paul Durrant 

I am not as actively involved with the Xen project as I once was so I need
to relinquish some of my maintainer responsibilities: IOMMU and I/O
emulation.

NOTE: Since I am sole maintainer for I/O EMULATION (IOREQ) and
      X86 I/O EMULATION, these sections are removed.

Signed-off-by: Paul Durrant 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Jan Beulich 
Cc: Julien Grall 
Cc: Stefano Stabellini 
Cc: Wei Liu 
---
 MAINTAINERS | 20 --------------------
 1 file changed, 20 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 56a6932037fe..b2cc3cc3921b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -358,7 +358,6 @@ F:	xen/drivers/passthrough/vtd/
 
 IOMMU VENDOR INDEPENDENT CODE
 M:	Jan Beulich 
-M:	Paul Durrant 
 R:	Roger Pau Monné 
 S:	Supported
 F:	xen/drivers/passthrough/
@@ -368,13 +367,6 @@ X:	xen/drivers/passthrough/vtd/
 X:	xen/drivers/passthrough/device_tree.c
 F:	xen/include/xen/iommu.h
 
-I/O EMULATION (IOREQ)
-M:	Paul Durrant 
-S:	Supported
-F:	xen/common/ioreq.c
-F:	xen/include/xen/ioreq.h
-F:	xen/include/public/hvm/ioreq.h
-
 KCONFIG
 M:	Doug Goldstein 
 S:	Supported
@@ -608,18 +600,6 @@ F:	tools/misc/xen-cpuid.c
 F:	tools/tests/cpu-policy/
 F:	tools/tests/x86_emulator/
 
-X86 I/O EMULATION
-M:	Paul Durrant 
-S:	Supported
-F:	xen/arch/x86/hvm/emulate.c
-F:	xen/arch/x86/hvm/intercept.c
-F:	xen/arch/x86/hvm/io.c
-F:	xen/arch/x86/hvm/ioreq.c
-F:	xen/arch/x86/include/asm/hvm/emulate.h
-F:	xen/arch/x86/include/asm/hvm/io.h
-F:	xen/arch/x86/include/asm/hvm/ioreq.h
-F:	xen/arch/x86/include/asm/ioreq.h
-
 X86 MEMORY MANAGEMENT
 M:	Jan Beulich 
 M:	Andrew Cooper 
-- 
2.39.2



From xen-devel-bounces@lists.xenproject.org Wed Mar 13 18:41:38 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 18:41:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692727.1080128 (Exim 4.92)
	(envelope-from )
	id 1rkTXm-0006c4-Na; Wed, 13 Mar 2024 18:41:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692727.1080128; Wed, 13 Mar 2024 18:41:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkTXm-0006bx-KZ; Wed, 13 Mar 2024 18:41:38 +0000
Received: by outflank-mailman (input) for mailman id 692727;
 Wed, 13 Mar 2024 18:41:37 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkTXl-0006QV-LR; Wed, 13 Mar 2024 18:41:37 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkTXl-0004uW-J5; Wed, 13 Mar 2024 18:41:37 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkTXl-0000GE-2y; Wed, 13 Mar 2024 18:41:37 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rkTXl-0002gY-2Y; Wed, 13 Mar 2024 18:41:37 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=i8HIPpysSi7/NpFLZFws1d4B7iLqC/jiWEPC6EiMbio=; b=ADjv6qByxD9K4+NvDgQL2gOoYE
	VsoS0PTsUfVBh8SPP0VSNjCxxfSwYNP9mRf5l6NWAUzJIBljhqp8SmFup2d+DjTQ/wEI5+7MReP1f
	aytFyx0oTNg5g/8lSYdHiX907PETPgglgC+LjxVof86W9aJREnYaf03J1OaV3jKAWknE=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 185010: tolerable FAIL - PUSHED
X-Osstest-Failures:
    xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:windows-install:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-i386-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking
X-Osstest-Versions-This:
    xen=03cf7ca23e0e876075954c558485b267b7d02406
X-Osstest-Versions-That:
    xen=7c81558208de7858251b62f168a449be84305595
From: osstest service owner 
Date: Wed, 13 Mar 2024 18:41:37 +0000

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop            fail like 184998
 test-armhf-armhf-libvirt     16 saverestore-support-check    fail  like 184998
 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop             fail like 184998
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop            fail like 184998
 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop             fail like 184998
 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop             fail like 184998
 test-armhf-armhf-libvirt-raw 15 saverestore-support-check    fail  like 184998
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop            fail like 184998
 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check   fail like 184998
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop             fail like 184998
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184998
 test-amd64-amd64-xl-qemuu-win7-amd64 12 windows-install       fail like 184998
 test-amd64-amd64-libvirt     15 migrate-support-check        fail   never pass
 test-amd64-i386-xl-pvshim    14 guest-start                  fail   never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  15 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      16 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass
 test-armhf-armhf-xl-multivcpu 15 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-rtds     15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-rtds     16 saverestore-support-check    fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass
 test-armhf-armhf-xl-arndale  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     15 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-raw  14 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-raw 14 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-raw 15 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-vhd      14 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-vhd      15 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-vhd      14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      15 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-raw 14 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          16 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-qcow2 14 migrate-support-check        fail never pass

version targeted for testing:
 xen                  03cf7ca23e0e876075954c558485b267b7d02406
baseline version:
 xen                  7c81558208de7858251b62f168a449be84305595

Last test of basis   184998  2024-03-12 01:55:48 Z    1 days
Testing same since   185010  2024-03-12 21:09:04 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Roger Pau Monné 

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-i386-examine-bios                                 pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-armhf-armhf-libvirt-qcow2                               pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-libvirt-raw                                  pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-i386-examine-uefi                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-arm64-arm64-xl-vhd                                      pass    
 test-armhf-armhf-xl-vhd                                      pass    
 test-amd64-i386-xl-vhd                                       pass    


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

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

Explanation of these 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
   7c81558208..03cf7ca23e  03cf7ca23e0e876075954c558485b267b7d02406 -> master


From xen-devel-bounces@lists.xenproject.org Wed Mar 13 19:39:13 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 19:39:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692752.1080196 (Exim 4.92)
	(envelope-from )
	id 1rkURS-0007ZB-10; Wed, 13 Mar 2024 19:39:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692752.1080196; Wed, 13 Mar 2024 19:39:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkURR-0007Z4-Tw; Wed, 13 Mar 2024 19:39:09 +0000
Received: by outflank-mailman (input) for mailman id 692752;
 Wed, 13 Mar 2024 19:39:09 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkURR-0007Yd-8p
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 19:39:09 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on20601.outbound.protection.outlook.com
 [2a01:111:f403:2418::601])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5a299ba1-e171-11ee-a1ee-f123f15fe8a2;
 Wed, 13 Mar 2024 20:39:06 +0100 (CET)
Received: from BN9PR03CA0705.namprd03.prod.outlook.com (2603:10b6:408:ef::20)
 by PH7PR12MB9066.namprd12.prod.outlook.com (2603:10b6:510:1f6::5)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.36; Wed, 13 Mar
 2024 19:39:00 +0000
Received: from BN3PEPF0000B06C.namprd21.prod.outlook.com
 (2603:10b6:408:ef:cafe::cb) by BN9PR03CA0705.outlook.office365.com
 (2603:10b6:408:ef::20) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.36 via Frontend
 Transport; Wed, 13 Mar 2024 19:38:59 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN3PEPF0000B06C.mail.protection.outlook.com (10.167.243.71) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.0 via Frontend Transport; Wed, 13 Mar 2024 19:38:59 +0000
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Wed, 13 Mar
 2024 14:38:59 -0500
Received: from fedora.mshome.net (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Wed, 13 Mar 2024 14:38:58 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5a299ba1-e171-11ee-a1ee-f123f15fe8a2
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=J09avBg0T+9cyAlKVUrKClWdQvNf2o9zXTa6YdVt79rscNa7r2nOpADIBBIvKRiTexQUh6D2VJ/ptgaaSH++NFq2VYFO32VFNIadczwm3pKoCHK1Kml4NuENk9mzHvqvgTOoz0MYCRbeo8Jrjy+GvZCoBw/r2Wp0I0N1GAvzJ5Fp3nucw+pVD3mbgraZ1O+90C6f5yHrTQtNB4AZdgRCXX7/DOPVEaLkAcqYGh2JTdMQVQPeibjJWVLIQfzdeMfec3VrziNFxBiSBTcronIlRcFV6sHIyzjkHrX4qqjuH441MAaJsyBS5QxgL1/C3gUryK6EXVd2q19GyT04IvztSg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=lvOehq1EJKjZfWXBSzZg1ZZ1p5IUUk1AykmRfeyalZA=;
 b=T4q7oPTrmG9j3v6ldT7/69Ad0mrcEwHsLTuLzkhfv4f7z3/MOgLIcO3A6pKxatyogbSa0EkmL2qAJ7KqDnnxdyGDsUTbUHNQdOh7WZ3Q5Eg8MvdFkVI/yVhDnM65V5+M5efkhis2qCRDMllwah2WXJWn+wUxfGHMAIxiBbaWVE+j0BRC3lohazYMqj+ZG1to77VywyzzrYh6OVZq29WdqhZSF6r6Mob9b6MYMIrl9CShXdfH1AMjdLofG34z0f2Qo3B3HxvHNoAWFvGMoB780sTJ7zLUIUJCOOYWAZhkX/hX+32LrcvVDrYJ8NcVWMw4Oe85PIP1u6NXTsu9mmTNjg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=lvOehq1EJKjZfWXBSzZg1ZZ1p5IUUk1AykmRfeyalZA=;
 b=uRgM+SmzYGpGdYzzorttE/tzliN76mT2C+FJgL9jAAxM2ZalKQWfmPxLPZXweTm+5rc+nLPNUpo1LJUlq1fkwlG7GBg6mdU93XgAwuWOfFDDFssHyHJBcDi9m5Rj/zJj2brp1ZoqMoZTuCpjeYmyCgS/lVCmQnkbK+dpzgu+oz8=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Jason Andryuk 
To: 
CC: Jason Andryuk , Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Wei Liu
	
Subject: [PATCH v2 1/3] Revert "xen/x86: bzImage parse kernel_alignment"
Date: Wed, 13 Mar 2024 15:30:19 -0400
Message-ID: <20240313193021.241764-2-jason.andryuk@amd.com>
X-Mailer: git-send-email 2.44.0
In-Reply-To: <20240313193021.241764-1-jason.andryuk@amd.com>
References: <20240313193021.241764-1-jason.andryuk@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB04.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN3PEPF0000B06C:EE_|PH7PR12MB9066:EE_
X-MS-Office365-Filtering-Correlation-Id: 3a7b6868-0736-4eaf-9305-08dc43953aba
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	YqqWOBL36/cuyS43g264cfWuN2eTLVPbKPm8aU8SJZ8Ssb1wf3iuOVzLr6/ZmTLxFdGEJqNYYQHR/2qn4nK6GymcGRj6Dz6d0FBnJaW33lefGSP51kC8JChPjx0a6YTtGYMjSI0g7i1cOG4HMThn3Ud3BBI1bNQkPgf1Z3nuSgesSX6cKvYHg9zcGEVkjQ4mcRDJ2MecPdrHt54r/9i4hdZU4n3cGt+kLC7LxcrFZvhdjZk/sW5/eCWNzO6MrJMtVIq4q23TQZ22lM+NIiQMFfO/fQNPF3CnFy8oRJk7BcaWLiVJ3x7jwTr/XWIMi186Dq7ZXFmsnavL8D9p3897lgM7Kw7e1zzz7tMnie6QMvqK1OFlrd2bWfXFIN9VkhU8ARwNY28LtlDWj271b5xH4ItKhggvF+b3zWbBvOLaP2QsVovOBc6JFRJU3SRCcFpcqZz4tT/U8sISYhnqLinkU2NKR2NI30En79w0WW/75jFkqrH5QzBAow3abuyQNnOhX8DK+RaZNH5dYwhGx0/pO2RgDMzsnvtKFaKwnk4VqGSnvMTPLGBTKzLpD06BTHtiDOGKaP8lj/3zoTWqxcxzzWARhfcV2+YG/pRbuJKU7/F0rww3W8tZeJ3mpU5EEPOa0ph4zKQ5UKVbzHEugB4+fB66SJC5x3dALRFoud/DuWtLJRgWsg5FDYLi2gyUh+ZRPptBxJILbY1TLTi16QUz2st5hFk/bb83dJQ8Am7tFIY=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(82310400014)(376005)(1800799015)(36860700004);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Mar 2024 19:38:59.3949
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 3a7b6868-0736-4eaf-9305-08dc43953aba
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN3PEPF0000B06C.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB9066

A new ELF note will specify the alignment for a relocatable PVH kernel.
ELF notes are suitable for vmlinux and other ELF files, so this
Linux-specific bzImage parsing in unnecessary.

This reverts commit c44cac229067faeec8f49247d1cf281723ac2d40.

Signed-off-by: Jason Andryuk 
---
 xen/arch/x86/bzimage.c             | 4 +---
 xen/arch/x86/hvm/dom0_build.c      | 4 +---
 xen/arch/x86/include/asm/bzimage.h | 2 +-
 xen/arch/x86/pv/dom0_build.c       | 2 +-
 4 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/xen/arch/x86/bzimage.c b/xen/arch/x86/bzimage.c
index 0f4cfc49f7..ac4fd428be 100644
--- a/xen/arch/x86/bzimage.c
+++ b/xen/arch/x86/bzimage.c
@@ -105,7 +105,7 @@ unsigned long __init bzimage_headroom(void *image_start,
 }
 
 int __init bzimage_parse(void *image_base, void **image_start,
-                         unsigned long *image_len, unsigned int *align)
+                         unsigned long *image_len)
 {
     struct setup_header *hdr = (struct setup_header *)(*image_start);
     int err = bzimage_check(hdr, *image_len);
@@ -118,8 +118,6 @@ int __init bzimage_parse(void *image_base, void **image_start,
     {
         *image_start += (hdr->setup_sects + 1) * 512 + hdr->payload_offset;
         *image_len = hdr->payload_length;
-        if ( align )
-            *align = hdr->kernel_alignment;
     }
 
     if ( elf_is_elfbinary(*image_start, *image_len) )
diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index bbae8a5645..0ceda4140b 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -548,14 +548,12 @@ static int __init pvh_load_kernel(struct domain *d, const module_t *image,
     struct elf_binary elf;
     struct elf_dom_parms parms;
     paddr_t last_addr;
-    unsigned int align = 0;
     struct hvm_start_info start_info = { 0 };
     struct hvm_modlist_entry mod = { 0 };
     struct vcpu *v = d->vcpu[0];
     int rc;
 
-    rc = bzimage_parse(image_base, &image_start, &image_len, &align);
-    if ( rc != 0 )
+    if ( (rc = bzimage_parse(image_base, &image_start, &image_len)) != 0 )
     {
         printk("Error trying to detect bz compressed kernel\n");
         return rc;
diff --git a/xen/arch/x86/include/asm/bzimage.h b/xen/arch/x86/include/asm/bzimage.h
index 2e04f5cc7b..7ed69d3910 100644
--- a/xen/arch/x86/include/asm/bzimage.h
+++ b/xen/arch/x86/include/asm/bzimage.h
@@ -6,6 +6,6 @@
 unsigned long bzimage_headroom(void *image_start, unsigned long image_length);
 
 int bzimage_parse(void *image_base, void **image_start,
-                  unsigned long *image_len, unsigned int *align);
+                  unsigned long *image_len);
 
 #endif /* __X86_BZIMAGE_H__ */
diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c
index e9fa8a9a82..d8043fa58a 100644
--- a/xen/arch/x86/pv/dom0_build.c
+++ b/xen/arch/x86/pv/dom0_build.c
@@ -416,7 +416,7 @@ int __init dom0_construct_pv(struct domain *d,
 
     d->max_pages = ~0U;
 
-    if ( (rc = bzimage_parse(image_base, &image_start, &image_len, NULL)) != 0 )
+    if ( (rc = bzimage_parse(image_base, &image_start, &image_len)) != 0 )
         return rc;
 
     if ( (rc = elf_init(&elf, image_start, image_len)) != 0 )
-- 
2.44.0



From xen-devel-bounces@lists.xenproject.org Wed Mar 13 19:39:13 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 19:39:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692751.1080186 (Exim 4.92)
	(envelope-from )
	id 1rkURK-0007JU-Oz; Wed, 13 Mar 2024 19:39:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692751.1080186; Wed, 13 Mar 2024 19:39:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkURK-0007JN-MB; Wed, 13 Mar 2024 19:39:02 +0000
Received: by outflank-mailman (input) for mailman id 692751;
 Wed, 13 Mar 2024 19:39:01 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkURJ-0007JH-Ou
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 19:39:01 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on20600.outbound.protection.outlook.com
 [2a01:111:f403:2009::600])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 564bc085-e171-11ee-afdd-a90da7624cb6;
 Wed, 13 Mar 2024 20:39:00 +0100 (CET)
Received: from BN1PR10CA0012.namprd10.prod.outlook.com (2603:10b6:408:e0::17)
 by PH0PR12MB7864.namprd12.prod.outlook.com (2603:10b6:510:26c::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.36; Wed, 13 Mar
 2024 19:38:57 +0000
Received: from BN3PEPF0000B06E.namprd21.prod.outlook.com
 (2603:10b6:408:e0:cafe::46) by BN1PR10CA0012.outlook.office365.com
 (2603:10b6:408:e0::17) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.20 via Frontend
 Transport; Wed, 13 Mar 2024 19:38:57 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN3PEPF0000B06E.mail.protection.outlook.com (10.167.243.73) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.0 via Frontend Transport; Wed, 13 Mar 2024 19:38:56 +0000
Received: from SATLEXMB06.amd.com (10.181.40.147) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Wed, 13 Mar
 2024 14:38:56 -0500
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB06.amd.com
 (10.181.40.147) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Wed, 13 Mar
 2024 14:38:55 -0500
Received: from fedora.mshome.net (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Wed, 13 Mar 2024 14:38:55 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 564bc085-e171-11ee-afdd-a90da7624cb6
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=IY35FrMSL9AQQ4+xljyowJsW74P4wtsdMvqzVcTh6CSAuOLBdb4gpJ18dM/P4oQ+v+USlWYEVbC3FIzyW43TxrTUXwDDjTSn7HaOu7ZzW4O1bKYv6G4NpgrW/4k0LLamNjm0qFMLnZna1ujoBsrCI1L1482CPk3jUYjnWrnrX5SFc/9aA7OyfZNWGP5STJM/tuA30uKzmIjON1ukzhCbwPxzcOePsrBv9PDNpdmPZR4e3QLnQ1481gxNfkUI/BkaNKo53phn/QGDRjztZ7WQjPmbiXcMv0eqCmKfp0n96DbsFGVTCVC0tNTTMFz4hTZwI+poV4Wnx8KtwGaN0F6+TA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Lz4h54/N/vGW4eVNNvLMe6hEsmbsEffwEzT057PZlXs=;
 b=cobKFs16vqbSl/boAwlV/bgvQqvu2Nswg8is3wJOXgBi7SNIHxe7DB/ddIg44sQmDpbyIghW+stT90ZtRxoo5cAzw6v/gz/AYC5ZhMp2x/cBDwcMGPwmOczupAyeHDQOFJQuHncWh6I26SkxfZwPrCBXUMku2sjRXfrzV9v33U5w5R3FCP/+gk2FF+9mIoeFbllgxoi8At6tbUOxVeALpQP+gRIiQ+zJp/aXl2+Xvq9qbC1EB38XO9Ctdd+5ZD0CJ7997TKP3TmPsFF/+NTQUiEcfmu/LU3/tHxzBmMDCSJF4+TAWuY+gmo+Cjp6Lxso7E0x8gqfW33VWtYEHrpwYw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=Lz4h54/N/vGW4eVNNvLMe6hEsmbsEffwEzT057PZlXs=;
 b=JFrAHE1fKxniWaUIZvIM7fGZAT3OzBbfTTU8xLYtsvlFGCafEi03IndHAeHnup1grOIj+319OFNHWf9EVXJllt2lDqQ/KVl1TH5290Uo/cWOvjY9N4bB+na94hHkQDgcMajK8afmZIj61lr1CAYwcgA7DPbJapYYrTBb42nrd8I=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Jason Andryuk 
To: 
CC: Jason Andryuk , Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Wei Liu
	, George Dunlap , Julien Grall
	, Stefano Stabellini 
Subject: [PATCH v2 0/3] x86/pvh: Support relocating dom0 kernel
Date: Wed, 13 Mar 2024 15:30:18 -0400
Message-ID: <20240313193021.241764-1-jason.andryuk@amd.com>
X-Mailer: git-send-email 2.44.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN3PEPF0000B06E:EE_|PH0PR12MB7864:EE_
X-MS-Office365-Filtering-Correlation-Id: 07128a3d-93b0-48b5-66af-08dc439538f5
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	NI0tetK6zEeojuZ1GrjDoEuynu0nAvJagg2FOO67ScBtTzDvGvJD8rC28a7VH+R5vXw8XsCOx1ZXUB8o7hh7gtPKO3TIGaAcEDYHrnOZsrVcOdzM1OB/u7C9sDXMaUx+eHw3zejWPoyLsO1RBSTy9D90EGJjQ+z0uybrolXJRVgxT3crF2+lSEl7Uq4td3cZtxhpUeWm+4PddeoVYZxsukQGBZlhbQvJdcGSQKOBcPrayJbJ4NG/oOMHE8w4kEqzqI3d/3aArx01BRsT1oVd7wecOCNa3n/9u6GwOMmu+05vuq1AmM5PjOM2s9BiX3+GTgvGYcK5B4VESVb7Rn+CvgkDZIuJWrM4ZLV0huUXQoI28oQE/PO1UcTTZxpV2pH7Qv9R+e30sfgZIBF3CQSWP+GhAoiuVk2uxOn3MOHvas1+7q3TrjE93KnAYyn907tAfMNvSr36ymkGk3crVE7bc+c3b8gE7is8kM1oy52XLtzyOr05x8guF9/Gt/mhW1aVihGBvvLxGOmz5+/C5VOHiIgUSs2lIFud/7gx1aT+kEBkbWRdLjaR2vtfBrh1wH6og4mu6D9McLf8XB58W/0ymfL0APagNM1LDdJHiFV117O9IvA56gmSVP2LnDa8cJG6cMx45dWehHnVgOghC6CJEF/jhPp4JZDKYo3eraGhZj5F3qRVxAsGm2TYZ1xJqW8OZ9aI/anWcDpyv7uugW1891x0FYHCi6WpTO4U9KilzSL4vIOnPFhAuGz3cf8y9tRh
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(36860700004)(376005)(82310400014)(1800799015);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Mar 2024 19:38:56.4093
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 07128a3d-93b0-48b5-66af-08dc439538f5
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN3PEPF0000B06E.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR12MB7864

Xen tries to load a PVH dom0 kernel at the fixed guest physical address
from the elf headers.  For Linux, this defaults to 0x1000000 (16MB), but
it can be configured.

Unfortunately there exist firmwares that have reserved regions at this
address, so Xen fails to load the dom0 kernel since it's not RAM.

The other issue is that the Linux PVH entry point is not
position-independent.  It expects to run at the compiled
CONFIG_PHYSICAL_ADDRESS.

This patch set expands the PVH dom0 builder to try to relocate the
kernel if needed and possible.  XEN_ELFNOTE_PVH_RELOCATION is added for
kernels to indicate they are relocatable and their acceptable address
range and alignment.

The first patch reverts "xen/x86: bzImage parse kernel_alignment" since
the alignment will be specified by the ELF note.

The second patch expands ELF note printing so arrays of values can be
handled.

The third patch expands the pvh dom0 kernel placement code.

I'll post an additional patch showing the Linux changes to make PVH
relocatable.

Jason Andryuk (3):
  Revert "xen/x86: bzImage parse kernel_alignment"
  libelf: Expand ELF note printing
  x86/PVH: Support relocatable dom0 kernels

 xen/arch/x86/bzimage.c             |   4 +-
 xen/arch/x86/hvm/dom0_build.c      | 112 ++++++++++++++++++++++++++++-
 xen/arch/x86/include/asm/bzimage.h |   2 +-
 xen/arch/x86/pv/dom0_build.c       |   2 +-
 xen/common/libelf/libelf-dominfo.c |  72 +++++++++++++------
 xen/include/public/elfnote.h       |  11 +++
 xen/include/xen/libelf.h           |   3 +
 7 files changed, 177 insertions(+), 29 deletions(-)

-- 
2.44.0



From xen-devel-bounces@lists.xenproject.org Wed Mar 13 19:39:13 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 19:39:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692753.1080206 (Exim 4.92)
	(envelope-from )
	id 1rkURV-0007rb-7n; Wed, 13 Mar 2024 19:39:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692753.1080206; Wed, 13 Mar 2024 19:39:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkURV-0007rR-4J; Wed, 13 Mar 2024 19:39:13 +0000
Received: by outflank-mailman (input) for mailman id 692753;
 Wed, 13 Mar 2024 19:39:11 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkURT-0007Yd-U2
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 19:39:11 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on20607.outbound.protection.outlook.com
 [2a01:111:f400:7e88::607])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5ce1089e-e171-11ee-a1ee-f123f15fe8a2;
 Wed, 13 Mar 2024 20:39:10 +0100 (CET)
Received: from CY5P221CA0145.NAMP221.PROD.OUTLOOK.COM (2603:10b6:930:6a::25)
 by CY5PR12MB6369.namprd12.prod.outlook.com (2603:10b6:930:21::10) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.35; Wed, 13 Mar
 2024 19:39:06 +0000
Received: from CY4PEPF0000E9CF.namprd03.prod.outlook.com
 (2603:10b6:930:6a:cafe::44) by CY5P221CA0145.outlook.office365.com
 (2603:10b6:930:6a::25) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.20 via Frontend
 Transport; Wed, 13 Mar 2024 19:39:05 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 CY4PEPF0000E9CF.mail.protection.outlook.com (10.167.241.142) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7386.12 via Frontend Transport; Wed, 13 Mar 2024 19:39:05 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Wed, 13 Mar
 2024 14:39:04 -0500
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB05.amd.com
 (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Wed, 13 Mar
 2024 14:39:04 -0500
Received: from fedora.mshome.net (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Wed, 13 Mar 2024 14:39:02 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5ce1089e-e171-11ee-a1ee-f123f15fe8a2
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=jSEtrjmKZKsOC7FOfgVsewbMOvUuqXGS5Zh+kjMOlVgaxscvewr2+QZmV1WNRvn2R2VRilaqTTo0luK5ScITdm1Rv9drtGnNBBNZzT75dAYtBK/yJ7kxSmIJ58NWN1i/lQs3mkfRRsp71XPs6LVpGs1iK+0JWGx+Y52ZFB6yLjK+T6j2MGcAZNm0HedXdPuGvzl96JlrfOnQxbWbBLGnKG18lip6CuaFD4tYeeHAa24DAyh6u8mzSLWo3+UXOYLGJl7QSLGIRtGdncL2mzaTMKCu6oNKyp6gg4cpoOVn5Wx159ERHcoq2ZdYcLoJZ92ZjvuqBnHSjaXKasEulAx+eg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ZaYStxNKhxziDBKjMiI264ns3R4OBvC1TLDcC7wP1GE=;
 b=c8V27ODprsF40khRs7sXT878TaNomsTM3deuhqat6hMdP2Y3aqTb5N5Td5sxSsggb97dosDP50wPH9tFRlvmlErCQ8SBkbgR5AT/ME3iZcnuDTOs8K0LdN6n3VVSmZkTWW1TVFHTaerYJHJpv0lxGe63l8NZDyTopFPfFQiHfE7DDD0B1/AcadokcgCWPGBdvYAAJaTbp/ZCI7oXrSM7Md5kHyJYBqFEX78PkvfOvUT1qcgMsh5NfiXMd/pM4kty2XR+qRyL7tQgDUnBnt0PoIqQLN/bYjm/9WcnBktEZikLT98T8cvbwFWyxiobT0ZOZYfLcGaK/xRjrIOWB5Q71g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=ZaYStxNKhxziDBKjMiI264ns3R4OBvC1TLDcC7wP1GE=;
 b=1AIdR64+BBhfKZrT5wZXd2DOXZsy15FrI5hLVo/FK1NEvUzEtataiEYK8PKEKI6XNN3o06njZdl0loLPSzcp1E4GdclbPUoR1lNBCM4r09NPnzC74VKsJ3j+AuEk/OhzICaIq3B61/1DoIuU9QrpaYhE8tRfTNK5K4GCyTEPJis=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
From: Jason Andryuk 
To: 
CC: Jason Andryuk , Andrew Cooper
	, George Dunlap , "Jan
 Beulich" , Julien Grall , "Stefano
 Stabellini" , Wei Liu 
Subject: [PATCH v2 2/3] libelf: Expand ELF note printing
Date: Wed, 13 Mar 2024 15:30:20 -0400
Message-ID: <20240313193021.241764-3-jason.andryuk@amd.com>
X-Mailer: git-send-email 2.44.0
In-Reply-To: <20240313193021.241764-1-jason.andryuk@amd.com>
References: <20240313193021.241764-1-jason.andryuk@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB05.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CY4PEPF0000E9CF:EE_|CY5PR12MB6369:EE_
X-MS-Office365-Filtering-Correlation-Id: 338926f9-b4e0-4fd2-fcee-08dc43953e35
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	xDEYkK9IRi2EoBCjF20Ik0ap0chhjn7aMoWF7sNlv/qF5/23/chd7BB/9UKtnBGJH/gGVc1HA9qKapPR0gDVueC2BbVCY/szsK0xmKo3eD1PGIYlhVVxkBV0AZDCVICHnU4HGNO5ZL9+L+68QPD1Bl3YkfZppxFXsalCs9nhJfQKj3ng+l55GrTdyx4u4caVlq0VR0SOkOzEWBqTsAAG6HV6pX2GGNhpA9I7Q/xTKURXtR5+wW50ySKF+MPiC2AhVh2WoviA3/2UtR9vXGNH1swE5t8eYqumikW2vXYYpbm88c60V8RNHXmC5WmF5NwpHnwBQsyJe+UWD8lTY8ef5iMAvYhgr4N0jYZPb4FI4DEez1nLR4BxSYu3Htt7mlP32kkTGk2uolVCtY8CUNqY2tQJU0xaOVySuG5DmWXCSTKbbj1m3A2rbQgro2lCI1IcspMGGYPLMaMxMQIdKl3ALMD89yBdBSCt9oLSxiMHBCDxQmQQTwZG/dagBJRfPLFQN7fx20wJ3QUxbnrmWUTs+Pq5UQ9SewQdmkgHOXWJGXohTpgghdlp+wxu+7edwPxB4dHw0OxrXQO3Y1PhXV22tkBr3yhQQpEYIETkrMPmaSYepeEKWL8ONQY2GT3ClJ6TQTv4KJTEx8o/y8NhHBTx5qOvcE5lny8Uj3kEcEtn6XkOJTNMOyzhB4MQdvOjlJctnw7nLyjDCx+dIMoj6Xcp5daf8K++4Me06C0vqoHEZOHaAJZjdRzxsWEFvTnQcXsn
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(36860700004)(82310400014)(1800799015)(376005);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Mar 2024 19:39:05.1587
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 338926f9-b4e0-4fd2-fcee-08dc43953e35
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CY4PEPF0000E9CF.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY5PR12MB6369

The XEN_ELFNOTE_L1_MFN_VALID is an arrray of two values, but it is
printed as:
(XEN) ELF: note: L1_MFN_VALID = 0

Expand the printing to handle an array.
(XEN) ELF: note: L1_MFN_VALID = mask: 0x1 val: 0x1

ELFNOTE_OTHER prints the name and " = ", but not the value.
Implementing a switch case is needed to show the value, which should
include a newline.

Signed-off-by: Jason Andryuk 
---
 xen/common/libelf/libelf-dominfo.c | 59 +++++++++++++++++++-----------
 1 file changed, 38 insertions(+), 21 deletions(-)

diff --git a/xen/common/libelf/libelf-dominfo.c b/xen/common/libelf/libelf-dominfo.c
index a13a5e4db6..7cc7b18a51 100644
--- a/xen/common/libelf/libelf-dominfo.c
+++ b/xen/common/libelf/libelf-dominfo.c
@@ -101,26 +101,30 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
 /* *INDENT-OFF* */
     static const struct {
         const char *name;
-        bool str;
+        enum {
+            ELFNOTE_INT,
+            ELFNOTE_STRING,
+            ELFNOTE_OTHER
+        } type;
     } note_desc[] = {
-        [XEN_ELFNOTE_ENTRY] = { "ENTRY", 0},
-        [XEN_ELFNOTE_HYPERCALL_PAGE] = { "HYPERCALL_PAGE", 0},
-        [XEN_ELFNOTE_VIRT_BASE] = { "VIRT_BASE", 0},
-        [XEN_ELFNOTE_INIT_P2M] = { "INIT_P2M", 0},
-        [XEN_ELFNOTE_PADDR_OFFSET] = { "PADDR_OFFSET", 0},
-        [XEN_ELFNOTE_HV_START_LOW] = { "HV_START_LOW", 0},
-        [XEN_ELFNOTE_XEN_VERSION] = { "XEN_VERSION", 1},
-        [XEN_ELFNOTE_GUEST_OS] = { "GUEST_OS", 1},
-        [XEN_ELFNOTE_GUEST_VERSION] = { "GUEST_VERSION", 1},
-        [XEN_ELFNOTE_LOADER] = { "LOADER", 1},
-        [XEN_ELFNOTE_PAE_MODE] = { "PAE_MODE", 1},
-        [XEN_ELFNOTE_FEATURES] = { "FEATURES", 1},
-        [XEN_ELFNOTE_SUPPORTED_FEATURES] = { "SUPPORTED_FEATURES", 0},
-        [XEN_ELFNOTE_BSD_SYMTAB] = { "BSD_SYMTAB", 1},
-        [XEN_ELFNOTE_L1_MFN_VALID] = { "L1_MFN_VALID", false },
-        [XEN_ELFNOTE_SUSPEND_CANCEL] = { "SUSPEND_CANCEL", 0 },
-        [XEN_ELFNOTE_MOD_START_PFN] = { "MOD_START_PFN", 0 },
-        [XEN_ELFNOTE_PHYS32_ENTRY] = { "PHYS32_ENTRY", 0 },
+        [XEN_ELFNOTE_ENTRY] = { "ENTRY", ELFNOTE_INT },
+        [XEN_ELFNOTE_HYPERCALL_PAGE] = { "HYPERCALL_PAGE", ELFNOTE_INT },
+        [XEN_ELFNOTE_VIRT_BASE] = { "VIRT_BASE", ELFNOTE_INT },
+        [XEN_ELFNOTE_INIT_P2M] = { "INIT_P2M", ELFNOTE_INT },
+        [XEN_ELFNOTE_PADDR_OFFSET] = { "PADDR_OFFSET", ELFNOTE_INT },
+        [XEN_ELFNOTE_HV_START_LOW] = { "HV_START_LOW", ELFNOTE_INT },
+        [XEN_ELFNOTE_XEN_VERSION] = { "XEN_VERSION", ELFNOTE_STRING },
+        [XEN_ELFNOTE_GUEST_OS] = { "GUEST_OS", ELFNOTE_STRING },
+        [XEN_ELFNOTE_GUEST_VERSION] = { "GUEST_VERSION", ELFNOTE_STRING },
+        [XEN_ELFNOTE_LOADER] = { "LOADER", ELFNOTE_STRING },
+        [XEN_ELFNOTE_PAE_MODE] = { "PAE_MODE", ELFNOTE_STRING },
+        [XEN_ELFNOTE_FEATURES] = { "FEATURES", ELFNOTE_STRING },
+        [XEN_ELFNOTE_SUPPORTED_FEATURES] = { "SUPPORTED_FEATURES", ELFNOTE_INT },
+        [XEN_ELFNOTE_BSD_SYMTAB] = { "BSD_SYMTAB", ELFNOTE_STRING },
+        [XEN_ELFNOTE_L1_MFN_VALID] = { "L1_MFN_VALID", ELFNOTE_OTHER },
+        [XEN_ELFNOTE_SUSPEND_CANCEL] = { "SUSPEND_CANCEL", ELFNOTE_INT },
+        [XEN_ELFNOTE_MOD_START_PFN] = { "MOD_START_PFN", ELFNOTE_INT },
+        [XEN_ELFNOTE_PHYS32_ENTRY] = { "PHYS32_ENTRY", ELFNOTE_INT },
     };
 /* *INDENT-ON* */
 
@@ -136,7 +140,7 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
         return 0;
     }
 
-    if ( note_desc[type].str )
+    if ( note_desc[type].type == ELFNOTE_STRING )
     {
         str = elf_strval(elf, elf_note_desc(elf, note));
         if (str == NULL)
@@ -146,13 +150,17 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
         parms->elf_notes[type].type = XEN_ENT_STR;
         parms->elf_notes[type].data.str = str;
     }
-    else
+    else if ( note_desc[type].type == ELFNOTE_INT )
     {
         val = elf_note_numeric(elf, note);
         elf_msg(elf, "ELF: note: %s = %#" PRIx64 "\n", note_desc[type].name, val);
         parms->elf_notes[type].type = XEN_ENT_LONG;
         parms->elf_notes[type].data.num = val;
     }
+    else
+    {
+        elf_msg(elf, "ELF: note: %s = ", note_desc[type].name);
+    }
     parms->elf_notes[type].name = note_desc[type].name;
 
     switch ( type )
@@ -217,6 +225,15 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
     case XEN_ELFNOTE_PHYS32_ENTRY:
         parms->phys_entry = val;
         break;
+
+    case XEN_ELFNOTE_L1_MFN_VALID:
+        if ( elf_uval(elf, note, descsz) != 2 * sizeof(uint64_t) )
+            return -1;
+
+        elf_msg(elf, "mask: %#"PRIx64" val: %#"PRIx64"\n",
+                elf_note_numeric_array(elf, note, 8, 0),
+                elf_note_numeric_array(elf, note, 8, 1));
+        break;
     }
     return 0;
 }
-- 
2.44.0



From xen-devel-bounces@lists.xenproject.org Wed Mar 13 19:39:15 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 19:39:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692754.1080216 (Exim 4.92)
	(envelope-from )
	id 1rkURX-00088l-HM; Wed, 13 Mar 2024 19:39:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692754.1080216; Wed, 13 Mar 2024 19:39:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkURX-00088e-EP; Wed, 13 Mar 2024 19:39:15 +0000
Received: by outflank-mailman (input) for mailman id 692754;
 Wed, 13 Mar 2024 19:39:13 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkURV-0007Yd-Hf
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 19:39:13 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on20601.outbound.protection.outlook.com
 [2a01:111:f403:2418::601])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5d5d8466-e171-11ee-a1ee-f123f15fe8a2;
 Wed, 13 Mar 2024 20:39:11 +0100 (CET)
Received: from BN9PR03CA0646.namprd03.prod.outlook.com (2603:10b6:408:13b::21)
 by SJ0PR12MB8090.namprd12.prod.outlook.com (2603:10b6:a03:4ea::22)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.36; Wed, 13 Mar
 2024 19:39:09 +0000
Received: from BN3PEPF0000B069.namprd21.prod.outlook.com
 (2603:10b6:408:13b:cafe::39) by BN9PR03CA0646.outlook.office365.com
 (2603:10b6:408:13b::21) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.35 via Frontend
 Transport; Wed, 13 Mar 2024 19:39:08 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN3PEPF0000B069.mail.protection.outlook.com (10.167.243.68) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.0 via Frontend Transport; Wed, 13 Mar 2024 19:39:08 +0000
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Wed, 13 Mar
 2024 14:39:06 -0500
Received: from fedora.mshome.net (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Wed, 13 Mar 2024 14:39:05 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5d5d8466-e171-11ee-a1ee-f123f15fe8a2
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=kAgMfomW72cUTDjqvEqQiWKpFmgZHtmBmJl1KvtnG1b/whR+m17V+7/BW+03cdhkH4llfjb3tWtxy4gNrBws/MiMEmYfRp2eIME1fF5yd5gMLJbxPnngOQEJ7ZQ5I8uFmqZZyywaGmqOp/uW7+18AqbUHq8Bl7ale3tYBrPLdCndwctm57/X0BWnlCRBU8QU/piL3iOEkVudgh1kxJmuns+TnsOtz+S7mxQCH4McMXHFa8UY5kU0xaPNpeNMnpcOQ/0lENxQjAwBwrTSgVQq4rFZWTbtU02EtAmx6zGx8pWIeJ8FvEhgGTUDwI9+XPLvx0GaKZlclLjaeJ5Z+YFbUg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=isSLpVSY0AA5iF+eAEUdjNCIEYGADkjQFYjW2bQ+zck=;
 b=Fs8MMlClH9ooTMElOJweGf9G/IAGipgVjmLcRiR5Z1CGg1XlvqwZvBaVJWtCnXAeNyWca5I0honLBf7JOfC2ecLLxU0AfNHlLBZDKEQqxYA/PtbaItiGPp31uHQpd7E8RAsVC5Slfi6DbXozHs8B5Gf7U/Wy27w+36p7ntGezsC+ps6sJCp9GteGIK0r39YTGXlMV4YOpRrFNJ+8V29Mj9CaNkAco13Uf6s4xg4tHeb0g7csgiJffmdNSO1CIYa7wWO3lFq4oOWw2WLz1nmUjmW0oSDhP4wlJUnssrPAERA0sAZSwoUuem6jvGWFPivIbwYGIh6NX5vpBIILC4HEug==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=isSLpVSY0AA5iF+eAEUdjNCIEYGADkjQFYjW2bQ+zck=;
 b=KTeo08n3cbdkPBuBHnaekA35vS6c2khMcYtVGnzNCsCrJXeQ/599qSJWXSxRjonBLwABL14NCaGljhkGibe6FHi3F0JeRBqeWNM31s3W/74wcCSOtlrxAO2cdJgprYLc5/HW9WNBfsGzFfrK4882ShEWEK47yBpHoAoO+cxdZl4=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Jason Andryuk 
To: 
CC: Jason Andryuk , Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Wei Liu
	, George Dunlap , Julien Grall
	, Stefano Stabellini 
Subject: [PATCH v2 3/3] x86/PVH: Support relocatable dom0 kernels
Date: Wed, 13 Mar 2024 15:30:21 -0400
Message-ID: <20240313193021.241764-4-jason.andryuk@amd.com>
X-Mailer: git-send-email 2.44.0
In-Reply-To: <20240313193021.241764-1-jason.andryuk@amd.com>
References: <20240313193021.241764-1-jason.andryuk@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB04.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN3PEPF0000B069:EE_|SJ0PR12MB8090:EE_
X-MS-Office365-Filtering-Correlation-Id: 9e01ad16-0beb-4507-f2c5-08dc43953fea
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	+dZJltLeqQLYIFQP5YL1WyRP0XRUOYPHnHBnOaHhCHv9wzSI9+CiqahwVQuCtTSWbzjtJ2sSgHJg6nuwCEM0EoFYO1ehMWya1O8Ka/eIKqIwrxL/ySkZbgygUE/7jCty3YRfyznveUInZkekzJae+LgSEhBmyxFcFLwYNjJ+SvcZsMONw3V/VXhIVBgtlJiOiC3iqOXJi2RWivUXFdPcYPZ4fdKn6ys3t96L80hwcdH3RLB8eSGhMJWdEKvQu2WJq1kzP3QOO9pf1aWqd0bTAZJD7vnw/bWubuh1N3sqmyKsHsRxonn5alnH+HPCNAr+EwZgOnqeQpBGxhktfI+VBlvZsaMc9uX/dvVEVtapQL2N9PNxoc1znHzdp46uH2b13YSjinJNVIPER5aD1QbCdQUylWor1HUxEGP/dBR6Axuk4rKXZvGL8UksLpS3GJlUVqGz5TTlcu83ldxkSBFR3EeYoLGdCkXj1GJNod3aCGqfpY8JNR3uUieM6873tZwOcSIU7+ld66+smrIcagf12JSGmBtBRP6PzNL1LXlZ6xEZQ0qHCJs4QEq/Ymd3RWgBbXmVxu+/9kJalYd9l4qCO3x8F1iHkE500AFSlJ+A+pmE+bTTV63FVXK548XAYSbQqX/LJdtYeZxQQ5OAF7Rfd68TUL4GEo3Jnj0oigaxyc5wl1V+cXXoIjDh4B4K36fxWwz6brOVZn0Ab7oknwkX5g==
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(36860700004)(82310400014)(376005)(1800799015);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Mar 2024 19:39:08.0849
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 9e01ad16-0beb-4507-f2c5-08dc43953fea
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN3PEPF0000B069.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR12MB8090

Xen tries to load a PVH dom0 kernel at the fixed guest physical address
from the elf headers.  For Linux, this defaults to 0x1000000 (16MB), but
it can be configured.

Unfortunately there exist firmwares that have reserved regions at this
address, so Xen fails to load the dom0 kernel since it's not RAM.

The PVH entry code is not relocatable - it loads from absolute
addresses, which fail when the kernel is loaded at a different address.
With a suitably modified kernel, a reloctable entry point is possible.

Add XEN_ELFNOTE_PVH_RELOCATION which specifies the minimum, maximum and
alignment needed for the kernel.  The presence of the NOTE indicates the
kernel supports a relocatable entry path.

Change the loading to check for an acceptable load address.  If the
kernel is relocatable, support finding an alternate load address.

Link: https://gitlab.com/xen-project/xen/-/issues/180
Signed-off-by: Jason Andryuk 
---
ELF Note printing looks like:
(XEN) ELF: note: PVH_RELOCATION = min: 0x1000000 max: 0xffffffff align: 0x200000

v2:
Use elfnote for min, max & align - use 64bit values.
Print original and relocated memory addresses
Use check_and_adjust_load_address() name
Return relocated base instead of offset
Use PAGE_ALIGN
Don't load above max_phys (expected to be 4GB in kernel elf note)
Use single line comments
Exit check_load_address loop earlier
Add __init to find_kernel_memory()
---
 xen/arch/x86/hvm/dom0_build.c      | 108 +++++++++++++++++++++++++++++
 xen/common/libelf/libelf-dominfo.c |  13 ++++
 xen/include/public/elfnote.h       |  11 +++
 xen/include/xen/libelf.h           |   3 +
 4 files changed, 135 insertions(+)

diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index 0ceda4140b..5c6c0d2db3 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -537,6 +537,108 @@ static paddr_t __init find_memory(
     return INVALID_PADDR;
 }
 
+static bool __init check_load_address(
+    const struct domain *d, const struct elf_binary *elf)
+{
+    paddr_t kernel_start = (paddr_t)elf->dest_base & PAGE_MASK;
+    paddr_t kernel_end = PAGE_ALIGN((paddr_t)elf->dest_base + elf->dest_size);
+    unsigned int i;
+
+    /*
+     * The memory map is sorted and all RAM regions starts and sizes are
+     * aligned to page boundaries.
+     */
+    for ( i = 0; i < d->arch.nr_e820; i++ )
+    {
+        paddr_t start = d->arch.e820[i].addr;
+        paddr_t end = d->arch.e820[i].addr + d->arch.e820[i].size;
+
+        if ( start >= kernel_end )
+            return false;
+
+        if ( start <= kernel_start &&
+             end >= kernel_end &&
+             d->arch.e820[i].type == E820_RAM )
+            return true;
+    }
+
+    return false;
+}
+
+/* Find an e820 RAM region that fits the kernel at a suitable alignment. */
+static paddr_t __init find_kernel_memory(
+    const struct domain *d, struct elf_binary *elf,
+    const struct elf_dom_parms *parms)
+{
+    paddr_t kernel_start = (paddr_t)elf->dest_base & PAGE_MASK;
+    paddr_t kernel_end = PAGE_ALIGN((paddr_t)elf->dest_base + elf->dest_size);
+    paddr_t kernel_size = kernel_end - kernel_start;
+    unsigned int i;
+
+    /*
+     * The memory map is sorted and all RAM regions starts and sizes are
+     * aligned to page boundaries.
+     */
+    for ( i = 0; i < d->arch.nr_e820; i++ )
+    {
+        paddr_t start = d->arch.e820[i].addr;
+        paddr_t end = d->arch.e820[i].addr + d->arch.e820[i].size;
+        paddr_t kstart, kend;
+
+        if ( d->arch.e820[i].type != E820_RAM )
+            continue;
+
+        if ( d->arch.e820[i].size < kernel_size )
+            continue;
+
+        kstart = ROUNDUP(start, parms->phys_align);
+        kstart = kstart < parms->phys_min ? parms->phys_min : kstart;
+        kend = kstart + kernel_size;
+
+        if ( kend > parms->phys_max )
+            return 0;
+
+        if ( kend <= end )
+            return kstart;
+    }
+
+    return 0;
+}
+
+/* Check the kernel load address, and adjust if necessary and possible. */
+static bool __init check_and_adjust_load_address(
+    const struct domain *d, struct elf_binary *elf, struct elf_dom_parms *parms)
+{
+    paddr_t reloc_base;
+
+    if ( check_load_address(d, elf) )
+        return true;
+
+    if ( parms->phys_align == UNSET_ADDR )
+    {
+        printk("Address conflict and %pd kernel is not relocatable\n", d);
+        return false;
+    }
+
+    reloc_base = find_kernel_memory(d, elf, parms);
+    if ( reloc_base == 0 )
+    {
+        printk("Failed find a load address for the kernel\n");
+        return false;
+    }
+
+    if ( opt_dom0_verbose )
+        printk("Relocating kernel from [%lx, %lx] -> [%lx, %lx]\n",
+               (paddr_t)elf->dest_base,
+               (paddr_t)elf->dest_base + elf->dest_size,
+               reloc_base, reloc_base + elf->dest_size);
+
+    parms->phys_entry += (reloc_base - (paddr_t)elf->dest_base);
+    elf->dest_base = (char *)reloc_base;
+
+    return true;
+}
+
 static int __init pvh_load_kernel(struct domain *d, const module_t *image,
                                   unsigned long image_headroom,
                                   module_t *initrd, void *image_base,
@@ -585,6 +687,12 @@ static int __init pvh_load_kernel(struct domain *d, const module_t *image,
     elf.dest_base = (void *)(parms.virt_kstart - parms.virt_base);
     elf.dest_size = parms.virt_kend - parms.virt_kstart;
 
+    if ( !check_and_adjust_load_address(d, &elf, &parms) )
+    {
+        printk("Unable to load kernel\n");
+        return -ENOMEM;
+    }
+
     elf_set_vcpu(&elf, v);
     rc = elf_load_binary(&elf);
     if ( rc < 0 )
diff --git a/xen/common/libelf/libelf-dominfo.c b/xen/common/libelf/libelf-dominfo.c
index 7cc7b18a51..837a1b0f21 100644
--- a/xen/common/libelf/libelf-dominfo.c
+++ b/xen/common/libelf/libelf-dominfo.c
@@ -125,6 +125,7 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
         [XEN_ELFNOTE_SUSPEND_CANCEL] = { "SUSPEND_CANCEL", ELFNOTE_INT },
         [XEN_ELFNOTE_MOD_START_PFN] = { "MOD_START_PFN", ELFNOTE_INT },
         [XEN_ELFNOTE_PHYS32_ENTRY] = { "PHYS32_ENTRY", ELFNOTE_INT },
+        [XEN_ELFNOTE_PVH_RELOCATION] = { "PVH_RELOCATION", ELFNOTE_OTHER },
     };
 /* *INDENT-ON* */
 
@@ -234,6 +235,17 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
                 elf_note_numeric_array(elf, note, 8, 0),
                 elf_note_numeric_array(elf, note, 8, 1));
         break;
+
+    case XEN_ELFNOTE_PVH_RELOCATION:
+        if ( elf_uval(elf, note, descsz) != 3 * sizeof(uint64_t) )
+            return -1;
+
+        parms->phys_min = elf_note_numeric_array(elf, note, 8, 0);
+        parms->phys_max = elf_note_numeric_array(elf, note, 8, 1);
+        parms->phys_align = elf_note_numeric_array(elf, note, 8, 2);
+        elf_msg(elf, "min: %#"PRIx64" max: %#"PRIx64" align: %#"PRIx64"\n",
+                parms->phys_min, parms->phys_max, parms->phys_align);
+        break;
     }
     return 0;
 }
@@ -545,6 +557,7 @@ elf_errorstatus elf_xen_parse(struct elf_binary *elf,
     parms->p2m_base = UNSET_ADDR;
     parms->elf_paddr_offset = UNSET_ADDR;
     parms->phys_entry = UNSET_ADDR32;
+    parms->phys_align = UNSET_ADDR;
 
     /* Find and parse elf notes. */
     count = elf_phdr_count(elf);
diff --git a/xen/include/public/elfnote.h b/xen/include/public/elfnote.h
index 8bf54d035b..70bb93499c 100644
--- a/xen/include/public/elfnote.h
+++ b/xen/include/public/elfnote.h
@@ -194,6 +194,17 @@
  */
 #define XEN_ELFNOTE_PHYS32_ENTRY 18
 
+/*
+ * Physical loading constraints for PVH kernels
+ *
+ * Used to place constraints on the guest physical loading addresses and
+ * alignment for a PVH kernel.  This note's value is 3 64bit values in
+ * the following order: minimum, maximum and alignment.
+ *
+ * The presence of this note indicates the kernel is relocatable.
+ */
+#define XEN_ELFNOTE_PVH_RELOCATION 19
+
 /*
  * The number of the highest elfnote defined.
  */
diff --git a/xen/include/xen/libelf.h b/xen/include/xen/libelf.h
index 1c77e3df31..d55a839411 100644
--- a/xen/include/xen/libelf.h
+++ b/xen/include/xen/libelf.h
@@ -431,6 +431,9 @@ struct elf_dom_parms {
     uint64_t virt_hv_start_low;
     uint64_t p2m_base;
     uint64_t elf_paddr_offset;
+    uint64_t phys_min;
+    uint64_t phys_max;
+    uint64_t phys_align;
     uint32_t f_supported[XENFEAT_NR_SUBMAPS];
     uint32_t f_required[XENFEAT_NR_SUBMAPS];
     uint32_t phys_entry;
-- 
2.44.0



From xen-devel-bounces@lists.xenproject.org Wed Mar 13 19:55:02 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 19:55:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692764.1080225 (Exim 4.92)
	(envelope-from )
	id 1rkUgf-0003ir-RI; Wed, 13 Mar 2024 19:54:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692764.1080225; Wed, 13 Mar 2024 19:54:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkUgf-0003ik-Ob; Wed, 13 Mar 2024 19:54:53 +0000
Received: by outflank-mailman (input) for mailman id 692764;
 Wed, 13 Mar 2024 19:54:52 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkUge-0003ie-2n
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 19:54:52 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on20601.outbound.protection.outlook.com
 [2a01:111:f403:2416::601])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8bd96942-e173-11ee-a1ee-f123f15fe8a2;
 Wed, 13 Mar 2024 20:54:49 +0100 (CET)
Received: from BN9PR03CA0461.namprd03.prod.outlook.com (2603:10b6:408:139::16)
 by DS0PR12MB6581.namprd12.prod.outlook.com (2603:10b6:8:d3::13) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.19; Wed, 13 Mar
 2024 19:54:44 +0000
Received: from BN3PEPF0000B06D.namprd21.prod.outlook.com
 (2603:10b6:408:139:cafe::71) by BN9PR03CA0461.outlook.office365.com
 (2603:10b6:408:139::16) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.35 via Frontend
 Transport; Wed, 13 Mar 2024 19:54:44 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 BN3PEPF0000B06D.mail.protection.outlook.com (10.167.243.72) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.0 via Frontend Transport; Wed, 13 Mar 2024 19:54:43 +0000
Received: from SATLEXMB08.amd.com (10.181.40.132) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Wed, 13 Mar
 2024 14:54:43 -0500
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB08.amd.com
 (10.181.40.132) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Wed, 13 Mar
 2024 12:54:43 -0700
Received: from fedora.mshome.net (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Wed, 13 Mar 2024 14:54:42 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8bd96942-e173-11ee-a1ee-f123f15fe8a2
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=Vu1DYvuWeJYLwrrNBTB8z1DQU3riBdQ6q9czIkmD6KgBnzajXEhbFZBc0pKvNXUP8O8t2j25A7OExYhK4BePPgnnE8H10ObszbZY+unSX7BsEpICtALC/iD+QoGwkn613SlzzAAka5szvIp4OY154EHq/CiiDy6VnISIGKdycuTVboT0mfQh1i6yIdPXGZ8Lpbn3y6QLTzATn+4CyILg5g7DBHwbOazDAPBqjVZdaaReUBEmX901DyyzHMtWqNeErQFU6YKd77DE52XFgu3A/Qeio4mcsB48s7dpImNxFBgvw58AeD/bLevM1GuCcbFNW+Dy0+tldEcTqSWLKyJiyg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=K3KEHyWZ45Wdbu143akVTpbHQb4wzlvUSovJv6P4SFM=;
 b=KliL4d/kh7y8Df/qRPQzA3fFNTdE/i1NjCUF7RvPYSy86e4j7AiH7WOLGzcbKu1qhx1JJdAL1n24t7E/I+gxR6ukVNmPPZ8jICHZGwxfM1GZbIEwHf+qJAzVTaI2ewDaRbfo1ZGAeCXg/pP6o2S+QQ+DcamXUCMPL60tFXMA4NcLvpA6WOWZcnjNediLZI5bI5+0WMkNaMqQc6hdnT2ic3cJaVIMV7oc+DDZAi67ZIWUpLjbYbtXo4Hwr3oVrwHmbg38JAAW1OD/gWQoJLivnKV6w4m9+48mWeMyoFf7Rf3UmXMg6e1XtltoFw9IDxjDNGRsVCb84XecYYVKwH7sSA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=K3KEHyWZ45Wdbu143akVTpbHQb4wzlvUSovJv6P4SFM=;
 b=qKhvAjr0XzUceiZtwxeQ9ZhY3oUm1o1UBH7VFwjX5BHuSxlfDMPNujonP8Z0gKqUtTnKvBJDUBgEIjp6+TZyw5hRtPqWM7zDvoUhODSlgBH9AFlXVYvsam0NltTLWGbUhpiXsqWyyu322wakhwt2oogA4KTQ+VxQCEVLaLMEdzc=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
From: Jason Andryuk 
To: 
CC: Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, Andrew Cooper , "Juergen
 Gross" , Boris Ostrovsky , Jason
 Andryuk 
Subject: [PATCH] RFC: x86/pvh: Make Xen PVH entrypoint PIC for x86-64
Date: Wed, 13 Mar 2024 15:46:12 -0400
Message-ID: <20240313194612.242957-1-jason.andryuk@amd.com>
X-Mailer: git-send-email 2.44.0
In-Reply-To: <20240313193021.241764-1-jason.andryuk@amd.com>
References: <20240313193021.241764-1-jason.andryuk@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN3PEPF0000B06D:EE_|DS0PR12MB6581:EE_
X-MS-Office365-Filtering-Correlation-Id: 4788504c-ca91-4d3e-d885-08dc43976db7
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	upv7Dk96RJ2Bgd3rdgOzN2wYWc7FbZPiL00WErL8Af7/xvnoJ8TdyNZ4fVbODwfk+KprSbErXmN+LU1qLWkDP2IU5ZqCpK5T3q7fKA2FwuhaUfxTWldfTRdu6IjKJ55jn6ZEUv4i+KVaYNz6DnhRQJaCLfo8FCpESv8FNkGFnJzC/d04wdtvcDsxupy5CdEqvGVqN0RxmgimLEH2hFHIotcpscJH3BR6k/SN+9oGTOfu6KKHNtKAu3/3k8kn60j006YATciw+St2qECXybxm4Cp0N7yaGzz1FReIneN4nCXsxwUFS4FBdMs9YWryWyjmRop1ZeDGBUQeYoaS8SEGmkAS2beS5AdPe6RSLlHCPOzE6BPjK6FVE0liwLTZWJoRbAEraaucIhDJlyv1FxcGDoArS2bEyYzHfPIN9Vv6oMU6bObKvacntaCRZd3bdwFI9BSR+iO1/3Jmhs4x+n+LWg8snBFhOFSZ2inYxYiItMKu8bLFRQOBGyrrJ4ExY6Gaz0iZpejFU5pZEaZFock5r1nG1kolhweAzCBzhtOvfZrmZBeX+rmt+BpnRR7jw+xAeT+HwTH64OvxbacPN8IHw02hVtWJ3VezOxnlRqKwW8YR3aCgmk5IG9lIDGLQRlC/Wnks+afjbnN5Ar0ApGn7FGngIO+mYfrTInmNhBgx8jVpCZ78GO7IYold7ZMz6yv4miGTCgCs/kwtabgtbUQZpjBgMWFFJbVGp2cWRqClcawQ9MKRR9OWXQQJHkfzPQvf
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(82310400014)(1800799015)(36860700004)(376005);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Mar 2024 19:54:43.9343
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 4788504c-ca91-4d3e-d885-08dc43976db7
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN3PEPF0000B06D.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB6581

The Xen PVH entrypoint is 32bit non-PIC code running at a default load
address of 0x1000000 (16MB) (CONFIG_PHYSICAL_START).  Xen loads the
kernel at that physical address inside the PVH container.

When running a PVH Dom0, the system reserved addresses are mapped 1-1
into the PVH container.  There exist system firmwares (Coreboot/EDK2)
with reserved memory at 16MB.  This creates a conflict where the PVH
kernel cannot be loaded at that address.

Modify the PVH entrypoint to be position-indepedent to allow flexibility
in load address.  Only the 64bit entry path is converted.  A 32bit
kernel is not PIC, so calling into other parts of the kernel, like
xen_prepare_pvh() and mk_pgtable_32(), don't work properly when
relocated.

Initial PVH entry runs at the physical addresses and then transitions to
the identity mapped address.  While executing xen_prepare_pvh() calls
through pv_ops function pointers transition to the high mapped
addresses.  Additionally, __va() is called on some hvm_start_info
physical addresses, we need the directmap address range is used.  So we
need to run page tables with all of those ranges mapped.

Modifying init_top_pgt tables ran into issue since
startup_64/__startup_64() will modify those page tables again.  Use a
dedicated set of page tables - pvh_init_top_pgt  - for the PVH entry to
avoid unwanted interactions.

In xen_pvh_init(), __pa() is called to find the physical address of the
hypercall page.  Set phys_base temporarily before calling into
xen_prepare_pvh(), which calls xen_pvh_init(), and clear it afterwards.
__startup_64() assumes phys_base is zero and adds load_delta to it.  If
phys_base is already set, the calculation results in an incorrect cr3.

TODO: Sync elfnote.h from xen.git commit xxxxxxxxxx when it is
commited.

Signed-off-by: Jason Andryuk 
---
Put this out as an example for the Xen modifications

Instead of setting and clearing phys_base, add a dedicated variable?
Clearing phys_base is a little weird, but it leaves the kernel more
consistent when running non-entry code.

Make __startup_64() exit if phys_base is already set to allow calling
multiple times, and use that and init_top_pgt instead of adding
additional page tables?  That won't work.  __startup_64 is 64bit code,
and pvh needs to create page tables in 32bit code before it can
transition to 64bit long mode.  Hence it can't be re-used to relocate
page tables.
---
 arch/x86/platform/pvh/head.S    | 182 ++++++++++++++++++++++++++++++--
 include/xen/interface/elfnote.h |  10 ++
 2 files changed, 181 insertions(+), 11 deletions(-)

diff --git a/arch/x86/platform/pvh/head.S b/arch/x86/platform/pvh/head.S
index f7235ef87bc3..cfb7fdc8c784 100644
--- a/arch/x86/platform/pvh/head.S
+++ b/arch/x86/platform/pvh/head.S
@@ -50,11 +50,32 @@
 #define PVH_CS_SEL		(PVH_GDT_ENTRY_CS * 8)
 #define PVH_DS_SEL		(PVH_GDT_ENTRY_DS * 8)
 
+#define rva(x) ((x) - pvh_start_xen)
+
 SYM_CODE_START_LOCAL(pvh_start_xen)
 	UNWIND_HINT_END_OF_STACK
 	cld
 
-	lgdt (_pa(gdt))
+	/*
+	 * See the comment for startup_32 for more details.  We need to
+	 * execute a call to get the execution address to be position
+	 * independent, but we don't have a stack.  Save and restore the
+	 * magic field of start_info in ebx, and use that as the stack.
+	 */
+	mov	(%ebx), %eax
+	leal	4(%ebx), %esp
+	ANNOTATE_INTRA_FUNCTION_CALL
+	call	1f
+1:	popl	%ebp
+	mov	%eax, (%ebx)
+	subl	$ rva(1b), %ebp
+	movl	$0, %esp
+
+	leal	rva(gdt)(%ebp), %eax
+	movl	%eax, %ecx
+	leal	rva(gdt_start)(%ebp), %ecx
+	movl	%ecx, 2(%eax)
+	lgdt	(%eax)
 
 	mov $PVH_DS_SEL,%eax
 	mov %eax,%ds
@@ -62,14 +83,14 @@ SYM_CODE_START_LOCAL(pvh_start_xen)
 	mov %eax,%ss
 
 	/* Stash hvm_start_info. */
-	mov $_pa(pvh_start_info), %edi
+	leal rva(pvh_start_info)(%ebp), %edi
 	mov %ebx, %esi
-	mov _pa(pvh_start_info_sz), %ecx
+	movl rva(pvh_start_info_sz)(%ebp), %ecx
 	shr $2,%ecx
 	rep
 	movsl
 
-	mov $_pa(early_stack_end), %esp
+	leal rva(early_stack_end)(%ebp), %esp
 
 	/* Enable PAE mode. */
 	mov %cr4, %eax
@@ -83,29 +104,83 @@ SYM_CODE_START_LOCAL(pvh_start_xen)
 	btsl $_EFER_LME, %eax
 	wrmsr
 
+	mov %ebp, %ebx
+	subl $LOAD_PHYSICAL_ADDR, %ebx /* offset */
+	jz .Lpagetable_done
+
+	/* Fixup page-tables for relocation. */
+	leal rva(pvh_init_top_pgt)(%ebp), %edi
+	movl $512, %ecx
+2:
+	movl 0x00(%edi), %eax
+	addl 0x04(%edi), %eax
+	jz 1f
+	addl %ebx, 0x00(%edi)
+1:
+	addl $8, %edi
+	decl %ecx
+	jnz 2b
+
+	/* L3 ident has a single entry. */
+	leal rva(pvh_level3_ident_pgt)(%ebp), %edi
+	addl %ebx, 0x00(%edi)
+
+	leal rva(pvh_level3_kernel_pgt)(%ebp), %edi
+	addl %ebx, (4096 - 16)(%edi)
+	addl %ebx, (4096 - 8)(%edi)
+
+	/* pvh_level2_ident_pgt is fine - large pages */
+
+	/* pvh_level2_kernel_pgt needs adjustment - large pages */
+	leal rva(pvh_level2_kernel_pgt)(%ebp), %edi
+	movl $512, %ecx
+2:
+	movl 0x00(%edi), %eax
+	addl 0x04(%edi), %eax
+	jz 1f
+	addl %ebx, 0x00(%edi)
+1:
+	addl $8, %edi
+	decl %ecx
+	jnz 2b
+
+.Lpagetable_done:
 	/* Enable pre-constructed page tables. */
-	mov $_pa(init_top_pgt), %eax
+	leal rva(pvh_init_top_pgt)(%ebp), %eax
 	mov %eax, %cr3
 	mov $(X86_CR0_PG | X86_CR0_PE), %eax
 	mov %eax, %cr0
 
 	/* Jump to 64-bit mode. */
-	ljmp $PVH_CS_SEL, $_pa(1f)
+	pushl $PVH_CS_SEL
+	leal  rva(1f)(%ebp), %eax
+	pushl %eax
+	lretl
 
 	/* 64-bit entry point. */
 	.code64
 1:
 	/* Set base address in stack canary descriptor. */
 	mov $MSR_GS_BASE,%ecx
-	mov $_pa(canary), %eax
+	leal rva(canary)(%ebp), %eax
 	xor %edx, %edx
 	wrmsr
 
+	/* Calculate load offset from LOAD_PHYSICAL_ADDR and store in
+	 * phys_base.  __pa() needs phys_base set to calculate the the
+	 * hypercall page in xen_pvh_init(). */
+	movq %rbp, %rbx
+	subq $LOAD_PHYSICAL_ADDR, %rbx
+	movq %rbx, phys_base(%rip)
 	call xen_prepare_pvh
+	/* Clear phys_base.  startup_64/__startup_64 will *add* to its value,
+	   so start from 0. */
+	xor  %rbx, %rbx
+	movq %rbx, phys_base(%rip)
 
 	/* startup_64 expects boot_params in %rsi. */
-	mov $_pa(pvh_bootparams), %rsi
-	mov $_pa(startup_64), %rax
+	lea rva(pvh_bootparams)(%ebp), %rsi
+	lea rva(startup_64)(%ebp), %rax
 	ANNOTATE_RETPOLINE_SAFE
 	jmp *%rax
 
@@ -137,13 +212,14 @@ SYM_CODE_START_LOCAL(pvh_start_xen)
 
 	ljmp $PVH_CS_SEL, $_pa(startup_32)
 #endif
+
 SYM_CODE_END(pvh_start_xen)
 
 	.section ".init.data","aw"
 	.balign 8
 SYM_DATA_START_LOCAL(gdt)
-	.word gdt_end - gdt_start
-	.long _pa(gdt_start)
+	.word gdt_end - gdt_start - 1
+	.long _pa(gdt_start) /* x86-64 will overwrite if relocated. */
 	.word 0
 SYM_DATA_END(gdt)
 SYM_DATA_START_LOCAL(gdt_start)
@@ -163,5 +239,89 @@ SYM_DATA_START_LOCAL(early_stack)
 	.fill BOOT_STACK_SIZE, 1, 0
 SYM_DATA_END_LABEL(early_stack, SYM_L_LOCAL, early_stack_end)
 
+#ifdef CONFIG_X86_64
+/*
+ * We are not able to switch in one step to the final KERNEL ADDRESS SPACE
+ * because we need identity-mapped pages.
+ */
+#define l4_index(x)     (((x) >> 39) & 511)
+#define pud_index(x)    (((x) >> PUD_SHIFT) & (PTRS_PER_PUD-1))
+
+L4_PAGE_OFFSET  = l4_index(__PAGE_OFFSET_BASE_L4)
+L4_START_KERNEL = l4_index(__START_KERNEL_map)
+L3_START_KERNEL = pud_index(__START_KERNEL_map)
+
+#define SYM_DATA_START_PAGE_ALIGNED(name)			\
+	SYM_START(name, SYM_L_GLOBAL, .balign PAGE_SIZE)
+
+/* Automate the creation of 1 to 1 mapping pmd entries */
+#define PMDS(START, PERM, COUNT)			\
+	i = 0 ;						\
+	.rept (COUNT) ;					\
+	.quad	(START) + (i << PMD_SHIFT) + (PERM) ;	\
+	i = i + 1 ;					\
+	.endr
+
+/*
+ * Xen PVH needs a set of identity mapped and kernel high mapping
+ * page tables.  pvh_start_xen starts running on the identity mapped
+ * page tables, but xen_prepare_pvh calls into the high mapping.
+ * These page tables need to be relocatable and are only used until
+ * startup_64 transitions to init_top_pgt.
+ */
+SYM_DATA_START_PAGE_ALIGNED(pvh_init_top_pgt)
+	.quad   pvh_level3_ident_pgt - __START_KERNEL_map + _KERNPG_TABLE_NOENC
+	.org    pvh_init_top_pgt + L4_PAGE_OFFSET*8, 0
+	.quad   pvh_level3_ident_pgt - __START_KERNEL_map + _KERNPG_TABLE_NOENC
+	.org    pvh_init_top_pgt + L4_START_KERNEL*8, 0
+	/* (2^48-(2*1024*1024*1024))/(2^39) = 511 */
+	.quad   pvh_level3_kernel_pgt - __START_KERNEL_map + _PAGE_TABLE_NOENC
+SYM_DATA_END(pvh_init_top_pgt)
+
+SYM_DATA_START_PAGE_ALIGNED(pvh_level3_ident_pgt)
+	.quad	pvh_level2_ident_pgt - __START_KERNEL_map + _KERNPG_TABLE_NOENC
+	.fill	511, 8, 0
+SYM_DATA_END(pvh_level3_ident_pgt)
+SYM_DATA_START_PAGE_ALIGNED(pvh_level2_ident_pgt)
+	/*
+	 * Since I easily can, map the first 1G.
+	 * Don't set NX because code runs from these pages.
+	 *
+	 * Note: This sets _PAGE_GLOBAL despite whether
+	 * the CPU supports it or it is enabled.  But,
+	 * the CPU should ignore the bit.
+	 */
+	PMDS(0, __PAGE_KERNEL_IDENT_LARGE_EXEC, PTRS_PER_PMD)
+SYM_DATA_END(pvh_level2_ident_pgt)
+SYM_DATA_START_PAGE_ALIGNED(pvh_level3_kernel_pgt)
+	.fill	L3_START_KERNEL,8,0
+	/* (2^48-(2*1024*1024*1024)-((2^39)*511))/(2^30) = 510 */
+	.quad	pvh_level2_kernel_pgt - __START_KERNEL_map + _KERNPG_TABLE_NOENC
+	.quad	0 /* no fixmap */
+SYM_DATA_END(pvh_level3_kernel_pgt)
+
+SYM_DATA_START_PAGE_ALIGNED(pvh_level2_kernel_pgt)
+	/*
+	 * Kernel high mapping.
+	 *
+	 * The kernel code+data+bss must be located below KERNEL_IMAGE_SIZE in
+	 * virtual address space, which is 1 GiB if RANDOMIZE_BASE is enabled,
+	 * 512 MiB otherwise.
+	 *
+	 * (NOTE: after that starts the module area, see MODULES_VADDR.)
+	 *
+	 * This table is eventually used by the kernel during normal runtime.
+	 * Care must be taken to clear out undesired bits later, like _PAGE_RW
+	 * or _PAGE_GLOBAL in some cases.
+	 */
+	PMDS(0, __PAGE_KERNEL_LARGE_EXEC, KERNEL_IMAGE_SIZE/PMD_SIZE)
+SYM_DATA_END(pvh_level2_kernel_pgt)
+
+	ELFNOTE(Xen, XEN_ELFNOTE_PVH_RELOCATION,
+		     .quad LOAD_PHYSICAL_ADDR;
+		     .quad 0xffffffff;
+		     .quad CONFIG_PHYSICAL_ALIGN)
+#endif
+
 	ELFNOTE(Xen, XEN_ELFNOTE_PHYS32_ENTRY,
 	             _ASM_PTR (pvh_start_xen - __START_KERNEL_map))
diff --git a/include/xen/interface/elfnote.h b/include/xen/interface/elfnote.h
index 38deb1214613..f2b418db4261 100644
--- a/include/xen/interface/elfnote.h
+++ b/include/xen/interface/elfnote.h
@@ -185,6 +185,16 @@
  */
 #define XEN_ELFNOTE_PHYS32_ENTRY 18
 
+/*
+ * Physical loading constraints for PVH kernels
+ *
+ * Used to place constraints on the guest physical loading addresses and
+ * alignment for a PVH kernel.  This note's value is 3 64bit values in
+ * the following order: minimum, maximum and alignment.
+ *
+ * The presence of this note indicates the kernel is relocatable.
+ */
+#define XEN_ELFNOTE_PVH_RELOCATION 19
 /*
  * The number of the highest elfnote defined.
  */
-- 
2.44.0



From xen-devel-bounces@lists.xenproject.org Wed Mar 13 20:00:25 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 20:00:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692768.1080235 (Exim 4.92)
	(envelope-from )
	id 1rkUlx-0005aB-Hk; Wed, 13 Mar 2024 20:00:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692768.1080235; Wed, 13 Mar 2024 20:00:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkUlx-0005a4-Eu; Wed, 13 Mar 2024 20:00:21 +0000
Received: by outflank-mailman (input) for mailman id 692768;
 Wed, 13 Mar 2024 20:00:20 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkUlw-0005Zu-AD; Wed, 13 Mar 2024 20:00:20 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkUlw-0006MQ-6T; Wed, 13 Mar 2024 20:00:20 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkUlv-0002Kn-QZ; Wed, 13 Mar 2024 20:00:19 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rkUlv-0007mh-Q3; Wed, 13 Mar 2024 20:00:19 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=TPjd4ddxefs6ya9N5ga+9BRmLPPqGR5ac6tmhw1+67U=; b=GSLxcmBpZ0G9t92xFNA0PlfqFH
	w+XMiamZtdGbm7MwlvxJS3ZPlU1vu7mTRrFhv8V70WjHkcQKxtm3o+M7qWItOhRQ/q6oTusChyrr2
	FUVUJmRAt8kt25nS6XIIapuEU9yKIZDjMW/05FahMVd7m+4gXVuFiqI/LJNfFvawkCb0=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-4.18-testing test] 185014: regressions - FAIL
X-Osstest-Failures:
    xen-4.18-testing:test-armhf-armhf-xl-credit1:guest-start/debian.repeat:fail:regression
    xen-4.18-testing:build-arm64-pvops:kernel-build:fail:regression
    xen-4.18-testing:test-amd64-amd64-xl-qemut-debianhvm-i386-xsm:debian-hvm-install:fail:regression
    xen-4.18-testing:test-arm64-arm64-libvirt-raw:build-check(1):blocked:nonblocking
    xen-4.18-testing:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl:build-check(1):blocked:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-credit1:build-check(1):blocked:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-credit2:build-check(1):blocked:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-thunderx:build-check(1):blocked:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-vhd:build-check(1):blocked:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-xsm:build-check(1):blocked:nonblocking
    xen-4.18-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    xen-4.18-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    xen-4.18-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    xen-4.18-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-i386-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    xen=4da8ca9cb9cfdb92c9dd09d5270ae16a3b2dbc89
X-Osstest-Versions-That:
    xen=a96d2d4355d85fc82abd0a3799978db04ee8cff3
From: osstest service owner 
Date: Wed, 13 Mar 2024 20:00:19 +0000

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-credit1 18 guest-start/debian.repeat fail REGR. vs. 185003
 build-arm64-pvops             6 kernel-build             fail REGR. vs. 185003
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail REGR. vs. 185003

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

version targeted for testing:
 xen                  4da8ca9cb9cfdb92c9dd09d5270ae16a3b2dbc89
baseline version:
 xen                  a96d2d4355d85fc82abd0a3799978db04ee8cff3

Last test of basis   185003  2024-03-12 11:40:22 Z    1 days
Testing same since   185014  2024-03-13 02:53:58 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Roger Pau Monné 

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            fail    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          blocked 
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 fail    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 blocked 
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      blocked 
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  blocked 
 test-armhf-armhf-xl-credit1                                  fail    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  blocked 
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-armhf-armhf-libvirt-qcow2                               pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-arm64-arm64-libvirt-raw                                 blocked 
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-libvirt-raw                                  pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 blocked 
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-arm64-arm64-xl-vhd                                      blocked 
 test-armhf-armhf-xl-vhd                                      pass    
 test-amd64-i386-xl-vhd                                       pass    


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

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

Explanation of these 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 323 lines long.)


From xen-devel-bounces@lists.xenproject.org Wed Mar 13 21:11:51 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 21:11:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692775.1080249 (Exim 4.92)
	(envelope-from )
	id 1rkVsu-0007Kd-OW; Wed, 13 Mar 2024 21:11:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692775.1080249; Wed, 13 Mar 2024 21:11:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkVsu-0007KW-LS; Wed, 13 Mar 2024 21:11:36 +0000
Received: by outflank-mailman (input) for mailman id 692775;
 Wed, 13 Mar 2024 21:11:36 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkVst-0007KQ-V1
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 21:11:36 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on20600.outbound.protection.outlook.com
 [2a01:111:f403:200a::600])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 44b91b09-e17e-11ee-afdd-a90da7624cb6;
 Wed, 13 Mar 2024 22:11:34 +0100 (CET)
Received: from CY8PR19CA0038.namprd19.prod.outlook.com (2603:10b6:930:6::26)
 by LV2PR12MB5918.namprd12.prod.outlook.com (2603:10b6:408:174::21) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.35; Wed, 13 Mar
 2024 21:11:29 +0000
Received: from CY4PEPF0000E9D4.namprd03.prod.outlook.com
 (2603:10b6:930:6:cafe::99) by CY8PR19CA0038.outlook.office365.com
 (2603:10b6:930:6::26) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.20 via Frontend
 Transport; Wed, 13 Mar 2024 21:11:29 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 CY4PEPF0000E9D4.mail.protection.outlook.com (10.167.241.147) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7386.12 via Frontend Transport; Wed, 13 Mar 2024 21:11:28 +0000
Received: from SATLEXMB08.amd.com (10.181.40.132) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Wed, 13 Mar
 2024 16:11:27 -0500
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB08.amd.com
 (10.181.40.132) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Wed, 13 Mar
 2024 14:11:27 -0700
Received: from [172.17.162.8] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Wed, 13 Mar 2024 16:11:27 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 44b91b09-e17e-11ee-afdd-a90da7624cb6
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=JMKwaKhcpgQhawOrA1+H+tTRz+yf8CpAfuR33RbynQTaT5005BOLVreZ1M0S80kbhm7vNVCvBnvfB4s40zIXGj5RnNia2kxFwGoVVT3LMNT66/ELGAMCGFiqPYSTQbjXrBvfeRHBkwiM8RwFFFe/GKN+vMTIcqASUvbQ0YklV9FZYtDH4TkJcy8+qz30GpvZguVaCde/U2UjtA5p2O6vKyIB96vNmIp6YZaWRa/ioSzJcm4sN+CvrJamqzR1J+n8j+UA2Su28LoMUPJWRWEA4iFzGq+t6CYM/dlSmubURBTDcRnO69CCyvOsqOUmT/KlxunqVUvq71Z4Uj2D5vSEuA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=BOA50aDClGxCZ7KJGc0o8TzBjN4VZHbs1YW90aGbT30=;
 b=i/RvT1UQWqJHEaBEmv+NyCIMLpwbk4qjYnOd2qnsVjPbLS+9Dk+z9iGek1Y1B1kIwoI8fD1EkfkxYQIm5gLVxpEWcps3M1dhdalkPpURU1xI1oKJj6+7JP64xqBMF2mKJRVDJ3+mjH1iZmi20gpCQzjVe/t9U1/BRCxhdIqbCXboxoi1Jmk+X99vaieHhmDMtfmGN0iPZvYMQV7m0TQcgIJ/5pcg4jIAYcnR/uJO8QR/8gZ3iEfKLd8I2Lhot7EIIH+5Yqjym08MLe3Nx54FNv47xAEzMwqoiLUjW6rx3O7r0jDtheaWgxCVXFJTbQPkwR0twiw3WXLu/CWBZgOIkA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=BOA50aDClGxCZ7KJGc0o8TzBjN4VZHbs1YW90aGbT30=;
 b=p46MFm83wZReXOkwBmmFMt9AXgPVnEkMBQTVwFGN7uWhX4dAGPQNvm2yj2jtR4XKsD/pvIfzmEnBYkIIpik8nKdNQNx4gidRw1YF3TWFsKUXrbetEjIKBLIjEgSsGZtbDvzNcnz/hhNVN5oDTxlytGv2u/+oc+BtcyLzbSQRED4=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
Message-ID: <70daf607-03e7-4927-8ce2-5721ca3387ee@amd.com>
Date: Wed, 13 Mar 2024 17:02:56 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 3/3] x86/PVH: Support relocatable dom0 kernels
To: 
CC: Jan Beulich , Andrew Cooper
	, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
	, Wei Liu , George Dunlap
	, Julien Grall , Stefano Stabellini
	
References: <20240313193021.241764-1-jason.andryuk@amd.com>
 <20240313193021.241764-4-jason.andryuk@amd.com>
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: <20240313193021.241764-4-jason.andryuk@amd.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CY4PEPF0000E9D4:EE_|LV2PR12MB5918:EE_
X-MS-Office365-Filtering-Correlation-Id: 0214dec3-b7e7-4be0-057b-08dc43a22653
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	+pl13C0La32KDK68EV1rmpKPnrhTzhIPbrnJdFvPW7DLh6x6TXXnl7U0whsuz0SpCwUIA0zAABn6mHX6BUTwdHppr2cyJjamnnc5fg5+3da07ddbnZL3/v31IXwlbXgORnAh4mHPfTkNzJZbpfj67lD5fzStqlV8ahKtLTyYsziBfDs8kLG+2G3Xk3DXMguLmANkIzjsE/1pBga/qWEOLa3U2NQalEdwnR6B83zQPlqnnCbbphJ8lDyhb0ntm11tORqeyo4RLmgiu4RxfnyaYhgTx5oT71/jK/uJrSXX7kvkXDHkfLugfDPpjywKz+giCgYe4Apcso6OCjbWiCYtdkU8iD1z2kaNuJLnxwRI/SOpftgx/3KYL9bzmJhtf+kh0QYnX/pdbp9ny/J2qrbszaYKpjmLLqJgawVS8EgV8Yytu3SAQedBuAR6CPK0EAIBHcwVZxomYInxhFNYEKri/bgEkmr0IdzLIe2xVJOA+Li2qONbB+YskFOJOvZnXP5kvxMencsbz8PVdHJUVfsHPYUb5s4EsMUJcBH5H4XHcN0lWsTyIdhcAXly2rA3yQJnQ4GdUr3AdG5X/OsHpoJIijF1nko2hSpe82VZ2vCBFr0mZS52UsDp4y+gQIhGiVMgXdas8wjcjBxio7tRDt9nVsai4MNFaEbdhLjFf2ZpF2YhwBZdY+RCzwJbO/qRykSROaLCQ7Cg2d7zz+C4FAvnVt0QQaou9/XwhXVQ6Kv4YbtjRcDyu+hzFWylCdgRE7NW
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(82310400014)(36860700004)(376005)(1800799015);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Mar 2024 21:11:28.5412
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 0214dec3-b7e7-4be0-057b-08dc43a22653
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CY4PEPF0000E9D4.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV2PR12MB5918

On 2024-03-13 15:30, Jason Andryuk wrote:
> +/* Find an e820 RAM region that fits the kernel at a suitable alignment. */
> +static paddr_t __init find_kernel_memory(
> +    const struct domain *d, struct elf_binary *elf,
> +    const struct elf_dom_parms *parms)
> +{
> +    paddr_t kernel_start = (paddr_t)elf->dest_base & PAGE_MASK;
> +    paddr_t kernel_end = PAGE_ALIGN((paddr_t)elf->dest_base + elf->dest_size);
> +    paddr_t kernel_size = kernel_end - kernel_start;
> +    unsigned int i;
> +
> +    /*
> +     * The memory map is sorted and all RAM regions starts and sizes are
> +     * aligned to page boundaries.
> +     */
> +    for ( i = 0; i < d->arch.nr_e820; i++ )
> +    {
> +        paddr_t start = d->arch.e820[i].addr;
> +        paddr_t end = d->arch.e820[i].addr + d->arch.e820[i].size;
> +        paddr_t kstart, kend;
> +
> +        if ( d->arch.e820[i].type != E820_RAM )
> +            continue;
> +
> +        if ( d->arch.e820[i].size < kernel_size )
> +            continue;
> +
> +        kstart = ROUNDUP(start, parms->phys_align);
> +        kstart = kstart < parms->phys_min ? parms->phys_min : kstart;

This should be
         kstart = MAX(kstart, parms->phys_min);

Regards,
Jason

> +        kend = kstart + kernel_size;
> +
> +        if ( kend > parms->phys_max )
> +            return 0;
> +
> +        if ( kend <= end )
> +            return kstart;
> +    }
> +
> +    return 0;
> +}


From xen-devel-bounces@lists.xenproject.org Wed Mar 13 21:29:24 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 21:29:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692780.1080278 (Exim 4.92)
	(envelope-from )
	id 1rkWA1-0001IG-GQ; Wed, 13 Mar 2024 21:29:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692780.1080278; Wed, 13 Mar 2024 21:29:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkWA1-0001I9-Ci; Wed, 13 Mar 2024 21:29:17 +0000
Received: by outflank-mailman (input) for mailman id 692780;
 Wed, 13 Mar 2024 21:29:15 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkW9z-0000t0-7P
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 21:29:15 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id baf323ce-e180-11ee-afdd-a90da7624cb6;
 Wed, 13 Mar 2024 22:29:12 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id EC8B96119A;
 Wed, 13 Mar 2024 21:29:09 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id EA77FC433F1;
 Wed, 13 Mar 2024 21:29:08 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: baf323ce-e180-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1710365349;
	bh=Bso4gP8lGFoM6PdkrcO7zM5aQ2bfhaRYxY1cmj6FdpE=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=asWJebLKZqCuNVgkbhSkTcou+NcaQe8tGARoj4DSBOuR1E8O3Jx+fEq2DBxOUGcLs
	 kN4OZ4X1xUeicnC/2Q1i4NdYDgjBswQ5OXEXEdSMy/UZumKMItupi+f+SxWdpB8t/0
	 J6CT/rSMhUEbFVV1y44iaYY/813MuT8Raz8e4R6f/qj0Ha9hMHOFURjjjv8UZeXChe
	 fpHkdD049ltVwrJAeN76FdhkRVb3eoWwgLWq0BM3Yol/+IUmNQCpyrt8zoPbFh9LPh
	 gHp+1izSf0yoK0k36zxtLgjGC3wR8XyTtfM34TPXHuaxfLHoZNXoWoexufeY0ewu74
	 KCym7ntdhKdyA==
Date: Wed, 13 Mar 2024 14:29:07 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Kelly Choi 
cc: xen-devel , xen-users@lists.xenproject.org, 
    advisory-board@lists.xenproject.org, committers@xenproject.org
Subject: Re: Mailing list changes
In-Reply-To: 
Message-ID: 
References: 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-44451026-1710365349=:853156"

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-44451026-1710365349=:853156
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Wed, 13 Mar 2024, Kelly Choi wrote:
> Hi everyone,
> We recently discussed some mailing list changes in our last community call. 
> 
> Issue:
>  *  Lists.xenproject.org software is outdated, DKIM, DMARC, ARC is no longer sufficient, and there's no clear update path from Mailman2 to
>     Mailman3. 
> Potential solution:
>  *  Host them at https://subspace.kernel.org/ due to us being part of the Linux Foundation
>  *  No additional cost to the project
> There was no objection to this during the call. For everyone else who was not present, please feel free to give your feedback here on the
> mailing list (should you have any).

Hi all,

I just wanted to add that the kernel.org infrastructure is very well
maintained -- I can recommend it.
--8323329-44451026-1710365349=:853156--


From xen-devel-bounces@lists.xenproject.org Wed Mar 13 22:36:46 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 22:36:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692808.1080288 (Exim 4.92)
	(envelope-from )
	id 1rkXD5-0002w8-Eh; Wed, 13 Mar 2024 22:36:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692808.1080288; Wed, 13 Mar 2024 22:36:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkXD5-0002w1-B8; Wed, 13 Mar 2024 22:36:31 +0000
Received: by outflank-mailman (input) for mailman id 692808;
 Wed, 13 Mar 2024 22:36:30 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkXD4-0002vv-BX
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 22:36:30 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org
 [2604:1380:4641:c500::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 212895e4-e18a-11ee-a1ee-f123f15fe8a2;
 Wed, 13 Mar 2024 23:36:28 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id EF1BD61476;
 Wed, 13 Mar 2024 22:36:26 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7E525C433F1;
 Wed, 13 Mar 2024 22:36:25 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 212895e4-e18a-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1710369386;
	bh=2bhy0KpQCUdsqpzVvwAMwVTCEyAPBiPR1v62GkCGL8k=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=aV8USHzX0FnrlECDHXY5BaAgBEdmLy7sFTSSoWUz9vZMJ8YPpp48I6BAnoPYmRDAc
	 03s+3+6WJoZOxlgx4QB3/G2OITmP01ViSopr0zkJcQH0BGbaVlWx0kOp6YIX4aCm05
	 I8xitejxNptdEdVF2Rv9X/M9pqb6JuQKkIzp5G2ohKvC9pmSvnJ6SW8UjjfT4Cl9DZ
	 irs4OpnzuJtEQTPVTSlOixWJpfn2MhxUdviul8syCSkBjBu899tsU3s9wf4VSdYV0b
	 7hxjoFxYAMK75RMCchggFG6KvaAcXJHj1BTrLJBy/vlW8DCyN1D9N4j4sW8Srl73aT
	 /NmYW+ybKWRAQ==
Date: Wed, 13 Mar 2024 15:36:23 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Paul Durrant 
cc: xen-devel@lists.xenproject.org, Paul Durrant , 
    Andrew Cooper , 
    George Dunlap , Jan Beulich , 
    Julien Grall , Stefano Stabellini , 
    Wei Liu 
Subject: Re: [PATCH] MAINTAINERS: Remove myself from several subsystems
In-Reply-To: <20240313184125.39185-1-paul@xen.org>
Message-ID: 
References: <20240313184125.39185-1-paul@xen.org>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Wed, 13 Mar 2024, Paul Durrant wrote:
> From: Paul Durrant 
> 
> I am not as actively involved with the Xen project as I once was so I need
> to relinquish some of my maintainer responsibilities: IOMMU and I/O
> emulation.
> 
> NOTE: Since I am sole maintainer for I/O EMULATION (IOREQ) and
>       X86 I/O EMULATION, these sections are removed.
> 
> Signed-off-by: Paul Durrant 

Acked-by: Stefano Stabellini 


From xen-devel-bounces@lists.xenproject.org Wed Mar 13 23:05:11 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 23:05:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692812.1080298 (Exim 4.92)
	(envelope-from )
	id 1rkXej-0007TL-Kc; Wed, 13 Mar 2024 23:05:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692812.1080298; Wed, 13 Mar 2024 23:05:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkXej-0007TE-GQ; Wed, 13 Mar 2024 23:05:05 +0000
Received: by outflank-mailman (input) for mailman id 692812;
 Wed, 13 Mar 2024 23:05:04 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkXei-0007T8-GR
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 23:05:04 +0000
Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1e0c5231-e18e-11ee-a1ee-f123f15fe8a2;
 Thu, 14 Mar 2024 00:05:01 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sin.source.kernel.org (Postfix) with ESMTP id DE02ECE1CA2;
 Wed, 13 Mar 2024 23:04:56 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1531EC433C7;
 Wed, 13 Mar 2024 23:04:54 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1e0c5231-e18e-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1710371096;
	bh=294N+38gOOh3pZ1r4mUaNjHKsZxwVMcpbaIIT40Dm9o=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=u5pc8ebSDw8TtxU13rFUCnQvDqGpffGofeKubzHKzG2bgZ6G98o8a8+VHthactvTP
	 WLKHUjgfGP1yq0AuW+N9VQQ0IbI5L//G4zmkXRz6glDcKHPcpLrFZcTyuvOQJB59ej
	 duR5l6pIqj1i7IKfcn7kAXP6FhA/Zv1BnQcvwyxbDZDoOTDHJJAARmw7POMC4/I+rs
	 oUSCJOC0Sq9n3XQoXaDfZXb98GZ+vPthI1Dh+Q7oIvki3SW6s3wnjOPYpd75xF1IvS
	 q5+V7yKjQ42koLkgzePMO4oPGof8r/3i5utAhtfl3oAlgmQ0JJS+pAfo8BK7DNHU9a
	 8Imnk8hNaHWfg==
Date: Wed, 13 Mar 2024 16:04:53 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich 
cc: Stefano Stabellini , andrew.cooper3@citrix.com, 
    bertrand.marquis@arm.com, julien@xen.org, michal.orzel@amd.com, 
    roger.pau@citrix.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH] docs/misra: add Rule 16.4
In-Reply-To: <136e4667-8c6d-45ec-b652-b6b690a16f34@suse.com>
Message-ID: 
References:  <136e4667-8c6d-45ec-b652-b6b690a16f34@suse.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Wed, 13 Mar 2024, Jan Beulich wrote:
> On 13.03.2024 01:28, Stefano Stabellini wrote:
> > --- a/docs/misra/rules.rst
> > +++ b/docs/misra/rules.rst
> > @@ -478,6 +478,30 @@ maintainers if you want to suggest a change.
> >       - In addition to break, also other unconditional flow control statements
> >         such as continue, return, goto are allowed.
> >  
> > +   * - `Rule 16.4 `_
> > +     - Required
> > +     - Every switch statement shall have a default label
> > +     - Switch statements with enums as controlling expression don't need
> > +       a default label as gcc -Wall enables -Wswitch which warns (and
> > +       breaks the build)
> 
> I think this could do with mentioning -Werror.

No problem


> > if one of the enum labels is missing from the
> > +       switch.
> > +
> > +       Switch statements with integer types as controlling expression
> > +       should have a default label:
> > +
> > +       - if the switch is expected to handle all possible cases
> > +         explicitly, then a default label shall be added to handle
> > +         unexpected error conditions, using BUG(), ASSERT(), WARN(),
> > +         domain_crash(), or other appropriate methods;
> > +
> > +       - if the switch is expected to handle a subset of all
> > +         possible cases, then a default label shall be added with an
> > +         in-code comment as follows::
> > +
> > +             /* only handle a subset of the possible cases */
> > +             default:
> > +                 break;
> 
> Unless it being made crystal clear that mechanically reproducing this
> comment isn't going to do, I'm going to have a hard time picking
> between actively vetoing or just accepting if someone else acks this.
> At the very least, though, the suggested (or, as requested, example)
> comment should match ./CODING_STYLE. And it may need placing
> differently if I understood correctly what Misra / Eclair demand
> (between default: and break; rather than ahead of both).
> 
> The only place I'd accept a pre-cooked comment is to cover the
> "notifier pattern".

Hi Jan, 

During the MISRA C call we discussed two distinct situations:

1) when the default is not supposed to happen (it could be an BUG_ON)
2) when we only handle a subset of cases on purpose

For 2), it is useful to have a comment to clarify that we are dealing
with 2) instead of 1). It is not a pre-cooked comment. The comment
should be reviewed and checked that it is actually true that for this
specific switch the default is expected and we should do nothing.

However, the comment is indeed pre-cooked in the sense that we don't
need to have several different variations of them to explain why we only
handle a subset of cases.

The majority of people on the call agreed with this (or so I understood).


From xen-devel-bounces@lists.xenproject.org Wed Mar 13 23:06:55 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 23:06:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692814.1080308 (Exim 4.92)
	(envelope-from )
	id 1rkXgS-00080G-Vl; Wed, 13 Mar 2024 23:06:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692814.1080308; Wed, 13 Mar 2024 23:06:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkXgS-000809-SA; Wed, 13 Mar 2024 23:06:52 +0000
Received: by outflank-mailman (input) for mailman id 692814;
 Wed, 13 Mar 2024 23:06:51 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkXgR-000801-03
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 23:06:51 +0000
Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com
 [2a00:1450:4864:20::32f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5f8d0900-e18e-11ee-afdd-a90da7624cb6;
 Thu, 14 Mar 2024 00:06:50 +0100 (CET)
Received: by mail-wm1-x32f.google.com with SMTP id
 5b1f17b1804b1-413ef8f77e1so2189035e9.3
 for ; Wed, 13 Mar 2024 16:06:50 -0700 (PDT)
Received: from [192.168.1.10] (host-92-3-248-192.as13285.net. [92.3.248.192])
 by smtp.gmail.com with ESMTPSA id
 j30-20020a05600c1c1e00b004133825e6cfsm3649265wms.24.2024.03.13.16.06.47
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 13 Mar 2024 16:06:48 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5f8d0900-e18e-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710371208; x=1710976008; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=E026i1YNwPtDgfbtcRd9t2FJoQKmQLatozjbsG664Qo=;
        b=P3KRw+yCnbhGslz+5tIeORLPJjJfF+KrtOqSql8PFgZ57O84n0FC5p9nM860Q9kfI1
         L0AsjUJbhmRqUlzez+sl0AcxExi9mZGdBvkGXRYmGfOk0c75EIAhW8sr8OSThZgLMFxR
         nna9ngLE35IgPQ9LtLhNg7qIP2zGLmXaRmM5g=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710371208; x=1710976008;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=E026i1YNwPtDgfbtcRd9t2FJoQKmQLatozjbsG664Qo=;
        b=fyDySyDLklhY/GYwvzkKJ5YxK0MipAyGuxTWJId+ETcN6vO88ov2WbS13sLiIE6nUv
         0rbQ26wLsipze0pWye/fIlxTyI5FBhIcSMTneR8MR9mg20I5bH7U/9xodddg2VuLVuGt
         pqekMU/MsBG5F8qudSwHzPfwbuWhSWkdYIcNCLy65eM00tMFgq951WQwIFcrc51CvMBA
         JFBEWjHnNI5MaGkYYPRZffYVhf/Xw29MBdLv8UHksLpma2/a79g/QBVtOwZTpRM2iI+b
         0bpdlcX/kCVH2fFeLKkSV9veVLkiZ/TfBoA3DDJIglZeIJlREzbZL7sjwJ0UbnkGlEWX
         fuZQ==
X-Gm-Message-State: AOJu0Yz+vNyJ9TyQneBD753OFP00C8nzCkKwBVDXtfteDLr1MmIlCUif
	P52VBNEZ4/lbuU1DSPdtB0W+vnn3s36IGoEKARAYDjpQyQiclgaNIf+7aBc+fR3GniO09IVaroR
	5
X-Google-Smtp-Source: AGHT+IG2SrORB9mvpQQ13XoPojCmlv6ozokP/mP8VVt5ib5WA/+zFzN9Z3X1O8TriHdAThNkypkwkQ==
X-Received: by 2002:a05:600c:500a:b0:412:d149:254c with SMTP id n10-20020a05600c500a00b00412d149254cmr144443wmr.17.1710371208491;
        Wed, 13 Mar 2024 16:06:48 -0700 (PDT)
Message-ID: <4a190351-1ab2-4a5c-ad5c-6d45095a1595@citrix.com>
Date: Wed, 13 Mar 2024 23:06:47 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/7] xen/bitops: Cleanup ahead of rearrangements
Content-Language: en-GB
To: Xen-devel 
Cc: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Wei Liu ,
 Stefano Stabellini , Julien Grall ,
 Volodymyr Babchuk ,
 Bertrand Marquis ,
 Michal Orzel ,
 Oleksii Kurochko ,
 Shawn Anastasio ,
 "consulting @ bugseng . com" ,
 Simone Ballarin ,
 Federico Serafini ,
 Nicola Vetrini 
References: <20240313172716.2325427-1-andrew.cooper3@citrix.com>
 <20240313172716.2325427-2-andrew.cooper3@citrix.com>
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <20240313172716.2325427-2-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 13/03/2024 5:27 pm, Andrew Cooper wrote:
> diff --git a/xen/common/bitops.c b/xen/common/bitops.c
> new file mode 100644
> index 000000000000..4c07191b4030
> --- /dev/null
> +++ b/xen/common/bitops.c
> @@ -0,0 +1,41 @@
> +#include 
> +#include 
> +#include 
> +
> +/* Hide a value from the optimiser. */
> +#define HIDE(x) ({ typeof(x) _x = x; asm volatile ( "" : "+r" (_x) ); _x; })
> +
> +/*
> + * Check that fn(val) can be calcuated by the compiler, and that it gives the
> + * expected answer.
> + */
> +#define COMPILE_CHECK(fn, val, res)                                     \
> +    do {                                                                \
> +        if ( fn(val) != res )                                           \
> +            asm (".error \"Compile time check '" STR(fn(val) == res) "' failed\""); \
> +    } while ( 0 )

It turns out that Clang doesn't like this

https://gitlab.com/xen-project/people/andyhhp/xen/-/jobs/6387413632

despite it being capable of reducing the expression to a constant.

This also calls into question whether it's a viable replacement for
__bad_bitop_size() et al.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Mar 13 23:23:25 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 23:23:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692819.1080317 (Exim 4.92)
	(envelope-from )
	id 1rkXwM-0003BW-8b; Wed, 13 Mar 2024 23:23:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692819.1080317; Wed, 13 Mar 2024 23:23:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkXwM-0003BP-68; Wed, 13 Mar 2024 23:23:18 +0000
Received: by outflank-mailman (input) for mailman id 692819;
 Wed, 13 Mar 2024 23:23:17 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkXwL-0003BJ-3M
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 23:23:17 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id aa9e1f16-e190-11ee-afdd-a90da7624cb6;
 Thu, 14 Mar 2024 00:23:15 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 3719461445;
 Wed, 13 Mar 2024 23:23:14 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id CDDFCC433C7;
 Wed, 13 Mar 2024 23:23:12 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: aa9e1f16-e190-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1710372193;
	bh=4En7hBriDeUR/3n8aZrHavGdsjdCkKqRaKx13kljPKs=;
	h=Date:From:To:cc:Subject:From;
	b=kZAwOhcIr6/+5pXi0SnGbOk4XHQXZxHTf/ZEjz+ZXjvcfdsjpAsha44OPsZwFFL2F
	 Tnl4dOL3L+kz5c5Fbi+zKyFvHYyssvliWgev9CKhnXjqdTC4yaSqfMPIGlqN0y/OSg
	 5IMNVD6oyuV9zUEAJ626tThaBNToPW++gd5Sy0xl7dGqHF3/i5d09Es6DyRXILfVbr
	 RaOjWx9YJjnluoJvmh8xVCo/+DXJ7yuY/q1hTergPz/vQutfpDlH3abOLQT+YpSLXP
	 DkTzOnswimWCi5QNcipYMf9VdKw4biW5ItzQuqxuLSGwDgS1Z1V9h8WRH7pa276hOt
	 dT6leCSziXgKw==
Date: Wed, 13 Mar 2024 16:23:11 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: xen-devel@lists.xenproject.org
cc: andrew.cooper3@citrix.com, bertrand.marquis@arm.com, 
    george.dunlap@citrix.com, jbeulich@suse.com, julien@xen.org, 
    michal.orzel@amd.com, roger.pau@citrix.com
Subject: [PATCH] docs/misra: document the expected sizes of integer types
Message-ID: 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

Xen makes assumptions about the size of integer types on the various
architectures. Document these assumptions.

Signed-off-by: Stefano Stabellini 
---
 docs/misra/C-language-toolchain.rst | 44 +++++++++++++++++++++++++++++
 1 file changed, 44 insertions(+)

diff --git a/docs/misra/C-language-toolchain.rst b/docs/misra/C-language-toolchain.rst
index b7c2000992..0d3bb2fe6e 100644
--- a/docs/misra/C-language-toolchain.rst
+++ b/docs/misra/C-language-toolchain.rst
@@ -480,4 +480,48 @@ The table columns are as follows:
      - See Section "4.13 Preprocessing Directives" of GCC_MANUAL and Section "11.1 Implementation-defined behavior" of CPP_MANUAL.
 
 
+Sizes of Integer types
+______________________
+
+.. list-table::
+   :widths: 10 10 45
+   :header-rows: 1
+
+   * - Type
+     - Size
+     - Architectures
+
+   * - char 
+     - 8 bits
+     - all architectures
+
+   * - short
+     - 16 bits
+     - all architectures
+
+   * - int
+     - 32 bits
+     - all architectures
+
+   * - long
+     - 32 bits 
+     - 32-bit architectures (x86_32, ARMv8-A AArch32, ARMv8-R AArch32)
+
+   * - long
+     - 64 bits 
+     - 64-bit architectures (x86_64, ARMv8-A AArch64, RV64, PPC64)
+
+   * - long long
+     - 64-bit
+     - all architectures
+
+   * - pointer
+     - 32-bit
+     - 32-bit architectures (x86_32, ARMv8-A AArch32, ARMv8-R AArch32)
+
+   * - pointer
+     - 64-bit
+     - 64-bit architectures (x86_64, ARMv8-A AArch64, RV64, PPC64)
+
+
 END OF DOCUMENT.
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Wed Mar 13 23:40:43 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Mar 2024 23:40:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692822.1080328 (Exim 4.92)
	(envelope-from )
	id 1rkYCx-0006Z2-L8; Wed, 13 Mar 2024 23:40:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692822.1080328; Wed, 13 Mar 2024 23:40:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkYCx-0006Yv-I9; Wed, 13 Mar 2024 23:40:27 +0000
Received: by outflank-mailman (input) for mailman id 692822;
 Wed, 13 Mar 2024 23:40:27 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkYCx-0006Yp-3m
 for xen-devel@lists.xenproject.org; Wed, 13 Mar 2024 23:40:27 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org
 [2604:1380:4641:c500::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1022d0ec-e193-11ee-afdd-a90da7624cb6;
 Thu, 14 Mar 2024 00:40:25 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 2C27761482;
 Wed, 13 Mar 2024 23:40:24 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id B5CF2C433F1;
 Wed, 13 Mar 2024 23:40:22 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1022d0ec-e193-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1710373223;
	bh=q96bMAe7S/BAlgQKBLJAjhHNlcen9mqsMrQiYkkOgag=;
	h=Date:From:To:cc:Subject:From;
	b=Cd9wDUIglPrOlKaClWetp0N75JJhRBL9KK0+MfianwesmS9Wt8901aYY+O2sgNpuH
	 XLWuUWar+GbFyq6NHF0nyDFd1xT9P1M/K+Zbs5eC5Hmv4x2TLnOpqtYYvcjZ8N/uyv
	 zOOuTQnavqLsTLzcOBnjuOCt6uVhIaWWB0xhjcM9+p1PjBwVWD7SisoXcy0TXC9bNQ
	 y0hsAe0CHl1Ms9JW5NQQ9yOSDALd37Ht+AZ0LB8VdUzT1aKRmj/ivvOEJOo4gvISLq
	 koPeGawAPmofQjly4O+pA6xzM+YoT/i5qKs6C9+09EiDH08iWKk2yKPNbGxC0036Uw
	 OYM+74DJxqUyg==
Date: Wed, 13 Mar 2024 16:40:20 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: xen-devel@lists.xenproject.org
cc: andrew.cooper3@citrix.com, bertrand.marquis@arm.com, 
    george.dunlap@citrix.com, jbeulich@suse.com, julien@xen.org, 
    michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org
Subject: [PATCH] MAINTAINERS: make Roger an IOMMU Maintainer
Message-ID: 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-340617375-1710373223=:853156"

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-340617375-1710373223=:853156
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

Roger kindly volunteered to step up as IOMMU Maintainer.

Signed-off-by: Stefano Stabellini 
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 56a6932037..ad385abd2d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -359,7 +359,7 @@ F:	xen/drivers/passthrough/vtd/
 IOMMU VENDOR INDEPENDENT CODE
 M:	Jan Beulich 
 M:	Paul Durrant 
-R:	Roger Pau Monné 
+M:	Roger Pau Monné 
 S:	Supported
 F:	xen/drivers/passthrough/
 X:	xen/drivers/passthrough/amd/
-- 
2.25.1

--8323329-340617375-1710373223=:853156--


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 00:05:58 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 00:05:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692826.1080338 (Exim 4.92)
	(envelope-from )
	id 1rkYbY-0002Jt-Nr; Thu, 14 Mar 2024 00:05:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692826.1080338; Thu, 14 Mar 2024 00:05:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkYbY-0002Jm-KL; Thu, 14 Mar 2024 00:05:52 +0000
Received: by outflank-mailman (input) for mailman id 692826;
 Thu, 14 Mar 2024 00:05:50 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkYbW-0002Jc-Tz; Thu, 14 Mar 2024 00:05:50 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkYbV-0002mV-T3; Thu, 14 Mar 2024 00:05:49 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkYbV-0008Qw-LL; Thu, 14 Mar 2024 00:05:49 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rkYbV-0006Ik-I2; Thu, 14 Mar 2024 00:05:49 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=FgAx480XPVCa3ob7n4ozVFskVa+Ibi3B8aVei6+HVGw=; b=mm79EXtlcO1if1gYKLXGi7IHs5
	Y7tKiciA7/6lzqAq6Tfxin/CNd81+KfRXZ9Wo6aqwy/k602n21vLMSJn+BMC2/HTJChwNlJIwDevd
	o4MZlHQ2sAp9tXLVFT8FeERflhG4dIF6xR0dDyUp385QW5dyj2MzTmelQ09gmonHRaCI=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 185016: regressions - FAIL
X-Osstest-Failures:
    linux-linus:test-armhf-armhf-libvirt-raw:xen-boot:fail:regression
    linux-linus:build-arm64-pvops:kernel-build:fail:regression
    linux-linus:test-arm64-arm64-examine:build-check(1):blocked:nonblocking
    linux-linus:test-arm64-arm64-libvirt-raw:build-check(1):blocked:nonblocking
    linux-linus:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking
    linux-linus:test-arm64-arm64-xl:build-check(1):blocked:nonblocking
    linux-linus:test-arm64-arm64-xl-credit1:build-check(1):blocked:nonblocking
    linux-linus:test-arm64-arm64-xl-credit2:build-check(1):blocked:nonblocking
    linux-linus:test-arm64-arm64-xl-thunderx:build-check(1):blocked:nonblocking
    linux-linus:test-arm64-arm64-xl-vhd:build-check(1):blocked:nonblocking
    linux-linus:test-arm64-arm64-xl-xsm:build-check(1):blocked:nonblocking
    linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    linux=b0546776ad3f332e215cebc0b063ba4351971cca
X-Osstest-Versions-That:
    linux=855684c7d938c2442f07eabc154e7532b4c1fbf9
From: osstest service owner 
Date: Thu, 14 Mar 2024 00:05:49 +0000

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-raw  8 xen-boot                 fail REGR. vs. 185004
 build-arm64-pvops             6 kernel-build             fail REGR. vs. 185004

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-examine      1 build-check(1)               blocked  n/a
 test-arm64-arm64-libvirt-raw  1 build-check(1)               blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)               blocked  n/a
 test-arm64-arm64-xl           1 build-check(1)               blocked  n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)               blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)               blocked  n/a
 test-arm64-arm64-xl-thunderx  1 build-check(1)               blocked  n/a
 test-arm64-arm64-xl-vhd       1 build-check(1)               blocked  n/a
 test-arm64-arm64-xl-xsm       1 build-check(1)               blocked  n/a
 test-armhf-armhf-libvirt     16 saverestore-support-check    fail  like 185004
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop            fail like 185004
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop            fail like 185004
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop            fail like 185004
 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check   fail like 185004
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop            fail like 185004
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 185004
 test-amd64-amd64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-multivcpu 15 migrate-support-check        fail  never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit1  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          16 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     15 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-qcow2 14 migrate-support-check        fail never pass
 test-amd64-amd64-libvirt-raw 14 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     15 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-qcow2 14 migrate-support-check        fail never pass
 test-armhf-armhf-xl-vhd      14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      15 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  16 saverestore-support-check    fail   never pass

version targeted for testing:
 linux                b0546776ad3f332e215cebc0b063ba4351971cca
baseline version:
 linux                855684c7d938c2442f07eabc154e7532b4c1fbf9

Last test of basis   185004  2024-03-12 13:44:04 Z    1 days
Testing same since   185016  2024-03-13 04:24:26 Z    0 days    1 attempts

------------------------------------------------------------
863 people touched revisions under test,
not listing them all

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            fail    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          blocked 
 test-armhf-armhf-xl                                          pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 blocked 
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      blocked 
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-freebsd11-amd64                             pass    
 test-amd64-amd64-freebsd12-amd64                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  blocked 
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  blocked 
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     blocked 
 test-armhf-armhf-examine                                     pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-libvirt-qcow2                               pass    
 test-armhf-armhf-libvirt-qcow2                               pass    
 test-amd64-amd64-libvirt-raw                                 pass    
 test-arm64-arm64-libvirt-raw                                 blocked 
 test-armhf-armhf-libvirt-raw                                 fail    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-arm64-arm64-xl-thunderx                                 blocked 
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-amd64-xl-vhd                                      pass    
 test-arm64-arm64-xl-vhd                                      blocked 
 test-armhf-armhf-xl-vhd                                      pass    


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

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

Explanation of these 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 87639 lines long.)


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 01:07:47 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 01:07:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692836.1080357 (Exim 4.92)
	(envelope-from )
	id 1rkZZE-0000zf-EM; Thu, 14 Mar 2024 01:07:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692836.1080357; Thu, 14 Mar 2024 01:07:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkZZE-0000zY-A3; Thu, 14 Mar 2024 01:07:32 +0000
Received: by outflank-mailman (input) for mailman id 692836;
 Thu, 14 Mar 2024 01:07:31 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkZZD-0000zO-2P; Thu, 14 Mar 2024 01:07:31 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkZZC-0002AV-Tm; Thu, 14 Mar 2024 01:07:30 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkZZC-0004VB-CX; Thu, 14 Mar 2024 01:07:30 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rkZZC-00037m-AR; Thu, 14 Mar 2024 01:07:30 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=70fNy/MtYVrQ3e174r10hKYG5goH/dVLvILLea00kjE=; b=1MvtPDNGDRssib15DDEyXV88Zc
	zzRX0Lg0OXK7VxFpPFgpgH3d/LQKlnpIoKPPYHBgq/CJF2PdEsBDM/KKLW0ruXSXUbJFUiKdCpxLe
	ss1G36EzDnslGbN3IB6+JbhJWoJK7h7eXjGqbOq67EEeuT6tGkTySZ6JepYe1XQgRQIo=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-4.17-testing test] 185012: tolerable FAIL - PUSHED
X-Osstest-Failures:
    xen-4.17-testing:test-amd64-amd64-xl-qemut-debianhvm-i386-xsm:debian-hvm-install:fail:heisenbug
    xen-4.17-testing:test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow:guest-localmigrate/x10:fail:heisenbug
    xen-4.17-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    xen-4.17-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    xen-4.17-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    xen-4.17-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    xen-4.17-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    xen-4.17-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    xen-4.17-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    xen-4.17-testing:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
    xen-4.17-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-amd64-i386-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    xen=0ebd2e49bcd0f566ba6b9158555942aab8e41332
X-Osstest-Versions-That:
    xen=1f94117bec55a7b934fed3dfd3529db624eb441f
From: osstest service owner 
Date: Thu, 14 Mar 2024 01:07:30 +0000

flight 185012 xen-4.17-testing real [real]
flight 185022 xen-4.17-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/185012/
http://logs.test-lab.xenproject.org/osstest/logs/185022/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail pass in 185022-retest
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 18 guest-localmigrate/x10 fail pass in 185022-retest

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

version targeted for testing:
 xen                  0ebd2e49bcd0f566ba6b9158555942aab8e41332
baseline version:
 xen                  1f94117bec55a7b934fed3dfd3529db624eb441f

Last test of basis   185002  2024-03-12 11:40:22 Z    1 days
Testing same since   185012  2024-03-13 00:10:35 Z    1 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Roger Pau Monné 

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 fail    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-armhf-armhf-libvirt-qcow2                               pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-libvirt-raw                                  pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             fail    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-arm64-arm64-xl-vhd                                      pass    
 test-armhf-armhf-xl-vhd                                      pass    
 test-amd64-i386-xl-vhd                                       pass    


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

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

Explanation of these 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
   1f94117bec..0ebd2e49bc  0ebd2e49bcd0f566ba6b9158555942aab8e41332 -> stable-4.17


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 05:46:19 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 05:46:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692863.1080442 (Exim 4.92)
	(envelope-from )
	id 1rkduj-0007gB-Jh; Thu, 14 Mar 2024 05:46:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692863.1080442; Thu, 14 Mar 2024 05:46:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkduj-0007g4-Gp; Thu, 14 Mar 2024 05:46:01 +0000
Received: by outflank-mailman (input) for mailman id 692863;
 Thu, 14 Mar 2024 05:46:00 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkdui-0007fu-Rv; Thu, 14 Mar 2024 05:46:00 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkdui-0007s0-QT; Thu, 14 Mar 2024 05:46:00 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkdui-0001gb-Eq; Thu, 14 Mar 2024 05:46:00 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rkdui-0008Nm-EN; Thu, 14 Mar 2024 05:46:00 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=eE1pRraxiM/Dhc1jr2OpJCB9rRfqaqbtH51DtgIR7AE=; b=AOfjNA/TdYbkTu6a5l2sdCTAgs
	ZyrXAkF99jLdCbAMNNGMkLYe01IeD6+jsBLC+Mo4IIUJVvc3Nhog3CbDK/AU66tH0AgilkcxQtkqf
	Ch5lfBhPxO+LieylTXodSWMR2TTxJjnVk03RtoEry6NuCHgOmI5tPBfQ7//XqkKKbNuE=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 185025: tolerable all pass - PUSHED
X-Osstest-Failures:
    xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    xen=4dc9a8b0606770dc9c6be20ff5a74a9af5fcba70
X-Osstest-Versions-That:
    xen=03cf7ca23e0e876075954c558485b267b7d02406
From: osstest service owner 
Date: Thu, 14 Mar 2024 05:46:00 +0000

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          16 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  4dc9a8b0606770dc9c6be20ff5a74a9af5fcba70
baseline version:
 xen                  03cf7ca23e0e876075954c558485b267b7d02406

Last test of basis   185009  2024-03-12 18:00:27 Z    1 days
Testing same since   185025  2024-03-14 01:00:28 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Nicola Vetrini 

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-amd64                    pass    
 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
   03cf7ca23e..4dc9a8b060  4dc9a8b0606770dc9c6be20ff5a74a9af5fcba70 -> smoke


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 06:14:37 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 06:14:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692869.1080452 (Exim 4.92)
	(envelope-from )
	id 1rkeMJ-0002wn-Rg; Thu, 14 Mar 2024 06:14:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692869.1080452; Thu, 14 Mar 2024 06:14:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkeMJ-0002wg-P2; Thu, 14 Mar 2024 06:14:31 +0000
Received: by outflank-mailman (input) for mailman id 692869;
 Thu, 14 Mar 2024 06:14:31 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkeMJ-0002wW-8e; Thu, 14 Mar 2024 06:14:31 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkeMJ-0008QY-3R; Thu, 14 Mar 2024 06:14:31 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkeMI-00030E-Oh; Thu, 14 Mar 2024 06:14:30 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rkeMI-0001rc-OE; Thu, 14 Mar 2024 06:14:30 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=R3YiralVGyVLbm/c5tjkqn0RwpJOSy6DwK46HNW59bM=; b=FQ+x5Ncafba5K7Mc2OHoS4V9HO
	019eJChvQhJXlqGvZCILIKO7DyANI9y493QaNi/+Jt+P1FTmj1Qe57d23Wa42YHgRJZLkb+z5BRlr
	3LIrFnYns5ZYRUXOY6h5mZmzPl79p64pGjPHnyUy3bl5mOPas3bRj3b2RQOxeiIkwk5I=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 185019: tolerable FAIL
X-Osstest-Failures:
    xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-i386-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking
X-Osstest-Versions-This:
    xen=03cf7ca23e0e876075954c558485b267b7d02406
X-Osstest-Versions-That:
    xen=03cf7ca23e0e876075954c558485b267b7d02406
From: osstest service owner 
Date: Thu, 14 Mar 2024 06:14:30 +0000

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop      fail blocked in 185010
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop            fail like 185010
 test-armhf-armhf-libvirt     16 saverestore-support-check    fail  like 185010
 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop             fail like 185010
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop            fail like 185010
 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop             fail like 185010
 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop             fail like 185010
 test-armhf-armhf-libvirt-raw 15 saverestore-support-check    fail  like 185010
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop            fail like 185010
 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check   fail like 185010
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 185010
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop             fail like 185010
 test-amd64-amd64-libvirt     15 migrate-support-check        fail   never pass
 test-amd64-i386-xl-pvshim    14 guest-start                  fail   never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  15 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  16 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      16 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass
 test-armhf-armhf-xl-multivcpu 15 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-rtds     15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-rtds     16 saverestore-support-check    fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass
 test-armhf-armhf-xl-arndale  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     15 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-raw  14 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-raw 14 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-raw 15 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-vhd      14 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-vhd      15 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-vhd      14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      15 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-raw 14 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          16 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-qcow2 14 migrate-support-check        fail never pass

version targeted for testing:
 xen                  03cf7ca23e0e876075954c558485b267b7d02406
baseline version:
 xen                  03cf7ca23e0e876075954c558485b267b7d02406

Last test of basis   185019  2024-03-13 18:46:04 Z    0 days
Testing same since                          (not found)         0 attempts

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-i386-examine-bios                                 pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-armhf-armhf-libvirt-qcow2                               pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-libvirt-raw                                  pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-i386-examine-uefi                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-arm64-arm64-xl-vhd                                      pass    
 test-armhf-armhf-xl-vhd                                      pass    
 test-amd64-i386-xl-vhd                                       pass    


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

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

Explanation of these 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


Published tested tree is already up to date.



From xen-devel-bounces@lists.xenproject.org Thu Mar 14 06:56:40 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 06:56:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692876.1080465 (Exim 4.92)
	(envelope-from )
	id 1rkf0s-0007jH-4Q; Thu, 14 Mar 2024 06:56:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692876.1080465; Thu, 14 Mar 2024 06:56:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkf0s-0007jA-19; Thu, 14 Mar 2024 06:56:26 +0000
Received: by outflank-mailman (input) for mailman id 692876;
 Thu, 14 Mar 2024 06:56:25 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkf0r-0007j1-0Y
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 06:56:25 +0000
Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com
 [2a00:1450:4864:20::12f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f71f0708-e1cf-11ee-a1ee-f123f15fe8a2;
 Thu, 14 Mar 2024 07:56:21 +0100 (CET)
Received: by mail-lf1-x12f.google.com with SMTP id
 2adb3069b0e04-513c8b72b24so761794e87.3
 for ; Wed, 13 Mar 2024 23:56:21 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 i26-20020a17090671da00b00a46231722ffsm393340ejk.26.2024.03.13.23.56.20
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 13 Mar 2024 23:56:20 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f71f0708-e1cf-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710399381; x=1711004181; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=4bsRFjvEs9d2X4RMP01V0aWA4NbOMHn0nWSvnkSs0c4=;
        b=gnbUvIBM2lbZWDFJGCHwReS+q8JvAaybt52o5k/J3P0Q32SfrUZmlwE9aK23QYtnk4
         ioMKIlMHgJ9tMKwexA+7nyC5l1W/1PEEpU6namPowv+aPMT8bRdJE2LnMxgXCwR41EjF
         rM67IGrSaIiaU1ZSkYRrcw1T3wwPSmvcQo3fsT81YZe89+fkWqEsTECioxZw4ZgPQzye
         iKHvE+TXUf1knjshH5uV/+97NDOTUOAYy4cB0FGjD877yz52o2zvkYLZq/C3drjHB3yp
         KP1IGhpb9jVw3hHgWlek5AFQB5LVLJ2z7SQfB93w3G+X+sL2cS0kClv4KOatxJk25MU8
         5/Mg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710399381; x=1711004181;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=4bsRFjvEs9d2X4RMP01V0aWA4NbOMHn0nWSvnkSs0c4=;
        b=D8JZ1YetGTKzpi3GHMmw5ot+4JqRRUE6nSxFUgMINfmjT2iHWYrhKpWRHgXzBY11JN
         HX0qi6WAJrTohD6RoZc/bRL0F1466t7G83ai9pMxHa/mDjucrmHApc2M0m9moK2lkBwW
         hcu1JIAJKCm86kwdZf0JyOCLfHNZvNNn/t45SUSEut5Cc0yHRMV5w6lEtEmsyRVfLRHb
         UM1rj8/+/nTIGbLLWbVIW+cICkJVTGT3CTumUjXHNLTFmxJde8op73jzij/Ag9GbUl7V
         4B/9Erhrmg1TS/woLUa+pcct8W9Gto7u5jSfmceFaagL+udjdwz+HSEEGaM50fFhsDnn
         Ogug==
X-Forwarded-Encrypted: i=1; AJvYcCW7P8aTisOFIchYB4Zng6mVCU8kDMkSyx8PXz2XjcagAeX5ulZ3whbhOrMgSJ1O2SIqidf8Y9y8A8UcwznW/O+h9fJ3JbUHuXU7yhzQ4lk=
X-Gm-Message-State: AOJu0YwygoTfAAez4LeYnOIPMrfttgUzvOW3ojpg22GHYSx83zhk0QyY
	dTc/pj2L/UzNTVpMuUOYcOiSDNYMJjQMIIABdQ0ZkwOfXCwRLV0R7OyAylpwYA==
X-Google-Smtp-Source: AGHT+IGgHPeJlmnkLd9D6K+sgH0kd6RJ4KwJ6Pa0Bf4BUEL4LzxqyR31kpGaPDfbL0OHsX7EThy/ag==
X-Received: by 2002:a19:2d55:0:b0:512:ab58:3807 with SMTP id t21-20020a192d55000000b00512ab583807mr533489lft.9.1710399381036;
        Wed, 13 Mar 2024 23:56:21 -0700 (PDT)
Message-ID: 
Date: Thu, 14 Mar 2024 07:56:19 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] docs/misra: add Rule 16.4
Content-Language: en-US
To: Stefano Stabellini 
Cc: andrew.cooper3@citrix.com, bertrand.marquis@arm.com, julien@xen.org,
 michal.orzel@amd.com, roger.pau@citrix.com, xen-devel@lists.xenproject.org
References: 
 <136e4667-8c6d-45ec-b652-b6b690a16f34@suse.com>
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 14.03.2024 00:04, Stefano Stabellini wrote:
> On Wed, 13 Mar 2024, Jan Beulich wrote:
>> On 13.03.2024 01:28, Stefano Stabellini wrote:
>>> +       Switch statements with integer types as controlling expression
>>> +       should have a default label:
>>> +
>>> +       - if the switch is expected to handle all possible cases
>>> +         explicitly, then a default label shall be added to handle
>>> +         unexpected error conditions, using BUG(), ASSERT(), WARN(),
>>> +         domain_crash(), or other appropriate methods;
>>> +
>>> +       - if the switch is expected to handle a subset of all
>>> +         possible cases, then a default label shall be added with an
>>> +         in-code comment as follows::
>>> +
>>> +             /* only handle a subset of the possible cases */
>>> +             default:
>>> +                 break;
>>
>> Unless it being made crystal clear that mechanically reproducing this
>> comment isn't going to do, I'm going to have a hard time picking
>> between actively vetoing or just accepting if someone else acks this.
>> At the very least, though, the suggested (or, as requested, example)
>> comment should match ./CODING_STYLE. And it may need placing
>> differently if I understood correctly what Misra / Eclair demand
>> (between default: and break; rather than ahead of both).
>>
>> The only place I'd accept a pre-cooked comment is to cover the
>> "notifier pattern".
> 
> Hi Jan, 
> 
> During the MISRA C call we discussed two distinct situations:
> 
> 1) when the default is not supposed to happen (it could be an BUG_ON)
> 2) when we only handle a subset of cases on purpose
> 
> For 2), it is useful to have a comment to clarify that we are dealing
> with 2) instead of 1). It is not a pre-cooked comment. The comment
> should be reviewed and checked that it is actually true that for this
> specific switch the default is expected and we should do nothing.
> 
> However, the comment is indeed pre-cooked in the sense that we don't
> need to have several different variations of them to explain why we only
> handle a subset of cases.
> 
> The majority of people on the call agreed with this (or so I understood).

Hmm, my -0.5 was on the understanding that we would not encourage entirely
mechanical adding of such comments. Yet providing a pre-worded comment
here does exactly this, in my opinion. Imo here it should be made clear
_where_ the comment needs to be put, but not how it is to be worded. As
was (largely) settled on during the discussion, the comment doesn't need
to go into a great level of detail.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 06:59:47 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 06:59:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692879.1080478 (Exim 4.92)
	(envelope-from )
	id 1rkf46-0008Nm-IU; Thu, 14 Mar 2024 06:59:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692879.1080478; Thu, 14 Mar 2024 06:59:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkf46-0008Nf-FX; Thu, 14 Mar 2024 06:59:46 +0000
Received: by outflank-mailman (input) for mailman id 692879;
 Thu, 14 Mar 2024 06:59:45 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkf45-0008NT-IW
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 06:59:45 +0000
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com
 [2a00:1450:4864:20::62d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 70238bc3-e1d0-11ee-afdd-a90da7624cb6;
 Thu, 14 Mar 2024 07:59:44 +0100 (CET)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-a466f6318e9so43556166b.0
 for ; Wed, 13 Mar 2024 23:59:44 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 rf22-20020a1709076a1600b00a450b817705sm390590ejc.154.2024.03.13.23.59.43
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 13 Mar 2024 23:59:43 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 70238bc3-e1d0-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710399584; x=1711004384; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=VV5YwNgoCT/B7J5r+Pq5V4OoUWpPdECRCv+fqrqNjto=;
        b=EGZkwMAbI200dG1sHuEeuOH2FqrK6S31jorJ9Kd9bYZyZOoTBLbKYtvk6s7SX6e4r9
         B8PT1WL+90Ajbuhn7v1rGPCuYFFTM19hSXJtTy77kBUU+yNu9NreHq05SQhSsK8btk6W
         MxLArVRvM5UT3fOGgstKMW9AAm6vUe7cfPVc0PqtKMqLspDVw1r7P+/xopRWYi8jR/ov
         gIAT5p6EhFCWD7u+KebomJLEVgrxH8/i5Fjwn3e0ndEGapDD1RIKVFuwSJRhJkPAZiDk
         ZXPBVuFrC23PYmNSRN/cybeILLggntY0XvMNBtYhj7DtccEDGHqjZnclx5xBNZlNJCFc
         WHdQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710399584; x=1711004384;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=VV5YwNgoCT/B7J5r+Pq5V4OoUWpPdECRCv+fqrqNjto=;
        b=CX9f8jPUoAAPKp+/oFvg4cqRxhL39SOgyPnw/rCSb3nO/qHS96kSxGFi+Z/mzPkLX0
         A2IMbAJ8y/W/dfk5ZvDoZwBAG+UlTYL+0c7psLdlpFponKkGdFPr1EPFh7kC2Z9nO9dk
         XtN8VQoKaopyQhITWg4biUSw17x22r4Nllg9tzCBcJKlEzAydZudo1z5ASF949Pl3VEP
         KA17o7RKXQ131lhprpd0SSxtNCxIhQFM4DO2xZblWIYpBb8Q3hmhWH2RwhzL5HXd+/13
         brJ3zavGyT5xNmrH304vixMI38w4CaKCekCB8ZnTpCQKAy/DQCsTFCReFHb0u0XeUINa
         f1Tg==
X-Gm-Message-State: AOJu0YwoV2yvJoW9MPxSEroqqqW1IZMJDh3UQgF6p5X0ZxvuMSI0OF42
	96rKy4aWqiiiboJYtipedJsIQCyUHjyi3m7TslnJl5rSoqzdIoTMWex0mUesmg==
X-Google-Smtp-Source: AGHT+IFQYCByxxlLskiIeN9Te63LVh6xABQ83MgYO96JNYY5akMaw0NUd8KfDL+uA2/NCw/5M1YJlw==
X-Received: by 2002:a17:906:24d6:b0:a46:58ac:8b55 with SMTP id f22-20020a17090624d600b00a4658ac8b55mr544904ejb.15.1710399584175;
        Wed, 13 Mar 2024 23:59:44 -0700 (PDT)
Message-ID: <40fd93be-f626-43d5-b239-6976665efe30@suse.com>
Date: Thu, 14 Mar 2024 07:59:42 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4] x86/PoD: tie together P2M update and increment of
 entry count
Content-Language: en-US
To: George Dunlap 
Cc: "xen-devel@lists.xenproject.org" ,
 Andrew Cooper , Wei Liu ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: 
 <3daef84c-47dd-4a6b-9984-402e997598dc@suse.com>
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 13.03.2024 17:31, George Dunlap wrote:
> On Wed, Mar 13, 2024 at 2:00 PM Jan Beulich  wrote:
>>
>> When not holding the PoD lock across the entire region covering P2M
>> update and stats update, the entry count - if to be incorrect at all -
>> should indicate too large a value in preference to a too small one, to
>> avoid functions bailing early when they find the count is zero. However,
>> instead of moving the increment ahead (and adjust back upon failure),
>> extend the PoD-locked region.
>>
>> Fixes: 99af3cd40b6e ("x86/mm: Rework locking in the PoD layer")
>> Signed-off-by: Jan Beulich 
> 
> Would you mind commenting on why you went with multiple unlocks,
> rather than multiple if statements?

Simply because what I did I view as more logical a code structure
than ...

> e.g.,
> 
> ```
> rc = p2m_set_entry(...);
> 
> /* Do the pod entry adjustment while holding the lock on success */
> if ( rc == 0 ) {
>  /* adjust pod entries */
> }
> 
> pod_unlock(p2m);
> 
> /* Do the rest of the clean-up and error handling */
> if (rc == 0 ) {

... this, ...

> Just right now the multiple unlocks makes me worry that we may forget
> one at some point.

... despite this possible concern. But well, if going the other route
is what it takes to finally get this in, so be it.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 07:06:36 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 07:06:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692883.1080488 (Exim 4.92)
	(envelope-from )
	id 1rkfAe-0001Tu-7W; Thu, 14 Mar 2024 07:06:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692883.1080488; Thu, 14 Mar 2024 07:06:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkfAe-0001Tn-4l; Thu, 14 Mar 2024 07:06:32 +0000
Received: by outflank-mailman (input) for mailman id 692883;
 Thu, 14 Mar 2024 07:06:31 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkfAd-0001Th-1x
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 07:06:31 +0000
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com
 [2a00:1450:4864:20::535])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 610f8199-e1d1-11ee-a1ee-f123f15fe8a2;
 Thu, 14 Mar 2024 08:06:28 +0100 (CET)
Received: by mail-ed1-x535.google.com with SMTP id
 4fb4d7f45d1cf-5684073ab38so1135902a12.0
 for ; Thu, 14 Mar 2024 00:06:28 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 eg22-20020a056402289600b005682fbc2531sm397893edb.74.2024.03.14.00.06.27
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 14 Mar 2024 00:06:28 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 610f8199-e1d1-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710399988; x=1711004788; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=9P1OYHEIZ00D70YK/MTK2q4gEfIL8FZO5C4MTZJrik8=;
        b=G+62XjKhkQztUfDwBDwhJhAp0+lvujsfvAQtggRhGuA1JNfOwre+0itBZsWIZLVXn0
         LRx25dMCuDT8J5yecai2HJ/ViVD2t+n0jRBDRwcEePfXiL2v/Dpe0C72fJByQhNJuVmj
         Cv0Ovah/Sdm1Qb7AEpGF/RIFnYt/aiu2kU3gckLZsYSWs9cu00+ryyjEneY9fd6IKqHn
         fwugXnbWn3uZmt7sS2keik2OX2PeUsEtH/IY2F7x/90A+ib7gSqTTQpRol6LikEzyfcd
         TxOEZ5SJQxZYdGZxDe6m7AvsMdcuOejK6VriwEdrvO0aB4rVQydft87RNgcdyhcB4VyD
         4fZw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710399988; x=1711004788;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=9P1OYHEIZ00D70YK/MTK2q4gEfIL8FZO5C4MTZJrik8=;
        b=vRd4vO4430MS4hkqdIpDsOcr/TwQyQfxbUIacUENtctn4bl5WcoE9Jt+EyVwxr4Zz9
         aS8OnymKdI1tLXPHr2aqTQ/nshsrI7L6nC4KbSc+cpA0SbL8uc40evgQcmo3gEnETNeq
         zx3fbfKngMW/j4in83/EAZzsX9BjkMOEFQgreX17XfEEvDBa8pMlc6T+wmjoTFjEVT2T
         JJgKEY3OtEQ5x/zThAATseqy4P8OTrcKR8ayZaK1MZkt/F6qqvDqojJ1e5nYpblRbsmg
         gRUrPCcOMB7PTlTn2B8iI7C4l0SHF3tvbgQy82VA7wzCQlTJfPwGezeksu7HgwNZwtzr
         XxNg==
X-Forwarded-Encrypted: i=1; AJvYcCWmu3rB68HPK+VSI5Pvw0cKep4lggj/YNhMKniRBIeMLqleSJLF4q85UOWF6UOzyCOSZQYIH+P3scFD7eGRhfYJww6JNXOEUURtdp35Yf8=
X-Gm-Message-State: AOJu0Yy96w+CJ5FA0oDg4Tu2AjY92ceKNWKchMzXvN9cdA8QU37gArem
	rQf8vHg3c1ZReJESzWmAj/AOMv0Bmd9rmM7LG88Ni1EJewEqpPUTpc5WblEC1w==
X-Google-Smtp-Source: AGHT+IEWtqa7IXxXxoU6Zayu+tLvIcUZ3CgKocmrCpSSW8tvucasIBcihFSI04JmZ5fAkeollUsyow==
X-Received: by 2002:a05:6402:1f14:b0:567:1263:e31f with SMTP id b20-20020a0564021f1400b005671263e31fmr1183986edb.10.1710399988467;
        Thu, 14 Mar 2024 00:06:28 -0700 (PDT)
Message-ID: <97516382-b756-48da-a358-6b093c4cb20f@suse.com>
Date: Thu, 14 Mar 2024 08:06:27 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] MAINTAINERS: make Roger an IOMMU Maintainer
Content-Language: en-US
To: Stefano Stabellini 
Cc: andrew.cooper3@citrix.com, bertrand.marquis@arm.com,
 george.dunlap@citrix.com, julien@xen.org, michal.orzel@amd.com,
 roger.pau@citrix.com, xen-devel@lists.xenproject.org
References: 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 14.03.2024 00:40, Stefano Stabellini wrote:
> Roger kindly volunteered to step up as IOMMU Maintainer.
> 
> Signed-off-by: Stefano Stabellini 

Acked-by: Jan Beulich 




From xen-devel-bounces@lists.xenproject.org Thu Mar 14 07:11:16 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 07:11:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692885.1080499 (Exim 4.92)
	(envelope-from )
	id 1rkfFC-0003Bp-PD; Thu, 14 Mar 2024 07:11:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692885.1080499; Thu, 14 Mar 2024 07:11:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkfFC-0003Bi-La; Thu, 14 Mar 2024 07:11:14 +0000
Received: by outflank-mailman (input) for mailman id 692885;
 Thu, 14 Mar 2024 07:11:12 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkfFA-0003BH-SL
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 07:11:12 +0000
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com
 [2a00:1450:4864:20::635])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 09889e8c-e1d2-11ee-afdd-a90da7624cb6;
 Thu, 14 Mar 2024 08:11:11 +0100 (CET)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-a4644bde1d4so72571066b.3
 for ; Thu, 14 Mar 2024 00:11:11 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a11-20020a170906190b00b00a44e2f3024bsm407573eje.68.2024.03.14.00.11.10
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 14 Mar 2024 00:11:10 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 09889e8c-e1d2-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710400271; x=1711005071; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=SDY4jjLhZUBmy0omOEEqP4FrI3d4/utzdwwQ/ZpA04M=;
        b=TPc0ygq3tWNuC326HPrMf004Xysuv4WZ+18mWXBpcDRlRYR96LEZwUQh3O9NQORV8h
         VCFKZrOIF93kZTEIzKlgBJXrfW9Ev3oA8b+fIN8yjoYEuAC6io5sRnFDcTTdiE/rbLNR
         gcnkv/p987X9QJVEwwRXiCdV6JWJTxL4c1pGpGI4/4tlN1F/dJG0y03YeSzjmGGTnq0z
         +27ZFJKf4t3ii/0lpBovLTj7HCs7D46+bYb48iJv6c2D1lBK7DB8fcjvRg/WY+ST9lWA
         eG4a34j7bLvUih8LfNhBBbkHMoifQelnJJwL/Jh80KVciXIohvETuvASLdXJE6vA5nmG
         i1SA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710400271; x=1711005071;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=SDY4jjLhZUBmy0omOEEqP4FrI3d4/utzdwwQ/ZpA04M=;
        b=J671szI0O0OuSKIioSUa5qE2OWLuQ6sfeAjh68N84qC8nIIkunaspY/dXXDX6OkQ2z
         BApdHnJVNE24zlH9XTS0OAvu/nMK4sQle65/bd2pPffOGrYosz3Q8i8f0go1mKCiSNze
         mPsdWWo/tX5O43AI9sSaqDnBGUW6gfqTFeSpC8JomFsfaF8tH1n1fMWj4CHhx6M1amxg
         eDST1Tb6c3cdlslDQZR04Ot/oTOp//ij51dz02MZVMEGTm7Q+9mkdJh1dQaESsrDmXtO
         HJgKVXM7JdPheQEKC84ECqG2beVTs5LAxVkv3nHvUbmSBFlg+DMZDyk7NVWiWp2+ZVZ9
         JijA==
X-Forwarded-Encrypted: i=1; AJvYcCUBt4pyOrH9rxyE3+fVQIFlmBHzRnco7RHVsmCY0LAp2yxY01DO+15bDhEjxngkILRNj50Eu93WpGgteG7h/nqZ0o3xUfwRyhKDwA1jfkk=
X-Gm-Message-State: AOJu0YyAtNrEUkWOu5X7rD+N9BWJKe0WQwwmiPHi3E/FpNwrLZ/0Oada
	uWZ1ufaXWuRQVtUx/ti33k0ExG8sqrVdseVModXtdbacTYjLRPNpUATCLu3pkA==
X-Google-Smtp-Source: AGHT+IE39Fz82EN2jBhgle/gy6FAsWss++CefBwacU6aIw//7hMZpmN58GHMQbkeidRy0ALmgFnttQ==
X-Received: by 2002:a17:907:c082:b0:a46:74f0:6380 with SMTP id st2-20020a170907c08200b00a4674f06380mr292932ejc.3.1710400271021;
        Thu, 14 Mar 2024 00:11:11 -0700 (PDT)
Message-ID: <82ae53ac-f2d1-4d86-8719-4e5cc2e5f57d@suse.com>
Date: Thu, 14 Mar 2024 08:11:09 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/3] Revert "xen/x86: bzImage parse kernel_alignment"
Content-Language: en-US
To: Jason Andryuk 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org, Wei Liu 
References: <20240313193021.241764-1-jason.andryuk@amd.com>
 <20240313193021.241764-2-jason.andryuk@amd.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240313193021.241764-2-jason.andryuk@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 13.03.2024 20:30, Jason Andryuk wrote:
> A new ELF note will specify the alignment for a relocatable PVH kernel.
> ELF notes are suitable for vmlinux and other ELF files, so this
> Linux-specific bzImage parsing in unnecessary.

Hmm, shouldn't the order of attempts to figure the alignment be ELF note,
ELF header, and then 2Mb?

Jan


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 07:12:53 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 07:12:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692888.1080510 (Exim 4.92)
	(envelope-from )
	id 1rkfGj-0003jB-3a; Thu, 14 Mar 2024 07:12:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692888.1080510; Thu, 14 Mar 2024 07:12:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkfGi-0003j4-VY; Thu, 14 Mar 2024 07:12:48 +0000
Received: by outflank-mailman (input) for mailman id 692888;
 Thu, 14 Mar 2024 07:12:47 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkfGh-0003ir-4N
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 07:12:47 +0000
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com
 [2a00:1450:4864:20::631])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 414cb66f-e1d2-11ee-a1ee-f123f15fe8a2;
 Thu, 14 Mar 2024 08:12:45 +0100 (CET)
Received: by mail-ej1-x631.google.com with SMTP id
 a640c23a62f3a-a467322d52eso22830966b.2
 for ; Thu, 14 Mar 2024 00:12:45 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a11-20020a170906190b00b00a44e2f3024bsm407573eje.68.2024.03.14.00.12.44
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 14 Mar 2024 00:12:44 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 414cb66f-e1d2-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710400364; x=1711005164; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=uEGIKWERXxJZZsP2GSvtxoFBn1i7L5TVlz/9PjvFIIg=;
        b=YU775gH72Tq9CChpUK+sszg0rOd6unSEEP3oKcNnhVDx9V3Pq50x0h1Sue5DUS9WOj
         IBEm1oz3S0VHckOR9/70YYxUiG/mVn7U1ZFk8MUOOkL5LzEA9qhv+0oC2UIj4iTbhqAY
         9OnLHCwAvmtPm4vfXMkeWNhKETIiaTmqMB+InyUh5sDkr77y/h1uIytLXuAG0tFNryZB
         LaHbLCV1KepKqnX+ClNB3QvIIMKJSrZVwlYTBPo7qWqZOSvCnRIpLMXIxd8KksuqHlg/
         FZmAZ8mZd7In/r158k1f2dGxRfp9YOVWaK6YDLMzyG4hWIawdruWBhsZ3pKcOvwAzFjO
         pi3g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710400364; x=1711005164;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=uEGIKWERXxJZZsP2GSvtxoFBn1i7L5TVlz/9PjvFIIg=;
        b=PtleGJuEE7pQiRUMcJ/RN+vxhG4Mqv1aHxMCSzwTR3UnxB61qyc9ACH+irPZhRgCX2
         re3DFguqT7oxy3eiOb6owcUq7RlhTx9V0V7scaOHscCIgx+7n5Ya1nru44AbxUA2qFc3
         jxNSjjliQxik/rM2C3cGdnEHk+qjFh/gO+h9w1ze+4Bs3SZ9D6v6dqp1KILfQvl7iBke
         5K2dbEgZwYMhZ1n1t4JqIZzTvxq99Y0ye77ovQw3CHNjYiGmT/S+yyJjrdSDlJEa0eyH
         47jl6Hi/lfpshdtQJePx6+sGn7sMaK2UwAEe2Uk83GRgzUNFc4kEUSpQgdklPGLN+86v
         5vgA==
X-Forwarded-Encrypted: i=1; AJvYcCX6rW2oomA5biTUbFyTMJiwghFe09hXZ8hUSxo2Xn/E8ySjszVvB9j1/8J7joRkuZkavrgQ5HVNSTJt50nK23OdjUrWA42nVKVYkX3Ey2g=
X-Gm-Message-State: AOJu0YweIGHWjFRdyqkcuiu9vwQ6CsKpSiarUUtOHsFJkCsgmseCZgUq
	FVdCYj/adHNetDOeqG9qGXznnKyzVkq9GixdP0mwHtYZo18wKReLw7k9DygOKg==
X-Google-Smtp-Source: AGHT+IHlAGzbMsO3qiuxPwesexCM+itoBYdRpP/Rr/YTkAsTZBpwUOjui8Fsp4B6W7gp2nn7qRDa4Q==
X-Received: by 2002:a17:906:6545:b0:a45:2e21:c78c with SMTP id u5-20020a170906654500b00a452e21c78cmr453720ejn.13.1710400364611;
        Thu, 14 Mar 2024 00:12:44 -0700 (PDT)
Message-ID: 
Date: Thu, 14 Mar 2024 08:12:43 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 3/3] x86/PVH: Support relocatable dom0 kernels
Content-Language: en-US
To: Jason Andryuk , xen-devel@lists.xenproject.org
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu
 , George Dunlap ,
 Julien Grall , Stefano Stabellini 
References: <20240313193021.241764-1-jason.andryuk@amd.com>
 <20240313193021.241764-4-jason.andryuk@amd.com>
 <70daf607-03e7-4927-8ce2-5721ca3387ee@amd.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <70daf607-03e7-4927-8ce2-5721ca3387ee@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 13.03.2024 22:02, Jason Andryuk wrote:
> On 2024-03-13 15:30, Jason Andryuk wrote:
>> +/* Find an e820 RAM region that fits the kernel at a suitable alignment. */
>> +static paddr_t __init find_kernel_memory(
>> +    const struct domain *d, struct elf_binary *elf,
>> +    const struct elf_dom_parms *parms)
>> +{
>> +    paddr_t kernel_start = (paddr_t)elf->dest_base & PAGE_MASK;
>> +    paddr_t kernel_end = PAGE_ALIGN((paddr_t)elf->dest_base + elf->dest_size);
>> +    paddr_t kernel_size = kernel_end - kernel_start;
>> +    unsigned int i;
>> +
>> +    /*
>> +     * The memory map is sorted and all RAM regions starts and sizes are
>> +     * aligned to page boundaries.
>> +     */
>> +    for ( i = 0; i < d->arch.nr_e820; i++ )
>> +    {
>> +        paddr_t start = d->arch.e820[i].addr;
>> +        paddr_t end = d->arch.e820[i].addr + d->arch.e820[i].size;
>> +        paddr_t kstart, kend;
>> +
>> +        if ( d->arch.e820[i].type != E820_RAM )
>> +            continue;
>> +
>> +        if ( d->arch.e820[i].size < kernel_size )
>> +            continue;
>> +
>> +        kstart = ROUNDUP(start, parms->phys_align);
>> +        kstart = kstart < parms->phys_min ? parms->phys_min : kstart;
> 
> This should be
>          kstart = MAX(kstart, parms->phys_min);

Except that MAX() really ought to be the last resort; max() and max_t()
want considering in preference.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 07:20:40 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 07:20:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692891.1080519 (Exim 4.92)
	(envelope-from )
	id 1rkfOG-0005cq-Tu; Thu, 14 Mar 2024 07:20:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692891.1080519; Thu, 14 Mar 2024 07:20:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkfOG-0005cj-R0; Thu, 14 Mar 2024 07:20:36 +0000
Received: by outflank-mailman (input) for mailman id 692891;
 Thu, 14 Mar 2024 07:20:35 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkfOF-0005cd-Ke
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 07:20:35 +0000
Received: from smtp-out2.suse.de (smtp-out2.suse.de
 [2a07:de40:b251:101:10:150:64:2])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 58d593b5-e1d3-11ee-afdd-a90da7624cb6;
 Thu, 14 Mar 2024 08:20:34 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org
 [IPv6:2a07:de40:b281:104:10:150:64:97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out2.suse.de (Postfix) with ESMTPS id 19B0A1F801;
 Thu, 14 Mar 2024 07:20:32 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 8D17913977;
 Thu, 14 Mar 2024 07:20:31 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id Bu7nID+l8mUqDgAAD6G6ig
 (envelope-from ); Thu, 14 Mar 2024 07:20:31 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 58d593b5-e1d3-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1710400832; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:  content-transfer-encoding:content-transfer-encoding;
	bh=3JjqpskdWWqkFNyb/N4nRGDuK7ct4tF8cPaLgVVji5c=;
	b=A8aTLtBvZYM/5v7bsN1qa/KcvDXg1P6fZiEPFCsPSLxORnmMwM8VjfVx+rkpoxla/h06fN
	exz3nSjgNV2SZsAqHwXI04RCVypdZLvutjBjOKEkT8ZbiArc45zhHWCLyIzgcbjrIq6QVM
	dazuz8Yt7XyIil9G8QnsIqFZyiydKC4=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1710400832; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:  content-transfer-encoding:content-transfer-encoding;
	bh=3JjqpskdWWqkFNyb/N4nRGDuK7ct4tF8cPaLgVVji5c=;
	b=A8aTLtBvZYM/5v7bsN1qa/KcvDXg1P6fZiEPFCsPSLxORnmMwM8VjfVx+rkpoxla/h06fN
	exz3nSjgNV2SZsAqHwXI04RCVypdZLvutjBjOKEkT8ZbiArc45zhHWCLyIzgcbjrIq6QVM
	dazuz8Yt7XyIil9G8QnsIqFZyiydKC4=
From: Juergen Gross 
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini ,
	Wei Liu ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Paul Durrant ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Tamas K Lengyel ,
	Lukasz Hawrylko ,
	"Daniel P. Smith" ,
	=?UTF-8?q?Mateusz=20M=C3=B3wka?= 
Subject: [PATCH v5 00/13] xen/spinlock: make recursive spinlocks a dedicated type
Date: Thu, 14 Mar 2024 08:20:16 +0100
Message-Id: <20240314072029.16937-1-jgross@suse.com>
X-Mailer: git-send-email 2.35.3
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Level: 
Authentication-Results: smtp-out2.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b=A8aTLtBv
X-Spamd-Result: default: False [-1.81 / 50.00];
	 ARC_NA(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 R_DKIM_ALLOW(-0.20)[suse.com:s=susede1];
	 RCVD_DKIM_ARC_DNSWL_HI(-1.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_MISSING_CHARSET(2.50)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 BROKEN_CONTENT_TYPE(1.50)[];
	 DWL_DNSWL_MED(-2.00)[suse.com:dkim];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_SIGNED(0.00)[suse.com:s=susede1];
	 DKIM_TRACE(0.00)[suse.com:+];
	 MX_GOOD(-0.01)[];
	 RCPT_COUNT_TWELVE(0.00)[17];
	 MID_CONTAINS_FROM(1.00)[];
	 FUZZY_BLOCKED(0.00)[rspamd.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 RCVD_IN_DNSWL_HI(-0.50)[2a07:de40:b281:106:10:150:64:167:received];
	 RCVD_TLS_ALL(0.00)[];
	 BAYES_HAM(-3.00)[100.00%]
X-Spam-Score: -1.81
X-Rspamd-Queue-Id: 19B0A1F801
X-Spam-Flag: NO
X-Rspamd-Server: rspamd1.dmz-prg2.suse.org

Instead of being able to use normal spinlocks as recursive ones, too,
make recursive spinlocks a special lock type.

This will make the spinlock structure smaller in production builds and
add type-safety.

This allows to increase the maximum number of physical cpus from 4095
to 65535 without increasing the size of the lock structure in production
builds (the size of recursive spinlocks in debug builds will grow to
12 bytes due to that change).

Note that rwlock handling is still limiting the number of cpus to 4095,
this is being taken care off in patch 12, which raises the rwlock limit
to 16384 cpus.

Iommu code imposes a limit of 16383 cpus.

Changes in V2:
- addressed comments by Jan Beulich
- lots of additional cleanups
- reorganized complete series

Changes in V3:
- addressed comments by Jan Beulich

Changes in V4:
- former patch 1 has already been applied
- fixed a coding style issue in patch 1

Changes in V5:
- new patches 1 + 10 + 12 + 13
- due to the recent Ghost-race patches the macro layer for calling
  spinlock functions is kept
- addressed comments

Juergen Gross (13):
  xen/spinlock: remove misra rule 21.1 violations
  xen/spinlock: introduce new type for recursive spinlocks
  xen/spinlock: rename recursive lock functions
  xen/spinlock: add rspin_[un]lock_irq[save|restore]()
  xen/spinlock: make struct lock_profile rspinlock_t aware
  xen/spinlock: add explicit non-recursive locking functions
  xen/spinlock: add another function level
  xen/spinlock: add missing rspin_is_locked() and rspin_barrier()
  xen/spinlock: split recursive spinlocks from normal ones
  xen/spinlock: let all is_locked and trylock variants return bool
  xen/spinlock: support higher number of cpus
  xen/rwlock: raise the number of possible cpus
  xen: allow up to 16383 cpus

 xen/arch/Kconfig              |   2 +-
 xen/arch/arm/domain.c         |   4 +-
 xen/arch/arm/mm.c             |   4 +-
 xen/arch/x86/domain.c         |  20 +--
 xen/arch/x86/include/asm/mm.h |   2 +-
 xen/arch/x86/mm.c             |  12 +-
 xen/arch/x86/mm/mem_sharing.c |  16 +--
 xen/arch/x86/mm/mm-locks.h    |   6 +-
 xen/arch/x86/mm/p2m-pod.c     |   6 +-
 xen/arch/x86/mm/p2m.c         |   4 +-
 xen/arch/x86/tboot.c          |   4 +-
 xen/common/domain.c           |   6 +-
 xen/common/domctl.c           |   4 +-
 xen/common/grant_table.c      |  10 +-
 xen/common/ioreq.c            |  54 ++++----
 xen/common/memory.c           |   4 +-
 xen/common/numa.c             |   4 +-
 xen/common/page_alloc.c       |  30 ++---
 xen/common/spinlock.c         | 235 +++++++++++++++++++++++++---------
 xen/drivers/char/console.c    |  38 +++---
 xen/drivers/passthrough/pci.c |   8 +-
 xen/include/xen/rwlock.h      |  18 +--
 xen/include/xen/sched.h       |  10 +-
 xen/include/xen/spinlock.h    | 174 ++++++++++++++++++-------
 24 files changed, 440 insertions(+), 235 deletions(-)

-- 
2.35.3



From xen-devel-bounces@lists.xenproject.org Thu Mar 14 07:20:41 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 07:20:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692892.1080529 (Exim 4.92)
	(envelope-from )
	id 1rkfOL-0005rw-64; Thu, 14 Mar 2024 07:20:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692892.1080529; Thu, 14 Mar 2024 07:20:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkfOL-0005rn-30; Thu, 14 Mar 2024 07:20:41 +0000
Received: by outflank-mailman (input) for mailman id 692892;
 Thu, 14 Mar 2024 07:20:40 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkfOK-0005rB-A4
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 07:20:40 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5b4f105f-e1d3-11ee-a1ee-f123f15fe8a2;
 Thu, 14 Mar 2024 08:20:38 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org
 [IPv6:2a07:de40:b281:104:10:150:64:97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id C04EB21CF1;
 Thu, 14 Mar 2024 07:20:37 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 7C81F13977;
 Thu, 14 Mar 2024 07:20:37 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id UhLnHEWl8mU9DgAAD6G6ig
 (envelope-from ); Thu, 14 Mar 2024 07:20:37 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5b4f105f-e1d3-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1710400837; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=X3wK2bnFDRfOZpwTuXtrdzOv2dz+Aoq7ilBYLmKlrOE=;
	b=XtEVciV9XSAXvu2Ftt1+X3UG5p21zNQSUHdmIzP+sWEnRFuJ1G6mR2eE0/t473+PkyA25j
	XqTgtWkod6gbedfJlR9XQQ2vMSKGiSIxld5Kemrw6yTApNUKqr60B0paxCi0vZnP6j5O4X
	adH0J5hyzmO3FanzLPuyZPZOWSePXPk=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1710400837; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=X3wK2bnFDRfOZpwTuXtrdzOv2dz+Aoq7ilBYLmKlrOE=;
	b=XtEVciV9XSAXvu2Ftt1+X3UG5p21zNQSUHdmIzP+sWEnRFuJ1G6mR2eE0/t473+PkyA25j
	XqTgtWkod6gbedfJlR9XQQ2vMSKGiSIxld5Kemrw6yTApNUKqr60B0paxCi0vZnP6j5O4X
	adH0J5hyzmO3FanzLPuyZPZOWSePXPk=
From: Juergen Gross 
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini ,
	Wei Liu 
Subject: [PATCH v5 01/13] xen/spinlock: remove misra rule 21.1 violations
Date: Thu, 14 Mar 2024 08:20:17 +0100
Message-Id: <20240314072029.16937-2-jgross@suse.com>
X-Mailer: git-send-email 2.35.3
In-Reply-To: <20240314072029.16937-1-jgross@suse.com>
References: <20240314072029.16937-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spamd-Bar: +
Authentication-Results: smtp-out1.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b=XtEVciV9
X-Spamd-Result: default: False [1.19 / 50.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_MISSING_CHARSET(2.50)[];
	 BROKEN_CONTENT_TYPE(1.50)[];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_TRACE(0.00)[suse.com:+];
	 MX_GOOD(-0.01)[];
	 RCPT_COUNT_SEVEN(0.00)[8];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 BAYES_HAM(-0.00)[13.89%];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[suse.com:s=susede1];
	 URIBL_BLOCKED(0.00)[suse.com:email,suse.com:dkim];
	 FROM_HAS_DN(0.00)[];
	 DWL_DNSWL_MED(-2.00)[suse.com:dkim];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 RCVD_DKIM_ARC_DNSWL_HI(-1.00)[];
	 DKIM_SIGNED(0.00)[suse.com:s=susede1];
	 MID_CONTAINS_FROM(1.00)[];
	 FUZZY_BLOCKED(0.00)[rspamd.com];
	 RCVD_IN_DNSWL_HI(-0.50)[2a07:de40:b281:106:10:150:64:167:received];
	 RCVD_TLS_ALL(0.00)[]
X-Spam-Score: 1.19
X-Spam-Level: *
X-Rspamd-Queue-Id: C04EB21CF1
X-Spam-Flag: NO
X-Rspamd-Server: rspamd1.dmz-prg2.suse.org

In xen spinlock code there are several violations of MISRA rule 21.1
(identifiers starting with "__" or "_[A-Z]").

Fix them by using trailing underscores instead.

Signed-off-by: Juergen Gross 
---
V5:
- new patch (Julien Grall)
---
 xen/include/xen/spinlock.h | 28 ++++++++++++++--------------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/xen/include/xen/spinlock.h b/xen/include/xen/spinlock.h
index e351fc9995..8a443efc19 100644
--- a/xen/include/xen/spinlock.h
+++ b/xen/include/xen/spinlock.h
@@ -22,7 +22,7 @@ union lock_debug {
         bool unseen:1;
     };
 };
-#define _LOCK_DEBUG { .val = LOCK_DEBUG_INITVAL }
+#define LOCK_DEBUG_ { .val = LOCK_DEBUG_INITVAL }
 void check_lock(union lock_debug *debug, bool try);
 void lock_enter(const union lock_debug *debug);
 void lock_exit(const union lock_debug *debug);
@@ -30,7 +30,7 @@ void spin_debug_enable(void);
 void spin_debug_disable(void);
 #else
 union lock_debug { };
-#define _LOCK_DEBUG { }
+#define LOCK_DEBUG_ { }
 #define check_lock(l, t) ((void)0)
 #define lock_enter(l) ((void)0)
 #define lock_exit(l) ((void)0)
@@ -95,27 +95,27 @@ struct lock_profile_qhead {
     int32_t                   idx;     /* index for printout */
 };
 
-#define _LOCK_PROFILE(lockname) { .name = #lockname, .lock = &(lockname), }
-#define _LOCK_PROFILE_PTR(name)                                               \
-    static struct lock_profile * const __lock_profile_##name                  \
+#define LOCK_PROFILE_(lockname) { .name = #lockname, .lock = &(lockname), }
+#define LOCK_PROFILE_PTR_(name)                                               \
+    static struct lock_profile * const lock_profile__##name                   \
     __used_section(".lockprofile.data") =                                     \
-    &__lock_profile_data_##name
-#define _SPIN_LOCK_UNLOCKED(x) {                                              \
+    &lock_profile_data__##name
+#define SPIN_LOCK_UNLOCKED_(x) {                                              \
     .recurse_cpu = SPINLOCK_NO_CPU,                                           \
-    .debug =_LOCK_DEBUG,                                                      \
+    .debug = LOCK_DEBUG_,                                                     \
     .profile = x,                                                             \
 }
-#define SPIN_LOCK_UNLOCKED _SPIN_LOCK_UNLOCKED(NULL)
+#define SPIN_LOCK_UNLOCKED SPIN_LOCK_UNLOCKED_(NULL)
 #define DEFINE_SPINLOCK(l)                                                    \
-    spinlock_t l = _SPIN_LOCK_UNLOCKED(NULL);                                 \
-    static struct lock_profile __lock_profile_data_##l = _LOCK_PROFILE(l);    \
-    _LOCK_PROFILE_PTR(l)
+    spinlock_t l = SPIN_LOCK_UNLOCKED_(NULL);                                 \
+    static struct lock_profile lock_profile_data__##l = LOCK_PROFILE_(l);     \
+    LOCK_PROFILE_PTR_(l)
 
 #define spin_lock_init_prof(s, l)                                             \
     do {                                                                      \
         struct lock_profile *prof;                                            \
         prof = xzalloc(struct lock_profile);                                  \
-        (s)->l = (spinlock_t)_SPIN_LOCK_UNLOCKED(prof);                       \
+        (s)->l = (spinlock_t)SPIN_LOCK_UNLOCKED_(prof);                       \
         if ( !prof )                                                          \
         {                                                                     \
             printk(XENLOG_WARNING                                             \
@@ -149,7 +149,7 @@ struct lock_profile_qhead { };
 
 #define SPIN_LOCK_UNLOCKED {                                                  \
     .recurse_cpu = SPINLOCK_NO_CPU,                                           \
-    .debug =_LOCK_DEBUG,                                                      \
+    .debug = LOCK_DEBUG_,                                                     \
 }
 #define DEFINE_SPINLOCK(l) spinlock_t l = SPIN_LOCK_UNLOCKED
 
-- 
2.35.3



From xen-devel-bounces@lists.xenproject.org Thu Mar 14 07:20:46 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 07:20:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692893.1080539 (Exim 4.92)
	(envelope-from )
	id 1rkfOQ-0006A3-FV; Thu, 14 Mar 2024 07:20:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692893.1080539; Thu, 14 Mar 2024 07:20:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkfOQ-00069u-BN; Thu, 14 Mar 2024 07:20:46 +0000
Received: by outflank-mailman (input) for mailman id 692893;
 Thu, 14 Mar 2024 07:20:44 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkfOO-0005cd-JJ
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 07:20:44 +0000
Received: from smtp-out2.suse.de (smtp-out2.suse.de
 [2a07:de40:b251:101:10:150:64:2])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5ea5b875-e1d3-11ee-afdd-a90da7624cb6;
 Thu, 14 Mar 2024 08:20:43 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [10.150.64.97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out2.suse.de (Postfix) with ESMTPS id 849331F79B;
 Thu, 14 Mar 2024 07:20:43 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 2C51A13977;
 Thu, 14 Mar 2024 07:20:43 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id 23g9CUul8mVEDgAAD6G6ig
 (envelope-from ); Thu, 14 Mar 2024 07:20:43 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5ea5b875-e1d3-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1710400843; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=8SoHtTqibFLRHMVIneFYHEvHJn0+Pf8akCVrfANI5Kk=;
	b=UtjjGmvlEZgzkf0ajpqMhzvRwrdgeNDNME2mUCv+CJMiXhz3as7rV/7nj/7fiVFa0hsXix
	uWwNXwxF8MhGnXogt3ROWFqc4KsqhGqQAE0dYclbYLDV1ERRVQcjcsneH4fzA7F/53Bxck
	RNryG3rbnPYxLr2WLz1x3cnU7k1G7as=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1710400843; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=8SoHtTqibFLRHMVIneFYHEvHJn0+Pf8akCVrfANI5Kk=;
	b=UtjjGmvlEZgzkf0ajpqMhzvRwrdgeNDNME2mUCv+CJMiXhz3as7rV/7nj/7fiVFa0hsXix
	uWwNXwxF8MhGnXogt3ROWFqc4KsqhGqQAE0dYclbYLDV1ERRVQcjcsneH4fzA7F/53Bxck
	RNryG3rbnPYxLr2WLz1x3cnU7k1G7as=
From: Juergen Gross 
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross ,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Wei Liu ,
	George Dunlap ,
	Julien Grall ,
	Stefano Stabellini ,
	Paul Durrant ,
	Julien Grall 
Subject: [PATCH v5 02/13] xen/spinlock: introduce new type for recursive spinlocks
Date: Thu, 14 Mar 2024 08:20:18 +0100
Message-Id: <20240314072029.16937-3-jgross@suse.com>
X-Mailer: git-send-email 2.35.3
In-Reply-To: <20240314072029.16937-1-jgross@suse.com>
References: <20240314072029.16937-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Authentication-Results: smtp-out2.suse.de;
	none
X-Spam-Level: 
X-Spam-Score: 0.70
X-Spamd-Result: default: False [0.70 / 50.00];
	 ARC_NA(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_MISSING_CHARSET(2.50)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 BROKEN_CONTENT_TYPE(1.50)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_SIGNED(0.00)[suse.com:s=susede1];
	 NEURAL_HAM_SHORT(-0.20)[-1.000];
	 RCPT_COUNT_SEVEN(0.00)[11];
	 MID_CONTAINS_FROM(1.00)[];
	 FUZZY_BLOCKED(0.00)[rspamd.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 RCVD_TLS_ALL(0.00)[];
	 BAYES_HAM(-3.00)[100.00%]
X-Spam-Flag: NO

Introduce a new type "rspinlock_t" to be used for recursive spinlocks.

For now it is only an alias of spinlock_t, so both types can still be
used for recursive spinlocks. This will be changed later, though.

Switch all recursive spinlocks to the new type.

Define the initializer helpers and use them where appropriate.

Signed-off-by: Juergen Gross 
Acked-by: Julien Grall 
---
V2:
- carved out from V1 patch
V5:
- avoid MISRA violation (Julien Grall)
---
 xen/arch/x86/include/asm/mm.h |  2 +-
 xen/arch/x86/mm/mm-locks.h    |  2 +-
 xen/common/domain.c           |  4 ++--
 xen/common/ioreq.c            |  2 +-
 xen/drivers/char/console.c    |  4 ++--
 xen/drivers/passthrough/pci.c |  2 +-
 xen/include/xen/sched.h       |  6 +++---
 xen/include/xen/spinlock.h    | 19 +++++++++++++++----
 8 files changed, 26 insertions(+), 15 deletions(-)

diff --git a/xen/arch/x86/include/asm/mm.h b/xen/arch/x86/include/asm/mm.h
index 65d209d5ff..98b66edaca 100644
--- a/xen/arch/x86/include/asm/mm.h
+++ b/xen/arch/x86/include/asm/mm.h
@@ -597,7 +597,7 @@ unsigned long domain_get_maximum_gpfn(struct domain *d);
 
 /* Definition of an mm lock: spinlock with extra fields for debugging */
 typedef struct mm_lock {
-    spinlock_t         lock;
+    rspinlock_t        lock;
     int                unlock_level;
     int                locker;          /* processor which holds the lock */
     const char        *locker_function; /* func that took it */
diff --git a/xen/arch/x86/mm/mm-locks.h b/xen/arch/x86/mm/mm-locks.h
index 2eae73ac68..c25261b4c0 100644
--- a/xen/arch/x86/mm/mm-locks.h
+++ b/xen/arch/x86/mm/mm-locks.h
@@ -20,7 +20,7 @@ DECLARE_PERCPU_RWLOCK_GLOBAL(p2m_percpu_rwlock);
 
 static inline void mm_lock_init(mm_lock_t *l)
 {
-    spin_lock_init(&l->lock);
+    rspin_lock_init(&l->lock);
     l->locker = -1;
     l->locker_function = "nobody";
     l->unlock_level = 0;
diff --git a/xen/common/domain.c b/xen/common/domain.c
index f6f5574996..8e0109c590 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -627,8 +627,8 @@ struct domain *domain_create(domid_t domid,
 
     atomic_set(&d->refcnt, 1);
     RCU_READ_LOCK_INIT(&d->rcu_lock);
-    spin_lock_init_prof(d, domain_lock);
-    spin_lock_init_prof(d, page_alloc_lock);
+    rspin_lock_init_prof(d, domain_lock);
+    rspin_lock_init_prof(d, page_alloc_lock);
     spin_lock_init(&d->hypercall_deadlock_mutex);
     INIT_PAGE_LIST_HEAD(&d->page_list);
     INIT_PAGE_LIST_HEAD(&d->extra_page_list);
diff --git a/xen/common/ioreq.c b/xen/common/ioreq.c
index 62b907f4c4..652c18a9b5 100644
--- a/xen/common/ioreq.c
+++ b/xen/common/ioreq.c
@@ -1331,7 +1331,7 @@ unsigned int ioreq_broadcast(ioreq_t *p, bool buffered)
 
 void ioreq_domain_init(struct domain *d)
 {
-    spin_lock_init(&d->ioreq_server.lock);
+    rspin_lock_init(&d->ioreq_server.lock);
 
     arch_ioreq_domain_init(d);
 }
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index d2cb0530b2..6a88a0b32c 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -119,7 +119,7 @@ static int __read_mostly sercon_handle = -1;
 int8_t __read_mostly opt_console_xen; /* console=xen */
 #endif
 
-static DEFINE_SPINLOCK(console_lock);
+static DEFINE_RSPINLOCK(console_lock);
 
 /*
  * To control the amount of printing, thresholds are added.
@@ -1177,7 +1177,7 @@ void console_force_unlock(void)
 {
     watchdog_disable();
     spin_debug_disable();
-    spin_lock_init(&console_lock);
+    rspin_lock_init(&console_lock);
     serial_force_unlock(sercon_handle);
     console_locks_busted = 1;
     console_start_sync();
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 6a1eda675d..b6b2196ab0 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -50,7 +50,7 @@ struct pci_seg {
     } bus2bridge[MAX_BUSES];
 };
 
-static spinlock_t _pcidevs_lock = SPIN_LOCK_UNLOCKED;
+static DEFINE_RSPINLOCK(_pcidevs_lock);
 
 /* Do not use, as it has no speculation barrier, use pcidevs_lock() instead. */
 void pcidevs_lock_unsafe(void)
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 37f5922f32..bc320f4e55 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -376,9 +376,9 @@ struct domain
 
     rcu_read_lock_t  rcu_lock;
 
-    spinlock_t       domain_lock;
+    rspinlock_t      domain_lock;
 
-    spinlock_t       page_alloc_lock; /* protects all the following fields  */
+    rspinlock_t      page_alloc_lock; /* protects all the following fields  */
     struct page_list_head page_list;  /* linked list */
     struct page_list_head extra_page_list; /* linked list (size extra_pages) */
     struct page_list_head xenpage_list; /* linked list (size xenheap_pages) */
@@ -620,7 +620,7 @@ struct domain
 #ifdef CONFIG_IOREQ_SERVER
     /* Lock protects all other values in the sub-struct */
     struct {
-        spinlock_t              lock;
+        rspinlock_t             lock;
         struct ioreq_server     *server[MAX_NR_IOREQ_SERVERS];
     } ioreq_server;
 #endif
diff --git a/xen/include/xen/spinlock.h b/xen/include/xen/spinlock.h
index 8a443efc19..bbf12b93c4 100644
--- a/xen/include/xen/spinlock.h
+++ b/xen/include/xen/spinlock.h
@@ -46,7 +46,7 @@ union lock_debug { };
     lock profiling on:
 
     Global locks which should be subject to profiling must be declared via
-    DEFINE_SPINLOCK.
+    DEFINE_[R]SPINLOCK.
 
     For locks in structures further measures are necessary:
     - the structure definition must include a profile_head with exactly this
@@ -57,7 +57,7 @@ union lock_debug { };
     - the single locks which are subject to profiling have to be initialized
       via
 
-      spin_lock_init_prof(ptr, lock);
+      [r]spin_lock_init_prof(ptr, lock);
 
       with ptr being the main structure pointer and lock the spinlock field
 
@@ -110,12 +110,16 @@ struct lock_profile_qhead {
     spinlock_t l = SPIN_LOCK_UNLOCKED_(NULL);                                 \
     static struct lock_profile lock_profile_data__##l = LOCK_PROFILE_(l);     \
     LOCK_PROFILE_PTR_(l)
+#define DEFINE_RSPINLOCK(l)                                                   \
+    rspinlock_t l = SPIN_LOCK_UNLOCKED_(NULL);                                \
+    static struct lock_profile lock_profile_data__##l = LOCK_PROFILE_(l);     \
+    LOCK_PROFILE_PTR_(l)
 
-#define spin_lock_init_prof(s, l)                                             \
+#define spin_lock_init_prof__(s, l, locktype)                                 \
     do {                                                                      \
         struct lock_profile *prof;                                            \
         prof = xzalloc(struct lock_profile);                                  \
-        (s)->l = (spinlock_t)SPIN_LOCK_UNLOCKED_(prof);                       \
+        (s)->l = (locktype)SPIN_LOCK_UNLOCKED_(prof);                         \
         if ( !prof )                                                          \
         {                                                                     \
             printk(XENLOG_WARNING                                             \
@@ -129,6 +133,9 @@ struct lock_profile_qhead {
         (s)->profile_head.elem_q = prof;                                      \
     } while( 0 )
 
+#define spin_lock_init_prof(s, l) spin_lock_init_prof__(s, l, spinlock_t)
+#define rspin_lock_init_prof(s, l) spin_lock_init_prof__(s, l, rspinlock_t)
+
 void _lock_profile_register_struct(
     int32_t type, struct lock_profile_qhead *qhead, int32_t idx);
 void _lock_profile_deregister_struct(int32_t type,
@@ -152,8 +159,10 @@ struct lock_profile_qhead { };
     .debug = LOCK_DEBUG_,                                                     \
 }
 #define DEFINE_SPINLOCK(l) spinlock_t l = SPIN_LOCK_UNLOCKED
+#define DEFINE_RSPINLOCK(l) rspinlock_t l = SPIN_LOCK_UNLOCKED
 
 #define spin_lock_init_prof(s, l) spin_lock_init(&((s)->l))
+#define rspin_lock_init_prof(s, l) rspin_lock_init(&((s)->l))
 #define lock_profile_register_struct(type, ptr, idx)
 #define lock_profile_deregister_struct(type, ptr)
 #define spinlock_profile_printall(key)
@@ -183,8 +192,10 @@ typedef struct spinlock {
 #endif
 } spinlock_t;
 
+typedef spinlock_t rspinlock_t;
 
 #define spin_lock_init(l) (*(l) = (spinlock_t)SPIN_LOCK_UNLOCKED)
+#define rspin_lock_init(l) (*(l) = (rspinlock_t)SPIN_LOCK_UNLOCKED)
 
 void _spin_lock(spinlock_t *lock);
 void _spin_lock_cb(spinlock_t *lock, void (*cb)(void *data), void *data);
-- 
2.35.3



From xen-devel-bounces@lists.xenproject.org Thu Mar 14 07:20:52 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 07:20:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692894.1080548 (Exim 4.92)
	(envelope-from )
	id 1rkfOW-0006YG-Ma; Thu, 14 Mar 2024 07:20:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692894.1080548; Thu, 14 Mar 2024 07:20:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkfOW-0006Y9-Jo; Thu, 14 Mar 2024 07:20:52 +0000
Received: by outflank-mailman (input) for mailman id 692894;
 Thu, 14 Mar 2024 07:20:51 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkfOU-0005cd-WE
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 07:20:51 +0000
Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 623eb253-e1d3-11ee-afdd-a90da7624cb6;
 Thu, 14 Mar 2024 08:20:50 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org
 [IPv6:2a07:de40:b281:104:10:150:64:97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out2.suse.de (Postfix) with ESMTPS id 6480F1F801;
 Thu, 14 Mar 2024 07:20:49 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id E7ECB13977;
 Thu, 14 Mar 2024 07:20:48 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id nmnrNlCl8mVIDgAAD6G6ig
 (envelope-from ); Thu, 14 Mar 2024 07:20:48 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 623eb253-e1d3-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1710400849; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=FVq2Hhj4vgnKxymRlgvuDk+/88ycU3FDdi3C03ffSSU=;
	b=LSj85bTVer0Yyv4TshSUyjWTfE2y5k/eAAEuirfoBmlJ8JkQt9Nq9d2XFIuYPWbUOWnpd8
	wLUqj/svIK5VFADn7nOP3h5T48gWU3zM8JDh0KyIxx2Ah8MZZ5+3MkWm2Cs5+g6lWqVD0w
	vWCJs0tLIOX2UDoGxaViRCBfMFJQEh0=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1710400849; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=FVq2Hhj4vgnKxymRlgvuDk+/88ycU3FDdi3C03ffSSU=;
	b=LSj85bTVer0Yyv4TshSUyjWTfE2y5k/eAAEuirfoBmlJ8JkQt9Nq9d2XFIuYPWbUOWnpd8
	wLUqj/svIK5VFADn7nOP3h5T48gWU3zM8JDh0KyIxx2Ah8MZZ5+3MkWm2Cs5+g6lWqVD0w
	vWCJs0tLIOX2UDoGxaViRCBfMFJQEh0=
From: Juergen Gross 
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Wei Liu ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Tamas K Lengyel ,
	Paul Durrant ,
	Julien Grall 
Subject: [PATCH v5 03/13] xen/spinlock: rename recursive lock functions
Date: Thu, 14 Mar 2024 08:20:19 +0100
Message-Id: <20240314072029.16937-4-jgross@suse.com>
X-Mailer: git-send-email 2.35.3
In-Reply-To: <20240314072029.16937-1-jgross@suse.com>
References: <20240314072029.16937-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Level: 
Authentication-Results: smtp-out2.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b=LSj85bTV
X-Spamd-Result: default: False [-1.81 / 50.00];
	 ARC_NA(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 R_DKIM_ALLOW(-0.20)[suse.com:s=susede1];
	 URIBL_BLOCKED(0.00)[suse.com:email,suse.com:dkim];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_MISSING_CHARSET(2.50)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 RCVD_DKIM_ARC_DNSWL_HI(-1.00)[];
	 BROKEN_CONTENT_TYPE(1.50)[];
	 DWL_DNSWL_MED(-2.00)[suse.com:dkim];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_SIGNED(0.00)[suse.com:s=susede1];
	 DKIM_TRACE(0.00)[suse.com:+];
	 MX_GOOD(-0.01)[];
	 RCPT_COUNT_TWELVE(0.00)[15];
	 MID_CONTAINS_FROM(1.00)[];
	 FUZZY_BLOCKED(0.00)[rspamd.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 RCVD_IN_DNSWL_HI(-0.50)[2a07:de40:b281:106:10:150:64:167:received];
	 RCVD_TLS_ALL(0.00)[];
	 BAYES_HAM(-3.00)[100.00%]
X-Spam-Score: -1.81
X-Rspamd-Queue-Id: 6480F1F801
X-Spam-Flag: NO
X-Rspamd-Server: rspamd1.dmz-prg2.suse.org

Rename the recursive spin_lock() functions by replacing the trailing
"_recursive" with a leading "r".

Switch the parameter to be a pointer to rspinlock_t.

Suggested-by: Jan Beulich 
Signed-off-by: Juergen Gross 
Acked-by: Julien Grall 
Acked-by: Jan Beulich 
---
V2:
- new patch
V5:
- let rspin_trylock() return bool (Jan Beulich)
- keep inline/macro layer
---
 xen/arch/arm/domain.c         |  4 +--
 xen/arch/x86/domain.c         |  8 +++---
 xen/arch/x86/mm/mem_sharing.c |  8 +++---
 xen/arch/x86/mm/mm-locks.h    |  4 +--
 xen/common/ioreq.c            | 52 +++++++++++++++++------------------
 xen/common/page_alloc.c       | 12 ++++----
 xen/common/spinlock.c         | 12 ++++----
 xen/drivers/char/console.c    | 12 ++++----
 xen/drivers/passthrough/pci.c |  4 +--
 xen/include/xen/sched.h       |  4 +--
 xen/include/xen/spinlock.h    | 18 ++++++------
 11 files changed, 68 insertions(+), 70 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 5e7a7f3e7e..f38cb5e04c 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -987,7 +987,7 @@ static int relinquish_memory(struct domain *d, struct page_list_head *list)
     int               ret = 0;
 
     /* Use a recursive lock, as we may enter 'free_domheap_page'. */
-    spin_lock_recursive(&d->page_alloc_lock);
+    rspin_lock(&d->page_alloc_lock);
 
     page_list_for_each_safe( page, tmp, list )
     {
@@ -1014,7 +1014,7 @@ static int relinquish_memory(struct domain *d, struct page_list_head *list)
     }
 
   out:
-    spin_unlock_recursive(&d->page_alloc_lock);
+    rspin_unlock(&d->page_alloc_lock);
     return ret;
 }
 
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index bda853e3c9..a11c55f921 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1323,7 +1323,7 @@ int arch_set_info_guest(
         {
             bool done = false;
 
-            spin_lock_recursive(&d->page_alloc_lock);
+            rspin_lock(&d->page_alloc_lock);
 
             for ( i = 0; ; )
             {
@@ -1344,7 +1344,7 @@ int arch_set_info_guest(
                     break;
             }
 
-            spin_unlock_recursive(&d->page_alloc_lock);
+            rspin_unlock(&d->page_alloc_lock);
 
             if ( !done )
                 return -ERESTART;
@@ -2183,7 +2183,7 @@ static int relinquish_memory(
     int               ret = 0;
 
     /* Use a recursive lock, as we may enter 'free_domheap_page'. */
-    spin_lock_recursive(&d->page_alloc_lock);
+    rspin_lock(&d->page_alloc_lock);
 
     while ( (page = page_list_remove_head(list)) )
     {
@@ -2324,7 +2324,7 @@ static int relinquish_memory(
     page_list_move(list, &d->arch.relmem_list);
 
  out:
-    spin_unlock_recursive(&d->page_alloc_lock);
+    rspin_unlock(&d->page_alloc_lock);
     return ret;
 }
 
diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index fe299a2bf9..f58576c702 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -682,7 +682,7 @@ static int page_make_sharable(struct domain *d,
     int rc = 0;
     bool drop_dom_ref = false;
 
-    spin_lock_recursive(&d->page_alloc_lock);
+    rspin_lock(&d->page_alloc_lock);
 
     if ( d->is_dying )
     {
@@ -725,7 +725,7 @@ static int page_make_sharable(struct domain *d,
     }
 
 out:
-    spin_unlock_recursive(&d->page_alloc_lock);
+    rspin_unlock(&d->page_alloc_lock);
 
     if ( drop_dom_ref )
         put_domain(d);
@@ -1936,7 +1936,7 @@ int mem_sharing_fork_reset(struct domain *d, bool reset_state,
         goto state;
 
     /* need recursive lock because we will free pages */
-    spin_lock_recursive(&d->page_alloc_lock);
+    rspin_lock(&d->page_alloc_lock);
     page_list_for_each_safe(page, tmp, &d->page_list)
     {
         shr_handle_t sh;
@@ -1965,7 +1965,7 @@ int mem_sharing_fork_reset(struct domain *d, bool reset_state,
         put_page_alloc_ref(page);
         put_page_and_type(page);
     }
-    spin_unlock_recursive(&d->page_alloc_lock);
+    rspin_unlock(&d->page_alloc_lock);
 
  state:
     if ( reset_state )
diff --git a/xen/arch/x86/mm/mm-locks.h b/xen/arch/x86/mm/mm-locks.h
index c25261b4c0..669969c6ee 100644
--- a/xen/arch/x86/mm/mm-locks.h
+++ b/xen/arch/x86/mm/mm-locks.h
@@ -79,7 +79,7 @@ static always_inline void _mm_lock(const struct domain *d, mm_lock_t *l,
 {
     if ( !((mm_locked_by_me(l)) && rec) )
         _check_lock_level(d, level);
-    spin_lock_recursive(&l->lock);
+    rspin_lock(&l->lock);
     if ( l->lock.recurse_cnt == 1 )
     {
         l->locker_function = func;
@@ -202,7 +202,7 @@ static inline void mm_unlock(mm_lock_t *l)
         l->locker_function = "nobody";
         _set_lock_level(l->unlock_level);
     }
-    spin_unlock_recursive(&l->lock);
+    rspin_unlock(&l->lock);
 }
 
 static inline void mm_enforce_order_unlock(int unlock_level,
diff --git a/xen/common/ioreq.c b/xen/common/ioreq.c
index 652c18a9b5..1257a3d972 100644
--- a/xen/common/ioreq.c
+++ b/xen/common/ioreq.c
@@ -329,7 +329,7 @@ bool is_ioreq_server_page(struct domain *d, const struct page_info *page)
     unsigned int id;
     bool found = false;
 
-    spin_lock_recursive(&d->ioreq_server.lock);
+    rspin_lock(&d->ioreq_server.lock);
 
     FOR_EACH_IOREQ_SERVER(d, id, s)
     {
@@ -340,7 +340,7 @@ bool is_ioreq_server_page(struct domain *d, const struct page_info *page)
         }
     }
 
-    spin_unlock_recursive(&d->ioreq_server.lock);
+    rspin_unlock(&d->ioreq_server.lock);
 
     return found;
 }
@@ -658,7 +658,7 @@ static int ioreq_server_create(struct domain *d, int bufioreq_handling,
         return -ENOMEM;
 
     domain_pause(d);
-    spin_lock_recursive(&d->ioreq_server.lock);
+    rspin_lock(&d->ioreq_server.lock);
 
     for ( i = 0; i < MAX_NR_IOREQ_SERVERS; i++ )
     {
@@ -686,13 +686,13 @@ static int ioreq_server_create(struct domain *d, int bufioreq_handling,
     if ( id )
         *id = i;
 
-    spin_unlock_recursive(&d->ioreq_server.lock);
+    rspin_unlock(&d->ioreq_server.lock);
     domain_unpause(d);
 
     return 0;
 
  fail:
-    spin_unlock_recursive(&d->ioreq_server.lock);
+    rspin_unlock(&d->ioreq_server.lock);
     domain_unpause(d);
 
     xfree(s);
@@ -704,7 +704,7 @@ static int ioreq_server_destroy(struct domain *d, ioservid_t id)
     struct ioreq_server *s;
     int rc;
 
-    spin_lock_recursive(&d->ioreq_server.lock);
+    rspin_lock(&d->ioreq_server.lock);
 
     s = get_ioreq_server(d, id);
 
@@ -736,7 +736,7 @@ static int ioreq_server_destroy(struct domain *d, ioservid_t id)
     rc = 0;
 
  out:
-    spin_unlock_recursive(&d->ioreq_server.lock);
+    rspin_unlock(&d->ioreq_server.lock);
 
     return rc;
 }
@@ -749,7 +749,7 @@ static int ioreq_server_get_info(struct domain *d, ioservid_t id,
     struct ioreq_server *s;
     int rc;
 
-    spin_lock_recursive(&d->ioreq_server.lock);
+    rspin_lock(&d->ioreq_server.lock);
 
     s = get_ioreq_server(d, id);
 
@@ -783,7 +783,7 @@ static int ioreq_server_get_info(struct domain *d, ioservid_t id,
     rc = 0;
 
  out:
-    spin_unlock_recursive(&d->ioreq_server.lock);
+    rspin_unlock(&d->ioreq_server.lock);
 
     return rc;
 }
@@ -796,7 +796,7 @@ int ioreq_server_get_frame(struct domain *d, ioservid_t id,
 
     ASSERT(is_hvm_domain(d));
 
-    spin_lock_recursive(&d->ioreq_server.lock);
+    rspin_lock(&d->ioreq_server.lock);
 
     s = get_ioreq_server(d, id);
 
@@ -834,7 +834,7 @@ int ioreq_server_get_frame(struct domain *d, ioservid_t id,
     }
 
  out:
-    spin_unlock_recursive(&d->ioreq_server.lock);
+    rspin_unlock(&d->ioreq_server.lock);
 
     return rc;
 }
@@ -850,7 +850,7 @@ static int ioreq_server_map_io_range(struct domain *d, ioservid_t id,
     if ( start > end )
         return -EINVAL;
 
-    spin_lock_recursive(&d->ioreq_server.lock);
+    rspin_lock(&d->ioreq_server.lock);
 
     s = get_ioreq_server(d, id);
 
@@ -886,7 +886,7 @@ static int ioreq_server_map_io_range(struct domain *d, ioservid_t id,
     rc = rangeset_add_range(r, start, end);
 
  out:
-    spin_unlock_recursive(&d->ioreq_server.lock);
+    rspin_unlock(&d->ioreq_server.lock);
 
     return rc;
 }
@@ -902,7 +902,7 @@ static int ioreq_server_unmap_io_range(struct domain *d, ioservid_t id,
     if ( start > end )
         return -EINVAL;
 
-    spin_lock_recursive(&d->ioreq_server.lock);
+    rspin_lock(&d->ioreq_server.lock);
 
     s = get_ioreq_server(d, id);
 
@@ -938,7 +938,7 @@ static int ioreq_server_unmap_io_range(struct domain *d, ioservid_t id,
     rc = rangeset_remove_range(r, start, end);
 
  out:
-    spin_unlock_recursive(&d->ioreq_server.lock);
+    rspin_unlock(&d->ioreq_server.lock);
 
     return rc;
 }
@@ -963,7 +963,7 @@ int ioreq_server_map_mem_type(struct domain *d, ioservid_t id,
     if ( flags & ~XEN_DMOP_IOREQ_MEM_ACCESS_WRITE )
         return -EINVAL;
 
-    spin_lock_recursive(&d->ioreq_server.lock);
+    rspin_lock(&d->ioreq_server.lock);
 
     s = get_ioreq_server(d, id);
 
@@ -978,7 +978,7 @@ int ioreq_server_map_mem_type(struct domain *d, ioservid_t id,
     rc = arch_ioreq_server_map_mem_type(d, s, flags);
 
  out:
-    spin_unlock_recursive(&d->ioreq_server.lock);
+    rspin_unlock(&d->ioreq_server.lock);
 
     if ( rc == 0 )
         arch_ioreq_server_map_mem_type_completed(d, s, flags);
@@ -992,7 +992,7 @@ static int ioreq_server_set_state(struct domain *d, ioservid_t id,
     struct ioreq_server *s;
     int rc;
 
-    spin_lock_recursive(&d->ioreq_server.lock);
+    rspin_lock(&d->ioreq_server.lock);
 
     s = get_ioreq_server(d, id);
 
@@ -1016,7 +1016,7 @@ static int ioreq_server_set_state(struct domain *d, ioservid_t id,
     rc = 0;
 
  out:
-    spin_unlock_recursive(&d->ioreq_server.lock);
+    rspin_unlock(&d->ioreq_server.lock);
     return rc;
 }
 
@@ -1026,7 +1026,7 @@ int ioreq_server_add_vcpu_all(struct domain *d, struct vcpu *v)
     unsigned int id;
     int rc;
 
-    spin_lock_recursive(&d->ioreq_server.lock);
+    rspin_lock(&d->ioreq_server.lock);
 
     FOR_EACH_IOREQ_SERVER(d, id, s)
     {
@@ -1035,7 +1035,7 @@ int ioreq_server_add_vcpu_all(struct domain *d, struct vcpu *v)
             goto fail;
     }
 
-    spin_unlock_recursive(&d->ioreq_server.lock);
+    rspin_unlock(&d->ioreq_server.lock);
 
     return 0;
 
@@ -1050,7 +1050,7 @@ int ioreq_server_add_vcpu_all(struct domain *d, struct vcpu *v)
         ioreq_server_remove_vcpu(s, v);
     }
 
-    spin_unlock_recursive(&d->ioreq_server.lock);
+    rspin_unlock(&d->ioreq_server.lock);
 
     return rc;
 }
@@ -1060,12 +1060,12 @@ void ioreq_server_remove_vcpu_all(struct domain *d, struct vcpu *v)
     struct ioreq_server *s;
     unsigned int id;
 
-    spin_lock_recursive(&d->ioreq_server.lock);
+    rspin_lock(&d->ioreq_server.lock);
 
     FOR_EACH_IOREQ_SERVER(d, id, s)
         ioreq_server_remove_vcpu(s, v);
 
-    spin_unlock_recursive(&d->ioreq_server.lock);
+    rspin_unlock(&d->ioreq_server.lock);
 }
 
 void ioreq_server_destroy_all(struct domain *d)
@@ -1076,7 +1076,7 @@ void ioreq_server_destroy_all(struct domain *d)
     if ( !arch_ioreq_server_destroy_all(d) )
         return;
 
-    spin_lock_recursive(&d->ioreq_server.lock);
+    rspin_lock(&d->ioreq_server.lock);
 
     /* No need to domain_pause() as the domain is being torn down */
 
@@ -1094,7 +1094,7 @@ void ioreq_server_destroy_all(struct domain *d)
         xfree(s);
     }
 
-    spin_unlock_recursive(&d->ioreq_server.lock);
+    rspin_unlock(&d->ioreq_server.lock);
 }
 
 struct ioreq_server *ioreq_server_select(struct domain *d,
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 2ec17df9b4..b4e0ef3a4c 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -2500,7 +2500,7 @@ void free_domheap_pages(struct page_info *pg, unsigned int order)
     if ( unlikely(is_xen_heap_page(pg)) )
     {
         /* NB. May recursively lock from relinquish_memory(). */
-        spin_lock_recursive(&d->page_alloc_lock);
+        rspin_lock(&d->page_alloc_lock);
 
         for ( i = 0; i < (1 << order); i++ )
             arch_free_heap_page(d, &pg[i]);
@@ -2508,7 +2508,7 @@ void free_domheap_pages(struct page_info *pg, unsigned int order)
         d->xenheap_pages -= 1 << order;
         drop_dom_ref = (d->xenheap_pages == 0);
 
-        spin_unlock_recursive(&d->page_alloc_lock);
+        rspin_unlock(&d->page_alloc_lock);
     }
     else
     {
@@ -2517,7 +2517,7 @@ void free_domheap_pages(struct page_info *pg, unsigned int order)
         if ( likely(d) && likely(d != dom_cow) )
         {
             /* NB. May recursively lock from relinquish_memory(). */
-            spin_lock_recursive(&d->page_alloc_lock);
+            rspin_lock(&d->page_alloc_lock);
 
             for ( i = 0; i < (1 << order); i++ )
             {
@@ -2540,7 +2540,7 @@ void free_domheap_pages(struct page_info *pg, unsigned int order)
 
             drop_dom_ref = !domain_adjust_tot_pages(d, -(1 << order));
 
-            spin_unlock_recursive(&d->page_alloc_lock);
+            rspin_unlock(&d->page_alloc_lock);
 
             /*
              * Normally we expect a domain to clear pages before freeing them,
@@ -2756,7 +2756,7 @@ void free_domstatic_page(struct page_info *page)
     ASSERT_ALLOC_CONTEXT();
 
     /* NB. May recursively lock from relinquish_memory(). */
-    spin_lock_recursive(&d->page_alloc_lock);
+    rspin_lock(&d->page_alloc_lock);
 
     arch_free_heap_page(d, page);
 
@@ -2767,7 +2767,7 @@ void free_domstatic_page(struct page_info *page)
     /* Add page on the resv_page_list *after* it has been freed. */
     page_list_add_tail(page, &d->resv_page_list);
 
-    spin_unlock_recursive(&d->page_alloc_lock);
+    rspin_unlock(&d->page_alloc_lock);
 
     if ( drop_dom_ref )
         put_domain(d);
diff --git a/xen/common/spinlock.c b/xen/common/spinlock.c
index 09028af864..11e13e1259 100644
--- a/xen/common/spinlock.c
+++ b/xen/common/spinlock.c
@@ -436,7 +436,7 @@ void _spin_barrier(spinlock_t *lock)
     smp_mb();
 }
 
-int _spin_trylock_recursive(spinlock_t *lock)
+bool _rspin_trylock(rspinlock_t *lock)
 {
     unsigned int cpu = smp_processor_id();
 
@@ -448,8 +448,8 @@ int _spin_trylock_recursive(spinlock_t *lock)
 
     if ( likely(lock->recurse_cpu != cpu) )
     {
-        if ( !spin_trylock(lock) )
-            return 0;
+        if ( !_spin_trylock(lock) )
+            return false;
         lock->recurse_cpu = cpu;
     }
 
@@ -457,10 +457,10 @@ int _spin_trylock_recursive(spinlock_t *lock)
     ASSERT(lock->recurse_cnt < SPINLOCK_MAX_RECURSE);
     lock->recurse_cnt++;
 
-    return 1;
+    return true;
 }
 
-void _spin_lock_recursive(spinlock_t *lock)
+void _rspin_lock(rspinlock_t *lock)
 {
     unsigned int cpu = smp_processor_id();
 
@@ -475,7 +475,7 @@ void _spin_lock_recursive(spinlock_t *lock)
     lock->recurse_cnt++;
 }
 
-void _spin_unlock_recursive(spinlock_t *lock)
+void _rspin_unlock(rspinlock_t *lock)
 {
     if ( likely(--lock->recurse_cnt == 0) )
     {
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 6a88a0b32c..eca17b55b4 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -919,7 +919,7 @@ static void vprintk_common(const char *prefix, const char *fmt, va_list args)
 
     /* console_lock can be acquired recursively from __printk_ratelimit(). */
     local_irq_save(flags);
-    spin_lock_recursive(&console_lock);
+    rspin_lock(&console_lock);
     state = &this_cpu(state);
 
     (void)vsnprintf(buf, sizeof(buf), fmt, args);
@@ -955,7 +955,7 @@ static void vprintk_common(const char *prefix, const char *fmt, va_list args)
         state->continued = 1;
     }
 
-    spin_unlock_recursive(&console_lock);
+    rspin_unlock(&console_lock);
     local_irq_restore(flags);
 }
 
@@ -1162,14 +1162,14 @@ unsigned long console_lock_recursive_irqsave(void)
     unsigned long flags;
 
     local_irq_save(flags);
-    spin_lock_recursive(&console_lock);
+    rspin_lock(&console_lock);
 
     return flags;
 }
 
 void console_unlock_recursive_irqrestore(unsigned long flags)
 {
-    spin_unlock_recursive(&console_lock);
+    rspin_unlock(&console_lock);
     local_irq_restore(flags);
 }
 
@@ -1230,12 +1230,12 @@ int __printk_ratelimit(int ratelimit_ms, int ratelimit_burst)
             char lost_str[8];
             snprintf(lost_str, sizeof(lost_str), "%d", lost);
             /* console_lock may already be acquired by printk(). */
-            spin_lock_recursive(&console_lock);
+            rspin_lock(&console_lock);
             printk_start_of_line("(XEN) ");
             __putstr("printk: ");
             __putstr(lost_str);
             __putstr(" messages suppressed.\n");
-            spin_unlock_recursive(&console_lock);
+            rspin_unlock(&console_lock);
         }
         local_irq_restore(flags);
         return 1;
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index b6b2196ab0..4fcc7e2cde 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -55,12 +55,12 @@ static DEFINE_RSPINLOCK(_pcidevs_lock);
 /* Do not use, as it has no speculation barrier, use pcidevs_lock() instead. */
 void pcidevs_lock_unsafe(void)
 {
-    _spin_lock_recursive(&_pcidevs_lock);
+    _rspin_lock(&_pcidevs_lock);
 }
 
 void pcidevs_unlock(void)
 {
-    spin_unlock_recursive(&_pcidevs_lock);
+    rspin_unlock(&_pcidevs_lock);
 }
 
 bool pcidevs_locked(void)
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index bc320f4e55..85d44a16f5 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -358,8 +358,8 @@ struct sched_unit {
           (v) = (v)->next_in_list )
 
 /* Per-domain lock can be recursively acquired in fault handlers. */
-#define domain_lock(d) spin_lock_recursive(&(d)->domain_lock)
-#define domain_unlock(d) spin_unlock_recursive(&(d)->domain_lock)
+#define domain_lock(d) rspin_lock(&(d)->domain_lock)
+#define domain_unlock(d) rspin_unlock(&(d)->domain_lock)
 
 struct evtchn_port_ops;
 
diff --git a/xen/include/xen/spinlock.h b/xen/include/xen/spinlock.h
index bbf12b93c4..50f6580f52 100644
--- a/xen/include/xen/spinlock.h
+++ b/xen/include/xen/spinlock.h
@@ -210,10 +210,6 @@ int _spin_is_locked(const spinlock_t *lock);
 int _spin_trylock(spinlock_t *lock);
 void _spin_barrier(spinlock_t *lock);
 
-int _spin_trylock_recursive(spinlock_t *lock);
-void _spin_lock_recursive(spinlock_t *lock);
-void _spin_unlock_recursive(spinlock_t *lock);
-
 static always_inline void spin_lock(spinlock_t *l)
 {
     _spin_lock(l);
@@ -268,21 +264,23 @@ static always_inline void spin_lock_if(bool condition, spinlock_t *l)
 #define spin_barrier(l)               _spin_barrier(l)
 
 /*
- * spin_[un]lock_recursive(): Use these forms when the lock can (safely!) be
+ * rspin_[un]lock(): Use these forms when the lock can (safely!) be
  * reentered recursively on the same CPU. All critical regions that may form
  * part of a recursively-nested set must be protected by these forms. If there
  * are any critical regions that cannot form part of such a set, they can use
  * standard spin_[un]lock().
  */
-#define spin_trylock_recursive(l) \
-    lock_evaluate_nospec(_spin_trylock_recursive(l))
+bool _rspin_trylock(rspinlock_t *lock);
+void _rspin_lock(rspinlock_t *lock);
+void _rspin_unlock(rspinlock_t *lock);
 
-static always_inline void spin_lock_recursive(spinlock_t *l)
+static always_inline void rspin_lock(rspinlock_t *lock)
 {
-    _spin_lock_recursive(l);
+    _rspin_lock(lock);
     block_lock_speculation();
 }
 
-#define spin_unlock_recursive(l)      _spin_unlock_recursive(l)
+#define rspin_trylock(l)              lock_evaluate_nospec(_rspin_trylock(l))
+#define rspin_unlock(l)               _rspin_unlock(l)
 
 #endif /* __SPINLOCK_H__ */
-- 
2.35.3



From xen-devel-bounces@lists.xenproject.org Thu Mar 14 07:20:58 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 07:20:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692897.1080559 (Exim 4.92)
	(envelope-from )
	id 1rkfOc-00070P-30; Thu, 14 Mar 2024 07:20:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692897.1080559; Thu, 14 Mar 2024 07:20:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkfOc-0006za-0E; Thu, 14 Mar 2024 07:20:58 +0000
Received: by outflank-mailman (input) for mailman id 692897;
 Thu, 14 Mar 2024 07:20:57 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkfOa-0005cd-VK
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 07:20:56 +0000
Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 658ef96a-e1d3-11ee-afdd-a90da7624cb6;
 Thu, 14 Mar 2024 08:20:55 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [10.150.64.97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out2.suse.de (Postfix) with ESMTPS id 271C01F801;
 Thu, 14 Mar 2024 07:20:55 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id CDFCD13977;
 Thu, 14 Mar 2024 07:20:54 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id EhKxMFal8mVTDgAAD6G6ig
 (envelope-from ); Thu, 14 Mar 2024 07:20:54 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 658ef96a-e1d3-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1710400855; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=CZJrib1UGrzmVSpmgprY0xMWihJMCjOR39gpkTSzqsU=;
	b=dpaeFiBTyGzUg2S/xFMG3QJSOPMci0iY/s+TfqbBPwwlVDibOvhTJGjQ20x81ka4Lual9x
	2ZKVnSUWUZbHkmwDP9JoDyIMYXrUJrxq3nrM6DhdvY6XJClNGfRz4mf3gYcgpTj0LfQ1xg
	oPaUuYHRt5oACbrPijI/NYCpHY0ev/U=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1710400855; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=CZJrib1UGrzmVSpmgprY0xMWihJMCjOR39gpkTSzqsU=;
	b=dpaeFiBTyGzUg2S/xFMG3QJSOPMci0iY/s+TfqbBPwwlVDibOvhTJGjQ20x81ka4Lual9x
	2ZKVnSUWUZbHkmwDP9JoDyIMYXrUJrxq3nrM6DhdvY6XJClNGfRz4mf3gYcgpTj0LfQ1xg
	oPaUuYHRt5oACbrPijI/NYCpHY0ev/U=
From: Juergen Gross 
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini ,
	Wei Liu 
Subject: [PATCH v5 04/13] xen/spinlock: add rspin_[un]lock_irq[save|restore]()
Date: Thu, 14 Mar 2024 08:20:20 +0100
Message-Id: <20240314072029.16937-5-jgross@suse.com>
X-Mailer: git-send-email 2.35.3
In-Reply-To: <20240314072029.16937-1-jgross@suse.com>
References: <20240314072029.16937-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Level: *
Authentication-Results: smtp-out2.suse.de;
	none
X-Spamd-Result: default: False [1.90 / 50.00];
	 ARC_NA(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_MISSING_CHARSET(2.50)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 BROKEN_CONTENT_TYPE(1.50)[];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_SIGNED(0.00)[suse.com:s=susede1];
	 RCPT_COUNT_SEVEN(0.00)[8];
	 MID_CONTAINS_FROM(1.00)[];
	 FUZZY_BLOCKED(0.00)[rspamd.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 RCVD_TLS_ALL(0.00)[];
	 BAYES_HAM(-3.00)[100.00%]
X-Spam-Score: 1.90
X-Spam-Flag: NO

Instead of special casing rspin_lock_irqsave() and
rspin_unlock_irqrestore() for the console lock, add those functions
to spinlock handling and use them where needed.

Signed-off-by: Juergen Gross 
---
V2:
- new patch
V5:
- avoid MISRA violation (Julien Grall)
- keep wrapper functions (Jan Beulich)
---
 xen/common/spinlock.c      | 18 +++++++++++++++++-
 xen/drivers/char/console.c |  6 ++----
 xen/include/xen/spinlock.h |  9 +++++++++
 3 files changed, 28 insertions(+), 5 deletions(-)

diff --git a/xen/common/spinlock.c b/xen/common/spinlock.c
index 11e13e1259..5ef0ac7f89 100644
--- a/xen/common/spinlock.c
+++ b/xen/common/spinlock.c
@@ -475,15 +475,31 @@ void _rspin_lock(rspinlock_t *lock)
     lock->recurse_cnt++;
 }
 
+unsigned long _rspin_lock_irqsave(rspinlock_t *lock)
+{
+    unsigned long flags;
+
+    local_irq_save(flags);
+    _rspin_lock(lock);
+
+    return flags;
+}
+
 void _rspin_unlock(rspinlock_t *lock)
 {
     if ( likely(--lock->recurse_cnt == 0) )
     {
         lock->recurse_cpu = SPINLOCK_NO_CPU;
-        spin_unlock(lock);
+        _spin_unlock(lock);
     }
 }
 
+void _rspin_unlock_irqrestore(rspinlock_t *lock, unsigned long flags)
+{
+    _rspin_unlock(lock);
+    local_irq_restore(flags);
+}
+
 #ifdef CONFIG_DEBUG_LOCK_PROFILE
 
 struct lock_profile_anc {
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index eca17b55b4..ccd5f8cc14 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -1161,16 +1161,14 @@ unsigned long console_lock_recursive_irqsave(void)
 {
     unsigned long flags;
 
-    local_irq_save(flags);
-    rspin_lock(&console_lock);
+    rspin_lock_irqsave(&console_lock, flags);
 
     return flags;
 }
 
 void console_unlock_recursive_irqrestore(unsigned long flags)
 {
-    rspin_unlock(&console_lock);
-    local_irq_restore(flags);
+    rspin_unlock_irqrestore(&console_lock, flags);
 }
 
 void console_force_unlock(void)
diff --git a/xen/include/xen/spinlock.h b/xen/include/xen/spinlock.h
index 50f6580f52..afa24c8e29 100644
--- a/xen/include/xen/spinlock.h
+++ b/xen/include/xen/spinlock.h
@@ -272,7 +272,15 @@ static always_inline void spin_lock_if(bool condition, spinlock_t *l)
  */
 bool _rspin_trylock(rspinlock_t *lock);
 void _rspin_lock(rspinlock_t *lock);
+#define rspin_lock_irqsave(l, f)                                \
+    ({                                                          \
+        BUILD_BUG_ON(sizeof(f) != sizeof(unsigned long));       \
+        ((f) = _rspin_lock_irqsave(l));                         \
+        block_lock_speculation();                               \
+    })
+unsigned long _rspin_lock_irqsave(rspinlock_t *lock);
 void _rspin_unlock(rspinlock_t *lock);
+void _rspin_unlock_irqrestore(rspinlock_t *lock, unsigned long flags);
 
 static always_inline void rspin_lock(rspinlock_t *lock)
 {
@@ -282,5 +290,6 @@ static always_inline void rspin_lock(rspinlock_t *lock)
 
 #define rspin_trylock(l)              lock_evaluate_nospec(_rspin_trylock(l))
 #define rspin_unlock(l)               _rspin_unlock(l)
+#define rspin_unlock_irqrestore(l, f) _rspin_unlock_irqrestore(l, f)
 
 #endif /* __SPINLOCK_H__ */
-- 
2.35.3



From xen-devel-bounces@lists.xenproject.org Thu Mar 14 07:21:04 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 07:21:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692899.1080569 (Exim 4.92)
	(envelope-from )
	id 1rkfOi-0007US-BX; Thu, 14 Mar 2024 07:21:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692899.1080569; Thu, 14 Mar 2024 07:21:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkfOi-0007UI-7r; Thu, 14 Mar 2024 07:21:04 +0000
Received: by outflank-mailman (input) for mailman id 692899;
 Thu, 14 Mar 2024 07:21:02 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkfOg-0005rB-SA
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 07:21:02 +0000
Received: from smtp-out2.suse.de (smtp-out2.suse.de
 [2a07:de40:b251:101:10:150:64:2])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 69000f81-e1d3-11ee-a1ee-f123f15fe8a2;
 Thu, 14 Mar 2024 08:21:01 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [10.150.64.97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out2.suse.de (Postfix) with ESMTPS id CACBB1F79B;
 Thu, 14 Mar 2024 07:21:00 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 7BC6813977;
 Thu, 14 Mar 2024 07:21:00 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id 69SvHFyl8mVWDgAAD6G6ig
 (envelope-from ); Thu, 14 Mar 2024 07:21:00 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 69000f81-e1d3-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1710400860; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=a3Lzu5w3Sdvw06E/H34sX80jbLTV1UigAHpKpIJhJHE=;
	b=NJPhIVfe32Lkx0q3Y/1oQNem7v+szp2DChpY95VPQJ3hiKRJIlLgwLhRJecuw4TxPk9WfB
	vE2/JDXx/D3FSMJjDlWHMWaxdl3DM6pRn6hWCuR29OavCQzxQVlZn81x0Yv52Qe7izL1ht
	piKji4mpTMzF80KV1DJ02X8MoI75exM=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1710400860; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=a3Lzu5w3Sdvw06E/H34sX80jbLTV1UigAHpKpIJhJHE=;
	b=NJPhIVfe32Lkx0q3Y/1oQNem7v+szp2DChpY95VPQJ3hiKRJIlLgwLhRJecuw4TxPk9WfB
	vE2/JDXx/D3FSMJjDlWHMWaxdl3DM6pRn6hWCuR29OavCQzxQVlZn81x0Yv52Qe7izL1ht
	piKji4mpTMzF80KV1DJ02X8MoI75exM=
From: Juergen Gross 
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini ,
	Wei Liu ,
	Alejandro Vallejo ,
	Julien Grall 
Subject: [PATCH v5 05/13] xen/spinlock: make struct lock_profile rspinlock_t aware
Date: Thu, 14 Mar 2024 08:20:21 +0100
Message-Id: <20240314072029.16937-6-jgross@suse.com>
X-Mailer: git-send-email 2.35.3
In-Reply-To: <20240314072029.16937-1-jgross@suse.com>
References: <20240314072029.16937-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Authentication-Results: smtp-out2.suse.de;
	none
X-Spam-Level: 
X-Spam-Score: 0.70
X-Spamd-Result: default: False [0.70 / 50.00];
	 ARC_NA(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_MISSING_CHARSET(2.50)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 BROKEN_CONTENT_TYPE(1.50)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_SIGNED(0.00)[suse.com:s=susede1];
	 NEURAL_HAM_SHORT(-0.20)[-1.000];
	 RCPT_COUNT_SEVEN(0.00)[10];
	 MID_CONTAINS_FROM(1.00)[];
	 FUZZY_BLOCKED(0.00)[rspamd.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 RCVD_TLS_ALL(0.00)[];
	 BAYES_HAM(-3.00)[100.00%]
X-Spam-Flag: NO

Struct lock_profile contains a pointer to the spinlock it is associated
with. Prepare support of differing spinlock_t and rspinlock_t types by
adding a type indicator of the pointer. Use the highest bit of the
block_cnt member for this indicator in order to not grow the struct
while hurting only the slow path with slightly less performant code.
Note that this requires a cast when printing the value in order to be
format compliant.

Signed-off-by: Juergen Gross 
Acked-by: Alejandro Vallejo 
Acked-by: Julien Grall 
---
V2:
- new patch
V5:
- use bool for is_rlock (Julien Grall)
- use unsigned int for lockval in spinlock_profile_print_elem()
  (Jan Beulich)
- don't use anonymous union (Jan Beulich)
---
 xen/common/spinlock.c      | 28 ++++++++++++++++++++--------
 xen/include/xen/spinlock.h | 14 ++++++++++----
 2 files changed, 30 insertions(+), 12 deletions(-)

diff --git a/xen/common/spinlock.c b/xen/common/spinlock.c
index 5ef0ac7f89..0e8b525cec 100644
--- a/xen/common/spinlock.c
+++ b/xen/common/spinlock.c
@@ -538,19 +538,31 @@ static void spinlock_profile_iterate(lock_profile_subfunc *sub, void *par)
 static void cf_check spinlock_profile_print_elem(struct lock_profile *data,
     int32_t type, int32_t idx, void *par)
 {
-    struct spinlock *lock = data->lock;
+    unsigned int cpu;
+    unsigned int lockval;
+
+    if ( data->is_rlock )
+    {
+        cpu = data->ptr.rlock->debug.cpu;
+        lockval = data->ptr.rlock->tickets.head_tail;
+    }
+    else
+    {
+        cpu = data->ptr.lock->debug.cpu;
+        lockval = data->ptr.lock->tickets.head_tail;
+    }
 
     printk("%s ", lock_profile_ancs[type].name);
     if ( type != LOCKPROF_TYPE_GLOBAL )
         printk("%d ", idx);
-    printk("%s: addr=%p, lockval=%08x, ", data->name, lock,
-           lock->tickets.head_tail);
-    if ( lock->debug.cpu == SPINLOCK_NO_CPU )
+    printk("%s: addr=%p, lockval=%08x, ", data->name, data->ptr.lock, lockval);
+    if ( cpu == SPINLOCK_NO_CPU )
         printk("not locked\n");
     else
-        printk("cpu=%d\n", lock->debug.cpu);
-    printk("  lock:%" PRId64 "(%" PRI_stime "), block:%" PRId64 "(%" PRI_stime ")\n",
-           data->lock_cnt, data->time_hold, data->block_cnt, data->time_block);
+        printk("cpu=%u\n", cpu);
+    printk("  lock:%" PRIu64 "(%" PRI_stime "), block:%" PRIu64 "(%" PRI_stime ")\n",
+           data->lock_cnt, data->time_hold, (uint64_t)data->block_cnt,
+           data->time_block);
 }
 
 void cf_check spinlock_profile_printall(unsigned char key)
@@ -680,7 +692,7 @@ static int __init cf_check lock_prof_init(void)
     {
         (*q)->next = lock_profile_glb_q.elem_q;
         lock_profile_glb_q.elem_q = *q;
-        (*q)->lock->profile = *q;
+        (*q)->ptr.lock->profile = *q;
     }
 
     _lock_profile_register_struct(LOCKPROF_TYPE_GLOBAL,
diff --git a/xen/include/xen/spinlock.h b/xen/include/xen/spinlock.h
index afa24c8e29..49c5115f52 100644
--- a/xen/include/xen/spinlock.h
+++ b/xen/include/xen/spinlock.h
@@ -77,13 +77,19 @@ union lock_debug { };
 */
 
 struct spinlock;
+/* Temporary hack until a dedicated struct rspinlock is existing. */
+#define rspinlock spinlock
 
 struct lock_profile {
     struct lock_profile *next;       /* forward link */
     const char          *name;       /* lock name */
-    struct spinlock     *lock;       /* the lock itself */
+    union {
+        struct spinlock *lock;       /* the lock itself */
+        struct rspinlock *rlock;     /* the recursive lock itself */
+    } ptr;
     uint64_t            lock_cnt;    /* # of complete locking ops */
-    uint64_t            block_cnt;   /* # of complete wait for lock */
+    uint64_t            block_cnt:63; /* # of complete wait for lock */
+    bool                is_rlock:1;  /* use rlock pointer */
     s_time_t            time_hold;   /* cumulated lock time */
     s_time_t            time_block;  /* cumulated wait time */
     s_time_t            time_locked; /* system time of last locking */
@@ -95,7 +101,7 @@ struct lock_profile_qhead {
     int32_t                   idx;     /* index for printout */
 };
 
-#define LOCK_PROFILE_(lockname) { .name = #lockname, .lock = &(lockname), }
+#define LOCK_PROFILE_(lockname) { .name = #lockname, .ptr.lock = &(lockname), }
 #define LOCK_PROFILE_PTR_(name)                                               \
     static struct lock_profile * const lock_profile__##name                   \
     __used_section(".lockprofile.data") =                                     \
@@ -128,7 +134,7 @@ struct lock_profile_qhead {
             break;                                                            \
         }                                                                     \
         prof->name = #l;                                                      \
-        prof->lock = &(s)->l;                                                 \
+        prof->ptr.lock = &(s)->l;                                             \
         prof->next = (s)->profile_head.elem_q;                                \
         (s)->profile_head.elem_q = prof;                                      \
     } while( 0 )
-- 
2.35.3



From xen-devel-bounces@lists.xenproject.org Thu Mar 14 07:21:11 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 07:21:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692902.1080579 (Exim 4.92)
	(envelope-from )
	id 1rkfOp-00081o-L6; Thu, 14 Mar 2024 07:21:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692902.1080579; Thu, 14 Mar 2024 07:21:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkfOp-00081A-Hj; Thu, 14 Mar 2024 07:21:11 +0000
Received: by outflank-mailman (input) for mailman id 692902;
 Thu, 14 Mar 2024 07:21:10 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkfOo-0005rB-9L
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 07:21:10 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de
 [2a07:de40:b251:101:10:150:64:1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6d163f8c-e1d3-11ee-a1ee-f123f15fe8a2;
 Thu, 14 Mar 2024 08:21:08 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org
 [IPv6:2a07:de40:b281:104:10:150:64:97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id AA3C021D08;
 Thu, 14 Mar 2024 07:21:06 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 351BF13977;
 Thu, 14 Mar 2024 07:21:06 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id 0aSMC2Kl8mVhDgAAD6G6ig
 (envelope-from ); Thu, 14 Mar 2024 07:21:06 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6d163f8c-e1d3-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1710400867; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=rNOyQPsbL1VDg7jKcqQA3YKjVDmW24LPmpHEEveFp9k=;
	b=lzItKastQ++H1Y9cq6iQBm3AXgqCEJhJCX5+3qAdjdqCspEjCnfcY+qzD5rz7ecsufvA35
	ZuKvP5wN5tQ5ckwJT+8dzc5lvF/8/Aac41Cm6FywPAyLPJIVUic05Usnm1kxEXDjtG0cvv
	9zHmDlLZNsLDc59G2Sqri33awkN6K5Y=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1710400866; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=rNOyQPsbL1VDg7jKcqQA3YKjVDmW24LPmpHEEveFp9k=;
	b=k/EY3VtRlUk3A7O4wluCUPmen2sw5VPKWWQpMlTWzmIlJOelZi65U2n+/utO4o6cYcvVn8
	PWapTz2U3JBJWArNLrKnz6vfDmoIQ+SAObtRsfv4XHCtOMY/W6q2EoK2bqACaBIUvuc2RD
	QojCNCYV/+f4Uk0/EcOuLNjzUTG296I=
From: Juergen Gross 
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Wei Liu ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Tamas K Lengyel ,
	Lukasz Hawrylko ,
	"Daniel P. Smith" ,
	=?UTF-8?q?Mateusz=20M=C3=B3wka?= 
Subject: [PATCH v5 06/13] xen/spinlock: add explicit non-recursive locking functions
Date: Thu, 14 Mar 2024 08:20:22 +0100
Message-Id: <20240314072029.16937-7-jgross@suse.com>
X-Mailer: git-send-email 2.35.3
In-Reply-To: <20240314072029.16937-1-jgross@suse.com>
References: <20240314072029.16937-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Level: 
Authentication-Results: smtp-out1.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b="k/EY3VtR"
X-Spamd-Result: default: False [-1.81 / 50.00];
	 ARC_NA(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 R_DKIM_ALLOW(-0.20)[suse.com:s=susede1];
	 URIBL_BLOCKED(0.00)[suse.com:email,suse.com:dkim];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_MISSING_CHARSET(2.50)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 RCVD_DKIM_ARC_DNSWL_HI(-1.00)[];
	 BROKEN_CONTENT_TYPE(1.50)[];
	 DWL_DNSWL_MED(-2.00)[suse.com:dkim];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_SIGNED(0.00)[suse.com:s=susede1];
	 DKIM_TRACE(0.00)[suse.com:+];
	 MX_GOOD(-0.01)[];
	 RCPT_COUNT_TWELVE(0.00)[16];
	 MID_CONTAINS_FROM(1.00)[];
	 FUZZY_BLOCKED(0.00)[rspamd.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 RCVD_IN_DNSWL_HI(-0.50)[2a07:de40:b281:106:10:150:64:167:received];
	 RCVD_TLS_ALL(0.00)[];
	 BAYES_HAM(-3.00)[99.98%]
X-Spam-Score: -1.81
X-Rspamd-Queue-Id: AA3C021D08
X-Spam-Flag: NO
X-Rspamd-Server: rspamd1.dmz-prg2.suse.org

In order to prepare a type-safe recursive spinlock structure, add
explicitly non-recursive locking functions to be used for non-recursive
locking of spinlocks, which are used recursively, too.

Signed-off-by: Juergen Gross 
Acked-by: Jan Beulich 
---
V2:
- rename functions (Jan Beulich)
- get rid of !! in pcidevs_locked() (Jan Beulich)
V5:
- remove spurious change (Julien Grall)
- add nrspin_lock() description (Julien Grall)
---
 xen/arch/arm/mm.c             |  4 ++--
 xen/arch/x86/domain.c         | 12 ++++++------
 xen/arch/x86/mm.c             | 12 ++++++------
 xen/arch/x86/mm/mem_sharing.c |  8 ++++----
 xen/arch/x86/mm/p2m-pod.c     |  4 ++--
 xen/arch/x86/mm/p2m.c         |  4 ++--
 xen/arch/x86/tboot.c          |  4 ++--
 xen/common/domctl.c           |  4 ++--
 xen/common/grant_table.c      | 10 +++++-----
 xen/common/memory.c           |  4 ++--
 xen/common/numa.c             |  4 ++--
 xen/common/page_alloc.c       | 16 ++++++++--------
 xen/drivers/char/console.c    | 16 ++++++++--------
 xen/include/xen/spinlock.h    | 29 +++++++++++++++++++++++------
 14 files changed, 74 insertions(+), 57 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index b15a18a494..def939172c 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -105,7 +105,7 @@ void share_xen_page_with_guest(struct page_info *page, struct domain *d,
     if ( page_get_owner(page) == d )
         return;
 
-    spin_lock(&d->page_alloc_lock);
+    nrspin_lock(&d->page_alloc_lock);
 
     /*
      * The incremented type count pins as writable or read-only.
@@ -136,7 +136,7 @@ void share_xen_page_with_guest(struct page_info *page, struct domain *d,
         page_list_add_tail(page, &d->xenpage_list);
     }
 
-    spin_unlock(&d->page_alloc_lock);
+    nrspin_unlock(&d->page_alloc_lock);
 }
 
 int xenmem_add_to_physmap_one(
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index a11c55f921..33a2830d9d 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -212,7 +212,7 @@ void dump_pageframe_info(struct domain *d)
     {
         unsigned long total[MASK_EXTR(PGT_type_mask, PGT_type_mask) + 1] = {};
 
-        spin_lock(&d->page_alloc_lock);
+        nrspin_lock(&d->page_alloc_lock);
         page_list_for_each ( page, &d->page_list )
         {
             unsigned int index = MASK_EXTR(page->u.inuse.type_info,
@@ -231,13 +231,13 @@ void dump_pageframe_info(struct domain *d)
                    _p(mfn_x(page_to_mfn(page))),
                    page->count_info, page->u.inuse.type_info);
         }
-        spin_unlock(&d->page_alloc_lock);
+        nrspin_unlock(&d->page_alloc_lock);
     }
 
     if ( is_hvm_domain(d) )
         p2m_pod_dump_data(d);
 
-    spin_lock(&d->page_alloc_lock);
+    nrspin_lock(&d->page_alloc_lock);
 
     page_list_for_each ( page, &d->xenpage_list )
     {
@@ -253,7 +253,7 @@ void dump_pageframe_info(struct domain *d)
                page->count_info, page->u.inuse.type_info);
     }
 
-    spin_unlock(&d->page_alloc_lock);
+    nrspin_unlock(&d->page_alloc_lock);
 }
 
 void update_guest_memory_policy(struct vcpu *v,
@@ -2448,10 +2448,10 @@ int domain_relinquish_resources(struct domain *d)
             d->arch.auto_unmask = 0;
         }
 
-        spin_lock(&d->page_alloc_lock);
+        nrspin_lock(&d->page_alloc_lock);
         page_list_splice(&d->arch.relmem_list, &d->page_list);
         INIT_PAGE_LIST_HEAD(&d->arch.relmem_list);
-        spin_unlock(&d->page_alloc_lock);
+        nrspin_unlock(&d->page_alloc_lock);
 
     PROGRESS(xen):
 
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 62f5b811bb..b4d125db39 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -482,7 +482,7 @@ void share_xen_page_with_guest(struct page_info *page, struct domain *d,
 
     set_gpfn_from_mfn(mfn_x(page_to_mfn(page)), INVALID_M2P_ENTRY);
 
-    spin_lock(&d->page_alloc_lock);
+    nrspin_lock(&d->page_alloc_lock);
 
     /* The incremented type count pins as writable or read-only. */
     page->u.inuse.type_info =
@@ -502,7 +502,7 @@ void share_xen_page_with_guest(struct page_info *page, struct domain *d,
         page_list_add_tail(page, &d->xenpage_list);
     }
 
-    spin_unlock(&d->page_alloc_lock);
+    nrspin_unlock(&d->page_alloc_lock);
 }
 
 void make_cr3(struct vcpu *v, mfn_t mfn)
@@ -3597,11 +3597,11 @@ long do_mmuext_op(
             {
                 bool drop_ref;
 
-                spin_lock(&pg_owner->page_alloc_lock);
+                nrspin_lock(&pg_owner->page_alloc_lock);
                 drop_ref = (pg_owner->is_dying &&
                             test_and_clear_bit(_PGT_pinned,
                                                &page->u.inuse.type_info));
-                spin_unlock(&pg_owner->page_alloc_lock);
+                nrspin_unlock(&pg_owner->page_alloc_lock);
                 if ( drop_ref )
                 {
         pin_drop:
@@ -4424,7 +4424,7 @@ int steal_page(
      * that it might be upon return from alloc_domheap_pages with
      * MEMF_no_owner set.
      */
-    spin_lock(&d->page_alloc_lock);
+    nrspin_lock(&d->page_alloc_lock);
 
     BUG_ON(page->u.inuse.type_info & (PGT_count_mask | PGT_locked |
                                       PGT_pinned));
@@ -4436,7 +4436,7 @@ int steal_page(
     if ( !(memflags & MEMF_no_refcount) && !domain_adjust_tot_pages(d, -1) )
         drop_dom_ref = true;
 
-    spin_unlock(&d->page_alloc_lock);
+    nrspin_unlock(&d->page_alloc_lock);
 
     if ( unlikely(drop_dom_ref) )
         put_domain(d);
diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index f58576c702..da28266ef0 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -740,11 +740,11 @@ static int page_make_private(struct domain *d, struct page_info *page)
     if ( !get_page(page, dom_cow) )
         return -EINVAL;
 
-    spin_lock(&d->page_alloc_lock);
+    nrspin_lock(&d->page_alloc_lock);
 
     if ( d->is_dying )
     {
-        spin_unlock(&d->page_alloc_lock);
+        nrspin_unlock(&d->page_alloc_lock);
         put_page(page);
         return -EBUSY;
     }
@@ -752,7 +752,7 @@ static int page_make_private(struct domain *d, struct page_info *page)
     expected_type = (PGT_shared_page | PGT_validated | PGT_locked | 2);
     if ( page->u.inuse.type_info != expected_type )
     {
-        spin_unlock(&d->page_alloc_lock);
+        nrspin_unlock(&d->page_alloc_lock);
         put_page(page);
         return -EEXIST;
     }
@@ -769,7 +769,7 @@ static int page_make_private(struct domain *d, struct page_info *page)
     if ( domain_adjust_tot_pages(d, 1) == 1 )
         get_knownalive_domain(d);
     page_list_add_tail(page, &d->page_list);
-    spin_unlock(&d->page_alloc_lock);
+    nrspin_unlock(&d->page_alloc_lock);
 
     put_page(page);
 
diff --git a/xen/arch/x86/mm/p2m-pod.c b/xen/arch/x86/mm/p2m-pod.c
index 65d31e5523..515a8c98a5 100644
--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -27,7 +27,7 @@
 static always_inline void lock_page_alloc(struct p2m_domain *p2m)
 {
     page_alloc_mm_pre_lock(p2m->domain);
-    spin_lock(&(p2m->domain->page_alloc_lock));
+    nrspin_lock(&(p2m->domain->page_alloc_lock));
     page_alloc_mm_post_lock(p2m->domain,
                             p2m->domain->arch.page_alloc_unlock_level);
 }
@@ -35,7 +35,7 @@ static always_inline void lock_page_alloc(struct p2m_domain *p2m)
 static inline void unlock_page_alloc(struct p2m_domain *p2m)
 {
     page_alloc_mm_unlock(p2m->domain->arch.page_alloc_unlock_level);
-    spin_unlock(&(p2m->domain->page_alloc_lock));
+    nrspin_unlock(&(p2m->domain->page_alloc_lock));
 }
 
 /*
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index ca24cd4a67..6bdff9aee9 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -2228,7 +2228,7 @@ void audit_p2m(struct domain *d,
 
     /* Audit part two: walk the domain's page allocation list, checking
      * the m2p entries. */
-    spin_lock(&d->page_alloc_lock);
+    nrspin_lock(&d->page_alloc_lock);
     page_list_for_each ( page, &d->page_list )
     {
         mfn = mfn_x(page_to_mfn(page));
@@ -2280,7 +2280,7 @@ void audit_p2m(struct domain *d,
         P2M_PRINTK("OK: mfn=%#lx, gfn=%#lx, p2mfn=%#lx\n",
                        mfn, gfn, mfn_x(p2mfn));
     }
-    spin_unlock(&d->page_alloc_lock);
+    nrspin_unlock(&d->page_alloc_lock);
 
     pod_unlock(p2m);
     p2m_unlock(p2m);
diff --git a/xen/arch/x86/tboot.c b/xen/arch/x86/tboot.c
index 4c254b4e34..ba0700d2d5 100644
--- a/xen/arch/x86/tboot.c
+++ b/xen/arch/x86/tboot.c
@@ -205,14 +205,14 @@ static void tboot_gen_domain_integrity(const uint8_t key[TB_KEY_SIZE],
             continue;
         printk("MACing Domain %u\n", d->domain_id);
 
-        spin_lock(&d->page_alloc_lock);
+        nrspin_lock(&d->page_alloc_lock);
         page_list_for_each(page, &d->page_list)
         {
             void *pg = __map_domain_page(page);
             vmac_update(pg, PAGE_SIZE, &ctx);
             unmap_domain_page(pg);
         }
-        spin_unlock(&d->page_alloc_lock);
+        nrspin_unlock(&d->page_alloc_lock);
 
         if ( is_iommu_enabled(d) && is_vtd )
         {
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index f5a71ee5f7..cb62b18a9d 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -621,14 +621,14 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
     {
         uint64_t new_max = op->u.max_mem.max_memkb >> (PAGE_SHIFT - 10);
 
-        spin_lock(&d->page_alloc_lock);
+        nrspin_lock(&d->page_alloc_lock);
         /*
          * NB. We removed a check that new_max >= current tot_pages; this means
          * that the domain will now be allowed to "ratchet" down to new_max. In
          * the meantime, while tot > max, all new allocations are disallowed.
          */
         d->max_pages = min(new_max, (uint64_t)(typeof(d->max_pages))-1);
-        spin_unlock(&d->page_alloc_lock);
+        nrspin_unlock(&d->page_alloc_lock);
         break;
     }
 
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 7708930882..e98e9da520 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -2376,7 +2376,7 @@ gnttab_transfer(
             mfn = page_to_mfn(page);
         }
 
-        spin_lock(&e->page_alloc_lock);
+        nrspin_lock(&e->page_alloc_lock);
 
         /*
          * Check that 'e' will accept the page and has reservation
@@ -2387,7 +2387,7 @@ gnttab_transfer(
              unlikely(domain_tot_pages(e) >= e->max_pages) ||
              unlikely(!(e->tot_pages + 1)) )
         {
-            spin_unlock(&e->page_alloc_lock);
+            nrspin_unlock(&e->page_alloc_lock);
 
             if ( e->is_dying )
                 gdprintk(XENLOG_INFO, "Transferee d%d is dying\n",
@@ -2411,7 +2411,7 @@ gnttab_transfer(
          * safely drop the lock and re-aquire it later to add page to the
          * pagelist.
          */
-        spin_unlock(&e->page_alloc_lock);
+        nrspin_unlock(&e->page_alloc_lock);
         okay = gnttab_prepare_for_transfer(e, d, gop.ref);
 
         /*
@@ -2427,9 +2427,9 @@ gnttab_transfer(
              * Need to grab this again to safely free our "reserved"
              * page in the page total
              */
-            spin_lock(&e->page_alloc_lock);
+            nrspin_lock(&e->page_alloc_lock);
             drop_dom_ref = !domain_adjust_tot_pages(e, -1);
-            spin_unlock(&e->page_alloc_lock);
+            nrspin_unlock(&e->page_alloc_lock);
 
             if ( okay /* i.e. e->is_dying due to the surrounding if() */ )
                 gdprintk(XENLOG_INFO, "Transferee d%d is now dying\n",
diff --git a/xen/common/memory.c b/xen/common/memory.c
index b3b05c2ec0..b4593f5f45 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -770,10 +770,10 @@ static long memory_exchange(XEN_GUEST_HANDLE_PARAM(xen_memory_exchange_t) arg)
                               (1UL << in_chunk_order)) -
                              (j * (1UL << exch.out.extent_order)));
 
-                spin_lock(&d->page_alloc_lock);
+                nrspin_lock(&d->page_alloc_lock);
                 drop_dom_ref = (dec_count &&
                                 !domain_adjust_tot_pages(d, -dec_count));
-                spin_unlock(&d->page_alloc_lock);
+                nrspin_unlock(&d->page_alloc_lock);
 
                 if ( drop_dom_ref )
                     put_domain(d);
diff --git a/xen/common/numa.c b/xen/common/numa.c
index 6374ba1721..28a09766fa 100644
--- a/xen/common/numa.c
+++ b/xen/common/numa.c
@@ -719,13 +719,13 @@ static void cf_check dump_numa(unsigned char key)
 
         memset(page_num_node, 0, sizeof(page_num_node));
 
-        spin_lock(&d->page_alloc_lock);
+        nrspin_lock(&d->page_alloc_lock);
         page_list_for_each ( page, &d->page_list )
         {
             i = page_to_nid(page);
             page_num_node[i]++;
         }
-        spin_unlock(&d->page_alloc_lock);
+        nrspin_unlock(&d->page_alloc_lock);
 
         for_each_online_node ( i )
             printk("    Node %u: %u\n", i, page_num_node[i]);
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index b4e0ef3a4c..20238015ed 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -514,7 +514,7 @@ int domain_set_outstanding_pages(struct domain *d, unsigned long pages)
      * must always take the global heap_lock rather than only in the much
      * rarer case that d->outstanding_pages is non-zero
      */
-    spin_lock(&d->page_alloc_lock);
+    nrspin_lock(&d->page_alloc_lock);
     spin_lock(&heap_lock);
 
     /* pages==0 means "unset" the claim. */
@@ -560,7 +560,7 @@ int domain_set_outstanding_pages(struct domain *d, unsigned long pages)
 
 out:
     spin_unlock(&heap_lock);
-    spin_unlock(&d->page_alloc_lock);
+    nrspin_unlock(&d->page_alloc_lock);
     return ret;
 }
 
@@ -2346,7 +2346,7 @@ int assign_pages(
     int rc = 0;
     unsigned int i;
 
-    spin_lock(&d->page_alloc_lock);
+    nrspin_lock(&d->page_alloc_lock);
 
     if ( unlikely(d->is_dying) )
     {
@@ -2428,7 +2428,7 @@ int assign_pages(
     }
 
  out:
-    spin_unlock(&d->page_alloc_lock);
+    nrspin_unlock(&d->page_alloc_lock);
     return rc;
 }
 
@@ -2907,9 +2907,9 @@ mfn_t acquire_reserved_page(struct domain *d, unsigned int memflags)
     ASSERT_ALLOC_CONTEXT();
 
     /* Acquire a page from reserved page list(resv_page_list). */
-    spin_lock(&d->page_alloc_lock);
+    nrspin_lock(&d->page_alloc_lock);
     page = page_list_remove_head(&d->resv_page_list);
-    spin_unlock(&d->page_alloc_lock);
+    nrspin_unlock(&d->page_alloc_lock);
     if ( unlikely(!page) )
         return INVALID_MFN;
 
@@ -2928,9 +2928,9 @@ mfn_t acquire_reserved_page(struct domain *d, unsigned int memflags)
      */
     unprepare_staticmem_pages(page, 1, false);
  fail:
-    spin_lock(&d->page_alloc_lock);
+    nrspin_lock(&d->page_alloc_lock);
     page_list_add_tail(page, &d->resv_page_list);
-    spin_unlock(&d->page_alloc_lock);
+    nrspin_unlock(&d->page_alloc_lock);
     return INVALID_MFN;
 }
 #endif
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index ccd5f8cc14..22f50fc617 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -368,9 +368,9 @@ long read_console_ring(struct xen_sysctl_readconsole *op)
 
     if ( op->clear )
     {
-        spin_lock_irq(&console_lock);
+        nrspin_lock_irq(&console_lock);
         conringc = p - c > conring_size ? p - conring_size : c;
-        spin_unlock_irq(&console_lock);
+        nrspin_unlock_irq(&console_lock);
     }
 
     op->count = sofar;
@@ -638,7 +638,7 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer,
         if ( is_hardware_domain(cd) )
         {
             /* Use direct console output as it could be interactive */
-            spin_lock_irq(&console_lock);
+            nrspin_lock_irq(&console_lock);
 
             console_serial_puts(kbuf, kcount);
             video_puts(kbuf, kcount);
@@ -659,7 +659,7 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer,
                 tasklet_schedule(¬ify_dom0_con_ring_tasklet);
             }
 
-            spin_unlock_irq(&console_lock);
+            nrspin_unlock_irq(&console_lock);
         }
         else
         {
@@ -1026,9 +1026,9 @@ void __init console_init_preirq(void)
     pv_console_set_rx_handler(serial_rx);
 
     /* HELLO WORLD --- start-of-day banner text. */
-    spin_lock(&console_lock);
+    nrspin_lock(&console_lock);
     __putstr(xen_banner());
-    spin_unlock(&console_lock);
+    nrspin_unlock(&console_lock);
     printk("Xen version %d.%d%s (%s@%s) (%s) %s %s\n",
            xen_major_version(), xen_minor_version(), xen_extra_version(),
            xen_compile_by(), xen_compile_domain(), xen_compiler(),
@@ -1065,13 +1065,13 @@ void __init console_init_ring(void)
     }
     opt_conring_size = PAGE_SIZE << order;
 
-    spin_lock_irqsave(&console_lock, flags);
+    nrspin_lock_irqsave(&console_lock, flags);
     for ( i = conringc ; i != conringp; i++ )
         ring[i & (opt_conring_size - 1)] = conring[i & (conring_size - 1)];
     conring = ring;
     smp_wmb(); /* Allow users of console_force_unlock() to see larger buffer. */
     conring_size = opt_conring_size;
-    spin_unlock_irqrestore(&console_lock, flags);
+    nrspin_unlock_irqrestore(&console_lock, flags);
 
     printk("Allocated console ring of %u KiB.\n", opt_conring_size >> 10);
 }
diff --git a/xen/include/xen/spinlock.h b/xen/include/xen/spinlock.h
index 49c5115f52..f912fa968c 100644
--- a/xen/include/xen/spinlock.h
+++ b/xen/include/xen/spinlock.h
@@ -102,6 +102,9 @@ struct lock_profile_qhead {
 };
 
 #define LOCK_PROFILE_(lockname) { .name = #lockname, .ptr.lock = &(lockname), }
+#define RLOCK_PROFILE_(lockname) { .name = #lockname,                         \
+                                   .ptr.rlock = &(lockname),                  \
+                                   .is_rlock = true, }
 #define LOCK_PROFILE_PTR_(name)                                               \
     static struct lock_profile * const lock_profile__##name                   \
     __used_section(".lockprofile.data") =                                     \
@@ -118,10 +121,10 @@ struct lock_profile_qhead {
     LOCK_PROFILE_PTR_(l)
 #define DEFINE_RSPINLOCK(l)                                                   \
     rspinlock_t l = SPIN_LOCK_UNLOCKED_(NULL);                                \
-    static struct lock_profile lock_profile_data__##l = LOCK_PROFILE_(l);     \
+    static struct lock_profile lock_profile_data__##l = RLOCK_PROFILE_(l);    \
     LOCK_PROFILE_PTR_(l)
 
-#define spin_lock_init_prof__(s, l, locktype)                                 \
+#define spin_lock_init_prof__(s, l, lockptr, locktype, isr)                   \
     do {                                                                      \
         struct lock_profile *prof;                                            \
         prof = xzalloc(struct lock_profile);                                  \
@@ -134,13 +137,16 @@ struct lock_profile_qhead {
             break;                                                            \
         }                                                                     \
         prof->name = #l;                                                      \
-        prof->ptr.lock = &(s)->l;                                             \
+        prof->ptr.lockptr = &(s)->l;                                          \
+        prof->is_rlock = isr;                                                 \
         prof->next = (s)->profile_head.elem_q;                                \
         (s)->profile_head.elem_q = prof;                                      \
     } while( 0 )
 
-#define spin_lock_init_prof(s, l) spin_lock_init_prof__(s, l, spinlock_t)
-#define rspin_lock_init_prof(s, l) spin_lock_init_prof__(s, l, rspinlock_t)
+#define spin_lock_init_prof(s, l)                                             \
+    spin_lock_init_prof__(s, l, lock, spinlock_t, false)
+#define rspin_lock_init_prof(s, l)                                            \
+    spin_lock_init_prof__(s, l, rlock, rspinlock_t, true)
 
 void _lock_profile_register_struct(
     int32_t type, struct lock_profile_qhead *qhead, int32_t idx);
@@ -274,7 +280,10 @@ static always_inline void spin_lock_if(bool condition, spinlock_t *l)
  * reentered recursively on the same CPU. All critical regions that may form
  * part of a recursively-nested set must be protected by these forms. If there
  * are any critical regions that cannot form part of such a set, they can use
- * standard spin_[un]lock().
+ * nrspin_[un]lock().
+ * The nrspin_[un]lock() forms act the same way as normal spin_[un]lock()
+ * calls, but operate on rspinlock_t locks. nrspin_lock() and rspin_lock()
+ * calls are blocking to each other for a specific lock even on the same cpu.
  */
 bool _rspin_trylock(rspinlock_t *lock);
 void _rspin_lock(rspinlock_t *lock);
@@ -298,4 +307,12 @@ static always_inline void rspin_lock(rspinlock_t *lock)
 #define rspin_unlock(l)               _rspin_unlock(l)
 #define rspin_unlock_irqrestore(l, f) _rspin_unlock_irqrestore(l, f)
 
+#define nrspin_trylock(l)    spin_trylock(l)
+#define nrspin_lock(l)       spin_lock(l)
+#define nrspin_unlock(l)     spin_unlock(l)
+#define nrspin_lock_irq(l)   spin_lock_irq(l)
+#define nrspin_unlock_irq(l) spin_unlock_irq(l)
+#define nrspin_lock_irqsave(l, f)      spin_lock_irqsave(l, f)
+#define nrspin_unlock_irqrestore(l, f) spin_unlock_irqrestore(l, f)
+
 #endif /* __SPINLOCK_H__ */
-- 
2.35.3



From xen-devel-bounces@lists.xenproject.org Thu Mar 14 07:21:15 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 07:21:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692905.1080589 (Exim 4.92)
	(envelope-from )
	id 1rkfOt-0008SW-3I; Thu, 14 Mar 2024 07:21:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692905.1080589; Thu, 14 Mar 2024 07:21:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkfOs-0008Rv-VK; Thu, 14 Mar 2024 07:21:14 +0000
Received: by outflank-mailman (input) for mailman id 692905;
 Thu, 14 Mar 2024 07:21:13 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkfOr-0005cd-F2
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 07:21:13 +0000
Received: from smtp-out2.suse.de (smtp-out2.suse.de
 [2a07:de40:b251:101:10:150:64:2])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6fd588df-e1d3-11ee-afdd-a90da7624cb6;
 Thu, 14 Mar 2024 08:21:12 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [10.150.64.97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out2.suse.de (Postfix) with ESMTPS id 5FE081F801;
 Thu, 14 Mar 2024 07:21:12 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 1D26F13977;
 Thu, 14 Mar 2024 07:21:12 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id B1msBWil8mVpDgAAD6G6ig
 (envelope-from ); Thu, 14 Mar 2024 07:21:12 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6fd588df-e1d3-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1710400872; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=azHliw2rnZkSZFAFqf4pqY8Nf/40zwEm0vTijoAtrF8=;
	b=bLfXCDM6/ugPfJHYGhkYNXmUNuQhqN1fcoBqGpRZQtiRDa7Qcrm1cUWlwtidOlh+4z5QF5
	JJ4JEdduNM51KUNlqVzr/lVwdlkI6qEfUDeNWCT959WduonddW/9MYoMjs4OWY8TPH7gF+
	qiP1lfVxD0me8cAG9LY3+SimxaYny8A=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1710400872; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=azHliw2rnZkSZFAFqf4pqY8Nf/40zwEm0vTijoAtrF8=;
	b=bLfXCDM6/ugPfJHYGhkYNXmUNuQhqN1fcoBqGpRZQtiRDa7Qcrm1cUWlwtidOlh+4z5QF5
	JJ4JEdduNM51KUNlqVzr/lVwdlkI6qEfUDeNWCT959WduonddW/9MYoMjs4OWY8TPH7gF+
	qiP1lfVxD0me8cAG9LY3+SimxaYny8A=
From: Juergen Gross 
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini ,
	Wei Liu 
Subject: [PATCH v5 07/13] xen/spinlock: add another function level
Date: Thu, 14 Mar 2024 08:20:23 +0100
Message-Id: <20240314072029.16937-8-jgross@suse.com>
X-Mailer: git-send-email 2.35.3
In-Reply-To: <20240314072029.16937-1-jgross@suse.com>
References: <20240314072029.16937-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Level: *
Authentication-Results: smtp-out2.suse.de;
	none
X-Spamd-Result: default: False [1.90 / 50.00];
	 ARC_NA(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 URIBL_BLOCKED(0.00)[suse.com:email];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_MISSING_CHARSET(2.50)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 BROKEN_CONTENT_TYPE(1.50)[];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_SIGNED(0.00)[suse.com:s=susede1];
	 RCPT_COUNT_SEVEN(0.00)[8];
	 MID_CONTAINS_FROM(1.00)[];
	 FUZZY_BLOCKED(0.00)[rspamd.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 RCVD_TLS_ALL(0.00)[];
	 BAYES_HAM(-3.00)[100.00%]
X-Spam-Score: 1.90
X-Spam-Flag: NO

Add another function level in spinlock.c hiding the spinlock_t layout
from the low level locking code.

This is done in preparation of introducing rspinlock_t for recursive
locks without having to duplicate all of the locking code.

Signed-off-by: Juergen Gross 
---
V2:
- new patch
V5:
- don't regress spin_is_locked() for rspin-lock (Jan Beulich)
- use bool as return type of spin_is_locked_common() and
  spin_trylock_common() (Jan Beulich)
---
 xen/common/spinlock.c      | 103 ++++++++++++++++++++++++-------------
 xen/include/xen/spinlock.h |   1 +
 2 files changed, 68 insertions(+), 36 deletions(-)

diff --git a/xen/common/spinlock.c b/xen/common/spinlock.c
index 0e8b525cec..648393d95f 100644
--- a/xen/common/spinlock.c
+++ b/xen/common/spinlock.c
@@ -261,29 +261,31 @@ void spin_debug_disable(void)
 
 #ifdef CONFIG_DEBUG_LOCK_PROFILE
 
+#define LOCK_PROFILE_PAR lock->profile
 #define LOCK_PROFILE_REL                                                     \
-    if ( lock->profile )                                                     \
+    if ( profile )                                                           \
     {                                                                        \
-        lock->profile->time_hold += NOW() - lock->profile->time_locked;      \
-        lock->profile->lock_cnt++;                                           \
+        profile->time_hold += NOW() - profile->time_locked;                  \
+        profile->lock_cnt++;                                                 \
     }
 #define LOCK_PROFILE_VAR(var, val)    s_time_t var = (val)
 #define LOCK_PROFILE_BLOCK(var)       var = var ? : NOW()
 #define LOCK_PROFILE_BLKACC(tst, val)                                        \
     if ( tst )                                                               \
     {                                                                        \
-        lock->profile->time_block += lock->profile->time_locked - (val);     \
-        lock->profile->block_cnt++;                                          \
+        profile->time_block += profile->time_locked - (val);                 \
+        profile->block_cnt++;                                                \
     }
 #define LOCK_PROFILE_GOT(val)                                                \
-    if ( lock->profile )                                                     \
+    if ( profile )                                                           \
     {                                                                        \
-        lock->profile->time_locked = NOW();                                  \
+        profile->time_locked = NOW();                                        \
         LOCK_PROFILE_BLKACC(val, val);                                       \
     }
 
 #else
 
+#define LOCK_PROFILE_PAR NULL
 #define LOCK_PROFILE_REL
 #define LOCK_PROFILE_VAR(var, val)
 #define LOCK_PROFILE_BLOCK(var)
@@ -307,17 +309,18 @@ static always_inline uint16_t observe_head(const spinlock_tickets_t *t)
     return read_atomic(&t->head);
 }
 
-static void always_inline spin_lock_common(spinlock_t *lock,
+static void always_inline spin_lock_common(spinlock_tickets_t *t,
+                                           union lock_debug *debug,
+                                           struct lock_profile *profile,
                                            void (*cb)(void *data), void *data)
 {
     spinlock_tickets_t tickets = SPINLOCK_TICKET_INC;
     LOCK_PROFILE_VAR(block, 0);
 
-    check_lock(&lock->debug, false);
+    check_lock(debug, false);
     preempt_disable();
-    tickets.head_tail = arch_fetch_and_add(&lock->tickets.head_tail,
-                                           tickets.head_tail);
-    while ( tickets.tail != observe_head(&lock->tickets) )
+    tickets.head_tail = arch_fetch_and_add(&t->head_tail, tickets.head_tail);
+    while ( tickets.tail != observe_head(t) )
     {
         LOCK_PROFILE_BLOCK(block);
         if ( cb )
@@ -325,18 +328,19 @@ static void always_inline spin_lock_common(spinlock_t *lock,
         arch_lock_relax();
     }
     arch_lock_acquire_barrier();
-    got_lock(&lock->debug);
+    got_lock(debug);
     LOCK_PROFILE_GOT(block);
 }
 
 void _spin_lock(spinlock_t *lock)
 {
-    spin_lock_common(lock, NULL, NULL);
+    spin_lock_common(&lock->tickets, &lock->debug, LOCK_PROFILE_PAR, NULL,
+                     NULL);
 }
 
 void _spin_lock_cb(spinlock_t *lock, void (*cb)(void *data), void *data)
 {
-    spin_lock_common(lock, cb, data);
+    spin_lock_common(&lock->tickets, &lock->debug, LOCK_PROFILE_PAR, cb, data);
 }
 
 void _spin_lock_irq(spinlock_t *lock)
@@ -355,16 +359,23 @@ unsigned long _spin_lock_irqsave(spinlock_t *lock)
     return flags;
 }
 
-void _spin_unlock(spinlock_t *lock)
+static void always_inline spin_unlock_common(spinlock_tickets_t *t,
+                                             union lock_debug *debug,
+                                             struct lock_profile *profile)
 {
     LOCK_PROFILE_REL;
-    rel_lock(&lock->debug);
+    rel_lock(debug);
     arch_lock_release_barrier();
-    add_sized(&lock->tickets.head, 1);
+    add_sized(&t->head, 1);
     arch_lock_signal();
     preempt_enable();
 }
 
+void _spin_unlock(spinlock_t *lock)
+{
+    spin_unlock_common(&lock->tickets, &lock->debug, LOCK_PROFILE_PAR);
+}
+
 void _spin_unlock_irq(spinlock_t *lock)
 {
     _spin_unlock(lock);
@@ -377,6 +388,11 @@ void _spin_unlock_irqrestore(spinlock_t *lock, unsigned long flags)
     local_irq_restore(flags);
 }
 
+static bool always_inline spin_is_locked_common(const spinlock_tickets_t *t)
+{
+    return t->head != t->tail;
+}
+
 int _spin_is_locked(const spinlock_t *lock)
 {
     /*
@@ -385,57 +401,70 @@ int _spin_is_locked(const spinlock_t *lock)
      * ASSERT()s and alike.
      */
     return lock->recurse_cpu == SPINLOCK_NO_CPU
-           ? lock->tickets.head != lock->tickets.tail
+           ? spin_is_locked_common(&lock->tickets)
            : lock->recurse_cpu == smp_processor_id();
 }
 
-int _spin_trylock(spinlock_t *lock)
+static bool always_inline spin_trylock_common(spinlock_tickets_t *t,
+                                              union lock_debug *debug,
+                                              struct lock_profile *profile)
 {
     spinlock_tickets_t old, new;
 
     preempt_disable();
-    check_lock(&lock->debug, true);
-    old = observe_lock(&lock->tickets);
+    check_lock(debug, true);
+    old = observe_lock(t);
     if ( old.head != old.tail )
     {
         preempt_enable();
-        return 0;
+        return false;
     }
     new = old;
     new.tail++;
-    if ( cmpxchg(&lock->tickets.head_tail,
-                 old.head_tail, new.head_tail) != old.head_tail )
+    if ( cmpxchg(&t->head_tail, old.head_tail, new.head_tail) != old.head_tail )
     {
         preempt_enable();
-        return 0;
+        return false;
     }
     /*
      * cmpxchg() is a full barrier so no need for an
      * arch_lock_acquire_barrier().
      */
-    got_lock(&lock->debug);
+    got_lock(debug);
     LOCK_PROFILE_GOT(0);
 
-    return 1;
+    return true;
 }
 
-void _spin_barrier(spinlock_t *lock)
+int _spin_trylock(spinlock_t *lock)
+{
+    return spin_trylock_common(&lock->tickets, &lock->debug, LOCK_PROFILE_PAR);
+}
+
+static void always_inline spin_barrier_common(spinlock_tickets_t *t,
+                                              union lock_debug *debug,
+                                              struct lock_profile *profile)
 {
     spinlock_tickets_t sample;
     LOCK_PROFILE_VAR(block, NOW());
 
-    check_barrier(&lock->debug);
+    check_barrier(debug);
     smp_mb();
-    sample = observe_lock(&lock->tickets);
+    sample = observe_lock(t);
     if ( sample.head != sample.tail )
     {
-        while ( observe_head(&lock->tickets) == sample.head )
+        while ( observe_head(t) == sample.head )
             arch_lock_relax();
-        LOCK_PROFILE_BLKACC(lock->profile, block);
+        LOCK_PROFILE_BLKACC(profile, block);
     }
     smp_mb();
 }
 
+void _spin_barrier(spinlock_t *lock)
+{
+    spin_barrier_common(&lock->tickets, &lock->debug, LOCK_PROFILE_PAR);
+}
+
 bool _rspin_trylock(rspinlock_t *lock)
 {
     unsigned int cpu = smp_processor_id();
@@ -448,7 +477,8 @@ bool _rspin_trylock(rspinlock_t *lock)
 
     if ( likely(lock->recurse_cpu != cpu) )
     {
-        if ( !_spin_trylock(lock) )
+        if ( !spin_trylock_common(&lock->tickets, &lock->debug,
+                                  LOCK_PROFILE_PAR) )
             return false;
         lock->recurse_cpu = cpu;
     }
@@ -466,7 +496,8 @@ void _rspin_lock(rspinlock_t *lock)
 
     if ( likely(lock->recurse_cpu != cpu) )
     {
-        _spin_lock(lock);
+        spin_lock_common(&lock->tickets, &lock->debug, LOCK_PROFILE_PAR, NULL,
+                         NULL);
         lock->recurse_cpu = cpu;
     }
 
@@ -490,7 +521,7 @@ void _rspin_unlock(rspinlock_t *lock)
     if ( likely(--lock->recurse_cnt == 0) )
     {
         lock->recurse_cpu = SPINLOCK_NO_CPU;
-        _spin_unlock(lock);
+        spin_unlock_common(&lock->tickets, &lock->debug, LOCK_PROFILE_PAR);
     }
 }
 
diff --git a/xen/include/xen/spinlock.h b/xen/include/xen/spinlock.h
index f912fa968c..5b20b11db6 100644
--- a/xen/include/xen/spinlock.h
+++ b/xen/include/xen/spinlock.h
@@ -165,6 +165,7 @@ extern void cf_check spinlock_profile_reset(unsigned char key);
 #else
 
 struct lock_profile_qhead { };
+struct lock_profile { };
 
 #define SPIN_LOCK_UNLOCKED {                                                  \
     .recurse_cpu = SPINLOCK_NO_CPU,                                           \
-- 
2.35.3



From xen-devel-bounces@lists.xenproject.org Thu Mar 14 07:21:21 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 07:21:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692906.1080599 (Exim 4.92)
	(envelope-from )
	id 1rkfOz-0000WL-CK; Thu, 14 Mar 2024 07:21:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692906.1080599; Thu, 14 Mar 2024 07:21:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkfOz-0000WC-8O; Thu, 14 Mar 2024 07:21:21 +0000
Received: by outflank-mailman (input) for mailman id 692906;
 Thu, 14 Mar 2024 07:21:20 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkfOy-0005rB-8A
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 07:21:20 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 734e3892-e1d3-11ee-a1ee-f123f15fe8a2;
 Thu, 14 Mar 2024 08:21:18 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org
 [IPv6:2a07:de40:b281:104:10:150:64:97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id 2476C21CCF;
 Thu, 14 Mar 2024 07:21:18 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id C8A2913977;
 Thu, 14 Mar 2024 07:21:17 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id 2JR4L22l8mVvDgAAD6G6ig
 (envelope-from ); Thu, 14 Mar 2024 07:21:17 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 734e3892-e1d3-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1710400878; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=RyZIS9vv4iGwmrp5sN5jilaqDKgUnxECEpqJeS43geA=;
	b=eFNSh6Vj+J1kybS3kei57Vr1fHut95++7ADIWA23bgHGVVPcmsc3eYzRgBgOWZwWiCUhSQ
	28fMMQh3jvUeQY/iUoS5SP5KvHaUfpE4wW1n7fYR/zlSBkfSGqjN66hY5/Q5tLB0SINp3A
	C9nV+ap17jwMvMWmZ6lEDuIrkZbBgMQ=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1710400878; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=RyZIS9vv4iGwmrp5sN5jilaqDKgUnxECEpqJeS43geA=;
	b=eFNSh6Vj+J1kybS3kei57Vr1fHut95++7ADIWA23bgHGVVPcmsc3eYzRgBgOWZwWiCUhSQ
	28fMMQh3jvUeQY/iUoS5SP5KvHaUfpE4wW1n7fYR/zlSBkfSGqjN66hY5/Q5tLB0SINp3A
	C9nV+ap17jwMvMWmZ6lEDuIrkZbBgMQ=
From: Juergen Gross 
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross ,
	Jan Beulich ,
	Andrew Cooper ,
	George Dunlap ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Wei Liu ,
	Julien Grall ,
	Stefano Stabellini ,
	Paul Durrant 
Subject: [PATCH v5 08/13] xen/spinlock: add missing rspin_is_locked() and rspin_barrier()
Date: Thu, 14 Mar 2024 08:20:24 +0100
Message-Id: <20240314072029.16937-9-jgross@suse.com>
X-Mailer: git-send-email 2.35.3
In-Reply-To: <20240314072029.16937-1-jgross@suse.com>
References: <20240314072029.16937-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Level: 
Authentication-Results: smtp-out1.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b=eFNSh6Vj
X-Rspamd-Server: rspamd2.dmz-prg2.suse.org
X-Spamd-Result: default: False [-3.01 / 50.00];
	 ARC_NA(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 R_DKIM_ALLOW(-0.20)[suse.com:s=susede1];
	 RCVD_DKIM_ARC_DNSWL_HI(-1.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_MISSING_CHARSET(2.50)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 BROKEN_CONTENT_TYPE(1.50)[];
	 DWL_DNSWL_MED(-2.00)[suse.com:dkim];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_SIGNED(0.00)[suse.com:s=susede1];
	 DKIM_TRACE(0.00)[suse.com:+];
	 MX_GOOD(-0.01)[];
	 RCPT_COUNT_SEVEN(0.00)[10];
	 MID_CONTAINS_FROM(1.00)[];
	 FUZZY_BLOCKED(0.00)[rspamd.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 NEURAL_HAM_SHORT(-0.20)[-1.000];
	 RCVD_IN_DNSWL_HI(-0.50)[2a07:de40:b281:106:10:150:64:167:received];
	 RCVD_TLS_ALL(0.00)[];
	 BAYES_HAM(-3.00)[100.00%]
X-Spam-Score: -3.01
X-Rspamd-Queue-Id: 2476C21CCF
X-Spam-Flag: NO

Add rspin_is_locked() and rspin_barrier() in order to prepare differing
spinlock_t and rspinlock_t types.

Signed-off-by: Juergen Gross 
---
V2:
- partially carved out from V1 patch, partially new
V5:
- let rspin_is_locked() return bool (Jan Beulich)
---
 xen/arch/x86/mm/p2m-pod.c     |  2 +-
 xen/common/domain.c           |  2 +-
 xen/common/page_alloc.c       |  2 +-
 xen/common/spinlock.c         | 26 ++++++++++++++++++--------
 xen/drivers/char/console.c    |  4 ++--
 xen/drivers/passthrough/pci.c |  2 +-
 xen/include/xen/spinlock.h    |  4 ++++
 7 files changed, 28 insertions(+), 14 deletions(-)

diff --git a/xen/arch/x86/mm/p2m-pod.c b/xen/arch/x86/mm/p2m-pod.c
index 515a8c98a5..ae5dcb1870 100644
--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -374,7 +374,7 @@ int p2m_pod_empty_cache(struct domain *d)
 
     /* After this barrier no new PoD activities can happen. */
     BUG_ON(!d->is_dying);
-    spin_barrier(&p2m->pod.lock.lock);
+    rspin_barrier(&p2m->pod.lock.lock);
 
     lock_page_alloc(p2m);
 
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 8e0109c590..2d7c69e6d2 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -983,7 +983,7 @@ int domain_kill(struct domain *d)
     case DOMDYING_alive:
         domain_pause(d);
         d->is_dying = DOMDYING_dying;
-        spin_barrier(&d->domain_lock);
+        rspin_barrier(&d->domain_lock);
         argo_destroy(d);
         vnuma_destroy(d->vnuma);
         domain_set_outstanding_pages(d, 0);
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 20238015ed..83d1715e25 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -475,7 +475,7 @@ unsigned long domain_adjust_tot_pages(struct domain *d, long pages)
 {
     long dom_before, dom_after, dom_claimed, sys_before, sys_after;
 
-    ASSERT(spin_is_locked(&d->page_alloc_lock));
+    ASSERT(rspin_is_locked(&d->page_alloc_lock));
     d->tot_pages += pages;
 
     /*
diff --git a/xen/common/spinlock.c b/xen/common/spinlock.c
index 648393d95f..c3f2f9b209 100644
--- a/xen/common/spinlock.c
+++ b/xen/common/spinlock.c
@@ -395,14 +395,7 @@ static bool always_inline spin_is_locked_common(const spinlock_tickets_t *t)
 
 int _spin_is_locked(const spinlock_t *lock)
 {
-    /*
-     * Recursive locks may be locked by another CPU, yet we return
-     * "false" here, making this function suitable only for use in
-     * ASSERT()s and alike.
-     */
-    return lock->recurse_cpu == SPINLOCK_NO_CPU
-           ? spin_is_locked_common(&lock->tickets)
-           : lock->recurse_cpu == smp_processor_id();
+    return spin_is_locked_common(&lock->tickets);
 }
 
 static bool always_inline spin_trylock_common(spinlock_tickets_t *t,
@@ -465,6 +458,23 @@ void _spin_barrier(spinlock_t *lock)
     spin_barrier_common(&lock->tickets, &lock->debug, LOCK_PROFILE_PAR);
 }
 
+bool _rspin_is_locked(const rspinlock_t *lock)
+{
+    /*
+     * Recursive locks may be locked by another CPU, yet we return
+     * "false" here, making this function suitable only for use in
+     * ASSERT()s and alike.
+     */
+    return lock->recurse_cpu == SPINLOCK_NO_CPU
+           ? spin_is_locked_common(&lock->tickets)
+           : lock->recurse_cpu == smp_processor_id();
+}
+
+void _rspin_barrier(rspinlock_t *lock)
+{
+    spin_barrier_common(&lock->tickets, &lock->debug, LOCK_PROFILE_PAR);
+}
+
 bool _rspin_trylock(rspinlock_t *lock)
 {
     unsigned int cpu = smp_processor_id();
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 22f50fc617..d5e6aacc27 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -327,7 +327,7 @@ static void cf_check do_dec_thresh(unsigned char key, bool unused)
 
 static void conring_puts(const char *str, size_t len)
 {
-    ASSERT(spin_is_locked(&console_lock));
+    ASSERT(rspin_is_locked(&console_lock));
 
     while ( len-- )
         conring[CONRING_IDX_MASK(conringp++)] = *str++;
@@ -765,7 +765,7 @@ static void __putstr(const char *str)
 {
     size_t len = strlen(str);
 
-    ASSERT(spin_is_locked(&console_lock));
+    ASSERT(rspin_is_locked(&console_lock));
 
     console_serial_puts(str, len);
     video_puts(str, len);
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 4fcc7e2cde..5a446d3dce 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -65,7 +65,7 @@ void pcidevs_unlock(void)
 
 bool pcidevs_locked(void)
 {
-    return !!spin_is_locked(&_pcidevs_lock);
+    return rspin_is_locked(&_pcidevs_lock);
 }
 
 static struct radix_tree_root pci_segments;
diff --git a/xen/include/xen/spinlock.h b/xen/include/xen/spinlock.h
index 5b20b11db6..7dd11faab3 100644
--- a/xen/include/xen/spinlock.h
+++ b/xen/include/xen/spinlock.h
@@ -297,6 +297,8 @@ void _rspin_lock(rspinlock_t *lock);
 unsigned long _rspin_lock_irqsave(rspinlock_t *lock);
 void _rspin_unlock(rspinlock_t *lock);
 void _rspin_unlock_irqrestore(rspinlock_t *lock, unsigned long flags);
+bool _rspin_is_locked(const rspinlock_t *lock);
+void _rspin_barrier(rspinlock_t *lock);
 
 static always_inline void rspin_lock(rspinlock_t *lock)
 {
@@ -307,6 +309,8 @@ static always_inline void rspin_lock(rspinlock_t *lock)
 #define rspin_trylock(l)              lock_evaluate_nospec(_rspin_trylock(l))
 #define rspin_unlock(l)               _rspin_unlock(l)
 #define rspin_unlock_irqrestore(l, f) _rspin_unlock_irqrestore(l, f)
+#define rspin_barrier(l)              _rspin_barrier(l)
+#define rspin_is_locked(l)            _rspin_is_locked(l)
 
 #define nrspin_trylock(l)    spin_trylock(l)
 #define nrspin_lock(l)       spin_lock(l)
-- 
2.35.3



From xen-devel-bounces@lists.xenproject.org Thu Mar 14 07:21:38 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 07:21:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692910.1080609 (Exim 4.92)
	(envelope-from )
	id 1rkfPG-0001VV-JI; Thu, 14 Mar 2024 07:21:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692910.1080609; Thu, 14 Mar 2024 07:21:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkfPG-0001VO-GF; Thu, 14 Mar 2024 07:21:38 +0000
Received: by outflank-mailman (input) for mailman id 692910;
 Thu, 14 Mar 2024 07:21:37 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkfPF-0005rB-08
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 07:21:37 +0000
Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7d5675c0-e1d3-11ee-a1ee-f123f15fe8a2;
 Thu, 14 Mar 2024 08:21:35 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [10.150.64.97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out2.suse.de (Postfix) with ESMTPS id 101F41F79B;
 Thu, 14 Mar 2024 07:21:35 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id C38D513977;
 Thu, 14 Mar 2024 07:21:34 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id L25ELn6l8mV/DgAAD6G6ig
 (envelope-from ); Thu, 14 Mar 2024 07:21:34 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7d5675c0-e1d3-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1710400895; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=lVUg9sUvshZn0hcfy+zcEBYHChto2sM8ej1C5kH/2gA=;
	b=bCTeyhrUUqc9JD5BDVIVsaj3drWovyp3NBzB06q9GTGxzwLgDmX2VQaefJXGE/31hJSHo4
	poM0XP+Ato6d3pg2Tn6TFGmEEYiO5fewWFNDLf5jkjfaiublYF5jZ89DSzqrU9ynQAkyY/
	kDVyy2aKqlzsey9cnGYU0o0T1QkP/rQ=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1710400895; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=lVUg9sUvshZn0hcfy+zcEBYHChto2sM8ej1C5kH/2gA=;
	b=bCTeyhrUUqc9JD5BDVIVsaj3drWovyp3NBzB06q9GTGxzwLgDmX2VQaefJXGE/31hJSHo4
	poM0XP+Ato6d3pg2Tn6TFGmEEYiO5fewWFNDLf5jkjfaiublYF5jZ89DSzqrU9ynQAkyY/
	kDVyy2aKqlzsey9cnGYU0o0T1QkP/rQ=
From: Juergen Gross 
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini ,
	Wei Liu 
Subject: [PATCH v5 11/13] xen/spinlock: support higher number of cpus
Date: Thu, 14 Mar 2024 08:20:27 +0100
Message-Id: <20240314072029.16937-12-jgross@suse.com>
X-Mailer: git-send-email 2.35.3
In-Reply-To: <20240314072029.16937-1-jgross@suse.com>
References: <20240314072029.16937-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Level: *
Authentication-Results: smtp-out2.suse.de;
	none
X-Spamd-Result: default: False [1.90 / 50.00];
	 ARC_NA(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_MISSING_CHARSET(2.50)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 BROKEN_CONTENT_TYPE(1.50)[];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_SIGNED(0.00)[suse.com:s=susede1];
	 RCPT_COUNT_SEVEN(0.00)[8];
	 MID_CONTAINS_FROM(1.00)[];
	 FUZZY_BLOCKED(0.00)[rspamd.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 RCVD_TLS_ALL(0.00)[];
	 BAYES_HAM(-3.00)[100.00%]
X-Spam-Score: 1.90
X-Spam-Flag: NO

Allow 16 bits per cpu number, which is the limit imposed by
spinlock_tickets_t.

This will allow up to 65535 cpus, while increasing only the size of
recursive spinlocks in debug builds from 8 to 12 bytes.

The current Xen limit of 4095 cpus is imposed by SPINLOCK_CPU_BITS
being 12. There are machines available with more cpus than the current
Xen limit, so it makes sense to have the possibility to use more cpus.

Signed-off-by: Juergen Gross 
---
V5:
- keep previous recursion limit (Julien Grall)
---
 xen/common/spinlock.c      |  2 ++
 xen/include/xen/spinlock.h | 20 ++++++++++----------
 2 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/xen/common/spinlock.c b/xen/common/spinlock.c
index b28239f74d..5be48be082 100644
--- a/xen/common/spinlock.c
+++ b/xen/common/spinlock.c
@@ -481,7 +481,9 @@ bool _rspin_trylock(rspinlock_t *lock)
 
     /* Don't allow overflow of recurse_cpu field. */
     BUILD_BUG_ON(NR_CPUS > SPINLOCK_NO_CPU);
+    BUILD_BUG_ON(SPINLOCK_CPU_BITS > sizeof(lock->recurse_cpu) * 8);
     BUILD_BUG_ON(SPINLOCK_RECURSE_BITS < 3);
+    BUILD_BUG_ON(SPINLOCK_MAX_RECURSE > ((1u << SPINLOCK_RECURSE_BITS) - 1));
 
     check_lock(&lock->debug, true);
 
diff --git a/xen/include/xen/spinlock.h b/xen/include/xen/spinlock.h
index 1b50a7e6a0..984da6d4c9 100644
--- a/xen/include/xen/spinlock.h
+++ b/xen/include/xen/spinlock.h
@@ -8,16 +8,16 @@
 #include 
 #include 
 
-#define SPINLOCK_CPU_BITS  12
+#define SPINLOCK_CPU_BITS  16
 
 #ifdef CONFIG_DEBUG_LOCKS
 union lock_debug {
-    uint16_t val;
-#define LOCK_DEBUG_INITVAL 0xffff
+    uint32_t val;
+#define LOCK_DEBUG_INITVAL 0xffffffff
     struct {
-        uint16_t cpu:SPINLOCK_CPU_BITS;
-#define LOCK_DEBUG_PAD_BITS (14 - SPINLOCK_CPU_BITS)
-        uint16_t :LOCK_DEBUG_PAD_BITS;
+        uint32_t cpu:SPINLOCK_CPU_BITS;
+#define LOCK_DEBUG_PAD_BITS (30 - SPINLOCK_CPU_BITS)
+        uint32_t :LOCK_DEBUG_PAD_BITS;
         bool irq_safe:1;
         bool unseen:1;
     };
@@ -211,11 +211,11 @@ typedef struct spinlock {
 
 typedef struct rspinlock {
     spinlock_tickets_t tickets;
-    uint16_t recurse_cpu:SPINLOCK_CPU_BITS;
+    uint16_t recurse_cpu;
 #define SPINLOCK_NO_CPU        ((1u << SPINLOCK_CPU_BITS) - 1)
-#define SPINLOCK_RECURSE_BITS  (16 - SPINLOCK_CPU_BITS)
-    uint16_t recurse_cnt:SPINLOCK_RECURSE_BITS;
-#define SPINLOCK_MAX_RECURSE   ((1u << SPINLOCK_RECURSE_BITS) - 1)
+#define SPINLOCK_RECURSE_BITS  8
+    uint8_t recurse_cnt;
+#define SPINLOCK_MAX_RECURSE   15
     union lock_debug debug;
 #ifdef CONFIG_DEBUG_LOCK_PROFILE
     struct lock_profile *profile;
-- 
2.35.3



From xen-devel-bounces@lists.xenproject.org Thu Mar 14 07:24:06 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 07:24:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692911.1080619 (Exim 4.92)
	(envelope-from )
	id 1rkfRd-0002d6-4t; Thu, 14 Mar 2024 07:24:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692911.1080619; Thu, 14 Mar 2024 07:24:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkfRd-0002cz-13; Thu, 14 Mar 2024 07:24:05 +0000
Received: by outflank-mailman (input) for mailman id 692911;
 Thu, 14 Mar 2024 07:24:03 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkfRb-0002ct-Sp
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 07:24:03 +0000
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com
 [2a00:1450:4864:20::635])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d5317350-e1d3-11ee-afdd-a90da7624cb6;
 Thu, 14 Mar 2024 08:24:02 +0100 (CET)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-a4675aaa2e8so15626566b.0
 for ; Thu, 14 Mar 2024 00:24:02 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 h25-20020a17090634d900b00a4519304f8bsm427417ejb.14.2024.03.14.00.24.01
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 14 Mar 2024 00:24:02 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d5317350-e1d3-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710401042; x=1711005842; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=4sDFUaYnqDqb/TMVYQI7f7jRxysLpxHHjCEPGJ6Lvyg=;
        b=VzOAl6X0nUeRs4dfNldfNoewymfPcM1+mHA4c7r3lNSWsd9vbMOOGGorraNAzJYxng
         NtxreZlEjTQnxlZ78fzfbNuL9RHmsspaZxMVoqpHaJFeb+jLdKaIlb1qiAwI3HNf+mvj
         IJ8MeGmRkADcfFtLYiXbMx1W4v97hdFw6sGvvnMywKzo2IuoD4hqyNDsLf4dS2+ibkaW
         nuQPAuYW27qtxHVbZ8acRnh0F/Wh9Y681CiVBo+3Tbv9iiWdSp9O8fpzyZHXSSowL65D
         M0RKXT/CLbb4rmtMMDs5YEliuLrpkIpMy7uvYrPwqxeSeS6bZOR1lPtHmYKKFt39dRoi
         Hxsg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710401042; x=1711005842;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=4sDFUaYnqDqb/TMVYQI7f7jRxysLpxHHjCEPGJ6Lvyg=;
        b=aW+pcdfaGeImOCAlNCnW7BdbPnR+K6M5u9dz3KUrZ5wsl8erIzmBn+F4hr5v+lL/Cd
         2T1pig0AMO0tS2D00W76gFzeGhcsLO3JyMrh3kMIjzNpOEDLJwCUBNQm8NLud/JmTh//
         uXUyFTlqBPd2YRuKHv94Uww7w5eCxpCejwbrv2MXnPd1c4BfGf6KrJtyxIIqjSUJrpZc
         UdiTjRKcDQex+9g8eIKO0SKRA1xzBYNMpUbAfbC+HNtBlfcKPOdIIzfQCmhW9t1INPR5
         NWrTIHrqa8v6TOK/BNzDdw2PpX52bomh0XfMwvdyfsubcqWGX3lx7/dFVHuvKcbXjnKO
         Ag0A==
X-Gm-Message-State: AOJu0YyLnjQDKElxXKrVeJuTNp2oFUtPx/Jter1tONqbk5k0i8aQ2+TW
	qkQFCwoTqt6F1Bky33N73j1MJYJX13C4JwW5QITc1XqOXWPk6j00tL2h+BP0KQ==
X-Google-Smtp-Source: AGHT+IE2GSrgo1+8c4+6Fx6+UXTZLKakH6dZIJlaj7SOhEJgh4l4lKhn4uNNtJl/Zgzw/TZa9/oZ+g==
X-Received: by 2002:a17:906:e11:b0:a45:8b6d:9c92 with SMTP id l17-20020a1709060e1100b00a458b6d9c92mr649867eji.31.1710401042262;
        Thu, 14 Mar 2024 00:24:02 -0700 (PDT)
Message-ID: 
Date: Thu, 14 Mar 2024 08:24:00 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/7] multiboot2: Add load type header and support for the
 PE binary type
To: Ross Lagerwall 
Cc: xen-devel@lists.xenproject.org, Andrew Cooper
 , Daniel Kiper ,
 grub-devel@gnu.org
References: <20240313150748.791236-1-ross.lagerwall@citrix.com>
 <20240313150748.791236-2-ross.lagerwall@citrix.com>
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240313150748.791236-2-ross.lagerwall@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 13.03.2024 16:07, Ross Lagerwall wrote:
> In addition to the existing address and ELF load types, specify a new
> optional PE binary load type. This new type is a useful addition since
> PE binaries can be signed and verified (i.e. used with Secure Boot).

And the consideration to have ELF signable (by whatever extension to
the ELF spec) went nowhere?

Jan


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 07:26:46 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 07:26:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692914.1080629 (Exim 4.92)
	(envelope-from )
	id 1rkfU9-0003Ax-Gt; Thu, 14 Mar 2024 07:26:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692914.1080629; Thu, 14 Mar 2024 07:26:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkfU9-0003Aq-D5; Thu, 14 Mar 2024 07:26:41 +0000
Received: by outflank-mailman (input) for mailman id 692914;
 Thu, 14 Mar 2024 07:26:40 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkfU8-0003Ak-BR
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 07:26:40 +0000
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com
 [2a00:1450:4864:20::62c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 31e664d1-e1d4-11ee-a1ee-f123f15fe8a2;
 Thu, 14 Mar 2024 08:26:38 +0100 (CET)
Received: by mail-ej1-x62c.google.com with SMTP id
 a640c23a62f3a-a466a256726so119611766b.1
 for ; Thu, 14 Mar 2024 00:26:38 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 f23-20020a1709067f9700b00a43e8e76825sm424651ejr.149.2024.03.14.00.26.37
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 14 Mar 2024 00:26:37 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 31e664d1-e1d4-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710401198; x=1711005998; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=DgaqQRLa/bceGTxMnXEXk4fxq4M6cGxB2GPnK5l9feI=;
        b=VWRcASX33rwHVNM/wXJHrT7xIK4X/nVdQLEaSSwQHMNZVC8VoeMmEKFho3hdLptO3t
         t+mabPYJz5VaJdiCw3bnhd3vu42bq2M8uNw9JDzqAY43OP6rKDWgcmlBfk29vjVRG67M
         73suKqvw5i6aBd4tukQODhrc18lZkP7OsCHIOia8qnc5KAweR+JjPZPpWTThHk7KMMz+
         eHi4CmnaSb8PFAlgUaP5L5dUBjuFZXXbrs2KDJHhj5PHJWs3Yfy6OSX0bRE2qV2cPJev
         P+sRNlwzJontsLAN0sagqWtzcITz1x14SjyMJr/SRKhS6kgrgcRB/uv7Yi5lryCVPrqu
         jNkA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710401198; x=1711005998;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=DgaqQRLa/bceGTxMnXEXk4fxq4M6cGxB2GPnK5l9feI=;
        b=MztA5qfSS1lnlX+oR5f1DiGKUzNqAy+m1n1rdUcU1kGeMz5LgL4LhHxnZ7gbqKv+gq
         LtM43Mk/L2S3mFiUKZL6IGQjfr+gwZoMq6FPULlgbWc+7PUusXlF98E02+auMaDAVPX3
         IBfxJUXWeLYHBlmnGlLAcj9I5f1EtXl3MdTPDHeHl2LbRW11N3HwONbV1IUoGC8B2Zcq
         UMHscl2DGXntJ63FTkL1SQM1PwBA/AVA7o2DCKXFAj/R3arOpt8C+DdgSHB5KVFkyVI3
         DIjiIXomKPxB2odstYzKSG70u0epI2O7ims9o6OGdS+5cvnQqx9mA8OtV9wBDZcDaim8
         wytQ==
X-Forwarded-Encrypted: i=1; AJvYcCU2cstJWGObRp4mspxKCdaR0+B2GZDB41QF2ysHgn0zIVVJ/FJKyoAaYF2EA2BzWhpHmbyJ3MSUs4bdAxHY0SU5YRvQbQKHHKl9wC85Odg=
X-Gm-Message-State: AOJu0YyYigeaAnyu8tIkPUVrZXtpk4B7qU3N+1EFhmYOqO6usZfYc4yq
	P8M1qghzPpVxT3n9wcHk72F86El6vdnVZ9ywWlcvAqhrn0lEkzO8Yc11LrNQeg==
X-Google-Smtp-Source: AGHT+IEESfg3kAvlJ0pFbGpp9wwXZHIsccwivDl9X+A3LfW2040M7bnzjFpf7TwRUgN+twxMvRYN7Q==
X-Received: by 2002:a17:906:6a03:b0:a46:75d3:dd46 with SMTP id qw3-20020a1709066a0300b00a4675d3dd46mr320990ejc.17.1710401197826;
        Thu, 14 Mar 2024 00:26:37 -0700 (PDT)
Message-ID: 
Date: Thu, 14 Mar 2024 08:26:36 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 13/13] xen: allow up to 16383 cpus
Content-Language: en-US
To: Juergen Gross 
Cc: Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 xen-devel@lists.xenproject.org
References: <20240314072029.16937-1-jgross@suse.com>
 <20240314072029.16937-14-jgross@suse.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240314072029.16937-14-jgross@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 14.03.2024 08:20, Juergen Gross wrote:
> With lock handling now allowing up to 16384 cpus (spinlocks can handle
> 65535 cpus, rwlocks can handle 16384 cpus), raise the allowed limit for
> the number of cpus to be configured to 16383.
> 
> The new limit is imposed by IOMMU_CMD_BUFFER_MAX_ENTRIES and
> QINVAL_MAX_ENTRY_NR required to be larger than 2 * CONFIG_NR_CPUS.

That's quite sad - I was really hoping we'd finally end up with a
power-of-2 upper bound.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 07:28:50 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 07:28:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692919.1080638 (Exim 4.92)
	(envelope-from )
	id 1rkfWC-0003qV-QR; Thu, 14 Mar 2024 07:28:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692919.1080638; Thu, 14 Mar 2024 07:28:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkfWC-0003qO-Nv; Thu, 14 Mar 2024 07:28:48 +0000
Received: by outflank-mailman (input) for mailman id 692919;
 Thu, 14 Mar 2024 07:28:48 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkfPP-0005cd-8l
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 07:21:47 +0000
Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 84170f40-e1d3-11ee-afdd-a90da7624cb6;
 Thu, 14 Mar 2024 08:21:46 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [10.150.64.97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out2.suse.de (Postfix) with ESMTPS id 623A91F79B;
 Thu, 14 Mar 2024 07:21:46 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 1F2EE13977;
 Thu, 14 Mar 2024 07:21:46 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id 6SIlBoql8mWXDgAAD6G6ig
 (envelope-from ); Thu, 14 Mar 2024 07:21:46 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 84170f40-e1d3-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1710400906; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=svDhVGjKFzIPpcWjFYARn/2rWUfeidU+xfRiYlSjnX4=;
	b=EkBnLKOBMPSiT+mLfvH5diIs5oNZa3ZYrVL2mqE0YS3a3slf6xVaQ1xNZbcKaPWCXxlsId
	saQdPEEfqZF0QIsteoa/J3SfuX2vLdA99ZEWn4uun0ngYCOJjlesSCZY3akhpEmeiPfPqf
	CBS9SfE5xRbTmX3zGkjFY4/M9SIZ0JY=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1710400906; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=svDhVGjKFzIPpcWjFYARn/2rWUfeidU+xfRiYlSjnX4=;
	b=EkBnLKOBMPSiT+mLfvH5diIs5oNZa3ZYrVL2mqE0YS3a3slf6xVaQ1xNZbcKaPWCXxlsId
	saQdPEEfqZF0QIsteoa/J3SfuX2vLdA99ZEWn4uun0ngYCOJjlesSCZY3akhpEmeiPfPqf
	CBS9SfE5xRbTmX3zGkjFY4/M9SIZ0JY=
From: Juergen Gross 
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini ,
	Wei Liu 
Subject: [PATCH v5 13/13] xen: allow up to 16383 cpus
Date: Thu, 14 Mar 2024 08:20:29 +0100
Message-Id: <20240314072029.16937-14-jgross@suse.com>
X-Mailer: git-send-email 2.35.3
In-Reply-To: <20240314072029.16937-1-jgross@suse.com>
References: <20240314072029.16937-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Level: ****
Authentication-Results: smtp-out2.suse.de;
	none
X-Spamd-Result: default: False [4.90 / 50.00];
	 ARC_NA(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 URIBL_BLOCKED(0.00)[suse.com:email];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_MISSING_CHARSET(2.50)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 BROKEN_CONTENT_TYPE(1.50)[];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_SIGNED(0.00)[suse.com:s=susede1];
	 RCPT_COUNT_SEVEN(0.00)[8];
	 MID_CONTAINS_FROM(1.00)[];
	 FUZZY_BLOCKED(0.00)[rspamd.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 RCVD_TLS_ALL(0.00)[]
X-Spam-Score: 4.90
X-Spam-Flag: NO

With lock handling now allowing up to 16384 cpus (spinlocks can handle
65535 cpus, rwlocks can handle 16384 cpus), raise the allowed limit for
the number of cpus to be configured to 16383.

The new limit is imposed by IOMMU_CMD_BUFFER_MAX_ENTRIES and
QINVAL_MAX_ENTRY_NR required to be larger than 2 * CONFIG_NR_CPUS.

Signed-off-by: Juergen Gross 
---
V5:
- new patch (Jan Beulich)
---
 xen/arch/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/Kconfig b/xen/arch/Kconfig
index 67ba38f32f..308ce129a8 100644
--- a/xen/arch/Kconfig
+++ b/xen/arch/Kconfig
@@ -6,7 +6,7 @@ config PHYS_ADDR_T_32
 
 config NR_CPUS
 	int "Maximum number of CPUs"
-	range 1 4095
+	range 1 16383
 	default "256" if X86
 	default "8" if ARM && RCAR3
 	default "4" if ARM && QEMU
-- 
2.35.3



From xen-devel-bounces@lists.xenproject.org Thu Mar 14 07:32:08 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 07:32:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692930.1080648 (Exim 4.92)
	(envelope-from )
	id 1rkfZK-00065b-8H; Thu, 14 Mar 2024 07:32:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692930.1080648; Thu, 14 Mar 2024 07:32:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkfZK-00065U-5l; Thu, 14 Mar 2024 07:32:02 +0000
Received: by outflank-mailman (input) for mailman id 692930;
 Thu, 14 Mar 2024 07:32:01 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkfPJ-0005cd-Of
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 07:21:41 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 80bf598c-e1d3-11ee-afdd-a90da7624cb6;
 Thu, 14 Mar 2024 08:21:41 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [10.150.64.97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id B808D21CF1;
 Thu, 14 Mar 2024 07:21:40 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 74A4713977;
 Thu, 14 Mar 2024 07:21:40 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id rPftGoSl8mWSDgAAD6G6ig
 (envelope-from ); Thu, 14 Mar 2024 07:21:40 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 80bf598c-e1d3-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1710400900; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=DBLksahmXlvC7yfjAllNqgbhTHyvKKzQktudFgw2Foo=;
	b=kWqNAVP3JS7sjxQkIwZt1BroxwjcH64mEb2qLaXG2yWdT6SUyShr2k5C0fhULY5SHAQyDL
	27e/Xl3xDpcLXVIrGcioT/W5GthopOOYd4IdRNewui2wM30Wj2Myq6U4SoVxMJF3EjnC04
	gqSbGmQ78luNfFIUgkKVSfgwsiKz4Gw=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1710400900; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=DBLksahmXlvC7yfjAllNqgbhTHyvKKzQktudFgw2Foo=;
	b=kWqNAVP3JS7sjxQkIwZt1BroxwjcH64mEb2qLaXG2yWdT6SUyShr2k5C0fhULY5SHAQyDL
	27e/Xl3xDpcLXVIrGcioT/W5GthopOOYd4IdRNewui2wM30Wj2Myq6U4SoVxMJF3EjnC04
	gqSbGmQ78luNfFIUgkKVSfgwsiKz4Gw=
From: Juergen Gross 
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini ,
	Wei Liu 
Subject: [PATCH v5 12/13] xen/rwlock: raise the number of possible cpus
Date: Thu, 14 Mar 2024 08:20:28 +0100
Message-Id: <20240314072029.16937-13-jgross@suse.com>
X-Mailer: git-send-email 2.35.3
In-Reply-To: <20240314072029.16937-1-jgross@suse.com>
References: <20240314072029.16937-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Level: ****
Authentication-Results: smtp-out1.suse.de;
	none
X-Spamd-Result: default: False [4.90 / 50.00];
	 ARC_NA(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 URIBL_BLOCKED(0.00)[suse.com:email];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_MISSING_CHARSET(2.50)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 BROKEN_CONTENT_TYPE(1.50)[];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_SIGNED(0.00)[suse.com:s=susede1];
	 RCPT_COUNT_SEVEN(0.00)[8];
	 MID_CONTAINS_FROM(1.00)[];
	 FUZZY_BLOCKED(0.00)[rspamd.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 RCVD_TLS_ALL(0.00)[]
X-Spam-Score: 4.90
X-Spam-Flag: NO

The rwlock handling is limiting the number of cpus to 4095 today. The
main reason is the use of the atomic_t data type for the main lock
handling, which needs 2 bits for the locking state (writer waiting or
write locked), 12 bits for the id of a possible writer, and a 12 bit
counter for readers. The limit isn't 4096 due to an off by one sanity
check.

The atomic_t data type is 32 bits wide, so in theory 15 bits for the
writer's cpu id and 15 bits for the reader count seem to be fine, but
via read_trylock() more readers than cpus are possible.

This means that it is possible to raise the number of cpus to 16384
without changing the rwlock_t data structure. In order to avoid the
reader count wrapping to zero, don't let read_trylock() succeed in case
the highest bit of the reader's count is set already. This leaves enough
headroom for non-recursive readers to enter without risking a wrap.

While at it calculate _QW_CPUMASK and _QR_SHIFT from _QW_SHIFT and
add a sanity check for not overflowing the atomic_t data type.

Signed-off-by: Juergen Gross 
---
V5:
- new patch
---
 xen/include/xen/rwlock.h | 18 ++++++++++--------
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/xen/include/xen/rwlock.h b/xen/include/xen/rwlock.h
index 65d88b0ef4..afd57659bd 100644
--- a/xen/include/xen/rwlock.h
+++ b/xen/include/xen/rwlock.h
@@ -23,12 +23,12 @@ typedef struct {
 #define rwlock_init(l) (*(l) = (rwlock_t)RW_LOCK_UNLOCKED)
 
 /* Writer states & reader shift and bias. */
-#define    _QW_CPUMASK  0xfffU             /* Writer CPU mask */
-#define    _QW_SHIFT    12                 /* Writer flags shift */
-#define    _QW_WAITING  (1U << _QW_SHIFT)  /* A writer is waiting */
-#define    _QW_LOCKED   (3U << _QW_SHIFT)  /* A writer holds the lock */
-#define    _QW_WMASK    (3U << _QW_SHIFT)  /* Writer mask */
-#define    _QR_SHIFT    14                 /* Reader count shift */
+#define    _QW_SHIFT    14                      /* Writer flags shift */
+#define    _QW_CPUMASK  ((1U << _QW_SHIFT) - 1) /* Writer CPU mask */
+#define    _QW_WAITING  (1U << _QW_SHIFT)       /* A writer is waiting */
+#define    _QW_LOCKED   (3U << _QW_SHIFT)       /* A writer holds the lock */
+#define    _QW_WMASK    (3U << _QW_SHIFT)       /* Writer mask */
+#define    _QR_SHIFT    (_QW_SHIFT + 2)         /* Reader count shift */
 #define    _QR_BIAS     (1U << _QR_SHIFT)
 
 void queue_read_lock_slowpath(rwlock_t *lock);
@@ -36,14 +36,16 @@ void queue_write_lock_slowpath(rwlock_t *lock);
 
 static inline bool _is_write_locked_by_me(unsigned int cnts)
 {
-    BUILD_BUG_ON(_QW_CPUMASK < NR_CPUS);
+    BUILD_BUG_ON((_QW_CPUMASK + 1) < NR_CPUS);
+    BUILD_BUG_ON(NR_CPUS * _QR_BIAS > INT_MAX);
     return (cnts & _QW_WMASK) == _QW_LOCKED &&
            (cnts & _QW_CPUMASK) == smp_processor_id();
 }
 
 static inline bool _can_read_lock(unsigned int cnts)
 {
-    return !(cnts & _QW_WMASK) || _is_write_locked_by_me(cnts);
+    return cnts <= INT_MAX &&
+           (!(cnts & _QW_WMASK) || _is_write_locked_by_me(cnts));
 }
 
 /*
-- 
2.35.3



From xen-devel-bounces@lists.xenproject.org Thu Mar 14 07:32:14 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 07:32:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692931.1080660 (Exim 4.92)
	(envelope-from )
	id 1rkfZW-0006PM-H7; Thu, 14 Mar 2024 07:32:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692931.1080660; Thu, 14 Mar 2024 07:32:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkfZW-0006PD-Cp; Thu, 14 Mar 2024 07:32:14 +0000
Received: by outflank-mailman (input) for mailman id 692931;
 Thu, 14 Mar 2024 07:32:13 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkfP3-0005cd-1V
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 07:21:25 +0000
Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 76a7a4a1-e1d3-11ee-afdd-a90da7624cb6;
 Thu, 14 Mar 2024 08:21:24 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [10.150.64.97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out2.suse.de (Postfix) with ESMTPS id C880A1F801;
 Thu, 14 Mar 2024 07:21:23 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 8724C13977;
 Thu, 14 Mar 2024 07:21:23 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id vU2WH3Ol8mVzDgAAD6G6ig
 (envelope-from ); Thu, 14 Mar 2024 07:21:23 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 76a7a4a1-e1d3-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1710400883; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=19/vfjk9VoFmZDJkVOwl2hl/O+FfTEfUdeHMhW/BgRM=;
	b=QXh4cxQRBmzMmecuhxANgyiBTHg1HsMWZR2Je574rEAJVNbvXDDeTAHlwEnKOk4O/bPC8m
	sYZpeRECDXox8+UgmzyvnPBOkz7I27JjMPLCieAotX7ffHhJzIZ7wBaSuyXeHfZEs66smf
	TPkhsY2T5ScwttZUsL7kAxsm3Xnu6RY=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1710400883; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=19/vfjk9VoFmZDJkVOwl2hl/O+FfTEfUdeHMhW/BgRM=;
	b=QXh4cxQRBmzMmecuhxANgyiBTHg1HsMWZR2Je574rEAJVNbvXDDeTAHlwEnKOk4O/bPC8m
	sYZpeRECDXox8+UgmzyvnPBOkz7I27JjMPLCieAotX7ffHhJzIZ7wBaSuyXeHfZEs66smf
	TPkhsY2T5ScwttZUsL7kAxsm3Xnu6RY=
From: Juergen Gross 
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini ,
	Wei Liu 
Subject: [PATCH v5 09/13] xen/spinlock: split recursive spinlocks from normal ones
Date: Thu, 14 Mar 2024 08:20:25 +0100
Message-Id: <20240314072029.16937-10-jgross@suse.com>
X-Mailer: git-send-email 2.35.3
In-Reply-To: <20240314072029.16937-1-jgross@suse.com>
References: <20240314072029.16937-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Level: *
Authentication-Results: smtp-out2.suse.de;
	none
X-Spamd-Result: default: False [1.90 / 50.00];
	 ARC_NA(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_MISSING_CHARSET(2.50)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 BROKEN_CONTENT_TYPE(1.50)[];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_SIGNED(0.00)[suse.com:s=susede1];
	 RCPT_COUNT_SEVEN(0.00)[8];
	 MID_CONTAINS_FROM(1.00)[];
	 FUZZY_BLOCKED(0.00)[rspamd.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 RCVD_TLS_ALL(0.00)[];
	 BAYES_HAM(-3.00)[100.00%]
X-Spam-Score: 1.90
X-Spam-Flag: NO

Recursive and normal spinlocks are sharing the same data structure for
representation of the lock. This has two major disadvantages:

- it is not clear from the definition of a lock, whether it is intended
  to be used recursive or not, while a mixture of both usage variants
  needs to be

- in production builds (builds without CONFIG_DEBUG_LOCKS) the needed
  data size of an ordinary spinlock is 8 bytes instead of 4, due to the
  additional recursion data needed (associated with that the rwlock
  data is using 12 instead of only 8 bytes)

Fix that by introducing a struct spinlock_recursive for recursive
spinlocks only, and switch recursive spinlock functions to require
pointers to this new struct.

This allows to check the correct usage at build time.

Signed-off-by: Juergen Gross 
---
V2:
- use shorter names (Jan Beulich)
- don't embed spinlock_t in rspinlock_t (Jan Beulich)
V5:
- some style fixes (Jan Beulich)
- bool instead of int (Jan Beulich)
---
 xen/common/spinlock.c      | 50 ++++++++++++++++++++++++++
 xen/include/xen/spinlock.h | 72 +++++++++++++++++++++++++++++---------
 2 files changed, 105 insertions(+), 17 deletions(-)

diff --git a/xen/common/spinlock.c b/xen/common/spinlock.c
index c3f2f9b209..a88ad9b93c 100644
--- a/xen/common/spinlock.c
+++ b/xen/common/spinlock.c
@@ -541,6 +541,56 @@ void _rspin_unlock_irqrestore(rspinlock_t *lock, unsigned long flags)
     local_irq_restore(flags);
 }
 
+bool _nrspin_trylock(rspinlock_t *lock)
+{
+    check_lock(&lock->debug, true);
+
+    if ( unlikely(lock->recurse_cpu != SPINLOCK_NO_CPU) )
+        return false;
+
+    return spin_trylock_common(&lock->tickets, &lock->debug, LOCK_PROFILE_PAR);
+}
+
+void _nrspin_lock(rspinlock_t *lock)
+{
+    spin_lock_common(&lock->tickets, &lock->debug, LOCK_PROFILE_PAR, NULL,
+                     NULL);
+}
+
+void _nrspin_unlock(rspinlock_t *lock)
+{
+    spin_unlock_common(&lock->tickets, &lock->debug, LOCK_PROFILE_PAR);
+}
+
+void _nrspin_lock_irq(rspinlock_t *lock)
+{
+    ASSERT(local_irq_is_enabled());
+    local_irq_disable();
+    _nrspin_lock(lock);
+}
+
+void _nrspin_unlock_irq(rspinlock_t *lock)
+{
+    _nrspin_unlock(lock);
+    local_irq_enable();
+}
+
+unsigned long _nrspin_lock_irqsave(rspinlock_t *lock)
+{
+    unsigned long flags;
+
+    local_irq_save(flags);
+    _nrspin_lock(lock);
+
+    return flags;
+}
+
+void _nrspin_unlock_irqrestore(rspinlock_t *lock, unsigned long flags)
+{
+    _nrspin_unlock(lock);
+    local_irq_restore(flags);
+}
+
 #ifdef CONFIG_DEBUG_LOCK_PROFILE
 
 struct lock_profile_anc {
diff --git a/xen/include/xen/spinlock.h b/xen/include/xen/spinlock.h
index 7dd11faab3..181e5c7d35 100644
--- a/xen/include/xen/spinlock.h
+++ b/xen/include/xen/spinlock.h
@@ -77,8 +77,6 @@ union lock_debug { };
 */
 
 struct spinlock;
-/* Temporary hack until a dedicated struct rspinlock is existing. */
-#define rspinlock spinlock
 
 struct lock_profile {
     struct lock_profile *next;       /* forward link */
@@ -110,6 +108,10 @@ struct lock_profile_qhead {
     __used_section(".lockprofile.data") =                                     \
     &lock_profile_data__##name
 #define SPIN_LOCK_UNLOCKED_(x) {                                              \
+    .debug = LOCK_DEBUG_,                                                     \
+    .profile = x,                                                             \
+}
+#define RSPIN_LOCK_UNLOCKED_(x) {                                             \
     .recurse_cpu = SPINLOCK_NO_CPU,                                           \
     .debug = LOCK_DEBUG_,                                                     \
     .profile = x,                                                             \
@@ -119,8 +121,9 @@ struct lock_profile_qhead {
     spinlock_t l = SPIN_LOCK_UNLOCKED_(NULL);                                 \
     static struct lock_profile lock_profile_data__##l = LOCK_PROFILE_(l);     \
     LOCK_PROFILE_PTR_(l)
+#define RSPIN_LOCK_UNLOCKED RSPIN_LOCK_UNLOCKED_(NULL)
 #define DEFINE_RSPINLOCK(l)                                                   \
-    rspinlock_t l = SPIN_LOCK_UNLOCKED_(NULL);                                \
+    rspinlock_t l = RSPIN_LOCK_UNLOCKED_(NULL);                               \
     static struct lock_profile lock_profile_data__##l = RLOCK_PROFILE_(l);    \
     LOCK_PROFILE_PTR_(l)
 
@@ -145,8 +148,11 @@ struct lock_profile_qhead {
 
 #define spin_lock_init_prof(s, l)                                             \
     spin_lock_init_prof__(s, l, lock, spinlock_t, false)
-#define rspin_lock_init_prof(s, l)                                            \
-    spin_lock_init_prof__(s, l, rlock, rspinlock_t, true)
+#define rspin_lock_init_prof(s, l) do {                                       \
+        spin_lock_init_prof__(s, l, rlock, rspinlock_t, true);                \
+        (s)->l.recurse_cpu = SPINLOCK_NO_CPU;                                 \
+        (s)->l.recurse_cnt = 0;                                               \
+    } while (0)
 
 void _lock_profile_register_struct(
     int32_t type, struct lock_profile_qhead *qhead, int32_t idx);
@@ -168,11 +174,14 @@ struct lock_profile_qhead { };
 struct lock_profile { };
 
 #define SPIN_LOCK_UNLOCKED {                                                  \
+    .debug = LOCK_DEBUG_,                                                     \
+}
+#define RSPIN_LOCK_UNLOCKED {                                                 \
     .recurse_cpu = SPINLOCK_NO_CPU,                                           \
     .debug = LOCK_DEBUG_,                                                     \
 }
 #define DEFINE_SPINLOCK(l) spinlock_t l = SPIN_LOCK_UNLOCKED
-#define DEFINE_RSPINLOCK(l) rspinlock_t l = SPIN_LOCK_UNLOCKED
+#define DEFINE_RSPINLOCK(l) rspinlock_t l = RSPIN_LOCK_UNLOCKED
 
 #define spin_lock_init_prof(s, l) spin_lock_init(&((s)->l))
 #define rspin_lock_init_prof(s, l) rspin_lock_init(&((s)->l))
@@ -193,6 +202,14 @@ typedef union {
 #define SPINLOCK_TICKET_INC { .head_tail = 0x10000, }
 
 typedef struct spinlock {
+    spinlock_tickets_t tickets;
+    union lock_debug debug;
+#ifdef CONFIG_DEBUG_LOCK_PROFILE
+    struct lock_profile *profile;
+#endif
+} spinlock_t;
+
+typedef struct rspinlock {
     spinlock_tickets_t tickets;
     uint16_t recurse_cpu:SPINLOCK_CPU_BITS;
 #define SPINLOCK_NO_CPU        ((1u << SPINLOCK_CPU_BITS) - 1)
@@ -203,12 +220,10 @@ typedef struct spinlock {
 #ifdef CONFIG_DEBUG_LOCK_PROFILE
     struct lock_profile *profile;
 #endif
-} spinlock_t;
-
-typedef spinlock_t rspinlock_t;
+} rspinlock_t;
 
 #define spin_lock_init(l) (*(l) = (spinlock_t)SPIN_LOCK_UNLOCKED)
-#define rspin_lock_init(l) (*(l) = (rspinlock_t)SPIN_LOCK_UNLOCKED)
+#define rspin_lock_init(l) (*(l) = (rspinlock_t)RSPIN_LOCK_UNLOCKED)
 
 void _spin_lock(spinlock_t *lock);
 void _spin_lock_cb(spinlock_t *lock, void (*cb)(void *data), void *data);
@@ -312,12 +327,35 @@ static always_inline void rspin_lock(rspinlock_t *lock)
 #define rspin_barrier(l)              _rspin_barrier(l)
 #define rspin_is_locked(l)            _rspin_is_locked(l)
 
-#define nrspin_trylock(l)    spin_trylock(l)
-#define nrspin_lock(l)       spin_lock(l)
-#define nrspin_unlock(l)     spin_unlock(l)
-#define nrspin_lock_irq(l)   spin_lock_irq(l)
-#define nrspin_unlock_irq(l) spin_unlock_irq(l)
-#define nrspin_lock_irqsave(l, f)      spin_lock_irqsave(l, f)
-#define nrspin_unlock_irqrestore(l, f) spin_unlock_irqrestore(l, f)
+bool _nrspin_trylock(rspinlock_t *lock);
+void _nrspin_lock(rspinlock_t *lock);
+#define nrspin_lock_irqsave(l, f)                               \
+    ({                                                          \
+        BUILD_BUG_ON(sizeof(f) != sizeof(unsigned long));       \
+        (f) = _nrspin_lock_irqsave(l);                         \
+        block_lock_speculation();                               \
+    })
+unsigned long _nrspin_lock_irqsave(rspinlock_t *lock);
+void _nrspin_unlock(rspinlock_t *lock);
+void _nrspin_lock_irq(rspinlock_t *lock);
+void _nrspin_unlock_irq(rspinlock_t *lock);
+void _nrspin_unlock_irqrestore(rspinlock_t *lock, unsigned long flags);
+
+static always_inline void nrspin_lock(rspinlock_t *lock)
+{
+    _nrspin_lock(lock);
+    block_lock_speculation();
+}
+
+static always_inline void nrspin_lock_irq(rspinlock_t *l)
+{
+    _nrspin_lock_irq(l);
+    block_lock_speculation();
+}
+
+#define nrspin_trylock(l)              lock_evaluate_nospec(_nrspin_trylock(l))
+#define nrspin_unlock(l)               _nrspin_unlock(l)
+#define nrspin_unlock_irqrestore(l, f) _nrspin_unlock_irqrestore(l, f)
+#define nrspin_unlock_irq(l)           _nrspin_unlock_irq(l)
 
 #endif /* __SPINLOCK_H__ */
-- 
2.35.3



From xen-devel-bounces@lists.xenproject.org Thu Mar 14 07:32:18 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 07:32:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692935.1080669 (Exim 4.92)
	(envelope-from )
	id 1rkfZa-0006ie-Pu; Thu, 14 Mar 2024 07:32:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692935.1080669; Thu, 14 Mar 2024 07:32:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkfZa-0006iX-N6; Thu, 14 Mar 2024 07:32:18 +0000
Received: by outflank-mailman (input) for mailman id 692935;
 Thu, 14 Mar 2024 07:32:17 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkfZZ-0006ec-Qj
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 07:32:17 +0000
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com
 [2a00:1450:4864:20::634])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id fb120c9b-e1d4-11ee-afdd-a90da7624cb6;
 Thu, 14 Mar 2024 08:32:15 +0100 (CET)
Received: by mail-ej1-x634.google.com with SMTP id
 a640c23a62f3a-a4663b29334so80786866b.0
 for ; Thu, 14 Mar 2024 00:32:15 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 qs28-20020a170906459c00b00a4550e8ae70sm426840ejc.63.2024.03.14.00.32.14
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 14 Mar 2024 00:32:15 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: fb120c9b-e1d4-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710401535; x=1711006335; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=GIcEdI7kxKhclI2LxWoGU/C+gHk87AbL9d+nyKPro2c=;
        b=Zu94OhF+EgjWRUeeFLj6xgaAY+AWVcfeMrOSjAlCOVzZ4dSV+INoCofBh0Vqmh7B0L
         miwavrrL0xs7ZijsbZ8VAJ/CejZGTxBKz8OlxLUuoFXQFBq1ngjDwuimz8M4zqIMTVjk
         EsbUHEFJ0Ka8QF9jQBRWctiCm5dfYuUz+/uxgE3rsf6XH7NgcFss45LqLG/vsG/kWzMA
         6ZvzNl6koYZH1RCebyILhfXRJ1BQ7465o9xDY4PUDdPv8VXC2hXGoOldoqpeylnVjGnN
         y11I6cu8MEwFG3YXngeJDFwD4j/RE9xGX6Mu/z+aviZc0xZH+K2tkDr76yYFFJPEoWl1
         Sdxg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710401535; x=1711006335;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=GIcEdI7kxKhclI2LxWoGU/C+gHk87AbL9d+nyKPro2c=;
        b=YdLFOvYf0lEKZkwjmx/qAZQz+Slo9xpmUeUvgv6ApLjaqgLS2RxTtENmT6J0qzifcs
         7JIE457rpdnJ8YTL0cvLeQ8OB173SUptcI6hKCw+qmbxRXvie/XmZ0DxRseKSl1Mu5j7
         ux3OWiAPc1rD6QRXikG2XJ0GLlZjw5nZVe345vs2DKB03S/crEp8ldZeEe0DEibbnOQy
         Nsl6z+LvcZ5JvwlFosh03NKViwQy7pwPiaUtZ986iWmjalw3UsyK7J+m8nN/DGAsFrBn
         usKRPzsLEHzO7muOrOAtr9pe9//KIDfnRrYIwOIuxupHiHlUt+GOXffpU3yt4fGiGIXf
         OZ+Q==
X-Forwarded-Encrypted: i=1; AJvYcCV/D/U0nUEAMSdFNH00VTjbbmE10bURVDj5X47ec/eQowQd678veFkVHBtHJ4ojx9W4py1LLu4XuItpnDr4NdGrjFYm4yQf2E4GwC4y1TA=
X-Gm-Message-State: AOJu0Yz4aCvsSgqDEq0SOWuDL9SB9rmcP0ncRBryvUoJaQ8GEXWAdpu9
	CSnl59tg89OKbQeU3GQi2VxsfSGkZVNM57g2ANQc8XQe8HCpJEHQe+fuOXVDSg==
X-Google-Smtp-Source: AGHT+IF9WzJnd6nnanJZeTCmwGwPjJUgCKSkfJVCB5DEoFNuhLDB9i6TTbrwqmpcGKAFNZwp3mPGRg==
X-Received: by 2002:a17:907:1049:b0:a46:6623:6938 with SMTP id oy9-20020a170907104900b00a4666236938mr508517ejb.50.1710401535292;
        Thu, 14 Mar 2024 00:32:15 -0700 (PDT)
Message-ID: <272d0e4a-3ac0-4b42-9297-6d476151e28d@suse.com>
Date: Thu, 14 Mar 2024 08:32:13 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 01/13] xen/spinlock: remove misra rule 21.1 violations
To: Juergen Gross 
Cc: Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 xen-devel@lists.xenproject.org
References: <20240314072029.16937-1-jgross@suse.com>
 <20240314072029.16937-2-jgross@suse.com>
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240314072029.16937-2-jgross@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 14.03.2024 08:20, Juergen Gross wrote:
> In xen spinlock code there are several violations of MISRA rule 21.1
> (identifiers starting with "__" or "_[A-Z]").
> 
> Fix them by using trailing underscores instead.
> 
> Signed-off-by: Juergen Gross 

I can live with the changes as they are, but before giving an ack, I'd
still like to ask if the moved underscores are really useful / necessary
in all cases. E.g.

> --- a/xen/include/xen/spinlock.h
> +++ b/xen/include/xen/spinlock.h
> @@ -22,7 +22,7 @@ union lock_debug {
>          bool unseen:1;
>      };
>  };
> -#define _LOCK_DEBUG { .val = LOCK_DEBUG_INITVAL }
> +#define LOCK_DEBUG_ { .val = LOCK_DEBUG_INITVAL }

... for an internal helper macro it may indeed be better to have a
trailing one here, but ...

> @@ -95,27 +95,27 @@ struct lock_profile_qhead {
>      int32_t                   idx;     /* index for printout */
>  };
>  
> -#define _LOCK_PROFILE(lockname) { .name = #lockname, .lock = &(lockname), }
> -#define _LOCK_PROFILE_PTR(name)                                               \
> -    static struct lock_profile * const __lock_profile_##name                  \
> +#define LOCK_PROFILE_(lockname) { .name = #lockname, .lock = &(lockname), }
> +#define LOCK_PROFILE_PTR_(name)                                               \
> +    static struct lock_profile * const lock_profile__##name                   \

... I'm not entirely convinced of the need for the double infix ones
here ...

> -#define SPIN_LOCK_UNLOCKED _SPIN_LOCK_UNLOCKED(NULL)
> +#define SPIN_LOCK_UNLOCKED SPIN_LOCK_UNLOCKED_(NULL)
>  #define DEFINE_SPINLOCK(l)                                                    \
> -    spinlock_t l = _SPIN_LOCK_UNLOCKED(NULL);                                 \
> -    static struct lock_profile __lock_profile_data_##l = _LOCK_PROFILE(l);    \
> -    _LOCK_PROFILE_PTR(l)
> +    spinlock_t l = SPIN_LOCK_UNLOCKED_(NULL);                                 \
> +    static struct lock_profile lock_profile_data__##l = LOCK_PROFILE_(l);     \

.... and here.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 07:32:25 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 07:32:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692937.1080680 (Exim 4.92)
	(envelope-from )
	id 1rkfZh-00078o-4F; Thu, 14 Mar 2024 07:32:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692937.1080680; Thu, 14 Mar 2024 07:32:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkfZg-00078f-VT; Thu, 14 Mar 2024 07:32:24 +0000
Received: by outflank-mailman (input) for mailman id 692937;
 Thu, 14 Mar 2024 07:32:23 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkfP8-0005cd-IZ
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 07:21:30 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7a07dfa7-e1d3-11ee-afdd-a90da7624cb6;
 Thu, 14 Mar 2024 08:21:29 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org
 [IPv6:2a07:de40:b281:104:10:150:64:97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id 7881E21CCF;
 Thu, 14 Mar 2024 07:21:29 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 2C5B413977;
 Thu, 14 Mar 2024 07:21:29 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id pRJvCXml8mV4DgAAD6G6ig
 (envelope-from ); Thu, 14 Mar 2024 07:21:29 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7a07dfa7-e1d3-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1710400889; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=lmSzZbPq+fuy/WPTZvVH6l4HYZ5NaZICGCs9qLuY+8E=;
	b=QtyrVSiL8myusCEnPXafNPhTR2V+wduG3G6xGsJX/oqnOWhS+maITNelnRsSaBaFjqi6bC
	M73SkcYctb9Vd+z0bT3jeNCpUEVs3K4x5b/GkYNsoFIG1MFztH1ux88W166noW6hNbXGmC
	JfnKCIfnn/XLqxSdbs+sEikhsZUAiBg=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1710400889; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=lmSzZbPq+fuy/WPTZvVH6l4HYZ5NaZICGCs9qLuY+8E=;
	b=QtyrVSiL8myusCEnPXafNPhTR2V+wduG3G6xGsJX/oqnOWhS+maITNelnRsSaBaFjqi6bC
	M73SkcYctb9Vd+z0bT3jeNCpUEVs3K4x5b/GkYNsoFIG1MFztH1ux88W166noW6hNbXGmC
	JfnKCIfnn/XLqxSdbs+sEikhsZUAiBg=
From: Juergen Gross 
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini ,
	Wei Liu 
Subject: [PATCH v5 10/13] xen/spinlock: let all is_locked and trylock variants return bool
Date: Thu, 14 Mar 2024 08:20:26 +0100
Message-Id: <20240314072029.16937-11-jgross@suse.com>
X-Mailer: git-send-email 2.35.3
In-Reply-To: <20240314072029.16937-1-jgross@suse.com>
References: <20240314072029.16937-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spamd-Bar: +
Authentication-Results: smtp-out1.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b=QtyrVSiL
X-Spamd-Result: default: False [1.19 / 50.00];
	 ARC_NA(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 R_DKIM_ALLOW(-0.20)[suse.com:s=susede1];
	 RCVD_DKIM_ARC_DNSWL_HI(-1.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_MISSING_CHARSET(2.50)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 BROKEN_CONTENT_TYPE(1.50)[];
	 DWL_DNSWL_MED(-2.00)[suse.com:dkim];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_SIGNED(0.00)[suse.com:s=susede1];
	 DKIM_TRACE(0.00)[suse.com:+];
	 MX_GOOD(-0.01)[];
	 RCPT_COUNT_SEVEN(0.00)[8];
	 MID_CONTAINS_FROM(1.00)[];
	 FUZZY_BLOCKED(0.00)[rspamd.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 RCVD_IN_DNSWL_HI(-0.50)[2a07:de40:b281:106:10:150:64:167:received];
	 RCVD_TLS_ALL(0.00)[];
	 BAYES_HAM(-0.00)[28.51%]
X-Spam-Score: 1.19
X-Spam-Level: *
X-Rspamd-Queue-Id: 7881E21CCF
X-Spam-Flag: NO
X-Rspamd-Server: rspamd1.dmz-prg2.suse.org

Switch the remaining trylock and is_locked variants to return bool.

Signed-off-by: Juergen Gross 
---
V5:
- new patch (Jan Beulich)
---
 xen/common/spinlock.c      | 4 ++--
 xen/include/xen/spinlock.h | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/xen/common/spinlock.c b/xen/common/spinlock.c
index a88ad9b93c..b28239f74d 100644
--- a/xen/common/spinlock.c
+++ b/xen/common/spinlock.c
@@ -393,7 +393,7 @@ static bool always_inline spin_is_locked_common(const spinlock_tickets_t *t)
     return t->head != t->tail;
 }
 
-int _spin_is_locked(const spinlock_t *lock)
+bool _spin_is_locked(const spinlock_t *lock)
 {
     return spin_is_locked_common(&lock->tickets);
 }
@@ -429,7 +429,7 @@ static bool always_inline spin_trylock_common(spinlock_tickets_t *t,
     return true;
 }
 
-int _spin_trylock(spinlock_t *lock)
+bool _spin_trylock(spinlock_t *lock)
 {
     return spin_trylock_common(&lock->tickets, &lock->debug, LOCK_PROFILE_PAR);
 }
diff --git a/xen/include/xen/spinlock.h b/xen/include/xen/spinlock.h
index 181e5c7d35..1b50a7e6a0 100644
--- a/xen/include/xen/spinlock.h
+++ b/xen/include/xen/spinlock.h
@@ -234,8 +234,8 @@ void _spin_unlock(spinlock_t *lock);
 void _spin_unlock_irq(spinlock_t *lock);
 void _spin_unlock_irqrestore(spinlock_t *lock, unsigned long flags);
 
-int _spin_is_locked(const spinlock_t *lock);
-int _spin_trylock(spinlock_t *lock);
+bool _spin_is_locked(const spinlock_t *lock);
+bool _spin_trylock(spinlock_t *lock);
 void _spin_barrier(spinlock_t *lock);
 
 static always_inline void spin_lock(spinlock_t *l)
-- 
2.35.3



From xen-devel-bounces@lists.xenproject.org Thu Mar 14 07:36:32 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 07:36:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692944.1080689 (Exim 4.92)
	(envelope-from )
	id 1rkfdf-00006R-K1; Thu, 14 Mar 2024 07:36:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692944.1080689; Thu, 14 Mar 2024 07:36:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkfdf-00006K-Gt; Thu, 14 Mar 2024 07:36:31 +0000
Received: by outflank-mailman (input) for mailman id 692944;
 Thu, 14 Mar 2024 07:36:30 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkfde-00006E-80
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 07:36:30 +0000
Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com
 [2a00:1450:4864:20::52f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 917cd516-e1d5-11ee-a1ee-f123f15fe8a2;
 Thu, 14 Mar 2024 08:36:28 +0100 (CET)
Received: by mail-ed1-x52f.google.com with SMTP id
 4fb4d7f45d1cf-5654f700705so884223a12.1
 for ; Thu, 14 Mar 2024 00:36:28 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a4-20020a170906368400b00a44936527b5sm424171ejc.99.2024.03.14.00.36.27
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 14 Mar 2024 00:36:27 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 917cd516-e1d5-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710401787; x=1711006587; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=k3dqRlcRe/o4vhkTOMhPU2eVhFfQTGacqRMrQJxnmuc=;
        b=aYynHamUuT8G1WdhCIanI6deIstgTOoHaJa7Hcg9gvU9wuES1WN6+tmXUzhWl7rXLP
         tq8GjSGG8DuPofA4pfJaWpa5uxDqCHreYdj7Ylrp/WoshSZIuxTSbZgTEJS6FU6oK+sL
         eEU8G38ppxdJ+UPszR7WPvWAxTelFo++Gaj9NlQI9mh8Ju0L4TkoamF9agChedOE0Nma
         w2lnCcNhjLW74ZDo0BI/mpYc5ecxWv6p1EhJ1Z1hNxFNgtq9ugHD0cHXq0QHtwMR5Ied
         o3QJIj0Uqj6avCupbd7omYjiiT3fAKFHCNpN0A+Znw4ULAi0zEF4PM0QSA9jJMMf7PDY
         RNpg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710401787; x=1711006587;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=k3dqRlcRe/o4vhkTOMhPU2eVhFfQTGacqRMrQJxnmuc=;
        b=THi0FH1KKofXddGrUHkFcd+DTzhtfZqw9OBfypLTrva5MCMbERJszlodzya10vrAjq
         L3IAwlrV7X845IL63xEzjP5eaCzV/OfU8nFEM93+8kovVv1r+AW7Pw3n81TQN6KaVHrB
         ng3hVf3fCsL/5zO3XOmlZ1a+rxwNzQy5b/SxQO9uwDToDmimoFBfsxIZtL/ZXqWnCm5i
         vZl9xDrEYPpwRF4BPv83jcg3crc9lSonVoHvH67W7tN+ttW7Zxa3xIiJ76sQenbTrZ44
         RupObfq4ytqjlajfPCVgaRlCRyMDfiJ+UTLL24IX16RqqiEGcWCZ3ie5kLjOo9PK0oBT
         jU2Q==
X-Forwarded-Encrypted: i=1; AJvYcCXD6wKzveT/iGIzLVWIFUPLwaMROzAp0WnFXHc+27wO/ZwXdQWTyRaIx200ApKxvgjpcP2mUuDRGck5NBxLWsCH5wg3Vrw4ljCO+DHcjr8=
X-Gm-Message-State: AOJu0YzM+aYOO725M+t4rVMsGtaVFOtNq4AlDHT6B3qmy3g5wGd0TLtP
	I+M255tGYtixVr20QrpEls/8tbfJ5Ge60OYqNnCICR3y2nbnq4jR3O18hdNKBw==
X-Google-Smtp-Source: AGHT+IFi2XyF7/kFS3zjUSX36HXApkTJui7R3HfkuSbr/GbdJuTFQgY8zWOZlNi7JJWkSLFXLL3TUg==
X-Received: by 2002:a17:907:d310:b0:a46:776b:1d5f with SMTP id vg16-20020a170907d31000b00a46776b1d5fmr117114ejc.73.1710401787629;
        Thu, 14 Mar 2024 00:36:27 -0700 (PDT)
Message-ID: <5bfd2a8e-afa9-4630-ae75-382edc943bc6@suse.com>
Date: Thu, 14 Mar 2024 08:36:25 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] docs/misra: document the expected sizes of integer types
Content-Language: en-US
To: Stefano Stabellini 
Cc: andrew.cooper3@citrix.com, bertrand.marquis@arm.com,
 george.dunlap@citrix.com, julien@xen.org, michal.orzel@amd.com,
 roger.pau@citrix.com, xen-devel@lists.xenproject.org
References: 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 14.03.2024 00:23, Stefano Stabellini wrote:
> Xen makes assumptions about the size of integer types on the various
> architectures. Document these assumptions.

This all reads as if we required exact widths. Is that really the case? Imo
we e.g. merely depend upon sizeof(int) >= 4 * CHAR_BITS. (I can see that,
while not technically required, we may want to specify CHAR_BITS == 8, at
least for the time being.)

Jan

> Signed-off-by: Stefano Stabellini 
> ---
>  docs/misra/C-language-toolchain.rst | 44 +++++++++++++++++++++++++++++
>  1 file changed, 44 insertions(+)
> 
> diff --git a/docs/misra/C-language-toolchain.rst b/docs/misra/C-language-toolchain.rst
> index b7c2000992..0d3bb2fe6e 100644
> --- a/docs/misra/C-language-toolchain.rst
> +++ b/docs/misra/C-language-toolchain.rst
> @@ -480,4 +480,48 @@ The table columns are as follows:
>       - See Section "4.13 Preprocessing Directives" of GCC_MANUAL and Section "11.1 Implementation-defined behavior" of CPP_MANUAL.
>  
>  
> +Sizes of Integer types
> +______________________
> +
> +.. list-table::
> +   :widths: 10 10 45
> +   :header-rows: 1
> +
> +   * - Type
> +     - Size
> +     - Architectures
> +
> +   * - char 
> +     - 8 bits
> +     - all architectures
> +
> +   * - short
> +     - 16 bits
> +     - all architectures
> +
> +   * - int
> +     - 32 bits
> +     - all architectures
> +
> +   * - long
> +     - 32 bits 
> +     - 32-bit architectures (x86_32, ARMv8-A AArch32, ARMv8-R AArch32)
> +
> +   * - long
> +     - 64 bits 
> +     - 64-bit architectures (x86_64, ARMv8-A AArch64, RV64, PPC64)
> +
> +   * - long long
> +     - 64-bit
> +     - all architectures
> +
> +   * - pointer
> +     - 32-bit
> +     - 32-bit architectures (x86_32, ARMv8-A AArch32, ARMv8-R AArch32)
> +
> +   * - pointer
> +     - 64-bit
> +     - 64-bit architectures (x86_64, ARMv8-A AArch64, RV64, PPC64)
> +
> +
>  END OF DOCUMENT.



From xen-devel-bounces@lists.xenproject.org Thu Mar 14 07:37:46 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 07:37:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692946.1080699 (Exim 4.92)
	(envelope-from )
	id 1rkfel-0000dA-Sv; Thu, 14 Mar 2024 07:37:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692946.1080699; Thu, 14 Mar 2024 07:37:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkfel-0000d3-Px; Thu, 14 Mar 2024 07:37:39 +0000
Received: by outflank-mailman (input) for mailman id 692946;
 Thu, 14 Mar 2024 07:37:39 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkfel-0000cv-72
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 07:37:39 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id bac60428-e1d5-11ee-afdd-a90da7624cb6;
 Thu, 14 Mar 2024 08:37:37 +0100 (CET)
Received: from truciono.bugseng.com (unknown [78.209.96.112])
 by support.bugseng.com (Postfix) with ESMTPSA id 8EE514EE0739;
 Thu, 14 Mar 2024 08:37:35 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: bac60428-e1d5-11ee-afdd-a90da7624cb6
From: Federico Serafini 
To: xen-devel@lists.xenproject.org
Cc: consulting@bugseng.com,
	Federico Serafini ,
	Jan Beulich ,
	Paul Durrant ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Andrew Cooper ,
	George Dunlap ,
	Julien Grall ,
	Stefano Stabellini ,
	Wei Liu 
Subject: [XEN PATCH v2] xen: avoid grep fodder define and undef
Date: Thu, 14 Mar 2024 08:37:28 +0100
Message-Id: <1f41883b6688d669d912f9358beccca016bd7ba8.1710401549.git.federico.serafini@bugseng.com>
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Place an "#if 0" before grep fodder #define-s and remove
the #undef-s.

This addresses violations of MISRA C:2012 Rules 20.5 ("#undef should
not be used") and 5.5 ("Identifiers shall be distinct from macro
names").

No functional change.

Signed-off-by: Federico Serafini 
---
 xen/include/xen/iommu.h    |  5 +----
 xen/include/xen/mm-frame.h | 15 +++------------
 2 files changed, 4 insertions(+), 16 deletions(-)

diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
index 9621459c63..ef57f31417 100644
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -33,13 +33,10 @@ TYPE_SAFE(uint64_t, dfn);
 #define PRI_dfn     PRIx64
 #define INVALID_DFN _dfn(~0ULL)
 
-#ifndef dfn_t
+#if 0
 #define dfn_t /* Grep fodder: dfn_t, _dfn() and dfn_x() are defined above */
 #define _dfn
 #define dfn_x
-#undef dfn_t
-#undef _dfn
-#undef dfn_x
 #endif
 
 static inline dfn_t __must_check dfn_add(dfn_t dfn, unsigned long i)
diff --git a/xen/include/xen/mm-frame.h b/xen/include/xen/mm-frame.h
index c25e836f25..d973aec901 100644
--- a/xen/include/xen/mm-frame.h
+++ b/xen/include/xen/mm-frame.h
@@ -14,13 +14,10 @@ TYPE_SAFE(unsigned long, mfn);
  */
 #define INVALID_MFN_INITIALIZER { INVALID_MFN_RAW }
 
-#ifndef mfn_t
+#if 0
 #define mfn_t /* Grep fodder: mfn_t, _mfn() and mfn_x() are defined above */
 #define _mfn
 #define mfn_x
-#undef mfn_t
-#undef _mfn
-#undef mfn_x
 #endif
 
 static inline mfn_t __must_check mfn_add(mfn_t mfn, unsigned long i)
@@ -53,13 +50,10 @@ TYPE_SAFE(unsigned long, gfn);
  */
 #define INVALID_GFN_INITIALIZER { INVALID_GFN_RAW }
 
-#ifndef gfn_t
+#if 0
 #define gfn_t /* Grep fodder: gfn_t, _gfn() and gfn_x() are defined above */
 #define _gfn
 #define gfn_x
-#undef gfn_t
-#undef _gfn
-#undef gfn_x
 #endif
 
 static inline gfn_t __must_check gfn_add(gfn_t gfn, unsigned long i)
@@ -85,13 +79,10 @@ static inline bool gfn_eq(gfn_t x, gfn_t y)
 TYPE_SAFE(unsigned long, pfn);
 #define PRI_pfn          "05lx"
 
-#ifndef pfn_t
+#if 0
 #define pfn_t /* Grep fodder: pfn_t, _pfn() and pfn_x() are defined above */
 #define _pfn
 #define pfn_x
-#undef pfn_t
-#undef _pfn
-#undef pfn_x
 #endif
 
 #endif /* __XEN_FRAME_NUM_H__ */
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Thu Mar 14 07:43:06 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 07:43:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692955.1080708 (Exim 4.92)
	(envelope-from )
	id 1rkfjv-0002wP-FQ; Thu, 14 Mar 2024 07:42:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692955.1080708; Thu, 14 Mar 2024 07:42:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkfjv-0002wI-CZ; Thu, 14 Mar 2024 07:42:59 +0000
Received: by outflank-mailman (input) for mailman id 692955;
 Thu, 14 Mar 2024 07:42:58 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkfju-0002wC-1B
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 07:42:58 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 79553d23-e1d6-11ee-afdd-a90da7624cb6;
 Thu, 14 Mar 2024 08:42:57 +0100 (CET)
Received: from nico.bugseng.com (unknown [46.228.253.194])
 by support.bugseng.com (Postfix) with ESMTPSA id 5FC174EE0739;
 Thu, 14 Mar 2024 08:42:55 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 79553d23-e1d6-11ee-afdd-a90da7624cb6
From: Nicola Vetrini 
To: nicola.vetrini@bugseng.com,
	xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org,
	michal.orzel@amd.com,
	xenia.ragiadakou@amd.com,
	ayan.kumar.halder@amd.com,
	consulting@bugseng.com,
	bertrand.marquis@arm.com,
	julien@xen.org,
	Jan Beulich ,
	Andrew Cooper 
Subject: [XEN PATCH] amd/iommu: add fixed size to function parameter of array type
Date: Thu, 14 Mar 2024 08:42:52 +0100
Message-Id: <533a2d4f0c92d7fe92aa200b64434389de546f69.1710343652.git.nicola.vetrini@bugseng.com>
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

The 'cmd' parameter of amd_iommu_send_guest_cmd is passed
to a function that expects arrays of size 4, therefore
specifying explicitly the size also in amd_iommu_send_guest_cmd
allows not to accidentally pass a smaller array or assume that
send_iommu_command handles array sizes >4 correctly.

No functional change.

Signed-off-by: Nicola Vetrini 
---
All current users pass an array of size 4, hence this patch is addressing
a potential issue noticed by the analyzer in the context of Rule 17.5
("The function argument corresponding to a parameter declared to have an array
type shall have an appropriate number of elements"), not an actual problem in
the sources.
---
 xen/drivers/passthrough/amd/iommu.h     | 2 +-
 xen/drivers/passthrough/amd/iommu_cmd.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/drivers/passthrough/amd/iommu.h b/xen/drivers/passthrough/amd/iommu.h
index 1b62c083ba67..be82bd950e30 100644
--- a/xen/drivers/passthrough/amd/iommu.h
+++ b/xen/drivers/passthrough/amd/iommu.h
@@ -346,7 +346,7 @@ void cf_check amd_iommu_crash_shutdown(void);
 
 /* guest iommu support */
 #ifdef CONFIG_HVM
-void amd_iommu_send_guest_cmd(struct amd_iommu *iommu, u32 cmd[]);
+void amd_iommu_send_guest_cmd(struct amd_iommu *iommu, u32 cmd[4]);
 void guest_iommu_add_ppr_log(struct domain *d, u32 entry[]);
 void guest_iommu_add_event_log(struct domain *d, u32 entry[]);
 int guest_iommu_init(struct domain* d);
diff --git a/xen/drivers/passthrough/amd/iommu_cmd.c b/xen/drivers/passthrough/amd/iommu_cmd.c
index 49b9fcac9410..321a814eb810 100644
--- a/xen/drivers/passthrough/amd/iommu_cmd.c
+++ b/xen/drivers/passthrough/amd/iommu_cmd.c
@@ -390,7 +390,7 @@ void amd_iommu_flush_all_caches(struct amd_iommu *iommu)
     flush_command_buffer(iommu, 0);
 }
 
-void amd_iommu_send_guest_cmd(struct amd_iommu *iommu, u32 cmd[])
+void amd_iommu_send_guest_cmd(struct amd_iommu *iommu, u32 cmd[4])
 {
     send_iommu_command(iommu, cmd);
     /* TBD: Timeout selection may require peeking into cmd[]. */
-- 
2.34.1


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 08:18:06 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 08:18:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692970.1080725 (Exim 4.92)
	(envelope-from )
	id 1rkgHf-0002oZ-J7; Thu, 14 Mar 2024 08:17:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692970.1080725; Thu, 14 Mar 2024 08:17:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkgHf-0002oS-Fm; Thu, 14 Mar 2024 08:17:51 +0000
Received: by outflank-mailman (input) for mailman id 692970;
 Thu, 14 Mar 2024 08:17:50 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkgHd-0002oM-Uh
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 08:17:49 +0000
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com
 [2a00:1450:4864:20::536])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 57f6501d-e1db-11ee-afdd-a90da7624cb6;
 Thu, 14 Mar 2024 09:17:48 +0100 (CET)
Received: by mail-ed1-x536.google.com with SMTP id
 4fb4d7f45d1cf-5683576ea18so789466a12.3
 for ; Thu, 14 Mar 2024 01:17:48 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 r17-20020a1709067fd100b00a466782e438sm457427ejs.139.2024.03.14.01.17.47
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 14 Mar 2024 01:17:47 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 57f6501d-e1db-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710404268; x=1711009068; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Nso9/bITkvgqCNF2Pq/xJjH1cfXae86AGuoS4vdniSY=;
        b=QWPKJFGwM1B8Et8l84kySGJ/o3FNe4TfpmzJ8dYEYLXof05o1ZRRaF4rlWiVRv77kJ
         sXr1CzgMz2OPXAAnMVUS8z7D6q+R4AaUoxsQZFMDics8eayrkLZ/5eYJVyjIvkfjCh/a
         2Rc2U1Vijn5FgZjwTDBKnGyjYdcv+c1YCfZY+pTVHuVIC3VC6np6o4g/Ns2Ic31nEiZv
         KCGV/dQYBFh14fjLPd149r/6XGiOhqthkAvtQHyaAuM6tQHplc0+c/IJuJ1z+jFXkLnd
         Mlo26Kkqi2MsHbVCe7WWKYIR6MLHBcZQMw21ua1xStXG2B50fQkcsL7tfEx4EHtiwHta
         udpg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710404268; x=1711009068;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Nso9/bITkvgqCNF2Pq/xJjH1cfXae86AGuoS4vdniSY=;
        b=QumkLwO5N0WAgHoDgWs5+wzCBUNqtwkE6/eaKMiaEpsobJPda+uFc8jT+JxyBUf8VW
         HPVFZzSPfQWS8tAPI3FDmaam0/fpslEvN8hketKYOFAL18F8RsyKJPNuuI+xrpkHSmqt
         nn6CdiA+cFkaDN/EaIR/l+QzlPy+PB5urt06BSLt5aL50id1uaJwFteO17xWd0JysXnr
         p7pvsIMIHHhtRDHPEORlQgsc1kEvITpnhAEDY4AjFQZkhy7AdkNV2oukAFprVGqf+fF4
         IAW955zp+leqqUyUPvXSnzoBk/D+8VLms1S5Jgg7QlHOdiy4d/+ZSNSB6TGlvotC5JXw
         7mZw==
X-Forwarded-Encrypted: i=1; AJvYcCWOfV5gGHrwBSPF8vvtALonX/tFJUiaYQTlj2wDDodSE9MwcP6qX8FYvpDByD1U64E6pj/KnWwaPK0ziApBLA7JT/Kkyt7R0QbBmTL3Jv8=
X-Gm-Message-State: AOJu0Yz61IuArqyJi2vrxjC2vQWVuIbC2AP5QNQOk+0KerRAom2PQCy/
	DblFIRwZyrF4YBpLYUYrljVn4lhFW1MS7Ec4c4kKkd2nfwudXEMokdv+mkvc3g==
X-Google-Smtp-Source: AGHT+IGJiLsULhyDKRA22nVIlHVWOZZryKJfMZZoe7mPS6OErLfdwarNmQIs+BYR+gq8yUbT8hx4xw==
X-Received: by 2002:a17:907:c78b:b0:a46:703d:55e2 with SMTP id tz11-20020a170907c78b00b00a46703d55e2mr701293ejc.53.1710404268090;
        Thu, 14 Mar 2024 01:17:48 -0700 (PDT)
Message-ID: <62af3aad-3020-4d24-9dd4-ec4eafea0803@suse.com>
Date: Thu, 14 Mar 2024 09:17:46 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/2] x86/entry: Introduce POP_GPRS
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Wei Liu , Xen-devel 
References: <20240313142641.2150302-1-andrew.cooper3@citrix.com>
 <20240313142641.2150302-2-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240313142641.2150302-2-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 13.03.2024 15:26, Andrew Cooper wrote:
> The macro named RESTORE_ALL has several problems.  It adjusts the stack
> pointer despite this not being clear to the caller.  It also goes against
> recommendations in the optimisation guides because of trying to do too many
> things at once.  (i.e. there's a reason why compilers don't emit code looking
> like this.)

Not anymore; I'm sure they used to over a certain period of time, which is
why 4d246723a85a ("x86: use MOV instead of PUSH/POP when saving/restoring
register state") was created in the first place (and which you now say was
a mistake, or at least has become a mistake in the over 10 years since then).

> Introduce a new POP_GPRS macro which only POPs GPRs.  Use it for the HVM paths
> which are already using POPs.
> 
> Also use it for restore_all_{xen,guest}().  This saves most of a cacheline
> worth of code from two fastpaths:
> 
>   add/remove: 0/0 grow/shrink: 0/2 up/down: 0/-99 (-99)
>   Function                                     old     new   delta
>   restore_all_guest                            378     330     -48
>   restore_all_xen                              165     114     -51
> 
> but it also avoids having an explicit modification to the stack pointer
> between %rsp-relative accesses, which avoids stalls in the stack-engine
> optimisations in some microarchitectures.

Is there such a rule? All I was able to find (and even that only with
quite a bit of effort, because the section it's in wouldn't have had
me think of a stack pointer rule being there) is

"Assembly/Compiler Coding Rule 22. (M impact, M generality) Avoid
 putting explicit references to ESP in a sequence of stack operations
 (POP, PUSH, CALL, RET)."

I actually wonder whether %rsp really is special in the way you
indicate - other registers, when used for memory accesses and being
updated ought to have a similar stall issue?

> --- a/xen/arch/x86/hvm/svm/entry.S
> +++ b/xen/arch/x86/hvm/svm/entry.S
> @@ -74,22 +74,9 @@ __UNLIKELY_END(nsvm_hap)
>          ALTERNATIVE "", svm_vmentry_spec_ctrl, X86_FEATURE_SC_MSR_HVM
>          ALTERNATIVE "", DO_SPEC_CTRL_DIV, X86_FEATURE_SC_DIV
>  
> -        pop  %r15
> -        pop  %r14
> -        pop  %r13
> -        pop  %r12
> -        pop  %rbp
>          mov  VCPU_svm_vmcb_pa(%rbx),%rax
> -        pop  %rbx
> -        pop  %r11
> -        pop  %r10
> -        pop  %r9
> -        pop  %r8
> -        pop  %rcx /* Skip %rax: restored by VMRUN. */
> -        pop  %rcx
> -        pop  %rdx
> -        pop  %rsi
> -        pop  %rdi
> +
> +        POP_GPRS rax=%rcx /* Skip %rax.  It's restored by VMRUN. */

In light of you having asked my to try and decouple ABI and internal stack
frame layout, I'm wary of encoding a dependency on the ordering of registers
in the frame at a use site like this one. Imo the argument ought to merely
indicate "skip %rax", with the macro taking care of how that skipping is
actually carried out.

> @@ -696,20 +697,19 @@ UNLIKELY_END(exit_cr3)
>          /* WARNING! `ret`, `call *`, `jmp *` not safe beyond this point. */
>          SPEC_CTRL_EXIT_TO_XEN /* Req: %r12=ist_exit %r14=end %rsp=regs, Clob: abcd */
>  
> -        RESTORE_ALL adj=8
> +        POP_GPRS
>  
>          /*
>           * When the CPU pushed this exception frame, it zero-extended eflags.
>           * For an IST exit, SPEC_CTRL_EXIT_TO_XEN stashed shadow copies of
>           * spec_ctrl_flags and ver_sel above eflags, as we can't use any GPRs,
>           * and we're at a random place on the stack, not in a CPUFINFO block.
> -         *
> -         * Account for ev/ec having already been popped off the stack.
>           */
>          SPEC_CTRL_COND_VERW \
> -            scf=STK_REL(EFRAME_shadow_scf, EFRAME_rip), \
> -            sel=STK_REL(EFRAME_shadow_sel, EFRAME_rip)
> +            scf=STK_REL(EFRAME_shadow_scf, EFRAME_error_code), \
> +            sel=STK_REL(EFRAME_shadow_sel, EFRAME_error_code)
>  
> +        add   $8, %rsp
>          iretq

How is this ADD different from the RESTORE_ALL one, in particular in light
of the ORM rule quoted above (which surely extends to IRET as well)? It
ought to be possible to avoid, by having POP_GPRS (optionally) move the
%r15 value into the error code slot first thing (i.e. before %rsp starts
being updated), and then having "pop %r15" last.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 08:26:00 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 08:26:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692972.1080735 (Exim 4.92)
	(envelope-from )
	id 1rkgPT-0005I1-Ay; Thu, 14 Mar 2024 08:25:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692972.1080735; Thu, 14 Mar 2024 08:25:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkgPT-0005Hu-8K; Thu, 14 Mar 2024 08:25:55 +0000
Received: by outflank-mailman (input) for mailman id 692972;
 Thu, 14 Mar 2024 08:25:54 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkgPS-0005Ho-Km
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 08:25:54 +0000
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com
 [2a00:1450:4864:20::52a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7859c334-e1dc-11ee-afdd-a90da7624cb6;
 Thu, 14 Mar 2024 09:25:52 +0100 (CET)
Received: by mail-ed1-x52a.google.com with SMTP id
 4fb4d7f45d1cf-5684ea117a3so881250a12.0
 for ; Thu, 14 Mar 2024 01:25:52 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 sa37-20020a1709076d2500b00a4635a21ff0sm467385ejc.38.2024.03.14.01.25.51
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 14 Mar 2024 01:25:51 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7859c334-e1dc-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710404752; x=1711009552; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=E4BQVZCAUZLtOYbg/K1gx8DsAF2ZNaLfyFD+765ChUs=;
        b=S2E6PyR3X8YA6JUy4BOQzjXtxe2Q3v44QmbQfr+IAZV1qQvqoPpuFnGjJrtpzF7ISj
         B7o61CZj5RtO20s6DkjuivOYRvF9MR3wpSJCcphQc2aWN4M80zrPjgCR3+n2sgWGz6HE
         GME+FUfmzF4uD+cXOqe4C7CKpR0SzJhPZm5iNX3KmIJnlhAgp6djNEfgJcJrLwhvaw9L
         aO6PhAMlUIBbRFiyCNfAac/uFtZo3hMXuLKgs43AdS9tqIiJWZkY4rP6xCHPMDGGhgVv
         pb9SH44g5TEMJFPt6mmXz5PiqZ9tWmuB19Hj03cBqTQoobAReaZP5jX1fL42sSMmfKPz
         SUSw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710404752; x=1711009552;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=E4BQVZCAUZLtOYbg/K1gx8DsAF2ZNaLfyFD+765ChUs=;
        b=dRbRPOnzDbDRzwoJpD6tb5AcuUxgzTnt+zaJ4htvgAZiYfZtoyGHSj4B45FgZ0BpId
         V3TIwIhvPoHb8mv6oL+m9K/GBDNw/By+UyatPhQ1P9qlYmmoH962INAwYE43LlY3LW38
         Du4XvPwCsGUlSeAtwoQ6CGUGzb6sbIXuHf29zsDQcFFSE85ik40NbuYyYugh/y3axioY
         dXMVP3Y07Xyw1D8puCld0mltgUohR7m9mjJ5fjK/5UPHdBAcX1cMOuwmitW/IVoo+xO9
         66/HFeFtATLgbn11OIyXbmX0KS3fWZk1dtgzzCH9Mp//AA1yAZfF6yv/0A69QNeRpFvk
         rbwA==
X-Forwarded-Encrypted: i=1; AJvYcCVB887i37/ZWDFTq/jmmBL8xmvXEZ1VCa/1oZPV5leLzoDztAdd0uCNs4LNt8BJINTf+alykFEEZ5yKEr5ctvPX6wir02qqJUGdZFQFw5M=
X-Gm-Message-State: AOJu0YyAk6lgz6uqRzS9Y2WBWiylpOncAp3A69OvBeLBFjWRuhR/++cv
	m7avEeiKIYBB0ZGUcybzVdRfVE8St6Q/iBVOplHK5D0iYwKcUOFpLWTeVCnJ3A==
X-Google-Smtp-Source: AGHT+IFJxzEXEIIRmszXVnSvDzECzMhxKKcMo2qJi3iESG9UivHQQgDKP6KO6UK4SpqW3hvu8TVw7A==
X-Received: by 2002:a17:907:a705:b0:a46:4d97:82a3 with SMTP id vw5-20020a170907a70500b00a464d9782a3mr732254ejc.59.1710404751893;
        Thu, 14 Mar 2024 01:25:51 -0700 (PDT)
Message-ID: <4fd5140b-0a34-464c-8ed8-4c38a094e9b1@suse.com>
Date: Thu, 14 Mar 2024 09:25:50 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/2] x86/entry: Delete RESTORE_ALL
Content-Language: en-US
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Wei Liu , Xen-devel 
References: <20240313142641.2150302-1-andrew.cooper3@citrix.com>
 <20240313142641.2150302-3-andrew.cooper3@citrix.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240313142641.2150302-3-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 13.03.2024 15:26, Andrew Cooper wrote:
> There is only a single user now, and it's the one odd case.  Inline and
> simplify it to just the compat case.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 

> In principle we want to delay the %rsp adjustment until after VERW, but that
> turns disp8's into disp32's, making the overall code size larger.

While beneficial for SPEC_CTRL_COND_VERW, that might then harm the IRETQ.
So aiui neither placement is ideal, and hence the Disp consideration
is the determining factor either way.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 08:27:57 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 08:27:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692968.1080745 (Exim 4.92)
	(envelope-from )
	id 1rkgRN-0005oO-LN; Thu, 14 Mar 2024 08:27:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692968.1080745; Thu, 14 Mar 2024 08:27:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkgRN-0005oH-Ii; Thu, 14 Mar 2024 08:27:53 +0000
Received: by outflank-mailman (input) for mailman id 692968;
 Thu, 14 Mar 2024 08:13:24 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkgDK-0002aN-WA
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 08:13:23 +0000
Received: from mail-4323.proton.ch (mail-4323.proton.ch [185.70.43.23])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b7044d2d-e1da-11ee-a1ee-f123f15fe8a2;
 Thu, 14 Mar 2024 09:13:19 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b7044d2d-e1da-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zamaudio.com;
	s=protonmail2; t=1710403996; x=1710663196;
	bh=QX53ikl/A6rMwZE/LD2LcGZ0Q9sfRlbAsySKSrfXqK4=;
	h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References:
	 Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
	 Message-ID:BIMI-Selector;
	b=V0Kck0tDfBs4pvj9H1hF6PLb9iAB4i695ciID5PLM1yecDAwThq37UUSgD0dzxDPu
	 GobFkvPpWVTtjze+9jWhoqklXe1M44QBmAkB23RcW3tWd1dDjhXHkxtzWWdGZYhjbo
	 t7l3/R/Tmx9SyXBG/wOz4pXh0EW4cnbIt12f9/qdmqD4G+cxh0ZYHDJOmhGRNvJu24
	 Uc7yL8DsaEYVxUtMgsbcbGGi80/+BiktE+kEaUV+r0Ll9FotioYrH+cuHEnwlKGIbh
	 ONh8nvLBHTXoWYPvbOg0dGDeh50yTmNyaw4htiqi2QwooqRCce5UvgssGKvGuCoPhC
	 WnWGa+h0CoqRA==
Date: Thu, 14 Mar 2024 08:12:55 +0000
To: grub-devel@gnu.org, ross.lagerwall@citrix.com
From: Damien Zammit 
Cc: jbeulich@suse.com, xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com, daniel.kiper@oracle.com
Subject: Re: [PATCH 1/7] multiboot2: Add load type header and support for the PE binary type
Message-ID: 
In-Reply-To: 
References: <20240313150748.791236-1-ross.lagerwall@citrix.com> <20240313150748.791236-2-ross.lagerwall@citrix.com> 
Feedback-ID: 43209410:user:proton
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="b1_5UKU0ZFo1nzlsuNs6kMAoj1fU1IoP1eCT3hclJ8"

This is a multi-part message in MIME format.

--b1_5UKU0ZFo1nzlsuNs6kMAoj1fU1IoP1eCT3hclJ8
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64

SGksIEkgc2F3IHRoaXMgb24gdGhlIGxpc3QgYW5kIGhhdmUgY29uY2VybnM6CgotLS0tLS0tLSBP
cmlnaW5hbCBNZXNzYWdlIC0tLS0tLS0tCk9uIDE0IE1hciAyMDI0LCA2OjI04oCvcG0sIEphbiBC
ZXVsaWNoIHZpYSBHcnViLWRldmVsIDwgZ3J1Yi1kZXZlbEBnbnUub3JnPiB3cm90ZToKT24gMTMu
MDMuMjAyNCAxNjowNywgUm9zcyBMYWdlcndhbGwgd3JvdGU6Cj4+IEluIGFkZGl0aW9uIHRvIHRo
ZSBleGlzdGluZyBhZGRyZXNzIGFuZCBFTEYgbG9hZCB0eXBlcywgc3BlY2lmeSBhIG5ldwo+PiBv
cHRpb25hbCBQRSBiaW5hcnkgbG9hZCB0eXBlLiBUaGlzIG5ldyB0eXBlIGlzIGEgdXNlZnVsIGFk
ZGl0aW9uIHNpbmNlCj4+IFBFIGJpbmFyaWVzIGNhbiBiZSBzaWduZWQgYW5kIHZlcmlmaWVkIChp
LmUuIHVzZWQgd2l0aCBTZWN1cmUgQm9vdCkuCgo+IEFuZCB0aGUgY29uc2lkZXJhdGlvbiB0byBo
YXZlIEVMRiBzaWduYWJsZSAoYnkgd2hhdGV2ZXIgZXh0ZW5zaW9uIHRvIHRoZSBFTEYgc3BlYykg
d2VudCBub3doZXJlPyBKYW4KCklmIHRoZSBwdXJwb3NlIG9mIHNpZ25pbmcgYmluYXJpZXMgaXMg
dG8gcHJldmVudCB0aGVpciBleGVjdXRpb24gdW5sZXNzIHRoZXkgYXJlIHNpZ25lZCBieSB0aGVp
ciBvd25lciwgdGhpcyBpcyBNQUxXQVJFIHVubGVzcyB0aGUgZW5kIHVzZXIgY2FuIHJlcGxhY2Ug
dGhlIGtleXMgd2l0aCBvbmUgb2YgdGhlaXIgY2hvb3NpbmcuCkFkZGluZyBhIGZpZWxkIHRvIGVs
ZiB0byBwcm92aWRlIHRoaXMgZmVhdHVyZSBpcyBJTUhPIGFza2luZyBmb3IgdHJvdWJsZSBiZWNh
dXNlIHRoZSBrZXkgaXMgc3RvcmVkIGVsc2V3aGVyZSBhbmQgdGhlcmUgaXMgbm90aGluZyB0byBw
cmV2ZW50IGFidXNlIG9mIHRoaXMgZmllbGQgdG8gZGVueSB1c2VycyB0aGVpciBmcmVlZG9tIHRv
IHJ1biBjb2RlLCAoaWUgYnkgbm90IHByb3ZpZGluZyB0aGVtIHRoZSBrZXkgb3IgYSBndWFyYW50
ZWVkIG1lY2hhbmlzbSBmb3IgcHJvdmlkaW5nIHRoZWlyIG93bikuCgpPbiB0aGF0IG5vdGUsIHdo
eSBpcyBpdCBzdWNoIGEgdXNlZnVsIGZlYXR1cmUgdG8gcmVzdHJpY3QgdGhlIGZyZWVkb20gdG8g
cnVuIGNvZGUgaW4gZ3J1Yj8gSWYgZ3J1YiBzZWxlY3RzIG1hbHdhcmUgdG8gZXhlY3V0ZSwgdGhl
IHVzZXIgbXVzdCBoYXZlIGNob3NlbiB0byBydW4gaXQgLSBvciBncnViIGl0c2VsZiBpcyBjb21w
cm9taXNlZD8KCkRvIHlvdSB0aGluayB0aGF0IGxvY2tpbmcgYmluYXJpZXMgZG93biBpcyB0aGUg
ZnV0dXJlIGZvciB1c2VycyB0byBlbnN1cmUgdGhlaXIgb3duIHNlY3VyaXR5IG9yIGl0IGlzIGFj
Y2VwdGFibGUgZm9yIDNyZCBwYXJ0aWVzIHRvIGhpZGUgcGxhdGZvcm0ga2V5cyB0byBsb2NrIGFs
bCBzeXN0ZW1zIGRvd24sIGV2ZW4gYnkgYmluYXJ5PwoKSSdtIG5vdCBjb252aW5jZWQuCgpEYW1p
ZW4gWmFtbWl0CkdOVS9IdXJkIGhhY2tlcg==

--b1_5UKU0ZFo1nzlsuNs6kMAoj1fU1IoP1eCT3hclJ8
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64

SGksIEkgc2F3IHRoaXMgb24gdGhlIGxpc3QgYW5kIGhhdmUgY29uY2VybnM6PGJyPjxicj4tLS0t
LS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tLS0tPGJyPk9uIDE0IE1hciAyMDI0LCA2OjI04oCv
cG0sIEphbiBCZXVsaWNoIHZpYSBHcnViLWRldmVsICZsdDsgZ3J1Yi1kZXZlbEBnbnUub3JnJmd0
OyB3cm90ZTo8YnI+T24gMTMuMDMuMjAyNCAxNjowNywgUm9zcyBMYWdlcndhbGwgd3JvdGU6IDxi
cj4mZ3Q7Jmd0OyBJbiBhZGRpdGlvbiB0byB0aGUgZXhpc3RpbmcgYWRkcmVzcyBhbmQgRUxGIGxv
YWQgdHlwZXMsIHNwZWNpZnkgYSBuZXc8YnI+Jmd0OyZndDsgb3B0aW9uYWwgUEUgYmluYXJ5IGxv
YWQgdHlwZS4gVGhpcyBuZXcgdHlwZSBpcyBhIHVzZWZ1bCBhZGRpdGlvbiBzaW5jZSA8YnI+Jmd0
OyZndDsgUEUgYmluYXJpZXMgY2FuIGJlIHNpZ25lZCBhbmQgdmVyaWZpZWQgKGkuZS4gdXNlZCB3
aXRoIFNlY3VyZSBCb290KS48YnI+PGJyPiZndDsgQW5kIHRoZSBjb25zaWRlcmF0aW9uIHRvIGhh
dmUgRUxGIHNpZ25hYmxlIChieSB3aGF0ZXZlciBleHRlbnNpb24gdG8gdGhlIEVMRiBzcGVjKSB3
ZW50IG5vd2hlcmU/IEphbiA8YnI+PGJyPklmIHRoZSBwdXJwb3NlIG9mIHNpZ25pbmcgYmluYXJp
ZXMgaXMgdG8gcHJldmVudCB0aGVpciBleGVjdXRpb24gdW5sZXNzIHRoZXkgYXJlIHNpZ25lZCBi
eSB0aGVpciBvd25lciwgdGhpcyBpcyBNQUxXQVJFIHVubGVzcyB0aGUgZW5kIHVzZXIgY2FuIHJl
cGxhY2UgdGhlIGtleXMgd2l0aCBvbmUgb2YgdGhlaXIgY2hvb3NpbmcuPGJyPkFkZGluZyBhIGZp
ZWxkIHRvIGVsZiB0byBwcm92aWRlIHRoaXMgZmVhdHVyZSBpcyBJTUhPIGFza2luZyBmb3IgdHJv
dWJsZSBiZWNhdXNlIHRoZSBrZXkgaXMgc3RvcmVkIGVsc2V3aGVyZSBhbmQgdGhlcmUgaXMgbm90
aGluZyB0byBwcmV2ZW50IGFidXNlIG9mIHRoaXMgZmllbGQgdG8gZGVueSB1c2VycyB0aGVpciBm
cmVlZG9tIHRvIHJ1biBjb2RlLCAoaWUgYnkgbm90IHByb3ZpZGluZyB0aGVtIHRoZSBrZXkgb3Ig
YSBndWFyYW50ZWVkIG1lY2hhbmlzbSBmb3IgcHJvdmlkaW5nIHRoZWlyIG93bikuPGJyPjxicj5P
biB0aGF0IG5vdGUsIHdoeSBpcyBpdCBzdWNoIGEgdXNlZnVsIGZlYXR1cmUgdG8gcmVzdHJpY3Qg
dGhlIGZyZWVkb20gdG8gcnVuIGNvZGUgaW4gZ3J1Yj8gIElmIGdydWIgc2VsZWN0cyBtYWx3YXJl
IHRvIGV4ZWN1dGUsIHRoZSB1c2VyIG11c3QgaGF2ZSBjaG9zZW4gdG8gcnVuIGl0IC0gb3IgZ3J1
YiBpdHNlbGYgaXMgY29tcHJvbWlzZWQ/PGJyPjxicj5EbyB5b3UgdGhpbmsgdGhhdCBsb2NraW5n
IGJpbmFyaWVzIGRvd24gaXMgdGhlIGZ1dHVyZSBmb3IgdXNlcnMgdG8gZW5zdXJlIHRoZWlyIG93
biBzZWN1cml0eSBvciBpdCBpcyBhY2NlcHRhYmxlIGZvciAzcmQgcGFydGllcyB0byBoaWRlIHBs
YXRmb3JtIGtleXMgdG8gbG9jayBhbGwgc3lzdGVtcyBkb3duLCBldmVuIGJ5IGJpbmFyeT88YnI+
PGJyPkknbSBub3QgY29udmluY2VkLjxicj48YnI+RGFtaWVuIFphbW1pdDxicj5HTlUvSHVyZCBo
YWNrZXI8YnI+PGJyPjxicj4=


--b1_5UKU0ZFo1nzlsuNs6kMAoj1fU1IoP1eCT3hclJ8--



From xen-devel-bounces@lists.xenproject.org Thu Mar 14 08:32:36 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 08:32:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.692976.1080755 (Exim 4.92)
	(envelope-from )
	id 1rkgVr-0008MA-5t; Thu, 14 Mar 2024 08:32:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 692976.1080755; Thu, 14 Mar 2024 08:32:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkgVr-0008M3-3A; Thu, 14 Mar 2024 08:32:31 +0000
Received: by outflank-mailman (input) for mailman id 692976;
 Thu, 14 Mar 2024 08:32:30 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkgVq-0008Lx-Bu
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 08:32:30 +0000
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com
 [2a00:1450:4864:20::52d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 64d26b68-e1dd-11ee-afdd-a90da7624cb6;
 Thu, 14 Mar 2024 09:32:29 +0100 (CET)
Received: by mail-ed1-x52d.google.com with SMTP id
 4fb4d7f45d1cf-5654f700705so953495a12.1
 for ; Thu, 14 Mar 2024 01:32:29 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 vi2-20020a170907d40200b00a45c8b6e965sm474970ejc.3.2024.03.14.01.32.27
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 14 Mar 2024 01:32:28 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 64d26b68-e1dd-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710405149; x=1711009949; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=eAq5lHzW3IOwT/BTYiASAU2qB4P+zsotmrOl4INl2+Q=;
        b=MKp7E2uqKWtCFRLkHWx5m+C5iDaRWC2u2TwqdsYNSQ0nMGmIhqr3Xhm/A/9fpkNswj
         +HAes7apsoJPT/BHbHC+NVb5mp8mvMrZ9JL3keE080+j3oV1XxD51YM7vk7Q7lWFmmzE
         Q2qbQj+1vkcPTeXaer2p8fMWeUGsZPgN9rQkc4lKruPlUFzm8CCrrE2oiU4rtAu5Rsoz
         YGHty+AGbmp4ETl5XK53X7HFbM395/DGsLvf1w2aT3X3Ju/DQl7W6kP4JPKbGAFYvuDp
         0pvRIiz2WdsT5xEsZIOFia2/x2LQcom5Zq6zTvXeLpQ+6el/1AVXoPjX0Q9rvKkInCaa
         KodQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710405149; x=1711009949;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=eAq5lHzW3IOwT/BTYiASAU2qB4P+zsotmrOl4INl2+Q=;
        b=SRG67mEDlBzS3mB+4yALwMFqrjtoGjcuPwR0slzCFuI/SuTn4vycwTaDNN1LTLD7rl
         NsZsEckLYJ1MvthZVYzV3h59gIAP/BTYD2ZlmRPImdRnIu1tEFriAOw4HjUUx82XvNSd
         NDqZmk3Mi/b1djCOyfF7rxWxrCCBzzIpuh3qlMwi7KQ2dfKFiphlU7jVIO/C55AYfpjI
         bvFiC6lyDOwv8Enc7ECwtOXrk2YwqACZH9U3iswmzQ6E4e4Hp/ypcdjypys9Ke0tQDOE
         r/L9D02YYhMaaYMoijjo42rrGZhMpeFcB4Cfuu8FeTVGXOY32md5i3zO7IIZHHvc9RWH
         rd9Q==
X-Forwarded-Encrypted: i=1; AJvYcCX8M72xjZrBaK2/uNAHuv3uMEBP+ggAhQZuFtKrO//l1Rh+pbZP6ZdyB/JNv+C4LVqkTIpXraUZeF6cvGkuVoAWRpvjssxLK/kMiUehGlw=
X-Gm-Message-State: AOJu0Yw+jJc4Zf30AWRSF7CasAbmQVdXoAKeFHm5bcUKPs6kmAGyy0O6
	LmQUj3xV/oK+O8H4n/7ayxJ/JoILpAbagT3+kLiV3i5koXHeRJn9v51aWb5KzA==
X-Google-Smtp-Source: AGHT+IHpzrOffIcWE2Wi3cSg242I/M5nZ1oNnuAYKUMyt9f48X1FwHGz2/DA09gA2fIpxQ/VyKuWKQ==
X-Received: by 2002:a17:907:2d21:b0:a43:bf25:989 with SMTP id gs33-20020a1709072d2100b00a43bf250989mr879258ejc.9.1710405148691;
        Thu, 14 Mar 2024 01:32:28 -0700 (PDT)
Message-ID: <6186b676-660c-4bfa-a825-18ff7f0d7f62@suse.com>
Date: Thu, 14 Mar 2024 09:32:27 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH] amd/iommu: add fixed size to function parameter of
 array type
Content-Language: en-US
To: Nicola Vetrini 
Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com,
 ayan.kumar.halder@amd.com, consulting@bugseng.com, bertrand.marquis@arm.com,
 julien@xen.org, Andrew Cooper ,
 xen-devel@lists.xenproject.org
References: <533a2d4f0c92d7fe92aa200b64434389de546f69.1710343652.git.nicola.vetrini@bugseng.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <533a2d4f0c92d7fe92aa200b64434389de546f69.1710343652.git.nicola.vetrini@bugseng.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 14.03.2024 08:42, Nicola Vetrini wrote:
> The 'cmd' parameter of amd_iommu_send_guest_cmd is passed
> to a function that expects arrays of size 4, therefore
> specifying explicitly the size also in amd_iommu_send_guest_cmd
> allows not to accidentally pass a smaller array or assume that
> send_iommu_command handles array sizes >4 correctly.
> 
> No functional change.
> 
> Signed-off-by: Nicola Vetrini 
> ---
> All current users pass an array of size 4, hence this patch is addressing
> a potential issue noticed by the analyzer in the context of Rule 17.5
> ("The function argument corresponding to a parameter declared to have an array
> type shall have an appropriate number of elements"), not an actual problem in
> the sources.

While true, I think we want to consider alternatives. First one being to rip
out this dead code (thus addressing other Misra concerns as well). Second,
if we meant to keep it, to properly do away with the (ab)use of u32[].

Finally, if to be taken in this least-effort shape, ...

> --- a/xen/drivers/passthrough/amd/iommu.h
> +++ b/xen/drivers/passthrough/amd/iommu.h
> @@ -346,7 +346,7 @@ void cf_check amd_iommu_crash_shutdown(void);
>  
>  /* guest iommu support */
>  #ifdef CONFIG_HVM
> -void amd_iommu_send_guest_cmd(struct amd_iommu *iommu, u32 cmd[]);
> +void amd_iommu_send_guest_cmd(struct amd_iommu *iommu, u32 cmd[4]);

... u32 here and ...

> --- a/xen/drivers/passthrough/amd/iommu_cmd.c
> +++ b/xen/drivers/passthrough/amd/iommu_cmd.c
> @@ -390,7 +390,7 @@ void amd_iommu_flush_all_caches(struct amd_iommu *iommu)
>      flush_command_buffer(iommu, 0);
>  }
>  
> -void amd_iommu_send_guest_cmd(struct amd_iommu *iommu, u32 cmd[])
> +void amd_iommu_send_guest_cmd(struct amd_iommu *iommu, u32 cmd[4])

... here would better be replaced by uint32_t at the same time, not the
least because that's what ...

>  {
>      send_iommu_command(iommu, cmd);

... this function already takes afaics.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 09:05:49 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 09:05:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693060.1080785 (Exim 4.92)
	(envelope-from )
	id 1rkh21-0006eD-79; Thu, 14 Mar 2024 09:05:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693060.1080785; Thu, 14 Mar 2024 09:05:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkh21-0006e6-4A; Thu, 14 Mar 2024 09:05:45 +0000
Received: by outflank-mailman (input) for mailman id 693060;
 Thu, 14 Mar 2024 09:05:44 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkh20-0006e0-Kl
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 09:05:44 +0000
Received: from mail-oa1-x34.google.com (mail-oa1-x34.google.com
 [2001:4860:4864:20::34])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 08b18431-e1e2-11ee-a1ee-f123f15fe8a2;
 Thu, 14 Mar 2024 10:05:42 +0100 (CET)
Received: by mail-oa1-x34.google.com with SMTP id
 586e51a60fabf-22215ccbafeso381451fac.0
 for ; Thu, 14 Mar 2024 02:05:42 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 08b18431-e1e2-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1710407141; x=1711011941; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=7BxBaJcrAmxi2huKCdNF1/OD24+lEdSeSWhukacTCPU=;
        b=DEdJLEaAFkKvocFUsTtfOt1jSuBnclDogwCeQ2BoZspaAfjZ7pSEdj+tXMA3Ja/v7Y
         9Nm8Xn8HtORrT6yLxGu3Ad4gdXVO2EGiSF1fOPUJoqcbTgk2OLCywi0bWrmkwjnmBjfM
         uQiRhagZPIGQjXvQuEQxJmeL0BZVh/tCfrxfY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710407141; x=1711011941;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=7BxBaJcrAmxi2huKCdNF1/OD24+lEdSeSWhukacTCPU=;
        b=YCbf/eabMxNYIks2KiAlDUMTn66FWLEoKbfRlCTM0ZaSrA2U+lUAiPxahg8dA6y9rp
         jQr7qTVQG0u26VINBDQqt4UncTOvsdIDkcjztWLXqM72kuPUzgSRSYihgJxobQ0y7F4y
         KUR2HwmcxCNn91DZOluTcrijNc88u7sJvz0MS7Z8WmtySKulc8uT+tVPOZJY/xXxU4HW
         KO6MUpUSyRmLFQQ7Xb0pvgLn1oUkJDiE/CAnc48aR+lISikfqagHfBa57vgmOIoo+iEm
         3TW7vjStMQt10jTrqqxMoPNZYJyPY0uuQbCuY88CChmUzc1myTKNw4ArkC7gVX8qCRXr
         sYqQ==
X-Forwarded-Encrypted: i=1; AJvYcCWekO5U4OGtm9Q61Tbqh8mw6OUV1aEVHW3Y7ftmYBblq22KcrANTzgM/9rsGtEx9xk8DNfayFcyRXD5Y9UZA1tA/NlflBEYa8r5VaPkpaM=
X-Gm-Message-State: AOJu0YynQ5IEKDnzt4GADUli4JrxMJYq9x/s6MaMvIBicDwPyuv4GiLF
	uCPVCe15CiXrAXq0oP3PL2UgTdFlDmkm2koRC/O9MNShy8N4lzc+gD4r5DiktpWReBtrwAy7/tM
	Qpc74WSpm6N13BrInNH5/ghjatETggH9/aDTqTg==
X-Google-Smtp-Source: AGHT+IHnYaeIN8ZWl0ZQ8WXofu9hPBDLWpuV3nWBRIUpTlElCPA5mS+woRgk2jbu10j226lsCe2MzMmQBm1kyR19Puo=
X-Received: by 2002:a05:6871:286:b0:21f:d1e6:d8e8 with SMTP id
 i6-20020a056871028600b0021fd1e6d8e8mr1305710oae.39.1710407141441; Thu, 14 Mar
 2024 02:05:41 -0700 (PDT)
MIME-Version: 1.0
References: 
 <5bfd2a8e-afa9-4630-ae75-382edc943bc6@suse.com>
In-Reply-To: <5bfd2a8e-afa9-4630-ae75-382edc943bc6@suse.com>
From: George Dunlap 
Date: Thu, 14 Mar 2024 09:05:30 +0000
Message-ID: 
Subject: Re: [PATCH] docs/misra: document the expected sizes of integer types
To: Jan Beulich 
Cc: Stefano Stabellini , andrew.cooper3@citrix.com, 
	bertrand.marquis@arm.com, julien@xen.org, michal.orzel@amd.com, 
	roger.pau@citrix.com, xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Mar 14, 2024 at 7:36=E2=80=AFAM Jan Beulich  wro=
te:
>
> On 14.03.2024 00:23, Stefano Stabellini wrote:
> > Xen makes assumptions about the size of integer types on the various
> > architectures. Document these assumptions.
>
> This all reads as if we required exact widths. Is that really the case?

At least one thing here is that *all compilers on the architecture*
need to have the same idea.  If not, we absolutely need to change
"unsigned int" to "uint32_t" in any public interface.

A second thing is not only assumptions about minimum number of bits,
but about storage size and alignment.  Again, if we don't assume that
"unsigned int" is exactly 4 bytes, then we should go through and
change it to "uint32_t" anywhere that the size or alignment matter.

 -George


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 09:25:41 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 09:25:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693067.1080794 (Exim 4.92)
	(envelope-from )
	id 1rkhL2-0001X1-PP; Thu, 14 Mar 2024 09:25:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693067.1080794; Thu, 14 Mar 2024 09:25:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkhL2-0001Wu-Md; Thu, 14 Mar 2024 09:25:24 +0000
Received: by outflank-mailman (input) for mailman id 693067;
 Thu, 14 Mar 2024 09:25:23 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkhL1-0001Wj-JX
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 09:25:23 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c80d592a-e1e4-11ee-afdd-a90da7624cb6;
 Thu, 14 Mar 2024 10:25:22 +0100 (CET)
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 by support.bugseng.com (Postfix) with ESMTPA id 95C504EE0739;
 Thu, 14 Mar 2024 10:25:21 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c80d592a-e1e4-11ee-afdd-a90da7624cb6
MIME-Version: 1.0
Date: Thu, 14 Mar 2024 10:25:21 +0100
From: Nicola Vetrini 
To: Jan Beulich 
Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com,
 ayan.kumar.halder@amd.com, consulting@bugseng.com, bertrand.marquis@arm.com,
 julien@xen.org, Andrew Cooper ,
 xen-devel@lists.xenproject.org
Subject: Re: [XEN PATCH] amd/iommu: add fixed size to function parameter of
 array type
In-Reply-To: <6186b676-660c-4bfa-a825-18ff7f0d7f62@suse.com>
References: <533a2d4f0c92d7fe92aa200b64434389de546f69.1710343652.git.nicola.vetrini@bugseng.com>
 <6186b676-660c-4bfa-a825-18ff7f0d7f62@suse.com>
Message-ID: <503aa63b5204e9b9eab5a21235df7c6c@bugseng.com>
X-Sender: nicola.vetrini@bugseng.com
Organization: BUGSENG s.r.l.
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit

On 2024-03-14 09:32, Jan Beulich wrote:
> On 14.03.2024 08:42, Nicola Vetrini wrote:
>> The 'cmd' parameter of amd_iommu_send_guest_cmd is passed
>> to a function that expects arrays of size 4, therefore
>> specifying explicitly the size also in amd_iommu_send_guest_cmd
>> allows not to accidentally pass a smaller array or assume that
>> send_iommu_command handles array sizes >4 correctly.
>> 
>> No functional change.
>> 
>> Signed-off-by: Nicola Vetrini 
>> ---
>> All current users pass an array of size 4, hence this patch is 
>> addressing
>> a potential issue noticed by the analyzer in the context of Rule 17.5
>> ("The function argument corresponding to a parameter declared to have 
>> an array
>> type shall have an appropriate number of elements"), not an actual 
>> problem in
>> the sources.
> 
> While true, I think we want to consider alternatives. First one being 
> to rip
> out this dead code (thus addressing other Misra concerns as well). 
> Second,
> if we meant to keep it, to properly do away with the (ab)use of u32[].
> 

I'm not understanding what you consider dead code.
I see three users of amd_iommu_send_guest_cmd and seven for 
send_iommu_command.
I can adjust u32 for sure. There are also other u32/uint32_t 
incosistencies in that header.

> Finally, if to be taken in this least-effort shape, ...
> 
>> --- a/xen/drivers/passthrough/amd/iommu.h
>> +++ b/xen/drivers/passthrough/amd/iommu.h
>> @@ -346,7 +346,7 @@ void cf_check amd_iommu_crash_shutdown(void);
>> 
>>  /* guest iommu support */
>>  #ifdef CONFIG_HVM
>> -void amd_iommu_send_guest_cmd(struct amd_iommu *iommu, u32 cmd[]);
>> +void amd_iommu_send_guest_cmd(struct amd_iommu *iommu, u32 cmd[4]);
> 
> ... u32 here and ...
> 
>> --- a/xen/drivers/passthrough/amd/iommu_cmd.c
>> +++ b/xen/drivers/passthrough/amd/iommu_cmd.c
>> @@ -390,7 +390,7 @@ void amd_iommu_flush_all_caches(struct amd_iommu 
>> *iommu)
>>      flush_command_buffer(iommu, 0);
>>  }
>> 
>> -void amd_iommu_send_guest_cmd(struct amd_iommu *iommu, u32 cmd[])
>> +void amd_iommu_send_guest_cmd(struct amd_iommu *iommu, u32 cmd[4])
> 
> ... here would better be replaced by uint32_t at the same time, not the
> least because that's what ...
> 
>>  {
>>      send_iommu_command(iommu, cmd);
> 
> ... this function already takes afaics.
> 
> Jan

-- 
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 09:31:18 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 09:31:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693071.1080809 (Exim 4.92)
	(envelope-from )
	id 1rkhQf-0003JC-FI; Thu, 14 Mar 2024 09:31:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693071.1080809; Thu, 14 Mar 2024 09:31:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkhQf-0003J5-B5; Thu, 14 Mar 2024 09:31:13 +0000
Received: by outflank-mailman (input) for mailman id 693071;
 Thu, 14 Mar 2024 09:31:11 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkhQd-0003Iz-IA
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 09:31:11 +0000
Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com
 [2607:f8b0:4864:20::1034])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9576d367-e1e5-11ee-afdd-a90da7624cb6;
 Thu, 14 Mar 2024 10:31:07 +0100 (CET)
Received: by mail-pj1-x1034.google.com with SMTP id
 98e67ed59e1d1-29c722a2e1aso564192a91.1
 for ; Thu, 14 Mar 2024 02:31:07 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9576d367-e1e5-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710408666; x=1711013466; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=+rwb5oqQFsCQxahi/bVQs5Z69+pPSBgsWMhIQOKz5gw=;
        b=fePrSBxolucvkMtuEmpkY70bY+NVcuKL5pEGAU9M3F27ITiEIuvM6S3Z4SYpeErmRY
         W3xx8s4/+PhOsmZFu75OBY+TDQOuaO8UF2Hu0oxBNQUrhw/WGEwLqkO5L79kLEpYpmzD
         urLCX5GqlhZX0KYHerqPC4T1k7rEy6Ygt7j1s=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710408666; x=1711013466;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=+rwb5oqQFsCQxahi/bVQs5Z69+pPSBgsWMhIQOKz5gw=;
        b=aONtYE3Ld+6VTGKnpN9emJ+AfbwQEyXYBYazx/EfkBWm4pEomteOorBM1+DxYeDU0k
         GqqQtOG0Xioqa6w3eM06NNKl4V8Fzq/v9BP95Fbry0NHY/8P1FFT+Hk0WYMduGRCSmFR
         J63yMKbq4GxVuF4sZbEhXtBBOBtaVMrnTQPkBAgqomPRk5L6lYJL9BS4MkjLk0SbM6FR
         lVimYmpAB6g1qqRGi1ntGq3zVZ2gQNbbVJXGcsEDI/iFPSCJ5sEPfBl/Pe8rW5wNruGZ
         cXflnwtJtig1E1L5cjVr+YNVCIkWZ/1Oh5q4lMdBOahDdbrIXZYzqc6vMoM5QrK94cjI
         vnUA==
X-Gm-Message-State: AOJu0YzkhBp6q6DHj2EtkMwSrxCCJaW1TtHi7DkVKm26EAWPdXQ+umGQ
	2lNbxQvQesyvfQgSWVKQq60plFNQ1gM4D7YCtvYjT0R3S7qzQGb/nmjEbuzTLTtX18QNz3tlK3R
	1g/JDO0KCQcqethYhpRSwvolwFY2ssg89e6OL
X-Google-Smtp-Source: AGHT+IEUOg1KYg94duL74iAVK63VnYRkbZwhJ59ARuVjLYmHNKeKlhACEdoiZMKrshTTQKcSTakDxiFHS+Eg1Pk67Ag=
X-Received: by 2002:a17:90b:3912:b0:29d:dd40:cdc3 with SMTP id
 ob18-20020a17090b391200b0029ddd40cdc3mr432200pjb.18.1710408665939; Thu, 14
 Mar 2024 02:31:05 -0700 (PDT)
MIME-Version: 1.0
References: <20240313150748.791236-1-ross.lagerwall@citrix.com>
 <20240313150748.791236-2-ross.lagerwall@citrix.com> 
In-Reply-To: 
From: Ross Lagerwall 
Date: Thu, 14 Mar 2024 09:30:54 +0000
Message-ID: 
Subject: Re: [PATCH 1/7] multiboot2: Add load type header and support for the
 PE binary type
To: Jan Beulich 
Cc: xen-devel@lists.xenproject.org, Andrew Cooper , 
	Daniel Kiper , grub-devel@gnu.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Mar 14, 2024 at 7:24=E2=80=AFAM Jan Beulich  wro=
te:
>
> On 13.03.2024 16:07, Ross Lagerwall wrote:
> > In addition to the existing address and ELF load types, specify a new
> > optional PE binary load type. This new type is a useful addition since
> > PE binaries can be signed and verified (i.e. used with Secure Boot).
>
> And the consideration to have ELF signable (by whatever extension to
> the ELF spec) went nowhere?
>

I'm not sure if you're referring to some ongoing work to create signable
ELFs that I'm not aware of.

I didn't choose that route because:

* Signed PE binaries are the current standard for Secure Boot.

* Having signed ELF binaries would mean that code to handle them needs
to be added to Shim which contravenes its goals of being small and
simple to verify.

* I could be wrong on this but to my knowledge, the ELF format is not
being actively updated nor is the standard owned/maintained by a
specific group which makes updating it difficult.

* Tools would need to be updated/developed to add support for signing
ELF binaries and inspecting the signatures.

I am open to suggestions of course but I'm not sure what benefits there
would be to going the ELF route.

Ross


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 09:49:05 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 09:49:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693084.1080821 (Exim 4.92)
	(envelope-from )
	id 1rkhhp-0005ZU-RW; Thu, 14 Mar 2024 09:48:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693084.1080821; Thu, 14 Mar 2024 09:48:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkhhp-0005ZN-Oh; Thu, 14 Mar 2024 09:48:57 +0000
Received: by outflank-mailman (input) for mailman id 693084;
 Thu, 14 Mar 2024 09:48:56 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkhho-0005ZH-OI
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 09:48:56 +0000
Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com
 [2607:f8b0:4864:20::834])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 123a64e9-e1e8-11ee-afdd-a90da7624cb6;
 Thu, 14 Mar 2024 10:48:55 +0100 (CET)
Received: by mail-qt1-x834.google.com with SMTP id
 d75a77b69052e-430a65e973bso262661cf.3
 for ; Thu, 14 Mar 2024 02:48:55 -0700 (PDT)
Received: from localhost ([85.31.135.62]) by smtp.gmail.com with ESMTPSA id
 o23-20020ac872d7000000b00430a67b3437sm34478qtp.17.2024.03.14.02.48.53
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 14 Mar 2024 02:48:54 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 123a64e9-e1e8-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710409734; x=1711014534; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=xxDAwbG8nOc3eyKo8MEb496Icb3PY8Fs08zpqF7laFI=;
        b=lfoNlz46eQA94+hRzQVXQTferfiGnGmwnMI+Fw/ncvkMi1OVZviLl39UTtvjpX0Ooa
         E6SY2zNu+6rnBzxbj/nLMPxCWbh8CjOi2dAfA5F7J6k323q1D1kUI2ytfOh8RO/gVeYY
         B01E2fyVna4N4aE5bRue+hx65w0B4Cu8FaJhE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710409734; x=1711014534;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=xxDAwbG8nOc3eyKo8MEb496Icb3PY8Fs08zpqF7laFI=;
        b=uoNOdPx1UQwwGbAVGMZG7MOIYmERHG1cMMqieL+4663L8X3plkx/mfWcaSHq94yNSy
         aw7C6YwNU5+nXB4Xa++CMa8kryytWAIiUDa65eDzMXdPpsGMDamRWCsm9BG5oSP+TUkG
         qXRXJPiFb1FILKbuRaHUld5YMux6IbR9rCVfygvl7E7IyadNMSQnFbctBr6pQY/Kvkob
         a8Gwivz7a6TowG3jtBKrCaiPIX8eHYG0sJmigKdFy+L2XNbphSNTjx+5qRb+60EZGcIE
         pNqG3nQN+niNl+JXATX5/HQ7GVyMiHWzvpKGe/KPQUN5mtw5AWucepL/dEbMP/eD1gYS
         N2tA==
X-Gm-Message-State: AOJu0YxczbvC1S1yfXGeUSPGBzUWQQ+12xJRlZMjaUB//vNLOBmPosFV
	t8t2lNu61wYq8IoW/ELjl2zGg/VByi9XeX5aHNzhCGDAjZ6XwSoTVhsDVvA+XYY=
X-Google-Smtp-Source: AGHT+IHYbyVum+dbjN89JJGy65DnYrTUioGEYAbQox9ZBiOGX1K+vilFfRFDKBHSLsNi/pJlen+gAQ==
X-Received: by 2002:ac8:7dc2:0:b0:42e:cf0d:c9e7 with SMTP id c2-20020ac87dc2000000b0042ecf0dc9e7mr1405129qte.44.1710409734329;
        Thu, 14 Mar 2024 02:48:54 -0700 (PDT)
Date: Thu, 14 Mar 2024 10:48:52 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jason Andryuk 
Cc: xen-devel@lists.xenproject.org, Jan Beulich ,
	Andrew Cooper , Wei Liu ,
	George Dunlap ,
	Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH v2 3/3] x86/PVH: Support relocatable dom0 kernels
Message-ID: 
References: <20240313193021.241764-1-jason.andryuk@amd.com>
 <20240313193021.241764-4-jason.andryuk@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20240313193021.241764-4-jason.andryuk@amd.com>

On Wed, Mar 13, 2024 at 03:30:21PM -0400, Jason Andryuk wrote:
> Xen tries to load a PVH dom0 kernel at the fixed guest physical address
> from the elf headers.  For Linux, this defaults to 0x1000000 (16MB), but
> it can be configured.
> 
> Unfortunately there exist firmwares that have reserved regions at this
> address, so Xen fails to load the dom0 kernel since it's not RAM.
> 
> The PVH entry code is not relocatable - it loads from absolute
> addresses, which fail when the kernel is loaded at a different address.
> With a suitably modified kernel, a reloctable entry point is possible.
> 
> Add XEN_ELFNOTE_PVH_RELOCATION which specifies the minimum, maximum and
> alignment needed for the kernel.  The presence of the NOTE indicates the
> kernel supports a relocatable entry path.
> 
> Change the loading to check for an acceptable load address.  If the
> kernel is relocatable, support finding an alternate load address.
> 
> Link: https://gitlab.com/xen-project/xen/-/issues/180
> Signed-off-by: Jason Andryuk 
> ---
> ELF Note printing looks like:
> (XEN) ELF: note: PVH_RELOCATION = min: 0x1000000 max: 0xffffffff align: 0x200000
> 
> v2:
> Use elfnote for min, max & align - use 64bit values.
> Print original and relocated memory addresses
> Use check_and_adjust_load_address() name
> Return relocated base instead of offset
> Use PAGE_ALIGN
> Don't load above max_phys (expected to be 4GB in kernel elf note)
> Use single line comments
> Exit check_load_address loop earlier
> Add __init to find_kernel_memory()
> ---
>  xen/arch/x86/hvm/dom0_build.c      | 108 +++++++++++++++++++++++++++++
>  xen/common/libelf/libelf-dominfo.c |  13 ++++
>  xen/include/public/elfnote.h       |  11 +++
>  xen/include/xen/libelf.h           |   3 +
>  4 files changed, 135 insertions(+)
> 
> diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
> index 0ceda4140b..5c6c0d2db3 100644
> --- a/xen/arch/x86/hvm/dom0_build.c
> +++ b/xen/arch/x86/hvm/dom0_build.c
> @@ -537,6 +537,108 @@ static paddr_t __init find_memory(
>      return INVALID_PADDR;
>  }
>  
> +static bool __init check_load_address(
> +    const struct domain *d, const struct elf_binary *elf)
> +{
> +    paddr_t kernel_start = (paddr_t)elf->dest_base & PAGE_MASK;

Are you sure this is correct?  If a program header specifies a non-4K
aligned load address we should still try to honor it.  I think this is
very unlikely, but still we shouldn't apply non-requested alignments
to addresses coming from the ELF headers.

> +    paddr_t kernel_end = PAGE_ALIGN((paddr_t)elf->dest_base + elf->dest_size);
> +    unsigned int i;
> +
> +    /*
> +     * The memory map is sorted and all RAM regions starts and sizes are
> +     * aligned to page boundaries.

Relying on sizes to be page aligned seems fragile: it might work now
because of the order in which pvh_setup_vmx_realmode_helpers() first
reserves memory for the TSS and afterwards for the identity page
tables, but it's not a property this code should assume.

> +     */
> +    for ( i = 0; i < d->arch.nr_e820; i++ )
> +    {
> +        paddr_t start = d->arch.e820[i].addr;
> +        paddr_t end = d->arch.e820[i].addr + d->arch.e820[i].size;
> +
> +        if ( start >= kernel_end )
> +            return false;
> +
> +        if ( start <= kernel_start &&
> +             end >= kernel_end &&
> +             d->arch.e820[i].type == E820_RAM )

Nit: I would maybe do the type check before the boundary ones, as it's
pointless to do boundary checking on a region of a non-RAM type.  But
I guess you could also see it the other way around.

> +            return true;
> +    }
> +
> +    return false;
> +}
> +
> +/* Find an e820 RAM region that fits the kernel at a suitable alignment. */
> +static paddr_t __init find_kernel_memory(
> +    const struct domain *d, struct elf_binary *elf,

const for elf also.

> +    const struct elf_dom_parms *parms)
> +{
> +    paddr_t kernel_start = (paddr_t)elf->dest_base & PAGE_MASK;
> +    paddr_t kernel_end = PAGE_ALIGN((paddr_t)elf->dest_base + elf->dest_size);
> +    paddr_t kernel_size = kernel_end - kernel_start;

Hm, I'm again unsure about the alignments applied here.

I think if anything we want to assert that dest_base is aligned to phys_align.

> +    unsigned int i;
> +
> +    /*
> +     * The memory map is sorted and all RAM regions starts and sizes are
> +     * aligned to page boundaries.
> +     */
> +    for ( i = 0; i < d->arch.nr_e820; i++ )
> +    {
> +        paddr_t start = d->arch.e820[i].addr;
> +        paddr_t end = d->arch.e820[i].addr + d->arch.e820[i].size;
> +        paddr_t kstart, kend;
> +
> +        if ( d->arch.e820[i].type != E820_RAM )
> +            continue;
> +
> +        if ( d->arch.e820[i].size < kernel_size )
> +            continue;

You can unify both checks in a single condition.

> +
> +        kstart = ROUNDUP(start, parms->phys_align);
> +        kstart = kstart < parms->phys_min ? parms->phys_min : kstart;
> +        kend = kstart + kernel_size;
> +
> +        if ( kend > parms->phys_max )
> +            return 0;
> +
> +        if ( kend <= end )
> +            return kstart;
> +    }
> +
> +    return 0;
> +}
> +
> +/* Check the kernel load address, and adjust if necessary and possible. */
> +static bool __init check_and_adjust_load_address(
> +    const struct domain *d, struct elf_binary *elf, struct elf_dom_parms *parms)
> +{
> +    paddr_t reloc_base;
> +
> +    if ( check_load_address(d, elf) )
> +        return true;
> +
> +    if ( parms->phys_align == UNSET_ADDR )
> +    {
> +        printk("Address conflict and %pd kernel is not relocatable\n", d);
> +        return false;
> +    }
> +
> +    reloc_base = find_kernel_memory(d, elf, parms);
> +    if ( reloc_base == 0 )
> +    {
> +        printk("Failed find a load address for the kernel\n");

Since you print the domain in the error message prior to this one, I
would consider also printing it here (or not printing it in both
cases).

> +        return false;
> +    }
> +
> +    if ( opt_dom0_verbose )
> +        printk("Relocating kernel from [%lx, %lx] -> [%lx, %lx]\n",
> +               (paddr_t)elf->dest_base,
> +               (paddr_t)elf->dest_base + elf->dest_size,
> +               reloc_base, reloc_base + elf->dest_size);

I think you need `- 1` for the end calculation if you use inclusive
ranges [, ].  Otherwise [, ) should be used.

> +
> +    parms->phys_entry += (reloc_base - (paddr_t)elf->dest_base);

This seems to assume that the image is always relocated at a higher
address that the original one?

parms->phys_entry = reloc_base + (parms->phys_entry - elf->dest_base);

> +    elf->dest_base = (char *)reloc_base;
> +
> +    return true;
> +}
> +
>  static int __init pvh_load_kernel(struct domain *d, const module_t *image,
>                                    unsigned long image_headroom,
>                                    module_t *initrd, void *image_base,
> @@ -585,6 +687,12 @@ static int __init pvh_load_kernel(struct domain *d, const module_t *image,
>      elf.dest_base = (void *)(parms.virt_kstart - parms.virt_base);
>      elf.dest_size = parms.virt_kend - parms.virt_kstart;
>  
> +    if ( !check_and_adjust_load_address(d, &elf, &parms) )
> +    {
> +        printk("Unable to load kernel\n");

check_and_adjust_load_address() already prints an error message,
probably no need to print another message.

> +        return -ENOMEM;
> +    }
> +
>      elf_set_vcpu(&elf, v);
>      rc = elf_load_binary(&elf);
>      if ( rc < 0 )
> diff --git a/xen/common/libelf/libelf-dominfo.c b/xen/common/libelf/libelf-dominfo.c
> index 7cc7b18a51..837a1b0f21 100644
> --- a/xen/common/libelf/libelf-dominfo.c
> +++ b/xen/common/libelf/libelf-dominfo.c
> @@ -125,6 +125,7 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
>          [XEN_ELFNOTE_SUSPEND_CANCEL] = { "SUSPEND_CANCEL", ELFNOTE_INT },
>          [XEN_ELFNOTE_MOD_START_PFN] = { "MOD_START_PFN", ELFNOTE_INT },
>          [XEN_ELFNOTE_PHYS32_ENTRY] = { "PHYS32_ENTRY", ELFNOTE_INT },
> +        [XEN_ELFNOTE_PVH_RELOCATION] = { "PVH_RELOCATION", ELFNOTE_OTHER },
>      };
>  /* *INDENT-ON* */
>  
> @@ -234,6 +235,17 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
>                  elf_note_numeric_array(elf, note, 8, 0),
>                  elf_note_numeric_array(elf, note, 8, 1));
>          break;
> +
> +    case XEN_ELFNOTE_PVH_RELOCATION:
> +        if ( elf_uval(elf, note, descsz) != 3 * sizeof(uint64_t) )
> +            return -1;
> +
> +        parms->phys_min = elf_note_numeric_array(elf, note, 8, 0);
> +        parms->phys_max = elf_note_numeric_array(elf, note, 8, 1);
> +        parms->phys_align = elf_note_numeric_array(elf, note, 8, 2);

Size for those needs to be 4 (32bits) as the entry point is in 32bit
mode?  I don't see how we can start past the 4GB boundary.

> +        elf_msg(elf, "min: %#"PRIx64" max: %#"PRIx64" align: %#"PRIx64"\n",
> +                parms->phys_min, parms->phys_max, parms->phys_align);
> +        break;
>      }
>      return 0;
>  }
> @@ -545,6 +557,7 @@ elf_errorstatus elf_xen_parse(struct elf_binary *elf,
>      parms->p2m_base = UNSET_ADDR;
>      parms->elf_paddr_offset = UNSET_ADDR;
>      parms->phys_entry = UNSET_ADDR32;
> +    parms->phys_align = UNSET_ADDR;

For correctness I would also init phys_{min,max}.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 09:49:46 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 09:49:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693087.1080831 (Exim 4.92)
	(envelope-from )
	id 1rkhic-0006AP-3o; Thu, 14 Mar 2024 09:49:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693087.1080831; Thu, 14 Mar 2024 09:49:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkhic-0006AH-1I; Thu, 14 Mar 2024 09:49:46 +0000
Received: by outflank-mailman (input) for mailman id 693087;
 Thu, 14 Mar 2024 09:49:44 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkhia-000655-Fe
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 09:49:44 +0000
Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com
 [2607:f8b0:4864:20::833])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2e79f76f-e1e8-11ee-a1ee-f123f15fe8a2;
 Thu, 14 Mar 2024 10:49:43 +0100 (CET)
Received: by mail-qt1-x833.google.com with SMTP id
 d75a77b69052e-42edf8325f6so3436041cf.0
 for ; Thu, 14 Mar 2024 02:49:42 -0700 (PDT)
Received: from localhost ([85.31.135.62]) by smtp.gmail.com with ESMTPSA id
 t8-20020ac85888000000b004309dec7efdsm456427qta.44.2024.03.14.02.49.41
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 14 Mar 2024 02:49:41 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2e79f76f-e1e8-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710409782; x=1711014582; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=egW0tuoipRPbKvhh5ZNSPDl4SE4lfrMigWlgO5Xq9fQ=;
        b=KrYnHxQdnNnJHJ3XWzDd4lgt2/D53hdtXVV5gFM+7UiCNyb24iGLjxjkSI2CPn/FWS
         9Hq2OHAsIw/UbEQMFkslwonCYcRfN5f4k/ySJE37gxMZRUzLr330Y4nJhA7kf93jM1E2
         g5Nq18ln/P2J26xoEMjMXzsTw1nAWlWie4cgQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710409782; x=1711014582;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=egW0tuoipRPbKvhh5ZNSPDl4SE4lfrMigWlgO5Xq9fQ=;
        b=tTwY8rRKMzvGkNNljGX3Q7faqOG6hQ8AkYMEJdofqbHupsfhThuy9jhFKyXyAtI2sG
         fxifgA2yx5U+i2Tt1fMoPO6nL7/cCDADlyGKCwFyax9GsDkbLKpOatk/wrEsxp3E1arj
         51vCaei04MBQjlZqUjz/NYLy6298hAxIdCmVZ8rygfOLFkdHfbD4YsSzPEN2/G43UWQp
         L/OBuXcAIJCOc3xhkR6Bqoue9jXyyyNvzG34+3On0VXIbP+tNmgUUBF0M7z5T811o8QR
         BYM2YCggbXq3bhj2jJMrdwiOCrFCV3/gxhaE8nowYnFtWNnwoQlc5kUUFxaYYG7LoTf6
         0SRA==
X-Forwarded-Encrypted: i=1; AJvYcCV8zgqO2SMO18gvQCEDSL6k8n2qCUZ87blu7PARpeaSurxrI6dbpNkGhz1nLyJYlQvqEqHenv/I1COjFkX1JWlAtwJXdumskzHO7R2xQQE=
X-Gm-Message-State: AOJu0YwND8zVbZLT8n7bDDdJwvkUmHrM+Ri1KlrugCFjcXrV6KDufLvQ
	DVjbCzEAkqgXOiNmtleSAeDw46Xuel2TAakPvZ5C+WEjQYItG9gPJtPf3N/N2V6GS/nkel7ZSeV
	G
X-Google-Smtp-Source: AGHT+IFAw7BEKOo7VsS7XC6Wi19P/R8ILKGF4EoKyzaij3dojhqVF2DEiqsr9fQc6Zh/p+WQIlRkpQ==
X-Received: by 2002:a05:622a:4b:b0:430:9e89:9f33 with SMTP id y11-20020a05622a004b00b004309e899f33mr944532qtw.62.1710409781841;
        Thu, 14 Mar 2024 02:49:41 -0700 (PDT)
Date: Thu, 14 Mar 2024 10:49:39 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: Stefano Stabellini , andrew.cooper3@citrix.com,
	bertrand.marquis@arm.com, george.dunlap@citrix.com, julien@xen.org,
	michal.orzel@amd.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH] MAINTAINERS: make Roger an IOMMU Maintainer
Message-ID: 
References: 
 <97516382-b756-48da-a358-6b093c4cb20f@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <97516382-b756-48da-a358-6b093c4cb20f@suse.com>

On Thu, Mar 14, 2024 at 08:06:27AM +0100, Jan Beulich wrote:
> On 14.03.2024 00:40, Stefano Stabellini wrote:
> > Roger kindly volunteered to step up as IOMMU Maintainer.
> > 
> > Signed-off-by: Stefano Stabellini 
> 
> Acked-by: Jan Beulich 

Acked-by: Roger Pau Monné 

Thanks.


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 10:14:02 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 10:14:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693105.1080841 (Exim 4.92)
	(envelope-from )
	id 1rki5w-00023R-Vn; Thu, 14 Mar 2024 10:13:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693105.1080841; Thu, 14 Mar 2024 10:13:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rki5w-00023K-Sw; Thu, 14 Mar 2024 10:13:52 +0000
Received: by outflank-mailman (input) for mailman id 693105;
 Thu, 14 Mar 2024 10:13:51 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rki5v-00023E-N6
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 10:13:51 +0000
Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com
 [2a00:1450:4864:20::132])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8cff4877-e1eb-11ee-a1ee-f123f15fe8a2;
 Thu, 14 Mar 2024 11:13:49 +0100 (CET)
Received: by mail-lf1-x132.google.com with SMTP id
 2adb3069b0e04-513d3746950so247890e87.1
 for ; Thu, 14 Mar 2024 03:13:49 -0700 (PDT)
Received: from ?IPV6:2003:e5:873a:400:704b:6dbb:e7c0:786e?
 (p200300e5873a0400704b6dbbe7c0786e.dip0.t-ipconnect.de.
 [2003:e5:873a:400:704b:6dbb:e7c0:786e])
 by smtp.gmail.com with ESMTPSA id
 az9-20020adfe189000000b0033e43756d11sm418115wrb.85.2024.03.14.03.13.48
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 14 Mar 2024 03:13:48 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8cff4877-e1eb-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710411229; x=1711016029; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:references:cc:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=QV/7YSOjyXoSad2Q83mYfpPTpBrwdJT2JAjx5TCIICs=;
        b=U6Y42fGP2F+NXzf2xKbsE4uHCp+ILe0uLwAcZVlRn0aOa3TTc+Vg9hjTJgYfXXC8F4
         Nd8M1yZ5nxG/HwL9O6PXVkvA8t5bBtE4JQBOgMu2iLUJzCKTk8n9H6tDvH2VMA/nGMeY
         vzOk/iJJ+c5vyjuOvk3F9ah0IYC1DqY9IMc3J0RJPNC4qgtafWOdKz2RUyRXobDkrKer
         2clT6jXu5zsWpV06jY4ASwhFyZ98evILdjdq7kaIVQE6/WhL8AgFquL4vaRJP6Tg1PUJ
         B7EHR6AO4sekIP2XBEuKqHEd/46PbP8mcmrRFOblGku6VnnLBle5GukR+cM+UDHEEmnr
         r9KQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710411229; x=1711016029;
        h=content-transfer-encoding:in-reply-to:from:references:cc:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=QV/7YSOjyXoSad2Q83mYfpPTpBrwdJT2JAjx5TCIICs=;
        b=USbZycsZ+y4S/iMHtZpB2s8laq3fJds5JY29geKgefdQO5fVWySmzwxJk0IPvEpTkn
         z5q0cbbP2dKKZyutdl8VIoHk1zYKEc6lD8PSXjxNQUv/sqq76hGJFlezvZDhMlsqJbCT
         v3IRl+g8HxrKzWr9Nbg8HRst0BsnZq84jbXXq1YY91usYqjbluqUQIWJjJtJoGdNQbaG
         tJ9ZgSGkJXHB6ADt+mLQGkMfcjowsA1V4wY/gUJIb2qQUeU0aFe3A2VLGv+i4m4ztIN3
         zXcvE61eVK1hmEckfGLK3nhGc0zYp7sVJ5SJjer/6DJ02ZLGgLSGoAFPWV6d8eWyh6l5
         NpKg==
X-Forwarded-Encrypted: i=1; AJvYcCV8t7Ogtq3Uf58pMmjRAV0ZNaLn2HONbmI0PMr6sYpmt1DwKiL+J++SzkLY/mjcfLyULUHa+Z3Bwq9L2M28xMZVCxlDatlGwzfgzi+ALjQ=
X-Gm-Message-State: AOJu0YzRQMQ7uhobQCxMcXwKrrauMt8u1yu9z6ZH8akISrqzKKjc/dih
	LQklX9HFaSgjPOITPTFW8SupkawXCO6ekXdCWzz2gZBFrYbzmL7kvZ7A/gdcpAE=
X-Google-Smtp-Source: AGHT+IFsdAq1sObnIBALiBXbjhwsyGGd6S6C10jbyOssYWYqr4CSQ/1oBaatC2I4q63KzfvSvAcEPg==
X-Received: by 2002:ac2:4296:0:b0:513:96ff:a04a with SMTP id m22-20020ac24296000000b0051396ffa04amr770394lfh.43.1710411228962;
        Thu, 14 Mar 2024 03:13:48 -0700 (PDT)
Message-ID: <3753234c-2f9c-44f1-84f5-60a58c81b7b6@suse.com>
Date: Thu, 14 Mar 2024 11:13:48 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 01/13] xen/spinlock: remove misra rule 21.1 violations
Content-Language: en-US
To: Jan Beulich 
Cc: Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 xen-devel@lists.xenproject.org
References: <20240314072029.16937-1-jgross@suse.com>
 <20240314072029.16937-2-jgross@suse.com>
 <272d0e4a-3ac0-4b42-9297-6d476151e28d@suse.com>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
In-Reply-To: <272d0e4a-3ac0-4b42-9297-6d476151e28d@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 14.03.24 08:32, Jan Beulich wrote:
> On 14.03.2024 08:20, Juergen Gross wrote:
>> In xen spinlock code there are several violations of MISRA rule 21.1
>> (identifiers starting with "__" or "_[A-Z]").
>>
>> Fix them by using trailing underscores instead.
>>
>> Signed-off-by: Juergen Gross 
> 
> I can live with the changes as they are, but before giving an ack, I'd
> still like to ask if the moved underscores are really useful / necessary
> in all cases. E.g.
> 
>> --- a/xen/include/xen/spinlock.h
>> +++ b/xen/include/xen/spinlock.h
>> @@ -22,7 +22,7 @@ union lock_debug {
>>           bool unseen:1;
>>       };
>>   };
>> -#define _LOCK_DEBUG { .val = LOCK_DEBUG_INITVAL }
>> +#define LOCK_DEBUG_ { .val = LOCK_DEBUG_INITVAL }
> 
> ... for an internal helper macro it may indeed be better to have a
> trailing one here, but ...
> 
>> @@ -95,27 +95,27 @@ struct lock_profile_qhead {
>>       int32_t                   idx;     /* index for printout */
>>   };
>>   
>> -#define _LOCK_PROFILE(lockname) { .name = #lockname, .lock = &(lockname), }
>> -#define _LOCK_PROFILE_PTR(name)                                               \
>> -    static struct lock_profile * const __lock_profile_##name                  \
>> +#define LOCK_PROFILE_(lockname) { .name = #lockname, .lock = &(lockname), }
>> +#define LOCK_PROFILE_PTR_(name)                                               \
>> +    static struct lock_profile * const lock_profile__##name                   \
> 
> ... I'm not entirely convinced of the need for the double infix ones
> here ...

This reduces the chance of name clashes with other lock profiling variables or
functions (e.g. lock_profile_lock). In case you think this can be neglected, I'm
fine with dropping the extra underscores.


Juergen


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 10:14:12 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 10:14:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693106.1080852 (Exim 4.92)
	(envelope-from )
	id 1rki6G-0002NS-7i; Thu, 14 Mar 2024 10:14:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693106.1080852; Thu, 14 Mar 2024 10:14:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rki6G-0002NL-3v; Thu, 14 Mar 2024 10:14:12 +0000
Received: by outflank-mailman (input) for mailman id 693106;
 Thu, 14 Mar 2024 10:14:11 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rki6F-0002M1-36
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 10:14:11 +0000
Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com
 [2a00:1450:4864:20::435])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 99303747-e1eb-11ee-afdd-a90da7624cb6;
 Thu, 14 Mar 2024 11:14:10 +0100 (CET)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-33e5978fc1bso327046f8f.3
 for ; Thu, 14 Mar 2024 03:14:10 -0700 (PDT)
Received: from ?IPV6:2003:e5:873a:400:704b:6dbb:e7c0:786e?
 (p200300e5873a0400704b6dbbe7c0786e.dip0.t-ipconnect.de.
 [2003:e5:873a:400:704b:6dbb:e7c0:786e])
 by smtp.gmail.com with ESMTPSA id
 az9-20020adfe189000000b0033e43756d11sm418115wrb.85.2024.03.14.03.14.09
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 14 Mar 2024 03:14:09 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 99303747-e1eb-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710411249; x=1711016049; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:references:cc:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=9OTZRhCxnsKwTrd1IiO9b2Chf8sfIkoNDtX6afa3FAs=;
        b=DmPqU2P10mj1vTqSghF1Izkk75RiZq5AxE+v6kHjWiFGac5mj/CyYMTUy9aSjfiU6D
         j92Ev3aLeZo+15AxmtXQZkuc9mCCCqrAuWBndDMZ0WhnJqSAFHfbegd7/dKkGXh+GKqf
         FsA8kqy8QjVLr/E3fkLVomGa3z7VUysNXcsySxjdp6Zfh1EWUE5JSCAYMr6hcDrSR+8T
         9UxDpMd/E3b/wu1yY0hJNar+/SvHQCrzUiTE6bH6QqNSSkZCMm+Z508BJciN+z7isj7h
         hvQJQo+rmXYR/e/F5c8WzbOd44q4G7qQZ3h0E8N055A0oj0QZ9nxk+K0rTZ1aRqFSnUs
         52Jg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710411249; x=1711016049;
        h=content-transfer-encoding:in-reply-to:from:references:cc:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=9OTZRhCxnsKwTrd1IiO9b2Chf8sfIkoNDtX6afa3FAs=;
        b=JhrqoI6ieAC+6Bdu60jtFHDlEhE0OQ/4LL14OTi98AHQnRo1vtDlr0rDvTiZSQGfAD
         FcWZ5NP7NqWkdIaBypGDWwUXceY055Q89fH2pda/4uWMVezIVgfrunIuh3JKFCwe9beR
         h96ebEi2pIbtWmXr6CXQAiYSVhLgctUedjfdqBSGadhtzCglsOe2os0o9CiEXaroi3GV
         loeIm5qCBOSlbDYgQpK8VP6rVFqHmc90EoxpKBjUtWmShr1VC14xdcY6zjYyJxWdHzu0
         eI2r8gcNl4ugyJWwntBI7cj3OHxf/zX6+kJPFosfnKBDvSXWNnBiJJbD3Hr/KRtbb0MO
         pw6A==
X-Forwarded-Encrypted: i=1; AJvYcCVgn7rPpq3hEmemYrta/jJXtgT6hwBZOZcAJymIVm0oAfwudfin12UVXqs/5OCOXBtiN2RXkXlFG4Poe8FGPbVT9TVOuiXbM6ZUlPDirgU=
X-Gm-Message-State: AOJu0YzdlbbGRsA4vZAYPnhRtffKBzORFQpVmPhiqZq66KvHKMmR04cc
	K5vBPpH30AE8PRat/hnNai9vo/oeGWEfaddtCpkxZVBhqitRDOEF+ow1yDjkA9w=
X-Google-Smtp-Source: AGHT+IFu/AVBYTuAq8LLN5a+S1+H1PHD2TShUnuPnahACBVXzOcEYtUTxYro4L+/ETCvHR9MkznmAQ==
X-Received: by 2002:adf:b307:0:b0:33d:ac70:2e09 with SMTP id j7-20020adfb307000000b0033dac702e09mr712985wrd.59.1710411249567;
        Thu, 14 Mar 2024 03:14:09 -0700 (PDT)
Message-ID: <219994d0-7dd8-4862-aa95-d97e0832baac@suse.com>
Date: Thu, 14 Mar 2024 11:14:09 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 13/13] xen: allow up to 16383 cpus
Content-Language: en-US
To: Jan Beulich 
Cc: Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 xen-devel@lists.xenproject.org
References: <20240314072029.16937-1-jgross@suse.com>
 <20240314072029.16937-14-jgross@suse.com>
 
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 14.03.24 08:26, Jan Beulich wrote:
> On 14.03.2024 08:20, Juergen Gross wrote:
>> With lock handling now allowing up to 16384 cpus (spinlocks can handle
>> 65535 cpus, rwlocks can handle 16384 cpus), raise the allowed limit for
>> the number of cpus to be configured to 16383.
>>
>> The new limit is imposed by IOMMU_CMD_BUFFER_MAX_ENTRIES and
>> QINVAL_MAX_ENTRY_NR required to be larger than 2 * CONFIG_NR_CPUS.
> 
> That's quite sad - I was really hoping we'd finally end up with a
> power-of-2 upper bound.

Yes, me too.


Juergen


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 10:44:29 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 10:44:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693140.1080874 (Exim 4.92)
	(envelope-from )
	id 1rkiZN-0007Q0-Mg; Thu, 14 Mar 2024 10:44:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693140.1080874; Thu, 14 Mar 2024 10:44:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkiZN-0007Pt-Je; Thu, 14 Mar 2024 10:44:17 +0000
Received: by outflank-mailman (input) for mailman id 693140;
 Thu, 14 Mar 2024 10:44:16 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkiZM-0007Pj-Fa; Thu, 14 Mar 2024 10:44:16 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkiZM-0005po-9Q; Thu, 14 Mar 2024 10:44:16 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkiZM-0006gp-0G; Thu, 14 Mar 2024 10:44:16 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rkiZL-00077Y-Vn; Thu, 14 Mar 2024 10:44:15 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=c8fR5hvdpqwFRJhjcdXGG6X+R2hS1RKtmS+31Gv/E4Q=; b=sBg/2xu3Riekb0nQpIREg44zDz
	tWmJ5ZhsplbpEkz8GwN8fRvCJ+oqJq1Va/uEhRDDIPZnFSyeHMajZ2k/GxU8JlSXct5R9H8ePU7mU
	i0/ZyEZJgj60nm1Es3xNT98+Z0M9bTiLn7m2e+aqfq8Gfy6G+zQRdVhrxhaop2hJV/CI=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-4.18-testing test] 185020: regressions - FAIL
X-Osstest-Failures:
    xen-4.18-testing:test-amd64-amd64-xl-qemut-debianhvm-i386-xsm:debian-hvm-install:fail:regression
    xen-4.18-testing:build-arm64-pvops:kernel-build:fail:regression
    xen-4.18-testing:test-armhf-armhf-xl-credit1:guest-start/debian.repeat:fail:heisenbug
    xen-4.18-testing:test-armhf-armhf-libvirt-raw:guest-start:fail:heisenbug
    xen-4.18-testing:test-arm64-arm64-xl-vhd:build-check(1):blocked:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl:build-check(1):blocked:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-xsm:build-check(1):blocked:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-thunderx:build-check(1):blocked:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-credit1:build-check(1):blocked:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-credit2:build-check(1):blocked:nonblocking
    xen-4.18-testing:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking
    xen-4.18-testing:test-arm64-arm64-libvirt-raw:build-check(1):blocked:nonblocking
    xen-4.18-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    xen-4.18-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    xen-4.18-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    xen-4.18-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    xen-4.18-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
    xen-4.18-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-i386-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    xen=4da8ca9cb9cfdb92c9dd09d5270ae16a3b2dbc89
X-Osstest-Versions-That:
    xen=a96d2d4355d85fc82abd0a3799978db04ee8cff3
From: osstest service owner 
Date: Thu, 14 Mar 2024 10:44:15 +0000

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail REGR. vs. 185003
 build-arm64-pvops             6 kernel-build   fail in 185014 REGR. vs. 185003

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-credit1 18 guest-start/debian.repeat fail in 185014 pass in 185020
 test-armhf-armhf-libvirt-raw 13 guest-start                fail pass in 185014

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-vhd       1 build-check(1)           blocked in 185014 n/a
 test-arm64-arm64-xl           1 build-check(1)           blocked in 185014 n/a
 test-arm64-arm64-xl-xsm       1 build-check(1)           blocked in 185014 n/a
 test-arm64-arm64-xl-thunderx  1 build-check(1)           blocked in 185014 n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)           blocked in 185014 n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)           blocked in 185014 n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)           blocked in 185014 n/a
 test-arm64-arm64-libvirt-raw  1 build-check(1)           blocked in 185014 n/a
 test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail in 185014 like 185003
 test-armhf-armhf-libvirt-raw 14 migrate-support-check fail in 185014 never pass
 test-armhf-armhf-libvirt     16 saverestore-support-check    fail  like 185003
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop            fail like 185003
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop            fail like 185003
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop            fail like 185003
 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check   fail like 185003
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop            fail like 185003
 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop             fail like 185003
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop             fail like 185003
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 185003
 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop             fail like 185003
 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop             fail like 185003
 test-arm64-arm64-xl          15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          16 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     15 migrate-support-check        fail   never pass
 test-amd64-i386-xl-pvshim    14 guest-start                  fail   never pass
 test-amd64-i386-libvirt      15 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  15 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-check    fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass
 test-armhf-armhf-xl-credit2  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-multivcpu 15 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-arndale  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-check    fail  never pass
 test-armhf-armhf-libvirt     15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          16 saverestore-support-check    fail   never pass
 test-amd64-i386-libvirt-raw  14 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass
 test-arm64-arm64-libvirt-raw 14 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-raw 15 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-vhd      14 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-vhd      15 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-qcow2 14 migrate-support-check        fail never pass
 test-armhf-armhf-xl-vhd      14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      15 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  4da8ca9cb9cfdb92c9dd09d5270ae16a3b2dbc89
baseline version:
 xen                  a96d2d4355d85fc82abd0a3799978db04ee8cff3

Last test of basis   185003  2024-03-12 11:40:22 Z    1 days
Testing same since   185014  2024-03-13 02:53:58 Z    1 days    2 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Roger Pau Monné 

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 fail    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-armhf-armhf-libvirt-qcow2                               pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-armhf-armhf-libvirt-raw                                 fail    
 test-amd64-i386-libvirt-raw                                  pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-arm64-arm64-xl-vhd                                      pass    
 test-armhf-armhf-xl-vhd                                      pass    
 test-amd64-i386-xl-vhd                                       pass    


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

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

Explanation of these 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 323 lines long.)


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 11:54:25 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 11:54:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693159.1080884 (Exim 4.92)
	(envelope-from )
	id 1rkjf0-0008EY-U6; Thu, 14 Mar 2024 11:54:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693159.1080884; Thu, 14 Mar 2024 11:54:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkjf0-0008ER-RX; Thu, 14 Mar 2024 11:54:10 +0000
Received: by outflank-mailman (input) for mailman id 693159;
 Thu, 14 Mar 2024 11:54:09 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkjez-0008EJ-37
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 11:54:09 +0000
Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com
 [2607:f8b0:4864:20::f35])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 90053d8f-e1f9-11ee-afdd-a90da7624cb6;
 Thu, 14 Mar 2024 12:54:08 +0100 (CET)
Received: by mail-qv1-xf35.google.com with SMTP id
 6a1803df08f44-690fed6816fso5506506d6.1
 for ; Thu, 14 Mar 2024 04:54:08 -0700 (PDT)
Received: from [10.80.67.149] (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 gs7-20020a056214226700b0068fcfef2077sm339201qvb.93.2024.03.14.04.54.05
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 14 Mar 2024 04:54:06 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 90053d8f-e1f9-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710417247; x=1711022047; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=VV97gBqoOSjs5ndq0Aw3AU/fQLxuOaxS8JGpY1ZwC+U=;
        b=olkIehVoUI5Yt1ODiHO6traXLmx3imGrurE82rsZfhbYPg6T0dBoFtd3f+UJBJEan1
         +0T+IeTNZ1c7moaexHIOkdYYvV0NF6tzC6ukSe8TU0bLnUxQFs/9TswOp8Fbxj9teTnN
         /Yg0FT6LnZPbYoTBuCkzixDpThVcKvvg0yLHQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710417247; x=1711022047;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=VV97gBqoOSjs5ndq0Aw3AU/fQLxuOaxS8JGpY1ZwC+U=;
        b=OKwqYHGKO3Oee2QDhq5yXGvu/SMw7t0opupjngLKW47w6HWywGDJY9/SA27mPIbiRD
         LHcSikHZ/xSSLSoERUOtnwb4+raxczFvOTcSuBl00FWbdmI5XzuUvKuN6K/ljk5Spz30
         NhLQqFSnjcU4ApKlDusprA5yObu2Y7anhrmwTw3SjK986lg08nZtR/OZBF/wuydbbHex
         F44jk/6sc03OxQluK1LUK4F8nxFNLtkcv7pJsHs4Zb4omt+5dhJu0B3IuygJtgNjQtQv
         1f4N+QFLT5rAb2xTTn1bAKjrjgvXHLczwxXu4LcPbnc/zTwvMZBogZ7QAk+44UiGi/kC
         MHpA==
X-Forwarded-Encrypted: i=1; AJvYcCUxcyzDXYR6Ws6874U14KPt4qk4/PMsMzHidwUVc8qJxl2vAtSTZYU6+Z0DOMRc5aY/8rCZ8gwJ8PJ58q18jKB6NIKNu1iDSvBLLzqk8i4=
X-Gm-Message-State: AOJu0YzZd6Nj8mtiLrRIjBS2RIHj94oFD8fTx3Qs4zJs/URXzWGBvmq2
	TRhFYR0YUGZxr0ejCkAqIbXpqhBHP8r/DlAy/RrRSAmwRGJKIqf08qijUhxnpo0=
X-Google-Smtp-Source: AGHT+IEuuAWffBYiqnQULRbO4u+18hYYyUy8oHh26n6ndD0HEX6YmLoeCWlmDrqdwIT2o15lbSQz6g==
X-Received: by 2002:a0c:e3c2:0:b0:691:46ee:6abc with SMTP id e2-20020a0ce3c2000000b0069146ee6abcmr1678249qvl.3.1710417246980;
        Thu, 14 Mar 2024 04:54:06 -0700 (PDT)
Message-ID: 
Date: Thu, 14 Mar 2024 11:54:04 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH v2] xen: avoid grep fodder define and undef
Content-Language: en-GB
To: Federico Serafini ,
 xen-devel@lists.xenproject.org
Cc: consulting@bugseng.com, Jan Beulich ,
 Paul Durrant , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , George Dunlap ,
 Julien Grall , Stefano Stabellini ,
 Wei Liu 
References: <1f41883b6688d669d912f9358beccca016bd7ba8.1710401549.git.federico.serafini@bugseng.com>
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <1f41883b6688d669d912f9358beccca016bd7ba8.1710401549.git.federico.serafini@bugseng.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 14/03/2024 7:37 am, Federico Serafini wrote:
> Place an "#if 0" before grep fodder #define-s and remove
> the #undef-s.
>
> This addresses violations of MISRA C:2012 Rules 20.5 ("#undef should
> not be used") and 5.5 ("Identifiers shall be distinct from macro
> names").
>
> No functional change.
>
> Signed-off-by: Federico Serafini 

Acked-by: Andrew Cooper 

It really doesn't matter how we go about excluding the grep-fodder from
the build, and this is a little neater.


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 12:23:44 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 12:23:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693177.1080893 (Exim 4.92)
	(envelope-from )
	id 1rkk7Y-0004H2-F0; Thu, 14 Mar 2024 12:23:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693177.1080893; Thu, 14 Mar 2024 12:23:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkk7Y-0004Gv-CR; Thu, 14 Mar 2024 12:23:40 +0000
Received: by outflank-mailman (input) for mailman id 693177;
 Thu, 14 Mar 2024 12:23:39 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkk7X-0004Gp-Aw
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 12:23:39 +0000
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com
 [2a00:1450:4864:20::62d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id aee1430c-e1fd-11ee-a1ee-f123f15fe8a2;
 Thu, 14 Mar 2024 13:23:37 +0100 (CET)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-a45bb2a9c20so85276766b.0
 for ; Thu, 14 Mar 2024 05:23:37 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 qx12-20020a170906fccc00b00a44a04aa3cfsm654915ejb.225.2024.03.14.05.23.36
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 14 Mar 2024 05:23:36 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: aee1430c-e1fd-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710419017; x=1711023817; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=WOjMpM+Npomr4BsE2wNuLO5CgqwO8e+gdOM4yMDJy3A=;
        b=AQBrFKrOHdY9P1yLAPta5hutET7r2vT5/DYmPRHJDP3jdCuzYbrvPKVHeOzT4t4VYF
         jp39JdX2oQW5tbt3/jGuG42205byBwYXFJuu33ATi2G7HhII68A+St8q7yEl/Tooimcu
         nYv61ospC4beOM25t7q4GJ4yx3YrstJbe2akfElKVexsx24NYTEHT5W5UfDf20XKcSNE
         7XMWzlBqbuTr2hlUnQQ6Jf7MY1uacNd2kEU9PLDxc7e8X3KrvmjH6CO7oPjMf+S1cM98
         uJpozYHoa87o4rlJbYzjcMspA6IpdbG7SCqKRRHLhW2boA2f/JohrJg6jEO3LORsarpZ
         KWVw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710419017; x=1711023817;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=WOjMpM+Npomr4BsE2wNuLO5CgqwO8e+gdOM4yMDJy3A=;
        b=MFV1//3BZzlo16IkFWyjVJinT1BYiw2WAbdl2GJRrlctiiLamfEOxAm56Ypa2Xqa7w
         KUHBbwHxl97+HBxG/rMj5c05MjK9qb6xoEF7J7NP29w7rK8NSwI+uZrfFJG5ktKq7xmP
         WhbZ0PxLFDz/E8KXrn9iOhzWSB8hcpZAk/+4vbyyfHasIY9ZeNTfKHsHMWbD5VO6Q8xX
         B2J3E6AWvW3NRguctswqrnccTlijpzyt3jnh3qLyBsP2/PGTB5GzxOHdTGfIrBHpeGeg
         CN/ncn07oBMDYXa8XMNT21ebf/4STwLdy1TpMb2paGbCLQ4qY47qC5aSdUwmT7G+UQLB
         doRA==
X-Forwarded-Encrypted: i=1; AJvYcCXv4qCpTtdo/mPsw2yRQzYpewRBrzbNX2JWZszqGHZte4c63Sla7TvgB9hr71gEAxw75pFkXaLur+GSV4WX2VWmNt8o6GPdRptk5RUv5R0=
X-Gm-Message-State: AOJu0YxROeE8pBl5KySlAYuJ3SJqk3cG42knxj0C93HTXS1xErL2XM9E
	sFAcKDk3d8alEzThs5JCvC+NhMaXbjOrT247iOxonK5ELy+oFaEsByWdfo+h7g==
X-Google-Smtp-Source: AGHT+IGTmU40Nx3TfIrptU2UsWf0iOe22ix1XDbX6UZvv4x9DO7r3Ts1hl5e2sCTK5RyQ+CnrzJqww==
X-Received: by 2002:a17:906:a282:b0:a45:9008:ca1b with SMTP id i2-20020a170906a28200b00a459008ca1bmr1083786ejz.1.1710419016841;
        Thu, 14 Mar 2024 05:23:36 -0700 (PDT)
Message-ID: 
Date: Thu, 14 Mar 2024 13:23:35 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH] amd/iommu: add fixed size to function parameter of
 array type
Content-Language: en-US
To: Nicola Vetrini 
Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com,
 ayan.kumar.halder@amd.com, consulting@bugseng.com, bertrand.marquis@arm.com,
 julien@xen.org, Andrew Cooper ,
 xen-devel@lists.xenproject.org
References: <533a2d4f0c92d7fe92aa200b64434389de546f69.1710343652.git.nicola.vetrini@bugseng.com>
 <6186b676-660c-4bfa-a825-18ff7f0d7f62@suse.com>
 <503aa63b5204e9b9eab5a21235df7c6c@bugseng.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <503aa63b5204e9b9eab5a21235df7c6c@bugseng.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 14.03.2024 10:25, Nicola Vetrini wrote:
> On 2024-03-14 09:32, Jan Beulich wrote:
>> On 14.03.2024 08:42, Nicola Vetrini wrote:
>>> The 'cmd' parameter of amd_iommu_send_guest_cmd is passed
>>> to a function that expects arrays of size 4, therefore
>>> specifying explicitly the size also in amd_iommu_send_guest_cmd
>>> allows not to accidentally pass a smaller array or assume that
>>> send_iommu_command handles array sizes >4 correctly.
>>>
>>> No functional change.
>>>
>>> Signed-off-by: Nicola Vetrini 
>>> ---
>>> All current users pass an array of size 4, hence this patch is 
>>> addressing
>>> a potential issue noticed by the analyzer in the context of Rule 17.5
>>> ("The function argument corresponding to a parameter declared to have 
>>> an array
>>> type shall have an appropriate number of elements"), not an actual 
>>> problem in
>>> the sources.
>>
>> While true, I think we want to consider alternatives. First one being 
>> to rip
>> out this dead code (thus addressing other Misra concerns as well). 
>> Second,
>> if we meant to keep it, to properly do away with the (ab)use of u32[].
>>
> 
> I'm not understanding what you consider dead code.

iommu_guest.c:guest_iommu_{init,destroy,set_base,add_event_log}() have
no callers; guest_iommu_add_ppr_log() having one is suspicious, but the
function will still bail early due to domain_iommu() never returning
non-NULL in practice. With that I'm pretty sure nothing else in the file
is actually reachable.

> I see three users of amd_iommu_send_guest_cmd

All in said file.

> and seven for send_iommu_command.

Well, this one of course isn't dead.

> I can adjust u32 for sure. There are also other u32/uint32_t 
> incosistencies in that header.

Which we're going to take care of over time.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 12:25:17 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 12:25:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693179.1080903 (Exim 4.92)
	(envelope-from )
	id 1rkk95-0004ms-Pa; Thu, 14 Mar 2024 12:25:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693179.1080903; Thu, 14 Mar 2024 12:25:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkk95-0004ml-Mv; Thu, 14 Mar 2024 12:25:15 +0000
Received: by outflank-mailman (input) for mailman id 693179;
 Thu, 14 Mar 2024 12:25:14 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkk94-0004mf-U1
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 12:25:14 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e7c3289b-e1fd-11ee-a1ee-f123f15fe8a2;
 Thu, 14 Mar 2024 13:25:12 +0100 (CET)
Received: from truciolo.bugseng.com (unknown [78.209.105.118])
 by support.bugseng.com (Postfix) with ESMTPSA id 805554EE0739;
 Thu, 14 Mar 2024 13:25:11 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e7c3289b-e1fd-11ee-a1ee-f123f15fe8a2
From: Federico Serafini 
To: xen-devel@lists.xenproject.org
Cc: consulting@bugseng.com,
	Federico Serafini ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini ,
	Wei Liu 
Subject: [XEN PATCH] perfc: add pseudo-keyword fallthrough
Date: Thu, 14 Mar 2024 13:25:02 +0100
Message-Id: <47eb1f8316672af172d9c34bfa6e7dda6bd7ce37.1710403601.git.federico.serafini@bugseng.com>
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Add pseudo-keyword fallthrough to make explicit the intention of the
code and meet requirements to deviate MISRA C:2012 Rule 16.3
("An unconditional `break' statement shall terminate every
switch-clause").

No functional change.

Signed-off-by: Federico Serafini 
---
 xen/common/perfc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/xen/common/perfc.c b/xen/common/perfc.c
index 7400667bf0..80480aa776 100644
--- a/xen/common/perfc.c
+++ b/xen/common/perfc.c
@@ -134,6 +134,7 @@ void cf_check perfc_reset(unsigned char key)
         case TYPE_SINGLE:
             for_each_online_cpu ( cpu )
                 per_cpu(perfcounters, cpu)[j] = 0;
+            fallthrough;
         case TYPE_S_SINGLE:
             ++j;
             break;
@@ -141,6 +142,7 @@ void cf_check perfc_reset(unsigned char key)
             for_each_online_cpu ( cpu )
                 memset(per_cpu(perfcounters, cpu) + j, 0,
                        perfc_info[i].nr_elements * sizeof(perfc_t));
+            fallthrough;
         case TYPE_S_ARRAY:
             j += perfc_info[i].nr_elements;
             break;
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Thu Mar 14 12:33:40 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 12:33:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693186.1080914 (Exim 4.92)
	(envelope-from )
	id 1rkkH8-0006Vl-Jk; Thu, 14 Mar 2024 12:33:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693186.1080914; Thu, 14 Mar 2024 12:33:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkkH8-0006Ve-FG; Thu, 14 Mar 2024 12:33:34 +0000
Received: by outflank-mailman (input) for mailman id 693186;
 Thu, 14 Mar 2024 12:33:33 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkkH7-0006VY-AZ
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 12:33:33 +0000
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com
 [2a00:1450:4864:20::62d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1127d7e6-e1ff-11ee-afdd-a90da7624cb6;
 Thu, 14 Mar 2024 13:33:31 +0100 (CET)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-a44665605f3so92273866b.2
 for ; Thu, 14 Mar 2024 05:33:31 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 jt12-20020a170906dfcc00b00a465f570dcesm680689ejc.144.2024.03.14.05.33.30
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 14 Mar 2024 05:33:30 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1127d7e6-e1ff-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710419611; x=1711024411; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=hMsj3FylCP7oKPcU/EF8ndE36MTZCLB4/juuFmblABs=;
        b=GMMsf47CwMNxRhPWIHxBl4BClggmblX6xFEJNpvykF7gUbD2G0VNZDUZirm/aELQL/
         rs3ndWix31IMI6TI+J3xWNA3YW1s3jmHLe7nz4p4xJK0E3qQrW1Q+A95MDmxkPG5scKo
         KODcnpuS31GYlH7YV0vZ2tah6NcbeCIriRVYnv+5ITnMYu9aPMZcPFXVbGFPgc2vUnyM
         F3AFlWaZDNwJtbkd9mcj3SbDjkcIEg/IB7XDURz0PiooFMjZPvxTH9LzjI6H41LDwzDy
         Q/UiObL8JOGbsyrY7KB97IpI9Umn/oPUneJbjHFLHJreeHnfJ9Yh+bI9heItPKGODjQD
         wbUA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710419611; x=1711024411;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=hMsj3FylCP7oKPcU/EF8ndE36MTZCLB4/juuFmblABs=;
        b=Lw+Bbm81sbP/Denx4/fK1f+pdzDpal9XwAQ0xTYe7v/L0Htc3TxbChUUmGcRI9DBhU
         BBEvmSGtq6UB12rSbepOJZtHc2huFBsMmj9YOWDCnIzSoAtCKlYnW9FjSwupp/XzmTKg
         0g3aFk341wO0byxbrIjZ1cms9JuLixJIJ2THngsBHHG83ZJchim9dbjtzv1svvYV5XsJ
         Q0sUmbABWb/OymQoblCcp/ldHtnLa2jzP8MoSzP2z6B1ARVrVCfeyuAe6fd4mPkooTlG
         ECDT7CGsdrslffJdb0x7JVRawDVb4/6gMC+Z2jtJ7MUG3EmNBKZ67pTmS58I3zcZnrsC
         h1Bg==
X-Forwarded-Encrypted: i=1; AJvYcCVK5jkwPD6kkkqaTzRm+StaAqoOS8oAMY1xYeDxZvst3W6lPHvAbTA+PDtAiTn3TAvUnsjy5QfCuctUem92q49ls9Sr6sXahTo+kgwlxkQ=
X-Gm-Message-State: AOJu0YxkC4BUeynwrDo63tE5ju+6fot/bAafkDVTCR2Bd64s0rJ3tDGT
	zWCAWdZlL/2yJ1sfl4q0uu/vXF7rTxzpUvvRIxwd2Y81tvouRRHJ2S8/jfGfiA==
X-Google-Smtp-Source: AGHT+IHlBshpT5wwt9H9QyXHl7jS/FBPdtn8H6tl8IxX/K/AcevIK/rm8nI2qSx6+GUCE6suOiq/JQ==
X-Received: by 2002:a17:906:1d1a:b0:a45:22e2:bd6 with SMTP id n26-20020a1709061d1a00b00a4522e20bd6mr362732ejh.23.1710419611175;
        Thu, 14 Mar 2024 05:33:31 -0700 (PDT)
Message-ID: <617f4e55-4b7c-424a-b545-ce117bb264fb@suse.com>
Date: Thu, 14 Mar 2024 13:33:29 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH] perfc: add pseudo-keyword fallthrough
Content-Language: en-US
To: Federico Serafini 
Cc: consulting@bugseng.com, Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 xen-devel@lists.xenproject.org
References: <47eb1f8316672af172d9c34bfa6e7dda6bd7ce37.1710403601.git.federico.serafini@bugseng.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <47eb1f8316672af172d9c34bfa6e7dda6bd7ce37.1710403601.git.federico.serafini@bugseng.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 14.03.2024 13:25, Federico Serafini wrote:
> Add pseudo-keyword fallthrough to make explicit the intention of the
> code and meet requirements to deviate MISRA C:2012 Rule 16.3
> ("An unconditional `break' statement shall terminate every
> switch-clause").
> 
> No functional change.
> 
> Signed-off-by: Federico Serafini 

Acked-by: Jan Beulich 




From xen-devel-bounces@lists.xenproject.org Thu Mar 14 12:47:01 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 12:47:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693191.1080923 (Exim 4.92)
	(envelope-from )
	id 1rkkU3-0008HZ-MB; Thu, 14 Mar 2024 12:46:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693191.1080923; Thu, 14 Mar 2024 12:46:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkkU3-0008HS-Jb; Thu, 14 Mar 2024 12:46:55 +0000
Received: by outflank-mailman (input) for mailman id 693191;
 Thu, 14 Mar 2024 12:46:54 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkkU2-0008HM-0j
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 12:46:54 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on2062c.outbound.protection.outlook.com
 [2a01:111:f400:7e88::62c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ebfebc61-e200-11ee-a1ee-f123f15fe8a2;
 Thu, 14 Mar 2024 13:46:49 +0100 (CET)
Received: from CY5P221CA0017.NAMP221.PROD.OUTLOOK.COM (2603:10b6:930:b::18) by
 IA1PR12MB9062.namprd12.prod.outlook.com (2603:10b6:208:3aa::14) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.21; Thu, 14 Mar
 2024 12:46:46 +0000
Received: from CY4PEPF0000E9DB.namprd05.prod.outlook.com
 (2603:10b6:930:b:cafe::7f) by CY5P221CA0017.outlook.office365.com
 (2603:10b6:930:b::18) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.21 via Frontend
 Transport; Thu, 14 Mar 2024 12:46:46 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 CY4PEPF0000E9DB.mail.protection.outlook.com (10.167.241.81) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7386.12 via Frontend Transport; Thu, 14 Mar 2024 12:46:45 +0000
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 14 Mar
 2024 07:46:45 -0500
Received: from [172.17.162.8] (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Thu, 14 Mar 2024 07:46:44 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ebfebc61-e200-11ee-a1ee-f123f15fe8a2
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=IY2UGM5ym2E3El9xU+31Z+CG6nU9+XAEjiddEMrOR+iXl5SkFx7tmVX1H7iaI3T9CJLMoCk7ar5Xk7E5sANSxKzmaAzDWwuax+7uIyqUKGmuXXuVtsl3H6juH/q5hFRCdS0OqX9Hov0JCv7pigdYaRFSL2tjb7Hg/N1hAFRtcLBfRBdBrDSCYbYVslEcJ1XzAtVsxgUHbZ4twyq1EdElxUKIzOzLrIuoXKkOSUmNwVNTnoRt68WKJ/51R8dXY+FiwDFNMFcrUYM/nMQ2tY2Oy67cj+x5NY4XdrkbaCA85M15DroSEVZdSo+SspAk4IjzKYTwux4qkqW6KyvoVNgm1w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=zwsxoslQo6epcIHeLAvExmX6llLb507hpt1snaIsrBI=;
 b=dvWLIoFUKbPc2tn+wrbDauEKWyEnUmJ1mqi6xC0BQaJ9w+E+Ci6JrwVpmOzlFXu767yGo4yH7TlKQIzHKctbPkFseutoFv/2Z3PdoO3UjVie8bU3xIKCbqv+lluiFUWrwzGVPkiFtu32PT+W4XU2z+pT7PfVyZncJvX3OcPZ3t4/P4EkjTpczkRtkU8y3pNOpa8mnAkjBrRnbplVQVWQziG1EYvkqKNELqJVvUnMwdEVUDnQakOPhI8Bqy23fgSEQ83SXPdB2KXU7WEj9SZgNvVqKuuu8LybqZdhuQxzNfXGGPpfYpBoDU9okHe790Qz23zRfEu29YkL7SxZNjfI8w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=zwsxoslQo6epcIHeLAvExmX6llLb507hpt1snaIsrBI=;
 b=1LMCsyYcEAhbMWw8vWP2sjESyyebI0FOAWrWtkufG+MeU/hhVaWBB3leVQNujlE1fk93PTTi+s+h3TeRvMV8f0dG4CPhcoPk015ASMB9JMIq/2eifaCxL5+DbYumUoygfC7OjLldq5NrpTdW3sjDMHA8GTXlLvfJAMcS3/CWybM=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
Message-ID: <53900008-c10c-44af-bdbd-bf78c5d6f4ff@amd.com>
Date: Thu, 14 Mar 2024 08:46:41 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 3/3] x86/PVH: Support relocatable dom0 kernels
To: Jan Beulich , 
CC: Andrew Cooper ,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu
	, George Dunlap , Julien Grall
	, Stefano Stabellini 
References: <20240313193021.241764-1-jason.andryuk@amd.com>
 <20240313193021.241764-4-jason.andryuk@amd.com>
 <70daf607-03e7-4927-8ce2-5721ca3387ee@amd.com>
 
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: 
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB03.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CY4PEPF0000E9DB:EE_|IA1PR12MB9062:EE_
X-MS-Office365-Filtering-Correlation-Id: cb8eb9f8-5c4a-458d-8d6e-08dc4424ceb8
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	TMjFGvx6P9z5+4eOx0vo2uKqWS2yQ8pgxQcq0wmkFAmiR0Q4MGKHxXCnZ4BRONrOOKwqOV8fyxvNOkBmib+XS9Fk+ZgT6B8IcIM12PTfQj6u5d93nk/0XK3VYIinS490RHfCd6SelDYiKk47hIqDDlp0w7dYSWqonE1zOaEr+cNCPKze8rbkNjd0a3zTIanXbw2ysXO/TDCOo6zHQl09Rm9Kz1QZ76hwwcws5QVCjnhVW7V6vygOnkShxUGzEbtNVoCRampa0bDDhW2wsdWW98mvUGQ29SAhokl5YDCjLKOnz3a/lQroy7pYMsLX7+MPL1tEDsSfHbKZ50hLJCk/XN6tEIiK8dESF0yo1/bx3WdbMk0b+zZhmNuoSkiJHx4bm1lL+tbjsCUNUuyOgfTMf+JzAbMqqC+/HWGSzkzSwsxTR0Y0KSSAYd0Is2FEKuzuigGpH0+3E5UNR5qSN5u+b5aITTcb3U/ZjLgGo6ZWcJY+CwyssaSwvynZlxyeNr5JxcT3u/TrkCNwfuvWTEyrbrGTA8dHK6Y1oeTLpTZvGkvFJhNYCn7iA4MLXCuZqA3l9flpH2+QgFDpJjJkgWQOUv8pT0n4fgAiTkjcWOKQWz8RRqMwju+qTUaQVt/Co5wWcDkmb5PRGuk2dqGn1xziQsu+j/g3MIo2dZ3mmsPz5C9PFtxs6kWzzlo5wqHgl3EN2d6Oqbo0Xt+4B+/Vjo37g1lHbV5laadxPv8rMhrXlUFomZXKb8oaOHJ0ll4P/DKd
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(82310400014)(1800799015)(376005)(36860700004);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Mar 2024 12:46:45.6543
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: cb8eb9f8-5c4a-458d-8d6e-08dc4424ceb8
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CY4PEPF0000E9DB.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB9062

On 2024-03-14 03:12, Jan Beulich wrote:
> On 13.03.2024 22:02, Jason Andryuk wrote:
>> On 2024-03-13 15:30, Jason Andryuk wrote:
>>> +/* Find an e820 RAM region that fits the kernel at a suitable alignment. */
>>> +static paddr_t __init find_kernel_memory(
>>> +    const struct domain *d, struct elf_binary *elf,
>>> +    const struct elf_dom_parms *parms)
>>> +{
>>> +    paddr_t kernel_start = (paddr_t)elf->dest_base & PAGE_MASK;
>>> +    paddr_t kernel_end = PAGE_ALIGN((paddr_t)elf->dest_base + elf->dest_size);
>>> +    paddr_t kernel_size = kernel_end - kernel_start;
>>> +    unsigned int i;
>>> +
>>> +    /*
>>> +     * The memory map is sorted and all RAM regions starts and sizes are
>>> +     * aligned to page boundaries.
>>> +     */
>>> +    for ( i = 0; i < d->arch.nr_e820; i++ )
>>> +    {
>>> +        paddr_t start = d->arch.e820[i].addr;
>>> +        paddr_t end = d->arch.e820[i].addr + d->arch.e820[i].size;
>>> +        paddr_t kstart, kend;
>>> +
>>> +        if ( d->arch.e820[i].type != E820_RAM )
>>> +            continue;
>>> +
>>> +        if ( d->arch.e820[i].size < kernel_size )
>>> +            continue;
>>> +
>>> +        kstart = ROUNDUP(start, parms->phys_align);
>>> +        kstart = kstart < parms->phys_min ? parms->phys_min : kstart;
>>
>> This should be
>>           kstart = MAX(kstart, parms->phys_min);
> 
> Except that MAX() really ought to be the last resort; max() and max_t()
> want considering in preference.

Yes, thanks.  max() will do.

Regards,
Jason


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 13:01:00 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 13:01:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693199.1080954 (Exim 4.92)
	(envelope-from )
	id 1rkkhW-0002yi-2a; Thu, 14 Mar 2024 13:00:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693199.1080954; Thu, 14 Mar 2024 13:00:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkkhV-0002yb-Vm; Thu, 14 Mar 2024 13:00:49 +0000
Received: by outflank-mailman (input) for mailman id 693199;
 Thu, 14 Mar 2024 13:00:49 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkkhV-0002yI-Cw
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 13:00:49 +0000
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com
 [2a00:1450:4864:20::635])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e0b893b7-e202-11ee-afdd-a90da7624cb6;
 Thu, 14 Mar 2024 14:00:48 +0100 (CET)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-a3122b70439so106677666b.3
 for ; Thu, 14 Mar 2024 06:00:48 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 h25-20020a17090634d900b00a454438091fsm695601ejb.70.2024.03.14.06.00.47
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 14 Mar 2024 06:00:47 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e0b893b7-e202-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710421248; x=1711026048; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=xxX6tRihFpbFbxjTQJfpq7y02+CBj3GJMuSLm/6MH3E=;
        b=DfJyGOJMsDEwpUw8c+8VpzDhv/kG9uWoQFZZuEYRia2QP2Tty6KSFWBOrxh1Y41376
         VvMI8gFpPqZcOSnm68BjvOzSMeVDaoUdToOJ4sUf2bCg0s7cQEVyLz1nCVjWzBjrhqxE
         Jag4wiQPF2H/2H9J5rZd4vdKuMtrtJLVFgp4ytHdUkzfJCL7oK05X7XUpFC4hUuURmrG
         8jH/SeQFpDyXM6QyKMQzg3oDaihi1eHZ8OFHI6CDojFUwZxeCPC+/yAgWk0wxrhHZR9T
         IvN0eUKrHLvq8JcdG5aVZjIC7n4kKwgv5arXSBwwLTKjH8yWmtzon7/xsdh83i/yi7np
         63+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710421248; x=1711026048;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=xxX6tRihFpbFbxjTQJfpq7y02+CBj3GJMuSLm/6MH3E=;
        b=KtkSaWHtHd4fTMTjUe2vsjY7yUjodL3KpvSTWR/Q9JyAsA2pxyI04O4osqJx9J4RmP
         QMRu/lC99yRlZeHk2jxJgKJJPd+C2OLUzRrs4VEtCBIC0TdCwgp+18EMLoJsVjqnJJfI
         yoBOPPp6L9dx+R0HYn31EVexj/qOAzxvzCCCfCCpJQb1VZ/cCIWwUmsqpIV1rEE6usvt
         SR4YNDyYBoqsmBE5Zj72qiWrqOu78aVcof/idcPYfW7et2qz/SmiWJgnuuwNxHt8yunm
         gPBtTgaKkyrVKf8UKUCXEU+Sqxkv72wqGSx5hicdL9sA/igiBjxT0xE+ehrRbF8L4uRA
         CCaA==
X-Forwarded-Encrypted: i=1; AJvYcCWJQcBMO/JguXmDqKW9nlf4uN2NpBNyr3sR1pd9dd1Qk3FVOKlVV6uNq9K2uRH9O9/0jihGqlc17EtZMudnae0ZJfAwjg/PH3ofp+lTRbc=
X-Gm-Message-State: AOJu0YzCbFyoo+scWl16LhT/fOi5kf8ZtnxZpP/OBSuShgXCOk6wgYYa
	sMMAIDg+2LYeU6vfvm9yStJBqEtP0TxzTRqH91GZbwCXjM+vwS/ikDJ3OWjILQ==
X-Google-Smtp-Source: AGHT+IFYZmJl5OU+ACmgMU0urdDqIm7Kek42Ih2zzJ9ZaYdIJDRN6z84/8D5IVEsSuVzUG0ZlDUryQ==
X-Received: by 2002:a17:906:26cb:b0:a46:61ef:2846 with SMTP id u11-20020a17090626cb00b00a4661ef2846mr1110386ejc.66.1710421247951;
        Thu, 14 Mar 2024 06:00:47 -0700 (PDT)
Message-ID: 
Date: Thu, 14 Mar 2024 14:00:45 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH v3 15/16] x86/mtrr: address violations of MISRA C:2012
 Directive 4.10
Content-Language: en-US
To: Simone Ballarin ,
 Maria Celeste Cesario 
Cc: consulting@bugseng.com, sstabellini@kernel.org,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu
 , xen-devel@lists.xenproject.org
References: 
 <33413c877af70c8aed05ed1bc7b259c59087cb96.1710145041.git.simone.ballarin@bugseng.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <33413c877af70c8aed05ed1bc7b259c59087cb96.1710145041.git.simone.ballarin@bugseng.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 11.03.2024 09:59, Simone Ballarin wrote:
> From: Maria Celeste Cesario 
> 
> Add inclusion guard to address violations of
> MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order to
> prevent the contents of a header file being included more than once").
> Mechanical change.
> ---
> Commit introduced in v3

I almost hadn't noticed this misplaced revlog (also in patch 16); with
it kept in place I expect git would have zapped ...

> Signed-off-by: Maria Celeste Cesario  
> Signed-off-by: Simone Ballarin  

... all tags.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 13:01:43 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 13:01:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693205.1080976 (Exim 4.92)
	(envelope-from )
	id 1rkkiN-0003gU-HZ; Thu, 14 Mar 2024 13:01:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693205.1080976; Thu, 14 Mar 2024 13:01:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkkiN-0003gN-EM; Thu, 14 Mar 2024 13:01:43 +0000
Received: by outflank-mailman (input) for mailman id 693205;
 Thu, 14 Mar 2024 13:01:42 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkkiM-0003g3-BW
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 13:01:42 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on20600.outbound.protection.outlook.com
 [2a01:111:f403:2418::600])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id fe27e87b-e202-11ee-afdd-a90da7624cb6;
 Thu, 14 Mar 2024 14:01:41 +0100 (CET)
Received: from BN0PR02CA0046.namprd02.prod.outlook.com (2603:10b6:408:e5::21)
 by MW6PR12MB8833.namprd12.prod.outlook.com (2603:10b6:303:23f::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.35; Thu, 14 Mar
 2024 13:01:35 +0000
Received: from BN2PEPF000044A1.namprd02.prod.outlook.com
 (2603:10b6:408:e5:cafe::b1) by BN0PR02CA0046.outlook.office365.com
 (2603:10b6:408:e5::21) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.20 via Frontend
 Transport; Thu, 14 Mar 2024 13:01:34 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN2PEPF000044A1.mail.protection.outlook.com (10.167.243.152) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7386.12 via Frontend Transport; Thu, 14 Mar 2024 13:01:34 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 14 Mar
 2024 08:01:33 -0500
Received: from [172.17.162.8] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Thu, 14 Mar 2024 08:01:33 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: fe27e87b-e202-11ee-afdd-a90da7624cb6
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=GdQTB/btjcGaMAVbp0lABPRf0/PeVeDJDJ9yOg3zu2ijum8tOS0c0cpqAvVNC1UJvSsqBDEYGjfseZDpNkw00Ne9E5POXxcgW05b0OB7TuWNre6gSlYHKTuRQwikcl4jHhIaYJl72Cup645OANXmKmo/5W/PFrIMBgukBtJVLLozBj4AHpZ0AeRZzYEKms0t1pAHhab7tPbkylpDlfOLkiaCP3VSe2R6IYoPEcZ7H7lNE6RBENy7mmZz9x0TjgaB+LkfA0+VULeVhrPvQkH2RzXZVIZmLvELEd8JGsE03YskHwF19CJePt00gKu/t7AaCBQFMD3BpjBMz+hkfu680g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=2DHtA8NVvw/hqNNL6V0lTnnxoGT8K7/zE/1b3H+04ic=;
 b=CRZXeifnvilGo6pCpBVYyonYIlZ/witq4ow1K2dLgRYGfdHSteBapBPNWPjw+D9FvuxBib1Vt/jB1jbWd1Nhtd48cGgghcn7d4d68u6g13nT3jZRu/vscQvuxYZJV0GNeeOdJV0bmgqFhYsaKzMoe+XTGOTzxG5zXSKdZ7rTXJNi585XNFfe7UUxWrYxC6jqrfoZe/bGYa0jfNQM88Czqc9ZsUamTppY4MZ2032qvETjJRYXEaXIq4qHuUDA9B9YAyBvX6rWQSLUAJUZDHoQuirGiNQzPU4i3cH9ms9N/SSftyHKasRyvjhMnDfvepYlCbjURT8Qt2jiy6hZMcOF4A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=2DHtA8NVvw/hqNNL6V0lTnnxoGT8K7/zE/1b3H+04ic=;
 b=xAn5iJwBEwW6O0qZ0GyyhAIP0cLhaoOTapHzs/tIzb26KYNlnnf5tnwNg1Rlylc7xCbrQ1yDmj0I+I+8fcxBhOfptKSPcEIZAyMfGLrK0VeZ2k27lkpwgt5dsDd8hLxaqTUtnuGyzNUIiTEAhq1o1K86DaoD7aPePIWvepokwio=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Message-ID: 
Date: Thu, 14 Mar 2024 09:01:26 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/3] Revert "xen/x86: bzImage parse kernel_alignment"
Content-Language: en-US
To: Jan Beulich 
CC: Andrew Cooper ,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
	, Wei Liu 
References: <20240313193021.241764-1-jason.andryuk@amd.com>
 <20240313193021.241764-2-jason.andryuk@amd.com>
 <82ae53ac-f2d1-4d86-8719-4e5cc2e5f57d@suse.com>
From: Jason Andryuk 
In-Reply-To: <82ae53ac-f2d1-4d86-8719-4e5cc2e5f57d@suse.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB04.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN2PEPF000044A1:EE_|MW6PR12MB8833:EE_
X-MS-Office365-Filtering-Correlation-Id: 97d96a7b-56c5-446f-3413-08dc4426e091
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	KBWSN2JS8BVT4oSZxBlWhWTT+OVoT/0iLC+lnB/YETEmopF9bjs1QIKZdmpBupNgC/SXj/3Xfcw5h8jmfpNv1jGaHjUm5wsZot1/1DblBCzrrTpBu4Fv8H9yyVY3C9vvOnheSdXFJpGdzrcwVprjys7hFZiCjJKeGHTAaGlQHS2zGrgNE6m2J+F+Fnu5niK6qYlO/PvhUlZIGUe4u+Vo4qNZR8PfoWCe4YTbsnV7yoFFwaQuLHivpAgfQoGHW6UmbkWGfAefqBAdBLEPnIqIy2DSJUCEOZYJdh979XMSHZOLlUZTR1ntsHBmeUTRlw/r3V7EFAQI2ivPdRg7nyAUveqY3JHSKWWudr0X7ph9lbnIV4dGQIsR14s4ShhX1rfk6ZcZzv6BAPBwh4IW5cXC25KjE2ZaLIZDYpZ6WZqRLDmZzl0XqIvOA8bsmuFpMouNZgMjYS3IF1RT0Z63nBk0xM9Vfl5yLyOIlAXXWw6W1zfmDCqZuavCTWSVB0Jv+dODk4Hifou9xsFOGe2Gxvue8UliVYpADHUwrUTxjCzYWEFYP28znlIW7LubCKTgPcEUjC7k+kj/8KBpqtdxTT8n05QSB3j4QK89/z7MknUzQUrF2RGRHrjyNwumNaFeRQu6HmvTpUJQHtOzHWlc/IS75MqMYJVheZxK4hLwPmeGpOHTYTkCeVgQgsCGPaIhXpoIt6y7dCh+D6Y3Pk18KY6uLpLRss87FyGajfRwFJxS4emiYpz250WZ9M0Bw5n0NpRT
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(36860700004)(1800799015)(376005)(82310400014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Mar 2024 13:01:34.6357
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 97d96a7b-56c5-446f-3413-08dc4426e091
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN2PEPF000044A1.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW6PR12MB8833

On 2024-03-14 03:11, Jan Beulich wrote:
> On 13.03.2024 20:30, Jason Andryuk wrote:
>> A new ELF note will specify the alignment for a relocatable PVH kernel.
>> ELF notes are suitable for vmlinux and other ELF files, so this
>> Linux-specific bzImage parsing in unnecessary.
> 
> Hmm, shouldn't the order of attempts to figure the alignment be ELF note,
> ELF header, and then 2Mb?

This patch series makes Xen only relocate when the ELF Note is present. 
Linux PVH entry points today are not relocatable, so that needs to be 
specified some way.  This new note also includes the alignment, so there 
is no need to try other means of obtaining the alignment.

Also, the ELF header values didn't change with CONFIG_PHYSICAL_ALIGN, so 
that didn't seem reliable.

Thanks,
Jason


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 13:05:06 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 13:05:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693207.1080987 (Exim 4.92)
	(envelope-from )
	id 1rkkld-0004K8-12; Thu, 14 Mar 2024 13:05:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693207.1080987; Thu, 14 Mar 2024 13:05:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkklc-0004K1-T3; Thu, 14 Mar 2024 13:05:04 +0000
Received: by outflank-mailman (input) for mailman id 693207;
 Thu, 14 Mar 2024 13:05:03 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1rkklb-0004Jo-Rk
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 13:05:03 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkklb-0000FK-Gt; Thu, 14 Mar 2024 13:05:03 +0000
Received: from [15.248.2.233] (helo=[10.24.67.21])
 by xenbits.xenproject.org with esmtpsa
 (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92)
 (envelope-from )
 id 1rkklb-0002BL-9l; Thu, 14 Mar 2024 13:05:03 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=RMLE+8EQP3e1rIQFGir0fpapdmY+/+zZKLCMYIH65o0=; b=YXIX1BYv+z//xY2zYG3SNFqQ0M
	A45ztxEOKsDvxUItju+fGS7Pv3ERJuXEO8NlN0UZ6ogUIzJYE5E0URh1CUdobfKXv7NLztvIZSJ8S
	2I/FFu5hbNBqGNvxzE3xym9uqbZRZQUYloAwQkkun25EipVHJJyoNsxb073YWQvYaDd4=;
Message-ID: <8dfba9d5-8bed-4952-82a7-5ab41e74df16@xen.org>
Date: Thu, 14 Mar 2024 13:05:01 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN v6 0/3] xen/arm: Add emulation of Debug Data Transfer
 Registers
Content-Language: en-GB
To: Ayan Kumar Halder ,
 xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org, stefano.stabellini@amd.com,
 Volodymyr_Babchuk@epam.com, bertrand.marquis@arm.com, michal.orzel@amd.com
References: <20240307123943.1991755-1-ayan.kumar.halder@amd.com>
From: Julien Grall 
In-Reply-To: <20240307123943.1991755-1-ayan.kumar.halder@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Ayan,

On 07/03/2024 12:39, Ayan Kumar Halder wrote:
> Hi,
> 
> Refer https://lore.kernel.org/all/alpine.DEB.2.22.394.2312071341540.1265976@ubuntu-linux-20-04-desktop/T/
> for the previous discussion on this issue.
> 
> Also, the linux earlycon hvc driver has been fixed.
> See https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git/commit/?h=tty-next&id=0ec058ece2f933aed66b76bd5cb9b5e6764853c3
> 
> Changes from v1:-
> 1. Split the change across 3 patches as per the design consensus.
> 
> v2 :-
> 1. Reordered the patches.
> 
> v3 :-
> 1. Change mentioned in individual patches.
> 
> v4 :-
> 1. Change mentioned in individual patches.
> 
> v5 :-
> 1. Change mentioned in individual patches.
> 
> 
> Ayan Kumar Halder (2):
>    xen/arm: Introduce CONFIG_PARTIAL_EMULATION and "partial-emulation"
>      cmd option
>    xen/arm: arm32: Add emulation of Debug Data Transfer Registers
> 
> Michal Orzel (1):
>    xen/arm: arm64: Add emulation of Debug Data Transfer Registers

I have committed the 3 patches.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 13:17:05 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 13:17:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693215.1081008 (Exim 4.92)
	(envelope-from )
	id 1rkkxA-0006QE-5v; Thu, 14 Mar 2024 13:17:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693215.1081008; Thu, 14 Mar 2024 13:17:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkkxA-0006Q7-2C; Thu, 14 Mar 2024 13:17:00 +0000
Received: by outflank-mailman (input) for mailman id 693215;
 Thu, 14 Mar 2024 13:16:58 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkkx8-0006Q1-8L
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 13:16:58 +0000
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com
 [2a00:1450:4864:20::535])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2169455b-e205-11ee-a1ee-f123f15fe8a2;
 Thu, 14 Mar 2024 14:16:56 +0100 (CET)
Received: by mail-ed1-x535.google.com with SMTP id
 4fb4d7f45d1cf-5689f4d318fso1127033a12.0
 for ; Thu, 14 Mar 2024 06:16:55 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 v23-20020a1709067d9700b00a461a7ba686sm709882ejo.75.2024.03.14.06.16.48
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 14 Mar 2024 06:16:55 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2169455b-e205-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710422215; x=1711027015; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=6xDKgJDGSYr7k+8waxFdvg07emX4bhKkBKNzDxX580I=;
        b=g1jTntNmUaDxKoOQhaCVAacNzwHiVR/ZiGbv2vWxOQEyAJnDasZO016ZFZtj6D2ope
         94OimlClx0lqk2Sp3Kcr4Qufqnw0XGIhKw3eHXvLKndxLe7YBMrWF8XzIbxXsSiz202a
         l40hxCxWNsO88AFFQg6I10sWBfJP+gZm0QIxzJ+ggtNYSrwf5l/CoAxGlo6Hcb7cjtpb
         kkTDncoyYU/bzjTlvLPDKRAN2d1HnKAcTMyI3m1GvUl3n3u/FHbhcTOD+SCUN8e8GSTz
         iOGkIK49XpUC1cjocrcIqoNN5SNzw/oWey8080xltYxWzC/9dyqi7xRxR0W3hfR9aGOK
         1AmQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710422215; x=1711027015;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=6xDKgJDGSYr7k+8waxFdvg07emX4bhKkBKNzDxX580I=;
        b=XgLuFE/9hYrrtchw54GkIWPZUpa56jbVPWkZjxB7/vnxI59Z9S/aq0odAiDT168V+o
         wdT9EvwcDiTtCegthmefw69kppRY4ZTuNiMCtHSvvm94HrxrdrTsyZUXkC1NB8lrXU3f
         VzysRNPCU3rl/9m980EAc95nukLYeoUFih4BHgVl/oGsXWb6Rf5d/cBF3MRsBzO+bKwu
         8xx+7prfXL9F8y78aucUnhzi+CRAY/Ygf6l+3tKbRwIaOOK0lX2mkzxkXimsSRRRyh3u
         c/F7Iap3UvC4pM8lQVY88rCegkZXNBMJ4+qkC75xEtu/U64ScYrLBjtXvlYErk4OMny4
         NfvA==
X-Forwarded-Encrypted: i=1; AJvYcCUbTgLlxoAJj+kZEeAKrSZkp3przJ3hVHOr6yOwKg0g+RvFLgxCe6TaaR5FslHWbhOS7bdwigxpFyTRjvlP0QtCIhFlHrfYc8uUDEeC9is=
X-Gm-Message-State: AOJu0Yx9M7QHHnaCArQle0fmcMqzcCQOY+FAJP93HYUCEdgd3ysT1J+g
	9kWTMImU694R2n/nvM1kE62fMyvgT/Hx9dFtdNe5VgKiUM18+oqse2t+KjK/Fw==
X-Google-Smtp-Source: AGHT+IHCEWfphZRblLvqN52y2avWfZEd1GZr1Lb9E5Mj/eYmgAJ8xXO3+t9gwz+5Nm7G71sRmrfFhQ==
X-Received: by 2002:a17:906:6b12:b0:a45:ada9:4bf1 with SMTP id q18-20020a1709066b1200b00a45ada94bf1mr4980983ejr.12.1710422215363;
        Thu, 14 Mar 2024 06:16:55 -0700 (PDT)
Message-ID: 
Date: Thu, 14 Mar 2024 14:16:47 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/3] libelf: Expand ELF note printing
Content-Language: en-US
To: Jason Andryuk 
Cc: Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 xen-devel@lists.xenproject.org
References: <20240313193021.241764-1-jason.andryuk@amd.com>
 <20240313193021.241764-3-jason.andryuk@amd.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240313193021.241764-3-jason.andryuk@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 13.03.2024 20:30, Jason Andryuk wrote:
> @@ -217,6 +225,15 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
>      case XEN_ELFNOTE_PHYS32_ENTRY:
>          parms->phys_entry = val;
>          break;
> +
> +    case XEN_ELFNOTE_L1_MFN_VALID:
> +        if ( elf_uval(elf, note, descsz) != 2 * sizeof(uint64_t) )
> +            return -1;

elf_note_numeric() use sites don't have such a check. Why would we need
one here, and even more so causing a error to be raised when in reality
the supplied values (still) aren't consumed? Furthermore the documentation
says "pairs" (plural) for a reason. Finally maddr_t-sized only happens to
mean uint64_t on all architectures we presently support.

Jan

> +        elf_msg(elf, "mask: %#"PRIx64" val: %#"PRIx64"\n",
> +                elf_note_numeric_array(elf, note, 8, 0),
> +                elf_note_numeric_array(elf, note, 8, 1));
> +        break;
>      }
>      return 0;
>  }



From xen-devel-bounces@lists.xenproject.org Thu Mar 14 13:21:55 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 13:21:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693217.1081018 (Exim 4.92)
	(envelope-from )
	id 1rkl1t-0008Iw-OC; Thu, 14 Mar 2024 13:21:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693217.1081018; Thu, 14 Mar 2024 13:21:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkl1t-0008Ip-KR; Thu, 14 Mar 2024 13:21:53 +0000
Received: by outflank-mailman (input) for mailman id 693217;
 Thu, 14 Mar 2024 13:21:52 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkl1s-0008Ij-CF
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 13:21:52 +0000
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com
 [2a00:1450:4864:20::12a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d0ea69af-e205-11ee-a1ee-f123f15fe8a2;
 Thu, 14 Mar 2024 14:21:50 +0100 (CET)
Received: by mail-lf1-x12a.google.com with SMTP id
 2adb3069b0e04-512ed314881so881170e87.2
 for ; Thu, 14 Mar 2024 06:21:50 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 p13-20020a170906228d00b00a4674a2bb3csm486762eja.1.2024.03.14.06.21.49
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 14 Mar 2024 06:21:49 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d0ea69af-e205-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710422510; x=1711027310; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=g7m8/tJkD59UgmWhQUC53WkJ0pubyi6X1UATytYLsMo=;
        b=U8hOP/Bg/oplqTcs4qXImAvhAOX7ZTLdyT57NIpoxMjjggCZOdhQnhoJsZd/HtSZuw
         5yyHCD8gYIJtybrF/TOTqfa7tz8SmNYoH/DwMiBA8TXIVqEl4o4Fm6uTL3NRxJbeCne4
         gSr3MykgKV8A3HKHKr2qiX3vZfhHB4fRmYQoQai8Nsdu+/6e/Tnhksmo4WAkFgrTH8at
         zr5x1s/m/lmMz0fZeI+cG3egdAAeVyH3OovnWMCqApm2TzhYlpi2J494yocPXZ1HM1tI
         UoNDSWhFIhil1Jt10/IygksRgH2rKcXfI3E8yqhUX268wSW0xMAB11uSou8PODei9KKK
         R/Lg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710422510; x=1711027310;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=g7m8/tJkD59UgmWhQUC53WkJ0pubyi6X1UATytYLsMo=;
        b=smDUDQ/j3qpa0tR5MfiCIQfADwNkqnyj9M8ZZV6O/9vlMYgPbIAlK7pGtFK8j0Mk4V
         G8vbyBS3+tz8vLZAbG+p2W4GmL20gr0ay4y49prrgUj+NybAMXTJdKpPeW/AzthvPupG
         DuREKHtn1+SxGvhYeTpr9jCs+jT7Zd3y0Ewt7JmjwfsdiqEeNY2SRShX2IQdQ0XaKcmX
         MJCUI5OVbn6tOJKvNTCRK3L/h2dOjmX1BvW+o0eiV37jKiy1WgKlGqxEPUqYJ9jbTz+F
         53QUks+gq+jHeT9SxovOtf8oqGsCrwn6GU9O7c4UGADEwBuu3RKlfwRtN61IaJMEMboL
         ucCg==
X-Forwarded-Encrypted: i=1; AJvYcCVTMNdaw7qPHvM74tCJcJUeYrodftTrZXHbWBzYMJ+fKbkRrBtLrsjAtYcFN/KZ16RHy8KnOOgNu6wbbngg1svNcYLjkHcy854HPxh0aUo=
X-Gm-Message-State: AOJu0YwPr0Tisw6l5apkgtezsoC1di6QvkWdmHnLw3Kvaj0dXRbnroUW
	0eWih4UF3N3Dp5t9+6phUByPcxlgmVN8m7Lrv/qbsYntQdxru1M8A7UXneF8XQ==
X-Google-Smtp-Source: AGHT+IG7zbROVytd1lxmw89V2aZzPFxVfPvSu+JWHNDuU5xQp0oZ6IXDTXc5X2CCMWnMl246+2XI0A==
X-Received: by 2002:a05:6512:32a6:b0:513:c54d:d4a with SMTP id q6-20020a05651232a600b00513c54d0d4amr1220022lfe.5.1710422509801;
        Thu, 14 Mar 2024 06:21:49 -0700 (PDT)
Message-ID: <945609d6-741e-4934-a4f2-6e5597ce5dcd@suse.com>
Date: Thu, 14 Mar 2024 14:21:48 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 3/3] x86/PVH: Support relocatable dom0 kernels
Content-Language: en-US
To: Jason Andryuk 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu
 , George Dunlap ,
 Julien Grall , Stefano Stabellini ,
 xen-devel@lists.xenproject.org
References: <20240313193021.241764-1-jason.andryuk@amd.com>
 <20240313193021.241764-4-jason.andryuk@amd.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240313193021.241764-4-jason.andryuk@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 13.03.2024 20:30, Jason Andryuk wrote:
> --- a/xen/include/public/elfnote.h
> +++ b/xen/include/public/elfnote.h
> @@ -194,6 +194,17 @@
>   */
>  #define XEN_ELFNOTE_PHYS32_ENTRY 18
>  
> +/*
> + * Physical loading constraints for PVH kernels
> + *
> + * Used to place constraints on the guest physical loading addresses and
> + * alignment for a PVH kernel.  This note's value is 3 64bit values in
> + * the following order: minimum, maximum and alignment.

Along the lines of what I said on another sub-thread, I think at least
alignment wants to be optional here. Perhaps, with max going first, min
could also be optional.

As indicated in different context by Roger, the values being uniformly
64-bit ones also is questionable.

> + * The presence of this note indicates the kernel is relocatable.

I think it wants making explicit here that the act of relocating is still
left to the kernel.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 13:27:36 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 13:27:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693221.1081028 (Exim 4.92)
	(envelope-from )
	id 1rkl7L-0000St-AP; Thu, 14 Mar 2024 13:27:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693221.1081028; Thu, 14 Mar 2024 13:27:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkl7L-0000Sm-7O; Thu, 14 Mar 2024 13:27:31 +0000
Received: by outflank-mailman (input) for mailman id 693221;
 Thu, 14 Mar 2024 13:27:30 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1rkl7K-0000Sg-2f
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 13:27:30 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkl7J-0000eY-G1; Thu, 14 Mar 2024 13:27:29 +0000
Received: from [15.248.2.233] (helo=[10.24.67.21])
 by xenbits.xenproject.org with esmtpsa
 (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92)
 (envelope-from )
 id 1rkl7J-0003TK-8S; Thu, 14 Mar 2024 13:27:29 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=pQelkiwX0kX7ykh541CjD1da4ARJjAM4zimwE5aQOGk=; b=b0JSf5POyVk2QTyf54K8jbl+AE
	zyuFdWlAHAns6nTI98B878sA0Pw0T1S5RztuzRBl8dIt/d4iNI5YOt6pnHqwmOben8PPxsXoi/RO1
	hh6axB8F090AkJ8B14q2j/jzdPk4v0gUdb6nQsbEfWuJVjWMPylAY781Ksqrf+hBne8U=;
Message-ID: <77520838-67cb-4755-8b02-2ec8b90c7bfa@xen.org>
Date: Thu, 14 Mar 2024 13:27:27 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] xen/arm: Set correct per-cpu cpu_core_mask
Content-Language: en-GB
To: Henry Wang , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Henry Wang 
References: <20240228015822.56108-1-xin.wang2@amd.com>
From: Julien Grall 
In-Reply-To: <20240228015822.56108-1-xin.wang2@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Henry,

On 28/02/2024 01:58, Henry Wang wrote:
> In the common sysctl command XEN_SYSCTL_physinfo, the value of
> cores_per_socket is calculated based on the cpu_core_mask of CPU0.
> Currently on Arm this is a fixed value 1 (can be checked via xl info),
> which is not correct. This is because during the Arm CPU online
> process at boot time, setup_cpu_sibling_map() only sets the per-cpu
> cpu_core_mask for itself.
> 
> cores_per_socket refers to the number of cores that belong to the same
> socket (NUMA node). Currently Xen on Arm does not support physical
> CPU hotplug and NUMA, also we assume there is no multithread. Therefore
> cores_per_socket means all possible CPUs detected from the device
> tree. Setting the per-cpu cpu_core_mask in setup_cpu_sibling_map()
> accordingly. Drop the in-code comment which seems to be outdated.
> 
> Signed-off-by: Henry Wang 
> Signed-off-by: Henry Wang 
> ---
> v2:
> - Do not do the multithread check.
> ---
>   xen/arch/arm/smpboot.c | 5 ++++-
>   1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
> index a84e706d77..d9ebd55d4a 100644
> --- a/xen/arch/arm/smpboot.c
> +++ b/xen/arch/arm/smpboot.c
> @@ -66,7 +66,6 @@ static bool cpu_is_dead;
>   
>   /* ID of the PCPU we're running on */
>   DEFINE_PER_CPU(unsigned int, cpu_id);
> -/* XXX these seem awfully x86ish... */

:). I guess at the time we didn't realize that MT was supported on Arm. 
It is at least part of the spec, but as Michal pointed out it doesn't 
look like a lot of processors supports it.

>   /* representing HT siblings of each logical CPU */
>   DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_sibling_mask);
>   /* representing HT and core siblings of each logical CPU */
> @@ -89,6 +88,10 @@ static int setup_cpu_sibling_map(int cpu)
>       cpumask_set_cpu(cpu, per_cpu(cpu_sibling_mask, cpu));
>       cpumask_set_cpu(cpu, per_cpu(cpu_core_mask, cpu));
>   
> +    /* Currently we assume there is no multithread. */

I am not very familiar with the scheduling in Xen. Do you know what's 
the consequence of not properly supporting MT? One thing I can think of 
is security (I know there were plenty of security issues with SMT).

Depending on the answer, I would consider to print a warning and maybe 
add it in SUPPORT.MD in a separate patch.

Also, looking at the v1 discussion, it sounds like even cpu_sibling_mask 
would not be correct. So I think it would make sense to move the comment 
on top of setup_cpu_sibling_map.

> +    cpumask_or(per_cpu(cpu_core_mask, cpu),
> +               per_cpu(cpu_core_mask, cpu), &cpu_possible_map);

AFIACT, per_cpu(cpu_core_mask, ...) will now be equal to 
cpu_possible_map. In that case, wouldn't it be better to simply copy the 
cpumask?

This would also allow to drop cpumask_set_cpu(..., cpu_core_mask) above.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 13:28:31 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 13:28:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693224.1081038 (Exim 4.92)
	(envelope-from )
	id 1rkl8J-000134-Mw; Thu, 14 Mar 2024 13:28:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693224.1081038; Thu, 14 Mar 2024 13:28:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkl8J-00012x-JQ; Thu, 14 Mar 2024 13:28:31 +0000
Received: by outflank-mailman (input) for mailman id 693224;
 Thu, 14 Mar 2024 13:28:29 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkl8H-00012g-PV
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 13:28:29 +0000
Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com
 [2a00:1450:4864:20::42b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id bdd20f53-e206-11ee-a1ee-f123f15fe8a2;
 Thu, 14 Mar 2024 14:28:27 +0100 (CET)
Received: by mail-wr1-x42b.google.com with SMTP id
 ffacd0b85a97d-33e9ba0eadcso769527f8f.2
 for ; Thu, 14 Mar 2024 06:28:27 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: bdd20f53-e206-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1710422907; x=1711027707; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Rxz6zr/A0KmtPpM6C1crLjJ3+KNq8mczIP+nYFliWBI=;
        b=Y30Tyvh7YFa57vDEe0WczIfYQvI/jIMxiB7/GiuhEpXgAJJaKQ0LVqFaI9uy8sPgmP
         iDvBkP8vh9qelfxr/zrSvtosUczAhn2qzE55euz3AcOMprJGPjwwEZE1trSOjY4oeR8Z
         PZRS+PtLP17n1KN89F0jjRZKpJuOc1Esez3/MbVxSXWvQIz19kTqahixEdTW/g4uKDgz
         RPxM1sic6ViWXlLUI9ZV0u58gqFpr7KKvmhhFablVJFb5ax6H8hz6TZNFnmFs+cD+p9+
         DzDooqlyaz3xaJxMuDg5paWKUnRmRhxvKuUNsoSEkp58vvsT3GKfMP3IKggvfNdYRFoN
         C1vQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710422907; x=1711027707;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=Rxz6zr/A0KmtPpM6C1crLjJ3+KNq8mczIP+nYFliWBI=;
        b=xGGRJkaArTUkxPfG9Elyy4o7jLiac6SIWpBK1NvFnmsgKp6asi6K19F+Jo/DfxDCot
         9Ujo1uNzWD/+ZtXNVwbpkHuii95rEQlLvWHJ77xx1MwrnvkPRQBfDhtf8mfgcxJqwlwF
         BryXBOoiC273C92P3f1S951SOGSiTI6GrIvm4nZt4kffQ/XB+P8U+TS0fdHz85r11aK9
         WMFmWFtc8NGRYLcf8vgaxt3P3T7xjTe+KG+U6spF5YkB0fX/Ya8jneHaA7tdQnTelA4T
         aNIZqj10CKbzWzsehrSvKXkscJrkNnJycJN7h5ag3AokgiI1U3wD48pfi0LAhp/G2iHL
         0nRw==
X-Gm-Message-State: AOJu0YzDRDuzFi5ufwMOoW5QeNUfDRjhpTny/bmiRR2gOQkUJkZc+Y9X
	6LfO7c+ngrwZqgiHLFgMecSHo02DLi1HeFbElOpLu2ARm7fqafLha3v4mXrslObbY2dObPoM/nx
	CTHgzdxVIlv/aTBFqVyu1pdUeqPM=
X-Google-Smtp-Source: AGHT+IHS6Tga3i38yK7PAZXOPp0aJeW4RgTQuu45hEIVwS7IzD64dnQb9Nu3Bg8U4DHSg947etd+nz8y34WRN+qXF8k=
X-Received: by 2002:adf:f6c1:0:b0:33d:5f98:82e3 with SMTP id
 y1-20020adff6c1000000b0033d5f9882e3mr1182135wrp.13.1710422907128; Thu, 14 Mar
 2024 06:28:27 -0700 (PDT)
MIME-Version: 1.0
References: <20240306051548.90954-1-flyingpeng@tencent.com> 
In-Reply-To: 
From: Hao Peng 
Date: Thu, 14 Mar 2024 21:28:15 +0800
Message-ID: 
Subject: Re: [PATCH] xen/blkback: use kmap_local_page()
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: xen-devel@lists.xenproject.org, Peng Hao 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Mar 6, 2024 at 4:41=E2=80=AFPM Roger Pau Monn=C3=A9  wrote:
>
> On Wed, Mar 06, 2024 at 01:15:48PM +0800, flyingpenghao@gmail.com wrote:
> > From: Peng Hao 
> >
> > From: Peng Hao 
> >
> > Use kmap_local_page() instead of kmap_atomic() which has been
> > deprecated.
> >
> > Signed-off-by: Peng Hao 
> > ---
> >  drivers/block/xen-blkback/blkback.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-bl=
kback/blkback.c
> > index 4defd7f387c7..cce534f43292 100644
> > --- a/drivers/block/xen-blkback/blkback.c
> > +++ b/drivers/block/xen-blkback/blkback.c
> > @@ -937,8 +937,8 @@ static int xen_blkbk_parse_indirect(struct blkif_re=
quest *req,
> >               if ((n % SEGS_PER_INDIRECT_FRAME) =3D=3D 0) {
> >                       /* Map indirect segments */
> >                       if (segments)
> > -                             kunmap_atomic(segments);
> > -                     segments =3D kmap_atomic(pages[n/SEGS_PER_INDIREC=
T_FRAME]->page);
> > +                             kunmap_local(segments);
> > +                     segments =3D kmap_local_page(pages[n/SEGS_PER_IND=
IRECT_FRAME]->page);
>
> Don't you need to also switch to kunmap_local() then instead of
> kunmap_atomic()?
 kmap_local() and  kunmap_local() are paired.
 I found that I missed a modification, I will re-issue patch v2
 Thanks.
>
> Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 13:28:58 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 13:28:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693225.1081049 (Exim 4.92)
	(envelope-from )
	id 1rkl8i-0001Zl-V5; Thu, 14 Mar 2024 13:28:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693225.1081049; Thu, 14 Mar 2024 13:28:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkl8i-0001Ze-Qk; Thu, 14 Mar 2024 13:28:56 +0000
Received: by outflank-mailman (input) for mailman id 693225;
 Thu, 14 Mar 2024 13:28:55 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkl8h-00012g-Bm
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 13:28:55 +0000
Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com
 [2607:f8b0:4864:20::42d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ccd9c761-e206-11ee-a1ee-f123f15fe8a2;
 Thu, 14 Mar 2024 14:28:53 +0100 (CET)
Received: by mail-pf1-x42d.google.com with SMTP id
 d2e1a72fcca58-6e6eb891db9so428467b3a.3
 for ; Thu, 14 Mar 2024 06:28:53 -0700 (PDT)
Received: from FLYINGPENG-MB1.tencent.com ([103.7.29.30])
 by smtp.gmail.com with ESMTPSA id
 ff13-20020a056a002f4d00b006e6c4b8a5bdsm1480882pfb.96.2024.03.14.06.28.50
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Thu, 14 Mar 2024 06:28:51 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ccd9c761-e206-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1710422932; x=1711027732; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:from:to:cc:subject:date:message-id:reply-to;
        bh=yXgAyG/c2dF1nEwW+SvC94ycXPYiD8dQ1lT7fqQcXNE=;
        b=gALMkjfMdPs+ZUGwNaoFF39DbADumbdf5dCJiXsHHTLF8fl+MHUE4QGkFv/Y3WbPQ2
         yETeIaQZ7f+ZRj5mDpbGbsRkpo8uwezCZ8ovCqr7folNKf0vW7rTgTq6z3lFan7Kf/sy
         WmlITtJ+ST1F9kW2klwJX7Nv4XB9rmGjmy/gYKiIBf6sMq6FzrMfUtEp2BpfgRrqBl/7
         CCRzb/7IMkrPs1qnqGf+raSW53RG+CKDjBMkQ/v160IXobIw7PuKM6PF44Ia82nDCfCD
         e0V7hxuRnmdmmYj2uZ0KdpKFmT3jxajXdNT5qXLb2FYVRjMQ9NKM9H5aR0AFpOsuqhO1
         sYug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710422932; x=1711027732;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=yXgAyG/c2dF1nEwW+SvC94ycXPYiD8dQ1lT7fqQcXNE=;
        b=IMBSioQ+pj5tar2j3Jr7gvukcWs8iwEM7OHG08cvR6TkA8anEu8V+xk/bhZ1kFFEJi
         H8wJKpI9fd1vq1mNim16IdqU1AkIM5n5uvDOAXhnQgCinf6zd2kGF6KpxrjcCeHucjtN
         2kDqREwYMrgfa29AU8JJ8vY6MRaGCwbwaV+vgM+8IhgakwyvAhsEgNIFhNXjyfeSlkLP
         f78Ux2Om7GlMQMoiVBayPoQM+b5H9FnzAqY7daQ/xvXaRJz4xXhR3OE11zbCSymTROl1
         LaqSjEyG15fwdGTfiShEZwKd9yQ9DzPbrfN+wfx2daJNlGbsVu9Wpnk1oUpWuMefq9CC
         L/FQ==
X-Gm-Message-State: AOJu0Yx0t+UUzFo5CcAgmchrCPJQOVB8OqvRLPbBlk0cq8UNm21rv2u2
	9b9qEj7QfDb/cC/BfbP8AnX7lIw7uv518IKv22OMa4ZJLs2EQmZt
X-Google-Smtp-Source: AGHT+IHr12UprP31HY2RN33rSwNjYFuYH5Y6I5fH+HcdqptwWyyY5drbZqk1rODFPsGlW9w92GBtYA==
X-Received: by 2002:a05:6a20:3407:b0:1a1:47c6:a495 with SMTP id i7-20020a056a20340700b001a147c6a495mr1620985pzd.43.1710422932105;
        Thu, 14 Mar 2024 06:28:52 -0700 (PDT)
From: flyingpenghao@gmail.com
X-Google-Original-From: flyingpeng@tencent.com
To: roger.pau@citrix.com
Cc: xen-devel@lists.xenproject.org,
	Peng Hao 
Subject: [PATCH v2] xen/blkback: use kmap_local_page()
Date: Thu, 14 Mar 2024 21:28:43 +0800
Message-Id: <20240314132843.24069-1-flyingpeng@tencent.com>
X-Mailer: git-send-email 2.39.3 (Apple Git-145)
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Peng Hao 

Use kmap_local_page() instead of kmap_atomic() which has been
deprecated.

Signed-off-by: Peng Hao 
---
 drivers/block/xen-blkback/blkback.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
index 4defd7f387c7..09503e269842 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -937,8 +937,8 @@ static int xen_blkbk_parse_indirect(struct blkif_request *req,
 		if ((n % SEGS_PER_INDIRECT_FRAME) == 0) {
 			/* Map indirect segments */
 			if (segments)
-				kunmap_atomic(segments);
-			segments = kmap_atomic(pages[n/SEGS_PER_INDIRECT_FRAME]->page);
+				kunmap_local(segments);
+			segments = kmap_local_page(pages[n/SEGS_PER_INDIRECT_FRAME]->page);
 		}
 		i = n % SEGS_PER_INDIRECT_FRAME;
 
@@ -958,7 +958,7 @@ static int xen_blkbk_parse_indirect(struct blkif_request *req,
 
 unmap:
 	if (segments)
-		kunmap_atomic(segments);
+		kunmap_local(segments);
 	xen_blkbk_unmap(ring, pages, indirect_grefs);
 	return rc;
 }
-- 
2.31.1



From xen-devel-bounces@lists.xenproject.org Thu Mar 14 13:31:10 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 13:31:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693228.1081058 (Exim 4.92)
	(envelope-from )
	id 1rklAq-0003X2-8V; Thu, 14 Mar 2024 13:31:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693228.1081058; Thu, 14 Mar 2024 13:31:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rklAq-0003Wv-5s; Thu, 14 Mar 2024 13:31:08 +0000
Received: by outflank-mailman (input) for mailman id 693228;
 Thu, 14 Mar 2024 13:31:06 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rklAo-0003Wn-Bd
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 13:31:06 +0000
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com
 [2a00:1450:4864:20::62b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1ad7cc16-e207-11ee-afdd-a90da7624cb6;
 Thu, 14 Mar 2024 14:31:03 +0100 (CET)
Received: by mail-ej1-x62b.google.com with SMTP id
 a640c23a62f3a-a4644bde1d4so124861266b.3
 for ; Thu, 14 Mar 2024 06:31:03 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 h21-20020a17090619d500b00a46447348e8sm713003ejd.191.2024.03.14.06.31.02
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 14 Mar 2024 06:31:02 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1ad7cc16-e207-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710423063; x=1711027863; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=rbv8X/itk9iBg29io8nrJACg0Q3U8I3Ljwurfv0ChPI=;
        b=YTeYmhwrvs0/KVOHFluD/317+Wge2hgu5R4I972mZAzAdhuttl2sbxoO/7PRKk9KSh
         0AVE17tJ5lVgIlgQR/KBW8dfghAg1BFvzuqkzvTQFgNNx4wTMKyC1LRjyN+F+DueDetT
         v2C4ZCjpp+1RcawRd1TAJtSPHzaaai3FrJpXS3Tgc53CVf0ZpPrkMIfYKiPZwTEBirEb
         UJmj21/MGuhdv9fZVtST5GzdgmCR7tZN427Xskd1pfSQH/pMV2hvpqrMF5L/wj3ySRNr
         YMLonNL/+xEIp27uUDe1cAbrXGPK2koMLi48ZqXLwgsJxEAQ4w1IRlVfeeOlB9O7Xz/W
         knWw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710423063; x=1711027863;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=rbv8X/itk9iBg29io8nrJACg0Q3U8I3Ljwurfv0ChPI=;
        b=r6AQoxWPAGRxvNxuG75XkrabTRL/Wwuhm0TfPecHS3znE5b7w0OayP3w9XM5m5Kjlt
         6MgG0FyVZQkVESi2VdWLuHbb8YxtbNbCJKERCDKeVlYdrPnNIKbvKNY2lteMZAk8sPAn
         2mOzyZufMmUPv6NHOa4BmIHzXPFEuF/pexlHRdn1rwi9j7FYQVC7Vw4/6tFpe3P8vF2K
         GBMi3+8AVT3AT8s8qxFIULFA22T3r4W5YuTXRsBjjpREd777UAhW5UEs+IivWNuKVotB
         DeaZff+UKPj/cWO6CfFLkQeH8B2AeqFgZQToITZCWYZ0D3X3V7yVWJO/I5aPM7tWxryv
         /NVg==
X-Forwarded-Encrypted: i=1; AJvYcCX3Z6C95tQ2VRSKFlhzevKra0sHF/KApJaX7RX/QN8m+xw7Mh+7PlL619im0alt8vWcoQ+qyBbHHkdcn+EZp62flwua9GcP6+LKlJSGOco=
X-Gm-Message-State: AOJu0YyQ6Us86Kzu6n8XNuAxA++64WG0xJpiSGJw4KOT5WPhKpJmUpn/
	tElyVPbp3+1D9dwJo330MSIdEVcEgiBR69UKXB3EMXiEYIFaomaJ32zCgbBlg+t0UPPPWkoTt/A
	=
X-Google-Smtp-Source: AGHT+IFChXVIOBetCKYvxYHiQFI/lc6ZU9XRA2+Bj53Tbj5K4HU0mIm7dRqmh7LegnTdKU78SxyrVA==
X-Received: by 2002:a17:906:ba8a:b0:a46:75ce:289 with SMTP id cu10-20020a170906ba8a00b00a4675ce0289mr1218010ejd.55.1710423063421;
        Thu, 14 Mar 2024 06:31:03 -0700 (PDT)
Message-ID: <12fe48a6-6957-49d7-adf5-1a3ac8b1bfaa@suse.com>
Date: Thu, 14 Mar 2024 14:31:01 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 3/3] x86/PVH: Support relocatable dom0 kernels
Content-Language: en-US
To: Jason Andryuk 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu
 , George Dunlap ,
 Julien Grall , Stefano Stabellini ,
 xen-devel@lists.xenproject.org
References: <20240313193021.241764-1-jason.andryuk@amd.com>
 <20240313193021.241764-4-jason.andryuk@amd.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240313193021.241764-4-jason.andryuk@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 13.03.2024 20:30, Jason Andryuk wrote:
> --- a/xen/arch/x86/hvm/dom0_build.c
> +++ b/xen/arch/x86/hvm/dom0_build.c
> @@ -537,6 +537,108 @@ static paddr_t __init find_memory(
>      return INVALID_PADDR;
>  }
>  
> +static bool __init check_load_address(
> +    const struct domain *d, const struct elf_binary *elf)
> +{
> +    paddr_t kernel_start = (paddr_t)elf->dest_base & PAGE_MASK;
> +    paddr_t kernel_end = PAGE_ALIGN((paddr_t)elf->dest_base + elf->dest_size);

Both casts act on a pointer value. Such cannot legitimately be converted
to paddr_t; it only so happens that paddr_t is effectively the same as
uintptr_t right now. (Same issue again further down.) That said, I notice
we have pre-existing examples of this ...

> +/* Check the kernel load address, and adjust if necessary and possible. */
> +static bool __init check_and_adjust_load_address(
> +    const struct domain *d, struct elf_binary *elf, struct elf_dom_parms *parms)
> +{
> +    paddr_t reloc_base;
> +
> +    if ( check_load_address(d, elf) )
> +        return true;
> +
> +    if ( parms->phys_align == UNSET_ADDR )
> +    {
> +        printk("Address conflict and %pd kernel is not relocatable\n", d);
> +        return false;
> +    }
> +
> +    reloc_base = find_kernel_memory(d, elf, parms);
> +    if ( reloc_base == 0 )
> +    {
> +        printk("Failed find a load address for the kernel\n");
> +        return false;
> +    }
> +
> +    if ( opt_dom0_verbose )
> +        printk("Relocating kernel from [%lx, %lx] -> [%lx, %lx]\n",
> +               (paddr_t)elf->dest_base,
> +               (paddr_t)elf->dest_base + elf->dest_size,

By using %p you clearly can avoid the casts here.

> +               reloc_base, reloc_base + elf->dest_size);

I'm not convinced %lx is really appropriate for paddr_t.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 13:33:53 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 13:33:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693231.1081069 (Exim 4.92)
	(envelope-from )
	id 1rklDQ-00046I-Ne; Thu, 14 Mar 2024 13:33:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693231.1081069; Thu, 14 Mar 2024 13:33:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rklDQ-00046B-J5; Thu, 14 Mar 2024 13:33:48 +0000
Received: by outflank-mailman (input) for mailman id 693231;
 Thu, 14 Mar 2024 13:33:47 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rklDP-000464-EW
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 13:33:47 +0000
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com
 [2a00:1450:4864:20::630])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7afa911e-e207-11ee-a1ee-f123f15fe8a2;
 Thu, 14 Mar 2024 14:33:45 +0100 (CET)
Received: by mail-ej1-x630.google.com with SMTP id
 a640c23a62f3a-a466c85ae5fso120689866b.0
 for ; Thu, 14 Mar 2024 06:33:45 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 e27-20020a170906375b00b00a45bda3cbb8sm714344ejc.134.2024.03.14.06.33.44
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 14 Mar 2024 06:33:44 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7afa911e-e207-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710423225; x=1711028025; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=DV2fqh8fbe5eNL0l+uJ/zUcvgZUuCCoTF0s8xwQ1OVY=;
        b=VWwc4hHoHUxPRPEcmj2QqhM/itwrJLlr17u9+j0+NL8ksMSEVUFAWfQGQX8J/jEpUH
         pyc5j8CiMADwNe1LICsEtpUNkQKwjMdGDi5HlVUPs4baH989WMVtr8Y6VGS0ZYgz6AQI
         aM6ae+NBrPRMvnP9FLIwOSNYHxpyo9SCDBv6xTA/zYjETYQsyKbZGn9nADv+KifkZ00l
         6KGUqbLESycsiGU0QCbkCvOHm1LdJGsvkeDreNBHwYs93lD9ThYoFEhU6zKHgpMo4/Ze
         QVZ5HO0ZP8jBfGsIpV4SEYTGmA+vE0ky/PDmcwaiiC0v9/atOGYhKoJi+ow/AvnJIxtA
         z0JQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710423225; x=1711028025;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=DV2fqh8fbe5eNL0l+uJ/zUcvgZUuCCoTF0s8xwQ1OVY=;
        b=vQgJ3sF2khulHPzRlIppo/b5yUD6cTEMXmDXKBoiurVNj4KkMxWG+x7CgvhkPvGbCO
         vpmbnmAWVRYdvBhHXRwFKMdWLkOM+FfUj5cvfg8PoAKHcq24UHb7ut9SD3D/Zwt1MNeb
         nXXUMzPTtV2ficu2DTKtMIdmnYBBEV5YUWL+Zw/BDYJrhCgj5gefo28ed9wCBSwK+o5o
         q4Uyrmu6BFVMAEFlVlQw2uoHBkjTszA3WzwvChHA2MvWlRaKIb4WZGRmJFpNDL0hSXjC
         a7rkFwYznXtQInAe9sACOVtfHFiFZ4BnNW6yffWNtUIOeAVsWMRBlpDygQUwC0ztWjTe
         VqOw==
X-Forwarded-Encrypted: i=1; AJvYcCXI5iRBUyGNSLfzHv8wbiyO51H3JrbEgfI+pKZfIG37K+n+bgjzel/WsLRuDq+b5EL/tqkbrLoyPxnH/NUPbnapdaUYLW09RLhn711uPEs=
X-Gm-Message-State: AOJu0Yx5+UI3QdTsG/pJSziKEbfrbdFeK9Z5A3cVqiYu0/c/1+IKiFmP
	dCdVwMUr6TK74elF2D0fJWHqzaAfEH4fDeXkZHxng6FpujPCA+3sIJD7sro+gg==
X-Google-Smtp-Source: AGHT+IHUmmMCC5Klqzndny8WXRumeBWz+dDrgskqFiTO4npK0S/3in0HysDamns5cEeBPmLMd1WpHw==
X-Received: by 2002:a17:906:298b:b0:a46:1861:ffdb with SMTP id x11-20020a170906298b00b00a461861ffdbmr1151279eje.35.1710423224767;
        Thu, 14 Mar 2024 06:33:44 -0700 (PDT)
Message-ID: <1ea3d5f9-d639-486f-af03-95c75597e7ae@suse.com>
Date: Thu, 14 Mar 2024 14:33:43 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/3] Revert "xen/x86: bzImage parse kernel_alignment"
Content-Language: en-US
To: Jason Andryuk 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org, Wei Liu 
References: <20240313193021.241764-1-jason.andryuk@amd.com>
 <20240313193021.241764-2-jason.andryuk@amd.com>
 <82ae53ac-f2d1-4d86-8719-4e5cc2e5f57d@suse.com>
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 14.03.2024 14:01, Jason Andryuk wrote:
> On 2024-03-14 03:11, Jan Beulich wrote:
>> On 13.03.2024 20:30, Jason Andryuk wrote:
>>> A new ELF note will specify the alignment for a relocatable PVH kernel.
>>> ELF notes are suitable for vmlinux and other ELF files, so this
>>> Linux-specific bzImage parsing in unnecessary.
>>
>> Hmm, shouldn't the order of attempts to figure the alignment be ELF note,
>> ELF header, and then 2Mb?
> 
> This patch series makes Xen only relocate when the ELF Note is present. 
> Linux PVH entry points today are not relocatable, so that needs to be 
> specified some way.  This new note also includes the alignment, so there 
> is no need to try other means of obtaining the alignment.

Going yet beyond what I said in reply to the patch: The mere presence of
the note, with no data at all, could be sufficient to indicate the
kernel is relocatable, when no other restrictions (min, max, align) apply.

> Also, the ELF header values didn't change with CONFIG_PHYSICAL_ALIGN, so 
> that didn't seem reliable.

Well, that's an observation for Linux. But the interface here ought to be
OS-agnostic.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 13:37:45 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 13:37:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693236.1081078 (Exim 4.92)
	(envelope-from )
	id 1rklHC-0004eS-4n; Thu, 14 Mar 2024 13:37:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693236.1081078; Thu, 14 Mar 2024 13:37:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rklHC-0004eL-1s; Thu, 14 Mar 2024 13:37:42 +0000
Received: by outflank-mailman (input) for mailman id 693236;
 Thu, 14 Mar 2024 13:37:40 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rklHA-0004eE-S7
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 13:37:40 +0000
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com
 [2a00:1450:4864:20::531])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0640739a-e208-11ee-a1ee-f123f15fe8a2;
 Thu, 14 Mar 2024 14:37:38 +0100 (CET)
Received: by mail-ed1-x531.google.com with SMTP id
 4fb4d7f45d1cf-56845954ffeso1275821a12.2
 for ; Thu, 14 Mar 2024 06:37:38 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 z20-20020aa7c654000000b005686184eb77sm723829edr.78.2024.03.14.06.37.37
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 14 Mar 2024 06:37:38 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0640739a-e208-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710423458; x=1711028258; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=LRPBSc9tVTtYpmQX2XYGrzNR5RaaO3zD+OQAAHDOvQw=;
        b=Jiz4EIFaUNgITvuupbi/4FO0p+HiBXnqWUSTZbJYCkRZRZQ1CSy4kbZBtw97nVX5Ou
         PgxEjfwdrx8Ksf0k3BaAaVljkMo5j1pdIwoKKqKBWErsUflQhOsJYg09/f3IoNgniuG/
         1GxHC8TeHX8IVMnp4g/IpE+7omPKOlx3CHxh/2jgBubo0UvelQ25/9XsHQtqatrWEXsh
         ClJzL4Qubi7hXwZYSOYy099nhZ02iu3U03eBz3XMQJMXAXJJuv/zmBd1fmzlJS38SmIG
         vQl37z9PAYLbPY5nFhy513lP8YBN10syLhkqYgayrxAeIezf6nxIfTtBviWOgMYJuN23
         BhIQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710423458; x=1711028258;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=LRPBSc9tVTtYpmQX2XYGrzNR5RaaO3zD+OQAAHDOvQw=;
        b=hBUSvulZ5RdEBXAXWuxJCSH8M0rymnU2+FgUNRPS97b7Ujoozn2VAJpYIpypld5e67
         X2HSqys0eq75Fjp/QPgMO56NYo+wWSzw8YwLTH8qZW8Saqpj3KH3IMKe2feLcHlfbjxE
         qSyU6JnWcdOV3/xcN6SYKf6n1ze+NuFDwGlH5S/ZMBEPLMy+LyTkSici8EMlWDwGC6kP
         KMkobFRoMwGPv80OiIur/CqoEN27yrliFx7+Q1PkjVNzrdtE9+TCut0Kz907sz0NsBX5
         rUnvDb3AgDQ/HzYpaJmv+l90DDoKNKDFn+29O6Imny6q4PpagPMWvbugniSH9XC8/WKP
         uhTw==
X-Gm-Message-State: AOJu0YxKTzrRCNzXgt9R6nkBxMNn+pxkWDVwLqprLhADhInTzPCR8nEM
	R5PXECj352leNBqetmHhYwBCRtEBsuKEaYk8Z/PeQsYvZB14Yx8gqlkFH5lKwQ==
X-Google-Smtp-Source: AGHT+IHj9RaEr/1IeBfRbWxPvhwnXm2Z4pLX6zJ4vTzphYNCb6jWQln9LpIlJvEyMmHgrJftx+i91g==
X-Received: by 2002:a05:6402:4586:b0:568:2505:93ad with SMTP id ig6-20020a056402458600b00568250593admr1218061edb.5.1710423458382;
        Thu, 14 Mar 2024 06:37:38 -0700 (PDT)
Message-ID: 
Date: Thu, 14 Mar 2024 14:37:37 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/7] multiboot2: Add load type header and support for the
 PE binary type
Content-Language: en-US
To: Ross Lagerwall 
Cc: xen-devel@lists.xenproject.org, Andrew Cooper
 , Daniel Kiper ,
 grub-devel@gnu.org
References: <20240313150748.791236-1-ross.lagerwall@citrix.com>
 <20240313150748.791236-2-ross.lagerwall@citrix.com>
 
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 14.03.2024 10:30, Ross Lagerwall wrote:
> On Thu, Mar 14, 2024 at 7:24 AM Jan Beulich  wrote:
>>
>> On 13.03.2024 16:07, Ross Lagerwall wrote:
>>> In addition to the existing address and ELF load types, specify a new
>>> optional PE binary load type. This new type is a useful addition since
>>> PE binaries can be signed and verified (i.e. used with Secure Boot).
>>
>> And the consideration to have ELF signable (by whatever extension to
>> the ELF spec) went nowhere?
>>
> 
> I'm not sure if you're referring to some ongoing work to create signable
> ELFs that I'm not aware of.

Something must have been invented already to make Linux modules signable.

> I didn't choose that route because:
> 
> * Signed PE binaries are the current standard for Secure Boot.
> 
> * Having signed ELF binaries would mean that code to handle them needs
> to be added to Shim which contravenes its goals of being small and
> simple to verify.

Both true, but neither goes entirely without saying, I suppose.

> * I could be wrong on this but to my knowledge, the ELF format is not
> being actively updated nor is the standard owned/maintained by a
> specific group which makes updating it difficult.

And PE/COFF isn't under control of a public entity / group afaik, which
may be viewed as no better, if not worse.

> * Tools would need to be updated/developed to add support for signing
> ELF binaries and inspecting the signatures.

As above, yes indeed.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 13:45:33 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 13:45:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693243.1081087 (Exim 4.92)
	(envelope-from )
	id 1rklOi-00072G-2q; Thu, 14 Mar 2024 13:45:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693243.1081087; Thu, 14 Mar 2024 13:45:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rklOi-000729-0H; Thu, 14 Mar 2024 13:45:28 +0000
Received: by outflank-mailman (input) for mailman id 693243;
 Thu, 14 Mar 2024 13:45:27 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rklOh-000723-0d
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 13:45:27 +0000
Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com
 [2607:f8b0:4864:20::32e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1b93340d-e209-11ee-a1ee-f123f15fe8a2;
 Thu, 14 Mar 2024 14:45:24 +0100 (CET)
Received: by mail-ot1-x32e.google.com with SMTP id
 46e09a7af769-6dc8b280155so591720a34.0
 for ; Thu, 14 Mar 2024 06:45:24 -0700 (PDT)
Received: from [10.80.67.149] (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 z1-20020ae9e601000000b00788287e3430sm816917qkf.130.2024.03.14.06.45.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 14 Mar 2024 06:45:21 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1b93340d-e209-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710423922; x=1711028722; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:references:cc:to
         :from:content-language:subject:user-agent:mime-version:date
         :message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Vk3eG1yUy1iHjDkf06H64Bx/Lk42Yi6SJ26azqHUXFI=;
        b=m/x8+VdSozmTqwvDWx/qhAk5lIT3A6y6f/k6JxGS9QbPObCIoKcGoxPVNhY3xbtBvJ
         T1pyYLN7JIAjtFU9Q3zrWSzVXMuYF1BnWKrIjbRAXIxrrvegE9ewPwSkGD29czY5UG9A
         nO1KD8BKMC29LCdstF/VsFr0C8/nhMjM8prF8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710423922; x=1711028722;
        h=content-transfer-encoding:in-reply-to:autocrypt:references:cc:to
         :from:content-language:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=Vk3eG1yUy1iHjDkf06H64Bx/Lk42Yi6SJ26azqHUXFI=;
        b=fzhycw0Cc3CBnUrLsOKJdNsvDf+dyVFZdCNBLBtJOxCn68O/PfjeO8L2pB1Le4cmHn
         WyG/LhoVZg86cIQU4OmJnbVK7yC2ynL2hSl+yDkpVqDzhf01g0omMIJt5JyTUCqwGAbe
         /BTaangw1eAnLz8zM1r3ykYu5kPw4BLs2iHoOFyavLfcN9aaIsfKsE1PkMQK0TYIdZqW
         EkTYNME7GF/SQDwCELYCIIa4lHN/RJE86KxuH/UuJ0AeezhFq8rvWrJA8kc4nZHSyFhM
         dUbX2ao7wlr4PIVToXzUMrRABuzzM16X+UM84x3rDZp5Gtra3qJhtZEvH+A2Q+02rjSU
         jVVw==
X-Gm-Message-State: AOJu0YwfpzHwEizAJjun2OhDuSBJXrO1DiK7Ho2tKv4zxNxKAm6yDGMk
	9bE7/OUpdXdcrQcorM2AsWgYCkEDdFjnh558GZgTAFVzHhu3jvxqDyNMDlTXMYW7QG6szCOWhBH
	g
X-Google-Smtp-Source: AGHT+IHvoa7GbzYO5c8ma97/GQ4gmIoiUeQU0YvqcqlSZPsC0vg8hUORpj+rSf+qGTna0n4jKwPt0w==
X-Received: by 2002:a05:6830:2644:b0:6e5:210c:5e53 with SMTP id f4-20020a056830264400b006e5210c5e53mr801150otu.33.1710423922196;
        Thu, 14 Mar 2024 06:45:22 -0700 (PDT)
Message-ID: <21b3f342-3a51-46df-9a18-2b6015bb125b@citrix.com>
Date: Thu, 14 Mar 2024 13:45:18 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 3/7] xen/bitops: Implement ffsl() in common logic
Content-Language: en-GB
From: Andrew Cooper 
To: Xen-devel 
Cc: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Wei Liu ,
 Stefano Stabellini , Julien Grall ,
 Volodymyr Babchuk ,
 Bertrand Marquis ,
 Michal Orzel ,
 Oleksii Kurochko ,
 Shawn Anastasio ,
 "consulting @ bugseng . com" ,
 Simone Ballarin ,
 Federico Serafini ,
 Nicola Vetrini 
References: <20240313172716.2325427-1-andrew.cooper3@citrix.com>
 <20240313172716.2325427-4-andrew.cooper3@citrix.com>
 <04b7bed5-ef60-4d21-90f2-2eea05397fb3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <04b7bed5-ef60-4d21-90f2-2eea05397fb3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 13/03/2024 5:48 pm, Andrew Cooper wrote:
> On 13/03/2024 5:27 pm, Andrew Cooper wrote:
>>  xen/arch/arm/include/asm/bitops.h |  2 +-
>>  xen/arch/ppc/include/asm/bitops.h |  1 -
>>  xen/arch/x86/include/asm/bitops.h | 30 +++++++++++++-----------------
>>  xen/common/bitops.c               |  7 +++++++
>>  xen/include/xen/bitops.h          | 12 ++++++++++++
>>  5 files changed, 33 insertions(+), 19 deletions(-)
>>
>> diff --git a/xen/arch/arm/include/asm/bitops.h b/xen/arch/arm/include/asm/bitops.h
>> index 09c6064274a7..59ae8ed150b6 100644
>> --- a/xen/arch/arm/include/asm/bitops.h
>> +++ b/xen/arch/arm/include/asm/bitops.h
>> @@ -158,7 +158,7 @@ static inline int fls(unsigned int x)
>>  
>>  
>>  #define arch_ffs(x) ({ unsigned int __t = (x); fls(ISOLATE_LSB(__t)); })
>> -#define ffsl(x) ({ unsigned long __t = (x); flsl(ISOLATE_LSB(__t)); })
>> +#define arch_ffsl(x) ({ unsigned long __t = (x); flsl(ISOLATE_LSB(__t)); })
>>  
>>  /**
>>   * find_first_set_bit - find the first set bit in @word
> It turns out this change isn't bisectable on ARM, but it is by the end
> of the series.
>
> Reordering patches 6+7 to be ahead of this one resolves the bisection
> problem.

... but introduces a bisection issue on x86.

I'm going to have to split the series up a bit more to do nicely.

~Andrew

>
> ~Andrew



From xen-devel-bounces@lists.xenproject.org Thu Mar 14 13:50:09 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 13:50:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693249.1081097 (Exim 4.92)
	(envelope-from )
	id 1rklTD-00009p-L5; Thu, 14 Mar 2024 13:50:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693249.1081097; Thu, 14 Mar 2024 13:50:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rklTD-00009g-Ic; Thu, 14 Mar 2024 13:50:07 +0000
Received: by outflank-mailman (input) for mailman id 693249;
 Thu, 14 Mar 2024 13:50:05 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rklTB-0008R1-H9
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 13:50:05 +0000
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com
 [2a00:1450:4864:20::532])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c2989781-e209-11ee-afdd-a90da7624cb6;
 Thu, 14 Mar 2024 14:50:04 +0100 (CET)
Received: by mail-ed1-x532.google.com with SMTP id
 4fb4d7f45d1cf-5683247fd0fso1415271a12.3
 for ; Thu, 14 Mar 2024 06:50:04 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 fe4-20020a056402390400b00567e27c72c4sm724838edb.62.2024.03.14.06.50.02
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 14 Mar 2024 06:50:02 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c2989781-e209-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710424204; x=1711029004; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=jyMhEAcE+ONrg9SbjkT2CneQMZ+uB2RNa9WH9aBaYxg=;
        b=O+DTg6aP1C8ylTngN/zZHoH6wueaD9gZDOCEQ+JIk7/04U4P0lEGMkrWOA2Y3y0w8S
         smG8ljqL1eWv+lXwDWi0qNZMexywc+sTiSuv23eCeSOEnuTkmbhQZN6RouvQ855EJin/
         oWuYkfC51ppCPVZLL2NRKyvS3TuL3shCTayk4KAvZ68eOE9/ZGoJVBOLDkWL8n1UVR4L
         eR9Uh13vfNKRpf3b4Z0Aqoltbtw8PpUFly5DF7bsMpUFuoy9516Z3XuL45CYVpOAJD1+
         vDSkgrAIWYKR3petmuAPPWu81UGYrBkiJ8JJHW4AxOlzvGLes4d9MHEf10X/BP9yj4wh
         cPAQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710424204; x=1711029004;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=jyMhEAcE+ONrg9SbjkT2CneQMZ+uB2RNa9WH9aBaYxg=;
        b=kIgsIdocMYrD/PW7qKatPVjf2B6H4m/U8HuMWTvqgLaTMGOw+e1oUqIxJB3Cp49lhs
         96gpK4Qrc0uhfM51s3rxOx8jITdxICRQUWSyyPgYoj8iq6HL72e9mpQfQ8jFwhrXdykL
         C41QdHh5w9Wx40FWx+U3rmXy+jfrk8XTSZwxmyYzbVRXQ3ys3h0EIer4hRRYMgjFakJ3
         65iNcV1ruwNsuYCwz33hKWHGb00BbjhlQClzHtY9dbfUKloazTNhmGlLNl7QQBTTw408
         lItYErLaWzztmpxCNzBG9uYmPFLhJYz/col/uk2Rde5L1Md5j8f4QQOyG3xATxPkZB2P
         KWAQ==
X-Forwarded-Encrypted: i=1; AJvYcCUTI05OAQmeFCz6TCcH8M5nQxhAP6rlh7seclnu/+NVRmjSozeWhYD17CNP92OxH7zRCNFWVkiVjIjxRF4+jhU6m6RX6luIvAa1sY8q7jw=
X-Gm-Message-State: AOJu0Yyr2dUYeWWj55NcPjkQy43jBlNfGlFSHPd7jdTkR+rqI8bt9JGV
	QpTaDSyzg2jioaB7FNw22Ho5ke9Ypeyye+XBrb33iJ4fjbbBnRgZJPpCi3mZpg==
X-Google-Smtp-Source: AGHT+IHWv+HiTqJ6lVR/STiwd80AwDbiWqmn8BjWNFxebSXvCOkJFrKSL42QuecRwSLuHFykJcDSPA==
X-Received: by 2002:a05:6402:4495:b0:566:777:af4f with SMTP id er21-20020a056402449500b005660777af4fmr560442edb.1.1710424203799;
        Thu, 14 Mar 2024 06:50:03 -0700 (PDT)
Message-ID: <32a4de1e-94fe-4b44-b95c-55cd1ec7e7e4@suse.com>
Date: Thu, 14 Mar 2024 14:50:01 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH] tools: add x2APIC entries in MADT based on APIC ID
Content-Language: en-US
To: Matthew Barnes 
Cc: Wei Liu , Anthony PERARD ,
 Xen-devel 
References: 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 13.03.2024 16:35, Matthew Barnes wrote:
> libacpi is a tool that is used by libxl (for PVH guests) and hvmloader
> (for HVM guests) to construct ACPI tables for guests.
> 
> Currently, libacpi only uses APIC entries to enumerate processors for
> guests in the MADT.
> 
> The APIC ID field in APIC entries is an octet big, which is fine for
> xAPIC IDs, but not so for sufficiently large x2APIC IDs.

Yet where would those come from? I can see that down the road we will
have such, but right now I don't think we do. Without saying so, this
change could be mistaken for a fix of an active bug.

> This patch scans each APIC ID before constructing the MADT, and uses the
> x2APIC entry for each vCPU whose APIC ID exceeds the size limit imposed
> by regular APIC entries.

It is my understanding that if you use any x2APIC entry, every CPU needs
to have one.

> @@ -134,27 +151,45 @@ static struct acpi_20_madt *construct_madt(struct acpi_ctxt *ctxt,
>          io_apic->ioapic_id   = config->ioapic_id;
>          io_apic->ioapic_addr = config->ioapic_base_address;
>  
> -        lapic = (struct acpi_20_madt_lapic *)(io_apic + 1);
> +        apicid_entry = io_apic + 1;
>      }
>      else
> -        lapic = (struct acpi_20_madt_lapic *)(madt + 1);
> +        apicid_entry = madt + 1;
>  
>      info->nr_cpus = hvminfo->nr_vcpus;
> -    info->madt_lapic0_addr = ctxt->mem_ops.v2p(ctxt, lapic);
> +    info->madt_lapic0_addr = ctxt->mem_ops.v2p(ctxt, apicid_entry);
>      for ( i = 0; i < hvminfo->nr_vcpus; i++ )
>      {
> -        memset(lapic, 0, sizeof(*lapic));
> -        lapic->type    = ACPI_PROCESSOR_LOCAL_APIC;
> -        lapic->length  = sizeof(*lapic);
> -        /* Processor ID must match processor-object IDs in the DSDT. */
> -        lapic->acpi_processor_id = i;
> -        lapic->apic_id = config->lapic_id(i);
> -        lapic->flags = (test_bit(i, hvminfo->vcpu_online)
> -                        ? ACPI_LOCAL_APIC_ENABLED : 0);
> -        lapic++;
> +        uint32_t apic_id = config->lapic_id(i);
> +        if ( apic_id < 255 )

Nit (here and below): This file uses hypervisor coding style. and hence a
blank line is wanted between declaration(s) and statement(s).

> +        {
> +            struct acpi_20_madt_lapic *lapic = apicid_entry;
> +            memset(lapic, 0, sizeof(*lapic));
> +            lapic->type    = ACPI_PROCESSOR_LOCAL_APIC;
> +            lapic->length  = sizeof(*lapic);
> +            /* Processor ID must match processor-object IDs in the DSDT. */
> +            lapic->acpi_processor_id = i;
> +            lapic->apic_id = apic_id;
> +            lapic->flags = (test_bit(i, hvminfo->vcpu_online)
> +                            ? ACPI_LOCAL_APIC_ENABLED : 0);
> +            apicid_entry = lapic + 1;
> +        }
> +        else
> +        {
> +            struct acpi_20_madt_x2apic *x2apic = apicid_entry;
> +            memset(x2apic, 0, sizeof(*x2apic));
> +            x2apic->type    = ACPI_PROCESSOR_LOCAL_X2APIC;
> +            x2apic->length  = sizeof(*x2apic);
> +            x2apic->apic_id = apic_id;
> +            x2apic->flags   = (test_bit(i, hvminfo->vcpu_online)
> +                                ? ACPI_LOCAL_APIC_ENABLED : 0);

Nit: Indentation off by 1.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 13:51:41 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 13:51:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693251.1081108 (Exim 4.92)
	(envelope-from )
	id 1rklUf-0000gj-Vx; Thu, 14 Mar 2024 13:51:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693251.1081108; Thu, 14 Mar 2024 13:51:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rklUf-0000gc-Sp; Thu, 14 Mar 2024 13:51:37 +0000
Received: by outflank-mailman (input) for mailman id 693251;
 Thu, 14 Mar 2024 13:51:37 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rklUf-0000gU-3H
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 13:51:37 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on20601.outbound.protection.outlook.com
 [2a01:111:f403:2417::601])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f8899aea-e209-11ee-afdd-a90da7624cb6;
 Thu, 14 Mar 2024 14:51:35 +0100 (CET)
Received: from CH2PR08CA0007.namprd08.prod.outlook.com (2603:10b6:610:5a::17)
 by IA1PR12MB7661.namprd12.prod.outlook.com (2603:10b6:208:426::17)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.26; Thu, 14 Mar
 2024 13:51:23 +0000
Received: from DS2PEPF00003447.namprd04.prod.outlook.com
 (2603:10b6:610:5a:cafe::49) by CH2PR08CA0007.outlook.office365.com
 (2603:10b6:610:5a::17) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7339.38 via Frontend
 Transport; Thu, 14 Mar 2024 13:51:22 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 DS2PEPF00003447.mail.protection.outlook.com (10.167.17.74) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7386.12 via Frontend Transport; Thu, 14 Mar 2024 13:51:22 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 14 Mar
 2024 08:51:22 -0500
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB05.amd.com
 (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 14 Mar
 2024 08:51:21 -0500
Received: from [172.17.162.8] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Thu, 14 Mar 2024 08:51:21 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f8899aea-e209-11ee-afdd-a90da7624cb6
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=hmJXtctNhitLjZLr3jvCoG0iNdt8sGhqnE2UbDasN1zTI5Hb/PhRLJIaC9FampqME6TlT48V7+36DzkfkKtEe9SvD/t0vYYYKByCPfYcNRK1QK7OAB1HIDl/q0yJAS6hjRJYN7wQWLEmp8FSDAcdo/dDPZxKHetpCYlIj79dMWMJkmZuSaZBU+1LNLUCLa0YWQAUJRAhybk9WZxSjmJB1PrWttft/TNTiUTs0w/4740082Qryz79DK7N8Y5Mh+oVXtDyAM2yZiNx+EvIccBUjTnNqNqC+dRP6fISmyXDWDjE4iGKe0nvnBTKMM8qBHOwKqSGiq3Yjvzx7EfXnUMY0g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=eDt/puo9y9p/vv03V5R6XBNRP5HW9wRwW3BZC+S4ujw=;
 b=KfnDN5uWwWuq9Wp0P73QL1mSCd5gfm4UKT/DTGZ4p/O7KMaXzwm4+L65CPc96YkzlxmwCpPdtWrnGol2mAhv/6oo6zTjP2trRsMqdfHPzeXUjC9Jfc6jk/4ee1knAIaz+/hJrdU/0crazdtc88b0nBx8NI6mBVbDb4GD6h1ujl3eFbls0FnUkRl/mqw5CztLmciyBdFAb19vOuFIfx40OlR2Cp8+anTSVPiNROll3vQisrdhetpJ7qsWqwU1FlmThF/EK7pOjb8Grs39/xArbyLTQrGNYTc5//AL9GUqmA2QVdLLKEf51av8jJccmuQC0foTPM8OSypbxTHB5r63Ww==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=citrix.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=eDt/puo9y9p/vv03V5R6XBNRP5HW9wRwW3BZC+S4ujw=;
 b=yZBwZlwlsWHZwaB4qC5tZipTgvYL5GbffAfAuFGpcbAovCB7cOLKVNbUP0upGqFEGaug83xXCztFczFAHxDGNjyKFyEPkYejb5qlOUZGsdgEaMkBwjFv22+LQOqV2v9iez0FGVUYCIN8IOYOrST3E0+Feutjs3vz3cz4RRVdb7c=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Message-ID: 
Date: Thu, 14 Mar 2024 09:51:22 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 3/3] x86/PVH: Support relocatable dom0 kernels
Content-Language: en-US
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
CC: , Jan Beulich , "Andrew
 Cooper" , Wei Liu , George Dunlap
	, Julien Grall , Stefano Stabellini
	
References: <20240313193021.241764-1-jason.andryuk@amd.com>
 <20240313193021.241764-4-jason.andryuk@amd.com> 
From: Jason Andryuk 
In-Reply-To: 
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
Received-SPF: None (SATLEXMB05.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DS2PEPF00003447:EE_|IA1PR12MB7661:EE_
X-MS-Office365-Filtering-Correlation-Id: cb863103-2fff-4735-9cb4-08dc442dd583
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	Sfqrq/NsXJ5QkvLs6JK+wNUvAYEmzmy67KVX117pB8w9i3pCtvnZYE5HkmIYhjGG0ddZx1i/mImYzXmTMQdiZJnaJBD+3FKpVVWKYEFWZ8QU4ak15pTIWD98Ek7zREbQTzDFVKGwkrZ+49mRbmHTtLBPkup1fgJQ6qtGYeSloOs85pJmue9BaeX3l4xl4kU1+/SbSHHBLHPoeQuqeeN0Fb/yn37ML9YDEAWAxoMTCt7NaL+0fsnvZN08tIwDjmOpbxnglrvKoA4aHxBhePLwxdC+SjyZf6YFBHl6i9donvDkhVjIugQ03wPXOHz9JHrEJulVO4Jh4c0/zujaIAzosMtdboTxZtBNlw+GCO0/yK0YYstTIb9BJknwp6zgZuQneQamVyhtV1NDZesroGmOHhEN6TSf61crQU0uMAhI5xLijIZJon7X86W1KJ/6AGISQjemtgTeTE8VtvizQIJa5xy47Gk5DO46RXqcMOh89VI09MOLHdnLZ8tphnPFRhBkTrMDpaTjpmH1cuu9nwCJvIN2weKTr77GKdzk3RCu44vIibwxCjRV81Nlu/D6//ikPZlq/AjXUr9LEyBWm9JMSAmX8SC/GpDpTnyXgXmR959GkZ//FXlTDArh9lJTqPaZucHLa3yVCeAylK/SNv/lIMaEjlqC35LrlcBE+6v7CeYYsOMmD4ti9hypmZAdnAfU+JCdPtzA3ZqFlEejLMSH5g==
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(1800799015)(376005)(82310400014)(36860700004);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Mar 2024 13:51:22.5376
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: cb863103-2fff-4735-9cb4-08dc442dd583
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DS2PEPF00003447.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB7661

On 2024-03-14 05:48, Roger Pau Monné wrote:
> On Wed, Mar 13, 2024 at 03:30:21PM -0400, Jason Andryuk wrote:
>> Xen tries to load a PVH dom0 kernel at the fixed guest physical address
>> from the elf headers.  For Linux, this defaults to 0x1000000 (16MB), but
>> it can be configured.
>>
>> Unfortunately there exist firmwares that have reserved regions at this
>> address, so Xen fails to load the dom0 kernel since it's not RAM.
>>
>> The PVH entry code is not relocatable - it loads from absolute
>> addresses, which fail when the kernel is loaded at a different address.
>> With a suitably modified kernel, a reloctable entry point is possible.
>>
>> Add XEN_ELFNOTE_PVH_RELOCATION which specifies the minimum, maximum and
>> alignment needed for the kernel.  The presence of the NOTE indicates the
>> kernel supports a relocatable entry path.
>>
>> Change the loading to check for an acceptable load address.  If the
>> kernel is relocatable, support finding an alternate load address.
>>
>> Link: https://gitlab.com/xen-project/xen/-/issues/180
>> Signed-off-by: Jason Andryuk 
>> ---
>> ELF Note printing looks like:
>> (XEN) ELF: note: PVH_RELOCATION = min: 0x1000000 max: 0xffffffff align: 0x200000
>>
>> v2:
>> Use elfnote for min, max & align - use 64bit values.
>> Print original and relocated memory addresses
>> Use check_and_adjust_load_address() name
>> Return relocated base instead of offset
>> Use PAGE_ALIGN
>> Don't load above max_phys (expected to be 4GB in kernel elf note)
>> Use single line comments
>> Exit check_load_address loop earlier
>> Add __init to find_kernel_memory()
>> ---
>>   xen/arch/x86/hvm/dom0_build.c      | 108 +++++++++++++++++++++++++++++
>>   xen/common/libelf/libelf-dominfo.c |  13 ++++
>>   xen/include/public/elfnote.h       |  11 +++
>>   xen/include/xen/libelf.h           |   3 +
>>   4 files changed, 135 insertions(+)
>>
>> diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
>> index 0ceda4140b..5c6c0d2db3 100644
>> --- a/xen/arch/x86/hvm/dom0_build.c
>> +++ b/xen/arch/x86/hvm/dom0_build.c
>> @@ -537,6 +537,108 @@ static paddr_t __init find_memory(
>>       return INVALID_PADDR;
>>   }
>>   
>> +static bool __init check_load_address(
>> +    const struct domain *d, const struct elf_binary *elf)
>> +{
>> +    paddr_t kernel_start = (paddr_t)elf->dest_base & PAGE_MASK;
> 
> Are you sure this is correct?  If a program header specifies a non-4K
> aligned load address we should still try to honor it.  I think this is
> very unlikely, but still we shouldn't apply non-requested alignments
> to addresses coming from the ELF headers.

I think it's correct in terms of checking the e820 table.  Since the 
memory map is limited to 4k granularity, the bounds need to be rounded 
accordingly.

>> +    paddr_t kernel_end = PAGE_ALIGN((paddr_t)elf->dest_base + elf->dest_size);
>> +    unsigned int i;
>> +
>> +    /*
>> +     * The memory map is sorted and all RAM regions starts and sizes are
>> +     * aligned to page boundaries.
> 
> Relying on sizes to be page aligned seems fragile: it might work now
> because of the order in which pvh_setup_vmx_realmode_helpers() first
> reserves memory for the TSS and afterwards for the identity page
> tables, but it's not a property this code should assume.

That can be removed.  It would just eliminate the early exit...

>> +     */
>> +    for ( i = 0; i < d->arch.nr_e820; i++ )
>> +    {
>> +        paddr_t start = d->arch.e820[i].addr;
>> +        paddr_t end = d->arch.e820[i].addr + d->arch.e820[i].size;
>> +
>> +        if ( start >= kernel_end )
>> +            return false;

... here.

>> +        if ( start <= kernel_start &&
>> +             end >= kernel_end &&
>> +             d->arch.e820[i].type == E820_RAM )
> 
> Nit: I would maybe do the type check before the boundary ones, as it's
> pointless to do boundary checking on a region of a non-RAM type.  But
> I guess you could also see it the other way around.
> 
>> +            return true;
>> +    }
>> +
>> +    return false;
>> +}
>> +
>> +/* Find an e820 RAM region that fits the kernel at a suitable alignment. */
>> +static paddr_t __init find_kernel_memory(
>> +    const struct domain *d, struct elf_binary *elf,
> 
> const for elf also.

Yes, thanks.

>> +    const struct elf_dom_parms *parms)
>> +{
>> +    paddr_t kernel_start = (paddr_t)elf->dest_base & PAGE_MASK;
>> +    paddr_t kernel_end = PAGE_ALIGN((paddr_t)elf->dest_base + elf->dest_size);
>> +    paddr_t kernel_size = kernel_end - kernel_start;
> 
> Hm, I'm again unsure about the alignments applied here.

Same as above regarding 4k granularity.

> I think if anything we want to assert that dest_base is aligned to phys_align.

That would indicate the kernel image is inconsistent.

>> +    unsigned int i;
>> +
>> +    /*
>> +     * The memory map is sorted and all RAM regions starts and sizes are
>> +     * aligned to page boundaries.
>> +     */
>> +    for ( i = 0; i < d->arch.nr_e820; i++ )
>> +    {
>> +        paddr_t start = d->arch.e820[i].addr;
>> +        paddr_t end = d->arch.e820[i].addr + d->arch.e820[i].size;
>> +        paddr_t kstart, kend;
>> +
>> +        if ( d->arch.e820[i].type != E820_RAM )
>> +            continue;
>> +
>> +        if ( d->arch.e820[i].size < kernel_size )
>> +            continue;
> 
> You can unify both checks in a single condition.

Ok.

>> +
>> +        kstart = ROUNDUP(start, parms->phys_align);
>> +        kstart = kstart < parms->phys_min ? parms->phys_min : kstart;
>> +        kend = kstart + kernel_size;
>> +
>> +        if ( kend > parms->phys_max )
>> +            return 0;
>> +
>> +        if ( kend <= end )
>> +            return kstart;
>> +    }
>> +
>> +    return 0;
>> +}
>> +
>> +/* Check the kernel load address, and adjust if necessary and possible. */
>> +static bool __init check_and_adjust_load_address(
>> +    const struct domain *d, struct elf_binary *elf, struct elf_dom_parms *parms)
>> +{
>> +    paddr_t reloc_base;
>> +
>> +    if ( check_load_address(d, elf) )
>> +        return true;
>> +
>> +    if ( parms->phys_align == UNSET_ADDR )
>> +    {
>> +        printk("Address conflict and %pd kernel is not relocatable\n", d);
>> +        return false;
>> +    }
>> +
>> +    reloc_base = find_kernel_memory(d, elf, parms);
>> +    if ( reloc_base == 0 )
>> +    {
>> +        printk("Failed find a load address for the kernel\n");
> 
> Since you print the domain in the error message prior to this one, I
> would consider also printing it here (or not printing it in both
> cases).

I'll add the %pd.

>> +        return false;
>> +    }
>> +
>> +    if ( opt_dom0_verbose )
>> +        printk("Relocating kernel from [%lx, %lx] -> [%lx, %lx]\n",
>> +               (paddr_t)elf->dest_base,
>> +               (paddr_t)elf->dest_base + elf->dest_size,
>> +               reloc_base, reloc_base + elf->dest_size);
> 
> I think you need `- 1` for the end calculation if you use inclusive
> ranges [, ].  Otherwise [, ) should be used.

Ok, I'll do [, ] with the -1.

>> +
>> +    parms->phys_entry += (reloc_base - (paddr_t)elf->dest_base);
> 
> This seems to assume that the image is always relocated at a higher
> address that the original one?
> 
> parms->phys_entry = reloc_base + (parms->phys_entry - elf->dest_base);

Ok

>> +    elf->dest_base = (char *)reloc_base;
>> +
>> +    return true;
>> +}
>> +
>>   static int __init pvh_load_kernel(struct domain *d, const module_t *image,
>>                                     unsigned long image_headroom,
>>                                     module_t *initrd, void *image_base,
>> @@ -585,6 +687,12 @@ static int __init pvh_load_kernel(struct domain *d, const module_t *image,
>>       elf.dest_base = (void *)(parms.virt_kstart - parms.virt_base);
>>       elf.dest_size = parms.virt_kend - parms.virt_kstart;
>>   
>> +    if ( !check_and_adjust_load_address(d, &elf, &parms) )
>> +    {
>> +        printk("Unable to load kernel\n");
> 
> check_and_adjust_load_address() already prints an error message,
> probably no need to print another message.

Ok

>> +        return -ENOMEM;
>> +    }
>> +
>>       elf_set_vcpu(&elf, v);
>>       rc = elf_load_binary(&elf);
>>       if ( rc < 0 )
>> diff --git a/xen/common/libelf/libelf-dominfo.c b/xen/common/libelf/libelf-dominfo.c
>> index 7cc7b18a51..837a1b0f21 100644
>> --- a/xen/common/libelf/libelf-dominfo.c
>> +++ b/xen/common/libelf/libelf-dominfo.c
>> @@ -125,6 +125,7 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
>>           [XEN_ELFNOTE_SUSPEND_CANCEL] = { "SUSPEND_CANCEL", ELFNOTE_INT },
>>           [XEN_ELFNOTE_MOD_START_PFN] = { "MOD_START_PFN", ELFNOTE_INT },
>>           [XEN_ELFNOTE_PHYS32_ENTRY] = { "PHYS32_ENTRY", ELFNOTE_INT },
>> +        [XEN_ELFNOTE_PVH_RELOCATION] = { "PVH_RELOCATION", ELFNOTE_OTHER },
>>       };
>>   /* *INDENT-ON* */
>>   
>> @@ -234,6 +235,17 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
>>                   elf_note_numeric_array(elf, note, 8, 0),
>>                   elf_note_numeric_array(elf, note, 8, 1));
>>           break;
>> +
>> +    case XEN_ELFNOTE_PVH_RELOCATION:
>> +        if ( elf_uval(elf, note, descsz) != 3 * sizeof(uint64_t) )
>> +            return -1;
>> +
>> +        parms->phys_min = elf_note_numeric_array(elf, note, 8, 0);
>> +        parms->phys_max = elf_note_numeric_array(elf, note, 8, 1);
>> +        parms->phys_align = elf_note_numeric_array(elf, note, 8, 2);
> 
> Size for those needs to be 4 (32bits) as the entry point is in 32bit
> mode?  I don't see how we can start past the 4GB boundary.

I specified the note as 3x 64bit values.  It seemed simpler than trying 
to support both 32bit and 64bit depending on the kernel arch.  Also, 
just using 64bit provides room in case it is needed in the future.

Do you want the note to be changed to 3x 32bit values?

>> +        elf_msg(elf, "min: %#"PRIx64" max: %#"PRIx64" align: %#"PRIx64"\n",
>> +                parms->phys_min, parms->phys_max, parms->phys_align);
>> +        break;
>>       }
>>       return 0;
>>   }
>> @@ -545,6 +557,7 @@ elf_errorstatus elf_xen_parse(struct elf_binary *elf,
>>       parms->p2m_base = UNSET_ADDR;
>>       parms->elf_paddr_offset = UNSET_ADDR;
>>       parms->phys_entry = UNSET_ADDR32;
>> +    parms->phys_align = UNSET_ADDR;
> 
> For correctness I would also init phys_{min,max}.

There is a memset() out of context above to zero the structure.  I 
thought leaving them both 0 would be fine.

I chose to initialize phys_align as the 64bit UNSET_ADDR since that is 
clearly invalid...  Though we don't have any checking that phys_align is 
a power of 2.

Regards,
Jason


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 13:52:29 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 13:52:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693255.1081118 (Exim 4.92)
	(envelope-from )
	id 1rklVV-0001Fp-BS; Thu, 14 Mar 2024 13:52:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693255.1081118; Thu, 14 Mar 2024 13:52:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rklVV-0001Fi-8Q; Thu, 14 Mar 2024 13:52:29 +0000
Received: by outflank-mailman (input) for mailman id 693255;
 Thu, 14 Mar 2024 13:52:28 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rklVT-0001FS-LI
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 13:52:28 +0000
Received: from esa.hc1631-21.eu.iphmx.com (esa.hc1631-21.eu.iphmx.com
 [23.90.122.185]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 15d131ae-e20a-11ee-a1ee-f123f15fe8a2;
 Thu, 14 Mar 2024 14:52:24 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 15d131ae-e20a-11ee-a1ee-f123f15fe8a2
X-CSE-ConnectionGUID: BjX6b61lRe6r6HRks16WJA==
X-CSE-MsgGUID: b6PQTAT6QVaLwbir97eWYQ==
Authentication-Results: ob1.hc1631-21.eu.iphmx.com; dkim=pass (signature verified) header.i=@thalesgroup.com
X-IronPort-AV: E=McAfee;i="6600,9927,11012"; a="10941823"
X-IronPort-AV: E=Sophos;i="6.07,125,1708383600"; 
   d="scan'208,217";a="10941823"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=thalesgroup.com; i=@thalesgroup.com; s=bbmfo20230504;
  t=1710424344;
  h=from:to:cc:subject:date:message-id:references:
   in-reply-to:mime-version;
  bh=1Q0ZSvZ+La6sDkq/7cSMfDjLfoxBuh7d7Uu3bMmHd3A=;
  b=x79pzWvJzgFUH1Z3dS+WJzdcsKZ4mBti8G4yI7peVvo5kpcKjxJBGBon
   q7T3wheBMZBzBxzwYHb/3akYiQ/TgWpi6YEP3080MVw0uHPkAEugisWW2
   j38tAv5Vjk+iJ2ew87cNR/zkpAFLRoGCX1v7t33zZESJ++tfeo4amDQfI
   A4rJr2mbLxhJWqyslbAC1gECLtnd+IDpyTJdYhCoeYTwwuVspeGWxD8rf
   SBKyTDukygLgpDs3NgNdukK7X60D/DbknNxKrzULmhoMMojBKKC0iEpJo
   euH8U1rGEWZdZncdoDV6K3HHkIblWaVD5v28gW1o/X+OkOkSQ9gozgaUJ
   w==;
X-CSE-ConnectionGUID: kMLm1cC6TICyqkblWOxqSQ==
X-CSE-MsgGUID: sZ28oqNmRYC4Tu2oHGzGcg==
X-CSE-ConnectionGUID: DjxuUZQvT2uuM56Hmm0C+w==
X-CSE-MsgGUID: JpfGlVJkRviOAeoJu31UAw==
X-IronPort-AV: E=McAfee;i="6600,9927,11012"; a="19619924"
X-IronPort-AV: E=Sophos;i="6.07,125,1708383600"; 
   d="scan'208,217";a="19619924"
From: LARRIEU Dominique 
To: Julien Grall 
CC: GOURLOT Francois , GRUO Nicolas
	, Cc , "Kelly
 Choi" , Jan Beulich ,
	=?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Andrew Cooper
	, George Dunlap ,
	Juergen Gross , WILLEMS Louis
	
Subject: RE: IMPORTANT - : Need help on USB port virtualization with Xen
 hypervisor
Thread-Topic: IMPORTANT - : Need help on USB port virtualization with Xen
 hypervisor
Thread-Index: AdpmcWIlf+ro0u5NSE2ZDRGqfQbNXAArMvkAAFwqbLAAdf8JUAAgWMTwAAKsSXAAApdqgAA+HiRgAlmoBSAALkcn4A==
Sensitivity: company-confidential
Date: Thu, 14 Mar 2024 13:52:22 +0000
Message-ID: <2e53bd839f904d8a97ee5645ee9e9361@thalesgroup.com>
References: 
 
 
 <427d2ecb865648b7a459c592c208c0be@thalesgroup.com>
 <673b2bc630d748e8af0a15d4b553906e@thalesgroup.com>
 <3ee3659afff645cabed86bcc22c44686@thalesgroup.com>
 <4778822e-582f-4e0d-9933-86d8d49ea3a5@xen.org>
 <8f2a2bbaf29e41709eeab695efe48f17@thalesgroup.com>
 
In-Reply-To: 
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-nodisclaimer: 0
Content-Type: multipart/alternative;
	boundary="_000_2e53bd839f904d8a97ee5645ee9e9361thalesgroupcom_"
MIME-Version: 1.0

--_000_2e53bd839f904d8a97ee5645ee9e9361thalesgroupcom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgSnVsaWVuLA0KDQoNCg0KWW91IHdpbGwgZmluZCBoZXJlIGFib3ZlIHRoZSBhbnN3ZXJzIHRv
IHlvdXIgcXVlc3Rpb25zLg0KDQoNCg0KVGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgeW91ciBoZWxw
Lg0KDQoNCg0KQmVzdCByZWdhcmRzLA0KDQpEb21pbmlxdWUNCg0KDQoNCg0KDQoNCg0KLS0tLS1N
ZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQpEZSA6IEp1bGllbiBHcmFsbCA8anVsaWVuQHhlbi5vcmc8
bWFpbHRvOmp1bGllbkB4ZW4ub3JnPj4NCkVudm95w6kgOiBqZXVkaSAyOSBmw6l2cmllciAyMDI0
IDEyOjUyDQrDgCA6IExBUlJJRVUgRG9taW5pcXVlIDxkb21pbmlxdWUubGFycmlldUB0aGFsZXNn
cm91cC5jb208bWFpbHRvOmRvbWluaXF1ZS5sYXJyaWV1QHRoYWxlc2dyb3VwLmNvbT4+DQpDYyA6
IEdPVVJMT1QgRnJhbmNvaXMgPGZyYW5jb2lzLmdvdXJsb3RAdGhhbGVzZ3JvdXAuY29tPG1haWx0
bzpmcmFuY29pcy5nb3VybG90QHRoYWxlc2dyb3VwLmNvbT4+OyBHUlVPIE5pY29sYXMgPG5pY29s
YXMtbi5ncnVvQHRoYWxlc2dyb3VwLmNvbTxtYWlsdG86bmljb2xhcy1uLmdydW9AdGhhbGVzZ3Jv
dXAuY29tPj47IENjIDx4ZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmc8bWFpbHRvOnhlbi1k
ZXZlbEBsaXN0cy54ZW5wcm9qZWN0Lm9yZz4+OyBLZWxseSBDaG9pIDxrZWxseS5jaG9pQGNsb3Vk
LmNvbTxtYWlsdG86a2VsbHkuY2hvaUBjbG91ZC5jb20+PjsgSmFuIEJldWxpY2ggPGpiZXVsaWNo
QHN1c2UuY29tPG1haWx0bzpqYmV1bGljaEBzdXNlLmNvbT4+OyBSb2dlciBQYXUgTW9ubsOpIDxy
b2dlci5wYXVAY2l0cml4LmNvbTxtYWlsdG86cm9nZXIucGF1QGNpdHJpeC5jb20+PjsgQW5kcmV3
IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbTxtYWlsdG86YW5kcmV3LmNvb3BlcjNA
Y2l0cml4LmNvbT4+OyBHZW9yZ2UgRHVubGFwIDxnZW9yZ2UuZHVubGFwQGNpdHJpeC5jb208bWFp
bHRvOmdlb3JnZS5kdW5sYXBAY2l0cml4LmNvbT4+OyBKdWVyZ2VuIEdyb3NzIDxqZ3Jvc3NAc3Vz
ZS5jb208bWFpbHRvOmpncm9zc0BzdXNlLmNvbT4+OyBXSUxMRU1TIExvdWlzIDxsb3Vpcy53aWxs
ZW1zQHRoYWxlc2dyb3VwLmNvbTxtYWlsdG86bG91aXMud2lsbGVtc0B0aGFsZXNncm91cC5jb20+
Pg0KT2JqZXQgOiBSZTogSU1QT1JUQU5UIC0gOiBOZWVkIGhlbHAgb24gVVNCIHBvcnQgdmlydHVh
bGl6YXRpb24gd2l0aCBYZW4gaHlwZXJ2aXNvcg0KDQoNCg0KSGkgRG9taW5pcXVlLA0KDQoNCg0K
T24gMjkvMDIvMjAyNCAxMDozMywgTEFSUklFVSBEb21pbmlxdWUgd3JvdGU6DQoNCj4gVGhhbmsg
eW91IGZvciB5b3VyIHF1aWNrIGFuc3dlci4NCg0KPg0KDQo+IFlvdSB3aWxsIGZpbmQgYmVsb3cg
b3VyIGFuc3dlcnMgKGluIHJlZCkgdG8geW91ciBxdWVzdGlvbnMuDQoNCj4NCg0KPiBUbyBzdW1t
YXJpemUgb3VyIHJlcXVlc3QgOiB3aGF0IHdlIHdvdWxkIGxpa2UgaXMgdG8gdXNlIFVTQiAzLjAg
ZHJpdmVyIHdpdGggaGlnaCBzcGVlZCBjb25maWd1cmF0aW9uLg0KDQo+IFRvZGF5LCBpdCBpcyBu
b3QgcG9zc2libGUgdG8gZG8gdGhhdC4NCg0KPiBUaGUgZHJpdmVyIHN0YXkgaW4gZnVsbCBzcGVl
ZCBtb2RlLCBhbmQgbW9yZSBvZnRlbiBpbiBVU0IgMS4wIG9yIDIuMCBjb25maWd1cmF0aW9uLg0K
DQo+DQoNCj4gSXMgaXQgcG9zc2libGUgdG8gY29uZmlndXJlIHRoZSBYRU4gVVNCIDMuMCBkcml2
ZXIgd2l0aCB0aGUgaGlnaCBzcGVlZCBtb2RlID8NCg0KPiAocmVhZCBpbiBvdXIgYW5zd2VycyBi
ZWxvdyB0aGUgcmVmZXJlbmNlIHRvIHRoZSBkcml2ZXIpDQoNCg0KDQpMb29raW5nIGF0IHdoYXQg
eW91IHByb3ZpZGVkIGJlbG93LCBpdCBpcyBzdGlsbCB1bmNsZWFyIHdoYXQgeW91IG1lYW4gYnkg
IlhlbiBVU0IgMy4wIGRyaXZlciIuIEJ5IGFueSBjaGFuY2UsIGFyZSB5b3UgY29uZnVzZWQgd2l0
aCB0aGUgIngiIGluIHhoY2k/DQoNCg0KDQpUaGUgZHJpdmVycyAieGhjaV9oY2QiIGFuZCAieGhj
aV9wY2kiIGFyZSBnZW5lcmljIGFuZCBub3QgcHJvdmlkZWQvbWFpbnRhaW5lZCBieSBYZW4uIFNv
IGZhciwgd2l0aCB0aGUgaW5mb3JtYXRpb24gcHJvdmlkZWQsIGl0IGlzIHVuY2xlYXIgd2hldGhl
ciB0aGUgcHJvYmxlbSBpcyBhY3R1YWxseSBpbiB0aGUgZHJpdmVyIGl0c2VsZi4gSSBoYXZlIGEg
ZmV3IG1vcmUgcXVlc3Rpb25zLiBTZWUgYmVsb3cuDQoNCg0KDQo+PiAgICAgIFdlIGFyZSBkZXRl
Y3Rpbmcgc2V2ZXJhbCBpc3N1ZXMgd2l0aCBVU0IgcG9ydCB2aXJ0dWFsaXphdGlvbg0KDQo+PiB3
aXRoIHRoZQ0KDQo+DQoNCj4+ICAgICAgWGVuIGh5cGVydmlzb3IuDQoNCj4NCg0KPg0KDQo+DQoN
Cj4gSnVzdCB0byBjbGFyaWZ5LCB5b3UgYXJlIGFzc2lnbmluZyB0aGUgUENJIFVTQiBidXMgKHJh
dGhlciB0aGFuIGp1c3QgdGhlIFVTQiBkZXZpY2UpIHRvIHRoZSBndWVzdC4gSXMgdGhhdCBjb3Jy
ZWN0Pw0KDQo+DQoNCj4NCg0KPg0KDQo+IElmIHNvLi4uDQoNCj4NCg0KPg0KDQo+DQoNCj4gW1Ro
YWxlc10gOiB3ZSBhcmUgdXNpbmcgdGhlIFVTQiBjaGlwc2V0IG9mIHRoZSBtb3RoZXIgYm9hcmQg
KHNlZSBiZWxvdw0KDQo+IHRoZSByZWZlcmVuY2VzKQ0KDQoNCg0KVGhhbmtzIGZvciB0aGUgY2xh
cmlmaWNhdGlvbi4gSUlVQywgeW91IHNhaWQgeW91IGFyZSBoYXZpbmcgcHJvYmxlbSBpbiB0aGUg
Z3Vlc3QgaXRzZWxmLiBIYXZlIHlvdSB0cmllZCB0byBhY2Nlc3MgdGhlIHNhbWUgVVNCIGRldmlj
ZSBmcm9tIGRvbTA/IE9yIGJldHRlciB3aXRob3V0IGFueSBYZW4gaW52b2x2ZWQgKGkuZS4gYm9v
dGluZyBEZWJpYW4gb24gYmFyZW1ldGFsKS4NCg0KDQoNClRoaXMgd291bGQgaGVscCB0byBuYXJy
b3cgZG93biB0aGUgaXNzdWUuDQoNCg0KDQpbVGhhbGVzLCAxNC8wMy8yNF0gV2UgaGF2ZSBubyBk
aWZmaWN1bHR5IGFjY2Vzc2luZyB0aGUgVVNCIGRldmljZSBvbiB0aGUgZG9tMA0KDQoNCg0KPj4N
Cg0KPg0KDQo+PiAgICAgIFdlIG5lZWR5b3VyIGhlbHB0byBmaW5kIGEgc29sdXRpb24gZm9yIHRo
ZXNlIHByb2JsZW1zLg0KDQo+DQoNCj4+DQoNCj4NCg0KPj4gICAgICBUaGUgU29mdHdhcmUgdXNl
ZCBhcmUgOg0KDQo+DQoNCj4NCg0KPg0KDQo+IENhbiB5b3Ugc2hhcmUgc29tZSBkZXRhaWxzIG9m
IHRoZSBIVyB5b3UgYXJlIHVzaW5nID8NCg0KPg0KDQo+DQoNCj4NCg0KPiBbVGhhbGVzXSA6IEhX
IDoNCg0KPg0KDQo+IFtUaGFsZXNdIDogV2UgYXJlIHVzaW5nIGEgR0VUQUMgWDUwMCB1c2luZyB0
aGUgTW9iaWxlIEludGVsIFFNMTc1DQoNCj4gQ2hpcHNldA0KDQo+DQoNCj4gW1RoYWxlc10gOiBV
U0IgY29udHJvbGxlcjogSW50ZWwgQ29ycG9yYXRpb24gMTAwIFNlcmllcy9DMjMwIFNlcmllcw0K
DQo+IENoaXBzZXQgRmFtaWx5IFVTQiAzLjAgeEhDSSBDb250cm9sbGVyIChyZXYgMzEpDQoNCj4N
Cg0KPiBbVGhhbGVzXSA6IFN1YnN5c3RlbTogTWl0YWMgMTAwIFNlcmllcy9DMjMwIFNlcmllcyBD
aGlwc2V0IEZhbWlseSBVU0INCg0KPiAzLjAgeEhDSSBDb250cm9sbGVyDQoNCj4NCg0KPg0KDQo+
DQoNCj4gW1RoYWxlc10gOiBTVyA6DQoNCj4NCg0KPiBbVGhhbGVzXSA6IEtlcm5lbCBkcml2ZXIg
aW4gdXNlOiB4aGNpX2hjZA0KDQo+DQoNCj4gW1RoYWxlc10gOiBLZXJuZWwgbW9kdWxlcyA6IHho
Y2lfcGNpDQoNCj4NCg0KPg0KDQo+DQoNCj4+DQoNCj4NCg0KPj4gICAgICAtRGViaWFuIDExIHZl
cnNpb241LjEwLjAtMjANCg0KDQoNCklJVUMsIGJlZm9yZSB5b3Ugc2FpZCB5b3UgaGFkIHByb2Js
ZW0gd2l0aCBXaW5kb3dzLiBTbyBpcyB0aGlzIHRoZSBzb2Z0d2FyZSBpbiBkb20wPyBPciBkaWQg
eW91IGFjdHVhbGx5IHRyeSB3aXRoIERlYmlhbiBhbmQgc3RpbGwgc2VlIHRoZSBzYW1lIGlzc3Vl
Pw0KDQpbVGhhbGVzLCAxNC8wMy8yNF0gV2UgYXJlIG5vdCBzdXJlIHRvIHVuZGVyc3RhbmQgdGhl
IHF1ZXN0aW9uLiBUaGUgaW5mb3JtYXRpb24gd2UgcHJvdmlkZWQgdG8geW91IHdhcyB0aGUgbW9k
dWxlcyBvbiB0aGUgZG9tMC4gVGhlIGRyaXZlciB3aGljaCBpcyBiYWNrIG9uIHRoZSBkb20gZ3Vl
c3QgV2luZG93czogY29udHJvbGV1ciBob3RlIFJldW5lc2FzVVNCIDMuMCBleHRlbnNpYmxlDQoN
Cg0KDQpSZWdhcmRpbmcgdGhlIGNvbmZpZ3VyYXRpb24sIGdpdmVuIHlvdSBhcmUgdXNpbmcgdGhl
IG9mZmljaWFsIERlYmlhbiBwYWNrYWdlLiBBcmUgeW91IHVzaW5nICd4bCcgdG8gY3JlYXRlIHlv
dXIgZ3Vlc3Q/DQoNCltUaGFsZXMsIDE0LzAzLzI0XSB5ZXMgd2UgZG8NCg0KDQoNClRoZSBpZGVh
bCB3b3VsZCBiZSBpZiB5b3UgY2FuIHBhc3RlIHRoZSBmdWxsIGNvbmZpZ3VyYXRpb24uIElmIHlv
dSBjYW4ndCBjYW4geW91IHRlbGwgdXMgaWYgeW91IGFyZSB1c2luZyBhbnkgb2YgdGhlc2Ugb3B0
aW9uczogJ3BjaScsICd1c2JkZXYnLCAndXNiY3RybCc/DQoNCltUaGFsZXMsIDE0LzAzLzI0XQ0K
DQpkZXZpY2VfbW9kZWxfYXJncyA9IFsgIg0KDQogICAgICAgICAgICAgICAgICAgICAgIi1kZXZp
Y2UiLCJuZWMtdXNiLXhoY2ksaWQ9eGhjaSIsDQoNCiAgICAgICAgICAgICAgICAgICAgICAiLWRl
dmljZSIsInVzYi1ob3N0LGJ1cz14aGNpLjAsaG9zdGJ1cz0xLGhvc3Rwb3J0PTEzIiwNCg0KICAg
ICAgICAgICAgICAgICAgICAgICItZGV2aWNlIiwidXNiLWhvc3QsYnVzPXhoY2kuMCxob3N0YnVz
PTEsaG9zdHBvcnQ9MTAiLA0KDQogICAgICAgICAgICAgICAgICAgICAgIi1kZXZpY2UiLCJ1c2It
aG9zdCxidXM9eGhjaS4wLGhvc3RidXM9MSxob3N0cG9ydD0yIiwNCg0KICAgICAgICAgICAgICAg
ICAgICAgICItZGV2aWNlIiwidXNiLWhvc3QsYnVzPXhoY2kuMCxob3N0YnVzPTIsaG9zdHBvcnQ9
MiIsDQoNCiAgICAgICAgICAgICAgICAgICAgICAiLWRldmljZSIsInVzYi1ob3N0LGJ1cz14aGNp
LjAsaG9zdGJ1cz0yLGhvc3Rwb3J0PTEiLA0KDQogICAgICAgICAgICAgICAgICAgICAgIi1kZXZp
Y2UiLCJ1c2ItaG9zdCxidXM9eGhjaS4wLGhvc3RidXM9MSxob3N0cG9ydD0xIl0NCg0KW2VuZCBU
aGFsZXMsIDE0LzAzLzI0XQ0KDQoNCg0KWy4uLl0NCg0KDQoNCj4+ICAgICAgLVhlbiB2ZXJzaW9u
NC4xNA0KDQo+DQoNCj4NCg0KPg0KDQo+IEFyZSBtaW5vciB2ZXJzaW9uIG9mIFhlbiA0LjE0IGFy
ZSB5b3UgdXNpbmcgPyBBbnkgcGF0Y2hlcyBvbiB0b3AgPw0KDQo+DQoNCj4NCg0KPg0KDQo+IFhl
biA0LjE0IGhhcyBhbHNvIGJlZW4gb3V0IG9mIHN1cHBvcnQgZm9yIGEgZmV3IG1vbnRocyBub3cu
IElmIHRoYXTigJlzDQoNCj4gcG9zc2libGUsIEkgd291bGQgcmVjb21tZW5kIHRvIHRyeSBhIG5l
dyBYZW4gdmVyc2lvbiAodGhlIGxhc3Qgc3RhYmxlDQoNCj4gaXMNCg0KPg0KDQo+IDQuMTgpIGp1
c3QgaW4gY2FzZSB5b3VyIGlzc3VlIGFzIGJlZW4gZml4ZWQgaW4gbmV3ZXIgcmVsZWFzZS4NCg0K
Pg0KDQo+DQoNCj4NCg0KPiBbVGhhbGVzXSA6IHdlIGhhdmUgdG8gdXNlIFhlbiByZWxlYXNlIHRo
YXQgYXJlIGRvd25sb2FkZWQgZnJvbSB0aGUNCg0KPiBEZWJpYW4gb2ZmaWNpYWwgcmVwb3NpdG9y
eSAgKHJlcXVlc3RlZCBieSBvdXIgY3VzdG9tZXIpDQoNCj4NCg0KPiBbVGhhbGVzXSA6IHRoZSBs
YXN0IG9uZSBpcyB2ZXJzaW9uIDQuMTQsIGJ1dCB3ZSB3b3VsZCBsaWtlIHRvIGtub3cgaWYgdGhl
cmUgaXMgb25lIG1vcmUgcmVjZW50IHRoYXQgaXMgY29tcGF0aWJsZSB3aXRoIExpbnV4IERlYmlh
biAxMSA/DQoNCg0KDQpOZXdlciBYZW4gcmVsZWFzZXMgc2hvdWxkIGJlIGNvbXBhdGlibGUgd2l0
aCBEZWJpYW4gMTEuIEJ1dCBJIGFtIG5vdCBhd2FyZSBvZiBhbnkgIm9mZmljaWFsIiBwYWNrYWdl
IGZvciB0aGF0IHNwZWNpZmljIHZlcnNpb24uDQoNCg0KDQpDaGVlcnMsDQoNCg0KDQotLQ0KDQpK
dWxpZW4gR3JhbGwNCg==

--_000_2e53bd839f904d8a97ee5645ee9e9361thalesgroupcom_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglt
c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ
e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlv
bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z
by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1
bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWlu
VGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRlIGJy
dXQgQ2FyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp
emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJl
YXN0LWxhbmd1YWdlOkVOLVVTO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1z
b25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFs
dDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87
DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp
bWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5UZXh0ZWJydXRDYXINCgl7bXNvLXN0eWxlLW5h
bWU6IlRleHRlIGJydXQgQ2FyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl
LWxpbms6IlRleHRlIGJydXQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N
CnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFt
aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0
eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh
bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt
c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdv
cmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44
NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp
b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1
bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt
LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp
ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl
bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZSIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0i
Izk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb1BsYWlu
VGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkhpIEp1bGllbiw8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFG
NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4
dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5Zb3Ugd2lsbCBmaW5k
IGhlcmUgYWJvdmUgdGhlIGFuc3dlcnMgdG8geW91ciBxdWVzdGlvbnMuPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl
PSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlRo
YW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHlvdXIgaGVscC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMx
RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl
eHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+QmVzdCByZWdhcmRz
LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+RG9taW5pcXVlPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl
PSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0
LWxhbmd1YWdlOkZSIj4tLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS08YnI+DQpEZSZuYnNwOzog
SnVsaWVuIEdyYWxsICZsdDs8YSBocmVmPSJtYWlsdG86anVsaWVuQHhlbi5vcmciPmp1bGllbkB4
ZW4ub3JnPC9hPiZndDsgPGJyPg0KRW52b3nDqSZuYnNwOzogamV1ZGkgMjkgZsOpdnJpZXIgMjAy
NCAxMjo1Mjxicj4NCsOAJm5ic3A7OiBMQVJSSUVVIERvbWluaXF1ZSAmbHQ7PGEgaHJlZj0ibWFp
bHRvOmRvbWluaXF1ZS5sYXJyaWV1QHRoYWxlc2dyb3VwLmNvbSI+ZG9taW5pcXVlLmxhcnJpZXVA
dGhhbGVzZ3JvdXAuY29tPC9hPiZndDs8YnI+DQpDYyZuYnNwOzogR09VUkxPVCBGcmFuY29pcyAm
bHQ7PGEgaHJlZj0ibWFpbHRvOmZyYW5jb2lzLmdvdXJsb3RAdGhhbGVzZ3JvdXAuY29tIj5mcmFu
Y29pcy5nb3VybG90QHRoYWxlc2dyb3VwLmNvbTwvYT4mZ3Q7OyBHUlVPIE5pY29sYXMgJmx0Ozxh
IGhyZWY9Im1haWx0bzpuaWNvbGFzLW4uZ3J1b0B0aGFsZXNncm91cC5jb20iPm5pY29sYXMtbi5n
cnVvQHRoYWxlc2dyb3VwLmNvbTwvYT4mZ3Q7OyBDYyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnhlbi1k
ZXZlbEBsaXN0cy54ZW5wcm9qZWN0Lm9yZyI+eGVuLWRldmVsQGxpc3RzLnhlbnByb2plY3Qub3Jn
PC9hPiZndDs7DQogS2VsbHkgQ2hvaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtlbGx5LmNob2lAY2xv
dWQuY29tIj5rZWxseS5jaG9pQGNsb3VkLmNvbTwvYT4mZ3Q7OyBKYW4gQmV1bGljaCAmbHQ7PGEg
aHJlZj0ibWFpbHRvOmpiZXVsaWNoQHN1c2UuY29tIj5qYmV1bGljaEBzdXNlLmNvbTwvYT4mZ3Q7
OyBSb2dlciBQYXUgTW9ubsOpICZsdDs8YSBocmVmPSJtYWlsdG86cm9nZXIucGF1QGNpdHJpeC5j
b20iPnJvZ2VyLnBhdUBjaXRyaXguY29tPC9hPiZndDs7IEFuZHJldyBDb29wZXIgJmx0OzxhIGhy
ZWY9Im1haWx0bzphbmRyZXcuY29vcGVyM0BjaXRyaXguY29tIj5hbmRyZXcuY29vcGVyM0BjaXRy
aXguY29tPC9hPiZndDs7DQogR2VvcmdlIER1bmxhcCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdlb3Jn
ZS5kdW5sYXBAY2l0cml4LmNvbSI+Z2VvcmdlLmR1bmxhcEBjaXRyaXguY29tPC9hPiZndDs7IEp1
ZXJnZW4gR3Jvc3MgJmx0OzxhIGhyZWY9Im1haWx0bzpqZ3Jvc3NAc3VzZS5jb20iPmpncm9zc0Bz
dXNlLmNvbTwvYT4mZ3Q7OyBXSUxMRU1TIExvdWlzICZsdDs8YSBocmVmPSJtYWlsdG86bG91aXMu
d2lsbGVtc0B0aGFsZXNncm91cC5jb20iPmxvdWlzLndpbGxlbXNAdGhhbGVzZ3JvdXAuY29tPC9h
PiZndDs8YnI+DQpPYmpldCZuYnNwOzogUmU6IElNUE9SVEFOVCAtIDogTmVlZCBoZWxwIG9uIFVT
QiBwb3J0IHZpcnR1YWxpemF0aW9uIHdpdGggWGVuIGh5cGVydmlzb3I8L3NwYW4+PG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29QbGFpblRleHQiPkhpIERvbWluaXF1ZSw8bzpwPjwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs
YWluVGV4dCI+T24gMjkvMDIvMjAyNCAxMDozMywgTEFSUklFVSBEb21pbmlxdWUgd3JvdGU6PG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFRoYW5rIHlvdSBmb3Ig
eW91ciBxdWljayBhbnN3ZXIuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0
Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBZb3Ug
d2lsbCBmaW5kIGJlbG93IG91ciBhbnN3ZXJzIChpbiByZWQpIHRvIHlvdXIgcXVlc3Rpb25zLjxv
OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgVG8gc3VtbWFyaXplIG91ciByZXF1ZXN0
IDogd2hhdCB3ZSB3b3VsZCBsaWtlIGlzIHRvIHVzZSBVU0IgMy4wIGRyaXZlciB3aXRoIGhpZ2gg
c3BlZWQgY29uZmlndXJhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl
eHQiPiZndDsgVG9kYXksIGl0IGlzIG5vdCBwb3NzaWJsZSB0byBkbyB0aGF0LjxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBUaGUgZHJpdmVyIHN0YXkgaW4gZnVs
bCBzcGVlZCBtb2RlLCBhbmQgbW9yZSBvZnRlbiBpbiBVU0IgMS4wIG9yIDIuMCBjb25maWd1cmF0
aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgSXMgaXQgcG9zc2libGUgdG8g
Y29uZmlndXJlIHRoZSBYRU4gVVNCIDMuMCBkcml2ZXIgd2l0aCB0aGUgaGlnaCBzcGVlZCBtb2Rl
ID88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgKHJlYWQgaW4g
b3VyIGFuc3dlcnMgYmVsb3cgdGhlIHJlZmVyZW5jZSB0byB0aGUgZHJpdmVyKTxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwQjBGMCI+TG9va2luZyBh
dCB3aGF0IHlvdSBwcm92aWRlZCBiZWxvdywgaXQgaXMgc3RpbGwgdW5jbGVhciB3aGF0IHlvdSBt
ZWFuIGJ5ICZxdW90O1hlbiBVU0IgMy4wIGRyaXZlciZxdW90Oy4gQnkgYW55IGNoYW5jZSwgYXJl
IHlvdSBjb25mdXNlZCB3aXRoIHRoZSAmcXVvdDt4JnF1b3Q7IGluIHhoY2k/PG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMw
MEIwRjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl
eHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDBCMEYwIj5UaGUgZHJpdmVycyAmcXVvdDt4aGNpX2hj
ZCZxdW90OyBhbmQgJnF1b3Q7eGhjaV9wY2kmcXVvdDsgYXJlIGdlbmVyaWMgYW5kIG5vdCBwcm92
aWRlZC9tYWludGFpbmVkIGJ5IFhlbi4gU28gZmFyLCB3aXRoIHRoZSBpbmZvcm1hdGlvbiBwcm92
aWRlZCwgaXQgaXMgdW5jbGVhciB3aGV0aGVyIHRoZSBwcm9ibGVtIGlzIGFjdHVhbGx5IGluIHRo
ZSBkcml2ZXIgaXRzZWxmLiBJIGhhdmUgYSBmZXcNCiBtb3JlIHF1ZXN0aW9ucy4gU2VlIGJlbG93
LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsgV2UgYXJlIGRldGVjdGluZyBzZXZlcmFsIGlzc3VlcyB3aXRo
IFVTQiBwb3J0IHZpcnR1YWxpemF0aW9uDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q
bGFpblRleHQiPiZndDsmZ3Q7IHdpdGggdGhlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
UGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+
Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgWGVuIGh5cGVydmlzb3IuPG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U
ZXh0Ij4mZ3Q7IEp1c3QgdG8gY2xhcmlmeSwgeW91IGFyZSBhc3NpZ25pbmcgdGhlIFBDSSBVU0Ig
YnVzIChyYXRoZXIgdGhhbiBqdXN0IHRoZSBVU0IgZGV2aWNlKSB0byB0aGUgZ3Vlc3QuIElzIHRo
YXQgY29ycmVjdD88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29QbGFpblRleHQiPiZndDsgSWYgc28uLi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U
ZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgW1RoYWxlc10gOiB3
ZSBhcmUgdXNpbmcgdGhlIFVTQiBjaGlwc2V0IG9mIHRoZSBtb3RoZXIgYm9hcmQgKHNlZSBiZWxv
dw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHRoZSByZWZl
cmVuY2VzKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6
IzAwQjBGMCI+VGhhbmtzIGZvciB0aGUgY2xhcmlmaWNhdGlvbi4gSUlVQywgeW91IHNhaWQgeW91
IGFyZSBoYXZpbmcgcHJvYmxlbSBpbiB0aGUgZ3Vlc3QgaXRzZWxmLiBIYXZlIHlvdSB0cmllZCB0
byBhY2Nlc3MgdGhlIHNhbWUgVVNCIGRldmljZSBmcm9tIGRvbTA/IE9yIGJldHRlciB3aXRob3V0
IGFueSBYZW4gaW52b2x2ZWQgKGkuZS4gYm9vdGluZyBEZWJpYW4gb24gYmFyZW1ldGFsKS48bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0i
Y29sb3I6IzAwQjBGMCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEIwRjAiPlRoaXMgd291bGQgaGVscCB0
byBuYXJyb3cgZG93biB0aGUgaXNzdWUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb1BsYWluVGV4dCI+PGI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0
OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Q
bGFpblRleHQiPjxiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+
W1RoYWxlcywgMTQvMDMvMjRdIFdlIGhhdmUgbm8gZGlmZmljdWx0eSBhY2Nlc3NpbmcgdGhlIFVT
QiBkZXZpY2Ugb24gdGhlIGRvbTA8L3NwYW4+PC9pPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q
bGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29QbGFpblRleHQiPiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFdlIG5l
ZWR5b3VyIGhlbHB0byBmaW5kIGEgc29sdXRpb24gZm9yIHRoZXNlIHByb2JsZW1zLjxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs
YWluVGV4dCI+Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhlIFNvZnR3
YXJlIHVzZWQgYXJlIDo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn
dDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgQ2FuIHlvdSBzaGFyZSBzb21lIGRldGFpbHMgb2Yg
dGhlIEhXIHlvdSBhcmUgdXNpbmcgPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu
VGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBbVGhhbGVzXSA6IEhXIDo8bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFtUaGFsZXNdIDogV2UgYXJlIHVzaW5nIGEgR0VU
QUMgWDUwMCB1c2luZyB0aGUgTW9iaWxlIEludGVsIFFNMTc1DQo8bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgQ2hpcHNldDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp
blRleHQiPiZndDsgW1RoYWxlc10gOiBVU0IgY29udHJvbGxlcjogSW50ZWwgQ29ycG9yYXRpb24g
MTAwIFNlcmllcy9DMjMwIFNlcmllcw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh
aW5UZXh0Ij4mZ3Q7IENoaXBzZXQgRmFtaWx5IFVTQiAzLjAgeEhDSSBDb250cm9sbGVyIChyZXYg
MzEpPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBbVGhhbGVzXSA6IFN1YnN5c3Rl
bTogTWl0YWMgMTAwIFNlcmllcy9DMjMwIFNlcmllcyBDaGlwc2V0IEZhbWlseSBVU0INCjxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAzLjAgeEhDSSBDb250cm9s
bGVyPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
UGxhaW5UZXh0Ij4mZ3Q7IFtUaGFsZXNdIDogU1cgOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl
eHQiPiZndDsgW1RoYWxlc10gOiBLZXJuZWwgZHJpdmVyIGluIHVzZTogeGhjaV9oY2Q8bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFtUaGFsZXNdIDogS2VybmVsIG1vZHVsZXMgOiB4
aGNpX3BjaTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0
Ij4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtRGViaWFuIDExIHZlcnNp
b241LjEwLjAtMjA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNv
bG9yOiMwMEIwRjAiPklJVUMsIGJlZm9yZSB5b3Ugc2FpZCB5b3UgaGFkIHByb2JsZW0gd2l0aCBX
aW5kb3dzLiBTbyBpcyB0aGlzIHRoZSBzb2Z0d2FyZSBpbiBkb20wPyBPciBkaWQgeW91IGFjdHVh
bGx5IHRyeSB3aXRoIERlYmlhbiBhbmQgc3RpbGwgc2VlIHRoZSBzYW1lIGlzc3VlPzxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxiPjxpPjxzcGFuIGxhbmc9
IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+W1RoYWxlcywgMTQvMDMvMjRdIFdlIGFyZSBu
b3Qgc3VyZSB0byB1bmRlcnN0YW5kIHRoZSBxdWVzdGlvbi4gVGhlIGluZm9ybWF0aW9uIHdlIHBy
b3ZpZGVkIHRvIHlvdSB3YXMgdGhlIG1vZHVsZXMgb24gdGhlIGRvbTAuIFRoZSBkcml2ZXIgd2hp
Y2ggaXMgYmFjayBvbiB0aGUgZG9tIGd1ZXN0IFdpbmRvd3M6IGNvbnRyb2xldXINCiBob3RlIFJl
dW5lc2FzVVNCIDMuMCBleHRlbnNpYmxlPC9zcGFuPjwvaT48L2I+PHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMwMEIwRjAiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu
IHN0eWxlPSJjb2xvcjojMDBCMEYwIj5SZWdhcmRpbmcgdGhlIGNvbmZpZ3VyYXRpb24sIGdpdmVu
IHlvdSBhcmUgdXNpbmcgdGhlIG9mZmljaWFsIERlYmlhbiBwYWNrYWdlLiBBcmUgeW91IHVzaW5n
ICd4bCcgdG8gY3JlYXRlIHlvdXIgZ3Vlc3Q/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb1BsYWluVGV4dCI+PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPls8L3Nw
YW4+PC9pPjwvYj48Yj48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi
PlRoYWxlcywgMTQvMDMvMjQ8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPl0geWVz
IHdlIGRvPC9zcGFuPjwvaT48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xv
cjojMDBCMEYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh
aW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwQjBGMCI+VGhlIGlkZWFsIHdvdWxkIGJlIGlm
IHlvdSBjYW4gcGFzdGUgdGhlIGZ1bGwgY29uZmlndXJhdGlvbi4gSWYgeW91IGNhbid0IGNhbiB5
b3UgdGVsbCB1cyBpZiB5b3UgYXJlIHVzaW5nIGFueSBvZiB0aGVzZSBvcHRpb25zOiAncGNpJywg
J3VzYmRldicsICd1c2JjdHJsJz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
UGxhaW5UZXh0Ij48Yj48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi
PltUaGFsZXMsIDE0LzAzLzI0XQ0KPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBj
bGFzcz0iTXNvUGxhaW5UZXh0Ij48Yj48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y
OiMxRjQ5N0QiPmRldmljZV9tb2RlbF9hcmdzID0gWyAmcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48
L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxiPjxpPjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90Oy1kZXZpY2UmcXVv
dDssJnF1b3Q7bmVjLXVzYi14aGNpLGlkPXhoY2kmcXVvdDssPG86cD48L286cD48L3NwYW4+PC9p
PjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48Yj48aT48c3BhbiBsYW5nPSJFTi1V
UyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDstZGV2aWNlJnF1b3Q7
LCZxdW90O3VzYi1ob3N0LGJ1cz14aGNpLjAsaG9zdGJ1cz0xLGhvc3Rwb3J0PTEzJnF1b3Q7LDxv
OnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PGI+
PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
JnF1b3Q7LWRldmljZSZxdW90OywmcXVvdDt1c2ItaG9zdCxidXM9eGhjaS4wLGhvc3RidXM9MSxo
b3N0cG9ydD0xMCZxdW90Oyw8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNz
PSJNc29QbGFpblRleHQiPjxiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFG
NDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90Oy1kZXZpY2UmcXVvdDssJnF1b3Q7dXNiLWhvc3QsYnVz
PXhoY2kuMCxob3N0YnVzPTEsaG9zdHBvcnQ9MiZxdW90Oyw8bzpwPjwvbzpwPjwvc3Bhbj48L2k+
PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxiPjxpPjxzcGFuIGxhbmc9IkVOLVVT
IiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90Oy1kZXZpY2UmcXVvdDss
JnF1b3Q7dXNiLWhvc3QsYnVzPXhoY2kuMCxob3N0YnVzPTIsaG9zdHBvcnQ9MiZxdW90Oyw8bzpw
PjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxiPjxp
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZx
dW90Oy1kZXZpY2UmcXVvdDssJnF1b3Q7dXNiLWhvc3QsYnVzPXhoY2kuMCxob3N0YnVzPTIsaG9z
dHBvcnQ9MSZxdW90Oyw8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJN
c29QbGFpblRleHQiPjxiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3
RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7ICZxdW90Oy1kZXZpY2UmcXVvdDssJnF1b3Q7dXNiLWhvc3QsYnVzPXho
Y2kuMCxob3N0YnVzPTEsaG9zdHBvcnQ9MSZxdW90O108bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9i
PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBz
dHlsZT0iY29sb3I6IzFGNDk3RCI+W2VuZCBUaGFsZXMsIDE0LzAzLzI0XTwvc3Bhbj48L2k+PC9i
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl
PSJjb2xvcjojMDBCMEYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwQjBGMCI+Wy4uLl08bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7IC1YZW4gdmVyc2lvbjQuMTQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q
bGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m
Z3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgQXJlIG1pbm9yIHZlcnNpb24g
b2YgWGVuIDQuMTQgYXJlIHlvdSB1c2luZyA/IEFueSBwYXRjaGVzIG9uIHRvcCA/PG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q
bGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m
Z3Q7IFhlbiA0LjE0IGhhcyBhbHNvIGJlZW4gb3V0IG9mIHN1cHBvcnQgZm9yIGEgZmV3IG1vbnRo
cyBub3cuIElmIHRoYXTigJlzDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl
eHQiPiZndDsgcG9zc2libGUsIEkgd291bGQgcmVjb21tZW5kIHRvIHRyeSBhIG5ldyBYZW4gdmVy
c2lvbiAodGhlIGxhc3Qgc3RhYmxlDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp
blRleHQiPiZndDsgaXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn
dDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDQuMTgpIGp1
c3QgaW4gY2FzZSB5b3VyIGlzc3VlIGFzIGJlZW4gZml4ZWQgaW4gbmV3ZXIgcmVsZWFzZS48bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl
eHQiPiZndDsgW1RoYWxlc10gOiB3ZSBoYXZlIHRvIHVzZSBYZW4gcmVsZWFzZSB0aGF0IGFyZSBk
b3dubG9hZGVkIGZyb20gdGhlDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl
eHQiPiZndDsgRGViaWFuIG9mZmljaWFsIHJlcG9zaXRvcnkmbmJzcDsgKHJlcXVlc3RlZCBieSBv
dXIgY3VzdG9tZXIpPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7
IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBbVGhhbGVzXSA6
IHRoZSBsYXN0IG9uZSBpcyB2ZXJzaW9uIDQuMTQsIGJ1dCB3ZSB3b3VsZCBsaWtlIHRvIGtub3cg
aWYgdGhlcmUgaXMgb25lIG1vcmUgcmVjZW50IHRoYXQgaXMgY29tcGF0aWJsZSB3aXRoIExpbnV4
IERlYmlhbiAxMSA/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJj
b2xvcjojMDBCMEYwIj5OZXdlciBYZW4gcmVsZWFzZXMgc2hvdWxkIGJlIGNvbXBhdGlibGUgd2l0
aCBEZWJpYW4gMTEuIEJ1dCBJIGFtIG5vdCBhd2FyZSBvZiBhbnkgJnF1b3Q7b2ZmaWNpYWwmcXVv
dDsgcGFja2FnZSBmb3IgdGhhdCBzcGVjaWZpYyB2ZXJzaW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb1BsYWluVGV4dCI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs
YWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4t
LTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SnVsaWVuIEdyYWxsPG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_2e53bd839f904d8a97ee5645ee9e9361thalesgroupcom_--


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 13:59:22 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 13:59:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693262.1081128 (Exim 4.92)
	(envelope-from )
	id 1rklc6-0002kh-3k; Thu, 14 Mar 2024 13:59:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693262.1081128; Thu, 14 Mar 2024 13:59:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rklc6-0002ka-0j; Thu, 14 Mar 2024 13:59:18 +0000
Received: by outflank-mailman (input) for mailman id 693262;
 Thu, 14 Mar 2024 13:59:16 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rklc4-0002kB-Lv
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 13:59:16 +0000
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com
 [2a00:1450:4864:20::62b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0b3253bb-e20b-11ee-afdd-a90da7624cb6;
 Thu, 14 Mar 2024 14:59:15 +0100 (CET)
Received: by mail-ej1-x62b.google.com with SMTP id
 a640c23a62f3a-a44ad785a44so110491566b.3
 for ; Thu, 14 Mar 2024 06:59:15 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 v23-20020a1709067d9700b00a4663a7120asm732563ejo.166.2024.03.14.06.59.14
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 14 Mar 2024 06:59:14 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0b3253bb-e20b-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710424755; x=1711029555; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=PTZHmdbshlGJsjltfROdPt/9dSDQ3SNpaFHQiXFxfzU=;
        b=EDLvOM/TGWtj1QeRg9UISkzkAgfcHAH/Dw9PpMbVgoQJgOH+1kvD/hYp0gvRJB3VNZ
         Wro1LWtk/Tlmve3Y7vHInBX3B2U2uU4HiOYWr1edIfnYmHula9NzNvnwmGCuhszxa8C/
         01fA3pveoYW1lTCuw8XYK++i76neXFNNUbB1V2sSyEqDjZn9WRzEXN/LEtlYO+EyZTqt
         dCq9EifE0yYBRFL7mOP/b3acpKrL3Ivlk47dfK6ykvzS32UuoQRRDn317ps8PokRtMH5
         USZzaDDAcJZasEYUMbLFB/j/w913liphW55ouAqsAZMMp3PMk9gHJ3l6xLmAuBdQA9y8
         555g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710424755; x=1711029555;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=PTZHmdbshlGJsjltfROdPt/9dSDQ3SNpaFHQiXFxfzU=;
        b=hHfIsG1lH65YvWWupjW+W5lmgrL/MCcgPcvVliYdeDNGCkTz5QpdF8QJAoOZFNf6YO
         KV3+Wbw5HjnfhE7RK1ha0Aaz6NvjaksCrkgsFTHF4kCAbTITkEC9XPsM28GAZ3Igbehl
         YQ2sa2jW0wF40bf/ygA+NxhfewcdSYkCP5YV7jIcvxr/7k2bX+H1B9LzBlecUXPmchx7
         h99nSjjDVOFqS5HA3Eo3vqecBtS2LJouXIqJ/cml4CHegQBzsywoJy1LRrGaI2BBdzda
         wRQOvZY3AzCdmiloS6Dnc45WZ0UeVEYuvQfnbpHynK0+taCprxe99/poGjkdMFNWVtIy
         Wj8g==
X-Forwarded-Encrypted: i=1; AJvYcCWompE1cLW4v0DrFiunS5bU15uCz4iukSJCb1LpzkADPswjIKLiSM8bpVx7/PJccjrdcqzquPTSdDjXqAnHyvKG1dzNZ//aCEYdYAadVug=
X-Gm-Message-State: AOJu0YxfYwCfEdpF5EM1e0bJtF2HDSxn4iEN9Nol7+zDsf2Uxpz83HBD
	J4tmQ/Ep1/8VHpiocR79nBByWv/JnUTtjPJvccyBZ5T25ZzzcaxUme3ZHza+hg==
X-Google-Smtp-Source: AGHT+IGdSMmJxR7r40xC+jIBEfDp5KWLTkBsjfq30vkny9N2IIt1A4cHNyuBVGz7OlYqEGT66nGrlg==
X-Received: by 2002:a17:907:cbc8:b0:a46:2772:de9b with SMTP id vk8-20020a170907cbc800b00a462772de9bmr645749ejc.22.1710424755139;
        Thu, 14 Mar 2024 06:59:15 -0700 (PDT)
Message-ID: <141bc66c-79f4-474e-8421-34f9aaa2d47c@suse.com>
Date: Thu, 14 Mar 2024 14:59:13 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/7] xen/bitops: Cleanup ahead of rearrangements
Content-Language: en-US
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Wei Liu , Stefano Stabellini ,
 Julien Grall , Volodymyr Babchuk
 , Bertrand Marquis ,
 Michal Orzel ,
 Oleksii Kurochko ,
 Shawn Anastasio ,
 "consulting @ bugseng . com" ,
 Simone Ballarin ,
 Federico Serafini ,
 Nicola Vetrini ,
 Xen-devel 
References: <20240313172716.2325427-1-andrew.cooper3@citrix.com>
 <20240313172716.2325427-2-andrew.cooper3@citrix.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240313172716.2325427-2-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 13.03.2024 18:27, Andrew Cooper wrote:
>  * Rename __attribute_pure__ to just __pure before it gains users.
>  * Identify the areas of xen/bitops.h which are a mess.
>  * Create common/bitops.c for compile and runtime testing.  This provides a
>    statement of the ABI, and a confirmation that arch-specific implementations
>    behave as expected.

If this is the sole purpose of the new file, then ...

> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -1,5 +1,6 @@
>  obj-$(CONFIG_ARGO) += argo.o
>  obj-y += bitmap.o
> +obj-y += bitops.o

obj-bin-y += bitops.init.o

please.

> --- /dev/null
> +++ b/xen/common/bitops.c
> @@ -0,0 +1,41 @@
> +#include 
> +#include 
> +#include 
> +
> +/* Hide a value from the optimiser. */
> +#define HIDE(x) ({ typeof(x) _x = x; asm volatile ( "" : "+r" (_x) ); _x; })

Irrespective of the question of leading underscores, x wants parenthesizing here.

> +/*
> + * Check that fn(val) can be calcuated by the compiler, and that it gives the
> + * expected answer.
> + */
> +#define COMPILE_CHECK(fn, val, res)                                     \
> +    do {                                                                \
> +        if ( fn(val) != res )                                           \
> +            asm (".error \"Compile time check '" STR(fn(val) == res) "' failed\""); \

Nit: Blanks missing immediately inside the outermost pair of parentheses. (As
per your own reply it's unclear whether this would actually survive.)

> --- a/xen/include/xen/compiler.h
> +++ b/xen/include/xen/compiler.h
> @@ -85,7 +85,8 @@
>  #define inline inline __init
>  #endif
>  
> -#define __attribute_pure__  __attribute__((__pure__))
> +#define __pure  __attribute__((__pure__))

I'd say either there be just a single padding blank or enough to align the
rhs with ...

>  #define __attribute_const__ __attribute__((__const__))
>  #define __transparent__     __attribute__((__transparent_union__))

... these.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 14:14:11 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 14:14:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693269.1081138 (Exim 4.92)
	(envelope-from )
	id 1rklqJ-0006P7-6N; Thu, 14 Mar 2024 14:13:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693269.1081138; Thu, 14 Mar 2024 14:13:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rklqJ-0006P0-3m; Thu, 14 Mar 2024 14:13:59 +0000
Received: by outflank-mailman (input) for mailman id 693269;
 Thu, 14 Mar 2024 14:13:57 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rklqH-0006Ou-Pk
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 14:13:57 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on20601.outbound.protection.outlook.com
 [2a01:111:f403:2412::601])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1773e1bb-e20d-11ee-afdd-a90da7624cb6;
 Thu, 14 Mar 2024 15:13:56 +0100 (CET)
Received: from CH2PR04CA0003.namprd04.prod.outlook.com (2603:10b6:610:52::13)
 by CH3PR12MB8331.namprd12.prod.outlook.com (2603:10b6:610:12f::10)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.20; Thu, 14 Mar
 2024 14:13:52 +0000
Received: from DS2PEPF0000343E.namprd02.prod.outlook.com
 (2603:10b6:610:52:cafe::43) by CH2PR04CA0003.outlook.office365.com
 (2603:10b6:610:52::13) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.20 via Frontend
 Transport; Thu, 14 Mar 2024 14:13:52 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 DS2PEPF0000343E.mail.protection.outlook.com (10.167.18.41) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7386.12 via Frontend Transport; Thu, 14 Mar 2024 14:13:52 +0000
Received: from SATLEXMB08.amd.com (10.181.40.132) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 14 Mar
 2024 09:13:51 -0500
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB08.amd.com
 (10.181.40.132) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 14 Mar
 2024 07:13:51 -0700
Received: from [172.17.162.8] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Thu, 14 Mar 2024 09:13:51 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1773e1bb-e20d-11ee-afdd-a90da7624cb6
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=OX5bxpBE1K8qGm27nPc6kHCiWIvBBm7Jtm90eHv6p+0wmSDcPX/PbEky9ELxLpPvpNO4KNNfz1dp2BO6MCb8TBlO5cw+5N+YCBPHqg6bXLLc8ROv6YCL5YRkqcKUqpq77fScrTwxUDZJeeuiLYk5vr9CAE5Gn0UmVH9s0rCXesfGwHV5/rkoPuTW0S0sHu5+Jtr8eFmXgGUTXbvhikEM17yqr9jeixRcOXikn3+YrI7sIFSSdzFcK855zCl/nykvXqmCuX2b4Rahewh8jLEwhNiWDwAqkhd5TQvQa7iltamTIxCzzeXauy0DlvnIvr1Jd5tIAyWyJ8Fk5YR9QCkU6g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=R5wTw/V01G9PPcilKrECgw44W63dKh2A+HwVEmxQPNg=;
 b=bKSHeEZJl4ZDZh6rAyj2H6OGFEFuFeepoekibOXEoqsUVD5mrJXf6RXJzDk3KCW4+bR48ceBX1fSRTqLKffPxRhFFYfQea/bORxhZyKaB6+sW5FsFIwqKaQ1pgbqiEdKFXLFmJSTNgNNRhhusLYTLjlA6U1wWgjWxM53GuBQ1EJ4vcl9BsltuXcQYdk7tnqK35VR0EJ0ZpnJ88nfPbt6aKPucTD4msx+BUp07YJBtS3ipmdYE5a+w3PECDHCj52wyNn8QtcDF4BOYZVPHvOsg8e9/dFMQYzggPBTxuEpz3sNdlvlAgWnhQm2P55w13zdct6WbD9XeF+bq1NZ785XBA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=R5wTw/V01G9PPcilKrECgw44W63dKh2A+HwVEmxQPNg=;
 b=vlFTSoMHeeid1U8TzthzFeUki/aVFgS89Sy0rwbREU6BQJOdBqj9UoAHGq96TOjkdNBN7kmc/sUJ2bDzUqrdLovmy1URmkS0Sa576AoSDPSmweELfgfDR7iQxLwA5ddYHCZVBIvkySH6IYz9wrnMpRlsJihVpx96skWvXCpYMRk=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
Message-ID: 
Date: Thu, 14 Mar 2024 10:13:52 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 3/3] x86/PVH: Support relocatable dom0 kernels
Content-Language: en-US
To: Jan Beulich 
CC: Andrew Cooper ,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu
	, George Dunlap , Julien Grall
	, Stefano Stabellini ,
	
References: <20240313193021.241764-1-jason.andryuk@amd.com>
 <20240313193021.241764-4-jason.andryuk@amd.com>
 <945609d6-741e-4934-a4f2-6e5597ce5dcd@suse.com>
From: Jason Andryuk 
In-Reply-To: <945609d6-741e-4934-a4f2-6e5597ce5dcd@suse.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DS2PEPF0000343E:EE_|CH3PR12MB8331:EE_
X-MS-Office365-Filtering-Correlation-Id: 23695a0f-a963-4ef8-89b7-08dc4430fa15
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	aM9aeTCv7ZSl2UGGUrDGSvz9sgdn0MJxOZUsIyViui295K73LXYcw7NVTLVo1a2yn6HpKZwjB+RhpmjD71OArfrP/HR3Y+ZepNfoOVGc+KklHeV+e5UW7pYHQfrzI5fUmMVSI7z//6pHTfDbltVxPeb4bMTTDfhjAUo/Rhww12WRsVK8M0VaIGXRPl73kffg09SUGBv5gx5QXY8RnnAOGgZxOnw47WQEHVWhvKYJcc1jmrrHI/UrnWaPv7J1Z1TDQNXabXOfosM9Jdeg3aG2vM9XRC4l4kxesRYcEzdH0chtUrST403XHFioly7n8MvCOIFwenIazMbFnYcMTJO2n6i/gVTZdrEMflcF0uXC0DSOcspwm2ymDOml0S3J7KzmkX3S62FOYffluPq0sd/jlFL6jHnIbJ9rQeyJzDkz19XUNH7wS1ySsady5SS2s0/0UWuXcNnRP4zzUh9we8y1yGc4x1+Nlswv2TK1wPnICtz7uZtt38+Tk7W3fsDpvpTTKYxUQJkm/1iRBFOUzeVR6dVSCdRxXtnmW1oRVJBFB5tGBAgCGViJibO59sy7Zlox1XNtoxr+cBDhQ7UoAGAKaDDRAhEc1p2RSdViSTqiJrVtMYNU+0QXk04PmKTMSdHoNTwu4H4ZMTdgZqJM1DCR3R7WLULnRLocRw2q7wHAGjshMp3eXvVYNAleWUqqSIKB9es+JzBR9bj5ZGrbGhNbiwyMDD/ALrd/KOFsyyrp/6Ozxz2wO4iSGHg8beGB4PR3
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(36860700004)(1800799015)(82310400014)(376005);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Mar 2024 14:13:52.3664
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 23695a0f-a963-4ef8-89b7-08dc4430fa15
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DS2PEPF0000343E.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB8331

On 2024-03-14 09:21, Jan Beulich wrote:
> On 13.03.2024 20:30, Jason Andryuk wrote:
>> --- a/xen/include/public/elfnote.h
>> +++ b/xen/include/public/elfnote.h
>> @@ -194,6 +194,17 @@
>>    */
>>   #define XEN_ELFNOTE_PHYS32_ENTRY 18
>>   
>> +/*
>> + * Physical loading constraints for PVH kernels
>> + *
>> + * Used to place constraints on the guest physical loading addresses and
>> + * alignment for a PVH kernel.  This note's value is 3 64bit values in
>> + * the following order: minimum, maximum and alignment.
> 
> Along the lines of what I said on another sub-thread, I think at least
> alignment wants to be optional here. Perhaps, with max going first, min
> could also be optional.

Interesting idea.

> As indicated in different context by Roger, the values being uniformly
> 64-bit ones also is questionable.
> 
>> + * The presence of this note indicates the kernel is relocatable.
> 
> I think it wants making explicit here that the act of relocating is still
> left to the kernel.

Ok.

How is this for a new description?

"""
Physical loading constraints for PVH kernels

Used to place constraints on the guest physical loading addresses and 
alignment for a PVH kernel.

The presence of this note indicates the kernel supports relocating itself.

The note may include up to three 32bit values.
  - a maximum address for the entire image to be loaded below (default 
0xfffffff)
  - a minimum address for the start of the image (default 0)
  - a required start alignment (default 1)
"""

I think if we can agree on the ELF note, the rest will fall into place.

Thanks,
Jason


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 14:16:21 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 14:16:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693271.1081147 (Exim 4.92)
	(envelope-from )
	id 1rklsZ-00078p-IW; Thu, 14 Mar 2024 14:16:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693271.1081147; Thu, 14 Mar 2024 14:16:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rklsZ-00078i-Fv; Thu, 14 Mar 2024 14:16:19 +0000
Received: by outflank-mailman (input) for mailman id 693271;
 Thu, 14 Mar 2024 14:16:18 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rklsY-00078c-9Z
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 14:16:18 +0000
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com
 [2a00:1450:4864:20::635])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6b4b14a6-e20d-11ee-a1ee-f123f15fe8a2;
 Thu, 14 Mar 2024 15:16:16 +0100 (CET)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-a466381b411so118311966b.2
 for ; Thu, 14 Mar 2024 07:16:16 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 qs28-20020a170906459c00b00a4550e8ae70sm755944ejc.63.2024.03.14.07.16.14
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 14 Mar 2024 07:16:15 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6b4b14a6-e20d-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710425775; x=1711030575; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=imitLls3Iml+yz8NLBOmoFjmf4ds0peculVdTuXhQEM=;
        b=ELyDaQV7WnXRMiIAaLCKyHVQMwMKd625lrp5ZqV07WkLf0i2BdVd4v8EQ3jGjGfwH8
         kXzeTzWVFLKj+ocSiFgR4bos/yJq/7EhinjeOYQmkd0t+GmLUEpUoDjhq4aOsQ9YIT6r
         +6gM0X2FDYwvz50b5HI9qFQN63OZEXBIR7cT2VAxh84NCIKsm73NZC0R6NzishbvrOh9
         aY7MkedrhGln+kgM6BlATpUdZUlFJ/YAxkSzeF8WcXuVK1sd8fUQbpOTZaZDJ5oiXn44
         PabZzf16W+BDUcqZlHBIXYKr02EYX3WxSTmGBhj6FNpFOzjtqd0mPrbb6ixfIY4kR1nl
         NOSA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710425775; x=1711030575;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=imitLls3Iml+yz8NLBOmoFjmf4ds0peculVdTuXhQEM=;
        b=GQGt0OYln8ONs+OY+MEeaRDpGiWEZrHutG7xGYbXK8Lf90KiahJeHRwnRUpETVBw0q
         Noy9oQE5ltKKBDIJjuZhA2FD20TSxusFWKxuXUu78/EE/QTkZvXcZnvk4wSQGN/wD0W8
         xDkuTO9IQw+t7GvEd95N5zjfXuDQPdXtRIFagM+yVTp4CKEwUfk145pxAwUF4t0ur3xh
         rBNRTh0sfIoT3KYKMDMzLLB3bK82z2qFwgqn5ZRBHrBBAb7Z4bJjjq5QtS7OFtrQXjVP
         muDLYOhLtQLlNFAdnfqlyCxWBWvdq4rJVNwuu49YA11LwX37L72JIjum/LGPkYUmPKfE
         IN8Q==
X-Forwarded-Encrypted: i=1; AJvYcCWqlBbuAzaslhfVbRbyIPgXOBocyVJK764HteivROle15B5a73RnXQOpTcmsns+i6fXiHDlzz5pwYfYBoLVGiiAx2S4e7NuIrapUmwKOAU=
X-Gm-Message-State: AOJu0YwJITsH2LUfGCgzWUnL9nUNIZm0ouBSIr8w+b5ZtQI7PWek67pG
	ghdKAz9BKNQfoUqINOJ9Qw8RvRbyzWMf5cGtY0ypDOZsO5ZWznJvExbwEOJJtg==
X-Google-Smtp-Source: AGHT+IGsvL/wr3RjqyuVvH5rKRhKBzNE1OlHkuczQufEM5OD/OAhhclESnIszZUBkH6kRwORALOONA==
X-Received: by 2002:a17:906:6899:b0:a44:7bbe:d774 with SMTP id n25-20020a170906689900b00a447bbed774mr759918ejr.9.1710425775394;
        Thu, 14 Mar 2024 07:16:15 -0700 (PDT)
Message-ID: <76a1e81d-86d1-438c-975e-c4db46af93ee@suse.com>
Date: Thu, 14 Mar 2024 15:16:13 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/7] xen/bitops: Implement ffs() in common logic
Content-Language: en-US
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Wei Liu , Stefano Stabellini ,
 Julien Grall , Volodymyr Babchuk
 , Bertrand Marquis ,
 Michal Orzel ,
 Oleksii Kurochko ,
 Shawn Anastasio ,
 "consulting @ bugseng . com" ,
 Simone Ballarin ,
 Federico Serafini ,
 Nicola Vetrini ,
 Xen-devel 
References: <20240313172716.2325427-1-andrew.cooper3@citrix.com>
 <20240313172716.2325427-3-andrew.cooper3@citrix.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240313172716.2325427-3-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 13.03.2024 18:27, Andrew Cooper wrote:
> --- a/xen/arch/arm/include/asm/bitops.h
> +++ b/xen/arch/arm/include/asm/bitops.h
> @@ -157,7 +157,7 @@ static inline int fls(unsigned int x)
>  }
>  
>  
> -#define ffs(x) ({ unsigned int __t = (x); fls(ISOLATE_LSB(__t)); })
> +#define arch_ffs(x) ({ unsigned int __t = (x); fls(ISOLATE_LSB(__t)); })

The way the macro is invoked, I don't think the helper local variable
is then needed anymore?

> --- a/xen/arch/x86/include/asm/bitops.h
> +++ b/xen/arch/x86/include/asm/bitops.h
> @@ -430,16 +430,23 @@ static inline int ffsl(unsigned long x)
>      return (int)r+1;
>  }
>  
> -static inline int ffs(unsigned int x)
> +static inline unsigned int arch_ffs(unsigned int x)
>  {
> -    int r;
> +    int r = -1;
> +
> +    /*
> +     * The AMD manual states that BSF won't modify the destination register if
> +     * x=0.  The Intel manual states that the result is undefined, but the
> +     * architects have said that the register is written back with it's old
> +     * value, possibly zero extended above 32 bits.
> +     */
> +    asm ( "bsf %[val], %[res]"
> +          : [res] "+r" (r)
> +          : [val] "rm" (x) );

And this isn't what the compiler would be doing anyway?

Also, just to mention it: I take it that you/we are sure that disallowing
both operands to be the same register is still better than ...

> -    asm ( "bsf %1,%0\n\t"
> -          "jnz 1f\n\t"
> -          "mov $-1,%0\n"
> -          "1:" : "=r" (r) : "rm" (x));

... the original form?

> --- a/xen/common/bitops.c
> +++ b/xen/common/bitops.c
> @@ -34,8 +34,18 @@
>          RUNTIME_CHECK(fn, val, res);            \
>      } while ( 0 )
>  
> +static void test_ffs(void)

Nit: __init please, even if there ought to be no reason for the compiler
to not inline this function.

> --- a/xen/include/xen/bitops.h
> +++ b/xen/include/xen/bitops.h
> @@ -110,6 +110,21 @@ static inline int generic_flsl(unsigned long x)
>  
>  #include 
>  
> +/*
> + * Find First Set bit.  Bits are labelled from 1.
> + */
> +static always_inline __pure unsigned int ffs(unsigned int x)

Why always_inline?

> +{
> +    if ( __builtin_constant_p(x) )
> +        return __builtin_ffs(x);
> +
> +#ifndef arch_ffs
> +#define arch_ffs __builtin_ffs
> +#endif
> +
> +    return arch_ffs(x);
> +}

Just to mention it: __builtin_ffs() takes and returns plain int. I'm
happy about our own helper being unsigned-correct, but anything like
this has a Misra angle too.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 14:19:41 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 14:19:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693275.1081157 (Exim 4.92)
	(envelope-from )
	id 1rklvk-0008ML-Vs; Thu, 14 Mar 2024 14:19:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693275.1081157; Thu, 14 Mar 2024 14:19:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rklvk-0008ME-TL; Thu, 14 Mar 2024 14:19:36 +0000
Received: by outflank-mailman (input) for mailman id 693275;
 Thu, 14 Mar 2024 14:19:35 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rklvj-0008M8-Fr
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 14:19:35 +0000
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com
 [2a00:1450:4864:20::22a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e105b0a2-e20d-11ee-a1ee-f123f15fe8a2;
 Thu, 14 Mar 2024 15:19:33 +0100 (CET)
Received: by mail-lj1-x22a.google.com with SMTP id
 38308e7fff4ca-2d28051376eso11642361fa.0
 for ; Thu, 14 Mar 2024 07:19:33 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 k11-20020aa7c38b000000b005684fa1c4dbsm763553edq.52.2024.03.14.07.19.32
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 14 Mar 2024 07:19:32 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e105b0a2-e20d-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710425973; x=1711030773; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=8VV/7UStmUOrNQMmzxeCw9icNXOCDteX0ZLA/7seFCg=;
        b=af3QS0ViR+4unAggB876dsNRmEMitLanWPsK7jOk0rfNUo2BzQ+NL4VzbM7/y1HJw6
         PKa9NFsIw5OVSC28k70bUU9dtDnspMPkua4Njroi+TQQgmFAV/LajeZwnGYh1qg/x8KT
         mJClxUl3qXX3n6mOKzStw9psb03S57KlL8euPO9G6us0taltm9Kt9m7ch0exSICoTrVl
         9VAlQP3uMZKISQceKXUie7KzwMtrJ7poPOEkSHJhwhoH66WowCja8fKPwIh65t9NibBy
         hhtmf4RG7T4Kk8q2IKUIE1TwMQEfSKXV5IFI2VLRGI41Drk/LIiAo7TwSrrqtRYtDk0b
         JYFw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710425973; x=1711030773;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=8VV/7UStmUOrNQMmzxeCw9icNXOCDteX0ZLA/7seFCg=;
        b=v2xej57aQUh7KwRLsXvAJ9C43Yjzfi+xz2ebKtCC1Lu9R8lGm1/YiCnvUSj6w0szfL
         b70+kfgjZTyPLBrkGZn38SUNgvojbL4KEfHV1IXsHzrg9Kd0SKxDtJpwxmchSgOPtFGn
         xRtxJqez9MmTmbXTSEoGN9E7ySd3CSqRFCSIB9z4aMVEOa02zjY02xogPIa0zEyBfWcN
         CrGxz3gR1HXaURvHUhqjuslTnQaWWbsqtjxA4j3+y00+jScbcdZLGb0agkUPdlzlXTOm
         c/4KJG3UE8zw5R7fu4Xmntdvgla7sEdzKeGWfoEhwVEEvNSS4a3FHQj5rT+FfUUTrdIL
         qxzQ==
X-Forwarded-Encrypted: i=1; AJvYcCWDBgIeKH3+Y4YsCW3ch/eYcG3lMNlCCZrRZgpT3CnjpQ36EIIb+xARJdhunhLjFspo1TkOIi8WjcT8F3eGU/hbQnC/hEEgsW9TGLMyiRg=
X-Gm-Message-State: AOJu0YwDK8tkSt/WYM8H2q0nIWVauryhO67XVS3DqJDAy3OtqwiTnh3o
	TQq45fhNvnmEKoKK/52J1YsjmNfeqb4eNS7qtypl73Qk/koVaz95BLJMdMgm+g==
X-Google-Smtp-Source: AGHT+IE0ull/N5JIyjy4s7JChuo1XtdH8I3NYhDUEl2j8kbE5D75Q1ZqSf+CVwjAmLtbZrXMVoKNPw==
X-Received: by 2002:a05:651c:1039:b0:2d4:3e96:47ee with SMTP id w25-20020a05651c103900b002d43e9647eemr106264ljm.26.1710425972794;
        Thu, 14 Mar 2024 07:19:32 -0700 (PDT)
Message-ID: <43c49aa6-d690-467e-8ce3-ca37b9d41e76@suse.com>
Date: Thu, 14 Mar 2024 15:19:31 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 3/3] x86/PVH: Support relocatable dom0 kernels
Content-Language: en-US
To: Jason Andryuk 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu
 , George Dunlap ,
 Julien Grall , Stefano Stabellini ,
 xen-devel@lists.xenproject.org
References: <20240313193021.241764-1-jason.andryuk@amd.com>
 <20240313193021.241764-4-jason.andryuk@amd.com>
 <945609d6-741e-4934-a4f2-6e5597ce5dcd@suse.com>
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 14.03.2024 15:13, Jason Andryuk wrote:
> On 2024-03-14 09:21, Jan Beulich wrote:
>> On 13.03.2024 20:30, Jason Andryuk wrote:
>>> --- a/xen/include/public/elfnote.h
>>> +++ b/xen/include/public/elfnote.h
>>> @@ -194,6 +194,17 @@
>>>    */
>>>   #define XEN_ELFNOTE_PHYS32_ENTRY 18
>>>   
>>> +/*
>>> + * Physical loading constraints for PVH kernels
>>> + *
>>> + * Used to place constraints on the guest physical loading addresses and
>>> + * alignment for a PVH kernel.  This note's value is 3 64bit values in
>>> + * the following order: minimum, maximum and alignment.
>>
>> Along the lines of what I said on another sub-thread, I think at least
>> alignment wants to be optional here. Perhaps, with max going first, min
>> could also be optional.
> 
> Interesting idea.
> 
>> As indicated in different context by Roger, the values being uniformly
>> 64-bit ones also is questionable.
>>
>>> + * The presence of this note indicates the kernel is relocatable.
>>
>> I think it wants making explicit here that the act of relocating is still
>> left to the kernel.
> 
> Ok.
> 
> How is this for a new description?
> 
> """
> Physical loading constraints for PVH kernels
> 
> Used to place constraints on the guest physical loading addresses and 
> alignment for a PVH kernel.
> 
> The presence of this note indicates the kernel supports relocating itself.
> 
> The note may include up to three 32bit values.

I'm as unsure about always 32-bit as I am on it being uniformly 64-bit.
One question here is whether this note is intended to be x86-specific.

>   - a maximum address for the entire image to be loaded below (default 
> 0xfffffff)

One f too few?

>   - a minimum address for the start of the image (default 0)
>   - a required start alignment (default 1)
> """
> 
> I think if we can agree on the ELF note, the rest will fall into place.

Presumably, yes.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 14:19:52 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 14:19:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693276.1081168 (Exim 4.92)
	(envelope-from )
	id 1rklw0-0000J2-AZ; Thu, 14 Mar 2024 14:19:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693276.1081168; Thu, 14 Mar 2024 14:19:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rklw0-0000Iv-7s; Thu, 14 Mar 2024 14:19:52 +0000
Received: by outflank-mailman (input) for mailman id 693276;
 Thu, 14 Mar 2024 14:19:51 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rklvz-0008M8-Hp
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 14:19:51 +0000
Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com
 [2607:f8b0:4864:20::733])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id eaa3a229-e20d-11ee-a1ee-f123f15fe8a2;
 Thu, 14 Mar 2024 15:19:50 +0100 (CET)
Received: by mail-qk1-x733.google.com with SMTP id
 af79cd13be357-789ddcd57f4so19760785a.2
 for ; Thu, 14 Mar 2024 07:19:50 -0700 (PDT)
Received: from localhost ([85.31.135.62]) by smtp.gmail.com with ESMTPSA id
 ay16-20020a05620a179000b00789d57f93c2sm787822qkb.88.2024.03.14.07.19.47
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 14 Mar 2024 07:19:48 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: eaa3a229-e20d-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710425989; x=1711030789; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=jBIFqTTJjpfDnSIlnYU2CZlKU457KwTvVqvgW6/Lj+8=;
        b=iZhwyTHfvQyxBVk6VNVtq1I6QM14Em2PwDUt3PWIUXjl7jtEN4R6vstmtrM6y+/vD2
         N6zptivK1IU4eyjcnbRdInOYw5/xToWwwLoIK/Rafgvp3UCHn6AyDpibPch1JFB4atdD
         wjcpYvQiEDu4HaiinmyRoJnSx3IoVFgMEvGSc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710425989; x=1711030789;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=jBIFqTTJjpfDnSIlnYU2CZlKU457KwTvVqvgW6/Lj+8=;
        b=D4XJvS5G3+4qPM4vXflyTJZfxuPxyAKqStnYe/DZ/QtajHv+yifeKecbINBFfo6BQB
         cfZEKGLdv7lDVDuS8CE4JaiDaqEDwwKOvEvfW8pH9OggsSXxTyrJlT+zZDUvJZdqmLzu
         lNU+u9eUE5E++76kGaVljqYTe5TW0xy1bT6lgPH8MIvuIixCjO3FoAC3DDVJU4GV+tTX
         HMycCyKzJsgqU9N8WYvmhyeVpIN2ChvWNuE4x0vjOHnhudTf8rqgQ+0bTr8CpSLFc+Bn
         3XIZnHQp1F/n71XISMGLOlxkv3IiwgrApqWKPdkRi2qiEJK7TvG+3wKvw/tdCHKfWZKf
         RzgA==
X-Gm-Message-State: AOJu0YwkGiKxizs7gxQxIqhBo206rv3dJ3llA/WDOxPZcZ9kd6Hfk/nX
	/EHlJ2odY+zMLAC1upCbn1c5YBs1VZ0Dv32b8hQrikudOef60kDmgR2z53x8yQmIVBGVodlXS/4
	E
X-Google-Smtp-Source: AGHT+IFCI7irLPQzEKE5CbghjfxpbJc1VgM7Z2ocaZNyjc1TXbwcj0Z/BakfUJM5wxgDT12goCdAjQ==
X-Received: by 2002:a05:620a:817:b0:788:2e47:b297 with SMTP id s23-20020a05620a081700b007882e47b297mr1993595qks.78.1710425988737;
        Thu, 14 Mar 2024 07:19:48 -0700 (PDT)
Date: Thu, 14 Mar 2024 15:19:46 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: flyingpenghao@gmail.com
Cc: xen-devel@lists.xenproject.org, Peng Hao 
Subject: Re: [PATCH v2] xen/blkback: use kmap_local_page()
Message-ID: 
References: <20240314132843.24069-1-flyingpeng@tencent.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20240314132843.24069-1-flyingpeng@tencent.com>

On Thu, Mar 14, 2024 at 09:28:43PM +0800, flyingpenghao@gmail.com wrote:
> From: Peng Hao 
> 
> Use kmap_local_page() instead of kmap_atomic() which has been
> deprecated.
> 
> Signed-off-by: Peng Hao 

Acked-by: Roger Pau Monné 

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 14:23:05 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 14:23:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693281.1081179 (Exim 4.92)
	(envelope-from )
	id 1rklz5-0002Jq-QT; Thu, 14 Mar 2024 14:23:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693281.1081179; Thu, 14 Mar 2024 14:23:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rklz5-0002Jj-M0; Thu, 14 Mar 2024 14:23:03 +0000
Received: by outflank-mailman (input) for mailman id 693281;
 Thu, 14 Mar 2024 14:23:02 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rklz4-0002Jd-Bj
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 14:23:02 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on20600.outbound.protection.outlook.com
 [2a01:111:f403:2416::600])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 59d10820-e20e-11ee-afdd-a90da7624cb6;
 Thu, 14 Mar 2024 15:23:01 +0100 (CET)
Received: from BN9P221CA0027.NAMP221.PROD.OUTLOOK.COM (2603:10b6:408:10a::21)
 by PH7PR12MB6787.namprd12.prod.outlook.com (2603:10b6:510:1ad::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.36; Thu, 14 Mar
 2024 14:22:52 +0000
Received: from BN1PEPF00004680.namprd03.prod.outlook.com
 (2603:10b6:408:10a:cafe::1c) by BN9P221CA0027.outlook.office365.com
 (2603:10b6:408:10a::21) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.20 via Frontend
 Transport; Thu, 14 Mar 2024 14:22:52 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 BN1PEPF00004680.mail.protection.outlook.com (10.167.243.85) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7386.12 via Frontend Transport; Thu, 14 Mar 2024 14:22:52 +0000
Received: from SATLEXMB08.amd.com (10.181.40.132) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 14 Mar
 2024 09:22:51 -0500
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB08.amd.com
 (10.181.40.132) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 14 Mar
 2024 07:22:51 -0700
Received: from [172.31.100.92] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Thu, 14 Mar 2024 09:22:49 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 59d10820-e20e-11ee-afdd-a90da7624cb6
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=Wjz7BtwncGPKeICgjbJ2O+KTIsRtbl6x+dQmYxsup/BGwmaxsmFMkEWNBzRWWWGzkSoGTzfVQDkXmTdXxSh+WEh5tIWcn0RzNTKjbKmZ7n2CvijpYEl6FskOmE4/uksFqw1ulRqV9tjpANJm3h09MspLf0Zy4NxLBnSQ09Bve0vRa75zqDHQsNbj141FMPIUVAz9iQm+lUPztETcEmsBMheHw5cnGr9dNe86mjfif3gdqdvJ+CuP68IUcheCXrBOBEhcwNLFSKfSYxdU4UsyHJv/ud3+5c6EDTGNCuneHq14s1y8xltkkVdXJ4TiwXZoJPdqHzpH780zybO/JJWegA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=r7kvXzE3vgZ5ZBPCne65+lAl7sJC9Zn4ki+5/yEAF4A=;
 b=WKmtrqGkJR3X+In0+gWCHvW8d6ajQpWHl6kbQFU5umEHZexe6KHw+xg07di4IyV7BvsfUFHQnys3qikavg4lzQcHyKaM8GdHvYAAB0AFizAwUpbx61DpIHNesIl63Jscet/ZwMQlCueHO3AxnL39xZZres2huLC7E1EeFQs/CKlCvjb1/HcGADHWdWNvy0KStdGm21ZwITZQx7fKhc+m99bUsqkQmy5qjB2m5UYQbWeKfHz18W+UYy6j0zsknmkVG1VM62f+QKG8/MwotItXMxxF2WYz2Fw5x+l20Bo3k/LFbTrO8lAYTpT65C6bVkBwag8u1cbDASGyq8DPO/yoBw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=xen.org smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=r7kvXzE3vgZ5ZBPCne65+lAl7sJC9Zn4ki+5/yEAF4A=;
 b=MwDEb64+Mb3gU8NRGQ+2Hi3EAaPpEza6hlj1gbjTW7EZcAmPqO3toF6OriBQCVljgIV3sdpjFgQPpRFWNBNUAZenwwsDRfd0i72icWcNy13X+tk7q8f+P1zXI19ZR/Ti6cKTC1scDBZJinHh33AmcQawV9I77W45lvY4nI3qsDs=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
Message-ID: <16838c64-c633-4125-9388-af02e18a89be@amd.com>
Date: Thu, 14 Mar 2024 22:22:48 +0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] xen/arm: Set correct per-cpu cpu_core_mask
To: Julien Grall , ,
	
CC: Stefano Stabellini , Bertrand Marquis
	, Michal Orzel , "Volodymyr
 Babchuk" , Henry Wang 
References: <20240228015822.56108-1-xin.wang2@amd.com>
 <77520838-67cb-4755-8b02-2ec8b90c7bfa@xen.org>
Content-Language: en-US
From: Henry Wang 
In-Reply-To: <77520838-67cb-4755-8b02-2ec8b90c7bfa@xen.org>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN1PEPF00004680:EE_|PH7PR12MB6787:EE_
X-MS-Office365-Filtering-Correlation-Id: 523380af-343a-4f7d-53d6-08dc44323bc5
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	UQpNxn2UTDEMqrVLrd5gcy4pM5QflLZkzmLsp5vnUTDL10QIUtFAVbpVDmv9jS4dMxkNZ5qp7cYWYnshOQEV3b+lo2ypBCu3kzIK79cwGZEltmc46JAIRI9BrMLqgE+FKHkvQg4ZdnedOuoiTGZp0DGi7US7BPfIFVgLdgiPP8KipknJdON0X8BZ3DSra2q58fSm3hP/yB6q5vng8Avscp+tt1AhW8W/dnpH9kjbBTBmSXzPY6+i5PBU9xd9G8FiT0A91kgEmGU7x7YHpIAaWwmCyQaS8k2WB39kierOQTeU7EjwmniEfq0om6UO0qjybtgcTeLQbdq3C5VJosX0FS4yaPV/qHHO1lCBbf4YpECYsfKv3FAvioBBO8nHdfza9Jm8yjPSswT4qZCpRgkkW42xo9M/mn0xwb/QFuUpI26/9lIS6wp6E7Wz2+Te/fWCSOFav/KqoqyOU3K+vL43nJmjhlUx3v8gQo30jRv3ZwUoiJwbL2i/+tujCusgifrGtnl1f4N6Ks6/mTMW57nMzvHPe/TZvUv01/5oDMrh+foTjn2PbNolZiXQMV/YL1bSHZDOZBCiVZrSs4OhTMW5b+PI3CwZ9OsGd4reySvMQHrXqulhE0bsj1efnE3OChRntWmzg1fQgfN8bmXZpO1NRDZWz+O0qee6vut+tzAuCprFiC1DOb/JnKkcJ3AtbG3Hzp7u3e+ynG6aLMNgd5xAFhDmk4HBfyf14xXUVtt8SBG3aY/nKdloH74MegbS5sQ7
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(376005)(82310400014)(36860700004)(1800799015);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Mar 2024 14:22:52.1140
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 523380af-343a-4f7d-53d6-08dc44323bc5
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN1PEPF00004680.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB6787

Hi Julien,

On 3/14/2024 9:27 PM, Julien Grall wrote:
> Hi Henry,
>
> On 28/02/2024 01:58, Henry Wang wrote:
>> diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
>> index a84e706d77..d9ebd55d4a 100644
>> --- a/xen/arch/arm/smpboot.c
>> +++ b/xen/arch/arm/smpboot.c
>> @@ -66,7 +66,6 @@ static bool cpu_is_dead;
>>     /* ID of the PCPU we're running on */
>>   DEFINE_PER_CPU(unsigned int, cpu_id);
>> -/* XXX these seem awfully x86ish... */
>
> :). I guess at the time we didn't realize that MT was supported on 
> Arm. It is at least part of the spec, but as Michal pointed out it 
> doesn't look like a lot of processors supports it.

Yep. Do you think changing the content of this line to something like 
"Although multithread is part of the Arm spec, there are not many 
processors support multithread and current Xen on Arm assumes there is 
no multithread" makes sense to you?

>>   /* representing HT siblings of each logical CPU */
>>   DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_sibling_mask);
>>   /* representing HT and core siblings of each logical CPU */
>> @@ -89,6 +88,10 @@ static int setup_cpu_sibling_map(int cpu)
>>       cpumask_set_cpu(cpu, per_cpu(cpu_sibling_mask, cpu));
>>       cpumask_set_cpu(cpu, per_cpu(cpu_core_mask, cpu));
>>   +    /* Currently we assume there is no multithread. */
>
> I am not very familiar with the scheduling in Xen. Do you know what's 
> the consequence of not properly supporting MT? One thing I can think 
> of is security (I know there were plenty of security issues with SMT).

Unfortunately me neither, so adding George to this thread as I think he 
can bring us some insights on this topic from the scheduler perspective.

> Depending on the answer, I would consider to print a warning and maybe 
> add it in SUPPORT.MD in a separate patch.

To be honest, as discussed in v1. I think I am quite tempted to add an 
ASSERT(system_cpuinfo.mpidr.mt == 0) to make sure we catch the 
multithread support stuff earlier. I don't really know what will happen 
if running current Xen on top of a multithread-implemented processor, 
probably it will be fine, but probably some strange behavior will happen 
after the boot time which I think will be difficult to debug...

> Also, looking at the v1 discussion, it sounds like even 
> cpu_sibling_mask would not be correct. So I think it would make sense 
> to move the comment on top of setup_cpu_sibling_map.

Sounds good. I will move it in v3.

>> +    cpumask_or(per_cpu(cpu_core_mask, cpu),
>> +               per_cpu(cpu_core_mask, cpu), &cpu_possible_map);
>
> AFIACT, per_cpu(cpu_core_mask, ...) will now be equal to 
> cpu_possible_map. In that case, wouldn't it be better to simply copy 
> the cpumask?

You mean cpumask_copy(per_cpu(cpu_core_mask, cpu), &cpu_possible_map)? 
Good question...I forgot if there was a reason behind this back to the 
time I wrote this patch (it is likely just me being silly). But yes 
definitely I can do this way in v3.

> This would also allow to drop cpumask_set_cpu(..., cpu_core_mask) above.

Good point. I will drop in v3.

Kind regards,
Henry

>
> Cheers,
>



From xen-devel-bounces@lists.xenproject.org Thu Mar 14 14:24:51 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 14:24:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693283.1081187 (Exim 4.92)
	(envelope-from )
	id 1rkm0l-0002re-40; Thu, 14 Mar 2024 14:24:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693283.1081187; Thu, 14 Mar 2024 14:24:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkm0l-0002rX-1M; Thu, 14 Mar 2024 14:24:47 +0000
Received: by outflank-mailman (input) for mailman id 693283;
 Thu, 14 Mar 2024 14:24:45 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkm0j-0002rN-UJ
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 14:24:45 +0000
Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com
 [2a00:1450:4864:20::235])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9ab345bb-e20e-11ee-afdd-a90da7624cb6;
 Thu, 14 Mar 2024 15:24:44 +0100 (CET)
Received: by mail-lj1-x235.google.com with SMTP id
 38308e7fff4ca-2d208be133bso13972551fa.2
 for ; Thu, 14 Mar 2024 07:24:44 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9ab345bb-e20e-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710426284; x=1711031084; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=eE9q4Q01UYQYqY5fwC6tqKiprWoMreG95et3p+5+Q9k=;
        b=KTDcODzP5HiUjbTJs4dhEzxXDIzQYlGyDESxAj1bcaqEkchZON6t6DglJwHem8kUwZ
         BqNdTnk3VbhpUyovzEuZ1ddz4NqrUkXStdQ+ZOWYlhOYKJoGk0qmSuW6y1CNgTUQJWv+
         hTDB118CVq3YDl7QRGYUSYhkfgsgYQRmgq2nI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710426284; x=1711031084;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=eE9q4Q01UYQYqY5fwC6tqKiprWoMreG95et3p+5+Q9k=;
        b=bpEPiQZluoY4K7cWNK326J4pskdThmMA53naD2+tSZlyVlNRoXTxMsbJDtM+CkG5iM
         4IVWDK0oXsb+NvvyKK2yozSYsn11tsQrD5YdZQg0zayFUZ9CRDP6USw5DrxSffHnVK3x
         cm2D0WQ3hEefpSb++U5GLd57T31OrJaDLT2wKD1zVgYLy1TuQzLyxMz4L8YNqobe5h5t
         MQeu/t0FxANb2gPkwP5DCljYlWb2xWmbDPTbBl3vBuokuLEtyc357QYPumZHichSNFI2
         tN6nowieTq8r8DG+SeUNqkh2Gti8z/njhnbDxxKQkmXQaKTaVhIqilmnZ+YTe+F8jBhT
         KnRw==
X-Gm-Message-State: AOJu0YxOsKzbhIXjP/xMlVsl9lOOkiGUillwvfZo6KnPwr/xqjTfin3p
	aeGNog9RiEYbtNo2xZkpe+WzTDu/V2UAOBcSoTW2o0HOfZId4kvvDMVfGbTN3WNp6uhuicyG5Qf
	BNq+6aebdIV8V2QW+RLCjB1GuUULq5p5+8D4CzzysELIFbbR95EE1
X-Google-Smtp-Source: AGHT+IGvh0qoWbbG2d+SvduVPKKMqsK/Z0ugqZHGsWLdzsNVC5nhhv1ttkMdHOFkyicUGvbNpEM9qot11RQYXjpDaOM=
X-Received: by 2002:a2e:9bc3:0:b0:2d4:4777:e2d8 with SMTP id
 w3-20020a2e9bc3000000b002d44777e2d8mr135371ljj.13.1710426284181; Thu, 14 Mar
 2024 07:24:44 -0700 (PDT)
MIME-Version: 1.0
References: <20240313150748.791236-1-ross.lagerwall@citrix.com>
 <20240313150748.791236-2-ross.lagerwall@citrix.com> 
  
In-Reply-To: 
From: Ross Lagerwall 
Date: Thu, 14 Mar 2024 14:24:31 +0000
Message-ID: 
Subject: Re: [PATCH 1/7] multiboot2: Add load type header and support for the
 PE binary type
To: Jan Beulich 
Cc: xen-devel@lists.xenproject.org, Andrew Cooper , 
	Daniel Kiper , grub-devel@gnu.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Mar 14, 2024 at 1:37=E2=80=AFPM Jan Beulich  wro=
te:
>
> On 14.03.2024 10:30, Ross Lagerwall wrote:
> > On Thu, Mar 14, 2024 at 7:24=E2=80=AFAM Jan Beulich =
 wrote:
> >>
> >> On 13.03.2024 16:07, Ross Lagerwall wrote:
> >>> In addition to the existing address and ELF load types, specify a new
> >>> optional PE binary load type. This new type is a useful addition sinc=
e
> >>> PE binaries can be signed and verified (i.e. used with Secure Boot).
> >>
> >> And the consideration to have ELF signable (by whatever extension to
> >> the ELF spec) went nowhere?
> >>
> >
> > I'm not sure if you're referring to some ongoing work to create signabl=
e
> > ELFs that I'm not aware of.
>
> Something must have been invented already to make Linux modules signable.

Linux module signatures operate outside of the ELF container. In fact,
AFAIK the actual signed content could be anything. The file format is:

* Content (i.e. ELF binary)
* Signature of content in PKCS7 format
* Signature info, including signature length
* Magic marker: "~Module signature appended~\n"

This kind of arrangement does indeed work but it is fragile. Since the
signature is on the entire contents and tools that understand ELF don't
parse the signature, any transformation of the binary (e.g. to
strip out debuginfo) will cause the signature to be lost / invalidated.

Nevertheless, this could still be an option for Xen if this is
deemed to be a preferred solution by others. It would be good to hear
some opinions on this.

>
> > I didn't choose that route because:
> >
> > * Signed PE binaries are the current standard for Secure Boot.
> >
> > * Having signed ELF binaries would mean that code to handle them needs
> > to be added to Shim which contravenes its goals of being small and
> > simple to verify.
>
> Both true, but neither goes entirely without saying, I suppose.
>
> > * I could be wrong on this but to my knowledge, the ELF format is not
> > being actively updated nor is the standard owned/maintained by a
> > specific group which makes updating it difficult.
>
> And PE/COFF isn't under control of a public entity / group afaik, which
> may be viewed as no better, if not worse.

Agreed, I guess my point was that PE/COFF doesn't need to be updated to
support signing because it already supports it.

Thanks,
Ross


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 14:31:02 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 14:31:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693295.1081198 (Exim 4.92)
	(envelope-from )
	id 1rkm6i-0004qz-S4; Thu, 14 Mar 2024 14:30:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693295.1081198; Thu, 14 Mar 2024 14:30:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkm6i-0004qs-OX; Thu, 14 Mar 2024 14:30:56 +0000
Received: by outflank-mailman (input) for mailman id 693295;
 Thu, 14 Mar 2024 14:30:55 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkm6h-0004qj-63
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 14:30:55 +0000
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com
 [2a00:1450:4864:20::536])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 76222929-e20f-11ee-a1ee-f123f15fe8a2;
 Thu, 14 Mar 2024 15:30:53 +0100 (CET)
Received: by mail-ed1-x536.google.com with SMTP id
 4fb4d7f45d1cf-568a42133d8so648648a12.1
 for ; Thu, 14 Mar 2024 07:30:53 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a4-20020a170906368400b00a44936527b5sm761937ejc.99.2024.03.14.07.30.51
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 14 Mar 2024 07:30:52 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 76222929-e20f-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710426652; x=1711031452; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=DCT1wZkB8l4x4i4dYUX7Zb52JDKuaiCmBD63nWQOknw=;
        b=PnSVz6ZL1Zq+FwqtOu6oV4YBJfGfyzWz5cm/Bgo1O5++Z9xrbe9JFRXavMXpzth4nD
         MySAnU5RSiz4A0NIJMLSlTTRELi97c8bfmVks36jQ/Ctr1vT1IZoEm2vBj+YVWn0eHQJ
         nkEpljuuWuOf+kYzPxopkX8kBfkNXVbZNpbKoOtLspLJ8DmAtNDy1almpSjuXdzHEAvc
         HA3ePc8PpgZrWkPyabigp/yUiFgl1jBSIZBxjFQaGg9w2yxsa/cKgfVlgIYEVgkdqdw3
         Sj2SpszCxowKG7Ng+6sRaPXE3n4FwshZG1kUFCl2mIn5tDLlQFxEpaP0jil+zTm8Diud
         CtVg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710426652; x=1711031452;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=DCT1wZkB8l4x4i4dYUX7Zb52JDKuaiCmBD63nWQOknw=;
        b=Kgj/zyK6hrZuI87TQIaMcRd9gGp+f6HNe8I49+JPFaSmvuaD7ZC+9jRWtztGE519mX
         R7eYlCOqrXsOjLDQhE3I1pye6les9uVr2ZtPxF3P+O0/aHvslOCreAQII8O4OsB5X6x6
         yHGCkMtdzPqRoi8q+LEm4KusUTHzkyhEyq8g/3llG2v3xfF+7p8Os3W5ikDv4aoFfGB2
         WmwJccLk4jKt+7amMosC8zse8vS51wqTlGi/+kyJxSMn3cSr6zstG9ASjLj9Zog6nNqk
         CNDFikhk0lzrb9lxOb5WShH7HP4Nysrz4/NqGhp97VSyg1K1qz8bV9/KlVdoiu/1Xq2V
         ErRw==
X-Forwarded-Encrypted: i=1; AJvYcCVUUuma5gPMk7Dfqz8Q2lQibFif5m/zMCbwpaBPxHaqhdt3M3404CcuHbqj5oEr5d3VixuHgbHxl5g98KzX+bp3yGRC9/rATmjCeDjdUT4=
X-Gm-Message-State: AOJu0Yxty/hzZbVIGvHj5Rg/sR9sq9Iki0hfNJSubWPD6v4lCE6coFok
	xFgoHsawtwI1bGLdOxQr9V+vzPUpNBroeVdxFhRNwXR6idxz/8cnxMCWys1Tvw==
X-Google-Smtp-Source: AGHT+IGf65dEOO2zzR5oTanXDAp4VQjbwxFowMHlsGcYKPQEd0EgRlMFe2Vyxh+f+37ca8Zax1U0kw==
X-Received: by 2002:a17:906:40ca:b0:a45:2e21:c776 with SMTP id a10-20020a17090640ca00b00a452e21c776mr1335826ejk.3.1710426652575;
        Thu, 14 Mar 2024 07:30:52 -0700 (PDT)
Message-ID: 
Date: Thu, 14 Mar 2024 15:30:50 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 6/7] xen: Swap find_first_set_bit() for ffsl() - 1
Content-Language: en-US
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Wei Liu , Stefano Stabellini ,
 Julien Grall , Volodymyr Babchuk
 , Bertrand Marquis ,
 Michal Orzel ,
 Oleksii Kurochko ,
 Shawn Anastasio ,
 "consulting @ bugseng . com" ,
 Simone Ballarin ,
 Federico Serafini ,
 Nicola Vetrini ,
 Xen-devel 
References: <20240313172716.2325427-1-andrew.cooper3@citrix.com>
 <20240313172716.2325427-7-andrew.cooper3@citrix.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240313172716.2325427-7-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 13.03.2024 18:27, Andrew Cooper wrote:
> --- a/xen/drivers/passthrough/x86/iommu.c
> +++ b/xen/drivers/passthrough/x86/iommu.c
> @@ -641,7 +641,7 @@ struct page_info *iommu_alloc_pgtable(struct domain_iommu *hd,
>      if ( contig_mask )
>      {
>          /* See pt-contig-markers.h for a description of the marker scheme. */
> -        unsigned int i, shift = find_first_set_bit(contig_mask);
> +        unsigned int i, shift = ffsl(contig_mask) - 1;

The need for subtracting 1 is why personally I dislike ffs() / ffsl() (and
why I think find_first_set_bit() and __ffs() (but no __ffsl()) were
introduced).

But what I first of all would like to have clarification on is what your
(perhaps just abstract at this point) plans are wrt ffz() / ffzl().
Potential side-by-side uses would be odd now, and would continue to be odd
if the difference in bit labeling was retained. Since we're switching to
a consolidated set of basic helpers, such an anomaly would better not
survive imo.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 14:33:06 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 14:33:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693300.1081208 (Exim 4.92)
	(envelope-from )
	id 1rkm8n-0005q2-8k; Thu, 14 Mar 2024 14:33:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693300.1081208; Thu, 14 Mar 2024 14:33:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkm8n-0005pv-4x; Thu, 14 Mar 2024 14:33:05 +0000
Received: by outflank-mailman (input) for mailman id 693300;
 Thu, 14 Mar 2024 14:33:04 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkm8m-0005pp-HV
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 14:33:04 +0000
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com
 [2a00:1450:4864:20::634])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c3d49105-e20f-11ee-afdd-a90da7624cb6;
 Thu, 14 Mar 2024 15:33:03 +0100 (CET)
Received: by mail-ej1-x634.google.com with SMTP id
 a640c23a62f3a-a44ad785a44so115261266b.3
 for ; Thu, 14 Mar 2024 07:33:03 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 v23-20020a1709067d9700b00a4663a7120asm758327ejo.166.2024.03.14.07.33.02
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 14 Mar 2024 07:33:02 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c3d49105-e20f-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710426783; x=1711031583; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=QRzneQIbB1lWKpJoC5q0aXoJLsyRGUVQnNwFc8SYcz8=;
        b=SEdCToGGn4rjEvALoaRKSZGdK+LDL/X3dF/u4tKX+rMX2yr9hjuwLzWWfbkfFZFWzK
         3Xtxq/Sa5SMz2DsthzvjfEtNVDNhs0dCzyGHXea2oI1Hbz1O6u+UwvXs9ufyOk+oQtBh
         r9/K4G7pR6BMJh/pMK9L0K0Ungu89FfUwkM/GmOxfr+EyAQMrxHLfRvL6O0gEORl3QYM
         7Kc/9zSXDneqIboNK4TeYdbJuPEY+7Z/0t7X/R5aGNCXha/w8HsC1dSI7DSX2G8LfTxp
         clwRp3kMXZ1zuYHgQFoADcSEnwRf5ncWinZJo9gFEgDxvC/p5ahz7oZPxOQD6Fwugd6D
         bWbg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710426783; x=1711031583;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=QRzneQIbB1lWKpJoC5q0aXoJLsyRGUVQnNwFc8SYcz8=;
        b=hdLqcC9wm/E8ZQsfZWPlVkY+Px2NKVzyzpmtb7xoRyqB4++JmZdgbyEG9AwFBXGZQD
         Ed7U4XJhJuGOzLPfq/7Ef3IHcI2nH8zg9c5/dwjjkGR7oB6TRpCBKr+rAr5Sd2f4HGmG
         8pYxvc4UUmN7GfwkI92yCR/G5X2fCRtrahgHSmCOPRgUZGiAdft2MApmOLHylOTip4f7
         +loQO1ZuvVPBUwzN2/khZFnwuIvwakzydqhn6/o246PHy4B2E7bnZlFFCdM613TjSljd
         Lin+pSCx+vOZGun9JFcNuMSYsL8OQguN2/dUm/BqIS0VU6qzqmFwj4oAI4QabkE+pPGN
         U4wg==
X-Gm-Message-State: AOJu0YzIig1QrQYTLjhoGyvGeMxwE8O7620Eb1CQuSSP2UHECKiub2Yz
	Kf8k/WbSaiMWLU70tweZf3BldwxdmxHXYY1RkkWTpIcxxG2Tnt2aAYoxN3rc4Q==
X-Google-Smtp-Source: AGHT+IE/hyKjk4oxselP63p81n5F0QgPzuyAWalggblhlofF0UOzNbsSYDYrVITmuTXodkKqJqyyZw==
X-Received: by 2002:a17:907:d40d:b0:a43:49ca:2473 with SMTP id vi13-20020a170907d40d00b00a4349ca2473mr947071ejc.0.1710426782891;
        Thu, 14 Mar 2024 07:33:02 -0700 (PDT)
Message-ID: 
Date: Thu, 14 Mar 2024 15:33:01 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/7] multiboot2: Add load type header and support for the
 PE binary type
Content-Language: en-US
To: Ross Lagerwall 
Cc: xen-devel@lists.xenproject.org, Andrew Cooper
 , Daniel Kiper ,
 grub-devel@gnu.org
References: <20240313150748.791236-1-ross.lagerwall@citrix.com>
 <20240313150748.791236-2-ross.lagerwall@citrix.com>
 
 
 
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 14.03.2024 15:24, Ross Lagerwall wrote:
> On Thu, Mar 14, 2024 at 1:37 PM Jan Beulich  wrote:
>> On 14.03.2024 10:30, Ross Lagerwall wrote:
>>> On Thu, Mar 14, 2024 at 7:24 AM Jan Beulich  wrote:
>>>> On 13.03.2024 16:07, Ross Lagerwall wrote:
>>>>> In addition to the existing address and ELF load types, specify a new
>>>>> optional PE binary load type. This new type is a useful addition since
>>>>> PE binaries can be signed and verified (i.e. used with Secure Boot).
>>>>
>>>> And the consideration to have ELF signable (by whatever extension to
>>>> the ELF spec) went nowhere?
>>>
>>> I'm not sure if you're referring to some ongoing work to create signable
>>> ELFs that I'm not aware of.
>>
>> Something must have been invented already to make Linux modules signable.
> 
> Linux module signatures operate outside of the ELF container. In fact,
> AFAIK the actual signed content could be anything. The file format is:
> 
> * Content (i.e. ELF binary)
> * Signature of content in PKCS7 format
> * Signature info, including signature length
> * Magic marker: "~Module signature appended~\n"
> 
> This kind of arrangement does indeed work but it is fragile. Since the
> signature is on the entire contents and tools that understand ELF don't
> parse the signature, any transformation of the binary (e.g. to
> strip out debuginfo) will cause the signature to be lost / invalidated.

This looks extremely poor to me, so ...

> Nevertheless, this could still be an option for Xen if this is
> deemed to be a preferred solution by others. It would be good to hear
> some opinions on this.

... I'd rather not see this used for Xen.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 14:33:34 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 14:33:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693303.1081218 (Exim 4.92)
	(envelope-from )
	id 1rkm9G-0006Rj-KF; Thu, 14 Mar 2024 14:33:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693303.1081218; Thu, 14 Mar 2024 14:33:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkm9G-0006Rc-HN; Thu, 14 Mar 2024 14:33:34 +0000
Received: by outflank-mailman (input) for mailman id 693303;
 Thu, 14 Mar 2024 14:33:33 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkm9F-0005pp-AE
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 14:33:33 +0000
Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com
 [2607:f8b0:4864:20::72c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d4e5f14a-e20f-11ee-afdd-a90da7624cb6;
 Thu, 14 Mar 2024 15:33:32 +0100 (CET)
Received: by mail-qk1-x72c.google.com with SMTP id
 af79cd13be357-788303f317eso46697185a.2
 for ; Thu, 14 Mar 2024 07:33:32 -0700 (PDT)
Received: from localhost ([85.31.135.62]) by smtp.gmail.com with ESMTPSA id
 bl32-20020a05620a1aa000b00789dfdfa12esm196775qkb.19.2024.03.14.07.33.30
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 14 Mar 2024 07:33:30 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d4e5f14a-e20f-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710426811; x=1711031611; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=LfP4doKPQLrJtKtwWlZC1QrZ3hW6BNrPh5jy4k7/53k=;
        b=PT+kXBYfQX/sgnCb9WVO6ThYtGC3Mjhiumc0YVF9RGnDren4USq4Eil/cgLnYBPLuH
         42iQuguZ+JasFavWnNm/N+/dh9+lrkkyPXTrJWvwkysH9uZFbEg915cnafatLOQF29o0
         xlOhCub5eu1a0XeyyVkTauNZtFwtk27WMSRoA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710426811; x=1711031611;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=LfP4doKPQLrJtKtwWlZC1QrZ3hW6BNrPh5jy4k7/53k=;
        b=l1R4P/ZnVWWU0XXFB94//3ciFsl/Cx2cIVrivgz//HXCwQCMA/uR3E7bKPMo9KCKKR
         xvq59nmiOXaZGh8S5RInf0FoCqCSD+2Tnm8k8yKiRdIgGvfM/rEvaj3lIGDQeNLCt45T
         MTd48bJM/G1dk/aY+n+ud5HNjh0bnT/+7yl44lDbmosn3b2w+CkzKz7LhF7+l34n7kj3
         81jNbthWvwCDODivkrbLK5IauOlRR/566U7uTna7RdF4rHsv9jJegbKPy6vG0wLzOnZE
         n3p0m0fD/zzNGmoQ9NO4RBAwLH6PYcAIje1EiEUf67tEkcx3/crIAUIn2Vb/GpiC5b0+
         l69Q==
X-Gm-Message-State: AOJu0YxYlULm+qVXsnBjh2pBVXDwOqx32Y5ncoHQeyHnbJ0cyhspju0q
	yqg8VPIbxI9fB/V2MVs8hJULVIYlEnw1SQgqR+Ude1OtdAby9jTzdekthk98FmA=
X-Google-Smtp-Source: AGHT+IEVRBu34ffizHVWtACX8Y9ZLlw2RDlsw+3BR5Hv3IxkrMN1tEYum0iJUKC98yyC5bjGRkN/Gw==
X-Received: by 2002:a05:620a:3905:b0:789:d306:879a with SMTP id qr5-20020a05620a390500b00789d306879amr2439220qkn.7.1710426811307;
        Thu, 14 Mar 2024 07:33:31 -0700 (PDT)
Date: Thu, 14 Mar 2024 15:33:29 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jason Andryuk 
Cc: xen-devel@lists.xenproject.org, Jan Beulich ,
	Andrew Cooper , Wei Liu ,
	George Dunlap ,
	Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH v2 3/3] x86/PVH: Support relocatable dom0 kernels
Message-ID: 
References: <20240313193021.241764-1-jason.andryuk@amd.com>
 <20240313193021.241764-4-jason.andryuk@amd.com>
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Thu, Mar 14, 2024 at 09:51:22AM -0400, Jason Andryuk wrote:
> On 2024-03-14 05:48, Roger Pau Monné wrote:
> > On Wed, Mar 13, 2024 at 03:30:21PM -0400, Jason Andryuk wrote:
> > > Xen tries to load a PVH dom0 kernel at the fixed guest physical address
> > > from the elf headers.  For Linux, this defaults to 0x1000000 (16MB), but
> > > it can be configured.
> > > 
> > > Unfortunately there exist firmwares that have reserved regions at this
> > > address, so Xen fails to load the dom0 kernel since it's not RAM.
> > > 
> > > The PVH entry code is not relocatable - it loads from absolute
> > > addresses, which fail when the kernel is loaded at a different address.
> > > With a suitably modified kernel, a reloctable entry point is possible.
> > > 
> > > Add XEN_ELFNOTE_PVH_RELOCATION which specifies the minimum, maximum and
> > > alignment needed for the kernel.  The presence of the NOTE indicates the
> > > kernel supports a relocatable entry path.
> > > 
> > > Change the loading to check for an acceptable load address.  If the
> > > kernel is relocatable, support finding an alternate load address.
> > > 
> > > Link: https://gitlab.com/xen-project/xen/-/issues/180
> > > Signed-off-by: Jason Andryuk 
> > > ---
> > > ELF Note printing looks like:
> > > (XEN) ELF: note: PVH_RELOCATION = min: 0x1000000 max: 0xffffffff align: 0x200000
> > > 
> > > v2:
> > > Use elfnote for min, max & align - use 64bit values.
> > > Print original and relocated memory addresses
> > > Use check_and_adjust_load_address() name
> > > Return relocated base instead of offset
> > > Use PAGE_ALIGN
> > > Don't load above max_phys (expected to be 4GB in kernel elf note)
> > > Use single line comments
> > > Exit check_load_address loop earlier
> > > Add __init to find_kernel_memory()
> > > ---
> > >   xen/arch/x86/hvm/dom0_build.c      | 108 +++++++++++++++++++++++++++++
> > >   xen/common/libelf/libelf-dominfo.c |  13 ++++
> > >   xen/include/public/elfnote.h       |  11 +++
> > >   xen/include/xen/libelf.h           |   3 +
> > >   4 files changed, 135 insertions(+)
> > > 
> > > diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
> > > index 0ceda4140b..5c6c0d2db3 100644
> > > --- a/xen/arch/x86/hvm/dom0_build.c
> > > +++ b/xen/arch/x86/hvm/dom0_build.c
> > > @@ -537,6 +537,108 @@ static paddr_t __init find_memory(
> > >       return INVALID_PADDR;
> > >   }
> > > +static bool __init check_load_address(
> > > +    const struct domain *d, const struct elf_binary *elf)
> > > +{
> > > +    paddr_t kernel_start = (paddr_t)elf->dest_base & PAGE_MASK;
> > 
> > Are you sure this is correct?  If a program header specifies a non-4K
> > aligned load address we should still try to honor it.  I think this is
> > very unlikely, but still we shouldn't apply non-requested alignments
> > to addresses coming from the ELF headers.
> 
> I think it's correct in terms of checking the e820 table.  Since the memory
> map is limited to 4k granularity, the bounds need to be rounded accordingly.

That's for populating the p2m, but I don't see why the kernel load
area should be limited by this?

There's AFAICt no issue from a kernel requesting that it's start load
address is not page aligned (granted that's very unlikely), but I
don't see why we would impose an unneeded restriction here.

The kernel load area doesn't affect how the p2m is populated, that's
mandated by the e820.

> > > +    paddr_t kernel_end = PAGE_ALIGN((paddr_t)elf->dest_base + elf->dest_size);
> > > +    unsigned int i;
> > > +
> > > +    /*
> > > +     * The memory map is sorted and all RAM regions starts and sizes are
> > > +     * aligned to page boundaries.
> > 
> > Relying on sizes to be page aligned seems fragile: it might work now
> > because of the order in which pvh_setup_vmx_realmode_helpers() first
> > reserves memory for the TSS and afterwards for the identity page
> > tables, but it's not a property this code should assume.
> 
> That can be removed.  It would just eliminate the early exit...
> 
> > > +     */
> > > +    for ( i = 0; i < d->arch.nr_e820; i++ )
> > > +    {
> > > +        paddr_t start = d->arch.e820[i].addr;
> > > +        paddr_t end = d->arch.e820[i].addr + d->arch.e820[i].size;
> > > +
> > > +        if ( start >= kernel_end )
> > > +            return false;
> 
> ... here.

I think the sorted aspect is fine, the aligned part is the one I'm
complaining about, so the check above can stay.

> > > +    const struct elf_dom_parms *parms)
> > > +{
> > > +    paddr_t kernel_start = (paddr_t)elf->dest_base & PAGE_MASK;
> > > +    paddr_t kernel_end = PAGE_ALIGN((paddr_t)elf->dest_base + elf->dest_size);
> > > +    paddr_t kernel_size = kernel_end - kernel_start;
> > 
> > Hm, I'm again unsure about the alignments applied here.
> 
> Same as above regarding 4k granularity.
> 
> > I think if anything we want to assert that dest_base is aligned to phys_align.
> 
> That would indicate the kernel image is inconsistent.

Indeed.  I think doing that sanity check would be worth.

> > > diff --git a/xen/common/libelf/libelf-dominfo.c b/xen/common/libelf/libelf-dominfo.c
> > > index 7cc7b18a51..837a1b0f21 100644
> > > --- a/xen/common/libelf/libelf-dominfo.c
> > > +++ b/xen/common/libelf/libelf-dominfo.c
> > > @@ -125,6 +125,7 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
> > >           [XEN_ELFNOTE_SUSPEND_CANCEL] = { "SUSPEND_CANCEL", ELFNOTE_INT },
> > >           [XEN_ELFNOTE_MOD_START_PFN] = { "MOD_START_PFN", ELFNOTE_INT },
> > >           [XEN_ELFNOTE_PHYS32_ENTRY] = { "PHYS32_ENTRY", ELFNOTE_INT },
> > > +        [XEN_ELFNOTE_PVH_RELOCATION] = { "PVH_RELOCATION", ELFNOTE_OTHER },
> > >       };
> > >   /* *INDENT-ON* */
> > > @@ -234,6 +235,17 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
> > >                   elf_note_numeric_array(elf, note, 8, 0),
> > >                   elf_note_numeric_array(elf, note, 8, 1));
> > >           break;
> > > +
> > > +    case XEN_ELFNOTE_PVH_RELOCATION:
> > > +        if ( elf_uval(elf, note, descsz) != 3 * sizeof(uint64_t) )
> > > +            return -1;
> > > +
> > > +        parms->phys_min = elf_note_numeric_array(elf, note, 8, 0);
> > > +        parms->phys_max = elf_note_numeric_array(elf, note, 8, 1);
> > > +        parms->phys_align = elf_note_numeric_array(elf, note, 8, 2);
> > 
> > Size for those needs to be 4 (32bits) as the entry point is in 32bit
> > mode?  I don't see how we can start past the 4GB boundary.
> 
> I specified the note as 3x 64bit values.  It seemed simpler than trying to
> support both 32bit and 64bit depending on the kernel arch.  Also, just using
> 64bit provides room in case it is needed in the future.

Why do you say depending on the kernel arch?

PVH doesn't know the bitness of the kernel, as the kernel entry point
is always started in protected 32bit mode.  We should just support
32bit values, regardless of the kernel bitness, because that's the
only range that's suitable in order to jump into the entry point.

Note how XEN_ELFNOTE_PHYS32_ENTRY is also unconditionally a 32bit
integer.

> Do you want the note to be changed to 3x 32bit values?

Unless anyone objects, yes, that's would be my preference.

> > > +        elf_msg(elf, "min: %#"PRIx64" max: %#"PRIx64" align: %#"PRIx64"\n",
> > > +                parms->phys_min, parms->phys_max, parms->phys_align);
> > > +        break;
> > >       }
> > >       return 0;
> > >   }
> > > @@ -545,6 +557,7 @@ elf_errorstatus elf_xen_parse(struct elf_binary *elf,
> > >       parms->p2m_base = UNSET_ADDR;
> > >       parms->elf_paddr_offset = UNSET_ADDR;
> > >       parms->phys_entry = UNSET_ADDR32;
> > > +    parms->phys_align = UNSET_ADDR;
> > 
> > For correctness I would also init phys_{min,max}.
> 
> There is a memset() out of context above to zero the structure.  I thought
> leaving them both 0 would be fine.

0 would be a valid value, hence it's best to use UNSET_ADDR to clearly
notice when a value has been provided by the parsed binary or not.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 14:46:14 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 14:46:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693311.1081227 (Exim 4.92)
	(envelope-from )
	id 1rkmLP-0000zr-OT; Thu, 14 Mar 2024 14:46:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693311.1081227; Thu, 14 Mar 2024 14:46:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkmLP-0000zk-LW; Thu, 14 Mar 2024 14:46:07 +0000
Received: by outflank-mailman (input) for mailman id 693311;
 Thu, 14 Mar 2024 14:46:06 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkmLO-0000ze-6Y
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 14:46:06 +0000
Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com
 [2607:f8b0:4864:20::f2f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 94547899-e211-11ee-a1ee-f123f15fe8a2;
 Thu, 14 Mar 2024 15:46:03 +0100 (CET)
Received: by mail-qv1-xf2f.google.com with SMTP id
 6a1803df08f44-69145fc4265so5622496d6.1
 for ; Thu, 14 Mar 2024 07:46:03 -0700 (PDT)
Received: from [10.80.67.149] (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 pt10-20020a056214048a00b00690494d2766sm524966qvb.96.2024.03.14.07.45.58
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 14 Mar 2024 07:46:00 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 94547899-e211-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710427561; x=1711032361; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=15TzI8ow3cv04JT6Ed7qn1VR0mROIfYxoNQPdLk0wik=;
        b=HOvj4qZKLZeLh0itABrkcxPA/4emWhwUA8tWDFhoQkgiPdVxgsDupjFdx3FLreDnyw
         wWo36SZJ8ha1JrAGuvA2YNt2sMcbSs8CIzr1+9zpF9bqJv9Z/ERPckO88ubjCFqXc2YY
         Asq6mG6+WGoAwtCSfMHRzjUJbxUhaOlurRwWw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710427561; x=1711032361;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=15TzI8ow3cv04JT6Ed7qn1VR0mROIfYxoNQPdLk0wik=;
        b=wc9uneP/Z77kEj/i6MBCw5T7Hd19uSxp9yfOaZuKHcreu+6a1vKWJ9LizHcvckO7vi
         cLz1lqTmRNMgBIcvYcly3n0pVNbrDnG/iZSJDwAB7A1RAZzLV7MbE0oDz70iWdIPje//
         f14MBoEOx72/WaEM0iSl3zbk/HekXs9neU8PvnfvvYbMsBXejN2E/LMnhvkUKuCGP64i
         4zgUHfjEXCObAhKb7lvOMeonL7qc7s/Jwe2tKB6lWvkeAoaFXPkKuJEGEVInpHmcfvHl
         CkDM2y3EblbInl5uC1BVCaib9lC0MPh5PB6dryzHUhMSCIQSR+ZRarjn5cENUe2kNlRk
         zd0A==
X-Gm-Message-State: AOJu0YxDbjQwjzbEDv1SZCJf7ms+Gok6C9Y7Tlf30b9Npf7idUK3MWE5
	ft/XzJ4FBjSrUnc8kPhA9vyHLJQypiYC1qEtkDFTsxnygrBI26ExDtShYC6bnz5+W/DOJqpZF2n
	F
X-Google-Smtp-Source: AGHT+IFMynwX6WM8JR/g9D3bHh2WUMiBrBKQmFWE+LqBAS/qc0SmP9KGY3XSGnrb8xtB9gh/cu71jQ==
X-Received: by 2002:a0c:dd91:0:b0:691:2153:55ba with SMTP id v17-20020a0cdd91000000b00691215355bamr2160530qvk.45.1710427561080;
        Thu, 14 Mar 2024 07:46:01 -0700 (PDT)
Message-ID: <1805b028-e21f-448f-bf94-2156092e40a5@citrix.com>
Date: Thu, 14 Mar 2024 14:45:57 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [RISCV] [PATCH 0/7] xen/bitops: Reduce the mess, starting with ffs()
Content-Language: en-GB
To: Xen-devel 
Cc: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Wei Liu ,
 Stefano Stabellini , Julien Grall ,
 Volodymyr Babchuk ,
 Bertrand Marquis ,
 Michal Orzel ,
 Oleksii Kurochko ,
 Shawn Anastasio ,
 "consulting @ bugseng . com" ,
 Simone Ballarin ,
 Federico Serafini ,
 Nicola Vetrini 
References: <20240313172716.2325427-1-andrew.cooper3@citrix.com>
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <20240313172716.2325427-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 13/03/2024 5:27 pm, Andrew Cooper wrote:
> Start cleaning it up with ffs() and friends.  Across the board, this adds:
>
>  * Functioning bitops without arch-specific asm

It turns out that RISC-V doesn't have a CLZ instruction in the base
ISA.  As a consequence, __builtin_ffs() emits a library call to ffs() on
GCC, or a de Bruijn sequence on Clang.

The optional Zbb extension adds a CLZ instruction, after which
__builtin_ffs() emits a very simple sequence.

This leaves us with several options.

1) Put generic_ffs() back in, although if we do this then it's going to
be out-of-line in lib/ where it can be mostly ignored.

2) Require Zbb for Xen.

3) Alternative it up with Zbb or generic_ffs().


I've got half a mind to do 1) irrespective.  It's mostly just shuffling
logic out of bitops.h into lib/.

I also think we should do option 2 for RISCV.  Given the instruction
groups that H does mandate, it's unrealistic to expect that such a chip
wouldn't support Zbb/etc.

Also, getting full alternatives working is yet-more work that's not
trivial at this point in RISCV's development.  I think it is entirely
reasonable to avoid this work for now, and make it a problem for anyone
who has an H-capable Zbb-incapable system.  (with a strong implication
that this is work that probably never needs to be done.)

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 15:13:19 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 15:13:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693318.1081238 (Exim 4.92)
	(envelope-from )
	id 1rkmlc-0007Eq-Rx; Thu, 14 Mar 2024 15:13:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693318.1081238; Thu, 14 Mar 2024 15:13:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkmlc-0007Ej-PC; Thu, 14 Mar 2024 15:13:12 +0000
Received: by outflank-mailman (input) for mailman id 693318;
 Thu, 14 Mar 2024 15:13:11 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkmlb-0007D6-9Q
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 15:13:11 +0000
Received: from EUR05-DB8-obe.outbound.protection.outlook.com
 (mail-db8eur05on20631.outbound.protection.outlook.com
 [2a01:111:f400:7e1a::631])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5d768fdb-e215-11ee-a1ee-f123f15fe8a2;
 Thu, 14 Mar 2024 16:13:08 +0100 (CET)
Received: from DU6P191CA0017.EURP191.PROD.OUTLOOK.COM (2603:10a6:10:540::28)
 by DB3PR08MB9898.eurprd08.prod.outlook.com (2603:10a6:10:434::7) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.21; Thu, 14 Mar
 2024 15:13:00 +0000
Received: from DB5PEPF00014B97.eurprd02.prod.outlook.com
 (2603:10a6:10:540:cafe::a1) by DU6P191CA0017.outlook.office365.com
 (2603:10a6:10:540::28) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.21 via Frontend
 Transport; Thu, 14 Mar 2024 15:13:00 +0000
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by
 DB5PEPF00014B97.mail.protection.outlook.com (10.167.8.235) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.7386.12 via Frontend Transport; Thu, 14 Mar 2024 15:12:59 +0000
Received: ("Tessian outbound 5180408f3322:v276");
 Thu, 14 Mar 2024 15:12:59 +0000
Received: from fe822e5a61bb.1
 by 64aa7808-outbound-1.mta.getcheckrecipient.com id
 335EC9A3-6871-40C4-9CF0-C925D1683FFB.1; 
 Thu, 14 Mar 2024 15:12:52 +0000
Received: from EUR04-DB3-obe.outbound.protection.outlook.com
 by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id fe822e5a61bb.1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384);
 Thu, 14 Mar 2024 15:12:52 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com (2603:10a6:10:25a::24)
 by AS4PR08MB7477.eurprd08.prod.outlook.com (2603:10a6:20b:4e4::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.36; Thu, 14 Mar
 2024 15:12:49 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::7fb0:6621:56b:22d5]) by DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::7fb0:6621:56b:22d5%3]) with mapi id 15.20.7386.020; Thu, 14 Mar 2024
 15:12:49 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5d768fdb-e215-11ee-a1ee-f123f15fe8a2
ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass;
 b=AsgHN+U5n0+iQdKHkRihwnp2lOQRamQ8cvU783PlTGsMsbu+XUjH3N1GDGfs5PjNNT1pmOTInhNajGf+LEctTiz3oLFOsdsVlONpXJWeJS0HyfJL9wbAP8ykjsWzF4MwKLoxJlDh5PlWJzvJdgrFQVJ0QaYID/yFw83kGQoF06ZwngTxZSMUjW+gmUfozJjPmsQZDs9ercAGF6EVeV8OYoaFLf98ihZYPk/q1JxfcQgAM/4Vj+NmM4OTcCay2gYaXe4v7J7hIEC5zBojTous8h3L+SFebtPxp3Ue9q26k01mmhbmfn1rGo0rG+FRCucM308plALxIQkbIPgn8m+ARA==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=i4F9q04AcUhjcEca3Qf+BmiZXzSicBAcKJFgph0eUFQ=;
 b=l2uuFi/KwewOUZ/KczJcA0ZjKNt+tQUUthfb42qEeaVoKDYb+mUn8qB9pOaaD5+csYn1rsa1yMYF24NdNSXjbRpeSNxGz42UuG4ZBDvQMfhkk1XdEXGqGCkAEw0QV8GhbjwA4/la7MaTrIUkkXwcjHmAMeGifbB7wuL4i3gHerl2MGd+l43So6fELqdmEQLQvIp1Yfk4VV1Kiqj1zz6P6tz/nYupmoyi44nc8IHi1fClvGfVMV8lXQuPV2WglDx/UVMAXGtx/Fena20wFKSVb70lIYg1CwMEsWR/U2AxHQrfPMGrU65w8zhNHLUrwTejpnpUtvQuxvYN/V/6fZxUlw==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 63.35.35.123) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=arm.com;
 dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com;
 dkim=pass (signature was verified) header.d=armh.onmicrosoft.com; arc=pass (0
 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com]
 dmarc=[1,1,header.from=arm.com])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com;
 s=selector2-armh-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=i4F9q04AcUhjcEca3Qf+BmiZXzSicBAcKJFgph0eUFQ=;
 b=H1soPOPONDV7Zd8SupyzgYNCnAlR8siUqwbS0Admkyf6Q2N08wG8oUR6xgJ+lV/wtsEIQzMsE4FZWu26ho2HK/dOTIzPzzGX2sYZHvjfdXcLQ9j7YLvxFKKsOqRCMh+lgidKAkvWE+qbNlrnc9Rcsd9ArIUEY+X8rxR6dqlc+U8=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=armh.onmicrosoft.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 63.35.35.123 as permitted sender) receiver=protection.outlook.com;
 client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
 pr=C
X-CheckRecipientChecked: true
X-CR-MTA-CID: 7e365bc79c29dd4b
X-CR-MTA-TID: 64aa7808
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=id6WeEzTVUbBnd5E2SQ7T4tP1fh3rX7K3MZ/uO5kNYoDwL9IMP289d5xB13umbpOuyqS7uFLMGnN+JbfhWGmvrPtnDD4B7Oylwzg0qm/pUBt5JNsP084YYBCH7kKHQ+AryylID0SKNngPit4d5KY7cSQlaNneoAyXs17VcyCKtDLzN8aHsWDQynLB9mG+ajoFXIhBXLa5d1Nu6DPwP6TE7toKGdYu0dwhO8XeH7RCjkhznrViUSJ6+gC7tj+QA3J0+VcAnG1xUEvdERyDgcM/GSAWtkqTr/iJu3Fy3kN5rhU1paO7GZRN8uzb8X1qtDSZ0BUI94o+GdBUGQY4140VQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=i4F9q04AcUhjcEca3Qf+BmiZXzSicBAcKJFgph0eUFQ=;
 b=WKNAp9/z6DF2RK84byZW9Fk0HBncgSzryf3DL5Q/2X8hcScgVPKhrATbgIXacOKKSlx0XCfxnQ5iVnpAK2X+2mRSwSpLf/BAL25WHNOLi+vPXRie8jCiRpdCAlCOO04pygNHft1DeJSamii+dkpOU0geSP7cDuIwoWf2wIyNBOq7zWOR9Njm683TW882VJEnaYx/C4M+wcmUhVeePEYtZ+Xn8TeLZ+0PW9oe9uJPLCx2lvfbac+E+pmEA++CN9qc67cBqR98/E7XG14a6BCNaJu4bw8Nl0QdyR4mCo2ScNcCT/JzOJMqJuKWb5FzI+YE+joNU6zoNpZTdrEP41jHjQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass
 header.d=arm.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com;
 s=selector2-armh-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=i4F9q04AcUhjcEca3Qf+BmiZXzSicBAcKJFgph0eUFQ=;
 b=H1soPOPONDV7Zd8SupyzgYNCnAlR8siUqwbS0Admkyf6Q2N08wG8oUR6xgJ+lV/wtsEIQzMsE4FZWu26ho2HK/dOTIzPzzGX2sYZHvjfdXcLQ9j7YLvxFKKsOqRCMh+lgidKAkvWE+qbNlrnc9Rcsd9ArIUEY+X8rxR6dqlc+U8=
From: Bertrand Marquis 
To: Stefano Stabellini 
CC: Jan Beulich , Andrew Cooper
	, Julien Grall , Michal Orzel
	, =?iso-8859-1?Q?Roger_Pau_Monn=E9?=
	, "xen-devel@lists.xenproject.org"
	
Subject: Re: [PATCH] docs/misra: add Rule 16.4
Thread-Topic: [PATCH] docs/misra: add Rule 16.4
Thread-Index: AQHadN1oSVYbGKIFE0GfGxIx2bdb6LE1S9QAgAEAKICAAQ5kgA==
Date: Thu, 14 Mar 2024 15:12:49 +0000
Message-ID: 
References:
 
 <136e4667-8c6d-45ec-b652-b6b690a16f34@suse.com>
 
In-Reply-To:
 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3774.200.91.1.1)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DB9PR08MB6588:EE_|AS4PR08MB7477:EE_|DB5PEPF00014B97:EE_|DB3PR08MB9898:EE_
X-MS-Office365-Filtering-Correlation-Id: 3576ed36-4648-4661-a4a4-08dc44393c58
x-checkrecipientrouted: true
nodisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted: BCL:0;
X-Microsoft-Antispam-Message-Info-Original:
 PIkNpgt8/osUNpUCvZKZnLV8XWAKGfdeBG1qQaq0M2zqTQvvSAh4JdYk9GYOtX0FRLnlnMXjoWPfCAy2vt/WkAyiDZg0v14fM49M3YqbzTZ/0hYoMz48tluQTci7GsEPAwqCv1lM9eR42TchSllmJXN+YwreRMXxajf7GpKrEsVCYSNVPURBiGsMFkCsBfU3muLVn+9FD4o0ti17cG3BUrKEJBWnzsVXWh0eBpWjduO1ph/oDW2J87wC7lGkUUUHNdcOM0n+/tf9+z0q9eOYBGlCCszLaiL5U5HvSNbbdyUZmAztECT0/3lskTEayd312VFI0OGBcnXc3VbK1p2K8YluaotczMuPgp4vZs92SBygrPEDEIRgudm+j+/RYxgfBzM7WgFdKRVQOjShALxZnn3DSh3zX6ax4hwj897/q9b/LJ3qpCyMEynWQl/2FISF7/majIwTcsmGiV2QkYAEWNBURbUg4v7uX6FZnH86yKAANOHYoJN0b5kLnQArBD1dhMqlowvHMLzRIKvKCc7+SpwpBu6focG30vpenaklWTS7uRJ7l670UO5wa0kuR7y2IQq6b8naTonfAE0r9HeaOn572OfcBC8Dwn3abJddvy9YhuiM7F5yS52xrqd8NJSuiPdvEbqMFKsmQamabRvB+GeHpZP8uT5W7oisRrzmiBs=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB9PR08MB6588.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(1800799015)(376005)(38070700009);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <9FD390162A57F34B87C65D199B3F6155@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS4PR08MB7477
Original-Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 DB5PEPF00014B97.eurprd02.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	e59f6bb7-ff78-4478-b453-08dc4439368f
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	/gVraXxA58yK+dV2JZiaCdc/uFycTHUgvDJXTl/zi2tA7H33LOVJgDrmc4KirBCMidQ5smi0+83DGZYJAoJxJywrhtbRtIGXzboq9LiN//LS6EoU+MNkFlX4follb1KsePdJmUtrOiR3fmeC+/qyWyDF3ZcdFmKzh1B3OmxuFKOcVWR9qQlvaa8WUHRFZSFiwNMsJU4qIMYUEhz2l3hpm0tAg11DtKqrnz8XKTeSRbHx8E4xplJnQEJaS5+XTAHNz+BXYlr4qg0+glgdp3iNQYVm8jBln6Jxbz5afU7u1DgRtdCfAaJrLIvyBf7WVbltw2zGoAky+ocqQPrzkAh81COTiRbX5dpHh17rbsHF1ah1WaMsmMpVFOLRoDYoHsnXWfPxsVOOvJcEODtfvxDGWPiVz7N8K/ISP7Llz8ncyTHwU5c/M7Fe2l997ctRgZe4wltMAEPxCLVDsnKT2hZcnYw6P28qktUq0+zNWaEq8MhXkXitWWBPjnHppDs9immRQg46PhowZtJKCynr2VVWKkuVPoiwYXL4KLAt9bg97ZqGTLnc4eq2qPlNyjtQ/DM1bjQJE452Jr8Ny5KzEsNvrCPq933gc4UO4+BHfb+qwpDMmn4BDfSL6TcLvTvhba97OUiS0pqXSkntNUoRnmqbeHFCT+ppDd56399Qp+zlllkh6E2E4/UnVxkIP4CTkAekIC+ksrWYWdIepBllaQwp2g==
X-Forefront-Antispam-Report:
	CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com;CAT:NONE;SFS:(13230031)(376005)(1800799015)(36860700004)(82310400014);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Mar 2024 15:12:59.6034
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 3576ed36-4648-4661-a4a4-08dc44393c58
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DB5PEPF00014B97.eurprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR08MB9898

Hi Stefano,

> On 14 Mar 2024, at 00:04, Stefano Stabellini  wro=
te:
>=20
> On Wed, 13 Mar 2024, Jan Beulich wrote:
>> On 13.03.2024 01:28, Stefano Stabellini wrote:
>>> --- a/docs/misra/rules.rst
>>> +++ b/docs/misra/rules.rst
>>> @@ -478,6 +478,30 @@ maintainers if you want to suggest a change.
>>>      - In addition to break, also other unconditional flow control stat=
ements
>>>        such as continue, return, goto are allowed.
>>>=20
>>> +   * - `Rule 16.4 `_
>>> +     - Required
>>> +     - Every switch statement shall have a default label
>>> +     - Switch statements with enums as controlling expression don't ne=
ed
>>> +       a default label as gcc -Wall enables -Wswitch which warns (and
>>> +       breaks the build)
>>=20
>> I think this could do with mentioning -Werror.
>=20
> No problem
>=20
>=20
>>> if one of the enum labels is missing from the
>>> +       switch.
>>> +
>>> +       Switch statements with integer types as controlling expression
>>> +       should have a default label:
>>> +
>>> +       - if the switch is expected to handle all possible cases
>>> +         explicitly, then a default label shall be added to handle
>>> +         unexpected error conditions, using BUG(), ASSERT(), WARN(),
>>> +         domain_crash(), or other appropriate methods;
>>> +
>>> +       - if the switch is expected to handle a subset of all
>>> +         possible cases, then a default label shall be added with an
>>> +         in-code comment as follows::
>>> +
>>> +             /* only handle a subset of the possible cases */
>>> +             default:
>>> +                 break;
>>=20
>> Unless it being made crystal clear that mechanically reproducing this
>> comment isn't going to do, I'm going to have a hard time picking
>> between actively vetoing or just accepting if someone else acks this.
>> At the very least, though, the suggested (or, as requested, example)
>> comment should match ./CODING_STYLE. And it may need placing
>> differently if I understood correctly what Misra / Eclair demand
>> (between default: and break; rather than ahead of both).
>>=20
>> The only place I'd accept a pre-cooked comment is to cover the
>> "notifier pattern".
>=20
> Hi Jan,=20
>=20
> During the MISRA C call we discussed two distinct situations:
>=20
> 1) when the default is not supposed to happen (it could be an BUG_ON)
> 2) when we only handle a subset of cases on purpose
>=20
> For 2), it is useful to have a comment to clarify that we are dealing
> with 2) instead of 1). It is not a pre-cooked comment. The comment
> should be reviewed and checked that it is actually true that for this
> specific switch the default is expected and we should do nothing.
>=20
> However, the comment is indeed pre-cooked in the sense that we don't
> need to have several different variations of them to explain why we only
> handle a subset of cases.
>=20
> The majority of people on the call agreed with this (or so I understood).

In fact i do agree with Jan here somehow: we must not have a default commen=
t
in the rules.rst.
It might be that a comment will look like that but I think it would be a mi=
stake to
have a default one that people can just copy and paste without thinking.
I would suggest to put something like the following instead:
When a default is empty, a comment shall be added to state it with a reason
and when possible a more detailed explanation.

Regards
Bertrand





From xen-devel-bounces@lists.xenproject.org Thu Mar 14 15:30:22 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 15:30:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693325.1081248 (Exim 4.92)
	(envelope-from )
	id 1rkn22-0002Wa-C3; Thu, 14 Mar 2024 15:30:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693325.1081248; Thu, 14 Mar 2024 15:30:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkn22-0002WT-9N; Thu, 14 Mar 2024 15:30:10 +0000
Received: by outflank-mailman (input) for mailman id 693325;
 Thu, 14 Mar 2024 15:30:09 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkn21-0002WN-A4
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 15:30:09 +0000
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com
 [2a00:1450:4864:20::531])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id bd1a7950-e217-11ee-afdd-a90da7624cb6;
 Thu, 14 Mar 2024 16:30:08 +0100 (CET)
Received: by mail-ed1-x531.google.com with SMTP id
 4fb4d7f45d1cf-56845954fffso1295443a12.3
 for ; Thu, 14 Mar 2024 08:30:08 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d3-20020a1709064c4300b00a466d1641f0sm795163ejw.123.2024.03.14.08.30.06
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 14 Mar 2024 08:30:07 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: bd1a7950-e217-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710430207; x=1711035007; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=YH0oQ8jj10jESIRADjk9ySvuGKF46f+zs1nG8AmLPO8=;
        b=WgCgGMK/9NAL8zFzXbVahMR9Ulg527Wm2oZx+SzfjWL/iIaZl4w/L0WyZqvhHfvI0i
         Vkwp9ATm+EGCZadYSJXiZ3z8JhD/Ol5CZG0juHg+IuDQsKBcNdvgADHz0XA7e9VR7+kR
         BWfZQ/6Q0biWSpIHHSt4V28Pb/qV3LX2bvduCTRsugzRp+3Ug/nrbunyk072rCXotW5D
         YXUCibZtnbWYmB3SNPv8Ws5Fn9Y6fSurKVAhGaCHuEI2PlObVA+XEKEZufTqhMQI+Pd4
         HlyJlUEOH5wBT18+Vsjr3rU21vS3p5ftOmGDbONpJPK+Q5rIJBV2v1pGLuQLm5xGsVbS
         j5uA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710430207; x=1711035007;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=YH0oQ8jj10jESIRADjk9ySvuGKF46f+zs1nG8AmLPO8=;
        b=kueta4wsFscA2KARKpuzeraveRie/uET4muHrjGlYveIc6S6N+pG6+64LzLki/PL6Q
         30HyRFYqzoyNos9yiW0Mwmag92NOcnPfUmbckOPx2OoMg77tz9jIP82DyA5Z23bPYWfm
         E1a0kRP5pn3CAOs5OnWXq1pva9JhHwoWc4Jg7a6l2MamCRTLCPkBHmxZBsRUL18Rg5+K
         2thjNd4W8X+1KXLyJxt35/tqu/Ad9w3N8Gda9NgWwykUUwI5OznnDkyC3bD5Jx9tMhDD
         VHgW9eI2G9rLeSHhN7yvH9D/lHfjbcExArL4oe3HFyNAGYhc8zCsOaOhExLBBW2qfrWw
         2wyA==
X-Gm-Message-State: AOJu0YzZB+mrPtHhb3L55+4y3LPhWneZPxdGy62sC8aw3zMZSNS7n79C
	AByKaXWBQDEwN3C8mdCtfzGD2UPmCEifXPhiuFz+CdxDvwke1J5D6BBQgwqgTg==
X-Google-Smtp-Source: AGHT+IF3K4rRN/KBPvxNp1/4QSSPNAElPWrQuZ3rM+GcDXf+ka9odBNf+r1r9PX9CwEI47qG74sPjQ==
X-Received: by 2002:a17:906:1c0e:b0:a45:ebdf:b071 with SMTP id k14-20020a1709061c0e00b00a45ebdfb071mr218277ejg.35.1710430207539;
        Thu, 14 Mar 2024 08:30:07 -0700 (PDT)
Message-ID: 
Date: Thu, 14 Mar 2024 16:30:05 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 3/3] x86/PVH: Support relocatable dom0 kernels
Content-Language: en-US
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: xen-devel@lists.xenproject.org, Andrew Cooper
 , Wei Liu ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini ,
 Jason Andryuk 
References: <20240313193021.241764-1-jason.andryuk@amd.com>
 <20240313193021.241764-4-jason.andryuk@amd.com> 
  
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 14.03.2024 15:33, Roger Pau Monné wrote:
> On Thu, Mar 14, 2024 at 09:51:22AM -0400, Jason Andryuk wrote:
>> On 2024-03-14 05:48, Roger Pau Monné wrote:
>>> On Wed, Mar 13, 2024 at 03:30:21PM -0400, Jason Andryuk wrote:
>>>> @@ -234,6 +235,17 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
>>>>                   elf_note_numeric_array(elf, note, 8, 0),
>>>>                   elf_note_numeric_array(elf, note, 8, 1));
>>>>           break;
>>>> +
>>>> +    case XEN_ELFNOTE_PVH_RELOCATION:
>>>> +        if ( elf_uval(elf, note, descsz) != 3 * sizeof(uint64_t) )
>>>> +            return -1;
>>>> +
>>>> +        parms->phys_min = elf_note_numeric_array(elf, note, 8, 0);
>>>> +        parms->phys_max = elf_note_numeric_array(elf, note, 8, 1);
>>>> +        parms->phys_align = elf_note_numeric_array(elf, note, 8, 2);
>>>
>>> Size for those needs to be 4 (32bits) as the entry point is in 32bit
>>> mode?  I don't see how we can start past the 4GB boundary.
>>
>> I specified the note as 3x 64bit values.  It seemed simpler than trying to
>> support both 32bit and 64bit depending on the kernel arch.  Also, just using
>> 64bit provides room in case it is needed in the future.
> 
> Why do you say depending on the kernel arch?
> 
> PVH doesn't know the bitness of the kernel, as the kernel entry point
> is always started in protected 32bit mode.  We should just support
> 32bit values, regardless of the kernel bitness, because that's the
> only range that's suitable in order to jump into the entry point.
> 
> Note how XEN_ELFNOTE_PHYS32_ENTRY is also unconditionally a 32bit
> integer.
> 
>> Do you want the note to be changed to 3x 32bit values?
> 
> Unless anyone objects, yes, that's would be my preference.

As mentioned elsewhere, unless the entire note is meant to be x86-specific,
this fixed-32-bit property then would want limiting to x86.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 15:33:34 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 15:33:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693329.1081261 (Exim 4.92)
	(envelope-from )
	id 1rkn5J-0003Ez-Sp; Thu, 14 Mar 2024 15:33:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693329.1081261; Thu, 14 Mar 2024 15:33:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkn5J-0003Es-Oy; Thu, 14 Mar 2024 15:33:33 +0000
Received: by outflank-mailman (input) for mailman id 693329;
 Thu, 14 Mar 2024 15:33:32 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkn5I-0003Ej-7S
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 15:33:32 +0000
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com
 [2a00:1450:4864:20::536])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 35951c5f-e218-11ee-a1ee-f123f15fe8a2;
 Thu, 14 Mar 2024 16:33:30 +0100 (CET)
Received: by mail-ed1-x536.google.com with SMTP id
 4fb4d7f45d1cf-56647babfe6so1458715a12.3
 for ; Thu, 14 Mar 2024 08:33:30 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 f23-20020a170906049700b00a4588098c5esm803943eja.132.2024.03.14.08.33.29
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 14 Mar 2024 08:33:29 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 35951c5f-e218-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710430410; x=1711035210; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=QY+LJPNp7m6PeIjTFExpYUxA+SrCAjz9mhvCE9G7UGk=;
        b=Xvnz4n9PDjikuHFo6zmv92l0IDetndd6Gjk1oHts6F1YIZqywHvTXT0OlHWUS1i6pW
         rPN7afjwHoBORPU7qiHRdmdKQ+jrDUUjYrrrsIM/4QKAngoZZYTrpMMSCm1W71oAEzuN
         YSFVEQGVfcBn7hoI8KThzjvorz7tKUDbmv2RVRwCfnBvBw2wqo0WOhXTeT/PL5kui2Gi
         MxAM63498ga7HeGnJx42yBEeRxkQX0/AgKORrNyDzAN76wsnHk13iz5PKtGJM1jVkdE3
         ZSiHWX16zd2hyX9Zdi+RDVSpfK+NLiTmLk8dZsXqRKlM1Y5nmx4Pd0zUE/5lpImnmsUh
         VQBg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710430410; x=1711035210;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=QY+LJPNp7m6PeIjTFExpYUxA+SrCAjz9mhvCE9G7UGk=;
        b=Bb4OdzAtv90jNQp0YwW2blvZAA61uptHpsY4KYl2v/70iVX2wpK6tfgpI1y2pEyW9m
         yEbo2lCUaGlgnnuU/Caq3NzMRFD6XRBPkbtF5xDkf6EmoTaLEXAzTilUFpWSqzdj2pm7
         zJpgY9DMqic/sfs147bWXYmx2Qlq3xl5daFahBXdIEq6uaR8TYHcYwMC2k5rcbPHUPYP
         61lYvCcLJX/5wGh2JCOf5RYFNt6QTYsF3d6RQEH7vtbdYpihHRANYTt1vUBBA0farz+Z
         X+nnTUDhPss0uEQEQVyoRIQ56IJ2dL06+l0hoR9A09I/UcUH44IMyGXcQMMvF6sksZQi
         nJFg==
X-Forwarded-Encrypted: i=1; AJvYcCUcd2xb2dd2Z7Rg1EdB6vBYB3+uSf+zG6MH/KQ49Uvc/i836bTTAhWuFN5xIPR9q/i2KG29zVgEKMxfvO8JGXsxHsrkreHH8lIQi+5RrYI=
X-Gm-Message-State: AOJu0YwdNEl6w1kCD6S8fMUbY1xTRaEVlK0lwFsus/lyiAo7wDVn11qL
	i4ok+3eGU+jWYGGYircjSmSW2OnA/VhjRAK3YUx53mqkdVjgOtgMGP4zoOOO8w==
X-Google-Smtp-Source: AGHT+IGj2cW4rbPrS21BAX30Hty+57JXFKO7Whn4B06BftR1b529siPQV812q3cQsy/3K5AOGqql1g==
X-Received: by 2002:a17:906:7fc8:b0:a46:2760:3c9b with SMTP id r8-20020a1709067fc800b00a4627603c9bmr1326410ejs.34.1710430409734;
        Thu, 14 Mar 2024 08:33:29 -0700 (PDT)
Message-ID: 
Date: Thu, 14 Mar 2024 16:33:28 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RISCV] [PATCH 0/7] xen/bitops: Reduce the mess, starting with
 ffs()
Content-Language: en-US
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Wei Liu , Stefano Stabellini ,
 Julien Grall , Volodymyr Babchuk
 , Bertrand Marquis ,
 Michal Orzel ,
 Oleksii Kurochko ,
 Shawn Anastasio ,
 "consulting @ bugseng . com" ,
 Simone Ballarin ,
 Federico Serafini ,
 Nicola Vetrini ,
 Xen-devel 
References: <20240313172716.2325427-1-andrew.cooper3@citrix.com>
 <1805b028-e21f-448f-bf94-2156092e40a5@citrix.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <1805b028-e21f-448f-bf94-2156092e40a5@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 14.03.2024 15:45, Andrew Cooper wrote:
> On 13/03/2024 5:27 pm, Andrew Cooper wrote:
>> Start cleaning it up with ffs() and friends.  Across the board, this adds:
>>
>>  * Functioning bitops without arch-specific asm
> 
> It turns out that RISC-V doesn't have a CLZ instruction in the base
> ISA.  As a consequence, __builtin_ffs() emits a library call to ffs() on
> GCC, or a de Bruijn sequence on Clang.
> 
> The optional Zbb extension adds a CLZ instruction, after which
> __builtin_ffs() emits a very simple sequence.
> 
> This leaves us with several options.
> 
> 1) Put generic_ffs() back in, although if we do this then it's going to
> be out-of-line in lib/ where it can be mostly ignored.
> 
> 2) Require Zbb for Xen.
> 
> 3) Alternative it up with Zbb or generic_ffs().
> 
> 
> I've got half a mind to do 1) irrespective.  It's mostly just shuffling
> logic out of bitops.h into lib/.

Yes. Might also help with the bi-sectability issue you faced.

> I also think we should do option 2 for RISCV.  Given the instruction
> groups that H does mandate, it's unrealistic to expect that such a chip
> wouldn't support Zbb/etc.

I'm not so sure here.

> Also, getting full alternatives working is yet-more work that's not
> trivial at this point in RISCV's development.  I think it is entirely
> reasonable to avoid this work for now, and make it a problem for anyone
> who has an H-capable Zbb-incapable system.  (with a strong implication
> that this is work that probably never needs to be done.)

That's definitely for later.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 15:34:29 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 15:34:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693331.1081270 (Exim 4.92)
	(envelope-from )
	id 1rkn6D-0003kB-3h; Thu, 14 Mar 2024 15:34:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693331.1081270; Thu, 14 Mar 2024 15:34:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkn6D-0003k4-0w; Thu, 14 Mar 2024 15:34:29 +0000
Received: by outflank-mailman (input) for mailman id 693331;
 Thu, 14 Mar 2024 15:34:27 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkn6B-0003js-Py; Thu, 14 Mar 2024 15:34:27 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkn6B-0002to-L5; Thu, 14 Mar 2024 15:34:27 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkn6B-0000OY-AJ; Thu, 14 Mar 2024 15:34:27 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rkn6B-00075v-9t; Thu, 14 Mar 2024 15:34:27 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=e+uL2BeGgTn8TQeUTG4L6L6xC6PJQve2HBYVZKghIlw=; b=k9bCXVKv6lhFvTIAhWBXwlh0h0
	YjCURaQRpyj3AlxyIipXbrFxEaFfO6kaGbFZTJCWbll9slpieQtWB6vjmQfRIcw1mLdFCRXQE8GPY
	LfN+ui3XCzojRipRVEdQpA8zKmDbrykvDRYMFg54Z1/SLeaujkwH/tZzDvUKZ7g1laEI=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 185033: tolerable all pass - PUSHED
X-Osstest-Failures:
    xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    xen=af7fed3fdf82981ebbb09628b278df957569333d
X-Osstest-Versions-That:
    xen=4dc9a8b0606770dc9c6be20ff5a74a9af5fcba70
From: osstest service owner 
Date: Thu, 14 Mar 2024 15:34:27 +0000

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          16 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  af7fed3fdf82981ebbb09628b278df957569333d
baseline version:
 xen                  4dc9a8b0606770dc9c6be20ff5a74a9af5fcba70

Last test of basis   185025  2024-03-14 01:00:28 Z    0 days
Testing same since   185033  2024-03-14 13:02:16 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper 
  Federico Serafini 
  Jan Beulich 
  Juergen Gross 
  Julien Grall 
  Maria Celeste Cesario 
  Nicola Vetrini 
  Paul Durrant 
  Simone Ballarin 
  Stefano Stabellini 
  Vaishali Thakkar 

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-amd64                    pass    
 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
   4dc9a8b060..af7fed3fdf  af7fed3fdf82981ebbb09628b278df957569333d -> smoke


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 15:47:20 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 15:47:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693338.1081281 (Exim 4.92)
	(envelope-from )
	id 1rknIX-0005wF-6V; Thu, 14 Mar 2024 15:47:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693338.1081281; Thu, 14 Mar 2024 15:47:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rknIX-0005w8-3J; Thu, 14 Mar 2024 15:47:13 +0000
Received: by outflank-mailman (input) for mailman id 693338;
 Thu, 14 Mar 2024 15:47:12 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rknIW-0005vy-Bd; Thu, 14 Mar 2024 15:47:12 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rknIW-00038O-7k; Thu, 14 Mar 2024 15:47:12 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rknIV-00018v-PR; Thu, 14 Mar 2024 15:47:11 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rknIV-0002dJ-Ov; Thu, 14 Mar 2024 15:47:11 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=4oZDGUxEH1OFmtNeijIDowZdNK4NtbB6WUiTKID8LDs=; b=qLgzhrxKkq08G9pA0bE51BIHex
	L7jTFWitX2J8SOgbHCcXGW7lXh2tGXs/Q6iRQJWmBnGF4EDDMLEdqbfqEJWWuET1IotRQJ0b5g2bt
	LDiWkJNqqQERpLx7k7SY/BmxyiC/a2a9+4Tnrqdd4UvLgtAi7oQDEYMb+RsOvVUA8XFU=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 185029: regressions - FAIL
X-Osstest-Failures:
    xen-unstable:test-amd64-amd64-dom0pvh-xl-amd:guest-start:fail:regression
    xen-unstable:test-armhf-armhf-libvirt-qcow2:guest-start:fail:regression
    xen-unstable:build-arm64-pvops:kernel-build:fail:regression
    xen-unstable:test-arm64-arm64-examine:build-check(1):blocked:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-raw:build-check(1):blocked:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking
    xen-unstable:test-arm64-arm64-xl:build-check(1):blocked:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit1:build-check(1):blocked:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit2:build-check(1):blocked:nonblocking
    xen-unstable:test-arm64-arm64-xl-thunderx:build-check(1):blocked:nonblocking
    xen-unstable:test-arm64-arm64-xl-vhd:build-check(1):blocked:nonblocking
    xen-unstable:test-arm64-arm64-xl-xsm:build-check(1):blocked:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:windows-install:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-i386-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    xen=4dc9a8b0606770dc9c6be20ff5a74a9af5fcba70
X-Osstest-Versions-That:
    xen=03cf7ca23e0e876075954c558485b267b7d02406
From: osstest service owner 
Date: Thu, 14 Mar 2024 15:47:11 +0000

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-dom0pvh-xl-amd 14 guest-start           fail REGR. vs. 185019
 test-armhf-armhf-libvirt-qcow2 13 guest-start            fail REGR. vs. 185019
 build-arm64-pvops             6 kernel-build             fail REGR. vs. 185019

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-examine      1 build-check(1)               blocked  n/a
 test-arm64-arm64-libvirt-raw  1 build-check(1)               blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)               blocked  n/a
 test-arm64-arm64-xl           1 build-check(1)               blocked  n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)               blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)               blocked  n/a
 test-arm64-arm64-xl-thunderx  1 build-check(1)               blocked  n/a
 test-arm64-arm64-xl-vhd       1 build-check(1)               blocked  n/a
 test-arm64-arm64-xl-xsm       1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64 12 windows-install       fail like 185010
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop            fail like 185019
 test-armhf-armhf-libvirt     16 saverestore-support-check    fail  like 185019
 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop             fail like 185019
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop            fail like 185019
 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop             fail like 185019
 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop             fail like 185019
 test-armhf-armhf-libvirt-raw 15 saverestore-support-check    fail  like 185019
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop            fail like 185019
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 185019
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop             fail like 185019
 test-amd64-i386-libvirt      15 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     15 migrate-support-check        fail   never pass
 test-amd64-i386-xl-pvshim    14 guest-start                  fail   never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  15 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass
 test-armhf-armhf-xl-multivcpu 15 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-rtds     15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-rtds     16 saverestore-support-check    fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass
 test-armhf-armhf-xl-arndale  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     15 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-raw  14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      15 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-raw 14 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          16 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  4dc9a8b0606770dc9c6be20ff5a74a9af5fcba70
baseline version:
 xen                  03cf7ca23e0e876075954c558485b267b7d02406

Last test of basis   185019  2024-03-13 18:46:04 Z    0 days
Testing same since   185029  2024-03-14 06:18:49 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Nicola Vetrini 

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            fail    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          blocked 
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 blocked 
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      blocked 
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-dom0pvh-xl-amd                              fail    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-i386-examine-bios                                 pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  blocked 
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  blocked 
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     blocked 
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-armhf-armhf-libvirt-qcow2                               fail    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-arm64-arm64-libvirt-raw                                 blocked 
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-libvirt-raw                                  pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 blocked 
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-i386-examine-uefi                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-arm64-arm64-xl-vhd                                      blocked 
 test-armhf-armhf-xl-vhd                                      pass    
 test-amd64-i386-xl-vhd                                       pass    


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

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

Explanation of these 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 4dc9a8b0606770dc9c6be20ff5a74a9af5fcba70
Author: Nicola Vetrini 
Date:   Thu Feb 15 14:06:17 2024 +0100

    automation/eclair_analysis: deviate certain macros for Rule 20.12
    
    Certain macros are allowed to violate the Rule, since their meaning and
    intended use is well-known to all Xen developers.
    
    Variadic macros that rely on the GCC extension for removing a trailing
    comma when token pasting the variable argument are similarly
    well-understood and therefore allowed.
    
    No functional change.
    
    Signed-off-by: Nicola Vetrini 
    Reviewed-by: Stefano Stabellini 
(qemu changes not included)


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 15:56:13 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 15:56:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693345.1081301 (Exim 4.92)
	(envelope-from )
	id 1rknRE-0008EJ-B9; Thu, 14 Mar 2024 15:56:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693345.1081301; Thu, 14 Mar 2024 15:56:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rknRE-0008EC-7h; Thu, 14 Mar 2024 15:56:12 +0000
Received: by outflank-mailman (input) for mailman id 693345;
 Thu, 14 Mar 2024 15:56:11 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rknRD-0007yo-18
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 15:56:11 +0000
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com
 [2a00:1450:4864:20::632])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5f995025-e21b-11ee-a1ee-f123f15fe8a2;
 Thu, 14 Mar 2024 16:56:09 +0100 (CET)
Received: by mail-ej1-x632.google.com with SMTP id
 a640c23a62f3a-a45ecef71deso128448766b.2
 for ; Thu, 14 Mar 2024 08:56:09 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 cb4-20020a0564020b6400b005663b0d7243sm823552edb.83.2024.03.14.08.56.07
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 14 Mar 2024 08:56:08 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5f995025-e21b-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710431769; x=1711036569; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=wOCU3NWJniNyX6fc79VPzHP9+dGIk3tKzVJn2zsQ0i8=;
        b=clcmQ9RJejav5ZJv5blLPG0p6h//6h4OtyUStyMAukM6kbUzCqTskkkkzjBR7gP50B
         m2o7iI37OH1U/HwI7WBRJGBDQFGUGI6JlVGaRVtLOjRS8S8/tSrOy+fEVxfYPM4GBbKi
         gprqvP3oGcsTLPFGoLJGvw31XEePfXbyVNNtc0DDQbiuCIgfB7yq5zZrLbw8G+gobE9e
         jsWg/9zjugZh1ss9Rj9VanLvL+dsMAvwWrSx4KK44UvInS+T1sIDLtldouIs6ExyJSn/
         tV6dj9VLbW/g7cR6xq7Y0Q8R36rhZlI8yHKBtrsR7R+F+LmVAzHl/3JzdLXFCnPu/Hx6
         26Xg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710431769; x=1711036569;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=wOCU3NWJniNyX6fc79VPzHP9+dGIk3tKzVJn2zsQ0i8=;
        b=TM5AUcUqejwYnIgWyZw6fgntTKlsG4fxFOAXCXfn+2c7gADSLddu6GztsG9QOAIt7b
         oUmCud9u3ccFiFhQkuAWWpis9S1N3LR4fhSypNcU2PZNa0mb29/roilXbapNxX5YcRbP
         k+K19fbVfiFv7mhoFFmoiRvkX1yfMYwWWJOV466sJgWQZuSTpt5EjzXkaESgngeqQBB4
         uyBUOpLMAIEG1mk/mm60zbxkhxmlFxKy5nUOnF1+M4wFk9G7C2wcYcp8yzO9aVfqZ75V
         EyNiFBFLS6B64U2rw+B02jgcu4aJs91eQQLeI3A4PAfpBb+RzOOpQ2BIqkBBv2yIqgeJ
         mRsA==
X-Forwarded-Encrypted: i=1; AJvYcCUQvIqcAhGv8um2N2k8g/I4FzQGrFMXqJWCkPuBZHttsFfSEkm/XvtcHKCnRWMm20JqkRXoJLuBv8mM8/9XaKSZbkzKKuAbELbqC2uK4ms=
X-Gm-Message-State: AOJu0Yw9SSYrfRm57uFKVCbrxGRweXSBCJ0RPaQQ0jAPudhezIklzyEE
	tkKKufKCLmjh1JkQS+CuEXpPkkg9ALm7Y7mpY2QnX0Ja853dCDWu4BEeXI5T1w==
X-Google-Smtp-Source: AGHT+IGEVsvslfT7/SAY3eNFXwst+hLJ9kwNj20DOtZxPSMdt9GSFlKzceHurGUfYH24AgzQtqqfXQ==
X-Received: by 2002:a17:907:a801:b0:a45:ca21:7694 with SMTP id vo1-20020a170907a80100b00a45ca217694mr1850235ejc.10.1710431768736;
        Thu, 14 Mar 2024 08:56:08 -0700 (PDT)
Message-ID: 
Date: Thu, 14 Mar 2024 16:56:07 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 5/7] xen/bitops: Implement ffs64() in common logic
Content-Language: en-US
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Wei Liu , Stefano Stabellini ,
 Julien Grall , Volodymyr Babchuk
 , Bertrand Marquis ,
 Michal Orzel ,
 Oleksii Kurochko ,
 Shawn Anastasio ,
 "consulting @ bugseng . com" ,
 Simone Ballarin ,
 Federico Serafini ,
 Nicola Vetrini ,
 Xen-devel 
References: <20240313172716.2325427-1-andrew.cooper3@citrix.com>
 <20240313172716.2325427-6-andrew.cooper3@citrix.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240313172716.2325427-6-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 13.03.2024 18:27, Andrew Cooper wrote:
> --- a/xen/common/bitops.c
> +++ b/xen/common/bitops.c
> @@ -47,6 +47,18 @@ static void test_ffs(void)
>      CHECK(ffsl, 1UL << (BITS_PER_LONG - 1), BITS_PER_LONG);
>      if ( BITS_PER_LONG > 32 )
>          CHECK(ffsl, 1UL << 32, 33);
> +
> +    /*
> +     * unsigned int ffs64(uint64_t)
> +     *
> +     * 32-bit builds of Xen have to split this into two adjacent operations,
> +     * so test all interesting bit positions.
> +     */
> +    CHECK(ffs64, 0, 0);
> +    CHECK(ffs64, 1, 1);
> +    CHECK(ffs64, (uint64_t)0x0000000080000000, 32);
> +    CHECK(ffs64, (uint64_t)0x0000000100000000, 33);
> +    CHECK(ffs64, (uint64_t)0x8000000000000000, 64);

I'm pretty sure Misra will want ULL suffixes on the last two and at least an UL
one on the middle of the lines. The casts aren't going to help (and could then
be dropped).

Jan


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 15:56:13 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 15:56:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693344.1081290 (Exim 4.92)
	(envelope-from )
	id 1rknRA-0007z1-40; Thu, 14 Mar 2024 15:56:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693344.1081290; Thu, 14 Mar 2024 15:56:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rknRA-0007yu-1Q; Thu, 14 Mar 2024 15:56:08 +0000
Received: by outflank-mailman (input) for mailman id 693344;
 Thu, 14 Mar 2024 15:56:07 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rknR9-0007yo-7X
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 15:56:07 +0000
Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com
 [2607:f8b0:4864:20::834])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5bd8a0b3-e21b-11ee-a1ee-f123f15fe8a2;
 Thu, 14 Mar 2024 16:56:03 +0100 (CET)
Received: by mail-qt1-x834.google.com with SMTP id
 d75a77b69052e-430a0d6c876so3244191cf.3
 for ; Thu, 14 Mar 2024 08:56:03 -0700 (PDT)
Received: from [10.80.67.149] (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 jx5-20020a0562142b0500b0068f4520e42dsm616461qvb.16.2024.03.14.08.56.00
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 14 Mar 2024 08:56:01 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5bd8a0b3-e21b-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710431762; x=1711036562; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=1cZ4RQK3/QRbhwXTVy1hgCxBHnNNmY9tzE2Sh2FydxA=;
        b=P1Uf/lofcsYpE4ZPkDkFTm0pCbvMRxwZYQHzICEHKCdM3tl4I6va/KgaSX3OJuaD0C
         VLUNAICHf5xhSsE2hcGSEMKv+iYVvOjg/Io1nXxJkikfwG7i8Z+BDZdIfw7KX3OrYuLI
         kK8jSGp4Tgx+lELoBxrOtQ9nrz/bttVH8W6Fc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710431762; x=1711036562;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=1cZ4RQK3/QRbhwXTVy1hgCxBHnNNmY9tzE2Sh2FydxA=;
        b=tyx9NsOXO5mL30o+53BHP+r3mMcfQ/+RQzmMWYBJmcKeVT7zMtAE1OGHDed/WoGNmV
         LaP+QX6ELQs8TznzAqyhALVAdsFwYjfGuX6EXhj4UljMnwv1F0Jg/AkoLDPP3P3nvItH
         DGJmrUogsW8FhrK1iptqC4ZkU5VzmvUtwTubQ4PZ9xEHOMRC7plvcCjH/+6EtTHN4Y86
         bMHFHOVTDhuoEtsQMUUvWApTxoOGSDT5JTuqM7jLSh40vI1xHGQFAoU7uVntMKXjFtQL
         5yoQW1ZS6uOO4VexjvRc1magBbqqIudy2r5c9EC7VsbPEW0ylOg0y3IoASKJQuN8Sa2m
         Rb+w==
X-Forwarded-Encrypted: i=1; AJvYcCWwbxj4GP/Hsk2sPEfucr3irjwSZD1B9MdOXQBX4wu/CRyHM0N6SJdlrUFZpIfjDbwxMSGiRrykXdOLMZT2h3wX5b6vwOA6Ai5aHgkq8NE=
X-Gm-Message-State: AOJu0YzOApgXqBlTuU+0BoslSSQstLGrim3aJ3TkaN+beCcPe5PuqCY6
	QAO20Whc1z4ZJmrmHAfEofu/gZAtPc/q5voRKnx/5SeFVQ9PXjWWyiLkXsTcv68=
X-Google-Smtp-Source: AGHT+IE1fkpWVniQXZnpVpjD9QrkVQUhmbpQ0qf62KPdP+zbWQApGqW1VEl/Xo8mnS2RLaVCaD2RxA==
X-Received: by 2002:a0c:e346:0:b0:690:bd8c:c360 with SMTP id a6-20020a0ce346000000b00690bd8cc360mr2098200qvm.43.1710431762300;
        Thu, 14 Mar 2024 08:56:02 -0700 (PDT)
Message-ID: <747617cf-e24d-4c66-988b-2fee365404a0@citrix.com>
Date: Thu, 14 Mar 2024 15:55:58 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RISCV] [PATCH 0/7] xen/bitops: Reduce the mess, starting with
 ffs()
Content-Language: en-GB
To: Jan Beulich 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Wei Liu , Stefano Stabellini ,
 Julien Grall , Volodymyr Babchuk
 , Bertrand Marquis ,
 Michal Orzel ,
 Oleksii Kurochko ,
 Shawn Anastasio ,
 "consulting @ bugseng . com" ,
 Simone Ballarin ,
 Federico Serafini ,
 Nicola Vetrini ,
 Xen-devel 
References: <20240313172716.2325427-1-andrew.cooper3@citrix.com>
 <1805b028-e21f-448f-bf94-2156092e40a5@citrix.com>
 
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 14/03/2024 3:33 pm, Jan Beulich wrote:
> On 14.03.2024 15:45, Andrew Cooper wrote:
>> On 13/03/2024 5:27 pm, Andrew Cooper wrote:
>>> Start cleaning it up with ffs() and friends.  Across the board, this adds:
>>>
>>>  * Functioning bitops without arch-specific asm
>> It turns out that RISC-V doesn't have a CLZ instruction in the base
>> ISA.  As a consequence, __builtin_ffs() emits a library call to ffs() on
>> GCC, or a de Bruijn sequence on Clang.
>>
>> The optional Zbb extension adds a CLZ instruction, after which
>> __builtin_ffs() emits a very simple sequence.
>>
>> This leaves us with several options.
>>
>> 1) Put generic_ffs() back in, although if we do this then it's going to
>> be out-of-line in lib/ where it can be mostly ignored.
>>
>> 2) Require Zbb for Xen.
>>
>> 3) Alternative it up with Zbb or generic_ffs().
>>
>>
>> I've got half a mind to do 1) irrespective.  It's mostly just shuffling
>> logic out of bitops.h into lib/.
> Yes. Might also help with the bi-sectability issue you faced.

I'm not sure it will help for bisectability in this case.  But it might
simplify some of the other rearrangements.


>> I also think we should do option 2 for RISCV.  Given the instruction
>> groups that H does mandate, it's unrealistic to expect that such a chip
>> wouldn't support Zbb/etc.
> I'm not so sure here.
>
>> Also, getting full alternatives working is yet-more work that's not
>> trivial at this point in RISCV's development.  I think it is entirely
>> reasonable to avoid this work for now, and make it a problem for anyone
>> who has an H-capable Zbb-incapable system.  (with a strong implication
>> that this is work that probably never needs to be done.)
> That's definitely for later.

The argument being made is that it seems highly unlikely for there to be
non-Zbb systems running Xen, and furthermore, if this turns out not to
be true, it is reasonable to offload the effort of making it work to
whomever has hardware looking like that.

i.e. it's fine to require Zbb at this point.

This doesn't prevent someone else doing the work to alter this in the
future, for what appears to be an absurd configuration that is unlikely
to exist in reality.

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 15:59:22 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 15:59:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693351.1081311 (Exim 4.92)
	(envelope-from )
	id 1rknUG-00011O-Og; Thu, 14 Mar 2024 15:59:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693351.1081311; Thu, 14 Mar 2024 15:59:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rknUG-00011H-Ln; Thu, 14 Mar 2024 15:59:20 +0000
Received: by outflank-mailman (input) for mailman id 693351;
 Thu, 14 Mar 2024 15:59:19 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rknUF-00011B-Is
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 15:59:19 +0000
Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com
 [2a00:1450:4864:20::636])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id cfd6cbda-e21b-11ee-a1ee-f123f15fe8a2;
 Thu, 14 Mar 2024 16:59:17 +0100 (CET)
Received: by mail-ej1-x636.google.com with SMTP id
 a640c23a62f3a-a44e3176120so149983466b.1
 for ; Thu, 14 Mar 2024 08:59:17 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 u23-20020a1709064ad700b00a4479997b97sm827987ejt.66.2024.03.14.08.59.16
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 14 Mar 2024 08:59:16 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: cfd6cbda-e21b-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710431957; x=1711036757; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=fgW6x4OIe60B2dlZUDhPbecfA3EZ1GTZVuz81ZJtJu4=;
        b=dFGviQnn/+BdwUHmAEaZjG36pLQRAy/LHdsDoxoycrT+KMzH70jORizYAhA7HW+T5H
         DvkryQ+iLOyOvJCYRDprpVLfJC4okVS72sTgEuEznRGPThCZlRSYEnknnhdpAYSfQP/0
         p6X5AKDZkdgAW5bPj/nweGn7RvqYOOQOhJBaTWC9xVpKMAJPzVfo4ZTZoM1iaAxmv/yx
         unKqXEf8ZjBvEdmg3dObZ5Q/fz8hcRGjXOBP/MDGEvxFQa5jpJyuvH1aWj3gwPbiUBpV
         2eQ7jn8reDI4matkIs2Hu6z3P7H4u2COfCkYT94W7O4gqerziXMs9hShWMvLTFiDn/r9
         9Kqw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710431957; x=1711036757;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=fgW6x4OIe60B2dlZUDhPbecfA3EZ1GTZVuz81ZJtJu4=;
        b=uLygjuwvs1f++GODGMfk9JhKXo04DKGVzE5iEMdbznPMoCTQQ+UBd7FiSVHgD3LROT
         VGZX2GUzUlnGiAxmpnJEWhN8JWpQAbxF30ZT/R+oeh+cbQW1YFpcCq9GkVqJN6bMg9ox
         v7e7EKMsh0HZE1C622mtdF8CtnO9yvxtGlo3McHtGrQ+cbaVLnoHBVKS2dEH9kAfCMhY
         G1xiuy6Ri9otbT/w3Numrmnw9kpvUK6cSd0FD4NWufuZVkPu5iENQVj+x6WjaquwQc6+
         Ww0cz8hUacdQ2FYOfZSuDtalH4w1xpm+o/x0gGhmn9kBJYVsdgnt0wnyTJpdbHCbrXR+
         NKuA==
X-Forwarded-Encrypted: i=1; AJvYcCWQkOr1Ao3KETxELMKZ2K1PEmYPkRY6H29lvdI6QaqAN+oqMOXQ7RAnvWubK/VqvUWYKN6MsIF5wBcuLXuIZHaInnS3W2QJ/ZQb/VyvuEM=
X-Gm-Message-State: AOJu0YzONmpKZWVH+/y/SVVUgdNO011cgxDApr2TY+aNn60oe+M+cBwF
	mWm1KpfzbLWcAzNRwoq9amQxnOoQuCsbBIggs8dFzZmSM0zD/HjcY19Y+WOgyQ==
X-Google-Smtp-Source: AGHT+IGWwC/XwNYlYaLKlj6hhGSuOjawQ1L55RSNxPzkUmB6xnfcUIkDuSwKGxljl3UpDQXlPSLCzg==
X-Received: by 2002:a17:906:3b42:b0:a46:5f03:fe01 with SMTP id h2-20020a1709063b4200b00a465f03fe01mr216432ejf.18.1710431956971;
        Thu, 14 Mar 2024 08:59:16 -0700 (PDT)
Message-ID: <926895a0-f777-4e17-951f-6df0cc24b0f2@suse.com>
Date: Thu, 14 Mar 2024 16:59:15 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 7/7] xen/bitops: Delete find_first_set_bit()
Content-Language: en-US
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Wei Liu , Stefano Stabellini ,
 Julien Grall , Volodymyr Babchuk
 , Bertrand Marquis ,
 Michal Orzel ,
 Oleksii Kurochko ,
 Shawn Anastasio ,
 "consulting @ bugseng . com" ,
 Simone Ballarin ,
 Federico Serafini ,
 Nicola Vetrini ,
 Xen-devel 
References: <20240313172716.2325427-1-andrew.cooper3@citrix.com>
 <20240313172716.2325427-8-andrew.cooper3@citrix.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240313172716.2325427-8-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 13.03.2024 18:27, Andrew Cooper wrote:
> --- a/xen/arch/x86/include/asm/bitops.h
> +++ b/xen/arch/x86/include/asm/bitops.h
> @@ -401,18 +401,6 @@ static always_inline unsigned int __scanbit(unsigned long val, unsigned int max)
>      r__;                                                                    \
>  })
>  
> -/**
> - * find_first_set_bit - find the first set bit in @word
> - * @word: the word to search
> - * 
> - * Returns the bit-number of the first set bit. The input must *not* be zero.
> - */
> -static inline unsigned int find_first_set_bit(unsigned long word)
> -{
> -    asm ( "rep; bsf %1,%0" : "=r" (word) : "rm" (word) );
> -    return (unsigned int)word;
> -}

And you think it's okay to no longer use TZCNT like this when available,
where the output doesn't have to have its value set up front?

Jan


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 16:04:58 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 16:04:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693357.1081324 (Exim 4.92)
	(envelope-from )
	id 1rknZc-0003Er-Cp; Thu, 14 Mar 2024 16:04:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693357.1081324; Thu, 14 Mar 2024 16:04:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rknZc-0003Ek-9H; Thu, 14 Mar 2024 16:04:52 +0000
Received: by outflank-mailman (input) for mailman id 693357;
 Thu, 14 Mar 2024 16:04:50 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rknZa-0003Ed-PS
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 16:04:50 +0000
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com
 [2a00:1450:4864:20::62a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9544480b-e21c-11ee-a1ee-f123f15fe8a2;
 Thu, 14 Mar 2024 17:04:48 +0100 (CET)
Received: by mail-ej1-x62a.google.com with SMTP id
 a640c23a62f3a-a28a6cef709so152741166b.1
 for ; Thu, 14 Mar 2024 09:04:48 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 h21-20020a17090619d500b00a46447348e8sm827048ejd.191.2024.03.14.09.04.47
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 14 Mar 2024 09:04:48 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9544480b-e21c-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710432288; x=1711037088; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=VhbS3U795qG1siKvxeuRBWc5m9VW37NK7XrVFdwFPCQ=;
        b=AC4L9lmG1DS2fudNPXuNtFrO8EnR+mgc7KpYTmpEN8gbsztvh/TNtFN7W4vkr6bBoQ
         iOCjurwiOrOPeRUjZQUY2INPvN/NXmcDjxS8TFVbxyvWkTU2ZUNgtHTVCDYISUA7xR5E
         wCg6RFOQFEEwmA6i0KIxgEkOcGSZZcy5SHg2m6gVMniuluIiio8+fWc57Kv4N6JF4hI8
         b+0qZBMjGwHI872HyL+52MBxb7yEaAuU4KSmuXpcccIoMT9B3FaggE4A7dMgOVRO4R5A
         iQzjgQu8RsuwJfEnExTSNVvtZ4gGPFYFl2c6b0nyNh9xnamwywx+gkNd0GgKp9qwIfG/
         s3ww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710432288; x=1711037088;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=VhbS3U795qG1siKvxeuRBWc5m9VW37NK7XrVFdwFPCQ=;
        b=pDvUjO7EOU19UkDH413fPv9R4E/QLLFkB8Az0d5ILg9neGCpDw0KFPpxyYxkAAlLpV
         wbQaNBh6lCXzvM26Sp0gjvw4cdWbzNF2COQ3yJkY6m/3vyJ8eq91+UoreHTd4ZYCMk4E
         eoP1EW+qxlREMFzigG9mnUWPe5IWxll0Qskuw/ENx/e2zuT5LpN96FDLWJ1gmxWk1F7e
         egLn3DO32hLPxUMA3rIkXFV+J3vARUE+ELTBFYDZtM37sJLmAFD5f32ms428k67EdhPe
         v3wuWfH2E9VnvlJOVnUAZ6q0aTWwCitEpP1BgwIS7ctprUGnwvxlJjUNjD1cBs9zQdta
         vzBg==
X-Forwarded-Encrypted: i=1; AJvYcCXq1Vy2d9Svi1EZENXEqvjLAC3lKz0GyDSLvEIyFR/y1/6kZeAV32AGYmsqyeldcr5695u/O2c3njKkpTs0XfqXDGWkl7SQxZWT6AFuya0=
X-Gm-Message-State: AOJu0Yw5ZY8ZjMsfZTCOI0RKYEyPBt4PGroeNwCU/eIcfrg5ERE+8kuh
	z5521AE8ttW88HaDz8CBXxzvR8w7wLtny8RvHhaYM5DCvl5pglmIHIV/pnOKPg==
X-Google-Smtp-Source: AGHT+IGxkQH+DOGbBNbcZAAZv+5+a9Tp9q5e+bC+JAh8tahWu9b3UYpWDlGepDupM7GQfYgaFwDx3A==
X-Received: by 2002:a17:906:ca56:b0:a43:e550:4067 with SMTP id jx22-20020a170906ca5600b00a43e5504067mr885215ejb.12.1710432288274;
        Thu, 14 Mar 2024 09:04:48 -0700 (PDT)
Message-ID: <3f8af14a-391b-46db-99cb-d7cafe126cfd@suse.com>
Date: Thu, 14 Mar 2024 17:04:46 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 2/3] x86/svm: Drop the suffix _guest from vmcb bit
Content-Language: en-US
To: Vaishali Thakkar 
Cc: andrew.cooper3@citrix.com, roger.pau@citrix.com, wl@xen.org,
 xen-devel@lists.xenproject.org
References: 
 <88d5a0ce6745428120ebc37369d3d75358d5c582.1710347950.git.vaishali.thakkar@vates.tech>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <88d5a0ce6745428120ebc37369d3d75358d5c582.1710347950.git.vaishali.thakkar@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 13.03.2024 17:41, Vaishali Thakkar wrote:
> The suffix _guest is redundant for asid bit. Drop it
> to avoid adding extra code volume.
> 
> While we're here, replace 0/1 with false/true and use
> VMCB accessors instead of open coding.
> 
> Suggested-by: Andrew Cooper 
> Signed-off-by: Vaishali Thakkar 

Reviewed-by: Jan Beulich 
with ...

> --- a/xen/arch/x86/hvm/svm/asid.c
> +++ b/xen/arch/x86/hvm/svm/asid.c
> @@ -37,14 +37,14 @@ void svm_asid_handle_vmrun(void)
>      /* ASID 0 indicates that ASIDs are disabled. */
>      if ( p_asid->asid == 0 )
>      {
> -        vmcb_set_guest_asid(vmcb, 1);
> +        vmcb_set_asid(vmcb,true);

... the blank put back that was lost here (can be done while committing).

Jan


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 16:05:50 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 16:05:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693360.1081334 (Exim 4.92)
	(envelope-from )
	id 1rknaX-0003lZ-QN; Thu, 14 Mar 2024 16:05:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693360.1081334; Thu, 14 Mar 2024 16:05:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rknaX-0003lS-Lg; Thu, 14 Mar 2024 16:05:49 +0000
Received: by outflank-mailman (input) for mailman id 693360;
 Thu, 14 Mar 2024 16:05:49 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rknaX-0003lG-4Y
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 16:05:49 +0000
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com
 [2a00:1450:4864:20::62e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b8c8af66-e21c-11ee-afdd-a90da7624cb6;
 Thu, 14 Mar 2024 17:05:48 +0100 (CET)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-a45606c8444so131431866b.3
 for ; Thu, 14 Mar 2024 09:05:48 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 h21-20020a17090619d500b00a46447348e8sm827048ejd.191.2024.03.14.09.05.47
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 14 Mar 2024 09:05:47 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b8c8af66-e21c-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710432348; x=1711037148; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=lDFQUkvNMfU2vCunQ8k56Z3/CNehReAEK/vThUwXMAg=;
        b=e6zQqz/gBf8AT1FW3wmq1dzmbNwodjAfx9FzosdAG046JK67tzBoQZh48QRjiQoFS+
         LWLBe37ll+g2pgyXKPGkJFypx1wLhmjpXBtlXBNulUOBpHPr8WlOzPP8pENUOpZ7TpO+
         hxDKH/jF4NtFi12uB/GZgG+4omWHWXSs9Z6/UlscLhzdqP1SHUFd0n4CVI0R0ta1VZeQ
         Kk2uGN5zo7l477BzaxY9GxUSDhfSXy4O3UD0W5oRQnPBdQrmA4SKBOVztsTKpPUIKsP4
         XmYS99mKK9ZK57yx+Tt5B3UA9KpbhJPa6LPvLguo1yPTWSWmN/YP2DktrEYuMywfoV8Z
         PGlA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710432348; x=1711037148;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=lDFQUkvNMfU2vCunQ8k56Z3/CNehReAEK/vThUwXMAg=;
        b=L8bCIJCrQGdN/Yyt3tIn2QLyIrb56NMIBJWYy0hWXys3KP2iP4dIwDKXdAqIfsTjTa
         dYdu+orulKof7/ebDnn00M6eNZC3+5l7htBFeWx7j3kpEg2348FBtnuYjB8PH9Wax/rs
         fqHesl+1FvHag5Pl6BgjyiJFQjqTRfFblKZu025Ees1VQDkbuAOr0+SsI7aJtRzeWhUV
         6FIu/RtRqHvXVv+dWjbrXh5Kurh0DLWZuDyarnvh9ze0RdHnkLp9/QLQOId2EmwV1UAK
         bJaq2rYuTPzq7dMMoPl4ZdLWDd7i0y/+CP9D9yOtQ46coQNR23BC/SlXQ3pJA2H/R+Vg
         3g8A==
X-Forwarded-Encrypted: i=1; AJvYcCWuJLRFhoqfjOW1vxfjdBHBNeGGCk2Mnn/wrVCc1r6MUOzR3c9EiT+sPJw/XnWGwcx2FTgow5+c+IviBoSl3+rXzG7EroYGVd9z3TNtV9s=
X-Gm-Message-State: AOJu0YzPUjqoJZnI6E9ih5exsaEFAOOYyVLYMpxMHJe1ZWvtKMytec8v
	OFwbxfXEclTzDmj8TgtQ4BXNgx3BGMvKA3Io27Hrs9n+pWLzux3kiSbTOFIJvNUorpM6PhZwjUE
	=
X-Google-Smtp-Source: AGHT+IGO6570hR7uaewWamPznXEZ5N6T/BSsXWUZmv/LNoZlsU1c95gwD2Qk2xSNBUGnr/s3wj0XPQ==
X-Received: by 2002:a17:906:ba84:b0:a46:74d2:a0c3 with SMTP id cu4-20020a170906ba8400b00a4674d2a0c3mr1644715ejd.4.1710432347990;
        Thu, 14 Mar 2024 09:05:47 -0700 (PDT)
Message-ID: <8b844971-4266-474e-b1d5-6ee40b64664e@suse.com>
Date: Thu, 14 Mar 2024 17:05:46 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 3/3] x86/svmdebug: Print np, sev and sev_es vmcb bits
Content-Language: en-US
To: Vaishali Thakkar 
Cc: andrew.cooper3@citrix.com, roger.pau@citrix.com, wl@xen.org,
 xen-devel@lists.xenproject.org
References: 
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 13.03.2024 17:41, Vaishali Thakkar wrote:
> Currently only raw _np_ctrl is being printed. It can
> be informational to know about which particular bits
> are enabled. So, this commit adds the bit-by-bit decode
> for np, sev and sev_es bits.
> 
> Note that while, only np is enabled in certain scenarios
> at the moment, work for enabling sev and sev_es is in
> progress. And it'll be useful to have this information as
> part of svmdebug.
> 
> Signed-off-by: Vaishali Thakkar 

Acked-by: Jan Beulich 




From xen-devel-bounces@lists.xenproject.org Thu Mar 14 16:22:59 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 16:22:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693370.1081343 (Exim 4.92)
	(envelope-from )
	id 1rknr2-0007eQ-46; Thu, 14 Mar 2024 16:22:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693370.1081343; Thu, 14 Mar 2024 16:22:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rknr2-0007eJ-1a; Thu, 14 Mar 2024 16:22:52 +0000
Received: by outflank-mailman (input) for mailman id 693370;
 Thu, 14 Mar 2024 16:22:51 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rknr1-0007e2-7E
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 16:22:51 +0000
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com
 [2a00:1450:4864:20::62d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1961c5ba-e21f-11ee-a1ee-f123f15fe8a2;
 Thu, 14 Mar 2024 17:22:49 +0100 (CET)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-a466c85ae5fso150941166b.0
 for ; Thu, 14 Mar 2024 09:22:49 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 f23-20020a1709067f9700b00a43e8e76825sm858769ejr.149.2024.03.14.09.22.48
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 14 Mar 2024 09:22:48 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1961c5ba-e21f-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710433369; x=1711038169; darn=lists.xenproject.org;
        h=content-transfer-encoding:autocrypt:subject:from:cc:to
         :content-language:user-agent:mime-version:date:message-id:from:to:cc
         :subject:date:message-id:reply-to;
        bh=4oVKLablG+Qh/v1xDndKOU60srso5+m5m2GRhr72xYQ=;
        b=CtglCud747GQaqIfZVK93F2bimrSM0PDKsX/ij3KhGwAzh4xhS59rMOQTCBRvYv4Xn
         G0SbNlfz1NzbI8OrkxKtn9yXt0EU0mN0C51vHkQjKPv/YZwhAYMdP9Y60gRetHDLPtSr
         5dI5vIm/Z60ilFwk2G1CRxgESLlJLSVAJG2h1NbzS+N3kfteV0hJ+JLZ0T8+6slH4lwA
         87Mze86uky14/TdYC61ANwdaXD6HbrNhNXp3SVQZhrcGcRzFhOpCo/AXLLyi6joQCt7b
         /mBSe9SDYJOztBbSPOyNGkQDwCCUw9PnvM4UOM1gxsFGZg8NwtHe5qWuNnhCmhG0eStt
         EkGg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710433369; x=1711038169;
        h=content-transfer-encoding:autocrypt:subject:from:cc:to
         :content-language:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=4oVKLablG+Qh/v1xDndKOU60srso5+m5m2GRhr72xYQ=;
        b=jV5lzgC5nnWjQDLZjRCDAUVT+mWMuIj8pcMPi9YvWJyDaQZbF4cMmEdgHGQPDjqVRd
         kLzeHSmTujTHdQ5nSFWGLZta436Ec4Cti2IAq5CtS9SKrp7FxtHZFEgIZDuyKWS74A3R
         vbNpk42PsNHWbzmuFh2sovTLKLqpg5b/7s1gkPnDzxjG4WarBHqhv6/qWlqwF3SX5zWk
         0HVWQb18g4OYfzQrkvTpWunMPEGdx3S1ykvvETL5fRumMpHLTtNIW7Mepf/XAM6UehnA
         UQ7KcWbZOTKc+YxQznswVxu+jyh0Z/4w0wEAxYRK8JvzbHbqXSypRnc6rEHDbk4fHYUo
         4a/w==
X-Gm-Message-State: AOJu0YyOfJG8Ru63D0+J0kmxJG2Klomy8ie00u4Rbopw7xsud4xg3Gcp
	5Ym1RvpsCBEg28jPr2cZ1U+JhnF/DT+2Xt2rh71Wln5/CDo7T3makHyoeJZAQ8w842L7iq3j2eE
	=
X-Google-Smtp-Source: AGHT+IEHpBMPHNk2y/WCDGyZC78ua4d9WSRUI07OpQrt8gKth9vtDS8MK3umdsi8pFcU9R5nXIJaJQ==
X-Received: by 2002:a17:907:bb8a:b0:a3e:792f:3955 with SMTP id xo10-20020a170907bb8a00b00a3e792f3955mr1739649ejc.62.1710433368788;
        Thu, 14 Mar 2024 09:22:48 -0700 (PDT)
Message-ID: <36bf6c96-c266-4908-ae85-1ec9325b5bd9@suse.com>
Date: Thu, 14 Mar 2024 17:22:47 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: "xen-devel@lists.xenproject.org" 
Cc: Kevin Tian ,
 Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
From: Jan Beulich 
Subject: [PATCH] MAINTAINERS: drop AMD IOMMU and Intel VT-d sections
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

We'd like to thank Kevin, so far the VT-d maintainer, for his past
contributions, while at the same time we'd like to reflect reality as it
has been for quite some time. Have VT-d maintainership (and for symmetry
also AMD IOMMU's) fall back to the maintainers of general x86. This also
brings things in sync with how they are for Arm.

While touching the X86 section also append two so far missing slashes.

Signed-off-by: Jan Beulich 

--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -220,12 +220,6 @@ F:	xen/drivers/acpi/
 F:	xen/include/acpi/
 F:	tools/libacpi/
 
-AMD IOMMU
-M:	Jan Beulich 
-M:	Andrew Cooper 
-S:	Maintained
-F:	xen/drivers/passthrough/amd/
-
 ARGO
 M:	Christopher Clark 
 S:	Maintained
@@ -351,11 +345,6 @@ S:	Odd Fixes
 F:	xen/arch/x86/include/asm/tboot.h
 F:	xen/arch/x86/tboot.c
 
-INTEL(R) VT FOR DIRECTED I/O (VT-D)
-M:	Kevin Tian 
-S:	Supported
-F:	xen/drivers/passthrough/vtd/
-
 IOMMU VENDOR INDEPENDENT CODE
 M:	Jan Beulich 
 R:	Roger Pau Monné 
@@ -587,9 +576,11 @@ R:	Wei Liu 
 S:	Supported
 L:	xen-devel@lists.xenproject.org
 F:	xen/arch/x86/
+F:	xen/drivers/passthrough/amd/
+F:	xen/drivers/passthrough/vtd/
 F:	xen/include/public/arch-x86/
-F:	xen/include/xen/lib/x86
-F:	xen/lib/x86
+F:	xen/include/xen/lib/x86/
+F:	xen/lib/x86/
 F:	xen/tools/gen-cpuid.py
 F:	tools/firmware/hvmloader/
 F:	tools/firmware/rombios/


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 16:24:01 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 16:24:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693372.1081353 (Exim 4.92)
	(envelope-from )
	id 1rkns8-0008Aw-E7; Thu, 14 Mar 2024 16:24:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693372.1081353; Thu, 14 Mar 2024 16:24:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkns8-0008Ap-BJ; Thu, 14 Mar 2024 16:24:00 +0000
Received: by outflank-mailman (input) for mailman id 693372;
 Thu, 14 Mar 2024 16:23:59 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkns7-0008Ag-Jn
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 16:23:59 +0000
Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com
 [2607:f8b0:4864:20::736])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 41bff52e-e21f-11ee-a1ee-f123f15fe8a2;
 Thu, 14 Mar 2024 17:23:57 +0100 (CET)
Received: by mail-qk1-x736.google.com with SMTP id
 af79cd13be357-781753f52afso67267685a.2
 for ; Thu, 14 Mar 2024 09:23:57 -0700 (PDT)
Received: from [10.80.67.149] (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 h15-20020a05620a10af00b0078861322748sm992012qkk.102.2024.03.14.09.23.54
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 14 Mar 2024 09:23:55 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 41bff52e-e21f-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710433436; x=1711038236; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=nDYxu/GWIa2hifdrZpxrefOg8QGb0tTGr/kbspM9Ja4=;
        b=WNxqxORDRe4Tt8DFVKAtCcApIr+0q1nW0ZSyPiX31y0eTB77wd3o7pBjDQFic/k1y6
         tIcQxV3oqxnXVaICujb8zj/9xsqwCB3XR8Vd6WOWjUm15n/TUlYbgsmOtQfLI4RfGxJU
         m1G7f+eC4kUfcgfJE1Yb+LuL5XEG3X8LD/BZk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710433436; x=1711038236;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=nDYxu/GWIa2hifdrZpxrefOg8QGb0tTGr/kbspM9Ja4=;
        b=srYsIo1qjnMg1fcZBpCVcT9S6epLZSfpoQlmuPdSriNgX+JbzkaMXWvchArtZ3XMys
         ln+9Th8YElLv4mHtghyF+uBLr33IF6smeN2fNwLH9WPGd8j+h66Q+Il55VBSx8KH7Ztj
         2fZRHXui971Mzjaepi4m43YqyY+8Q9xRZ3We/5+HPDpjqOS1nC3pQLWdc1ZIwht8hTcg
         TNTXDt72LpoUkcS7AFcYWBQOid5D461vTems/pxHdOT6JkO3X4K8cTQJlnhjz73APM3v
         MIBY8e4tq04G2//L3IkA7GCAFctx0bBChpR/UTdCdl1rB53N5GEByNZEkN/vqqyO4TNY
         +8BQ==
X-Forwarded-Encrypted: i=1; AJvYcCW2QBepQ2GZsGIaeYlx8zTyWs6BMGZWTSiJ1SdbZIieBs3G8IAmOTdVuI0yjL4eyc+xwBVWlAx+QHJgelT93yBTM3aVLw6OXIHgB8yfwyY=
X-Gm-Message-State: AOJu0YwiskCsBv5SKaaKm8tp7TbBr4eEyuKU5aReGhv9FwLXuvWg31kh
	v4hkNsCZYUWf7gYP+R9gtVw66wmgVYb4oRSZFMFc7azjNyxxmzK/JZ/hMI/2RVo=
X-Google-Smtp-Source: AGHT+IEoiWoAQRJk9XSdS6rJEGLf4gBKMzcz0OlRLuaAZmIm4lITzHUfBc17ecXEU/CaU0E94HuBVg==
X-Received: by 2002:a05:620a:4d5:b0:788:33e6:aac5 with SMTP id 21-20020a05620a04d500b0078833e6aac5mr2396491qks.73.1710433436507;
        Thu, 14 Mar 2024 09:23:56 -0700 (PDT)
Message-ID: <6a3c09a1-f35f-4d1e-bbba-342388da71ef@citrix.com>
Date: Thu, 14 Mar 2024 16:23:52 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/7] xen/bitops: Implement ffs() in common logic
Content-Language: en-GB
To: Jan Beulich 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Wei Liu , Stefano Stabellini ,
 Julien Grall , Volodymyr Babchuk
 , Bertrand Marquis ,
 Michal Orzel ,
 Oleksii Kurochko ,
 Shawn Anastasio ,
 "consulting @ bugseng . com" ,
 Simone Ballarin ,
 Federico Serafini ,
 Nicola Vetrini ,
 Xen-devel 
References: <20240313172716.2325427-1-andrew.cooper3@citrix.com>
 <20240313172716.2325427-3-andrew.cooper3@citrix.com>
 <76a1e81d-86d1-438c-975e-c4db46af93ee@suse.com>
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <76a1e81d-86d1-438c-975e-c4db46af93ee@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 14/03/2024 2:16 pm, Jan Beulich wrote:
> On 13.03.2024 18:27, Andrew Cooper wrote:
>> --- a/xen/arch/arm/include/asm/bitops.h
>> +++ b/xen/arch/arm/include/asm/bitops.h
>> @@ -157,7 +157,7 @@ static inline int fls(unsigned int x)
>>  }
>>  
>>  
>> -#define ffs(x) ({ unsigned int __t = (x); fls(ISOLATE_LSB(__t)); })
>> +#define arch_ffs(x) ({ unsigned int __t = (x); fls(ISOLATE_LSB(__t)); })
> The way the macro is invoked, I don't think the helper local variable
> is then needed anymore?

I strongly suspect It is still needed.  ISOLATE_LSB() double-expands its
parameter.

Either way, I'm not reopening that can of worms that lead to this form.
>> --- a/xen/arch/x86/include/asm/bitops.h
>> +++ b/xen/arch/x86/include/asm/bitops.h
>> @@ -430,16 +430,23 @@ static inline int ffsl(unsigned long x)
>>      return (int)r+1;
>>  }
>>  
>> -static inline int ffs(unsigned int x)
>> +static inline unsigned int arch_ffs(unsigned int x)
>>  {
>> -    int r;
>> +    int r = -1;
>> +
>> +    /*
>> +     * The AMD manual states that BSF won't modify the destination register if
>> +     * x=0.  The Intel manual states that the result is undefined, but the
>> +     * architects have said that the register is written back with it's old
>> +     * value, possibly zero extended above 32 bits.
>> +     */
>> +    asm ( "bsf %[val], %[res]"
>> +          : [res] "+r" (r)
>> +          : [val] "rm" (x) );
> And this isn't what the compiler would be doing anyway?

No.  The builtin avoids all undefined behaviour, and is quite a lot of
asm as a result.

With some help from the gcc mailing list
https://gcc.gnu.org/pipermail/gcc/2024-March/243465.html I've found a
solution which improves things in the common case.

> Also, just to mention it: I take it that you/we are sure that disallowing
> both operands to be the same register is still better than ...
>
>> -    asm ( "bsf %1,%0\n\t"
>> -          "jnz 1f\n\t"
>> -          "mov $-1,%0\n"
>> -          "1:" : "=r" (r) : "rm" (x));
> ... the original form?

Yes.  Without any doubt, on a 64bit CPU.

This transformation isn't safe on a 486, but I expect even the later
32bit CPUs lacking register renaming would still be better with the
non-branch form.


>> --- a/xen/include/xen/bitops.h
>> +++ b/xen/include/xen/bitops.h
>> @@ -110,6 +110,21 @@ static inline int generic_flsl(unsigned long x)
>>  
>>  #include 
>>  
>> +/*
>> + * Find First Set bit.  Bits are labelled from 1.
>> + */
>> +static always_inline __pure unsigned int ffs(unsigned int x)
> Why always_inline?

For all the normal reasons to counter Clang and GCC doing stupid things
with inlines that contain assembly.

>
>> +{
>> +    if ( __builtin_constant_p(x) )
>> +        return __builtin_ffs(x);
>> +
>> +#ifndef arch_ffs
>> +#define arch_ffs __builtin_ffs
>> +#endif
>> +
>> +    return arch_ffs(x);
>> +}
> Just to mention it: __builtin_ffs() takes and returns plain int. I'm
> happy about our own helper being unsigned-correct, but anything like
> this has a Misra angle too.

I did note that, and decided it could wait until some other point.

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 16:32:59 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 16:32:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693377.1081364 (Exim 4.92)
	(envelope-from )
	id 1rko0e-0001y0-9r; Thu, 14 Mar 2024 16:32:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693377.1081364; Thu, 14 Mar 2024 16:32:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rko0e-0001xt-5X; Thu, 14 Mar 2024 16:32:48 +0000
Received: by outflank-mailman (input) for mailman id 693377;
 Thu, 14 Mar 2024 16:32:47 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rko0d-0001xn-1i
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 16:32:47 +0000
Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com
 [2607:f8b0:4864:20::72e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7bfdf36b-e220-11ee-a1ee-f123f15fe8a2;
 Thu, 14 Mar 2024 17:32:44 +0100 (CET)
Received: by mail-qk1-x72e.google.com with SMTP id
 af79cd13be357-789d76ad270so45430385a.0
 for ; Thu, 14 Mar 2024 09:32:44 -0700 (PDT)
Received: from [10.80.67.149] (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 15-20020ac8590f000000b0042f21b795d0sm955841qty.45.2024.03.14.09.32.42
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 14 Mar 2024 09:32:43 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7bfdf36b-e220-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710433964; x=1711038764; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=zqrBUkuQNQU05sZt9Kg9g2gZXqF7A/y4fGTkRtGI9xM=;
        b=NMT4tOX7afjgsiME2MRVOBN5gfIIJjYjKuk2SLeDk6eQD45GEJd9EzRwgxmBhokqPD
         9TcBMDjyXF4E1NcMCWG2D1B5t+ntQbVH8/udV0+nUTtWWHvmqvHzBeGW2VhVFWSKQDj0
         klLIgms4fKMLyiu1wz90NIx8biyW+ovkbXbA8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710433964; x=1711038764;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=zqrBUkuQNQU05sZt9Kg9g2gZXqF7A/y4fGTkRtGI9xM=;
        b=eLMjUfoCPcs7psa6wtfskcwujL1qE//e7FJ4wfAoobB60My2gGSxUr+5imwvJl1Gre
         gOn054DE8HtZ0B1TxOxBUDO9rHoNWG7E/1Y3CAwOG7kcs6O4c0HGqISdizhsg3FGymZI
         goayayr3wYsQRjA4kET0V48j0Z/e6hbcuJgOGm+FstUMdvF3v/czTpAUi5aI9M4+zgbX
         OqH6yOyq1i+8Hj3q6juEi1oaKxbRe9eY/Iov6G/f6rrYG5uW0cLwmc/NVS/Uhw2df2U6
         CbDjRDUTk6EIlfVxA/c6mekm8qZpU6h5sYtl/9eKWjR4g3TTs3ZE3rIDjKvK4gRwuPyA
         WL3A==
X-Forwarded-Encrypted: i=1; AJvYcCX0h0ql7NZSxAZc4+xcKnFrN9cURVHfWAHKyPIqJjcHjaF0ivPs9gyoqrD+mHjEFinj7wD7FTbL43rxeaS103nhC5CehJExOQYyQg0v4Rw=
X-Gm-Message-State: AOJu0YzZDjTAFlCvbidAqiUCofvnoSBYPo3wpYuC7P4tf/evcgtnDDCx
	DGP2KJeT212uw9FWWvjdHDwwXFAbRyxSDSv8ZaiJSLGoPfUZM3LNWr+uLuvScqs=
X-Google-Smtp-Source: AGHT+IEMm2lkeGK0kzeu4fwBj9DfMwQeG/HSRrmvO8SDH8xDJmeALuv6tsuy9WeXaQ+sSeI7kdZsMA==
X-Received: by 2002:ae9:e216:0:b0:788:5e6f:53d0 with SMTP id c22-20020ae9e216000000b007885e6f53d0mr1174120qkc.44.1710433963763;
        Thu, 14 Mar 2024 09:32:43 -0700 (PDT)
Message-ID: 
Date: Thu, 14 Mar 2024 16:32:41 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] MAINTAINERS: drop AMD IOMMU and Intel VT-d sections
Content-Language: en-GB
To: Jan Beulich ,
 "xen-devel@lists.xenproject.org" 
Cc: Kevin Tian ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <36bf6c96-c266-4908-ae85-1ec9325b5bd9@suse.com>
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <36bf6c96-c266-4908-ae85-1ec9325b5bd9@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 14/03/2024 4:22 pm, Jan Beulich wrote:
> We'd like to thank Kevin, so far the VT-d maintainer, for his past
> contributions, while at the same time we'd like to reflect reality as it
> has been for quite some time. Have VT-d maintainership (and for symmetry
> also AMD IOMMU's) fall back to the maintainers of general x86. This also
> brings things in sync with how they are for Arm.
>
> While touching the X86 section also append two so far missing slashes.
>
> Signed-off-by: Jan Beulich 

Acked-by: Andrew Cooper 


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 16:33:28 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 16:33:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693379.1081374 (Exim 4.92)
	(envelope-from )
	id 1rko1H-0002VH-KU; Thu, 14 Mar 2024 16:33:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693379.1081374; Thu, 14 Mar 2024 16:33:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rko1H-0002VA-Go; Thu, 14 Mar 2024 16:33:27 +0000
Received: by outflank-mailman (input) for mailman id 693379;
 Thu, 14 Mar 2024 16:33:25 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rko1F-0002Uq-MP
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 16:33:25 +0000
Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com
 [2a00:1450:4864:20::12f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 76e93c41-e220-11ee-afdd-a90da7624cb6;
 Thu, 14 Mar 2024 17:32:35 +0100 (CET)
Received: by mail-lf1-x12f.google.com with SMTP id
 2adb3069b0e04-513d212f818so964664e87.2
 for ; Thu, 14 Mar 2024 09:32:35 -0700 (PDT)
Received: from [192.168.206.239] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 h4-20020a056512350400b00513c541dba8sm328441lfs.300.2024.03.14.09.32.34
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 14 Mar 2024 09:32:34 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 76e93c41-e220-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1710433955; x=1711038755; darn=lists.xenproject.org;
        h=mime-version:user-agent:content-transfer-encoding:references
         :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject
         :date:message-id:reply-to;
        bh=MC2xlIiAZTrvR9ntYM+yVSRnEvX4TUjWNo9cEE/e3Ds=;
        b=LUs6RVlif4ba+0yhLx3t8a9u5sYCHR+si87Kp1oENqg8Zdz/2wk1BJ/g9LbKniCTnL
         hOn3F0nxYEzzVE64n4NISwJWZ8Ot/ysWeWBSRwIdZfd1wnJk7j3IM0ybON5+qyd9WMLZ
         1DwdXailvdl4J4MOM/Gz905ApfADylc92uHrjKQd5Cd3+/IKnm7QI1TElhWIY9OJ4+jl
         Bd49cSzUrnak3XiVnQMqA8pW4VvpvHwPT2utHTK5CSkUI2MK3Zp0j5AK+k35UVtUMwl6
         KpqQAExK5Ajmso81aEsiteqP0KowLrdshD2E3kTht/uVE7jXBhoLXu/lav958TIty50q
         sZYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710433955; x=1711038755;
        h=mime-version:user-agent:content-transfer-encoding:references
         :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=MC2xlIiAZTrvR9ntYM+yVSRnEvX4TUjWNo9cEE/e3Ds=;
        b=Q7OFxq7UbeNl1okAVrOOPPNKQmdcEu3gpYvkonOdMH1g53rgqwelWIyspkRL6LvxOG
         g8FCaLpSONwdP+cpEOtiUWOF4OVM0Hnri0Ic3S5cbH7DIOqyGiJLoRBspvoT+C+6gyTC
         ecMm1nN9l1zRNDXxoWSOejk17vTaN3rcag9c4vNMFmMMo/LWYj5PqOP9xX5RuBCOftMX
         V1IPbwZz6ZjhYqIpxF7356QvncwAdGugAf+CjdFC1+6WRBslpbwkIt4awSVnGlPSpWHj
         AeRPLQTlwyjPaGUxeW3OiNmjcXq08qXxEBjeJoo00mOMY3QldeMuxEpzycIPi2ZoY0p3
         XsKw==
X-Forwarded-Encrypted: i=1; AJvYcCU0P8Jx7qq5PDvutM2EXtB/8nbGKhR4KMMVMQzOuvAGti7ZWnMrn0a/4TijjFBBkVFx4qAljylB1RFGDmCD37kzSxo7jTT+9joljxcz6j8=
X-Gm-Message-State: AOJu0YysByihzfckkzLT/iVkzhnd1GEV17gmXrT5ek6yiJ4Hw4GJwOxm
	UhQ3FMtdILQX1zCiXRbfbcYO9aMz8qXa5UREpO05ZnaNx1dsQw2T
X-Google-Smtp-Source: AGHT+IFzHfiUXap42ebsC2x25ld3F3zf9UHSZSflWpQI33y+sVa3PW5Svq1H5tORK0+kwkhJB5cBFg==
X-Received: by 2002:a19:a408:0:b0:513:572f:88f0 with SMTP id q8-20020a19a408000000b00513572f88f0mr506862lfc.41.1710433955169;
        Thu, 14 Mar 2024 09:32:35 -0700 (PDT)
Message-ID: <308749abd97ac659b09ff42b3f80f8c57cdeb51a.camel@gmail.com>
Subject: Re: [RISCV] [PATCH 0/7] xen/bitops: Reduce the mess, starting with
 ffs()
From: Oleksii 
To: Jan Beulich , Andrew Cooper
 
Cc: Roger Pau =?ISO-8859-1?Q?Monn=E9?= , Wei Liu
 , Stefano Stabellini , Julien Grall
 , Volodymyr Babchuk , Bertrand
 Marquis , Michal Orzel ,
 Shawn Anastasio , "consulting @ bugseng .
 com" , Simone Ballarin
 ,  Federico Serafini
 , Nicola Vetrini
 , Xen-devel 
Date: Thu, 14 Mar 2024 17:32:33 +0100
In-Reply-To: 
References: <20240313172716.2325427-1-andrew.cooper3@citrix.com>
	 <1805b028-e21f-448f-bf94-2156092e40a5@citrix.com>
	 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.50.2 (3.50.2-1.fc39) 
MIME-Version: 1.0

On Thu, 2024-03-14 at 16:33 +0100, Jan Beulich wrote:
> On 14.03.2024 15:45, Andrew Cooper wrote:
> > On 13/03/2024 5:27 pm, Andrew Cooper wrote:
> > > Start cleaning it up with ffs() and friends.=C2=A0 Across the board,
> > > this adds:
> > >=20
> > > =C2=A0* Functioning bitops without arch-specific asm
> >=20
> > It turns out that RISC-V doesn't have a CLZ instruction in the base
> > ISA.=C2=A0 As a consequence, __builtin_ffs() emits a library call to
> > ffs() on
> > GCC, or a de Bruijn sequence on Clang.
> >=20
> > The optional Zbb extension adds a CLZ instruction, after which
> > __builtin_ffs() emits a very simple sequence.
> >=20
> > This leaves us with several options.
> >=20
> > 1) Put generic_ffs() back in, although if we do this then it's
> > going to
> > be out-of-line in lib/ where it can be mostly ignored.
> >=20
> > 2) Require Zbb for Xen.
> >=20
> > 3) Alternative it up with Zbb or generic_ffs().
> >=20
> >=20
> > I've got half a mind to do 1) irrespective.=C2=A0 It's mostly just
> > shuffling
> > logic out of bitops.h into lib/.
>=20
> Yes. Might also help with the bi-sectability issue you faced.
>=20
> > I also think we should do option 2 for RISCV.=C2=A0 Given the
> > instruction
> > groups that H does mandate, it's unrealistic to expect that such a
> > chip
> > wouldn't support Zbb/etc.
>=20
> I'm not so sure here.
If to look at available specs of CPUs with H, then, for example, SiFive
P600 series family doesn't support Zbb extenstion:
https://sifive.cdn.prismic.io/sifive/7be0420e-dac1-4558-85bc-50c7a10787e7_p=
600_datasheet.pdf

But I asked a team who are producing CPU with H support and they have
Zbb extenstion.

>=20
> > Also, getting full alternatives working is yet-more work that's not
> > trivial at this point in RISCV's development.=C2=A0 I think it is
> > entirely
> > reasonable to avoid this work for now, and make it a problem for
> > anyone
> > who has an H-capable Zbb-incapable system.=C2=A0 (with a strong
> > implication
> > that this is work that probably never needs to be done.)
>=20
> That's definitely for later.
Considering that we are mainly using QEMU and it provides Zbb extension
we can just update -march, and that a real h/w where I can ask to test
a code also support this extenstion I will update riscv/booting.txt and
update -march.

~ Oleksii


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 16:35:08 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 16:35:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693383.1081384 (Exim 4.92)
	(envelope-from )
	id 1rko2s-000351-Ub; Thu, 14 Mar 2024 16:35:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693383.1081384; Thu, 14 Mar 2024 16:35:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rko2s-00034u-RH; Thu, 14 Mar 2024 16:35:06 +0000
Received: by outflank-mailman (input) for mailman id 693383;
 Thu, 14 Mar 2024 16:35:05 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rko2r-00034o-Ni
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 16:35:05 +0000
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com
 [2a00:1450:4864:20::62b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id cfa83ca7-e220-11ee-afdd-a90da7624cb6;
 Thu, 14 Mar 2024 17:35:04 +0100 (CET)
Received: by mail-ej1-x62b.google.com with SMTP id
 a640c23a62f3a-a468004667aso5208466b.2
 for ; Thu, 14 Mar 2024 09:35:04 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 i12-20020a1709064fcc00b00a4671721babsm775175ejw.208.2024.03.14.09.35.03
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 14 Mar 2024 09:35:04 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: cfa83ca7-e220-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710434104; x=1711038904; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=VyO1w9mGTBI1hva3ZwaMWtjIpqiAoenVVUo8FHOBu6E=;
        b=CIolnPI9ZrWJy4NXFmarjI5FkCWCygxwsFAXW5no2qYM8nKHGmFpAOSG+YoY90MtPG
         t3mx0LwysPs5EHqyOJulIj+rp95aAuDqmPTv6rUmGthYESeBunUQq8EBFq4qRHu66pCi
         SQD1UsBD3x26HCKIpuWmRnZDT3Mo5DAHRAUK9FTJ1DWe5I7Pvei1Kl/Wq6551rgcH251
         lol3HI6sRicD1cgg/q7rIA5sQF7FYzSc1VntuBxEXzxuDKRptwqebjMmpzDCUmPzmxGm
         7CiyNubBCB6ilsgnOxizMIGK1khNWaneOFpy6FhycxL+7nccBhnuPYFaDdGlIo3NJxsf
         OCMQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710434104; x=1711038904;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=VyO1w9mGTBI1hva3ZwaMWtjIpqiAoenVVUo8FHOBu6E=;
        b=aQ3UTLP3Yhvpihg2eAcLt7zfFYNQ93z8OGA14I4IPtoh3vGWxpvgPOMbc0uZUHV8dn
         GAE4aOYKhMFPyI2fh/XW980tsFRVxup+pQh8Z9xqJHJlbJVtwrI9XTDkNDV42HL/BS//
         L1c/ggDPMM7NXVGj0aBEAHpZ1ZFthZbylSZcuUMP0whR8cXeiGj6tJ6o2k/lQg/k6AyT
         yFMuFla2yXDNVZh/LKSNuQq8PmzoiBW6shGH+B+KeEUDKZAE3UXQakkjLMdb5mkbmy5v
         lHYn9jp5V1meHKD5hrJoLsbX6hvQZK6WJ50GwWefI83sBJFK3pWeTgZ3SlJ7xZJUW1UK
         sXqQ==
X-Forwarded-Encrypted: i=1; AJvYcCWGo4BGJxJePxji1Fsk50vI15d+jjn8vu4kF33dgs16DisRiNbKYLO28wUrZ8N9ziaDNlMncrJ+E+Su0oEKwbG2LR9p2rwH8j4lByPG/5g=
X-Gm-Message-State: AOJu0YweRQtWZYKDkPs9V7BqQDKgk9HWPRCye+QkVGTMbRw0WXVPY8oN
	WZHKHLYUtx9JdIFp0TBuE9EEFiZtJ9hifE/w54EDMwDjV0Yv5HHt+1rEg/KRDg==
X-Google-Smtp-Source: AGHT+IEOxPg04E7dOA8H2rbdnSzTk+WscLVX9lTCXX6ojmK3ZrLEFB+5uim0VIUZ7aaa0IjieIYHpA==
X-Received: by 2002:a17:907:8b9b:b0:a46:74d2:a0e7 with SMTP id tb27-20020a1709078b9b00b00a4674d2a0e7mr1485517ejc.11.1710434104230;
        Thu, 14 Mar 2024 09:35:04 -0700 (PDT)
Message-ID: <06cedbcc-fee9-4a58-a0bb-42f6b594ccf8@suse.com>
Date: Thu, 14 Mar 2024 17:35:02 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/7] xen/bitops: Implement ffs() in common logic
Content-Language: en-US
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Wei Liu , Stefano Stabellini ,
 Julien Grall , Volodymyr Babchuk
 , Bertrand Marquis ,
 Michal Orzel ,
 Oleksii Kurochko ,
 Shawn Anastasio ,
 "consulting @ bugseng . com" ,
 Simone Ballarin ,
 Federico Serafini ,
 Nicola Vetrini ,
 Xen-devel 
References: <20240313172716.2325427-1-andrew.cooper3@citrix.com>
 <20240313172716.2325427-3-andrew.cooper3@citrix.com>
 <76a1e81d-86d1-438c-975e-c4db46af93ee@suse.com>
 <6a3c09a1-f35f-4d1e-bbba-342388da71ef@citrix.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <6a3c09a1-f35f-4d1e-bbba-342388da71ef@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 14.03.2024 17:23, Andrew Cooper wrote:
> On 14/03/2024 2:16 pm, Jan Beulich wrote:
>> On 13.03.2024 18:27, Andrew Cooper wrote:
>>> --- a/xen/arch/arm/include/asm/bitops.h
>>> +++ b/xen/arch/arm/include/asm/bitops.h
>>> @@ -157,7 +157,7 @@ static inline int fls(unsigned int x)
>>>  }
>>>  
>>>  
>>> -#define ffs(x) ({ unsigned int __t = (x); fls(ISOLATE_LSB(__t)); })
>>> +#define arch_ffs(x) ({ unsigned int __t = (x); fls(ISOLATE_LSB(__t)); })
>> The way the macro is invoked, I don't think the helper local variable
>> is then needed anymore?
> 
> I strongly suspect It is still needed.  ISOLATE_LSB() double-expands its
> parameter.

Even that double evaluation doesn't matter when the invoking entity is an
inline function, and it doesn't use any non-trivial expression as argument.

>>> --- a/xen/include/xen/bitops.h
>>> +++ b/xen/include/xen/bitops.h
>>> @@ -110,6 +110,21 @@ static inline int generic_flsl(unsigned long x)
>>>  
>>>  #include 
>>>  
>>> +/*
>>> + * Find First Set bit.  Bits are labelled from 1.
>>> + */
>>> +static always_inline __pure unsigned int ffs(unsigned int x)
>> Why always_inline?
> 
> For all the normal reasons to counter Clang and GCC doing stupid things
> with inlines that contain assembly.

Hmm, there are issues when the asm() would look "complex" to the compiler,
but that's not the case here. I was asking because, as you imply by how
you responded, we may need to gain many more always_inline when at some
time even you were arguing against overriding compiler decisions like this
(unless I'm mis-remembering).

Jan


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 16:35:34 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 16:35:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693384.1081393 (Exim 4.92)
	(envelope-from )
	id 1rko3K-0003Xm-5S; Thu, 14 Mar 2024 16:35:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693384.1081393; Thu, 14 Mar 2024 16:35:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rko3K-0003Xf-2z; Thu, 14 Mar 2024 16:35:34 +0000
Received: by outflank-mailman (input) for mailman id 693384;
 Thu, 14 Mar 2024 16:35:33 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rko3J-0003WM-E5
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 16:35:33 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id df84be04-e220-11ee-a1ee-f123f15fe8a2;
 Thu, 14 Mar 2024 17:35:31 +0100 (CET)
Received: from truciolo.bugseng.com (unknown [37.161.186.27])
 by support.bugseng.com (Postfix) with ESMTPSA id EDD644EE0739;
 Thu, 14 Mar 2024 17:35:29 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: df84be04-e220-11ee-a1ee-f123f15fe8a2
From: Federico Serafini 
To: xen-devel@lists.xenproject.org
Cc: consulting@bugseng.com,
	Federico Serafini ,
	Simone Ballarin ,
	Doug Goldstein ,
	Stefano Stabellini ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Wei Liu 
Subject: [XEN PATCH] automation/eclair: allow parameter name "unused"
Date: Thu, 14 Mar 2024 17:35:21 +0100
Message-Id: 
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Update ECLAIR configuration of MISRA C:2012 Rule 8.3 to deviate
violations involving parameter name "unused":
it makes explicit the intention of not using the parameter within
the function.

Signed-off-by: Federico Serafini 
---
 automation/eclair_analysis/ECLAIR/deviations.ecl | 4 ++++
 docs/misra/deviations.rst                        | 5 +++++
 2 files changed, 9 insertions(+)

diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
index 9ac3ee4dfd..7e913050d2 100644
--- a/automation/eclair_analysis/ECLAIR/deviations.ecl
+++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
@@ -167,6 +167,10 @@ const-qualified."
 -config=MC3R1.R8.3,reports+={deliberate,"any_area(any_loc(file(adopted_decompress_r8_3)))&&any_area(any_loc(file(^xen/include/xen/decompress\\.h$)))"}
 -doc_end
 
+-doc_begin="Parameter name \"unused\" is deliberate and makes explicit the intention of not using the parameter within the function."
+-config=MC3R1.R8.3,reports+={deliberate, "any_area(^.*parameter `unused'.*$)"}
+-doc_end
+
 -doc_begin="The following file is imported from Linux: ignore for now."
 -file_tag+={adopted_time_r8_3,"^xen/arch/x86/time\\.c$"}
 -config=MC3R1.R8.3,reports+={deliberate,"any_area(any_loc(file(adopted_time_r8_3)))&&(any_area(any_loc(file(^xen/include/xen/time\\.h$)))||any_area(any_loc(file(^xen/arch/x86/include/asm/setup\\.h$))))"}
diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
index ce855ddae6..941da4c40b 100644
--- a/docs/misra/deviations.rst
+++ b/docs/misra/deviations.rst
@@ -157,6 +157,11 @@ Deviations related to MISRA C:2012 Rules:
          - xen/common/unxz.c
          - xen/common/unzstd.c
 
+   * - R8.3
+     - Parameter name "unused" is deliberate and makes explicit the intention
+       of not using the parameter within the function.
+     - Tagged as `deliberate` for ECLAIR.
+
    * - R8.4
      - The definitions present in the files 'asm-offsets.c' for any architecture
        are used to generate definitions for asm modules, and are not called by
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Thu Mar 14 16:48:27 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 16:48:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693394.1081404 (Exim 4.92)
	(envelope-from )
	id 1rkoFh-00063c-A7; Thu, 14 Mar 2024 16:48:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693394.1081404; Thu, 14 Mar 2024 16:48:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkoFh-00063V-6I; Thu, 14 Mar 2024 16:48:21 +0000
Received: by outflank-mailman (input) for mailman id 693394;
 Thu, 14 Mar 2024 16:48:19 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkoFf-00063P-Kd
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 16:48:19 +0000
Received: from mail-yw1-x1130.google.com (mail-yw1-x1130.google.com
 [2607:f8b0:4864:20::1130])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a87019b4-e222-11ee-afdd-a90da7624cb6;
 Thu, 14 Mar 2024 17:48:18 +0100 (CET)
Received: by mail-yw1-x1130.google.com with SMTP id
 00721157ae682-609f060cbafso14318067b3.0
 for ; Thu, 14 Mar 2024 09:48:18 -0700 (PDT)
Received: from [192.168.206.239] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 z7-20020a81ac47000000b00607b9efdf49sm344264ywj.2.2024.03.14.09.48.13
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 14 Mar 2024 09:48:16 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a87019b4-e222-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1710434897; x=1711039697; darn=lists.xenproject.org;
        h=mime-version:user-agent:content-transfer-encoding:references
         :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject
         :date:message-id:reply-to;
        bh=ZrtCJv4jEEbuCG8j1AngvJejGsg0ASv5ZPzIuzlQyBw=;
        b=lyetR0FdOCi4aaqoQR5PrDofxluTK2xV0Wxpizc48pnOrkI22YzG/owLn6RoIVVALd
         UK6S+78CU69hwMPhoxUkkkdXtfsnJA6UzkVJijhA1TGKjFiyS7bZRjfcctFP2Q+m5bvv
         NI/wufZgfRC+CxHry/322ZQKdrEPNKi7apYDO85vb8OUX2/qaPTlH9Jj6F/E91t67v5w
         IFkkdVoV1r7r1+UddU6LvBliz+BptlAZnJbcd93opHUOgSoydMZGKZoShCavqWeNrhZO
         kKEAgFEXGx6az+g3+pSjQYBroLbZTXX0xh5Pqt9A4hOD4XtK7l2/enCI1bj6mGI+keTb
         EtNg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710434897; x=1711039697;
        h=mime-version:user-agent:content-transfer-encoding:references
         :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=ZrtCJv4jEEbuCG8j1AngvJejGsg0ASv5ZPzIuzlQyBw=;
        b=uCpPiS0wjNjsN/Ltgn1sYHFqIe7lqZbj7DZUnjP7f5sLRAaHY2fByaurF//JCH4GQ+
         QMbYxkASkkzKfGTPD3QXDPBfZLKgiokTJun9fEV30Ps4s5t4m07f0MM027Y7OdbfvhR6
         3aMQEQygQPz1hQWGuq9ZPbZ0SY+dGrxSikyNBnZ1ffJVGZ5qoOvkjdjLQ8URfYa7m2Rm
         bwZBApOJHlyT36OroUKe5QWnbGXL8QpMaSae1xocmjYSa90YuQkzAwHslFeV3z/yfITQ
         28/ER7kxbbXXCEYh5ZR94iD0f6oPzfS6C7Q6hKre8LKrVy5Ifn9JJQ/k87T5GlQiX09N
         J/Sg==
X-Forwarded-Encrypted: i=1; AJvYcCUIPZi58lj0GNAFvIJ66Q5sZZyfIFgRZa9SgDLsI3u4XiaDMdq2PfzF99AMwNnxtaruLPdNMNcxJnCsduahXrox/NW/JIbhU9vd5N76HYk=
X-Gm-Message-State: AOJu0Yw5dmBD0teY4PLi4uj8Slr2F4yFIMiwkDpNVekWSzjWXWHfuynR
	89hrMAgZ+hagsIjvF9RjOb3DDuQcGp3Z5xx+IoEI+gyEnmKfJZFL
X-Google-Smtp-Source: AGHT+IHZZxsQ0foAXkw5kfSM5tw8VR+078au92m/r4jWIbyvf83eR1WEvQALFVfz8gF4iOuqrqAwuQ==
X-Received: by 2002:a81:b61a:0:b0:60c:d230:49d0 with SMTP id u26-20020a81b61a000000b0060cd23049d0mr1258420ywh.2.1710434897254;
        Thu, 14 Mar 2024 09:48:17 -0700 (PDT)
Message-ID: 
Subject: Re: [PATCH 6/7] xen: Swap find_first_set_bit() for ffsl() - 1
From: Oleksii 
To: Jan Beulich , Andrew Cooper
 
Cc: Roger Pau =?ISO-8859-1?Q?Monn=E9?= , Wei Liu
 , Stefano Stabellini , Julien Grall
 , Volodymyr Babchuk , Bertrand
 Marquis , Michal Orzel ,
 Shawn Anastasio , "consulting @ bugseng .
 com" , Simone Ballarin
 ,  Federico Serafini
 , Nicola Vetrini
 , Xen-devel 
Date: Thu, 14 Mar 2024 17:48:12 +0100
In-Reply-To: 
References: <20240313172716.2325427-1-andrew.cooper3@citrix.com>
	 <20240313172716.2325427-7-andrew.cooper3@citrix.com>
	 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.50.2 (3.50.2-1.fc39) 
MIME-Version: 1.0

On Thu, 2024-03-14 at 15:30 +0100, Jan Beulich wrote:
> On 13.03.2024 18:27, Andrew Cooper wrote:
> > --- a/xen/drivers/passthrough/x86/iommu.c
> > +++ b/xen/drivers/passthrough/x86/iommu.c
> > @@ -641,7 +641,7 @@ struct page_info *iommu_alloc_pgtable(struct
> > domain_iommu *hd,
> > =C2=A0=C2=A0=C2=A0=C2=A0 if ( contig_mask )
> > =C2=A0=C2=A0=C2=A0=C2=A0 {
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /* See pt-contig-marke=
rs.h for a description of the marker
> > scheme. */
> > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 unsigned int i, shift =3D f=
ind_first_set_bit(contig_mask);
> > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 unsigned int i, shift =3D f=
fsl(contig_mask) - 1;
>=20
> The need for subtracting 1 is why personally I dislike ffs() / ffsl()
> (and
> why I think find_first_set_bit() and __ffs() (but no __ffsl()) were
> introduced).
>=20
> But what I first of all would like to have clarification on is what
> your
> (perhaps just abstract at this point) plans are wrt ffz() / ffzl().
> Potential side-by-side uses would be odd now, and would continue to
> be odd
> if the difference in bit labeling was retained. Since we're switching
> to
> a consolidated set of basic helpers, such an anomaly would better not
> survive imo.
Right now, ffz() is defined as __ffs(~(x)), so and it seems to me
__ffs()/ffz() exist only as a Linux compatible, so I wanted as a part
of RISC-V patch series put into xen/linux-compat.h and just include
this header where it will be necessary:

#define __ffs(x) (ffs(~(x)) - 1)
#define ffz(x) __ffs(~(x))

Why should we care about ffzl()? It is not used in Xen, is it?

~ Oleksii




From xen-devel-bounces@lists.xenproject.org Thu Mar 14 16:48:59 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 16:48:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693396.1081414 (Exim 4.92)
	(envelope-from )
	id 1rkoGJ-0006ev-HQ; Thu, 14 Mar 2024 16:48:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693396.1081414; Thu, 14 Mar 2024 16:48:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkoGJ-0006eo-EI; Thu, 14 Mar 2024 16:48:59 +0000
Received: by outflank-mailman (input) for mailman id 693396;
 Thu, 14 Mar 2024 16:48:58 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkoGI-00063P-6s
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 16:48:58 +0000
Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com
 [2607:f8b0:4864:20::82b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id bfbff003-e222-11ee-afdd-a90da7624cb6;
 Thu, 14 Mar 2024 17:48:57 +0100 (CET)
Received: by mail-qt1-x82b.google.com with SMTP id
 d75a77b69052e-42ee2012bf0so9277301cf.0
 for ; Thu, 14 Mar 2024 09:48:57 -0700 (PDT)
Received: from localhost ([85.31.135.62]) by smtp.gmail.com with ESMTPSA id
 s2-20020a05622a1a8200b0042f3098f410sm973946qtc.48.2024.03.14.09.48.55
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 14 Mar 2024 09:48:55 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: bfbff003-e222-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710434936; x=1711039736; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=QhGTgxGuc/vLdL7mOaAwiaCw8lqrwm8qGBnkXKqns0I=;
        b=dymGnHUJ2txuuBK8rpm8LtIeoJOWHht2QQH5npwcLVs+eQMmgUPYCvINiUXVARYFZ6
         ZQ4uRV/02RLOx7izfNqwaAR6AkSFOC0+mxj9+ga8ARuOsywVf88zPtCkCL9P25F9M06T
         9CfjpDtgSHaBnpK5dJUW4F0EsAS9J0BqB/8d0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710434936; x=1711039736;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=QhGTgxGuc/vLdL7mOaAwiaCw8lqrwm8qGBnkXKqns0I=;
        b=lUk2Y4C+RV+mDGYbPyHffH+MgwyfqUx/mstQeEttI8LQVEyY7plbVU3Lu0cWqk7y1z
         JgoClL8hNy77l8+FYeNzbFVt0o1wObug5sM/aFhpldK5zYsJejHbPdPcQU6CztZDrFva
         eaK6+xlmzKXVW1V/jWG8ar+RFnH9+Y1tWXGzd85Z9c8C32M9k5TMqms8ezSnuNH6WsJi
         SopmPisaLtGeL+JIQwGVQIMLoVHaQxzSukT7VMkuob2hiNHeu1b4WvqDjgXYfYO3sW1M
         cO+dHgglD2q79mBEXJ97vd7exnXMLeKLNUgJpSh8EBuHPUGuYmjIna5UAMF9yYfwxxt7
         ayuA==
X-Gm-Message-State: AOJu0YwJK737YCFkaeSSap8fe4cG5JtRQArXlSRwNuUsr5ClZqW8oJBf
	bS0FVkQhFuDjnk8MOKuNn+Taq8tp3cgBHBDDGXyG5OQS8ZcgYw73ypgzmvbLhp4=
X-Google-Smtp-Source: AGHT+IGYt+PP1Ggwp+R99Iysek8feMjPiPu4EcUHmK1JGRSpH5ltzDmKJOztUNPzMHEdBJ/bPaRwKw==
X-Received: by 2002:ac8:590f:0:b0:42e:f55f:3922 with SMTP id 15-20020ac8590f000000b0042ef55f3922mr3599046qty.26.1710434936278;
        Thu, 14 Mar 2024 09:48:56 -0700 (PDT)
Date: Thu, 14 Mar 2024 17:48:53 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper , Wei Liu ,
	George Dunlap ,
	Julien Grall ,
	Stefano Stabellini ,
	Jason Andryuk 
Subject: Re: [PATCH v2 3/3] x86/PVH: Support relocatable dom0 kernels
Message-ID: 
References: <20240313193021.241764-1-jason.andryuk@amd.com>
 <20240313193021.241764-4-jason.andryuk@amd.com>
 
 
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Thu, Mar 14, 2024 at 04:30:05PM +0100, Jan Beulich wrote:
> On 14.03.2024 15:33, Roger Pau Monné wrote:
> > On Thu, Mar 14, 2024 at 09:51:22AM -0400, Jason Andryuk wrote:
> >> On 2024-03-14 05:48, Roger Pau Monné wrote:
> >>> On Wed, Mar 13, 2024 at 03:30:21PM -0400, Jason Andryuk wrote:
> >>>> @@ -234,6 +235,17 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
> >>>>                   elf_note_numeric_array(elf, note, 8, 0),
> >>>>                   elf_note_numeric_array(elf, note, 8, 1));
> >>>>           break;
> >>>> +
> >>>> +    case XEN_ELFNOTE_PVH_RELOCATION:
> >>>> +        if ( elf_uval(elf, note, descsz) != 3 * sizeof(uint64_t) )
> >>>> +            return -1;
> >>>> +
> >>>> +        parms->phys_min = elf_note_numeric_array(elf, note, 8, 0);
> >>>> +        parms->phys_max = elf_note_numeric_array(elf, note, 8, 1);
> >>>> +        parms->phys_align = elf_note_numeric_array(elf, note, 8, 2);
> >>>
> >>> Size for those needs to be 4 (32bits) as the entry point is in 32bit
> >>> mode?  I don't see how we can start past the 4GB boundary.
> >>
> >> I specified the note as 3x 64bit values.  It seemed simpler than trying to
> >> support both 32bit and 64bit depending on the kernel arch.  Also, just using
> >> 64bit provides room in case it is needed in the future.
> > 
> > Why do you say depending on the kernel arch?
> > 
> > PVH doesn't know the bitness of the kernel, as the kernel entry point
> > is always started in protected 32bit mode.  We should just support
> > 32bit values, regardless of the kernel bitness, because that's the
> > only range that's suitable in order to jump into the entry point.
> > 
> > Note how XEN_ELFNOTE_PHYS32_ENTRY is also unconditionally a 32bit
> > integer.
> > 
> >> Do you want the note to be changed to 3x 32bit values?
> > 
> > Unless anyone objects, yes, that's would be my preference.
> 
> As mentioned elsewhere, unless the entire note is meant to be x86-specific,
> this fixed-32-bit property then would want limiting to x86.

Elfnotes are used only on x86 so far.  I don't see why if/when another
architecture wants to use the same elfnotes names with different field
sizes that would be an issue.  When such a need arises we could
clarify that 32-bit size is only for x86 and also specify the size for
the other architecture.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 16:55:57 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 16:55:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693400.1081423 (Exim 4.92)
	(envelope-from )
	id 1rkoMz-0000Oz-9P; Thu, 14 Mar 2024 16:55:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693400.1081423; Thu, 14 Mar 2024 16:55:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkoMz-0000Os-6d; Thu, 14 Mar 2024 16:55:53 +0000
Received: by outflank-mailman (input) for mailman id 693400;
 Thu, 14 Mar 2024 16:55:51 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkoMx-0000Om-Dh
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 16:55:51 +0000
Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com
 [2a00:1450:4864:20::636])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b5f108e8-e223-11ee-afdd-a90da7624cb6;
 Thu, 14 Mar 2024 17:55:50 +0100 (CET)
Received: by mail-ej1-x636.google.com with SMTP id
 a640c23a62f3a-a450bedffdfso136634466b.3
 for ; Thu, 14 Mar 2024 09:55:50 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 k23-20020a1709063e1700b00a4636d9d28dsm872349eji.69.2024.03.14.09.55.48
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 14 Mar 2024 09:55:49 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b5f108e8-e223-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710435349; x=1711040149; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=tyqK0iqMM6FVsPeF8OFoEKVxujQqI3d8zXfZTvnDxJ4=;
        b=YOueGrIijVcK3gWSKWMK3rkucXWM2VZLShdDUFtiD8tcHq5yg31h0thhyhf9TRcH5M
         37BzwXz6489xxZ0KdJXx4Xk/oCXDbqJ3+C4AzEinwz5aMzt7emKMmiCh605AJWUscP+L
         5WNYbsti6ZJLtfRHAOXOZem+T6rw83OIxZXVFwdyVcVcvoOotemoiMq7217y9UFWd9rC
         6cyG1kV7gsKwj/G8bJVN5y3vUM0bAN+gZ/Qwt+7eSuxytp4IyHpX8RMni9MP2lZ84BNi
         oxlCq2jLOkbss1bvIgq4UvFnDM3Sot1V+y5ce5p8WOaw3mgCjQkD4rMuN2+0wReLN0v8
         cM2w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710435349; x=1711040149;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=tyqK0iqMM6FVsPeF8OFoEKVxujQqI3d8zXfZTvnDxJ4=;
        b=tw9ohHl9htP6lsyeOHB1M9BghpyIPzc/ERG+rLba2pK/5MU/4j6n4LnE8cP1FrkP4Q
         B9p0UmFxBCICastptSU87tjtqoBXFqcGtiCR5f/6YHTFU0L7kngO4uR0KaYF16BVTX99
         hnT/UJnX613KjaUidlYajCmxaRbdsO30XUCCHhpLEMg/Hjei5729m+c2LmA8VVYbe5ZO
         pe7U7j1EFOYfGeEDZ+oVaVyiI2xlSZxsgNEKJQOn0EWM7cxsSvUfVfHYfk0qU+EuCd/G
         BWGTWjq62fsw8/3ZQq7VHu9fpw5/PBhj+axQWzy989W6TXxds838Nhcy2KC7MvXX+1it
         XI0A==
X-Forwarded-Encrypted: i=1; AJvYcCVKZBJb5AbhuCrW5yeozSFPT0ruZxQc1Eky7iHnVlEkh8/B+hBh2WdkrtH6j5VBNaBlXxYjz3cQqY+B2ivvpNWu5Lbqsu/iUvRaipr12/U=
X-Gm-Message-State: AOJu0YwlEMgtDAGmvJ43NVpj5nWf/q91a/bCYGWNhFbGAs5SYQFesQYo
	+knftOwl00C7UIWcXxb7N3XMExK6Fhl7n3eR9xYPE2v0RcUxeeFcfC+G0YVXyw==
X-Google-Smtp-Source: AGHT+IFisFGeVFtiHCWotiAmC1F2QHh6y0aUFfAnuPqup6HdxI7yadrGPhRRfyvjsrw2hbt4esXqyQ==
X-Received: by 2002:a17:907:724f:b0:a46:70d1:dda6 with SMTP id ds15-20020a170907724f00b00a4670d1dda6mr1797635ejc.28.1710435349425;
        Thu, 14 Mar 2024 09:55:49 -0700 (PDT)
Message-ID: <98c40483-e291-4a56-acd7-6e6d1ef15178@suse.com>
Date: Thu, 14 Mar 2024 17:55:47 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 6/7] xen: Swap find_first_set_bit() for ffsl() - 1
Content-Language: en-US
To: Oleksii 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Wei Liu , Stefano Stabellini ,
 Julien Grall , Volodymyr Babchuk
 , Bertrand Marquis ,
 Michal Orzel ,
 Shawn Anastasio ,
 "consulting @ bugseng . com" ,
 Simone Ballarin ,
 Federico Serafini ,
 Nicola Vetrini ,
 Xen-devel ,
 Andrew Cooper 
References: <20240313172716.2325427-1-andrew.cooper3@citrix.com>
 <20240313172716.2325427-7-andrew.cooper3@citrix.com>
 
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 14.03.2024 17:48, Oleksii wrote:
> On Thu, 2024-03-14 at 15:30 +0100, Jan Beulich wrote:
>> On 13.03.2024 18:27, Andrew Cooper wrote:
>>> --- a/xen/drivers/passthrough/x86/iommu.c
>>> +++ b/xen/drivers/passthrough/x86/iommu.c
>>> @@ -641,7 +641,7 @@ struct page_info *iommu_alloc_pgtable(struct
>>> domain_iommu *hd,
>>>      if ( contig_mask )
>>>      {
>>>          /* See pt-contig-markers.h for a description of the marker
>>> scheme. */
>>> -        unsigned int i, shift = find_first_set_bit(contig_mask);
>>> +        unsigned int i, shift = ffsl(contig_mask) - 1;
>>
>> The need for subtracting 1 is why personally I dislike ffs() / ffsl()
>> (and
>> why I think find_first_set_bit() and __ffs() (but no __ffsl()) were
>> introduced).
>>
>> But what I first of all would like to have clarification on is what
>> your
>> (perhaps just abstract at this point) plans are wrt ffz() / ffzl().
>> Potential side-by-side uses would be odd now, and would continue to
>> be odd
>> if the difference in bit labeling was retained. Since we're switching
>> to
>> a consolidated set of basic helpers, such an anomaly would better not
>> survive imo.
> Right now, ffz() is defined as __ffs(~(x)), so and it seems to me
> __ffs()/ffz() exist only as a Linux compatible, so I wanted as a part
> of RISC-V patch series put into xen/linux-compat.h and just include
> this header where it will be necessary:
> 
> #define __ffs(x) (ffs(~(x)) - 1)
> #define ffz(x) __ffs(~(x))

Well, right now ffz() is used in just a single file. One option therefore
would be to not have it available generally, and - as you say - if need
be supply it in linux-compat.h. Another option would be to have something
along its lines generally available, if we deem it useful.

> Why should we care about ffzl()? It is not used in Xen, is it?

I find it odd to have ffs() and ffsl(), but then ffz() without ffzl().
That's not my understanding of a generally useful (and largely free of
surprises) set of library routines.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 16:59:40 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 16:59:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693405.1081434 (Exim 4.92)
	(envelope-from )
	id 1rkoQc-0001GG-Pk; Thu, 14 Mar 2024 16:59:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693405.1081434; Thu, 14 Mar 2024 16:59:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkoQc-0001G9-M8; Thu, 14 Mar 2024 16:59:38 +0000
Received: by outflank-mailman (input) for mailman id 693405;
 Thu, 14 Mar 2024 16:59:37 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkoQb-0001G3-DL
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 16:59:37 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on20600.outbound.protection.outlook.com
 [2a01:111:f403:2418::600])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3b783b32-e224-11ee-a1ee-f123f15fe8a2;
 Thu, 14 Mar 2024 17:59:34 +0100 (CET)
Received: from BLAPR03CA0119.namprd03.prod.outlook.com (2603:10b6:208:32a::34)
 by IA0PR12MB8745.namprd12.prod.outlook.com (2603:10b6:208:48d::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.19; Thu, 14 Mar
 2024 16:59:28 +0000
Received: from BN3PEPF0000B071.namprd04.prod.outlook.com
 (2603:10b6:208:32a:cafe::a9) by BLAPR03CA0119.outlook.office365.com
 (2603:10b6:208:32a::34) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.21 via Frontend
 Transport; Thu, 14 Mar 2024 16:59:25 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 BN3PEPF0000B071.mail.protection.outlook.com (10.167.243.116) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7386.12 via Frontend Transport; Thu, 14 Mar 2024 16:59:25 +0000
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 14 Mar
 2024 11:59:24 -0500
Received: from [172.17.162.8] (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Thu, 14 Mar 2024 11:59:23 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3b783b32-e224-11ee-a1ee-f123f15fe8a2
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=AZm0f1OsglXIhLirbMUs4HjIOtZA6h1TD03ux0JRagDYTuwd0fz8OI73OfdwejO1M13i0E0QQTHsg6jkXuVPxe4dRaJJeta8/mvo4NSsllLGXc7PpOOZ7UApXxtMTrtPJW0niUDDItMA5WQ92dU6NeT5UchSBea79JaUYdBS9YvGVcFDqBNmh5RO+vtDvHH+gd9h8g0OkNefaS8k0rJPdpE6ExRwQq2RC74NXupWLgPJ8KNpeZcuqemp+IWd4BtRlNFTxR1wpDzKsQGjD+40Jq+0aY16/Wh+XlzlJBPEMvLw0yV8T/v5tp5W6YFWRpE8ajptlQSeE2kDi+phjn27fQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=wiNG0Ak7+U+SIt+PZ8WIA6lzrnMnIqjZFnuNRPS1Kek=;
 b=E1NRIY1s28M4KYgIz5EZsg5tAA7tJituL8pKYA4Ky1ROxHeo6ioYyehDAvih/8lw/pwGkTZPWObo/euHYkOP3Q/GHua9/g3nJPujyNSmTqh8HMcc0ptXQCD+b1aPi5htvhDNo98HbF3zz23jz1IXae69x4jiTH1J/VqwljPCua9jRkzz1ZA6B4D2E7NCMbqu3UmRCJSG8LDRtCX1zGGSHjeGELNF/fpMura6U6JBlCnyvTJSa1r9FNsFbPOmeV4Ujc9SdIj/ejOMLoYXBAIBl9SaPyEAvnWj7dRMKgJ6kbsI4EgwtMBDcyVTuBYRLRhB4PiJpJlj7gFz3cp4XyVaJg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=wiNG0Ak7+U+SIt+PZ8WIA6lzrnMnIqjZFnuNRPS1Kek=;
 b=GfasofVWOhdoqmaqGG8MGEghDij5LB3ExjBN6YIafPt0PLKpTHTeHjuIOu0YStgU33uHEjfBNAmbbSEe4U7v6cjpRyGPfJwQCoav2pWGq8s7nB6n7NdQCLZF+xHREkn2EdZvtb02vyNRtWrWoJcQoFJwg8FHFGQW7KhItTrbV8o=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
Message-ID: 
Date: Thu, 14 Mar 2024 12:59:19 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 3/3] x86/PVH: Support relocatable dom0 kernels
Content-Language: en-US
To: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
	
CC: , Andrew Cooper
	, Wei Liu , George Dunlap
	, Julien Grall , Stefano Stabellini
	
References: <20240313193021.241764-1-jason.andryuk@amd.com>
 <20240313193021.241764-4-jason.andryuk@amd.com> 
  
 
From: Jason Andryuk 
In-Reply-To: 
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
Received-SPF: None (SATLEXMB03.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN3PEPF0000B071:EE_|IA0PR12MB8745:EE_
X-MS-Office365-Filtering-Correlation-Id: d89d4ca4-2ace-46b3-8cbd-08dc44481ade
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	T9j7NPn5mk0mBajiXAjU1lvHF5A0YhcqPbSle135i615wC+3XV7Ptu4PBWFWkFnwELkHMvJM5HFdYtQi/JFotGqs0zbjxlkXfBr/1P3QNCsFGKYmsru5oNKHVXEUZnG3fFrkr6tuZKWp27dzzSePTESyMI6fpik1tnds9Vb4vuEO840sSOh0oGLvZc2CskAvcXE81Oitk/nWxbSPImYfzEvKd92L7rO0UnoRGvbm7l5qLeB/ZV+nzjc6Bk3K55eHH5rfN+1AmPADobOiLh8x19bVaSVNquPKIjkhoCdtr/Xbrtdh2M1SEVpwR1tkj/iytqYbewjwlMiIM7utwPPlFyN+jRPVA6Rdtkbe3P2uyGV3L/wtkd8ZZUmAVmuaGTMcHx96YG/ftrvCso5wxUrnLZmX9qfFfoBd6TMkOj2H9t4EoZKf/NzS4faCwyBQYnH86VoKNI7gzvsMQ2uFYjk3MkpGvRkPxdEvkE+DJ3WNrEDuxO2ISP9+n7UHckCJ/QmIUszmyo/cJPcVWJ8TQsNyW7j9k7k4TFxfnvst4Iq0DbtmD1m4oqFGzspu4w0wt8HZGT24vJUBoqLqw06gggN34Xtc7Ghb/1CnilhNlDIN6HyAtMFFMtKgC+ILvDuP7EJs1jWHvme/e7WNQlWtfQ0CjlAh+pYBYL8M9XeF8HwQCR5inuAcftjJaJJPft6Bim5e3z917QJBZv37gOGnurVKITkPio+jK7ddqJpr+abHba7uHH+CitTCj5+pTIpAaIjG
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(376005)(82310400014)(1800799015)(36860700004);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Mar 2024 16:59:25.8425
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: d89d4ca4-2ace-46b3-8cbd-08dc44481ade
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN3PEPF0000B071.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR12MB8745

On 2024-03-14 11:30, Jan Beulich wrote:
> On 14.03.2024 15:33, Roger Pau Monné wrote:
>> On Thu, Mar 14, 2024 at 09:51:22AM -0400, Jason Andryuk wrote:
>>> On 2024-03-14 05:48, Roger Pau Monné wrote:
>>>> On Wed, Mar 13, 2024 at 03:30:21PM -0400, Jason Andryuk wrote:
>>>>> @@ -234,6 +235,17 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
>>>>>                    elf_note_numeric_array(elf, note, 8, 0),
>>>>>                    elf_note_numeric_array(elf, note, 8, 1));
>>>>>            break;
>>>>> +
>>>>> +    case XEN_ELFNOTE_PVH_RELOCATION:
>>>>> +        if ( elf_uval(elf, note, descsz) != 3 * sizeof(uint64_t) )
>>>>> +            return -1;
>>>>> +
>>>>> +        parms->phys_min = elf_note_numeric_array(elf, note, 8, 0);
>>>>> +        parms->phys_max = elf_note_numeric_array(elf, note, 8, 1);
>>>>> +        parms->phys_align = elf_note_numeric_array(elf, note, 8, 2);
>>>>
>>>> Size for those needs to be 4 (32bits) as the entry point is in 32bit
>>>> mode?  I don't see how we can start past the 4GB boundary.
>>>
>>> I specified the note as 3x 64bit values.  It seemed simpler than trying to
>>> support both 32bit and 64bit depending on the kernel arch.  Also, just using
>>> 64bit provides room in case it is needed in the future.
>>
>> Why do you say depending on the kernel arch?
>>
>> PVH doesn't know the bitness of the kernel, as the kernel entry point
>> is always started in protected 32bit mode.  We should just support
>> 32bit values, regardless of the kernel bitness, because that's the
>> only range that's suitable in order to jump into the entry point.
>>
>> Note how XEN_ELFNOTE_PHYS32_ENTRY is also unconditionally a 32bit
>> integer.

Linux defines PHYS32_ENTRY with _ASM_PTR, so it's 32 or 64 bit to match 
how the kernel is compiled.  The Xen code parses the integer according 
to the size of the note.

>>> Do you want the note to be changed to 3x 32bit values?
>>
>> Unless anyone objects, yes, that's would be my preference.
> 
> As mentioned elsewhere, unless the entire note is meant to be x86-specific,
> this fixed-32-bit property then would want limiting to x86.

PVH is only implemented for x86 today.  Are you saying that the comment 
should just specify the values are 32bit for x86?  If the note is reused 
for other arches, then they can specify their usage?

If this note is to be a variably sized array of values, then the 
elements should be of fixed size.  Otherwise parsing is ambiguous 
without, say, another field specifying element size.

Maybe XEN_ELFNOTE_PHYS32_RELOC would be a better name to complement the 
PHYS32_ENTRY?

Regards,
Jason


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 17:02:29 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 17:02:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693410.1081444 (Exim 4.92)
	(envelope-from )
	id 1rkoTK-00030g-67; Thu, 14 Mar 2024 17:02:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693410.1081444; Thu, 14 Mar 2024 17:02:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkoTK-00030Z-36; Thu, 14 Mar 2024 17:02:26 +0000
Received: by outflank-mailman (input) for mailman id 693410;
 Thu, 14 Mar 2024 17:02:24 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkoTI-00030O-JH
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 17:02:24 +0000
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com
 [2a00:1450:4864:20::535])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a0906b16-e224-11ee-afdd-a90da7624cb6;
 Thu, 14 Mar 2024 18:02:23 +0100 (CET)
Received: by mail-ed1-x535.google.com with SMTP id
 4fb4d7f45d1cf-55a179f5fa1so1524414a12.0
 for ; Thu, 14 Mar 2024 10:02:23 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 e27-20020a170906375b00b00a45bda3cbb8sm868006ejc.134.2024.03.14.10.02.22
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 14 Mar 2024 10:02:22 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a0906b16-e224-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710435743; x=1711040543; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=BqjKQL8SYfkmK/oQBy9DE2rDPUqNAWN3XDkBt8J5gVg=;
        b=K6yKhS/SuepAZbfVHEC9V+vjIzaO8AfymT6OAZJSaMiQ9kKT3r0xcrPClZsBYcZi/Y
         l1WZsjs49Jaom7zsO6NLE2STXzVSkd3FeeRaZBw84Ure5szTZW7GqtTqZN+jT2OzWVSW
         G7tqMwVzsUKXAmRq8vJFUjU04di05vHQFFgc1iJsFuFa+buawDAa4VljnxvVNeqK41MR
         CNxrYTGFpBJd6sy3jhXCcRZkb3kjA9k6QNWx7bstU/+pNTfS3lHtDDQSBmz/+uzBADeD
         Ippk3fbVH42MtuNkDskJndbe/lmzYnVxOhCLlzLsj8QT8P0JJjNqWoopqrpqFFG9Ft4V
         JFTA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710435743; x=1711040543;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=BqjKQL8SYfkmK/oQBy9DE2rDPUqNAWN3XDkBt8J5gVg=;
        b=vBL/1yaxW6ZcEh+iqxIb6Qby19cLi+3LT6hnyGx8SLoDqv1o8ab6sqAD+cqcGrOtYo
         /TV+OWb1XtcmO9B1RAMXVA8kVo0+oPZifKqLSeXSRf0BM9fJwDLnnJPQyPWgXYSysDXh
         I/3/rOOuBz72Mdmk4rPtOcaCdW6qmpmChQ66K9YGmZfSUWgRXqYuBVUcRRFqPyoKVONl
         3h90PrN3iMx9CPFbngeQQRFpZWWhk9VFbR8RjQ3oVilHOCPGy6y2EPMukBML+ChgydkV
         6YKG+r481HKDdRddK9VblnplE76ngjDXxLp+IfQvra92FXv3l+Y5WkyMjxSQ3NiE35wJ
         9VZg==
X-Gm-Message-State: AOJu0YyOKqa2Wowecac2TYdWhV72IY2E5AT8o+W7IcRWd3RspXPReoHm
	DKsfDZBiNqpSDltBspKJX1twhbkS64K5RHrOwJgEl/gmnLCO7ds6nWyiiqnr8g==
X-Google-Smtp-Source: AGHT+IEJY+ImUxiXs6nu5po1hEJJtZq7HAqyiVZZCXHziIsz2v4r2Q5jmqRAv6gDWZnGQEAuAsK/Hw==
X-Received: by 2002:a17:906:169b:b0:a43:b472:9a57 with SMTP id s27-20020a170906169b00b00a43b4729a57mr1323008ejd.62.1710435743052;
        Thu, 14 Mar 2024 10:02:23 -0700 (PDT)
Message-ID: 
Date: Thu, 14 Mar 2024 18:02:21 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 3/3] x86/PVH: Support relocatable dom0 kernels
Content-Language: en-US
To: Jason Andryuk ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: xen-devel@lists.xenproject.org, Andrew Cooper
 , Wei Liu ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini 
References: <20240313193021.241764-1-jason.andryuk@amd.com>
 <20240313193021.241764-4-jason.andryuk@amd.com> 
  
 
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 14.03.2024 17:59, Jason Andryuk wrote:
> On 2024-03-14 11:30, Jan Beulich wrote:
>> On 14.03.2024 15:33, Roger Pau Monné wrote:
>>> On Thu, Mar 14, 2024 at 09:51:22AM -0400, Jason Andryuk wrote:
>>>> On 2024-03-14 05:48, Roger Pau Monné wrote:
>>>>> On Wed, Mar 13, 2024 at 03:30:21PM -0400, Jason Andryuk wrote:
>>>>>> @@ -234,6 +235,17 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
>>>>>>                    elf_note_numeric_array(elf, note, 8, 0),
>>>>>>                    elf_note_numeric_array(elf, note, 8, 1));
>>>>>>            break;
>>>>>> +
>>>>>> +    case XEN_ELFNOTE_PVH_RELOCATION:
>>>>>> +        if ( elf_uval(elf, note, descsz) != 3 * sizeof(uint64_t) )
>>>>>> +            return -1;
>>>>>> +
>>>>>> +        parms->phys_min = elf_note_numeric_array(elf, note, 8, 0);
>>>>>> +        parms->phys_max = elf_note_numeric_array(elf, note, 8, 1);
>>>>>> +        parms->phys_align = elf_note_numeric_array(elf, note, 8, 2);
>>>>>
>>>>> Size for those needs to be 4 (32bits) as the entry point is in 32bit
>>>>> mode?  I don't see how we can start past the 4GB boundary.
>>>>
>>>> I specified the note as 3x 64bit values.  It seemed simpler than trying to
>>>> support both 32bit and 64bit depending on the kernel arch.  Also, just using
>>>> 64bit provides room in case it is needed in the future.
>>>
>>> Why do you say depending on the kernel arch?
>>>
>>> PVH doesn't know the bitness of the kernel, as the kernel entry point
>>> is always started in protected 32bit mode.  We should just support
>>> 32bit values, regardless of the kernel bitness, because that's the
>>> only range that's suitable in order to jump into the entry point.
>>>
>>> Note how XEN_ELFNOTE_PHYS32_ENTRY is also unconditionally a 32bit
>>> integer.
> 
> Linux defines PHYS32_ENTRY with _ASM_PTR, so it's 32 or 64 bit to match 
> how the kernel is compiled.  The Xen code parses the integer according 
> to the size of the note.
> 
>>>> Do you want the note to be changed to 3x 32bit values?
>>>
>>> Unless anyone objects, yes, that's would be my preference.
>>
>> As mentioned elsewhere, unless the entire note is meant to be x86-specific,
>> this fixed-32-bit property then would want limiting to x86.
> 
> PVH is only implemented for x86 today.  Are you saying that the comment 
> should just specify the values are 32bit for x86?  If the note is reused 
> for other arches, then they can specify their usage?

Along these lines. But looks like Roger isn't concerned and would be
happy to leave that to the future.

> If this note is to be a variably sized array of values, then the 
> elements should be of fixed size.  Otherwise parsing is ambiguous 
> without, say, another field specifying element size.
> 
> Maybe XEN_ELFNOTE_PHYS32_RELOC would be a better name to complement the 
> PHYS32_ENTRY?

Perhaps, yes.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 17:14:31 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 17:14:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693414.1081453 (Exim 4.92)
	(envelope-from )
	id 1rkoet-0005jZ-6v; Thu, 14 Mar 2024 17:14:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693414.1081453; Thu, 14 Mar 2024 17:14:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkoet-0005jS-4C; Thu, 14 Mar 2024 17:14:23 +0000
Received: by outflank-mailman (input) for mailman id 693414;
 Thu, 14 Mar 2024 17:14:22 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkoer-0005jM-UN
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 17:14:21 +0000
Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com
 [2607:f8b0:4864:20::32b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4a3f6ab4-e226-11ee-a1ee-f123f15fe8a2;
 Thu, 14 Mar 2024 18:14:18 +0100 (CET)
Received: by mail-ot1-x32b.google.com with SMTP id
 46e09a7af769-6e677008501so112009a34.1
 for ; Thu, 14 Mar 2024 10:14:18 -0700 (PDT)
Received: from [10.80.67.149] (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 r27-20020a05620a03db00b007883218feb7sm1040991qkm.97.2024.03.14.10.14.14
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 14 Mar 2024 10:14:16 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4a3f6ab4-e226-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710436457; x=1711041257; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=0bjRqtas4rx6wxJs5Cs9nm3xTvNnI+odLidhChqnt+k=;
        b=q6Mgczjnv6lMuPL+kfjYJUAVxBRSRIoa3RvuVWfylhIj3/bFJmcpBcazauHr9Sw3M6
         H3VuXvlOyxmGmOO40Hl3or/4eGLhKdLqjaEZ1cATgnDr6WXvYuFMPbuSt+CBmjWyL8Eq
         G84M/SvR6rKyud8HR+asptmN7kflm9mV4TytA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710436457; x=1711041257;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=0bjRqtas4rx6wxJs5Cs9nm3xTvNnI+odLidhChqnt+k=;
        b=uGQTHRk4hJgk6oDP+MqS3fjaLm61R9QBXqTc9bOUDF298KYfNz1e2Te5duqCrvjsgv
         yY+yPGgyR6HJGd9mgZjNOwGHTBc/n4s1rRE3Z9lfMn/OvY41UIVX4hpr3UVZNUrOs0bz
         G1VPTovPkuvhXQKkIESQ2xJ/FB7SpkrFaWep3AzbxEazy11+LCGfeWhwbT6e0BB4rBo8
         ItUMIzWFEioAFGswt85+xnp5g0J/oAXgxXn0Ilsi99pmyk4P4opJ1r6BOrmw/QjBUNjL
         BYIfP2NbWfUNHxe22Im7g79vE+XKBaElvYSisfGA3+xtUFi/VvxDaBek93kloCpIocEz
         pRdQ==
X-Forwarded-Encrypted: i=1; AJvYcCVm0GfuAtyQdcjKBXkQ3RxbYI4MS5K7RCwA/8ETPXS+IVjc0cgPn649Fih3myOXcQ0iO9kcTKFdpQArCOTik7a4ZVg98OXqlCO/htr/U2M=
X-Gm-Message-State: AOJu0YyvbsiZEE6iqLMQGldxMyWzXi9Dhx4/PvdLXT5s3V7hUBWRN3uF
	tSnwlVEBevxdglrxO69+8DaWKHmU/UVRKtTqUdiTQWD/EZCm7Q6oy9zombA/FZ8=
X-Google-Smtp-Source: AGHT+IH0n0oCBAUFSxkVZ3st5gWbKJ2FG92FqpOtKHEi+D7WTSd9i+RvNKp6RKLaUDFC4/wHAyr4OA==
X-Received: by 2002:a05:6830:1d8b:b0:6e5:34d4:843d with SMTP id y11-20020a0568301d8b00b006e534d4843dmr2309079oti.15.1710436457120;
        Thu, 14 Mar 2024 10:14:17 -0700 (PDT)
Message-ID: 
Date: Thu, 14 Mar 2024 17:14:14 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 7/7] xen/bitops: Delete find_first_set_bit()
Content-Language: en-GB
To: Jan Beulich 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Wei Liu , Stefano Stabellini ,
 Julien Grall , Volodymyr Babchuk
 , Bertrand Marquis ,
 Michal Orzel ,
 Oleksii Kurochko ,
 Shawn Anastasio ,
 "consulting @ bugseng . com" ,
 Simone Ballarin ,
 Federico Serafini ,
 Nicola Vetrini ,
 Xen-devel 
References: <20240313172716.2325427-1-andrew.cooper3@citrix.com>
 <20240313172716.2325427-8-andrew.cooper3@citrix.com>
 <926895a0-f777-4e17-951f-6df0cc24b0f2@suse.com>
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <926895a0-f777-4e17-951f-6df0cc24b0f2@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 14/03/2024 3:59 pm, Jan Beulich wrote:
> On 13.03.2024 18:27, Andrew Cooper wrote:
>> --- a/xen/arch/x86/include/asm/bitops.h
>> +++ b/xen/arch/x86/include/asm/bitops.h
>> @@ -401,18 +401,6 @@ static always_inline unsigned int __scanbit(unsigned long val, unsigned int max)
>>      r__;                                                                    \
>>  })
>>  
>> -/**
>> - * find_first_set_bit - find the first set bit in @word
>> - * @word: the word to search
>> - * 
>> - * Returns the bit-number of the first set bit. The input must *not* be zero.
>> - */
>> -static inline unsigned int find_first_set_bit(unsigned long word)
>> -{
>> -    asm ( "rep; bsf %1,%0" : "=r" (word) : "rm" (word) );
>> -    return (unsigned int)word;
>> -}
> And you think it's okay to no longer use TZCNT like this when available,
> where the output doesn't have to have its value set up front?

This is a particularly evil piece of inline asm.

It is interpreted as BSF or TZCNT depending on the BMI instruction set
(Haswell/Piledriver era).  Furthermore there are errata on some Intel
systems where REP BSF behaves as per TZCNT *even* when BMI isn't enumerated.

Which means this piece of asm suffers from all of an undefined output
register, undefined CF behaviour, and differing ZF behaviour (I believe)
depending on which hardware you're running on.

The only thing the REP prefix is getting you is a deterministic 0 in the
destination register, on some hardware only, for code which has already
violated the input safety condition.  As a piece of defence in depth,
then perhaps it's useful.

But following up from the other thread,
https://gcc.gnu.org/pipermail/gcc/2024-March/243475.html is form where
the compiler can (and does!) simplify back to the plain BSF form when it
can prove that this is safe.


The only case where using TZCNT is helpful is when we're compiling for
x86_64-v3 and there is no need to work around BSF's undefined behaviour.

Even with x86's arch_ffs() now split nicely based on whether the
compiler knows BSF is safe or not, an alternative to swap between BSF
and TZCNT probably isn't a win; you still have to cover up 6 or 7 bytes
of the -1 setup, which you can't do with leading prefixes on the TZCNT
itself.

All CPUs with BMI can swallow the double-instruction data dependency
without breaking a sweat, at which point you're trading off (at best) a
1-cycle improvement vs the setup costs of the alternative.  If there is
any real improvement to be had here, it's marginal enough that I'm not
sure it's worth doing.

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 17:39:50 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 17:39:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693420.1081463 (Exim 4.92)
	(envelope-from )
	id 1rkp3G-0001da-1k; Thu, 14 Mar 2024 17:39:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693420.1081463; Thu, 14 Mar 2024 17:39:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkp3F-0001dT-Ui; Thu, 14 Mar 2024 17:39:33 +0000
Received: by outflank-mailman (input) for mailman id 693420;
 Thu, 14 Mar 2024 17:39:32 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1rkp3E-0001dN-Jh
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 17:39:32 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkp3E-0005rG-G1; Thu, 14 Mar 2024 17:39:32 +0000
Received: from 54-240-197-232.amazon.com ([54.240.197.232]
 helo=dev-dsk-jgrall-1b-035652ec.eu-west-1.amazon.com)
 by xenbits.xenproject.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92)
 (envelope-from )
 id 1rkp3E-0004iJ-0P; Thu, 14 Mar 2024 17:39:32 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:MIME-Version:Message-Id:Date:
	Subject:Cc:To:From; bh=BBgVk/VxeF7lwwDF6FtK4BZYXcyviQU7xqFnvHmS8gE=; b=bE0tlc
	T0dnTLLEvNSaaiQgANhXPn/XlTa4yPmFhySjKkZrU/aYXt5IE0GQNmmLv9WctXPExUOim5e/Z+e3s
	dtAqKB4reKQBSgk2A6hOSpnRp6At5O0YJmtpx0wC04+oqOHHBTIo4aD/emdedj2QRcY91ZZZbvQe0
	F6Kpzuo2msM=;
From: Julien Grall 
To: xen-devel@lists.xenproject.org
Cc: michal.orzel@amd.com,
	ayan.kumar.halder@amd.com,
	Julien Grall ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini ,
	Wei Liu 
Subject: [PATCH] SUPPORT.MD: Fix matrix generation after 43c416d0d819 and 77c39a53cf5b
Date: Thu, 14 Mar 2024 17:39:29 +0000
Message-Id: <20240314173929.12040-1-julien@xen.org>
X-Mailer: git-send-email 2.40.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Julien Grall 

The script docs/support-matrix-generate throw the following error on the
latest staging.

MDCCSR_EL0
DBGDTR_EL0
DBGDTRTX_EL0
DBGDTRRX_EL0
DBGDSCRINT
DBGDTRTXINT
DBGDTRRXINT
^ cannot parse status codeblock line:
MDCCSR_EL0
 ? at docs/parse-support-md line 172,  chunk 1.

With the current indentation, it looks like the script thinks this is
a status code block.

Solve the issue by switching to a bullet list.

Fixes: 43c416d0d819 ("xen/arm: arm64: Add emulation of Debug Data Transfer Registers")
Fixes: 77c39a53cf5b ("xen/arm: arm32: Add emulation of Debug Data Transfer Registers")
---
 SUPPORT.md | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/SUPPORT.md b/SUPPORT.md
index 58f075538f73..e10d46d924a4 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -111,13 +111,13 @@ that would normally trigger a fault injection.
 
 Only the following system registers are security supported:
 
-    MDCCSR_EL0
-    DBGDTR_EL0
-    DBGDTRTX_EL0
-    DBGDTRRX_EL0
-    DBGDSCRINT
-    DBGDTRTXINT
-    DBGDTRRXINT
+  * MDCCSR_EL0
+  * DBGDTR_EL0
+  * DBGDTRTX_EL0
+  * DBGDTRRX_EL0
+  * DBGDSCRINT
+  * DBGDTRTXINT
+  * DBGDTRRXINT
 
 ### ARM Scalable Vector Extension (SVE/SVE2)
 
-- 
2.40.1



From xen-devel-bounces@lists.xenproject.org Thu Mar 14 17:41:25 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 17:41:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693422.1081474 (Exim 4.92)
	(envelope-from )
	id 1rkp52-00031r-Bp; Thu, 14 Mar 2024 17:41:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693422.1081474; Thu, 14 Mar 2024 17:41:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkp52-00031k-8h; Thu, 14 Mar 2024 17:41:24 +0000
Received: by outflank-mailman (input) for mailman id 693422;
 Thu, 14 Mar 2024 17:41:22 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkp50-00031Y-BR
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 17:41:22 +0000
Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com
 [2607:f8b0:4864:20::42f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 115416ac-e22a-11ee-afdd-a90da7624cb6;
 Thu, 14 Mar 2024 18:41:21 +0100 (CET)
Received: by mail-pf1-x42f.google.com with SMTP id
 d2e1a72fcca58-6e46dcd8feaso946462b3a.2
 for ; Thu, 14 Mar 2024 10:41:21 -0700 (PDT)
Received: from [10.80.67.149] (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 n29-20020a634d5d000000b005d6a0b2efb3sm980651pgl.21.2024.03.14.10.41.17
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 14 Mar 2024 10:41:18 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 115416ac-e22a-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710438079; x=1711042879; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=v76VnWZ6f97ShybuKoxCi8k8XuPkC78HnVbwJkhJRPY=;
        b=LRS9DN15CLZd/d98/uufTLmwO3Idf6pJeFetOaTJEhrNRSQsOLLv7yE0GowKvk0TVd
         CabmBW5or3kpU6sUGY2h/rOF4h+p19/apPzVJURJQ7tgCJTs0xXZECW2y0HETwJbQYQA
         y3QQT7QMo9cC/aAfUeA7jMoodkLnf2i3yVKNE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710438079; x=1711042879;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=v76VnWZ6f97ShybuKoxCi8k8XuPkC78HnVbwJkhJRPY=;
        b=uk2AubAI5JTt0lU6IyVhF4v6ge41S0IJnMTTYFT9YF4zG5HghhkxNjhKQhBedmjjDj
         PoUAFDc9HP8PQj0uG1ak1+erYAQLoP773WWGGzLtIpHhy7eCx0eHsnIGYfzdNIsdiFh+
         LkbQSasbwU+0UpT0BjGjy78C8RvkDg7jPpwZn2JaBv5y+AyTRC8AMc01s7MGUWF+TPTd
         8WMQ8nBez3V7DSqSTp22B54WGesf4eGTrn3vblAe1cGsJZOm8Zer6TmzKLenP/gYw7Gf
         At++6LjBG1syJmvxejRRKlAiX9vFUdR92ivJycyEpIa1kmytRT54Y/ck4QB+g8Z9z2N9
         wWFQ==
X-Forwarded-Encrypted: i=1; AJvYcCUnBTRBiCaAA/XmvD/5iHacE+PO+e5hgbvbuHGUKNYBSdfWofy7wb142A4PlDspplCpd4u0re2aslGbeTVNYFycMmpxpdwinSSVxb8BF58=
X-Gm-Message-State: AOJu0YzkF4liCZojnKSz3Xt7blbNqhhvdb2n5l7CtpIcL6I8ZQOeGIsx
	FRq2odN0eWTt5/VGrmC05dTYnUA4o8SRozBy0KhTOI51js0lLkTV7MQIyFsZCUkfQbKuq/au3iy
	j
X-Google-Smtp-Source: AGHT+IF7PNftTWyEd0v9bJWucwC5vdX0x/vYEz/y2VtT9d+wBFcv8CqyMXezUKYl2QwMrPw+8vxKkw==
X-Received: by 2002:a05:6a20:4289:b0:1a3:113a:bbd5 with SMTP id o9-20020a056a20428900b001a3113abbd5mr2818937pzj.40.1710438079583;
        Thu, 14 Mar 2024 10:41:19 -0700 (PDT)
Message-ID: 
Date: Thu, 14 Mar 2024 17:41:15 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] SUPPORT.MD: Fix matrix generation after 43c416d0d819 and
 77c39a53cf5b
Content-Language: en-GB
To: Julien Grall , xen-devel@lists.xenproject.org
Cc: michal.orzel@amd.com, ayan.kumar.halder@amd.com,
 Julien Grall , George Dunlap ,
 Jan Beulich , Stefano Stabellini
 , Wei Liu 
References: <20240314173929.12040-1-julien@xen.org>
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <20240314173929.12040-1-julien@xen.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 14/03/2024 5:39 pm, Julien Grall wrote:
> From: Julien Grall 
>
> The script docs/support-matrix-generate throw the following error on the
> latest staging.
>
> MDCCSR_EL0
> DBGDTR_EL0
> DBGDTRTX_EL0
> DBGDTRRX_EL0
> DBGDSCRINT
> DBGDTRTXINT
> DBGDTRRXINT
> ^ cannot parse status codeblock line:
> MDCCSR_EL0
>  ? at docs/parse-support-md line 172,  chunk 1.
>
> With the current indentation, it looks like the script thinks this is
> a status code block.
>
> Solve the issue by switching to a bullet list.
>
> Fixes: 43c416d0d819 ("xen/arm: arm64: Add emulation of Debug Data Transfer Registers")
> Fixes: 77c39a53cf5b ("xen/arm: arm32: Add emulation of Debug Data Transfer Registers")
> ---

You need a SoB somewhere, but Acked-by: Andrew Cooper



From xen-devel-bounces@lists.xenproject.org Thu Mar 14 17:42:09 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 17:42:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693426.1081484 (Exim 4.92)
	(envelope-from )
	id 1rkp5l-0003YT-LA; Thu, 14 Mar 2024 17:42:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693426.1081484; Thu, 14 Mar 2024 17:42:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkp5l-0003YM-HU; Thu, 14 Mar 2024 17:42:09 +0000
Received: by outflank-mailman (input) for mailman id 693426;
 Thu, 14 Mar 2024 17:42:08 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1rkp5k-0003YA-Ny
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 17:42:08 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkp5k-0005wC-I3; Thu, 14 Mar 2024 17:42:08 +0000
Received: from [15.248.2.233] (helo=[10.24.67.21])
 by xenbits.xenproject.org with esmtpsa
 (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92)
 (envelope-from )
 id 1rkp5k-0004nv-Ck; Thu, 14 Mar 2024 17:42:08 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=c3AsWHz2USgxH1IKQ+QX4M/AebETs5dzS7i+IGBC/Ss=; b=C5mbov6kZMTAmu5UxT7OsYmQsU
	iFuUWUNBzqOukpyDekcml7np23zP0lVnVnbMCEQSmxa+kbjL6fIVdfu9hUxPHNPkXxqkxarp3cDtJ
	kR5Eg7Z0GtiTOgjozVRiQgmQEnNsu/lKjVuriKE3STULDEMcbwB01ahHZo3R0cWa196s=;
Message-ID: 
Date: Thu, 14 Mar 2024 17:42:06 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] SUPPORT.MD: Fix matrix generation after 43c416d0d819 and
 77c39a53cf5b
Content-Language: en-GB
To: Andrew Cooper , xen-devel@lists.xenproject.org
Cc: michal.orzel@amd.com, ayan.kumar.halder@amd.com,
 Julien Grall , George Dunlap ,
 Jan Beulich , Stefano Stabellini
 , Wei Liu 
References: <20240314173929.12040-1-julien@xen.org>
 
From: Julien Grall 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit



On 14/03/2024 17:41, Andrew Cooper wrote:
> On 14/03/2024 5:39 pm, Julien Grall wrote:
>> From: Julien Grall 
>>
>> The script docs/support-matrix-generate throw the following error on the
>> latest staging.
>>
>> MDCCSR_EL0
>> DBGDTR_EL0
>> DBGDTRTX_EL0
>> DBGDTRRX_EL0
>> DBGDSCRINT
>> DBGDTRTXINT
>> DBGDTRRXINT
>> ^ cannot parse status codeblock line:
>> MDCCSR_EL0
>>   ? at docs/parse-support-md line 172,  chunk 1.
>>
>> With the current indentation, it looks like the script thinks this is
>> a status code block.
>>
>> Solve the issue by switching to a bullet list.
>>
>> Fixes: 43c416d0d819 ("xen/arm: arm64: Add emulation of Debug Data Transfer Registers")
>> Fixes: 77c39a53cf5b ("xen/arm: arm32: Add emulation of Debug Data Transfer Registers")
>> ---
> 
> You need a SoB somewhere, but Acked-by: Andrew Cooper
> 

Whoops yes:

Signed-off-by: Julien Grall 

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 18:29:49 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 18:29:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693435.1081504 (Exim 4.92)
	(envelope-from )
	id 1rkppl-0003cN-1n; Thu, 14 Mar 2024 18:29:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693435.1081504; Thu, 14 Mar 2024 18:29:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkppk-0003cG-V1; Thu, 14 Mar 2024 18:29:40 +0000
Received: by outflank-mailman (input) for mailman id 693435;
 Thu, 14 Mar 2024 18:29:40 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkppk-0003cA-4I
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 18:29:40 +0000
Received: from raptorengineering.com (mail.raptorengineering.com
 [23.155.224.40]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id cec5240e-e230-11ee-a1ee-f123f15fe8a2;
 Thu, 14 Mar 2024 19:29:36 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
 by mail.rptsys.com (Postfix) with ESMTP id 899908285394;
 Thu, 14 Mar 2024 13:29:34 -0500 (CDT)
Received: from mail.rptsys.com ([127.0.0.1])
 by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10032)
 with ESMTP id 3G_ib1pnrOqR; Thu, 14 Mar 2024 13:29:33 -0500 (CDT)
Received: from localhost (localhost [127.0.0.1])
 by mail.rptsys.com (Postfix) with ESMTP id 623108285461;
 Thu, 14 Mar 2024 13:29:33 -0500 (CDT)
Received: from mail.rptsys.com ([127.0.0.1])
 by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10026)
 with ESMTP id ThLNig8R0o33; Thu, 14 Mar 2024 13:29:33 -0500 (CDT)
Received: from [10.11.0.3] (5.edge.rptsys.com [23.155.224.38])
 by mail.rptsys.com (Postfix) with ESMTPSA id 9AC758285394;
 Thu, 14 Mar 2024 13:29:32 -0500 (CDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: cec5240e-e230-11ee-a1ee-f123f15fe8a2
DKIM-Filter: OpenDKIM Filter v2.10.3 mail.rptsys.com 623108285461
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=raptorengineering.com; s=B8E824E6-0BE2-11E6-931D-288C65937AAD;
	t=1710440973; bh=WJm5lBRkhO+k/HUqpQUQBRC3VGg2b99MohoQAWlMCYI=;
	h=Message-ID:Date:MIME-Version:To:From;
	b=qyXZjaqH4tLtAUd20bBv8L0E5ork2O7MX6UVFqGIdoUxAOxhzWuYtUlXPhZIPBtBQ
	 yZPuVuH7c3gua50HVyx4toisH33HekyEIfUQb204oLUj6zmND8oGTg0iha9IzBJ3JP
	 1FEbCEln4Eo8lSvmGw6mYUfLyKHR8FdpMLOV5bNw=
X-Virus-Scanned: amavisd-new at rptsys.com
Message-ID: <9bad9729-1d77-4a7d-9c9f-33bd8f50fb0d@raptorengineering.com>
Date: Thu, 14 Mar 2024 13:29:31 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 7/7] xen/ppc: mm-radix: Allocate Partition and Process
 Tables at runtime
Content-Language: en-US
To: Jan Beulich 
Cc: Timothy Pearson ,
 xen-devel@lists.xenproject.org
References: 
 
 <6ba01b31-fc51-4d12-83a2-4754ccfb6339@suse.com>
From: Shawn Anastasio 
In-Reply-To: <6ba01b31-fc51-4d12-83a2-4754ccfb6339@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Hi Jan,

I'm revisiting this series in preparation for a v3 and had some
follow-up comments.

On 12/21/23 1:06 AM, Jan Beulich wrote:
> On 15.12.2023 03:44, Shawn Anastasio wrote:
>> In the initial mm-radix implementation, the in-memory partition and
>> process tables required to configure the MMU were allocated statically
>> since the boot allocator was not yet available.
>>
>> Now that it is, allocate these tables at runtime and bump the size of
>> the Process Table to its maximum supported value (on POWER9). Also bump
>> the number of static LVL2/3 PD frames to tolerate cases where the boot
>> allocator returns an address outside of the range of the LVL2 frame used
>> for Xen.
> 
> Don't you need to bump to 4, in case PATB and PRTB end up sufficiently
> far apart? Or even further, considering that you may need distinct L2
> and L3 for each of Xen, PATB, and PRTB?
>

In practice this won't happen since the boot allocator will start from
the top of free address space and move downwards, while the PowerNV
firmware allocates all of its memory towards the bottom of the physical
address space. I see your point though, and will likely end up scrapping
the static page table allocation entirely (see below).

> However, with there being memory to allocate now, is there a reason you
> still reserve (perhaps more than necessary) static memory for the
> page tables, rather than allocating those dynamically as well?
>

Initially I had avoided doing this to simplify the identity mapping of
the paging structures themselves, since dynamically allocating them
would (obviously) mean that their location wouldn't be known ahead of
time and that would complicate the process of mapping them.

On second thought though, this can be trivially solved by keeping track
of the maximum and minimum addresses returned by all calls to
alloc_boot_pages() in this early paging code and then simply identity
mapping that entire region, and I think that this is worth doing to
avoid these wasteful static allocations.

>> @@ -105,80 +157,43 @@ static void __init setup_initial_mapping(struct lvl1_pd *lvl1,
>>          die();
>>      }
>>
>> +    /* Identity map Xen itself */
>>      for ( page_addr = map_start; page_addr < map_end; page_addr += PAGE_SIZE )
>>      {
>> -        struct lvl2_pd *lvl2;
>> -        struct lvl3_pd *lvl3;
>> -        struct lvl4_pt *lvl4;
>> -        pde_t *pde;
>> -        pte_t *pte;
>> -
>> -        /* Allocate LVL 2 PD if necessary */
>> -        pde = pt_entry(lvl1, page_addr);
>> -        if ( !pde_is_valid(*pde) )
>> -        {
>> -            lvl2 = lvl2_pd_pool_alloc();
>> -            *pde = paddr_to_pde(__pa(lvl2), PDE_VALID,
>> -                                XEN_PT_ENTRIES_LOG2_LVL_2);
>> -        }
>> -        else
>> -            lvl2 = __va(pde_to_paddr(*pde));
>> +        unsigned long flags;
>>
>> -        /* Allocate LVL 3 PD if necessary */
>> -        pde = pt_entry(lvl2, page_addr);
>> -        if ( !pde_is_valid(*pde) )
>> +        if ( is_kernel_text(page_addr) || is_kernel_inittext(page_addr) )
>>          {
>> -            lvl3 = lvl3_pd_pool_alloc();
>> -            *pde = paddr_to_pde(__pa(lvl3), PDE_VALID,
>> -                                XEN_PT_ENTRIES_LOG2_LVL_3);
>> +            radix_dprintk("%016lx being marked as TEXT (RX)\n", page_addr);
>> +            flags = PTE_XEN_RX;
>>          }
>> -        else
>> -            lvl3 = __va(pde_to_paddr(*pde));
>> -
>> -        /* Allocate LVL 4 PT if necessary */
>> -        pde = pt_entry(lvl3, page_addr);
>> -        if ( !pde_is_valid(*pde) )
>> -        {
>> -            lvl4 = lvl4_pt_pool_alloc();
>> -            *pde = paddr_to_pde(__pa(lvl4), PDE_VALID,
>> -                                XEN_PT_ENTRIES_LOG2_LVL_4);
>> -        }
>> -        else
>> -            lvl4 = __va(pde_to_paddr(*pde));
>> -
>> -        /* Finally, create PTE in LVL 4 PT */
>> -        pte = pt_entry(lvl4, page_addr);
>> -        if ( !pte_is_valid(*pte) )
>> +        else if ( is_kernel_rodata(page_addr) )
>>          {
>> -            unsigned long paddr = (page_addr - map_start) + phys_base;
>> -            unsigned long flags;
>> -
>> -            radix_dprintk("%016lx being mapped to %016lx\n", paddr, page_addr);
>> -            if ( is_kernel_text(page_addr) || is_kernel_inittext(page_addr) )
>> -            {
>> -                radix_dprintk("%016lx being marked as TEXT (RX)\n", page_addr);
>> -                flags = PTE_XEN_RX;
>> -            }
>> -            else if ( is_kernel_rodata(page_addr) )
>> -            {
>> -                radix_dprintk("%016lx being marked as RODATA (RO)\n", page_addr);
>> -                flags = PTE_XEN_RO;
>> -            }
>> -            else
>> -            {
>> -                radix_dprintk("%016lx being marked as DEFAULT (RW)\n", page_addr);
>> -                flags = PTE_XEN_RW;
>> -            }
>> -
>> -            *pte = paddr_to_pte(paddr, flags);
>> -            radix_dprintk("%016lx is the result of PTE map\n",
>> -                paddr_to_pte(paddr, flags).pte);
>> +            radix_dprintk("%016lx being marked as RODATA (RO)\n", page_addr);
>> +            flags = PTE_XEN_RO;
>>          }
>>          else
>>          {
>> -            early_printk("BUG: Tried to create PTE for already-mapped page!");
>> -            die();
>> +            radix_dprintk("%016lx being marked as DEFAULT (RW)\n", page_addr);
>> +            flags = PTE_XEN_RW;
>>          }
>> +
>> +        map_page_initial(lvl1, page_addr, (page_addr - map_start) + phys_base, flags);
>> +    }
>> +
>> +    /* Map runtime-allocated PATB, PRTB */
>> +    for ( page_addr = (uint64_t)initial_patb;
>> +          page_addr < (uint64_t)initial_patb + PATB_SIZE;
> 
> While technically not an issue, casting pointers to fixed width types is
> generally bogus. page_addr itself would likely better also be of a
> different type (unsigned long, uintptr_t, or vaddr_t; the latter only if
> that's meant to represent hypervisor virtual addresses, not guest ones).
>

Noted. I'll go with one of the other types you suggested.

>> +          page_addr += PAGE_SIZE )
>> +    {
>> +        map_page_initial(lvl1, page_addr, __pa(page_addr), PTE_XEN_RW);
>> +    }
>> +
>> +    for ( page_addr = (uint64_t)initial_prtb;
>> +          page_addr < (uint64_t)initial_prtb + PRTB_SIZE;
>> +          page_addr += PAGE_SIZE )
>> +    {
>> +        map_page_initial(lvl1, page_addr, __pa(page_addr), PTE_XEN_RW);
>>      }
> 
> Just as a remark (you're the maintainer) - in cases like these we generally
> prefer to omit the braces.
> 

Noted. In this case I feel pretty strongly that the braces aid
readability so I'm inclined to keep them.

>> @@ -210,6 +225,16 @@ void __init setup_initial_pagetables(void)
>>  {
>>      struct lvl1_pd *root = lvl1_pd_pool_alloc();
>>      unsigned long lpcr;
>> +    mfn_t patb_mfn, prtb_mfn;
>> +
>> +    /* Allocate mfns for in-memory tables using the boot allocator */
>> +    prtb_mfn = alloc_boot_pages(PRTB_SIZE / PAGE_SIZE,
>> +                                max(1, PRTB_SIZE_LOG2 - PAGE_SHIFT));
>> +    patb_mfn = alloc_boot_pages(PATB_SIZE / PAGE_SIZE,
>> +                                max(1, PATB_SIZE_LOG2 - PAGE_SHIFT));
>> +
>> +    initial_patb = __va(mfn_to_maddr(patb_mfn));
>> +    initial_prtb = __va(mfn_to_maddr(prtb_mfn));
> 
> Overall, what's the plan wrt directmap: Are you meaning to not have one
> covering all memory? If you do, I wonder if you wouldn't be better off
> mapping memory as you pass it to the boot allocator, such that you
> won't need to map things piecemeal like you're doing here.
>

This isn't a design decision that I've made yet, but I'm inclined to
think that having a directmap would be a reasonable decision. Mapping
memory as it is passed to the boot allocator seems reasonable in
theory, but unless I'm missing something, doing so would create a
chicken-and-egg problem since the act of mapping pages requires
allocating page frames for the paging structures, and per your prior
suggestion I'm planning to do that using the boot allocator itself.

This is probably something I'd want to revisit once the PPC mm code is
more fleshed out.

> Jan

Thanks,
Shawn


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 18:38:17 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 18:38:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693438.1081515 (Exim 4.92)
	(envelope-from )
	id 1rkpy1-0005JO-To; Thu, 14 Mar 2024 18:38:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693438.1081515; Thu, 14 Mar 2024 18:38:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkpy1-0005JH-PC; Thu, 14 Mar 2024 18:38:13 +0000
Received: by outflank-mailman (input) for mailman id 693438;
 Thu, 14 Mar 2024 18:38:12 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkpy0-0005J7-OL; Thu, 14 Mar 2024 18:38:12 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkpy0-000743-MG; Thu, 14 Mar 2024 18:38:12 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkpy0-0007Qp-DW; Thu, 14 Mar 2024 18:38:12 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rkpy0-0005LQ-D4; Thu, 14 Mar 2024 18:38:12 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=SfJ6KZM9iIVOLEVXNRijx4SMvWEAR3iwuaL67/fPLCE=; b=anyl5MHy8H/Kx5PgEv9VoKbYPe
	jcyanMDOYyfovmD3UiPVSmj0MSaaK3zqcX2KKGXkAJPDwiCBU5E+YXU6H2wpTWncXlirTX2/KNGyQ
	NKman8BDM7986N8kkyne9/QdARM1Q0s2pgzrbj0yRs5zlgsRbZM/JrtXEHsKD9nlRaKo=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 185035: tolerable all pass - PUSHED
X-Osstest-Failures:
    xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    xen=77c39a53cf5bfe185b7bff6544c63731513830d3
X-Osstest-Versions-That:
    xen=af7fed3fdf82981ebbb09628b278df957569333d
From: osstest service owner 
Date: Thu, 14 Mar 2024 18:38:12 +0000

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          16 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  77c39a53cf5bfe185b7bff6544c63731513830d3
baseline version:
 xen                  af7fed3fdf82981ebbb09628b278df957569333d

Last test of basis   185033  2024-03-14 13:02:16 Z    0 days
Testing same since   185035  2024-03-14 16:05:12 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Ayan Kumar Halder 
  Julien Grall 
  Michal Orzel 

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-amd64                    pass    
 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
   af7fed3fdf..77c39a53cf  77c39a53cf5bfe185b7bff6544c63731513830d3 -> smoke


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 18:47:37 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 18:47:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693447.1081524 (Exim 4.92)
	(envelope-from )
	id 1rkq6v-0007JM-Qw; Thu, 14 Mar 2024 18:47:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693447.1081524; Thu, 14 Mar 2024 18:47:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkq6v-0007JF-O4; Thu, 14 Mar 2024 18:47:25 +0000
Received: by outflank-mailman (input) for mailman id 693447;
 Thu, 14 Mar 2024 18:47:25 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkq6v-0007J9-0B
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 18:47:25 +0000
Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com
 [2607:f8b0:4864:20::833])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4adbbe54-e233-11ee-a1ee-f123f15fe8a2;
 Thu, 14 Mar 2024 19:47:22 +0100 (CET)
Received: by mail-qt1-x833.google.com with SMTP id
 d75a77b69052e-430acf667afso1014611cf.1
 for ; Thu, 14 Mar 2024 11:47:22 -0700 (PDT)
Received: from [10.80.67.149] (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 l1-20020ac84cc1000000b0042f04e421d2sm1067472qtv.24.2024.03.14.11.47.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 14 Mar 2024 11:47:21 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4adbbe54-e233-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710442042; x=1711046842; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=edk6fdaxLwF/Pq30+zYWxTrKfjAUS/7mmdROmeeEAcE=;
        b=R+Q38khTa71kq+DYN9A8oEo+0RPDH5C3dCmmfTo5upXnF3iHtqLjSInLpO3kgtCT12
         YEcYDqNfIHP91T9+re43JmyC3ozE+A65aa1yhLOU4pQuQy+FQVh6lSCVTyoGK2m5H86z
         mCf3b6685ixqONnX4KXx/XFy7BNpohfO72+VU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710442042; x=1711046842;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=edk6fdaxLwF/Pq30+zYWxTrKfjAUS/7mmdROmeeEAcE=;
        b=K/bhUb1NVnbUfuj6+An9Vkmnh+7RxhOiMwyhoY0XNXXzixgF6CG/j9BdJwmSQ5lo3V
         xeDgAMQ1Lu+BBvXhLaazR+jlfKSI1obfKeJYoqS4ibtYONp6bE18/DnBUx9dUD3Ory+c
         qOF5/y1Me814lKHDZcPfj/am0vu/DHNSElUYNorBXfKQgmPeQ47rOq4smt5i206DhHTs
         gTpvQd+Qe/H2QMCXJyR6eSG48szOP7zgaa+87Khuc+3648faQd9jBa59/Prnt8yCHxos
         +heA6Sgtth+qd2RMmrz+NqxdHSlQwygmnR+YzU+09Nx60bGkhOFTFyAIgBONM2gyzhir
         zPwg==
X-Forwarded-Encrypted: i=1; AJvYcCV2PwYU4tzQWBKl4sSqguwjj0T4ZbwVjtufB0BSOpQNdoR4xujNCQhbV9cqCw8mnrmAsNdTeJ0Z6eO02+lQCzJJ6kBRN6Kuh5FLFMq5Ijc=
X-Gm-Message-State: AOJu0Yxjn0icpAsdue3CnLkpKIUsfT6zYVqnjs97b9RaT8I/c3QMEWEQ
	Ns60ktUKVinTaD53T8RPTYS2KPi+Jz1lh0vH9+0kCYKfWoLlrsaZwQ5ghAx3xxY=
X-Google-Smtp-Source: AGHT+IFEAur5dlDVikexYq4s8x/G5TPcC91b0437JkcY65Hhw+TbZGEu4+aWv+UI7GGv7JFFrzCB9w==
X-Received: by 2002:a05:622a:5cf:b0:42e:f660:8067 with SMTP id d15-20020a05622a05cf00b0042ef6608067mr2758444qtb.36.1710442041721;
        Thu, 14 Mar 2024 11:47:21 -0700 (PDT)
Message-ID: <1356dd16-03e1-4c01-9aac-597a127dea85@citrix.com>
Date: Thu, 14 Mar 2024 18:47:18 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 6/7] xen: Swap find_first_set_bit() for ffsl() - 1
Content-Language: en-GB
To: Jan Beulich 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Wei Liu , Stefano Stabellini ,
 Julien Grall , Volodymyr Babchuk
 , Bertrand Marquis ,
 Michal Orzel ,
 Oleksii Kurochko ,
 Shawn Anastasio ,
 "consulting @ bugseng . com" ,
 Simone Ballarin ,
 Federico Serafini ,
 Nicola Vetrini ,
 Xen-devel 
References: <20240313172716.2325427-1-andrew.cooper3@citrix.com>
 <20240313172716.2325427-7-andrew.cooper3@citrix.com>
 
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 14/03/2024 2:30 pm, Jan Beulich wrote:
> On 13.03.2024 18:27, Andrew Cooper wrote:
>> --- a/xen/drivers/passthrough/x86/iommu.c
>> +++ b/xen/drivers/passthrough/x86/iommu.c
>> @@ -641,7 +641,7 @@ struct page_info *iommu_alloc_pgtable(struct domain_iommu *hd,
>>      if ( contig_mask )
>>      {
>>          /* See pt-contig-markers.h for a description of the marker scheme. */
>> -        unsigned int i, shift = find_first_set_bit(contig_mask);
>> +        unsigned int i, shift = ffsl(contig_mask) - 1;
> The need for subtracting 1 is why personally I dislike ffs() / ffsl() (and
> why I think find_first_set_bit() and __ffs() (but no __ffsl()) were
> introduced).

It's sad that there are competing APIs with different bit-labelling, but
the optimiser does cancel the -1 with arch_ffs() (for at least x86 and
ARM that I studied in detail).

I firmly believe that fewer APIs which are fully well defined (and can
optimise based on the compiler's idea of safety) is still better than a
maze of APIs with different behaviours.

> But what I first of all would like to have clarification on is what your
> (perhaps just abstract at this point) plans are wrt ffz() / ffzl().
> Potential side-by-side uses would be odd now, and would continue to be odd
> if the difference in bit labeling was retained. Since we're switching to
> a consolidated set of basic helpers, such an anomaly would better not
> survive imo.

I honestly hadn't got that far yet.  I was mainly trying to dis-entangle
the existing mess so RISC-V wasn't making it yet-worse.

But yes - it warrants thinking about.


I was intending to do the fls() next then popcnt().   The latter has
quite a lot of cleanup wanting to come with it, and is more
architecturally invasive, and I know I've got a years-old outstanding
piece of work to try and do popcnt more nicely on x86.

I have wanted ffz() in the past.  I think I just went with explicit ~
because I didn't want to continue this debate at the time.

However, I (very much more) do not want a situation where ffs() and
ffz() have different bit-labellings.


There are no builtins, and having now studied the architectures we care
about... https://godbolt.org/z/KasP41n1e ...not even x86 has a "count
leading/trailing zeros" instruction.

So using ffs(~val) really will get you the best code generation
available, and seeing as it halves the number of bitops to maintain, I
think this is the best tradeoff overall.

I intend to put ffz() and __ffs() into linux-compat.h and leave them
there to discourage their use generally.

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 18:51:21 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 18:51:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693451.1081533 (Exim 4.92)
	(envelope-from )
	id 1rkqAi-0000lh-9S; Thu, 14 Mar 2024 18:51:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693451.1081533; Thu, 14 Mar 2024 18:51:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkqAi-0000la-6m; Thu, 14 Mar 2024 18:51:20 +0000
Received: by outflank-mailman (input) for mailman id 693451;
 Thu, 14 Mar 2024 18:51:19 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkqAh-0000lU-4N
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 18:51:19 +0000
Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com
 [2607:f8b0:4864:20::829])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d705c156-e233-11ee-afdd-a90da7624cb6;
 Thu, 14 Mar 2024 19:51:18 +0100 (CET)
Received: by mail-qt1-x829.google.com with SMTP id
 d75a77b69052e-42ee33b2d58so7005851cf.3
 for ; Thu, 14 Mar 2024 11:51:18 -0700 (PDT)
Received: from [10.80.67.149] (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 d13-20020ac847cd000000b0042f21fe66f7sm1066590qtr.73.2024.03.14.11.51.14
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 14 Mar 2024 11:51:16 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d705c156-e233-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710442277; x=1711047077; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:references:cc:to
         :from:content-language:subject:user-agent:mime-version:date
         :message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=35IIQwAtd0xy77CIsxN6/OzZ7I4Hyg1YPyW5Febi9xY=;
        b=Qrq4Fi/wlqCgQDxIpqvMTM1VBJCgN9+Av3XDHcJ6UhbBXGSNFymh2OOGcABeMTrCVG
         O2RxPcX9lyJNhwN+8Cd7OQwWivHF05qhVSib5sVHl5Mj2YuHpXAQGjldFJe6zohIMM+B
         NfcNzjO7Pjpzb99rAPX8qz9t4tSeGPW2jLhdc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710442277; x=1711047077;
        h=content-transfer-encoding:in-reply-to:autocrypt:references:cc:to
         :from:content-language:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=35IIQwAtd0xy77CIsxN6/OzZ7I4Hyg1YPyW5Febi9xY=;
        b=dlqDoKjy6I41oGoWZ5KvYxM1XuUn+IPB0kRqniSjZUk8KrWgGYGn1KNDN1vGpz2IMn
         JBlxc8ukNw6jGRz6Ocntx84zdzr9JjwxkqCOUJjzu7Wzw9oqirBCmOEX2W5owYo7tEA6
         AxmyM/HYPPTQZM7t25oochzlVddmaesmgZ89q1qthR53g2PC0B+bFURK9jlXbgMfAj3q
         zBJpNMZvk5cZ+TiINwfGm5/LfY/ZKOubcWDgycwoW83PXWuHwaBMkYSx4gO6RZvPntZG
         F8pRIe5bQzQ5ay/Gvw1ZkBHSFJEVwm0mLg5lNgg96D4g/TuK1Xs7nQpIPC47v4KT457o
         ptEA==
X-Forwarded-Encrypted: i=1; AJvYcCUjl/hhZnnkDE4DRS1rCyP91CzjOCvJXapQFrCYKsQ01ptGdTeW9BW9CT1MV+6NAqQOXCXqXk6KbOlqYUTfa3aq8aXgl/hVuhKPnU7wQuQ=
X-Gm-Message-State: AOJu0YyCmvZoWilrKP9M5KaMksogXsWeA7dh0K9nmrkyNdIbIsahE2XJ
	dvILBbVlMw91OnlvAseoqT92Ne3NPEaNmGM8rC9K8wotSubsRK0snWgeompWFLE=
X-Google-Smtp-Source: AGHT+IGPldSYfuK3jyE6mCTuz/mAQ2JfROMvXHyXNdFjJDxuECYBJrBNX8ONvlIRvzcpc/aHqWKgew==
X-Received: by 2002:ac8:5e50:0:b0:42e:d18f:71d9 with SMTP id i16-20020ac85e50000000b0042ed18f71d9mr2790790qtx.5.1710442276817;
        Thu, 14 Mar 2024 11:51:16 -0700 (PDT)
Message-ID: 
Date: Thu, 14 Mar 2024 18:51:13 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 6/7] xen: Swap find_first_set_bit() for ffsl() - 1
Content-Language: en-GB
From: Andrew Cooper 
To: Jan Beulich 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Wei Liu , Stefano Stabellini ,
 Julien Grall , Volodymyr Babchuk
 , Bertrand Marquis ,
 Michal Orzel ,
 Oleksii Kurochko ,
 Shawn Anastasio ,
 "consulting @ bugseng . com" ,
 Simone Ballarin ,
 Federico Serafini ,
 Nicola Vetrini ,
 Xen-devel 
References: <20240313172716.2325427-1-andrew.cooper3@citrix.com>
 <20240313172716.2325427-7-andrew.cooper3@citrix.com>
 
 <1356dd16-03e1-4c01-9aac-597a127dea85@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <1356dd16-03e1-4c01-9aac-597a127dea85@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 14/03/2024 6:47 pm, Andrew Cooper wrote:
> On 14/03/2024 2:30 pm, Jan Beulich wrote:
>> On 13.03.2024 18:27, Andrew Cooper wrote:
>>> --- a/xen/drivers/passthrough/x86/iommu.c
>>> +++ b/xen/drivers/passthrough/x86/iommu.c
>>> @@ -641,7 +641,7 @@ struct page_info *iommu_alloc_pgtable(struct domain_iommu *hd,
>>>      if ( contig_mask )
>>>      {
>>>          /* See pt-contig-markers.h for a description of the marker scheme. */
>>> -        unsigned int i, shift = find_first_set_bit(contig_mask);
>>> +        unsigned int i, shift = ffsl(contig_mask) - 1;
>> The need for subtracting 1 is why personally I dislike ffs() / ffsl() (and
>> why I think find_first_set_bit() and __ffs() (but no __ffsl()) were
>> introduced).
> It's sad that there are competing APIs with different bit-labelling, but
> the optimiser does cancel the -1 with arch_ffs() (for at least x86 and
> ARM that I studied in detail).
>
> I firmly believe that fewer APIs which are fully well defined (and can
> optimise based on the compiler's idea of safety) is still better than a
> maze of APIs with different behaviours.
>
>> But what I first of all would like to have clarification on is what your
>> (perhaps just abstract at this point) plans are wrt ffz() / ffzl().
>> Potential side-by-side uses would be odd now, and would continue to be odd
>> if the difference in bit labeling was retained. Since we're switching to
>> a consolidated set of basic helpers, such an anomaly would better not
>> survive imo.
> I honestly hadn't got that far yet.  I was mainly trying to dis-entangle
> the existing mess so RISC-V wasn't making it yet-worse.
>
> But yes - it warrants thinking about.
>
>
> I was intending to do the fls() next then popcnt().   The latter has
> quite a lot of cleanup wanting to come with it, and is more
> architecturally invasive, and I know I've got a years-old outstanding
> piece of work to try and do popcnt more nicely on x86.
>
> I have wanted ffz() in the past.  I think I just went with explicit ~
> because I didn't want to continue this debate at the time.
>
> However, I (very much more) do not want a situation where ffs() and
> ffz() have different bit-labellings.
>
>
> There are no builtins, and having now studied the architectures we care
> about... https://godbolt.org/z/KasP41n1e ...not even x86 has a "count
> leading/trailing zeros" instruction.

Hopefully obviously, I meant ones here.   My point is that the compiler
emitted code always has a NOT in it somewhere.

>
> So using ffs(~val) really will get you the best code generation
> available, and seeing as it halves the number of bitops to maintain, I
> think this is the best tradeoff overall.
>
> I intend to put ffz() and __ffs() into linux-compat.h and leave them
> there to discourage their use generally.
>
> ~Andrew



From xen-devel-bounces@lists.xenproject.org Thu Mar 14 18:56:44 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 18:56:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693456.1081543 (Exim 4.92)
	(envelope-from )
	id 1rkqFs-0001O6-Sh; Thu, 14 Mar 2024 18:56:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693456.1081543; Thu, 14 Mar 2024 18:56:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkqFs-0001Nz-Pt; Thu, 14 Mar 2024 18:56:40 +0000
Received: by outflank-mailman (input) for mailman id 693456;
 Thu, 14 Mar 2024 18:56:39 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkqFr-0001Nn-8S; Thu, 14 Mar 2024 18:56:39 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkqFr-0007Ss-1Y; Thu, 14 Mar 2024 18:56:39 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkqFq-0008Sd-MU; Thu, 14 Mar 2024 18:56:38 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rkqFq-0004zI-M1; Thu, 14 Mar 2024 18:56:38 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=Yzw+IYUyji/yNQKM1varTG7kSOBONt+JWLRQClXkvK0=; b=rur53hjQJnrNEvPr/TlxQdDI47
	QUeuF7sScPjW5Quh/XhPjS7ldW0oWVJt6B749PNYgFUY79HmwGdEbS4eq251NEu55ebGnHLJFLMt5
	+zLmpz2i8idpnRDt4Nlz0g4D1yirMPxlAioBQzpX7lgctWbGBDZlOJpiGNhBaoyspY74=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 185023: tolerable FAIL - PUSHED
X-Osstest-Failures:
    linux-linus:test-amd64-amd64-libvirt:guest-start/debian.repeat:fail:heisenbug
    linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    linux=e5e038b7ae9da96b93974bf072ca1876899a01a3
X-Osstest-Versions-That:
    linux=855684c7d938c2442f07eabc154e7532b4c1fbf9
From: osstest service owner 
Date: Thu, 14 Mar 2024 18:56:38 +0000

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-libvirt 20 guest-start/debian.repeat fail pass in 185038-retest

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

version targeted for testing:
 linux                e5e038b7ae9da96b93974bf072ca1876899a01a3
baseline version:
 linux                855684c7d938c2442f07eabc154e7532b4c1fbf9

Last test of basis   185004  2024-03-12 13:44:04 Z    2 days
Failing since        185016  2024-03-13 04:24:26 Z    1 days    2 attempts
Testing same since   185023  2024-03-14 00:14:57 Z    0 days    1 attempts

------------------------------------------------------------
1052 people touched revisions under test,
not listing them all

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-freebsd11-amd64                             pass    
 test-amd64-amd64-freebsd12-amd64                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-libvirt-qcow2                               pass    
 test-armhf-armhf-libvirt-qcow2                               pass    
 test-amd64-amd64-libvirt-raw                                 pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-amd64-xl-vhd                                      pass    
 test-arm64-arm64-xl-vhd                                      pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

Explanation of these 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 :

hint: The 'hooks/update' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
hint: The 'hooks/post-receive' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
hint: The 'hooks/post-update' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
To xenbits.xen.org:/home/xen/git/linux-pvops.git
   855684c7d938c..e5e038b7ae9da  e5e038b7ae9da96b93974bf072ca1876899a01a3 -> tested/linux-linus


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 19:07:56 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 19:07:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693465.1081553 (Exim 4.92)
	(envelope-from )
	id 1rkqQf-0003Xc-Vz; Thu, 14 Mar 2024 19:07:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693465.1081553; Thu, 14 Mar 2024 19:07:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkqQf-0003XV-TR; Thu, 14 Mar 2024 19:07:49 +0000
Received: by outflank-mailman (input) for mailman id 693465;
 Thu, 14 Mar 2024 19:03:04 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkqM4-0003PL-Ka
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 19:03:04 +0000
Received: from mail-pf1-f170.google.com (mail-pf1-f170.google.com
 [209.85.210.170]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7b714a19-e235-11ee-afdd-a90da7624cb6;
 Thu, 14 Mar 2024 20:03:03 +0100 (CET)
Received: by mail-pf1-f170.google.com with SMTP id
 d2e1a72fcca58-6e6ee9e3cffso525375b3a.1
 for ; Thu, 14 Mar 2024 12:03:03 -0700 (PDT)
Received: from
 liuwe-devbox-debian-v2.lamzopl0uupeniq2etz1fddiyg.xx.internal.cloudapp.net
 ([20.69.120.36]) by smtp.gmail.com with ESMTPSA id
 c28-20020a631c5c000000b005dc4829d0e1sm1020966pgm.85.2024.03.14.12.03.01
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 14 Mar 2024 12:03:01 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7b714a19-e235-11ee-afdd-a90da7624cb6
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710442982; x=1711047782;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=iIhTvWiIiruvW4futHFoixCiMWFfl1h56d1q6p2Xg1I=;
        b=Yx8po4H1i4vOrNkqiAj1hLq+ua2SBfVnhZ4/ogF8QfpPQ/HWEG/fdFu4xB4hMJMvNL
         8Ns8HD9coK1NLpjTH6f4xe/HrjzGjtQ9iCZ4AML7pwuPcmkEZ0NC73wpqsJag+JHIKKf
         IMUKt25s40vHhksizRIdEItLBoUOcg4b/rW18sTLGMddW1V9vGN7qzu/i1K9FwXRXbJX
         uURPvwcU22WeFwz8qY7DZ3feeeVUmvM87ZepLwk7/i7A8egQl6kqvT0lb1YgE9to1Rdl
         110+ziZkaON+nB1dCl7tzo1lH22IyF4d0DcH9AaDQE8NgvGKHoAOLnsD91u7luY1Brm+
         J79Q==
X-Gm-Message-State: AOJu0YyRYPwTMnxkjnHZqnv0fF9VL1a1kz8q57L47AiZeToow7Qj5SEE
	zSV6k8kfc8lXbFgEBf3GgCkYMbjH1ibsP5pBT7+2cIPRLTcCW5xPdzjjU7U9
X-Google-Smtp-Source: AGHT+IHsagkwLC9rBgzPMX3mqy9u/Ds6Fdh3w7nLO5y8n6iMR9M8tc0hW4/zXvKW9/XPzVIPz9/S5Q==
X-Received: by 2002:a05:6a00:3d01:b0:6e6:9cc9:59b3 with SMTP id lo1-20020a056a003d0100b006e69cc959b3mr4167236pfb.5.1710442982022;
        Thu, 14 Mar 2024 12:03:02 -0700 (PDT)
From: Wei Liu 
To: Xen Development List 
Cc: liuwe@microsoft.com,
	wei.liu@kernel.org,
	Wei Liu ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini 
Subject: [PATCH] MAINTAINERS: remove myself from various positions
Date: Thu, 14 Mar 2024 19:02:37 +0000
Message-ID: <20240314190239.908402-1-wl@xen.org>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

I have not been active in the Xen community for some time. Update the
MAINTAINERS file to reflect reality.

Signed-off-by: Wei Liu 
---
It has been a pleasure working with all of you. I'm sure we will cross
paths in the future.

Seabios is in need for a new owner. For now I left my name there.
---
 MAINTAINERS | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index b2cc3cc3921b..f003085ad175 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -387,7 +387,6 @@ F:	xen/arch/x86/machine_kexec.c
 F:	xen/arch/x86/x86_64/kexec_reloc.S
 
 LIBS
-M:	Wei Liu 
 M:	Anthony PERARD 
 R:	Juergen Gross 
 S:	Supported
@@ -422,7 +421,6 @@ F:	xen/test/livepatch/*
 MINI-OS
 M:	Samuel Thibault 
 M:	Juergen Gross 
-R:	Wei Liu 
 S:	Supported
 L:	minios-devel@lists.xenproject.org
 T:	git https://xenbits.xenproject.org/git-http/mini-os.git
@@ -436,7 +434,6 @@ F:	tools/ocaml/
 
 OVMF UPSTREAM
 M:	Anthony PERARD 
-M:	Wei Liu 
 S:	Supported
 T:	git https://xenbits.xenproject.org/git-http/ovmf.git
 
@@ -521,7 +518,6 @@ F:	xen/arch/arm/include/asm/tee
 F:	xen/arch/arm/tee/
 
 TOOLSTACK
-M:	Wei Liu 
 M:	Anthony PERARD 
 S:	Supported
 F:	autogen.sh
@@ -583,7 +579,6 @@ X86 ARCHITECTURE
 M:	Jan Beulich 
 M:	Andrew Cooper 
 M:	Roger Pau Monné 
-R:	Wei Liu 
 S:	Supported
 L:	xen-devel@lists.xenproject.org
 F:	xen/arch/x86/
@@ -626,7 +621,6 @@ F:	xen/arch/x86/mm/shadow/
 
 X86 VIRIDIAN ENLIGHTENMENTS
 M:	Paul Durrant 
-M:	Wei Liu 
 S:	Supported
 F:	xen/arch/x86/guest/hyperv/
 F:	xen/arch/x86/hvm/viridian/
@@ -636,7 +630,6 @@ F:	xen/arch/x86/include/asm/guest/hyperv-tlfs.h
 F:	xen/arch/x86/include/asm/hvm/viridian.h
 
 XENSTORE
-M:	Wei Liu 
 M:	Juergen Gross 
 R:	Julien Grall 
 S:	Supported
@@ -682,7 +675,6 @@ M:	George Dunlap 
 M:	Jan Beulich 
 M:	Julien Grall 
 M:	Stefano Stabellini 
-M:	Wei Liu 
 L:	xen-devel@lists.xenproject.org
 S:	Supported
 F:	*
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Mar 14 19:19:53 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 19:19:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693471.1081567 (Exim 4.92)
	(envelope-from )
	id 1rkqcG-0005j0-04; Thu, 14 Mar 2024 19:19:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693471.1081567; Thu, 14 Mar 2024 19:19:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkqcF-0005it-SY; Thu, 14 Mar 2024 19:19:47 +0000
Received: by outflank-mailman (input) for mailman id 693471;
 Thu, 14 Mar 2024 19:19:46 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkqcE-0005ij-Gi
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 19:19:46 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on20601.outbound.protection.outlook.com
 [2a01:111:f403:2414::601])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id cfb14d59-e237-11ee-a1ee-f123f15fe8a2;
 Thu, 14 Mar 2024 20:19:44 +0100 (CET)
Received: from CH2PR17CA0018.namprd17.prod.outlook.com (2603:10b6:610:53::28)
 by SJ0PR12MB7065.namprd12.prod.outlook.com (2603:10b6:a03:4ae::19)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.21; Thu, 14 Mar
 2024 19:19:40 +0000
Received: from CY4PEPF0000EDD7.namprd03.prod.outlook.com
 (2603:10b6:610:53:cafe::41) by CH2PR17CA0018.outlook.office365.com
 (2603:10b6:610:53::28) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.20 via Frontend
 Transport; Thu, 14 Mar 2024 19:19:40 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CY4PEPF0000EDD7.mail.protection.outlook.com (10.167.241.211) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7386.12 via Frontend Transport; Thu, 14 Mar 2024 19:19:39 +0000
Received: from SATLEXMB08.amd.com (10.181.40.132) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 14 Mar
 2024 14:19:38 -0500
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB08.amd.com
 (10.181.40.132) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 14 Mar
 2024 12:19:38 -0700
Received: from [172.17.162.8] (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Thu, 14 Mar 2024 14:19:37 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: cfb14d59-e237-11ee-a1ee-f123f15fe8a2
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=cl+x09hD3usxbBPSkWEJ9g4gN+CtcfOlhJV8PrzcAIFZaBgbO3tYEpdUK41RObZ7KZZXjs74CECfME5lpliJpeyJ++Zz73XyTBW6fiS76dGfG3L1unVeMqHfz/ZkmRSpVTE295r/spLkrjSDssERT8PKaj9TVE58QzN0TxKcmGokl4/8HI067vWsiVCBG5HQwApi/9iOY+mxraYCUl7KFQsMCYRPINzjGpoXVZV435k6B6a5D/ahAB9Z6ZMfzBPyMAQNO5kC1Z426qKO9r+kmAh5kFGcYI6mgue6puWHO1p+cWQq++JfXufQth6aXoI188LDGOoRSGYsmhi/mdTqig==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Qg/6kFamlDBS5RrBwaJRByAveRK72o7QVCM4MUN4aBg=;
 b=krVPz4D/FWOtjwE4TyTJNLUcwGEFYlSsKwPMzVT4T+Z0mKvMBzitXuEr9zj8PnQQzUOE1qYXYvY9tqqw06sTyUce6zAiOq+yPmOvnHFlxWfeMyEB2J0iRuI8IgLmi5FZwtgn7YU0XjaxTPZ3xgN8mm7+SLkKV5zPajWqxjAOEajKLg4jwIrNGd/l6hQ3Z5qXSUrFeTfOyczJTPDeBOagN60Cblap5Ega5/+U2xuPFiRyvXACyM7ohYUkVIrZdPWTQh13+icG1Ez8/GyyPOl8PsJfVOcXK+cZ7aOXRcZLBgIuiWgAFXVzBUoU50SpRgVeuhAMbwk9NyK2qL18BZEMkQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=Qg/6kFamlDBS5RrBwaJRByAveRK72o7QVCM4MUN4aBg=;
 b=DKyujHF4HTBBt1f1RD266Bv8Qym9Nee8AD2PCM0wvcjbCgbRkDOjx8xnqo/4j+5sbER0dEYpOe/DMz6eDZL85YopAToipAxTw3wOE6U+n2ROWK9BJCCTuRURufeoByPhpbbTFFQ7EQkWaf4dkeD+IIUv72WvcBMsBH68WoyvxOM=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Message-ID: <7506abe0-e3d4-44f7-b54d-592ae2e3fd3e@amd.com>
Date: Thu, 14 Mar 2024 15:19:38 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 3/3] x86/PVH: Support relocatable dom0 kernels
Content-Language: en-US
To: Jan Beulich 
CC: Andrew Cooper ,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu
	, George Dunlap , Julien Grall
	, Stefano Stabellini ,
	
References: <20240313193021.241764-1-jason.andryuk@amd.com>
 <20240313193021.241764-4-jason.andryuk@amd.com>
 <12fe48a6-6957-49d7-adf5-1a3ac8b1bfaa@suse.com>
From: Jason Andryuk 
In-Reply-To: <12fe48a6-6957-49d7-adf5-1a3ac8b1bfaa@suse.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CY4PEPF0000EDD7:EE_|SJ0PR12MB7065:EE_
X-MS-Office365-Filtering-Correlation-Id: 808bd57d-02d2-4705-0516-08dc445bb1e1
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	r7rEaQ4oSDkzMRuE4TUWhuEwLDELjCGbsGLMnoP3qPj44np4Bm1h6oc4OD2dYfKOpmDGU1mlyYuP6uGYVyRlgHlw0Lx3OPLsMJ3Jylml3jwqcXwGztsFxy3RWYg4XAUaSxJ5fv50NjtwIHBSuVVDv7CYyKf03E26Yx2nkZ2u+l6PY5Lz37hN9aa0cg+YhfJ9TmCcAoPABIAVFCL12vCHHZLvoLkjBKsPTLWdZoZF+X2DzEtiwiHcplRVyeiqq0IfXpsekQVXqaDkrYPFB3wSdsH30evSNuwlUffpUCQCepQ3XD59drqOeL2yYaaNnox39ZVztudeVpaLmbfw0yqrYRwHLfPrgjSQiieDRP1fY2hFXbhrTaHoc9pNlPI7lzwEcjDaJP/+J63o6mtjVrI9jxA6pdroIwbFXuv9iFEPBTYZ+EN7zZzFl6Llzhhx9jhcPxxbD0egvBZ2Xvjhqzin5YV/qkfWpT1xm5gn16f+B+XvmpwUvAnrqXi1389BoFKhAqMuO4FSVWVrqvBoVDMwqPKPJJGSpHluJpvOC7eQlk087IKW1URbk4nAuvn33ojTAcnN+0MOSPlgqDxMJFKkkXfZerOwVeUTlaY2w6v/9UXq2my3McrpEUJzrt/sF8I/F4JMydASDwFweOLxk5FJplZ34qt2KSTOIDFbrBzchlC/Clz+b05rg3d7/2ptLU4nQityYwDCCaGi2BlN+m6aAVbghsLxlAahOli8rOKUzaSl8EjeeUEcYQpVXqNC5rvE
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(1800799015)(36860700004)(376005)(82310400014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Mar 2024 19:19:39.5700
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 808bd57d-02d2-4705-0516-08dc445bb1e1
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CY4PEPF0000EDD7.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR12MB7065

On 2024-03-14 09:31, Jan Beulich wrote:
> On 13.03.2024 20:30, Jason Andryuk wrote:
>> --- a/xen/arch/x86/hvm/dom0_build.c
>> +++ b/xen/arch/x86/hvm/dom0_build.c
>> @@ -537,6 +537,108 @@ static paddr_t __init find_memory(
>>       return INVALID_PADDR;
>>   }
>>   
>> +static bool __init check_load_address(
>> +    const struct domain *d, const struct elf_binary *elf)
>> +{
>> +    paddr_t kernel_start = (paddr_t)elf->dest_base & PAGE_MASK;
>> +    paddr_t kernel_end = PAGE_ALIGN((paddr_t)elf->dest_base + elf->dest_size);
> 
> Both casts act on a pointer value. Such cannot legitimately be converted
> to paddr_t; it only so happens that paddr_t is effectively the same as
> uintptr_t right now. (Same issue again further down.) That said, I notice
> we have pre-existing examples of this ...

Yes, I followed existing code.  Do you want dest_base to be switched to 
a uintptr_t?

>> +/* Check the kernel load address, and adjust if necessary and possible. */
>> +static bool __init check_and_adjust_load_address(
>> +    const struct domain *d, struct elf_binary *elf, struct elf_dom_parms *parms)
>> +{
>> +    paddr_t reloc_base;
>> +
>> +    if ( check_load_address(d, elf) )
>> +        return true;
>> +
>> +    if ( parms->phys_align == UNSET_ADDR )
>> +    {
>> +        printk("Address conflict and %pd kernel is not relocatable\n", d);
>> +        return false;
>> +    }
>> +
>> +    reloc_base = find_kernel_memory(d, elf, parms);
>> +    if ( reloc_base == 0 )
>> +    {
>> +        printk("Failed find a load address for the kernel\n");
>> +        return false;
>> +    }
>> +
>> +    if ( opt_dom0_verbose )
>> +        printk("Relocating kernel from [%lx, %lx] -> [%lx, %lx]\n",
>> +               (paddr_t)elf->dest_base,
>> +               (paddr_t)elf->dest_base + elf->dest_size,
> 
> By using %p you clearly can avoid the casts here.

Ok.

>> +               reloc_base, reloc_base + elf->dest_size);
> 
> I'm not convinced %lx is really appropriate for paddr_t.

PRIpaddr exists.  It's "016lx" for x86.  Using that and %p add lots of 0s:
(XEN) Relocating kernel from [0000000001000000, 000000000202ffff] -> 
[0000000002200000, 000000000322ffff]

Regards,
Jason


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 19:24:24 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 19:24:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693474.1081580 (Exim 4.92)
	(envelope-from )
	id 1rkqgg-0007Kj-HV; Thu, 14 Mar 2024 19:24:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693474.1081580; Thu, 14 Mar 2024 19:24:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkqgg-0007Kc-Dj; Thu, 14 Mar 2024 19:24:22 +0000
Received: by outflank-mailman (input) for mailman id 693474;
 Thu, 14 Mar 2024 19:24:21 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkqgf-0007KW-M5
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 19:24:21 +0000
Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 73131814-e238-11ee-a1ee-f123f15fe8a2;
 Thu, 14 Mar 2024 20:24:19 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sin.source.kernel.org (Postfix) with ESMTP id EF150CE1E62;
 Thu, 14 Mar 2024 19:24:15 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 19B47C433F1;
 Thu, 14 Mar 2024 19:24:13 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 73131814-e238-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1710444255;
	bh=8HWGyCa2jj/1cUUh9PVsnhTUObz0v0gsP1kArkzUU3o=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=RJwRjxefgg0bsJlP4oyxjnbWEO5ORW02BKsVY9aT8E+e548E1aoL1s9hSG85If3nB
	 JMlIlHpkr8qebTrG2GL021iQ0au4OIf0OX1Un+1GDAUlOYyC9Bdn73oLt7RDy38beZ
	 HzRvjZHPlGNxJY1Jmt/h3KFCGj+qdfDX+EyBfBcWAAiJEZoa6EXfApGqcA5baE4Bzb
	 +pIy8hlW6zetVE7il5n0ewmyBBiqyBBRS/l6/uzgzpkAR/2gxYb+vQcczg4eYyx7qG
	 DTpQCz9DHi4o4AdmiO9nXaZg6x0oiyk7l/aphdNEgqr/3sBmP2vzF5xlGgJu88Q7UE
	 MnDQlPopQ61nA==
Date: Thu, 14 Mar 2024 12:24:12 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Wei Liu 
cc: Xen Development List , liuwe@microsoft.com, 
    wei.liu@kernel.org, Andrew Cooper , 
    George Dunlap , Jan Beulich , 
    Julien Grall , Stefano Stabellini 
Subject: Re: [PATCH] MAINTAINERS: remove myself from various positions
In-Reply-To: <20240314190239.908402-1-wl@xen.org>
Message-ID: 
References: <20240314190239.908402-1-wl@xen.org>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1778962320-1710444255=:853156"

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-1778962320-1710444255=:853156
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Thu, 14 Mar 2024, Wei Liu wrote:
> I have not been active in the Xen community for some time. Update the
> MAINTAINERS file to reflect reality.
> 
> Signed-off-by: Wei Liu 

Acked-by: Stefano Stabellini 


> ---
> It has been a pleasure working with all of you. I'm sure we will cross
> paths in the future.

Thanks Wei! It has been fantastic working with you, and I look forward
at the opportunity to do so again when the opportunity arises in the
future.


> Seabios is in need for a new owner. For now I left my name there.
> ---
>  MAINTAINERS | 8 --------
>  1 file changed, 8 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index b2cc3cc3921b..f003085ad175 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -387,7 +387,6 @@ F:	xen/arch/x86/machine_kexec.c
>  F:	xen/arch/x86/x86_64/kexec_reloc.S
>  
>  LIBS
> -M:	Wei Liu 
>  M:	Anthony PERARD 
>  R:	Juergen Gross 
>  S:	Supported
> @@ -422,7 +421,6 @@ F:	xen/test/livepatch/*
>  MINI-OS
>  M:	Samuel Thibault 
>  M:	Juergen Gross 
> -R:	Wei Liu 
>  S:	Supported
>  L:	minios-devel@lists.xenproject.org
>  T:	git https://xenbits.xenproject.org/git-http/mini-os.git
> @@ -436,7 +434,6 @@ F:	tools/ocaml/
>  
>  OVMF UPSTREAM
>  M:	Anthony PERARD 
> -M:	Wei Liu 
>  S:	Supported
>  T:	git https://xenbits.xenproject.org/git-http/ovmf.git
>  
> @@ -521,7 +518,6 @@ F:	xen/arch/arm/include/asm/tee
>  F:	xen/arch/arm/tee/
>  
>  TOOLSTACK
> -M:	Wei Liu 
>  M:	Anthony PERARD 
>  S:	Supported
>  F:	autogen.sh
> @@ -583,7 +579,6 @@ X86 ARCHITECTURE
>  M:	Jan Beulich 
>  M:	Andrew Cooper 
>  M:	Roger Pau Monné 
> -R:	Wei Liu 
>  S:	Supported
>  L:	xen-devel@lists.xenproject.org
>  F:	xen/arch/x86/
> @@ -626,7 +621,6 @@ F:	xen/arch/x86/mm/shadow/
>  
>  X86 VIRIDIAN ENLIGHTENMENTS
>  M:	Paul Durrant 
> -M:	Wei Liu 
>  S:	Supported
>  F:	xen/arch/x86/guest/hyperv/
>  F:	xen/arch/x86/hvm/viridian/
> @@ -636,7 +630,6 @@ F:	xen/arch/x86/include/asm/guest/hyperv-tlfs.h
>  F:	xen/arch/x86/include/asm/hvm/viridian.h
>  
>  XENSTORE
> -M:	Wei Liu 
>  M:	Juergen Gross 
>  R:	Julien Grall 
>  S:	Supported
> @@ -682,7 +675,6 @@ M:	George Dunlap 
>  M:	Jan Beulich 
>  M:	Julien Grall 
>  M:	Stefano Stabellini 
> -M:	Wei Liu 
>  L:	xen-devel@lists.xenproject.org
>  S:	Supported
>  F:	*
> -- 
> 2.43.0
> 
--8323329-1778962320-1710444255=:853156--


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 19:53:42 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 19:53:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693480.1081590 (Exim 4.92)
	(envelope-from )
	id 1rkr8r-0003dy-LX; Thu, 14 Mar 2024 19:53:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693480.1081590; Thu, 14 Mar 2024 19:53:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkr8r-0003dr-IZ; Thu, 14 Mar 2024 19:53:29 +0000
Received: by outflank-mailman (input) for mailman id 693480;
 Thu, 14 Mar 2024 19:53:28 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkr8q-0003dl-OV
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 19:53:28 +0000
Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8487aaca-e23c-11ee-a1ee-f123f15fe8a2;
 Thu, 14 Mar 2024 20:53:26 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sin.source.kernel.org (Postfix) with ESMTP id 4F1D9CE1E5D;
 Thu, 14 Mar 2024 19:53:23 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3C16FC433F1;
 Thu, 14 Mar 2024 19:53:21 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8487aaca-e23c-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1710446002;
	bh=G3dubiycm6kBLZkZ4BwKaUn1NRVJSeofPZbgIHNH/kY=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=N8xXKJyAisgtUo2JMgxX/IEdDK/8J6ZTT0MquDS5NyuIxZMLj/qyGzvREX5Oy4VPO
	 6fe3FFH8E0+386P9oBHYyOug9UHTHkfO3suLt0eUVwfTQDNG6U1g+CJmdeJKfIAJew
	 t0CN+70Ao23FqmaxKtl1IYTsx0BlZdSMJFeBblqJFd6RMVEyxgUN6uAGh5AtDdfccq
	 LoDlaynHNGkwVYmTp/xmGXYnReICkOOuFMGNGxQuJXim0lq0P7C+U7uQ1jzB0zMrSa
	 0QGgyXirvLBX4pI6N69uK/xUYaLmLTjl1GoTDrNpl5Zm08YdGtNWNfttft00DluBxG
	 ///hMW/okPiPw==
Date: Thu, 14 Mar 2024 12:53:19 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Federico Serafini 
cc: xen-devel@lists.xenproject.org, consulting@bugseng.com, 
    Simone Ballarin , 
    Doug Goldstein , 
    Stefano Stabellini , 
    Andrew Cooper , 
    George Dunlap , Jan Beulich , 
    Julien Grall , Wei Liu 
Subject: Re: [XEN PATCH] automation/eclair: allow parameter name "unused"
In-Reply-To: 
Message-ID: 
References: 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Thu, 14 Mar 2024, Federico Serafini wrote:
> Update ECLAIR configuration of MISRA C:2012 Rule 8.3 to deviate
> violations involving parameter name "unused":
> it makes explicit the intention of not using the parameter within
> the function.
> 
> Signed-off-by: Federico Serafini 

Reviewed-by: Stefano Stabellini 


> ---
>  automation/eclair_analysis/ECLAIR/deviations.ecl | 4 ++++
>  docs/misra/deviations.rst                        | 5 +++++
>  2 files changed, 9 insertions(+)
> 
> diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
> index 9ac3ee4dfd..7e913050d2 100644
> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> @@ -167,6 +167,10 @@ const-qualified."
>  -config=MC3R1.R8.3,reports+={deliberate,"any_area(any_loc(file(adopted_decompress_r8_3)))&&any_area(any_loc(file(^xen/include/xen/decompress\\.h$)))"}
>  -doc_end
>  
> +-doc_begin="Parameter name \"unused\" is deliberate and makes explicit the intention of not using the parameter within the function."
> +-config=MC3R1.R8.3,reports+={deliberate, "any_area(^.*parameter `unused'.*$)"}
> +-doc_end
> +
>  -doc_begin="The following file is imported from Linux: ignore for now."
>  -file_tag+={adopted_time_r8_3,"^xen/arch/x86/time\\.c$"}
>  -config=MC3R1.R8.3,reports+={deliberate,"any_area(any_loc(file(adopted_time_r8_3)))&&(any_area(any_loc(file(^xen/include/xen/time\\.h$)))||any_area(any_loc(file(^xen/arch/x86/include/asm/setup\\.h$))))"}
> diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
> index ce855ddae6..941da4c40b 100644
> --- a/docs/misra/deviations.rst
> +++ b/docs/misra/deviations.rst
> @@ -157,6 +157,11 @@ Deviations related to MISRA C:2012 Rules:
>           - xen/common/unxz.c
>           - xen/common/unzstd.c
>  
> +   * - R8.3
> +     - Parameter name "unused" is deliberate and makes explicit the intention
> +       of not using the parameter within the function.
> +     - Tagged as `deliberate` for ECLAIR.
> +
>     * - R8.4
>       - The definitions present in the files 'asm-offsets.c' for any architecture
>         are used to generate definitions for asm modules, and are not called by
> -- 
> 2.34.1
> 


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 20:36:47 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 20:36:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693484.1081599 (Exim 4.92)
	(envelope-from )
	id 1rkroZ-00014C-Qb; Thu, 14 Mar 2024 20:36:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693484.1081599; Thu, 14 Mar 2024 20:36:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkroZ-000145-Nr; Thu, 14 Mar 2024 20:36:35 +0000
Received: by outflank-mailman (input) for mailman id 693484;
 Thu, 14 Mar 2024 20:36:34 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkroY-00013z-HZ
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 20:36:34 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on20601.outbound.protection.outlook.com
 [2a01:111:f403:200a::601])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 89eebc2b-e242-11ee-a1ee-f123f15fe8a2;
 Thu, 14 Mar 2024 21:36:32 +0100 (CET)
Received: from SA9PR13CA0113.namprd13.prod.outlook.com (2603:10b6:806:24::28)
 by DS0PR12MB6413.namprd12.prod.outlook.com (2603:10b6:8:ce::10) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.20; Thu, 14 Mar
 2024 20:36:26 +0000
Received: from SN1PEPF00026367.namprd02.prod.outlook.com
 (2603:10b6:806:24:cafe::17) by SA9PR13CA0113.outlook.office365.com
 (2603:10b6:806:24::28) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.7 via Frontend
 Transport; Thu, 14 Mar 2024 20:36:26 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SN1PEPF00026367.mail.protection.outlook.com (10.167.241.132) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7386.12 via Frontend Transport; Thu, 14 Mar 2024 20:36:26 +0000
Received: from SATLEXMB06.amd.com (10.181.40.147) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 14 Mar
 2024 15:36:25 -0500
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB06.amd.com
 (10.181.40.147) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 14 Mar
 2024 15:36:25 -0500
Received: from [172.17.162.8] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Thu, 14 Mar 2024 15:36:25 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 89eebc2b-e242-11ee-a1ee-f123f15fe8a2
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=iriAO/cXkp52RhhXjvoa82enwqTn+a7epl+vUDfhGtnhFJI6z75pM5/s3KaJ5th6w9HdA1nOOEqE5trgyBlfN/t7AumjhUJu8ACfXVeKB8kr0IVO3VPZ8LN35ZzHI3wG3mQ+/BEltUF252d24UtZsmlcczFdOIpl7H7g2Y+g7XPGeHEAN3cfNva4B4++5Dc5nTi8/E4kjzU+bbW5lObQE0YDaKn/2yfApCE93rQbrniuLxKzq+Zqx/HhGqgLAnHnc5Kx83ieitwJ+4MNAUyvsJvj/rQKE4gS3wt/RLAQ5t92d2elMdiVDzRRtdQEWGwTrj53ub09AGeO7OoPdQftYg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=piwOf8ANvZ+qozANPPSOGx1ygTDKAE5UUxoJUqgz4Mk=;
 b=nNCsvxAiFTuEfCb0+xuInShM4qP37pkz9iqWqwCPfACqi4NFezQgOcOsB96H1EIoWjK98pLGctcuwnyKZlDl3BDxJOWLirvG8Va1I0OW9o1JhZ2oQktsQxXUm9L1O2BC99z1HXA+oPgbmI/B0lprWru22h8XiIlN4D6bh6vNmGC0XYeo25NewRB9wWfdJlas0Kh6epLFkjBjF9xzoursc7o7+grIzZDPgWhKkRXGKkRU+sKLJD+jCP0736P5UmVAPnlqtRTb7NVgUM3W27jPB90zg5O/ZsQF4IPGA1cee1zdGZAy3jaZHoUTTt+BarF8FlTDNUIzF+O+XkhBCG9PgQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=piwOf8ANvZ+qozANPPSOGx1ygTDKAE5UUxoJUqgz4Mk=;
 b=uhJg6J16Fz/9VU9PoiMFHTbMBbnrphr1p3GEwXiz/i2V1pU2Bwax1SmDqpEpU028MPF99i/VUdAqY+fGQ4OMERe+ZiuKci7bS4Bhzpv73jklEuWsgpQZvWqyL20UKRcR4v8ChleEpLuPT7Q4Cy5yPQGaNFh/6VLilk7L2a+vkEY=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Message-ID: <7777da94-4c47-4034-9306-bd8161d6af25@amd.com>
Date: Thu, 14 Mar 2024 16:36:27 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/3] libelf: Expand ELF note printing
Content-Language: en-US
To: Jan Beulich 
CC: Andrew Cooper , George Dunlap
	, Julien Grall , Stefano Stabellini
	, Wei Liu ,
	
References: <20240313193021.241764-1-jason.andryuk@amd.com>
 <20240313193021.241764-3-jason.andryuk@amd.com>
 
From: Jason Andryuk 
In-Reply-To: 
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF00026367:EE_|DS0PR12MB6413:EE_
X-MS-Office365-Filtering-Correlation-Id: 7b6746fe-5513-4e38-3ebd-08dc44666bb0
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	Z6EgR2Ol5Ocm1n9FbF4c6yYVNQN5Ob0P+wjXCEhhEB6oYu39zNia7sZZwoZWJDWFis5c9jvx55ydCkDu0ewVD+DBRnIiuaNdj0zpbiCN7nLqBvDBSUQgXqt+C0sb9YgROk3pXcFtClmIAMtIb00pCpma831QIz83BrAfT3rzkzirNH2wXW5elBV9T+IVdEeSLs6axIFuGhKSJiekbPQ4qVtus9QsDVhLy42VXoMnsu9/SaHTDHLlBXCU62Hx0xWEzBLS8aiOOT4Y02ieA0cUZh2oQftWBFLPq/BnJUMfyepra2WDJs6VQRVNbR6Cl9o7ZTVqE6E3Tjxi3bP34TDlX6ULMdH6epSIhBQv4awKQgJY3GjoqsLrGyESIlGEktyjdx460J+ZXu2kLMqJ3N9AcCvXhFxDeo3I3J9Db9vA2xQuraol6D1/eIedbRQnOMRUYscaxyCCkPDACxuR6/5Jy+FvTz38vnjzT0bnS9mb36RrwYoxC8iR8I6h4C2ujYK+bgWG8pRlIFBQKXr85v0N+7QXqXgtp6TbLu4h7gYG0xbhrWl91QoSmzmRQsRAdpr0UwAEeRcTuuWf1wUwOhQmOSdnzruYguuYs2jvH4U7IDQlcgrP6s8aEdv0CZk3vUQ1VtfFVXY32950122iqz3KtYiv7jbGw9Jo2o2/fzBWj3hC3yrovBHheS8AxgOTodfzyMTo+Ntdm+Cbi1IOW5IyfhIglRWoje8006GqtwEFrjmOmdY/SF2FS18Qd9jVg0oj
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(82310400014)(1800799015)(36860700004)(376005);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Mar 2024 20:36:26.3208
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 7b6746fe-5513-4e38-3ebd-08dc44666bb0
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF00026367.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB6413

On 2024-03-14 09:16, Jan Beulich wrote:
> On 13.03.2024 20:30, Jason Andryuk wrote:
>> @@ -217,6 +225,15 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
>>       case XEN_ELFNOTE_PHYS32_ENTRY:
>>           parms->phys_entry = val;
>>           break;
>> +
>> +    case XEN_ELFNOTE_L1_MFN_VALID:
>> +        if ( elf_uval(elf, note, descsz) != 2 * sizeof(uint64_t) )
>> +            return -1;
> 
> elf_note_numeric() use sites don't have such a check. Why would we need
> one here, and even more so causing a error to be raised when in reality
> the supplied values (still) aren't consumed? Furthermore the documentation
> says "pairs" (plural) for a reason. Finally maddr_t-sized only happens to
> mean uint64_t on all architectures we presently support.

I failed to pay attention to the definition stating plural pairs.  I saw 
Linux stored two 64bit values and printed them.

I added the size check to avoid going out of bounds.  elf_note_numeric() 
handles 1, 2, 4 or 8 bytes and returns 0 otherwise, so it won't overrun 
boundaries.  That's why it was getting printed as "ELF: note: 
L1_MFN_VALID = 0"

What motivated this was seeing "PVH_RELOCATION = 0".  That confusingly 
looks like relocation is disabled.

I'm fine dropping this attempt at printing the L1_MFN_VALID note. 
maddr_t is not defined, and it looks the note values were 32bit in 
non-PAE kernels.  It could just be printed as "ELF: note: L1_MFN_VALID" 
with no details.

Regards,
Jason

>> +        elf_msg(elf, "mask: %#"PRIx64" val: %#"PRIx64"\n",
>> +                elf_note_numeric_array(elf, note, 8, 0),
>> +                elf_note_numeric_array(elf, note, 8, 1));
>> +        break;
>>       }
>>       return 0;
>>   }
> 


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 21:25:03 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 21:25:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693490.1081612 (Exim 4.92)
	(envelope-from )
	id 1rksZF-0007yG-Bw; Thu, 14 Mar 2024 21:24:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693490.1081612; Thu, 14 Mar 2024 21:24:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rksZF-0007y9-9L; Thu, 14 Mar 2024 21:24:49 +0000
Received: by outflank-mailman (input) for mailman id 693490;
 Thu, 14 Mar 2024 21:24:47 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rksZD-0007xz-Pz; Thu, 14 Mar 2024 21:24:47 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rksZD-0001nX-Es; Thu, 14 Mar 2024 21:24:47 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rksZD-0002Fn-7Q; Thu, 14 Mar 2024 21:24:47 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rksZD-0002eB-6p; Thu, 14 Mar 2024 21:24:47 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=O50ke9lRFBW9xcxv/JTq2yr20//2vAuqOoHtpiqEpvE=; b=CNOBNwoGvVlL9t0MzyTEMENn1T
	s/I/irFFWvOloXYe8TNQWTI60rwwgGIPp/GuuL03yU5brH2w+AAuL8jpCn894qOjP748kiywLYl6H
	aw3u5WkWVf4cIFnH231T7drllRqoVGm/sBCbclfo+z+etyrgNqDre+n4ht7OXP2CmZSM=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [ovmf test] 185037: all pass - PUSHED
X-Osstest-Versions-This:
    ovmf=e7486b50646d6a645706b61d2f8d74b3dca23ce0
X-Osstest-Versions-That:
    ovmf=5572b43c6767f7cc46b074ae1fc288f6eccdc65d
From: osstest service owner 
Date: Thu, 14 Mar 2024 21:24:47 +0000

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf                 e7486b50646d6a645706b61d2f8d74b3dca23ce0
baseline version:
 ovmf                 5572b43c6767f7cc46b074ae1fc288f6eccdc65d

Last test of basis   185018  2024-03-13 11:45:09 Z    1 days
Testing same since   185037  2024-03-14 16:41:16 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Ard Biesheuvel 
  Oliver Smith-Denny 

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-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   5572b43c67..e7486b5064  e7486b50646d6a645706b61d2f8d74b3dca23ce0 -> xen-tested-master


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 21:44:24 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 21:44:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693495.1081622 (Exim 4.92)
	(envelope-from )
	id 1rkss6-0002Ld-Ub; Thu, 14 Mar 2024 21:44:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693495.1081622; Thu, 14 Mar 2024 21:44:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkss6-0002LW-Re; Thu, 14 Mar 2024 21:44:18 +0000
Received: by outflank-mailman (input) for mailman id 693495;
 Thu, 14 Mar 2024 21:44:18 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkss5-0002LM-W0; Thu, 14 Mar 2024 21:44:17 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkss5-000275-Pr; Thu, 14 Mar 2024 21:44:17 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkss5-0003aR-HR; Thu, 14 Mar 2024 21:44:17 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rkss5-0004mg-Gi; Thu, 14 Mar 2024 21:44:17 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=4anVEqt7bNbDZ7cwamLfqOTUg5v7kywPhJqrV/RSHPs=; b=UICfpNidzARPLm3CMJP+5hg1Za
	yGPDBFQIJNdX8xfj14/b8+IBOR+6rlinRPCOu69ydvCI2rD+GeWALsEw6Yzi1hnYhA6lC4q4yU/jA
	3dd9MtnXf8RxCo0MFu2Mfik9wrvlfagNdYUHWh92XmOVCYPoIyPqWCCTYtnnbY+I2NI0=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 185041: tolerable all pass - PUSHED
X-Osstest-Failures:
    xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    xen=d638e304f13a5ef7d125de5ace5f7828a7b25bac
X-Osstest-Versions-That:
    xen=77c39a53cf5bfe185b7bff6544c63731513830d3
From: osstest service owner 
Date: Thu, 14 Mar 2024 21:44:17 +0000

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          16 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  d638e304f13a5ef7d125de5ace5f7828a7b25bac
baseline version:
 xen                  77c39a53cf5bfe185b7bff6544c63731513830d3

Last test of basis   185035  2024-03-14 16:05:12 Z    0 days
Testing same since   185041  2024-03-14 19:01:16 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper 
  Julien Grall 

jobs:
 build-arm64-xsm                                              pass    
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-amd64-libvirt                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 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
   77c39a53cf..d638e304f1  d638e304f13a5ef7d125de5ace5f7828a7b25bac -> smoke


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 21:50:34 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 21:50:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693500.1081633 (Exim 4.92)
	(envelope-from )
	id 1rksy5-0003xE-Fj; Thu, 14 Mar 2024 21:50:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693500.1081633; Thu, 14 Mar 2024 21:50:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rksy5-0003x7-D3; Thu, 14 Mar 2024 21:50:29 +0000
Received: by outflank-mailman (input) for mailman id 693500;
 Thu, 14 Mar 2024 21:50:28 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rksy4-0003x1-Pp
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 21:50:28 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id dd87e35d-e24c-11ee-a1ee-f123f15fe8a2;
 Thu, 14 Mar 2024 22:50:26 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 55DA0614FE;
 Thu, 14 Mar 2024 21:50:25 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7750AC433F1;
 Thu, 14 Mar 2024 21:50:23 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: dd87e35d-e24c-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1710453024;
	bh=MgpMG91kr6ccIQgc4f7pyYqg/BDji6TRP7AqFlrewPI=;
	h=Date:From:To:cc:Subject:From;
	b=k/3bivuhbe+q35WO3YG+17un2vlI/2t4nXzluCmmyR2eLIELEsSkh3AX++ar5qheq
	 y1xz5BlbMTfWf7fylPQFkJJoe6CkBR9Nu2ufBtDxumClghMao9/yvopB9AXBt/QmC2
	 KpN+bfeijWlo50Da4GsmZ2Ktho1F7u1zbMmcZrY4RkJJBigc5+WaNOKNGda6h04WfQ
	 J6lY93RZyONZ7V1bx9bDBGZsAjblhCQSgEfoZ7ZBppSy/WYAwmmVWuEJpqLMoRCxVm
	 f6BaSVDjlMyXlFWdQeM7rqJffLkorDW9heHbKLIb0zsB43j5vFpF05VLaDk+Mhy14/
	 IZoo73r+fVSRw==
Date: Thu, 14 Mar 2024 14:50:21 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: xen-devel@lists.xenproject.org
cc: sstabellini@kernel.org, andrew.cooper3@citrix.com, 
    bertrand.marquis@arm.com, george.dunlap@citrix.com, jbeulich@suse.com, 
    julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com
Subject: [PATCH v2] docs/misra: add Rule 16.4
Message-ID: 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII


Signed-off-by: Stefano Stabellini 
---
Changes in v2:
- mention -Werror
- change the position of the in-code comment in the example
- use "notifier pattern" in the example
- clarify it is only an example
---
 docs/misra/rules.rst | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst
index 1e134ccebc..5c84091e45 100644
--- a/docs/misra/rules.rst
+++ b/docs/misra/rules.rst
@@ -478,6 +478,31 @@ maintainers if you want to suggest a change.
      - In addition to break, also other unconditional flow control statements
        such as continue, return, goto are allowed.
 
+   * - `Rule 16.4 `_
+     - Required
+     - Every switch statement shall have a default label
+     - Switch statements with enums as controlling expression don't need
+       a default label as gcc -Wall enables -Wswitch which warns (and
+       breaks the build as we use -Werror) if one of the enum labels is
+       missing from the switch.
+
+       Switch statements with integer types as controlling expression
+       should have a default label:
+
+       - if the switch is expected to handle all possible cases
+         explicitly, then a default label shall be added to handle
+         unexpected error conditions, using BUG(), ASSERT(), WARN(),
+         domain_crash(), or other appropriate methods;
+
+       - if the switch is expected to handle a subset of all possible
+         cases, then an empty default label shall be added with an
+         in-code comment on top of the default label with a reason and
+         when possible a more detailed explanation. Example::
+
+             default:
+                 /* Notifier pattern */
+                 break;
+
    * - `Rule 16.2 `_
      - Required
      - A switch label shall only be used when the most closely-enclosing
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Thu Mar 14 21:54:36 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 21:54:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693502.1081642 (Exim 4.92)
	(envelope-from )
	id 1rkt23-0004Xc-0R; Thu, 14 Mar 2024 21:54:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693502.1081642; Thu, 14 Mar 2024 21:54:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkt22-0004XV-UG; Thu, 14 Mar 2024 21:54:34 +0000
Received: by outflank-mailman (input) for mailman id 693502;
 Thu, 14 Mar 2024 21:54:34 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkt22-0004XP-42
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 21:54:34 +0000
Received: from sin.source.kernel.org (sin.source.kernel.org
 [2604:1380:40e1:4800::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6f5636a4-e24d-11ee-afdd-a90da7624cb6;
 Thu, 14 Mar 2024 22:54:32 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sin.source.kernel.org (Postfix) with ESMTP id 91931CE1E63;
 Thu, 14 Mar 2024 21:54:27 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 66BC1C433C7;
 Thu, 14 Mar 2024 21:54:25 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6f5636a4-e24d-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1710453266;
	bh=KYWOMQ6ABttkyI7aGru1cUWLR2Va7H8yGpFLnOxdBSU=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=KVMDgzVmn8YogsCkB8aKM3tPEHIa2aaa1AdfFcDzab4jAzEZfYaxval2h+rNfb6oA
	 zJ19IDrSpZ8EZVLLwtTXHG4vvK+51Q/0kFgfLlfTwqVJDZT+iwWcn8kVMXLIWq8Izy
	 TCupHTbnpj2sGqJGR0ufd1LZl+pCSlVfnNHgnx/oiI1DcgQn2uXCeDTeD4PBsOTuv7
	 H1hj275WlIR8yZdz9qy4jRDMB/GvjNcT8egGzXL1zhpHNKZXrRAO2E6DeTxS3nwGcT
	 XXxizL0sJNRDljT97jppCcfx0aEEuYU+rRQZNP8QewXvlnE4IMKxy2T20itqG/s/dV
	 MjCbBpJ9RKTSw==
Date: Thu, 14 Mar 2024 14:54:23 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich 
cc: Nicola Vetrini , sstabellini@kernel.org, 
    michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, 
    consulting@bugseng.com, bertrand.marquis@arm.com, julien@xen.org, 
    Andrew Cooper , xen-devel@lists.xenproject.org
Subject: Re: [XEN PATCH] amd/iommu: add fixed size to function parameter of
 array type
In-Reply-To: 
Message-ID: 
References: <533a2d4f0c92d7fe92aa200b64434389de546f69.1710343652.git.nicola.vetrini@bugseng.com> <6186b676-660c-4bfa-a825-18ff7f0d7f62@suse.com> <503aa63b5204e9b9eab5a21235df7c6c@bugseng.com> 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Thu, 14 Mar 2024, Jan Beulich wrote:
> On 14.03.2024 10:25, Nicola Vetrini wrote:
> > On 2024-03-14 09:32, Jan Beulich wrote:
> >> On 14.03.2024 08:42, Nicola Vetrini wrote:
> >>> The 'cmd' parameter of amd_iommu_send_guest_cmd is passed
> >>> to a function that expects arrays of size 4, therefore
> >>> specifying explicitly the size also in amd_iommu_send_guest_cmd
> >>> allows not to accidentally pass a smaller array or assume that
> >>> send_iommu_command handles array sizes >4 correctly.
> >>>
> >>> No functional change.
> >>>
> >>> Signed-off-by: Nicola Vetrini 
> >>> ---
> >>> All current users pass an array of size 4, hence this patch is 
> >>> addressing
> >>> a potential issue noticed by the analyzer in the context of Rule 17.5
> >>> ("The function argument corresponding to a parameter declared to have 
> >>> an array
> >>> type shall have an appropriate number of elements"), not an actual 
> >>> problem in
> >>> the sources.
> >>
> >> While true, I think we want to consider alternatives. First one being 
> >> to rip
> >> out this dead code (thus addressing other Misra concerns as well). 
> >> Second,
> >> if we meant to keep it, to properly do away with the (ab)use of u32[].
> >>
> > 
> > I'm not understanding what you consider dead code.
> 
> iommu_guest.c:guest_iommu_{init,destroy,set_base,add_event_log}() have
> no callers; guest_iommu_add_ppr_log() having one is suspicious, but the
> function will still bail early due to domain_iommu() never returning
> non-NULL in practice. With that I'm pretty sure nothing else in the file
> is actually reachable.

I also prefer removing the code that is not used


> > I see three users of amd_iommu_send_guest_cmd
> 
> All in said file.
> 
> > and seven for send_iommu_command.
> 
> Well, this one of course isn't dead.
> 
> > I can adjust u32 for sure. There are also other u32/uint32_t 
> > incosistencies in that header.
> 
> Which we're going to take care of over time.
> 
> Jan
> 


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 21:58:02 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 21:58:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693506.1081653 (Exim 4.92)
	(envelope-from )
	id 1rkt5J-00056Q-FA; Thu, 14 Mar 2024 21:57:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693506.1081653; Thu, 14 Mar 2024 21:57:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkt5J-00056J-BO; Thu, 14 Mar 2024 21:57:57 +0000
Received: by outflank-mailman (input) for mailman id 693506;
 Thu, 14 Mar 2024 21:57:55 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkt5H-00056D-MS
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 21:57:55 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org
 [2604:1380:4641:c500::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e7e05e18-e24d-11ee-a1ee-f123f15fe8a2;
 Thu, 14 Mar 2024 22:57:53 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 3DD39614FE;
 Thu, 14 Mar 2024 21:57:52 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id B0D33C433C7;
 Thu, 14 Mar 2024 21:57:50 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e7e05e18-e24d-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1710453471;
	bh=1iSKslSc1yjNNdzyH2kxNZp9kY4NxfqAixi70qK2K90=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=CwvWkcvjHp9ZbJOaaf6nbL9sVpKqY694eoBwt/tiCLtDWMrOLGAJmZv9foPvsf2PJ
	 YjVmxS5nHlPUdlAX92ydvhO1uAhxtO2QpKUzQ+ZiDY0RGFT68DKuoA7B1fNajLA0r1
	 hSlXk80WDBbjSDOU5J2W4KzF0m17ZDjVAumxAqKadhof0iZMs5K8RFY3NFaeaddC1z
	 dg5sBP5Eqm4j2i/J+HLDCAnVJ1iyMhrdabkiCgW61Q88PrsnBvs07AODTnh3acJHbd
	 XPtncVYWLRhvs0wLH1/Zsk6fZAs8GWnH0H8ExynCojTwfN93/v7jM7G9ObeGn5BtPw
	 sMkfE/DuN29gg==
Date: Thu, 14 Mar 2024 14:57:49 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: George Dunlap 
cc: Jan Beulich , 
    Stefano Stabellini , andrew.cooper3@citrix.com, 
    bertrand.marquis@arm.com, julien@xen.org, michal.orzel@amd.com, 
    roger.pau@citrix.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH] docs/misra: document the expected sizes of integer
 types
In-Reply-To: 
Message-ID: 
References:  <5bfd2a8e-afa9-4630-ae75-382edc943bc6@suse.com> 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1009727898-1710453471=:853156"

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-1009727898-1710453471=:853156
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Thu, 14 Mar 2024, George Dunlap wrote:
> On Thu, Mar 14, 2024 at 7:36 AM Jan Beulich  wrote:
> >
> > On 14.03.2024 00:23, Stefano Stabellini wrote:
> > > Xen makes assumptions about the size of integer types on the various
> > > architectures. Document these assumptions.
> >
> > This all reads as if we required exact widths. Is that really the case?
> 
> At least one thing here is that *all compilers on the architecture*
> need to have the same idea.  If not, we absolutely need to change
> "unsigned int" to "uint32_t" in any public interface.

Minor NIT to say "all compilers we intend to support on the
architecture". I am sure there are compilers that don't respect these
assumptions out there but we won't support them.


> A second thing is not only assumptions about minimum number of bits,
> but about storage size and alignment.  Again, if we don't assume that
> "unsigned int" is exactly 4 bytes, then we should go through and
> change it to "uint32_t" anywhere that the size or alignment matter.

Yes, exactly.

Actually I forgot to add the alignment information. I'll do that in the
next version of the patch.
--8323329-1009727898-1710453471=:853156--


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 22:16:11 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 22:16:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693510.1081667 (Exim 4.92)
	(envelope-from )
	id 1rktMt-0008KG-6T; Thu, 14 Mar 2024 22:16:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693510.1081667; Thu, 14 Mar 2024 22:16:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rktMt-0008JI-1K; Thu, 14 Mar 2024 22:16:07 +0000
Received: by outflank-mailman (input) for mailman id 693510;
 Thu, 14 Mar 2024 22:16:05 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rktMr-0008HV-Pk
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 22:16:05 +0000
Received: from raptorengineering.com (mail.raptorengineering.com
 [23.155.224.40]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 70a72db8-e250-11ee-afdd-a90da7624cb6;
 Thu, 14 Mar 2024 23:16:01 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
 by mail.rptsys.com (Postfix) with ESMTP id 7F2158286790;
 Thu, 14 Mar 2024 17:16:00 -0500 (CDT)
Received: from mail.rptsys.com ([127.0.0.1])
 by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10032)
 with ESMTP id lUNMd4vATcAF; Thu, 14 Mar 2024 17:15:59 -0500 (CDT)
Received: from localhost (localhost [127.0.0.1])
 by mail.rptsys.com (Postfix) with ESMTP id 7D6408286C9A;
 Thu, 14 Mar 2024 17:15:59 -0500 (CDT)
Received: from mail.rptsys.com ([127.0.0.1])
 by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10026)
 with ESMTP id 3BlC2zDAPcW5; Thu, 14 Mar 2024 17:15:59 -0500 (CDT)
Received: from raptor-ewks-026.lan (5.edge.rptsys.com [23.155.224.38])
 by mail.rptsys.com (Postfix) with ESMTPSA id 2772A8286CAF;
 Thu, 14 Mar 2024 17:15:59 -0500 (CDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 70a72db8-e250-11ee-afdd-a90da7624cb6
DKIM-Filter: OpenDKIM Filter v2.10.3 mail.rptsys.com 7D6408286C9A
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=raptorengineering.com; s=B8E824E6-0BE2-11E6-931D-288C65937AAD;
	t=1710454559; bh=LiAKCYohOpMozP7U6Dsl0j+g+b4qIs2c8DEzGA/uNbQ=;
	h=From:To:Date:Message-Id:MIME-Version;
	b=BXJv/7q3k8aoRXt8CcNdxAo60Mdn4rgHGOGC/TZnxhnwptCitLxly2ReHBqfRbxzM
	 A0oZP7nHS47sPMomAD4+TPUVeEhIBokOCw7yihj9AykjBkZ7w/8RwSnyoDhU5VnCZG
	 KJ4rV4UQWNbfQSPuGAe7ceFijdvP/BEpvL7TwvJ8=
X-Virus-Scanned: amavisd-new at rptsys.com
From: Shawn Anastasio 
To: xen-devel@lists.xenproject.org
Cc: tpearson@raptorengineering.com,
	Jan Beulich ,
	Shawn Anastasio 
Subject: [PATCH v3 4/9] xen/ppc: Update setup.h with required definitions for bootfdt
Date: Thu, 14 Mar 2024 17:15:42 -0500
Message-Id: <2c14419bd9fbd5307fe4d5b079a9927e4d3ec9fc.1710443965.git.sanastasio@raptorengineering.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

Add the definitions used by ARM's bootfdt.c, which will be moved into
xen/common in a later patch, to PPC's setup.h.

Signed-off-by: Shawn Anastasio 
---
 xen/arch/ppc/include/asm/setup.h | 112 +++++++++++++++++++++++++++++++
 1 file changed, 112 insertions(+)

diff --git a/xen/arch/ppc/include/asm/setup.h b/xen/arch/ppc/include/asm/setup.h
index e4f64879b6..1b2d29c5b6 100644
--- a/xen/arch/ppc/include/asm/setup.h
+++ b/xen/arch/ppc/include/asm/setup.h
@@ -3,4 +3,116 @@
 
 #define max_init_domid (0)
 
+#include 
+#include 
+#include 
+
+#define MIN_FDT_ALIGN 8
+#define MAX_FDT_SIZE SZ_2M
+
+#define NR_MEM_BANKS 256
+
+#define MAX_MODULES 32 /* Current maximum useful modules */
+
+typedef enum {
+    BOOTMOD_XEN,
+    BOOTMOD_FDT,
+    BOOTMOD_KERNEL,
+    BOOTMOD_RAMDISK,
+    BOOTMOD_XSM,
+    BOOTMOD_GUEST_DTB,
+    BOOTMOD_UNKNOWN
+}  bootmodule_kind;
+
+enum membank_type {
+    /*
+     * The MEMBANK_DEFAULT type refers to either reserved memory for the
+     * device/firmware (when the bank is in 'reserved_mem') or any RAM (when
+     * the bank is in 'mem').
+     */
+    MEMBANK_DEFAULT,
+    /*
+     * The MEMBANK_STATIC_DOMAIN type is used to indicate whether the memory
+     * bank is bound to a static Xen domain. It is only valid when the bank
+     * is in reserved_mem.
+     */
+    MEMBANK_STATIC_DOMAIN,
+    /*
+     * The MEMBANK_STATIC_HEAP type is used to indicate whether the memory
+     * bank is reserved as static heap. It is only valid when the bank is
+     * in reserved_mem.
+     */
+    MEMBANK_STATIC_HEAP,
+};
+
+/* Indicates the maximum number of characters(\0 included) for shm_id */
+#define MAX_SHM_ID_LENGTH 16
+
+struct membank {
+    paddr_t start;
+    paddr_t size;
+    enum membank_type type;
+};
+
+struct meminfo {
+    unsigned int nr_banks;
+    struct membank bank[NR_MEM_BANKS];
+};
+
+/*
+ * The domU flag is set for kernels and ramdisks of "xen,domain" nodes.
+ * The purpose of the domU flag is to avoid getting confused in
+ * kernel_probe, where we try to guess which is the dom0 kernel and
+ * initrd to be compatible with all versions of the multiboot spec.
+ */
+#define BOOTMOD_MAX_CMDLINE 1024
+struct bootmodule {
+    bootmodule_kind kind;
+    bool domU;
+    paddr_t start;
+    paddr_t size;
+};
+
+/* DT_MAX_NAME is the node name max length according the DT spec */
+#define DT_MAX_NAME 41
+struct bootcmdline {
+    bootmodule_kind kind;
+    bool domU;
+    paddr_t start;
+    char dt_name[DT_MAX_NAME];
+    char cmdline[BOOTMOD_MAX_CMDLINE];
+};
+
+struct bootmodules {
+    int nr_mods;
+    struct bootmodule module[MAX_MODULES];
+};
+
+struct bootcmdlines {
+    unsigned int nr_mods;
+    struct bootcmdline cmdline[MAX_MODULES];
+};
+
+struct bootinfo {
+    struct meminfo mem;
+    struct meminfo reserved_mem;
+    struct bootmodules modules;
+    struct bootcmdlines cmdlines;
+    bool static_heap;
+};
+
+extern struct bootinfo bootinfo;
+
+/*
+ * bootinfo.c
+ */
+bool check_reserved_regions_overlap(paddr_t region_start, paddr_t region_size);
+struct bootmodule *add_boot_module(bootmodule_kind kind,
+                                   paddr_t start, paddr_t size, bool domU);
+void add_boot_cmdline(const char *name, const char *cmdline,
+                      bootmodule_kind kind, paddr_t start, bool domU);
+const char *boot_module_kind_as_string(bootmodule_kind kind);
+struct bootcmdline *boot_cmdline_find_by_kind(bootmodule_kind kind);
+void populate_boot_allocator(void);
+
 #endif /* __ASM_PPC_SETUP_H__ */
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu Mar 14 22:16:11 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 22:16:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693509.1081662 (Exim 4.92)
	(envelope-from )
	id 1rktMs-0008Hr-TR; Thu, 14 Mar 2024 22:16:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693509.1081662; Thu, 14 Mar 2024 22:16:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rktMs-0008Hg-QA; Thu, 14 Mar 2024 22:16:06 +0000
Received: by outflank-mailman (input) for mailman id 693509;
 Thu, 14 Mar 2024 22:16:05 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rktMr-0008HV-3u
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 22:16:05 +0000
Received: from raptorengineering.com (mail.raptorengineering.com
 [23.155.224.40]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6fc0704c-e250-11ee-afdd-a90da7624cb6;
 Thu, 14 Mar 2024 23:16:00 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
 by mail.rptsys.com (Postfix) with ESMTP id E15F68286C24;
 Thu, 14 Mar 2024 17:15:58 -0500 (CDT)
Received: from mail.rptsys.com ([127.0.0.1])
 by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10032)
 with ESMTP id ec4yAnXXj4Sk; Thu, 14 Mar 2024 17:15:58 -0500 (CDT)
Received: from localhost (localhost [127.0.0.1])
 by mail.rptsys.com (Postfix) with ESMTP id 02A278285446;
 Thu, 14 Mar 2024 17:15:57 -0500 (CDT)
Received: from mail.rptsys.com ([127.0.0.1])
 by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10026)
 with ESMTP id TxU3LaOiDISN; Thu, 14 Mar 2024 17:15:57 -0500 (CDT)
Received: from raptor-ewks-026.lan (5.edge.rptsys.com [23.155.224.38])
 by mail.rptsys.com (Postfix) with ESMTPSA id 479598284FCB;
 Thu, 14 Mar 2024 17:15:57 -0500 (CDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6fc0704c-e250-11ee-afdd-a90da7624cb6
DKIM-Filter: OpenDKIM Filter v2.10.3 mail.rptsys.com 02A278285446
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=raptorengineering.com; s=B8E824E6-0BE2-11E6-931D-288C65937AAD;
	t=1710454558; bh=jBHUJFudAp3cUjQTNlDpg9GPx5Id51bFuggbdPz/eRA=;
	h=From:To:Date:Message-Id:MIME-Version;
	b=YDIo8zc2hRQ/xrFqRS3dXWvO/o+Vo63zJNk4xpEoRrey0blLln10gObYnAExqxcTq
	 z3Ps39ffj0NqacW1K4yfYlE0rl4A9Vi5hzwZTMfJbTMvENZT1INZ73BpDHu2/c9kA7
	 j+afXAtyGvPKrdOdQBQ+DOQd+iIwECem1bTUg2x4=
X-Virus-Scanned: amavisd-new at rptsys.com
From: Shawn Anastasio 
To: xen-devel@lists.xenproject.org
Cc: tpearson@raptorengineering.com,
	Jan Beulich ,
	Shawn Anastasio ,
	Andrew Cooper ,
	George Dunlap ,
	Julien Grall ,
	Stefano Stabellini ,
	Wei Liu ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	"Daniel P. Smith" 
Subject: [PATCH v3 0/9] Early Boot Allocation on Power
Date: Thu, 14 Mar 2024 17:15:38 -0500
Message-Id: 
X-Mailer: git-send-email 2.30.2
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

Hello all,

This series enables the Xen boot time allocator on Power by parsing
the available memory regions from the firmware-provided device tree.

Version 3 of the patch set greatly reduces the amount of code copied
from ARM, instead opting to move things into common code where possible.

Thanks,
Shawn

Shawn Anastasio (9):
  EFI: Introduce inline stub for efi_enabled on !X86 && !ARM
  xen/asm-generic: Introduce generic acpi.h
  xen/ppc: Introduce stub asm/static-shmem.h
  xen/ppc: Update setup.h with required definitions for bootfdt
  xen/device-tree: Move Arm's setup.c bootinfo functions to common
  xen/common: Move Arm's bootfdt.c to common
  xen/ppc: Enable bootfdt and boot allocator
  xen/ppc: mm-radix: Replace debug printing code with printk
  xen/ppc: mm-radix: Allocate all paging structures at runtime

 MAINTAINERS                                   |   2 +
 xen/arch/arm/Makefile                         |   1 -
 xen/arch/arm/setup.c                          | 419 ----------------
 xen/arch/ppc/include/asm/Makefile             |   1 +
 xen/arch/ppc/include/asm/setup.h              | 117 +++++
 xen/arch/ppc/include/asm/static-shmem.h       |  12 +
 xen/arch/ppc/mm-radix.c                       | 263 +++++-----
 xen/arch/ppc/setup.c                          |  21 +-
 xen/common/Makefile                           |   1 +
 xen/common/device-tree/Makefile               |   2 +
 .../arm => common/device-tree}/bootfdt.c      |  11 +-
 xen/common/device-tree/bootinfo.c             | 469 ++++++++++++++++++
 xen/include/asm-generic/acpi.h                |  20 +
 xen/include/xen/efi.h                         |   8 +
 14 files changed, 781 insertions(+), 566 deletions(-)
 create mode 100644 xen/arch/ppc/include/asm/static-shmem.h
 create mode 100644 xen/common/device-tree/Makefile
 rename xen/{arch/arm => common/device-tree}/bootfdt.c (97%)
 create mode 100644 xen/common/device-tree/bootinfo.c
 create mode 100644 xen/include/asm-generic/acpi.h

--
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu Mar 14 22:16:11 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 22:16:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693512.1081693 (Exim 4.92)
	(envelope-from )
	id 1rktMu-0000YZ-UB; Thu, 14 Mar 2024 22:16:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693512.1081693; Thu, 14 Mar 2024 22:16:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rktMu-0000YS-QR; Thu, 14 Mar 2024 22:16:08 +0000
Received: by outflank-mailman (input) for mailman id 693512;
 Thu, 14 Mar 2024 22:16:07 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rktMt-0008HV-QM
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 22:16:07 +0000
Received: from raptorengineering.com (mail.raptorengineering.com
 [23.155.224.40]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 73c560cc-e250-11ee-afdd-a90da7624cb6;
 Thu, 14 Mar 2024 23:16:06 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
 by mail.rptsys.com (Postfix) with ESMTP id D4A238286CAE;
 Thu, 14 Mar 2024 17:16:02 -0500 (CDT)
Received: from mail.rptsys.com ([127.0.0.1])
 by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10032)
 with ESMTP id fRK23-8nHYBk; Thu, 14 Mar 2024 17:16:01 -0500 (CDT)
Received: from localhost (localhost [127.0.0.1])
 by mail.rptsys.com (Postfix) with ESMTP id CE62282856F3;
 Thu, 14 Mar 2024 17:16:01 -0500 (CDT)
Received: from mail.rptsys.com ([127.0.0.1])
 by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10026)
 with ESMTP id hpv1Dl9dC7ym; Thu, 14 Mar 2024 17:16:01 -0500 (CDT)
Received: from raptor-ewks-026.lan (5.edge.rptsys.com [23.155.224.38])
 by mail.rptsys.com (Postfix) with ESMTPSA id 7BFCD8286CF5;
 Thu, 14 Mar 2024 17:16:01 -0500 (CDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 73c560cc-e250-11ee-afdd-a90da7624cb6
DKIM-Filter: OpenDKIM Filter v2.10.3 mail.rptsys.com CE62282856F3
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=raptorengineering.com; s=B8E824E6-0BE2-11E6-931D-288C65937AAD;
	t=1710454561; bh=50skhtpwMDcPgIfs73jJDeuj0sPH24wFUgn3url2ebE=;
	h=From:To:Date:Message-Id:MIME-Version;
	b=HegyX1oSVMwtUNjRNeC/Ndr2pHrhOiPCBnaXSqIkETPn5Ga0mSU6IEE1xA7AhONlP
	 RT5JniJbhoE0iqXpRxTZ7+lSqz5wCd7g0sHj0QHgg443v7rkiRHHvknPMFzNkds1A3
	 F0dD1d7C1/WQetnGLLjF08gB+VDatfCIpf67ixPc=
X-Virus-Scanned: amavisd-new at rptsys.com
From: Shawn Anastasio 
To: xen-devel@lists.xenproject.org
Cc: tpearson@raptorengineering.com,
	Jan Beulich ,
	Shawn Anastasio 
Subject: [PATCH v3 9/9] xen/ppc: mm-radix: Allocate all paging structures at runtime
Date: Thu, 14 Mar 2024 17:15:47 -0500
Message-Id: <00f22a6a08451614179219fd430539fbb1e6e8cf.1710443965.git.sanastasio@raptorengineering.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

In the initial mm-radix implementation, the in-memory partition and
process tables required to configure the MMU, as well as the page tables
themselves were all allocated statically since the boot allocator was
not yet available.

Now that it is, allocate these structures at runtime and bump the size
of the Process Table to its maximum supported value (on POWER9).

Signed-off-by: Shawn Anastasio 
---
Changes in v2:
  - Drop all static allocation and use boot allocator for page tables
    too

 xen/arch/ppc/mm-radix.c | 227 +++++++++++++++++++++-------------------
 1 file changed, 119 insertions(+), 108 deletions(-)

diff --git a/xen/arch/ppc/mm-radix.c b/xen/arch/ppc/mm-radix.c
index ab5a10695c..edae41e0be 100644
--- a/xen/arch/ppc/mm-radix.c
+++ b/xen/arch/ppc/mm-radix.c
@@ -21,69 +21,101 @@ void enable_mmu(void);
 #define radix_dprintk(...)
 #endif

-#define INITIAL_LVL1_PD_COUNT      1
-#define INITIAL_LVL2_LVL3_PD_COUNT 2
-#define INITIAL_LVL4_PT_COUNT      256
-
-static size_t __initdata initial_lvl1_pd_pool_used;
-static struct lvl1_pd initial_lvl1_pd_pool[INITIAL_LVL1_PD_COUNT];
-
-static size_t __initdata initial_lvl2_lvl3_pd_pool_used;
-static struct lvl2_pd initial_lvl2_lvl3_pd_pool[INITIAL_LVL2_LVL3_PD_COUNT];
-
-static size_t __initdata initial_lvl4_pt_pool_used;
-static struct lvl4_pt initial_lvl4_pt_pool[INITIAL_LVL4_PT_COUNT];
-
-/* Only reserve minimum Partition and Process tables  */
 #define PATB_SIZE_LOG2 16 /* Only supported partition table size on POWER9 */
 #define PATB_SIZE      (1UL << PATB_SIZE_LOG2)
-#define PRTB_SIZE_LOG2 12
+#define PRTB_SIZE_LOG2 24 /* Maximum process table size on POWER9 */
 #define PRTB_SIZE      (1UL << PRTB_SIZE_LOG2)

-static struct patb_entry
-    __aligned(PATB_SIZE) initial_patb[PATB_SIZE / sizeof(struct patb_entry)];
+static struct patb_entry *initial_patb;
+static struct prtb_entry *initial_prtb;

-static struct prtb_entry
-    __aligned(PRTB_SIZE) initial_prtb[PRTB_SIZE / sizeof(struct prtb_entry)];
+static mfn_t __initdata min_alloc_mfn = {-1};
+static mfn_t __initdata max_alloc_mfn = {0};

-static __init struct lvl1_pd *lvl1_pd_pool_alloc(void)
+/*
+ * A thin wrapper for alloc_boot_pages that keeps track of the maximum and
+ * minimum mfns that have been allocated. This information is used by
+ * setup_initial_mapping to include the allocated pages in the initial
+ * page mapping.
+ */
+static mfn_t __init initial_page_alloc(unsigned long nr_pfns,
+                                       unsigned long pfn_align)
 {
-    if ( initial_lvl1_pd_pool_used >= INITIAL_LVL1_PD_COUNT )
-    {
-        early_printk("Ran out of space for LVL1 PD!\n");
-        die();
-    }
+    mfn_t mfn_first, mfn_last;

-    return &initial_lvl1_pd_pool[initial_lvl1_pd_pool_used++];
-}
+    mfn_first = alloc_boot_pages(nr_pfns, pfn_align);
+    mfn_last = _mfn(mfn_x(mfn_first) + nr_pfns - 1);

-static __init struct lvl2_pd *lvl2_pd_pool_alloc(void)
-{
-    if ( initial_lvl2_lvl3_pd_pool_used >= INITIAL_LVL2_LVL3_PD_COUNT )
-    {
-        early_printk("Ran out of space for LVL2/3 PD!\n");
-        die();
-    }
+    min_alloc_mfn = _mfn(min(mfn_x(min_alloc_mfn), mfn_x(mfn_first)));
+    max_alloc_mfn = _mfn(max(mfn_x(max_alloc_mfn), mfn_x(mfn_last)));

-    return &initial_lvl2_lvl3_pd_pool[initial_lvl2_lvl3_pd_pool_used++];
+    return mfn_first;
 }

-static __init struct lvl3_pd *lvl3_pd_pool_alloc(void)
+static __init void *initial_pd_pt_alloc(void)
 {
-    BUILD_BUG_ON(sizeof(struct lvl3_pd) != sizeof(struct lvl2_pd));
+    BUILD_BUG_ON(sizeof(struct lvl1_pd) > PAGE_SIZE);
+    BUILD_BUG_ON(sizeof(struct lvl2_pd) > PAGE_SIZE);
+    BUILD_BUG_ON(sizeof(struct lvl3_pd) > PAGE_SIZE);
+    BUILD_BUG_ON(sizeof(struct lvl4_pt) > PAGE_SIZE);

-    return (struct lvl3_pd *) lvl2_pd_pool_alloc();
+    return __va(mfn_to_maddr(initial_page_alloc(1, 1)));
 }

-static __init struct lvl4_pt *lvl4_pt_pool_alloc(void)
+static void map_page_initial(struct lvl1_pd *lvl1, vaddr_t virt, paddr_t phys,
+                             unsigned long flags)
 {
-    if ( initial_lvl4_pt_pool_used >= INITIAL_LVL4_PT_COUNT )
+    struct lvl2_pd *lvl2;
+    struct lvl3_pd *lvl3;
+    struct lvl4_pt *lvl4;
+    pde_t *pde;
+    pte_t *pte;
+
+    /* Allocate LVL 2 PD if necessary */
+    pde = pt_entry(lvl1, virt);
+    if ( !pde_is_valid(*pde) )
     {
-        early_printk("Ran out of space for LVL4 PT!\n");
-        die();
+        lvl2 = initial_pd_pt_alloc();
+        *pde = paddr_to_pde(__pa(lvl2), PDE_VALID,
+                            XEN_PT_ENTRIES_LOG2_LVL_2);
+    }
+    else
+        lvl2 = __va(pde_to_paddr(*pde));
+
+    /* Allocate LVL 3 PD if necessary */
+    pde = pt_entry(lvl2, virt);
+    if ( !pde_is_valid(*pde) )
+    {
+        lvl3 = initial_pd_pt_alloc();
+        *pde = paddr_to_pde(__pa(lvl3), PDE_VALID,
+                            XEN_PT_ENTRIES_LOG2_LVL_3);
+    }
+    else
+        lvl3 = __va(pde_to_paddr(*pde));
+
+    /* Allocate LVL 4 PT if necessary */
+    pde = pt_entry(lvl3, virt);
+    if ( !pde_is_valid(*pde) )
+    {
+        lvl4 = initial_pd_pt_alloc();
+        *pde = paddr_to_pde(__pa(lvl4), PDE_VALID,
+                            XEN_PT_ENTRIES_LOG2_LVL_4);
     }
+    else
+        lvl4 = __va(pde_to_paddr(*pde));

-    return &initial_lvl4_pt_pool[initial_lvl4_pt_pool_used++];
+    /* Finally, create PTE in LVL 4 PT */
+    pte = pt_entry(lvl4, virt);
+    if ( !pte_is_valid(*pte) )
+    {
+        radix_dprintk("%016lx being mapped to %016lx\n", phys, virt);
+        *pte = paddr_to_pte(phys, flags);
+    }
+    else
+    {
+        early_printk("BUG: Tried to create PTE for already-mapped page!");
+        die();
+    }
 }

 static void __init setup_initial_mapping(struct lvl1_pd *lvl1,
@@ -92,6 +124,7 @@ static void __init setup_initial_mapping(struct lvl1_pd *lvl1,
                                          paddr_t phys_base)
 {
     uint64_t page_addr;
+    mfn_t previous_max_alloc_mfn;

     if ( map_start & ~PAGE_MASK )
     {
@@ -105,81 +138,47 @@ static void __init setup_initial_mapping(struct lvl1_pd *lvl1,
         die();
     }

+    /* Identity map Xen itself */
     for ( page_addr = map_start; page_addr < map_end; page_addr += PAGE_SIZE )
     {
-        struct lvl2_pd *lvl2;
-        struct lvl3_pd *lvl3;
-        struct lvl4_pt *lvl4;
-        pde_t *pde;
-        pte_t *pte;
-
-        /* Allocate LVL 2 PD if necessary */
-        pde = pt_entry(lvl1, page_addr);
-        if ( !pde_is_valid(*pde) )
-        {
-            lvl2 = lvl2_pd_pool_alloc();
-            *pde = paddr_to_pde(__pa(lvl2), PDE_VALID,
-                                XEN_PT_ENTRIES_LOG2_LVL_2);
-        }
-        else
-            lvl2 = __va(pde_to_paddr(*pde));
+        unsigned long flags;

-        /* Allocate LVL 3 PD if necessary */
-        pde = pt_entry(lvl2, page_addr);
-        if ( !pde_is_valid(*pde) )
+        if ( is_kernel_text(page_addr) || is_kernel_inittext(page_addr) )
         {
-            lvl3 = lvl3_pd_pool_alloc();
-            *pde = paddr_to_pde(__pa(lvl3), PDE_VALID,
-                                XEN_PT_ENTRIES_LOG2_LVL_3);
+            radix_dprintk("%016lx being marked as TEXT (RX)\n", page_addr);
+            flags = PTE_XEN_RX;
         }
-        else
-            lvl3 = __va(pde_to_paddr(*pde));
-
-        /* Allocate LVL 4 PT if necessary */
-        pde = pt_entry(lvl3, page_addr);
-        if ( !pde_is_valid(*pde) )
+        else if ( is_kernel_rodata(page_addr) )
         {
-            lvl4 = lvl4_pt_pool_alloc();
-            *pde = paddr_to_pde(__pa(lvl4), PDE_VALID,
-                                XEN_PT_ENTRIES_LOG2_LVL_4);
+            radix_dprintk("%016lx being marked as RODATA (RO)\n", page_addr);
+            flags = PTE_XEN_RO;
         }
         else
-            lvl4 = __va(pde_to_paddr(*pde));
-
-        /* Finally, create PTE in LVL 4 PT */
-        pte = pt_entry(lvl4, page_addr);
-        if ( !pte_is_valid(*pte) )
         {
-            unsigned long paddr = (page_addr - map_start) + phys_base;
-            unsigned long flags;
-
-            radix_dprintk("%016lx being mapped to %016lx\n", paddr, page_addr);
-            if ( is_kernel_text(page_addr) || is_kernel_inittext(page_addr) )
-            {
-                radix_dprintk("%016lx being marked as TEXT (RX)\n", page_addr);
-                flags = PTE_XEN_RX;
-            }
-            else if ( is_kernel_rodata(page_addr) )
-            {
-                radix_dprintk("%016lx being marked as RODATA (RO)\n", page_addr);
-                flags = PTE_XEN_RO;
-            }
-            else
-            {
-                radix_dprintk("%016lx being marked as DEFAULT (RW)\n", page_addr);
-                flags = PTE_XEN_RW;
-            }
-
-            *pte = paddr_to_pte(paddr, flags);
-            radix_dprintk("%016lx is the result of PTE map\n",
-                paddr_to_pte(paddr, flags).pte);
-        }
-        else
-        {
-            early_printk("BUG: Tried to create PTE for already-mapped page!");
-            die();
+            radix_dprintk("%016lx being marked as DEFAULT (RW)\n", page_addr);
+            flags = PTE_XEN_RW;
         }
+
+        map_page_initial(lvl1, page_addr, (page_addr - map_start) + phys_base, flags);
+    }
+
+    previous_max_alloc_mfn = max_alloc_mfn;
+
+    /*
+     * Identity map all pages we've allocated for paging structures. This act
+     * itself will allocate more pages, so continue until we've mapped from
+     * `max_alloc_mfn` down to `min_alloc_mfn`. This assumes that the heap grows
+     * downwards, which matches the behavior of alloc_boot_pages.
+     */
+    for ( page_addr = (vaddr_t)__va(mfn_to_maddr(max_alloc_mfn));
+          mfn_to_maddr(min_alloc_mfn) <= __pa(page_addr);
+          page_addr -= PAGE_SIZE)
+    {
+        map_page_initial(lvl1, page_addr, __pa(page_addr), PTE_XEN_RW);
     }
+
+    if ( mfn_x(previous_max_alloc_mfn) != mfn_x(max_alloc_mfn) )
+        panic("Early page heap unexpectedly grew upwards\n");
 }

 static void __init setup_partition_table(struct lvl1_pd *root)
@@ -208,9 +207,21 @@ static void __init setup_process_table(struct lvl1_pd *root)

 void __init setup_initial_pagetables(void)
 {
-    struct lvl1_pd *root = lvl1_pd_pool_alloc();
+    struct lvl1_pd *root;
     unsigned long lpcr;
+    mfn_t patb_mfn, prtb_mfn;
+
+    /* Allocate mfns for in-memory tables using the boot allocator */
+    prtb_mfn = initial_page_alloc(PRTB_SIZE / PAGE_SIZE,
+                                  1 << (PRTB_SIZE_LOG2 - PAGE_SHIFT));
+    patb_mfn = initial_page_alloc(PATB_SIZE / PAGE_SIZE,
+                                  1 << (PATB_SIZE_LOG2 - PAGE_SHIFT));
+
+    initial_patb = __va(mfn_to_maddr(patb_mfn));
+    initial_prtb = __va(mfn_to_maddr(prtb_mfn));

+    /* Allocate and create page tables */
+    root = initial_pd_pt_alloc();
     setup_initial_mapping(root, (vaddr_t)_start, (vaddr_t)_end, __pa(_start));

     /* Enable Radix mode in LPCR */
--
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu Mar 14 22:16:11 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 22:16:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693511.1081676 (Exim 4.92)
	(envelope-from )
	id 1rktMt-0008WI-Kw; Thu, 14 Mar 2024 22:16:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693511.1081676; Thu, 14 Mar 2024 22:16:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rktMt-0008UV-Gf; Thu, 14 Mar 2024 22:16:07 +0000
Received: by outflank-mailman (input) for mailman id 693511;
 Thu, 14 Mar 2024 22:16:06 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rktMs-0008HV-Q3
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 22:16:06 +0000
Received: from raptorengineering.com (mail.raptorengineering.com
 [23.155.224.40]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 72dc1d32-e250-11ee-afdd-a90da7624cb6;
 Thu, 14 Mar 2024 23:16:05 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
 by mail.rptsys.com (Postfix) with ESMTP id F1101828673E;
 Thu, 14 Mar 2024 17:16:01 -0500 (CDT)
Received: from mail.rptsys.com ([127.0.0.1])
 by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10032)
 with ESMTP id PsppJZOTuu59; Thu, 14 Mar 2024 17:16:01 -0500 (CDT)
Received: from localhost (localhost [127.0.0.1])
 by mail.rptsys.com (Postfix) with ESMTP id 3AF578286A4B;
 Thu, 14 Mar 2024 17:16:01 -0500 (CDT)
Received: from mail.rptsys.com ([127.0.0.1])
 by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10026)
 with ESMTP id tgjB4xl8g7Ku; Thu, 14 Mar 2024 17:16:01 -0500 (CDT)
Received: from raptor-ewks-026.lan (5.edge.rptsys.com [23.155.224.38])
 by mail.rptsys.com (Postfix) with ESMTPSA id BA7988286CDC;
 Thu, 14 Mar 2024 17:16:00 -0500 (CDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 72dc1d32-e250-11ee-afdd-a90da7624cb6
DKIM-Filter: OpenDKIM Filter v2.10.3 mail.rptsys.com 3AF578286A4B
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=raptorengineering.com; s=B8E824E6-0BE2-11E6-931D-288C65937AAD;
	t=1710454561; bh=ImWiIfCHbaewHCZffKSjHa8JvgXFPUKjK9FnpBwpojM=;
	h=From:To:Date:Message-Id:MIME-Version;
	b=gaVilxusz+uoUP3SZd87R5ePrtO3uSDmeGW6+2ItIMFg5fe9LIdtDsfPPX29ELf36
	 jezQawQXoEsi4jiOmdrPxkZlJJrcUpBs2BMjIamka1RRn0gmW4mv5+HaT+KdoHkFFP
	 NQY7f8pC6SCN2L+EhqCCqpNs6dimIFGQjmE0YEtY=
X-Virus-Scanned: amavisd-new at rptsys.com
From: Shawn Anastasio 
To: xen-devel@lists.xenproject.org
Cc: tpearson@raptorengineering.com,
	Jan Beulich ,
	Shawn Anastasio ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk 
Subject: [PATCH v3 7/9] xen/ppc: Enable bootfdt and boot allocator
Date: Thu, 14 Mar 2024 17:15:45 -0500
Message-Id: 
X-Mailer: git-send-email 2.30.2
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

Enable usage of bootfdt for populating the boot info struct from the
firmware-provided device tree.  Also enable the Xen boot page allocator.

Includes minor changes to bootfdt.c's boot_fdt_info() to tolerate the
scenario in which the FDT overlaps a reserved memory region, as is the
case on PPC when booted directly from skiboot.

Signed-off-by: Shawn Anastasio 
---
 xen/arch/ppc/include/asm/setup.h |  5 +++++
 xen/arch/ppc/setup.c             | 21 ++++++++++++++++++++-
 xen/common/device-tree/bootfdt.c | 11 +++++++++--
 3 files changed, 34 insertions(+), 3 deletions(-)

diff --git a/xen/arch/ppc/include/asm/setup.h b/xen/arch/ppc/include/asm/setup.h
index 1b2d29c5b6..fe27f61fc3 100644
--- a/xen/arch/ppc/include/asm/setup.h
+++ b/xen/arch/ppc/include/asm/setup.h
@@ -115,4 +115,9 @@ const char *boot_module_kind_as_string(bootmodule_kind kind);
 struct bootcmdline *boot_cmdline_find_by_kind(bootmodule_kind kind);
 void populate_boot_allocator(void);
 
+/*
+ * bootfdt.c
+ */
+size_t boot_fdt_info(const void *fdt, paddr_t paddr);
+
 #endif /* __ASM_PPC_SETUP_H__ */
diff --git a/xen/arch/ppc/setup.c b/xen/arch/ppc/setup.c
index 101bdd8bb6..946167a56f 100644
--- a/xen/arch/ppc/setup.c
+++ b/xen/arch/ppc/setup.c
@@ -1,12 +1,14 @@
 /* SPDX-License-Identifier: GPL-2.0-or-later */
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 /* Xen stack for bringing up the first CPU. */
 unsigned char __initdata cpu0_boot_stack[STACK_SIZE] __aligned(STACK_SIZE);
@@ -24,6 +26,9 @@ void __init noreturn start_xen(unsigned long r3, unsigned long r4,
                                unsigned long r5, unsigned long r6,
                                unsigned long r7)
 {
+    void *boot_fdt;
+    struct bootmodule *xen_bootmodule;
+
     if ( r5 )
     {
         /* Unsupported OpenFirmware boot protocol */
@@ -32,11 +37,25 @@ void __init noreturn start_xen(unsigned long r3, unsigned long r4,
     else
     {
         /* kexec boot protocol */
-        boot_opal_init((void *)r3);
+        boot_fdt = (void *)r3;
+        boot_opal_init(boot_fdt);
     }
 
     setup_exceptions();
 
+    device_tree_flattened = boot_fdt;
+    boot_fdt_info(boot_fdt, r3);
+
+    /*
+     * Xen relocates itself at the ppc64 entrypoint, so we need to manually mark
+     * the kernel module.
+     */
+    xen_bootmodule = add_boot_module(BOOTMOD_XEN, __pa(_start),
+                                     PAGE_ALIGN(__pa(_end)), false);
+    BUG_ON(!xen_bootmodule);
+
+    populate_boot_allocator();
+
     setup_initial_pagetables();
 
     early_printk("Hello, ppc64le!\n");
diff --git a/xen/common/device-tree/bootfdt.c b/xen/common/device-tree/bootfdt.c
index 35dbdf3384..1985648b31 100644
--- a/xen/common/device-tree/bootfdt.c
+++ b/xen/common/device-tree/bootfdt.c
@@ -543,12 +543,19 @@ size_t __init boot_fdt_info(const void *fdt, paddr_t paddr)
     if ( ret < 0 )
         panic("No valid device tree\n");
 
-    add_boot_module(BOOTMOD_FDT, paddr, fdt_totalsize(fdt), false);
-
     ret = device_tree_for_each_node(fdt, 0, early_scan_node, NULL);
     if ( ret )
         panic("Early FDT parsing failed (%d)\n", ret);
 
+    /*
+     * Add module for the FDT itself after the device tree has been parsed. This
+     * is required on ppc64le where the device tree passed to Xen may have been
+     * allocated by skiboot, in which case it will exist within a reserved
+     * region and this call will fail. This is fine, however, since either way
+     * the allocator will know not to step on the device tree.
+     */
+    add_boot_module(BOOTMOD_FDT, paddr, fdt_totalsize(fdt), false);
+
     /*
      * On Arm64 setup_directmap_mappings() expects to be called with the lowest
      * bank in memory first. There is no requirement that the DT will provide
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu Mar 14 22:16:11 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 22:16:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693513.1081703 (Exim 4.92)
	(envelope-from )
	id 1rktMx-0000pe-4k; Thu, 14 Mar 2024 22:16:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693513.1081703; Thu, 14 Mar 2024 22:16:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rktMx-0000pV-1L; Thu, 14 Mar 2024 22:16:11 +0000
Received: by outflank-mailman (input) for mailman id 693513;
 Thu, 14 Mar 2024 22:16:09 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rktMv-0000X2-2B
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 22:16:09 +0000
Received: from raptorengineering.com (mail.raptorengineering.com
 [23.155.224.40]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6fbee253-e250-11ee-a1ee-f123f15fe8a2;
 Thu, 14 Mar 2024 23:16:00 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
 by mail.rptsys.com (Postfix) with ESMTP id 1B23E8285446;
 Thu, 14 Mar 2024 17:15:59 -0500 (CDT)
Received: from mail.rptsys.com ([127.0.0.1])
 by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10032)
 with ESMTP id 5HM8izUN8lnN; Thu, 14 Mar 2024 17:15:58 -0500 (CDT)
Received: from localhost (localhost [127.0.0.1])
 by mail.rptsys.com (Postfix) with ESMTP id 5C43A828673E;
 Thu, 14 Mar 2024 17:15:58 -0500 (CDT)
Received: from mail.rptsys.com ([127.0.0.1])
 by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10026)
 with ESMTP id OKrLz0-b-UO0; Thu, 14 Mar 2024 17:15:58 -0500 (CDT)
Received: from raptor-ewks-026.lan (5.edge.rptsys.com [23.155.224.38])
 by mail.rptsys.com (Postfix) with ESMTPSA id D68AF828543D;
 Thu, 14 Mar 2024 17:15:57 -0500 (CDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6fbee253-e250-11ee-a1ee-f123f15fe8a2
DKIM-Filter: OpenDKIM Filter v2.10.3 mail.rptsys.com 5C43A828673E
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=raptorengineering.com; s=B8E824E6-0BE2-11E6-931D-288C65937AAD;
	t=1710454558; bh=sYFuyPzI+hrrFJYLQ4ibI3REmlE1nCAfT4TkBNcqNYs=;
	h=From:To:Date:Message-Id:MIME-Version;
	b=RzrlIuYuVGBybpl9EcDNGgjX4G+3zxrBCmEfVoQ+tXsIRSp6xvp1tTfgjU2Mphebl
	 wOz25CGw3W98rVsls2QkzQofvLspPhBrHFzm7vYT6J1R6U04H25UnsfmeEqcwkPdFt
	 R35HGpFCKaHBDAmduVRBT1P3SqR8dkBwcA4CP+tg=
X-Virus-Scanned: amavisd-new at rptsys.com
From: Shawn Anastasio 
To: xen-devel@lists.xenproject.org
Cc: tpearson@raptorengineering.com,
	Jan Beulich ,
	Shawn Anastasio ,
	Andrew Cooper ,
	George Dunlap ,
	Julien Grall ,
	Stefano Stabellini ,
	Wei Liu 
Subject: [PATCH v3 1/9] EFI: Introduce inline stub for efi_enabled on !X86 && !ARM
Date: Thu, 14 Mar 2024 17:15:39 -0500
Message-Id: <39069a589f9c4dc0db9b01b7412c1a99bea55f37.1710443965.git.sanastasio@raptorengineering.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

On architectures with no EFI support, define an inline stub
implementation of efi_enabled in efi.h that always returns false.

Suggested-by: Jan Beulich 
Signed-off-by: Shawn Anastasio 
---
 xen/include/xen/efi.h | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/xen/include/xen/efi.h b/xen/include/xen/efi.h
index 942d2e9491..160804e294 100644
--- a/xen/include/xen/efi.h
+++ b/xen/include/xen/efi.h
@@ -31,7 +31,15 @@ union compat_pf_efi_info;
 struct xenpf_efi_runtime_call;
 struct compat_pf_efi_runtime_call;
 
+#if defined(CONFIG_X86) || defined(CONFIG_ARM)
 bool efi_enabled(unsigned int feature);
+#else
+static inline bool efi_enabled(unsigned int feature)
+{
+    return false;
+}
+#endif
+
 void efi_init_memory(void);
 bool efi_boot_mem_unused(unsigned long *start, unsigned long *end);
 bool efi_rs_using_pgtables(void);
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu Mar 14 22:16:11 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 22:16:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693514.1081709 (Exim 4.92)
	(envelope-from )
	id 1rktMx-0000uH-JT; Thu, 14 Mar 2024 22:16:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693514.1081709; Thu, 14 Mar 2024 22:16:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rktMx-0000tu-Bs; Thu, 14 Mar 2024 22:16:11 +0000
Received: by outflank-mailman (input) for mailman id 693514;
 Thu, 14 Mar 2024 22:16:09 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rktMv-0000X2-NA
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 22:16:09 +0000
Received: from raptorengineering.com (mail.raptorengineering.com
 [23.155.224.40]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6fe7b67b-e250-11ee-a1ee-f123f15fe8a2;
 Thu, 14 Mar 2024 23:16:00 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
 by mail.rptsys.com (Postfix) with ESMTP id 88409828543D;
 Thu, 14 Mar 2024 17:15:59 -0500 (CDT)
Received: from mail.rptsys.com ([127.0.0.1])
 by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10032)
 with ESMTP id In-F3fzw0PDH; Thu, 14 Mar 2024 17:15:59 -0500 (CDT)
Received: from localhost (localhost [127.0.0.1])
 by mail.rptsys.com (Postfix) with ESMTP id 24B9F8286CAE;
 Thu, 14 Mar 2024 17:15:59 -0500 (CDT)
Received: from mail.rptsys.com ([127.0.0.1])
 by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10026)
 with ESMTP id 6m4HiXoewgMk; Thu, 14 Mar 2024 17:15:59 -0500 (CDT)
Received: from raptor-ewks-026.lan (5.edge.rptsys.com [23.155.224.38])
 by mail.rptsys.com (Postfix) with ESMTPSA id C418182869D5;
 Thu, 14 Mar 2024 17:15:58 -0500 (CDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6fe7b67b-e250-11ee-a1ee-f123f15fe8a2
DKIM-Filter: OpenDKIM Filter v2.10.3 mail.rptsys.com 24B9F8286CAE
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=raptorengineering.com; s=B8E824E6-0BE2-11E6-931D-288C65937AAD;
	t=1710454559; bh=XvBjwwSLExGOWxlieVRFHyENhmyN7ighTk2ZoHF8cvc=;
	h=From:To:Date:Message-Id:MIME-Version;
	b=kzYlWCFu8fsxDTKu4dg75848JNYpHBKKuXv1BDVBx0LGLdqcqWDBYB1gzTRaT9kbQ
	 xMy88qpLIRHHxLYrXEzTv7r6sEmtfIAvNeU3XdXv3krFY5J3q/2wSzrT7uMJ9geHKq
	 6l4U2CvGyXA3Ext0MzkTDP6tq3DnYpXXBKd9G7G4=
X-Virus-Scanned: amavisd-new at rptsys.com
From: Shawn Anastasio 
To: xen-devel@lists.xenproject.org
Cc: tpearson@raptorengineering.com,
	Jan Beulich ,
	Shawn Anastasio 
Subject: [PATCH v3 3/9] xen/ppc: Introduce stub asm/static-shmem.h
Date: Thu, 14 Mar 2024 17:15:41 -0500
Message-Id: <0cf8286269a1c5cdc63e2c19d832a4923cd14f39.1710443965.git.sanastasio@raptorengineering.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

Required for bootfdt.c to build.

Signed-off-by: Shawn Anastasio 
---
 xen/arch/ppc/include/asm/static-shmem.h | 12 ++++++++++++
 1 file changed, 12 insertions(+)
 create mode 100644 xen/arch/ppc/include/asm/static-shmem.h

diff --git a/xen/arch/ppc/include/asm/static-shmem.h b/xen/arch/ppc/include/asm/static-shmem.h
new file mode 100644
index 0000000000..84370d6e6c
--- /dev/null
+++ b/xen/arch/ppc/include/asm/static-shmem.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier:  GPL-2.0-only */
+
+#ifndef __ASM_PPC_STATIC_SHMEM_H__
+#define __ASM_PPC_STATIC_SHMEM_H__
+
+static inline int process_shm_node(const void *fdt, int node,
+                                   uint32_t address_cells, uint32_t size_cells)
+{
+    return -EINVAL;
+}
+
+#endif /* __ASM_PPC_STATIC_SHMEM_H__ */
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu Mar 14 22:16:12 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 22:16:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693515.1081713 (Exim 4.92)
	(envelope-from )
	id 1rktMx-0000yK-Sv; Thu, 14 Mar 2024 22:16:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693515.1081713; Thu, 14 Mar 2024 22:16:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rktMx-0000wR-Me; Thu, 14 Mar 2024 22:16:11 +0000
Received: by outflank-mailman (input) for mailman id 693515;
 Thu, 14 Mar 2024 22:16:10 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rktMw-0000X2-NE
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 22:16:10 +0000
Received: from raptorengineering.com (mail.raptorengineering.com
 [23.155.224.40]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 72db41df-e250-11ee-a1ee-f123f15fe8a2;
 Thu, 14 Mar 2024 23:16:05 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
 by mail.rptsys.com (Postfix) with ESMTP id A5F1C8286CAF;
 Thu, 14 Mar 2024 17:16:01 -0500 (CDT)
Received: from mail.rptsys.com ([127.0.0.1])
 by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10032)
 with ESMTP id tDgj889x-TCk; Thu, 14 Mar 2024 17:16:01 -0500 (CDT)
Received: from localhost (localhost [127.0.0.1])
 by mail.rptsys.com (Postfix) with ESMTP id F1AAE828673E;
 Thu, 14 Mar 2024 17:16:00 -0500 (CDT)
Received: from mail.rptsys.com ([127.0.0.1])
 by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10026)
 with ESMTP id Ekesbb3plJdX; Thu, 14 Mar 2024 17:16:00 -0500 (CDT)
Received: from raptor-ewks-026.lan (5.edge.rptsys.com [23.155.224.38])
 by mail.rptsys.com (Postfix) with ESMTPSA id 214678286CAF;
 Thu, 14 Mar 2024 17:16:00 -0500 (CDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 72db41df-e250-11ee-a1ee-f123f15fe8a2
DKIM-Filter: OpenDKIM Filter v2.10.3 mail.rptsys.com F1AAE828673E
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=raptorengineering.com; s=B8E824E6-0BE2-11E6-931D-288C65937AAD;
	t=1710454561; bh=MDQ4qX1cZClSO+Sy5SemqANFOXF/LtmGjUBuy5sUWoI=;
	h=From:To:Date:Message-Id:MIME-Version;
	b=ViEnf6+rfF6+CQ43NWAtk16nUwQnLpNd9AHxGAbH51+3DDm96kWYULgFqvzEiAuNW
	 xMrmDMWWLbs6I/zpmaaoQH5vh6EiZgfBUYgQGI6OUOVDa11VLvih0jM/RNUAlfJmFM
	 XHUnFR9879uXfHp92MjtFv4vlayklRSQ4L+ogEy4=
X-Virus-Scanned: amavisd-new at rptsys.com
From: Shawn Anastasio 
To: xen-devel@lists.xenproject.org
Cc: tpearson@raptorengineering.com,
	Jan Beulich ,
	Shawn Anastasio ,
	Andrew Cooper ,
	George Dunlap ,
	Julien Grall ,
	Stefano Stabellini ,
	Wei Liu ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk 
Subject: [PATCH v3 6/9] xen/common: Move Arm's bootfdt.c to common
Date: Thu, 14 Mar 2024 17:15:44 -0500
Message-Id: <908ea2d9bccf0b3455119cfd9af0597aee005fe8.1710443965.git.sanastasio@raptorengineering.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

Move Arm's bootfdt.c to xen/common so that it can be used by other
device tree architectures like PPC and RISCV.

Suggested-by: Julien Grall 
Signed-off-by: Shawn Anastasio 
Acked-by: Julien Grall 
---
Changes in v2:
  - Drop #if defined(CONFIG_ARM_EFI) now that efi_enabled is stubbed

 MAINTAINERS                                    | 1 +
 xen/arch/arm/Makefile                          | 1 -
 xen/common/device-tree/Makefile                | 1 +
 xen/{arch/arm => common/device-tree}/bootfdt.c | 0
 4 files changed, 2 insertions(+), 1 deletion(-)
 rename xen/{arch/arm => common/device-tree}/bootfdt.c (100%)

diff --git a/MAINTAINERS b/MAINTAINERS
index e85fbe6737..20fdec9ffa 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -251,6 +251,7 @@ S:	Supported
 L:	xen-devel@lists.xenproject.org
 F:	docs/misc/arm/
 F:	xen/arch/arm/
+F:	xen/common/device-tree/bootfdt.c
 F:	xen/drivers/char/arm-uart.c
 F:	xen/drivers/char/cadence-uart.c
 F:	xen/drivers/char/exynos4210-uart.c
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 7b1350e2ef..9e1548378c 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -10,7 +10,6 @@ obj-$(CONFIG_TEE) += tee/
 obj-$(CONFIG_HAS_VPCI) += vpci.o

 obj-$(CONFIG_HAS_ALTERNATIVE) += alternative.o
-obj-y += bootfdt.init.o
 obj-y += cpuerrata.o
 obj-y += cpufeature.o
 obj-y += decode.o
diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile
index c97b2bd88c..fa5beafd65 100644
--- a/xen/common/device-tree/Makefile
+++ b/xen/common/device-tree/Makefile
@@ -1 +1,2 @@
+obj-y += bootfdt.init.o
 obj-y += bootinfo.o
diff --git a/xen/arch/arm/bootfdt.c b/xen/common/device-tree/bootfdt.c
similarity index 100%
rename from xen/arch/arm/bootfdt.c
rename to xen/common/device-tree/bootfdt.c
--
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu Mar 14 22:16:13 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 22:16:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693516.1081732 (Exim 4.92)
	(envelope-from )
	id 1rktMz-0001XE-JG; Thu, 14 Mar 2024 22:16:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693516.1081732; Thu, 14 Mar 2024 22:16:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rktMz-0001VZ-D0; Thu, 14 Mar 2024 22:16:13 +0000
Received: by outflank-mailman (input) for mailman id 693516;
 Thu, 14 Mar 2024 22:16:11 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rktMx-0000X2-NM
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 22:16:11 +0000
Received: from raptorengineering.com (mail.raptorengineering.com
 [23.155.224.40]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6fe46582-e250-11ee-a1ee-f123f15fe8a2;
 Thu, 14 Mar 2024 23:16:00 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
 by mail.rptsys.com (Postfix) with ESMTP id 744238285564;
 Thu, 14 Mar 2024 17:15:59 -0500 (CDT)
Received: from mail.rptsys.com ([127.0.0.1])
 by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10032)
 with ESMTP id UdD9ZEYWtjvs; Thu, 14 Mar 2024 17:15:58 -0500 (CDT)
Received: from localhost (localhost [127.0.0.1])
 by mail.rptsys.com (Postfix) with ESMTP id C9F65828543D;
 Thu, 14 Mar 2024 17:15:58 -0500 (CDT)
Received: from mail.rptsys.com ([127.0.0.1])
 by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10026)
 with ESMTP id cyxb2cIHxSnA; Thu, 14 Mar 2024 17:15:58 -0500 (CDT)
Received: from raptor-ewks-026.lan (5.edge.rptsys.com [23.155.224.38])
 by mail.rptsys.com (Postfix) with ESMTPSA id 59AF78285564;
 Thu, 14 Mar 2024 17:15:58 -0500 (CDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6fe46582-e250-11ee-a1ee-f123f15fe8a2
DKIM-Filter: OpenDKIM Filter v2.10.3 mail.rptsys.com C9F65828543D
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=raptorengineering.com; s=B8E824E6-0BE2-11E6-931D-288C65937AAD;
	t=1710454558; bh=WG1KE8M9PlKZmebhXqBSnvpa7eeG1otWt/lFqFW0d9Y=;
	h=From:To:Date:Message-Id:MIME-Version;
	b=QdMUGUkCD+q3TmBTdELez63waXReD0+ItPQ79RX5QY1KVhCQIReBKI4zu55IQBuKb
	 JGLOT/a0fn19U8QfHHXqDq5C5aGKq6qBvclRdkyENdNkL1UTPMFoFlixWxvXAh4SM9
	 LFNtDX8ur+NgPeR+KknSxUn2PyfhoKT+41VMBkW8=
X-Virus-Scanned: amavisd-new at rptsys.com
From: Shawn Anastasio 
To: xen-devel@lists.xenproject.org
Cc: tpearson@raptorengineering.com,
	Jan Beulich ,
	Shawn Anastasio ,
	Andrew Cooper ,
	George Dunlap ,
	Julien Grall ,
	Stefano Stabellini ,
	Wei Liu 
Subject: [PATCH v3 2/9] xen/asm-generic: Introduce generic acpi.h
Date: Thu, 14 Mar 2024 17:15:40 -0500
Message-Id: <794e46b16475c0b4f482cdc8560ebb2f37875715.1710443965.git.sanastasio@raptorengineering.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

Introduce a generic acpi.h header that provides the required definitions
to allow files including xen/acpi.h to be compiled. The definitions were
largely derived from the !CONFIG_ACPI parts of ARM's acpi.h.

Signed-off-by: Shawn Anastasio 
---
 xen/arch/ppc/include/asm/Makefile |  1 +
 xen/include/asm-generic/acpi.h    | 20 ++++++++++++++++++++
 2 files changed, 21 insertions(+)
 create mode 100644 xen/include/asm-generic/acpi.h

diff --git a/xen/arch/ppc/include/asm/Makefile b/xen/arch/ppc/include/asm/Makefile
index ced02e26ed..a4faa0f2aa 100644
--- a/xen/arch/ppc/include/asm/Makefile
+++ b/xen/arch/ppc/include/asm/Makefile
@@ -1,4 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0-only
+generic-y += acpi.h
 generic-y += altp2m.h
 generic-y += device.h
 generic-y += div64.h
diff --git a/xen/include/asm-generic/acpi.h b/xen/include/asm-generic/acpi.h
new file mode 100644
index 0000000000..ae9ed83ba8
--- /dev/null
+++ b/xen/include/asm-generic/acpi.h
@@ -0,0 +1,20 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef __ASM_GENERIC_ACPI_H
+#define __ASM_GENERIC_ACPI_H
+
+#include 
+#include 
+
+#ifdef CONFIG_ACPI
+#error "asm-generic acpi.h can't be used with CONFIG_ACPI set"
+#endif
+
+#define COMPILER_DEPENDENT_INT64   int64_t
+#define COMPILER_DEPENDENT_UINT64  uint64_t
+#define ACPI_MAP_MEM_ATTR          PAGE_HYPERVISOR
+
+#define acpi_disabled (true)
+#define disable_acpi()
+#define enable_acpi()
+
+#endif /* __ASM_GENERIC_ACPI_H */
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu Mar 14 22:16:14 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 22:16:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693517.1081738 (Exim 4.92)
	(envelope-from )
	id 1rktN0-0001f9-35; Thu, 14 Mar 2024 22:16:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693517.1081738; Thu, 14 Mar 2024 22:16:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rktMz-0001d3-RY; Thu, 14 Mar 2024 22:16:13 +0000
Received: by outflank-mailman (input) for mailman id 693517;
 Thu, 14 Mar 2024 22:16:12 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rktMy-0000X2-NO
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 22:16:12 +0000
Received: from raptorengineering.com (mail.raptorengineering.com
 [23.155.224.40]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 72f8a9cb-e250-11ee-a1ee-f123f15fe8a2;
 Thu, 14 Mar 2024 23:16:05 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
 by mail.rptsys.com (Postfix) with ESMTP id 36AE48286A4B;
 Thu, 14 Mar 2024 17:16:02 -0500 (CDT)
Received: from mail.rptsys.com ([127.0.0.1])
 by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10032)
 with ESMTP id n9bwzI00_r5F; Thu, 14 Mar 2024 17:16:01 -0500 (CDT)
Received: from localhost (localhost [127.0.0.1])
 by mail.rptsys.com (Postfix) with ESMTP id 81C7A8286D0A;
 Thu, 14 Mar 2024 17:16:01 -0500 (CDT)
Received: from mail.rptsys.com ([127.0.0.1])
 by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10026)
 with ESMTP id pFHCcpG6XIBN; Thu, 14 Mar 2024 17:16:01 -0500 (CDT)
Received: from raptor-ewks-026.lan (5.edge.rptsys.com [23.155.224.38])
 by mail.rptsys.com (Postfix) with ESMTPSA id 319138286CAF;
 Thu, 14 Mar 2024 17:16:01 -0500 (CDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 72f8a9cb-e250-11ee-a1ee-f123f15fe8a2
DKIM-Filter: OpenDKIM Filter v2.10.3 mail.rptsys.com 81C7A8286D0A
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=raptorengineering.com; s=B8E824E6-0BE2-11E6-931D-288C65937AAD;
	t=1710454561; bh=dt6YNGcjC+/2CTbftddRfgPKz9WX5uH4sC7NdpXR/zg=;
	h=From:To:Date:Message-Id:MIME-Version;
	b=Z2UNifXzecjQuuILvfxWVzbh6HVrO3/il7j/lFSgu0kAdSFhgjbxGI+ipe1qXPV7/
	 BUgYeJv5JFNmYJXheZFCIRup4mpXh3T6k0ikrhIk9rDXkH6P/5CH0dnLA7JasCw/GH
	 H7NjdrNE+ydC3wG1UjVBSJYX0DHOG5029obWFytI=
X-Virus-Scanned: amavisd-new at rptsys.com
From: Shawn Anastasio 
To: xen-devel@lists.xenproject.org
Cc: tpearson@raptorengineering.com,
	Jan Beulich ,
	Shawn Anastasio 
Subject: [PATCH v3 8/9] xen/ppc: mm-radix: Replace debug printing code with printk
Date: Thu, 14 Mar 2024 17:15:46 -0500
Message-Id: 
X-Mailer: git-send-email 2.30.2
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

Now that we have common code building, there's no need to keep the old
itoa64+debug print function in mm-radix.c

Signed-off-by: Shawn Anastasio 
---
Changes in v2:
  - Use CONFIG_DEBUG instead of NDEBUG

 xen/arch/ppc/mm-radix.c | 58 +++++++++--------------------------------
 1 file changed, 12 insertions(+), 46 deletions(-)

diff --git a/xen/arch/ppc/mm-radix.c b/xen/arch/ppc/mm-radix.c
index daa411a6fa..ab5a10695c 100644
--- a/xen/arch/ppc/mm-radix.c
+++ b/xen/arch/ppc/mm-radix.c
@@ -15,6 +15,12 @@

 void enable_mmu(void);

+#ifdef CONFIG_DEBUG
+#define radix_dprintk(msg, ...) printk(XENLOG_DEBUG msg, ## __VA_ARGS__)
+#else
+#define radix_dprintk(...)
+#endif
+
 #define INITIAL_LVL1_PD_COUNT      1
 #define INITIAL_LVL2_LVL3_PD_COUNT 2
 #define INITIAL_LVL4_PT_COUNT      256
@@ -80,45 +86,6 @@ static __init struct lvl4_pt *lvl4_pt_pool_alloc(void)
     return &initial_lvl4_pt_pool[initial_lvl4_pt_pool_used++];
 }

-#ifndef NDEBUG
-/* TODO: Remove once we get common/ building */
-static char *__init itoa64_hex(uint64_t val, char *out_buf, size_t buf_len)
-{
-    uint64_t cur;
-    size_t i = buf_len - 1;
-
-    /* Null terminate buffer */
-    out_buf[i] = '\0';
-
-    /* Add digits in reverse */
-    cur = val;
-    while ( cur && i > 0 )
-    {
-        out_buf[--i] = "0123456789ABCDEF"[cur % 16];
-        cur /= 16;
-    }
-
-    /* Pad to 16 digits */
-    while ( i > 0 )
-        out_buf[--i] = '0';
-
-    return out_buf + i;
-}
-#endif
-
-static void __init radix_dprint(uint64_t addr, const char *msg)
-{
-#ifndef NDEBUG
-    char buf[sizeof("DEADBEEFCAFEBABA")];
-    char *addr_s = itoa64_hex(addr, buf, sizeof(buf));
-
-    early_printk("(0x");
-    early_printk(addr_s);
-    early_printk(") ");
-    early_printk(msg);
-#endif
-}
-
 static void __init setup_initial_mapping(struct lvl1_pd *lvl1,
                                          vaddr_t map_start,
                                          vaddr_t map_end,
@@ -186,27 +153,26 @@ static void __init setup_initial_mapping(struct lvl1_pd *lvl1,
             unsigned long paddr = (page_addr - map_start) + phys_base;
             unsigned long flags;

-            radix_dprint(paddr, "being mapped to ");
-            radix_dprint(page_addr, "!\n");
+            radix_dprintk("%016lx being mapped to %016lx\n", paddr, page_addr);
             if ( is_kernel_text(page_addr) || is_kernel_inittext(page_addr) )
             {
-                radix_dprint(page_addr, "being marked as TEXT (RX)\n");
+                radix_dprintk("%016lx being marked as TEXT (RX)\n", page_addr);
                 flags = PTE_XEN_RX;
             }
             else if ( is_kernel_rodata(page_addr) )
             {
-                radix_dprint(page_addr, "being marked as RODATA (RO)\n");
+                radix_dprintk("%016lx being marked as RODATA (RO)\n", page_addr);
                 flags = PTE_XEN_RO;
             }
             else
             {
-                radix_dprint(page_addr, "being marked as DEFAULT (RW)\n");
+                radix_dprintk("%016lx being marked as DEFAULT (RW)\n", page_addr);
                 flags = PTE_XEN_RW;
             }

             *pte = paddr_to_pte(paddr, flags);
-            radix_dprint(paddr_to_pte(paddr, flags).pte,
-                             "is result of PTE map!\n");
+            radix_dprintk("%016lx is the result of PTE map\n",
+                paddr_to_pte(paddr, flags).pte);
         }
         else
         {
--
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu Mar 14 22:16:15 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 22:16:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693518.1081751 (Exim 4.92)
	(envelope-from )
	id 1rktN1-000244-CJ; Thu, 14 Mar 2024 22:16:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693518.1081751; Thu, 14 Mar 2024 22:16:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rktN1-00023V-5F; Thu, 14 Mar 2024 22:16:15 +0000
Received: by outflank-mailman (input) for mailman id 693518;
 Thu, 14 Mar 2024 22:16:14 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rktMz-0000X2-NV
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 22:16:13 +0000
Received: from raptorengineering.com (mail.raptorengineering.com
 [23.155.224.40]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 72f8547a-e250-11ee-a1ee-f123f15fe8a2;
 Thu, 14 Mar 2024 23:16:05 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
 by mail.rptsys.com (Postfix) with ESMTP id 9C3FC8286CF5;
 Thu, 14 Mar 2024 17:16:02 -0500 (CDT)
Received: from mail.rptsys.com ([127.0.0.1])
 by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10032)
 with ESMTP id czhFb6PbTxxG; Thu, 14 Mar 2024 17:16:00 -0500 (CDT)
Received: from localhost (localhost [127.0.0.1])
 by mail.rptsys.com (Postfix) with ESMTP id 3628B8286CAE;
 Thu, 14 Mar 2024 17:16:00 -0500 (CDT)
Received: from mail.rptsys.com ([127.0.0.1])
 by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10026)
 with ESMTP id JtVqs41vqD3h; Thu, 14 Mar 2024 17:15:59 -0500 (CDT)
Received: from raptor-ewks-026.lan (5.edge.rptsys.com [23.155.224.38])
 by mail.rptsys.com (Postfix) with ESMTPSA id 6F11E8286790;
 Thu, 14 Mar 2024 17:15:59 -0500 (CDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 72f8547a-e250-11ee-a1ee-f123f15fe8a2
DKIM-Filter: OpenDKIM Filter v2.10.3 mail.rptsys.com 3628B8286CAE
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=raptorengineering.com; s=B8E824E6-0BE2-11E6-931D-288C65937AAD;
	t=1710454560; bh=qU6fRQlVfTPmaXGICHyYeZAo/sfzg+/2MQ1+Rm907mk=;
	h=From:To:Date:Message-Id:MIME-Version;
	b=DeL4d2CDd0M/SK+9HBrLrwb2I5xooKHCerbnsnnHjy8vIIw2fPpaX9YCoHH5Ht1RF
	 3Da9+0ozUElYTvPsSD2KZKzfHP+6x6c0CfYMlGOinAKhoZFWxx4jBpXk9mWgRs8U3H
	 Jzgm1VS/VCPW/HQy3yDXxhxMIOm9jZwWDYFVfcuo=
X-Virus-Scanned: amavisd-new at rptsys.com
From: Shawn Anastasio 
To: xen-devel@lists.xenproject.org
Cc: tpearson@raptorengineering.com,
	Jan Beulich ,
	Shawn Anastasio ,
	Andrew Cooper ,
	George Dunlap ,
	Julien Grall ,
	Stefano Stabellini ,
	Wei Liu ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	"Daniel P. Smith" 
Subject: [PATCH v3 5/9] xen/device-tree: Move Arm's setup.c bootinfo functions to common
Date: Thu, 14 Mar 2024 17:15:43 -0500
Message-Id: <039524d4157dddb2faf6887739a727f6e993b53f.1710443965.git.sanastasio@raptorengineering.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

Arm's setup.c contains a collection of functions for parsing memory map
and other boot information from a device tree. Since these routines are
generally useful on any architecture that supports device tree booting,
move them into xen/common/device-tree.

Suggested-by: Julien Grall 
Signed-off-by: Shawn Anastasio 
---
 MAINTAINERS                       |   1 +
 xen/arch/arm/setup.c              | 419 --------------------------
 xen/common/Makefile               |   1 +
 xen/common/device-tree/Makefile   |   1 +
 xen/common/device-tree/bootinfo.c | 469 ++++++++++++++++++++++++++++++
 5 files changed, 472 insertions(+), 419 deletions(-)
 create mode 100644 xen/common/device-tree/Makefile
 create mode 100644 xen/common/device-tree/bootinfo.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 56a6932037..e85fbe6737 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -301,6 +301,7 @@ M:	Stefano Stabellini 
 M:	Julien Grall 
 S:	Supported
 F:	xen/common/libfdt/
+F:	xen/common/device-tree/setup.c
 F:	xen/common/device_tree.c
 F:	xen/common/dt-overlay.c
 F:	xen/include/xen/libfdt/
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 424744ad5e..e60184f583 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -48,8 +48,6 @@
 #include 
 #include 
 
-struct bootinfo __initdata bootinfo;
-
 /*
  * Sanitized version of cpuinfo containing only features available on all
  * cores (only on arm64 as there is no sanitization support on arm32).
@@ -203,309 +201,6 @@ static void __init processor_id(void)
     processor_setup();
 }
 
-static void __init dt_unreserved_regions(paddr_t s, paddr_t e,
-                                         void (*cb)(paddr_t ps, paddr_t pe),
-                                         unsigned int first)
-{
-    unsigned int i, nr;
-    int rc;
-
-    rc = fdt_num_mem_rsv(device_tree_flattened);
-    if ( rc < 0 )
-        panic("Unable to retrieve the number of reserved regions (rc=%d)\n",
-              rc);
-
-    nr = rc;
-
-    for ( i = first; i < nr ; i++ )
-    {
-        paddr_t r_s, r_e;
-
-        if ( fdt_get_mem_rsv_paddr(device_tree_flattened, i, &r_s, &r_e ) < 0 )
-            /* If we can't read it, pretend it doesn't exist... */
-            continue;
-
-        r_e += r_s; /* fdt_get_mem_rsv_paddr returns length */
-
-        if ( s < r_e && r_s < e )
-        {
-            dt_unreserved_regions(r_e, e, cb, i+1);
-            dt_unreserved_regions(s, r_s, cb, i+1);
-            return;
-        }
-    }
-
-    /*
-     * i is the current bootmodule we are evaluating across all possible
-     * kinds.
-     *
-     * When retrieving the corresponding reserved-memory addresses
-     * below, we need to index the bootinfo.reserved_mem bank starting
-     * from 0, and only counting the reserved-memory modules. Hence,
-     * we need to use i - nr.
-     */
-    for ( ; i - nr < bootinfo.reserved_mem.nr_banks; i++ )
-    {
-        paddr_t r_s = bootinfo.reserved_mem.bank[i - nr].start;
-        paddr_t r_e = r_s + bootinfo.reserved_mem.bank[i - nr].size;
-
-        if ( s < r_e && r_s < e )
-        {
-            dt_unreserved_regions(r_e, e, cb, i + 1);
-            dt_unreserved_regions(s, r_s, cb, i + 1);
-            return;
-        }
-    }
-
-    cb(s, e);
-}
-
-/*
- * TODO: '*_end' could be 0 if the bank/region is at the end of the physical
- * address space. This is for now not handled as it requires more rework.
- */
-static bool __init meminfo_overlap_check(struct meminfo *meminfo,
-                                         paddr_t region_start,
-                                         paddr_t region_size)
-{
-    paddr_t bank_start = INVALID_PADDR, bank_end = 0;
-    paddr_t region_end = region_start + region_size;
-    unsigned int i, bank_num = meminfo->nr_banks;
-
-    for ( i = 0; i < bank_num; i++ )
-    {
-        bank_start = meminfo->bank[i].start;
-        bank_end = bank_start + meminfo->bank[i].size;
-
-        if ( region_end <= bank_start || region_start >= bank_end )
-            continue;
-        else
-        {
-            printk("Region: [%#"PRIpaddr", %#"PRIpaddr") overlapping with bank[%u]: [%#"PRIpaddr", %#"PRIpaddr")\n",
-                   region_start, region_end, i, bank_start, bank_end);
-            return true;
-        }
-    }
-
-    return false;
-}
-
-/*
- * TODO: '*_end' could be 0 if the module/region is at the end of the physical
- * address space. This is for now not handled as it requires more rework.
- */
-static bool __init bootmodules_overlap_check(struct bootmodules *bootmodules,
-                                             paddr_t region_start,
-                                             paddr_t region_size)
-{
-    paddr_t mod_start = INVALID_PADDR, mod_end = 0;
-    paddr_t region_end = region_start + region_size;
-    unsigned int i, mod_num = bootmodules->nr_mods;
-
-    for ( i = 0; i < mod_num; i++ )
-    {
-        mod_start = bootmodules->module[i].start;
-        mod_end = mod_start + bootmodules->module[i].size;
-
-        if ( region_end <= mod_start || region_start >= mod_end )
-            continue;
-        else
-        {
-            printk("Region: [%#"PRIpaddr", %#"PRIpaddr") overlapping with mod[%u]: [%#"PRIpaddr", %#"PRIpaddr")\n",
-                   region_start, region_end, i, mod_start, mod_end);
-            return true;
-        }
-    }
-
-    return false;
-}
-
-void __init fw_unreserved_regions(paddr_t s, paddr_t e,
-                                  void (*cb)(paddr_t ps, paddr_t pe),
-                                  unsigned int first)
-{
-    if ( acpi_disabled )
-        dt_unreserved_regions(s, e, cb, first);
-    else
-        cb(s, e);
-}
-
-/*
- * Given an input physical address range, check if this range is overlapping
- * with the existing reserved memory regions defined in bootinfo.
- * Return true if the input physical address range is overlapping with any
- * existing reserved memory regions, otherwise false.
- */
-bool __init check_reserved_regions_overlap(paddr_t region_start,
-                                           paddr_t region_size)
-{
-    /* Check if input region is overlapping with bootinfo.reserved_mem banks */
-    if ( meminfo_overlap_check(&bootinfo.reserved_mem,
-                               region_start, region_size) )
-        return true;
-
-    /* Check if input region is overlapping with bootmodules */
-    if ( bootmodules_overlap_check(&bootinfo.modules,
-                                   region_start, region_size) )
-        return true;
-
-#ifdef CONFIG_ACPI
-    /* Check if input region is overlapping with ACPI EfiACPIReclaimMemory */
-    if ( meminfo_overlap_check(&bootinfo.acpi, region_start, region_size) )
-        return true;
-#endif
-
-    return false;
-}
-
-struct bootmodule __init *add_boot_module(bootmodule_kind kind,
-                                          paddr_t start, paddr_t size,
-                                          bool domU)
-{
-    struct bootmodules *mods = &bootinfo.modules;
-    struct bootmodule *mod;
-    unsigned int i;
-
-    if ( mods->nr_mods == MAX_MODULES )
-    {
-        printk("Ignoring %s boot module at %"PRIpaddr"-%"PRIpaddr" (too many)\n",
-               boot_module_kind_as_string(kind), start, start + size);
-        return NULL;
-    }
-
-    if ( check_reserved_regions_overlap(start, size) )
-        return NULL;
-
-    for ( i = 0 ; i < mods->nr_mods ; i++ )
-    {
-        mod = &mods->module[i];
-        if ( mod->kind == kind && mod->start == start )
-        {
-            if ( !domU )
-                mod->domU = false;
-            return mod;
-        }
-    }
-
-    mod = &mods->module[mods->nr_mods++];
-    mod->kind = kind;
-    mod->start = start;
-    mod->size = size;
-    mod->domU = domU;
-
-    return mod;
-}
-
-/*
- * boot_module_find_by_kind can only be used to return Xen modules (e.g
- * XSM, DTB) or Dom0 modules. This is not suitable for looking up guest
- * modules.
- */
-struct bootmodule * __init boot_module_find_by_kind(bootmodule_kind kind)
-{
-    struct bootmodules *mods = &bootinfo.modules;
-    struct bootmodule *mod;
-    int i;
-    for (i = 0 ; i < mods->nr_mods ; i++ )
-    {
-        mod = &mods->module[i];
-        if ( mod->kind == kind && !mod->domU )
-            return mod;
-    }
-    return NULL;
-}
-
-void __init add_boot_cmdline(const char *name, const char *cmdline,
-                             bootmodule_kind kind, paddr_t start, bool domU)
-{
-    struct bootcmdlines *cmds = &bootinfo.cmdlines;
-    struct bootcmdline *cmd;
-
-    if ( cmds->nr_mods == MAX_MODULES )
-    {
-        printk("Ignoring %s cmdline (too many)\n", name);
-        return;
-    }
-
-    cmd = &cmds->cmdline[cmds->nr_mods++];
-    cmd->kind = kind;
-    cmd->domU = domU;
-    cmd->start = start;
-
-    ASSERT(strlen(name) <= DT_MAX_NAME);
-    safe_strcpy(cmd->dt_name, name);
-
-    if ( strlen(cmdline) > BOOTMOD_MAX_CMDLINE )
-        panic("module %s command line too long\n", name);
-    safe_strcpy(cmd->cmdline, cmdline);
-}
-
-/*
- * boot_cmdline_find_by_kind can only be used to return Xen modules (e.g
- * XSM, DTB) or Dom0 modules. This is not suitable for looking up guest
- * modules.
- */
-struct bootcmdline * __init boot_cmdline_find_by_kind(bootmodule_kind kind)
-{
-    struct bootcmdlines *cmds = &bootinfo.cmdlines;
-    struct bootcmdline *cmd;
-    int i;
-
-    for ( i = 0 ; i < cmds->nr_mods ; i++ )
-    {
-        cmd = &cmds->cmdline[i];
-        if ( cmd->kind == kind && !cmd->domU )
-            return cmd;
-    }
-    return NULL;
-}
-
-struct bootcmdline * __init boot_cmdline_find_by_name(const char *name)
-{
-    struct bootcmdlines *mods = &bootinfo.cmdlines;
-    struct bootcmdline *mod;
-    unsigned int i;
-
-    for (i = 0 ; i < mods->nr_mods ; i++ )
-    {
-        mod = &mods->cmdline[i];
-        if ( strcmp(mod->dt_name, name) == 0 )
-            return mod;
-    }
-    return NULL;
-}
-
-struct bootmodule * __init boot_module_find_by_addr_and_kind(bootmodule_kind kind,
-                                                             paddr_t start)
-{
-    struct bootmodules *mods = &bootinfo.modules;
-    struct bootmodule *mod;
-    unsigned int i;
-
-    for (i = 0 ; i < mods->nr_mods ; i++ )
-    {
-        mod = &mods->module[i];
-        if ( mod->kind == kind && mod->start == start )
-            return mod;
-    }
-    return NULL;
-}
-
-const char * __init boot_module_kind_as_string(bootmodule_kind kind)
-{
-    switch ( kind )
-    {
-    case BOOTMOD_XEN:     return "Xen";
-    case BOOTMOD_FDT:     return "Device Tree";
-    case BOOTMOD_KERNEL:  return "Kernel";
-    case BOOTMOD_RAMDISK: return "Ramdisk";
-    case BOOTMOD_XSM:     return "XSM";
-    case BOOTMOD_GUEST_DTB:     return "DTB";
-    case BOOTMOD_UNKNOWN: return "Unknown";
-    default: BUG();
-    }
-}
-
 void __init discard_initial_modules(void)
 {
     struct bootmodules *mi = &bootinfo.modules;
@@ -544,40 +239,6 @@ static void * __init relocate_fdt(paddr_t dtb_paddr, size_t dtb_size)
     return fdt;
 }
 
-/*
- * Return the end of the non-module region starting at s. In other
- * words return s the start of the next modules after s.
- *
- * On input *end is the end of the region which should be considered
- * and it is updated to reflect the end of the module, clipped to the
- * end of the region if it would run over.
- */
-static paddr_t __init next_module(paddr_t s, paddr_t *end)
-{
-    struct bootmodules *mi = &bootinfo.modules;
-    paddr_t lowest = ~(paddr_t)0;
-    int i;
-
-    for ( i = 0; i < mi->nr_mods; i++ )
-    {
-        paddr_t mod_s = mi->module[i].start;
-        paddr_t mod_e = mod_s + mi->module[i].size;
-
-        if ( !mi->module[i].size )
-            continue;
-
-        if ( mod_s < s )
-            continue;
-        if ( mod_s > lowest )
-            continue;
-        if ( mod_s > *end )
-            continue;
-        lowest = mod_s;
-        *end = min(*end, mod_e);
-    }
-    return lowest;
-}
-
 void __init init_pdx(void)
 {
     paddr_t bank_start, bank_size, bank_end;
@@ -622,86 +283,6 @@ void __init init_pdx(void)
     }
 }
 
-/*
- * Populate the boot allocator.
- * If a static heap was not provided by the admin, all the RAM but the
- * following regions will be added:
- *  - Modules (e.g., Xen, Kernel)
- *  - Reserved regions
- *  - Xenheap (arm32 only)
- * If a static heap was provided by the admin, populate the boot
- * allocator with the corresponding regions only, but with Xenheap excluded
- * on arm32.
- */
-void __init populate_boot_allocator(void)
-{
-    unsigned int i;
-    const struct meminfo *banks = &bootinfo.mem;
-    paddr_t s, e;
-
-    if ( bootinfo.static_heap )
-    {
-        for ( i = 0 ; i < bootinfo.reserved_mem.nr_banks; i++ )
-        {
-            if ( bootinfo.reserved_mem.bank[i].type != MEMBANK_STATIC_HEAP )
-                continue;
-
-            s = bootinfo.reserved_mem.bank[i].start;
-            e = s + bootinfo.reserved_mem.bank[i].size;
-#ifdef CONFIG_ARM_32
-            /* Avoid the xenheap, note that the xenheap cannot across a bank */
-            if ( s <= mfn_to_maddr(directmap_mfn_start) &&
-                 e >= mfn_to_maddr(directmap_mfn_end) )
-            {
-                init_boot_pages(s, mfn_to_maddr(directmap_mfn_start));
-                init_boot_pages(mfn_to_maddr(directmap_mfn_end), e);
-            }
-            else
-#endif
-                init_boot_pages(s, e);
-        }
-
-        return;
-    }
-
-    for ( i = 0; i < banks->nr_banks; i++ )
-    {
-        const struct membank *bank = &banks->bank[i];
-        paddr_t bank_end = bank->start + bank->size;
-
-        s = bank->start;
-        while ( s < bank_end )
-        {
-            paddr_t n = bank_end;
-
-            e = next_module(s, &n);
-
-            if ( e == ~(paddr_t)0 )
-                e = n = bank_end;
-
-            /*
-             * Module in a RAM bank other than the one which we are
-             * not dealing with here.
-             */
-            if ( e > bank_end )
-                e = bank_end;
-
-#ifdef CONFIG_ARM_32
-            /* Avoid the xenheap */
-            if ( s < mfn_to_maddr(directmap_mfn_end) &&
-                 mfn_to_maddr(directmap_mfn_start) < e )
-            {
-                e = mfn_to_maddr(directmap_mfn_start);
-                n = mfn_to_maddr(directmap_mfn_end);
-            }
-#endif
-
-            fw_unreserved_regions(s, e, init_boot_pages, 0);
-            s = n;
-        }
-    }
-}
-
 size_t __read_mostly dcache_line_bytes;
 
 /* C entry point for boot CPU */
diff --git a/xen/common/Makefile b/xen/common/Makefile
index e5eee19a85..3a39dd35f2 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -76,6 +76,7 @@ obj-$(CONFIG_UBSAN) += ubsan/
 
 obj-$(CONFIG_NEEDS_LIBELF) += libelf/
 obj-$(CONFIG_HAS_DEVICE_TREE) += libfdt/
+obj-$(CONFIG_HAS_DEVICE_TREE) += device-tree/
 
 CONF_FILE := $(if $(patsubst /%,,$(KCONFIG_CONFIG)),$(objtree)/)$(KCONFIG_CONFIG)
 $(obj)/config.gz: $(CONF_FILE)
diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile
new file mode 100644
index 0000000000..c97b2bd88c
--- /dev/null
+++ b/xen/common/device-tree/Makefile
@@ -0,0 +1 @@
+obj-y += bootinfo.o
diff --git a/xen/common/device-tree/bootinfo.c b/xen/common/device-tree/bootinfo.c
new file mode 100644
index 0000000000..a6c0fe7917
--- /dev/null
+++ b/xen/common/device-tree/bootinfo.c
@@ -0,0 +1,469 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * Derived from $xen/arch/arm/setup.c.
+ *
+ * Early device tree parsing and bookkeeping routines.
+ *
+ * Tim Deegan 
+ * Copyright (c) 2011 Citrix Systems.
+ * Copyright (c) 2024 Raptor Engineering LLC
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct bootinfo __initdata bootinfo;
+
+const char * __init boot_module_kind_as_string(bootmodule_kind kind)
+{
+    switch ( kind )
+    {
+    case BOOTMOD_XEN:     return "Xen";
+    case BOOTMOD_FDT:     return "Device Tree";
+    case BOOTMOD_KERNEL:  return "Kernel";
+    case BOOTMOD_RAMDISK: return "Ramdisk";
+    case BOOTMOD_XSM:     return "XSM";
+    case BOOTMOD_GUEST_DTB:     return "DTB";
+    case BOOTMOD_UNKNOWN: return "Unknown";
+    default: BUG();
+    }
+}
+
+static void __init dt_unreserved_regions(paddr_t s, paddr_t e,
+                                         void (*cb)(paddr_t ps, paddr_t pe),
+                                         unsigned int first)
+{
+    unsigned int i, nr;
+    int rc;
+
+    rc = fdt_num_mem_rsv(device_tree_flattened);
+    if ( rc < 0 )
+        panic("Unable to retrieve the number of reserved regions (rc=%d)\n",
+              rc);
+
+    nr = rc;
+
+    for ( i = first; i < nr ; i++ )
+    {
+        paddr_t r_s, r_e;
+
+        if ( fdt_get_mem_rsv_paddr(device_tree_flattened, i, &r_s, &r_e ) < 0 )
+            /* If we can't read it, pretend it doesn't exist... */
+            continue;
+
+        r_e += r_s; /* fdt_get_mem_rsv_paddr returns length */
+
+        if ( s < r_e && r_s < e )
+        {
+            dt_unreserved_regions(r_e, e, cb, i+1);
+            dt_unreserved_regions(s, r_s, cb, i+1);
+            return;
+        }
+    }
+
+    /*
+     * i is the current bootmodule we are evaluating across all possible
+     * kinds.
+     *
+     * When retrieving the corresponding reserved-memory addresses
+     * below, we need to index the bootinfo.reserved_mem bank starting
+     * from 0, and only counting the reserved-memory modules. Hence,
+     * we need to use i - nr.
+     */
+    for ( ; i - nr < bootinfo.reserved_mem.nr_banks; i++ )
+    {
+        paddr_t r_s = bootinfo.reserved_mem.bank[i - nr].start;
+        paddr_t r_e = r_s + bootinfo.reserved_mem.bank[i - nr].size;
+
+        if ( s < r_e && r_s < e )
+        {
+            dt_unreserved_regions(r_e, e, cb, i + 1);
+            dt_unreserved_regions(s, r_s, cb, i + 1);
+            return;
+        }
+    }
+
+    cb(s, e);
+}
+
+/*
+ * TODO: '*_end' could be 0 if the bank/region is at the end of the physical
+ * address space. This is for now not handled as it requires more rework.
+ */
+static bool __init meminfo_overlap_check(struct meminfo *meminfo,
+                                         paddr_t region_start,
+                                         paddr_t region_size)
+{
+    paddr_t bank_start = INVALID_PADDR, bank_end = 0;
+    paddr_t region_end = region_start + region_size;
+    unsigned int i, bank_num = meminfo->nr_banks;
+
+    for ( i = 0; i < bank_num; i++ )
+    {
+        bank_start = meminfo->bank[i].start;
+        bank_end = bank_start + meminfo->bank[i].size;
+
+        if ( region_end <= bank_start || region_start >= bank_end )
+            continue;
+        else
+        {
+            printk("Region: [%#"PRIpaddr", %#"PRIpaddr") overlapping with bank[%u]: [%#"PRIpaddr", %#"PRIpaddr")\n",
+                   region_start, region_end, i, bank_start, bank_end);
+            return true;
+        }
+    }
+
+    return false;
+}
+
+/*
+ * TODO: '*_end' could be 0 if the module/region is at the end of the physical
+ * address space. This is for now not handled as it requires more rework.
+ */
+static bool __init bootmodules_overlap_check(struct bootmodules *bootmodules,
+                                             paddr_t region_start,
+                                             paddr_t region_size)
+{
+    paddr_t mod_start = INVALID_PADDR, mod_end = 0;
+    paddr_t region_end = region_start + region_size;
+    unsigned int i, mod_num = bootmodules->nr_mods;
+
+    for ( i = 0; i < mod_num; i++ )
+    {
+        mod_start = bootmodules->module[i].start;
+        mod_end = mod_start + bootmodules->module[i].size;
+
+        if ( region_end <= mod_start || region_start >= mod_end )
+            continue;
+        else
+        {
+            printk("Region: [%#"PRIpaddr", %#"PRIpaddr") overlapping with mod[%u]: [%#"PRIpaddr", %#"PRIpaddr")\n",
+                   region_start, region_end, i, mod_start, mod_end);
+            return true;
+        }
+    }
+
+    return false;
+}
+
+void __init fw_unreserved_regions(paddr_t s, paddr_t e,
+                                  void (*cb)(paddr_t ps, paddr_t pe),
+                                  unsigned int first)
+{
+    if ( acpi_disabled )
+        dt_unreserved_regions(s, e, cb, first);
+    else
+        cb(s, e);
+}
+
+/*
+ * Given an input physical address range, check if this range is overlapping
+ * with the existing reserved memory regions defined in bootinfo.
+ * Return true if the input physical address range is overlapping with any
+ * existing reserved memory regions, otherwise false.
+ */
+bool __init check_reserved_regions_overlap(paddr_t region_start,
+                                           paddr_t region_size)
+{
+    /* Check if input region is overlapping with bootinfo.reserved_mem banks */
+    if ( meminfo_overlap_check(&bootinfo.reserved_mem,
+                               region_start, region_size) )
+        return true;
+
+    /* Check if input region is overlapping with bootmodules */
+    if ( bootmodules_overlap_check(&bootinfo.modules,
+                                   region_start, region_size) )
+        return true;
+
+#ifdef CONFIG_ACPI
+    /* Check if input region is overlapping with ACPI EfiACPIReclaimMemory */
+    if ( meminfo_overlap_check(&bootinfo.acpi, region_start, region_size) )
+        return true;
+#endif
+
+    return false;
+}
+
+struct bootmodule __init *add_boot_module(bootmodule_kind kind,
+                                          paddr_t start, paddr_t size,
+                                          bool domU)
+{
+    struct bootmodules *mods = &bootinfo.modules;
+    struct bootmodule *mod;
+    unsigned int i;
+
+    if ( mods->nr_mods == MAX_MODULES )
+    {
+        printk("Ignoring %s boot module at %"PRIpaddr"-%"PRIpaddr" (too many)\n",
+               boot_module_kind_as_string(kind), start, start + size);
+        return NULL;
+    }
+
+    if ( check_reserved_regions_overlap(start, size) )
+        return NULL;
+
+    for ( i = 0 ; i < mods->nr_mods ; i++ )
+    {
+        mod = &mods->module[i];
+        if ( mod->kind == kind && mod->start == start )
+        {
+            if ( !domU )
+                mod->domU = false;
+            return mod;
+        }
+    }
+
+    mod = &mods->module[mods->nr_mods++];
+    mod->kind = kind;
+    mod->start = start;
+    mod->size = size;
+    mod->domU = domU;
+
+    return mod;
+}
+
+/*
+ * boot_module_find_by_kind can only be used to return Xen modules (e.g
+ * XSM, DTB) or Dom0 modules. This is not suitable for looking up guest
+ * modules.
+ */
+struct bootmodule * __init boot_module_find_by_kind(bootmodule_kind kind)
+{
+    struct bootmodules *mods = &bootinfo.modules;
+    struct bootmodule *mod;
+    int i;
+    for (i = 0 ; i < mods->nr_mods ; i++ )
+    {
+        mod = &mods->module[i];
+        if ( mod->kind == kind && !mod->domU )
+            return mod;
+    }
+    return NULL;
+}
+
+void __init add_boot_cmdline(const char *name, const char *cmdline,
+                             bootmodule_kind kind, paddr_t start, bool domU)
+{
+    struct bootcmdlines *cmds = &bootinfo.cmdlines;
+    struct bootcmdline *cmd;
+
+    if ( cmds->nr_mods == MAX_MODULES )
+    {
+        printk("Ignoring %s cmdline (too many)\n", name);
+        return;
+    }
+
+    cmd = &cmds->cmdline[cmds->nr_mods++];
+    cmd->kind = kind;
+    cmd->domU = domU;
+    cmd->start = start;
+
+    ASSERT(strlen(name) <= DT_MAX_NAME);
+    safe_strcpy(cmd->dt_name, name);
+
+    if ( strlen(cmdline) > BOOTMOD_MAX_CMDLINE )
+        panic("module %s command line too long\n", name);
+    safe_strcpy(cmd->cmdline, cmdline);
+}
+
+/*
+ * boot_cmdline_find_by_kind can only be used to return Xen modules (e.g
+ * XSM, DTB) or Dom0 modules. This is not suitable for looking up guest
+ * modules.
+ */
+struct bootcmdline * __init boot_cmdline_find_by_kind(bootmodule_kind kind)
+{
+    struct bootcmdlines *cmds = &bootinfo.cmdlines;
+    struct bootcmdline *cmd;
+    int i;
+
+    for ( i = 0 ; i < cmds->nr_mods ; i++ )
+    {
+        cmd = &cmds->cmdline[i];
+        if ( cmd->kind == kind && !cmd->domU )
+            return cmd;
+    }
+    return NULL;
+}
+
+struct bootcmdline * __init boot_cmdline_find_by_name(const char *name)
+{
+    struct bootcmdlines *mods = &bootinfo.cmdlines;
+    struct bootcmdline *mod;
+    unsigned int i;
+
+    for (i = 0 ; i < mods->nr_mods ; i++ )
+    {
+        mod = &mods->cmdline[i];
+        if ( strcmp(mod->dt_name, name) == 0 )
+            return mod;
+    }
+    return NULL;
+}
+
+struct bootmodule * __init boot_module_find_by_addr_and_kind(bootmodule_kind kind,
+                                                             paddr_t start)
+{
+    struct bootmodules *mods = &bootinfo.modules;
+    struct bootmodule *mod;
+    unsigned int i;
+
+    for (i = 0 ; i < mods->nr_mods ; i++ )
+    {
+        mod = &mods->module[i];
+        if ( mod->kind == kind && mod->start == start )
+            return mod;
+    }
+    return NULL;
+}
+
+/*
+ * Return the end of the non-module region starting at s. In other
+ * words return s the start of the next modules after s.
+ *
+ * On input *end is the end of the region which should be considered
+ * and it is updated to reflect the end of the module, clipped to the
+ * end of the region if it would run over.
+ */
+static paddr_t __init next_module(paddr_t s, paddr_t *end)
+{
+    struct bootmodules *mi = &bootinfo.modules;
+    paddr_t lowest = ~(paddr_t)0;
+    int i;
+
+    for ( i = 0; i < mi->nr_mods; i++ )
+    {
+        paddr_t mod_s = mi->module[i].start;
+        paddr_t mod_e = mod_s + mi->module[i].size;
+
+        if ( !mi->module[i].size )
+            continue;
+
+        if ( mod_s < s )
+            continue;
+        if ( mod_s > lowest )
+            continue;
+        if ( mod_s > *end )
+            continue;
+        lowest = mod_s;
+        *end = min(*end, mod_e);
+    }
+    return lowest;
+}
+
+/*
+ * Populate the boot allocator.
+ * If a static heap was not provided by the admin, all the RAM but the
+ * following regions will be added:
+ *  - Modules (e.g., Xen, Kernel)
+ *  - Reserved regions
+ *  - Xenheap (arm32 only)
+ * If a static heap was provided by the admin, populate the boot
+ * allocator with the corresponding regions only, but with Xenheap excluded
+ * on arm32.
+ */
+void __init populate_boot_allocator(void)
+{
+    unsigned int i;
+    const struct meminfo *banks = &bootinfo.mem;
+    paddr_t s, e;
+
+    if ( bootinfo.static_heap )
+    {
+        for ( i = 0 ; i < bootinfo.reserved_mem.nr_banks; i++ )
+        {
+            if ( bootinfo.reserved_mem.bank[i].type != MEMBANK_STATIC_HEAP )
+                continue;
+
+            s = bootinfo.reserved_mem.bank[i].start;
+            e = s + bootinfo.reserved_mem.bank[i].size;
+#ifdef CONFIG_ARM_32
+            /* Avoid the xenheap, note that the xenheap cannot across a bank */
+            if ( s <= mfn_to_maddr(directmap_mfn_start) &&
+                 e >= mfn_to_maddr(directmap_mfn_end) )
+            {
+                init_boot_pages(s, mfn_to_maddr(directmap_mfn_start));
+                init_boot_pages(mfn_to_maddr(directmap_mfn_end), e);
+            }
+            else
+#endif
+                init_boot_pages(s, e);
+        }
+
+        return;
+    }
+
+    for ( i = 0; i < banks->nr_banks; i++ )
+    {
+        const struct membank *bank = &banks->bank[i];
+        paddr_t bank_end = bank->start + bank->size;
+
+        s = bank->start;
+        while ( s < bank_end )
+        {
+            paddr_t n = bank_end;
+
+            e = next_module(s, &n);
+
+            if ( e == ~(paddr_t)0 )
+                e = n = bank_end;
+
+            /*
+             * Module in a RAM bank other than the one which we are
+             * not dealing with here.
+             */
+            if ( e > bank_end )
+                e = bank_end;
+
+#ifdef CONFIG_ARM_32
+            /* Avoid the xenheap */
+            if ( s < mfn_to_maddr(directmap_mfn_end) &&
+                 mfn_to_maddr(directmap_mfn_start) < e )
+            {
+                e = mfn_to_maddr(directmap_mfn_start);
+                n = mfn_to_maddr(directmap_mfn_end);
+            }
+#endif
+
+            fw_unreserved_regions(s, e, init_boot_pages, 0);
+            s = n;
+        }
+    }
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu Mar 14 22:18:03 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 22:18:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693529.1081763 (Exim 4.92)
	(envelope-from )
	id 1rktOk-00059c-8Y; Thu, 14 Mar 2024 22:18:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693529.1081763; Thu, 14 Mar 2024 22:18:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rktOk-00059V-5a; Thu, 14 Mar 2024 22:18:02 +0000
Received: by outflank-mailman (input) for mailman id 693529;
 Thu, 14 Mar 2024 22:18:01 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rktOj-00059B-F3
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 22:18:01 +0000
Received: from sin.source.kernel.org (sin.source.kernel.org
 [2604:1380:40e1:4800::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b60f8269-e250-11ee-a1ee-f123f15fe8a2;
 Thu, 14 Mar 2024 23:17:59 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sin.source.kernel.org (Postfix) with ESMTP id 633D6CE1ED5;
 Thu, 14 Mar 2024 22:17:54 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 74FBBC433F1;
 Thu, 14 Mar 2024 22:17:52 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b60f8269-e250-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1710454673;
	bh=vl19X1L7rDzQ4BQVx8EUyivT3+r6CM4cAn3QKJUqk6Y=;
	h=Date:From:To:cc:Subject:From;
	b=OuxpOOBtBkNrKmhgverxe/H7FYiDK22uyJDhgjEsnvTXK3adRLR2WcnNHaQFVfNeb
	 FcMSaLvZCSjGN2Go0NbxtzF0EWl2IyX0QsgOuw/CBbpXaHcXheS2GoOP8kRA1bD78d
	 xQ37h0h2QNHIihzcmLtloJnd1RSqw1T2z7L+qS6AKZa88uOtyoGUQLqSM9cdAyRvKS
	 G0i8NMLr8xNE1jt2ua6m/Qawe6/c2qOKFqTP5e8qbgKYgNfw470I+rAaob+gqd/Kr7
	 +fID80B3JQpAKDMhUxX3ZW/BX0MYY9uAUTUa1rYpE4eeO4TZZAD3ZpjpaCNh/gFclr
	 5UChpzT6GEkIA==
Date: Thu, 14 Mar 2024 15:17:50 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: xen-devel@lists.xenproject.org
cc: sstabellini@kernel.org, andrew.cooper3@citrix.com, 
    bertrand.marquis@arm.com, george.dunlap@citrix.com, jbeulich@suse.com, 
    julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com
Subject: [PATCH v2] docs/misra: document the expected sizes of integer
 types
Message-ID: 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

Xen makes assumptions about the size of integer types on the various
architectures. Document these assumptions.

Signed-off-by: Stefano Stabellini 
---
Changes in v2:
- add alignment info
---
 docs/misra/C-language-toolchain.rst | 58 +++++++++++++++++++++++++++++
 1 file changed, 58 insertions(+)

diff --git a/docs/misra/C-language-toolchain.rst b/docs/misra/C-language-toolchain.rst
index b7c2000992..24d3c1cac6 100644
--- a/docs/misra/C-language-toolchain.rst
+++ b/docs/misra/C-language-toolchain.rst
@@ -480,4 +480,62 @@ The table columns are as follows:
      - See Section "4.13 Preprocessing Directives" of GCC_MANUAL and Section "11.1 Implementation-defined behavior" of CPP_MANUAL.
 
 
+Sizes of Integer types
+______________________
+
+.. list-table::
+   :widths: 10 10 10 45
+   :header-rows: 1
+
+   * - Type
+     - Size
+     - Alignment
+     - Architectures
+
+   * - char 
+     - 8 bits
+     - 8 bits
+     - all architectures
+
+   * - short
+     - 16 bits
+     - 16 bits
+     - all architectures
+
+   * - int
+     - 32 bits
+     - 32 bits
+     - all architectures
+
+   * - long
+     - 32 bits
+     - 32 bits 
+     - 32-bit architectures (x86_32, ARMv8-A AArch32, ARMv8-R AArch32)
+
+   * - long
+     - 64 bits
+     - 64 bits 
+     - 64-bit architectures (x86_64, ARMv8-A AArch64, RV64, PPC64)
+
+   * - long long
+     - 64-bit
+     - 32-bit
+     - x86_32
+
+   * - long long
+     - 64-bit
+     - 64-bit
+     - 64-bit architectures, ARMv8-A AArch32, ARMv8-R AArch32
+
+   * - pointer
+     - 32-bit
+     - 32-bit
+     - 32-bit architectures (x86_32, ARMv8-A AArch32, ARMv8-R AArch32)
+
+   * - pointer
+     - 64-bit
+     - 64-bit
+     - 64-bit architectures (x86_64, ARMv8-A AArch64, RV64, PPC64)
+
+
 END OF DOCUMENT.
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Thu Mar 14 22:23:39 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 22:23:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693554.1081812 (Exim 4.92)
	(envelope-from )
	id 1rktU7-0000FD-B1; Thu, 14 Mar 2024 22:23:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693554.1081812; Thu, 14 Mar 2024 22:23:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rktU7-0000F6-8C; Thu, 14 Mar 2024 22:23:35 +0000
Received: by outflank-mailman (input) for mailman id 693554;
 Thu, 14 Mar 2024 22:23:33 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rktU5-0000DU-Bs; Thu, 14 Mar 2024 22:23:33 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rktU5-0002pH-AL; Thu, 14 Mar 2024 22:23:33 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rktU4-0005vO-Vh; Thu, 14 Mar 2024 22:23:33 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rktU4-0005qe-VI; Thu, 14 Mar 2024 22:23:32 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=C5CHAXVlTIN3v+f3rIhtEDSlXO9fxU7AMSGDwsMs+4o=; b=iaNL3CfG+9j0SsxnkF7qxKxUCS
	6kK3T1zZcSZ0a6ic7G/k+EngZTin7IgduNjqA2aaHfq5mCMSNDRHqbq++iMC3IIQ3hqi+bKAoWFW7
	2kzvL2lkys3ekKOocex+44BnKpKEmJujdMXWHNrtc6VM1FlZifO8a9c+zsRVrpxfKiH4=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-4.18-testing test] 185032: tolerable FAIL - PUSHED
X-Osstest-Failures:
    xen-4.18-testing:test-armhf-armhf-libvirt-raw:guest-start:fail:heisenbug
    xen-4.18-testing:test-amd64-amd64-xl-qemut-debianhvm-i386-xsm:debian-hvm-install:fail:heisenbug
    xen-4.18-testing:test-arm64-arm64-xl-thunderx:guest-start/debian.repeat:fail:heisenbug
    xen-4.18-testing:test-armhf-armhf-xl-credit1:guest-start/debian.repeat:fail:heisenbug
    xen-4.18-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    xen-4.18-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    xen-4.18-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    xen-4.18-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
    xen-4.18-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-i386-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    xen=4da8ca9cb9cfdb92c9dd09d5270ae16a3b2dbc89
X-Osstest-Versions-That:
    xen=a96d2d4355d85fc82abd0a3799978db04ee8cff3
From: osstest service owner 
Date: Thu, 14 Mar 2024 22:23:32 +0000

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt-raw 13 guest-start      fail in 185020 pass in 185032
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail in 185020 pass in 185032
 test-arm64-arm64-xl-thunderx 18 guest-start/debian.repeat  fail pass in 185020
 test-armhf-armhf-xl-credit1  18 guest-start/debian.repeat  fail pass in 185020

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

version targeted for testing:
 xen                  4da8ca9cb9cfdb92c9dd09d5270ae16a3b2dbc89
baseline version:
 xen                  a96d2d4355d85fc82abd0a3799978db04ee8cff3

Last test of basis   185003  2024-03-12 11:40:22 Z    2 days
Testing same since   185014  2024-03-13 02:53:58 Z    1 days    3 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Roger Pau Monné 

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  fail    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-armhf-armhf-libvirt-qcow2                               pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-libvirt-raw                                  pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 fail    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-arm64-arm64-xl-vhd                                      pass    
 test-armhf-armhf-xl-vhd                                      pass    
 test-amd64-i386-xl-vhd                                       pass    


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

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

Explanation of these 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
   a96d2d4355..4da8ca9cb9  4da8ca9cb9cfdb92c9dd09d5270ae16a3b2dbc89 -> stable-4.18


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 22:56:02 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 22:56:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693564.1081839 (Exim 4.92)
	(envelope-from )
	id 1rktzJ-000803-1q; Thu, 14 Mar 2024 22:55:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693564.1081839; Thu, 14 Mar 2024 22:55:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rktzI-0007zw-Tz; Thu, 14 Mar 2024 22:55:48 +0000
Received: by outflank-mailman (input) for mailman id 693564;
 Thu, 14 Mar 2024 22:55:47 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rktzH-0007zo-4I
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 22:55:47 +0000
Received: from sin.source.kernel.org (sin.source.kernel.org
 [2604:1380:40e1:4800::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id fb51890f-e255-11ee-a1ee-f123f15fe8a2;
 Thu, 14 Mar 2024 23:55:42 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sin.source.kernel.org (Postfix) with ESMTP id 10C6ACE1EC9;
 Thu, 14 Mar 2024 22:55:40 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id EDEC5C433F1;
 Thu, 14 Mar 2024 22:55:37 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: fb51890f-e255-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1710456939;
	bh=WCC3C9KxuL3Vypvc5yL8wz2EW5JuzQWUG8taUiXqK/Y=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=R3a2mHQGDyJ/Ceg6SjucLXadGJTm8Nqv4cWnV/jXgv3+q+KO1dOLQKWRILUH3qkY5
	 LfXYVV5WMBFzzeVVSNUsYnHTBPxBV0EEUheMnHdsQl8Q11lYymS2aC2ACMhQ4HLgRw
	 MQW0sFAXMGAFumn1rE66IwU/beeCNEM/6mzg41uXe09mSUamk4f/uSeECSY+ftNf7t
	 y/65jWtDVAEzyiFaeI7SncCKkTwN3DQ4u+eyY9U9FcWdw1+LDZeTKbSIGl4XjOwB3Q
	 jkenDdYH9HrYGTjY2WgCgc9OTyfkuiuo9qT+G7aY8AwKZA2UH7hr2XTyLo7GZbL6ON
	 3Kr05EuK0URFw==
Date: Thu, 14 Mar 2024 15:55:36 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich 
cc: Simone Ballarin , consulting@bugseng.com, 
    sstabellini@kernel.org, Andrew Cooper , 
    George Dunlap , Julien Grall , 
    Wei Liu , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    xen-devel@lists.xenproject.org
Subject: Re: [XEN PATCH v3 01/16] misra: add deviation for headers that
 explicitly avoid guards
In-Reply-To: 
Message-ID: 
References:  <310fe4a0ccd0ad45bcf1cd9811ac56c9a560dd0b.1710145041.git.simone.ballarin@bugseng.com> 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Mon, 11 Mar 2024, Jan Beulich wrote:
> On 11.03.2024 09:59, Simone Ballarin wrote:
> > Some headers, under specific circumstances (documented in a comment at
> > the beginning of the file), explicitly avoid inclusion guards: the caller
> > is responsible for including them correctly.
> > 
> > These files are not supposed to comply with Directive 4.10:
> > "Precautions shall be taken in order to prevent the contents of a header
> > file being included more than once"
> > 
> > This patch adds deviation cooments for headers that avoid guards.
> > 
> > Signed-off-by: Simone Ballarin 
> > 
> > ---
> > Changes in v3:
> > - fix inconsistent deviation ID
> > - change comment-based deviation text
> > Changes in v2:
> > - use the format introduced with doc/misra/safe.json instead of
> >   a generic text-based deviation
> > ---
> >  docs/misra/safe.json                        | 9 +++++++++
> >  xen/include/public/arch-x86/cpufeatureset.h | 1 +
> >  xen/include/public/errno.h                  | 1 +
> >  3 files changed, 11 insertions(+)
> 
> I understand something wants doing, but having such comments appear in public
> headers feels wrong to me. I'm afraid I have no good alternative suggestion.

Given that in both cases there is very nice explanation on how to use
the headers as an in-code comment just above, could we embed the
SAF-3-safe marker in the existing comment?

If not, I think we should go with this patch as is (I don't think it is
worth my, your, and Simone's time to look for alternatives).


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 22:57:40 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 22:57:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693567.1081850 (Exim 4.92)
	(envelope-from )
	id 1rku15-00007x-HQ; Thu, 14 Mar 2024 22:57:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693567.1081850; Thu, 14 Mar 2024 22:57:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rku15-00007q-Co; Thu, 14 Mar 2024 22:57:39 +0000
Received: by outflank-mailman (input) for mailman id 693567;
 Thu, 14 Mar 2024 22:57:38 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rku14-00007k-MG
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 22:57:38 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 400c3759-e256-11ee-afdd-a90da7624cb6;
 Thu, 14 Mar 2024 23:57:37 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 1EFF761501;
 Thu, 14 Mar 2024 22:57:36 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2FC2EC433F1;
 Thu, 14 Mar 2024 22:57:34 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 400c3759-e256-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1710457055;
	bh=0m1bNOAcoF6TX+7VGMPS2Eeh6UaoS2g1I1NnY0n4LOI=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=VLGS9eYFW35AK9inpfHUskn0HkjJ6x9PGo9p2DYunEapA4G2wP7UsJ7PCmmtIr1xW
	 oyxPVaf7JoAAXU2OyNi0DaKCArCRup4p4CQKX5lOEw+Bm3IffDs0xCekH8sg+9bOQc
	 yimLn2bjzkuP0qEkSCUFeH8AgR6GR13N48pU+Z0AoRKmpKUj4ri0KyuCVCavtQpUv7
	 HJnnQE+PZ/Fb8m8KRX0r/aYDC+H89Rpk79XJkt4RSeKYN28BDvujIOfI0d9DKAuL01
	 ZoSdoCvYge4e+MX94TaaDbo0ZH24pR0V1njny66akZRh0qdjno96Z1ZX8DDw29qdZa
	 WKy8WM1Un4QSg==
Date: Thu, 14 Mar 2024 15:57:32 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Simone Ballarin 
cc: xen-devel@lists.xenproject.org, consulting@bugseng.com, 
    sstabellini@kernel.org, Doug Goldstein , 
    Andrew Cooper , 
    George Dunlap , Jan Beulich , 
    Julien Grall , Wei Liu , 
    Bertrand Marquis , 
    Michal Orzel , 
    Volodymyr Babchuk 
Subject: Re: [XEN PATCH v3 02/16] misra: modify deviations for empty and
 generated headers
In-Reply-To: <8a491f641a8931b6ccc91fca1da6cdfa090c5b36.1710145041.git.simone.ballarin@bugseng.com>
Message-ID: 
References:  <8a491f641a8931b6ccc91fca1da6cdfa090c5b36.1710145041.git.simone.ballarin@bugseng.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Mon, 11 Mar 2024, Simone Ballarin wrote:
> This patch modifies deviations for Directive 4.10:
> "Precautions shall be taken in order to prevent the contents of
> a header file being included more than once"
> 
> This patch avoids the file-based deviation for empty headers, and
> replaces it with a comment-based one using the format specified in
> docs/misra/safe.json.
> 
> Generated headers are not generally safe against multi-inclusions,
> whether a header is safe depends on the nature of the generated code
> in the header. For that reason, this patch drops the deviation for
> generated headers.
> 
> Signed-off-by: Simone Ballarin 

Nice!

Reviewed-by: Stefano Stabellini 


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 22:59:57 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 22:59:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693570.1081860 (Exim 4.92)
	(envelope-from )
	id 1rku3G-00016s-T8; Thu, 14 Mar 2024 22:59:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693570.1081860; Thu, 14 Mar 2024 22:59:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rku3G-00016l-Ow; Thu, 14 Mar 2024 22:59:54 +0000
Received: by outflank-mailman (input) for mailman id 693570;
 Thu, 14 Mar 2024 22:59:53 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rku3F-00016d-5M
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 22:59:53 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org
 [2604:1380:4641:c500::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8fa4d13f-e256-11ee-a1ee-f123f15fe8a2;
 Thu, 14 Mar 2024 23:59:51 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 97D72614BF;
 Thu, 14 Mar 2024 22:59:49 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6856CC433C7;
 Thu, 14 Mar 2024 22:59:47 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8fa4d13f-e256-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1710457189;
	bh=B1m3mkYGtw035NpRvFdVY8FwG6Pi9tCTh0TuZyTNYr4=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=bNXdlUM0GwJpidoKgE1aPU9zpJm/TOBddO1i+i5YJ9ASLfekX/JJzFm5i0CWXK2UJ
	 qNrDSCs7h/VN+zXzuEjtggPKuTeM2PQ6DteE08KInwGf+RjtF3segRSZ6WY0Y//ZC4
	 ZlU8a+s7VjMp4jkIy8m/YHGIQjqSQ82G97jIOcbZjgAdazohRhUpm6TLD4ECn0I3So
	 geDpGbDnX1XpQb8EL6RaPbuyQ268cJAAmZkiX6NqoXDDaeKsy6HC342qz4wu+fAaWd
	 1cUiJZw1FxdPuzD185crLA134CuPubrBDbFkh604LZoQOFkuK2pfJ91DFIuuaSPpTZ
	 qxJrckCIUw2gQ==
Date: Thu, 14 Mar 2024 15:59:45 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Simone Ballarin 
cc: Jan Beulich , consulting@bugseng.com, 
    sstabellini@kernel.org, Andrew Cooper , 
    George Dunlap , Julien Grall , 
    Wei Liu , Bertrand Marquis , 
    Michal Orzel , 
    Volodymyr Babchuk , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    xen-devel@lists.xenproject.org
Subject: Re: [XEN PATCH v3 03/16] misra: add deviations for direct inclusion
 guards
In-Reply-To: <3e4bb597-3624-418e-93d0-b95042fd27a7@bugseng.com>
Message-ID: 
References:  <1fdfec12fd2207c294f50d01d8ec32f890b915d7.1710145041.git.simone.ballarin@bugseng.com>  <6472eb42-157a-4d6e-b5bb-daa74fbbd97b@bugseng.com>
  <3e4bb597-3624-418e-93d0-b95042fd27a7@bugseng.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Mon, 11 Mar 2024, Simone Ballarin wrote:
> On 11/03/24 14:56, Jan Beulich wrote:
> > On 11.03.2024 13:00, Simone Ballarin wrote:
> > > On 11/03/24 11:08, Jan Beulich wrote:
> > > > On 11.03.2024 09:59, Simone Ballarin wrote:
> > > > > --- a/xen/arch/arm/include/asm/hypercall.h
> > > > > +++ b/xen/arch/arm/include/asm/hypercall.h
> > > > > @@ -1,3 +1,4 @@
> > > > > +/* SAF-5-safe direct inclusion guard before */
> > > > >    #ifndef __XEN_HYPERCALL_H__
> > > > >    #error "asm/hypercall.h should not be included directly - include
> > > > > xen/hypercall.h instead"
> > > > >    #endif
> > > > > --- a/xen/arch/x86/include/asm/hypercall.h
> > > > > +++ b/xen/arch/x86/include/asm/hypercall.h
> > > > > @@ -2,6 +2,7 @@
> > > > >     * asm-x86/hypercall.h
> > > > >     */
> > > > >    +/* SAF-5-safe direct inclusion guard before */
> > > > >    #ifndef __XEN_HYPERCALL_H__
> > > > >    #error "asm/hypercall.h should not be included directly - include
> > > > > xen/hypercall.h instead"
> > > > >    #endif
> > > > 
> > > > Iirc it was said that this way checking for correct guards is suppressed
> > > > altogether in Eclair, which is not what we want. Can you clarify this,
> > > > please?
> > > > 
> > > 
> > > My first change was moving this check inside the guard.
> > > You commented my patch saying that this would be an error because someone
> > > can
> > > include it directly if it has already been included indirectly.
> > > I replied telling that this was the case also before the change.
> > > You agreed with me, and we decided that the correct thing would be fixing
> > > the
> > > check and not apply my temporary change to address the finding.
> > > 
> > > Considering that the code should be amended, a SAF deviation seems to me
> > > the most appropriate way for suppressing these findings.
> > 
> > Since I don't feel your reply addresses my question, asking differently:
> > With
> > your change in place, will failure to have proper guards (later) in these
> > headers still be reported by Eclair?
> > 
> > Jan
> > 
> 
> No, if you put something between the check and the guard,
> no violation will be reported.

>From this email exchange I cannot under if Jan is OK with this patch or
not.


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 23:02:17 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 23:02:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693572.1081869 (Exim 4.92)
	(envelope-from )
	id 1rku5W-00033J-88; Thu, 14 Mar 2024 23:02:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693572.1081869; Thu, 14 Mar 2024 23:02:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rku5W-00033C-5Z; Thu, 14 Mar 2024 23:02:14 +0000
Received: by outflank-mailman (input) for mailman id 693572;
 Thu, 14 Mar 2024 23:02:13 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rku5V-000334-0T
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 23:02:13 +0000
Received: from sin.source.kernel.org (sin.source.kernel.org
 [2604:1380:40e1:4800::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e28f46d8-e256-11ee-a1ee-f123f15fe8a2;
 Fri, 15 Mar 2024 00:02:10 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sin.source.kernel.org (Postfix) with ESMTP id 7D23DCE1DC3;
 Thu, 14 Mar 2024 23:02:06 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id A0611C433C7;
 Thu, 14 Mar 2024 23:02:04 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e28f46d8-e256-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1710457325;
	bh=IEDZIjOiDUXTJ1Fjsb9V8MUfaaWeGYJ907oOVLUHUnA=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=od+D6HnmAKhG+HE0th8QcmNvBa7UPnQ1AqSUXTNSbw2YmC2nSBO5x4abI4QqMStnx
	 pNerSYwdWlArfn/W4xTbhFF2uyVvpno9HAhrhvLubXCy2wWZF5jS1w4BJ/aaseyiGC
	 4c+CoCcrFkuh8aKylQgxmRqmgNBWX2XJ+CsbBbOeY62iy8c/Wb4ol50sa8JPT6vvV2
	 B7onDSL4wEfDZtGhVpz9pf+QduRGwDE10WHnQMYkt4+RwlKt45ymxYPKhXopGrzdwH
	 MJTgCh05vph9Z0m+n/NGbZRJlyPtj4h2duhxZAMvrNJK31s+X9IAX3fLuRHiCm9ATz
	 yi7KdBfv1fTsw==
Date: Thu, 14 Mar 2024 16:02:02 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Simone Ballarin 
cc: xen-devel@lists.xenproject.org, consulting@bugseng.com, 
    sstabellini@kernel.org, Jan Beulich , 
    Andrew Cooper , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Wei Liu , 
    Maria Celeste Cesario 
Subject: Re: [XEN PATCH v3 06/16] x86/EFI: address violations of MISRA C:2012
 Directive 4.10
In-Reply-To: 
Message-ID: 
References:  
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Mon, 11 Mar 2024, Simone Ballarin wrote:
> Add inclusion guard to address violations of
> MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order
> to prevent the contents of a header file being included more than
> once").
> 
> Mechanical change.
> 
> Signed-off-by: Simone Ballarin 
> Signed-off-by: Maria Celeste Cesario 

Reviewed-by: Stefano Stabellini 


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 23:04:07 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 23:04:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693574.1081879 (Exim 4.92)
	(envelope-from )
	id 1rku7K-00041m-JN; Thu, 14 Mar 2024 23:04:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693574.1081879; Thu, 14 Mar 2024 23:04:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rku7K-00041f-Gh; Thu, 14 Mar 2024 23:04:06 +0000
Received: by outflank-mailman (input) for mailman id 693574;
 Thu, 14 Mar 2024 23:04:05 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rku7J-00041Z-4N
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 23:04:05 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 260374c5-e257-11ee-a1ee-f123f15fe8a2;
 Fri, 15 Mar 2024 00:04:03 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id F1456614F5;
 Thu, 14 Mar 2024 23:04:01 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 67891C433C7;
 Thu, 14 Mar 2024 23:04:00 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 260374c5-e257-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1710457441;
	bh=6dWZ92S77NIaPaF6pnS10UM1Y6AVRRCICA/VozF5tsM=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=mP8HauQ9rwt21jpgUZL8gG1ADBvtEGqbwDNUluzR5ODyEUOab3/DOLNJtu2KJtaUz
	 /1wpQjZF2FS8wWojaJODBo920cmzjDoxwKjwNVHrmcIvZKwDQE2/w94jmv8vy+Z/aZ
	 KqZQfEsy3vazqxJxkmMNMRWmmQATqCdeemvr50DdwPt0pxuR4P+6SKUqRzhP+cPoc/
	 NCZ6ttbuDVNgCPLrDkCwdzvIdjgvcGYmvhpXRK/QVcWL0cEqFtI1pnERfdyGGBOAej
	 vEMyyz9k2RPUhsC9FC+0bol0TAAyQXAsr4myGFz1LGnghYg5tq2U+UZJQHJKFLtt/t
	 2Pckz1khajdcw==
Date: Thu, 14 Mar 2024 16:03:58 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Simone Ballarin 
cc: xen-devel@lists.xenproject.org, consulting@bugseng.com, 
    sstabellini@kernel.org, Andrew Cooper , 
    George Dunlap , Jan Beulich , 
    Julien Grall , Wei Liu , 
    Maria Celeste Cesario 
Subject: Re: [XEN PATCH v3 07/16] xen/common: address violations of MISRA
 C:2012 Directive 4.10
In-Reply-To: 
Message-ID: 
References:  
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Mon, 11 Mar 2024, Simone Ballarin wrote:
> Add inclusion guards to address violations of
> MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order
> to prevent the contents of a header file being included more than
> once").
> 
> Mechanical change.
> 
> Signed-off-by: Simone Ballarin 
> Signed-off-by: Maria Celeste Cesario  

Reviewed-by: Stefano Stabellini 


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 23:04:35 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 23:04:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693576.1081889 (Exim 4.92)
	(envelope-from )
	id 1rku7m-0004W0-RY; Thu, 14 Mar 2024 23:04:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693576.1081889; Thu, 14 Mar 2024 23:04:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rku7m-0004Vr-OD; Thu, 14 Mar 2024 23:04:34 +0000
Received: by outflank-mailman (input) for mailman id 693576;
 Thu, 14 Mar 2024 23:04:33 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rku7l-00041Z-L4
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 23:04:33 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 36e9e5aa-e257-11ee-a1ee-f123f15fe8a2;
 Fri, 15 Mar 2024 00:04:31 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 4E2B4615FC;
 Thu, 14 Mar 2024 23:04:30 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 38782C433C7;
 Thu, 14 Mar 2024 23:04:29 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 36e9e5aa-e257-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1710457470;
	bh=6dWZ92S77NIaPaF6pnS10UM1Y6AVRRCICA/VozF5tsM=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=ghtNwoDZ9faIancOHFAR5AQNlH2e5ESo/5lTvAdMb0pTvn3rB4i3JnhNjXku5hwVx
	 XCKccQLrkjEDdv42pnmU76cZs71+tWtfsc8AMO9Kjp+odc2HhtZwxOwlDq5J6AjQ9L
	 K1NKIK90+HPPcmjXhciYWblSKWsYUIPpje6c57jwBPltHFhguyuiXPfZFFnQ21mdkz
	 wYJk358fHuRsuar9juvu2+kRZJCiKdpy72lXkQQywJ4S61Fty8FIkKQBeF6LdXtrhq
	 GFxqcDl7SRTimgazeGCMcCxieKP5Qzdht6XRC1mCmRL9bmmmooLvvxypi9bKKnz5QQ
	 koe560MZlTbNA==
Date: Thu, 14 Mar 2024 16:04:27 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Simone Ballarin 
cc: xen-devel@lists.xenproject.org, consulting@bugseng.com, 
    sstabellini@kernel.org, Jan Beulich , 
    Maria Celeste Cesario 
Subject: Re: [XEN PATCH v3 08/16] xen/efi: address violations of MISRA C:2012
 Directive 4.10
In-Reply-To: 
Message-ID: 
References:  
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Mon, 11 Mar 2024, Simone Ballarin wrote:
> Add inclusion guards to address violations of
> MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order
> to prevent the contents of a header file being included more than
> once").
> 
> Mechanical change.
> 
> Signed-off-by: Simone Ballarin 
> Signed-off-by: Maria Celeste Cesario  

Reviewed-by: Stefano Stabellini 


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 23:07:48 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 23:07:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693580.1081898 (Exim 4.92)
	(envelope-from )
	id 1rkuAo-00059T-7b; Thu, 14 Mar 2024 23:07:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693580.1081898; Thu, 14 Mar 2024 23:07:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkuAo-00059M-4g; Thu, 14 Mar 2024 23:07:42 +0000
Received: by outflank-mailman (input) for mailman id 693580;
 Thu, 14 Mar 2024 23:07:41 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkuAn-00059F-1c
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 23:07:41 +0000
Received: from sin.source.kernel.org (sin.source.kernel.org
 [2604:1380:40e1:4800::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a6ac9d99-e257-11ee-afdd-a90da7624cb6;
 Fri, 15 Mar 2024 00:07:39 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sin.source.kernel.org (Postfix) with ESMTP id 6577BCE1F0A;
 Thu, 14 Mar 2024 23:07:35 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 98200C433F1;
 Thu, 14 Mar 2024 23:07:32 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a6ac9d99-e257-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1710457653;
	bh=WKCV4XpqhurLaxE36e/z1suFrUlXoAsYCrCXD2m4XR4=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=TJK2vh/159ZEUjmrq+OiMH5/jluO3cevtmBrlt0ch+hrd3KLUTOTMYYfxVCgkqrrL
	 h7fEmnsW+4OrpjwbvS/ipw4P6n169F2G45wMclFjp2e8kg4yzhIqOVbV9NFdvIZgpm
	 v8NgGYJxYyYXceiXP1uuBCtdWKDalch5cHQCGMHEgGoGmeQL7A9ye8Gi1D1KZI5+SY
	 Zfw56dWjE9Ne8RS+zE0T5OLgo9CTFYIDTietrfdPwZZzV5Sntj+bsSth4JzUodsQNi
	 6AyFNbLN387Cyb18rUtEBMjzHNkD9Ii1qQ8c3akoznSUaIkJRxs1mjXtCL9xlBsJC3
	 dHhVeCDfsCDZw==
Date: Thu, 14 Mar 2024 16:07:31 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Simone Ballarin 
cc: xen-devel@lists.xenproject.org, consulting@bugseng.com, 
    sstabellini@kernel.org, Andrew Cooper , 
    George Dunlap , Jan Beulich , 
    Julien Grall , Wei Liu , 
    Maria Celeste Cesario 
Subject: Re: [XEN PATCH v3 09/16] xen: address violations of MISRA C:2012
 Directive 4.10
In-Reply-To: <504cdd2a0f27d28e0a87492f75476b123b68bbc0.1710145041.git.simone.ballarin@bugseng.com>
Message-ID: 
References:  <504cdd2a0f27d28e0a87492f75476b123b68bbc0.1710145041.git.simone.ballarin@bugseng.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Mon, 11 Mar 2024, Simone Ballarin wrote:
> Amend inclusion guards to address violations of
> MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order
> to prevent the contents of a header file being included more than
> once").
> 
> Inclusion guards must appear at the beginning of the headers
> (comments are permitted anywhere) and the #if directive cannot
> be used for other checks.
> 
> Mechanical change.
> 
> Signed-off-by: Simone Ballarin  
> Signed-off-by: Maria Celeste Cesario  

Reviewed-by: Stefano Stabellini 


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 23:12:16 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 23:12:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693586.1081909 (Exim 4.92)
	(envelope-from )
	id 1rkuFC-0007IV-OI; Thu, 14 Mar 2024 23:12:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693586.1081909; Thu, 14 Mar 2024 23:12:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkuFC-0007IO-Kt; Thu, 14 Mar 2024 23:12:14 +0000
Received: by outflank-mailman (input) for mailman id 693586;
 Thu, 14 Mar 2024 23:12:13 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkuFB-0007II-Q0
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 23:12:13 +0000
Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 489ac700-e258-11ee-a1ee-f123f15fe8a2;
 Fri, 15 Mar 2024 00:12:11 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sin.source.kernel.org (Postfix) with ESMTP id 2DF3ACE098E;
 Thu, 14 Mar 2024 23:12:09 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4FBE2C433F1;
 Thu, 14 Mar 2024 23:12:07 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 489ac700-e258-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1710457928;
	bh=LMARwQlxMkZVBwCLM64CBOpXAaLcHbY5bm9BforpgYo=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=KdCrPvxRqJTnkO4aGQIFJMzcP8sq3itDt2onCS3xt6NBu5NJFYPSNtjcsgDKWl8qb
	 TIe7SxouLdqGQ0OmsUOT2hjzjJS5vr1UDgBD3UVKSkq+FkS5WSoSL2P1z6CAdVCHpW
	 4M2gF/+0rFcWq7X0YPGNn07VrM1qZ40i+3olnKtNIEVxDobLvLATBKjffilM7f9wwy
	 N/zaybJarCYtqWK4a6cKEbuNc+gd8EUaoFJv0Qir6tj2oGHlUZePsMgnMLn3JonfeO
	 tnIlPyY0cU66Wai5BOgLx4XlQxp1Pi8ZJqxwvPbRkvmoS0KLQNFXqBSNj+FV1jM7cW
	 mR/iP0fkCX7LA==
Date: Thu, 14 Mar 2024 16:12:05 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Simone Ballarin 
cc: xen-devel@lists.xenproject.org, consulting@bugseng.com, 
    sstabellini@kernel.org, 
    Maria Celeste Cesario , 
    Julien Grall , Bertrand Marquis , 
    Michal Orzel , 
    Volodymyr Babchuk 
Subject: Re: [XEN PATCH v3 11/16] xen/arm: address violations of MISRA C:2012
 Directive 4.10
In-Reply-To: 
Message-ID: 
References:  
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Mon, 11 Mar 2024, Simone Ballarin wrote:
> From: Maria Celeste Cesario 
> 
> Add or modify inclusion guards to address violations of
> MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order to
> prevent the contents of a header file being included more than once").
> Mechanical change.
> ---
> Commit introduced in v3
> 
> Signed-off-by: Maria Celeste Cesario  
> Signed-off-by: Simone Ballarin  
> ---
>  xen/arch/arm/include/asm/domain.h      | 6 +++---
>  xen/arch/arm/include/asm/efibind.h     | 5 +++++
>  xen/arch/arm/include/asm/event.h       | 6 +++---
>  xen/arch/arm/include/asm/grant_table.h | 6 +++---
>  xen/arch/arm/include/asm/io.h          | 6 +++---
>  xen/arch/arm/include/asm/irq.h         | 6 +++---
>  xen/arch/arm/include/asm/smp.h         | 6 +++---
>  xen/arch/arm/include/asm/spinlock.h    | 6 +++---
>  xen/arch/arm/include/asm/system.h      | 6 +++---
>  9 files changed, 29 insertions(+), 24 deletions(-)
> 
> diff --git a/xen/arch/arm/include/asm/domain.h b/xen/arch/arm/include/asm/domain.h
> index 8218afb862..b7dc023a25 100644
> --- a/xen/arch/arm/include/asm/domain.h
> +++ b/xen/arch/arm/include/asm/domain.h
> @@ -1,5 +1,5 @@
> -#ifndef __ASM_DOMAIN_H__
> -#define __ASM_DOMAIN_H__
> +#ifndef ASM_ARM_DOMAIN_H
> +#define ASM_ARM_DOMAIN_H
>  
>  #include 
>  #include 
> @@ -312,7 +312,7 @@ static inline void update_guest_memory_policy(struct vcpu *v,
>                                                struct guest_memory_policy *gmp)
>  {}
>  
> -#endif /* __ASM_DOMAIN_H__ */
> +#endif /* ASM_ARM_DOMAIN_H */
>  
>  /*
>   * Local variables:
> diff --git a/xen/arch/arm/include/asm/efibind.h b/xen/arch/arm/include/asm/efibind.h
> index 09dca7a8c9..689bf63232 100644
> --- a/xen/arch/arm/include/asm/efibind.h
> +++ b/xen/arch/arm/include/asm/efibind.h
> @@ -1,2 +1,7 @@
> +#ifndef ASM_ARM_EFI_BIND_H

This should be ASM_ARM_EFIBIND_H ?

Everything else looks fine to me


From xen-devel-bounces@lists.xenproject.org Thu Mar 14 23:20:07 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Mar 2024 23:20:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693590.1081919 (Exim 4.92)
	(envelope-from )
	id 1rkuMi-0001AK-GU; Thu, 14 Mar 2024 23:20:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693590.1081919; Thu, 14 Mar 2024 23:20:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkuMi-0001AD-CG; Thu, 14 Mar 2024 23:20:00 +0000
Received: by outflank-mailman (input) for mailman id 693590;
 Thu, 14 Mar 2024 23:19:59 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkuMh-00017Z-CG
 for xen-devel@lists.xenproject.org; Thu, 14 Mar 2024 23:19:59 +0000
Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5e1dff92-e259-11ee-a1ee-f123f15fe8a2;
 Fri, 15 Mar 2024 00:19:57 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sin.source.kernel.org (Postfix) with ESMTP id 48C5FCE1E30;
 Thu, 14 Mar 2024 23:19:51 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0A708C433C7;
 Thu, 14 Mar 2024 23:19:48 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5e1dff92-e259-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1710458390;
	bh=Pv+dE59ggmG2qzf7R1Dkckr9mrK1X/YubGJWg8w3XKs=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=nk8rICd7sv5rPm+KRPmjDQpAjFTYtHZizlZSnAALeIYw+5a0Nrt9so5LQHJ+LqALX
	 LfAo7vrBCVqLJRV0K3bVsqMJlnwK0ZZi/dxO8Hs5DtX8DkyyiAgtjIrgEWyVBKbOrk
	 Eyo79IkuzaSxyYOKxkbB1bBmmuWIYHmbseP6RWHMcoIg/WdTuI5zqnqXNdwDwJWjiC
	 EXg/qLEorw4eFHkwA2xAt3q+IkcdQ6AWk0W5FFBZP829CPP7KdK1qPxIl3zRGEEsxq
	 UDk5UeJvQ/fW+rUuFLnp0FKDE3KV6HdgzDsroCDOhcV0miyoFQ6zriOGVjnhCAOtYe
	 BuOuuFeT/bJvw==
Date: Thu, 14 Mar 2024 16:19:47 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich 
cc: Simone Ballarin , consulting@bugseng.com, 
    sstabellini@kernel.org, xen-devel@lists.xenproject.org, 
    Maria Celeste Cesario , 
    Andrew Cooper , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Wei Liu 
Subject: Re: [XEN PATCH v3 14/16] xen/x86: address violations of MISRA C:2012
 Directive 4.10
In-Reply-To: <7a9d46bb-e231-4b1a-a60c-62905e6cc1cc@suse.com>
Message-ID: 
References:  <305d6474a84e16d44c193a93e2c2ca91d6dd0f7e.1710145041.git.simone.ballarin@bugseng.com> <7a9d46bb-e231-4b1a-a60c-62905e6cc1cc@suse.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Tue, 12 Mar 2024, Jan Beulich wrote:
> On 11.03.2024 09:59, Simone Ballarin wrote:
> > From: Maria Celeste Cesario 
> > 
> > Edit inclusion guards to address violations of
> > MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order to
> > prevent the contents of a header file being included more than once").
> > Mechanical change.
> 
> The changes all follow a single pattern, yet I'm afraid I can't bring
> this pattern in line with this description. To take ...
> 
> > --- a/xen/arch/x86/include/asm/domain.h
> > +++ b/xen/arch/x86/include/asm/domain.h
> > @@ -1,5 +1,5 @@
> > -#ifndef __ASM_DOMAIN_H__
> > -#define __ASM_DOMAIN_H__
> > +#ifndef ASM_X86_DOMAIN_H
> > +#define ASM_X86_DOMAIN_H
> >  
> >  #include 
> >  #include 
> > @@ -780,7 +780,7 @@ struct arch_vcpu_io {
> >  /* Maxphysaddr supportable by the paging infrastructure. */
> >  unsigned int domain_max_paddr_bits(const struct domain *d);
> >  
> > -#endif /* __ASM_DOMAIN_H__ */
> > +#endif /* ASM_X86_DOMAIN_H */
> 
> ... this as example - what's the violation here? The existing symbol
> provides the intended effect, doesn't it? What it does not is adhere
> to the new naming scheme, but there's no mention of that in the
> description.

I think the commit message is incorrect. As you pointed out there is no
underlying MISRA issue. However, it does bring the headers inline with
the new naming scheme, which I think it is a great improvement.

With the commit message improved:

Reviewed-by: Stefano Stabellini 


From xen-devel-bounces@lists.xenproject.org Fri Mar 15 00:22:13 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 00:22:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693595.1081929 (Exim 4.92)
	(envelope-from )
	id 1rkvKf-00081f-Iq; Fri, 15 Mar 2024 00:21:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693595.1081929; Fri, 15 Mar 2024 00:21:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkvKf-00081Y-Fm; Fri, 15 Mar 2024 00:21:57 +0000
Received: by outflank-mailman (input) for mailman id 693595;
 Fri, 15 Mar 2024 00:21:55 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkvKd-00081K-UL
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 00:21:55 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 04ac73f9-e262-11ee-a1ee-f123f15fe8a2;
 Fri, 15 Mar 2024 01:21:51 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 6120C61569;
 Fri, 15 Mar 2024 00:21:50 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id BE163C433F1;
 Fri, 15 Mar 2024 00:21:48 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 04ac73f9-e262-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1710462110;
	bh=Y+B7WoTj0l9eRXufxNLznT/NkIcc3pWkJu4toqxmkVA=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=Gd/MwbfHG9qhXLyUyKunmCrZaDdBK0UF93pgWe9ZvF+XbsaMlH/XEcMf/kjAYiOM3
	 V8zU+B4TrBECTpMaE2PzzFdcajS2TSyi7pBLUGgNANMwEoHkWcJip/BUCZbKHlAurv
	 inr4nXjJamoig68hde6UQASNvXxDL/QxdWC2VaDq9l3Kq2BkvN/m1pDjyC2GrQZjr7
	 xVEH8HAC36FYqpRRT9WIZvFbQj7sTdDMJxeRAQBW3Q8glv4KRI6B1yHOmS4EeyBSAD
	 BWZMhhOuXK0scxRm3vFpP4ePTY0jsgBjGSAJkBhgebOPgBq0WKQRywjm2CiPDLTpn8
	 uoOOg08kRDtrA==
Date: Thu, 14 Mar 2024 17:21:46 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: jbeulich@suse.com
cc: George Dunlap , 
    Stefano Stabellini , federico.serafini@bugseng.com, 
    Andrew Cooper , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Bertrand Marquis , 
    xen-devel@lists.xenproject.org, michal.orzel@amd.com, julien@xen.org
Subject: Re: [PATCH] do_multicall and MISRA Rule 8.3\
In-Reply-To: 
Message-ID: 
References:  <5a8f90d6-6502-4d93-9fd7-45fea0ede24a@suse.com>  
 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="8323329-1508082843-1710461585=:853156"
Content-ID: 

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-1508082843-1710461585=:853156
Content-Type: text/plain; CHARSET=UTF-8
Content-Transfer-Encoding: 8BIT
Content-ID: 

On Mon, 11 Mar 2024, Julien Grall wrote:
> On 11/03/2024 11:32, George Dunlap wrote:
> > On Sat, Mar 9, 2024 at 1:59 AM Stefano Stabellini
> >  wrote:
> > > 
> > > I would like to resurrect this thread and ask other opinions.
> > > 
> > > 
> > > On Thu, 23 Nov 2023, Jan Beulich wrote:
> > > > On 22.11.2023 22:46, Stefano Stabellini wrote:
> > > > > Two out of three do_multicall definitions/declarations use uint32_t as
> > > > > type for the "nr_calls" parameters. Change the third one to be
> > > > > consistent with the other two.
> > > > > 
> > > > > Link:
> > > > > https://lore.kernel.org/xen-devel/7e3abd4c0ef5127a07a60de1bf090a8aefac8e5c.1692717906.git.federico.serafini@bugseng.com/
> > > > > Link:
> > > > > https://lore.kernel.org/xen-devel/alpine.DEB.2.22.394.2308251502430.6458@ubuntu-linux-20-04-desktop/
> > > > > Signed-off-by: Stefano Stabellini 
> > > > > ---
> > > > > Note that a previous discussion showed disagreement between
> > > > > maintainers
> > > > > on this topic. The source of disagreements are that we don't want to
> > > > > change a guest-visible ABI and we haven't properly documented how to
> > > > > use
> > > > > types for guest ABIs.
> > > > > 
> > > > > As an example, fixed-width types have the advantage of being explicit
> > > > > about their size but sometimes register-size types are required (e.g.
> > > > > unsigned long). The C specification says little about the size of
> > > > > unsigned long and today, and we even use unsigned int in guest ABIs
> > > > > without specifying the expected width of unsigned int on the various
> > > > > arches. As Jan pointed out, in Xen we assume sizeof(int) >= 4, but
> > > > > that's not written anywhere as far as I can tell.
> > > > > 
> > > > > I think the appropriate solution would be to document properly our
> > > > > expectations of both fixed-width and non-fixed-width types, and how to
> > > > > use them for guest-visible ABIs.
> > > > > 
> > > > > In this patch I used uint32_t for a couple of reasons:
> > > > > - until we have better documentation, I feel more confident in using
> > > > >    explicitly-sized integers in guest-visible ABIs
> > > > 
> > > > I disagree with this way of looking at it. Guests don't invoke these
> > > > functions directly, and our assembly code sitting in between already is
> > > > expected to (and does) guarantee that (in the case here) unsigned int
> > > > would be okay to use (as would be unsigned long, but at least on x86
> > > > that's slightly less efficient), in line with what ./CODING_STYLE says.
> > > > 
> > > > Otoh structure definitions in the public interface of course need to
> > > > use fixed with types (and still doesn't properly do so in a few cases).
> > 
> > You didn't address the other argument, which was that all the other
> > definitions have uint32_t; in particular,
> > common/multicall.c:do_multicall() takes uint32_t.  Surely that should
> > match the non-compat definition in include/hypercall-defs.c?
> > 
> > Whether they should both be `unsigned int` or `uint32_t` I don't
> > really feel like I have a good enough grasp of the situation to form a
> > strong opinion.
> 
> FWIW +1. We at least need some consistency.

Consistency is my top concern. Let's put the "unsigned int" vs
"uint32_t" argument aside.

do_multicall is not consistent with itself. We need
hypercall-defs.c:do_multicall and multicall.c:do_multicall to match.

Option1) We can change hypercall-defs.c:do_multicall to use uint32_t.

Option2) Or we can change multicall.c:do_multicall to use unsigned int.

I went with Option1. Andrew expressed his strong preference toward
Option1 in the past. George seems to prefer Option1.

Jan, can you accept Option1 and move on?
--8323329-1508082843-1710461585=:853156--


From xen-devel-bounces@lists.xenproject.org Fri Mar 15 00:35:18 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 00:35:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693600.1081945 (Exim 4.92)
	(envelope-from )
	id 1rkvXU-0002Cv-Nb; Fri, 15 Mar 2024 00:35:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693600.1081945; Fri, 15 Mar 2024 00:35:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkvXU-0002Co-Kv; Fri, 15 Mar 2024 00:35:12 +0000
Received: by outflank-mailman (input) for mailman id 693600;
 Fri, 15 Mar 2024 00:35:11 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rkvXT-0002Cc-Aq
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 00:35:11 +0000
Received: from sin.source.kernel.org (sin.source.kernel.org
 [2604:1380:40e1:4800::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id dfcce535-e263-11ee-afdd-a90da7624cb6;
 Fri, 15 Mar 2024 01:35:09 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sin.source.kernel.org (Postfix) with ESMTP id 53B23CE1F0B;
 Fri, 15 Mar 2024 00:35:07 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 72127C433C7;
 Fri, 15 Mar 2024 00:35:05 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: dfcce535-e263-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1710462906;
	bh=0w+MdDqKlm43yhbmnOm/SBn6kayFfUY9JQ+jwjYZNAk=;
	h=Date:From:To:cc:Subject:From;
	b=EgCvpnQJ1arwCbQPhXpdsbADIVI4MCkiD8gkG4tsuJSTaj+zwpMpoN0BU4zxeaR9W
	 olKBXyPS+ChghFa3dJ3flEnw4bu/vXJPlbP3BJEbfwhuCsQxQKhqZrdUIv+j/Ndo3Q
	 HKzL0tquheXnBca2RBeNkP7O7QDEXphcj3umw28H5jjkKtfa6FVG9S3BtiEMW+6pQ5
	 D9UdIzDqh+HilkC8ufi1JxtgRjTRE+MtoPQhhDxX2SaXY5a98sfhiU8LBBLusWZgzm
	 1oywlRQsrdeVzprEy5nS1+UW+3aJ1zIEBuZYZjuXafxCxeZedQsjmA7QYZUyIBQOXQ
	 LvR4NZmwt1/xA==
Date: Thu, 14 Mar 2024 17:35:03 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: xen-devel@lists.xenproject.org
cc: andrew.cooper3@citrix.com, bertrand.marquis@arm.com, 
    george.dunlap@citrix.com, jbeulich@suse.com, julien@xen.org, 
    michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org
Subject: [PATCH v3] docs/misra/rules.rst: add rule 5.5
Message-ID: 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

Signed-off-by: Stefano Stabellini 
---
Changes in v3:
- better clarify what is allowed and not allowed with examples
---
 docs/misra/rules.rst | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst
index 1e134ccebc..5766b2286d 100644
--- a/docs/misra/rules.rst
+++ b/docs/misra/rules.rst
@@ -181,6 +181,21 @@ maintainers if you want to suggest a change.
        headers (xen/include/public/) are allowed to retain longer
        identifiers for backward compatibility.
 
+   * - `Rule 5.5 `_
+     - Required
+     - Identifiers shall be distinct from macro names
+     - Macros expanding to their own name are allowed, e.g.::
+
+           #define x x
+
+       Clashes between names of function-like macros and identifiers of
+       non-callable entities are allowed. Callable entities having an
+       identifier that is the same of the name of a
+       function-like macro are not allowed. Example (not allowed)::
+
+           #define f(x, y) f(x, y);
+           void f(int x, int y);
+
    * - `Rule 5.6 `_
      - Required
      - A typedef name shall be a unique identifier
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Fri Mar 15 03:50:30 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 03:50:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693617.1081955 (Exim 4.92)
	(envelope-from )
	id 1rkyaH-0001Zb-6t; Fri, 15 Mar 2024 03:50:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693617.1081955; Fri, 15 Mar 2024 03:50:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkyaH-0001ZU-2q; Fri, 15 Mar 2024 03:50:17 +0000
Received: by outflank-mailman (input) for mailman id 693617;
 Fri, 15 Mar 2024 03:50:16 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkyaG-0001ZO-22
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 03:50:16 +0000
Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com
 [2a00:1450:4864:20::22d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 211d6595-e27f-11ee-afdd-a90da7624cb6;
 Fri, 15 Mar 2024 04:50:14 +0100 (CET)
Received: by mail-lj1-x22d.google.com with SMTP id
 38308e7fff4ca-2d23114b19dso18825271fa.3
 for ; Thu, 14 Mar 2024 20:50:14 -0700 (PDT)
Received: from localhost (118-168-133-24.dynamic-ip.hinet.net.
 [118.168.133.24]) by smtp.gmail.com with ESMTPSA id
 i13-20020a17090adc0d00b0029d7e7b7b41sm1790580pjv.33.2024.03.14.20.50.12
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 14 Mar 2024 20:50:12 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 211d6595-e27f-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710474613; x=1711079413; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=LH65GpFfZfh9n5rXs2As6F9rQE3oOpUCSwLIKwpAmQc=;
        b=gFTPuFLOjLU2bSLNBNC9fKIC9aFdPKsYuNpo7bOPRr6E9NsTOTSl2koNVzoVvwgne4
         wmNnmKO67go7DdTD7cduBkqdvfsAmnDkF48HZ98Ftov8Iovrr2MzLddWXEwJF75rAocj
         h8fMfC/Qu+CpOvPA0QFA6gaxtkTkNfbvWAJSDyXUGguihmaHbb0ZJBsSKYO24FZIAhdO
         D39Oxa9+gtK2L4MtSq7e93ZX6PP0A1dPWAvihAD7PcIlwOJZRzL6nFZc42m6xwmVAlYP
         B3xdEO1S/9oBvqGOpclG9qGeBfT+Be/GU+rGq4sH6+pNxJuh2GStJ9Nf7xModlIFXCjb
         ug0w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710474613; x=1711079413;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=LH65GpFfZfh9n5rXs2As6F9rQE3oOpUCSwLIKwpAmQc=;
        b=mBSrRFwpEcCiytYpRhJRKqahAqH32z3QQ8s0yRajitXY4WK8UauZsquf+jCOdb89/3
         7EPg7oMkEF5gZ+2Sh3IoQse+uITE5B57w96qLILb9a2nxyWfvv9hCmyDM5JrR6w0L+1+
         3ENwAju+Dngby2Q61uawwu/bSC7kpHUY9yqGTEShxo59svOV4XQ1kR0IH+hZMl0EtLDT
         eigFRyozyp3JbHShRf3Vm8TleZQVLkjh28+OwmJH2bbYO7G8uwibMWdykkpYAbjGliVS
         3DM+uAScgHxDPws7b/QnBVG9a5IlT1MK5mvFST8Va0uadUQMAw9iF1xGJn8OZb0w+yfr
         KhJA==
X-Forwarded-Encrypted: i=1; AJvYcCWtOfH9kd1eStHKheXRcf1bVYY2M9qwbhXkPpvGSEZGQesdYcpaVHusPuKjU55YrPv9jX22x//jIxvsFiRMey6uSs9SrthDqeDzxzd0l5s=
X-Gm-Message-State: AOJu0Ywyjfkp3OeODdACQEtdVsaO40GRheh6B2pT0LPHSyiBDgZUYDUA
	eIICM6tqIFJT/KlvxHv3K25deJs7x6tFszFErDf++03Fc2EpRRvgt9DFHCsgSgs=
X-Google-Smtp-Source: AGHT+IEq3tVOLhlUQiCv41fV74AdfW2juh5e4eOSkOah1RAieQfpEouDeuWmQPqYy21HZlqdLoMotg==
X-Received: by 2002:a05:651c:10c9:b0:2d2:2ce1:1196 with SMTP id l9-20020a05651c10c900b002d22ce11196mr2308729ljn.53.1710474613439;
        Thu, 14 Mar 2024 20:50:13 -0700 (PDT)
Date: Fri, 15 Mar 2024 11:50:02 +0800
From: Michael Chang 
To: The development of GNU GRUB 
Cc: Ross Lagerwall , 
	xen-devel@lists.xenproject.org, Andrew Cooper , 
	Daniel Kiper 
Subject: Re: [PATCH 7/7] verifiers: Verify after decompression
Message-ID: 
References: <20240313150748.791236-1-ross.lagerwall@citrix.com>
 <20240313150748.791236-8-ross.lagerwall@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240313150748.791236-8-ross.lagerwall@citrix.com>

On Wed, Mar 13, 2024 at 03:07:48PM +0000, Ross Lagerwall via Grub-devel wrote:
> It is convenient and common to have binaries stored in gzip archives
> (e.g. xen.gz). Verification should be run after decompression rather
> than before so reorder the file filter list as appropriate.

The proposed change would result in the disruption of the tpm and pgp
clients within the verifier framework. Specifically, the tpm pcr
prediction software relies on the integrity of raw files rather than
decompressed ones. Additionally, pgp detached signatures are designed to
target original files, thus necessitating the current structure to
maintain functionality.

Thanks,
Michael

> 
> Signed-off-by: Ross Lagerwall 
> ---
>  include/grub/file.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/grub/file.h b/include/grub/file.h
> index a5bf3a792d6f..a1ef3582bc7b 100644
> --- a/include/grub/file.h
> +++ b/include/grub/file.h
> @@ -182,10 +182,10 @@ extern grub_disk_read_hook_t EXPORT_VAR(grub_file_progress_hook);
>  /* Filters with lower ID are executed first.  */
>  typedef enum grub_file_filter_id
>    {
> -    GRUB_FILE_FILTER_VERIFY,
>      GRUB_FILE_FILTER_GZIO,
>      GRUB_FILE_FILTER_XZIO,
>      GRUB_FILE_FILTER_LZOPIO,
> +    GRUB_FILE_FILTER_VERIFY,
>      GRUB_FILE_FILTER_MAX,
>      GRUB_FILE_FILTER_COMPRESSION_FIRST = GRUB_FILE_FILTER_GZIO,
>      GRUB_FILE_FILTER_COMPRESSION_LAST = GRUB_FILE_FILTER_LZOPIO,
> -- 
> 2.43.0
> 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel


From xen-devel-bounces@lists.xenproject.org Fri Mar 15 05:10:06 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 05:10:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693622.1081971 (Exim 4.92)
	(envelope-from )
	id 1rkzpI-0002jh-J3; Fri, 15 Mar 2024 05:09:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693622.1081971; Fri, 15 Mar 2024 05:09:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rkzpI-0002ja-GC; Fri, 15 Mar 2024 05:09:52 +0000
Received: by outflank-mailman (input) for mailman id 693622;
 Fri, 15 Mar 2024 05:09:51 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkzpG-0002jP-VR; Fri, 15 Mar 2024 05:09:50 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkzpG-0001Xj-KG; Fri, 15 Mar 2024 05:09:50 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rkzpG-0007so-6W; Fri, 15 Mar 2024 05:09:50 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rkzpG-0005b3-6G; Fri, 15 Mar 2024 05:09:50 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=32zvr1N9i14dCwtBFgQkE0HeIHEvOg1tr1QfpI0LNcw=; b=b0KuDtzPTHZCvCMyvbdpKU59Md
	lMGtuhre56Gy3VURwz04e8D0+DNyxR+Iyv7PSu3qK26Lp2yx1dPM16EMuArjmLrj40IVS1lwaNivT
	I8tWH6OhwQDjBCMETD9xfM4bP8etHafL7eh627VULQEWY5dwIn59lvZr/IUwi/w6Oge8=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 185036: tolerable FAIL - PUSHED
X-Osstest-Failures:
    xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-i386-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking
X-Osstest-Versions-This:
    xen=af7fed3fdf82981ebbb09628b278df957569333d
X-Osstest-Versions-That:
    xen=03cf7ca23e0e876075954c558485b267b7d02406
From: osstest service owner 
Date: Fri, 15 Mar 2024 05:09:50 +0000

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen                  af7fed3fdf82981ebbb09628b278df957569333d
baseline version:
 xen                  03cf7ca23e0e876075954c558485b267b7d02406

Last test of basis   185019  2024-03-13 18:46:04 Z    1 days
Failing since        185029  2024-03-14 06:18:49 Z    0 days    2 attempts
Testing same since   185036  2024-03-14 16:08:13 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper 
  Federico Serafini 
  Jan Beulich 
  Juergen Gross 
  Julien Grall 
  Maria Celeste Cesario 
  Nicola Vetrini 
  Paul Durrant 
  Simone Ballarin 
  Stefano Stabellini 
  Vaishali Thakkar 

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-i386-examine-bios                                 pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-armhf-armhf-libvirt-qcow2                               pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-libvirt-raw                                  pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-i386-examine-uefi                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-arm64-arm64-xl-vhd                                      pass    
 test-armhf-armhf-xl-vhd                                      pass    
 test-amd64-i386-xl-vhd                                       pass    


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

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

Explanation of these 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
   03cf7ca23e..af7fed3fdf  af7fed3fdf82981ebbb09628b278df957569333d -> master


From xen-devel-bounces@lists.xenproject.org Fri Mar 15 06:54:52 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 06:54:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693639.1082017 (Exim 4.92)
	(envelope-from )
	id 1rl1Se-0007Dm-TS; Fri, 15 Mar 2024 06:54:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693639.1082017; Fri, 15 Mar 2024 06:54:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl1Se-0007Df-QL; Fri, 15 Mar 2024 06:54:36 +0000
Received: by outflank-mailman (input) for mailman id 693639;
 Fri, 15 Mar 2024 06:54:35 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rl1Sd-0007DZ-NR
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 06:54:35 +0000
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com
 [2a00:1450:4864:20::632])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e05a35d2-e298-11ee-a1ee-f123f15fe8a2;
 Fri, 15 Mar 2024 07:54:32 +0100 (CET)
Received: by mail-ej1-x632.google.com with SMTP id
 a640c23a62f3a-a44ad785a44so193375866b.3
 for ; Thu, 14 Mar 2024 23:54:32 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 vi2-20020a170907d40200b00a42f6d17123sm1387485ejc.46.2024.03.14.23.54.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 14 Mar 2024 23:54:31 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e05a35d2-e298-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710485672; x=1711090472; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=f9YystZ4iIy2Dv15uat55EcESdVpeUKstkG2ZBxT/7w=;
        b=YBLhQJ7EL/AoWlY6uoIxn2p64rhLa8ZLeEovPdqNMUvwnZlNb47sBJx25d7wi8X6Mb
         AeApQcdNyiE5ZOuNP3o9b7nYJGBUc3NXKJ48NhZ5ZZzfUg6XDwiODGSFiwO5EnJrOEec
         Qhqvy/0fkgbeT05GvQN7x7i4qnTHybsboOF93LorGW62jyGh+FP8XxH5mPZq2h/8mXsH
         aRnPMu/HB5++4Kxx1uGxWbq9ehEELWbcgE9zZv9+O9oWJo2YOkvc49lY9UQAjo1KvnAK
         go5BIujIwyAoOIQ0v0ebcnVrG2j1Ugvdg955dkLW4z9oUAd4XA9fh4hdk4TJJeYlD5Ed
         sxdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710485672; x=1711090472;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=f9YystZ4iIy2Dv15uat55EcESdVpeUKstkG2ZBxT/7w=;
        b=HT85rGu+F7w3EqoY8CNawyQwJTUnQ4xGsUdUqrj3F5wAAJ+5KiNEf8LX2i2NK12No8
         j0SlMfX0muVPG4SfYhuEobOeJOp+3u7/IgHhimR3EtrxVZgASpe6HyPWeMlKGInkSrA4
         olUTqvMzEzVBexC+x/8IiHg5tOTCnaIK0dPIn5loeHjmTGNyzvm6IVp68hK+F35JJ/rn
         fH+fQiqEYnK7FEdcqrmfvCaflLcUJzEvmVWsvH6jpSKl2US+LoFz6/7OVf1NrTdd7/hJ
         0ZrvKMmgWgS/sx9mHJ6akE1a22nMw1kMuFeDmF/PUVuhNFaEY4W9bzO3vFG4fezAHT5f
         HsHg==
X-Forwarded-Encrypted: i=1; AJvYcCWUxiPL5BuKwahGGWVsW4/sGf0PJYLEa9RADab2jOTl6jur6MwLmrnommqHtZV8QZ5g95oGIoB0tpZF4ISo5q0abEUGKfueqTPH4u/SL8c=
X-Gm-Message-State: AOJu0YwPUmgsDHndppY4KeyO32mmgPbW2fY+XPmXpVZbFKpZof1zageK
	9fgGSHuL+Ycwd0fPnTRs7XhjgnE04Xb+P3CWhwBY0xNay/OPJOgR8oiksoMXUA==
X-Google-Smtp-Source: AGHT+IF26C6s+o21o/zUm5yoXuIqyYUdtDXDtKc86rlnkdApJE9G/mE1jKaiKURTIb5X3DLOQqPQjA==
X-Received: by 2002:a17:906:5592:b0:a46:6b54:70a6 with SMTP id y18-20020a170906559200b00a466b5470a6mr1374258ejp.65.1710485671774;
        Thu, 14 Mar 2024 23:54:31 -0700 (PDT)
Message-ID: 
Date: Fri, 15 Mar 2024 07:54:30 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] do_multicall and MISRA Rule 8.3\
Content-Language: en-US
To: Stefano Stabellini 
Cc: George Dunlap , federico.serafini@bugseng.com,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Bertrand Marquis , xen-devel@lists.xenproject.org,
 michal.orzel@amd.com, julien@xen.org
References: 
 <5a8f90d6-6502-4d93-9fd7-45fea0ede24a@suse.com>
 
 
 
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 15.03.2024 01:21, Stefano Stabellini wrote:
> On Mon, 11 Mar 2024, Julien Grall wrote:
>> On 11/03/2024 11:32, George Dunlap wrote:
>>> On Sat, Mar 9, 2024 at 1:59 AM Stefano Stabellini
>>>  wrote:
>>>>
>>>> I would like to resurrect this thread and ask other opinions.
>>>>
>>>>
>>>> On Thu, 23 Nov 2023, Jan Beulich wrote:
>>>>> On 22.11.2023 22:46, Stefano Stabellini wrote:
>>>>>> Two out of three do_multicall definitions/declarations use uint32_t as
>>>>>> type for the "nr_calls" parameters. Change the third one to be
>>>>>> consistent with the other two.
>>>>>>
>>>>>> Link:
>>>>>> https://lore.kernel.org/xen-devel/7e3abd4c0ef5127a07a60de1bf090a8aefac8e5c.1692717906.git.federico.serafini@bugseng.com/
>>>>>> Link:
>>>>>> https://lore.kernel.org/xen-devel/alpine.DEB.2.22.394.2308251502430.6458@ubuntu-linux-20-04-desktop/
>>>>>> Signed-off-by: Stefano Stabellini 
>>>>>> ---
>>>>>> Note that a previous discussion showed disagreement between
>>>>>> maintainers
>>>>>> on this topic. The source of disagreements are that we don't want to
>>>>>> change a guest-visible ABI and we haven't properly documented how to
>>>>>> use
>>>>>> types for guest ABIs.
>>>>>>
>>>>>> As an example, fixed-width types have the advantage of being explicit
>>>>>> about their size but sometimes register-size types are required (e.g.
>>>>>> unsigned long). The C specification says little about the size of
>>>>>> unsigned long and today, and we even use unsigned int in guest ABIs
>>>>>> without specifying the expected width of unsigned int on the various
>>>>>> arches. As Jan pointed out, in Xen we assume sizeof(int) >= 4, but
>>>>>> that's not written anywhere as far as I can tell.
>>>>>>
>>>>>> I think the appropriate solution would be to document properly our
>>>>>> expectations of both fixed-width and non-fixed-width types, and how to
>>>>>> use them for guest-visible ABIs.
>>>>>>
>>>>>> In this patch I used uint32_t for a couple of reasons:
>>>>>> - until we have better documentation, I feel more confident in using
>>>>>>    explicitly-sized integers in guest-visible ABIs
>>>>>
>>>>> I disagree with this way of looking at it. Guests don't invoke these
>>>>> functions directly, and our assembly code sitting in between already is
>>>>> expected to (and does) guarantee that (in the case here) unsigned int
>>>>> would be okay to use (as would be unsigned long, but at least on x86
>>>>> that's slightly less efficient), in line with what ./CODING_STYLE says.
>>>>>
>>>>> Otoh structure definitions in the public interface of course need to
>>>>> use fixed with types (and still doesn't properly do so in a few cases).
>>>
>>> You didn't address the other argument, which was that all the other
>>> definitions have uint32_t; in particular,
>>> common/multicall.c:do_multicall() takes uint32_t.  Surely that should
>>> match the non-compat definition in include/hypercall-defs.c?
>>>
>>> Whether they should both be `unsigned int` or `uint32_t` I don't
>>> really feel like I have a good enough grasp of the situation to form a
>>> strong opinion.
>>
>> FWIW +1. We at least need some consistency.
> 
> Consistency is my top concern. Let's put the "unsigned int" vs
> "uint32_t" argument aside.
> 
> do_multicall is not consistent with itself. We need
> hypercall-defs.c:do_multicall and multicall.c:do_multicall to match.
> 
> Option1) We can change hypercall-defs.c:do_multicall to use uint32_t.
> 
> Option2) Or we can change multicall.c:do_multicall to use unsigned int.
> 
> I went with Option1. Andrew expressed his strong preference toward
> Option1 in the past. George seems to prefer Option1.
> 
> Jan, can you accept Option1 and move on?

Counter question: Why do we have the opposite of what you all want stated
in ./CODING_STYLE? Looking at the commit, it was actually George who ack-ed
it. I can accept option 1 if ./CODING_STYLE is first changed / amended.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Mar 15 06:55:38 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 06:55:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693641.1082027 (Exim 4.92)
	(envelope-from )
	id 1rl1Te-0007h5-6v; Fri, 15 Mar 2024 06:55:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693641.1082027; Fri, 15 Mar 2024 06:55:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl1Te-0007gy-2m; Fri, 15 Mar 2024 06:55:38 +0000
Received: by outflank-mailman (input) for mailman id 693641;
 Fri, 15 Mar 2024 06:55:36 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rl1Tc-0007fC-GT
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 06:55:36 +0000
Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.9])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 03b7e297-e299-11ee-afdd-a90da7624cb6;
 Fri, 15 Mar 2024 07:55:34 +0100 (CET)
Received: from orviesa003.jf.intel.com ([10.64.159.143])
 by fmvoesa103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 14 Mar 2024 23:55:30 -0700
Received: from orsmsx601.amr.corp.intel.com ([10.22.229.14])
 by orviesa003.jf.intel.com with ESMTP/TLS/AES256-GCM-SHA384;
 14 Mar 2024 23:55:30 -0700
Received: from orsmsx610.amr.corp.intel.com (10.22.229.23) by
 ORSMSX601.amr.corp.intel.com (10.22.229.14) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2507.35; Thu, 14 Mar 2024 23:55:30 -0700
Received: from ORSEDG602.ED.cps.intel.com (10.7.248.7) by
 orsmsx610.amr.corp.intel.com (10.22.229.23) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2507.35 via Frontend Transport; Thu, 14 Mar 2024 23:55:30 -0700
Received: from NAM11-BN8-obe.outbound.protection.outlook.com (104.47.58.168)
 by edgegateway.intel.com (134.134.137.103) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.1.2507.35; Thu, 14 Mar 2024 23:55:29 -0700
Received: from BN9PR11MB5276.namprd11.prod.outlook.com (2603:10b6:408:135::18)
 by IA0PR11MB8302.namprd11.prod.outlook.com (2603:10b6:208:482::10)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.19; Fri, 15 Mar
 2024 06:55:27 +0000
Received: from BN9PR11MB5276.namprd11.prod.outlook.com
 ([fe80::39d:5a9c:c9f5:c327]) by BN9PR11MB5276.namprd11.prod.outlook.com
 ([fe80::39d:5a9c:c9f5:c327%5]) with mapi id 15.20.7386.017; Fri, 15 Mar 2024
 06:55:27 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 03b7e297-e299-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
  d=intel.com; i=@intel.com; q=dns/txt; s=Intel;
  t=1710485734; x=1742021734;
  h=from:to:cc:subject:date:message-id:references:
   in-reply-to:content-transfer-encoding:mime-version;
  bh=zlJDIE1LCmYEb1YgXAoF3OL/6KnAQbgu58xuDblVz3g=;
  b=QmU51cEtw8wv2DdIfcujjFMdY04yxNHPxunxDi1DNv0cZ/6GI3Tn1GmY
   q53r5LrXXPve4uOBsvOePZ7Yfqbm0p95zhNCIDYaiNKIjsRqaqjk2GPkx
   hPUu092o/ysjcSuzTureWTnM7Fpo9s/Jf+al7xt9BOPsVTipEwCTRbgmE
   rQkhzv2aHRXbRGR+Yz3zrT0ZdCfpB0Lt6Mc/wbNFbPDP/gc+JUqxg+oF8
   W0MYvcEy7lfMBnnSCJTe9nCnt0fLNSkThtpkaRF2BcBEUhWdXnB0OPEic
   KFGI2XoZ4H1gB8TUUpqwwVyETcFNI1rfooE6We8jhp7226lO7L1BCMErI
   A==;
X-IronPort-AV: E=McAfee;i="6600,9927,11013"; a="16067326"
X-IronPort-AV: E=Sophos;i="6.07,127,1708416000"; 
   d="scan'208";a="16067326"
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="6.07,127,1708416000"; 
   d="scan'208";a="17261321"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=DaO/5hHseDAS1sPCzj84ZDAKLCwu3dPKL1jzvfxyrtOWtnizhkaqogDbGn9/rEpf2so7BpnDdRJMlxAVoiJteLk7hEaltUjwEb7ojNHnGvdzfK+LDMrXANGIHEN5ptM0Q6uLMKMDV+6QMULRhXFBCAhkhjPM7XR9XnVfT7ZZZ55jyBXf2MHyGikQTWrPnCW7MgN2ywlvph3RJKLaBaa158awCNtaQ5/5/vKt4U8bQs44bZBZARhQXYOSNq7mukrr8CZ52DcwT1zn23EfndUSVZgUbIypmhuNv9nMqLY8vq+rdzA7omoObGXKY59T3hQxMRm0DffwsXfdQHsxgXXofw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=zlJDIE1LCmYEb1YgXAoF3OL/6KnAQbgu58xuDblVz3g=;
 b=LNj1CuW0WAXfogW+mIUH0lYJg+u659NXydmrk4Ylk5qLafJisOFVyTpgtM6j45Pd09YfUMcRAKlhnWbq3awrwRgZ4hcVkbYg47pa3haxM8Ib3+LBiQRjp5mUJQEtzi0+Cjn4ulHGBtX6/kGlwBcCiuz9U7yJEHAPStsSj3yKFBwUr/I2SvxPQYdRbx7YVZprZ4BhM8QGUEL+cNGH58p2adqMHhlJ9qwXjbELmDjGpjvK05jzoNY8Q47NaOLp52UhmRG0OXOGbCSVXnN+wxYfZ2FHFvn6SsstkQtZ8LXjqaA/R9XFskifmiyNG5Z8U8jfmV/ILYMXEsXhAZFNqpwodA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com;
 dkim=pass header.d=intel.com; arc=none
From: "Tian, Kevin" 
To: "Beulich, Jan" , "xen-devel@lists.xenproject.org"
	
CC: "andrew.cooper3@citrix.com" , George Dunlap
	, Julien Grall , Stefano Stabellini
	, Wei Liu ,
	=?utf-8?B?UGF1IE1vbm7DqSwgUm9nZXI=?= 
Subject: RE: [PATCH] MAINTAINERS: drop AMD IOMMU and Intel VT-d sections
Thread-Topic: [PATCH] MAINTAINERS: drop AMD IOMMU and Intel VT-d sections
Thread-Index: AQHadivoTV8SqgOV10K8LvzRFdAHwrE4Xw9A
Date: Fri, 15 Mar 2024 06:55:27 +0000
Message-ID: 
References: <36bf6c96-c266-4908-ae85-1ec9325b5bd9@suse.com>
In-Reply-To: <36bf6c96-c266-4908-ae85-1ec9325b5bd9@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=intel.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BN9PR11MB5276:EE_|IA0PR11MB8302:EE_
x-ms-office365-filtering-correlation-id: 10f4f093-db16-45b2-cfda-08dc44bce559
x-ld-processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: empezgXMXpOCA/mhHe6NPFiYO4cAdOPRsIZkaPpwUOJt++E79dyD0z0GSWlc1E/XN0Tn10zyvzaHiYJjWIzGecYtgLSIUS0OjB9ZN+LaVIS5MTJ7sNjql7aQXcW/jzTpnigZSmuKOFTh7qeHocK0ZwioIsbzdxnzxFqhYIl0bWgRY5PlP9JOQ2vubY1oGWDnKHkLnuOSgW720ob4ywXJk6nJtkn/7UeGebyJ65zQxe4MoC0tQ3CWgvjACauccZi1312asnF4S9ospujJ3fEinrH8fpo8ViN5/GcuAADV966NfLFGCa5itOt9nduuPTVcn+aHfHScVJHgws2PYX6eNPA4kukpmlQ42MAFs04P83dhsw1XIkODgtH7W6qC0ru4qs1xsdmwfvYukVqb9AElznVmogz2QFkIM244deUweHaHCT8x43bLGjW/2UakSArlo+D30t/f9gBRd08Z8Tp74YXaGEXg75Wd6yayn/UMc4RQnHwo/IPCmz1T3JMFA2esvtvVS0jsIYYurWmTqWBih75RzVqmHffnvUDF6eSe1BoCr2mVQhnp8fW57DrZlnWXyY08cGm0WHQLJoqqc+A0n7YXDcis/atOVWZgbGHVYvWDEAYGUoSk8s+MpNoO1d2Ba6WE03lXE+I/I2mtt568AjMZJdImICKhGeneq3MKW7fbuPLJfAqcKiKfou3X85c1fRtcX3bpeUEVEJKuxD/NyWDI/e29+cv4V7hsTpQtwz0=
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR11MB5276.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(366007)(1800799015)(376005)(38070700009);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?utf-8?B?QmlOOTlPSkNrU3Zad2k5VzArbTYzdThGLzAwVUZBcHdRRFl4UGdyUXRmSlVQ?=
 =?utf-8?B?TkZjdTNnY2VtckRTV0RRbC9JZkN5WWhCZlRGb21IMnh3aGMvSVdHenlUcmo1?=
 =?utf-8?B?NHFzK3VSdTJDeFpVdk5EM2QrMUJTYzB1dzZhU0lyS01iTVltbjN1L1RmR1o4?=
 =?utf-8?B?Q3RhbktXUS9GeGIxdHN3M0tsZDlwWWsvb2drRXpBeG9kRm5RT1JnL0V0Umtt?=
 =?utf-8?B?K2svQlJaTWd6TS9Ga2JXSU1tdFFzTFQ3TUVyaitMSlczaEMvQWJ1Y3hxVFdq?=
 =?utf-8?B?R3NVNmpxbUl3WTRVRW9MVmJUekxsa0RQOGhvZGtrSzNNbno0TC91VGtqVVRF?=
 =?utf-8?B?NlZaQWIwNW8yc2hiaGdQWURiNDIxTTZtTVo5UWQyeTNDcTRLck92cmVlUHBJ?=
 =?utf-8?B?RDFocGQ2K09KeWRDV2RNQURGa1JrdzBEQ0RHdUp5YVArWldXM0FyUmZFcDE2?=
 =?utf-8?B?TjFZMlFoL2lXei93NVowbkRzTy9UcXEzMWtFanBheUxQcC9xSEFwM0lsT3F6?=
 =?utf-8?B?L1BUMHMvR3htZkZjQ2FOUTFhYXg0NmRWTUNuSFlqajdlV2lqWlJvQ2tNd2Jn?=
 =?utf-8?B?RTFNSzdBejU1QS9PL0JSL09pVzFPQXZra0RxdG4xK0ludThYamJqOEI5MUtS?=
 =?utf-8?B?Mms0VXp4TW1acXZYbjhMZUhDcXlBbkVOWENQb3FTb0RIYkZ0TG83WEw4MXhy?=
 =?utf-8?B?Vko1bk9wVjkxL1cxRHJxTE9JUUZHQVp0L3NYTVNldStHSndVMVZpblVPdjh5?=
 =?utf-8?B?QnZNTEliVE5KWkhDRFB1c0QxTHphRE5RMzF6RlArWFE5YzNxaVpiN3FlVUpi?=
 =?utf-8?B?cUlid01iWFdjdStJTTZQU3lSOC9NRFQ5bFhFWGRydU05V3hoYTJOeFpxU0Jt?=
 =?utf-8?B?V0N5VTN2MGwxb0pVdXdQemNteUt5YUEzVUoya0dMdHFqYTI0UHl3WVAxcTBE?=
 =?utf-8?B?SytreHNERnpUQmJTMnN2NERNTjZMYjY5ZEVmMDRKdlZJcU03TjB2UE8xT2xj?=
 =?utf-8?B?dWFDREFaekRnKzZFa2NQVXV0dGRJb0FwWXdMdHg2eUpJdyt2OWZoQXZld25L?=
 =?utf-8?B?L3VkWW5CSzA0TysxWVppQzJWZlZkS3Q1YmVOL3FMRElhR3RXVmZpNEVGOHdL?=
 =?utf-8?B?M2RzRXVSYTFySU85WnAySS8vVDlERTFNdFhkeGxqMXVXeTc1Um5ncTRaTi9o?=
 =?utf-8?B?dGpQVG13aE1OTjdtUDFvdzFpazZWZTRkeTFHbS94Z2dOaCs2K21FNU01QUtG?=
 =?utf-8?B?MmxpNnBlS0J4c0RhSEhJRU1nNVVUMnVlcDJ5WEloczFhbjgvTVFWVjI1djRN?=
 =?utf-8?B?VzBkNjV4ditZR1M5RkViNWV3UXNFLzQrT3BVY2lVaVJmMGZiMVB4YW1aZG9s?=
 =?utf-8?B?RHY0ajBINXFRR2cwUWZTb2QyNjhRVE9nZUQ2Um9Sa0ptekNiRkRzc1hNdGlq?=
 =?utf-8?B?T0JLaWhTeVRuejFjTUsvblFJK3Zrelh0OHl1VktJK25saU9RUWxkK2R2OHJV?=
 =?utf-8?B?c1ozc1V2OUxURGhqWCtxeDF2Z25kSXg0SUhxYnNPbjRGNUZEUUFuTU9NckJk?=
 =?utf-8?B?cmdCWDRHUzZuMDhoL0hJWEF3aTJnbW14TXB5VTdnenU0U2pPNlRQQVR4VWJn?=
 =?utf-8?B?UnVFSlFZU0hUb0hPMDYwUU02aGdtVUhxUlR3Vnp3VlhpczNGUFhEdkExWWZ3?=
 =?utf-8?B?Q2ZWNVFxbEIxTW43Wk9BalQrM1BxLzVsRjRLWFd1bkgxa3htdEZ0Y1JvTVRX?=
 =?utf-8?B?K00rcWRVYTdPQXg1K1V4czdaUzhsSUh3Nmw1ZGhpaHFFdzJLcldpcW5kckpq?=
 =?utf-8?B?UnowYkkrNUFIdU1LVmxDRVI4R1lXVUdJRUNmTDEwQzF3V0VwbXhpM1hVQkw5?=
 =?utf-8?B?cjdtSjBHRTB1a0o1Z3ZsNG5kWjY4L1RkMWxQTHVkK0xqMlZYNGMyMzlZbkVW?=
 =?utf-8?B?UjhTNEVSK3ltNUhDeS83VG9nd2k3Y2dPVWhESGdITlVzUzBQVEFFT3pGc0x0?=
 =?utf-8?B?K0lyQVNxdHBvSFp0dnVJRkU1a2pkNitwSHBuakZzMGpMK1VycE85S1QzK0JG?=
 =?utf-8?B?cnAxdi92aVhWU1FUam9wUU5ualdWaFhMUXMvVElueG5nOEZKUHV3eWszTy9l?=
 =?utf-8?Q?gIekP2H2S+OlizW5bW/5Y+/JH?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN9PR11MB5276.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 10f4f093-db16-45b2-cfda-08dc44bce559
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Mar 2024 06:55:27.1784
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: SP6YwG8ghVfmFOlY46nF76TZMXKQNGfVbMcq3E6xfZ+gMoeA4k4FQ5qjB9HshSMUZSxkKazHXQ41fH4omJqyTg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR11MB8302
X-OriginatorOrg: intel.com

PiBGcm9tOiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IFNlbnQ6IEZyaWRheSwg
TWFyY2ggMTUsIDIwMjQgMTI6MjMgQU0NCj4gDQo+IFdlJ2QgbGlrZSB0byB0aGFuayBLZXZpbiwg
c28gZmFyIHRoZSBWVC1kIG1haW50YWluZXIsIGZvciBoaXMgcGFzdA0KPiBjb250cmlidXRpb25z
LCB3aGlsZSBhdCB0aGUgc2FtZSB0aW1lIHdlJ2QgbGlrZSB0byByZWZsZWN0IHJlYWxpdHkgYXMg
aXQNCj4gaGFzIGJlZW4gZm9yIHF1aXRlIHNvbWUgdGltZS4gSGF2ZSBWVC1kIG1haW50YWluZXJz
aGlwIChhbmQgZm9yIHN5bW1ldHJ5DQo+IGFsc28gQU1EIElPTU1VJ3MpIGZhbGwgYmFjayB0byB0
aGUgbWFpbnRhaW5lcnMgb2YgZ2VuZXJhbCB4ODYuIFRoaXMgYWxzbw0KPiBicmluZ3MgdGhpbmdz
IGluIHN5bmMgd2l0aCBob3cgdGhleSBhcmUgZm9yIEFybS4NCj4gDQo+IFdoaWxlIHRvdWNoaW5n
IHRoZSBYODYgc2VjdGlvbiBhbHNvIGFwcGVuZCB0d28gc28gZmFyIG1pc3Npbmcgc2xhc2hlcy4N
Cj4gDQo+IFNpZ25lZC1vZmYtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4NCj4g
DQoNCkFja2VkLWJ5OiBLZXZpbiBUaWFuIDxrZXZpbi50aWFuQGludGVsLmNvbT4NCg==


From xen-devel-bounces@lists.xenproject.org Fri Mar 15 06:59:17 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 06:59:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693643.1082036 (Exim 4.92)
	(envelope-from )
	id 1rl1X9-00009v-LS; Fri, 15 Mar 2024 06:59:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693643.1082036; Fri, 15 Mar 2024 06:59:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl1X9-00009o-IO; Fri, 15 Mar 2024 06:59:15 +0000
Received: by outflank-mailman (input) for mailman id 693643;
 Fri, 15 Mar 2024 06:59:14 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rl1X8-00009g-Ni
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 06:59:14 +0000
Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com
 [2a00:1450:4864:20::132])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8797ca88-e299-11ee-a1ee-f123f15fe8a2;
 Fri, 15 Mar 2024 07:59:12 +0100 (CET)
Received: by mail-lf1-x132.google.com with SMTP id
 2adb3069b0e04-512f3e75391so1640402e87.2
 for ; Thu, 14 Mar 2024 23:59:12 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 sa37-20020a1709076d2500b00a4635a21ff0sm1412722ejc.38.2024.03.14.23.59.11
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 14 Mar 2024 23:59:12 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8797ca88-e299-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710485952; x=1711090752; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=f0BNugw9oUIIEpNu31+YGP/DO2a6/E/ajyMHR3fBV80=;
        b=HooDN3ajluP6RuuBLWqwGDh29pU+7eqQThknQISR1skmA8enov1j5RbptEYUTeN7Ur
         tZuDOqfF8hVvllTp6LZpthvTJM5yqx9HsFQau1C8twtlRRqbb/Pl++5rCQmfxlAB84cE
         +WISJZpLBFhnton59Y+zO6yo+lSezKdgggg5wzPkoMINaKNEHubuSo0HEqtOOwQhiJ+f
         MifCSqUKRLFOjnKkEuVCiPwhIgnRCeHojqhU1yvixPxMwxaHQ/+2Mxwnd0NW7CU7j8n4
         eaw6DlFgs0iYs6BwTSbdwHQKYnhPWpLAWnIXn9FeUJhM6S1endznTB68n/qQ3SEDza0G
         Q/Sw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710485952; x=1711090752;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=f0BNugw9oUIIEpNu31+YGP/DO2a6/E/ajyMHR3fBV80=;
        b=vtkdJ408xD7e/YYX38HAq6Vg0A+xTFRbo84qEIPW6x7W1XPw08NnB9skf7oT5UQBVq
         h24nxWT1/4IV9JnQUrmUFuA9tAopJh9GVDaXWqzn45PDh/Y+1KObxQy+yTqRe/w9o7Lw
         PVZi/RL896ftiMm9dXoyeMLhexnRO6OgrwViBKCu64B3BEuE95OxdTL3pmufQerXyq2w
         AGcuxPS2u2KmO67ft+Qd2dbP+hA97h3Cj01b+fb/y5EusHZ658Xd7IMx9eKcyiB8Aybt
         H3XjCq+hDMOCS2slOeHAvZosqJ9QwqwnLEEUu4OHNozjOaV5bD1h70jZO7Nrtn/humFt
         +rEA==
X-Forwarded-Encrypted: i=1; AJvYcCU80P/BAShU6/LtenH8w/jxu5gr4zbWqF87B1Im6KDph7qbBsO6mTcfOznV+wAY9bSdVcvLWr7OTnyepDkZFT9NWfAxoT79Qaddy7KaSoo=
X-Gm-Message-State: AOJu0YzZ6xmIEfIhl61hwKvcwZZdNxj/u+qXoycD3DM46MST0b9st7uw
	/4hX/vJ62sxzEb/pp49pexCS+/emii209R58D5qB2z6sOtOrDOceFm+ASMi9Vg==
X-Google-Smtp-Source: AGHT+IGSBkE57xWXRzEnNDTEof79wsq4rPg9HP96IMo0m54w5Eo51e690dvYzWz80KPwy9rwq1NJwQ==
X-Received: by 2002:a05:6512:3ca6:b0:513:d3e3:f78c with SMTP id h38-20020a0565123ca600b00513d3e3f78cmr2959529lfv.40.1710485952333;
        Thu, 14 Mar 2024 23:59:12 -0700 (PDT)
Message-ID: <2ea3d566-1b21-44e6-bdb6-7c554a7f7996@suse.com>
Date: Fri, 15 Mar 2024 07:59:10 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH v3 01/16] misra: add deviation for headers that
 explicitly avoid guards
Content-Language: en-US
To: Stefano Stabellini 
Cc: Simone Ballarin , consulting@bugseng.com,
 Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , xen-devel@lists.xenproject.org
References: 
 <310fe4a0ccd0ad45bcf1cd9811ac56c9a560dd0b.1710145041.git.simone.ballarin@bugseng.com>
 
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 14.03.2024 23:55, Stefano Stabellini wrote:
> On Mon, 11 Mar 2024, Jan Beulich wrote:
>> On 11.03.2024 09:59, Simone Ballarin wrote:
>>> Some headers, under specific circumstances (documented in a comment at
>>> the beginning of the file), explicitly avoid inclusion guards: the caller
>>> is responsible for including them correctly.
>>>
>>> These files are not supposed to comply with Directive 4.10:
>>> "Precautions shall be taken in order to prevent the contents of a header
>>> file being included more than once"
>>>
>>> This patch adds deviation cooments for headers that avoid guards.
>>>
>>> Signed-off-by: Simone Ballarin 
>>>
>>> ---
>>> Changes in v3:
>>> - fix inconsistent deviation ID
>>> - change comment-based deviation text
>>> Changes in v2:
>>> - use the format introduced with doc/misra/safe.json instead of
>>>   a generic text-based deviation
>>> ---
>>>  docs/misra/safe.json                        | 9 +++++++++
>>>  xen/include/public/arch-x86/cpufeatureset.h | 1 +
>>>  xen/include/public/errno.h                  | 1 +
>>>  3 files changed, 11 insertions(+)
>>
>> I understand something wants doing, but having such comments appear in public
>> headers feels wrong to me. I'm afraid I have no good alternative suggestion.
> 
> Given that in both cases there is very nice explanation on how to use
> the headers as an in-code comment just above, could we embed the
> SAF-3-safe marker in the existing comment?

I'm afraid that won't address my remark, and I'm further afraid this would
then render the SAF part of the comment ineffectual.

> If not, I think we should go with this patch as is (I don't think it is
> worth my, your, and Simone's time to look for alternatives).

Easy alternative: Simply leave public headers alone.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Mar 15 07:31:09 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 07:31:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693677.1082046 (Exim 4.92)
	(envelope-from )
	id 1rl21w-0005sk-Gg; Fri, 15 Mar 2024 07:31:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693677.1082046; Fri, 15 Mar 2024 07:31:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl21w-0005sd-Dw; Fri, 15 Mar 2024 07:31:04 +0000
Received: by outflank-mailman (input) for mailman id 693677;
 Fri, 15 Mar 2024 07:31:02 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rl21u-0005p8-It
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 07:31:02 +0000
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com
 [2a00:1450:4864:20::22a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f98f534c-e29d-11ee-afdd-a90da7624cb6;
 Fri, 15 Mar 2024 08:31:02 +0100 (CET)
Received: by mail-lj1-x22a.google.com with SMTP id
 38308e7fff4ca-2d46dd8b0b8so21229541fa.2
 for ; Fri, 15 Mar 2024 00:31:02 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f98f534c-e29d-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1710487861; x=1711092661; darn=lists.xenproject.org;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=wehPS2kEKkREW3AN11EsCYAASYqr8Gk/vdvA5GOTKLk=;
        b=IzpUb5WwyDrGamtsBAzKXuD9mNfXXYbXGa/Hm7sRGZVMOrgp/eI7hrZBxvM0IrzptE
         3i75N7FLZPK+rRREmp3F+Uhc3qhA1Dc2+g/djdvIGJ9ThiWhcAtPGjwbvaEXeU5eXf7Q
         a0b7WqxQhGw56uiYbYnQc+NMXBCIL/IeJXT0sOKDdUWd9bM1fR0qa1oYnrzk/PT5vcKt
         Izf5QJrw464uvnrqBCgkI1ntBTLR+Z8e+eIReSX1mkt6mndZ0RK0fAvzBsAo1IjS8lfh
         71+GBXt0mN89LP+8TNlv9aXBbeDePY/sonS9wSDTrCO4vI3F4rWzAP3rOtEvvzeCqPoL
         lqPA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710487861; x=1711092661;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=wehPS2kEKkREW3AN11EsCYAASYqr8Gk/vdvA5GOTKLk=;
        b=WLCcpUVPnKtIoC3GDNGjpjaYglO3C8VA4EKAzTY2VOa6fF1L67o2jdPy5jqc9dWCNN
         SKqi3RlTTxx5iKfUdRvy9gdk0FBAJet98dIJzoYuSH0v9NrJ1yHuGuqJTG2m+XAUCcEw
         hSU8QUsR1YBMiAvffWSlv0pIu/4U017q/E4i3w4MLJD2XT5C2eEkYiy0kdD11mMJFi3o
         eZE7kXZQVLJ4moXcVxd/SjxkihkpudQ9GFr+iuja8ldvgsx6E5HeCCYqClWlwt0H++ki
         8/ynwMmwa02Mx2wwu/zR0QaMSYcObXx23QxPm5x+o/Aub0e/7ElJQdGMrd0r0aqPUDxC
         Sq+w==
X-Forwarded-Encrypted: i=1; AJvYcCXHgsVzYCvxZerWrEUJiBMAnCQyBFkq9FREmNpuQldjfqOKO6VaKJ6gehNx46XkVU6lAC1Z13wKAyQ7sCxfUB77HqmuPEoxNR0Jf3vY5tc=
X-Gm-Message-State: AOJu0YyBCNmI1m5gELdNyxhvYta7scTJMEnQQqoI/lswEs/wohpuLcfB
	LDJCapKnqt5zYHp63GS/XkprJsvh6f/SD1ZRhZiVjCkvgozNxOsPNo349GgL1FltF0JtFJKEcQz
	7p3vdb7mLdYYdA7W9tm4KLhtRhxc=
X-Google-Smtp-Source: AGHT+IFPPGnPPOV1zLV6mH02SJS4GVbYq3kTRHYpWSLkfR1Qw4+lYFWESVLcUr3tiTeZGz1jwfEHjMLVJaNHCk5wTqw=
X-Received: by 2002:a2e:8949:0:b0:2d4:6765:65ec with SMTP id
 b9-20020a2e8949000000b002d4676565ecmr3009805ljk.42.1710487861328; Fri, 15 Mar
 2024 00:31:01 -0700 (PDT)
MIME-Version: 1.0
References: <20240313150748.791236-1-ross.lagerwall@citrix.com> <20240313150748.791236-4-ross.lagerwall@citrix.com>
In-Reply-To: <20240313150748.791236-4-ross.lagerwall@citrix.com>
From: "Vladimir 'phcoder' Serbinenko" 
Date: Fri, 15 Mar 2024 10:30:50 +0300
Message-ID: 
Subject: Re: [PATCH 3/7] multiboot2: Add support for the load type header tag
To: The development of GNU GRUB 
Cc: Ross Lagerwall , xen-devel , 
	Andrew Cooper , Daniel Kiper 
Content-Type: multipart/alternative; boundary="0000000000005e05b50613adfde6"

--0000000000005e05b50613adfde6
Content-Type: text/plain; charset="UTF-8"

Not a full review. Just one blocking problem


>
>      }
> +  case MULTIBOOT_LOAD_TYPE_PE:
> +      grub_fatal ("Unsupported load type: %u\n", mld.load_type);
> +  default:
> +    /* should be impossible */
> +    grub_fatal ("Unknown load type: %u\n", mld.load_type);
>
Don't use grub_fatal for this. grub_fatal is only when continue to execute
grub is unwise. Here you just have an unsupported file. This is definitely
a GRUB_ERR_BAD_OS


>

--0000000000005e05b50613adfde6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Not a full review. Just one blocking problem




=C2=A0 =C2=A0 =C2=A0}

+=C2=A0 case MULTIBOOT_LOAD_TYPE_PE:

+=C2=A0 =C2=A0 =C2=A0 grub_fatal ("Unsupported load type: %u\n", =
mld.load_type);

+=C2=A0 default:

+=C2=A0 =C2=A0 /* should be impossible */

+=C2=A0 =C2=A0 grub_fatal ("Unknown load type: %u\n", mld.load_ty=
pe);
Don't use grub_fatal for t=
his. grub_fatal is only when continue to execute grub is unwise. Here you j=
ust have an unsupported file. This is definitely a GRUB_ERR_BAD_OS






--0000000000005e05b50613adfde6--


From xen-devel-bounces@lists.xenproject.org Fri Mar 15 08:38:16 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 08:38:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693689.1082057 (Exim 4.92)
	(envelope-from )
	id 1rl34i-0006Z3-Pr; Fri, 15 Mar 2024 08:38:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693689.1082057; Fri, 15 Mar 2024 08:38:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl34i-0006Yw-M2; Fri, 15 Mar 2024 08:38:00 +0000
Received: by outflank-mailman (input) for mailman id 693689;
 Fri, 15 Mar 2024 08:37:59 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rl34h-0006Ym-Fc; Fri, 15 Mar 2024 08:37:59 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rl34h-0005kQ-87; Fri, 15 Mar 2024 08:37:59 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rl34g-0000Sp-SH; Fri, 15 Mar 2024 08:37:58 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rl34g-00015G-R3; Fri, 15 Mar 2024 08:37:58 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=0/dFTBEqGx8mfaTfJp7wlNmnf2SsXoe8t2ZJlIOJXSs=; b=r9PaVyS9KVLmFSELK2REYNInYI
	vR8NagUd/W3s/zchFqU6Qv/kBgifoGoR4JwDleeT9Mg8EIqTHYeRlTjWgdZnnJFiOUaX0ObZAQRrv
	vaiovFZy4GOJ8EPvhMdUznySTlqmgJm/haULgr65fv53vNX1v20XlpcR370MSExr05tA=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 185040: regressions - FAIL
X-Osstest-Failures:
    linux-linus:build-arm64-xsm:xen-build:fail:regression
    linux-linus:test-amd64-amd64-libvirt-pair:guest-migrate/dst_host/src_host/debian.repeat:fail:regression
    linux-linus:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:regression
    linux-linus:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking
    linux-linus:test-arm64-arm64-xl-xsm:build-check(1):blocked:nonblocking
    linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    linux=fe46a7dd189e25604716c03576d05ac8a5209743
X-Osstest-Versions-That:
    linux=e5e038b7ae9da96b93974bf072ca1876899a01a3
From: osstest service owner 
Date: Fri, 15 Mar 2024 08:37:58 +0000

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-xsm               6 xen-build                fail REGR. vs. 185023
 test-amd64-amd64-libvirt-pair 28 guest-migrate/dst_host/src_host/debian.repeat fail REGR. vs. 185023
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 12 debian-hvm-install fail REGR. vs. 185023

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)               blocked  n/a
 test-arm64-arm64-xl-xsm       1 build-check(1)               blocked  n/a
 test-armhf-armhf-libvirt     16 saverestore-support-check    fail  like 185023
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop            fail like 185023
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop            fail like 185023
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop            fail like 185023
 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check   fail like 185023
 test-armhf-armhf-libvirt-raw 15 saverestore-support-check    fail  like 185023
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop            fail like 185023
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 185023
 test-amd64-amd64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 15 migrate-support-check        fail  never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit1  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          16 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     15 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-qcow2 14 migrate-support-check        fail never pass
 test-amd64-amd64-libvirt-raw 14 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-raw 14 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-raw 15 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt     15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-vhd      14 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-vhd      15 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-qcow2 14 migrate-support-check        fail never pass
 test-armhf-armhf-libvirt-raw 14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      15 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  16 saverestore-support-check    fail   never pass

version targeted for testing:
 linux                fe46a7dd189e25604716c03576d05ac8a5209743
baseline version:
 linux                e5e038b7ae9da96b93974bf072ca1876899a01a3

Last test of basis   185023  2024-03-14 00:14:57 Z    1 days
Testing same since   185040  2024-03-14 19:00:47 Z    0 days    1 attempts

------------------------------------------------------------
530 people touched revisions under test,
not listing them all

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              fail    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 fail    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 blocked 
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      blocked 
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-freebsd11-amd64                             pass    
 test-amd64-amd64-freebsd12-amd64                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-amd64-libvirt-pair                                fail    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-libvirt-qcow2                               pass    
 test-armhf-armhf-libvirt-qcow2                               pass    
 test-amd64-amd64-libvirt-raw                                 pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-amd64-xl-vhd                                      pass    
 test-arm64-arm64-xl-vhd                                      pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

Explanation of these 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 44263 lines long.)


From xen-devel-bounces@lists.xenproject.org Fri Mar 15 08:45:21 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 08:45:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693693.1082067 (Exim 4.92)
	(envelope-from )
	id 1rl3Bl-0008GH-Gb; Fri, 15 Mar 2024 08:45:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693693.1082067; Fri, 15 Mar 2024 08:45:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl3Bl-0008GA-DS; Fri, 15 Mar 2024 08:45:17 +0000
Received: by outflank-mailman (input) for mailman id 693693;
 Fri, 15 Mar 2024 08:45:16 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rl3Bk-0008G4-Kd
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 08:45:16 +0000
Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com
 [2607:f8b0:4864:20::735])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 576e740b-e2a8-11ee-afdd-a90da7624cb6;
 Fri, 15 Mar 2024 09:45:15 +0100 (CET)
Received: by mail-qk1-x735.google.com with SMTP id
 af79cd13be357-789e6f7f748so15110985a.3
 for ; Fri, 15 Mar 2024 01:45:15 -0700 (PDT)
Received: from localhost ([85.31.135.62]) by smtp.gmail.com with ESMTPSA id
 j4-20020a05620a0a4400b007883687ef00sm1806420qka.69.2024.03.15.01.45.13
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 15 Mar 2024 01:45:13 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 576e740b-e2a8-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710492314; x=1711097114; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=IwCFGTOnknvM9jgq2jeOOeQwSk3SwCmaIKVHNl4pJmg=;
        b=qK6kmYa5dXPS6JfVNp7IOCsY12JjIuZjJqzbhYngEnOh6ajZ2VFOUdayJxd/7uSaSL
         a0CSXadczt7yFOuhvvqEfN+nPRmD7zK1aFOdXLVdLGNRYZnVFTpIHgIjoSY4Vzb1lLEP
         zybbK5Yyvr9/8G+9C975S32Kr2Ef1Gy541Jac=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710492314; x=1711097114;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=IwCFGTOnknvM9jgq2jeOOeQwSk3SwCmaIKVHNl4pJmg=;
        b=mKK+A7LX6MzHkwgICJkEL3jbyF/wMURzhcF0tleYhgvFFSRd44+i6ehWDSaUH/0eNC
         cwdSFDkHgVbPrBIntaVDQRdSr4M8ODBLKcVAgGBkXnbE0J+hyk07YThVZBlwD37S21dw
         /tQmRwg+ZOyxbdF1te2bTidTBGcbnMsOEjmZaKrvM5DaNOa5AmeL9+QDWBHuEp7h4xrW
         DQ5Yajape6QU3JlfhP9dAnz9e9e4uBbcWlxqiqOLdrteQzso8WpLf+8cxJt5lzTQaCar
         1EIt5hXbqO2LDLOLz8rzhKNCDPw7e1s5ZY3DFHKtpmRzPxLs8fweTv24053hq7FsSs3a
         9KSQ==
X-Forwarded-Encrypted: i=1; AJvYcCVq8x5uCti0sobOvtf6HvymcZoVPyjNhOmJSEPFx1PGmSYv5kANVd/gM94d6stx8tGfbehXWqG9f1Xmkesl83y4BJc7yDjjA4zwEy5RDKQ=
X-Gm-Message-State: AOJu0Yy6ZycUtc4O5dzScv8TiMASCKiohRBdI8F9+H78QDo4b6rhiI+w
	2nrXVosXPexm8BnYqsBsP0Jpqmva4l6qcT0TpWj1CWddeD6NtfBjtNEq41a/xnY=
X-Google-Smtp-Source: AGHT+IGRj/RLAu0w+ktkOvQ08pDl+wZFAzl0dJZyyDzBy5d6+jDDvcgLzLXCQmT2juLtxtia/gPoMg==
X-Received: by 2002:a05:620a:1790:b0:789:c643:d086 with SMTP id ay16-20020a05620a179000b00789c643d086mr5444119qkb.73.1710492313978;
        Fri, 15 Mar 2024 01:45:13 -0700 (PDT)
Date: Fri, 15 Mar 2024 09:45:11 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jason Andryuk 
Cc: Jan Beulich , xen-devel@lists.xenproject.org,
	Andrew Cooper , Wei Liu ,
	George Dunlap ,
	Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH v2 3/3] x86/PVH: Support relocatable dom0 kernels
Message-ID: 
References: <20240313193021.241764-1-jason.andryuk@amd.com>
 <20240313193021.241764-4-jason.andryuk@amd.com>
 
 
 
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Thu, Mar 14, 2024 at 12:59:19PM -0400, Jason Andryuk wrote:
> On 2024-03-14 11:30, Jan Beulich wrote:
> > On 14.03.2024 15:33, Roger Pau Monné wrote:
> > > On Thu, Mar 14, 2024 at 09:51:22AM -0400, Jason Andryuk wrote:
> > > > On 2024-03-14 05:48, Roger Pau Monné wrote:
> > > > > On Wed, Mar 13, 2024 at 03:30:21PM -0400, Jason Andryuk wrote:
> > > > > > @@ -234,6 +235,17 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
> > > > > >                    elf_note_numeric_array(elf, note, 8, 0),
> > > > > >                    elf_note_numeric_array(elf, note, 8, 1));
> > > > > >            break;
> > > > > > +
> > > > > > +    case XEN_ELFNOTE_PVH_RELOCATION:
> > > > > > +        if ( elf_uval(elf, note, descsz) != 3 * sizeof(uint64_t) )
> > > > > > +            return -1;
> > > > > > +
> > > > > > +        parms->phys_min = elf_note_numeric_array(elf, note, 8, 0);
> > > > > > +        parms->phys_max = elf_note_numeric_array(elf, note, 8, 1);
> > > > > > +        parms->phys_align = elf_note_numeric_array(elf, note, 8, 2);
> > > > > 
> > > > > Size for those needs to be 4 (32bits) as the entry point is in 32bit
> > > > > mode?  I don't see how we can start past the 4GB boundary.
> > > > 
> > > > I specified the note as 3x 64bit values.  It seemed simpler than trying to
> > > > support both 32bit and 64bit depending on the kernel arch.  Also, just using
> > > > 64bit provides room in case it is needed in the future.
> > > 
> > > Why do you say depending on the kernel arch?
> > > 
> > > PVH doesn't know the bitness of the kernel, as the kernel entry point
> > > is always started in protected 32bit mode.  We should just support
> > > 32bit values, regardless of the kernel bitness, because that's the
> > > only range that's suitable in order to jump into the entry point.
> > > 
> > > Note how XEN_ELFNOTE_PHYS32_ENTRY is also unconditionally a 32bit
> > > integer.
> 
> Linux defines PHYS32_ENTRY with _ASM_PTR, so it's 32 or 64 bit to match how
> the kernel is compiled.  The Xen code parses the integer according to the
> size of the note.

I think that's wrong, PHYS32_ENTRY should strictly be a 32bit integer,
in fact the field in struct elf_dom_parms is an uint32_t, so Linux
using _ASM_PTR seems bogus, it should unconditionally use .long
regardless of the kernel bitness.

> > > > Do you want the note to be changed to 3x 32bit values?
> > > 
> > > Unless anyone objects, yes, that's would be my preference.
> > 
> > As mentioned elsewhere, unless the entire note is meant to be x86-specific,
> > this fixed-32-bit property then would want limiting to x86.
> 
> PVH is only implemented for x86 today.  Are you saying that the comment
> should just specify the values are 32bit for x86?  If the note is reused for
> other arches, then they can specify their usage?
> 
> If this note is to be a variably sized array of values, then the elements
> should be of fixed size.  Otherwise parsing is ambiguous without, say,
> another field specifying element size.
> 
> Maybe XEN_ELFNOTE_PHYS32_RELOC would be a better name to complement the
> PHYS32_ENTRY?

IMO the '32' part of PHYS32_ENTRY is kind of redundant, given the CPU
state when using such entry point it's impossible to use 64bit
addresses.  I would be fine with using XEN_ELFNOTE_PHYS_RELOC or some
such.  Anyway, this is just a name so I'm not going to opposed if Jan
and yourself prefer to keep using PHYS32.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri Mar 15 08:59:56 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 08:59:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693700.1082077 (Exim 4.92)
	(envelope-from )
	id 1rl3Pp-0001t0-MY; Fri, 15 Mar 2024 08:59:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693700.1082077; Fri, 15 Mar 2024 08:59:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl3Pp-0001st-JA; Fri, 15 Mar 2024 08:59:49 +0000
Received: by outflank-mailman (input) for mailman id 693700;
 Fri, 15 Mar 2024 08:59:49 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rl3Po-0001sn-Ux
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 08:59:49 +0000
Received: from EUR05-DB8-obe.outbound.protection.outlook.com
 (mail-db8eur05on20614.outbound.protection.outlook.com
 [2a01:111:f400:7e1a::614])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5df29f3a-e2aa-11ee-a1ee-f123f15fe8a2;
 Fri, 15 Mar 2024 09:59:46 +0100 (CET)
Received: from DU2PR04CA0019.eurprd04.prod.outlook.com (2603:10a6:10:3b::24)
 by AS2PR08MB8877.eurprd08.prod.outlook.com (2603:10a6:20b:5e6::16) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.22; Fri, 15 Mar
 2024 08:59:40 +0000
Received: from DB5PEPF00014B9D.eurprd02.prod.outlook.com
 (2603:10a6:10:3b:cafe::d1) by DU2PR04CA0019.outlook.office365.com
 (2603:10a6:10:3b::24) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.36 via Frontend
 Transport; Fri, 15 Mar 2024 08:59:40 +0000
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by
 DB5PEPF00014B9D.mail.protection.outlook.com (10.167.8.164) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.7386.12 via Frontend Transport; Fri, 15 Mar 2024 08:59:38 +0000
Received: ("Tessian outbound 5fdc1e2b2c35:v276");
 Fri, 15 Mar 2024 08:59:38 +0000
Received: from 7deb1d671cd3.1
 by 64aa7808-outbound-1.mta.getcheckrecipient.com id
 2425F618-8A6A-4AD7-A19A-42EB3282DFA7.1; 
 Fri, 15 Mar 2024 08:59:30 +0000
Received: from EUR01-VE1-obe.outbound.protection.outlook.com
 by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 7deb1d671cd3.1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384);
 Fri, 15 Mar 2024 08:59:30 +0000
Received: from AM6PR08MB3749.eurprd08.prod.outlook.com (2603:10a6:20b:8f::22)
 by AS4PR08MB7501.eurprd08.prod.outlook.com (2603:10a6:20b:4e5::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.22; Fri, 15 Mar
 2024 08:59:28 +0000
Received: from AM6PR08MB3749.eurprd08.prod.outlook.com
 ([fe80::13e4:dd98:2513:db0]) by AM6PR08MB3749.eurprd08.prod.outlook.com
 ([fe80::13e4:dd98:2513:db0%7]) with mapi id 15.20.7386.020; Fri, 15 Mar 2024
 08:59:28 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5df29f3a-e2aa-11ee-a1ee-f123f15fe8a2
ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass;
 b=d0kREhPWVPGfSCqfE1Td8fIbgzylO0YH7FE7tTLBJgz0p5d0RU7fdoNJOgq2vgFbQKkA/YZYSgq3TBWqCK2s2R2HU7fhuArMkGnEz+cuMSW3X/cSd3FrtKk5i/XvmuEMCEcl9VdQrNrOT93vK+va9VHF9ZQ26ERYxxTC1vIG10wp5gHV7nHFYmC4iR9g0A4YnD1gqzxu+mFeE/hYzLlq1O7az9un7Lvr3gPBsfWBLAJSIKFPlXVznX6+AYqdcA9b1URP4Rn6VM3XDYrPaWIbenYAhIasImOaSMQ7+OglIwmSlHNIQwzzxHDiwW0rKKsKfIVAeh9pIMZAjtpyiIWMlA==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=/4KqKIOk8g0hOmD/GWMr8JzUf1mB1Zm/zKmK/5XsM+k=;
 b=CzOSrPRN5jv4O7+uwoJ1w7Iz6aIW/lqMZgr47OrfJ67aX86qNOBeHde35+J6riUgV+mK494OJ4l3g2R0+CT8Qe7kTRGSt3GwLtnwG0Vo53MvC7h0bBvUy7icGDByTERuzf3KzuTzLuudlgbyEF7hKv5EKDyc8DLqBVCcZ5pnjc3joHe//aJPCGDDUtdiHf3VekV7S+LanLpj6246goO5+gyh+fQ9XQSUO/qcu85OFVA9Jx8hLrkgCABsM0L//iUJ47uQ0FhGEZIKDDm1hLJ29p4O0WngO16IV3p9M2k1qoNgGb0pPJZB8Jutc3tyFcgs5imIUfz9bEwApnaCHvgZcw==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 63.35.35.123) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=arm.com;
 dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com;
 dkim=pass (signature was verified) header.d=armh.onmicrosoft.com; arc=pass (0
 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com]
 dmarc=[1,1,header.from=arm.com])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com;
 s=selector2-armh-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=/4KqKIOk8g0hOmD/GWMr8JzUf1mB1Zm/zKmK/5XsM+k=;
 b=YdE46lpC9eXgoUbvDl0KdYd9VzWLJGwq74Fil/xbaotz5z3sKvghQmgsvbXlGT+j2LzvdzBOGlAv/G7UGoGvG2/VwAT9Hgi4o95SSKAAbLtYe6CJcODoZ72WRiBuGUVQE1GoGWr4WMEUbFe8lriQ5N3m8gBU66kxo3pBixvcuOk=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=armh.onmicrosoft.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 63.35.35.123 as permitted sender) receiver=protection.outlook.com;
 client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
 pr=C
X-CheckRecipientChecked: true
X-CR-MTA-CID: 312b1157eb7869de
X-CR-MTA-TID: 64aa7808
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=fmFdA13nsOD3Km4s6jat+Je7zdRzO0W45YN0AyQoJMX+Kl1zIKZn63LxxItURQYPggDwkgBIn2sY08pETpQ+TPRqjyBej1sWGylL9s//MkXcTMdxglrnnYutdF9zUYEg+gSPF84uIR59UgfoJGXENiWX9zo7PG5mpZ4qOIMX1NiR7PEYQX3VyoW6mtlerCjx3Kvqx2bFULAYjlx3B7Q32JaBh9dSOo6eh/wZQDG0Yyu+9g5PAco5ockXqbTadItWpdCOOePpFg3jyhkv9fqPmHXXK0Vbp26DTZ9+FzxjViOPe5GkIXte5NjvO9tOXYZCJiJgoVyimenOJVIe/xorPw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=/4KqKIOk8g0hOmD/GWMr8JzUf1mB1Zm/zKmK/5XsM+k=;
 b=OYjE7wK4NemkGKaAC30ih4G8bATHXAW1LjK4hTMug0tFYcbkY8a9LNYfeTVEWzATmdKOC6vdVQFTnJwpWJML66X6gSKEryn3upsOD4+sg11MMhSDcf9tcP09eBbR9SyZVdGNTNQuKVurIT/PQqCKnfDFUWJMQhzPcAwVpZlSabmcXti75AdkShzUMbOtfb//DigHpx/8Kb1Zfhps9c9R4+eHQ+A5wgoc5lmYMjpmBiKYDM/GZ+1a4fi3SAd4i5UeKzSfmccH8mVHFTc4CyuCsZb+97qzPOU5mVbHDN0rDsBO2liDwxB/Hpm3JtvkUiPA6uaqTnzVC2yzwk/IJdF7eg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass
 header.d=arm.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com;
 s=selector2-armh-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=/4KqKIOk8g0hOmD/GWMr8JzUf1mB1Zm/zKmK/5XsM+k=;
 b=YdE46lpC9eXgoUbvDl0KdYd9VzWLJGwq74Fil/xbaotz5z3sKvghQmgsvbXlGT+j2LzvdzBOGlAv/G7UGoGvG2/VwAT9Hgi4o95SSKAAbLtYe6CJcODoZ72WRiBuGUVQE1GoGWr4WMEUbFe8lriQ5N3m8gBU66kxo3pBixvcuOk=
From: Luca Fancellu 
To: Shawn Anastasio 
CC: "xen-devel@lists.xenproject.org" ,
	"tpearson@raptorengineering.com" , Jan
 Beulich 
Subject: Re: [PATCH v3 4/9] xen/ppc: Update setup.h with required definitions
 for bootfdt
Thread-Topic: [PATCH v3 4/9] xen/ppc: Update setup.h with required definitions
 for bootfdt
Thread-Index: AQHadl1F8erabWW43UiNIhzv59WNJbE4gWUA
Date: Fri, 15 Mar 2024 08:59:28 +0000
Message-ID: <21CE733E-0F62-41D1-9F9F-805AFA94DB01@arm.com>
References: 
 <2c14419bd9fbd5307fe4d5b079a9927e4d3ec9fc.1710443965.git.sanastasio@raptorengineering.com>
In-Reply-To:
 <2c14419bd9fbd5307fe4d5b079a9927e4d3ec9fc.1710443965.git.sanastasio@raptorengineering.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3774.400.31)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	AM6PR08MB3749:EE_|AS4PR08MB7501:EE_|DB5PEPF00014B9D:EE_|AS2PR08MB8877:EE_
X-MS-Office365-Filtering-Correlation-Id: d49681de-2191-47c8-21ab-08dc44ce3ee6
x-checkrecipientrouted: true
nodisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted: BCL:0;
X-Microsoft-Antispam-Message-Info-Original:
 MHimX+IHg7+J7qjIM0WyPKpHNjDfhOVcOsyXQ7OvHzAE4SA2N4uDTtJ6eQoUdpfXokS/uGR/0YlDtr8gbcw5CbgIFJfrj4EQpDfaIpDeOVaeJl5WNvBGEeVxmkJqdzkk26DROj1iF2rBahTkSEB8XqFL0jqe75E+FC1Uwc4rdxl3t4e26TpHEOolZ/jQGGfo4OI5HfDEVdnLd88BWw2Tyd7dONO+hDrJJWUdkS3bOvNquYgUxv3i5VWgSnDt0Sqot4pi9+JErTn8iFtnlh8WDBxmEfb9ndtxgTnRNzRtUuQTIsw00cZ4bjKRpo976CcraCRhcvndp3kbhpgGvhpHVsoHx25/rutNA/9ACNoZCCjHzwUkq9OLeByqcp8pv9O8CLgs3Fa0Qqk53ZFPiFT4mOa+jBaG4Wxp5pKeoDBoOvbellEQGxm1h3ioc6gLyEGDedQIkURyUXfcht2mPFJF79LN4fuH+W/UTouohyUZTSAx4uQPUc/RLVAgiKY8tL1o6pXScX5EP+LUwcuEKJ6BEtVFJr53zTjFS33RM5kcolb6znN2ffsWa6VWEa1EZwff5ugd4TMXIGxoTKcG/vXkK8srttlq6jqDItOtXa8R7u+gY9RxllPted/9eQZtXmGKf7mFXJsb0ht2eyOrn69rSysAVOK6DbtLDsyV75WpBdRMmu2H/fiN/2VvdqYVPfKf3rW8B3IY0LCPRe0ycZQVyS6jBRKkakV9xfcwUOtcBrA=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM6PR08MB3749.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(1800799015)(376005)(366007)(38070700009);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS4PR08MB7501
Original-Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 DB5PEPF00014B9D.eurprd02.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	2216249d-8c20-4862-9d3f-08dc44ce38da
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	NCX07U3LCglf44o0iyn/GjJvWYjmusrEOfWZw8lmnkH/b8F7gQKl6FWo5jCwdDR/7l03U+IOZMtxCA4itcaIG3rcYc7blRm4fP0o0uH5KekXrQH+f5cGZif6rubgIAGaXDKDZOXVrHjmETml+33RYjWCfsNA8nurt8QeI2AnU4wtz40Vbr+aprPewtb4RrMUyXQgjk3WUNNT5qUmbYWfwB7tGZMETqO9BmFkz0YTEc+MbpySx1Q7S2zdimoie7ZxHSpkWx4tOf2fx1HIrcZdCIVZsUAIbhHQZv1knDESiSmjWoKd85NGaMx/+KdE9HKipmvJwZWqwseSf/BKx74v2rahbZVssdZHlHJC9aOnQX9aID7IjXMyTO2pVJfDU9mil+gbm4xuRb5GHD+gxtYRb1Z369x7kEQ8YYYicPt5XFz0mYudhnN9pBsX4uP09p6eGDw70hus/Y1LcOxkMyPfOdTTNVU7JJqYTd1sHUup7O537rsfPU1EcoJItEZNxe9nVh53Mv1vJ7Z7MGuP+x4XvVpil+H2jdhAi6hfVvROruwrAV38V9KYuqqlEX/RUCfM6qzoYnsGDGk7CR2NxWeh408JruNUO0eciB+OocTNdpCH8d4X8IpISAMf0k1wujczCSHP57bY6v+T9cnbTuBAYrIcdbCCO4V8pmNqemY/3/U3pRTm6rVOTkdqRrlbGlQ0guTLlD0m1ySghk563AofaLg4PuATk4HJ72NPsp47z1DHE79bLKV/RffgvUw0z9Ev
X-Forefront-Antispam-Report:
	CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com;CAT:NONE;SFS:(13230031)(36860700004)(376005)(1800799015)(82310400014);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Mar 2024 08:59:38.8988
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: d49681de-2191-47c8-21ab-08dc44ce3ee6
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DB5PEPF00014B9D.eurprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR08MB8877

DQpIaSBTaGF3biwNCg0KPiBPbiAxNCBNYXIgMjAyNCwgYXQgMjI6MTUsIFNoYXduIEFuYXN0YXNp
byA8c2FuYXN0YXNpb0ByYXB0b3JlbmdpbmVlcmluZy5jb20+IHdyb3RlOg0KPiANCj4gQWRkIHRo
ZSBkZWZpbml0aW9ucyB1c2VkIGJ5IEFSTSdzIGJvb3RmZHQuYywgd2hpY2ggd2lsbCBiZSBtb3Zl
ZCBpbnRvDQo+IHhlbi9jb21tb24gaW4gYSBsYXRlciBwYXRjaCwgdG8gUFBDJ3Mgc2V0dXAuaC4N
Cj4gDQo+IFNpZ25lZC1vZmYtYnk6IFNoYXduIEFuYXN0YXNpbyA8c2FuYXN0YXNpb0ByYXB0b3Jl
bmdpbmVlcmluZy5jb20+DQo+IC0tLQ0KPiB4ZW4vYXJjaC9wcGMvaW5jbHVkZS9hc20vc2V0dXAu
aCB8IDExMiArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrDQo+IDEgZmlsZSBjaGFuZ2Vk
LCAxMTIgaW5zZXJ0aW9ucygrKQ0KPiANCj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3BwYy9pbmNs
dWRlL2FzbS9zZXR1cC5oIGIveGVuL2FyY2gvcHBjL2luY2x1ZGUvYXNtL3NldHVwLmgNCj4gaW5k
ZXggZTRmNjQ4NzliNi4uMWIyZDI5YzViNiAxMDA2NDQNCj4gLS0tIGEveGVuL2FyY2gvcHBjL2lu
Y2x1ZGUvYXNtL3NldHVwLmgNCj4gKysrIGIveGVuL2FyY2gvcHBjL2luY2x1ZGUvYXNtL3NldHVw
LmgNCj4gQEAgLTMsNCArMywxMTYgQEANCj4gDQo+ICNkZWZpbmUgbWF4X2luaXRfZG9taWQgKDAp
DQo+IA0KPiArI2luY2x1ZGUgPHB1YmxpYy92ZXJzaW9uLmg+DQo+ICsjaW5jbHVkZSA8YXNtL3Ay
bS5oPg0KPiArI2luY2x1ZGUgPHhlbi9kZXZpY2VfdHJlZS5oPg0KPiArDQo+ICsjZGVmaW5lIE1J
Tl9GRFRfQUxJR04gOA0KPiArI2RlZmluZSBNQVhfRkRUX1NJWkUgU1pfMk0NCj4gKw0KPiArI2Rl
ZmluZSBOUl9NRU1fQkFOS1MgMjU2DQo+ICsNCj4gKyNkZWZpbmUgTUFYX01PRFVMRVMgMzIgLyog
Q3VycmVudCBtYXhpbXVtIHVzZWZ1bCBtb2R1bGVzICovDQo+ICsNCj4gK3R5cGVkZWYgZW51bSB7
DQo+ICsgICAgQk9PVE1PRF9YRU4sDQo+ICsgICAgQk9PVE1PRF9GRFQsDQo+ICsgICAgQk9PVE1P
RF9LRVJORUwsDQo+ICsgICAgQk9PVE1PRF9SQU1ESVNLLA0KPiArICAgIEJPT1RNT0RfWFNNLA0K
PiArICAgIEJPT1RNT0RfR1VFU1RfRFRCLA0KPiArICAgIEJPT1RNT0RfVU5LTk9XTg0KPiArfSAg
Ym9vdG1vZHVsZV9raW5kOw0KPiArDQo+ICtlbnVtIG1lbWJhbmtfdHlwZSB7DQo+ICsgICAgLyoN
Cj4gKyAgICAgKiBUaGUgTUVNQkFOS19ERUZBVUxUIHR5cGUgcmVmZXJzIHRvIGVpdGhlciByZXNl
cnZlZCBtZW1vcnkgZm9yIHRoZQ0KPiArICAgICAqIGRldmljZS9maXJtd2FyZSAod2hlbiB0aGUg
YmFuayBpcyBpbiAncmVzZXJ2ZWRfbWVtJykgb3IgYW55IFJBTSAod2hlbg0KPiArICAgICAqIHRo
ZSBiYW5rIGlzIGluICdtZW0nKS4NCj4gKyAgICAgKi8NCj4gKyAgICBNRU1CQU5LX0RFRkFVTFQs
DQo+ICsgICAgLyoNCj4gKyAgICAgKiBUaGUgTUVNQkFOS19TVEFUSUNfRE9NQUlOIHR5cGUgaXMg
dXNlZCB0byBpbmRpY2F0ZSB3aGV0aGVyIHRoZSBtZW1vcnkNCj4gKyAgICAgKiBiYW5rIGlzIGJv
dW5kIHRvIGEgc3RhdGljIFhlbiBkb21haW4uIEl0IGlzIG9ubHkgdmFsaWQgd2hlbiB0aGUgYmFu
aw0KPiArICAgICAqIGlzIGluIHJlc2VydmVkX21lbS4NCj4gKyAgICAgKi8NCj4gKyAgICBNRU1C
QU5LX1NUQVRJQ19ET01BSU4sDQo+ICsgICAgLyoNCj4gKyAgICAgKiBUaGUgTUVNQkFOS19TVEFU
SUNfSEVBUCB0eXBlIGlzIHVzZWQgdG8gaW5kaWNhdGUgd2hldGhlciB0aGUgbWVtb3J5DQo+ICsg
ICAgICogYmFuayBpcyByZXNlcnZlZCBhcyBzdGF0aWMgaGVhcC4gSXQgaXMgb25seSB2YWxpZCB3
aGVuIHRoZSBiYW5rIGlzDQo+ICsgICAgICogaW4gcmVzZXJ2ZWRfbWVtLg0KPiArICAgICAqLw0K
PiArICAgIE1FTUJBTktfU1RBVElDX0hFQVAsDQo+ICt9Ow0KPiArDQo+ICsvKiBJbmRpY2F0ZXMg
dGhlIG1heGltdW0gbnVtYmVyIG9mIGNoYXJhY3RlcnMoXDAgaW5jbHVkZWQpIGZvciBzaG1faWQg
Ki8NCj4gKyNkZWZpbmUgTUFYX1NITV9JRF9MRU5HVEggMTYNCg0KTWF5YmUgeW91IGRvbuKAmXQg
bmVlZCB0aGlzIGRlZmluZQ0KDQoNClRoYXTigJlzIGEgYnVtbWVyIEnigJltIG1vZGlmeWluZyBh
IGxvdCB0aGlzIGhlYWRlciBpbiBvbmUgb2YgbXkgc2VyaWUgOikgaWYgdGhpcyBvbmUgZ29lcyBp
biBiZWZvcmUgbWluZQ0KSeKAmWxsIGhhdmUgdG8gdG91Y2ggeW91ciBoZWFkZXJzLiBOb3QgYSBw
cm9ibGVtIHRob3VnaC4NCg0KQ2hlZXJzLA0KTHVjYQ0KDQoNCg0K


From xen-devel-bounces@lists.xenproject.org Fri Mar 15 09:12:56 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 09:12:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693703.1082088 (Exim 4.92)
	(envelope-from )
	id 1rl3cP-0004XH-S9; Fri, 15 Mar 2024 09:12:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693703.1082088; Fri, 15 Mar 2024 09:12:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl3cP-0004XA-NG; Fri, 15 Mar 2024 09:12:49 +0000
Received: by outflank-mailman (input) for mailman id 693703;
 Fri, 15 Mar 2024 09:12:49 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rl3cP-0004X1-0G
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 09:12:49 +0000
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com
 [2a00:1450:4864:20::629])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2f0cdb41-e2ac-11ee-a1ee-f123f15fe8a2;
 Fri, 15 Mar 2024 10:12:44 +0100 (CET)
Received: by mail-ej1-x629.google.com with SMTP id
 a640c23a62f3a-a449c5411e1so239191466b.1
 for ; Fri, 15 Mar 2024 02:12:45 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 h21-20020a17090619d500b00a46447348e8sm1510700ejd.191.2024.03.15.02.12.43
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 15 Mar 2024 02:12:44 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2f0cdb41-e2ac-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710493964; x=1711098764; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=jVOgakGe8faeutUV1zRVP7AxkFZ6opIywJfJEZvuySI=;
        b=cGJcag21FPF31XowVnHlhF5NwyDRLapFoDBrYRvRPc2+31P3dtIOYsN1v5QNP9cgBK
         M0W4rdhqnm8Ck5Dc67jy8CBSNk+A5hQAqO03oPFeG1gPkpErfTYf522L9LUUREgD+GRT
         2Gg2UMurxeCZfUu/QI2Ltadq4d1rTHVIUSXSvsl9n9EaixrKPG7SyA69Kuh6YHOL+gWM
         Hc4QA+Q7uvNhV4F32NHk/bD/ojDsiYrJd/zttxsaK0R+9seZlnxwjoZ55edBSHu47yQe
         OPRxDD+4vXIKvtHTlN366A0Ayt5L4NtFhBjfcelXot30N5LEzda1hDT7O8WdYJXvNQwA
         gZGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710493964; x=1711098764;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=jVOgakGe8faeutUV1zRVP7AxkFZ6opIywJfJEZvuySI=;
        b=YFVAccTAogZs5C4GUxRzfMf/AxpQZvq4sPQK6F0l2ArjJaXPaAKW9RRooB9slq0rWe
         9rSaw3Bh2vbQmhTK1NCBb1dvhIcWF5q1QvjNkzQJaUk83aQq6j8Vmsy4IuA7lqwV27Us
         jQXk8R6ZpMK02goqaTKI6vmMHiSzj6tvgqfMLWUVjRQ3BPf7HXZLNpG1BHXUL6G0JpAw
         zXaBbH3vE10eli+TFKBSJQOxfMLC4Ux2qIgN3drD0hyw4xmwyXTXreVVTTB3D7vM4SJT
         +TTU2JvL7u9ILsYiY5fxZClgPdrOgNOTMHVaaRHmPfXhdMR3BESt3YIn63ulp+SAhjnN
         z2Vg==
X-Forwarded-Encrypted: i=1; AJvYcCWCibu/nBVnzpMc5fJuRXlO6jAoJYtyGniTS2ESXliZgKqKKknTRRSy+JLS28EiHb0QKWi9/TXKpBTOUjzeH8C9PlDQ7tj/keO3zCzxPFI=
X-Gm-Message-State: AOJu0YzrWtmYxfVCMhuZxQB7QCbWKoBSbStw3/J1JFwzdWb6rqd2ErgE
	ww6OumhGAb0bIE5thp33XWbRRekKLkFaCOpBn0DfMHGRGbnv2QQHWU4voxg7WQ==
X-Google-Smtp-Source: AGHT+IFGmhPGHf8xubxpEjvi8G1D1dt3RI7nSybuQy9yeA/Hkmp8/13SoUQlQ6sM6Xde7510j8u+WQ==
X-Received: by 2002:a17:906:3545:b0:a46:1fb:1df with SMTP id s5-20020a170906354500b00a4601fb01dfmr2642544eja.42.1710493964451;
        Fri, 15 Mar 2024 02:12:44 -0700 (PDT)
Message-ID: 
Date: Fri, 15 Mar 2024 10:12:42 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH] automation/eclair: allow parameter name "unused"
Content-Language: en-US
To: Federico Serafini 
Cc: consulting@bugseng.com, Simone Ballarin ,
 Doug Goldstein ,
 Stefano Stabellini ,
 Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Wei Liu , xen-devel@lists.xenproject.org
References: 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 14.03.2024 17:35, Federico Serafini wrote:
> --- a/docs/misra/deviations.rst
> +++ b/docs/misra/deviations.rst
> @@ -157,6 +157,11 @@ Deviations related to MISRA C:2012 Rules:
>           - xen/common/unxz.c
>           - xen/common/unzstd.c
>  
> +   * - R8.3
> +     - Parameter name "unused" is deliberate and makes explicit the intention
> +       of not using the parameter within the function.
> +     - Tagged as `deliberate` for ECLAIR.

Before writing this, did you consider what is going to happen when a
function happens to have more than one unused parameter? They can't all
be named "unused", so some flexibility is needed here. E.g. by permitting
a number to be appended.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Mar 15 09:16:33 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 09:16:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693705.1082097 (Exim 4.92)
	(envelope-from )
	id 1rl3g0-00056v-9A; Fri, 15 Mar 2024 09:16:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693705.1082097; Fri, 15 Mar 2024 09:16:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl3g0-00056o-5i; Fri, 15 Mar 2024 09:16:32 +0000
Received: by outflank-mailman (input) for mailman id 693705;
 Fri, 15 Mar 2024 09:16:30 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rl3fy-00056b-Np
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 09:16:30 +0000
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com
 [2a00:1450:4864:20::62e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b47066f1-e2ac-11ee-a1ee-f123f15fe8a2;
 Fri, 15 Mar 2024 10:16:28 +0100 (CET)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-a466f89560eso217391766b.3
 for ; Fri, 15 Mar 2024 02:16:28 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 jo26-20020a170906f6da00b00a45f63d2959sm1509823ejb.210.2024.03.15.02.16.27
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 15 Mar 2024 02:16:28 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b47066f1-e2ac-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710494188; x=1711098988; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=0hdcfZXt+BfhaR+5vj1AtvNow29vmEI8shV/8Y9XsK4=;
        b=IkAc7qxrmFOk+3q8q4aB3UngiZyHgf/KVbNgldY1K9vxqIUJshx9ViohK88XYALdH8
         g8SWaMgTkWnH6cKNkSmJ+a9dJmvBPmP6yJYYH2TDh6aLkYVLvJtCs3agnDVM8WjW4miR
         3Us7Xa362Qzm4OMalkikt36zhvejNz4q/IheudTWeMXerukWJ28Ir1N0IiNtD+DIMdPe
         a1yRpj0Ps9P4KnwM/eihhlGaeQ4STls+vBvdqUU103CiHJYPV5qswqlGg+zQoLEAPZZY
         EV7bGOx1b2I0lRUFUtBRSgUskIjpKZQ7UUy1cessfvwwGvG0hWWFSVeyF00dGJI0Xi7w
         2sxA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710494188; x=1711098988;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=0hdcfZXt+BfhaR+5vj1AtvNow29vmEI8shV/8Y9XsK4=;
        b=nKq3kQWDoiEaYCUfoJRN452fugBZzOMZBSPxgPmpQQWjOzBNSSrIwB/M9RIDmOwPc6
         fO2oiU8Ks4Nk1QUKrboISaL+aHJhO0dfOyqw8JHSlvWnVhUs1EaG1b1J0DRSa+3s4o91
         ADzss/Br/T/mJbeZP/wHRpcQtzdoh9OSf87F5ab8nHlJQbHBe+/zF4msi6wYmO936/KO
         1IQ4IhIDEfXEXW9/WjQjfTkgc2VLvTFTkaybgSYYYxBOruQbYx1supIOBTRwYDfg7LLE
         +HMXrwshgihWl+hU5iHGheM9mAiZosXcixDns62C+P8bqzmrDL9/dgmSka3I6QC3Z0Vp
         2aoA==
X-Forwarded-Encrypted: i=1; AJvYcCV1gHb6wWVk45ZODMaPJLLIGdjF5pr8r7S2fcc4yUiDAlAPmBDdpD10Tbms6S85p3O8+kyqJI8FmKYXvX8+IxPwMzV41HvMCvoCJeWYPcg=
X-Gm-Message-State: AOJu0YwSqi2rBuVe79cMivGSzqgrw2lWuduDNHpyUFd9IiY08rYETUOX
	mOJOj9ZNmAPZz8xxgPizskozgB2eajDh37uKap84gXZkSXyeL8msaEE2/AkWXA==
X-Google-Smtp-Source: AGHT+IEdXWF6zuyRlPEeIIohOi3bLNcjKdTXo1CEPzeyiWowRjdJ7XHTUW1G2BIphG//lI8mIo70Rw==
X-Received: by 2002:a17:906:a40c:b0:a46:2874:ecd5 with SMTP id l12-20020a170906a40c00b00a462874ecd5mr2472107ejz.55.1710494188344;
        Fri, 15 Mar 2024 02:16:28 -0700 (PDT)
Message-ID: <152e76ee-6e75-4881-aa88-313f0ae058be@suse.com>
Date: Fri, 15 Mar 2024 10:16:26 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 5/9] xen/device-tree: Move Arm's setup.c bootinfo
 functions to common
Content-Language: en-US
To: Shawn Anastasio 
Cc: tpearson@raptorengineering.com, Andrew Cooper
 , George Dunlap ,
 Julien Grall , Stefano Stabellini ,
 Wei Liu , Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 "Daniel P. Smith" ,
 xen-devel@lists.xenproject.org
References: 
 <039524d4157dddb2faf6887739a727f6e993b53f.1710443965.git.sanastasio@raptorengineering.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <039524d4157dddb2faf6887739a727f6e993b53f.1710443965.git.sanastasio@raptorengineering.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 14.03.2024 23:15, Shawn Anastasio wrote:
> Arm's setup.c contains a collection of functions for parsing memory map
> and other boot information from a device tree. Since these routines are
> generally useful on any architecture that supports device tree booting,
> move them into xen/common/device-tree.
> 
> Suggested-by: Julien Grall 
> Signed-off-by: Shawn Anastasio 
> ---
>  MAINTAINERS                       |   1 +
>  xen/arch/arm/setup.c              | 419 --------------------------
>  xen/common/Makefile               |   1 +
>  xen/common/device-tree/Makefile   |   1 +
>  xen/common/device-tree/bootinfo.c | 469 ++++++++++++++++++++++++++++++
>  5 files changed, 472 insertions(+), 419 deletions(-)
>  create mode 100644 xen/common/device-tree/Makefile
>  create mode 100644 xen/common/device-tree/bootinfo.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 56a6932037..e85fbe6737 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -301,6 +301,7 @@ M:	Stefano Stabellini 
>  M:	Julien Grall 
>  S:	Supported
>  F:	xen/common/libfdt/
> +F:	xen/common/device-tree/setup.c

Perhaps more generally

F:	xen/common/device-tree/

?

Jan


From xen-devel-bounces@lists.xenproject.org Fri Mar 15 09:19:42 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 09:19:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693708.1082106 (Exim 4.92)
	(envelope-from )
	id 1rl3iz-000611-Ld; Fri, 15 Mar 2024 09:19:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693708.1082106; Fri, 15 Mar 2024 09:19:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl3iz-00060u-J9; Fri, 15 Mar 2024 09:19:37 +0000
Received: by outflank-mailman (input) for mailman id 693708;
 Fri, 15 Mar 2024 09:19:35 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rl3ix-00060o-TS
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 09:19:35 +0000
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com
 [2a00:1450:4864:20::630])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 22a950c6-e2ad-11ee-a1ee-f123f15fe8a2;
 Fri, 15 Mar 2024 10:19:33 +0100 (CET)
Received: by mail-ej1-x630.google.com with SMTP id
 a640c23a62f3a-a46682e71a9so181300466b.3
 for ; Fri, 15 Mar 2024 02:19:33 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 er18-20020a056402449200b0056899fc9a94sm1504499edb.12.2024.03.15.02.19.32
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 15 Mar 2024 02:19:32 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 22a950c6-e2ad-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710494373; x=1711099173; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=+FH6yDcVL14ZMcRgd2DqD8HoFaUa7nMaki9Jh2GhZLs=;
        b=XQ/EYcsmpzGjOPKkyFC28Ye7CIMkMymw1uMFKMTFWQ3J+b6k1NX9sTPCA8pYw2bn7Y
         8X8duEuJ9TQmzi4WgZ50uZOeUJvPW9UWIEnSdHwwwH7gKBzZ+KuK5ex9lBs9thnxHP76
         5KCxIN00Ue3f//kJwC7DIHRZcwrEEgUza1x1PmIntOUci9weih30OkDbsSewIyijSS12
         khBsgs+cOyTByK1gz9K0Df9hOMW9JYRQ7pTDBZwA1CFvCjVEqxqd/3YN9bkExz+uT34E
         /qOTfIp/A86IB83hU8NEw8xxzsAvwK1hTEqBYt9wx9OPE0Wj36D9grBkgpiH2SrVzXh2
         JiRw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710494373; x=1711099173;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=+FH6yDcVL14ZMcRgd2DqD8HoFaUa7nMaki9Jh2GhZLs=;
        b=e0RpLfHK/X/SWYzO0qfgqD85PqnbUhzLUId/7CLHt9+4RWtb3v2Wwd/mcS7g5jiFUC
         zi/5COlNQXteOx2pyV4VDqsDLm3w3ihkf+68CRB/CKSMnPPOvbT+sd2YgRJEUOZTEUtW
         f/hmmjBz5MM4EvcoapNZcp0gAn/xNETTwInKgGUl5FKbsQ02Gtbu+71tfcFJ/nffE5PN
         WXDkYKgWkGYdtkD+mcO4yGrqxuUgU6osXdiy8rDB093FFj3j5xpjN3+NYak7oMNT89c8
         V7bj/XIovfBKEYtCqfRcYJfrU4JmCt60o7bH4yC9zIFi90mDB/DsVSMvhbvVmugvYPzO
         8f/Q==
X-Forwarded-Encrypted: i=1; AJvYcCUcbSPUQxi7UwKm7+613PxrD0g+Nc8iPqcYPSsxgeIhAZPS0SwQoGnGa0F9g5qUbBYbQVDcZV07zL7Otd6xnjp7fvI46ZJiFVEosVijWto=
X-Gm-Message-State: AOJu0YzlJaENtxkfGDJv1YIWneZzuS3x3q6JidWD1xRpQ5wIuc3P1X2E
	V2rhW8ywiAQvI4LRNG0+bdz91mVSZky7TsfVgZJTXU8X4cifJKtBeTBFFIROkg==
X-Google-Smtp-Source: AGHT+IGGZx9URRUGlB985Jfa21wvgb9Uf38mxIs50/v+5Z+e/PqSLsI0x8dnJSO3H2YSYXo9frVTYw==
X-Received: by 2002:a05:6402:388a:b0:568:abe3:52b2 with SMTP id fd10-20020a056402388a00b00568abe352b2mr1541840edb.23.1710494373235;
        Fri, 15 Mar 2024 02:19:33 -0700 (PDT)
Message-ID: <077c0373-6eec-4403-b31e-574c8e8ae067@suse.com>
Date: Fri, 15 Mar 2024 10:19:31 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH v3 03/16] misra: add deviations for direct inclusion
 guards
Content-Language: en-US
To: Stefano Stabellini 
Cc: consulting@bugseng.com, Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Wei Liu , Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org, Simone Ballarin 
References: 
 <1fdfec12fd2207c294f50d01d8ec32f890b915d7.1710145041.git.simone.ballarin@bugseng.com>
 
 <6472eb42-157a-4d6e-b5bb-daa74fbbd97b@bugseng.com>
 
 <3e4bb597-3624-418e-93d0-b95042fd27a7@bugseng.com>
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 14.03.2024 23:59, Stefano Stabellini wrote:
> On Mon, 11 Mar 2024, Simone Ballarin wrote:
>> On 11/03/24 14:56, Jan Beulich wrote:
>>> On 11.03.2024 13:00, Simone Ballarin wrote:
>>>> On 11/03/24 11:08, Jan Beulich wrote:
>>>>> On 11.03.2024 09:59, Simone Ballarin wrote:
>>>>>> --- a/xen/arch/arm/include/asm/hypercall.h
>>>>>> +++ b/xen/arch/arm/include/asm/hypercall.h
>>>>>> @@ -1,3 +1,4 @@
>>>>>> +/* SAF-5-safe direct inclusion guard before */
>>>>>>    #ifndef __XEN_HYPERCALL_H__
>>>>>>    #error "asm/hypercall.h should not be included directly - include
>>>>>> xen/hypercall.h instead"
>>>>>>    #endif
>>>>>> --- a/xen/arch/x86/include/asm/hypercall.h
>>>>>> +++ b/xen/arch/x86/include/asm/hypercall.h
>>>>>> @@ -2,6 +2,7 @@
>>>>>>     * asm-x86/hypercall.h
>>>>>>     */
>>>>>>    +/* SAF-5-safe direct inclusion guard before */
>>>>>>    #ifndef __XEN_HYPERCALL_H__
>>>>>>    #error "asm/hypercall.h should not be included directly - include
>>>>>> xen/hypercall.h instead"
>>>>>>    #endif
>>>>>
>>>>> Iirc it was said that this way checking for correct guards is suppressed
>>>>> altogether in Eclair, which is not what we want. Can you clarify this,
>>>>> please?
>>>>>
>>>>
>>>> My first change was moving this check inside the guard.
>>>> You commented my patch saying that this would be an error because someone
>>>> can
>>>> include it directly if it has already been included indirectly.
>>>> I replied telling that this was the case also before the change.
>>>> You agreed with me, and we decided that the correct thing would be fixing
>>>> the
>>>> check and not apply my temporary change to address the finding.
>>>>
>>>> Considering that the code should be amended, a SAF deviation seems to me
>>>> the most appropriate way for suppressing these findings.
>>>
>>> Since I don't feel your reply addresses my question, asking differently:
>>> With
>>> your change in place, will failure to have proper guards (later) in these
>>> headers still be reported by Eclair?
>>
>> No, if you put something between the check and the guard,
>> no violation will be reported.
> 
> From this email exchange I cannot under if Jan is OK with this patch or
> not.

Whether I'm okay(ish) with the patch here depends on our position towards
the lost checking in Eclair mentioned above. To me it still looks relevant
that checking for a guard occurs, even if that isn't first in a file for
some specific reason.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Mar 15 09:25:08 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 09:25:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693711.1082116 (Exim 4.92)
	(envelope-from )
	id 1rl3oF-0007WY-Az; Fri, 15 Mar 2024 09:25:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693711.1082116; Fri, 15 Mar 2024 09:25:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl3oF-0007WR-8I; Fri, 15 Mar 2024 09:25:03 +0000
Received: by outflank-mailman (input) for mailman id 693711;
 Fri, 15 Mar 2024 09:25:03 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rl3oE-0007WL-Uq
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 09:25:02 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e61e3328-e2ad-11ee-afdd-a90da7624cb6;
 Fri, 15 Mar 2024 10:25:01 +0100 (CET)
Received: from [192.168.1.113] (93-36-220-117.ip62.fastwebnet.it
 [93.36.220.117])
 by support.bugseng.com (Postfix) with ESMTPSA id C3FD54EE073C;
 Fri, 15 Mar 2024 10:25:00 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e61e3328-e2ad-11ee-afdd-a90da7624cb6
Message-ID: 
Date: Fri, 15 Mar 2024 10:25:00 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH] automation/eclair: allow parameter name "unused"
Content-Language: en-US, it
To: Jan Beulich 
Cc: consulting@bugseng.com, Simone Ballarin ,
 Doug Goldstein ,
 Stefano Stabellini ,
 Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Wei Liu , xen-devel@lists.xenproject.org
References: 
 
From: Federico Serafini 
Organization: BUGSENG
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 15/03/24 10:12, Jan Beulich wrote:
> On 14.03.2024 17:35, Federico Serafini wrote:
>> --- a/docs/misra/deviations.rst
>> +++ b/docs/misra/deviations.rst
>> @@ -157,6 +157,11 @@ Deviations related to MISRA C:2012 Rules:
>>            - xen/common/unxz.c
>>            - xen/common/unzstd.c
>>   
>> +   * - R8.3
>> +     - Parameter name "unused" is deliberate and makes explicit the intention
>> +       of not using the parameter within the function.
>> +     - Tagged as `deliberate` for ECLAIR.
> 
> Before writing this, did you consider what is going to happen when a
> function happens to have more than one unused parameter? They can't all
> be named "unused", so some flexibility is needed here. E.g. by permitting
> a number to be appended.

Right, thanks for the observation.

-- 
Federico Serafini, M.Sc.

Software Engineer, BUGSENG (http://bugseng.com)


From xen-devel-bounces@lists.xenproject.org Fri Mar 15 09:34:49 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 09:34:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693716.1082126 (Exim 4.92)
	(envelope-from )
	id 1rl3xd-00013T-4Q; Fri, 15 Mar 2024 09:34:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693716.1082126; Fri, 15 Mar 2024 09:34:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl3xd-00013M-11; Fri, 15 Mar 2024 09:34:45 +0000
Received: by outflank-mailman (input) for mailman id 693716;
 Fri, 15 Mar 2024 09:34:44 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rl3xc-00013G-79
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 09:34:44 +0000
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com
 [2a00:1450:4864:20::634])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 40b20d66-e2af-11ee-afdd-a90da7624cb6;
 Fri, 15 Mar 2024 10:34:42 +0100 (CET)
Received: by mail-ej1-x634.google.com with SMTP id
 a640c23a62f3a-a449c5411e1so242193966b.1
 for ; Fri, 15 Mar 2024 02:34:42 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 sa15-20020a1709076d0f00b00a45bbeeea9asm1514832ejc.167.2024.03.15.02.34.41
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 15 Mar 2024 02:34:42 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 40b20d66-e2af-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710495282; x=1711100082; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=dhjjVOC80pNyBwiTU+xpcfNzWvp0QP/7r2RStgUYOWI=;
        b=XwfiDxiKEZctADj2rDtK0rcI0fVEVGpETFZEM3JjK0psHL+aSxMhm2woF+mCTvrcCh
         /WeLGxSIM8oWEJAuc0ODyVJNPyRmEMLamwpT2u6EkcB9KWgNWmtqxGmSg5ofMqNnDvmf
         eyQXlQT6bTx5FV56QUwSmRxSaOIVMP31gmT1vHdaqOuLiH1HPUWedMVexbeA8e7UadrB
         CbhmhjSIXCD+sFCRAKgRHG0XGYrM1QjKk4o5H2NK3gKPTEIh9622/xZBSZGXjxPJcDLd
         CUu8FE/xR7AOdKoiUCBVbUXIUymyIQnD+oxG+8gA2lGzk7+RvjXsGWfcK4xq4pVyNiQZ
         VHNA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710495282; x=1711100082;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=dhjjVOC80pNyBwiTU+xpcfNzWvp0QP/7r2RStgUYOWI=;
        b=V4pwB3NU0Q8fNs0SQilSs508LKtDn3qqOsgYZEzbjI+HTA8l8MlyyrlWIGqxV/CJ3l
         PuKAFasjZlzeL3V7+UNos3m/GwaesSu4DmbO0HJq+GT7JaSHQuCM35Lxm3mraOGi7mKi
         l7FZZKFs+YkZOpNOaDYLYsb4Kd9doq5h+g0qaBMut1tTkB/oor26xDsH401ga19U0gLP
         kBkxbd/ilL4HfK7CZbVKvJhgotvx1Ms6jSXx7ghRXUC1Sd3675tkuXmqca5+BGVrgZxS
         DaN4QbMy+QDOQNoyJct1kLJzZwbAmJBoMQ+H/C3RcLuK+KlT+N6GowuhR3JwagIVTnZy
         a6iw==
X-Forwarded-Encrypted: i=1; AJvYcCWFOzYgbn0szv0yFfsGmT9NYfxTVm04MS0Kz7DrT0jWuDMkpw559EZN27Z7OcaqkuBq6EAPs6ap1PqzlVocGxjRFPpy6shvuCwvGSDguAI=
X-Gm-Message-State: AOJu0YzuMGs1HAi2YVMLL12R+w2FNCdQjf+4gNisA+wQXgTIPiZ6mTRQ
	phCq4HkD6EsNYQiwRWwLiBJGrLlp5NvtQOzHc2XsU/PmT2A8cYlbyPK987/1CQ==
X-Google-Smtp-Source: AGHT+IHLkBNfzonNvhwYRmmMfxkDb1+FfnTIizyDzKMhmmkykGxyIvEnB4xtU5ydmZFT2CqI0Nooag==
X-Received: by 2002:a17:906:6a1c:b0:a46:8d93:6c4d with SMTP id qw28-20020a1709066a1c00b00a468d936c4dmr590268ejc.25.1710495282445;
        Fri, 15 Mar 2024 02:34:42 -0700 (PDT)
Message-ID: <5a4533e5-c6f3-418c-811b-2bd0a631f1ad@suse.com>
Date: Fri, 15 Mar 2024 10:34:40 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3] docs/misra/rules.rst: add rule 5.5
Content-Language: en-US
To: Stefano Stabellini 
Cc: andrew.cooper3@citrix.com, bertrand.marquis@arm.com,
 george.dunlap@citrix.com, julien@xen.org, michal.orzel@amd.com,
 roger.pau@citrix.com, xen-devel@lists.xenproject.org
References: 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 15.03.2024 01:35, Stefano Stabellini wrote:
> --- a/docs/misra/rules.rst
> +++ b/docs/misra/rules.rst
> @@ -181,6 +181,21 @@ maintainers if you want to suggest a change.
>         headers (xen/include/public/) are allowed to retain longer
>         identifiers for backward compatibility.
>  
> +   * - `Rule 5.5 `_
> +     - Required
> +     - Identifiers shall be distinct from macro names
> +     - Macros expanding to their own name are allowed, e.g.::
> +
> +           #define x x
> +
> +       Clashes between names of function-like macros and identifiers of
> +       non-callable entities are allowed. Callable entities having an
> +       identifier that is the same of the name of a
> +       function-like macro are not allowed. Example (not allowed)::
> +
> +           #define f(x, y) f(x, y);

The semicolon here wants dropping, just to not give questionable constructs
as examples.

> +           void f(int x, int y);

With this not allowed and there (iirc) being examples of such in the code,
I'll be curious how it is meant to deal with them.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Mar 15 09:41:25 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 09:41:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693719.1082136 (Exim 4.92)
	(envelope-from )
	id 1rl43u-0002mo-PV; Fri, 15 Mar 2024 09:41:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693719.1082136; Fri, 15 Mar 2024 09:41:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl43u-0002mh-Mj; Fri, 15 Mar 2024 09:41:14 +0000
Received: by outflank-mailman (input) for mailman id 693719;
 Fri, 15 Mar 2024 09:41:13 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rl43t-0002mb-Bm
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 09:41:13 +0000
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com
 [2a00:1450:4864:20::52e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 283aa5b9-e2b0-11ee-a1ee-f123f15fe8a2;
 Fri, 15 Mar 2024 10:41:11 +0100 (CET)
Received: by mail-ed1-x52e.google.com with SMTP id
 4fb4d7f45d1cf-568a9c331a3so984948a12.0
 for ; Fri, 15 Mar 2024 02:41:11 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 es8-20020a056402380800b00568afb0e731sm410668edb.63.2024.03.15.02.41.10
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 15 Mar 2024 02:41:10 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 283aa5b9-e2b0-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710495671; x=1711100471; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=teJnyWDQr2oaTGWwL+dBcI4Yobw/suAYoMyuPznVkAc=;
        b=DiX/IOMawDU86xF/O6YXCpZp8WWc7JvsGxE9UPrknfpp5Wwk1y9wtIkbyHzc1fQC9L
         0SplM/5rBDD9mz5XsY9MxOIboyKI3/J/0neUaJiPoymuI1Ze1SA1bQvRPllxa+lWOwkW
         8k/vtRo8Tl6LzR7bBJ8dCuOInXifIVIUbSx0KLNEkmIlDoIf6w5Z6e+t6gyxkW/3NXQ2
         u9mGlqKA94ea4j6ReNvpTuQ7aP2kSxxk9Hbo7IfZ6gMahA4LEnCh0/dVCfkNMVAwAIqq
         U0FE0jYi78d/gZ5M49+tOpWgNLSk4pMIz5y3rbFIcuGp9nO9Ubc0ZcGKTEjFrtXv1U7o
         XnZg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710495671; x=1711100471;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=teJnyWDQr2oaTGWwL+dBcI4Yobw/suAYoMyuPznVkAc=;
        b=aJ6zxCUdtjJ6e6OADPPPIUJAuer2i855PxY8au82B7S+n7CqZk5nJO0fOCojwQHuru
         cGme50KdSoOkLU5cbgjGT/Usf9Axo6RkXIFv8wrqJqDs2M5PIr8iOpAP5b3k+hJkD+Le
         t4vnXrjWFHnpB3sYtTbcAyxmKqvqDLm1JhAAyTqsiRpRiuiGj013XZAIqPE1/gKdvysa
         SiwCG2v1B3+t2qaWQEA0hiT+HbSc944RFeoWJL8tkB5qFk9mSftcIMXGcnoxFacy4UIA
         bOPgRm3I5Iuvgu6KQp3TTfB/DjHDnIJZhZMt55ZBNTgEszBPOTLvGUsW5E3gh2GUdoef
         PD9g==
X-Forwarded-Encrypted: i=1; AJvYcCVbKL0K58sM4I44VxI3LzOdJkM4uGpMi0yXrErAUSdBSId6VEbc88J7PSWvtXvY6xC9YSrU7eRNuEv8xe8eV+dyEigqxiHTFGGDjG7oHhs=
X-Gm-Message-State: AOJu0YygdMpGc1lsB34adhLadLHn9X3YehfWlMlQ72ufxA/nCRrCgkj2
	XeH4nXrYdZSyHQ10hvdczyHm9t1uAJlD54M+4Iva57hulChCM9gw7O4OIe6W3Q==
X-Google-Smtp-Source: AGHT+IGbx8q4GVgXeOD+o0CxbRx07eT9Nw8gmt7lUBAYEvKqMQQplzoJsgzpF0hiBo5P8VCCavkuFw==
X-Received: by 2002:a05:6402:538f:b0:564:dd13:56e9 with SMTP id ew15-20020a056402538f00b00564dd1356e9mr3332585edb.29.1710495670791;
        Fri, 15 Mar 2024 02:41:10 -0700 (PDT)
Message-ID: <6a76723e-ba47-40b3-8f33-d68030b14299@suse.com>
Date: Fri, 15 Mar 2024 10:41:09 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] docs/misra: document the expected sizes of integer
 types
Content-Language: en-US
To: Stefano Stabellini 
Cc: andrew.cooper3@citrix.com, bertrand.marquis@arm.com,
 george.dunlap@citrix.com, julien@xen.org, michal.orzel@amd.com,
 roger.pau@citrix.com, xen-devel@lists.xenproject.org
References: 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 14.03.2024 23:17, Stefano Stabellini wrote:
> Xen makes assumptions about the size of integer types on the various
> architectures. Document these assumptions.

My prior reservation wrt exact vs minimum sizes remains. Additionally,
is it really meaningful to document x86-32 as an architecture, when it's
been many years that the hypervisor cannot be built anymore for that
target? If it's not (just) the hypervisor build that's intended to be
covered here (the file living under docs/misra/, after all), can that
further purpose please be mentioned?

Jan


From xen-devel-bounces@lists.xenproject.org Fri Mar 15 09:48:14 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 09:48:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693722.1082146 (Exim 4.92)
	(envelope-from )
	id 1rl4Ac-0003bs-CZ; Fri, 15 Mar 2024 09:48:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693722.1082146; Fri, 15 Mar 2024 09:48:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl4Ac-0003bl-A2; Fri, 15 Mar 2024 09:48:10 +0000
Received: by outflank-mailman (input) for mailman id 693722;
 Fri, 15 Mar 2024 09:48:09 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rl4Ab-0003bf-BL
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 09:48:09 +0000
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com
 [2a00:1450:4864:20::52c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2022290b-e2b1-11ee-a1ee-f123f15fe8a2;
 Fri, 15 Mar 2024 10:48:07 +0100 (CET)
Received: by mail-ed1-x52c.google.com with SMTP id
 4fb4d7f45d1cf-568a5e15ae8so1500394a12.0
 for ; Fri, 15 Mar 2024 02:48:07 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a13-20020a170906684d00b00a4646051f25sm1514861ejs.203.2024.03.15.02.48.06
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 15 Mar 2024 02:48:06 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2022290b-e2b1-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710496087; x=1711100887; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=gD/Pc9X6PfFxpUAKaLZpaRNJBs5DNUIe8R8bnxvxUvQ=;
        b=PSV4eXLl68BtB0O5u68QV48K9kVlRTjMzAtvXE+aRoo1I1kNOcMd+L7Zk20M1HhuSg
         rYBG58yo2zl/zC0XGPbF5O1JtTmZpwJz37BZ8UZfJOQ8SMISq0TQ0mmKhkOqwO9MCROD
         mFcktLoRm9yCReLI7bhvVL4x0dz+9VI5h3aHMmKObGF5uCN0V5pPZxbOTGI8xLoE7kT/
         41+EnyiCv8TFOaA5Vj4GKVG7KfO7DropTk16EFuMfp4goY+UbkMhXHsUSyPzV6htpnqu
         BuNkYNKXnkEFIAqlpkQIWXg/V8L7xYDgOz+cVjaAUCyXnpepwlXF+ZJI979/ubyo9xzY
         12Hw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710496087; x=1711100887;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=gD/Pc9X6PfFxpUAKaLZpaRNJBs5DNUIe8R8bnxvxUvQ=;
        b=Y82Jo0N44jX53OeLes4ty++kVNlppFceghDEShUxPP1tef7Lx2YmHCcc05e+ixhYK2
         5Z00x6PDrLh5sdw8a7t54UobmuZimgYNao2GisCQ9v5azKvKtGqNL9sjZrWgLdlyqiRf
         GKPjE5JwQ4amZopULVwaJKMxOVgopC3eo72za9TTKLVKOZlMlYcU9TNwRAp7qTxcXZs8
         4qPw3C4gJvGpXQu9O/9QIMpV044PZQTm330oF3UeZjH4W+T72a2UlnJQhgRVEyC/+eZb
         +kb9gB5hNzx3MTzIIVVfkVwEofPXS14gsKxQzTbtIRE/m0ZFrTrwjRjXnrI7OxnyKvBc
         yZug==
X-Forwarded-Encrypted: i=1; AJvYcCX+sbhgy4/a5TAdoyfok3KnxWytLDMr7AZkSRtmf7BSwOP/dhrdjLMiUeFFt7SbKrRajAkOysGA4pU50xbPCwdQqAv/X9XeZ2PdhCiULns=
X-Gm-Message-State: AOJu0YzMqQgyBVQ1UbjzJQOb+FAoI19Wj+11lOCUJqEWvIoDKW4zDzEj
	zyXylqGzrriDnsyJMCq3yNebIxO4Xl4c2L+8TypAUI9rqojI8wPQrlVvx1UPYA==
X-Google-Smtp-Source: AGHT+IG5niJGd+BSRLD+GT/59wfmkytP2ffo86hUx8JjVzkbnCD8HTSA73eERwn9f4rK7BjTStTxNw==
X-Received: by 2002:a17:906:874d:b0:a46:11a9:430 with SMTP id hj13-20020a170906874d00b00a4611a90430mr2812879ejb.76.1710496086797;
        Fri, 15 Mar 2024 02:48:06 -0700 (PDT)
Message-ID: <88bd8577-42e6-4087-9888-00cd73e7f0bc@suse.com>
Date: Fri, 15 Mar 2024 10:48:05 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 3/3] x86/PVH: Support relocatable dom0 kernels
Content-Language: en-US
To: Jason Andryuk 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu
 , George Dunlap ,
 Julien Grall , Stefano Stabellini ,
 xen-devel@lists.xenproject.org
References: <20240313193021.241764-1-jason.andryuk@amd.com>
 <20240313193021.241764-4-jason.andryuk@amd.com>
 <12fe48a6-6957-49d7-adf5-1a3ac8b1bfaa@suse.com>
 <7506abe0-e3d4-44f7-b54d-592ae2e3fd3e@amd.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <7506abe0-e3d4-44f7-b54d-592ae2e3fd3e@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 14.03.2024 20:19, Jason Andryuk wrote:
> On 2024-03-14 09:31, Jan Beulich wrote:
>> On 13.03.2024 20:30, Jason Andryuk wrote:
>>> --- a/xen/arch/x86/hvm/dom0_build.c
>>> +++ b/xen/arch/x86/hvm/dom0_build.c
>>> @@ -537,6 +537,108 @@ static paddr_t __init find_memory(
>>>       return INVALID_PADDR;
>>>   }
>>>   
>>> +static bool __init check_load_address(
>>> +    const struct domain *d, const struct elf_binary *elf)
>>> +{
>>> +    paddr_t kernel_start = (paddr_t)elf->dest_base & PAGE_MASK;
>>> +    paddr_t kernel_end = PAGE_ALIGN((paddr_t)elf->dest_base + elf->dest_size);
>>
>> Both casts act on a pointer value. Such cannot legitimately be converted
>> to paddr_t; it only so happens that paddr_t is effectively the same as
>> uintptr_t right now. (Same issue again further down.) That said, I notice
>> we have pre-existing examples of this ...
> 
> Yes, I followed existing code.  Do you want dest_base to be switched to 
> a uintptr_t?

I think it was deliberately switched to being a pointer at some point,
maybe even in a security fix.

>>> +/* Check the kernel load address, and adjust if necessary and possible. */
>>> +static bool __init check_and_adjust_load_address(
>>> +    const struct domain *d, struct elf_binary *elf, struct elf_dom_parms *parms)
>>> +{
>>> +    paddr_t reloc_base;
>>> +
>>> +    if ( check_load_address(d, elf) )
>>> +        return true;
>>> +
>>> +    if ( parms->phys_align == UNSET_ADDR )
>>> +    {
>>> +        printk("Address conflict and %pd kernel is not relocatable\n", d);
>>> +        return false;
>>> +    }
>>> +
>>> +    reloc_base = find_kernel_memory(d, elf, parms);
>>> +    if ( reloc_base == 0 )
>>> +    {
>>> +        printk("Failed find a load address for the kernel\n");
>>> +        return false;
>>> +    }
>>> +
>>> +    if ( opt_dom0_verbose )
>>> +        printk("Relocating kernel from [%lx, %lx] -> [%lx, %lx]\n",
>>> +               (paddr_t)elf->dest_base,
>>> +               (paddr_t)elf->dest_base + elf->dest_size,
>>
>> By using %p you clearly can avoid the casts here.
> 
> Ok.
> 
>>> +               reloc_base, reloc_base + elf->dest_size);
>>
>> I'm not convinced %lx is really appropriate for paddr_t.
> 
> PRIpaddr exists.  It's "016lx" for x86.  Using that and %p add lots of 0s:
> (XEN) Relocating kernel from [0000000001000000, 000000000202ffff] -> 
> [0000000002200000, 000000000322ffff]

That's to be accepted, I guess.

Looking at it again, is "Relocating" in the log message perhaps misleading?
We don't relocate it, that's something the kernel itself has to do. We only
put it at other than the default position. Maybe "Moving" instead?

Jan


From xen-devel-bounces@lists.xenproject.org Fri Mar 15 10:05:30 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 10:05:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693726.1082156 (Exim 4.92)
	(envelope-from )
	id 1rl4RF-0007Fm-Pe; Fri, 15 Mar 2024 10:05:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693726.1082156; Fri, 15 Mar 2024 10:05:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl4RF-0007Ff-Mu; Fri, 15 Mar 2024 10:05:21 +0000
Received: by outflank-mailman (input) for mailman id 693726;
 Fri, 15 Mar 2024 10:05:19 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rl4RD-0007FY-Oy
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 10:05:19 +0000
Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com
 [2607:f8b0:4864:20::234])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 85f2a0c9-e2b3-11ee-a1ee-f123f15fe8a2;
 Fri, 15 Mar 2024 11:05:17 +0100 (CET)
Received: by mail-oi1-x234.google.com with SMTP id
 5614622812f47-3c21ecc072cso860453b6e.2
 for ; Fri, 15 Mar 2024 03:05:17 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 85f2a0c9-e2b3-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1710497116; x=1711101916; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Q/3uSXayn9fsf2sZSvts+4sNQNELRmTpXC22EUK66Es=;
        b=IQj6xbeVNq8Wyjis/cN8jNDZYcjigNd/3+Xj3C7BB5C857K0CqLtDbxa2n8l/XrM0R
         mZA00+Jiv9FfxZO4p8bO/X7Rt43cKTbZoiGQxNPn11Lm8TNu+//IE9gEA9llh1QVJMiP
         f+chzrsNfl/DHrw6wGnvdlIm2kxW8FbuUb+I8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710497116; x=1711101916;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=Q/3uSXayn9fsf2sZSvts+4sNQNELRmTpXC22EUK66Es=;
        b=JmNW0oKoCFibWj9N2V7QN6f6TefQsmY3EKuQZsIxZnleuELrifYgy7pvdEV0JaZbky
         X0H3uRbZM1zwlPjRXCW0oSVKQj6nC4+gnrAv5nCjXTwHVwu35/CcoIhPxYXIOcfcUNys
         DnpFZe111WCBF8NwiyIs5Lm6ez43NJgV9iCdO7PEFopknsfOmj/fobmNIEVpPajhpnEp
         nD0nQ7bQkLdfn9alQPmh2RYbDR2sU9aYDV7JDOg3d7obZRFf1qcfx4BUWEQebu4g/A4C
         sXCs/nlkLRWvbmVKAXus958JSFNq/1LFTpZuykeBOHra7FrBfywNA63QLMux76vlEok5
         Sb6Q==
X-Gm-Message-State: AOJu0YwgXMizRvtzoDh9CqJWIe03DSMEup9cPqwZ0vvA43bczMhzq7do
	wVgfCXP5TBOcMeLKnasKaQ9ZombTciw4a/KrQAlBCPT6aPZ14X0p+euvylywMR8XzUa8KT+6jnN
	qYwxNWfvymGdFyLqlovmH6wahCWoPiMWEDOhMhQ==
X-Google-Smtp-Source: AGHT+IHCdpS5avOL8rIDJIa1dcYa/tnydUQmdKQGQHINKQ05DDwFekmNEm7nr9L9+CWl0EpgCPXBqAYbz16You6aiA4=
X-Received: by 2002:a05:6871:7995:b0:21e:698f:5c87 with SMTP id
 pb21-20020a056871799500b0021e698f5c87mr4326791oac.50.1710497116421; Fri, 15
 Mar 2024 03:05:16 -0700 (PDT)
MIME-Version: 1.0
References: <20240314173929.12040-1-julien@xen.org>
In-Reply-To: <20240314173929.12040-1-julien@xen.org>
From: George Dunlap 
Date: Fri, 15 Mar 2024 10:05:05 +0000
Message-ID: 
Subject: Re: [PATCH] SUPPORT.MD: Fix matrix generation after 43c416d0d819 and 77c39a53cf5b
To: Julien Grall 
Cc: xen-devel@lists.xenproject.org, michal.orzel@amd.com, 
	ayan.kumar.halder@amd.com, Julien Grall , 
	Andrew Cooper , Jan Beulich , 
	Stefano Stabellini , Wei Liu 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Mar 14, 2024 at 5:39=E2=80=AFPM Julien Grall  wrote=
:
>
> From: Julien Grall 
>
> The script docs/support-matrix-generate throw the following error on the
> latest staging.

I wonder if it would be worth adding a follow-up patch to run that
script, maybe only when debug=3Dy, so it catches errors in development.

 -George


From xen-devel-bounces@lists.xenproject.org Fri Mar 15 10:36:27 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 10:36:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693740.1082170 (Exim 4.92)
	(envelope-from )
	id 1rl4v1-0003ue-6c; Fri, 15 Mar 2024 10:36:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693740.1082170; Fri, 15 Mar 2024 10:36:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl4v1-0003uX-3e; Fri, 15 Mar 2024 10:36:07 +0000
Received: by outflank-mailman (input) for mailman id 693740;
 Fri, 15 Mar 2024 10:36:05 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rl4uz-0003uR-68
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 10:36:05 +0000
Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com
 [2a00:1450:4864:20::436])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d13a1d64-e2b7-11ee-a1ee-f123f15fe8a2;
 Fri, 15 Mar 2024 11:36:01 +0100 (CET)
Received: by mail-wr1-x436.google.com with SMTP id
 ffacd0b85a97d-33ed4dd8659so171104f8f.0
 for ; Fri, 15 Mar 2024 03:36:01 -0700 (PDT)
Received: from [10.80.67.149] (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 u3-20020a5d6ac3000000b0033dd2c3131fsm2866244wrw.65.2024.03.15.03.36.00
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 15 Mar 2024 03:36:00 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d13a1d64-e2b7-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710498961; x=1711103761; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=OYwZbRVQVgqvge4vMwVH/anqoDrC8O0HimCiICQzuxs=;
        b=Et9PdBf+iuxJXSoM99GO/NzRL1XD6fwVVJrNVmB1a+TEcpykNpqEPiNuJ3XWWEKlpP
         TLFJNOTiRiM+VHnUxu047jqvNrJjI+Ajif10EPQkoB0HVccP/9KyZB0jUICxmhjbGcG4
         17Eaalk8cm+8X2qSxD6XB1xyVy1yJ+dMTmMp8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710498961; x=1711103761;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=OYwZbRVQVgqvge4vMwVH/anqoDrC8O0HimCiICQzuxs=;
        b=hCk0mBwxLX0C5AK9MKKOz6Cr2+wG8lclD/nc8bl+JM2Jy5ArZ2M2uODUD5Su/MudMM
         x8AJY/AD71yNIqUE3cLlTFX3LXV4IT9jEo2vwNBTSfRX73jleKNgPvOimdl8EJBiA3Yb
         bWlZgqvyyH/lLK3JsaWvyBNxfokOQHb59+GmQCCHsgR/gYK5ZYDpCt+U6QcoYyag3NB7
         w1TSdNfKpcQOFMCAYdUOlTAKpNr6tBwEjEEytWIzdjIDUo3UUOfkvhjHTAkhp0kfDQTd
         XaW6dXdpjqSlnp4OSWy3unt/mSLdet4kd+1uORfvAQlI4LC8KxvjPLuvh1Rc83sHUNIH
         p2Gg==
X-Gm-Message-State: AOJu0YwaMCQ17/mvvrL8dWJNdDdzhnL27t8sHLsg/61A+imP9lfeRvqK
	drABAdaYRIN4/mpU05LRBBujbhqvDIVKXM51+oPKPS7NfWP5DmJC/aFiYsZ6Gi0=
X-Google-Smtp-Source: AGHT+IHzHGscQ2WuPjr/YTV/Vxdm/YKuMCKBfcImcMb0UuPxmvLaTfiZMJl8PBXnr/CSBF17sGlmQw==
X-Received: by 2002:adf:a152:0:b0:33e:c234:3f57 with SMTP id r18-20020adfa152000000b0033ec2343f57mr4219055wrr.14.1710498960846;
        Fri, 15 Mar 2024 03:36:00 -0700 (PDT)
Message-ID: <8bffbeea-c1fb-4858-b20c-09ad5d52c71c@citrix.com>
Date: Fri, 15 Mar 2024 10:35:59 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] SUPPORT.MD: Fix matrix generation after 43c416d0d819 and
 77c39a53cf5b
Content-Language: en-GB
To: George Dunlap , Julien Grall 
Cc: xen-devel@lists.xenproject.org, michal.orzel@amd.com,
 ayan.kumar.halder@amd.com, Julien Grall ,
 Jan Beulich , Stefano Stabellini
 , Wei Liu 
References: <20240314173929.12040-1-julien@xen.org>
 
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 15/03/2024 10:05 am, George Dunlap wrote:
> On Thu, Mar 14, 2024 at 5:39 PM Julien Grall  wrote:
>> From: Julien Grall 
>>
>> The script docs/support-matrix-generate throw the following error on the
>> latest staging.
> I wonder if it would be worth adding a follow-up patch to run that
> script, maybe only when debug=y, so it catches errors in development.

I have a second docs thing which needs doing in some copious free
never.  The Sphinx build is getting broken occasionally and I'm the only
one who notices.

I was intending to have a Gitlab run specifically for docs, although the
container for it is going to need to be giant to get all of our ad-hoc
dependencies.

~Andrew


From xen-devel-bounces@lists.xenproject.org Fri Mar 15 10:56:09 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 10:56:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693743.1082180 (Exim 4.92)
	(envelope-from )
	id 1rl5EA-0007Yp-P3; Fri, 15 Mar 2024 10:55:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693743.1082180; Fri, 15 Mar 2024 10:55:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl5EA-0007Yi-MQ; Fri, 15 Mar 2024 10:55:54 +0000
Received: by outflank-mailman (input) for mailman id 693743;
 Fri, 15 Mar 2024 10:55:53 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rl5E9-0007Yc-Ku
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 10:55:53 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 970bf92a-e2ba-11ee-afdd-a90da7624cb6;
 Fri, 15 Mar 2024 11:55:52 +0100 (CET)
Received: from truciolo.bugseng.com (unknown [78.211.227.3])
 by support.bugseng.com (Postfix) with ESMTPSA id CFEA14EE073C;
 Fri, 15 Mar 2024 11:55:49 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 970bf92a-e2ba-11ee-afdd-a90da7624cb6
From: Federico Serafini 
To: xen-devel@lists.xenproject.org
Cc: consulting@bugseng.com,
	Federico Serafini ,
	Simone Ballarin ,
	Doug Goldstein ,
	Stefano Stabellini ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Wei Liu 
Subject: [XEN PATCH v2] automation/eclair: allow parameter name "unused"
Date: Fri, 15 Mar 2024 11:55:41 +0100
Message-Id: 
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Update ECLAIR configuration of MISRA C:2012 Rule 8.3 to deviate
violations involving parameter name "unused" (with an optional
numeric suffix): it makes explicit the intention of not using such
parameter within the function.

Signed-off-by: Federico Serafini 
---
Changes in v2:
- optional numeric suffix.
---
 automation/eclair_analysis/ECLAIR/deviations.ecl | 4 ++++
 docs/misra/deviations.rst                        | 6 ++++++
 2 files changed, 10 insertions(+)

diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
index 53f7623454..de9ba723fb 100644
--- a/automation/eclair_analysis/ECLAIR/deviations.ecl
+++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
@@ -167,6 +167,10 @@ const-qualified."
 -config=MC3R1.R8.3,reports+={deliberate,"any_area(any_loc(file(adopted_decompress_r8_3)))&&any_area(any_loc(file(^xen/include/xen/decompress\\.h$)))"}
 -doc_end
 
+-doc_begin="Parameter name \"unused\" (with an optional numeric suffix) is deliberate and makes explicit the intention of not using such parameter within the function."
+-config=MC3R1.R8.3,reports+={deliberate, "any_area(^.*parameter `unused[0-9]*'.*$)"}
+-doc_end
+
 -doc_begin="The following file is imported from Linux: ignore for now."
 -file_tag+={adopted_time_r8_3,"^xen/arch/x86/time\\.c$"}
 -config=MC3R1.R8.3,reports+={deliberate,"any_area(any_loc(file(adopted_time_r8_3)))&&(any_area(any_loc(file(^xen/include/xen/time\\.h$)))||any_area(any_loc(file(^xen/arch/x86/include/asm/setup\\.h$))))"}
diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
index 41fa5b31b0..eb5ef2bd9d 100644
--- a/docs/misra/deviations.rst
+++ b/docs/misra/deviations.rst
@@ -157,6 +157,12 @@ Deviations related to MISRA C:2012 Rules:
          - xen/common/unxz.c
          - xen/common/unzstd.c
 
+   * - R8.3
+     - Parameter name "unused" (with an optional numeric suffix) is deliberate
+       and makes explicit the intention of not using such parameter within the
+       function.
+     - Tagged as `deliberate` for ECLAIR.
+
    * - R8.4
      - The definitions present in the files 'asm-offsets.c' for any architecture
        are used to generate definitions for asm modules, and are not called by
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Mar 15 10:58:14 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 10:58:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693745.1082190 (Exim 4.92)
	(envelope-from )
	id 1rl5GP-00087R-3l; Fri, 15 Mar 2024 10:58:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693745.1082190; Fri, 15 Mar 2024 10:58:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl5GP-00087K-0z; Fri, 15 Mar 2024 10:58:13 +0000
Received: by outflank-mailman (input) for mailman id 693745;
 Fri, 15 Mar 2024 10:58:11 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1rl5GN-00085d-ER
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 10:58:11 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rl5GM-0008Tg-Lh; Fri, 15 Mar 2024 10:58:10 +0000
Received: from gw1.octic.net ([88.97.20.152] helo=[10.0.1.240])
 by xenbits.xenproject.org with esmtpsa
 (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92)
 (envelope-from )
 id 1rl5GM-0003jY-Cl; Fri, 15 Mar 2024 10:58:10 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=4riWuCVUm7NgESscmGYEJ55dDJYLa2cImkKzyhvYz+M=; b=UeUyWQII61HBU3x/ax+BknYdaU
	XCeX8MlZSjt5SinMc6Qvq22acqch7asgbYVvfXBxbTSXCGAbw8Rva4cgnRZefMYrrGAdKJxBTudmO
	W/6F6IH5U94YeNuJHakJhtWj+CFAxjjtfP+X/Y1bJPMwoM6eH2pvLDBZCIFi5CqlbClI=;
Message-ID: 
Date: Fri, 15 Mar 2024 10:58:08 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] xen/arm: Set correct per-cpu cpu_core_mask
Content-Language: en-GB
To: Henry Wang , xen-devel@lists.xenproject.org,
 george.dunlap@cloud.com
Cc: Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Henry Wang , Juergen Gross 
References: <20240228015822.56108-1-xin.wang2@amd.com>
 <77520838-67cb-4755-8b02-2ec8b90c7bfa@xen.org>
 <16838c64-c633-4125-9388-af02e18a89be@amd.com>
From: Julien Grall 
In-Reply-To: <16838c64-c633-4125-9388-af02e18a89be@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit



On 14/03/2024 14:22, Henry Wang wrote:
> Hi Julien,

Hi,

> 
> On 3/14/2024 9:27 PM, Julien Grall wrote:
>> Hi Henry,
>>
>> On 28/02/2024 01:58, Henry Wang wrote:
>>> diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
>>> index a84e706d77..d9ebd55d4a 100644
>>> --- a/xen/arch/arm/smpboot.c
>>> +++ b/xen/arch/arm/smpboot.c
>>> @@ -66,7 +66,6 @@ static bool cpu_is_dead;
>>>     /* ID of the PCPU we're running on */
>>>   DEFINE_PER_CPU(unsigned int, cpu_id);
>>> -/* XXX these seem awfully x86ish... */
>>
>> :). I guess at the time we didn't realize that MT was supported on 
>> Arm. It is at least part of the spec, but as Michal pointed out it 
>> doesn't look like a lot of processors supports it.
> 
> Yep. Do you think changing the content of this line to something like 
> "Although multithread is part of the Arm spec, there are not many 
> processors support multithread and current Xen on Arm assumes there is 
> no multithread" makes sense to you?
> 
>>>   /* representing HT siblings of each logical CPU */
>>>   DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_sibling_mask);
>>>   /* representing HT and core siblings of each logical CPU */
>>> @@ -89,6 +88,10 @@ static int setup_cpu_sibling_map(int cpu)
>>>       cpumask_set_cpu(cpu, per_cpu(cpu_sibling_mask, cpu));
>>>       cpumask_set_cpu(cpu, per_cpu(cpu_core_mask, cpu));
>>>   +    /* Currently we assume there is no multithread. */
>>
>> I am not very familiar with the scheduling in Xen. Do you know what's 
>> the consequence of not properly supporting MT? One thing I can think 
>> of is security (I know there were plenty of security issues with SMT).
> 
> Unfortunately me neither, so adding George to this thread as I think he 
> can bring us some insights on this topic from the scheduler perspective.

+Juergen as he worked on co-scheduling.

> 
>> Depending on the answer, I would consider to print a warning and maybe 
>> add it in SUPPORT.MD in a separate patch.
> 
> To be honest, as discussed in v1. I think I am quite tempted to add an 
> ASSERT(system_cpuinfo.mpidr.mt == 0) to make sure we catch the 
> multithread support stuff earlier. 

ASSERT(...) is not the right solution. You may have user using a Xen 
shipped by distros where this would be a NOP.

We could try to hide MT completely from the scheduler. If that's too 
difficult, then we could add use warning_add() to throw a warning (see 
how we dealt with opt_hmp_unsafe).

I don't really know what will happen
> if running current Xen on top of a multithread-implemented processor, 
> probably it will be fine, but probably some strange behavior will happen 
> after the boot time which I think will be difficult to debug...

I am not sure what you mean by "strange behavior". AFAIK, you may see 
different performance characteristics and more importantly this is a 
nest for security issue. But I don't expect any difficult to debug.

> 
>> Also, looking at the v1 discussion, it sounds like even 
>> cpu_sibling_mask would not be correct. So I think it would make sense 
>> to move the comment on top of setup_cpu_sibling_map.
> 
> Sounds good. I will move it in v3.
> 
>>> +    cpumask_or(per_cpu(cpu_core_mask, cpu),
>>> +               per_cpu(cpu_core_mask, cpu), &cpu_possible_map);
>>
>> AFIACT, per_cpu(cpu_core_mask, ...) will now be equal to 
>> cpu_possible_map. In that case, wouldn't it be better to simply copy 
>> the cpumask?
> 
> You mean cpumask_copy(per_cpu(cpu_core_mask, cpu), &cpu_possible_map)? 

Yes.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Fri Mar 15 10:59:41 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 10:59:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693747.1082201 (Exim 4.92)
	(envelope-from )
	id 1rl5Ho-0000am-Dt; Fri, 15 Mar 2024 10:59:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693747.1082201; Fri, 15 Mar 2024 10:59:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl5Ho-0000af-AF; Fri, 15 Mar 2024 10:59:40 +0000
Received: by outflank-mailman (input) for mailman id 693747;
 Fri, 15 Mar 2024 10:59:39 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rl5Hn-0000aQ-04
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 10:59:39 +0000
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com
 [2a00:1450:4864:20::62d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1d66fc1c-e2bb-11ee-afdd-a90da7624cb6;
 Fri, 15 Mar 2024 11:59:37 +0100 (CET)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-a468226e135so74733566b.0
 for ; Fri, 15 Mar 2024 03:59:37 -0700 (PDT)
Received: from carlo-ubuntu.mo54.unimo.it (nonato.mo54.unimo.it.
 [155.185.85.8]) by smtp.gmail.com with ESMTPSA id
 en6-20020a17090728c600b00a465a012cf1sm1621493ejc.18.2024.03.15.03.59.35
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 15 Mar 2024 03:59:36 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1d66fc1c-e2bb-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1710500376; x=1711105176; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:from:to:cc:subject:date:message-id:reply-to;
        bh=3rCKwXe47zdPxf3eu90GCtkMGXFP7tCC1kpyZ9XRJHM=;
        b=RLj9VxmDkRbZHKu3sXWrg8SXv4EMPGtTrFzjmA90MRE61bZGRF7rY0UPBaXRpkkzGJ
         oZGAYS/LamYB7uthNjETh6x/lF0Afla+Xsfp5pn1I3e/1pkwDxNq315M6cXna2g6VGVa
         LiU6ymY183zB2/xUfxUBCytmpX7PpuNrT0TnAw9qYwGVgJ3ymRkoT5QWl6zP7B/b/WXI
         pCt7gnur6ZgnMXSnEgSWmq3+YPVtypAzEWOGKu/BS5AxGqb2JeJvlmEeo43Ffmzdyy8C
         jN6XpHFhtsuXIEZEiBRdmdv1CbidnszoXEFrw1qYg4LJ+RinY6gWLOcyOFnJVkcUOjt2
         8AqQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710500376; x=1711105176;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=3rCKwXe47zdPxf3eu90GCtkMGXFP7tCC1kpyZ9XRJHM=;
        b=gnzKiKtV6OSGqEPPgbB/Uy3UM1G2irsmwLldysvgIc7xwSEXj54B2wvpYIOrxaorhW
         Drq6XSXr0WzcFa1K09PYLM358FIQuS4CcKCgPJVIBa57i0NetQTvyqigMKae7Hr3RXL7
         Rd1KurTLJxn75AbOaJvnC7Py++r8BnROYyN6X7t6lBIJo9AOh697PDUWE5wHAXs5y4mL
         eNQxBMF99unHBxoo4e9IX27sMshlXZfhzL2Za1ZBqMwg99gDOzwQLCfwO7Ki9Lg7TNgO
         oeRSkPE4WxBg73ixM2t0YgJsakOveh08jDZ1GWB7z8qvaOQQne9jDJrbuL+3WiQ6MMG0
         glQg==
X-Gm-Message-State: AOJu0YzMQINtMHO9bMnFJm1ythvZjU6VBDLglZzSPyNWPT8u7Dutfs3Y
	eg97355W0dPyYmGAFoE/1IAYdHjhRTHaERoK/sVx1p98xNy5YM0ze8m0XFeqmCupd/BULU3+mHg
	4w3E=
X-Google-Smtp-Source: AGHT+IEeWS16YrFMYdPbrZbKXVbRq2wvHOC5Obn8jrlOL6J0MKm0DIXRyIFrJdaI0X1uF5iO5pd2RQ==
X-Received: by 2002:a17:906:5d7:b0:a45:f6fa:8c20 with SMTP id t23-20020a17090605d700b00a45f6fa8c20mr3186789ejt.14.1710500376488;
        Fri, 15 Mar 2024 03:59:36 -0700 (PDT)
From: Carlo Nonato 
To: xen-devel@lists.xenproject.org
Cc: Carlo Nonato ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini ,
	Wei Liu ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Anthony PERARD ,
	Juergen Gross 
Subject: [PATCH v7 00/14] Arm cache coloring
Date: Fri, 15 Mar 2024 11:58:48 +0100
Message-Id: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Shared caches in multi-core CPU architectures represent a problem for
predictability of memory access latency. This jeopardizes applicability
of many Arm platform in real-time critical and mixed-criticality
scenarios. We introduce support for cache partitioning with page
coloring, a transparent software technique that enables isolation
between domains and Xen, and thus avoids cache interference.

When creating a domain, a simple syntax (e.g. `0-3` or `4-11`) allows
the user to define assignments of cache partitions ids, called colors,
where assigning different colors guarantees no mutual eviction on cache
will ever happen. This instructs the Xen memory allocator to provide
the i-th color assignee only with pages that maps to color i, i.e. that
are indexed in the i-th cache partition.

The proposed implementation supports the dom0less feature.
The proposed implementation doesn't support the static-mem feature.
The solution has been tested in several scenarios, including Xilinx Zynq
MPSoCs.

Carlo Nonato (13):
  xen/common: add cache coloring common code
  xen/arm: add initial support for LLC coloring on arm64
  xen/arm: permit non direct-mapped Dom0 construction
  xen/arm: add Dom0 cache coloring support
  xen: extend domctl interface for cache coloring
  tools: add support for cache coloring configuration
  xen/arm: add support for cache coloring configuration via device-tree
  xen/page_alloc: introduce preserved page flags macro
  xen/page_alloc: introduce page flag to stop buddy merging
  xen: add cache coloring allocator for domains
  xen/arm: use domain memory to allocate p2m page tables
  xen/arm: make consider_modules() available for xen relocation
  xen/arm: add cache coloring support for Xen

Luca Miccio (1):
  xen/arm: add Xen cache colors command line parameter

 SUPPORT.md                              |   7 +
 docs/man/xl.cfg.5.pod.in                |  10 +
 docs/misc/arm/device-tree/booting.txt   |   4 +
 docs/misc/cache-coloring.rst            | 255 +++++++++++++++++
 docs/misc/xen-command-line.pandoc       |  70 +++++
 tools/include/libxl.h                   |   5 +
 tools/include/xenctrl.h                 |   9 +
 tools/libs/ctrl/xc_domain.c             |  35 +++
 tools/libs/light/libxl_create.c         |   9 +
 tools/libs/light/libxl_types.idl        |   1 +
 tools/xl/xl_parse.c                     |  38 ++-
 xen/arch/Kconfig                        |  28 ++
 xen/arch/arm/Kconfig                    |   1 +
 xen/arch/arm/Makefile                   |   1 +
 xen/arch/arm/alternative.c              |  30 +-
 xen/arch/arm/arm32/mmu/mm.c             |  93 +-----
 xen/arch/arm/arm64/mmu/head.S           |  58 +++-
 xen/arch/arm/arm64/mmu/mm.c             |  28 +-
 xen/arch/arm/dom0less-build.c           |  59 ++--
 xen/arch/arm/domain_build.c             | 109 ++++++-
 xen/arch/arm/include/asm/domain_build.h |   1 +
 xen/arch/arm/include/asm/mm.h           |   5 +
 xen/arch/arm/include/asm/mmu/layout.h   |   3 +
 xen/arch/arm/include/asm/processor.h    |  16 ++
 xen/arch/arm/include/asm/setup.h        |   3 +
 xen/arch/arm/llc-coloring.c             | 136 +++++++++
 xen/arch/arm/mmu/p2m.c                  |   4 +-
 xen/arch/arm/mmu/setup.c                | 199 ++++++++++++-
 xen/arch/arm/setup.c                    |  13 +-
 xen/common/Kconfig                      |   3 +
 xen/common/Makefile                     |   1 +
 xen/common/domain.c                     |   3 +
 xen/common/domctl.c                     |   8 +
 xen/common/keyhandler.c                 |   3 +
 xen/common/llc-coloring.c               | 360 ++++++++++++++++++++++++
 xen/common/page_alloc.c                 | 210 +++++++++++++-
 xen/include/public/domctl.h             |   9 +
 xen/include/xen/llc-coloring.h          |  64 +++++
 xen/include/xen/sched.h                 |   5 +
 39 files changed, 1721 insertions(+), 175 deletions(-)
 create mode 100644 docs/misc/cache-coloring.rst
 create mode 100644 xen/arch/arm/llc-coloring.c
 create mode 100644 xen/common/llc-coloring.c
 create mode 100644 xen/include/xen/llc-coloring.h

-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Mar 15 10:59:41 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 10:59:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693748.1082211 (Exim 4.92)
	(envelope-from )
	id 1rl5Hp-0000pM-Ja; Fri, 15 Mar 2024 10:59:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693748.1082211; Fri, 15 Mar 2024 10:59:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl5Hp-0000pF-Gt; Fri, 15 Mar 2024 10:59:41 +0000
Received: by outflank-mailman (input) for mailman id 693748;
 Fri, 15 Mar 2024 10:59:39 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rl5Hn-0000aQ-M1
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 10:59:39 +0000
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com
 [2a00:1450:4864:20::629])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1dd7ebd2-e2bb-11ee-afdd-a90da7624cb6;
 Fri, 15 Mar 2024 11:59:38 +0100 (CET)
Received: by mail-ej1-x629.google.com with SMTP id
 a640c23a62f3a-a468532272eso70034166b.2
 for ; Fri, 15 Mar 2024 03:59:38 -0700 (PDT)
Received: from carlo-ubuntu.mo54.unimo.it (nonato.mo54.unimo.it.
 [155.185.85.8]) by smtp.gmail.com with ESMTPSA id
 en6-20020a17090728c600b00a465a012cf1sm1621493ejc.18.2024.03.15.03.59.36
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 15 Mar 2024 03:59:37 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1dd7ebd2-e2bb-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1710500378; x=1711105178; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=jU4aBycHZ0QecrRZ6TOab+up3UUZUcn3g0RV4PB3Gco=;
        b=gD11aRHFzPjRsM+znDC5T0Rxh4GcfCQZ1W/K2KWKlGEBvSeP+GE5GT3UjZy8NG6agY
         6QMSQ1TcrrMDXVFs3g3nNZ23Cp8fB5n7WoM42g5b/muPmF9g1dl7YhegOCDZfhjcqpIm
         8ULMqcDh8ea/HhmH9oQXm4PMJBuzc1hMxemiKf69baq0iy+jdsVp6a8oS7ulxwwjeXhr
         YSSy7YItqW26zhBdo8rZj368fJY2PF9qRdo9U/ryNJqQDsdf+ECHa9jx+aQiH44SYix3
         JmQGUUcI4YhqDDWmKH+3cBJWjHSZczLyQDX+k0Kh3DQNSR821dWPv8La+Hl/xBdwTCbh
         sJqg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710500378; x=1711105178;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=jU4aBycHZ0QecrRZ6TOab+up3UUZUcn3g0RV4PB3Gco=;
        b=LSOa01bf78MSXhmbOSYJeJhKGDHjT2uUnk5cVelDrM1V4+7Da3eMOSKaX1hswlqR5r
         C0m38ncmQ8ho7oHR2XXf7kjMALE/kIE23D3p7yITLyDvCqdGUGjYwIBC25JbR2oVRmy8
         N0iPk//xeYD9gKNHz7yMOZ44sydkKhVffFtqcCDKbEmf5cTF5yqj4uB5YIJU+l15Zyq4
         t++XCtSO8Ia0zoe+HeF+pRq0Ox9kHeWGkbJDibqgmm5JpTgjGU40/ixSuvqIJmyodZ3X
         pKfcd6e4t20eLW+ivG9myE9ffB4qCcNjS6xdjrSULPbtsGJklB5gNDXa9BE3Q9V1KXqg
         qpZQ==
X-Gm-Message-State: AOJu0YwScwzANNnzox3xiCoxmeZAu96JxRScwahFKIQv3OIHnt3F4Y1w
	UtY7OcnjDtG9/TRl5vOvC0OPZm8xzctz8XQWcqoCDQWPKcZiSb5Dqwi3xoKMIBTqPDnSXehxH5X
	afzw=
X-Google-Smtp-Source: AGHT+IHpf4sk/rSBERwuRtgSuKJ0ojkJIgfaU82jJqHH5eJ7FVjgIBwXfanWGr1184XrtIB/o70CWg==
X-Received: by 2002:a17:906:1c93:b0:a46:22fc:74d3 with SMTP id g19-20020a1709061c9300b00a4622fc74d3mr2928027ejh.72.1710500377641;
        Fri, 15 Mar 2024 03:59:37 -0700 (PDT)
From: Carlo Nonato 
To: xen-devel@lists.xenproject.org
Cc: Carlo Nonato ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini ,
	Wei Liu ,
	Marco Solieri 
Subject: [PATCH v7 01/14] xen/common: add cache coloring common code
Date: Fri, 15 Mar 2024 11:58:49 +0100
Message-Id: <20240315105902.160047-2-carlo.nonato@minervasys.tech>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
References: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Last Level Cache (LLC) coloring allows to partition the cache in smaller
chunks called cache colors. Since not all architectures can actually
implement it, add a HAS_LLC_COLORING Kconfig and put other options under
xen/arch.

LLC colors are a property of the domain, so the domain struct has to be
extended.

Based on original work from: Luca Miccio 

Signed-off-by: Carlo Nonato 
Signed-off-by: Marco Solieri 
---
v7:
- SUPPORT.md changes added to this patch
- extended documentation to better address applicability of cache coloring
- "llc-nr-ways" and "llc-size" params introduced in favor of "llc-way-size"
- moved dump_llc_coloring_info() call in 'm' keyhandler (pagealloc_info())
v6:
- moved almost all code in common
- moved documentation in this patch
- reintroduced range for CONFIG_NR_LLC_COLORS
- reintroduced some stub functions to reduce the number of checks on
  llc_coloring_enabled
- moved domain_llc_coloring_free() in same patch where allocation happens
- turned "d->llc_colors" to pointer-to-const
- llc_coloring_init() now returns void and panics if errors are found
v5:
- used - instead of _ for filenames
- removed domain_create_llc_colored()
- removed stub functions
- coloring domain fields are now #ifdef protected
v4:
- Kconfig options moved to xen/arch
- removed range for CONFIG_NR_LLC_COLORS
- added "llc_coloring_enabled" global to later implement the boot-time
  switch
- added domain_create_llc_colored() to be able to pass colors
- added is_domain_llc_colored() macro
---
 SUPPORT.md                        |   7 ++
 docs/misc/cache-coloring.rst      | 125 ++++++++++++++++++++++++++++++
 docs/misc/xen-command-line.pandoc |  37 +++++++++
 xen/arch/Kconfig                  |  20 +++++
 xen/common/Kconfig                |   3 +
 xen/common/Makefile               |   1 +
 xen/common/keyhandler.c           |   3 +
 xen/common/llc-coloring.c         | 102 ++++++++++++++++++++++++
 xen/common/page_alloc.c           |   3 +
 xen/include/xen/llc-coloring.h    |  36 +++++++++
 xen/include/xen/sched.h           |   5 ++
 11 files changed, 342 insertions(+)
 create mode 100644 docs/misc/cache-coloring.rst
 create mode 100644 xen/common/llc-coloring.c
 create mode 100644 xen/include/xen/llc-coloring.h

diff --git a/SUPPORT.md b/SUPPORT.md
index 510bb02190..456abd42bf 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -364,6 +364,13 @@ by maintaining multiple physical to machine (p2m) memory mappings.
     Status, x86 HVM: Tech Preview
     Status, ARM: Tech Preview
 
+### Cache coloring
+
+Allows to reserve Last Level Cache (LLC) partitions for Dom0, DomUs and Xen
+itself.
+
+    Status, Arm64: Experimental
+
 ## Resource Management
 
 ### CPU Pools
diff --git a/docs/misc/cache-coloring.rst b/docs/misc/cache-coloring.rst
new file mode 100644
index 0000000000..52ce52ffbd
--- /dev/null
+++ b/docs/misc/cache-coloring.rst
@@ -0,0 +1,125 @@
+Xen cache coloring user guide
+=============================
+
+The cache coloring support in Xen allows to reserve Last Level Cache (LLC)
+partitions for Dom0, DomUs and Xen itself. Currently only ARM64 is supported.
+Cache coloring realizes per-set cache partitioning in software and is applicable
+to shared LLCs as implemented in Cortex-A53, Cortex-A72 and similar CPUs.
+
+To compile LLC coloring support set ``CONFIG_LLC_COLORING=y``.
+
+If needed, change the maximum number of colors with
+``CONFIG_NR_LLC_COLORS=``.
+
+Runtime configuration is done via `Command line parameters`_.
+
+Background
+**********
+
+Cache hierarchy of a modern multi-core CPU typically has first levels dedicated
+to each core (hence using multiple cache units), while the last level is shared
+among all of them. Such configuration implies that memory operations on one
+core (e.g. running a DomU) are able to generate interference on another core
+(e.g. hosting another DomU). Cache coloring realizes per-set cache-partitioning
+in software and mitigates this, guaranteeing higher and more predictable
+performances for memory accesses.
+Software-based cache coloring is particularly useful in those situations where
+no hardware mechanisms (e.g., DSU-based way partitioning) are available to
+partition caches. This is the case for e.g., Cortex-A53, A57 and A72 CPUs that
+feature a L2 LLC cache shared among all cores.
+
+The key concept underlying cache coloring is a fragmentation of the memory
+space into a set of sub-spaces called colors that are mapped to disjoint cache
+partitions. Technically, the whole memory space is first divided into a number
+of subsequent regions. Then each region is in turn divided into a number of
+subsequent sub-colors. The generic i-th color is then obtained by all the
+i-th sub-colors in each region.
+
+::
+
+                            Region j            Region j+1
+                .....................   ............
+                .                     . .
+                .                       .
+            _ _ _______________ _ _____________________ _ _
+                |     |     |     |     |     |     |
+                | c_0 | c_1 |     | c_n | c_0 | c_1 |
+           _ _ _|_____|_____|_ _ _|_____|_____|_____|_ _ _
+                    :                       :
+                    :                       :...         ... .
+                    :                            color 0
+                    :...........................         ... .
+                                                :
+          . . ..................................:
+
+How colors are actually defined depends on the function that maps memory to
+cache lines. In case of physically-indexed, physically-tagged caches with linear
+mapping, the set index is found by extracting some contiguous bits from the
+physical address. This allows colors to be defined as shown in figure: they
+appear in memory as subsequent blocks of equal size and repeats themselves after
+``n`` different colors, where ``n`` is the total number of colors.
+
+If some kind of bit shuffling appears in the mapping function, then colors
+assume a different layout in memory. Those kind of caches aren't supported by
+the current implementation.
+
+**Note**: Finding the exact cache mapping function can be a really difficult
+task since it's not always documented in the CPU manual. As said Cortex-A53, A57
+and A72 are known to work with the current implementation.
+
+How to compute the number of colors
+###################################
+
+Given the linear mapping from physical memory to cache lines for granted, the
+number of available colors for a specific platform is computed using three
+parameters:
+
+- the size of the LLC.
+- the number of the LLC ways.
+- the page size used by Xen.
+
+The first two parameters can be found in the processor manual, while the third
+one is the minimum mapping granularity. Dividing the cache size by the number of
+its ways we obtain the size of a way. Dividing this number by the page size,
+the number of total cache colors is found. So for example an Arm Cortex-A53
+with a 16-ways associative 1 MiB LLC can isolate up to 16 colors when pages are
+4 KiB in size.
+
+LLC size and number of ways are probed automatically by default so there's
+should be no need to compute the number of colors by yourself.
+
+Effective colors assignment
+###########################
+
+When assigning colors:
+
+1. If one wants to avoid cache interference between two domains, different
+   colors needs to be used for their memory.
+
+2. To improve spatial locality, color assignment should privilege continuity in
+   the partitioning. E.g., assigning colors (0,1) to domain I and (2,3) to
+   domain J is better than assigning colors (0,2) to I and (1,3) to J.
+
+Command line parameters
+***********************
+
+Specific documentation is available at `docs/misc/xen-command-line.pandoc`.
+
++----------------------+-------------------------------+
+| **Parameter**        | **Description**               |
++----------------------+-------------------------------+
+| ``llc-coloring``     | enable coloring at runtime    |
++----------------------+-------------------------------+
+| ``llc-size``         | set the LLC size              |
++----------------------+-------------------------------+
+| ``llc-nr-ways``      | set the LLC number of ways    |
++----------------------+-------------------------------+
+
+Auto-probing of LLC specs
+#########################
+
+LLC size and number of ways are probed automatically by default.
+
+LLC specs can be manually set via the above command line parameters. This
+bypasses any auto-probing and it's used to overcome failing situations or for
+debugging/testing purposes.
diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
index 54edbc0fbc..2936abea2c 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -1706,6 +1706,43 @@ This option is intended for debugging purposes only.  Enable MSR_DEBUGCTL.LBR
 in hypervisor context to be able to dump the Last Interrupt/Exception To/From
 record with other registers.
 
+### llc-coloring
+> `= `
+
+> Default: `false`
+
+Flag to enable or disable LLC coloring support at runtime. This option is
+available only when `CONFIG_LLC_COLORING` is enabled. See the general
+cache coloring documentation for more info.
+
+### llc-nr-ways
+> `= `
+
+> Default: `Obtained from hardware`
+
+Specify the number of ways of the Last Level Cache. This option is available
+only when `CONFIG_LLC_COLORING` is enabled. LLC size and number of ways are used
+to find the number of supported cache colors. By default the value is
+automatically computed by probing the hardware, but in case of specific needs,
+it can be manually set. Those include failing probing and debugging/testing
+purposes so that it's possibile to emulate platforms with different number of
+supported colors. If set, also "llc-size" must be set, otherwise the default
+will be used.
+
+### llc-size
+> `= `
+
+> Default: `Obtained from hardware`
+
+Specify the size of the Last Level Cache. This option is available only when
+`CONFIG_LLC_COLORING` is enabled. LLC size and number of ways are used to find
+the number of supported cache colors. By default the value is automatically
+computed by probing the hardware, but in case of specific needs, it can be
+manually set. Those include failing probing and debugging/testing purposes so
+that it's possibile to emulate platforms with different number of supported
+colors. If set, also "llc-nr-ways" must be set, otherwise the default will be
+used.
+
 ### lock-depth-size
 > `= `
 
diff --git a/xen/arch/Kconfig b/xen/arch/Kconfig
index 67ba38f32f..a65c38e53e 100644
--- a/xen/arch/Kconfig
+++ b/xen/arch/Kconfig
@@ -31,3 +31,23 @@ config NR_NUMA_NODES
 	  associated with multiple-nodes management. It is the upper bound of
 	  the number of NUMA nodes that the scheduler, memory allocation and
 	  other NUMA-aware components can handle.
+
+config LLC_COLORING
+	bool "Last Level Cache (LLC) coloring" if EXPERT
+	depends on HAS_LLC_COLORING
+	depends on !NUMA
+
+config NR_LLC_COLORS
+	int "Maximum number of LLC colors"
+	range 2 1024
+	default 128
+	depends on LLC_COLORING
+	help
+	  Controls the build-time size of various arrays associated with LLC
+	  coloring. Refer to cache coloring documentation for how to compute the
+	  number of colors supported by the platform. This is only an upper
+	  bound. The runtime value is autocomputed or manually set via cmdline.
+	  The default value corresponds to an 8 MiB 16-ways LLC, which should be
+	  more than what's needed in the general case. Use only power of 2 values.
+	  1024 is the number of colors that fit in a 4 KiB page when integers are 4
+	  bytes long.
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index a5c3d5a6bf..1e467178bd 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -71,6 +71,9 @@ config HAS_IOPORTS
 config HAS_KEXEC
 	bool
 
+config HAS_LLC_COLORING
+	bool
+
 config HAS_PMAP
 	bool
 
diff --git a/xen/common/Makefile b/xen/common/Makefile
index e5eee19a85..3054254a7d 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -23,6 +23,7 @@ obj-y += keyhandler.o
 obj-$(CONFIG_KEXEC) += kexec.o
 obj-$(CONFIG_KEXEC) += kimage.o
 obj-$(CONFIG_LIVEPATCH) += livepatch.o livepatch_elf.o
+obj-$(CONFIG_LLC_COLORING) += llc-coloring.o
 obj-$(CONFIG_MEM_ACCESS) += mem_access.o
 obj-y += memory.o
 obj-y += multicall.o
diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
index 127ca50696..778f93e063 100644
--- a/xen/common/keyhandler.c
+++ b/xen/common/keyhandler.c
@@ -5,6 +5,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -303,6 +304,8 @@ static void cf_check dump_domains(unsigned char key)
 
         arch_dump_domain_info(d);
 
+        domain_dump_llc_colors(d);
+
         rangeset_domain_printk(d);
 
         dump_pageframe_info(d);
diff --git a/xen/common/llc-coloring.c b/xen/common/llc-coloring.c
new file mode 100644
index 0000000000..db96a83ddd
--- /dev/null
+++ b/xen/common/llc-coloring.c
@@ -0,0 +1,102 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Last Level Cache (LLC) coloring common code
+ *
+ * Copyright (C) 2022 Xilinx Inc.
+ */
+#include 
+#include 
+#include 
+
+static bool __ro_after_init llc_coloring_enabled;
+boolean_param("llc-coloring", llc_coloring_enabled);
+
+static unsigned int __initdata llc_size;
+size_param("llc-size", llc_size);
+static unsigned int __initdata llc_nr_ways;
+integer_param("llc-nr-ways", llc_nr_ways);
+/* Number of colors available in the LLC */
+static unsigned int __ro_after_init max_nr_colors;
+
+static void print_colors(const unsigned int *colors, unsigned int num_colors)
+{
+    unsigned int i;
+
+    printk("{ ");
+    for ( i = 0; i < num_colors; i++ )
+    {
+        unsigned int start = colors[i], end = start;
+
+        printk("%u", start);
+
+        for ( ; i < num_colors - 1 && end + 1 == colors[i + 1]; i++, end++ )
+            ;
+
+        if ( start != end )
+            printk("-%u", end);
+
+        if ( i < num_colors - 1 )
+            printk(", ");
+    }
+    printk(" }\n");
+}
+
+void __init llc_coloring_init(void)
+{
+    unsigned int way_size;
+
+    if ( !llc_coloring_enabled )
+        return;
+
+    if ( llc_size && llc_nr_ways )
+        way_size = llc_size / llc_nr_ways;
+    else
+    {
+        way_size = get_llc_way_size();
+        if ( !way_size )
+            panic("LLC probing failed and 'llc-size' or 'llc-nr-ways' missing\n");
+    }
+
+    /*
+     * The maximum number of colors must be a power of 2 in order to correctly
+     * map them to bits of an address.
+     */
+    max_nr_colors = way_size >> PAGE_SHIFT;
+
+    if ( max_nr_colors & (max_nr_colors - 1) )
+        panic("Number of LLC colors (%u) isn't a power of 2\n", max_nr_colors);
+
+    if ( max_nr_colors < 2 || max_nr_colors > CONFIG_NR_LLC_COLORS )
+        panic("Number of LLC colors (%u) not in range [2, %u]\n",
+              max_nr_colors, CONFIG_NR_LLC_COLORS);
+
+    arch_llc_coloring_init();
+}
+
+void cf_check dump_llc_coloring_info(void)
+{
+    if ( !llc_coloring_enabled )
+        return;
+
+    printk("LLC coloring info:\n");
+    printk("    Number of LLC colors supported: %u\n", max_nr_colors);
+}
+
+void cf_check domain_dump_llc_colors(const struct domain *d)
+{
+    if ( !llc_coloring_enabled )
+        return;
+
+    printk("%u LLC colors: ", d->num_llc_colors);
+    print_colors(d->llc_colors, d->num_llc_colors);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 2ec17df9b4..c38edb9a58 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -126,6 +126,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -2623,6 +2624,8 @@ static void cf_check pagealloc_info(unsigned char key)
     }
 
     printk("    Dom heap: %lukB free\n", total << (PAGE_SHIFT-10));
+
+    dump_llc_coloring_info();
 }
 
 static __init int cf_check pagealloc_keyhandler_init(void)
diff --git a/xen/include/xen/llc-coloring.h b/xen/include/xen/llc-coloring.h
new file mode 100644
index 0000000000..c60c8050c5
--- /dev/null
+++ b/xen/include/xen/llc-coloring.h
@@ -0,0 +1,36 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Last Level Cache (LLC) coloring common header
+ *
+ * Copyright (C) 2022 Xilinx Inc.
+ */
+#ifndef __COLORING_H__
+#define __COLORING_H__
+
+#include 
+#include 
+
+#ifdef CONFIG_LLC_COLORING
+void llc_coloring_init(void);
+void dump_llc_coloring_info(void);
+void domain_dump_llc_colors(const struct domain *d);
+#else
+static inline void llc_coloring_init(void) {}
+static inline void dump_llc_coloring_info(void) {}
+static inline void domain_dump_llc_colors(const struct domain *d) {}
+#endif
+
+unsigned int get_llc_way_size(void);
+void arch_llc_coloring_init(void);
+
+#endif /* __COLORING_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 37f5922f32..96cc934fc3 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -627,6 +627,11 @@ struct domain
 
     /* Holding CDF_* constant. Internal flags for domain creation. */
     unsigned int cdf;
+
+#ifdef CONFIG_LLC_COLORING
+    unsigned int num_llc_colors;
+    const unsigned int *llc_colors;
+#endif
 };
 
 static inline struct page_list_head *page_to_list(
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Mar 15 10:59:43 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 10:59:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693749.1082221 (Exim 4.92)
	(envelope-from )
	id 1rl5Hq-000151-UX; Fri, 15 Mar 2024 10:59:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693749.1082221; Fri, 15 Mar 2024 10:59:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl5Hq-00014s-RX; Fri, 15 Mar 2024 10:59:42 +0000
Received: by outflank-mailman (input) for mailman id 693749;
 Fri, 15 Mar 2024 10:59:40 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rl5Ho-0000aQ-MK
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 10:59:40 +0000
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com
 [2a00:1450:4864:20::62b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1ea15f2e-e2bb-11ee-afdd-a90da7624cb6;
 Fri, 15 Mar 2024 11:59:39 +0100 (CET)
Received: by mail-ej1-x62b.google.com with SMTP id
 a640c23a62f3a-a44665605f3so208450866b.2
 for ; Fri, 15 Mar 2024 03:59:39 -0700 (PDT)
Received: from carlo-ubuntu.mo54.unimo.it (nonato.mo54.unimo.it.
 [155.185.85.8]) by smtp.gmail.com with ESMTPSA id
 en6-20020a17090728c600b00a465a012cf1sm1621493ejc.18.2024.03.15.03.59.37
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 15 Mar 2024 03:59:38 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1ea15f2e-e2bb-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1710500378; x=1711105178; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=x7qgLspBNpxBucIcCqnnYGElw1yQeDssnQnTybbfdgM=;
        b=n/N0OpmmGWYcWTTGlmIRya2J/ahuYyh8HR4n51Q1P0Qz+5+q8RKZuZWSkYhAD1dG3x
         JbEST+310zrvbVfa8dY3cLhIk+h/tV1pe/jsDYZWxKOSR/FAl2KmNCUaedLkcnjDcJ0E
         oztL9kJCXIvO6KzY8HOkknx9EZu6AYU1sG0nUJFVnzBPRZQu2aWy60LA9IlT7y3T+Ej6
         iqQNJkbjpoN7//aC2lWlfZ1I9030EK52+qjxnZgUaEuaZ5vKvEGb0NSkYCEE4kETAQ/z
         VLgZLRT+Vzsy3ZTAT2xAItEIntI5i4wcROlk6y1t5NZCwW6zbifLfuE/rbiEOCoMHFy9
         lNEA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710500378; x=1711105178;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=x7qgLspBNpxBucIcCqnnYGElw1yQeDssnQnTybbfdgM=;
        b=a3A3sAhnejEfeg3B4FoEG4vm/k7SJFLI1VVJ2T+n7xX51ZqN4STjwDvmn/RUpUmAB2
         9zmWeKl2s4t2b9SslQ/uwDVX+MVCckH+cF004k05jNc5o84ce+rOA0lD6z8pFJCl8Ju6
         l2ea6davXjfSoOanByE4z8FoKy1KbVMjgGJ2hzpL9onoTlDhjAwF6crli2we6xFj9nty
         wyP9S6kAyMC2hHx2ZesRkVc7OPM040eotMkaiZCg1VtavJFSz7ZvjhPr4uvIBCi/u+qA
         4o81iZpsB0htuRk+VVJrzPHgOg/J5emIBf0THB1iYqsxrPVn32CQeYoEnegkPilgtEoa
         e2GA==
X-Gm-Message-State: AOJu0YygWMV/G1rAKVeEoMDVIpmEXoq/XGlnpGIP/5m9luvhqJlRijWl
	wOzyWta0d0G/PkkrxEpQJSjMTm7F4xOyD4p57KumtTcMpe3gLDZsRabqF5l4XQSXSUjT9aTt9Kr
	DCM0=
X-Google-Smtp-Source: AGHT+IGx2+970rAP4gkHNMJwtJTjBvh81JAADd4udQI1aCReWCaMxMdvAxC3x2LRrXqZsfP9RkGCmA==
X-Received: by 2002:a17:906:aad1:b0:a46:966b:ebfe with SMTP id kt17-20020a170906aad100b00a46966bebfemr326115ejb.46.1710500378562;
        Fri, 15 Mar 2024 03:59:38 -0700 (PDT)
From: Carlo Nonato 
To: xen-devel@lists.xenproject.org
Cc: Carlo Nonato ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini ,
	Wei Liu ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Marco Solieri 
Subject: [PATCH v7 02/14] xen/arm: add initial support for LLC coloring on arm64
Date: Fri, 15 Mar 2024 11:58:50 +0100
Message-Id: <20240315105902.160047-3-carlo.nonato@minervasys.tech>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
References: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

LLC coloring needs to know the last level cache layout in order to make the
best use of it. This can be probed by inspecting the CLIDR_EL1 register,
so the Last Level is defined as the last level visible by this register.
Note that this excludes system caches in some platforms.

Static memory allocation and cache coloring are incompatible because static
memory can't be guaranteed to use only colors assigned to the domain.
Panic during DomUs creation when both are enabled.

Based on original work from: Luca Miccio 

Signed-off-by: Carlo Nonato 
Signed-off-by: Marco Solieri 
---
v7:
- only minor changes
v6:
- get_llc_way_size() now checks for at least separate I/D caches
v5:
- used - instead of _ for filenames
- moved static-mem check in this patch
- moved dom0 colors parsing in next patch
- moved color allocation and configuration in next patch
- moved check_colors() in next patch
- colors are now printed in short form
v4:
- added "llc-coloring" cmdline option for the boot-time switch
- dom0 colors are now checked during domain init as for any other domain
- fixed processor.h masks bit width
- check for overflow in parse_color_config()
- check_colors() now checks also that colors are sorted and unique
---
 docs/misc/cache-coloring.rst         | 14 ++++++
 xen/arch/arm/Kconfig                 |  1 +
 xen/arch/arm/Makefile                |  1 +
 xen/arch/arm/dom0less-build.c        |  6 +++
 xen/arch/arm/include/asm/processor.h | 16 ++++++
 xen/arch/arm/llc-coloring.c          | 75 ++++++++++++++++++++++++++++
 xen/arch/arm/setup.c                 |  3 ++
 xen/common/llc-coloring.c            |  2 +-
 xen/include/xen/llc-coloring.h       |  4 ++
 9 files changed, 121 insertions(+), 1 deletion(-)
 create mode 100644 xen/arch/arm/llc-coloring.c

diff --git a/docs/misc/cache-coloring.rst b/docs/misc/cache-coloring.rst
index 52ce52ffbd..871e7a3ddb 100644
--- a/docs/misc/cache-coloring.rst
+++ b/docs/misc/cache-coloring.rst
@@ -120,6 +120,20 @@ Auto-probing of LLC specs
 
 LLC size and number of ways are probed automatically by default.
 
+In the Arm implementation, this is done by inspecting the CLIDR_EL1 register.
+This means that other system caches that aren't visible there are ignored.
+
 LLC specs can be manually set via the above command line parameters. This
 bypasses any auto-probing and it's used to overcome failing situations or for
 debugging/testing purposes.
+
+Known issues and limitations
+****************************
+
+"xen,static-mem" isn't supported when coloring is enabled
+#########################################################
+
+In the domain configuration, "xen,static-mem" allows memory to be statically
+allocated to the domain. This isn't possible when LLC coloring is enabled,
+because that memory can't be guaranteed to use only colors assigned to the
+domain.
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 40f834bb71..fa96d8247e 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -8,6 +8,7 @@ config ARM_64
 	depends on !ARM_32
 	select 64BIT
 	select HAS_FAST_MULTIPLY
+	select HAS_LLC_COLORING
 
 config ARM
 	def_bool y
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 7b1350e2ef..18ae566521 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -37,6 +37,7 @@ obj-$(CONFIG_IOREQ_SERVER) += ioreq.o
 obj-y += irq.o
 obj-y += kernel.init.o
 obj-$(CONFIG_LIVEPATCH) += livepatch.o
+obj-$(CONFIG_LLC_COLORING) += llc-coloring.o
 obj-y += mem_access.o
 obj-y += mm.o
 obj-y += monitor.o
diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
index fb63ec6fd1..1142f7f74a 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch/arm/dom0less-build.c
@@ -5,6 +5,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -879,7 +880,12 @@ void __init create_domUs(void)
             panic("No more domain IDs available\n");
 
         if ( dt_find_property(node, "xen,static-mem", NULL) )
+        {
+            if ( llc_coloring_enabled )
+                panic("LLC coloring and static memory are incompatible\n");
+
             flags |= CDF_staticmem;
+        }
 
         if ( dt_property_read_bool(node, "direct-map") )
         {
diff --git a/xen/arch/arm/include/asm/processor.h b/xen/arch/arm/include/asm/processor.h
index 8e02410465..ef33ea198c 100644
--- a/xen/arch/arm/include/asm/processor.h
+++ b/xen/arch/arm/include/asm/processor.h
@@ -18,6 +18,22 @@
 #define CTR_IDC_SHIFT       28
 #define CTR_DIC_SHIFT       29
 
+/* CCSIDR Current Cache Size ID Register */
+#define CCSIDR_LINESIZE_MASK            _AC(0x7, UL)
+#define CCSIDR_NUMSETS_SHIFT            13
+#define CCSIDR_NUMSETS_MASK             _AC(0x3fff, UL)
+#define CCSIDR_NUMSETS_SHIFT_FEAT_CCIDX 32
+#define CCSIDR_NUMSETS_MASK_FEAT_CCIDX  _AC(0xffffff, UL)
+
+/* CSSELR Cache Size Selection Register */
+#define CSSELR_LEVEL_MASK  _AC(0x7, UL)
+#define CSSELR_LEVEL_SHIFT 1
+
+/* CLIDR Cache Level ID Register */
+#define CLIDR_CTYPEn_SHIFT(n) (3 * ((n) - 1))
+#define CLIDR_CTYPEn_MASK     _AC(0x7, UL)
+#define CLIDR_CTYPEn_LEVELS   7
+
 #define ICACHE_POLICY_VPIPT  0
 #define ICACHE_POLICY_AIVIVT 1
 #define ICACHE_POLICY_VIPT   2
diff --git a/xen/arch/arm/llc-coloring.c b/xen/arch/arm/llc-coloring.c
new file mode 100644
index 0000000000..b83540ff41
--- /dev/null
+++ b/xen/arch/arm/llc-coloring.c
@@ -0,0 +1,75 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Last Level Cache (LLC) coloring support for ARM
+ *
+ * Copyright (C) 2022 Xilinx Inc.
+ */
+#include 
+#include 
+
+#include 
+#include 
+
+/* Return the LLC way size by probing the hardware */
+unsigned int __init get_llc_way_size(void)
+{
+    register_t ccsidr_el1;
+    register_t clidr_el1 = READ_SYSREG(CLIDR_EL1);
+    register_t csselr_el1 = READ_SYSREG(CSSELR_EL1);
+    register_t id_aa64mmfr2_el1 = READ_SYSREG(ID_AA64MMFR2_EL1);
+    uint32_t ccsidr_numsets_shift = CCSIDR_NUMSETS_SHIFT;
+    uint32_t ccsidr_numsets_mask = CCSIDR_NUMSETS_MASK;
+    unsigned int n, line_size, num_sets;
+
+    for ( n = CLIDR_CTYPEn_LEVELS; n != 0; n-- )
+    {
+        uint8_t ctype_n = (clidr_el1 >> CLIDR_CTYPEn_SHIFT(n)) &
+                          CLIDR_CTYPEn_MASK;
+
+        /* Unified cache (see Arm ARM DDI 0487J.a D19.2.27) */
+        if ( ctype_n == 0b100 )
+            break;
+    }
+
+    if ( n == 0 )
+        return 0;
+
+    WRITE_SYSREG((n - 1) << CSSELR_LEVEL_SHIFT, CSSELR_EL1);
+    isb();
+
+    ccsidr_el1 = READ_SYSREG(CCSIDR_EL1);
+
+    /* Arm ARM: (Log2(Number of bytes in cache line)) - 4 */
+    line_size = 1U << ((ccsidr_el1 & CCSIDR_LINESIZE_MASK) + 4);
+
+    /* If FEAT_CCIDX is enabled, CCSIDR_EL1 has a different bit layout */
+    if ( (id_aa64mmfr2_el1 >> ID_AA64MMFR2_CCIDX_SHIFT) & 0x7 )
+    {
+        ccsidr_numsets_shift = CCSIDR_NUMSETS_SHIFT_FEAT_CCIDX;
+        ccsidr_numsets_mask = CCSIDR_NUMSETS_MASK_FEAT_CCIDX;
+    }
+
+    /* Arm ARM: (Number of sets in cache) - 1 */
+    num_sets = ((ccsidr_el1 >> ccsidr_numsets_shift) & ccsidr_numsets_mask) + 1;
+
+    printk(XENLOG_INFO "LLC found: L%u (line size: %u bytes, sets num: %u)\n",
+           n, line_size, num_sets);
+
+    /* Restore value in CSSELR_EL1 */
+    WRITE_SYSREG(csselr_el1, CSSELR_EL1);
+    isb();
+
+    return line_size * num_sets;
+}
+
+void __init arch_llc_coloring_init(void) {}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 424744ad5e..c72c90302e 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -746,6 +747,8 @@ void asmlinkage __init start_xen(unsigned long boot_phys_offset,
     printk("Command line: %s\n", cmdline);
     cmdline_parse(cmdline);
 
+    llc_coloring_init();
+
     setup_mm();
 
     vm_init();
diff --git a/xen/common/llc-coloring.c b/xen/common/llc-coloring.c
index db96a83ddd..51eae90ad5 100644
--- a/xen/common/llc-coloring.c
+++ b/xen/common/llc-coloring.c
@@ -8,7 +8,7 @@
 #include 
 #include 
 
-static bool __ro_after_init llc_coloring_enabled;
+bool __ro_after_init llc_coloring_enabled;
 boolean_param("llc-coloring", llc_coloring_enabled);
 
 static unsigned int __initdata llc_size;
diff --git a/xen/include/xen/llc-coloring.h b/xen/include/xen/llc-coloring.h
index c60c8050c5..67b27c995b 100644
--- a/xen/include/xen/llc-coloring.h
+++ b/xen/include/xen/llc-coloring.h
@@ -11,10 +11,14 @@
 #include 
 
 #ifdef CONFIG_LLC_COLORING
+extern bool llc_coloring_enabled;
+
 void llc_coloring_init(void);
 void dump_llc_coloring_info(void);
 void domain_dump_llc_colors(const struct domain *d);
 #else
+#define llc_coloring_enabled false
+
 static inline void llc_coloring_init(void) {}
 static inline void dump_llc_coloring_info(void) {}
 static inline void domain_dump_llc_colors(const struct domain *d) {}
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Mar 15 10:59:43 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 10:59:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693750.1082225 (Exim 4.92)
	(envelope-from )
	id 1rl5Hr-00017o-6S; Fri, 15 Mar 2024 10:59:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693750.1082225; Fri, 15 Mar 2024 10:59:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl5Hr-000172-2O; Fri, 15 Mar 2024 10:59:43 +0000
Received: by outflank-mailman (input) for mailman id 693750;
 Fri, 15 Mar 2024 10:59:42 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rl5Hq-0000xG-AC
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 10:59:42 +0000
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com
 [2a00:1450:4864:20::635])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1ef74117-e2bb-11ee-a1ee-f123f15fe8a2;
 Fri, 15 Mar 2024 11:59:40 +0100 (CET)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-a44ad785a44so222892866b.3
 for ; Fri, 15 Mar 2024 03:59:40 -0700 (PDT)
Received: from carlo-ubuntu.mo54.unimo.it (nonato.mo54.unimo.it.
 [155.185.85.8]) by smtp.gmail.com with ESMTPSA id
 en6-20020a17090728c600b00a465a012cf1sm1621493ejc.18.2024.03.15.03.59.38
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 15 Mar 2024 03:59:39 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1ef74117-e2bb-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1710500379; x=1711105179; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=OWLty+UmaFeSrZ8CDxzo05Ip09kKWG0NEp9+DODidks=;
        b=ldiOgj3xJn5axnXkIuNYwNxKrbZ+bFUu9GJBfYeMdTiJhLD9gtg0MTOhMJm78J50g4
         itTUfh3ZyzG0GEn3xH6Fg3rTmNDbGtLZkdttBvSlKbwEH/4PbQO6+EkgSp3tve2eqOLo
         SYpv1uCT55kSzwRGisaP3Ph4s8kbcsFmhUQrZKgk6gsuRIUa0CD8hxtqZrcHu70dJQ9H
         yIW3Tn0CRzhAZp3yaytDfCMEuHeMAIPJojxWKZni76W4ALhls/V8h8FkLXRwNlcO908K
         TN1BfpBNudXQRvTselnAzRQkpvV5Wk/M+UpWBmTROjemLbUVreOkqb0KhLBcxl4etYGj
         gIQA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710500379; x=1711105179;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=OWLty+UmaFeSrZ8CDxzo05Ip09kKWG0NEp9+DODidks=;
        b=S7A3t576kxJariIu06ce6unjzqHEGcilH8znFQwT+jifklbQlkYWgzq7izX8PM09O1
         mXU8L2HT/mqGAslPPPmR5VB6vR4N6p4QbMkgK07/lsfvexcqXBbm+TDDZHHzQehCawtY
         JLSwxtE0J4mwb9d4TF6k9avrbSqMFlNWxHfxQVrlps4p8Hmt+UajVG0c4AVeJ1YCBbZA
         PJo7rS53b5r6pTPXaCKQahrS+krLfyDbikl0nUUj4pinID1P9T4mFKWziR+7Jqy5fMZh
         NSYZboq0F13k4f3mbOT0cr6u+/SAdIycBBLg0tjK0N8SLoQnlMvsISlvTF/rJAk1fFT+
         f/hg==
X-Gm-Message-State: AOJu0YzEzH0uklMwB+F343MCHMxGzw1jj+zoVwQt16Kh5AjmceIfJIQC
	PW3BtGoDI9h9/Sw3NsAHwc1I4Jn8jM3PerNanOOZSl3xClzR/Xw+drPDdcw/kOiTrK3DZo+Y1Nq
	2q6Y=
X-Google-Smtp-Source: AGHT+IGyDlyKdPdWuWCjfVqFNKccm5QWYNVLFSk/SQKMB8nHSuqPqqc0RsTIGPi//EncToi9WPg4iw==
X-Received: by 2002:a17:906:80da:b0:a46:8c40:dabf with SMTP id a26-20020a17090680da00b00a468c40dabfmr666865ejx.31.1710500379690;
        Fri, 15 Mar 2024 03:59:39 -0700 (PDT)
From: Carlo Nonato 
To: xen-devel@lists.xenproject.org
Cc: Carlo Nonato ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk 
Subject: [PATCH v7 03/14] xen/arm: permit non direct-mapped Dom0 construction
Date: Fri, 15 Mar 2024 11:58:51 +0100
Message-Id: <20240315105902.160047-4-carlo.nonato@minervasys.tech>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
References: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Cache coloring requires Dom0 not to be direct-mapped because of its non
contiguous mapping nature, so allocate_memory() is needed in this case.
8d2c3ab18cc1 ("arm/dom0less: put dom0less feature code in a separate module")
moved allocate_memory() in dom0less_build.c. In order to use it
in Dom0 construction bring it back to domain_build.c and declare it in
domain_build.h.

Take the opportunity to adapt the implementation of allocate_memory() so
that it uses the host layout when called on the hwdom, via
find_unallocated_memory().

Signed-off-by: Carlo Nonato 
---
v7:
- allocate_memory() now uses the host layout when called on the hwdom
v6:
- new patch
---
 xen/arch/arm/dom0less-build.c           | 43 -----------
 xen/arch/arm/domain_build.c             | 99 ++++++++++++++++++++++++-
 xen/arch/arm/include/asm/domain_build.h |  1 +
 3 files changed, 96 insertions(+), 47 deletions(-)

diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
index 1142f7f74a..992080e61a 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch/arm/dom0less-build.c
@@ -49,49 +49,6 @@ bool __init is_dom0less_mode(void)
     return ( !dom0found && domUfound );
 }
 
-static void __init allocate_memory(struct domain *d, struct kernel_info *kinfo)
-{
-    unsigned int i;
-    paddr_t bank_size;
-
-    printk(XENLOG_INFO "Allocating mappings totalling %ldMB for %pd:\n",
-           /* Don't want format this as PRIpaddr (16 digit hex) */
-           (unsigned long)(kinfo->unassigned_mem >> 20), d);
-
-    kinfo->mem.nr_banks = 0;
-    bank_size = MIN(GUEST_RAM0_SIZE, kinfo->unassigned_mem);
-    if ( !allocate_bank_memory(d, kinfo, gaddr_to_gfn(GUEST_RAM0_BASE),
-                               bank_size) )
-        goto fail;
-
-    bank_size = MIN(GUEST_RAM1_SIZE, kinfo->unassigned_mem);
-    if ( !allocate_bank_memory(d, kinfo, gaddr_to_gfn(GUEST_RAM1_BASE),
-                               bank_size) )
-        goto fail;
-
-    if ( kinfo->unassigned_mem )
-        goto fail;
-
-    for( i = 0; i < kinfo->mem.nr_banks; i++ )
-    {
-        printk(XENLOG_INFO "%pd BANK[%d] %#"PRIpaddr"-%#"PRIpaddr" (%ldMB)\n",
-               d,
-               i,
-               kinfo->mem.bank[i].start,
-               kinfo->mem.bank[i].start + kinfo->mem.bank[i].size,
-               /* Don't want format this as PRIpaddr (16 digit hex) */
-               (unsigned long)(kinfo->mem.bank[i].size >> 20));
-    }
-
-    return;
-
-fail:
-    panic("Failed to allocate requested domain memory."
-          /* Don't want format this as PRIpaddr (16 digit hex) */
-          " %ldKB unallocated. Fix the VMs configurations.\n",
-          (unsigned long)kinfo->unassigned_mem >> 10);
-}
-
 #ifdef CONFIG_VGICV2
 static int __init make_gicv2_domU_node(struct kernel_info *kinfo)
 {
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 085d88671e..d21be2c57b 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -415,7 +415,6 @@ static void __init allocate_memory_11(struct domain *d,
     }
 }
 
-#ifdef CONFIG_DOM0LESS_BOOT
 bool __init allocate_bank_memory(struct domain *d, struct kernel_info *kinfo,
                                  gfn_t sgfn, paddr_t tot_size)
 {
@@ -477,7 +476,96 @@ bool __init allocate_bank_memory(struct domain *d, struct kernel_info *kinfo,
 
     return true;
 }
-#endif
+
+/* Forward declaration */
+static int __init find_unallocated_memory(const struct kernel_info *kinfo,
+                                          struct meminfo *ext_regions);
+
+void __init allocate_memory(struct domain *d, struct kernel_info *kinfo)
+{
+    unsigned int i = 0;
+    unsigned int nr_banks = 2;
+    paddr_t bank_start, bank_size;
+    struct meminfo *hwdom_free_mem = NULL;
+
+    printk(XENLOG_INFO "Allocating mappings totalling %ldMB for %pd:\n",
+           /* Don't want format this as PRIpaddr (16 digit hex) */
+           (unsigned long)(kinfo->unassigned_mem >> 20), d);
+
+    kinfo->mem.nr_banks = 0;
+    /*
+     * Use host memory layout for hwdom. Only case for this is when LLC coloring
+     * is enabled.
+     */
+    if ( is_hardware_domain(d) )
+    {
+        ASSERT(llc_coloring_enabled);
+
+        hwdom_free_mem = xzalloc(struct meminfo);
+        if ( !hwdom_free_mem )
+            goto fail;
+
+        if ( find_unallocated_memory(kinfo, hwdom_free_mem) )
+            goto fail;
+
+        nr_banks = hwdom_free_mem->nr_banks;
+    }
+
+    for ( ; kinfo->unassigned_mem > 0 && nr_banks > 0; i++, nr_banks-- )
+    {
+        if ( is_hardware_domain(d) )
+        {
+            bank_start = hwdom_free_mem->bank[i].start;
+            bank_size = hwdom_free_mem->bank[i].size;
+
+            if ( bank_size < min_t(paddr_t, kinfo->unassigned_mem, MB(128)) )
+                continue;
+        }
+        else
+        {
+            if ( i == 0 )
+            {
+                bank_start = GUEST_RAM0_BASE;
+                bank_size = GUEST_RAM0_SIZE;
+            }
+            else if ( i == 1 )
+            {
+                bank_start = GUEST_RAM1_BASE;
+                bank_size = GUEST_RAM1_SIZE;
+            }
+            else
+                goto fail;
+        }
+
+        bank_size = MIN(bank_size, kinfo->unassigned_mem);
+        if ( !allocate_bank_memory(d, kinfo, gaddr_to_gfn(bank_start),
+                                   bank_size) )
+            goto fail;
+    }
+
+    if ( kinfo->unassigned_mem )
+        goto fail;
+
+    for( i = 0; i < kinfo->mem.nr_banks; i++ )
+    {
+        printk(XENLOG_INFO "%pd BANK[%d] %#"PRIpaddr"-%#"PRIpaddr" (%ldMB)\n",
+               d,
+               i,
+               kinfo->mem.bank[i].start,
+               kinfo->mem.bank[i].start + kinfo->mem.bank[i].size,
+               /* Don't want format this as PRIpaddr (16 digit hex) */
+               (unsigned long)(kinfo->mem.bank[i].size >> 20));
+    }
+
+    xfree(hwdom_free_mem);
+    return;
+
+fail:
+    panic("Failed to allocate requested domain memory."
+          /* Don't want format this as PRIpaddr (16 digit hex) */
+          " %ldKB unallocated. Fix the VMs configurations.\n",
+          (unsigned long)kinfo->unassigned_mem >> 10);
+}
 
 /*
  * When PCI passthrough is available we want to keep the
@@ -1161,7 +1249,7 @@ int __init make_hypervisor_node(struct domain *d,
         if ( !ext_regions )
             return -ENOMEM;
 
-        if ( is_domain_direct_mapped(d) )
+        if ( domain_use_host_layout(d) )
         {
             if ( !is_iommu_enabled(d) )
                 res = find_unallocated_memory(kinfo, ext_regions);
@@ -2073,7 +2161,10 @@ static int __init construct_dom0(struct domain *d)
     /* type must be set before allocate_memory */
     d->arch.type = kinfo.type;
 #endif
-    allocate_memory_11(d, &kinfo);
+    if ( is_domain_direct_mapped(d) )
+        allocate_memory_11(d, &kinfo);
+    else
+        allocate_memory(d, &kinfo);
     find_gnttab_region(d, &kinfo);
 
     rc = process_shm_chosen(d, &kinfo);
diff --git a/xen/arch/arm/include/asm/domain_build.h b/xen/arch/arm/include/asm/domain_build.h
index da9e6025f3..b8e171e5cc 100644
--- a/xen/arch/arm/include/asm/domain_build.h
+++ b/xen/arch/arm/include/asm/domain_build.h
@@ -8,6 +8,7 @@ typedef __be32 gic_interrupt_t[3];
 
 bool allocate_bank_memory(struct domain *d, struct kernel_info *kinfo,
                           gfn_t sgfn, paddr_t tot_size);
+void allocate_memory(struct domain *d, struct kernel_info *kinfo);
 int construct_domain(struct domain *d, struct kernel_info *kinfo);
 int domain_fdt_begin_node(void *fdt, const char *name, uint64_t unit);
 int make_chosen_node(const struct kernel_info *kinfo);
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Mar 15 10:59:44 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 10:59:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693751.1082242 (Exim 4.92)
	(envelope-from )
	id 1rl5Hs-0001Ya-IK; Fri, 15 Mar 2024 10:59:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693751.1082242; Fri, 15 Mar 2024 10:59:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl5Hs-0001Y0-C9; Fri, 15 Mar 2024 10:59:44 +0000
Received: by outflank-mailman (input) for mailman id 693751;
 Fri, 15 Mar 2024 10:59:43 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rl5Hr-0000xG-Cd
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 10:59:43 +0000
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com
 [2a00:1450:4864:20::629])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1fbae93e-e2bb-11ee-a1ee-f123f15fe8a2;
 Fri, 15 Mar 2024 11:59:41 +0100 (CET)
Received: by mail-ej1-x629.google.com with SMTP id
 a640c23a62f3a-a4682272ff6so74871766b.2
 for ; Fri, 15 Mar 2024 03:59:41 -0700 (PDT)
Received: from carlo-ubuntu.mo54.unimo.it (nonato.mo54.unimo.it.
 [155.185.85.8]) by smtp.gmail.com with ESMTPSA id
 en6-20020a17090728c600b00a465a012cf1sm1621493ejc.18.2024.03.15.03.59.39
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 15 Mar 2024 03:59:40 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1fbae93e-e2bb-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1710500380; x=1711105180; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=/2v5J5S6fkJ+uKCqq6m+sZTt6B+LqvwXJp/jvybin1k=;
        b=BPTzWojcNtCaSf1/MrwzKjYozF8M+g8IoQPW3OW9B9qUldhHoMRfAaxw2MqEw3/QoW
         zQ/iegoaVeeFxTcWFCySQVd3kj4ee+Nd/+uILiO0+n9udLasHSexWh+GNOUgciQ6km2a
         VjNBI8ksZMROox4AEEarHd379lF7zQZyVd+iMNY+qUY9/Vn6jOIpF4FbbyMgFBc+fsv7
         8ZR8F3kGQBdWQM4ufDWdefkRFLF/zrRIGZN0Qu+NVRWdL2sMdSSzPEL6bPVn5HmCl9BK
         xH1ZMbnEL/BPtXdJL456c8uWfRYdM9Mn2kb/I8zi8qciag7VS7nOnBCr7ZJgbfyBKe70
         TIMg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710500380; x=1711105180;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=/2v5J5S6fkJ+uKCqq6m+sZTt6B+LqvwXJp/jvybin1k=;
        b=BpYj95qh8xdVkAa1TV0Qvl0YCPEpD762yRvRPi63F4Wn/mh71OcAUBR6Lj/CKWIOMS
         q8x6yXi3C8yeBd1JnkTBY3eAVsm+dXC80TTOcWAt4aHDpyvKd7Rq66EVbfAgQB1tfNmd
         Dq/CGjSwCX+NiM43d286MrSArwdIgwoILYgnaDhFy9EU7/XYDAgbOHztAUbIuhqpoKlG
         mY2ykzY/Or0ltNpWT3ew4pyx/leqyPs43lczXkQEOYAiWBWHCKC8f2vNCEnkfEmJsZWm
         3719755U4zC1+4VEPtXbMW17sTs0EVOZKtrYbL9s3amAtxUy2sLQGDCKOPWrkgT7vzWJ
         m8Cw==
X-Gm-Message-State: AOJu0Yz9is77vaSvQnmE12xAF45Y6EgPuNU3wr/94eNIaFEhop5v8Z5E
	NH8A6t1hkivNIn7KwiHxq3MRGlQUqOYXrKXsc4zCmQmPN03fo4M1sgZaCx/UDgHcSKRiQq2oeh9
	cN+Q=
X-Google-Smtp-Source: AGHT+IG0AJsxocPF4EmR44olv+T0FuBTWutAsozsmvN0BMhXTg/2NAX/gD+c4ZdKPiRK9F9JUb4AgQ==
X-Received: by 2002:a17:906:e286:b0:a46:220b:25b4 with SMTP id gg6-20020a170906e28600b00a46220b25b4mr2436716ejb.11.1710500380493;
        Fri, 15 Mar 2024 03:59:40 -0700 (PDT)
From: Carlo Nonato 
To: xen-devel@lists.xenproject.org
Cc: Carlo Nonato ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini ,
	Wei Liu ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Marco Solieri 
Subject: [PATCH v7 04/14] xen/arm: add Dom0 cache coloring support
Date: Fri, 15 Mar 2024 11:58:52 +0100
Message-Id: <20240315105902.160047-5-carlo.nonato@minervasys.tech>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
References: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Add a command line parameter to allow the user to set the coloring
configuration for Dom0.
A common configuration syntax for cache colors is introduced and
documented.
Take the opportunity to also add:
 - default configuration notion.
 - function to check well-formed configurations.

Direct mapping Dom0 isn't possible when coloring is enabled, so
CDF_directmap flag is removed when creating it.

Based on original work from: Luca Miccio 

Signed-off-by: Carlo Nonato 
Signed-off-by: Marco Solieri 
---
v7:
- parse_color_config() doesn't accept leading/trailing commas anymore
- removed alloc_colors() helper
v6:
- moved domain_llc_coloring_free() in this patch
- removed domain_alloc_colors() in favor of a more explicit allocation
- parse_color_config() now accepts the size of the array to be filled
- allocate_memory() moved in another patch
v5:
- Carlo Nonato as the new author
- moved dom0 colors parsing (parse_colors()) in this patch
- added dom0_set_llc_colors() to set dom0 colors after creation
- moved color allocation and checking in this patch
- error handling when allocating color arrays
- FIXME: copy pasted allocate_memory() cause it got moved
v4:
- dom0 colors are dynamically allocated as for any other domain
  (colors are duplicated in dom0_colors and in the new array, but logic
  is simpler)
---
 docs/misc/cache-coloring.rst      |  29 +++++++
 docs/misc/xen-command-line.pandoc |   9 +++
 xen/arch/arm/domain_build.c       |  10 ++-
 xen/common/domain.c               |   3 +
 xen/common/llc-coloring.c         | 128 ++++++++++++++++++++++++++++++
 xen/include/xen/llc-coloring.h    |   3 +
 6 files changed, 181 insertions(+), 1 deletion(-)

diff --git a/docs/misc/cache-coloring.rst b/docs/misc/cache-coloring.rst
index 871e7a3ddb..4c859135cb 100644
--- a/docs/misc/cache-coloring.rst
+++ b/docs/misc/cache-coloring.rst
@@ -114,6 +114,35 @@ Specific documentation is available at `docs/misc/xen-command-line.pandoc`.
 +----------------------+-------------------------------+
 | ``llc-nr-ways``      | set the LLC number of ways    |
 +----------------------+-------------------------------+
+| ``dom0-llc-colors``  | Dom0 color configuration      |
++----------------------+-------------------------------+
+
+Colors selection format
+***********************
+
+Regardless of the memory pool that has to be colored (Xen, Dom0/DomUs),
+the color selection can be expressed using the same syntax. In particular a
+comma-separated list of colors or ranges of colors is used.
+Ranges are hyphen-separated intervals (such as `0-4`) and are inclusive on both
+sides.
+
+Note that:
+
+- no spaces are allowed between values.
+- no overlapping ranges or duplicated colors are allowed.
+- values must be written in ascending order.
+
+Examples:
+
++-------------------+-----------------------------+
+| **Configuration** | **Actual selection**        |
++-------------------+-----------------------------+
+| 1-2,5-8           | [1, 2, 5, 6, 7, 8]          |
++-------------------+-----------------------------+
+| 4-8,10,11,12      | [4, 5, 6, 7, 8, 10, 11, 12] |
++-------------------+-----------------------------+
+| 0                 | [0]                         |
++-------------------+-----------------------------+
 
 Auto-probing of LLC specs
 #########################
diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
index 2936abea2c..28035a214d 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -963,6 +963,15 @@ Controls for the dom0 IOMMU setup.
 
 Specify a list of IO ports to be excluded from dom0 access.
 
+### dom0-llc-colors
+> `= List of [  | - ]`
+
+> Default: `All available LLC colors`
+
+Specify dom0 LLC color configuration. This option is available only when
+`CONFIG_LLC_COLORING` is enabled. If the parameter is not set, all available
+colors are used.
+
 ### dom0_max_vcpus
 
 Either:
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index d21be2c57b..3de1659836 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2,6 +2,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -2208,6 +2209,7 @@ void __init create_dom0(void)
         .max_maptrack_frames = -1,
         .grant_opts = XEN_DOMCTL_GRANT_version(opt_gnttab_max_version),
     };
+    unsigned int flags = CDF_privileged;
     int rc;
 
     /* The vGIC for DOM0 is exactly emulating the hardware GIC */
@@ -2235,10 +2237,16 @@ void __init create_dom0(void)
             panic("SVE vector length error\n");
     }
 
-    dom0 = domain_create(0, &dom0_cfg, CDF_privileged | CDF_directmap);
+    if ( !llc_coloring_enabled )
+        flags |= CDF_directmap;
+
+    dom0 = domain_create(0, &dom0_cfg, flags);
     if ( IS_ERR(dom0) )
         panic("Error creating domain 0 (rc = %ld)\n", PTR_ERR(dom0));
 
+    if ( llc_coloring_enabled && (rc = dom0_set_llc_colors(dom0)) )
+        panic("Error initializing LLC coloring for domain 0 (rc = %d)", rc);
+
     if ( alloc_dom0_vcpu0(dom0) == NULL )
         panic("Error creating domain 0 vcpu0\n");
 
diff --git a/xen/common/domain.c b/xen/common/domain.c
index f6f5574996..f144b54f4f 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1208,6 +1209,8 @@ void domain_destroy(struct domain *d)
 
     BUG_ON(!d->is_dying);
 
+    domain_llc_coloring_free(d);
+
     /* May be already destroyed, or get_domain() can race us. */
     if ( atomic_cmpxchg(&d->refcnt, 0, DOMAIN_DESTROYED) != 0 )
         return;
diff --git a/xen/common/llc-coloring.c b/xen/common/llc-coloring.c
index 51eae90ad5..ebd7087dc2 100644
--- a/xen/common/llc-coloring.c
+++ b/xen/common/llc-coloring.c
@@ -18,6 +18,63 @@ integer_param("llc-nr-ways", llc_nr_ways);
 /* Number of colors available in the LLC */
 static unsigned int __ro_after_init max_nr_colors;
 
+static unsigned int __initdata dom0_colors[CONFIG_NR_LLC_COLORS];
+static unsigned int __initdata dom0_num_colors;
+
+/*
+ * Parse the coloring configuration given in the buf string, following the
+ * syntax below.
+ *
+ * COLOR_CONFIGURATION ::= COLOR | RANGE,...,COLOR | RANGE
+ * RANGE               ::= COLOR-COLOR
+ *
+ * Example: "0,2-6,15-16" represents the set of colors: 0,2,3,4,5,6,15,16.
+ */
+static int __init parse_color_config(const char *buf, unsigned int *colors,
+                                     unsigned int max_num_colors,
+                                     unsigned int *num_colors)
+{
+    const char *s = buf;
+
+    *num_colors = 0;
+
+    while ( *s != '\0' )
+    {
+        unsigned int color, start, end;
+
+        start = simple_strtoul(s, &s, 0);
+
+        if ( *s == '-' )    /* Range */
+        {
+            s++;
+            end = simple_strtoul(s, &s, 0);
+        }
+        else                /* Single value */
+            end = start;
+
+        if ( start > end || (end - start) > (UINT_MAX - *num_colors) ||
+             (*num_colors + (end - start)) >= max_num_colors )
+            return -EINVAL;
+
+        for ( color = start; color <= end; color++ )
+            colors[(*num_colors)++] = color;
+
+        if ( *s == ',' )
+            s++;
+        else if ( *s != '\0' )
+            break;
+    }
+
+    return *s ? -EINVAL : 0;
+}
+
+static int __init parse_dom0_colors(const char *s)
+{
+    return parse_color_config(s, dom0_colors, ARRAY_SIZE(dom0_colors),
+                              &dom0_num_colors);
+}
+custom_param("dom0-llc-colors", parse_dom0_colors);
+
 static void print_colors(const unsigned int *colors, unsigned int num_colors)
 {
     unsigned int i;
@@ -41,6 +98,22 @@ static void print_colors(const unsigned int *colors, unsigned int num_colors)
     printk(" }\n");
 }
 
+static bool check_colors(const unsigned int *colors, unsigned int num_colors)
+{
+    unsigned int i;
+
+    for ( i = 0; i < num_colors; i++ )
+    {
+        if ( colors[i] >= max_nr_colors )
+        {
+            printk(XENLOG_ERR "LLC color %u >= %u\n", colors[i], max_nr_colors);
+            return false;
+        }
+    }
+
+    return true;
+}
+
 void __init llc_coloring_init(void)
 {
     unsigned int way_size;
@@ -91,6 +164,61 @@ void cf_check domain_dump_llc_colors(const struct domain *d)
     print_colors(d->llc_colors, d->num_llc_colors);
 }
 
+static int domain_set_default_colors(struct domain *d)
+{
+    unsigned int *colors = xmalloc_array(unsigned int, max_nr_colors);
+    unsigned int i;
+
+    if ( !colors )
+        return -ENOMEM;
+
+    printk(XENLOG_WARNING
+           "LLC color config not found for %pd, using all colors\n", d);
+
+    for ( i = 0; i < max_nr_colors; i++ )
+        colors[i] = i;
+
+    d->llc_colors = colors;
+    d->num_llc_colors = max_nr_colors;
+
+    return 0;
+}
+
+int __init dom0_set_llc_colors(struct domain *d)
+{
+    unsigned int *colors;
+
+    if ( !dom0_num_colors )
+        return domain_set_default_colors(d);
+
+    if ( !check_colors(dom0_colors, dom0_num_colors) )
+    {
+        printk(XENLOG_ERR "Bad LLC color config for %pd\n", d);
+        return -EINVAL;
+    }
+
+    colors = xmalloc_array(unsigned int, dom0_num_colors);
+    if ( !colors )
+        return -ENOMEM;
+
+    /* Static type checking */
+    (void)(colors == dom0_colors);
+    memcpy(colors, dom0_colors, sizeof(*colors) * dom0_num_colors);
+    d->llc_colors = colors;
+    d->num_llc_colors = dom0_num_colors;
+
+    return 0;
+}
+
+void domain_llc_coloring_free(struct domain *d)
+{
+    if ( !llc_coloring_enabled )
+        return;
+
+    /* free pointer-to-const using __va(__pa()) */
+    xfree(__va(__pa(d->llc_colors)));
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/xen/llc-coloring.h b/xen/include/xen/llc-coloring.h
index 67b27c995b..ee82932266 100644
--- a/xen/include/xen/llc-coloring.h
+++ b/xen/include/xen/llc-coloring.h
@@ -16,16 +16,19 @@ extern bool llc_coloring_enabled;
 void llc_coloring_init(void);
 void dump_llc_coloring_info(void);
 void domain_dump_llc_colors(const struct domain *d);
+void domain_llc_coloring_free(struct domain *d);
 #else
 #define llc_coloring_enabled false
 
 static inline void llc_coloring_init(void) {}
 static inline void dump_llc_coloring_info(void) {}
 static inline void domain_dump_llc_colors(const struct domain *d) {}
+static inline void domain_llc_coloring_free(struct domain *d) {}
 #endif
 
 unsigned int get_llc_way_size(void);
 void arch_llc_coloring_init(void);
+int dom0_set_llc_colors(struct domain *d);
 
 #endif /* __COLORING_H__ */
 
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Mar 15 10:59:45 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 10:59:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693752.1082251 (Exim 4.92)
	(envelope-from )
	id 1rl5Ht-0001rd-Sr; Fri, 15 Mar 2024 10:59:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693752.1082251; Fri, 15 Mar 2024 10:59:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl5Ht-0001qr-On; Fri, 15 Mar 2024 10:59:45 +0000
Received: by outflank-mailman (input) for mailman id 693752;
 Fri, 15 Mar 2024 10:59:44 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rl5Hs-0000xG-01
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 10:59:44 +0000
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com
 [2a00:1450:4864:20::629])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 203480fb-e2bb-11ee-a1ee-f123f15fe8a2;
 Fri, 15 Mar 2024 11:59:42 +0100 (CET)
Received: by mail-ej1-x629.google.com with SMTP id
 a640c23a62f3a-a468004667aso114424566b.2
 for ; Fri, 15 Mar 2024 03:59:42 -0700 (PDT)
Received: from carlo-ubuntu.mo54.unimo.it (nonato.mo54.unimo.it.
 [155.185.85.8]) by smtp.gmail.com with ESMTPSA id
 en6-20020a17090728c600b00a465a012cf1sm1621493ejc.18.2024.03.15.03.59.40
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 15 Mar 2024 03:59:40 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 203480fb-e2bb-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1710500382; x=1711105182; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=IC3TyEtibJD75zpZ0IhFnt1yswFb6xMybexaSNsbLU0=;
        b=S2jWAS5ed8AmzQGWbYvL3pIy3IErB351gE884DFupXsyNOczxcj+tBpg9CZe9qJw+N
         61NPLJhimFLDT3sQLtj1UUjzJ+wFlcNzz1zcMqVmINU8XMJrMS/g9BiU8Le269176uMx
         9/R4YNCe1iW3RsPqzYv6qkg7bykYhufAxosyeYspsyVdncSLm6GVpRvplBxFOTPOevIG
         i3plOdZcAtf6QiYkEncN1Ackj2LyjoxL0verslnakwYj2lC3Kph3VDf1WjKmNMjWxNG+
         2a2OdZfZ8S4Vn89CglV0j1daJH7tfad+IudrTavRzVhdWoscT/VNO6DP17qNv+mx7VoM
         H/iw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710500382; x=1711105182;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=IC3TyEtibJD75zpZ0IhFnt1yswFb6xMybexaSNsbLU0=;
        b=Jf0WYsA8faLTVnMFMe2oyJCrH4dF/PD0hRyF8FGtTYHFh7Z7tmL7rngV3y4Re0zhfZ
         62Jj/V4K0uVEPgIixVsnhGWYc8fkcn50qS1zg1u3l3JuDPWV9eZspluzDIiqNrEP4vfp
         5+yKN7iF/sOFzcNq74p//bRSwYwxotmKjfiZGWobnJyueNzsJTQe20sDcrloAP4IuGHx
         b/oXI4vEvzIRMCM7JKGs99P3txkqF9GDdKeDpNLwve3cPMw1liDLEpa5AVvMAcRVcqrm
         noagN+e953kh92LcRB2nlCaw7qjcFI57jqJsMa6iuLMU1P6cMeBffdL9YK2mUI2hSYDD
         wJhQ==
X-Gm-Message-State: AOJu0YxW9iLCuexcY797MI6Cdqw8vNgOHFCk5PTH+yK2twg3U4wUJQ8f
	XLARi9ekwjjRiKYOQd2Tfv1Eqst4KxfWYUoVtC9rjhjvXIT1KKPZ7ewAwAZFUYBTQv46oNAOuZU
	ItkM=
X-Google-Smtp-Source: AGHT+IFcPZ4YeaeLnZKZdbdcuJWgPQ0ngX5yOAq9oJjhTwcqxTMdBH22sUfXDBtkFRjEWudJT6Eliw==
X-Received: by 2002:a17:907:cbc7:b0:a46:7933:9839 with SMTP id vk7-20020a170907cbc700b00a4679339839mr2732511ejc.71.1710500381583;
        Fri, 15 Mar 2024 03:59:41 -0700 (PDT)
From: Carlo Nonato 
To: xen-devel@lists.xenproject.org
Cc: Carlo Nonato ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini ,
	Wei Liu ,
	Marco Solieri 
Subject: [PATCH v7 05/14] xen: extend domctl interface for cache coloring
Date: Fri, 15 Mar 2024 11:58:53 +0100
Message-Id: <20240315105902.160047-6-carlo.nonato@minervasys.tech>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
References: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Add a new domctl hypercall to allow the user to set LLC coloring
configurations. Colors can be set only once, just after domain creation,
since recoloring isn't supported.

Based on original work from: Luca Miccio 

Signed-off-by: Carlo Nonato 
Signed-off-by: Marco Solieri 
---
v7:
- -EOPNOTSUPP returned in case of hypercall called without llc_coloring_enabled
- domain_set_llc_colors_domctl() renamed to domain_set_llc_colors()
- added padding and input bound checks to domain_set_llc_colors()
- removed alloc_colors() helper usage from domain_set_llc_colors()
v6:
- reverted the XEN_DOMCTL_INTERFACE_VERSION bump
- reverted to uint32 for the guest handle
- explicit padding added to the domctl struct
- rewrote domain_set_llc_colors_domctl() to be more explicit
v5:
- added a new hypercall to set colors
- uint for the guest handle
v4:
- updated XEN_DOMCTL_INTERFACE_VERSION
---
 xen/common/domctl.c            |  8 ++++++++
 xen/common/llc-coloring.c      | 34 ++++++++++++++++++++++++++++++++++
 xen/include/public/domctl.h    |  9 +++++++++
 xen/include/xen/llc-coloring.h |  2 ++
 4 files changed, 53 insertions(+)

diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index f5a71ee5f7..6c940ac833 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -8,6 +8,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -858,6 +859,13 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
                 __HYPERVISOR_domctl, "h", u_domctl);
         break;
 
+    case XEN_DOMCTL_set_llc_colors:
+        if ( llc_coloring_enabled )
+            ret = domain_set_llc_colors(d, &op->u.set_llc_colors);
+        else
+            ret = -EOPNOTSUPP;
+        break;
+
     default:
         ret = arch_do_domctl(op, d, u_domctl);
         break;
diff --git a/xen/common/llc-coloring.c b/xen/common/llc-coloring.c
index ebd7087dc2..9c1f152b96 100644
--- a/xen/common/llc-coloring.c
+++ b/xen/common/llc-coloring.c
@@ -4,6 +4,7 @@
  *
  * Copyright (C) 2022 Xilinx Inc.
  */
+#include 
 #include 
 #include 
 #include 
@@ -219,6 +220,39 @@ void domain_llc_coloring_free(struct domain *d)
     xfree(__va(__pa(d->llc_colors)));
 }
 
+int domain_set_llc_colors(struct domain *d,
+                          const struct xen_domctl_set_llc_colors *config)
+{
+    unsigned int *colors;
+
+    if ( d->num_llc_colors )
+        return -EEXIST;
+
+    if ( !config->num_llc_colors )
+        return domain_set_default_colors(d);
+
+    if ( config->num_llc_colors > max_nr_colors || config->pad )
+        return -EINVAL;
+
+    colors = xmalloc_array(unsigned int, config->num_llc_colors);
+    if ( !colors )
+        return -ENOMEM;
+
+    if ( copy_from_guest(colors, config->llc_colors, config->num_llc_colors) )
+        return -EFAULT;
+
+    if ( !check_colors(colors, config->num_llc_colors) )
+    {
+        printk(XENLOG_ERR "Bad LLC color config for %pd\n", d);
+        return -EINVAL;
+    }
+
+    d->llc_colors = colors;
+    d->num_llc_colors = config->num_llc_colors;
+
+    return 0;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index a33f9ec32b..d44eac8775 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -1190,6 +1190,13 @@ struct xen_domctl_vmtrace_op {
 typedef struct xen_domctl_vmtrace_op xen_domctl_vmtrace_op_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_vmtrace_op_t);
 
+struct xen_domctl_set_llc_colors {
+    /* IN LLC coloring parameters */
+    uint32_t num_llc_colors;
+    uint32_t pad;
+    XEN_GUEST_HANDLE_64(uint32) llc_colors;
+};
+
 struct xen_domctl {
     uint32_t cmd;
 #define XEN_DOMCTL_createdomain                   1
@@ -1277,6 +1284,7 @@ struct xen_domctl {
 #define XEN_DOMCTL_vmtrace_op                    84
 #define XEN_DOMCTL_get_paging_mempool_size       85
 #define XEN_DOMCTL_set_paging_mempool_size       86
+#define XEN_DOMCTL_set_llc_colors                87
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -1339,6 +1347,7 @@ struct xen_domctl {
         struct xen_domctl_vuart_op          vuart_op;
         struct xen_domctl_vmtrace_op        vmtrace_op;
         struct xen_domctl_paging_mempool    paging_mempool;
+        struct xen_domctl_set_llc_colors    set_llc_colors;
         uint8_t                             pad[128];
     } u;
 };
diff --git a/xen/include/xen/llc-coloring.h b/xen/include/xen/llc-coloring.h
index ee82932266..b3801fca00 100644
--- a/xen/include/xen/llc-coloring.h
+++ b/xen/include/xen/llc-coloring.h
@@ -29,6 +29,8 @@ static inline void domain_llc_coloring_free(struct domain *d) {}
 unsigned int get_llc_way_size(void);
 void arch_llc_coloring_init(void);
 int dom0_set_llc_colors(struct domain *d);
+int domain_set_llc_colors(struct domain *d,
+                          const struct xen_domctl_set_llc_colors *config);
 
 #endif /* __COLORING_H__ */
 
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Mar 15 10:59:47 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 10:59:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693753.1082262 (Exim 4.92)
	(envelope-from )
	id 1rl5Hv-00028T-9I; Fri, 15 Mar 2024 10:59:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693753.1082262; Fri, 15 Mar 2024 10:59:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl5Hv-00027S-24; Fri, 15 Mar 2024 10:59:47 +0000
Received: by outflank-mailman (input) for mailman id 693753;
 Fri, 15 Mar 2024 10:59:45 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rl5Hs-0000aQ-VU
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 10:59:44 +0000
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com
 [2a00:1450:4864:20::533])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 212f74e8-e2bb-11ee-afdd-a90da7624cb6;
 Fri, 15 Mar 2024 11:59:44 +0100 (CET)
Received: by mail-ed1-x533.google.com with SMTP id
 4fb4d7f45d1cf-568a5114881so1760170a12.1
 for ; Fri, 15 Mar 2024 03:59:44 -0700 (PDT)
Received: from carlo-ubuntu.mo54.unimo.it (nonato.mo54.unimo.it.
 [155.185.85.8]) by smtp.gmail.com with ESMTPSA id
 en6-20020a17090728c600b00a465a012cf1sm1621493ejc.18.2024.03.15.03.59.42
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 15 Mar 2024 03:59:42 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 212f74e8-e2bb-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1710500383; x=1711105183; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=5+Vu4Fggbp4Y0GsyZklBM1aj7v1C64ye9Ydxu/52UA4=;
        b=oFxcQO8haE1PxcQFVgrfHyCmmc37zHKpyPaPYyFxlL/+XgUi760o9xRe3FytITDw+1
         RZUE1i2pyMsmAeMQsEwlHl+nGsk/2nvAQ6xfudS/9AcdBr30sZTqizZ2osznHxaVLs4A
         XDPBUJ0V2OmtWe7Z4nfiu4Yaka1XRfSw6stzN+H/4jeYlpY/3hdrcablgxKgv8jT8XNI
         F/kYBW7H/XrjxkwOKbNb2hyww0NQUxgKMUeggUakZ+VsVolOFuOFhguF6oVSUVQwD4yR
         jN9jBIlcgXZI49SP9MMVP/eP2OWzwwXyIKkHBuQKgL82+q58GC/p0Oi201pbi9gk/7EV
         I0Vg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710500383; x=1711105183;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=5+Vu4Fggbp4Y0GsyZklBM1aj7v1C64ye9Ydxu/52UA4=;
        b=cFhzb1j1MGi54u5VdJ5fd6kNgP4O4HYuK2Dg0jh3n0Bw6au8N20+ji1z1iLZc1rrfc
         XZY9bRoj3gAmRtTW6LBQVrV0AOQnq5UlEVc6ce7X2pBtOKwv9kq5Q/WY/xMHUmyJr9WC
         tVsm++hdoo3IB0GchrNXDUYL4oGMxENf6qtmn5a/KeY6koHxfDbQULn2zEfrOUQkYy2K
         st/JgpStdlSqxMB9YpjewxL61aksB4JhpJ3HHFtcM5Yo+NQVCaZ9XrpZYXdoZazATu3V
         29/RGVpLikclcYp9dGmMXHIcJcPllfrL/Rm+lnmyETlTH4yvn0X/I6eKpiJBd1x0J+3t
         SlNQ==
X-Gm-Message-State: AOJu0Yx6GUemoitrkW+J3Kg4qr+FfUtvoXcFORorXxrSSVCiEY2ZQS/v
	UWglIdV7542QiVSjyx2bz8G6tSywglNksc6uUOzspKKi4r3wZNMIYPACEDxHmWHRguaS3ZDSGxB
	7PKo=
X-Google-Smtp-Source: AGHT+IESDraWCMlp4kM9GuRaW/ZTZSKmJifqtNLUnrRbvvn0kvJI180ejOrrRWcSpx3DHP6Bs3jhqw==
X-Received: by 2002:a17:907:cbc5:b0:a46:7ba4:9cb with SMTP id vk5-20020a170907cbc500b00a467ba409cbmr2517075ejc.9.1710500383400;
        Fri, 15 Mar 2024 03:59:43 -0700 (PDT)
From: Carlo Nonato 
To: xen-devel@lists.xenproject.org
Cc: Carlo Nonato ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Wei Liu ,
	Marco Solieri 
Subject: [PATCH v7 07/14] xen/arm: add support for cache coloring configuration via device-tree
Date: Fri, 15 Mar 2024 11:58:55 +0100
Message-Id: <20240315105902.160047-8-carlo.nonato@minervasys.tech>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
References: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Add the "llc-colors" Device Tree attribute to express DomUs and Dom0less
color configurations.

Based on original work from: Luca Miccio 

Signed-off-by: Carlo Nonato 
Signed-off-by: Marco Solieri 
---
v7:
- removed alloc_colors() helper usage from domain_set_llc_colors_from_str()
v6:
- rewrote domain_set_llc_colors_from_str() to be more explicit
v5:
- static-mem check has been moved in a previous patch
- added domain_set_llc_colors_from_str() to set colors after domain creation
---
 docs/misc/arm/device-tree/booting.txt |  4 +++
 docs/misc/cache-coloring.rst          | 48 +++++++++++++++++++++++++++
 xen/arch/arm/dom0less-build.c         | 10 ++++++
 xen/common/llc-coloring.c             | 31 +++++++++++++++++
 xen/include/xen/llc-coloring.h        |  1 +
 5 files changed, 94 insertions(+)

diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-tree/booting.txt
index bbd955e9c2..bbe49faadc 100644
--- a/docs/misc/arm/device-tree/booting.txt
+++ b/docs/misc/arm/device-tree/booting.txt
@@ -162,6 +162,10 @@ with the following properties:
 
     An integer specifying the number of vcpus to allocate to the guest.
 
+- llc-colors
+    A string specifying the LLC color configuration for the guest.
+    Refer to docs/misc/cache_coloring.rst for syntax.
+
 - vpl011
 
     An empty property to enable/disable a virtual pl011 for the guest to
diff --git a/docs/misc/cache-coloring.rst b/docs/misc/cache-coloring.rst
index 4c859135cb..028aecda28 100644
--- a/docs/misc/cache-coloring.rst
+++ b/docs/misc/cache-coloring.rst
@@ -12,6 +12,7 @@ If needed, change the maximum number of colors with
 ``CONFIG_NR_LLC_COLORS=``.
 
 Runtime configuration is done via `Command line parameters`_.
+For DomUs follow `DomUs configuration`_.
 
 Background
 **********
@@ -156,6 +157,53 @@ LLC specs can be manually set via the above command line parameters. This
 bypasses any auto-probing and it's used to overcome failing situations or for
 debugging/testing purposes.
 
+DomUs configuration
+*******************
+
+DomUs colors can be set either in the ``xl`` configuration file (documentation
+at `docs/man/xl.cfg.pod.5.in`) or via Device Tree, also for Dom0less
+configurations (documentation at `docs/misc/arm/device-tree/booting.txt`) using
+the ``llc-colors`` option. For example:
+
+::
+
+    xen,xen-bootargs = "console=dtuart dtuart=serial0 dom0_mem=1G dom0_max_vcpus=1 sched=null llc-coloring=on dom0-llc-colors=2-6";
+    xen,dom0-bootargs "console=hvc0 earlycon=xen earlyprintk=xen root=/dev/ram0"
+
+    dom0 {
+        compatible = "xen,linux-zimage" "xen,multiboot-module";
+        reg = <0x0 0x1000000 0x0 15858176>;
+    };
+
+    dom0-ramdisk {
+        compatible = "xen,linux-initrd" "xen,multiboot-module";
+        reg = <0x0 0x2000000 0x0 20638062>;
+    };
+
+    domU0 {
+        #address-cells = <0x1>;
+        #size-cells = <0x1>;
+        compatible = "xen,domain";
+        memory = <0x0 0x40000>;
+        llc-colors = "4-8,10,11,12";
+        cpus = <0x1>;
+        vpl011 = <0x1>;
+
+        module@2000000 {
+            compatible = "multiboot,kernel", "multiboot,module";
+            reg = <0x2000000 0xffffff>;
+            bootargs = "console=ttyAMA0";
+        };
+
+        module@30000000 {
+            compatible = "multiboot,ramdisk", "multiboot,module";
+            reg = <0x3000000 0xffffff>;
+        };
+    };
+
+**Note:** If no color configuration is provided for a domain, the default one,
+which corresponds to all available colors is used instead.
+
 Known issues and limitations
 ****************************
 
diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
index 992080e61a..f7ac9b9900 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch/arm/dom0less-build.c
@@ -807,6 +807,7 @@ void __init create_domUs(void)
     struct dt_device_node *node;
     const struct dt_device_node *cpupool_node,
                                 *chosen = dt_find_node_by_path("/chosen");
+    const char *llc_colors_str = NULL;
 
     BUG_ON(chosen == NULL);
     dt_for_each_child_node(chosen, node)
@@ -950,6 +951,10 @@ void __init create_domUs(void)
 #endif
         }
 
+        dt_property_read_string(node, "llc-colors", &llc_colors_str);
+        if ( !llc_coloring_enabled && llc_colors_str)
+            panic("'llc-colors' found, but LLC coloring is disabled\n");
+
         /*
          * The variable max_init_domid is initialized with zero, so here it's
          * very important to use the pre-increment operator to call
@@ -960,6 +965,11 @@ void __init create_domUs(void)
             panic("Error creating domain %s (rc = %ld)\n",
                   dt_node_name(node), PTR_ERR(d));
 
+        if ( llc_coloring_enabled &&
+             (rc = domain_set_llc_colors_from_str(d, llc_colors_str)) )
+            panic("Error initializing LLC coloring for domain %s (rc = %d)\n",
+                  dt_node_name(node), rc);
+
         d->is_console = true;
         dt_device_set_used_by(node, d->domain_id);
 
diff --git a/xen/common/llc-coloring.c b/xen/common/llc-coloring.c
index 9c1f152b96..77d24553e0 100644
--- a/xen/common/llc-coloring.c
+++ b/xen/common/llc-coloring.c
@@ -253,6 +253,37 @@ int domain_set_llc_colors(struct domain *d,
     return 0;
 }
 
+int __init domain_set_llc_colors_from_str(struct domain *d, const char *str)
+{
+    int err;
+    unsigned int *colors, num_colors;
+
+    if ( !str )
+        return domain_set_default_colors(d);
+
+    colors = xmalloc_array(unsigned int, max_nr_colors);
+    if ( !colors )
+        return -ENOMEM;
+
+    err = parse_color_config(str, colors, max_nr_colors, &num_colors);
+    if ( err )
+    {
+        printk(XENLOG_ERR "Error parsing LLC color configuration");
+        return err;
+    }
+
+    if ( !check_colors(colors, num_colors) )
+    {
+        printk(XENLOG_ERR "Bad LLC color config for %pd\n", d);
+        return -EINVAL;
+    }
+
+    d->llc_colors = colors;
+    d->num_llc_colors = num_colors;
+
+    return 0;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/xen/llc-coloring.h b/xen/include/xen/llc-coloring.h
index b3801fca00..49ebd1e712 100644
--- a/xen/include/xen/llc-coloring.h
+++ b/xen/include/xen/llc-coloring.h
@@ -31,6 +31,7 @@ void arch_llc_coloring_init(void);
 int dom0_set_llc_colors(struct domain *d);
 int domain_set_llc_colors(struct domain *d,
                           const struct xen_domctl_set_llc_colors *config);
+int domain_set_llc_colors_from_str(struct domain *d, const char *str);
 
 #endif /* __COLORING_H__ */
 
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Mar 15 10:59:47 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 10:59:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693754.1082267 (Exim 4.92)
	(envelope-from )
	id 1rl5Hv-0002E4-Ok; Fri, 15 Mar 2024 10:59:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693754.1082267; Fri, 15 Mar 2024 10:59:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl5Hv-0002DT-Fy; Fri, 15 Mar 2024 10:59:47 +0000
Received: by outflank-mailman (input) for mailman id 693754;
 Fri, 15 Mar 2024 10:59:45 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rl5Ht-0000xG-4b
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 10:59:45 +0000
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com
 [2a00:1450:4864:20::633])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 20d5b4fc-e2bb-11ee-a1ee-f123f15fe8a2;
 Fri, 15 Mar 2024 11:59:43 +0100 (CET)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-a449c5411e1so254277066b.1
 for ; Fri, 15 Mar 2024 03:59:43 -0700 (PDT)
Received: from carlo-ubuntu.mo54.unimo.it (nonato.mo54.unimo.it.
 [155.185.85.8]) by smtp.gmail.com with ESMTPSA id
 en6-20020a17090728c600b00a465a012cf1sm1621493ejc.18.2024.03.15.03.59.41
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 15 Mar 2024 03:59:42 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 20d5b4fc-e2bb-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1710500382; x=1711105182; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=E3HBQ0ayQI+jR97F8fnT64pMvcLpR1MuWmyK0hTevP0=;
        b=lJVaGOeaGqFFyHaPYECJvNAl1xuaSje39MiGwLNYKUv79a+L9qsqGmNjajZ4WxFgkf
         OEXgOjoncKPl63PVMJKjnmYPhjYftrsiIBXxyUvFQPpC+9j1WOldu6hMC4qfGkkfO5va
         DptznaZRZWtDdYXm8LLKlkGSgTnBTQJIChrsOb03U4eXTI9aAVbF2wLVALqHWHSXDgiO
         MUYDoaF6PdsJMMgXISt6c3gBX0FD/ux4g0oRALNWZVYbl517fASslvkJjwt+MsExLDc8
         m1p9JnUYKkvdB4YhsmUm1FUYBA/sMGYAJFQ179ynydzfIM/9PcoGGrjmOnaaczHgcMqk
         wRSw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710500382; x=1711105182;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=E3HBQ0ayQI+jR97F8fnT64pMvcLpR1MuWmyK0hTevP0=;
        b=UtmLMxtbd+9tgDWDg3MObJh9+Ng8jThvSfBRY6pkOO2OPDQc6cgZoYNlGkzfbZTUR5
         FxDwIVZsjCZEOaKyUj23cBKexT76v43AXIrmAxon0w5knGbNf4I36LmeS9E+BW4+Joyg
         SHMwlBOAj6ky1T3NfSbqQR03JgnnmVRgMEPtWhcASo3MsYMuMF8qW68a5H/5YQ0Pvo80
         H3yMXt9kUaDzkCSCF6V6Ib6xHGhBi03XFMQX/87sbvGARM0qm94RTkJhVyNgbCOKr5CI
         /m5jgBD8d9Nrj1BpPNuCsDCHghYqkPHjbkKb2OhhjyJl++vmO3LCP8PcpZaKBQ83DjMk
         gSlw==
X-Gm-Message-State: AOJu0YzY78gMuM78WqctGiHU9x8AYohK/BVexi+1dQUY6vYMmZpIAvgW
	VdHXwINtTtlNacZWdk/PnLy4uoJkPK68b0iZIldobSzPZoiNvDCWm9AhvwfEJzO1+AqexrtUrYF
	c/kE=
X-Google-Smtp-Source: AGHT+IGLfdJySe4LkA0Tpn+tYU9zpv7/iHI6deZJiDkyG3TOMq4zlrYZ8SVbRMpY54Rzpxqu2oeWKw==
X-Received: by 2002:a17:906:c2d0:b0:a43:5bc6:17f3 with SMTP id ch16-20020a170906c2d000b00a435bc617f3mr2734090ejb.6.1710500382346;
        Fri, 15 Mar 2024 03:59:42 -0700 (PDT)
From: Carlo Nonato 
To: xen-devel@lists.xenproject.org
Cc: Carlo Nonato ,
	Wei Liu ,
	Anthony PERARD ,
	Juergen Gross ,
	Marco Solieri 
Subject: [PATCH v7 06/14] tools: add support for cache coloring configuration
Date: Fri, 15 Mar 2024 11:58:54 +0100
Message-Id: <20240315105902.160047-7-carlo.nonato@minervasys.tech>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
References: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Add a new "llc_colors" parameter that defines the LLC color assignment for
a domain. The user can specify one or more color ranges using the same
syntax used everywhere else for color config described in the
documentation.
The parameter is defined as a list of strings that represent the color
ranges.

Documentation is also added.

Based on original work from: Luca Miccio 

Signed-off-by: Carlo Nonato 
Signed-off-by: Marco Solieri 
---
v7:
- removed unneeded NULL check before xc_hypercall_buffer_free() in
  xc_domain_set_llc_colors()
v6:
- no edits
v5:
- added LIBXL_HAVE_BUILDINFO_LLC_COLORS
- moved color configuration in xc_domain_set_llc_colors() cause of the new
  hypercall
v4:
- removed overlapping color ranges checks during parsing
- moved hypercall buffer initialization in libxenctrl
---
 docs/man/xl.cfg.5.pod.in         | 10 +++++++++
 tools/include/libxl.h            |  5 +++++
 tools/include/xenctrl.h          |  9 ++++++++
 tools/libs/ctrl/xc_domain.c      | 35 +++++++++++++++++++++++++++++
 tools/libs/light/libxl_create.c  |  9 ++++++++
 tools/libs/light/libxl_types.idl |  1 +
 tools/xl/xl_parse.c              | 38 +++++++++++++++++++++++++++++++-
 7 files changed, 106 insertions(+), 1 deletion(-)

diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
index 039e057318..941de07408 100644
--- a/docs/man/xl.cfg.5.pod.in
+++ b/docs/man/xl.cfg.5.pod.in
@@ -3070,6 +3070,16 @@ raised.
 
 =back
 
+=over 4
+
+=item B
+
+Specify the Last Level Cache (LLC) color configuration for the guest.
+B can be either a single color value or a hypen-separated closed
+interval of colors (such as "0-4").
+
+=back
+
 =head3 x86
 
 =over 4
diff --git a/tools/include/libxl.h b/tools/include/libxl.h
index 62cb07dea6..49521e5da4 100644
--- a/tools/include/libxl.h
+++ b/tools/include/libxl.h
@@ -1368,6 +1368,11 @@ void libxl_mac_copy(libxl_ctx *ctx, libxl_mac *dst, const libxl_mac *src);
  */
 #define LIBXL_HAVE_BUILDINFO_HVM_SYSTEM_FIRMWARE
 
+/*
+ * The libxl_domain_build_info has the llc_colors array.
+ */
+#define LIBXL_HAVE_BUILDINFO_LLC_COLORS 1
+
 /*
  * ERROR_REMUS_XXX error code only exists from Xen 4.5, Xen 4.6 and it
  * is changed to ERROR_CHECKPOINT_XXX in Xen 4.7
diff --git a/tools/include/xenctrl.h b/tools/include/xenctrl.h
index 2ef8b4e054..2c2a5c4bd4 100644
--- a/tools/include/xenctrl.h
+++ b/tools/include/xenctrl.h
@@ -2653,6 +2653,15 @@ int xc_livepatch_replace(xc_interface *xch, char *name, uint32_t timeout, uint32
 int xc_domain_cacheflush(xc_interface *xch, uint32_t domid,
                          xen_pfn_t start_pfn, xen_pfn_t nr_pfns);
 
+/*
+ * Set LLC colors for a domain.
+ * It can only be used directly after domain creation. An attempt to use it
+ * afterwards will result in an error.
+ */
+int xc_domain_set_llc_colors(xc_interface *xch, uint32_t domid,
+                             const unsigned int *llc_colors,
+                             unsigned int num_llc_colors);
+
 #if defined(__arm__) || defined(__aarch64__)
 int xc_dt_overlay(xc_interface *xch, void *overlay_fdt,
                   uint32_t overlay_fdt_size, uint8_t overlay_op);
diff --git a/tools/libs/ctrl/xc_domain.c b/tools/libs/ctrl/xc_domain.c
index f2d9d14b4d..d315cfa6c1 100644
--- a/tools/libs/ctrl/xc_domain.c
+++ b/tools/libs/ctrl/xc_domain.c
@@ -2180,6 +2180,41 @@ int xc_domain_soft_reset(xc_interface *xch,
     domctl.domain = domid;
     return do_domctl(xch, &domctl);
 }
+
+int xc_domain_set_llc_colors(xc_interface *xch, uint32_t domid,
+                             const unsigned int *llc_colors,
+                             unsigned int num_llc_colors)
+{
+    struct xen_domctl domctl = {};
+    DECLARE_HYPERCALL_BUFFER(uint32_t, local);
+    int ret = -1;
+
+    if ( num_llc_colors )
+    {
+        size_t bytes = sizeof(uint32_t) * num_llc_colors;
+
+        local = xc_hypercall_buffer_alloc(xch, local, bytes);
+        if ( local == NULL )
+        {
+            PERROR("Could not allocate LLC colors for set_llc_colors");
+            ret = -ENOMEM;
+            goto out;
+        }
+        memcpy(local, llc_colors, bytes);
+        set_xen_guest_handle(domctl.u.set_llc_colors.llc_colors, local);
+    }
+
+    domctl.cmd = XEN_DOMCTL_set_llc_colors;
+    domctl.domain = domid;
+    domctl.u.set_llc_colors.num_llc_colors = num_llc_colors;
+
+    ret = do_domctl(xch, &domctl);
+
+out:
+    xc_hypercall_buffer_free(xch, local);
+
+    return ret;
+}
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libs/light/libxl_create.c b/tools/libs/light/libxl_create.c
index 5546335973..79f206f616 100644
--- a/tools/libs/light/libxl_create.c
+++ b/tools/libs/light/libxl_create.c
@@ -726,6 +726,15 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config,
             /* A new domain now exists */
             *domid = local_domid;
 
+            ret = xc_domain_set_llc_colors(ctx->xch, local_domid,
+                                           b_info->llc_colors,
+                                           b_info->num_llc_colors);
+            if (ret < 0 && errno != EOPNOTSUPP) {
+                LOGED(ERROR, local_domid, "LLC colors allocation failed");
+                rc = ERROR_FAIL;
+                goto out;
+            }
+
             rc = libxl__is_domid_recent(gc, local_domid, &recent);
             if (rc)
                 goto out;
diff --git a/tools/libs/light/libxl_types.idl b/tools/libs/light/libxl_types.idl
index 470122e768..79118e1582 100644
--- a/tools/libs/light/libxl_types.idl
+++ b/tools/libs/light/libxl_types.idl
@@ -616,6 +616,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
     ("ioports",          Array(libxl_ioport_range, "num_ioports")),
     ("irqs",             Array(uint32, "num_irqs")),
     ("iomem",            Array(libxl_iomem_range, "num_iomem")),
+    ("llc_colors",       Array(uint32, "num_llc_colors")),
     ("claim_mode",	     libxl_defbool),
     ("event_channels",   uint32),
     ("kernel",           string),
diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
index 80ffe85f5e..aa9623a6b9 100644
--- a/tools/xl/xl_parse.c
+++ b/tools/xl/xl_parse.c
@@ -1294,7 +1294,7 @@ void parse_config_data(const char *config_source,
     XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids, *vtpms,
                    *usbctrls, *usbdevs, *p9devs, *vdispls, *pvcallsifs_devs;
     XLU_ConfigList *channels, *ioports, *irqs, *iomem, *viridian, *dtdevs,
-                   *mca_caps, *smbios;
+                   *mca_caps, *smbios, *llc_colors;
     int num_ioports, num_irqs, num_iomem, num_cpus, num_viridian, num_mca_caps;
     int num_smbios;
     int pci_power_mgmt = 0;
@@ -1302,6 +1302,7 @@ void parse_config_data(const char *config_source,
     int pci_permissive = 0;
     int pci_seize = 0;
     int i, e;
+    int num_llc_colors;
     char *kernel_basename;
 
     libxl_domain_create_info *c_info = &d_config->c_info;
@@ -1445,6 +1446,41 @@ void parse_config_data(const char *config_source,
     if (!xlu_cfg_get_long (config, "maxmem", &l, 0))
         b_info->max_memkb = l * 1024;
 
+    if (!xlu_cfg_get_list(config, "llc_colors", &llc_colors, &num_llc_colors, 0)) {
+        int cur_index = 0;
+
+        b_info->num_llc_colors = 0;
+        for (i = 0; i < num_llc_colors; i++) {
+            uint32_t start = 0, end = 0, k;
+
+            buf = xlu_cfg_get_listitem(llc_colors, i);
+            if (!buf) {
+                fprintf(stderr,
+                        "xl: Can't get element %d in LLC color list\n", i);
+                exit(1);
+            }
+
+            if (sscanf(buf, "%" SCNu32 "-%" SCNu32, &start, &end) != 2) {
+                if (sscanf(buf, "%" SCNu32, &start) != 1) {
+                    fprintf(stderr, "xl: Invalid LLC color range: %s\n", buf);
+                    exit(1);
+                }
+                end = start;
+            } else if (start > end) {
+                fprintf(stderr,
+                        "xl: Start LLC color is greater than end: %s\n", buf);
+                exit(1);
+            }
+
+            b_info->num_llc_colors += (end - start) + 1;
+            b_info->llc_colors = (uint32_t *)realloc(b_info->llc_colors,
+                        sizeof(*b_info->llc_colors) * b_info->num_llc_colors);
+
+            for (k = start; k <= end; k++)
+                b_info->llc_colors[cur_index++] = k;
+        }
+    }
+
     if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
         vcpus = l;
         if (libxl_cpu_bitmap_alloc(ctx, &b_info->avail_vcpus, l)) {
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Mar 15 10:59:48 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 10:59:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693755.1082271 (Exim 4.92)
	(envelope-from )
	id 1rl5Hw-0002Id-3j; Fri, 15 Mar 2024 10:59:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693755.1082271; Fri, 15 Mar 2024 10:59:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl5Hv-0002Gu-QB; Fri, 15 Mar 2024 10:59:47 +0000
Received: by outflank-mailman (input) for mailman id 693755;
 Fri, 15 Mar 2024 10:59:46 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rl5Ht-0000aQ-Vm
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 10:59:45 +0000
Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com
 [2a00:1450:4864:20::231])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 21f5cafa-e2bb-11ee-afdd-a90da7624cb6;
 Fri, 15 Mar 2024 11:59:45 +0100 (CET)
Received: by mail-lj1-x231.google.com with SMTP id
 38308e7fff4ca-2d220e39907so27823621fa.1
 for ; Fri, 15 Mar 2024 03:59:45 -0700 (PDT)
Received: from carlo-ubuntu.mo54.unimo.it (nonato.mo54.unimo.it.
 [155.185.85.8]) by smtp.gmail.com with ESMTPSA id
 en6-20020a17090728c600b00a465a012cf1sm1621493ejc.18.2024.03.15.03.59.43
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 15 Mar 2024 03:59:43 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 21f5cafa-e2bb-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1710500384; x=1711105184; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=f3nbEfmEpx8CguNEN8gEFkVE6z/NmIxHeRdycAh23yc=;
        b=ZtMcNOCFFwJ8HlksF+89ZN0t0QLikziO/Cmo4BcX/hJJCOrR9e+EMos2SIbGIZYWzL
         aT6/Skj4FYr/UvXprdnr//Iqifle1firf3XP/sj5mUcRqLxzXOuswSKVSDZDMfEGbTR3
         RbpGHFs/DN4rJw/z88/rOHvq6tTcKgd7hsrfa9XoYr2Ejot93ZcdDjKafEGIPlxyw7ry
         nUUb4M/NXgPNaZ6FNgWfS2XJtrk4Nbhkx+KirM9WoTK312FIgeBq/WcuhsprXuVxJfu6
         fLE2GBOgcdpYpkDY4hgo8Zw3yU8V218yOw5dDB8/Ixyjrp23Fmsn14T8rXndocbz0+JO
         ELUg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710500384; x=1711105184;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=f3nbEfmEpx8CguNEN8gEFkVE6z/NmIxHeRdycAh23yc=;
        b=GaNq+dZTyx3EmLFv2G2fPWlrzONh5pEndjKJ6ky/543ihOD4k6ANcy0mtb02pv0QDq
         KynF/Yf/40s7GMwhsXsoHT+1iXSh8fUXn9xVmzaDa40CBpRkZva4ok4By/dky8E5o3pT
         1mcW4yoYA7UHQeMEo3qbb0133aJtkXdPQ79hT6RCZfVQ6Jp+b2fGwhg2WgG540SNhsYr
         V2R2lftexieoW0MoINWeqxlatRvmBgTxrS5q1OqJ2FH8bnHHqzbx+4rvNYUZTumHGUcv
         +5t9nZitlY+gEfAXWT30cCeMwXDfcgQwAw1JBY2t2HauTCZEft0bqPedCmshAkBzNTOh
         sOzg==
X-Gm-Message-State: AOJu0Ywo/kpA0GknYPXrxva+JVInNQfYEWI5dNEoGu6nkLEoxQMpS0dj
	DXIPqsw4y279+KpMFNRsADEGg3qB8dLaqB60Rw4RkIPtp+UNAGQbW7bThMXittsNnaXjq7Fdjdf
	w+O0=
X-Google-Smtp-Source: AGHT+IGvjMI4CSCy4Kj7MlnFpSDPyGLnerqnAE6xHvfjJ/mwehU28p8DGGTKt7kXixv/CY7kxpohUw==
X-Received: by 2002:a05:651c:10c9:b0:2d2:2ce1:1196 with SMTP id l9-20020a05651c10c900b002d22ce11196mr2946605ljn.53.1710500384097;
        Fri, 15 Mar 2024 03:59:44 -0700 (PDT)
From: Carlo Nonato 
To: xen-devel@lists.xenproject.org
Cc: Carlo Nonato ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini ,
	Wei Liu 
Subject: [PATCH v7 08/14] xen/page_alloc: introduce preserved page flags macro
Date: Fri, 15 Mar 2024 11:58:56 +0100
Message-Id: <20240315105902.160047-9-carlo.nonato@minervasys.tech>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
References: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

PGC_static and PGC_extra needs to be preserved when assigning a page.
Define a new macro that groups those flags and use it instead of or'ing
every time.

To make preserved flags even more meaningful, they are kept also when
switching state in mark_page_free().

Signed-off-by: Carlo Nonato 
---
v7:
- PGC_preserved used also in mark_page_free()
v6:
- preserved_flags renamed to PGC_preserved
- PGC_preserved is used only in assign_pages()
v5:
- new patch
---
 xen/common/page_alloc.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index c38edb9a58..6a98d9013f 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -158,6 +158,8 @@
 #define PGC_static 0
 #endif
 
+#define PGC_preserved (PGC_extra | PGC_static)
+
 #ifndef PGT_TYPE_INFO_INITIALIZER
 #define PGT_TYPE_INFO_INITIALIZER 0
 #endif
@@ -1424,11 +1426,11 @@ static bool mark_page_free(struct page_info *pg, mfn_t mfn)
     {
     case PGC_state_inuse:
         BUG_ON(pg->count_info & PGC_broken);
-        pg->count_info = PGC_state_free;
+        pg->count_info = PGC_state_free | (pg->count_info & PGC_preserved);
         break;
 
     case PGC_state_offlining:
-        pg->count_info = (pg->count_info & PGC_broken) |
+        pg->count_info = (pg->count_info & (PGC_broken | PGC_preserved)) |
                          PGC_state_offlined;
         pg_offlined = true;
         break;
@@ -2363,7 +2365,7 @@ int assign_pages(
 
         for ( i = 0; i < nr; i++ )
         {
-            ASSERT(!(pg[i].count_info & ~(PGC_extra | PGC_static)));
+            ASSERT(!(pg[i].count_info & ~PGC_preserved));
             if ( pg[i].count_info & PGC_extra )
                 extra_pages++;
         }
@@ -2423,7 +2425,7 @@ int assign_pages(
         page_set_owner(&pg[i], d);
         smp_wmb(); /* Domain pointer must be visible before updating refcnt. */
         pg[i].count_info =
-            (pg[i].count_info & (PGC_extra | PGC_static)) | PGC_allocated | 1;
+            (pg[i].count_info & PGC_preserved) | PGC_allocated | 1;
 
         page_list_add_tail(&pg[i], page_to_list(d, &pg[i]));
     }
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Mar 15 10:59:49 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 10:59:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693756.1082280 (Exim 4.92)
	(envelope-from )
	id 1rl5Hx-0002Zj-2C; Fri, 15 Mar 2024 10:59:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693756.1082280; Fri, 15 Mar 2024 10:59:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl5Hw-0002W1-J7; Fri, 15 Mar 2024 10:59:48 +0000
Received: by outflank-mailman (input) for mailman id 693756;
 Fri, 15 Mar 2024 10:59:47 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rl5Hu-0000aQ-W2
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 10:59:47 +0000
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com
 [2a00:1450:4864:20::136])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 22750349-e2bb-11ee-afdd-a90da7624cb6;
 Fri, 15 Mar 2024 11:59:46 +0100 (CET)
Received: by mail-lf1-x136.google.com with SMTP id
 2adb3069b0e04-512f892500cso2178590e87.3
 for ; Fri, 15 Mar 2024 03:59:46 -0700 (PDT)
Received: from carlo-ubuntu.mo54.unimo.it (nonato.mo54.unimo.it.
 [155.185.85.8]) by smtp.gmail.com with ESMTPSA id
 en6-20020a17090728c600b00a465a012cf1sm1621493ejc.18.2024.03.15.03.59.44
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 15 Mar 2024 03:59:44 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 22750349-e2bb-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1710500385; x=1711105185; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=mYc2fjm39MgqSAD7cglykxE3vKSQ8RsibFkKXHp3q6E=;
        b=O0rmustzajsoCV/424Og3NT9yw7pkVsqCzJSgcVIQ7M4qMN1vRke/fa3zY0OcQ1Bz5
         cl3DZhhrS8tXMVAVjEU/x8QUHIXS55DhtsJPmqPbbUL6+8N9dqxr7Ut3k++bEC8Oks4F
         Ktwkpnrjpyzbs3LKAModiTN8ymaJ00ftl7MMrGaAcJ9UbkA8CqdAHs3xhcNCBNbvLc+A
         tRa2XLOxy2mcpvL9HGa0YnXSV8mz1i4jE5VE0DcFScmUhxgRgDbIB2SI7jsjXDgssgDE
         b3rwg9V02ZBzYTY81g6LV0wdNRorH4jWBY7FrvCqXMdMMVg4C8c4M0v4jZzdgtPZcdEg
         W/bw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710500385; x=1711105185;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=mYc2fjm39MgqSAD7cglykxE3vKSQ8RsibFkKXHp3q6E=;
        b=HNsobFylwUc0DoW21SEk/1YVcOghNL1i4eKUPPzJdGhYbPIpk9Ay3aOD5nXAYu9WWr
         Ypeyd25ukqdNB6Hz/NW4WQoxK5xoaN5rHbiC70OwMaBWCPYkrkC6Sxehs56I085TERlV
         GuY7c7GnH8ZHKL9t+92jIJcdb7Tfd9hMvhgOfsBi3IYgeMilMcoFjOE3nlyIbIOKtSmc
         bvGVcPlguNLT6rPPStawta5QLBAhJKSeWZ8G8+GpObVTAFmF8wVA7F/8payYbhleF67w
         iGQqRY4a6a1CJJ4yVP2CDv/sW84fRhg73tzZmdg7EdLe75XOzPcLMExzGxjsWGDcO4Me
         8CPA==
X-Gm-Message-State: AOJu0Yx+0wfIXdWFzcy3Z7TdyNsb/DSbkpgYGt5rs7nqGhu2s3nIAbcK
	aixH+J1tBwH0DZBO8/S4pgHXxMbJa1s9dY/D7FSSTvknw8hUbpNMk9l6UpZo4+YQlEB4vyAYS9p
	VZl8=
X-Google-Smtp-Source: AGHT+IEQP+6WDfiheoSz5yXjt+PCwXQ2A8A+Q0SD4r64xEVv8nX/DG7p5uhgn0dD+s4xfjmMgOhj/g==
X-Received: by 2002:a19:5f5a:0:b0:513:cff2:967f with SMTP id a26-20020a195f5a000000b00513cff2967fmr2230732lfj.18.1710500385215;
        Fri, 15 Mar 2024 03:59:45 -0700 (PDT)
From: Carlo Nonato 
To: xen-devel@lists.xenproject.org
Cc: Carlo Nonato ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini ,
	Wei Liu 
Subject: [PATCH v7 09/14] xen/page_alloc: introduce page flag to stop buddy merging
Date: Fri, 15 Mar 2024 11:58:57 +0100
Message-Id: <20240315105902.160047-10-carlo.nonato@minervasys.tech>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
References: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Add a new PGC_no_buddy_merge flag that prevents the buddy algorithm in
free_heap_pages() from merging pages that have it set. As of now, only
PGC_static has this feature, but future work can extend it easier than
before.

Signed-off-by: Carlo Nonato 
---
v7:
- new patch
---
 xen/common/page_alloc.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 6a98d9013f..3adea713b7 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -159,6 +159,7 @@
 #endif
 
 #define PGC_preserved (PGC_extra | PGC_static)
+#define PGC_no_buddy_merge PGC_static
 
 #ifndef PGT_TYPE_INFO_INITIALIZER
 #define PGT_TYPE_INFO_INITIALIZER 0
@@ -1504,7 +1505,7 @@ static void free_heap_pages(
             /* Merge with predecessor block? */
             if ( !mfn_valid(page_to_mfn(predecessor)) ||
                  !page_state_is(predecessor, free) ||
-                 (predecessor->count_info & PGC_static) ||
+                 (predecessor->count_info & PGC_no_buddy_merge) ||
                  (PFN_ORDER(predecessor) != order) ||
                  (page_to_nid(predecessor) != node) )
                 break;
@@ -1528,7 +1529,7 @@ static void free_heap_pages(
             /* Merge with successor block? */
             if ( !mfn_valid(page_to_mfn(successor)) ||
                  !page_state_is(successor, free) ||
-                 (successor->count_info & PGC_static) ||
+                 (successor->count_info & PGC_no_buddy_merge) ||
                  (PFN_ORDER(successor) != order) ||
                  (page_to_nid(successor) != node) )
                 break;
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Mar 15 10:59:51 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 10:59:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693757.1082299 (Exim 4.92)
	(envelope-from )
	id 1rl5Hz-0003BQ-7J; Fri, 15 Mar 2024 10:59:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693757.1082299; Fri, 15 Mar 2024 10:59:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl5Hy-0003AR-Tx; Fri, 15 Mar 2024 10:59:50 +0000
Received: by outflank-mailman (input) for mailman id 693757;
 Fri, 15 Mar 2024 10:59:48 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rl5Hw-0000aQ-I2
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 10:59:48 +0000
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com
 [2a00:1450:4864:20::631])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 23a6928c-e2bb-11ee-afdd-a90da7624cb6;
 Fri, 15 Mar 2024 11:59:48 +0100 (CET)
Received: by mail-ej1-x631.google.com with SMTP id
 a640c23a62f3a-a3fb8b0b7acso204437266b.2
 for ; Fri, 15 Mar 2024 03:59:48 -0700 (PDT)
Received: from carlo-ubuntu.mo54.unimo.it (nonato.mo54.unimo.it.
 [155.185.85.8]) by smtp.gmail.com with ESMTPSA id
 en6-20020a17090728c600b00a465a012cf1sm1621493ejc.18.2024.03.15.03.59.46
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 15 Mar 2024 03:59:46 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 23a6928c-e2bb-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1710500387; x=1711105187; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=F0DrmZJci78FoZxvC5v5mCbOhkfLgAdNFnybJw+ptbQ=;
        b=utN+/1vMcr6pXa5n9fcfpyIDbGxLJiwjZSY08OBJx+y2GCgwydh0/AjmfT+OvWKvXw
         brYIRTw+GXIFv2wmrGJEjYONGVc7IYh6zUNjViBMQd9AnlNeidUsb68gveclQwtNJP0/
         t1KDNcpRYieaolBqTHK6DOK6DGW1J2MXgEmKzmN/pFNpNq7sBR6tcde3soNuHGdSveEX
         jklbTa7ymHYKAsQBr8Gri0YmmsljVd6tZbdLol72k8q+vg/oQDwRQzFNiGcu0Jha3O84
         pgMPiYrCWK0KQdjqiY7WwZM778sBp50Kgkme3Ej5pj5s9h1xVQ35OqmcBhBznOtOe4GY
         KAsQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710500387; x=1711105187;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=F0DrmZJci78FoZxvC5v5mCbOhkfLgAdNFnybJw+ptbQ=;
        b=T2tVnWFcWCJbAXMvVj7ijsRhj/SJ7XlW8Jno7k7mlhPvOYc5tnyD3DKLLH97IbC6vw
         ctNX6XiU+AAswEOzKin3nPvdbaPo+4oitHaj3d1amau8GzZmvrb5w0UAi70qU1Zg2smd
         Y4LgmQsimmxmUW2l67SwfXJP7XhuqXl1wk4u4pZbZ5X/nlCcyzcgJvm7wMkBzWV2o/l7
         s4fCgo8cmIKcaLqa75hC3En6jcvxcbxCUxXrCGCTKUsteCPo3HIXPLkUW2aaXUedNAUI
         y+XeghXD3M8zNJcwppsImRkKbMLkSNZv+1ZVa1/OP3cQOGx3ksLHH+r1gShUM4W7kYV1
         yrXQ==
X-Gm-Message-State: AOJu0Ywdi6iS3M48vh2EyVdOIMT1c9Uur07qCKhrPXZUEkWI+fq51wtq
	fSlKPsJoXm9XgVaxBCWt7k4oNaa7jovXKHLPjMPzdDJq7c4yYByewpeinjBrtU7cWmLuvPpp+kN
	90cQ=
X-Google-Smtp-Source: AGHT+IEKt/6Ps0/3taD+3fbNYM0uMQ7bRVuTic9mtyQZB35bEGeJxY/vGwpfgAqcjAN8ctp88Bcwaw==
X-Received: by 2002:a17:906:1707:b0:a46:708d:a9d3 with SMTP id c7-20020a170906170700b00a46708da9d3mr2423303eje.71.1710500387182;
        Fri, 15 Mar 2024 03:59:47 -0700 (PDT)
From: Carlo Nonato 
To: xen-devel@lists.xenproject.org
Cc: Carlo Nonato ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk 
Subject: [PATCH v7 11/14] xen/arm: use domain memory to allocate p2m page tables
Date: Fri, 15 Mar 2024 11:58:59 +0100
Message-Id: <20240315105902.160047-12-carlo.nonato@minervasys.tech>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
References: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Cache colored domains can benefit from having p2m page tables allocated
with the same coloring schema so that isolation can be achieved also for
those kind of memory accesses.
In order to do that, the domain struct is passed to the allocator and the
MEMF_no_owner flag is used.

This will be useful also when NUMA will be supported on Arm.

Signed-off-by: Carlo Nonato 
Acked-by: Julien Grall 
---
v7:
- no changes
v6:
- Carlo Nonato as the only signed-off-by
v5:
- new patch
---
 xen/arch/arm/mmu/p2m.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/mmu/p2m.c b/xen/arch/arm/mmu/p2m.c
index 41fcca011c..d02a478cb8 100644
--- a/xen/arch/arm/mmu/p2m.c
+++ b/xen/arch/arm/mmu/p2m.c
@@ -32,7 +32,7 @@ static struct page_info *p2m_alloc_page(struct domain *d)
      */
     if ( is_hardware_domain(d) )
     {
-        pg = alloc_domheap_page(NULL, 0);
+        pg = alloc_domheap_page(d, MEMF_no_owner);
         if ( pg == NULL )
             printk(XENLOG_G_ERR "Failed to allocate P2M pages for hwdom.\n");
     }
@@ -81,7 +81,7 @@ int p2m_set_allocation(struct domain *d, unsigned long pages, bool *preempted)
         if ( d->arch.paging.p2m_total_pages < pages )
         {
             /* Need to allocate more memory from domheap */
-            pg = alloc_domheap_page(NULL, 0);
+            pg = alloc_domheap_page(d, MEMF_no_owner);
             if ( pg == NULL )
             {
                 printk(XENLOG_ERR "Failed to allocate P2M pages.\n");
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Mar 15 10:59:52 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 10:59:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693758.1082305 (Exim 4.92)
	(envelope-from )
	id 1rl5Hz-0003IT-Sk; Fri, 15 Mar 2024 10:59:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693758.1082305; Fri, 15 Mar 2024 10:59:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl5Hz-0003G8-EN; Fri, 15 Mar 2024 10:59:51 +0000
Received: by outflank-mailman (input) for mailman id 693758;
 Fri, 15 Mar 2024 10:59:49 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rl5Hx-0000xG-9S
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 10:59:49 +0000
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com
 [2a00:1450:4864:20::62e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 23174c63-e2bb-11ee-a1ee-f123f15fe8a2;
 Fri, 15 Mar 2024 11:59:47 +0100 (CET)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-a461c50deccso236192466b.0
 for ; Fri, 15 Mar 2024 03:59:47 -0700 (PDT)
Received: from carlo-ubuntu.mo54.unimo.it (nonato.mo54.unimo.it.
 [155.185.85.8]) by smtp.gmail.com with ESMTPSA id
 en6-20020a17090728c600b00a465a012cf1sm1621493ejc.18.2024.03.15.03.59.45
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 15 Mar 2024 03:59:45 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 23174c63-e2bb-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1710500386; x=1711105186; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=6e/8REgmA1CaltErR3Yy22Lv/iZKWXNjZ4COUyKK6y8=;
        b=Q+M5Yn4t4anmrRPrzcE06zvGsXQC9sJQpXFs93Z5Y/LNMjxYRoeu29Cs9DMYj94DxW
         E88arqFPQZud8+7stXQLsS4QoDoAWM6t5u9LxmOny/8M0Akjz8P6K01B8JU6gpDTycPo
         SwvQ2B5hyJgWG6l0tgfJDEB2EOJz7oOFZKDGEYQ4OiZYAxz3fN5s5frE/0oIm0QhcGhG
         rzzbHEGZ7d3//9iCGkitIc8XgXq3bjlxA6ezaD4ymcT5D4RgsOzO7h5j8qFhfo4BTvzc
         xYNRzwO4KuMaA/QSFqWFSYiPpwmKCyy5tIMyTzPMircZQszCO+DWmhp7k+Eqzwdz5zMU
         5WCQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710500386; x=1711105186;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=6e/8REgmA1CaltErR3Yy22Lv/iZKWXNjZ4COUyKK6y8=;
        b=kQRMDJbuqia7HSR9ES/5a2Zmfi4o4dAciO6+l0RhotQuBrCk4AN4lGKYZ177dBfZcW
         /vtMo698GwOSk8YOTPC1SMKcYOL0BwTphO0A1VPkWqrEZXvSksMxIh6IC33c3ZoWk879
         5u/WIBWDszlDmOt/3GAkzwODEXvtptf2ahioKhPwFMrp/yeCTGaAGmtMkfzcdbwxVIQy
         prQLqOf05eDrkWeRgSG4u2tHgYgYZLncxDQIrUy+SVnNxvjM/C4RImZLlpbCXz7PNrKe
         hfSLaJWHUvVnTq3WhDCfOO/RNXuRykfbIxLCs8YNtLh8Bepd/Gem3IQuQcxVirs7Zi6h
         G0QA==
X-Gm-Message-State: AOJu0Yx6HJ4z4SMQ8owueqSDREB1LaPckax6BS71Ev/x9dCiRpNyyXnZ
	3jPB1oaniz/vO3uCTmg9kCK7Zpcqk80VEsLF286LLzNhtvL2NkuxaXMFLDQrHOoOa562gmK9TGL
	KJtQ=
X-Google-Smtp-Source: AGHT+IHNzfiThoyRxNOWL9E4ToDDMCqWOWCkNIl1LK4kAHq6ROtd4vu7SHwZ64QUM+cuWQZSF2nn9Q==
X-Received: by 2002:a17:906:4691:b0:a3e:b263:d769 with SMTP id a17-20020a170906469100b00a3eb263d769mr3011367ejr.4.1710500386072;
        Fri, 15 Mar 2024 03:59:46 -0700 (PDT)
From: Carlo Nonato 
To: xen-devel@lists.xenproject.org
Cc: Carlo Nonato ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini ,
	Wei Liu ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Marco Solieri 
Subject: [PATCH v7 10/14] xen: add cache coloring allocator for domains
Date: Fri, 15 Mar 2024 11:58:58 +0100
Message-Id: <20240315105902.160047-11-carlo.nonato@minervasys.tech>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
References: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Add a new memory page allocator that implements the cache coloring mechanism.
The allocation algorithm enforces equal frequency distribution of cache
partitions, following the coloring configuration of a domain. This allows
for an even utilization of cache sets for every domain.

Pages are stored in a color-indexed array of lists. Those lists are filled
by a simple init function which computes the color of each page.
When a domain requests a page, the allocator extract the page from the list
with the maximum number of free pages between those that the domain can
access, given its coloring configuration.

The allocator can only handle requests of order-0 pages. This allows for
easier implementation and since cache coloring targets only embedded systems,
it's assumed not to be a major problem.

The buddy allocator must coexist with the colored one because the Xen heap
isn't colored. For this reason a new Kconfig option and a command line
parameter are added to let the user set the amount of memory reserved for
the buddy allocator. Even when cache coloring is enabled, this memory
isn't managed by the colored allocator.

Colored heap information is dumped in the dump_heap() debug-key function.

Based on original work from: Luca Miccio 

Signed-off-by: Marco Solieri 
Signed-off-by: Carlo Nonato 
---
v7:
- requests to alloc_color_heap_page() now fail if MEMF_bits is used
v6:
- colored allocator functions are now static
v5:
- Carlo Nonato as the new author
- the colored allocator balances color usage for each domain and it searches
  linearly only in the number of colors (FIXME removed)
- addedd scrub functionality
- removed stub functions (still requires some macro definition)
- addr_to_color turned to mfn_to_color for easier operations
- removed BUG_ON in init_color_heap_pages() in favor of panic()
- only non empty page lists are logged in dump_color_heap()
v4:
- moved colored allocator code after buddy allocator because it now has
  some dependencies on buddy functions
- buddy_alloc_size is now used only by the colored allocator
- fixed a bug that allowed the buddy to merge pages when they were colored
- free_color_heap_page() now calls mark_page_free()
- free_color_heap_page() uses of the frametable array for faster searches
- added FIXME comment for the linear search in free_color_heap_page()
- removed alloc_color_domheap_page() to let the colored allocator exploit
  some more buddy allocator code
- alloc_color_heap_page() now allocs min address pages first
- reduced the mess in end_boot_allocator(): use the first loop for
  init_color_heap_pages()
- fixed page_list_add_prev() (list.h) since it was doing the opposite of
  what it was supposed to do
- fixed page_list_add_prev() (non list.h) to check also for next existence
- removed unused page_list_add_next()
- moved p2m code in another patch
---
 docs/misc/cache-coloring.rst      |  37 ++++++
 docs/misc/xen-command-line.pandoc |  14 +++
 xen/arch/Kconfig                  |   8 ++
 xen/arch/arm/include/asm/mm.h     |   5 +
 xen/common/llc-coloring.c         |  13 ++
 xen/common/page_alloc.c           | 196 +++++++++++++++++++++++++++++-
 xen/include/xen/llc-coloring.h    |   4 +
 7 files changed, 271 insertions(+), 6 deletions(-)

diff --git a/docs/misc/cache-coloring.rst b/docs/misc/cache-coloring.rst
index 028aecda28..50b6d94ffc 100644
--- a/docs/misc/cache-coloring.rst
+++ b/docs/misc/cache-coloring.rst
@@ -11,6 +11,9 @@ To compile LLC coloring support set ``CONFIG_LLC_COLORING=y``.
 If needed, change the maximum number of colors with
 ``CONFIG_NR_LLC_COLORS=``.
 
+If needed, change the buddy allocator reserved size with
+``CONFIG_BUDDY_ALLOCATOR_SIZE=``.
+
 Runtime configuration is done via `Command line parameters`_.
 For DomUs follow `DomUs configuration`_.
 
@@ -117,6 +120,8 @@ Specific documentation is available at `docs/misc/xen-command-line.pandoc`.
 +----------------------+-------------------------------+
 | ``dom0-llc-colors``  | Dom0 color configuration      |
 +----------------------+-------------------------------+
+| ``buddy-alloc-size`` | Buddy allocator reserved size |
++----------------------+-------------------------------+
 
 Colors selection format
 ***********************
@@ -204,6 +209,17 @@ the ``llc-colors`` option. For example:
 **Note:** If no color configuration is provided for a domain, the default one,
 which corresponds to all available colors is used instead.
 
+Colored allocator and buddy allocator
+*************************************
+
+The colored allocator distributes pages based on color configurations of
+domains so that each domains only gets pages of its own colors.
+The colored allocator is meant as an alternative to the buddy allocator because
+its allocation policy is by definition incompatible with the generic one. Since
+the Xen heap is not colored yet, we need to support the coexistence of the two
+allocators and some memory must be left for the buddy one. Buddy memory
+reservation is configured via Kconfig or via command-line.
+
 Known issues and limitations
 ****************************
 
@@ -214,3 +230,24 @@ In the domain configuration, "xen,static-mem" allows memory to be statically
 allocated to the domain. This isn't possible when LLC coloring is enabled,
 because that memory can't be guaranteed to use only colors assigned to the
 domain.
+
+Cache coloring is intended only for embedded systems
+####################################################
+
+The current implementation aims to satisfy the need of predictability in
+embedded systems with small amount of memory to be managed in a colored way.
+Given that, some shortcuts are taken in the development. Expect worse
+performances on larger systems.
+
+Colored allocator can only make use of order-0 pages
+####################################################
+
+The cache coloring technique relies on memory mappings and on the smallest
+mapping granularity to achieve the maximum number of colors (cache partitions)
+possible. This granularity is what is normally called a page and, in Xen
+terminology, the order-0 page is the smallest one. The fairly simple
+colored allocator currently implemented, makes use only of such pages.
+It must be said that a more complex one could, in theory, adopt higher order
+pages if the colors selection contained adjacent colors. Two subsequent colors,
+for example, can be represented by an order-1 page, four colors correspond to
+an order-2 page, etc.
diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
index 28035a214d..461403362f 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -270,6 +270,20 @@ and not running softirqs. Reduce this if softirqs are not being run frequently
 enough. Setting this to a high value may cause boot failure, particularly if
 the NMI watchdog is also enabled.
 
+### buddy-alloc-size (arm64)
+> `= `
+
+> Default: `64M`
+
+Amount of memory reserved for the buddy allocator when colored allocator is
+active. This options is parsed only when LLC coloring support is enabled.
+The colored allocator is meant as an alternative to the buddy allocator,
+because its allocation policy is by definition incompatible with the generic
+one. Since the Xen heap systems is not colored yet, we need to support the
+coexistence of the two allocators for now. This parameter, which is optional
+and for expert only, it's used to set the amount of memory reserved to the
+buddy allocator.
+
 ### cet
     = List of [ shstk=, ibt= ]
 
diff --git a/xen/arch/Kconfig b/xen/arch/Kconfig
index a65c38e53e..6819a96f78 100644
--- a/xen/arch/Kconfig
+++ b/xen/arch/Kconfig
@@ -51,3 +51,11 @@ config NR_LLC_COLORS
 	  more than what's needed in the general case. Use only power of 2 values.
 	  1024 is the number of colors that fit in a 4 KiB page when integers are 4
 	  bytes long.
+
+config BUDDY_ALLOCATOR_SIZE
+	int "Buddy allocator reserved memory size (MiB)"
+	default "64"
+	depends on LLC_COLORING
+	help
+	  Amount of memory reserved for the buddy allocator to serve Xen heap,
+	  working alongside the colored one.
diff --git a/xen/arch/arm/include/asm/mm.h b/xen/arch/arm/include/asm/mm.h
index 48538b5337..68b7754bec 100644
--- a/xen/arch/arm/include/asm/mm.h
+++ b/xen/arch/arm/include/asm/mm.h
@@ -145,6 +145,11 @@ struct page_info
 #else
 #define PGC_static     0
 #endif
+#ifdef CONFIG_LLC_COLORING
+/* Page is cache colored */
+#define _PGC_colored      PG_shift(4)
+#define PGC_colored       PG_mask(1, 4)
+#endif
 /* ... */
 /* Page is broken? */
 #define _PGC_broken       PG_shift(7)
diff --git a/xen/common/llc-coloring.c b/xen/common/llc-coloring.c
index 77d24553e0..e34ba6b6ec 100644
--- a/xen/common/llc-coloring.c
+++ b/xen/common/llc-coloring.c
@@ -22,6 +22,9 @@ static unsigned int __ro_after_init max_nr_colors;
 static unsigned int __initdata dom0_colors[CONFIG_NR_LLC_COLORS];
 static unsigned int __initdata dom0_num_colors;
 
+#define mfn_color_mask              (max_nr_colors - 1)
+#define mfn_to_color(mfn)           (mfn_x(mfn) & mfn_color_mask)
+
 /*
  * Parse the coloring configuration given in the buf string, following the
  * syntax below.
@@ -284,6 +287,16 @@ int __init domain_set_llc_colors_from_str(struct domain *d, const char *str)
     return 0;
 }
 
+unsigned int page_to_llc_color(const struct page_info *pg)
+{
+    return mfn_to_color(page_to_mfn(pg));
+}
+
+unsigned int get_max_nr_llc_colors(void)
+{
+    return max_nr_colors;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 3adea713b7..8aab18d1fe 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -158,8 +158,12 @@
 #define PGC_static 0
 #endif
 
-#define PGC_preserved (PGC_extra | PGC_static)
-#define PGC_no_buddy_merge PGC_static
+#ifndef PGC_colored
+#define PGC_colored 0
+#endif
+
+#define PGC_preserved (PGC_extra | PGC_static | PGC_colored)
+#define PGC_no_buddy_merge (PGC_static | PGC_colored)
 
 #ifndef PGT_TYPE_INFO_INITIALIZER
 #define PGT_TYPE_INFO_INITIALIZER 0
@@ -1945,6 +1949,164 @@ static unsigned long avail_heap_pages(
     return free_pages;
 }
 
+/*************************
+ * COLORED SIDE-ALLOCATOR
+ *
+ * Pages are grouped by LLC color in lists which are globally referred to as the
+ * color heap. Lists are populated in end_boot_allocator().
+ * After initialization there will be N lists where N is the number of
+ * available colors on the platform.
+ */
+static struct page_list_head *__ro_after_init _color_heap;
+#define color_heap(color) (&_color_heap[color])
+
+static unsigned long *__ro_after_init free_colored_pages;
+
+/* Memory required for buddy allocator to work with colored one */
+#ifdef CONFIG_LLC_COLORING
+static unsigned long __initdata buddy_alloc_size =
+    MB(CONFIG_BUDDY_ALLOCATOR_SIZE);
+size_param("buddy-alloc-size", buddy_alloc_size);
+
+#define domain_num_llc_colors(d) (d)->num_llc_colors
+#define domain_llc_color(d, i)   (d)->llc_colors[i]
+#else
+static unsigned long __initdata buddy_alloc_size;
+
+#define domain_num_llc_colors(d) 0
+#define domain_llc_color(d, i)   0
+#endif
+
+static void free_color_heap_page(struct page_info *pg, bool need_scrub)
+{
+    unsigned int color = page_to_llc_color(pg);
+    struct page_list_head *head = color_heap(color);
+
+    spin_lock(&heap_lock);
+
+    mark_page_free(pg, page_to_mfn(pg));
+
+    if ( need_scrub )
+    {
+        pg->count_info |= PGC_need_scrub;
+        poison_one_page(pg);
+    }
+
+    free_colored_pages[color]++;
+    page_list_add(pg, head);
+
+    spin_unlock(&heap_lock);
+}
+
+static struct page_info *alloc_color_heap_page(unsigned int memflags,
+                                               const struct domain *d)
+{
+    struct page_info *pg = NULL;
+    unsigned int i, color = 0;
+    unsigned long max = 0;
+    bool need_tlbflush = false;
+    uint32_t tlbflush_timestamp = 0;
+    bool need_scrub;
+
+    if ( memflags >> _MEMF_bits )
+        return NULL;
+
+    spin_lock(&heap_lock);
+
+    for ( i = 0; i < domain_num_llc_colors(d); i++ )
+    {
+        unsigned long free = free_colored_pages[domain_llc_color(d, i)];
+
+        if ( free > max )
+        {
+            color = domain_llc_color(d, i);
+            pg = page_list_first(color_heap(color));
+            max = free;
+        }
+    }
+
+    if ( !pg )
+    {
+        spin_unlock(&heap_lock);
+        return NULL;
+    }
+
+    need_scrub = pg->count_info & (PGC_need_scrub);
+    pg->count_info = PGC_state_inuse | (pg->count_info & PGC_colored);
+    free_colored_pages[color]--;
+    page_list_del(pg, color_heap(color));
+
+    if ( !(memflags & MEMF_no_tlbflush) )
+        accumulate_tlbflush(&need_tlbflush, pg, &tlbflush_timestamp);
+
+    init_free_page_fields(pg);
+
+    spin_unlock(&heap_lock);
+
+    if ( !(memflags & MEMF_no_scrub) )
+    {
+        if ( need_scrub )
+            scrub_one_page(pg);
+        else
+            check_one_page(pg);
+    }
+
+    if ( need_tlbflush )
+        filtered_flush_tlb_mask(tlbflush_timestamp);
+
+    flush_page_to_ram(mfn_x(page_to_mfn(pg)),
+                      !(memflags & MEMF_no_icache_flush));
+
+    return pg;
+}
+
+static void __init init_color_heap_pages(struct page_info *pg,
+                                         unsigned long nr_pages)
+{
+    unsigned int i;
+    bool need_scrub = opt_bootscrub == BOOTSCRUB_IDLE;
+
+    if ( buddy_alloc_size )
+    {
+        unsigned long buddy_pages = min(PFN_DOWN(buddy_alloc_size), nr_pages);
+
+        init_heap_pages(pg, buddy_pages);
+        nr_pages -= buddy_pages;
+        buddy_alloc_size -= buddy_pages << PAGE_SHIFT;
+        pg += buddy_pages;
+    }
+
+    if ( !_color_heap )
+    {
+        unsigned int max_nr_colors = get_max_nr_llc_colors();
+
+        _color_heap = xmalloc_array(struct page_list_head, max_nr_colors);
+        free_colored_pages = xzalloc_array(unsigned long, max_nr_colors);
+        if ( !_color_heap || !free_colored_pages )
+            panic("Can't allocate colored heap. Buddy reserved size is too low");
+
+        for ( i = 0; i < max_nr_colors; i++ )
+            INIT_PAGE_LIST_HEAD(color_heap(i));
+    }
+
+    for ( i = 0; i < nr_pages; i++ )
+    {
+        pg[i].count_info = PGC_colored;
+        free_color_heap_page(&pg[i], need_scrub);
+    }
+}
+
+static void dump_color_heap(void)
+{
+    unsigned int color;
+
+    printk("Dumping color heap info\n");
+    for ( color = 0; color < get_max_nr_llc_colors(); color++ )
+        if ( free_colored_pages[color] > 0 )
+            printk("Color heap[%u]: %lu pages\n",
+                   color, free_colored_pages[color]);
+}
+
 void __init end_boot_allocator(void)
 {
     unsigned int i;
@@ -1964,7 +2126,13 @@ void __init end_boot_allocator(void)
     for ( i = nr_bootmem_regions; i-- > 0; )
     {
         struct bootmem_region *r = &bootmem_region_list[i];
-        if ( r->s < r->e )
+
+        if ( r->s >= r->e )
+            continue;
+
+        if ( llc_coloring_enabled )
+            init_color_heap_pages(mfn_to_page(_mfn(r->s)), r->e - r->s);
+        else
             init_heap_pages(mfn_to_page(_mfn(r->s)), r->e - r->s);
     }
     nr_bootmem_regions = 0;
@@ -2460,7 +2628,14 @@ struct page_info *alloc_domheap_pages(
     if ( memflags & MEMF_no_owner )
         memflags |= MEMF_no_refcount;
 
-    if ( !dma_bitsize )
+    /* Only domains are supported for coloring */
+    if ( d && llc_coloring_enabled )
+    {
+        /* Colored allocation must be done on 0 order */
+        if ( order || (pg = alloc_color_heap_page(memflags, d)) == NULL )
+            return NULL;
+    }
+    else if ( !dma_bitsize )
         memflags &= ~MEMF_no_dma;
     else if ( (dma_zone = bits_to_zone(dma_bitsize)) < zone_hi )
         pg = alloc_heap_pages(dma_zone + 1, zone_hi, order, memflags, d);
@@ -2485,7 +2660,10 @@ struct page_info *alloc_domheap_pages(
         }
         if ( assign_page(pg, order, d, memflags) )
         {
-            free_heap_pages(pg, order, memflags & MEMF_no_scrub);
+            if ( pg->count_info & PGC_colored )
+                free_color_heap_page(pg, memflags & MEMF_no_scrub);
+            else
+                free_heap_pages(pg, order, memflags & MEMF_no_scrub);
             return NULL;
         }
     }
@@ -2568,7 +2746,10 @@ void free_domheap_pages(struct page_info *pg, unsigned int order)
             scrub = 1;
         }
 
-        free_heap_pages(pg, order, scrub);
+        if ( pg->count_info & PGC_colored )
+            free_color_heap_page(pg, scrub);
+        else
+            free_heap_pages(pg, order, scrub);
     }
 
     if ( drop_dom_ref )
@@ -2677,6 +2858,9 @@ static void cf_check dump_heap(unsigned char key)
             continue;
         printk("Node %d has %lu unscrubbed pages\n", i, node_need_scrub[i]);
     }
+
+    if ( llc_coloring_enabled )
+        dump_color_heap();
 }
 
 static __init int cf_check register_heap_trigger(void)
diff --git a/xen/include/xen/llc-coloring.h b/xen/include/xen/llc-coloring.h
index 49ebd1e712..7f8218bfb2 100644
--- a/xen/include/xen/llc-coloring.h
+++ b/xen/include/xen/llc-coloring.h
@@ -33,6 +33,10 @@ int domain_set_llc_colors(struct domain *d,
                           const struct xen_domctl_set_llc_colors *config);
 int domain_set_llc_colors_from_str(struct domain *d, const char *str);
 
+struct page_info;
+unsigned int page_to_llc_color(const struct page_info *pg);
+unsigned int get_max_nr_llc_colors(void);
+
 #endif /* __COLORING_H__ */
 
 /*
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Mar 15 10:59:53 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 10:59:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693759.1082313 (Exim 4.92)
	(envelope-from )
	id 1rl5I1-0003XB-4X; Fri, 15 Mar 2024 10:59:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693759.1082313; Fri, 15 Mar 2024 10:59:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl5I0-0003UP-Cn; Fri, 15 Mar 2024 10:59:52 +0000
Received: by outflank-mailman (input) for mailman id 693759;
 Fri, 15 Mar 2024 10:59:49 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rl5Hx-0000aQ-L9
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 10:59:49 +0000
Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com
 [2a00:1450:4864:20::132])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 244b4dc5-e2bb-11ee-afdd-a90da7624cb6;
 Fri, 15 Mar 2024 11:59:49 +0100 (CET)
Received: by mail-lf1-x132.google.com with SMTP id
 2adb3069b0e04-513ccc70a6dso3196346e87.1
 for ; Fri, 15 Mar 2024 03:59:49 -0700 (PDT)
Received: from carlo-ubuntu.mo54.unimo.it (nonato.mo54.unimo.it.
 [155.185.85.8]) by smtp.gmail.com with ESMTPSA id
 en6-20020a17090728c600b00a465a012cf1sm1621493ejc.18.2024.03.15.03.59.47
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 15 Mar 2024 03:59:47 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 244b4dc5-e2bb-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1710500388; x=1711105188; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Fy6uWZxsQOXNFgh1t1htiToV73nbyClGXslCHnFbHAI=;
        b=wnCszeK0MpHW9O9WgznMZiEFE77klpawPSJgJi8Auoj6514TVq5A84FHMu1QGOGuuM
         ll7KsRsbAjJ9bqpxl9Ayxx6mbiyNPgKMtMlF0nBKlLBwZJACsLj5mBjW4wiiztV/9pxI
         fk7dY3XUDeOgrXTOpGXrDYO1QQSWs7uH3DHdHPQQ1NzK85mkgjI0Io1bbKa+XLUD4erU
         +0TAvOj0+yrs9jgQGUJlJHVbi1kl79XH0trkdh4vhDB1pzyQA9CPWVKgE0t6n8gQRogB
         O0J+b6KvTfjmX9g+s3imX25Vcf1Iwj5t756+Wfj5XkzdvSi7rA4XVD4lLD1S5vStAl3o
         Nk3w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710500388; x=1711105188;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=Fy6uWZxsQOXNFgh1t1htiToV73nbyClGXslCHnFbHAI=;
        b=KDyZTyhwi8COeFyoKkL8yMPmkWI5I5h4VSrGfQbrrN1Qa335/DBXqNl2CHjT0zrcpE
         zqqYAGcpZ5fBX98XYn2OLIBVRSXcCd1y5hrCxsRODXryW19gI4Wcbden6rMxkKhdy9KI
         JMWgWYocNDyOJ3W9VV8LESewtjZbPsN4JQDoVLkAV1+75RMs0g6mJBrz/Leg9zFlxAOH
         bK1hQkKe72rlTDc4vO3NEVGwxclo3J5BiHo9Kqk6sH7q4ij1IAqypjMxa0PxP6FebT6/
         rtFc11kk9F+RZ7NVA1HWf0hVTR1kMYMRtu/7/sV6fsdcj1iHz4bEU6xnJr/U/0j8LNlQ
         EMXQ==
X-Gm-Message-State: AOJu0YzkWv60aGsfVxZyVdh7wOFY3MpL1uWpjWmVxeyvIg9t6JTm8rwM
	CtORcQU/01CQtns6LdcUmWME55arMCg1bPJfNo2fcyjdjSkqTjtt/aMCKJqBeZOB9LvnxiHkfTk
	NAno=
X-Google-Smtp-Source: AGHT+IH/o8X1NzxhHhmnEuPlued9ZHWVlwWB4jolG9fXN+mFALODN5no3ZFup68S8jPAIXwcjRZW2w==
X-Received: by 2002:ac2:4ed1:0:b0:513:caa7:3773 with SMTP id p17-20020ac24ed1000000b00513caa73773mr2149934lfr.63.1710500388134;
        Fri, 15 Mar 2024 03:59:48 -0700 (PDT)
From: Carlo Nonato 
To: xen-devel@lists.xenproject.org
Cc: Luca Miccio ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini ,
	Wei Liu ,
	Marco Solieri ,
	Carlo Nonato 
Subject: [PATCH v7 12/14] xen/arm: add Xen cache colors command line parameter
Date: Fri, 15 Mar 2024 11:59:00 +0100
Message-Id: <20240315105902.160047-13-carlo.nonato@minervasys.tech>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
References: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Luca Miccio 

Add a new command line parameter to configure Xen cache colors.
These colors can be dumped with the cache coloring info debug-key.

By default, Xen uses the first color.
Benchmarking the VM interrupt response time provides an estimation of
LLC usage by Xen's most latency-critical runtime task. Results on Arm
Cortex-A53 on Xilinx Zynq UltraScale+ XCZU9EG show that one color, which
reserves 64 KiB of L2, is enough to attain best responsiveness:
- Xen 1 color latency:  3.1 us
- Xen 2 color latency:  3.1 us

More colors are instead very likely to be needed on processors whose L1
cache is physically-indexed and physically-tagged, such as Cortex-A57.
In such cases, coloring applies to L1 also, and there typically are two
distinct L1-colors. Therefore, reserving only one color for Xen would
senselessly partitions a cache memory that is already private, i.e.
underutilize it. The default amount of Xen colors is thus set to one.

Signed-off-by: Luca Miccio 
Signed-off-by: Marco Solieri 
Signed-off-by: Carlo Nonato 
---
v7:
- removed XEN_DEFAULT_COLOR
- XEN_DEFAULT_NUM_COLORS is now used in a for loop to set xen default colors
---
 docs/misc/cache-coloring.rst      |  2 ++
 docs/misc/xen-command-line.pandoc | 10 ++++++++++
 xen/common/llc-coloring.c         | 29 +++++++++++++++++++++++++++++
 3 files changed, 41 insertions(+)

diff --git a/docs/misc/cache-coloring.rst b/docs/misc/cache-coloring.rst
index 50b6d94ffc..f427a14b65 100644
--- a/docs/misc/cache-coloring.rst
+++ b/docs/misc/cache-coloring.rst
@@ -122,6 +122,8 @@ Specific documentation is available at `docs/misc/xen-command-line.pandoc`.
 +----------------------+-------------------------------+
 | ``buddy-alloc-size`` | Buddy allocator reserved size |
 +----------------------+-------------------------------+
+| ``xen-llc-colors``   | Xen color configuration       |
++----------------------+-------------------------------+
 
 Colors selection format
 ***********************
diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
index 461403362f..fa18ec942e 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -2885,6 +2885,16 @@ mode.
 **WARNING: `x2apic_phys` is deprecated and superseded by `x2apic-mode`.
 The latter takes precedence if both are set.**
 
+### xen-llc-colors (arm64)
+> `= List of [  | - ]`
+
+> Default: `0: the lowermost color`
+
+Specify Xen LLC color configuration. This options is available only when
+`CONFIG_LLC_COLORING` is enabled.
+Two colors are most likely needed on platforms where private caches are
+physically indexed, e.g. the L1 instruction cache of the Arm Cortex-A57.
+
 ### xenheap_megabytes (arm32)
 > `= `
 
diff --git a/xen/common/llc-coloring.c b/xen/common/llc-coloring.c
index e34ba6b6ec..f1a7561d79 100644
--- a/xen/common/llc-coloring.c
+++ b/xen/common/llc-coloring.c
@@ -9,6 +9,8 @@
 #include 
 #include 
 
+#define XEN_DEFAULT_NUM_COLORS 1
+
 bool __ro_after_init llc_coloring_enabled;
 boolean_param("llc-coloring", llc_coloring_enabled);
 
@@ -22,6 +24,9 @@ static unsigned int __ro_after_init max_nr_colors;
 static unsigned int __initdata dom0_colors[CONFIG_NR_LLC_COLORS];
 static unsigned int __initdata dom0_num_colors;
 
+static unsigned int __ro_after_init xen_colors[CONFIG_NR_LLC_COLORS];
+static unsigned int __ro_after_init xen_num_colors;
+
 #define mfn_color_mask              (max_nr_colors - 1)
 #define mfn_to_color(mfn)           (mfn_x(mfn) & mfn_color_mask)
 
@@ -79,6 +84,13 @@ static int __init parse_dom0_colors(const char *s)
 }
 custom_param("dom0-llc-colors", parse_dom0_colors);
 
+static int __init parse_xen_colors(const char *s)
+{
+    return parse_color_config(s, xen_colors, ARRAY_SIZE(xen_colors),
+                              &xen_num_colors);
+}
+custom_param("xen-llc-colors", parse_xen_colors);
+
 static void print_colors(const unsigned int *colors, unsigned int num_colors)
 {
     unsigned int i;
@@ -147,6 +159,21 @@ void __init llc_coloring_init(void)
         panic("Number of LLC colors (%u) not in range [2, %u]\n",
               max_nr_colors, CONFIG_NR_LLC_COLORS);
 
+    if ( !xen_num_colors )
+    {
+        unsigned int i;
+
+        xen_num_colors = MIN(XEN_DEFAULT_NUM_COLORS, max_nr_colors);
+
+        printk(XENLOG_WARNING
+               "Xen LLC color config not found. Using first %u colors\n",
+               xen_num_colors);
+        for ( i = 0; i < xen_num_colors; i++ )
+            xen_colors[i] = i;
+    }
+    else if ( !check_colors(xen_colors, xen_num_colors) )
+        panic("Bad LLC color config for Xen\n");
+
     arch_llc_coloring_init();
 }
 
@@ -157,6 +184,8 @@ void cf_check dump_llc_coloring_info(void)
 
     printk("LLC coloring info:\n");
     printk("    Number of LLC colors supported: %u\n", max_nr_colors);
+    printk("    Xen LLC colors (%u): ", xen_num_colors);
+    print_colors(xen_colors, xen_num_colors);
 }
 
 void cf_check domain_dump_llc_colors(const struct domain *d)
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Mar 15 10:59:54 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 10:59:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693760.1082318 (Exim 4.92)
	(envelope-from )
	id 1rl5I2-0003qH-6I; Fri, 15 Mar 2024 10:59:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693760.1082318; Fri, 15 Mar 2024 10:59:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl5I1-0003mo-Ot; Fri, 15 Mar 2024 10:59:53 +0000
Received: by outflank-mailman (input) for mailman id 693760;
 Fri, 15 Mar 2024 10:59:52 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rl5I0-0000aQ-0W
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 10:59:52 +0000
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com
 [2a00:1450:4864:20::52a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 255efade-e2bb-11ee-afdd-a90da7624cb6;
 Fri, 15 Mar 2024 11:59:51 +0100 (CET)
Received: by mail-ed1-x52a.google.com with SMTP id
 4fb4d7f45d1cf-55a179f5fa1so2380568a12.0
 for ; Fri, 15 Mar 2024 03:59:51 -0700 (PDT)
Received: from carlo-ubuntu.mo54.unimo.it (nonato.mo54.unimo.it.
 [155.185.85.8]) by smtp.gmail.com with ESMTPSA id
 en6-20020a17090728c600b00a465a012cf1sm1621493ejc.18.2024.03.15.03.59.49
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 15 Mar 2024 03:59:49 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 255efade-e2bb-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1710500390; x=1711105190; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=sbEIlrFinQvaC1WD6b5XEhk/JsHo3IkTpES3k/kc46M=;
        b=X5JVq7H1JTVoibFWfH7zfKh8jxhZ6grpTdcRu3FSWT8dzIF/VGlNeL1CyHHYGz220k
         Jt3A2P5dzHBtXhGyIT+B3tlI31CEJoQttRwiCku7Uf3Hb46naJ/w7nKcgotiXjPm3n/U
         80kwrrCqe8DcUs2MLtiMBJUenJkjCQ4zvqtU5JBwNRNOaI/GvFy6OLVj5RgUS74RtiyS
         xXklv0yPcM9QN2thkgXQLZ+TSsIcwpEUeaU5NvpMPRNg46mHeJGX9xNYd+N3Q2a5Obca
         8Agsi0EOw5HunJhbeGQdvCrhTcG1JS9EDzGZeXrjycHbmK1tzQwRlCD/q6m182s4lM6a
         nedQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710500390; x=1711105190;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=sbEIlrFinQvaC1WD6b5XEhk/JsHo3IkTpES3k/kc46M=;
        b=RNLQpPQ4DjBeJVk0TJajZBjle5uz0uUqbf3zxZ7HE0nK2eB8/dioUnSclA+BCp1egW
         c6T7u4XsrZQ1yjkFgsr+jO5UdU6hp6vIQ9jmBtFnDfXGD35TrBbf9N4d9d8Vm2HyMfox
         Ef+wWxLxCP1jGtJI8mAEP9kSZRDJIJiZA3/AWTXJr3PXLAmb9ci8llWu6hU/eWf6dfSC
         7+OKHZq9YpLFaGCcREIKDX4skRRDNCiUBz7qLbTAIO5n3xJoUlKrIIMcDOzqmUdZhHCn
         4Yko0SVED5A1+nryh+sLOERef+flE2YUgx5SBU9bQ9UpStYqkD2oDuPtCJ6rh1mIheyR
         PSyw==
X-Gm-Message-State: AOJu0YwSriebwm6PN745yXoJgEJshDyNeJUBbA6E0vyogAiEBtfMfUwZ
	gRGaomDmDh8BnRFL70GnCSBerKX0i2ihCmmk/wjHbGIWUM2W9Smd98z3jwq6Sz5Y43b235ZXW3N
	Lib8=
X-Google-Smtp-Source: AGHT+IH3NBLNVrmScXSTwts+gpKohCdh9i0IaKFl3uSRhUKa3ZVww9eYWhgik88FBbBnQKZ6KFz/Ew==
X-Received: by 2002:a17:906:9c8c:b0:a3e:cdae:7aa2 with SMTP id fj12-20020a1709069c8c00b00a3ecdae7aa2mr3666451ejc.35.1710500390296;
        Fri, 15 Mar 2024 03:59:50 -0700 (PDT)
From: Carlo Nonato 
To: xen-devel@lists.xenproject.org
Cc: Carlo Nonato ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Wei Liu ,
	Marco Solieri 
Subject: [PATCH v7 14/14] xen/arm: add cache coloring support for Xen
Date: Fri, 15 Mar 2024 11:59:02 +0100
Message-Id: <20240315105902.160047-15-carlo.nonato@minervasys.tech>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
References: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Add the cache coloring support for Xen physical space.

Since Xen must be relocated to a new physical space, some relocation
functionalities must be brought back:
- the virtual address of the new space is taken from 0c18fb76323b
  ("xen/arm: Remove unused BOOT_RELOC_VIRT_START").
- relocate_xen() and get_xen_paddr() are taken from f60658c6ae47
  ("xen/arm: Stop relocating Xen").

setup_pagetables() must be adapted for coloring and for relocation. Runtime
page tables are used to map the colored space, but they are also linked in
boot tables so that the new space is temporarily available for relocation.
This implies that Xen protection must happen after the copy.

Finally, since the alternative framework needs to remap the Xen text and
inittext sections, this operation must be done in a coloring-aware way.
The function xen_remap_colored() is introduced for that.

Signed-off-by: Carlo Nonato 
Signed-off-by: Marco Solieri 
---
v7:
- added BUG_ON() checks to arch_llc_coloring_init() and
  create_llc_coloring_mappings()
v6:
- squashed with BOOT_RELOC_VIRT_START patch
- consider_modules() moved in another patch
- removed psci and smpboot code because of new idmap work already handles that
- moved xen_remap_colored() in alternative.c since it's only used there
- removed xen_colored_temp[] in favor of xen_xenmap[] usage for mapping
- use of boot_module_find_by_kind() to remove the need of extra parameter in
  setup_pagetables()
- moved get_xen_paddr() in arm/llc-coloring.c since it's only used there
v5:
- FIXME: consider_modules copy pasted since it got moved
v4:
- removed set_value_for_secondary() because it was wrongly cleaning cache
- relocate_xen() now calls switch_ttbr_id()
---
 xen/arch/arm/alternative.c            |  30 +++++++-
 xen/arch/arm/arm64/mmu/head.S         |  58 +++++++++++++-
 xen/arch/arm/arm64/mmu/mm.c           |  28 ++++++-
 xen/arch/arm/include/asm/mmu/layout.h |   3 +
 xen/arch/arm/llc-coloring.c           |  63 +++++++++++++++-
 xen/arch/arm/mmu/setup.c              | 104 ++++++++++++++++++++++----
 xen/arch/arm/setup.c                  |  10 ++-
 xen/common/llc-coloring.c             |  23 ++++++
 xen/include/xen/llc-coloring.h        |  14 ++++
 9 files changed, 310 insertions(+), 23 deletions(-)

diff --git a/xen/arch/arm/alternative.c b/xen/arch/arm/alternative.c
index 016e66978b..8ca649b55e 100644
--- a/xen/arch/arm/alternative.c
+++ b/xen/arch/arm/alternative.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -191,6 +192,27 @@ static int __apply_alternatives_multi_stop(void *xenmap)
     return 0;
 }
 
+static void __init *xen_remap_colored(mfn_t xen_mfn, paddr_t xen_size)
+{
+    unsigned int i;
+    void *xenmap;
+    mfn_t *xen_colored_mfns, mfn;
+
+    xen_colored_mfns = xmalloc_array(mfn_t, xen_size >> PAGE_SHIFT);
+    if ( !xen_colored_mfns )
+        panic("Can't allocate LLC colored MFNs\n");
+
+    for_each_xen_colored_mfn ( xen_mfn, mfn, i )
+    {
+        xen_colored_mfns[i] = mfn;
+    }
+
+    xenmap = vmap(xen_colored_mfns, xen_size >> PAGE_SHIFT);
+    xfree(xen_colored_mfns);
+
+    return xenmap;
+}
+
 /*
  * This function should only be called during boot and before CPU0 jump
  * into the idle_loop.
@@ -209,8 +231,12 @@ void __init apply_alternatives_all(void)
      * The text and inittext section are read-only. So re-map Xen to
      * be able to patch the code.
      */
-    xenmap = __vmap(&xen_mfn, 1U << xen_order, 1, 1, PAGE_HYPERVISOR,
-                    VMAP_DEFAULT);
+    if ( llc_coloring_enabled )
+        xenmap = xen_remap_colored(xen_mfn, xen_size);
+    else
+        xenmap = __vmap(&xen_mfn, 1U << xen_order, 1, 1, PAGE_HYPERVISOR,
+                        VMAP_DEFAULT);
+
     /* Re-mapping Xen is not expected to fail during boot. */
     BUG_ON(!xenmap);
 
diff --git a/xen/arch/arm/arm64/mmu/head.S b/xen/arch/arm/arm64/mmu/head.S
index fa40b696dd..7ad2c00fd5 100644
--- a/xen/arch/arm/arm64/mmu/head.S
+++ b/xen/arch/arm/arm64/mmu/head.S
@@ -427,6 +427,61 @@ fail:   PRINT("- Boot failed -\r\n")
         b     1b
 ENDPROC(fail)
 
+/*
+ * Copy Xen to new location and switch TTBR
+ * x0    ttbr
+ * x1    source address
+ * x2    destination address
+ * x3    length
+ *
+ * Source and destination must be word aligned, length is rounded up
+ * to a 16 byte boundary.
+ *
+ * MUST BE VERY CAREFUL when saving things to RAM over the copy
+ */
+ENTRY(relocate_xen)
+        /*
+         * Copy 16 bytes at a time using:
+         *   x9: counter
+         *   x10: data
+         *   x11: data
+         *   x12: source
+         *   x13: destination
+         */
+        mov     x9, x3
+        mov     x12, x1
+        mov     x13, x2
+
+1:      ldp     x10, x11, [x12], #16
+        stp     x10, x11, [x13], #16
+
+        subs    x9, x9, #16
+        bgt     1b
+
+        /*
+         * Flush destination from dcache using:
+         *   x9: counter
+         *   x10: step
+         *   x11: vaddr
+         *
+         * This is to ensure data is visible to the instruction cache
+         */
+        dsb   sy
+
+        mov   x9, x3
+        ldr   x10, =dcache_line_bytes /* x10 := step */
+        ldr   x10, [x10]
+        mov   x11, x2
+
+1:      dc    cvac, x11
+
+        add   x11, x11, x10
+        subs  x9, x9, x10
+        bgt   1b
+
+        /* No need for dsb/isb because they are alredy done in switch_ttbr_id */
+        b switch_ttbr_id
+
 /*
  * Switch TTBR
  *
@@ -452,7 +507,8 @@ ENTRY(switch_ttbr_id)
 
         /*
          * 5) Flush I-cache
-         * This should not be necessary but it is kept for safety.
+         * This should not be necessary in the general case, but it's needed
+         * for cache coloring because code is relocated in that case.
          */
         ic     iallu
         isb
diff --git a/xen/arch/arm/arm64/mmu/mm.c b/xen/arch/arm/arm64/mmu/mm.c
index d2651c9486..07cf8040a2 100644
--- a/xen/arch/arm/arm64/mmu/mm.c
+++ b/xen/arch/arm/arm64/mmu/mm.c
@@ -1,6 +1,7 @@
 /* SPDX-License-Identifier: GPL-2.0 */
 
 #include 
+#include 
 #include 
 #include 
 
@@ -125,27 +126,46 @@ void update_identity_mapping(bool enable)
 }
 
 extern void switch_ttbr_id(uint64_t ttbr);
+extern void relocate_xen(uint64_t ttbr, void *src, void *dst, size_t len);
 
 typedef void (switch_ttbr_fn)(uint64_t ttbr);
+typedef void (relocate_xen_fn)(uint64_t ttbr, void *src, void *dst, size_t len);
 
 void __init switch_ttbr(uint64_t ttbr)
 {
-    vaddr_t id_addr = virt_to_maddr(switch_ttbr_id);
-    switch_ttbr_fn *fn = (switch_ttbr_fn *)id_addr;
+    vaddr_t vaddr, id_addr;
     lpae_t pte;
 
+    if ( llc_coloring_enabled )
+        vaddr = (vaddr_t)relocate_xen;
+    else
+        vaddr = (vaddr_t)switch_ttbr_id;
+
+    id_addr = virt_to_maddr(vaddr);
+
     /* Enable the identity mapping in the boot page tables */
     update_identity_mapping(true);
 
     /* Enable the identity mapping in the runtime page tables */
-    pte = pte_of_xenaddr((vaddr_t)switch_ttbr_id);
+    pte = pte_of_xenaddr(vaddr);
     pte.pt.table = 1;
     pte.pt.xn = 0;
     pte.pt.ro = 1;
     write_pte(&xen_third_id[third_table_offset(id_addr)], pte);
 
     /* Switch TTBR */
-    fn(ttbr);
+    if ( llc_coloring_enabled )
+    {
+        relocate_xen_fn *fn = (relocate_xen_fn *)id_addr;
+
+        fn(ttbr, _start, (void *)BOOT_RELOC_VIRT_START, _end - _start);
+    }
+    else
+    {
+        switch_ttbr_fn *fn = (switch_ttbr_fn *)id_addr;
+
+        fn(ttbr);
+    }
 
     /*
      * Disable the identity mapping in the runtime page tables.
diff --git a/xen/arch/arm/include/asm/mmu/layout.h b/xen/arch/arm/include/asm/mmu/layout.h
index a3b546465b..19c0ec63a5 100644
--- a/xen/arch/arm/include/asm/mmu/layout.h
+++ b/xen/arch/arm/include/asm/mmu/layout.h
@@ -30,6 +30,7 @@
  *  10M -  12M   Fixmap: special-purpose 4K mapping slots
  *  12M -  16M   Early boot mapping of FDT
  *  16M -  18M   Livepatch vmap (if compiled in)
+ *  16M -  24M   Cache-colored Xen text, data, bss (temporary, if compiled in)
  *
  *   1G -   2G   VMAP: ioremap and early_ioremap
  *
@@ -74,6 +75,8 @@
 #define BOOT_FDT_VIRT_START     (FIXMAP_VIRT_START + FIXMAP_VIRT_SIZE)
 #define BOOT_FDT_VIRT_SIZE      _AT(vaddr_t, MB(4))
 
+#define BOOT_RELOC_VIRT_START   (BOOT_FDT_VIRT_START + BOOT_FDT_VIRT_SIZE)
+
 #ifdef CONFIG_LIVEPATCH
 #define LIVEPATCH_VMAP_START    (BOOT_FDT_VIRT_START + BOOT_FDT_VIRT_SIZE)
 #define LIVEPATCH_VMAP_SIZE    _AT(vaddr_t, MB(2))
diff --git a/xen/arch/arm/llc-coloring.c b/xen/arch/arm/llc-coloring.c
index b83540ff41..a072407e6c 100644
--- a/xen/arch/arm/llc-coloring.c
+++ b/xen/arch/arm/llc-coloring.c
@@ -9,6 +9,7 @@
 
 #include 
 #include 
+#include 
 
 /* Return the LLC way size by probing the hardware */
 unsigned int __init get_llc_way_size(void)
@@ -62,7 +63,67 @@ unsigned int __init get_llc_way_size(void)
     return line_size * num_sets;
 }
 
-void __init arch_llc_coloring_init(void) {}
+/**
+ * get_xen_paddr - get physical address to relocate Xen to
+ *
+ * Xen is relocated to as near to the top of RAM as possible and
+ * aligned to a XEN_PADDR_ALIGN boundary.
+ */
+static paddr_t __init get_xen_paddr(paddr_t xen_size)
+{
+    const struct meminfo *mi = &bootinfo.mem;
+    paddr_t min_size;
+    paddr_t paddr = 0;
+    unsigned int i;
+
+    min_size = (xen_size + (XEN_PADDR_ALIGN-1)) & ~(XEN_PADDR_ALIGN-1);
+
+    /* Find the highest bank with enough space. */
+    for ( i = 0; i < mi->nr_banks; i++ )
+    {
+        const struct membank *bank = &mi->bank[i];
+        paddr_t s, e;
+
+        if ( bank->size >= min_size )
+        {
+            e = consider_modules(bank->start, bank->start + bank->size,
+                                 min_size, XEN_PADDR_ALIGN, 0);
+            if ( !e )
+                continue;
+
+#ifdef CONFIG_ARM_32
+            /* Xen must be under 4GB */
+            if ( e > GB(4) )
+                e = GB(4);
+            if ( e < bank->start )
+                continue;
+#endif
+
+            s = e - min_size;
+
+            if ( s > paddr )
+                paddr = s;
+        }
+    }
+
+    if ( !paddr )
+        panic("Not enough memory to relocate Xen\n");
+
+    printk("Placing Xen at 0x%"PRIpaddr"-0x%"PRIpaddr"\n",
+           paddr, paddr + min_size);
+
+    return paddr;
+}
+
+void __init arch_llc_coloring_init(void)
+{
+    struct bootmodule *xen_bootmodule = boot_module_find_by_kind(BOOTMOD_XEN);
+
+    BUG_ON(!xen_bootmodule);
+
+    xen_bootmodule->size = xen_colored_map_size();
+    xen_bootmodule->start = get_xen_paddr(xen_bootmodule->size);
+}
 
 /*
  * Local variables:
diff --git a/xen/arch/arm/mmu/setup.c b/xen/arch/arm/mmu/setup.c
index de036c1f49..5823b7237f 100644
--- a/xen/arch/arm/mmu/setup.c
+++ b/xen/arch/arm/mmu/setup.c
@@ -18,6 +18,11 @@
 /* Override macros from asm/page.h to make them work with mfn_t */
 #undef mfn_to_virt
 #define mfn_to_virt(mfn) __mfn_to_virt(mfn_x(mfn))
+#undef virt_to_mfn
+#define virt_to_mfn(va) _mfn(__virt_to_mfn(va))
+
+#define virt_to_reloc_virt(virt) \
+    (((vaddr_t)virt) - XEN_VIRT_START + BOOT_RELOC_VIRT_START)
 
 /* Main runtime page tables */
 
@@ -72,6 +77,7 @@ static void __init __maybe_unused build_assertions(void)
     /* 2MB aligned regions */
     BUILD_BUG_ON(XEN_VIRT_START & ~SECOND_MASK);
     BUILD_BUG_ON(FIXMAP_ADDR(0) & ~SECOND_MASK);
+    BUILD_BUG_ON(BOOT_RELOC_VIRT_START & ~SECOND_MASK);
     /* 1GB aligned regions */
 #ifdef CONFIG_ARM_32
     BUILD_BUG_ON(XENHEAP_VIRT_START & ~FIRST_MASK);
@@ -135,7 +141,12 @@ static void __init __maybe_unused build_assertions(void)
 
 lpae_t __init pte_of_xenaddr(vaddr_t va)
 {
-    paddr_t ma = va + phys_offset;
+    paddr_t ma;
+
+    if ( llc_coloring_enabled )
+        ma = virt_to_maddr(virt_to_reloc_virt(va));
+    else
+        ma = va + phys_offset;
 
     return mfn_to_xen_entry(maddr_to_mfn(ma), MT_NORMAL);
 }
@@ -313,9 +324,44 @@ paddr_t __init consider_modules(paddr_t s, paddr_t e,
     return e;
 }
 
+static void __init create_llc_coloring_mappings(void)
+{
+    lpae_t pte;
+    unsigned int i;
+    struct bootmodule *xen_bootmodule = boot_module_find_by_kind(BOOTMOD_XEN);
+    mfn_t start_mfn = maddr_to_mfn(xen_bootmodule->start), mfn;
+
+    for_each_xen_colored_mfn ( start_mfn, mfn, i )
+    {
+        pte = mfn_to_xen_entry(mfn, MT_NORMAL);
+        pte.pt.table = 1; /* level 3 mappings always have this bit set */
+        xen_xenmap[i] = pte;
+    }
+
+    for ( i = 0; i < XEN_NR_ENTRIES(2); i++ )
+    {
+        vaddr_t va = BOOT_RELOC_VIRT_START + (i << XEN_PT_LEVEL_SHIFT(2));
+
+        pte = mfn_to_xen_entry(virt_to_mfn(xen_xenmap +
+                                           i * XEN_PT_LPAE_ENTRIES),
+                               MT_NORMAL);
+        pte.pt.table = 1;
+        write_pte(&boot_second[second_table_offset(va)], pte);
+    }
+}
+
 /*
- * Boot-time pagetable setup.
+ * Boot-time pagetable setup with coloring support
  * Changes here may need matching changes in head.S
+ *
+ * The cache coloring support consists of:
+ * - Create colored mapping that conforms to Xen color selection in xen_xenmap[]
+ * - Link the mapping in boot page tables using BOOT_RELOC_VIRT_START as vaddr
+ * - pte_of_xenaddr() takes care of translating addresses to the new space
+ *   during runtime page tables creation
+ * - Relocate xen and update TTBR with the new address in the colored space
+ *   (see switch_ttbr())
+ * - Protect the new space
  */
 void __init setup_pagetables(unsigned long boot_phys_offset)
 {
@@ -325,6 +371,9 @@ void __init setup_pagetables(unsigned long boot_phys_offset)
 
     phys_offset = boot_phys_offset;
 
+    if ( llc_coloring_enabled )
+        create_llc_coloring_mappings();
+
     arch_setup_page_tables();
 
 #ifdef CONFIG_ARM_64
@@ -352,13 +401,7 @@ void __init setup_pagetables(unsigned long boot_phys_offset)
             break;
         pte = pte_of_xenaddr(va);
         pte.pt.table = 1; /* third level mappings always have this bit set */
-        if ( is_kernel_text(va) || is_kernel_inittext(va) )
-        {
-            pte.pt.xn = 0;
-            pte.pt.ro = 1;
-        }
-        if ( is_kernel_rodata(va) )
-            pte.pt.ro = 1;
+        pte.pt.xn = 0; /* Permissions will be enforced later. Allow execution */
         xen_xenmap[i] = pte;
     }
 
@@ -384,13 +427,48 @@ void __init setup_pagetables(unsigned long boot_phys_offset)
     ttbr = (uintptr_t) cpu0_pgtable + phys_offset;
 #endif
 
-    switch_ttbr(ttbr);
-
-    xen_pt_enforce_wnx();
-
 #ifdef CONFIG_ARM_32
     per_cpu(xen_pgtable, 0) = cpu0_pgtable;
 #endif
+
+    if ( llc_coloring_enabled )
+        ttbr = virt_to_maddr(virt_to_reloc_virt(THIS_CPU_PGTABLE));
+
+    switch_ttbr(ttbr);
+
+    /* Protect Xen */
+    for ( i = 0; i < XEN_NR_ENTRIES(3); i++ )
+    {
+        vaddr_t va = XEN_VIRT_START + (i << PAGE_SHIFT);
+        lpae_t *entry = xen_xenmap + i;
+
+        if ( !is_kernel(va) )
+            break;
+
+        pte = read_atomic(entry);
+
+        if ( is_kernel_text(va) || is_kernel_inittext(va) )
+        {
+            pte.pt.xn = 0;
+            pte.pt.ro = 1;
+        } else if ( is_kernel_rodata(va) ) {
+            pte.pt.ro = 1;
+            pte.pt.xn = 1;
+        } else {
+            pte.pt.xn = 1;
+            pte.pt.ro = 0;
+        }
+
+        write_pte(entry, pte);
+    }
+
+    /*
+     * We modified live page-tables. Ensure the TLBs are invalidated
+     * before setting enforcing the WnX permissions.
+     */
+    flush_xen_tlb_local();
+
+    xen_pt_enforce_wnx();
 }
 
 void *__init arch_vmap_virt_end(void)
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index c72c90302e..9acec8e8b1 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -724,8 +724,6 @@ void asmlinkage __init start_xen(unsigned long boot_phys_offset,
     /* Initialize traps early allow us to get backtrace when an error occurred */
     init_traps();
 
-    setup_pagetables(boot_phys_offset);
-
     smp_clear_cpu_maps();
 
     device_tree_flattened = early_fdt_map(fdt_paddr);
@@ -749,6 +747,14 @@ void asmlinkage __init start_xen(unsigned long boot_phys_offset,
 
     llc_coloring_init();
 
+    /*
+     * Page tables must be setup after LLC coloring initialization because
+     * coloring info are required in order to create colored mappings
+     */
+    setup_pagetables(boot_phys_offset);
+    /* Device-tree was mapped in boot page tables, remap it in the new tables */
+    device_tree_flattened = early_fdt_map(fdt_paddr);
+
     setup_mm();
 
     vm_init();
diff --git a/xen/common/llc-coloring.c b/xen/common/llc-coloring.c
index f1a7561d79..246b0ca04d 100644
--- a/xen/common/llc-coloring.c
+++ b/xen/common/llc-coloring.c
@@ -29,6 +29,8 @@ static unsigned int __ro_after_init xen_num_colors;
 
 #define mfn_color_mask              (max_nr_colors - 1)
 #define mfn_to_color(mfn)           (mfn_x(mfn) & mfn_color_mask)
+#define get_mfn_with_color(mfn, color) \
+    (_mfn((mfn_x(mfn) & ~mfn_color_mask) | (color)))
 
 /*
  * Parse the coloring configuration given in the buf string, following the
@@ -326,6 +328,27 @@ unsigned int get_max_nr_llc_colors(void)
     return max_nr_colors;
 }
 
+paddr_t __init xen_colored_map_size(void)
+{
+    return ROUNDUP((_end - _start) * max_nr_colors, XEN_PADDR_ALIGN);
+}
+
+mfn_t __init xen_colored_mfn(mfn_t mfn)
+{
+    unsigned int i, color = mfn_to_color(mfn);
+
+    for ( i = 0; i < xen_num_colors; i++ )
+    {
+        if ( color == xen_colors[i] )
+            return mfn;
+        else if ( color < xen_colors[i] )
+            return get_mfn_with_color(mfn, xen_colors[i]);
+    }
+
+    /* Jump to next color space (max_nr_colors mfns) and use the first color */
+    return get_mfn_with_color(mfn_add(mfn, max_nr_colors), xen_colors[0]);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/xen/llc-coloring.h b/xen/include/xen/llc-coloring.h
index 7f8218bfb2..618833c5dc 100644
--- a/xen/include/xen/llc-coloring.h
+++ b/xen/include/xen/llc-coloring.h
@@ -26,6 +26,17 @@ static inline void domain_dump_llc_colors(const struct domain *d) {}
 static inline void domain_llc_coloring_free(struct domain *d) {}
 #endif
 
+/**
+ * Iterate over each Xen mfn in the colored space.
+ * @start_mfn:  the first mfn that needs to be colored.
+ * @mfn:        the current mfn.
+ * @i:          loop index.
+ */
+#define for_each_xen_colored_mfn(start_mfn, mfn, i) \
+    for ( i = 0, mfn = xen_colored_mfn(start_mfn);  \
+          i < (_end - _start) >> PAGE_SHIFT;        \
+          i++, mfn = xen_colored_mfn(mfn_add(mfn, 1)) )
+
 unsigned int get_llc_way_size(void);
 void arch_llc_coloring_init(void);
 int dom0_set_llc_colors(struct domain *d);
@@ -37,6 +48,9 @@ struct page_info;
 unsigned int page_to_llc_color(const struct page_info *pg);
 unsigned int get_max_nr_llc_colors(void);
 
+paddr_t xen_colored_map_size(void);
+mfn_t xen_colored_mfn(mfn_t mfn);
+
 #endif /* __COLORING_H__ */
 
 /*
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Mar 15 10:59:56 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 10:59:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693761.1082328 (Exim 4.92)
	(envelope-from )
	id 1rl5I3-00047Y-Pi; Fri, 15 Mar 2024 10:59:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693761.1082328; Fri, 15 Mar 2024 10:59:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl5I3-00044U-75; Fri, 15 Mar 2024 10:59:55 +0000
Received: by outflank-mailman (input) for mailman id 693761;
 Fri, 15 Mar 2024 10:59:52 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rl5I0-0000xG-0U
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 10:59:52 +0000
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com
 [2a00:1450:4864:20::536])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 24eda1b6-e2bb-11ee-a1ee-f123f15fe8a2;
 Fri, 15 Mar 2024 11:59:50 +0100 (CET)
Received: by mail-ed1-x536.google.com with SMTP id
 4fb4d7f45d1cf-5684db9147dso2707411a12.2
 for ; Fri, 15 Mar 2024 03:59:50 -0700 (PDT)
Received: from carlo-ubuntu.mo54.unimo.it (nonato.mo54.unimo.it.
 [155.185.85.8]) by smtp.gmail.com with ESMTPSA id
 en6-20020a17090728c600b00a465a012cf1sm1621493ejc.18.2024.03.15.03.59.48
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 15 Mar 2024 03:59:48 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 24eda1b6-e2bb-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1710500389; x=1711105189; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=LB6BgYTUa1kOXdqGeJqi23zdypFJzo1UCspbeuE4GtA=;
        b=UE5vEGiKQOPdsxZ3bxtagA1/fKYRhyfVURi2X+drUIt98poyLuu1htH5TAxALtxeIj
         s0HlQWSvJwNCXFaup3gAeVf2jOnrc3a+9GPqQ8wCljSKVwHVHpB066joR3DFOb3nrmrh
         CpVRZwqp1shj3KdFPMaANG66MpXXceoYZkOqi0s2Ky9IWz2STjfw+9/FPYxsDF0CcAbv
         N7VLSga1ZMNylxXpiwBgYH58lBOiWtyZmkN8F9whf+EzCtMFgHx7mCYJKEJ5eyEcMzKB
         5ctFQ39dfFU/fu6ry3leuJECyXUSvg/nhRzfwNDlQzwSYwD6Kzq5IqIliHZNjk1J95aA
         g4LA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710500389; x=1711105189;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=LB6BgYTUa1kOXdqGeJqi23zdypFJzo1UCspbeuE4GtA=;
        b=wZsZibVbXpSBSztV7CSaPKJZUoES47cFK202rYbIuEKhoV/BSYk0MnFBUICVYaMYBq
         522MnKTnULGlI5SeEpLyL3eZ8qCVVW+SQj+C8DIEL/EdvKZlQtJ8XGhXIz9iKYKYuP+G
         T6nKCp5rq242Io3WIpDU+hGNNEMedQj8kLRCRG4O2aMJXPgR9fKFpy9QeoKsdSoKhq9F
         byMypFfrXFZyZhEDY+TZw+h/XXj9/3/x0NRYASNxKuGw8gXhI/8Lep6Avx4EeJ+f21yK
         t2HVOzf2XUl8H3LMVfCWNrloscdr08w+eu+jYXWhvTMcIURHY5EGQV4Jf2ueXzadRDV8
         oigA==
X-Gm-Message-State: AOJu0Yz8uo7Jj5XlCi4/HSU0MtHHxI/yl0gPt1Qo3r4qovtxYhs1Bh5r
	9SAB3DmwFli+qytI46E995g7O/GfPVrrbTsE6VYiBcet3bGxA0wBkc1knJJl7Fj1S+bK/TosQJW
	IWF8=
X-Google-Smtp-Source: AGHT+IEWF9JpYIT8wllQAlXqsumloaAQUttwEWWZ8iRrRYvP2s6KNOSHgSAVlGUfoE5QYhlPJBU5jg==
X-Received: by 2002:a17:907:c783:b0:a46:42d4:fbd4 with SMTP id tz3-20020a170907c78300b00a4642d4fbd4mr3545057ejc.35.1710500389201;
        Fri, 15 Mar 2024 03:59:49 -0700 (PDT)
From: Carlo Nonato 
To: xen-devel@lists.xenproject.org
Cc: Carlo Nonato ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk 
Subject: [PATCH v7 13/14] xen/arm: make consider_modules() available for xen relocation
Date: Fri, 15 Mar 2024 11:59:01 +0100
Message-Id: <20240315105902.160047-14-carlo.nonato@minervasys.tech>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
References: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Cache coloring must physically relocate Xen in order to color the hypervisor
and consider_modules() is a key function that is needed to find a new
available physical address.

672d67f339c0 ("xen/arm: Split MMU-specific setup_mm() and related code out")
moved consider_modules() under arm32. Move it to mmu/setup.c and make it
non-static so that it can be used outside.

Signed-off-by: Carlo Nonato 
---
v7:
- moved consider_modules() to arm/mmu/setup.c
v6:
- new patch
---
 xen/arch/arm/arm32/mmu/mm.c      | 93 +------------------------------
 xen/arch/arm/include/asm/setup.h |  3 +
 xen/arch/arm/mmu/setup.c         | 95 ++++++++++++++++++++++++++++++++
 3 files changed, 99 insertions(+), 92 deletions(-)

diff --git a/xen/arch/arm/arm32/mmu/mm.c b/xen/arch/arm/arm32/mmu/mm.c
index cb441ca87c..e9e1e48f9f 100644
--- a/xen/arch/arm/arm32/mmu/mm.c
+++ b/xen/arch/arm/arm32/mmu/mm.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static unsigned long opt_xenheap_megabytes __initdata;
 integer_param("xenheap_megabytes", opt_xenheap_megabytes);
@@ -29,98 +30,6 @@ static void __init setup_directmap_mappings(unsigned long base_mfn,
     directmap_virt_end = XENHEAP_VIRT_START + nr_mfns * PAGE_SIZE;
 }
 
-/*
- * Returns the end address of the highest region in the range s..e
- * with required size and alignment that does not conflict with the
- * modules from first_mod to nr_modules.
- *
- * For non-recursive callers first_mod should normally be 0 (all
- * modules and Xen itself) or 1 (all modules but not Xen).
- */
-static paddr_t __init consider_modules(paddr_t s, paddr_t e,
-                                       uint32_t size, paddr_t align,
-                                       int first_mod)
-{
-    const struct bootmodules *mi = &bootinfo.modules;
-    int i;
-    int nr;
-
-    s = (s+align-1) & ~(align-1);
-    e = e & ~(align-1);
-
-    if ( s > e ||  e - s < size )
-        return 0;
-
-    /* First check the boot modules */
-    for ( i = first_mod; i < mi->nr_mods; i++ )
-    {
-        paddr_t mod_s = mi->module[i].start;
-        paddr_t mod_e = mod_s + mi->module[i].size;
-
-        if ( s < mod_e && mod_s < e )
-        {
-            mod_e = consider_modules(mod_e, e, size, align, i+1);
-            if ( mod_e )
-                return mod_e;
-
-            return consider_modules(s, mod_s, size, align, i+1);
-        }
-    }
-
-    /* Now check any fdt reserved areas. */
-
-    nr = fdt_num_mem_rsv(device_tree_flattened);
-
-    for ( ; i < mi->nr_mods + nr; i++ )
-    {
-        paddr_t mod_s, mod_e;
-
-        if ( fdt_get_mem_rsv_paddr(device_tree_flattened,
-                                   i - mi->nr_mods,
-                                   &mod_s, &mod_e ) < 0 )
-            /* If we can't read it, pretend it doesn't exist... */
-            continue;
-
-        /* fdt_get_mem_rsv_paddr returns length */
-        mod_e += mod_s;
-
-        if ( s < mod_e && mod_s < e )
-        {
-            mod_e = consider_modules(mod_e, e, size, align, i+1);
-            if ( mod_e )
-                return mod_e;
-
-            return consider_modules(s, mod_s, size, align, i+1);
-        }
-    }
-
-    /*
-     * i is the current bootmodule we are evaluating, across all
-     * possible kinds of bootmodules.
-     *
-     * When retrieving the corresponding reserved-memory addresses, we
-     * need to index the bootinfo.reserved_mem bank starting from 0, and
-     * only counting the reserved-memory modules. Hence, we need to use
-     * i - nr.
-     */
-    nr += mi->nr_mods;
-    for ( ; i - nr < bootinfo.reserved_mem.nr_banks; i++ )
-    {
-        paddr_t r_s = bootinfo.reserved_mem.bank[i - nr].start;
-        paddr_t r_e = r_s + bootinfo.reserved_mem.bank[i - nr].size;
-
-        if ( s < r_e && r_s < e )
-        {
-            r_e = consider_modules(r_e, e, size, align, i + 1);
-            if ( r_e )
-                return r_e;
-
-            return consider_modules(s, r_s, size, align, i + 1);
-        }
-    }
-    return e;
-}
-
 /*
  * Find a contiguous region that fits in the static heap region with
  * required size and alignment, and return the end address of the region
diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h
index d15a88d2e0..37c0e345f0 100644
--- a/xen/arch/arm/include/asm/setup.h
+++ b/xen/arch/arm/include/asm/setup.h
@@ -207,6 +207,9 @@ struct init_info
     unsigned int cpuid;
 };
 
+paddr_t consider_modules(paddr_t s, paddr_t e, uint32_t size, paddr_t align,
+                         int first_mod);
+
 #endif
 /*
  * Local variables:
diff --git a/xen/arch/arm/mmu/setup.c b/xen/arch/arm/mmu/setup.c
index 57f1b46499..de036c1f49 100644
--- a/xen/arch/arm/mmu/setup.c
+++ b/xen/arch/arm/mmu/setup.c
@@ -6,7 +6,10 @@
  */
 
 #include 
+#include 
 #include 
+#include 
+#include 
 #include 
 #include 
 
@@ -218,6 +221,98 @@ static void xen_pt_enforce_wnx(void)
     flush_xen_tlb_local();
 }
 
+/*
+ * Returns the end address of the highest region in the range s..e
+ * with required size and alignment that does not conflict with the
+ * modules from first_mod to nr_modules.
+ *
+ * For non-recursive callers first_mod should normally be 0 (all
+ * modules and Xen itself) or 1 (all modules but not Xen).
+ */
+paddr_t __init consider_modules(paddr_t s, paddr_t e,
+                                uint32_t size, paddr_t align,
+                                int first_mod)
+{
+    const struct bootmodules *mi = &bootinfo.modules;
+    int i;
+    int nr;
+
+    s = (s+align-1) & ~(align-1);
+    e = e & ~(align-1);
+
+    if ( s > e ||  e - s < size )
+        return 0;
+
+    /* First check the boot modules */
+    for ( i = first_mod; i < mi->nr_mods; i++ )
+    {
+        paddr_t mod_s = mi->module[i].start;
+        paddr_t mod_e = mod_s + mi->module[i].size;
+
+        if ( s < mod_e && mod_s < e )
+        {
+            mod_e = consider_modules(mod_e, e, size, align, i+1);
+            if ( mod_e )
+                return mod_e;
+
+            return consider_modules(s, mod_s, size, align, i+1);
+        }
+    }
+
+    /* Now check any fdt reserved areas. */
+
+    nr = fdt_num_mem_rsv(device_tree_flattened);
+
+    for ( ; i < mi->nr_mods + nr; i++ )
+    {
+        paddr_t mod_s, mod_e;
+
+        if ( fdt_get_mem_rsv_paddr(device_tree_flattened,
+                                   i - mi->nr_mods,
+                                   &mod_s, &mod_e ) < 0 )
+            /* If we can't read it, pretend it doesn't exist... */
+            continue;
+
+        /* fdt_get_mem_rsv_paddr returns length */
+        mod_e += mod_s;
+
+        if ( s < mod_e && mod_s < e )
+        {
+            mod_e = consider_modules(mod_e, e, size, align, i+1);
+            if ( mod_e )
+                return mod_e;
+
+            return consider_modules(s, mod_s, size, align, i+1);
+        }
+    }
+
+    /*
+     * i is the current bootmodule we are evaluating, across all
+     * possible kinds of bootmodules.
+     *
+     * When retrieving the corresponding reserved-memory addresses, we
+     * need to index the bootinfo.reserved_mem bank starting from 0, and
+     * only counting the reserved-memory modules. Hence, we need to use
+     * i - nr.
+     */
+    nr += mi->nr_mods;
+    for ( ; i - nr < bootinfo.reserved_mem.nr_banks; i++ )
+    {
+        paddr_t r_s = bootinfo.reserved_mem.bank[i - nr].start;
+        paddr_t r_e = r_s + bootinfo.reserved_mem.bank[i - nr].size;
+
+        if ( s < r_e && r_s < e )
+        {
+            r_e = consider_modules(r_e, e, size, align, i + 1);
+            if ( r_e )
+                return r_e;
+
+            return consider_modules(s, r_s, size, align, i + 1);
+        }
+    }
+    return e;
+}
+
 /*
  * Boot-time pagetable setup.
  * Changes here may need matching changes in head.S
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Mar 15 11:08:05 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 11:08:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693784.1082351 (Exim 4.92)
	(envelope-from )
	id 1rl5Pr-0001K9-Po; Fri, 15 Mar 2024 11:07:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693784.1082351; Fri, 15 Mar 2024 11:07:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl5Pr-0001K2-N2; Fri, 15 Mar 2024 11:07:59 +0000
Received: by outflank-mailman (input) for mailman id 693784;
 Fri, 15 Mar 2024 11:07:58 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rl5Pq-0001J2-Eu
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 11:07:58 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 47868e4a-e2bc-11ee-afdd-a90da7624cb6;
 Fri, 15 Mar 2024 12:07:57 +0100 (CET)
Received: from [172.20.10.8] (unknown [78.211.227.3])
 by support.bugseng.com (Postfix) with ESMTPSA id B8FEA4EE073C;
 Fri, 15 Mar 2024 12:07:56 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 47868e4a-e2bc-11ee-afdd-a90da7624cb6
Message-ID: <42d630c9-e311-4e17-9fae-e14ec81a339e@bugseng.com>
Date: Fri, 15 Mar 2024 12:07:55 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US, it
From: Federico Serafini 
Subject: x86/bitops and MISRA C:2012 Rule 5.5
Organization: BUGSENG
To: xen-devel@lists.xenproject.org
Cc: Jan Beulich , Andrew Cooper
 , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Wei Liu 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hello everyone,

there are violations of Rule 5.5 ("Identifiers shall be distinct
from macro names") in xen/arch/x86/include/asm/bitops.h.
You can see them at [1].

Do you agree to distinguish between function-like macros and
inline functions by adding a suffix to the functions?
I thought about "_unsafe" or "_nocheck" suffixes.
As an example:

@@ -32,14 +32,14 @@ extern void __bitop_bad_size(void);
   * Note that @nr may be almost arbitrarily large; this function is not
   * restricted to acting on a single-word quantity.
   */
-static inline void set_bit(int nr, volatile void *addr)
+static inline void set_bit_unsafe(int nr, volatile void *addr)
  {
      asm volatile ( "lock; btsl %1,%0"
                     : "+m" (ADDR) : "Ir" (nr) : "memory");
  }
  #define set_bit(nr, addr) ({                            \
      if ( bitop_bad_size(addr) ) __bitop_bad_size();     \
-    set_bit(nr, addr);                                  \
+    set_bit_unsafe(nr, addr);                           \
  })


[1]
https://saas.eclairit.com:3787/fs/var/local/eclair/XEN.ecdf/ECLAIR_normal/staging/X86_64-BUGSENG/575/PROJECT.ecd;/by_service/MC3R1.R5.5.html#{"select":true,"selection":{"hiddenAreaKinds":[],"hiddenSubareaKinds":[],"show":true,"selector":{"enabled":true,"negated":false,"kind":2,"children":[{"enabled":true,"negated":false,"kind":0,"domain":"file","inputs":[{"enabled":true,"text":"xen/arch/x86/include/asm/bitops.h"}]}]}}}

-- 
Federico Serafini, M.Sc.

Software Engineer, BUGSENG (http://bugseng.com)


From xen-devel-bounces@lists.xenproject.org Fri Mar 15 11:13:12 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 11:13:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693789.1082361 (Exim 4.92)
	(envelope-from )
	id 1rl5Up-0002zC-BK; Fri, 15 Mar 2024 11:13:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693789.1082361; Fri, 15 Mar 2024 11:13:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl5Up-0002z5-8P; Fri, 15 Mar 2024 11:13:07 +0000
Received: by outflank-mailman (input) for mailman id 693789;
 Fri, 15 Mar 2024 11:13:05 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rl5Un-0002yz-T2
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 11:13:05 +0000
Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com
 [2607:f8b0:4864:20::733])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id fd9dadac-e2bc-11ee-a1ee-f123f15fe8a2;
 Fri, 15 Mar 2024 12:13:03 +0100 (CET)
Received: by mail-qk1-x733.google.com with SMTP id
 af79cd13be357-789de1f59feso98226385a.3
 for ; Fri, 15 Mar 2024 04:13:03 -0700 (PDT)
Received: from [10.80.67.149] (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 dc33-20020a05620a522100b007885cd1c058sm1929059qkb.103.2024.03.15.04.13.01
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 15 Mar 2024 04:13:02 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: fd9dadac-e2bc-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710501183; x=1711105983; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=TH4oZKWsSpsm50Au/stOiDvSfimGlrtLfYhMA69EASM=;
        b=U2OzfFIVelUG0OPWW+7Kd2L/n//3E4Tvneb0m6/SEmYpMWE5By12z/quyXKoY5qDGH
         YD5U2tHiHGb93uTcUYsapBWEEYKv1Hs6iw8WasBq0Z3KdD4GXYsMWYY2W6yTt0Xv8dw8
         H65dyrJZ53zg309TtzKxU9hLG5Fz2YrPzISns=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710501183; x=1711105983;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=TH4oZKWsSpsm50Au/stOiDvSfimGlrtLfYhMA69EASM=;
        b=cIZs8ep9qFLAS9cW5LwqXTytBNQI72iup19TnhP+94uskLP+df6dzfO+xwAQAqZ2YU
         ui6Q7wFvcuAyY7FkkzTKAU2b1VWsWSb6TBKzjfqQ7E9uw0O3MrHgtxmFTAGzk1i4Qj8P
         tCKcmlmU0LxN6ebHo5vSdMvuEjr83VWz6CwsnlTCF/O2pddnlv/FettaHZD/VX+hG75g
         RHVDk/HgxzlUIQ/WchVVKvwwbKQn+bTv+XX+GHGuUWkbXupbXkrWAG4PCYbC5d2QnXsq
         nKuHlpTfbKRVqM91hQjUeHF+KPQKPFkGehptxJkx3Pg8QYEBkjOs0bblsJZj78LCJpND
         VJcA==
X-Forwarded-Encrypted: i=1; AJvYcCVz42NKhwzrDHcYGknLt9WXXXHrJucDJ/rfFDYT1jXNnHMHEEEOKTpfwCpmw+2WfgRONn+kA01OGTC7/ZA89NvZB1ePtgJ4sHYTIokTQJU=
X-Gm-Message-State: AOJu0Yyt34NKJIU+gXPxc1FOxOctfrt2UL9PSPMpJOumIpOuNXrWN+6/
	zMvb0CAzYa5YceG1FeHZ/9H/3EIXsK/XiJeSy11xTxmiv3vkixBkzG86i2sElws=
X-Google-Smtp-Source: AGHT+IF0RF8eP42+G5vXE7DU8L5+KV19LL5nEUsrAFC0mtTocqvnBzvW7BXp5hW40aLri8akp1GhFQ==
X-Received: by 2002:a05:620a:cf2:b0:789:d334:619c with SMTP id c18-20020a05620a0cf200b00789d334619cmr4503526qkj.29.1710501182604;
        Fri, 15 Mar 2024 04:13:02 -0700 (PDT)
Message-ID: <9958b4cc-a6a5-4370-b87e-3e2facf7ee5f@citrix.com>
Date: Fri, 15 Mar 2024 11:13:00 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: x86/bitops and MISRA C:2012 Rule 5.5
Content-Language: en-GB
To: Federico Serafini ,
 xen-devel@lists.xenproject.org
Cc: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Wei Liu 
References: <42d630c9-e311-4e17-9fae-e14ec81a339e@bugseng.com>
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <42d630c9-e311-4e17-9fae-e14ec81a339e@bugseng.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 15/03/2024 11:07 am, Federico Serafini wrote:
> Hello everyone,
>
> there are violations of Rule 5.5 ("Identifiers shall be distinct
> from macro names") in xen/arch/x86/include/asm/bitops.h.
> You can see them at [1].
>
> Do you agree to distinguish between function-like macros and
> inline functions by adding a suffix to the functions?

Please see the other bitops thread, which you're also CC'd on.

Although it's not got to these functions yet, this is going to be fixed
by having set_bit() be common, and arch_set_bit() be the per-arch
implemenation.

Neither _unsafe nor _nocheck are remotely appropriate here.

~Andrew


From xen-devel-bounces@lists.xenproject.org Fri Mar 15 11:16:31 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 11:16:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693797.1082371 (Exim 4.92)
	(envelope-from )
	id 1rl5Y5-00045y-Oi; Fri, 15 Mar 2024 11:16:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693797.1082371; Fri, 15 Mar 2024 11:16:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl5Y5-00045r-Lh; Fri, 15 Mar 2024 11:16:29 +0000
Received: by outflank-mailman (input) for mailman id 693797;
 Fri, 15 Mar 2024 11:16:28 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rl5Y3-00042w-UK
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 11:16:28 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 75021a23-e2bd-11ee-afdd-a90da7624cb6;
 Fri, 15 Mar 2024 12:16:23 +0100 (CET)
Received: from nico.bugseng.com (unknown [46.228.253.194])
 by support.bugseng.com (Postfix) with ESMTPSA id D5F484EE073C;
 Fri, 15 Mar 2024 12:16:22 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 75021a23-e2bd-11ee-afdd-a90da7624cb6
From: Nicola Vetrini 
To: nicola.vetrini@bugseng.com,
	xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org,
	michal.orzel@amd.com,
	xenia.ragiadakou@amd.com,
	ayan.kumar.halder@amd.com,
	consulting@bugseng.com,
	Jan Beulich ,
	Andrew Cooper 
Subject: [XEN PATCH v2] amd/iommu: clean up unused guest iommu related functions
Date: Fri, 15 Mar 2024 12:16:19 +0100
Message-Id: <324c939125677032af2c1d2e5fb628849415d68e.1710501265.git.nicola.vetrini@bugseng.com>
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Delete unused functions from 'iommu_guest.c'.

The 'cmd' parameter of amd_iommu_send_guest_cmd is passed
to a function that expects arrays of size 4, therefore
specifying explicitly the size also in amd_iommu_send_guest_cmd
allows not to accidentally pass a bigger array.

No functional change.

Signed-off-by: Nicola Vetrini 
---
All current users of amd_iommu_send_guest pass an array of size 4,
hence this is fixing a potential issue noticed by the analyzer for MISRA C
Rule 17.5, not an actual bug.

guest_iommu_add_ptr_log has still one caller, but even that seems
suspicious. I left it in and uniformed its parameter type at the
moment, so that whether it should be kept can be sorted out later.
If that caller indeed should be removed as well, then
no function in the file is actually reachable as far as I can tell.

Changes in v2:
- change parameter type to uint32_t
- remove unused functions
---
 xen/drivers/passthrough/amd/iommu.h       |   8 +-
 xen/drivers/passthrough/amd/iommu_cmd.c   |   2 +-
 xen/drivers/passthrough/amd/iommu_guest.c | 762 +---------------------
 3 files changed, 4 insertions(+), 768 deletions(-)

diff --git a/xen/drivers/passthrough/amd/iommu.h b/xen/drivers/passthrough/amd/iommu.h
index 1b62c083ba67..6b8ef2ca527c 100644
--- a/xen/drivers/passthrough/amd/iommu.h
+++ b/xen/drivers/passthrough/amd/iommu.h
@@ -346,12 +346,8 @@ void cf_check amd_iommu_crash_shutdown(void);
 
 /* guest iommu support */
 #ifdef CONFIG_HVM
-void amd_iommu_send_guest_cmd(struct amd_iommu *iommu, u32 cmd[]);
-void guest_iommu_add_ppr_log(struct domain *d, u32 entry[]);
-void guest_iommu_add_event_log(struct domain *d, u32 entry[]);
-int guest_iommu_init(struct domain* d);
-void guest_iommu_destroy(struct domain *d);
-int guest_iommu_set_base(struct domain *d, uint64_t base);
+void amd_iommu_send_guest_cmd(struct amd_iommu *iommu, uint32_t cmd[4]);
+void guest_iommu_add_ppr_log(struct domain *d, uint32_t entry[]);
 #else
 static inline void guest_iommu_add_ppr_log(struct domain *d, uint32_t entry[]) {}
 #endif
diff --git a/xen/drivers/passthrough/amd/iommu_cmd.c b/xen/drivers/passthrough/amd/iommu_cmd.c
index 49b9fcac9410..e12840ed02f5 100644
--- a/xen/drivers/passthrough/amd/iommu_cmd.c
+++ b/xen/drivers/passthrough/amd/iommu_cmd.c
@@ -390,7 +390,7 @@ void amd_iommu_flush_all_caches(struct amd_iommu *iommu)
     flush_command_buffer(iommu, 0);
 }
 
-void amd_iommu_send_guest_cmd(struct amd_iommu *iommu, u32 cmd[])
+void amd_iommu_send_guest_cmd(struct amd_iommu *iommu, uint32_t cmd[4])
 {
     send_iommu_command(iommu, cmd);
     /* TBD: Timeout selection may require peeking into cmd[]. */
diff --git a/xen/drivers/passthrough/amd/iommu_guest.c b/xen/drivers/passthrough/amd/iommu_guest.c
index 4c4252eea116..19bd2e5d8e63 100644
--- a/xen/drivers/passthrough/amd/iommu_guest.c
+++ b/xen/drivers/passthrough/amd/iommu_guest.c
@@ -20,28 +20,7 @@
 
 #include "iommu.h"
 
-#define IOMMU_MMIO_SIZE                         0x8000
-#define IOMMU_MMIO_PAGE_NR                      0x8
-#define RING_BF_LENGTH_MASK                     0x0F000000
-#define RING_BF_LENGTH_SHIFT                    24
-
-#define PASMAX_9_bit                            0x8
-#define GUEST_CR3_1_LEVEL                       0x0
-#define GUEST_ADDRESS_SIZE_6_LEVEL              0x2
-#define HOST_ADDRESS_SIZE_6_LEVEL               0x2
-
 #define reg_to_u64(reg) (((uint64_t)reg.hi << 32) | reg.lo )
-#define u64_to_reg(reg, val) \
-    do \
-    { \
-        (reg)->lo = (u32)(val); \
-        (reg)->hi = (val) >> 32; \
-    } while (0)
-
-static unsigned int get_machine_bdf(struct domain *d, uint16_t guest_bdf)
-{
-    return guest_bdf;
-}
 
 static uint16_t get_guest_bdf(struct domain *d, uint16_t machine_bdf)
 {
@@ -53,62 +32,6 @@ static inline struct guest_iommu *domain_iommu(struct domain *d)
     return dom_iommu(d)->arch.amd.g_iommu;
 }
 
-static inline struct guest_iommu *vcpu_iommu(struct vcpu *v)
-{
-    return dom_iommu(v->domain)->arch.amd.g_iommu;
-}
-
-static void guest_iommu_enable(struct guest_iommu *iommu)
-{
-    iommu->enabled = 1;
-}
-
-static void guest_iommu_disable(struct guest_iommu *iommu)
-{
-    iommu->enabled = 0;
-}
-
-/*
- * The Guest CR3 Table is a table written by the guest kernel, pointing at
- * gCR3 values for PASID transactions to use.  The Device Table Entry points
- * at a system physical address.
- *
- * However, these helpers deliberately use untyped parameters without
- * reference to gfn/mfn because they are used both for programming the real
- * IOMMU, and interpreting a guests programming of its vIOMMU.
- */
-static uint64_t dte_get_gcr3_table(const struct amd_iommu_dte *dte)
-{
-    return (((uint64_t)dte->gcr3_trp_51_31 << 31) |
-            (dte->gcr3_trp_30_15 << 15) |
-            (dte->gcr3_trp_14_12 << 12));
-}
-
-static void dte_set_gcr3_table(struct amd_iommu_dte *dte, uint16_t dom_id,
-                               uint64_t addr, bool gv, uint8_t glx)
-{
-#define GCR3_MASK(hi, lo) (((1UL << ((hi) + 1)) - 1) & ~((1UL << (lo)) - 1))
-
-    /* I bit must be set when gcr3 is enabled */
-    dte->i = true;
-
-    dte->gcr3_trp_14_12 = MASK_EXTR(addr, GCR3_MASK(14, 12));
-    dte->gcr3_trp_30_15 = MASK_EXTR(addr, GCR3_MASK(30, 15));
-    dte->gcr3_trp_51_31 = MASK_EXTR(addr, GCR3_MASK(51, 31));
-
-    dte->domain_id = dom_id;
-    dte->glx = glx;
-    dte->gv = gv;
-
-#undef GCR3_MASK
-}
-
-static unsigned int host_domid(struct domain *d, uint64_t g_domid)
-{
-    /* Only support one PPR device in guest for now */
-    return d->domain_id;
-}
-
 static unsigned long get_gfn_from_base_reg(uint64_t base_raw)
 {
     base_raw &= PADDR_MASK;
@@ -146,24 +69,6 @@ static unsigned long guest_iommu_get_table_mfn(struct domain *d,
     return mfn;
 }
 
-static void guest_iommu_enable_dev_table(struct guest_iommu *iommu)
-{
-    uint32_t length_raw = get_field_from_reg_u32(iommu->dev_table.reg_base.lo,
-                                                 IOMMU_DEV_TABLE_SIZE_MASK,
-                                                 IOMMU_DEV_TABLE_SIZE_SHIFT);
-    iommu->dev_table.size = (length_raw + 1) * PAGE_SIZE;
-}
-
-static void guest_iommu_enable_ring_buffer(struct guest_iommu *iommu,
-                                           struct guest_buffer *buffer,
-                                           uint32_t entry_size)
-{
-    uint32_t length_raw = get_field_from_reg_u32(buffer->reg_base.hi,
-                                                 RING_BF_LENGTH_MASK,
-                                                 RING_BF_LENGTH_SHIFT);
-    buffer->size = entry_size << length_raw;
-}
-
 void guest_iommu_add_ppr_log(struct domain *d, u32 entry[])
 {
     uint16_t gdev_id;
@@ -184,7 +89,7 @@ void guest_iommu_add_ppr_log(struct domain *d, u32 entry[])
     if ( tail >= iommu->ppr_log.size || head >= iommu->ppr_log.size )
     {
         AMD_IOMMU_DEBUG("Error: guest iommu ppr log overflows\n");
-        guest_iommu_disable(iommu);
+        iommu->enabled = 0;
         return;
     }
 
@@ -213,668 +118,3 @@ void guest_iommu_add_ppr_log(struct domain *d, u32 entry[])
 
     guest_iommu_deliver_msi(d);
 }
-
-void guest_iommu_add_event_log(struct domain *d, u32 entry[])
-{
-    uint16_t dev_id;
-    unsigned long mfn, tail, head;
-    event_entry_t *log;
-    struct guest_iommu *iommu;
-
-    if ( !is_hvm_domain(d) )
-        return;
-
-    iommu = domain_iommu(d);
-    if ( !iommu )
-        return;
-
-    tail = iommu->event_log.reg_tail.lo;
-    head = iommu->event_log.reg_head.lo;
-
-    if ( tail >= iommu->event_log.size || head >= iommu->event_log.size )
-    {
-        AMD_IOMMU_DEBUG("Error: guest iommu event overflows\n");
-        guest_iommu_disable(iommu);
-        return;
-    }
-
-    mfn = guest_iommu_get_table_mfn(d, reg_to_u64(iommu->event_log.reg_base),
-                                    tail);
-    ASSERT(mfn_valid(_mfn(mfn)));
-
-    log = map_domain_page(_mfn(mfn)) + (tail & ~PAGE_MASK);
-
-    /* re-write physical device id into virtual device id */
-    dev_id = get_guest_bdf(d, iommu_get_devid_from_cmd(entry[0]));
-    iommu_set_devid_to_cmd(&entry[0], dev_id);
-    memcpy(log, entry, sizeof(event_entry_t));
-
-    /* Now shift event log tail pointer */
-    tail += sizeof(event_entry_t);
-    if ( tail >= iommu->event_log.size )
-    {
-        tail = 0;
-        iommu->reg_status.lo |= IOMMU_STATUS_EVENT_LOG_OVERFLOW;
-    }
-
-    iommu->event_log.reg_tail.lo = tail;
-    unmap_domain_page(log);
-
-    guest_iommu_deliver_msi(d);
-}
-
-static int do_complete_ppr_request(struct domain *d, cmd_entry_t *cmd)
-{
-    uint16_t dev_id;
-    struct amd_iommu *iommu;
-
-    dev_id = get_machine_bdf(d, iommu_get_devid_from_cmd(cmd->data[0]));
-    iommu = find_iommu_for_device(0, dev_id);
-
-    if ( !iommu )
-    {
-        AMD_IOMMU_DEBUG("%s: Fail to find iommu for bdf %x\n",
-                        __func__, dev_id);
-        return -ENODEV;
-    }
-
-    /* replace virtual device id into physical */
-    iommu_set_devid_to_cmd(&cmd->data[0], dev_id);
-    amd_iommu_send_guest_cmd(iommu, cmd->data);
-
-    return 0;
-}
-
-static int do_invalidate_pages(struct domain *d, cmd_entry_t *cmd)
-{
-    uint16_t gdom_id, hdom_id;
-    struct amd_iommu *iommu = NULL;
-
-    gdom_id = get_field_from_reg_u32(cmd->data[1],
-                                    IOMMU_INV_IOMMU_PAGES_DOMAIN_ID_MASK,
-                                    IOMMU_INV_IOMMU_PAGES_DOMAIN_ID_SHIFT);
-
-    hdom_id = host_domid(d, gdom_id);
-    set_field_in_reg_u32(hdom_id, cmd->data[1],
-                         IOMMU_INV_IOMMU_PAGES_DOMAIN_ID_MASK,
-                         IOMMU_INV_IOMMU_PAGES_DOMAIN_ID_SHIFT, &cmd->data[1]);
-
-    for_each_amd_iommu ( iommu )
-        amd_iommu_send_guest_cmd(iommu, cmd->data);
-
-    return 0;
-}
-
-static int do_invalidate_all(struct domain *d, cmd_entry_t *cmd)
-{
-    struct amd_iommu *iommu = NULL;
-
-    for_each_amd_iommu ( iommu )
-        amd_iommu_flush_all_pages(d);
-
-    return 0;
-}
-
-static int do_invalidate_iotlb_pages(struct domain *d, cmd_entry_t *cmd)
-{
-    struct amd_iommu *iommu;
-    uint16_t dev_id;
-
-    dev_id = get_machine_bdf(d, iommu_get_devid_from_cmd(cmd->data[0]));
-
-    iommu = find_iommu_for_device(0, dev_id);
-    if ( !iommu )
-    {
-        AMD_IOMMU_DEBUG("%s: Fail to find iommu for bdf %x\n",
-                         __func__, dev_id);
-        return -ENODEV;
-    }
-
-    iommu_set_devid_to_cmd(&cmd->data[0], dev_id);
-    amd_iommu_send_guest_cmd(iommu, cmd->data);
-
-    return 0;
-}
-
-static int do_completion_wait(struct domain *d, cmd_entry_t *cmd)
-{
-    bool com_wait_int, i, s;
-    struct guest_iommu *iommu;
-    unsigned long gfn;
-    p2m_type_t p2mt;
-
-    iommu = domain_iommu(d);
-
-    i = cmd->data[0] & IOMMU_COMP_WAIT_I_FLAG_MASK;
-    s = cmd->data[0] & IOMMU_COMP_WAIT_S_FLAG_MASK;
-
-    if ( i )
-        iommu->reg_status.lo |= IOMMU_STATUS_COMP_WAIT_INT;
-
-    if ( s )
-    {
-        uint64_t gaddr_lo, gaddr_hi, gaddr_64, data;
-        void *vaddr;
-
-        data = (uint64_t)cmd->data[3] << 32 | cmd->data[2];
-        gaddr_lo = get_field_from_reg_u32(cmd->data[0],
-                                          IOMMU_COMP_WAIT_ADDR_LOW_MASK,
-                                          IOMMU_COMP_WAIT_ADDR_LOW_SHIFT);
-        gaddr_hi = get_field_from_reg_u32(cmd->data[1],
-                                          IOMMU_COMP_WAIT_ADDR_HIGH_MASK,
-                                          IOMMU_COMP_WAIT_ADDR_HIGH_SHIFT);
-
-        gaddr_64 = (gaddr_hi << 32) | (gaddr_lo << 3);
-
-        gfn = gaddr_64 >> PAGE_SHIFT;
-        vaddr = map_domain_page(get_gfn(d, gfn ,&p2mt));
-        put_gfn(d, gfn);
-
-        write_u64_atomic((uint64_t *)(vaddr + (gaddr_64 & (PAGE_SIZE-1))),
-                         data);
-        unmap_domain_page(vaddr);
-    }
-
-    com_wait_int = iommu->reg_status.lo & IOMMU_STATUS_COMP_WAIT_INT;
-
-    if ( iommu->reg_ctrl.com_wait_int_en && com_wait_int )
-        guest_iommu_deliver_msi(d);
-
-    return 0;
-}
-
-static int do_invalidate_dte(struct domain *d, cmd_entry_t *cmd)
-{
-    uint16_t gbdf, mbdf, req_id, gdom_id, hdom_id, prev_domid;
-    struct amd_iommu_dte *gdte, *mdte, *dte_base;
-    struct amd_iommu *iommu = NULL;
-    struct guest_iommu *g_iommu;
-    uint64_t gcr3_gfn, gcr3_mfn;
-    uint8_t glx, gv;
-    unsigned long dte_mfn, flags;
-    p2m_type_t p2mt;
-
-    g_iommu = domain_iommu(d);
-    gbdf = iommu_get_devid_from_cmd(cmd->data[0]);
-    mbdf = get_machine_bdf(d, gbdf);
-
-    /* Guest can only update DTEs for its passthru devices */
-    if ( mbdf == 0 || gbdf == 0 )
-        return 0;
-
-    /* Sometimes guest invalidates devices from non-exists dtes */
-    if ( (gbdf * sizeof(struct amd_iommu_dte)) > g_iommu->dev_table.size )
-        return 0;
-
-    dte_mfn = guest_iommu_get_table_mfn(d,
-                                        reg_to_u64(g_iommu->dev_table.reg_base),
-                                        sizeof(struct amd_iommu_dte) * gbdf);
-    ASSERT(mfn_valid(_mfn(dte_mfn)));
-
-    /* Read guest dte information */
-    dte_base = map_domain_page(_mfn(dte_mfn));
-
-    gdte = &dte_base[gbdf % (PAGE_SIZE / sizeof(struct amd_iommu_dte))];
-
-    gdom_id = gdte->domain_id;
-    gcr3_gfn = dte_get_gcr3_table(gdte) >> PAGE_SHIFT;
-    glx = gdte->glx;
-    gv = gdte->gv;
-
-    unmap_domain_page(dte_base);
-
-    /* Do not update host dte before gcr3 has been set */
-    if ( gcr3_gfn == 0 )
-        return 0;
-
-    gcr3_mfn = mfn_x(get_gfn(d, gcr3_gfn, &p2mt));
-    put_gfn(d, gcr3_gfn);
-
-    ASSERT(mfn_valid(_mfn(gcr3_mfn)));
-
-    iommu = find_iommu_for_device(0, mbdf);
-    if ( !iommu )
-    {
-        AMD_IOMMU_DEBUG("%s: Fail to find iommu for bdf %x!\n",
-                        __func__, mbdf);
-        return -ENODEV;
-    }
-
-    /* Setup host device entry */
-    hdom_id = host_domid(d, gdom_id);
-    req_id = get_dma_requestor_id(iommu->seg, mbdf);
-    dte_base = iommu->dev_table.buffer;
-    mdte = &dte_base[req_id];
-    prev_domid = mdte->domain_id;
-
-    spin_lock_irqsave(&iommu->lock, flags);
-    dte_set_gcr3_table(mdte, hdom_id, gcr3_mfn << PAGE_SHIFT, gv, glx);
-
-    spin_unlock_irqrestore(&iommu->lock, flags);
-
-    amd_iommu_flush_device(iommu, req_id, prev_domid);
-
-    return 0;
-}
-
-static void cf_check guest_iommu_process_command(void *data)
-{
-    unsigned long opcode, tail, head, cmd_mfn;
-    cmd_entry_t *cmd;
-    struct domain *d = data;
-    struct guest_iommu *iommu;
-
-    iommu = domain_iommu(d);
-
-    if ( !iommu->enabled )
-        return;
-
-    head = iommu->cmd_buffer.reg_head.lo;
-    tail = iommu->cmd_buffer.reg_tail.lo;
-
-    /* Tail pointer is rolled over by guest driver, value outside
-     * cmd_buffer_entries cause iommu disabled
-     */
-
-    if ( tail >= iommu->cmd_buffer.size || head >= iommu->cmd_buffer.size )
-    {
-        AMD_IOMMU_DEBUG("Error: guest iommu cmd buffer overflows\n");
-        guest_iommu_disable(iommu);
-        return;
-    }
-
-    while ( head != tail )
-    {
-        int ret = 0;
-
-        cmd_mfn = guest_iommu_get_table_mfn(d,
-                                            reg_to_u64(iommu->cmd_buffer.reg_base),
-                                            head);
-        ASSERT(mfn_valid(_mfn(cmd_mfn)));
-
-        cmd = map_domain_page(_mfn(cmd_mfn)) + (head & ~PAGE_MASK);
-
-        opcode = get_field_from_reg_u32(cmd->data[1],
-                                        IOMMU_CMD_OPCODE_MASK,
-                                        IOMMU_CMD_OPCODE_SHIFT);
-        switch ( opcode )
-        {
-        case IOMMU_CMD_COMPLETION_WAIT:
-            ret = do_completion_wait(d, cmd);
-            break;
-        case IOMMU_CMD_INVALIDATE_DEVTAB_ENTRY:
-            ret = do_invalidate_dte(d, cmd);
-            break;
-        case IOMMU_CMD_INVALIDATE_IOMMU_PAGES:
-            ret = do_invalidate_pages(d, cmd);
-            break;
-        case IOMMU_CMD_INVALIDATE_IOTLB_PAGES:
-            ret = do_invalidate_iotlb_pages(d, cmd);
-            break;
-        case IOMMU_CMD_INVALIDATE_INT_TABLE:
-            break;
-        case IOMMU_CMD_COMPLETE_PPR_REQUEST:
-            ret = do_complete_ppr_request(d, cmd);
-            break;
-        case IOMMU_CMD_INVALIDATE_IOMMU_ALL:
-            ret = do_invalidate_all(d, cmd);
-            break;
-        default:
-            AMD_IOMMU_DEBUG("CMD: Unknown command cmd_type = %lx "
-                            "head = %ld\n", opcode, head);
-            break;
-        }
-
-        unmap_domain_page(cmd);
-        head += sizeof(cmd_entry_t);
-        if ( head >= iommu->cmd_buffer.size )
-            head = 0;
-        if ( ret )
-            guest_iommu_disable(iommu);
-    }
-
-    /* Now shift cmd buffer head pointer */
-    iommu->cmd_buffer.reg_head.lo = head;
-    return;
-}
-
-static int guest_iommu_write_ctrl(struct guest_iommu *iommu, uint64_t val)
-{
-    union amd_iommu_control newctrl = { .raw = val };
-
-    if ( newctrl.iommu_en )
-    {
-        guest_iommu_enable(iommu);
-        guest_iommu_enable_dev_table(iommu);
-    }
-
-    if ( newctrl.iommu_en && newctrl.cmd_buf_en )
-    {
-        guest_iommu_enable_ring_buffer(iommu, &iommu->cmd_buffer,
-                                       sizeof(cmd_entry_t));
-        /* Enable iommu command processing */
-        tasklet_schedule(&iommu->cmd_buffer_tasklet);
-    }
-
-    if ( newctrl.iommu_en && newctrl.event_log_en )
-    {
-        guest_iommu_enable_ring_buffer(iommu, &iommu->event_log,
-                                       sizeof(event_entry_t));
-        iommu->reg_status.lo |=  IOMMU_STATUS_EVENT_LOG_RUN;
-        iommu->reg_status.lo &= ~IOMMU_STATUS_EVENT_LOG_OVERFLOW;
-    }
-
-    if ( newctrl.iommu_en && newctrl.ppr_en && newctrl.ppr_log_en )
-    {
-        guest_iommu_enable_ring_buffer(iommu, &iommu->ppr_log,
-                                       sizeof(ppr_entry_t));
-        iommu->reg_status.lo |=  IOMMU_STATUS_PPR_LOG_RUN;
-        iommu->reg_status.lo &= ~IOMMU_STATUS_PPR_LOG_OVERFLOW;
-    }
-
-    if ( newctrl.iommu_en && iommu->reg_ctrl.cmd_buf_en &&
-         !newctrl.cmd_buf_en )
-    {
-        /* Disable iommu command processing */
-        tasklet_kill(&iommu->cmd_buffer_tasklet);
-    }
-
-    if ( iommu->reg_ctrl.event_log_en && !newctrl.event_log_en )
-        iommu->reg_status.lo &= ~IOMMU_STATUS_EVENT_LOG_RUN;
-
-    if ( iommu->reg_ctrl.iommu_en && !newctrl.iommu_en )
-        guest_iommu_disable(iommu);
-
-    iommu->reg_ctrl = newctrl;
-
-    return 0;
-}
-
-static uint64_t iommu_mmio_read64(struct guest_iommu *iommu,
-                                  unsigned long offset)
-{
-    uint64_t val;
-
-    switch ( offset )
-    {
-    case IOMMU_DEV_TABLE_BASE_LOW_OFFSET:
-        val = reg_to_u64(iommu->dev_table.reg_base);
-        break;
-    case IOMMU_CMD_BUFFER_BASE_LOW_OFFSET:
-        val = reg_to_u64(iommu->cmd_buffer.reg_base);
-        break;
-    case IOMMU_EVENT_LOG_BASE_LOW_OFFSET:
-        val = reg_to_u64(iommu->event_log.reg_base);
-        break;
-    case IOMMU_PPR_LOG_BASE_LOW_OFFSET:
-        val = reg_to_u64(iommu->ppr_log.reg_base);
-        break;
-    case IOMMU_CMD_BUFFER_HEAD_OFFSET:
-        val = reg_to_u64(iommu->cmd_buffer.reg_head);
-        break;
-    case IOMMU_CMD_BUFFER_TAIL_OFFSET:
-        val = reg_to_u64(iommu->cmd_buffer.reg_tail);
-        break;
-    case IOMMU_EVENT_LOG_HEAD_OFFSET:
-        val = reg_to_u64(iommu->event_log.reg_head);
-        break;
-    case IOMMU_EVENT_LOG_TAIL_OFFSET:
-        val = reg_to_u64(iommu->event_log.reg_tail);
-        break;
-    case IOMMU_PPR_LOG_HEAD_OFFSET:
-        val = reg_to_u64(iommu->ppr_log.reg_head);
-        break;
-    case IOMMU_PPR_LOG_TAIL_OFFSET:
-        val = reg_to_u64(iommu->ppr_log.reg_tail);
-        break;
-    case IOMMU_CONTROL_MMIO_OFFSET:
-        val = iommu->reg_ctrl.raw;
-        break;
-    case IOMMU_STATUS_MMIO_OFFSET:
-        val = reg_to_u64(iommu->reg_status);
-        break;
-    case IOMMU_EXT_FEATURE_MMIO_OFFSET:
-        val = iommu->reg_ext_feature.raw;
-        break;
-
-    default:
-        AMD_IOMMU_DEBUG("Guest reads unknown mmio offset = %lx\n", offset);
-        val = 0;
-        break;
-    }
-
-    return val;
-}
-
-static int cf_check guest_iommu_mmio_read(
-    struct vcpu *v, unsigned long addr, unsigned int len, unsigned long *pval)
-{
-    struct guest_iommu *iommu = vcpu_iommu(v);
-    unsigned long offset;
-    uint64_t val;
-    uint32_t mmio, shift;
-    uint64_t mask = 0;
-
-    offset = addr - iommu->mmio_base;
-
-    if ( unlikely((offset & (len - 1 )) || (len > 8)) )
-    {
-        AMD_IOMMU_DEBUG("iommu mmio read access is not aligned:"
-                        " offset = %lx, len = %x\n", offset, len);
-        return X86EMUL_UNHANDLEABLE;
-    }
-
-    mask = (len == 8) ? ~0ULL : (1ULL << (len * 8)) - 1;
-    shift = (offset & 7u) * 8;
-
-    /* mmio access is always aligned on 8-byte boundary */
-    mmio = offset & (~7u);
-
-    spin_lock(&iommu->lock);
-    val = iommu_mmio_read64(iommu, mmio);
-    spin_unlock(&iommu->lock);
-
-    *pval = (val >> shift ) & mask;
-
-    return X86EMUL_OKAY;
-}
-
-static void guest_iommu_mmio_write64(struct guest_iommu *iommu,
-                                    unsigned long offset, uint64_t val)
-{
-    switch ( offset )
-    {
-    case IOMMU_DEV_TABLE_BASE_LOW_OFFSET:
-        u64_to_reg(&iommu->dev_table.reg_base, val);
-        break;
-    case IOMMU_CMD_BUFFER_BASE_LOW_OFFSET:
-        u64_to_reg(&iommu->cmd_buffer.reg_base, val);
-        break;
-    case IOMMU_EVENT_LOG_BASE_LOW_OFFSET:
-        u64_to_reg(&iommu->event_log.reg_base, val);
-        break;
-    case IOMMU_PPR_LOG_BASE_LOW_OFFSET:
-        u64_to_reg(&iommu->ppr_log.reg_base, val);
-        break;
-    case IOMMU_CONTROL_MMIO_OFFSET:
-        guest_iommu_write_ctrl(iommu, val);
-        break;
-    case IOMMU_CMD_BUFFER_HEAD_OFFSET:
-        iommu->cmd_buffer.reg_head.lo = val & IOMMU_RING_BUFFER_PTR_MASK;
-        break;
-    case IOMMU_CMD_BUFFER_TAIL_OFFSET:
-        iommu->cmd_buffer.reg_tail.lo = val & IOMMU_RING_BUFFER_PTR_MASK;
-        tasklet_schedule(&iommu->cmd_buffer_tasklet);
-        break;
-    case IOMMU_EVENT_LOG_HEAD_OFFSET:
-        iommu->event_log.reg_head.lo = val & IOMMU_RING_BUFFER_PTR_MASK;
-        break;
-    case IOMMU_EVENT_LOG_TAIL_OFFSET:
-        iommu->event_log.reg_tail.lo = val & IOMMU_RING_BUFFER_PTR_MASK;
-        break;
-    case IOMMU_PPR_LOG_HEAD_OFFSET:
-        iommu->ppr_log.reg_head.lo = val & IOMMU_RING_BUFFER_PTR_MASK;
-        break;
-    case IOMMU_PPR_LOG_TAIL_OFFSET:
-        iommu->ppr_log.reg_tail.lo = val & IOMMU_RING_BUFFER_PTR_MASK;
-        break;
-    case IOMMU_STATUS_MMIO_OFFSET:
-        val &= IOMMU_STATUS_EVENT_LOG_OVERFLOW |
-               IOMMU_STATUS_EVENT_LOG_INT |
-               IOMMU_STATUS_COMP_WAIT_INT |
-               IOMMU_STATUS_PPR_LOG_OVERFLOW |
-               IOMMU_STATUS_PPR_LOG_INT |
-               IOMMU_STATUS_GAPIC_LOG_OVERFLOW |
-               IOMMU_STATUS_GAPIC_LOG_INT;
-        u64_to_reg(&iommu->reg_status, reg_to_u64(iommu->reg_status) & ~val);
-        break;
-
-    default:
-        AMD_IOMMU_DEBUG("guest writes unknown mmio offset = %lx,"
-                        " val = %" PRIx64 "\n", offset, val);
-        break;
-    }
-}
-
-static int cf_check guest_iommu_mmio_write(
-    struct vcpu *v, unsigned long addr, unsigned int len, unsigned long val)
-{
-    struct guest_iommu *iommu = vcpu_iommu(v);
-    unsigned long offset;
-    uint64_t reg_old, mmio;
-    uint32_t shift;
-    uint64_t mask = 0;
-
-    offset = addr - iommu->mmio_base;
-
-    if ( unlikely((offset & (len - 1)) || (len > 8)) )
-    {
-        AMD_IOMMU_DEBUG("iommu mmio write access is not aligned:"
-                        " offset = %lx, len = %x\n", offset, len);
-        return X86EMUL_UNHANDLEABLE;
-    }
-
-    mask = (len == 8) ? ~0ULL : (1ULL << (len * 8)) - 1;
-    shift = (offset & 7) * 8;
-
-    /* mmio access is always aligned on 8-byte boundary */
-    mmio = offset & ~7;
-
-    spin_lock(&iommu->lock);
-
-    reg_old = iommu_mmio_read64(iommu, mmio);
-    reg_old &= ~(mask << shift);
-    val = reg_old | ((val & mask) << shift);
-    guest_iommu_mmio_write64(iommu, mmio, val);
-
-    spin_unlock(&iommu->lock);
-
-    return X86EMUL_OKAY;
-}
-
-int guest_iommu_set_base(struct domain *d, uint64_t base)
-{
-    p2m_type_t t;
-    struct guest_iommu *iommu = domain_iommu(d);
-
-    if ( !iommu )
-        return -EACCES;
-
-    iommu->mmio_base = base;
-    base >>= PAGE_SHIFT;
-
-    for ( int i = 0; i < IOMMU_MMIO_PAGE_NR; i++ )
-    {
-        unsigned long gfn = base + i;
-
-        get_gfn_query(d, gfn, &t);
-        p2m_change_type_one(d, gfn, t, p2m_mmio_dm);
-        put_gfn(d, gfn);
-    }
-
-    return 0;
-}
-
-/* Initialize mmio read only bits */
-static void guest_iommu_reg_init(struct guest_iommu *iommu)
-{
-    union amd_iommu_ext_features ef = {
-        /* Support prefetch */
-        .flds.pref_sup = 1,
-        /* Support PPR log */
-        .flds.ppr_sup = 1,
-        /* Support guest translation */
-        .flds.gt_sup = 1,
-        /* Support invalidate all command */
-        .flds.ia_sup = 1,
-        /* Host translation size has 6 levels */
-        .flds.hats = HOST_ADDRESS_SIZE_6_LEVEL,
-        /* Guest translation size has 6 levels */
-        .flds.gats = GUEST_ADDRESS_SIZE_6_LEVEL,
-        /* Single level gCR3 */
-        .flds.glx_sup = GUEST_CR3_1_LEVEL,
-        /* 9 bit PASID */
-        .flds.pas_max = PASMAX_9_bit,
-    };
-
-    iommu->reg_ext_feature = ef;
-}
-
-static int cf_check guest_iommu_mmio_range(struct vcpu *v, unsigned long addr)
-{
-    struct guest_iommu *iommu = vcpu_iommu(v);
-
-    return iommu && addr >= iommu->mmio_base &&
-           addr < iommu->mmio_base + IOMMU_MMIO_SIZE;
-}
-
-static const struct hvm_mmio_ops iommu_mmio_ops = {
-    .check = guest_iommu_mmio_range,
-    .read = guest_iommu_mmio_read,
-    .write = guest_iommu_mmio_write
-};
-
-/* Domain specific initialization */
-int guest_iommu_init(struct domain* d)
-{
-    struct guest_iommu *iommu;
-    struct domain_iommu *hd = dom_iommu(d);
-
-    if ( !is_hvm_domain(d) || !is_iommu_enabled(d) || !iommuv2_enabled ||
-         !has_viommu(d) )
-        return 0;
-
-    iommu = xzalloc(struct guest_iommu);
-    if ( !iommu )
-    {
-        AMD_IOMMU_DEBUG("Error allocating guest iommu structure.\n");
-        return 1;
-    }
-
-    guest_iommu_reg_init(iommu);
-    iommu->mmio_base = ~0ULL;
-    iommu->domain = d;
-    hd->arch.amd.g_iommu = iommu;
-
-    tasklet_init(&iommu->cmd_buffer_tasklet, guest_iommu_process_command, d);
-
-    spin_lock_init(&iommu->lock);
-
-    register_mmio_handler(d, &iommu_mmio_ops);
-
-    return 0;
-}
-
-void guest_iommu_destroy(struct domain *d)
-{
-    struct guest_iommu *iommu;
-
-    iommu = domain_iommu(d);
-    if ( !iommu )
-        return;
-
-    tasklet_kill(&iommu->cmd_buffer_tasklet);
-    xfree(iommu);
-
-    dom_iommu(d)->arch.amd.g_iommu = NULL;
-}
-- 
2.34.1


From xen-devel-bounces@lists.xenproject.org Fri Mar 15 11:18:38 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 11:18:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693802.1082380 (Exim 4.92)
	(envelope-from )
	id 1rl5a6-00054N-7P; Fri, 15 Mar 2024 11:18:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693802.1082380; Fri, 15 Mar 2024 11:18:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl5a6-00054G-4u; Fri, 15 Mar 2024 11:18:34 +0000
Received: by outflank-mailman (input) for mailman id 693802;
 Fri, 15 Mar 2024 11:18:33 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rl5I7-0000aQ-Mk
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 10:59:59 +0000
Received: from mail-oo1-xc2f.google.com (mail-oo1-xc2f.google.com
 [2607:f8b0:4864:20::c2f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 29c19788-e2bb-11ee-afdd-a90da7624cb6;
 Fri, 15 Mar 2024 11:59:59 +0100 (CET)
Received: by mail-oo1-xc2f.google.com with SMTP id
 006d021491bc7-5a4790ff899so234563eaf.0
 for ; Fri, 15 Mar 2024 03:59:58 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 29c19788-e2bb-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1710500397; x=1711105197; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Jd9T79YYURQmVc9LQO/y4cA05WDxZJjl6Yw0m2Srx00=;
        b=dEXjQIaG6qdj4ot3JdDTp7kEzIuAvNQ512itNRSDdGJsNqb2LhVh+VBvg8z6LCt/qk
         R+j2pYnq5tFkHUcGVysEQMqr5vEvVPRmml3wYSC/iqTA+wiXcCbkCis6nJhnIP4idSnn
         HwH14LT+C4LUMZ2YpcgtvDZEg75780o/Msteo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710500397; x=1711105197;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=Jd9T79YYURQmVc9LQO/y4cA05WDxZJjl6Yw0m2Srx00=;
        b=iQRvyE3ueo5dgGNK0nPX+Di6hOP6Qv/56uSxMyTXBJB5LMDJuQp8ugK3wfA10mxXI1
         GXNghtVtiuB4UV7kfKHRwUw0XQgwV+ZhyKDLMLdgOQ1v4osda4tb3Zm3xsJ8gkJ3svyv
         WySyjENE0BpovHMK9BDrQVdTGDEw41h7sjpfPZpkEWxwXr0lYZ3GajCCn9ntzUAb0RLo
         ah0CgHUxUBTbqFwQS9QIS9RxxXv7VNWdl7at73sQ0WHrErXxxI8HL9kU0TZ2FWuYcskw
         Q02gvH8ecDqiqNjqklKs4/czmVTfh7E44axxbBrEZFXazWSXoHmJ7gTiM3mKyT6uq3fd
         OwYA==
X-Forwarded-Encrypted: i=1; AJvYcCXi4d2nLnBLS/sEio/NKx72vsxqj/l5mvOCdsQ+llpRlHTj06bqoyahFBu0GHJv4mQ5S0aVMfZxid69a0iWyV7wO7XkAukIbpFuyVE8Xxo=
X-Gm-Message-State: AOJu0YzWYgVDuqfZ1+PeMfbCgMgJ4ptKxW2PwX4p9/m7kYNBKz+wzOu7
	cqRNb7N0EJBZLAjeiSnyX0Nz6q9Azuf2wLGx5GdqBaLUR6Az7Nya7c6ZGUsZkOSzh9MjSmjSNKJ
	V6http83AQC7s8kBdGOEAPASxh+Pd7A9ik2rKV8rnwjoUNPDLh5Y=
X-Google-Smtp-Source: AGHT+IFmoLot8oumfNqwdoZw1nIoU6wewM4fjGNGBZHxxD232wRZspJQoBwBuKAmtDBf2hCLr7vUsKsxQcyAxtDcb6A=
X-Received: by 2002:a05:6871:340d:b0:222:6b21:3816 with SMTP id
 nh13-20020a056871340d00b002226b213816mr1627435oac.23.1710500397515; Fri, 15
 Mar 2024 03:59:57 -0700 (PDT)
MIME-Version: 1.0
References: 
 <5a8f90d6-6502-4d93-9fd7-45fea0ede24a@suse.com> 
 
  
 
In-Reply-To: 
From: George Dunlap 
Date: Fri, 15 Mar 2024 10:59:46 +0000
Message-ID: 
Subject: Re: [PATCH] do_multicall and MISRA Rule 8.3\
To: Jan Beulich 
Cc: Stefano Stabellini , federico.serafini@bugseng.com, 
	Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
	Bertrand Marquis , xen-devel@lists.xenproject.org, 
	michal.orzel@amd.com, julien@xen.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 15, 2024 at 6:54=E2=80=AFAM Jan Beulich  wro=
te:
>
> On 15.03.2024 01:21, Stefano Stabellini wrote:
> > On Mon, 11 Mar 2024, Julien Grall wrote:
> >> On 11/03/2024 11:32, George Dunlap wrote:
> >>> On Sat, Mar 9, 2024 at 1:59=E2=80=AFAM Stefano Stabellini
> >>>  wrote:
> >>>>
> >>>> I would like to resurrect this thread and ask other opinions.
> >>>>
> >>>>
> >>>> On Thu, 23 Nov 2023, Jan Beulich wrote:
> >>>>> On 22.11.2023 22:46, Stefano Stabellini wrote:
> >>>>>> Two out of three do_multicall definitions/declarations use uint32_=
t as
> >>>>>> type for the "nr_calls" parameters. Change the third one to be
> >>>>>> consistent with the other two.
> >>>>>>
> >>>>>> Link:
> >>>>>> https://lore.kernel.org/xen-devel/7e3abd4c0ef5127a07a60de1bf090a8a=
efac8e5c.1692717906.git.federico.serafini@bugseng.com/
> >>>>>> Link:
> >>>>>> https://lore.kernel.org/xen-devel/alpine.DEB.2.22.394.230825150243=
0.6458@ubuntu-linux-20-04-desktop/
> >>>>>> Signed-off-by: Stefano Stabellini 
> >>>>>> ---
> >>>>>> Note that a previous discussion showed disagreement between
> >>>>>> maintainers
> >>>>>> on this topic. The source of disagreements are that we don't want =
to
> >>>>>> change a guest-visible ABI and we haven't properly documented how =
to
> >>>>>> use
> >>>>>> types for guest ABIs.
> >>>>>>
> >>>>>> As an example, fixed-width types have the advantage of being expli=
cit
> >>>>>> about their size but sometimes register-size types are required (e=
.g.
> >>>>>> unsigned long). The C specification says little about the size of
> >>>>>> unsigned long and today, and we even use unsigned int in guest ABI=
s
> >>>>>> without specifying the expected width of unsigned int on the vario=
us
> >>>>>> arches. As Jan pointed out, in Xen we assume sizeof(int) >=3D 4, b=
ut
> >>>>>> that's not written anywhere as far as I can tell.
> >>>>>>
> >>>>>> I think the appropriate solution would be to document properly our
> >>>>>> expectations of both fixed-width and non-fixed-width types, and ho=
w to
> >>>>>> use them for guest-visible ABIs.
> >>>>>>
> >>>>>> In this patch I used uint32_t for a couple of reasons:
> >>>>>> - until we have better documentation, I feel more confident in usi=
ng
> >>>>>>    explicitly-sized integers in guest-visible ABIs
> >>>>>
> >>>>> I disagree with this way of looking at it. Guests don't invoke thes=
e
> >>>>> functions directly, and our assembly code sitting in between alread=
y is
> >>>>> expected to (and does) guarantee that (in the case here) unsigned i=
nt
> >>>>> would be okay to use (as would be unsigned long, but at least on x8=
6
> >>>>> that's slightly less efficient), in line with what ./CODING_STYLE s=
ays.
> >>>>>
> >>>>> Otoh structure definitions in the public interface of course need t=
o
> >>>>> use fixed with types (and still doesn't properly do so in a few cas=
es).
> >>>
> >>> You didn't address the other argument, which was that all the other
> >>> definitions have uint32_t; in particular,
> >>> common/multicall.c:do_multicall() takes uint32_t.  Surely that should
> >>> match the non-compat definition in include/hypercall-defs.c?
> >>>
> >>> Whether they should both be `unsigned int` or `uint32_t` I don't
> >>> really feel like I have a good enough grasp of the situation to form =
a
> >>> strong opinion.
> >>
> >> FWIW +1. We at least need some consistency.
> >
> > Consistency is my top concern. Let's put the "unsigned int" vs
> > "uint32_t" argument aside.
> >
> > do_multicall is not consistent with itself. We need
> > hypercall-defs.c:do_multicall and multicall.c:do_multicall to match.
> >
> > Option1) We can change hypercall-defs.c:do_multicall to use uint32_t.
> >
> > Option2) Or we can change multicall.c:do_multicall to use unsigned int.
> >
> > I went with Option1. Andrew expressed his strong preference toward
> > Option1 in the past. George seems to prefer Option1.
> >
> > Jan, can you accept Option1 and move on?
>
> Counter question: Why do we have the opposite of what you all want stated
> in ./CODING_STYLE?

Indeed, that's what I wanted to ask at the committer's meeting on
Wednesday, but we ran out of time.

> Looking at the commit, it was actually George who ack-ed
> it. I can accept option 1 if ./CODING_STYLE is first changed / amended.

That change was added in 2019, but I certainly remember discussions
along these lines going on long before then.  Presumably there was a
long unwritten tradition of avoiding explicitly-sized types unless
necessary, and someone said, "that's not in the CODING_STYLE", and so
you added it.  Having the expectation written down is certainly worth
having, even if I don't personally care that much about it.

I will note that when I gave my Ack, I said that it probably wanted an
Ack from then ARM maintainers as well [1]; that doesn't seem to have
happened, so there's an argument that it was checked in improperly.

The coding style says, "Fixed width types should only be used when a
fixed width quantity is meant".  In the discussion on v2 of the patch,
I went through some uses of uint32_t, and regarding instances "Inside
headers for public interfaces", you said [2]:

> Here fixed width types are definitely the right choice.

It sounds like Andy and Stefano feel like this is a situation where "a
fixed width quantity is meant"; absent any further guidance from the
CODING_STYLE about when fixed widths should or should not be used, I
don't think this change would be a violation of CODING_STYLE.

 -George

[1] https://lore.kernel.org/xen-devel/0a8031c0-b668-eeb1-a9a2-659b52aaf98d@=
citrix.com/
[2] https://lore.kernel.org/xen-devel/72580391-d34e-aaf9-2e41-ab1df5967408@=
suse.com/


From xen-devel-bounces@lists.xenproject.org Fri Mar 15 11:19:07 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 11:19:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693805.1082391 (Exim 4.92)
	(envelope-from )
	id 1rl5ad-0005j4-H2; Fri, 15 Mar 2024 11:19:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693805.1082391; Fri, 15 Mar 2024 11:19:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl5ad-0005ix-D6; Fri, 15 Mar 2024 11:19:07 +0000
Received: by outflank-mailman (input) for mailman id 693805;
 Fri, 15 Mar 2024 11:19:06 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rl5ac-0005hc-L2
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 11:19:06 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d596e4f3-e2bd-11ee-afdd-a90da7624cb6;
 Fri, 15 Mar 2024 12:19:05 +0100 (CET)
Received: from [172.20.10.8] (unknown [78.211.227.3])
 by support.bugseng.com (Postfix) with ESMTPSA id A21404EE073C;
 Fri, 15 Mar 2024 12:19:04 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d596e4f3-e2bd-11ee-afdd-a90da7624cb6
Message-ID: <4a6f8d2a-9ab7-447c-b9cb-c19e7167174f@bugseng.com>
Date: Fri, 15 Mar 2024 12:19:02 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: x86/bitops and MISRA C:2012 Rule 5.5
Content-Language: en-US, it
To: Andrew Cooper , xen-devel@lists.xenproject.org
Cc: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Wei Liu 
References: <42d630c9-e311-4e17-9fae-e14ec81a339e@bugseng.com>
 <9958b4cc-a6a5-4370-b87e-3e2facf7ee5f@citrix.com>
From: Federico Serafini 
Organization: BUGSENG
In-Reply-To: <9958b4cc-a6a5-4370-b87e-3e2facf7ee5f@citrix.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 15/03/24 12:13, Andrew Cooper wrote:
> On 15/03/2024 11:07 am, Federico Serafini wrote:
>> Hello everyone,
>>
>> there are violations of Rule 5.5 ("Identifiers shall be distinct
>> from macro names") in xen/arch/x86/include/asm/bitops.h.
>> You can see them at [1].
>>
>> Do you agree to distinguish between function-like macros and
>> inline functions by adding a suffix to the functions?
> 
> Please see the other bitops thread, which you're also CC'd on.
> 
> Although it's not got to these functions yet, this is going to be fixed
> by having set_bit() be common, and arch_set_bit() be the per-arch
> implemenation.
> 
> Neither _unsafe nor _nocheck are remotely appropriate here.

Thanks, I missed it.

-- 
Federico Serafini, M.Sc.

Software Engineer, BUGSENG (http://bugseng.com)


From xen-devel-bounces@lists.xenproject.org Fri Mar 15 11:20:10 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 11:20:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693809.1082401 (Exim 4.92)
	(envelope-from )
	id 1rl5bc-0007UI-Pz; Fri, 15 Mar 2024 11:20:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693809.1082401; Fri, 15 Mar 2024 11:20:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl5bc-0007UB-MG; Fri, 15 Mar 2024 11:20:08 +0000
Received: by outflank-mailman (input) for mailman id 693809;
 Fri, 15 Mar 2024 11:20:06 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rl5ba-0007Nv-Sg
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 11:20:06 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f996eb03-e2bd-11ee-afdd-a90da7624cb6;
 Fri, 15 Mar 2024 12:20:06 +0100 (CET)
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 by support.bugseng.com (Postfix) with ESMTPA id CAD784EE073C;
 Fri, 15 Mar 2024 12:20:05 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f996eb03-e2bd-11ee-afdd-a90da7624cb6
MIME-Version: 1.0
Date: Fri, 15 Mar 2024 12:20:05 +0100
From: Nicola Vetrini 
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: Simone Ballarin ,
 xen-devel@lists.xenproject.org, consulting@bugseng.com, Maria Celeste
 Cesario , Jan Beulich
 , Andrew Cooper , Wei Liu
 , Kevin Tian 
Subject: Re: [PATCH v2 1/2] x86/IOMMU: address violations of MISRA C:2012 Rule
 14.4
In-Reply-To: 
References: 
 <746a33fff1386b2e76657b5f7cfb31f3b117a1fe.1702310368.git.maria.celeste.cesario@bugseng.com>
 
Message-ID: 
X-Sender: nicola.vetrini@bugseng.com
Organization: BUGSENG s.r.l.
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit

On 2024-03-12 12:01, Roger Pau Monné wrote:
> On Wed, Dec 13, 2023 at 05:10:50PM +0100, Simone Ballarin wrote:
>> From: Maria Celeste Cesario 
>> 
>> The xen sources contain violations of MISRA C:2012 Rule 14.4 whose
>> headline states:
>> "The controlling expression of an if statement and the controlling
>> expression of an iteration-statement shall have essentially Boolean 
>> type".
>> 
>> Add comparisons to avoid using enum constants as controlling 
>> expressions
>> to comply with Rule 14.4.
> 
> If we really want to go this route, we also need to amend the comment
> in iommu_intremap definition, as it's no longer valid:
> 
> extern enum __packed iommu_intremap {
>    /*
>     * In order to allow traditional boolean uses of the iommu_intremap
>     * variable, the "off" value has to come first (yielding a value of 
> zero).
>     */
>    iommu_intremap_off,
> 
> We no longer allow traditional boolean uses of iommu_intremap.
> 
> Thanks, Roger.

Noted, thanks.

-- 
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)


From xen-devel-bounces@lists.xenproject.org Fri Mar 15 11:39:43 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 11:39:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693822.1082411 (Exim 4.92)
	(envelope-from )
	id 1rl5uR-0004ZI-AQ; Fri, 15 Mar 2024 11:39:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693822.1082411; Fri, 15 Mar 2024 11:39:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl5uR-0004ZB-7p; Fri, 15 Mar 2024 11:39:35 +0000
Received: by outflank-mailman (input) for mailman id 693822;
 Fri, 15 Mar 2024 11:39:33 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rl5uP-0004Z5-Ot
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 11:39:33 +0000
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com
 [2a00:1450:4864:20::635])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b01b48be-e2c0-11ee-a1ee-f123f15fe8a2;
 Fri, 15 Mar 2024 12:39:31 +0100 (CET)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-a3122b70439so242942866b.3
 for ; Fri, 15 Mar 2024 04:39:31 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b01b48be-e2c0-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1710502770; x=1711107570; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=t3NUU0GS/HozcZ3HYb4tvh+06YYWS2jGALIKJFAoltM=;
        b=foazjUYeXf1WZ/6veC7PDc2jWpzW2LfJbtkrOflBbvpTKwLsH+erpxjPzm4l3PDVVN
         7nxBQn+i7nDHhmvv+Xw9jllnWHItvbOWun7uf8h/Pid/qUbA2PbMqhsnHqKFBcpgjbn0
         +6ke3xKUyIAi/x7SWIEf6miQhNAMn7scgzUp1J33DKTHJP2LO0iY3yKq5E9IxIzbrFxH
         ENwsL8ekRqLxMnskLvO5Is8onVB3gQ64Res19bXCZ0Is6TydUgbRdOms0OAihiy7Lf/U
         ODUQlFbeYbuzueRzMvVdamo7D4o+q1oPRd89QFtW/cRvO//lKWKqo9m2FQov1249cs+r
         q6Qg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710502770; x=1711107570;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=t3NUU0GS/HozcZ3HYb4tvh+06YYWS2jGALIKJFAoltM=;
        b=OyW8T70ZH1VgYNmUtI40hSn10GDxIO/4oWBAv03Ty3m1S6WA9/NdqYPs0NWvTLbpCq
         LkqLwJSoEIYZNEEo7uk+Qc2Bq8a66zTjEAvJ95Fdf782GPHMI5jxGC+pOzfK8iYbDibi
         +w/bknwwIMhgdpiiAyIseqVfzw9bOIpxOR9SsTL4qwGVSnf5ZXUoS7hUjgY9+MMTuKLy
         rOoJlCYf+3DRMi2IE7R8xodvEqtzBMhlIVjuNcpVt+tsF90+G+IAQ3Ux2YZ4YzWMFJ47
         yNhjtKPVsbbMrS68cJjUOeBNUxX67eQPmIS95Dn6QWZs/naGWgKifd8rVeyPQ0J20Axw
         1Bbg==
X-Gm-Message-State: AOJu0YyBLEt5YPusxzQqZdYgHGu+4hcwdpDRE87yFRU8XkwDwxVH+Vyo
	4P/rUP1dXTi8vgJvWA5LvC84GpcOIdw4bJALx2dUVSInDV8eZmqbnKVtREyoHj+esKzgM+u36vZ
	Mh42EIBzO8oX8ri/3pUdcMpJ4iLP6MRO56A3ZtxGcQmnN2WN6bTmB9w==
X-Google-Smtp-Source: AGHT+IFzKMafqRSJqRO/DFA9qXpD+OEe2H1B6CYzZcNwEsu9w9bbPPgS4UXULqu5P1lG8xvCJ8nT5WodltUbqhSXSrU=
X-Received: by 2002:a17:906:9c85:b0:a46:7323:6ab4 with SMTP id
 fj5-20020a1709069c8500b00a4673236ab4mr3443810ejc.14.1710502770361; Fri, 15
 Mar 2024 04:39:30 -0700 (PDT)
MIME-Version: 1.0
References: <20240315105902.160047-1-carlo.nonato@minervasys.tech> <20240315105902.160047-2-carlo.nonato@minervasys.tech>
In-Reply-To: <20240315105902.160047-2-carlo.nonato@minervasys.tech>
From: Carlo Nonato 
Date: Fri, 15 Mar 2024 12:39:19 +0100
Message-ID: 
Subject: Re: [PATCH v7 01/14] xen/common: add cache coloring common code
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper , George Dunlap , 
	Jan Beulich , Julien Grall , 
	Stefano Stabellini , Wei Liu , 
	Marco Solieri 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi all,

unfortunately, this patch doesn't apply cleanly to the latest master.
The conflict is very small: just a reordering of two lines in
xen/common/Kconfig. Should I resend the whole series?

Thanks.

On Fri, Mar 15, 2024 at 11:59=E2=80=AFAM Carlo Nonato
 wrote:
>
> Last Level Cache (LLC) coloring allows to partition the cache in smaller
> chunks called cache colors. Since not all architectures can actually
> implement it, add a HAS_LLC_COLORING Kconfig and put other options under
> xen/arch.
>
> LLC colors are a property of the domain, so the domain struct has to be
> extended.
>
> Based on original work from: Luca Miccio 
>
> Signed-off-by: Carlo Nonato 
> Signed-off-by: Marco Solieri 
> ---
> v7:
> - SUPPORT.md changes added to this patch
> - extended documentation to better address applicability of cache colorin=
g
> - "llc-nr-ways" and "llc-size" params introduced in favor of "llc-way-siz=
e"
> - moved dump_llc_coloring_info() call in 'm' keyhandler (pagealloc_info()=
)
> v6:
> - moved almost all code in common
> - moved documentation in this patch
> - reintroduced range for CONFIG_NR_LLC_COLORS
> - reintroduced some stub functions to reduce the number of checks on
>   llc_coloring_enabled
> - moved domain_llc_coloring_free() in same patch where allocation happens
> - turned "d->llc_colors" to pointer-to-const
> - llc_coloring_init() now returns void and panics if errors are found
> v5:
> - used - instead of _ for filenames
> - removed domain_create_llc_colored()
> - removed stub functions
> - coloring domain fields are now #ifdef protected
> v4:
> - Kconfig options moved to xen/arch
> - removed range for CONFIG_NR_LLC_COLORS
> - added "llc_coloring_enabled" global to later implement the boot-time
>   switch
> - added domain_create_llc_colored() to be able to pass colors
> - added is_domain_llc_colored() macro
> ---
>  SUPPORT.md                        |   7 ++
>  docs/misc/cache-coloring.rst      | 125 ++++++++++++++++++++++++++++++
>  docs/misc/xen-command-line.pandoc |  37 +++++++++
>  xen/arch/Kconfig                  |  20 +++++
>  xen/common/Kconfig                |   3 +
>  xen/common/Makefile               |   1 +
>  xen/common/keyhandler.c           |   3 +
>  xen/common/llc-coloring.c         | 102 ++++++++++++++++++++++++
>  xen/common/page_alloc.c           |   3 +
>  xen/include/xen/llc-coloring.h    |  36 +++++++++
>  xen/include/xen/sched.h           |   5 ++
>  11 files changed, 342 insertions(+)
>  create mode 100644 docs/misc/cache-coloring.rst
>  create mode 100644 xen/common/llc-coloring.c
>  create mode 100644 xen/include/xen/llc-coloring.h
>
> diff --git a/SUPPORT.md b/SUPPORT.md
> index 510bb02190..456abd42bf 100644
> --- a/SUPPORT.md
> +++ b/SUPPORT.md
> @@ -364,6 +364,13 @@ by maintaining multiple physical to machine (p2m) me=
mory mappings.
>      Status, x86 HVM: Tech Preview
>      Status, ARM: Tech Preview
>
> +### Cache coloring
> +
> +Allows to reserve Last Level Cache (LLC) partitions for Dom0, DomUs and =
Xen
> +itself.
> +
> +    Status, Arm64: Experimental
> +
>  ## Resource Management
>
>  ### CPU Pools
> diff --git a/docs/misc/cache-coloring.rst b/docs/misc/cache-coloring.rst
> new file mode 100644
> index 0000000000..52ce52ffbd
> --- /dev/null
> +++ b/docs/misc/cache-coloring.rst
> @@ -0,0 +1,125 @@
> +Xen cache coloring user guide
> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
> +
> +The cache coloring support in Xen allows to reserve Last Level Cache (LL=
C)
> +partitions for Dom0, DomUs and Xen itself. Currently only ARM64 is suppo=
rted.
> +Cache coloring realizes per-set cache partitioning in software and is ap=
plicable
> +to shared LLCs as implemented in Cortex-A53, Cortex-A72 and similar CPUs=
.
> +
> +To compile LLC coloring support set ``CONFIG_LLC_COLORING=3Dy``.
> +
> +If needed, change the maximum number of colors with
> +``CONFIG_NR_LLC_COLORS=3D``.
> +
> +Runtime configuration is done via `Command line parameters`_.
> +
> +Background
> +**********
> +
> +Cache hierarchy of a modern multi-core CPU typically has first levels de=
dicated
> +to each core (hence using multiple cache units), while the last level is=
 shared
> +among all of them. Such configuration implies that memory operations on =
one
> +core (e.g. running a DomU) are able to generate interference on another =
core
> +(e.g. hosting another DomU). Cache coloring realizes per-set cache-parti=
tioning
> +in software and mitigates this, guaranteeing higher and more predictable
> +performances for memory accesses.
> +Software-based cache coloring is particularly useful in those situations=
 where
> +no hardware mechanisms (e.g., DSU-based way partitioning) are available =
to
> +partition caches. This is the case for e.g., Cortex-A53, A57 and A72 CPU=
s that
> +feature a L2 LLC cache shared among all cores.
> +
> +The key concept underlying cache coloring is a fragmentation of the memo=
ry
> +space into a set of sub-spaces called colors that are mapped to disjoint=
 cache
> +partitions. Technically, the whole memory space is first divided into a =
number
> +of subsequent regions. Then each region is in turn divided into a number=
 of
> +subsequent sub-colors. The generic i-th color is then obtained by all th=
e
> +i-th sub-colors in each region.
> +
> +::
> +
> +                            Region j            Region j+1
> +                .....................   ............
> +                .                     . .
> +                .                       .
> +            _ _ _______________ _ _____________________ _ _
> +                |     |     |     |     |     |     |
> +                | c_0 | c_1 |     | c_n | c_0 | c_1 |
> +           _ _ _|_____|_____|_ _ _|_____|_____|_____|_ _ _
> +                    :                       :
> +                    :                       :...         ... .
> +                    :                            color 0
> +                    :...........................         ... .
> +                                                :
> +          . . ..................................:
> +
> +How colors are actually defined depends on the function that maps memory=
 to
> +cache lines. In case of physically-indexed, physically-tagged caches wit=
h linear
> +mapping, the set index is found by extracting some contiguous bits from =
the
> +physical address. This allows colors to be defined as shown in figure: t=
hey
> +appear in memory as subsequent blocks of equal size and repeats themselv=
es after
> +``n`` different colors, where ``n`` is the total number of colors.
> +
> +If some kind of bit shuffling appears in the mapping function, then colo=
rs
> +assume a different layout in memory. Those kind of caches aren't support=
ed by
> +the current implementation.
> +
> +**Note**: Finding the exact cache mapping function can be a really diffi=
cult
> +task since it's not always documented in the CPU manual. As said Cortex-=
A53, A57
> +and A72 are known to work with the current implementation.
> +
> +How to compute the number of colors
> +###################################
> +
> +Given the linear mapping from physical memory to cache lines for granted=
, the
> +number of available colors for a specific platform is computed using thr=
ee
> +parameters:
> +
> +- the size of the LLC.
> +- the number of the LLC ways.
> +- the page size used by Xen.
> +
> +The first two parameters can be found in the processor manual, while the=
 third
> +one is the minimum mapping granularity. Dividing the cache size by the n=
umber of
> +its ways we obtain the size of a way. Dividing this number by the page s=
ize,
> +the number of total cache colors is found. So for example an Arm Cortex-=
A53
> +with a 16-ways associative 1 MiB LLC can isolate up to 16 colors when pa=
ges are
> +4 KiB in size.
> +
> +LLC size and number of ways are probed automatically by default so there=
's
> +should be no need to compute the number of colors by yourself.
> +
> +Effective colors assignment
> +###########################
> +
> +When assigning colors:
> +
> +1. If one wants to avoid cache interference between two domains, differe=
nt
> +   colors needs to be used for their memory.
> +
> +2. To improve spatial locality, color assignment should privilege contin=
uity in
> +   the partitioning. E.g., assigning colors (0,1) to domain I and (2,3) =
to
> +   domain J is better than assigning colors (0,2) to I and (1,3) to J.
> +
> +Command line parameters
> +***********************
> +
> +Specific documentation is available at `docs/misc/xen-command-line.pando=
c`.
> +
> ++----------------------+-------------------------------+
> +| **Parameter**        | **Description**               |
> ++----------------------+-------------------------------+
> +| ``llc-coloring``     | enable coloring at runtime    |
> ++----------------------+-------------------------------+
> +| ``llc-size``         | set the LLC size              |
> ++----------------------+-------------------------------+
> +| ``llc-nr-ways``      | set the LLC number of ways    |
> ++----------------------+-------------------------------+
> +
> +Auto-probing of LLC specs
> +#########################
> +
> +LLC size and number of ways are probed automatically by default.
> +
> +LLC specs can be manually set via the above command line parameters. Thi=
s
> +bypasses any auto-probing and it's used to overcome failing situations o=
r for
> +debugging/testing purposes.
> diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-li=
ne.pandoc
> index 54edbc0fbc..2936abea2c 100644
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -1706,6 +1706,43 @@ This option is intended for debugging purposes onl=
y.  Enable MSR_DEBUGCTL.LBR
>  in hypervisor context to be able to dump the Last Interrupt/Exception To=
/From
>  record with other registers.
>
> +### llc-coloring
> +> `=3D `
> +
> +> Default: `false`
> +
> +Flag to enable or disable LLC coloring support at runtime. This option i=
s
> +available only when `CONFIG_LLC_COLORING` is enabled. See the general
> +cache coloring documentation for more info.
> +
> +### llc-nr-ways
> +> `=3D `
> +
> +> Default: `Obtained from hardware`
> +
> +Specify the number of ways of the Last Level Cache. This option is avail=
able
> +only when `CONFIG_LLC_COLORING` is enabled. LLC size and number of ways =
are used
> +to find the number of supported cache colors. By default the value is
> +automatically computed by probing the hardware, but in case of specific =
needs,
> +it can be manually set. Those include failing probing and debugging/test=
ing
> +purposes so that it's possibile to emulate platforms with different numb=
er of
> +supported colors. If set, also "llc-size" must be set, otherwise the def=
ault
> +will be used.
> +
> +### llc-size
> +> `=3D `
> +
> +> Default: `Obtained from hardware`
> +
> +Specify the size of the Last Level Cache. This option is available only =
when
> +`CONFIG_LLC_COLORING` is enabled. LLC size and number of ways are used t=
o find
> +the number of supported cache colors. By default the value is automatica=
lly
> +computed by probing the hardware, but in case of specific needs, it can =
be
> +manually set. Those include failing probing and debugging/testing purpos=
es so
> +that it's possibile to emulate platforms with different number of suppor=
ted
> +colors. If set, also "llc-nr-ways" must be set, otherwise the default wi=
ll be
> +used.
> +
>  ### lock-depth-size
>  > `=3D `
>
> diff --git a/xen/arch/Kconfig b/xen/arch/Kconfig
> index 67ba38f32f..a65c38e53e 100644
> --- a/xen/arch/Kconfig
> +++ b/xen/arch/Kconfig
> @@ -31,3 +31,23 @@ config NR_NUMA_NODES
>           associated with multiple-nodes management. It is the upper boun=
d of
>           the number of NUMA nodes that the scheduler, memory allocation =
and
>           other NUMA-aware components can handle.
> +
> +config LLC_COLORING
> +       bool "Last Level Cache (LLC) coloring" if EXPERT
> +       depends on HAS_LLC_COLORING
> +       depends on !NUMA
> +
> +config NR_LLC_COLORS
> +       int "Maximum number of LLC colors"
> +       range 2 1024
> +       default 128
> +       depends on LLC_COLORING
> +       help
> +         Controls the build-time size of various arrays associated with =
LLC
> +         coloring. Refer to cache coloring documentation for how to comp=
ute the
> +         number of colors supported by the platform. This is only an upp=
er
> +         bound. The runtime value is autocomputed or manually set via cm=
dline.
> +         The default value corresponds to an 8 MiB 16-ways LLC, which sh=
ould be
> +         more than what's needed in the general case. Use only power of =
2 values.
> +         1024 is the number of colors that fit in a 4 KiB page when inte=
gers are 4
> +         bytes long.
> diff --git a/xen/common/Kconfig b/xen/common/Kconfig
> index a5c3d5a6bf..1e467178bd 100644
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -71,6 +71,9 @@ config HAS_IOPORTS
>  config HAS_KEXEC
>         bool
>
> +config HAS_LLC_COLORING
> +       bool
> +
>  config HAS_PMAP
>         bool
>
> diff --git a/xen/common/Makefile b/xen/common/Makefile
> index e5eee19a85..3054254a7d 100644
> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -23,6 +23,7 @@ obj-y +=3D keyhandler.o
>  obj-$(CONFIG_KEXEC) +=3D kexec.o
>  obj-$(CONFIG_KEXEC) +=3D kimage.o
>  obj-$(CONFIG_LIVEPATCH) +=3D livepatch.o livepatch_elf.o
> +obj-$(CONFIG_LLC_COLORING) +=3D llc-coloring.o
>  obj-$(CONFIG_MEM_ACCESS) +=3D mem_access.o
>  obj-y +=3D memory.o
>  obj-y +=3D multicall.o
> diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
> index 127ca50696..778f93e063 100644
> --- a/xen/common/keyhandler.c
> +++ b/xen/common/keyhandler.c
> @@ -5,6 +5,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -303,6 +304,8 @@ static void cf_check dump_domains(unsigned char key)
>
>          arch_dump_domain_info(d);
>
> +        domain_dump_llc_colors(d);
> +
>          rangeset_domain_printk(d);
>
>          dump_pageframe_info(d);
> diff --git a/xen/common/llc-coloring.c b/xen/common/llc-coloring.c
> new file mode 100644
> index 0000000000..db96a83ddd
> --- /dev/null
> +++ b/xen/common/llc-coloring.c
> @@ -0,0 +1,102 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Last Level Cache (LLC) coloring common code
> + *
> + * Copyright (C) 2022 Xilinx Inc.
> + */
> +#include 
> +#include 
> +#include 
> +
> +static bool __ro_after_init llc_coloring_enabled;
> +boolean_param("llc-coloring", llc_coloring_enabled);
> +
> +static unsigned int __initdata llc_size;
> +size_param("llc-size", llc_size);
> +static unsigned int __initdata llc_nr_ways;
> +integer_param("llc-nr-ways", llc_nr_ways);
> +/* Number of colors available in the LLC */
> +static unsigned int __ro_after_init max_nr_colors;
> +
> +static void print_colors(const unsigned int *colors, unsigned int num_co=
lors)
> +{
> +    unsigned int i;
> +
> +    printk("{ ");
> +    for ( i =3D 0; i < num_colors; i++ )
> +    {
> +        unsigned int start =3D colors[i], end =3D start;
> +
> +        printk("%u", start);
> +
> +        for ( ; i < num_colors - 1 && end + 1 =3D=3D colors[i + 1]; i++,=
 end++ )
> +            ;
> +
> +        if ( start !=3D end )
> +            printk("-%u", end);
> +
> +        if ( i < num_colors - 1 )
> +            printk(", ");
> +    }
> +    printk(" }\n");
> +}
> +
> +void __init llc_coloring_init(void)
> +{
> +    unsigned int way_size;
> +
> +    if ( !llc_coloring_enabled )
> +        return;
> +
> +    if ( llc_size && llc_nr_ways )
> +        way_size =3D llc_size / llc_nr_ways;
> +    else
> +    {
> +        way_size =3D get_llc_way_size();
> +        if ( !way_size )
> +            panic("LLC probing failed and 'llc-size' or 'llc-nr-ways' mi=
ssing\n");
> +    }
> +
> +    /*
> +     * The maximum number of colors must be a power of 2 in order to cor=
rectly
> +     * map them to bits of an address.
> +     */
> +    max_nr_colors =3D way_size >> PAGE_SHIFT;
> +
> +    if ( max_nr_colors & (max_nr_colors - 1) )
> +        panic("Number of LLC colors (%u) isn't a power of 2\n", max_nr_c=
olors);
> +
> +    if ( max_nr_colors < 2 || max_nr_colors > CONFIG_NR_LLC_COLORS )
> +        panic("Number of LLC colors (%u) not in range [2, %u]\n",
> +              max_nr_colors, CONFIG_NR_LLC_COLORS);
> +
> +    arch_llc_coloring_init();
> +}
> +
> +void cf_check dump_llc_coloring_info(void)
> +{
> +    if ( !llc_coloring_enabled )
> +        return;
> +
> +    printk("LLC coloring info:\n");
> +    printk("    Number of LLC colors supported: %u\n", max_nr_colors);
> +}
> +
> +void cf_check domain_dump_llc_colors(const struct domain *d)
> +{
> +    if ( !llc_coloring_enabled )
> +        return;
> +
> +    printk("%u LLC colors: ", d->num_llc_colors);
> +    print_colors(d->llc_colors, d->num_llc_colors);
> +}
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * tab-width: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
> index 2ec17df9b4..c38edb9a58 100644
> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -126,6 +126,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -2623,6 +2624,8 @@ static void cf_check pagealloc_info(unsigned char k=
ey)
>      }
>
>      printk("    Dom heap: %lukB free\n", total << (PAGE_SHIFT-10));
> +
> +    dump_llc_coloring_info();
>  }
>
>  static __init int cf_check pagealloc_keyhandler_init(void)
> diff --git a/xen/include/xen/llc-coloring.h b/xen/include/xen/llc-colorin=
g.h
> new file mode 100644
> index 0000000000..c60c8050c5
> --- /dev/null
> +++ b/xen/include/xen/llc-coloring.h
> @@ -0,0 +1,36 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Last Level Cache (LLC) coloring common header
> + *
> + * Copyright (C) 2022 Xilinx Inc.
> + */
> +#ifndef __COLORING_H__
> +#define __COLORING_H__
> +
> +#include 
> +#include 
> +
> +#ifdef CONFIG_LLC_COLORING
> +void llc_coloring_init(void);
> +void dump_llc_coloring_info(void);
> +void domain_dump_llc_colors(const struct domain *d);
> +#else
> +static inline void llc_coloring_init(void) {}
> +static inline void dump_llc_coloring_info(void) {}
> +static inline void domain_dump_llc_colors(const struct domain *d) {}
> +#endif
> +
> +unsigned int get_llc_way_size(void);
> +void arch_llc_coloring_init(void);
> +
> +#endif /* __COLORING_H__ */
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * tab-width: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
> index 37f5922f32..96cc934fc3 100644
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -627,6 +627,11 @@ struct domain
>
>      /* Holding CDF_* constant. Internal flags for domain creation. */
>      unsigned int cdf;
> +
> +#ifdef CONFIG_LLC_COLORING
> +    unsigned int num_llc_colors;
> +    const unsigned int *llc_colors;
> +#endif
>  };
>
>  static inline struct page_list_head *page_to_list(
> --
> 2.34.1
>


From xen-devel-bounces@lists.xenproject.org Fri Mar 15 11:43:17 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 11:43:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693825.1082422 (Exim 4.92)
	(envelope-from )
	id 1rl5xz-0006ph-VI; Fri, 15 Mar 2024 11:43:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693825.1082422; Fri, 15 Mar 2024 11:43:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl5xz-0006ow-Qf; Fri, 15 Mar 2024 11:43:15 +0000
Received: by outflank-mailman (input) for mailman id 693825;
 Fri, 15 Mar 2024 11:43:14 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rl5xy-0006oI-SG
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 11:43:14 +0000
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com
 [2a00:1450:4864:20::12e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 34d02e27-e2c1-11ee-afdd-a90da7624cb6;
 Fri, 15 Mar 2024 12:43:13 +0100 (CET)
Received: by mail-lf1-x12e.google.com with SMTP id
 2adb3069b0e04-513b022a238so2456990e87.0
 for ; Fri, 15 Mar 2024 04:43:13 -0700 (PDT)
Received: from localhost ([85.31.135.62]) by smtp.gmail.com with ESMTPSA id
 fm23-20020a05600c0c1700b00413e4cf0c42sm8607143wmb.25.2024.03.15.04.43.12
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 15 Mar 2024 04:43:12 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 34d02e27-e2c1-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710502992; x=1711107792; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:from:to:cc:subject:date:message-id:reply-to;
        bh=vEJHp5ZUQhSC5CXAl5Yq1iRDuA5cFRJNww0FB4moeVA=;
        b=KIIRLd/F3LH4H85Ji7B0lHwU9erZOclpNTilxc8edCkb+Hxb8ui1Sd4q6LRAM4S40x
         PoZshUS2w/HG+Jpz1xm9EVgy5ypRsEfNB/X2ig9iQDoitBlT94T2yGgX+gwtk+tTi3C5
         gzx3lCqMtBjDZvo6YpVuaP6bqBTJsswUfKvVE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710502992; x=1711107792;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=vEJHp5ZUQhSC5CXAl5Yq1iRDuA5cFRJNww0FB4moeVA=;
        b=rhvEhVu9+r8FCDIuXeVTINtykYwj05P7pPt/BdUxar0jQ+mjc6YP9wh3I3eL+MoSG1
         izp8ecAu9fD7Zh5afTseeQ5T1jzvGCwkfLtnO1t3jA4Vpqc+nmr/8gnlk9SHqEIbQTHB
         7op8FAU5oSd+CzjQ+uryjiU0JSQzJQsfTMf2ew/WxsF+qu/Hz3nFY5fXllf0rzJKEvyA
         +I9girt2dDF29tODV9ywDgzuisI3jfivf5+GmYbMYojlpSgbOphqasJ+3OS2wHoYRGkk
         VN20FJeH44rYLzgYYNoAyIUs34aI0U56UdB47XvxbEDy9eVFHuyFN8BwLUScpR6OUY9c
         3prw==
X-Gm-Message-State: AOJu0YynaAC4j/T/z7CurqByda1Pfyw91sYnVhgIddJECYgX1smg7RQQ
	3S8dIu8NCHuUkxXk2/WMMiSRZJPydSHpZMW2+AFZsfzHSCo1vX7eDyxNGs/T14x+Bvg2ez5lLKK
	N
X-Google-Smtp-Source: AGHT+IGiM6YwL8oGxPMiPNae6cVIqdAkxb5Gkg1NKp5mei5KRbGk7UjORJlmP4WEiuSHsgpmVwHTlA==
X-Received: by 2002:ac2:5b41:0:b0:513:d20b:1d5a with SMTP id i1-20020ac25b41000000b00513d20b1d5amr3182203lfp.29.1710502992468;
        Fri, 15 Mar 2024 04:43:12 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Jan Beulich ,
	Andrew Cooper ,
	Wei Liu 
Subject: [PATCH] x86/time: prefer CMOS over EFI_GET_TIME
Date: Fri, 15 Mar 2024 12:42:42 +0100
Message-ID: <20240315114242.33309-1-roger.pau@citrix.com>
X-Mailer: git-send-email 2.44.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

EFI_GET_TIME doesn't seem to be very reliable:

----[ Xen-4.19-unstable  x86_64  debug=y  Tainted:   C    ]----
CPU:    0
RIP:    e008:[<0000000062ccfa70>] 0000000062ccfa70
[...]
Xen call trace:
   [<0000000062ccfa70>] R 0000000062ccfa70
   [<00000000732e9a3f>] S 00000000732e9a3f
   [] F arch/x86/time.c#get_cmos_time+0x1b3/0x26e
   [] F init_xen_time+0x28/0xa4
   [] F __start_xen+0x1ee7/0x2578
   [] F __high_start+0x94/0xa0

Pagetable walk from 0000000062ccfa70:
 L4[0x000] = 000000207ef1c063 ffffffffffffffff
 L3[0x001] = 000000005d6c0063 ffffffffffffffff
 L2[0x116] = 8000000062c001e3 ffffffffffffffff (PSE)

****************************************
Panic on CPU 0:
FATAL PAGE FAULT
[error_code=0011]
Faulting linear address: 0000000062ccfa70
****************************************

Swap the preference to default to CMOS first, and EFI later, in an attempt to
use EFI_GET_TIME as a last resort option only.  Note that Linux for example
doesn't allow calling the get_time method, and instead provides a dummy handler
that unconditionally returns EFI_UNSUPPORTED on x86-64.

The error checks are moved to the end of the function, in order to have them
grouped together.

Signed-off-by: Roger Pau Monné 
---
 xen/arch/x86/time.c | 38 ++++++++++++++++++++++----------------
 1 file changed, 22 insertions(+), 16 deletions(-)

diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
index 60870047894b..fcce5528e1f0 100644
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -1176,26 +1176,17 @@ static void __get_cmos_time(struct rtc_time *rtc)
 
 static unsigned long get_cmos_time(void)
 {
-    unsigned long res, flags;
+    unsigned long flags;
     struct rtc_time rtc;
     unsigned int seconds = 60;
     static bool __read_mostly cmos_rtc_probe;
     boolean_param("cmos-rtc-probe", cmos_rtc_probe);
 
-    if ( efi_enabled(EFI_RS) )
-    {
-        res = efi_get_time();
-        if ( res )
-            return res;
-    }
-
     if ( likely(!(acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_CMOS_RTC)) )
         cmos_rtc_probe = false;
-    else if ( system_state < SYS_STATE_smp_boot && !cmos_rtc_probe )
-        panic("System with no CMOS RTC advertised must be booted from EFI"
-              " (or with command line option \"cmos-rtc-probe\")\n");
 
-    for ( ; ; )
+    for ( ; !(acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_CMOS_RTC) ||
+            cmos_rtc_probe; )
     {
         s_time_t start, t1, t2;
 
@@ -1223,7 +1214,8 @@ static unsigned long get_cmos_time(void)
              rtc.sec >= 60 || rtc.min >= 60 || rtc.hour >= 24 ||
              !rtc.day || rtc.day > 31 ||
              !rtc.mon || rtc.mon > 12 )
-            break;
+            return mktime(rtc.year, rtc.mon, rtc.day, rtc.hour, rtc.min,
+                          rtc.sec);
 
         if ( seconds < 60 )
         {
@@ -1231,6 +1223,8 @@ static unsigned long get_cmos_time(void)
             {
                 cmos_rtc_probe = false;
                 acpi_gbl_FADT.boot_flags &= ~ACPI_FADT_NO_CMOS_RTC;
+                return mktime(rtc.year, rtc.mon, rtc.day, rtc.hour, rtc.min,
+                              rtc.sec);
             }
             break;
         }
@@ -1240,10 +1234,22 @@ static unsigned long get_cmos_time(void)
         seconds = rtc.sec;
     }
 
-    if ( unlikely(cmos_rtc_probe) )
-        panic("No CMOS RTC found - system must be booted from EFI\n");
+    if ( efi_enabled(EFI_RS) )
+    {
+        unsigned long res = efi_get_time();
+
+        if ( res )
+            return res;
+
+        panic("Broken EFI_GET_TIME %s\n",
+              !cmos_rtc_probe ? "try booting with \"cmos-rtc-probe\""
+                              : "and no CMOS RTC found");
+    }
+    if ( !cmos_rtc_probe )
+        panic("System with no CMOS RTC advertised must be booted from EFI"
+              " (or with command line option \"cmos-rtc-probe\")\n");
 
-    return mktime(rtc.year, rtc.mon, rtc.day, rtc.hour, rtc.min, rtc.sec);
+    panic("No CMOS RTC found - system must be booted from EFI\n");
 }
 
 static unsigned int __ro_after_init cmos_alias_mask;
-- 
2.44.0



From xen-devel-bounces@lists.xenproject.org Fri Mar 15 11:57:28 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 11:57:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693830.1082431 (Exim 4.92)
	(envelope-from )
	id 1rl6BX-00026j-2S; Fri, 15 Mar 2024 11:57:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693830.1082431; Fri, 15 Mar 2024 11:57:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl6BW-00026c-VW; Fri, 15 Mar 2024 11:57:14 +0000
Received: by outflank-mailman (input) for mailman id 693830;
 Fri, 15 Mar 2024 11:57:14 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rl6BV-00026U-Ve
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 11:57:13 +0000
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com
 [2a00:1450:4864:20::531])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 27f52361-e2c3-11ee-a1ee-f123f15fe8a2;
 Fri, 15 Mar 2024 12:57:11 +0100 (CET)
Received: by mail-ed1-x531.google.com with SMTP id
 4fb4d7f45d1cf-55a179f5fa1so2450103a12.0
 for ; Fri, 15 Mar 2024 04:57:11 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 jy5-20020a170907762500b00a4675490095sm1374917ejc.42.2024.03.15.04.57.09
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 15 Mar 2024 04:57:10 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 27f52361-e2c3-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710503831; x=1711108631; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=+yOmxhPCWXdF9hS0DFfqfFyhifL6yntj5Zf+pKecLhw=;
        b=QqDs1i++iFQyiOw7iKBXKB/DYvomWYJkM/beJqyvgX5ZgU/Qx269m75AxTLdHvOezL
         M9FszYFGyZdcR+CR084Qt4qMt4mInpUwo2Cyxr1AoG/7Neax8Q2T+X9bzRLjSiE3heqH
         Muhs3EQ9UXsnYnQaTHcbxQ2XkY1kJjvkqsKQ3nIhdMADcyE7b5V7H9W3nUOuM3VIuRMc
         2qNgqfVqjWASXGEYDUacXBrdHOl4GcS9/68VwDya1oGcNIDZowMYUvk7xyy9v5gn/E7W
         T/LwQDX0S3yQ11/LuWyXrK/NbvOQi+wY5eHoObs3h5uYGguuaPFiKcbf+XXVpWeK0sfK
         RxJg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710503831; x=1711108631;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=+yOmxhPCWXdF9hS0DFfqfFyhifL6yntj5Zf+pKecLhw=;
        b=iUPVrTvYDf5U4x5tifNw/3tHp4/iXbAgYvAbzT44ip/3Fi8aE0lbPZTg1E3UCF7YSb
         K95PyFJeLidRYXFDjEPauk+GoYG91hJBrFUSpc1iHlEfTj7dKReqbwegRkD9hHi9wcVf
         /VE8iz3b6qBXLyiOwCZdtWlPu9r01WjuwR0ld2YhBR626GoBaprD5WoYZQPEHikYNsSe
         PzwYUuN7WX0LYib11B8YRfnmwPilPAu5oGMXEghAW+WYrE+6WA8WeGXCIrsVnnc50dar
         YUxmFZukJEl0tgXFv2vzeL3b95rQU5VEWlUiuwG/gIL31RnUMwgXr+5Js2FS4/mP972S
         noGA==
X-Forwarded-Encrypted: i=1; AJvYcCXWjfMiVJJm2Nm7CjIYkGLSSuG7aiU8iZBDba58KlDeb//Kw4YXopRFgCMjCvf0zuBFrSyF99RwuAsh9VZJ6SmbsPY1X/KfQi2B1Ge5e9w=
X-Gm-Message-State: AOJu0YwfsswMQUH8+H5S5Ms3eDdd5oIwO5VqDUflsoV7nfUkd5/wTCvz
	tBFcHTvto3FWMP1wDaX+O/pFf2TB0HzPtI0qWpOE1w+2JtWeEQk1BPMiUI2mIA==
X-Google-Smtp-Source: AGHT+IGqu+M6FC5OCHBOnz1+6nH8cgOM/s8KP7vlnFOQjL6CrcodEGZEGlSpfEkKv2YdQdclQ3JYnQ==
X-Received: by 2002:a17:906:9c8c:b0:a3e:cdae:7aa2 with SMTP id fj12-20020a1709069c8c00b00a3ecdae7aa2mr3801232ejc.35.1710503830761;
        Fri, 15 Mar 2024 04:57:10 -0700 (PDT)
Message-ID: <63891474-1dc4-4c86-aaf4-cc4d4c53a0ae@suse.com>
Date: Fri, 15 Mar 2024 12:57:08 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] do_multicall and MISRA Rule 8.3\
Content-Language: en-US
To: George Dunlap 
Cc: Stefano Stabellini ,
 federico.serafini@bugseng.com, Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Bertrand Marquis , xen-devel@lists.xenproject.org,
 michal.orzel@amd.com, julien@xen.org
References: 
 <5a8f90d6-6502-4d93-9fd7-45fea0ede24a@suse.com>
 
 
 
 
 
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 15.03.2024 11:59, George Dunlap wrote:
> On Fri, Mar 15, 2024 at 6:54 AM Jan Beulich  wrote:
>> On 15.03.2024 01:21, Stefano Stabellini wrote:
>>> On Mon, 11 Mar 2024, Julien Grall wrote:
>>>> On 11/03/2024 11:32, George Dunlap wrote:
>>>>> On Sat, Mar 9, 2024 at 1:59 AM Stefano Stabellini
>>>>>  wrote:
>>>>>>
>>>>>> I would like to resurrect this thread and ask other opinions.
>>>>>>
>>>>>>
>>>>>> On Thu, 23 Nov 2023, Jan Beulich wrote:
>>>>>>> On 22.11.2023 22:46, Stefano Stabellini wrote:
>>>>>>>> Two out of three do_multicall definitions/declarations use uint32_t as
>>>>>>>> type for the "nr_calls" parameters. Change the third one to be
>>>>>>>> consistent with the other two.
>>>>>>>>
>>>>>>>> Link:
>>>>>>>> https://lore.kernel.org/xen-devel/7e3abd4c0ef5127a07a60de1bf090a8aefac8e5c.1692717906.git.federico.serafini@bugseng.com/
>>>>>>>> Link:
>>>>>>>> https://lore.kernel.org/xen-devel/alpine.DEB.2.22.394.2308251502430.6458@ubuntu-linux-20-04-desktop/
>>>>>>>> Signed-off-by: Stefano Stabellini 
>>>>>>>> ---
>>>>>>>> Note that a previous discussion showed disagreement between
>>>>>>>> maintainers
>>>>>>>> on this topic. The source of disagreements are that we don't want to
>>>>>>>> change a guest-visible ABI and we haven't properly documented how to
>>>>>>>> use
>>>>>>>> types for guest ABIs.
>>>>>>>>
>>>>>>>> As an example, fixed-width types have the advantage of being explicit
>>>>>>>> about their size but sometimes register-size types are required (e.g.
>>>>>>>> unsigned long). The C specification says little about the size of
>>>>>>>> unsigned long and today, and we even use unsigned int in guest ABIs
>>>>>>>> without specifying the expected width of unsigned int on the various
>>>>>>>> arches. As Jan pointed out, in Xen we assume sizeof(int) >= 4, but
>>>>>>>> that's not written anywhere as far as I can tell.
>>>>>>>>
>>>>>>>> I think the appropriate solution would be to document properly our
>>>>>>>> expectations of both fixed-width and non-fixed-width types, and how to
>>>>>>>> use them for guest-visible ABIs.
>>>>>>>>
>>>>>>>> In this patch I used uint32_t for a couple of reasons:
>>>>>>>> - until we have better documentation, I feel more confident in using
>>>>>>>>    explicitly-sized integers in guest-visible ABIs
>>>>>>>
>>>>>>> I disagree with this way of looking at it. Guests don't invoke these
>>>>>>> functions directly, and our assembly code sitting in between already is
>>>>>>> expected to (and does) guarantee that (in the case here) unsigned int
>>>>>>> would be okay to use (as would be unsigned long, but at least on x86
>>>>>>> that's slightly less efficient), in line with what ./CODING_STYLE says.
>>>>>>>
>>>>>>> Otoh structure definitions in the public interface of course need to
>>>>>>> use fixed with types (and still doesn't properly do so in a few cases).
>>>>>
>>>>> You didn't address the other argument, which was that all the other
>>>>> definitions have uint32_t; in particular,
>>>>> common/multicall.c:do_multicall() takes uint32_t.  Surely that should
>>>>> match the non-compat definition in include/hypercall-defs.c?
>>>>>
>>>>> Whether they should both be `unsigned int` or `uint32_t` I don't
>>>>> really feel like I have a good enough grasp of the situation to form a
>>>>> strong opinion.
>>>>
>>>> FWIW +1. We at least need some consistency.
>>>
>>> Consistency is my top concern. Let's put the "unsigned int" vs
>>> "uint32_t" argument aside.
>>>
>>> do_multicall is not consistent with itself. We need
>>> hypercall-defs.c:do_multicall and multicall.c:do_multicall to match.
>>>
>>> Option1) We can change hypercall-defs.c:do_multicall to use uint32_t.
>>>
>>> Option2) Or we can change multicall.c:do_multicall to use unsigned int.
>>>
>>> I went with Option1. Andrew expressed his strong preference toward
>>> Option1 in the past. George seems to prefer Option1.
>>>
>>> Jan, can you accept Option1 and move on?
>>
>> Counter question: Why do we have the opposite of what you all want stated
>> in ./CODING_STYLE?
> 
> Indeed, that's what I wanted to ask at the committer's meeting on
> Wednesday, but we ran out of time.
> 
>> Looking at the commit, it was actually George who ack-ed
>> it. I can accept option 1 if ./CODING_STYLE is first changed / amended.
> 
> That change was added in 2019, but I certainly remember discussions
> along these lines going on long before then.  Presumably there was a
> long unwritten tradition of avoiding explicitly-sized types unless
> necessary, and someone said, "that's not in the CODING_STYLE", and so
> you added it.  Having the expectation written down is certainly worth
> having, even if I don't personally care that much about it.
> 
> I will note that when I gave my Ack, I said that it probably wanted an
> Ack from then ARM maintainers as well [1]; that doesn't seem to have
> happened, so there's an argument that it was checked in improperly.

Hmm. "Would be good" doesn't sound like a strict requirement to me.
Don't forget that there was over 8 months between submission and your
ack. Anyone caring to object had their chance. I also didn't commit
this the same day you gave your ack.

> The coding style says, "Fixed width types should only be used when a
> fixed width quantity is meant".  In the discussion on v2 of the patch,
> I went through some uses of uint32_t, and regarding instances "Inside
> headers for public interfaces", you said [2]:
> 
>> Here fixed width types are definitely the right choice.
> 
> It sounds like Andy and Stefano feel like this is a situation where "a
> fixed width quantity is meant"; absent any further guidance from the
> CODING_STYLE about when fixed widths should or should not be used, I
> don't think this change would be a violation of CODING_STYLE.

As with any not sufficiently clear statement, that's certainly true here,
too. Yet if we try to give as wide meaning as possible to "a fixed width
quantity is meant", there's basically no restriction on use of fixed width
types because everyone can just say "but I mean a fixed width quantity
here". I think the earlier sentence needs taking with higher priority,
i.e. if a basic type does for the purpose, that's what should be used. The
2nd sentence then only tries to further clarify what the 1st means.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Mar 15 12:13:34 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 12:13:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693836.1082441 (Exim 4.92)
	(envelope-from )
	id 1rl6RE-0006bI-H5; Fri, 15 Mar 2024 12:13:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693836.1082441; Fri, 15 Mar 2024 12:13:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl6RE-0006bB-Dc; Fri, 15 Mar 2024 12:13:28 +0000
Received: by outflank-mailman (input) for mailman id 693836;
 Fri, 15 Mar 2024 12:13:26 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rl6RC-0006b5-Jt
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 12:13:26 +0000
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com
 [2a00:1450:4864:20::536])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6ca13c1c-e2c5-11ee-afdd-a90da7624cb6;
 Fri, 15 Mar 2024 13:13:25 +0100 (CET)
Received: by mail-ed1-x536.google.com with SMTP id
 4fb4d7f45d1cf-563bb51c36eso2578732a12.2
 for ; Fri, 15 Mar 2024 05:13:25 -0700 (PDT)
Received: from andrewcoop.citrite.net (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 h25-20020a17090634d900b00a454438091fsm1654875ejb.70.2024.03.15.05.13.23
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 15 Mar 2024 05:13:23 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6ca13c1c-e2c5-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710504804; x=1711109604; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:from:to:cc:subject:date:message-id:reply-to;
        bh=1aZV9TonYmvhh8ERncfMGScFuRJUFVx1UlX7BWrmAn8=;
        b=UF5xkQIRE/agyCK2r8XokBpT8s6hMhCWMXzof6f8F4R6BEo1fcGr6GvliSKkz751Tx
         94rcOrcyMxTHC8303ROe/vEMqro+84tOWUZxMTXh5mZS7CEMae7ohHjCnd/Jp65Hj9PR
         56xiAQAFFmBAE9mFt4QJ2SSSYzCtfmI4/qxgY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710504804; x=1711109604;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=1aZV9TonYmvhh8ERncfMGScFuRJUFVx1UlX7BWrmAn8=;
        b=EB6hQfPW4t2cRNYQuklgV6SeGfLPwxirftDpYSzhUYBez51YLs4WDnogz3+egsB90D
         3+T70Qu9MdGmmXj91UpmYVW3eDPQsAp+kyI9TfFG6/2urLK2KPtpQYAHjmc2SWmkGTTj
         ADHzj2hBmZwzs+Qp/bLd6fk+kV61oQuOb15BFNw3LaOV8ohmggDRC9QYYbv2g/g+xpWT
         CvJsF9Ee+6qYbB25ldNcAVy5HlYA/LUnR/WMt7jN0IZuDtRdFk2qbOjgGZL+4wCYeVN1
         EJyxKyy+W6yyTpv1kXzl/gkNLoyvBqPoR2xGgbBeK96fLZqswGbfkH9fNlipEmC1zSIk
         mfeA==
X-Gm-Message-State: AOJu0YyDhkGXcDk7WTrV+piNBWmWhppmezmRA8WbxV4IucTH3+or9Y+V
	Th94y+f5iSRSr1KpAw5VM44swkVNuWbgUyOFCbeEN5U+t0IDa1aQbDIOZH6uNKIP49Bd6iD8ddN
	V
X-Google-Smtp-Source: AGHT+IGZKvTM/4eMMxsMM0rZZNSgULV/RpS+/Uc3ymt/V9eHGvVfVNPI2oxyPTMeUcUEzS5kLckolQ==
X-Received: by 2002:a17:907:987c:b0:a44:4c8e:f167 with SMTP id ko28-20020a170907987c00b00a444c8ef167mr2898559ejc.69.1710504804093;
        Fri, 15 Mar 2024 05:13:24 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH] xen/vpci: Improve code generation in mask_write()
Date: Fri, 15 Mar 2024 12:13:22 +0000
Message-Id: <20240315121322.3300387-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.30.2
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The use of __clear_bit() forces dmask to be spilled to the stack, and
interferes with the compiler heuristcs for some upcoming improvements to the
ffs() code generation.

First, shrink dmask to just the active vectors by making out the upper bits.
This replaces the "i < msi->vectors" part of the loop condition.

Next, use a simple while() loop with "clear bottom bit" expressed in plane C,
which affords the optimiser a far better understanding of what the loop is
doing.

Signed-off-by: Andrew Cooper 
---
CC: Roger Pau Monné 

Noticed when looking at the ffs() code gen improvements.

Any suggestion on how to test this?  test_vcpi doesn't seem to check anything
here.  I think I've got the boundary conditions for msi->vectors right, but
I'd be lying if I said I was certain...

bloat-o-meter reports:

  add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-28 (-28)
  Function                                     old     new   delta
  mask_write                                   142     114     -28

which is a consequence of the compiler having a much better idea of what's
going on in the loop.  There's more to come with the ffs() improvements too.
---
 xen/drivers/vpci/msi.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/xen/drivers/vpci/msi.c b/xen/drivers/vpci/msi.c
index d3aa5df08941..30adcf7df05d 100644
--- a/xen/drivers/vpci/msi.c
+++ b/xen/drivers/vpci/msi.c
@@ -169,13 +169,15 @@ static void cf_check mask_write(
 
     if ( msi->enabled )
     {
-        unsigned int i;
+        /* Skip changes to vectors which aren't enabled. */
+        dmask &= (~0U >> (32 - msi->vectors));
 
-        for ( i = ffs(dmask) - 1; dmask && i < msi->vectors;
-              i = ffs(dmask) - 1 )
+        while ( dmask )
         {
+            unsigned int i = ffs(dmask) - 1;
+
             vpci_msi_arch_mask(msi, pdev, i, (val >> i) & 1);
-            __clear_bit(i, &dmask);
+            dmask &= (dmask - 1);
         }
     }
 

base-commit: d638e304f13a5ef7d125de5ace5f7828a7b25bac
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Fri Mar 15 12:17:35 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 12:17:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693839.1082451 (Exim 4.92)
	(envelope-from )
	id 1rl6VC-00079p-W6; Fri, 15 Mar 2024 12:17:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693839.1082451; Fri, 15 Mar 2024 12:17:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl6VC-00079i-T6; Fri, 15 Mar 2024 12:17:34 +0000
Received: by outflank-mailman (input) for mailman id 693839;
 Fri, 15 Mar 2024 12:17:32 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rl6VA-00079b-Rx
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 12:17:32 +0000
Received: from mail-oa1-x30.google.com (mail-oa1-x30.google.com
 [2001:4860:4864:20::30])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ff1402ff-e2c5-11ee-afdd-a90da7624cb6;
 Fri, 15 Mar 2024 13:17:31 +0100 (CET)
Received: by mail-oa1-x30.google.com with SMTP id
 586e51a60fabf-221830f6643so1118153fac.2
 for ; Fri, 15 Mar 2024 05:17:31 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ff1402ff-e2c5-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1710505050; x=1711109850; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=b6gPQ4WDYUxprQhEdyUeUfF/08t4lHxJxIj5U8So4xs=;
        b=hrCMNhkOoJfeaZbmTXuiStpFGPo8BnlmLTjq6foc9RMZSgXm5+z9CoyhDW3LHK75zf
         gFyQRxMmlLSwkc9yygIPAQ/ocF8ycUo2tgVYKhsZ5tGA0IV7UY6RrA5lgKp3hlA9jGb9
         jNkmknPPNd8yUnGTCF21t1GJZ8+rH44p8NXlE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710505050; x=1711109850;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=b6gPQ4WDYUxprQhEdyUeUfF/08t4lHxJxIj5U8So4xs=;
        b=CUKtKZ28IGmSLSWA/Z00kNb2DYjbAzdtGMIe+9VF0uOK4TiIqcmNiLEbY8WsLLr0T6
         r1WICG5irQDR2O9LlaXTwXRef77dJvhavcTP1hZSDIuscejrIel7WJ3SKLRmCO4EyjBi
         zhRn1VkOWPMZIqztA3jfNjclXalYinufyROz+FdALQfgAfKiB0MdZWIg63x0vQu0fe22
         N+P8x3zf2PKPjQ2ERlVo1WDHmJevwXixJvC1TQG27AuxTCv392gVPXK5XHr2+1dxRIFc
         DVbgoRe2oh8ccln1NVQ40oNDMaM5O5edwCZ34VqgRYUtH7Pd+qAsj8olg2WZCbZ1Dwu+
         J0mw==
X-Forwarded-Encrypted: i=1; AJvYcCVSkEpo1IZNu27tijOYDB2BN5LKTqmBNHgVMdLDVPXwvagPIaLvMsKIZPSM/BxJkcC/DwkxW6ry+GxP633HPnTaKnp2QeBBgjltZSwaqoA=
X-Gm-Message-State: AOJu0Yytfj8EvWQPucgZXnBLe0udog67b9Ct910Sv9MY7XCpcc/GPhbb
	baRWtXdScP8yfrzUdzbfeZ30xBxLtx8y1ug84TVmFuNAVYbl3B2iP3ylciVqeQbDmPLx6So+tdN
	I/D+aUZ8EyKNvTSsvZOkiJY80M2RRAkZOsMgABQ==
X-Google-Smtp-Source: AGHT+IG5GSULDr5g0JuUkibPJm8GUihvcxvoHSQflK1udT/a6PfpKRJDEU2GJMPn3UG2C9udzPNdGf6WefRb0A0q0TU=
X-Received: by 2002:a05:6870:5b81:b0:221:cb1b:c57d with SMTP id
 em1-20020a0568705b8100b00221cb1bc57dmr5209269oab.7.1710505050569; Fri, 15 Mar
 2024 05:17:30 -0700 (PDT)
MIME-Version: 1.0
References: 
 <5a8f90d6-6502-4d93-9fd7-45fea0ede24a@suse.com> 
 
  
  
 <63891474-1dc4-4c86-aaf4-cc4d4c53a0ae@suse.com>
In-Reply-To: <63891474-1dc4-4c86-aaf4-cc4d4c53a0ae@suse.com>
From: George Dunlap 
Date: Fri, 15 Mar 2024 12:17:19 +0000
Message-ID: 
Subject: Re: [PATCH] do_multicall and MISRA Rule 8.3\
To: Jan Beulich 
Cc: Stefano Stabellini , federico.serafini@bugseng.com, 
	Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
	Bertrand Marquis , xen-devel@lists.xenproject.org, 
	michal.orzel@amd.com, julien@xen.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 15, 2024 at 11:57=E2=80=AFAM Jan Beulich  wr=
ote:
> > It sounds like Andy and Stefano feel like this is a situation where "a
> > fixed width quantity is meant"; absent any further guidance from the
> > CODING_STYLE about when fixed widths should or should not be used, I
> > don't think this change would be a violation of CODING_STYLE.
>
> As with any not sufficiently clear statement, that's certainly true here,
> too. Yet if we try to give as wide meaning as possible to "a fixed width
> quantity is meant", there's basically no restriction on use of fixed widt=
h
> types because everyone can just say "but I mean a fixed width quantity
> here". I think the earlier sentence needs taking with higher priority,
> i.e. if a basic type does for the purpose, that's what should be used. Th=
e
> 2nd sentence then only tries to further clarify what the 1st means.

Come, now.  There are lots of situations where we just need some sort
of number, and there's no real need to worry about the exact size.
There are other situations, where we mean "whatever covers the whole
address space" or the like, where it makes sense to have something
like "unsigned long", which changes size, but in predictable and
useful ways.  There are other situations, like when talking over an
API to code which may be compiled by a different compiler, or may be
running in a different processor mode, where we want to be more
specific, and set an exact number of bits.

Should we use uint32_t for random loop variables?  Pretty clearly
"No".  Should we use uint32_t for the C entry of a hypercall, even
though the assembly code allegedly makes that unnecessary?  At least
two core maintainers think "maybe just to be safe".  That's hardly a
slippery slope of "anyone can say anything".

Other than "it's in CODING_STYLE", and "it's not really necessary
because it's ensured in the assembly code", you haven't advanced a
single reason why "uint32_t" is problematic.

 -George


From xen-devel-bounces@lists.xenproject.org Fri Mar 15 12:33:57 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 12:33:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693842.1082461 (Exim 4.92)
	(envelope-from )
	id 1rl6kv-0004Fp-BX; Fri, 15 Mar 2024 12:33:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693842.1082461; Fri, 15 Mar 2024 12:33:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl6kv-0004Fi-7S; Fri, 15 Mar 2024 12:33:49 +0000
Received: by outflank-mailman (input) for mailman id 693842;
 Fri, 15 Mar 2024 12:33:48 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rl6ku-0004FY-An; Fri, 15 Mar 2024 12:33:48 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rl6ku-0001jv-3y; Fri, 15 Mar 2024 12:33:48 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rl6kt-0006DO-Lk; Fri, 15 Mar 2024 12:33:47 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rl6kt-0005mr-LI; Fri, 15 Mar 2024 12:33:47 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=+088NxbR/iApl7wfijBA0GEnwcQ7BNQUqbDQqsfwN1k=; b=JJ59FvYi3RQDjARSFMIg+aeCj5
	z2VeLD1R3GELe+pxFb9GXsntUwKIjYzNLOK2EeyLebCkdc0rmJo63iFBGxIuirVbxHsErF3q2ygHm
	X0MZlB7biShyj1JR8h+DbZGFGnqc+w6jn2HT8xbdDCHWMUznd8pdx3l9lWGJ+VOsyPuU=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [ovmf test] 185047: all pass - PUSHED
X-Osstest-Versions-This:
    ovmf=ccbbc2a5c84a0330b28b726ef0936fc16937005a
X-Osstest-Versions-That:
    ovmf=e7486b50646d6a645706b61d2f8d74b3dca23ce0
From: osstest service owner 
Date: Fri, 15 Mar 2024 12:33:47 +0000

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

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

Last test of basis   185037  2024-03-14 16:41:16 Z    0 days
Testing same since   185047  2024-03-15 09:11:16 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Du Lin 

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-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   e7486b5064..ccbbc2a5c8  ccbbc2a5c84a0330b28b726ef0936fc16937005a -> xen-tested-master


From xen-devel-bounces@lists.xenproject.org Fri Mar 15 13:25:13 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 13:25:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693860.1082471 (Exim 4.92)
	(envelope-from )
	id 1rl7YT-0005IK-4I; Fri, 15 Mar 2024 13:25:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693860.1082471; Fri, 15 Mar 2024 13:25:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl7YT-0005ID-1E; Fri, 15 Mar 2024 13:25:01 +0000
Received: by outflank-mailman (input) for mailman id 693860;
 Fri, 15 Mar 2024 13:24:59 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rl7YR-0005I7-Py
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 13:24:59 +0000
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com
 [2a00:1450:4864:20::52a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 683fe153-e2cf-11ee-a1ee-f123f15fe8a2;
 Fri, 15 Mar 2024 14:24:53 +0100 (CET)
Received: by mail-ed1-x52a.google.com with SMTP id
 4fb4d7f45d1cf-568b4b9aeeaso599166a12.3
 for ; Fri, 15 Mar 2024 06:24:53 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 g18-20020a056402091200b00568b6f73491sm240052edz.14.2024.03.15.06.24.52
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 15 Mar 2024 06:24:52 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 683fe153-e2cf-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710509092; x=1711113892; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=bociKXp9DNG9xROayi03Wc1oYquHr60jp09vWqzEsUE=;
        b=QLB3CXOp9s6TMiniFVMGgOr03VNI9H6w+GQ6x5gPHkT3ZeEqwoSkjLWeoSZ/hBHhVr
         a+Zd1rfIA0ISyWEtfmHR/wUAmLaUbTY9tg+758YIQU2nmucvxRbFwDaZe9FspWX7Ronr
         DZXFVh9SNuLzHcvb3r/Lux/HXqTs7m+pd3OGn4p/eBfxSW8j4Ss8oCYdEywdp20KHTTC
         OVFQBNTR3MrxRhZ+I3gr9gVQd+mX4oWo55LDvMAMK362imGFkTzqzPlkKOtJS6BJ8zbK
         F/ORtktVSTRQs4Lh5uhZn3b6/90yB8TAOu/73jORADU46iIPC5PSSugTUeECBMa+VAIv
         vrRg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710509092; x=1711113892;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=bociKXp9DNG9xROayi03Wc1oYquHr60jp09vWqzEsUE=;
        b=JIhJWQRgu/SQ5v4dDDtnHvXPlBdieeEEwICt2NjotieClS7G1DGTkqJy+dNfDN/YMf
         Pqmmx/Lr+rVbWV+J41lRLX6YLN/86eEi6nTwZcuLTeXHf7fqsy8LhYw1lok81jp+SaAo
         o/jv6bQviVJvM102jfC53a0TJOHfwlgOV+cQivMkISv3dGgvYI4zZnLCfCg5gCvnQFaR
         gGF61mf4Cec6fRvff16nbk/nLXEo91rlMi5Gd9wpyS0zTxSPB53rR95foNfbAq/qHBKj
         ANh1ul/KbDNpvwYD8/m+Hcxy7LGNvNlKWFB9GkC+qxTtfNMR0Yx2QUjIzqTND4X0X0sQ
         Y5Qg==
X-Forwarded-Encrypted: i=1; AJvYcCWC17lgwi/YhT8HPbuFpzR0V9AFFq8OJKFMP3L7w4bKxIASdjcjY29cLZ+w4jd2csnkGOzKUoB7eMC26biatYszvvDaeg5vmZLziFUUD6A=
X-Gm-Message-State: AOJu0YxeE2Z4tlHPAyzY6+iZ5Hf6APQTzsJe2WpJocnIke8QmkGD16Ln
	7HmANisZ60oKHIq/3aTHgC1Am6+olgh5QKpSo46t14qmlC4ZOYkc2uHp9yA2IQ==
X-Google-Smtp-Source: AGHT+IGakwekdhuLRNnsZLRRfXlc3GxQsG7r1CvkZ3NISX90+n3+C1n9FqdP3M3tMjhVfOrGYTgUSg==
X-Received: by 2002:a05:6402:194a:b0:568:9cfe:1974 with SMTP id f10-20020a056402194a00b005689cfe1974mr3106124edz.18.1710509092559;
        Fri, 15 Mar 2024 06:24:52 -0700 (PDT)
Message-ID: 
Date: Fri, 15 Mar 2024 14:24:50 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] do_multicall and MISRA Rule 8.3\
Content-Language: en-US
To: George Dunlap 
Cc: Stefano Stabellini ,
 federico.serafini@bugseng.com, Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Bertrand Marquis , xen-devel@lists.xenproject.org,
 michal.orzel@amd.com, julien@xen.org
References: 
 <5a8f90d6-6502-4d93-9fd7-45fea0ede24a@suse.com>
 
 
 
 
 
 
 <63891474-1dc4-4c86-aaf4-cc4d4c53a0ae@suse.com>
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 15.03.2024 13:17, George Dunlap wrote:
> On Fri, Mar 15, 2024 at 11:57 AM Jan Beulich  wrote:
>>> It sounds like Andy and Stefano feel like this is a situation where "a
>>> fixed width quantity is meant"; absent any further guidance from the
>>> CODING_STYLE about when fixed widths should or should not be used, I
>>> don't think this change would be a violation of CODING_STYLE.
>>
>> As with any not sufficiently clear statement, that's certainly true here,
>> too. Yet if we try to give as wide meaning as possible to "a fixed width
>> quantity is meant", there's basically no restriction on use of fixed width
>> types because everyone can just say "but I mean a fixed width quantity
>> here". I think the earlier sentence needs taking with higher priority,
>> i.e. if a basic type does for the purpose, that's what should be used. The
>> 2nd sentence then only tries to further clarify what the 1st means.
> 
> Come, now.  There are lots of situations where we just need some sort
> of number, and there's no real need to worry about the exact size.
> There are other situations, where we mean "whatever covers the whole
> address space" or the like, where it makes sense to have something
> like "unsigned long", which changes size, but in predictable and
> useful ways.  There are other situations, like when talking over an
> API to code which may be compiled by a different compiler, or may be
> running in a different processor mode, where we want to be more
> specific, and set an exact number of bits.
> 
> Should we use uint32_t for random loop variables?  Pretty clearly
> "No".  Should we use uint32_t for the C entry of a hypercall, even
> though the assembly code allegedly makes that unnecessary?  At least
> two core maintainers think "maybe just to be safe".  That's hardly a
> slippery slope of "anyone can say anything".
> 
> Other than "it's in CODING_STYLE", and "it's not really necessary
> because it's ensured in the assembly code", you haven't advanced a
> single reason why "uint32_t" is problematic.

And it isn't, I never said it would be. But if we set rules for
ourselves, why would we take the first opportunity to not respect them?

Jan


From xen-devel-bounces@lists.xenproject.org Fri Mar 15 13:31:41 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 13:31:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693864.1082481 (Exim 4.92)
	(envelope-from )
	id 1rl7ep-00074n-QH; Fri, 15 Mar 2024 13:31:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693864.1082481; Fri, 15 Mar 2024 13:31:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl7ep-00074g-NF; Fri, 15 Mar 2024 13:31:35 +0000
Received: by outflank-mailman (input) for mailman id 693864;
 Fri, 15 Mar 2024 13:31:35 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rl7ep-00074a-5P
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 13:31:35 +0000
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com
 [2a00:1450:4864:20::531])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 57365d46-e2d0-11ee-afdd-a90da7624cb6;
 Fri, 15 Mar 2024 14:31:34 +0100 (CET)
Received: by mail-ed1-x531.google.com with SMTP id
 4fb4d7f45d1cf-568a5114881so1960127a12.1
 for ; Fri, 15 Mar 2024 06:31:34 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d10-20020a170907272a00b00a45ff890df0sm1725305ejl.35.2024.03.15.06.31.32
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 15 Mar 2024 06:31:33 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 57365d46-e2d0-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710509493; x=1711114293; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=snZXQnNFl4bDuth7n216ZDoL9SPL+HjiFq4UARJH/S4=;
        b=Sd2YvBg+CQiVvV08/8BLEI2JCIy8jygTYYvoGNkPXUpInGSqiblJjBEK3gyed9Seib
         WQqpZ7aYKDO213SD93l4yzLaaV/58SRF70M1AV7GGKt+LY8XUsd0pEuxODzxU8fmd78T
         gW81ZYhogkZ6ViF9Uafpp/TpuRGd08vPrVwpVZqe/dCvhQ/OTILsQZNhyhQMShr81HwL
         5t/MqgCDPjATsXlBrzD+E/ei+KSuExhj3tKrwYQU/+IasJMdhI+DhMHXSIBr50Ecvr1Z
         +F97pWmQHxEPk/waPFgK3QV0b9w+xmyuYEW1PjPusOuc7c+EAnflyF6fcuqzTGj8MzlU
         3utw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710509493; x=1711114293;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=snZXQnNFl4bDuth7n216ZDoL9SPL+HjiFq4UARJH/S4=;
        b=HbG7TD1Vm5DCYwtOBIrF5HWzxxlhMXuEP5+uL6FgATP7QJdiHnvWIOyKBi+e3t7DH8
         37x+EdB2AiDlXLXXirNBvVg4+3IQTb3jUlU3c5j7Vf/yvG6gsERRMyDOdbwMOwLyd1Fr
         SBSDyP6IGrHwQSXHqKMzpn3o7G8vJJdLHRhdV56lZYfHBciu8urzqXPKU1tqGOOET/Xi
         UIwlJNlSeDCCoFaMC1bD+Krd0kQDy2nJts9NN6Bcvppl1VLKyCL/7y0TaV2FeV4bRnU8
         Fh96Iej0anFFCV6GQIdkBHGf8UBU3LVDOXX56nA1rCygkBMhLtjJrKgCxEfcCS2oppHZ
         d5HA==
X-Forwarded-Encrypted: i=1; AJvYcCV404UeNhuTYYRO5yTgV57rIlXlyQ/WJilECvGe2l7SXbdeOaQDaMJr6cXbVYybZM1zwyogECXTp/DeyX9bdP6RTwXIv7/vibuVXsc8CA4=
X-Gm-Message-State: AOJu0Yz0NCW8GQQz41VmxKWeH3QNL/REynQ7pfcM+x025FB94RGn92ZI
	0JdQM993b1YmiqVsdjN8nYfQadpYGASNxZgZqMJPoIhB6ohJRbTZ5a1I30EIPQ==
X-Google-Smtp-Source: AGHT+IGHX2sgIvhXOo5aL1yrfBpF8Z7HWMVCnvT30znhvhQDKOvgpa71IOsLA0754gGpjPM/GB8gEw==
X-Received: by 2002:a17:906:a291:b0:a46:7e08:37e8 with SMTP id i17-20020a170906a29100b00a467e0837e8mr1869130ejz.53.1710509493460;
        Fri, 15 Mar 2024 06:31:33 -0700 (PDT)
Message-ID: <8f3275b9-ef64-4f49-8d81-fe32b217f74e@suse.com>
Date: Fri, 15 Mar 2024 14:31:31 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH v2] amd/iommu: clean up unused guest iommu related
 functions
Content-Language: en-US
To: Nicola Vetrini 
Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com,
 ayan.kumar.halder@amd.com, consulting@bugseng.com,
 Andrew Cooper , xen-devel@lists.xenproject.org
References: <324c939125677032af2c1d2e5fb628849415d68e.1710501265.git.nicola.vetrini@bugseng.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <324c939125677032af2c1d2e5fb628849415d68e.1710501265.git.nicola.vetrini@bugseng.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 15.03.2024 12:16, Nicola Vetrini wrote:
> Delete unused functions from 'iommu_guest.c'.
> 
> The 'cmd' parameter of amd_iommu_send_guest_cmd is passed
> to a function that expects arrays of size 4, therefore
> specifying explicitly the size also in amd_iommu_send_guest_cmd
> allows not to accidentally pass a bigger array.
> 
> No functional change.
> 
> Signed-off-by: Nicola Vetrini 
> ---
> All current users of amd_iommu_send_guest pass an array of size 4,
> hence this is fixing a potential issue noticed by the analyzer for MISRA C
> Rule 17.5, not an actual bug.
> 
> guest_iommu_add_ptr_log has still one caller, but even that seems
> suspicious. I left it in and uniformed its parameter type at the
> moment, so that whether it should be kept can be sorted out later.
> If that caller indeed should be removed as well, then
> no function in the file is actually reachable as far as I can tell.

Afaict this wants removing too.

But what I'm more puzzled by: You remove all callers of
amd_iommu_send_guest_cmd(), yet still ...

> --- a/xen/drivers/passthrough/amd/iommu.h
> +++ b/xen/drivers/passthrough/amd/iommu.h
> @@ -346,12 +346,8 @@ void cf_check amd_iommu_crash_shutdown(void);
>  
>  /* guest iommu support */
>  #ifdef CONFIG_HVM
> -void amd_iommu_send_guest_cmd(struct amd_iommu *iommu, u32 cmd[]);
> -void guest_iommu_add_ppr_log(struct domain *d, u32 entry[]);
> -void guest_iommu_add_event_log(struct domain *d, u32 entry[]);
> -int guest_iommu_init(struct domain* d);
> -void guest_iommu_destroy(struct domain *d);
> -int guest_iommu_set_base(struct domain *d, uint64_t base);
> +void amd_iommu_send_guest_cmd(struct amd_iommu *iommu, uint32_t cmd[4]);

... retain the function.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Mar 15 13:39:19 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 13:39:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693868.1082490 (Exim 4.92)
	(envelope-from )
	id 1rl7mE-0008EX-K8; Fri, 15 Mar 2024 13:39:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693868.1082490; Fri, 15 Mar 2024 13:39:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl7mE-0008EQ-HZ; Fri, 15 Mar 2024 13:39:14 +0000
Received: by outflank-mailman (input) for mailman id 693868;
 Fri, 15 Mar 2024 13:39:13 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rl7mD-0008EK-CT
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 13:39:13 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6839a842-e2d1-11ee-afdd-a90da7624cb6;
 Fri, 15 Mar 2024 14:39:12 +0100 (CET)
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 by support.bugseng.com (Postfix) with ESMTPA id A36194EE073C;
 Fri, 15 Mar 2024 14:39:11 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6839a842-e2d1-11ee-afdd-a90da7624cb6
MIME-Version: 1.0
Date: Fri, 15 Mar 2024 14:39:11 +0100
From: Nicola Vetrini 
To: Jan Beulich 
Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com,
 ayan.kumar.halder@amd.com, consulting@bugseng.com, Andrew Cooper
 , xen-devel@lists.xenproject.org
Subject: Re: [XEN PATCH v2] amd/iommu: clean up unused guest iommu related
 functions
In-Reply-To: <8f3275b9-ef64-4f49-8d81-fe32b217f74e@suse.com>
References: <324c939125677032af2c1d2e5fb628849415d68e.1710501265.git.nicola.vetrini@bugseng.com>
 <8f3275b9-ef64-4f49-8d81-fe32b217f74e@suse.com>
Message-ID: 
X-Sender: nicola.vetrini@bugseng.com
Organization: BUGSENG s.r.l.
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit

On 2024-03-15 14:31, Jan Beulich wrote:
> On 15.03.2024 12:16, Nicola Vetrini wrote:
>> Delete unused functions from 'iommu_guest.c'.
>> 
>> The 'cmd' parameter of amd_iommu_send_guest_cmd is passed
>> to a function that expects arrays of size 4, therefore
>> specifying explicitly the size also in amd_iommu_send_guest_cmd
>> allows not to accidentally pass a bigger array.
>> 
>> No functional change.
>> 
>> Signed-off-by: Nicola Vetrini 
>> ---
>> All current users of amd_iommu_send_guest pass an array of size 4,
>> hence this is fixing a potential issue noticed by the analyzer for 
>> MISRA C
>> Rule 17.5, not an actual bug.
>> 
>> guest_iommu_add_ptr_log has still one caller, but even that seems
>> suspicious. I left it in and uniformed its parameter type at the
>> moment, so that whether it should be kept can be sorted out later.
>> If that caller indeed should be removed as well, then
>> no function in the file is actually reachable as far as I can tell.
> 
> Afaict this wants removing too.
> 
> But what I'm more puzzled by: You remove all callers of
> amd_iommu_send_guest_cmd(), yet still ...
> 
>> --- a/xen/drivers/passthrough/amd/iommu.h
>> +++ b/xen/drivers/passthrough/amd/iommu.h
>> @@ -346,12 +346,8 @@ void cf_check amd_iommu_crash_shutdown(void);
>> 
>>  /* guest iommu support */
>>  #ifdef CONFIG_HVM
>> -void amd_iommu_send_guest_cmd(struct amd_iommu *iommu, u32 cmd[]);
>> -void guest_iommu_add_ppr_log(struct domain *d, u32 entry[]);
>> -void guest_iommu_add_event_log(struct domain *d, u32 entry[]);
>> -int guest_iommu_init(struct domain* d);
>> -void guest_iommu_destroy(struct domain *d);
>> -int guest_iommu_set_base(struct domain *d, uint64_t base);
>> +void amd_iommu_send_guest_cmd(struct amd_iommu *iommu, uint32_t 
>> cmd[4]);
> 
> ... retain the function.
> 
> Jan

Right, I forgot to remove it.
Thanks,

-- 
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)


From xen-devel-bounces@lists.xenproject.org Fri Mar 15 13:48:31 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 13:48:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693872.1082502 (Exim 4.92)
	(envelope-from )
	id 1rl7v8-0001No-Gi; Fri, 15 Mar 2024 13:48:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693872.1082502; Fri, 15 Mar 2024 13:48:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl7v8-0001Nh-C5; Fri, 15 Mar 2024 13:48:26 +0000
Received: by outflank-mailman (input) for mailman id 693872;
 Fri, 15 Mar 2024 13:48:24 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rl7v6-0001Nb-QC
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 13:48:24 +0000
Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com
 [2607:f8b0:4864:20::829])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b01c2097-e2d2-11ee-a1ee-f123f15fe8a2;
 Fri, 15 Mar 2024 14:48:22 +0100 (CET)
Received: by mail-qt1-x829.google.com with SMTP id
 d75a77b69052e-42a9c21f9ecso10327261cf.0
 for ; Fri, 15 Mar 2024 06:48:22 -0700 (PDT)
Received: from [10.80.67.149] (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 t11-20020a05621421ab00b006911fb61126sm2038924qvc.128.2024.03.15.06.48.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 15 Mar 2024 06:48:20 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b01c2097-e2d2-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710510501; x=1711115301; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:references:cc:to
         :from:content-language:subject:user-agent:mime-version:date
         :message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=h/4Mx/me5VArnQxnWLftSCzOoO+H22p/BzNzM+Ci27E=;
        b=BO8GPfdLvgmfh/fyYgmfWKMkkQEIpR5WNPDNAbmwy9hQHAvdO/7edYxOAMNBfdSVKj
         CBBxEVkX5RCzZMaYm+HRdPcBTNdtCiqijPOsDAmQVjgiSsx2ADs2HzLsNLfczRzOrWhT
         A2xscho8E1jpYKrjO1lQCtLd2CDOhEidxg5X8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710510501; x=1711115301;
        h=content-transfer-encoding:in-reply-to:autocrypt:references:cc:to
         :from:content-language:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=h/4Mx/me5VArnQxnWLftSCzOoO+H22p/BzNzM+Ci27E=;
        b=OczTzL27DSyLHjPO7TBM4aQ4iPprvB89prCF+lHpiw6JXw7qkOdSIvJiZDqFJv/KU0
         m1LtOPAWw5x6ejoKbw2UR9CYdcSPO1wLlwxM8RkqpwJUyPVodrs52VYC17BffZPgOMM5
         VRtj2p1R178kfQVvELbrRyL9gFtBokZ7SzljiQh1fm/Z+QpmINMoOLrl/htOb7L7j7hj
         RskYOEvXVFZL4o9FqXow0rECmVD6LRxOYtw/c/7HbqQYxqxdwVGbUGQDhAawHUwlQuyN
         aA3Ucfqtq3D4X/5b5JTcS/qJ5Qugz7XcjU5vhjISpTwTJWJSr6j3dz2dOjClHVuwSsWf
         lhTA==
X-Forwarded-Encrypted: i=1; AJvYcCXh6ytibVpvuZPGXvWVXfQjg7xSQFIv17BtaWVfh+4N0kJGHn+ZiM5kfDHvvAkNpTNlB0AK5sso9U6tGc4AnLHJJo/18Hl1PrOFqWExECE=
X-Gm-Message-State: AOJu0YwIOBNH6vHJN6BIDKR9ssM+eQhBgHWbefDfiyTNYMb9y+7Pe18c
	WU1oS7KX9S8dJf12D2ue92KYGwHGRaYrEFotxhlWYXG7L+vb22kwwBrwrjHDLrk=
X-Google-Smtp-Source: AGHT+IHAAwemSkLEoFF5g1howmL9IWnB5dQ01YgODjpxfaeC5ztWhvpYyXW+FCtyxYraZMe1Mme2Zw==
X-Received: by 2002:a05:6214:1772:b0:690:d247:8a97 with SMTP id et18-20020a056214177200b00690d2478a97mr4441369qvb.4.1710510501345;
        Fri, 15 Mar 2024 06:48:21 -0700 (PDT)
Message-ID: <33ed3c99-65e2-4ba9-9ff8-7934ecdf26f6@citrix.com>
Date: Fri, 15 Mar 2024 13:48:17 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 7/7] xen/bitops: Delete find_first_set_bit()
Content-Language: en-GB
From: Andrew Cooper 
To: Jan Beulich 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Wei Liu , Stefano Stabellini ,
 Julien Grall , Volodymyr Babchuk
 , Bertrand Marquis ,
 Michal Orzel ,
 Oleksii Kurochko ,
 Shawn Anastasio ,
 "consulting @ bugseng . com" ,
 Simone Ballarin ,
 Federico Serafini ,
 Nicola Vetrini ,
 Xen-devel 
References: <20240313172716.2325427-1-andrew.cooper3@citrix.com>
 <20240313172716.2325427-8-andrew.cooper3@citrix.com>
 <926895a0-f777-4e17-951f-6df0cc24b0f2@suse.com>
 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 14/03/2024 5:14 pm, Andrew Cooper wrote:
> On 14/03/2024 3:59 pm, Jan Beulich wrote:
>> On 13.03.2024 18:27, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/include/asm/bitops.h
>>> +++ b/xen/arch/x86/include/asm/bitops.h
>>> @@ -401,18 +401,6 @@ static always_inline unsigned int __scanbit(unsigned long val, unsigned int max)
>>>      r__;                                                                    \
>>>  })
>>>  
>>> -/**
>>> - * find_first_set_bit - find the first set bit in @word
>>> - * @word: the word to search
>>> - * 
>>> - * Returns the bit-number of the first set bit. The input must *not* be zero.
>>> - */
>>> -static inline unsigned int find_first_set_bit(unsigned long word)
>>> -{
>>> -    asm ( "rep; bsf %1,%0" : "=r" (word) : "rm" (word) );
>>> -    return (unsigned int)word;
>>> -}
>> And you think it's okay to no longer use TZCNT like this when available,
>> where the output doesn't have to have its value set up front?
> This is a particularly evil piece of inline asm.
>
> It is interpreted as BSF or TZCNT depending on the BMI instruction set
> (Haswell/Piledriver era).  Furthermore there are errata on some Intel
> systems where REP BSF behaves as per TZCNT *even* when BMI isn't enumerated.
>
> Which means this piece of asm suffers from all of an undefined output
> register, undefined CF behaviour, and differing ZF behaviour (I believe)
> depending on which hardware you're running on.
>
> The only thing the REP prefix is getting you is a deterministic 0 in the
> destination register,

No, it doesn't.

For a zero input, TZCNT yields the operand size, so you get 16/32/64; 64
in this case.

It also means there's no chance of coming up with a useful alternative
for ffs() to use TZCNT when available.

~Andrew


From xen-devel-bounces@lists.xenproject.org Fri Mar 15 13:55:44 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 13:55:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693874.1082511 (Exim 4.92)
	(envelope-from )
	id 1rl828-0003Gg-6K; Fri, 15 Mar 2024 13:55:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693874.1082511; Fri, 15 Mar 2024 13:55:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl828-0003GZ-2H; Fri, 15 Mar 2024 13:55:40 +0000
Received: by outflank-mailman (input) for mailman id 693874;
 Fri, 15 Mar 2024 13:55:38 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1rl826-0003GT-8Y
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 13:55:38 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rl822-0003Bd-49; Fri, 15 Mar 2024 13:55:34 +0000
Received: from gw1.octic.net ([88.97.20.152] helo=[10.0.1.240])
 by xenbits.xenproject.org with esmtpsa
 (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92)
 (envelope-from )
 id 1rl821-0005JI-NE; Fri, 15 Mar 2024 13:55:33 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=MnVIp05F5yrN6rlMJva4K+AfoeCH/692t0nM0NGmdeA=; b=ahEhHbF8DYGB+ssS/C6JuZQ6L2
	CSkrJTo76q8QwdBoSDJwu5w6mW3rwC8y6HvvoFIMETsM5Os1fu2E3PHaQB6hM3u2BzZ1XxaN2PPu7
	5jGEkVaBGK9Xeu8dpTUY4WP3fnfuiv4o9UjKnu0SAwo8CxDYunrnEtzbRaVul0LOAN8A=;
Message-ID: <3f27abc3-9809-4637-a29c-8aeafcd29ade@xen.org>
Date: Fri, 15 Mar 2024 13:55:31 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] do_multicall and MISRA Rule 8.3\
Content-Language: en-GB
To: Jan Beulich , George Dunlap 
Cc: Stefano Stabellini ,
 federico.serafini@bugseng.com, Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Bertrand Marquis , xen-devel@lists.xenproject.org,
 michal.orzel@amd.com
References: 
 <5a8f90d6-6502-4d93-9fd7-45fea0ede24a@suse.com>
 
 
 
 
 
 
 <63891474-1dc4-4c86-aaf4-cc4d4c53a0ae@suse.com>
 
 
From: Julien Grall 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Jan,

On 15/03/2024 13:24, Jan Beulich wrote:
> On 15.03.2024 13:17, George Dunlap wrote:
>> On Fri, Mar 15, 2024 at 11:57 AM Jan Beulich  wrote:
>>>> It sounds like Andy and Stefano feel like this is a situation where "a
>>>> fixed width quantity is meant"; absent any further guidance from the
>>>> CODING_STYLE about when fixed widths should or should not be used, I
>>>> don't think this change would be a violation of CODING_STYLE.
>>>
>>> As with any not sufficiently clear statement, that's certainly true here,
>>> too. Yet if we try to give as wide meaning as possible to "a fixed width
>>> quantity is meant", there's basically no restriction on use of fixed width
>>> types because everyone can just say "but I mean a fixed width quantity
>>> here". I think the earlier sentence needs taking with higher priority,
>>> i.e. if a basic type does for the purpose, that's what should be used. The
>>> 2nd sentence then only tries to further clarify what the 1st means.
>>
>> Come, now.  There are lots of situations where we just need some sort
>> of number, and there's no real need to worry about the exact size.
>> There are other situations, where we mean "whatever covers the whole
>> address space" or the like, where it makes sense to have something
>> like "unsigned long", which changes size, but in predictable and
>> useful ways.  There are other situations, like when talking over an
>> API to code which may be compiled by a different compiler, or may be
>> running in a different processor mode, where we want to be more
>> specific, and set an exact number of bits.
>>
>> Should we use uint32_t for random loop variables?  Pretty clearly
>> "No".  Should we use uint32_t for the C entry of a hypercall, even
>> though the assembly code allegedly makes that unnecessary?  At least
>> two core maintainers think "maybe just to be safe".  That's hardly a
>> slippery slope of "anyone can say anything".
>>
>> Other than "it's in CODING_STYLE", and "it's not really necessary
>> because it's ensured in the assembly code", you haven't advanced a
>> single reason why "uint32_t" is problematic.
> 
> And it isn't, I never said it would be. But if we set rules for
> ourselves, why would we take the first opportunity to not respect them?

I am a bit confused. Reading through the thread you seem to agree that
the written rules are respected here. So what rules are you talking about?

Or are we just disagreeing on the interpretation? In which case, then 
that's a call for clarification of CODING_STYLE.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Fri Mar 15 14:13:49 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 14:13:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693878.1082520 (Exim 4.92)
	(envelope-from )
	id 1rl8Jc-0006tq-Ju; Fri, 15 Mar 2024 14:13:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693878.1082520; Fri, 15 Mar 2024 14:13:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl8Jc-0006tj-HL; Fri, 15 Mar 2024 14:13:44 +0000
Received: by outflank-mailman (input) for mailman id 693878;
 Fri, 15 Mar 2024 14:13:43 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rl8Jb-0006td-9Y
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 14:13:43 +0000
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com
 [2a00:1450:4864:20::22a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3967bb13-e2d6-11ee-a1ee-f123f15fe8a2;
 Fri, 15 Mar 2024 15:13:41 +0100 (CET)
Received: by mail-lj1-x22a.google.com with SMTP id
 38308e7fff4ca-2d4541bf57eso28119331fa.2
 for ; Fri, 15 Mar 2024 07:13:41 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 gq25-20020a170906e25900b00a46636af78dsm1747620ejb.100.2024.03.15.07.13.39
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 15 Mar 2024 07:13:40 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3967bb13-e2d6-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710512020; x=1711116820; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=sfDziWEKbg23n7KL+NCj4ZqT+RMsRJjyK9lajTzkRjM=;
        b=P5HCwQYSZ0qEFV3g9d4CrYRAnVCTVrXdfStfC320KbAo8hQinGmtrMimaeCkHe3uAI
         9NhB9fMTu4h3UeRDGujW5+tEPNb8zK0pQuFGQhkIyY6AyVs896N0nSnTihnE+4QLsSpH
         R4FlOLjwXGydyVAh3c1J0rA3lh9FsH0q6q1yEqjpDAaVOw5wDunuzpIsuz0Y8et7gDtA
         stHghVPjtTC+Oji+/qJUzQpdOofNHl9xR/4fcS+ubt9T5YPUDnUKKq1rL8NxQWeLS96Y
         iZjHQ0rABnEDcg2SWUQu6oLc58RSXlTkj7PFYkASqC0VlJtGXXw/9jcerqVFk/9vbrPv
         Dpig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710512020; x=1711116820;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=sfDziWEKbg23n7KL+NCj4ZqT+RMsRJjyK9lajTzkRjM=;
        b=massAHtMAJvXJBWXBdaZwCzERQSdHZBOaxm4A2q5TKkwOpDxC2mIkETf6EgCpDY7oY
         2AUp7fvBGWt88nkdWdmCVDfgneD/ciVGcXnKHh8xQXfZOmM7v3n1+MWkDQcrToNPhDtb
         berEIeCsQxTAMPnjajJgXMD19ZOWMeoPzwg/EzuyGiBu6eDeI6hC5dGm08LOYa9N+Vwi
         d6m5qyFp6z9EUDVHMk1bhzVUeCq550zbYXO01C1a74XeTzgXC1GuQWgNGlQxMBppv6ce
         xN/nTOP/hmfpsOAzHh86gJe3eonZbJ+QDWsHDeD+0bXTBGxTcsdyKXKaszv8YWAqYC5v
         Byag==
X-Forwarded-Encrypted: i=1; AJvYcCVdZecSG+SedbITUF8zlRowkAYem3aru2k9+uch/lk5z7E1q5IswtuCQTL3bIi8nGVfC8ZX9GuY2E2njzNnrIUTvN388DvZaROaByEJj/c=
X-Gm-Message-State: AOJu0YyrF88mc5vuqCq4HG6RJAmlBOB089EVxnAhJL5ZwVXbisC3DQJC
	QyYIVKoUQV+R2s/6jgCmK1Pjvsq0cJmZPhduV3XqjGcuue9Aeyur93mhqqHDuA==
X-Google-Smtp-Source: AGHT+IH5ZDPDDiCFv6+tSLuP8UYVAgt/mTfpvUOZS2NM0l9jJQP5m0RwTcrTlUPqyNQN9b3YKDMEOQ==
X-Received: by 2002:a2e:9357:0:b0:2d2:ad40:a7de with SMTP id m23-20020a2e9357000000b002d2ad40a7demr3390835ljh.20.1710512020411;
        Fri, 15 Mar 2024 07:13:40 -0700 (PDT)
Message-ID: <7109ef7e-040c-4d11-ba4b-d898ed2530ff@suse.com>
Date: Fri, 15 Mar 2024 15:13:38 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] do_multicall and MISRA Rule 8.3\
Content-Language: en-US
To: Julien Grall 
Cc: Stefano Stabellini ,
 federico.serafini@bugseng.com, Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Bertrand Marquis , xen-devel@lists.xenproject.org,
 michal.orzel@amd.com, George Dunlap 
References: 
 <5a8f90d6-6502-4d93-9fd7-45fea0ede24a@suse.com>
 
 
 
 
 
 
 <63891474-1dc4-4c86-aaf4-cc4d4c53a0ae@suse.com>
 
 
 <3f27abc3-9809-4637-a29c-8aeafcd29ade@xen.org>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <3f27abc3-9809-4637-a29c-8aeafcd29ade@xen.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 15.03.2024 14:55, Julien Grall wrote:
> Hi Jan,
> 
> On 15/03/2024 13:24, Jan Beulich wrote:
>> On 15.03.2024 13:17, George Dunlap wrote:
>>> On Fri, Mar 15, 2024 at 11:57 AM Jan Beulich  wrote:
>>>>> It sounds like Andy and Stefano feel like this is a situation where "a
>>>>> fixed width quantity is meant"; absent any further guidance from the
>>>>> CODING_STYLE about when fixed widths should or should not be used, I
>>>>> don't think this change would be a violation of CODING_STYLE.
>>>>
>>>> As with any not sufficiently clear statement, that's certainly true here,
>>>> too. Yet if we try to give as wide meaning as possible to "a fixed width
>>>> quantity is meant", there's basically no restriction on use of fixed width
>>>> types because everyone can just say "but I mean a fixed width quantity
>>>> here". I think the earlier sentence needs taking with higher priority,
>>>> i.e. if a basic type does for the purpose, that's what should be used. The
>>>> 2nd sentence then only tries to further clarify what the 1st means.
>>>
>>> Come, now.  There are lots of situations where we just need some sort
>>> of number, and there's no real need to worry about the exact size.
>>> There are other situations, where we mean "whatever covers the whole
>>> address space" or the like, where it makes sense to have something
>>> like "unsigned long", which changes size, but in predictable and
>>> useful ways.  There are other situations, like when talking over an
>>> API to code which may be compiled by a different compiler, or may be
>>> running in a different processor mode, where we want to be more
>>> specific, and set an exact number of bits.
>>>
>>> Should we use uint32_t for random loop variables?  Pretty clearly
>>> "No".  Should we use uint32_t for the C entry of a hypercall, even
>>> though the assembly code allegedly makes that unnecessary?  At least
>>> two core maintainers think "maybe just to be safe".  That's hardly a
>>> slippery slope of "anyone can say anything".
>>>
>>> Other than "it's in CODING_STYLE", and "it's not really necessary
>>> because it's ensured in the assembly code", you haven't advanced a
>>> single reason why "uint32_t" is problematic.
>>
>> And it isn't, I never said it would be. But if we set rules for
>> ourselves, why would we take the first opportunity to not respect them?
> 
> I am a bit confused. Reading through the thread you seem to agree that
> the written rules are respected here. So what rules are you talking about?

What was proposed is use of a fixed width type where according to my
reading ./CODING_STYLE says it shouldn't be used.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Mar 15 14:16:24 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 14:16:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693880.1082531 (Exim 4.92)
	(envelope-from )
	id 1rl8MB-0007R9-0l; Fri, 15 Mar 2024 14:16:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693880.1082531; Fri, 15 Mar 2024 14:16:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl8MA-0007R2-Tb; Fri, 15 Mar 2024 14:16:22 +0000
Received: by outflank-mailman (input) for mailman id 693880;
 Fri, 15 Mar 2024 14:16:21 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rl8M9-0007Qw-P4
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 14:16:21 +0000
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com
 [2a00:1450:4864:20::533])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 98760556-e2d6-11ee-afdd-a90da7624cb6;
 Fri, 15 Mar 2024 15:16:20 +0100 (CET)
Received: by mail-ed1-x533.google.com with SMTP id
 4fb4d7f45d1cf-56845954ffeso2928153a12.2
 for ; Fri, 15 Mar 2024 07:16:20 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 f19-20020a170906085300b00a45a72fadfcsm1744066ejd.23.2024.03.15.07.16.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 15 Mar 2024 07:16:19 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 98760556-e2d6-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710512180; x=1711116980; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=ux6YLkUzuGMO9KL0ahBLZ7FHL+CpXBtBJEPOPKwtP9w=;
        b=ZDfYWn6Qj56HC1m/QCMrEXfX04zWddz64B0LkkBJekmf5s9fqJOYm5s4bJOg7P73sk
         VO+jMtqFdog/KJj4qqchLA6jv1UUrrpMJ9O960wNuTCSb1pjXpjshhjcwOJe7WPHjAt8
         LFmfn7es+X1uf/Wn++f9j9Id27DOYG75jRllak3UCPhNoPHmYcnFC5SxqlTghzq2Hc7h
         +eYPyTdb7zK4tCZnF0J+F3tpMjNh6hksPA6I5Rf1v7t7AkALnfN7mqypdoerdeL7Fjvk
         5Zrlpmh1Yr2vNJFN3hFKmfAyAvjdZrU7Hkf9rHIVUSfsTGR93Q8yRuDlb92bgrJytJ6/
         3xew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710512180; x=1711116980;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=ux6YLkUzuGMO9KL0ahBLZ7FHL+CpXBtBJEPOPKwtP9w=;
        b=GQsKpYGcvaTcwiKbElEHfoilEKgMk6i7kItSwR2IKeBARmxt7Bpj213erJD32smZ1O
         ubwF6Kq2YIgioR8wUHPDqVd+iCas8nmVDQKGYnUv1CEo4RihQ7yQbqttpBc8vhLOX+aQ
         Ypy/EoyAZswbUCnm7FiO1mTo/yIflGVAMbnyWfogIzri/hWVxVdf7QX1C74azkSpns/L
         bCU5LbdmiYx2BUJUWJTQrP5e6LeFf8a7sjg9AbvB3AJIPRLQ1VWlQuyJZNhFzZPHNa4P
         FDG2Xlp4mofFm6fWxgRLBTub+qBNhk+Qi+X9im7x0OF6c16OghAGOYPbbpmhBE9oQHZf
         ATyQ==
X-Forwarded-Encrypted: i=1; AJvYcCVIkTgLwgVVjtx/Eyo9J3+MgSXTSudzTRATLNn0yt01fQXfLpHeIVVC7NkIWAVKBNJOhgRU1yHosv/xY8mRPc8yT/jb/ZPH9Pssw0fsNbs=
X-Gm-Message-State: AOJu0YwNap8ZKLv7DhR8lQ+WocBydC+jvvNv2kKJsQmeKKDRR/b/FdPF
	X54m2Nt37ms/jrJR7Mh5my3TyAzb1BEF2tQKDoqL/hCc/jo3nmfY+R5x45TgmA==
X-Google-Smtp-Source: AGHT+IGd3EvBovu9+rdIOoqYtmnQVVHquQCxnZDmHTNo9nWvOILw3OaO+zpn5cVCXZtqsL/wUWUg6Q==
X-Received: by 2002:a17:907:a095:b0:a46:2445:632a with SMTP id hu21-20020a170907a09500b00a462445632amr4093696ejc.16.1710512180144;
        Fri, 15 Mar 2024 07:16:20 -0700 (PDT)
Message-ID: 
Date: Fri, 15 Mar 2024 15:16:18 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 7/7] xen/bitops: Delete find_first_set_bit()
Content-Language: en-US
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Wei Liu , Stefano Stabellini ,
 Julien Grall , Volodymyr Babchuk
 , Bertrand Marquis ,
 Michal Orzel ,
 Oleksii Kurochko ,
 Shawn Anastasio ,
 "consulting @ bugseng . com" ,
 Simone Ballarin ,
 Federico Serafini ,
 Nicola Vetrini ,
 Xen-devel 
References: <20240313172716.2325427-1-andrew.cooper3@citrix.com>
 <20240313172716.2325427-8-andrew.cooper3@citrix.com>
 <926895a0-f777-4e17-951f-6df0cc24b0f2@suse.com>
 
 <33ed3c99-65e2-4ba9-9ff8-7934ecdf26f6@citrix.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <33ed3c99-65e2-4ba9-9ff8-7934ecdf26f6@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 15.03.2024 14:48, Andrew Cooper wrote:
> On 14/03/2024 5:14 pm, Andrew Cooper wrote:
>> On 14/03/2024 3:59 pm, Jan Beulich wrote:
>>> On 13.03.2024 18:27, Andrew Cooper wrote:
>>>> --- a/xen/arch/x86/include/asm/bitops.h
>>>> +++ b/xen/arch/x86/include/asm/bitops.h
>>>> @@ -401,18 +401,6 @@ static always_inline unsigned int __scanbit(unsigned long val, unsigned int max)
>>>>      r__;                                                                    \
>>>>  })
>>>>  
>>>> -/**
>>>> - * find_first_set_bit - find the first set bit in @word
>>>> - * @word: the word to search
>>>> - * 
>>>> - * Returns the bit-number of the first set bit. The input must *not* be zero.
>>>> - */
>>>> -static inline unsigned int find_first_set_bit(unsigned long word)
>>>> -{
>>>> -    asm ( "rep; bsf %1,%0" : "=r" (word) : "rm" (word) );
>>>> -    return (unsigned int)word;
>>>> -}
>>> And you think it's okay to no longer use TZCNT like this when available,
>>> where the output doesn't have to have its value set up front?
>> This is a particularly evil piece of inline asm.
>>
>> It is interpreted as BSF or TZCNT depending on the BMI instruction set
>> (Haswell/Piledriver era).  Furthermore there are errata on some Intel
>> systems where REP BSF behaves as per TZCNT *even* when BMI isn't enumerated.
>>
>> Which means this piece of asm suffers from all of an undefined output
>> register, undefined CF behaviour, and differing ZF behaviour (I believe)
>> depending on which hardware you're running on.
>>
>> The only thing the REP prefix is getting you is a deterministic 0 in the
>> destination register,
> 
> No, it doesn't.
> 
> For a zero input, TZCNT yields the operand size, so you get 16/32/64; 64
> in this case.
> 
> It also means there's no chance of coming up with a useful alternative
> for ffs() to use TZCNT when available.

Right, for ffs() TZCNT isn't suitable. But for find_first_set_bit() it was,
yielding a reliably out-of-range output for zero input (which BSF wouldn't
guarantee).

Jan


From xen-devel-bounces@lists.xenproject.org Fri Mar 15 14:28:09 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 14:28:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693891.1082540 (Exim 4.92)
	(envelope-from )
	id 1rl8XN-0001Gk-5Q; Fri, 15 Mar 2024 14:27:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693891.1082540; Fri, 15 Mar 2024 14:27:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl8XN-0001Gd-2t; Fri, 15 Mar 2024 14:27:57 +0000
Received: by outflank-mailman (input) for mailman id 693891;
 Fri, 15 Mar 2024 14:27:56 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rl8XM-0001GT-5j; Fri, 15 Mar 2024 14:27:56 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rl8XL-0003sI-Tv; Fri, 15 Mar 2024 14:27:55 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rl8XL-0002OC-J1; Fri, 15 Mar 2024 14:27:55 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rl8XL-0001D9-Ih; Fri, 15 Mar 2024 14:27:55 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=jigkvZ2WWAncg2z3mz1A15Yyc65W3oXzR6d035AaN/8=; b=EFqN3FsvwSzKyMK4IshNqYry5F
	yOH2EJHBUD+7c6iXlyQ6AI59rhUtjvQY+uOLx98o174WzjI4ileS93Iual9h1IlzAU0iE0Xtg1wng
	dEaCF5T91IikQaoPzQWejSNuHOp0lUVjV1gKftscvkNRh4mnzuS7cykbLw+MwiPbMX6g=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [ovmf test] 185049: all pass - PUSHED
X-Osstest-Versions-This:
    ovmf=3840c35e34d1c992268092b6366e26f2acc55a75
X-Osstest-Versions-That:
    ovmf=ccbbc2a5c84a0330b28b726ef0936fc16937005a
From: osstest service owner 
Date: Fri, 15 Mar 2024 14:27:55 +0000

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf                 3840c35e34d1c992268092b6366e26f2acc55a75
baseline version:
 ovmf                 ccbbc2a5c84a0330b28b726ef0936fc16937005a

Last test of basis   185047  2024-03-15 09:11:16 Z    0 days
Testing same since   185049  2024-03-15 12:41:10 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Du Lin 

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-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   ccbbc2a5c8..3840c35e34  3840c35e34d1c992268092b6366e26f2acc55a75 -> xen-tested-master


From xen-devel-bounces@lists.xenproject.org Fri Mar 15 14:45:44 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 14:45:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693898.1082550 (Exim 4.92)
	(envelope-from )
	id 1rl8oU-0004tF-J4; Fri, 15 Mar 2024 14:45:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693898.1082550; Fri, 15 Mar 2024 14:45:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl8oU-0004t8-Gb; Fri, 15 Mar 2024 14:45:38 +0000
Received: by outflank-mailman (input) for mailman id 693898;
 Fri, 15 Mar 2024 14:45:37 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rl8oT-0004t2-BH
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 14:45:37 +0000
Received: from mail-oa1-x2f.google.com (mail-oa1-x2f.google.com
 [2001:4860:4864:20::2f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ad61bee7-e2da-11ee-a1ee-f123f15fe8a2;
 Fri, 15 Mar 2024 15:45:35 +0100 (CET)
Received: by mail-oa1-x2f.google.com with SMTP id
 586e51a60fabf-2220a389390so1105099fac.0
 for ; Fri, 15 Mar 2024 07:45:35 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ad61bee7-e2da-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1710513933; x=1711118733; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=u//wIGFq1yQTQLzBR6MSPkedM2eYpzAAUoGuU2PDtA0=;
        b=N72e1oyvLQsuNBZGZCtRBUzj5WblzIf5aLHT6M9VEsB68Yjz/Fh/J/U0JxQJ2QPc+1
         H1TrHurUUP6apDw/v51VN5MaPRfB7FyHlvLsLTcIaiLsoVAxbB8onp5XbM5t3zU9hsnD
         /gJ3sSC94hXRLGl/PEbQ+dBf8gyvDNUTvYl6M=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710513933; x=1711118733;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=u//wIGFq1yQTQLzBR6MSPkedM2eYpzAAUoGuU2PDtA0=;
        b=rOG0wBAbiFjKP8Gb7HRWaE8T4ZxXwM5VN0VXGBH8yasAulejujgcIkTS0wgnRDw1C3
         pYWSx3OYr8RHEhnbaHyUOOs3gZAit+HkNccvEz66ThrZxP43ZvZDwHXCf7d8YtsiO68P
         D6qx9lBJQGTwKa6CARigGg9DxbZPOHezDGXtOscfnYkhwJFYhtNxPHB7EmL7aN860zwY
         aiJNkJMOicSL7pwbIuI59TgNV46izBzrft/zCZbuHlhT4HWBF6gRcmenYAQZ+BJNnNv0
         00jKv28lY88MyHZ8x01W1wzCmPoqnfGds4YDXYrtS1DcKzuGBW1YYetSGa5NEXWQOjQG
         1Zwg==
X-Forwarded-Encrypted: i=1; AJvYcCW5tgdAQvpLRRT0El5qqyK3rpB04moA0SGqe7aXzqhrvKXQEB+95/FBxv6KbFdPHcXMCbFC2FnbBLnaIbECUMtRUVEhK0Nh9UozPjgZXEs=
X-Gm-Message-State: AOJu0YxzhoNNDoWD94zds+23n0eJf1B8yDVogSi4Ljv9t0LdLqv/IQDt
	CL3HB1J2LQQqGKgAeu67ekoxx2FzJv75plamZuHHszZ8GFQouhS37c/kIA+/aoHPrsKBdGADuED
	4jXj579OkfMbeE8WOkAMjABZ7PlIeFf3mHu6i1A==
X-Google-Smtp-Source: AGHT+IEslSXPGgfyyimDUiovSqXJsNPowt/4E9lwjWThs37NKWEZDujK+wt/j8PmacQfQUJR6sXH8PcjJq5pbFcZzwI=
X-Received: by 2002:a05:6870:200e:b0:221:9cf3:8ae5 with SMTP id
 o14-20020a056870200e00b002219cf38ae5mr3574390oab.24.1710513932865; Fri, 15
 Mar 2024 07:45:32 -0700 (PDT)
MIME-Version: 1.0
References: 
 <5a8f90d6-6502-4d93-9fd7-45fea0ede24a@suse.com> 
 
  
  
 <63891474-1dc4-4c86-aaf4-cc4d4c53a0ae@suse.com> 
  <3f27abc3-9809-4637-a29c-8aeafcd29ade@xen.org>
 <7109ef7e-040c-4d11-ba4b-d898ed2530ff@suse.com>
In-Reply-To: <7109ef7e-040c-4d11-ba4b-d898ed2530ff@suse.com>
From: George Dunlap 
Date: Fri, 15 Mar 2024 14:45:21 +0000
Message-ID: 
Subject: Re: [PATCH] do_multicall and MISRA Rule 8.3\
To: Jan Beulich 
Cc: Julien Grall , Stefano Stabellini , 
	federico.serafini@bugseng.com, Andrew Cooper , 
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
	Bertrand Marquis , xen-devel@lists.xenproject.org, 
	michal.orzel@amd.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 15, 2024 at 2:13=E2=80=AFPM Jan Beulich  wro=
te:
>
> On 15.03.2024 14:55, Julien Grall wrote:
> > Hi Jan,
> >
> > On 15/03/2024 13:24, Jan Beulich wrote:
> >> On 15.03.2024 13:17, George Dunlap wrote:
> >>> On Fri, Mar 15, 2024 at 11:57=E2=80=AFAM Jan Beulich  wrote:
> >>>>> It sounds like Andy and Stefano feel like this is a situation where=
 "a
> >>>>> fixed width quantity is meant"; absent any further guidance from th=
e
> >>>>> CODING_STYLE about when fixed widths should or should not be used, =
I
> >>>>> don't think this change would be a violation of CODING_STYLE.
[snip]
> >>> Other than "it's in CODING_STYLE", and "it's not really necessary
> >>> because it's ensured in the assembly code", you haven't advanced a
> >>> single reason why "uint32_t" is problematic.
> >>
> >> And it isn't, I never said it would be. But if we set rules for
> >> ourselves, why would we take the first opportunity to not respect them=
?
> >
> > I am a bit confused. Reading through the thread you seem to agree that
> > the written rules are respected here. So what rules are you talking abo=
ut?
>
> What was proposed is use of a fixed width type where according to my
> reading ./CODING_STYLE says it shouldn't be used.

This conversation is starting to get frustrating.  That's simply not
what it says, and I pointed that out just a few messages ago.

To reiterate:The text says fixed-width types are OK when a fixed-width
quantity is "meant"; and that in this case, Stefano and Andy "mean" to
use a fixed-width quantity.  The implied subtext of that sentence
could be, "Don't use fixed width types unless there's a good reason to
use a fixed width", and both Andy and Stefano think there's a good
reason.  This argument you haven't really addressed at all, except
with a specious "slippery slope" argument meant to nullify the
exception; and now you attempt to simply ignore.

I venture to assert that for most people, the rules are a means to an
end: That end being code which is correct, robust, fast, easy to
write, maintain, debug, and review patches for.  What I agreed to,
when I accepted this patch, was that *in general* we would avoid using
fixed-width types; but that there were cases where doing so made
sense.  Some of those were discussed in the thread above.

Andy and Stefano have already put forward reasons why they think a
fixed-width type would be better here, which are related to "end
goals": namely, more robust and easy to maintain code.  When I asked
what "end goals" would be negatively impacted by using a fixed-width
type, you explicitly said that there were none!  That the *only*
reason you're continuing to argue is that we have a document somewhere
that says we should -- a document which explicitly acknowledges that
there will be exceptions!

The ideal response would have been to lay out a reasonably
comprehensive set of criteria for when to use basic types, when to use
fixed-width types, and how each criteria advanced the end goals of a
better codebase.  A sufficient response would have been to lay out
reasons why "better codebase", in this instance, tilts towards using a
basic type rather than a fixed-width type.

Saying "That's what the rules say", without motivating it by
explaining how it connects to a better codebase, is just not a helpful
response; and making that argument after it's been pointed out that
that is *not* what the rules say is even worse.

 -George


From xen-devel-bounces@lists.xenproject.org Fri Mar 15 15:04:44 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 15:04:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693902.1082560 (Exim 4.92)
	(envelope-from )
	id 1rl96t-0008T8-4Y; Fri, 15 Mar 2024 15:04:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693902.1082560; Fri, 15 Mar 2024 15:04:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl96t-0008T1-1f; Fri, 15 Mar 2024 15:04:39 +0000
Received: by outflank-mailman (input) for mailman id 693902;
 Fri, 15 Mar 2024 15:04:37 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rl96r-0008Sr-Fc; Fri, 15 Mar 2024 15:04:37 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rl96r-0004ag-68; Fri, 15 Mar 2024 15:04:37 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rl96q-0003tY-P7; Fri, 15 Mar 2024 15:04:36 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rl96q-0005b2-Oe; Fri, 15 Mar 2024 15:04:36 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=JeE4ska4QpVPsNd4Lf3AOG3mMHs8jCgAV4YHn8WQruk=; b=6iW2asgPkMUMKMnuCjvZ9Jd2Uy
	CLTCm/Xzxae5oBeuInUucxjCPE1sAdkZ2vWbrDCA3QNgmrWrY2FRUEOBnRMj1h8o6P/GoCSTTbD55
	rkn29zDtu80HBss+d9vlM4GaOECKCQ5H87zRzl022kkBipFg299YmkRAWLwdL5dF8VzM=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 185045: regressions - FAIL
X-Osstest-Failures:
    xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:windows-install:fail:regression
    xen-unstable:test-armhf-armhf-xl-vhd:guest-start:fail:heisenbug
    xen-unstable:test-armhf-armhf-libvirt-qcow2:guest-start:fail:heisenbug
    xen-unstable:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
    xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-i386-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
X-Osstest-Versions-This:
    xen=d638e304f13a5ef7d125de5ace5f7828a7b25bac
X-Osstest-Versions-That:
    xen=af7fed3fdf82981ebbb09628b278df957569333d
From: osstest service owner 
Date: Fri, 15 Mar 2024 15:04:36 +0000

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-win7-amd64 12 windows-install  fail REGR. vs. 185036

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

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

version targeted for testing:
 xen                  d638e304f13a5ef7d125de5ace5f7828a7b25bac
baseline version:
 xen                  af7fed3fdf82981ebbb09628b278df957569333d

Last test of basis   185036  2024-03-14 16:08:13 Z    0 days
Testing same since   185045  2024-03-15 05:12:15 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper 
  Ayan Kumar Halder 
  Julien Grall 
  Michal Orzel 

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-i386-examine-bios                                 pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-armhf-armhf-libvirt-qcow2                               fail    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-libvirt-raw                                  pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-i386-examine-uefi                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-arm64-arm64-xl-vhd                                      pass    
 test-armhf-armhf-xl-vhd                                      fail    
 test-amd64-i386-xl-vhd                                       pass    


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

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

Explanation of these 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 d638e304f13a5ef7d125de5ace5f7828a7b25bac
Author: Julien Grall 
Date:   Thu Mar 14 17:39:29 2024 +0000

    SUPPORT.MD: Fix matrix generation after 43c416d0d819 and 77c39a53cf5b
    
    The script docs/support-matrix-generate throw the following error on the
    latest staging.
    
    MDCCSR_EL0
    DBGDTR_EL0
    DBGDTRTX_EL0
    DBGDTRRX_EL0
    DBGDSCRINT
    DBGDTRTXINT
    DBGDTRRXINT
    ^ cannot parse status codeblock line:
    MDCCSR_EL0
     ? at docs/parse-support-md line 172,  chunk 1.
    
    With the current indentation, it looks like the script thinks this is
    a status code block.
    
    Solve the issue by switching to a bullet list.
    
    Fixes: 43c416d0d819 ("xen/arm: arm64: Add emulation of Debug Data Transfer Registers")
    Fixes: 77c39a53cf5b ("xen/arm: arm32: Add emulation of Debug Data Transfer Registers")
    Signed-off-by: Julien Grall 
    Acked-by: Andrew Cooper 

commit 77c39a53cf5bfe185b7bff6544c63731513830d3
Author: Ayan Kumar Halder 
Date:   Thu Mar 7 12:39:43 2024 +0000

    xen/arm: arm32: Add emulation of Debug Data Transfer Registers
    
    When user enables HVC_DCC config option in Linux, it invokes access to debug
    transfer register (i.e. DBGDTRTXINT). As this register is not emulated, Xen
    injects an undefined exception to the guest and Linux crashes.
    
    To prevent this crash, introduce a partial emulation of DBGDTR[TR]XINT (these
    registers share the same encoding) as RAZ/WI and DBGDSCRINT as TXfull.
    
    Refer ARM DDI 0487J.a ID042523, G8.3.19, DBGDTRTXint:
    "If TXfull is set to 1, set DTRTX to UNKNOWN".
    
    As a pre-requisite, DBGOSLSR should be emulated in the same way as its AArch64
    variant (i.e. OSLSR_EL1). This is to ensure that DBGOSLSR.OSLK is 0, which
    allows us to skip the emulation of DBGDSCREXT (TXfull is treated as UNK/SBZP)
    and focus on DBGDSCRINT. DBGOSLSR.OSLM[1] is set to 1 to mantain consistency
    with Arm64.
    
    Take the opportunity to fix the minimum EL for DBGDSCRINT, which should be 0.
    
    Signed-off-by: Ayan Kumar Halder 
    Signed-off-by: Michal Orzel 
    Acked-by: Julien Grall 

commit 43c416d0d81957229b5b5d73be694fb1ba149a3e
Author: Michal Orzel 
Date:   Thu Mar 7 12:39:42 2024 +0000

    xen/arm: arm64: Add emulation of Debug Data Transfer Registers
    
    Currently, if user enables HVC_DCC config option in Linux, it invokes access
    to debug data transfer registers (i.e. DBGDTRTX_EL0 on arm64, DBGDTRTXINT on
    arm32). As these registers are not emulated, Xen injects an undefined
    exception to the guest and Linux crashes.
    
    To prevent this crash, introduce a partial emulation of DBGDTR[TR]X_EL0
    (these registers share the same encoding) as RAZ/WI and MDCCSR_EL0 as TXfull.
    
    Refer ARM DDI 0487J.a ID042523, D19.3.8, DBGDTRTX_EL0
    "If TXfull is set to 1, set DTRRX and DTRTX to UNKNOWN".
    
    Thus, any OS is expected to read MDCCSR_EL0 and check for TXfull before
    using DBGDTRTX_EL0. Linux does it via hvc_dcc_init() ---> hvc_dcc_check(),
    and returns -ENODEV in case TXfull bit is still set after writing a test
    character. This way we prevent the guest from making use of HVC DCC as a
    console.
    
    Signed-off-by: Michal Orzel 
    Signed-off-by: Ayan Kumar Halder 
    Acked-by: Julien Grall 

commit bd06cf74fccc065ea67e9dd8c31e70abad1f0507
Author: Ayan Kumar Halder 
Date:   Thu Mar 7 12:39:41 2024 +0000

    xen/arm: Introduce CONFIG_PARTIAL_EMULATION and "partial-emulation" cmd option
    
    There can be situations when the registers cannot be emulated to their full
    functionality. This can be due to the complexity involved. In such cases, one
    can emulate those registers as RAZ/WI for example. We call them as partial
    emulation.
    
    Some registers are non-optional and as such there is nothing preventing an OS
    from accessing them.
    Instead of injecting undefined exception (which might result in crashing a
    guest), one may want to prefer a partial emulation to let the guest running
    (in some cases accepting the fact that it might result in unwanted behavior).
    
    A suitable example of this (as seen in subsequent patches) is emulation of
    DBGDTRTX_EL0 (on Arm64) and DBGDTRTXINT(on Arm32). These non-optional
    registers can be emulated as RAZ/WI and they can be enclosed within
    CONFIG_PARTIAL_EMULATION.
    
    Further, "partial-emulation" command line option allows us to
    enable/disable partial emulation at run time. While CONFIG_PARTIAL_EMULATION
    enables support for partial emulation at compile time (i.e. adds code for
    partial emulation), this option may be enabled or disabled by Yocto or other
    build systems. However if the build system turns this option on, users
    can use scripts like Imagebuilder to generate uboot-script which will append
    "partial-emulation=true" to xen command line to turn on the partial emulation.
    Thus, it helps to avoid rebuilding xen.
    
    By default, "CONFIG_PARTIAL_EMULATION=y" and "partial-emulation=false".
    This is done so that Xen supports partial emulation. However, customers are
    fully aware when they enable partial emulation. It's important to note that
    enabling such support might result in unwanted/non-spec compliant behavior.
    
    Added a note in SUPPORT.md to clarify the security support for partial
    emulation.
    
    Signed-off-by: Ayan Kumar Halder 
    Signed-off-by: Michal Orzel 
    Acked-by: Julien Grall 
(qemu changes not included)


From xen-devel-bounces@lists.xenproject.org Fri Mar 15 15:13:51 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 15:13:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693908.1082571 (Exim 4.92)
	(envelope-from )
	id 1rl9Fj-00023l-4U; Fri, 15 Mar 2024 15:13:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693908.1082571; Fri, 15 Mar 2024 15:13:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl9Fj-00023e-1K; Fri, 15 Mar 2024 15:13:47 +0000
Received: by outflank-mailman (input) for mailman id 693908;
 Fri, 15 Mar 2024 15:13:45 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rl9Fh-00023Y-JV
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 15:13:45 +0000
Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com
 [2607:f8b0:4864:20::736])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9c0be137-e2de-11ee-a1ee-f123f15fe8a2;
 Fri, 15 Mar 2024 16:13:43 +0100 (CET)
Received: by mail-qk1-x736.google.com with SMTP id
 af79cd13be357-7882d713f6fso96033985a.0
 for ; Fri, 15 Mar 2024 08:13:43 -0700 (PDT)
Received: from localhost ([85.31.135.62]) by smtp.gmail.com with ESMTPSA id
 h3-20020ae9ec03000000b007882e204d45sm2150529qkg.37.2024.03.15.08.13.40
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 15 Mar 2024 08:13:41 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9c0be137-e2de-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710515622; x=1711120422; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=VDrHQpeXdupsys/4qNHCU8Q1I9aBw1O7iUAfnS9FPA8=;
        b=EQ3WJ8EBBigNISTmybS/NUSyN6L9G3kz73Ky4oDuLG3jVkHrS9IV7fPasadt6hDwIS
         cydCmFOX4SMTuoL4sEylpLqaoKws6lAi1sgGyIz+tDn+bkAylDR5aLLlKnMQxvEeFqkC
         tt/vz0wLr29DYQg+4Jig6CRDt82pGWeDOIUrM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710515622; x=1711120422;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=VDrHQpeXdupsys/4qNHCU8Q1I9aBw1O7iUAfnS9FPA8=;
        b=q4qHTqs2MkX+UOfPIHXJNjvpJXQTcjCrefyxP3hG2G+dnh7lbrzvSUOMlBdNi1CmoD
         x0lnRliBk7RrmnhetQkEiNyG3ugI2JGSmCFPDaVXIpy47LOyt6lPEOTaudtHupjek/pn
         dfnpE5fxjS2v2pdpANMVMgSJpQ9iRcJ1gnxP+thbb5SGBy6B4fSVgpFXv0HVlpUKTBkC
         2Ro4jO8UwLQaCHgsmLSlLqBaKnDelJJyclLF0jpaVbsq/9/v/PkfhNBP5M0mODMiXu9B
         RImHDqjdiklbHfSrcfmNNoG1+5S2rbfljd8ttTCb1DGnlioDbC9Ft9CKQRJF9UfJ2Gno
         ha8A==
X-Gm-Message-State: AOJu0YywA/PHLq1aH0pKrAS7O6yZoTF+3YzJYi7b+W+VsNAgc89fqtGc
	3kEChCVy4ZE/RJjwqXz6zXqzN5VJ7LhWysm89dSc1wMKvB0bTTXaTgESslCP+hg=
X-Google-Smtp-Source: AGHT+IE3gBfmUccLkJ6PqoN3LYo502VaBZkMs8nQsU3rOl0gPlQoiLfk+IHRG7gOAQ0QtNJdbtm26A==
X-Received: by 2002:a05:620a:4081:b0:789:e93a:ae88 with SMTP id f1-20020a05620a408100b00789e93aae88mr884497qko.15.1710515621813;
        Fri, 15 Mar 2024 08:13:41 -0700 (PDT)
Date: Fri, 15 Mar 2024 16:13:39 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Andrew Cooper 
Cc: Xen-devel 
Subject: Re: [PATCH] xen/vpci: Improve code generation in mask_write()
Message-ID: 
References: <20240315121322.3300387-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20240315121322.3300387-1-andrew.cooper3@citrix.com>

On Fri, Mar 15, 2024 at 12:13:22PM +0000, Andrew Cooper wrote:
> The use of __clear_bit() forces dmask to be spilled to the stack, and
> interferes with the compiler heuristcs for some upcoming improvements to the
> ffs() code generation.
> 
> First, shrink dmask to just the active vectors by making out the upper bits.
> This replaces the "i < msi->vectors" part of the loop condition.
> 
> Next, use a simple while() loop with "clear bottom bit" expressed in plane C,
> which affords the optimiser a far better understanding of what the loop is
> doing.
> 
> Signed-off-by: Andrew Cooper 
> ---
> CC: Roger Pau Monné 
> 
> Noticed when looking at the ffs() code gen improvements.
> 
> Any suggestion on how to test this?  test_vcpi doesn't seem to check anything
> here.  I think I've got the boundary conditions for msi->vectors right, but
> I'd be lying if I said I was certain...

There's no easy way to test this because it relies on having a PCI
device underneath.  test_vpci just checks the logic to add & remove
handlers, but doesn't get remotely close as to attempting to provide
some kind of dummy environment for pass through to be sanity tested.

I should look into it.

> 
> bloat-o-meter reports:
> 
>   add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-28 (-28)
>   Function                                     old     new   delta
>   mask_write                                   142     114     -28
> 
> which is a consequence of the compiler having a much better idea of what's
> going on in the loop.  There's more to come with the ffs() improvements too.
> ---
>  xen/drivers/vpci/msi.c | 10 ++++++----
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/drivers/vpci/msi.c b/xen/drivers/vpci/msi.c
> index d3aa5df08941..30adcf7df05d 100644
> --- a/xen/drivers/vpci/msi.c
> +++ b/xen/drivers/vpci/msi.c
> @@ -169,13 +169,15 @@ static void cf_check mask_write(
>  
>      if ( msi->enabled )
>      {
> -        unsigned int i;
> +        /* Skip changes to vectors which aren't enabled. */
> +        dmask &= (~0U >> (32 - msi->vectors));

Do we need to ASSERT that msi->vectors <= 32 in order to avoid
theoretical UB?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri Mar 15 15:49:06 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 15:49:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693915.1082589 (Exim 4.92)
	(envelope-from )
	id 1rl9nm-0006qC-64; Fri, 15 Mar 2024 15:48:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693915.1082589; Fri, 15 Mar 2024 15:48:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl9nm-0006pn-1z; Fri, 15 Mar 2024 15:48:58 +0000
Received: by outflank-mailman (input) for mailman id 693915;
 Fri, 15 Mar 2024 15:48:57 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rl9nl-0006nS-7r
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 15:48:57 +0000
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com
 [2a00:1450:4864:20::42e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 86abc7b0-e2e3-11ee-a1ee-f123f15fe8a2;
 Fri, 15 Mar 2024 16:48:54 +0100 (CET)
Received: by mail-wr1-x42e.google.com with SMTP id
 ffacd0b85a97d-33e8b957a89so1454670f8f.0
 for ; Fri, 15 Mar 2024 08:48:54 -0700 (PDT)
Received: from localhost.localdomain
 (cpc92320-cmbg19-2-0-cust35.5-4.cable.virginm.net. [82.13.64.36])
 by smtp.gmail.com with ESMTPSA id
 bw29-20020a0560001f9d00b0033ecaf7a2adsm3394689wrb.23.2024.03.15.08.48.52
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 15 Mar 2024 08:48:52 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 86abc7b0-e2e3-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710517733; x=1711122533; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=M6yTHZbvAYgPYQxhgozyTT9aLniHTdMU1NEg2rJApoQ=;
        b=mMTQU2bDAIFzLXorilqonjlKpzUlRTEYg9Sxh5K5puRFN8UhDRjl+1MUaOFZgIIXkn
         fk+6dpbSiHfrzkOvpeQQoUVpTLxQ0PKD4WDIcIIVl/YfQn2oVfZjBccUcgMUJlNXiw/v
         IvkcXetx+g5a1glzdXnJOm9H1KAxKZN+apHrg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710517733; x=1711122533;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=M6yTHZbvAYgPYQxhgozyTT9aLniHTdMU1NEg2rJApoQ=;
        b=G4YoGdfqgCuv8bOZkh6pPwEeCUs+lxUiaibJdExvmsT6bSb8ciDVNNXrITjFkqbfJh
         vhUGcOVqm2uMfxDYruMJIxwvpVOHRUlSQR85a6InfZcEq8o+hpuj/F0M5i4poqvdQuUy
         oZdpM7CR2WjTFf0kg++NFc5qOIn7B80EHmMdjQ7YVsbzh15GLrGvbViAqRfTkD96qFIn
         FNuc0g4dsQsPfszysMJBG3RUBGpJTEiPixxMxy8cAUepMnMJy8fn7vK5acOJNfkGBrfa
         fiVi/PsnwLxbDuHuhaeb9WuD7ReGw5gECFSTPXxCtXqJbbWfHrbPkahLItJl/bhsp4oT
         kkMQ==
X-Gm-Message-State: AOJu0YzL3F1vXkkGVxSx49S4v1vZz2h0kothoPXvxujiEhO1j0iDbTSW
	H76A1L0qUtpAkJ4Zqn8G/UCGRca3OpGr77bqGHnsgZW1ycR7eF6yx/QMTizRq5VsbVgI3Kw34EG
	p
X-Google-Smtp-Source: AGHT+IFTqUWpcn+teuUysKa+tyI2jjGO+7Xocq8aLMXMlR/EmcMAAgN2Cx1B/ge2Su8QE0+I3CG4nA==
X-Received: by 2002:a5d:64a6:0:b0:33e:c601:fcfd with SMTP id m6-20020a5d64a6000000b0033ec601fcfdmr3615824wrp.43.1710517733466;
        Fri, 15 Mar 2024 08:48:53 -0700 (PDT)
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne 
Subject: [OSSTEST PATCH v2 1/3] make-fligh: Fix freebsd guest test test-id
Date: Fri, 15 Mar 2024 15:48:47 +0000
Message-Id: <20240315154849.28819-2-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.39.2
In-Reply-To: <20240315154849.28819-1-anthony.perard@citrix.com>
References: <20240315154849.28819-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Current freebsd as guest tests rely on the variable $qemuu_suffix, but
that one may or may not be set yet, and can't be rely upon. It isn't
set on the first iteration which call test_matrix_do_one(), with
xenarch=amd64 dom0arch=i386, but it is on the second call with
xenarch=amd64 dom0arch=amd64.

Only flights on branch linux-linus and linux-6.1 are changes (and the
disabled linux-next branch). This is because the first call of
test_matrix_do_one() is with dom0arch=amd64 as we skip "i386". On
those branches, we have this changes in jobs names:

-test-amd64-amd64-freebsd11-amd64
-test-amd64-amd64-freebsd12-amd64
+test-amd64-amd64-qemuu-freebsd11-amd64
+test-amd64-amd64-qemuu-freebsd12-amd64

This patch will have the benefit to avoid the opposite changes in all the other
branches as we are going to make some changes to job generation.

Signed-off-by: Anthony PERARD 
---
 make-flight | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/make-flight b/make-flight
index d7eeb4eb..155a0c1f 100755
--- a/make-flight
+++ b/make-flight
@@ -248,11 +248,11 @@ do_freebsd_tests () {
 
   # NB: limit to amd64 ATM due to bugs with the i386 versions (11.3 and 12.1).
   for freebsdarch in amd64; do
-    job_create_test test-$xenarch$kern-$dom0arch$qemuu_suffix-freebsd11-$freebsdarch \
+    job_create_test test-$xenarch$kern-$dom0arch-qemuu-freebsd11-$freebsdarch \
                     test-freebsd xl $xenarch $dom0arch freebsd_arch=$freebsdarch \
  freebsd_image=${FREEBSD_IMAGE_PREFIX-FreeBSD-11.3-RELEASE-}$freebsdarch${FREEBSD_IMAGE_SUFFIX-.raw.xz} \
                     all_hostflags=$most_hostflags,hvm
-    job_create_test test-$xenarch$kern-$dom0arch$qemuu_suffix-freebsd12-$freebsdarch \
+    job_create_test test-$xenarch$kern-$dom0arch-qemuu-freebsd12-$freebsdarch \
                     test-freebsd xl $xenarch $dom0arch freebsd_arch=$freebsdarch \
  freebsd_image=${FREEBSD_IMAGE_PREFIX-FreeBSD-12.1-RELEASE-}$freebsdarch${FREEBSD_IMAGE_SUFFIX-.raw.xz} \
                     all_hostflags=$most_hostflags,hvm
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Fri Mar 15 15:49:06 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 15:49:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693916.1082603 (Exim 4.92)
	(envelope-from )
	id 1rl9nn-0007GF-AQ; Fri, 15 Mar 2024 15:48:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693916.1082603; Fri, 15 Mar 2024 15:48:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl9nn-0007G8-7k; Fri, 15 Mar 2024 15:48:59 +0000
Received: by outflank-mailman (input) for mailman id 693916;
 Fri, 15 Mar 2024 15:48:57 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rl9nl-0006nS-Mo
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 15:48:57 +0000
Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com
 [2a00:1450:4864:20::429])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 87ceb89e-e2e3-11ee-a1ee-f123f15fe8a2;
 Fri, 15 Mar 2024 16:48:56 +0100 (CET)
Received: by mail-wr1-x429.google.com with SMTP id
 ffacd0b85a97d-33e9ba0eadcso1737201f8f.2
 for ; Fri, 15 Mar 2024 08:48:56 -0700 (PDT)
Received: from localhost.localdomain
 (cpc92320-cmbg19-2-0-cust35.5-4.cable.virginm.net. [82.13.64.36])
 by smtp.gmail.com with ESMTPSA id
 bw29-20020a0560001f9d00b0033ecaf7a2adsm3394689wrb.23.2024.03.15.08.48.53
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 15 Mar 2024 08:48:53 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 87ceb89e-e2e3-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710517735; x=1711122535; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Cff+tBKrHygNjFy5WuxJ/QQ3GCTm7QZWRNHRxDD+f0Y=;
        b=qu1d5hb+4s8N3YWQ5eJoYhoguaQaj08LUSi1GH149/ZC++jYG6eIfvdJfhtL/5Kst8
         1DHW1qlwWodEBJTkr2BPvFwuAk+1vkrm6jNXdNJFvOBj0lOqvF/SC80e7+QGAGqTqMKr
         HVp6SGHcLD4rD3kWyw9LF5PggDeBvqlo4m9GI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710517735; x=1711122535;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=Cff+tBKrHygNjFy5WuxJ/QQ3GCTm7QZWRNHRxDD+f0Y=;
        b=qTIxg2dTj9n/nixrtAKRh+LKofEsE/KxlTU1Dsxxy2o4+N0EiTdmZlxT/Db4oSaM1t
         0qUBWaZVGWeqxjwsDaaRZwKRMLNeaCnTEHaghwfjhofVTYfPXFJn2nMIQ6gjn4vPdMig
         cvYOLbmXx/UW6s8UnuddThF81CWv6WAemSWIe7zKD6xNq5HQrhnBHbP7XMtMRIfiakCh
         ekoKoXdz7R1YOZg29rGlHySH4Jdr2jZE+3b13lkl8Z7LQdA44FdgR9oVrlhj16goBwiD
         lGLIQ8elsz+iyWQl9No8RVoDdANMxLnhnmKSrrhYT4HiKYb8HD/qWTpGI3TkZE8vrUaK
         Tulw==
X-Gm-Message-State: AOJu0YwvHzh2njAtn8rpIYTkyDClDkbRU+FmATOirxckMfa16FjVKrYf
	tVpDzLkJOEmViSyUQi+ZtiP15qDb/o7+WT0oW8LoS0ZlCUzXMIzWqMZcWKR+PTKfP90IdfZ3vNT
	K
X-Google-Smtp-Source: AGHT+IE+Q3XFie4743wbkm+Cs8yfcDEkexgkNESoNnzxOrsUwhfQSsm5hBauDDfM7Dkh3oVC0kKRhA==
X-Received: by 2002:a5d:428c:0:b0:33e:774f:e3ca with SMTP id k12-20020a5d428c000000b0033e774fe3camr4246024wrq.64.1710517735190;
        Fri, 15 Mar 2024 08:48:55 -0700 (PDT)
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne 
Subject: [OSSTEST PATCH v2 2/3] mfi-common: Rework toolstack-disk_format test matrix
Date: Fri, 15 Mar 2024 15:48:48 +0000
Message-Id: <20240315154849.28819-3-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.39.2
In-Reply-To: <20240315154849.28819-1-anthony.perard@citrix.com>
References: <20240315154849.28819-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

There is 6 potenteil test of toolstack disk_format combination:
{xl,libvirt}-{raw,vhd,qcow2}. Commit f536e834f673 ("make-flight: Trim
the matrix of disk format flights") introduced a way to avoid testing
on every architecture and actually do only 6 tests accross all
arches, 3 on x86, 3 on armhf (no arm64 at the time).

But, commit 5c70735f177f ("fmtarches: Use dom0arches, not hardcoded
arch list") broke that. There's an extra space ' ' added at the
begining of the string in variable $fmtarches_outer which break the
algorithm. This mean that the combination of xl+raw is never tested
and both armhf and amd64 are testing the same combination of
toolstack+disk_format.

We could just remove the extra ' ', but that would mean 3 extra tests
on armhf and 3 extra tests on arm64. At least x86 would have a test
for each combination.

I'd like to avoid adding more arm* tests due to limited capacity, so
the new goal is to have the 6 combination of toolstack-disk_format
spread on both arm*, where each get to test all possible disk_format.
On x86, we are also going to tests all 6 combinations, which might all
happen on dom0=amd64 if we don't test dom0=i386, or they will be
spread on both kind of dom0.

To avoid too many changes in jobs on x86 with the current list of
jobs, we reverse the order of "i386" and "amd64".

Jobs changes on xen-unstable and most branches:
x86:
+ test-amd64-amd64-xl-raw
+ test-amd64-i386-libvirt-qcow2
arm*:
- test-armhf-armhf-libvirt-qcow2
- test-armhf-armhf-libvirt-raw
- test-armhf-armhf-xl-vhd
+ test-armhf-armhf-libvirt-vhd
+ test-armhf-armhf-xl-qcow2
+ test-armhf-armhf-xl-raw

Jobs changes on linux-{linus,next,6.1}:
x86:
+ test-amd64-amd64-libvirt-vhd
+ test-amd64-amd64-xl-qcow2
+ test-amd64-amd64-xl-raw
arm*:
- test-armhf-armhf-libvirt-qcow2
- test-armhf-armhf-libvirt-raw
- test-armhf-armhf-xl-vhd
+ test-armhf-armhf-libvirt-vhd
+ test-armhf-armhf-xl-qcow2
+ test-armhf-armhf-xl-raw

Signed-off-by: Anthony PERARD 
---

Notes:
    Putting i386 in second or later in dom0arches mean that the freebsd10
    jobs on i386 are been renamed to have -qemuu... but those will
    disappear with a follow-up change to use linux 6.1, as will stop i386
    dom0 tests.

 mfi-common | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/mfi-common b/mfi-common
index d8d167fd..00669677 100644
--- a/mfi-common
+++ b/mfi-common
@@ -649,7 +649,7 @@ test_matrix_iterate () {
       esac
 
       dom0arches=''
-      for dom0arch in i386 armhf amd64 arm64; do
+      for dom0arch in amd64 i386 armhf arm64; do
 
         case ${xenarch}_${dom0arch} in
             amd64_amd64) ;;
@@ -667,9 +667,15 @@ test_matrix_iterate () {
 
         dom0arches+=" $dom0arch"
       done
+      dom0arches=${dom0arches# }
 
       for dom0arch in $dom0arches; do
 
+        # For disk format tests, in do_pv_debian_tests()
+        case $xenarch in
+            arm*) dom0arches="armhf arm64" ;;
+        esac
+
         eval "
             arch_runvars=\"\$ARCH_RUNVARS_$dom0arch\"
         "
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Fri Mar 15 15:49:06 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 15:49:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693917.1082611 (Exim 4.92)
	(envelope-from )
	id 1rl9nn-0007J9-L8; Fri, 15 Mar 2024 15:48:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693917.1082611; Fri, 15 Mar 2024 15:48:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl9nn-0007IH-Dv; Fri, 15 Mar 2024 15:48:59 +0000
Received: by outflank-mailman (input) for mailman id 693917;
 Fri, 15 Mar 2024 15:48:58 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rl9nm-0006uT-J0
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 15:48:58 +0000
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com
 [2a00:1450:4864:20::42e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 889fef52-e2e3-11ee-afdd-a90da7624cb6;
 Fri, 15 Mar 2024 16:48:57 +0100 (CET)
Received: by mail-wr1-x42e.google.com with SMTP id
 ffacd0b85a97d-33ed4d8e9edso418018f8f.2
 for ; Fri, 15 Mar 2024 08:48:57 -0700 (PDT)
Received: from localhost.localdomain
 (cpc92320-cmbg19-2-0-cust35.5-4.cable.virginm.net. [82.13.64.36])
 by smtp.gmail.com with ESMTPSA id
 bw29-20020a0560001f9d00b0033ecaf7a2adsm3394689wrb.23.2024.03.15.08.48.55
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 15 Mar 2024 08:48:55 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 889fef52-e2e3-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710517737; x=1711122537; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=aSG7P4fI+ffI86jlOgtGbDAtFP5aasyP8dl1KHYjsJ4=;
        b=S6BeMBhXrqyNVsIsjw1vyLs3HKmbiN2YzcI+Mjx/5Xm3xaWvUxmvhNVmp651x8SpdH
         NPthCu92ndkyGFMXGIi1jsLsUnG34OnjVf25q2owB7KAX8XL2wC2G4Xpa3cHjt0nqEKw
         29+ud0wa3mNA3GFfkFcLNdOgjfxMSyeZGcank=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710517737; x=1711122537;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=aSG7P4fI+ffI86jlOgtGbDAtFP5aasyP8dl1KHYjsJ4=;
        b=nqpHdfwpPv9CNsN0VgQZBxM7pGlg/oSXxKzKAUbsZGGcbLyPpcP0RZ862G9wtx5NA8
         bZufOVjEbXOiNFdqKz1O2g2S6qQjQ+MYCLkYLXIIi+g3Uyd85OgjtbaD+WSgPoVyqEKp
         7zgJ4QGVexMCIqaTyLhN4n2QZPQWm/Betdj+pzCdSGA045ZVFj9GYZxIBiF+Jxg13GT/
         M1QFfg2CNOKERcR70jbPzO3wT2ij2w8Y/VPI+mpgPV8Zd4H/+PpIRrUVe1k2EMZJNU47
         +TZS0R71QyUwNRxdWyl8/nYfNMmYtK6Hit/TqmpSAy72pBmr2Pdb7ADPxScAfMKzJWF6
         a3OQ==
X-Gm-Message-State: AOJu0YzqOjKcMt7/i378Jm5/YVSWy3uF41DOSH7u8XlsIaSxkPQPBCq+
	tG/HSFqxpIbWZBSImHfqsaE6//agBiMLlqvNdwKW/JpaNyrUy5W9Vcz1gz0k5/0QGCU6xU8Z3gF
	C
X-Google-Smtp-Source: AGHT+IFQzLoBakuE4e4ZmqxbkuXP4H1B4R13QRj/UFxClVBf7R4LSuwX6fNc/0nYNv6w86hkU9C9BQ==
X-Received: by 2002:adf:ee0f:0:b0:33e:7946:4cc8 with SMTP id y15-20020adfee0f000000b0033e79464cc8mr3851476wrn.19.1710517736806;
        Fri, 15 Mar 2024 08:48:56 -0700 (PDT)
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Jan Beulich ,
	Andrew Cooper ,
	Juergen Gross 
Subject: [OSSTEST PATCH v2 3/3] ap-common: Switch to Linux 6.1 by default on x86 + drop dom0 i386
Date: Fri, 15 Mar 2024 15:48:49 +0000
Message-Id: <20240315154849.28819-4-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.39.2
In-Reply-To: <20240315154849.28819-1-anthony.perard@citrix.com>
References: <20240315154849.28819-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

linux-4.19 branch in xenbits is outdated, it haven't been updated and
tested since 2020 as it has been disabled in osstest. Also, this 4.19
branch doesn't build on Bookworm.

So we will start to use a newer version of Linux. We switch to 6.1 for
the Arm* tests recently, so will use that same version for x86.

Also, following commit 3a3089c94913 ("mfi-common: Drop Linux dom0 i386
tests for newer Linux branches"), 32bit dom0 isn't tested on newer
Linux, so we need to drop all dom0 i386 tests wherever the default
linux branch is used. That is, this changes in jobs will apply to
"xen-unstable" branch but also all xen stable branches, seabios, qemu,
osstest, libvirt, so every branch that aren't "linux-*".

Here is the list jobs that changes, and whether they are replace, or
have existing equivalents, on the "xen-unstable" branch. Changes
compared with:
    OSSTEST_CONFIG=standalone-config-example nice eatmydata ./standalone-generate-dump-flight-runvars

Gone, without exiting or new test-amd64-amd64-*:
- test-amd64-i386-freebsd10-amd64
- test-amd64-i386-freebsd10-i386
- test-amd64-i386-qemut-rhel6hvm-amd
- test-amd64-i386-qemut-rhel6hvm-intel
- test-amd64-i386-qemuu-rhel6hvm-amd
- test-amd64-i386-qemuu-rhel6hvm-intel

Gone, but with exiting test-amd64-amd64-* equivalent:
- test-amd64-coresched-i386-xl
- test-amd64-i386-examine
- test-amd64-i386-examine-bios
- test-amd64-i386-examine-uefi
- test-amd64-i386-libvirt
- test-amd64-i386-libvirt-pair
- test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm
- test-amd64-i386-libvirt-xsm
- test-amd64-i386-livepatch
- test-amd64-i386-migrupgrade
- test-amd64-i386-pair
- test-amd64-i386-xl
- test-amd64-i386-xl-pvshim
- test-amd64-i386-xl-qemut-debianhvm-amd64
- test-amd64-i386-xl-qemut-debianhvm-i386-xsm
- test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
- test-amd64-i386-xl-qemut-win7-amd64
- test-amd64-i386-xl-qemut-ws16-amd64
- test-amd64-i386-xl-qemuu-debianhvm-amd64
- test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow
- test-amd64-i386-xl-qemuu-debianhvm-i386-xsm
- test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict
- test-amd64-i386-xl-qemuu-ovmf-amd64
- test-amd64-i386-xl-qemuu-win7-amd64
- test-amd64-i386-xl-qemuu-ws16-amd64
- test-amd64-i386-xl-shadow
- test-amd64-i386-xl-simplat-amd64-buster
- test-amd64-i386-xl-xsm

Gone, but replaced by a new test-amd64-amd64-*:
- test-amd64-i386-libvirt-qcow2
- test-amd64-i386-libvirt-raw
- test-amd64-i386-xl-vhd
+ test-amd64-amd64-libvirt-qcow2
+ test-amd64-amd64-libvirt-raw
+ test-amd64-amd64-xl-vhd

In any case, the list of test would be the same as for the existing
branch "linux-linus" or "linux-6.1" branches.

Signed-off-by: Anthony PERARD 
---

Notes:
    CC: Jan Beulich 
    CC: Andrew Cooper 
    CC: Juergen Gross 

 ap-common  | 2 +-
 mfi-common | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/ap-common b/ap-common
index 48a95a22..5384891b 100644
--- a/ap-common
+++ b/ap-common
@@ -59,7 +59,7 @@
 
 : ${PUSH_TREE_LINUX:=$XENBITS:/home/xen/git/linux-pvops.git}
 : ${BASE_TREE_LINUX:=git://xenbits.xen.org/linux-pvops.git}
-: ${BASE_TAG_LINUX:=tested/linux-4.19}
+: ${BASE_TAG_LINUX:=tested/linux-6.1}
 : ${BASE_TAG_LINUX_ARM:=tested/linux-6.1}
 
 if [ "x${TREE_LINUX}" = x ]; then
diff --git a/mfi-common b/mfi-common
index 00669677..6dc39422 100644
--- a/mfi-common
+++ b/mfi-common
@@ -662,7 +662,7 @@ test_matrix_iterate () {
 
         case "${branch}_${dom0arch}" in
           linux-5.4_i386 | linux-[2-4].*_i386) ;; # keep 32-bit for old linux
-          linux-*_i386) continue;;
+          *_i386) continue;;
         esac
 
         dom0arches+=" $dom0arch"
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Fri Mar 15 15:49:06 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 15:49:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693914.1082584 (Exim 4.92)
	(envelope-from )
	id 1rl9nl-0006np-UA; Fri, 15 Mar 2024 15:48:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693914.1082584; Fri, 15 Mar 2024 15:48:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl9nl-0006nh-RD; Fri, 15 Mar 2024 15:48:57 +0000
Received: by outflank-mailman (input) for mailman id 693914;
 Fri, 15 Mar 2024 15:48:57 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rl9nl-0006nS-0p
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 15:48:57 +0000
Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com
 [2a00:1450:4864:20::436])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 862b1ad4-e2e3-11ee-a1ee-f123f15fe8a2;
 Fri, 15 Mar 2024 16:48:53 +0100 (CET)
Received: by mail-wr1-x436.google.com with SMTP id
 ffacd0b85a97d-33ecbe78c3fso945055f8f.3
 for ; Fri, 15 Mar 2024 08:48:53 -0700 (PDT)
Received: from localhost.localdomain
 (cpc92320-cmbg19-2-0-cust35.5-4.cable.virginm.net. [82.13.64.36])
 by smtp.gmail.com with ESMTPSA id
 bw29-20020a0560001f9d00b0033ecaf7a2adsm3394689wrb.23.2024.03.15.08.48.51
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 15 Mar 2024 08:48:51 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 862b1ad4-e2e3-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710517732; x=1711122532; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:from:to:cc:subject:date:message-id:reply-to;
        bh=DjkFnK8slP+AFdcjYO+Dd1es+dZZ+s27+xdsnD3t2d4=;
        b=lBOk1henbbZsVa3oDDNYXXf8D4/+49iBhitS0U01EE24MV1taQp9JOhFpSkAI38HJh
         vQNwUjfLaZLaFK2ttAYqX8QmKe/1zuJLAc67BbxwZr5jf3DRdbodjb1pbPqHu/pLHRoC
         M+4yx3E2SN6nTJc5tAoOCXxfUE4TRJVir/AIo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710517732; x=1711122532;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=DjkFnK8slP+AFdcjYO+Dd1es+dZZ+s27+xdsnD3t2d4=;
        b=M8bKk9x9C4tJy1K65HMl7JRw3RSuysuqZRpmeauJZRLu2jM+fAohvUACbC/rdE1mup
         HIdDRlRg9IB0qRBZqcbJr3fWwjMI3F3b4pkWQRHRykiAy9RodQjGa/Mojz1yRtu/zRuU
         4+YBOZ/XY1NM/xubVaQCAfQ+759hVAqQMstaOWeabZBjPoO6avLH6/cnDrd06K5WQ9IH
         hJg+ggz56iuXxM8IKwJ32WdNbL2dS+xS3EA7cqs4eF6UXTdZSO5TED+mWcTxWeSpmXjn
         xL4gI0OVYeuBKzA+WPXxG1bMvKuZeBWODKIMQ7v7kdc0NbqfiqWC+3TmDzOdW3UIHK3l
         gXhQ==
X-Gm-Message-State: AOJu0YxH+EzxDExXWxAT4oB1vqRh4ACrR6oaS34jyM+3e2aWC4GzIIyl
	ShZKhOGBjC7VW1UOX8jZNdYVxTnR4ICn8osHqqqdwSPvpU1t6tNcr7p+UFnMmowMB2DaqGtG6Ud
	W
X-Google-Smtp-Source: AGHT+IHTCKBi9KPx6D9K5BzvquMDLr5IRoandLn9mmWlzV4+tZXau1o0KUm8xkcLVLRlOpfuGy7Phg==
X-Received: by 2002:a5d:6a04:0:b0:33d:e6e:b5f6 with SMTP id m4-20020a5d6a04000000b0033d0e6eb5f6mr3743499wru.27.1710517732521;
        Fri, 15 Mar 2024 08:48:52 -0700 (PDT)
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne 
Subject: [OSSTEST PATCH v2 0/3] Switch to Linux 6.1 by default on x86
Date: Fri, 15 Mar 2024 15:48:46 +0000
Message-Id: <20240315154849.28819-1-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.39.2
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Patch series available in this git branch:
https://xenbits.xen.org/git-http/people/aperard/osstest.git br.linux-6.1-v2

Hi,

A set of patch which lead to using Linux 6.1 instead of 4.19 as a default
kernel on x86.

I've check the list of jobs changes with
OSSTEST_CONFIG=standalone-config-example nice eatmydata ./standalone-generate-dump-flight-runvars

All branches are affected with changes, most will have the same changes as the
branch "xen-unstable" (unless the only have a subset of those jobs like
"libvirt"), and linux-{linus,6.1} will have the changes as listed on
linux-linus.

Thanks,

xen-unstable:
- test-amd64-coresched-i386-xl
- test-amd64-i386-examine
- test-amd64-i386-examine-bios
- test-amd64-i386-examine-uefi
- test-amd64-i386-freebsd10-amd64
- test-amd64-i386-freebsd10-i386
- test-amd64-i386-libvirt
- test-amd64-i386-libvirt-pair
- test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm
- test-amd64-i386-libvirt-raw
- test-amd64-i386-libvirt-xsm
- test-amd64-i386-livepatch
- test-amd64-i386-migrupgrade
- test-amd64-i386-pair
- test-amd64-i386-qemut-rhel6hvm-amd
- test-amd64-i386-qemut-rhel6hvm-intel
- test-amd64-i386-qemuu-rhel6hvm-amd
- test-amd64-i386-qemuu-rhel6hvm-intel
- test-amd64-i386-xl
- test-amd64-i386-xl-pvshim
- test-amd64-i386-xl-qemut-debianhvm-amd64
- test-amd64-i386-xl-qemut-debianhvm-i386-xsm
- test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
- test-amd64-i386-xl-qemut-win7-amd64
- test-amd64-i386-xl-qemut-ws16-amd64
- test-amd64-i386-xl-qemuu-debianhvm-amd64
- test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow
- test-amd64-i386-xl-qemuu-debianhvm-i386-xsm
- test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict
- test-amd64-i386-xl-qemuu-ovmf-amd64
- test-amd64-i386-xl-qemuu-win7-amd64
- test-amd64-i386-xl-qemuu-ws16-amd64
- test-amd64-i386-xl-shadow
- test-amd64-i386-xl-simplat-amd64-buster
- test-amd64-i386-xl-vhd
- test-amd64-i386-xl-xsm
- test-armhf-armhf-libvirt-qcow2
- test-armhf-armhf-libvirt-raw
- test-armhf-armhf-xl-vhd
+ test-amd64-amd64-libvirt-qcow2
+ test-amd64-amd64-libvirt-raw
+ test-amd64-amd64-xl-raw
+ test-amd64-amd64-xl-vhd
+ test-armhf-armhf-libvirt-vhd
+ test-armhf-armhf-xl-qcow2
+ test-armhf-armhf-xl-raw

linux-linus:
- test-amd64-amd64-freebsd11-amd64
- test-amd64-amd64-freebsd12-amd64
- test-armhf-armhf-libvirt-qcow2
- test-armhf-armhf-libvirt-raw
- test-armhf-armhf-xl-vhd
+ test-amd64-amd64-libvirt-vhd
+ test-amd64-amd64-qemuu-freebsd11-amd64
+ test-amd64-amd64-qemuu-freebsd12-amd64
+ test-amd64-amd64-xl-qcow2
+ test-amd64-amd64-xl-raw
+ test-armhf-armhf-libvirt-vhd
+ test-armhf-armhf-xl-qcow2
+ test-armhf-armhf-xl-raw

Anthony PERARD (3):
  make-fligh: Fix freebsd guest test test-id
  mfi-common: Rework toolstack-disk_format test matrix
  ap-common: Switch to Linux 6.1 by default on x86 + drop dom0 i386

 ap-common   |  2 +-
 make-flight |  4 ++--
 mfi-common  | 10 ++++++++--
 3 files changed, 11 insertions(+), 5 deletions(-)

-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Fri Mar 15 15:56:01 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 15:56:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693924.1082624 (Exim 4.92)
	(envelope-from )
	id 1rl9uX-0001ae-Av; Fri, 15 Mar 2024 15:55:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693924.1082624; Fri, 15 Mar 2024 15:55:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rl9uX-0001aW-8I; Fri, 15 Mar 2024 15:55:57 +0000
Received: by outflank-mailman (input) for mailman id 693924;
 Fri, 15 Mar 2024 15:55:55 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rl9uV-0001aM-At
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 15:55:55 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8010c385-e2e4-11ee-a1ee-f123f15fe8a2;
 Fri, 15 Mar 2024 16:55:52 +0100 (CET)
Received: from nico.bugseng.com (unknown [46.228.253.194])
 by support.bugseng.com (Postfix) with ESMTPSA id 886D54EE073C;
 Fri, 15 Mar 2024 16:55:51 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8010c385-e2e4-11ee-a1ee-f123f15fe8a2
From: Nicola Vetrini 
To: nicola.vetrini@bugseng.com,
	xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org,
	michal.orzel@amd.com,
	xenia.ragiadakou@amd.com,
	ayan.kumar.halder@amd.com,
	consulting@bugseng.com,
	Jan Beulich ,
	Andrew Cooper 
Subject: [XEN PATCH v3] amd/iommu: clean up unused guest iommu related functions
Date: Fri, 15 Mar 2024 16:55:39 +0100
Message-Id: <98fef1239e4f0e756daf863a9e4e7bb679baa264.1710518105.git.nicola.vetrini@bugseng.com>
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Delete unused functions from 'iommu_guest.c'.

No functional change.

Signed-off-by: Nicola Vetrini 
---
guest_iommu_add_ptr_log has still one caller, but even that seems
suspicious. I left it in and uniformed its parameter type at the
moment, so that whether it should be kept can be sorted out later.
If that caller indeed should be removed as well, then
no function in the file is actually reachable as far as I can tell.

Changes in v2:
- change parameter type to uint32_t
- remove unused functions
Changes in v3:
- also remove amd_iommu_send_guest_cmd
---
 xen/drivers/passthrough/amd/iommu.h       |   7 +-
 xen/drivers/passthrough/amd/iommu_cmd.c   |   7 -
 xen/drivers/passthrough/amd/iommu_guest.c | 762 +---------------------
 3 files changed, 2 insertions(+), 774 deletions(-)

diff --git a/xen/drivers/passthrough/amd/iommu.h b/xen/drivers/passthrough/amd/iommu.h
index 1b62c083ba67..65de88217c07 100644
--- a/xen/drivers/passthrough/amd/iommu.h
+++ b/xen/drivers/passthrough/amd/iommu.h
@@ -346,12 +346,7 @@ void cf_check amd_iommu_crash_shutdown(void);
 
 /* guest iommu support */
 #ifdef CONFIG_HVM
-void amd_iommu_send_guest_cmd(struct amd_iommu *iommu, u32 cmd[]);
-void guest_iommu_add_ppr_log(struct domain *d, u32 entry[]);
-void guest_iommu_add_event_log(struct domain *d, u32 entry[]);
-int guest_iommu_init(struct domain* d);
-void guest_iommu_destroy(struct domain *d);
-int guest_iommu_set_base(struct domain *d, uint64_t base);
+void guest_iommu_add_ppr_log(struct domain *d, uint32_t entry[]);
 #else
 static inline void guest_iommu_add_ppr_log(struct domain *d, uint32_t entry[]) {}
 #endif
diff --git a/xen/drivers/passthrough/amd/iommu_cmd.c b/xen/drivers/passthrough/amd/iommu_cmd.c
index 49b9fcac9410..83c525b84f91 100644
--- a/xen/drivers/passthrough/amd/iommu_cmd.c
+++ b/xen/drivers/passthrough/amd/iommu_cmd.c
@@ -389,10 +389,3 @@ void amd_iommu_flush_all_caches(struct amd_iommu *iommu)
     invalidate_iommu_all(iommu);
     flush_command_buffer(iommu, 0);
 }
-
-void amd_iommu_send_guest_cmd(struct amd_iommu *iommu, u32 cmd[])
-{
-    send_iommu_command(iommu, cmd);
-    /* TBD: Timeout selection may require peeking into cmd[]. */
-    flush_command_buffer(iommu, 0);
-}
diff --git a/xen/drivers/passthrough/amd/iommu_guest.c b/xen/drivers/passthrough/amd/iommu_guest.c
index 4c4252eea116..19bd2e5d8e63 100644
--- a/xen/drivers/passthrough/amd/iommu_guest.c
+++ b/xen/drivers/passthrough/amd/iommu_guest.c
@@ -20,28 +20,7 @@
 
 #include "iommu.h"
 
-#define IOMMU_MMIO_SIZE                         0x8000
-#define IOMMU_MMIO_PAGE_NR                      0x8
-#define RING_BF_LENGTH_MASK                     0x0F000000
-#define RING_BF_LENGTH_SHIFT                    24
-
-#define PASMAX_9_bit                            0x8
-#define GUEST_CR3_1_LEVEL                       0x0
-#define GUEST_ADDRESS_SIZE_6_LEVEL              0x2
-#define HOST_ADDRESS_SIZE_6_LEVEL               0x2
-
 #define reg_to_u64(reg) (((uint64_t)reg.hi << 32) | reg.lo )
-#define u64_to_reg(reg, val) \
-    do \
-    { \
-        (reg)->lo = (u32)(val); \
-        (reg)->hi = (val) >> 32; \
-    } while (0)
-
-static unsigned int get_machine_bdf(struct domain *d, uint16_t guest_bdf)
-{
-    return guest_bdf;
-}
 
 static uint16_t get_guest_bdf(struct domain *d, uint16_t machine_bdf)
 {
@@ -53,62 +32,6 @@ static inline struct guest_iommu *domain_iommu(struct domain *d)
     return dom_iommu(d)->arch.amd.g_iommu;
 }
 
-static inline struct guest_iommu *vcpu_iommu(struct vcpu *v)
-{
-    return dom_iommu(v->domain)->arch.amd.g_iommu;
-}
-
-static void guest_iommu_enable(struct guest_iommu *iommu)
-{
-    iommu->enabled = 1;
-}
-
-static void guest_iommu_disable(struct guest_iommu *iommu)
-{
-    iommu->enabled = 0;
-}
-
-/*
- * The Guest CR3 Table is a table written by the guest kernel, pointing at
- * gCR3 values for PASID transactions to use.  The Device Table Entry points
- * at a system physical address.
- *
- * However, these helpers deliberately use untyped parameters without
- * reference to gfn/mfn because they are used both for programming the real
- * IOMMU, and interpreting a guests programming of its vIOMMU.
- */
-static uint64_t dte_get_gcr3_table(const struct amd_iommu_dte *dte)
-{
-    return (((uint64_t)dte->gcr3_trp_51_31 << 31) |
-            (dte->gcr3_trp_30_15 << 15) |
-            (dte->gcr3_trp_14_12 << 12));
-}
-
-static void dte_set_gcr3_table(struct amd_iommu_dte *dte, uint16_t dom_id,
-                               uint64_t addr, bool gv, uint8_t glx)
-{
-#define GCR3_MASK(hi, lo) (((1UL << ((hi) + 1)) - 1) & ~((1UL << (lo)) - 1))
-
-    /* I bit must be set when gcr3 is enabled */
-    dte->i = true;
-
-    dte->gcr3_trp_14_12 = MASK_EXTR(addr, GCR3_MASK(14, 12));
-    dte->gcr3_trp_30_15 = MASK_EXTR(addr, GCR3_MASK(30, 15));
-    dte->gcr3_trp_51_31 = MASK_EXTR(addr, GCR3_MASK(51, 31));
-
-    dte->domain_id = dom_id;
-    dte->glx = glx;
-    dte->gv = gv;
-
-#undef GCR3_MASK
-}
-
-static unsigned int host_domid(struct domain *d, uint64_t g_domid)
-{
-    /* Only support one PPR device in guest for now */
-    return d->domain_id;
-}
-
 static unsigned long get_gfn_from_base_reg(uint64_t base_raw)
 {
     base_raw &= PADDR_MASK;
@@ -146,24 +69,6 @@ static unsigned long guest_iommu_get_table_mfn(struct domain *d,
     return mfn;
 }
 
-static void guest_iommu_enable_dev_table(struct guest_iommu *iommu)
-{
-    uint32_t length_raw = get_field_from_reg_u32(iommu->dev_table.reg_base.lo,
-                                                 IOMMU_DEV_TABLE_SIZE_MASK,
-                                                 IOMMU_DEV_TABLE_SIZE_SHIFT);
-    iommu->dev_table.size = (length_raw + 1) * PAGE_SIZE;
-}
-
-static void guest_iommu_enable_ring_buffer(struct guest_iommu *iommu,
-                                           struct guest_buffer *buffer,
-                                           uint32_t entry_size)
-{
-    uint32_t length_raw = get_field_from_reg_u32(buffer->reg_base.hi,
-                                                 RING_BF_LENGTH_MASK,
-                                                 RING_BF_LENGTH_SHIFT);
-    buffer->size = entry_size << length_raw;
-}
-
 void guest_iommu_add_ppr_log(struct domain *d, u32 entry[])
 {
     uint16_t gdev_id;
@@ -184,7 +89,7 @@ void guest_iommu_add_ppr_log(struct domain *d, u32 entry[])
     if ( tail >= iommu->ppr_log.size || head >= iommu->ppr_log.size )
     {
         AMD_IOMMU_DEBUG("Error: guest iommu ppr log overflows\n");
-        guest_iommu_disable(iommu);
+        iommu->enabled = 0;
         return;
     }
 
@@ -213,668 +118,3 @@ void guest_iommu_add_ppr_log(struct domain *d, u32 entry[])
 
     guest_iommu_deliver_msi(d);
 }
-
-void guest_iommu_add_event_log(struct domain *d, u32 entry[])
-{
-    uint16_t dev_id;
-    unsigned long mfn, tail, head;
-    event_entry_t *log;
-    struct guest_iommu *iommu;
-
-    if ( !is_hvm_domain(d) )
-        return;
-
-    iommu = domain_iommu(d);
-    if ( !iommu )
-        return;
-
-    tail = iommu->event_log.reg_tail.lo;
-    head = iommu->event_log.reg_head.lo;
-
-    if ( tail >= iommu->event_log.size || head >= iommu->event_log.size )
-    {
-        AMD_IOMMU_DEBUG("Error: guest iommu event overflows\n");
-        guest_iommu_disable(iommu);
-        return;
-    }
-
-    mfn = guest_iommu_get_table_mfn(d, reg_to_u64(iommu->event_log.reg_base),
-                                    tail);
-    ASSERT(mfn_valid(_mfn(mfn)));
-
-    log = map_domain_page(_mfn(mfn)) + (tail & ~PAGE_MASK);
-
-    /* re-write physical device id into virtual device id */
-    dev_id = get_guest_bdf(d, iommu_get_devid_from_cmd(entry[0]));
-    iommu_set_devid_to_cmd(&entry[0], dev_id);
-    memcpy(log, entry, sizeof(event_entry_t));
-
-    /* Now shift event log tail pointer */
-    tail += sizeof(event_entry_t);
-    if ( tail >= iommu->event_log.size )
-    {
-        tail = 0;
-        iommu->reg_status.lo |= IOMMU_STATUS_EVENT_LOG_OVERFLOW;
-    }
-
-    iommu->event_log.reg_tail.lo = tail;
-    unmap_domain_page(log);
-
-    guest_iommu_deliver_msi(d);
-}
-
-static int do_complete_ppr_request(struct domain *d, cmd_entry_t *cmd)
-{
-    uint16_t dev_id;
-    struct amd_iommu *iommu;
-
-    dev_id = get_machine_bdf(d, iommu_get_devid_from_cmd(cmd->data[0]));
-    iommu = find_iommu_for_device(0, dev_id);
-
-    if ( !iommu )
-    {
-        AMD_IOMMU_DEBUG("%s: Fail to find iommu for bdf %x\n",
-                        __func__, dev_id);
-        return -ENODEV;
-    }
-
-    /* replace virtual device id into physical */
-    iommu_set_devid_to_cmd(&cmd->data[0], dev_id);
-    amd_iommu_send_guest_cmd(iommu, cmd->data);
-
-    return 0;
-}
-
-static int do_invalidate_pages(struct domain *d, cmd_entry_t *cmd)
-{
-    uint16_t gdom_id, hdom_id;
-    struct amd_iommu *iommu = NULL;
-
-    gdom_id = get_field_from_reg_u32(cmd->data[1],
-                                    IOMMU_INV_IOMMU_PAGES_DOMAIN_ID_MASK,
-                                    IOMMU_INV_IOMMU_PAGES_DOMAIN_ID_SHIFT);
-
-    hdom_id = host_domid(d, gdom_id);
-    set_field_in_reg_u32(hdom_id, cmd->data[1],
-                         IOMMU_INV_IOMMU_PAGES_DOMAIN_ID_MASK,
-                         IOMMU_INV_IOMMU_PAGES_DOMAIN_ID_SHIFT, &cmd->data[1]);
-
-    for_each_amd_iommu ( iommu )
-        amd_iommu_send_guest_cmd(iommu, cmd->data);
-
-    return 0;
-}
-
-static int do_invalidate_all(struct domain *d, cmd_entry_t *cmd)
-{
-    struct amd_iommu *iommu = NULL;
-
-    for_each_amd_iommu ( iommu )
-        amd_iommu_flush_all_pages(d);
-
-    return 0;
-}
-
-static int do_invalidate_iotlb_pages(struct domain *d, cmd_entry_t *cmd)
-{
-    struct amd_iommu *iommu;
-    uint16_t dev_id;
-
-    dev_id = get_machine_bdf(d, iommu_get_devid_from_cmd(cmd->data[0]));
-
-    iommu = find_iommu_for_device(0, dev_id);
-    if ( !iommu )
-    {
-        AMD_IOMMU_DEBUG("%s: Fail to find iommu for bdf %x\n",
-                         __func__, dev_id);
-        return -ENODEV;
-    }
-
-    iommu_set_devid_to_cmd(&cmd->data[0], dev_id);
-    amd_iommu_send_guest_cmd(iommu, cmd->data);
-
-    return 0;
-}
-
-static int do_completion_wait(struct domain *d, cmd_entry_t *cmd)
-{
-    bool com_wait_int, i, s;
-    struct guest_iommu *iommu;
-    unsigned long gfn;
-    p2m_type_t p2mt;
-
-    iommu = domain_iommu(d);
-
-    i = cmd->data[0] & IOMMU_COMP_WAIT_I_FLAG_MASK;
-    s = cmd->data[0] & IOMMU_COMP_WAIT_S_FLAG_MASK;
-
-    if ( i )
-        iommu->reg_status.lo |= IOMMU_STATUS_COMP_WAIT_INT;
-
-    if ( s )
-    {
-        uint64_t gaddr_lo, gaddr_hi, gaddr_64, data;
-        void *vaddr;
-
-        data = (uint64_t)cmd->data[3] << 32 | cmd->data[2];
-        gaddr_lo = get_field_from_reg_u32(cmd->data[0],
-                                          IOMMU_COMP_WAIT_ADDR_LOW_MASK,
-                                          IOMMU_COMP_WAIT_ADDR_LOW_SHIFT);
-        gaddr_hi = get_field_from_reg_u32(cmd->data[1],
-                                          IOMMU_COMP_WAIT_ADDR_HIGH_MASK,
-                                          IOMMU_COMP_WAIT_ADDR_HIGH_SHIFT);
-
-        gaddr_64 = (gaddr_hi << 32) | (gaddr_lo << 3);
-
-        gfn = gaddr_64 >> PAGE_SHIFT;
-        vaddr = map_domain_page(get_gfn(d, gfn ,&p2mt));
-        put_gfn(d, gfn);
-
-        write_u64_atomic((uint64_t *)(vaddr + (gaddr_64 & (PAGE_SIZE-1))),
-                         data);
-        unmap_domain_page(vaddr);
-    }
-
-    com_wait_int = iommu->reg_status.lo & IOMMU_STATUS_COMP_WAIT_INT;
-
-    if ( iommu->reg_ctrl.com_wait_int_en && com_wait_int )
-        guest_iommu_deliver_msi(d);
-
-    return 0;
-}
-
-static int do_invalidate_dte(struct domain *d, cmd_entry_t *cmd)
-{
-    uint16_t gbdf, mbdf, req_id, gdom_id, hdom_id, prev_domid;
-    struct amd_iommu_dte *gdte, *mdte, *dte_base;
-    struct amd_iommu *iommu = NULL;
-    struct guest_iommu *g_iommu;
-    uint64_t gcr3_gfn, gcr3_mfn;
-    uint8_t glx, gv;
-    unsigned long dte_mfn, flags;
-    p2m_type_t p2mt;
-
-    g_iommu = domain_iommu(d);
-    gbdf = iommu_get_devid_from_cmd(cmd->data[0]);
-    mbdf = get_machine_bdf(d, gbdf);
-
-    /* Guest can only update DTEs for its passthru devices */
-    if ( mbdf == 0 || gbdf == 0 )
-        return 0;
-
-    /* Sometimes guest invalidates devices from non-exists dtes */
-    if ( (gbdf * sizeof(struct amd_iommu_dte)) > g_iommu->dev_table.size )
-        return 0;
-
-    dte_mfn = guest_iommu_get_table_mfn(d,
-                                        reg_to_u64(g_iommu->dev_table.reg_base),
-                                        sizeof(struct amd_iommu_dte) * gbdf);
-    ASSERT(mfn_valid(_mfn(dte_mfn)));
-
-    /* Read guest dte information */
-    dte_base = map_domain_page(_mfn(dte_mfn));
-
-    gdte = &dte_base[gbdf % (PAGE_SIZE / sizeof(struct amd_iommu_dte))];
-
-    gdom_id = gdte->domain_id;
-    gcr3_gfn = dte_get_gcr3_table(gdte) >> PAGE_SHIFT;
-    glx = gdte->glx;
-    gv = gdte->gv;
-
-    unmap_domain_page(dte_base);
-
-    /* Do not update host dte before gcr3 has been set */
-    if ( gcr3_gfn == 0 )
-        return 0;
-
-    gcr3_mfn = mfn_x(get_gfn(d, gcr3_gfn, &p2mt));
-    put_gfn(d, gcr3_gfn);
-
-    ASSERT(mfn_valid(_mfn(gcr3_mfn)));
-
-    iommu = find_iommu_for_device(0, mbdf);
-    if ( !iommu )
-    {
-        AMD_IOMMU_DEBUG("%s: Fail to find iommu for bdf %x!\n",
-                        __func__, mbdf);
-        return -ENODEV;
-    }
-
-    /* Setup host device entry */
-    hdom_id = host_domid(d, gdom_id);
-    req_id = get_dma_requestor_id(iommu->seg, mbdf);
-    dte_base = iommu->dev_table.buffer;
-    mdte = &dte_base[req_id];
-    prev_domid = mdte->domain_id;
-
-    spin_lock_irqsave(&iommu->lock, flags);
-    dte_set_gcr3_table(mdte, hdom_id, gcr3_mfn << PAGE_SHIFT, gv, glx);
-
-    spin_unlock_irqrestore(&iommu->lock, flags);
-
-    amd_iommu_flush_device(iommu, req_id, prev_domid);
-
-    return 0;
-}
-
-static void cf_check guest_iommu_process_command(void *data)
-{
-    unsigned long opcode, tail, head, cmd_mfn;
-    cmd_entry_t *cmd;
-    struct domain *d = data;
-    struct guest_iommu *iommu;
-
-    iommu = domain_iommu(d);
-
-    if ( !iommu->enabled )
-        return;
-
-    head = iommu->cmd_buffer.reg_head.lo;
-    tail = iommu->cmd_buffer.reg_tail.lo;
-
-    /* Tail pointer is rolled over by guest driver, value outside
-     * cmd_buffer_entries cause iommu disabled
-     */
-
-    if ( tail >= iommu->cmd_buffer.size || head >= iommu->cmd_buffer.size )
-    {
-        AMD_IOMMU_DEBUG("Error: guest iommu cmd buffer overflows\n");
-        guest_iommu_disable(iommu);
-        return;
-    }
-
-    while ( head != tail )
-    {
-        int ret = 0;
-
-        cmd_mfn = guest_iommu_get_table_mfn(d,
-                                            reg_to_u64(iommu->cmd_buffer.reg_base),
-                                            head);
-        ASSERT(mfn_valid(_mfn(cmd_mfn)));
-
-        cmd = map_domain_page(_mfn(cmd_mfn)) + (head & ~PAGE_MASK);
-
-        opcode = get_field_from_reg_u32(cmd->data[1],
-                                        IOMMU_CMD_OPCODE_MASK,
-                                        IOMMU_CMD_OPCODE_SHIFT);
-        switch ( opcode )
-        {
-        case IOMMU_CMD_COMPLETION_WAIT:
-            ret = do_completion_wait(d, cmd);
-            break;
-        case IOMMU_CMD_INVALIDATE_DEVTAB_ENTRY:
-            ret = do_invalidate_dte(d, cmd);
-            break;
-        case IOMMU_CMD_INVALIDATE_IOMMU_PAGES:
-            ret = do_invalidate_pages(d, cmd);
-            break;
-        case IOMMU_CMD_INVALIDATE_IOTLB_PAGES:
-            ret = do_invalidate_iotlb_pages(d, cmd);
-            break;
-        case IOMMU_CMD_INVALIDATE_INT_TABLE:
-            break;
-        case IOMMU_CMD_COMPLETE_PPR_REQUEST:
-            ret = do_complete_ppr_request(d, cmd);
-            break;
-        case IOMMU_CMD_INVALIDATE_IOMMU_ALL:
-            ret = do_invalidate_all(d, cmd);
-            break;
-        default:
-            AMD_IOMMU_DEBUG("CMD: Unknown command cmd_type = %lx "
-                            "head = %ld\n", opcode, head);
-            break;
-        }
-
-        unmap_domain_page(cmd);
-        head += sizeof(cmd_entry_t);
-        if ( head >= iommu->cmd_buffer.size )
-            head = 0;
-        if ( ret )
-            guest_iommu_disable(iommu);
-    }
-
-    /* Now shift cmd buffer head pointer */
-    iommu->cmd_buffer.reg_head.lo = head;
-    return;
-}
-
-static int guest_iommu_write_ctrl(struct guest_iommu *iommu, uint64_t val)
-{
-    union amd_iommu_control newctrl = { .raw = val };
-
-    if ( newctrl.iommu_en )
-    {
-        guest_iommu_enable(iommu);
-        guest_iommu_enable_dev_table(iommu);
-    }
-
-    if ( newctrl.iommu_en && newctrl.cmd_buf_en )
-    {
-        guest_iommu_enable_ring_buffer(iommu, &iommu->cmd_buffer,
-                                       sizeof(cmd_entry_t));
-        /* Enable iommu command processing */
-        tasklet_schedule(&iommu->cmd_buffer_tasklet);
-    }
-
-    if ( newctrl.iommu_en && newctrl.event_log_en )
-    {
-        guest_iommu_enable_ring_buffer(iommu, &iommu->event_log,
-                                       sizeof(event_entry_t));
-        iommu->reg_status.lo |=  IOMMU_STATUS_EVENT_LOG_RUN;
-        iommu->reg_status.lo &= ~IOMMU_STATUS_EVENT_LOG_OVERFLOW;
-    }
-
-    if ( newctrl.iommu_en && newctrl.ppr_en && newctrl.ppr_log_en )
-    {
-        guest_iommu_enable_ring_buffer(iommu, &iommu->ppr_log,
-                                       sizeof(ppr_entry_t));
-        iommu->reg_status.lo |=  IOMMU_STATUS_PPR_LOG_RUN;
-        iommu->reg_status.lo &= ~IOMMU_STATUS_PPR_LOG_OVERFLOW;
-    }
-
-    if ( newctrl.iommu_en && iommu->reg_ctrl.cmd_buf_en &&
-         !newctrl.cmd_buf_en )
-    {
-        /* Disable iommu command processing */
-        tasklet_kill(&iommu->cmd_buffer_tasklet);
-    }
-
-    if ( iommu->reg_ctrl.event_log_en && !newctrl.event_log_en )
-        iommu->reg_status.lo &= ~IOMMU_STATUS_EVENT_LOG_RUN;
-
-    if ( iommu->reg_ctrl.iommu_en && !newctrl.iommu_en )
-        guest_iommu_disable(iommu);
-
-    iommu->reg_ctrl = newctrl;
-
-    return 0;
-}
-
-static uint64_t iommu_mmio_read64(struct guest_iommu *iommu,
-                                  unsigned long offset)
-{
-    uint64_t val;
-
-    switch ( offset )
-    {
-    case IOMMU_DEV_TABLE_BASE_LOW_OFFSET:
-        val = reg_to_u64(iommu->dev_table.reg_base);
-        break;
-    case IOMMU_CMD_BUFFER_BASE_LOW_OFFSET:
-        val = reg_to_u64(iommu->cmd_buffer.reg_base);
-        break;
-    case IOMMU_EVENT_LOG_BASE_LOW_OFFSET:
-        val = reg_to_u64(iommu->event_log.reg_base);
-        break;
-    case IOMMU_PPR_LOG_BASE_LOW_OFFSET:
-        val = reg_to_u64(iommu->ppr_log.reg_base);
-        break;
-    case IOMMU_CMD_BUFFER_HEAD_OFFSET:
-        val = reg_to_u64(iommu->cmd_buffer.reg_head);
-        break;
-    case IOMMU_CMD_BUFFER_TAIL_OFFSET:
-        val = reg_to_u64(iommu->cmd_buffer.reg_tail);
-        break;
-    case IOMMU_EVENT_LOG_HEAD_OFFSET:
-        val = reg_to_u64(iommu->event_log.reg_head);
-        break;
-    case IOMMU_EVENT_LOG_TAIL_OFFSET:
-        val = reg_to_u64(iommu->event_log.reg_tail);
-        break;
-    case IOMMU_PPR_LOG_HEAD_OFFSET:
-        val = reg_to_u64(iommu->ppr_log.reg_head);
-        break;
-    case IOMMU_PPR_LOG_TAIL_OFFSET:
-        val = reg_to_u64(iommu->ppr_log.reg_tail);
-        break;
-    case IOMMU_CONTROL_MMIO_OFFSET:
-        val = iommu->reg_ctrl.raw;
-        break;
-    case IOMMU_STATUS_MMIO_OFFSET:
-        val = reg_to_u64(iommu->reg_status);
-        break;
-    case IOMMU_EXT_FEATURE_MMIO_OFFSET:
-        val = iommu->reg_ext_feature.raw;
-        break;
-
-    default:
-        AMD_IOMMU_DEBUG("Guest reads unknown mmio offset = %lx\n", offset);
-        val = 0;
-        break;
-    }
-
-    return val;
-}
-
-static int cf_check guest_iommu_mmio_read(
-    struct vcpu *v, unsigned long addr, unsigned int len, unsigned long *pval)
-{
-    struct guest_iommu *iommu = vcpu_iommu(v);
-    unsigned long offset;
-    uint64_t val;
-    uint32_t mmio, shift;
-    uint64_t mask = 0;
-
-    offset = addr - iommu->mmio_base;
-
-    if ( unlikely((offset & (len - 1 )) || (len > 8)) )
-    {
-        AMD_IOMMU_DEBUG("iommu mmio read access is not aligned:"
-                        " offset = %lx, len = %x\n", offset, len);
-        return X86EMUL_UNHANDLEABLE;
-    }
-
-    mask = (len == 8) ? ~0ULL : (1ULL << (len * 8)) - 1;
-    shift = (offset & 7u) * 8;
-
-    /* mmio access is always aligned on 8-byte boundary */
-    mmio = offset & (~7u);
-
-    spin_lock(&iommu->lock);
-    val = iommu_mmio_read64(iommu, mmio);
-    spin_unlock(&iommu->lock);
-
-    *pval = (val >> shift ) & mask;
-
-    return X86EMUL_OKAY;
-}
-
-static void guest_iommu_mmio_write64(struct guest_iommu *iommu,
-                                    unsigned long offset, uint64_t val)
-{
-    switch ( offset )
-    {
-    case IOMMU_DEV_TABLE_BASE_LOW_OFFSET:
-        u64_to_reg(&iommu->dev_table.reg_base, val);
-        break;
-    case IOMMU_CMD_BUFFER_BASE_LOW_OFFSET:
-        u64_to_reg(&iommu->cmd_buffer.reg_base, val);
-        break;
-    case IOMMU_EVENT_LOG_BASE_LOW_OFFSET:
-        u64_to_reg(&iommu->event_log.reg_base, val);
-        break;
-    case IOMMU_PPR_LOG_BASE_LOW_OFFSET:
-        u64_to_reg(&iommu->ppr_log.reg_base, val);
-        break;
-    case IOMMU_CONTROL_MMIO_OFFSET:
-        guest_iommu_write_ctrl(iommu, val);
-        break;
-    case IOMMU_CMD_BUFFER_HEAD_OFFSET:
-        iommu->cmd_buffer.reg_head.lo = val & IOMMU_RING_BUFFER_PTR_MASK;
-        break;
-    case IOMMU_CMD_BUFFER_TAIL_OFFSET:
-        iommu->cmd_buffer.reg_tail.lo = val & IOMMU_RING_BUFFER_PTR_MASK;
-        tasklet_schedule(&iommu->cmd_buffer_tasklet);
-        break;
-    case IOMMU_EVENT_LOG_HEAD_OFFSET:
-        iommu->event_log.reg_head.lo = val & IOMMU_RING_BUFFER_PTR_MASK;
-        break;
-    case IOMMU_EVENT_LOG_TAIL_OFFSET:
-        iommu->event_log.reg_tail.lo = val & IOMMU_RING_BUFFER_PTR_MASK;
-        break;
-    case IOMMU_PPR_LOG_HEAD_OFFSET:
-        iommu->ppr_log.reg_head.lo = val & IOMMU_RING_BUFFER_PTR_MASK;
-        break;
-    case IOMMU_PPR_LOG_TAIL_OFFSET:
-        iommu->ppr_log.reg_tail.lo = val & IOMMU_RING_BUFFER_PTR_MASK;
-        break;
-    case IOMMU_STATUS_MMIO_OFFSET:
-        val &= IOMMU_STATUS_EVENT_LOG_OVERFLOW |
-               IOMMU_STATUS_EVENT_LOG_INT |
-               IOMMU_STATUS_COMP_WAIT_INT |
-               IOMMU_STATUS_PPR_LOG_OVERFLOW |
-               IOMMU_STATUS_PPR_LOG_INT |
-               IOMMU_STATUS_GAPIC_LOG_OVERFLOW |
-               IOMMU_STATUS_GAPIC_LOG_INT;
-        u64_to_reg(&iommu->reg_status, reg_to_u64(iommu->reg_status) & ~val);
-        break;
-
-    default:
-        AMD_IOMMU_DEBUG("guest writes unknown mmio offset = %lx,"
-                        " val = %" PRIx64 "\n", offset, val);
-        break;
-    }
-}
-
-static int cf_check guest_iommu_mmio_write(
-    struct vcpu *v, unsigned long addr, unsigned int len, unsigned long val)
-{
-    struct guest_iommu *iommu = vcpu_iommu(v);
-    unsigned long offset;
-    uint64_t reg_old, mmio;
-    uint32_t shift;
-    uint64_t mask = 0;
-
-    offset = addr - iommu->mmio_base;
-
-    if ( unlikely((offset & (len - 1)) || (len > 8)) )
-    {
-        AMD_IOMMU_DEBUG("iommu mmio write access is not aligned:"
-                        " offset = %lx, len = %x\n", offset, len);
-        return X86EMUL_UNHANDLEABLE;
-    }
-
-    mask = (len == 8) ? ~0ULL : (1ULL << (len * 8)) - 1;
-    shift = (offset & 7) * 8;
-
-    /* mmio access is always aligned on 8-byte boundary */
-    mmio = offset & ~7;
-
-    spin_lock(&iommu->lock);
-
-    reg_old = iommu_mmio_read64(iommu, mmio);
-    reg_old &= ~(mask << shift);
-    val = reg_old | ((val & mask) << shift);
-    guest_iommu_mmio_write64(iommu, mmio, val);
-
-    spin_unlock(&iommu->lock);
-
-    return X86EMUL_OKAY;
-}
-
-int guest_iommu_set_base(struct domain *d, uint64_t base)
-{
-    p2m_type_t t;
-    struct guest_iommu *iommu = domain_iommu(d);
-
-    if ( !iommu )
-        return -EACCES;
-
-    iommu->mmio_base = base;
-    base >>= PAGE_SHIFT;
-
-    for ( int i = 0; i < IOMMU_MMIO_PAGE_NR; i++ )
-    {
-        unsigned long gfn = base + i;
-
-        get_gfn_query(d, gfn, &t);
-        p2m_change_type_one(d, gfn, t, p2m_mmio_dm);
-        put_gfn(d, gfn);
-    }
-
-    return 0;
-}
-
-/* Initialize mmio read only bits */
-static void guest_iommu_reg_init(struct guest_iommu *iommu)
-{
-    union amd_iommu_ext_features ef = {
-        /* Support prefetch */
-        .flds.pref_sup = 1,
-        /* Support PPR log */
-        .flds.ppr_sup = 1,
-        /* Support guest translation */
-        .flds.gt_sup = 1,
-        /* Support invalidate all command */
-        .flds.ia_sup = 1,
-        /* Host translation size has 6 levels */
-        .flds.hats = HOST_ADDRESS_SIZE_6_LEVEL,
-        /* Guest translation size has 6 levels */
-        .flds.gats = GUEST_ADDRESS_SIZE_6_LEVEL,
-        /* Single level gCR3 */
-        .flds.glx_sup = GUEST_CR3_1_LEVEL,
-        /* 9 bit PASID */
-        .flds.pas_max = PASMAX_9_bit,
-    };
-
-    iommu->reg_ext_feature = ef;
-}
-
-static int cf_check guest_iommu_mmio_range(struct vcpu *v, unsigned long addr)
-{
-    struct guest_iommu *iommu = vcpu_iommu(v);
-
-    return iommu && addr >= iommu->mmio_base &&
-           addr < iommu->mmio_base + IOMMU_MMIO_SIZE;
-}
-
-static const struct hvm_mmio_ops iommu_mmio_ops = {
-    .check = guest_iommu_mmio_range,
-    .read = guest_iommu_mmio_read,
-    .write = guest_iommu_mmio_write
-};
-
-/* Domain specific initialization */
-int guest_iommu_init(struct domain* d)
-{
-    struct guest_iommu *iommu;
-    struct domain_iommu *hd = dom_iommu(d);
-
-    if ( !is_hvm_domain(d) || !is_iommu_enabled(d) || !iommuv2_enabled ||
-         !has_viommu(d) )
-        return 0;
-
-    iommu = xzalloc(struct guest_iommu);
-    if ( !iommu )
-    {
-        AMD_IOMMU_DEBUG("Error allocating guest iommu structure.\n");
-        return 1;
-    }
-
-    guest_iommu_reg_init(iommu);
-    iommu->mmio_base = ~0ULL;
-    iommu->domain = d;
-    hd->arch.amd.g_iommu = iommu;
-
-    tasklet_init(&iommu->cmd_buffer_tasklet, guest_iommu_process_command, d);
-
-    spin_lock_init(&iommu->lock);
-
-    register_mmio_handler(d, &iommu_mmio_ops);
-
-    return 0;
-}
-
-void guest_iommu_destroy(struct domain *d)
-{
-    struct guest_iommu *iommu;
-
-    iommu = domain_iommu(d);
-    if ( !iommu )
-        return;
-
-    tasklet_kill(&iommu->cmd_buffer_tasklet);
-    xfree(iommu);
-
-    dom_iommu(d)->arch.amd.g_iommu = NULL;
-}
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Mar 15 16:19:47 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 16:19:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693931.1082634 (Exim 4.92)
	(envelope-from )
	id 1rlAHV-000673-6j; Fri, 15 Mar 2024 16:19:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693931.1082634; Fri, 15 Mar 2024 16:19:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rlAHV-00066w-3I; Fri, 15 Mar 2024 16:19:41 +0000
Received: by outflank-mailman (input) for mailman id 693931;
 Fri, 15 Mar 2024 16:19:40 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rlAHU-00066q-6a
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 16:19:40 +0000
Received: from mail-qv1-xf2c.google.com (mail-qv1-xf2c.google.com
 [2607:f8b0:4864:20::f2c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d1bdf95a-e2e7-11ee-afdd-a90da7624cb6;
 Fri, 15 Mar 2024 17:19:38 +0100 (CET)
Received: by mail-qv1-xf2c.google.com with SMTP id
 6a1803df08f44-690c1747c3cso20834606d6.0
 for ; Fri, 15 Mar 2024 09:19:38 -0700 (PDT)
Received: from [10.80.67.149] (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 gg8-20020a056214252800b00690befbe5a5sm2165055qvb.74.2024.03.15.09.19.36
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 15 Mar 2024 09:19:36 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d1bdf95a-e2e7-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710519577; x=1711124377; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=CKu39slrG6a1VHtNDYlfaSJE1xOSh8axePXwE8pvjAU=;
        b=aShxp+o+L0vL7eb1VGdusHz33qT4jywa3ITUeOJ/WL+kjk+rBh2qC288mjKPqFPTiQ
         1ADweh4PdDPskLr6+FuJuUF9kvQXAblm1dl43RDcvB5VF0vEXEyEAZgIbeXCmuG7usVV
         v+mcejb3Y902VzSvXPXZ5HOqFL60sLIDFYNPI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710519577; x=1711124377;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=CKu39slrG6a1VHtNDYlfaSJE1xOSh8axePXwE8pvjAU=;
        b=MwxRcLWwRGJin5STAVbrjFeu2OedOgcWs3F74M8Zp1zPhsqn+cU0lxQ1xNU8OIQasi
         nK7TioQfZXssnPPinotb4+vYcm6mQxM86GeNCycJ2itTWlHRCnQExvtbIWKu0iaZsmC2
         N7cMnZsXtakf3EZZVJP4Su/iPEeD87qu2b7QfrnGaW51J2GA3BOjx1v2o4pG0eAlhAD0
         zIL3rEXTJL2Tp3OtOkcCGrnN1ysY48l0WW6fK2lvBvRw8BzkHqZq6o2GpNDaw94dzuxm
         hVr2A4Q+MX4wUlN7GPLXMYlugRnWFd8s66YN85sN7ScSDqhLhoLMxB52vlBOmuZnOUmo
         LmLA==
X-Gm-Message-State: AOJu0YwRHIYYyImKme3yQ4vSPwNGTWpVHgVUP4Ve3O07kREkPOnrejUS
	9G3VVfcBjHbccFp/l4qOEVIK1qM96HG8xhOb1/QH7mt/c+4f+kNRyhL62d40KI31X/s9sPmCKLI
	2
X-Google-Smtp-Source: AGHT+IFlA/OyynrsC5394jj0QMAwobbYSi/kX11eVpi5V7h2Mpeg4vY4wqUHPgCKvwUzUZ8Po1dRVA==
X-Received: by 2002:a0c:f2d0:0:b0:690:d4e7:1374 with SMTP id c16-20020a0cf2d0000000b00690d4e71374mr9548918qvm.13.1710519577378;
        Fri, 15 Mar 2024 09:19:37 -0700 (PDT)
Message-ID: <38ed2c56-67f3-4d6d-9766-38a294661af6@citrix.com>
Date: Fri, 15 Mar 2024 16:19:34 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/vpci: Improve code generation in mask_write()
Content-Language: en-GB
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: Xen-devel 
References: <20240315121322.3300387-1-andrew.cooper3@citrix.com>
 
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 15/03/2024 3:13 pm, Roger Pau Monné wrote:
> On Fri, Mar 15, 2024 at 12:13:22PM +0000, Andrew Cooper wrote:
>> The use of __clear_bit() forces dmask to be spilled to the stack, and
>> interferes with the compiler heuristcs for some upcoming improvements to the
>> ffs() code generation.
>>
>> First, shrink dmask to just the active vectors by making out the upper bits.
>> This replaces the "i < msi->vectors" part of the loop condition.
>>
>> Next, use a simple while() loop with "clear bottom bit" expressed in plane C,
>> which affords the optimiser a far better understanding of what the loop is
>> doing.
>>
>> Signed-off-by: Andrew Cooper 
>> ---
>> CC: Roger Pau Monné 
>>
>> Noticed when looking at the ffs() code gen improvements.
>>
>> Any suggestion on how to test this?  test_vcpi doesn't seem to check anything
>> here.  I think I've got the boundary conditions for msi->vectors right, but
>> I'd be lying if I said I was certain...
> There's no easy way to test this because it relies on having a PCI
> device underneath.  test_vpci just checks the logic to add & remove
> handlers, but doesn't get remotely close as to attempting to provide
> some kind of dummy environment for pass through to be sanity tested.
>
> I should look into it.
>
>> bloat-o-meter reports:
>>
>>   add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-28 (-28)
>>   Function                                     old     new   delta
>>   mask_write                                   142     114     -28
>>
>> which is a consequence of the compiler having a much better idea of what's
>> going on in the loop.  There's more to come with the ffs() improvements too.
>> ---
>>  xen/drivers/vpci/msi.c | 10 ++++++----
>>  1 file changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/xen/drivers/vpci/msi.c b/xen/drivers/vpci/msi.c
>> index d3aa5df08941..30adcf7df05d 100644
>> --- a/xen/drivers/vpci/msi.c
>> +++ b/xen/drivers/vpci/msi.c
>> @@ -169,13 +169,15 @@ static void cf_check mask_write(
>>  
>>      if ( msi->enabled )
>>      {
>> -        unsigned int i;
>> +        /* Skip changes to vectors which aren't enabled. */
>> +        dmask &= (~0U >> (32 - msi->vectors));
> Do we need to ASSERT that msi->vectors <= 32 in order to avoid
> theoretical UB?

I don't think so.  Things have gone catastrophically wrong elsewhere to
get here with 64 or 128.

All this does is stop calling the set-mask callback for disabled vectors.

~Andrew


From xen-devel-bounces@lists.xenproject.org Fri Mar 15 16:21:35 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 16:21:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693934.1082643 (Exim 4.92)
	(envelope-from )
	id 1rlAJK-0007Xb-Jr; Fri, 15 Mar 2024 16:21:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693934.1082643; Fri, 15 Mar 2024 16:21:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rlAJK-0007XU-HK; Fri, 15 Mar 2024 16:21:34 +0000
Received: by outflank-mailman (input) for mailman id 693934;
 Fri, 15 Mar 2024 16:21:33 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rlAJJ-0007X5-Br
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 16:21:33 +0000
Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 14c33a26-e2e8-11ee-a1ee-f123f15fe8a2;
 Fri, 15 Mar 2024 17:21:30 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org
 [IPv6:2a07:de40:b281:104:10:150:64:97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out2.suse.de (Postfix) with ESMTPS id D68271FB6E;
 Fri, 15 Mar 2024 16:21:29 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 9915813460;
 Fri, 15 Mar 2024 16:21:29 +0000 (UTC)
Received: from dovecot-director2.suse.de ([10.150.64.162])
 by imap1.dmz-prg2.suse.org with ESMTPSA id oEGZI4l19GW/ZAAAD6G6ig
 (envelope-from ); Fri, 15 Mar 2024 16:21:29 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 14c33a26-e2e8-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1710519690; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=Gbzilk9ApOhr8+018t9FIvtoIo5XwKCUVQ8A1h+AmDk=;
	b=HKdUVaXgdpmscw17ZIih86wMI4dC7oRYvja0brDtkhHldJWFruJHRfnvd1XVbTi0aYtoYO
	4ADzEUuEvN4j1nJOlQO7GMLou9wj/bR+lO1sSxik6P5+B7HFp3c6okOs4wXafsz8Rbc5dw
	3eIAwu0XsTNU92tWzHkwm+uR+r6pdMo=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1710519689; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=Gbzilk9ApOhr8+018t9FIvtoIo5XwKCUVQ8A1h+AmDk=;
	b=R6NfWTKz1XQcrqarSgoMVKK7urdMpfq73Bq1jW8XfX4BHc+nuy21WWB8nW4gH5NI9BPJb8
	VXtqnZauwyGnMlx9axQJtni26fMeh2phg4slZzYckmeDx3oEQjhu/gBFf9YCfSqVtSwaVN
	wny/gUqszwX9T/CXU9B2dkhkFIhpiV0=
Message-ID: <8448ac1a-9da2-4884-a6a1-a38ebd5b71f8@suse.com>
Date: Fri, 15 Mar 2024 17:21:28 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [OSSTEST PATCH v2 3/3] ap-common: Switch to Linux 6.1 by default
 on x86 + drop dom0 i386
To: Anthony PERARD , xen-devel@lists.xenproject.org
Cc: Roger Pau Monne , Jan Beulich ,
 Andrew Cooper 
References: <20240315154849.28819-1-anthony.perard@citrix.com>
 <20240315154849.28819-4-anthony.perard@citrix.com>
Content-Language: en-US
From: Juergen Gross 
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <20240315154849.28819-4-anthony.perard@citrix.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------C0N0Hf0SzeGME0kMHWBSWKdF"
X-Spam-Level: 
Authentication-Results: smtp-out2.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b=R6NfWTKz
X-Rspamd-Server: rspamd2.dmz-prg2.suse.org
X-Spamd-Result: default: False [-5.40 / 50.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 XM_UA_NO_VERSION(0.01)[];
	 SPAMHAUS_XBL(0.00)[2a07:de40:b281:104:10:150:64:97:from];
	 TO_DN_SOME(0.00)[];
	 HAS_ATTACHMENT(0.00)[];
	 MIME_BASE64_TEXT_BOGUS(1.00)[];
	 RCPT_COUNT_FIVE(0.00)[5];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_TRACE(0.00)[suse.com:+];
	 MIME_BASE64_TEXT(0.10)[];
	 MX_GOOD(-0.01)[];
	 SIGNED_PGP(-2.00)[];
	 NEURAL_HAM_SHORT(-0.20)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~];
	 MID_RHS_MATCH_FROM(0.00)[];
	 BAYES_HAM(-3.00)[100.00%];
	 MIME_UNKNOWN(0.10)[application/pgp-keys];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[suse.com:s=susede1];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain];
	 DKIM_SIGNED(0.00)[suse.com:s=susede1];
	 DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:dkim,suse.com:email];
	 FUZZY_BLOCKED(0.00)[rspamd.com];
	 RCVD_TLS_ALL(0.00)[];
	 RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:104:10:150:64:97:from]
X-Spam-Score: -5.40
X-Rspamd-Queue-Id: D68271FB6E
X-Spam-Flag: NO

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------C0N0Hf0SzeGME0kMHWBSWKdF
Content-Type: multipart/mixed; boundary="------------mtSumtQHxB8sPFdKxaERrt5R";
 protected-headers="v1"
From: Juergen Gross 
To: Anthony PERARD , xen-devel@lists.xenproject.org
Cc: Roger Pau Monne , Jan Beulich ,
 Andrew Cooper 
Message-ID: <8448ac1a-9da2-4884-a6a1-a38ebd5b71f8@suse.com>
Subject: Re: [OSSTEST PATCH v2 3/3] ap-common: Switch to Linux 6.1 by default
 on x86 + drop dom0 i386
References: <20240315154849.28819-1-anthony.perard@citrix.com>
 <20240315154849.28819-4-anthony.perard@citrix.com>
In-Reply-To: <20240315154849.28819-4-anthony.perard@citrix.com>
Autocrypt-Gossip: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE
 ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2
 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd
 pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ
 tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf
 OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C
 v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou
 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU
 jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z
 DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP
 Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ
 dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef
 AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs=

--------------mtSumtQHxB8sPFdKxaERrt5R
Content-Type: multipart/mixed; boundary="------------wyKdG8iQy4ECEdCvHtAQxKoC"

--------------wyKdG8iQy4ECEdCvHtAQxKoC
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMTUuMDMuMjQgMTY6NDgsIEFudGhvbnkgUEVSQVJEIHdyb3RlOg0KPiBsaW51eC00LjE5
IGJyYW5jaCBpbiB4ZW5iaXRzIGlzIG91dGRhdGVkLCBpdCBoYXZlbid0IGJlZW4gdXBkYXRl
ZCBhbmQNCj4gdGVzdGVkIHNpbmNlIDIwMjAgYXMgaXQgaGFzIGJlZW4gZGlzYWJsZWQgaW4g
b3NzdGVzdC4gQWxzbywgdGhpcyA0LjE5DQo+IGJyYW5jaCBkb2Vzbid0IGJ1aWxkIG9uIEJv
b2t3b3JtLg0KPiANCj4gU28gd2Ugd2lsbCBzdGFydCB0byB1c2UgYSBuZXdlciB2ZXJzaW9u
IG9mIExpbnV4LiBXZSBzd2l0Y2ggdG8gNi4xIGZvcg0KPiB0aGUgQXJtKiB0ZXN0cyByZWNl
bnRseSwgc28gd2lsbCB1c2UgdGhhdCBzYW1lIHZlcnNpb24gZm9yIHg4Ni4NCj4gDQo+IEFs
c28sIGZvbGxvd2luZyBjb21taXQgM2EzMDg5Yzk0OTEzICgibWZpLWNvbW1vbjogRHJvcCBM
aW51eCBkb20wIGkzODYNCj4gdGVzdHMgZm9yIG5ld2VyIExpbnV4IGJyYW5jaGVzIiksIDMy
Yml0IGRvbTAgaXNuJ3QgdGVzdGVkIG9uIG5ld2VyDQo+IExpbnV4LCBzbyB3ZSBuZWVkIHRv
IGRyb3AgYWxsIGRvbTAgaTM4NiB0ZXN0cyB3aGVyZXZlciB0aGUgZGVmYXVsdA0KPiBsaW51
eCBicmFuY2ggaXMgdXNlZC4gVGhhdCBpcywgdGhpcyBjaGFuZ2VzIGluIGpvYnMgd2lsbCBh
cHBseSB0bw0KPiAieGVuLXVuc3RhYmxlIiBicmFuY2ggYnV0IGFsc28gYWxsIHhlbiBzdGFi
bGUgYnJhbmNoZXMsIHNlYWJpb3MsIHFlbXUsDQo+IG9zc3Rlc3QsIGxpYnZpcnQsIHNvIGV2
ZXJ5IGJyYW5jaCB0aGF0IGFyZW4ndCAibGludXgtKiIuDQo+IA0KPiBIZXJlIGlzIHRoZSBs
aXN0IGpvYnMgdGhhdCBjaGFuZ2VzLCBhbmQgd2hldGhlciB0aGV5IGFyZSByZXBsYWNlLCBv
cg0KPiBoYXZlIGV4aXN0aW5nIGVxdWl2YWxlbnRzLCBvbiB0aGUgInhlbi11bnN0YWJsZSIg
YnJhbmNoLiBDaGFuZ2VzDQo+IGNvbXBhcmVkIHdpdGg6DQo+ICAgICAgT1NTVEVTVF9DT05G
SUc9c3RhbmRhbG9uZS1jb25maWctZXhhbXBsZSBuaWNlIGVhdG15ZGF0YSAuL3N0YW5kYWxv
bmUtZ2VuZXJhdGUtZHVtcC1mbGlnaHQtcnVudmFycw0KPiANCj4gR29uZSwgd2l0aG91dCBl
eGl0aW5nIG9yIG5ldyB0ZXN0LWFtZDY0LWFtZDY0LSo6DQo+IC0gdGVzdC1hbWQ2NC1pMzg2
LWZyZWVic2QxMC1hbWQ2NA0KPiAtIHRlc3QtYW1kNjQtaTM4Ni1mcmVlYnNkMTAtaTM4Ng0K
PiAtIHRlc3QtYW1kNjQtaTM4Ni1xZW11dC1yaGVsNmh2bS1hbWQNCj4gLSB0ZXN0LWFtZDY0
LWkzODYtcWVtdXQtcmhlbDZodm0taW50ZWwNCj4gLSB0ZXN0LWFtZDY0LWkzODYtcWVtdXUt
cmhlbDZodm0tYW1kDQo+IC0gdGVzdC1hbWQ2NC1pMzg2LXFlbXV1LXJoZWw2aHZtLWludGVs
DQo+IA0KPiBHb25lLCBidXQgd2l0aCBleGl0aW5nIHRlc3QtYW1kNjQtYW1kNjQtKiBlcXVp
dmFsZW50Og0KPiAtIHRlc3QtYW1kNjQtY29yZXNjaGVkLWkzODYteGwNCj4gLSB0ZXN0LWFt
ZDY0LWkzODYtZXhhbWluZQ0KPiAtIHRlc3QtYW1kNjQtaTM4Ni1leGFtaW5lLWJpb3MNCj4g
LSB0ZXN0LWFtZDY0LWkzODYtZXhhbWluZS11ZWZpDQo+IC0gdGVzdC1hbWQ2NC1pMzg2LWxp
YnZpcnQNCj4gLSB0ZXN0LWFtZDY0LWkzODYtbGlidmlydC1wYWlyDQo+IC0gdGVzdC1hbWQ2
NC1pMzg2LWxpYnZpcnQtcWVtdXUtZGViaWFuaHZtLWFtZDY0LXhzbQ0KPiAtIHRlc3QtYW1k
NjQtaTM4Ni1saWJ2aXJ0LXhzbQ0KPiAtIHRlc3QtYW1kNjQtaTM4Ni1saXZlcGF0Y2gNCj4g
LSB0ZXN0LWFtZDY0LWkzODYtbWlncnVwZ3JhZGUNCj4gLSB0ZXN0LWFtZDY0LWkzODYtcGFp
cg0KPiAtIHRlc3QtYW1kNjQtaTM4Ni14bA0KPiAtIHRlc3QtYW1kNjQtaTM4Ni14bC1wdnNo
aW0NCj4gLSB0ZXN0LWFtZDY0LWkzODYteGwtcWVtdXQtZGViaWFuaHZtLWFtZDY0DQo+IC0g
dGVzdC1hbWQ2NC1pMzg2LXhsLXFlbXV0LWRlYmlhbmh2bS1pMzg2LXhzbQ0KPiAtIHRlc3Qt
YW1kNjQtaTM4Ni14bC1xZW11dC1zdHViZG9tLWRlYmlhbmh2bS1hbWQ2NC14c20NCj4gLSB0
ZXN0LWFtZDY0LWkzODYteGwtcWVtdXQtd2luNy1hbWQ2NA0KPiAtIHRlc3QtYW1kNjQtaTM4
Ni14bC1xZW11dC13czE2LWFtZDY0DQo+IC0gdGVzdC1hbWQ2NC1pMzg2LXhsLXFlbXV1LWRl
Ymlhbmh2bS1hbWQ2NA0KPiAtIHRlc3QtYW1kNjQtaTM4Ni14bC1xZW11dS1kZWJpYW5odm0t
YW1kNjQtc2hhZG93DQo+IC0gdGVzdC1hbWQ2NC1pMzg2LXhsLXFlbXV1LWRlYmlhbmh2bS1p
Mzg2LXhzbQ0KPiAtIHRlc3QtYW1kNjQtaTM4Ni14bC1xZW11dS1kbXJlc3RyaWN0LWFtZDY0
LWRtcmVzdHJpY3QNCj4gLSB0ZXN0LWFtZDY0LWkzODYteGwtcWVtdXUtb3ZtZi1hbWQ2NA0K
PiAtIHRlc3QtYW1kNjQtaTM4Ni14bC1xZW11dS13aW43LWFtZDY0DQo+IC0gdGVzdC1hbWQ2
NC1pMzg2LXhsLXFlbXV1LXdzMTYtYW1kNjQNCj4gLSB0ZXN0LWFtZDY0LWkzODYteGwtc2hh
ZG93DQo+IC0gdGVzdC1hbWQ2NC1pMzg2LXhsLXNpbXBsYXQtYW1kNjQtYnVzdGVyDQo+IC0g
dGVzdC1hbWQ2NC1pMzg2LXhsLXhzbQ0KPiANCj4gR29uZSwgYnV0IHJlcGxhY2VkIGJ5IGEg
bmV3IHRlc3QtYW1kNjQtYW1kNjQtKjoNCj4gLSB0ZXN0LWFtZDY0LWkzODYtbGlidmlydC1x
Y293Mg0KPiAtIHRlc3QtYW1kNjQtaTM4Ni1saWJ2aXJ0LXJhdw0KPiAtIHRlc3QtYW1kNjQt
aTM4Ni14bC12aGQNCj4gKyB0ZXN0LWFtZDY0LWFtZDY0LWxpYnZpcnQtcWNvdzINCj4gKyB0
ZXN0LWFtZDY0LWFtZDY0LWxpYnZpcnQtcmF3DQo+ICsgdGVzdC1hbWQ2NC1hbWQ2NC14bC12
aGQNCj4gDQo+IEluIGFueSBjYXNlLCB0aGUgbGlzdCBvZiB0ZXN0IHdvdWxkIGJlIHRoZSBz
YW1lIGFzIGZvciB0aGUgZXhpc3RpbmcNCj4gYnJhbmNoICJsaW51eC1saW51cyIgb3IgImxp
bnV4LTYuMSIgYnJhbmNoZXMuDQo+IA0KPiBTaWduZWQtb2ZmLWJ5OiBBbnRob255IFBFUkFS
RCA8YW50aG9ueS5wZXJhcmRAY2l0cml4LmNvbT4NCg0KQWNrZWQtYnk6IEp1ZXJnZW4gR3Jv
c3MgPGpncm9zc0BzdXNlLmNvbT4NCg0KLi4uIGtub3dpbmcgdGhpcyBpcyBraW5kIG9mIG1l
YW5pbmdsZXNzIGdpdmVuIHRoYXQgSSdtIG5vIG1haW50YWluZXIgb2YNCk9TU3Rlc3QsIGJ1
dCBJJ2QgbGlrZSB0byBkb2N1bWVudCB0aGF0IEknbSBmaW5lIHdpdGggdGhlIGludGVudGlv
biBvZiB0aGUNCmNoYW5nZS4gOi0pDQoNCg0KSnVlcmdlbg0K
--------------wyKdG8iQy4ECEdCvHtAQxKoC
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri
oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2
kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i
1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B
BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK
N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg
PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE
FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F
UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye
vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u
+6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq
qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP
tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy
Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ
CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4
RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7
8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T
BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ
SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK
7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM
nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB
AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/
Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN
hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi
w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf
VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP
OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK
/1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1
c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC
F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4
k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ
wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu
5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB
TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io
N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6
AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr
0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x
Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF
LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm
we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I
v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv
Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD
534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH
b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT
yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc
suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B
jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W
KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge
gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422
bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN
aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay
7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF
RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn
g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib
4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX
kt+z4drzFUyEjLM1vVvIMjkUoJs=3D
=3DeeAB
-----END PGP PUBLIC KEY BLOCK-----

--------------wyKdG8iQy4ECEdCvHtAQxKoC--

--------------mtSumtQHxB8sPFdKxaERrt5R--

--------------C0N0Hf0SzeGME0kMHWBSWKdF
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmX0dYkFAwAAAAAACgkQsN6d1ii/Ey8x
mQf/dMcgaNUxn5jM4QF3OQWHB9jh1bdahRXewW3XFnSzCSI5B2wkQRXxST6rzg9JaTpiALe5tEoV
HDK3keUpXjo7gzyDC4SrUJhsYBBnDXQl+WG+4YLksZuliuyWHWLm2sNmTptc+v++K3hzwJTkk1Ry
jVHyWZSW9gEr9tsVL0HBriyBK77tj5sFLMD0q/XD/ybMcGsnoUI2mNiPhom5CxHG2po5BdVcZ+0n
t9jgz/RuVYsYereSXon4kvEszA/+N3Jy1BKSg7z9da7N2nzJFZrrEn8FziuxyPvAf5/i2am2u4Bp
vN6Fc0pEtirbEeM/n84CqMx4tr2Ai3qSfVOwn+PthQ==
=S+Cy
-----END PGP SIGNATURE-----

--------------C0N0Hf0SzeGME0kMHWBSWKdF--


From xen-devel-bounces@lists.xenproject.org Fri Mar 15 17:52:40 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 17:52:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693976.1082664 (Exim 4.92)
	(envelope-from )
	id 1rlBjL-000373-Mn; Fri, 15 Mar 2024 17:52:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693976.1082664; Fri, 15 Mar 2024 17:52:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rlBjL-00036w-JQ; Fri, 15 Mar 2024 17:52:31 +0000
Received: by outflank-mailman (input) for mailman id 693976;
 Fri, 15 Mar 2024 17:52:30 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rlBjK-0002sX-4J
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 17:52:30 +0000
Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com
 [2a00:1450:4864:20::32f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ca78f8af-e2f4-11ee-afdd-a90da7624cb6;
 Fri, 15 Mar 2024 18:52:29 +0100 (CET)
Received: by mail-wm1-x32f.google.com with SMTP id
 5b1f17b1804b1-413f76fcf41so14585645e9.3
 for ; Fri, 15 Mar 2024 10:52:29 -0700 (PDT)
Received: from EMEAENGAAD91498.citrite.net
 (default-46-102-197-201.interdsl.co.uk. [46.102.197.201])
 by smtp.gmail.com with ESMTPSA id
 s6-20020a5d69c6000000b0033e9f6997c7sm3631448wrw.66.2024.03.15.10.52.27
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 15 Mar 2024 10:52:27 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ca78f8af-e2f4-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1710525148; x=1711129948; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=A3xo7OpI3t17GvZtWVbf/bOFO4OxNlnVn4a3LYdu7XY=;
        b=lD31A+PCY8pEBsu1/GrO+uUYPeTT4tztVBGCoLJZjNtgvdPF31T4F9OvXX2iSWO678
         G/O/FEBjwp/IrRZWcAKiu3rXoJPg1UlEnEGVDwTiBVmcUssY9OWh4K0AxYLjq3OqnpnJ
         9GLbIfMo9Rxcy2lGfQgjsld6MGeyn9Ct0XL9U=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710525148; x=1711129948;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=A3xo7OpI3t17GvZtWVbf/bOFO4OxNlnVn4a3LYdu7XY=;
        b=gDoduhQTVM7bR9KVuuuG2qtlyrGOwmY/MZV/DOoeQmSxxo+rMo+LnIZY4OyzkFW4fY
         R+LufwxQyKwiRw81sE3v2SJv9xJhOFEpKHRgriZQDyPlwZjebin9w79PeaDZcC/bGNSM
         wNiWF11JeEb+Pg62BjOUAga1CKkWQIbQu2lLTJ5h6+ZuOEXqPOka1FvusTTHjnwsrUno
         Lt68q98qr0NFdX1z1oKz5EqOiWKk24iHUb3C9LQAKoX1t2OQojCe2Q572vkhmHxWp/SX
         ViZWV+R3peVwbdnqeLZfZapSc1FM5X/AQaAI4eVQKx0+/kEYihHvlSTISuxHKU0uwwXL
         SNFA==
X-Gm-Message-State: AOJu0YwWBzviF0Aca2Cgz1MNqp3DCU/ep9//KvKuE5icpyNAaBRF6gri
	Sil1d8fiWzkGoBPjeBdcetS+ObfrYjdqc7iyaFJw5dRcGwZ5tHO19COWhWe2c5Q3N+FbhrgnDId
	V
X-Google-Smtp-Source: AGHT+IFZr9DuyeXZebztwFFVMcKj7dEhu/jn+GFXCDO8LtgYFsieP3WM/Qj8hWEkm8nk9Euy5eeCzw==
X-Received: by 2002:adf:ff87:0:b0:33e:6833:8fa9 with SMTP id j7-20020adfff87000000b0033e68338fa9mr3985505wrr.44.1710525148557;
        Fri, 15 Mar 2024 10:52:28 -0700 (PDT)
From: Matthew Barnes 
To: Xen-devel 
Cc: Matthew Barnes ,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Wei Liu 
Subject: [XEN PATCH 1/2] x86: Enable BLD and handle #DB traps
Date: Fri, 15 Mar 2024 17:52:23 +0000
Message-Id: <5c0c2fd252f425a397981546496438ebac439db2.1710524011.git.matthew.barnes@cloud.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Enable Bus Lock Detect if available, and handle #DB traps to reduce
effects of DoS.

The value to restore MSR_DEBUGCTL to after VMExit will now depend on
whether BLD is enabled or not.

Restore MSR_DEBUGCTL after being cleared by storing a copy of the
register value in memory, instead of hard-coding it.

Signed-off-by: Matthew Barnes 
---
 xen/arch/x86/cpu/common.c            |  5 +++++
 xen/arch/x86/hvm/vmx/entry.S         |  2 +-
 xen/arch/x86/include/asm/debugreg.h  |  1 +
 xen/arch/x86/include/asm/msr-index.h |  1 +
 xen/arch/x86/include/asm/msr.h       |  2 ++
 xen/arch/x86/msr.c                   |  2 ++
 xen/arch/x86/traps.c                 | 10 ++++++++--
 7 files changed, 20 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
index 28d7f34c4dbe..f11ac06f8292 100644
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -623,6 +623,11 @@ void identify_cpu(struct cpuinfo_x86 *c)
 	}
 
 	setup_doitm();
+
+	if (cpu_has(c, X86_FEATURE_BLD)) {
+		host_msr_debugctl |= IA32_DEBUGCTLMSR_BLD;
+		wrmsrl(MSR_IA32_DEBUGCTLMSR, host_msr_debugctl);
+	}
 }
 
 /* leaf 0xb SMT level */
diff --git a/xen/arch/x86/hvm/vmx/entry.S b/xen/arch/x86/hvm/vmx/entry.S
index 1bead826caa3..a0148f78584d 100644
--- a/xen/arch/x86/hvm/vmx/entry.S
+++ b/xen/arch/x86/hvm/vmx/entry.S
@@ -46,8 +46,8 @@ ENTRY(vmx_asm_vmexit_handler)
         /* WARNING! `ret`, `call *`, `jmp *` not safe before this point. */
 
         /* Hardware clears MSR_DEBUGCTL on VMExit.  Reinstate it if debugging Xen. */
+        mov host_msr_debugctl(%rip), %eax
         .macro restore_lbr
-            mov $IA32_DEBUGCTLMSR_LBR, %eax
             mov $MSR_IA32_DEBUGCTLMSR, %ecx
             xor %edx, %edx
             wrmsr
diff --git a/xen/arch/x86/include/asm/debugreg.h b/xen/arch/x86/include/asm/debugreg.h
index 2bdaf5d9aa11..9c048ae215d6 100644
--- a/xen/arch/x86/include/asm/debugreg.h
+++ b/xen/arch/x86/include/asm/debugreg.h
@@ -19,6 +19,7 @@
 #define DR_TRAP1        (0x2)           /* db1 */
 #define DR_TRAP2        (0x4)           /* db2 */
 #define DR_TRAP3        (0x8)           /* db3 */
+#define DR_TRAP11       (0x800)         /* db11 */
 #define DR_STEP         (0x4000)        /* single-step */
 #define DR_SWITCH       (0x8000)        /* task switch */
 #define DR_NOT_RTM      (0x10000)       /* clear: #BP inside RTM region */
diff --git a/xen/arch/x86/include/asm/msr-index.h b/xen/arch/x86/include/asm/msr-index.h
index 92dd9fa4962c..2e397bd28c77 100644
--- a/xen/arch/x86/include/asm/msr-index.h
+++ b/xen/arch/x86/include/asm/msr-index.h
@@ -292,6 +292,7 @@
 #define MSR_IA32_DEBUGCTLMSR		0x000001d9
 #define IA32_DEBUGCTLMSR_LBR		(1<<0) /* Last Branch Record */
 #define IA32_DEBUGCTLMSR_BTF		(1<<1) /* Single Step on Branches */
+#define IA32_DEBUGCTLMSR_BLD		(1<<2) /* Bus Lock Detect */
 #define IA32_DEBUGCTLMSR_TR		(1<<6) /* Trace Message Enable */
 #define IA32_DEBUGCTLMSR_BTS		(1<<7) /* Branch Trace Store */
 #define IA32_DEBUGCTLMSR_BTINT		(1<<8) /* Branch Trace Interrupt */
diff --git a/xen/arch/x86/include/asm/msr.h b/xen/arch/x86/include/asm/msr.h
index 1d8ea9f26faa..9ff7dcc8ca8b 100644
--- a/xen/arch/x86/include/asm/msr.h
+++ b/xen/arch/x86/include/asm/msr.h
@@ -432,4 +432,6 @@ int init_vcpu_msr_policy(struct vcpu *v);
 int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t *val);
 int guest_wrmsr(struct vcpu *v, uint32_t msr, uint64_t val);
 
+extern uint32_t host_msr_debugctl;
+
 #endif /* __ASM_MSR_H */
diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c
index 9babd441f9d4..7d9d162cb8b4 100644
--- a/xen/arch/x86/msr.c
+++ b/xen/arch/x86/msr.c
@@ -24,6 +24,8 @@
 
 #include 
 
+uint32_t host_msr_debugctl;
+
 DEFINE_PER_CPU(uint32_t, tsc_aux);
 
 int init_vcpu_msr_policy(struct vcpu *v)
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index d554c9d41edd..7d8eee013d00 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1936,9 +1936,12 @@ void asmlinkage do_debug(struct cpu_user_regs *regs)
      */
     write_debugreg(6, X86_DR6_DEFAULT);
 
+    if ( !( dr6 & DR_TRAP11 ) )
+        return;
+
     /* #DB automatically disabled LBR.  Reinstate it if debugging Xen. */
     if ( cpu_has_xen_lbr )
-        wrmsrl(MSR_IA32_DEBUGCTLMSR, IA32_DEBUGCTLMSR_LBR);
+        wrmsrl(MSR_IA32_DEBUGCTLMSR, host_msr_debugctl);
 
     if ( !guest_mode(regs) )
     {
@@ -2130,7 +2133,10 @@ void percpu_traps_init(void)
     }
 
     if ( cpu_has_xen_lbr )
-        wrmsrl(MSR_IA32_DEBUGCTLMSR, IA32_DEBUGCTLMSR_LBR);
+    {
+        host_msr_debugctl |= IA32_DEBUGCTLMSR_LBR;
+        wrmsrl(MSR_IA32_DEBUGCTLMSR, host_msr_debugctl);
+    }
 }
 
 /* Exception entries */
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Mar 15 17:52:40 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 17:52:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693977.1082675 (Exim 4.92)
	(envelope-from )
	id 1rlBjN-0003Lb-3Z; Fri, 15 Mar 2024 17:52:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693977.1082675; Fri, 15 Mar 2024 17:52:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rlBjM-0003LS-Ur; Fri, 15 Mar 2024 17:52:32 +0000
Received: by outflank-mailman (input) for mailman id 693977;
 Fri, 15 Mar 2024 17:52:31 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rlBjL-0002sX-4Y
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 17:52:31 +0000
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com
 [2a00:1450:4864:20::42e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id cb15cd4d-e2f4-11ee-afdd-a90da7624cb6;
 Fri, 15 Mar 2024 18:52:30 +0100 (CET)
Received: by mail-wr1-x42e.google.com with SMTP id
 ffacd0b85a97d-33ed7ef0ae8so137624f8f.0
 for ; Fri, 15 Mar 2024 10:52:30 -0700 (PDT)
Received: from EMEAENGAAD91498.citrite.net
 (default-46-102-197-201.interdsl.co.uk. [46.102.197.201])
 by smtp.gmail.com with ESMTPSA id
 s6-20020a5d69c6000000b0033e9f6997c7sm3631448wrw.66.2024.03.15.10.52.28
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 15 Mar 2024 10:52:29 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: cb15cd4d-e2f4-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1710525149; x=1711129949; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=DhANpMH0RmM2IazXWYR9pQ3eiDcQ2h+dRBwSMMkIqgk=;
        b=LKj7pryhWyugbzCwRfcBBbY2VW+UULNr2ePhyMDZZMsTzBqbXzIgYB/6OnSPJqH3fD
         lVSPwJyCQ1BjXX2ok1HiTU012xtoFgJvPZgxkvLHB6bp0UDas6Nh4iY9T94p6HpqBjUu
         tnLyzIV9KdfvcaA75uVIrLm6JSPfDfdYrsr0U=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710525149; x=1711129949;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=DhANpMH0RmM2IazXWYR9pQ3eiDcQ2h+dRBwSMMkIqgk=;
        b=jYAz4bOMQ2aUwl5o1zOaEDXpRgR4o8kyHxIBBI4OXhb/eLWUBD01aJwUn+nq+uvbSs
         Zl/7mn26k3Iulnd+2RKilnpgfNfTn1LXSdEH5Eg7KVR4Wrf849EJ2bqqcM3t7/tqAfjE
         IZbaOLOM50FAn7Ls+LrO0l3wY+Yy4f/hZRNeplJYpV9uBiZ+BHHrIU4vNCXR8RwqTNyD
         CTTvIbkWXqH/q2kE5x+AYqQSlVbpVjM0YtKRI0LRJHUFTJAOjUBLGjk1Uon4bCyJaPzU
         vjFupNey1970RrDvoM4XY2xq9Ftgt9MUCmFHoMvvMpX+v9OxX8r1daa5elPpx+S1IkiF
         GMIQ==
X-Gm-Message-State: AOJu0Yy0AMM33jdJVVdZBR79U4fznhtR2JFBJkIvoj/i88RMk5KN3Aqn
	9MkDicltejoImwKebfP6a1WjUQxvUmFAejMKSTNsadQmol7YTBM2Fi87tjYFINMI1jyfMtXaF7T
	i
X-Google-Smtp-Source: AGHT+IHbuMsADpmNOECnVBNngfrOhAuNJq6QcV5ZjMangmbYD50/9fKavTSvct6iL02sv/soYyNy4Q==
X-Received: by 2002:a5d:58c4:0:b0:33e:d8f:3466 with SMTP id o4-20020a5d58c4000000b0033e0d8f3466mr3295974wrf.33.1710525149322;
        Fri, 15 Mar 2024 10:52:29 -0700 (PDT)
From: Matthew Barnes 
To: Xen-devel 
Cc: Matthew Barnes ,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Wei Liu 
Subject: [XEN PATCH 2/2] x86: Refactor LBR feature to MSR_DEBUGCTL feature
Date: Fri, 15 Mar 2024 17:52:24 +0000
Message-Id: <2f690a115fc78989bfc2e331221d7e10b5dcb196.1710524011.git.matthew.barnes@cloud.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Last Branch Record and Bus Lock Detect both belong to the same MSR.

The same mechanism that restores LBR also restores BLD.

Therefore, the name of the feature that enables this mechanism should
reflect restoring the MSR, instead of one field.

No functional change.

Signed-off-by: Matthew Barnes 
---
 xen/arch/x86/hvm/vmx/entry.S           | 4 ++--
 xen/arch/x86/include/asm/cpufeature.h  | 2 +-
 xen/arch/x86/include/asm/cpufeatures.h | 2 +-
 xen/arch/x86/traps.c                   | 6 +++---
 4 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/entry.S b/xen/arch/x86/hvm/vmx/entry.S
index a0148f78584d..acfdc370289d 100644
--- a/xen/arch/x86/hvm/vmx/entry.S
+++ b/xen/arch/x86/hvm/vmx/entry.S
@@ -47,12 +47,12 @@ ENTRY(vmx_asm_vmexit_handler)
 
         /* Hardware clears MSR_DEBUGCTL on VMExit.  Reinstate it if debugging Xen. */
         mov host_msr_debugctl(%rip), %eax
-        .macro restore_lbr
+        .macro restore_msr_debugctl
             mov $MSR_IA32_DEBUGCTLMSR, %ecx
             xor %edx, %edx
             wrmsr
         .endm
-        ALTERNATIVE "", restore_lbr, X86_FEATURE_XEN_LBR
+        ALTERNATIVE "", restore_msr_debugctl, X86_FEATURE_XEN_MSR_DEBUGCTL
 
         mov  %rsp,%rdi
         call vmx_vmexit_handler
diff --git a/xen/arch/x86/include/asm/cpufeature.h b/xen/arch/x86/include/asm/cpufeature.h
index 9bc553681f4a..084501c76a03 100644
--- a/xen/arch/x86/include/asm/cpufeature.h
+++ b/xen/arch/x86/include/asm/cpufeature.h
@@ -223,7 +223,7 @@ static inline bool boot_cpu_has(unsigned int feat)
 #define cpu_has_aperfmperf      boot_cpu_has(X86_FEATURE_APERFMPERF)
 #define cpu_has_lfence_dispatch boot_cpu_has(X86_FEATURE_LFENCE_DISPATCH)
 #define cpu_has_nscb            boot_cpu_has(X86_FEATURE_NSCB)
-#define cpu_has_xen_lbr         boot_cpu_has(X86_FEATURE_XEN_LBR)
+#define cpu_has_xen_msr_debugctl boot_cpu_has(X86_FEATURE_XEN_MSR_DEBUGCTL)
 #define cpu_has_xen_shstk       (IS_ENABLED(CONFIG_XEN_SHSTK) && \
                                  boot_cpu_has(X86_FEATURE_XEN_SHSTK))
 #define cpu_has_xen_ibt         (IS_ENABLED(CONFIG_XEN_IBT) && \
diff --git a/xen/arch/x86/include/asm/cpufeatures.h b/xen/arch/x86/include/asm/cpufeatures.h
index 7e8221fd85dd..060d7c1d5c9e 100644
--- a/xen/arch/x86/include/asm/cpufeatures.h
+++ b/xen/arch/x86/include/asm/cpufeatures.h
@@ -34,7 +34,7 @@ XEN_CPUFEATURE(SC_RSB_PV,         X86_SYNTH(18)) /* RSB overwrite needed for PV
 XEN_CPUFEATURE(SC_RSB_HVM,        X86_SYNTH(19)) /* RSB overwrite needed for HVM */
 XEN_CPUFEATURE(XEN_SELFSNOOP,     X86_SYNTH(20)) /* SELFSNOOP gets used by Xen itself */
 XEN_CPUFEATURE(SC_MSR_IDLE,       X86_SYNTH(21)) /* Clear MSR_SPEC_CTRL on idle */
-XEN_CPUFEATURE(XEN_LBR,           X86_SYNTH(22)) /* Xen uses MSR_DEBUGCTL.LBR */
+XEN_CPUFEATURE(XEN_MSR_DEBUGCTL,  X86_SYNTH(22)) /* Xen uses MSR_DEBUGCTL */
 XEN_CPUFEATURE(SC_DIV,            X86_SYNTH(23)) /* DIV scrub needed */
 XEN_CPUFEATURE(SC_RSB_IDLE,       X86_SYNTH(24)) /* RSB overwrite needed for idle. */
 XEN_CPUFEATURE(SC_VERW_IDLE,      X86_SYNTH(25)) /* VERW used by Xen for idle */
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 7d8eee013d00..16bef5d76620 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1940,7 +1940,7 @@ void asmlinkage do_debug(struct cpu_user_regs *regs)
         return;
 
     /* #DB automatically disabled LBR.  Reinstate it if debugging Xen. */
-    if ( cpu_has_xen_lbr )
+    if ( cpu_has_xen_msr_debugctl )
         wrmsrl(MSR_IA32_DEBUGCTLMSR, host_msr_debugctl);
 
     if ( !guest_mode(regs) )
@@ -2129,10 +2129,10 @@ void percpu_traps_init(void)
             return;
         }
 
-        setup_force_cpu_cap(X86_FEATURE_XEN_LBR);
+        setup_force_cpu_cap(X86_FEATURE_XEN_MSR_DEBUGCTL);
     }
 
-    if ( cpu_has_xen_lbr )
+    if ( cpu_has_xen_msr_debugctl )
     {
         host_msr_debugctl |= IA32_DEBUGCTLMSR_LBR;
         wrmsrl(MSR_IA32_DEBUGCTLMSR, host_msr_debugctl);
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Mar 15 17:52:40 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 17:52:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693975.1082654 (Exim 4.92)
	(envelope-from )
	id 1rlBjK-0002sp-Gf; Fri, 15 Mar 2024 17:52:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693975.1082654; Fri, 15 Mar 2024 17:52:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rlBjK-0002si-Cp; Fri, 15 Mar 2024 17:52:30 +0000
Received: by outflank-mailman (input) for mailman id 693975;
 Fri, 15 Mar 2024 17:52:29 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rlBjJ-0002sX-H5
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 17:52:29 +0000
Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com
 [2a00:1450:4864:20::334])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ca03e395-e2f4-11ee-afdd-a90da7624cb6;
 Fri, 15 Mar 2024 18:52:28 +0100 (CET)
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-413feaf0625so8445865e9.0
 for ; Fri, 15 Mar 2024 10:52:28 -0700 (PDT)
Received: from EMEAENGAAD91498.citrite.net
 (default-46-102-197-201.interdsl.co.uk. [46.102.197.201])
 by smtp.gmail.com with ESMTPSA id
 s6-20020a5d69c6000000b0033e9f6997c7sm3631448wrw.66.2024.03.15.10.52.26
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 15 Mar 2024 10:52:27 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ca03e395-e2f4-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1710525147; x=1711129947; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:from:to:cc:subject:date:message-id:reply-to;
        bh=R4EgK/nbAcJVQaX7mMXVqp7DYcV82QrYjBG/VZPrZqc=;
        b=AZOxzMd8JQSACyKPxp1dKqJ1tNF7IdV/AeKnGdA3X0dkCE/mI4Wwch8mMuXAurkhPd
         G1hdh37P7IbqxLUcX1p0PZSuiIaSE7/lI1ZNbl75uRx65x3o/w+NNCk2XI0l0UCJSWoT
         SoLasmCec487ywFhKFhcNVyuQ6bpweYLSMqa8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710525147; x=1711129947;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=R4EgK/nbAcJVQaX7mMXVqp7DYcV82QrYjBG/VZPrZqc=;
        b=EtzttwI2GVsHS8Zl3AamWaKH72tCRMVZmCFPRb2r6YTHWMbmZJOpBJltrX94fBpsvF
         luVOXdHNfSnG4Sk9JOC2k4O11Sswl1t0KymH6OidlRgcrqCWZ8uMLGKguqxLPTA1ec4d
         v8cqZcIcwGGDYdvWg37GgAg1Gww4pPId1icDMJfEDTCNDNmvQGZvdClGYfobHoP4iXpt
         V2hygyHaiAsw/qLXfW36ogtaNaB3jdExoGKTboWP9l1hZoKCFfYveIK6O2UZW7k5YlJT
         y1+vreCYp/slMo1Ou54N7+3iv/dsNfJ4V2FkMvdJSCjhl3LktSP4jnG2zw87M3lYQYvv
         v8xg==
X-Gm-Message-State: AOJu0YwWFrrbhXt6Rq1mTi8+B2jrOj5CGdaMHZlfh9YWilDiJ5744oAh
	3n6dDpY1gs0p4ee/H5VlDAbVsYu6ymARIqLZaHwcAnSCLwNxwBNdzUweDJdCSmCCqKKyp2gSdkL
	jMJ4=
X-Google-Smtp-Source: AGHT+IFjB2r6zpqvqMDCGFxLfaADnfywP2I8IzQTV4qnUzaQgVGIH7OrKKL8mGWjs5+pbybakBX17g==
X-Received: by 2002:adf:f192:0:b0:33e:7333:d459 with SMTP id h18-20020adff192000000b0033e7333d459mr2530612wro.49.1710525147351;
        Fri, 15 Mar 2024 10:52:27 -0700 (PDT)
From: Matthew Barnes 
To: Xen-devel 
Cc: Matthew Barnes ,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Wei Liu 
Subject: [XEN PATCH 0/2] Enable Bus Lock Detect as rate limiter
Date: Fri, 15 Mar 2024 17:52:22 +0000
Message-Id: 
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Bus Lock Detect can be used to reduce the effects of DoS in case it
happens.

This patch series enables BLD from MSR_DEBUGCTL if available, and
refines a mechanism to restore MSR_DEBUGCTL upon VMExit to support BLD
as well as LBR.

Said mechanism is also refactored to have a name that reflects generally
restoring the MSR, instead of only one field.

Matthew Barnes (2):
  x86: Enable BLD and handle #DB traps
  x86: Refactor LBR feature into general MSR_DEBUGCTL feature

 xen/arch/x86/cpu/common.c              |  5 +++++
 xen/arch/x86/hvm/vmx/entry.S           |  6 +++---
 xen/arch/x86/include/asm/cpufeature.h  |  2 +-
 xen/arch/x86/include/asm/cpufeatures.h |  2 +-
 xen/arch/x86/include/asm/debugreg.h    |  1 +
 xen/arch/x86/include/asm/msr-index.h   |  1 +
 xen/arch/x86/include/asm/msr.h         |  2 ++
 xen/arch/x86/msr.c                     |  2 ++
 xen/arch/x86/traps.c                   | 16 +++++++++++-----
 9 files changed, 27 insertions(+), 10 deletions(-)

-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Mar 15 18:06:28 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 18:06:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693989.1082703 (Exim 4.92)
	(envelope-from )
	id 1rlBwo-0006DP-7N; Fri, 15 Mar 2024 18:06:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693989.1082703; Fri, 15 Mar 2024 18:06:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rlBwn-0006Bm-Rf; Fri, 15 Mar 2024 18:06:25 +0000
Received: by outflank-mailman (input) for mailman id 693989;
 Fri, 15 Mar 2024 18:06:24 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rlBwm-0005yW-QW
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 18:06:24 +0000
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com
 [2a00:1450:4864:20::22c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id bbfdf0a6-e2f6-11ee-afdd-a90da7624cb6;
 Fri, 15 Mar 2024 19:06:24 +0100 (CET)
Received: by mail-lj1-x22c.google.com with SMTP id
 38308e7fff4ca-2d46d729d89so32931091fa.3
 for ; Fri, 15 Mar 2024 11:06:24 -0700 (PDT)
Received: from fedora.. ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id
 g29-20020a05651c079d00b002d0acb57c89sm568939lje.64.2024.03.15.11.06.21
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 15 Mar 2024 11:06:22 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: bbfdf0a6-e2f6-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1710525982; x=1711130782; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=q3qDdX1fVf6ELC4xrUOmJazs4+QxaTvpRVXWbmDV/+I=;
        b=c244gl9HMfi2AY0bRn4d9pTaDtknWsPEtcrkhQO7Kxu4V1P+rXA2Zo6TZBzhJ3SG68
         4NW8LNFwV/GedA4gAoRHVeI3aDWoGFtw14lmUvMnCTiYQNa+TmMvj9dthMPCOtUMZV4S
         UHZ0BdWnDlyxkUNr4xuNQdUgHRw5PPolB58ohR226T6r5XKNGQB9i4MX00dzlbn+qkkf
         x6Ymk52t6l+ps3IEKUZ2jp0TZXlF1EIQET0fPzPViL0ZSLkb4UqQYIiwJ3gyhu3KcMoC
         w2PjbJfgiONwQLejK9iUqlr2dhWSirRHJDrhljrEqPs7NBCLPPlTZkld1rQJiAYidZOy
         nwvA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710525982; x=1711130782;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=q3qDdX1fVf6ELC4xrUOmJazs4+QxaTvpRVXWbmDV/+I=;
        b=I1B5jhDOCDIYJQKvOrqM0grPJJm+qGaQCEB1yTiZFL/pXbjreHJumNmL1CK3CuwYGv
         Bc6d9HqKoHb2nZdBKPM3VMDpSp1FGLuFhzt9Ykwzk+FblInoP/ggkVDfxZ5Pc1HUe6JZ
         H8CJKSYdndqyKCu9go7xjUNhRDEwOs+mP8HeumqWckxGtYzjY8V1bYEKlxy6/5FJqjjD
         NDCVSQ9O9M9VCS2LlTLwX72H0VjC/tvkVbT+PzHGKP9H4nqFVgplD1l6vIq93dkDVH2Y
         CmLE2ujjtrIBunBAmVDTBQQkbUfdQ7IvOZjraqx44RMMEdsJZHkRxV7IDyeVAbTsH4yG
         RNNA==
X-Gm-Message-State: AOJu0YwB3ctPuurQy88X9kWi4leseTDNgRZRlf+N7cPODKjkXo3JU7pW
	5V6qoszLMyiRNGXWJERq02c1TzsPxKrUEqX8io6NCqAOSUfYRJM+oSgtxBkxMIQ=
X-Google-Smtp-Source: AGHT+IHeNIXc4RZKYxoGE93x76137GYbYkx6boDJJaNuddaxGW6N1RgI0MJTtn6sDj0oCFFiEOV5OQ==
X-Received: by 2002:a2e:be8f:0:b0:2d3:ba98:473 with SMTP id a15-20020a2ebe8f000000b002d3ba980473mr3172986ljr.19.1710525982507;
        Fri, 15 Mar 2024 11:06:22 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini ,
	Wei Liu ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis 
Subject: [PATCH v6 03/20] xen/riscv: introduce extenstion support check by compiler
Date: Fri, 15 Mar 2024 19:05:59 +0100
Message-ID: 
X-Mailer: git-send-email 2.43.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Currently, RISC-V requires two extensions: _zbb and _zihintpause.

This patch introduces a compiler check to check if these extensions
are supported.
Additionally, it introduces the riscv/booting.txt file, which contains
information about the extensions that should be supported by the platform.

In the future, a feature will be introduced to check whether an extension
is supported at runtime.
However, this feature requires functionality for parsing device tree
source (DTS), which is not yet available.

Signed-off-by: Oleksii Kurochko 
---
Changes in V6:
 - new patch for this patch series
---
 docs/misc/riscv/booting.txt | 16 ++++++++++++++++
 xen/arch/riscv/arch.mk      | 10 ++++++++--
 2 files changed, 24 insertions(+), 2 deletions(-)
 create mode 100644 docs/misc/riscv/booting.txt

diff --git a/docs/misc/riscv/booting.txt b/docs/misc/riscv/booting.txt
new file mode 100644
index 0000000000..cb4d79f12c
--- /dev/null
+++ b/docs/misc/riscv/booting.txt
@@ -0,0 +1,16 @@
+System requirements
+===================
+
+The following extensions are expected to be supported by a system on which
+Xen is run:
+- Zbb:
+  RISC-V doesn't have a CLZ instruction in the base ISA.
+  As a consequence, __builtin_ffs() emits a library call to ffs() on GCC,
+  or a de Bruijn sequence on Clang.
+  Zbb extension adds a CLZ instruction, after which __builtin_ffs() emits
+  a very simple sequence.
+  The similar issue occurs with other __builtin_, so it is needed to
+  provide a generic version of bitops in RISC-V bitops.h
+- Zihintpause:
+  On a system that doesn't have this extension, cpu_relax() should be
+  implemented properly.
diff --git a/xen/arch/riscv/arch.mk b/xen/arch/riscv/arch.mk
index 8403f96b6f..da6f8c82eb 100644
--- a/xen/arch/riscv/arch.mk
+++ b/xen/arch/riscv/arch.mk
@@ -3,16 +3,22 @@
 
 $(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS))
 
-CFLAGS-$(CONFIG_RISCV_64) += -mabi=lp64
+riscv-abi-$(CONFIG_RISCV_32) := -mabi=ilp32
+riscv-abi-$(CONFIG_RISCV_64) := -mabi=lp64
 
 riscv-march-$(CONFIG_RISCV_ISA_RV64G) := rv64g
 riscv-march-$(CONFIG_RISCV_ISA_C)       := $(riscv-march-y)c
 
+extensions := $(call as-insn,$(CC) $(riscv-abi-y) -march=$(riscv-march-y)_zbb,"",_zbb) \
+              $(call as-insn,$(CC) $(riscv-abi-y) -march=$(riscv-march-y)_zihintpause,"pause",_zihintpause)
+
+extensions := $(subst $(space),,$(extensions))
+
 # Note that -mcmodel=medany is used so that Xen can be mapped
 # into the upper half _or_ the lower half of the address space.
 # -mcmodel=medlow would force Xen into the lower half.
 
-CFLAGS += -march=$(riscv-march-y) -mstrict-align -mcmodel=medany
+CFLAGS += $(riscv-abi-y) -march=$(riscv-march-y)$(extensions) -mstrict-align -mcmodel=medany
 
 # TODO: Drop override when more of the build is working
 override ALL_OBJS-y = arch/$(SRCARCH)/built_in.o
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Mar 15 18:06:28 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 18:06:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693990.1082724 (Exim 4.92)
	(envelope-from )
	id 1rlBwp-0006rD-Fr; Fri, 15 Mar 2024 18:06:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693990.1082724; Fri, 15 Mar 2024 18:06:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rlBwp-0006q7-9Q; Fri, 15 Mar 2024 18:06:27 +0000
Received: by outflank-mailman (input) for mailman id 693990;
 Fri, 15 Mar 2024 18:06:26 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rlBwn-0005yW-Rl
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 18:06:25 +0000
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com
 [2a00:1450:4864:20::229])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id bcc33c8d-e2f6-11ee-afdd-a90da7624cb6;
 Fri, 15 Mar 2024 19:06:25 +0100 (CET)
Received: by mail-lj1-x229.google.com with SMTP id
 38308e7fff4ca-2d29aad15a5so28946081fa.3
 for ; Fri, 15 Mar 2024 11:06:25 -0700 (PDT)
Received: from fedora.. ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id
 g29-20020a05651c079d00b002d0acb57c89sm568939lje.64.2024.03.15.11.06.22
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 15 Mar 2024 11:06:22 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: bcc33c8d-e2f6-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1710525984; x=1711130784; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=kG3msNYRo0R9LmvVapMrH1VBiKyep4RKTNNpLZUcFSg=;
        b=HQMq3zyIHg6lQtWnD0cYIQ08wLZRqY3TUUoYiElXgLkso8ilRWhio7bIUUrNZug2hE
         xMhGiTJHHvVZB+RQEwTMxuMA0qF9scZZKVMdErql+FWHj0vC0X7p1zpfFndRLRDnf+xV
         WqnvR6A5A/JT7YkrNM0fXAkjoidthKVD86m3d6kmKCIP3laTJarNiVR7nn6lsFZZDoLX
         A4kIcNtPd67zZGczyP6j1TNKI/yozZlpZno05djpCZKwISxvxKi+0Kgd2MT9D69b3nzR
         Ru1E6IEegTgG412WVw0B93TcYWMgXHXaVUPbCB29t8FqToCVFbfjQfiVlCE/444BYLLL
         dMNg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710525984; x=1711130784;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=kG3msNYRo0R9LmvVapMrH1VBiKyep4RKTNNpLZUcFSg=;
        b=se2Yw2CV/FTAlioj41ON9jAqmaUT/bGpvkekO4YsXAiwhmq8wjOxIK9l9jqYgg4mFd
         HfoFfU9thpaHc0qWdih99iPOTmQ6GBV3to52fZSqvefdXr1Pxn706UmgmmG/7Y6dXbXz
         xhYSycd0s2s5OhjopqF12qQW5h6k/vmUbgch3mk5Shfc+1kznbQA2ZUUCQ5v9uuPJCvm
         4pudoP2w57PwIxhHWn6oW+v7YoIHbHYsfnDkh81lURUq7U1ODyAur3KogZ3G4lXrrMKy
         lShEJGnQm7c7yPq+TQ+ABwK9Wa2Zps+k76FS0v4e1UXvXvi4Toz1a5ZmfLo+tnDGiL0A
         rPwQ==
X-Gm-Message-State: AOJu0YwWTWMWgKCUl4C5UL5GIHrOS0DKujpIUuy0EFq/+opIeOQUeL14
	8wpq/rGyVLuicEPkCK/qYVs97vFdsBKQZrq3iEC684OgGvfzdsMNAT/kcfiMxws=
X-Google-Smtp-Source: AGHT+IER1qGM0C2g3OstU5cOLa+nT5EL75+B1RORH7m39YFrVWH7RrPkHs/GjfPERvRLRxUa7iHGhQ==
X-Received: by 2002:a2e:9b07:0:b0:2d3:8b2:6885 with SMTP id u7-20020a2e9b07000000b002d308b26885mr2522340lji.49.1710525984085;
        Fri, 15 Mar 2024 11:06:24 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini ,
	Wei Liu 
Subject: [PATCH v6 04/20] xen/asm-generic: introduce generic non-atomic test_*bit()
Date: Fri, 15 Mar 2024 19:06:00 +0100
Message-ID: <48b7dfafccc7a0ed814b5dfb0f109a0473a1b4b4.1710517542.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

The patch introduces the following generic functions:
* test_bit
* generic___test_and_set_bit
* generic___test_and_clear_bit
* generic___test_and_change_bit

Also, the patch introduces the following generics which are
used by the functions mentioned above:
* BITOP_BITS_PER_WORD
* BITOP_MASK
* BITOP_WORD
* BITOP_TYPE

These functions and macros can be useful for architectures
that don't have corresponding arch-specific instructions.

Signed-off-by: Oleksii Kurochko 
---
 Changes in V6:
  - Nothing changed ( only rebase )
---
 Changes in V5:
   - new patch
---
 xen/include/asm-generic/bitops/bitops-bits.h  | 21 +++++
 .../asm-generic/bitops/generic-non-atomic.h   | 89 +++++++++++++++++++
 xen/include/asm-generic/bitops/test-bit.h     | 18 ++++
 3 files changed, 128 insertions(+)
 create mode 100644 xen/include/asm-generic/bitops/bitops-bits.h
 create mode 100644 xen/include/asm-generic/bitops/generic-non-atomic.h
 create mode 100644 xen/include/asm-generic/bitops/test-bit.h

diff --git a/xen/include/asm-generic/bitops/bitops-bits.h b/xen/include/asm-generic/bitops/bitops-bits.h
new file mode 100644
index 0000000000..4ece2affd6
--- /dev/null
+++ b/xen/include/asm-generic/bitops/bitops-bits.h
@@ -0,0 +1,21 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_GENERIC_BITOPS_BITS_H_
+#define _ASM_GENERIC_BITOPS_BITS_H_
+
+#ifndef BITOP_BITS_PER_WORD
+#define BITOP_BITS_PER_WORD     32
+#endif
+
+#ifndef BITOP_MASK
+#define BITOP_MASK(nr)          (1U << ((nr) % BITOP_BITS_PER_WORD))
+#endif
+
+#ifndef BITOP_WORD
+#define BITOP_WORD(nr)          ((nr) / BITOP_BITS_PER_WORD)
+#endif
+
+#ifndef BITOP_TYPE
+typedef uint32_t bitops_uint_t;
+#endif
+
+#endif /* _ASM_GENERIC_BITOPS_BITS_H_ */
diff --git a/xen/include/asm-generic/bitops/generic-non-atomic.h b/xen/include/asm-generic/bitops/generic-non-atomic.h
new file mode 100644
index 0000000000..02d5721bfe
--- /dev/null
+++ b/xen/include/asm-generic/bitops/generic-non-atomic.h
@@ -0,0 +1,89 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * The file is based on Linux ( 6.4.0 ) header:
+ *   include/asm-generic/bitops/generic-non-atomic.h
+ * 
+ * Only functions that can be reused in Xen were left; others were removed.
+ * 
+ * Also, the following changes were done:
+ *  - it was updated the message inside #ifndef ... #endif.
+ *  - __always_inline -> always_inline to be align with definition in
+ *    xen/compiler.h.
+ *  - update function prototypes from
+ *    generic___test_and_*(unsigned long nr nr, volatile unsigned long *addr) to
+ *    generic___test_and_*(unsigned long nr, volatile void *addr) to be
+ *    consistent with other related macros/defines.
+ *  - convert identations from tabs to spaces.
+ *  - inside generic__test_and_* use 'bitops_uint_t' instead of 'unsigned long'
+ *    to be generic.
+ */
+
+#ifndef __ASM_GENERIC_BITOPS_GENERIC_NON_ATOMIC_H
+#define __ASM_GENERIC_BITOPS_GENERIC_NON_ATOMIC_H
+
+#include 
+
+#include 
+
+#ifndef XEN_BITOPS_H
+#error only  can be included directly
+#endif
+
+/*
+ * Generic definitions for bit operations, should not be used in regular code
+ * directly.
+ */
+
+/**
+ * generic___test_and_set_bit - Set a bit and return its old value
+ * @nr: Bit to set
+ * @addr: Address to count from
+ *
+ * This operation is non-atomic and can be reordered.
+ * If two examples of this operation race, one can appear to succeed
+ * but actually fail.  You must protect multiple accesses with a lock.
+ */
+static always_inline bool
+generic___test_and_set_bit(unsigned long nr, volatile void *addr)
+{
+    bitops_uint_t mask = BITOP_MASK(nr);
+    bitops_uint_t *p = ((bitops_uint_t *)addr) + BITOP_WORD(nr);
+    bitops_uint_t old = *p;
+
+    *p = old | mask;
+    return (old & mask) != 0;
+}
+
+/**
+ * generic___test_and_clear_bit - Clear a bit and return its old value
+ * @nr: Bit to clear
+ * @addr: Address to count from
+ *
+ * This operation is non-atomic and can be reordered.
+ * If two examples of this operation race, one can appear to succeed
+ * but actually fail.  You must protect multiple accesses with a lock.
+ */
+static always_inline bool
+generic___test_and_clear_bit(bitops_uint_t nr, volatile void *addr)
+{
+    bitops_uint_t mask = BITOP_MASK(nr);
+    bitops_uint_t *p = ((bitops_uint_t *)addr) + BITOP_WORD(nr);
+    bitops_uint_t old = *p;
+
+    *p = old & ~mask;
+    return (old & mask) != 0;
+}
+
+/* WARNING: non atomic and it can be reordered! */
+static always_inline bool
+generic___test_and_change_bit(unsigned long nr, volatile void *addr)
+{
+    bitops_uint_t mask = BITOP_MASK(nr);
+    bitops_uint_t *p = ((bitops_uint_t *)addr) + BITOP_WORD(nr);
+    bitops_uint_t old = *p;
+
+    *p = old ^ mask;
+    return (old & mask) != 0;
+}
+
+#endif /* __ASM_GENERIC_BITOPS_GENERIC_NON_ATOMIC_H */
diff --git a/xen/include/asm-generic/bitops/test-bit.h b/xen/include/asm-generic/bitops/test-bit.h
new file mode 100644
index 0000000000..6fb414d808
--- /dev/null
+++ b/xen/include/asm-generic/bitops/test-bit.h
@@ -0,0 +1,18 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_GENERIC_BITOPS_TESTBIT_H_
+#define _ASM_GENERIC_BITOPS_TESTBIT_H_
+
+#include 
+
+/**
+ * test_bit - Determine whether a bit is set
+ * @nr: bit number to test
+ * @addr: Address to start counting from
+ */
+static inline int test_bit(int nr, const volatile void *addr)
+{
+    const volatile bitops_uint_t *p = addr;
+    return 1 & (p[BITOP_WORD(nr)] >> (nr & (BITOP_BITS_PER_WORD - 1)));
+}
+
+#endif /* _ASM_GENERIC_BITOPS_TESTBIT_H_ */
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Mar 15 18:06:28 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 18:06:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693986.1082684 (Exim 4.92)
	(envelope-from )
	id 1rlBwn-0005z1-7C; Fri, 15 Mar 2024 18:06:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693986.1082684; Fri, 15 Mar 2024 18:06:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rlBwn-0005yu-4I; Fri, 15 Mar 2024 18:06:25 +0000
Received: by outflank-mailman (input) for mailman id 693986;
 Fri, 15 Mar 2024 18:06:24 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rlBwm-0005yV-2k
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 18:06:24 +0000
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com
 [2a00:1450:4864:20::232])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ba9e6de7-e2f6-11ee-a1ee-f123f15fe8a2;
 Fri, 15 Mar 2024 19:06:21 +0100 (CET)
Received: by mail-lj1-x232.google.com with SMTP id
 38308e7fff4ca-2d2505352e6so27142321fa.3
 for ; Fri, 15 Mar 2024 11:06:21 -0700 (PDT)
Received: from fedora.. ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id
 g29-20020a05651c079d00b002d0acb57c89sm568939lje.64.2024.03.15.11.06.18
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 15 Mar 2024 11:06:19 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ba9e6de7-e2f6-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1710525980; x=1711130780; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:from:to:cc:subject:date:message-id:reply-to;
        bh=GkZggCrWPbf3X2AL5ciXfMI66Mlu4MhD31Gm8gx0G1k=;
        b=hl9O6P8kt0tKbnSGVGWicvvAVvA4jFkeyL0GN0SwyZKOrhK4dZPBczriFX2Bts4lEJ
         Im0fs+Kt6YrA48gRBEQigT1QjJtNx6w2aJxFOCyv0NuKs9h8LFbjvgnM0WoaNrYYQV/b
         nNAoWcVBAZPgD/N5F8y4H1bng5PILJeXkGe65Aq7MEc5yc3gW0abE3ruJIlJrf079MKH
         tjF/QfckBXntNUT/KHsY/VL3jNoXgBfqPw0IMU5GjYPdQTtix5sVu8RjdTXFqwQaDR7K
         UbfPLhFHNgJdifSVeRerfx8QVcyl9AOsoT+LY7272ToJoIbD+D2LL7LxV4UzEyrcedAB
         RMaA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710525980; x=1711130780;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=GkZggCrWPbf3X2AL5ciXfMI66Mlu4MhD31Gm8gx0G1k=;
        b=dlB4AjQdk09BvG7RChZ1M9UigowAAfg7FgjGHofQv9OtuLJDka5cZ2Wy8/Mm409RO9
         xw7EWemuCw9NBR5IhIAarQrOWaTo5748NyhQzAt0Z4kjUOvPG8qN3G7cb4h552+tqJKA
         0SqWK+3UExgDpJtS/RLyPEM5p7koEvAnh2enCem9UxReuL0717v9HTQnT/3axxY000oE
         L5uzHLS0Sn2ohwdK1umx41GnRLZVtxhOnLvSqfVidfvqS7i/iNChSI0Ang91kJLLYfq+
         XJH1krfQTE1u5/4aaBv7KQR5Otd9L8qVSuFtcWOZBqlNWMtSxvhS8END0bZ4vc+T9dw1
         ixPg==
X-Gm-Message-State: AOJu0Yx5BuxeJEjoEKiiH2AHj3JC6jhuyw8NlR6UkaOldSwI9w1kfsIL
	uxwIiDiJ8jqyszA+PGUrkyoQhABvdV/GR6En4U0VrTQdtVL3TrSxPjlrSymN7DA=
X-Google-Smtp-Source: AGHT+IH+rHID2h5TgUUuyNzF//n6i3Pu3XMrcrb0J/9YNKd6G8QVlgc5AeIZItqShMmUFYSQjTd48g==
X-Received: by 2002:a05:651c:a0d:b0:2d2:7a4e:f5ec with SMTP id k13-20020a05651c0a0d00b002d27a4ef5ecmr4441010ljq.7.1710525979921;
        Fri, 15 Mar 2024 11:06:19 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Doug Goldstein ,
	Stefano Stabellini ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Wei Liu ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Shawn Anastasio ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Rahul Singh ,
	Tamas K Lengyel ,
	Alexandru Isaila ,
	Petre Pircalabu 
Subject: [PATCH v6 00/20] Enable build of full Xen for RISC-V
Date: Fri, 15 Mar 2024 19:05:56 +0100
Message-ID: 
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This patch series performs all of the additions necessary to drop the
build overrides for RISCV and enable the full Xen build. Except in cases
where compatibile implementations already exist (e.g. atomic.h and
bitops.h), the newly added definitions are simple.

The patch series is based on the following patch series:
- [PATCH 0/7] xen/bitops: Reduce the mess, starting with ffs() [1]
- [PATCH] move __read_mostly to xen/cache.h  [2]
- [XEN PATCH v2 1/3] xen: introduce STATIC_ASSERT_UNREACHABLE() [3]


Right now, the patch series doesn't have a direct dependency on [2] and it
provides __read_mostly in the patch:
    [PATCH v3 26/34] xen/riscv: add definition of __read_mostly
However, it will be dropped as soon as [2] is merged or at least when the
final version of the patch [2] is provided.

[1] https://lore.kernel.org/xen-devel/20240313172716.2325427-1-andrew.cooper3@citrix.com/T/#t
[2] https://lore.kernel.org/xen-devel/f25eb5c9-7c14-6e23-8535-2c66772b333e@suse.com/
[3] https://lore.kernel.org/xen-devel/42fc6ae8d3eb802429d29c774502ff232340dc84.1706259490.git.federico.serafini@bugseng.com/

---
Changes in V6:
 - Update the cover letter message: drop already merged dependecies and add
   a new one.
 - Patches were merged to staging:
   - [PATCH v5 02/23] xen/riscv: use some asm-generic headers ( even v4 was
     merged to staging branch, I just wasn't apply changes on top of the latest staging branch )
   - [PATCH v5 03/23] xen/riscv: introduce nospec.h
   - [PATCH v5 10/23] xen/riscv: introduces acrquire, release and full barriers
 - Introduce new patches:
   - xen/riscv: introduce extenstion support check by compiler
   - xen/bitops: put __ffs() and ffz() into linux compatible header
   - xen/bitops: implement fls{l}() in common logic
 - The following patches were dropped:
   - drop some patches related to bitops operations as they were introduced in another
     patch series [...]
   - introduce new version for generic __ffs(), ffz() and fls{l}().
 - Merge patch from patch series "[PATCH v9 0/7]  Introduce generic headers" to this patch
   series as only one patch left in the generic headers patch series and it is more about
   RISC-V.
 - Other changes are specific to specific patches. please look at specific patch.
---
Changes in V5:
 - Update the cover letter as one of the dependencies were merged to staging.
 - Was introduced asm-generic for atomic ops and separate patches for asm-generic bit ops
 - Moved fence.h to separate patch to deal with some patches dependecies on fence.h
 - Patches were dropped as they were merged to staging:
   * [PATCH v4 03/30] xen: add support in public/hvm/save.h for PPC and RISC-V
   * [PATCH v4 04/30] xen/riscv: introduce cpufeature.h
   * [PATCH v4 05/30] xen/riscv: introduce guest_atomics.h
   * [PATCH v4 06/30] xen: avoid generation of empty asm/iommu.h
   * [PATCH v4 08/30] xen/riscv: introduce setup.h
   * [PATCH v4 10/30] xen/riscv: introduce flushtlb.h
   * [PATCH v4 11/30] xen/riscv: introduce smp.h
   * [PATCH v4 15/30] xen/riscv: introduce irq.h
   * [PATCH v4 16/30] xen/riscv: introduce p2m.h
   * [PATCH v4 17/30] xen/riscv: introduce regs.h
   * [PATCH v4 18/30] xen/riscv: introduce time.h
   * [PATCH v4 19/30] xen/riscv: introduce event.h
   * [PATCH v4 22/30] xen/riscv: define an address of frame table
 - Other changes are specific to specific patches. please look at specific patch
---
Changes in V4:
 - Update the cover letter message: new patch series dependencies.
 - Some patches were merged to staging, so they were dropped in this patch series:
     [PATCH v3 09/34] xen/riscv: introduce system.h
     [PATCH v3 18/34] xen/riscv: introduce domain.h
     [PATCH v3 19/34] xen/riscv: introduce guest_access.h
 - Was sent out of this patch series:
     [PATCH v3 16/34] xen/lib: introduce generic find next bit operations
 - [PATCH v3 17/34] xen/riscv: add compilation of generic find-next-bit.c was
   droped as CONFIG_GENERIC_FIND_NEXT_BIT was dropped.
 - All other changes are specific to a specific patch.
---
Changes in V3:
 - Update the cover letter message
 - The following patches were dropped as they were merged to staging:
    [PATCH v2 03/39] xen/riscv:introduce asm/byteorder.h
    [PATCH v2 04/39] xen/riscv: add public arch-riscv.h
    [PATCH v2 05/39] xen/riscv: introduce spinlock.h
    [PATCH v2 20/39] xen/riscv: define bug frame tables in xen.lds.S
    [PATCH v2 34/39] xen: add RISCV support for pmu.h
    [PATCH v2 35/39] xen: add necessary headers to common to build full Xen for RISC-V
 - Instead of the following patches were introduced new:
    [PATCH v2 10/39] xen/riscv: introduce asm/iommu.h
    [PATCH v2 11/39] xen/riscv: introduce asm/nospec.h
 - remove "asm/"  for commit messages which start with "xen/riscv:"
 - code style updates.
 - add emulation of {cmp}xchg_* for 1 and 2 bytes types.
 - code style fixes.
 - add SPDX and footer for the newly added headers.
 - introduce generic find-next-bit.c.
 - some other mionor changes. ( details please find in a patch )
---
Changes in V2:
  - Drop the following patches as they are the part of [2]:
      [PATCH v1 06/57] xen/riscv: introduce paging.h
      [PATCH v1 08/57] xen/riscv: introduce asm/device.h
      [PATCH v1 10/57] xen/riscv: introduce asm/grant_table.h
      [PATCH v1 12/57] xen/riscv: introduce asm/hypercall.h
      [PATCH v1 13/57] xen/riscv: introduce asm/iocap.h
      [PATCH v1 15/57] xen/riscv: introduce asm/mem_access.h
      [PATCH v1 18/57] xen/riscv: introduce asm/random.h
      [PATCH v1 21/57] xen/riscv: introduce asm/xenoprof.h
      [PATCH v1 24/57] xen/riscv: introduce asm/percpu.h
      [PATCH v1 29/57] xen/riscv: introduce asm/hardirq.h
      [PATCH v1 33/57] xen/riscv: introduce asm/altp2m.h
      [PATCH v1 38/57] xen/riscv: introduce asm/monitor.h
      [PATCH v1 39/57] xen/riscv: introduce asm/numa.h
      [PATCH v1 42/57] xen/riscv: introduce asm/softirq.h
  - xen/lib.h in most of the cases were changed to xen/bug.h as
    mostly functionilty of bug.h is used.
  - align arch-riscv.h with Arm's version of it.
  - change the Author of commit with introduction of asm/atomic.h.
  - update some definition from spinlock.h.
  - code style changes.
---

Oleksii Kurochko (20):
  automation: introduce fixed randconfig for RISC-V
  xen/riscv: disable unnecessary configs
  xen/riscv: introduce extenstion support check by compiler
  xen/asm-generic: introduce generic non-atomic test_*bit()
  xen/bitops: implement fls{l}() in common logic
  xen/bitops: put __ffs() and ffz() into linux compatible header
  xen/riscv: introduce bitops.h
  xen/riscv: introduce cmpxchg.h
  xen/riscv: introduce io.h
  xen/riscv: introduce atomic.h
  xen/riscv: introduce monitor.h
  xen/riscv: add definition of __read_mostly
  xen/riscv: add required things to current.h
  xen/riscv: add minimal stuff to page.h to build full Xen
  xen/riscv: add minimal stuff to processor.h to build full Xen
  xen/riscv: add minimal stuff to mm.h to build full Xen
  xen/riscv: introduce vm_event_*() functions
  xen/riscv: add minimal amount of stubs to build full Xen
  xen/riscv: enable full Xen build
  xen/README: add compiler and binutils versions for RISC-V64

 README                                        |   4 +
 automation/gitlab-ci/build.yaml               |  38 +-
 docs/misc/riscv/booting.txt                   |  16 +
 xen/arch/arm/include/asm/arm32/bitops.h       |   2 +-
 xen/arch/arm/include/asm/arm64/bitops.h       |  27 +-
 xen/arch/arm/include/asm/bitops.h             |   7 +-
 xen/arch/ppc/include/asm/bitops.h             |  24 -
 xen/arch/riscv/Makefile                       |  18 +-
 xen/arch/riscv/arch.mk                        |  14 +-
 xen/arch/riscv/configs/tiny64_defconfig       |  17 +
 xen/arch/riscv/early_printk.c                 | 168 -------
 xen/arch/riscv/include/asm/atomic.h           | 263 +++++++++++
 xen/arch/riscv/include/asm/bitops.h           | 144 ++++++
 xen/arch/riscv/include/asm/cache.h            |   2 +
 xen/arch/riscv/include/asm/cmpxchg.h          | 209 +++++++++
 xen/arch/riscv/include/asm/config.h           |   2 +
 xen/arch/riscv/include/asm/current.h          |  19 +
 xen/arch/riscv/include/asm/io.h               | 167 +++++++
 xen/arch/riscv/include/asm/mm.h               | 240 ++++++++++
 xen/arch/riscv/include/asm/monitor.h          |  26 ++
 xen/arch/riscv/include/asm/page.h             |  19 +
 xen/arch/riscv/include/asm/processor.h        |  20 +
 xen/arch/riscv/mm.c                           |  52 ++-
 xen/arch/riscv/setup.c                        |  10 +-
 xen/arch/riscv/stubs.c                        | 415 ++++++++++++++++++
 xen/arch/riscv/traps.c                        |  25 ++
 xen/arch/riscv/vm_event.c                     |  19 +
 xen/arch/x86/include/asm/bitops.h             |   6 +-
 xen/common/bitops.c                           |  22 +
 xen/drivers/passthrough/arm/smmu-v3.c         |   2 +
 xen/include/asm-generic/atomic-ops.h          |  97 ++++
 xen/include/asm-generic/bitops/bitops-bits.h  |  21 +
 .../asm-generic/bitops/generic-non-atomic.h   |  89 ++++
 xen/include/asm-generic/bitops/test-bit.h     |  18 +
 xen/include/xen/bitops.h                      |  24 +
 xen/include/xen/linux-compat.h                |   3 +
 xen/lib/find-next-bit.c                       |   1 +
 37 files changed, 2012 insertions(+), 238 deletions(-)
 create mode 100644 docs/misc/riscv/booting.txt
 create mode 100644 xen/arch/riscv/include/asm/atomic.h
 create mode 100644 xen/arch/riscv/include/asm/bitops.h
 create mode 100644 xen/arch/riscv/include/asm/cmpxchg.h
 create mode 100644 xen/arch/riscv/include/asm/io.h
 create mode 100644 xen/arch/riscv/include/asm/monitor.h
 create mode 100644 xen/arch/riscv/stubs.c
 create mode 100644 xen/arch/riscv/vm_event.c
 create mode 100644 xen/include/asm-generic/atomic-ops.h
 create mode 100644 xen/include/asm-generic/bitops/bitops-bits.h
 create mode 100644 xen/include/asm-generic/bitops/generic-non-atomic.h
 create mode 100644 xen/include/asm-generic/bitops/test-bit.h

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Mar 15 18:06:28 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 18:06:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693987.1082690 (Exim 4.92)
	(envelope-from )
	id 1rlBwn-00061t-HY; Fri, 15 Mar 2024 18:06:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693987.1082690; Fri, 15 Mar 2024 18:06:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rlBwn-00060j-BS; Fri, 15 Mar 2024 18:06:25 +0000
Received: by outflank-mailman (input) for mailman id 693987;
 Fri, 15 Mar 2024 18:06:24 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rlBwm-0005yW-5n
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 18:06:24 +0000
Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com
 [2a00:1450:4864:20::236])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id bb93d62c-e2f6-11ee-afdd-a90da7624cb6;
 Fri, 15 Mar 2024 19:06:23 +0100 (CET)
Received: by mail-lj1-x236.google.com with SMTP id
 38308e7fff4ca-2d2509c66daso33948251fa.3
 for ; Fri, 15 Mar 2024 11:06:23 -0700 (PDT)
Received: from fedora.. ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id
 g29-20020a05651c079d00b002d0acb57c89sm568939lje.64.2024.03.15.11.06.20
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 15 Mar 2024 11:06:20 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: bb93d62c-e2f6-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1710525982; x=1711130782; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=b956toTh9DhRZ58EEcldn/bf2x22T6+RI+Lzdk85ScQ=;
        b=e727lqbUDai+CJTFcFdEl1/H1UlCA4YU+fzYnh+cOxeOMYZhX74NNzYl7HHZZD9CSL
         Z0W8JPg8Jggq/pOsblEOH78N64xy+paUSY5PyOI+qRrB18Ro5hIG+xea5U6sxXukXTjv
         suVlLQCQV5n9AZxAGRIplA3+olr1h+px8MgNzSLGriVhoy4vXzwlKy3Loq8MHNi2ZwQ+
         gbzJQBnWJpB/6OWufvHpU9s2FqM15NR/DN8u4aLuUzys0QoF0SiIJiMmd6RBC1nZ1D7q
         l26sv/CDwy3Ro91SduGYpmC8F2AK8cuEuRkNMcMvFErUzUt40PdpxAR6vOZydcH+CAjJ
         id0A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710525982; x=1711130782;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=b956toTh9DhRZ58EEcldn/bf2x22T6+RI+Lzdk85ScQ=;
        b=KdYvLIQS9v6eDEz31yM4NvJS8Z+eWlBwMnNg0BY7dNWxh4mJjY8lEOcR/1ei/tsVzf
         ofqV/+3EKgoaLNnm0x25ToThmyClz+bkATdRpdEk5fVdtU1A764XqDewT/vSeDAQ9XAy
         ihn9/Mh7qMNFfNJxsRxpXIy0jPScLcO5klxvbVc3XPOFkC1r+mr8hBY+jonL8b2WkR+w
         xKCT/BwSJyPZmePotIqaPIT2YTl+Dpu4klUTcty8i43kLEepBUsMUBUthSQcU6QAmoin
         cdnl+vwnHAe5gRpeD2W18xv6qqZgUSK96nlfs1hcNmevDqtL09VSVQJoH2T5bByz7sEI
         GzEA==
X-Gm-Message-State: AOJu0YwtLwxbCZAKrEvHggf8tguXgypzo/Ffqeqjn7W+EOELfA6FiQvc
	75vlHs17Jrb3x+gdgiyTrqhHGFu0wUOk2o2ZOp+3ciro26WFkOMdFzBFPG+z44s=
X-Google-Smtp-Source: AGHT+IEKZeiL7AjpnXkkbaowoYHyzoJTG23T1OhsLFonO4lxu26OuDUItxfXRVkVZcJK/PCBAV3i3w==
X-Received: by 2002:a05:651c:1050:b0:2d4:71bd:b072 with SMTP id x16-20020a05651c105000b002d471bdb072mr4127027ljm.14.1710525981785;
        Fri, 15 Mar 2024 11:06:21 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Doug Goldstein ,
	Stefano Stabellini ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis 
Subject: [PATCH v6 02/20] xen/riscv: disable unnecessary configs
Date: Fri, 15 Mar 2024 19:05:58 +0100
Message-ID: <5a1b905601db481a1a625dafbbf9b28dbe12876c.1710517542.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

This patch disables unnecessary configs for two cases:
1. By utilizing EXTRA_FIXED_RANDCONFIG for randconfig builds (GitLab CI jobs).
2. By using tiny64_defconfig for non-randconfig builds.

Signed-off-by: Oleksii Kurochko 
---
Changes in V6:
 - Nothing changed. Only rebase.
---
Changes in V5:
 - Rebase and drop duplicated configs in EXTRA_FIXED_RANDCONFIG list
 - Update the commit message
---
Changes in V4:
 - Nothing changed. Only rebase
---
Changes in V3:
 - Remove EXTRA_FIXED_RANDCONFIG for non-randconfig jobs.
   For non-randconfig jobs, it is sufficient to disable configs by using the defconfig.
 - Remove double blank lines in build.yaml file before archlinux-current-gcc-riscv64-debug
---
Changes in V2:
 - update the commit message.
 - remove xen/arch/riscv/Kconfig changes.
---
 automation/gitlab-ci/build.yaml         | 24 ++++++++++++++++++++++++
 xen/arch/riscv/configs/tiny64_defconfig | 17 +++++++++++++++++
 2 files changed, 41 insertions(+)

diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-ci/build.yaml
index aac29ee13a..3b3d2c47dc 100644
--- a/automation/gitlab-ci/build.yaml
+++ b/automation/gitlab-ci/build.yaml
@@ -519,6 +519,30 @@ alpine-3.18-gcc-debug-arm64-boot-cpupools:
       CONFIG_EXPERT=y
       CONFIG_GRANT_TABLE=n
       CONFIG_MEM_ACCESS=n
+      CONFIG_SCHED_CREDIT=n
+      CONFIG_SCHED_CREDIT2=n
+      CONFIG_SCHED_RTDS=n
+      CONFIG_SCHED_NULL=n
+      CONFIG_SCHED_ARINC653=n
+      CONFIG_TRACEBUFFER=n
+      CONFIG_HYPFS=n
+      CONFIG_SPECULATIVE_HARDEN_ARRAY=n
+      CONFIG_ARGO=n
+      CONFIG_HYPFS_CONFIG=n
+      CONFIG_CORE_PARKING=n
+      CONFIG_DEBUG_TRACE=n
+      CONFIG_IOREQ_SERVER=n
+      CONFIG_CRASH_DEBUG=n
+      CONFIG_KEXEC=n
+      CONFIG_LIVEPATCH=n
+      CONFIG_NUMA=n
+      CONFIG_PERF_COUNTERS=n
+      CONFIG_HAS_PMAP=n
+      CONFIG_XENOPROF=n
+      CONFIG_COMPAT=n
+      CONFIG_UBSAN=n
+      CONFIG_NEEDS_LIBELF=n
+      CONFIG_XSM=n
 
 archlinux-current-gcc-riscv64:
   extends: .gcc-riscv64-cross-build
diff --git a/xen/arch/riscv/configs/tiny64_defconfig b/xen/arch/riscv/configs/tiny64_defconfig
index 09defe236b..35915255e6 100644
--- a/xen/arch/riscv/configs/tiny64_defconfig
+++ b/xen/arch/riscv/configs/tiny64_defconfig
@@ -7,6 +7,23 @@
 # CONFIG_GRANT_TABLE is not set
 # CONFIG_SPECULATIVE_HARDEN_ARRAY is not set
 # CONFIG_MEM_ACCESS is not set
+# CONFIG_ARGO is not set
+# CONFIG_HYPFS_CONFIG is not set
+# CONFIG_CORE_PARKING is not set
+# CONFIG_DEBUG_TRACE is not set
+# CONFIG_IOREQ_SERVER is not set
+# CONFIG_CRASH_DEBUG is not setz
+# CONFIG_KEXEC is not set
+# CONFIG_LIVEPATCH is not set
+# CONFIG_NUMA is not set
+# CONFIG_PERF_COUNTERS is not set
+# CONFIG_HAS_PMAP is not set
+# CONFIG_TRACEBUFFER is not set
+# CONFIG_XENOPROF is not set
+# CONFIG_COMPAT is not set
+# CONFIG_COVERAGE is not set
+# CONFIG_UBSAN is not set
+# CONFIG_NEEDS_LIBELF is not set
 
 CONFIG_RISCV_64=y
 CONFIG_DEBUG=y
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Mar 15 18:06:28 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 18:06:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693988.1082695 (Exim 4.92)
	(envelope-from )
	id 1rlBwn-00069n-Ox; Fri, 15 Mar 2024 18:06:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693988.1082695; Fri, 15 Mar 2024 18:06:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rlBwn-00068K-Kw; Fri, 15 Mar 2024 18:06:25 +0000
Received: by outflank-mailman (input) for mailman id 693988;
 Fri, 15 Mar 2024 18:06:24 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rlBwm-0005yV-Nz
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 18:06:24 +0000
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com
 [2a00:1450:4864:20::229])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id baa43a90-e2f6-11ee-a1ee-f123f15fe8a2;
 Fri, 15 Mar 2024 19:06:22 +0100 (CET)
Received: by mail-lj1-x229.google.com with SMTP id
 38308e7fff4ca-2d29aad15a5so28945411fa.3
 for ; Fri, 15 Mar 2024 11:06:22 -0700 (PDT)
Received: from fedora.. ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id
 g29-20020a05651c079d00b002d0acb57c89sm568939lje.64.2024.03.15.11.06.20
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 15 Mar 2024 11:06:20 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: baa43a90-e2f6-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1710525980; x=1711130780; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=bnZCS2jkOQG1OwG5+NnDvOYWHQ+YyiN+63x/P+hS844=;
        b=CkqH++FjYYpEW1Pu7IAlD3oX9jh7rYJoI6qwTDFCDABGF6/1i9/7uo+jhJmE1QczsK
         TdJ8gBNBSU5/cbWDYT+/IHgpUxDWhomcNrbGGYPLBOancy10gFvw/xZHgCosRRFqFXOu
         SnRWUuxIbZ3KO4F6VEbacPYmlmbsWl/T1S9Thal99gri8FQP5HNl49gvX581WGi212OD
         LlAQM4wiNLQhXSVJpF8VAhYGzWVk/c68VbbGmIXPLGmJRgQBfCEFbGaoKYtt8562gfZP
         P+q7h2mYs/a9wkvy6HQbqpLX1bjV8iENyHSOqvi3NA57TwfjaplpObI9/KMxeC8yDuuH
         77Ow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710525980; x=1711130780;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=bnZCS2jkOQG1OwG5+NnDvOYWHQ+YyiN+63x/P+hS844=;
        b=JcjpHj6KGG2HoGslKj2OCky/nnkdz9caWuuEq1GdnND5tTme39n3urh9bp4TuF2MM8
         qtvsFtCLhEamCbd5kAjjhQUfgfewo5mDAUxjvk4mg+i3DAnrKt7YCPwoTx1AHQvYO/sx
         BV/pptfRTkLEeJJIhEwYxrDnIS1VNY/agXZKYzsoXtvJpg3FKRO2/lEHwN9nBlJCp/p+
         HAf60s2wWZ8JOUasTj3F89xtEgfaWD1Yx7WKrPoptKUIA/vmABsk+Z4ckQyKPB3txjDK
         DgzCh0qUctzwTEX3plq+a8TzoEwDWbFmZrI4xgpkQQtvNre1234Kbjfv/OmPpglVye31
         gYjQ==
X-Gm-Message-State: AOJu0Yxz/BEBUXJwJkiuNODgXh2QTOWDZMttjXK6VRgqEABGFB4d5fci
	4rpKdUVfpAmj42nK2NiaMKyxYC7br280AJNQ8yjoKXVtvF7+wj2LC9VjXqOcXNw=
X-Google-Smtp-Source: AGHT+IE7CXomGSgKuwJJpH8tAd57HXXdUUH5gqwKlDD0cS04ArIqQSpMGEqHTi7M7Y1tC2d2O80frw==
X-Received: by 2002:a2e:8011:0:b0:2d4:6910:2ee5 with SMTP id j17-20020a2e8011000000b002d469102ee5mr2530317ljg.8.1710525980466;
        Fri, 15 Mar 2024 11:06:20 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Doug Goldstein ,
	Stefano Stabellini ,
	Michal Orzel 
Subject: [PATCH v6 01/20] automation: introduce fixed randconfig for RISC-V
Date: Fri, 15 Mar 2024 19:05:57 +0100
Message-ID: 
X-Mailer: git-send-email 2.43.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

This patch introduces the anchor riscv-fixed-randconfig,
which includes all configurations that should be disabled for
randconfig builds.

Suggested-by: Stefano Stabellini 
Signed-off-by: Oleksii Kurochko 
Reviewed-by: Michal Orzel 
Acked-by: Stefano Stabellini 
---
Changes in V6:
 - new patch for this patch series
 - Reviewed-by and Acked-by was added. ( in another patch series they were
   recieved. )
---
 automation/gitlab-ci/build.yaml | 14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-ci/build.yaml
index 6d2cb18b88..aac29ee13a 100644
--- a/automation/gitlab-ci/build.yaml
+++ b/automation/gitlab-ci/build.yaml
@@ -512,6 +512,14 @@ alpine-3.18-gcc-debug-arm64-boot-cpupools:
       CONFIG_BOOT_TIME_CPUPOOLS=y
 
 # RISC-V 64 cross-build
+.riscv-fixed-randconfig:
+  variables: &riscv-fixed-randconfig
+    EXTRA_FIXED_RANDCONFIG: |
+      CONFIG_COVERAGE=n
+      CONFIG_EXPERT=y
+      CONFIG_GRANT_TABLE=n
+      CONFIG_MEM_ACCESS=n
+
 archlinux-current-gcc-riscv64:
   extends: .gcc-riscv64-cross-build
   variables:
@@ -532,8 +540,7 @@ archlinux-current-gcc-riscv64-randconfig:
     CONTAINER: archlinux:current-riscv64
     KBUILD_DEFCONFIG: tiny64_defconfig
     RANDCONFIG: y
-    EXTRA_FIXED_RANDCONFIG:
-      CONFIG_COVERAGE=n
+    <<: *riscv-fixed-randconfig
 
 archlinux-current-gcc-riscv64-debug-randconfig:
   extends: .gcc-riscv64-cross-build-debug
@@ -541,8 +548,7 @@ archlinux-current-gcc-riscv64-debug-randconfig:
     CONTAINER: archlinux:current-riscv64
     KBUILD_DEFCONFIG: tiny64_defconfig
     RANDCONFIG: y
-    EXTRA_FIXED_RANDCONFIG:
-      CONFIG_COVERAGE=n
+    <<: *riscv-fixed-randconfig
 
 # Power cross-build
 debian-bullseye-gcc-ppc64le:
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Mar 15 18:06:28 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 18:06:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693991.1082734 (Exim 4.92)
	(envelope-from )
	id 1rlBwq-0007AT-Q0; Fri, 15 Mar 2024 18:06:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693991.1082734; Fri, 15 Mar 2024 18:06:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rlBwq-00079a-IA; Fri, 15 Mar 2024 18:06:28 +0000
Received: by outflank-mailman (input) for mailman id 693991;
 Fri, 15 Mar 2024 18:06:27 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rlBwp-0005yW-BD
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 18:06:27 +0000
Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com
 [2a00:1450:4864:20::22b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id bda8ec48-e2f6-11ee-afdd-a90da7624cb6;
 Fri, 15 Mar 2024 19:06:26 +0100 (CET)
Received: by mail-lj1-x22b.google.com with SMTP id
 38308e7fff4ca-2d2509c66daso33949101fa.3
 for ; Fri, 15 Mar 2024 11:06:26 -0700 (PDT)
Received: from fedora.. ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id
 g29-20020a05651c079d00b002d0acb57c89sm568939lje.64.2024.03.15.11.06.24
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 15 Mar 2024 11:06:24 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: bda8ec48-e2f6-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1710525985; x=1711130785; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=ZLjLu7NTZLQs4Ktw0PAaKJT749xyDrNgvm4eQvKv/jw=;
        b=XaWI6uKxw02paAqGsB4GaPOcUSvIRO40T+wVYItiUYobvZcMyOmW2CrBhnDVQRCWTO
         0lqke7b/Q9BX+ML2RQxjlPMLVrmkiXqZB85g35FwhjglwJbMY0nW6Bx0toCtGzPrDqUq
         v2TKeHA3hPdCGhQwpigIdanzAwUlsfGEpPoarnU+ePEKBB481P+KG/q0L7iX1GF1dksY
         zj3QKK37Cav4kGfAIM7rhxmGspWL4fJxZo1pfbJrkMtZ1A24fc3XXwN6gr3320kaRsIP
         m34vRLm6YfWEemJ4w6AsV6PrGPndAZw6B0EfW7kBdS0xDUwhsW6Va1OPJISoNaVSdmgP
         ZgQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710525985; x=1711130785;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=ZLjLu7NTZLQs4Ktw0PAaKJT749xyDrNgvm4eQvKv/jw=;
        b=l0g4XXlYT0kNF6SaQ2+XnsGHBc0IC5k8GLONej1cW4l7q4HhKy60vDguJELshLaxQN
         roYkszp2jQ4zKCMVnZvsE9JncBpyYxy7X0M+kLsc0qLJ8fh4C7q45aZv64DO5LS0M3Gp
         ua2qPm8f/S2/bY5yx5kSIHE85Shvc9pL0o/AFcUXB/LiJTnavMk+wy/gV9dRHAanHMFP
         jCPvH4URxeEZkJUGhqLpmIEs15Al1yAUWVlFaNju5AD+a2aiCTlSGRDpwSuZX4YJg4DV
         DVEX/gnqHLuPqegstMtyZPCfoIKre5e25LcWwM9N6VN4I6PansW3bWkY66dq+b7Jg/jd
         yjRw==
X-Gm-Message-State: AOJu0Yz96wC2ZjUOqlPscj6jDVPSHiZ7hIKzCo3L8Zr/uJFodB3lZ4i8
	DOyvv4qhfDONdzeSaOFb+1vzXG7xwWE3O0B8SVc1vQ5K9alLtYRhZSJwUP07D/Y=
X-Google-Smtp-Source: AGHT+IGCsFBtBhS2vCW2niqNiPD74qj+Jg9e+Rhh+ldepWAMvFmN3caWAbPP+JYe7DVl2qxWuWwtjg==
X-Received: by 2002:a2e:9357:0:b0:2d3:f3bc:bb65 with SMTP id m23-20020a2e9357000000b002d3f3bcbb65mr3692888ljh.11.1710525985392;
        Fri, 15 Mar 2024 11:06:25 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Wei Liu ,
	Shawn Anastasio ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v6 05/20] xen/bitops: implement fls{l}() in common logic
Date: Fri, 15 Mar 2024 19:06:01 +0100
Message-ID: 
X-Mailer: git-send-email 2.43.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Return type was left 'int' because of the following compilation error:

./include/xen/kernel.h:18:21: error: comparison of distinct pointer types lacks a cast [-Werror]
       18 |         (void) (&_x == &_y);            \
          |                     ^~
    common/page_alloc.c:1843:34: note: in expansion of macro 'min'
     1843 |         unsigned int inc_order = min(MAX_ORDER, flsl(e - s) - 1);

generic_fls{l} was used instead of __builtin_clz{l}(x) as if x is 0,
the result in undefined.

Signed-off-by: Oleksii Kurochko 
---
Changes in V6:
 - new patch for the patch series.
---
 xen/arch/arm/include/asm/arm32/bitops.h |  2 +-
 xen/arch/arm/include/asm/arm64/bitops.h |  6 ++----
 xen/arch/arm/include/asm/bitops.h       |  7 ++-----
 xen/arch/ppc/include/asm/bitops.h       |  3 ---
 xen/arch/x86/include/asm/bitops.h       |  6 ++++--
 xen/common/bitops.c                     | 22 ++++++++++++++++++++++
 xen/include/xen/bitops.h                | 24 ++++++++++++++++++++++++
 7 files changed, 55 insertions(+), 15 deletions(-)

diff --git a/xen/arch/arm/include/asm/arm32/bitops.h b/xen/arch/arm/include/asm/arm32/bitops.h
index d0309d47c1..5552d4e945 100644
--- a/xen/arch/arm/include/asm/arm32/bitops.h
+++ b/xen/arch/arm/include/asm/arm32/bitops.h
@@ -1,7 +1,7 @@
 #ifndef _ARM_ARM32_BITOPS_H
 #define _ARM_ARM32_BITOPS_H
 
-#define flsl fls
+#define arch_flsl fls
 
 /*
  * Little endian assembly bitops.  nr = 0 -> byte 0 bit 0.
diff --git a/xen/arch/arm/include/asm/arm64/bitops.h b/xen/arch/arm/include/asm/arm64/bitops.h
index 0efde29068..5f5d97faa0 100644
--- a/xen/arch/arm/include/asm/arm64/bitops.h
+++ b/xen/arch/arm/include/asm/arm64/bitops.h
@@ -22,17 +22,15 @@ static /*__*/always_inline unsigned long __ffs(unsigned long word)
  */
 #define ffz(x)  __ffs(~(x))
 
-static inline int flsl(unsigned long x)
+static inline int arch_flsl(unsigned long x)
 {
         uint64_t ret;
 
-        if (__builtin_constant_p(x))
-               return generic_flsl(x);
-
         asm("clz\t%0, %1" : "=r" (ret) : "r" (x));
 
         return BITS_PER_LONG - ret;
 }
+#define arch_flsl arch_flsl
 
 /* Based on linux/include/asm-generic/bitops/find.h */
 
diff --git a/xen/arch/arm/include/asm/bitops.h b/xen/arch/arm/include/asm/bitops.h
index 5104334e48..bcf7b48731 100644
--- a/xen/arch/arm/include/asm/bitops.h
+++ b/xen/arch/arm/include/asm/bitops.h
@@ -145,17 +145,14 @@ static inline int test_bit(int nr, const volatile void *addr)
  * the clz instruction for much better code efficiency.
  */
 
-static inline int fls(unsigned int x)
+static inline int arch_fls(unsigned int x)
 {
         int ret;
 
-        if (__builtin_constant_p(x))
-               return generic_fls(x);
-
         asm("clz\t%"__OP32"0, %"__OP32"1" : "=r" (ret) : "r" (x));
         return 32 - ret;
 }
-
+#define arch_fls arch_fls
 
 #define arch_ffs(x) ({ unsigned int __t = (x); fls(ISOLATE_LSB(__t)); })
 #define arch_ffsl(x) ({ unsigned long __t = (x); flsl(ISOLATE_LSB(__t)); })
diff --git a/xen/arch/ppc/include/asm/bitops.h b/xen/arch/ppc/include/asm/bitops.h
index 989d341a44..16447a4be6 100644
--- a/xen/arch/ppc/include/asm/bitops.h
+++ b/xen/arch/ppc/include/asm/bitops.h
@@ -171,9 +171,6 @@ static inline int __test_and_clear_bit(int nr, volatile void *addr)
     return (old & mask) != 0;
 }
 
-#define flsl(x) generic_flsl(x)
-#define fls(x) generic_fls(x)
-
 /* Based on linux/include/asm-generic/bitops/ffz.h */
 /*
  * ffz - find first zero in word.
diff --git a/xen/arch/x86/include/asm/bitops.h b/xen/arch/x86/include/asm/bitops.h
index dd439b69a0..87e91a1b7b 100644
--- a/xen/arch/x86/include/asm/bitops.h
+++ b/xen/arch/x86/include/asm/bitops.h
@@ -438,7 +438,7 @@ static always_inline unsigned int arch_ffsl(unsigned long x)
  *
  * This is defined the same way as ffs.
  */
-static inline int flsl(unsigned long x)
+static always_inline int arch_flsl(unsigned long x)
 {
     long r;
 
@@ -448,8 +448,9 @@ static inline int flsl(unsigned long x)
           "1:" : "=r" (r) : "rm" (x));
     return (int)r+1;
 }
+#define arch_flsl arch_flsl
 
-static inline int fls(unsigned int x)
+static always_inline int arch_fls(unsigned int x)
 {
     int r;
 
@@ -459,6 +460,7 @@ static inline int fls(unsigned int x)
           "1:" : "=r" (r) : "rm" (x));
     return r + 1;
 }
+#define arch_fls arch_fls
 
 /**
  * hweightN - returns the hamming weight of a N-bit word
diff --git a/xen/common/bitops.c b/xen/common/bitops.c
index a8c32f6767..95bc47176b 100644
--- a/xen/common/bitops.c
+++ b/xen/common/bitops.c
@@ -62,9 +62,31 @@ static void test_ffs(void)
     CHECK(ffs64, (uint64_t)0x8000000000000000, 64);
 }
 
+static void test_fls(void)
+{
+    /* unsigned int ffs(unsigned int) */
+    CHECK(fls, 1, 1);
+    CHECK(fls, 3, 2);
+    CHECK(fls, 3U << 30, 32);
+
+    /* unsigned int flsl(unsigned long) */
+    CHECK(flsl, 1, 1);
+    CHECK(flsl, 1UL << (BITS_PER_LONG - 1), BITS_PER_LONG);
+#if BITS_PER_LONG > 32
+    CHECK(flsl, 3UL << 32, 34);
+#endif
+
+    /* unsigned int fls64(uint64_t) */
+    CHECK(fls64, 1, 1);
+    CHECK(fls64, 0x00000000C0000000ULL, 32);
+    CHECK(fls64, 0x0000000180000000ULL, 33);
+    CHECK(fls64, 0xC000000000000000ULL, 64);
+}
+
 static int __init cf_check test_bitops(void)
 {
     test_ffs();
+    test_fls();
 
     return 0;
 }
diff --git a/xen/include/xen/bitops.h b/xen/include/xen/bitops.h
index f14ad0d33a..fac8f768ff 100644
--- a/xen/include/xen/bitops.h
+++ b/xen/include/xen/bitops.h
@@ -69,6 +69,30 @@ static inline int generic_flsl(unsigned long x)
 
 #include 
 
+static always_inline __pure int fls(unsigned int x)
+{
+    if (__builtin_constant_p(x))
+        return generic_fls(x);
+
+#ifndef arch_fls
+#define arch_fls generic_fls
+#endif
+
+    return arch_fls(x);
+}
+
+static always_inline __pure int flsl(unsigned long x)
+{
+    if (__builtin_constant_p(x))
+        return generic_flsl(x);
+
+#ifndef arch_flsl
+#define arch_flsl generic_flsl
+#endif
+
+    return arch_flsl(x);
+}
+
 /*
  * Find First Set bit.  Bits are labelled from 1.
  */
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Mar 15 18:06:30 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 18:06:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693992.1082744 (Exim 4.92)
	(envelope-from )
	id 1rlBws-0007SN-25; Fri, 15 Mar 2024 18:06:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693992.1082744; Fri, 15 Mar 2024 18:06:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rlBwr-0007Rf-UE; Fri, 15 Mar 2024 18:06:29 +0000
Received: by outflank-mailman (input) for mailman id 693992;
 Fri, 15 Mar 2024 18:06:28 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rlBwq-0005yW-Ji
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 18:06:28 +0000
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com
 [2a00:1450:4864:20::232])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id be734498-e2f6-11ee-afdd-a90da7624cb6;
 Fri, 15 Mar 2024 19:06:28 +0100 (CET)
Received: by mail-lj1-x232.google.com with SMTP id
 38308e7fff4ca-2d47a92cfefso28803311fa.1
 for ; Fri, 15 Mar 2024 11:06:28 -0700 (PDT)
Received: from fedora.. ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id
 g29-20020a05651c079d00b002d0acb57c89sm568939lje.64.2024.03.15.11.06.25
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 15 Mar 2024 11:06:26 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: be734498-e2f6-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1710525987; x=1711130787; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=KHUhh6naISvb/QyLVfD3mSAYqmy1k+9yyg9dbj8PXL4=;
        b=bjvD0xnUNaaIG1n6/NWv6b50eIFufHWdZAmLILX5eNa30AxcN1bFgu0y1f3DUQkAUb
         zJIC1FfZgPZoo+sIRCIRASaRTiu+4Cvsu4IUH8DcMBfRAWfMGDUauzEUCIuTy5LTDC0q
         Xe4Vy+5MEct2Mf6P8FoVyqSiwn6VMFKMAIHHPdRGNJd0YLDHioXGHMP3tElJY8kessNM
         2HWqRjdf2swgHY6snYh7JyP6q5PnoWksKd6uCc4ZKFmr5VzGHj4KsXF0C6Z2Op7IomAu
         Smrh5tBg7gS2GJVUoIxbyZaCVpK8gcYUtiJ4BpqKfe/CiA0E0iVWoS04yykO5MibhCSJ
         bF6A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710525987; x=1711130787;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=KHUhh6naISvb/QyLVfD3mSAYqmy1k+9yyg9dbj8PXL4=;
        b=nGrEwoqzajUq3pHDviDriaZW+swCqetCi+QyFt08GJ3aFXfrMVvcbirUS5EmrVKM5R
         x6z8OutKj014jBtFAzRYPf+YngRzto7PstyLI0yUXjK5UDB1MmhmGeJdpqZItmvoz52B
         M2Jop3KiZtmT4l8psG+BzcCLSofILlHrid78s8+bhDEhvzoDB0tYHvlmbWdu+p9hsmKK
         kL2oSb2VZfNGt2praSxWNt06aS3Mp8P7FFVzxpSl7Bjwcbo3oITXAtqRUVEu6uo0bfAF
         iQwZX9Td/iOOVhF0rYxZEJvueQDAv2B+VPLmvaD5lxn0fXT/iiEspDW4UE4ra4fs1PHA
         ImVQ==
X-Gm-Message-State: AOJu0Yx3PJZgiqV8fZQccRIqkcy/8N5+Ie5l7Hkv3beTTLUhywT+AGXj
	3mWLIiigSELiQmxEYLqyvQ7Y4V1X+ziYrroJcEh7SNg7CtYjpKEkUWU50ZlG7DE=
X-Google-Smtp-Source: AGHT+IEwnlLHAuHLlfFWIVLSotj2xqJki8LDNKZtupckw1Hw046uDDkclaJtZGSbwoAiDHMfHPWPEg==
X-Received: by 2002:a2e:9b07:0:b0:2d3:8b2:6885 with SMTP id u7-20020a2e9b07000000b002d308b26885mr2522427lji.49.1710525986911;
        Fri, 15 Mar 2024 11:06:26 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Wei Liu ,
	Shawn Anastasio ,
	Rahul Singh 
Subject: [PATCH v6 06/20] xen/bitops: put __ffs() and ffz() into linux compatible header
Date: Fri, 15 Mar 2024 19:06:02 +0100
Message-ID: <8bc35da4a9fd44d2dcf9677dcc99334eb7142581.1710517542.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

The mentioned macros exist only because of Linux compatible purpose.

The patch defines __ffs() in terms of Xen bitops and it is safe
to define in this way ( as __ffs() - 1 ) as considering that __ffs()
was defined as __builtin_ctzl(x), which has undefined behavior when x=0,
so it is assumed that such cases are not encountered in the current code.

Signed-off-by: Oleksii Kurochko 
---
Changes in V6:
 - new patch for the patch series.
---
 xen/arch/arm/include/asm/arm64/bitops.h | 21 ---------------------
 xen/arch/ppc/include/asm/bitops.h       | 21 ---------------------
 xen/drivers/passthrough/arm/smmu-v3.c   |  2 ++
 xen/include/xen/linux-compat.h          |  3 +++
 xen/lib/find-next-bit.c                 |  1 +
 5 files changed, 6 insertions(+), 42 deletions(-)

diff --git a/xen/arch/arm/include/asm/arm64/bitops.h b/xen/arch/arm/include/asm/arm64/bitops.h
index 5f5d97faa0..2deb134388 100644
--- a/xen/arch/arm/include/asm/arm64/bitops.h
+++ b/xen/arch/arm/include/asm/arm64/bitops.h
@@ -1,27 +1,6 @@
 #ifndef _ARM_ARM64_BITOPS_H
 #define _ARM_ARM64_BITOPS_H
 
-/* Based on linux/include/asm-generic/bitops/builtin-__ffs.h */
-/**
- * __ffs - find first bit in word.
- * @word: The word to search
- *
- * Undefined if no bit exists, so code should check against 0 first.
- */
-static /*__*/always_inline unsigned long __ffs(unsigned long word)
-{
-        return __builtin_ctzl(word);
-}
-
-/* Based on linux/include/asm-generic/bitops/ffz.h */
-/*
- * ffz - find first zero in word.
- * @word: The word to search
- *
- * Undefined if no zero exists, so code should check against ~0UL first.
- */
-#define ffz(x)  __ffs(~(x))
-
 static inline int arch_flsl(unsigned long x)
 {
         uint64_t ret;
diff --git a/xen/arch/ppc/include/asm/bitops.h b/xen/arch/ppc/include/asm/bitops.h
index 16447a4be6..fd157f3632 100644
--- a/xen/arch/ppc/include/asm/bitops.h
+++ b/xen/arch/ppc/include/asm/bitops.h
@@ -171,15 +171,6 @@ static inline int __test_and_clear_bit(int nr, volatile void *addr)
     return (old & mask) != 0;
 }
 
-/* Based on linux/include/asm-generic/bitops/ffz.h */
-/*
- * ffz - find first zero in word.
- * @word: The word to search
- *
- * Undefined if no zero exists, so code should check against ~0UL first.
- */
-#define ffz(x) __ffs(~(x))
-
 /**
  * hweightN - returns the hamming weight of a N-bit word
  * @x: the word to weigh
@@ -191,16 +182,4 @@ static inline int __test_and_clear_bit(int nr, volatile void *addr)
 #define hweight16(x) __builtin_popcount((uint16_t)(x))
 #define hweight8(x)  __builtin_popcount((uint8_t)(x))
 
-/* Based on linux/include/asm-generic/bitops/builtin-__ffs.h */
-/**
- * __ffs - find first bit in word.
- * @word: The word to search
- *
- * Undefined if no bit exists, so code should check against 0 first.
- */
-static always_inline unsigned long __ffs(unsigned long word)
-{
-    return __builtin_ctzl(word);
-}
-
 #endif /* _ASM_PPC_BITOPS_H */
diff --git a/xen/drivers/passthrough/arm/smmu-v3.c b/xen/drivers/passthrough/arm/smmu-v3.c
index b1c40c2c0a..6904962467 100644
--- a/xen/drivers/passthrough/arm/smmu-v3.c
+++ b/xen/drivers/passthrough/arm/smmu-v3.c
@@ -72,12 +72,14 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/include/xen/linux-compat.h b/xen/include/xen/linux-compat.h
index 62ba71485c..de059bdf12 100644
--- a/xen/include/xen/linux-compat.h
+++ b/xen/include/xen/linux-compat.h
@@ -19,4 +19,7 @@ typedef int64_t __s64;
 
 typedef paddr_t phys_addr_t;
 
+#define __ffs(x) (ffsl(x) - 1)
+#define ffz(x) __ffs(~(x))
+
 #endif /* __XEN_LINUX_COMPAT_H__ */
diff --git a/xen/lib/find-next-bit.c b/xen/lib/find-next-bit.c
index ca6f82277e..b151f7f994 100644
--- a/xen/lib/find-next-bit.c
+++ b/xen/lib/find-next-bit.c
@@ -9,6 +9,7 @@
  * 2 of the License, or (at your option) any later version.
  */
 #include 
+#include 
 
 #include 
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Mar 15 18:06:31 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 18:06:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693993.1082754 (Exim 4.92)
	(envelope-from )
	id 1rlBwt-0007l7-MF; Fri, 15 Mar 2024 18:06:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693993.1082754; Fri, 15 Mar 2024 18:06:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rlBwt-0007jy-HY; Fri, 15 Mar 2024 18:06:31 +0000
Received: by outflank-mailman (input) for mailman id 693993;
 Fri, 15 Mar 2024 18:06:30 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rlBws-0005yV-Ic
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 18:06:30 +0000
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com
 [2a00:1450:4864:20::232])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id bef481c1-e2f6-11ee-a1ee-f123f15fe8a2;
 Fri, 15 Mar 2024 19:06:28 +0100 (CET)
Received: by mail-lj1-x232.google.com with SMTP id
 38308e7fff4ca-2d288bac3caso30176891fa.2
 for ; Fri, 15 Mar 2024 11:06:28 -0700 (PDT)
Received: from fedora.. ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id
 g29-20020a05651c079d00b002d0acb57c89sm568939lje.64.2024.03.15.11.06.27
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 15 Mar 2024 11:06:27 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: bef481c1-e2f6-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1710525988; x=1711130788; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=K7BmmOnotZNjNAla6pnLMXKldhtxVOBY9PyiBiwwiZE=;
        b=TxmN4w7fXvM0fykDbPrjG5dxs6iqmhXA6Bd5jWcOjcUKYBeneR6PEvOOciNeIdJapE
         XlM0O7BrR7MxBYl9ME/jSsvmbwdlF0Qy/Out+6z7QlD26oMCqbzmkVlJFVjfbYVgQZv6
         fcD6gA9bQ1vRIv7hF00U3yKaYCfBNDAH0Ee/3++ik0S4mZMco/TVZ22NBL0RwGwOn5HW
         UxCleCujWqgXKCWlu9HmVcoTuMVOukDeJbBQH/aPB6U0gsM36G0o+WhJwwoG9YHlV9pd
         uWxbbEIsRFScc0neJBdxphjHrwyRvFZEQ1Y+QwwGA5BGa3ccdoFP1xH6r+TFKc9iH05C
         dvJQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710525988; x=1711130788;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=K7BmmOnotZNjNAla6pnLMXKldhtxVOBY9PyiBiwwiZE=;
        b=vgxLUlNsuXNZekw5sPeUbjIyN7a/Uwg2/yzYic8xp/9kzo0dypDeYCU15GNzov1qjM
         ef2yhX5nIqlB8sCeyB0qXXl9T/afKWkCy57/MQZfrgTCNDG1TTi+34OXPfqxj6Niv1Ss
         Qi5otC7NmzZl7dibayxNJkFrnjaZdIKNeSl6GWnkZa701DsahMF6OG98Xff0ltWDn6vo
         phcarsuIF38zPiRBAZuY+Nu1o4Yt9AY0ZSqGr8KG+J4mMhfGpbiAEEqH3RJ8BuxMvOek
         /Z2Es6ArPKsaQNum6AyLm6TUHucJE9Nz3c1HVFm/sST4j9ujWpSOFk2ZQjf9wiSW9aGj
         ZRAw==
X-Gm-Message-State: AOJu0Yw8OfClbnwcDgszIYBvfB3RkYxx6Jx62Pb/170GMns85GSiivYh
	o+S1TV9ufw3DQMeqTfyWlod7VbBHwZoM5t/pG37d1SyweSfCZX+S/jTg1ovjer0=
X-Google-Smtp-Source: AGHT+IEBaldBFEU/oBGeiV/tYCFh5SAurQzdoH2PTQt4tY9+EjdLq8TELNNYvhRT+/sbaRQG8JoyOA==
X-Received: by 2002:a2e:9295:0:b0:2d4:3860:e80b with SMTP id d21-20020a2e9295000000b002d43860e80bmr3335344ljh.7.1710525988217;
        Fri, 15 Mar 2024 11:06:28 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini ,
	Wei Liu 
Subject: [PATCH v6 07/20] xen/riscv: introduce bitops.h
Date: Fri, 15 Mar 2024 19:06:03 +0100
Message-ID: <14c91e2ba2aeb6e49f9f7e549232244719fa6959.1710517542.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Taken from Linux-6.4.0-rc1

Xen's bitops.h consists of several Linux's headers:
* linux/arch/include/asm/bitops.h:
  * The following function were removed as they aren't used in Xen:
        * test_and_set_bit_lock
        * clear_bit_unlock
        * __clear_bit_unlock
  * The following functions were renamed in the way how they are
    used by common code:
        * __test_and_set_bit
        * __test_and_clear_bit
  * The declaration and implementation of the following functios
    were updated to make Xen build happy:
        * clear_bit
        * set_bit
        * __test_and_clear_bit
        * __test_and_set_bit
  * linux/include/asm-generic/bitops/generic-non-atomic.h with the
    following changes:
     * Only functions that can be reused in Xen were left;
       others were removed.
     * it was updated the message inside #ifndef ... #endif.
     * __always_inline -> always_inline to be align with definition in
       xen/compiler.h.
     * update function prototypes from
       generic___test_and_*(unsigned long nr nr, volatile unsigned long *addr)
       to
       generic___test_and_*(unsigned long nr, volatile void *addr) to be
       consistent with other related macros/defines.
     * convert identations from tabs to spaces.
     * inside generic__test_and_* use 'bitops_uint_t' instead of 'unsigned long'
        to be generic.

Signed-off-by: Oleksii Kurochko 
---
Changes in V6:
 - rebase clean ups were done: drop unused asm-generic includes
---
 Changes in V5:
   - new patch
---
 xen/arch/riscv/include/asm/bitops.h | 144 ++++++++++++++++++++++++++++
 xen/arch/riscv/include/asm/config.h |   2 +
 2 files changed, 146 insertions(+)
 create mode 100644 xen/arch/riscv/include/asm/bitops.h

diff --git a/xen/arch/riscv/include/asm/bitops.h b/xen/arch/riscv/include/asm/bitops.h
new file mode 100644
index 0000000000..21c4868355
--- /dev/null
+++ b/xen/arch/riscv/include/asm/bitops.h
@@ -0,0 +1,144 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/* Copyright (C) 2012 Regents of the University of California */
+
+#ifndef _ASM_RISCV_BITOPS_H
+#define _ASM_RISCV_BITOPS_H
+
+#include 
+
+#define BITOP_BITS_PER_WORD BITS_PER_LONG
+
+#define BITOP_TYPE
+typedef uint64_t bitops_uint_t;
+
+#include 
+
+#define __set_bit(n, p)      set_bit(n, p)
+#define __clear_bit(n, p)    clear_bit(n, p)
+
+/* Based on linux/arch/include/asm/bitops.h */
+
+#if BITS_PER_LONG == 64
+#define __AMO(op)   "amo" #op ".d"
+#elif BITS_PER_LONG == 32
+#define __AMO(op)   "amo" #op ".w"
+#else
+#error "Unexpected BITS_PER_LONG"
+#endif
+
+#define test_and_op_bit_ord(op, mod, nr, addr, ord)     \
+({                                                      \
+    unsigned long res, mask;                            \
+    mask = BITOP_MASK(nr);                              \
+    __asm__ __volatile__ (                              \
+        __AMO(op) #ord " %0, %2, %1"                    \
+        : "=r" (res), "+A" (addr[BITOP_WORD(nr)])       \
+        : "r" (mod(mask))                               \
+        : "memory");                                    \
+    ((res & mask) != 0);                                \
+})
+
+#define __op_bit_ord(op, mod, nr, addr, ord)    \
+    __asm__ __volatile__ (                      \
+        __AMO(op) #ord " zero, %1, %0"          \
+        : "+A" (addr[BITOP_WORD(nr)])           \
+        : "r" (mod(BITOP_MASK(nr)))             \
+        : "memory");
+
+#define test_and_op_bit(op, mod, nr, addr)    \
+    test_and_op_bit_ord(op, mod, nr, addr, .aqrl)
+#define __op_bit(op, mod, nr, addr) \
+    __op_bit_ord(op, mod, nr, addr, )
+
+/* Bitmask modifiers */
+#define NOP(x)    (x)
+#define NOT(x)    (~(x))
+
+/**
+ * test_and_set_bit - Set a bit and return its old value
+ * @nr: Bit to set
+ * @addr: Address to count from
+ */
+static inline int test_and_set_bit(int nr, volatile void *p)
+{
+    volatile bitops_uint_t *addr = p;
+
+    return test_and_op_bit(or, NOP, nr, addr);
+}
+
+/**
+ * test_and_clear_bit - Clear a bit and return its old value
+ * @nr: Bit to clear
+ * @addr: Address to count from
+ */
+static inline int test_and_clear_bit(int nr, volatile void *p)
+{
+    volatile bitops_uint_t *addr = p;
+
+    return test_and_op_bit(and, NOT, nr, addr);
+}
+
+/**
+ * set_bit - Atomically set a bit in memory
+ * @nr: the bit to set
+ * @addr: the address to start counting from
+ *
+ * Note that @nr may be almost arbitrarily large; this function is not
+ * restricted to acting on a single-word quantity.
+ */
+static inline void set_bit(int nr, volatile void *p)
+{
+    volatile bitops_uint_t *addr = p;
+
+    __op_bit(or, NOP, nr, addr);
+}
+
+/**
+ * clear_bit - Clears a bit in memory
+ * @nr: Bit to clear
+ * @addr: Address to start counting from
+ */
+static inline void clear_bit(int nr, volatile void *p)
+{
+    volatile bitops_uint_t *addr = p;
+
+    __op_bit(and, NOT, nr, addr);
+}
+
+/**
+ * test_and_change_bit - Toggle (change) a bit and return its old value
+ * @nr: Bit to change
+ * @addr: Address to count from
+ *
+ * This operation is atomic and cannot be reordered.
+ * It also implies a memory barrier.
+ */
+static inline int test_and_change_bit(int nr, volatile unsigned long *addr)
+{
+	return test_and_op_bit(xor, NOP, nr, addr);
+}
+
+#undef test_and_op_bit
+#undef __op_bit
+#undef NOP
+#undef NOT
+#undef __AMO
+
+#include 
+
+#define __test_and_set_bit generic___test_and_set_bit
+#define __test_and_clear_bit generic___test_and_clear_bit
+#define __test_and_change_bit generic___test_and_change_bit
+
+#include 
+
+#endif /* _ASM_RISCV_BITOPS_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/riscv/include/asm/config.h b/xen/arch/riscv/include/asm/config.h
index c5f93e6a01..a58086e4b2 100644
--- a/xen/arch/riscv/include/asm/config.h
+++ b/xen/arch/riscv/include/asm/config.h
@@ -113,6 +113,8 @@
 # error "Unsupported RISCV variant"
 #endif
 
+#define BITS_PER_BYTE 8
+
 #define BYTES_PER_LONG (1 << LONG_BYTEORDER)
 #define BITS_PER_LONG  (BYTES_PER_LONG << 3)
 #define POINTER_ALIGN  BYTES_PER_LONG
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Mar 15 18:06:32 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 18:06:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693994.1082759 (Exim 4.92)
	(envelope-from )
	id 1rlBwu-0007pC-4X; Fri, 15 Mar 2024 18:06:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693994.1082759; Fri, 15 Mar 2024 18:06:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rlBwt-0007od-TE; Fri, 15 Mar 2024 18:06:31 +0000
Received: by outflank-mailman (input) for mailman id 693994;
 Fri, 15 Mar 2024 18:06:31 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rlBws-0005yW-Qv
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 18:06:30 +0000
Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com
 [2a00:1450:4864:20::234])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id bf829991-e2f6-11ee-afdd-a90da7624cb6;
 Fri, 15 Mar 2024 19:06:29 +0100 (CET)
Received: by mail-lj1-x234.google.com with SMTP id
 38308e7fff4ca-2d41d1bedc9so38585381fa.3
 for ; Fri, 15 Mar 2024 11:06:29 -0700 (PDT)
Received: from fedora.. ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id
 g29-20020a05651c079d00b002d0acb57c89sm568939lje.64.2024.03.15.11.06.28
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 15 Mar 2024 11:06:28 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: bf829991-e2f6-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1710525989; x=1711130789; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=ti/NGZu80Gob+FUDMzaaMxrVNmtSZyxPSgcxSW8TGYY=;
        b=ioiHxM6YC4ipLL+FU8dPswJTlielQWGdGdaK5BztCVIMrqwCrzCvbUwThMeHZJQklJ
         gYf0OkydsQIeg2XIqfzikJsI/LVcTeZClhahTQnvHq+n1gmd+ymaKl3rVCHuRxgcKwmF
         ByqQxMG9Cqxp+t2P//hnHsuz3dOkcKCpTQHoF2EZteGydUGn0NPFwDFxdtGtDOPfM8A4
         bdNvURyNoRiPJdaMa3Wzc1NqUxdCeb+MXGLxrhKQIaxIkjn2wxFdU7HD1GCufNAM2sov
         Oj5l8isiXwC3nO7Dm3Pv/BDfFKPSyFMrHAfIvkJ24D0NIwi2DGqAbE6RJXN5YNCZ71hv
         iTVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710525989; x=1711130789;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=ti/NGZu80Gob+FUDMzaaMxrVNmtSZyxPSgcxSW8TGYY=;
        b=vuAHzaPXH1Ua+eC70HehzR6yYcjY2VWgF5DkyXyXhuk+9CpXtLFW+m0WLGY8b6Ogq/
         hmR35T/cBoPjYoiHxWUzl8Rc2G5KZrxaou00NasgbGyWK/mPFH6qlDjBPhqHSU7U94uQ
         4JzBz4H1kWzKm1/CiekExZWT7cTq+c7UdVIQbH5thwQ5JTcBCdxNDvAa35smu7hcYAlW
         fWaTZdX7P/TuMwdVue5pyExYkpGzbGiP+wG2Kw9JSIu37G6UdG3vk532qWWGjLyYUP6M
         GwAnI+seeo02J4gKFmMQ4LCEGoGoui15037mGS9vLdOkUiV9FMauUJRn6neFg9v7ZsXx
         GVjA==
X-Gm-Message-State: AOJu0YwEYDa/HvbDgKReOx3K53GphjxdpVQOiOSpKoH5PCXirGawSg1g
	B5KLmBKNOIqv83veVK7t+arUyNxiw9y6kWj2eAHQQzKKzmkut9v4+QJDoMdOBGY=
X-Google-Smtp-Source: AGHT+IF/Q5WWRUtov1Ash5MXosXNJ4R80T3CZiyJa9EhYCOflOTVmzB+NM1iRU/Noc+YnDxw2Ajs4A==
X-Received: by 2002:a05:651c:1039:b0:2d4:3e96:47ee with SMTP id w25-20020a05651c103900b002d43e9647eemr3262634ljm.26.1710525989052;
        Fri, 15 Mar 2024 11:06:29 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini ,
	Wei Liu 
Subject: [PATCH v6 08/20] xen/riscv: introduce cmpxchg.h
Date: Fri, 15 Mar 2024 19:06:04 +0100
Message-ID: 
X-Mailer: git-send-email 2.43.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The header was taken from Linux kernl 6.4.0-rc1.

Addionally, were updated:
* add emulation of {cmp}xchg for 1/2 byte types using 32-bit atomic
  access.
* replace tabs with spaces
* replace __* variale with *__
* introduce generic version of xchg_* and cmpxchg_*.
* drop {cmp}xchg{release,relaxed,acquire} as Xen doesn't use them
* drop barries and use instruction suffixices instead ( .aq, .rl, .aqrl )

Implementation of 4- and 8-byte cases were updated according to the spec:
```
              ....
Linux Construct         RVWMO AMO Mapping
atomic  relaxed     amo.{w|d}
atomic  acquire     amo.{w|d}.aq
atomic  release     amo.{w|d}.rl
atomic              amo.{w|d}.aqrl
Linux Construct         RVWMO LR/SC Mapping
atomic  relaxed     loop: lr.{w|d}; ; sc.{w|d}; bnez loop
atomic  acquire     loop: lr.{w|d}.aq; ; sc.{w|d}; bnez loop
atomic  release     loop: lr.{w|d}; ; sc.{w|d}.aqrl∗ ; bnez loop OR
                        fence.tso; loop: lr.{w|d}; ; sc.{w|d}∗ ; bnez loop
atomic              loop: lr.{w|d}.aq; ; sc.{w|d}.aqrl; bnez loop

Table A.5: Mappings from Linux memory primitives to RISC-V primitives

```

Signed-off-by: Oleksii Kurochko 
---
Changes in V6:
-  update the commit message? ( As before I don't understand this point. Can you give an example of what sort of opcode / instruction is missing?)
 - Code style fixes
 - change sizeof(*ptr) -> sizeof(*(ptr))
 - update operands names and some local variables for macros emulate_xchg_1_2() and emulate_cmpxchg_1_2()
 - drop {cmp}xchg_{relaxed,acquire,release) versions as they aren't needed for Xen
 - update __amoswap_generic() prototype and defintion: drop pre and post barries.
 - update emulate_xchg_1_2() prototype and definion: add lr_sfx, drop pre and post barries.
 - rename __xchg_generic to __xchg(), make __xchg as static inline function to be able to "#ifndef CONFIG_32BIT case 8:... " 
---
Changes in V5:
 - update the commit message.
 - drop ALIGN_DOWN().
 - update the definition of emulate_xchg_1_2(): 
   - lr.d -> lr.w, sc.d -> sc.w.
   - drop ret argument.
   - code style fixes around asm volatile.
   - update prototype.
   - use asm named operands.
   - rename local variables.
   - add comment above the macros
 - update the definition of __xchg_generic:
   - rename to __xchg()
   - transform it to static inline
   - code style fixes around switch()
   - update prototype.
 - redefine cmpxchg()
 - update emulate_cmpxchg_1_2():
   - update prototype
   - update local variables names and usage of them
   - use name asm operands.
   - add comment above the macros
 - drop pre and post, and use .aq,.rl, .aqrl suffixes.
 - drop {cmp}xchg_{relaxed, aquire, release} as they are not used by Xen.
 - drop unnessary details in comment above emulate_cmpxchg_1_2()
---
Changes in V4:
 - Code style fixes.
 - enforce in __xchg_*() has the same type for new and *ptr, also "\n"
   was removed at the end of asm instruction.
 - dependency from https://lore.kernel.org/xen-devel/cover.1706259490.git.federico.serafini@bugseng.com/
 - switch from ASSERT_UNREACHABLE to STATIC_ASSERT_UNREACHABLE().
 - drop xchg32(ptr, x) and xchg64(ptr, x) as they aren't used.
 - drop cmpxcg{32,64}_{local} as they aren't used.
 - introduce generic version of xchg_* and cmpxchg_*.
 - update the commit message.
---
Changes in V3:
 - update the commit message
 - add emulation of {cmp}xchg_... for 1 and 2 bytes types
---
Changes in V2:
 - update the comment at the top of the header.
 - change xen/lib.h to xen/bug.h.
 - sort inclusion of headers properly.
---
 xen/arch/riscv/include/asm/cmpxchg.h | 209 +++++++++++++++++++++++++++
 1 file changed, 209 insertions(+)
 create mode 100644 xen/arch/riscv/include/asm/cmpxchg.h

diff --git a/xen/arch/riscv/include/asm/cmpxchg.h b/xen/arch/riscv/include/asm/cmpxchg.h
new file mode 100644
index 0000000000..aba2858933
--- /dev/null
+++ b/xen/arch/riscv/include/asm/cmpxchg.h
@@ -0,0 +1,209 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/* Copyright (C) 2014 Regents of the University of California */
+
+#ifndef _ASM_RISCV_CMPXCHG_H
+#define _ASM_RISCV_CMPXCHG_H
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#define __amoswap_generic(ptr, new, ret, sfx) \
+({ \
+    asm volatile ( \
+        " amoswap" sfx " %0, %2, %1" \
+        : "=r" (ret), "+A" (*ptr) \
+        : "r" (new) \
+        : "memory" ); \
+})
+
+/*
+ * For LR and SC, the A extension requires that the address held in rs1 be
+ * naturally aligned to the size of the operand (i.e., eight-byte aligned
+ * for 64-bit words and four-byte aligned for 32-bit words).
+ * If the address is not naturally aligned, an address-misaligned exception
+ * or an access-fault exception will be generated.
+ *
+ * Thereby:
+ * - for 1-byte xchg access the containing word by clearing low two bits
+ * - for 2-byte xchg ccess the containing word by clearing bit 1.
+ *
+ * If resulting 4-byte access is still misalgined, it will fault just as
+ * non-emulated 4-byte access would.
+ */
+#define emulate_xchg_1_2(ptr, new, lr_sfx, sc_sfx) \
+({ \
+    uint32_t *aligned_ptr = (uint32_t *)((unsigned long)ptr & ~(0x4 - sizeof(*(ptr)))); \
+    unsigned int new_val_pos = ((unsigned long)(ptr) & (0x4 - sizeof(*(ptr)))) * BITS_PER_BYTE; \
+    unsigned long mask = GENMASK(((sizeof(*(ptr))) * BITS_PER_BYTE) - 1, 0) << new_val_pos; \
+    unsigned int new_ = new << new_val_pos; \
+    unsigned int old; \
+    unsigned int scratch; \
+    \
+    asm volatile ( \
+        "0: lr.w" lr_sfx " %[old], %[aligned_ptr]\n" \
+        "   and  %[scratch], %[old], %z[nmask]\n" \
+        "   or   %[scratch], %[scratch], %z[new_]\n" \
+        "   sc.w" sc_sfx " %[scratch], %[scratch], %[aligned_ptr]\n" \
+        "   bnez %[scratch], 0b\n" \
+        : [old] "=&r" (old), [scratch] "=&r" (scratch), [aligned_ptr] "+A" (*aligned_ptr) \
+        : [new_] "rJ" (new_), [nmask] "rJ" (~mask) \
+        : "memory" ); \
+    \
+    (__typeof__(*(ptr)))((old & mask) >> new_val_pos); \
+})
+
+static always_inline unsigned long __xchg(volatile void *ptr, unsigned long new, int size)
+{
+    unsigned long ret;
+
+    switch ( size )
+    {
+    case 1:
+        ret = emulate_xchg_1_2((volatile uint8_t *)ptr, new, ".aq", ".aqrl");
+        break;
+    case 2:
+        ret = emulate_xchg_1_2((volatile uint16_t *)ptr, new, ".aq", ".aqrl");
+        break;
+    case 4:
+        __amoswap_generic((volatile uint32_t *)ptr, new, ret, ".w.aqrl");
+        break;
+#ifndef CONFIG_32BIT
+    case 8:
+        __amoswap_generic((volatile uint64_t *)ptr, new, ret, ".d.aqrl");
+        break;
+#endif
+    default:
+        STATIC_ASSERT_UNREACHABLE();
+    }
+
+    return ret;
+}
+
+#define xchg(ptr, x) \
+({ \
+    __typeof__(*(ptr)) n_ = (x); \
+    (__typeof__(*(ptr))) \
+        __xchg((ptr), (unsigned long)(n_), sizeof(*(ptr))); \
+})
+
+#define __generic_cmpxchg(ptr, old, new, ret, lr_sfx, sc_sfx)	\
+ ({ \
+    register unsigned int rc; \
+    __typeof__(*(ptr)) old__ = (__typeof__(*(ptr)))(old); \
+    __typeof__(*(ptr)) new__ = (__typeof__(*(ptr)))(new); \
+    asm volatile( \
+        "0: lr" lr_sfx " %0, %2\n" \
+        "   bne  %0, %z3, 1f\n" \
+        "   sc" sc_sfx " %1, %z4, %2\n" \
+        "   bnez %1, 0b\n" \
+        "1:\n" \
+        : "=&r" (ret), "=&r" (rc), "+A" (*ptr) \
+        : "rJ" (old__), "rJ" (new__) \
+        : "memory"); \
+ })
+
+/*
+ * For LR and SC, the A extension requires that the address held in rs1 be
+ * naturally aligned to the size of the operand (i.e., eight-byte aligned
+ * for 64-bit words and four-byte aligned for 32-bit words).
+ * If the address is not naturally aligned, an address-misaligned exception
+ * or an access-fault exception will be generated.
+ *
+ * Thereby:
+ * - for 1-byte xchg access the containing word by clearing low two bits
+ * - for 2-byte xchg ccess the containing word by clearing first bit.
+ * 
+ * If resulting 4-byte access is still misalgined, it will fault just as
+ * non-emulated 4-byte access would.
+ *
+ * old_val was casted to unsigned long for cmpxchgptr()
+ */
+#define emulate_cmpxchg_1_2(ptr, old, new, lr_sfx, sc_sfx) \
+({ \
+    uint32_t *aligned_ptr = (uint32_t *)((unsigned long)ptr & ~(0x4 - sizeof(*(ptr)))); \
+    uint8_t new_val_pos = ((unsigned long)(ptr) & (0x4 - sizeof(*(ptr)))) * BITS_PER_BYTE; \
+    unsigned long mask = GENMASK(((sizeof(*(ptr))) * BITS_PER_BYTE) - 1, 0) << new_val_pos; \
+    unsigned int old_ = old << new_val_pos; \
+    unsigned int new_ = new << new_val_pos; \
+    unsigned int old_val; \
+    unsigned int scratch; \
+    \
+    __asm__ __volatile__ ( \
+        "0: lr.w" lr_sfx " %[scratch], %[aligned_ptr]\n" \
+        "   and  %[old_val], %[scratch], %z[mask]\n" \
+        "   bne  %[old_val], %z[old_], 1f\n" \
+        "   xor  %[scratch], %[old_val], %[scratch]\n" \
+        "   or   %[scratch], %[scratch], %z[new_]\n" \
+        "   sc.w" sc_sfx " %[scratch], %[scratch], %[aligned_ptr]\n" \
+        "   bnez %[scratch], 0b\n" \
+        "1:\n" \
+        : [old_val] "=&r" (old_val), [scratch] "=&r" (scratch), [aligned_ptr] "+A" (*aligned_ptr) \
+        : [old_] "rJ" (old_), [new_] "rJ" (new_), \
+          [mask] "rJ" (mask) \
+        : "memory" ); \
+    \
+    (__typeof__(*(ptr)))((unsigned long)old_val >> new_val_pos); \
+})
+
+/*
+ * Atomic compare and exchange.  Compare OLD with MEM, if identical,
+ * store NEW in MEM.  Return the initial value in MEM.  Success is
+ * indicated by comparing RETURN with OLD.
+ */
+static always_inline unsigned long __cmpxchg(volatile void *ptr,
+                         unsigned long old,
+                         unsigned long new,
+                         int size)
+{
+    unsigned long ret;
+
+    switch ( size )
+    {
+    case 1:
+        ret = emulate_cmpxchg_1_2((volatile uint8_t *)ptr, old, new,
+                                  ".aq", ".aqrl");
+        break;
+    case 2:
+        ret = emulate_cmpxchg_1_2((volatile uint16_t *)ptr, old, new,
+                                   ".aq", ".aqrl");
+        break;
+    case 4:
+        __generic_cmpxchg((volatile uint32_t *)ptr, old, new, ret,
+                          ".w.aq", ".w.aqrl");
+        break;
+#ifndef CONFIG_32BIT
+    case 8:
+        __generic_cmpxchg((volatile uint64_t *)ptr, old, new,
+                           ret, ".d.aq", ".d.aqrl");
+        break;
+#endif
+    default:
+        STATIC_ASSERT_UNREACHABLE();
+    }
+
+    return ret;
+}
+
+#define cmpxchg(ptr, o, n) \
+({ \
+    __typeof__(*(ptr)) o_ = (o); \
+    __typeof__(*(ptr)) n_ = (n); \
+    (__typeof__(*(ptr))) \
+    __cmpxchg((ptr), (unsigned long)(o_), (unsigned long)(n_), \
+              sizeof(*(ptr))); \
+})
+
+#endif /* _ASM_RISCV_CMPXCHG_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Mar 15 18:06:33 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 18:06:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693995.1082772 (Exim 4.92)
	(envelope-from )
	id 1rlBwv-0008Cm-Cp; Fri, 15 Mar 2024 18:06:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693995.1082772; Fri, 15 Mar 2024 18:06:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rlBwv-0008CH-6e; Fri, 15 Mar 2024 18:06:33 +0000
Received: by outflank-mailman (input) for mailman id 693995;
 Fri, 15 Mar 2024 18:06:32 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rlBwt-0005yW-So
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 18:06:31 +0000
Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com
 [2a00:1450:4864:20::230])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c04e270b-e2f6-11ee-afdd-a90da7624cb6;
 Fri, 15 Mar 2024 19:06:31 +0100 (CET)
Received: by mail-lj1-x230.google.com with SMTP id
 38308e7fff4ca-2d4515ec3aaso20751931fa.1
 for ; Fri, 15 Mar 2024 11:06:31 -0700 (PDT)
Received: from fedora.. ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id
 g29-20020a05651c079d00b002d0acb57c89sm568939lje.64.2024.03.15.11.06.29
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 15 Mar 2024 11:06:29 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c04e270b-e2f6-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1710525990; x=1711130790; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=R1pPG7wBEk5xnYRPInM0oJeLCyj54iS75LgxSjQvpZk=;
        b=Stvo39G3Y51Mnu84J5qztv7uNEfYOJS3EZWkUBqzdsxR/xK83l7jgDKl6yW9bjKRlb
         nnRSin/S8mD7ygG30NnZzVVCKXm/Qmj2NhYQbJMkHsco5Ik7Lethi3aUX0Q84zpmqE8N
         /bgikPMEuMfmr8U3M0JUYVu9UWQ3fUPAwOr5tDQtR8aSrg0yq3k73y646qM4gUA7FBkZ
         l7QJFhFdfxCd2hdTgXbGhaKvkSLfEvXEJvybgNy9ezazcGDgIfKbds69lKIVVZZN1l96
         nIedV4Kwujri52AKUuUBHHl7wQPrNMmFPs0fQInWbpTTWjIg7p7wG63s7oLW5dfDpoTb
         D51A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710525990; x=1711130790;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=R1pPG7wBEk5xnYRPInM0oJeLCyj54iS75LgxSjQvpZk=;
        b=Rf3uLmoqMv9VRHi01xtQqydN0rLw0/l2zJlCl8psSVASbuem4WCkyEwZkKWuU8Szhn
         pcyZSCeGPNleOEni88i0nyHYvcnyNLxon18A/jzzbVfOYlxJf3XRiZf+V0wZihBaJeKU
         MUGaNeYmWkw+nQZZ5oFw7lMJJ9I9laVuDcZrH/aBIAtrDpvFrIlEH9+RONlgMqMQbFEL
         Pl1YIGpZV9E/LInWHsRX89e/UaL+6jOLhjFs9vSujWh9UQgQsozRFGVAwrrz0fRF8NeF
         7ZNn50h1o7NsYKtkxPItxr3WhomJi37jOphYmklNH0P9CKuqux1JBXzPLRLjrAeFzieo
         A2+g==
X-Gm-Message-State: AOJu0Ywr3FTZWp7XBOrogPfFhB6FOlo2aRO1e2dK7s1He5Lz3ZVPJw4f
	pM1I/eXhvNvfDJBw7HlBDsYsRfP7RtaLGzWeyfif+E3jHn2nDQGxDIxfEtVZdNc=
X-Google-Smtp-Source: AGHT+IE+caOtR0warXJa+P68PN1HGZpudSfVVM+FB1k34qtRoWTmtVf74V9WS6+OdU8ZUhAoWZ8/Zw==
X-Received: by 2002:a05:651c:2d0:b0:2d4:8ff8:6435 with SMTP id f16-20020a05651c02d000b002d48ff86435mr432459ljo.19.1710525989982;
        Fri, 15 Mar 2024 11:06:29 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini ,
	Wei Liu 
Subject: [PATCH v6 09/20] xen/riscv: introduce io.h
Date: Fri, 15 Mar 2024 19:06:05 +0100
Message-ID: 
X-Mailer: git-send-email 2.43.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

The header taken form Linux 6.4.0-rc1 and is based on
arch/riscv/include/asm/mmio.h with the following changes:
- drop forcing of endianess for read*(), write*() functions as
  no matter what CPU endianness, what endianness a particular device
  (and hence its MMIO region(s)) is using is entirely independent.
  Hence conversion, where necessary, needs to occur at a layer up.
  Another one reason to drop endianess conversion here is:
  https://patchwork.kernel.org/project/linux-riscv/patch/20190411115623.5749-3-hch@lst.de/
  One of the answers of the author of the commit:
    And we don't know if Linux will be around if that ever changes.
    The point is:
     a) the current RISC-V spec is LE only
     b) the current linux port is LE only except for this little bit
    There is no point in leaving just this bitrotting code around.  It
    just confuses developers, (very very slightly) slows down compiles
    and will bitrot.  It also won't be any significant help to a future
    developer down the road doing a hypothetical BE RISC-V Linux port.
- drop unused argument of __io_ar() macros.
- drop "#define _raw_{read,write}{b,w,l,d,q} _raw_{read,write}{b,w,l,d,q}"
  as they are unnecessary.
- Adopt the Xen code style for this header, considering that significant changes
  are not anticipated in the future.
  In the event of any issues, adapting them to Xen style should be easily
  manageable.
- drop unnecessary  __r variables in macros read*_cpu()
- update inline assembler constraints for addr argument for
  __raw_read{b,w,l,q} and __raw_write{b,w,l,q} to tell a compiler that
 *addr will be accessed.
- add stubs for __raw_readq() and __raw_writeq() for RISCV_32

Addionally, to the header was added definions of ioremap_*().

Signed-off-by: Oleksii Kurochko 
---
Changes in V6:
 - drop unnecessary spaces and fix typos in the file comment.
 - s/CONFIG_64BIT/CONFIG_RISCV_32 as .d suffix for instruction doesn't exist for RV32.
 - add stubs for __raw_readq() and __raw_writeq() for RISCV_32
 - update inline assembler constraints for addr argument for __raw_read{b,w,l,q} and
   __raw_write{b,w,l,q} to tell compiler that *addr will be accessed.
 - s/u8/uint8_t
 - update the commit message
---
Changes in V5:
 - Xen code style related fixes
 - drop #define _raw_{read,write}{b,w,l,d,q} _raw_{read,write}{b,w,l,d,q}
 - drop cpu_to_le16()
 - remove unuused argument in _io_ar()
 - update the commit message 
 - drop unnessary __r variables in macros read*_cpu()
 - update the comments at the top of the header.
---
Changes in V4:
 - delete inner parentheses in macros.
 - s/u/uint.
---
Changes in V3:
 - re-sync with linux kernel
 - update the commit message
---
Changes in V2:
 - Nothing changed. Only rebase.
---
 xen/arch/riscv/include/asm/io.h | 167 ++++++++++++++++++++++++++++++++
 1 file changed, 167 insertions(+)
 create mode 100644 xen/arch/riscv/include/asm/io.h

diff --git a/xen/arch/riscv/include/asm/io.h b/xen/arch/riscv/include/asm/io.h
new file mode 100644
index 0000000000..4eb4cd4b49
--- /dev/null
+++ b/xen/arch/riscv/include/asm/io.h
@@ -0,0 +1,167 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ *  The header taken form Linux 6.4.0-rc1 and is based on
+ *  arch/riscv/include/asm/mmio.h with the following changes:
+ *   - drop forcing of endianess for read*(), write*() functions as
+ *     no matter what CPU endianness, what endianness a particular device
+ *     (and hence its MMIO region(s)) is using is entirely independent.
+ *     Hence conversion, where necessary, needs to occur at a layer up.
+ *     Another one reason to drop endianess conversion is:
+ *     https://patchwork.kernel.org/project/linux-riscv/patch/20190411115623.5749-3-hch@lst.de/
+ *     One of the answers of the author of the commit:
+ *       And we don't know if Linux will be around if that ever changes.
+ *       The point is:
+ *        a) the current RISC-V spec is LE only
+ *        b) the current linux port is LE only except for this little bit
+ *       There is no point in leaving just this bitrotting code around.  It
+ *       just confuses developers, (very very slightly) slows down compiles
+ *      and will bitrot.  It also won't be any significant help to a future
+ *       developer down the road doing a hypothetical BE RISC-V Linux port.
+ *   - drop unused argument of __io_ar() macros.
+ *   - drop "#define _raw_{read,write}{b,w,l,d,q} _raw_{read,write}{b,w,l,d,q}"
+ *     as they are unnecessary.
+ *   - Adopt the Xen code style for this header, considering that significant
+ *     changes are not anticipated in the future.
+ *     In the event of any issues, adapting them to Xen style should be easily
+ *     manageable.
+ *   - drop unnecessary __r variables in macros read*_cpu()
+ *   - update inline assembler constraints for addr argument for
+ *     __raw_read{b,w,l,q} and __raw_write{b,w,l,q} to tell a compiler that
+ *     *addr will be accessed.
+ *
+ * Copyright (C) 1996-2000 Russell King
+ * Copyright (C) 2012 ARM Ltd.
+ * Copyright (C) 2014 Regents of the University of California
+ * Copyright (C) 2024 Vates
+ */
+
+#ifndef _ASM_RISCV_IO_H
+#define _ASM_RISCV_IO_H
+
+#include 
+
+/*
+ * The RISC-V ISA doesn't yet specify how to query or modify PMAs, so we can't
+ * change the properties of memory regions.  This should be fixed by the
+ * upcoming platform spec.
+ */
+#define ioremap_nocache(addr, size) ioremap(addr, size)
+#define ioremap_wc(addr, size) ioremap(addr, size)
+#define ioremap_wt(addr, size) ioremap(addr, size)
+
+/* Generic IO read/write.  These perform native-endian accesses. */
+static inline void __raw_writeb(uint8_t val, volatile void __iomem *addr)
+{
+    asm volatile ( "sb %1, %0" : "=m" (*(volatile uint8_t __force *)addr) : "r" (val) );
+}
+
+static inline void __raw_writew(uint16_t val, volatile void __iomem *addr)
+{
+    asm volatile ( "sh %1, %0" : "=m" (*(volatile uint16_t __force *)addr) : "r" (val) );
+}
+
+static inline void __raw_writel(uint32_t val, volatile void __iomem *addr)
+{
+    asm volatile ( "sw %1, %0" : "=m" (*(volatile uint32_t __force *)addr) : "r" (val) );
+}
+
+#ifdef CONFIG_RISCV_32
+static inline void __raw_writeq(uint64_t val, volatile void __iomem *addr)
+{
+    BUILD_BUG_ON("unimplemented\n");
+}
+#else
+static inline void __raw_writeq(uint64_t val, volatile void __iomem *addr)
+{
+    asm volatile ( "sd %1, %0" : "=m" (*(volatile uint64_t __force *)addr) : "r" (val) );
+}
+#endif
+
+static inline uint8_t __raw_readb(const volatile void __iomem *addr)
+{
+    uint8_t val;
+
+    asm volatile ( "lb %0, %1" : "=r" (val) : "m" (*(volatile uint8_t __force *)addr) );
+    return val;
+}
+
+static inline uint16_t __raw_readw(const volatile void __iomem *addr)
+{
+    uint16_t val;
+
+    asm volatile ( "lh %0, %1" : "=r" (val) : "m" (*(volatile uint16_t __force *)addr) );
+    return val;
+}
+
+static inline uint32_t __raw_readl(const volatile void __iomem *addr)
+{
+    uint32_t val;
+
+    asm volatile ( "lw %0, %1" : "=r" (val) : "m" (*(volatile uint32_t __force *)addr) );
+    return val;
+}
+
+#ifdef CONFIG_RISCV_32
+static inline uint64_t __raw_readq(const volatile void __iomem *addr)
+{
+    BUILD_BUG_ON("unimplemented\n");
+    return 0;
+}
+#else
+static inline uint64_t __raw_readq(const volatile void __iomem *addr)
+{
+    uint64_t val;
+
+    asm volatile ( "ld %0, %1" : "=r" (val) : "m" (*(volatile uint64_t __force *)addr) );
+    return val;
+}
+#endif
+
+/*
+ * Unordered I/O memory access primitives.  These are even more relaxed than
+ * the relaxed versions, as they don't even order accesses between successive
+ * operations to the I/O regions.
+ */
+#define readb_cpu(c)        __raw_readb(c)
+#define readw_cpu(c)        __raw_readw(c)
+#define readl_cpu(c)        __raw_readl(c)
+
+#define writeb_cpu(v, c)    __raw_writeb(v, c)
+#define writew_cpu(v, c)    __raw_writew(v, c)
+#define writel_cpu(v, c)    __raw_writel(v, c)
+
+#define readq_cpu(c)        __raw_readq(c)
+#define writeq_cpu(v, c)    __raw_writeq(v, c)
+
+/*
+ * I/O memory access primitives. Reads are ordered relative to any
+ * following Normal memory access. Writes are ordered relative to any prior
+ * Normal memory access.  The memory barriers here are necessary as RISC-V
+ * doesn't define any ordering between the memory space and the I/O space.
+ */
+#define __io_br()   do { } while (0)
+#define __io_ar()   asm volatile ( "fence i,r" : : : "memory" );
+#define __io_bw()   asm volatile ( "fence w,o" : : : "memory" );
+#define __io_aw()   do { } while (0)
+
+#define readb(c)    ({ uint8_t  v; __io_br(); v = readb_cpu(c); __io_ar(); v; })
+#define readw(c)    ({ uint16_t v; __io_br(); v = readw_cpu(c); __io_ar(); v; })
+#define readl(c)    ({ uint32_t v; __io_br(); v = readl_cpu(c); __io_ar(); v; })
+
+#define writeb(v, c)    ({ __io_bw(); writeb_cpu(v, c); __io_aw(); })
+#define writew(v, c)    ({ __io_bw(); writew_cpu(v, c); __io_aw(); })
+#define writel(v, c)    ({ __io_bw(); writel_cpu(v, c); __io_aw(); })
+
+#define readq(c)        ({ uint64_t v; __io_br(); v = readq_cpu(c); __io_ar(); v; })
+#define writeq(v, c)    ({ __io_bw(); writeq_cpu(v, c); __io_aw(); })
+
+#endif /* _ASM_RISCV_IO_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Mar 15 18:06:35 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 18:06:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693996.1082782 (Exim 4.92)
	(envelope-from )
	id 1rlBwx-0000Av-4D; Fri, 15 Mar 2024 18:06:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693996.1082782; Fri, 15 Mar 2024 18:06:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rlBww-00009g-V5; Fri, 15 Mar 2024 18:06:34 +0000
Received: by outflank-mailman (input) for mailman id 693996;
 Fri, 15 Mar 2024 18:06:33 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rlBwv-0005yW-If
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 18:06:33 +0000
Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com
 [2a00:1450:4864:20::22b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c14c5ec1-e2f6-11ee-afdd-a90da7624cb6;
 Fri, 15 Mar 2024 19:06:32 +0100 (CET)
Received: by mail-lj1-x22b.google.com with SMTP id
 38308e7fff4ca-2d46dd8b0b8so29374971fa.2
 for ; Fri, 15 Mar 2024 11:06:32 -0700 (PDT)
Received: from fedora.. ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id
 g29-20020a05651c079d00b002d0acb57c89sm568939lje.64.2024.03.15.11.06.30
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 15 Mar 2024 11:06:30 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c14c5ec1-e2f6-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1710525992; x=1711130792; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=ZE7a6DyG7HrhqHnuqKEHobFd4GYM12z6GA2D6v4ifc8=;
        b=Z2MoWYUGQALcPcJ97VuZRud3jX//YKjSkrE1hW5fdGhhPoiWJ7f4UFgWfyM5cU9WFu
         t7jC4XLJHpAd0pnXzpSkW8dbL/t9Dd1sitVZP6+cX9fkRAgsEz9Tim1+WApdawkGvpAh
         r0wGIg315VP7JMsuOkOVOw/zztR2EtjInnLZK3n1DYgvFWD5Ih4xEHjlaU5cBftuK7OL
         ES3B+ri5/nprEMS2BiNb0SCyTxmcZ1E4eVn7cl16gNMjOboek78KbD3UACHW0/TRiBo6
         xlPGs2jvJfc5b3qNjyvCPu5BaD1Nw3uLLVe8T3KUTTga/UtDR1zASh9hB/sX4Tu5ZtH7
         W7TQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710525992; x=1711130792;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=ZE7a6DyG7HrhqHnuqKEHobFd4GYM12z6GA2D6v4ifc8=;
        b=vf3ckjIMMfcNoEuUCg/io+toSiH4Jr+qR+7vJu7RY4h9AyZGouCVu3Z6me0emmgIDP
         +F/TqTSGGgJ5NbVBHOERWBzYqTaTvbi0FidAHzpZezInnuOzQIvz2B8wScB1JWUq57a7
         ZS7GEsGLDgLEJZfqXPtlpVnyGODNgUVkPW/AyFqJABuDhQtNdx7OrWQ02T3VDCwrligt
         mVeptWVue2oaPald7xqEVUG0p8dzgYF2bSZ50TzyyelagQSsAyerrNvjqqIsEKyESEhd
         C7/Nr2i8MuYpt05/rUZOd9iBVJ5GuU3FIMqT/dk0SzM3C5pkcMzSOT5f2Wfa6jREegy0
         DeNQ==
X-Gm-Message-State: AOJu0YxS2JYA7jhxr8H28Cz2w6je4i2R/Jq1WBP1fiXNIErEK03cX3eI
	RE1nj00kt+GT4LYAkkVqqn3gBUkIhmGKqR/EWq0wp8nNcHMG8KkmloLw/PN4X1s=
X-Google-Smtp-Source: AGHT+IHF2NwE4bkCdY2LkNbwj8ABqLCgMklVcNZTsMrupm3XEVgoRJVYDZhCGwW9fW/R1tUp4e6JMA==
X-Received: by 2002:a2e:9cc9:0:b0:2d4:54dc:28e3 with SMTP id g9-20020a2e9cc9000000b002d454dc28e3mr4139965ljj.28.1710525991336;
        Fri, 15 Mar 2024 11:06:31 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini ,
	Wei Liu 
Subject: [PATCH v6 10/20] xen/riscv: introduce atomic.h
Date: Fri, 15 Mar 2024 19:06:06 +0100
Message-ID: <22ee9c8cc62c76cfb799fed800636e7c8bf25a17.1710517542.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Initially the patch was introduced by Bobby, who takes the header from
Linux kernel.

The following changes were done on top of Linux kernel header:
 - atomic##prefix##_*xchg_*(atomic##prefix##_t *v, c_t n) were updated
     to use__*xchg_generic()
 - drop casts in write_atomic() as they are unnecessary
 - drop introduction of WRITE_ONCE() and READ_ONCE().
   Xen provides ACCESS_ONCE()
 - remove zero-length array access in read_atomic()
 - drop defines similar to pattern
 - #define atomic_add_return_relaxed   atomic_add_return_relaxed
 - move not RISC-V specific functions to asm-generic/atomics-ops.h
 - drop  atomic##prefix##_{cmp}xchg_{release, aquire, release}() as they
   are not used in Xen.
 - update the defintion of  atomic##prefix##_{cmp}xchg according to
   {cmp}xchg() implementation in Xen.

Signed-off-by: Bobby Eshleman 
Signed-off-by: Oleksii Kurochko 
---
Changes in V6:
 - drop atomic##prefix##_{cmp}xchg_{release, aquire, relaxed} as they aren't used
   by Xen
 - code style fixes.
 - %s/__asm__ __volatile__/asm volatile
 - add explanational comments.
 - move inclusion of "#include " further down in atomic.h
   header.
---
Changes in V5:
 - fence.h changes were moved to separate patch as patches related to io.h and cmpxchg.h,
   which are dependecies for this patch, also needed changes in fence.h
 - remove accessing of zero-length array
 - drops cast in write_atomic()
 - drop introduction of WRITE_ONCE() and READ_ONCE().
 - drop defines similar to pattern #define atomic_add_return_relaxed   atomic_add_return_relaxed
 - Xen code style fixes
 - move not RISC-V specific functions to asm-generic/atomics-ops.h
---
Changes in V4:
 - do changes related to the updates of [PATCH v3 13/34] xen/riscv: introduce cmpxchg.h
 - drop casts in read_atomic_size(), write_atomic(), add_sized()
 - tabs -> spaces
 - drop #ifdef CONFIG_SMP ... #endif in fence.ha as it is simpler to handle NR_CPUS=1
   the same as NR_CPUS>1 with accepting less than ideal performance.
---
Changes in V3:
  - update the commit message
  - add SPDX for fence.h
  - code style fixes
  - Remove /* TODO: ... */ for add_sized macros. It looks correct to me.
  - re-order the patch
  - merge to this patch fence.h
---
Changes in V2:
 - Change an author of commit. I got this header from Bobby's old repo.
---
 xen/arch/riscv/include/asm/atomic.h  | 263 +++++++++++++++++++++++++++
 xen/include/asm-generic/atomic-ops.h |  97 ++++++++++
 2 files changed, 360 insertions(+)
 create mode 100644 xen/arch/riscv/include/asm/atomic.h
 create mode 100644 xen/include/asm-generic/atomic-ops.h

diff --git a/xen/arch/riscv/include/asm/atomic.h b/xen/arch/riscv/include/asm/atomic.h
new file mode 100644
index 0000000000..4964821f3a
--- /dev/null
+++ b/xen/arch/riscv/include/asm/atomic.h
@@ -0,0 +1,263 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Taken and modified from Linux.
+ *
+ * The following changes were done:
+ * - * atomic##prefix##_*xchg_*(atomic##prefix##_t *v, c_t n) were updated
+ *     to use__*xchg_generic()
+ * - drop casts in write_atomic() as they are unnecessary
+ * - drop introduction of WRITE_ONCE() and READ_ONCE().
+ *   Xen provides ACCESS_ONCE()
+ * - remove zero-length array access in read_atomic()
+ * - drop defines similar to pattern
+ *   #define atomic_add_return_relaxed   atomic_add_return_relaxed
+ * - move not RISC-V specific functions to asm-generic/atomics-ops.h
+ * 
+ * Copyright (C) 2007 Red Hat, Inc. All Rights Reserved.
+ * Copyright (C) 2012 Regents of the University of California
+ * Copyright (C) 2017 SiFive
+ * Copyright (C) 2024 Vates SAS
+ */
+
+#ifndef _ASM_RISCV_ATOMIC_H
+#define _ASM_RISCV_ATOMIC_H
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+void __bad_atomic_size(void);
+
+/*
+ * Legacy from Linux kernel. For some reason they wanted to have ordered
+ * read/write access. Thereby read* is used instead of read_cpu()
+ */
+static always_inline void read_atomic_size(const volatile void *p,
+                                           void *res,
+                                           unsigned int size)
+{
+    switch ( size )
+    {
+    case 1: *(uint8_t *)res = readb(p); break;
+    case 2: *(uint16_t *)res = readw(p); break;
+    case 4: *(uint32_t *)res = readl(p); break;
+    case 8: *(uint32_t *)res  = readq(p); break;
+    default: __bad_atomic_size(); break;
+    }
+}
+
+#define read_atomic(p) ({                                   \
+    union { typeof(*(p)) val; char c[sizeof(*(p))]; } x_;   \
+    read_atomic_size(p, x_.c, sizeof(*(p)));                \
+    x_.val;                                                 \
+})
+
+#define write_atomic(p, x)                              \
+({                                                      \
+    typeof(*(p)) x__ = (x);                             \
+    switch ( sizeof(*(p)) )                             \
+    {                                                   \
+    case 1: writeb(x__, p); break;                      \
+    case 2: writew(x__, p); break;                      \
+    case 4: writel(x__, p); break;                      \
+    case 8: writeq(x__, p); break;                      \
+    default: __bad_atomic_size(); break;                \
+    }                                                   \
+    x__;                                                \
+})
+
+#define add_sized(p, x)                                 \
+({                                                      \
+    typeof(*(p)) x__ = (x);                             \
+    switch ( sizeof(*(p)) )                             \
+    {                                                   \
+    case 1: writeb(read_atomic(p) + x__, p); break;     \
+    case 2: writew(read_atomic(p) + x__, p); break;     \
+    case 4: writel(read_atomic(p) + x__, p); break;     \
+    case 8: writeq(read_atomic(p) + x__, p); break;     \
+    default: __bad_atomic_size(); break;                \
+    }                                                   \
+})
+
+#define __atomic_acquire_fence() \
+    asm volatile ( RISCV_ACQUIRE_BARRIER "" ::: "memory" )
+
+#define __atomic_release_fence() \
+    asm volatile ( RISCV_RELEASE_BARRIER "" ::: "memory" )
+
+/*
+ * First, the atomic ops that have no ordering constraints and therefor don't
+ * have the AQ or RL bits set.  These don't return anything, so there's only
+ * one version to worry about.
+ */
+#define ATOMIC_OP(op, asm_op, I, asm_type, c_type, prefix)  \
+static inline                                               \
+void atomic##prefix##_##op(c_type i, atomic##prefix##_t *v) \
+{                                                           \
+    asm volatile (                                          \
+        "   amo" #asm_op "." #asm_type " zero, %1, %0"      \
+        : "+A" (v->counter)                                 \
+        : "r" (I)                                           \
+        : "memory" );                                       \
+}                                                           \
+
+/*
+ * Only CONFIG_GENERIC_ATOMIC64=y was ported to Xen that is the reason why
+ * last argument for ATOMIC_OP isn't used.
+ */
+#define ATOMIC_OPS(op, asm_op, I)                           \
+        ATOMIC_OP (op, asm_op, I, w, int,   )
+
+ATOMIC_OPS(add, add,  i)
+ATOMIC_OPS(sub, add, -i)
+ATOMIC_OPS(and, and,  i)
+ATOMIC_OPS( or,  or,  i)
+ATOMIC_OPS(xor, xor,  i)
+
+#undef ATOMIC_OP
+#undef ATOMIC_OPS
+
+#include 
+
+/*
+ * Atomic ops that have ordered, relaxed, acquire, and release variants.
+ * There's two flavors of these: the arithmatic ops have both fetch and return
+ * versions, while the logical ops only have fetch versions.
+ */
+#define ATOMIC_FETCH_OP(op, asm_op, I, asm_type, c_type, prefix)    \
+static inline                                                       \
+c_type atomic##prefix##_fetch_##op##_relaxed(c_type i,              \
+                         atomic##prefix##_t *v)                     \
+{                                                                   \
+    register c_type ret;                                            \
+    asm volatile (                                                  \
+        "   amo" #asm_op "." #asm_type " %1, %2, %0"                \
+        : "+A" (v->counter), "=r" (ret)                             \
+        : "r" (I)                                                   \
+        : "memory" );                                               \
+    return ret;                                                     \
+}                                                                   \
+static inline                                                       \
+c_type atomic##prefix##_fetch_##op(c_type i, atomic##prefix##_t *v) \
+{                                                                   \
+    register c_type ret;                                            \
+    asm volatile (                                                  \
+        "   amo" #asm_op "." #asm_type ".aqrl  %1, %2, %0"          \
+        : "+A" (v->counter), "=r" (ret)                             \
+        : "r" (I)                                                   \
+        : "memory" );                                               \
+    return ret;                                                     \
+}
+
+#define ATOMIC_OP_RETURN(op, asm_op, c_op, I, asm_type, c_type, prefix) \
+static inline                                                           \
+c_type atomic##prefix##_##op##_return_relaxed(c_type i,                 \
+                          atomic##prefix##_t *v)                        \
+{                                                                       \
+        return atomic##prefix##_fetch_##op##_relaxed(i, v) c_op I;      \
+}                                                                       \
+static inline                                                           \
+c_type atomic##prefix##_##op##_return(c_type i, atomic##prefix##_t *v)  \
+{                                                                       \
+        return atomic##prefix##_fetch_##op(i, v) c_op I;                \
+}
+
+/*
+ * Only CONFIG_GENERIC_ATOMIC64=y was ported to Xen that is the reason why
+ * last argument of ATOMIC_FETCH_OP, ATOMIC_OP_RETURN isn't used.
+ */
+#define ATOMIC_OPS(op, asm_op, c_op, I)                                 \
+        ATOMIC_FETCH_OP( op, asm_op,       I, w, int,   )               \
+        ATOMIC_OP_RETURN(op, asm_op, c_op, I, w, int,   )
+
+ATOMIC_OPS(add, add, +,  i)
+ATOMIC_OPS(sub, add, +, -i)
+
+#undef ATOMIC_OPS
+
+#define ATOMIC_OPS(op, asm_op, I) \
+        ATOMIC_FETCH_OP(op, asm_op, I, w, int,   )
+
+ATOMIC_OPS(and, and, i)
+ATOMIC_OPS( or,  or, i)
+ATOMIC_OPS(xor, xor, i)
+
+#undef ATOMIC_OPS
+
+#undef ATOMIC_FETCH_OP
+#undef ATOMIC_OP_RETURN
+
+/* This is required to provide a full barrier on success. */
+static inline int atomic_add_unless(atomic_t *v, int a, int u)
+{
+       int prev, rc;
+
+    asm volatile (
+        "0: lr.w     %[p],  %[c]\n"
+        "   beq      %[p],  %[u], 1f\n"
+        "   add      %[rc], %[p], %[a]\n"
+        "   sc.w.rl  %[rc], %[rc], %[c]\n"
+        "   bnez     %[rc], 0b\n"
+        RISCV_FULL_BARRIER
+        "1:\n"
+        : [p] "=&r" (prev), [rc] "=&r" (rc), [c] "+A" (v->counter)
+        : [a] "r" (a), [u] "r" (u)
+        : "memory");
+    return prev;
+}
+
+/*
+ * atomic_{cmp,}xchg is required to have exactly the same ordering semantics as
+ * {cmp,}xchg and the operations that return.
+ */
+#define ATOMIC_OP(c_t, prefix, size)                            \
+static inline                                                   \
+c_t atomic##prefix##_xchg(atomic##prefix##_t *v, c_t n)         \
+{                                                               \
+    return __xchg(&(v->counter), n, size);                      \
+}                                                               \
+static inline                                                   \
+c_t atomic##prefix##_cmpxchg(atomic##prefix##_t *v, c_t o, c_t n) \
+{                                                               \
+    return __cmpxchg(&v->counter, o, n, size);                  \
+}
+
+#define ATOMIC_OPS() \
+    ATOMIC_OP(int,   , 4)
+
+ATOMIC_OPS()
+
+#undef ATOMIC_OPS
+#undef ATOMIC_OP
+
+static inline int atomic_sub_if_positive(atomic_t *v, int offset)
+{
+       int prev, rc;
+
+    asm volatile (
+        "0: lr.w     %[p],  %[c]\n"
+        "   sub      %[rc], %[p], %[o]\n"
+        "   bltz     %[rc], 1f\n"
+        "   sc.w.rl  %[rc], %[rc], %[c]\n"
+        "   bnez     %[rc], 0b\n"
+        "   fence    rw, rw\n"
+        "1:\n"
+        : [p] "=&r" (prev), [rc] "=&r" (rc), [c] "+A" (v->counter)
+        : [o] "r" (offset)
+        : "memory" );
+    return prev - offset;
+}
+
+#endif /* _ASM_RISCV_ATOMIC_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-generic/atomic-ops.h b/xen/include/asm-generic/atomic-ops.h
new file mode 100644
index 0000000000..da1ea5aac2
--- /dev/null
+++ b/xen/include/asm-generic/atomic-ops.h
@@ -0,0 +1,97 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * The header provides default implementations for every xen/atomic.h-provided
+ * forward inline declaration that can be synthesized from other atomic
+ * functions.
+ */
+#ifndef _ASM_GENERIC_ATOMIC_OPS_H_
+#define _ASM_GENERIC_ATOMIC_OPS_H_
+
+#include 
+#include 
+
+#ifndef ATOMIC_READ
+static inline int atomic_read(const atomic_t *v)
+{
+    return ACCESS_ONCE(v->counter);
+}
+#endif
+
+#ifndef _ATOMIC_READ
+static inline int _atomic_read(atomic_t v)
+{
+    return v.counter;
+}
+#endif
+
+#ifndef ATOMIC_SET
+static inline void atomic_set(atomic_t *v, int i)
+{
+    ACCESS_ONCE(v->counter) = i;
+}
+#endif
+
+#ifndef _ATOMIC_SET
+static inline void _atomic_set(atomic_t *v, int i)
+{
+    v->counter = i;
+}
+#endif
+
+#ifndef ATOMIC_SUB_AND_TEST
+static inline int atomic_sub_and_test(int i, atomic_t *v)
+{
+    return atomic_sub_return(i, v) == 0;
+}
+#endif
+
+#ifndef ATOMIC_INC
+static inline void atomic_inc(atomic_t *v)
+{
+    atomic_add(1, v);
+}
+#endif
+
+#ifndef ATOMIC_INC_RETURN
+static inline int atomic_inc_return(atomic_t *v)
+{
+    return atomic_add_return(1, v);
+}
+#endif
+
+#ifndef ATOMIC_DEC
+static inline void atomic_dec(atomic_t *v)
+{
+    atomic_sub(1, v);
+}
+#endif
+
+#ifndef ATOMIC_DEC_RETURN
+static inline int atomic_dec_return(atomic_t *v)
+{
+    return atomic_sub_return(1, v);
+}
+#endif
+
+#ifndef ATOMIC_DEC_AND_TEST
+static inline int atomic_dec_and_test(atomic_t *v)
+{
+    return atomic_sub_return(1, v) == 0;
+}
+#endif
+
+#ifndef ATOMIC_ADD_NEGATIVE
+static inline int atomic_add_negative(int i, atomic_t *v)
+{
+    return atomic_add_return(i, v) < 0;
+}
+#endif
+
+#ifndef ATOMIC_INC_AND_TEST
+static inline int atomic_inc_and_test(atomic_t *v)
+{
+    return atomic_add_return(1, v) == 0;
+}
+#endif
+
+#endif /* _ASM_GENERIC_ATOMIC_OPS_H_ */
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Mar 15 18:06:36 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 18:06:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693997.1082791 (Exim 4.92)
	(envelope-from )
	id 1rlBwy-0000WQ-L4; Fri, 15 Mar 2024 18:06:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693997.1082791; Fri, 15 Mar 2024 18:06:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rlBwy-0000VV-Gk; Fri, 15 Mar 2024 18:06:36 +0000
Received: by outflank-mailman (input) for mailman id 693997;
 Fri, 15 Mar 2024 18:06:34 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rlBww-0005yW-Q0
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 18:06:34 +0000
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com
 [2a00:1450:4864:20::232])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c239e088-e2f6-11ee-afdd-a90da7624cb6;
 Fri, 15 Mar 2024 19:06:34 +0100 (CET)
Received: by mail-lj1-x232.google.com with SMTP id
 38308e7fff4ca-2d2509c66daso33951371fa.3
 for ; Fri, 15 Mar 2024 11:06:34 -0700 (PDT)
Received: from fedora.. ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id
 g29-20020a05651c079d00b002d0acb57c89sm568939lje.64.2024.03.15.11.06.32
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 15 Mar 2024 11:06:32 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c239e088-e2f6-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1710525994; x=1711130794; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=R0ZJ8zwoyTFUoE2+lGEttRsQ4y0+B4y5V6UHVOCeBNM=;
        b=DhgWlfJiAVi5S5LTFIEFEnWfufJdnAkQaOGZzNqTLfaGBQ+5LWDOeFRmyp07W+gW+l
         qmm+aVI+zkFnWRqQY/y916e+VE1ueRqlIsXZT8MB4VgJPsqQT4gNWcmwfvdeUdAUENOh
         BXBTstKfWVHZOH8XWr7A/UvXCxZ3ecacW1EK7Vxo41RzTjlxukxI8e1JGBlwULKfpc4+
         SLl2N5HGMQAMQsFU5AmjhruoUP0wgjG3yyZj8wlDQiAcU/iKT4NJVeQZYQEtrByShPTO
         4Vp54DeiEswXwKPhBYmkll5V8ydSKvXxtIyv9hKCKKVgCBH+PTCuMszvY5Y2Zf1sdBMH
         ejcQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710525994; x=1711130794;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=R0ZJ8zwoyTFUoE2+lGEttRsQ4y0+B4y5V6UHVOCeBNM=;
        b=AZXxQ1B5qUjguBsgjdydtxN7kcKl7wyaWyFGuOfIbLGNRKQNdr6S42L4Mgay1rgKpc
         4lMyBBvr6Ad7nszIB0jG2vHNO77/CD5hNQ8eyQU7H9b1yKcrdC8wo64MxHNMt927YEHu
         FAsTXnqPsIE+AbxznvmA54VERazyw33jKxyEC3SFGOoVF5sBjF140qZJ3Z4F2e2VOvNI
         eWNXGpC5H9hHq0RJZsSdhJ+Yh1AhLqFpHbI/unsQ8/XX7b0md9OAYxuDL0sNoKmIKKxP
         +mspAAzpTDBya6RJPSKn4pRTSw3ofxdKYQe5euJcQ+kXwQyXDVyPsfp3elcLlKBJ9iTn
         rNng==
X-Gm-Message-State: AOJu0YzriUIsmuQ0Y1U5xuVeVLd2kSp8Eq8lEKGjhlhOD4wLjw/ZMaFm
	GFf6n24E7gqkB/pKaa6/LFeudgs0Q++TYL11vygqWAG0RG2o4w66VLLTeNyuLrE=
X-Google-Smtp-Source: AGHT+IEFpC4E3dzwNXrHarHMlll3uOyZpHEq5UMYSVHFD+AipS9Kb5z7/0V71gSLRwGuwVN3xlM7SQ==
X-Received: by 2002:a2e:b5c8:0:b0:2d2:6227:d30a with SMTP id g8-20020a2eb5c8000000b002d26227d30amr3421195ljn.2.1710525993654;
        Fri, 15 Mar 2024 11:06:33 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini ,
	Wei Liu 
Subject: [PATCH v6 12/20] xen/riscv: add definition of __read_mostly
Date: Fri, 15 Mar 2024 19:06:08 +0100
Message-ID: 
X-Mailer: git-send-email 2.43.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

The definition of __read_mostly should be removed in:
https://lore.kernel.org/xen-devel/f25eb5c9-7c14-6e23-8535-2c66772b333e@suse.com/

The patch introduces it in arch-specific header to not
block enabling of full Xen build for RISC-V.

Signed-off-by: Oleksii Kurochko 
---
- [PATCH] move __read_mostly to xen/cache.h  [2]

Right now, the patch series doesn't have a direct dependency on [2] and it
provides __read_mostly in the patch:
    [PATCH v3 26/34] xen/riscv: add definition of __read_mostly
However, it will be dropped as soon as [2] is merged or at least when the
final version of the patch [2] is provided.

[2] https://lore.kernel.org/xen-devel/f25eb5c9-7c14-6e23-8535-2c66772b333e@suse.com/
---
Changes in V4-V7:
 - Nothing changed. Only rebase.
---
 xen/arch/riscv/include/asm/cache.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/xen/arch/riscv/include/asm/cache.h b/xen/arch/riscv/include/asm/cache.h
index 69573eb051..94bd94db53 100644
--- a/xen/arch/riscv/include/asm/cache.h
+++ b/xen/arch/riscv/include/asm/cache.h
@@ -3,4 +3,6 @@
 #ifndef _ASM_RISCV_CACHE_H
 #define _ASM_RISCV_CACHE_H
 
+#define __read_mostly __section(".data.read_mostly")
+
 #endif /* _ASM_RISCV_CACHE_H */
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Mar 15 18:06:37 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 18:06:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693998.1082799 (Exim 4.92)
	(envelope-from )
	id 1rlBwz-0000Zr-B3; Fri, 15 Mar 2024 18:06:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693998.1082799; Fri, 15 Mar 2024 18:06:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rlBwy-0000YZ-UJ; Fri, 15 Mar 2024 18:06:36 +0000
Received: by outflank-mailman (input) for mailman id 693998;
 Fri, 15 Mar 2024 18:06:35 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rlBwx-0005yV-3o
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 18:06:35 +0000
Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com
 [2a00:1450:4864:20::230])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c1b87cda-e2f6-11ee-a1ee-f123f15fe8a2;
 Fri, 15 Mar 2024 19:06:33 +0100 (CET)
Received: by mail-lj1-x230.google.com with SMTP id
 38308e7fff4ca-2d228a132acso33502901fa.0
 for ; Fri, 15 Mar 2024 11:06:33 -0700 (PDT)
Received: from fedora.. ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id
 g29-20020a05651c079d00b002d0acb57c89sm568939lje.64.2024.03.15.11.06.31
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 15 Mar 2024 11:06:31 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c1b87cda-e2f6-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1710525992; x=1711130792; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=zff6ossjNgY8dZpXRlsy8KdZaJuDQAMnmaMaUR1g5PM=;
        b=fZ3Ab2iIZWUUqT7ZvWrOa/LCIkdH0+Io7bNlY+GkV8o8pov/BU7GOGg3/nVWo1u02b
         EI/EyxFxqi8cABALvNdgvDNy2fNvv+2Rkq4N/7A6AnvgulfLzsVA9jeIOnLytgKnc70P
         5D4mmUfU/TBiIqO/HGpH8IKESDjoCg8NVTDcVC8MKeMtNkZBOFVryx1NXDJ5Q1tsFDcy
         9Iep+RnfdLhrxAj3s8hkSrhtJx8hmGtqCO4H/UZkBnEFqEFD7ZN6yQZXBi6UD0rHFsls
         oZxV438HWcuC2RjrvvornLnXV+4jJJGj9yEAEODyOMg5nmNebT2J7uh4rh1i+8uR2Pj4
         7PUw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710525992; x=1711130792;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=zff6ossjNgY8dZpXRlsy8KdZaJuDQAMnmaMaUR1g5PM=;
        b=HyuqK+nKXxX+Ohl6VMHvoxpNzuTmHzNsVc59ipqzGckTpkj7Oryv2wNWkNs6ysR5Tx
         5QAvcSN2YZ30+oydGo5gBdT2NvCYTT0M0tiSbdIugjoFf4i/jmYSbv3IICBBLc1Qe3Pw
         ztfxqtf1PYwrINY9RWYI9rhkCVbLT773PSi/EqAuicgLU4zoStsyMJrjcUagL/ZbKnQE
         sxAXuT+w54f/0q16uJCbJpP11/NiEl4ijVPlkUuSesiKxqoixQrGWnweQdVe4QuntHvM
         EKpkAgabFT2tE5tmJ3sPUmRWnhtEfHZoHTi4irbmmh5RoADqxFAx82hzZHgitlmG3hGC
         V40w==
X-Gm-Message-State: AOJu0YzhibP+X0BADT3nEcls9vJMVve4EtITUPFagtHXmNWYvl9tz4ZO
	V7iGX6ZY/qJHoU9oihwW4isEzdfiPPnp49xl+sGxRncsNs6DSO9Usos9Bpg555c=
X-Google-Smtp-Source: AGHT+IEHppgqCqzxoUIQjpZcPx03Rnt4Bd6d0FbIAWy1WybZeWZ+R967IHgDrTEmv0xEfL5fD5+Bfg==
X-Received: by 2002:a2e:a592:0:b0:2d4:6815:fc6f with SMTP id m18-20020a2ea592000000b002d46815fc6fmr4449587ljp.30.1710525992115;
        Fri, 15 Mar 2024 11:06:32 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Tamas K Lengyel ,
	Alexandru Isaila ,
	Petre Pircalabu ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis 
Subject: [PATCH v6 11/20] xen/riscv: introduce monitor.h
Date: Fri, 15 Mar 2024 19:06:07 +0100
Message-ID: <376e3ba3087b4d5d71ca20804abb33129f75bd5b.1710517542.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Signed-off-by: Oleksii Kurochko 
---
Changes in V4/V5/V6:
 - Nothing changed. Only rebase.
---
Changes in V3:
 - new patch.
---
 xen/arch/riscv/include/asm/monitor.h | 26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)
 create mode 100644 xen/arch/riscv/include/asm/monitor.h

diff --git a/xen/arch/riscv/include/asm/monitor.h b/xen/arch/riscv/include/asm/monitor.h
new file mode 100644
index 0000000000..f4fe2c0690
--- /dev/null
+++ b/xen/arch/riscv/include/asm/monitor.h
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef __ASM_RISCV_MONITOR_H__
+#define __ASM_RISCV_MONITOR_H__
+
+#include 
+
+#include 
+
+struct domain;
+
+static inline uint32_t arch_monitor_get_capabilities(struct domain *d)
+{
+    BUG_ON("unimplemented");
+    return 0;
+}
+
+#endif /* __ASM_RISCV_MONITOR_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Mar 15 18:06:38 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 18:06:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.693999.1082806 (Exim 4.92)
	(envelope-from )
	id 1rlBx0-0000nx-Cc; Fri, 15 Mar 2024 18:06:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 693999.1082806; Fri, 15 Mar 2024 18:06:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rlBwz-0000lw-QO; Fri, 15 Mar 2024 18:06:37 +0000
Received: by outflank-mailman (input) for mailman id 693999;
 Fri, 15 Mar 2024 18:06:36 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rlBwx-0005yW-Tu
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 18:06:35 +0000
Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com
 [2a00:1450:4864:20::230])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c2e1cc86-e2f6-11ee-afdd-a90da7624cb6;
 Fri, 15 Mar 2024 19:06:35 +0100 (CET)
Received: by mail-lj1-x230.google.com with SMTP id
 38308e7fff4ca-2d4541bf57eso31469891fa.2
 for ; Fri, 15 Mar 2024 11:06:35 -0700 (PDT)
Received: from fedora.. ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id
 g29-20020a05651c079d00b002d0acb57c89sm568939lje.64.2024.03.15.11.06.33
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 15 Mar 2024 11:06:34 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c2e1cc86-e2f6-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1710525995; x=1711130795; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=BniKWGYPbeiPbe87yny1VU0OUUHSQ613GEG/PFydHOE=;
        b=itv8IcP+YjsW51ghx2/psu7Lv1WOHpOPhW5Otl6ZQetsgS/O8NHQy77r3UyIS0RlI2
         DukQVbnMs/T87idD+KGC7xYK85gHhPd68WN2nbR7yF/P8Fj2ZQo+KXFoonLfmvqm3XxQ
         fKURLX89mUnl8sqNvdbja4PdKHdBG2RtkymIb3sjvvSHo1HWtr1nAhRaNcMdwzzAs5A6
         wKwl1BjsCwi3MAehoge7GJEeQ68NorJ1UfK77nxo/dhyX2sBqW7kVQI+l1UOQvPBY93F
         y/EsQEq2qxRz7WuP5b/7aO/vnaz4LIvyjWsQhnxZysvtUUeDwGlLX3f2E1PhUeIyAHpf
         MkEA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710525995; x=1711130795;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=BniKWGYPbeiPbe87yny1VU0OUUHSQ613GEG/PFydHOE=;
        b=M1kze4guZdRtY8OWsKvWTUU4X974TWm7W2WY1iBfmWclg+wcyUhNGBAWYooMuOFFPN
         olBjskun4pRmNwzJqDpJV4r0j3OcJKDFCpq6a1ySYV0t8uklDOqfEzdmbNMRKxzsgVpg
         pPzX2c9fETb8fPoHxMJ6ubnYLtdRtQGhIpz3XNfKFIl8KMqDCxv60xDqJKquF92f5WGc
         FB2tK6k2PJA8Is0f+KD0/M2clGfAtY4DTVAS8BAUeTvwe0J2N6Z5L6sdaGhpDZDMXmsW
         ouTRscoFvZ70l+IihFQBXSydYa8stOREsxemNPJF4txCFXzV6DRUOOfOGIsn/DWTfUeW
         fm1Q==
X-Gm-Message-State: AOJu0YwJxQFE+x7UR436W0OGY7Egw+Fi0DBz2rcQGgf9JE20pANFVqun
	ZuikzSSfpnj83UQ+cVJfSk9WoxMbu28YnSvvjZETn89dsyCuQVCPJOUeLekNEWQ=
X-Google-Smtp-Source: AGHT+IGA98oEzc5+hDzsjLGyoNfpm+Kj1QtNxE8WwYFQFfSSAdopDSh+QzESkCRsrUFzZ1HCT8cdRQ==
X-Received: by 2002:a05:651c:32a:b0:2d4:3c64:53f5 with SMTP id b10-20020a05651c032a00b002d43c6453f5mr3217155ljp.19.1710525994655;
        Fri, 15 Mar 2024 11:06:34 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini ,
	Wei Liu 
Subject: [PATCH v6 13/20] xen/riscv: add required things to current.h
Date: Fri, 15 Mar 2024 19:06:09 +0100
Message-ID: <7691cf03f61348d368e33200962c3fa73f7a47b1.1710517542.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Add minimal requied things to be able to build full Xen.

Signed-off-by: Oleksii Kurochko 
Acked-by: Jan Beulich 
---
Changes in V5/V6:
 - Nothing changed. Only rebase.
---
Changes in V4:
 - BUG() was changed to BUG_ON("unimplemented");
 - Change "xen/bug.h" to "xen/lib.h" as BUG_ON is defined in xen/lib.h.
 - Add Acked-by: Jan Beulich 
---
Changes in V3:
 - add SPDX
 - drop a forward declaration of struct vcpu;
 - update guest_cpu_user_regs() macros
 - replace get_processor_id with smp_processor_id
 - update the commit message
 - code style fixes
---
Changes in V2:
 - Nothing changed. Only rebase.
---
 xen/arch/riscv/include/asm/current.h | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/xen/arch/riscv/include/asm/current.h b/xen/arch/riscv/include/asm/current.h
index d84f15dc50..aedb6dc732 100644
--- a/xen/arch/riscv/include/asm/current.h
+++ b/xen/arch/riscv/include/asm/current.h
@@ -3,6 +3,21 @@
 #ifndef __ASM_CURRENT_H
 #define __ASM_CURRENT_H
 
+#include 
+#include 
+#include 
+
+#ifndef __ASSEMBLY__
+
+/* Which VCPU is "current" on this PCPU. */
+DECLARE_PER_CPU(struct vcpu *, curr_vcpu);
+
+#define current            this_cpu(curr_vcpu)
+#define set_current(vcpu)  do { current = (vcpu); } while (0)
+#define get_cpu_current(cpu)  per_cpu(curr_vcpu, cpu)
+
+#define guest_cpu_user_regs() ({ BUG_ON("unimplemented"); NULL; })
+
 #define switch_stack_and_jump(stack, fn) do {               \
     asm volatile (                                          \
             "mv sp, %0\n"                                   \
@@ -10,4 +25,8 @@
     unreachable();                                          \
 } while ( false )
 
+#define get_per_cpu_offset() __per_cpu_offset[smp_processor_id()]
+
+#endif /* __ASSEMBLY__ */
+
 #endif /* __ASM_CURRENT_H */
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Mar 15 18:06:43 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 18:06:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694000.1082824 (Exim 4.92)
	(envelope-from )
	id 1rlBx5-0001mA-4o; Fri, 15 Mar 2024 18:06:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694000.1082824; Fri, 15 Mar 2024 18:06:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rlBx4-0001lV-UQ; Fri, 15 Mar 2024 18:06:42 +0000
Received: by outflank-mailman (input) for mailman id 694000;
 Fri, 15 Mar 2024 18:06:40 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rlBx2-0005yV-Lj
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 18:06:40 +0000
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com
 [2a00:1450:4864:20::22a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c507ed31-e2f6-11ee-a1ee-f123f15fe8a2;
 Fri, 15 Mar 2024 19:06:39 +0100 (CET)
Received: by mail-lj1-x22a.google.com with SMTP id
 38308e7fff4ca-2d46dd8b0b8so29375951fa.2
 for ; Fri, 15 Mar 2024 11:06:39 -0700 (PDT)
Received: from fedora.. ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id
 g29-20020a05651c079d00b002d0acb57c89sm568939lje.64.2024.03.15.11.06.37
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 15 Mar 2024 11:06:37 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c507ed31-e2f6-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1710525998; x=1711130798; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=nzOhvuVMEWrAlSN3mvrz481DJXnExskCp2xBFUwfERo=;
        b=cQ9/5Y9TEVASjQMSMaaxSfdX0Hlgd/Q7eJlW3PATxiqClupFrwjwucLY5bngPzLMKD
         1Sxwudp0ZjKPNAyajWtuGJ42gr+YiFNxmiXOKeQhEG508lIgEcR0R3P+5pysho0KwpPZ
         mykauijp0kgktbag2SwzEb6rEZ3KaZS7yd+e2O+q03LSWzi7B3Z3snT4wlb14sAiD76X
         C7byOQSPQoHuhaCYY2LMM9lsLRgTmrHRyy0gMyJBoPsX1BawyYkanC8rlqRp9yEuQUmL
         9HD2pE5CU5xpBIR0trjk8FhNSaHM/HncVGChjK7s437puwqbknRX121agWhkILEyKA8o
         L4wg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710525998; x=1711130798;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=nzOhvuVMEWrAlSN3mvrz481DJXnExskCp2xBFUwfERo=;
        b=xF0eqDK5cIRePFlzr6miQPrcWosgzfhYPUmLQcVBxx1xbTBQ0mEiYeDSmhYZ7qIbzz
         0Uq3M+BDOG2jVzfqDj/DIy6RRsLIAO1aDR6pFogSf/Lbnp2dA3sP9mt/QHJ+If7EsjHv
         dqqimtUt2NMyvbDRgiulXZ3OjuJbQKPDnTEn5frIcI6BEuSPqweJnh3AYVRqA8EhgbV2
         4161i+4Q1Z+36aSEcgWWjh/cYx+irfpRFUDcPj2S/JwTpNo3nd+EPgk9l7Jbbbmy4Oa9
         j9ycjFb/Tezn7PbxRKWK13bM0q2yLO2cAkz4qSRy5a7dNfXPiLGZ5Si46v6ReuR5yzO+
         TFjA==
X-Gm-Message-State: AOJu0YzEe5jNYMa5OTk6E/B99yIu8o+P47Crfj7CShGFktB+6i/+CPXs
	s8j6JUt2RbpoLtwuYkOWJE7Q9WkPYWCi6thGQUUZDV/FdqOp+rYSr/cjdgyvJkw=
X-Google-Smtp-Source: AGHT+IEFh/oiRzCaxpgEPIJLr01iJJh2LVc57Qy0M1nc4LK03in1ME6rGNfPlUCj0rkhca1tkDJqng==
X-Received: by 2002:a05:651c:19a1:b0:2d4:6d57:84f4 with SMTP id bx33-20020a05651c19a100b002d46d5784f4mr5028421ljb.8.1710525997947;
        Fri, 15 Mar 2024 11:06:37 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Tamas K Lengyel ,
	Alexandru Isaila ,
	Petre Pircalabu 
Subject: [PATCH v6 17/20] xen/riscv: introduce vm_event_*() functions
Date: Fri, 15 Mar 2024 19:06:13 +0100
Message-ID: <446494168f3c3dbdba90536c4e69af7e9d6b4999.1710517542.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Signed-off-by: Oleksii Kurochko 
---
Changes in V5-V6:
 - Only rebase was done.
---
Changes in V4:
  - New patch.
---
 xen/arch/riscv/Makefile   |  1 +
 xen/arch/riscv/vm_event.c | 19 +++++++++++++++++++
 2 files changed, 20 insertions(+)
 create mode 100644 xen/arch/riscv/vm_event.c

diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile
index 2fefe14e7c..1ed1a8369b 100644
--- a/xen/arch/riscv/Makefile
+++ b/xen/arch/riscv/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_RISCV_64) += riscv64/
 obj-y += sbi.o
 obj-y += setup.o
 obj-y += traps.o
+obj-y += vm_event.o
 
 $(TARGET): $(TARGET)-syms
 	$(OBJCOPY) -O binary -S $< $@
diff --git a/xen/arch/riscv/vm_event.c b/xen/arch/riscv/vm_event.c
new file mode 100644
index 0000000000..bb1fc73bc1
--- /dev/null
+++ b/xen/arch/riscv/vm_event.c
@@ -0,0 +1,19 @@
+#include 
+
+struct vm_event_st;
+struct vcpu;
+
+void vm_event_fill_regs(struct vm_event_st *req)
+{
+    BUG_ON("unimplemented");
+}
+
+void vm_event_set_registers(struct vcpu *v, struct vm_event_st *rsp)
+{
+    BUG_ON("unimplemented");
+}
+
+void vm_event_monitor_next_interrupt(struct vcpu *v)
+{
+    /* Not supported on RISCV. */
+}
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Mar 15 18:06:44 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 18:06:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694001.1082829 (Exim 4.92)
	(envelope-from )
	id 1rlBx6-0001qg-0V; Fri, 15 Mar 2024 18:06:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694001.1082829; Fri, 15 Mar 2024 18:06:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rlBx5-0001o6-BF; Fri, 15 Mar 2024 18:06:43 +0000
Received: by outflank-mailman (input) for mailman id 694001;
 Fri, 15 Mar 2024 18:06:42 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rlBx4-0005yV-HW
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 18:06:42 +0000
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com
 [2a00:1450:4864:20::12a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c5f1b225-e2f6-11ee-a1ee-f123f15fe8a2;
 Fri, 15 Mar 2024 19:06:40 +0100 (CET)
Received: by mail-lf1-x12a.google.com with SMTP id
 2adb3069b0e04-513d3746950so2551193e87.1
 for ; Fri, 15 Mar 2024 11:06:40 -0700 (PDT)
Received: from fedora.. ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id
 g29-20020a05651c079d00b002d0acb57c89sm568939lje.64.2024.03.15.11.06.38
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 15 Mar 2024 11:06:38 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c5f1b225-e2f6-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1710525999; x=1711130799; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=qwu2DXrg0/pr+/WwCY5rbhJqHhZ0RnnWDt5vSQuU8ps=;
        b=CuBVi8ogeeRi5WTN+YiXzn2FxJIKJzCq6DqLZ5urdmxaLqLvWbLfxhpbj2/jCwheqJ
         uHzzPnq4qAH27X0auqxlN5hiWSdCRQjd/w/XFthM2+NKnLu8VJPOhRBVJDz243iFyeck
         mInZmOKG2Gd9XQWHB1qQ6OWJMcevfDNotSmnAIACrTebmUDP9STHIc2/H+NOcMJi9mLW
         MH5H5M2Xaw9HwzQ0Zk29RBxX5ELTIpaB1zUNkvvs+cGwChfMcCTIPzaIPY4+u2Q+EBnC
         htgIt7fRCU3basORGQQtKj5eRZWYEyxDOvYiQkPrWzG32n3Au6MdhV3lY4XlOkTnKnc+
         Dlwg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710525999; x=1711130799;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=qwu2DXrg0/pr+/WwCY5rbhJqHhZ0RnnWDt5vSQuU8ps=;
        b=XmPsdIp4Ae+q23JcW1DupmGjqh8+PB/+oqNwBwfa3hqTyUwssN6cv6a0R7HJPi1jHY
         UXJOsfBtUbD5rC32cABnWWYd8Lg6Pv/W3ObHpaIhxgVyCVr95Z+QLzO52aKybb1GlozR
         I+PALr0IWXG79VM2e2a4BJSA7/UsVO8oSbeWZcZ5JctGFDr/6VcQSMkPFPNhuIstJ6ps
         jD7y7Yu59x7qXmBluRTS63w7aqNRfRGGfub3fm68+ogGR1ZGDwlq4Am7Ur6jIQtBNzVv
         EZvBDpvjLF1AXP1d5JL4BP0fDmQVtRIJ4qBhQmzPbQ5BX1b1VkALumiUGeeXCSnr1cdn
         LNTw==
X-Gm-Message-State: AOJu0YzdUlda4wdbOizsv7U23eEeUs58EGD24D+cddIZss9JLYJBYgtl
	acmOnGsXRuZ2AD7nY1mmVGgAl0/K9/7I2byhMMw4xegMmkcMLjZRaNu5Q9AOmec=
X-Google-Smtp-Source: AGHT+IGXEYmuyciG/c3sp9WJz2MX9dYGNfqPA4VV+Uz+Ve2la8tnuxU8oYTi7Gmdnkw83b7Dw3Cmww==
X-Received: by 2002:a2e:7a02:0:b0:2d4:7218:4cf1 with SMTP id v2-20020a2e7a02000000b002d472184cf1mr2439090ljc.7.1710525999293;
        Fri, 15 Mar 2024 11:06:39 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini ,
	Wei Liu 
Subject: [PATCH v6 18/20] xen/riscv: add minimal amount of stubs to build full Xen
Date: Fri, 15 Mar 2024 19:06:14 +0100
Message-ID: <68276b974592b7bccc0a619959c0fdeec007f298.1710517542.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Signed-off-by: Oleksii Kurochko 
Acked-by: Jan Beulich 
---
Changes in V6:
 - update the commit in stubs.c around /* ... common/irq.c ... */
 - add Acked-by: Jan Beulich 
---
Changes in V5:
 - drop unrelated changes
 - assert_failed("unimplmented...") change to BUG_ON()
---
Changes in V4:
  - added new stubs which are necessary for compilation after rebase: __cpu_up(), __cpu_disable(), __cpu_die()
    from smpboot.c
  - back changes related to printk() in early_printk() as they should be removed in the next patch to avoid
    compilation error.
  - update definition of cpu_khz: __read_mostly -> __ro_after_init.
  - drop vm_event_reset_vmtrace(). It is defibed in asm-generic/vm_event.h.
  - move vm_event_*() functions from stubs.c to riscv/vm_event.c.
  - s/BUG/BUG_ON("unimplemented") in stubs.c
  - back irq_actor_none() and irq_actor_none() as common/irq.c isn't compiled at this moment,
    so this function are needed to avoid compilation error.
  - defined max_page to avoid compilation error, it will be removed as soon as common/page_alloc.c will
    be compiled.
---
Changes in V3:
 - code style fixes.
 - update attribute for frametable_base_pdx  and frametable_virt_end to __ro_after_init.
   insteaf of read_mostly.
 - use BUG() instead of assert_failed/WARN for newly introduced stubs.
 - drop "#include " in stubs.c and use forward declaration instead.
 - drop ack_node() and end_node() as they aren't used now.
---
Changes in V2:
 - define udelay stub
 - remove 'select HAS_PDX' from RISC-V Kconfig because of
   https://lore.kernel.org/xen-devel/20231006144405.1078260-1-andrew.cooper3@citrix.com/
---
 xen/arch/riscv/Makefile |   1 +
 xen/arch/riscv/mm.c     |  50 +++++
 xen/arch/riscv/setup.c  |   8 +
 xen/arch/riscv/stubs.c  | 439 ++++++++++++++++++++++++++++++++++++++++
 xen/arch/riscv/traps.c  |  25 +++
 5 files changed, 523 insertions(+)
 create mode 100644 xen/arch/riscv/stubs.c

diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile
index 1ed1a8369b..60afbc0ad9 100644
--- a/xen/arch/riscv/Makefile
+++ b/xen/arch/riscv/Makefile
@@ -4,6 +4,7 @@ obj-y += mm.o
 obj-$(CONFIG_RISCV_64) += riscv64/
 obj-y += sbi.o
 obj-y += setup.o
+obj-y += stubs.o
 obj-y += traps.o
 obj-y += vm_event.o
 
diff --git a/xen/arch/riscv/mm.c b/xen/arch/riscv/mm.c
index fe3a43be20..2c3fb7d72e 100644
--- a/xen/arch/riscv/mm.c
+++ b/xen/arch/riscv/mm.c
@@ -1,5 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 
+#include 
 #include 
 #include 
 #include 
@@ -14,6 +15,9 @@
 #include 
 #include 
 
+unsigned long __ro_after_init frametable_base_pdx;
+unsigned long __ro_after_init frametable_virt_end;
+
 struct mmu_desc {
     unsigned int num_levels;
     unsigned int pgtbl_count;
@@ -294,3 +298,49 @@ unsigned long __init calc_phys_offset(void)
     phys_offset = load_start - XEN_VIRT_START;
     return phys_offset;
 }
+
+void put_page(struct page_info *page)
+{
+    BUG_ON("unimplemented");
+}
+
+unsigned long get_upper_mfn_bound(void)
+{
+    /* No memory hotplug yet, so current memory limit is the final one. */
+    return max_page - 1;
+}
+
+void arch_dump_shared_mem_info(void)
+{
+    BUG_ON("unimplemented");
+}
+
+int populate_pt_range(unsigned long virt, unsigned long nr_mfns)
+{
+    BUG_ON("unimplemented");
+    return -1;
+}
+
+int xenmem_add_to_physmap_one(struct domain *d, unsigned int space,
+                              union add_to_physmap_extra extra,
+                              unsigned long idx, gfn_t gfn)
+{
+    BUG_ON("unimplemented");
+
+    return 0;
+}
+
+int destroy_xen_mappings(unsigned long s, unsigned long e)
+{
+    BUG_ON("unimplemented");
+    return -1;
+}
+
+int map_pages_to_xen(unsigned long virt,
+                     mfn_t mfn,
+                     unsigned long nr_mfns,
+                     unsigned int flags)
+{
+    BUG_ON("unimplemented");
+    return -1;
+}
diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c
index 98a94c4c48..8bb5bdb2ae 100644
--- a/xen/arch/riscv/setup.c
+++ b/xen/arch/riscv/setup.c
@@ -1,11 +1,19 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 
+#include 
 #include 
 #include 
 #include 
 
+#include 
+
 #include 
 
+void arch_get_xen_caps(xen_capabilities_info_t *info)
+{
+    BUG_ON("unimplemented");
+}
+
 /* Xen stack for bringing up the first CPU. */
 unsigned char __initdata cpu0_boot_stack[STACK_SIZE]
     __aligned(STACK_SIZE);
diff --git a/xen/arch/riscv/stubs.c b/xen/arch/riscv/stubs.c
new file mode 100644
index 0000000000..8285bcffef
--- /dev/null
+++ b/xen/arch/riscv/stubs.c
@@ -0,0 +1,439 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+/* smpboot.c */
+
+cpumask_t cpu_online_map;
+cpumask_t cpu_present_map;
+cpumask_t cpu_possible_map;
+
+/* ID of the PCPU we're running on */
+DEFINE_PER_CPU(unsigned int, cpu_id);
+/* XXX these seem awfully x86ish... */
+/* representing HT siblings of each logical CPU */
+DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_sibling_mask);
+/* representing HT and core siblings of each logical CPU */
+DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_core_mask);
+
+nodemask_t __read_mostly node_online_map = { { [0] = 1UL } };
+
+/*
+ * max_page is defined in page_alloc.c which isn't complied for now.
+ * definition of max_page will be remove as soon as page_alloc is built.
+ */
+unsigned long __read_mostly max_page;
+
+/* time.c */
+
+unsigned long __ro_after_init cpu_khz;  /* CPU clock frequency in kHz. */
+
+s_time_t get_s_time(void)
+{
+    BUG_ON("unimplemented");
+}
+
+int reprogram_timer(s_time_t timeout)
+{
+    BUG_ON("unimplemented");
+}
+
+void send_timer_event(struct vcpu *v)
+{
+    BUG_ON("unimplemented");
+}
+
+void domain_set_time_offset(struct domain *d, int64_t time_offset_seconds)
+{
+    BUG_ON("unimplemented");
+}
+
+/* shutdown.c */
+
+void machine_restart(unsigned int delay_millisecs)
+{
+    BUG_ON("unimplemented");
+}
+
+void machine_halt(void)
+{
+    BUG_ON("unimplemented");
+}
+
+/* domctl.c */
+
+long arch_do_domctl(struct xen_domctl *domctl, struct domain *d,
+                    XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
+{
+    BUG_ON("unimplemented");
+}
+
+void arch_get_domain_info(const struct domain *d,
+                          struct xen_domctl_getdomaininfo *info)
+{
+    BUG_ON("unimplemented");
+}
+
+void arch_get_info_guest(struct vcpu *v, vcpu_guest_context_u c)
+{
+    BUG_ON("unimplemented");
+}
+
+/* monitor.c */
+
+int arch_monitor_domctl_event(struct domain *d,
+                              struct xen_domctl_monitor_op *mop)
+{
+    BUG_ON("unimplemented");
+}
+
+/* smp.c */
+
+void arch_flush_tlb_mask(const cpumask_t *mask)
+{
+    BUG_ON("unimplemented");
+}
+
+void smp_send_event_check_mask(const cpumask_t *mask)
+{
+    BUG_ON("unimplemented");
+}
+
+void smp_send_call_function_mask(const cpumask_t *mask)
+{
+    BUG_ON("unimplemented");
+}
+
+/* irq.c */
+
+struct pirq *alloc_pirq_struct(struct domain *d)
+{
+    BUG_ON("unimplemented");
+}
+
+int pirq_guest_bind(struct vcpu *v, struct pirq *pirq, int will_share)
+{
+    BUG_ON("unimplemented");
+}
+
+void pirq_guest_unbind(struct domain *d, struct pirq *pirq)
+{
+    BUG_ON("unimplemented");
+}
+
+void pirq_set_affinity(struct domain *d, int pirq, const cpumask_t *mask)
+{
+    BUG_ON("unimplemented");
+}
+
+hw_irq_controller no_irq_type = {
+    .typename = "none",
+    .startup = irq_startup_none,
+    .shutdown = irq_shutdown_none,
+    .enable = irq_enable_none,
+    .disable = irq_disable_none,
+};
+
+int arch_init_one_irq_desc(struct irq_desc *desc)
+{
+    BUG_ON("unimplemented");
+}
+
+void smp_send_state_dump(unsigned int cpu)
+{
+    BUG_ON("unimplemented");
+}
+
+/* domain.c */
+
+DEFINE_PER_CPU(struct vcpu *, curr_vcpu);
+unsigned long __per_cpu_offset[NR_CPUS];
+
+void context_switch(struct vcpu *prev, struct vcpu *next)
+{
+    BUG_ON("unimplemented");
+}
+
+void continue_running(struct vcpu *same)
+{
+    BUG_ON("unimplemented");
+}
+
+void sync_local_execstate(void)
+{
+    BUG_ON("unimplemented");
+}
+
+void sync_vcpu_execstate(struct vcpu *v)
+{
+    BUG_ON("unimplemented");
+}
+
+void startup_cpu_idle_loop(void)
+{
+    BUG_ON("unimplemented");
+}
+
+void free_domain_struct(struct domain *d)
+{
+    BUG_ON("unimplemented");
+}
+
+void dump_pageframe_info(struct domain *d)
+{
+    BUG_ON("unimplemented");
+}
+
+void free_vcpu_struct(struct vcpu *v)
+{
+    BUG_ON("unimplemented");
+}
+
+int arch_vcpu_create(struct vcpu *v)
+{
+    BUG_ON("unimplemented");
+}
+
+void arch_vcpu_destroy(struct vcpu *v)
+{
+    BUG_ON("unimplemented");
+}
+
+void vcpu_switch_to_aarch64_mode(struct vcpu *v)
+{
+    BUG_ON("unimplemented");
+}
+
+int arch_sanitise_domain_config(struct xen_domctl_createdomain *config)
+{
+    BUG_ON("unimplemented");
+}
+
+int arch_domain_create(struct domain *d,
+                       struct xen_domctl_createdomain *config,
+                       unsigned int flags)
+{
+    BUG_ON("unimplemented");
+}
+
+int arch_domain_teardown(struct domain *d)
+{
+    BUG_ON("unimplemented");
+}
+
+void arch_domain_destroy(struct domain *d)
+{
+    BUG_ON("unimplemented");
+}
+
+void arch_domain_shutdown(struct domain *d)
+{
+    BUG_ON("unimplemented");
+}
+
+void arch_domain_pause(struct domain *d)
+{
+    BUG_ON("unimplemented");
+}
+
+void arch_domain_unpause(struct domain *d)
+{
+    BUG_ON("unimplemented");
+}
+
+int arch_domain_soft_reset(struct domain *d)
+{
+    BUG_ON("unimplemented");
+}
+
+void arch_domain_creation_finished(struct domain *d)
+{
+    BUG_ON("unimplemented");
+}
+
+int arch_set_info_guest(struct vcpu *v, vcpu_guest_context_u c)
+{
+    BUG_ON("unimplemented");
+}
+
+int arch_initialise_vcpu(struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg)
+{
+    BUG_ON("unimplemented");
+}
+
+int arch_vcpu_reset(struct vcpu *v)
+{
+    BUG_ON("unimplemented");
+}
+
+int domain_relinquish_resources(struct domain *d)
+{
+    BUG_ON("unimplemented");
+}
+
+void arch_dump_domain_info(struct domain *d)
+{
+    BUG_ON("unimplemented");
+}
+
+void arch_dump_vcpu_info(struct vcpu *v)
+{
+    BUG_ON("unimplemented");
+}
+
+void vcpu_mark_events_pending(struct vcpu *v)
+{
+    BUG_ON("unimplemented");
+}
+
+void vcpu_update_evtchn_irq(struct vcpu *v)
+{
+    BUG_ON("unimplemented");
+}
+
+void vcpu_block_unless_event_pending(struct vcpu *v)
+{
+    BUG_ON("unimplemented");
+}
+
+void vcpu_kick(struct vcpu *v)
+{
+    BUG_ON("unimplemented");
+}
+
+struct domain *alloc_domain_struct(void)
+{
+    BUG_ON("unimplemented");
+}
+
+struct vcpu *alloc_vcpu_struct(const struct domain *d)
+{
+    BUG_ON("unimplemented");
+}
+
+unsigned long
+hypercall_create_continuation(unsigned int op, const char *format, ...)
+{
+    BUG_ON("unimplemented");
+}
+
+int __init parse_arch_dom0_param(const char *s, const char *e)
+{
+    BUG_ON("unimplemented");
+}
+
+/* guestcopy.c */
+
+unsigned long raw_copy_to_guest(void *to, const void *from, unsigned int len)
+{
+    BUG_ON("unimplemented");
+}
+
+unsigned long raw_copy_from_guest(void *to, const void __user *from,
+                                  unsigned int len)
+{
+    BUG_ON("unimplemented");
+}
+
+/* sysctl.c */
+
+long arch_do_sysctl(struct xen_sysctl *sysctl,
+                    XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
+{
+    BUG_ON("unimplemented");
+}
+
+void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
+{
+    BUG_ON("unimplemented");
+}
+
+/* p2m.c */
+
+int arch_set_paging_mempool_size(struct domain *d, uint64_t size)
+{
+    BUG_ON("unimplemented");
+}
+
+int unmap_mmio_regions(struct domain *d,
+                       gfn_t start_gfn,
+                       unsigned long nr,
+                       mfn_t mfn)
+{
+    BUG_ON("unimplemented");
+}
+
+int map_mmio_regions(struct domain *d,
+                     gfn_t start_gfn,
+                     unsigned long nr,
+                     mfn_t mfn)
+{
+    BUG_ON("unimplemented");
+}
+
+int set_foreign_p2m_entry(struct domain *d, const struct domain *fd,
+                          unsigned long gfn, mfn_t mfn)
+{
+    BUG_ON("unimplemented");
+}
+
+/* Return the size of the pool, in bytes. */
+int arch_get_paging_mempool_size(struct domain *d, uint64_t *size)
+{
+    BUG_ON("unimplemented");
+}
+
+/* delay.c */
+
+void udelay(unsigned long usecs)
+{
+    BUG_ON("unimplemented");
+}
+
+/* guest_access.h */ 
+
+static inline unsigned long raw_clear_guest(void *to, unsigned int len)
+{
+    BUG_ON("unimplemented");
+}
+
+/* smpboot.c */
+
+int __cpu_up(unsigned int cpu)
+{
+    BUG_ON("unimplemented");
+}
+
+void __cpu_disable(void)
+{
+    BUG_ON("unimplemented");
+}
+
+void __cpu_die(unsigned int cpu)
+{
+    BUG_ON("unimplemented");
+}
+
+/*
+ * The following functions are defined in common/irq.c, but common/irq.c isn't
+ * built for now. These changes will be removed there when common/irq.c is
+ * ready.
+ */
+
+void cf_check irq_actor_none(struct irq_desc *desc)
+{
+    BUG_ON("unimplemented");
+}
+
+unsigned int cf_check irq_startup_none(struct irq_desc *desc)
+{
+    BUG_ON("unimplemented");
+
+    return 0;
+}
diff --git a/xen/arch/riscv/traps.c b/xen/arch/riscv/traps.c
index ccd3593f5a..5415cf8d90 100644
--- a/xen/arch/riscv/traps.c
+++ b/xen/arch/riscv/traps.c
@@ -4,6 +4,10 @@
  *
  * RISC-V Trap handlers
  */
+
+#include 
+#include 
+
 #include 
 #include 
 
@@ -11,3 +15,24 @@ void do_trap(struct cpu_user_regs *cpu_regs)
 {
     die();
 }
+
+void vcpu_show_execution_state(struct vcpu *v)
+{
+    BUG_ON("unimplemented");
+}
+
+void show_execution_state(const struct cpu_user_regs *regs)
+{
+    printk("implement show_execution_state(regs)\n");
+}
+
+void arch_hypercall_tasklet_result(struct vcpu *v, long res)
+{
+    BUG_ON("unimplemented");
+}
+
+enum mc_disposition arch_do_multicall_call(struct mc_state *state)
+{
+    BUG_ON("unimplemented");
+    return mc_continue;
+}
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Mar 15 18:06:45 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 18:06:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694002.1082838 (Exim 4.92)
	(envelope-from )
	id 1rlBx7-0002Eu-9E; Fri, 15 Mar 2024 18:06:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694002.1082838; Fri, 15 Mar 2024 18:06:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rlBx6-0002Ca-Uw; Fri, 15 Mar 2024 18:06:44 +0000
Received: by outflank-mailman (input) for mailman id 694002;
 Fri, 15 Mar 2024 18:06:43 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rlBx5-0005yV-AL
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 18:06:43 +0000
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com
 [2a00:1450:4864:20::135])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c67f260a-e2f6-11ee-a1ee-f123f15fe8a2;
 Fri, 15 Mar 2024 19:06:41 +0100 (CET)
Received: by mail-lf1-x135.google.com with SMTP id
 2adb3069b0e04-512b3b04995so2456839e87.3
 for ; Fri, 15 Mar 2024 11:06:41 -0700 (PDT)
Received: from fedora.. ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id
 g29-20020a05651c079d00b002d0acb57c89sm568939lje.64.2024.03.15.11.06.39
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 15 Mar 2024 11:06:39 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c67f260a-e2f6-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1710526001; x=1711130801; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=3q9Kevm0ysXdIye4S89icXPKMHvBnA3fngdOD03ubxs=;
        b=Iq74BLtfGrsf2gCskT0hEVuSS4FwVNBq3ghwEnirz1Mi5LabtVLtX2QbqnSVptusyz
         suv/S101G+d8hN8khOCRPKx9N6o/bpG+rCtQhJWMV672qH/OLsvvYkd99maw17FLqzTK
         nTiHzbkurTqaFp3I/C9/KJDGdqcSx1ynuzHnzsGBXwnXXXDarbu78Z1XLeRZbsAUnCGr
         +OfomSCfrBL3lNNP8OvjZ0PU8dWwyCk6bdzI2yJ0i0pG3F4ZnCxRVY99nn78gokKXRs2
         /e0QXDRUr1X8v5n/W1Qo8momgA5Lk3JtkYFUFdAGi4+Pw+kgJe/QHzVLQ1H8zAW2Rz7+
         fT4g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710526001; x=1711130801;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=3q9Kevm0ysXdIye4S89icXPKMHvBnA3fngdOD03ubxs=;
        b=Y6qra6poisbD3HWSdMvgmREaH1jywVZuOSVCa8X9q21XyKzotB7wVAYEjGBdovMvPS
         L9Sq1HJqyACTy0Aaj64rlTavv1XBqO73qhDaHf2fa3u5QhmEIiZIHfU/C9z/CbDVIZSn
         r9ZGbiGdCgzmwAeg37Bei0ZSjO/kxjia+IHXRmmhttGDTi9O9Vd3IUQIaKlQN/9KGW8M
         Xc5E6zcd5m89zNBsacmc1ob5frv9Z6Aw+Ps8DqyBkuNEyVI/30tUxvz7iNm4Nh8XXehb
         aCCw9ZJ4tphC1nXIf4+JL1li7cvXlVJAb235sH453FQ/sE2pJUip1tVEITUbVdpDX/bv
         U8Zw==
X-Gm-Message-State: AOJu0YyYl9OYO4wZHl7gXgvndqIvY/gM9e+hc6txw7EVHYXjt+H37IrQ
	D7Ux5xAgyR+SIEgLeZBjPl0IsQb/79TjjMnRIJW3yQYkbmSAFbQefnyMDQw8/co=
X-Google-Smtp-Source: AGHT+IEyGwuKCc9hIOptFHiGUvhvmc90TnIxEm3YbdY725CwP5OdwU72CcTUtoABneeG2q2s9XkVlA==
X-Received: by 2002:a2e:7a02:0:b0:2d4:7218:4cf1 with SMTP id v2-20020a2e7a02000000b002d472184cf1mr2439140ljc.7.1710526000767;
        Fri, 15 Mar 2024 11:06:40 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini ,
	Wei Liu 
Subject: [PATCH v6 19/20] xen/riscv: enable full Xen build
Date: Fri, 15 Mar 2024 19:06:15 +0100
Message-ID: <153fbf8e0e85b6c5742979396aff30fa0be67ffb.1710517542.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Signed-off-by: Oleksii Kurochko 
Reviewed-by: Jan Beulich 
---
Changes in V5-V6:
 - Nothing changed. Only rebase.
---
Changes in V4:
 - drop stubs for irq_actor_none() and irq_actor_none() as common/irq.c is compiled now.
 - drop defintion of max_page in stubs.c as common/page_alloc.c is compiled now.
 - drop printk() related changes in riscv/early_printk.c as common version will be used.
---
Changes in V3:
 - Reviewed-by: Jan Beulich 
 - unrealted change dropped in tiny64_defconfig
---
Changes in V2:
 - Nothing changed. Only rebase.
---
 xen/arch/riscv/Makefile       |  16 +++-
 xen/arch/riscv/arch.mk        |   4 -
 xen/arch/riscv/early_printk.c | 168 ----------------------------------
 xen/arch/riscv/stubs.c        |  24 -----
 4 files changed, 15 insertions(+), 197 deletions(-)

diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile
index 60afbc0ad9..81b77b13d6 100644
--- a/xen/arch/riscv/Makefile
+++ b/xen/arch/riscv/Makefile
@@ -12,10 +12,24 @@ $(TARGET): $(TARGET)-syms
 	$(OBJCOPY) -O binary -S $< $@
 
 $(TARGET)-syms: $(objtree)/prelink.o $(obj)/xen.lds
-	$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds -N $< $(build_id_linker) -o $@
+	$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds -N $< \
+	    $(objtree)/common/symbols-dummy.o -o $(dot-target).0
+	$(NM) -pa --format=sysv $(dot-target).0 \
+		| $(objtree)/tools/symbols $(all_symbols) --sysv --sort \
+		> $(dot-target).0.S
+	$(MAKE) $(build)=$(@D) $(dot-target).0.o
+	$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds -N $< \
+	    $(dot-target).0.o -o $(dot-target).1
+	$(NM) -pa --format=sysv $(dot-target).1 \
+		| $(objtree)/tools/symbols $(all_symbols) --sysv --sort \
+		> $(dot-target).1.S
+	$(MAKE) $(build)=$(@D) $(dot-target).1.o
+	$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds -N $< $(build_id_linker) \
+	    $(dot-target).1.o -o $@
 	$(NM) -pa --format=sysv $@ \
 		| $(objtree)/tools/symbols --all-symbols --xensyms --sysv --sort \
 		> $@.map
+	rm -f $(@D)/.$(@F).[0-9]*
 
 $(obj)/xen.lds: $(src)/xen.lds.S FORCE
 	$(call if_changed_dep,cpp_lds_S)
diff --git a/xen/arch/riscv/arch.mk b/xen/arch/riscv/arch.mk
index da6f8c82eb..97ab935903 100644
--- a/xen/arch/riscv/arch.mk
+++ b/xen/arch/riscv/arch.mk
@@ -19,7 +19,3 @@ extensions := $(subst $(space),,$(extensions))
 # -mcmodel=medlow would force Xen into the lower half.
 
 CFLAGS += $(riscv-abi-y) -march=$(riscv-march-y)$(extensions) -mstrict-align -mcmodel=medany
-
-# TODO: Drop override when more of the build is working
-override ALL_OBJS-y = arch/$(SRCARCH)/built_in.o
-override ALL_LIBS-y =
diff --git a/xen/arch/riscv/early_printk.c b/xen/arch/riscv/early_printk.c
index 60742a042d..610c814f54 100644
--- a/xen/arch/riscv/early_printk.c
+++ b/xen/arch/riscv/early_printk.c
@@ -40,171 +40,3 @@ void early_printk(const char *str)
         str++;
     }
 }
-
-/*
- * The following #if 1 ... #endif should be removed after printk
- * and related stuff are ready.
- */
-#if 1
-
-#include 
-#include 
-
-/**
- * strlen - Find the length of a string
- * @s: The string to be sized
- */
-size_t (strlen)(const char * s)
-{
-    const char *sc;
-
-    for (sc = s; *sc != '\0'; ++sc)
-        /* nothing */;
-    return sc - s;
-}
-
-/**
- * memcpy - Copy one area of memory to another
- * @dest: Where to copy to
- * @src: Where to copy from
- * @count: The size of the area.
- *
- * You should not use this function to access IO space, use memcpy_toio()
- * or memcpy_fromio() instead.
- */
-void *(memcpy)(void *dest, const void *src, size_t count)
-{
-    char *tmp = (char *) dest, *s = (char *) src;
-
-    while (count--)
-        *tmp++ = *s++;
-
-    return dest;
-}
-
-int vsnprintf(char* str, size_t size, const char* format, va_list args)
-{
-    size_t i = 0; /* Current position in the output string */
-    size_t written = 0; /* Total number of characters written */
-    char* dest = str;
-
-    while ( format[i] != '\0' && written < size - 1 )
-    {
-        if ( format[i] == '%' )
-        {
-            i++;
-
-            if ( format[i] == '\0' )
-                break;
-
-            if ( format[i] == '%' )
-            {
-                if ( written < size - 1 )
-                {
-                    dest[written] = '%';
-                    written++;
-                }
-                i++;
-                continue;
-            }
-
-            /*
-             * Handle format specifiers.
-             * For simplicity, only %s and %d are implemented here.
-             */
-
-            if ( format[i] == 's' )
-            {
-                char* arg = va_arg(args, char*);
-                size_t arglen = strlen(arg);
-
-                size_t remaining = size - written - 1;
-
-                if ( arglen > remaining )
-                    arglen = remaining;
-
-                memcpy(dest + written, arg, arglen);
-
-                written += arglen;
-                i++;
-            }
-            else if ( format[i] == 'd' )
-            {
-                int arg = va_arg(args, int);
-
-                /* Convert the integer to string representation */
-                char numstr[32]; /* Assumes a maximum of 32 digits */
-                int numlen = 0;
-                int num = arg;
-                size_t remaining;
-
-                if ( arg < 0 )
-                {
-                    if ( written < size - 1 )
-                    {
-                        dest[written] = '-';
-                        written++;
-                    }
-
-                    num = -arg;
-                }
-
-                do
-                {
-                    numstr[numlen] = '0' + num % 10;
-                    num = num / 10;
-                    numlen++;
-                } while ( num > 0 );
-
-                /* Reverse the string */
-                for (int j = 0; j < numlen / 2; j++)
-                {
-                    char tmp = numstr[j];
-                    numstr[j] = numstr[numlen - 1 - j];
-                    numstr[numlen - 1 - j] = tmp;
-                }
-
-                remaining = size - written - 1;
-
-                if ( numlen > remaining )
-                    numlen = remaining;
-
-                memcpy(dest + written, numstr, numlen);
-
-                written += numlen;
-                i++;
-            }
-        }
-        else
-        {
-            if ( written < size - 1 )
-            {
-                dest[written] = format[i];
-                written++;
-            }
-            i++;
-        }
-    }
-
-    if ( size > 0 )
-        dest[written] = '\0';
-
-    return written;
-}
-
-void printk(const char *format, ...)
-{
-    static char buf[1024];
-
-    va_list args;
-    va_start(args, format);
-
-    (void)vsnprintf(buf, sizeof(buf), format, args);
-
-    early_printk(buf);
-
-    va_end(args);
-}
-
-#endif
-
diff --git a/xen/arch/riscv/stubs.c b/xen/arch/riscv/stubs.c
index 8285bcffef..bda35fc347 100644
--- a/xen/arch/riscv/stubs.c
+++ b/xen/arch/riscv/stubs.c
@@ -24,12 +24,6 @@ DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_core_mask);
 
 nodemask_t __read_mostly node_online_map = { { [0] = 1UL } };
 
-/*
- * max_page is defined in page_alloc.c which isn't complied for now.
- * definition of max_page will be remove as soon as page_alloc is built.
- */
-unsigned long __read_mostly max_page;
-
 /* time.c */
 
 unsigned long __ro_after_init cpu_khz;  /* CPU clock frequency in kHz. */
@@ -419,21 +413,3 @@ void __cpu_die(unsigned int cpu)
 {
     BUG_ON("unimplemented");
 }
-
-/*
- * The following functions are defined in common/irq.c, but common/irq.c isn't
- * built for now. These changes will be removed there when common/irq.c is
- * ready.
- */
-
-void cf_check irq_actor_none(struct irq_desc *desc)
-{
-    BUG_ON("unimplemented");
-}
-
-unsigned int cf_check irq_startup_none(struct irq_desc *desc)
-{
-    BUG_ON("unimplemented");
-
-    return 0;
-}
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Mar 15 18:08:16 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 18:08:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694006.1082854 (Exim 4.92)
	(envelope-from )
	id 1rlByW-0006TA-Sv; Fri, 15 Mar 2024 18:08:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694006.1082854; Fri, 15 Mar 2024 18:08:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rlByW-0006T3-Ou; Fri, 15 Mar 2024 18:08:12 +0000
Received: by outflank-mailman (input) for mailman id 694006;
 Fri, 15 Mar 2024 18:08:11 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rlByV-0006R8-Et; Fri, 15 Mar 2024 18:08:11 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rlByV-0000KT-6l; Fri, 15 Mar 2024 18:08:11 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rlByU-0003nB-OD; Fri, 15 Mar 2024 18:08:10 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rlByU-0008P6-NS; Fri, 15 Mar 2024 18:08:10 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=IfOeSQxn/kT/Iy+tzuw6Lq77GsSztYCqYSPCV4m7mWc=; b=AjAesQIraJgeJs51mjvvPG07hh
	oH2GbQfcLiFTJIxHnBxRt7thk0K4KgaO7gEBBQnn2eo5UHwhkiK/FlMv+dItfgUZZmaC6kyTaTzOG
	ly8LBOCA7zW3teBGb+60nnPtNACUKLcijvMsvaqB4zvY7e+YqbKXLDVGSdrP31rIKJWE=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [seabios test] 185050: tolerable FAIL - PUSHED
X-Osstest-Failures:
    seabios:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    seabios:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    seabios:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    seabios:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    seabios:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    seabios:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    seabios:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
X-Osstest-Versions-This:
    seabios=192e23b78418abc23a92a7174ae2294fabe4b8a3
X-Osstest-Versions-That:
    seabios=3722c21de19ba64de56495502c0c025b913a9b15
From: osstest service owner 
Date: Fri, 15 Mar 2024 18:08:10 +0000

flight 185050 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185050/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop            fail like 185005
 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop             fail like 185005
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 185005
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop            fail like 185005
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop             fail like 185005
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass

version targeted for testing:
 seabios              192e23b78418abc23a92a7174ae2294fabe4b8a3
baseline version:
 seabios              3722c21de19ba64de56495502c0c025b913a9b15

Last test of basis   185005  2024-03-12 14:43:08 Z    3 days
Testing same since   185050  2024-03-15 14:41:08 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Daniel Verkamp 
  Kevin O'Connor 

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-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/seabios.git
   3722c21..192e23b  192e23b78418abc23a92a7174ae2294fabe4b8a3 -> xen-tested-master


From xen-devel-bounces@lists.xenproject.org Fri Mar 15 18:08:40 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 18:08:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694015.1082864 (Exim 4.92)
	(envelope-from )
	id 1rlByy-0007ba-3h; Fri, 15 Mar 2024 18:08:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694015.1082864; Fri, 15 Mar 2024 18:08:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rlByy-0007bT-10; Fri, 15 Mar 2024 18:08:40 +0000
Received: by outflank-mailman (input) for mailman id 694015;
 Fri, 15 Mar 2024 18:08:39 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rlBwz-0005yW-Jv
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 18:06:37 +0000
Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com
 [2a00:1450:4864:20::234])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c3e151d9-e2f6-11ee-afdd-a90da7624cb6;
 Fri, 15 Mar 2024 19:06:37 +0100 (CET)
Received: by mail-lj1-x234.google.com with SMTP id
 38308e7fff4ca-2d2991e8c12so24710611fa.0
 for ; Fri, 15 Mar 2024 11:06:37 -0700 (PDT)
Received: from fedora.. ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id
 g29-20020a05651c079d00b002d0acb57c89sm568939lje.64.2024.03.15.11.06.35
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 15 Mar 2024 11:06:36 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c3e151d9-e2f6-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1710525996; x=1711130796; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=wGwnnOcdfjc412dCuO+CoJYBZrQqT9IXKc8hUkISo5w=;
        b=GYWiLymj8b71XsG5UDprKuxszNyOpcR5QN2LQ+qCrvjrem/Do+rbu5OSLQd0psXZUR
         CP+9NqQ3VU2jbXgeE2liy1Bd6h0pqbjtb4SBDiyKs6ZEdE+J7Mxp8xBsKXnQmSCvHb5U
         rcdXa4g9M/vO95PQ4VzVuDcy4cg4VHY5zXQKE9mgLrpG2+udvWeB+XsxIvf5kRYSyrY6
         fzZrccgChQOPSMusKbZ+8hAqadRkM1GTs1vl8yWLWWGA+m8pMIKO4JPAZUio1bUVNpND
         r170dru6Lhag0qTNTx2tZte6m2U4JuOz4Lc3XSpd0FVfJDOAtyB2rxv9GqrCd84Kj9Un
         pjiw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710525996; x=1711130796;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=wGwnnOcdfjc412dCuO+CoJYBZrQqT9IXKc8hUkISo5w=;
        b=GqbuQdjga1l2hcYCq+/n5nCrxBAOnUx2R9IVNkU+BX5Z+2lLCU9j78TP71uDu/gWfv
         /x1qVVkopz1CpKNfQpLo4EnWtw23FxLkLsjeJAFwCP5klhPWxZ/C+BoiIuEAL8i25uMZ
         s3M5aWT6KT/JctwkqOKPop7dkFghcnE6tf/vXT4Xepq6Xmak2kzHJuKRjgJlA+SRTAK1
         2u8v+yHuguNA1Un7x7rYOB+24JlIlPXaY4Xlu7EW6koobnTnXJj2sLYjzPzYYptHh3OG
         jKVGJo9q5Gl5ol+Zh7wcTBB8FyVAAmwtcOW1FiMtSwL3lqtPomt88HKvYELLqf2U4L6H
         gIww==
X-Gm-Message-State: AOJu0Yz6B5O+N3giOeWsPLEyc3V6InFbVGc4TMyudYj3VVxVXBzhZYXh
	75yRzY08UvxhDMEit93j5Fd97ebQ+eIiXWEPkE5Doi9zNKvhBN7dPOz/36TdU8Q=
X-Google-Smtp-Source: AGHT+IH1136Hxh9YX3kAguU8HRg8bx+XReQwyc0NeKRtp/KnUPvBeNTOzg7kdZsYU3Aibk5PrQOBug==
X-Received: by 2002:a2e:80d1:0:b0:2d4:9334:3c11 with SMTP id r17-20020a2e80d1000000b002d493343c11mr108037ljg.16.1710525996435;
        Fri, 15 Mar 2024 11:06:36 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini ,
	Wei Liu 
Subject: [PATCH v6 15/20] xen/riscv: add minimal stuff to processor.h to build full Xen
Date: Fri, 15 Mar 2024 19:06:11 +0100
Message-ID: 
X-Mailer: git-send-email 2.43.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

The cpu_relax() function, introduced in this commit, is anticipated to
support _zihintpause by the CPU.

Signed-off-by: Oleksii Kurochko 
---
Changes in V6:
 - drop incorrect part in riscv/booting.txt and move the introduction of it to
   separate patch.
 - compiler check that __riscv_zihintpause exist was droped to separate patch.
 - minor fixes.
 - drop unnecessary comment.
 - update the commit message.
---
Changes in V5:
 - Code style fixes.
 - drop introduced TOOLCHAIN_HAS_ZIHINTPAUSE and use as-insn instead and use
   as-insn istead.
---
Changes in V4:
 - Change message -> subject in "Changes in V3"
 - Documentation about system requirement was added. In the future, it can be checked if the extension is supported
   by system __riscv_isa_extension_available() ( https://gitlab.com/xen-project/people/olkur/xen/-/commit/737998e89ed305eb92059300c374dfa53d2143fa )
 - update cpu_relax() function to check if __riscv_zihintpause is supported by a toolchain
 - add conditional _zihintpause to -march if it is supported by a toolchain
Changes in V3:
 - update the commit subject
 - rename get_processor_id to smp_processor_id
 - code style fixes
 - update the cpu_relax instruction: use pause instruction instead of div %0, %0, zero
---
Changes in V2:
 - Nothing changed. Only rebase.
---
 xen/arch/riscv/include/asm/processor.h | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/xen/arch/riscv/include/asm/processor.h b/xen/arch/riscv/include/asm/processor.h
index 6db681d805..6846151717 100644
--- a/xen/arch/riscv/include/asm/processor.h
+++ b/xen/arch/riscv/include/asm/processor.h
@@ -12,6 +12,9 @@
 
 #ifndef __ASSEMBLY__
 
+/* TODO: need to be implemeted */
+#define smp_processor_id() 0
+
 /* On stack VCPU state */
 struct cpu_user_regs
 {
@@ -53,6 +56,23 @@ struct cpu_user_regs
     unsigned long pregs;
 };
 
+/* TODO: need to implement */
+#define cpu_to_core(cpu)   0
+#define cpu_to_socket(cpu) 0
+
+static inline void cpu_relax(void)
+{
+#ifdef __riscv_zihintpause
+    /* Reduce instruction retirement. */
+    __asm__ __volatile__ ( "pause" );
+#else
+    /* Encoding of the pause instruction */
+    __asm__ __volatile__ ( ".insn 0x0100000F" );
+#endif
+
+    barrier();
+}
+
 static inline void wfi(void)
 {
     __asm__ __volatile__ ("wfi");
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Mar 15 18:08:40 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 18:08:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694017.1082869 (Exim 4.92)
	(envelope-from )
	id 1rlByy-0007f0-E4; Fri, 15 Mar 2024 18:08:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694017.1082869; Fri, 15 Mar 2024 18:08:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rlByy-0007dz-8B; Fri, 15 Mar 2024 18:08:40 +0000
Received: by outflank-mailman (input) for mailman id 694017;
 Fri, 15 Mar 2024 18:08:39 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rlBwy-0005yW-Pt
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 18:06:36 +0000
Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com
 [2a00:1450:4864:20::22d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c35ef7e6-e2f6-11ee-afdd-a90da7624cb6;
 Fri, 15 Mar 2024 19:06:36 +0100 (CET)
Received: by mail-lj1-x22d.google.com with SMTP id
 38308e7fff4ca-2d46dd8b0b8so29375531fa.2
 for ; Fri, 15 Mar 2024 11:06:36 -0700 (PDT)
Received: from fedora.. ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id
 g29-20020a05651c079d00b002d0acb57c89sm568939lje.64.2024.03.15.11.06.34
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 15 Mar 2024 11:06:35 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c35ef7e6-e2f6-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1710525996; x=1711130796; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=+NcaJ1FDBCgUizy11pti52TjBeZ8r/7o9i/6uOLh9pE=;
        b=VUevo1mlyzsIjlX02nKe+Uzl+W04mhqolgcz1olCi9pbeW3cbYyoqh0gIwOL7sYGDh
         2reK5Hob875uGjVsno0OMl20HJYagZuNOIgdxvoavMnqeiZ5zkgD6OaGzi5uu8Rs2bhN
         6Hh087pvc+coaDV5jLEbNvIGCYpyAgd7DzOcUo3YHTSzw77+xmauYk8PUpmh8Yy+OIIi
         58AH6YMWIMACuQN2fZxfbgR/DxLjYIBDdwnl1uL1lqSP0kYWAdLqwlgc8XiasVOOl0ym
         l555KAdv5B0o4hvJu+HurhuDP0tEd3rGZCfMrlEbXpQxkyvNjAhbVePb4hcfO2mkzEcw
         Y4jw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710525996; x=1711130796;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=+NcaJ1FDBCgUizy11pti52TjBeZ8r/7o9i/6uOLh9pE=;
        b=SD0X0g2rWCum7I8bJaGP0txq0GxvIRZ2cjKpDpQlqQvB176r+6yLcB5+LTptrAlNPH
         Al2WNexckJLT/W19wFXOhUZ0z+IgbX+4UdlcUfXp2QK0cIra2xRdl80FVrTKJsiLSVCO
         jcbwQkpwj/pTLYNvN4V8p1vFDa3d+mEA2/YrRBETbzHNRTYuiW1qqh7BL8WlCSSSQnL3
         N0RiA7FRpD0MQvjudE0IMyzzuhb2gAhOdQElzUn8QwnDPgRDIGQ/1OHpeL3ax5Ghocqy
         UHJZOd539Jl87hK3Mf1wiTTpcxaqhjr3YvUudcrtAJ6qt0V62gV7fmj+LgwiXZy0Hr68
         5jQw==
X-Gm-Message-State: AOJu0YzCfjJ/NKV4sWMQ4H2TByRA3WAZLyQiTVyAbW4w/mV9ilamwysj
	I520RpSWBGIp9dZO8ekLYw7L4NHlzn/mwcpS/+xbGHehNsezLjYoFcjlrAwieU8=
X-Google-Smtp-Source: AGHT+IFUA3l0o9eYEyt5lnD3XT9b0AohpyxLIuldInNn5GFm49HJTE/aTML44nK1r1Z3YqeXQ9yXFw==
X-Received: by 2002:a2e:3c10:0:b0:2d4:64db:d661 with SMTP id j16-20020a2e3c10000000b002d464dbd661mr4275254lja.0.1710525995665;
        Fri, 15 Mar 2024 11:06:35 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini ,
	Wei Liu 
Subject: [PATCH v6 14/20] xen/riscv: add minimal stuff to page.h to build full Xen
Date: Fri, 15 Mar 2024 19:06:10 +0100
Message-ID: 
X-Mailer: git-send-email 2.43.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Signed-off-by: Oleksii Kurochko 
Acked-by: Jan Beulich 
---
Changes in V5-6:
 - Nothing changed. Only rebase.
---
Changes in V4:
---
 - Change message -> subject in "Changes in V3"
 - s/BUG/BUG_ON("...")
 - Do proper rebase ( pfn_to_paddr() and paddr_to_pfn() aren't removed ).
---
Changes in V3:
 - update the commit subject
 - add implemetation of PAGE_HYPERVISOR macros
 - add Acked-by: Jan Beulich 
 - drop definition of pfn_to_addr, and paddr_to_pfn in 
---
Changes in V2:
 - Nothing changed. Only rebase.
---
 xen/arch/riscv/include/asm/page.h | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/xen/arch/riscv/include/asm/page.h b/xen/arch/riscv/include/asm/page.h
index 95074e29b3..c831e16417 100644
--- a/xen/arch/riscv/include/asm/page.h
+++ b/xen/arch/riscv/include/asm/page.h
@@ -6,6 +6,7 @@
 #ifndef __ASSEMBLY__
 
 #include 
+#include 
 #include 
 
 #include 
@@ -32,6 +33,10 @@
 #define PTE_LEAF_DEFAULT            (PTE_VALID | PTE_READABLE | PTE_WRITABLE)
 #define PTE_TABLE                   (PTE_VALID)
 
+#define PAGE_HYPERVISOR_RW          (PTE_VALID | PTE_READABLE | PTE_WRITABLE)
+
+#define PAGE_HYPERVISOR             PAGE_HYPERVISOR_RW
+
 /* Calculate the offsets into the pagetables for a given VA */
 #define pt_linear_offset(lvl, va)   ((va) >> XEN_PT_LEVEL_SHIFT(lvl))
 
@@ -62,6 +67,20 @@ static inline bool pte_is_valid(pte_t p)
     return p.pte & PTE_VALID;
 }
 
+static inline void invalidate_icache(void)
+{
+    BUG_ON("unimplemented");
+}
+
+#define clear_page(page) memset((void *)(page), 0, PAGE_SIZE)
+#define copy_page(dp, sp) memcpy(dp, sp, PAGE_SIZE)
+
+/* TODO: Flush the dcache for an entire page. */
+static inline void flush_page_to_ram(unsigned long mfn, bool sync_icache)
+{
+    BUG_ON("unimplemented");
+}
+
 #endif /* __ASSEMBLY__ */
 
 #endif /* _ASM_RISCV_PAGE_H */
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Mar 15 18:09:40 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 18:09:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694025.1082884 (Exim 4.92)
	(envelope-from )
	id 1rlBzu-000138-QU; Fri, 15 Mar 2024 18:09:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694025.1082884; Fri, 15 Mar 2024 18:09:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rlBzu-000131-MG; Fri, 15 Mar 2024 18:09:38 +0000
Received: by outflank-mailman (input) for mailman id 694025;
 Fri, 15 Mar 2024 18:09:37 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rlBx0-0005yW-VK
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 18:06:39 +0000
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com
 [2a00:1450:4864:20::229])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c47dfafc-e2f6-11ee-afdd-a90da7624cb6;
 Fri, 15 Mar 2024 19:06:38 +0100 (CET)
Received: by mail-lj1-x229.google.com with SMTP id
 38308e7fff4ca-2d4698f4936so31764361fa.1
 for ; Fri, 15 Mar 2024 11:06:38 -0700 (PDT)
Received: from fedora.. ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id
 g29-20020a05651c079d00b002d0acb57c89sm568939lje.64.2024.03.15.11.06.36
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 15 Mar 2024 11:06:36 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c47dfafc-e2f6-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1710525997; x=1711130797; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=HdoViRZuiJfC8Md0ZiutQ7qpovpj785YpYdT8OnD9PY=;
        b=XqXiAtFAk8pjIQbYW5sFzJeSoeZ4CJT45P+X6+5zwS3gCjkfj70q8FaDftgI2ptI9H
         OEek/KGZpBjtZaj73MJIv4ADnG5KmsdJ7QBJbZbtpA+FrWMLcSDllZK/lhJTD2sT8CKJ
         qu2ua5PQUUVUPldUsDSSgxhlZcYBnowzAJPWBb3e0WQn3Mw8NWbXZdPtvGTq285SpEe/
         9NfRdBleg7VJEiatReyBkUxzHlfF95DPry5mphq3HN6cE8QumirUTfDu3fd/sEvu+NuS
         lW2MRysi3qqqUaJNISjEy2Hq5jD1J7k6PcNzA6VB5xPPaHDQuymHD0rSr/5ZJ3ZYXAGa
         Gfvw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710525997; x=1711130797;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=HdoViRZuiJfC8Md0ZiutQ7qpovpj785YpYdT8OnD9PY=;
        b=Ens6aYLKuWZev645JE/9+zRdwlAc5rwWtfOLH4PYs9TPT/2wW7mGdCghziX52nRIBe
         MJPAglyMtkDK5qCV/lwgyH+YKkLwUTI1OWjUIX0kkvSrKIlGEIXS1DsSOFHFwR/bGt24
         LTWssVRheOa+Irdz685JdOQH6pnHFI6MPALQnKmGQzrKleIoXSxIP0NyGIJnPTKwwX44
         RctY3DBtDEpPxJK1kpIVmv5NvDN9Bgv6B8vmoCUxhSVIfXeqj48BOcevyztLY9+kxwRz
         NTP0LjGalsGwkeqj5A0F4wPMyKi7tcxyrxtWrNxmCHK5KSj9mTEsKWVxFEf6MYseXia2
         2qTg==
X-Gm-Message-State: AOJu0YyKdXLm+/zwxFbssgJ7j5HMCUEa7spHfpaw05kupkUAOMufqhZb
	prmsEJvs81RmpsvWH8qc/Io6OodSILtWQrVawxg4DLDezkdAFMl0rzMeRneYIKg=
X-Google-Smtp-Source: AGHT+IEZ0+MpPvH1d/3yDH9rRZ9mkNXEDMbDHdKea6ohV5UxsXnm0xFHaeRaNyvFbatAIWMegQxqwA==
X-Received: by 2002:a2e:be09:0:b0:2d4:2508:7fe6 with SMTP id z9-20020a2ebe09000000b002d425087fe6mr4156796ljq.40.1710525997321;
        Fri, 15 Mar 2024 11:06:37 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini ,
	Wei Liu 
Subject: [PATCH v6 16/20] xen/riscv: add minimal stuff to mm.h to build full Xen
Date: Fri, 15 Mar 2024 19:06:12 +0100
Message-ID: <8d9c91cad5b548785780659599ea704f7fdba7a1.1710517542.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Signed-off-by: Oleksii Kurochko 
---
Changes in V6:
 - drop __virt_to_maddr() ( transform to macro ) and __maddr_to_virt ( rename to maddr_to_virt ).
 - parenthesize va in definition of vmap_to_mfn().
 - Code style fixes. 
---
Changes in V5:
 - update the comment around "struct domain *domain;" : zero -> NULL
 - fix ident. for unsigned long val;
 - put page_to_virt() and virt_to_page() close to each other.
 - drop unnessary leading underscore
 - drop a space before the comment: /* Count of uses of this frame as its current type. */
 - drop comment about a page 'not as a shadow'. it is not necessary for RISC-V
---
Changes in V4:
 - update an argument name of PFN_ORDERN macros.
 - drop pad at the end of 'struct page_info'.
 - Change message -> subject in "Changes in V3"
 - delete duplicated macros from riscv/mm.h
 - fix identation in struct page_info
 - align comment for PGC_ macros
 - update definitions of domain_set_alloc_bitsize() and domain_clamp_alloc_bitsize()
 - drop unnessary comments.
 - s/BUG/BUG_ON("...")
 - define __virt_to_maddr, __maddr_to_virt as stubs
 - add inclusion of xen/mm-frame.h for mfn_x and others
 - include "xen/mm.h" instead of "asm/mm.h" to fix compilation issues:
	 In file included from arch/riscv/setup.c:7:
	./arch/riscv/include/asm/mm.h:60:28: error: field 'list' has incomplete type
	   60 |     struct page_list_entry list;
	      |                            ^~~~
	./arch/riscv/include/asm/mm.h:81:43: error: 'MAX_ORDER' undeclared here (not in a function)
	   81 |                 unsigned long first_dirty:MAX_ORDER + 1;
	      |                                           ^~~~~~~~~
	./arch/riscv/include/asm/mm.h:81:31: error: bit-field 'first_dirty' width not an integer constant
	   81 |                 unsigned long first_dirty:MAX_ORDER + 1;
 - Define __virt_to_mfn() and __mfn_to_virt() using maddr_to_mfn() and mfn_to_maddr().
---
Changes in V3:
 - update the commit title
 - introduce DIRECTMAP_VIRT_START.
 - drop changes related pfn_to_paddr() and paddr_to_pfn as they were remvoe in
   [PATCH v2 32/39] xen/riscv: add minimal stuff to asm/page.h to build full Xen
 - code style fixes.
 - drop get_page_nr  and put_page_nr as they don't need for time being
 - drop CONFIG_STATIC_MEMORY related things
 - code style fixes
---
Changes in V2:
 - define stub for arch_get_dma_bitsize(void)
---
 xen/arch/riscv/include/asm/mm.h | 240 ++++++++++++++++++++++++++++++++
 xen/arch/riscv/mm.c             |   2 +-
 xen/arch/riscv/setup.c          |   2 +-
 3 files changed, 242 insertions(+), 2 deletions(-)

diff --git a/xen/arch/riscv/include/asm/mm.h b/xen/arch/riscv/include/asm/mm.h
index 07c7a0abba..c9fd456418 100644
--- a/xen/arch/riscv/include/asm/mm.h
+++ b/xen/arch/riscv/include/asm/mm.h
@@ -3,11 +3,246 @@
 #ifndef _ASM_RISCV_MM_H
 #define _ASM_RISCV_MM_H
 
+#include 
+#include 
+#include 
+#include 
+#include 
+
 #include 
 
 #define pfn_to_paddr(pfn) ((paddr_t)(pfn) << PAGE_SHIFT)
 #define paddr_to_pfn(pa)  ((unsigned long)((pa) >> PAGE_SHIFT))
 
+#define paddr_to_pdx(pa)    mfn_to_pdx(maddr_to_mfn(pa))
+#define gfn_to_gaddr(gfn)   pfn_to_paddr(gfn_x(gfn))
+#define gaddr_to_gfn(ga)    _gfn(paddr_to_pfn(ga))
+#define mfn_to_maddr(mfn)   pfn_to_paddr(mfn_x(mfn))
+#define maddr_to_mfn(ma)    _mfn(paddr_to_pfn(ma))
+#define vmap_to_mfn(va)     maddr_to_mfn(virt_to_maddr((vaddr_t)(va)))
+#define vmap_to_page(va)    mfn_to_page(vmap_to_mfn(va))
+
+static inline void *maddr_to_virt(unsigned long ma)
+{
+    BUG_ON("unimplemented");
+    return NULL;
+}
+
+#define virt_to_maddr(va) ({ BUG_ON("unimplemented"); 0; })
+
+/* Convert between Xen-heap virtual addresses and machine frame numbers. */
+#define __virt_to_mfn(va)  mfn_x(maddr_to_mfn(virt_to_maddr(va)))
+#define __mfn_to_virt(mfn) maddr_to_virt(mfn_to_maddr(_mfn(mfn)))
+
+/*
+ * We define non-underscored wrappers for above conversion functions.
+ * These are overriden in various source files while underscored version
+ * remain intact.
+ */
+#define virt_to_mfn(va)     __virt_to_mfn(va)
+#define mfn_to_virt(mfn)    __mfn_to_virt(mfn)
+
+struct page_info
+{
+    /* Each frame can be threaded onto a doubly-linked list. */
+    struct page_list_entry list;
+
+    /* Reference count and various PGC_xxx flags and fields. */
+    unsigned long count_info;
+
+    /* Context-dependent fields follow... */
+    union {
+        /* Page is in use: ((count_info & PGC_count_mask) != 0). */
+        struct {
+            /* Type reference count and various PGT_xxx flags and fields. */
+            unsigned long type_info;
+        } inuse;
+
+        /* Page is on a free list: ((count_info & PGC_count_mask) == 0). */
+        union {
+            struct {
+                /*
+                 * Index of the first *possibly* unscrubbed page in the buddy.
+                 * One more bit than maximum possible order to accommodate
+                 * INVALID_DIRTY_IDX.
+                 */
+#define INVALID_DIRTY_IDX ((1UL << (MAX_ORDER + 1)) - 1)
+                unsigned long first_dirty:MAX_ORDER + 1;
+
+                /* Do TLBs need flushing for safety before next page use? */
+                bool need_tlbflush:1;
+
+#define BUDDY_NOT_SCRUBBING    0
+#define BUDDY_SCRUBBING        1
+#define BUDDY_SCRUB_ABORT      2
+                unsigned long scrub_state:2;
+            };
+
+            unsigned long val;
+        } free;
+    } u;
+
+    union {
+        /* Page is in use */
+        struct {
+            /* Owner of this page (NULL if page is anonymous). */
+            struct domain *domain;
+        } inuse;
+
+        /* Page is on a free list. */
+        struct {
+            /* Order-size of the free chunk this page is the head of. */
+            unsigned int order;
+        } free;
+    } v;
+
+    union {
+        /*
+         * Timestamp from 'TLB clock', used to avoid extra safety flushes.
+         * Only valid for: a) free pages, and b) pages with zero type count
+         */
+        uint32_t tlbflush_timestamp;
+    };
+};
+
+#define frame_table ((struct page_info *)FRAMETABLE_VIRT_START)
+
+/* PDX of the first page in the frame table. */
+extern unsigned long frametable_base_pdx;
+
+/* Convert between machine frame numbers and page-info structures. */
+#define mfn_to_page(mfn)                                            \
+    (frame_table + (mfn_to_pdx(mfn) - frametable_base_pdx))
+#define page_to_mfn(pg)                                             \
+    pdx_to_mfn((unsigned long)((pg) - frame_table) + frametable_base_pdx)
+
+static inline void *page_to_virt(const struct page_info *pg)
+{
+    return mfn_to_virt(mfn_x(page_to_mfn(pg)));
+}
+
+/* Convert between Xen-heap virtual addresses and page-info structures. */
+static inline struct page_info *virt_to_page(const void *v)
+{
+    BUG_ON("unimplemented");
+    return NULL;
+}
+
+/*
+ * Common code requires get_page_type and put_page_type.
+ * We don't care about typecounts so we just do the minimum to make it
+ * happy.
+ */
+static inline int get_page_type(struct page_info *page, unsigned long type)
+{
+    return 1;
+}
+
+static inline void put_page_type(struct page_info *page)
+{
+}
+
+static inline void put_page_and_type(struct page_info *page)
+{
+    put_page_type(page);
+    put_page(page);
+}
+
+/*
+ * RISC-V does not have an M2P, but common code expects a handful of
+ * M2P-related defines and functions. Provide dummy versions of these.
+ */
+#define INVALID_M2P_ENTRY        (~0UL)
+#define SHARED_M2P_ENTRY         (~0UL - 1UL)
+#define SHARED_M2P(_e)           ((_e) == SHARED_M2P_ENTRY)
+
+#define set_gpfn_from_mfn(mfn, pfn) do { (void)(mfn), (void)(pfn); } while (0)
+#define mfn_to_gfn(d, mfn) ((void)(d), _gfn(mfn_x(mfn)))
+
+#define PDX_GROUP_SHIFT (PAGE_SHIFT + VPN_BITS)
+
+static inline unsigned long domain_get_maximum_gpfn(struct domain *d)
+{
+    BUG_ON("unimplemented");
+    return 0;
+}
+
+static inline long arch_memory_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg)
+{
+    BUG_ON("unimplemented");
+    return 0;
+}
+
+/*
+ * On RISCV, all the RAM is currently direct mapped in Xen.
+ * Hence return always true.
+ */
+static inline bool arch_mfns_in_directmap(unsigned long mfn, unsigned long nr)
+{
+    return true;
+}
+
+#define PG_shift(idx)   (BITS_PER_LONG - (idx))
+#define PG_mask(x, idx) (x ## UL << PG_shift(idx))
+
+#define PGT_none          PG_mask(0, 1)  /* no special uses of this page   */
+#define PGT_writable_page PG_mask(1, 1)  /* has writable mappings?         */
+#define PGT_type_mask     PG_mask(1, 1)  /* Bits 31 or 63.                 */
+
+/* Count of uses of this frame as its current type. */
+#define PGT_count_width   PG_shift(2)
+#define PGT_count_mask    ((1UL << PGT_count_width) - 1)
+
+/*
+ * Page needs to be scrubbed. Since this bit can only be set on a page that is
+ * free (i.e. in PGC_state_free) we can reuse PGC_allocated bit.
+ */
+#define _PGC_need_scrub   _PGC_allocated
+#define PGC_need_scrub    PGC_allocated
+
+/* Cleared when the owning guest 'frees' this page. */
+#define _PGC_allocated    PG_shift(1)
+#define PGC_allocated     PG_mask(1, 1)
+/* Page is Xen heap? */
+#define _PGC_xen_heap     PG_shift(2)
+#define PGC_xen_heap      PG_mask(1, 2)
+/* Page is broken? */
+#define _PGC_broken       PG_shift(7)
+#define PGC_broken        PG_mask(1, 7)
+/* Mutually-exclusive page states: { inuse, offlining, offlined, free }. */
+#define PGC_state         PG_mask(3, 9)
+#define PGC_state_inuse   PG_mask(0, 9)
+#define PGC_state_offlining PG_mask(1, 9)
+#define PGC_state_offlined PG_mask(2, 9)
+#define PGC_state_free    PG_mask(3, 9)
+#define page_state_is(pg, st) (((pg)->count_info&PGC_state) == PGC_state_##st)
+
+/* Count of references to this frame. */
+#define PGC_count_width   PG_shift(9)
+#define PGC_count_mask    ((1UL << PGC_count_width) - 1)
+
+#define _PGC_extra        PG_shift(10)
+#define PGC_extra         PG_mask(1, 10)
+
+#define is_xen_heap_page(page) ((page)->count_info & PGC_xen_heap)
+#define is_xen_heap_mfn(mfn) \
+    (mfn_valid(mfn) && is_xen_heap_page(mfn_to_page(mfn)))
+
+#define is_xen_fixed_mfn(mfn)                                   \
+    ((mfn_to_maddr(mfn) >= virt_to_maddr((vaddr_t)_start)) &&   \
+     (mfn_to_maddr(mfn) <= virt_to_maddr((vaddr_t)_end - 1)))
+
+#define page_get_owner(p)    (p)->v.inuse.domain
+#define page_set_owner(p, d) ((p)->v.inuse.domain = (d))
+
+/* TODO: implement */
+#define mfn_valid(mfn) ({ (void)(mfn); 0; })
+
+#define domain_set_alloc_bitsize(d) ((void)(d))
+#define domain_clamp_alloc_bitsize(d, b) ((void)(d), (b))
+
+#define PFN_ORDER(pfn) ((pfn)->v.free.order)
+
 extern unsigned char cpu0_boot_stack[];
 
 void setup_initial_pagetables(void);
@@ -20,4 +255,9 @@ unsigned long calc_phys_offset(void);
 
 void turn_on_mmu(unsigned long ra);
 
+static inline unsigned int arch_get_dma_bitsize(void)
+{
+    return 32; /* TODO */
+}
+
 #endif /* _ASM_RISCV_MM_H */
diff --git a/xen/arch/riscv/mm.c b/xen/arch/riscv/mm.c
index 053f043a3d..fe3a43be20 100644
--- a/xen/arch/riscv/mm.c
+++ b/xen/arch/riscv/mm.c
@@ -5,12 +5,12 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c
index 6593f601c1..98a94c4c48 100644
--- a/xen/arch/riscv/setup.c
+++ b/xen/arch/riscv/setup.c
@@ -2,9 +2,9 @@
 
 #include 
 #include 
+#include 
 
 #include 
-#include 
 
 /* Xen stack for bringing up the first CPU. */
 unsigned char __initdata cpu0_boot_stack[STACK_SIZE]
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Mar 15 18:09:46 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 18:09:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694033.1082893 (Exim 4.92)
	(envelope-from )
	id 1rlC01-0001VO-Vh; Fri, 15 Mar 2024 18:09:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694033.1082893; Fri, 15 Mar 2024 18:09:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rlC01-0001VH-Sy; Fri, 15 Mar 2024 18:09:45 +0000
Received: by outflank-mailman (input) for mailman id 694033;
 Fri, 15 Mar 2024 18:09:44 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rlBx5-0005yW-Ao
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 18:06:43 +0000
Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com
 [2a00:1450:4864:20::22b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c74b4bfc-e2f6-11ee-afdd-a90da7624cb6;
 Fri, 15 Mar 2024 19:06:42 +0100 (CET)
Received: by mail-lj1-x22b.google.com with SMTP id
 38308e7fff4ca-2d4698f4936so31765381fa.1
 for ; Fri, 15 Mar 2024 11:06:42 -0700 (PDT)
Received: from fedora.. ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id
 g29-20020a05651c079d00b002d0acb57c89sm568939lje.64.2024.03.15.11.06.40
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 15 Mar 2024 11:06:41 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c74b4bfc-e2f6-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1710526002; x=1711130802; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=jsMXEbuzvQgFJEn0K8X9h9yZxAaRur+Xb5WLOt3ikK8=;
        b=gePbBkmJGKQc7GUheasZf2LMvRMy9qzQAbCCtTpR6vS63ZhiMsuFVE+vhkJfHAFHUD
         8ZAlJ7jT/ylSclX+H8lLLDuP6fyRk4KHtqqyTLbU7YFfEO+ebsd/0ZYKFmTbUfTW0siU
         oX4BfaqFMCB89EEZ6CjKp/J9rdu8raPd3fz3D9TP92OuLK+6eItrEbR6N2qZP2nLXqBO
         t6PyhIyM0YXc7onWomajyNzqZFHBJUkNtgdAvQ8USE7mVgthHlpuGnIaKzC302DFaVTL
         wjV8vd4ODsPn0rBp5Kkc/oRWbDm/1NQVytFlrGvzgd7yafUxqgVH6ZPao8UsK7m6U0wv
         oLEQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710526002; x=1711130802;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=jsMXEbuzvQgFJEn0K8X9h9yZxAaRur+Xb5WLOt3ikK8=;
        b=YUUZgP6k+2NuldVj0iyCIOLEN05bNnpyhCzegobsuNjB2Cyy0kBTEOtcd+r2+5Y+yZ
         t2p4YP4+qOv0d5UwR9fXt3/v0+HKA+WLfkfLLSF0FyDT6hBdbbwl0mdQHchOWbO7fiUZ
         vKExxoHERw8UqTXTJBhw7SAZDsY8l1gN/u8X4wg55Y4gD+PpbMfb5nKffENJLoOlFmpH
         FsxyQL5ZccabRxV8B7qb64me+3YAI6TjCJMQIwfhQThY2hPX8NTgb2yg9lD92Lolk5Rl
         EMszOGyH9ZTvh6AEzdeMWfoTP0d3A/X+M909L4w8mDclF5Jl73e6KvJ8ikINJnn7AVG4
         Zebw==
X-Gm-Message-State: AOJu0YzifmZR7nrh8iUrdmMOdHMaahbsg0bB9Og5MArfBoFE5w1apViW
	9313EfU4NREMyeYnY6t89LK7wFM5UzCKyLQd9h2BGwlHN3efuT2DVmzlDCw0x/w=
X-Google-Smtp-Source: AGHT+IE9dXphkeMbJR8ERhFEV7xr9bENpzyXUz8rXvndWu6/JOiC/7cONEq9zSxMkFaOAq+Cvy7U9Q==
X-Received: by 2002:a2e:8806:0:b0:2d4:3c32:814d with SMTP id x6-20020a2e8806000000b002d43c32814dmr4122685ljh.26.1710526001704;
        Fri, 15 Mar 2024 11:06:41 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini ,
	Wei Liu 
Subject: [PATCH v6 20/20] xen/README: add compiler and binutils versions for RISC-V64
Date: Fri, 15 Mar 2024 19:06:16 +0100
Message-ID: <6bbbc11bc16f31ee8b2a5f47405c61236c97d205.1710517542.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

This patch doesn't represent a strict lower bound for GCC and
GNU Binutils; rather, these versions are specifically employed by
the Xen RISC-V container and are anticipated to undergo continuous
testing. Older GCC and GNU Binutils would work,
but this is not a guarantee.

While it is feasible to utilize Clang, it's important to note that,
currently, there is no Xen RISC-V CI job in place to verify the
seamless functioning of the build with Clang.

Signed-off-by: Oleksii Kurochko 
---
 Changes in V6:
  - update the message in README.
---
 Changes in V5:
  - update the commit message and README file with additional explanation about GCC and
    GNU Binutils version. Additionally, it was added information about Clang.
---
 Changes in V4:
  - Update version of GCC (12.2) and GNU Binutils (2.39) to the version
    which are in Xen's contrainter for RISC-V
---
 Changes in V3:
  - new patch
---
 README | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/README b/README
index c8a108449e..30da5ff9c0 100644
--- a/README
+++ b/README
@@ -48,6 +48,10 @@ provided by your OS distributor:
       - For ARM 64-bit:
         - GCC 5.1 or later
         - GNU Binutils 2.24 or later
+      - For RISC-V 64-bit:
+        - GCC 12.2 or later
+        - GNU Binutils 2.39 or later
+          Older GCC and GNU Binutils would work, but this is not a guarantee.
     * POSIX compatible awk
     * Development install of zlib (e.g., zlib-dev)
     * Development install of Python 2.7 or later (e.g., python-dev)
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Mar 15 19:10:25 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 19:10:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694061.1082903 (Exim 4.92)
	(envelope-from )
	id 1rlCwQ-0000mA-AE; Fri, 15 Mar 2024 19:10:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694061.1082903; Fri, 15 Mar 2024 19:10:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rlCwQ-0000m3-6c; Fri, 15 Mar 2024 19:10:06 +0000
Received: by outflank-mailman (input) for mailman id 694061;
 Fri, 15 Mar 2024 19:10:04 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1rlCwO-0000Xq-Pc
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 19:10:04 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rlCwG-0001t9-9C; Fri, 15 Mar 2024 19:09:56 +0000
Received: from gw1.octic.net ([88.97.20.152] helo=[10.0.1.240])
 by xenbits.xenproject.org with esmtpsa
 (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92)
 (envelope-from )
 id 1rlCwF-0002bE-Vt; Fri, 15 Mar 2024 19:09:56 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=sgnd/LKnDObv7oG77bNP0S+oSMGArRJNgYRVwHSnbuY=; b=vCMmw7XOwCEXrxij6G56PisUrj
	PlSi4yft4Ez/QfrSNQcEe4H1svO+vd5vp4KYrl0owI9F+NH5jk4mgf6VR/GW6dQRgkPHRzf3qMdT5
	+Nf8KqwMWNKM0W2DACJc5w6EeYSK8N+IA3+HN5pLhRfUHBi0SA+PH/M6QhgO9VR9uIXM=;
Message-ID: <3914ac5b-2088-4b91-bd34-8a2c52c2c816@xen.org>
Date: Fri, 15 Mar 2024 19:09:54 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 4/8] Arm: annotate entry points with type and size
Content-Language: en-GB
To: Jan Beulich ,
 Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel 
Cc: Volodymyr Babchuk ,
 George Dunlap ,
 "xen-devel@lists.xenproject.org" 
References: 
 <7a133ed9-9d13-4e2c-893a-00c083c8a35d@suse.com>
 <7871702a-b5ca-4430-b282-148b46fccc71@suse.com>
 <362fb92c-98a9-4ec8-a715-cebbc5321b36@suse.com>
From: Julien Grall 
In-Reply-To: <362fb92c-98a9-4ec8-a715-cebbc5321b36@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Jan,

On 22/01/2024 13:22, Jan Beulich wrote:
> On 15.01.2024 15:36, Jan Beulich wrote:
>> Use the generic framework in xen/linkage.h. No change in generated code
>> except for the changed padding value (noticable when config.gz isn't a
>> multiple of 4 in size). Plus of course the converted symbols change to
>> be hidden ones.
>>
>> Note that ASM_INT() is switched to DATA(), not DATA_LOCAL(), as the only
>> use site wants the symbol global anyway.
>>
>> Signed-off-by: Jan Beulich 
>> Reviewed-by: Julien Grall 
>> ---
>> Only one each of the assembly files is being converted for now. More
>> could be done right here or as follow-on in separate patches.
> 
> As this was meanwhile committed, I'd like to understand you preference
> for further conversion steps: I can certainly see to find time to make
> some actual progress here, but it might also be that you prefer to do
> so yourself. Please let me know.

Sorry for the late reply. I will have a look.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Fri Mar 15 19:57:17 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 19:57:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694068.1082920 (Exim 4.92)
	(envelope-from )
	id 1rlDfy-00026m-Pk; Fri, 15 Mar 2024 19:57:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694068.1082920; Fri, 15 Mar 2024 19:57:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rlDfy-00026f-MA; Fri, 15 Mar 2024 19:57:10 +0000
Received: by outflank-mailman (input) for mailman id 694068;
 Fri, 15 Mar 2024 19:57:09 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rlDfx-00026Z-NX
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 19:57:09 +0000
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com
 [2a00:1450:4864:20::135])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 33bd6dce-e306-11ee-a1ee-f123f15fe8a2;
 Fri, 15 Mar 2024 20:57:07 +0100 (CET)
Received: by mail-lf1-x135.google.com with SMTP id
 2adb3069b0e04-513cf9bacf1so3155873e87.0
 for ; Fri, 15 Mar 2024 12:57:07 -0700 (PDT)
Received: from andrewcoop.citrite.net (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 l23-20020a170906645700b00a4655513f0bsm1965229ejn.88.2024.03.15.12.57.05
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 15 Mar 2024 12:57:05 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 33bd6dce-e306-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710532626; x=1711137426; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:from:to:cc:subject:date:message-id:reply-to;
        bh=O0ApqtLjzIi/04P3O2hgcnVwq8obyxxKEIjVNeGVDjY=;
        b=SyL0KLwDcGl1A4VCiDzIPMhqbOQUEQZ0c48JEx7pH90x96vLfDe9BrJDo3DJ9q2K5M
         KsSYg+4iNW/JxUv0DFWXrLHcdOSsoUDxJX8BOHRcKeIEkA1w7t07faUZMYru73Mh2R1w
         dzUkN7k1S4zJWBAdQYgYKyzp8YqCwt9Dclwqc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710532626; x=1711137426;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=O0ApqtLjzIi/04P3O2hgcnVwq8obyxxKEIjVNeGVDjY=;
        b=gWJyh3Nt+6jPvmVWuuUJTZm7y/Nar8PInbSOXwDIGzEA9QGWmh4fjYgkA5kFtJESkh
         tfaH23RUpbJxO8t2NOGRZ03DxAisaOOdkx7jbnzni8HGPbneikKrmTaxJH2rZYwB8D+f
         w2HXPop9GTGpkxm6pSNMQaju0vW0PawcWeujErDto6PB/9CWI4NJYFBUFihniJh9Jrq4
         9IpVuLVqPeqG6QV6Y44Ybjfr0IBoAv34cNF2GrA3O+e0DwY+T1AF3p2oLQt4f/CvHFwf
         uMI+qmlRlSRdXP9C8LY01EK4tV2ISfayDkGuECYseU0TaxrsrYYmVfRUayVVQpS5p4bM
         H7DA==
X-Gm-Message-State: AOJu0YziMmM+woYIuuFKq9cwteP8j36ncFCu3gS2pSoaqUpZ48bsqOL0
	a4BVkpKQzZbsln7D5VWOxBtu0XSjmz8kgTbq+CtlZNKGTGhYBE6mCvsjzgMlmvq/vpvz3IpL1hj
	y
X-Google-Smtp-Source: AGHT+IEwIdKSm+GJyLllXTuzToT1RkzdjTCcEC7XXEQW2g9x6/OTLRo03IcG38JHfZFOI56vBo2SiA==
X-Received: by 2002:ac2:4258:0:b0:513:fad:3a79 with SMTP id m24-20020ac24258000000b005130fad3a79mr2859499lfl.41.1710532625936;
        Fri, 15 Mar 2024 12:57:05 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Wei Liu 
Subject: [PATCH] x86/boot: Improve the boot watchdog determination of stuck cpus
Date: Fri, 15 Mar 2024 19:57:04 +0000
Message-Id: <20240315195704.3423282-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.30.2
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Right now, check_nmi_watchdog() has two processing loops over all online CP=
Us
using prev_nmi_count as storage.

Use a cpumask_t instead (1/32th as much initdata) and have wait_for_nmis()
make the determination of whether it is stuck, rather than having both
functions needing to agree on how many ticks mean stuck.

More importantly though, it means we can use the standard cpumask
infrastructure, including turning this:

  (XEN) Brought up 512 CPUs
  (XEN) Testing NMI watchdog on all CPUs: {0,1,2,3,4,5,6,7,8,9,10,11,12,13,=
14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,=
39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,=
64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,=
89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,11=
0,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128,1=
29,130,131,132,133,134,135,136,137,138,139,140,141,142,143,144,145,146,147,=
148,149,150,151,152,153,154,155,156,157,158,159,160,161,162,163,164,165,166=
,167,168,169,170,171,172,173,174,175,176,177,178,179,180,181,182,183,184,18=
5,186,187,188,189,190,191,192,193,194,195,196,197,198,199,200,201,202,203,2=
04,205,206,207,208,209,210,211,212,213,214,215,216,217,218,219,220,221,222,=
223,224,225,226,227,228,229,230,231,232,233,234,235,236,237,238,239,240,241=
,242,243,244,245,246,247,248,249,250,251,252,253,254,255,256,257,258,259,26=
0,261,262,263,264,265,266,267,268,269,270,271,272,273,274,275,276,277,278,2=
79,280,281,282,283,284,285,286,287,288,289,290,291,292,293,294,295,296,297,=
298,299,300,301,302,303,304,305,306,307,308,309,310,311,312,313,314,315,316=
,317,318,319,320,321,322,323,324,325,326,327,328,329,330,331,332,333,334,33=
5,336,337,338,339,340,341,342,343,344,345,346,347,348,349,350,351,352,353,3=
54,355,356,357,358,359,360,361,362,363,364,365,366,367,368,369,370,371,372,=
373,374,375,376,377,378,379,380,381,382,383,384,385,386,387,388,389,390,391=
,392,393,394,395,396,397,398,399,400,401,402,403,404,405,406,407,408,409,41=
0,411,412,413,414,415,416,417,418,419,420,421,422,423,424,425,426,427,428,4=
29,430,431,432,433,434,435,436,437,438,439,440,441,442,443,444,445,446,447,=
448,449,450,451,452,453,454,455,456,457,458,459,460,461,462,463,464,465,466=
,467,468,469,470,471,472,473,474,475,476,477,478,479,480,481,482,483,484,48=
5,486,487,488,489,490,491,492,493,494,495,496,497,498,499,500,501,502,503,5=
04,505,506,507,508,509,510,511} stuck

into the rather more manageable:

  (XEN) Brought up 512 CPUs
  (XEN) Testing NMI watchdog on all CPUs: {0-511} stuck

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monn=C3=A9 
CC: Wei Liu 
---
 xen/arch/x86/nmi.c | 35 ++++++++++++++---------------------
 1 file changed, 14 insertions(+), 21 deletions(-)

diff --git a/xen/arch/x86/nmi.c b/xen/arch/x86/nmi.c
index 633dc59bf830..8994c50cb5e4 100644
--- a/xen/arch/x86/nmi.c
+++ b/xen/arch/x86/nmi.c
@@ -151,6 +151,8 @@ static int nmi_active;
=20
 static void __init cf_check wait_for_nmis(void *p)
 {
+    cpumask_t *stuck_cpus =3D p;
+    unsigned int cpu =3D smp_processor_id();
     unsigned int start_count =3D this_cpu(nmi_count);
     unsigned long ticks =3D 10 * 1000 * cpu_khz / nmi_hz;
     unsigned long s, e;
@@ -159,44 +161,35 @@ static void __init cf_check wait_for_nmis(void *p)
     do {
         cpu_relax();
         if ( this_cpu(nmi_count) >=3D start_count + 2 )
-            break;
+            return;
+
         e =3D rdtsc();
-    } while( e - s < ticks );
+    } while ( e - s < ticks );
+
+    /* Timeout.  Mark ourselves as stuck. */
+    cpumask_set_cpu(cpu, stuck_cpus);
 }
=20
 void __init check_nmi_watchdog(void)
 {
-    static unsigned int __initdata prev_nmi_count[NR_CPUS];
-    unsigned int cpu;
-    char sep =3D '{';
-    bool ok =3D true;
+    static cpumask_t __initdata stuck_cpus;
=20
     if ( nmi_watchdog =3D=3D NMI_NONE )
         return;
=20
     printk("Testing NMI watchdog on all CPUs: ");
=20
-    for_each_online_cpu ( cpu )
-        prev_nmi_count[cpu] =3D per_cpu(nmi_count, cpu);
-
     /*
      * Wait at most 10 ticks for 2 watchdog NMIs on each CPU.
      * Busy-wait on all CPUs: the LAPIC counter that the NMI watchdog
      * uses only runs while the core's not halted
      */
-    on_selected_cpus(&cpu_online_map, wait_for_nmis, NULL, 1);
+    on_selected_cpus(&cpu_online_map, wait_for_nmis, &stuck_cpus, 1);
=20
-    for_each_online_cpu ( cpu )
-    {
-        if ( per_cpu(nmi_count, cpu) - prev_nmi_count[cpu] < 2 )
-        {
-            printk("%c%u", sep, cpu);
-            sep =3D ',';
-            ok =3D false;
-        }
-    }
-
-    printk("%s\n", ok ? "ok" : "} stuck");
+    if ( cpumask_empty(&stuck_cpus) )
+        printk("ok\n");
+    else
+        printk("{%*pbl} stuck\n", CPUMASK_PR(&stuck_cpus));
=20
     /*
      * Now that we know it works we can reduce NMI frequency to

base-commit: d638e304f13a5ef7d125de5ace5f7828a7b25bac
--=20
2.30.2



From xen-devel-bounces@lists.xenproject.org Fri Mar 15 19:57:17 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 19:57:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694069.1082929 (Exim 4.92)
	(envelope-from )
	id 1rlDg5-0002MP-2a; Fri, 15 Mar 2024 19:57:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694069.1082929; Fri, 15 Mar 2024 19:57:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rlDg5-0002MG-04; Fri, 15 Mar 2024 19:57:17 +0000
Received: by outflank-mailman (input) for mailman id 694069;
 Fri, 15 Mar 2024 19:57:15 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rlDg3-0002LY-AJ; Fri, 15 Mar 2024 19:57:15 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rlDg3-000307-57; Fri, 15 Mar 2024 19:57:15 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rlDg2-0002hF-RG; Fri, 15 Mar 2024 19:57:14 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rlDg2-0003kn-Qo; Fri, 15 Mar 2024 19:57:14 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=D+7d/AAmrdoZidh8ZNQVrdzey/19gKhEwg6RM7tl3aQ=; b=7Ici54s0utsJ4dfyacmI3Uz64R
	+TcfT4DgVm8YuSAxIesImGY699j1r4V4YbFdcJuG8jT2C+EgwLn033+qc9GYlDT0/pm0zDW75n1Wu
	pmrNkS2IX7IU84aP5VBgkvDg+xcNPfTIU+aPZK8cxpRPYcuZglfLfxj2Qf/BHY839YNw=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 185046: tolerable FAIL - PUSHED
X-Osstest-Failures:
    linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    linux=e5eb28f6d1afebed4bb7d740a797d0390bd3a357
X-Osstest-Versions-That:
    linux=e5e038b7ae9da96b93974bf072ca1876899a01a3
From: osstest service owner 
Date: Fri, 15 Mar 2024 19:57:14 +0000

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

Failures :-/ but no regressions.

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

version targeted for testing:
 linux                e5eb28f6d1afebed4bb7d740a797d0390bd3a357
baseline version:
 linux                e5e038b7ae9da96b93974bf072ca1876899a01a3

Last test of basis   185023  2024-03-14 00:14:57 Z    1 days
Failing since        185040  2024-03-14 19:00:47 Z    1 days    2 attempts
Testing same since   185046  2024-03-15 08:44:39 Z    0 days    1 attempts

------------------------------------------------------------
728 people touched revisions under test,
not listing them all

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-freebsd11-amd64                             pass    
 test-amd64-amd64-freebsd12-amd64                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-libvirt-qcow2                               pass    
 test-armhf-armhf-libvirt-qcow2                               pass    
 test-amd64-amd64-libvirt-raw                                 pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-amd64-xl-vhd                                      pass    
 test-arm64-arm64-xl-vhd                                      pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

Explanation of these 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 :

hint: The 'hooks/update' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
hint: The 'hooks/post-receive' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
hint: The 'hooks/post-update' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
To xenbits.xen.org:/home/xen/git/linux-pvops.git
   e5e038b7ae9d..e5eb28f6d1af  e5eb28f6d1afebed4bb7d740a797d0390bd3a357 -> tested/linux-linus


From xen-devel-bounces@lists.xenproject.org Fri Mar 15 23:33:24 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 23:33:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694093.1082943 (Exim 4.92)
	(envelope-from )
	id 1rlH2u-00071r-Ty; Fri, 15 Mar 2024 23:33:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694093.1082943; Fri, 15 Mar 2024 23:33:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rlH2u-00071k-R8; Fri, 15 Mar 2024 23:33:04 +0000
Received: by outflank-mailman (input) for mailman id 694093;
 Fri, 15 Mar 2024 23:33:03 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rlH2t-00071e-Kd
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 23:33:03 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5b75cb2d-e324-11ee-a1ee-f123f15fe8a2;
 Sat, 16 Mar 2024 00:32:59 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 2FEAA61807;
 Fri, 15 Mar 2024 23:32:58 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id F075BC433C7;
 Fri, 15 Mar 2024 23:32:55 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5b75cb2d-e324-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1710545577;
	bh=H/x2lLzI8P6R+NSkHS4VduyzdzVjwtYv/SKm4YvtS8w=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=Xg/egQJ5VPGfHWaPfbjkASUQgd5veABTLT8iDrq3nNqwxvhIK0uT3oLRuFcWxVxJb
	 UppGiDpf4Kbss+O3NEXXaAh9dmvniW+Fp/npU6CbXdKomTwTuNN+E1MRUWre0Y19PB
	 mx+J3+IwdnTzUOWFBIg3hotaP8H2+hGQkkDA+Ahwslm2gJbI9iwhYgVBk2n55Xhb9S
	 EMl0yjDc5BFtMKv4SxPzV+HpnSAGJbY3/hsIan66jomGxcpbFGapNJlZsUR6E4UBhk
	 sOng1+6AiasIrz7y7WQjDyhxsmr2T5d6MlPCgp6nCguBBi50keFRUp8t0MZGuTrhLz
	 iOeRc53lVC1Ng==
Date: Fri, 15 Mar 2024 16:32:53 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: LARRIEU Dominique 
cc: Julien Grall , 
    GOURLOT Francois , 
    GRUO Nicolas , 
    Cc , Kelly Choi , 
    Jan Beulich , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Andrew Cooper , 
    George Dunlap , Juergen Gross , 
    WILLEMS Louis , vikram.garhwal@amd.com, 
    Edgar.Iglesias@amd.com, sstabellini@kernel.org
Subject: RE: IMPORTANT - : Need help on USB port virtualization with Xen
 hypervisor
In-Reply-To: <2e53bd839f904d8a97ee5645ee9e9361@thalesgroup.com>
Message-ID: 
References:    <427d2ecb865648b7a459c592c208c0be@thalesgroup.com> <673b2bc630d748e8af0a15d4b553906e@thalesgroup.com>
 <3ee3659afff645cabed86bcc22c44686@thalesgroup.com> <4778822e-582f-4e0d-9933-86d8d49ea3a5@xen.org> <8f2a2bbaf29e41709eeab695efe48f17@thalesgroup.com>  <2e53bd839f904d8a97ee5645ee9e9361@thalesgroup.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="8323329-1892190326-1710544158=:853156"
Content-ID: 

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-1892190326-1710544158=:853156
Content-Type: text/plain; CHARSET=UTF-8
Content-Transfer-Encoding: 8BIT
Content-ID: 

Hi Dominique,

You posted this configuration:

device_model_args = [ "
                      "-device","nec-usb-xhci,id=xhci",
                      "-device","usb-host,bus=xhci.0,hostbus=1,hostport=13",
                      "-device","usb-host,bus=xhci.0,hostbus=1,hostport=10",
                      "-device","usb-host,bus=xhci.0,hostbus=1,hostport=2",
                      "-device","usb-host,bus=xhci.0,hostbus=2,hostport=2",
                      "-device","usb-host,bus=xhci.0,hostbus=2,hostport=1",
                      "-device","usb-host,bus=xhci.0,hostbus=1,hostport=1"]

It looks like you are using QEMU-based USB passthrough. Basically QEMU
(independently from Xen) is accessing the USB device in Dom0 and
exposing a corresponding device to the guest. I am not sure if there is
anything that can be done in QEMU to support USB 3.0 with high speed,
people in CC might know.

There two other alternatives to this approach. You can use PV USB
Passthrough instead. Juergen (CCed) is the original author. I am not
sure if that supports USB 3.0 either.

Finally, you can directly assign the entire USB Controller to the guest
using PCI Passthrough: assign the whole USB Controller, with all the USB
devices connect to it, as a PCI device to the guest. For sure, if this
approach is OK for you, it will lead to the best performance.

Cheers,

Stefano



On Thu, 14 Mar 2024, LARRIEU Dominique wrote:
> Hi Julien,
> 
>  
> 
> You will find here above the answers to your questions.
> 
>  
> 
> Thank you very much for your help.
> 
>  
> 
> Best regards,
> 
> Dominique
> 
>  
> 
>  
> 
>  
> 
> -----Message d'origine-----
> De : Julien Grall 
> Envoyé : jeudi 29 février 2024 12:52
> À : LARRIEU Dominique 
> Cc : GOURLOT Francois ; GRUO Nicolas ; Cc
> ; Kelly Choi ; Jan Beulich ; Roger Pau Monné
> ; Andrew Cooper ; George Dunlap ; Juergen Gross
> ; WILLEMS Louis 
> Objet : Re: IMPORTANT - : Need help on USB port virtualization with Xen hypervisor
> 
>  
> 
> Hi Dominique,
> 
>  
> 
> On 29/02/2024 10:33, LARRIEU Dominique wrote:
> 
> > Thank you for your quick answer.
> 
> >
> 
> > You will find below our answers (in red) to your questions.
> 
> >
> 
> > To summarize our request : what we would like is to use USB 3.0 driver with high speed configuration.
> 
> > Today, it is not possible to do that.
> 
> > The driver stay in full speed mode, and more often in USB 1.0 or 2.0 configuration.
> 
> >
> 
> > Is it possible to configure the XEN USB 3.0 driver with the high speed mode ?
> 
> > (read in our answers below the reference to the driver)
> 
>  
> 
> Looking at what you provided below, it is still unclear what you mean by "Xen USB 3.0 driver". By any chance, are you confused with the "x"
> in xhci?
> 
>  
> 
> The drivers "xhci_hcd" and "xhci_pci" are generic and not provided/maintained by Xen. So far, with the information provided, it is unclear
> whether the problem is actually in the driver itself. I have a few more questions. See below.
> 
>  
> 
> >>      We are detecting several issues with USB port virtualization
> 
> >> with the
> 
> >
> 
> >>      Xen hypervisor.
> 
> >
> 
> >
> 
> >
> 
> > Just to clarify, you are assigning the PCI USB bus (rather than just the USB device) to the guest. Is that correct?
> 
> >
> 
> >
> 
> >
> 
> > If so...
> 
> >
> 
> >
> 
> >
> 
> > [Thales] : we are using the USB chipset of the mother board (see below
> 
> > the references)
> 
>  
> 
> Thanks for the clarification. IIUC, you said you are having problem in the guest itself. Have you tried to access the same USB device from
> dom0? Or better without any Xen involved (i.e. booting Debian on baremetal).
> 
>  
> 
> This would help to narrow down the issue.
> 
>  
> 
> [Thales, 14/03/24] We have no difficulty accessing the USB device on the dom0
> 
>  
> 
> >> 
> 
> >
> 
> >>      We needyour helpto find a solution for these problems.
> 
> >
> 
> >> 
> 
> >
> 
> >>      The Software used are :
> 
> >
> 
> >
> 
> >
> 
> > Can you share some details of the HW you are using ?
> 
> >
> 
> >
> 
> >
> 
> > [Thales] : HW :
> 
> >
> 
> > [Thales] : We are using a GETAC X500 using the Mobile Intel QM175
> 
> > Chipset
> 
> >
> 
> > [Thales] : USB controller: Intel Corporation 100 Series/C230 Series
> 
> > Chipset Family USB 3.0 xHCI Controller (rev 31)
> 
> >
> 
> > [Thales] : Subsystem: Mitac 100 Series/C230 Series Chipset Family USB
> 
> > 3.0 xHCI Controller
> 
> >
> 
> >
> 
> >
> 
> > [Thales] : SW :
> 
> >
> 
> > [Thales] : Kernel driver in use: xhci_hcd
> 
> >
> 
> > [Thales] : Kernel modules : xhci_pci
> 
> >
> 
> >
> 
> >
> 
> >> 
> 
> >
> 
> >>      -Debian 11 version5.10.0-20
> 
>  
> 
> IIUC, before you said you had problem with Windows. So is this the software in dom0? Or did you actually try with Debian and still see the
> same issue?
> 
> [Thales, 14/03/24] We are not sure to understand the question. The information we provided to you was the modules on the dom0. The driver
> which is back on the dom guest Windows: controleur hote ReunesasUSB 3.0 extensible
> 
>  
> 
> Regarding the configuration, given you are using the official Debian package. Are you using 'xl' to create your guest?
> 
> [Thales, 14/03/24] yes we do
> 
>  
> 
> The ideal would be if you can paste the full configuration. If you can't can you tell us if you are using any of these options: 'pci',
> 'usbdev', 'usbctrl'?
> 
> [Thales, 14/03/24]
> 
> device_model_args = [ "
> 
>                       "-device","nec-usb-xhci,id=xhci",
> 
>                       "-device","usb-host,bus=xhci.0,hostbus=1,hostport=13",
> 
>                       "-device","usb-host,bus=xhci.0,hostbus=1,hostport=10",
> 
>                       "-device","usb-host,bus=xhci.0,hostbus=1,hostport=2",
> 
>                       "-device","usb-host,bus=xhci.0,hostbus=2,hostport=2",
> 
>                       "-device","usb-host,bus=xhci.0,hostbus=2,hostport=1",
> 
>                       "-device","usb-host,bus=xhci.0,hostbus=1,hostport=1"]
> 
> [end Thales, 14/03/24]
> 
>  
> 
> [...]
> 
>  
> 
> >>      -Xen version4.14
> 
> >
> 
> >
> 
> >
> 
> > Are minor version of Xen 4.14 are you using ? Any patches on top ?
> 
> >
> 
> >
> 
> >
> 
> > Xen 4.14 has also been out of support for a few months now. If that’s
> 
> > possible, I would recommend to try a new Xen version (the last stable
> 
> > is
> 
> >
> 
> > 4.18) just in case your issue as been fixed in newer release.
> 
> >
> 
> >
> 
> >
> 
> > [Thales] : we have to use Xen release that are downloaded from the
> 
> > Debian official repository  (requested by our customer)
> 
> >
> 
> > [Thales] : the last one is version 4.14, but we would like to know if there is one more recent that is compatible with Linux Debian 11 ?
> 
>  
> 
> Newer Xen releases should be compatible with Debian 11. But I am not aware of any "official" package for that specific version.
> 
>  
> 
> Cheers,
> 
>  
> 
> --
> 
> Julien Grall
> 
> 
> 
--8323329-1892190326-1710544158=:853156--


From xen-devel-bounces@lists.xenproject.org Fri Mar 15 23:58:51 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Mar 2024 23:58:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694097.1082952 (Exim 4.92)
	(envelope-from )
	id 1rlHRk-0001gu-Pn; Fri, 15 Mar 2024 23:58:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694097.1082952; Fri, 15 Mar 2024 23:58:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rlHRk-0001gn-NB; Fri, 15 Mar 2024 23:58:44 +0000
Received: by outflank-mailman (input) for mailman id 694097;
 Fri, 15 Mar 2024 23:58:43 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rlHRj-0001gh-Sq
 for xen-devel@lists.xenproject.org; Fri, 15 Mar 2024 23:58:43 +0000
Received: from sin.source.kernel.org (sin.source.kernel.org
 [2604:1380:40e1:4800::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f1f54c84-e327-11ee-a1ee-f123f15fe8a2;
 Sat, 16 Mar 2024 00:58:41 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sin.source.kernel.org (Postfix) with ESMTP id B5A66CE2238;
 Fri, 15 Mar 2024 23:58:38 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id AAED7C433F1;
 Fri, 15 Mar 2024 23:58:36 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f1f54c84-e327-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1710547118;
	bh=hch4Iq2kCOfE1Yr5gSemlDffouVi1ooMupgbzXdSvXA=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=nyI10j7cGrybdAhwikdbqmd6R6/OZgYpME1w9fNfMN9qRtMN7CxKTt9YlGgHX9R1A
	 gNHp5DmfWMV0bZuzE3jKbKaj3LCtB5kqMd3nvMZRhA+yp+LEqTYSEWLCtXdcELYo6u
	 f/947NOc7nYygRbYDl5v5gB/IcsvnQSZ1b2W0mPP34fYBVIn4goJNxavxAmnXN5cDS
	 tLkRjLtFi8lOo7ggrg0d6ac3Mg39K3r5p9cgqj3jP36wIAbRQgnScrwoO6GFeMPLvl
	 HjXurFei/m2CL1e+RmVCDSeGjPkfaO6JfD2sAo/KkziC0wOKlJ+MmMdX9tSZSa8JVt
	 bx9Pczmh73TSw==
Date: Fri, 15 Mar 2024 16:58:34 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: George Dunlap 
cc: Jan Beulich , Julien Grall , 
    Stefano Stabellini , federico.serafini@bugseng.com, 
    Andrew Cooper , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Bertrand Marquis , 
    xen-devel@lists.xenproject.org, michal.orzel@amd.com
Subject: Re: [PATCH] do_multicall and MISRA Rule 8.3\
In-Reply-To: 
Message-ID: 
References:  <5a8f90d6-6502-4d93-9fd7-45fea0ede24a@suse.com>  
    
 <63891474-1dc4-4c86-aaf4-cc4d4c53a0ae@suse.com>   <3f27abc3-9809-4637-a29c-8aeafcd29ade@xen.org> <7109ef7e-040c-4d11-ba4b-d898ed2530ff@suse.com>
 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="8323329-233457267-1710546788=:853156"
Content-ID: 

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-233457267-1710546788=:853156
Content-Type: text/plain; CHARSET=UTF-8
Content-Transfer-Encoding: 8BIT
Content-ID: 

On Fri, 15 Mar 2024, George Dunlap wrote:
> On Fri, Mar 15, 2024 at 2:13 PM Jan Beulich  wrote:
> >
> > On 15.03.2024 14:55, Julien Grall wrote:
> > > Hi Jan,
> > >
> > > On 15/03/2024 13:24, Jan Beulich wrote:
> > >> On 15.03.2024 13:17, George Dunlap wrote:
> > >>> On Fri, Mar 15, 2024 at 11:57 AM Jan Beulich  wrote:
> > >>>>> It sounds like Andy and Stefano feel like this is a situation where "a
> > >>>>> fixed width quantity is meant"; absent any further guidance from the
> > >>>>> CODING_STYLE about when fixed widths should or should not be used, I
> > >>>>> don't think this change would be a violation of CODING_STYLE.
> [snip]
> > >>> Other than "it's in CODING_STYLE", and "it's not really necessary
> > >>> because it's ensured in the assembly code", you haven't advanced a
> > >>> single reason why "uint32_t" is problematic.
> > >>
> > >> And it isn't, I never said it would be. But if we set rules for
> > >> ourselves, why would we take the first opportunity to not respect them?
> > >
> > > I am a bit confused. Reading through the thread you seem to agree that
> > > the written rules are respected here. So what rules are you talking about?
> >
> > What was proposed is use of a fixed width type where according to my
> > reading ./CODING_STYLE says it shouldn't be used.
> 
> This conversation is starting to get frustrating.  That's simply not
> what it says, and I pointed that out just a few messages ago.
> 
> To reiterate:The text says fixed-width types are OK when a fixed-width
> quantity is "meant"; and that in this case, Stefano and Andy "mean" to
> use a fixed-width quantity.  The implied subtext of that sentence
> could be, "Don't use fixed width types unless there's a good reason to
> use a fixed width", and both Andy and Stefano think there's a good
> reason.  This argument you haven't really addressed at all, except
> with a specious "slippery slope" argument meant to nullify the
> exception; and now you attempt to simply ignore.
> 
> I venture to assert that for most people, the rules are a means to an
> end: That end being code which is correct, robust, fast, easy to
> write, maintain, debug, and review patches for.  What I agreed to,
> when I accepted this patch, was that *in general* we would avoid using
> fixed-width types; but that there were cases where doing so made
> sense.  Some of those were discussed in the thread above.
> 
> Andy and Stefano have already put forward reasons why they think a
> fixed-width type would be better here, which are related to "end
> goals": namely, more robust and easy to maintain code.  When I asked
> what "end goals" would be negatively impacted by using a fixed-width
> type, you explicitly said that there were none!  That the *only*
> reason you're continuing to argue is that we have a document somewhere
> that says we should -- a document which explicitly acknowledges that
> there will be exceptions!
> 
> The ideal response would have been to lay out a reasonably
> comprehensive set of criteria for when to use basic types, when to use
> fixed-width types, and how each criteria advanced the end goals of a
> better codebase.  A sufficient response would have been to lay out
> reasons why "better codebase", in this instance, tilts towards using a
> basic type rather than a fixed-width type.
> 
> Saying "That's what the rules say", without motivating it by
> explaining how it connects to a better codebase, is just not a helpful
> response; and making that argument after it's been pointed out that
> that is *not* what the rules say is even worse.

Thanks George for taking the time to write all of the above.

Let's please move forward with this patch.
--8323329-233457267-1710546788=:853156--


From xen-devel-bounces@lists.xenproject.org Sat Mar 16 00:08:03 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 16 Mar 2024 00:08:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694101.1082963 (Exim 4.92)
	(envelope-from )
	id 1rlHah-000426-02; Sat, 16 Mar 2024 00:07:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694101.1082963; Sat, 16 Mar 2024 00:07:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rlHag-00041z-Te; Sat, 16 Mar 2024 00:07:58 +0000
Received: by outflank-mailman (input) for mailman id 694101;
 Sat, 16 Mar 2024 00:07:57 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rlHaf-00041t-Bx
 for xen-devel@lists.xenproject.org; Sat, 16 Mar 2024 00:07:57 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3c7307e5-e329-11ee-a1ee-f123f15fe8a2;
 Sat, 16 Mar 2024 01:07:55 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id E3C776181E;
 Sat, 16 Mar 2024 00:07:53 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5AE9FC433F1;
 Sat, 16 Mar 2024 00:07:52 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3c7307e5-e329-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1710547673;
	bh=YsslnC7kNcz4/PFmexsOORIdSazznJu1TK9JiAM+gsU=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=ttzHrMRI7DSWGTRZQZ1d5OFXDmaUzXnMZVEc6dtfR82cVuOobr4oCXRojrv/9VwfT
	 UMbfmy/qSNxzZ3HNVOdwBg45Q7JOiB52TwlHEa7OfR84MhZPqegV25yWd6eKLEg1Q8
	 NC7qeNXbpuzYjw1BOdB0P3khhsBUUJdWPlV7eKPQlr2DhvSKsP4P9/hOc+GymwOOaM
	 bLyh+jtzdjLYSjl/cZpQZrjlzA4ymYWIfDkTS0MrYbivh1cmI5PnVC/51B3gtB+Tw8
	 VSYIXk26DcOIKi+CM5RVqBbj8EWrcani+NqvG6KO/sA+RmkR8jUD98iZ4rcwz2P4qh
	 2f0LKpDDDhhGw==
Date: Fri, 15 Mar 2024 17:07:50 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich 
cc: Stefano Stabellini , andrew.cooper3@citrix.com, 
    bertrand.marquis@arm.com, george.dunlap@citrix.com, julien@xen.org, 
    michal.orzel@amd.com, roger.pau@citrix.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2] docs/misra: document the expected sizes of integer
 types
In-Reply-To: <6a76723e-ba47-40b3-8f33-d68030b14299@suse.com>
Message-ID: 
References:  <6a76723e-ba47-40b3-8f33-d68030b14299@suse.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Fri, 15 Mar 2024, Jan Beulich wrote:
> On 14.03.2024 23:17, Stefano Stabellini wrote:
> > Xen makes assumptions about the size of integer types on the various
> > architectures. Document these assumptions.
> 
> My prior reservation wrt exact vs minimum sizes remains.

We have to specify the exact size. In practice the size is predetermined
and exact with all our supported compilers given a architecture.

Most importantly, unfortunately we use non-fixed-size integer types in
C hypercall entry points and public ABIs. In my opinion, that is not
acceptable.

We have two options:

1) we go with this document, and we clarify that even if we specify
  "unsigned int", we actually mean a 32-bit integer

2) we change all our public ABIs and C hypercall entry points to use
   fixed-size types (e.g. s/unsigned int/uint32_t/g)

2) is preferred because it is clearer but it is more work. So I went
with 1). I also thought you would like 1) more.


> Additionally, is it really meaningful to document x86-32 as an
> architecture, when it's been many years that the hypervisor cannot be
> built anymore for that target?

You are right. I should take x86_32 out. I'll do it in the next version.


From xen-devel-bounces@lists.xenproject.org Sat Mar 16 00:10:57 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 16 Mar 2024 00:10:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694103.1082974 (Exim 4.92)
	(envelope-from )
	id 1rlHdX-0005nA-FV; Sat, 16 Mar 2024 00:10:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694103.1082974; Sat, 16 Mar 2024 00:10:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rlHdX-0005n3-Ac; Sat, 16 Mar 2024 00:10:55 +0000
Received: by outflank-mailman (input) for mailman id 694103;
 Sat, 16 Mar 2024 00:10:54 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rlHdW-0005mx-Go
 for xen-devel@lists.xenproject.org; Sat, 16 Mar 2024 00:10:54 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org
 [2604:1380:4641:c500::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a60fa1ba-e329-11ee-a1ee-f123f15fe8a2;
 Sat, 16 Mar 2024 01:10:52 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 1410D61820;
 Sat, 16 Mar 2024 00:10:51 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 81744C433F1;
 Sat, 16 Mar 2024 00:10:49 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a60fa1ba-e329-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1710547850;
	bh=RtG317NAqSuHheUaXBnD3mY4qWHQOZuAld0nDefX+34=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=J4qumpUyykUY3hD+KR0N4glMKFWP389iV3oWYP+hzs/HMQ/UF98DzfTX+tSpZZ4Ia
	 KCEGP5rKXQHsE4lLlsR90yY83P3dZ+wSuf6kjUD231WQW6Ur7QgQ5TGfuSPsHrV2cg
	 qKKPbOy+3I+UO5KyzBNoSFgsXGvAG79ba1hPpxL8HZWxotaYSkp15XdKsDHvlN1eud
	 ZlEGkYtOO26oBHBb9kRI0ooa67R0xPWkN9Q0ZOJ/YKRLvPvzS1RooH3NhDBS1PW0vB
	 ro0lcA3AsklzQWaECTFg88j/3mKeibwMVhxrAH235XamYq5GQfTyRxnrPc0+3bpiBT
	 ciXEKDffV9muA==
Date: Fri, 15 Mar 2024 17:10:47 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Federico Serafini 
cc: xen-devel@lists.xenproject.org, consulting@bugseng.com, 
    Simone Ballarin , 
    Doug Goldstein , 
    Stefano Stabellini , 
    Andrew Cooper , 
    George Dunlap , Jan Beulich , 
    Julien Grall , Wei Liu 
Subject: Re: [XEN PATCH v2] automation/eclair: allow parameter name
 "unused"
In-Reply-To: 
Message-ID: 
References: 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Fri, 15 Mar 2024, Federico Serafini wrote:
> Update ECLAIR configuration of MISRA C:2012 Rule 8.3 to deviate
> violations involving parameter name "unused" (with an optional
> numeric suffix): it makes explicit the intention of not using such
> parameter within the function.
> 
> Signed-off-by: Federico Serafini 

Reviewed-by: Stefano Stabellini 



From xen-devel-bounces@lists.xenproject.org Sat Mar 16 00:14:14 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 16 Mar 2024 00:14:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694105.1082983 (Exim 4.92)
	(envelope-from )
	id 1rlHgf-0006Md-Rg; Sat, 16 Mar 2024 00:14:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694105.1082983; Sat, 16 Mar 2024 00:14:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rlHgf-0006MW-Ou; Sat, 16 Mar 2024 00:14:09 +0000
Received: by outflank-mailman (input) for mailman id 694105;
 Sat, 16 Mar 2024 00:14:09 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rlHge-0006MQ-W1
 for xen-devel@lists.xenproject.org; Sat, 16 Mar 2024 00:14:08 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1a13e222-e32a-11ee-a1ee-f123f15fe8a2;
 Sat, 16 Mar 2024 01:14:06 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id A77E16170B;
 Sat, 16 Mar 2024 00:14:05 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 28F36C433F1;
 Sat, 16 Mar 2024 00:14:04 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1a13e222-e32a-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1710548045;
	bh=yrdKAsf52DSZ4/YYYyVVe9Ax/figrEAAglOhwZwdctU=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=im7GdM9FDqmNw9/6qVCg5gX6aZr+G3hcNRvGtyjr8KXCrKudF2euijHe+qLqquw05
	 ISLJbHEFBfrhjuYwn+THC5DnGYsi55PuKmK3Jwe5+X+XLtzWujeRKTnSxEqSEIx/iL
	 YTL5OOTg2NGcufoHqvpf9pWdL5R+QdKo8tCf1C8ccSVBVOk7fuUeduLy5+wrWW/+r4
	 gUM6jaqwZghOf4/OxWqMisYGbfIoX2RQ7Kf/U8Wg4ArBDEaTS2T1SjC3iXDP/FL3f1
	 sdDuX1UYbpZZy6J1/E6OpZhUpXY7HceEsFtBy56OD9UNYiJKPwQQYzlL7zqV2qdxoA
	 PEEm3XZBqwv7g==
Date: Fri, 15 Mar 2024 17:14:01 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich 
cc: Stefano Stabellini , andrew.cooper3@citrix.com, 
    bertrand.marquis@arm.com, george.dunlap@citrix.com, julien@xen.org, 
    michal.orzel@amd.com, roger.pau@citrix.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3] docs/misra/rules.rst: add rule 5.5
In-Reply-To: <5a4533e5-c6f3-418c-811b-2bd0a631f1ad@suse.com>
Message-ID: 
References:  <5a4533e5-c6f3-418c-811b-2bd0a631f1ad@suse.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Fri, 15 Mar 2024, Jan Beulich wrote:
> On 15.03.2024 01:35, Stefano Stabellini wrote:
> > --- a/docs/misra/rules.rst
> > +++ b/docs/misra/rules.rst
> > @@ -181,6 +181,21 @@ maintainers if you want to suggest a change.
> >         headers (xen/include/public/) are allowed to retain longer
> >         identifiers for backward compatibility.
> >  
> > +   * - `Rule 5.5 `_
> > +     - Required
> > +     - Identifiers shall be distinct from macro names
> > +     - Macros expanding to their own name are allowed, e.g.::
> > +
> > +           #define x x
> > +
> > +       Clashes between names of function-like macros and identifiers of
> > +       non-callable entities are allowed. Callable entities having an
> > +       identifier that is the same of the name of a
> > +       function-like macro are not allowed. Example (not allowed)::
> > +
> > +           #define f(x, y) f(x, y);
> 
> The semicolon here wants dropping, just to not give questionable constructs
> as examples.

Good point


> > +           void f(int x, int y);
> 
> With this not allowed and there (iirc) being examples of such in the code,
> I'll be curious how it is meant to deal with them.

I don't know how many violations we have, and if there is a general
pattern we could apply to address them. As usual we'll have a choice
between changing the code or adding a deviation.


From xen-devel-bounces@lists.xenproject.org Sat Mar 16 00:25:35 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 16 Mar 2024 00:25:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694111.1082993 (Exim 4.92)
	(envelope-from )
	id 1rlHre-0008NR-Qw; Sat, 16 Mar 2024 00:25:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694111.1082993; Sat, 16 Mar 2024 00:25:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rlHre-0008NK-Nv; Sat, 16 Mar 2024 00:25:30 +0000
Received: by outflank-mailman (input) for mailman id 694111;
 Sat, 16 Mar 2024 00:25:29 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rlHrd-0008NE-4K
 for xen-devel@lists.xenproject.org; Sat, 16 Mar 2024 00:25:29 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id aef409e0-e32b-11ee-a1ee-f123f15fe8a2;
 Sat, 16 Mar 2024 01:25:26 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 6913F6175A;
 Sat, 16 Mar 2024 00:25:24 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id D8A21C433C7;
 Sat, 16 Mar 2024 00:25:22 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: aef409e0-e32b-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1710548724;
	bh=uxSl1Cwa0XXqoDRLEn0FII40cr7kcuL8Vz6zNlWjQ7Y=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=KV6P5f7dQQmgM4WWV+qMKHMRY8eMtX38/jp8g7/3gq0bRb38iDtakRjSub0tGB8KS
	 SwvHwl+o2y6QWF2ilLAtv20MvydyexJXoiI0HWh75Pv/MbFFfL+YfH4DODVbK1nR5i
	 jCNXn55inXQebbuFzyXTsM/O4CGDuOCE9pOBNNYAlzsmvhrqpfRgKPCFZZWTwh2rBA
	 Cf7xrZ35k8PelXW2ZZqXVzXsOsUVLahQWqodPFG+qjP09iY9KDqycYrSK5JHENXQXR
	 RWqNB0IkZDWmPgUcwcuvho53fJuIoJHhvWY7BILmzFL/FlStkWFlkDY4ON78kUHuRF
	 reoFVA2DbyG9A==
Date: Fri, 15 Mar 2024 17:25:20 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Nicola Vetrini 
cc: xen-devel@lists.xenproject.org, sstabellini@kernel.org, 
    michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, 
    consulting@bugseng.com, Jan Beulich , 
    Andrew Cooper 
Subject: Re: [XEN PATCH v3] amd/iommu: clean up unused guest iommu related
 functions
In-Reply-To: <98fef1239e4f0e756daf863a9e4e7bb679baa264.1710518105.git.nicola.vetrini@bugseng.com>
Message-ID: 
References: <98fef1239e4f0e756daf863a9e4e7bb679baa264.1710518105.git.nicola.vetrini@bugseng.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Fri, 15 Mar 2024, Nicola Vetrini wrote:
> Delete unused functions from 'iommu_guest.c'.
> 
> No functional change.
> 
> Signed-off-by: Nicola Vetrini 

Reviewed-by: Stefano Stabellini 


> ---
> guest_iommu_add_ptr_log has still one caller, but even that seems
> suspicious. I left it in and uniformed its parameter type at the
> moment, so that whether it should be kept can be sorted out later.
> If that caller indeed should be removed as well, then
> no function in the file is actually reachable as far as I can tell.

I couldn't rule it out that guest_iommu_add_ptr_log might be useful so I
would keep it


> Changes in v2:
> - change parameter type to uint32_t
> - remove unused functions
> Changes in v3:
> - also remove amd_iommu_send_guest_cmd
> ---
>  xen/drivers/passthrough/amd/iommu.h       |   7 +-
>  xen/drivers/passthrough/amd/iommu_cmd.c   |   7 -
>  xen/drivers/passthrough/amd/iommu_guest.c | 762 +---------------------
>  3 files changed, 2 insertions(+), 774 deletions(-)
> 
> diff --git a/xen/drivers/passthrough/amd/iommu.h b/xen/drivers/passthrough/amd/iommu.h
> index 1b62c083ba67..65de88217c07 100644
> --- a/xen/drivers/passthrough/amd/iommu.h
> +++ b/xen/drivers/passthrough/amd/iommu.h
> @@ -346,12 +346,7 @@ void cf_check amd_iommu_crash_shutdown(void);
>  
>  /* guest iommu support */
>  #ifdef CONFIG_HVM
> -void amd_iommu_send_guest_cmd(struct amd_iommu *iommu, u32 cmd[]);
> -void guest_iommu_add_ppr_log(struct domain *d, u32 entry[]);
> -void guest_iommu_add_event_log(struct domain *d, u32 entry[]);
> -int guest_iommu_init(struct domain* d);
> -void guest_iommu_destroy(struct domain *d);
> -int guest_iommu_set_base(struct domain *d, uint64_t base);
> +void guest_iommu_add_ppr_log(struct domain *d, uint32_t entry[]);
>  #else
>  static inline void guest_iommu_add_ppr_log(struct domain *d, uint32_t entry[]) {}
>  #endif
> diff --git a/xen/drivers/passthrough/amd/iommu_cmd.c b/xen/drivers/passthrough/amd/iommu_cmd.c
> index 49b9fcac9410..83c525b84f91 100644
> --- a/xen/drivers/passthrough/amd/iommu_cmd.c
> +++ b/xen/drivers/passthrough/amd/iommu_cmd.c
> @@ -389,10 +389,3 @@ void amd_iommu_flush_all_caches(struct amd_iommu *iommu)
>      invalidate_iommu_all(iommu);
>      flush_command_buffer(iommu, 0);
>  }
> -
> -void amd_iommu_send_guest_cmd(struct amd_iommu *iommu, u32 cmd[])
> -{
> -    send_iommu_command(iommu, cmd);
> -    /* TBD: Timeout selection may require peeking into cmd[]. */
> -    flush_command_buffer(iommu, 0);
> -}
> diff --git a/xen/drivers/passthrough/amd/iommu_guest.c b/xen/drivers/passthrough/amd/iommu_guest.c
> index 4c4252eea116..19bd2e5d8e63 100644
> --- a/xen/drivers/passthrough/amd/iommu_guest.c
> +++ b/xen/drivers/passthrough/amd/iommu_guest.c
> @@ -20,28 +20,7 @@
>  
>  #include "iommu.h"
>  
> -#define IOMMU_MMIO_SIZE                         0x8000
> -#define IOMMU_MMIO_PAGE_NR                      0x8
> -#define RING_BF_LENGTH_MASK                     0x0F000000
> -#define RING_BF_LENGTH_SHIFT                    24
> -
> -#define PASMAX_9_bit                            0x8
> -#define GUEST_CR3_1_LEVEL                       0x0
> -#define GUEST_ADDRESS_SIZE_6_LEVEL              0x2
> -#define HOST_ADDRESS_SIZE_6_LEVEL               0x2
> -
>  #define reg_to_u64(reg) (((uint64_t)reg.hi << 32) | reg.lo )
> -#define u64_to_reg(reg, val) \
> -    do \
> -    { \
> -        (reg)->lo = (u32)(val); \
> -        (reg)->hi = (val) >> 32; \
> -    } while (0)
> -
> -static unsigned int get_machine_bdf(struct domain *d, uint16_t guest_bdf)
> -{
> -    return guest_bdf;
> -}
>  
>  static uint16_t get_guest_bdf(struct domain *d, uint16_t machine_bdf)
>  {
> @@ -53,62 +32,6 @@ static inline struct guest_iommu *domain_iommu(struct domain *d)
>      return dom_iommu(d)->arch.amd.g_iommu;
>  }
>  
> -static inline struct guest_iommu *vcpu_iommu(struct vcpu *v)
> -{
> -    return dom_iommu(v->domain)->arch.amd.g_iommu;
> -}
> -
> -static void guest_iommu_enable(struct guest_iommu *iommu)
> -{
> -    iommu->enabled = 1;
> -}
> -
> -static void guest_iommu_disable(struct guest_iommu *iommu)
> -{
> -    iommu->enabled = 0;
> -}
> -
> -/*
> - * The Guest CR3 Table is a table written by the guest kernel, pointing at
> - * gCR3 values for PASID transactions to use.  The Device Table Entry points
> - * at a system physical address.
> - *
> - * However, these helpers deliberately use untyped parameters without
> - * reference to gfn/mfn because they are used both for programming the real
> - * IOMMU, and interpreting a guests programming of its vIOMMU.
> - */
> -static uint64_t dte_get_gcr3_table(const struct amd_iommu_dte *dte)
> -{
> -    return (((uint64_t)dte->gcr3_trp_51_31 << 31) |
> -            (dte->gcr3_trp_30_15 << 15) |
> -            (dte->gcr3_trp_14_12 << 12));
> -}
> -
> -static void dte_set_gcr3_table(struct amd_iommu_dte *dte, uint16_t dom_id,
> -                               uint64_t addr, bool gv, uint8_t glx)
> -{
> -#define GCR3_MASK(hi, lo) (((1UL << ((hi) + 1)) - 1) & ~((1UL << (lo)) - 1))
> -
> -    /* I bit must be set when gcr3 is enabled */
> -    dte->i = true;
> -
> -    dte->gcr3_trp_14_12 = MASK_EXTR(addr, GCR3_MASK(14, 12));
> -    dte->gcr3_trp_30_15 = MASK_EXTR(addr, GCR3_MASK(30, 15));
> -    dte->gcr3_trp_51_31 = MASK_EXTR(addr, GCR3_MASK(51, 31));
> -
> -    dte->domain_id = dom_id;
> -    dte->glx = glx;
> -    dte->gv = gv;
> -
> -#undef GCR3_MASK
> -}
> -
> -static unsigned int host_domid(struct domain *d, uint64_t g_domid)
> -{
> -    /* Only support one PPR device in guest for now */
> -    return d->domain_id;
> -}
> -
>  static unsigned long get_gfn_from_base_reg(uint64_t base_raw)
>  {
>      base_raw &= PADDR_MASK;
> @@ -146,24 +69,6 @@ static unsigned long guest_iommu_get_table_mfn(struct domain *d,
>      return mfn;
>  }
>  
> -static void guest_iommu_enable_dev_table(struct guest_iommu *iommu)
> -{
> -    uint32_t length_raw = get_field_from_reg_u32(iommu->dev_table.reg_base.lo,
> -                                                 IOMMU_DEV_TABLE_SIZE_MASK,
> -                                                 IOMMU_DEV_TABLE_SIZE_SHIFT);
> -    iommu->dev_table.size = (length_raw + 1) * PAGE_SIZE;
> -}
> -
> -static void guest_iommu_enable_ring_buffer(struct guest_iommu *iommu,
> -                                           struct guest_buffer *buffer,
> -                                           uint32_t entry_size)
> -{
> -    uint32_t length_raw = get_field_from_reg_u32(buffer->reg_base.hi,
> -                                                 RING_BF_LENGTH_MASK,
> -                                                 RING_BF_LENGTH_SHIFT);
> -    buffer->size = entry_size << length_raw;
> -}
> -
>  void guest_iommu_add_ppr_log(struct domain *d, u32 entry[])
>  {
>      uint16_t gdev_id;
> @@ -184,7 +89,7 @@ void guest_iommu_add_ppr_log(struct domain *d, u32 entry[])
>      if ( tail >= iommu->ppr_log.size || head >= iommu->ppr_log.size )
>      {
>          AMD_IOMMU_DEBUG("Error: guest iommu ppr log overflows\n");
> -        guest_iommu_disable(iommu);
> +        iommu->enabled = 0;
>          return;
>      }
>  
> @@ -213,668 +118,3 @@ void guest_iommu_add_ppr_log(struct domain *d, u32 entry[])
>  
>      guest_iommu_deliver_msi(d);
>  }
> -
> -void guest_iommu_add_event_log(struct domain *d, u32 entry[])
> -{
> -    uint16_t dev_id;
> -    unsigned long mfn, tail, head;
> -    event_entry_t *log;
> -    struct guest_iommu *iommu;
> -
> -    if ( !is_hvm_domain(d) )
> -        return;
> -
> -    iommu = domain_iommu(d);
> -    if ( !iommu )
> -        return;
> -
> -    tail = iommu->event_log.reg_tail.lo;
> -    head = iommu->event_log.reg_head.lo;
> -
> -    if ( tail >= iommu->event_log.size || head >= iommu->event_log.size )
> -    {
> -        AMD_IOMMU_DEBUG("Error: guest iommu event overflows\n");
> -        guest_iommu_disable(iommu);
> -        return;
> -    }
> -
> -    mfn = guest_iommu_get_table_mfn(d, reg_to_u64(iommu->event_log.reg_base),
> -                                    tail);
> -    ASSERT(mfn_valid(_mfn(mfn)));
> -
> -    log = map_domain_page(_mfn(mfn)) + (tail & ~PAGE_MASK);
> -
> -    /* re-write physical device id into virtual device id */
> -    dev_id = get_guest_bdf(d, iommu_get_devid_from_cmd(entry[0]));
> -    iommu_set_devid_to_cmd(&entry[0], dev_id);
> -    memcpy(log, entry, sizeof(event_entry_t));
> -
> -    /* Now shift event log tail pointer */
> -    tail += sizeof(event_entry_t);
> -    if ( tail >= iommu->event_log.size )
> -    {
> -        tail = 0;
> -        iommu->reg_status.lo |= IOMMU_STATUS_EVENT_LOG_OVERFLOW;
> -    }
> -
> -    iommu->event_log.reg_tail.lo = tail;
> -    unmap_domain_page(log);
> -
> -    guest_iommu_deliver_msi(d);
> -}
> -
> -static int do_complete_ppr_request(struct domain *d, cmd_entry_t *cmd)
> -{
> -    uint16_t dev_id;
> -    struct amd_iommu *iommu;
> -
> -    dev_id = get_machine_bdf(d, iommu_get_devid_from_cmd(cmd->data[0]));
> -    iommu = find_iommu_for_device(0, dev_id);
> -
> -    if ( !iommu )
> -    {
> -        AMD_IOMMU_DEBUG("%s: Fail to find iommu for bdf %x\n",
> -                        __func__, dev_id);
> -        return -ENODEV;
> -    }
> -
> -    /* replace virtual device id into physical */
> -    iommu_set_devid_to_cmd(&cmd->data[0], dev_id);
> -    amd_iommu_send_guest_cmd(iommu, cmd->data);
> -
> -    return 0;
> -}
> -
> -static int do_invalidate_pages(struct domain *d, cmd_entry_t *cmd)
> -{
> -    uint16_t gdom_id, hdom_id;
> -    struct amd_iommu *iommu = NULL;
> -
> -    gdom_id = get_field_from_reg_u32(cmd->data[1],
> -                                    IOMMU_INV_IOMMU_PAGES_DOMAIN_ID_MASK,
> -                                    IOMMU_INV_IOMMU_PAGES_DOMAIN_ID_SHIFT);
> -
> -    hdom_id = host_domid(d, gdom_id);
> -    set_field_in_reg_u32(hdom_id, cmd->data[1],
> -                         IOMMU_INV_IOMMU_PAGES_DOMAIN_ID_MASK,
> -                         IOMMU_INV_IOMMU_PAGES_DOMAIN_ID_SHIFT, &cmd->data[1]);
> -
> -    for_each_amd_iommu ( iommu )
> -        amd_iommu_send_guest_cmd(iommu, cmd->data);
> -
> -    return 0;
> -}
> -
> -static int do_invalidate_all(struct domain *d, cmd_entry_t *cmd)
> -{
> -    struct amd_iommu *iommu = NULL;
> -
> -    for_each_amd_iommu ( iommu )
> -        amd_iommu_flush_all_pages(d);
> -
> -    return 0;
> -}
> -
> -static int do_invalidate_iotlb_pages(struct domain *d, cmd_entry_t *cmd)
> -{
> -    struct amd_iommu *iommu;
> -    uint16_t dev_id;
> -
> -    dev_id = get_machine_bdf(d, iommu_get_devid_from_cmd(cmd->data[0]));
> -
> -    iommu = find_iommu_for_device(0, dev_id);
> -    if ( !iommu )
> -    {
> -        AMD_IOMMU_DEBUG("%s: Fail to find iommu for bdf %x\n",
> -                         __func__, dev_id);
> -        return -ENODEV;
> -    }
> -
> -    iommu_set_devid_to_cmd(&cmd->data[0], dev_id);
> -    amd_iommu_send_guest_cmd(iommu, cmd->data);
> -
> -    return 0;
> -}
> -
> -static int do_completion_wait(struct domain *d, cmd_entry_t *cmd)
> -{
> -    bool com_wait_int, i, s;
> -    struct guest_iommu *iommu;
> -    unsigned long gfn;
> -    p2m_type_t p2mt;
> -
> -    iommu = domain_iommu(d);
> -
> -    i = cmd->data[0] & IOMMU_COMP_WAIT_I_FLAG_MASK;
> -    s = cmd->data[0] & IOMMU_COMP_WAIT_S_FLAG_MASK;
> -
> -    if ( i )
> -        iommu->reg_status.lo |= IOMMU_STATUS_COMP_WAIT_INT;
> -
> -    if ( s )
> -    {
> -        uint64_t gaddr_lo, gaddr_hi, gaddr_64, data;
> -        void *vaddr;
> -
> -        data = (uint64_t)cmd->data[3] << 32 | cmd->data[2];
> -        gaddr_lo = get_field_from_reg_u32(cmd->data[0],
> -                                          IOMMU_COMP_WAIT_ADDR_LOW_MASK,
> -                                          IOMMU_COMP_WAIT_ADDR_LOW_SHIFT);
> -        gaddr_hi = get_field_from_reg_u32(cmd->data[1],
> -                                          IOMMU_COMP_WAIT_ADDR_HIGH_MASK,
> -                                          IOMMU_COMP_WAIT_ADDR_HIGH_SHIFT);
> -
> -        gaddr_64 = (gaddr_hi << 32) | (gaddr_lo << 3);
> -
> -        gfn = gaddr_64 >> PAGE_SHIFT;
> -        vaddr = map_domain_page(get_gfn(d, gfn ,&p2mt));
> -        put_gfn(d, gfn);
> -
> -        write_u64_atomic((uint64_t *)(vaddr + (gaddr_64 & (PAGE_SIZE-1))),
> -                         data);
> -        unmap_domain_page(vaddr);
> -    }
> -
> -    com_wait_int = iommu->reg_status.lo & IOMMU_STATUS_COMP_WAIT_INT;
> -
> -    if ( iommu->reg_ctrl.com_wait_int_en && com_wait_int )
> -        guest_iommu_deliver_msi(d);
> -
> -    return 0;
> -}
> -
> -static int do_invalidate_dte(struct domain *d, cmd_entry_t *cmd)
> -{
> -    uint16_t gbdf, mbdf, req_id, gdom_id, hdom_id, prev_domid;
> -    struct amd_iommu_dte *gdte, *mdte, *dte_base;
> -    struct amd_iommu *iommu = NULL;
> -    struct guest_iommu *g_iommu;
> -    uint64_t gcr3_gfn, gcr3_mfn;
> -    uint8_t glx, gv;
> -    unsigned long dte_mfn, flags;
> -    p2m_type_t p2mt;
> -
> -    g_iommu = domain_iommu(d);
> -    gbdf = iommu_get_devid_from_cmd(cmd->data[0]);
> -    mbdf = get_machine_bdf(d, gbdf);
> -
> -    /* Guest can only update DTEs for its passthru devices */
> -    if ( mbdf == 0 || gbdf == 0 )
> -        return 0;
> -
> -    /* Sometimes guest invalidates devices from non-exists dtes */
> -    if ( (gbdf * sizeof(struct amd_iommu_dte)) > g_iommu->dev_table.size )
> -        return 0;
> -
> -    dte_mfn = guest_iommu_get_table_mfn(d,
> -                                        reg_to_u64(g_iommu->dev_table.reg_base),
> -                                        sizeof(struct amd_iommu_dte) * gbdf);
> -    ASSERT(mfn_valid(_mfn(dte_mfn)));
> -
> -    /* Read guest dte information */
> -    dte_base = map_domain_page(_mfn(dte_mfn));
> -
> -    gdte = &dte_base[gbdf % (PAGE_SIZE / sizeof(struct amd_iommu_dte))];
> -
> -    gdom_id = gdte->domain_id;
> -    gcr3_gfn = dte_get_gcr3_table(gdte) >> PAGE_SHIFT;
> -    glx = gdte->glx;
> -    gv = gdte->gv;
> -
> -    unmap_domain_page(dte_base);
> -
> -    /* Do not update host dte before gcr3 has been set */
> -    if ( gcr3_gfn == 0 )
> -        return 0;
> -
> -    gcr3_mfn = mfn_x(get_gfn(d, gcr3_gfn, &p2mt));
> -    put_gfn(d, gcr3_gfn);
> -
> -    ASSERT(mfn_valid(_mfn(gcr3_mfn)));
> -
> -    iommu = find_iommu_for_device(0, mbdf);
> -    if ( !iommu )
> -    {
> -        AMD_IOMMU_DEBUG("%s: Fail to find iommu for bdf %x!\n",
> -                        __func__, mbdf);
> -        return -ENODEV;
> -    }
> -
> -    /* Setup host device entry */
> -    hdom_id = host_domid(d, gdom_id);
> -    req_id = get_dma_requestor_id(iommu->seg, mbdf);
> -    dte_base = iommu->dev_table.buffer;
> -    mdte = &dte_base[req_id];
> -    prev_domid = mdte->domain_id;
> -
> -    spin_lock_irqsave(&iommu->lock, flags);
> -    dte_set_gcr3_table(mdte, hdom_id, gcr3_mfn << PAGE_SHIFT, gv, glx);
> -
> -    spin_unlock_irqrestore(&iommu->lock, flags);
> -
> -    amd_iommu_flush_device(iommu, req_id, prev_domid);
> -
> -    return 0;
> -}
> -
> -static void cf_check guest_iommu_process_command(void *data)
> -{
> -    unsigned long opcode, tail, head, cmd_mfn;
> -    cmd_entry_t *cmd;
> -    struct domain *d = data;
> -    struct guest_iommu *iommu;
> -
> -    iommu = domain_iommu(d);
> -
> -    if ( !iommu->enabled )
> -        return;
> -
> -    head = iommu->cmd_buffer.reg_head.lo;
> -    tail = iommu->cmd_buffer.reg_tail.lo;
> -
> -    /* Tail pointer is rolled over by guest driver, value outside
> -     * cmd_buffer_entries cause iommu disabled
> -     */
> -
> -    if ( tail >= iommu->cmd_buffer.size || head >= iommu->cmd_buffer.size )
> -    {
> -        AMD_IOMMU_DEBUG("Error: guest iommu cmd buffer overflows\n");
> -        guest_iommu_disable(iommu);
> -        return;
> -    }
> -
> -    while ( head != tail )
> -    {
> -        int ret = 0;
> -
> -        cmd_mfn = guest_iommu_get_table_mfn(d,
> -                                            reg_to_u64(iommu->cmd_buffer.reg_base),
> -                                            head);
> -        ASSERT(mfn_valid(_mfn(cmd_mfn)));
> -
> -        cmd = map_domain_page(_mfn(cmd_mfn)) + (head & ~PAGE_MASK);
> -
> -        opcode = get_field_from_reg_u32(cmd->data[1],
> -                                        IOMMU_CMD_OPCODE_MASK,
> -                                        IOMMU_CMD_OPCODE_SHIFT);
> -        switch ( opcode )
> -        {
> -        case IOMMU_CMD_COMPLETION_WAIT:
> -            ret = do_completion_wait(d, cmd);
> -            break;
> -        case IOMMU_CMD_INVALIDATE_DEVTAB_ENTRY:
> -            ret = do_invalidate_dte(d, cmd);
> -            break;
> -        case IOMMU_CMD_INVALIDATE_IOMMU_PAGES:
> -            ret = do_invalidate_pages(d, cmd);
> -            break;
> -        case IOMMU_CMD_INVALIDATE_IOTLB_PAGES:
> -            ret = do_invalidate_iotlb_pages(d, cmd);
> -            break;
> -        case IOMMU_CMD_INVALIDATE_INT_TABLE:
> -            break;
> -        case IOMMU_CMD_COMPLETE_PPR_REQUEST:
> -            ret = do_complete_ppr_request(d, cmd);
> -            break;
> -        case IOMMU_CMD_INVALIDATE_IOMMU_ALL:
> -            ret = do_invalidate_all(d, cmd);
> -            break;
> -        default:
> -            AMD_IOMMU_DEBUG("CMD: Unknown command cmd_type = %lx "
> -                            "head = %ld\n", opcode, head);
> -            break;
> -        }
> -
> -        unmap_domain_page(cmd);
> -        head += sizeof(cmd_entry_t);
> -        if ( head >= iommu->cmd_buffer.size )
> -            head = 0;
> -        if ( ret )
> -            guest_iommu_disable(iommu);
> -    }
> -
> -    /* Now shift cmd buffer head pointer */
> -    iommu->cmd_buffer.reg_head.lo = head;
> -    return;
> -}
> -
> -static int guest_iommu_write_ctrl(struct guest_iommu *iommu, uint64_t val)
> -{
> -    union amd_iommu_control newctrl = { .raw = val };
> -
> -    if ( newctrl.iommu_en )
> -    {
> -        guest_iommu_enable(iommu);
> -        guest_iommu_enable_dev_table(iommu);
> -    }
> -
> -    if ( newctrl.iommu_en && newctrl.cmd_buf_en )
> -    {
> -        guest_iommu_enable_ring_buffer(iommu, &iommu->cmd_buffer,
> -                                       sizeof(cmd_entry_t));
> -        /* Enable iommu command processing */
> -        tasklet_schedule(&iommu->cmd_buffer_tasklet);
> -    }
> -
> -    if ( newctrl.iommu_en && newctrl.event_log_en )
> -    {
> -        guest_iommu_enable_ring_buffer(iommu, &iommu->event_log,
> -                                       sizeof(event_entry_t));
> -        iommu->reg_status.lo |=  IOMMU_STATUS_EVENT_LOG_RUN;
> -        iommu->reg_status.lo &= ~IOMMU_STATUS_EVENT_LOG_OVERFLOW;
> -    }
> -
> -    if ( newctrl.iommu_en && newctrl.ppr_en && newctrl.ppr_log_en )
> -    {
> -        guest_iommu_enable_ring_buffer(iommu, &iommu->ppr_log,
> -                                       sizeof(ppr_entry_t));
> -        iommu->reg_status.lo |=  IOMMU_STATUS_PPR_LOG_RUN;
> -        iommu->reg_status.lo &= ~IOMMU_STATUS_PPR_LOG_OVERFLOW;
> -    }
> -
> -    if ( newctrl.iommu_en && iommu->reg_ctrl.cmd_buf_en &&
> -         !newctrl.cmd_buf_en )
> -    {
> -        /* Disable iommu command processing */
> -        tasklet_kill(&iommu->cmd_buffer_tasklet);
> -    }
> -
> -    if ( iommu->reg_ctrl.event_log_en && !newctrl.event_log_en )
> -        iommu->reg_status.lo &= ~IOMMU_STATUS_EVENT_LOG_RUN;
> -
> -    if ( iommu->reg_ctrl.iommu_en && !newctrl.iommu_en )
> -        guest_iommu_disable(iommu);
> -
> -    iommu->reg_ctrl = newctrl;
> -
> -    return 0;
> -}
> -
> -static uint64_t iommu_mmio_read64(struct guest_iommu *iommu,
> -                                  unsigned long offset)
> -{
> -    uint64_t val;
> -
> -    switch ( offset )
> -    {
> -    case IOMMU_DEV_TABLE_BASE_LOW_OFFSET:
> -        val = reg_to_u64(iommu->dev_table.reg_base);
> -        break;
> -    case IOMMU_CMD_BUFFER_BASE_LOW_OFFSET:
> -        val = reg_to_u64(iommu->cmd_buffer.reg_base);
> -        break;
> -    case IOMMU_EVENT_LOG_BASE_LOW_OFFSET:
> -        val = reg_to_u64(iommu->event_log.reg_base);
> -        break;
> -    case IOMMU_PPR_LOG_BASE_LOW_OFFSET:
> -        val = reg_to_u64(iommu->ppr_log.reg_base);
> -        break;
> -    case IOMMU_CMD_BUFFER_HEAD_OFFSET:
> -        val = reg_to_u64(iommu->cmd_buffer.reg_head);
> -        break;
> -    case IOMMU_CMD_BUFFER_TAIL_OFFSET:
> -        val = reg_to_u64(iommu->cmd_buffer.reg_tail);
> -        break;
> -    case IOMMU_EVENT_LOG_HEAD_OFFSET:
> -        val = reg_to_u64(iommu->event_log.reg_head);
> -        break;
> -    case IOMMU_EVENT_LOG_TAIL_OFFSET:
> -        val = reg_to_u64(iommu->event_log.reg_tail);
> -        break;
> -    case IOMMU_PPR_LOG_HEAD_OFFSET:
> -        val = reg_to_u64(iommu->ppr_log.reg_head);
> -        break;
> -    case IOMMU_PPR_LOG_TAIL_OFFSET:
> -        val = reg_to_u64(iommu->ppr_log.reg_tail);
> -        break;
> -    case IOMMU_CONTROL_MMIO_OFFSET:
> -        val = iommu->reg_ctrl.raw;
> -        break;
> -    case IOMMU_STATUS_MMIO_OFFSET:
> -        val = reg_to_u64(iommu->reg_status);
> -        break;
> -    case IOMMU_EXT_FEATURE_MMIO_OFFSET:
> -        val = iommu->reg_ext_feature.raw;
> -        break;
> -
> -    default:
> -        AMD_IOMMU_DEBUG("Guest reads unknown mmio offset = %lx\n", offset);
> -        val = 0;
> -        break;
> -    }
> -
> -    return val;
> -}
> -
> -static int cf_check guest_iommu_mmio_read(
> -    struct vcpu *v, unsigned long addr, unsigned int len, unsigned long *pval)
> -{
> -    struct guest_iommu *iommu = vcpu_iommu(v);
> -    unsigned long offset;
> -    uint64_t val;
> -    uint32_t mmio, shift;
> -    uint64_t mask = 0;
> -
> -    offset = addr - iommu->mmio_base;
> -
> -    if ( unlikely((offset & (len - 1 )) || (len > 8)) )
> -    {
> -        AMD_IOMMU_DEBUG("iommu mmio read access is not aligned:"
> -                        " offset = %lx, len = %x\n", offset, len);
> -        return X86EMUL_UNHANDLEABLE;
> -    }
> -
> -    mask = (len == 8) ? ~0ULL : (1ULL << (len * 8)) - 1;
> -    shift = (offset & 7u) * 8;
> -
> -    /* mmio access is always aligned on 8-byte boundary */
> -    mmio = offset & (~7u);
> -
> -    spin_lock(&iommu->lock);
> -    val = iommu_mmio_read64(iommu, mmio);
> -    spin_unlock(&iommu->lock);
> -
> -    *pval = (val >> shift ) & mask;
> -
> -    return X86EMUL_OKAY;
> -}
> -
> -static void guest_iommu_mmio_write64(struct guest_iommu *iommu,
> -                                    unsigned long offset, uint64_t val)
> -{
> -    switch ( offset )
> -    {
> -    case IOMMU_DEV_TABLE_BASE_LOW_OFFSET:
> -        u64_to_reg(&iommu->dev_table.reg_base, val);
> -        break;
> -    case IOMMU_CMD_BUFFER_BASE_LOW_OFFSET:
> -        u64_to_reg(&iommu->cmd_buffer.reg_base, val);
> -        break;
> -    case IOMMU_EVENT_LOG_BASE_LOW_OFFSET:
> -        u64_to_reg(&iommu->event_log.reg_base, val);
> -        break;
> -    case IOMMU_PPR_LOG_BASE_LOW_OFFSET:
> -        u64_to_reg(&iommu->ppr_log.reg_base, val);
> -        break;
> -    case IOMMU_CONTROL_MMIO_OFFSET:
> -        guest_iommu_write_ctrl(iommu, val);
> -        break;
> -    case IOMMU_CMD_BUFFER_HEAD_OFFSET:
> -        iommu->cmd_buffer.reg_head.lo = val & IOMMU_RING_BUFFER_PTR_MASK;
> -        break;
> -    case IOMMU_CMD_BUFFER_TAIL_OFFSET:
> -        iommu->cmd_buffer.reg_tail.lo = val & IOMMU_RING_BUFFER_PTR_MASK;
> -        tasklet_schedule(&iommu->cmd_buffer_tasklet);
> -        break;
> -    case IOMMU_EVENT_LOG_HEAD_OFFSET:
> -        iommu->event_log.reg_head.lo = val & IOMMU_RING_BUFFER_PTR_MASK;
> -        break;
> -    case IOMMU_EVENT_LOG_TAIL_OFFSET:
> -        iommu->event_log.reg_tail.lo = val & IOMMU_RING_BUFFER_PTR_MASK;
> -        break;
> -    case IOMMU_PPR_LOG_HEAD_OFFSET:
> -        iommu->ppr_log.reg_head.lo = val & IOMMU_RING_BUFFER_PTR_MASK;
> -        break;
> -    case IOMMU_PPR_LOG_TAIL_OFFSET:
> -        iommu->ppr_log.reg_tail.lo = val & IOMMU_RING_BUFFER_PTR_MASK;
> -        break;
> -    case IOMMU_STATUS_MMIO_OFFSET:
> -        val &= IOMMU_STATUS_EVENT_LOG_OVERFLOW |
> -               IOMMU_STATUS_EVENT_LOG_INT |
> -               IOMMU_STATUS_COMP_WAIT_INT |
> -               IOMMU_STATUS_PPR_LOG_OVERFLOW |
> -               IOMMU_STATUS_PPR_LOG_INT |
> -               IOMMU_STATUS_GAPIC_LOG_OVERFLOW |
> -               IOMMU_STATUS_GAPIC_LOG_INT;
> -        u64_to_reg(&iommu->reg_status, reg_to_u64(iommu->reg_status) & ~val);
> -        break;
> -
> -    default:
> -        AMD_IOMMU_DEBUG("guest writes unknown mmio offset = %lx,"
> -                        " val = %" PRIx64 "\n", offset, val);
> -        break;
> -    }
> -}
> -
> -static int cf_check guest_iommu_mmio_write(
> -    struct vcpu *v, unsigned long addr, unsigned int len, unsigned long val)
> -{
> -    struct guest_iommu *iommu = vcpu_iommu(v);
> -    unsigned long offset;
> -    uint64_t reg_old, mmio;
> -    uint32_t shift;
> -    uint64_t mask = 0;
> -
> -    offset = addr - iommu->mmio_base;
> -
> -    if ( unlikely((offset & (len - 1)) || (len > 8)) )
> -    {
> -        AMD_IOMMU_DEBUG("iommu mmio write access is not aligned:"
> -                        " offset = %lx, len = %x\n", offset, len);
> -        return X86EMUL_UNHANDLEABLE;
> -    }
> -
> -    mask = (len == 8) ? ~0ULL : (1ULL << (len * 8)) - 1;
> -    shift = (offset & 7) * 8;
> -
> -    /* mmio access is always aligned on 8-byte boundary */
> -    mmio = offset & ~7;
> -
> -    spin_lock(&iommu->lock);
> -
> -    reg_old = iommu_mmio_read64(iommu, mmio);
> -    reg_old &= ~(mask << shift);
> -    val = reg_old | ((val & mask) << shift);
> -    guest_iommu_mmio_write64(iommu, mmio, val);
> -
> -    spin_unlock(&iommu->lock);
> -
> -    return X86EMUL_OKAY;
> -}
> -
> -int guest_iommu_set_base(struct domain *d, uint64_t base)
> -{
> -    p2m_type_t t;
> -    struct guest_iommu *iommu = domain_iommu(d);
> -
> -    if ( !iommu )
> -        return -EACCES;
> -
> -    iommu->mmio_base = base;
> -    base >>= PAGE_SHIFT;
> -
> -    for ( int i = 0; i < IOMMU_MMIO_PAGE_NR; i++ )
> -    {
> -        unsigned long gfn = base + i;
> -
> -        get_gfn_query(d, gfn, &t);
> -        p2m_change_type_one(d, gfn, t, p2m_mmio_dm);
> -        put_gfn(d, gfn);
> -    }
> -
> -    return 0;
> -}
> -
> -/* Initialize mmio read only bits */
> -static void guest_iommu_reg_init(struct guest_iommu *iommu)
> -{
> -    union amd_iommu_ext_features ef = {
> -        /* Support prefetch */
> -        .flds.pref_sup = 1,
> -        /* Support PPR log */
> -        .flds.ppr_sup = 1,
> -        /* Support guest translation */
> -        .flds.gt_sup = 1,
> -        /* Support invalidate all command */
> -        .flds.ia_sup = 1,
> -        /* Host translation size has 6 levels */
> -        .flds.hats = HOST_ADDRESS_SIZE_6_LEVEL,
> -        /* Guest translation size has 6 levels */
> -        .flds.gats = GUEST_ADDRESS_SIZE_6_LEVEL,
> -        /* Single level gCR3 */
> -        .flds.glx_sup = GUEST_CR3_1_LEVEL,
> -        /* 9 bit PASID */
> -        .flds.pas_max = PASMAX_9_bit,
> -    };
> -
> -    iommu->reg_ext_feature = ef;
> -}
> -
> -static int cf_check guest_iommu_mmio_range(struct vcpu *v, unsigned long addr)
> -{
> -    struct guest_iommu *iommu = vcpu_iommu(v);
> -
> -    return iommu && addr >= iommu->mmio_base &&
> -           addr < iommu->mmio_base + IOMMU_MMIO_SIZE;
> -}
> -
> -static const struct hvm_mmio_ops iommu_mmio_ops = {
> -    .check = guest_iommu_mmio_range,
> -    .read = guest_iommu_mmio_read,
> -    .write = guest_iommu_mmio_write
> -};
> -
> -/* Domain specific initialization */
> -int guest_iommu_init(struct domain* d)
> -{
> -    struct guest_iommu *iommu;
> -    struct domain_iommu *hd = dom_iommu(d);
> -
> -    if ( !is_hvm_domain(d) || !is_iommu_enabled(d) || !iommuv2_enabled ||
> -         !has_viommu(d) )
> -        return 0;
> -
> -    iommu = xzalloc(struct guest_iommu);
> -    if ( !iommu )
> -    {
> -        AMD_IOMMU_DEBUG("Error allocating guest iommu structure.\n");
> -        return 1;
> -    }
> -
> -    guest_iommu_reg_init(iommu);
> -    iommu->mmio_base = ~0ULL;
> -    iommu->domain = d;
> -    hd->arch.amd.g_iommu = iommu;
> -
> -    tasklet_init(&iommu->cmd_buffer_tasklet, guest_iommu_process_command, d);
> -
> -    spin_lock_init(&iommu->lock);
> -
> -    register_mmio_handler(d, &iommu_mmio_ops);
> -
> -    return 0;
> -}
> -
> -void guest_iommu_destroy(struct domain *d)
> -{
> -    struct guest_iommu *iommu;
> -
> -    iommu = domain_iommu(d);
> -    if ( !iommu )
> -        return;
> -
> -    tasklet_kill(&iommu->cmd_buffer_tasklet);
> -    xfree(iommu);
> -
> -    dom_iommu(d)->arch.amd.g_iommu = NULL;
> -}
> -- 
> 2.34.1
> 


From xen-devel-bounces@lists.xenproject.org Sat Mar 16 00:34:51 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 16 Mar 2024 00:34:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694115.1083003 (Exim 4.92)
	(envelope-from )
	id 1rlI0V-00022U-Ox; Sat, 16 Mar 2024 00:34:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694115.1083003; Sat, 16 Mar 2024 00:34:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rlI0V-00022N-MI; Sat, 16 Mar 2024 00:34:39 +0000
Received: by outflank-mailman (input) for mailman id 694115;
 Sat, 16 Mar 2024 00:34:37 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rlI0T-00021z-KU
 for xen-devel@lists.xenproject.org; Sat, 16 Mar 2024 00:34:37 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org
 [2604:1380:4641:c500::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f64bfc2e-e32c-11ee-afdd-a90da7624cb6;
 Sat, 16 Mar 2024 01:34:35 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id D24CC617D4;
 Sat, 16 Mar 2024 00:34:33 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id ECFAAC433F1;
 Sat, 16 Mar 2024 00:34:31 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f64bfc2e-e32c-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1710549273;
	bh=2N548LDkvepe6zAL+QNEn7rCR0gImlwCNrHAwH+2Tok=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=T0Ab4DRp/k5lCq62vCX1yUlK7pIaRkgBqiX54PKIxn64bwnKEzDtfRgUxEWpahUxi
	 AJRIKNHfjzHhmeed1oacMheRth6AHrdtAMIXSkFeQ4Vu7Da8Un/I7h/V5GKQltRIw5
	 YGq+Kto9nR8gHy44QNqlmMmgal+T5iaqV1rJqwpPfKPk0yNLu3ruYXvN/69O4LaoKh
	 kgVsha4iFW5PXRftyw280SHqTRyZhdXljtXAs9AKgV8MyKRRBGSNszmNrhB3LSF1sf
	 lk1QajkA2O/pXTV6f5nNN7TZcMMeeVrDEUsM3rBURmaqG7Ue0E2UdxdnBvAtqhTV3r
	 /6Gei1v2vZtfw==
Date: Fri, 15 Mar 2024 17:34:29 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich 
cc: Stefano Stabellini , 
    Simone Ballarin , consulting@bugseng.com, 
    Andrew Cooper , 
    George Dunlap , Julien Grall , 
    Wei Liu , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    xen-devel@lists.xenproject.org
Subject: Re: [XEN PATCH v3 01/16] misra: add deviation for headers that
 explicitly avoid guards
In-Reply-To: <2ea3d566-1b21-44e6-bdb6-7c554a7f7996@suse.com>
Message-ID: 
References:  <310fe4a0ccd0ad45bcf1cd9811ac56c9a560dd0b.1710145041.git.simone.ballarin@bugseng.com>  
 <2ea3d566-1b21-44e6-bdb6-7c554a7f7996@suse.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Fri, 15 Mar 2024, Jan Beulich wrote:
> On 14.03.2024 23:55, Stefano Stabellini wrote:
> > On Mon, 11 Mar 2024, Jan Beulich wrote:
> >> On 11.03.2024 09:59, Simone Ballarin wrote:
> >>> Some headers, under specific circumstances (documented in a comment at
> >>> the beginning of the file), explicitly avoid inclusion guards: the caller
> >>> is responsible for including them correctly.
> >>>
> >>> These files are not supposed to comply with Directive 4.10:
> >>> "Precautions shall be taken in order to prevent the contents of a header
> >>> file being included more than once"
> >>>
> >>> This patch adds deviation cooments for headers that avoid guards.
> >>>
> >>> Signed-off-by: Simone Ballarin 
> >>>
> >>> ---
> >>> Changes in v3:
> >>> - fix inconsistent deviation ID
> >>> - change comment-based deviation text
> >>> Changes in v2:
> >>> - use the format introduced with doc/misra/safe.json instead of
> >>>   a generic text-based deviation
> >>> ---
> >>>  docs/misra/safe.json                        | 9 +++++++++
> >>>  xen/include/public/arch-x86/cpufeatureset.h | 1 +
> >>>  xen/include/public/errno.h                  | 1 +
> >>>  3 files changed, 11 insertions(+)
> >>
> >> I understand something wants doing, but having such comments appear in public
> >> headers feels wrong to me. I'm afraid I have no good alternative suggestion.
> > 
> > Given that in both cases there is very nice explanation on how to use
> > the headers as an in-code comment just above, could we embed the
> > SAF-3-safe marker in the existing comment?
> 
> I'm afraid that won't address my remark, and I'm further afraid this would
> then render the SAF part of the comment ineffectual.
> 
> > If not, I think we should go with this patch as is (I don't think it is
> > worth my, your, and Simone's time to look for alternatives).
> 
> Easy alternative: Simply leave public headers alone.

I don't think it is a good idea to skip MISRA on public headers as they
are used as part of the Xen build. I think adding the one line SAF
comment is better.

We still have strange tags like the following in public headers:

 * `incontents 150 evtchn Event Channels

What does `incontents 150 even mean? If I grep for "incontents" I cannot
find any explanation or definition. The SAF comment is easily greppable
and with a clear definition. I am in favor of adding them (and removing
"incontents" but that's a discussion for another day.) 


From xen-devel-bounces@lists.xenproject.org Sat Mar 16 00:44:12 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 16 Mar 2024 00:44:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694118.1083013 (Exim 4.92)
	(envelope-from )
	id 1rlI9f-0003lK-Kd; Sat, 16 Mar 2024 00:44:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694118.1083013; Sat, 16 Mar 2024 00:44:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rlI9f-0003lD-Hp; Sat, 16 Mar 2024 00:44:07 +0000
Received: by outflank-mailman (input) for mailman id 694118;
 Sat, 16 Mar 2024 00:44:06 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rlI9e-0003l7-FF
 for xen-devel@lists.xenproject.org; Sat, 16 Mar 2024 00:44:06 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 487cab6e-e32e-11ee-a1ee-f123f15fe8a2;
 Sat, 16 Mar 2024 01:44:02 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 48D2B616F9;
 Sat, 16 Mar 2024 00:44:01 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3FF22C433F1;
 Sat, 16 Mar 2024 00:43:59 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 487cab6e-e32e-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1710549840;
	bh=QE5XGarWmoRSKRE8AAfh+YEqBZRH8OunkXGkNAfGg78=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=nARYcesV8NaOJ2Fjh/Lj84aDxeGFQGG++Mb/HoDMQK2Ypp5HuebvStA1UmqeGD+rB
	 zbWiI4bupGfK90PSXsctVbLufwMebf978Z9ZAIugkdAIqBwOZk619MKyLcW/ExX6Cj
	 Dwy1TSz/44OypTJa5Oq99s35JyLpou1a/wqw6S1k5qye+Zu+dsqxVe0fWTdjjGRF7D
	 Gy4L0EgrX7Wq5ifhgk9mb3YUScMzg0UGnRsHKFqkvzCGqbeFMrmhFjsr4d9EZHlw9M
	 J4ivBUXRepqB/LYYO1eBiqpnWGpJqs/ucj6wwlyGsu+Okw2Hwsiyt4rK4G5vrvQzC4
	 e2tJ13AOus7BQ==
Date: Fri, 15 Mar 2024 17:43:57 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich 
cc: Stefano Stabellini , consulting@bugseng.com, 
    Andrew Cooper , 
    George Dunlap , Julien Grall , 
    Wei Liu , Bertrand Marquis , 
    Michal Orzel , 
    Volodymyr Babchuk , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    xen-devel@lists.xenproject.org, 
    Simone Ballarin 
Subject: Re: [XEN PATCH v3 03/16] misra: add deviations for direct inclusion
 guards
In-Reply-To: <077c0373-6eec-4403-b31e-574c8e8ae067@suse.com>
Message-ID: 
References:  <1fdfec12fd2207c294f50d01d8ec32f890b915d7.1710145041.git.simone.ballarin@bugseng.com>  <6472eb42-157a-4d6e-b5bb-daa74fbbd97b@bugseng.com>
  <3e4bb597-3624-418e-93d0-b95042fd27a7@bugseng.com>  <077c0373-6eec-4403-b31e-574c8e8ae067@suse.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Fri, 15 Mar 2024, Jan Beulich wrote:
> On 14.03.2024 23:59, Stefano Stabellini wrote:
> > On Mon, 11 Mar 2024, Simone Ballarin wrote:
> >> On 11/03/24 14:56, Jan Beulich wrote:
> >>> On 11.03.2024 13:00, Simone Ballarin wrote:
> >>>> On 11/03/24 11:08, Jan Beulich wrote:
> >>>>> On 11.03.2024 09:59, Simone Ballarin wrote:
> >>>>>> --- a/xen/arch/arm/include/asm/hypercall.h
> >>>>>> +++ b/xen/arch/arm/include/asm/hypercall.h
> >>>>>> @@ -1,3 +1,4 @@
> >>>>>> +/* SAF-5-safe direct inclusion guard before */
> >>>>>>    #ifndef __XEN_HYPERCALL_H__
> >>>>>>    #error "asm/hypercall.h should not be included directly - include
> >>>>>> xen/hypercall.h instead"
> >>>>>>    #endif
> >>>>>> --- a/xen/arch/x86/include/asm/hypercall.h
> >>>>>> +++ b/xen/arch/x86/include/asm/hypercall.h
> >>>>>> @@ -2,6 +2,7 @@
> >>>>>>     * asm-x86/hypercall.h
> >>>>>>     */
> >>>>>>    +/* SAF-5-safe direct inclusion guard before */
> >>>>>>    #ifndef __XEN_HYPERCALL_H__
> >>>>>>    #error "asm/hypercall.h should not be included directly - include
> >>>>>> xen/hypercall.h instead"
> >>>>>>    #endif
> >>>>>
> >>>>> Iirc it was said that this way checking for correct guards is suppressed
> >>>>> altogether in Eclair, which is not what we want. Can you clarify this,
> >>>>> please?
> >>>>>
> >>>>
> >>>> My first change was moving this check inside the guard.
> >>>> You commented my patch saying that this would be an error because someone
> >>>> can
> >>>> include it directly if it has already been included indirectly.
> >>>> I replied telling that this was the case also before the change.
> >>>> You agreed with me, and we decided that the correct thing would be fixing
> >>>> the
> >>>> check and not apply my temporary change to address the finding.
> >>>>
> >>>> Considering that the code should be amended, a SAF deviation seems to me
> >>>> the most appropriate way for suppressing these findings.
> >>>
> >>> Since I don't feel your reply addresses my question, asking differently:
> >>> With
> >>> your change in place, will failure to have proper guards (later) in these
> >>> headers still be reported by Eclair?
> >>
> >> No, if you put something between the check and the guard,
> >> no violation will be reported.
> > 
> > From this email exchange I cannot under if Jan is OK with this patch or
> > not.
> 
> Whether I'm okay(ish) with the patch here depends on our position towards
> the lost checking in Eclair mentioned above. To me it still looks relevant
> that checking for a guard occurs, even if that isn't first in a file for
> some specific reason.

More checking is better than less checking, but if we cannot find a
simple and actionable way forward on this violation, deviating it is
still a big improvement because it allows us to enable the ECLAIR Dir
4.10 checks in xen.git overall (which again goes back to more checking
is better than less checking). 

Do you have a simple alternative suggestion? If not, this is still an
improvement.


From xen-devel-bounces@lists.xenproject.org Sat Mar 16 01:19:00 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 16 Mar 2024 01:19:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694121.1083022 (Exim 4.92)
	(envelope-from )
	id 1rlIhI-0007fk-5O; Sat, 16 Mar 2024 01:18:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694121.1083022; Sat, 16 Mar 2024 01:18:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rlIhI-0007fd-2N; Sat, 16 Mar 2024 01:18:52 +0000
Received: by outflank-mailman (input) for mailman id 694121;
 Sat, 16 Mar 2024 01:18:51 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rlIhH-0007cO-67; Sat, 16 Mar 2024 01:18:51 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rlIhG-0000F4-W9; Sat, 16 Mar 2024 01:18:51 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rlIhG-0000jA-Jr; Sat, 16 Mar 2024 01:18:50 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rlIhG-00047N-JH; Sat, 16 Mar 2024 01:18:50 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=kim00YMr5Eo6dWakeg7zaxsqKcJ+KFm2lZLJbQAcldg=; b=pMW7Lc5lLKwBEDPmK/ZsgpMdJd
	ZFomphSNlGKGFKEhmjL+Fi8RWTJHR61gXR3u+sTu+qJy2UpTZWjQKjT9AnshtUva1EH5wwFQ29hki
	7vj7ySNQL11E8GXa4k4486UXrgqViMTuq/5rtQuqjuu3UXDD8RDS4ri66S00vbXmdgoc=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 185051: tolerable FAIL - PUSHED
X-Osstest-Failures:
    xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
    xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-i386-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
X-Osstest-Versions-This:
    xen=d638e304f13a5ef7d125de5ace5f7828a7b25bac
X-Osstest-Versions-That:
    xen=af7fed3fdf82981ebbb09628b278df957569333d
From: osstest service owner 
Date: Sat, 16 Mar 2024 01:18:50 +0000

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen                  d638e304f13a5ef7d125de5ace5f7828a7b25bac
baseline version:
 xen                  af7fed3fdf82981ebbb09628b278df957569333d

Last test of basis   185036  2024-03-14 16:08:13 Z    1 days
Testing same since   185045  2024-03-15 05:12:15 Z    0 days    2 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper 
  Ayan Kumar Halder 
  Julien Grall 
  Michal Orzel 

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-i386-examine-bios                                 pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-armhf-armhf-libvirt-qcow2                               pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-libvirt-raw                                  pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-i386-examine-uefi                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-arm64-arm64-xl-vhd                                      pass    
 test-armhf-armhf-xl-vhd                                      pass    
 test-amd64-i386-xl-vhd                                       pass    


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

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

Explanation of these 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
   af7fed3fdf..d638e304f1  d638e304f13a5ef7d125de5ace5f7828a7b25bac -> master


From xen-devel-bounces@lists.xenproject.org Sat Mar 16 03:23:23 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 16 Mar 2024 03:23:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694135.1083048 (Exim 4.92)
	(envelope-from )
	id 1rlKdW-0007XZ-38; Sat, 16 Mar 2024 03:23:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694135.1083048; Sat, 16 Mar 2024 03:23:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rlKdW-0007XS-0e; Sat, 16 Mar 2024 03:23:06 +0000
Received: by outflank-mailman (input) for mailman id 694135;
 Sat, 16 Mar 2024 03:23:04 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rlKdU-0007XM-Ir
 for xen-devel@lists.xenproject.org; Sat, 16 Mar 2024 03:23:04 +0000
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com
 [66.111.4.29]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7e261e40-e344-11ee-a1ee-f123f15fe8a2;
 Sat, 16 Mar 2024 04:23:01 +0100 (CET)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.46])
 by mailout.nyi.internal (Postfix) with ESMTP id 5D1D05C004F;
 Fri, 15 Mar 2024 23:23:00 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162])
 by compute2.internal (MEProxy); Fri, 15 Mar 2024 23:23:00 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri,
 15 Mar 2024 23:22:59 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7e261e40-e344-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-type:content-type:date
	:date:from:from:in-reply-to:message-id:mime-version:reply-to
	:subject:subject:to:to; s=fm1; t=1710559380; x=1710645780; bh=JG
	KYRygn5+9kiCBHJyMLdgRVPh3h1+QHe7wMvEDshX4=; b=IcKkSERbS/GWt9n5ac
	NtsdYKqbxPnMZJ45Scp6hBk43AtiEw+JPQCX33ddogfP8c8QVcd2BPdfxxPhcKTx
	0P04TYcudKJumskb4LaSwEJyLR57txdKkwaIsfZVfu1sMQUM9Ps6UGlE8toP5lZJ
	CohbAf3EJcI5BbiIwxc2jdM57oPcYRCcPDtjaFEb8/hXVPferDxzTMHyUhFk9nE9
	0wNfo6LhjeiGcs/ISNbnqZB9PUXWbLB1+QkFL9ury3NSgaZawMOjk7nZvg/pAsx3
	zeVeg83aRJyDn+tDoRibECimS7OwDQSSTfyc3Fv8O2DJgJT+WjSqsI+/97lkHkz6
	XfQw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-type:content-type:date:date
	:feedback-id:feedback-id:from:from:in-reply-to:message-id
	:mime-version:reply-to:subject:subject:to:to:x-me-proxy
	:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=
	1710559380; x=1710645780; bh=JGKYRygn5+9kiCBHJyMLdgRVPh3h1+QHe7w
	MvEDshX4=; b=qOuAL5SNITcwXg1l/GzJJRTIKI0rRUeKNYjyQbmg1pxMKR22otT
	GNYtLweSrclIOb07JMURQ5OdVN+QZfW+RwQfJVAxQqwdh4wKVGBq4Jo6G0WLoED2
	V8ZImSbiYFeZJA6UGMh6yZh4PXB4iPbWvn7OcQAh7HRm3IK7OVNRxXDprHhMdkaa
	xrtDEOFbt7tmZ5UeGIULIUdvGG8Wvk9ko0CHfAEnoCSwN6VddQ62toaj48BqUO4f
	p+EvDPYfm7HI4MppcG7YyPSMjg8NOqH3meP0Onoh/aVozxIWsZuz+mplLqqqL/hv
	GFhaFCncsPZDny6CDRkoRe1hHVkOn8HQj2A==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrkedtgdehkecutefuodetggdotefrodftvf
    curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
    uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc
    fjughrpeffhffvvefukfggtggusehgtderredttdejnecuhfhrohhmpeforghrvghkucfo
    rghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvhhish
    hisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpeduheeltdek
    kefgieekjeejiefgvefhudfhvdduhfdtvedufeefhfehteehieehteenucffohhmrghinh
    epkhgvrhhnvghlrdhorhhgpdhgihhthhhusgdrtghomhenucevlhhushhtvghrufhiiigv
    pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhesihhnvhhishhisg
    hlvghthhhinhhgshhlrggsrdgtohhm
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Sat, 16 Mar 2024 04:22:53 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: xen-devel 
Cc: Stefano Stabellini ,
	Simon Gaiser 
Subject: Status of S0ix with Xen
Message-ID: 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="PeMlmw02okIHY8Dx"
Content-Disposition: inline


--PeMlmw02okIHY8Dx
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Sat, 16 Mar 2024 04:22:53 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: xen-devel 
Cc: Stefano Stabellini ,
	Simon Gaiser 
Subject: Status of S0ix with Xen

Hi,

S0ix came up in a recent discussion, so let me post a small status
update. We have patches that makes Qubes suspend with ~90% S0ix
residency. It's significantly worse than native Linux on the same system
- that gets 99+%, but still a significant progress.
We do have a tricky case though, because we use PCI passthrough, with
stubdomains.

A summary of changes required is posted by Simon in a tracking issue[1],
but let me post it here too:

    So currently on my test system (NUC11TNHi5) I'm being able to reach
    S0ix residency with only dom0 running for nearly 90=E2=80=AF% of the su=
spend to
    idle time. (That's still worse than native Linux with >=C2=A099=E2=80=
=AF%.)

    Used changes:

     - Xen
       - Disable HPET legacy mode after it has been userd for IOAPIC
         test during boot ([upstream discussion](https://lore.kernel.org/xe=
n-devel/cb408368-077d-edb5-b4ad-f80086db48c1@invisiblethingslab.com/),
         including minimally required diff)
       - Tiger Lake support in Xen's mwait-idle driver. Unlike Linux'
         version of that driver Xen's only supports the CPUs for which
         it contains a hardcoded config. For the moment I just manualy adde=
d the
         config Linux is reading from ACPI. Needs to be tested if this is
         actually required (see also
         [Jan's comment](https://lore.kernel.org/xen-devel/f6c27788-bdd9-e5=
b1-a874-7f48a27c66a9@suse.com/))
       - Allow reading of S0ix related MSRs. Not sure if any of them is
         strictly required to get into S0ix states, but at the very
         least you want them to be able to debug things (for example via
         `/sys/kernel/debug/pmc_core/...`)
       - Teach `cpu_idle.c` that Tiger Lake also has PC{8..10} (for proper =
debug output)
       - Disable `ondemand` cpufreq governor (both `powersave` as well as `=
perfromance` work)
     - Linux in dom0
       - Add wakup support to `xen-pirq`
         ([patch](https://lore.kernel.org/xen-devel/20230313134102.3157-1-s=
imon@invisiblethingslab.com/) sent upstream)
       - If using a SATA device you need to enable low power mode for
         link management (`echo min_power > /sys/class/scsi_host/host0/link=
_power_management_policy`, tried to get
         it [enabled by default](https://lore.kernel.org/linux-ide/20230213=
102450.1604-1-simon@invisiblethingslab.com/)
         but that's
         [not so easy](https://lore.kernel.org/linux-ide/ad02467d-d623-5933=
-67e0-09925c185568@leemhuis.info))

    First tests with a running guest and investigating the difference to
    native Linux are progress (the later is probably due to some timer).

Since the above update, few more things came up:
1. Thunderbolt driver in Linux does not support suspending when kernel
is built with CONFIG_HOTPLUG_PCI=3Dn (which is the case in Qubes). We have
a hacky workaround at [2] (the first patch), together with more details
about the issue in the patch description.

2. When toolstack issues "suspend" command (via xenstore
control/shutdown), Linux uses "freeze" path, that doesn't put devices
into low power state. Changing that to "suspend" path helps (the second
patch in [2]), and for our case seems to have no negative consequences.
But we do not use live migration nor save/restore - which is another use
of this feature, and we have not tested if this still works.

3. QEMU emulates (instead of passthrough) power management related
config space. This is fixed at [3]

The relevant patches are all linked in pull requests connected to the issue.

This is still work in progress. Some of the patches were already posted
to relevant mailing lists, other still require some more work and will
be posted later. I'm posting it here mostly to share that we are working
on it. But also, if anybody wants to try it out and maybe help
improving, the patches are out there.

[1] https://github.com/QubesOS/qubes-issues/issues/6411#issuecomment-153808=
9344
[2] https://github.com/QubesOS/qubes-linux-kernel/pull/910/files
[3] https://github.com/QubesOS/qubes-vmm-xen-stubdom-linux/pull/63/files
--=20
Best Regards,
Marek Marczykowski-G=C3=B3recki
Invisible Things Lab

--PeMlmw02okIHY8Dx
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmX1EI4ACgkQ24/THMrX
1ywKngf/WbytYRhVxqGN+4F/FXKdP8I2vfrQTWYOK6FpP7vAuijgaTBtO6Z3Q5VK
izGubqVrrANF5xw+fsalsbXwsbE+Z/kjzHz9qGKzjBrnqu0hK7nxArDcRmGbH4ej
+uacy3SmY7fU6OxBzEtYbzomq9MF+ZgNrzQ63luO6g0c1vsRcdF3gFxKEpXArnQD
wUlqhJ4fnNRaKQQuEk9VZp1/eaN5nUTNEse1zz36z7FM0qWKmaTPQfuCfMTsRvZo
q3dwbnnyr8pXOw6isae47BWurkSErJkZ6UWfFuKdvpxqv+1mxJCjwZJW7ft/+eLn
dXVV9QOWUNQbegJapSwC6A5sW+0hKw==
=aNDT
-----END PGP SIGNATURE-----

--PeMlmw02okIHY8Dx--


From xen-devel-bounces@lists.xenproject.org Sat Mar 16 04:01:28 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 16 Mar 2024 04:01:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694139.1083058 (Exim 4.92)
	(envelope-from )
	id 1rlLEX-0004YM-W3; Sat, 16 Mar 2024 04:01:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694139.1083058; Sat, 16 Mar 2024 04:01:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rlLEX-0004YF-Ss; Sat, 16 Mar 2024 04:01:21 +0000
Received: by outflank-mailman (input) for mailman id 694139;
 Sat, 16 Mar 2024 04:01:20 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rlLEW-0004Y9-R4
 for xen-devel@lists.xenproject.org; Sat, 16 Mar 2024 04:01:20 +0000
Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com
 [64.147.123.21]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d561ee04-e349-11ee-afdd-a90da7624cb6;
 Sat, 16 Mar 2024 05:01:18 +0100 (CET)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.47])
 by mailout.west.internal (Postfix) with ESMTP id 15D95320010B;
 Sat, 16 Mar 2024 00:01:12 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163])
 by compute6.internal (MEProxy); Sat, 16 Mar 2024 00:01:13 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat,
 16 Mar 2024 00:01:11 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d561ee04-e349-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-type:content-type:date
	:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to; s=fm1; t=1710561672;
	 x=1710648072; bh=RDB0VzEGZIjYO7+eYsNfBjQXMjBAGaY8KxMVv2LWsp8=; b=
	ZCySQg06GLcTcy9RbUuNqPvNgNU/rBPwRLb9zgeDy6bU3Fa2HrUpJCPErtIC1Bdm
	pb/jarLjRbakRj5V0lUAWzPj2r2QXEpq669Xf+KDPAOv3/tcPRuZqJEwmZD5ilxb
	uFdJZgDKpr5tvaz0W5IkENU074ZVb+q+M7HX2ZSzqeMie8GEF4VZA68JLUI7KLif
	08o3nc1SPrPxVTq2rXh9srk0qUr1IblsfhDPg56YEk+7mCqxsUaEbRCpYnt2QfVu
	fcmQ0P9TB5n2bwqmYEu7e6PPYlO/WlG2ZLwFR2fXexwpIbrKS3GbR0hDQvhSNApM
	bw/rRrZRIum4hHUrtppvGw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-type:content-type:date:date
	:feedback-id:feedback-id:from:from:in-reply-to:in-reply-to
	:message-id:mime-version:references:reply-to:subject:subject:to
	:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=
	fm1; t=1710561672; x=1710648072; bh=RDB0VzEGZIjYO7+eYsNfBjQXMjBA
	GaY8KxMVv2LWsp8=; b=P2zNmKbNrMWMeSutXTfBhKv8khjXimSRw7CEUT8GEaCq
	y6+4WJGnJK25P2KErUZRV0d2z/7bDQDai+CG9xmOgb8JB2xhRRfAoux7fjETxzNR
	M+r0pzCSDotbpUhcBrzXHd2vhGBBMeA9H4uw9f8wfuoopj7rrAeHuqySxgxG48Tu
	+IQ5Us56DUVxe/O3WQVTMJs//VvYrrAP6rTH0XhaQ3pP58A2MDXouHlmK3HfinkR
	fYqYBuMQC/3EdalDeLXSHWvPMelyi3k8l3DNju8ihnIGkhpKmce9E12WW8oo019G
	L58+PB+k0+fFxt+MRYLdOn7S1FzIIbxAOFvrOZFF0Q==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrkedtgdeiiecutefuodetggdotefrodftvf
    curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
    uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc
    fjughrpefkffgguffvvehfhfgjtgesghdtreertddtjeenucfhrhhomhepufhimhhonhcu
    ifgrihhsvghruceoshhimhhonhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtoh
    hmqeenucggtffrrghtthgvrhhnpeeggeevtdefudehleefgeetvedtudeghfeifeegleff
    kedthefgiedvudefvddvudenucffohhmrghinhepghhithhhuhgsrdgtohhmnecuvehluh
    hsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepshhimhhonhesihhn
    vhhishhisghlvghthhhinhhgshhlrggsrdgtohhm
X-ME-Proxy: 
    
    
    
    
Feedback-ID: idc5945a3:Fastmail
Message-ID: <940f93dc-37cb-499c-9e48-1898e12ce053@invisiblethingslab.com>
Date: Sat, 16 Mar 2024 05:00:59 +0100
MIME-Version: 1.0
Subject: Re: Status of S0ix with Xen
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 , xen-devel 
Cc: Stefano Stabellini 
References: 
Content-Language: en-US
From: Simon Gaiser 
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------yxpE2F20G0aRgWgcKvscgSK9"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------yxpE2F20G0aRgWgcKvscgSK9
Content-Type: multipart/mixed; boundary="------------mSao4Len6MXjiPCP9pgZk61S";
 protected-headers="v1"
From: Simon Gaiser 
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 , xen-devel 
Cc: Stefano Stabellini 
Message-ID: <940f93dc-37cb-499c-9e48-1898e12ce053@invisiblethingslab.com>
Subject: Re: Status of S0ix with Xen
References: 
In-Reply-To: 
Autocrypt-Gossip: addr=marmarek@invisiblethingslab.com;
 keydata= xsBNBE5j9EwBCACbYHjxDrxFAY3n1x9KBFvjzkG1qFSTVBnH4vpD/5Na4sZq4uDDMUCjivrm
 MzbWYaivYj96BygdOiw7PWxYrhuW0b2WYOeGudZyApgFz42g458s78EciuhgfuWBlxr8dOEN
 /9ueVFHcvtZmDbHhMVPcQ0O7gwh0JmwkOsf7P7WAfYXsQlhO/EBRrNXR0Je+GEpYADhRktxX
 h1d3Iz+oKYuwHioLX8ovoAT4+peOuecWUSpUWebpDbTR5i7NRP3PIblB4KzWJa2kh/f3mx4v
 SRGnHn+BfX42xSe0X7Ktl4Xf+KNq9Wkcjk2CZP57hV2v4pO0ZUOXD7IhlZtnfNj67WjdABEB
 AAHNPU1hcmVrIE1hcmN6eWtvd3NraS1Hw7NyZWNraSA8bWFybWFyZWtAaW52aXNpYmxldGhp
 bmdzbGFiLmNvbT7CwHoEEwEIACQCGwMFCwkIBwMFFQoJCAsFFgIDAQACHgECF4AFAll+l7cC
 GQEACgkQ24/THMrX1yw6kAgAiKiUhzAPXZj5ndqiQDl8u8PUK34SupLzYNMJOCBw5Wh+CPHe
 XYlQUwfULWxmzjiWCzzWDx2X/ONsYdRGKDKMqG5srOSWe1IYXv00MEutGsK+m/hmC5mqi/97
 DVNZ1VtKj5WW79IsI0/7ueHsQYNNrXyOfZvKsRE8VIUJ0tNfLFDFlNpq9jONuF+GviMWxrA5
 FoVaGmjh63xC0fOQYqhP2v8dbYS4B6bO5NZKI2cTHb9Li2iY0e7wIoNgvqgtR3Iv2U2Ry0yL
 D3mNQhwyxcWChexlymjfqLEZwKqaIOo57HOpt7OA+bMg6MvkdUTjNWf2GE6fqCcALjcToJ3L
 NDc1KM7ATQROY/RMAQgAtRWgUZ5mOy+c/qzmiVnxqDkiOJjmnIh3Pn+OqCtjcrTyPI9eVc06
 uH30Jkco0soLiG/UgwVw4XwBlm95j9n6TSUms4mPBh1YiR1hBjsjYwn8zp/Ue9xWk1N6E14H
 aj55GxmS2H3YIlOXfQLr0X3RHsmKixTOKyisrYlJu71FmettDFV7CgMXy1Bc1LbAE08asvAS
 ShHFdRiRRtkuVHvY/Ebq9L54kOxtlI6ahrflMcT0YCMON5oe4GgQRh3p2uy+d/LS2bgRcQST
 IebErj8x0lM271f97GvxV/ypHo7XVIDI5FX1u31Agzx3HQr035GHt4HV4/GVCz+V4xt4BonB
 tQARAQABwsBfBBgBAgAJBQJOY/RMAhsMAAoJENuP0xzK19cs5MgH/jWLXil2Ud4TdtWnBxc+
 2/QZZk2JCssc1PgWNzvH5wH7U+8lGSlUK8ZMOqrrF8C5rX0+xEn7deSrsZChIOnUFo8rhCZK
 y/mBV+FhkMj24FZZ0n8w3eF4KF2t68Pt+AvMjxQHwxAMdf3QftgQhD0qYkt/28eedUQ+jwz6
 kipc4qUQmqTEViQRPa3WAnKgNDQUDUwNruzthfGvHUjllf7zbPI8gkbARM0KlTkLikc9u+Ni
 VMbJTiGPB7YHyw2MIPq1n+mhSPAyXE6CVBnYkonQ7P3SLZssxC3PIarV+DTU68umQB3pfrfF
 7hMcAY5csWrK9/x/Zz4RUfgN6Q3HLrSp9UQ=

--------------mSao4Len6MXjiPCP9pgZk61S
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

A very small correction to Marek's summary, only matters if you really
going to look at details:

Marek Marczykowski-G=C3=B3recki:
[...]
> 2. When toolstack issues "suspend" command (via xenstore
> control/shutdown), Linux uses "freeze" path, that doesn't put devices
> into low power state. Changing that to "suspend" path helps (the second=

> patch in [2]), and for our case seems to have no negative consequences.=


That's not quite true. See the hacky change to
xenbus_frontend_dev_resume in that patch. For a proper change this needs
to be clarified when which behavior is actually correct.

> But we do not use live migration nor save/restore - which is another us=
e
> of this feature, and we have not tested if this still works.
> [...]
> [1] https://github.com/QubesOS/qubes-issues/issues/6411#issuecomment-15=
38089344
> [2] https://github.com/QubesOS/qubes-linux-kernel/pull/910/files
> [3] https://github.com/QubesOS/qubes-vmm-xen-stubdom-linux/pull/63/file=
s

--------------mSao4Len6MXjiPCP9pgZk61S--

--------------yxpE2F20G0aRgWgcKvscgSK9
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3E8ezGzG3N1CTQ//kO9xfO/xly8FAmX1GX4ACgkQkO9xfO/x
ly//QBAArgXBZGCPwGN/mlzh7vyck9sUsxU3nhkNsl2GGR2Ymw4MTikfp4hcPT8R
iWtt5TlqaLJq9EFxCrjCWh2HqELSZy6weXl/VMdEeWqeOvYeVS3Wuv98LdwhzVCl
A3lOOGHhHwU9DBk2aXiRtmUrO+hErrtMXpaZpqc3d8X+3A+DEZkDJeGTTQ5vCACW
dIveuOn8zqt4t8Rkn+0QB+/eT5ORvXwxuhcVxTcn7TSdT8cRc/2lNXbg6yQhF59/
O7gTVGtLPcr9vdFC8R2e9S/cYOSUg/kw2w/PIipq9lEoSvgfo8u67O1xV+32mdCZ
OoWdelZyaRQsqpVXeINVC22wi0ANTUt4zee866LhX6voVhNInpb8LZOH5MPgOj7V
NStZ3VVzyhqwf8B7x1XSEQqq46jSOP52RlWdqrkWCvv4E7VRbwZzyEpCP+z6WNQf
kEKoa+pIs9ZCVVkfZSIUGCnM/peAjud5Jt+oTA+GHj8/vr530/1xxaCCxG0WhwKJ
EKZMxRotXu9gS0hOi+h7jxUR8Kaek6OFGW74W0xfw0JDlukKvCV6bVumPjXIuU3c
8Wrv4b20EwYEiZsdX83zf2zGezF/RMWbxMjLzi6Jl2pehDYur4o0cMiYbpqgGMJ+
1j8PMOEJDlO9yH168Wzu+lNP325r76bjkdz6GbEZ0NLHz4Hj3/s=
=NDi4
-----END PGP SIGNATURE-----

--------------yxpE2F20G0aRgWgcKvscgSK9--


From xen-devel-bounces@lists.xenproject.org Sat Mar 16 06:25:18 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 16 Mar 2024 06:25:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694149.1083069 (Exim 4.92)
	(envelope-from )
	id 1rlNTe-0005iD-2Q; Sat, 16 Mar 2024 06:25:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694149.1083069; Sat, 16 Mar 2024 06:25:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rlNTd-0005i6-VX; Sat, 16 Mar 2024 06:25:05 +0000
Received: by outflank-mailman (input) for mailman id 694149;
 Sat, 16 Mar 2024 06:25:04 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rlNTc-0005hw-GB; Sat, 16 Mar 2024 06:25:04 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rlNTc-0006Q8-5v; Sat, 16 Mar 2024 06:25:04 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rlNTb-0008Nr-Rz; Sat, 16 Mar 2024 06:25:03 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rlNTb-0000LY-RK; Sat, 16 Mar 2024 06:25:03 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=Th3QhKPCeZnN/51cUvBqY2+OaaCE88W2dy7xHYGCtMQ=; b=AMnI0yqxqMbHhh2KjGEMv5da5w
	PU31NPAzOZQ1QRAp5S81tDCjmC9hY6MseVjhXl+U1g0kcqr8npMvqkNzqjjRodJS6rL7EqzDx0asx
	ctdnHcNaRdinQB5gO0vE2nG9pw+xEMmxStqGlDcZ9AmCGYEC8stxyT0uFxeqTJVDyEB0=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-6.1 test] 185053: tolerable FAIL - PUSHED
X-Osstest-Failures:
    linux-6.1:test-armhf-armhf-xl-rtds:debian-install:fail:allowable
    linux-6.1:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    linux-6.1:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    linux-6.1:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
    linux-6.1:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking
    linux-6.1:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    linux-6.1:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    linux-6.1:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    linux-6.1:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    linux-6.1:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    linux-6.1:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    linux-6.1:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-6.1:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    linux-6.1:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    linux-6.1:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    linux-6.1:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    linux-6.1:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    linux-6.1:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-6.1:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    linux-6.1:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    linux-6.1:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    linux-6.1:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    linux-6.1:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    linux-6.1:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-6.1:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-6.1:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    linux-6.1:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    linux-6.1:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    linux-6.1:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    linux-6.1:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-6.1:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    linux-6.1:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
    linux-6.1:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    linux-6.1:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-6.1:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    linux-6.1:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking
    linux-6.1:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-6.1:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-6.1:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    linux-6.1:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    linux-6.1:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    linux-6.1:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-6.1:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking
    linux-6.1:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
    linux-6.1:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    linux=d7543167affd372819a94879b8b1e8b9b12547d9
X-Osstest-Versions-That:
    linux=61adba85cc40287232a539e607164f273260e0fe
From: osstest service owner 
Date: Sat, 16 Mar 2024 06:25:03 +0000

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds     12 debian-install           fail REGR. vs. 184922

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt     16 saverestore-support-check    fail  like 184922
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop            fail like 184922
 test-armhf-armhf-libvirt-raw 15 saverestore-support-check    fail  like 184922
 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check   fail like 184922
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop            fail like 184922
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop            fail like 184922
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop            fail like 184922
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184922
 test-armhf-armhf-xl-multivcpu 15 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-check    fail  never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     15 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass
 test-arm64-arm64-xl          15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     15 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-qcow2 14 migrate-support-check        fail never pass
 test-amd64-amd64-libvirt-raw 14 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-raw 14 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-raw 15 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-vhd      14 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-vhd      15 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-raw 14 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-qcow2 14 migrate-support-check        fail never pass
 test-armhf-armhf-xl-vhd      14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      15 saverestore-support-check    fail   never pass

version targeted for testing:
 linux                d7543167affd372819a94879b8b1e8b9b12547d9
baseline version:
 linux                61adba85cc40287232a539e607164f273260e0fe

Last test of basis   184922  2024-03-06 15:13:36 Z    9 days
Testing same since   185053  2024-03-15 19:18:14 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Alex Deucher 
  Andrew Morton 
  Chandan Kumar Rout  (A Contingent Worker at Intel)
  Christian Borntraeger 
  Dave Hansen 
  David S. Miller 
  Dylan Hatch 
  Edward Adam Davis 
  Eric Dumazet 
  Fangzhi Zuo 
  Florian Fainelli 
  Florian Kauer 
  Florian Westphal 
  Friedrich Vock 
  Gao Xiang 
  Greg Kroah-Hartman 
  Hamza Mahfooz 
  Horatiu Vultur 
  Hui Zhou 
  Ilya Dryomov 
  Jacob Keller 
  Jakub Kicinski 
  Jan Kara 
  Janosch Frank 
  Jason Xing 
  Johan Hovold 
  Josh Poimboeuf 
  kernelci.org bot 
  Lena Wang 
  Linux Kernel Functional Testing 
  Louis Peens 
  Ma Hanghong 
  Maciej Fijalkowski 
  Magnus Karlsson 
  Mark Broadworth 
  Mark Brown 
  Martin KaFai Lau 
  Mathias Nyman 
  Matthieu Baerts (NGI0) 
  Michal Pecio 
  Michał Pecio 
  Muhammad Usama Anjum 
  Naama Meir 
  Nico Boehr 
  Nico Pache 
  Oleg Nesterov 
  Oleksij Rempel 
  Pablo Neira Ayuso 
  Paolo Abeni 
  Pavel Machek (CIP) 
  Pawan Gupta 
  Rafal Romanowski 
  Rand Deeb 
  Rodrigo Siqueira 
  Sasha Levin 
  Simon Horman 
  Srinivasan Shanmugam 
  Steven Rostedt (Google) 
  Tobias Jakobi (Compleo) 
  Toke Høiland-Jørgensen 
  Tony Nguyen 
  Wentao Jia 
  Xiubo Li 

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-freebsd11-amd64                             pass    
 test-amd64-amd64-freebsd12-amd64                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-libvirt-qcow2                               pass    
 test-armhf-armhf-libvirt-qcow2                               pass    
 test-amd64-amd64-libvirt-raw                                 pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     fail    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-amd64-xl-vhd                                      pass    
 test-arm64-arm64-xl-vhd                                      pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

Explanation of these 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 :

hint: The 'hooks/update' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
hint: The 'hooks/post-receive' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
hint: The 'hooks/post-update' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
To xenbits.xen.org:/home/xen/git/linux-pvops.git
   61adba85cc40..d7543167affd  d7543167affd372819a94879b8b1e8b9b12547d9 -> tested/linux-6.1


From xen-devel-bounces@lists.xenproject.org Sat Mar 16 06:39:05 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 16 Mar 2024 06:39:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694155.1083079 (Exim 4.92)
	(envelope-from )
	id 1rlNh6-0007f6-D8; Sat, 16 Mar 2024 06:39:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694155.1083079; Sat, 16 Mar 2024 06:39:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rlNh6-0007ez-9S; Sat, 16 Mar 2024 06:39:00 +0000
Received: by outflank-mailman (input) for mailman id 694155;
 Sat, 16 Mar 2024 06:38:59 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rlNh5-0007et-1F
 for xen-devel@lists.xenproject.org; Sat, 16 Mar 2024 06:38:59 +0000
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com
 [2a00:1450:4864:20::633])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id dd9e848d-e35f-11ee-afdd-a90da7624cb6;
 Sat, 16 Mar 2024 07:38:57 +0100 (CET)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-a28a6cef709so392098866b.1
 for ; Fri, 15 Mar 2024 23:38:57 -0700 (PDT)
Received: from ?IPV6:2003:e5:873a:400:704b:6dbb:e7c0:786e?
 (p200300e5873a0400704b6dbbe7c0786e.dip0.t-ipconnect.de.
 [2003:e5:873a:400:704b:6dbb:e7c0:786e])
 by smtp.gmail.com with ESMTPSA id
 dl19-20020a170907945300b00a44b90abb1dsm2388520ejc.110.2024.03.15.23.38.56
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 15 Mar 2024 23:38:56 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: dd9e848d-e35f-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710571137; x=1711175937; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:references:cc:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=dibU6A4pQqcGS1XBDohuVXartAdYLZDKoYkxrmE8mQI=;
        b=QlVFIVMlwV1+6wvvgqRWiyLyGioqVxrwC0B9Tlngc+iaiopp+87RbluHHQ2pHAuvdw
         0YNAw1iwb2pKB1LIGJKiCI7rFE+bqWdYDmIj7SYYJp4k7KmFQkHCvg+J1cQ9eEDskfVk
         qxrKZGzBhC9gQo/STY+g9TtpAtrB21WLHCNb2E2uET/J7JjpdeY64mZ14VPzrhfhUTgV
         MbfNDJz6k7O0HmUhSOOJWjae2FSMGzBJ9BZxkd71idtxegKxEUuBtppmX28yutPqQUcW
         4k8915yU3eeSvJQDyQF+CkeQaBLAJHXERnvYArRD5ldTEfXBZjTf7CnPzo5kCOKIc37z
         Ay6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710571137; x=1711175937;
        h=content-transfer-encoding:in-reply-to:from:references:cc:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=dibU6A4pQqcGS1XBDohuVXartAdYLZDKoYkxrmE8mQI=;
        b=TxQBh0WdjrshEe2IE47X48euPbu29oQZLwum+Vu0b+Bq/6o0PMu0ADNScQpp2ocG7G
         S3eb55sZAiJh8FHtp0FSlM5lSvJB7tRuQxV12B0Bk+yUjwo8YfX6C4dKRUHvh/EAfoYH
         07nFkAHYcC3pY/djTw2Qa3a259SoNa96ZBVq71cUXxfsp4L6GB1N0Q+bjj3ENlIxK7a0
         JsXWCi0qj0chun1xmNGjcWQjzFYf9SjZzv04or9OnawOrXmiqeAa3H8aEwdcsC1ikE2s
         hobe6uI/jNwH+dCbYX7oQ8r6cyZxSfYFNGeb25Xh20fK3NneEJ+63bPiN0TjbGreLWIU
         Nhyw==
X-Forwarded-Encrypted: i=1; AJvYcCUwdrUAVu3riIvpJq0mN4PhdbFa7s59c8b0UmXYtxpNh9PK6dj1yEhzuvEiP2jzc5jEQxLM3nEftR6K4Z5HhzblaMQ4vYob4W/HOxotRBc=
X-Gm-Message-State: AOJu0Yw4BbHjf4+O7wmvwruasWjFXPXnZ8eCAug7qIZ7tECNWI1+RgD4
	icSvCDq4ecqiU5oKFkYCs99vRDQYzOmbd/0AEdHy3kP2jh1OkSVLxS2P/jLRvIs=
X-Google-Smtp-Source: AGHT+IGiwv3UFvsYek5BnhkOJtbU7oB70fzMMpUd6kK0qN+U5vhqbtNhtI6UyLcDMtLfMCYPz8DJTA==
X-Received: by 2002:a17:907:7a93:b0:a46:74fe:904f with SMTP id mm19-20020a1709077a9300b00a4674fe904fmr4362642ejc.26.1710571136966;
        Fri, 15 Mar 2024 23:38:56 -0700 (PDT)
Message-ID: <77b77bf7-f7ae-4f74-976a-9a591be1997f@suse.com>
Date: Sat, 16 Mar 2024 07:38:55 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: IMPORTANT - : Need help on USB port virtualization with Xen
 hypervisor
Content-Language: en-US
To: Stefano Stabellini ,
 LARRIEU Dominique 
Cc: Julien Grall ,
 GOURLOT Francois ,
 GRUO Nicolas ,
 Cc , Kelly Choi ,
 Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Andrew Cooper ,
 George Dunlap ,
 WILLEMS Louis , vikram.garhwal@amd.com,
 Edgar.Iglesias@amd.com
References: 
 
 
 <427d2ecb865648b7a459c592c208c0be@thalesgroup.com>
 <673b2bc630d748e8af0a15d4b553906e@thalesgroup.com>
 <3ee3659afff645cabed86bcc22c44686@thalesgroup.com>
 <4778822e-582f-4e0d-9933-86d8d49ea3a5@xen.org>
 <8f2a2bbaf29e41709eeab695efe48f17@thalesgroup.com>
 
 <2e53bd839f904d8a97ee5645ee9e9361@thalesgroup.com>
 
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 16.03.24 00:32, Stefano Stabellini wrote:
> Hi Dominique,
> 
> You posted this configuration:
> 
> device_model_args = [ "
>                        "-device","nec-usb-xhci,id=xhci",
>                        "-device","usb-host,bus=xhci.0,hostbus=1,hostport=13",
>                        "-device","usb-host,bus=xhci.0,hostbus=1,hostport=10",
>                        "-device","usb-host,bus=xhci.0,hostbus=1,hostport=2",
>                        "-device","usb-host,bus=xhci.0,hostbus=2,hostport=2",
>                        "-device","usb-host,bus=xhci.0,hostbus=2,hostport=1",
>                        "-device","usb-host,bus=xhci.0,hostbus=1,hostport=1"]
> 
> It looks like you are using QEMU-based USB passthrough. Basically QEMU
> (independently from Xen) is accessing the USB device in Dom0 and
> exposing a corresponding device to the guest. I am not sure if there is
> anything that can be done in QEMU to support USB 3.0 with high speed,
> people in CC might know.
> 
> There two other alternatives to this approach. You can use PV USB
> Passthrough instead. Juergen (CCed) is the original author. I am not
> sure if that supports USB 3.0 either.

PV USB doesn't support USB 3.0.

Instead of using device_model_args= in the guest configuration I'd rather
use the usbctrl= and usbdev= items (see the related xl.cfg(5) man page).
I'm not sure this will really make a performance difference, though.


Juergen



From xen-devel-bounces@lists.xenproject.org Sat Mar 16 11:32:22 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 16 Mar 2024 11:32:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694189.1083088 (Exim 4.92)
	(envelope-from )
	id 1rlSGg-0001jB-L9; Sat, 16 Mar 2024 11:32:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694189.1083088; Sat, 16 Mar 2024 11:32:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rlSGg-0001j4-IK; Sat, 16 Mar 2024 11:32:02 +0000
Received: by outflank-mailman (input) for mailman id 694189;
 Sat, 16 Mar 2024 11:32:01 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rlSGf-0001iu-7I; Sat, 16 Mar 2024 11:32:01 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rlSGf-0003x0-0S; Sat, 16 Mar 2024 11:32:01 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rlSGe-0001cu-A6; Sat, 16 Mar 2024 11:32:00 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rlSGe-0004g5-9c; Sat, 16 Mar 2024 11:32:00 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=lIAcP8uMYlOrh8Ti/ay7Jjngbhr+tAo0XLaGIyHO2vY=; b=xDwH/lLUZid+tvY88yYbjKaVof
	wTtnGONHMKp1DFcjq9EjOKFoqrykgfFGpqlNrbIIYB8OIow7Z/2B1X4EaQWdWUMCuEt8A5W6lc8Gu
	0bJo1OPnhtbRZxBDhWvuCcB85NZVdlmmNL1jPx2QmvYOOBA6zxfYaDixCeCDtpxEKHN0=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-5.4 test] 185054: regressions - trouble: broken/fail/pass
X-Osstest-Failures:
    linux-5.4:test-armhf-armhf-xl-arndale::broken:regression
    linux-5.4:test-armhf-armhf-xl-arndale:host-install(5):broken:regression
    linux-5.4:test-armhf-armhf-xl-multivcpu:guest-start/debian.repeat:fail:regression
    linux-5.4:test-armhf-armhf-xl-credit2:guest-start/debian.repeat:fail:regression
    linux-5.4:test-armhf-armhf-xl-credit1:guest-start/debian.repeat:fail:regression
    linux-5.4:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    linux-5.4:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
    linux-5.4:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-arm64-arm64-libvirt-raw:guest-start.2:fail:nonblocking
    linux-5.4:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking
    linux-5.4:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    linux-5.4:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    linux-5.4:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    linux-5.4:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-5.4:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-5.4:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
    linux-5.4:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
    linux-5.4:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    linux-5.4:test-amd64-i386-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-5.4:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking
X-Osstest-Versions-This:
    linux=84075826304f1a297838de6bcfd9bd84f566026e
X-Osstest-Versions-That:
    linux=3fec063b052e395f4920fbc59a8d0bb3c9666d76
From: osstest service owner 
Date: Sat, 16 Mar 2024 11:32:00 +0000

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-arndale                      broken
 test-armhf-armhf-xl-arndale   5 host-install(5)        broken REGR. vs. 184921
 test-armhf-armhf-xl-multivcpu 18 guest-start/debian.repeat fail REGR. vs. 184921
 test-armhf-armhf-xl-credit2 18 guest-start/debian.repeat fail REGR. vs. 184921
 test-armhf-armhf-xl-credit1 18 guest-start/debian.repeat fail REGR. vs. 184921

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt     16 saverestore-support-check    fail  like 184921
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop            fail like 184921
 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop             fail like 184921
 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop             fail like 184921
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop            fail like 184921
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop            fail like 184921
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop            fail like 184921
 test-armhf-armhf-libvirt-raw 15 saverestore-support-check    fail  like 184921
 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop             fail like 184921
 test-arm64-arm64-libvirt-raw 18 guest-start.2                fail  like 184921
 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check   fail like 184921
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop             fail like 184921
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184921
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass
 test-amd64-amd64-libvirt     15 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  15 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-amd64-i386-xl-pvshim    14 guest-start                  fail   never pass
 test-amd64-i386-libvirt      15 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass
 test-amd64-i386-libvirt-raw  14 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 15 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit2  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  16 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt     15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     16 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-raw 14 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-raw 15 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-vhd      14 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-vhd      15 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-raw 14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      15 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-qcow2 14 migrate-support-check        fail never pass

version targeted for testing:
 linux                84075826304f1a297838de6bcfd9bd84f566026e
baseline version:
 linux                3fec063b052e395f4920fbc59a8d0bb3c9666d76

Last test of basis   184921  2024-03-06 14:47:02 Z    9 days
Testing same since   185054  2024-03-15 19:18:15 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Morton 
  Andy Shevchenko 
  Andy Shevchenko 
  Ansuel Smith 
  Arnd Bergmann 
  Bjorn Andersson 
  Bjorn Andersson 
  Chandan Kumar Rout  (A Contingent Worker at Intel)
  Cosmin Tanislav 
  David S. Miller 
  Dexuan Cui 
  Dmitry Torokhov 
  Dylan Hatch 
  Edward Adam Davis 
  Eric Dumazet 
  Florian Fainelli 
  Florian Westphal 
  Greg Kroah-Hartman 
  Haiyang Zhang 
  Harshit Mogalapalli 
  Hugo Villeneuve 
  Jakub Kicinski 
  Jan Kundrát 
  Jason Xing 
  Johan Hovold 
  Johannes Berg 
  John Efstathiades 
  Juhee Kang 
  Lena Wang 
  Lina Iyer 
  Linux Kernel Functional Testing 
  Maciej Fijalkowski 
  Magnus Karlsson 
  Marek Vasut 
  Mark Brown 
  Nico Pache 
  Oleg Nesterov 
  Oleksij Rempel 
  Pablo Neira Ayuso 
  Paolo Abeni 
  Rand Deeb 
  Richard Weinberger 
  Sasha Levin 
  Shachar Raindel 
  Shradha Gupta 
  Stephen Hemminger 
  Tony Nguyen 
  Werner Sembach 

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  broken  
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-i386-examine-bios                                 pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  fail    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  fail    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-armhf-armhf-libvirt-qcow2                               pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-arm64-arm64-libvirt-raw                                 fail    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-libvirt-raw                                  pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-i386-examine-uefi                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-arm64-arm64-xl-vhd                                      pass    
 test-armhf-armhf-xl-vhd                                      pass    
 test-amd64-i386-xl-vhd                                       pass    


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

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

Explanation of these 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

broken-job test-armhf-armhf-xl-arndale broken
broken-step test-armhf-armhf-xl-arndale host-install(5)

Not pushing.

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


From xen-devel-bounces@lists.xenproject.org Sat Mar 16 14:38:03 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 16 Mar 2024 14:38:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694210.1083098 (Exim 4.92)
	(envelope-from )
	id 1rlVAT-0006Gl-Ig; Sat, 16 Mar 2024 14:37:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694210.1083098; Sat, 16 Mar 2024 14:37:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rlVAT-0006Ge-G3; Sat, 16 Mar 2024 14:37:49 +0000
Received: by outflank-mailman (input) for mailman id 694210;
 Sat, 16 Mar 2024 14:37:47 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rlVAR-0006G8-Pb; Sat, 16 Mar 2024 14:37:47 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rlVAR-00078f-KY; Sat, 16 Mar 2024 14:37:47 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rlVAR-0001jp-6K; Sat, 16 Mar 2024 14:37:47 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rlVAR-00020V-5t; Sat, 16 Mar 2024 14:37:47 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=Ea5T4SIfDQR0hRbpABZuU+5RyclAC7wqE83fjg1bim0=; b=4tR6eSaptLxHlkcOJGOFNhGXOh
	2vRbeTI3XZ6JAXdcGNSOYmp3n+7uZn66zBhiXSCBjXr49TpjfqsWiEHB0hCW1E29QO4bCrunB6MdS
	WQkoCoisqYpt2s7hXM06qTWUF0Xy6xN96GI/4cp4gt+V8ufkakSVFmlsbhMZTeAdw3Dc=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 185056: tolerable FAIL - PUSHED
X-Osstest-Failures:
    linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    linux=c442a42363b2ce5c3eb2b0ff1e052ee956f0a29f
X-Osstest-Versions-That:
    linux=e5eb28f6d1afebed4bb7d740a797d0390bd3a357
From: osstest service owner 
Date: Sat, 16 Mar 2024 14:37:47 +0000

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

Failures :-/ but no regressions.

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

version targeted for testing:
 linux                c442a42363b2ce5c3eb2b0ff1e052ee956f0a29f
baseline version:
 linux                e5eb28f6d1afebed4bb7d740a797d0390bd3a357

Last test of basis   185046  2024-03-15 08:44:39 Z    1 days
Testing same since   185056  2024-03-15 20:10:48 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  "Matthew Wilcox (Oracle)" 
  Alessio Balsini 
  Alexander Mikhalitsyn 
  Amir Goldstein 
  Arnd Bergmann 
  Baokun Li 
  Bernd Schubert 
  Brian Foster 
  Calvin Owens 
  Cheng Nie 
  Chengming Zhou 
  Colin Ian King 
  Daniel Hill 
  Darrick J. Wong 
  Eric Van Hensbergen 
  Erick Archer 
  Guenter Roeck 
  Guoyu Ou 
  Hongbo Li 
  Jan Kara 
  Jiachen Zhang 
  Jingbo Xu 
  Kemeng Shi 
  Kent Overstreet 
  Lei Huang 
  Li RongQing 
  Li Zetao 
  Linus Torvalds 
  Matthew Wilcox (Oracle) 
  Maximilian Heyne 
  Miklos Szeredi 
  Randy Dunlap  # build-tested
  Srivathsa Dara 
  Stefan Hajnoczi 
  Theodore Ts'o 
  Thomas Bertschinger 
  Vlastimil Babka 
  Wenchao Hao 
  yangerkun 
  Ye Bin 
  Zhang Yi 
  Zhao Chen 
  Zhou Jifeng 

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-freebsd11-amd64                             pass    
 test-amd64-amd64-freebsd12-amd64                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-libvirt-qcow2                               pass    
 test-armhf-armhf-libvirt-qcow2                               pass    
 test-amd64-amd64-libvirt-raw                                 pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-amd64-xl-vhd                                      pass    
 test-arm64-arm64-xl-vhd                                      pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

Explanation of these 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 :

hint: The 'hooks/update' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
hint: The 'hooks/post-receive' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
hint: The 'hooks/post-update' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
To xenbits.xen.org:/home/xen/git/linux-pvops.git
   e5eb28f6d1af..c442a42363b2  c442a42363b2ce5c3eb2b0ff1e052ee956f0a29f -> tested/linux-linus


From xen-devel-bounces@lists.xenproject.org Sat Mar 16 21:04:08 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 16 Mar 2024 21:04:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694270.1083124 (Exim 4.92)
	(envelope-from )
	id 1rlbC5-0003Yq-Es; Sat, 16 Mar 2024 21:03:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694270.1083124; Sat, 16 Mar 2024 21:03:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rlbC5-0003Yj-CP; Sat, 16 Mar 2024 21:03:53 +0000
Received: by outflank-mailman (input) for mailman id 694270;
 Sat, 16 Mar 2024 21:03:51 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rlbC3-0003YG-TF; Sat, 16 Mar 2024 21:03:51 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rlbC3-0005qC-D8; Sat, 16 Mar 2024 21:03:51 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rlbC2-0008UH-UM; Sat, 16 Mar 2024 21:03:51 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rlbC2-0001wA-Tj; Sat, 16 Mar 2024 21:03:50 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=v2lw1LTbvNreDdjnNz+dSa2L/pKYezXleAIMnKba32s=; b=HfL7wVO6p5w41FjTi1+lWYnG+n
	2xjVA42OtylHqK5DNR9gBZbP+VyV7D68E8JZe21oNyWS4eZFimAZj/8vbXTeaj0JJ7FyaAD4X8lcr
	Vjq0L7myH2QLLpRc/mut9q/CQdzwRc9MoSjJ7Bd9EQsvyb5j8wsibKX3IIyaLH8sxUI0=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 185057: tolerable FAIL
X-Osstest-Failures:
    xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
    xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-i386-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
X-Osstest-Versions-This:
    xen=d638e304f13a5ef7d125de5ace5f7828a7b25bac
X-Osstest-Versions-That:
    xen=d638e304f13a5ef7d125de5ace5f7828a7b25bac
From: osstest service owner 
Date: Sat, 16 Mar 2024 21:03:50 +0000

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen                  d638e304f13a5ef7d125de5ace5f7828a7b25bac
baseline version:
 xen                  d638e304f13a5ef7d125de5ace5f7828a7b25bac

Last test of basis   185057  2024-03-16 01:55:57 Z    0 days
Testing same since                          (not found)         0 attempts

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-i386-examine-bios                                 pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-armhf-armhf-libvirt-qcow2                               pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-libvirt-raw                                  pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-i386-examine-uefi                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-arm64-arm64-xl-vhd                                      pass    
 test-armhf-armhf-xl-vhd                                      pass    
 test-amd64-i386-xl-vhd                                       pass    


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

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

Explanation of these 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


Published tested tree is already up to date.



From xen-devel-bounces@lists.xenproject.org Sun Mar 17 01:00:21 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 17 Mar 2024 01:00:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694282.1083135 (Exim 4.92)
	(envelope-from )
	id 1rlesd-00083k-Q9; Sun, 17 Mar 2024 01:00:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694282.1083135; Sun, 17 Mar 2024 01:00:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rlesd-00082i-Mw; Sun, 17 Mar 2024 01:00:03 +0000
Received: by outflank-mailman (input) for mailman id 694282;
 Sun, 17 Mar 2024 01:00:01 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rlesb-0007Bl-HF; Sun, 17 Mar 2024 01:00:01 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rlesb-0002LO-89; Sun, 17 Mar 2024 01:00:01 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rlesa-0005Xz-Pm; Sun, 17 Mar 2024 01:00:00 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rlesa-0005lh-Oy; Sun, 17 Mar 2024 01:00:00 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=h2s2mC4Cz8Ub8A2cxR7OPcD/J7Jo/yZwZ+jPo/kfgVg=; b=TbYB/q6b8XDerf/MypFzrC/Wbo
	OO34Ke16pMBhYTAaoSZqHI05PbbbJ+MWCid2xJjT3KO7U4XiUN7XBs4abY0TFRiy0DW+WPirY1Rxl
	j/ePqe4sZC9dDXxZLqFjx0KIsxgcpBHl/V5d4yGzP5WIdSn0IlGyXDqtrFaUN1eLrNxI=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-5.4 test] 185058: regressions - FAIL
X-Osstest-Failures:
    linux-5.4:test-armhf-armhf-xl-arndale::broken:regression
    linux-5.4:test-armhf-armhf-xl-credit1:guest-start/debian.repeat:fail:regression
    linux-5.4:test-armhf-armhf-xl-credit2:guest-start/debian.repeat:fail:regression
    linux-5.4:test-armhf-armhf-xl-arndale:host-install(5):broken:heisenbug
    linux-5.4:test-armhf-armhf-xl-multivcpu:guest-start/debian.repeat:fail:heisenbug
    linux-5.4:test-armhf-armhf-xl-credit2:guest-start:fail:heisenbug
    linux-5.4:test-amd64-i386-xl-qemut-debianhvm-i386-xsm:debian-hvm-install:fail:heisenbug
    linux-5.4:test-armhf-armhf-libvirt-qcow2:guest-start/debian.repeat:fail:heisenbug
    linux-5.4:test-arm64-arm64-libvirt-raw:guest-start.2:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    linux-5.4:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
    linux-5.4:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking
    linux-5.4:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    linux-5.4:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    linux-5.4:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-5.4:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    linux-5.4:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-5.4:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
    linux-5.4:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
    linux-5.4:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-5.4:test-amd64-i386-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    linux-5.4:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking
X-Osstest-Versions-This:
    linux=84075826304f1a297838de6bcfd9bd84f566026e
X-Osstest-Versions-That:
    linux=3fec063b052e395f4920fbc59a8d0bb3c9666d76
From: osstest service owner 
Date: Sun, 17 Mar 2024 01:00:00 +0000

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-arndale                      broken  in 185054
 test-armhf-armhf-xl-credit1 18 guest-start/debian.repeat fail REGR. vs. 184921
 test-armhf-armhf-xl-credit2 18 guest-start/debian.repeat fail in 185054 REGR. vs. 184921

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-arndale  5 host-install(5) broken in 185054 pass in 185058
 test-armhf-armhf-xl-multivcpu 18 guest-start/debian.repeat fail in 185054 pass in 185058
 test-armhf-armhf-xl-credit2  14 guest-start                fail pass in 185054
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail pass in 185054
 test-armhf-armhf-libvirt-qcow2 17 guest-start/debian.repeat fail pass in 185054

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-raw 18 guest-start.2       fail in 185054 like 184921
 test-armhf-armhf-xl-credit2 15 migrate-support-check fail in 185054 never pass
 test-armhf-armhf-xl-credit2 16 saverestore-support-check fail in 185054 never pass
 test-armhf-armhf-libvirt     16 saverestore-support-check    fail  like 184921
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop            fail like 184921
 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop             fail like 184921
 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop             fail like 184921
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop            fail like 184921
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop            fail like 184921
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop            fail like 184921
 test-armhf-armhf-libvirt-raw 15 saverestore-support-check    fail  like 184921
 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop             fail like 184921
 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check   fail like 184921
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop             fail like 184921
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184921
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass
 test-amd64-i386-libvirt-xsm  15 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     15 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-amd64-i386-xl-pvshim    14 guest-start                  fail   never pass
 test-amd64-i386-libvirt      15 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass
 test-arm64-arm64-xl-thunderx 15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 15 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit1  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  16 saverestore-support-check    fail   never pass
 test-amd64-i386-libvirt-raw  14 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt     15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     16 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-raw 14 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-raw 15 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-vhd      14 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-vhd      15 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-raw 14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      15 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-qcow2 14 migrate-support-check        fail never pass

version targeted for testing:
 linux                84075826304f1a297838de6bcfd9bd84f566026e
baseline version:
 linux                3fec063b052e395f4920fbc59a8d0bb3c9666d76

Last test of basis   184921  2024-03-06 14:47:02 Z   10 days
Testing same since   185054  2024-03-15 19:18:15 Z    1 days    2 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Morton 
  Andy Shevchenko 
  Andy Shevchenko 
  Ansuel Smith 
  Arnd Bergmann 
  Bjorn Andersson 
  Bjorn Andersson 
  Chandan Kumar Rout  (A Contingent Worker at Intel)
  Cosmin Tanislav 
  David S. Miller 
  Dexuan Cui 
  Dmitry Torokhov 
  Dylan Hatch 
  Edward Adam Davis 
  Eric Dumazet 
  Florian Fainelli 
  Florian Westphal 
  Greg Kroah-Hartman 
  Haiyang Zhang 
  Harshit Mogalapalli 
  Hugo Villeneuve 
  Jakub Kicinski 
  Jan Kundrát 
  Jason Xing 
  Johan Hovold 
  Johannes Berg 
  John Efstathiades 
  Juhee Kang 
  Lena Wang 
  Lina Iyer 
  Linux Kernel Functional Testing 
  Maciej Fijalkowski 
  Magnus Karlsson 
  Marek Vasut 
  Mark Brown 
  Nico Pache 
  Oleg Nesterov 
  Oleksij Rempel 
  Pablo Neira Ayuso 
  Paolo Abeni 
  Rand Deeb 
  Richard Weinberger 
  Sasha Levin 
  Shachar Raindel 
  Shradha Gupta 
  Stephen Hemminger 
  Tony Nguyen 
  Werner Sembach 

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  fail    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-i386-examine-bios                                 pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  fail    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  fail    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-armhf-armhf-libvirt-qcow2                               fail    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-libvirt-raw                                  pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-i386-examine-uefi                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-arm64-arm64-xl-vhd                                      pass    
 test-armhf-armhf-xl-vhd                                      pass    
 test-amd64-i386-xl-vhd                                       pass    


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

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

Explanation of these 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

broken-job test-armhf-armhf-xl-arndale broken

Not pushing.

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


From xen-devel-bounces@lists.xenproject.org Sun Mar 17 04:53:28 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 17 Mar 2024 04:53:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694296.1083144 (Exim 4.92)
	(envelope-from )
	id 1rliWJ-0000O9-1k; Sun, 17 Mar 2024 04:53:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694296.1083144; Sun, 17 Mar 2024 04:53:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rliWI-0000O2-VP; Sun, 17 Mar 2024 04:53:14 +0000
Received: by outflank-mailman (input) for mailman id 694296;
 Sun, 17 Mar 2024 04:53:14 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rliWI-0000Ns-0O; Sun, 17 Mar 2024 04:53:14 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rliWH-0005MH-Ma; Sun, 17 Mar 2024 04:53:13 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rliWH-0000Fh-3w; Sun, 17 Mar 2024 04:53:13 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rliWG-0007dg-WE; Sun, 17 Mar 2024 04:53:13 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=k+zNM5WdQvpcZF7oq6eaH7wAZYSZoqPWGPoNP7Re3DY=; b=tOjzyjPoaOQcDSyN19Fuygc0F+
	VMhYHimt0jUDdLwFq1tse+MEhml9jWoQGKO8sRSgeX8G+YczbwzkXyjmzp2yZUrBf7gAmUwzbYrwu
	LVYWFteRquPB9NGZGFyAwkqoHeExXXQ6sWK7e48jvSFV9dCqGJbmlJf319NSZ8ty2DoI=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 185059: tolerable FAIL - PUSHED
X-Osstest-Failures:
    linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    linux=66a27abac311a30edbbb65fe8c41ff1b13876faa
X-Osstest-Versions-That:
    linux=c442a42363b2ce5c3eb2b0ff1e052ee956f0a29f
From: osstest service owner 
Date: Sun, 17 Mar 2024 04:53:13 +0000

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

Failures :-/ but no regressions.

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

version targeted for testing:
 linux                66a27abac311a30edbbb65fe8c41ff1b13876faa
baseline version:
 linux                c442a42363b2ce5c3eb2b0ff1e052ee956f0a29f

Last test of basis   185056  2024-03-15 20:10:48 Z    1 days
Testing same since   185059  2024-03-16 14:43:18 Z    0 days    1 attempts

------------------------------------------------------------
322 people touched revisions under test,
not listing them all

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-freebsd11-amd64                             pass    
 test-amd64-amd64-freebsd12-amd64                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-libvirt-qcow2                               pass    
 test-armhf-armhf-libvirt-qcow2                               pass    
 test-amd64-amd64-libvirt-raw                                 pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-amd64-xl-vhd                                      pass    
 test-arm64-arm64-xl-vhd                                      pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

Explanation of these 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 :

hint: The 'hooks/update' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
hint: The 'hooks/post-receive' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
hint: The 'hooks/post-update' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
To xenbits.xen.org:/home/xen/git/linux-pvops.git
   c442a42363b2..66a27abac311  66a27abac311a30edbbb65fe8c41ff1b13876faa -> tested/linux-linus


From xen-devel-bounces@lists.xenproject.org Sun Mar 17 11:38:47 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 17 Mar 2024 11:38:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694322.1083155 (Exim 4.92)
	(envelope-from )
	id 1rloqP-0006Yq-Kd; Sun, 17 Mar 2024 11:38:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694322.1083155; Sun, 17 Mar 2024 11:38:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rloqP-0006Yg-Ev; Sun, 17 Mar 2024 11:38:25 +0000
Received: by outflank-mailman (input) for mailman id 694322;
 Sun, 17 Mar 2024 11:38:24 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rloqO-0006YW-Ss; Sun, 17 Mar 2024 11:38:24 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rloqO-0005RK-GW; Sun, 17 Mar 2024 11:38:24 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rloqO-0006iG-7I; Sun, 17 Mar 2024 11:38:24 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rloqO-0003kn-6U; Sun, 17 Mar 2024 11:38:24 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=VhbR4hKniM5CzoDKFMat4JcmG5DT1Vv9BJgdJrjB+P4=; b=DRZx5VnFHkjNSY93pnI3nWj9wg
	skzIgInTDmHfhYOWiskH0Qgz0ySyEvFs9CrM6nVflknBi2kjY3kQrNdvIHhk0FtrUoo6NA6PR+rKG
	5CRCZpyCso5bfTebAVM99HtDzwVcv4yGDSWWo06pAc5HsE45W6g60mRlDszdgIV7Dads=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-5.4 test] 185060: regressions - FAIL
X-Osstest-Failures:
    linux-5.4:test-armhf-armhf-xl-credit2:guest-start/debian.repeat:fail:regression
    linux-5.4:test-armhf-armhf-xl-credit1:guest-start/debian.repeat:fail:regression
    linux-5.4:test-armhf-armhf-xl-credit2:guest-start:fail:heisenbug
    linux-5.4:test-amd64-i386-xl-qemut-debianhvm-i386-xsm:debian-hvm-install:fail:heisenbug
    linux-5.4:test-armhf-armhf-libvirt-qcow2:guest-start/debian.repeat:fail:heisenbug
    linux-5.4:test-armhf-armhf-xl-multivcpu:guest-start/debian.repeat:fail:heisenbug
    linux-5.4:test-armhf-armhf-xl-arndale:guest-start/debian.repeat:fail:heisenbug
    linux-5.4:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    linux-5.4:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking
    linux-5.4:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
    linux-5.4:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking
    linux-5.4:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    linux-5.4:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    linux-5.4:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-5.4:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-5.4:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    linux-5.4:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
    linux-5.4:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
    linux-5.4:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    linux-5.4:test-amd64-i386-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-5.4:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking
X-Osstest-Versions-This:
    linux=84075826304f1a297838de6bcfd9bd84f566026e
X-Osstest-Versions-That:
    linux=3fec063b052e395f4920fbc59a8d0bb3c9666d76
From: osstest service owner 
Date: Sun, 17 Mar 2024 11:38:24 +0000

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-credit2 18 guest-start/debian.repeat fail REGR. vs. 184921
 test-armhf-armhf-xl-credit1 18 guest-start/debian.repeat fail REGR. vs. 184921

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-credit2  14 guest-start      fail in 185058 pass in 185060
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail in 185058 pass in 185060
 test-armhf-armhf-libvirt-qcow2 17 guest-start/debian.repeat fail in 185058 pass in 185060
 test-armhf-armhf-xl-multivcpu 18 guest-start/debian.repeat fail pass in 185058
 test-armhf-armhf-xl-arndale  18 guest-start/debian.repeat  fail pass in 185058

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt     16 saverestore-support-check    fail  like 184921
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop            fail like 184921
 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop             fail like 184921
 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop             fail like 184921
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop            fail like 184921
 test-armhf-armhf-xl-rtds     18 guest-start/debian.repeat    fail  like 184921
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop            fail like 184921
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop            fail like 184921
 test-armhf-armhf-libvirt-raw 15 saverestore-support-check    fail  like 184921
 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop             fail like 184921
 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check   fail like 184921
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop             fail like 184921
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184921
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass
 test-amd64-i386-libvirt-xsm  15 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     15 migrate-support-check        fail   never pass
 test-amd64-i386-xl-pvshim    14 guest-start                  fail   never pass
 test-amd64-i386-libvirt      15 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass
 test-arm64-arm64-xl-thunderx 15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 15 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit1  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     16 saverestore-support-check    fail   never pass
 test-amd64-i386-libvirt-raw  14 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-raw 14 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-raw 15 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-vhd      14 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-vhd      15 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-raw 14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      15 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-qcow2 14 migrate-support-check        fail never pass

version targeted for testing:
 linux                84075826304f1a297838de6bcfd9bd84f566026e
baseline version:
 linux                3fec063b052e395f4920fbc59a8d0bb3c9666d76

Last test of basis   184921  2024-03-06 14:47:02 Z   10 days
Testing same since   185054  2024-03-15 19:18:15 Z    1 days    3 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Morton 
  Andy Shevchenko 
  Andy Shevchenko 
  Ansuel Smith 
  Arnd Bergmann 
  Bjorn Andersson 
  Bjorn Andersson 
  Chandan Kumar Rout  (A Contingent Worker at Intel)
  Cosmin Tanislav 
  David S. Miller 
  Dexuan Cui 
  Dmitry Torokhov 
  Dylan Hatch 
  Edward Adam Davis 
  Eric Dumazet 
  Florian Fainelli 
  Florian Westphal 
  Greg Kroah-Hartman 
  Haiyang Zhang 
  Harshit Mogalapalli 
  Hugo Villeneuve 
  Jakub Kicinski 
  Jan Kundrát 
  Jason Xing 
  Johan Hovold 
  Johannes Berg 
  John Efstathiades 
  Juhee Kang 
  Lena Wang 
  Lina Iyer 
  Linux Kernel Functional Testing 
  Maciej Fijalkowski 
  Magnus Karlsson 
  Marek Vasut 
  Mark Brown 
  Nico Pache 
  Oleg Nesterov 
  Oleksij Rempel 
  Pablo Neira Ayuso 
  Paolo Abeni 
  Rand Deeb 
  Richard Weinberger 
  Sasha Levin 
  Shachar Raindel 
  Shradha Gupta 
  Stephen Hemminger 
  Tony Nguyen 
  Werner Sembach 

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  fail    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-i386-examine-bios                                 pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  fail    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  fail    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-armhf-armhf-libvirt-qcow2                               pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-libvirt-raw                                  pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     fail    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-i386-examine-uefi                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-arm64-arm64-xl-vhd                                      pass    
 test-armhf-armhf-xl-vhd                                      pass    
 test-amd64-i386-xl-vhd                                       pass    


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

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

Explanation of these 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 1433 lines long.)


From xen-devel-bounces@lists.xenproject.org Sun Mar 17 15:37:33 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 17 Mar 2024 15:37:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694351.1083167 (Exim 4.92)
	(envelope-from )
	id 1rlsZa-0003XL-5l; Sun, 17 Mar 2024 15:37:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694351.1083167; Sun, 17 Mar 2024 15:37:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rlsZa-0003XE-2p; Sun, 17 Mar 2024 15:37:18 +0000
Received: by outflank-mailman (input) for mailman id 694351;
 Sun, 17 Mar 2024 15:37:16 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rlsZY-0003X4-Hz; Sun, 17 Mar 2024 15:37:16 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rlsZY-0001t8-Ar; Sun, 17 Mar 2024 15:37:16 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rlsZX-0000cu-Tt; Sun, 17 Mar 2024 15:37:16 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rlsZX-0005sF-TS; Sun, 17 Mar 2024 15:37:15 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=OqTZ49ZrXVyrydi+/e3xVRnARjAm/TyUf8iw+2QKw7o=; b=fPH3+IXEDfdj0D+FWa/48LEg0G
	umTsSTHkVYu0uh/86FwXkle14t/Z+26R9sR9Bw8Ksa28iwmejuw8t3hz6bv9t3JgCLGJS8Gx2UCYE
	sP3oCfuPb8FkRgDjK/amAs7T4y+XNgphfbvnF6uSoRwlWY3z8XRhxb226cZu7Jt2K80c=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 185061: tolerable FAIL
X-Osstest-Failures:
    xen-unstable:test-armhf-armhf-libvirt-raw:guest-start/debian.repeat:fail:heisenbug
    xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:windows-install:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
    xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-i386-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
X-Osstest-Versions-This:
    xen=d638e304f13a5ef7d125de5ace5f7828a7b25bac
X-Osstest-Versions-That:
    xen=d638e304f13a5ef7d125de5ace5f7828a7b25bac
From: osstest service owner 
Date: Sun, 17 Mar 2024 15:37:15 +0000

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt-raw 17 guest-start/debian.repeat  fail pass in 185057

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

version targeted for testing:
 xen                  d638e304f13a5ef7d125de5ace5f7828a7b25bac
baseline version:
 xen                  d638e304f13a5ef7d125de5ace5f7828a7b25bac

Last test of basis   185061  2024-03-17 01:52:11 Z    0 days
Testing same since                          (not found)         0 attempts

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-i386-examine-bios                                 pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-armhf-armhf-libvirt-qcow2                               pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-armhf-armhf-libvirt-raw                                 fail    
 test-amd64-i386-libvirt-raw                                  pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-i386-examine-uefi                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-arm64-arm64-xl-vhd                                      pass    
 test-armhf-armhf-xl-vhd                                      pass    
 test-amd64-i386-xl-vhd                                       pass    


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

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

Explanation of these 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


Published tested tree is already up to date.



From xen-devel-bounces@lists.xenproject.org Sun Mar 17 15:45:30 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 17 Mar 2024 15:45:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694355.1083177 (Exim 4.92)
	(envelope-from )
	id 1rlshS-0005GX-Ru; Sun, 17 Mar 2024 15:45:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694355.1083177; Sun, 17 Mar 2024 15:45:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rlshS-0005GQ-Ov; Sun, 17 Mar 2024 15:45:26 +0000
Received: by outflank-mailman (input) for mailman id 694355;
 Sun, 17 Mar 2024 15:45:26 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rlshS-0005GK-CL
 for xen-devel@lists.xenproject.org; Sun, 17 Mar 2024 15:45:26 +0000
Received: from mx0a-0039f301.pphosted.com (mx0a-0039f301.pphosted.com
 [148.163.133.242]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5d2df6bf-e475-11ee-a1ee-f123f15fe8a2;
 Sun, 17 Mar 2024 16:45:23 +0100 (CET)
Received: from pps.filterd (m0174678.ppops.net [127.0.0.1])
 by mx0a-0039f301.pphosted.com (8.17.1.24/8.17.1.24) with ESMTP id
 42H3g2Z6002322; Sun, 17 Mar 2024 15:45:11 GMT
Received: from eur05-am6-obe.outbound.protection.outlook.com
 (mail-am6eur05lp2105.outbound.protection.outlook.com [104.47.18.105])
 by mx0a-0039f301.pphosted.com (PPS) with ESMTPS id 3ww3jrhw9p-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Sun, 17 Mar 2024 15:45:11 +0000 (GMT)
Received: from DB8PR03MB6108.eurprd03.prod.outlook.com (2603:10a6:10:ed::15)
 by AS4PR03MB8650.eurprd03.prod.outlook.com (2603:10a6:20b:589::10) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.26; Sun, 17 Mar
 2024 15:45:07 +0000
Received: from DB8PR03MB6108.eurprd03.prod.outlook.com
 ([fe80::cb1c:3d36:163:e23]) by DB8PR03MB6108.eurprd03.prod.outlook.com
 ([fe80::cb1c:3d36:163:e23%7]) with mapi id 15.20.7386.023; Sun, 17 Mar 2024
 15:45:07 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5d2df6bf-e475-11ee-a1ee-f123f15fe8a2
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=eTxXyClXLhL8BrH4P3Oom+POK4GHGUMRGPRJgau915EZLu63K62Om6LB5mMNR/wQT+ZYL5L24AFO26LHjY70sxLawArdPblIPfNQm7ARIKsZZnaYKIH8UuTAw4mUkYZ85Bc6BtWie1WZCzh0VBjKzWcsdGYqncWQ3Gq9ENBL0q6Q+xPIu3hELcEQqGUa5HFB2feRn7wHeO9OtL7JOgUE+V8Xt4tEtY6CNS9603OLZJ8iwfcA0SeV7MUi0nOL3AryrAcXHAto9CeFoLPvApH2ldQeGhHR0wjYPq/kcyju+/eXNiAOSc1nn400qISWIE0NCdkRC6lez74TnUg0Zi4uIg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=6SLbOqfradRDs2Wlbhbhjele5KQOavepKjZl/yDqo40=;
 b=l+2Hk2eqQwxGmMeCXZN/sjSbsKT5vjdKBoycD4MH0C11WuOqOWZbCKBK/iQkfx1fuktA+HmRAJIeJ0Wfggy8aP95SHUxRmK8g3eA2Usk8hiTSadxihD58XEffVJal2QY+fYjYFKaq/iFzkGyCo3E1PyeSMlKcuhsh6Z0CdQ0Kr4StFPKhsstYg/lzlWViy664aEgQMFZRngRL9Vblkxt6MqNHX17TnuH4TV7MgrcMh1JK3ScfyrqwZwlIIGlOY48ErkqyFKYP4JuAXfvNb7vg0JxG50VTkbs5j+iiHg3/uzDKn33LB9BR8O9P9PhpRW/TTNi5IeS+zvqkP6YhMdwFw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector2;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=6SLbOqfradRDs2Wlbhbhjele5KQOavepKjZl/yDqo40=;
 b=nHq5vRY6C8lzDZ7JDdW/lnNAhsyrBe7b3UmpfBwlEDcVvxHFmcYkwFuKX8/rjMjG6QDNNQeCfkiTeu0MUBCkgkQFW2QRMr4xV7dhWFrfBkdb5W2yXkE2a7LZh1qMCmaFIvdCdWZWrRysOK6s/NxoRIGgIYAy8Y405Bal9Df+A7Rx7NiSyzspHVJ0YcRQPpvpOVc141blwUns5gmAWGlQ1xIPNVU8Cq1pu00c69Nj5TVAYbgZwK9WjDBGhM6vNAn6xgWtzI90aabDvcwXmrvb1PdIMqGfkuAYEEelsgJ1WDoeF19esY2l22fdqR9W+/PjfLxanZeoZArDQCMI2Jgf0Q==
From: Oleksandr Tyshchenko 
To: Juergen Gross ,
        "linux-kernel@vger.kernel.org"
	
CC: Stefano Stabellini ,
        "xen-devel@lists.xenproject.org" ,
        Demi Marie
 Obenour 
Subject: Re: [PATCH 1/2] xen/evtchn: avoid WARN() when unbinding an event
 channel
Thread-Topic: [PATCH 1/2] xen/evtchn: avoid WARN() when unbinding an event
 channel
Thread-Index: AQHadRYXv0kOlvmk5E2hHL7QAKtBUrE8GfkA
Date: Sun, 17 Mar 2024 15:45:07 +0000
Message-ID: <45f63f9b-43c7-494b-b10d-e2b43d16d448@epam.com>
References: <20240313071409.25913-1-jgross@suse.com>
 <20240313071409.25913-2-jgross@suse.com>
In-Reply-To: <20240313071409.25913-2-jgross@suse.com>
Accept-Language: en-US, ru-RU
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DB8PR03MB6108:EE_|AS4PR03MB8650:EE_
x-ms-office365-filtering-correlation-id: 5d5d2cc3-2283-4d24-06e6-08dc46993892
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 
 1dbxxCFZPEk1X10fidK8U9z+TNnJ6ofQC5A363aU6lsJawNZInEcdeLgEd4qRpQGGooXwKUKVIEOrwOF7EkI70xISRxjN+uZ/sjFRKI0HCUi5Xg5E5wJdSCAEjgzKCPSBlMrp4uaWEie+6EYjRoQzcr7XF+EUcn8O7kr6hECpUT5N5ZQrWf8EXm4cHdtIbk7arv6Y0t1gzNVmlqWmzzxVpKD+KkyZS2lNGOIshvpcAGIBv4SqZvDLVjDuQdgSlhnreJywJt5glAWvlRsE5z9ycY72jDmD81R1OwangW7ok4tWZTPMzF381PU3SJT3/Yh1SwTzwL3Ch4sduSf1fg8QetlOvvZ1EN7k5pLZhwaXNE7i/uYlpDUxa+0qz9/YyUioOyKxbpdkGpE9XT+Nltjz1cn7/ClftsWYuDRTNJljo9OfkLMRu11oBH6NfkO7VT2WoKAe+hs6WqgmoDOhOoxokbmxBgZGfOJ5Yxs9Q4cWk+TaWghX/bUs9rwQp8AYNjqVZ/Ql4naG9txMordJab7KnbLgPRq4w/EiJ7CbzYnMiNuZ+U5qcCa9HDsTtH7+rp4MmKkWUmI2TfH5YogB42mbVg0yFGR+wv+ISWvyH9fO811zg8gX05x9AZGih8PXLQ047wQrlhLXPTLN8z3we79vFZkFvMqkkF+mG92yV4dPPHmpEFRquNW/v6kj1kWmt5AJW+Yyj9movLy7e937emkEQlMNAxbNHGamiaKyQDk8RE=
x-forefront-antispam-report: 
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB8PR03MB6108.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(1800799015)(376005)(366007)(38070700009);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 
 =?utf-8?B?L1U2dEc4VFdWYlRIcnk3MmFxbWV3OUo3UWM1bTRGcjAvaDlOTGM5d3R0UVVn?=
 =?utf-8?B?OWJ6ZTRicVJBM3pNbVdHL3hSWkZYTEtrTmJzR2RLRG1vT1BKL3laTXpLd0p2?=
 =?utf-8?B?RTlKeGVDa20xYUN3ZGoweFViU3pKcnFrTXF0OXVIM0ZpWFBXcGVpVVlOWDR4?=
 =?utf-8?B?N0hkeHMzUys3N0FBU3YyWkJSRmJqK3JwTGZIWUJRM2wvMjVkV3F3YjdnMjh5?=
 =?utf-8?B?WFRrY21RNTJlaHpsMXB6Y0NRMktrTGNUZ0VDRG45emNoaWc4d00wbHdkOUJF?=
 =?utf-8?B?cUpQWSt3VnhoaGtIN2hqWUF1YXFiVThvd2dIeWUrNnFYSWdZbys2WFRVY2VI?=
 =?utf-8?B?Yzh3dFczRXIxNTN6VFJmRW9OaTZka21QLzc0VnJlMWJiR2FIWGtKMUhnN3BJ?=
 =?utf-8?B?MmZNbEUwRGlpOUE5b05WUUhvUVdralhKVjdEZ2N1akhub1Jjdlk1Z0pydFh3?=
 =?utf-8?B?VEJ0Rk4zUEpUbFQ1eXUrMnlXVE43bVFpVDBJOUJyK0lYY3BDdFI0bnZ3Tzl3?=
 =?utf-8?B?TzdIY0RtOVVHN2xSajY4bzRxc3AwekUwV09qVC9OMnFuMGZxd2pkVy9BZ0ZG?=
 =?utf-8?B?VzgwU2FpanBaWm9veWdLQW5wVHh2dnNqeHJxL01mem8vcHBOcnVtWXB5M0Fn?=
 =?utf-8?B?Q2NsVjB4eXozS05TUG02eGlEM2ppRzJyWStYa3VkSHlMMUxqemorRFg2Riti?=
 =?utf-8?B?Rkdvb0FHQXViZzMycTZNbDNuNnhYcmhvaWRRcC9oeENwQkxGR0EyeXRjdkNU?=
 =?utf-8?B?eWJVUlJxaEJTVzJ5RkxYbmVoaEtvdEJrSzJ3WndRejVtdUhZV0lpWTEybmhy?=
 =?utf-8?B?U0drSlQzQTFMazJpS1dpcGJOSm10eVk1SHJ3YTlDSTg4ZmdmK0pOSU9EOVo5?=
 =?utf-8?B?QnA3TUdkanJrVWZpK0xyQnM0b09WYldiYUpsUTVRNHVsLzY2eHpmK0loczFk?=
 =?utf-8?B?QmhCbWpjdXFaeDNSczE1VXVVUzdJNzFMRDZNMnVENGE4WlRqckt0SUFSdWtj?=
 =?utf-8?B?ZDZQS3oyQWRFSERhY2VsQmpzYUIyMk1kdnRPL0JwVnBKczFOYzBFL0k4UDZ1?=
 =?utf-8?B?Q0ZBb09kVE1PNVJ2aG5iRWNpalpYS3NFZWVwQXM1USt2bjVHWE9UNTRBSG1I?=
 =?utf-8?B?dVpsYjJGRXp6OS9nenViK2JTOC9QUk9mNDRoSE5RSkZydTNtanM5UjFLYnpC?=
 =?utf-8?B?QlNUdlI1WTNXT0tPL2M1cWdRTjhTTWhkeVhCc2VLNVZONW5lQkxCWVJvYlBY?=
 =?utf-8?B?cnY5V2REQW9ualdrL1NIWkF5OWMzelZrdnlzeU53cUJUcktaOUV2ZlJyTXkv?=
 =?utf-8?B?elFkVllyWTFhay9TckRIYzZxcTBDZVcxMnNHcElFaDZLOFJRYmRnYmZqbUx5?=
 =?utf-8?B?RURac2F2Y2xhdkpQYWV1Mkp2bEs4NlBkQmpxNHdhOU0wcWNUcGF2Z0lubk81?=
 =?utf-8?B?TTREcGVmbUJBTWNYVW02ZUhodm9Va2tQZkI4V1V4Q2dIMVFVSXpqSmxLakpH?=
 =?utf-8?B?VmdoT0I1aHJKeW9OMjBXQ0N6M1BlS3k2Z3Irb3NhZThHZ0hLRDZ4ZzdtZXd6?=
 =?utf-8?B?TlFMTzQ3S0pTQlJQUjFGeDkyUmZNUXI5UHpPS0U1VlBYY0NPUyt2SkhzZzhZ?=
 =?utf-8?B?OUlRTUhUU2J6MU1xVjk2dlpaUmxENTJKdjZpVjBPcktPNlhyTUZCM1E1RGww?=
 =?utf-8?B?Y0NqREJrcGtZNnp2SmxZQWNqaFV0d0d2bnhscTRKMmVYMHdYOTF6OWphYm1F?=
 =?utf-8?B?Z3hDYU92OVpvdVNYaGwwRmNEOEl1RXJ2bmI3ZXI2eE5IWjRxQ1BHbXVCMmVw?=
 =?utf-8?B?TkxEM3dxaW82azBsVFYzK3dQRWtJZlRZSWtLOWs4U3l1UHQvK202dUt4SWlR?=
 =?utf-8?B?SEVzS1RtSVRaMUxTTGI4YllPbDhGVHBuNGtJU3oweTVpMEZWUVdrUGJkNnhJ?=
 =?utf-8?B?VlJtajFuVTRXNUlwMDZtSHE1bnd2UjdpUGpDa0tzZ2gwd3RUb3VFMWJIS0l6?=
 =?utf-8?B?RU01Q0hKdlZSVGFNWkR3azUyNUVMR0MvVVYxRnR4N3BRbDBHVG1rNEZUbzN5?=
 =?utf-8?B?emNGVHl1UFZtamFzSGFVRFkwRGE3Rm0vL1pnWmpEdVdMYndibzJUdmNsRVVV?=
 =?utf-8?B?UlgrVEhoRFNuYnVtb0RYZndJNEk1MXVSaEszUWh1Y1N0MHRDUlVCcm9rRktD?=
 =?utf-8?Q?rZuYtP3dHe9151deBZGLKxg=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <996C6E110021CD47BC77497A62B2FE1B@eurprd03.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DB8PR03MB6108.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5d5d2cc3-2283-4d24-06e6-08dc46993892
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Mar 2024 15:45:07.2424
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: jU/gjjh+2vFzojpDaAPL7JsavPeTdO34ZNqOvrYxzKubmYEubTXQ2On8s5SSs4m34mwtvv+m1obp5o5/gWMi3K1a938F7IRoDvNrFdsVZks=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS4PR03MB8650
X-Proofpoint-ORIG-GUID: NuRuHINoOci2C9RIOSFundAzoEsy2n-y
X-Proofpoint-GUID: NuRuHINoOci2C9RIOSFundAzoEsy2n-y
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26
 definitions=2024-03-17_11,2024-03-15_01,2023-05-22_02
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 mlxscore=0
 clxscore=1011 priorityscore=1501 malwarescore=0 suspectscore=0
 phishscore=0 impostorscore=0 spamscore=0 adultscore=0 mlxlogscore=999
 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.19.0-2403140001 definitions=main-2403170123

DQoNCk9uIDEzLjAzLjI0IDA5OjE0LCBKdWVyZ2VuIEdyb3NzIHdyb3RlOg0KDQpIZWxsbyBKdWVy
Z2VuDQoNCg0KPiBXaGVuIHVuYmluZGluZyBhIHVzZXIgZXZlbnQgY2hhbm5lbCwgdGhlIHJlbGF0
ZWQgaGFuZGxlciBtaWdodCBiZQ0KPiBjYWxsZWQgYSBsYXN0IHRpbWUgaW4gY2FzZSB0aGUga2Vy
bmVsIHdhcyBidWlsdCB3aXRoDQo+IENPTkZJR19ERUJVR19TSElSUS4gVGhpcyBtaWdodCBjYXVz
ZSBhIFdBUk4oKSBpbiB0aGUgaGFuZGxlci4NCj4gDQo+IEF2b2lkIHRoYXQgYnkgYWRkaW5nIGFu
ICJ1bmJpbmRpbmciIGZsYWcgdG8gc3RydWN0IHVzZXJfZXZlbnQgd2hpY2gNCj4gd2lsbCBzaG9y
dCBjaXJjdWl0IHRoZSBoYW5kbGVyLg0KPiANCj4gRml4ZXM6IDllOTBlNThjMTFiNyAoInhlbjog
ZXZ0Y2huOiBBbGxvdyBzaGFyZWQgcmVnaXN0cmF0aW9uIG9mIElSUSBoYW5kZXJzIikNCj4gUmVw
b3J0ZWQtYnk6IERlbWkgTWFyaWUgT2Jlbm91ciA8ZGVtaUBpbnZpc2libGV0aGluZ3NsYWIuY29t
Pg0KPiBUZXN0ZWQtYnk6IERlbWkgTWFyaWUgT2Jlbm91ciA8ZGVtaUBpbnZpc2libGV0aGluZ3Ns
YWIuY29tPg0KPiBTaWduZWQtb2ZmLWJ5OiBKdWVyZ2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+
DQoNCg0KUmV2aWV3ZWQtYnk6IE9sZWtzYW5kciBUeXNoY2hlbmtvIDxvbGVrc2FuZHJfdHlzaGNo
ZW5rb0BlcGFtLmNvbT4NCg0KDQo+IC0tLQ0KPiAgIGRyaXZlcnMveGVuL2V2dGNobi5jIHwgNiAr
KysrKysNCj4gICAxIGZpbGUgY2hhbmdlZCwgNiBpbnNlcnRpb25zKCspDQo+IA0KPiBkaWZmIC0t
Z2l0IGEvZHJpdmVycy94ZW4vZXZ0Y2huLmMgYi9kcml2ZXJzL3hlbi9ldnRjaG4uYw0KPiBpbmRl
eCA1OTcxNzYyOGNhNDIuLmY2YTIyMTZjMmM4NyAxMDA2NDQNCj4gLS0tIGEvZHJpdmVycy94ZW4v
ZXZ0Y2huLmMNCj4gKysrIGIvZHJpdmVycy94ZW4vZXZ0Y2huLmMNCj4gQEAgLTg1LDYgKzg1LDcg
QEAgc3RydWN0IHVzZXJfZXZ0Y2huIHsNCj4gICAJc3RydWN0IHBlcl91c2VyX2RhdGEgKnVzZXI7
DQo+ICAgCWV2dGNobl9wb3J0X3QgcG9ydDsNCj4gICAJYm9vbCBlbmFibGVkOw0KPiArCWJvb2wg
dW5iaW5kaW5nOw0KPiAgIH07DQo+ICAgDQo+ICAgc3RhdGljIHZvaWQgZXZ0Y2huX2ZyZWVfcmlu
ZyhldnRjaG5fcG9ydF90ICpyaW5nKQ0KPiBAQCAtMTY0LDYgKzE2NSwxMCBAQCBzdGF0aWMgaXJx
cmV0dXJuX3QgZXZ0Y2huX2ludGVycnVwdChpbnQgaXJxLCB2b2lkICpkYXRhKQ0KPiAgIAlzdHJ1
Y3QgcGVyX3VzZXJfZGF0YSAqdSA9IGV2dGNobi0+dXNlcjsNCj4gICAJdW5zaWduZWQgaW50IHBy
b2QsIGNvbnM7DQo+ICAgDQo+ICsJLyogSGFuZGxlciBtaWdodCBiZSBjYWxsZWQgd2hlbiB0ZWFy
aW5nIGRvd24gdGhlIElSUS4gKi8NCj4gKwlpZiAoZXZ0Y2huLT51bmJpbmRpbmcpDQo+ICsJCXJl
dHVybiBJUlFfSEFORExFRDsNCj4gKw0KPiAgIAlXQVJOKCFldnRjaG4tPmVuYWJsZWQsDQo+ICAg
CSAgICAgIkludGVycnVwdCBmb3IgcG9ydCAldSwgYnV0IGFwcGFyZW50bHkgbm90IGVuYWJsZWQ7
IHBlci11c2VyICVwXG4iLA0KPiAgIAkgICAgIGV2dGNobi0+cG9ydCwgdSk7DQo+IEBAIC00MjEs
NiArNDI2LDcgQEAgc3RhdGljIHZvaWQgZXZ0Y2huX3VuYmluZF9mcm9tX3VzZXIoc3RydWN0IHBl
cl91c2VyX2RhdGEgKnUsDQo+ICAgDQo+ICAgCUJVR19PTihpcnEgPCAwKTsNCj4gICANCj4gKwll
dnRjaG4tPnVuYmluZGluZyA9IHRydWU7DQo+ICAgCXVuYmluZF9mcm9tX2lycWhhbmRsZXIoaXJx
LCBldnRjaG4pOw0KPiAgIA0KPiAgIAlkZWxfZXZ0Y2huKHUsIGV2dGNobik7


From xen-devel-bounces@lists.xenproject.org Sun Mar 17 16:03:59 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 17 Mar 2024 16:03:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694362.1083188 (Exim 4.92)
	(envelope-from )
	id 1rlszK-0000Ze-GM; Sun, 17 Mar 2024 16:03:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694362.1083188; Sun, 17 Mar 2024 16:03:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rlszK-0000ZX-D6; Sun, 17 Mar 2024 16:03:54 +0000
Received: by outflank-mailman (input) for mailman id 694362;
 Sun, 17 Mar 2024 16:03:53 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rlszJ-0000ZP-3j
 for xen-devel@lists.xenproject.org; Sun, 17 Mar 2024 16:03:53 +0000
Received: from mx0a-0039f301.pphosted.com (mx0a-0039f301.pphosted.com
 [148.163.133.242]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f1a1886d-e477-11ee-afdd-a90da7624cb6;
 Sun, 17 Mar 2024 17:03:51 +0100 (CET)
Received: from pps.filterd (m0174679.ppops.net [127.0.0.1])
 by mx0a-0039f301.pphosted.com (8.17.1.24/8.17.1.24) with ESMTP id
 42H3sfal022515; Sun, 17 Mar 2024 16:03:47 GMT
Received: from eur04-he1-obe.outbound.protection.outlook.com
 (mail-he1eur04lp2050.outbound.protection.outlook.com [104.47.13.50])
 by mx0a-0039f301.pphosted.com (PPS) with ESMTPS id 3ww4t2subd-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Sun, 17 Mar 2024 16:03:47 +0000 (GMT)
Received: from VE1PR03MB6109.eurprd03.prod.outlook.com (2603:10a6:803:10c::19)
 by AS8PR03MB8102.eurprd03.prod.outlook.com (2603:10a6:20b:445::6)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.26; Sun, 17 Mar
 2024 16:03:43 +0000
Received: from VE1PR03MB6109.eurprd03.prod.outlook.com
 ([fe80::69af:b5f1:b3b0:4061]) by VE1PR03MB6109.eurprd03.prod.outlook.com
 ([fe80::69af:b5f1:b3b0:4061%7]) with mapi id 15.20.7386.023; Sun, 17 Mar 2024
 16:03:42 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f1a1886d-e477-11ee-afdd-a90da7624cb6
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=P8dwVar/nWMLx7IhvEbFjCFDxokiSdxNoJF8aSKfVNRQlHPQgIfnQEnyFfD/f+xr01PfX3vUjxTnC3aPHvaJyZ+ayk791MM3z76KRlSiHH1VBXe3TWdMIekz2mTdmCBUsldPGdTfbQ82ZW+ahWjowoVp1yrZweuIlJ6iDy47bl1sVKdsYqnCtcvfq62J29/Iqhbj/RCuB0qev4eogkRLi0rVhWmmZrmbcsgJUQ0/OByAgZWTG7Xly1Xwn8+CFVKy4pNdBDx/TprJsxy0XuAB5B0E4Of8TE6PhzmFt6DEkJP1KBGFERaCWUXGJ0i7yQE2eCScd/ZYjD1rlqCklDORsg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=smMv8DutK5AvTFrpMG2RuL8Lil3iKk+bApA6CRuQv20=;
 b=kv+ZXmreuMg0JeyDu7u5Rj9+vmMzh/I8EsSywDAlr1/W/s6nwNkLSgDUCVPYgEhg2g/ljbrAIozHqMh7KiOS47lLypvooLdDW1d2aTAtp2w/KOVwvoydnellt3IiLsNCaRn88um61gjgrjdsR4ds00nPQcEiL96PRWes+/5NXfuGhD2tK6Z8a43oyXFskEFriaTYRN8AqyBGH/jY7kolziWoUqSsMGV0q/Mfj9aGmt4McaBdVtqF/JJBtI1broMj4Z0X++/BPgObvRJXCLVnjkskf4uOSrcxbX5FoBmg+sJNet8aK/BoFJrNyGqIZljdl/6PEJpRfT+KVXsPutKkpQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector2;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=smMv8DutK5AvTFrpMG2RuL8Lil3iKk+bApA6CRuQv20=;
 b=NBJ0w3FeZxpQIKUIUqCShER8rAqdGtkO3C8mGALTTBLxjkMNjVPM1vJHY6ERMhyF8WtQRhaCJ3OBJIvxrIFaw/PLM6X4LBCodZVNez9cB18A2vNuWf5fcq2gn/ESEHhNbbPwXN4ajR/tvAFx5i9C6qn2sgzis83X2wMIBwb7OJ1ExiwWhWX6RRVXU76d88j28aA0t2FhA9C6eF5F9pTHPktZSkXB6HtlQUO6KMJXIoXiPgEFwb/IUWxhGU/ZnCewCAG5P8so2akzR7iXvWO49361YHDwBpoHpuXg4Bv4Rf6nuHHJzQE9D30FVkc5cf9bBYnJzpBlC2GAOmRwyk864Q==
From: Oleksandr Tyshchenko 
To: Juergen Gross ,
        "linux-kernel@vger.kernel.org"
	
CC: Stefano Stabellini ,
        "xen-devel@lists.xenproject.org" 
Subject: Re: [PATCH 2/2] xen/events: increment refcnt only if event channel is
 refcounted
Thread-Topic: [PATCH 2/2] xen/events: increment refcnt only if event channel
 is refcounted
Thread-Index: AQHadRYYap97PRUEWUyJa/zlA+m6fbE8Hy2A
Date: Sun, 17 Mar 2024 16:03:41 +0000
Message-ID: <3dc20f60-9811-45c0-a6bf-773db35db78a@epam.com>
References: <20240313071409.25913-1-jgross@suse.com>
 <20240313071409.25913-3-jgross@suse.com>
In-Reply-To: <20240313071409.25913-3-jgross@suse.com>
Accept-Language: en-US, ru-RU
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: VE1PR03MB6109:EE_|AS8PR03MB8102:EE_
x-ms-office365-filtering-correlation-id: fb571332-8c90-4569-4314-08dc469bd109
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 
 +TeNImJmWkBgSq0nGdvdkKgT/pk7s07bokTi91SxSsfQc6rn4hPXL8vIzvb/WJtpoJUtoK5/8vgd/mwuwyMbDdrZGx7egSRiQQmM/p+DJIUFWSerF89AMgKaDxPEHs/E2kSaJE+9zjyTq5Jp8Ngr9pKeKfgkbxMs0pwvwgvEw7LLfQJW1QxOWP75fLp++FHpmqDVWJzbMY9hy4wxGBKZfZhT+aKuLUmZ7CxhQVYOSZDyb38AUqJnDD0pPZEAbmJF7M7oG3dMPNd72mh1WY2JO9d8Jd5GWHOVU3GHRRh3hD3rtq5D5ujjv4pUnDGZCAY8wn8sK/dcKYYVaB+CG7Q4OayyJY3D71g6S7oB09IHFz1VUThBzsyC4X9q73GqmqZHlrRdO7dXyNqO3OGpmFotIXnjgqj3WoGl6sVBkMQpe3v9Er+i7uowKSeCcsUKUVBw9rl+wCRr+rghGDovERegucXd3VFBacyEFLFCZ1wCayamI/rJDpfyWKfDaAqjMMlIAWwpp+YsJSEYjN1RW4gTiGg1hZduzUMiXFU30cwfp6jE37+TB+KDL52iES2wQqB/L33vOSn7xXct48C3WWV3NQcl2zgMpq+knD3eQ0AzOJuf/JyhHDvjakOjk6PyR9fC18+D1TqgH9duBmH7jtfHUcIycPP5jv2fAgIg46nuQrKa8UWqcpJJ8ng1GTRhRy9LJEuABwlHaWf/DLzHMxxPzg==
x-forefront-antispam-report: 
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VE1PR03MB6109.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(376005)(1800799015)(366007)(38070700009);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 
 =?utf-8?B?aUFYUUwrdEZLR3NjbXdicmdYSElILzUzU1pFS2hacDdOTWQvVlRpRlk5OGJk?=
 =?utf-8?B?T1pqTWhKd2JRcnlCbmlBemdvNjNKVFZWd2pSTjhnSENrQ21HNGtEdTBKNzQw?=
 =?utf-8?B?ZnZsYkZxWmQ2RW9rSmthK3Y0R3dWeWpFU0lmMElFUnhQYzVKN3B4TEZvU1lm?=
 =?utf-8?B?TXpIT043VlZ1T2tzeG9rR1BvNTdMZndIWG1RZTYwa2Y2UHVwUURNYlp4bkdC?=
 =?utf-8?B?cjVkdlJEQUZ4eGZjeTdnNVpCengzNmFkVWpTK0tOQm9LUGxkL0d2a3ZmR1FU?=
 =?utf-8?B?SG1PVkpHVkFvemZQYkljeDBkNmFNaXNIbDVySkN6VTJ4aFRlNjZXcXJpUTZP?=
 =?utf-8?B?T1pERnpUWHZUSytNUEpaSFV5RG1SQUZIWGhpV014bUg5dnRVR01LU2NkZndn?=
 =?utf-8?B?MGlOc2oxZ1NlWVdtOFIrWjRBczhHSnl2U0dQNnNqaG5BaWpnMWhJaXFWTVdV?=
 =?utf-8?B?TXdodVQvaGsrOWNTK0pCb2VFOG1FUHRkTXlvS3ZKUy92aFNyR2NZYmhmWFBn?=
 =?utf-8?B?UUlMZ29HWmZsN2d3SWk3L0UyYmJuamZyNG84WUR6QzJlSkRLb3hDUFhZSTUx?=
 =?utf-8?B?UTdTOERKSzBMd2l0MDJXUWF5Y3I2U0pmL0lkaVRjd0dYVVBhRVJLdDY5Y3ZH?=
 =?utf-8?B?akIyalFzRE9hVGRuSExDVGVxaTN4Mkt0UVhCZ0R4TjVFd1VoLzA4OUt0anBs?=
 =?utf-8?B?WXpvYWc1dThFcHZ5RXJ1dlo2UjBLdnFacnBWNVdtS2RMYmNvYW5haXJ0RVZG?=
 =?utf-8?B?U0t0YU1CYjhxcFJQa3FQTE95ZjdmZDA3SFQ3OGFjVG5IclFJNmlEalJIem03?=
 =?utf-8?B?MlpyL3pScDBZMDQ4ZXlhUUQwQkU5VlhsVmZVTHozZllqdEJGUDJWeHpTZDNQ?=
 =?utf-8?B?VFVpSkVHQmpCNmtodk0zVWRJcEkzT3UrSkUySFBkNkM3TjVqcTlhZTVkT21P?=
 =?utf-8?B?MHZQQXNaa1dtOGQ4L1ByZ2tpMGY3VEVrTitVT2s1cjAwbEtVbUF6VE5zRFRr?=
 =?utf-8?B?OThJVWUxY3BsSDYvMmFEUVZBS1IvR2NmTi9VdUVicjN2SityTGNGYjhGaUUy?=
 =?utf-8?B?b1ZBQkZwN1ByQ3lndVN4REZjcHpHeXdXd3E2d0RuOWN6RGE1cmpmVzgxamdt?=
 =?utf-8?B?RnBUQUhwb3JpQW81R1VhTGd6Yzh0dWt5NmhuSTFuQytEdTdsN1Y5dDhhZ2x4?=
 =?utf-8?B?SHZlckJmeEdjdWI1Q2IybHVkTGx4TmFYK1c0RjZVTWltZHZVUUNxMXM5MFlS?=
 =?utf-8?B?U1JFK3U3dm5jcUxMVC9jelc5TlB4bStZamltVzk1N04xb05PeU9YSGNxV3Q5?=
 =?utf-8?B?WEpTTCtMVTA1SG0yc1JCSXVXZnVlU1g0ZjlyWW1iTnIyVFdQNWdUTlhiWkgw?=
 =?utf-8?B?TWdMOGI1a29wc0VKUW1GdlJsbjgreEFvbFc4VitVeWVBdVhqakcwczRNV3RV?=
 =?utf-8?B?QzBZb3ZjUzVHalRlQ1RGWHBuM3RCcWhLWmcwb2JZUDdtcUk3YUs5TG9QRFk4?=
 =?utf-8?B?T0M0QW9qZlk1NFBBTkw0a1lDd2JGWHkxdCtYalVkN0xRRlNrMVQ0Ni9xdEl4?=
 =?utf-8?B?TzQ4MDlDdmNwU3dodEhmME9zQ1RjeXZLZ21aREt2RkQ3QzFKUkU3cElXenZC?=
 =?utf-8?B?VmJMK0dpWDdtV3F3VXhQQVFZR09vc09EZmRiRjJzZ29TYjkzNmVSZENFd2pP?=
 =?utf-8?B?bjJoR1FuSnJpa1NkUllBdVIwcTFSL2c3OXVMSkhIbzJNZlE2bGxhWklXK2hq?=
 =?utf-8?B?b3ZiTUgzanZnSHVTbWhDVCtIbTJvbE1lRUdUTy8xQ0krVmZUVWk0QVp4Zjhk?=
 =?utf-8?B?TGNYZUVQeFg3U09KQ2hyTjdmQVpMTVIrcG91RFgzWXJ5T1d2N1pXcGFGTm4w?=
 =?utf-8?B?clFmWUtpM3NRdTlsR1dCRmErTmxjeXYyY3VxaFNZTnVUQ2dTQVVNR3U2UlQ3?=
 =?utf-8?B?T3BXek5uemlqL0F3Q0I4eVlmVHpyV3hZVjhhL0FiT1lKNnBLdFZaK2VDWHda?=
 =?utf-8?B?UzZ5OUw4cDltY3lyQStDTlhhUWlIYmo5cnFOSWJjejMvbDA0MVJFcUIyaWRJ?=
 =?utf-8?B?VGl6WkNZQ0NkMVFjWDZ6Ynp1NFlYSy9vZ1k1M3ZaN0syZ0NhdEt1dnVoQXJt?=
 =?utf-8?B?ZnJrMVFId202b2Zmc2lGYU5ucHJTYjNyWWhJVVZKUk41T3Nrd3ZjWTdUYzJY?=
 =?utf-8?Q?Ro4ceJmSewZJbd8INHJScH0=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <0AFDFDE8DCEB4748B771174C9B3EA771@eurprd03.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: VE1PR03MB6109.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: fb571332-8c90-4569-4314-08dc469bd109
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Mar 2024 16:03:42.0155
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: XgrSXjPkd0ArlgQ1W3rrKOtwy5mCYd8FJfyfkBsqJ9BJf00peoGviPMUQyVQTFlJk42EByP3wYepAdnmoxEF8LyyQPzX7XTpaf+yZI1zG6I=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB8102
X-Proofpoint-GUID: f7v-kkxU4dZ2RO4GzrCRz7-twCksFguS
X-Proofpoint-ORIG-GUID: f7v-kkxU4dZ2RO4GzrCRz7-twCksFguS
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26
 definitions=2024-03-17_11,2024-03-15_01,2023-05-22_02
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 phishscore=0 mlxlogscore=999
 impostorscore=0 suspectscore=0 spamscore=0 priorityscore=1501
 lowpriorityscore=0 bulkscore=0 malwarescore=0 adultscore=0 mlxscore=0
 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.19.0-2403140001 definitions=main-2403170125

DQoNCk9uIDEzLjAzLjI0IDA5OjE0LCBKdWVyZ2VuIEdyb3NzIHdyb3RlOg0KDQoNCkhlbGxvIEp1
ZXJnZW4NCg0KPiBJbiBiaW5kX2V2dGNobl90b19pcnFfY2hpcCgpIGRvbid0IGluY3JlbWVudCB0
aGUgcmVmY250IG9mIHRoZSBldmVudA0KPiBjaGFubmVsIGJsaW5kbHkuIEluIGNhc2UgdGhlIGV2
ZW50IGNoYW5uZWwgaXMgTk9UIHJlZmNvdW50ZWQsIGlzc3VlIGENCj4gd2FybmluZyBpbnN0ZWFk
Lg0KPiANCj4gQWRkIGFuIGFkZGl0aW9uYWwgc2FmZXR5IG5ldCBieSBkb2luZyB0aGUgcmVmY250
IGluY3JlbWVudCBvbmx5IGlmIHRoZQ0KPiBjYWxsZXIgaGFzIHNwZWNpZmllZCBJUlFGX1NIQVJF
RCBpbiB0aGUgaXJxZmxhZ3MgcGFyYW1ldGVyLg0KPiANCj4gRml4ZXM6IDllOTBlNThjMTFiNyAo
InhlbjogZXZ0Y2huOiBBbGxvdyBzaGFyZWQgcmVnaXN0cmF0aW9uIG9mIElSUSBoYW5kZXJzIikN
Cj4gU2lnbmVkLW9mZi1ieTogSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1c2UuY29tPg0KDQoNClJl
dmlld2VkLWJ5OiBPbGVrc2FuZHIgVHlzaGNoZW5rbyA8b2xla3NhbmRyX3R5c2hjaGVua29AZXBh
bS5jb20+DQoNCg0KPiAtLS0NCj4gICBkcml2ZXJzL3hlbi9ldmVudHMvZXZlbnRzX2Jhc2UuYyB8
IDIyICsrKysrKysrKysrKystLS0tLS0tLS0NCj4gICAxIGZpbGUgY2hhbmdlZCwgMTMgaW5zZXJ0
aW9ucygrKSwgOSBkZWxldGlvbnMoLSkNCj4gDQo+IGRpZmYgLS1naXQgYS9kcml2ZXJzL3hlbi9l
dmVudHMvZXZlbnRzX2Jhc2UuYyBiL2RyaXZlcnMveGVuL2V2ZW50cy9ldmVudHNfYmFzZS5jDQo+
IGluZGV4IDJmYWE0YmY3OGM3YS4uODFlZmZiZDUzZGM1IDEwMDY0NA0KPiAtLS0gYS9kcml2ZXJz
L3hlbi9ldmVudHMvZXZlbnRzX2Jhc2UuYw0KPiArKysgYi9kcml2ZXJzL3hlbi9ldmVudHMvZXZl
bnRzX2Jhc2UuYw0KPiBAQCAtMTE5MCw3ICsxMTkwLDcgQEAgaW50IHhlbl9waXJxX2Zyb21faXJx
KHVuc2lnbmVkIGlycSkNCj4gICBFWFBPUlRfU1lNQk9MX0dQTCh4ZW5fcGlycV9mcm9tX2lycSk7
DQo+ICAgDQo+ICAgc3RhdGljIGludCBiaW5kX2V2dGNobl90b19pcnFfY2hpcChldnRjaG5fcG9y
dF90IGV2dGNobiwgc3RydWN0IGlycV9jaGlwICpjaGlwLA0KPiAtCQkJCSAgIHN0cnVjdCB4ZW5i
dXNfZGV2aWNlICpkZXYpDQo+ICsJCQkJICAgc3RydWN0IHhlbmJ1c19kZXZpY2UgKmRldiwgYm9v
bCBzaGFyZWQpDQo+ICAgew0KPiAgIAlpbnQgcmV0ID0gLUVOT01FTTsNCj4gICAJc3RydWN0IGly
cV9pbmZvICppbmZvOw0KPiBAQCAtMTIyNCw3ICsxMjI0LDggQEAgc3RhdGljIGludCBiaW5kX2V2
dGNobl90b19pcnFfY2hpcChldnRjaG5fcG9ydF90IGV2dGNobiwgc3RydWN0IGlycV9jaGlwICpj
aGlwLA0KPiAgIAkJICovDQo+ICAgCQliaW5kX2V2dGNobl90b19jcHUoaW5mbywgMCwgZmFsc2Up
Ow0KPiAgIAl9IGVsc2UgaWYgKCFXQVJOX09OKGluZm8tPnR5cGUgIT0gSVJRVF9FVlRDSE4pKSB7
DQo+IC0JCWluZm8tPnJlZmNudCsrOw0KPiArCQlpZiAoc2hhcmVkICYmICFXQVJOX09OKGluZm8t
PnJlZmNudCA8IDApKQ0KPiArCQkJaW5mby0+cmVmY250Kys7DQo+ICAgCX0NCj4gICANCj4gICAJ
cmV0ID0gaW5mby0+aXJxOw0KPiBAQCAtMTIzNywxMyArMTIzOCwxMyBAQCBzdGF0aWMgaW50IGJp
bmRfZXZ0Y2huX3RvX2lycV9jaGlwKGV2dGNobl9wb3J0X3QgZXZ0Y2huLCBzdHJ1Y3QgaXJxX2No
aXAgKmNoaXAsDQo+ICAgDQo+ICAgaW50IGJpbmRfZXZ0Y2huX3RvX2lycShldnRjaG5fcG9ydF90
IGV2dGNobikNCj4gICB7DQo+IC0JcmV0dXJuIGJpbmRfZXZ0Y2huX3RvX2lycV9jaGlwKGV2dGNo
biwgJnhlbl9keW5hbWljX2NoaXAsIE5VTEwpOw0KPiArCXJldHVybiBiaW5kX2V2dGNobl90b19p
cnFfY2hpcChldnRjaG4sICZ4ZW5fZHluYW1pY19jaGlwLCBOVUxMLCBmYWxzZSk7DQo+ICAgfQ0K
PiAgIEVYUE9SVF9TWU1CT0xfR1BMKGJpbmRfZXZ0Y2huX3RvX2lycSk7DQo+ICAgDQo+ICAgaW50
IGJpbmRfZXZ0Y2huX3RvX2lycV9sYXRlZW9pKGV2dGNobl9wb3J0X3QgZXZ0Y2huKQ0KPiAgIHsN
Cj4gLQlyZXR1cm4gYmluZF9ldnRjaG5fdG9faXJxX2NoaXAoZXZ0Y2huLCAmeGVuX2xhdGVlb2lf
Y2hpcCwgTlVMTCk7DQo+ICsJcmV0dXJuIGJpbmRfZXZ0Y2huX3RvX2lycV9jaGlwKGV2dGNobiwg
Jnhlbl9sYXRlZW9pX2NoaXAsIE5VTEwsIGZhbHNlKTsNCj4gICB9DQo+ICAgRVhQT1JUX1NZTUJP
TF9HUEwoYmluZF9ldnRjaG5fdG9faXJxX2xhdGVlb2kpOw0KPiAgIA0KPiBAQCAtMTI5NSw3ICsx
Mjk2LDggQEAgc3RhdGljIGludCBiaW5kX2lwaV90b19pcnEodW5zaWduZWQgaW50IGlwaSwgdW5z
aWduZWQgaW50IGNwdSkNCj4gICANCj4gICBzdGF0aWMgaW50IGJpbmRfaW50ZXJkb21haW5fZXZ0
Y2huX3RvX2lycV9jaGlwKHN0cnVjdCB4ZW5idXNfZGV2aWNlICpkZXYsDQo+ICAgCQkJCQkgICAg
ICAgZXZ0Y2huX3BvcnRfdCByZW1vdGVfcG9ydCwNCj4gLQkJCQkJICAgICAgIHN0cnVjdCBpcnFf
Y2hpcCAqY2hpcCkNCj4gKwkJCQkJICAgICAgIHN0cnVjdCBpcnFfY2hpcCAqY2hpcCwNCj4gKwkJ
CQkJICAgICAgIGJvb2wgc2hhcmVkKQ0KPiAgIHsNCj4gICAJc3RydWN0IGV2dGNobl9iaW5kX2lu
dGVyZG9tYWluIGJpbmRfaW50ZXJkb21haW47DQo+ICAgCWludCBlcnI7DQo+IEBAIC0xMzA3LDE0
ICsxMzA5LDE0IEBAIHN0YXRpYyBpbnQgYmluZF9pbnRlcmRvbWFpbl9ldnRjaG5fdG9faXJxX2No
aXAoc3RydWN0IHhlbmJ1c19kZXZpY2UgKmRldiwNCj4gICAJCQkJCSAgJmJpbmRfaW50ZXJkb21h
aW4pOw0KPiAgIA0KPiAgIAlyZXR1cm4gZXJyID8gOiBiaW5kX2V2dGNobl90b19pcnFfY2hpcChi
aW5kX2ludGVyZG9tYWluLmxvY2FsX3BvcnQsDQo+IC0JCQkJCSAgICAgICBjaGlwLCBkZXYpOw0K
PiArCQkJCQkgICAgICAgY2hpcCwgZGV2LCBzaGFyZWQpOw0KPiAgIH0NCj4gICANCj4gICBpbnQg
YmluZF9pbnRlcmRvbWFpbl9ldnRjaG5fdG9faXJxX2xhdGVlb2koc3RydWN0IHhlbmJ1c19kZXZp
Y2UgKmRldiwNCj4gICAJCQkJCSAgIGV2dGNobl9wb3J0X3QgcmVtb3RlX3BvcnQpDQo+ICAgew0K
PiAgIAlyZXR1cm4gYmluZF9pbnRlcmRvbWFpbl9ldnRjaG5fdG9faXJxX2NoaXAoZGV2LCByZW1v
dGVfcG9ydCwNCj4gLQkJCQkJCSAgICZ4ZW5fbGF0ZWVvaV9jaGlwKTsNCj4gKwkJCQkJCSAgICZ4
ZW5fbGF0ZWVvaV9jaGlwLCBmYWxzZSk7DQo+ICAgfQ0KPiAgIEVYUE9SVF9TWU1CT0xfR1BMKGJp
bmRfaW50ZXJkb21haW5fZXZ0Y2huX3RvX2lycV9sYXRlZW9pKTsNCj4gICANCj4gQEAgLTE0MzAs
NyArMTQzMiw4IEBAIHN0YXRpYyBpbnQgYmluZF9ldnRjaG5fdG9faXJxaGFuZGxlcl9jaGlwKGV2
dGNobl9wb3J0X3QgZXZ0Y2huLA0KPiAgIHsNCj4gICAJaW50IGlycSwgcmV0dmFsOw0KPiAgIA0K
PiAtCWlycSA9IGJpbmRfZXZ0Y2huX3RvX2lycV9jaGlwKGV2dGNobiwgY2hpcCwgTlVMTCk7DQo+
ICsJaXJxID0gYmluZF9ldnRjaG5fdG9faXJxX2NoaXAoZXZ0Y2huLCBjaGlwLCBOVUxMLA0KPiAr
CQkJCSAgICAgIGlycWZsYWdzICYgSVJRRl9TSEFSRUQpOw0KPiAgIAlpZiAoaXJxIDwgMCkNCj4g
ICAJCXJldHVybiBpcnE7DQo+ICAgCXJldHZhbCA9IHJlcXVlc3RfaXJxKGlycSwgaGFuZGxlciwg
aXJxZmxhZ3MsIGRldm5hbWUsIGRldl9pZCk7DQo+IEBAIC0xNDcxLDcgKzE0NzQsOCBAQCBzdGF0
aWMgaW50IGJpbmRfaW50ZXJkb21haW5fZXZ0Y2huX3RvX2lycWhhbmRsZXJfY2hpcCgNCj4gICB7
DQo+ICAgCWludCBpcnEsIHJldHZhbDsNCj4gICANCj4gLQlpcnEgPSBiaW5kX2ludGVyZG9tYWlu
X2V2dGNobl90b19pcnFfY2hpcChkZXYsIHJlbW90ZV9wb3J0LCBjaGlwKTsNCj4gKwlpcnEgPSBi
aW5kX2ludGVyZG9tYWluX2V2dGNobl90b19pcnFfY2hpcChkZXYsIHJlbW90ZV9wb3J0LCBjaGlw
LA0KPiArCQkJCQkJICBpcnFmbGFncyAmIElSUUZfU0hBUkVEKTsNCj4gICAJaWYgKGlycSA8IDAp
DQo+ICAgCQlyZXR1cm4gaXJxOw0KPiAgIA==


From xen-devel-bounces@lists.xenproject.org Sun Mar 17 20:51:51 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 17 Mar 2024 20:51:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694408.1083216 (Exim 4.92)
	(envelope-from )
	id 1rlxTk-0001pP-Fj; Sun, 17 Mar 2024 20:51:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694408.1083216; Sun, 17 Mar 2024 20:51:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rlxTk-0001pI-Bt; Sun, 17 Mar 2024 20:51:36 +0000
Received: by outflank-mailman (input) for mailman id 694408;
 Sun, 17 Mar 2024 20:51:34 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rlxTi-0001p6-Sh; Sun, 17 Mar 2024 20:51:34 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rlxTi-000830-Pk; Sun, 17 Mar 2024 20:51:34 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rlxTi-0001IU-JB; Sun, 17 Mar 2024 20:51:34 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rlxTi-00084N-Ig; Sun, 17 Mar 2024 20:51:34 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=5+QrnQwSZDxQk7a+VRxwMIrioG9n72pEAXiFKwcIulY=; b=uhBvHBmHRmnz5g475KTxFAntRT
	u5SqM8mlHbDqh+RIFnoYTF4RZsNJ5yet987MuplhiNAovPe/ct3NYZDxut7EzCBq9zsXbfpDy5s6L
	HpLB/9Au65HXlOg45fRQIlpyTUaLqlLDq0td7jO5j2Z/7XWmvnfinn/u83B3P1U+8Avo=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 185062: tolerable FAIL - PUSHED
X-Osstest-Failures:
    linux-linus:test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm:guest-start/debianhvm.repeat:fail:heisenbug
    linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    linux=741e9d668aa50c91e4f681511ce0e408d55dd7ce
X-Osstest-Versions-That:
    linux=66a27abac311a30edbbb65fe8c41ff1b13876faa
From: osstest service owner 
Date: Sun, 17 Mar 2024 20:51:34 +0000

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 20 guest-start/debianhvm.repeat fail pass in 185067-retest

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

version targeted for testing:
 linux                741e9d668aa50c91e4f681511ce0e408d55dd7ce
baseline version:
 linux                66a27abac311a30edbbb65fe8c41ff1b13876faa

Last test of basis   185059  2024-03-16 14:43:18 Z    1 days
Testing same since   185062  2024-03-17 04:58:47 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Abel Vesa 
  Algea Cao 
  Andrew Halaney 
  Andrew Halaney  # sa8775p-ride
  Andy Shevchenko 
  Arnd Bergmann 
  Ben Cheatham 
  Benjamin Coddington 
  Borislav Petkov (AMD) 
  Can Guo 
  ChanWoo Lee 
  Charlie Jenkins 
  Chen Hanxiao 
  Chris Down 
  Christoph Hellwig 
  Christophe JAILLET 
  Colin Ian King 
  Conor Dooley 
  Cristian Ciocaltea 
  Dai Ngo 
  Dan Williams 
  Dave Jiang 
  Dave Wysochanski 
  David Wronek 
  Dmitry Baryshkov 
  Eric Chanudet 
  Florian Fainelli  #Broadcom
  Florian Sylvestre 
  Greg Kroah-Hartman 
  Guenter Roeck 
  Guixin Liu 
  Heiko Stuebner 
  Helge Deller 
  Jack Wang 
  Jeff Layton 
  Jiapeng Chong 
  John David Anglin 
  Jonathan Cameron 
  Jorge Mora 
  Jorge Mora 
  Josef Bacik 
  Josua Mayer 
  Julien Stephan 
  Justin Stitt 
  Justin Tee 
  Konrad Dybcio 
  Krzysztof Kozlowski 
  Lee Jones 
  Li Zhijian 
  Linus Torvalds 
  Linus Walleij 
  Louis Kuo 
  Lukas Bulwahn 
  Manivannan Sadhasivam 
  Maramaina Naresh 
  Martin K. Petersen 
  Mike Christie 
  Naveen Kumar Goud Arepalli 
  Neil Armstrong  # on SM8550-HDK
  NeilBrown 
  Nitin Rawat 
  Olga Kornievskaia 
  Peter Wang 
  Petr Mladek 
  Phi-bang Nguyen 
  Qiang Yu 
  Ranjan Kumar 
  Ricardo B. Marliere 
  Rob Herring 
  Robert Richter 
  Simone Weiß 
  Swapnil Jakhade 
  Takashi Sakamoto 
  Thierry Reding 
  Thomas Richard 
  Trond Myklebust 
  Tyrel Datwyler 
  Uwe Kleine-König 
  Vinod Koul 
  Wonjae Lee 
  Xiang Chen 
  Yihang Li 

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        fail    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-freebsd11-amd64                             pass    
 test-amd64-amd64-freebsd12-amd64                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-libvirt-qcow2                               pass    
 test-armhf-armhf-libvirt-qcow2                               pass    
 test-amd64-amd64-libvirt-raw                                 pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-amd64-xl-vhd                                      pass    
 test-arm64-arm64-xl-vhd                                      pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

Explanation of these 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 :

hint: The 'hooks/update' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
hint: The 'hooks/post-receive' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
hint: The 'hooks/post-update' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
To xenbits.xen.org:/home/xen/git/linux-pvops.git
   66a27abac311..741e9d668aa5  741e9d668aa50c91e4f681511ce0e408d55dd7ce -> tested/linux-linus


From xen-devel-bounces@lists.xenproject.org Mon Mar 18 01:07:19 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 01:07:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694439.1083232 (Exim 4.92)
	(envelope-from )
	id 1rm1Sq-00058f-SI; Mon, 18 Mar 2024 01:06:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694439.1083232; Mon, 18 Mar 2024 01:06:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rm1Sq-00058Y-NK; Mon, 18 Mar 2024 01:06:56 +0000
Received: by outflank-mailman (input) for mailman id 694439;
 Mon, 18 Mar 2024 01:06:56 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rm1Sq-00058O-9s; Mon, 18 Mar 2024 01:06:56 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rm1Sp-0002y7-Pz; Mon, 18 Mar 2024 01:06:55 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rm1Sp-0002Be-Fu; Mon, 18 Mar 2024 01:06:55 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rm1Sp-0004XS-FG; Mon, 18 Mar 2024 01:06:55 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=Il0eFVJgwg9ZF+SHqjG52Fjs8hqCpjuCiz/yJOHVffE=; b=cbROWe/XKIOh1LRBXRv4GAO2E/
	WUSSKr3/eymmmjXWQVN0XgdiCeVZ+CBcZrzac9nmMsoaa1meCRymHgaGKE1EsNqWAi7HBT9rbO78X
	Cu+ZkNfq+MoJ8F5OhxHksZYX6zJQtNzUniZWl7V55sB+6iegKqfoUlZBDWuKPQj0WrVU=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-5.4 test] 185063: regressions - FAIL
X-Osstest-Failures:
    linux-5.4:test-armhf-armhf-xl-credit1:guest-start/debian.repeat:fail:regression
    linux-5.4:test-armhf-armhf-xl-credit2:guest-start:fail:heisenbug
    linux-5.4:test-amd64-i386-xl-qemut-debianhvm-i386-xsm:debian-hvm-install:fail:heisenbug
    linux-5.4:test-armhf-armhf-libvirt-qcow2:guest-start/debian.repeat:fail:heisenbug
    linux-5.4:test-armhf-armhf-xl-credit2:guest-start/debian.repeat:fail:heisenbug
    linux-5.4:test-armhf-armhf-xl-arndale:guest-start/debian.repeat:fail:heisenbug
    linux-5.4:test-armhf-armhf-xl-multivcpu:guest-start/debian.repeat:fail:heisenbug
    linux-5.4:test-armhf-armhf-xl:guest-start/debian.repeat:fail:heisenbug
    linux-5.4:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking
    linux-5.4:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    linux-5.4:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
    linux-5.4:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking
    linux-5.4:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    linux-5.4:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    linux-5.4:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-5.4:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-5.4:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    linux-5.4:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
    linux-5.4:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
    linux-5.4:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    linux-5.4:test-amd64-i386-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-5.4:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking
X-Osstest-Versions-This:
    linux=84075826304f1a297838de6bcfd9bd84f566026e
X-Osstest-Versions-That:
    linux=3fec063b052e395f4920fbc59a8d0bb3c9666d76
From: osstest service owner 
Date: Mon, 18 Mar 2024 01:06:55 +0000

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-credit1 18 guest-start/debian.repeat fail REGR. vs. 184921

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-credit2  14 guest-start      fail in 185058 pass in 185063
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail in 185058 pass in 185063
 test-armhf-armhf-libvirt-qcow2 17 guest-start/debian.repeat fail in 185058 pass in 185063
 test-armhf-armhf-xl-credit2 18 guest-start/debian.repeat fail in 185060 pass in 185063
 test-armhf-armhf-xl-arndale 18 guest-start/debian.repeat fail in 185060 pass in 185063
 test-armhf-armhf-xl-multivcpu 18 guest-start/debian.repeat fail pass in 185058
 test-armhf-armhf-xl          18 guest-start/debian.repeat  fail pass in 185060

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-rtds 18 guest-start/debian.repeat fail in 185060 like 184921
 test-armhf-armhf-libvirt     16 saverestore-support-check    fail  like 184921
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop            fail like 184921
 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop             fail like 184921
 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop             fail like 184921
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop            fail like 184921
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop            fail like 184921
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop            fail like 184921
 test-armhf-armhf-libvirt-raw 15 saverestore-support-check    fail  like 184921
 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop             fail like 184921
 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check   fail like 184921
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop             fail like 184921
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184921
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass
 test-amd64-i386-libvirt-xsm  15 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     15 migrate-support-check        fail   never pass
 test-amd64-i386-xl-pvshim    14 guest-start                  fail   never pass
 test-amd64-i386-libvirt      15 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass
 test-arm64-arm64-xl-thunderx 15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 15 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit1  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          16 saverestore-support-check    fail   never pass
 test-amd64-i386-libvirt-raw  14 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-raw 14 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-raw 15 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-vhd      14 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-vhd      15 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-raw 14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      15 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-qcow2 14 migrate-support-check        fail never pass

version targeted for testing:
 linux                84075826304f1a297838de6bcfd9bd84f566026e
baseline version:
 linux                3fec063b052e395f4920fbc59a8d0bb3c9666d76

Last test of basis   184921  2024-03-06 14:47:02 Z   11 days
Testing same since   185054  2024-03-15 19:18:15 Z    2 days    4 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Morton 
  Andy Shevchenko 
  Andy Shevchenko 
  Ansuel Smith 
  Arnd Bergmann 
  Bjorn Andersson 
  Bjorn Andersson 
  Chandan Kumar Rout  (A Contingent Worker at Intel)
  Cosmin Tanislav 
  David S. Miller 
  Dexuan Cui 
  Dmitry Torokhov 
  Dylan Hatch 
  Edward Adam Davis 
  Eric Dumazet 
  Florian Fainelli 
  Florian Westphal 
  Greg Kroah-Hartman 
  Haiyang Zhang 
  Harshit Mogalapalli 
  Hugo Villeneuve 
  Jakub Kicinski 
  Jan Kundrát 
  Jason Xing 
  Johan Hovold 
  Johannes Berg 
  John Efstathiades 
  Juhee Kang 
  Lena Wang 
  Lina Iyer 
  Linux Kernel Functional Testing 
  Maciej Fijalkowski 
  Magnus Karlsson 
  Marek Vasut 
  Mark Brown 
  Nico Pache 
  Oleg Nesterov 
  Oleksij Rempel 
  Pablo Neira Ayuso 
  Paolo Abeni 
  Rand Deeb 
  Richard Weinberger 
  Sasha Levin 
  Shachar Raindel 
  Shradha Gupta 
  Stephen Hemminger 
  Tony Nguyen 
  Werner Sembach 

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-i386-examine-bios                                 pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  fail    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-armhf-armhf-libvirt-qcow2                               pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-libvirt-raw                                  pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-i386-examine-uefi                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-arm64-arm64-xl-vhd                                      pass    
 test-armhf-armhf-xl-vhd                                      pass    
 test-amd64-i386-xl-vhd                                       pass    


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

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

Explanation of these 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 1433 lines long.)


From xen-devel-bounces@lists.xenproject.org Mon Mar 18 05:54:22 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 05:54:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694458.1083247 (Exim 4.92)
	(envelope-from )
	id 1rm5wm-0006X5-L7; Mon, 18 Mar 2024 05:54:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694458.1083247; Mon, 18 Mar 2024 05:54:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rm5wm-0006Wy-IX; Mon, 18 Mar 2024 05:54:08 +0000
Received: by outflank-mailman (input) for mailman id 694458;
 Mon, 18 Mar 2024 05:54:07 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rm5wl-0006Ws-Cb
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 05:54:07 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on20601.outbound.protection.outlook.com
 [2a01:111:f403:2418::601])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ecfef91e-e4eb-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 06:54:04 +0100 (CET)
Received: from BN0PR03CA0046.namprd03.prod.outlook.com (2603:10b6:408:e7::21)
 by MN2PR12MB4456.namprd12.prod.outlook.com (2603:10b6:208:266::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.27; Mon, 18 Mar
 2024 05:54:01 +0000
Received: from BN3PEPF0000B072.namprd04.prod.outlook.com
 (2603:10b6:408:e7:cafe::5b) by BN0PR03CA0046.outlook.office365.com
 (2603:10b6:408:e7::21) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.26 via Frontend
 Transport; Mon, 18 Mar 2024 05:54:01 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN3PEPF0000B072.mail.protection.outlook.com (10.167.243.117) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Mon, 18 Mar 2024 05:54:00 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Mon, 18 Mar
 2024 00:54:00 -0500
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB05.amd.com
 (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Mon, 18 Mar
 2024 00:54:00 -0500
Received: from [10.65.148.173] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Mon, 18 Mar 2024 00:53:57 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ecfef91e-e4eb-11ee-a1ee-f123f15fe8a2
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=RggYjv+ObU2LeHT9s5h5cWyuKwt0gflImJ37QhfnIhqYNojWMEI+WCuHgPZOZAHznkukncKNTcer0SJEqtdwRWPTeOO9xofNEmGS/WlmwvFAXfAYRBHNIVsZc0oOJRRN6zlCcUJP3A3T2X2ZeOMTO1Ivm68ysxAhSywGI5uQUa0EOs7fj+p/FcvL7pZH8zj3V4Qb8kYm7/6IAEqHXW5wUmNgRq5/ZSHvxlqe7W/spZhJOxbrRhVqGmtoe2Oa84LYKJPqHj8OXiE3AoSpw/W5taxMvsHYiBGHPXYnXcwQYkH47WGmVjqAKkV8qjElRsupQMHjTv7/OIMdmyZSPb21pA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Ibm2YtqLQ5URCqm23h2BHb2m1bmlA49TcqsiILZjzGI=;
 b=lsPfffCZhVkbYmrh0EJwuRvIhiyLnNQZcRr3CqqOnZb4dxlXwSDL1NWznjV0VjOXt6JYDbJC8AL8ndnYmgjQlA1G7IrM9yuCAgSFStY7xbmloy75bVnLZZJkZs6aObN/om7pdD5CLRQJfyqWAb6Z5saMkenBycUC2XpWWabWFdnNdz5A+GoNnceTEUJewuvUuQn/VBhkMcyguKtF4JUf9q2Yryu6mhFvsBUkP0aQF8AGSICx8s096ruCUNZgM5oxiSJwvRtcx0K+012zaB5aMvPhvMyjdY2Ijz5vvxJSpmeZwFnE498Ps2w1IQJFOuGOkrXCbjHI/7hI1Qe3JIT3gw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=xen.org smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=Ibm2YtqLQ5URCqm23h2BHb2m1bmlA49TcqsiILZjzGI=;
 b=Eyk10lWeg5ZCumktiYUqUPn01BV704AZ4AFrpxiI6hES0BgIxmnHi72UCXF2Q5bTASuFmqGz1IOoYRZymA5pGL2mU9eKjtm3OI86rjf3NspYQ62bDMEOgvlXQC/ljy0ZnyZTVv2LQ/JgLLY3lwP6EPkU21pKgttbdtnXIH47y2o=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Message-ID: <86be78f4-cd4e-47aa-94e3-f6c7bf6b3316@amd.com>
Date: Mon, 18 Mar 2024 13:53:57 +0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] xen/arm: Set correct per-cpu cpu_core_mask
To: Julien Grall , 
CC: Stefano Stabellini , Bertrand Marquis
	, Michal Orzel , "Volodymyr
 Babchuk" , Henry Wang ,
	Juergen Gross , 
References: <20240228015822.56108-1-xin.wang2@amd.com>
 <77520838-67cb-4755-8b02-2ec8b90c7bfa@xen.org>
 <16838c64-c633-4125-9388-af02e18a89be@amd.com>
 
Content-Language: en-US
From: Henry Wang 
In-Reply-To: 
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
Received-SPF: None (SATLEXMB05.amd.com: xin.wang2@amd.com does not designate
 permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN3PEPF0000B072:EE_|MN2PR12MB4456:EE_
X-MS-Office365-Filtering-Correlation-Id: cab6fc38-aeb4-42ba-0886-08dc470fcf43
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	asWaubEVsnBGqgK71FvoOIWKIxRrM0CImlhQarMZmrWX0/DAjmeEuOlqtPZQJI+uCkIy1uGYvy006a6k53p/SQ5naVsNn5pPCbb+V42H7JG+8irmHD19Kkn1JMtqjTgTC4359/e0ABq96TLPBUF3Bg9m0pQxNutYca1foA8pyXiS9B5bbI4I0lHUTCFJ/SscRbKm2tsrTsJAvy8R3BljYP/J9Syejdvezf7SohtkEwrH1U8Ubvx5m1tFzri6dm1UYsy8Ek9mUsKFtDS/J7++WVrvkQxrTdV4wfeQc39uazVLBEt7E4VFPWb0rbMzrqAmAykhQZuq8y9e3tYQCPKZWUrqgx/Cf73YyWL1TeAsocFrIm0OuTQWvC4KkV5gSQXa8eSdVsVhwmJ92lJzeU/oiW1jD3u0pzpIok6zL9UbWYU4qa7OzHVRfo+6c+M0yImSyWrh77FVUQ8v9JtXkOA2xPJ28YoX2pfbHlCp+5XFQ0wKf0sqRG9HQ8YNVCI47YWESr421w+qQaKp0jbBiManes/O5ohR6v2s7JUeus5C29RxGuXWMPUtfnp3n2rkJw4vWgPQ2xeNBjDXvKpehI4hFoaa/i6pBwhYQ+2x1tuiq7TOomJoLap7HBILSU8/2Yyh/FnOy+Hgt62r/x6pi5dDQIFpDe3P/zU+D4082VNx6lfhilUDY++QOXxDiSF66cGmb+puRSPowj4v6z9ffPSv1eXVrJcCDisr1PwkkUBqidBqLuPeDyvOIHKdP4sgqfrO
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(1800799015)(36860700004)(376005)(82310400014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Mar 2024 05:54:00.6813
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: cab6fc38-aeb4-42ba-0886-08dc470fcf43
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN3PEPF0000B072.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB4456

Hi Julien,

On 3/15/2024 6:58 PM, Julien Grall wrote:
> On 14/03/2024 14:22, Henry Wang wrote:
>> Hi Julien,
> Hi,
>>>>   /* representing HT siblings of each logical CPU */
>>>>   DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_sibling_mask);
>>>>   /* representing HT and core siblings of each logical CPU */
>>>> @@ -89,6 +88,10 @@ static int setup_cpu_sibling_map(int cpu)
>>>>       cpumask_set_cpu(cpu, per_cpu(cpu_sibling_mask, cpu));
>>>>       cpumask_set_cpu(cpu, per_cpu(cpu_core_mask, cpu));
>>>>   +    /* Currently we assume there is no multithread. */
>>>
>>> I am not very familiar with the scheduling in Xen. Do you know 
>>> what's the consequence of not properly supporting MT? One thing I 
>>> can think of is security (I know there were plenty of security 
>>> issues with SMT).
>>
>> Unfortunately me neither, so adding George to this thread as I think 
>> he can bring us some insights on this topic from the scheduler 
>> perspective.
>
> +Juergen as he worked on co-scheduling.

Thanks.

>>
>>> Depending on the answer, I would consider to print a warning and 
>>> maybe add it in SUPPORT.MD in a separate patch.
>>
>> To be honest, as discussed in v1. I think I am quite tempted to add 
>> an ASSERT(system_cpuinfo.mpidr.mt == 0) to make sure we catch the 
>> multithread support stuff earlier. 
>
> ASSERT(...) is not the right solution. You may have user using a Xen 
> shipped by distros where this would be a NOP.
>
> We could try to hide MT completely from the scheduler. If that's too 
> difficult, then we could add use warning_add() to throw a warning (see 
> how we dealt with opt_hmp_unsafe).

Ok. Let's first see what George and Juergen will say, if MT cannot be 
hidden from scheduler for Arm, maybe we can add something like below:

if ( system_cpuinfo.mpidr.mt == 1 )
      warning_add("WARNING: MULTITHREADING HAS BEEN DETECTED ON THE 
PROCESSOR.\n"
                               "It might impact the security and 
stability of the system.\n");

Kind regards,
Henry


From xen-devel-bounces@lists.xenproject.org Mon Mar 18 06:35:11 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 06:35:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694466.1083265 (Exim 4.92)
	(envelope-from )
	id 1rm6aO-0003YB-US; Mon, 18 Mar 2024 06:35:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694466.1083265; Mon, 18 Mar 2024 06:35:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rm6aO-0003Y4-QK; Mon, 18 Mar 2024 06:35:04 +0000
Received: by outflank-mailman (input) for mailman id 694466;
 Mon, 18 Mar 2024 06:35:04 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rm6aN-0003Xy-TC
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 06:35:03 +0000
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com
 [2a00:1450:4864:20::62e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a4df4c58-e4f1-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 07:35:00 +0100 (CET)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-a467d8efe78so379019666b.3
 for ; Sun, 17 Mar 2024 23:35:00 -0700 (PDT)
Received: from ?IPV6:2003:e5:873a:400:704b:6dbb:e7c0:786e?
 (p200300e5873a0400704b6dbbe7c0786e.dip0.t-ipconnect.de.
 [2003:e5:873a:400:704b:6dbb:e7c0:786e])
 by smtp.gmail.com with ESMTPSA id
 gc14-20020a170906c8ce00b00a46ab3adea5sm2049343ejb.113.2024.03.17.23.34.59
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 17 Mar 2024 23:34:59 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a4df4c58-e4f1-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710743699; x=1711348499; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:references:cc:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=WlT4lf4QT+N7CBObrOaQfgIRmr2ZJ20Y2+aXDVEVwPc=;
        b=SXr/5gKR7ReTCRAbYPcpZQi7q9ICv7NcITnh9XLgZ3iZWprNYgudqyA9pPxzn6hqex
         bpAKlVZGPSmdOxvHoFULhgEt/cOXhJoocTp7DFbiix3oG7DC5RoFyJq2CzWKfWf1Svke
         Kd7yC1Zf4Er6qFgILaifamkH2nATv9IwFMHHyO/VNl7iBEKoXrYOfkac0FXuX5dFlPZg
         VIk7yYSZcXITjaw5XN5/wJxhoLxL8aJWDtSG1zDe849GqKWZeSCC9Xskwuw61HBBR6rR
         mGSpRT2k4cdbNg6hajc/5sYEI/dF9Y0O54lj/G28gYeBAdwB0e8sfa0Q9K+5arlKxU/3
         FWaw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710743699; x=1711348499;
        h=content-transfer-encoding:in-reply-to:from:references:cc:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=WlT4lf4QT+N7CBObrOaQfgIRmr2ZJ20Y2+aXDVEVwPc=;
        b=RJlmAnh2ULHqhf9VrFcYeJ5BNhNnjh9UGw/0X3v0BwwBf2yoABZG98ZCVTLjRZL4Qe
         5eKY21zNyd0FrrHBlAJfKpXJ18xAbfrG9CPAryflJ2l2XcvthnTpXBkZPtk0TLI+SMjz
         RmKC6HXxS1BudSTnGgayMNOdP7Pjja+iKi9l64ssyC5QsO5tVWzdmmHTRejPVVOUvzIJ
         IDLKsTUqowqXhFNtMuU6AIPwEyfDgZ0qAJxljAVjF71wmQPXdonnpauWLYYsn81MZ7g+
         s9dAicXPkm2gITrnyUxImK+zDD4RjuSaprx1PWdTzCEEuTN8q3JVVtP1XFDNnh5VQBxG
         jTFw==
X-Forwarded-Encrypted: i=1; AJvYcCUzW0V+6AfqmFdmS+VyUU30GQq0uPWOIdczQANpIqkYnI1SC0nomWGxt29WIPfFF6oiaM22Wn7UkXPhWX299N7S6Kl4QVZZhfeOaUXLE5k=
X-Gm-Message-State: AOJu0Yx7lVW+EjjfnHvYLSXH3Y60BSGZO2nL0ZSPjqYpTDijoFVPFxYD
	hmF2vpqROr1y7ZcJV7pot9F6LrJu5JWSMCvcHRixhlWNwtgoMWjO3EScQCEKfWs=
X-Google-Smtp-Source: AGHT+IEkwbfLnF7KQV7xOnq5nLI/EFewzkLUcW4Q15vzQ6NsAUhisRoX1KZkhYAfLipTOXpX6FKcOg==
X-Received: by 2002:a17:906:80c7:b0:a46:c8e0:e253 with SMTP id a7-20020a17090680c700b00a46c8e0e253mr480656ejx.52.1710743699453;
        Sun, 17 Mar 2024 23:34:59 -0700 (PDT)
Message-ID: <0b0cc755-1418-4d2b-a935-555996bf550b@suse.com>
Date: Mon, 18 Mar 2024 07:34:58 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] xen/arm: Set correct per-cpu cpu_core_mask
Content-Language: en-US
To: Julien Grall , Henry Wang ,
 xen-devel@lists.xenproject.org, george.dunlap@cloud.com
Cc: Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Henry Wang 
References: <20240228015822.56108-1-xin.wang2@amd.com>
 <77520838-67cb-4755-8b02-2ec8b90c7bfa@xen.org>
 <16838c64-c633-4125-9388-af02e18a89be@amd.com>
 
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 15.03.24 11:58, Julien Grall wrote:
> 
> 
> On 14/03/2024 14:22, Henry Wang wrote:
>> Hi Julien,
> 
> Hi,
> 
>>
>> On 3/14/2024 9:27 PM, Julien Grall wrote:
>>> Hi Henry,
>>>
>>> On 28/02/2024 01:58, Henry Wang wrote:
>>>> diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
>>>> index a84e706d77..d9ebd55d4a 100644
>>>> --- a/xen/arch/arm/smpboot.c
>>>> +++ b/xen/arch/arm/smpboot.c
>>>> @@ -66,7 +66,6 @@ static bool cpu_is_dead;
>>>>     /* ID of the PCPU we're running on */
>>>>   DEFINE_PER_CPU(unsigned int, cpu_id);
>>>> -/* XXX these seem awfully x86ish... */
>>>
>>> :). I guess at the time we didn't realize that MT was supported on Arm. It is 
>>> at least part of the spec, but as Michal pointed out it doesn't look like a 
>>> lot of processors supports it.
>>
>> Yep. Do you think changing the content of this line to something like 
>> "Although multithread is part of the Arm spec, there are not many processors 
>> support multithread and current Xen on Arm assumes there is no multithread" 
>> makes sense to you?
>>
>>>>   /* representing HT siblings of each logical CPU */
>>>>   DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_sibling_mask);
>>>>   /* representing HT and core siblings of each logical CPU */
>>>> @@ -89,6 +88,10 @@ static int setup_cpu_sibling_map(int cpu)
>>>>       cpumask_set_cpu(cpu, per_cpu(cpu_sibling_mask, cpu));
>>>>       cpumask_set_cpu(cpu, per_cpu(cpu_core_mask, cpu));
>>>>   +    /* Currently we assume there is no multithread. */
>>>
>>> I am not very familiar with the scheduling in Xen. Do you know what's the 
>>> consequence of not properly supporting MT? One thing I can think of is 
>>> security (I know there were plenty of security issues with SMT).
>>
>> Unfortunately me neither, so adding George to this thread as I think he can 
>> bring us some insights on this topic from the scheduler perspective.
> 
> +Juergen as he worked on co-scheduling.

There are four aspects regarding multithreading:

- security (basically boils down to one thread possibly being able to use
   side channel attacks for accessing other thread's data via resources in
   the core shared between the threads)

- performance (trying to spread running vcpus across as many cores as
   possible will utilize more hardware resources resulting generally in better
   performance - especially credit2 is supporting that)

- power consumption (a completely idle core will consume less power - again
   credit2 is supporting that with the correct setting)

- busy loops (cpu_relax() support)

For credit2 MT specifics see the large comment block in xen/common/sched/credit2
starting at line 636.

Note that core scheduling is currently not supported on Arm, as there are
architecture specific bits missing in the context switching logic.


Juergen


From xen-devel-bounces@lists.xenproject.org Mon Mar 18 07:15:44 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 07:15:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694473.1083273 (Exim 4.92)
	(envelope-from )
	id 1rm7DX-0000cc-T6; Mon, 18 Mar 2024 07:15:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694473.1083273; Mon, 18 Mar 2024 07:15:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rm7DX-0000cV-Px; Mon, 18 Mar 2024 07:15:31 +0000
Received: by outflank-mailman (input) for mailman id 694473;
 Mon, 18 Mar 2024 07:15:30 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rm7DT-0000cL-TR
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 07:15:30 +0000
Received: from mail.zytor.com (unknown [2607:7c80:54:3::138])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 49fa2860-e4f7-11ee-afdd-a90da7624cb6;
 Mon, 18 Mar 2024 08:15:26 +0100 (CET)
Received: from terminus.zytor.com (terminus.zytor.com
 [IPv6:2607:7c80:54:3:0:0:0:136]) (authenticated bits=0)
 by mail.zytor.com (8.17.2/8.17.1) with ESMTPSA id 42I7ETdi910464
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
 Mon, 18 Mar 2024 00:14:34 -0700
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 49fa2860-e4f7-11ee-afdd-a90da7624cb6
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 42I7ETdi910464
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com;
	s=2024031401; t=1710746075;
	bh=lOgqPli4E6y6mgNZ3XzJ8MlzC1fqsi4wvgAp64a4zdg=;
	h=From:To:Cc:Subject:Date:From;
	b=4qfo7+Bopd2+cAB5JZREDFFnwJ9EUBUQzcTriimHV5zBacAHniCvGQvo/sA6muLna
	 r4PwVGXSNtnFAarpjPSIkcS/hfYgUg4ojZl9bimUFHmnM0P9CO9rh8dpDRYahLqOvt
	 jnGim1lPI+5C7q/LXw9w5uKxwMQXRUaNszLu95FjFea3zs0mFNXuwyPH5LagxqX0vC
	 DosUI2YMVafFXw+c4aHUHb5JuMOQj2w2l2V9R0IlbFLWugYYUIdGE6Z5Vy6yC1MuaW
	 vy1Q4stBFIJ3UVxNPttVvgPU9sLEwyljSMMwcFiw0pKIcgh2pkDHDqZRXAoNS8IABG
	 Eqfo27oqDTeqA==
From: "Xin Li (Intel)" 
To: linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
        linux-arch@vger.kernel.org
Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de,
        dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com,
        jgross@suse.com, boris.ostrovsky@oracle.com, arnd@arndb.de
Subject: [PATCH v2 1/1] x86: Rename __{start,end}_init_task to __{start,end}_init_stack
Date: Mon, 18 Mar 2024 00:14:29 -0700
Message-ID: <20240318071429.910454-1-xin@zytor.com>
X-Mailer: git-send-email 2.44.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The stack of a task has been separated from the memory of a task_struct
struture for a long time on x86, as a result __{start,end}_init_task no
longer mark the start and end of the init_task structure, but its stack
only.

Rename __{start,end}_init_task to __{start,end}_init_stack.

Note other architectures are not affected because __{start,end}_init_task
are used on x86 only.

Signed-off-by: Xin Li (Intel) 
---

Change since v1:
* Revert an accident insane change, init_task to init_stack (Jürgen Groß).
---
 arch/x86/include/asm/processor.h  | 4 ++--
 arch/x86/kernel/head_64.S         | 2 +-
 arch/x86/xen/xen-head.S           | 2 +-
 include/asm-generic/vmlinux.lds.h | 6 +++---
 4 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 811548f131f4..8b3a3f3bb859 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -636,10 +636,10 @@ static __always_inline void prefetchw(const void *x)
 #define KSTK_ESP(task)		(task_pt_regs(task)->sp)
 
 #else
-extern unsigned long __end_init_task[];
+extern unsigned long __end_init_stack[];
 
 #define INIT_THREAD {							\
-	.sp	= (unsigned long)&__end_init_task -			\
+	.sp	= (unsigned long)&__end_init_stack -			\
 		  TOP_OF_KERNEL_STACK_PADDING -				\
 		  sizeof(struct pt_regs),				\
 }
diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
index d8198fbd70e5..c7babd7ebb0f 100644
--- a/arch/x86/kernel/head_64.S
+++ b/arch/x86/kernel/head_64.S
@@ -66,7 +66,7 @@ SYM_CODE_START_NOALIGN(startup_64)
 	mov	%rsi, %r15
 
 	/* Set up the stack for verify_cpu() */
-	leaq	(__end_init_task - TOP_OF_KERNEL_STACK_PADDING - PTREGS_SIZE)(%rip), %rsp
+	leaq	(__end_init_stack - TOP_OF_KERNEL_STACK_PADDING - PTREGS_SIZE)(%rip), %rsp
 
 	/* Setup GSBASE to allow stack canary access for C code */
 	movl	$MSR_GS_BASE, %ecx
diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
index 04101b984f24..43eadf03f46d 100644
--- a/arch/x86/xen/xen-head.S
+++ b/arch/x86/xen/xen-head.S
@@ -49,7 +49,7 @@ SYM_CODE_START(startup_xen)
 	ANNOTATE_NOENDBR
 	cld
 
-	leaq	(__end_init_task - TOP_OF_KERNEL_STACK_PADDING - PTREGS_SIZE)(%rip), %rsp
+	leaq	(__end_init_stack - TOP_OF_KERNEL_STACK_PADDING - PTREGS_SIZE)(%rip), %rsp
 
 	/* Set up %gs.
 	 *
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 514d3002ad8a..cdfdcca23045 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -399,13 +399,13 @@
 
 #define INIT_TASK_DATA(align)						\
 	. = ALIGN(align);						\
-	__start_init_task = .;						\
+	__start_init_stack = .;						\
 	init_thread_union = .;						\
 	init_stack = .;							\
 	KEEP(*(.data..init_task))					\
 	KEEP(*(.data..init_thread_info))				\
-	. = __start_init_task + THREAD_SIZE;				\
-	__end_init_task = .;
+	. = __start_init_stack + THREAD_SIZE;				\
+	__end_init_stack = .;
 
 #define JUMP_TABLE_DATA							\
 	. = ALIGN(8);							\

base-commit: 7e19a79344df2ed5e106091c29338962261b0290
-- 
2.44.0



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 07:23:13 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 07:23:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694478.1083284 (Exim 4.92)
	(envelope-from )
	id 1rm7Ku-0002JO-Lq; Mon, 18 Mar 2024 07:23:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694478.1083284; Mon, 18 Mar 2024 07:23:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rm7Ku-0002JH-Hk; Mon, 18 Mar 2024 07:23:08 +0000
Received: by outflank-mailman (input) for mailman id 694478;
 Mon, 18 Mar 2024 07:23:06 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rm7Ks-0002JA-MZ
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 07:23:06 +0000
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com
 [2a00:1450:4864:20::52c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5c0ed3b3-e4f8-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 08:23:04 +0100 (CET)
Received: by mail-ed1-x52c.google.com with SMTP id
 4fb4d7f45d1cf-568aa282ccdso3555713a12.3
 for ; Mon, 18 Mar 2024 00:23:04 -0700 (PDT)
Received: from ?IPV6:2003:e5:873a:400:704b:6dbb:e7c0:786e?
 (p200300e5873a0400704b6dbbe7c0786e.dip0.t-ipconnect.de.
 [2003:e5:873a:400:704b:6dbb:e7c0:786e])
 by smtp.gmail.com with ESMTPSA id
 wg8-20020a17090705c800b00a46cc48ab13sm218367ejb.62.2024.03.18.00.23.03
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 18 Mar 2024 00:23:03 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5c0ed3b3-e4f8-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710746584; x=1711351384; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:references:cc:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=j2+xmiNT0HV1PrVIMTOkvVdPBI7GhnHCBaeppqG3Ayo=;
        b=dt0rzKW6PZSNFsl0P9kZEYkMtbxXGK9wPWf0cjxYAouT7huhVOcV/tG0CuPey4EktN
         jQ6dXTtKl6Hx65VYzbl6LS05OTh8PbFuaZTda47vbz+OTLzQ6GCmlr2tOR4AU1SXYAoU
         /ZH82Az/0YqqidBtv1r3FCNhU6geKrYDBTpnrrQtmv756078a3toXodMkVQKtch7AfA3
         rAR8K9aXB/4iDvOEjSv/+opQre/1ohffTyPgtrDohfj1XHCNF/GbtZawyZ45m+LUM/0H
         xCpOVRP47XQUNhrdzAz03e6bj1r7qvXnRlANXIOqsTw0ABpfj8hLsraL7llFN9sniuLT
         XFGw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710746584; x=1711351384;
        h=content-transfer-encoding:in-reply-to:from:references:cc:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=j2+xmiNT0HV1PrVIMTOkvVdPBI7GhnHCBaeppqG3Ayo=;
        b=c/8Bgblf+H1RrVsiTXad+FRKVK+JDxurXHVYYy5337CzNP4z5uxbkWwf7cl7aPkAqw
         w78D0YgSDQ43LFXyl0x0FxO3w2tG948AvppehcMQ4DnrCr/E4dCR0p3xkfx+/SAmhmHt
         4ab+XQe/ddxrPhZsT/omvvfPngTJMhYHDs6kNrWjZYo/Caq988mrrjit5TKrvHD9o5T9
         AIM7zVgy7rFNSTvW4kQaGPRjQ5VqQpxbDQ9PHoMuhetcU1Y6G0YyJUCgVy5LGu6lEU9T
         0jTw8el5CMPzRSiUufrhgXetEM+hcV9riVlOetPTRcoLBrvwaVsxl+s+tGqkiBdZwjFN
         9nLg==
X-Forwarded-Encrypted: i=1; AJvYcCXyRSmLrOGDu4T/MLxz4q+/uGc/txrvTpnk9YBqT3lR4UMTxr2kxrzpQS8DdGhVukNBBSzA+uAyHw/5IBn5VMra1czfvNj3cZtk6Iok6nI=
X-Gm-Message-State: AOJu0Yw3F+hzepjWRWxCwHo0Lnjf+ws5mEu4hxYO3to7iDxY0oyGxnx7
	drD7fGbmcBYmhS/O95/b15x2ROEg/L7dhHE5wSAJbJNENL+R/qcPfSxinFcXbJ8=
X-Google-Smtp-Source: AGHT+IG/FvP8FIPkOAjy1Sqh3yrjW0+6MsrVrNKO/gQxWJLTWjYkr4kGMhpQK7lOhCNJSTLGPpmMag==
X-Received: by 2002:a17:907:7a93:b0:a46:74fe:904f with SMTP id mm19-20020a1709077a9300b00a4674fe904fmr8405153ejc.26.1710746583937;
        Mon, 18 Mar 2024 00:23:03 -0700 (PDT)
Message-ID: 
Date: Mon, 18 Mar 2024 08:23:03 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/1] x86: Rename __{start,end}_init_task to
 __{start,end}_init_stack
Content-Language: en-US
To: "Xin Li (Intel)" , linux-kernel@vger.kernel.org,
 xen-devel@lists.xenproject.org, linux-arch@vger.kernel.org
Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de,
 dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com,
 boris.ostrovsky@oracle.com, arnd@arndb.de
References: <20240318071429.910454-1-xin@zytor.com>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
In-Reply-To: <20240318071429.910454-1-xin@zytor.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 18.03.24 08:14, Xin Li (Intel) wrote:
> The stack of a task has been separated from the memory of a task_struct
> struture for a long time on x86, as a result __{start,end}_init_task no
> longer mark the start and end of the init_task structure, but its stack
> only.
> 
> Rename __{start,end}_init_task to __{start,end}_init_stack.
> 
> Note other architectures are not affected because __{start,end}_init_task
> are used on x86 only.
> 
> Signed-off-by: Xin Li (Intel) 

Reviewed-by: Juergen Gross 


Juergen



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 07:44:46 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 07:44:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694500.1083294 (Exim 4.92)
	(envelope-from )
	id 1rm7fm-0005Q4-A7; Mon, 18 Mar 2024 07:44:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694500.1083294; Mon, 18 Mar 2024 07:44:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rm7fm-0005Px-7M; Mon, 18 Mar 2024 07:44:42 +0000
Received: by outflank-mailman (input) for mailman id 694500;
 Mon, 18 Mar 2024 07:44:41 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rm7fl-0005Pn-0b; Mon, 18 Mar 2024 07:44:41 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rm7fk-0003HX-P5; Mon, 18 Mar 2024 07:44:40 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rm7fk-0001Aj-Eh; Mon, 18 Mar 2024 07:44:40 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rm7fk-0007s7-E9; Mon, 18 Mar 2024 07:44:40 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=k4D94Yy5Qlj0qLTwz+qR6s9B39v3B7agFCHcXRFANcI=; b=3JhHD/rgfDu7dYiz5ktpr1NvNY
	CfUJ5iARJidFUsxwnNIDjfWcdQAirUygYfBnSBmWZB9U8Wo9SIaK4M82NDAfBiIo+Woo13Cr+MKNv
	JDmcfFRfZ++6BBUxHLipgrcIq5xVf1vNrJd9qIB/qrjw/CLHRUY3iudc6mw0N1jz2SIY=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 185069: tolerable FAIL - PUSHED
X-Osstest-Failures:
    linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    linux=906a93befec826475ab3d4facacc57a0b0a002a5
X-Osstest-Versions-That:
    linux=741e9d668aa50c91e4f681511ce0e408d55dd7ce
From: osstest service owner 
Date: Mon, 18 Mar 2024 07:44:40 +0000

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

Failures :-/ but no regressions.

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

version targeted for testing:
 linux                906a93befec826475ab3d4facacc57a0b0a002a5
baseline version:
 linux                741e9d668aa50c91e4f681511ce0e408d55dd7ce

Last test of basis   185062  2024-03-17 04:58:47 Z    1 days
Testing same since   185069  2024-03-17 21:12:38 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  "Ricardo B. Marliere" 
  Andy Shevchenko 
  Ard Biesheuvel 
  Ben Wolsieffer 
  Bernhard Seibold 
  Brenton Simpson 
  Bryant Mairs 
  Christophe JAILLET 
  Chunyan Zhang 
  Colin Ian King 
  Conor Dooley 
  Dharma Balasubiramani 
  Dmitry Torokhov 
  Dominik Brodowski 
  Duje Mihanović 
  Florian Fainelli 
  Frederic Weisbecker 
  Geert Uytterhoeven 
  Guenter Roeck 
  Heiner Kallweit 
  Ingo Molnar 
  Jeff LaBundy 
  Jernej Skrabec 
  Jerry Hoemann 
  Ji Sheng Teoh 
  Karel Balej 
  Kathiravan Thirumoorthy 
  Krzysztof Kozlowski 
  Kunwu Chan 
  Ley Foon Tan 
  Linus Torvalds 
  Luca Ceresoli 
  Luca Weiss 
  Markuss Broks 
  Matt Scialabba 
  Minh Le 
  Neil Armstrong 
  Ricardo B. Marliere 
  Rob Herring 
  Ruan Jinjie 
  Sandipan Das 
  Sia Jee Heng 
  Stanislav Jakubek 
  Thomas Gleixner 
  Varshini Rajendran 
  Wim Van Sebroeck 
  Xingyu Wu 
  Yang Li 
  Yang Xiwen 

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-freebsd11-amd64                             pass    
 test-amd64-amd64-freebsd12-amd64                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-libvirt-qcow2                               pass    
 test-armhf-armhf-libvirt-qcow2                               pass    
 test-amd64-amd64-libvirt-raw                                 pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-amd64-xl-vhd                                      pass    
 test-arm64-arm64-xl-vhd                                      pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

Explanation of these 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 :

hint: The 'hooks/update' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
hint: The 'hooks/post-receive' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
hint: The 'hooks/post-update' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
To xenbits.xen.org:/home/xen/git/linux-pvops.git
   741e9d668aa5..906a93befec8  906a93befec826475ab3d4facacc57a0b0a002a5 -> tested/linux-linus


From xen-devel-bounces@lists.xenproject.org Mon Mar 18 07:46:17 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 07:46:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694505.1083304 (Exim 4.92)
	(envelope-from )
	id 1rm7hH-000606-Pi; Mon, 18 Mar 2024 07:46:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694505.1083304; Mon, 18 Mar 2024 07:46:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rm7hH-0005zz-Lu; Mon, 18 Mar 2024 07:46:15 +0000
Received: by outflank-mailman (input) for mailman id 694505;
 Mon, 18 Mar 2024 07:46:14 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rm7hG-0005zY-KU
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 07:46:14 +0000
Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com
 [2a00:1450:4864:20::22f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9727276a-e4fb-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 08:46:12 +0100 (CET)
Received: by mail-lj1-x22f.google.com with SMTP id
 38308e7fff4ca-2d41d1bedc9so67927511fa.3
 for ; Mon, 18 Mar 2024 00:46:12 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 h12-20020a170906260c00b00a457a55b814sm4556217ejc.73.2024.03.18.00.46.10
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 18 Mar 2024 00:46:11 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9727276a-e4fb-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710747971; x=1711352771; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=6UQRtBhWJpPkCEMPCrBPLIFgvcaNsTRJRzsowCFQ7Xo=;
        b=J2Qvm9Hf4pk4i7JhCBOlYepUozsBT2IeA/MiBd3vBWuOE+76YnaeqUHXgKRKzuexLc
         3gkwpBaQ2OWDrgeNr4l/ikCVmNVC9XrohBQOqyn2w9eg3C4mWSwf8gvmkSrzjsOJFEDE
         CGzK+3cN7vl5yszP3Vt9lrnRiJF6qjLH90kC5RilDm0YWKfzo5uU3b1mDcSEmFqeSNS6
         EWSPcn/ttrrU1i6VntrmQfILVmXBQYIxyIqsby09XYFm0U6BbJU47G+vVbDDStWtmwuv
         0wfFDrR7gJ/wCcypQjepuAyC5liFgZszgrMhIPlbCkFFRytBYuuxLZ+qaHnJAlLcymZJ
         fj+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710747971; x=1711352771;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=6UQRtBhWJpPkCEMPCrBPLIFgvcaNsTRJRzsowCFQ7Xo=;
        b=LEMF8o+i6y5QF0FDAQSfmZqKkYm30GnUmYfoBfSc1iImht+te0qRuNAaiSROPkWJky
         VZMwZhCsJS6VatTFyJyJIcQEdwd6xFbObE1BlNW3hnJn1hRcdZVd4AU0IJ50M0JtkyfA
         z5OXms3NY90AIMBdbclWgNqvMWggu/Z/kYLZ/JChZCuc1WgS8dhX8nr97ahpu5ns0O9D
         aJR6XsVMeU3FIq/etn064Vr1WvyYiToYZ+YZLeujpUKfKKtfElsgL2mpS7EzsZ/f0K/k
         OOKuxPafwAGvlUOT2A1WgWouxE7+/8J1hmTOtvfV0xepuR/iRHnpA1LUEu4LPtz/AB51
         WZPQ==
X-Forwarded-Encrypted: i=1; AJvYcCUGNqhBjmomp5W9D+qKcMoOd4PbKG/8saYJTK7j+hYj+kyxxqNZgPITMKJqdi+wc+UUrcu9VL0lJQVMj+SSTXbyh9rgArrAgDdu6mmNHQg=
X-Gm-Message-State: AOJu0Yx3Qqa2dbeiBultIWcN6YkKgkh2VCd4X/7p+MULB1xS1m9FxBzz
	Ltr6yTMV0FpYIRyFxkHJveeTJelnnaCUBqlQvICWm+2syOAb3ucQSw1WpobXLA==
X-Google-Smtp-Source: AGHT+IH1QsWXurGWiJgWIx8XoD6rxDs1TBeUMTMLENuR9dVZHY3Ew4EEz47MRWCZ8bIuoOFHH7KTQQ==
X-Received: by 2002:a19:2d5b:0:b0:513:a766:4672 with SMTP id t27-20020a192d5b000000b00513a7664672mr4263912lft.4.1710747971554;
        Mon, 18 Mar 2024 00:46:11 -0700 (PDT)
Message-ID: <5128255f-fe52-4425-b168-34946c0c901e@suse.com>
Date: Mon, 18 Mar 2024 08:46:12 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] do_multicall and MISRA Rule 8.3
Content-Language: en-US
To: George Dunlap 
Cc: Julien Grall , Stefano Stabellini
 , federico.serafini@bugseng.com,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Bertrand Marquis , xen-devel@lists.xenproject.org,
 michal.orzel@amd.com
References: 
 <5a8f90d6-6502-4d93-9fd7-45fea0ede24a@suse.com>
 
 
 
 
 
 
 <63891474-1dc4-4c86-aaf4-cc4d4c53a0ae@suse.com>
 
 
 <3f27abc3-9809-4637-a29c-8aeafcd29ade@xen.org>
 <7109ef7e-040c-4d11-ba4b-d898ed2530ff@suse.com>
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 15.03.2024 15:45, George Dunlap wrote:
> On Fri, Mar 15, 2024 at 2:13 PM Jan Beulich  wrote:
>> On 15.03.2024 14:55, Julien Grall wrote:
>>> On 15/03/2024 13:24, Jan Beulich wrote:
>>>> On 15.03.2024 13:17, George Dunlap wrote:
>>>>> On Fri, Mar 15, 2024 at 11:57 AM Jan Beulich  wrote:
>>>>>>> It sounds like Andy and Stefano feel like this is a situation where "a
>>>>>>> fixed width quantity is meant"; absent any further guidance from the
>>>>>>> CODING_STYLE about when fixed widths should or should not be used, I
>>>>>>> don't think this change would be a violation of CODING_STYLE.
> [snip]
>>>>> Other than "it's in CODING_STYLE", and "it's not really necessary
>>>>> because it's ensured in the assembly code", you haven't advanced a
>>>>> single reason why "uint32_t" is problematic.
>>>>
>>>> And it isn't, I never said it would be. But if we set rules for
>>>> ourselves, why would we take the first opportunity to not respect them?
>>>
>>> I am a bit confused. Reading through the thread you seem to agree that
>>> the written rules are respected here. So what rules are you talking about?
>>
>> What was proposed is use of a fixed width type where according to my
>> reading ./CODING_STYLE says it shouldn't be used.
> 
> This conversation is starting to get frustrating.

Same here.

>  That's simply not
> what it says, and I pointed that out just a few messages ago.
> 
> To reiterate:The text says fixed-width types are OK when a fixed-width
> quantity is "meant"; and that in this case, Stefano and Andy "mean" to
> use a fixed-width quantity.  The implied subtext of that sentence
> could be, "Don't use fixed width types unless there's a good reason to
> use a fixed width", and both Andy and Stefano think there's a good
> reason.  This argument you haven't really addressed at all, except
> with a specious "slippery slope" argument meant to nullify the
> exception; and now you attempt to simply ignore.
> 
> I venture to assert that for most people, the rules are a means to an
> end: That end being code which is correct, robust, fast, easy to
> write, maintain, debug, and review patches for.  What I agreed to,
> when I accepted this patch, was that *in general* we would avoid using
> fixed-width types; but that there were cases where doing so made
> sense.  Some of those were discussed in the thread above.
> 
> Andy and Stefano have already put forward reasons why they think a
> fixed-width type would be better here, which are related to "end
> goals": namely, more robust and easy to maintain code.  When I asked
> what "end goals" would be negatively impacted by using a fixed-width
> type, you explicitly said that there were none!  That the *only*
> reason you're continuing to argue is that we have a document somewhere
> that says we should -- a document which explicitly acknowledges that
> there will be exceptions!

The named reasons simply aren't convincing to me, at all. There's no
loss towards the "end goals" when "unsigned int" is used instead of
"uint32_t". Plus I recall Andrew putting under question use of
"unsigned int" for various hypercall parameter declarations, indicating
his belief that "unsigned long" ought to be used. That's, to me, quite
the opposite of using fixed-width types here, as there's no uniformly
correct fixed-width type to use in that case.

So to me, besides there not having been technical arguments towards
the need to use fixed width types here, there's actually added
confusion about what's actually wanted. Imo if we started using fixed-
width types for hypercall handler parameter declarations, (almost?) all
non-handle ones would likely want to be converted. Consistency, after
all, is part of the "easy to maintain code" goal. Plus without
consistency how would one determine when to use what kind of types.

Bottom line: My take is that here we're discussing a matter of taste
(preferring fixed width types) vs a matter of a supposedly agreed upon
rule (preferring to avoid them). Hence my "there not having been
technical arguments". I therefore view your accuse as simply unfair.

> The ideal response would have been to lay out a reasonably
> comprehensive set of criteria for when to use basic types, when to use
> fixed-width types, and how each criteria advanced the end goals of a
> better codebase.  A sufficient response would have been to lay out
> reasons why "better codebase", in this instance, tilts towards using a
> basic type rather than a fixed-width type.

The main use of fixed width types, to me, is in interface structure
definitions - between Xen and hardware / firmware, or in hypercall
structures. I'm afraid I have a hard time seeing good uses outside of
that. Even in inline assembly, types of variables used for inputs or
outputs don't strictly need to be fixed-width; I can somewhat accept
their use there for documentation purposes.

> Saying "That's what the rules say", without motivating it by
> explaining how it connects to a better codebase, is just not a helpful
> response; and making that argument after it's been pointed out that
> that is *not* what the rules say is even worse.

Well, as above, I view this as unfair as well. The rule's there. It
should be followed. If there really were downsides to following it,
the rule should be amended or dropped. If it was dropped, we'd end
up where we were before: People randomly using fixed width types even
in places we agree they're not suitable for use. And there being no
real handle in reviews to ask for them to change.

In this context, may I remind you that I'm doing a lot more reviews
than you. Having been accused of (and in various cases also guilty of)
bike shedding, it is quite helpful when one can back change requests
by references to (more or less) clearly spelled out rules. If too much
room for interpretation remains (and if there's disagreement about
interpretation), what's written down needs tightening imo. Hence why a
goal of mine has been to get ./CODING_STYLE into less ambiguous shape.
With rather little success, sadly.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Mar 18 07:54:10 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 07:54:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694509.1083314 (Exim 4.92)
	(envelope-from )
	id 1rm7os-0007nR-HE; Mon, 18 Mar 2024 07:54:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694509.1083314; Mon, 18 Mar 2024 07:54:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rm7os-0007nK-E2; Mon, 18 Mar 2024 07:54:06 +0000
Received: by outflank-mailman (input) for mailman id 694509;
 Mon, 18 Mar 2024 07:54:04 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rm7oq-0007nE-RY
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 07:54:04 +0000
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com
 [2a00:1450:4864:20::62a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id afad461b-e4fc-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 08:54:02 +0100 (CET)
Received: by mail-ej1-x62a.google.com with SMTP id
 a640c23a62f3a-a4675aaa2e8so452128366b.0
 for ; Mon, 18 Mar 2024 00:54:02 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 js22-20020a170906ca9600b00a46b8cd9b51sm1226767ejb.185.2024.03.18.00.54.01
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 18 Mar 2024 00:54:02 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: afad461b-e4fc-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710748442; x=1711353242; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=JtSNiJ5JxZs/szM2xlAaB3/oeh0bAZWDXhtNPyZ1dq0=;
        b=Y9+rhZ92m+KdfhiUL0AZilSf7lwGpzEqN6wtrSRTLBCeFqofVGnb7Xx55QC1o/QHfH
         V4peBI1jl+SkJyR0hlN7rRDtCT9B16VhYn1w57B5ZYJ7OSOM1a9YLh1e9GAf9iwHHsGh
         eJiFd53a3eZlAMVGsctvV7Aqjye4+m45GeT6TsM956sY6Hyq6b4hA7nKyuaJU6L8D9S6
         2TOsEb0cF70S9rEHA/zP9oFq/bp3e4jRO86H6QEvNHcaJZpqzfpiEHthkKV1IxsANEJA
         Y8+6bxRfoaJ30BqcNzKfTkM1w+wdat2jDsvKTE2PLZ4INiHsurwsWzKiF3iTh93GoBS0
         L9eg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710748442; x=1711353242;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=JtSNiJ5JxZs/szM2xlAaB3/oeh0bAZWDXhtNPyZ1dq0=;
        b=PN4FrkYpXQfbIXlU5HZYahlZnzOabCVJL4GlcQNQJTt05gCr5vt8fHnMK7MK1K10qM
         UYsGj8S9LICoDxRSFQmxhqNZkmvTW9ZKaHoarAizDZm3dMhxPlpCJ0pgrgijjsRv5pl6
         cDB1ulHWBm3U+ARQMX6HAqGC8fqOzvQ3W4QWQGrJwSJBB3mJv6AAv23mzddKKLFhfOUK
         KrOP6au2uqo3vQRyVshqUfZCLh3FjKQ9I7jxgNCw98fwX7t5cPtIgQfIJJ4ggDdB+n3Y
         jZVgdpmUbDyOqKuDRUVUBET4BYsH47ir/0sgiDGfKzriGGz/einj2DYU59hbE/TtpZsX
         dDRA==
X-Forwarded-Encrypted: i=1; AJvYcCWgh2iFerdVERZYc0B9T6AKIC1AeLnWmgPxTiZ8SS73KwTGYGew641RQLuEvP9Ki7F3RWz6B9W98DReRP1BUHshUP8eP/FJGv+sZrUbtyc=
X-Gm-Message-State: AOJu0Yz70n9u6Y56k0eSK3whffL26VpgeL3j/cfyej/p0zpXYRcuWVKJ
	3uMox2ckoDHthxmg5MjBFRiqWHilPOJHFVAQoBIH+GSrxCErEE/s2/iu04IkLg==
X-Google-Smtp-Source: AGHT+IEchGSfqvlM0BpIeOtls7X44UfwIfZDBarIntrDZP6eGDoS2U3Dv/24fiphDw+7/qtsaXh/lQ==
X-Received: by 2002:a17:906:3586:b0:a46:c386:bfb0 with SMTP id o6-20020a170906358600b00a46c386bfb0mr826967ejb.4.1710748442255;
        Mon, 18 Mar 2024 00:54:02 -0700 (PDT)
Message-ID: <9ec42fc6-efc3-499b-b066-e582563cfc9c@suse.com>
Date: Mon, 18 Mar 2024 08:54:03 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 02/20] xen/riscv: disable unnecessary configs
Content-Language: en-US
To: Oleksii Kurochko 
Cc: Doug Goldstein ,
 Stefano Stabellini ,
 Alistair Francis ,
 Bob Eshleman , Connor Davis
 , xen-devel@lists.xenproject.org
References: 
 <5a1b905601db481a1a625dafbbf9b28dbe12876c.1710517542.git.oleksii.kurochko@gmail.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <5a1b905601db481a1a625dafbbf9b28dbe12876c.1710517542.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 15.03.2024 19:05, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/configs/tiny64_defconfig
> +++ b/xen/arch/riscv/configs/tiny64_defconfig
> @@ -7,6 +7,23 @@
>  # CONFIG_GRANT_TABLE is not set
>  # CONFIG_SPECULATIVE_HARDEN_ARRAY is not set
>  # CONFIG_MEM_ACCESS is not set
> +# CONFIG_ARGO is not set
> +# CONFIG_HYPFS_CONFIG is not set

What exactly is wrong with permitting this?

> +# CONFIG_CORE_PARKING is not set

At the example of this: It cannot be enabled by a user (or randconfig),
it needs to be selected by an arch. Which RISC-V doesn't. Hence why
specify (and not really override) the value here? This may apply to
others as well, at the very least ...

> +# CONFIG_DEBUG_TRACE is not set
> +# CONFIG_IOREQ_SERVER is not set
> +# CONFIG_CRASH_DEBUG is not setz
> +# CONFIG_KEXEC is not set
> +# CONFIG_LIVEPATCH is not set
> +# CONFIG_NUMA is not set
> +# CONFIG_PERF_COUNTERS is not set
> +# CONFIG_HAS_PMAP is not set

... anything CONFIG_HAS_*.

In summary - please limit overrides to what is minimally necessary.

Jan

> +# CONFIG_TRACEBUFFER is not set
> +# CONFIG_XENOPROF is not set
> +# CONFIG_COMPAT is not set
> +# CONFIG_COVERAGE is not set
> +# CONFIG_UBSAN is not set
> +# CONFIG_NEEDS_LIBELF is not set
>  
>  CONFIG_RISCV_64=y
>  CONFIG_DEBUG=y



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 08:04:51 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 08:04:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694516.1083324 (Exim 4.92)
	(envelope-from )
	id 1rm7z7-0001mP-S9; Mon, 18 Mar 2024 08:04:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694516.1083324; Mon, 18 Mar 2024 08:04:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rm7z7-0001mI-P3; Mon, 18 Mar 2024 08:04:41 +0000
Received: by outflank-mailman (input) for mailman id 694516;
 Mon, 18 Mar 2024 08:04:40 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rm7z6-0001mC-Lt
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 08:04:40 +0000
Received: from mail135-12.atl141.mandrillapp.com
 (mail135-12.atl141.mandrillapp.com [198.2.135.12])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2a957716-e4fe-11ee-afdd-a90da7624cb6;
 Mon, 18 Mar 2024 09:04:39 +0100 (CET)
Received: from pmta14.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1])
 by mail135-12.atl141.mandrillapp.com (Mailchimp) with ESMTP id
 4TynSh0QWMz705b6B
 for ; Mon, 18 Mar 2024 08:04:36 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 16831b18532c40069ca102c4ce20b37a; Mon, 18 Mar 2024 08:04:35 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2a957716-e4fe-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1710749076; x=1711009576;
	bh=gJsE7eiED6CpC81of9blFJB7sBvJO4jKm0WVYh5nYeY=;
	h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=gkQOenfcVZDinNa7qTZKgEmsHKDYlnjctQJpptwlVAd+lvyCaTHYmZyGskMGjh6ti
	 pyvhUM9H1oTGC/OpUp5jKSx/xymsLDlLgJmaD3ldtC3Ln2cd90Ue+MsuyhDawupjNM
	 VKFHFfl10e9Pc9CTlfh2bkBV4cc3DwhjdGbm2oXU9/meJkOaJQlA5lz22/jOwbx9bb
	 mGKgsH2CkFTZ/PU+j1zrP27uMvEX0Q0Qb/h93JIl4xbAhxIpqlv4CqkzX7Go7x72cP
	 BF1PzyqwMS54r992w+VxsYBJWjNlYAqZS5Y+VgmPA2c2WEM+0KYWqtppYogSYRD36L
	 JFRJ6vKRkUVWg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1710749076; x=1711009576; i=vaishali.thakkar@vates.tech;
	bh=gJsE7eiED6CpC81of9blFJB7sBvJO4jKm0WVYh5nYeY=;
	h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=iKsV38YB6fadT/f87JsFd254Y2u/TFHt9bn95S/nr9pDcJd3Ag6Ozh7GlDTsups5i
	 6Tm6149cPUcLZRqAWWqun/bM+RudB+kZqs01utqFNt7IwqD09H0ZPzhAsbVuaoGZnE
	 ZG5rKL5y4EpZ4y8Z4nUHKZyds2NG/uSVzJpW6JEzZpgz9gPE91JlPGOF7RaE1untet
	 +gax0AW3OFqJWs8zGhQEbTHc3+HNWtXkpCsvHxIWw5LJ+Ty9SvSJbsHG9JREyJ5D1+
	 NIaQQ4TsdAHIPaZbkIu6xTD1l7HVSMsFNP3UgY3rTgNt/HwGsxZYuvsPBHrI4bOHZ7
	 fhS9ftpNKBYXg==
From: Vaishali Thakkar 
Subject: =?utf-8?Q?Re:=20[PATCH=20v3=202/3]=20x86/svm:=20Drop=20the=20suffix=20=5Fguest=20from=20vmcb=20bit?=
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1710749074745
Message-Id: 
To: Jan Beulich 
Cc: andrew.cooper3@citrix.com, roger.pau@citrix.com, wl@xen.org, xen-devel@lists.xenproject.org
References:  <88d5a0ce6745428120ebc37369d3d75358d5c582.1710347950.git.vaishali.thakkar@vates.tech> <3f8af14a-391b-46db-99cb-d7cafe126cfd@suse.com>
In-Reply-To: <3f8af14a-391b-46db-99cb-d7cafe126cfd@suse.com>
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.16831b18532c40069ca102c4ce20b37a?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20240318:md
Date: Mon, 18 Mar 2024 08:04:35 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

On 3/14/24 17:04, Jan Beulich wrote:
> On 13.03.2024 17:41, Vaishali Thakkar wrote:
>> The suffix _guest is redundant for asid bit. Drop it
>> to avoid adding extra code volume.
>>
>> While we're here, replace 0/1 with false/true and use
>> VMCB accessors instead of open coding.
>>
>> Suggested-by: Andrew Cooper 
>> Signed-off-by: Vaishali Thakkar 
> 
> Reviewed-by: Jan Beulich 
> with ...
> 
>> --- a/xen/arch/x86/hvm/svm/asid.c
>> +++ b/xen/arch/x86/hvm/svm/asid.c
>> @@ -37,14 +37,14 @@ void svm_asid_handle_vmrun(void)
>>       /* ASID 0 indicates that ASIDs are disabled. */
>>       if ( p_asid->asid == 0 )
>>       {
>> -        vmcb_set_guest_asid(vmcb, 1);
>> +        vmcb_set_asid(vmcb,true);
> 
> ... the blank put back that was lost here (can be done while committing).

Thanks

> Jan


From xen-devel-bounces@lists.xenproject.org Mon Mar 18 08:07:04 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 08:07:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694519.1083334 (Exim 4.92)
	(envelope-from )
	id 1rm81O-0002J0-9n; Mon, 18 Mar 2024 08:07:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694519.1083334; Mon, 18 Mar 2024 08:07:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rm81O-0002It-6f; Mon, 18 Mar 2024 08:07:02 +0000
Received: by outflank-mailman (input) for mailman id 694519;
 Mon, 18 Mar 2024 08:07:00 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rm81M-0002IR-G7
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 08:07:00 +0000
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com
 [2a00:1450:4864:20::532])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7e35deba-e4fe-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 09:06:58 +0100 (CET)
Received: by mail-ed1-x532.google.com with SMTP id
 4fb4d7f45d1cf-5684ea117a3so5804650a12.0
 for ; Mon, 18 Mar 2024 01:06:58 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 fi5-20020a056402550500b00568b0dd377csm3173025edb.93.2024.03.18.01.06.57
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 18 Mar 2024 01:06:58 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7e35deba-e4fe-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710749218; x=1711354018; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=CPdFLP3nypU5TLvl4GAV8rsWsXN3ZJoQU/8TqZF7EHQ=;
        b=EkEHjmR+7pCqzyso2sYFeY/Skk6+lUVf7YJdHOx8q+CX7GWkzUui7TwZrRJTsOINyo
         6z9JaVsP1hzsjbTU/EvlWHPggRNjBntDAcmGvaJvmt2x7Hk2CBtTdUvZSS4ViJ0ywnvd
         kXThqcAs5pQTda3l23tOoYfgutu62wfdkspmnBInDrCsUe+dZtL/F6oNlHMP/nJQYH7C
         N+CQZn0qpshLG7pUm9deKtcpM2RrG1jVNxE21NA1QufpBroZbZhOkTrxiJrGJOVgIyOY
         e6Q17SB4rlO92JAptc42Pbxeuik1X3y7w6IQctcfAlWHwZjvzt0ho1Zr8vq0+NxiHHbq
         c5FQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710749218; x=1711354018;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=CPdFLP3nypU5TLvl4GAV8rsWsXN3ZJoQU/8TqZF7EHQ=;
        b=vxwauRD7FiXtQDLhvl1TWSrL6GdQsmjCLxDdpYkyvqukzRXc0cXJxEt/cdQrMd05+6
         GyhN9wwCwXFp8oHy+mmRMY7p9XF9XAlgfeSl3Qw5to2Bsvy5q+LzWrATiZhwsFSuAdy8
         d050K+h9lphKlYiMzTbq61o81GvVSSo+t99oUIIhCfC5e4sTUF3cEIwhyypgx7tLdJ8m
         UG9x5c0SRdcfo8hkiRtPP0R39uRoaVq0zqRnXHhPkwKSA/9AXUMxbTe7/7trB+BKlQlI
         Mit+AF2hVgwPG63esU7m1J87v69HpPMd3pe6rdVSXrb3BaPe+JGrX4ULkHgO3NukKAhm
         vJPQ==
X-Forwarded-Encrypted: i=1; AJvYcCVVfpQNyijFCkB9URtPpwxFHM4tOhRLuswfklE72S1J7SkVLkz2nOMWBmPXI7TtRPztZCgpr1PTCiVp0zQHFfL3/Lt+tqh28E8C0WLPEGA=
X-Gm-Message-State: AOJu0Yyx2iGWdOG7ET9HFE0qZHd9WDZ4rLOpp/mRdPni/J1O3z857GR1
	1xotPd0of0ZOBXOC36v4pRErz6kCGNHdbTgB1cnmuOfZJ0xq6t5K1Z8VnkO86g==
X-Google-Smtp-Source: AGHT+IGS2fO7Hs7s7g3y7RICx61TlyFIuiVH+p68f3kGtzDFSo4D7w2BUs9+NAm/ExobFCecpIZZeA==
X-Received: by 2002:a05:6402:1f82:b0:567:3ed0:47ec with SMTP id c2-20020a0564021f8200b005673ed047ecmr9817566edc.23.1710749218292;
        Mon, 18 Mar 2024 01:06:58 -0700 (PDT)
Message-ID: <0513e505-5444-4a9f-9a77-ec9f359ddf27@suse.com>
Date: Mon, 18 Mar 2024 09:06:59 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH v3 03/16] misra: add deviations for direct inclusion
 guards
To: Stefano Stabellini 
Cc: consulting@bugseng.com, Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Wei Liu , Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org, Simone Ballarin 
References: 
 <1fdfec12fd2207c294f50d01d8ec32f890b915d7.1710145041.git.simone.ballarin@bugseng.com>
 
 <6472eb42-157a-4d6e-b5bb-daa74fbbd97b@bugseng.com>
 
 <3e4bb597-3624-418e-93d0-b95042fd27a7@bugseng.com>
 
 <077c0373-6eec-4403-b31e-574c8e8ae067@suse.com>
 
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 16.03.2024 01:43, Stefano Stabellini wrote:
> On Fri, 15 Mar 2024, Jan Beulich wrote:
>> On 14.03.2024 23:59, Stefano Stabellini wrote:
>>> On Mon, 11 Mar 2024, Simone Ballarin wrote:
>>>> On 11/03/24 14:56, Jan Beulich wrote:
>>>>> On 11.03.2024 13:00, Simone Ballarin wrote:
>>>>>> On 11/03/24 11:08, Jan Beulich wrote:
>>>>>>> On 11.03.2024 09:59, Simone Ballarin wrote:
>>>>>>>> --- a/xen/arch/arm/include/asm/hypercall.h
>>>>>>>> +++ b/xen/arch/arm/include/asm/hypercall.h
>>>>>>>> @@ -1,3 +1,4 @@
>>>>>>>> +/* SAF-5-safe direct inclusion guard before */
>>>>>>>>    #ifndef __XEN_HYPERCALL_H__
>>>>>>>>    #error "asm/hypercall.h should not be included directly - include
>>>>>>>> xen/hypercall.h instead"
>>>>>>>>    #endif
>>>>>>>> --- a/xen/arch/x86/include/asm/hypercall.h
>>>>>>>> +++ b/xen/arch/x86/include/asm/hypercall.h
>>>>>>>> @@ -2,6 +2,7 @@
>>>>>>>>     * asm-x86/hypercall.h
>>>>>>>>     */
>>>>>>>>    +/* SAF-5-safe direct inclusion guard before */
>>>>>>>>    #ifndef __XEN_HYPERCALL_H__
>>>>>>>>    #error "asm/hypercall.h should not be included directly - include
>>>>>>>> xen/hypercall.h instead"
>>>>>>>>    #endif
>>>>>>>
>>>>>>> Iirc it was said that this way checking for correct guards is suppressed
>>>>>>> altogether in Eclair, which is not what we want. Can you clarify this,
>>>>>>> please?
>>>>>>>
>>>>>>
>>>>>> My first change was moving this check inside the guard.
>>>>>> You commented my patch saying that this would be an error because someone
>>>>>> can
>>>>>> include it directly if it has already been included indirectly.
>>>>>> I replied telling that this was the case also before the change.
>>>>>> You agreed with me, and we decided that the correct thing would be fixing
>>>>>> the
>>>>>> check and not apply my temporary change to address the finding.
>>>>>>
>>>>>> Considering that the code should be amended, a SAF deviation seems to me
>>>>>> the most appropriate way for suppressing these findings.
>>>>>
>>>>> Since I don't feel your reply addresses my question, asking differently:
>>>>> With
>>>>> your change in place, will failure to have proper guards (later) in these
>>>>> headers still be reported by Eclair?
>>>>
>>>> No, if you put something between the check and the guard,
>>>> no violation will be reported.
>>>
>>> From this email exchange I cannot under if Jan is OK with this patch or
>>> not.
>>
>> Whether I'm okay(ish) with the patch here depends on our position towards
>> the lost checking in Eclair mentioned above. To me it still looks relevant
>> that checking for a guard occurs, even if that isn't first in a file for
>> some specific reason.
> 
> More checking is better than less checking, but if we cannot find a
> simple and actionable way forward on this violation, deviating it is
> still a big improvement because it allows us to enable the ECLAIR Dir
> 4.10 checks in xen.git overall (which again goes back to more checking
> is better than less checking). 

You have a point here. I think though that at the very least the lost
checking opportunity wants calling out quite explicitly.

> Do you have a simple alternative suggestion? If not, this is still an
> improvement.

I don't know the inner workings of Eclair. Without that I'm afraid I'm not
in a position to make alternative suggestions.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Mar 18 08:15:40 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 08:15:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694523.1083344 (Exim 4.92)
	(envelope-from )
	id 1rm89e-0004Hn-7h; Mon, 18 Mar 2024 08:15:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694523.1083344; Mon, 18 Mar 2024 08:15:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rm89e-0004Hg-43; Mon, 18 Mar 2024 08:15:34 +0000
Received: by outflank-mailman (input) for mailman id 694523;
 Mon, 18 Mar 2024 08:15:33 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rm89d-0004Ha-8V
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 08:15:33 +0000
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com
 [2a00:1450:4864:20::633])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id afb973c1-e4ff-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 09:15:31 +0100 (CET)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-a3ddc13bbb3so924116766b.0
 for ; Mon, 18 Mar 2024 01:15:31 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 e9-20020a170906c00900b00a46ce8f5e11sm106095ejz.152.2024.03.18.01.15.30
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 18 Mar 2024 01:15:30 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: afb973c1-e4ff-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710749731; x=1711354531; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=wF1t1OePzE2zuBwKuw2iztC2ZI7yiT09I7BHKf/0jJ4=;
        b=UqSZOaW3+8hlzesZgFejP2iOqlvW18yRPu/GjgMVqmShj7gr3IKGbjIah2wR69gEXy
         ybEGrMyqELrUf8EGiOXtFzLC7koVxK585rtsQDbkiHo2Otg4EhGIbrUq25aRDa6b+7MT
         4HgjGdixc3LMEauQkQeROZ7y9vqVVK/mikHyeHgU+Xq2obVWqOl5Dgzp9sc9W/EYI3Uh
         gSby2yZylzkuq4VzIbXdePM1IzCMcLkVTgJRut2ssuyttAA5DaGu4+0MgDtg2qKmS/UO
         yTfLuIQc/UocnRcOabFkJWZ22JjrExemBLgD0ROk85q6xXuQXi1/H0E5tw4+ktaz26Ss
         Y9sQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710749731; x=1711354531;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=wF1t1OePzE2zuBwKuw2iztC2ZI7yiT09I7BHKf/0jJ4=;
        b=cz4YyqIqKWqTcnD06lM2wDmHf143uhE3fspQR5iSJMq48v3Vet3jWrNAr2FyY0Z/rT
         NB2CIetxDkNlx1TPNsn8G2uw4HfzhD3G4febIs+xCNrAwzFnxUxeyHJjPbC0nGqs78vd
         DoMbm5LnRPJxDHv8XrYXX8/ZsRs7GwxgFbabt8roC9CsiVwhgv/XAkttAZeDKSYEjguU
         QivPeu7cd+IaGI5+4fMNE8Apv0AW+8VeQOO082yQGG54fQk4Kl8DbWj5a/xQ1kXiPwGj
         yeLzK/MhYsPB0Qae2/WRbp++lT1AEGXilvC5/UJnp0eLvrG22Napqfya6ELS/HxG8nrh
         xudw==
X-Forwarded-Encrypted: i=1; AJvYcCWQZNc9St1EJTafQ+dQaIpmzBipGxVviCRvU3X0++b9H2p2Y8D/Ebp70zfJq4ZQR1wg20xpjcPl8IJxq43X6hUwcR3cyfkHegTcuBzeQLM=
X-Gm-Message-State: AOJu0Yzndqz8FtmU5EqmFBq+SSaDbF9tLdO+WTGbSJFZQ3RS/f/v8XPJ
	UjlnIvzFmwDbJn3DLi0DvzzE/AQYlVP4fak3oD+inT00s+GZwQ5wtS8H5d4Mdw==
X-Google-Smtp-Source: AGHT+IEchdIkjDYa+BxxYFLD694TV5ZPHVPVvRr0W/UOvNmeJ4EVeiVccYFiv6mU81ZMVz9mVQj+LQ==
X-Received: by 2002:a17:906:6a1d:b0:a46:bdfe:225b with SMTP id qw29-20020a1709066a1d00b00a46bdfe225bmr2033908ejc.11.1710749730870;
        Mon, 18 Mar 2024 01:15:30 -0700 (PDT)
Message-ID: <7ab73379-b057-4568-9869-141cef185752@suse.com>
Date: Mon, 18 Mar 2024 09:15:31 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] docs/misra: document the expected sizes of integer
 types
Content-Language: en-US
To: Stefano Stabellini 
Cc: andrew.cooper3@citrix.com, bertrand.marquis@arm.com,
 george.dunlap@citrix.com, julien@xen.org, michal.orzel@amd.com,
 roger.pau@citrix.com, xen-devel@lists.xenproject.org
References: 
 <6a76723e-ba47-40b3-8f33-d68030b14299@suse.com>
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 16.03.2024 01:07, Stefano Stabellini wrote:
> On Fri, 15 Mar 2024, Jan Beulich wrote:
>> On 14.03.2024 23:17, Stefano Stabellini wrote:
>>> Xen makes assumptions about the size of integer types on the various
>>> architectures. Document these assumptions.
>>
>> My prior reservation wrt exact vs minimum sizes remains.
> 
> We have to specify the exact size. In practice the size is predetermined
> and exact with all our supported compilers given a architecture.

But that's not the purpose of this document; if it was down to what
compilers offer, we could refer to compiler documentation (and iirc we
already do for various aspects). The purpose of this document, aiui,
is to document assumption we make in hypervisor code. And those should
be >=, not ==.

> Most importantly, unfortunately we use non-fixed-size integer types in
> C hypercall entry points and public ABIs. In my opinion, that is not
> acceptable.

The problem is that I can't see the reason for you thinking so. The C
entry points sit past assembly code doing (required to do) necessary
adjustments, if any. If there was no assembly layer, whether to use
fixed with types for such parameters would depend on what the
architecture guarantees.

As to public ABIs - that's structure definitions, and I agree we ought
to uniformly use fixed-width types there. We largely do; a few things
still require fixing.

> We have two options:
> 
> 1) we go with this document, and we clarify that even if we specify
>   "unsigned int", we actually mean a 32-bit integer
> 
> 2) we change all our public ABIs and C hypercall entry points to use
>    fixed-size types (e.g. s/unsigned int/uint32_t/g)
> 
> 2) is preferred because it is clearer but it is more work. So I went
> with 1). I also thought you would like 1) more.

For ABIs (i.e. structures) we ought to be making that change anyway.
Leaving basic types in there is latently buggy.

I'm happy to see a document like this added, for the purpose described
above. But to me 1) and 2) and largely independent of one another.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Mar 18 09:13:48 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 09:13:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694555.1083380 (Exim 4.92)
	(envelope-from )
	id 1rm93t-0006Nw-S4; Mon, 18 Mar 2024 09:13:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694555.1083380; Mon, 18 Mar 2024 09:13:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rm93t-0006Np-O5; Mon, 18 Mar 2024 09:13:41 +0000
Received: by outflank-mailman (input) for mailman id 694555;
 Mon, 18 Mar 2024 09:13:40 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rm93s-0006Nj-JV
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 09:13:40 +0000
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com
 [2a00:1450:4864:20::534])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ce6771ce-e507-11ee-afdd-a90da7624cb6;
 Mon, 18 Mar 2024 10:13:38 +0100 (CET)
Received: by mail-ed1-x534.google.com with SMTP id
 4fb4d7f45d1cf-56a2b881911so735688a12.3
 for ; Mon, 18 Mar 2024 02:13:38 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ko6-20020a170906aa0600b00a46a9c38a64sm2301711ejb.65.2024.03.18.02.13.37
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 18 Mar 2024 02:13:37 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ce6771ce-e507-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710753218; x=1711358018; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=FzxNvNLNHvnL98ErJsYdzvurFiNavMb6GDLPsMwaO4k=;
        b=OOYUhqEdF/hYOD/PwsKN0ZPP+DK1B1UMangK3/A36KSvlj/KpA7Hb2ti36og8GL1D/
         onFvjdqqN5sz2yCpRo/ssDnfS0F40xvikrejCFA6xY+Z3a+XB78Rgon3MEri0w0ToSvK
         e8cAVoqJ4QB8nZbp4OaRcqkQ+xlCLVla7lS4zhK3e8GzcIP26kEgdrobFHJmA7qGDdDL
         qO/NmBqwhL7FbbyQfkY3LY4aM8zUbB2LMuADvk0z4HFiDog/4bO5xGd8wC957Ym48+RR
         B95vjMIjZkYao7keTYw4ZiOlGuVJFcK9g7vBtrdcU7i79v1pEEXNrIyAtPeG8rLI0gd/
         q9pg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710753218; x=1711358018;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=FzxNvNLNHvnL98ErJsYdzvurFiNavMb6GDLPsMwaO4k=;
        b=aJ5Vd57V7RXId/zuokPZXztd1qnh8SgazdznPPt/10ttvyUnU9OoBeUaNQA+a3Lzlq
         PXcgMIJ/N2GzFNvN7Jfg7xplEh3s6jJwqafmjXc04EheG8lDT6xd//xZCZdL/oWFxzTF
         HITqaGkqxzrkoyp/XmPQ6SFrsRHRgwvSzkjaWh5ffCOIRA2Pu0GRYAu2HTRXUt6Mfdce
         0tnm9ux2lN5z0rCfo7sjrBX0wxS6LScexw8j+eGOMIro2L1Tw2/mht5qBuAx8ST4LYmn
         UCJvrfDA/bPeBYmI3GBqRm0n36XoG1DvP8/sjDwcMzWzNGmH5pRfh/2mAP3nnQVOzMux
         t+oQ==
X-Forwarded-Encrypted: i=1; AJvYcCVJV5TfFTiICTJ7PJD4nFLlv64vulcnqni5RHYWOYuYMcED9DXG2cCKdKcwXX4meMqOjszMMoSC1QBCcQO+22vBQsUNYtU59U5/f4Grspc=
X-Gm-Message-State: AOJu0Ywumiu6TqI1JvfrVacOpidTHWsOj5bRARbDt0Xxf+bWwUVFBWYV
	b1PUnGZ37FF1bxuJstYU8RJ1YJkbmXhFy5u+4cSlcbwNbSkJrf/0KsGcbYPrqg==
X-Google-Smtp-Source: AGHT+IEZYzPAWMXU4xehCEXy5woTKeEXJhZaerU86HdYBn8dglzctLbR7090UcIdiWu/FGihzaC5kQ==
X-Received: by 2002:a17:906:8406:b0:a46:7384:3233 with SMTP id n6-20020a170906840600b00a4673843233mr6610762ejx.57.1710753218100;
        Mon, 18 Mar 2024 02:13:38 -0700 (PDT)
Message-ID: 
Date: Mon, 18 Mar 2024 10:13:37 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 6/7] xen: Swap find_first_set_bit() for ffsl() - 1
Content-Language: en-US
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Wei Liu , Stefano Stabellini ,
 Julien Grall , Volodymyr Babchuk
 , Bertrand Marquis ,
 Michal Orzel ,
 Oleksii Kurochko ,
 Shawn Anastasio ,
 "consulting @ bugseng . com" ,
 Simone Ballarin ,
 Federico Serafini ,
 Nicola Vetrini ,
 Xen-devel 
References: <20240313172716.2325427-1-andrew.cooper3@citrix.com>
 <20240313172716.2325427-7-andrew.cooper3@citrix.com>
 
 <1356dd16-03e1-4c01-9aac-597a127dea85@citrix.com>
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 14.03.2024 19:51, Andrew Cooper wrote:
> On 14/03/2024 6:47 pm, Andrew Cooper wrote:
>> On 14/03/2024 2:30 pm, Jan Beulich wrote:
>>> On 13.03.2024 18:27, Andrew Cooper wrote:
>>>> --- a/xen/drivers/passthrough/x86/iommu.c
>>>> +++ b/xen/drivers/passthrough/x86/iommu.c
>>>> @@ -641,7 +641,7 @@ struct page_info *iommu_alloc_pgtable(struct domain_iommu *hd,
>>>>      if ( contig_mask )
>>>>      {
>>>>          /* See pt-contig-markers.h for a description of the marker scheme. */
>>>> -        unsigned int i, shift = find_first_set_bit(contig_mask);
>>>> +        unsigned int i, shift = ffsl(contig_mask) - 1;
>>> The need for subtracting 1 is why personally I dislike ffs() / ffsl() (and
>>> why I think find_first_set_bit() and __ffs() (but no __ffsl()) were
>>> introduced).
>> It's sad that there are competing APIs with different bit-labelling, but
>> the optimiser does cancel the -1 with arch_ffs() (for at least x86 and
>> ARM that I studied in detail).
>>
>> I firmly believe that fewer APIs which are fully well defined (and can
>> optimise based on the compiler's idea of safety) is still better than a
>> maze of APIs with different behaviours.

I agree here. The anomaly (as I would call it) with ffs(), though, is what
makes me wonder whether we might not be better off introducing ctz() and
clz() instead. Unlike ffs() their name says exactly what is meant. This is
then also a clear hint, for Arm and RISC-V at least, what underlying
instruction is used. Plus there are matching builtins (unlike for e.g.
fls()).

>>> But what I first of all would like to have clarification on is what your
>>> (perhaps just abstract at this point) plans are wrt ffz() / ffzl().
>>> Potential side-by-side uses would be odd now, and would continue to be odd
>>> if the difference in bit labeling was retained. Since we're switching to
>>> a consolidated set of basic helpers, such an anomaly would better not
>>> survive imo.
>> I honestly hadn't got that far yet.  I was mainly trying to dis-entangle
>> the existing mess so RISC-V wasn't making it yet-worse.
>>
>> But yes - it warrants thinking about.
>>
>>
>> I was intending to do the fls() next then popcnt().   The latter has
>> quite a lot of cleanup wanting to come with it, and is more
>> architecturally invasive, and I know I've got a years-old outstanding
>> piece of work to try and do popcnt more nicely on x86.
>>
>> I have wanted ffz() in the past.  I think I just went with explicit ~
>> because I didn't want to continue this debate at the time.
>>
>> However, I (very much more) do not want a situation where ffs() and
>> ffz() have different bit-labellings.
>>
>>
>> There are no builtins, and having now studied the architectures we care
>> about... https://godbolt.org/z/KasP41n1e ...not even x86 has a "count
>> leading/trailing zeros" instruction.
> 
> Hopefully obviously, I meant ones here.   My point is that the compiler
> emitted code always has a NOT in it somewhere.

Right; I was about to ask but then remembered there was another mail from
you on this thread.

>> So using ffs(~val) really will get you the best code generation
>> available, and seeing as it halves the number of bitops to maintain, I
>> think this is the best tradeoff overall.
>>
>> I intend to put ffz() and __ffs() into linux-compat.h and leave them
>> there to discourage their use generally.

I'm okay with this plan. As per above I'd prefer if ffs() moved there, too.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Mar 18 09:55:02 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 09:55:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694564.1083390 (Exim 4.92)
	(envelope-from )
	id 1rm9hi-00042J-Rf; Mon, 18 Mar 2024 09:54:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694564.1083390; Mon, 18 Mar 2024 09:54:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rm9hi-00042C-OC; Mon, 18 Mar 2024 09:54:50 +0000
Received: by outflank-mailman (input) for mailman id 694564;
 Mon, 18 Mar 2024 09:54:48 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rm9hg-000426-Ox
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 09:54:48 +0000
Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com
 [2607:f8b0:4864:20::736])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8dca18fa-e50d-11ee-afdd-a90da7624cb6;
 Mon, 18 Mar 2024 10:54:47 +0100 (CET)
Received: by mail-qk1-x736.google.com with SMTP id
 af79cd13be357-789e83637e0so154835485a.2
 for ; Mon, 18 Mar 2024 02:54:47 -0700 (PDT)
Received: from localhost ([85.31.135.62]) by smtp.gmail.com with ESMTPSA id
 pi20-20020a05620a379400b00788406f9c7dsm4410200qkn.101.2024.03.18.02.54.45
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 18 Mar 2024 02:54:46 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8dca18fa-e50d-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710755686; x=1711360486; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=Vb7sv4C/b8dEhPARry4PDXgALgtTgI/ctLV7gaE2U48=;
        b=IQg6fwrNzbQdUosOUlxDf7G0SGwY9XWxi8ZkJbabuGmaL2BoHEip5cfkrIsCUGNv3M
         kJqiU/B27wpJLuudqHCBTOLPPVzWNF3pIIkHmcmm9D1EXwlhWoHHr3oCndXINK2kqUV1
         HG/PGe4xEn3CuLwpTpLAM6mDWJxs9631qDF+E=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710755686; x=1711360486;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=Vb7sv4C/b8dEhPARry4PDXgALgtTgI/ctLV7gaE2U48=;
        b=AxuToZn5wV6wcvB8hwZ4dzh4498JFJqB6C1x+fcqJI4Lh/Y+VktCcGOCGOJdiCeLal
         WGrJPDWGm6ixGxKUzePbHFo/brckcRKeoxlMpOJAqd7O07L3nshwUwaZ5Z5fHF0MtsUk
         6Pm8roGh5+H3e35gpnbDO8kD/gapJoYhbqImZ7nyJD4esXuv9UocbZO7WJ9LY1vx43oD
         EVuICRoN091XPw0P1vcAMZ6la45VhezR4fM+gqbBA3p1dR8bMm1nP0IxGEZhRgdvpeE+
         C2WfJwj2ehi2NfUpKyFzyBG5d325LDKaQkdCzb0TfuQTU1vF9sqcLd2CJ/5L8JGLzJ5t
         7wZQ==
X-Gm-Message-State: AOJu0YwTvn4s2i2IkoLiV4Es6CYx5iIoTbOAEUqN1g0excdg9jiyJKRI
	0l2kUdajCoL65YrLG2RfrY2i31OtqzDrYrN2jrlipDVzcU3NvMsXgLIFFk6wMZM6m2ySiRePPYS
	W
X-Google-Smtp-Source: AGHT+IEMBr15bIUQFDJFkYcY7gMhbzh5b6DT8qTSxGgHIif9R82yvmomHsd0XxGcqKqmfRHwkfQaxg==
X-Received: by 2002:a05:620a:c0d:b0:789:e71b:f2e4 with SMTP id l13-20020a05620a0c0d00b00789e71bf2e4mr7957629qki.63.1710755686464;
        Mon, 18 Mar 2024 02:54:46 -0700 (PDT)
Date: Mon, 18 Mar 2024 10:54:44 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Andrew Cooper 
Cc: Xen-devel ,
	Jan Beulich , Wei Liu 
Subject: Re: [PATCH] x86/boot: Improve the boot watchdog determination of
 stuck cpus
Message-ID: 
References: <20240315195704.3423282-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <20240315195704.3423282-1-andrew.cooper3@citrix.com>

On Fri, Mar 15, 2024 at 07:57:04PM +0000, Andrew Cooper wrote:
> Right now, check_nmi_watchdog() has two processing loops over all online =
CPUs
> using prev_nmi_count as storage.
>=20
> Use a cpumask_t instead (1/32th as much initdata) and have wait_for_nmis()
> make the determination of whether it is stuck, rather than having both
> functions needing to agree on how many ticks mean stuck.
>=20
> More importantly though, it means we can use the standard cpumask
> infrastructure, including turning this:
>=20
>   (XEN) Brought up 512 CPUs
>   (XEN) Testing NMI watchdog on all CPUs: {0,1,2,3,4,5,6,7,8,9,10,11,12,1=
3,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,3=
8,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,6=
3,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,8=
8,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,=
110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128=
,129,130,131,132,133,134,135,136,137,138,139,140,141,142,143,144,145,146,14=
7,148,149,150,151,152,153,154,155,156,157,158,159,160,161,162,163,164,165,1=
66,167,168,169,170,171,172,173,174,175,176,177,178,179,180,181,182,183,184,=
185,186,187,188,189,190,191,192,193,194,195,196,197,198,199,200,201,202,203=
,204,205,206,207,208,209,210,211,212,213,214,215,216,217,218,219,220,221,22=
2,223,224,225,226,227,228,229,230,231,232,233,234,235,236,237,238,239,240,2=
41,242,243,244,245,246,247,248,249,250,251,252,253,254,255,256,257,258,259,=
260,261,262,263,264,265,266,267,268,269,270,271,272,273,274,275,276,277,278=
,279,280,281,282,283,284,285,286,287,288,289,290,291,292,293,294,295,296,29=
7,298,299,300,301,302,303,304,305,306,307,308,309,310,311,312,313,314,315,3=
16,317,318,319,320,321,322,323,324,325,326,327,328,329,330,331,332,333,334,=
335,336,337,338,339,340,341,342,343,344,345,346,347,348,349,350,351,352,353=
,354,355,356,357,358,359,360,361,362,363,364,365,366,367,368,369,370,371,37=
2,373,374,375,376,377,378,379,380,381,382,383,384,385,386,387,388,389,390,3=
91,392,393,394,395,396,397,398,399,400,401,402,403,404,405,406,407,408,409,=
410,411,412,413,414,415,416,417,418,419,420,421,422,423,424,425,426,427,428=
,429,430,431,432,433,434,435,436,437,438,439,440,441,442,443,444,445,446,44=
7,448,449,450,451,452,453,454,455,456,457,458,459,460,461,462,463,464,465,4=
66,467,468,469,470,471,472,473,474,475,476,477,478,479,480,481,482,483,484,=
485,486,487,488,489,490,491,492,493,494,495,496,497,498,499,500,501,502,503=
,504,505,506,507,508,509,510,511} stuck
>=20
> into the rather more manageable:
>=20
>   (XEN) Brought up 512 CPUs
>   (XEN) Testing NMI watchdog on all CPUs: {0-511} stuck
>=20
> Signed-off-by: Andrew Cooper 

One thing has to be said about the previous message: it was hard to
not see it when all CPUs on the system failed the watchdog test.

Reviewed-by: Roger Pau Monn=C3=A9 

Thanks.


From xen-devel-bounces@lists.xenproject.org Mon Mar 18 10:14:29 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 10:14:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694571.1083405 (Exim 4.92)
	(envelope-from )
	id 1rmA0c-0007R3-AI; Mon, 18 Mar 2024 10:14:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694571.1083405; Mon, 18 Mar 2024 10:14:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmA0c-0007Qw-7c; Mon, 18 Mar 2024 10:14:22 +0000
Received: by outflank-mailman (input) for mailman id 694571;
 Mon, 18 Mar 2024 10:14:21 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmA0b-0007Qq-Hl
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 10:14:21 +0000
Received: from mail-qv1-xf29.google.com (mail-qv1-xf29.google.com
 [2607:f8b0:4864:20::f29])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 48768d21-e510-11ee-afdd-a90da7624cb6;
 Mon, 18 Mar 2024 11:14:19 +0100 (CET)
Received: by mail-qv1-xf29.google.com with SMTP id
 6a1803df08f44-69185f093f5so16687976d6.3
 for ; Mon, 18 Mar 2024 03:14:19 -0700 (PDT)
Received: from localhost ([85.31.135.62]) by smtp.gmail.com with ESMTPSA id
 h12-20020a0562140dac00b00690ae7bbd05sm5147474qvh.72.2024.03.18.03.14.18
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 18 Mar 2024 03:14:18 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 48768d21-e510-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710756859; x=1711361659; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=+ChSCFs7gjsrFACr4WWzhqhD9fd6bGDWozfU/Ai940s=;
        b=vUPXttR/FNeM7PvJg6l+0OE06RuCet2k7oEmCEFAXFw0QXhETeT/FdBxLyOpGrmAGA
         CRkgJIEKS+nD1SthKzcfrDzJREu0jJ3DBAIm0JPQIOwURGQe3/wa+y3yFAp7uvW/jGRE
         I2mtiypF/oTlGatHS4XT8WDoG6fA/HfupIm3s=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710756859; x=1711361659;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=+ChSCFs7gjsrFACr4WWzhqhD9fd6bGDWozfU/Ai940s=;
        b=tob4p0CpJgd6bMna8mquM249E40KWl0aCDH4lMKFq0qfxRhilqn2acF5G+Z+9aCEGk
         HGxEjvtLXc4pElJ5agrC0OqF9X4+WUyGEA+HtY+X2uh2rfncK/zilNNZarzpRQ1/SM07
         KpIHw+ylfHiWwwyqaDNFyyOlbxtM77C8phjL40/dXSCY6S4D73Jzb2PHq8IsjUz4ypNk
         etq2lVwvtQ4oqhxN6qsIUZ0TWNJnxp7vlSYqfn0y3SMmgxIPNjsZ+R0qQfMEhG1doJKo
         6pycfrZLTP51x0jFwJrTZmX/OcR5GXPpJkYaF7v6X5wsLvvFals7vSnYpSGPrEDACFJz
         FVGw==
X-Gm-Message-State: AOJu0YyGNIhT5lsSmAaMtmShEEXGhqQNIryz91V/S4pqpv3SDcYrAQ54
	vtdMygCAB3UhKX0mPgEWhaxAdhDSRq/AOKWrO/VWmp5w7GbhMHg14T69d2QOLaQ=
X-Google-Smtp-Source: AGHT+IFV2DQe+CxyFV8C9VxxV9FGirK3JhMqzu0F0Ul4RPa4cgXDLtr5srjISknRzeAGDXGtRUDN7Q==
X-Received: by 2002:ad4:55e4:0:b0:696:2b3e:769b with SMTP id bu4-20020ad455e4000000b006962b3e769bmr58954qvb.56.1710756858732;
        Mon, 18 Mar 2024 03:14:18 -0700 (PDT)
Date: Mon, 18 Mar 2024 11:14:16 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Andrew Cooper 
Cc: Xen-devel 
Subject: Re: [PATCH] xen/vpci: Improve code generation in mask_write()
Message-ID: 
References: <20240315121322.3300387-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20240315121322.3300387-1-andrew.cooper3@citrix.com>

On Fri, Mar 15, 2024 at 12:13:22PM +0000, Andrew Cooper wrote:
> The use of __clear_bit() forces dmask to be spilled to the stack, and
> interferes with the compiler heuristcs for some upcoming improvements to the
> ffs() code generation.
> 
> First, shrink dmask to just the active vectors by making out the upper bits.
> This replaces the "i < msi->vectors" part of the loop condition.
> 
> Next, use a simple while() loop with "clear bottom bit" expressed in plane C,
> which affords the optimiser a far better understanding of what the loop is
> doing.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Roger Pau Monné 

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Mon Mar 18 10:42:59 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 10:42:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694576.1083416 (Exim 4.92)
	(envelope-from )
	id 1rmASC-0003Zz-F6; Mon, 18 Mar 2024 10:42:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694576.1083416; Mon, 18 Mar 2024 10:42:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmASC-0003Zs-CO; Mon, 18 Mar 2024 10:42:52 +0000
Received: by outflank-mailman (input) for mailman id 694576;
 Mon, 18 Mar 2024 10:42:51 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmASB-0003Zj-IB
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 10:42:51 +0000
Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com
 [2607:f8b0:4864:20::e31])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 429c4f03-e514-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 11:42:48 +0100 (CET)
Received: by mail-vs1-xe31.google.com with SMTP id
 ada2fe7eead31-4766e56ccccso1104189137.0
 for ; Mon, 18 Mar 2024 03:42:47 -0700 (PDT)
Received: from localhost ([85.31.135.62]) by smtp.gmail.com with ESMTPSA id
 t26-20020a05620a035a00b00789fb5397d4sm1142033qkm.100.2024.03.18.03.42.45
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 18 Mar 2024 03:42:45 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 429c4f03-e514-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710758567; x=1711363367; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=SNXGfHICvCJmaSXUF97NFYIM8VOq6lSNbXkP8BoBeiM=;
        b=p2z8RCXaFQAAN4yepOJ8HtRpjQEcjWEQLTUl9OLoyiuWvF2FWAdPOYbIAOunHMs4sO
         Q1WhcblKf7vbd6DXDa5tk2RgmgNpD3tIbDSywlqkD47v3K09aHCriJCxVXZx41oBcDao
         GjAfIvGHPgyagA2iMXW7dkyZ/oVOUDM6Hjv3g=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710758567; x=1711363367;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=SNXGfHICvCJmaSXUF97NFYIM8VOq6lSNbXkP8BoBeiM=;
        b=DEzgSNT0uMy7rP6sxsSpntEvCOiXGfcUDrdcPx8t0qTDOPTzCyAjeFpmRhhT+z/h2u
         DBmfed6hrVrIGbo2ux/nGJFoZ6vv30sVJmoKLH6s19XwkLueToPdpxXjLhTkBn3Fo7lA
         iY9FOo//gQwt8XzPCUmk0ZZm3fKRjEWxqysugfimE2oV0ruY47Al3CNA2kMidiE52krZ
         0FCbT/9y9A0sKDPKsKRfwtifDRqYC8XUcnsaMzCfMK3u0cci53G+W92v14I8d8qqNGw4
         0an3ZG4C0cKZZo0unL/4YX1fIJAcLN85qDCh/t9vy3ss3crjHrNNEjGrrwIEtgpMtO39
         SDaQ==
X-Gm-Message-State: AOJu0Yyy3mph/5lV5kuqSlVJA2VzxqOLB0068bdEW/WIbLBun96/T7Oh
	eb7M0zmzELNAhyCPUSkMBSpODjNAUOjXplY/JzvCECyM7VoPEoMXE+LkjvhtYe8=
X-Google-Smtp-Source: AGHT+IESddaQzFGXhOQLu3zE8U/OaaHxyJPeulHsVzNPdh1xUNkPYkHO7lrO3IY3+d1tq5JSRLLhZA==
X-Received: by 2002:a05:6102:d9:b0:476:7d83:9dae with SMTP id u25-20020a05610200d900b004767d839daemr2565971vsp.2.1710758565888;
        Mon, 18 Mar 2024 03:42:45 -0700 (PDT)
Date: Mon, 18 Mar 2024 11:42:43 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Anthony PERARD 
Cc: xen-devel@lists.xenproject.org
Subject: Re: [OSSTEST PATCH v2 0/3] Switch to Linux 6.1 by default on x86
Message-ID: 
References: <20240315154849.28819-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20240315154849.28819-1-anthony.perard@citrix.com>

On Fri, Mar 15, 2024 at 03:48:46PM +0000, Anthony PERARD wrote:
> Patch series available in this git branch:
> https://xenbits.xen.org/git-http/people/aperard/osstest.git br.linux-6.1-v2
> 
> Hi,
> 
> A set of patch which lead to using Linux 6.1 instead of 4.19 as a default
> kernel on x86.
> 
> I've check the list of jobs changes with
> OSSTEST_CONFIG=standalone-config-example nice eatmydata ./standalone-generate-dump-flight-runvars
> 
> All branches are affected with changes, most will have the same changes as the
> branch "xen-unstable" (unless the only have a subset of those jobs like
> "libvirt"), and linux-{linus,6.1} will have the changes as listed on
> linux-linus.
> 
> Thanks,
> 
> xen-unstable:
> - test-amd64-coresched-i386-xl
> - test-amd64-i386-examine
> - test-amd64-i386-examine-bios
> - test-amd64-i386-examine-uefi
> - test-amd64-i386-freebsd10-amd64
> - test-amd64-i386-freebsd10-i386
> - test-amd64-i386-libvirt
> - test-amd64-i386-libvirt-pair
> - test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm
> - test-amd64-i386-libvirt-raw
> - test-amd64-i386-libvirt-xsm
> - test-amd64-i386-livepatch
> - test-amd64-i386-migrupgrade
> - test-amd64-i386-pair
> - test-amd64-i386-qemut-rhel6hvm-amd
> - test-amd64-i386-qemut-rhel6hvm-intel
> - test-amd64-i386-qemuu-rhel6hvm-amd
> - test-amd64-i386-qemuu-rhel6hvm-intel
> - test-amd64-i386-xl
> - test-amd64-i386-xl-pvshim
> - test-amd64-i386-xl-qemut-debianhvm-amd64
> - test-amd64-i386-xl-qemut-debianhvm-i386-xsm
> - test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
> - test-amd64-i386-xl-qemut-win7-amd64
> - test-amd64-i386-xl-qemut-ws16-amd64
> - test-amd64-i386-xl-qemuu-debianhvm-amd64
> - test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow
> - test-amd64-i386-xl-qemuu-debianhvm-i386-xsm
> - test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict
> - test-amd64-i386-xl-qemuu-ovmf-amd64
> - test-amd64-i386-xl-qemuu-win7-amd64
> - test-amd64-i386-xl-qemuu-ws16-amd64
> - test-amd64-i386-xl-shadow
> - test-amd64-i386-xl-simplat-amd64-buster
> - test-amd64-i386-xl-vhd
> - test-amd64-i386-xl-xsm
> - test-armhf-armhf-libvirt-qcow2
> - test-armhf-armhf-libvirt-raw
> - test-armhf-armhf-xl-vhd
> + test-amd64-amd64-libvirt-qcow2
> + test-amd64-amd64-libvirt-raw
> + test-amd64-amd64-xl-raw
> + test-amd64-amd64-xl-vhd
> + test-armhf-armhf-libvirt-vhd
> + test-armhf-armhf-xl-qcow2
> + test-armhf-armhf-xl-raw

The shuffling of the armhf disk formats is unfortunate, but I don't
think there's much we can do about it without hardcoding the
combinations to be fixed instead of randomly spread.  I don't think
this random spreading was a good idea, as it's easy for unrelated
changes to alter the resulting tests, thus loosing history.

> 
> linux-linus:
> - test-amd64-amd64-freebsd11-amd64
> - test-amd64-amd64-freebsd12-amd64
> - test-armhf-armhf-libvirt-qcow2
> - test-armhf-armhf-libvirt-raw
> - test-armhf-armhf-xl-vhd
> + test-amd64-amd64-libvirt-vhd
> + test-amd64-amd64-qemuu-freebsd11-amd64
> + test-amd64-amd64-qemuu-freebsd12-amd64
> + test-amd64-amd64-xl-qcow2
> + test-amd64-amd64-xl-raw
> + test-armhf-armhf-libvirt-vhd
> + test-armhf-armhf-xl-qcow2
> + test-armhf-armhf-xl-raw
> 
> Anthony PERARD (3):
>   make-fligh: Fix freebsd guest test test-id
>   mfi-common: Rework toolstack-disk_format test matrix
>   ap-common: Switch to Linux 6.1 by default on x86 + drop dom0 i386

Acked-by: Roger Pau Monné 

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Mon Mar 18 10:55:14 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 10:55:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694580.1083425 (Exim 4.92)
	(envelope-from )
	id 1rmAdy-0005Uv-Ko; Mon, 18 Mar 2024 10:55:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694580.1083425; Mon, 18 Mar 2024 10:55:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmAdy-0005Uo-Hy; Mon, 18 Mar 2024 10:55:02 +0000
Received: by outflank-mailman (input) for mailman id 694580;
 Mon, 18 Mar 2024 10:55:01 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmAdx-0005Uh-Ej
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 10:55:01 +0000
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com
 [2a00:1450:4864:20::529])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f7458770-e515-11ee-afdd-a90da7624cb6;
 Mon, 18 Mar 2024 11:55:00 +0100 (CET)
Received: by mail-ed1-x529.google.com with SMTP id
 4fb4d7f45d1cf-56b84b2c8c8so216654a12.1
 for ; Mon, 18 Mar 2024 03:55:00 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 er27-20020a056402449b00b00568d2518105sm1461528edb.12.2024.03.18.03.54.59
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 18 Mar 2024 03:54:59 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f7458770-e515-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710759300; x=1711364100; darn=lists.xenproject.org;
        h=content-transfer-encoding:autocrypt:subject:from:cc:to
         :content-language:user-agent:mime-version:date:message-id:from:to:cc
         :subject:date:message-id:reply-to;
        bh=HAFNlQLx2cVtsybVUptvK+eVzOW3fyA22J6ForGF3/U=;
        b=CpmAQg8VjBO3hsw3w1nWWonZf/wEO8H1sXn8XNmzQuJPr8UtdOKbz9Y2FwM2ayE/gA
         r7Idck6W+WQjh7weSBciUPjf/ILODdfcCpQdJU0d5SoAHkeMJqx2b0/tloCQOqRcdlJq
         vMHoGy66CRr3OmrxDii8/eJx6he6CZ5mOp75ABBX2Qw2rPgQW3wIDQplgnIOx+7P7ktk
         dlhDfV0YRRFsBUZr9C2a25L2+QGETgdaTVbmsmfZnDpRN9cYSbRPvRm32h8lMQVubLNy
         My8CFIUoa2sdSbposKCBqoKzvxwghRoGw1sUc6RIzwiU5Cwow1xveQ1gTPorma/1aslX
         DaCQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710759300; x=1711364100;
        h=content-transfer-encoding:autocrypt:subject:from:cc:to
         :content-language:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=HAFNlQLx2cVtsybVUptvK+eVzOW3fyA22J6ForGF3/U=;
        b=tE7Gwk8ha5NKFbR60v04Yr4KgA5xwvfCRbks8oeauY/O/FoUcvg5u0xRuxhExwx3Wa
         ZCta0fvvSfDyQ0uUECz1WR52ZvVEBfftJT2rsyCrkbfRtL7t3alMBj0E0mXe5hymOmKC
         UFjlfFE2GubSrVr3Fwu/5QQ//+wONdnPoao15D4Re951b6+JqSGnRdFnsTFgtMlgul12
         kRUXVwebrjMpRzVrAbRJDFCFko0TfSm4FpUi3YuFWfCUd5oF35G8L8P3P6GhxYpmLvIq
         M+Ba/ye+fpxKTnDoC+lgLyU87jgdeKDIK5DjIbssaOjVv9O19R9UwTpnsqo0czbOiIpH
         W1/w==
X-Gm-Message-State: AOJu0YwSF9r1w9DMXbfofMEoSLc00MHDC4p4rI0F6a7wrrA2DXo+Lldp
	p2tA73EATATts4GIDzgHL9g5IUSX3FS17broViCDHltDaE3m/vqZ9sccNSKX4rytbESRrLnG3qU
	=
X-Google-Smtp-Source: AGHT+IEiNM3xXsvcQH7OFxm3WecjXIHkPseO8wePgSDM2H0Z13oo1KkHTDFv0dqXgK+HCStaONbZxA==
X-Received: by 2002:a05:6402:28c9:b0:567:29d9:99ae with SMTP id ef9-20020a05640228c900b0056729d999aemr7559137edb.28.1710759299669;
        Mon, 18 Mar 2024 03:54:59 -0700 (PDT)
Message-ID: 
Date: Mon, 18 Mar 2024 11:54:58 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper , Wei Liu ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 George Dunlap 
From: Jan Beulich 
Subject: [PATCH] x86/mm: use block_lock_speculation() in _mm_write_lock()
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

I can only guess that using block_speculation() there was a leftover
from, earlier on, SPECULATIVE_HARDEN_LOCK depending on
SPECULATIVE_HARDEN_BRANCH.

Fixes: 197ecd838a2a ("locking: attempt to ensure lock wrappers are always inline")
Signed-off-by: Jan Beulich 
---
Noticed while backporting to 4.12, where block_speculation() didn't
exist yet.

--- a/xen/arch/x86/mm/mm-locks.h
+++ b/xen/arch/x86/mm/mm-locks.h
@@ -138,7 +138,7 @@ static inline void _mm_write_lock(const struct domain *d, mm_rwlock_t *l,
         _set_lock_level(_lock_level(d, level));
     }
     else
-        block_speculation();
+        block_lock_speculation();
     l->recurse_count++;
 }
 


From xen-devel-bounces@lists.xenproject.org Mon Mar 18 11:04:58 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 11:04:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694589.1083445 (Exim 4.92)
	(envelope-from )
	id 1rmAnW-0007g7-QS; Mon, 18 Mar 2024 11:04:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694589.1083445; Mon, 18 Mar 2024 11:04:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmAnW-0007g0-Mz; Mon, 18 Mar 2024 11:04:54 +0000
Received: by outflank-mailman (input) for mailman id 694589;
 Mon, 18 Mar 2024 11:04:52 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmAnU-0007RX-OV
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 11:04:52 +0000
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com
 [2a00:1450:4864:20::536])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 57376e95-e517-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 12:04:51 +0100 (CET)
Received: by mail-ed1-x536.google.com with SMTP id
 4fb4d7f45d1cf-56a0c0a7ebcso947161a12.1
 for ; Mon, 18 Mar 2024 04:04:50 -0700 (PDT)
Received: from andrewcoop.citrite.net (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 f22-20020aa7d856000000b0056b818544a9sm324882eds.90.2024.03.18.04.04.48
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 18 Mar 2024 04:04:49 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 57376e95-e517-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710759889; x=1711364689; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:from:to:cc:subject:date:message-id:reply-to;
        bh=3r4xHUzG9Ecu6Kjh81DarskT8rMMxBwKozdg2CbJKKU=;
        b=VGSjvriHrAmBT8QviSIZ2SWJCVOP7tkU45nvw6n+OwYD1NNb1eB7KiH88rdFmiVytE
         e8VsSRwtMJdU/tkHRsyXFSKE0WMveDxO5ynBC4IRlurgX8JdQKP5/4fuzmQAZBhFBtFn
         2qLk24isppx7vNmj5P0eDKDaGA0NJhmJI1k0w=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710759889; x=1711364689;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=3r4xHUzG9Ecu6Kjh81DarskT8rMMxBwKozdg2CbJKKU=;
        b=eTzhaaOCvYT/84OzVmLNyvzQn/+6jjunpT/UWzNQvGa19w1QH+LNsjqAGLa09D+cQ5
         9nw6mg6BOulo2xk25uMrUf2M+USRc1cVyw5GGjeUnxt6J64zE4VETdRsFYagU7FG0z2O
         qyyEL9hlZ6wJqGG+KKKXHHbj0fTVuBee5Car8wXJIQlUuD6olZWrv/naIeJVXtoXNNhQ
         e1EF7XNvFELtad+xIHAn+HxF6LBjFynFarm61AePKKOaoM37M74zBxFb0BpGf2uH7oAr
         1q9aegiod7+BGVVOIDK2DEI2Kyf6I413X3Htf2qj3nur/mXvEcb08JWiRJD/gd/2bGfX
         XcKQ==
X-Gm-Message-State: AOJu0Yx+LwyGJ2msCXfAJ7xTU2inuZyDX7vl41ulfBSyUHjjakwjd3tP
	/kRBAAuZwKunYdjVQNib4u+Qd7rKQKmTZMSBTAkCXXdwy5JE1i1b5z4fZAfQhFjbyMMjjxWJ2m0
	+
X-Google-Smtp-Source: AGHT+IFLI2f2eZwoNNAEBzwVzMi+IqtjO/KUROxj+sr029ZijVt2L8rrEV0WZ4RzMk3zIgMWSZxV1g==
X-Received: by 2002:a05:6402:3589:b0:568:d315:b85e with SMTP id y9-20020a056402358900b00568d315b85emr2525712edc.36.1710759889673;
        Mon, 18 Mar 2024 04:04:49 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Wei Liu ,
	Stefano Stabellini ,
	Julien Grall ,
	Volodymyr Babchuk ,
	Bertrand Marquis ,
	Michal Orzel ,
	Oleksii Kurochko ,
	Shawn Anastasio ,
	Konrad Rzeszutek Wilk ,
	Ross Lagerwall 
Subject: [PATCH 0/4] xen/arch: Simplify virtual_region setup
Date: Mon, 18 Mar 2024 11:04:38 +0000
Message-Id: <20240318110442.3653997-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.30.2
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

There is nothing that setup_virtual_regions() does which can't be done at
build time.  Make this happen.

Importantly, this removes logic from needed prior to setting up exceptions.

Andrew Cooper (4):
  xen/link: Introduce a common BUGFRAMES definition
  xen/virtual-region: Rework how bugframe linkage works
  xen/virtual-region: Link the list build time
  xen/virtual-region: Drop setup_virtual_regions()

 xen/arch/arm/setup.c             |   1 -
 xen/arch/arm/traps.c             |   5 +-
 xen/arch/arm/xen.lds.S           |  13 +---
 xen/arch/ppc/xen.lds.S           |  13 +---
 xen/arch/riscv/xen.lds.S         |  13 +---
 xen/arch/x86/setup.c             |   2 -
 xen/arch/x86/xen.lds.S           |  11 +---
 xen/common/bug.c                 |   5 +-
 xen/common/livepatch.c           |   7 +-
 xen/common/virtual_region.c      | 107 +++++++++++++++++--------------
 xen/include/xen/bug.h            |   6 --
 xen/include/xen/virtual_region.h |   5 +-
 xen/include/xen/xen.lds.h        |  17 +++++
 13 files changed, 95 insertions(+), 110 deletions(-)


base-commit: d638e304f13a5ef7d125de5ace5f7828a7b25bac
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 11:04:58 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 11:04:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694588.1083437 (Exim 4.92)
	(envelope-from )
	id 1rmAnV-0007Rp-J1; Mon, 18 Mar 2024 11:04:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694588.1083437; Mon, 18 Mar 2024 11:04:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmAnV-0007Ri-Ed; Mon, 18 Mar 2024 11:04:53 +0000
Received: by outflank-mailman (input) for mailman id 694588;
 Mon, 18 Mar 2024 11:04:52 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmAnU-0007RW-EP
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 11:04:52 +0000
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com
 [2a00:1450:4864:20::532])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 57c03b65-e517-11ee-afdd-a90da7624cb6;
 Mon, 18 Mar 2024 12:04:51 +0100 (CET)
Received: by mail-ed1-x532.google.com with SMTP id
 4fb4d7f45d1cf-563bb51c36eso4809912a12.2
 for ; Mon, 18 Mar 2024 04:04:51 -0700 (PDT)
Received: from andrewcoop.citrite.net (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 f22-20020aa7d856000000b0056b818544a9sm324882eds.90.2024.03.18.04.04.49
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 18 Mar 2024 04:04:50 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 57c03b65-e517-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710759891; x=1711364691; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=at5KFl9nQfgpXq4Q7Iq5b9vyBtR/kiSx7kLCD84lTrQ=;
        b=lPTQZPylUVPwxdNBvHTjiD4ahw6dXqqaqzbcZPtRrLsO/9EX/ZV05Vxxtw9vBG5vEZ
         j2sZLGTEGGlpo9RZM+mwsnrt2IDTWGRP7Xszzud5opwbvhCpaW2T8rgzh241+/GXiA+0
         EiQwSKYgzNns1yCG3qF+hKfiADMhJ2gUtBj7M=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710759891; x=1711364691;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=at5KFl9nQfgpXq4Q7Iq5b9vyBtR/kiSx7kLCD84lTrQ=;
        b=G//4kVwIlUD+gO35Qr/JTkiA8Rmal1J5heQqj+rfWu6D+VBc2ywHLUgOohbjUWdxQ2
         OfCsZMjQrOb8IeW5FjSnCLv9xop7QkhT2X6Wq4x4EtglSzWsrofIgZ3p+P5mzaWhO8jb
         7uswRehFtyEVSLPrBVqI2zJn72Zx0OynyTEWqgk8JDsA6ZbujH9zoGDQKa3n0qJXR2+k
         bXv3RYq5YLudts3+uOaTMEWj7bTgaQ4U46NdPJcccmcSqlQ120hUea0keNYW43J3Vr7t
         yiCeppOukhzFcG8GzuYVEIBeVL/8pGRT7TVibossS7qacEzITT2xFsisU3vWJoyfd/Y4
         3rCw==
X-Gm-Message-State: AOJu0YxRe2kjWqtXVgKPFc/Ol5dvBFNGN0yB4yD5VB4DTmuVIZOe1uiV
	bpUFqEJs2cve2DvvL0NJTgPVld2NRs6zUwxus2fHufraiK2xHivikMwgEsEGvJLtHmtMrlZ+4FY
	7
X-Google-Smtp-Source: AGHT+IGbQXwmPyQQJOvSY/hRma7SWZ3N6q4E6jLJ4npsLQ3nMf71ZMxM4Mw8uBJpYE8qH3pUoz8dRg==
X-Received: by 2002:a05:6402:3981:b0:568:9b13:77fe with SMTP id fk1-20020a056402398100b005689b1377femr10391077edb.37.1710759890780;
        Mon, 18 Mar 2024 04:04:50 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Wei Liu ,
	Stefano Stabellini ,
	Julien Grall ,
	Volodymyr Babchuk ,
	Bertrand Marquis ,
	Michal Orzel ,
	Oleksii Kurochko ,
	Shawn Anastasio ,
	Konrad Rzeszutek Wilk ,
	Ross Lagerwall 
Subject: [PATCH 1/4] xen/link: Introduce a common BUGFRAMES definition
Date: Mon, 18 Mar 2024 11:04:39 +0000
Message-Id: <20240318110442.3653997-2-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20240318110442.3653997-1-andrew.cooper3@citrix.com>
References: <20240318110442.3653997-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Bugframe linkage is identical in all architectures.  This is not surprising
given that it is (now) only consumed by common/virtual_region.c

Introduce a common BUGFRAMES define in xen.lds.h ahead of rearranging their
structure.

No functional change.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
CC: Wei Liu 
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Volodymyr Babchuk 
CC: Bertrand Marquis 
CC: Michal Orzel 
CC: Oleksii Kurochko 
CC: Shawn Anastasio 
CC: Konrad Rzeszutek Wilk 
CC: Ross Lagerwall 
---
 xen/arch/arm/xen.lds.S    | 13 +++----------
 xen/arch/ppc/xen.lds.S    | 13 +++----------
 xen/arch/riscv/xen.lds.S  | 13 +++----------
 xen/arch/x86/xen.lds.S    | 11 +----------
 xen/include/xen/xen.lds.h | 11 +++++++++++
 5 files changed, 21 insertions(+), 40 deletions(-)

diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 2266c9536f05..bd884664adf6 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -55,16 +55,9 @@ SECTIONS
   . = ALIGN(PAGE_SIZE);
   .rodata : {
         _srodata = .;          /* Read-only data */
-        /* Bug frames table */
-       __start_bug_frames = .;
-       *(.bug_frames.0)
-       __stop_bug_frames_0 = .;
-       *(.bug_frames.1)
-       __stop_bug_frames_1 = .;
-       *(.bug_frames.2)
-       __stop_bug_frames_2 = .;
-       *(.bug_frames.3)
-       __stop_bug_frames_3 = .;
+
+        BUGFRAMES
+
        *(.rodata)
        *(.rodata.*)
        *(.data.rel.ro)
diff --git a/xen/arch/ppc/xen.lds.S b/xen/arch/ppc/xen.lds.S
index 05b6db272805..ca4d4a2b8adf 100644
--- a/xen/arch/ppc/xen.lds.S
+++ b/xen/arch/ppc/xen.lds.S
@@ -42,16 +42,9 @@ SECTIONS
     . = ALIGN(PAGE_SIZE);
     .rodata : {
         _srodata = .;          /* Read-only data */
-        /* Bug frames table */
-        __start_bug_frames = .;
-        *(.bug_frames.0)
-        __stop_bug_frames_0 = .;
-        *(.bug_frames.1)
-        __stop_bug_frames_1 = .;
-        *(.bug_frames.2)
-        __stop_bug_frames_2 = .;
-        *(.bug_frames.3)
-        __stop_bug_frames_3 = .;
+
+        BUGFRAMES
+
         *(.rodata)
         *(.rodata.*)
         *(.data.rel.ro)
diff --git a/xen/arch/riscv/xen.lds.S b/xen/arch/riscv/xen.lds.S
index ace6f49c579c..070b19d91503 100644
--- a/xen/arch/riscv/xen.lds.S
+++ b/xen/arch/riscv/xen.lds.S
@@ -42,16 +42,9 @@ SECTIONS
     . = ALIGN(PAGE_SIZE);
     .rodata : {
         _srodata = .;          /* Read-only data */
-        /* Bug frames table */
-        __start_bug_frames = .;
-        *(.bug_frames.0)
-        __stop_bug_frames_0 = .;
-        *(.bug_frames.1)
-        __stop_bug_frames_1 = .;
-        *(.bug_frames.2)
-        __stop_bug_frames_2 = .;
-        *(.bug_frames.3)
-        __stop_bug_frames_3 = .;
+
+        BUGFRAMES
+
         *(.rodata)
         *(.rodata.*)
         *(.data.rel.ro)
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 8930e14fc40e..fa4e608f0f97 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -131,16 +131,7 @@ SECTIONS
        . = ALIGN(PAGE_SIZE);
        __ro_after_init_end = .;
 
-       /* Bug frames table */
-       __start_bug_frames = .;
-       *(.bug_frames.0)
-       __stop_bug_frames_0 = .;
-       *(.bug_frames.1)
-       __stop_bug_frames_1 = .;
-       *(.bug_frames.2)
-       __stop_bug_frames_2 = .;
-       *(.bug_frames.3)
-       __stop_bug_frames_3 = .;
+       BUGFRAMES
 
        *(.rodata)
        *(.rodata.*)
diff --git a/xen/include/xen/xen.lds.h b/xen/include/xen/xen.lds.h
index 06b7110837a1..decd6db5fc6d 100644
--- a/xen/include/xen/xen.lds.h
+++ b/xen/include/xen/xen.lds.h
@@ -104,6 +104,17 @@
 
 /* List of constructs other than *_SECTIONS in alphabetical order. */
 
+#define BUGFRAMES                               \
+    __start_bug_frames = .;                     \
+    *(.bug_frames.0)                            \
+    __stop_bug_frames_0 = .;                    \
+    *(.bug_frames.1)                            \
+    __stop_bug_frames_1 = .;                    \
+    *(.bug_frames.2)                            \
+    __stop_bug_frames_2 = .;                    \
+    *(.bug_frames.3)                            \
+    __stop_bug_frames_3 = .;
+
 #ifdef CONFIG_HYPFS
 #define HYPFS_PARAM              \
        . = ALIGN(POINTER_ALIGN); \
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 11:04:58 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 11:04:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694591.1083461 (Exim 4.92)
	(envelope-from )
	id 1rmAnY-0007yy-Dq; Mon, 18 Mar 2024 11:04:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694591.1083461; Mon, 18 Mar 2024 11:04:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmAnY-0007xu-6K; Mon, 18 Mar 2024 11:04:56 +0000
Received: by outflank-mailman (input) for mailman id 694591;
 Mon, 18 Mar 2024 11:04:54 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmAnW-0007RW-Kd
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 11:04:54 +0000
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com
 [2a00:1450:4864:20::534])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5944d93b-e517-11ee-afdd-a90da7624cb6;
 Mon, 18 Mar 2024 12:04:54 +0100 (CET)
Received: by mail-ed1-x534.google.com with SMTP id
 4fb4d7f45d1cf-563c403719cso5161527a12.2
 for ; Mon, 18 Mar 2024 04:04:54 -0700 (PDT)
Received: from andrewcoop.citrite.net (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 f22-20020aa7d856000000b0056b818544a9sm324882eds.90.2024.03.18.04.04.52
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 18 Mar 2024 04:04:52 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5944d93b-e517-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710759893; x=1711364693; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=AWCsjWzVUd6sUyetSs9CWtqz4kTMclSOuQ/QVUP2fXQ=;
        b=W+TgMkZ8NmZt3fusV1/9lhb2JQoM9sEJIqY7GPGX5uYZ2zIPu7xetXvzH4c6oiGzWn
         ifx+sDZIjbyygSS5LsTPO9soshIE+N0O70HhWFLPZf+grseh62BoNh3vqoe/eiwDwplg
         qnWLY1eH6QwYZXizVSEW/0ap8h3WDhPFKhaiI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710759893; x=1711364693;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=AWCsjWzVUd6sUyetSs9CWtqz4kTMclSOuQ/QVUP2fXQ=;
        b=KPPNR6C5j6gm7Echvnuj4cdjFLMfQx2M4XE8D/9Hz6xo9Wk6exmRTgKy3nM55A4aDj
         2AOWLH6eUzujhxK1y7r+9fqdUI7KO43uUvXRPy+zDUjKGOsQTmsOWeAyDSg59mvcgZm+
         TLEMBtcrF4NfKigrO9DtHHUId4EclakDVPAgYyy1NEHLl+8Cd0y6isMWeV0dQnLszUlB
         ZUFtvP17hCRH4kdtzIb5BS+JqwZ6uvTnibaLegCXrWB1Rsfrn3pfk47p/fEpwBjKEQxS
         iPBTY4JglHpLLZdwu9BlH1eb99IVCk6O7GhiTL1g3mt2HUPQcyePfj8cj91GDo5NoV9X
         j/GQ==
X-Gm-Message-State: AOJu0Yw/YHP9B+U19ijMGXcu2naaISeJmHx3VqCTa6F/MT8AIu4R7vgp
	QXOJUUEao4AjLHJfmT+9hxwbtNRXAb24pGxKI+mr22gRQ7nDbqi/dQoWvFtqLhE3x6D1Sl0Y7mR
	0
X-Google-Smtp-Source: AGHT+IHYOf7G6CCC/WpXt7wf04NgE600a46ujZCW14kFOdpdY1FfSSehIjbad2g+Xr0NJDLNscsEVQ==
X-Received: by 2002:a05:6402:3784:b0:566:9fef:1ee9 with SMTP id et4-20020a056402378400b005669fef1ee9mr7994038edb.22.1710759893206;
        Mon, 18 Mar 2024 04:04:53 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Wei Liu ,
	Stefano Stabellini ,
	Julien Grall ,
	Volodymyr Babchuk ,
	Bertrand Marquis ,
	Michal Orzel ,
	Oleksii Kurochko ,
	Shawn Anastasio ,
	Konrad Rzeszutek Wilk ,
	Ross Lagerwall 
Subject: [PATCH 3/4] xen/virtual-region: Link the list build time
Date: Mon, 18 Mar 2024 11:04:41 +0000
Message-Id: <20240318110442.3653997-4-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20240318110442.3653997-1-andrew.cooper3@citrix.com>
References: <20240318110442.3653997-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Given 3 statically initialised objects, its easy to link the list at build
time.  There's no need to do it during runtime at boot (and with IRQs-off,
even).

As a consequence, register_virtual_region() can now move inside ifdef
CONFIG_LIVEPATCH like unregister_virtual_region().

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
CC: Wei Liu 
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Volodymyr Babchuk 
CC: Bertrand Marquis 
CC: Michal Orzel 
CC: Oleksii Kurochko 
CC: Shawn Anastasio 
CC: Konrad Rzeszutek Wilk 
CC: Ross Lagerwall 
---
 xen/common/virtual_region.c | 45 ++++++++++++++++++++++++-------------
 1 file changed, 30 insertions(+), 15 deletions(-)

diff --git a/xen/common/virtual_region.c b/xen/common/virtual_region.c
index eb9645daa99d..ad39bb74e15c 100644
--- a/xen/common/virtual_region.c
+++ b/xen/common/virtual_region.c
@@ -15,8 +15,19 @@ extern const struct bug_frame
     __start_bug_frames_2[], __stop_bug_frames_2[],
     __start_bug_frames_3[], __stop_bug_frames_3[];
 
+/*
+ * For the built-in regions, the double linked list can be constructed at
+ * build time.  Forward-declare the elements.
+ */
+static struct list_head virtual_region_list;
+static struct virtual_region core, core_init;
+
 static struct virtual_region core = {
-    .list = LIST_HEAD_INIT(core.list),
+    .list = {
+        .next = &core_init.list,
+        .prev = &virtual_region_list,
+    },
+
     .text_start = _stext,
     .text_end = _etext,
     .rodata_start = _srodata,
@@ -32,7 +43,11 @@ static struct virtual_region core = {
 
 /* Becomes irrelevant when __init sections are cleared. */
 static struct virtual_region core_init __initdata = {
-    .list = LIST_HEAD_INIT(core_init.list),
+    .list = {
+        .next = &virtual_region_list,
+        .prev = &core.list,
+    },
+
     .text_start = _sinittext,
     .text_end = _einittext,
 
@@ -50,7 +65,10 @@ static struct virtual_region core_init __initdata = {
  *
  * All readers of virtual_region_list MUST use list_for_each_entry_rcu.
  */
-static LIST_HEAD(virtual_region_list);
+static struct list_head virtual_region_list = {
+    .next = &core.list,
+    .prev = &core_init.list,
+};
 static DEFINE_SPINLOCK(virtual_region_lock);
 static DEFINE_RCU_READ_LOCK(rcu_virtual_region_lock);
 
@@ -73,15 +91,6 @@ const struct virtual_region *find_text_region(unsigned long addr)
     return region;
 }
 
-void register_virtual_region(struct virtual_region *r)
-{
-    unsigned long flags;
-
-    spin_lock_irqsave(&virtual_region_lock, flags);
-    list_add_tail_rcu(&r->list, &virtual_region_list);
-    spin_unlock_irqrestore(&virtual_region_lock, flags);
-}
-
 /*
  * Suggest inline so when !CONFIG_LIVEPATCH the function is not left
  * unreachable after init code is removed.
@@ -96,6 +105,15 @@ static void inline remove_virtual_region(struct virtual_region *r)
 }
 
 #ifdef CONFIG_LIVEPATCH
+void register_virtual_region(struct virtual_region *r)
+{
+    unsigned long flags;
+
+    spin_lock_irqsave(&virtual_region_lock, flags);
+    list_add_tail_rcu(&r->list, &virtual_region_list);
+    spin_unlock_irqrestore(&virtual_region_lock, flags);
+}
+
 void unregister_virtual_region(struct virtual_region *r)
 {
     remove_virtual_region(r);
@@ -155,9 +173,6 @@ void __init setup_virtual_regions(const struct exception_table_entry *start,
 {
     core_init.ex = core.ex = start;
     core_init.ex_end = core.ex_end = end;
-
-    register_virtual_region(&core_init);
-    register_virtual_region(&core);
 }
 
 /*
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 11:04:58 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 11:04:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694590.1083456 (Exim 4.92)
	(envelope-from )
	id 1rmAnY-0007vZ-1T; Mon, 18 Mar 2024 11:04:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694590.1083456; Mon, 18 Mar 2024 11:04:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmAnX-0007vS-UJ; Mon, 18 Mar 2024 11:04:55 +0000
Received: by outflank-mailman (input) for mailman id 694590;
 Mon, 18 Mar 2024 11:04:54 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmAnW-0007RX-Iz
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 11:04:54 +0000
Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com
 [2a00:1450:4864:20::230])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 58a83f6e-e517-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 12:04:53 +0100 (CET)
Received: by mail-lj1-x230.google.com with SMTP id
 38308e7fff4ca-2d46c44dcc0so51891901fa.2
 for ; Mon, 18 Mar 2024 04:04:52 -0700 (PDT)
Received: from andrewcoop.citrite.net (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 f22-20020aa7d856000000b0056b818544a9sm324882eds.90.2024.03.18.04.04.50
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 18 Mar 2024 04:04:51 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 58a83f6e-e517-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710759892; x=1711364692; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=6AClSgW20j4Oof9oRGR4px4rDSNwV8dwcCuptcu56/k=;
        b=ItN3jlNh7zJvOVQtMEbzjLKe5ggjLdecBcWzh9TNMph6Sp91s59laCHQzmLYi7W7GV
         LCYL/xYIt3G+RDDfjP2k2zm3zHNvAjF1B4tSEpaCNwSQmB/aYY9pCgXZXbfb0keft455
         Anq6hVDRngml8w3JlTXGcXepQEZt1kFxEhtYQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710759892; x=1711364692;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=6AClSgW20j4Oof9oRGR4px4rDSNwV8dwcCuptcu56/k=;
        b=CB/4+sQ1j0ekEQrf8kVAF4gTqV4O0p+hVqfWa/djqB1nRnSVHPac7hyPR7zu9O2qRp
         jx+qmr7H6R2kpjn+rjvGpmoqzDa90RspAdcvXVeXDJNJBXG4qCT6GmPBGIQ0Xb+ysWWV
         iVdxqrGLq6HkKG7wWUHslwzkvbyMmHJ2fteUIMUDlmxUI6TJEbtAmiP5/knBdWmFZZKs
         yEf2L5iIgcVSvwyAGBM5/zqB4uO28i0Ad1hQC7gCVlkXK37T3ELsidP5C1ca0UAbrclV
         ZRDP5Twqm3gzqErXZqhqC+QcpE+l7UAJq1MsTum0Iqrwpc9WxOkK+oWUMwjB0sDIINOn
         A8dA==
X-Gm-Message-State: AOJu0YzX3Qg5dY/oz/FnBYV9Tf8G7A4g66HRTNdwpE9rGGlsthPQNzn3
	HN+eSZElcaqrVNWAGAs8fheqj0x51Hn/najhs3/tpyOFDJYENDNTRfHUs+BAbV348IaObbFClI9
	V
X-Google-Smtp-Source: AGHT+IGjILct9cPcKheTXRHra5yIQEReuWJ6pyjCoLkoCxZHKBCtSluGbPbB5UYkJV5dQTWgacbxMg==
X-Received: by 2002:a2e:874d:0:b0:2d4:6863:5072 with SMTP id q13-20020a2e874d000000b002d468635072mr7615283ljj.44.1710759891920;
        Mon, 18 Mar 2024 04:04:51 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Wei Liu ,
	Stefano Stabellini ,
	Julien Grall ,
	Volodymyr Babchuk ,
	Bertrand Marquis ,
	Michal Orzel ,
	Oleksii Kurochko ,
	Shawn Anastasio ,
	Konrad Rzeszutek Wilk ,
	Ross Lagerwall 
Subject: [PATCH 2/4] xen/virtual-region: Rework how bugframe linkage works
Date: Mon, 18 Mar 2024 11:04:40 +0000
Message-Id: <20240318110442.3653997-3-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20240318110442.3653997-1-andrew.cooper3@citrix.com>
References: <20240318110442.3653997-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The start/stop1/etc linkage scheme predates struct virtual_region, and as
setup_virtual_regions() shows, it's awkward to express in the new scheme.

Change the linker to provide explicit start/stop symbols for each bugframe
type, and change virtual_region to have a stop pointer rather than a count.

This marginly simplifies both do_bug_frame()s and prepare_payload(), but it
massively simplifies setup_virtual_regions() by allowing the compiler to
initialise the .frame[] array at build time.

virtual_region.c is the only user of the linker symbols, and this is unlikely
to change given the purpose of struct virtual_region, so move their externs
out of bug.h

No functional change.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
CC: Wei Liu 
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Volodymyr Babchuk 
CC: Bertrand Marquis 
CC: Michal Orzel 
CC: Oleksii Kurochko 
CC: Shawn Anastasio 
CC: Konrad Rzeszutek Wilk 
CC: Ross Lagerwall 
---
 xen/arch/arm/traps.c             |  5 ++--
 xen/common/bug.c                 |  5 ++--
 xen/common/livepatch.c           |  7 +++--
 xen/common/virtual_region.c      | 45 ++++++++++++++------------------
 xen/include/xen/bug.h            |  6 -----
 xen/include/xen/virtual_region.h |  3 +--
 xen/include/xen/xen.lds.h        |  8 +++++-
 7 files changed, 35 insertions(+), 44 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 9cffe7f79005..a8039087c805 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1226,10 +1226,9 @@ int do_bug_frame(const struct cpu_user_regs *regs, vaddr_t pc)
         for ( id = 0; id < BUGFRAME_NR; id++ )
         {
             const struct bug_frame *b;
-            unsigned int i;
 
-            for ( i = 0, b = region->frame[id].bugs;
-                  i < region->frame[id].n_bugs; b++, i++ )
+            for ( b = region->frame[id].start;
+                  b < region->frame[id].stop; b++ )
             {
                 if ( ((vaddr_t)bug_loc(b)) == pc )
                 {
diff --git a/xen/common/bug.c b/xen/common/bug.c
index c43e7c439735..b7c5d8fd4d4a 100644
--- a/xen/common/bug.c
+++ b/xen/common/bug.c
@@ -25,10 +25,9 @@ int do_bug_frame(const struct cpu_user_regs *regs, unsigned long pc)
     for ( id = 0; id < BUGFRAME_NR; id++ )
     {
         const struct bug_frame *b;
-        size_t i;
 
-        for ( i = 0, b = region->frame[id].bugs;
-              i < region->frame[id].n_bugs; b++, i++ )
+        for ( b = region->frame[id].start;
+              b < region->frame[id].stop; b++ )
         {
             if ( bug_loc(b) == pc )
             {
diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
index cabfb6391117..351a3e0b9a60 100644
--- a/xen/common/livepatch.c
+++ b/xen/common/livepatch.c
@@ -804,12 +804,11 @@ static int prepare_payload(struct payload *payload,
         if ( !sec )
             continue;
 
-        if ( !section_ok(elf, sec, sizeof(*region->frame[i].bugs)) )
+        if ( !section_ok(elf, sec, sizeof(*region->frame[i].start)) )
             return -EINVAL;
 
-        region->frame[i].bugs = sec->load_addr;
-        region->frame[i].n_bugs = sec->sec->sh_size /
-                                  sizeof(*region->frame[i].bugs);
+        region->frame[i].start = sec->load_addr;
+        region->frame[i].stop  = sec->load_addr + sec->sec->sh_size;
     }
 
     sec = livepatch_elf_sec_by_name(elf, ".altinstructions");
diff --git a/xen/common/virtual_region.c b/xen/common/virtual_region.c
index b4325bcda71e..eb9645daa99d 100644
--- a/xen/common/virtual_region.c
+++ b/xen/common/virtual_region.c
@@ -9,12 +9,25 @@
 #include 
 #include 
 
+extern const struct bug_frame
+    __start_bug_frames_0[], __stop_bug_frames_0[],
+    __start_bug_frames_1[], __stop_bug_frames_1[],
+    __start_bug_frames_2[], __stop_bug_frames_2[],
+    __start_bug_frames_3[], __stop_bug_frames_3[];
+
 static struct virtual_region core = {
     .list = LIST_HEAD_INIT(core.list),
     .text_start = _stext,
     .text_end = _etext,
     .rodata_start = _srodata,
     .rodata_end = _erodata,
+
+    .frame = {
+        { __start_bug_frames_0, __stop_bug_frames_0 },
+        { __start_bug_frames_1, __stop_bug_frames_1 },
+        { __start_bug_frames_2, __stop_bug_frames_2 },
+        { __start_bug_frames_3, __stop_bug_frames_3 },
+    },
 };
 
 /* Becomes irrelevant when __init sections are cleared. */
@@ -22,6 +35,13 @@ static struct virtual_region core_init __initdata = {
     .list = LIST_HEAD_INIT(core_init.list),
     .text_start = _sinittext,
     .text_end = _einittext,
+
+    .frame = {
+        { __start_bug_frames_0, __stop_bug_frames_0 },
+        { __start_bug_frames_1, __stop_bug_frames_1 },
+        { __start_bug_frames_2, __stop_bug_frames_2 },
+        { __start_bug_frames_3, __stop_bug_frames_3 },
+    },
 };
 
 /*
@@ -133,31 +153,6 @@ void __init unregister_init_virtual_region(void)
 void __init setup_virtual_regions(const struct exception_table_entry *start,
                                   const struct exception_table_entry *end)
 {
-    size_t sz;
-    unsigned int i;
-    static const struct bug_frame *const __initconstrel bug_frames[] = {
-        __start_bug_frames,
-        __stop_bug_frames_0,
-        __stop_bug_frames_1,
-        __stop_bug_frames_2,
-        __stop_bug_frames_3,
-        NULL
-    };
-
-    for ( i = 1; bug_frames[i]; i++ )
-    {
-        const struct bug_frame *s;
-
-        s = bug_frames[i - 1];
-        sz = bug_frames[i] - s;
-
-        core.frame[i - 1].n_bugs = sz;
-        core.frame[i - 1].bugs = s;
-
-        core_init.frame[i - 1].n_bugs = sz;
-        core_init.frame[i - 1].bugs = s;
-    }
-
     core_init.ex = core.ex = start;
     core_init.ex_end = core.ex_end = end;
 
diff --git a/xen/include/xen/bug.h b/xen/include/xen/bug.h
index 77fe1e1ba840..99814c4bef36 100644
--- a/xen/include/xen/bug.h
+++ b/xen/include/xen/bug.h
@@ -155,12 +155,6 @@ int do_bug_frame(const struct cpu_user_regs *regs, unsigned long pc);
 
 #endif /* CONFIG_GENERIC_BUG_FRAME */
 
-extern const struct bug_frame __start_bug_frames[],
-                              __stop_bug_frames_0[],
-                              __stop_bug_frames_1[],
-                              __stop_bug_frames_2[],
-                              __stop_bug_frames_3[];
-
 #endif /* !__ASSEMBLY__ */
 
 #endif /* __XEN_BUG_H__ */
diff --git a/xen/include/xen/virtual_region.h b/xen/include/xen/virtual_region.h
index dcdc95ba494c..c8a90e3ef26d 100644
--- a/xen/include/xen/virtual_region.h
+++ b/xen/include/xen/virtual_region.h
@@ -29,8 +29,7 @@ struct virtual_region
     symbols_lookup_t *symbols_lookup;
 
     struct {
-        const struct bug_frame *bugs; /* The pointer to array of bug frames. */
-        size_t n_bugs;          /* The number of them. */
+        const struct bug_frame *start, *stop; /* Pointers to array of bug frames. */
     } frame[BUGFRAME_NR];
 
     const struct exception_table_entry *ex;
diff --git a/xen/include/xen/xen.lds.h b/xen/include/xen/xen.lds.h
index decd6db5fc6d..96f86ac58f38 100644
--- a/xen/include/xen/xen.lds.h
+++ b/xen/include/xen/xen.lds.h
@@ -105,13 +105,19 @@
 /* List of constructs other than *_SECTIONS in alphabetical order. */
 
 #define BUGFRAMES                               \
-    __start_bug_frames = .;                     \
+    __start_bug_frames_0 = .;                   \
     *(.bug_frames.0)                            \
     __stop_bug_frames_0 = .;                    \
+                                                \
+    __start_bug_frames_1 = .;                   \
     *(.bug_frames.1)                            \
     __stop_bug_frames_1 = .;                    \
+                                                \
+    __start_bug_frames_2 = .;                   \
     *(.bug_frames.2)                            \
     __stop_bug_frames_2 = .;                    \
+                                                \
+    __start_bug_frames_3 = .;                   \
     *(.bug_frames.3)                            \
     __stop_bug_frames_3 = .;
 
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 11:04:58 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 11:04:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694592.1083476 (Exim 4.92)
	(envelope-from )
	id 1rmAna-0008Rx-QS; Mon, 18 Mar 2024 11:04:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694592.1083476; Mon, 18 Mar 2024 11:04:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmAna-0008Ro-MD; Mon, 18 Mar 2024 11:04:58 +0000
Received: by outflank-mailman (input) for mailman id 694592;
 Mon, 18 Mar 2024 11:04:57 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmAnZ-0007RX-3u
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 11:04:57 +0000
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com
 [2a00:1450:4864:20::62e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5a40b7b6-e517-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 12:04:55 +0100 (CET)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-a466a1f9ea0so300097766b.1
 for ; Mon, 18 Mar 2024 04:04:55 -0700 (PDT)
Received: from andrewcoop.citrite.net (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 f22-20020aa7d856000000b0056b818544a9sm324882eds.90.2024.03.18.04.04.53
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 18 Mar 2024 04:04:53 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5a40b7b6-e517-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710759894; x=1711364694; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=LlCKlDfbOhZKV1J2ps7ot3moOOwpsbpj+o2HtA/2dsQ=;
        b=Ip1clXr2Dhfpc+rr4dbYtc7lovnNLe3WxpJ/Has1xw/8Iu2izlozTgwB5ldJyW6hdw
         a6+sJRyZ3Pi1MznlWCwvb7XETM2gY3PHZsQBAM+ZqSTmBY1G4XfYDNJU7wnreoHKXCuw
         7SMkB/Qpbcm/kqN/7wKds6DgmMTgEoV6Jpk70=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710759894; x=1711364694;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=LlCKlDfbOhZKV1J2ps7ot3moOOwpsbpj+o2HtA/2dsQ=;
        b=ZDKQde2GfKr6andkXfVUTcwhSaVc8nM5sr+TslgI89dbZjH6eAhdgrjVQXxkve9qsS
         dMY5HsfFuKwfvxLFApMzY0hwH9NrX5vGENiRDvAExKdbp79lVHl/bokwjIfmIQIq0c+D
         vwE4rhMWYfPiaex4Sumu+vqPIuotxUlIl/utlYp7dwhaWOCdF+8xPy4gD7mkfAItVBzs
         of8vlsWFvDJDy2I1/wtxQEcgnMJIT+YOhj1WN2XlyOEsDMBcUp/L9ObGzY5ZVYyNhf67
         +A4rKBUFT7ynn63iIJ1U+Esb6gIUiPg1xuJlJrCSY3gFK5GT2pZEKUxstKhWdfknYw+D
         iu2w==
X-Gm-Message-State: AOJu0YzKqyKgECnof3HJaal2SYkZNs1Uo4ob3vI1i6Ifw/RbizBfs0cA
	3yrS0qB9nKrVW30kYnisoOJ0igr0sfxZfB5PSgIReTejIoT+Z31DEH3n9wfbRhKY+uRYXb7As/Z
	J
X-Google-Smtp-Source: AGHT+IHMJ6j/otP77lTUgBDpwoiX+lsd05gj3mtFFuAjMNu82dHTyGRpN770FaBUz6STDrp4ntfLlQ==
X-Received: by 2002:a05:6402:1d34:b0:568:29f8:1d79 with SMTP id dh20-20020a0564021d3400b0056829f81d79mr4412379edb.38.1710759894351;
        Mon, 18 Mar 2024 04:04:54 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Wei Liu ,
	Stefano Stabellini ,
	Julien Grall ,
	Volodymyr Babchuk ,
	Bertrand Marquis ,
	Michal Orzel ,
	Oleksii Kurochko ,
	Shawn Anastasio ,
	Konrad Rzeszutek Wilk ,
	Ross Lagerwall 
Subject: [PATCH 4/4] xen/virtual-region: Drop setup_virtual_regions()
Date: Mon, 18 Mar 2024 11:04:42 +0000
Message-Id: <20240318110442.3653997-5-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20240318110442.3653997-1-andrew.cooper3@citrix.com>
References: <20240318110442.3653997-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

All other actions it used to perform have been converted to build-time
initialisation.  The extable setup can done at build time too.

This is one fewer setup step required to get exceptions working.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
CC: Wei Liu 
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Volodymyr Babchuk 
CC: Bertrand Marquis 
CC: Michal Orzel 
CC: Oleksii Kurochko 
CC: Shawn Anastasio 
CC: Konrad Rzeszutek Wilk 
CC: Ross Lagerwall 
---
 xen/arch/arm/setup.c             |  1 -
 xen/arch/x86/setup.c             |  2 --
 xen/common/virtual_region.c      | 17 ++++++++++-------
 xen/include/xen/virtual_region.h |  2 --
 4 files changed, 10 insertions(+), 12 deletions(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 424744ad5e1a..b9a7f61f73ef 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -719,7 +719,6 @@ void asmlinkage __init start_xen(unsigned long boot_phys_offset,
     percpu_init_areas();
     set_processor_id(0); /* needed early, for smp_processor_id() */
 
-    setup_virtual_regions(NULL, NULL);
     /* Initialize traps early allow us to get backtrace when an error occurred */
     init_traps();
 
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index a21984b1ccd8..801f5ca01a26 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1014,8 +1014,6 @@ void asmlinkage __init noreturn __start_xen(unsigned long mbi_p)
     smp_prepare_boot_cpu();
     sort_exception_tables();
 
-    setup_virtual_regions(__start___ex_table, __stop___ex_table);
-
     /* Full exception support from here on in. */
 
     rdmsrl(MSR_EFER, this_cpu(efer));
diff --git a/xen/common/virtual_region.c b/xen/common/virtual_region.c
index ad39bb74e15c..5322766ac765 100644
--- a/xen/common/virtual_region.c
+++ b/xen/common/virtual_region.c
@@ -39,6 +39,11 @@ static struct virtual_region core = {
         { __start_bug_frames_2, __stop_bug_frames_2 },
         { __start_bug_frames_3, __stop_bug_frames_3 },
     },
+
+#ifdef CONFIG_X86
+    .ex = __start___ex_table,
+    .ex_end = __stop___ex_table,
+#endif
 };
 
 /* Becomes irrelevant when __init sections are cleared. */
@@ -57,6 +62,11 @@ static struct virtual_region core_init __initdata = {
         { __start_bug_frames_2, __stop_bug_frames_2 },
         { __start_bug_frames_3, __stop_bug_frames_3 },
     },
+
+#ifdef CONFIG_X86
+    .ex = __start___ex_table,
+    .ex_end = __stop___ex_table,
+#endif
 };
 
 /*
@@ -168,13 +178,6 @@ void __init unregister_init_virtual_region(void)
     remove_virtual_region(&core_init);
 }
 
-void __init setup_virtual_regions(const struct exception_table_entry *start,
-                                  const struct exception_table_entry *end)
-{
-    core_init.ex = core.ex = start;
-    core_init.ex_end = core.ex_end = end;
-}
-
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/xen/virtual_region.h b/xen/include/xen/virtual_region.h
index c8a90e3ef26d..2c4deaaa2889 100644
--- a/xen/include/xen/virtual_region.h
+++ b/xen/include/xen/virtual_region.h
@@ -37,8 +37,6 @@ struct virtual_region
 };
 
 const struct virtual_region *find_text_region(unsigned long addr);
-void setup_virtual_regions(const struct exception_table_entry *start,
-                           const struct exception_table_entry *end);
 void unregister_init_virtual_region(void);
 void register_virtual_region(struct virtual_region *r);
 void unregister_virtual_region(struct virtual_region *r);
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 11:54:12 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 11:54:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694613.1083528 (Exim 4.92)
	(envelope-from )
	id 1rmBZ8-00023l-4n; Mon, 18 Mar 2024 11:54:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694613.1083528; Mon, 18 Mar 2024 11:54:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmBZ7-00023G-R3; Mon, 18 Mar 2024 11:54:05 +0000
Received: by outflank-mailman (input) for mailman id 694613;
 Mon, 18 Mar 2024 11:54:04 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmBZ6-0001F2-QP
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 11:54:04 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 368b82dd-e51e-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 12:54:02 +0100 (CET)
Received: from nico.bugseng.com (unknown [46.228.253.194])
 by support.bugseng.com (Postfix) with ESMTPSA id 7C43A4EE0747;
 Mon, 18 Mar 2024 12:54:01 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 368b82dd-e51e-11ee-a1ee-f123f15fe8a2
From: Nicola Vetrini 
To: nicola.vetrini@bugseng.com,
	xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org,
	michal.orzel@amd.com,
	xenia.ragiadakou@amd.com,
	ayan.kumar.halder@amd.com,
	consulting@bugseng.com,
	Jan Beulich 
Subject: [XEN PATCH 05/10] EFI: address violations of MISRA C Rule 20.7
Date: Mon, 18 Mar 2024 12:53:48 +0100
Message-Id: <66095ff2496d9b2be701877a3df762293fc8708b.1710762555.git.nicola.vetrini@bugseng.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter the semantics of the passed-in macro parameter.

No functional change.

Signed-off-by: Nicola Vetrini 
---
This file is matched by exclude-list.json, but the fix is rather trivial
and actually benefits code that is in scope for compliance.
---
 xen/include/efi/efierr.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/include/efi/efierr.h b/xen/include/efi/efierr.h
index dfd3d3cf4867..2ecde0b31302 100644
--- a/xen/include/efi/efierr.h
+++ b/xen/include/efi/efierr.h
@@ -22,7 +22,7 @@ Revision History
 
 
 #define EFIWARN(a)                            (a)
-#define EFI_ERROR(a)              (((INTN) a) < 0)
+#define EFI_ERROR(a)              (((INTN)(a)) < 0)
 
 
 #define EFI_SUCCESS                             0
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 11:54:12 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 11:54:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694618.1083582 (Exim 4.92)
	(envelope-from )
	id 1rmBZC-0003Zo-Rk; Mon, 18 Mar 2024 11:54:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694618.1083582; Mon, 18 Mar 2024 11:54:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmBZC-0003YJ-JQ; Mon, 18 Mar 2024 11:54:10 +0000
Received: by outflank-mailman (input) for mailman id 694618;
 Mon, 18 Mar 2024 11:54:08 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmBZA-0001F2-Qm
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 11:54:08 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 396893e5-e51e-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 12:54:07 +0100 (CET)
Received: from nico.bugseng.com (unknown [46.228.253.194])
 by support.bugseng.com (Postfix) with ESMTPSA id 3870D4EE0C8A;
 Mon, 18 Mar 2024 12:54:06 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 396893e5-e51e-11ee-a1ee-f123f15fe8a2
From: Nicola Vetrini 
To: nicola.vetrini@bugseng.com,
	xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org,
	michal.orzel@amd.com,
	xenia.ragiadakou@amd.com,
	ayan.kumar.halder@amd.com,
	consulting@bugseng.com,
	George Dunlap ,
	Dario Faggioli 
Subject: [XEN PATCH 10/10] xen/sched: address violations of MISRA C Rule 20.7
Date: Mon, 18 Mar 2024 12:53:53 +0100
Message-Id: <0c584c738f744a583497f1fb862d753836d8b249.1710762555.git.nicola.vetrini@bugseng.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter the semantics of the passed-in macro parameter.

No functional change.

Signed-off-by: Nicola Vetrini 
---
 xen/common/sched/private.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/common/sched/private.h b/xen/common/sched/private.h
index 459d1dfb11a5..c0e7c96d24f4 100644
--- a/xen/common/sched/private.h
+++ b/xen/common/sched/private.h
@@ -540,7 +540,7 @@ static inline void sched_unit_unpause(const struct sched_unit *unit)
 }
 
 #define REGISTER_SCHEDULER(x) static const struct scheduler *x##_entry \
-  __used_section(".data.schedulers") = &x
+  __used_section(".data.schedulers") = &(x)
 
 struct cpupool
 {
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 11:54:12 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 11:54:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694610.1083506 (Exim 4.92)
	(envelope-from )
	id 1rmBZ6-0001hx-RD; Mon, 18 Mar 2024 11:54:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694610.1083506; Mon, 18 Mar 2024 11:54:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmBZ6-0001hq-OO; Mon, 18 Mar 2024 11:54:04 +0000
Received: by outflank-mailman (input) for mailman id 694610;
 Mon, 18 Mar 2024 11:54:03 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmBZ5-0001F2-Db
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 11:54:03 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 34ff581b-e51e-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 12:53:59 +0100 (CET)
Received: from nico.bugseng.com (unknown [46.228.253.194])
 by support.bugseng.com (Postfix) with ESMTPSA id 2D5FD4EE073E;
 Mon, 18 Mar 2024 12:53:56 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 34ff581b-e51e-11ee-a1ee-f123f15fe8a2
From: Nicola Vetrini 
To: nicola.vetrini@bugseng.com,
	xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org,
	michal.orzel@amd.com,
	xenia.ragiadakou@amd.com,
	ayan.kumar.halder@amd.com,
	consulting@bugseng.com,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Wei Liu ,
	"Daniel P. Smith" ,
	Julien Grall ,
	Rahul Singh ,
	Bertrand Marquis ,
	Volodymyr Babchuk ,
	George Dunlap ,
	Dario Faggioli 
Subject: [XEN PATCH 00/10] address some violations of MISRA C Rule 20.7
Date: Mon, 18 Mar 2024 12:53:43 +0100
Message-Id: 
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Hi all,

this series aims to refactor some macros that cause violations of MISRA C Rule
20.7 ("Expressions resulting from the expansion of macro parameters shall be
enclosed in parentheses"). All the macros touched by these patches are in some
way involved in violations, and the strategy adopted to bring them into
compliance is to add parentheses around macro arguments where needed.

Given that the community has previously requested a deviation from the rule, as
stated in docs/misra/deviations.rst, and reported below for convenience [1],
some macro parameters do not need any adjusting (e.g., when used as lhs to
an assignment in statement expressions).

Note that the patch on list.h of the earlier series [2] has been intentionally
left out of this series, because it still needs some adjustments.

[1] - Code violating Rule 20.7 is safe when macro parameters are used:
       (1) as function arguments;
       (2) as macro arguments;
       (3) as array indices;
       (4) as lhs in assignments.
       
[2] https://lore.kernel.org/xen-devel/cover.1709896401.git.nicola.vetrini@bugseng.com/

Nicola Vetrini (10):
  x86/cpufeature: add parentheses to comply with Rule 20.7
  AMD/IOMMU: guest: address violations of MISRA C Rule 20.7
  xen/xsm: add parentheses to comply with MISRA C Rule 20.7
  xen/device_tree: address violations of MISRA C Rule 20.7
  EFI: address violations of MISRA C Rule 20.7
  xen/arm: smmu: address violations of MISRA C Rule 20.7
  xen/efi: efibind: address violations of MISRA C Rule 20.7
  xen/notifier: address violations of MISRA C Rule 20.7
  xen/wait: address violations of MISRA C Rule 20.7
  xen/sched: address violations of MISRA C Rule 20.7

 xen/arch/arm/include/asm/arm64/efibind.h  | 4 ++--
 xen/arch/x86/include/asm/cpufeatureset.h  | 2 +-
 xen/arch/x86/include/asm/x86_64/efibind.h | 4 ++--
 xen/common/sched/private.h                | 2 +-
 xen/drivers/passthrough/amd/iommu_guest.c | 2 +-
 xen/drivers/passthrough/arm/smmu.c        | 2 +-
 xen/include/efi/efierr.h                  | 2 +-
 xen/include/xen/device_tree.h             | 2 +-
 xen/include/xen/notifier.h                | 2 +-
 xen/include/xen/wait.h                    | 4 ++--
 xen/include/xsm/dummy.h                   | 4 ++--
 11 files changed, 15 insertions(+), 15 deletions(-)

-- 
2.34.1


From xen-devel-bounces@lists.xenproject.org Mon Mar 18 11:54:12 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 11:54:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694615.1083556 (Exim 4.92)
	(envelope-from )
	id 1rmBZA-0002v7-KF; Mon, 18 Mar 2024 11:54:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694615.1083556; Mon, 18 Mar 2024 11:54:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmBZA-0002uf-Eu; Mon, 18 Mar 2024 11:54:08 +0000
Received: by outflank-mailman (input) for mailman id 694615;
 Mon, 18 Mar 2024 11:54:06 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmBZ8-0001F2-QW
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 11:54:06 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 37a10472-e51e-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 12:54:04 +0100 (CET)
Received: from nico.bugseng.com (unknown [46.228.253.194])
 by support.bugseng.com (Postfix) with ESMTPSA id 0A9304EE0748;
 Mon, 18 Mar 2024 12:54:02 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 37a10472-e51e-11ee-a1ee-f123f15fe8a2
From: Nicola Vetrini 
To: nicola.vetrini@bugseng.com,
	xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org,
	michal.orzel@amd.com,
	xenia.ragiadakou@amd.com,
	ayan.kumar.halder@amd.com,
	consulting@bugseng.com,
	Julien Grall ,
	Bertrand Marquis ,
	Volodymyr Babchuk ,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Wei Liu 
Subject: [XEN PATCH 07/10] xen/efi: efibind: address violations of MISRA C Rule 20.7
Date: Mon, 18 Mar 2024 12:53:50 +0100
Message-Id: 
X-Mailer: git-send-email 2.34.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter the semantics of the passed-in macro parameter.

No functional change.

Signed-off-by: Nicola Vetrini 
---
This file is matched by exclude-list.json, but the fix is rather trivial
and impacts code that in under the scope of MISRA compliance.
---
 xen/arch/arm/include/asm/arm64/efibind.h  | 4 ++--
 xen/arch/x86/include/asm/x86_64/efibind.h | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/include/asm/arm64/efibind.h b/xen/arch/arm/include/asm/arm64/efibind.h
index f13eadd4f0ab..a1323d452e2e 100644
--- a/xen/arch/arm/include/asm/arm64/efibind.h
+++ b/xen/arch/arm/include/asm/arm64/efibind.h
@@ -22,9 +22,9 @@ Revision History
 #pragma pack()
 #endif
 
-#define EFIERR(a)           (0x8000000000000000ULL | a)
+#define EFIERR(a)           (0x8000000000000000ULL | (a))
 #define EFI_ERROR_MASK      0x8000000000000000ULL
-#define EFIERR_OEM(a)       (0xc000000000000000ULL | a)
+#define EFIERR_OEM(a)       (0xc000000000000000ULL | (a))
 
 #define BAD_POINTER         0xFBFBFBFBFBFBFBFBULL
 #define MAX_ADDRESS         0xFFFFFFFFFFFFFFFFULL
diff --git a/xen/arch/x86/include/asm/x86_64/efibind.h b/xen/arch/x86/include/asm/x86_64/efibind.h
index e23cd16cb6a0..28bc18c24bb3 100644
--- a/xen/arch/x86/include/asm/x86_64/efibind.h
+++ b/xen/arch/x86/include/asm/x86_64/efibind.h
@@ -117,9 +117,9 @@ typedef uint64_t   UINTN;
     #endif
 #endif
 
-#define EFIERR(a)           (0x8000000000000000 | a)
+#define EFIERR(a)           (0x8000000000000000 | (a))
 #define EFI_ERROR_MASK      0x8000000000000000
-#define EFIERR_OEM(a)       (0xc000000000000000 | a)
+#define EFIERR_OEM(a)       (0xc000000000000000 | (a))
 
 
 #define BAD_POINTER         0xFBFBFBFBFBFBFBFB
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 11:54:12 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 11:54:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694616.1083559 (Exim 4.92)
	(envelope-from )
	id 1rmBZA-0002z3-Um; Mon, 18 Mar 2024 11:54:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694616.1083559; Mon, 18 Mar 2024 11:54:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmBZA-0002xt-Nl; Mon, 18 Mar 2024 11:54:08 +0000
Received: by outflank-mailman (input) for mailman id 694616;
 Mon, 18 Mar 2024 11:54:06 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmBZ8-0001F3-PA
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 11:54:06 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 38e8a27b-e51e-11ee-afdd-a90da7624cb6;
 Mon, 18 Mar 2024 12:54:06 +0100 (CET)
Received: from nico.bugseng.com (unknown [46.228.253.194])
 by support.bugseng.com (Postfix) with ESMTPSA id 338494EE074B;
 Mon, 18 Mar 2024 12:54:05 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 38e8a27b-e51e-11ee-afdd-a90da7624cb6
From: Nicola Vetrini 
To: nicola.vetrini@bugseng.com,
	xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org,
	michal.orzel@amd.com,
	xenia.ragiadakou@amd.com,
	ayan.kumar.halder@amd.com,
	consulting@bugseng.com,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Wei Liu 
Subject: [XEN PATCH 09/10] xen/wait: address violations of MISRA C Rule 20.7
Date: Mon, 18 Mar 2024 12:53:52 +0100
Message-Id: <1d9f79590a224b4007f34a609b8024b36dd44a04.1710762555.git.nicola.vetrini@bugseng.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter the semantics of the passed-in macro parameter.

No functional change.

Signed-off-by: Nicola Vetrini 
---
 xen/include/xen/wait.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/include/xen/wait.h b/xen/include/xen/wait.h
index 6eb7667d9c7f..1c68bc564b09 100644
--- a/xen/include/xen/wait.h
+++ b/xen/include/xen/wait.h
@@ -40,12 +40,12 @@ do {                                            \
     if ( condition )                            \
         break;                                  \
     for ( ; ; ) {                               \
-        prepare_to_wait(&wq);                   \
+        prepare_to_wait(&(wq));                 \
         if ( condition )                        \
             break;                              \
         wait();                                 \
     }                                           \
-    finish_wait(&wq);                           \
+    finish_wait(&(wq));                         \
 } while (0)
 
 /* Private functions. */
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 11:54:12 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 11:54:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694617.1083567 (Exim 4.92)
	(envelope-from )
	id 1rmBZB-000350-GS; Mon, 18 Mar 2024 11:54:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694617.1083567; Mon, 18 Mar 2024 11:54:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmBZB-000335-5h; Mon, 18 Mar 2024 11:54:09 +0000
Received: by outflank-mailman (input) for mailman id 694617;
 Mon, 18 Mar 2024 11:54:07 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmBZ9-0001F2-Qm
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 11:54:07 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3846bc1c-e51e-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 12:54:05 +0100 (CET)
Received: from nico.bugseng.com (unknown [46.228.253.194])
 by support.bugseng.com (Postfix) with ESMTPSA id 192424EE0749;
 Mon, 18 Mar 2024 12:54:04 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3846bc1c-e51e-11ee-a1ee-f123f15fe8a2
From: Nicola Vetrini 
To: nicola.vetrini@bugseng.com,
	xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org,
	michal.orzel@amd.com,
	xenia.ragiadakou@amd.com,
	ayan.kumar.halder@amd.com,
	consulting@bugseng.com,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Wei Liu 
Subject: [XEN PATCH 08/10] xen/notifier: address violations of MISRA C Rule 20.7
Date: Mon, 18 Mar 2024 12:53:51 +0100
Message-Id: <5ea6d48a2af93c54693364eb5bfa7e575eb717a3.1710762555.git.nicola.vetrini@bugseng.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter the semantics of the passed-in macro parameter.

No functional change.

Signed-off-by: Nicola Vetrini 
---
 xen/include/xen/notifier.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/include/xen/notifier.h b/xen/include/xen/notifier.h
index 2a952484df43..05359e8a850d 100644
--- a/xen/include/xen/notifier.h
+++ b/xen/include/xen/notifier.h
@@ -34,7 +34,7 @@ struct notifier_head {
 };
 
 #define NOTIFIER_HEAD(name) \
-    struct notifier_head name = { .head = LIST_HEAD_INIT(name.head) }
+    struct notifier_head name = { .head = LIST_HEAD_INIT((name).head) }
 
 
 void notifier_chain_register(
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 11:54:12 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 11:54:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694609.1083492 (Exim 4.92)
	(envelope-from )
	id 1rmBZ5-0001Hx-Mk; Mon, 18 Mar 2024 11:54:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694609.1083492; Mon, 18 Mar 2024 11:54:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmBZ5-0001HD-Gc; Mon, 18 Mar 2024 11:54:03 +0000
Received: by outflank-mailman (input) for mailman id 694609;
 Mon, 18 Mar 2024 11:54:02 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmBZ4-0001F3-UO
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 11:54:02 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 35d9b533-e51e-11ee-afdd-a90da7624cb6;
 Mon, 18 Mar 2024 12:54:01 +0100 (CET)
Received: from nico.bugseng.com (unknown [46.228.253.194])
 by support.bugseng.com (Postfix) with ESMTPSA id 92BBE4EE0745;
 Mon, 18 Mar 2024 12:54:00 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 35d9b533-e51e-11ee-afdd-a90da7624cb6
From: Nicola Vetrini 
To: nicola.vetrini@bugseng.com,
	xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org,
	michal.orzel@amd.com,
	xenia.ragiadakou@amd.com,
	ayan.kumar.halder@amd.com,
	consulting@bugseng.com,
	"Daniel P. Smith" 
Subject: [XEN PATCH 03/10] xen/xsm: add parentheses to comply with MISRA C Rule 20.7
Date: Mon, 18 Mar 2024 12:53:46 +0100
Message-Id: <4eeb9be581e3fa07378f5a7deb23c9066474638b.1710762555.git.nicola.vetrini@bugseng.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter the semantics of the passed-in macro parameter.

No functional change.

Signed-off-by: Nicola Vetrini 
---
 xen/include/xsm/dummy.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 8671af1ba4d3..88039fdd227c 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -58,7 +58,7 @@ void __xsm_action_mismatch_detected(void);
 
 #define XSM_DEFAULT_ARG /* */
 #define XSM_DEFAULT_VOID void
-#define XSM_ASSERT_ACTION(def) xsm_default_t action = def; (void)action
+#define XSM_ASSERT_ACTION(def) xsm_default_t action = (def); (void)action
 
 #else /* CONFIG_XSM */
 
@@ -71,7 +71,7 @@ void __xsm_action_mismatch_detected(void);
 #define XSM_INLINE always_inline
 #define XSM_DEFAULT_ARG xsm_default_t action,
 #define XSM_DEFAULT_VOID xsm_default_t action
-#define XSM_ASSERT_ACTION(def) LINKER_BUG_ON(def != action)
+#define XSM_ASSERT_ACTION(def) LINKER_BUG_ON((def) != action)
 
 #endif /* CONFIG_XSM */
 
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 11:54:12 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 11:54:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694611.1083512 (Exim 4.92)
	(envelope-from )
	id 1rmBZ7-0001lK-7T; Mon, 18 Mar 2024 11:54:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694611.1083512; Mon, 18 Mar 2024 11:54:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmBZ7-0001kp-08; Mon, 18 Mar 2024 11:54:05 +0000
Received: by outflank-mailman (input) for mailman id 694611;
 Mon, 18 Mar 2024 11:54:03 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmBZ5-0001F2-KM
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 11:54:03 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3594ff97-e51e-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 12:54:00 +0100 (CET)
Received: from nico.bugseng.com (unknown [46.228.253.194])
 by support.bugseng.com (Postfix) with ESMTPSA id 17AE44EE073F;
 Mon, 18 Mar 2024 12:54:00 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3594ff97-e51e-11ee-a1ee-f123f15fe8a2
From: Nicola Vetrini 
To: nicola.vetrini@bugseng.com,
	xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org,
	michal.orzel@amd.com,
	xenia.ragiadakou@amd.com,
	ayan.kumar.halder@amd.com,
	consulting@bugseng.com,
	Jan Beulich ,
	Andrew Cooper 
Subject: [XEN PATCH 02/10] AMD/IOMMU: guest: address violations of MISRA C Rule 20.7
Date: Mon, 18 Mar 2024 12:53:45 +0100
Message-Id: 
X-Mailer: git-send-email 2.34.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter the semantics of the passed-in macro parameter.

No functional change.

Signed-off-by: Nicola Vetrini 
---
This local helper may disappear as a follow-up to [1], if the function that
remains there after the cleanup ends up being removed, so this patch has a slight
dependency on what follows up from that thread (in which case it can be dropped).

[1] https://lore.kernel.org/xen-devel/alpine.DEB.2.22.394.2403151724380.853156@ubuntu-linux-20-04-desktop/T/#m9474ad4f35830345a22acd4a665245f7085d4b46
---
 xen/drivers/passthrough/amd/iommu_guest.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/drivers/passthrough/amd/iommu_guest.c b/xen/drivers/passthrough/amd/iommu_guest.c
index 4c4252eea116..5bfaa48d9d65 100644
--- a/xen/drivers/passthrough/amd/iommu_guest.c
+++ b/xen/drivers/passthrough/amd/iommu_guest.c
@@ -30,7 +30,7 @@
 #define GUEST_ADDRESS_SIZE_6_LEVEL              0x2
 #define HOST_ADDRESS_SIZE_6_LEVEL               0x2
 
-#define reg_to_u64(reg) (((uint64_t)reg.hi << 32) | reg.lo )
+#define reg_to_u64(reg) (((uint64_t)((reg).hi << 32)) | (reg).lo )
 #define u64_to_reg(reg, val) \
     do \
     { \
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 11:54:12 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 11:54:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694608.1083485 (Exim 4.92)
	(envelope-from )
	id 1rmBZ5-0001FL-Cg; Mon, 18 Mar 2024 11:54:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694608.1083485; Mon, 18 Mar 2024 11:54:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmBZ5-0001FE-A1; Mon, 18 Mar 2024 11:54:03 +0000
Received: by outflank-mailman (input) for mailman id 694608;
 Mon, 18 Mar 2024 11:54:02 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmBZ4-0001F3-96
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 11:54:02 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3548f086-e51e-11ee-afdd-a90da7624cb6;
 Mon, 18 Mar 2024 12:54:00 +0100 (CET)
Received: from nico.bugseng.com (unknown [46.228.253.194])
 by support.bugseng.com (Postfix) with ESMTPSA id 6D7E04EE0742;
 Mon, 18 Mar 2024 12:53:59 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3548f086-e51e-11ee-afdd-a90da7624cb6
From: Nicola Vetrini 
To: nicola.vetrini@bugseng.com,
	xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org,
	michal.orzel@amd.com,
	xenia.ragiadakou@amd.com,
	ayan.kumar.halder@amd.com,
	consulting@bugseng.com,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Wei Liu 
Subject: [XEN PATCH 01/10] x86/cpufeature: add parentheses to comply with Rule 20.7
Date: Mon, 18 Mar 2024 12:53:44 +0100
Message-Id: 
X-Mailer: git-send-email 2.34.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter the semantics of the passed-in macro parameter.

No functional change.

Signed-off-by: Nicola Vetrini 
---
 xen/arch/x86/include/asm/cpufeatureset.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/x86/include/asm/cpufeatureset.h b/xen/arch/x86/include/asm/cpufeatureset.h
index f179229f192f..a9c51bc514a8 100644
--- a/xen/arch/x86/include/asm/cpufeatureset.h
+++ b/xen/arch/x86/include/asm/cpufeatureset.h
@@ -5,7 +5,7 @@
 
 #include 
 
-#define XEN_CPUFEATURE(name, value) X86_FEATURE_##name = value,
+#define XEN_CPUFEATURE(name, value) X86_FEATURE_##name = (value),
 enum {
 #include 
 #include 
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 11:54:12 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 11:54:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694614.1083543 (Exim 4.92)
	(envelope-from )
	id 1rmBZ9-0002W4-8z; Mon, 18 Mar 2024 11:54:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694614.1083543; Mon, 18 Mar 2024 11:54:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmBZ9-0002V4-2A; Mon, 18 Mar 2024 11:54:07 +0000
Received: by outflank-mailman (input) for mailman id 694614;
 Mon, 18 Mar 2024 11:54:05 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmBZ7-0001F2-QQ
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 11:54:05 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3701a563-e51e-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 12:54:03 +0100 (CET)
Received: from nico.bugseng.com (unknown [46.228.253.194])
 by support.bugseng.com (Postfix) with ESMTPSA id 4620D4EE0744;
 Mon, 18 Mar 2024 12:54:02 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3701a563-e51e-11ee-a1ee-f123f15fe8a2
From: Nicola Vetrini 
To: nicola.vetrini@bugseng.com,
	xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org,
	michal.orzel@amd.com,
	xenia.ragiadakou@amd.com,
	ayan.kumar.halder@amd.com,
	consulting@bugseng.com,
	Julien Grall ,
	Rahul Singh ,
	Bertrand Marquis ,
	Volodymyr Babchuk 
Subject: [XEN PATCH 06/10] xen/arm: smmu: address violations of MISRA C Rule 20.7
Date: Mon, 18 Mar 2024 12:53:49 +0100
Message-Id: <50ec3074772b0c58bef446d1c06aa41db04a66d0.1710762555.git.nicola.vetrini@bugseng.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter the semantics of the passed-in macro parameter.

No functional change.

Signed-off-by: Nicola Vetrini 
---
 xen/drivers/passthrough/arm/smmu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/drivers/passthrough/arm/smmu.c b/xen/drivers/passthrough/arm/smmu.c
index 83196057a937..f2cee82f553a 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -326,7 +326,7 @@ static struct iommu_group *iommu_group_get(struct device *dev)
  */
 #define ARM_SMMU_GR0_NS(smmu)						\
 	((smmu)->base +							\
-		((smmu->options & ARM_SMMU_OPT_SECURE_CFG_ACCESS)	\
+		(((smmu)->options & ARM_SMMU_OPT_SECURE_CFG_ACCESS)	\
 			? 0x400 : 0))
 
 /* Page table bits */
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 11:54:12 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 11:54:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694612.1083516 (Exim 4.92)
	(envelope-from )
	id 1rmBZ7-0001sM-F5; Mon, 18 Mar 2024 11:54:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694612.1083516; Mon, 18 Mar 2024 11:54:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmBZ7-0001qM-Ac; Mon, 18 Mar 2024 11:54:05 +0000
Received: by outflank-mailman (input) for mailman id 694612;
 Mon, 18 Mar 2024 11:54:03 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmBZ5-0001F2-R8
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 11:54:03 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 361da749-e51e-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 12:54:01 +0100 (CET)
Received: from nico.bugseng.com (unknown [46.228.253.194])
 by support.bugseng.com (Postfix) with ESMTPSA id 0C6044EE0746;
 Mon, 18 Mar 2024 12:54:01 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 361da749-e51e-11ee-a1ee-f123f15fe8a2
From: Nicola Vetrini 
To: nicola.vetrini@bugseng.com,
	xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org,
	michal.orzel@amd.com,
	xenia.ragiadakou@amd.com,
	ayan.kumar.halder@amd.com,
	consulting@bugseng.com,
	Julien Grall 
Subject: [XEN PATCH 04/10] xen/device_tree: address violations of MISRA C Rule 20.7
Date: Mon, 18 Mar 2024 12:53:47 +0100
Message-Id: <3845d2a318bdaab242a7fd67473b05198db1b111.1710762555.git.nicola.vetrini@bugseng.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter the semantics of the passed-in macro parameter.

No functional change.

Signed-off-by: Nicola Vetrini 
---
This patch uniforms the way these macros use parentheses, skipping the
already deviated cases of the lhs of an assignment. In principle, all
three could have the parentheses on the macro argument in the lhs added.
---
 xen/include/xen/device_tree.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 6fe2fa8b2123..e6287305a7b5 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -250,7 +250,7 @@ dt_find_interrupt_controller(const struct dt_device_match *matches);
     for ( pp = (dn)->properties; (pp) != NULL; pp = (pp)->next )
 
 #define dt_for_each_device_node(dt, dn)                     \
-    for ( dn = dt; (dn) != NULL; dn = (dn)->allnext )
+    for ( dn = (dt); (dn) != NULL; dn = (dn)->allnext )
 
 #define dt_for_each_child_node(dt, dn)                      \
     for ( dn = (dt)->child; (dn) != NULL; dn = (dn)->sibling )
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 12:00:56 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 12:00:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694646.1083596 (Exim 4.92)
	(envelope-from )
	id 1rmBfb-00009J-N5; Mon, 18 Mar 2024 12:00:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694646.1083596; Mon, 18 Mar 2024 12:00:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmBfb-00009C-KP; Mon, 18 Mar 2024 12:00:47 +0000
Received: by outflank-mailman (input) for mailman id 694646;
 Mon, 18 Mar 2024 12:00:46 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmBfa-0008VL-Ph
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 12:00:46 +0000
Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com
 [2607:f8b0:4864:20::231])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 26584048-e51f-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 13:00:45 +0100 (CET)
Received: by mail-oi1-x231.google.com with SMTP id
 5614622812f47-3c38bac4c50so170364b6e.1
 for ; Mon, 18 Mar 2024 05:00:45 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 26584048-e51f-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1710763244; x=1711368044; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=/pVtFyqZfvvBB1UYqatX5Ax0FSP5NTPHu/QejxaaD5Q=;
        b=bVvuhGVlnLpbtfLMKnFZUKFQ49nVc9Ifl8zXts8/fLoWWua+H64aHp2gW5hkH1QxB6
         hfc9OxQplOEJYEMbAhhMai1Rw/+CO8BPSgZBR4MdGObrsl/AOzPPuhOyRMuANc9djgHr
         P6DUGOmF2yJ6kWBeJSR7ecj4u9E16kv+3lkrg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710763244; x=1711368044;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=/pVtFyqZfvvBB1UYqatX5Ax0FSP5NTPHu/QejxaaD5Q=;
        b=trheFgAzHHJWkTtMHHkXYQuYPwPMc53JYuXISzy7fLKZTcc6X1ZMaK4Dzh5QnyI97c
         dBAvJhWIZBBW61O+LzvCbyoH+qT/D9Cn9JQeGhuT6h75eaq//hVtPsiwtEIu5Y1LkSMn
         0cVXY4gWNbWnaL3JqqaM4s8/tw0GcMu9oo1O6rBHGAWRIEtTfRRSAKcaBxQKwidcpMaE
         g4CVKuQpfNe/Tpir8ka/p35Wmn1u7Ntq8s9XvS6hyN5DF/HdJ2udtJN34dlcQPSYRd/e
         URd3reHzq0uj7n8RT0CVOXviUJfnjBLxpMo6Vixy5YwkwhPlLr+XjyJXFz4f1au7ZHe2
         9SKg==
X-Gm-Message-State: AOJu0Yy1JLD5g5MdCtJ6wrTNboPmrnjGgi2wG/MerBzcITpdOH/R5ZKc
	Zdzq7WuXSvtPASNBxs6Bpis+dPg6m7DQAfn/crjELw9Y3LWSP0uAWoi20WcWSx8E90QkvLc/Ho5
	DdpP5qjJR9/qHPW22bXAtQxFaybRLw+Lma12GMg==
X-Google-Smtp-Source: AGHT+IF1erhh6qPb2+vPFu3twX4R0XdL8tC9t4mIN+qiUJsNptDyJZLJgye46L0p3kwRSwhL0sG3gYzkGGA2p06RZgQ=
X-Received: by 2002:a05:6870:a68e:b0:221:ca43:604e with SMTP id
 i14-20020a056870a68e00b00221ca43604emr11685694oam.53.1710763243910; Mon, 18
 Mar 2024 05:00:43 -0700 (PDT)
MIME-Version: 1.0
References:  <0c584c738f744a583497f1fb862d753836d8b249.1710762555.git.nicola.vetrini@bugseng.com>
In-Reply-To: <0c584c738f744a583497f1fb862d753836d8b249.1710762555.git.nicola.vetrini@bugseng.com>
From: George Dunlap 
Date: Mon, 18 Mar 2024 12:00:33 +0000
Message-ID: 
Subject: Re: [XEN PATCH 10/10] xen/sched: address violations of MISRA C Rule 20.7
To: Nicola Vetrini 
Cc: xen-devel@lists.xenproject.org, sstabellini@kernel.org, 
	michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, 
	consulting@bugseng.com, Dario Faggioli 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Mar 18, 2024 at 11:54=E2=80=AFAM Nicola Vetrini
 wrote:
>
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be safe with respect to expansions that
> can possibly alter the semantics of the passed-in macro parameter.
>
> No functional change.
>
> Signed-off-by: Nicola Vetrini 
> ---
>  xen/common/sched/private.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/xen/common/sched/private.h b/xen/common/sched/private.h
> index 459d1dfb11a5..c0e7c96d24f4 100644
> --- a/xen/common/sched/private.h
> +++ b/xen/common/sched/private.h
> @@ -540,7 +540,7 @@ static inline void sched_unit_unpause(const struct sc=
hed_unit *unit)
>  }
>
>  #define REGISTER_SCHEDULER(x) static const struct scheduler *x##_entry \
> -  __used_section(".data.schedulers") =3D &x
> +  __used_section(".data.schedulers") =3D &(x)

Arguably this is safe, because any `x` which would be problematic in
this line wouldn't compile in the line above.

But it's almost certainly not worth the effort of documenting or deviating,=
 so:

Acked-by: George Dunlap 


From xen-devel-bounces@lists.xenproject.org Mon Mar 18 12:02:58 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 12:02:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694651.1083606 (Exim 4.92)
	(envelope-from )
	id 1rmBhh-0000oQ-2S; Mon, 18 Mar 2024 12:02:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694651.1083606; Mon, 18 Mar 2024 12:02:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmBhg-0000oJ-Vm; Mon, 18 Mar 2024 12:02:56 +0000
Received: by outflank-mailman (input) for mailman id 694651;
 Mon, 18 Mar 2024 12:02:56 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmBhg-0000oD-6G
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 12:02:56 +0000
Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com
 [2a00:1450:4864:20::336])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 741f7692-e51f-11ee-afdd-a90da7624cb6;
 Mon, 18 Mar 2024 13:02:55 +0100 (CET)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-413f1853bf3so28840035e9.0
 for ; Mon, 18 Mar 2024 05:02:55 -0700 (PDT)
Received: from perard.uk.xensource.com (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 t20-20020a05600c199400b004132ae838absm14793489wmq.43.2024.03.18.05.02.53
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 18 Mar 2024 05:02:54 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 741f7692-e51f-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1710763374; x=1711368174; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=zw2EktgE+5/3X3GE505EIk99kT1ap2KZKgZaaJMsPhk=;
        b=XE2Lp+Fq8jJM5EYDQWaz1wQHL4LvkXun3l4/KRZLJr9J/ZDVcS/OfY321TjSltKhAN
         hZlBxgZKd0oC7V+NHPlAqhF9mLYCMCkCOQ53gl84dx4d2JPN/VoF1+LYFfJKSQZIAx8K
         WTu4pmBHIszFzTQZYq7vIVXzDH3cPwNIDSLvU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710763374; x=1711368174;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=zw2EktgE+5/3X3GE505EIk99kT1ap2KZKgZaaJMsPhk=;
        b=YTZI007XLCwF2tmH8A/ob+tGqAj8woVSUVOH8vDgcuOJfUoXdi6c+7YZd1HVYOnSu0
         rUUewxeyPVmdSrrUhTK8I3f3CV0/EAnLYZEyxFuduR441WWf83jnsrqUNR53b18c2drb
         NISs2u6RQHucDpcPi/KT9RhWzAgBzHLhW6TR/l64RE4zEo5ILZd0xEPPVTLGtLN8a5Ti
         erlRKDzRXnaSl4OuxJCV4fT0zCQdcnqMn2ixse8exOjjet5cCKw+IijsHceIeca5tsO5
         tFI4HDu2yEpgDfExH4Yulz7BlSgBdX6CtXyqty5En5v8rifMatBW27RfD4V9c8VEbdi9
         3fJw==
X-Gm-Message-State: AOJu0YzNuJraAFc2lplzoxBcGyoq8oaxqCYXfK5kHki/P3F3/KSPC8po
	mR1RUSUmhWaBxbauxAyPt87t6rRnZA6oDBkNCUrjRzZzug38VOSkcd071+neeEU=
X-Google-Smtp-Source: AGHT+IH1Xeji7NT5Hr7hdguPclUtPwKCiCfGpR9kBBlsVbliHOJkp5sg4zsaLriPiVqdNB2hDsb0Hg==
X-Received: by 2002:a05:600c:3150:b0:413:f80f:9a5 with SMTP id h16-20020a05600c315000b00413f80f09a5mr8262467wmo.5.1710763374582;
        Mon, 18 Mar 2024 05:02:54 -0700 (PDT)
Date: Mon, 18 Mar 2024 12:02:53 +0000
From: Anthony PERARD 
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= 
Cc: xen-devel@lists.xenproject.org
Subject: Re: [OSSTEST PATCH v2 0/3] Switch to Linux 6.1 by default on x86
Message-ID: <73baa2f3-4ce1-4611-8633-cc024a42d0c9@perard>
References: <20240315154849.28819-1-anthony.perard@citrix.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Mon, Mar 18, 2024 at 11:42:43AM +0100, Roger Pau Monn wrote:
> On Fri, Mar 15, 2024 at 03:48:46PM +0000, Anthony PERARD wrote:
> > Anthony PERARD (3):
> >   make-fligh: Fix freebsd guest test test-id
> >   mfi-common: Rework toolstack-disk_format test matrix
> >   ap-common: Switch to Linux 6.1 by default on x86 + drop dom0 i386
> 
> Acked-by: Roger Pau Monn 

Pushed.

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Mon Mar 18 12:22:06 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 12:22:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694656.1083616 (Exim 4.92)
	(envelope-from )
	id 1rmC07-0004Sh-Ha; Mon, 18 Mar 2024 12:21:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694656.1083616; Mon, 18 Mar 2024 12:21:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmC07-0004Sa-EF; Mon, 18 Mar 2024 12:21:59 +0000
Received: by outflank-mailman (input) for mailman id 694656;
 Mon, 18 Mar 2024 12:21:58 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmC06-0004SU-5N
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 12:21:58 +0000
Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com
 [2607:f8b0:4864:20::730])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1bf9072e-e522-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 13:21:56 +0100 (CET)
Received: by mail-qk1-x730.google.com with SMTP id
 af79cd13be357-789e6f7f748so165495885a.3
 for ; Mon, 18 Mar 2024 05:21:56 -0700 (PDT)
Received: from [10.80.67.23] (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 e7-20020a05620a12c700b00789ea49fd22sm2437045qkl.49.2024.03.18.05.21.53
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 18 Mar 2024 05:21:54 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1bf9072e-e522-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710764515; x=1711369315; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=98xrJ4tASlah8xufYKmqEE73Ggve4q4kDHL4pwkBFFg=;
        b=l57I2tciupYKPElqvFeBfvKbZeBXQqPWsvfjULHQz0XOPjx7rc63rxL4cuHeg9wGpI
         3zzoO081J8IAQBA9pvoEyX7lcNtCsxhUSN+Lz0QFrQu2Xlp6eEyApbKDapqx/PzaxTZi
         ggDJIfTZltu4DpM8YinUakZrF73QwNiRneb58=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710764515; x=1711369315;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=98xrJ4tASlah8xufYKmqEE73Ggve4q4kDHL4pwkBFFg=;
        b=ijUJpdglqOJUdCxeXyF+cPYDIQwZqULdSGfyuYH56KhKCTBa/hwbZTlGCrBM7msGQ2
         uiKQprJhdHlBIDJdmrpcMnrtbD185S2LunHB8GK6yHLQ5lqCxfuX49cMmwIrEol3z7sZ
         QATG0O4jNr0BozpiQUIuarCs3lH9La31f7JYZOZFL7V8LuNpmDGx7DWFLHgpuxuR2UJ5
         H5ROmej6Gdydpj93RILowBdpi6eJks0b9XAs6meVK1dTSU3HKuFwJUoQRtMz4S2GfFfz
         9hfDsFdxTDkkSHkUXiaRVKvWhg98+GX+iawYk/Y5sMwn/uGP+K4kBI7UV8PzlC8upayw
         upNQ==
X-Forwarded-Encrypted: i=1; AJvYcCXcTy/8So/3yDeQqEuQ+kPAHLq9JX5MPA8PIpUsktAVWYLa8C7Hj8ECrkc7mAtRxayVqFRBRpxJvXPXDQi+9huvzvtTx+0Ta4uEJTNCKlc=
X-Gm-Message-State: AOJu0Yx40q9+EJNzyC/wYUQlK4yWgMf+RsJPasZsq7sfqlyQabcTrcqi
	R/97X6xJsd1VPzgdVkAChjFY5g8saWbx1mIo82WTM0GhzuIIA/0tIDiZg4PPJuc=
X-Google-Smtp-Source: AGHT+IG/B6EpVZ7mTbxVkwy1x8aWhQB/0MOSsAnpcLBBXouCROaJYhVGXRLwIphI2b6FT9CIjp+Okw==
X-Received: by 2002:a05:620a:c93:b0:78a:10c:fa2f with SMTP id q19-20020a05620a0c9300b0078a010cfa2fmr2605377qki.39.1710764515008;
        Mon, 18 Mar 2024 05:21:55 -0700 (PDT)
Message-ID: <31220753-95bf-4742-a2ab-dfb4f814abdf@citrix.com>
Date: Mon, 18 Mar 2024 12:21:52 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/mm: use block_lock_speculation() in _mm_write_lock()
Content-Language: en-GB
To: Jan Beulich ,
 "xen-devel@lists.xenproject.org" 
Cc: Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , George Dunlap 
References: 
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 18/03/2024 10:54 am, Jan Beulich wrote:
> I can only guess that using block_speculation() there was a leftover
> from, earlier on, SPECULATIVE_HARDEN_LOCK depending on
> SPECULATIVE_HARDEN_BRANCH.
>
> Fixes: 197ecd838a2a ("locking: attempt to ensure lock wrappers are always inline")
> Signed-off-by: Jan Beulich 

Yes, it looks that way.

Reviewed-by: Andrew Cooper 


From xen-devel-bounces@lists.xenproject.org Mon Mar 18 12:27:55 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 12:27:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694659.1083626 (Exim 4.92)
	(envelope-from )
	id 1rmC5n-00053d-4l; Mon, 18 Mar 2024 12:27:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694659.1083626; Mon, 18 Mar 2024 12:27:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmC5n-00053W-1Q; Mon, 18 Mar 2024 12:27:51 +0000
Received: by outflank-mailman (input) for mailman id 694659;
 Mon, 18 Mar 2024 12:27:49 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmC5l-00053Q-C6
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 12:27:49 +0000
Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com
 [2607:f8b0:4864:20::f35])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ed6246a7-e522-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 13:27:47 +0100 (CET)
Received: by mail-qv1-xf35.google.com with SMTP id
 6a1803df08f44-690b24973beso43511296d6.0
 for ; Mon, 18 Mar 2024 05:27:47 -0700 (PDT)
Received: from [10.80.67.23] (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 jo4-20020a056214500400b00696147f229fsm1552831qvb.83.2024.03.18.05.27.44
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 18 Mar 2024 05:27:45 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ed6246a7-e522-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710764866; x=1711369666; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:subject:from:user-agent:mime-version:date
         :message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=7Dqy3uGGUTCCJ04acWTfAoJy8UG8EAW2DBMPEf+PuuY=;
        b=pgle5gptn6HecOOHP4HDDKnikDTjurOVZh9gGp8HxMuDi3OhczQlK5j6Ptu3CrKVgL
         UAidy6OPjn8SDoves1YaVBy6LCv2i0dJfmybhn7R2HdX50bIqG/eJia65dQPX6ccBEtO
         Su9i+EkiFENFt5Qt8JN04ixLN6IsgiHjLkKwc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710764866; x=1711369666;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:subject:from:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=7Dqy3uGGUTCCJ04acWTfAoJy8UG8EAW2DBMPEf+PuuY=;
        b=joo/EJ4dtc6GXUCHf69hLH3v75ppt1fdEclRqn2+MrExw3btiP0ETcLhU40TJXKcDU
         IGNyzACJMtOI1SeE+4rfw7hkt1FKsfR1u17Q1TX/AZWelOrCjtAzjkRjdsek3ZWcORzz
         WMGKHYmdfiXJfUCFA1JHWNDEr0xikqNA9dCBuafzb0D4Cr2eg6BKSjrrcBNC1uXNKWrF
         9mTahoYhEbI6Qtm8ca4x1Gt80rnjTdL9Elbs1K+JJbpnyEjAzpJ4fWhFGAK1sWZ+lV04
         5zizQhuMKqKsBqWIOfh3zerytYijI0aOetJWDInZJIE1CEoD2uvSFcz+BEOFU6B6X89W
         r6tA==
X-Forwarded-Encrypted: i=1; AJvYcCXpsjZEglNjDdJQlWOInoenoPnqrD0St0b91mPHep3oGNvS0G02P2u5VW0axscOgbE3T9DM6pw78/81iwcKBKbpNlvoS2zl2Fy6QG/GiTA=
X-Gm-Message-State: AOJu0Yy/I7bjU8gHlGbkAPayb3oRomoF6TrIO/OWeDpmVRF8szCv0FTA
	sE7HbgIGCEzLdJEnJyzPRYx47dmf5NwGEkpms5ZY2q3kFEyLHRlzjuwj4UuRMwU=
X-Google-Smtp-Source: AGHT+IHQYRWvquMY99FoEEq6TMEPjL4BHr2fO6YqBLzxWEBlz8HILXUMSDhBdyCh6SNWpaC7L6lohA==
X-Received: by 2002:a0c:8ec7:0:b0:691:497a:334 with SMTP id y7-20020a0c8ec7000000b00691497a0334mr19268365qvb.2.1710764866433;
        Mon, 18 Mar 2024 05:27:46 -0700 (PDT)
Message-ID: <2b40f2d6-9096-4e14-bdb3-e218bc3919fa@citrix.com>
Date: Mon, 18 Mar 2024 12:27:42 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Andrew Cooper 
Subject: Re: [PATCH 6/7] xen: Swap find_first_set_bit() for ffsl() - 1
To: Jan Beulich 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Wei Liu , Stefano Stabellini ,
 Julien Grall , Volodymyr Babchuk
 , Bertrand Marquis ,
 Michal Orzel ,
 Oleksii Kurochko ,
 Shawn Anastasio ,
 "consulting @ bugseng . com" ,
 Simone Ballarin ,
 Federico Serafini ,
 Nicola Vetrini ,
 Xen-devel 
References: <20240313172716.2325427-1-andrew.cooper3@citrix.com>
 <20240313172716.2325427-7-andrew.cooper3@citrix.com>
 
 <1356dd16-03e1-4c01-9aac-597a127dea85@citrix.com>
 
 
Content-Language: en-GB
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 18/03/2024 9:13 am, Jan Beulich wrote:
> On 14.03.2024 19:51, Andrew Cooper wrote:
>> On 14/03/2024 6:47 pm, Andrew Cooper wrote:
>>> On 14/03/2024 2:30 pm, Jan Beulich wrote:
>>>> On 13.03.2024 18:27, Andrew Cooper wrote:
>>>>> --- a/xen/drivers/passthrough/x86/iommu.c
>>>>> +++ b/xen/drivers/passthrough/x86/iommu.c
>>>>> @@ -641,7 +641,7 @@ struct page_info *iommu_alloc_pgtable(struct domain_iommu *hd,
>>>>>      if ( contig_mask )
>>>>>      {
>>>>>          /* See pt-contig-markers.h for a description of the marker scheme. */
>>>>> -        unsigned int i, shift = find_first_set_bit(contig_mask);
>>>>> +        unsigned int i, shift = ffsl(contig_mask) - 1;
>>>> The need for subtracting 1 is why personally I dislike ffs() / ffsl() (and
>>>> why I think find_first_set_bit() and __ffs() (but no __ffsl()) were
>>>> introduced).
>>> It's sad that there are competing APIs with different bit-labelling, but
>>> the optimiser does cancel the -1 with arch_ffs() (for at least x86 and
>>> ARM that I studied in detail).
>>>
>>> I firmly believe that fewer APIs which are fully well defined (and can
>>> optimise based on the compiler's idea of safety) is still better than a
>>> maze of APIs with different behaviours.
> I agree here. The anomaly (as I would call it) with ffs(), though, is what
> makes me wonder whether we might not be better off introducing ctz() and
> clz() instead. Unlike ffs() their name says exactly what is meant. This is
> then also a clear hint, for Arm and RISC-V at least, what underlying
> instruction is used. Plus there are matching builtins (unlike for e.g.
> fls()).

I considered this, but I think it will be a bad idea.

Right now, almost all of our logic is expressed in terms of
ffs()/fls().  Rearranging this to clz/ctz is risky enough on its own,
let alone the potential for mistakes during backport.

Both ffs() and fls() are well defined for all inputs, and I've found a
way to let the optimiser deal with simplifying things when safe to do so.

Therefore, keeping ffs()/fls() is the right thing to do.  It's harder to
shoot yourself in the foot with, and optimiser can still do an good job
in the general case.

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon Mar 18 12:55:06 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 12:55:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694666.1083636 (Exim 4.92)
	(envelope-from )
	id 1rmCW3-0001WV-3O; Mon, 18 Mar 2024 12:54:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694666.1083636; Mon, 18 Mar 2024 12:54:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmCW3-0001WO-07; Mon, 18 Mar 2024 12:54:59 +0000
Received: by outflank-mailman (input) for mailman id 694666;
 Mon, 18 Mar 2024 12:54:57 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmCW1-0001WC-PZ; Mon, 18 Mar 2024 12:54:57 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmCW1-0000ne-4u; Mon, 18 Mar 2024 12:54:57 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmCW0-0001c3-MT; Mon, 18 Mar 2024 12:54:56 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rmCW0-000461-M2; Mon, 18 Mar 2024 12:54:56 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=m2wx08pEBA+APw2aDaAAg0i1z8DK+QHdnxM4kl+hRH4=; b=Sya90Ioqc33T/G+w/u7vlKxuv0
	SB8luoHALF4a6HZslnmq7vytUuLW5+GDL8KvBP5bhI/5b/NMQ5CnpueyG05F99rfKLuUFr2MezzTq
	FKI0glJE3mVg1ot9CGJP2kfviCTqlK6vfuDv6M4Ur52qGL8JNsRlhneDOBquVRLYctYo=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-5.4 test] 185071: regressions - FAIL
X-Osstest-Failures:
    linux-5.4:test-armhf-armhf-xl-credit1:guest-start/debian.repeat:fail:regression
    linux-5.4:test-armhf-armhf-libvirt-qcow2:guest-start/debian.repeat:fail:heisenbug
    linux-5.4:test-armhf-armhf-xl-credit2:guest-start:fail:heisenbug
    linux-5.4:test-amd64-i386-xl-qemut-debianhvm-i386-xsm:debian-hvm-install:fail:heisenbug
    linux-5.4:test-armhf-armhf-xl:guest-start/debian.repeat:fail:heisenbug
    linux-5.4:test-armhf-armhf-xl-multivcpu:guest-start/debian.repeat:fail:heisenbug
    linux-5.4:test-armhf-armhf-xl-credit1:guest-start:fail:heisenbug
    linux-5.4:test-armhf-armhf-xl-rtds:guest-start:fail:heisenbug
    linux-5.4:test-arm64-arm64-libvirt-raw:guest-start/debian.repeat:fail:heisenbug
    linux-5.4:test-armhf-armhf-libvirt-qcow2:guest-start:fail:heisenbug
    linux-5.4:test-armhf-armhf-xl-vhd:guest-start/debian.repeat:fail:heisenbug
    linux-5.4:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    linux-5.4:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
    linux-5.4:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    linux-5.4:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-5.4:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    linux-5.4:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-5.4:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    linux-5.4:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
    linux-5.4:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    linux-5.4:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    linux-5.4:test-amd64-i386-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-5.4:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    linux=84075826304f1a297838de6bcfd9bd84f566026e
X-Osstest-Versions-That:
    linux=3fec063b052e395f4920fbc59a8d0bb3c9666d76
From: osstest service owner 
Date: Mon, 18 Mar 2024 12:54:56 +0000

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-credit1 18 guest-start/debian.repeat fail in 185063 REGR. vs. 184921

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt-qcow2 17 guest-start/debian.repeat fail in 185058 pass in 185063
 test-armhf-armhf-xl-credit2  14 guest-start      fail in 185058 pass in 185071
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail in 185058 pass in 185071
 test-armhf-armhf-xl 18 guest-start/debian.repeat fail in 185063 pass in 185071
 test-armhf-armhf-xl-multivcpu 18 guest-start/debian.repeat fail pass in 185058
 test-armhf-armhf-xl-credit1  14 guest-start                fail pass in 185063
 test-armhf-armhf-xl-rtds     14 guest-start                fail pass in 185063
 test-arm64-arm64-libvirt-raw 17 guest-start/debian.repeat  fail pass in 185063
 test-armhf-armhf-libvirt-qcow2 13 guest-start              fail pass in 185063
 test-armhf-armhf-xl-vhd      17 guest-start/debian.repeat  fail pass in 185063

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

version targeted for testing:
 linux                84075826304f1a297838de6bcfd9bd84f566026e
baseline version:
 linux                3fec063b052e395f4920fbc59a8d0bb3c9666d76

Last test of basis   184921  2024-03-06 14:47:02 Z   11 days
Testing same since   185054  2024-03-15 19:18:15 Z    2 days    5 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Morton 
  Andy Shevchenko 
  Andy Shevchenko 
  Ansuel Smith 
  Arnd Bergmann 
  Bjorn Andersson 
  Bjorn Andersson 
  Chandan Kumar Rout  (A Contingent Worker at Intel)
  Cosmin Tanislav 
  David S. Miller 
  Dexuan Cui 
  Dmitry Torokhov 
  Dylan Hatch 
  Edward Adam Davis 
  Eric Dumazet 
  Florian Fainelli 
  Florian Westphal 
  Greg Kroah-Hartman 
  Haiyang Zhang 
  Harshit Mogalapalli 
  Hugo Villeneuve 
  Jakub Kicinski 
  Jan Kundrát 
  Jason Xing 
  Johan Hovold 
  Johannes Berg 
  John Efstathiades 
  Juhee Kang 
  Lena Wang 
  Lina Iyer 
  Linux Kernel Functional Testing 
  Maciej Fijalkowski 
  Magnus Karlsson 
  Marek Vasut 
  Mark Brown 
  Nico Pache 
  Oleg Nesterov 
  Oleksij Rempel 
  Pablo Neira Ayuso 
  Paolo Abeni 
  Rand Deeb 
  Richard Weinberger 
  Sasha Levin 
  Shachar Raindel 
  Shradha Gupta 
  Stephen Hemminger 
  Tony Nguyen 
  Werner Sembach 

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-i386-examine-bios                                 pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  fail    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-armhf-armhf-libvirt-qcow2                               fail    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-arm64-arm64-libvirt-raw                                 fail    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-libvirt-raw                                  pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     fail    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-i386-examine-uefi                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-arm64-arm64-xl-vhd                                      pass    
 test-armhf-armhf-xl-vhd                                      fail    
 test-amd64-i386-xl-vhd                                       pass    


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

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

Explanation of these 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 1433 lines long.)


From xen-devel-bounces@lists.xenproject.org Mon Mar 18 13:05:34 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 13:05:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694680.1083677 (Exim 4.92)
	(envelope-from )
	id 1rmCg4-0003tC-Ed; Mon, 18 Mar 2024 13:05:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694680.1083677; Mon, 18 Mar 2024 13:05:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmCg4-0003t5-Bs; Mon, 18 Mar 2024 13:05:20 +0000
Received: by outflank-mailman (input) for mailman id 694680;
 Mon, 18 Mar 2024 13:05:19 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmCg3-0003sx-7S
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 13:05:19 +0000
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com
 [2a00:1450:4864:20::52a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2b11915b-e528-11ee-afdd-a90da7624cb6;
 Mon, 18 Mar 2024 14:05:18 +0100 (CET)
Received: by mail-ed1-x52a.google.com with SMTP id
 4fb4d7f45d1cf-566e869f631so4836333a12.0
 for ; Mon, 18 Mar 2024 06:05:18 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 lc17-20020a170906dff100b00a46bdffd002sm1164722ejc.158.2024.03.18.06.05.16
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 18 Mar 2024 06:05:17 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2b11915b-e528-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710767117; x=1711371917; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=2MKvWL+Y6y7QZUtCQnQugGOSxbO7LN9Yha4cAfbYvIo=;
        b=c9sAT5/N6T/gv8ZJGNG8GchIyc9lvDMw4mbjwWZ5cvusU6BzuPTFhg0iInNIv2kUoY
         ee+P3V0/Q9uwT9Fusjqc9jEH7/mwdxpGQOM65KnO0WJyV1ePEtwTsFpvQOYDaDg+QAjg
         FfUUibJqnDjX1h51u9hC+ACXyvTeTWY2y/sxVYtqZHuu7P1LKONK7qCNeQh2iHznJ4DJ
         U+UiG5PuBq02lsqUR369mBTc5zTC6v15wiW05/Z0CcV3AWXCFwUEckZ1TIufn77dhzJC
         2knYr54pTiX8FO5GJhOISb9d6GHwXI2bXLRdKafRRSqFUHvWqesESmKrd9HmB8aBtZoP
         TiGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710767117; x=1711371917;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=2MKvWL+Y6y7QZUtCQnQugGOSxbO7LN9Yha4cAfbYvIo=;
        b=vanqaWktOr0sdX3RCwQuBgRPDJC0M3axl0QavanMo8G+dimkor92UcT0n5uKUgEuWB
         GkkwN0TRCXtGICFv9pOvF1sMqyMDiSUDETpOyvOfxOh/YtSz9EjmwifJU6VVKLjDErtj
         RT6VslI1PrH9UsjZsUu8z/Tcv6Hsk+Lnf6l6TTNI+nMQT26AgcV2FgdbKVKoEnYb6bG/
         d50ePY74WwNunDfPhnc5FIE/cA7yyRRDJhDHxsdAPLnwupDXMxxnJiwermH9tyKq6Bhe
         X907Uhp9KBaF3u/MkAHY2mXlQ58/4fOirhBz9ahJUttILIJ1DKPCJuFLPvU+ihJYI9Hu
         asSw==
X-Forwarded-Encrypted: i=1; AJvYcCXlmQgxEqs6ehM9ZFdR34obdDaWtUQPZUPDk6W8wN6AdL6L8E5gCxdFHZgDjylslX/2fBtVZolXzl42q5506RNg7QvB/96bu6rza4iYjUY=
X-Gm-Message-State: AOJu0YznfnZdDe5bg1dwAVmhl7ISMBI4VVrFfRTkozj1tq5hi9VIKnt3
	PoDboySCnDeK4aD0O714ZHuXSwoYE+uwWOu5bSn4zOXi3XakD4cBpSBxVy9QBQ==
X-Google-Smtp-Source: AGHT+IEHd5icWl5jCQXO/j2Rpb7yqnUkHfILRbpmPVLQ3/EpDOfBiRP3wBkTv68mkMoV/lFNlqF5hQ==
X-Received: by 2002:a17:907:a0cc:b0:a45:ed7f:265c with SMTP id hw12-20020a170907a0cc00b00a45ed7f265cmr10058792ejc.0.1710767117478;
        Mon, 18 Mar 2024 06:05:17 -0700 (PDT)
Message-ID: <74477362-3022-45c9-bebb-c194a92aa10e@suse.com>
Date: Mon, 18 Mar 2024 14:05:16 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH v3] amd/iommu: clean up unused guest iommu related
 functions
To: Nicola Vetrini 
Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com,
 ayan.kumar.halder@amd.com, consulting@bugseng.com,
 Andrew Cooper , xen-devel@lists.xenproject.org
References: <98fef1239e4f0e756daf863a9e4e7bb679baa264.1710518105.git.nicola.vetrini@bugseng.com>
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <98fef1239e4f0e756daf863a9e4e7bb679baa264.1710518105.git.nicola.vetrini@bugseng.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 15.03.2024 16:55, Nicola Vetrini wrote:
> Delete unused functions from 'iommu_guest.c'.
> 
> No functional change.
> 
> Signed-off-by: Nicola Vetrini 
> ---
> guest_iommu_add_ptr_log has still one caller, but even that seems
> suspicious.

As said, it should be dropped. You remove ...

> -/* Domain specific initialization */
> -int guest_iommu_init(struct domain* d)
> -{
> -    struct guest_iommu *iommu;
> -    struct domain_iommu *hd = dom_iommu(d);
> -
> -    if ( !is_hvm_domain(d) || !is_iommu_enabled(d) || !iommuv2_enabled ||
> -         !has_viommu(d) )
> -        return 0;
> -
> -    iommu = xzalloc(struct guest_iommu);
> -    if ( !iommu )
> -    {
> -        AMD_IOMMU_DEBUG("Error allocating guest iommu structure.\n");
> -        return 1;
> -    }
> -
> -    guest_iommu_reg_init(iommu);
> -    iommu->mmio_base = ~0ULL;
> -    iommu->domain = d;
> -    hd->arch.amd.g_iommu = iommu;

... the only place setting  to non-NULL. With that the 2nd if() in
guest_iommu_add_ppr_log() is guaranteed to cause an early return, at which
point the function is meaningless to call.

But yeah, we can of course clean that up in a 2nd step. It's not like in
order to make a new attempt we would be very likely to simply revert the
changes to drop all of this code (in which case it being a single commit
would make things easier). It very likely wants re-writing from scratch.
Hence on top of Stefano's R-b:
Acked-by: Jan Beulich 

Jan


From xen-devel-bounces@lists.xenproject.org Mon Mar 18 13:10:39 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 13:10:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694686.1083689 (Exim 4.92)
	(envelope-from )
	id 1rmCl8-0005je-2N; Mon, 18 Mar 2024 13:10:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694686.1083689; Mon, 18 Mar 2024 13:10:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmCl7-0005jX-UP; Mon, 18 Mar 2024 13:10:33 +0000
Received: by outflank-mailman (input) for mailman id 694686;
 Mon, 18 Mar 2024 13:10:33 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmCl7-0005jP-C1
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 13:10:33 +0000
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com
 [2a00:1450:4864:20::629])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e5a4c373-e528-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 14:10:31 +0100 (CET)
Received: by mail-ej1-x629.google.com with SMTP id
 a640c23a62f3a-a46cf8f649dso51086766b.3
 for ; Mon, 18 Mar 2024 06:10:31 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 v15-20020a1709061dcf00b00a46cf83216csm298369ejh.120.2024.03.18.06.10.29
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 18 Mar 2024 06:10:30 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e5a4c373-e528-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710767430; x=1711372230; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=gjILFo13bCOElL9oZ/z9R73yH+FFeKVq0zNPOrbcw9o=;
        b=KHqbBpIhjecTku/dap1Dcw77Zkz8YxvTOU7suebh8JXB2jTNYpu2C4zHI/Io9pAALB
         u1TpYRtatG6+E1aYgJYLMaZ/xunk6YgrfN+nq0vc8nAPTRxavMNsA9PzgS9MikpNaOM7
         slnodGjn9T+63VBrW6QoN1sIZ0UD/Fdj2GWiQVGkVQ7AOSECOdzP0SU2C+agHw1h7hr6
         cM7piigHDL8BrjrdPzcZyzPs6MLoabb7BchXvv5RL/k+/I7QvWA60CFQVWCNbvHZkNbs
         HwQoqGtqfD4kt6SeGSEuF1GNheqO7EW7FIMizZY9b3G5ixWj3jcBZ3dihk2usw0SwKzY
         XXaA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710767430; x=1711372230;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=gjILFo13bCOElL9oZ/z9R73yH+FFeKVq0zNPOrbcw9o=;
        b=o0A41TeULIYmKXLSIgwEwk4sC9rKZlWDLX0fUfW+stDm4myyOhJoZaNcFcet+oomGl
         i5PF0NsjTC+JrgD+/Prgf3Ac4DCuVL49WqGfbtT9mVSijTMm4sNlKmetMgMHw9kNFStv
         cGBzmCMSwWABtar+DgEZwSjuuIr7UJ9oGdqcxVd3GHHrCufIp9bd9QPa6FMwYP0PBkdp
         4+Vz082NiO9wl3hGN9UB6qqg/btUVOznWc0U249CndBgO8QBddqvvjCyUkrQ4uENhctr
         4CqIKmHnIKdIKDMUkwhwEHQyhAWwtw4CeUjWQYGBvZ902oGeMnAPbiZivSBZ0guT8Oxe
         LcuA==
X-Forwarded-Encrypted: i=1; AJvYcCURFWRw0gJZjiul030LSWcXlWBmG+zbjY7820GjJy07i7jdXCg4DRPOUuPv0K6HiqX77wD1Y+PdSamvNelGBGXcvwcWGm6qBzpcvdyIplc=
X-Gm-Message-State: AOJu0YxkFx4V/FY7dO5iHPiXEWlM44ZTW0oLYgqXZnnyomiZ8IUoqdiy
	SlXFRnNJW/vKesRdPsRgU+ZmIh4xoMkj8Xie1N2U7bWmnNtZUOUXOeadEe6x8g==
X-Google-Smtp-Source: AGHT+IGaqVUMv2Zp+HJqWL/U8nJA4cHByVyaBtIaSgjd5fORAizKl5XvTHFASFh0zU8gvSnBrEZUzw==
X-Received: by 2002:a17:906:6607:b0:a46:5da0:7c09 with SMTP id b7-20020a170906660700b00a465da07c09mr8073580ejp.28.1710767430559;
        Mon, 18 Mar 2024 06:10:30 -0700 (PDT)
Message-ID: 
Date: Mon, 18 Mar 2024 14:10:29 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/4] xen/link: Introduce a common BUGFRAMES definition
Content-Language: en-US
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Wei Liu , Stefano Stabellini ,
 Julien Grall , Volodymyr Babchuk
 , Bertrand Marquis ,
 Michal Orzel ,
 Oleksii Kurochko ,
 Shawn Anastasio ,
 Konrad Rzeszutek Wilk ,
 Ross Lagerwall ,
 Xen-devel 
References: <20240318110442.3653997-1-andrew.cooper3@citrix.com>
 <20240318110442.3653997-2-andrew.cooper3@citrix.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240318110442.3653997-2-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 18.03.2024 12:04, Andrew Cooper wrote:
> Bugframe linkage is identical in all architectures.  This is not surprising
> given that it is (now) only consumed by common/virtual_region.c
> 
> Introduce a common BUGFRAMES define in xen.lds.h ahead of rearranging their
> structure.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 13:17:49 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 13:17:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694689.1083697 (Exim 4.92)
	(envelope-from )
	id 1rmCs4-0006OX-NN; Mon, 18 Mar 2024 13:17:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694689.1083697; Mon, 18 Mar 2024 13:17:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmCs4-0006OQ-Kg; Mon, 18 Mar 2024 13:17:44 +0000
Received: by outflank-mailman (input) for mailman id 694689;
 Mon, 18 Mar 2024 13:17:43 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmCs3-0006OK-Jw
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 13:17:43 +0000
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com
 [2a00:1450:4864:20::232])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e6d4ecb4-e529-11ee-afdd-a90da7624cb6;
 Mon, 18 Mar 2024 14:17:42 +0100 (CET)
Received: by mail-lj1-x232.google.com with SMTP id
 38308e7fff4ca-2d4a901e284so20850151fa.1
 for ; Mon, 18 Mar 2024 06:17:42 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 rf22-20020a1709076a1600b00a450b817705sm4858244ejc.154.2024.03.18.06.17.41
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 18 Mar 2024 06:17:41 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e6d4ecb4-e529-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710767862; x=1711372662; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=QAfHcqOuoyowVDXX5Dlp/ajXlFsU4Lc2t/kbY7CFOAM=;
        b=BtcaHTe1AZ3KUOVU7eQIt2f8dy3aRO+k4ADuyOy0DujD+MFps22q6rYpbLJjZPSi4x
         9VNm4MzrAhWhU65014NVUQ50HLNe6LmEhiv4z6V0zq7HbXHv5yYzIuRq3ykqrFl7oEtU
         ePbi4hFXKWNkJSh6GwCJWRno78JlEOctXelNH0HIJ6gXCzWn/DHALYTig6LrJSeO3uyE
         rw9U69civsJEU2wtz7sdGBLHZBJ0B+Xxeq2DSzyOWqRhmZwzD578/3Gz0Fta1vVBGbfR
         FLPuSnX+GESMHkhifts1F7UVW/S9i+xqqaFnuwcafTdDcCBmVVdseqCpzBJFvxyol02q
         Flmg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710767862; x=1711372662;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=QAfHcqOuoyowVDXX5Dlp/ajXlFsU4Lc2t/kbY7CFOAM=;
        b=t5YHQuMprkPlsuBaYj6BXipHc789yqxmyg6JM3ZZIhCiUqrlduN+Af/pQXB+BroyC/
         1czP0dX/F55IhxcAD2ml0n+jMKe1P3DFZkvANENOllILwLzNwRrmCCe5jVOeXF+DcizU
         S+A7blRi21dFNnIjOAgKAAmV9zQIv+c1AM7X2SZfBjJck1oxUFnSANmqu/PDwtpG5fwY
         mIBL1JlYFVppWtDXqepWZO+hYicgJMJU30Uo42Yh2H7OLBj0f5rfiZRQ74L6IPcvDQ84
         VxQ0zzOxGEeb0Xv2fz1tK1gFr5F3gVA/5XLc2/c+L9L0WXS1p/NcxQHMeGoQbh6U5Ir5
         jeIA==
X-Forwarded-Encrypted: i=1; AJvYcCV4pxkCBNgjByQj9aYBxMRJQuflWDY17tbrVHZUN/E6Akp1XP77BPT7tlZYOcxmePDIWdoFgnAUeZzOw7mnr4NhTVv+2z+8eUmLOGeiKSw=
X-Gm-Message-State: AOJu0YxuQOBOwYdh5wzAR2lsSVVdOzUBiwjYXyyDlEqF0j1Sh//8zT9v
	MeKV1vNrYtfMzQZPi6Y++FEg1v1+osNVrFDNVqicmh8qhn/zB2DZiwxBTbgljg==
X-Google-Smtp-Source: AGHT+IGYqghyRcxGiZu8VvpwH11TnJ1be/qORUGKgJzfaLFwolNnEIdNYCh0+VA6LHNI/M2uh5XUzQ==
X-Received: by 2002:a2e:9c18:0:b0:2d4:676b:f591 with SMTP id s24-20020a2e9c18000000b002d4676bf591mr4637667lji.45.1710767861935;
        Mon, 18 Mar 2024 06:17:41 -0700 (PDT)
Message-ID: <47ae2b45-b5da-4c5c-bbea-387f44d21a2f@suse.com>
Date: Mon, 18 Mar 2024 14:17:40 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/4] xen/virtual-region: Rework how bugframe linkage works
Content-Language: en-US
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Wei Liu , Stefano Stabellini ,
 Julien Grall , Volodymyr Babchuk
 , Bertrand Marquis ,
 Michal Orzel ,
 Oleksii Kurochko ,
 Shawn Anastasio ,
 Konrad Rzeszutek Wilk ,
 Ross Lagerwall ,
 Xen-devel 
References: <20240318110442.3653997-1-andrew.cooper3@citrix.com>
 <20240318110442.3653997-3-andrew.cooper3@citrix.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240318110442.3653997-3-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 18.03.2024 12:04, Andrew Cooper wrote:
> The start/stop1/etc linkage scheme predates struct virtual_region, and as
> setup_virtual_regions() shows, it's awkward to express in the new scheme.
> 
> Change the linker to provide explicit start/stop symbols for each bugframe
> type, and change virtual_region to have a stop pointer rather than a count.
> 
> This marginly simplifies both do_bug_frame()s and prepare_payload(), but it
> massively simplifies setup_virtual_regions() by allowing the compiler to
> initialise the .frame[] array at build time.
> 
> virtual_region.c is the only user of the linker symbols, and this is unlikely
> to change given the purpose of struct virtual_region, so move their externs
> out of bug.h
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 

Of course ...

> --- a/xen/common/virtual_region.c
> +++ b/xen/common/virtual_region.c
> @@ -9,12 +9,25 @@
>  #include 
>  #include 
>  
> +extern const struct bug_frame
> +    __start_bug_frames_0[], __stop_bug_frames_0[],
> +    __start_bug_frames_1[], __stop_bug_frames_1[],
> +    __start_bug_frames_2[], __stop_bug_frames_2[],
> +    __start_bug_frames_3[], __stop_bug_frames_3[];
> +
>  static struct virtual_region core = {
>      .list = LIST_HEAD_INIT(core.list),
>      .text_start = _stext,
>      .text_end = _etext,
>      .rodata_start = _srodata,
>      .rodata_end = _erodata,
> +
> +    .frame = {
> +        { __start_bug_frames_0, __stop_bug_frames_0 },
> +        { __start_bug_frames_1, __stop_bug_frames_1 },
> +        { __start_bug_frames_2, __stop_bug_frames_2 },
> +        { __start_bug_frames_3, __stop_bug_frames_3 },
> +    },
>  };
>  
>  /* Becomes irrelevant when __init sections are cleared. */
> @@ -22,6 +35,13 @@ static struct virtual_region core_init __initdata = {
>      .list = LIST_HEAD_INIT(core_init.list),
>      .text_start = _sinittext,
>      .text_end = _einittext,
> +
> +    .frame = {
> +        { __start_bug_frames_0, __stop_bug_frames_0 },
> +        { __start_bug_frames_1, __stop_bug_frames_1 },
> +        { __start_bug_frames_2, __stop_bug_frames_2 },
> +        { __start_bug_frames_3, __stop_bug_frames_3 },
> +    },
>  };

... this is now calling yet louder for splitting runtime from init bug
frame records.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Mar 18 13:24:28 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 13:24:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694692.1083708 (Exim 4.92)
	(envelope-from )
	id 1rmCyW-0008S0-Cg; Mon, 18 Mar 2024 13:24:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694692.1083708; Mon, 18 Mar 2024 13:24:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmCyW-0008Rt-A1; Mon, 18 Mar 2024 13:24:24 +0000
Received: by outflank-mailman (input) for mailman id 694692;
 Mon, 18 Mar 2024 13:24:23 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmCyV-0008Rn-EK
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 13:24:23 +0000
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com
 [2a00:1450:4864:20::630])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d49f04f9-e52a-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 14:24:21 +0100 (CET)
Received: by mail-ej1-x630.google.com with SMTP id
 a640c23a62f3a-a466f796fc1so550134266b.3
 for ; Mon, 18 Mar 2024 06:24:21 -0700 (PDT)
Received: from [10.80.67.23] (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 ko6-20020a170906aa0600b00a46a9c38a64sm2530108ejb.65.2024.03.18.06.24.20
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 18 Mar 2024 06:24:20 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d49f04f9-e52a-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710768261; x=1711373061; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=cUTij3OYTkLsjp4me+RmTl8kZLp1GeHkX4Fe0fiFvV0=;
        b=q64G9Xqwu/9g9PK+UVue6arImly0F61ZGJ7rNkcpp5UJzim04igpWbP/Mx9BSQ3rG0
         lndiGuWBkySlHBfhbY3Uo7l8H5MsnbuoMahHWqfnRMaui97P0gtm3JVlHwQFSvDQSU+D
         Z6F9XjXbQ6Z3cWCPq/ZyFCDJ7Vs7HGRiv1b88=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710768261; x=1711373061;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=cUTij3OYTkLsjp4me+RmTl8kZLp1GeHkX4Fe0fiFvV0=;
        b=Bwx+Qy+DbksdOKNOg7Z7JmB8KpgHAMNnbdt0uTybfXdCCJXiCm5mQSok1ks5tDmQ3r
         pm4R8ALPFl1sRt5Po/UQGxNjCqjYuvQLRMCTvOaiJXihEIuvo2BGWRL9mQxbS+YANEvw
         XQBHCT3S7bcqV4iuFjfyrnZKe9TSQh1FkCQV8WOmrb3u9X5VjqpNm5+xrTIkz7DECwQs
         SOeyoPGYbFZv9/XuYlEEmdELNZTcnYZDcFT8u7HeVtLoByhpWrFatyH1nKfIqO2GBHMX
         bzFHGkCnqDayR3fAZFIPZQSBurcx1gPzypTBLB7IwXacTNph+5BR6htsweMHAWFa93wc
         f7ZA==
X-Forwarded-Encrypted: i=1; AJvYcCXsPoIn9aURzmY6IeJ/ThaO93boECALI3+uix9C2a01sWDHXBUfU8agRCWxV6Y+7WaZy0VZSIZTM5aFOvKLRj58lVLrISYUWK1UfEaBSqE=
X-Gm-Message-State: AOJu0YxdczCERqaDKPh1+xR3rU5jk/lgFuFora88apfE59bDLv/+8/9n
	AYhu8FUd2RV5YADZ8YIjuLtRkntDTPF/1ZU/o8jSkd+vapLQA8vT7il9la3c/Ao=
X-Google-Smtp-Source: AGHT+IGM4zB5jQjo/bwV6q90Mzlgxdko60AClFzBe3KfoKnucHSg3wRqcW4QEzeTG4vThFXM5G4m4A==
X-Received: by 2002:a17:906:3708:b0:a45:f215:ce89 with SMTP id d8-20020a170906370800b00a45f215ce89mr8179284ejc.6.1710768260827;
        Mon, 18 Mar 2024 06:24:20 -0700 (PDT)
Message-ID: 
Date: Mon, 18 Mar 2024 13:24:19 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/4] xen/virtual-region: Rework how bugframe linkage works
Content-Language: en-GB
To: Jan Beulich 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Wei Liu , Stefano Stabellini ,
 Julien Grall , Volodymyr Babchuk
 , Bertrand Marquis ,
 Michal Orzel ,
 Oleksii Kurochko ,
 Shawn Anastasio ,
 Konrad Rzeszutek Wilk ,
 Ross Lagerwall ,
 Xen-devel 
References: <20240318110442.3653997-1-andrew.cooper3@citrix.com>
 <20240318110442.3653997-3-andrew.cooper3@citrix.com>
 <47ae2b45-b5da-4c5c-bbea-387f44d21a2f@suse.com>
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <47ae2b45-b5da-4c5c-bbea-387f44d21a2f@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 18/03/2024 1:17 pm, Jan Beulich wrote:
> On 18.03.2024 12:04, Andrew Cooper wrote:
>> The start/stop1/etc linkage scheme predates struct virtual_region, and as
>> setup_virtual_regions() shows, it's awkward to express in the new scheme.
>>
>> Change the linker to provide explicit start/stop symbols for each bugframe
>> type, and change virtual_region to have a stop pointer rather than a count.
>>
>> This marginly simplifies both do_bug_frame()s and prepare_payload(), but it
>> massively simplifies setup_virtual_regions() by allowing the compiler to
>> initialise the .frame[] array at build time.
>>
>> virtual_region.c is the only user of the linker symbols, and this is unlikely
>> to change given the purpose of struct virtual_region, so move their externs
>> out of bug.h
>>
>> No functional change.
>>
>> Signed-off-by: Andrew Cooper 
> Reviewed-by: Jan Beulich 

Thanks.

>
> Of course ...
>
>> --- a/xen/common/virtual_region.c
>> +++ b/xen/common/virtual_region.c
>> @@ -9,12 +9,25 @@
>>  #include 
>>  #include 
>>  
>> +extern const struct bug_frame
>> +    __start_bug_frames_0[], __stop_bug_frames_0[],
>> +    __start_bug_frames_1[], __stop_bug_frames_1[],
>> +    __start_bug_frames_2[], __stop_bug_frames_2[],
>> +    __start_bug_frames_3[], __stop_bug_frames_3[];
>> +
>>  static struct virtual_region core = {
>>      .list = LIST_HEAD_INIT(core.list),
>>      .text_start = _stext,
>>      .text_end = _etext,
>>      .rodata_start = _srodata,
>>      .rodata_end = _erodata,
>> +
>> +    .frame = {
>> +        { __start_bug_frames_0, __stop_bug_frames_0 },
>> +        { __start_bug_frames_1, __stop_bug_frames_1 },
>> +        { __start_bug_frames_2, __stop_bug_frames_2 },
>> +        { __start_bug_frames_3, __stop_bug_frames_3 },
>> +    },
>>  };
>>  
>>  /* Becomes irrelevant when __init sections are cleared. */
>> @@ -22,6 +35,13 @@ static struct virtual_region core_init __initdata = {
>>      .list = LIST_HEAD_INIT(core_init.list),
>>      .text_start = _sinittext,
>>      .text_end = _einittext,
>> +
>> +    .frame = {
>> +        { __start_bug_frames_0, __stop_bug_frames_0 },
>> +        { __start_bug_frames_1, __stop_bug_frames_1 },
>> +        { __start_bug_frames_2, __stop_bug_frames_2 },
>> +        { __start_bug_frames_3, __stop_bug_frames_3 },
>> +    },
>>  };
> ... this is now calling yet louder for splitting runtime from init bug
> frame records.

How do you propose we do this?

We can probably do it for *.init.o objects by renaming the bugframe
sections too, but unless we can do it for *every* bugframe emitted in
all init code, splitting this will break things.

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon Mar 18 13:26:04 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 13:26:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694695.1083718 (Exim 4.92)
	(envelope-from )
	id 1rmD06-0000b7-RO; Mon, 18 Mar 2024 13:26:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694695.1083718; Mon, 18 Mar 2024 13:26:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmD06-0000b0-Nj; Mon, 18 Mar 2024 13:26:02 +0000
Received: by outflank-mailman (input) for mailman id 694695;
 Mon, 18 Mar 2024 13:26:01 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmD05-0000au-1j
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 13:26:01 +0000
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com
 [2a00:1450:4864:20::62e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0edc4e3c-e52b-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 14:25:59 +0100 (CET)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-a465ddc2c09so309194166b.2
 for ; Mon, 18 Mar 2024 06:25:59 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 t26-20020a056402241a00b005689f73704csm4609584eda.38.2024.03.18.06.25.58
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 18 Mar 2024 06:25:58 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0edc4e3c-e52b-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710768359; x=1711373159; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=5SgnoUJb82+G01g/W7KbVHHnL69V6qQCv06GWruWVUI=;
        b=WPblPA2kKESCyhO4+S9YKo5mseBjiR40ZupzmXQq4gq/jJjDBBsMcZKaX9JwmDC2Ke
         kvb9pJrbY02mVIv46YmADBi4WPgICLjYAOGgCAu912TO88Eang4jAHRPgsYwj3x3m2UM
         9J7zyMAbfnaiPW0scaLTuWIRv/OgcWqbrnxsShnKT03sEyNJAdIKuOD7cguRGQBVq2iu
         f2u2njfz/ebQldmUoUC/QDCWkCK2c+sS4joRkwuS8yefyOnpqRZ0lrZz/lwNuF1tVHSs
         IKEWoLVkiZeePz3NwM2fKeJILYuUsyg54sykLiUMU+Rdo/iRm4gdxo6uVBqWrm8JYpNM
         9m2w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710768359; x=1711373159;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=5SgnoUJb82+G01g/W7KbVHHnL69V6qQCv06GWruWVUI=;
        b=FNHRV63HyJPZTvd1SyZGPzEgId57W6yzGBdEu/rGzg5b+CLycb3Jw/Fp4Exyc3bUIM
         riLjXXPU7aOLgC0oNPR85mHIRE9K7JOC7xOvh+wwrIYqLSZS2B2mGEdqw0lMlLODxg7/
         C7kWPFLDlYDsSsFDBuP22ewUjo3abbc6vIb2XzCvc+DqNkFdytaH8WVDw1RvfY0N1MQ9
         vbNa9gx0LzCcJL1D3r4P3CJ7pESC0SCTzDlgbnXaPtZaZum1urOXL6uzkYJdWyWDePlJ
         XVbzCJAfoPKOWZjrwMjdr5xcSpVLQlGZGhwsRp1msTZDh5QmwiasE2hrtio9fpkSUcq1
         comA==
X-Forwarded-Encrypted: i=1; AJvYcCWb/r/rLpmwMNgPvjKlbLh36tlyXYCCusPK6EmGBjJ4b0TYl0/mVHNiUzdvZYUTXwmTmDkyKN61+EehDusxvNFpIM0Tk1Ue18l5EG+eIPA=
X-Gm-Message-State: AOJu0YyAgay/oSWQOD+X3l5o29jeobTDCNfM+gjHIpNSEi8iC4fNoJFZ
	NCFli9qsIvPow9qxkd9mFkR9vKWLTUiEOBnjK98mDJq6OjgVmZMAI79fkSuLxg==
X-Google-Smtp-Source: AGHT+IG2w3qbN4dAXvZs17g+0MEjz15vX3dDpzTGniSSagXdozwaNTC8Bg2s9wJOgGAvsjKcIK0Peg==
X-Received: by 2002:a05:6402:2418:b0:568:d19e:7ab0 with SMTP id t24-20020a056402241800b00568d19e7ab0mr4073163eda.36.1710768358709;
        Mon, 18 Mar 2024 06:25:58 -0700 (PDT)
Message-ID: <94622e8d-e5b9-4306-bc61-d37cd8078338@suse.com>
Date: Mon, 18 Mar 2024 14:25:57 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 3/4] xen/virtual-region: Link the list build time
Content-Language: en-US
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Wei Liu , Stefano Stabellini ,
 Julien Grall , Volodymyr Babchuk
 , Bertrand Marquis ,
 Michal Orzel ,
 Oleksii Kurochko ,
 Shawn Anastasio ,
 Konrad Rzeszutek Wilk ,
 Ross Lagerwall ,
 Xen-devel 
References: <20240318110442.3653997-1-andrew.cooper3@citrix.com>
 <20240318110442.3653997-4-andrew.cooper3@citrix.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240318110442.3653997-4-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 18.03.2024 12:04, Andrew Cooper wrote:
> Given 3 statically initialised objects, its easy to link the list at build
> time.  There's no need to do it during runtime at boot (and with IRQs-off,
> even).

Hmm, technically that's correct, but isn't the overall result more fragile,
in being more error prone if going forward someone found a need to alter
things? Kind of supporting that view is also ...

> ---
>  xen/common/virtual_region.c | 45 ++++++++++++++++++++++++-------------
>  1 file changed, 30 insertions(+), 15 deletions(-)

... the diffstat of the change. It's perhaps also for a reason that ...

> --- a/xen/common/virtual_region.c
> +++ b/xen/common/virtual_region.c
> @@ -15,8 +15,19 @@ extern const struct bug_frame
>      __start_bug_frames_2[], __stop_bug_frames_2[],
>      __start_bug_frames_3[], __stop_bug_frames_3[];
>  
> +/*
> + * For the built-in regions, the double linked list can be constructed at
> + * build time.  Forward-declare the elements.
> + */
> +static struct list_head virtual_region_list;
> +static struct virtual_region core, core_init;
> +
>  static struct virtual_region core = {
> -    .list = LIST_HEAD_INIT(core.list),
> +    .list = {
> +        .next = &core_init.list,
> +        .prev = &virtual_region_list,
> +    },
> +
>      .text_start = _stext,
>      .text_end = _etext,
>      .rodata_start = _srodata,
> @@ -32,7 +43,11 @@ static struct virtual_region core = {
>  
>  /* Becomes irrelevant when __init sections are cleared. */
>  static struct virtual_region core_init __initdata = {
> -    .list = LIST_HEAD_INIT(core_init.list),
> +    .list = {
> +        .next = &virtual_region_list,
> +        .prev = &core.list,
> +    },
> +
>      .text_start = _sinittext,
>      .text_end = _einittext,
>  
> @@ -50,7 +65,10 @@ static struct virtual_region core_init __initdata = {
>   *
>   * All readers of virtual_region_list MUST use list_for_each_entry_rcu.
>   */
> -static LIST_HEAD(virtual_region_list);
> +static struct list_head virtual_region_list = {
> +    .next = &core.list,
> +    .prev = &core_init.list,
> +};

... there's no pre-cooked construct to avoid any open-coding at least
here.

To clarify up front: I'm willing to be convinced otherwise, and I therefore
might subsequently provide an ack. I'm also specifically not meaning this
to be treated as "pending objection"; if another maintainer provides an ack,
that's okay(ish) with me.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Mar 18 13:29:16 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 13:29:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694702.1083727 (Exim 4.92)
	(envelope-from )
	id 1rmD3C-0001WW-8H; Mon, 18 Mar 2024 13:29:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694702.1083727; Mon, 18 Mar 2024 13:29:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmD3C-0001WP-5e; Mon, 18 Mar 2024 13:29:14 +0000
Received: by outflank-mailman (input) for mailman id 694702;
 Mon, 18 Mar 2024 13:29:13 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmD3B-0001WJ-3u
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 13:29:13 +0000
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com
 [2a00:1450:4864:20::62a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 81cc2a5b-e52b-11ee-afdd-a90da7624cb6;
 Mon, 18 Mar 2024 14:29:12 +0100 (CET)
Received: by mail-ej1-x62a.google.com with SMTP id
 a640c23a62f3a-a46c0b40157so109592266b.0
 for ; Mon, 18 Mar 2024 06:29:12 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 p5-20020a170906604500b00a46a2ac0dbasm2824759ejj.197.2024.03.18.06.29.10
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 18 Mar 2024 06:29:11 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 81cc2a5b-e52b-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710768551; x=1711373351; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=e2BEpNTh21JJwZw/ewuLcLG7ijbMcMVNCFoUq0q0tbA=;
        b=Lz3/6S4O447ON3Ycmz/B4/hDCPORuaSs+bpR81KurXk5hm9GloGoCtXEe8BQnoK4qi
         qTDozRIoNPmJljkHGs4KS29o7j2vNv/S+QElOQ1rd/C4fzRHVa++t0SseXamIHaF1uCr
         WKzW3BouOm4Gid0ow9d+KDD0IxrZvk3kr7P0zrBxAvNN5PnIiZ6PN3VUYAe7aMdMazpO
         TTmlncxoUq4Ya/1EcLNFQfdT3eSSBErKr8AAim0mJT7+gPFiX2Dxf9AvF31euiIIG46C
         mog+uOc7zapCUMsvyzeKtqVC5jCeQs+FdRcZX0SiyDFYPg6lRNK7NIqF16DWq+aqGl53
         UvKg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710768551; x=1711373351;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=e2BEpNTh21JJwZw/ewuLcLG7ijbMcMVNCFoUq0q0tbA=;
        b=mFTIRx0HRrBcWGAU3LAjSv/E5Tr2QGWh0Zwx3x31Hx0KNFeQ8i7JRtmNZScazflATT
         S6NfX1PoIoC15uiReFYnwPaouqJri9Yy5aXmh3SYIRB3JFZM/n4iFhdFA0Dxttk7vAys
         8+uI/vyxfj1DXbYXyCo9WoxPcIhE20BrO/X/Rg/TuGb2D+g60EzjbxTf0KUgHllqfvV1
         EwtRwCpxLYJ9LwbHQhZ5jDyBvfrMko2ZPHlcYdgUiz9Cgy9BTaRTeq2iFs1yIsAhSXBy
         W05G7L87VVFnSRSmY5Suhe5dAevEs60BxpGk2y1AezwJp3EiWcIsQ9IZrdVYyUGe9sh3
         XSBw==
X-Forwarded-Encrypted: i=1; AJvYcCWAMuTESkk49ZQJhZk/GwQD2PUKoLq8BDUZWmk3bDyB7+KWsjOi6gdIUBToa6nd70nD1K5rklIwI/w2RPE3mLteyhoI8sXw4FoHsoJ7yjM=
X-Gm-Message-State: AOJu0YxAeOBZQVS8qH2K8lO0emrK+9l8Y9x/1oH+iB2g1IQzYDBpoI+s
	h6oyiDrY6VbdlEgHwryyAUk1CTldKdFOAQeJjtfpvGL11407gPoCEHxJauw55Q==
X-Google-Smtp-Source: AGHT+IEXss58LoC4IZ9PG45qrLOArpm3b+Oeo0miulVk4zRlj5n9tK/tzrilkHL463IXPS02GhLmCg==
X-Received: by 2002:a17:906:6582:b0:a46:1426:f7c with SMTP id x2-20020a170906658200b00a4614260f7cmr8155044ejn.63.1710768551533;
        Mon, 18 Mar 2024 06:29:11 -0700 (PDT)
Message-ID: <047ecaf2-66c6-4d07-ab14-9c50acfc1f9a@suse.com>
Date: Mon, 18 Mar 2024 14:29:10 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 4/4] xen/virtual-region: Drop setup_virtual_regions()
Content-Language: en-US
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Wei Liu , Stefano Stabellini ,
 Julien Grall , Volodymyr Babchuk
 , Bertrand Marquis ,
 Michal Orzel ,
 Oleksii Kurochko ,
 Shawn Anastasio ,
 Konrad Rzeszutek Wilk ,
 Ross Lagerwall ,
 Xen-devel 
References: <20240318110442.3653997-1-andrew.cooper3@citrix.com>
 <20240318110442.3653997-5-andrew.cooper3@citrix.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240318110442.3653997-5-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 18.03.2024 12:04, Andrew Cooper wrote:
> --- a/xen/common/virtual_region.c
> +++ b/xen/common/virtual_region.c
> @@ -39,6 +39,11 @@ static struct virtual_region core = {
>          { __start_bug_frames_2, __stop_bug_frames_2 },
>          { __start_bug_frames_3, __stop_bug_frames_3 },
>      },
> +
> +#ifdef CONFIG_X86
> +    .ex = __start___ex_table,
> +    .ex_end = __stop___ex_table,
> +#endif
>  };
>  
>  /* Becomes irrelevant when __init sections are cleared. */
> @@ -57,6 +62,11 @@ static struct virtual_region core_init __initdata = {
>          { __start_bug_frames_2, __stop_bug_frames_2 },
>          { __start_bug_frames_3, __stop_bug_frames_3 },
>      },
> +
> +#ifdef CONFIG_X86
> +    .ex = __start___ex_table,
> +    .ex_end = __stop___ex_table,
> +#endif
>  };

My main reservation here is this x86-specific code in a common file.
Are we certain both RISC-V and PPC will get away without needing to
touch this? If so, I might consider ack-ing. But really I'd prefer if
this could be minimally abstracted, via e.g. CONFIG_HAS_EXTABLE
(selected by x86 only for now).

Jan


From xen-devel-bounces@lists.xenproject.org Mon Mar 18 13:32:04 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 13:32:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694705.1083737 (Exim 4.92)
	(envelope-from )
	id 1rmD5r-0003B4-Lh; Mon, 18 Mar 2024 13:31:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694705.1083737; Mon, 18 Mar 2024 13:31:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmD5r-0003Ax-In; Mon, 18 Mar 2024 13:31:59 +0000
Received: by outflank-mailman (input) for mailman id 694705;
 Mon, 18 Mar 2024 13:31:58 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmD5q-0003Ar-Mb
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 13:31:58 +0000
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com
 [2a00:1450:4864:20::62d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e49351bc-e52b-11ee-afdd-a90da7624cb6;
 Mon, 18 Mar 2024 14:31:57 +0100 (CET)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-a2f22bfb4e6so604015866b.0
 for ; Mon, 18 Mar 2024 06:31:57 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 o1-20020a1709064f8100b00a4671c92907sm4752876eju.28.2024.03.18.06.31.56
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 18 Mar 2024 06:31:56 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e49351bc-e52b-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710768717; x=1711373517; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=NwtRDyHtFf43gosol81bXfRCcxu/+x2qM2XPgA/Ti4U=;
        b=DO7N15OUc+/K4qXobBsO9g7SE7v8I+aMDMGIiYuo6bZJmlDAszSjo+s7LhYMMF86UD
         wyzZfahojShkV0of5cVHLtMu/eybUkiKAfn5J0b2KuB/PXpeqpJZyDAinLyzXzNeNLx5
         uBYdPspdPH9KirgciOtb9/ed6Fbg8FOI3/1nZ6827s2MarlnCZKW3wFcbjbRRbxyNhBw
         byw97YxyJ0YjkJorCdtEJdYFdFaLyhCTDzL1qgzF5OcfdrFLlnNKnmd6edF02pSxvvQ9
         zGz7re7taUl/ofLH0LDfGgeXgQvPbf9R//1SJU8PoUeZhkxyCJ90d1KaJeUBtftBwV3T
         fjDA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710768717; x=1711373517;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=NwtRDyHtFf43gosol81bXfRCcxu/+x2qM2XPgA/Ti4U=;
        b=IKsCDTGpAioL8Di152r5zArX+uvltgXLYQ3hWycQp8ycDqtZ9LwicRUprRN1I2JTb6
         5hNgEocI0+CAeu6y6Y2eklYCX9CXU05Q8Mv1Bcc8hmuSVBWE6R/f8DhhlavIaHYsktY5
         zAsptzJUcB8nmR62UqwE7mZGKyeD1Q67S9FADMnVHhrskfzafWaRVwR4XSub4iKNphJX
         /TEK/YUmDA2NXf+jo/NA/WkdPsd2rpFJeplA4YmYItiYnKYGqEL0wSDIhMkk7scAq+Pr
         tUj86V7A71pTGBulKncDaLEag6sijoQfMwtXQuuGFfztLIKiGDLvJ3vB2Zc/tapqJ7Sm
         7VnA==
X-Forwarded-Encrypted: i=1; AJvYcCXfBt/6dn2wKmNEGUAKmsiXzV1UlOvmZZUxLpr5vSkKKDyvnpsy+bBkV5hgFfCWDu+N3o1hAThpzNVz1FMipc1NTPjBZ0+EUj4SmsvOeiM=
X-Gm-Message-State: AOJu0Yzz1K0/af9t/rzsCMH5aWq6Xr4gnjzdfBqu0TUuDPZ0ekxKQYfl
	ewPi7hen4sCXPgEeVdsYX15etfidOx9LhLhfndUS1CJl26+eTjIewDIhiJDQwg==
X-Google-Smtp-Source: AGHT+IEr+zR6ClnN/KUAR9W//MIivAR+DQEXPo4ZFegAYSwO36SxGRR0u/QUm4DnJG45P3UVmdmhqA==
X-Received: by 2002:a17:907:6d0d:b0:a46:a928:3034 with SMTP id sa13-20020a1709076d0d00b00a46a9283034mr4776803ejc.18.1710768717257;
        Mon, 18 Mar 2024 06:31:57 -0700 (PDT)
Message-ID: <5e9321b7-9d7a-4b1c-bcad-b5850e03aed8@suse.com>
Date: Mon, 18 Mar 2024 14:31:55 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/4] xen/virtual-region: Rework how bugframe linkage works
Content-Language: en-US
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Wei Liu , Stefano Stabellini ,
 Julien Grall , Volodymyr Babchuk
 , Bertrand Marquis ,
 Michal Orzel ,
 Oleksii Kurochko ,
 Shawn Anastasio ,
 Konrad Rzeszutek Wilk ,
 Ross Lagerwall ,
 Xen-devel 
References: <20240318110442.3653997-1-andrew.cooper3@citrix.com>
 <20240318110442.3653997-3-andrew.cooper3@citrix.com>
 <47ae2b45-b5da-4c5c-bbea-387f44d21a2f@suse.com>
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 18.03.2024 14:24, Andrew Cooper wrote:
> On 18/03/2024 1:17 pm, Jan Beulich wrote:
>> On 18.03.2024 12:04, Andrew Cooper wrote:
>>> --- a/xen/common/virtual_region.c
>>> +++ b/xen/common/virtual_region.c
>>> @@ -9,12 +9,25 @@
>>>  #include 
>>>  #include 
>>>  
>>> +extern const struct bug_frame
>>> +    __start_bug_frames_0[], __stop_bug_frames_0[],
>>> +    __start_bug_frames_1[], __stop_bug_frames_1[],
>>> +    __start_bug_frames_2[], __stop_bug_frames_2[],
>>> +    __start_bug_frames_3[], __stop_bug_frames_3[];
>>> +
>>>  static struct virtual_region core = {
>>>      .list = LIST_HEAD_INIT(core.list),
>>>      .text_start = _stext,
>>>      .text_end = _etext,
>>>      .rodata_start = _srodata,
>>>      .rodata_end = _erodata,
>>> +
>>> +    .frame = {
>>> +        { __start_bug_frames_0, __stop_bug_frames_0 },
>>> +        { __start_bug_frames_1, __stop_bug_frames_1 },
>>> +        { __start_bug_frames_2, __stop_bug_frames_2 },
>>> +        { __start_bug_frames_3, __stop_bug_frames_3 },
>>> +    },
>>>  };
>>>  
>>>  /* Becomes irrelevant when __init sections are cleared. */
>>> @@ -22,6 +35,13 @@ static struct virtual_region core_init __initdata = {
>>>      .list = LIST_HEAD_INIT(core_init.list),
>>>      .text_start = _sinittext,
>>>      .text_end = _einittext,
>>> +
>>> +    .frame = {
>>> +        { __start_bug_frames_0, __stop_bug_frames_0 },
>>> +        { __start_bug_frames_1, __stop_bug_frames_1 },
>>> +        { __start_bug_frames_2, __stop_bug_frames_2 },
>>> +        { __start_bug_frames_3, __stop_bug_frames_3 },
>>> +    },
>>>  };
>> ... this is now calling yet louder for splitting runtime from init bug
>> frame records.
> 
> How do you propose we do this?
> 
> We can probably do it for *.init.o objects by renaming the bugframe
> sections too, but unless we can do it for *every* bugframe emitted in
> all init code, splitting this will break things.

On halfway recent toolchains we can pass -Wa,--sectname-subst and then
construct section names derived from the containing text ones.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Mar 18 13:40:30 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 13:40:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694710.1083748 (Exim 4.92)
	(envelope-from )
	id 1rmDE1-0004i0-E7; Mon, 18 Mar 2024 13:40:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694710.1083748; Mon, 18 Mar 2024 13:40:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmDE1-0004ht-BO; Mon, 18 Mar 2024 13:40:25 +0000
Received: by outflank-mailman (input) for mailman id 694710;
 Mon, 18 Mar 2024 13:40:24 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmDE0-0004hn-Hu
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 13:40:24 +0000
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com
 [2a00:1450:4864:20::535])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 117cacc7-e52d-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 14:40:22 +0100 (CET)
Received: by mail-ed1-x535.google.com with SMTP id
 4fb4d7f45d1cf-563c595f968so5439252a12.0
 for ; Mon, 18 Mar 2024 06:40:22 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 n5-20020aa7c685000000b00568d4cf3288sm1532231edq.7.2024.03.18.06.40.21
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 18 Mar 2024 06:40:21 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 117cacc7-e52d-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710769222; x=1711374022; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=CkhltwH2owqMEQdxw5OamMfonlQX4S1yJYCHEIrOOUA=;
        b=DrAgb7Mg1cFoPwE8/V9Lla+ulNCAvEOuD1k8GqLTjRTHsr88XQgmc5fdp7TjLtdFDw
         q6rCEslT9++aox8CvHmL+/i/0f0VJxzbe8XYevOIqZ3og7bwBo+23PyC+tYBXGCoM3QL
         DcCduh+vHEx4NCc0bHzfp5B31RNn+/MS2bjqwv9ubeJvb1EnK96W1lu/PoMTmxR6n6w6
         LhTdGQFJ3s+pSXabS4xGzuGY51s2mNa2HHphzbQdL8UIt8tx24sgn5/6QbVFx6gCogP0
         hmaNctnBqvkRiBGyuhRtRNX9B8ljAqOmnge6Rtz6P+2gsRK3+Mv28LzLz394/eU62wfF
         6Npg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710769222; x=1711374022;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=CkhltwH2owqMEQdxw5OamMfonlQX4S1yJYCHEIrOOUA=;
        b=INtCQiauWQ0YEYW1n56au+6r9kKWNLhN0AT49PiEv5FTzyEeJe+t5rIoDwXsQFa3TS
         nTLOjcpTjh9GDQ587LmuCkBzJ+RSvbtD1MngdTICp1VAGGkqfsO+YZhuFc/LSeTPTxLY
         jIj+lj6zbKwQglXsVtMZi0rfyknYNPW4UEwhM5aOYu3LIGIRtJ2Fb6v3Aump/tFfB39Y
         WC9swzSALpFuyREAm8cDToGHcJvFfr8/fuEYxtedLaQgvIO2Nh9LCCkhz6Pwq9DEAQJP
         U0/EZNpP6jfuMfACVnIFAjdnJubX7kocyoT176drLeKHYZ6cwxnMhpy2bKD8BTjoUKOh
         F9Lw==
X-Forwarded-Encrypted: i=1; AJvYcCXrg/NxEhur4LXrHamEeB5GfkT2vyHUgIpTgySJ9FWXVv95lWWqiwTIXKkQ+hmwJEBH/a9rkJqQ/TudL/cH0yj/DtuEhyLoXGPGYmzTaLc=
X-Gm-Message-State: AOJu0Yzmm7dOlwC4G325f2p8e2g63k/tRlsAbYI1BdMRUq3fjWUVlgyp
	M9bXah7eNr9Ag1maIO4Bs3XNWLpJ0e+w8eD9E7eRtKkA5xkPojTyj4syFlQNjw==
X-Google-Smtp-Source: AGHT+IEqHENuRkhFNUXiMITh4f21gNlDo5Ktzad0xyYQv1gBeV9E0ObNOXyMylanQzAv2BErxDJXEw==
X-Received: by 2002:a05:6402:3708:b0:568:c283:f168 with SMTP id ek8-20020a056402370800b00568c283f168mr3818855edb.24.1710769222118;
        Mon, 18 Mar 2024 06:40:22 -0700 (PDT)
Message-ID: <3ab49282-6b67-4ab0-bb65-f04c62bcadcb@suse.com>
Date: Mon, 18 Mar 2024 14:40:21 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/2] IOMMU: store name for extra reserved device memory
Content-Language: en-US
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 
Cc: Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 Paul Durrant , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , xen-devel@lists.xenproject.org
References: <20240312162541.384793-1-marmarek@invisiblethingslab.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240312162541.384793-1-marmarek@invisiblethingslab.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 12.03.2024 17:25, Marek Marczykowski-Górecki wrote:
> It will be useful for error reporting in a subsequent patch.
> 
> Signed-off-by: Marek Marczykowski-Górecki 

In principle
Acked-by: Jan Beulich 
However, ...

> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -682,6 +682,7 @@ struct extra_reserved_range {
>      unsigned long start;
>      unsigned long nr;
>      pci_sbdf_t sbdf;
> +    const char *name;
>  };

... to me "descr" (or the longer "description") would seem more suitable.
Thoughts?

Jan


From xen-devel-bounces@lists.xenproject.org Mon Mar 18 13:48:19 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 13:48:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694716.1083758 (Exim 4.92)
	(envelope-from )
	id 1rmDLa-0005bY-9A; Mon, 18 Mar 2024 13:48:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694716.1083758; Mon, 18 Mar 2024 13:48:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmDLa-0005bR-6U; Mon, 18 Mar 2024 13:48:14 +0000
Received: by outflank-mailman (input) for mailman id 694716;
 Mon, 18 Mar 2024 13:48:13 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmDLY-0005bL-V4
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 13:48:12 +0000
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com
 [2a00:1450:4864:20::630])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 285b166b-e52e-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 14:48:10 +0100 (CET)
Received: by mail-ej1-x630.google.com with SMTP id
 a640c23a62f3a-a466a27d30aso567509566b.1
 for ; Mon, 18 Mar 2024 06:48:10 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 wn2-20020a170907068200b00a46c508d661sm814213ejb.176.2024.03.18.06.48.09
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 18 Mar 2024 06:48:09 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 285b166b-e52e-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710769690; x=1711374490; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=du66YwXtf6/Ss4etI303MhOow965JdkYQmY9J0bKLhE=;
        b=E/Msq3mZ3jLyxzZqAUi0BywRAAAPTNIctOMr7OjAHmyvFQMF6+Gj6qaV24qboGDGYY
         9lKhQj7O0hkb1gP6miwB2nJ0VAfvNfhY8Wo9tKEq+f8Hx6K7CUeR6YQKA+yJ1L/jNKWr
         Xo4k8n8Ln4ygkWx/CN+LkfhkQnRrnfqDx4vjRz8w4RKmrD+uCTFSB6WJW81u/RBVkVIj
         yvJCLOYF81utvsf7bwBc+fzqEHaQyR/0cEFQ5V+CMpDsAJPy9BVtzIb/sl3IWEIvMcFK
         S+HVy4AxfsAtO1bi5+Gq0fl2k9inP8rTBkc6xvDVKnCAxaAiemsxgwZzJUJk9NhcFxti
         dJpg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710769690; x=1711374490;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=du66YwXtf6/Ss4etI303MhOow965JdkYQmY9J0bKLhE=;
        b=gfgbBunQVYLVOekER34wKJ5WVc0Mbtn312tzM8dXLhsklIfurceTLWa5T/q1m0GY/v
         Q86YjPAsRhemkdx75qjzLxsi4zl0R4+1PC5khpfz84Fe8Z9bRdzp0D8ZSUi0ZKVqszqa
         eKLlxcgjTFD+e0S+Ud+RJoFU36u8eO5/EmSWIcFoD+PmDeHyAzeTj97/X8PhlzNRBFbl
         guR5z5Ice987VGMoe66kWKPx4dmTmoiQ3QZrrgqmoi+WPbeQV5g5tq7JQ/ZchqfUlKih
         dRklQcSaT1/bPBm2LdKzvrExMk3jQgDFxK202ROGkXefCuX4yj+9EqBTRSTWmub7BNOX
         olpA==
X-Forwarded-Encrypted: i=1; AJvYcCUL6toyjSJZ7S+F79MdGvs1NO5cS61L4qFCg0IgcuvB0HT8RElksXP14jSenoxcXah06OKAoUpLmjOOWsz1xLCMAUPnJ2PWB4r0GgWqNLA=
X-Gm-Message-State: AOJu0Yz8NnUNfTSnIVTJ1JzB4PsKJdNBXNJ3qYK7jp4xhxNFlGAbI5wc
	uS8Dw9jWENVI5Lr3YEQWwvV6BYUQmpEwTpYMp5eV+6U2ROZNq3POOPbpDJfH0A==
X-Google-Smtp-Source: AGHT+IEnXlaMjUhNTy1ZLvdl4Nk+vOaoFx/Po/X8mVGdyQHWfBpM0AlRk0B7l19EZZLSF2ryEhKl2g==
X-Received: by 2002:a17:907:1ca4:b0:a46:9e3c:9e62 with SMTP id nb36-20020a1709071ca400b00a469e3c9e62mr5833474ejc.13.1710769689910;
        Mon, 18 Mar 2024 06:48:09 -0700 (PDT)
Message-ID: <351eebc2-7da3-4082-830b-d8e764e2066a@suse.com>
Date: Mon, 18 Mar 2024 14:48:09 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/2] drivers/char: mark extra reserved device memory in
 memory map
Content-Language: en-US
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 
Cc: Paul Durrant , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , xen-devel@lists.xenproject.org
References: <20240312162541.384793-1-marmarek@invisiblethingslab.com>
 <20240312162541.384793-2-marmarek@invisiblethingslab.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240312162541.384793-2-marmarek@invisiblethingslab.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 12.03.2024 17:25, Marek Marczykowski-Górecki wrote:
> The IOMMU driver checks if RMRR/IVMD are marked as reserved in memory
> map. This should be true for addresses coming from the firmware, but
> when extra pages used by Xen itself are included in the mapping, those
> are taken from usable RAM used. Mark those pages as reserved too.
> 
> Not marking the pages as reserved didn't caused issues before due to
> another a bug in IOMMU driver code, that was fixed in 83afa3135830
> ("amd-vi: fix IVMD memory type checks").
> 
> Failing to reserve memory will lead to panic in IOMMU setup code. And
> not including the page in IOMMU mapping will lead to broken console (due
> to IOMMU faults). The pages chosen by the XHCI console driver should
> still be usable by the CPU though, and the console code already can deal
> with too slow console by dropping characters (and console not printing
> anything is a special case of "slow"). When reserving fails print an error
> message showing which pages failed and who requested them. This should
> be enough hint to find why XHCI console doesn't work.
> 
> Fixes: 3a1a7b809ffa "drivers/char: mark DMA buffers as reserved for the XHCI"
> Signed-off-by: Marek Marczykowski-Górecki 
> ---
> Alternative error handling could be a panic, but with this version I
> think it can be avoided. And not panicing gives a better chance to
> actually see the error message (from the hopefully started dom0),
> especially as the affected driver is the console one.
> 
> The reserve_e820_ram() is x86-specific. Is there some equivalent API for
> ARM, or maybe even some abstract one? That said, I have no way to test
> XHCI console on ARM, I don't know if such hardware even exists...

These are normal PCI devices, so I don't see why they shouldn't be usable
on non-x86 systems. But this is all okay as long as XHCI depends on X86
in Kconfig.

> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -21,6 +21,9 @@
>  #include 
>  #include 
>  #include 
> +#ifdef CONFIG_X86
> +#include 
> +#endif

This could do with a separating newline.

> @@ -715,6 +718,22 @@ int __init iommu_get_extra_reserved_device_memory(iommu_grdm_t *func,
>  
>      for ( idx = 0; idx < nr_extra_reserved_ranges; idx++ )
>      {
> +#ifdef CONFIG_X86
> +        if ( !reserve_e820_ram(
> +                &e820,
> +                pfn_to_paddr(extra_reserved_ranges[idx].start),
> +                pfn_to_paddr(extra_reserved_ranges[idx].start +
> +                             extra_reserved_ranges[idx].nr)) )

Indentation is odd here - it should be one level down from the start
of the function name. That side, code here and ...

> +        {
> +            printk(XENLOG_ERR "Failed to reserve [%"PRIx64"-%"PRIx64") for %s, "
> +                   "skipping IOMMU mapping for it, some functionality may be broken\n",
> +                   pfn_to_paddr(extra_reserved_ranges[idx].start),
> +                   pfn_to_paddr(extra_reserved_ranges[idx].start +
> +                                extra_reserved_ranges[idx].nr),

... here would likely benefit from introducing "start" and "end"
local variables.

> --- a/xen/include/xen/iommu.h
> +++ b/xen/include/xen/iommu.h
> @@ -324,7 +324,8 @@ struct iommu_ops {
>  };
>  
>  /*
> - * To be called by Xen internally, to register extra RMRR/IVMD ranges.
> + * To be called by Xen internally, to register extra RMRR/IVMD ranges for RAM
> + * pages.
>   * Needs to be called before IOMMU initialization.
>   */
>  extern int iommu_add_extra_reserved_device_memory(unsigned long start,
> @@ -334,6 +335,8 @@ extern int iommu_add_extra_reserved_device_memory(unsigned long start,
>  /*
>   * To be called by specific IOMMU driver during initialization,
>   * to fetch ranges registered with iommu_add_extra_reserved_device_memory().
> + * This has a side effect of marking requested ranges as "reserverd" in the

Nit: "reserved"

Jan

> + * memory map.
>   */
>  extern int iommu_get_extra_reserved_device_memory(iommu_grdm_t *func,
>                                                    void *ctxt);



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 13:50:04 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 13:50:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694722.1083768 (Exim 4.92)
	(envelope-from )
	id 1rmDNK-0007BW-KQ; Mon, 18 Mar 2024 13:50:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694722.1083768; Mon, 18 Mar 2024 13:50:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmDNK-0007Ax-HL; Mon, 18 Mar 2024 13:50:02 +0000
Received: by outflank-mailman (input) for mailman id 694722;
 Mon, 18 Mar 2024 13:50:00 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmDNI-0006xz-S3
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 13:50:00 +0000
Received: from mail-yb1-xb33.google.com (mail-yb1-xb33.google.com
 [2607:f8b0:4864:20::b33])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 69404b7d-e52e-11ee-afdd-a90da7624cb6;
 Mon, 18 Mar 2024 14:49:59 +0100 (CET)
Received: by mail-yb1-xb33.google.com with SMTP id
 3f1490d57ef6-dcbc00f6c04so3712625276.3
 for ; Mon, 18 Mar 2024 06:49:59 -0700 (PDT)
Received: from [10.80.67.23] (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 fk13-20020a05622a558d00b00430b59c37acsm3442625qtb.13.2024.03.18.06.49.56
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 18 Mar 2024 06:49:58 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 69404b7d-e52e-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710769799; x=1711374599; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=jGI563ovUKf9CtxDtAQ3CoJsPfD3toO3vX1R2ObYPCg=;
        b=Ios6ERztea6ijIukT0d9m6zLHXsED20UGdO0RQEyUmyknzY1sIICUCNmrBivZjb08O
         1ZU+TZ/jIJItk+xohtC2btqoEUy+u77LsM2lw1fqRvwt2VczFkLZq5FFt4Ofpz4sXyTN
         r3oS56X0kFd8Inq2U0J7Kb4/IIP2dxxHHcUaY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710769799; x=1711374599;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=jGI563ovUKf9CtxDtAQ3CoJsPfD3toO3vX1R2ObYPCg=;
        b=AvQyzbOnpc009rAAGtmNFdWljBFOB8Tc97l+X+BNsqQYcnInG0I1utFV5/UmJ64bpQ
         L22c8pVEHqNPR/UvgvqRUQMTNk9ehBJY/LDscYHATFJpeykC9YNmaa+RMQw1FLpgDTK+
         SdlmfuZN6+a6Zh1fcNlbWtRAD0MUghAjneUV+K5fd/+Y6ZtKgV2TUGCJsc9nztqx2pEm
         ZkHWmJGsDyJUeFsL+J95v8PM4ejYWKwfp1FTuv6fEd+aMRxNC2AMgFXqmzkqbiXbSpDQ
         7fTTY96HbupiI05biy8o5Ym/eagcedLeUdJBErfuOK9UN4DUudXADhq13mjohkhc51HW
         42+g==
X-Forwarded-Encrypted: i=1; AJvYcCVlVsyN+Ek8rY7EzSf/GlY9E38PUOD7gCYiZbcfeh39zOCTI286KzsOwazqQKz6M/fF2h3gG3/eg+HtIjVjo6qNGND6p/O52f1Nx0284QQ=
X-Gm-Message-State: AOJu0Yym+f0lGBg7rrxhxe9dd5xIEyHZ6T2UPniCy2y791oZTCk3/tN7
	azebxhlHmAaitpU+jfFdaE99jcWNmwhHYxUB5cbibri+QawUX7fe0UJu4AY2Qjk=
X-Google-Smtp-Source: AGHT+IG0FxvqvMUoLFE/nBLua3BfXo+u0XNYkVAAzBs35HqXyjaTizG6HnlvJV2r/Oxe2VX/bWRbyg==
X-Received: by 2002:a25:6a83:0:b0:dcb:ba75:bde7 with SMTP id f125-20020a256a83000000b00dcbba75bde7mr6562385ybc.7.1710769798711;
        Mon, 18 Mar 2024 06:49:58 -0700 (PDT)
Message-ID: <14accd85-d549-4551-a95c-6c8bcee92db5@citrix.com>
Date: Mon, 18 Mar 2024 13:49:55 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 4/4] xen/virtual-region: Drop setup_virtual_regions()
Content-Language: en-GB
To: Jan Beulich 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Wei Liu , Stefano Stabellini ,
 Julien Grall , Volodymyr Babchuk
 , Bertrand Marquis ,
 Michal Orzel ,
 Oleksii Kurochko ,
 Shawn Anastasio ,
 Konrad Rzeszutek Wilk ,
 Ross Lagerwall ,
 Xen-devel 
References: <20240318110442.3653997-1-andrew.cooper3@citrix.com>
 <20240318110442.3653997-5-andrew.cooper3@citrix.com>
 <047ecaf2-66c6-4d07-ab14-9c50acfc1f9a@suse.com>
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <047ecaf2-66c6-4d07-ab14-9c50acfc1f9a@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 18/03/2024 1:29 pm, Jan Beulich wrote:
> On 18.03.2024 12:04, Andrew Cooper wrote:
>> --- a/xen/common/virtual_region.c
>> +++ b/xen/common/virtual_region.c
>> @@ -39,6 +39,11 @@ static struct virtual_region core = {
>>          { __start_bug_frames_2, __stop_bug_frames_2 },
>>          { __start_bug_frames_3, __stop_bug_frames_3 },
>>      },
>> +
>> +#ifdef CONFIG_X86
>> +    .ex = __start___ex_table,
>> +    .ex_end = __stop___ex_table,
>> +#endif
>>  };
>>  
>>  /* Becomes irrelevant when __init sections are cleared. */
>> @@ -57,6 +62,11 @@ static struct virtual_region core_init __initdata = {
>>          { __start_bug_frames_2, __stop_bug_frames_2 },
>>          { __start_bug_frames_3, __stop_bug_frames_3 },
>>      },
>> +
>> +#ifdef CONFIG_X86
>> +    .ex = __start___ex_table,
>> +    .ex_end = __stop___ex_table,
>> +#endif
>>  };
> My main reservation here is this x86-specific code in a common file.
> Are we certain both RISC-V and PPC will get away without needing to
> touch this? If so, I might consider ack-ing. But really I'd prefer if
> this could be minimally abstracted, via e.g. CONFIG_HAS_EXTABLE
> (selected by x86 only for now).

This isn't the first bit of CONFIG_X86 in this file.  However, I'd not
spotted that we have CONFIG_HAS_EX_TABLE already.  I can swap.

As to extable on other architectures, that's not something I can answer,
although it's not something I can see in Oleksii's or Shawn's series so far.

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon Mar 18 13:54:23 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 13:54:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694725.1083787 (Exim 4.92)
	(envelope-from )
	id 1rmDRU-0000El-An; Mon, 18 Mar 2024 13:54:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694725.1083787; Mon, 18 Mar 2024 13:54:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmDRU-0000Ee-8G; Mon, 18 Mar 2024 13:54:20 +0000
Received: by outflank-mailman (input) for mailman id 694725;
 Mon, 18 Mar 2024 13:54:19 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmDRS-0008Qw-Vg
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 13:54:18 +0000
Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com
 [2607:f8b0:4864:20::72a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 03502659-e52f-11ee-afdd-a90da7624cb6;
 Mon, 18 Mar 2024 14:54:18 +0100 (CET)
Received: by mail-qk1-x72a.google.com with SMTP id
 af79cd13be357-789e2bf854dso158611385a.3
 for ; Mon, 18 Mar 2024 06:54:18 -0700 (PDT)
Received: from [10.80.67.23] (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 o5-20020ae9f505000000b0078812b73ea1sm4581535qkg.28.2024.03.18.06.54.15
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 18 Mar 2024 06:54:16 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 03502659-e52f-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710770057; x=1711374857; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=ai+rH1Ya2HGRi5MrW4Yk9UAKRD8uMIBORJU1vstP6xw=;
        b=o9jZf9z/oDiIi99fBT9i0KlIGkDYqTM3UUpYWhUpgitSjwWcP6zrRKgRfTy4F14nBC
         Di0LHvFDITy72AL1+ZoMWAxTYHFNrPPQJUZdJXnt6UP4+akstkcT3K0BVqUhOOF1Nm92
         t7ht1JcMeTR+R3vHYs676vMfR7rekB5O0N/2M=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710770057; x=1711374857;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=ai+rH1Ya2HGRi5MrW4Yk9UAKRD8uMIBORJU1vstP6xw=;
        b=gpW6o2QtecKf1t10m/HTEu6wsxeXvxJJL2zNieM53/TTOsq6oeISJ+j/LVseKQ9eWg
         nHYsliUkKAvNq6r0qBLoscKKRn9yXmguB00v8g6LM6/Y1oHkqsM72Z869RsJbtJiaVxh
         F3NzvQLXhmvum9ORHvXAIcs1tZgMGO/ZZLvrSSA3/0NavLuJKGxnwdLkEE9AKcp7LSFp
         6GCtOkHiTU8DEDZBLvp1NbwOGYw8XuzcPcLxeBRByw+vF9UX7dEKTSm7OtxkkwiIQxNi
         Dkz7uAID2FM3yTFsiLpMwV8UDIHN6zUz5e6SQndbEkZSxJmdvblJq7pUOtP1IaYT+MFc
         tHBA==
X-Forwarded-Encrypted: i=1; AJvYcCVVX0QcDCKQpXiDvGEd32R7b+ie6aWucDnthEmipcQPT9U5FNOuum+Gz4p68x1QGpCImm31atlb8lKhtUVgXvez/Zkm6L9uptqmlfqHYOo=
X-Gm-Message-State: AOJu0YxY47+jUTnqZU+rr+L5K8NsJjEJontrQGsCqGdL1DCJFceqwIMX
	PQlpFwLwKBnZ5KeaRWPKyB+1iTmPX3ZOAIXiVB7DAzuydzzZGEtpJZklxnZ8Ed8=
X-Google-Smtp-Source: AGHT+IFnkx8BnXe53mpSL+LDkTWhltJ/rmeXDFYclFZMadSWR7d8pcwiJiPOkLlTlTvt2mx+iaNelg==
X-Received: by 2002:a05:620a:2951:b0:789:fe61:8451 with SMTP id n17-20020a05620a295100b00789fe618451mr3649504qkp.63.1710770057223;
        Mon, 18 Mar 2024 06:54:17 -0700 (PDT)
Message-ID: <483c2375-26f9-442d-ba2f-c87cb2253178@citrix.com>
Date: Mon, 18 Mar 2024 13:54:14 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 3/4] xen/virtual-region: Link the list build time
Content-Language: en-GB
To: Jan Beulich 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Wei Liu , Stefano Stabellini ,
 Julien Grall , Volodymyr Babchuk
 , Bertrand Marquis ,
 Michal Orzel ,
 Oleksii Kurochko ,
 Shawn Anastasio ,
 Konrad Rzeszutek Wilk ,
 Ross Lagerwall ,
 Xen-devel 
References: <20240318110442.3653997-1-andrew.cooper3@citrix.com>
 <20240318110442.3653997-4-andrew.cooper3@citrix.com>
 <94622e8d-e5b9-4306-bc61-d37cd8078338@suse.com>
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <94622e8d-e5b9-4306-bc61-d37cd8078338@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 18/03/2024 1:25 pm, Jan Beulich wrote:
> On 18.03.2024 12:04, Andrew Cooper wrote:
>> Given 3 statically initialised objects, its easy to link the list at build
>> time.  There's no need to do it during runtime at boot (and with IRQs-off,
>> even).
> Hmm, technically that's correct, but isn't the overall result more fragile,
> in being more error prone if going forward someone found a need to alter
> things? Kind of supporting that view is also ...
>
>> ---
>>  xen/common/virtual_region.c | 45 ++++++++++++++++++++++++-------------
>>  1 file changed, 30 insertions(+), 15 deletions(-)
> ... the diffstat of the change. It's perhaps also for a reason that ...
>
>> --- a/xen/common/virtual_region.c
>> +++ b/xen/common/virtual_region.c
>> @@ -15,8 +15,19 @@ extern const struct bug_frame
>>      __start_bug_frames_2[], __stop_bug_frames_2[],
>>      __start_bug_frames_3[], __stop_bug_frames_3[];
>>  
>> +/*
>> + * For the built-in regions, the double linked list can be constructed at
>> + * build time.  Forward-declare the elements.
>> + */
>> +static struct list_head virtual_region_list;
>> +static struct virtual_region core, core_init;
>> +
>>  static struct virtual_region core = {
>> -    .list = LIST_HEAD_INIT(core.list),
>> +    .list = {
>> +        .next = &core_init.list,
>> +        .prev = &virtual_region_list,
>> +    },
>> +
>>      .text_start = _stext,
>>      .text_end = _etext,
>>      .rodata_start = _srodata,
>> @@ -32,7 +43,11 @@ static struct virtual_region core = {
>>  
>>  /* Becomes irrelevant when __init sections are cleared. */
>>  static struct virtual_region core_init __initdata = {
>> -    .list = LIST_HEAD_INIT(core_init.list),
>> +    .list = {
>> +        .next = &virtual_region_list,
>> +        .prev = &core.list,
>> +    },
>> +
>>      .text_start = _sinittext,
>>      .text_end = _einittext,
>>  
>> @@ -50,7 +65,10 @@ static struct virtual_region core_init __initdata = {
>>   *
>>   * All readers of virtual_region_list MUST use list_for_each_entry_rcu.
>>   */
>> -static LIST_HEAD(virtual_region_list);
>> +static struct list_head virtual_region_list = {
>> +    .next = &core.list,
>> +    .prev = &core_init.list,
>> +};
> ... there's no pre-cooked construct to avoid any open-coding at least
> here.
>
> To clarify up front: I'm willing to be convinced otherwise, and I therefore
> might subsequently provide an ack. I'm also specifically not meaning this
> to be treated as "pending objection"; if another maintainer provides an ack,
> that's okay(ish) with me.

I think it's a very small price to pay in order to allow patch 4 to exist.

If you can think of a nice way to express this with a pre-cooked
construct then suggestions welcome, but it's a really complicated piece
of metaprogramming to express in a nice way.

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon Mar 18 13:54:23 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 13:54:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694724.1083778 (Exim 4.92)
	(envelope-from )
	id 1rmDRT-0008RD-4B; Mon, 18 Mar 2024 13:54:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694724.1083778; Mon, 18 Mar 2024 13:54:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmDRT-0008R6-1B; Mon, 18 Mar 2024 13:54:19 +0000
Received: by outflank-mailman (input) for mailman id 694724;
 Mon, 18 Mar 2024 13:54:18 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmDRS-0008Qw-5w
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 13:54:18 +0000
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com
 [2a00:1450:4864:20::62c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0302366c-e52f-11ee-afdd-a90da7624cb6;
 Mon, 18 Mar 2024 14:54:17 +0100 (CET)
Received: by mail-ej1-x62c.google.com with SMTP id
 a640c23a62f3a-a46aaf6081fso229286266b.2
 for ; Mon, 18 Mar 2024 06:54:17 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 l22-20020a1709067d5600b00a469e550472sm3039024ejp.60.2024.03.18.06.54.16
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 18 Mar 2024 06:54:16 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0302366c-e52f-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710770057; x=1711374857; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:cc:references
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=vdFJzLL7+XxWvJIfFHzS8ECIuG+kQxLH5Hk8uTvzn5E=;
        b=eeXGTYU7LmT4MuzWJRj/SzMifbhgfBtrm+GXTd4DQiNSA9gGtcWOx7VamHSTkOqZ9k
         DIRsqBkNumkKNhPg20EE8l4KrAlAP941DA5NPRWZ07anCVNBRSUupyIG0cbcIoLPNLaP
         H1Y7gWy6Icp8uj1D1iAhvhS+2KuZi3AKb1PMzSXL4Fd4hZdsD08i8iH7dMt+Lqj2urBI
         3nlSSvJVWFZbuBgeJd1YBzcZCq9hKAiEBxvR2TI5eSHsCfFXFBF52QGpaR9zCUMyFu24
         +lcQPA7oHPnS77hd2BZ9Ysp9T9fU0rfDUBRZN9csLnws32/7UuF5R6ZwHORcq/RvjRob
         fvNw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710770057; x=1711374857;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:cc:references
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=vdFJzLL7+XxWvJIfFHzS8ECIuG+kQxLH5Hk8uTvzn5E=;
        b=T1JOs6oupzNz6gynk5gvCP8iMaac1/mOKm54xZ8HLjX9hdl479WYaCNN1JD8Ag/kr0
         FNr3j4InepPudSis4VJZtWbM7hcVM4NfqpSrJrcFyYrgy+khjWZdr8SHHTpd4sPGkMjg
         +eZ5Qj1KRQSS6h3L+IcWI1K/ZO5fgtErTMZ8K9omgM07zA4VPDxYfO+c+9Lkv3ITvFyr
         fLp3kaL27dDqQqN02VXUfpga9TxL0suM7ig2kVZM2bvAAIbvglAvqJlalCV2lqEQ2dLE
         NR3R71ZS1c66xV6KvqssjVdSY3nYBD7by+9wcwUsSn7azVhOth1WV47lmTPb2lxg1dZV
         xd0A==
X-Gm-Message-State: AOJu0YzRlimarooDR0Ov8bi9uXZJp4MpxkIdw4NWGJz68DW/SzHEMLai
	iS8+2x8HTbR8ZWoTEkZ9aIlae8LcEPLfOTvL/drJoTOgoZxlCHotkReflDWd9dx10eUP0XJPzWc
	=
X-Google-Smtp-Source: AGHT+IEZvCP6dQv64Uc05XniwlVkQ962g8rOYRrZf1yU+wZVh9Ui7TfW4Dw7QDIeY9Ni+GuxMFSdKw==
X-Received: by 2002:a17:907:11c7:b0:a45:c027:372 with SMTP id va7-20020a17090711c700b00a45c0270372mr6672048ejb.68.1710770056817;
        Mon, 18 Mar 2024 06:54:16 -0700 (PDT)
Message-ID: <75b51044-50dc-492c-b87d-b0e1a9701696@suse.com>
Date: Mon, 18 Mar 2024 14:54:15 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/3] x86: Move SVM features exposed to guest into
 hvm_max_cpu_policy
Content-Language: en-US
To: George Dunlap 
References: <20240313122454.965566-1-george.dunlap@cloud.com>
 <20240313122454.965566-2-george.dunlap@cloud.com>
Cc: xen-devel@lists.xenproject.org
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240313122454.965566-2-george.dunlap@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 13.03.2024 13:24, George Dunlap wrote:
> Currently (nested) SVM features we're willing to expose to the guest
> are defined in calculate_host_policy, and stored in host_cpu_policy.
> This is the wrong place for this; move it into
> calculate_hvm_max_policy(), and store it in hvm_max_cpu_policy.
> 
> Signed-off-by: George Dunlap 

Reviewed-by: Jan Beulich 




From xen-devel-bounces@lists.xenproject.org Mon Mar 18 13:56:43 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 13:56:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694732.1083797 (Exim 4.92)
	(envelope-from )
	id 1rmDTk-000187-Qf; Mon, 18 Mar 2024 13:56:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694732.1083797; Mon, 18 Mar 2024 13:56:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmDTk-000180-OD; Mon, 18 Mar 2024 13:56:40 +0000
Received: by outflank-mailman (input) for mailman id 694732;
 Mon, 18 Mar 2024 13:56:39 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmDTj-00017p-OL
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 13:56:39 +0000
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com
 [2a00:1450:4864:20::534])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 57913563-e52f-11ee-afdd-a90da7624cb6;
 Mon, 18 Mar 2024 14:56:39 +0100 (CET)
Received: by mail-ed1-x534.google.com with SMTP id
 4fb4d7f45d1cf-568a9c331a3so4066859a12.0
 for ; Mon, 18 Mar 2024 06:56:39 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ij11-20020a056402158b00b005688450c264sm4631306edb.91.2024.03.18.06.56.38
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 18 Mar 2024 06:56:38 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 57913563-e52f-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710770199; x=1711374999; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=M26AKOSwj1thasag5hkT096kGfsSdSx8dLZESqL0/GE=;
        b=PapynUfkGedSVVw8C2vB0MY+lFTn0VThbnYYe1mbn2grrYy4VkJky6Sw+/1PSlrIze
         sjoCQGhwptTWNDwl0zA8pLhZOONLFQv+ZXQjzATzmjcx1Qt2RQM3KmNfY2sPjS2mrrzv
         GGmTYb3jU4JYNNPaYtfUassqZDuvm8pdXlz+yaEwMJSxe1VWMJSXcx4iNcDULQlW4OcF
         bgcCSZouDJ2UUcrkpxAL0esZCyZeOFUFTbKOfWegY8rcu009rncwiTFzOAQoJT3XcbXL
         B1zvYLQm7KEljMjAgrTt1ycRFCxY6aqpbOfbE1YFRdEvIimzD0iSI7H1yNGlydtszw2N
         q4QA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710770199; x=1711374999;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=M26AKOSwj1thasag5hkT096kGfsSdSx8dLZESqL0/GE=;
        b=at+kXqFyt+lkEf6JtOS7oYMbEPUaIYeKVMNxrzIFSRVUNE1Pj+R9/Os78aN6y2eGn6
         hn5ZgTxLmk46p7fH7fbxiAkeRUiI+mV2qkNaSs/cG9WsHECTSe4e/fk2LZBB1j7yzSIq
         11PBhkX0KjUvaAcxH40CyeoBO+bWnJRHlYFcF0Cx6Ib/ehuX+uAaBQ9ubB6L+9QOk+O8
         MsLNNbn196D4z2UtE+0Ul8mJfMR1IFxgxfiTYwPXvNHzcO1PYynD0H4dNTnF5jfofecx
         ynggScFw+WOcL6VWPl2Lkdxr9ytES8XLN7BBKDtEn+HKlZqFkFeBNhHY9L0cz7q7rMWf
         NCvQ==
X-Forwarded-Encrypted: i=1; AJvYcCVRC4YrGIwDTu5eE6mOtuY0HlvRtphEDt/AX5jHFAvvevOrify27ewA+ubVTV5ISKD3vUPeci0ylvHc+zp4fg9z5hh9rBT2g3O4mYMNLP0=
X-Gm-Message-State: AOJu0Yz72y9gSSyU4cx0Jzd8N21Fl4xGYM8SV1s2wHFoKSQRexeLw9DS
	jAu1B/sqtzsV0lLWD0kUaFcCEQ7Wxyb0i3dbsosrnNQ0E7Lf8y3pXvojya/+IQ==
X-Google-Smtp-Source: AGHT+IFg5WEZrYjPaAOsvuosd/ojX4YzQrK/kI9Qt7YaaiCqV5RegHI3Wd176J4OkbUVV1fHTzGWNw==
X-Received: by 2002:a05:6402:3986:b0:568:223e:f2b0 with SMTP id fk6-20020a056402398600b00568223ef2b0mr10176553edb.21.1710770198712;
        Mon, 18 Mar 2024 06:56:38 -0700 (PDT)
Message-ID: <15911343-1eab-46bb-9e97-dce0b87ab504@suse.com>
Date: Mon, 18 Mar 2024 14:56:37 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/3] nestedsvm: Disable TscRateMSR
Content-Language: en-US
To: George Dunlap 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu
 , xen-devel@lists.xenproject.org
References: <20240313122454.965566-1-george.dunlap@cloud.com>
 <20240313122454.965566-3-george.dunlap@cloud.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240313122454.965566-3-george.dunlap@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 13.03.2024 13:24, George Dunlap wrote:
> The primary purpose of TSC scaling, from our perspective, is to
> maintain the fiction of an "invariant TSC" across migrates between
> platforms with different clock speeds.
> 
> On AMD, the TscRateMSR CPUID bit is unconditionally enabled in the
> "host cpuid", even if the hardware doesn't actually support it.
> According to c/s fd14a1943c4 ("nestedsvm: Support TSC Rate MSR"),
> testing showed that emulating TSC scaling in an L1 was more expensive
> than emulating TSC scaling on an L0 (due to extra sets of vmexit /
> vmenter).
> 
> However, the current implementation seems to be broken.
> 
> First of all, the final L2 scaling ratio should be a composition of
> the L0 scaling ratio and the L1 scaling ratio; there's no indication
> this is being done anywhere.
> 
> Secondly, it's not clear that the L1 tsc scaling ratio actually
> affects the L0 tsc scaling ratio.  The stored value (ns_tscratio) is
> used to affect the tsc *offset*, but doesn't seem to actually be
> factored into d->hvm.tsc_scaling_ratio.  (Which shouldn't be
> per-domain anyway, but per-vcpu.)  Having the *offset* scaled
> according to the nested scaling without the actual RDTSC itself also
> being scaled has got to produce inconsistent results.
> 
> For now, just disable the functionality entirely until we can
> implement it properly:
> 
> - Don't set TSCRATEMSR in the host CPUID policy

"host" is stale here; it's "HVM max" now.

> - Remove MSR_AMD64_TSC_RATIO emulation handling, so that the guest
>   guests a #GP if it tries to access them (as it should when
>   TSCRATEMSR is clear)
> 
> - Remove ns_tscratio from struct nestedhvm, and all code that touches
>   it
> 
> Unfortunately this means ripping out the scaling calculation stuff as
> well, since it's only used in the nested case; it's there in the git
> tree if we need it for reference when we re-introduce it.
> 
> Signed-off-by: George Dunlap 

Acked-by: Jan Beulich 

Jan


From xen-devel-bounces@lists.xenproject.org Mon Mar 18 14:18:04 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 14:18:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694741.1083807 (Exim 4.92)
	(envelope-from )
	id 1rmDoH-0004bD-GX; Mon, 18 Mar 2024 14:17:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694741.1083807; Mon, 18 Mar 2024 14:17:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmDoH-0004b6-E0; Mon, 18 Mar 2024 14:17:53 +0000
Received: by outflank-mailman (input) for mailman id 694741;
 Mon, 18 Mar 2024 14:17:52 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmDoG-0004au-1D
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 14:17:52 +0000
Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com
 [2a00:1450:4864:20::636])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4c106a21-e532-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 15:17:48 +0100 (CET)
Received: by mail-ej1-x636.google.com with SMTP id
 a640c23a62f3a-a46d0a8399aso59278166b.1
 for ; Mon, 18 Mar 2024 07:17:48 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 my10-20020a1709065a4a00b00a4663d3b2bfsm4873630ejc.217.2024.03.18.07.17.47
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 18 Mar 2024 07:17:47 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4c106a21-e532-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710771468; x=1711376268; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=qwFxVwwG6hCkpAos63NFwCKOuaguL+cfxYb3mvG+OQg=;
        b=gi+LHvDSeWWzRv9rFWlu9MrhXYknDq+dvKaepzEQaJAR+0b2EAZ+JdozNGvyAOO9SW
         JfK/DE/CjPUiNJ8P4Xyk9Yl3n9LWi0UT40CrWjA+acrNLqf9UHb4ovsPWGAhDXScsrEO
         UQ+RtJk5TBS6t9haJtQjRVd10rtd0ZVZcnL2Fl46RoEssu1d49mOq6kkqehzNAhOJXDz
         8t6r5+daMzoclYrKWRsW5Ip29od9eiKyp6E3Hc9JlypRTtkO93UNcEldlhT2oafq4pZ2
         WL/QtBmJdBO6MPXfq837v5bwB+7WxGEYdgnleExN2RrHPKOrg03fqawOXhvfY1i98ljh
         Gkfg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710771468; x=1711376268;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=qwFxVwwG6hCkpAos63NFwCKOuaguL+cfxYb3mvG+OQg=;
        b=S2j773rFN8h8xxyF24WEpfeLljZeXShQ923p16ET9oB3n3Jr1HF2RI/H1Zbtidn2d5
         TRGZYilGikZVwdrjALl2sB9m+dXC/poLLXFUPLnj/J7HjzOzdyFFP4TIHylcF/YPtxxI
         n9U6i2t/1APbzaUO35a6yOt4+lEGSbJTF32jrEImr82xnsScuYEhEuTRmCCAxSHAk6UV
         50kCZMekUAHUj78aHTf6WadljgldPqkhNAt5ZOch/zPn2MFC+OO9rZQH8047Kz5Swbhn
         CFWrmgvFX/8AA4vKkjq6GudjV+EB1QQQnkaC7sqQS1c1oCgJb5Qp9p4vNrewJyaQCsWz
         YaAA==
X-Forwarded-Encrypted: i=1; AJvYcCWqA6L6VcldYyK5zzsqLP8SygNPqohqnM0LVvRcy7isxJKxA91a3Shb3Enwwve/3HB0uyb34ErmJUabwukv5l4tmTphRk2MiCxGreb5WzU=
X-Gm-Message-State: AOJu0Yx3OKc3g5g+pnKLQPlxNS4IuvYEzb5ercElyvhYWn64dosJHN3j
	Iy7psIJZn0N8FZHMkR2XW9trIT7M26NuBhDtpdkjbQauyRfc5K1tPFjilQS2UA==
X-Google-Smtp-Source: AGHT+IFxDjTgVPgvKbPd+01/1lQ8twVqqwIiK+1gi+EMKSv0WOe9jIou3VmOPunGME5rAlx6ELt28g==
X-Received: by 2002:a17:907:7249:b0:a46:a85d:de81 with SMTP id ds9-20020a170907724900b00a46a85dde81mr5811263ejc.12.1710771467759;
        Mon, 18 Mar 2024 07:17:47 -0700 (PDT)
Message-ID: <7a5b3ec3-c122-479a-b714-529e150bf4c0@suse.com>
Date: Mon, 18 Mar 2024 15:17:46 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 3/3] svm/nestedsvm: Introduce nested capabilities bit
Content-Language: en-US
To: George Dunlap 
Cc: Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Jun Nakajima , Kevin Tian ,
 xen-devel@lists.xenproject.org
References: <20240313122454.965566-1-george.dunlap@cloud.com>
 <20240313122454.965566-4-george.dunlap@cloud.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240313122454.965566-4-george.dunlap@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 13.03.2024 13:24, George Dunlap wrote:
> In order to make implementation and testing tractable, we will require
> specific host functionality.  Add a nested_virt bit to hvm_funcs.caps,
> and return an error if a domain is created with nested virt and this
> bit isn't set.  Create VMX and SVM callbacks to be executed from
> start_nested_svm(), which is guaranteed to execute after all

Nit: nestedhvm_setup() (or, with different wording, start_nested_{svm,vmx}()).

> command-line options have been procesed.
> 
> For VMX, start with always enabling it if HAP is present; this
> shouldn't change current behvior.
> 
> For SVM, require some basic functionality, adding a document
> explaining the rationale.
> 
> NB that only SVM CPUID bits 0-7 have been considered.  Bits 10-16 may
> be considered in a follow-up patch.
> 
> Signed-off-by: George Dunlap 
>[...]
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -673,6 +673,12 @@ int arch_sanitise_domain_config(struct xen_domctl_createdomain *config)
>           */
>          config->flags |= XEN_DOMCTL_CDF_oos_off;
>  
> +    if ( nested_virt && !hvm_nested_virt_supported() )
> +    {
> +        dprintk(XENLOG_INFO, "Nested virt requested but not available\n");
> +        return -EINVAL;        
> +    }
> +
>      if ( nested_virt && !hap )
>      {
>          dprintk(XENLOG_INFO, "Nested virt not supported without HAP\n");

As mentioned in reply to v1, I think what both start_nested_{svm,vmx}() check
is redundant with this latter check. I think that check isn't necessary there
(yet unlike suggested in reply to v1 I don't think anymore that the check here
can alternatively be dropped). And even if it was to be kept for some reason,
I'm having some difficulty seeing why vendor code needs to do that check, when
nestedhvm_setup() could do it for both of them.

> --- a/xen/arch/x86/hvm/nestedhvm.c
> +++ b/xen/arch/x86/hvm/nestedhvm.c
> @@ -150,6 +150,16 @@ static int __init cf_check nestedhvm_setup(void)
>      __clear_bit(0x80, shadow_io_bitmap[0]);
>      __clear_bit(0xed, shadow_io_bitmap[1]);
>  
> +    /* 
> +     * NB this must be called after all command-line processing has been
> +     * done, so that if (for example) HAP is disabled, nested virt is
> +     * disabled as well.
> +     */
> +    if ( cpu_has_vmx )
> +        start_nested_vmx(&hvm_funcs);
> +    else if ( cpu_has_svm )
> +        start_nested_svm(&hvm_funcs);

Instead of passing the pointer, couldn't you have the functions return
bool, and then set hvm_funcs.caps.nested_virt from that? Passing that
pointer looks somewhat odd to me.

Is there a reason to use direct calls here rather than a true hook
(seeing that hvm_funcs must have been populated by the time we make it
here)? I understand we're (remotely) considering to switch away from
using hooks at some point, but right now this feels somewhat
inconsistent if not further justified.

> --- a/xen/arch/x86/hvm/vmx/vvmx.c
> +++ b/xen/arch/x86/hvm/vmx/vvmx.c
> @@ -2816,6 +2816,14 @@ void nvmx_set_cr_read_shadow(struct vcpu *v, unsigned int cr)
>      __vmwrite(read_shadow_field, v->arch.hvm.nvcpu.guest_cr[cr]);
>  }
>  
> +void __init start_nested_vmx(struct hvm_function_table *hvm_function_table)
> +{
> +    /* TODO: Require hardware support before enabling nested virt */
> +    hvm_function_table->caps.nested_virt =
> +        hvm_function_table->caps.hap;
> +}
> +
> +

Nit: No double blank lines please.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Mar 18 14:23:17 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 14:23:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694749.1083818 (Exim 4.92)
	(envelope-from )
	id 1rmDtR-0007Qm-3f; Mon, 18 Mar 2024 14:23:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694749.1083818; Mon, 18 Mar 2024 14:23:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmDtR-0007Qf-02; Mon, 18 Mar 2024 14:23:13 +0000
Received: by outflank-mailman (input) for mailman id 694749;
 Mon, 18 Mar 2024 14:23:12 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmDtQ-0007Pn-1U
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 14:23:12 +0000
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com
 [2a00:1450:4864:20::635])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0bd73bc9-e533-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 15:23:10 +0100 (CET)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-a46aaf6081fso235499866b.2
 for ; Mon, 18 Mar 2024 07:23:10 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 dl19-20020a170907945300b00a44b90abb1dsm4826650ejc.110.2024.03.18.07.23.08
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 18 Mar 2024 07:23:09 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0bd73bc9-e533-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710771789; x=1711376589; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=vzKDrBCNe4KDT0EZdUfGfCbruNaSk8Ji1ErhSE7z6i8=;
        b=MYC9JM99pinJ+t0pgtcN3qd/oW94ehTpJqRLasTKXVP/fXfT81dXGeB4XvaIS5v53c
         mcx+GeMzFivT+yLWKVlGGfdKehepWla+K8aFkzGh8limaCIAvKzvhLBhHaKcKc1PCFyB
         qdSFFY3mXOsWUp/aJGxsZgJomyTuuYG7s9ZAebU1tWPq8zsdv5KAjeJ1SfnHCeLhrEz1
         5Sq01W+sIwlptovd8OvKrrL2CkTu6SnLF9bHqTszJmDKfgkNQOvo5kJZRt6gM6lLD10u
         CAa0uFyW4RTdUiTMJcA1tkIg7FXKOhLi72F+3nha4uwbflKtI4U7I0P7ehAYSWC76cIJ
         w/KA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710771789; x=1711376589;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=vzKDrBCNe4KDT0EZdUfGfCbruNaSk8Ji1ErhSE7z6i8=;
        b=QmcOU7n5kXJypcFt45mtigHK8LFOBj8MYxovdieZNohlmuyLWkrhRQq+6LQQkiCfC6
         xppkcped0xaPCPTDJK1W3k+3miAFiq5cOLksSsq6IMJRi43Kmjg12kg73f7gtz7fAOSP
         +99990Y0cKxUIcQf89YjgjHZxUfGxrY7mRnqbNhdAU5QupV1xxys/JN8WQ3oJTILSSOI
         X8IGREWhWLSH7cxhSE7W25yWrcEA1/jw+TOH3DN2oabPfMTZeCwtJFqi6ojyIt9E/4b3
         NHJr2nKJj2tcZ6hyaP9YXq5XJlP/Aa8tJKOvEgvhskRCNv7hAUMsjnYZd/85bQlF3CU0
         +mvg==
X-Forwarded-Encrypted: i=1; AJvYcCU7Ppe+bEjT7cTxM4DV6AkWDG/Wq1u8ACMfQ2g40wAw49HWDtf7gBheyCxmPQO7xmempJXRk35zUwtZxAkuR6ppgFiCTQEjZd41/XWEccI=
X-Gm-Message-State: AOJu0Yz37jT59fXZunRnvdjF+CVolqrqbGFXgtjCiuJVmJ4vKZg7XHIk
	BS2cYMaalICp3djMQkS9C/xk5q/DJtt9AHrOVzLUT7IbUVGA5eMz4ezdo56GiQ==
X-Google-Smtp-Source: AGHT+IHR+RklMTX9K/qyQa0NuSMNJruYJjqhll/N6ysX+BzdBwvF7Kr0AvixSVOLEg7AJWI9kTIJFQ==
X-Received: by 2002:a17:906:2291:b0:a46:9395:de1f with SMTP id p17-20020a170906229100b00a469395de1fmr5811986eja.62.1710771789501;
        Mon, 18 Mar 2024 07:23:09 -0700 (PDT)
Message-ID: 
Date: Mon, 18 Mar 2024 15:23:07 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 4/4] xen/virtual-region: Drop setup_virtual_regions()
Content-Language: en-US
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Wei Liu , Stefano Stabellini ,
 Julien Grall , Volodymyr Babchuk
 , Bertrand Marquis ,
 Michal Orzel ,
 Oleksii Kurochko ,
 Shawn Anastasio ,
 Konrad Rzeszutek Wilk ,
 Ross Lagerwall ,
 Xen-devel 
References: <20240318110442.3653997-1-andrew.cooper3@citrix.com>
 <20240318110442.3653997-5-andrew.cooper3@citrix.com>
 <047ecaf2-66c6-4d07-ab14-9c50acfc1f9a@suse.com>
 <14accd85-d549-4551-a95c-6c8bcee92db5@citrix.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <14accd85-d549-4551-a95c-6c8bcee92db5@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 18.03.2024 14:49, Andrew Cooper wrote:
> On 18/03/2024 1:29 pm, Jan Beulich wrote:
>> On 18.03.2024 12:04, Andrew Cooper wrote:
>>> --- a/xen/common/virtual_region.c
>>> +++ b/xen/common/virtual_region.c
>>> @@ -39,6 +39,11 @@ static struct virtual_region core = {
>>>          { __start_bug_frames_2, __stop_bug_frames_2 },
>>>          { __start_bug_frames_3, __stop_bug_frames_3 },
>>>      },
>>> +
>>> +#ifdef CONFIG_X86
>>> +    .ex = __start___ex_table,
>>> +    .ex_end = __stop___ex_table,
>>> +#endif
>>>  };
>>>  
>>>  /* Becomes irrelevant when __init sections are cleared. */
>>> @@ -57,6 +62,11 @@ static struct virtual_region core_init __initdata = {
>>>          { __start_bug_frames_2, __stop_bug_frames_2 },
>>>          { __start_bug_frames_3, __stop_bug_frames_3 },
>>>      },
>>> +
>>> +#ifdef CONFIG_X86
>>> +    .ex = __start___ex_table,
>>> +    .ex_end = __stop___ex_table,
>>> +#endif
>>>  };
>> My main reservation here is this x86-specific code in a common file.
>> Are we certain both RISC-V and PPC will get away without needing to
>> touch this? If so, I might consider ack-ing. But really I'd prefer if
>> this could be minimally abstracted, via e.g. CONFIG_HAS_EXTABLE
>> (selected by x86 only for now).
> 
> This isn't the first bit of CONFIG_X86 in this file.  However, I'd not
> spotted that we have CONFIG_HAS_EX_TABLE already.  I can swap.

At which point:
Reviewed-by: Jan Beulich 

Jan


From xen-devel-bounces@lists.xenproject.org Mon Mar 18 14:31:23 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 14:31:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694754.1083828 (Exim 4.92)
	(envelope-from )
	id 1rmE1F-0001HQ-P8; Mon, 18 Mar 2024 14:31:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694754.1083828; Mon, 18 Mar 2024 14:31:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmE1F-0001HJ-M5; Mon, 18 Mar 2024 14:31:17 +0000
Received: by outflank-mailman (input) for mailman id 694754;
 Mon, 18 Mar 2024 14:31:16 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmE1E-0001HD-H0
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 14:31:16 +0000
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com
 [2a00:1450:4864:20::62c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2d09db4f-e534-11ee-afdd-a90da7624cb6;
 Mon, 18 Mar 2024 15:31:15 +0100 (CET)
Received: by mail-ej1-x62c.google.com with SMTP id
 a640c23a62f3a-a46c0b40157so120532666b.0
 for ; Mon, 18 Mar 2024 07:31:15 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a11-20020a170906190b00b00a44e2f3024bsm4879318eje.68.2024.03.18.07.31.14
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 18 Mar 2024 07:31:14 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2d09db4f-e534-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710772275; x=1711377075; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=wrVp/XY+6S5ve9dYXYVPytiqX81mqwYE5sySayCRtpg=;
        b=KW5qp7dwoLAVLpZ86h8Nr2wTs7cyPZwhvqoSSgvwZ+lqPSaNw24dRVdJwSgioPG2JK
         LIYQxT4+0QGiD2JZJMr4Uh7SWDVNqTEKSjdaBgbjgfg/QzgUGxUvii/x4sYECiO4lBOS
         Rs1DfZVYZf6mIaS/CcbgK0h7AfQaV+/xNVj58K54P8770L+foUBBxhRECVjdwuhJJnqP
         zvRmZ4VmeyU/NPbOOPSl/v5h5HeXhvvQlaQgjLDvJmJxZgxaoRUP84CJ1Dv5kDZ45aVB
         zCo9C+SdL7r0g4KjyKe0Rn2t7F2IG1z4+rbsejpsmUzJBQ56RJkAlpBduRqRLBzifgG/
         e8ag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710772275; x=1711377075;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=wrVp/XY+6S5ve9dYXYVPytiqX81mqwYE5sySayCRtpg=;
        b=e9oG7fm7Ay9jEfR/yUw/+4qponOJ9VY9NofgrEH8Pc8/zCTLbjQdf9pEh6bWsQE8ak
         /EeUC0JtaF0SMbt4aO67Zs+CnqgUGaTBd+xc772iMUv0hCMwwLGUvWTNgDozoZUiTPHk
         4nVBmUd7OS09Ohx5Vie5krOk92Hz6NEi+GE7+rnh5lRtwTrUYrW3ZOavKfK3d5vqRY6D
         gV6N80tGqKz1bDDRkjM8Br8d3eNtXF0VEW0S09z2ICNyQ2HciVIhQH5CY/2bcxsq1fGA
         4JZ9W96sFXy2YBKFAhT2jmc+CD+cGkjXmIc5k6P14ktfvG5W1B98WGSzMGbodPk3vT7N
         WzIw==
X-Forwarded-Encrypted: i=1; AJvYcCWAE6cM/aaZUEJayG/juFHUC1gpIhplEYzwnSCBPcyWcc633/niXQPRzGXn6qKyTPU6TO2BWWxThsmSRdUBAJM4t+l6B7TR17KO/72lc5s=
X-Gm-Message-State: AOJu0YzysgHM6ysfNlbD00j4z/XR3nbJlxH3w85I3HnPqurJ1+7t5/q7
	1lU3lknGnd7q9LAAEUgJJJej9rE9POQLFcN0PF3ijk9BBrOCSrLzGWKXSIHjow==
X-Google-Smtp-Source: AGHT+IFe7UIPLsNGypZ+1N7ZnzHPe5vLLzmY5y6Estp0zdhkvNS3g1EE3MaCZFpwg21UCfn1DB8otg==
X-Received: by 2002:a17:906:f75a:b0:a44:1fcf:9b97 with SMTP id jp26-20020a170906f75a00b00a441fcf9b97mr7244104ejb.24.1710772274800;
        Mon, 18 Mar 2024 07:31:14 -0700 (PDT)
Message-ID: <87b68741-71dc-407c-ab46-8dadcc0dfcef@suse.com>
Date: Mon, 18 Mar 2024 15:31:13 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 3/4] xen/virtual-region: Link the list build time
Content-Language: en-US
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Wei Liu , Stefano Stabellini ,
 Julien Grall , Volodymyr Babchuk
 , Bertrand Marquis ,
 Michal Orzel ,
 Oleksii Kurochko ,
 Shawn Anastasio ,
 Konrad Rzeszutek Wilk ,
 Ross Lagerwall ,
 Xen-devel 
References: <20240318110442.3653997-1-andrew.cooper3@citrix.com>
 <20240318110442.3653997-4-andrew.cooper3@citrix.com>
 <94622e8d-e5b9-4306-bc61-d37cd8078338@suse.com>
 <483c2375-26f9-442d-ba2f-c87cb2253178@citrix.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <483c2375-26f9-442d-ba2f-c87cb2253178@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 18.03.2024 14:54, Andrew Cooper wrote:
> On 18/03/2024 1:25 pm, Jan Beulich wrote:
>> On 18.03.2024 12:04, Andrew Cooper wrote:
>>> Given 3 statically initialised objects, its easy to link the list at build
>>> time.  There's no need to do it during runtime at boot (and with IRQs-off,
>>> even).
>> Hmm, technically that's correct, but isn't the overall result more fragile,
>> in being more error prone if going forward someone found a need to alter
>> things? Kind of supporting that view is also ...
>>
>>> ---
>>>  xen/common/virtual_region.c | 45 ++++++++++++++++++++++++-------------
>>>  1 file changed, 30 insertions(+), 15 deletions(-)
>> ... the diffstat of the change. It's perhaps also for a reason that ...
>>
>>> --- a/xen/common/virtual_region.c
>>> +++ b/xen/common/virtual_region.c
>>> @@ -15,8 +15,19 @@ extern const struct bug_frame
>>>      __start_bug_frames_2[], __stop_bug_frames_2[],
>>>      __start_bug_frames_3[], __stop_bug_frames_3[];
>>>  
>>> +/*
>>> + * For the built-in regions, the double linked list can be constructed at
>>> + * build time.  Forward-declare the elements.
>>> + */
>>> +static struct list_head virtual_region_list;
>>> +static struct virtual_region core, core_init;
>>> +
>>>  static struct virtual_region core = {
>>> -    .list = LIST_HEAD_INIT(core.list),
>>> +    .list = {
>>> +        .next = &core_init.list,
>>> +        .prev = &virtual_region_list,
>>> +    },
>>> +
>>>      .text_start = _stext,
>>>      .text_end = _etext,
>>>      .rodata_start = _srodata,
>>> @@ -32,7 +43,11 @@ static struct virtual_region core = {
>>>  
>>>  /* Becomes irrelevant when __init sections are cleared. */
>>>  static struct virtual_region core_init __initdata = {
>>> -    .list = LIST_HEAD_INIT(core_init.list),
>>> +    .list = {
>>> +        .next = &virtual_region_list,
>>> +        .prev = &core.list,
>>> +    },
>>> +
>>>      .text_start = _sinittext,
>>>      .text_end = _einittext,
>>>  
>>> @@ -50,7 +65,10 @@ static struct virtual_region core_init __initdata = {
>>>   *
>>>   * All readers of virtual_region_list MUST use list_for_each_entry_rcu.
>>>   */
>>> -static LIST_HEAD(virtual_region_list);
>>> +static struct list_head virtual_region_list = {
>>> +    .next = &core.list,
>>> +    .prev = &core_init.list,
>>> +};
>> ... there's no pre-cooked construct to avoid any open-coding at least
>> here.
>>
>> To clarify up front: I'm willing to be convinced otherwise, and I therefore
>> might subsequently provide an ack. I'm also specifically not meaning this
>> to be treated as "pending objection"; if another maintainer provides an ack,
>> that's okay(ish) with me.
> 
> I think it's a very small price to pay in order to allow patch 4 to exist.
> 
> If you can think of a nice way to express this with a pre-cooked
> construct then suggestions welcome, but it's a really complicated piece
> of metaprogramming to express in a nice way.

I don't see any suitable pre-cooked construct, but something custom just for
this file might be to have

/*
 * For the built-in regions, the double linked list can be constructed at
 * build time.  Forward-declare the elements.
 */
static struct list_head virtual_region_list;
static struct virtual_region core, core_init;
#define ENTRY1() { .next = &core_init.list, .prev = &virtual_region_list }
#define ENTRY2() { .next = &virtual_region_list, .prev = &core.list }
#define ENTRY3() { .next = &core.list, .prev = &core_init.list }

such that they're all close together and hence the list arrangement can be
easily seen. Sure, that'll still require each of the macros to be used
exactly once. Maybe instead of numeric suffixes the name of the struct the
macro is to be used in might help:

#define ENTRY_HEAD() { .next = &core.list, .prev = &core_init.list }
#define ENTRY_CORE() { .next = &core_init.list, .prev = &virtual_region_list }
#define ENTRY_INIT() { .next = &virtual_region_list, .prev = &core.list }

This way entries also come in list order.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Mar 18 14:35:21 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 14:35:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694757.1083837 (Exim 4.92)
	(envelope-from )
	id 1rmE59-0001v9-DD; Mon, 18 Mar 2024 14:35:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694757.1083837; Mon, 18 Mar 2024 14:35:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmE59-0001v2-A8; Mon, 18 Mar 2024 14:35:19 +0000
Received: by outflank-mailman (input) for mailman id 694757;
 Mon, 18 Mar 2024 14:35:18 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmE57-0001uw-W5
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 14:35:18 +0000
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com
 [2a00:1450:4864:20::633])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id bd20506e-e534-11ee-afdd-a90da7624cb6;
 Mon, 18 Mar 2024 15:35:17 +0100 (CET)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-a28a6cef709so661562566b.1
 for ; Mon, 18 Mar 2024 07:35:17 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 st6-20020a170907c08600b00a46af639a77sm2105205ejc.172.2024.03.18.07.35.15
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 18 Mar 2024 07:35:16 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: bd20506e-e534-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710772516; x=1711377316; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=3F5/xI2n9bTtGbvGmkUFaStfCLvsQ6kyaeiV8iaV5zU=;
        b=bUm4ujD5EIUDY/Zub3eIkSeT48s5pdwlWU9HhLB3aldgHQkNxb7Sjhiyl4aKxhIHe+
         /5rqHfgw2BdghBWXEx2koBc1H5gf9N8R4V55uvCq2j1vkpw3RB5UgRXWsONM/3rB42Wh
         SEkzDhlk99xixxQYajPQOd9hfYygDh4ZORMBrFNhVkTuxTiGV+4z4nPuJpjVrLI48MwY
         OIBmoYtXg6qfou0BOK3k1y6etwv/F/LzoK2zgYfjso6ueiJiXzvEYla2jnHab34msPvX
         3yVs+FwFjb/y0W0cubG7o/G7xLzIOmM8rmkJXhniJXNLASgzkcHUO8iX4hrEMf82ipqr
         NhuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710772516; x=1711377316;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=3F5/xI2n9bTtGbvGmkUFaStfCLvsQ6kyaeiV8iaV5zU=;
        b=NY8cIsgO/381e5SDk+be/fpXk0R44VwUhhngoQQL8a2NHmzv29I0sPqaCJIB2c+rUn
         5X9QL7pr7JEsNBs/LW8qC51vZQrV3Z9+ECJWZZYgjtM/EsXE84cvmr2pwafsPlSdTsVD
         MJtWvqgvQ3IAvzIvPH/bUEEwctYtBwCWq2y0+nG6Pp2xA2ZzXpnpQuVyUgtGC7ReZWuJ
         HLMNp7d3a97cqUd6+11xI+6ylbO29HRqhO5o15QwsTzUDBLPJgCnPxNcjUuOk6Eu2ps4
         eBfkEisdFAp+aFZ5xLzHjny7rY7Hc1IbTNWT3kAMPMyqXM0m4a0Y9CcqP58nZLzOZNiS
         5cVQ==
X-Forwarded-Encrypted: i=1; AJvYcCVHuPCjkQBY3EO6QH+OtrIcjI5uYwtCIJykANn30J3mTXom/Bt1ZCFTLk1axft+gvtEOtBygP9f/a7SahmYy3PQUH+fN6+141yCO8eoAEs=
X-Gm-Message-State: AOJu0YyS1W7CkCkTL7lgJZ6nQyFsDlpRXv9LA8oU1tiHc4Trxae8vX/m
	/iYCZRWhG/nZcjcy8kzDj/AGm0veutB0axDl23MnoKLTw31DqpX8hFSupEeRiA==
X-Google-Smtp-Source: AGHT+IFbvfOWz7saOjpj2bMk6TAXCeaOu4uE2iVUfy/WOkUmzWO8BEDhcNpFckVqwguwefLBhjY85Q==
X-Received: by 2002:a17:906:264c:b0:a46:b8fa:518 with SMTP id i12-20020a170906264c00b00a46b8fa0518mr2917770ejc.22.1710772516538;
        Mon, 18 Mar 2024 07:35:16 -0700 (PDT)
Message-ID: <33b44205-2edb-496f-9c92-e04f50f90deb@suse.com>
Date: Mon, 18 Mar 2024 15:35:15 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 02/13] xen/spinlock: introduce new type for recursive
 spinlocks
Content-Language: en-US
To: Juergen Gross 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu
 , George Dunlap ,
 Julien Grall , Stefano Stabellini ,
 Paul Durrant , Julien Grall ,
 xen-devel@lists.xenproject.org
References: <20240314072029.16937-1-jgross@suse.com>
 <20240314072029.16937-3-jgross@suse.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240314072029.16937-3-jgross@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 14.03.2024 08:20, Juergen Gross wrote:
> Introduce a new type "rspinlock_t" to be used for recursive spinlocks.
> 
> For now it is only an alias of spinlock_t, so both types can still be
> used for recursive spinlocks. This will be changed later, though.
> 
> Switch all recursive spinlocks to the new type.
> 
> Define the initializer helpers and use them where appropriate.
> 
> Signed-off-by: Juergen Gross 
> Acked-by: Julien Grall 

Acked-by: Jan Beulich 




From xen-devel-bounces@lists.xenproject.org Mon Mar 18 14:42:16 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 14:42:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694761.1083848 (Exim 4.92)
	(envelope-from )
	id 1rmEBm-0003Re-3Z; Mon, 18 Mar 2024 14:42:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694761.1083848; Mon, 18 Mar 2024 14:42:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmEBm-0003RX-0a; Mon, 18 Mar 2024 14:42:10 +0000
Received: by outflank-mailman (input) for mailman id 694761;
 Mon, 18 Mar 2024 14:42:08 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmEBk-0003RP-RI
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 14:42:08 +0000
Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com
 [2a00:1450:4864:20::231])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b144c240-e535-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 15:42:06 +0100 (CET)
Received: by mail-lj1-x231.google.com with SMTP id
 38308e7fff4ca-2d288bac3caso55351151fa.2
 for ; Mon, 18 Mar 2024 07:42:06 -0700 (PDT)
Received: from [192.168.206.239] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 m6-20020a2e8706000000b002d46c4b5be5sm1580896lji.120.2024.03.18.07.42.05
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 18 Mar 2024 07:42:05 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b144c240-e535-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1710772926; x=1711377726; darn=lists.xenproject.org;
        h=mime-version:user-agent:content-transfer-encoding:references
         :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject
         :date:message-id:reply-to;
        bh=0zs9FORdCVqjbN8HHPmhE3X+WIfBMifp4yNn8VM6DPw=;
        b=A0TvXpLXcSi65kjzvLEnfH9wWgEaSwV3QpeHscwwyNrOV1qjEhbGhgGh8Dx/5don+7
         KTdekKlEOGA7zSlm6tQcCfm5JrVr4PxCUluhV1aIqvqyB35fnM6vv4qEi3aNroUpQUU7
         P437mYj6dRcJHFOc5VG7VsL2BE1UMNQyS+fANhUzOPk8yspfwi8bDwNNEGA0J0NZt8ZW
         rfWNSH1tla7NAcMBrelyA6+Mygs4WbofMJsiXxO9DfjEd95SFsx/lLuN8o5Ft8EUDHIw
         eyJ+0S2cvtuOUdBPhybHaSsSS9bCyDIQBQW6C4tROUyLBkZH1RM8JVPoJMWTuRyC4iPN
         isvA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710772926; x=1711377726;
        h=mime-version:user-agent:content-transfer-encoding:references
         :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=0zs9FORdCVqjbN8HHPmhE3X+WIfBMifp4yNn8VM6DPw=;
        b=W6jF+QRtVV2NMgoJaxJB9thVL3C+2LnO/NsyJWFq334JpQmqxdJ+FKFOG4BEa0iDSF
         bK47SWOm12GrDinIkiE+PCVUyYYqkvMjUwbaAjUJnvv4ciD8scxzAl/altCZQRCu++i+
         kCHvID/jeqxqhFF2H5YRgX4tS1pVVcrbMOaNIpwWZzqWg/MH6fDWMGDmarT859e8IQxH
         6uWqsKGWs2zEgPEB1DKvODAvQO5mZV+GX3wJ17uz3DdRVUkyGGovQYLlRfikemkUKS3x
         ODNyieU+aB0IgSBVCPAvaK3U/OpN8kGffWjW1ijPpoo+FBHfUKOb4/RjfwLb9sjhzcvb
         c9DQ==
X-Forwarded-Encrypted: i=1; AJvYcCUZZsKeaf3Mbj7nKJ0I4QzFNoFB6QQzh5dIs6XB9ZgHB3x09i9GnSugTMcIWrmmT2KDW8jdo/L5YC9XCKlQ4YjDVUOX2e8YBI5pfUkiXcg=
X-Gm-Message-State: AOJu0Yxrv0jZqwAmr6+enkFyRqo8j0UYKAQfIrcnfX6J84ADc8z7ECIQ
	kj96LTtGA2WVABsV9xw7lVTcPI0welgvCmhWHR5c5LKNwwQjayTolGP3+OscO18=
X-Google-Smtp-Source: AGHT+IHWuKFDIFNjQO25vSdws2rjPdOas2ZNWE2GLB2C6AUfexi5FaAV0jgPgH9HUr2XfT9vA7p03w==
X-Received: by 2002:a2e:9c8e:0:b0:2d4:9201:d505 with SMTP id x14-20020a2e9c8e000000b002d49201d505mr4456143lji.51.1710772925761;
        Mon, 18 Mar 2024 07:42:05 -0700 (PDT)
Message-ID: <8fedc1b62712a8f9e64b06ae24be9359fbfb1947.camel@gmail.com>
Subject: Re: [PATCH v6 02/20] xen/riscv: disable unnecessary configs
From: Oleksii 
To: Jan Beulich 
Cc: Doug Goldstein , Stefano Stabellini
	 , Alistair Francis , Bob
	Eshleman , Connor Davis , 
	xen-devel@lists.xenproject.org
Date: Mon, 18 Mar 2024 15:42:04 +0100
In-Reply-To: <9ec42fc6-efc3-499b-b066-e582563cfc9c@suse.com>
References: 
	 <5a1b905601db481a1a625dafbbf9b28dbe12876c.1710517542.git.oleksii.kurochko@gmail.com>
	 <9ec42fc6-efc3-499b-b066-e582563cfc9c@suse.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.50.2 (3.50.2-1.fc39) 
MIME-Version: 1.0

On Mon, 2024-03-18 at 08:54 +0100, Jan Beulich wrote:
> On 15.03.2024 19:05, Oleksii Kurochko wrote:
> > --- a/xen/arch/riscv/configs/tiny64_defconfig
> > +++ b/xen/arch/riscv/configs/tiny64_defconfig
> > @@ -7,6 +7,23 @@
> > =C2=A0# CONFIG_GRANT_TABLE is not set
> > =C2=A0# CONFIG_SPECULATIVE_HARDEN_ARRAY is not set
> > =C2=A0# CONFIG_MEM_ACCESS is not set
> > +# CONFIG_ARGO is not set
> > +# CONFIG_HYPFS_CONFIG is not set
>=20
> What exactly is wrong with permitting this?
Nothing wrong, I just chose the wrong approach about which configs
should be disabled.

Considering your comment below, I'll limit overrides to what is
minimally necessary.

~ Oleksii
>=20
> > +# CONFIG_CORE_PARKING is not set
>=20
> At the example of this: It cannot be enabled by a user (or
> randconfig),
> it needs to be selected by an arch. Which RISC-V doesn't. Hence why
> specify (and not really override) the value here? This may apply to
> others as well, at the very least ...
>=20
> > +# CONFIG_DEBUG_TRACE is not set
> > +# CONFIG_IOREQ_SERVER is not set
> > +# CONFIG_CRASH_DEBUG is not setz
> > +# CONFIG_KEXEC is not set
> > +# CONFIG_LIVEPATCH is not set
> > +# CONFIG_NUMA is not set
> > +# CONFIG_PERF_COUNTERS is not set
> > +# CONFIG_HAS_PMAP is not set
>=20
> ... anything CONFIG_HAS_*.
>=20
> In summary - please limit overrides to what is minimally necessary.
>=20
> Jan
>=20
> > +# CONFIG_TRACEBUFFER is not set
> > +# CONFIG_XENOPROF is not set
> > +# CONFIG_COMPAT is not set
> > +# CONFIG_COVERAGE is not set
> > +# CONFIG_UBSAN is not set
> > +# CONFIG_NEEDS_LIBELF is not set
> > =C2=A0
> > =C2=A0CONFIG_RISCV_64=3Dy
> > =C2=A0CONFIG_DEBUG=3Dy
>=20



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 14:43:35 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 14:43:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694763.1083857 (Exim 4.92)
	(envelope-from )
	id 1rmED8-0003zR-DS; Mon, 18 Mar 2024 14:43:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694763.1083857; Mon, 18 Mar 2024 14:43:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmED8-0003zK-Al; Mon, 18 Mar 2024 14:43:34 +0000
Received: by outflank-mailman (input) for mailman id 694763;
 Mon, 18 Mar 2024 14:43:33 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmED7-0003zC-3f
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 14:43:33 +0000
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com
 [2a00:1450:4864:20::633])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e3a8472f-e535-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 15:43:31 +0100 (CET)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-a46aaf6081fso239503766b.2
 for ; Mon, 18 Mar 2024 07:43:31 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 u6-20020a1709063b8600b00a45f2dc6795sm4917001ejf.137.2024.03.18.07.43.30
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 18 Mar 2024 07:43:30 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e3a8472f-e535-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710773010; x=1711377810; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=NMq7fp3DEzVpxOUkpNplTvXW3AR6X2LrAaxIpotthZc=;
        b=ZWKHnp46q4YQYP3K267N8zfvNGaMVo4C4E89X21Mp9IiT1LMJ76FdXrXYp25KQ9QB5
         +PW6d1si2by/bx1O/GhKSS0yfnwEuLqrgRl9Y+7Bk0aiQe28PGAU19gZvDBGnz4EAC9l
         vw2A9xloCz5vowVb0APBPji9chfciD1mriO52ydTsjZNO1WonbXBQcnZu6p5N/jK5WyV
         vN9NyctiIQWx0nS4Iumf+WILLeoT9RAOttNoqlNYbbDdJL1Ao93F5aEHwqGlq5aerV+w
         +EW7D9dD771RRZ2IsdBK0EqyvPtJr3ckEWyjcotaHI+k4R+cndmG4qPLV5XvIvHqTcF2
         C42w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710773010; x=1711377810;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=NMq7fp3DEzVpxOUkpNplTvXW3AR6X2LrAaxIpotthZc=;
        b=RdLnFCD6wpDaHfnutqbn8uRWLLEVji7UTNe6vlOtXuY0z/ID8KJuMiAL76onVB0pPn
         yprD0krY1gzafxVQOXT3uy7y0xF8Z+Iaucpu8N+S7sBl6TfVc/p8tIeJK0uIQyJj6zVp
         85wWIi905gzJwa13UIe3yrdj3OMcoyRXiHDJ7uKQiLAYl3C2zcDDb4cWRiBtaTKblqum
         Aas+VIjuDAqNpvRgIlwPDhtUfBhdAv4PHTu3Pl+sXZAvm77oMnY2hb+0lSuwmXsYc/rK
         a7ZJPmKnCl15rlcHF0lZBQ0pfhU1IwGxuaxfMotv6CW+LNLPSpQ51CBl2tNcOXRlS+SL
         W6NQ==
X-Forwarded-Encrypted: i=1; AJvYcCUnrvocGAOZ9nElVrF8oDzlnQILWmRdUIu0x7coxYjM0jFlr/Kl5bCqB/aa9i9mQB9Rp/5OJFl70TkXnxsx+BgwvhRhoX32OUgdxF6S8lY=
X-Gm-Message-State: AOJu0YxR67RvGlqG+t0S4Vap5HmQlesT2u56Bcnpb2gybeVaD0HaHIH/
	BytdT/blSkXFXmlmEgDO5U0o5nFkJCl3WdRY3bUUXxlGYA4i7rjnz+UQRjOT3w==
X-Google-Smtp-Source: AGHT+IGr4BW7VhxMh6/CAG9fVotYIMOvtmu5+mKI47lTIgIiN8Kai+THtv6aOHMM6s2nq5T7+dkvZw==
X-Received: by 2002:a17:906:d8ad:b0:a46:13d5:46fe with SMTP id qc13-20020a170906d8ad00b00a4613d546femr7767014ejb.11.1710773010585;
        Mon, 18 Mar 2024 07:43:30 -0700 (PDT)
Message-ID: <1b8417b8-93aa-4976-a27a-701cfdf183b4@suse.com>
Date: Mon, 18 Mar 2024 15:43:29 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 04/13] xen/spinlock: add
 rspin_[un]lock_irq[save|restore]()
Content-Language: en-US
To: Juergen Gross 
Cc: Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 xen-devel@lists.xenproject.org
References: <20240314072029.16937-1-jgross@suse.com>
 <20240314072029.16937-5-jgross@suse.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240314072029.16937-5-jgross@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 14.03.2024 08:20, Juergen Gross wrote:
> Instead of special casing rspin_lock_irqsave() and
> rspin_unlock_irqrestore() for the console lock, add those functions
> to spinlock handling and use them where needed.
> 
> Signed-off-by: Juergen Gross 

Reviewed-by: Jan Beulich 
with two remarks:

> --- a/xen/common/spinlock.c
> +++ b/xen/common/spinlock.c
> @@ -475,15 +475,31 @@ void _rspin_lock(rspinlock_t *lock)
>      lock->recurse_cnt++;
>  }
>  
> +unsigned long _rspin_lock_irqsave(rspinlock_t *lock)
> +{
> +    unsigned long flags;
> +
> +    local_irq_save(flags);
> +    _rspin_lock(lock);
> +
> +    return flags;
> +}
> +
>  void _rspin_unlock(rspinlock_t *lock)
>  {
>      if ( likely(--lock->recurse_cnt == 0) )
>      {
>          lock->recurse_cpu = SPINLOCK_NO_CPU;
> -        spin_unlock(lock);
> +        _spin_unlock(lock);

This looks like an unrelated change. I think I can guess the purpose, but
it would be nice if such along-the-way changes could be mentioned in the
description.

> --- a/xen/include/xen/spinlock.h
> +++ b/xen/include/xen/spinlock.h
> @@ -272,7 +272,15 @@ static always_inline void spin_lock_if(bool condition, spinlock_t *l)
>   */
>  bool _rspin_trylock(rspinlock_t *lock);
>  void _rspin_lock(rspinlock_t *lock);
> +#define rspin_lock_irqsave(l, f)                                \
> +    ({                                                          \
> +        BUILD_BUG_ON(sizeof(f) != sizeof(unsigned long));       \
> +        ((f) = _rspin_lock_irqsave(l));                         \

Perhaps in the context of another patch in the series I think I had
pointed out that the outer pair of parentheses is unnecessary in
constructs like this. I'd be fine adjusting this while committing, as
long as for the other item above you'd provide some text to add.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Mar 18 14:49:23 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 14:49:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694768.1083868 (Exim 4.92)
	(envelope-from )
	id 1rmEIh-0005Jh-2z; Mon, 18 Mar 2024 14:49:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694768.1083868; Mon, 18 Mar 2024 14:49:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmEIg-0005Ja-W1; Mon, 18 Mar 2024 14:49:18 +0000
Received: by outflank-mailman (input) for mailman id 694768;
 Mon, 18 Mar 2024 14:49:18 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmEIg-0005JU-B3
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 14:49:18 +0000
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com
 [2a00:1450:4864:20::52d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b1ca4807-e536-11ee-afdd-a90da7624cb6;
 Mon, 18 Mar 2024 15:49:17 +0100 (CET)
Received: by mail-ed1-x52d.google.com with SMTP id
 4fb4d7f45d1cf-56b8e4f38a2so6580a12.3
 for ; Mon, 18 Mar 2024 07:49:16 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 p8-20020aa7c888000000b00567fa27e75fsm4655186eds.32.2024.03.18.07.49.16
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 18 Mar 2024 07:49:16 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b1ca4807-e536-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710773356; x=1711378156; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=1E622452z54d2ZKN7d8wn0TImsbuLvk7Yn3b+UyU6CA=;
        b=KbiEssLKPwTsbogkgHNllKt2sdrecxgqGSzW+eVJ9ym8Uzmyn3vJazY+i8mmbJTd/g
         2oXVuXUChs6wI78xtlPN2QDvyAzp1CzHNQ8LHsPni/JcMTvEgssh9FDGebeYNJ1WCIBl
         4qzmv6QEDyVW9iiKxggRsdIOtYOsSOBVe3JaQON9MNn4paaoq5567XBc/1ggjJZGStEF
         tinV2iMmrjKmQ8Q9S157dRbe78iisiukhYVFe85KSX0XXDHDjVo9fthqcOgh6Dkb9r4D
         /imJfYwBQl415Q3p6ndb0/RirgpLjE5P4KkI3cH9PkT0cH06oTnjrb7oB3rHbR9G+dZJ
         sIpg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710773356; x=1711378156;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=1E622452z54d2ZKN7d8wn0TImsbuLvk7Yn3b+UyU6CA=;
        b=ZjRVYNhIM9FqkzjvGwtkGEAXGXEg+XFrfA6C0SGCAka7/fd+jUz0yfz8qAo12bZUf0
         B42+FM3vzqgcgCsyGeAjJgblzUbrXJGOPDt7yA0NSwf+f7Wu3GIOOcH89+Nii9YoQB1p
         ElbI64lHVkjEslOcCsFihLowcZAl2cB2/J8jfHJQ5+IUI44P5Z7qXMP8HQmgVJ/sPtmp
         61ba8sWxdRGdWd/1ml4WEmSlKhBgTWJogpjJUJdhC15JaXa01dVlrKbfAB/dWyPHvwf8
         WiOXUcNf+TJspt9njU0Mp010GsKjIspu+Dd9pIVwRGh4TinFEGZe4bcygANMKEfzr5/x
         aHoQ==
X-Forwarded-Encrypted: i=1; AJvYcCU6EYH3m3CSIAqnzfGmui9ucevpmblh3ZxjIA9aJDu7BXbMey/7Xxyq+Idj9Xij3abwA03SipVySA6W1X4SAFxNVsTO8Br2y8oUWs7X5po=
X-Gm-Message-State: AOJu0Yx7p+1pU2dis/9D+fem2eeKbvZdilXuO46Y0fME/4L98CzHs4L7
	NfMlWLTttYtQjk98w6mX1GC3nSX7Fl6EOS96d1BPSu+f4ATePPDssvK/mZ2KhQ==
X-Google-Smtp-Source: AGHT+IFA9M1AzQM14aWje1Sf86pErhuNUlRMgo1sZsXZ8ap2P5nKkLmnACdOh1qn8mf2C0mHEB8tyQ==
X-Received: by 2002:a05:6402:1f49:b0:568:93f:36c6 with SMTP id 9-20020a0564021f4900b00568093f36c6mr8924338edz.22.1710773356582;
        Mon, 18 Mar 2024 07:49:16 -0700 (PDT)
Message-ID: <91819455-52ca-41c8-aa9f-ae092e117489@suse.com>
Date: Mon, 18 Mar 2024 15:49:15 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 07/13] xen/spinlock: add another function level
Content-Language: en-US
To: Juergen Gross 
Cc: Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 xen-devel@lists.xenproject.org
References: <20240314072029.16937-1-jgross@suse.com>
 <20240314072029.16937-8-jgross@suse.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240314072029.16937-8-jgross@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 14.03.2024 08:20, Juergen Gross wrote:
> Add another function level in spinlock.c hiding the spinlock_t layout
> from the low level locking code.
> 
> This is done in preparation of introducing rspinlock_t for recursive
> locks without having to duplicate all of the locking code.
> 
> Signed-off-by: Juergen Gross 

Reviewed-by: Jan Beulich 




From xen-devel-bounces@lists.xenproject.org Mon Mar 18 14:57:30 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 14:57:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694774.1083877 (Exim 4.92)
	(envelope-from )
	id 1rmEQT-0007oN-Se; Mon, 18 Mar 2024 14:57:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694774.1083877; Mon, 18 Mar 2024 14:57:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmEQT-0007oG-Q8; Mon, 18 Mar 2024 14:57:21 +0000
Received: by outflank-mailman (input) for mailman id 694774;
 Mon, 18 Mar 2024 14:57:21 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmEQT-0007oA-56
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 14:57:21 +0000
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com
 [2a00:1450:4864:20::62e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d1843e76-e537-11ee-afdd-a90da7624cb6;
 Mon, 18 Mar 2024 15:57:19 +0100 (CET)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-a46cc855600so118880966b.0
 for ; Mon, 18 Mar 2024 07:57:19 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 l20-20020a1709067d5400b00a46bed423a0sm1170690ejp.23.2024.03.18.07.57.18
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 18 Mar 2024 07:57:19 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d1843e76-e537-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710773839; x=1711378639; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=vaPg+rnST4a2xz31vCnYXXNma73H0XKOPY4z7JssaZk=;
        b=X9r5kvVm40K5yb9o301x9jIMgotHo9zbdP89YDym8zui7CONhLxQ5qd466YQqb2x+L
         X3Y7cw5Z+oNrd2VyWvb3SfPyfD2kyQHtaejznzhWWaUkGlgX0Kuuf3JSXYgaBR9+R8WA
         jARR9TtkKI9WPnr62zcunZ6QHzOHwdr4q6EtwWZoB0h1WXGuP5XGxVH8a0RZwqGE7hvm
         bxyMffjsb6hHOchbi+i78D/ZKLNp5BaPpObBVZIrEJ1X09lbb7lp9ypQDuDfJq604RZ0
         QDiCxIPVHPHR6DPL49VVtPH8mZd5+376kAPGLlWC+MhD+hDnTArH3Qud1aL8tU7OIQDB
         Uw4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710773839; x=1711378639;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=vaPg+rnST4a2xz31vCnYXXNma73H0XKOPY4z7JssaZk=;
        b=hU8oONtU45kYVZXykEDYQWtJD9I4BklC/1A6RZfK0f8CuOCiAbAMr8OJ8bcfzeSXjd
         whre/yFmqaWbwcq9cZejNoACHn05fJv9MXRFkRJXbTRmtRiUSGyvPplVmsveo1uCOaN5
         aHb1lQpfpb11c8MX9kVFLGBYFCi72MC8Co4b2GO3AzpfTHM/xolDFFlQ93HY7jvrKGmg
         foCbtHzMdAxyhSMptEaUY/n6eBUuA4Trp9+NsIt/QVEdg/SzHq6R1IAADHwOyg1rrltn
         AO7DyrcbQsbUV98XOujH46CCJBRx/hkf8vc47hzgr6ry57yucGm6Ee1PS1NnMW1bxHpq
         RxNQ==
X-Forwarded-Encrypted: i=1; AJvYcCUB2NBHyFSZtZejRSyOATHoQgjVLtnHR3EuNnwFtm5BVjjW9AuhW1ipROdMZX6GHqwcw4FFeoedTcbJGlvFlTZIhHbXjGi20gA/Uawc6fk=
X-Gm-Message-State: AOJu0YxOTRgOAoUZWALPrJjMlddxoe2dt5KYyc2loNN8LlJGlRLKKGLH
	KZYyaUNdfm2tcEswM3OKFTCHG+EuzKQ7/ldoOBsRUegD9zqXMssAThOZINSleQ==
X-Google-Smtp-Source: AGHT+IG5ibjyMQwRKzdG7XcJfHQj5hiPJH7hWMKT4SPwg+9pxK6Fmg6J+bMyuLtg9HAUgn+RZoamAA==
X-Received: by 2002:a17:906:6bd4:b0:a44:1e32:a503 with SMTP id t20-20020a1709066bd400b00a441e32a503mr8582452ejs.22.1710773839286;
        Mon, 18 Mar 2024 07:57:19 -0700 (PDT)
Message-ID: 
Date: Mon, 18 Mar 2024 15:57:18 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 08/13] xen/spinlock: add missing rspin_is_locked() and
 rspin_barrier()
Content-Language: en-US
To: Juergen Gross 
Cc: Andrew Cooper ,
 George Dunlap ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu
 , Julien Grall ,
 Stefano Stabellini , Paul Durrant ,
 xen-devel@lists.xenproject.org
References: <20240314072029.16937-1-jgross@suse.com>
 <20240314072029.16937-9-jgross@suse.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240314072029.16937-9-jgross@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 14.03.2024 08:20, Juergen Gross wrote:
> --- a/xen/common/spinlock.c
> +++ b/xen/common/spinlock.c
> @@ -395,14 +395,7 @@ static bool always_inline spin_is_locked_common(const spinlock_tickets_t *t)
>  
>  int _spin_is_locked(const spinlock_t *lock)
>  {
> -    /*
> -     * Recursive locks may be locked by another CPU, yet we return
> -     * "false" here, making this function suitable only for use in
> -     * ASSERT()s and alike.
> -     */
> -    return lock->recurse_cpu == SPINLOCK_NO_CPU
> -           ? spin_is_locked_common(&lock->tickets)
> -           : lock->recurse_cpu == smp_processor_id();
> +    return spin_is_locked_common(&lock->tickets);
>  }

The "only suitable for ASSERT()s and alike" part of the comment wants
to survive here, I think.

> @@ -465,6 +458,23 @@ void _spin_barrier(spinlock_t *lock)
>      spin_barrier_common(&lock->tickets, &lock->debug, LOCK_PROFILE_PAR);
>  }
>  
> +bool _rspin_is_locked(const rspinlock_t *lock)
> +{
> +    /*
> +     * Recursive locks may be locked by another CPU, yet we return
> +     * "false" here, making this function suitable only for use in
> +     * ASSERT()s and alike.
> +     */
> +    return lock->recurse_cpu == SPINLOCK_NO_CPU
> +           ? spin_is_locked_common(&lock->tickets)
> +           : lock->recurse_cpu == smp_processor_id();
> +}

Here otoh I wonder if both the comment and the spin_is_locked_common()
part of the condition are actually correct. Oh, the latter needs
retaining as long as we have nrspin_*() functions, I suppose. But the
comment could surely do with improving a little - at the very least
"yet we return "false"" isn't quite right; minimally there's a "may"
missing.

In principle, without any nrspin_*() functions, the result here ought
to be usable generally, not just for ASSERT()s. Whether having its
and _spin_is_locked()'s behavior differ would be a good idea is a
separate question, of course.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Mar 18 14:59:33 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 14:59:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694777.1083887 (Exim 4.92)
	(envelope-from )
	id 1rmESa-0000wc-Cf; Mon, 18 Mar 2024 14:59:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694777.1083887; Mon, 18 Mar 2024 14:59:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmESa-0000wU-9r; Mon, 18 Mar 2024 14:59:32 +0000
Received: by outflank-mailman (input) for mailman id 694777;
 Mon, 18 Mar 2024 14:59:31 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmESZ-0000wO-Cb
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 14:59:31 +0000
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com
 [2a00:1450:4864:20::536])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1ebac03b-e538-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 15:59:29 +0100 (CET)
Received: by mail-ed1-x536.google.com with SMTP id
 4fb4d7f45d1cf-55a179f5fa1so5142530a12.0
 for ; Mon, 18 Mar 2024 07:59:29 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 eo14-20020a056402530e00b00568a1897dbesm4440379edb.77.2024.03.18.07.59.28
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 18 Mar 2024 07:59:28 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1ebac03b-e538-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710773969; x=1711378769; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=3riX+v6dfd9+Zjk5Yj5hZvN8xcEUeV+FYYHRvgqoxRA=;
        b=EhND6e9Q42fyZp6kPv5o953d9Y8I3Z/f6uAmyFR4acWbwT9leMY6RlTERHqgnRuYcH
         p5XuDwUCP2sFelMaQVndM3ps4A/SJT9PlM7WFD7GXwaovbS/tu/rhSjOjCGYxTC0w9oA
         TASDHyWtrsJIskClE28wAnYNVWDJ4yjPNx0DTn6ShT3pu0ksBZdHHqmObqmApkHohR5L
         VPNECltLbndvOyIZQJ49LN+qmhXzwlXu7PESVAgrcolIl5Y9/wyLVQOWQtAPvdBr/cur
         rBmrzgi0EisXh4IxfVXkKeDOiVNr3CxHn2CCxlEhwe50RAtOsaY0y9BQV3RwAwkWwanZ
         9hTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710773969; x=1711378769;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=3riX+v6dfd9+Zjk5Yj5hZvN8xcEUeV+FYYHRvgqoxRA=;
        b=M4/NiqZGj+4uM/D/JhWy0VOdHDJLYhIVpZROqoAldwStxx4iEYiVOQNYgeZhxQgnVb
         rhSAizDIzQ+jkZsUTxpMnYhB61kzO0zYVXwnCn6vKz+u36QRQaEProgYTyRwDBxe5F+n
         judfSH+CyWfBy2pRfbkIwjpJCBXobM5ZURkjGK9CsgTd7mNoRFE8+IiVNIDg8itJzBWd
         X3wb/u5s+D2ayWyQIFleSJp2414WEK7TdxXPcCkzDSljfbUEto4791kdOjAbzQgU2B+5
         3b75gyLLb/ImaAYX/MtNxC1RI00GbRvVwJnJkrUjipcq81o2K6n/EY9UuUPY6SrEclXr
         eOSQ==
X-Forwarded-Encrypted: i=1; AJvYcCUNmUYO+vRhQ/DCdOVsIHHIgRudSKxid5BnZ+qWV2pAe/yvT3j3B5heZcpI1htAe72KaCQJg1IiiN0yoy9MpcTbNsct2V2tGcdo5wkD9n4=
X-Gm-Message-State: AOJu0Yzrm0bMFz/WsyFYZFhx1b8EjNPI8q/wceS2t2WtxK/s3KZaH9UX
	qAZ1fqSfkn0qxg5l6iCklm1TmxwajJ5Qg01kBY+VSNvXGPPGUmnq7Yj26k3wWg==
X-Google-Smtp-Source: AGHT+IGWb42vkoX7Y8/zVVp8bLKmfVbJBri2tFhKl6S4eSBILILA8b5+enTgTDHwbS90Ke1dH4Craw==
X-Received: by 2002:a05:6402:4282:b0:568:7ad9:f2af with SMTP id g2-20020a056402428200b005687ad9f2afmr10509674edc.27.1710773968764;
        Mon, 18 Mar 2024 07:59:28 -0700 (PDT)
Message-ID: <6aa7699e-fe39-44d6-8781-c32147ff9581@suse.com>
Date: Mon, 18 Mar 2024 15:59:27 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 09/13] xen/spinlock: split recursive spinlocks from
 normal ones
Content-Language: en-US
To: Juergen Gross 
Cc: Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 xen-devel@lists.xenproject.org
References: <20240314072029.16937-1-jgross@suse.com>
 <20240314072029.16937-10-jgross@suse.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240314072029.16937-10-jgross@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 14.03.2024 08:20, Juergen Gross wrote:
> Recursive and normal spinlocks are sharing the same data structure for
> representation of the lock. This has two major disadvantages:
> 
> - it is not clear from the definition of a lock, whether it is intended
>   to be used recursive or not, while a mixture of both usage variants
>   needs to be
> 
> - in production builds (builds without CONFIG_DEBUG_LOCKS) the needed
>   data size of an ordinary spinlock is 8 bytes instead of 4, due to the
>   additional recursion data needed (associated with that the rwlock
>   data is using 12 instead of only 8 bytes)
> 
> Fix that by introducing a struct spinlock_recursive for recursive
> spinlocks only, and switch recursive spinlock functions to require
> pointers to this new struct.
> 
> This allows to check the correct usage at build time.
> 
> Signed-off-by: Juergen Gross 

Reviewed-by: Jan Beulich 




From xen-devel-bounces@lists.xenproject.org Mon Mar 18 15:00:17 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 15:00:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694779.1083897 (Exim 4.92)
	(envelope-from )
	id 1rmETJ-0002J3-Lq; Mon, 18 Mar 2024 15:00:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694779.1083897; Mon, 18 Mar 2024 15:00:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmETJ-0002Iw-IP; Mon, 18 Mar 2024 15:00:17 +0000
Received: by outflank-mailman (input) for mailman id 694779;
 Mon, 18 Mar 2024 15:00:16 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmETI-0002Ig-9R
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 15:00:16 +0000
Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com
 [2a00:1450:4864:20::52f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3a197cc0-e538-11ee-afdd-a90da7624cb6;
 Mon, 18 Mar 2024 16:00:15 +0100 (CET)
Received: by mail-ed1-x52f.google.com with SMTP id
 4fb4d7f45d1cf-56890b533aaso5049732a12.3
 for ; Mon, 18 Mar 2024 08:00:15 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 eo14-20020a056402530e00b00568a1897dbesm4440379edb.77.2024.03.18.08.00.14
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 18 Mar 2024 08:00:14 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3a197cc0-e538-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710774015; x=1711378815; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=YHqamr0gTEW8e7B50+a4ktySInOO/1ridk6aQsoXk/o=;
        b=UELAuUmfU7FU+i5tcC25L0dRHPJg9Xw/fSZatT1mL8aExMcXPIXqmH/3taZnBhxasN
         qcXWJgnbDLUv7gKvXTyJwF4oF3sntVTUByAuxgWPFjZKleYOSjQcKIG8EGJXzPTCuwTe
         IGJq6PFdpAHuLROpv+ggl5+fPxBzzH+nSQXJLpvhXDeT4GLkRmop9qiX553vwbOPJLLd
         xKcrdfs2zO+5rau4d3MzlIPMt+uD/ZGbABujuqTFnOyJyLd6BSUVqPAm/fWCLawF6uQl
         AdQZQQF3hin8uk8t4q0EUe3yx8+sBizt/VuW3TCQDqrWpAFof/8Y2D1YEnBz8DfXAWH4
         499w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710774015; x=1711378815;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=YHqamr0gTEW8e7B50+a4ktySInOO/1ridk6aQsoXk/o=;
        b=TAQ1DLDeku58Myvi4HVvpe+cESFc+Wf0sKy6onjmwErufCy010aF/tWa8UcJPCokXo
         XYMUJOELlymB/p95E3rYfJddtMl3LJhdXEPJWvPWz7RkC3z1z3957ALD3HWqfER8gk4Y
         esqStzDzQqCGPFYHX55T5e25XTCBq3O9Yqgp9jRVxFH1fPJHxTj4zU2u1yhYHaWQXKyX
         tOBRFtmBqfwH+xrkFeheNlvpXGDkIPhm7OeBGRnY9x2KCyKrzOJdum9dmehIKyiNUDgn
         vDeh0P5Iv67bHpapTq1NBg1nMy1X7JCRbfHE68VvSYxTnphFYaH2qfdSdvuFi9CU+AuJ
         JAbA==
X-Forwarded-Encrypted: i=1; AJvYcCVA3OJpUmbk7x/8yPO+RKjb2XSXPeiauKjARr4iqTPwirBdS/TiGB3e/+FvUT0CjI7+wt65wgjSCPpCBGF4R/7V7Ctoo2puAnN5FJfgX6o=
X-Gm-Message-State: AOJu0YyH+PCdYR78bQcxkRN2LVwd95iNGfxoptuJU67Fp2AaLfflkELZ
	Jwli0OthAFIiOP+ais3+1X0txOQJ/0QotMXc4nm2C3PDTOlQKCJg6PtwBUk+MQ==
X-Google-Smtp-Source: AGHT+IEaukdOFEr+1z7MEGZbQDmcIPUZF1zlEal+HfLqwP1jaEDk1RaTtl2DmezurIAH9aGlO2KAUA==
X-Received: by 2002:a05:6402:4149:b0:566:ab45:e6c5 with SMTP id x9-20020a056402414900b00566ab45e6c5mr9460492eda.28.1710774014769;
        Mon, 18 Mar 2024 08:00:14 -0700 (PDT)
Message-ID: <1385ed46-da4f-484e-b562-5b0d7ff038f0@suse.com>
Date: Mon, 18 Mar 2024 16:00:14 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 10/13] xen/spinlock: let all is_locked and trylock
 variants return bool
Content-Language: en-US
To: Juergen Gross 
Cc: Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 xen-devel@lists.xenproject.org
References: <20240314072029.16937-1-jgross@suse.com>
 <20240314072029.16937-11-jgross@suse.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240314072029.16937-11-jgross@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 14.03.2024 08:20, Juergen Gross wrote:
> Switch the remaining trylock and is_locked variants to return bool.
> 
> Signed-off-by: Juergen Gross 

Reviewed-by: Jan Beulich 




From xen-devel-bounces@lists.xenproject.org Mon Mar 18 15:08:23 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 15:08:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694785.1083911 (Exim 4.92)
	(envelope-from )
	id 1rmEb3-00030e-Ga; Mon, 18 Mar 2024 15:08:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694785.1083911; Mon, 18 Mar 2024 15:08:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmEb3-00030X-Cq; Mon, 18 Mar 2024 15:08:17 +0000
Received: by outflank-mailman (input) for mailman id 694785;
 Mon, 18 Mar 2024 15:08:16 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmEb2-00030R-DO
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 15:08:16 +0000
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com
 [2a00:1450:4864:20::633])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 58602026-e539-11ee-afdd-a90da7624cb6;
 Mon, 18 Mar 2024 16:08:15 +0100 (CET)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-a46ba1a05e0so163788866b.3
 for ; Mon, 18 Mar 2024 08:08:15 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 wp12-20020a170907060c00b00a3edb758561sm4913932ejb.129.2024.03.18.08.08.14
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 18 Mar 2024 08:08:14 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 58602026-e539-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710774495; x=1711379295; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=zKtRfYSXNNAlTQU1Ws/fz9PhPefaepws8tQvjzXo16s=;
        b=K6Gb19d/lQfAL2eKBGb7mqunc77+qhFrL63PuxLPckNzqjxVoQXBu+FGg0ILh6RSdh
         CKNvpvop1o7GLXn9JWcxKpQ9PjKDLla3B2twYq3qgrxysjdfDQ8FBwHKEJWDkXyaGSez
         LeA7/fqVS1XqWuJX/LBO5dAdYmJvHke3ueraZP8wEbB2XVY4lbnaqtQoVzxevG1uuEmz
         3ZqGu3GAfnToE8C6lg5j+BYNFc0qVJBu78r/+1GYQYL/p00uq8O9UHxFmZnTGwa2IBwG
         n47b3K9rWrn3aSZxKEqGeYcvQpB9S/XqqFMWK+gGDC8m3Wm8slJHT6eapVBu5mrDKNiW
         jUNw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710774495; x=1711379295;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=zKtRfYSXNNAlTQU1Ws/fz9PhPefaepws8tQvjzXo16s=;
        b=BFGA4Oidx9jE7JyFXXjQ2Dgz7+ij5Ql5AZDEdP4tk9/MJKkyUhoAudQ3auNL/SlRXb
         PojucBf/I5lCFWBJl98J4bUtH0ERuDTIoLIW1acDMd8JIL4rJxaRUIFwZbzeoT13E0pS
         rze6fpBLiqp9zulTX87YsexjIdNijHN8645j4mmXC8SzSzdoSUQvdP2mfZzKfZ//VSDt
         X+qUYHBVhTSF0eOGBP9DHNgZP45Em6wFxcl5xvyU7FVKQ4kX7ZDw7+rbgdOyMq/B4V1A
         q+MEtin9NQANpql+XguA95ziWvWFFo5nuBCpKfoEj/BWOo5ZGZHLxfzXwaVi+wHeP2Bk
         yy9Q==
X-Forwarded-Encrypted: i=1; AJvYcCUph24uF80n+ZFacrOvZ7PscoOk8Y1Hvz01rqUOluUesf8rIcP2vH7ftzqQCurLXhAYkgVRi2WQmkujgHghZZ9S7owo9s6IpmWNoZsGdcA=
X-Gm-Message-State: AOJu0YzIUx942nN8WRHirQna+YtNPkmkb3PFNsOeuNfrgqfWYk6ltOfe
	wR3yCZdmadC5fr/pr0AxsgiKNjZGj254rd190k2IiYYEXVnCm0kGbAFNp92B/A==
X-Google-Smtp-Source: AGHT+IE2zyrJe63RcGMDR0+QvWtLCTgkXo5f8mPkntft/qoFsOluGjNp13cidXafBeda2TiKeEa5fQ==
X-Received: by 2002:a17:906:dc43:b0:a45:5bc1:ac35 with SMTP id yz3-20020a170906dc4300b00a455bc1ac35mr7797792ejb.30.1710774494980;
        Mon, 18 Mar 2024 08:08:14 -0700 (PDT)
Message-ID: <37b4410d-8fc5-40c3-bff8-49eaae2298c4@suse.com>
Date: Mon, 18 Mar 2024 16:08:13 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 11/13] xen/spinlock: support higher number of cpus
Content-Language: en-US
To: Juergen Gross 
Cc: Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 xen-devel@lists.xenproject.org
References: <20240314072029.16937-1-jgross@suse.com>
 <20240314072029.16937-12-jgross@suse.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240314072029.16937-12-jgross@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 14.03.2024 08:20, Juergen Gross wrote:
> --- a/xen/include/xen/spinlock.h
> +++ b/xen/include/xen/spinlock.h
> @@ -8,16 +8,16 @@
>  #include 
>  #include 
>  
> -#define SPINLOCK_CPU_BITS  12
> +#define SPINLOCK_CPU_BITS  16
>  
>  #ifdef CONFIG_DEBUG_LOCKS
>  union lock_debug {
> -    uint16_t val;
> -#define LOCK_DEBUG_INITVAL 0xffff
> +    uint32_t val;
> +#define LOCK_DEBUG_INITVAL 0xffffffff

With this #define I can see the desire for using a fixed width type for "val".
However, ...

>      struct {
> -        uint16_t cpu:SPINLOCK_CPU_BITS;
> -#define LOCK_DEBUG_PAD_BITS (14 - SPINLOCK_CPU_BITS)
> -        uint16_t :LOCK_DEBUG_PAD_BITS;
> +        uint32_t cpu:SPINLOCK_CPU_BITS;
> +#define LOCK_DEBUG_PAD_BITS (30 - SPINLOCK_CPU_BITS)
> +        uint32_t :LOCK_DEBUG_PAD_BITS;

.. "unsigned int" ought to be fine for both of these.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Mar 18 15:31:25 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 15:31:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694799.1083928 (Exim 4.92)
	(envelope-from )
	id 1rmExF-0000g5-BX; Mon, 18 Mar 2024 15:31:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694799.1083928; Mon, 18 Mar 2024 15:31:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmExF-0000fy-8C; Mon, 18 Mar 2024 15:31:13 +0000
Received: by outflank-mailman (input) for mailman id 694799;
 Mon, 18 Mar 2024 15:31:12 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmExE-0000fT-F2
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 15:31:12 +0000
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com
 [2a00:1450:4864:20::62a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8bc695d0-e53c-11ee-afdd-a90da7624cb6;
 Mon, 18 Mar 2024 16:31:10 +0100 (CET)
Received: by mail-ej1-x62a.google.com with SMTP id
 a640c23a62f3a-a44ad785a44so529158466b.3
 for ; Mon, 18 Mar 2024 08:31:10 -0700 (PDT)
Received: from ?IPV6:2003:e5:873a:400:704b:6dbb:e7c0:786e?
 (p200300e5873a0400704b6dbbe7c0786e.dip0.t-ipconnect.de.
 [2003:e5:873a:400:704b:6dbb:e7c0:786e])
 by smtp.gmail.com with ESMTPSA id
 v17-20020a1709063bd100b00a46caa13e67sm719105ejf.105.2024.03.18.08.31.09
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 18 Mar 2024 08:31:09 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8bc695d0-e53c-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710775870; x=1711380670; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:references:cc:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=G9GIcfB6F1PaixOlBwvgYhZIcpTkWDg05vPZk8nkA5Q=;
        b=QJEGQnYJ52fxp0AbV6yuteUuoiiBORGVgLNf2OAShvPQ8fOTXZWKn82vNSjQbAeFbm
         MUAhufoG4KQhWEgXJo/h6GyS8DmAW0JdthpXiYCYj6MxBMAbt1A5yfdLr2O4ByjHU0W6
         nhpqsF2lCqF2ddA6KHbM8AoT9lr/jz+hjkHqSREG3mmOXjJkpk/VWVwlbQweUbFzXB5f
         ZrYz3Ild1516Fdu/mCg3lcZ9pWd8FsQaYX89neZZM9cKYlBxE9NPHjvZKMTSQFdWW7RO
         F8JfrOIm68I3IKUkgG5BGJ5doYQSCeMooqWNJHh6SbiOXge4qujFjJPUYiag9MHyylTq
         M/cA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710775870; x=1711380670;
        h=content-transfer-encoding:in-reply-to:from:references:cc:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=G9GIcfB6F1PaixOlBwvgYhZIcpTkWDg05vPZk8nkA5Q=;
        b=NjTGsCAv6cl0ubFD6SYX8tq3cbcWbEZ2qP10Oj3MJ5hMf4dIVK/AcfeNaFLE0bs4EV
         ULoxcaE8E8Bhhxit/C8114InaykzljKbC2Y0cEE01RjIcNGRC0WRfQR284CC7j5dlK7x
         1/KXxl7TeFWNSL6ZK4y31Kvtl3L3l+BcKBLC/g0uJRkCi0WW5R5QHhhHsBog1/JxqAos
         ASDx4A5twJ7n3JkhkXmqxsqEevyX7AYOwjQovI8TroTPt+Z2vMW9L+bj4sQRh9bWdzUS
         n3I3RWYyWn5bgZLZ6CQ+FgeLQHkBxxy9eDQs1KTqIsH9XTtP/piBymk3Devtz7tg5hSh
         OETQ==
X-Forwarded-Encrypted: i=1; AJvYcCWz2XT/0nXsitG2aTQh/og5V+JxQAwqcHA5pMPKxriAoHVxr3EWt9/CcR7KzxzcnRjsoM0AYetwofkCv7VlOjc4zveRSpUDKKtXxgDpo4Y=
X-Gm-Message-State: AOJu0Yx0kvIVYCRm07lAB4508Fy72qhqBCNwbD69mOEzDY1roRWXih09
	KWJ3XOWldi+1X03EZmCT6BGaIFu/nSvuQ9JJoj/K9Vw+54XhNo/lfM3WwLu6vVs=
X-Google-Smtp-Source: AGHT+IG1MVVqoVKJWTyL7mNMp+0xOrQ/Y2gSECy2cIzsPnS0Qzm/WtRZ1wVx6OcXMF9z/e7BaeNUQw==
X-Received: by 2002:a17:907:208a:b0:a46:636a:2c23 with SMTP id pv10-20020a170907208a00b00a46636a2c23mr7819179ejb.34.1710775869717;
        Mon, 18 Mar 2024 08:31:09 -0700 (PDT)
Message-ID: 
Date: Mon, 18 Mar 2024 16:31:08 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 08/13] xen/spinlock: add missing rspin_is_locked() and
 rspin_barrier()
Content-Language: en-US
To: Jan Beulich 
Cc: Andrew Cooper ,
 George Dunlap ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu
 , Julien Grall ,
 Stefano Stabellini , Paul Durrant ,
 xen-devel@lists.xenproject.org
References: <20240314072029.16937-1-jgross@suse.com>
 <20240314072029.16937-9-jgross@suse.com>
 
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 18.03.24 15:57, Jan Beulich wrote:
> On 14.03.2024 08:20, Juergen Gross wrote:
>> --- a/xen/common/spinlock.c
>> +++ b/xen/common/spinlock.c
>> @@ -395,14 +395,7 @@ static bool always_inline spin_is_locked_common(const spinlock_tickets_t *t)
>>   
>>   int _spin_is_locked(const spinlock_t *lock)
>>   {
>> -    /*
>> -     * Recursive locks may be locked by another CPU, yet we return
>> -     * "false" here, making this function suitable only for use in
>> -     * ASSERT()s and alike.
>> -     */
>> -    return lock->recurse_cpu == SPINLOCK_NO_CPU
>> -           ? spin_is_locked_common(&lock->tickets)
>> -           : lock->recurse_cpu == smp_processor_id();
>> +    return spin_is_locked_common(&lock->tickets);
>>   }
> 
> The "only suitable for ASSERT()s and alike" part of the comment wants
> to survive here, I think.

Why?

I could understand you asking for putting such a comment to spinlock.h
mentioning that any *_is_locked() variant isn't safe, but with
_spin_is_locked() no longer covering recursive locks the comment's reasoning
is no longer true.

> 
>> @@ -465,6 +458,23 @@ void _spin_barrier(spinlock_t *lock)
>>       spin_barrier_common(&lock->tickets, &lock->debug, LOCK_PROFILE_PAR);
>>   }
>>   
>> +bool _rspin_is_locked(const rspinlock_t *lock)
>> +{
>> +    /*
>> +     * Recursive locks may be locked by another CPU, yet we return
>> +     * "false" here, making this function suitable only for use in
>> +     * ASSERT()s and alike.
>> +     */
>> +    return lock->recurse_cpu == SPINLOCK_NO_CPU
>> +           ? spin_is_locked_common(&lock->tickets)
>> +           : lock->recurse_cpu == smp_processor_id();
>> +}
> 
> Here otoh I wonder if both the comment and the spin_is_locked_common()
> part of the condition are actually correct. Oh, the latter needs
> retaining as long as we have nrspin_*() functions, I suppose. But the
> comment could surely do with improving a little - at the very least
> "yet we return "false"" isn't quite right; minimally there's a "may"
> missing.

If anything I guess the comment shouldn't gain a "may", but rather say
"Recursive locks may be locked by another CPU via rspin_lock() ..."


Juergen


From xen-devel-bounces@lists.xenproject.org Mon Mar 18 15:39:27 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 15:39:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694807.1083939 (Exim 4.92)
	(envelope-from )
	id 1rmF59-0001cp-51; Mon, 18 Mar 2024 15:39:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694807.1083939; Mon, 18 Mar 2024 15:39:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmF59-0001ci-0E; Mon, 18 Mar 2024 15:39:23 +0000
Received: by outflank-mailman (input) for mailman id 694807;
 Mon, 18 Mar 2024 15:39:21 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmF57-0001cc-NB
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 15:39:21 +0000
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com
 [2a00:1450:4864:20::52b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b0119930-e53d-11ee-afdd-a90da7624cb6;
 Mon, 18 Mar 2024 16:39:20 +0100 (CET)
Received: by mail-ed1-x52b.google.com with SMTP id
 4fb4d7f45d1cf-565c6cf4819so9612481a12.1
 for ; Mon, 18 Mar 2024 08:39:20 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 l20-20020a1709067d5400b00a46bed423a0sm1206029ejp.23.2024.03.18.08.39.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 18 Mar 2024 08:39:19 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b0119930-e53d-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710776360; x=1711381160; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=DDTDpfEiXD+aZF0PiU/LCyHoU9KWxY8KaDB5BaW2EyA=;
        b=KnsolgRC7QdO+YerUANanQEe5DwgD+tN6SGc7/1cmqbpgumKpRczzNAdk6GDp27y9a
         j4XxC5Gsy7arNv4ZFrnaIFn3y2t0o7f4fAINp9tRZyZX5KsKnoFBB5tu7bQWkj+GcjtI
         DzNgfjv6uCRL2pux9GeC8rCKUBb4BIsEau+q0icMy1hPNVgPJDFhcNTKhNvahdm1c1Jx
         MbfX3ppWbR/WOU2yJ4/bId8zz3wPMQF7lQ+1KNzEfFBfTD924jRU3bP4iVghdwdgQHsg
         oOfkcim8WAIPxL3ZvSM0HnDAtWd2S9Kt/K9xJA5/NlB8snpQOsVa5sd1XVBlxn/q2DoK
         O6vQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710776360; x=1711381160;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=DDTDpfEiXD+aZF0PiU/LCyHoU9KWxY8KaDB5BaW2EyA=;
        b=F30OdWCJj15Xc7my9oow5kYN3SJyfQ+b8WrYI0h+eN/8gmwKrA7sOA5Rssca4bCzY4
         sGRqZ9vYtrwCnWbkWUTl3yX/QnbckODVlibwuSszp7S/c8cF55OMxnLtm1rapDxuigtw
         T2YxRehZfVqfp5Y8LORfZ2IRsYicfZO8fQwJIvi960VoWe/Z6sZuESkJs5Al07MqJ7A+
         an92a1M4DbDpStui1kBCmyKJhLwf8ntpRh4HT2ktrrOsdlRKDbdu2Nmpq5yEDdmInLrx
         je3/8ILqh1335ex2V3GhMFHSZWlY8Z9FQoZL7xjSwMu1pNNgYms5bBdLQEZISGjpZxtW
         IEnw==
X-Forwarded-Encrypted: i=1; AJvYcCXAC9yG0BeZvQ2xmxR0h+7wh6L0PrXPj5vqE57zke0a6II9W8ujIINcUXET0xE6z3EHjWF5+bB8H2W+LHT4hav5VM2dUjj5PL2H8gQMqw0=
X-Gm-Message-State: AOJu0YzK3oWa66VUmIscCW55SEk76smcKhOdZgUIpG3sSwx9dNMbZhrF
	59eRtWcUmx3BxwU+y7rO/hhI6iyBWSLw1qRcGsN8ssAeKVd/e52+KZ83bM7sMA==
X-Google-Smtp-Source: AGHT+IHFZKroyKBiKJeJgdK3makNuOOPD2WCAaFhKctkbvI1gCAIvw8tqUdLKsTfsmGkqaYQsZcqdQ==
X-Received: by 2002:a17:907:2d26:b0:a46:8a8c:6075 with SMTP id gs38-20020a1709072d2600b00a468a8c6075mr9323772ejc.5.1710776360022;
        Mon, 18 Mar 2024 08:39:20 -0700 (PDT)
Message-ID: 
Date: Mon, 18 Mar 2024 16:39:18 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 12/13] xen/rwlock: raise the number of possible cpus
Content-Language: en-US
To: Juergen Gross 
Cc: Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 xen-devel@lists.xenproject.org
References: <20240314072029.16937-1-jgross@suse.com>
 <20240314072029.16937-13-jgross@suse.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240314072029.16937-13-jgross@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 14.03.2024 08:20, Juergen Gross wrote:
> The rwlock handling is limiting the number of cpus to 4095 today. The
> main reason is the use of the atomic_t data type for the main lock
> handling, which needs 2 bits for the locking state (writer waiting or
> write locked), 12 bits for the id of a possible writer, and a 12 bit
> counter for readers. The limit isn't 4096 due to an off by one sanity
> check.
> 
> The atomic_t data type is 32 bits wide, so in theory 15 bits for the
> writer's cpu id and 15 bits for the reader count seem to be fine, but
> via read_trylock() more readers than cpus are possible.

As a result, afaict you choose to use just 14 bits for the CPU, but
still 15 bits (with the 16th to deal with overflow) for the reader count.
That could do with making explicit here, as a question is whether we
deem as sufficient that there is just one extra bit for the reader
count.

> --- a/xen/include/xen/rwlock.h
> +++ b/xen/include/xen/rwlock.h
> @@ -23,12 +23,12 @@ typedef struct {
>  #define rwlock_init(l) (*(l) = (rwlock_t)RW_LOCK_UNLOCKED)
>  
>  /* Writer states & reader shift and bias. */
> -#define    _QW_CPUMASK  0xfffU             /* Writer CPU mask */
> -#define    _QW_SHIFT    12                 /* Writer flags shift */
> -#define    _QW_WAITING  (1U << _QW_SHIFT)  /* A writer is waiting */
> -#define    _QW_LOCKED   (3U << _QW_SHIFT)  /* A writer holds the lock */
> -#define    _QW_WMASK    (3U << _QW_SHIFT)  /* Writer mask */
> -#define    _QR_SHIFT    14                 /* Reader count shift */
> +#define    _QW_SHIFT    14                      /* Writer flags shift */
> +#define    _QW_CPUMASK  ((1U << _QW_SHIFT) - 1) /* Writer CPU mask */
> +#define    _QW_WAITING  (1U << _QW_SHIFT)       /* A writer is waiting */
> +#define    _QW_LOCKED   (3U << _QW_SHIFT)       /* A writer holds the lock */
> +#define    _QW_WMASK    (3U << _QW_SHIFT)       /* Writer mask */
> +#define    _QR_SHIFT    (_QW_SHIFT + 2)         /* Reader count shift */
>  #define    _QR_BIAS     (1U << _QR_SHIFT)

Btw, seeing all the uppercase U suffixes here, I think you had some
lowercase ones earlier in the series. While Misra doesn't demand
uppercase for U, it does for L and iirc we decided to use all
uppercase suffixes as a result. Would be nice if what goes in could
have this correct right away.

> @@ -36,14 +36,16 @@ void queue_write_lock_slowpath(rwlock_t *lock);
>  
>  static inline bool _is_write_locked_by_me(unsigned int cnts)
>  {
> -    BUILD_BUG_ON(_QW_CPUMASK < NR_CPUS);
> +    BUILD_BUG_ON((_QW_CPUMASK + 1) < NR_CPUS);
> +    BUILD_BUG_ON(NR_CPUS * _QR_BIAS > INT_MAX);
>      return (cnts & _QW_WMASK) == _QW_LOCKED &&
>             (cnts & _QW_CPUMASK) == smp_processor_id();
>  }
>  
>  static inline bool _can_read_lock(unsigned int cnts)
>  {
> -    return !(cnts & _QW_WMASK) || _is_write_locked_by_me(cnts);
> +    return cnts <= INT_MAX &&
> +           (!(cnts & _QW_WMASK) || _is_write_locked_by_me(cnts));
>  }

I view this as problematic: Code knowing that a write lock is being held
may invoke a function using read_trylock() and expect the lock to be
available there.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Mar 18 15:45:00 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 15:45:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694812.1083948 (Exim 4.92)
	(envelope-from )
	id 1rmFAU-0003YC-Qu; Mon, 18 Mar 2024 15:44:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694812.1083948; Mon, 18 Mar 2024 15:44:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmFAU-0003Y5-Nr; Mon, 18 Mar 2024 15:44:54 +0000
Received: by outflank-mailman (input) for mailman id 694812;
 Mon, 18 Mar 2024 15:44:53 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmFAT-0003Xz-AS
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 15:44:53 +0000
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com
 [2a00:1450:4864:20::62d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 752ebf22-e53e-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 16:44:51 +0100 (CET)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-a44ad785a44so531383766b.3
 for ; Mon, 18 Mar 2024 08:44:51 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 g17-20020a17090670d100b00a46a04d7dc4sm3045410ejk.61.2024.03.18.08.44.50
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 18 Mar 2024 08:44:50 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 752ebf22-e53e-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710776691; x=1711381491; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=KL7DNASydYh7/Nnby9dmK1L4kzHGl7aNreX8OwqpHNc=;
        b=HXg1p8NqRB5mUI9Sxg8YMZ6qmPIT+6CiIcr1ZsF7zkfKfVyZXpmtILOcpWbhaLvkJC
         9hXOmtBN04ob7hrNus5icsM1p1zgH4A+wffYdUgIUhMf/qIDGZYTuLChUEdTIghRaHAg
         hjhYcHrC3x7DpJjoam0LuzEIKNa8qVZ4QjPK2vZx+2i6iXLsITdC4c4o9gAX84EI9Eqr
         U8M/P8iE+iMgZUB+g+nmNeds8OIU697zKEeEhVWCeehuAzNU/LRbiLLtbVS0rbw4jd9A
         tka0NzPpHJdCMa2HPCb30UgEvx2gWNhCnh4oPUqJ4BDiZKSp8dvA8OD3Izp6G7p0vF27
         lNlg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710776691; x=1711381491;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=KL7DNASydYh7/Nnby9dmK1L4kzHGl7aNreX8OwqpHNc=;
        b=NgHFC4G3+PkqF6WKU+AakMoMXNhNUqDVhscLOKfgDjjQrSQ5X6OH5oR1dNdEZ5Dzf9
         Q6Q3BUKSzNBd93qpnYNUq2tE7WPkICKJgETNrOlMjV7nbBvaTwMGSNwtdrtXgJhj/AyF
         77WC28aHaI82kQP+WwbPj9zPKKnHMiWk23DdbTxUJ1NEPcnW9J2FcngrJAXzmhGOptmE
         euKUYQJr3UCQ0FfGcScbJCS44zqY8uvMsr8d1yWWTPkxcUVI+o4l6lqNwMHsAbPGUtCc
         6BG9ikup03wrRYtNrEngOiYgD5if6XKKJ3giLjtGQESVIHvY5O7YeHQ6rjxD88SETe0R
         U+sg==
X-Forwarded-Encrypted: i=1; AJvYcCX5b870Z9Ax8TvrxN/X+q8s6GaLlH9Vk1sAM/oIZf9Q/jvkvMS/+iLqXmOTUpUXpxDhbN0M666JrraNl7i0pbjQBfReY/j7W7xdPY4lypw=
X-Gm-Message-State: AOJu0YwNT3V4MHOwVzsMpbqJoPqkcjlzejkOPec3X8ufDSbGVAtK+9Tn
	p6HCbHMz5oeptdtjTAQQYWHhdB0xl8lpOhMc1+vrF7izpmQAtRjD7iMy5TXqIw==
X-Google-Smtp-Source: AGHT+IGLstH1DTXFtC+UbFWA1/l3lDRMWJvUU64qSfJKfB3TqKRtcKkeep0VPtiIQSjSK0edwiN9Ug==
X-Received: by 2002:a17:906:2c1a:b0:a46:bde3:91ec with SMTP id e26-20020a1709062c1a00b00a46bde391ecmr2243639ejh.52.1710776690784;
        Mon, 18 Mar 2024 08:44:50 -0700 (PDT)
Message-ID: 
Date: Mon, 18 Mar 2024 16:44:49 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 08/13] xen/spinlock: add missing rspin_is_locked() and
 rspin_barrier()
Content-Language: en-US
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
Cc: Andrew Cooper ,
 George Dunlap ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu
 , Julien Grall ,
 Stefano Stabellini , Paul Durrant ,
 xen-devel@lists.xenproject.org
References: <20240314072029.16937-1-jgross@suse.com>
 <20240314072029.16937-9-jgross@suse.com>
 
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 18.03.2024 16:31, Jürgen Groß wrote:
> On 18.03.24 15:57, Jan Beulich wrote:
>> On 14.03.2024 08:20, Juergen Gross wrote:
>>> --- a/xen/common/spinlock.c
>>> +++ b/xen/common/spinlock.c
>>> @@ -395,14 +395,7 @@ static bool always_inline spin_is_locked_common(const spinlock_tickets_t *t)
>>>   
>>>   int _spin_is_locked(const spinlock_t *lock)
>>>   {
>>> -    /*
>>> -     * Recursive locks may be locked by another CPU, yet we return
>>> -     * "false" here, making this function suitable only for use in
>>> -     * ASSERT()s and alike.
>>> -     */
>>> -    return lock->recurse_cpu == SPINLOCK_NO_CPU
>>> -           ? spin_is_locked_common(&lock->tickets)
>>> -           : lock->recurse_cpu == smp_processor_id();
>>> +    return spin_is_locked_common(&lock->tickets);
>>>   }
>>
>> The "only suitable for ASSERT()s and alike" part of the comment wants
>> to survive here, I think.
> 
> Why?
> 
> I could understand you asking for putting such a comment to spinlock.h
> mentioning that any *_is_locked() variant isn't safe, but with
> _spin_is_locked() no longer covering recursive locks the comment's reasoning
> is no longer true.

Hmm. I guess there is a difference in expectations. To me, these
functions in principle ought to report whether the lock is "owned",
not just "locked by some CPU". They don't, hence why they may not be
used for other than ASSERT()s.

As to the reasoning no longer being applicable here: That's why I
asked to only retain the "only ASSERT()s" part of the comment. Yes,
such a comment may also be suitable to have in spinlock.h. What I'd
like to avoid is for it to be lost altogether.

Jan

>>> @@ -465,6 +458,23 @@ void _spin_barrier(spinlock_t *lock)
>>>       spin_barrier_common(&lock->tickets, &lock->debug, LOCK_PROFILE_PAR);
>>>   }
>>>   
>>> +bool _rspin_is_locked(const rspinlock_t *lock)
>>> +{
>>> +    /*
>>> +     * Recursive locks may be locked by another CPU, yet we return
>>> +     * "false" here, making this function suitable only for use in
>>> +     * ASSERT()s and alike.
>>> +     */
>>> +    return lock->recurse_cpu == SPINLOCK_NO_CPU
>>> +           ? spin_is_locked_common(&lock->tickets)
>>> +           : lock->recurse_cpu == smp_processor_id();
>>> +}
>>
>> Here otoh I wonder if both the comment and the spin_is_locked_common()
>> part of the condition are actually correct. Oh, the latter needs
>> retaining as long as we have nrspin_*() functions, I suppose. But the
>> comment could surely do with improving a little - at the very least
>> "yet we return "false"" isn't quite right; minimally there's a "may"
>> missing.
> 
> If anything I guess the comment shouldn't gain a "may", but rather say
> "Recursive locks may be locked by another CPU via rspin_lock() ..."
> 
> 
> Juergen



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 15:49:45 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 15:49:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694831.1083974 (Exim 4.92)
	(envelope-from )
	id 1rmFF9-0005Er-NW; Mon, 18 Mar 2024 15:49:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694831.1083974; Mon, 18 Mar 2024 15:49:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmFF9-0005Ek-KR; Mon, 18 Mar 2024 15:49:43 +0000
Received: by outflank-mailman (input) for mailman id 694831;
 Mon, 18 Mar 2024 15:49:42 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmFF8-0005EW-Hp
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 15:49:42 +0000
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com
 [2a00:1450:4864:20::52c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 219fd712-e53f-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 16:49:40 +0100 (CET)
Received: by mail-ed1-x52c.google.com with SMTP id
 4fb4d7f45d1cf-56829f41f81so6310253a12.2
 for ; Mon, 18 Mar 2024 08:49:40 -0700 (PDT)
Received: from ?IPV6:2003:e5:873a:400:704b:6dbb:e7c0:786e?
 (p200300e5873a0400704b6dbbe7c0786e.dip0.t-ipconnect.de.
 [2003:e5:873a:400:704b:6dbb:e7c0:786e])
 by smtp.gmail.com with ESMTPSA id
 cf13-20020a0564020b8d00b00569731a1eb2sm1332485edb.46.2024.03.18.08.49.39
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 18 Mar 2024 08:49:39 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 219fd712-e53f-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710776980; x=1711381780; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:references:cc:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=wUV2XqQza7lh7Z9gxvg1e3DFAK1zWnksTDOLlHqEAkY=;
        b=GCVS9vgAYSTmI11CLFKfyG0+obFmC+2F/SNsCbS8bgqSK+tGGfnkUjMbJVAyVfalmZ
         a6yoNM/haGV9cU/DZdCwoklXWf4aHlMpKQFRLcCxQu/MbceC9Eoj98xS827bZroMffN1
         SFw++gLA2FE718DPUzzj+mm39fLEHiQDtJ4is8aq7lPky3ZMSnrfAU5PdAWcrpeH04vW
         +hLVzgQ3588uSUrZP/WV3it7t4EoHM60z7W3/VhprORnLr0DIKk9ukqPxroxCQmq4vTM
         Qqwa7kLPFZX6CEBs0+vhHPuj114ZNc0/XbD4mgJbVbnikp3RwQTUr5BN4nzG9UpGK2uc
         wNMQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710776980; x=1711381780;
        h=content-transfer-encoding:in-reply-to:from:references:cc:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=wUV2XqQza7lh7Z9gxvg1e3DFAK1zWnksTDOLlHqEAkY=;
        b=mLBMXgdLRH7KomqY4IOO+qoaH3m/aTQaE8TLZL9WO4QPs2soSy82lBfXPC/pV7R9Gj
         NaqkJoBjap9QiL9QG2/DxcC/kz+mmUwVhJ6yyoFBNpF3HtL+gTtv7M0ZKAyanT+Qr5KQ
         o567Km9n1dkYtk7ODVaksL6SFHuWZGHduu3eV36/VheP9Udc5c4EnSYZR4IixyM2zZWu
         OZsIWt7wCws9049AfPfHbRKIKsTTZgoo7tE6DMaT3YTDAGEtRT3h2nedsHi3CFHCv3Uk
         NJZJu4jRf3rnL34HAG3UClHQrGFcb/bHxcKIOQhGOyO9oQWjL8sQ/no7t5QIK43tseBC
         yZuQ==
X-Forwarded-Encrypted: i=1; AJvYcCWA0w2mjON6ySePDZoh4ILzsB9YBC5MDo0K3R68hC7dsWiaiwV520XhlF50M3QU9kojlUb2vFLxwUl7uwumIQ2EiRd9CTeuCEWPPE/sW60=
X-Gm-Message-State: AOJu0Yy7pOs8XcTcSoSaMM6/xjUEMLfTzkRBRi7eJxsOYpXXp2VxBxMY
	5SLiWzF11G5mtzslnQvgqhwrkxZ33FhZiIKwAat/foS0h6PIBGsqVWi3/a04pMc=
X-Google-Smtp-Source: AGHT+IGG2F9tc9AENOeLchADcnW+T578qfq5oq+avDI9GfHDfpZu+hQyGGuYqxelY9JDronlgGimDA==
X-Received: by 2002:a05:6402:2401:b0:568:a05e:eafd with SMTP id t1-20020a056402240100b00568a05eeafdmr10636679eda.39.1710776980111;
        Mon, 18 Mar 2024 08:49:40 -0700 (PDT)
Message-ID: 
Date: Mon, 18 Mar 2024 16:49:39 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 08/13] xen/spinlock: add missing rspin_is_locked() and
 rspin_barrier()
Content-Language: en-US
To: Jan Beulich 
Cc: Andrew Cooper ,
 George Dunlap ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu
 , Julien Grall ,
 Stefano Stabellini , Paul Durrant ,
 xen-devel@lists.xenproject.org
References: <20240314072029.16937-1-jgross@suse.com>
 <20240314072029.16937-9-jgross@suse.com>
 
 
 
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 18.03.24 16:44, Jan Beulich wrote:
> On 18.03.2024 16:31, Jürgen Groß wrote:
>> On 18.03.24 15:57, Jan Beulich wrote:
>>> On 14.03.2024 08:20, Juergen Gross wrote:
>>>> --- a/xen/common/spinlock.c
>>>> +++ b/xen/common/spinlock.c
>>>> @@ -395,14 +395,7 @@ static bool always_inline spin_is_locked_common(const spinlock_tickets_t *t)
>>>>    
>>>>    int _spin_is_locked(const spinlock_t *lock)
>>>>    {
>>>> -    /*
>>>> -     * Recursive locks may be locked by another CPU, yet we return
>>>> -     * "false" here, making this function suitable only for use in
>>>> -     * ASSERT()s and alike.
>>>> -     */
>>>> -    return lock->recurse_cpu == SPINLOCK_NO_CPU
>>>> -           ? spin_is_locked_common(&lock->tickets)
>>>> -           : lock->recurse_cpu == smp_processor_id();
>>>> +    return spin_is_locked_common(&lock->tickets);
>>>>    }
>>>
>>> The "only suitable for ASSERT()s and alike" part of the comment wants
>>> to survive here, I think.
>>
>> Why?
>>
>> I could understand you asking for putting such a comment to spinlock.h
>> mentioning that any *_is_locked() variant isn't safe, but with
>> _spin_is_locked() no longer covering recursive locks the comment's reasoning
>> is no longer true.
> 
> Hmm. I guess there is a difference in expectations. To me, these
> functions in principle ought to report whether the lock is "owned",
> not just "locked by some CPU". They don't, hence why they may not be
> used for other than ASSERT()s.

Okay, thanks for clarification. I'll change the comment accordingly.


Juergen


From xen-devel-bounces@lists.xenproject.org Mon Mar 18 15:52:52 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 15:52:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694838.1083983 (Exim 4.92)
	(envelope-from )
	id 1rmFI7-0007QK-3Z; Mon, 18 Mar 2024 15:52:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694838.1083983; Mon, 18 Mar 2024 15:52:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmFI7-0007QD-14; Mon, 18 Mar 2024 15:52:47 +0000
Received: by outflank-mailman (input) for mailman id 694838;
 Mon, 18 Mar 2024 15:52:46 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmFI6-0007Q0-0P
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 15:52:46 +0000
Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com
 [2607:f8b0:4864:20::f2b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8f8c289a-e53f-11ee-afdd-a90da7624cb6;
 Mon, 18 Mar 2024 16:52:45 +0100 (CET)
Received: by mail-qv1-xf2b.google.com with SMTP id
 6a1803df08f44-690fed6816fso31208676d6.1
 for ; Mon, 18 Mar 2024 08:52:45 -0700 (PDT)
Received: from localhost ([85.31.135.62]) by smtp.gmail.com with ESMTPSA id
 11-20020ad45bab000000b0069046d929a3sm5363281qvq.145.2024.03.18.08.52.43
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 18 Mar 2024 08:52:44 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8f8c289a-e53f-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710777164; x=1711381964; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=g1SXh3TRJWNRoXlu8AMgOkJ0X83NQ6GJjyvwMEEkrD0=;
        b=S7dVcuuF6kU8uAIMapQ6r3lpu9s2oe0+c8/E4uMaEW4UXEYBCjziCAiJeFJ9V+x2Ye
         I6jEMVqAu76VjaxsUCjj2y/TAArJczPJfbBJ/rb+2NmV9eSpFOsixpdE21apydj5vRBh
         111ma/ps40weYTUXJ2gDnKgJIKAw5Kv/L3B18=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710777164; x=1711381964;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=g1SXh3TRJWNRoXlu8AMgOkJ0X83NQ6GJjyvwMEEkrD0=;
        b=oioasCQrcrj95bEuPUVSVN+zUhNnCqE1xykG5JkumSDtyqxRQrQIx/sGVAigeJic6f
         AwOrKlKSCcwZOc7EcpF/eDDNXVCstaDesR9tNc1rDGO2TFbez/Ob7eNBTs2/9hshwA9w
         STd1cCey+zU8plqDt68gc90NqbMyWgpXcNrizgsZCEk7SuORnJn+eJHnWpVMkqO8R3NN
         KtFokZZgI8BCPCwcUSIyIG3BESa1iEzlDvnCcQyvZpZUDy0RCISlnGaIhAvhtNQhOOa2
         iCbD/o0K14sTLSUdKF7UL/v47ta716WVi8v0DRJcLpQeaXh5AluxjXo7JhcqcAlTQr7u
         yQpQ==
X-Forwarded-Encrypted: i=1; AJvYcCV+H2QyorSHjBU+wo33LF91/u5pwRGVQxHGouBmZskcFrI5z2umm1/A0BC9Sv3PN8LZbJuwrIJwYoBBgApfZ2Nf0BYzMTQGuxCHmvlgoJY=
X-Gm-Message-State: AOJu0Yx4zTIMQBvjmoUrhfFhlfARk6ZQ8sqRnJIFOJvzqd8ZZySNtzBY
	qaqNyr3Ph8VkRLmORXngvsQmp/LglMSSoX+h75VAkB7EgVNV2bBlBXDev/Dz9+g=
X-Google-Smtp-Source: AGHT+IE7qr1H6LtG96P5eYjKxk7LFvzAzPmHAEhBL2oxWpFILpALXkEOM8Pxk9mAG8kqmhbdnyXQoQ==
X-Received: by 2002:a0c:e3c2:0:b0:691:46ee:6abc with SMTP id e2-20020a0ce3c2000000b0069146ee6abcmr13458520qvl.3.1710777164430;
        Mon, 18 Mar 2024 08:52:44 -0700 (PDT)
Date: Mon, 18 Mar 2024 16:52:42 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= ,
	Andrew Cooper ,
	George Dunlap ,
	Julien Grall ,
	Stefano Stabellini , Wei Liu ,
	Paul Durrant , xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 1/2] IOMMU: store name for extra reserved device memory
Message-ID: 
References: <20240312162541.384793-1-marmarek@invisiblethingslab.com>
 <3ab49282-6b67-4ab0-bb65-f04c62bcadcb@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <3ab49282-6b67-4ab0-bb65-f04c62bcadcb@suse.com>

On Mon, Mar 18, 2024 at 02:40:21PM +0100, Jan Beulich wrote:
> On 12.03.2024 17:25, Marek Marczykowski-Górecki wrote:
> > It will be useful for error reporting in a subsequent patch.
> > 
> > Signed-off-by: Marek Marczykowski-Górecki 
> 
> In principle
> Acked-by: Jan Beulich 
> However, ...
> 
> > --- a/xen/drivers/passthrough/iommu.c
> > +++ b/xen/drivers/passthrough/iommu.c
> > @@ -682,6 +682,7 @@ struct extra_reserved_range {
> >      unsigned long start;
> >      unsigned long nr;
> >      pci_sbdf_t sbdf;
> > +    const char *name;
> >  };
> 
> ... to me "descr" (or the longer "description") would seem more suitable.
> Thoughts?

I'm happy either way, but I don't find 'name' odd.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Mon Mar 18 15:55:30 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 15:55:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694842.1083994 (Exim 4.92)
	(envelope-from )
	id 1rmFKh-0007zx-HC; Mon, 18 Mar 2024 15:55:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694842.1083994; Mon, 18 Mar 2024 15:55:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmFKh-0007zq-E7; Mon, 18 Mar 2024 15:55:27 +0000
Received: by outflank-mailman (input) for mailman id 694842;
 Mon, 18 Mar 2024 15:55:25 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmFKf-0007zk-SQ
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 15:55:25 +0000
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com
 [2a00:1450:4864:20::629])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ee146862-e53f-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 16:55:23 +0100 (CET)
Received: by mail-ej1-x629.google.com with SMTP id
 a640c23a62f3a-a46805cd977so453034566b.0
 for ; Mon, 18 Mar 2024 08:55:23 -0700 (PDT)
Received: from ?IPV6:2003:e5:873a:400:704b:6dbb:e7c0:786e?
 (p200300e5873a0400704b6dbbe7c0786e.dip0.t-ipconnect.de.
 [2003:e5:873a:400:704b:6dbb:e7c0:786e])
 by smtp.gmail.com with ESMTPSA id
 d20-20020a1709067f1400b00a468bcde79bsm3745619ejr.109.2024.03.18.08.55.22
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 18 Mar 2024 08:55:23 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ee146862-e53f-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710777323; x=1711382123; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:references:cc:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=dUEPalGmDXdpQ5eI8mLGAlTuARjS7QQ1V8I4dDK1z9g=;
        b=PW7fPvrSAS5vX6XQUOVgE6VDArsAz6fz/9Kbl0feTgmRoKFoMgY+MM32hLpF+6+jIh
         7cezVfLKrL8fGcErsZ5EFfcmXRIMqqcAWIiUx2zFjO++7M/Hqw5Oj8r2Hp8rkd3a0O4u
         GV9tHWHeqkDb28D9du6egdOHurD5bj8/iWEFe196baWfbhhZksC/OJsMVxD7EbojA7gV
         mq5yufwOiwXdxhhce8y3JJ1KGZ8fpCqYuVjeO0K6NLvpIQLoOG6S3YjfFkTK8fXM5Fhm
         FVwdn+64QDv4UIn6shyruvNwc/Fk72qvpFB3NSAO4kKPaScRVMmkp+cqeCaWwWUTem5Y
         9Xiw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710777323; x=1711382123;
        h=content-transfer-encoding:in-reply-to:from:references:cc:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=dUEPalGmDXdpQ5eI8mLGAlTuARjS7QQ1V8I4dDK1z9g=;
        b=EpnPhbPvBfm/1CKOtnV8AsJWwYSFvM5RG/Tbh6sU6p9bP3qqQ4k4OiJXMaHPpxYjEa
         wn8YrNo3Iww9icxR8b9rvzrE4f/0s6OP3cxDFnk71dwKa1Qq0OsTGv5MYpFzD4ySfVVa
         mjbHszGtom/Ae89MDYjlnlcpIB8dLFyVtDoB+rgyXMRABXlnvU3VWQ7yIG8RlHEKH/M2
         61DVr3XotnO1Zh8W3dXljAjMqUc64UgQvKnG1q5m57r1nR5Q3ZoIDZ4nLcAPmMdK42iJ
         KusFpGBTTm5MIF1ztKWdllYGleSRkiCg4zOKERQMZJ3hrHYKYuZ41mHP1ZprNdlFrgOE
         3s7g==
X-Forwarded-Encrypted: i=1; AJvYcCVMl0KkkOo0AaC6xBvIYJcxYzlEvYkJjGNfAqUwuqyrk828r1aKI+cMFoYR8U+WqQXZn2O5j/UNbTkbx0WDPKcllV6LpbJ25xRHRoATfhE=
X-Gm-Message-State: AOJu0YyDLuYvpOJjwqSPQu5mXUiP8A2zemMVfJtb46QL2PETMAmG0RR9
	Vm9ll8OSDCDiPfAuzuvYT5EjDW1nQS+n5J7AUyyCmEfbDC4atWQv0otKn/d3MqI=
X-Google-Smtp-Source: AGHT+IH5jFzXO8+bsqCVFgSb/RdY2e94djCs8rhKL5LhE2LqQwj/c5m685dqh5OnfADlo0VInRFv8Q==
X-Received: by 2002:a17:906:17d5:b0:a46:ba9d:29aa with SMTP id u21-20020a17090617d500b00a46ba9d29aamr2398417eje.66.1710777323136;
        Mon, 18 Mar 2024 08:55:23 -0700 (PDT)
Message-ID: <39e1f192-9790-49da-8f33-1eeb6a245539@suse.com>
Date: Mon, 18 Mar 2024 16:55:22 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 04/13] xen/spinlock: add
 rspin_[un]lock_irq[save|restore]()
Content-Language: en-US
To: Jan Beulich 
Cc: Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 xen-devel@lists.xenproject.org
References: <20240314072029.16937-1-jgross@suse.com>
 <20240314072029.16937-5-jgross@suse.com>
 <1b8417b8-93aa-4976-a27a-701cfdf183b4@suse.com>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
In-Reply-To: <1b8417b8-93aa-4976-a27a-701cfdf183b4@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 18.03.24 15:43, Jan Beulich wrote:
> On 14.03.2024 08:20, Juergen Gross wrote:
>> Instead of special casing rspin_lock_irqsave() and
>> rspin_unlock_irqrestore() for the console lock, add those functions
>> to spinlock handling and use them where needed.
>>
>> Signed-off-by: Juergen Gross 
> 
> Reviewed-by: Jan Beulich 
> with two remarks:
> 
>> --- a/xen/common/spinlock.c
>> +++ b/xen/common/spinlock.c
>> @@ -475,15 +475,31 @@ void _rspin_lock(rspinlock_t *lock)
>>       lock->recurse_cnt++;
>>   }
>>   
>> +unsigned long _rspin_lock_irqsave(rspinlock_t *lock)
>> +{
>> +    unsigned long flags;
>> +
>> +    local_irq_save(flags);
>> +    _rspin_lock(lock);
>> +
>> +    return flags;
>> +}
>> +
>>   void _rspin_unlock(rspinlock_t *lock)
>>   {
>>       if ( likely(--lock->recurse_cnt == 0) )
>>       {
>>           lock->recurse_cpu = SPINLOCK_NO_CPU;
>> -        spin_unlock(lock);
>> +        _spin_unlock(lock);
> 
> This looks like an unrelated change. I think I can guess the purpose, but
> it would be nice if such along-the-way changes could be mentioned in the
> description.

I think it would be better to move that change to patch 3.

> 
>> --- a/xen/include/xen/spinlock.h
>> +++ b/xen/include/xen/spinlock.h
>> @@ -272,7 +272,15 @@ static always_inline void spin_lock_if(bool condition, spinlock_t *l)
>>    */
>>   bool _rspin_trylock(rspinlock_t *lock);
>>   void _rspin_lock(rspinlock_t *lock);
>> +#define rspin_lock_irqsave(l, f)                                \
>> +    ({                                                          \
>> +        BUILD_BUG_ON(sizeof(f) != sizeof(unsigned long));       \
>> +        ((f) = _rspin_lock_irqsave(l));                         \
> 
> Perhaps in the context of another patch in the series I think I had
> pointed out that the outer pair of parentheses is unnecessary in
> constructs like this.

Oh, this one slipped through, sorry for that.

Will fix it in the next iteration.


Juergen


From xen-devel-bounces@lists.xenproject.org Mon Mar 18 15:56:04 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 15:56:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694844.1084004 (Exim 4.92)
	(envelope-from )
	id 1rmFLI-0008Tl-PQ; Mon, 18 Mar 2024 15:56:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694844.1084004; Mon, 18 Mar 2024 15:56:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmFLI-0008Te-Mq; Mon, 18 Mar 2024 15:56:04 +0000
Received: by outflank-mailman (input) for mailman id 694844;
 Mon, 18 Mar 2024 15:56:03 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmFLH-0008TW-5d
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 15:56:03 +0000
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com
 [2a00:1450:4864:20::633])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 05237969-e540-11ee-afdd-a90da7624cb6;
 Mon, 18 Mar 2024 16:56:02 +0100 (CET)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-a46cf8f649dso85387366b.3
 for ; Mon, 18 Mar 2024 08:56:02 -0700 (PDT)
Received: from ?IPV6:2003:e5:873a:400:704b:6dbb:e7c0:786e?
 (p200300e5873a0400704b6dbbe7c0786e.dip0.t-ipconnect.de.
 [2003:e5:873a:400:704b:6dbb:e7c0:786e])
 by smtp.gmail.com with ESMTPSA id
 d20-20020a1709067f1400b00a468bcde79bsm3745619ejr.109.2024.03.18.08.56.01
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 18 Mar 2024 08:56:01 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 05237969-e540-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710777362; x=1711382162; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:references:cc:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=HQJre/nhIH5uFLd1fQUCQ+si34B+icspJjrPPPSh1lc=;
        b=fAE9P/cYhNVeoOlOnvB1UZjlcI3k3izzjlTWsV3lZHAsnSw0Xr9VoCfMZ/6zrIBa9R
         5RS3Ru78LpUt2RUJVPvA5hUd7W3tfi4W+cfD+nxf4pGCFU6UDeRUBmpKQI5/P/QmnVYt
         xLUQiNN24SLzjYzmGGOO+ugTgP//XkBlp8OZ9i6sHJGMYGvLxud89oUddVn8r4mD28wp
         BC2U3eBgreXNsnwKLKYrzhNcOcgGp2J4vi9KAO7Pj5EPXwCYU1XedpJwb/MxHT/BrAGc
         7ALLqXJs4dJyfwKYypZMelUkcs4g5LBpOZvOIPiR4IwoJE2yQW14Wo7agQFj2jcdaSXj
         Z35w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710777362; x=1711382162;
        h=content-transfer-encoding:in-reply-to:from:references:cc:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=HQJre/nhIH5uFLd1fQUCQ+si34B+icspJjrPPPSh1lc=;
        b=syZEViNwDyEKFTfZ2WLoD4B3+AxfWzHLxiVYJ2mrEAlKB0EphlvVk+eO0Q+awEyYmS
         I+8VO1hepxuEvWFr8Sy1hfmDJ8VpKPzCH5tSaG7BD/cSZIgSEx8KjT2c1qKBHWQ/UqMw
         T+DfLVsVOgecWBohcnAV+DeE8jSU/p5hQ1gH093KN7H9ibTh43G6/yfu6ds7mLvgQ+nV
         thY2x8cVOGycT3PPNHYzCBU88wDOLKGUkX7ShU2ev88gT7NqUbm65AUkmk0n9pnTyZFd
         DN1plmU+sO7flcPRHddJkaro5XQjuhaQLy4PN3YMmAyrtbj99NBmOYb7tpyI/QXFLPQT
         SZLA==
X-Forwarded-Encrypted: i=1; AJvYcCWNRznOmYwHfmZbhcPyzgAqK1jezEtGt9X/7LUKlKlBxA1S8CwXdKugncsAB0cploV9Bed4k2MvAiKEs5rMO5tCmqYhZtWv+VjqXJCwhio=
X-Gm-Message-State: AOJu0Yx4EFYoF4fzbQLXqrXdDoF9PF/QI14xuZ+0R26NGQaaVWW5nGZN
	t453PgZ7QH/IE97XisL/fjgHlRa3gPwLBVHbnZTQltW2t0xFzKcU1V1adLOpl3dyIDE3mUyWnLX
	E
X-Google-Smtp-Source: AGHT+IEMMgMWIQ5gsSHnFkOzSu1V0ntClm2HytSdOJ9OGykCmxb0n3NUKwmkQypEsPLmwTcWMFxxiA==
X-Received: by 2002:a17:906:b2d1:b0:a46:d430:2ced with SMTP id cf17-20020a170906b2d100b00a46d4302cedmr389329ejb.29.1710777361863;
        Mon, 18 Mar 2024 08:56:01 -0700 (PDT)
Message-ID: 
Date: Mon, 18 Mar 2024 16:56:01 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 11/13] xen/spinlock: support higher number of cpus
Content-Language: en-US
To: Jan Beulich 
Cc: Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 xen-devel@lists.xenproject.org
References: <20240314072029.16937-1-jgross@suse.com>
 <20240314072029.16937-12-jgross@suse.com>
 <37b4410d-8fc5-40c3-bff8-49eaae2298c4@suse.com>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
In-Reply-To: <37b4410d-8fc5-40c3-bff8-49eaae2298c4@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 18.03.24 16:08, Jan Beulich wrote:
> On 14.03.2024 08:20, Juergen Gross wrote:
>> --- a/xen/include/xen/spinlock.h
>> +++ b/xen/include/xen/spinlock.h
>> @@ -8,16 +8,16 @@
>>   #include 
>>   #include 
>>   
>> -#define SPINLOCK_CPU_BITS  12
>> +#define SPINLOCK_CPU_BITS  16
>>   
>>   #ifdef CONFIG_DEBUG_LOCKS
>>   union lock_debug {
>> -    uint16_t val;
>> -#define LOCK_DEBUG_INITVAL 0xffff
>> +    uint32_t val;
>> +#define LOCK_DEBUG_INITVAL 0xffffffff
> 
> With this #define I can see the desire for using a fixed width type for "val".
> However, ...
> 
>>       struct {
>> -        uint16_t cpu:SPINLOCK_CPU_BITS;
>> -#define LOCK_DEBUG_PAD_BITS (14 - SPINLOCK_CPU_BITS)
>> -        uint16_t :LOCK_DEBUG_PAD_BITS;
>> +        uint32_t cpu:SPINLOCK_CPU_BITS;
>> +#define LOCK_DEBUG_PAD_BITS (30 - SPINLOCK_CPU_BITS)
>> +        uint32_t :LOCK_DEBUG_PAD_BITS;
> 
> .. "unsigned int" ought to be fine for both of these.

Fine with me.


Juergen



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 15:59:44 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 15:59:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694853.1084014 (Exim 4.92)
	(envelope-from )
	id 1rmFOm-00010k-Ca; Mon, 18 Mar 2024 15:59:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694853.1084014; Mon, 18 Mar 2024 15:59:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmFOm-00010d-9V; Mon, 18 Mar 2024 15:59:40 +0000
Received: by outflank-mailman (input) for mailman id 694853;
 Mon, 18 Mar 2024 15:59:39 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmFOl-00010X-1n
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 15:59:39 +0000
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com
 [2a00:1450:4864:20::52e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8530ad81-e540-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 16:59:37 +0100 (CET)
Received: by mail-ed1-x52e.google.com with SMTP id
 4fb4d7f45d1cf-56b84b2c8c8so829662a12.1
 for ; Mon, 18 Mar 2024 08:59:37 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 s26-20020a170906a19a00b00a46b121050dsm2053101ejy.77.2024.03.18.08.59.36
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 18 Mar 2024 08:59:36 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8530ad81-e540-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710777576; x=1711382376; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=A++HtnT2NUb2uEOgnpsY9lobpOMCAqc3GDVnBETfZMc=;
        b=Q3B/y4HGAyQha7qcUzPsjcByhmO5sVIjCsaokgqDbef1zONdeIsYEBaBQ37ZZCggQX
         iK0NWQJ1RINZSLQ05qiDycKVvBS4ORmy+S4kNYwtlrmYvxrXu4trfsklELKsqIUu4BWy
         W1FNrok/vRNnzv5G1ZWR/Ypi9zTMtmEMezYq+DVmp1SPs0NILdvBEv0GEitTv4ywXZtU
         x7qyrJK7fS6KUDclTrxDLjmlEFBoQFjjvyYK3SVhGJZOCf3y1oW/2GtTYhtC/TcbS9TD
         6OIKdOWwc3oy9v5IaeAfTqGBQagx8QyOT4fg20WXKAry72h8jYPHDu0DdFWtWjh3MLaO
         2o3A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710777576; x=1711382376;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=A++HtnT2NUb2uEOgnpsY9lobpOMCAqc3GDVnBETfZMc=;
        b=mAOPMl92ic4P8sXc5L3jAxGyCQN0z8Bh5KVtEfN9iYju/L4lg9TUGscXe1Iuw7zg5J
         pNgZUoYIwwIjLcMrQTJord877UnnQ+m5PRjC2gB06jxCNVAznZ61/jjOGWTW9NvOUSxs
         sJzkzev8Otn0SePp5bkeVCFo2vjsW8xB6Qi02/V2SKPpDHG5CJrOwRdzEbWHL0V6IWiM
         lMtoHL6LIJgnLHSbV0NwAETp+fdSu3CD5/WAk8jJ4vROTxSFAaqNgSYx2Vo2CojUNXO3
         gUUW+dob9S+EllP4FiA3+EzDabR4+E8U5QhhK42zkqneB+8os13zrndRZJVbnGrQ8MbG
         7oQA==
X-Forwarded-Encrypted: i=1; AJvYcCUQi4rZIOng89c/KGA3OxQK+p9GeMON2WwaYJbWCIsx+jSFwXO7CeKtgjKFaJKqyidR8Ks1SgnhFWnuKtr9iuuqrIJxStWZRXnVt8Wb3gI=
X-Gm-Message-State: AOJu0YzabzjCzEAjPJ09OiFGkdrrFJIqF6yorZePgkWQvb65xs4Dl68B
	LlLRZg6zH7V4yqsmB486asjK8a83JZ/C5n0EwPuNvUlFpy4iQCmlQ06Y7qaUUg==
X-Google-Smtp-Source: AGHT+IEOZ7FMs0FizW0n6nMFA7ICUb2dOufDIafp9z/K9qTD8P80D71KXeS41NeISMmFr6wuLCH3vQ==
X-Received: by 2002:a17:906:6a13:b0:a46:5dff:bf26 with SMTP id qw19-20020a1709066a1300b00a465dffbf26mr9226036ejc.8.1710777576702;
        Mon, 18 Mar 2024 08:59:36 -0700 (PDT)
Message-ID: <1ac7b3cd-2f61-4c13-8cac-f74f953ffb08@suse.com>
Date: Mon, 18 Mar 2024 16:59:35 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 04/13] xen/spinlock: add
 rspin_[un]lock_irq[save|restore]()
Content-Language: en-US
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
Cc: Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 xen-devel@lists.xenproject.org
References: <20240314072029.16937-1-jgross@suse.com>
 <20240314072029.16937-5-jgross@suse.com>
 <1b8417b8-93aa-4976-a27a-701cfdf183b4@suse.com>
 <39e1f192-9790-49da-8f33-1eeb6a245539@suse.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <39e1f192-9790-49da-8f33-1eeb6a245539@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 18.03.2024 16:55, Jürgen Groß wrote:
> On 18.03.24 15:43, Jan Beulich wrote:
>> On 14.03.2024 08:20, Juergen Gross wrote:
>>> Instead of special casing rspin_lock_irqsave() and
>>> rspin_unlock_irqrestore() for the console lock, add those functions
>>> to spinlock handling and use them where needed.
>>>
>>> Signed-off-by: Juergen Gross 
>>
>> Reviewed-by: Jan Beulich 
>> with two remarks:
>>
>>> --- a/xen/common/spinlock.c
>>> +++ b/xen/common/spinlock.c
>>> @@ -475,15 +475,31 @@ void _rspin_lock(rspinlock_t *lock)
>>>       lock->recurse_cnt++;
>>>   }
>>>   
>>> +unsigned long _rspin_lock_irqsave(rspinlock_t *lock)
>>> +{
>>> +    unsigned long flags;
>>> +
>>> +    local_irq_save(flags);
>>> +    _rspin_lock(lock);
>>> +
>>> +    return flags;
>>> +}
>>> +
>>>   void _rspin_unlock(rspinlock_t *lock)
>>>   {
>>>       if ( likely(--lock->recurse_cnt == 0) )
>>>       {
>>>           lock->recurse_cpu = SPINLOCK_NO_CPU;
>>> -        spin_unlock(lock);
>>> +        _spin_unlock(lock);
>>
>> This looks like an unrelated change. I think I can guess the purpose, but
>> it would be nice if such along-the-way changes could be mentioned in the
>> description.
> 
> I think it would be better to move that change to patch 3.

Hmm, it would be a secondary change there, too. I was actually meaning to
commit patches 2-5, but if things want moving around I guess I better
wait with doing so?

Jan


From xen-devel-bounces@lists.xenproject.org Mon Mar 18 16:00:07 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 16:00:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694855.1084024 (Exim 4.92)
	(envelope-from )
	id 1rmFPD-0002tC-Ky; Mon, 18 Mar 2024 16:00:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694855.1084024; Mon, 18 Mar 2024 16:00:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmFPD-0002t5-I2; Mon, 18 Mar 2024 16:00:07 +0000
Received: by outflank-mailman (input) for mailman id 694855;
 Mon, 18 Mar 2024 16:00:06 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmFPC-00010X-Jg
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 16:00:06 +0000
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com
 [2a00:1450:4864:20::635])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 95c297b6-e540-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 17:00:04 +0100 (CET)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-a466a27d30aso591541966b.1
 for ; Mon, 18 Mar 2024 09:00:04 -0700 (PDT)
Received: from ?IPV6:2003:e5:873a:400:704b:6dbb:e7c0:786e?
 (p200300e5873a0400704b6dbbe7c0786e.dip0.t-ipconnect.de.
 [2003:e5:873a:400:704b:6dbb:e7c0:786e])
 by smtp.gmail.com with ESMTPSA id
 i26-20020a1709061cda00b00a46baa4723asm1556486ejh.119.2024.03.18.09.00.03
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 18 Mar 2024 09:00:03 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 95c297b6-e540-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710777604; x=1711382404; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:references:cc:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=1HbzZscfp2/Mm7Ud1ZYajdefYIS3C3CLwkbOLfjXB1Y=;
        b=KqtK6CEsy6VG2OC1XrVGJUR4GU0fp9izr7nUHD2NvoBs9CQMGKMvi086CADpXSg1of
         /DaN9VWMq1xY7BY5eCDVRYiPfiHAQZnlj2n46/QoFeSXDd9X5UT9BM5bJXtqYAH13tz3
         8AnH/WZ7FKTtAEKnSEmITGfun5DX2c0doH2g1/tjcDml2shuCR0PEY2XVaSO724RBzt/
         9poHz9xDD9e6YAvIsgxJv+PEoqF7S4YPjsS3Y+RbXYFESXNfTqbmwLpkQejwHsXJakFu
         LCeNJhSuupcqFTIdijnf0psxz+kAiwfWGo6OY9J93DBsTUgdwgL8klCaZwrE1HbeZ1Zf
         E0Ow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710777604; x=1711382404;
        h=content-transfer-encoding:in-reply-to:from:references:cc:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=1HbzZscfp2/Mm7Ud1ZYajdefYIS3C3CLwkbOLfjXB1Y=;
        b=cHT3po0Tyd0e9HAWyYIp7Rh4xagpSW4LvFfg9vX+fiBK2Ed+uB4MSBcHLtKC7H7Q/R
         Q+INKEPTXbRR3Br6Kko8J7VX01wlFibhM5AS3IxAq3aYujjVU5OtlRdk2WuFan28M5OK
         l+BCJdwZ8XZmeNnNBiIWK0YqNbT8/u4563U4qykxmblAOwgwk96/MhT+i0wjosGdPN6p
         29EGYsqkctiT9Ap7Jz54/cCRJtm8d/6IaUlW42iGAcQPVnQ8Td9i528TobectqvFJmpc
         ezuhKqgHystlxVrAEpQuYIvZBXa6uFS1fffDi6LxOKj3S2jRusDqDg9xFQnXvnvTbSRb
         xRxg==
X-Forwarded-Encrypted: i=1; AJvYcCVlPg750WXLMtQSYqsC+TogNjrP4tKzQfUQBt7POSYMCS2t4mb33UQi6Ofus5ZoWBUEglHcEBSRvnDDjHiQY9kNSUzk2kWul89DshU4Hus=
X-Gm-Message-State: AOJu0YzGe0GubUYstW1nkKUP6fTZVk8bI8Fii9i/bkrJLkZD3TaH4Eul
	WtXx8x4IuZXN8ID6KABa6/ZJWMCesD5REBIrZxc0h4kXsEGamBdLy0oe4QNQiLk=
X-Google-Smtp-Source: AGHT+IGyTlOC3pRf5WIC+HFxyf//D44oVOGRSP99lU4wZoYYaOT/Y7j4ofoUwiaIPWdYzk8khWuxrQ==
X-Received: by 2002:a17:906:7f10:b0:a45:f705:777c with SMTP id d16-20020a1709067f1000b00a45f705777cmr7637596ejr.40.1710777603836;
        Mon, 18 Mar 2024 09:00:03 -0700 (PDT)
Message-ID: <4ee88d53-4b2f-4768-951c-7080680df337@suse.com>
Date: Mon, 18 Mar 2024 17:00:03 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 12/13] xen/rwlock: raise the number of possible cpus
Content-Language: en-US
To: Jan Beulich 
Cc: Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 xen-devel@lists.xenproject.org
References: <20240314072029.16937-1-jgross@suse.com>
 <20240314072029.16937-13-jgross@suse.com>
 
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 18.03.24 16:39, Jan Beulich wrote:
> On 14.03.2024 08:20, Juergen Gross wrote:
>> The rwlock handling is limiting the number of cpus to 4095 today. The
>> main reason is the use of the atomic_t data type for the main lock
>> handling, which needs 2 bits for the locking state (writer waiting or
>> write locked), 12 bits for the id of a possible writer, and a 12 bit
>> counter for readers. The limit isn't 4096 due to an off by one sanity
>> check.
>>
>> The atomic_t data type is 32 bits wide, so in theory 15 bits for the
>> writer's cpu id and 15 bits for the reader count seem to be fine, but
>> via read_trylock() more readers than cpus are possible.
> 
> As a result, afaict you choose to use just 14 bits for the CPU, but
> still 15 bits (with the 16th to deal with overflow) for the reader count.
> That could do with making explicit here, as a question is whether we
> deem as sufficient that there is just one extra bit for the reader
> count.

Okay, I'll add a sentence to the commit message.

> 
>> --- a/xen/include/xen/rwlock.h
>> +++ b/xen/include/xen/rwlock.h
>> @@ -23,12 +23,12 @@ typedef struct {
>>   #define rwlock_init(l) (*(l) = (rwlock_t)RW_LOCK_UNLOCKED)
>>   
>>   /* Writer states & reader shift and bias. */
>> -#define    _QW_CPUMASK  0xfffU             /* Writer CPU mask */
>> -#define    _QW_SHIFT    12                 /* Writer flags shift */
>> -#define    _QW_WAITING  (1U << _QW_SHIFT)  /* A writer is waiting */
>> -#define    _QW_LOCKED   (3U << _QW_SHIFT)  /* A writer holds the lock */
>> -#define    _QW_WMASK    (3U << _QW_SHIFT)  /* Writer mask */
>> -#define    _QR_SHIFT    14                 /* Reader count shift */
>> +#define    _QW_SHIFT    14                      /* Writer flags shift */
>> +#define    _QW_CPUMASK  ((1U << _QW_SHIFT) - 1) /* Writer CPU mask */
>> +#define    _QW_WAITING  (1U << _QW_SHIFT)       /* A writer is waiting */
>> +#define    _QW_LOCKED   (3U << _QW_SHIFT)       /* A writer holds the lock */
>> +#define    _QW_WMASK    (3U << _QW_SHIFT)       /* Writer mask */
>> +#define    _QR_SHIFT    (_QW_SHIFT + 2)         /* Reader count shift */
>>   #define    _QR_BIAS     (1U << _QR_SHIFT)
> 
> Btw, seeing all the uppercase U suffixes here, I think you had some
> lowercase ones earlier in the series. While Misra doesn't demand
> uppercase for U, it does for L and iirc we decided to use all
> uppercase suffixes as a result. Would be nice if what goes in could
> have this correct right away.

I'll rescan all the patches and change them accordingly.

> 
>> @@ -36,14 +36,16 @@ void queue_write_lock_slowpath(rwlock_t *lock);
>>   
>>   static inline bool _is_write_locked_by_me(unsigned int cnts)
>>   {
>> -    BUILD_BUG_ON(_QW_CPUMASK < NR_CPUS);
>> +    BUILD_BUG_ON((_QW_CPUMASK + 1) < NR_CPUS);
>> +    BUILD_BUG_ON(NR_CPUS * _QR_BIAS > INT_MAX);
>>       return (cnts & _QW_WMASK) == _QW_LOCKED &&
>>              (cnts & _QW_CPUMASK) == smp_processor_id();
>>   }
>>   
>>   static inline bool _can_read_lock(unsigned int cnts)
>>   {
>> -    return !(cnts & _QW_WMASK) || _is_write_locked_by_me(cnts);
>> +    return cnts <= INT_MAX &&
>> +           (!(cnts & _QW_WMASK) || _is_write_locked_by_me(cnts));
>>   }
> 
> I view this as problematic: Code knowing that a write lock is being held
> may invoke a function using read_trylock() and expect the lock to be
> available there.

So you expect it to be fine that someone is using read_trylock() 32768 times
recursively while holding a lock as a writer? Sure, I can change the condition,
but OTOH ...


Juergen



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 16:05:49 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 16:05:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694862.1084033 (Exim 4.92)
	(envelope-from )
	id 1rmFUe-0004KW-7d; Mon, 18 Mar 2024 16:05:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694862.1084033; Mon, 18 Mar 2024 16:05:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmFUe-0004KP-4l; Mon, 18 Mar 2024 16:05:44 +0000
Received: by outflank-mailman (input) for mailman id 694862;
 Mon, 18 Mar 2024 16:05:43 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmFUd-0004KJ-5V
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 16:05:43 +0000
Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com
 [2a00:1450:4864:20::636])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5ec1419d-e541-11ee-afdd-a90da7624cb6;
 Mon, 18 Mar 2024 17:05:42 +0100 (CET)
Received: by mail-ej1-x636.google.com with SMTP id
 a640c23a62f3a-a46aaf6081fso255143666b.2
 for ; Mon, 18 Mar 2024 09:05:42 -0700 (PDT)
Received: from ?IPV6:2003:e5:873a:400:704b:6dbb:e7c0:786e?
 (p200300e5873a0400704b6dbbe7c0786e.dip0.t-ipconnect.de.
 [2003:e5:873a:400:704b:6dbb:e7c0:786e])
 by smtp.gmail.com with ESMTPSA id
 i22-20020a17090671d600b00a46d58fbc11sm81704ejk.118.2024.03.18.09.05.41
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 18 Mar 2024 09:05:41 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5ec1419d-e541-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710777941; x=1711382741; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:references:cc:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=n2z791031MnjwyORIdmOta/N62xQ8VXP7ioyI/cQbCk=;
        b=FGIr0c/2wyQH2G0vhDj1rAKZdtZv3G8aKhRW4ZzIYkXt4WtP1lyKcquRu8eaPmfc9y
         SYBToLecdVV6MTrX3E1syq4wP0olnyzC6csot73IaIduIGagBNtpSg9Qk0rfTRv5QJkd
         O/YzSPz5CbcvaCRs32RLlnSLyB2mbHiuT48azJ+5uSdxeZbjb3jYYMpr+kJPhIpeBvZc
         iKyY9u1wzjq3HflY/NlEGW2eg0ILRtOTKyD1sds/Hi8pZmv0+IPNXbnomn4lAOuH9Ckh
         xsyPs0pTlm/s/JED3l6ro4wErjSHhKJMVhx1W6+HD6AN+wkaQSigvqjfQ175VgvJoVf9
         mwHA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710777941; x=1711382741;
        h=content-transfer-encoding:in-reply-to:from:references:cc:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=n2z791031MnjwyORIdmOta/N62xQ8VXP7ioyI/cQbCk=;
        b=EApccBI7KKZdE4hXQNuyy/Rpc5p+IH6DPrm4eOJ2dcu9AScyar1ci+fmM9KPx/xQcd
         a6fd1y1vZ//lln6iTXUonjbSygC92lsCd6J1WFhEqSFZEWHvyjhuxnQq4RiNq80GxU4A
         gPmu87X3+XDbZ+QNCJnWZWgzxf8Kdl7YPh5iq380fMCtu5qAEkB4zRY6ddGsrWKo4gbL
         +BiFkDMHsPGMGs5TQzS8v6EVFvJXO9Qx6x/uqm/e4ih/lwCZtaGG6Y1hb5HRe7T6mHXa
         q6yNAo3NVcuW1PG3T9ssrdeAF3+ePDsabbBU9uH9vuCx5hnwvAbzY0mvSR4u++smHgmJ
         Ipuw==
X-Forwarded-Encrypted: i=1; AJvYcCXNvJBi0f/BP4tQEnp8v4M6KpWsj8P24466V1XXUrvtb8bBJFK+qCi+qNYAchRkreldT3Kt4gXrFp7sDiIc+hjxTpX8Gt/8B6eBbDxSgFI=
X-Gm-Message-State: AOJu0Yzgvf5y08CV8QR4eIQg0ui4I/fvISAagEYkf/x9gYOHTLWqWCcj
	MxXpH+tGaMsukuB19bT4++7ERtv+xAQujWAYy4euaBa4OotkNFG5S5x5Sb3d9uY=
X-Google-Smtp-Source: AGHT+IFPUFT8UOZBxZ217QsFSB7tcASN6JcFr+Ty+CUte1Eo59pgmjDm4BNwLqrSvmQ5ET0k24ohsQ==
X-Received: by 2002:a17:907:7e93:b0:a46:a9f7:eebd with SMTP id qb19-20020a1709077e9300b00a46a9f7eebdmr4631967ejc.47.1710777941595;
        Mon, 18 Mar 2024 09:05:41 -0700 (PDT)
Message-ID: <51229f1e-bfbb-41b2-82a9-4b58ce9afaa2@suse.com>
Date: Mon, 18 Mar 2024 17:05:40 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 04/13] xen/spinlock: add
 rspin_[un]lock_irq[save|restore]()
Content-Language: en-US
To: Jan Beulich 
Cc: Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 xen-devel@lists.xenproject.org
References: <20240314072029.16937-1-jgross@suse.com>
 <20240314072029.16937-5-jgross@suse.com>
 <1b8417b8-93aa-4976-a27a-701cfdf183b4@suse.com>
 <39e1f192-9790-49da-8f33-1eeb6a245539@suse.com>
 <1ac7b3cd-2f61-4c13-8cac-f74f953ffb08@suse.com>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
In-Reply-To: <1ac7b3cd-2f61-4c13-8cac-f74f953ffb08@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 18.03.24 16:59, Jan Beulich wrote:
> On 18.03.2024 16:55, Jürgen Groß wrote:
>> On 18.03.24 15:43, Jan Beulich wrote:
>>> On 14.03.2024 08:20, Juergen Gross wrote:
>>>> Instead of special casing rspin_lock_irqsave() and
>>>> rspin_unlock_irqrestore() for the console lock, add those functions
>>>> to spinlock handling and use them where needed.
>>>>
>>>> Signed-off-by: Juergen Gross 
>>>
>>> Reviewed-by: Jan Beulich 
>>> with two remarks:
>>>
>>>> --- a/xen/common/spinlock.c
>>>> +++ b/xen/common/spinlock.c
>>>> @@ -475,15 +475,31 @@ void _rspin_lock(rspinlock_t *lock)
>>>>        lock->recurse_cnt++;
>>>>    }
>>>>    
>>>> +unsigned long _rspin_lock_irqsave(rspinlock_t *lock)
>>>> +{
>>>> +    unsigned long flags;
>>>> +
>>>> +    local_irq_save(flags);
>>>> +    _rspin_lock(lock);
>>>> +
>>>> +    return flags;
>>>> +}
>>>> +
>>>>    void _rspin_unlock(rspinlock_t *lock)
>>>>    {
>>>>        if ( likely(--lock->recurse_cnt == 0) )
>>>>        {
>>>>            lock->recurse_cpu = SPINLOCK_NO_CPU;
>>>> -        spin_unlock(lock);
>>>> +        _spin_unlock(lock);
>>>
>>> This looks like an unrelated change. I think I can guess the purpose, but
>>> it would be nice if such along-the-way changes could be mentioned in the
>>> description.
>>
>> I think it would be better to move that change to patch 3.
> 
> Hmm, it would be a secondary change there, too. I was actually meaning to
> commit patches 2-5, but if things want moving around I guess I better
> wait with doing so?

Hmm, maybe just drop this hunk and let patch 7 handle it?


Juergen


From xen-devel-bounces@lists.xenproject.org Mon Mar 18 16:05:49 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 16:05:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694863.1084045 (Exim 4.92)
	(envelope-from )
	id 1rmFUj-0004ZY-Gt; Mon, 18 Mar 2024 16:05:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694863.1084045; Mon, 18 Mar 2024 16:05:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmFUj-0004ZR-C1; Mon, 18 Mar 2024 16:05:49 +0000
Received: by outflank-mailman (input) for mailman id 694863;
 Mon, 18 Mar 2024 16:05:47 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmFUh-0004Yz-U3
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 16:05:47 +0000
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com
 [2a00:1450:4864:20::62f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 610bd5d8-e541-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 17:05:46 +0100 (CET)
Received: by mail-ej1-x62f.google.com with SMTP id
 a640c23a62f3a-a46cd9e7fcaso100705266b.1
 for ; Mon, 18 Mar 2024 09:05:46 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 dv22-20020a170906b81600b00a4658d3e405sm4957398ejb.196.2024.03.18.09.05.44
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 18 Mar 2024 09:05:45 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 610bd5d8-e541-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710777945; x=1711382745; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=u1kaXoK3SUR4iTYqjbzRn2UcjiCElS90ElTBpcj+RZo=;
        b=MSRmooaf2x/7Nr+T6M0Za9NvsBI1TetfqTxsH8++Uyjwt+/7q0xUE5fi3wZLf0sDkA
         TqcwGpx6esxKZe5WqLxTAd2EB3NDJuKUezfiBrBqyawUC+d6Dn6wBTGNXmcxPSIClIho
         aJN/yHYWfNrL/+OA74RZmhEDUTnUkhzRAGGObjhXP5PMjKCM8LndHDMhqbsfz9GHtZ+o
         c/7AT1wADt1f/qe164LPtECRbCweqXrc71RB2oWXqoP1koQ6SO5rdZttiJ62YPQNsgT6
         kzdSKAVfK0jXI9in7u8vack5hGofNozxRJO2lnkotE2opPPMNnitxlSnymeex50vtz/X
         ML6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710777945; x=1711382745;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=u1kaXoK3SUR4iTYqjbzRn2UcjiCElS90ElTBpcj+RZo=;
        b=dkqxULSINoZBZlXE2ZJyEgOG5hJIiwP0H5mI/oy22c0pwXJLR7413h/6bzImwlnpR3
         AsGS21ouL5WvZUmDhEkkV2I9bSgTajGL0gGipTfD72jj9tCBIjYn6Yzfu5gmNwvKK8M8
         tQZWF9LpYOc/SA09uLgiQiZQiVR+KsA4eSK0IfYnDySVTVTxVbxfDHtBBcdGD9bqqSKM
         nJAP0MW4TXvjMCx/oVab8QO8u45F4Sz4z+pj8uSpjM8App190EvzSxGAJFtx/p85q6Y5
         IcL2E76b++j4Eo7mvy9swL8C8AAxBrq0ZPpBr4HDLblDy93GMymoP49+dPjQoSMFGvdY
         60zg==
X-Forwarded-Encrypted: i=1; AJvYcCWq1ccVRyRHFuI1/BW+EEekN0rEoa44T7SafvvvtTd8RfaaYhHjF9DWCAQyZJ8+SDVOWyeNTuLXCrs71WgxD7GDEGGTKuNNCNfJ27zxNYU=
X-Gm-Message-State: AOJu0Yy5rAJ5E2cqqDqokBxWA9SF2F+wkyBs5ZGqF27K7gImPTY1TBF8
	q1e6JYUUeUCbrkM7sWQMv3UctvbZ1d9C8pX7h86auNT9k7VeN3Sr6lI9O7TepA==
X-Google-Smtp-Source: AGHT+IEUdqe5I5inMx1UaOtuFgeHcDz3cyO9deCle21EK7vp7RHvtkYgzCbhaLGtkMLxSf4VVsDVFw==
X-Received: by 2002:a17:906:bf4a:b0:a46:7794:2c00 with SMTP id ps10-20020a170906bf4a00b00a4677942c00mr9878572ejb.40.1710777945510;
        Mon, 18 Mar 2024 09:05:45 -0700 (PDT)
Message-ID: 
Date: Mon, 18 Mar 2024 17:05:43 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 12/13] xen/rwlock: raise the number of possible cpus
Content-Language: en-US
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
Cc: Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 xen-devel@lists.xenproject.org
References: <20240314072029.16937-1-jgross@suse.com>
 <20240314072029.16937-13-jgross@suse.com>
 
 <4ee88d53-4b2f-4768-951c-7080680df337@suse.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <4ee88d53-4b2f-4768-951c-7080680df337@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 18.03.2024 17:00, Jürgen Groß wrote:
> On 18.03.24 16:39, Jan Beulich wrote:
>> On 14.03.2024 08:20, Juergen Gross wrote:
>>> @@ -36,14 +36,16 @@ void queue_write_lock_slowpath(rwlock_t *lock);
>>>   
>>>   static inline bool _is_write_locked_by_me(unsigned int cnts)
>>>   {
>>> -    BUILD_BUG_ON(_QW_CPUMASK < NR_CPUS);
>>> +    BUILD_BUG_ON((_QW_CPUMASK + 1) < NR_CPUS);
>>> +    BUILD_BUG_ON(NR_CPUS * _QR_BIAS > INT_MAX);
>>>       return (cnts & _QW_WMASK) == _QW_LOCKED &&
>>>              (cnts & _QW_CPUMASK) == smp_processor_id();
>>>   }
>>>   
>>>   static inline bool _can_read_lock(unsigned int cnts)
>>>   {
>>> -    return !(cnts & _QW_WMASK) || _is_write_locked_by_me(cnts);
>>> +    return cnts <= INT_MAX &&
>>> +           (!(cnts & _QW_WMASK) || _is_write_locked_by_me(cnts));
>>>   }
>>
>> I view this as problematic: Code knowing that a write lock is being held
>> may invoke a function using read_trylock() and expect the lock to be
>> available there.
> 
> So you expect it to be fine that someone is using read_trylock() 32768 times
> recursively while holding a lock as a writer? Sure, I can change the condition,
> but OTOH ...

Hmm, yes, the reader count (leaving aside nested read_trylock()) is zero
when the lock is held for writing. So yes, I agree the condition is fine,
but may I ask for a brief comment to this effect, for blind people like
me?

Jan


From xen-devel-bounces@lists.xenproject.org Mon Mar 18 16:06:29 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 16:06:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694866.1084053 (Exim 4.92)
	(envelope-from )
	id 1rmFVN-0005GX-OF; Mon, 18 Mar 2024 16:06:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694866.1084053; Mon, 18 Mar 2024 16:06:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmFVN-0005GQ-LR; Mon, 18 Mar 2024 16:06:29 +0000
Received: by outflank-mailman (input) for mailman id 694866;
 Mon, 18 Mar 2024 16:06:28 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmFVL-0005G4-V2
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 16:06:27 +0000
Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com
 [2a00:1450:4864:20::52f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 78f5d917-e541-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 17:06:26 +0100 (CET)
Received: by mail-ed1-x52f.google.com with SMTP id
 4fb4d7f45d1cf-563cb3ba9daso5151471a12.3
 for ; Mon, 18 Mar 2024 09:06:26 -0700 (PDT)
Received: from ?IPV6:2003:e5:873a:400:704b:6dbb:e7c0:786e?
 (p200300e5873a0400704b6dbbe7c0786e.dip0.t-ipconnect.de.
 [2003:e5:873a:400:704b:6dbb:e7c0:786e])
 by smtp.gmail.com with ESMTPSA id
 i22-20020a17090671d600b00a46d58fbc11sm81704ejk.118.2024.03.18.09.06.25
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 18 Mar 2024 09:06:25 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 78f5d917-e541-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710777985; x=1711382785; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:references:cc:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=vX+fmbm5pzkcwBY5MBPxIvLynu/sq1ati2pR4LHakyE=;
        b=W4nLdxbUyOzq1DEVYAdsH3Dn5dnaqQbZXmKlFKaBiPffQzM7/Q0ygZRITaKuNDsNbz
         2rjq+vkyT+08Vo+MQzo2bnX219tTCh/d6vf+IlR+QuxsAeXRsOCE9XbYdWQMC4Owyt5Z
         h0/WEGTLORxlNm66Vy51M62iZG9hXFAOjEBxSNPWr4+dKtlmBwIKQUxxJynpKPTSX9aF
         RMjrKouw74VcRcOJhHlYdk4J+QGafvsviQHAA9ikFgA+KMYQ+g2bgjT3xZ+vIbps6yl1
         653Bc3Rv7UAyUQgYv+je+CNNFx8i/vovOw2mjNiN7pG+czVG2hJv03maIqN/YV+kOzeY
         YkDg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710777985; x=1711382785;
        h=content-transfer-encoding:in-reply-to:from:references:cc:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=vX+fmbm5pzkcwBY5MBPxIvLynu/sq1ati2pR4LHakyE=;
        b=xRYzVzDFCkZIESWTadwC5ZNH2d17I5hbAXSQ68F/S3Ix0kxNsTtcKlF32xaP5MLPXG
         XUzhRCp3jmOmasslzPWodpAtYMJZc0mKGPD8JW7ziU/CWeFjBHGZyCpYIS4inFo55BYn
         4L+wK5uUNumRzhBmgy68r66/bFBi7loLlY+kGcj6uRB9sXANEaI+rkwk/YiVVpsLIusp
         UNc6DAR/sTTFij8/hXQRCsfMSe1HmxS6byhUgvZu9/0R+H6ML1Rv+bwQqfrnP+MsGa3d
         +nb4cXl5uHeggkAjIiVExSTQpZGNCdTETXV5mVj90DJHpMXlZGb/Lw1DpEimUWHUGiZl
         On8w==
X-Forwarded-Encrypted: i=1; AJvYcCXOevheuHAHHp7D7ayRoYDXvUenelvDV77ujqfyIWgdREoOmsSpHlwmno9xG8S3p4h2if2ZXztoGoDU+SfcsDEKIrWni3wPp7PIjvgcQj4=
X-Gm-Message-State: AOJu0Yzszu8xiZgY6ZLgzzVgloHg4Wl+jQ6fRqyXWdFIYQwnWx4z5VZC
	mN/P+viXI/NNgAKNXg7PiQ9oaat6FFmgDOGlRcNMOX+1RrNzpXHNKnex6R/q7CY=
X-Google-Smtp-Source: AGHT+IHnjDxsD0/Dq7Q+4UmbFpzAEeH7UbDldRmC5GnjI7sGR308bRx6HKAiFsh0iOleu8cLn86JPg==
X-Received: by 2002:a17:906:3199:b0:a43:fd9e:2d44 with SMTP id 25-20020a170906319900b00a43fd9e2d44mr8268491ejy.42.1710777985763;
        Mon, 18 Mar 2024 09:06:25 -0700 (PDT)
Message-ID: 
Date: Mon, 18 Mar 2024 17:06:25 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 12/13] xen/rwlock: raise the number of possible cpus
Content-Language: en-US
To: Jan Beulich 
Cc: Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 xen-devel@lists.xenproject.org
References: <20240314072029.16937-1-jgross@suse.com>
 <20240314072029.16937-13-jgross@suse.com>
 
 <4ee88d53-4b2f-4768-951c-7080680df337@suse.com>
 
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 18.03.24 17:05, Jan Beulich wrote:
> On 18.03.2024 17:00, Jürgen Groß wrote:
>> On 18.03.24 16:39, Jan Beulich wrote:
>>> On 14.03.2024 08:20, Juergen Gross wrote:
>>>> @@ -36,14 +36,16 @@ void queue_write_lock_slowpath(rwlock_t *lock);
>>>>    
>>>>    static inline bool _is_write_locked_by_me(unsigned int cnts)
>>>>    {
>>>> -    BUILD_BUG_ON(_QW_CPUMASK < NR_CPUS);
>>>> +    BUILD_BUG_ON((_QW_CPUMASK + 1) < NR_CPUS);
>>>> +    BUILD_BUG_ON(NR_CPUS * _QR_BIAS > INT_MAX);
>>>>        return (cnts & _QW_WMASK) == _QW_LOCKED &&
>>>>               (cnts & _QW_CPUMASK) == smp_processor_id();
>>>>    }
>>>>    
>>>>    static inline bool _can_read_lock(unsigned int cnts)
>>>>    {
>>>> -    return !(cnts & _QW_WMASK) || _is_write_locked_by_me(cnts);
>>>> +    return cnts <= INT_MAX &&
>>>> +           (!(cnts & _QW_WMASK) || _is_write_locked_by_me(cnts));
>>>>    }
>>>
>>> I view this as problematic: Code knowing that a write lock is being held
>>> may invoke a function using read_trylock() and expect the lock to be
>>> available there.
>>
>> So you expect it to be fine that someone is using read_trylock() 32768 times
>> recursively while holding a lock as a writer? Sure, I can change the condition,
>> but OTOH ...
> 
> Hmm, yes, the reader count (leaving aside nested read_trylock()) is zero
> when the lock is held for writing. So yes, I agree the condition is fine,
> but may I ask for a brief comment to this effect, for blind people like
> me?

Yeah, fine with me. :-)


Juergen



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 16:08:25 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 16:08:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694869.1084064 (Exim 4.92)
	(envelope-from )
	id 1rmFXE-0005yu-6R; Mon, 18 Mar 2024 16:08:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694869.1084064; Mon, 18 Mar 2024 16:08:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmFXE-0005yn-3m; Mon, 18 Mar 2024 16:08:24 +0000
Received: by outflank-mailman (input) for mailman id 694869;
 Mon, 18 Mar 2024 16:08:22 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmFXC-0005yh-TR
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 16:08:22 +0000
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com
 [2a00:1450:4864:20::633])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id bd68b2aa-e541-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 17:08:20 +0100 (CET)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-a468226e135so374532366b.0
 for ; Mon, 18 Mar 2024 09:08:20 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 wn2-20020a170907068200b00a46c508d661sm937297ejb.176.2024.03.18.09.08.20
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 18 Mar 2024 09:08:20 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: bd68b2aa-e541-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710778100; x=1711382900; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=4jNfAM/pMlccXbG04LSjtAJR3CBSJopuWGWyzHGuPzA=;
        b=LfwdxFHoBgAdpZUCDuQjzKD/4DSxJEuN4k3P5NUacGZypARQxwzuhM/kmlfySUhifn
         LyUV+8ZxFcXxdCHVTNkn+fv/0fTQw+8cyJbM6VaIQodMpxMH9IvW/jjJOPmUBoaAgQat
         58Q3JyI89l9U24TrrkdtJNRGdIlrY0CAQOEdW+O1ZKK0vtVpVlQH7lFBNsxBBiKQ6OQY
         CUq4WKViNda5Q3EnG6IF4JG6QcBkeHe2UG8sSUzJgL6fSagLcQr0abViGB6SqG+iabI7
         uxu1fuHbZ/SHYJwK9RsG0gfIuWymoWi1drJKhAqCTmjQifOFZQwxRlZxPIC3wg3K5NyL
         ygmw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710778100; x=1711382900;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=4jNfAM/pMlccXbG04LSjtAJR3CBSJopuWGWyzHGuPzA=;
        b=uFq80w2r7wTopu3+c/eFuGMcOBUI9IZEaGYPbYWPj6LVlpj0cpdjgMRMocupEcoMdk
         OFXxAjAlkd4bD3gsjESxAWbNF+x/8iTCPSSzahDfnXvA/T6U7HgJwsoe7Z2Ee5B6c5dM
         Z/epfZCTTAL4Enpjwd39xFOinUre71x+SQXNVnkv06a31AFlBuUFJhUSObLcdHz0oZ7L
         4+5UmUgwUAkH+pNjaOLH6RkmDA95voYzn/b064CXx8OEj7Q3f0L6gJOxIngQvJtk8UA6
         OhyVhC7j8f7u80IMZYRFTDsyFuTpqpEO2HiyoWRktbZfZtVdA4op4+W0AKQdMJSY3F+M
         76rg==
X-Forwarded-Encrypted: i=1; AJvYcCW30xvuBTLftqDQ6GY9CNmpF4cePsp4JiASMdf+I5Fh3TKqPSW4A7juAhCk6CjnU3PzCG+5C3m63BTaNz1Y5SvVQFSBMvi+D3lsUX6uum4=
X-Gm-Message-State: AOJu0YzhY/ZIcd8NdQjOFxcOyUaNahVgXWcGwGVRbs/qJLGy1Awss7pu
	Ko6bvL4o9+v84KzmudnHEVVZEdAfJjVhEv8Y1lBGGo485t9kZej1Wub4i1BZPQ==
X-Google-Smtp-Source: AGHT+IEtg3TC4BLHWdU+PTczvSc5zWsT9V4XPfnV/xuVUYaUi7G7mW5HFD9lv3bEdRinOATs8y4HeQ==
X-Received: by 2002:a17:906:d8c:b0:a46:181f:c1c3 with SMTP id m12-20020a1709060d8c00b00a46181fc1c3mr7816235eji.70.1710778100487;
        Mon, 18 Mar 2024 09:08:20 -0700 (PDT)
Message-ID: <76443915-db52-4728-8d7e-429f0f0a53f3@suse.com>
Date: Mon, 18 Mar 2024 17:08:19 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 04/13] xen/spinlock: add
 rspin_[un]lock_irq[save|restore]()
Content-Language: en-US
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
Cc: Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 xen-devel@lists.xenproject.org
References: <20240314072029.16937-1-jgross@suse.com>
 <20240314072029.16937-5-jgross@suse.com>
 <1b8417b8-93aa-4976-a27a-701cfdf183b4@suse.com>
 <39e1f192-9790-49da-8f33-1eeb6a245539@suse.com>
 <1ac7b3cd-2f61-4c13-8cac-f74f953ffb08@suse.com>
 <51229f1e-bfbb-41b2-82a9-4b58ce9afaa2@suse.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <51229f1e-bfbb-41b2-82a9-4b58ce9afaa2@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 18.03.2024 17:05, Jürgen Groß wrote:
> On 18.03.24 16:59, Jan Beulich wrote:
>> On 18.03.2024 16:55, Jürgen Groß wrote:
>>> On 18.03.24 15:43, Jan Beulich wrote:
>>>> On 14.03.2024 08:20, Juergen Gross wrote:
>>>>> Instead of special casing rspin_lock_irqsave() and
>>>>> rspin_unlock_irqrestore() for the console lock, add those functions
>>>>> to spinlock handling and use them where needed.
>>>>>
>>>>> Signed-off-by: Juergen Gross 
>>>>
>>>> Reviewed-by: Jan Beulich 
>>>> with two remarks:
>>>>
>>>>> --- a/xen/common/spinlock.c
>>>>> +++ b/xen/common/spinlock.c
>>>>> @@ -475,15 +475,31 @@ void _rspin_lock(rspinlock_t *lock)
>>>>>        lock->recurse_cnt++;
>>>>>    }
>>>>>    
>>>>> +unsigned long _rspin_lock_irqsave(rspinlock_t *lock)
>>>>> +{
>>>>> +    unsigned long flags;
>>>>> +
>>>>> +    local_irq_save(flags);
>>>>> +    _rspin_lock(lock);
>>>>> +
>>>>> +    return flags;
>>>>> +}
>>>>> +
>>>>>    void _rspin_unlock(rspinlock_t *lock)
>>>>>    {
>>>>>        if ( likely(--lock->recurse_cnt == 0) )
>>>>>        {
>>>>>            lock->recurse_cpu = SPINLOCK_NO_CPU;
>>>>> -        spin_unlock(lock);
>>>>> +        _spin_unlock(lock);
>>>>
>>>> This looks like an unrelated change. I think I can guess the purpose, but
>>>> it would be nice if such along-the-way changes could be mentioned in the
>>>> description.
>>>
>>> I think it would be better to move that change to patch 3.
>>
>> Hmm, it would be a secondary change there, too. I was actually meaning to
>> commit patches 2-5, but if things want moving around I guess I better
>> wait with doing so?
> 
> Hmm, maybe just drop this hunk and let patch 7 handle it?

Ah yes, that seem more logical to me. I take it you don't mean "hunk"
though, but really just this one line change.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Mar 18 16:09:28 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 16:09:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694872.1084073 (Exim 4.92)
	(envelope-from )
	id 1rmFYF-0006ZT-EW; Mon, 18 Mar 2024 16:09:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694872.1084073; Mon, 18 Mar 2024 16:09:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmFYF-0006ZM-Bi; Mon, 18 Mar 2024 16:09:27 +0000
Received: by outflank-mailman (input) for mailman id 694872;
 Mon, 18 Mar 2024 16:09:26 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmFYE-0006ZE-14
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 16:09:26 +0000
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com
 [2a00:1450:4864:20::630])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e3168999-e541-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 17:09:24 +0100 (CET)
Received: by mail-ej1-x630.google.com with SMTP id
 a640c23a62f3a-a450bedffdfso556706466b.3
 for ; Mon, 18 Mar 2024 09:09:24 -0700 (PDT)
Received: from ?IPV6:2003:e5:873a:400:704b:6dbb:e7c0:786e?
 (p200300e5873a0400704b6dbbe7c0786e.dip0.t-ipconnect.de.
 [2003:e5:873a:400:704b:6dbb:e7c0:786e])
 by smtp.gmail.com with ESMTPSA id
 h26-20020a17090619da00b00a4668200ba1sm4936649ejd.207.2024.03.18.09.09.22
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 18 Mar 2024 09:09:23 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e3168999-e541-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710778164; x=1711382964; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:references:cc:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=yvwn+Gfj3kr/kfwlJ1imZ5Wh57RO6P4Zq5naMkcxsZE=;
        b=EX0Cfnjcxb2+ou9pG7QYtvZJOFwMRonSzrNGA4qwR/FfAUnT5NjY4GfULYyj8+i1Sw
         RGmwxHtEo86boqcVVDalIGzWIPOY6+RkmHLdtgnDDPr6JEG+Uhl93OFts72Pmw76jxf0
         AGiZu2C5iGaTkv3+eok10MLhCoLmnyGdCkfWBwB1xhNQ/iIcYhBRP4DFHsbn55JfKigF
         0iMfHR3Tn2nQzEM0xdaNQyk1SC3/bI4tidJINKjR7RalZFM9lDksXpH8eSntD6PPhMAO
         L8GjO3MnVfC/9h9JMRHdtwyvXEcyJRzyJi5JDx6q9GBFMpGlts96O5ExBf6X4LbB5+oH
         E8TA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710778164; x=1711382964;
        h=content-transfer-encoding:in-reply-to:from:references:cc:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=yvwn+Gfj3kr/kfwlJ1imZ5Wh57RO6P4Zq5naMkcxsZE=;
        b=BGSnQuav2s31jSCEHVieV+mn3xt1wxxNRNhV7rXrY7Pbbt55IQV2kkHvK1wxYESCqp
         Bw6WfsSRUXpR59uBobK/OsssvV4M7KpH/ov6+Y6WxaNIb/FkrED9IUFyqpizCO8gl8vW
         cYLy8lZPBjlfr9j5DfaZezdgzh6Y4PJrP2p/+7vZB2Y3ZPP7Gm7yJTUss/EN8jzhahEG
         A5EenTsd5FNUayDERK9tZ27i6Eov9a4QPbRq6gxAM7gDB1NVlKM98lQRcX4wkKh+kULP
         tkJjhzAUUj95DErm/jErNjeTT/6KG815CdgUrEaGYwKnDVtP8VExPDqV/KmSP+WmQaCk
         0wOg==
X-Forwarded-Encrypted: i=1; AJvYcCXFdXM3GlBMs97yQR760DZeSdVwPmztzKBZ0DJrb6qLBk2dqHVK4Toq+vHDWrYwA6DOX8wxvHg6MiokZ2GEh09gYNbT2JrF8oTAfiykDwk=
X-Gm-Message-State: AOJu0YxBnAmmhCy/gKKEuFa4EJIbWxkTVGnF+sjNfiVJuUXrV5H22fS+
	Vs+80zt0w8Zg3+jRrcIDWhJkMotsnnpL01lGlvwO7zDMby5wkXV+STfvX53fYqM=
X-Google-Smtp-Source: AGHT+IG1kQI8hGUPiwoT6nUyH63BgDBdOXk/yhzIgxPtEbXUbWgQ3CrBQjCMyS2bN2X4R+GucDiXpg==
X-Received: by 2002:a17:906:3750:b0:a46:ac55:8e77 with SMTP id e16-20020a170906375000b00a46ac558e77mr3546607ejc.13.1710778163608;
        Mon, 18 Mar 2024 09:09:23 -0700 (PDT)
Message-ID: <41742751-6e14-4fdb-905a-aac52d750c1b@suse.com>
Date: Mon, 18 Mar 2024 17:09:22 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 04/13] xen/spinlock: add
 rspin_[un]lock_irq[save|restore]()
Content-Language: en-US
To: Jan Beulich 
Cc: Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 xen-devel@lists.xenproject.org
References: <20240314072029.16937-1-jgross@suse.com>
 <20240314072029.16937-5-jgross@suse.com>
 <1b8417b8-93aa-4976-a27a-701cfdf183b4@suse.com>
 <39e1f192-9790-49da-8f33-1eeb6a245539@suse.com>
 <1ac7b3cd-2f61-4c13-8cac-f74f953ffb08@suse.com>
 <51229f1e-bfbb-41b2-82a9-4b58ce9afaa2@suse.com>
 <76443915-db52-4728-8d7e-429f0f0a53f3@suse.com>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
In-Reply-To: <76443915-db52-4728-8d7e-429f0f0a53f3@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 18.03.24 17:08, Jan Beulich wrote:
> On 18.03.2024 17:05, Jürgen Groß wrote:
>> On 18.03.24 16:59, Jan Beulich wrote:
>>> On 18.03.2024 16:55, Jürgen Groß wrote:
>>>> On 18.03.24 15:43, Jan Beulich wrote:
>>>>> On 14.03.2024 08:20, Juergen Gross wrote:
>>>>>> Instead of special casing rspin_lock_irqsave() and
>>>>>> rspin_unlock_irqrestore() for the console lock, add those functions
>>>>>> to spinlock handling and use them where needed.
>>>>>>
>>>>>> Signed-off-by: Juergen Gross 
>>>>>
>>>>> Reviewed-by: Jan Beulich 
>>>>> with two remarks:
>>>>>
>>>>>> --- a/xen/common/spinlock.c
>>>>>> +++ b/xen/common/spinlock.c
>>>>>> @@ -475,15 +475,31 @@ void _rspin_lock(rspinlock_t *lock)
>>>>>>         lock->recurse_cnt++;
>>>>>>     }
>>>>>>     
>>>>>> +unsigned long _rspin_lock_irqsave(rspinlock_t *lock)
>>>>>> +{
>>>>>> +    unsigned long flags;
>>>>>> +
>>>>>> +    local_irq_save(flags);
>>>>>> +    _rspin_lock(lock);
>>>>>> +
>>>>>> +    return flags;
>>>>>> +}
>>>>>> +
>>>>>>     void _rspin_unlock(rspinlock_t *lock)
>>>>>>     {
>>>>>>         if ( likely(--lock->recurse_cnt == 0) )
>>>>>>         {
>>>>>>             lock->recurse_cpu = SPINLOCK_NO_CPU;
>>>>>> -        spin_unlock(lock);
>>>>>> +        _spin_unlock(lock);
>>>>>
>>>>> This looks like an unrelated change. I think I can guess the purpose, but
>>>>> it would be nice if such along-the-way changes could be mentioned in the
>>>>> description.
>>>>
>>>> I think it would be better to move that change to patch 3.
>>>
>>> Hmm, it would be a secondary change there, too. I was actually meaning to
>>> commit patches 2-5, but if things want moving around I guess I better
>>> wait with doing so?
>>
>> Hmm, maybe just drop this hunk and let patch 7 handle it?
> 
> Ah yes, that seem more logical to me. I take it you don't mean "hunk"
> though, but really just this one line change.

Oh yes, of course.


Juergen



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 16:21:03 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 16:21:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694880.1084084 (Exim 4.92)
	(envelope-from )
	id 1rmFjL-0002PZ-D0; Mon, 18 Mar 2024 16:20:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694880.1084084; Mon, 18 Mar 2024 16:20:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmFjL-0002PS-AJ; Mon, 18 Mar 2024 16:20:55 +0000
Received: by outflank-mailman (input) for mailman id 694880;
 Mon, 18 Mar 2024 16:20:54 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmFjK-0002PI-9x; Mon, 18 Mar 2024 16:20:54 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmFjK-0005Jd-3z; Mon, 18 Mar 2024 16:20:54 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmFjJ-0005Py-Pj; Mon, 18 Mar 2024 16:20:53 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rmFjJ-0004wb-PG; Mon, 18 Mar 2024 16:20:53 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=J24nDWbpyGkzzbQURknPrGOdkzkl69e6x+GFRm8FqTE=; b=P4sbNpV/ftoTTsNhpogerSM8Kc
	SRRTszwlVByMc9R5qnW08aC9YZB/aV6GeHubfYP0c134ynVAuuH+SW0o4VYZM3ptFPig/w6N2lH0v
	c8OPgH0om1XiSLB49Bty7RXSm4PPTefqexEuzjmXsA2r5pKY6yFB8SOQse3lIANxyVpY=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 185081: tolerable all pass - PUSHED
X-Osstest-Failures:
    xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    xen=62018f08708a5ff6ef8fc8ff2aaaac46e5a60430
X-Osstest-Versions-That:
    xen=d638e304f13a5ef7d125de5ace5f7828a7b25bac
From: osstest service owner 
Date: Mon, 18 Mar 2024 16:20:53 +0000

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          16 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  62018f08708a5ff6ef8fc8ff2aaaac46e5a60430
baseline version:
 xen                  d638e304f13a5ef7d125de5ace5f7828a7b25bac

Last test of basis   185041  2024-03-14 19:01:16 Z    3 days
Testing same since   185081  2024-03-18 13:00:27 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper 
  Federico Serafini 
  George Dunlap 
  Jan Beulich 
  Kevin Tian 
  Nicola Vetrini 
  Stefano Stabellini 
  Vaishali Thakkar 
  Wei Liu 

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-amd64                    pass    
 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
   d638e304f1..62018f0870  62018f08708a5ff6ef8fc8ff2aaaac46e5a60430 -> smoke


From xen-devel-bounces@lists.xenproject.org Mon Mar 18 16:32:29 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 16:32:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694885.1084094 (Exim 4.92)
	(envelope-from )
	id 1rmFuM-0004gI-Ff; Mon, 18 Mar 2024 16:32:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694885.1084094; Mon, 18 Mar 2024 16:32:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmFuM-0004gB-BZ; Mon, 18 Mar 2024 16:32:18 +0000
Received: by outflank-mailman (input) for mailman id 694885;
 Mon, 18 Mar 2024 16:32:16 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmFuK-0004g1-Pi; Mon, 18 Mar 2024 16:32:16 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmFuK-0005Vu-JX; Mon, 18 Mar 2024 16:32:16 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmFuK-0006BY-9I; Mon, 18 Mar 2024 16:32:16 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rmFuK-0005OM-8q; Mon, 18 Mar 2024 16:32:16 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=iC8XMjISjxe4fg0BKyiOE+mXDUFzVfpZv9Zx19iZxgE=; b=2BO5KNN39xJlewabo8FtvUsYkm
	XHHch5mDnVSqd5nOrXYCAlqv8DBS7WVt0i7e6dOG3Iaxxg3mjC/KDAgMYlRNMX5nQCcWnDx1ewygh
	DjRrisHto30001ItH7IoWDqyvenW+YZSzqlxpPD5kfHRKrZ1xXz9IofDeApOZXIzoja8=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 185072: tolerable FAIL
X-Osstest-Failures:
    xen-unstable:test-armhf-armhf-libvirt-raw:guest-start/debian.repeat:fail:heisenbug
    xen-unstable:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:heisenbug
    xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:windows-install:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
    xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-i386-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
X-Osstest-Versions-This:
    xen=d638e304f13a5ef7d125de5ace5f7828a7b25bac
X-Osstest-Versions-That:
    xen=d638e304f13a5ef7d125de5ace5f7828a7b25bac
From: osstest service owner 
Date: Mon, 18 Mar 2024 16:32:16 +0000

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt-raw 17 guest-start/debian.repeat fail in 185061 pass in 185072
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 12 debian-hvm-install fail pass in 185061

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

version targeted for testing:
 xen                  d638e304f13a5ef7d125de5ace5f7828a7b25bac
baseline version:
 xen                  d638e304f13a5ef7d125de5ace5f7828a7b25bac

Last test of basis   185072  2024-03-18 01:54:35 Z    0 days
Testing same since                          (not found)         0 attempts

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 fail    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-i386-examine-bios                                 pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-armhf-armhf-libvirt-qcow2                               pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-libvirt-raw                                  pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-i386-examine-uefi                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-arm64-arm64-xl-vhd                                      pass    
 test-armhf-armhf-xl-vhd                                      pass    
 test-amd64-i386-xl-vhd                                       pass    


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

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

Explanation of these 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


Published tested tree is already up to date.



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 16:36:01 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 16:36:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694891.1084109 (Exim 4.92)
	(envelope-from )
	id 1rmFxw-0005LR-A4; Mon, 18 Mar 2024 16:36:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694891.1084109; Mon, 18 Mar 2024 16:36:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmFxw-0005L7-5P; Mon, 18 Mar 2024 16:36:00 +0000
Received: by outflank-mailman (input) for mailman id 694891;
 Mon, 18 Mar 2024 16:35:59 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmFxu-0005JO-W2
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 16:35:58 +0000
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com
 [2a00:1450:4864:20::632])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 98c415ae-e545-11ee-afdd-a90da7624cb6;
 Mon, 18 Mar 2024 17:35:57 +0100 (CET)
Received: by mail-ej1-x632.google.com with SMTP id
 a640c23a62f3a-a468004667aso469316066b.2
 for ; Mon, 18 Mar 2024 09:35:57 -0700 (PDT)
Received: from andrewcoop.citrite.net (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 j22-20020a170906051600b00a441a7a75b5sm4988894eja.209.2024.03.18.09.35.55
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 18 Mar 2024 09:35:56 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 98c415ae-e545-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710779756; x=1711384556; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Cpzmmaoi0pJueucz7Za6oBj+S2IXaqOnagU2yAyCJ44=;
        b=JP9orS50tij7AR5qSry6psj3uSxN+dqggrNruuOGAo5lKFRepM6iDtccLLDS4d9j00
         VnwGA6p4Td7d7Wv54zs+62zDQWslgbV73ZJ9fLnovz8D5dq7o+cvrrQAC28b+kWRgbOJ
         bXoHqmAIInr8qAHHC18zjjlx7sw8l978xW9Q0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710779756; x=1711384556;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=Cpzmmaoi0pJueucz7Za6oBj+S2IXaqOnagU2yAyCJ44=;
        b=if/w0DYXDIzTg/uEBxgo1+1IBfN40KJ8/Z/LPFHMMMkynANIpJiO7XAVlBn9i4zQRo
         PMtKLrddf0vcjaE4JXNPczYDpdo/Y2ZoADBv+hL5hCEtduryqgpICM/U+0YVWOa0xJKN
         wp8uakLmSi2metjuiOQ2rNrdSuswiPQcufLVC+4Dii7VwD4/lmvVEx975QdEbXL+nDi2
         LmSCb70opR1dLL23R8E+2/uxIMaVFjX0+P2IFA5oqZyoMs/lEBJqlkPYCFA1dfyA5AhU
         0FlXY5h/LLRHutSHGzeab8/WO4a8k0uV7lyuNgQ3FDPXJrG3lP/zTdBoWtS3BdqLW+gs
         YIPw==
X-Gm-Message-State: AOJu0YytK9Pjhfss0KWzSNRlBdbA9nLO7tCn8HH/V89oz8zDfmv+m9e1
	slZzXZIPM1zZBsMB37rC/PAOGoNl2jfr+IoSvp4fU8MOqt0IUU6+ZenX2EiRHR6tv7X2OyblJW9
	k
X-Google-Smtp-Source: AGHT+IFlFP6MCdOoAYd9kZM9daEwNdNvAgjw0dy0gDaSkJUU2uztyqS390yRXY9RR7dsxHNJEWQejw==
X-Received: by 2002:a17:906:81d0:b0:a46:d304:fce2 with SMTP id e16-20020a17090681d000b00a46d304fce2mr617114ejx.35.1710779756410;
        Mon, 18 Mar 2024 09:35:56 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Stefano Stabellini ,
	Julien Grall ,
	Nicola Vetrini ,
	"consulting @ bugseng . com" 
Subject: [PATCH 1/7] xen/trace: Introduce new API
Date: Mon, 18 Mar 2024 16:35:46 +0000
Message-Id: <20240318163552.3808695-2-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20240318163552.3808695-1-andrew.cooper3@citrix.com>
References: <20240318163552.3808695-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

trace() and trace_time(), in function form for struct arguments, and macro
form for simple uint32_t list arguments.

This will be used to clean up the mess of macros which exists throughout the
codebase, as well as eventually dropping __trace_var().

There is intentionally no macro to split a 64-bit parameter in the new API,
for MISRA reasons.

Signed-off-by: Andrew Cooper 
---
CC: George Dunlap 
CC: Jan Beulich 
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Nicola Vetrini 
CC: consulting@bugseng.com 

v3:
 * Extend with trace() and trace_time()
 * Delete TRACE_PARAM64() for MISRA reasons.
---
 xen/common/trace.c      |  5 +++++
 xen/include/xen/trace.h | 30 ++++++++++++++++++++++++++++++
 2 files changed, 35 insertions(+)

diff --git a/xen/common/trace.c b/xen/common/trace.c
index 4e7b080e6154..c94ce1f7dc90 100644
--- a/xen/common/trace.c
+++ b/xen/common/trace.c
@@ -808,6 +808,11 @@ void __trace_var(u32 event, bool cycles, unsigned int extra,
         tasklet_schedule(&trace_notify_dom0_tasklet);
 }
 
+void trace(uint32_t event, unsigned int extra, const void *extra_data)
+{
+    __trace_var(event, event & TRC_HD_CYCLE_FLAG, extra, extra_data);
+}
+
 void __trace_hypercall(uint32_t event, unsigned long op,
                        const xen_ulong_t *args)
 {
diff --git a/xen/include/xen/trace.h b/xen/include/xen/trace.h
index 055883287e8c..f184844e1b55 100644
--- a/xen/include/xen/trace.h
+++ b/xen/include/xen/trace.h
@@ -37,6 +37,9 @@ int tb_control(struct xen_sysctl_tbuf_op *tbc);
 
 int trace_will_trace_event(u32 event);
 
+/* Create a trace record, with pre-constructed additional parameters. */
+void trace(uint32_t event, unsigned int extra, const void *extra_data);
+
 void __trace_var(uint32_t event, bool cycles, unsigned int extra, const void *);
 
 static inline void trace_var(uint32_t event, bool cycles, unsigned int extra,
@@ -66,6 +69,9 @@ static inline int trace_will_trace_event(uint32_t event)
     return 0;
 }
 
+static inline void trace(
+    uint32_t event, unsigned int extra, const void *extra_data) {}
+
 static inline void trace_var(uint32_t event, bool cycles, unsigned int extra,
                              const void *extra_data) {}
 static inline void __trace_var(uint32_t event, bool cycles, unsigned int extra,
@@ -74,6 +80,30 @@ static inline void __trace_hypercall(uint32_t event, unsigned long op,
                                      const xen_ulong_t *args) {}
 #endif /* CONFIG_TRACEBUFFER */
 
+/* Create a trace record with time included. */
+static inline void trace_time(
+    uint32_t event, unsigned int extra, const void *extra_data)
+{
+    trace(event | TRC_HD_CYCLE_FLAG, extra, extra_data);
+}
+
+/*
+ * Create a trace record, packaging up to 7 additional parameters into a
+ * uint32_t array.
+ */
+#define TRACE(_e, ...)                                          \
+    do {                                                        \
+        if ( unlikely(tb_init_done) )                           \
+        {                                                       \
+            uint32_t _d[] = { __VA_ARGS__ };                    \
+            BUILD_BUG_ON(ARRAY_SIZE(_d) > TRACE_EXTRA_MAX);     \
+            trace(_e, sizeof(_d), sizeof(_d) ? _d : NULL);      \
+        }                                                       \
+    } while ( 0 )
+
+/* Create a trace record with time included. */
+#define TRACE_TIME(_e, ...) TRACE((_e) | TRC_HD_CYCLE_FLAG, ##__VA_ARGS__)
+
 /* Convenience macros for calling the trace function. */
 #define TRACE_0D(_e)                            \
     do {                                        \
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 16:36:01 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 16:36:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694892.1084124 (Exim 4.92)
	(envelope-from )
	id 1rmFxx-0005mS-IC; Mon, 18 Mar 2024 16:36:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694892.1084124; Mon, 18 Mar 2024 16:36:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmFxx-0005mL-DV; Mon, 18 Mar 2024 16:36:01 +0000
Received: by outflank-mailman (input) for mailman id 694892;
 Mon, 18 Mar 2024 16:36:00 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmFxw-0005JN-97
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 16:36:00 +0000
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com
 [2a00:1450:4864:20::52b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 996fdeaf-e545-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 17:35:58 +0100 (CET)
Received: by mail-ed1-x52b.google.com with SMTP id
 4fb4d7f45d1cf-568aa3096e9so5493096a12.0
 for ; Mon, 18 Mar 2024 09:35:58 -0700 (PDT)
Received: from andrewcoop.citrite.net (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 j22-20020a170906051600b00a441a7a75b5sm4988894eja.209.2024.03.18.09.35.56
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 18 Mar 2024 09:35:56 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 996fdeaf-e545-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710779758; x=1711384558; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=x3WegiCwiNXkkjs6VfwYfT79v4emqYj9IeVAQcTvOi4=;
        b=cpOoF0uaI4Pa8rubhx2A76gvCLgQDPevnFFRYNeTNO0wU+etRQUt5RuMJDO9s/350u
         ly/Hw4+GnD+RNILgwFwK+5rSLtYYxFnFHOeA+lkEm+Vo6BaCyy7poaaiE0D8UFx/Vw1R
         85VlsI2y5EcTKRJxCXQjvp/1xwHh5S/d0fHoU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710779758; x=1711384558;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=x3WegiCwiNXkkjs6VfwYfT79v4emqYj9IeVAQcTvOi4=;
        b=BNgw4RTY+UZY0P6NYbdPCRUwrs46mNNFHWcsMF1MdG9DwqX+ISUyWNRPBRPd0euAXd
         GEEEAM/V5FKO6AX4rgp+3x4HqHJbDcqhzHCy/tkjIi5pjzQDeaWNL55NgPBF2x6x2gBL
         gi7W7KktYfhhtxdfIVKmp2YvubWFrpKalXVPv4tsPoYT5r9A+f54FmnU6HSesaNZzNgq
         lna7sjTl4Qn/gRmkpvCMU8cqg1gJa+1vOFcl5bX/W1qBCSUOF5xmgPc1Mex3TxpKMKlP
         /z2InVtITQJjMDUnIGacz3lRMfrt+yn0DjzEQ9ZLMjB+igmlLZgmKVWXmJrW7oV8z6wO
         /tsQ==
X-Gm-Message-State: AOJu0Yw+EVEIbMVp3xSOvb9zH4hED+4btHHGFFnOvV3JMzUVj9O/MfU9
	HiBcSOHxY9UecOMtiKbZpF+RNSN0vheDnV/nhhJ8Km0Xl/MynQLP8uHK0AKwPLMV+6umAMClWUg
	J
X-Google-Smtp-Source: AGHT+IFwQFT4d2T2VeU4ObTqUFuCgzNbdi9xZPxcaU1yxWCMOe8aG00Scb7/bBqScL2xuuXgVRZpVw==
X-Received: by 2002:a17:906:80c4:b0:a46:a8b8:f4cf with SMTP id a4-20020a17090680c400b00a46a8b8f4cfmr79151ejx.35.1710779757835;
        Mon, 18 Mar 2024 09:35:57 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	Dario Faggioli ,
	George Dunlap ,
	Jan Beulich ,
	Stefano Stabellini ,
	Julien Grall ,
	Nicola Vetrini ,
	"consulting @ bugseng . com" 
Subject: [PATCH 2/7] xen/credit2: Clean up trace handling
Date: Mon, 18 Mar 2024 16:35:47 +0000
Message-Id: <20240318163552.3808695-3-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20240318163552.3808695-1-andrew.cooper3@citrix.com>
References: <20240318163552.3808695-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

There is no need for bitfields anywhere - use more sensible types.  There is
also no need to cast 'd' to (unsigned char *) before passing it to a function
taking void *.  Switch to new trace_time() API.

No functional change.

Signed-off-by: Andrew Cooper 
Reviewed-by: Jan Beulich 
Reviewed-by: Dario Faggioli 
---
CC: George Dunlap 
CC: Jan Beulich 
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Dario Faggioli 
CC: Nicola Vetrini 
CC: consulting@bugseng.com 

v2:
 * Fix whitespace.
v3:
 * Rebase over core API changes.
---
 xen/common/sched/credit2.c | 301 ++++++++++++++++++-------------------
 1 file changed, 146 insertions(+), 155 deletions(-)

diff --git a/xen/common/sched/credit2.c b/xen/common/sched/credit2.c
index c76330d79d3a..b7df9f2a9111 100644
--- a/xen/common/sched/credit2.c
+++ b/xen/common/sched/credit2.c
@@ -1085,13 +1085,13 @@ static void update_max_weight(struct csched2_runqueue_data *rqd, int new_weight,
     if ( unlikely(tb_init_done) )
     {
         struct {
-            unsigned rqi:16, max_weight:16;
-        } d;
-        d.rqi = rqd->id;
-        d.max_weight = rqd->max_weight;
-        __trace_var(TRC_CSCHED2_RUNQ_MAX_WEIGHT, 1,
-                    sizeof(d),
-                    (unsigned char *)&d);
+            uint16_t rqi, max_weight;
+        } d = {
+            .rqi        = rqd->id,
+            .max_weight = rqd->max_weight,
+        };
+
+        trace_time(TRC_CSCHED2_RUNQ_MAX_WEIGHT, sizeof(d), &d);
     }
 }
 
@@ -1119,9 +1119,7 @@ _runq_assign(struct csched2_unit *svc, struct csched2_runqueue_data *rqd)
             .rqi  = rqd->id,
         };
 
-        __trace_var(TRC_CSCHED2_RUNQ_ASSIGN, 1,
-                    sizeof(d),
-                    (unsigned char *)&d);
+        trace_time(TRC_CSCHED2_RUNQ_ASSIGN, sizeof(d), &d);
     }
 
 }
@@ -1354,9 +1352,7 @@ update_runq_load(const struct scheduler *ops,
             .shift      = P,
         };
 
-        __trace_var(TRC_CSCHED2_UPDATE_RUNQ_LOAD, 1,
-                    sizeof(d),
-                    (unsigned char *)&d);
+        trace_time(TRC_CSCHED2_UPDATE_RUNQ_LOAD, sizeof(d), &d);
     }
 }
 
@@ -1406,16 +1402,16 @@ update_svc_load(const struct scheduler *ops,
     {
         struct {
             uint64_t v_avgload;
-            unsigned unit:16, dom:16;
-            unsigned shift;
-        } d;
-        d.dom = svc->unit->domain->domain_id;
-        d.unit = svc->unit->unit_id;
-        d.v_avgload = svc->avgload;
-        d.shift = P;
-        __trace_var(TRC_CSCHED2_UPDATE_UNIT_LOAD, 1,
-                    sizeof(d),
-                    (unsigned char *)&d);
+            uint16_t unit, dom;
+            uint32_t shift;
+        } d = {
+            .v_avgload = svc->avgload,
+            .unit      = svc->unit->unit_id,
+            .dom       = svc->unit->domain->domain_id,
+            .shift     = P,
+        };
+
+        trace_time(TRC_CSCHED2_UPDATE_UNIT_LOAD, sizeof(d), &d);
     }
 }
 
@@ -1424,7 +1420,7 @@ update_load(const struct scheduler *ops,
             struct csched2_runqueue_data *rqd,
             struct csched2_unit *svc, int change, s_time_t now)
 {
-    trace_var(TRC_CSCHED2_UPDATE_LOAD, 1, 0,  NULL);
+    TRACE_TIME(TRC_CSCHED2_UPDATE_LOAD);
 
     update_runq_load(ops, rqd, change, now);
     if ( svc )
@@ -1462,15 +1458,15 @@ static void runq_insert(struct csched2_unit *svc)
     if ( unlikely(tb_init_done) )
     {
         struct {
-            unsigned unit:16, dom:16;
-            unsigned pos;
-        } d;
-        d.dom = svc->unit->domain->domain_id;
-        d.unit = svc->unit->unit_id;
-        d.pos = pos;
-        __trace_var(TRC_CSCHED2_RUNQ_POS, 1,
-                    sizeof(d),
-                    (unsigned char *)&d);
+            uint16_t unit, dom;
+            uint32_t pos;
+        } d = {
+            .unit = svc->unit->unit_id,
+            .dom  = svc->unit->domain->domain_id,
+            .pos  = pos,
+        };
+
+        trace_time(TRC_CSCHED2_RUNQ_POS, sizeof(d), &d);
     }
 }
 
@@ -1563,16 +1559,16 @@ static s_time_t tickle_score(const struct scheduler *ops, s_time_t now,
     if ( unlikely(tb_init_done) )
     {
         struct {
-            unsigned unit:16, dom:16;
-            int credit, score;
-        } d;
-        d.dom = cur->unit->domain->domain_id;
-        d.unit = cur->unit->unit_id;
-        d.credit = cur->credit;
-        d.score = score;
-        __trace_var(TRC_CSCHED2_TICKLE_CHECK, 1,
-                    sizeof(d),
-                    (unsigned char *)&d);
+            uint16_t unit, dom;
+            uint32_t credit, score;
+        } d = {
+            .unit   = cur->unit->unit_id,
+            .dom    = cur->unit->domain->domain_id,
+            .credit = cur->credit,
+            .score  = score,
+        };
+
+        trace_time(TRC_CSCHED2_TICKLE_CHECK, sizeof(d), &d);
     }
 
     return score;
@@ -1610,17 +1606,16 @@ runq_tickle(const struct scheduler *ops, struct csched2_unit *new, s_time_t now)
     if ( unlikely(tb_init_done) )
     {
         struct {
-            unsigned unit:16, dom:16;
-            unsigned processor;
-            int credit;
-        } d;
-        d.dom = unit->domain->domain_id;
-        d.unit = unit->unit_id;
-        d.processor = cpu;
-        d.credit = new->credit;
-        __trace_var(TRC_CSCHED2_TICKLE_NEW, 1,
-                    sizeof(d),
-                    (unsigned char *)&d);
+            uint16_t unit, dom;
+            uint32_t processor, credit;
+        } d = {
+            .dom       = unit->domain->domain_id,
+            .unit      = unit->unit_id,
+            .processor = cpu,
+            .credit    = new->credit,
+        };
+
+        trace_time(TRC_CSCHED2_TICKLE_NEW, sizeof(d), &d);
     }
 
     /*
@@ -1759,12 +1754,12 @@ runq_tickle(const struct scheduler *ops, struct csched2_unit *new, s_time_t now)
     if ( unlikely(tb_init_done) )
     {
         struct {
-            unsigned cpu:16, pad:16;
-        } d;
-        d.cpu = ipid; d.pad = 0;
-        __trace_var(TRC_CSCHED2_TICKLE, 1,
-                    sizeof(d),
-                    (unsigned char *)&d);
+            uint16_t cpu, _pad;
+        } d = {
+            .cpu = ipid,
+        };
+
+        trace_time(TRC_CSCHED2_TICKLE, sizeof(d), &d);
     }
 
     tickle_cpu(ipid, rqd);
@@ -1840,16 +1835,16 @@ static void reset_credit(int cpu, s_time_t now, struct csched2_unit *snext)
         if ( unlikely(tb_init_done) )
         {
             struct {
-                unsigned unit:16, dom:16;
-                int credit_start, credit_end;
-            } d;
-            d.dom = svc->unit->domain->domain_id;
-            d.unit = svc->unit->unit_id;
-            d.credit_start = start_credit;
-            d.credit_end = svc->credit;
-            __trace_var(TRC_CSCHED2_CREDIT_RESET, 1,
-                        sizeof(d),
-                        (unsigned char *)&d);
+                uint16_t unit, dom;
+                uint32_t credit_start, credit_end;
+            } d = {
+                .unit         = svc->unit->unit_id,
+                .dom          = svc->unit->domain->domain_id,
+                .credit_start = start_credit,
+                .credit_end   = svc->credit,
+            };
+
+            trace_time(TRC_CSCHED2_CREDIT_RESET, sizeof(d), &d);
         }
     }
 
@@ -1895,18 +1890,17 @@ void burn_credits(struct csched2_runqueue_data *rqd,
     if ( unlikely(tb_init_done) )
     {
         struct {
-            unsigned unit:16, dom:16;
-            int credit, budget;
-            int delta;
-        } d;
-        d.dom = svc->unit->domain->domain_id;
-        d.unit = svc->unit->unit_id;
-        d.credit = svc->credit;
-        d.budget = has_cap(svc) ?  svc->budget : INT_MIN;
-        d.delta = delta;
-        __trace_var(TRC_CSCHED2_CREDIT_BURN, 1,
-                    sizeof(d),
-                    (unsigned char *)&d);
+            uint16_t unit, dom;
+            uint32_t credit, budget, delta;
+        } d = {
+            .unit   = svc->unit->unit_id,
+            .dom    = svc->unit->domain->domain_id,
+            .credit = svc->credit,
+            .budget = has_cap(svc) ? svc->budget : INT_MIN,
+            .delta  = delta,
+        };
+
+        trace_time(TRC_CSCHED2_CREDIT_BURN, sizeof(d), &d);
     }
 }
 
@@ -2551,17 +2545,17 @@ csched2_res_pick(const struct scheduler *ops, const struct sched_unit *unit)
     {
         struct {
             uint64_t b_avgload;
-            unsigned unit:16, dom:16;
-            unsigned rq_id:16, new_cpu:16;
-        } d;
-        d.dom = unit->domain->domain_id;
-        d.unit = unit->unit_id;
-        d.rq_id = min_rqd ? min_rqd->id : -1;
-        d.b_avgload = min_avgload;
-        d.new_cpu = new_cpu;
-        __trace_var(TRC_CSCHED2_PICKED_CPU, 1,
-                    sizeof(d),
-                    (unsigned char *)&d);
+            uint16_t unit, dom;
+            uint16_t rq_id, new_cpu;
+        } d = {
+            .b_avgload = min_avgload,
+            .unit      = unit->unit_id,
+            .dom       = unit->domain->domain_id,
+            .rq_id     = min_rqd ? min_rqd->id : -1,
+            .new_cpu   = new_cpu,
+        };
+
+        trace_time(TRC_CSCHED2_PICKED_CPU, sizeof(d), &d);
     }
 
     return get_sched_res(new_cpu);
@@ -2622,16 +2616,16 @@ static void migrate(const struct scheduler *ops,
     if ( unlikely(tb_init_done) )
     {
         struct {
-            unsigned unit:16, dom:16;
-            unsigned rqi:16, trqi:16;
-        } d;
-        d.dom = unit->domain->domain_id;
-        d.unit = unit->unit_id;
-        d.rqi = svc->rqd->id;
-        d.trqi = trqd->id;
-        __trace_var(TRC_CSCHED2_MIGRATE, 1,
-                    sizeof(d),
-                    (unsigned char *)&d);
+            uint16_t unit, dom;
+            uint16_t rqi, trqi;
+        } d = {
+            .unit = unit->unit_id,
+            .dom  = unit->domain->domain_id,
+            .rqi  = svc->rqd->id,
+            .trqi = trqd->id,
+        };
+
+        trace_time(TRC_CSCHED2_MIGRATE, sizeof(d), &d);
     }
 
     if ( svc->flags & CSFLAG_scheduled )
@@ -2768,15 +2762,15 @@ static void balance_load(const struct scheduler *ops, int cpu, s_time_t now)
         if ( unlikely(tb_init_done) )
         {
             struct {
-                unsigned lrq_id:16, orq_id:16;
-                unsigned load_delta;
-            } d;
-            d.lrq_id = st.lrqd->id;
-            d.orq_id = st.orqd->id;
-            d.load_delta = st.load_delta;
-            __trace_var(TRC_CSCHED2_LOAD_CHECK, 1,
-                        sizeof(d),
-                        (unsigned char *)&d);
+                uint16_t lrq_id, orq_id;
+                uint32_t load_delta;
+            } d = {
+                .lrq_id     = st.lrqd->id,
+                .orq_id     = st.orqd->id,
+                .load_delta = st.load_delta,
+            };
+
+            trace_time(TRC_CSCHED2_LOAD_CHECK, sizeof(d), &d);
         }
 
         /*
@@ -2820,9 +2814,7 @@ static void balance_load(const struct scheduler *ops, int cpu, s_time_t now)
             .orq_id     = st.orqd->id,
         };
 
-        __trace_var(TRC_CSCHED2_LOAD_BALANCE, 1,
-                    sizeof(d),
-                    (unsigned char *)&d);
+        trace_time(TRC_CSCHED2_LOAD_BALANCE, sizeof(d), &d);
     }
 
     SCHED_STAT_CRANK(acct_load_balance);
@@ -3407,15 +3399,15 @@ runq_candidate(struct csched2_runqueue_data *rqd,
         if ( unlikely(tb_init_done) )
         {
             struct {
-                unsigned unit:16, dom:16;
-                unsigned runtime;
-            } d;
-            d.dom = scurr->unit->domain->domain_id;
-            d.unit = scurr->unit->unit_id;
-            d.runtime = now - scurr->unit->state_entry_time;
-            __trace_var(TRC_CSCHED2_RATELIMIT, 1,
-                        sizeof(d),
-                        (unsigned char *)&d);
+                uint16_t unit, dom;
+                uint32_t runtime;
+            } d = {
+                .unit    = scurr->unit->unit_id,
+                .dom     = scurr->unit->domain->domain_id,
+                .runtime = now - scurr->unit->state_entry_time,
+            };
+
+            trace_time(TRC_CSCHED2_RATELIMIT, sizeof(d), &d);
         }
         return scurr;
     }
@@ -3468,13 +3460,13 @@ runq_candidate(struct csched2_runqueue_data *rqd,
         if ( unlikely(tb_init_done) )
         {
             struct {
-                unsigned unit:16, dom:16;
-            } d;
-            d.dom = svc->unit->domain->domain_id;
-            d.unit = svc->unit->unit_id;
-            __trace_var(TRC_CSCHED2_RUNQ_CAND_CHECK, 1,
-                        sizeof(d),
-                        (unsigned char *)&d);
+                uint16_t unit, dom;
+            } d = {
+                .unit = svc->unit->unit_id,
+                .dom  = svc->unit->domain->domain_id,
+            };
+
+            trace_time(TRC_CSCHED2_RUNQ_CAND_CHECK, sizeof(d), &d);
         }
 
         /*
@@ -3542,17 +3534,16 @@ runq_candidate(struct csched2_runqueue_data *rqd,
     if ( unlikely(tb_init_done) )
     {
         struct {
-            unsigned unit:16, dom:16;
-            unsigned tickled_cpu;
-            int credit;
-        } d;
-        d.dom = snext->unit->domain->domain_id;
-        d.unit = snext->unit->unit_id;
-        d.credit = snext->credit;
-        d.tickled_cpu = snext->tickled_cpu;
-        __trace_var(TRC_CSCHED2_RUNQ_CANDIDATE, 1,
-                    sizeof(d),
-                    (unsigned char *)&d);
+            uint16_t unit, dom;
+            uint32_t tickled_cpu, credit;
+        } d = {
+            .unit        = snext->unit->unit_id,
+            .dom         = snext->unit->domain->domain_id,
+            .tickled_cpu = snext->tickled_cpu,
+            .credit      = snext->credit,
+        };
+
+        trace_time(TRC_CSCHED2_RUNQ_CANDIDATE, sizeof(d), &d);
     }
 
     if ( unlikely(snext->tickled_cpu != -1 && snext->tickled_cpu != cpu) )
@@ -3608,18 +3599,18 @@ static void cf_check csched2_schedule(
     if ( unlikely(tb_init_done) )
     {
         struct {
-            unsigned cpu:16, rq_id:16;
-            unsigned tasklet:8, idle:8, smt_idle:8, tickled:8;
-        } d;
-        d.cpu = cur_cpu;
-        d.rq_id = c2r(sched_cpu);
-        d.tasklet = tasklet_work_scheduled;
-        d.idle = is_idle_unit(currunit);
-        d.smt_idle = cpumask_test_cpu(sched_cpu, &rqd->smt_idle);
-        d.tickled = tickled;
-        __trace_var(TRC_CSCHED2_SCHEDULE, 1,
-                    sizeof(d),
-                    (unsigned char *)&d);
+            uint16_t cpu, rq_id;
+            uint8_t tasklet, idle, smt_idle, tickled;
+        } d = {
+            .cpu      = cur_cpu,
+            .rq_id    = c2r(sched_cpu),
+            .tasklet  = tasklet_work_scheduled,
+            .idle     = is_idle_unit(currunit),
+            .smt_idle = cpumask_test_cpu(sched_cpu, &rqd->smt_idle),
+            .tickled  = tickled,
+        };
+
+        trace_time(TRC_CSCHED2_SCHEDULE, sizeof(d), &d);
     }
 
     /* Update credits (and budget, if necessary). */
@@ -3654,7 +3645,7 @@ static void cf_check csched2_schedule(
     if ( tasklet_work_scheduled )
     {
         __clear_bit(__CSFLAG_unit_yield, &scurr->flags);
-        trace_var(TRC_CSCHED2_SCHED_TASKLET, 1, 0, NULL);
+        TRACE_TIME(TRC_CSCHED2_SCHED_TASKLET);
         snext = csched2_unit(sched_idle_unit(sched_cpu));
     }
     else
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 16:36:02 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 16:36:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694890.1084104 (Exim 4.92)
	(envelope-from )
	id 1rmFxw-0005Jg-2c; Mon, 18 Mar 2024 16:36:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694890.1084104; Mon, 18 Mar 2024 16:36:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmFxv-0005JZ-Vu; Mon, 18 Mar 2024 16:35:59 +0000
Received: by outflank-mailman (input) for mailman id 694890;
 Mon, 18 Mar 2024 16:35:58 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmFxu-0005JN-Pz
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 16:35:58 +0000
Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com
 [2a00:1450:4864:20::636])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 987eb1b1-e545-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 17:35:57 +0100 (CET)
Received: by mail-ej1-x636.google.com with SMTP id
 a640c23a62f3a-a46c35dfb5aso140877966b.2
 for ; Mon, 18 Mar 2024 09:35:57 -0700 (PDT)
Received: from andrewcoop.citrite.net (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 j22-20020a170906051600b00a441a7a75b5sm4988894eja.209.2024.03.18.09.35.55
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 18 Mar 2024 09:35:55 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 987eb1b1-e545-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710779756; x=1711384556; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:from:to:cc:subject:date:message-id:reply-to;
        bh=zEC7r2jF8BEfoecBkIf0j/7FO0i8OB8TShnkhkJo6Z8=;
        b=OL+X+IGgYBuay1hXgdfHalxmHCBn4LE8pDIqsvIURAUYCorIp/H9VGcLtWZpph+kXW
         IeoGjsEvBYXlcaQkIA+ULB69FEcN2FEoMbCxMF2QCptOBmYoJiRaNQBVD6RSLCyNaPCv
         Hm7ohJ4g8SaPcVTByhb0OuBZ891kn6FGPWCaE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710779756; x=1711384556;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=zEC7r2jF8BEfoecBkIf0j/7FO0i8OB8TShnkhkJo6Z8=;
        b=B0x2uCdGMqncU/o0sYj5PNLyhLTLEGeWop3xzLs5lIzb77krtknQDlETZWIdRnC+97
         va9wAwGPM90ZfR6ayREa4aemgAk7Qj3q2Fo5B70bf9ojt1PfnhRenmGWF5H1ySZ/ke9I
         eSW0bEJsxWRX0D4Lb214gNbBHGF9RWILJquhmj4lpOrDmlRiwgMXk61Fu0LCqrMrE9i6
         VZNItU080T62JeiDaGSTMnZhuTaUngf8US3mxyK/Uz8nl1hAy3T/JOdIuLMK3z9jn/77
         KYcaMpL32QNOXBEsy65f6Hw2MWVflbeUL+f7d6jhxGOlr8/jYdhTDR6MBK2fXWp8hIHJ
         9lyQ==
X-Gm-Message-State: AOJu0YzSRGurz4kk7NBfRB9kYNa98T5vDt8QoUsZF35wLf7f+pgQfCkk
	gA8r3Lx42xOn+IdR0x3yvF+HwxFNmkUJ/x4/yNiqWduUiQJlpiCIssGQjCEhk9OU+4v6aLlFdDT
	B
X-Google-Smtp-Source: AGHT+IFwbiIi1rM/HknDpp84YFhD/NI3g6a796y6wylzweGrU90oJEWIkrxuBx30VRm1X8aipP4yUw==
X-Received: by 2002:a17:907:60ca:b0:a44:5477:bb46 with SMTP id hv10-20020a17090760ca00b00a445477bb46mr10862867ejc.61.1710779755745;
        Mon, 18 Mar 2024 09:35:55 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	George Dunlap ,
	Jan Beulich ,
	Stefano Stabellini ,
	Julien Grall ,
	Dario Faggioli ,
	Nicola Vetrini ,
	"consulting @ bugseng . com" 
Subject: [PATCH 0/7] xen/trace: Treewide API cleanup
Date: Mon, 18 Mar 2024 16:35:45 +0000
Message-Id: <20240318163552.3808695-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.30.2
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Rework the trace API to unify it (remove the HVM specific obfuscation), and
remove MISRA violations.

v3:
 * Delete TRACE_PARAM64()

Andrew Cooper (7):
  xen/trace: Introduce new API
  xen/credit2: Clean up trace handling
  xen/rt: Clean up trace handling
  xen/sched: Clean up trace handling
  xen: Switch to new TRACE() API
  xen/trace: Update final {__,}trace_var() users to the new API
  xen/trace: Drop old trace API

 xen/arch/x86/acpi/cpu_idle.c           |  12 +-
 xen/arch/x86/compat.c                  |   4 +-
 xen/arch/x86/cpu/mwait-idle.c          |   6 +-
 xen/arch/x86/emul-i8254.c              |  14 +-
 xen/arch/x86/hvm/emulate.c             |  11 +-
 xen/arch/x86/hvm/hpet.c                |   7 +-
 xen/arch/x86/hvm/hvm.c                 |  20 +-
 xen/arch/x86/hvm/io.c                  |   1 -
 xen/arch/x86/hvm/rtc.c                 |  12 +-
 xen/arch/x86/hvm/svm/intr.c            |   7 +-
 xen/arch/x86/hvm/svm/svm.c             |  43 ++--
 xen/arch/x86/hvm/vlapic.c              |  52 +++--
 xen/arch/x86/hvm/vmx/intr.c            |   7 +-
 xen/arch/x86/hvm/vmx/vmx.c             |  57 +++--
 xen/arch/x86/hvm/vpic.c                |  13 +-
 xen/arch/x86/include/asm/hvm/trace.h   | 114 ----------
 xen/arch/x86/include/asm/hvm/vmx/vmx.h |   1 -
 xen/arch/x86/irq.c                     |  16 +-
 xen/arch/x86/mm/p2m-pod.c              |   8 +-
 xen/arch/x86/mm/p2m-pt.c               |   2 +-
 xen/arch/x86/mm/shadow/common.c        |   6 +-
 xen/arch/x86/mm/shadow/multi.c         |  10 +-
 xen/arch/x86/pv/trace.c                |  21 +-
 xen/arch/x86/traps.c                   |   2 +-
 xen/common/domain.c                    |   4 +-
 xen/common/grant_table.c               |   6 +-
 xen/common/memory.c                    |   2 +-
 xen/common/sched/core.c                |  56 +++--
 xen/common/sched/credit.c              |  70 +++---
 xen/common/sched/credit2.c             | 301 ++++++++++++-------------
 xen/common/sched/null.c                |  63 +++---
 xen/common/sched/rt.c                  |  99 ++++----
 xen/common/trace.c                     |   9 +-
 xen/drivers/cpufreq/utility.c          |   2 +-
 xen/include/xen/trace.h                |  67 ++----
 35 files changed, 493 insertions(+), 632 deletions(-)
 delete mode 100644 xen/arch/x86/include/asm/hvm/trace.h


base-commit: 62018f08708a5ff6ef8fc8ff2aaaac46e5a60430
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 16:36:03 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 16:36:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694893.1084134 (Exim 4.92)
	(envelope-from )
	id 1rmFxy-00062i-TO; Mon, 18 Mar 2024 16:36:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694893.1084134; Mon, 18 Mar 2024 16:36:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmFxy-00062Z-PG; Mon, 18 Mar 2024 16:36:02 +0000
Received: by outflank-mailman (input) for mailman id 694893;
 Mon, 18 Mar 2024 16:36:01 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmFxx-0005JN-MY
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 16:36:01 +0000
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com
 [2a00:1450:4864:20::62b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9a5bf40b-e545-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 17:36:00 +0100 (CET)
Received: by mail-ej1-x62b.google.com with SMTP id
 a640c23a62f3a-a466f796fc1so587433066b.3
 for ; Mon, 18 Mar 2024 09:36:00 -0700 (PDT)
Received: from andrewcoop.citrite.net (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 j22-20020a170906051600b00a441a7a75b5sm4988894eja.209.2024.03.18.09.35.57
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 18 Mar 2024 09:35:58 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9a5bf40b-e545-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710779759; x=1711384559; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=43RBkv9nNt2AeKgY3ovhftrUIQfOhkhQXVZiRG6YSx0=;
        b=ao95LOdoc7zdpUQ4jYJnKqA17h0rGI3dejjuPRtnGGrxignSsS5w4020N8y6RymxdH
         4fIg678LMf/VPL2J06Ab3e6Uuv4XJ5tSNfEyn2bsuauy4u0r64KhSes8qUfSEDB8iikW
         sEA9xjnBmenTnJPeICi3jiEqfqFILnHpTW0Ho=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710779759; x=1711384559;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=43RBkv9nNt2AeKgY3ovhftrUIQfOhkhQXVZiRG6YSx0=;
        b=UQDtyIFVXhVHC1Phm9WQMvO7EVG7YubIaBNehvesD9iHAuPXX4JyT0Fgg55Q4i075z
         6vOqZ/2VS2VDiqKorYorVbuXdKya3upgDdtvsPClkPlWl9lylx8A++HhaF/JgDqZdZnH
         d6yyOm2gj7xcoCTBgkCkDq4LMHFsIqou7f2QKhUo03GvbeOhErlAfp8mEcW5Jkk8r7pE
         Qpen9vOsKve0/7Ugbgu2kslqOvG3mKD3yaLnVEam1GX4Cna9p3rUqM9rdpCIRn3PnvI4
         ZEeyPPuh3mpUv15GXxnRUFtgpszGXXm0hX4hFEelQnYkyVCaGb5PY5gyyKSEhOF3XZVO
         +E/g==
X-Gm-Message-State: AOJu0YwOzRNoc3I2QbP5ATdG3HhZVbDaF+7USa9D46pZZmx7lhnxhjV9
	wfkgriKsqrYAGylO/CQtscmHsc+gxvPun1+pFITUKTIjvojBZmSHxFzG3URxxs9TPcxcpm56cER
	/
X-Google-Smtp-Source: AGHT+IHE1OrPskT/jI53hC6Cj/B9BDqWSE89qkPT9exCF/Pfak0XZaz2HnBAxNcRRpgi/aJbGFHuLw==
X-Received: by 2002:a17:906:190e:b0:a46:24fa:ea9f with SMTP id a14-20020a170906190e00b00a4624faea9fmr7551909eje.37.1710779758953;
        Mon, 18 Mar 2024 09:35:58 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Dario Faggioli ,
	George Dunlap ,
	Jan Beulich ,
	Stefano Stabellini ,
	Julien Grall ,
	Nicola Vetrini ,
	"consulting @ bugseng . com" 
Subject: [PATCH 3/7] xen/rt: Clean up trace handling
Date: Mon, 18 Mar 2024 16:35:48 +0000
Message-Id: <20240318163552.3808695-4-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20240318163552.3808695-1-andrew.cooper3@citrix.com>
References: <20240318163552.3808695-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Most uses of bitfields and __packed are unnecessary.  There is also no need to
cast 'd' to (unsigned char *) before passing it to a function taking void *.
Switch to new trace_time() API.

No functional change.

Signed-off-by: Andrew Cooper 
Reviewed-by: Dario Faggioli 
---
CC: George Dunlap 
CC: Jan Beulich 
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Dario Faggioli 
CC: Nicola Vetrini 
CC: consulting@bugseng.com 

v2:
 * New.
v3:
 * Rebase over core API changes.
---
 xen/common/sched/rt.c | 99 ++++++++++++++++++++-----------------------
 1 file changed, 47 insertions(+), 52 deletions(-)

diff --git a/xen/common/sched/rt.c b/xen/common/sched/rt.c
index b279f957f622..f368e0fdd5a5 100644
--- a/xen/common/sched/rt.c
+++ b/xen/common/sched/rt.c
@@ -455,21 +455,21 @@ rt_update_deadline(s_time_t now, struct rt_unit *svc)
     svc->cur_budget = svc->budget;
     svc->priority_level = 0;
 
-    /* TRACE */
+    if ( unlikely(tb_init_done) )
     {
-        struct __packed {
-            unsigned unit:16, dom:16;
-            unsigned priority_level;
+        struct {
+            uint16_t unit, dom;
+            uint32_t priority_level;
             uint64_t cur_deadline, cur_budget;
-        } d;
-        d.dom = svc->unit->domain->domain_id;
-        d.unit = svc->unit->unit_id;
-        d.priority_level = svc->priority_level;
-        d.cur_deadline = (uint64_t) svc->cur_deadline;
-        d.cur_budget = (uint64_t) svc->cur_budget;
-        trace_var(TRC_RTDS_BUDGET_REPLENISH, 1,
-                  sizeof(d),
-                  (unsigned char *) &d);
+        } d = {
+            .dom            = svc->unit->domain->domain_id,
+            .unit           = svc->unit->unit_id,
+            .priority_level = svc->priority_level,
+            .cur_deadline   = svc->cur_deadline,
+            .cur_budget     = svc->cur_budget,
+        };
+
+        trace_time(TRC_RTDS_BUDGET_REPLENISH, sizeof(d), &d);
     }
 
     return;
@@ -986,7 +986,7 @@ burn_budget(const struct scheduler *ops, struct rt_unit *svc, s_time_t now)
         }
     }
 
-    /* TRACE */
+    if ( unlikely(tb_init_done) )
     {
         struct __packed {
             uint16_t unit, dom;
@@ -1003,9 +1003,7 @@ burn_budget(const struct scheduler *ops, struct rt_unit *svc, s_time_t now)
             .has_extratime  = !!(svc->flags & RTDS_extratime),
         };
 
-        trace_var(TRC_RTDS_BUDGET_BURN, 1,
-                  sizeof(d),
-                  (unsigned char *) &d);
+        trace_time(TRC_RTDS_BUDGET_BURN, sizeof(d), &d);
     }
 }
 
@@ -1040,22 +1038,19 @@ runq_pick(const struct scheduler *ops, const cpumask_t *mask, unsigned int cpu)
         break;
     }
 
-    /* TRACE */
+    if ( unlikely(tb_init_done) && svc )
     {
-        if( svc != NULL )
-        {
-            struct __packed {
-                unsigned unit:16, dom:16;
-                uint64_t cur_deadline, cur_budget;
-            } d;
-            d.dom = svc->unit->domain->domain_id;
-            d.unit = svc->unit->unit_id;
-            d.cur_deadline = (uint64_t) svc->cur_deadline;
-            d.cur_budget = (uint64_t) svc->cur_budget;
-            trace_var(TRC_RTDS_RUNQ_PICK, 1,
-                      sizeof(d),
-                      (unsigned char *) &d);
-        }
+        struct __packed {
+            uint16_t unit, dom;
+            uint64_t cur_deadline, cur_budget;
+        } d = {
+            .unit         = svc->unit->unit_id,
+            .dom          = svc->unit->domain->domain_id,
+            .cur_deadline = svc->cur_deadline,
+            .cur_budget   = svc->cur_budget,
+        };
+
+        trace_time(TRC_RTDS_RUNQ_PICK, sizeof(d), &d);
     }
 
     return svc;
@@ -1076,18 +1071,19 @@ rt_schedule(const struct scheduler *ops, struct sched_unit *currunit,
     struct rt_unit *snext = NULL;
     bool migrated = false;
 
-    /* TRACE */
+    if ( unlikely(tb_init_done) )
     {
-        struct __packed {
-            unsigned cpu:16, tasklet:8, tickled:4, idle:4;
-        } d;
-        d.cpu = cur_cpu;
-        d.tasklet = tasklet_work_scheduled;
-        d.tickled = cpumask_test_cpu(sched_cpu, &prv->tickled);
-        d.idle = is_idle_unit(currunit);
-        trace_var(TRC_RTDS_SCHEDULE, 1,
-                  sizeof(d),
-                  (unsigned char *)&d);
+        struct {
+            uint16_t cpu;
+            uint8_t tasklet, tickled:4, idle:4;
+        } d = {
+            .cpu     = cur_cpu,
+            .tasklet = tasklet_work_scheduled,
+            .tickled = cpumask_test_cpu(sched_cpu, &prv->tickled),
+            .idle    = is_idle_unit(currunit),
+        };
+
+        trace_time(TRC_RTDS_SCHEDULE, sizeof(d), &d);
     }
 
     /* clear ticked bit now that we've been scheduled */
@@ -1098,7 +1094,7 @@ rt_schedule(const struct scheduler *ops, struct sched_unit *currunit,
 
     if ( tasklet_work_scheduled )
     {
-        trace_var(TRC_RTDS_SCHED_TASKLET, 1, 0,  NULL);
+        TRACE_TIME(TRC_RTDS_SCHED_TASKLET);
         snext = rt_unit(sched_idle_unit(sched_cpu));
     }
     else
@@ -1250,16 +1246,15 @@ runq_tickle(const struct scheduler *ops, const struct rt_unit *new)
     SCHED_STAT_CRANK(tickled_no_cpu);
     return;
  out:
-    /* TRACE */
+    if ( unlikely(tb_init_done) )
     {
         struct {
-            unsigned cpu:16, pad:16;
-        } d;
-        d.cpu = cpu_to_tickle;
-        d.pad = 0;
-        trace_var(TRC_RTDS_TICKLE, 1,
-                  sizeof(d),
-                  (unsigned char *)&d);
+            uint16_t cpu, _pad;
+        } d = {
+            .cpu = cpu_to_tickle,
+        };
+
+        trace_time(TRC_RTDS_TICKLE, sizeof(d), &d);
     }
 
     cpumask_set_cpu(cpu_to_tickle, &prv->tickled);
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 16:36:04 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 16:36:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694894.1084144 (Exim 4.92)
	(envelope-from )
	id 1rmFy0-0006Iv-4z; Mon, 18 Mar 2024 16:36:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694894.1084144; Mon, 18 Mar 2024 16:36:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmFy0-0006Ii-1s; Mon, 18 Mar 2024 16:36:04 +0000
Received: by outflank-mailman (input) for mailman id 694894;
 Mon, 18 Mar 2024 16:36:02 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmFxy-0005JO-GX
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 16:36:02 +0000
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com
 [2a00:1450:4864:20::635])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9b45409c-e545-11ee-afdd-a90da7624cb6;
 Mon, 18 Mar 2024 17:36:01 +0100 (CET)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-a466e53f8c0so596821666b.1
 for ; Mon, 18 Mar 2024 09:36:01 -0700 (PDT)
Received: from andrewcoop.citrite.net (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 j22-20020a170906051600b00a441a7a75b5sm4988894eja.209.2024.03.18.09.35.59
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 18 Mar 2024 09:35:59 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9b45409c-e545-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710779760; x=1711384560; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=o1+TIJTTe6vbKVkQQzyzQLjvyWxN7MN/m4K6cIC1Be8=;
        b=BEx6t+/fYEi0z4xNzfjvmCcvyoMB5WwnxfquByAEHBE/Oc0nIC8tXT6H7kO0VpanAP
         FLBVxlNhkcp9DSGFteZP1NmtyDqP16F/QUJsoHYuww9/OdAVQT3h5P/zmsVq9z2vbabB
         hpk4IujbC8neqLhYqEoybc4uKgWIdfKExNE3w=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710779760; x=1711384560;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=o1+TIJTTe6vbKVkQQzyzQLjvyWxN7MN/m4K6cIC1Be8=;
        b=Rtwolck9/w7cevKYGRWazWW9vXWaPKoyPfush12/njQglg8v6vaesiOktJ2J7DpI15
         1TecVEHZAZzhCI3R7ir64aaLphn0RKGQXRqqtbEYMJ9VL3zD3lSKH+IpD8n9JpbURMZs
         x0PMbL59KI9dI5FIPQ60CN2+aM58y9ti86s72NG/ZWhS6P1gNlHT4FiZyZ2OHUK7JD8S
         WwFK6hvkEh1wZDz37haA+f6mMq0MUhkqra5nogQtRLm3kkZTJPU6Hf/pND9/pCVsTjaM
         pMhyKs2GeIo4rpGIDGRZegn8CmkqmP2CdijbESrgeQaD7/K9a2KzPUwI84EhJZmUYT88
         UEew==
X-Gm-Message-State: AOJu0YxOT+BT9oXOSgWa8/Cis5imkHrV26CcnX/suF3Yk86T82K7XeR7
	DvmjZJt01RECaVUQCFTTJsrMIufB49flgx/FA5LXRIcwDuseDjbGn6aUyTx31SqtfgxAqGwf7Zq
	x
X-Google-Smtp-Source: AGHT+IHztVPDUb2EwfK3dSyLyDrjgOO2EjrU9wAG3xcUThSleC6DVoqlKx6XIX8tPFsUp+jSg2NgPA==
X-Received: by 2002:a17:907:807:b0:a46:c06f:669e with SMTP id wv7-20020a170907080700b00a46c06f669emr2914527ejb.7.1710779760447;
        Mon, 18 Mar 2024 09:36:00 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Dario Faggioli ,
	George Dunlap ,
	Jan Beulich ,
	Stefano Stabellini ,
	Julien Grall ,
	Nicola Vetrini ,
	"consulting @ bugseng . com" 
Subject: [PATCH 4/7] xen/sched: Clean up trace handling
Date: Mon, 18 Mar 2024 16:35:49 +0000
Message-Id: <20240318163552.3808695-5-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20240318163552.3808695-1-andrew.cooper3@citrix.com>
References: <20240318163552.3808695-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

There is no need for bitfields anywhere - use more sensible types.  There is
also no need to cast 'd' to (unsigned char *) before passing it to a function
taking void *.  Switch to new trace_time() API.

No functional change.

Signed-off-by: Andrew Cooper 
Reviewed-by: Dario Faggioli 
---
CC: George Dunlap 
CC: Jan Beulich 
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Dario Faggioli 
CC: Nicola Vetrini 
CC: consulting@bugseng.com 

v2:
 * New.
v3:
 * Rebase over core API changes.
---
 xen/common/sched/core.c   | 56 +++++++++++++++----------------
 xen/common/sched/credit.c | 70 ++++++++++++++++++---------------------
 xen/common/sched/null.c   | 63 ++++++++++++++++++++---------------
 3 files changed, 97 insertions(+), 92 deletions(-)

diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
index 3e48da1cdd4e..cd662280bbad 100644
--- a/xen/common/sched/core.c
+++ b/xen/common/sched/core.c
@@ -205,7 +205,7 @@ static inline struct scheduler *vcpu_scheduler(const struct vcpu *v)
 
 static inline void trace_runstate_change(const struct vcpu *v, int new_state)
 {
-    struct { uint32_t vcpu:16, domain:16; } d;
+    struct { uint16_t vcpu, domain; } d;
     uint32_t event;
 
     if ( likely(!tb_init_done) )
@@ -218,12 +218,12 @@ static inline void trace_runstate_change(const struct vcpu *v, int new_state)
     event |= ( v->runstate.state & 0x3 ) << 8;
     event |= ( new_state & 0x3 ) << 4;
 
-    __trace_var(event, 1/*tsc*/, sizeof(d), &d);
+    trace_time(event, sizeof(d), &d);
 }
 
 static inline void trace_continue_running(const struct vcpu *v)
 {
-    struct { uint32_t vcpu:16, domain:16; } d;
+    struct { uint16_t vcpu, domain; } d;
 
     if ( likely(!tb_init_done) )
         return;
@@ -231,7 +231,7 @@ static inline void trace_continue_running(const struct vcpu *v)
     d.vcpu = v->vcpu_id;
     d.domain = v->domain->domain_id;
 
-    __trace_var(TRC_SCHED_CONTINUE_RUNNING, 1/*tsc*/, sizeof(d), &d);
+    trace_time(TRC_SCHED_CONTINUE_RUNNING, sizeof(d), &d);
 }
 
 static inline void vcpu_urgent_count_update(struct vcpu *v)
@@ -872,7 +872,7 @@ int sched_init_domain(struct domain *d, unsigned int poolid)
         return ret;
 
     SCHED_STAT_CRANK(dom_init);
-    TRACE_1D(TRC_SCHED_DOM_ADD, d->domain_id);
+    TRACE_TIME(TRC_SCHED_DOM_ADD, d->domain_id);
 
     rcu_read_lock(&sched_res_rculock);
 
@@ -895,7 +895,7 @@ void sched_destroy_domain(struct domain *d)
     if ( d->cpupool )
     {
         SCHED_STAT_CRANK(dom_destroy);
-        TRACE_1D(TRC_SCHED_DOM_REM, d->domain_id);
+        TRACE_TIME(TRC_SCHED_DOM_REM, d->domain_id);
 
         rcu_read_lock(&sched_res_rculock);
 
@@ -936,7 +936,7 @@ void vcpu_sleep_nosync(struct vcpu *v)
     unsigned long flags;
     spinlock_t *lock;
 
-    TRACE_2D(TRC_SCHED_SLEEP, v->domain->domain_id, v->vcpu_id);
+    TRACE_TIME(TRC_SCHED_SLEEP, v->domain->domain_id, v->vcpu_id);
 
     rcu_read_lock(&sched_res_rculock);
 
@@ -965,7 +965,7 @@ void vcpu_wake(struct vcpu *v)
     spinlock_t *lock;
     struct sched_unit *unit = v->sched_unit;
 
-    TRACE_2D(TRC_SCHED_WAKE, v->domain->domain_id, v->vcpu_id);
+    TRACE_TIME(TRC_SCHED_WAKE, v->domain->domain_id, v->vcpu_id);
 
     rcu_read_lock(&sched_res_rculock);
 
@@ -1425,7 +1425,7 @@ void vcpu_block(void)
     }
     else
     {
-        TRACE_2D(TRC_SCHED_BLOCK, v->domain->domain_id, v->vcpu_id);
+        TRACE_TIME(TRC_SCHED_BLOCK, v->domain->domain_id, v->vcpu_id);
         raise_softirq(SCHEDULE_SOFTIRQ);
     }
 }
@@ -1498,7 +1498,7 @@ static long do_poll(const struct sched_poll *sched_poll)
     if ( sched_poll->timeout != 0 )
         set_timer(&v->poll_timer, sched_poll->timeout);
 
-    TRACE_2D(TRC_SCHED_BLOCK, d->domain_id, v->vcpu_id);
+    TRACE_TIME(TRC_SCHED_BLOCK, d->domain_id, v->vcpu_id);
     raise_softirq(SCHEDULE_SOFTIRQ);
 
     return 0;
@@ -1526,7 +1526,7 @@ long vcpu_yield(void)
 
     SCHED_STAT_CRANK(vcpu_yield);
 
-    TRACE_2D(TRC_SCHED_YIELD, current->domain->domain_id, current->vcpu_id);
+    TRACE_TIME(TRC_SCHED_YIELD, current->domain->domain_id, current->vcpu_id);
     raise_softirq(SCHEDULE_SOFTIRQ);
     return 0;
 }
@@ -1904,9 +1904,8 @@ ret_t do_sched_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
         if ( copy_from_guest(&sched_shutdown, arg, 1) )
             break;
 
-        TRACE_3D(TRC_SCHED_SHUTDOWN,
-                 current->domain->domain_id, current->vcpu_id,
-                 sched_shutdown.reason);
+        TRACE_TIME(TRC_SCHED_SHUTDOWN, current->domain->domain_id,
+                   current->vcpu_id, sched_shutdown.reason);
         ret = domain_shutdown(current->domain, (u8)sched_shutdown.reason);
 
         break;
@@ -1921,8 +1920,8 @@ ret_t do_sched_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
         if ( copy_from_guest(&sched_shutdown, arg, 1) )
             break;
 
-        TRACE_3D(TRC_SCHED_SHUTDOWN_CODE,
-                 d->domain_id, current->vcpu_id, sched_shutdown.reason);
+        TRACE_TIME(TRC_SCHED_SHUTDOWN_CODE, d->domain_id, current->vcpu_id,
+                   sched_shutdown.reason);
 
         spin_lock(&d->shutdown_lock);
         if ( d->shutdown_code == SHUTDOWN_CODE_INVALID )
@@ -2085,7 +2084,7 @@ long sched_adjust(struct domain *d, struct xen_domctl_scheduler_op *op)
     rcu_read_lock(&sched_res_rculock);
 
     if ( (ret = sched_adjust_dom(dom_scheduler(d), d, op)) == 0 )
-        TRACE_1D(TRC_SCHED_ADJDOM, d->domain_id);
+        TRACE_TIME(TRC_SCHED_ADJDOM, d->domain_id);
 
     rcu_read_unlock(&sched_res_rculock);
 
@@ -2180,14 +2179,13 @@ static void sched_switch_units(struct sched_resource *sr,
         sr->curr = next;
         sr->prev = prev;
 
-        TRACE_3D(TRC_SCHED_SWITCH_INFPREV, prev->domain->domain_id,
-                 prev->unit_id, now - prev->state_entry_time);
-        TRACE_4D(TRC_SCHED_SWITCH_INFNEXT, next->domain->domain_id,
-                 next->unit_id,
-                 (next->vcpu_list->runstate.state == RUNSTATE_runnable) ?
-                 (now - next->state_entry_time) : 0, prev->next_time);
-        TRACE_4D(TRC_SCHED_SWITCH, prev->domain->domain_id, prev->unit_id,
-                 next->domain->domain_id, next->unit_id);
+        TRACE_TIME(TRC_SCHED_SWITCH_INFPREV, prev->domain->domain_id,
+                   prev->unit_id, now - prev->state_entry_time);
+        TRACE_TIME(TRC_SCHED_SWITCH_INFNEXT, next->domain->domain_id, next->unit_id,
+                   (next->vcpu_list->runstate.state == RUNSTATE_runnable) ?
+                   (now - next->state_entry_time) : 0, prev->next_time);
+        TRACE_TIME(TRC_SCHED_SWITCH, prev->domain->domain_id, prev->unit_id,
+                   next->domain->domain_id, next->unit_id);
 
         ASSERT(!unit_running(next));
 
@@ -2378,10 +2376,10 @@ static void sched_context_switch(struct vcpu *vprev, struct vcpu *vnext,
 {
     if ( unlikely(vprev == vnext) )
     {
-        TRACE_4D(TRC_SCHED_SWITCH_INFCONT,
-                 vnext->domain->domain_id, vnext->sched_unit->unit_id,
-                 now - vprev->runstate.state_entry_time,
-                 vprev->sched_unit->next_time);
+        TRACE_TIME(TRC_SCHED_SWITCH_INFCONT,
+                   vnext->domain->domain_id, vnext->sched_unit->unit_id,
+                   now - vprev->runstate.state_entry_time,
+                   vprev->sched_unit->next_time);
         sched_context_switched(vprev, vnext);
 
         /*
diff --git a/xen/common/sched/credit.c b/xen/common/sched/credit.c
index a72d0715276a..020f44595ed0 100644
--- a/xen/common/sched/credit.c
+++ b/xen/common/sched/credit.c
@@ -493,7 +493,7 @@ static inline void __runq_tickle(const struct csched_unit *new)
         {
             /* Avoid TRACE_*: saves checking !tb_init_done each step */
             for_each_cpu(cpu, &mask)
-                __trace_var(TRC_CSCHED_TICKLE, 1, sizeof(cpu), &cpu);
+                trace_time(TRC_CSCHED_TICKLE, sizeof(cpu), &cpu);
         }
 
         /*
@@ -862,8 +862,7 @@ _csched_cpu_pick(const struct scheduler *ops, const struct sched_unit *unit,
     if ( commit && spc )
        spc->idle_bias = cpu;
 
-    TRACE_3D(TRC_CSCHED_PICKED_CPU, unit->domain->domain_id, unit->unit_id,
-             cpu);
+    TRACE_TIME(TRC_CSCHED_PICKED_CPU, unit->domain->domain_id, unit->unit_id, cpu);
 
     return cpu;
 }
@@ -907,8 +906,8 @@ __csched_unit_acct_start(struct csched_private *prv, struct csched_unit *svc)
         }
     }
 
-    TRACE_3D(TRC_CSCHED_ACCOUNT_START, sdom->dom->domain_id,
-             svc->unit->unit_id, sdom->active_unit_count);
+    TRACE_TIME(TRC_CSCHED_ACCOUNT_START, sdom->dom->domain_id,
+               svc->unit->unit_id, sdom->active_unit_count);
 
     spin_unlock_irqrestore(&prv->lock, flags);
 }
@@ -933,8 +932,8 @@ __csched_unit_acct_stop_locked(struct csched_private *prv,
         list_del_init(&sdom->active_sdom_elem);
     }
 
-    TRACE_3D(TRC_CSCHED_ACCOUNT_STOP, sdom->dom->domain_id,
-             svc->unit->unit_id, sdom->active_unit_count);
+    TRACE_TIME(TRC_CSCHED_ACCOUNT_STOP, sdom->dom->domain_id,
+               svc->unit->unit_id, sdom->active_unit_count);
 }
 
 static void
@@ -957,8 +956,8 @@ csched_unit_acct(struct csched_private *prv, unsigned int cpu)
     if ( svc->pri == CSCHED_PRI_TS_BOOST )
     {
         svc->pri = CSCHED_PRI_TS_UNDER;
-        TRACE_2D(TRC_CSCHED_BOOST_END, svc->sdom->dom->domain_id,
-                 svc->unit->unit_id);
+        TRACE_TIME(TRC_CSCHED_BOOST_END, svc->sdom->dom->domain_id,
+                   svc->unit->unit_id);
     }
 
     /*
@@ -1164,8 +1163,7 @@ csched_unit_wake(const struct scheduler *ops, struct sched_unit *unit)
     if ( !migrating && svc->pri == CSCHED_PRI_TS_UNDER &&
          !test_bit(CSCHED_FLAG_UNIT_PARKED, &svc->flags) )
     {
-        TRACE_2D(TRC_CSCHED_BOOST_START, unit->domain->domain_id,
-                 unit->unit_id);
+        TRACE_TIME(TRC_CSCHED_BOOST_START, unit->domain->domain_id, unit->unit_id);
         SCHED_STAT_CRANK(unit_boost);
         svc->pri = CSCHED_PRI_TS_BOOST;
     }
@@ -1671,8 +1669,8 @@ csched_runq_steal(int peer_cpu, int cpu, int pri, int balance_step)
         if ( __csched_unit_is_migrateable(prv, unit, cpu, cpumask_scratch) )
         {
             /* We got a candidate. Grab it! */
-            TRACE_3D(TRC_CSCHED_STOLEN_UNIT, peer_cpu,
-                     unit->domain->domain_id, unit->unit_id);
+            TRACE_TIME(TRC_CSCHED_STOLEN_UNIT, peer_cpu,
+                       unit->domain->domain_id, unit->unit_id);
             SCHED_UNIT_STAT_CRANK(speer, migrate_q);
             SCHED_STAT_CRANK(migrate_queued);
             runq_remove(speer);
@@ -1783,7 +1781,7 @@ csched_load_balance(struct csched_private *prv, int cpu,
                  */
                 if ( CSCHED_PCPU(peer_cpu)->nr_runnable <= 1 )
                 {
-                    TRACE_2D(TRC_CSCHED_STEAL_CHECK, peer_cpu, /* skipp'n */ 0);
+                    TRACE_TIME(TRC_CSCHED_STEAL_CHECK, peer_cpu, /* skipp'n */ 0);
                     goto next_cpu;
                 }
 
@@ -1799,11 +1797,11 @@ csched_load_balance(struct csched_private *prv, int cpu,
                 if ( !lock )
                 {
                     SCHED_STAT_CRANK(steal_trylock_failed);
-                    TRACE_2D(TRC_CSCHED_STEAL_CHECK, peer_cpu, /* skip */ 0);
+                    TRACE_TIME(TRC_CSCHED_STEAL_CHECK, peer_cpu, /* skip */ 0);
                     goto next_cpu;
                 }
 
-                TRACE_2D(TRC_CSCHED_STEAL_CHECK, peer_cpu, /* checked */ 1);
+                TRACE_TIME(TRC_CSCHED_STEAL_CHECK, peer_cpu, /* checked */ 1);
 
                 /* Any work over there to steal? */
                 speer = cpumask_test_cpu(peer_cpu, online) ?
@@ -1860,21 +1858,18 @@ static void cf_check csched_schedule(
     SCHED_STAT_CRANK(schedule);
     CSCHED_UNIT_CHECK(unit);
 
-    /*
-     * Here in Credit1 code, we usually just call TRACE_nD() helpers, and
-     * don't care about packing. But scheduling happens very often, so it
-     * actually is important that the record is as small as possible.
-     */
     if ( unlikely(tb_init_done) )
     {
         struct {
-            unsigned cpu:16, tasklet:8, idle:8;
-        } d;
-        d.cpu = cur_cpu;
-        d.tasklet = tasklet_work_scheduled;
-        d.idle = is_idle_unit(unit);
-        __trace_var(TRC_CSCHED_SCHEDULE, 1, sizeof(d),
-                    (unsigned char *)&d);
+            uint16_t cpu;
+            uint8_t tasklet, idle;
+        } d = {
+            .cpu     = cur_cpu,
+            .tasklet = tasklet_work_scheduled,
+            .idle    = is_idle_unit(unit),
+        };
+
+        trace_time(TRC_CSCHED_SCHEDULE, sizeof(d), &d);
     }
 
     runtime = now - unit->state_entry_time;
@@ -1936,14 +1931,15 @@ static void cf_check csched_schedule(
         if ( unlikely(tb_init_done) )
         {
             struct {
-                unsigned unit:16, dom:16;
-                unsigned runtime;
-            } d;
-            d.dom = unit->domain->domain_id;
-            d.unit = unit->unit_id;
-            d.runtime = runtime;
-            __trace_var(TRC_CSCHED_RATELIMIT, 1, sizeof(d),
-                        (unsigned char *)&d);
+                uint16_t unit, dom;
+                uint32_t runtime;
+            } d = {
+                .dom     = unit->domain->domain_id,
+                .unit    = unit->unit_id,
+                .runtime = runtime,
+            };
+
+            trace_time(TRC_CSCHED_RATELIMIT, sizeof(d), &d);
         }
 
         goto out;
@@ -1968,7 +1964,7 @@ static void cf_check csched_schedule(
         /* Tasklet work (which runs in idle UNIT context) overrides all else. */
         if ( tasklet_work_scheduled )
         {
-            TRACE_0D(TRC_CSCHED_SCHED_TASKLET);
+            TRACE_TIME(TRC_CSCHED_SCHED_TASKLET);
             snext = CSCHED_UNIT(sched_idle_unit(sched_cpu));
             snext->pri = CSCHED_PRI_TS_BOOST;
         }
diff --git a/xen/common/sched/null.c b/xen/common/sched/null.c
index 2091337fcd06..7e31440e5b84 100644
--- a/xen/common/sched/null.c
+++ b/xen/common/sched/null.c
@@ -331,11 +331,13 @@ pick_res(const struct null_private *prv, const struct sched_unit *unit)
         struct {
             uint16_t unit, dom;
             uint32_t new_cpu;
-        } d;
-        d.dom = unit->domain->domain_id;
-        d.unit = unit->unit_id;
-        d.new_cpu = new_cpu;
-        __trace_var(TRC_SNULL_PICKED_CPU, 1, sizeof(d), &d);
+        } d = {
+            .unit    = unit->unit_id,
+            .dom     = unit->domain->domain_id,
+            .new_cpu = new_cpu,
+        };
+
+        trace_time(TRC_SNULL_PICKED_CPU, sizeof(d), &d);
     }
 
     return get_sched_res(new_cpu);
@@ -359,11 +361,13 @@ static void unit_assign(struct null_private *prv, struct sched_unit *unit,
         struct {
             uint16_t unit, dom;
             uint32_t cpu;
-        } d;
-        d.dom = unit->domain->domain_id;
-        d.unit = unit->unit_id;
-        d.cpu = cpu;
-        __trace_var(TRC_SNULL_UNIT_ASSIGN, 1, sizeof(d), &d);
+        } d = {
+            .unit = unit->unit_id,
+            .dom  = unit->domain->domain_id,
+            .cpu  = cpu,
+        };
+
+        trace_time(TRC_SNULL_UNIT_ASSIGN, sizeof(d), &d);
     }
 }
 
@@ -390,11 +394,13 @@ static bool unit_deassign(struct null_private *prv, const struct sched_unit *uni
         struct {
             uint16_t unit, dom;
             uint32_t cpu;
-        } d;
-        d.dom = unit->domain->domain_id;
-        d.unit = unit->unit_id;
-        d.cpu = cpu;
-        __trace_var(TRC_SNULL_UNIT_DEASSIGN, 1, sizeof(d), &d);
+        } d = {
+            .unit = unit->unit_id,
+            .dom  = unit->domain->domain_id,
+            .cpu  = cpu,
+        };
+
+        trace_time(TRC_SNULL_UNIT_DEASSIGN, sizeof(d), &d);
     }
 
     spin_lock(&prv->waitq_lock);
@@ -695,12 +701,14 @@ static void cf_check null_unit_migrate(
         struct {
             uint16_t unit, dom;
             uint16_t cpu, new_cpu;
-        } d;
-        d.dom = unit->domain->domain_id;
-        d.unit = unit->unit_id;
-        d.cpu = sched_unit_master(unit);
-        d.new_cpu = new_cpu;
-        __trace_var(TRC_SNULL_MIGRATE, 1, sizeof(d), &d);
+        } d = {
+            .unit    = unit->unit_id,
+            .dom     = unit->domain->domain_id,
+            .cpu     = sched_unit_master(unit),
+            .new_cpu = new_cpu,
+        };
+
+        trace_time(TRC_SNULL_MIGRATE, sizeof(d), &d);
     }
 
     /*
@@ -824,9 +832,11 @@ static void cf_check null_schedule(
         struct {
             uint16_t tasklet, cpu;
             int16_t unit, dom;
-        } d;
-        d.cpu = cur_cpu;
-        d.tasklet = tasklet_work_scheduled;
+        } d = {
+            .tasklet = tasklet_work_scheduled,
+            .cpu     = cur_cpu,
+        };
+
         if ( npc->unit == NULL )
         {
             d.unit = d.dom = -1;
@@ -836,12 +846,13 @@ static void cf_check null_schedule(
             d.unit = npc->unit->unit_id;
             d.dom = npc->unit->domain->domain_id;
         }
-        __trace_var(TRC_SNULL_SCHEDULE, 1, sizeof(d), &d);
+
+        trace_time(TRC_SNULL_SCHEDULE, sizeof(d), &d);
     }
 
     if ( tasklet_work_scheduled )
     {
-        trace_var(TRC_SNULL_TASKLET, 1, 0, NULL);
+        TRACE_TIME(TRC_SNULL_TASKLET);
         prev->next_task = sched_idle_unit(sched_cpu);
     }
     else
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 16:36:06 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 16:36:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694895.1084154 (Exim 4.92)
	(envelope-from )
	id 1rmFy2-0006bf-IR; Mon, 18 Mar 2024 16:36:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694895.1084154; Mon, 18 Mar 2024 16:36:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmFy2-0006bW-El; Mon, 18 Mar 2024 16:36:06 +0000
Received: by outflank-mailman (input) for mailman id 694895;
 Mon, 18 Mar 2024 16:36:05 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmFy1-0005JN-Cj
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 16:36:05 +0000
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com
 [2a00:1450:4864:20::52a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9c4651e1-e545-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 17:36:03 +0100 (CET)
Received: by mail-ed1-x52a.google.com with SMTP id
 4fb4d7f45d1cf-5649c25369aso6221037a12.2
 for ; Mon, 18 Mar 2024 09:36:03 -0700 (PDT)
Received: from andrewcoop.citrite.net (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 j22-20020a170906051600b00a441a7a75b5sm4988894eja.209.2024.03.18.09.36.00
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 18 Mar 2024 09:36:00 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9c4651e1-e545-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710779762; x=1711384562; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=+Es/OAet7dNZ7FixRa/pu3b/1ceG+5ckl7uGOXfyyFU=;
        b=cpw6tsuEofu9xDWc6cQD/xmfmw3CK0zDnMp87RnAHbSC7LaYSOAEJrrqS99FCbQoLS
         rOwQDMBGH2HvIeHs8Rz8R7VwDLgXbsPSnmYZ1zqBWhZPDqQalLwMdVJTZEqF7GNK4vkC
         sUY41omIzhSSj/q91PYkqGsORwfWPoKbu1Brc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710779762; x=1711384562;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=+Es/OAet7dNZ7FixRa/pu3b/1ceG+5ckl7uGOXfyyFU=;
        b=A5UghqaPUvaEqYnitYlVU2Y5nCFS97CM8ojlHIBvRMDbJZphiY2x/XoXRGnKW2giRp
         J7wdTw54o2DuHJU1jXypMBfJJKiDodKX8k13rY4tihMwahNTs0oxug8G2cSGEioVae2K
         lchmIF2AhYggesxHLt3XgZN9zxTQxPNnCI9Mvpom7Rw4RvDlYL322SD7IGd9lUBzmDtH
         Wh3lsWtK6bWC6E/TNzz7jyJXzf4DAzczAe1MXU1kR8X+gTphmsCHVWZyiCr3bslsp5nd
         Fb+oihKW+PkQVejkyg1ef/RInTAm+IQ/NeGnbyCgGjG//jJruGvvRGxUZ0FZR2gfHGf4
         cWtg==
X-Gm-Message-State: AOJu0Yzw4X9hisdMiI4fCsDJgv8JwkBymLV9t1XKdh3+GqoN5U9Cwj+m
	FVZuZLd3aCwhQVHVy/b5iuYxgM0qytOEDYOuo0FW+/45YwMyS6bng6Fmj/JE3Dn7iXfMriBdwe1
	x
X-Google-Smtp-Source: AGHT+IGuGed2OIpdg8mf45PQ90xsx+u1p/YYwxpG5q13Of4+Z8/utQniX7dc+gofmdEtnZVi2HXaug==
X-Received: by 2002:a17:906:a18c:b0:a46:a17b:c44e with SMTP id s12-20020a170906a18c00b00a46a17bc44emr4306442ejy.30.1710779762049;
        Mon, 18 Mar 2024 09:36:02 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	George Dunlap ,
	Stefano Stabellini ,
	Julien Grall ,
	Nicola Vetrini ,
	"consulting @ bugseng . com" 
Subject: [PATCH 5/7] xen: Switch to new TRACE() API
Date: Mon, 18 Mar 2024 16:35:50 +0000
Message-Id: <20240318163552.3808695-6-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20240318163552.3808695-1-andrew.cooper3@citrix.com>
References: <20240318163552.3808695-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

(Almost) no functional change.

irq_move_cleanup_interrupt() changes two smp_processor_id() calls to the 'me'
local variable which manifests as a minor code improvement.  All other
differences in the compiled binary are to do with line numbers changing.

Some conversion notes:
 * HVMTRACE_LONG_[234]D() and TRACE_2_LONG_[234]D() were latently buggy.  They
   blindly discard extra parameters, but luckily no users are impacted.  They
   are also obfuscated wrappers, depending on exactly one or two parameters
   being TRC_PAR_LONG() to compile successfully.
 * HVMTRACE_LONG_1D() behaves unlike its named companions, and takes exactly
   one 64bit parameter which it splits manually.  It's one user,
   vmx_cr_access()'s LMSW path, is gets adjusted.
 * TRACE_?D() and TRACE_2_LONG_*() change to TRACE_TIME() as cycles is always
   enabled.
 * HVMTRACE_ND() is opencoded for VMENTRY/VMEXIT records to include cycles.
   These are converted to TRACE_TIME(), with the old modifier parameter
   expressed as an OR at the callsite.  One callsite, svm_vmenter_helper() had
   a nested tb_init_done check, which is dropped.  (The optimiser also spotted
   this, which is why it doesn't manifest as a binary difference.)
 * All uses of *LONG() are either opencoded or swapped to using a struct, to
   avoid MISRA issues.
 * All HVMTRACE_?D() change to TRACE() as cycles is explicitly skipped.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
CC: George Dunlap 
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Nicola Vetrini 
CC: consulting@bugseng.com 

v2.1:
 * New
v3:
 * Remove TRACE_PARAM64() for MISRA reasons.
---
 xen/arch/x86/acpi/cpu_idle.c  | 12 ++++----
 xen/arch/x86/compat.c         |  4 +--
 xen/arch/x86/cpu/mwait-idle.c |  6 ++--
 xen/arch/x86/emul-i8254.c     | 14 ++++-----
 xen/arch/x86/hvm/emulate.c    |  8 +++---
 xen/arch/x86/hvm/hpet.c       |  6 ++--
 xen/arch/x86/hvm/hvm.c        | 16 +++++------
 xen/arch/x86/hvm/rtc.c        | 12 ++++----
 xen/arch/x86/hvm/svm/intr.c   |  6 ++--
 xen/arch/x86/hvm/svm/svm.c    | 40 ++++++++++++--------------
 xen/arch/x86/hvm/vlapic.c     | 51 +++++++++++++++++++++++----------
 xen/arch/x86/hvm/vmx/intr.c   |  6 ++--
 xen/arch/x86/hvm/vmx/vmx.c    | 54 +++++++++++++++++------------------
 xen/arch/x86/hvm/vpic.c       | 13 ++++-----
 xen/arch/x86/irq.c            | 14 ++++-----
 xen/arch/x86/traps.c          |  2 +-
 xen/common/domain.c           |  4 +--
 xen/common/grant_table.c      |  6 ++--
 xen/drivers/cpufreq/utility.c |  2 +-
 19 files changed, 144 insertions(+), 132 deletions(-)

diff --git a/xen/arch/x86/acpi/cpu_idle.c b/xen/arch/x86/acpi/cpu_idle.c
index cfce4cc0408f..30094ff485b4 100644
--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -767,7 +767,7 @@ static void cf_check acpi_processor_idle(void)
             /* Get start time (ticks) */
             t1 = alternative_call(cpuidle_get_tick);
             /* Trace cpu idle entry */
-            TRACE_4D(TRC_PM_IDLE_ENTRY, cx->idx, t1, exp, pred);
+            TRACE_TIME(TRC_PM_IDLE_ENTRY, cx->idx, t1, exp, pred);
 
             update_last_cx_stat(power, cx, t1);
 
@@ -777,8 +777,8 @@ static void cf_check acpi_processor_idle(void)
             t2 = alternative_call(cpuidle_get_tick);
             trace_exit_reason(irq_traced);
             /* Trace cpu idle exit */
-            TRACE_6D(TRC_PM_IDLE_EXIT, cx->idx, t2,
-                     irq_traced[0], irq_traced[1], irq_traced[2], irq_traced[3]);
+            TRACE_TIME(TRC_PM_IDLE_EXIT, cx->idx, t2,
+                       irq_traced[0], irq_traced[1], irq_traced[2], irq_traced[3]);
             /* Update statistics */
             update_idle_stats(power, cx, t1, t2);
             /* Re-enable interrupts */
@@ -798,7 +798,7 @@ static void cf_check acpi_processor_idle(void)
         /* Get start time (ticks) */
         t1 = alternative_call(cpuidle_get_tick);
         /* Trace cpu idle entry */
-        TRACE_4D(TRC_PM_IDLE_ENTRY, cx->idx, t1, exp, pred);
+        TRACE_TIME(TRC_PM_IDLE_ENTRY, cx->idx, t1, exp, pred);
 
         update_last_cx_stat(power, cx, t1);
 
@@ -853,8 +853,8 @@ static void cf_check acpi_processor_idle(void)
         cstate_restore_tsc();
         trace_exit_reason(irq_traced);
         /* Trace cpu idle exit */
-        TRACE_6D(TRC_PM_IDLE_EXIT, cx->idx, t2,
-                 irq_traced[0], irq_traced[1], irq_traced[2], irq_traced[3]);
+        TRACE_TIME(TRC_PM_IDLE_EXIT, cx->idx, t2,
+                   irq_traced[0], irq_traced[1], irq_traced[2], irq_traced[3]);
 
         /* Update statistics */
         update_idle_stats(power, cx, t1, t2);
diff --git a/xen/arch/x86/compat.c b/xen/arch/x86/compat.c
index a03106283028..217b5b1fcc41 100644
--- a/xen/arch/x86/compat.c
+++ b/xen/arch/x86/compat.c
@@ -37,8 +37,8 @@ long do_sched_op_compat(int cmd, unsigned long arg)
         return do_sched_op(cmd, guest_handle_from_ptr(NULL, void));
 
     case SCHEDOP_shutdown:
-        TRACE_3D(TRC_SCHED_SHUTDOWN,
-                 current->domain->domain_id, current->vcpu_id, arg);
+        TRACE_TIME(TRC_SCHED_SHUTDOWN,
+                   current->domain->domain_id, current->vcpu_id, arg);
         domain_shutdown(current->domain, (u8)arg);
         break;
 
diff --git a/xen/arch/x86/cpu/mwait-idle.c b/xen/arch/x86/cpu/mwait-idle.c
index ff5c808bc952..ae6987117169 100644
--- a/xen/arch/x86/cpu/mwait-idle.c
+++ b/xen/arch/x86/cpu/mwait-idle.c
@@ -962,7 +962,7 @@ static void cf_check mwait_idle(void)
 		lapic_timer_off();
 
 	before = alternative_call(cpuidle_get_tick);
-	TRACE_4D(TRC_PM_IDLE_ENTRY, cx->type, before, exp, pred);
+	TRACE_TIME(TRC_PM_IDLE_ENTRY, cx->type, before, exp, pred);
 
 	update_last_cx_stat(power, cx, before);
 
@@ -986,8 +986,8 @@ static void cf_check mwait_idle(void)
 
 	local_irq_enable();
 
-	TRACE_6D(TRC_PM_IDLE_EXIT, cx->type, after,
-		irq_traced[0], irq_traced[1], irq_traced[2], irq_traced[3]);
+	TRACE_TIME(TRC_PM_IDLE_EXIT, cx->type, after,
+		   irq_traced[0], irq_traced[1], irq_traced[2], irq_traced[3]);
 
 	if (!(lapic_timer_reliable_states & (1 << cx->type)))
 		lapic_timer_on();
diff --git a/xen/arch/x86/emul-i8254.c b/xen/arch/x86/emul-i8254.c
index 0191f80ba251..144aa168a3f0 100644
--- a/xen/arch/x86/emul-i8254.c
+++ b/xen/arch/x86/emul-i8254.c
@@ -94,7 +94,7 @@ static void cf_check pit_time_fired(struct vcpu *v, void *priv)
 {
     uint64_t *count_load_time = priv;
 
-    TRACE_0D(TRC_HVM_EMUL_PIT_TIMER_CB);
+    TRACE_TIME(TRC_HVM_EMUL_PIT_TIMER_CB);
     *count_load_time = get_guest_time(v);
 }
 
@@ -128,19 +128,19 @@ static void pit_load_count(PITState *pit, int channel, int val)
     case 2:
     case 3:
         /* Periodic timer. */
-        TRACE_2D(TRC_HVM_EMUL_PIT_START_TIMER, period, period);
+        TRACE_TIME(TRC_HVM_EMUL_PIT_START_TIMER, period, period);
         create_periodic_time(v, &pit->pt0, period, period, 0, pit_time_fired,
                              &pit->count_load_time[channel], false);
         break;
     case 1:
     case 4:
         /* One-shot timer. */
-        TRACE_2D(TRC_HVM_EMUL_PIT_START_TIMER, period, 0);
+        TRACE_TIME(TRC_HVM_EMUL_PIT_START_TIMER, period, 0);
         create_periodic_time(v, &pit->pt0, period, 0, 0, pit_time_fired,
                              &pit->count_load_time[channel], false);
         break;
     default:
-        TRACE_0D(TRC_HVM_EMUL_PIT_STOP_TIMER);
+        TRACE_TIME(TRC_HVM_EMUL_PIT_STOP_TIMER);
         destroy_periodic_time(&pit->pt0);
         break;
     }
@@ -404,7 +404,7 @@ void pit_stop_channel0_irq(PITState *pit)
     if ( !has_vpit(current->domain) )
         return;
 
-    TRACE_0D(TRC_HVM_EMUL_PIT_STOP_TIMER);
+    TRACE_TIME(TRC_HVM_EMUL_PIT_STOP_TIMER);
     spin_lock(&pit->lock);
     destroy_periodic_time(&pit->pt0);
     spin_unlock(&pit->lock);
@@ -615,7 +615,7 @@ void pit_reset(struct domain *d)
 
     if ( is_hvm_domain(d) )
     {
-        TRACE_0D(TRC_HVM_EMUL_PIT_STOP_TIMER);
+        TRACE_TIME(TRC_HVM_EMUL_PIT_STOP_TIMER);
         destroy_periodic_time(&pit->pt0);
         pit->pt0.source = PTSRC_isa;
     }
@@ -660,7 +660,7 @@ void pit_deinit(struct domain *d)
 
     if ( is_hvm_domain(d) )
     {
-        TRACE_0D(TRC_HVM_EMUL_PIT_STOP_TIMER);
+        TRACE_TIME(TRC_HVM_EMUL_PIT_STOP_TIMER);
         destroy_periodic_time(&pit->pt0);
     }
 }
diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index ab1bc516839a..d8f36206a712 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -2181,7 +2181,7 @@ static int cf_check hvmemul_read_cr(
     case 3:
     case 4:
         *val = current->arch.hvm.guest_cr[reg];
-        HVMTRACE_LONG_2D(CR_READ, reg, TRC_PAR_LONG(*val));
+        TRACE(TRC_HVM_CR_READ64, reg, *val, *val >> 32);
         return X86EMUL_OKAY;
     default:
         break;
@@ -2197,7 +2197,7 @@ static int cf_check hvmemul_write_cr(
 {
     int rc;
 
-    HVMTRACE_LONG_2D(CR_WRITE, reg, TRC_PAR_LONG(val));
+    TRACE(TRC_HVM_CR_WRITE64, reg, val, val >> 32);
     switch ( reg )
     {
     case 0:
@@ -2242,7 +2242,7 @@ static int cf_check hvmemul_read_xcr(
     int rc = x86emul_read_xcr(reg, val, ctxt);
 
     if ( rc == X86EMUL_OKAY )
-        HVMTRACE_LONG_2D(XCR_READ, reg, TRC_PAR_LONG(*val));
+        TRACE(TRC_HVM_XCR_READ64, reg, *val, *val >> 32);
 
     return rc;
 }
@@ -2252,7 +2252,7 @@ static int cf_check hvmemul_write_xcr(
     uint64_t val,
     struct x86_emulate_ctxt *ctxt)
 {
-    HVMTRACE_LONG_2D(XCR_WRITE, reg, TRC_PAR_LONG(val));
+    TRACE(TRC_HVM_XCR_WRITE64, reg, val, val >> 32);
 
     return x86emul_write_xcr(reg, val, ctxt);
 }
diff --git a/xen/arch/x86/hvm/hpet.c b/xen/arch/x86/hvm/hpet.c
index 1db9c0b60ee0..0356ade5957b 100644
--- a/xen/arch/x86/hvm/hpet.c
+++ b/xen/arch/x86/hvm/hpet.c
@@ -201,7 +201,7 @@ static void hpet_stop_timer(HPETState *h, unsigned int tn,
 {
     ASSERT(tn < HPET_TIMER_NUM);
     ASSERT(rw_is_write_locked(&h->lock));
-    TRACE_1D(TRC_HVM_EMUL_HPET_STOP_TIMER, tn);
+    TRACE_TIME(TRC_HVM_EMUL_HPET_STOP_TIMER, tn);
     destroy_periodic_time(&h->pt[tn]);
     /* read the comparator to get it updated so a read while stopped will
      * return the expected value. */
@@ -305,8 +305,8 @@ static void hpet_set_timer(HPETState *h, unsigned int tn,
     if ( !oneshot )
         period_ns = hpet_tick_to_ns(h, h->hpet.period[tn]);
 
-    TRACE_2_LONG_4D(TRC_HVM_EMUL_HPET_START_TIMER, tn, irq,
-                    TRC_PAR_LONG(diff_ns), TRC_PAR_LONG(period_ns));
+    TRACE_TIME(TRC_HVM_EMUL_HPET_START_TIMER, tn, irq,
+               diff_ns, diff_ns >> 32, period_ns, period_ns >> 32);
 
     create_periodic_time(vhpet_vcpu(h), &h->pt[tn], diff_ns, period_ns,
                          irq, timer_level(h, tn) ? hpet_timer_fired : NULL,
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index c75959588c0e..e8af42eb499d 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1699,7 +1699,7 @@ void hvm_hlt(unsigned int eflags)
 
     do_sched_op(SCHEDOP_block, guest_handle_from_ptr(NULL, void));
 
-    HVMTRACE_1D(HLT, /* pending = */ vcpu_runnable(curr));
+    TRACE(TRC_HVM_HLT, /* pending = */ vcpu_runnable(curr));
 }
 
 void hvm_triple_fault(void)
@@ -2153,7 +2153,7 @@ int hvm_mov_to_cr(unsigned int cr, unsigned int gpr)
     unsigned long val = *decode_gpr(guest_cpu_user_regs(), gpr);
     int rc;
 
-    HVMTRACE_LONG_2D(CR_WRITE, cr, TRC_PAR_LONG(val));
+    TRACE(TRC_HVM_CR_WRITE64, cr, val, val >> 32);
     HVM_DBG_LOG(DBG_LEVEL_1, "CR%u, value = %lx", cr, val);
 
     switch ( cr )
@@ -2218,7 +2218,7 @@ int hvm_mov_from_cr(unsigned int cr, unsigned int gpr)
     }
 
     *reg = val;
-    HVMTRACE_LONG_2D(CR_READ, cr, TRC_PAR_LONG(val));
+    TRACE(TRC_HVM_CR_READ64, cr, val, val >> 32);
     HVM_DBG_LOG(DBG_LEVEL_VMMU, "CR%u, value = %lx", cr, val);
 
     return X86EMUL_OKAY;
@@ -3508,7 +3508,7 @@ int hvm_vmexit_cpuid(struct cpu_user_regs *regs, unsigned int inst_len)
     }
 
     guest_cpuid(curr, leaf, subleaf, &res);
-    HVMTRACE_6D(CPUID, leaf, subleaf, res.a, res.b, res.c, res.d);
+    TRACE(TRC_HVM_CPUID, leaf, subleaf, res.a, res.b, res.c, res.d);
 
     regs->rax = res.a;
     regs->rbx = res.b;
@@ -3522,7 +3522,7 @@ void hvm_rdtsc_intercept(struct cpu_user_regs *regs)
 {
     msr_split(regs, hvm_get_guest_tsc(current));
 
-    HVMTRACE_2D(RDTSC, regs->eax, regs->edx);
+    TRACE(TRC_HVM_RDTSC, regs->eax, regs->edx);
 }
 
 int hvm_msr_read_intercept(unsigned int msr, uint64_t *msr_content)
@@ -3629,8 +3629,7 @@ int hvm_msr_read_intercept(unsigned int msr, uint64_t *msr_content)
     }
 
  out:
-    HVMTRACE_3D(MSR_READ, msr,
-                (uint32_t)*msr_content, (uint32_t)(*msr_content >> 32));
+    TRACE(TRC_HVM_MSR_READ, msr, *msr_content, *msr_content >> 32);
     return ret;
 
  gp_fault:
@@ -3646,8 +3645,7 @@ int hvm_msr_write_intercept(unsigned int msr, uint64_t msr_content,
     struct domain *d = v->domain;
     int ret;
 
-    HVMTRACE_3D(MSR_WRITE, msr,
-               (uint32_t)msr_content, (uint32_t)(msr_content >> 32));
+    TRACE(TRC_HVM_MSR_WRITE, msr, msr_content, msr_content >> 32);
 
     if ( may_defer && unlikely(monitored_msr(v->domain, msr)) )
     {
diff --git a/xen/arch/x86/hvm/rtc.c b/xen/arch/x86/hvm/rtc.c
index 4b31382619f4..3ad5e4faba76 100644
--- a/xen/arch/x86/hvm/rtc.c
+++ b/xen/arch/x86/hvm/rtc.c
@@ -91,7 +91,7 @@ static void cf_check rtc_pf_callback(struct vcpu *v, void *opaque)
          && ++(s->pt_dead_ticks) >= 10 )
     {
         /* VM is ignoring its RTC; no point in running the timer */
-        TRACE_0D(TRC_HVM_EMUL_RTC_STOP_TIMER);
+        TRACE_TIME(TRC_HVM_EMUL_RTC_STOP_TIMER);
         destroy_periodic_time(&s->pt);
         s->period = 0;
     }
@@ -154,7 +154,7 @@ static void rtc_timer_update(RTCState *s)
                     delta = period - ((now - s->start_time) % period);
                 if ( s->hw.cmos_data[RTC_REG_B] & RTC_PIE )
                 {
-                    TRACE_2D(TRC_HVM_EMUL_RTC_START_TIMER, delta, period);
+                    TRACE_TIME(TRC_HVM_EMUL_RTC_START_TIMER, delta, period);
                     create_periodic_time(v, &s->pt, delta, period,
                                          RTC_IRQ, rtc_pf_callback, s, false);
                 }
@@ -165,7 +165,7 @@ static void rtc_timer_update(RTCState *s)
         }
         /* fall through */
     default:
-        TRACE_0D(TRC_HVM_EMUL_RTC_STOP_TIMER);
+        TRACE_TIME(TRC_HVM_EMUL_RTC_STOP_TIMER);
         destroy_periodic_time(&s->pt);
         s->period = 0;
         break;
@@ -552,7 +552,7 @@ static int rtc_ioport_write(void *opaque, uint32_t addr, uint32_t data)
         rtc_update_irq(s);
         if ( (data ^ orig) & RTC_PIE )
         {
-            TRACE_0D(TRC_HVM_EMUL_RTC_STOP_TIMER);
+            TRACE_TIME(TRC_HVM_EMUL_RTC_STOP_TIMER);
             destroy_periodic_time(&s->pt);
             s->period = 0;
             rtc_timer_update(s);
@@ -806,7 +806,7 @@ void rtc_reset(struct domain *d)
     if ( !has_vrtc(d) )
         return;
 
-    TRACE_0D(TRC_HVM_EMUL_RTC_STOP_TIMER);
+    TRACE_TIME(TRC_HVM_EMUL_RTC_STOP_TIMER);
     destroy_periodic_time(&s->pt);
     s->period = 0;
     s->pt.source = PTSRC_isa;
@@ -891,7 +891,7 @@ void rtc_deinit(struct domain *d)
 
     spin_barrier(&s->lock);
 
-    TRACE_0D(TRC_HVM_EMUL_RTC_STOP_TIMER);
+    TRACE_TIME(TRC_HVM_EMUL_RTC_STOP_TIMER);
     destroy_periodic_time(&s->pt);
     kill_timer(&s->update_timer);
     kill_timer(&s->update_timer2);
diff --git a/xen/arch/x86/hvm/svm/intr.c b/xen/arch/x86/hvm/svm/intr.c
index 4805c5567213..dc684fdc843e 100644
--- a/xen/arch/x86/hvm/svm/intr.c
+++ b/xen/arch/x86/hvm/svm/intr.c
@@ -90,8 +90,8 @@ static void svm_enable_intr_window(struct vcpu *v, struct hvm_intack intack)
         }
     }
 
-    HVMTRACE_3D(INTR_WINDOW, intack.vector, intack.source,
-                vmcb->event_inj.v ? vmcb->event_inj.vector : -1);
+    TRACE(TRC_HVM_INTR_WINDOW, intack.vector, intack.source,
+          vmcb->event_inj.v ? vmcb->event_inj.vector : -1);
 
     /*
      * Create a dummy virtual interrupt to intercept as soon as the
@@ -206,7 +206,7 @@ void asmlinkage svm_intr_assist(void)
     }
     else
     {
-        HVMTRACE_2D(INJ_VIRQ, intack.vector, /*fake=*/ 0);
+        TRACE(TRC_HVM_INJ_VIRQ, intack.vector, /*fake=*/ 0);
         svm_inject_extint(v, intack.vector);
         pt_intr_post(v, intack);
     }
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index b1ab0b568b85..09a79d761163 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1066,10 +1066,8 @@ void asmlinkage svm_vmenter_helper(void)
 
     svm_asid_handle_vmrun();
 
-    if ( unlikely(tb_init_done) )
-        HVMTRACE_ND(VMENTRY,
-                    nestedhvm_vcpu_in_guestmode(curr) ? TRC_HVM_NESTEDFLAG : 0,
-                    1/*cycles*/);
+    TRACE_TIME(TRC_HVM_VMENTRY |
+               (nestedhvm_vcpu_in_guestmode(curr) ? TRC_HVM_NESTEDFLAG : 0));
 
     svm_sync_vmcb(curr, vmcb_needs_vmsave);
 
@@ -1441,10 +1439,10 @@ static void cf_check svm_inject_event(const struct x86_event *event)
 
     if ( _event.vector == X86_EXC_PF &&
          _event.type == X86_EVENTTYPE_HW_EXCEPTION )
-        HVMTRACE_LONG_2D(PF_INJECT, _event.error_code,
-                         TRC_PAR_LONG(_event.cr2));
+        TRACE(TRC_HVM_PF_INJECT64, _event.error_code,
+              _event.cr2, _event.cr2 >> 32);
     else
-        HVMTRACE_2D(INJ_EXC, _event.vector, _event.error_code);
+        TRACE(TRC_HVM_INJ_EXC, _event.vector, _event.error_code);
 }
 
 static bool cf_check svm_event_pending(const struct vcpu *v)
@@ -1751,7 +1749,7 @@ static void svm_dr_access(struct vcpu *v, struct cpu_user_regs *regs)
 {
     struct vmcb_struct *vmcb = vcpu_nestedhvm(v).nv_n1vmcx;
 
-    HVMTRACE_0D(DR_WRITE);
+    TRACE(TRC_HVM_DR_WRITE);
     __restore_debug_registers(vmcb, v);
 }
 
@@ -2402,7 +2400,7 @@ static void svm_invlpga_intercept(
 
 static void svm_invlpg_intercept(unsigned long linear)
 {
-    HVMTRACE_LONG_2D(INVLPG, 0, TRC_PAR_LONG(linear));
+    TRACE(TRC_HVM_INVLPG64, 0, linear, linear >> 32);
     paging_invlpg(current, linear);
 }
 
@@ -2629,11 +2627,11 @@ void asmlinkage svm_vmexit_handler(void)
     exit_reason = vmcb->exitcode;
 
     if ( hvm_long_mode_active(v) )
-        HVMTRACE_ND(VMEXIT64, vcpu_guestmode ? TRC_HVM_NESTEDFLAG : 0,
-                    1/*cycles*/, exit_reason, TRC_PAR_LONG(regs->rip));
+        TRACE_TIME(TRC_HVM_VMEXIT64 | (vcpu_guestmode ? TRC_HVM_NESTEDFLAG : 0),
+                   exit_reason, regs->rip, regs->rip >> 32);
     else
-        HVMTRACE_ND(VMEXIT, vcpu_guestmode ? TRC_HVM_NESTEDFLAG : 0,
-                    1/*cycles*/, exit_reason, regs->eip);
+        TRACE_TIME(TRC_HVM_VMEXIT | (vcpu_guestmode ? TRC_HVM_NESTEDFLAG : 0),
+                   exit_reason, regs->eip);
 
     if ( vcpu_guestmode )
     {
@@ -2728,17 +2726,17 @@ void asmlinkage svm_vmexit_handler(void)
     {
     case VMEXIT_INTR:
         /* Asynchronous event, handled when we STGI'd after the VMEXIT. */
-        HVMTRACE_0D(INTR);
+        TRACE(TRC_HVM_INTR);
         break;
 
     case VMEXIT_NMI:
         /* Asynchronous event, handled when we STGI'd after the VMEXIT. */
-        HVMTRACE_0D(NMI);
+        TRACE(TRC_HVM_NMI);
         break;
 
     case VMEXIT_SMI:
         /* Asynchronous event, handled when we STGI'd after the VMEXIT. */
-        HVMTRACE_0D(SMI);
+        TRACE(TRC_HVM_SMI);
         break;
 
     case VMEXIT_ICEBP:
@@ -2826,9 +2824,9 @@ void asmlinkage svm_vmexit_handler(void)
             if ( trace_will_trace_event(TRC_SHADOW) )
                 break;
             if ( hvm_long_mode_active(v) )
-                HVMTRACE_LONG_2D(PF_XEN, regs->error_code, TRC_PAR_LONG(va));
+                TRACE(TRC_HVM_PF_XEN64, regs->error_code, va, va >> 32);
             else
-                HVMTRACE_2D(PF_XEN, regs->error_code, va);
+                TRACE(TRC_HVM_PF_XEN, regs->error_code, va);
             break;
         }
 
@@ -2837,7 +2835,7 @@ void asmlinkage svm_vmexit_handler(void)
     }
 
     case VMEXIT_EXCEPTION_AC:
-        HVMTRACE_1D(TRAP, X86_EXC_AC);
+        TRACE(TRC_HVM_TRAP, X86_EXC_AC);
         hvm_inject_hw_exception(X86_EXC_AC, vmcb->ei.exc.ec);
         break;
 
@@ -2847,7 +2845,7 @@ void asmlinkage svm_vmexit_handler(void)
 
     /* Asynchronous event, handled when we STGI'd after the VMEXIT. */
     case VMEXIT_EXCEPTION_MC:
-        HVMTRACE_0D(MCE);
+        TRACE(TRC_HVM_MCE);
         svm_vmexit_mce_intercept(v, regs);
         break;
 
@@ -2993,7 +2991,7 @@ void asmlinkage svm_vmexit_handler(void)
         if ( (insn_len = svm_get_insn_len(v, INSTR_VMCALL)) == 0 )
             break;
         BUG_ON(vcpu_guestmode);
-        HVMTRACE_1D(VMMCALL, regs->eax);
+        TRACE(TRC_HVM_VMMCALL, regs->eax);
 
         if ( hvm_hypercall(regs) == HVM_HCALL_completed )
             __update_guest_eip(regs, insn_len);
diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
index dcbcf4a1feb5..65e171d4751f 100644
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -682,7 +682,7 @@ int guest_rdmsr_x2apic(const struct vcpu *v, uint32_t msr, uint64_t *val)
 
 static void cf_check vlapic_pt_cb(struct vcpu *v, void *data)
 {
-    TRACE_0D(TRC_HVM_EMUL_LAPIC_TIMER_CB);
+    TRACE_TIME(TRC_HVM_EMUL_LAPIC_TIMER_CB);
     *(s_time_t *)data = hvm_get_guest_time(v);
 }
 
@@ -736,9 +736,19 @@ static void vlapic_update_timer(struct vlapic *vlapic, uint32_t lvtt,
             delta = delta * vlapic->hw.timer_divisor / old_divisor;
         }
 
-        TRACE_2_LONG_3D(TRC_HVM_EMUL_LAPIC_START_TIMER, TRC_PAR_LONG(delta),
-                        TRC_PAR_LONG(is_periodic ? period : 0),
-                        vlapic->pt.irq);
+        if ( unlikely(tb_init_done) )
+        {
+            struct {
+                uint64_t delta, period;
+                uint32_t irq;
+            } __packed d = {
+                .delta = delta,
+                .period = is_periodic ? period : 0,
+                .irq = vlapic->pt.irq,
+            };
+
+            trace_time(TRC_HVM_EMUL_LAPIC_START_TIMER, sizeof(d), &d);
+        }
 
         create_periodic_time(current, &vlapic->pt, delta,
                              is_periodic ? period : 0, vlapic->pt.irq,
@@ -758,7 +768,7 @@ static void vlapic_update_timer(struct vlapic *vlapic, uint32_t lvtt,
     }
     else
     {
-        TRACE_0D(TRC_HVM_EMUL_LAPIC_STOP_TIMER);
+        TRACE_TIME(TRC_HVM_EMUL_LAPIC_STOP_TIMER);
         destroy_periodic_time(&vlapic->pt);
         /*
          * From now, TMCCT should return 0 until TMICT is set again.
@@ -1208,8 +1218,8 @@ void vlapic_tdt_msr_set(struct vlapic *vlapic, uint64_t value)
 
         vlapic->hw.tdt_msr = value;
         /* .... reprogram tdt timer */
-        TRACE_2_LONG_3D(TRC_HVM_EMUL_LAPIC_START_TIMER, TRC_PAR_LONG(delta),
-                        TRC_PAR_LONG(0LL), vlapic->pt.irq);
+        TRACE_TIME(TRC_HVM_EMUL_LAPIC_START_TIMER, delta, delta >> 32,
+                   0, 0, vlapic->pt.irq);
         create_periodic_time(v, &vlapic->pt, delta, 0,
                              vlapic->pt.irq, vlapic_tdt_pt_cb,
                              &vlapic->timer_last_update, false);
@@ -1222,8 +1232,8 @@ void vlapic_tdt_msr_set(struct vlapic *vlapic, uint64_t value)
         /* trigger a timer event if needed */
         if ( value > 0 )
         {
-            TRACE_2_LONG_3D(TRC_HVM_EMUL_LAPIC_START_TIMER, TRC_PAR_LONG(0LL),
-                            TRC_PAR_LONG(0LL), vlapic->pt.irq);
+            TRACE_TIME(TRC_HVM_EMUL_LAPIC_START_TIMER, 0, 0,
+                       0, 0, vlapic->pt.irq);
             create_periodic_time(v, &vlapic->pt, 0, 0,
                                  vlapic->pt.irq, vlapic_tdt_pt_cb,
                                  &vlapic->timer_last_update, false);
@@ -1232,7 +1242,7 @@ void vlapic_tdt_msr_set(struct vlapic *vlapic, uint64_t value)
         else
         {
             /* .... stop tdt timer */
-            TRACE_0D(TRC_HVM_EMUL_LAPIC_STOP_TIMER);
+            TRACE_TIME(TRC_HVM_EMUL_LAPIC_STOP_TIMER);
             destroy_periodic_time(&vlapic->pt);
         }
 
@@ -1282,7 +1292,7 @@ int vlapic_accept_pic_intr(struct vcpu *v)
     if ( target )
         accept = __vlapic_accept_pic_intr(v);
 
-    TRACE_2D(TRC_HVM_EMUL_LAPIC_PIC_INTR, target, accept);
+    TRACE_TIME(TRC_HVM_EMUL_LAPIC_PIC_INTR, target, accept);
 
     return target && accept;
 }
@@ -1433,7 +1443,7 @@ static void vlapic_do_init(struct vlapic *vlapic)
     vlapic_set_reg(vlapic, APIC_SPIV, 0xff);
     vlapic->hw.disabled |= VLAPIC_SW_DISABLED;
 
-    TRACE_0D(TRC_HVM_EMUL_LAPIC_STOP_TIMER);
+    TRACE_TIME(TRC_HVM_EMUL_LAPIC_STOP_TIMER);
     destroy_periodic_time(&vlapic->pt);
 }
 
@@ -1476,8 +1486,19 @@ static void lapic_rearm(struct vlapic *s)
               (uint32_t)tmict * s->hw.timer_divisor);
     is_periodic = vlapic_lvtt_period(s);
 
-    TRACE_2_LONG_3D(TRC_HVM_EMUL_LAPIC_START_TIMER, TRC_PAR_LONG(period),
-             TRC_PAR_LONG(is_periodic ? period : 0LL), s->pt.irq);
+    if ( unlikely(tb_init_done) )
+    {
+         struct {
+             uint64_t delta, period;
+             uint32_t irq;
+        } __packed d = {
+             .delta = period,
+             .period = is_periodic ? period : 0,
+             .irq = s->pt.irq,
+        };
+
+        trace_time(TRC_HVM_EMUL_LAPIC_START_TIMER, sizeof(d), &d);
+    }
 
     create_periodic_time(vlapic_vcpu(s), &s->pt, period,
                          is_periodic ? period : 0,
@@ -1669,7 +1690,7 @@ void vlapic_destroy(struct vcpu *v)
         return;
 
     tasklet_kill(&vlapic->init_sipi.tasklet);
-    TRACE_0D(TRC_HVM_EMUL_LAPIC_STOP_TIMER);
+    TRACE_TIME(TRC_HVM_EMUL_LAPIC_STOP_TIMER);
     destroy_periodic_time(&vlapic->pt);
     unmap_domain_page_global(vlapic->regs);
     free_domheap_page(vlapic->regs_page);
diff --git a/xen/arch/x86/hvm/vmx/intr.c b/xen/arch/x86/hvm/vmx/intr.c
index 8beeaab1517b..d36498d83104 100644
--- a/xen/arch/x86/hvm/vmx/intr.c
+++ b/xen/arch/x86/hvm/vmx/intr.c
@@ -67,8 +67,8 @@ static void vmx_enable_intr_window(struct vcpu *v, struct hvm_intack intack)
         unsigned long intr;
 
         __vmread(VM_ENTRY_INTR_INFO, &intr);
-        HVMTRACE_3D(INTR_WINDOW, intack.vector, intack.source,
-                    (intr & INTR_INFO_VALID_MASK) ? intr & 0xff : -1);
+        TRACE(TRC_HVM_INTR_WINDOW, intack.vector, intack.source,
+              (intr & INTR_INFO_VALID_MASK) ? intr & 0xff : -1);
     }
 
     if ( (intack.source == hvm_intsrc_nmi) && cpu_has_vmx_vnmi )
@@ -390,7 +390,7 @@ void asmlinkage vmx_intr_assist(void)
     }
     else
     {
-        HVMTRACE_2D(INJ_VIRQ, intack.vector, /*fake=*/ 0);
+        TRACE(TRC_HVM_INJ_VIRQ, intack.vector, /*fake=*/ 0);
         vmx_inject_extint(intack.vector, intack.source);
         pt_intr_post(v, intack);
     }
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 23bdf0d1957f..ac73f58798ed 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2090,10 +2090,10 @@ static void cf_check vmx_inject_event(const struct x86_event *event)
 
     if ( (_event.vector == X86_EXC_PF) &&
          (_event.type == X86_EVENTTYPE_HW_EXCEPTION) )
-        HVMTRACE_LONG_2D(PF_INJECT, _event.error_code,
-                         TRC_PAR_LONG(curr->arch.hvm.guest_cr[2]));
+        TRACE(TRC_HVM_PF_INJECT64, _event.error_code,
+              curr->arch.hvm.guest_cr[2], curr->arch.hvm.guest_cr[2] >> 32);
     else
-        HVMTRACE_2D(INJ_EXC, _event.vector, _event.error_code);
+        TRACE(TRC_HVM_INJ_EXC, _event.vector, _event.error_code);
 }
 
 static bool cf_check vmx_event_pending(const struct vcpu *v)
@@ -3085,7 +3085,7 @@ static void vmx_dr_access(unsigned long exit_qualification,
 {
     struct vcpu *v = current;
 
-    HVMTRACE_0D(DR_WRITE);
+    TRACE(TRC_HVM_DR_WRITE);
 
     if ( !v->arch.hvm.flag_dr_dirty )
         __restore_debug_registers(v);
@@ -3097,7 +3097,7 @@ static void vmx_dr_access(unsigned long exit_qualification,
 
 static void vmx_invlpg_intercept(unsigned long linear)
 {
-    HVMTRACE_LONG_2D(INVLPG, /*invlpga=*/ 0, TRC_PAR_LONG(linear));
+    TRACE(TRC_HVM_INVLPG64, /*invlpga=*/ 0, linear, linear >> 32);
     paging_invlpg(current, linear);
 }
 
@@ -3145,7 +3145,7 @@ static int vmx_cr_access(cr_access_qual_t qual)
         hvm_monitor_crX(CR0, value, old);
         curr->arch.hvm.guest_cr[0] = value;
         vmx_update_guest_cr(curr, 0, 0);
-        HVMTRACE_0D(CLTS);
+        TRACE(TRC_HVM_CLTS);
         break;
     }
 
@@ -3158,7 +3158,7 @@ static int vmx_cr_access(cr_access_qual_t qual)
         value = (value & ~(X86_CR0_MP|X86_CR0_EM|X86_CR0_TS)) |
                 (qual.lmsw_data &
                  (X86_CR0_PE|X86_CR0_MP|X86_CR0_EM|X86_CR0_TS));
-        HVMTRACE_LONG_1D(LMSW, value);
+        TRACE(TRC_HVM_LMSW64, value, value >> 32);
 
         if ( (rc = hvm_set_cr0(value, true)) == X86EMUL_EXCEPTION )
             hvm_inject_hw_exception(X86_EXC_GP, 0);
@@ -3711,7 +3711,7 @@ static void vmx_do_extint(struct cpu_user_regs *regs)
     BUG_ON(!(vector & INTR_INFO_VALID_MASK));
 
     vector &= INTR_INFO_VECTOR_MASK;
-    HVMTRACE_1D(INTR, vector);
+    TRACE(TRC_HVM_INTR, vector);
 
     regs->entry_vector = vector;
     do_IRQ(regs);
@@ -3851,7 +3851,7 @@ static void vmx_failed_vmentry(unsigned int exit_reason,
 
     case EXIT_REASON_MCE_DURING_VMENTRY:
         printk("MCE\n");
-        HVMTRACE_0D(MCE);
+        TRACE(TRC_HVM_MCE);
         /* Already handled. */
         break;
 
@@ -3892,7 +3892,7 @@ static int vmx_handle_eoi_write(void)
     {
         update_guest_eip(); /* Safe: APIC data write */
         vlapic_EOI_set(vcpu_vlapic(current));
-        HVMTRACE_0D(VLAPIC);
+        TRACE(TRC_HVM_VLAPIC);
         return 1;
     }
 
@@ -4062,10 +4062,9 @@ void asmlinkage vmx_vmexit_handler(struct cpu_user_regs *regs)
     __vmread(VM_EXIT_REASON, &exit_reason);
 
     if ( hvm_long_mode_active(v) )
-        HVMTRACE_ND(VMEXIT64, 0, 1/*cycles*/, exit_reason,
-                    TRC_PAR_LONG(regs->rip));
+        TRACE_TIME(TRC_HVM_VMEXIT64, exit_reason, regs->rip, regs->rip >> 32);
     else
-        HVMTRACE_ND(VMEXIT, 0, 1/*cycles*/, exit_reason, regs->eip);
+        TRACE_TIME(TRC_HVM_VMEXIT, exit_reason, regs->eip);
 
     perfc_incra(vmexits, (uint16_t)exit_reason);
 
@@ -4182,7 +4181,7 @@ void asmlinkage vmx_vmexit_handler(struct cpu_user_regs *regs)
         default:
                 perfc_incr(realmode_exits);
                 v->arch.hvm.vmx.vmx_emulate = 1;
-                HVMTRACE_0D(REALMODE_EMULATE);
+                TRACE(TRC_HVM_REALMODE_EMULATE);
                 return;
             }
         case EXIT_REASON_EXTERNAL_INTERRUPT:
@@ -4239,7 +4238,7 @@ void asmlinkage vmx_vmexit_handler(struct cpu_user_regs *regs)
              * Table 23-1, "Exit Qualification for Debug Exceptions").
              */
             __vmread(EXIT_QUALIFICATION, &exit_qualification);
-            HVMTRACE_1D(TRAP_DEBUG, exit_qualification);
+            TRACE(TRC_HVM_TRAP_DEBUG, exit_qualification);
             __restore_debug_registers(v);
             write_debugreg(6, exit_qualification | DR_STATUS_RESERVED_ONE);
 
@@ -4301,7 +4300,7 @@ void asmlinkage vmx_vmexit_handler(struct cpu_user_regs *regs)
                 domain_pause_for_debugger();
             break;
         case X86_EXC_BP:
-            HVMTRACE_1D(TRAP, vector);
+            TRACE(TRC_HVM_TRAP, vector);
             if ( !v->domain->debugger_attached )
             {
                 unsigned long insn_len;
@@ -4326,7 +4325,7 @@ void asmlinkage vmx_vmexit_handler(struct cpu_user_regs *regs)
             }
             break;
         case X86_EXC_NM:
-            HVMTRACE_1D(TRAP, vector);
+            TRACE(TRC_HVM_TRAP, vector);
             vmx_fpu_dirty_intercept();
             break;
         case X86_EXC_PF:
@@ -4344,37 +4343,36 @@ void asmlinkage vmx_vmexit_handler(struct cpu_user_regs *regs)
                 if ( trace_will_trace_event(TRC_SHADOW) )
                     break;
                 if ( hvm_long_mode_active(v) )
-                    HVMTRACE_LONG_2D(PF_XEN, regs->error_code,
-                                     TRC_PAR_LONG(exit_qualification) );
+                    TRACE(TRC_HVM_PF_XEN64, regs->error_code,
+                          exit_qualification, exit_qualification >> 32);
                 else
-                    HVMTRACE_2D(PF_XEN,
-                                regs->error_code, exit_qualification );
+                    TRACE(TRC_HVM_PF_XEN, regs->error_code, exit_qualification);
                 break;
             }
 
             hvm_inject_page_fault(regs->error_code, exit_qualification);
             break;
         case X86_EXC_AC:
-            HVMTRACE_1D(TRAP, vector);
+            TRACE(TRC_HVM_TRAP, vector);
             vmx_propagate_intr(intr_info);
             break;
         case X86_EXC_NMI:
             if ( MASK_EXTR(intr_info, INTR_INFO_INTR_TYPE_MASK) !=
                  X86_EVENTTYPE_NMI )
                 goto exit_and_crash;
-            HVMTRACE_0D(NMI);
+            TRACE(TRC_HVM_NMI);
             /* Already handled above. */
             break;
         case X86_EXC_MC:
-            HVMTRACE_0D(MCE);
+            TRACE(TRC_HVM_MCE);
             /* Already handled above. */
             break;
         case X86_EXC_UD:
-            HVMTRACE_1D(TRAP, vector);
+            TRACE(TRC_HVM_TRAP, vector);
             hvm_ud_intercept(regs);
             break;
         default:
-            HVMTRACE_1D(TRAP, vector);
+            TRACE(TRC_HVM_TRAP, vector);
             goto exit_and_crash;
         }
         break;
@@ -4460,7 +4458,7 @@ void asmlinkage vmx_vmexit_handler(struct cpu_user_regs *regs)
         break;
 
     case EXIT_REASON_VMCALL:
-        HVMTRACE_1D(VMMCALL, regs->eax);
+        TRACE(TRC_HVM_VMMCALL, regs->eax);
 
         if ( hvm_hypercall(regs) == HVM_HCALL_completed )
             update_guest_eip(); /* Safe: VMCALL */
@@ -4868,7 +4866,7 @@ bool asmlinkage vmx_vmenter_helper(const struct cpu_user_regs *regs)
     if ( unlikely(curr->arch.hvm.vmx.lbr_flags & LBR_FIXUP_MASK) )
         lbr_fixup();
 
-    HVMTRACE_ND(VMENTRY, 0, 1/*cycles*/);
+    TRACE_TIME(TRC_HVM_VMENTRY);
 
     __vmwrite(GUEST_RIP,    regs->rip);
     __vmwrite(GUEST_RSP,    regs->rsp);
diff --git a/xen/arch/x86/hvm/vpic.c b/xen/arch/x86/hvm/vpic.c
index 4e23247a464a..7c3b5c7254a8 100644
--- a/xen/arch/x86/hvm/vpic.c
+++ b/xen/arch/x86/hvm/vpic.c
@@ -99,8 +99,7 @@ static void vpic_update_int_output(struct hvm_hw_vpic *vpic)
     ASSERT(vpic_is_locked(vpic));
 
     irq = vpic_get_highest_priority_irq(vpic);
-    TRACE_3D(TRC_HVM_EMUL_PIC_INT_OUTPUT, vpic->int_output, vpic->is_master,
-             irq);
+    TRACE_TIME(TRC_HVM_EMUL_PIC_INT_OUTPUT, vpic->int_output, vpic->is_master, irq);
     if ( vpic->int_output == (!vpic->init_state && irq >= 0) )
         return;
 
@@ -119,7 +118,7 @@ static void vpic_update_int_output(struct hvm_hw_vpic *vpic)
 
             if ( v != NULL )
             {
-                TRACE_1D(TRC_HVM_EMUL_PIC_KICK, irq);
+                TRACE_TIME(TRC_HVM_EMUL_PIC_KICK, irq);
                 vcpu_kick(v);
             }
         }
@@ -144,7 +143,7 @@ static void __vpic_intack(struct hvm_hw_vpic *vpic, int irq)
 
     ASSERT(vpic_is_locked(vpic));
 
-    TRACE_2D(TRC_HVM_EMUL_PIC_INTACK, vpic->is_master, irq);
+    TRACE_TIME(TRC_HVM_EMUL_PIC_INTACK, vpic->is_master, irq);
     /* Edge-triggered: clear the IRR (forget the edge). */
     if ( !(vpic->elcr & mask) )
         vpic->irr &= ~mask;
@@ -526,7 +525,7 @@ void vpic_irq_positive_edge(struct domain *d, int irq)
     ASSERT(irq <= 15);
     ASSERT(vpic_is_locked(vpic));
 
-    TRACE_1D(TRC_HVM_EMUL_PIC_POSEDGE, irq);
+    TRACE_TIME(TRC_HVM_EMUL_PIC_POSEDGE, irq);
     if ( irq == 2 )
         return;
 
@@ -544,7 +543,7 @@ void vpic_irq_negative_edge(struct domain *d, int irq)
     ASSERT(irq <= 15);
     ASSERT(vpic_is_locked(vpic));
 
-    TRACE_1D(TRC_HVM_EMUL_PIC_NEGEDGE, irq);
+    TRACE_TIME(TRC_HVM_EMUL_PIC_NEGEDGE, irq);
     if ( irq == 2 )
         return;
 
@@ -562,7 +561,7 @@ int vpic_ack_pending_irq(struct vcpu *v)
 
     accept = vlapic_accept_pic_intr(v);
 
-    TRACE_2D(TRC_HVM_EMUL_PIC_PEND_IRQ_CALL, accept, vpic->int_output);
+    TRACE_TIME(TRC_HVM_EMUL_PIC_PEND_IRQ_CALL, accept, vpic->int_output);
     if ( !accept || !vpic->int_output )
         return -1;
 
diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c
index 0487f734a5d2..2c1f858d3e64 100644
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -229,7 +229,7 @@ static void _clear_irq_vector(struct irq_desc *desc)
         for_each_cpu(cpu, tmp_mask)
         {
             ASSERT(per_cpu(vector_irq, cpu)[old_vector] == irq);
-            TRACE_3D(TRC_HW_IRQ_MOVE_FINISH, irq, old_vector, cpu);
+            TRACE_TIME(TRC_HW_IRQ_MOVE_FINISH, irq, old_vector, cpu);
             per_cpu(vector_irq, cpu)[old_vector] = ~irq;
         }
 
@@ -796,13 +796,11 @@ void cf_check irq_move_cleanup_interrupt(void)
                 goto unlock;
             }
             send_IPI_self(IRQ_MOVE_CLEANUP_VECTOR);
-            TRACE_3D(TRC_HW_IRQ_MOVE_CLEANUP_DELAY,
-                     irq, vector, smp_processor_id());
+            TRACE_TIME(TRC_HW_IRQ_MOVE_CLEANUP_DELAY, irq, vector, me);
             goto unlock;
         }
 
-        TRACE_3D(TRC_HW_IRQ_MOVE_CLEANUP,
-                 irq, vector, smp_processor_id());
+        TRACE_TIME(TRC_HW_IRQ_MOVE_CLEANUP, irq, vector, me);
 
         per_cpu(vector_irq, me)[vector] = ~irq;
         desc->arch.move_cleanup_count--;
@@ -1943,7 +1941,7 @@ void do_IRQ(struct cpu_user_regs *regs)
                     spin_unlock(&desc->lock);
                 }
             }
-            TRACE_1D(TRC_HW_IRQ_UNMAPPED_VECTOR, vector);
+            TRACE_TIME(TRC_HW_IRQ_UNMAPPED_VECTOR, vector);
         }
         goto out_no_unlock;
     }
@@ -1984,7 +1982,7 @@ void do_IRQ(struct cpu_user_regs *regs)
 
         tsc_in = tb_init_done ? get_cycles() : 0;
         do_IRQ_guest(desc, vector);
-        TRACE_3D(TRC_HW_IRQ_HANDLED, irq, tsc_in, get_cycles());
+        TRACE_TIME(TRC_HW_IRQ_HANDLED, irq, tsc_in, get_cycles());
         goto out_no_end;
     }
 
@@ -2008,7 +2006,7 @@ void do_IRQ(struct cpu_user_regs *regs)
 
         tsc_in = tb_init_done ? get_cycles() : 0;
         action->handler(irq, action->dev_id);
-        TRACE_3D(TRC_HW_IRQ_HANDLED, irq, tsc_in, get_cycles());
+        TRACE_TIME(TRC_HW_IRQ_HANDLED, irq, tsc_in, get_cycles());
 
         spin_lock_irq(&desc->lock);
     }
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index d554c9d41edd..468a03608102 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1899,7 +1899,7 @@ void asmlinkage do_device_not_available(struct cpu_user_regs *regs)
         curr->arch.pv.ctrlreg[0] &= ~X86_CR0_TS;
     }
     else
-        TRACE_0D(TRC_PV_MATH_STATE_RESTORE);
+        TRACE_TIME(TRC_PV_MATH_STATE_RESTORE);
 #else
     ASSERT_UNREACHABLE();
 #endif
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 1f0d23a1e09b..fe8a216d29b6 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -625,7 +625,7 @@ struct domain *domain_create(domid_t domid,
         hardware_domain = d;
     }
 
-    TRACE_1D(TRC_DOM0_DOM_ADD, d->domain_id);
+    TRACE_TIME(TRC_DOM0_DOM_ADD, d->domain_id);
 
     lock_profile_register_struct(LOCKPROF_TYPE_PERDOM, d, domid);
 
@@ -1222,7 +1222,7 @@ void domain_destroy(struct domain *d)
     if ( atomic_cmpxchg(&d->refcnt, 0, DOMAIN_DESTROYED) != 0 )
         return;
 
-    TRACE_1D(TRC_DOM0_DOM_REM, d->domain_id);
+    TRACE_TIME(TRC_DOM0_DOM_REM, d->domain_id);
 
     /* Delete from task list and task hashtable. */
     spin_lock(&domlist_update_lock);
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 77089308829b..8d34c8815f05 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -1307,7 +1307,7 @@ map_grant_ref(
             goto undo_out;
     }
 
-    TRACE_1D(TRC_MEM_PAGE_GRANT_MAP, op->dom);
+    TRACE_TIME(TRC_MEM_PAGE_GRANT_MAP, op->dom);
 
     /*
      * All maptrack entry users check mt->flags first before using the
@@ -1434,7 +1434,7 @@ unmap_common(
         return;
     }
 
-    TRACE_1D(TRC_MEM_PAGE_GRANT_UNMAP, dom);
+    TRACE_TIME(TRC_MEM_PAGE_GRANT_UNMAP, dom);
 
     rgt = rd->grant_table;
 
@@ -2445,7 +2445,7 @@ gnttab_transfer(
         put_gfn(d, gop.mfn);
 #endif
 
-        TRACE_1D(TRC_MEM_PAGE_GRANT_TRANSFER, e->domain_id);
+        TRACE_TIME(TRC_MEM_PAGE_GRANT_TRANSFER, e->domain_id);
 
         /* Tell the guest about its new page frame. */
         grant_read_lock(e->grant_table);
diff --git a/xen/drivers/cpufreq/utility.c b/xen/drivers/cpufreq/utility.c
index dbf8985969b2..ede22650a387 100644
--- a/xen/drivers/cpufreq/utility.c
+++ b/xen/drivers/cpufreq/utility.c
@@ -368,7 +368,7 @@ int __cpufreq_driver_target(struct cpufreq_policy *policy,
         retval = alternative_call(cpufreq_driver.target,
                                   policy, target_freq, relation);
         if ( retval == 0 )
-            TRACE_2D(TRC_PM_FREQ_CHANGE, prev_freq/1000, policy->cur/1000);
+            TRACE_TIME(TRC_PM_FREQ_CHANGE, prev_freq / 1000, policy->cur / 1000);
     }
 
     return retval;
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 16:36:07 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 16:36:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694896.1084161 (Exim 4.92)
	(envelope-from )
	id 1rmFy3-0006iC-6S; Mon, 18 Mar 2024 16:36:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694896.1084161; Mon, 18 Mar 2024 16:36:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmFy2-0006h4-Vg; Mon, 18 Mar 2024 16:36:06 +0000
Received: by outflank-mailman (input) for mailman id 694896;
 Mon, 18 Mar 2024 16:36:06 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmFy2-0005JN-D3
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 16:36:06 +0000
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com
 [2a00:1450:4864:20::632])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9ccc7f93-e545-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 17:36:04 +0100 (CET)
Received: by mail-ej1-x632.google.com with SMTP id
 a640c23a62f3a-a4675aaa2e8so530463766b.0
 for ; Mon, 18 Mar 2024 09:36:04 -0700 (PDT)
Received: from andrewcoop.citrite.net (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 j22-20020a170906051600b00a441a7a75b5sm4988894eja.209.2024.03.18.09.36.02
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 18 Mar 2024 09:36:02 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9ccc7f93-e545-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710779763; x=1711384563; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=8vrAhsgU6cX18okKuYBRpNmDoptjsZfxbtY0fNi0S6I=;
        b=YJE3oceJHQ3uKQr8hNkLSsp9XV7vs6q0l+zUv5atmkaQD6LWrlbbkbzsUW2+nIfvjj
         ZgcAdL3rOCbuIPBDvT9u2DsTcKFTh79Cnzg2PE27ybun/R5OSK14SCUjDwbBHLZTD5J0
         DFhT0YcGwh86QrNf+vvgcqNM9QxFW1mUZ5SYA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710779763; x=1711384563;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=8vrAhsgU6cX18okKuYBRpNmDoptjsZfxbtY0fNi0S6I=;
        b=YB6us06KbyjAz3gC3aHbiaOexuypMrDAKzqlkRwe9MOqwLHah5kySWAbpkkJMzh09G
         hNpLpGDTxfOUCEdX/8YXVRGgpor7wAokTvz3+JdH/HsA/L51s5hHcn9HhmVtwQkRsGVU
         iA+09iU24em6CjEgE6FT8WkLLSAT0PGQoN2Z32IpuVg2bFz0WHrSkbVeWpqUquX/PDeB
         bvGWu/99cwIYajWmKIP/FtMJu/o17U6lSq/qjNVmeDisgfM+sdj3tpPgqhaFLAY6wA8f
         CEggbO/faMGWXTKtNol7W3w2S353x7ZyKH+zI9rgY1017tPWq7aex3cGSwvwmbUx9+9k
         lvlw==
X-Gm-Message-State: AOJu0YzC3sEH+DWvDKhRq7UtG0b4gPf1zdSF5cP62c04b9AfrY+z8L1H
	zoYHraJn9cG3fMZqBNwzJ6Vsd86XG4ki72Dg/hRiCE+4gSbc1BfhoeJtjs8FFE/MZyhLwE/tk8o
	R
X-Google-Smtp-Source: AGHT+IEnk6AfX4SLXJGON1k0UkIeAvbg61kD28TZM+u99GXJOtoZvunt1o7QU0IrhGe8s4ngEuX9Tw==
X-Received: by 2002:a17:906:6947:b0:a46:1e16:317c with SMTP id c7-20020a170906694700b00a461e16317cmr7955308ejs.55.1710779762757;
        Mon, 18 Mar 2024 09:36:02 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	George Dunlap ,
	Stefano Stabellini ,
	Julien Grall ,
	Nicola Vetrini ,
	"consulting @ bugseng . com" 
Subject: [PATCH 6/7] xen/trace: Update final {__,}trace_var() users to the new API
Date: Mon, 18 Mar 2024 16:35:51 +0000
Message-Id: <20240318163552.3808695-7-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20240318163552.3808695-1-andrew.cooper3@citrix.com>
References: <20240318163552.3808695-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This logically drops the cycles parameter, as it's now encoded directly in the
event code.

No functional change.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
CC: George Dunlap 
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Nicola Vetrini 
CC: consulting@bugseng.com 

v3:
 * New
---
 xen/arch/x86/hvm/emulate.c      |  2 +-
 xen/arch/x86/hvm/hvm.c          |  3 +--
 xen/arch/x86/hvm/svm/svm.c      |  2 +-
 xen/arch/x86/hvm/vmx/vmx.c      |  2 +-
 xen/arch/x86/irq.c              |  2 +-
 xen/arch/x86/mm/p2m-pod.c       |  8 ++++----
 xen/arch/x86/mm/p2m-pt.c        |  2 +-
 xen/arch/x86/mm/shadow/common.c |  6 +++---
 xen/arch/x86/mm/shadow/multi.c  | 10 +++++-----
 xen/arch/x86/pv/trace.c         | 21 +++++++++++----------
 xen/common/memory.c             |  2 +-
 xen/common/trace.c              |  2 +-
 12 files changed, 31 insertions(+), 31 deletions(-)

diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index d8f36206a712..a37525316c6e 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -67,7 +67,7 @@ static void hvmtrace_io_assist(const ioreq_t *p)
         size *= 2;
     }
 
-    trace_var(event, 0/*!cycles*/, size, buffer);
+    trace(event, size, buffer);
 }
 
 static int cf_check null_read(
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index e8af42eb499d..bb4eda4ecde2 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -5136,8 +5136,7 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
             return -EINVAL;
 
         /* Cycles will be taken at the vmexit and vmenter */
-        trace_var(tr.event | TRC_GUEST, 0 /*!cycles*/,
-                  tr.extra_bytes, tr.extra);
+        trace(tr.event | TRC_GUEST, tr.extra_bytes, tr.extra);
         break;
     }
 
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 09a79d761163..2d0c8762359f 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1681,7 +1681,7 @@ static void svm_do_nested_pgfault(struct vcpu *v,
         _d.mfn = mfn_x(mfn);
         _d.p2mt = p2mt;
 
-        __trace_var(TRC_HVM_NPF, 0, sizeof(_d), &_d);
+        trace(TRC_HVM_NPF, sizeof(_d), &_d);
     }
 
     switch ( ret )
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index ac73f58798ed..255c97f18162 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -3767,7 +3767,7 @@ static void ept_handle_violation(ept_qual_t q, paddr_t gpa)
         _d.qualification = q.raw;
         _d.mfn = mfn_x(get_gfn_query_unlocked(d, gfn, &_d.p2mt));
 
-        __trace_var(TRC_HVM_NPF, 0, sizeof(_d), &_d);
+        trace(TRC_HVM_NPF, sizeof(_d), &_d);
     }
 
     if ( q.gla_valid )
diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c
index 2c1f858d3e64..45a74c6a0256 100644
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -135,7 +135,7 @@ static void _trace_irq_mask(uint32_t event, int irq, int vector,
 
     memcpy(d.mask, mask,
            min(sizeof(d.mask), BITS_TO_LONGS(nr_cpu_ids) * sizeof(long)));
-    trace_var(event, 1, sizeof(d), &d);
+    trace_time(event, sizeof(d), &d);
 }
 
 static void trace_irq_mask(uint32_t event, int irq, int vector,
diff --git a/xen/arch/x86/mm/p2m-pod.c b/xen/arch/x86/mm/p2m-pod.c
index 65d31e552305..79a016682f1d 100644
--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -854,7 +854,7 @@ p2m_pod_zero_check_superpage(struct p2m_domain *p2m, gfn_t gfn)
         t.d = d->domain_id;
         t.order = 9;
 
-        __trace_var(TRC_MEM_POD_ZERO_RECLAIM, 0, sizeof(t), &t);
+        trace(TRC_MEM_POD_ZERO_RECLAIM, sizeof(t), &t);
     }
 
     /*
@@ -1022,7 +1022,7 @@ p2m_pod_zero_check(struct p2m_domain *p2m, const gfn_t *gfns, unsigned int count
                 t.d = d->domain_id;
                 t.order = 0;
 
-                __trace_var(TRC_MEM_POD_ZERO_RECLAIM, 0, sizeof(t), &t);
+                trace(TRC_MEM_POD_ZERO_RECLAIM, sizeof(t), &t);
             }
 
             /* Add to cache, and account for the new p2m PoD entry */
@@ -1262,7 +1262,7 @@ p2m_pod_demand_populate(struct p2m_domain *p2m, gfn_t gfn,
         t.d = d->domain_id;
         t.order = order;
 
-        __trace_var(TRC_MEM_POD_POPULATE, 0, sizeof(t), &t);
+        trace(TRC_MEM_POD_POPULATE, sizeof(t), &t);
     }
 
     pod_unlock_and_flush(p2m);
@@ -1307,7 +1307,7 @@ p2m_pod_demand_populate(struct p2m_domain *p2m, gfn_t gfn,
         t.d = d->domain_id;
         t.order = order;
 
-        __trace_var(TRC_MEM_POD_SUPERPAGE_SPLINTER, 0, sizeof(t), &t);
+        trace(TRC_MEM_POD_SUPERPAGE_SPLINTER, sizeof(t), &t);
     }
 
     return true;
diff --git a/xen/arch/x86/mm/p2m-pt.c b/xen/arch/x86/mm/p2m-pt.c
index 348130d0dd3b..666abd46be16 100644
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -608,7 +608,7 @@ p2m_pt_set_entry(struct p2m_domain *p2m, gfn_t gfn_, mfn_t mfn,
         t.d = d->domain_id;
         t.order = page_order;
 
-        __trace_var(TRC_MEM_SET_P2M_ENTRY, 0, sizeof(t), &t);
+        trace(TRC_MEM_SET_P2M_ENTRY, sizeof(t), &t);
     }
 
     /* Carry out any eventually pending earlier changes first. */
diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c
index 8aa7b698f879..1303aec85918 100644
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -433,7 +433,7 @@ static inline void trace_resync(int event, mfn_t gmfn)
         /* Convert gmfn to gfn */
         gfn_t gfn = mfn_to_gfn(current->domain, gmfn);
 
-        __trace_var(event, 0/*!tsc*/, sizeof(gfn), &gfn);
+        trace(event, sizeof(gfn), &gfn);
     }
 }
 
@@ -910,7 +910,7 @@ static inline void trace_shadow_prealloc_unpin(struct domain *d, mfn_t smfn)
 
         ASSERT(mfn_valid(smfn));
         gfn = mfn_to_gfn(d, backpointer(mfn_to_page(smfn)));
-        __trace_var(TRC_SHADOW_PREALLOC_UNPIN, 0/*!tsc*/, sizeof(gfn), &gfn);
+        trace(TRC_SHADOW_PREALLOC_UNPIN, sizeof(gfn), &gfn);
     }
 }
 
@@ -1808,7 +1808,7 @@ static inline void trace_shadow_wrmap_bf(mfn_t gmfn)
         /* Convert gmfn to gfn */
         gfn_t gfn = mfn_to_gfn(current->domain, gmfn);
 
-        __trace_var(TRC_SHADOW_WRMAP_BF, 0/*!tsc*/, sizeof(gfn), &gfn);
+        trace(TRC_SHADOW_WRMAP_BF, sizeof(gfn), &gfn);
     }
 }
 
diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index 90cf0ceaa367..bcd02b2d0037 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -1979,7 +1979,7 @@ static inline void trace_shadow_gen(u32 event, guest_va_t va)
     if ( tb_init_done )
     {
         event |= (GUEST_PAGING_LEVELS-2)<<8;
-        __trace_var(event, 0/*!tsc*/, sizeof(va), &va);
+        trace(event, sizeof(va), &va);
     }
 }
 
@@ -2003,7 +2003,7 @@ static inline void trace_shadow_fixup(guest_l1e_t gl1e,
         d.va = va;
         d.flags = this_cpu(trace_shadow_path_flags);
 
-        __trace_var(event, 0/*!tsc*/, sizeof(d), &d);
+        trace(event, sizeof(d), &d);
     }
 }
 
@@ -2027,7 +2027,7 @@ static inline void trace_not_shadow_fault(guest_l1e_t gl1e,
         d.va = va;
         d.flags = this_cpu(trace_shadow_path_flags);
 
-        __trace_var(event, 0/*!tsc*/, sizeof(d), &d);
+        trace(event, sizeof(d), &d);
     }
 }
 
@@ -2053,7 +2053,7 @@ static inline void trace_shadow_emulate_other(u32 event,
         d.gfn=gfn_x(gfn);
         d.va = va;
 
-        __trace_var(event, 0/*!tsc*/, sizeof(d), &d);
+        trace(event, sizeof(d), &d);
     }
 }
 
@@ -2106,7 +2106,7 @@ static inline void trace_shadow_emulate(guest_l1e_t gl1e, unsigned long va)
 #endif
         d.flags = this_cpu(trace_shadow_path_flags);
 
-        __trace_var(event, 0/*!tsc*/, sizeof(d), &d);
+        trace(event, sizeof(d), &d);
     }
 }
 #endif /* CONFIG_HVM */
diff --git a/xen/arch/x86/pv/trace.c b/xen/arch/x86/pv/trace.c
index cf3897061e1f..70f426f2095c 100644
--- a/xen/arch/x86/pv/trace.c
+++ b/xen/arch/x86/pv/trace.c
@@ -19,7 +19,7 @@ void __trace_pv_trap(int trapnr, unsigned long eip,
             .error_code     = error_code,
         };
 
-        __trace_var(TRC_PV_TRAP, 1, sizeof(d), &d);
+        trace_time(TRC_PV_TRAP, sizeof(d), &d);
     }
     else
     {
@@ -35,7 +35,7 @@ void __trace_pv_trap(int trapnr, unsigned long eip,
             .error_code     = error_code,
         };
 
-        __trace_var(TRC_PV_TRAP | TRC_64_FLAG, 1, sizeof(d), &d);
+        trace_time(TRC_PV_TRAP | TRC_64_FLAG, sizeof(d), &d);
     }
 }
 
@@ -53,7 +53,7 @@ void __trace_pv_page_fault(unsigned long addr, unsigned error_code)
             .error_code = error_code,
         };
 
-        __trace_var(TRC_PV_PAGE_FAULT, 1, sizeof(d), &d);
+        trace_time(TRC_PV_PAGE_FAULT, sizeof(d), &d);
     }
     else
     {
@@ -66,7 +66,7 @@ void __trace_pv_page_fault(unsigned long addr, unsigned error_code)
             .error_code = error_code,
         };
 
-        __trace_var(TRC_PV_PAGE_FAULT | TRC_64_FLAG, 1, sizeof(d), &d);
+        trace_time(TRC_PV_PAGE_FAULT | TRC_64_FLAG, sizeof(d), &d);
     }
 }
 
@@ -75,10 +75,11 @@ void __trace_trap_one_addr(unsigned event, unsigned long va)
     if ( is_pv_32bit_vcpu(current) )
     {
         u32 d = va;
-        __trace_var(event, 1, sizeof(d), &d);
+
+        trace_time(event, sizeof(d), &d);
     }
     else
-        __trace_var(event | TRC_64_FLAG, 1, sizeof(va), &va);
+        trace_time(event | TRC_64_FLAG, sizeof(va), &va);
 }
 
 void __trace_trap_two_addr(unsigned event, unsigned long va1,
@@ -93,7 +94,7 @@ void __trace_trap_two_addr(unsigned event, unsigned long va1,
             .va2 = va2,
         };
 
-        __trace_var(event, 1, sizeof(d), &d);
+        trace_time(event, sizeof(d), &d);
     }
     else
     {
@@ -104,7 +105,7 @@ void __trace_trap_two_addr(unsigned event, unsigned long va1,
             .va2 = va2,
         };
 
-        __trace_var(event | TRC_64_FLAG, 1, sizeof(d), &d);
+        trace_time(event | TRC_64_FLAG, sizeof(d), &d);
     }
 }
 
@@ -123,7 +124,7 @@ void __trace_ptwr_emulation(unsigned long addr, l1_pgentry_t npte)
             .eip  = eip,
         };
 
-        __trace_var(TRC_PV_PTWR_EMULATION_PAE, 1, sizeof(d), &d);
+        trace_time(TRC_PV_PTWR_EMULATION_PAE, sizeof(d), &d);
     }
     else
     {
@@ -136,6 +137,6 @@ void __trace_ptwr_emulation(unsigned long addr, l1_pgentry_t npte)
             .rip  = eip,
         };
 
-        __trace_var(TRC_PV_PTWR_EMULATION | TRC_64_FLAG, 1, sizeof(d), &d);
+        trace_time(TRC_PV_PTWR_EMULATION | TRC_64_FLAG, sizeof(d), &d);
     }
 }
diff --git a/xen/common/memory.c b/xen/common/memory.c
index b3b05c2ec090..3cecfdee9518 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -483,7 +483,7 @@ static void decrease_reservation(struct memop_args *a)
             t.d = a->domain->domain_id;
             t.order = a->extent_order;
         
-            __trace_var(TRC_MEM_DECREASE_RESERVATION, 0, sizeof(t), &t);
+            trace(TRC_MEM_DECREASE_RESERVATION, sizeof(t), &t);
         }
 
         /* See if populate-on-demand wants to handle this */
diff --git a/xen/common/trace.c b/xen/common/trace.c
index c94ce1f7dc90..27c8a19f0549 100644
--- a/xen/common/trace.c
+++ b/xen/common/trace.c
@@ -868,7 +868,7 @@ void __trace_hypercall(uint32_t event, unsigned long op,
         break;
     }
 
-    __trace_var(event, 1, sizeof(uint32_t) * (1 + (a - d.args)), &d);
+    trace_time(event, sizeof(uint32_t) * (1 + (a - d.args)), &d);
 }
 
 /*
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 16:36:08 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 16:36:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694897.1084173 (Exim 4.92)
	(envelope-from )
	id 1rmFy4-000764-Ht; Mon, 18 Mar 2024 16:36:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694897.1084173; Mon, 18 Mar 2024 16:36:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmFy4-00074q-Be; Mon, 18 Mar 2024 16:36:08 +0000
Received: by outflank-mailman (input) for mailman id 694897;
 Mon, 18 Mar 2024 16:36:07 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmFy3-0005JN-DY
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 16:36:07 +0000
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com
 [2a00:1450:4864:20::630])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9d9b2ef8-e545-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 17:36:05 +0100 (CET)
Received: by mail-ej1-x630.google.com with SMTP id
 a640c23a62f3a-a46cd9e7fcaso106121166b.1
 for ; Mon, 18 Mar 2024 09:36:05 -0700 (PDT)
Received: from andrewcoop.citrite.net (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 j22-20020a170906051600b00a441a7a75b5sm4988894eja.209.2024.03.18.09.36.02
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 18 Mar 2024 09:36:03 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9d9b2ef8-e545-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710779764; x=1711384564; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=PINeZIOEWeXs0aAyqXBWjda/ShH0F0UcrolT6+Sh/5w=;
        b=dEZS4AgTv8Z87yqX0To8RcxHntjxQEEMNGoDtmQN3WeHqQ/RNiDotfPwYL8EbHk74M
         OaTsjTQLuaHgZ+QDZVW8VvbcGb2f5gLSZ6GnQ1tIXyuFvmbMrDMoUgFXwr6mSZg4+urC
         Ntqoh+fcUqJaoC3HrrDVcDffzoMPdGP5la0oo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710779764; x=1711384564;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=PINeZIOEWeXs0aAyqXBWjda/ShH0F0UcrolT6+Sh/5w=;
        b=sUDC6paG924YFMEaF/Rnke/4VFb2HBfjL0prwp5rtmEDRTFAHKmgeQBJgnEvBUSvD4
         ccQiJdyh7G1cPXHFJZ492RpSe576lQ/PgBxRKTmViOqI38TyNejoFwe1JZvi/nqt4f4g
         6zjhaMQ+awqbSUVVmbrQStG7X6QHnAl7BbB6QCZEpk4CfGO5YPfMXV2opq8r84nkf2dM
         BHi8xluUU7TfNo0KY19BJdDZSkOgER19Mx2MZ6SP9fsqg0Vh86iy/x/nnFNwsaq+xzKY
         5ZahwT8ix/VgUI9YeR8KUmKeO9if082tRRvi2N0Py92P0eiPThl8AUsBqkD90XvEQ8Kr
         X7Vg==
X-Gm-Message-State: AOJu0YzwuZ0jtuyjPc+tNzOBANun7cUDGEbSyNNWlH/tev+6spLkaTPc
	W0GB7Z+ozdqoHgpshi+OpMNEzOjbCY1zZeyZUlRJQowE7c7YCpPEC3VaZ48wRpn8vUsluDzL/V6
	c
X-Google-Smtp-Source: AGHT+IGP+9zN7xY7mThQWojYYbsKhTiU1tp+r4cl/2ev977sOFuznyozo9OoqQrM7KtJyUqm8N1VNw==
X-Received: by 2002:a17:906:6a16:b0:a46:954a:aa14 with SMTP id qw22-20020a1709066a1600b00a46954aaa14mr6404141ejc.67.1710779764631;
        Mon, 18 Mar 2024 09:36:04 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	George Dunlap ,
	Stefano Stabellini ,
	Julien Grall ,
	Nicola Vetrini ,
	"consulting @ bugseng . com" 
Subject: [PATCH 7/7] xen/trace: Drop old trace API
Date: Mon, 18 Mar 2024 16:35:52 +0000
Message-Id: <20240318163552.3808695-8-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20240318163552.3808695-1-andrew.cooper3@citrix.com>
References: <20240318163552.3808695-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

With all users updated to the new API, drop the old API.  This includes all of
asm/hvm/trace.h, which allows us to drop some includes.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
CC: George Dunlap 
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Nicola Vetrini 
CC: consulting@bugseng.com 

v2.1:
 * New
v3:
 * Extend to drop __trace_var() too
---
 xen/arch/x86/hvm/emulate.c             |   1 -
 xen/arch/x86/hvm/hpet.c                |   1 -
 xen/arch/x86/hvm/hvm.c                 |   1 -
 xen/arch/x86/hvm/io.c                  |   1 -
 xen/arch/x86/hvm/svm/intr.c            |   1 -
 xen/arch/x86/hvm/svm/svm.c             |   1 -
 xen/arch/x86/hvm/vlapic.c              |   1 -
 xen/arch/x86/hvm/vmx/intr.c            |   1 -
 xen/arch/x86/hvm/vmx/vmx.c             |   1 -
 xen/arch/x86/include/asm/hvm/trace.h   | 114 -------------------------
 xen/arch/x86/include/asm/hvm/vmx/vmx.h |   1 -
 xen/common/trace.c                     |  12 +--
 xen/include/xen/trace.h                |  47 ----------
 13 files changed, 3 insertions(+), 180 deletions(-)
 delete mode 100644 xen/arch/x86/include/asm/hvm/trace.h

diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index a37525316c6e..02e378365b40 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -22,7 +22,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/x86/hvm/hpet.c b/xen/arch/x86/hvm/hpet.c
index 0356ade5957b..dd85e46d4001 100644
--- a/xen/arch/x86/hvm/hpet.c
+++ b/xen/arch/x86/hvm/hpet.c
@@ -8,7 +8,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index bb4eda4ecde2..cedaf428b400 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -51,7 +51,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/x86/hvm/io.c b/xen/arch/x86/hvm/io.c
index 06283b41c463..db726b38177b 100644
--- a/xen/arch/x86/hvm/io.c
+++ b/xen/arch/x86/hvm/io.c
@@ -28,7 +28,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/x86/hvm/svm/intr.c b/xen/arch/x86/hvm/svm/intr.c
index dc684fdc843e..780c7e178a52 100644
--- a/xen/arch/x86/hvm/svm/intr.c
+++ b/xen/arch/x86/hvm/svm/intr.c
@@ -24,7 +24,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include "nestedhvm.h"
 
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 2d0c8762359f..c94b83dc22f7 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -28,7 +28,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
index 65e171d4751f..7a971470537e 100644
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -27,7 +27,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/x86/hvm/vmx/intr.c b/xen/arch/x86/hvm/vmx/intr.c
index d36498d83104..1a4dfb499bcd 100644
--- a/xen/arch/x86/hvm/vmx/intr.c
+++ b/xen/arch/x86/hvm/vmx/intr.c
@@ -24,7 +24,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 /*
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 255c97f18162..3fbbd44a6b45 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -37,7 +37,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/x86/include/asm/hvm/trace.h b/xen/arch/x86/include/asm/hvm/trace.h
deleted file mode 100644
index 22eadbdd4720..000000000000
--- a/xen/arch/x86/include/asm/hvm/trace.h
+++ /dev/null
@@ -1,114 +0,0 @@
-#ifndef __ASM_X86_HVM_TRACE_H__
-#define __ASM_X86_HVM_TRACE_H__
-
-#include 
-
-#define DEFAULT_HVM_TRACE_ON  1
-#define DEFAULT_HVM_TRACE_OFF 0
-
-#define DEFAULT_HVM_VMSWITCH   DEFAULT_HVM_TRACE_ON
-#define DEFAULT_HVM_PF         DEFAULT_HVM_TRACE_ON
-#define DEFAULT_HVM_INJECT     DEFAULT_HVM_TRACE_ON
-#define DEFAULT_HVM_IO         DEFAULT_HVM_TRACE_ON
-#define DEFAULT_HVM_REGACCESS  DEFAULT_HVM_TRACE_ON
-#define DEFAULT_HVM_MISC       DEFAULT_HVM_TRACE_ON
-#define DEFAULT_HVM_INTR       DEFAULT_HVM_TRACE_ON
-
-#define DO_TRC_HVM_VMENTRY     DEFAULT_HVM_VMSWITCH
-#define DO_TRC_HVM_VMEXIT      DEFAULT_HVM_VMSWITCH
-#define DO_TRC_HVM_VMEXIT64    DEFAULT_HVM_VMSWITCH
-#define DO_TRC_HVM_PF_XEN      DEFAULT_HVM_PF
-#define DO_TRC_HVM_PF_XEN64    DEFAULT_HVM_PF
-#define DO_TRC_HVM_PF_INJECT   DEFAULT_HVM_PF
-#define DO_TRC_HVM_PF_INJECT64 DEFAULT_HVM_PF
-#define DO_TRC_HVM_INJ_EXC     DEFAULT_HVM_INJECT
-#define DO_TRC_HVM_INJ_VIRQ    DEFAULT_HVM_INJECT
-#define DO_TRC_HVM_REINJ_VIRQ  DEFAULT_HVM_INJECT
-#define DO_TRC_HVM_INTR_WINDOW DEFAULT_HVM_INJECT
-#define DO_TRC_HVM_IO_READ     DEFAULT_HVM_IO
-#define DO_TRC_HVM_IO_WRITE    DEFAULT_HVM_IO
-#define DO_TRC_HVM_CR_READ     DEFAULT_HVM_REGACCESS
-#define DO_TRC_HVM_CR_READ64   DEFAULT_HVM_REGACCESS
-#define DO_TRC_HVM_CR_WRITE    DEFAULT_HVM_REGACCESS
-#define DO_TRC_HVM_CR_WRITE64  DEFAULT_HVM_REGACCESS
-#define DO_TRC_HVM_DR_READ     DEFAULT_HVM_REGACCESS
-#define DO_TRC_HVM_DR_WRITE    DEFAULT_HVM_REGACCESS
-#define DO_TRC_HVM_XCR_READ64  DEFAULT_HVM_REGACCESS
-#define DO_TRC_HVM_XCR_WRITE64 DEFAULT_HVM_REGACCESS
-#define DO_TRC_HVM_MSR_READ    DEFAULT_HVM_REGACCESS
-#define DO_TRC_HVM_MSR_WRITE   DEFAULT_HVM_REGACCESS
-#define DO_TRC_HVM_RDTSC       DEFAULT_HVM_REGACCESS
-#define DO_TRC_HVM_CPUID       DEFAULT_HVM_MISC
-#define DO_TRC_HVM_INTR        DEFAULT_HVM_INTR
-#define DO_TRC_HVM_NMI         DEFAULT_HVM_INTR
-#define DO_TRC_HVM_MCE         DEFAULT_HVM_INTR
-#define DO_TRC_HVM_SMI         DEFAULT_HVM_INTR
-#define DO_TRC_HVM_VMMCALL     DEFAULT_HVM_MISC
-#define DO_TRC_HVM_HLT         DEFAULT_HVM_MISC
-#define DO_TRC_HVM_INVLPG      DEFAULT_HVM_MISC
-#define DO_TRC_HVM_INVLPG64    DEFAULT_HVM_MISC
-#define DO_TRC_HVM_IO_ASSIST   DEFAULT_HVM_MISC
-#define DO_TRC_HVM_MMIO_ASSIST DEFAULT_HVM_MISC
-#define DO_TRC_HVM_CLTS        DEFAULT_HVM_MISC
-#define DO_TRC_HVM_LMSW        DEFAULT_HVM_MISC
-#define DO_TRC_HVM_LMSW64      DEFAULT_HVM_MISC
-#define DO_TRC_HVM_REALMODE_EMULATE DEFAULT_HVM_MISC
-#define DO_TRC_HVM_TRAP             DEFAULT_HVM_MISC
-#define DO_TRC_HVM_TRAP_DEBUG       DEFAULT_HVM_MISC
-#define DO_TRC_HVM_VLAPIC           DEFAULT_HVM_MISC
-
-
-#define TRC_PAR_LONG(par) ((uint32_t)(par)), ((par) >> 32)
-
-#define TRACE_2_LONG_2D(_e, d1, d2, ...) \
-    TRACE_4D(_e, d1, d2)
-#define TRACE_2_LONG_3D(_e, d1, d2, d3, ...) \
-    TRACE_5D(_e, d1, d2, d3)
-#define TRACE_2_LONG_4D(_e, d1, d2, d3, d4, ...) \
-    TRACE_6D(_e, d1, d2, d3, d4)
-
-#define HVMTRACE_ND(evt, modifier, cycles, ...)                           \
-    do {                                                                  \
-        if ( unlikely(tb_init_done) && DO_TRC_HVM_ ## evt )               \
-        {                                                                 \
-            uint32_t _d[] = { __VA_ARGS__ };                              \
-            __trace_var(TRC_HVM_ ## evt | (modifier), cycles,             \
-                        sizeof(_d), sizeof(_d) ? _d : NULL);              \
-        }                                                                 \
-    } while(0)
-
-#define HVMTRACE_6D(evt, d1, d2, d3, d4, d5, d6)    \
-    HVMTRACE_ND(evt, 0, 0, d1, d2, d3, d4, d5, d6)
-#define HVMTRACE_5D(evt, d1, d2, d3, d4, d5)        \
-    HVMTRACE_ND(evt, 0, 0, d1, d2, d3, d4, d5)
-#define HVMTRACE_4D(evt, d1, d2, d3, d4)            \
-    HVMTRACE_ND(evt, 0, 0, d1, d2, d3, d4)
-#define HVMTRACE_3D(evt, d1, d2, d3)                \
-    HVMTRACE_ND(evt, 0, 0, d1, d2, d3)
-#define HVMTRACE_2D(evt, d1, d2)                    \
-    HVMTRACE_ND(evt, 0, 0, d1, d2)
-#define HVMTRACE_1D(evt, d1)                        \
-    HVMTRACE_ND(evt, 0, 0, d1)
-#define HVMTRACE_0D(evt)                            \
-    HVMTRACE_ND(evt, 0, 0)
-
-#define HVMTRACE_LONG_1D(evt, d1)                  \
-                   HVMTRACE_2D(evt ## 64, (uint32_t)(d1), (d1) >> 32)
-#define HVMTRACE_LONG_2D(evt, d1, d2, ...)              \
-                   HVMTRACE_3D(evt ## 64, d1, d2)
-#define HVMTRACE_LONG_3D(evt, d1, d2, d3, ...)      \
-                   HVMTRACE_4D(evt ## 64, d1, d2, d3)
-#define HVMTRACE_LONG_4D(evt, d1, d2, d3, d4, ...)  \
-                   HVMTRACE_5D(evt ## 64, d1, d2, d3, d4)
-
-#endif /* __ASM_X86_HVM_TRACE_H__ */
-
-/*
- * Local variables:
- * mode: C
- * c-file-style: "BSD"
- * c-basic-offset: 4
- * tab-width: 4
- * indent-tabs-mode: nil
- * End:
- */
diff --git a/xen/arch/x86/include/asm/hvm/vmx/vmx.h b/xen/arch/x86/include/asm/hvm/vmx/vmx.h
index 8ffab7d94c26..1489dd05c2a1 100644
--- a/xen/arch/x86/include/asm/hvm/vmx/vmx.h
+++ b/xen/arch/x86/include/asm/hvm/vmx/vmx.h
@@ -15,7 +15,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 extern int8_t opt_ept_exec_sp;
diff --git a/xen/common/trace.c b/xen/common/trace.c
index 27c8a19f0549..c9c555094bf7 100644
--- a/xen/common/trace.c
+++ b/xen/common/trace.c
@@ -666,22 +666,21 @@ static DECLARE_SOFTIRQ_TASKLET(trace_notify_dom0_tasklet,
                                trace_notify_dom0, NULL);
 
 /**
- * __trace_var - Enters a trace tuple into the trace buffer for the current CPU.
+ * trace - Enters a trace tuple into the trace buffer for the current CPU.
  * @event: the event type being logged
- * @cycles: include tsc timestamp into trace record
  * @extra: size of additional trace data in bytes
  * @extra_data: pointer to additional trace data
  *
  * Logs a trace record into the appropriate buffer.
  */
-void __trace_var(u32 event, bool cycles, unsigned int extra,
-                 const void *extra_data)
+void trace(uint32_t event, unsigned int extra, const void *extra_data)
 {
     struct t_buf *buf;
     unsigned long flags;
     u32 bytes_to_tail, bytes_to_wrap;
     unsigned int rec_size, total_size;
     bool started_below_highwater;
+    bool cycles = event & TRC_HD_CYCLE_FLAG;
 
     if( !tb_init_done )
         return;
@@ -808,11 +807,6 @@ void __trace_var(u32 event, bool cycles, unsigned int extra,
         tasklet_schedule(&trace_notify_dom0_tasklet);
 }
 
-void trace(uint32_t event, unsigned int extra, const void *extra_data)
-{
-    __trace_var(event, event & TRC_HD_CYCLE_FLAG, extra, extra_data);
-}
-
 void __trace_hypercall(uint32_t event, unsigned long op,
                        const xen_ulong_t *args)
 {
diff --git a/xen/include/xen/trace.h b/xen/include/xen/trace.h
index f184844e1b55..b39a286d2a8e 100644
--- a/xen/include/xen/trace.h
+++ b/xen/include/xen/trace.h
@@ -40,15 +40,6 @@ int trace_will_trace_event(u32 event);
 /* Create a trace record, with pre-constructed additional parameters. */
 void trace(uint32_t event, unsigned int extra, const void *extra_data);
 
-void __trace_var(uint32_t event, bool cycles, unsigned int extra, const void *);
-
-static inline void trace_var(uint32_t event, bool cycles, unsigned int extra,
-                             const void *extra_data)
-{
-    if ( unlikely(tb_init_done) )
-        __trace_var(event, cycles, extra, extra_data);
-}
-
 void __trace_hypercall(uint32_t event, unsigned long op,
                        const xen_ulong_t *args);
 
@@ -72,10 +63,6 @@ static inline int trace_will_trace_event(uint32_t event)
 static inline void trace(
     uint32_t event, unsigned int extra, const void *extra_data) {}
 
-static inline void trace_var(uint32_t event, bool cycles, unsigned int extra,
-                             const void *extra_data) {}
-static inline void __trace_var(uint32_t event, bool cycles, unsigned int extra,
-                               const void *extra_data) {}
 static inline void __trace_hypercall(uint32_t event, unsigned long op,
                                      const xen_ulong_t *args) {}
 #endif /* CONFIG_TRACEBUFFER */
@@ -104,38 +91,4 @@ static inline void trace_time(
 /* Create a trace record with time included. */
 #define TRACE_TIME(_e, ...) TRACE((_e) | TRC_HD_CYCLE_FLAG, ##__VA_ARGS__)
 
-/* Convenience macros for calling the trace function. */
-#define TRACE_0D(_e)                            \
-    do {                                        \
-        trace_var(_e, 1, 0, NULL);              \
-    } while ( 0 )
-
-/* Common helper for TRACE_{1..6}D() below. */
-#define TRACE_varD(_e, ...)                             \
-    do {                                                \
-        if ( unlikely(tb_init_done) )                   \
-        {                                               \
-            uint32_t _d[] = { __VA_ARGS__ };            \
-            __trace_var(_e, true, sizeof(_d), _d);      \
-        }                                               \
-    } while ( 0 )
-
-#define TRACE_1D(_e, d1) \
-    TRACE_varD(_e, d1)
-
-#define TRACE_2D(_e, d1, d2) \
-    TRACE_varD(_e, d1, d2)
-
-#define TRACE_3D(_e, d1, d2, d3) \
-    TRACE_varD(_e, d1, d2, d3)
-
-#define TRACE_4D(_e, d1, d2, d3, d4) \
-    TRACE_varD(_e, d1, d2, d3, d4)
-
-#define TRACE_5D(_e, d1, d2, d3, d4, d5) \
-    TRACE_varD(_e, d1, d2, d3, d4, d5)
-
-#define TRACE_6D(_e, d1, d2, d3, d4, d5, d6) \
-    TRACE_varD(_e, d1, d2, d3, d4, d5, d6)
-
 #endif /* __XEN_TRACE_H__ */
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 16:42:24 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 16:42:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694918.1084183 (Exim 4.92)
	(envelope-from )
	id 1rmG41-0004my-Bq; Mon, 18 Mar 2024 16:42:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694918.1084183; Mon, 18 Mar 2024 16:42:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmG41-0004mr-8X; Mon, 18 Mar 2024 16:42:17 +0000
Received: by outflank-mailman (input) for mailman id 694918;
 Mon, 18 Mar 2024 16:42:16 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmG40-0004jj-63
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 16:42:16 +0000
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com
 [2a00:1450:4864:20::536])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 79c44399-e546-11ee-afdd-a90da7624cb6;
 Mon, 18 Mar 2024 17:42:15 +0100 (CET)
Received: by mail-ed1-x536.google.com with SMTP id
 4fb4d7f45d1cf-568a19fcc4eso2582124a12.1
 for ; Mon, 18 Mar 2024 09:42:14 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 dl19-20020a170907945300b00a44b90abb1dsm4942497ejc.110.2024.03.18.09.42.13
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 18 Mar 2024 09:42:14 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 79c44399-e546-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710780134; x=1711384934; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=47KOIssaEzxtjQTqyt3uWH4deUrbCtDwYpwQMeCeJGo=;
        b=EY5qy/y92Nh+m+T3LCn7MiaJg6IS992UzkkpEivnDJiFcd8meenl4CKUkJ1djxrr4D
         H0XNn/lR7ar+OUwXeCKnlpSGeqLVLcIeV0XuccK/DdBV+dEcZwfumVX0rZ7ZW1GkN+Z6
         G5tc6OaC6ETcluCEwW9Mj9TE8kTRdOTEhXKbby3kv9hRnrwttuE9mGKt5EG0ysgZXsfa
         auXQO4jCBdhl95FNiwLNJzw086LoWhr2a/+j7ra8kSgrB6kGvb9tJqrRh5k7Zl05csJP
         uwimKt8rJb0ga1mZQl0IrwQJklxpAMLYdT0bGeyLk6JTuRt2d9Tv3/Gqnqsz56FyGDAn
         +1Ag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710780134; x=1711384934;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=47KOIssaEzxtjQTqyt3uWH4deUrbCtDwYpwQMeCeJGo=;
        b=PtKaQuTmUNbSGUoYfr381aWuFOFNKpu0w7SijqhFzCNaP2uk2ISv0+ZXIC14fjvBt8
         iBfFHV/65ogvcjQ/6cPVtss23z+8z8d27fcGY+vqpkog/YHCx11ZH0SMdy84RwqYRB7o
         /uQm1hNEBlqPw+CQCY+r7lUD5hPgmB4Sj7vhPakOgV5uFPmfuh8H9l3mKcLn3rD4SLtD
         iex9EFxoR6IR1f2TavS4dt8Y1R2GtXnv3qUDK+jMTQloE5FlYJbSbD9kjXlkmiwzhPit
         JsVqwYtCk+oonoY5ErEjxuDsMlASnK3Pn6+LRnmkDeIKvGaAqjcLtYlDD1LghkQzD1Jv
         WY6A==
X-Forwarded-Encrypted: i=1; AJvYcCWMrwhhYbfPAV4S1SgBGcbQFWa5TS6XGxK3DAEEd+JlLJ74UBRJzrFKLeJK+9QVJEpjzVt4zSw3JTVM4jfxDq1gkP2wlhlPEi3QXM6bK/I=
X-Gm-Message-State: AOJu0YxovrlqSMaqzkxp54xuB8ZI9lPCUICri6lFQUaASwQ8kVWrps1s
	7vbLoh5DC8yUBDzz3utNW40qmpX1wbXWRK5KgIKJonilz07F+5kdRH7cgUrbPw==
X-Google-Smtp-Source: AGHT+IGHdLeIu4R9HRU+RDRzDb34v1dLIm9T3i+U9vnZ5ON2qQZRd4YhZZX+s8bMrrahIuba2un+Pw==
X-Received: by 2002:a05:6402:428a:b0:565:b456:435d with SMTP id g10-20020a056402428a00b00565b456435dmr6930608edc.17.1710780134491;
        Mon, 18 Mar 2024 09:42:14 -0700 (PDT)
Message-ID: <12ef9d96-c6bd-4ed1-b3a3-402ec122fb85@suse.com>
Date: Mon, 18 Mar 2024 17:42:12 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 01/10] x86/cpufeature: add parentheses to comply with
 Rule 20.7
To: Nicola Vetrini 
Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com,
 ayan.kumar.halder@amd.com, consulting@bugseng.com,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu
 , xen-devel@lists.xenproject.org
References: 
 
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 18.03.2024 12:53, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be safe with respect to expansions that
> can possibly alter the semantics of the passed-in macro parameter.
> 
> No functional change.
> 
> Signed-off-by: Nicola Vetrini 

Acked-by: Jan Beulich 




From xen-devel-bounces@lists.xenproject.org Mon Mar 18 16:43:28 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 16:43:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694927.1084194 (Exim 4.92)
	(envelope-from )
	id 1rmG58-0005be-Kv; Mon, 18 Mar 2024 16:43:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694927.1084194; Mon, 18 Mar 2024 16:43:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmG58-0005bX-Ht; Mon, 18 Mar 2024 16:43:26 +0000
Received: by outflank-mailman (input) for mailman id 694927;
 Mon, 18 Mar 2024 16:43:26 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmG58-0005DK-9S
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 16:43:26 +0000
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com
 [2a00:1450:4864:20::62f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a33a77c9-e546-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 17:43:24 +0100 (CET)
Received: by mail-ej1-x62f.google.com with SMTP id
 a640c23a62f3a-a44665605f3so514020866b.2
 for ; Mon, 18 Mar 2024 09:43:24 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 dl19-20020a170907945300b00a44b90abb1dsm4942497ejc.110.2024.03.18.09.43.23
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 18 Mar 2024 09:43:23 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a33a77c9-e546-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710780204; x=1711385004; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=ulHwTAIaTZrGJUikZmbd881riswrlSkh4lVnhSaF1/w=;
        b=aO1qbGrOm3DFcHrTfsn/yAs/8H8EOccIJF99EDaJyOkA6AM+mK+Z5BHxY3Y7O65kQ2
         FQK7iY7L0GLP2uZUF7N77MzibyomGOWZK9jwvqUD4H7fmwnRZoYIV4VXSFSRAk5gWRL3
         crExwZIUqX86lVoRjGgyQyK9UHSTG8nE9O5QasiWYOcu8C9PjdMZkr9jV0pfi93i/tpU
         Cq3iRmlxMKI7FGrINwIuYsc0OXTE6zMVaejXEKoM64DCDP7HP+bL6Lpe13lGdFoOvb81
         SLU0Xp8b2QtAIXBlIBMbuznSgJynZ4NbnEH+fEgV/4KqEHoK8axuIgo163tZmX5DnLbL
         LTDA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710780204; x=1711385004;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=ulHwTAIaTZrGJUikZmbd881riswrlSkh4lVnhSaF1/w=;
        b=IXN0JfN6jEkF3qpj8o1tAnKLYIOkMsJ98Mn/FihbfjbDxoqi7dGNMwkfbwA4oB2pR+
         ZtAjh8HAYKTyWNiEjK0zeV6GH3C0mB9DDajlFODsyZ+k4P99laHEIRji4+1E1tW54nJO
         MtME7dvWdC3haYx3bh55AFJqeV6bbXTrcyOhnoZCtwSLSPNlkdtyXXkOlhBjBoOSz00b
         EpVeIqsPWnoWvWnRAPNmASm1s335H6Oqv7cs/MRLYw6Ia42K17+dvTHJhmZek5XOrqIH
         Tk5L6rRQP37akuuaXqJ880vAfcL+EbvoWa0RVAAryIwMTttU0PU19K9Sg+SkjCEdW6yh
         1dVQ==
X-Forwarded-Encrypted: i=1; AJvYcCXwHr1cO6yi6hY5TW8ULiy4ff0qgzxlpMCsLl9egAyBUp9glRbxJhgBY4ZJc9+26M+K3Lm4+XYUMD1olKAv9zw5Fb6Wy2avOCQlgy9Dwks=
X-Gm-Message-State: AOJu0YyXQ3kR84FPardYUDBt3aXbUZrWKVjb+UdOFDGerGJT4yNGLMgp
	tAYVIAjnqcKuLhRJ9AzBQCBZjxohAefcwyWjWKh06XNKrSmR0GHCenmI/r/+7A==
X-Google-Smtp-Source: AGHT+IFqbdzSLXfj1Y1chT8Zo9Dgo/xZHUB8uih0fUBe4wSyugjootFgHNGqJjU1B5iBc4vzNHFChA==
X-Received: by 2002:a17:906:d293:b0:a46:ca55:2f9e with SMTP id ay19-20020a170906d29300b00a46ca552f9emr1415680ejb.1.1710780204051;
        Mon, 18 Mar 2024 09:43:24 -0700 (PDT)
Message-ID: <876b9326-e537-4fe9-8fba-2c2594768304@suse.com>
Date: Mon, 18 Mar 2024 17:43:23 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 02/10] AMD/IOMMU: guest: address violations of MISRA C
 Rule 20.7
Content-Language: en-US
To: Nicola Vetrini 
Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com,
 ayan.kumar.halder@amd.com, consulting@bugseng.com,
 Andrew Cooper , xen-devel@lists.xenproject.org
References: 
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 18.03.2024 12:53, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be safe with respect to expansions that
> can possibly alter the semantics of the passed-in macro parameter.
> 
> No functional change.
> 
> Signed-off-by: Nicola Vetrini 
> ---
> This local helper may disappear as a follow-up to [1], if the function that
> remains there after the cleanup ends up being removed, so this patch has a slight
> dependency on what follows up from that thread (in which case it can be dropped).

Indeed let's not add more churn to the file before it disappears.

Jan

> [1] https://lore.kernel.org/xen-devel/alpine.DEB.2.22.394.2403151724380.853156@ubuntu-linux-20-04-desktop/T/#m9474ad4f35830345a22acd4a665245f7085d4b46



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 16:48:01 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 16:48:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694931.1084204 (Exim 4.92)
	(envelope-from )
	id 1rmG9U-0006BB-49; Mon, 18 Mar 2024 16:47:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694931.1084204; Mon, 18 Mar 2024 16:47:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmG9U-0006B4-1T; Mon, 18 Mar 2024 16:47:56 +0000
Received: by outflank-mailman (input) for mailman id 694931;
 Mon, 18 Mar 2024 16:47:55 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmG9T-0006Ay-L0
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 16:47:55 +0000
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com
 [2a00:1450:4864:20::62e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 444415d6-e547-11ee-afdd-a90da7624cb6;
 Mon, 18 Mar 2024 17:47:54 +0100 (CET)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-a467d8efe78so472934066b.3
 for ; Mon, 18 Mar 2024 09:47:54 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 e9-20020a170906c00900b00a46ce8f5e11sm564072ejz.152.2024.03.18.09.47.53
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 18 Mar 2024 09:47:53 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 444415d6-e547-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710780474; x=1711385274; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=3JQQC7SCOR0ADM40aLhKPCBH7sTI8Bxk7mQM461sbfo=;
        b=BJUXR7J6LNukJBHEdkdw3jgShFsyt/FF0grr/vHG68qp+LuPWp+P1aQbozRzXzSeuQ
         TGJzDd4IesZIgsVfQQiRQGKglbSIhp/kabnieECkoKsyJmYR06aOhayV2EkHh1UmmwM+
         rQzDRKAK+FW4CBreW2SCCLpX2d2gM2lkW5rVh5yo/h8eJTa7SyC1DfwIKFEYq0bsR+Rq
         M+duisopU6cVHDwUaTgdtH7Jt3h8na8ngRE9taXUdbcmh1xIRHRbflDGjHv5+MNfVf4E
         igKWCaPd80lwIYIV6buHzGod9mpKWO7c7XL0GLoFnHvufFM9fbc5JDHiK4vA4p0C+F1c
         WJqA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710780474; x=1711385274;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=3JQQC7SCOR0ADM40aLhKPCBH7sTI8Bxk7mQM461sbfo=;
        b=wX9NFUEy661AK1KsJMkorcyXjHuSd3lvWqRrZ57pWuWCIdabBSzd/zGdl9+jYlV5B7
         oZ+tdx2r9VC9pkHjR7ZyX3VazPR23NjqX+vhNTZxn29NjsERz9sZZBkDnFBQB8MLj0KC
         jKlAfH+uS3wM/d0eepyXVqOq6Qm49cB+hvMSxg28uw5Gf0zuq78WlLZrxZlpKYy6FuyO
         cSYsdrGVVr91uGaZrp02noAh+aV3Mx4jisXpqOofE6RXvjSwoU5xqaqCsBRD/kAJlO0/
         phw4ebwpFEoQOy3dHJ751JRuOt+G+pnZ8D+Pan5u0PsslyWGZ9ix9XoP1UEIqfP7+qdN
         /WQQ==
X-Forwarded-Encrypted: i=1; AJvYcCWFSNgtliPdjHaZ2iqXoEtHmf+y1JiwmmtIGMBpUkeECnIL0RqWgMx4kavHMgurkvrSR0oz+KnuXEHAfjzar5GyNTVQDre0dmmIw9KVNHI=
X-Gm-Message-State: AOJu0YzoWDZu54OYgTrbm/qHvXl2qiAtrwBJn2eNiUReU26Qvw00Ap+l
	nYZKPuif9gYAbjUWZAOhPFXBrgqWoGQEASsmXaSVPjX/BQVUqDG5r9IcrrueEw==
X-Google-Smtp-Source: AGHT+IFJpirN2ACSw9GPznDMX5THDiGiTds4anPrl9HayfkJPBBd8DafzaimSZUH39buKyLeBRbzAQ==
X-Received: by 2002:a17:906:3e18:b0:a44:51c1:733c with SMTP id k24-20020a1709063e1800b00a4451c1733cmr8337654eji.39.1710780474163;
        Mon, 18 Mar 2024 09:47:54 -0700 (PDT)
Message-ID: <5a3a2087-36fd-4ac7-8cd7-7dc29a0d0bd5@suse.com>
Date: Mon, 18 Mar 2024 17:47:53 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 05/10] EFI: address violations of MISRA C Rule 20.7
Content-Language: en-US
To: Nicola Vetrini 
Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com,
 ayan.kumar.halder@amd.com, consulting@bugseng.com,
 xen-devel@lists.xenproject.org
References: 
 <66095ff2496d9b2be701877a3df762293fc8708b.1710762555.git.nicola.vetrini@bugseng.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <66095ff2496d9b2be701877a3df762293fc8708b.1710762555.git.nicola.vetrini@bugseng.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 18.03.2024 12:53, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be safe with respect to expansions that
> can possibly alter the semantics of the passed-in macro parameter.
> 
> No functional change.
> 
> Signed-off-by: Nicola Vetrini 
> ---
> This file is matched by exclude-list.json, but the fix is rather trivial
> and actually benefits code that is in scope for compliance.

Hmm, yes, the change is simple enough to not be a big hindrance even if we
were to pull in incremental updates from gnu-efi, so
Acked-by: Jan Beulich 

Albeit preferably with ...

> --- a/xen/include/efi/efierr.h
> +++ b/xen/include/efi/efierr.h
> @@ -22,7 +22,7 @@ Revision History
>  
>  
>  #define EFIWARN(a)                            (a)
> -#define EFI_ERROR(a)              (((INTN) a) < 0)
> +#define EFI_ERROR(a)              (((INTN)(a)) < 0)

... excess parentheses dropped in exchange:

#define EFI_ERROR(a)              ((INTN)(a) < 0)

I may take the liberty of doing so while committing.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Mar 18 16:49:33 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 16:49:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694933.1084214 (Exim 4.92)
	(envelope-from )
	id 1rmGB2-0008Uz-G5; Mon, 18 Mar 2024 16:49:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694933.1084214; Mon, 18 Mar 2024 16:49:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmGB2-0008Us-C9; Mon, 18 Mar 2024 16:49:32 +0000
Received: by outflank-mailman (input) for mailman id 694933;
 Mon, 18 Mar 2024 16:49:31 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmGB1-0008Um-Ny
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 16:49:31 +0000
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com
 [2a00:1450:4864:20::634])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7d86570d-e547-11ee-afdd-a90da7624cb6;
 Mon, 18 Mar 2024 17:49:30 +0100 (CET)
Received: by mail-ej1-x634.google.com with SMTP id
 a640c23a62f3a-a46aaf6081fso262904266b.2
 for ; Mon, 18 Mar 2024 09:49:30 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 e9-20020a170906c00900b00a46ce8f5e11sm564072ejz.152.2024.03.18.09.49.29
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 18 Mar 2024 09:49:30 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7d86570d-e547-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710780570; x=1711385370; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=P/b80GEbnFGDZM70kWZE83UJmRDIWScWxcxf64Q2gco=;
        b=Q4wKIAikK5qEFN86AWHpfP38R/5kbI5HUtd62DJ0M1+Dj9xDpDmZBa5e6GAbC17nwi
         cfT2LdPBCXjHdecNk1xaTjobGOCVeFdBu9DdiSeZVNH/us9Hik2CbYaix4mz3lh13FcE
         9530eypk2TuqhHNbw4p5QZg+OGJeKYInzB1fHisJ8rFKCLKdKcNI6dpa8ZrWUVGdn69Z
         JP8B/emJsueNW0CZ1oXEuK10adtItxbzhJocSLFRGKF/Ytx3AajuhJrG3vP/G1GZhk3Y
         jEZLwC7dqe+8oXCfg01Xp0bwLvrck32mVEhDK2f2FNiBBKbNxX5vw+UKjXcSvddbcIt3
         8GBg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710780570; x=1711385370;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=P/b80GEbnFGDZM70kWZE83UJmRDIWScWxcxf64Q2gco=;
        b=UUSZKYlkCRiIh8G9lKKPlQ6JIlaEWUKfQMnYIfqncygYx+zZGw9qUHFBHXJJ6mUmnY
         aybQONQXg1ZmvBffmuo+KS01GjvU+pjCLRN7tZ0Qy83FY1Q6KjB3ayqy9zDcasCyM0Jy
         DsTbEFlw5ZQWclF9vI6LZ2KQAw/08bCW/tJMvezH0uTDkJqXK1Kc5lhBqZIRhXLSrQcK
         bSUn9ySOGvg5shzb8kN0TiGGaKJ5Jzyi1igzjXgu1eQM8n5yoPZTYt0DW40l/MfvN3Eo
         Xhgpz8YFDbizcWyVa2FV9/nck1Jrx3HS6s6zd0M1PZnWMvbrUSknuG6Vt8h2hx0W/7Tr
         IC7Q==
X-Forwarded-Encrypted: i=1; AJvYcCVJeGIGtd24RktkpJSB7VCX3jA1V7BJdcxTDIsbx1ZtsFdbGu9MbUKICtg4ODG9Oicj/gcaMupe7hJwhVYFT7sYirNL9Ienre8YvCYY0KI=
X-Gm-Message-State: AOJu0YzCSZGbn3ZloXMxRgklDw57HmM8ho7ZAaQ/gZvBX+lc8Az12Emt
	Gs46jdJIOeRlPSpnTxHvZX3aZhdJU4IS6/khcAaUgP/IF0V1roxeRE/+Z8UGww==
X-Google-Smtp-Source: AGHT+IHEOvzc2V82eWwghBz1J8gllLa0v/NmL50y1dYSw7rW25XGSHHMcmymDbUCwJZzvEFpsTgZ3Q==
X-Received: by 2002:a17:907:11c7:b0:a45:c027:372 with SMTP id va7-20020a17090711c700b00a45c0270372mr6909150ejb.68.1710780570268;
        Mon, 18 Mar 2024 09:49:30 -0700 (PDT)
Message-ID: <28eaf480-4ed6-4c1d-9508-63e8d497d530@suse.com>
Date: Mon, 18 Mar 2024 17:49:29 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 07/10] xen/efi: efibind: address violations of MISRA C
 Rule 20.7
Content-Language: en-US
To: Nicola Vetrini 
Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com,
 ayan.kumar.halder@amd.com, consulting@bugseng.com,
 Julien Grall , Bertrand Marquis ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu
 , xen-devel@lists.xenproject.org
References: 
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 18.03.2024 12:53, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be safe with respect to expansions that
> can possibly alter the semantics of the passed-in macro parameter.
> 
> No functional change.
> 
> Signed-off-by: Nicola Vetrini 
> ---
> This file is matched by exclude-list.json, but the fix is rather trivial
> and impacts code that in under the scope of MISRA compliance.

On the same basis as the other change:
Acked-by: Jan Beulich 

I wonder though: Where do we draw the line?

Jan


From xen-devel-bounces@lists.xenproject.org Mon Mar 18 16:50:08 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 16:50:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694936.1084224 (Exim 4.92)
	(envelope-from )
	id 1rmGBc-0001RK-ON; Mon, 18 Mar 2024 16:50:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694936.1084224; Mon, 18 Mar 2024 16:50:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmGBc-0001RD-LF; Mon, 18 Mar 2024 16:50:08 +0000
Received: by outflank-mailman (input) for mailman id 694936;
 Mon, 18 Mar 2024 16:50:07 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmGBb-0001Lz-3F
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 16:50:07 +0000
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com
 [2a00:1450:4864:20::62d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 92ab38f9-e547-11ee-afdd-a90da7624cb6;
 Mon, 18 Mar 2024 17:50:06 +0100 (CET)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-a44ad785a44so541708666b.3
 for ; Mon, 18 Mar 2024 09:50:06 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 e9-20020a170906c00900b00a46ce8f5e11sm564072ejz.152.2024.03.18.09.50.05
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 18 Mar 2024 09:50:05 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 92ab38f9-e547-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710780606; x=1711385406; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=47KOIssaEzxtjQTqyt3uWH4deUrbCtDwYpwQMeCeJGo=;
        b=fwsYHxbAsQ5xvKuOpXWVq5f1bxUc2arfn59tJ419wBzXPkPkT2AvuDttZxOznfa6xg
         Oz5vzHlcSufUkCMTa0QDpiVnyUbSYGcmsj1zcAX1tQwkCD2kJxX/X5tI6SPl/RwbMuQ2
         XBUWdr8ZVunl4Wl7FRwRfnJscZGODLaZ+tyTAiXCwVdB9yTnKdDYHrASaJtieihtyxxj
         OqnxFi3My6Xe1AsuOblivKGfS/VpDerV0smIz+gYVYGWB4jFjjO0mDVMPMor3hGsexaK
         bWClyhEdkvBn3NW07Kpn+AwnlwMdmPMTsw1+AYCt1fXTau4l4i9wZ2W971jKUZ6GluJ8
         mroA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710780606; x=1711385406;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=47KOIssaEzxtjQTqyt3uWH4deUrbCtDwYpwQMeCeJGo=;
        b=MuYPQEPl9bz9qeIY1Y8dd5Hif7UNpQAxe/QSJdQ616re19cHjZz+WThfmKpVZ8mYrL
         z0FLeSPwhXAld57zr6CPhxk6dLp2/PXhFbAPQDxWi1tVF4UcCNckEk4SYab2dynalQH4
         +cdOTmUvua4Z0Zx1XBGN6G8KJV3TpFHsZc45BzQEbxoGLx9X5e/Ck+1I1kq44xqXdFXB
         UbiCNuaK88LQIy9zd0FNqoi+cGOYlj2e8QqwPgA4kUVjhDi8gMawxXQtjPgJXE2JTrnV
         f6at4BM6s+ACWUlxM7vK/BAYJ+5I5/YdrkpbOi7E50YtSZZtohW17yLeMayN0WrsksaF
         OF/Q==
X-Forwarded-Encrypted: i=1; AJvYcCXFfryNfablnWp49i6xEDgosyLZkLyQ2DsRC6JgK24k+VhbSkJ8fmoNesUiyyQvZAbeVFqNNhT54iZKlIgJmGWU4iN2qnTEwnTL8DwqSB4=
X-Gm-Message-State: AOJu0YzZs8DjOxX8X8DZnGykDSPoxXbt/laQ1k3fmYd9I1U5Sbmyn+xo
	7Ivxg2SJ3wGH0rQTp984fFs7GkSXu8K1fTDCiqHeODrkKw5+zlWpuaQ55lq7xA==
X-Google-Smtp-Source: AGHT+IH2yScdPKV+9YqN/Awa6O7r2yAdcDBXOtEiG7LW4RFn3DT6+Lzz8qSxpDBRbu8wthl08T5U1Q==
X-Received: by 2002:a17:906:ee8e:b0:a46:bdd8:64ef with SMTP id wt14-20020a170906ee8e00b00a46bdd864efmr3001261ejb.19.1710780605903;
        Mon, 18 Mar 2024 09:50:05 -0700 (PDT)
Message-ID: <6e6dce2b-dcfe-4fe9-add4-4f93dabc51a5@suse.com>
Date: Mon, 18 Mar 2024 17:50:05 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 08/10] xen/notifier: address violations of MISRA C
 Rule 20.7
Content-Language: en-US
To: Nicola Vetrini 
Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com,
 ayan.kumar.halder@amd.com, consulting@bugseng.com,
 Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Wei Liu , xen-devel@lists.xenproject.org
References: 
 <5ea6d48a2af93c54693364eb5bfa7e575eb717a3.1710762555.git.nicola.vetrini@bugseng.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <5ea6d48a2af93c54693364eb5bfa7e575eb717a3.1710762555.git.nicola.vetrini@bugseng.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 18.03.2024 12:53, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be safe with respect to expansions that
> can possibly alter the semantics of the passed-in macro parameter.
> 
> No functional change.
> 
> Signed-off-by: Nicola Vetrini 

Acked-by: Jan Beulich 




From xen-devel-bounces@lists.xenproject.org Mon Mar 18 16:51:05 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 16:51:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694939.1084234 (Exim 4.92)
	(envelope-from )
	id 1rmGCW-00022v-4o; Mon, 18 Mar 2024 16:51:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694939.1084234; Mon, 18 Mar 2024 16:51:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmGCW-00022m-28; Mon, 18 Mar 2024 16:51:04 +0000
Received: by outflank-mailman (input) for mailman id 694939;
 Mon, 18 Mar 2024 16:51:02 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmGCU-00022Y-G0
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 16:51:02 +0000
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com
 [2a00:1450:4864:20::634])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b3aa82c7-e547-11ee-afdd-a90da7624cb6;
 Mon, 18 Mar 2024 17:51:01 +0100 (CET)
Received: by mail-ej1-x634.google.com with SMTP id
 a640c23a62f3a-a44f2d894b7so539656166b.1
 for ; Mon, 18 Mar 2024 09:51:01 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 e9-20020a170906c00900b00a46ce8f5e11sm564072ejz.152.2024.03.18.09.51.00
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 18 Mar 2024 09:51:00 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b3aa82c7-e547-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710780661; x=1711385461; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=47KOIssaEzxtjQTqyt3uWH4deUrbCtDwYpwQMeCeJGo=;
        b=DQSyAUCYne15jovCr3OADkRATzgkLwMOdXwbxkXoqnewfTq55eYN95T7efMNPYO6gc
         5hGIee+hY00dPHlIczPEqA3+Sfp4nEKEXr2YBpVOulFzwZDYOA8mV7qSGlUVt6b3AMmO
         cR7N+cKSUWSXHSs9W+IF3NH7fumEcBA2k3QcLZujMc+Xik5+jwBC9bIk1fZjXRbuNA48
         gL4fJJ4Y1ZEKX/at0+zFZfqLoETJ+d0Mqy7Fexzc8DNZkxOQeYahaflOIu7MYGqSBAyS
         6sNbzVU92K+miBHqfL5AnEzVdHmZN0LT8p6qJY11vad63KE4PnS89uFQUxOwnbHiK9Il
         MRYA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710780661; x=1711385461;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=47KOIssaEzxtjQTqyt3uWH4deUrbCtDwYpwQMeCeJGo=;
        b=sJZ6PvqR+DYFs9OkhZ2hZ2gpg2oG/rgamsTtb9xBRoMeDA02o39XrgHuQ2t5UzNrIL
         RmaMLVId6QpaN/Oyh/QMkaghsY8p7kBLn8R/6ESpfVxgwiBdiUxS9AR7fIRs/gsAujp1
         7Ysns4/6fWnG9QlCgpVRQQpGqpGmN5XURZpDazI5/yvIqtIrD5I9L4Vizk+R5O1StBDt
         4pS2mIMtzJc1YVmkCGXreEoU0X8R0gpKiNuVoechI8NgAS1EM0odljN2FUl3RJ4dxBab
         0Tplo528prArjuof0hvyfMt8ahOp9MKMhxin90LPB+51OIkk40ssDdwdGdxJbQ7/p5V3
         6+9A==
X-Forwarded-Encrypted: i=1; AJvYcCW1QmkxspjHwvLKVzis06EUfwKywFb3wDNN0Ws0Uf11DjH31s8DNLTv3j96kYHg2eJjAJfH995IVdxxF1zFfrBeIEbDkpNa39bX7LRwNio=
X-Gm-Message-State: AOJu0YyuDQuQqSc9pEQ0tAaG1rFgBOtbAHzUbxFOd8ybVy/WTTwbV/Pm
	8aapeMqX75AGSLeArcCu1f0dqnmc+y97lsMFXIP5unNC62UKQO2m1z4jWIKhNw==
X-Google-Smtp-Source: AGHT+IEdBP/KVZsHXgiJzGrfhE8yUR9Zkaay7bZZ6mmt4cZw0CeZvzwhQWI+K/1w/G55jvDJUFw0UA==
X-Received: by 2002:a17:906:e951:b0:a44:dc35:df19 with SMTP id jw17-20020a170906e95100b00a44dc35df19mr7926837ejb.67.1710780661123;
        Mon, 18 Mar 2024 09:51:01 -0700 (PDT)
Message-ID: 
Date: Mon, 18 Mar 2024 17:51:00 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 09/10] xen/wait: address violations of MISRA C Rule
 20.7
Content-Language: en-US
To: Nicola Vetrini 
Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com,
 ayan.kumar.halder@amd.com, consulting@bugseng.com,
 Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Wei Liu , xen-devel@lists.xenproject.org
References: 
 <1d9f79590a224b4007f34a609b8024b36dd44a04.1710762555.git.nicola.vetrini@bugseng.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <1d9f79590a224b4007f34a609b8024b36dd44a04.1710762555.git.nicola.vetrini@bugseng.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 18.03.2024 12:53, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be safe with respect to expansions that
> can possibly alter the semantics of the passed-in macro parameter.
> 
> No functional change.
> 
> Signed-off-by: Nicola Vetrini 

Acked-by: Jan Beulich 




From xen-devel-bounces@lists.xenproject.org Mon Mar 18 16:55:58 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 16:55:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694944.1084274 (Exim 4.92)
	(envelope-from )
	id 1rmGHF-0003NB-C7; Mon, 18 Mar 2024 16:55:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694944.1084274; Mon, 18 Mar 2024 16:55:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmGHF-0003Md-98; Mon, 18 Mar 2024 16:55:57 +0000
Received: by outflank-mailman (input) for mailman id 694944;
 Mon, 18 Mar 2024 16:55:55 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmGHD-0002f9-Li
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 16:55:55 +0000
Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com
 [2a00:1450:4864:20::334])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 61ba3bef-e548-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 17:55:53 +0100 (CET)
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-414006a0115so34420025e9.3
 for ; Mon, 18 Mar 2024 09:55:53 -0700 (PDT)
Received: from localhost.localdomain
 (cpc92320-cmbg19-2-0-cust35.5-4.cable.virginm.net. [82.13.64.36])
 by smtp.gmail.com with ESMTPSA id
 a18-20020a05600c349200b0041413d11838sm2020141wmq.26.2024.03.18.09.55.52
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 18 Mar 2024 09:55:52 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 61ba3bef-e548-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710780953; x=1711385753; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=HcKGBjF7duyhQKCXtEFBeJNsUbmPicCjB0pyp6hYt+o=;
        b=WsrC13EOsz8uLsoCjJAXgTlodUkrdK5HChxaGKeJHl69+9lwZ0bvIU/lQDF+SmzCyy
         juFtSc9OwIbx8lscllSTUT6ejNn8qBXQW4RfS/CzsAuMIHw3tHwpN/zfYgWNSteMArSL
         yPqKAVyT7JkzzfJwPP6w0A+hqd6Q1AwrgioaU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710780953; x=1711385753;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=HcKGBjF7duyhQKCXtEFBeJNsUbmPicCjB0pyp6hYt+o=;
        b=slJZBswnbkjJZ6ePOXwmWOxEYh9pOgdI1dgZB/+Fn2znzsTsFcHVDZXIOwqsxuMaWL
         SKS/1OWy/8fPJ79zbLePbgycHOf2YPDuEPcY8s1s1dFV7qT00gSXKrdnIrYqQUix0/2v
         aueKRo+xfKhSSn+zZvyoHj+SxY5NiTyDuGY3xBm6hpkeN19SHPP3qiI4NM7nQR4mqLE0
         aEXJ8Pr99hfZGQs4Q0Wq2GFvGSQPw4fEgKe32r1Bc6sQ8I+rpoezXurPqDgw5LXp9puX
         xkj6fI4W/yj6az0NAltswkHsXccoUVUYSccLt7WIHnW8Gt9XzyiZMgK59auYGTyZwxJ8
         OnNw==
X-Gm-Message-State: AOJu0YwVJDvgS8tAPGZBK0dEBOZ8FcSadIGW6Xd6K/nryDHrcB2bLQOi
	qNlANVlFN7NvEGQEeWx5ESE+gyeAvdB1N/s7+P1bmaYqq03tVJ8tt56Cv/sYEAwBIzS/oQ8/S58
	L
X-Google-Smtp-Source: AGHT+IEXEM7HDGP+KeNvTIogdB7vL94LrpI5Hk/v603q5Y0GFu3bqylgTJf7/90kics/0EwcAuWZmg==
X-Received: by 2002:a05:600c:4e8e:b0:414:286:fd21 with SMTP id f14-20020a05600c4e8e00b004140286fd21mr6171036wmq.28.1710780952980;
        Mon, 18 Mar 2024 09:55:52 -0700 (PDT)
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne 
Subject: [OSSTEST PATCH 02/36] ts-xen-build-prep: Only force git protocol v2 on buster
Date: Mon, 18 Mar 2024 16:55:11 +0000
Message-Id: <20240318165545.3898-3-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.39.2
In-Reply-To: <20240318165545.3898-1-anthony.perard@citrix.com>
References: <20240318165545.3898-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Newer version of Debian and thus git would use this automatically, no
need to force it.

Signed-off-by: Anthony PERARD 
---
 Osstest/TestSupport.pm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index f0e087aa..0dded9b2 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -3257,7 +3257,7 @@ END
 
     # Adding mandadory use of Git protocol v2
     # necessary on buster when building QEMU v8.1
-    $gitcfg .= <{Suite} =~ m/buster/;
 [protocol]
 	version = 2
 END
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 16:55:58 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 16:55:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694941.1084243 (Exim 4.92)
	(envelope-from )
	id 1rmGHC-0002fM-NN; Mon, 18 Mar 2024 16:55:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694941.1084243; Mon, 18 Mar 2024 16:55:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmGHC-0002fF-KL; Mon, 18 Mar 2024 16:55:54 +0000
Received: by outflank-mailman (input) for mailman id 694941;
 Mon, 18 Mar 2024 16:55:54 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmGHB-0002f9-WD
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 16:55:54 +0000
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com
 [2a00:1450:4864:20::136])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 60cccd77-e548-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 17:55:52 +0100 (CET)
Received: by mail-lf1-x136.google.com with SMTP id
 2adb3069b0e04-513dc99b709so3567308e87.1
 for ; Mon, 18 Mar 2024 09:55:52 -0700 (PDT)
Received: from localhost.localdomain
 (cpc92320-cmbg19-2-0-cust35.5-4.cable.virginm.net. [82.13.64.36])
 by smtp.gmail.com with ESMTPSA id
 a18-20020a05600c349200b0041413d11838sm2020141wmq.26.2024.03.18.09.55.50
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 18 Mar 2024 09:55:50 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 60cccd77-e548-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710780951; x=1711385751; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:from:to:cc:subject:date:message-id:reply-to;
        bh=C50NXD25vOco05Cszq76+7IApZVDAJzX6DHnuaE2dDI=;
        b=rTJ0ftQSnSVj8WCNGQJUK9skEmNIEV6uZ8iht5jqUR28wKQ3hnFd4iCPauZ8+mUq70
         +CtcvT+Q2QdIGqubBnvmBEIUIvl/0/G8d2HIwPs635b5r+H7e0pS1n8x0wM4I3yw6IJ/
         t6zUEO3pfRrVLZS9NQDdBHUVgyOGWfo1ZOkuE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710780951; x=1711385751;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=C50NXD25vOco05Cszq76+7IApZVDAJzX6DHnuaE2dDI=;
        b=ZqYPwVLw04pxTmwFFMVNK/lWj/z7Jh6rgSwc/cEIBFUgX+qeuL5rzPQdPCK4dcYCga
         flCBqkMwuM7HtnIHRBxnDRh0T8ATW8SAuECHPO+jgrU7IBqpoZU4P91ky/7/4XCDPgMz
         dLIDQwonWROnDCiUrL/kzHvDLRimfGcQcLT+8weQVJnI+EPBafVBPbk7A+JO/t0DBx7A
         lTaQn2cgV8PG80a3gRt36tgUUGJwRTNbk2V9DXCv7XwzF09vqI5Be91Q0JZTJSjuGoS9
         lLzhz2ITJIvd9O673SujqHdNSsr6roWjGAG+lvCVNXP/NEH+6FEtIfpqlsxNVEDQJfXC
         D0tA==
X-Gm-Message-State: AOJu0Yz5qyATToT5MBcqX0aylo0xz8pY3q6nWrYTVt/D99gysufQgD4Y
	LlqrdTS3I1KFjbUfBiK3JrQmEibHqHFM+w5zBgXqGSq95/0z0da6MDofry6oZEPuMix545W27TN
	5
X-Google-Smtp-Source: AGHT+IF4aN/OD1yniwnsuSk8uniUu3cP3qQ+kkghzZ/Tj1uemUkZMPpfmF/F4mk1eMsKu6UWpiLqdQ==
X-Received: by 2002:ac2:5f9c:0:b0:512:b0a7:2943 with SMTP id r28-20020ac25f9c000000b00512b0a72943mr60380lfe.5.1710780951260;
        Mon, 18 Mar 2024 09:55:51 -0700 (PDT)
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne 
Subject: [OSSTEST PATCH 00/36] Switch to Debian Bookworm
Date: Mon, 18 Mar 2024 16:55:09 +0000
Message-Id: <20240318165545.3898-1-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.39.2
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Patch series available in this git branch:
https://xenbits.xen.org/git-http/people/aperard/osstest.git br.bookworm-v1

Hi,

I intend to push this series in two waves.

First, push up to commit "Temporally switch "qemu-mainline" branch to
Bookworm". This is to test that osstest still works fine if we need to use
"buster" for a branch. Also upstream QEMU doesn't build on buster anymore, so
I've included a commit to use bookworm for it.

Second, push the remaning two patches, at least a week later, which will switch
the default debian suite.

I did run many tests, but hopefully nothing breaks.

Cheers,

Anthony PERARD (36):
  production-config: Add bookworm debian install media filename
  ts-xen-build-prep: Only force git protocol v2 on buster
  mgi-common: Fix fetch_debian_package error message
  mg-debian-installer-update: Download non-free firmware from new repo.
  ts-host-install: fix ntp.conf path on bookworm
  ts-host-install: fix ntp server setting
  ts-host-install: Restart ntp service
  preseed_create: Use new "d-i grub-installer/update-nvram" for UEFI
    installation
  preseed_create: osstest-erase-other-disks: workaround creating
    /dev/sdXD files
  preseed_create: Workaround fail grub-install on arndale
  ts-host-install,preseed_create: Do lvm vgextend at install time
  di_installcmdline_core: Add link_wait_timeout to install cmdline
  Disable persistent net generator on Bookworm
  preseed_base, ts-host-install: Change NIC NamePolicy to "mac"
  ts-xen-build-prep: Change package selection for Bookworm
  bl_getmenu_open: Read grub.cfg as root
  target_editfile: Use the same user to retrieve and send
  ts-xen-install: remove "libc6-xen" package installation
  overlay-bookworm: Import grub's 20_linux_xen from Debian Bookworm
  overlay-bookworm: 20_linux_xen: Fix XSM entries generation
  ts-xtf-install: Install python symlink
  setupboot_grub2: Parse arm64 uefi grub verbes
  bookworm: Extend ARM clock workaround
  ts-nested-setup, setup l1 lvm volume groupe in guest
  ts-leak-check: add new name for udevd workers
  ts-debian-hvm-install: Allow udev failure in install media
  ts-debian-fixup: Fix nic names for bookworm
  ts-debian-install: keep avoiding to use pygrub
  ts-debian-hvm-install: Increase min guest ram size
  bookworm: Extend guest bootloader workaround
  ts-debian-*-install: Replace dots in hostnames by dashs
  ts-xen-install: Fix bridge setup, ask to copy MAC addr
  make-flight: Keep using buster for L2 guest in nested tests
  Temporally switch "qemu-mainline" branch to Bookworm
  Switch to Debian Bookworm as default suite
  make-hosts-flight: default to bookworm

 Osstest.pm                               |   2 +-
 Osstest/Debian.pm                        |  92 +++++-
 Osstest/TestSupport.pm                   |   4 +-
 make-flight                              |  16 +-
 make-hosts-flight                        |   2 +-
 mfi-common                               |   5 +-
 mg-debian-installer-update               |   9 +-
 mgi-common                               |   2 +-
 overlay-bookworm/etc/grub.d/20_linux_xen | 379 +++++++++++++++++++++++
 production-config                        |   2 +
 ts-debian-di-install                     |   4 +-
 ts-debian-fixup                          |  15 +
 ts-debian-hvm-install                    |  21 +-
 ts-debian-install                        |  17 +-
 ts-host-install                          |  42 ++-
 ts-leak-check                            |   1 +
 ts-nested-setup                          |  10 +-
 ts-xen-build-prep                        |  10 +-
 ts-xen-install                           |   5 +-
 ts-xtf-install                           |   6 +
 20 files changed, 591 insertions(+), 53 deletions(-)
 create mode 100755 overlay-bookworm/etc/grub.d/20_linux_xen

-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 16:55:58 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 16:55:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694942.1084254 (Exim 4.92)
	(envelope-from )
	id 1rmGHD-0002tk-Ui; Mon, 18 Mar 2024 16:55:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694942.1084254; Mon, 18 Mar 2024 16:55:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmGHD-0002td-Rc; Mon, 18 Mar 2024 16:55:55 +0000
Received: by outflank-mailman (input) for mailman id 694942;
 Mon, 18 Mar 2024 16:55:54 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmGHC-0002f9-Lg
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 16:55:54 +0000
Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com
 [2a00:1450:4864:20::329])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 614004a5-e548-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 17:55:52 +0100 (CET)
Received: by mail-wm1-x329.google.com with SMTP id
 5b1f17b1804b1-412e784060cso33041695e9.1
 for ; Mon, 18 Mar 2024 09:55:52 -0700 (PDT)
Received: from localhost.localdomain
 (cpc92320-cmbg19-2-0-cust35.5-4.cable.virginm.net. [82.13.64.36])
 by smtp.gmail.com with ESMTPSA id
 a18-20020a05600c349200b0041413d11838sm2020141wmq.26.2024.03.18.09.55.51
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 18 Mar 2024 09:55:51 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 614004a5-e548-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710780952; x=1711385752; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=pFcZD/vzCDZy7qgNaMCGQWkAf2ZxLdhNx3qOWLX+MmQ=;
        b=LoYGUUIwwtNY88Ya7k++i7V57mDREXCNQP8BR/24s1etfq96izIqjssA7mkBVFC79E
         XYOfz6K9mXr95T/jm2R/LxAPZjSOYjXyqZT1L5z4+0R+Iunv+AfqG85XkTrrfvkTfyep
         95xMOkEGdIcAIcuupE19UfVRsY5ipKbLunrB4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710780952; x=1711385752;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=pFcZD/vzCDZy7qgNaMCGQWkAf2ZxLdhNx3qOWLX+MmQ=;
        b=Dwapubd876t2p+AoFfdeJP5CaCxh5PwZ+X8trHXIOIXQh5WhOE8Mvy50lffzW2VP8P
         i/3xGVeX4p7xFSMCYRNCRHio+QVEKWxq6seulyZtZ+jBUtgswhAA7Gl6LjzEXiweKrFP
         tRIj+UD9lCtoXBYs3vqyd5Qi/8X9zoe2rCjAVwNHei3LjXRAglx6eHg1cHODx2rgnVHm
         6pSQRhklqMFn9aMFsZUMXgTfpcPrt8fM4B4CgpnQiweE4tJORm/YJIWsSUiEB2lJDLZ0
         q+8k7bR06x6ibQhRAp6yJD+CKOYAzE00d48s4oMv6+1Nctk6m5tfCmEDkPsdqp88UeiP
         66xg==
X-Gm-Message-State: AOJu0Yy4xsMAhlh/jiSsu9pYN4ncEi0xvOzhd+rWmYTjyJCnAiNFIEOW
	E8U7TFqL1knpI6AXJkmwkRn5+ERa81XeAqbNnBVyl7sWJ6AGLsd1jTM+lJmxbd+L/TpdRPaAWcp
	m
X-Google-Smtp-Source: AGHT+IG8YAV1ftnzazAZIDxBa3utzD1TDHSKSdBtOtR7vb9I1M5xfaPy+clF7DLuB05ctRuoArjHUg==
X-Received: by 2002:a05:600c:4f04:b0:412:e0f7:ef52 with SMTP id l4-20020a05600c4f0400b00412e0f7ef52mr148317wmq.19.1710780952144;
        Mon, 18 Mar 2024 09:55:52 -0700 (PDT)
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne 
Subject: [OSSTEST PATCH 01/36] production-config: Add bookworm debian install media filename
Date: Mon, 18 Mar 2024 16:55:10 +0000
Message-Id: <20240318165545.3898-2-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.39.2
In-Reply-To: <20240318165545.3898-1-anthony.perard@citrix.com>
References: <20240318165545.3898-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Signed-off-by: Anthony PERARD 
---
 production-config | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/production-config b/production-config
index 2c44805c..6345c40c 100644
--- a/production-config
+++ b/production-config
@@ -101,6 +101,8 @@ DebianImageVersion_jessie 8.2.0
 DebianImageVersion_stretch 9.4.0
 DebianImageFile_buster_amd64 debian-10.12.0-amd64-xfce-CD-1.iso
 DebianImageFile_buster_i386 debian-10.12.0-i386-xfce-CD-1.iso
+DebianImageFile_bookworm_amd64 debian-12.5.0-amd64-netinst.iso
+DebianImageFile_bookworm_i386 debian-12.5.0-i386-netinst.iso
 
 
 # Update with ./mg-netgrub-loader-update
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 16:55:58 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 16:55:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694943.1084260 (Exim 4.92)
	(envelope-from )
	id 1rmGHE-0002wj-8P; Mon, 18 Mar 2024 16:55:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694943.1084260; Mon, 18 Mar 2024 16:55:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmGHE-0002vx-1u; Mon, 18 Mar 2024 16:55:56 +0000
Received: by outflank-mailman (input) for mailman id 694943;
 Mon, 18 Mar 2024 16:55:55 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmGHD-0002gq-5S
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 16:55:55 +0000
Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com
 [2a00:1450:4864:20::32e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 621d9fcd-e548-11ee-afdd-a90da7624cb6;
 Mon, 18 Mar 2024 17:55:54 +0100 (CET)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-41400a9844aso17118995e9.0
 for ; Mon, 18 Mar 2024 09:55:54 -0700 (PDT)
Received: from localhost.localdomain
 (cpc92320-cmbg19-2-0-cust35.5-4.cable.virginm.net. [82.13.64.36])
 by smtp.gmail.com with ESMTPSA id
 a18-20020a05600c349200b0041413d11838sm2020141wmq.26.2024.03.18.09.55.53
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 18 Mar 2024 09:55:53 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 621d9fcd-e548-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710780953; x=1711385753; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=D8kMmfgRq+uIvUAnPJWzu57cwgfUkor1PWJ6MGv3dPY=;
        b=jLdOEag0dDzCt2HMeAKogbxsrj/VL4ryTnec5X0ImhJMVvooJdBc+t/0z3VnrfAxC1
         OIIyUR92gi6mCVxvuKt5a3YxQXcPt0fHlWPa2cZ0A6EZKGYMktADOsnHfWuXHh/gP/sP
         M46IDWHvhZNnpWZ5/Y7IqI53caAUvNRGUDDrs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710780953; x=1711385753;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=D8kMmfgRq+uIvUAnPJWzu57cwgfUkor1PWJ6MGv3dPY=;
        b=TUigHAH4AlQCGOfbt8D7Re5NW5Do9nelw8Z9KsNahAws+BxMMFhua4RlSQyp7J+9as
         REoo3Nr7Ux/uuid11HlG+uz1ur8ECkLY8AcfiChO1G48+jHbZgd9oE6qhIxi9QaTG0K1
         JJorcm+Hx0KkeUMfYcHtD2+k6ulFnwJB64i7KCPj5Anz0Gi/MDbIlG/ppWHUOLGpQWxV
         JNwVnweRUVn3MGr9OaaGCd9ZFCM8Ob9JWejQ0AS84czA0qOpSNb7junSwk/CH+L9h1xM
         1lVws9719MZ15NhDOLFUJYS6+uEiKWZYgMAbWJzn25QDaoMVxYb3xdPnRFBOsgaoFZav
         Xy0w==
X-Gm-Message-State: AOJu0YzsiMkvecqElLq7/VMHjzcMsiVoJG1PR7Vq5FailhDS+VW4TNXE
	OgKmSAwBnhQ3GOQvZRN2z1XWA2ZzuW62sb3YVbph7NdAqqqIqOcwygdkTEdKROWgpKNj21sbPyA
	x
X-Google-Smtp-Source: AGHT+IH6j9RfgTsn7+po8KRRANVQ3xRpnv0hTecjgJ3XM5FB9vDJ9H1qgvfABbSR1BvxNI42chVO1Q==
X-Received: by 2002:a05:6000:cc5:b0:33e:c0fc:5e4b with SMTP id dq5-20020a0560000cc500b0033ec0fc5e4bmr185338wrb.2.1710780953624;
        Mon, 18 Mar 2024 09:55:53 -0700 (PDT)
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne 
Subject: [OSSTEST PATCH 03/36] mgi-common: Fix fetch_debian_package error message
Date: Mon, 18 Mar 2024 16:55:12 +0000
Message-Id: <20240318165545.3898-4-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.39.2
In-Reply-To: <20240318165545.3898-1-anthony.perard@citrix.com>
References: <20240318165545.3898-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

$@ expand to two or more words, but fail() only take one argument.
So if there's more than one argument left, fail() only shows the first
one, and don't event display "not found".

Signed-off-by: Anthony PERARD 
---
 mgi-common | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mgi-common b/mgi-common
index 6ce34162..98f795b1 100644
--- a/mgi-common
+++ b/mgi-common
@@ -49,7 +49,7 @@ fetch_debian_package () {
     set -e
 
     if [ $rc -ne 0 ] || [ x$pkgfile = x ]; then
-	fail "package matching $@ not found";
+	fail "package matching $* not found";
     fi
 
     fetch "$site/$pkgfile"
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 16:55:58 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 16:55:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694945.1084278 (Exim 4.92)
	(envelope-from )
	id 1rmGHF-0003QZ-N4; Mon, 18 Mar 2024 16:55:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694945.1084278; Mon, 18 Mar 2024 16:55:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmGHF-0003PE-Gu; Mon, 18 Mar 2024 16:55:57 +0000
Received: by outflank-mailman (input) for mailman id 694945;
 Mon, 18 Mar 2024 16:55:56 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmGHE-0002gq-9i
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 16:55:56 +0000
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com
 [2a00:1450:4864:20::331])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 63090c5b-e548-11ee-afdd-a90da7624cb6;
 Mon, 18 Mar 2024 17:55:55 +0100 (CET)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-414624a65beso19915e9.3
 for ; Mon, 18 Mar 2024 09:55:55 -0700 (PDT)
Received: from localhost.localdomain
 (cpc92320-cmbg19-2-0-cust35.5-4.cable.virginm.net. [82.13.64.36])
 by smtp.gmail.com with ESMTPSA id
 a18-20020a05600c349200b0041413d11838sm2020141wmq.26.2024.03.18.09.55.54
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 18 Mar 2024 09:55:54 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 63090c5b-e548-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710780955; x=1711385755; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=pJd5erfZkWtwSzXglEFDYQHe8C/Kx7YDmuH1rlEbXsI=;
        b=W+3SSKsj25z4mEM2262ebLcKPVVrUDuKL8880DMLcgNqRaBkJUkE20KT2d4jbpQ2ZE
         zGeA7IeFFelyEZ1PBnCQ5YFXzD4q7PGvmqaHXzNe6g57USnYojqsicBleJBjzJq9ZSP1
         CWNhpcrY1NOgT876Jw7j8JArRO0StL2KWFm54=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710780955; x=1711385755;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=pJd5erfZkWtwSzXglEFDYQHe8C/Kx7YDmuH1rlEbXsI=;
        b=NHnv4F+Lwd7xeD3sWv/cKIPA/xiJAb/kWpDBnI/xhPN9PHkrikd1tjkecAfx5XdYUw
         B0uUBQUERjFjjjzUAAAxK3Ev+Pt+rm0ejqN4fJgnZAHgPKlGkETJgQJmSNsjDJwsxtPS
         DeSrd0pGvs5gqMOVPoqUiYWNAWr0zXlaMpAN3m1FTlCqaQGJhlDomAbFVNhi1LDmuEW+
         UA5ohZ0YmJRtEvIU6rGTNmp2XLfDdOPjPVR6rcxeaGZz/csSY2KfQ8KGedWLTqlgLWtK
         zIIbPMN1hG6r7Tvgr1R1Ojpb5mQEALO8IKIJMuAI0Xtvo8nGYnOYMSq9fJVUXRv36znY
         B8cQ==
X-Gm-Message-State: AOJu0YzwN9D3yvpySyxKy+2e48kWNWrxflfiquSUPyHz/f5sTvFbZEBL
	lVf7g7XP13LldfG+ZVHKM/yjH50R/ekZwXIlf7cTAyn9VJigyhtCJSBR60wnXjbtmuBMwbhDwtA
	P
X-Google-Smtp-Source: AGHT+IEJ2/iL6KmWbo51mROrBbNxnkrtty+8fZDPRUDG1OnLfQQ6qKRZF4wesc3cLJt4vWLpR13A7A==
X-Received: by 2002:a05:600c:458b:b0:413:e523:eed2 with SMTP id r11-20020a05600c458b00b00413e523eed2mr10017053wmo.33.1710780955190;
        Mon, 18 Mar 2024 09:55:55 -0700 (PDT)
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne 
Subject: [OSSTEST PATCH 05/36] ts-host-install: fix ntp.conf path on bookworm
Date: Mon, 18 Mar 2024 16:55:14 +0000
Message-Id: <20240318165545.3898-6-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.39.2
In-Reply-To: <20240318165545.3898-1-anthony.perard@citrix.com>
References: <20240318165545.3898-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Signed-off-by: Anthony PERARD 
---
 ts-host-install | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/ts-host-install b/ts-host-install
index f79a1beb..61433e64 100755
--- a/ts-host-install
+++ b/ts-host-install
@@ -151,7 +151,13 @@ END
 
     my $ntpserver = get_target_property($ho, 'NtpServer');
     if ($ntpserver) {
-	target_editfile_root($ho, '/etc/ntp.conf', sub {
+        my $ntpconf_path;
+        if ($ho->{Suite} =~ m/lenny|squeeze|wheezy|jessie|stretch|buster/) {
+            $ntpconf_path = '/etc/ntp.conf';
+        } else {
+            $ntpconf_path = '/etc/ntpsec/ntp.conf';
+        }
+	target_editfile_root($ho, $ntpconf_path, sub {
 	    my $done= 0;
 	    while () {
 		if (m/^server\b|^pool\b\s/) {
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 16:55:58 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 16:55:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694946.1084287 (Exim 4.92)
	(envelope-from )
	id 1rmGHG-0003dC-HE; Mon, 18 Mar 2024 16:55:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694946.1084287; Mon, 18 Mar 2024 16:55:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmGHG-0003aJ-7W; Mon, 18 Mar 2024 16:55:58 +0000
Received: by outflank-mailman (input) for mailman id 694946;
 Mon, 18 Mar 2024 16:55:56 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmGHE-0002f9-Lk
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 16:55:56 +0000
Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com
 [2a00:1450:4864:20::330])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 62985079-e548-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 17:55:55 +0100 (CET)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-414612cfd82so2582615e9.2
 for ; Mon, 18 Mar 2024 09:55:55 -0700 (PDT)
Received: from localhost.localdomain
 (cpc92320-cmbg19-2-0-cust35.5-4.cable.virginm.net. [82.13.64.36])
 by smtp.gmail.com with ESMTPSA id
 a18-20020a05600c349200b0041413d11838sm2020141wmq.26.2024.03.18.09.55.53
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 18 Mar 2024 09:55:53 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 62985079-e548-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710780954; x=1711385754; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=JMMRuVEHCIqxXdaks8BW5gt1whiZVVCqeN/v42vNtjo=;
        b=BKgyvtJ5cmmsbfli/EO4wkwbKcuUWtqDpP0vE4vdRjqureIsn23EwWKC0xqBleNOe0
         D6DN6KoZMEL1RJs1ib45W9JNzd27JQqfdwrPSAYNMUmeayZoxn+GWGmQ6vGTN0lBjbQa
         arhaTAIpkam+0SMfBQmBInV7TjJqLXkh2jv1w=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710780954; x=1711385754;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=JMMRuVEHCIqxXdaks8BW5gt1whiZVVCqeN/v42vNtjo=;
        b=PeMXS3jm0o0ozAxyyXFQVMqf+MWN6tffym5r5FZNveN0Gdx8SYnkfuQem1ZHhSKO07
         XkNfaYElK5/H6WNj/SVQn6+fFfXjzT0VF6owZQBojWg/aYIuWp8EJPkp9jj1sTDaxkuG
         xTqGerUMKjjCRoLz21jHa1+tYKxrtp3ka15MndKHhqkxDkd//VywMgeZJWj5J7oXynzI
         xD+UGK9teo5fhh+2PzwMO1pwH3wIqqar95P6s5r6/KUzdLNG5SvrUQQLIm1c0QD/TD9e
         yL7mFVh3Z+dLQo75XEUpA9+O7xkMbSBSv2yHr4TwoSIdN0ZL/8/8h/98TDcA0L+QxDpr
         ee9Q==
X-Gm-Message-State: AOJu0YwzUANptF8K/tk1RDZHUuEa5K3wN5MnPCv4W6eFbkNViafVA2G7
	GZKwT2bHMfzsS9I7EnYwqbWkc779+de5nDJL8J69N/U0yGVHyZZc7ubUIv1eAn5SseRSB41OI89
	f
X-Google-Smtp-Source: AGHT+IF0dBp3wk86BI4hu/16kKuYdAhsJDeyKJ8dVApEQECl5QUZVR6qkeNDEn31Hh7GtksB2LyKvQ==
X-Received: by 2002:a05:600c:5118:b0:414:203:3b70 with SMTP id o24-20020a05600c511800b0041402033b70mr40994wms.28.1710780954475;
        Mon, 18 Mar 2024 09:55:54 -0700 (PDT)
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne 
Subject: [OSSTEST PATCH 04/36] mg-debian-installer-update: Download non-free firmware from new repo.
Date: Mon, 18 Mar 2024 16:55:13 +0000
Message-Id: <20240318165545.3898-5-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.39.2
In-Reply-To: <20240318165545.3898-1-anthony.perard@citrix.com>
References: <20240318165545.3898-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Signed-off-by: Anthony PERARD 
---
 mg-debian-installer-update | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/mg-debian-installer-update b/mg-debian-installer-update
index 4fb4bc21..31b8a192 100755
--- a/mg-debian-installer-update
+++ b/mg-debian-installer-update
@@ -105,7 +105,14 @@ if [ "x$dtbs" != "x" ] ; then
     gzip -9nf dtbs.tar
 fi
 
-pfile=$sbase/non-free/binary-$arch/Packages.gz
+case $suite in
+    wheezy|jessie|stretch|buster|bullseye)
+        pfile=$sbase/non-free/binary-$arch/Packages.gz
+        ;;
+    *)
+        # Starting with bookworm, firmware are in a new repo
+        pfile=$sbase/non-free-firmware/binary-$arch/Packages.gz
+esac
 
 fetch $pfile >Packages.gz
 
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 16:56:00 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 16:56:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694947.1084302 (Exim 4.92)
	(envelope-from )
	id 1rmGHH-00044M-QA; Mon, 18 Mar 2024 16:55:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694947.1084302; Mon, 18 Mar 2024 16:55:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmGHH-00042F-KO; Mon, 18 Mar 2024 16:55:59 +0000
Received: by outflank-mailman (input) for mailman id 694947;
 Mon, 18 Mar 2024 16:55:58 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmGHG-0002f9-42
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 16:55:58 +0000
Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com
 [2a00:1450:4864:20::336])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 63843ede-e548-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 17:55:56 +0100 (CET)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-41411421113so7763755e9.1
 for ; Mon, 18 Mar 2024 09:55:56 -0700 (PDT)
Received: from localhost.localdomain
 (cpc92320-cmbg19-2-0-cust35.5-4.cable.virginm.net. [82.13.64.36])
 by smtp.gmail.com with ESMTPSA id
 a18-20020a05600c349200b0041413d11838sm2020141wmq.26.2024.03.18.09.55.55
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 18 Mar 2024 09:55:55 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 63843ede-e548-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710780956; x=1711385756; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=OxOm50nBYccC83Ra9oGTkRkIB7zi8ZuMsoGfL9HmHqU=;
        b=trkv0WHAGgaLUO2UcAApmNANrQo/R5PhuJw6L1ErGdytuhfL/q6va9iyrYZSs9adyz
         /meN5zP0qnJJkfnHhLN6anROemEI89PQVkYIFBb7Vq2AY7TYYf1ydKaJY62HVKKI1qjF
         hDlVnCF+WC7nZVZAXewDi4sB1RaiK40FFQkQo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710780956; x=1711385756;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=OxOm50nBYccC83Ra9oGTkRkIB7zi8ZuMsoGfL9HmHqU=;
        b=bcHuV4yjBw9eNm4kzk9yo+fVBjJO1/hYRqSPYxnpKMYPjiovPD061jUYEWvglFGByQ
         E7lB7iS52eMCytTi4e1rFTNasxU/e9SCpaxf+rXUZW7LHzCIJOLKJxgG/5vPpbuF2tlz
         dzABMl0r8xd0PvwhjB2v2Rznmoi28NHvw1lJwI+3vUg09JqC6g4dcBbHFkicRnD0OGXm
         g4FqLZz2BT5bCsjTLlBcqIffLHqrskeB8rQ4z2msCwe5O7ZXb40F8Qwpztds2JG3LJXT
         K23rzFynxzNs6HvOoAHz7Yc1uN5LWIP9T8Cch762hWqFOLViKv4Sf86Pf0K1Hfso/xKn
         1mzQ==
X-Gm-Message-State: AOJu0Yzsu21iOC9y2WFkimdzVel7keHB+lwsaBIbfGd8IoUrRl8o3NU2
	ipNIELljpSp8xgX47JokFWE6tX9ar6Xyi91iuEFay1egefBP4tQcTqu1fcATiU2TI4OalCT/UUq
	2
X-Google-Smtp-Source: AGHT+IEs0T2xUdzMiCM9wX1GUfZ4c07htL6c5G668fyp8ybNjhYPol7w21y72KJ30v6arccsWDXdqw==
X-Received: by 2002:a05:600c:1554:b0:414:39c:d9f0 with SMTP id f20-20020a05600c155400b00414039cd9f0mr26678wmg.2.1710780955895;
        Mon, 18 Mar 2024 09:55:55 -0700 (PDT)
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne 
Subject: [OSSTEST PATCH 06/36] ts-host-install: fix ntp server setting
Date: Mon, 18 Mar 2024 16:55:15 +0000
Message-Id: <20240318165545.3898-7-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.39.2
In-Reply-To: <20240318165545.3898-1-anthony.perard@citrix.com>
References: <20240318165545.3898-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

The Debian #778564 bug report is still open, the ntp.conf file doesn't
contain the setting from NtpServer after installation, so we still
need to edit ntp.conf on Bookworm.

Signed-off-by: Anthony PERARD 
---
 ts-host-install | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ts-host-install b/ts-host-install
index 61433e64..00277485 100755
--- a/ts-host-install
+++ b/ts-host-install
@@ -161,7 +161,7 @@ END
 	    my $done= 0;
 	    while () {
 		if (m/^server\b|^pool\b\s/) {
-		    if ($ho->{Suite} =~ m/lenny|squeeze|wheezy|jessie|stretch|buster/) {
+		    if ($ho->{Suite} =~ m/lenny|squeeze|wheezy|jessie|stretch|buster|bookworm/) {
 			$_= $done ? "" : "server $ntpserver\n";
 		    } else {
 			m/^server \Q$ntpserver\E\s/ or
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 16:56:01 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 16:56:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694948.1084313 (Exim 4.92)
	(envelope-from )
	id 1rmGHJ-0004OH-2A; Mon, 18 Mar 2024 16:56:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694948.1084313; Mon, 18 Mar 2024 16:56:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmGHI-0004N9-Ty; Mon, 18 Mar 2024 16:56:00 +0000
Received: by outflank-mailman (input) for mailman id 694948;
 Mon, 18 Mar 2024 16:55:58 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmGHG-0002f9-QX
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 16:55:58 +0000
Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com
 [2a00:1450:4864:20::32d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 63e3279b-e548-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 17:55:57 +0100 (CET)
Received: by mail-wm1-x32d.google.com with SMTP id
 5b1f17b1804b1-41409fd8b6bso14346895e9.1
 for ; Mon, 18 Mar 2024 09:55:57 -0700 (PDT)
Received: from localhost.localdomain
 (cpc92320-cmbg19-2-0-cust35.5-4.cable.virginm.net. [82.13.64.36])
 by smtp.gmail.com with ESMTPSA id
 a18-20020a05600c349200b0041413d11838sm2020141wmq.26.2024.03.18.09.55.56
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 18 Mar 2024 09:55:56 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 63e3279b-e548-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710780956; x=1711385756; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=7d1DO2DCVrdoG6T/ipv00ftRwAovDdK3fxHjf8zrTD8=;
        b=ejJI6tXevR/XiucRqH1xDSToXE9OHjoM9wnj9AoM4/iiuDtp3HGGYjfv+aUITzcfOX
         maiEH4okgG4spaI0fOJBWMj2FayBrX6JYnCxqCNgZ7kv0jSxguCn+Jvs5oKw/nRO+iNk
         wN1GD6t8mDRKq/70lh1Xiu1cDT/K3IuwsQNX0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710780956; x=1711385756;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=7d1DO2DCVrdoG6T/ipv00ftRwAovDdK3fxHjf8zrTD8=;
        b=Ugd8orX4ktR5QMIEv7+xlvzEY+UF3yfvaXppyqmuBgSsUthAzFFIG9qPwD4TYRTyBO
         FGW4gU922ha9trFuB4Q5uh/xU6QbPhDuqnfZOvIBYn3t2wOCnb7aD+IoGm//XlelifU/
         /AmxTupLISFLfWgXbpbY7BBinpuMVM5joJPwBMSk1svSca4owZUEp28fnqz7DAe4RmHz
         3cKxpKfd53ar6uvm7X1VfNbc4m2724AOwiy4YYWpYBDxlEBvp4Cg86zeHoBhhQMK51Na
         6VmdkiatT37qpAJkxkHhFH+AMTtVBWPpEvxdU0G2Jp5GlrSKoYWqEXDFb4stW5wCf5ms
         gYYQ==
X-Gm-Message-State: AOJu0YwBY0im651PZrUfFk80h10X+ZEcIPzDKEXt7RlAd1YBvstG1CER
	xVU0/INCL3eN+QqsfN6Yqhu+tUkaolQL+u00I1D9C4PErXqguGxKOnv2FPkNBpF8a4ON4/c0NAo
	G
X-Google-Smtp-Source: AGHT+IF9t9oDq5fjX710cgeERIrlw3KN0gLpL5ONKh1iYfqw9lmCcZ7Kxt8nVO4plWvZdHTwWJBAHg==
X-Received: by 2002:a05:600c:3514:b0:414:102f:27b8 with SMTP id h20-20020a05600c351400b00414102f27b8mr2074437wmq.32.1710780956701;
        Mon, 18 Mar 2024 09:55:56 -0700 (PDT)
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne 
Subject: [OSSTEST PATCH 07/36] ts-host-install: Restart ntp service
Date: Mon, 18 Mar 2024 16:55:16 +0000
Message-Id: <20240318165545.3898-8-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.39.2
In-Reply-To: <20240318165545.3898-1-anthony.perard@citrix.com>
References: <20240318165545.3898-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Otherwise, the change to the config file isn't taken into account
until the next reboot.

Signed-off-by: Anthony PERARD 
---
 ts-host-install | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/ts-host-install b/ts-host-install
index 00277485..43ed9285 100755
--- a/ts-host-install
+++ b/ts-host-install
@@ -152,10 +152,12 @@ END
     my $ntpserver = get_target_property($ho, 'NtpServer');
     if ($ntpserver) {
         my $ntpconf_path;
+        my $ntp_service;
         if ($ho->{Suite} =~ m/lenny|squeeze|wheezy|jessie|stretch|buster/) {
             $ntpconf_path = '/etc/ntp.conf';
         } else {
             $ntpconf_path = '/etc/ntpsec/ntp.conf';
+            $ntp_service = 'ntpsec';
         }
 	target_editfile_root($ho, $ntpconf_path, sub {
 	    my $done= 0;
@@ -173,6 +175,9 @@ END
 	    }
 	    $done or die;
 	});
+	if ($ntp_service) {
+	    target_cmd_root($ho, "service $ntp_service restart");
+	}
     }
 
     host_install_postboot_complete($ho);
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 16:56:01 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 16:56:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694949.1084320 (Exim 4.92)
	(envelope-from )
	id 1rmGHJ-0004UF-N1; Mon, 18 Mar 2024 16:56:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694949.1084320; Mon, 18 Mar 2024 16:56:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmGHJ-0004Rc-AM; Mon, 18 Mar 2024 16:56:01 +0000
Received: by outflank-mailman (input) for mailman id 694949;
 Mon, 18 Mar 2024 16:55:59 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmGHH-0002gq-5j
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 16:55:59 +0000
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com
 [2a00:1450:4864:20::135])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 64ba9c06-e548-11ee-afdd-a90da7624cb6;
 Mon, 18 Mar 2024 17:55:58 +0100 (CET)
Received: by mail-lf1-x135.google.com with SMTP id
 2adb3069b0e04-513cf9bacf1so5801653e87.0
 for ; Mon, 18 Mar 2024 09:55:58 -0700 (PDT)
Received: from localhost.localdomain
 (cpc92320-cmbg19-2-0-cust35.5-4.cable.virginm.net. [82.13.64.36])
 by smtp.gmail.com with ESMTPSA id
 a18-20020a05600c349200b0041413d11838sm2020141wmq.26.2024.03.18.09.55.56
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 18 Mar 2024 09:55:57 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 64ba9c06-e548-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710780958; x=1711385758; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=o+3r6fYzaXB3N/0rnw9Q6VwH4rxmenmG4TwlfD9Xy8Y=;
        b=Q6EO40YoRoSjpW7nAvt7U5MVyD80Rj+W+7bGB8X3c2psbCFmVcHGVOhm2P7tJrqtfC
         fZzM9VD6PvEwo2nwmzMKpm8yJPX2yqzptwOaAQHVO5nz4HTpV/itbJRucPep9Wa/YHpx
         yhkif0uYucWv9JDjJp7CXqhnfsZfenCJcq7rQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710780958; x=1711385758;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=o+3r6fYzaXB3N/0rnw9Q6VwH4rxmenmG4TwlfD9Xy8Y=;
        b=XHb6PTvcL+t6ynPLzF7ixAdgY2JcV4Gm2DFmTRr7BKmb1YrynhKfWLohl0V6eRAaWZ
         HffL440n2cTgPrjtB1xrio6EWn7AK4tNneEGuY5iBcFqUzk+bzIPAdVXoOODPGj5ou1G
         FlANnyEnjpTarln/XQmOskxEcBPT/zGDjR0WMsOOlf06/v0X9BwdSu+kE4uNBfuP0Gp5
         JfSKgBsIiqf1hgwEvf++m1er7/0Lu/CvsDlDN6qrXEmwUdz/CMRhcEdpx9Y7jao5sVb5
         PmHK1gUwk/XiNWV2Pl+VkxwytaO1whKi5ZSo7tp7yh6s4zYcq4C8GPvr8aBISoGqxIOn
         6vdQ==
X-Gm-Message-State: AOJu0YyS0G3DSJ7BBdrUUJOWu3k5KZp3ldT0DfL+aOw3GlCZwl+IXpf4
	1PAeXzVTMzTEYOFDiZHHe//7GE/myMXpT3ARczwBr++OBMsWizev86tYqvYZVG0Wf1dRwMbNpCv
	N
X-Google-Smtp-Source: AGHT+IG1aAUVttrMa2HZLGh7dogu1uNzjjZjmygv0wIoIGvDALRczq05npI7tR7zVopl9a66vng+NQ==
X-Received: by 2002:a05:6512:3b4:b0:513:5a38:f545 with SMTP id v20-20020a05651203b400b005135a38f545mr7392334lfp.62.1710780957661;
        Mon, 18 Mar 2024 09:55:57 -0700 (PDT)
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne 
Subject: [OSSTEST PATCH 08/36] preseed_create: Use new "d-i grub-installer/update-nvram" for UEFI installation
Date: Mon, 18 Mar 2024 16:55:17 +0000
Message-Id: <20240318165545.3898-9-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.39.2
In-Reply-To: <20240318165545.3898-1-anthony.perard@citrix.com>
References: <20240318165545.3898-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Instead of "grub-installer/no-nvram" proposed in Debian bug #789798,
we have "grub-installer/update-nvram". Make use of it, and remove
workaround.

Signed-off-by: Anthony PERARD 
---
 Osstest/Debian.pm | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 9b30a375..7d6f9778 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -1550,13 +1550,17 @@ d-i partman-auto/expert_recipe string					\\
 			lv_name{ dummy }				\\
 		.
 
+# Prevent grub-install from making a new Debian boot entry, so
+# we always reboot from the network.
+d-i grub-installer/update-nvram boolean false
 END
 
-    if (get_host_property($ho, "firmware") eq "uefi") {
-	die unless $ho->{Suite} =~ m/jessie|stretch|buster/;
+    if (get_host_property($ho, "firmware") eq "uefi" &&
+	$ho->{Suite} =~ m/jessie|stretch|buster/) {
 	# Prevent grub-install from making a new Debian boot entry, so
 	# we always reboot from the network. Debian bug #789798 proposes a
-	# properly preseedable solution to this.
+	# properly preseedable solution to this. Implemented with
+	# "grub-installer/update-nvram".
 	preseed_hook_installscript($ho, $sfx,
 		'/usr/lib/base-installer.d/',
 		'osstest-disable-grub-nvram', <<'END');
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 16:56:02 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 16:56:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694950.1084324 (Exim 4.92)
	(envelope-from )
	id 1rmGHK-0004Zi-1P; Mon, 18 Mar 2024 16:56:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694950.1084324; Mon, 18 Mar 2024 16:56:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmGHJ-0004YS-Os; Mon, 18 Mar 2024 16:56:01 +0000
Received: by outflank-mailman (input) for mailman id 694950;
 Mon, 18 Mar 2024 16:56:00 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmGHI-0002gq-5s
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 16:56:00 +0000
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com
 [2a00:1450:4864:20::32a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 64fec057-e548-11ee-afdd-a90da7624cb6;
 Mon, 18 Mar 2024 17:55:59 +0100 (CET)
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-41412e6b2cfso6571435e9.2
 for ; Mon, 18 Mar 2024 09:55:59 -0700 (PDT)
Received: from localhost.localdomain
 (cpc92320-cmbg19-2-0-cust35.5-4.cable.virginm.net. [82.13.64.36])
 by smtp.gmail.com with ESMTPSA id
 a18-20020a05600c349200b0041413d11838sm2020141wmq.26.2024.03.18.09.55.57
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 18 Mar 2024 09:55:58 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 64fec057-e548-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710780958; x=1711385758; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=grbljEezuAm5ddIqYTUtOOXKigH5i2pAC4iRghVwmV8=;
        b=uFtFhacI1Tirk2+ueChZwlsWpbCfd8EAwBzCp065BpQYj7Zri/Fodo8L1byVGBQCPa
         vucCJRMcu9+M0skDeP6U+D2cJo5DTM9Boh2USyXDjtg6J9yasbG0SQy6b7r4+hWEf8dF
         NnC1d0v7uZHaoYlPiP0l3qauuxoMi4wJtEryA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710780958; x=1711385758;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=grbljEezuAm5ddIqYTUtOOXKigH5i2pAC4iRghVwmV8=;
        b=rMLcIKIs9t6SGhjkSZjCiexoJY0lagmDYw4s+ip4po/5WteMeXYYi5zH+pC9fPd/yP
         m07z8YT7AtTCxE3En+0pGCGkkrErTeoI7lIPfSWqq7Oi6P7I1oEY0OCrhXKoZFjV+vS1
         9ajfnkUR739qEmBuC5oNDSNUSI/9CKXQ0QWCatKxyCLQaHKIh1VNWHZjpJHQjQlNi1Ur
         5qPjkZEusoJLCMWOrYVxVwHfxiUbWsNl94o8zQlXMECGJinoKn/ZyM1bhbRk8raWNDho
         b5LUZ+vkEMM3eJMuVskP6KlZNdOuMrAGtPQymVACEDm1RPjMXKjA25zuZ/MJ8nSGJDq7
         zwSg==
X-Gm-Message-State: AOJu0Yx6L0F9EjKcabJmer3mQUwjoylY+5c0reMf3ktm4KhZKT4w9n1c
	IunjZ75XN7GItb9WFlQRL/Kp2ctNSXmTNWnhd5SRYl0nESuUOFoHWaE0Bh7+57v/kN1ilt7h4lZ
	3
X-Google-Smtp-Source: AGHT+IFcgQCr2cM6JQpN9LZSX9YsTNRBfrJdElRzDqs5E9G5lzKWHqiz3bxuJX78jdQgzxXOg7YuBg==
X-Received: by 2002:a05:600c:4fd1:b0:413:f276:778b with SMTP id o17-20020a05600c4fd100b00413f276778bmr9778329wmq.23.1710780958404;
        Mon, 18 Mar 2024 09:55:58 -0700 (PDT)
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne 
Subject: [OSSTEST PATCH 09/36] preseed_create: osstest-erase-other-disks: workaround creating /dev/sdXD files
Date: Mon, 18 Mar 2024 16:55:18 +0000
Message-Id: <20240318165545.3898-10-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.39.2
In-Reply-To: <20240318165545.3898-1-anthony.perard@citrix.com>
References: <20240318165545.3898-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Sometime, it can happen that the erase-other-disks script fails and
indicate that /dev/sda1 isn't a block device anymore. This happened
when /dev/sda was erased before /dev/sda1. So to avoid this, we will
zero the partitions of ${disk} first, and hopefully the error won't
happen again.

Signed-off-by: Anthony PERARD 
---
 Osstest/Debian.pm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 7d6f9778..36c05551 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -1305,7 +1305,7 @@ for sd in sd hd; do
     udevadm settle
     log "\${sd} devices present after: `echo /dev/\${sd}*`"
 done
-for dev in ${disk}*; do
+for dev in ${disk}?* ${disk}*; do
     zero
 done
 echo ===
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 16:56:03 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 16:56:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694951.1084337 (Exim 4.92)
	(envelope-from )
	id 1rmGHL-00050t-J8; Mon, 18 Mar 2024 16:56:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694951.1084337; Mon, 18 Mar 2024 16:56:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmGHL-0004zE-6j; Mon, 18 Mar 2024 16:56:03 +0000
Received: by outflank-mailman (input) for mailman id 694951;
 Mon, 18 Mar 2024 16:56:01 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmGHJ-0002f9-BO
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 16:56:01 +0000
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com
 [2a00:1450:4864:20::135])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 657dfe6c-e548-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 17:55:59 +0100 (CET)
Received: by mail-lf1-x135.google.com with SMTP id
 2adb3069b0e04-514a8259ec1so719867e87.1
 for ; Mon, 18 Mar 2024 09:55:59 -0700 (PDT)
Received: from localhost.localdomain
 (cpc92320-cmbg19-2-0-cust35.5-4.cable.virginm.net. [82.13.64.36])
 by smtp.gmail.com with ESMTPSA id
 a18-20020a05600c349200b0041413d11838sm2020141wmq.26.2024.03.18.09.55.58
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 18 Mar 2024 09:55:58 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 657dfe6c-e548-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710780959; x=1711385759; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=HskY0/rWAkkufGRUO0YcZLuEXfDnS48xXAIqv0EwLpg=;
        b=vS/4wiK66x/6cLaBRMZXfUvkO/GS0JmziU31NoR+GqY1gasTCaLVimz5j4xHaElAIt
         roz0WVY35ID7XGC7SEvf9xojbHfTlgo8PZ95ouohfDAtWeQsmIXGRUsZSpS6OvT97uTq
         0Z9l45is0QCqqleKesSpDJQ1IxMrNENi1TOJo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710780959; x=1711385759;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=HskY0/rWAkkufGRUO0YcZLuEXfDnS48xXAIqv0EwLpg=;
        b=EC9Dx8fVp4sETflQHtJCLg4xpveV00SyeI64e8+iZKS+l/Bbn62sRjOki9h5pCagwL
         f2Ung7fbB/+uyvE9HV6FjsRoKf/gxXUsgLkoR9pMQkUckX6f5XqOn89e5nkRUD13YD16
         xeCOB603dd/BITIn/74+IC2eG65HaqBo5gBMt913XiGLPqCUfEZrNh01o+mnUU2A2D+1
         e7uqYg/OAdYsBGCGQS582fOQ821dzZVz5aAf3lDbHmrzL7Ay8Q5TzTs0VOq+45QsQKMp
         e4c8EKEycEwOnTk+BFENoMb5mzTHCzfyseEsGlrnSczcNVmynZmaPAkAqCogS3NG2dkX
         4/XA==
X-Gm-Message-State: AOJu0YweOBRDPZAjq1+/4gZMijm/5l9e8OhIdey84AUygi421pyUM20j
	EAVOy4UlBYyOs2/ZaaBYcrNcevAYwt0V/prBgOMc+EDT8ZL3A7fbBKnQuqBSuWbr247i5GoKX02
	H
X-Google-Smtp-Source: AGHT+IHissgjFavvd6I0K4K1XuCGNtvIVz2ecBEftkAlbPre0cCi0ljKz4wdjFPFtf1vPgXDoCXldA==
X-Received: by 2002:ac2:4985:0:b0:513:9f14:8f73 with SMTP id f5-20020ac24985000000b005139f148f73mr8121706lfl.36.1710780959342;
        Mon, 18 Mar 2024 09:55:59 -0700 (PDT)
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne 
Subject: [OSSTEST PATCH 10/36] preseed_create: Workaround fail grub-install on arndale
Date: Mon, 18 Mar 2024 16:55:19 +0000
Message-Id: <20240318165545.3898-11-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.39.2
In-Reply-To: <20240318165545.3898-1-anthony.perard@citrix.com>
References: <20240318165545.3898-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

grub-installer on arndale-* machine fails with Debian Bookworm. It
tries to install "grub-pc" which doesn't exist. Skip installation.

Somehow, cubietruck-* installation works fine.

Signed-off-by: Anthony PERARD 
---
 Osstest/Debian.pm | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 36c05551..98b2fc86 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -1581,6 +1581,14 @@ chmod +x /target/$t
 END
     }
 
+    if ( $ho->{Flags}{'need-uboot-bootscr'} &&
+        $ho->{Suite} =~ m/bookworm/) {
+
+        # grub-installer fails on the arndale machine, it's trying to install
+        # "grub-pc" which doesn't exist. Skip installation.
+        $preseed_file .= "d-i grub-installer/skip boolean true\n";
+    }
+
     $preseed_file .= preseed_hook_cmds();
 
     if ($backports_kernel || $ho->{Flags}{'no-di-kernel'}) {
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 16:56:04 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 16:56:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694952.1084341 (Exim 4.92)
	(envelope-from )
	id 1rmGHM-00056B-7u; Mon, 18 Mar 2024 16:56:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694952.1084341; Mon, 18 Mar 2024 16:56:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmGHL-00053s-MD; Mon, 18 Mar 2024 16:56:03 +0000
Received: by outflank-mailman (input) for mailman id 694952;
 Mon, 18 Mar 2024 16:56:02 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmGHK-0002f9-Ff
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 16:56:02 +0000
Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com
 [2a00:1450:4864:20::330])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 661a90c1-e548-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 17:56:01 +0100 (CET)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-4146172fb7eso2494145e9.1
 for ; Mon, 18 Mar 2024 09:56:01 -0700 (PDT)
Received: from localhost.localdomain
 (cpc92320-cmbg19-2-0-cust35.5-4.cable.virginm.net. [82.13.64.36])
 by smtp.gmail.com with ESMTPSA id
 a18-20020a05600c349200b0041413d11838sm2020141wmq.26.2024.03.18.09.55.59
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 18 Mar 2024 09:55:59 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 661a90c1-e548-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710780960; x=1711385760; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=d6vqIoo60jsb5f3ItIQP3yygc1lD7+80VS35yrYdlSk=;
        b=NBpSb9Zy9fcZf7XOo2paKA3TvdUru2Z273ukor5lUiEr4y/owK2TuwNdO5OV4lOAFE
         ZAhWS7zO9LtUYjkZcMb6V7Tvl0YQ/xRu22JVeACw6X0pUijAWuih8Sf5LGCl39yjlW1E
         AYEezZEt722zY9Ef/YA3tsVYgISjXz0HjZ1q8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710780960; x=1711385760;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=d6vqIoo60jsb5f3ItIQP3yygc1lD7+80VS35yrYdlSk=;
        b=koJqsTHUZZZC5eVYXnmw0PT7RDyvPomWAbSO8EQ6Be6yPDbKp5FnMdAjJdtThZhOnS
         d0g1P85SOIjyksGriuHxVrnIY99ICEgVjLOgS7B+8g21iTydwPejmhGoMNYEeEeNlSjE
         TrfDTkIdG5pNukmLN1pJeHJ6j5T4Gi1rxBZuER1bCZoeviJ5PMtMQCzfTXzng1NoAxuN
         8BypxF03xrVTXYEXEmuQLQNePAFILZRFbyTbXaIB3BUvtqslhnLKkyiM0HgoMSUEJbO1
         Y89tKELwQ1lPzWn9ehXQXfiY5/l0ZjEj1QXn4cbJn9Fc5MDqqOI76yea7C+h7HAN7fom
         pxAw==
X-Gm-Message-State: AOJu0YwZs6pCIskhK/Ef7XtfWDbUe5hYDQbLBSh4m86xL7wLaxsHXtEG
	oGMtL8R1i3TKDfmxkMB84g2i9sAI7YIFO3XiApRbc6N7niiTpKG9WlgJ2s7doQ2E21f2/PYdjuX
	B
X-Google-Smtp-Source: AGHT+IGVmI7hoax2kO6sT8eGLuG8aUxlCuwOu7OpEtCC+15tMFQlCVmk8irXv/63DlcF208QG7thSQ==
X-Received: by 2002:a05:600c:3588:b0:413:160b:fcb2 with SMTP id p8-20020a05600c358800b00413160bfcb2mr6727710wmq.30.1710780960269;
        Mon, 18 Mar 2024 09:56:00 -0700 (PDT)
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne 
Subject: [OSSTEST PATCH 11/36] ts-host-install,preseed_create: Do lvm vgextend at install time
Date: Mon, 18 Mar 2024 16:55:20 +0000
Message-Id: <20240318165545.3898-12-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.39.2
In-Reply-To: <20240318165545.3898-1-anthony.perard@citrix.com>
References: <20240318165545.3898-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

When there's more than one disk, like the "pinot?" machine, the name
assigned to e.g. "sda" may change after a reboot, at least when
installing Debian Bookworm, which is using Linux 6.1.

I believe Linux probes disk controller in parallel and assign "sda"
to the first controller to respond, or something like that, so disk
aren't assigned a name in a predictable order.

So, instead of extending lvm volume group to a new disk on reboot, do
that at install time when we know that lvm is on sda.

Alternatively, we could try to set "d-i partman-auto/disk" with a list
of all disk, but that would mean knowing all the disk before starting
the machine.

This new shell script in /lib/partman/finish.d/ should work in all
debian, so replace the script in ts-host-install by this new one.

Signed-off-by: Anthony PERARD 
---
 Osstest/Debian.pm | 21 +++++++++++++++++++++
 ts-host-install   |  9 ---------
 2 files changed, 21 insertions(+), 9 deletions(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 98b2fc86..14ec2293 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -1312,6 +1312,27 @@ echo ===
 set +e
 ls -l /dev/sd*
 true
+END
+
+    # Extend lvm vg to other disks
+    preseed_hook_installscript($ho, $sfx,
+          '/lib/partman/finish.d', '99extend-vg', <
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 16:56:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694953.1084349 (Exim 4.92)
	(envelope-from )
	id 1rmGHN-0005IJ-CN; Mon, 18 Mar 2024 16:56:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694953.1084349; Mon, 18 Mar 2024 16:56:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmGHM-0005De-NL; Mon, 18 Mar 2024 16:56:04 +0000
Received: by outflank-mailman (input) for mailman id 694953;
 Mon, 18 Mar 2024 16:56:03 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmGHK-0002gq-Ud
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 16:56:02 +0000
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com
 [2a00:1450:4864:20::135])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 670cf8ff-e548-11ee-afdd-a90da7624cb6;
 Mon, 18 Mar 2024 17:56:02 +0100 (CET)
Received: by mail-lf1-x135.google.com with SMTP id
 2adb3069b0e04-513da1c1f26so5002614e87.3
 for ; Mon, 18 Mar 2024 09:56:02 -0700 (PDT)
Received: from localhost.localdomain
 (cpc92320-cmbg19-2-0-cust35.5-4.cable.virginm.net. [82.13.64.36])
 by smtp.gmail.com with ESMTPSA id
 a18-20020a05600c349200b0041413d11838sm2020141wmq.26.2024.03.18.09.56.01
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 18 Mar 2024 09:56:01 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 670cf8ff-e548-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710780962; x=1711385762; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=2v7zAAUJTcHPnQWXPNIf3DNM+jdDTySTxnOrx9fx8gI=;
        b=SEsFMIhNJRYmVzF0aUM05JGCAUoRxpGvFltsmBKxpzd2GqvuEnpNfCC9UF+A0goe7w
         ZxgZJ5Ws7oxo6t0qMnc33c0t6Yr6dWGzPcFBreQWW4jIykiPmhpCsk4s8v5fbuXEdqp5
         Z2ATGOxYNEh2P9BjLF/MXl8n92a9wO02vE1gE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710780962; x=1711385762;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=2v7zAAUJTcHPnQWXPNIf3DNM+jdDTySTxnOrx9fx8gI=;
        b=cfS2Qm5rStoUaDewrQvWU0p4/NKD30uTCvm3X3RD5ycaEe0acyXNGhO13ygFzAqjJy
         a4nB7gOG2eltieZ/6lb1HZGez7eEAlpTbVDD5Kh9w+M9XHHc3xNJnMlnyD0rzeJ7ribV
         DUoGL/54sAvuqlhcLzno2iYGXZ6SQJPs06pOCl0bQ5y2r00KhdMOjOnEjMa8URAR21ky
         Fe5pmUCdzxMOGQn6e/vSbH6A/5QVTd9QntIpAtZlioZUZ/t2Jd5wxxvxCu3FQPGvp7N/
         dzxulO+wsd17rEZP3stSZdm/NLM+G4u4/kq5igIrupHyhUCZUVxOhOyMge2+aF/eELfk
         tu2g==
X-Gm-Message-State: AOJu0Yxo+loR+qmM8Kp9rAI2HNrXSd8XWiAZgmYTzLgfQMXPG7xB4iew
	B2BV56A+my94suYki1wRhJbEqsQY6xMG+pcaiia9KsWMrpKIh0fQDNo6b5yy7nxjg4bQI6gZ4fS
	a
X-Google-Smtp-Source: AGHT+IEVe9Iy8l1iOZhUjc/dwpqS9uIw7e2EYiEnDJrFJCr6GwYqghYVQZd1C0pbnwZcEwEgPhUZCA==
X-Received: by 2002:a05:6512:21cc:b0:513:27a1:24cb with SMTP id d12-20020a05651221cc00b0051327a124cbmr7433132lft.51.1710780961922;
        Mon, 18 Mar 2024 09:56:01 -0700 (PDT)
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne 
Subject: [OSSTEST PATCH 13/36] Disable persistent net generator on Bookworm
Date: Mon, 18 Mar 2024 16:55:22 +0000
Message-Id: <20240318165545.3898-14-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.39.2
In-Reply-To: <20240318165545.3898-1-anthony.perard@citrix.com>
References: <20240318165545.3898-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

This schema doesn't work. Even if the udev rule is there, the name of
the different NIC are different from one boot to the next. On a
machine (sabro*) with 3 different NIC, the name of each interface is
basically random and could take on of three name, "eth[0-2]".

net.ifnames=0 does still mean that we have "eth*" names, but the
generated file "75-persistent-net-generator" doesn't seems to name the
interfaces as expected.

The new predictable network interface names schema seems to work well
enough. The names are still the same after rebooting into Xen, at
least on the few machine tested so far. But, we will change to a "mac"
name policy in a follow-up commit.

Signed-off-by: Anthony PERARD 
---
 Osstest/Debian.pm | 12 +++++++-----
 ts-host-install   |  2 +-
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index cf5a3bd1..102b0246 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -87,10 +87,12 @@ sub debian_boot_setup ($$$$$;$) {
         $kopt .= ' '.$targkopt;
     }
 
-    # https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
-    # In fact these are anything but predictable.  We use the scheme
-    # from Debian jessie and earlier, persistent-net-generator etc.
-    $kopt .= ' net.ifnames=0';
+    if ($ho->{Suite} =~ m/stretch|buster/) {
+        # https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
+        # In fact these are anything but predictable.  We use the scheme
+        # from Debian jessie and earlier, persistent-net-generator etc.
+        $kopt .= ' net.ifnames=0';
+    }
 
     foreach my $hook ($hooks ? @$hooks : ()) {
         my $bo_hook= $hook->{EditBootOptions};
@@ -800,7 +802,7 @@ sub debian_overlays ($$) {
     # network device names', is the default; but it is anything but
     # predictable, so we disable it.  Instead, we restore the
     # 75-persistent-net-generator mechanism from jessie and earlier.
-    $maybe->("overlay-persistent-net") if $ho->{Suite} !~ m/wheezy|jessie/;
+    $maybe->("overlay-persistent-net") if $ho->{Suite} =~ m/stretch|buster/;
 
     $maybe->("overlay-$suite");
     $maybe->($c{OverlayLocal}, 'overlay-local.tar');
diff --git a/ts-host-install b/ts-host-install
index 17a1bf78..88481038 100755
--- a/ts-host-install
+++ b/ts-host-install
@@ -214,7 +214,7 @@ sub setup_netboot_firstboot($) {
     system qw(rm -rf --),"$initrd_overlay.d";
     mkdir "$initrd_overlay.d" or die "$initrd_overlay.d: $!";
 
-    if ($ho->{Suite} !~ m/wheezy|jessie/) {
+    if ($ho->{Suite} =~ m/stretch|buster/) {
 	my @cmd = (qw(cp -dR overlay-persistent-net/.),
 		   "$initrd_overlay.d/.");
 	logm("using persistent-net-generator: @cmd");
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 16:56:07 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 16:56:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694954.1084357 (Exim 4.92)
	(envelope-from )
	id 1rmGHO-0005Uw-OY; Mon, 18 Mar 2024 16:56:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694954.1084357; Mon, 18 Mar 2024 16:56:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmGHN-0005P6-Q9; Mon, 18 Mar 2024 16:56:05 +0000
Received: by outflank-mailman (input) for mailman id 694954;
 Mon, 18 Mar 2024 16:56:03 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmGHL-0002f9-5l
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 16:56:03 +0000
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com
 [2a00:1450:4864:20::136])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 669a38fd-e548-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 17:56:01 +0100 (CET)
Received: by mail-lf1-x136.google.com with SMTP id
 2adb3069b0e04-513cf9bacf1so5801720e87.0
 for ; Mon, 18 Mar 2024 09:56:01 -0700 (PDT)
Received: from localhost.localdomain
 (cpc92320-cmbg19-2-0-cust35.5-4.cable.virginm.net. [82.13.64.36])
 by smtp.gmail.com with ESMTPSA id
 a18-20020a05600c349200b0041413d11838sm2020141wmq.26.2024.03.18.09.56.00
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 18 Mar 2024 09:56:00 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 669a38fd-e548-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710780961; x=1711385761; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=rd9iUaTqxVeuY65CjLGL6cDo2UmB5wPhRHB/vSr/mm0=;
        b=tNh1J3lEzrqY8SlbTejF3KRU7H5V3RAdDfPgeOeiEcCniSLtEJ/D6m7lfgWVGxh5kH
         NLzTfW/XfYQdluRpr9Dvfpq/ZfyYcy/PoWp/kIuMxtfCPMnNJKaj4GdpsRs8JD8GCF0w
         8GjBq0Gc0pZM4EuRyiZWzRdob7VEXcbppvP0Y=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710780961; x=1711385761;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=rd9iUaTqxVeuY65CjLGL6cDo2UmB5wPhRHB/vSr/mm0=;
        b=SNW8B42qZipSA4aXqL2KBcKN2bXARaypmorNtywM3VJJ/oZru8YwGZepDC02RIxNEj
         1M4BlG4Z6gSptiRlYm5M9T8zI4vBXCK6D2CRQVFp66G7ZZx8VE8wafY4pRVVqO7aZXMd
         XOSZ1V69MYGNtkX+HrwDCdJD6cncnWmQFtolE70laqK63Wu/ZW/ujOzX085kdphlDaTf
         86PJFj/Amut6+5me4TLLVllni/emeOvLwV3Q/0YLM0hmLtrHYQTi1ckwJvM4kYUkRhnl
         2jJM/aA+H9Kr43ulIGCre4fcko++Z0sFKqbB0DqbtU3MG+6q9T8aJ65MpRbNkePK8DoE
         hpHw==
X-Gm-Message-State: AOJu0YzIM6FLh4cHr967psuCtN7ovf5q+jCM/AkoS1SYHedIYqznBIvd
	8hVDwekqdNyXixUw/aTvI/wibD6RBHq5kK9+Va+UEy9bh/pxmos/wB5tmN+WCbx5t9BxIZIJoyO
	8
X-Google-Smtp-Source: AGHT+IHlMI0WDpjOGMDmBg0WcpDF0MYnwJqnd2kHpPPrEe/KcP+Vq3g2qp8yYST2nrjesKhVRsX19g==
X-Received: by 2002:ac2:5047:0:b0:512:bf99:7d80 with SMTP id a7-20020ac25047000000b00512bf997d80mr7427974lfm.1.1710780961046;
        Mon, 18 Mar 2024 09:56:01 -0700 (PDT)
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne 
Subject: [OSSTEST PATCH 12/36] di_installcmdline_core: Add link_wait_timeout to install cmdline
Date: Mon, 18 Mar 2024 16:55:21 +0000
Message-Id: <20240318165545.3898-13-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.39.2
In-Reply-To: <20240318165545.3898-1-anthony.perard@citrix.com>
References: <20240318165545.3898-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

The default wait time of 3 seconds isn't always enough get an IP from
the DHCP, give more time to the installer to find a NIC that works.

Signed-off-by: Anthony PERARD 
---
 Osstest/Debian.pm | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 14ec2293..cf5a3bd1 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -723,6 +723,7 @@ sub di_installcmdline_core ($$;@) {
                "hostname=$tho->{Name}",
                "$xopts{PreseedScheme}=$ps_url",
                "netcfg/dhcp_timeout=150",
+               "netcfg/link_wait_timeout=10",
                "netcfg/choose_interface=$netcfg_interface",
                );
 
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 16:56:09 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 16:56:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694955.1084369 (Exim 4.92)
	(envelope-from )
	id 1rmGHQ-0005wC-Lo; Mon, 18 Mar 2024 16:56:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694955.1084369; Mon, 18 Mar 2024 16:56:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmGHP-0005t5-QB; Mon, 18 Mar 2024 16:56:07 +0000
Received: by outflank-mailman (input) for mailman id 694955;
 Mon, 18 Mar 2024 16:56:05 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmGHM-0002gq-Jp
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 16:56:04 +0000
Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com
 [2a00:1450:4864:20::32e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6800ac7f-e548-11ee-afdd-a90da7624cb6;
 Mon, 18 Mar 2024 17:56:04 +0100 (CET)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-4141156f245so7505795e9.2
 for ; Mon, 18 Mar 2024 09:56:04 -0700 (PDT)
Received: from localhost.localdomain
 (cpc92320-cmbg19-2-0-cust35.5-4.cable.virginm.net. [82.13.64.36])
 by smtp.gmail.com with ESMTPSA id
 a18-20020a05600c349200b0041413d11838sm2020141wmq.26.2024.03.18.09.56.02
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 18 Mar 2024 09:56:03 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6800ac7f-e548-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710780963; x=1711385763; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Pq6eeei87hao7bl7kATMciqySzcOcwgBpySkkkByHOs=;
        b=rn7auk2HZy3B9Sy5+rqED9hAN1EyCfJHQxUwvVcWMpzyufxLBeSFescbKS+MjeEpPr
         h5A/U1Ak0DdKbHEKY9wj1SRjGkdMHjZvkH/2oXaYVryZYVkEgic8aI/S/kx3+lSm18h6
         A1oOIfVxP5Pb4U/f/1rf1hJqaFwM+IRLfCQAo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710780963; x=1711385763;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=Pq6eeei87hao7bl7kATMciqySzcOcwgBpySkkkByHOs=;
        b=ZtBPw0MluhC8zV27hWMLFJvvOy+R6P5SpI2piegVDAvpJK3DVkuHyJzbmdt10vdujc
         rUhUAKxWbg52BX1naor927CR86GSCS49QGy/EAo7Zoha32WKjEVHkg6sC57MhtSGPKva
         5NzAzwgNaUUIR3NQ3vZabCji90k37ihEW805vJCfMqTM0hOi5Nl+pxaEo4xrQQ1dw490
         W/cLj1xiCzkb5CZLY4jFekPW73E7Mry3kaRHSdkx8pMKfaRv36M4RKAhEmkaiOsNFT4g
         st5/zcFTIvcwSxgHpcXGFFF1p+Puma7Uxqy9tTKMm3mqOThis8V1w6iQTPpdb9DpXIFk
         CLFg==
X-Gm-Message-State: AOJu0YwNOqHmn4gLIZPOSC0c1Uk0/gs2Fm9jEGK+iuf4/Rt35MDPa+XK
	/gUFLqakByfCfzPU0NWInQGENefoCLPKDGU/p60l8O/REQzZWpTSKlIXDburlEUYWLjVmfUW0Ku
	n
X-Google-Smtp-Source: AGHT+IGgDcQtvTM654d+tmeQwanSCT3po+N15r+1TYDul4GhmRBvO3zeGNYA2qI7rJvbettoAmpKdQ==
X-Received: by 2002:a05:600c:3587:b0:414:37f:26d with SMTP id p7-20020a05600c358700b00414037f026dmr6667536wmq.10.1710780963384;
        Mon, 18 Mar 2024 09:56:03 -0700 (PDT)
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne 
Subject: [OSSTEST PATCH 15/36] ts-xen-build-prep: Change package selection for Bookworm
Date: Mon, 18 Mar 2024 16:55:24 +0000
Message-Id: <20240318165545.3898-16-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.39.2
In-Reply-To: <20240318165545.3898-1-anthony.perard@citrix.com>
References: <20240318165545.3898-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

python-dev:
    It doesn't exist on bookworm, and python2 shouldn't be needed
    anymore.

libsdl-dev:
    On buster this already select "libsdl1.2-dev", but to not change
    buster installation we will only use the new package name on
    Bookworm.

Signed-off-by: Anthony PERARD 
---
 ts-xen-build-prep | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/ts-xen-build-prep b/ts-xen-build-prep
index 547bbc16..48d3fb75 100755
--- a/ts-xen-build-prep
+++ b/ts-xen-build-prep
@@ -200,9 +200,9 @@ sub prep () {
     my @packages = qw(mercurial rsync figlet
                       build-essential bin86 bcc iasl bc
                       flex bison cmake ninja-build meson
-                      libpci-dev libncurses5-dev libssl-dev python-dev
+                      libpci-dev libncurses5-dev libssl-dev
                       libx11-dev git-core uuid-dev gettext gawk
-                      libsdl-dev libyajl-dev libaio-dev libpixman-1-dev
+                      libyajl-dev libaio-dev libpixman-1-dev
                       libglib2.0-dev liblzma-dev pkg-config
                       autoconf automake libtool xsltproc
                       libxml2-utils libxml2-dev
@@ -229,6 +229,12 @@ sub prep () {
         push(@packages, qw(texinfo autopoint libpciaccess-dev));
     }
 
+    if ($ho->{Suite} =~ m/squeeze|wheezy|jessie|stretch|buster/) {
+        push(@packages, qw(python-dev libsdl-dev))
+    } else {
+        push(@packages, qw(libsdl1.2-dev))
+    }
+
     # The in-tree ext4 support in libfsimage can't cope with 64bit ext4 on
     # 32bit build. Use the packaged library.
     if ($ho->{Suite} !~ m/squeeze|wheezy|jessie/) {
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 16:56:10 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 16:56:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694956.1084375 (Exim 4.92)
	(envelope-from )
	id 1rmGHR-0006Bo-HL; Mon, 18 Mar 2024 16:56:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694956.1084375; Mon, 18 Mar 2024 16:56:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmGHQ-00067z-VG; Mon, 18 Mar 2024 16:56:08 +0000
Received: by outflank-mailman (input) for mailman id 694956;
 Mon, 18 Mar 2024 16:56:05 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmGHM-0002f9-Qb
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 16:56:04 +0000
Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com
 [2a00:1450:4864:20::330])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 67824e16-e548-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 17:56:03 +0100 (CET)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-4140edd58c9so10184315e9.2
 for ; Mon, 18 Mar 2024 09:56:03 -0700 (PDT)
Received: from localhost.localdomain
 (cpc92320-cmbg19-2-0-cust35.5-4.cable.virginm.net. [82.13.64.36])
 by smtp.gmail.com with ESMTPSA id
 a18-20020a05600c349200b0041413d11838sm2020141wmq.26.2024.03.18.09.56.02
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 18 Mar 2024 09:56:02 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 67824e16-e548-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710780962; x=1711385762; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=jEUzBm46DKDKIcvqZl7uzOx5U6pv71UqK2TcBX4GGFk=;
        b=h9N8BBsCRGmvBpDRoPOylUJn9KpiAdSIkC+GOlD/6yyPdRjiozWa2JN7Ey2JOtHTDT
         2/Xbc7zepa1/GSkOKdGiIZrA+Fh3JxwgyZUu/yWgKQF+L1FfANO23vrzPt54mPRYXMqC
         sETdIsY1IWxwlePqXgUO850uVE7xxzA8x+HUw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710780962; x=1711385762;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=jEUzBm46DKDKIcvqZl7uzOx5U6pv71UqK2TcBX4GGFk=;
        b=OKpxNWQ2KomxiM3f9HN3pfZj/zgf91o+wHgEC7yrRvAW2xaspjgB+lGY/mb8iYNNdl
         FQt3LH3oiyE8N5gq7lvbgEgyX9bBkIUfLyFPpaX7QrGUnpSy0YWmZJYPuW//XdyUfQB4
         LRA8sLh6POzdGPMK7VeNtu9+Ellp0BbVeIOMXzT8oaIilHhMlfAEYO8qxLrcbeKcJm7g
         UbgkO0J8PhqxQZT5xd0uWk8MJpFfioRJa6ll0W0kY8YhmDRgM0JlHnAVVS/uMdhvP1vM
         UfdDHxBAFHjoh/g5R0nW++M7x5pKDFRwItebHt23efwZNyMI+wqpWekipq5qXNz2NAEN
         zFjQ==
X-Gm-Message-State: AOJu0YwwqCtnznJqRs8vkzweHM+K4PoI5d3PuUBjuc8alz0z1ec85iPI
	zXTUywlUK5BzTXiBV94YIk0rp0FsZnoI3IBn3fPSHaSRVNy4N7WiGwGrFMTRVowLjJcSDXImIEG
	n
X-Google-Smtp-Source: AGHT+IHzbkjiHlHlbmYcOmyi2Ux5us6fmp/TDFt1UIjlqO3csZ1DIXqrVicrgzK5/h4a2vfbgqdK1g==
X-Received: by 2002:a05:600c:16d3:b0:414:a75:7457 with SMTP id l19-20020a05600c16d300b004140a757457mr59490wmn.10.1710780962746;
        Mon, 18 Mar 2024 09:56:02 -0700 (PDT)
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne 
Subject: [OSSTEST PATCH 14/36] preseed_base, ts-host-install: Change NIC NamePolicy to "mac"
Date: Mon, 18 Mar 2024 16:55:23 +0000
Message-Id: <20240318165545.3898-15-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.39.2
In-Reply-To: <20240318165545.3898-1-anthony.perard@citrix.com>
References: <20240318165545.3898-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

On "italia?" machine, the two network interfaces are competing to have
"eno1", base on the "onboard" naming policy. So the name of the
network interface can change between "eno1" and "eth0".

Switching to "mac" should avoid the unpredictable name based on
"onboard" or "slot" policy.

The "mac" naming policy break `vif-bridge` for the "vif*.*" network
interfaces. So we will avoid the "mac" policy if the driver is "vif".
This also have an impact on guest created with ./ts-debian-install, as
they use the initrd from dom0, so the interface in the guest will be
renamed according to default policy (which rename eth0 to enX0).

Signed-off-by: Anthony PERARD 
---
 Osstest/Debian.pm | 22 ++++++++++++++++++++++
 ts-host-install   | 16 ++++++++++++++++
 2 files changed, 38 insertions(+)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 102b0246..31d32d6f 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -962,6 +962,28 @@ cp /$RULESDIR/70-persistent-*.rules /target/$RULESDIR 2>/dev/null || true
 
 END
 
+    if ($ho->{Suite} !~ m/lenny|squeeze|wheezy|jessie|stretch|buster/) {
+        # Always use MAC address in network interface names.
+        #
+        # But keep the default policy if the driver is "vif", which match the
+        # "vif$domid.$idx" interface in dom0, and the interface in domU. This file
+        # is going to be added to dom0's initrd, which is used by some guests
+        # (created with ts-debian-install).
+        preseed_hook_installscript($ho, $sfx,
+            '/usr/lib/base-installer.d/', '05ifnamepolicy', <<'END');
+#!/bin/sh -e
+linkfile=/target/etc/systemd/network/90-eth-mac-policy.link
+mkdir -p `dirname $linkfile`
+cat > $linkfile <{Suite} !~ m/lenny|squeeze|wheezy|jessie|stretch|buster/) {
+        # Switch to more predictale nic name based on mac address, instead of the
+        # policy "onboard" which can try to set the same name ("eno1") to two
+        # differents nic, or "slot". New names are "enx$mac".
+        system_checked(qw(mkdir -p --), "$initrd_overlay.d/lib/systemd/network");
+        file_simple_write_contents
+            ("$initrd_overlay.d/lib/systemd/network/90-eth-mac-policy.link",
+                <
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 16:56:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694957.1084382 (Exim 4.92)
	(envelope-from )
	id 1rmGHT-0006Zc-J5; Mon, 18 Mar 2024 16:56:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694957.1084382; Mon, 18 Mar 2024 16:56:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmGHS-0006V2-Lp; Mon, 18 Mar 2024 16:56:10 +0000
Received: by outflank-mailman (input) for mailman id 694957;
 Mon, 18 Mar 2024 16:56:07 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmGHP-0002gq-I9
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 16:56:07 +0000
Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com
 [2a00:1450:4864:20::332])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 69b58789-e548-11ee-afdd-a90da7624cb6;
 Mon, 18 Mar 2024 17:56:07 +0100 (CET)
Received: by mail-wm1-x332.google.com with SMTP id
 5b1f17b1804b1-4141156f245so7506305e9.2
 for ; Mon, 18 Mar 2024 09:56:07 -0700 (PDT)
Received: from localhost.localdomain
 (cpc92320-cmbg19-2-0-cust35.5-4.cable.virginm.net. [82.13.64.36])
 by smtp.gmail.com with ESMTPSA id
 a18-20020a05600c349200b0041413d11838sm2020141wmq.26.2024.03.18.09.56.05
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 18 Mar 2024 09:56:06 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 69b58789-e548-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710780966; x=1711385766; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=fxXSne1viGno6ujJqAzeYSDYVejkK2lsBexcKCTd9Jg=;
        b=iuOyy86mGh/1HfkVANZ+JsVV865jsEK8Z5V0gDlncrdnzvuRLG/AmPEA5/G4PQdjMe
         EnlfoSWP1Tb8foyBVEHyqHgCl8qHzqMhItXI+JyWdvoyv794w6fM4/Vvef5/dbgxuZiA
         ySs9My/qfwyBOvzZP90UguozVeJ6gplcqt31E=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710780966; x=1711385766;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=fxXSne1viGno6ujJqAzeYSDYVejkK2lsBexcKCTd9Jg=;
        b=pKAJZ5dt+Ks7ifNOufWNZHDoLD2H9zG70jEhkX/GBjkYFxBWnFn8XQevAtDWnyZcvc
         lEI0BRoB6kBwJEK76kgUlYiK2M0v6xKh3o7bIbLBi+00GY3uu69sflCBq7VE7eufgqlV
         2xFE/pE4oW2z8Hd1fY9s/xQVbx2syKJnTKQpJxjOmUzh3MWSK0kQVYpcJU0UQtloz5f7
         8n6gEcqCsE9O4VoOjrnW0Jq7HKhlXrHIuMpGHadMtSN7aifClMQxoM/6XSasy5zb/s4q
         hF8Bh4KHn9IYbyjpjYsCBaLk+LYYxELD7tRkCdxVaaO2NR9c/SACBl0YrU3bF8Ma8vrq
         nOTw==
X-Gm-Message-State: AOJu0YzjIa0aVIWEZmwBwblsbwi+tHWKW/HrQgsPlumP5fHsqHcu2EiW
	+hdCcVcmU+w7yRR5+sXHkleslMN9Z2RWbvUL6MMKV6zjV6Dz8Gud1T8T5NVHr/ZDC6KqXAEQf76
	v
X-Google-Smtp-Source: AGHT+IGts/Clq9c4Y13uCTSoDOBJYRSXE2aoOQ9n3WCapA8Q5lY/5I6/FU2eI66ePGPjgudOWqCimA==
X-Received: by 2002:a05:600c:1912:b0:414:38d:81f with SMTP id j18-20020a05600c191200b00414038d081fmr6836636wmq.29.1710780966410;
        Mon, 18 Mar 2024 09:56:06 -0700 (PDT)
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne 
Subject: [OSSTEST PATCH 18/36] ts-xen-install: remove "libc6-xen" package installation
Date: Mon, 18 Mar 2024 16:55:27 +0000
Message-Id: <20240318165545.3898-19-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.39.2
In-Reply-To: <20240318165545.3898-1-anthony.perard@citrix.com>
References: <20240318165545.3898-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

libc6-xen packaged have been removed from Debian Bookworm.

Signed-off-by: Anthony PERARD 
---
 ts-xen-install | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ts-xen-install b/ts-xen-install
index bf55d4e5..3a913fce 100755
--- a/ts-xen-install
+++ b/ts-xen-install
@@ -64,7 +64,7 @@ sub packages () {
     if ($ho->{Suite} !~ m/lenny|squeeze/) {
         target_install_packages($ho, qw(libfdt1));
     }
-    if ($ho->{Arch} eq 'i386') {
+    if ($ho->{Arch} eq 'i386' && $ho->{Suite} =~ m/wheezy|jessie|stretch|buster/) {
 	target_install_packages($ho, qw(libc6-xen));
     }
     target_install_packages($ho, @{toolstack($ho)->{ExtraPackages}})
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 16:56:14 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 16:56:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694958.1084395 (Exim 4.92)
	(envelope-from )
	id 1rmGHV-0007A9-TR; Mon, 18 Mar 2024 16:56:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694958.1084395; Mon, 18 Mar 2024 16:56:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmGHU-0006yW-SI; Mon, 18 Mar 2024 16:56:12 +0000
Received: by outflank-mailman (input) for mailman id 694958;
 Mon, 18 Mar 2024 16:56:10 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmGHR-0002gq-IH
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 16:56:09 +0000
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com
 [2a00:1450:4864:20::32a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6ae69f0a-e548-11ee-afdd-a90da7624cb6;
 Mon, 18 Mar 2024 17:56:09 +0100 (CET)
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-4140efa16caso10029125e9.0
 for ; Mon, 18 Mar 2024 09:56:09 -0700 (PDT)
Received: from localhost.localdomain
 (cpc92320-cmbg19-2-0-cust35.5-4.cable.virginm.net. [82.13.64.36])
 by smtp.gmail.com with ESMTPSA id
 a18-20020a05600c349200b0041413d11838sm2020141wmq.26.2024.03.18.09.56.07
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 18 Mar 2024 09:56:07 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6ae69f0a-e548-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710780968; x=1711385768; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=TRUCir5QMxWCvauYalwhk7w+cXPi5YqEzZUAMUwLH6w=;
        b=PFOKlsl5ujJpoCHaw2IyubF/EZij9PKYxQWAOqhaivVxxHApqLgD/KnhcCSXN9lMlx
         Xy1lnkdf1tPRGcT/DeLsBz3eVCoBdB0DINF9uFBp6PVd8m3TrbA3XHDRBxa5TtqETDA/
         O/WX7Re7KtqkZZF9FZsLnhCpCr2cTnXVoJyMA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710780968; x=1711385768;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=TRUCir5QMxWCvauYalwhk7w+cXPi5YqEzZUAMUwLH6w=;
        b=bDyi5ZuKlLVRK8ILSh4/99KeelSq8sl7FRNduiPCz75E7PBN2As+fwKTgtJIUzPRlp
         YV8qcGROPIkWO9hOgAIRSu3eFqdREvUqd1+BS86WGUrgC9X2819Y7TmlivTPu0LWSxF3
         7W2JqPkA1F60reYiewUFqPnqp2pJ+CUnRadacVbvsTHH5pVHyipOFvmfB06CwSIoAOXn
         2fMdufylo6c0ReOhIZCVcET8YNtvGNqswnP/RuGOra7/FsO7Gj35Wrj+QhutTQDt1jU7
         VitPpT8mwuUXAZBI9wc3lhvdAfSbVZ4bL2w17iaq07slERFc5dkZO5xfWedms6hvH7b4
         LkSg==
X-Gm-Message-State: AOJu0YwjkVVX33TPC6UR1PSZ6FQ7BVwnkMMORS0ug1/q1p6WqIdzBx4r
	Xz5pO/5gM9cB7vqlyPn5W8tlo5hOpNNMajQnqvtaxKJVOoex3KyxJvGJimFfRK7s0vkNTPKLyMY
	9
X-Google-Smtp-Source: AGHT+IHCSGbNmuTOds0JmXB22ZwHsY5nwpzZhWQQbalycU8NtZvJ6ckR8/JppxSj4dFAsDDGBkJgMg==
X-Received: by 2002:a05:600c:314c:b0:414:1eb:287 with SMTP id h12-20020a05600c314c00b0041401eb0287mr7138883wmo.14.1710780968372;
        Mon, 18 Mar 2024 09:56:08 -0700 (PDT)
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne 
Subject: [OSSTEST PATCH 20/36] overlay-bookworm: 20_linux_xen: Fix XSM entries generation
Date: Mon, 18 Mar 2024 16:55:29 +0000
Message-Id: <20240318165545.3898-21-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.39.2
In-Reply-To: <20240318165545.3898-1-anthony.perard@citrix.com>
References: <20240318165545.3898-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

It turns out that setting $xen_version in linux_entry_xsm() override
$xen_version in the loop over $xen_list. This means that only one
entry per Xen version is going to enable XSM, but all further entries
are going to have "(XSM enabled)" in their titles without enabling
XSM.

When a "xenpolicy-$xen_version" file was found for the current
$xen_version, it would be overwrite $xen_version to add "(XSM
enabled)" to the menu entry title. Once change, the next call to
linux_entry_xsm() would also have this modified $xen_version and would
look for the file "xenpolicy-*(XSM enabled)" and fail.

Signed-off-by: Anthony PERARD 
(upstream commit: https://git.savannah.gnu.org/cgit/grub.git/commit/?id=db1faedccdce3cf83336155a95c04a8db03744c5)
---
 overlay-bookworm/etc/grub.d/20_linux_xen | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/overlay-bookworm/etc/grub.d/20_linux_xen b/overlay-bookworm/etc/grub.d/20_linux_xen
index 3a27fc6f..85593525 100755
--- a/overlay-bookworm/etc/grub.d/20_linux_xen
+++ b/overlay-bookworm/etc/grub.d/20_linux_xen
@@ -102,7 +102,7 @@ linux_entry_xsm ()
 {
   os="$1"
   version="$2"
-  xen_version="$3"
+  entry_xen_version="$3"
   type="$4"
   args="$5"
   xen_args="$6"
@@ -110,27 +110,27 @@ linux_entry_xsm ()
   # If user wants to enable XSM support, make sure there's
   # corresponding policy file.
   if ${xsm} ; then
-      xenpolicy="xenpolicy-$xen_version"
+      xenpolicy="xenpolicy-$entry_xen_version"
       if test ! -e "${xen_dirname}/${xenpolicy}" ; then
 	  return
       fi
       xen_args="$xen_args flask=enforcing"
-      xen_version="$(gettext_printf "%s (XSM enabled)" "$xen_version")"
-      # xen_version is used for messages only; actual file is xen_basename
+      entry_xen_version="$(gettext_printf "%s (XSM enabled)" "$entry_xen_version")"
+      # entry_xen_version is used for messages only; actual file is xen_basename
   fi
   if [ -z "$boot_device_id" ]; then
       boot_device_id="$(grub_get_device_id "${GRUB_DEVICE}")"
   fi
   if [ x$type != xsimple ] ; then
       if [ x$type = xrecovery ] ; then
-	  title="$(gettext_printf "%s, with Xen %s and Linux %s (%s)" "${os}" "${xen_version}" "${version}" "$(gettext "${GRUB_RECOVERY_TITLE}")")"
+	  title="$(gettext_printf "%s, with Xen %s and Linux %s (%s)" "${os}" "${entry_xen_version}" "${version}" "$(gettext "${GRUB_RECOVERY_TITLE}")")"
       elif [ "${type#init-}" != "$type" ] ; then
-	  title="$(gettext_printf "%s, with Xen %s and Linux %s (%s)" "${os}" "${xen_version}" "${version}" "${type#init-}")"
+	  title="$(gettext_printf "%s, with Xen %s and Linux %s (%s)" "${os}" "${entry_xen_version}" "${version}" "${type#init-}")"
       else
-	  title="$(gettext_printf "%s, with Xen %s and Linux %s" "${os}" "${xen_version}" "${version}")"
+	  title="$(gettext_printf "%s, with Xen %s and Linux %s" "${os}" "${entry_xen_version}" "${version}")"
       fi
       replacement_title="$(echo "Advanced options for ${OS}" | sed 's,>,>>,g')>$(echo "$title" | sed 's,>,>>,g')"
-      if [ x"Xen ${xen_version}>$title" = x"$GRUB_ACTUAL_DEFAULT" ]; then
+      if [ x"Xen ${entry_xen_version}>$title" = x"$GRUB_ACTUAL_DEFAULT" ]; then
          quoted="$(echo "$GRUB_ACTUAL_DEFAULT" | grub_quote)"
          title_correction_code="${title_correction_code}if [ \"x\$default\" = '$quoted' ]; then default='$(echo "$replacement_title" | grub_quote)'; fi;"
          grub_warn "$(gettext_printf "Please don't use old title \`%s' for GRUB_DEFAULT, use \`%s' (for versions before 2.00) or \`%s' (for 2.00 or later)" "$GRUB_ACTUAL_DEFAULT" "$replacement_title" "gnulinux-advanced-$boot_device_id>gnulinux-$version-$type-$boot_device_id")"
@@ -148,7 +148,7 @@ linux_entry_xsm ()
     prepare_boot_cache="$(prepare_grub_to_access_device ${GRUB_DEVICE_BOOT} | grub_add_tab)"
   fi
   printf '%s\n' "${prepare_boot_cache}" | sed "s/^/$submenu_indentation/"
-  xmessage="$(gettext_printf "Loading Xen %s ..." ${xen_version})"
+  xmessage="$(gettext_printf "Loading Xen %s ..." ${entry_xen_version})"
   lmessage="$(gettext_printf "Loading Linux %s ..." ${version})"
   sed "s/^/$submenu_indentation/" << EOF
 	echo	'$(echo "$xmessage" | grub_quote)'
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 16:56:17 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 16:56:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694960.1084411 (Exim 4.92)
	(envelope-from )
	id 1rmGHZ-00089X-08; Mon, 18 Mar 2024 16:56:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694960.1084411; Mon, 18 Mar 2024 16:56:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmGHY-000818-4H; Mon, 18 Mar 2024 16:56:16 +0000
Received: by outflank-mailman (input) for mailman id 694960;
 Mon, 18 Mar 2024 16:56:13 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmGHU-0002gq-KK
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 16:56:12 +0000
Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com
 [2a00:1450:4864:20::336])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6b5cee19-e548-11ee-afdd-a90da7624cb6;
 Mon, 18 Mar 2024 17:56:09 +0100 (CET)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-4140fcf4d02so9699765e9.2
 for ; Mon, 18 Mar 2024 09:56:09 -0700 (PDT)
Received: from localhost.localdomain
 (cpc92320-cmbg19-2-0-cust35.5-4.cable.virginm.net. [82.13.64.36])
 by smtp.gmail.com with ESMTPSA id
 a18-20020a05600c349200b0041413d11838sm2020141wmq.26.2024.03.18.09.56.08
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 18 Mar 2024 09:56:08 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6b5cee19-e548-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710780969; x=1711385769; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=x31hu31lN3/8MBLeRtOzuN/pstr4iAsaXj67oA29mMM=;
        b=QDF9rrS+Q0GRBzA0qB4B0FSE4WeWxLtTj0MBCJnB5qYDrLZUlzY9JzM65zelP9rx2A
         FFs5pDNLJDMb94agL2MVK9hSwlDkk71JBfmJ4CnxlJKBGDji62xnrlT3DtwAEadCgD3D
         Tk+/CKrLjZ6PROWw0k/29TT1i9hfG7E3HbP/I=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710780969; x=1711385769;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=x31hu31lN3/8MBLeRtOzuN/pstr4iAsaXj67oA29mMM=;
        b=uBODwpH66FtDbp5/SVmdfbWE13da51DKK6FcjBBsu14O9Ct2G3UXGvelewGKutKGXb
         WqK5FIIeVB5Ef+VId0rSXq77J3uU5cMlHy7Esey4uj/Ye6/3u9kMsGiVnSwHZJ96/zIe
         4Lr9jihRPrEAsdWD8nJoXl4BPyY7g2bi6sNRgv1S+SnWoviuAItAXDhF52y6qIS8r9pB
         RTOtF9DGbl/tG6cmzfI9c4L1aJvolKbT0L9Nkb/YxcUNSZqUWyy27n4cvf6dECzh9RdM
         6pTz0mkHCfMKYZqp4RETtZqIUOHheamUnk0HgyKaj0c6Kwow8PJm1sM+xClKi4jz5LGO
         3egg==
X-Gm-Message-State: AOJu0YxDwtaM5u3nku6VILtUxz9OE/ewAjcuRsjk9zknIHrfMU3ZGblq
	UMC9AyztQsuq0AU6GmghL5JtO5SHt58+iPlArMDFmifK8XG0mCr1rS2KoonZBrOJRM3UvqJkrOd
	j
X-Google-Smtp-Source: AGHT+IFb+ZRklxoef/nwlHBK96uZAbyl0zIIXrk9peG9eD6AT/xjIMfOYyOunlmza/YB/lsbTucYTw==
X-Received: by 2002:a05:600c:4f92:b0:414:101a:fa67 with SMTP id n18-20020a05600c4f9200b00414101afa67mr20261wmq.18.1710780969153;
        Mon, 18 Mar 2024 09:56:09 -0700 (PDT)
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne 
Subject: [OSSTEST PATCH 21/36] ts-xtf-install: Install python symlink
Date: Mon, 18 Mar 2024 16:55:30 +0000
Message-Id: <20240318165545.3898-22-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.39.2
In-Reply-To: <20240318165545.3898-1-anthony.perard@citrix.com>
References: <20240318165545.3898-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

ts-xtf-run does run ./xtf-runner, which run `python` in its shebang.
So install a `python` symlink to `python3`.

Signed-off-by: Anthony PERARD 
---
 ts-xtf-install | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/ts-xtf-install b/ts-xtf-install
index a64fd329..fea737ff 100755
--- a/ts-xtf-install
+++ b/ts-xtf-install
@@ -28,6 +28,11 @@ $whhost ||= 'host';
 
 our $ho= selecthost($whhost);
 
+sub packages () {
+    if ($ho->{Suite} !~ m/wheezy|jessie|stretch|buster/) {
+        target_install_packages($ho, qw(python-is-python3));
+    }
+}
 sub extract () {
     my %distpath;
 
@@ -35,4 +40,5 @@ sub extract () {
                                $r{xtfbuildjob}, \%distpath);
 }
 
+packages();
 extract();
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 16:58:22 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 16:58:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694963.1084434 (Exim 4.92)
	(envelope-from )
	id 1rmGJZ-0004Ir-Eh; Mon, 18 Mar 2024 16:58:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694963.1084434; Mon, 18 Mar 2024 16:58:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmGJZ-0004IP-C6; Mon, 18 Mar 2024 16:58:21 +0000
Received: by outflank-mailman (input) for mailman id 694963;
 Mon, 18 Mar 2024 16:58:19 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmGJX-0004ID-IV
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 16:58:19 +0000
Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com
 [2a00:1450:4864:20::12f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b80143d9-e548-11ee-afdd-a90da7624cb6;
 Mon, 18 Mar 2024 17:58:18 +0100 (CET)
Received: by mail-lf1-x12f.google.com with SMTP id
 2adb3069b0e04-513d212f818so5404519e87.2
 for ; Mon, 18 Mar 2024 09:58:18 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 y24-20020a170906471800b00a46be85684bsm1288358ejq.223.2024.03.18.09.58.17
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 18 Mar 2024 09:58:17 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b80143d9-e548-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710781098; x=1711385898; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=yrU0QqhRFrnpV1OS8+/Gxyvv/Y+9Ge7jCEayRTOxEbY=;
        b=OxEI06BILFXZxzM55uFUmXwR/QzgdDBzfCcOn4ZI6ON7GYmWmUcMpoLMh3yfqMZCtx
         AOkpC6X60IT+mteG3A63Ac7jpBUkXX2Pe+9grq+X+f9ii68KZIEV1TEC3OdZD3Xo7q1U
         ku7YQI/wnNWUt6uNgqdlCUierI7+3lOlHkmJsQ78ceE4m6xbXLevNBHRFWQgPq2+gUiz
         DgqgXTXHxO0pKRHQPjIA3RLjBiBXa10ZaETKPAx+/NW1B6yVnNmYD3Q6QeDzVmcTm9Rl
         AEmCOsg4myyc6DMOfCUyI6+K3L99UwIv7HVKJjLJ7mRbfpC+s1l0pphJIRf6abTFomtj
         lOKw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710781098; x=1711385898;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=yrU0QqhRFrnpV1OS8+/Gxyvv/Y+9Ge7jCEayRTOxEbY=;
        b=nZki3DwRsMqnP31HrOPDjn2XZ+kYOZnYTmfeWTjKplOYns5sGKB+GsRQc3r85Gwz3I
         X7iavv/7GM4rmZx1zqiKvmVzzIWpyNHLjNJHS903MUHNZm8Z3f34ayQIxaxRZiMQqK65
         JYx4/dQlPZ1f6HyQv3ruyxgL7IrgB+KW9XJ9+gjTKpiVLkKtHw6hoUWlNFdLKVZL2/Mp
         6N+PoMLBibuirCYd3D0dTjJDD3uI0i7AZp3kA1HN3RTazBIlWOivyhRtN5LGyeInGMkn
         YtonsDfKNkVXMVDOaTng3xCsKm/H5XzQKAq7S0hSrc/rqcyry/aKnddGZQHBJQGSLJhs
         SiAA==
X-Forwarded-Encrypted: i=1; AJvYcCVhtJjBuA7uqi7USqknu1YtjZDhrP8GJf+9wWSg4rhVWBtLuhBnXMCmaXrRZaikcq3D7ibj5K+98akE3hJFWQ7Q2bzKxUOVpWe0jmjTMWY=
X-Gm-Message-State: AOJu0YxiYJ70x7jPH1aoz1MGghQyz/vUIYlpBKeoEiataX5bRI26N8VP
	ncOOWpkGvgbhmEroTElRO44/v6XgUwCIpfGHWr5r5CNJpLzwa6qzPbr3Vl0HUA==
X-Google-Smtp-Source: AGHT+IEfEDJ6vGdSBY1ZgwN/IBSpXAa/NGnO+pHDNB5tPDFRrab3NYZEWtrFkQQbbLBn/bZ3Cb5atA==
X-Received: by 2002:a05:6512:559:b0:513:d3cb:249f with SMTP id h25-20020a056512055900b00513d3cb249fmr7379379lfl.52.1710781097893;
        Mon, 18 Mar 2024 09:58:17 -0700 (PDT)
Message-ID: <6ddc9d8a-20e7-4e4d-ae1a-d2ea01479b38@suse.com>
Date: Mon, 18 Mar 2024 17:58:16 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 03/20] xen/riscv: introduce extenstion support check by
 compiler
Content-Language: en-US
To: Oleksii Kurochko 
Cc: Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 Alistair Francis ,
 Bob Eshleman , Connor Davis
 , xen-devel@lists.xenproject.org
References: 
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 15.03.2024 19:05, Oleksii Kurochko wrote:
> Currently, RISC-V requires two extensions: _zbb and _zihintpause.

Do we really require Zbb already?

> This patch introduces a compiler check to check if these extensions
> are supported.
> Additionally, it introduces the riscv/booting.txt file, which contains
> information about the extensions that should be supported by the platform.
> 
> In the future, a feature will be introduced to check whether an extension
> is supported at runtime.
> However, this feature requires functionality for parsing device tree
> source (DTS), which is not yet available.

Can't you query the CPU for its features?

> --- a/xen/arch/riscv/arch.mk
> +++ b/xen/arch/riscv/arch.mk
> @@ -3,16 +3,22 @@
>  
>  $(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS))
>  
> -CFLAGS-$(CONFIG_RISCV_64) += -mabi=lp64
> +riscv-abi-$(CONFIG_RISCV_32) := -mabi=ilp32
> +riscv-abi-$(CONFIG_RISCV_64) := -mabi=lp64
>  
>  riscv-march-$(CONFIG_RISCV_ISA_RV64G) := rv64g
>  riscv-march-$(CONFIG_RISCV_ISA_C)       := $(riscv-march-y)c
>  
> +extensions := $(call as-insn,$(CC) $(riscv-abi-y) -march=$(riscv-march-y)_zbb,"",_zbb) \
> +              $(call as-insn,$(CC) $(riscv-abi-y) -march=$(riscv-march-y)_zihintpause,"pause",_zihintpause)

Imo you want another helper macro here, where all one needs to pass in is
the extension name (i.e. zbb and zihintpause as per above). That'll also
help with line length, I hope.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Mar 18 16:59:52 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 16:59:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694968.1084443 (Exim 4.92)
	(envelope-from )
	id 1rmGKz-0005MR-OE; Mon, 18 Mar 2024 16:59:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694968.1084443; Mon, 18 Mar 2024 16:59:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmGKz-0005MK-LV; Mon, 18 Mar 2024 16:59:49 +0000
Received: by outflank-mailman (input) for mailman id 694968;
 Mon, 18 Mar 2024 16:59:48 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmGHT-0002f9-RY
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 16:56:11 +0000
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com
 [2a00:1450:4864:20::333])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6bbc4195-e548-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 17:56:10 +0100 (CET)
Received: by mail-wm1-x333.google.com with SMTP id
 5b1f17b1804b1-41412e6b2cfso6573085e9.2
 for ; Mon, 18 Mar 2024 09:56:10 -0700 (PDT)
Received: from localhost.localdomain
 (cpc92320-cmbg19-2-0-cust35.5-4.cable.virginm.net. [82.13.64.36])
 by smtp.gmail.com with ESMTPSA id
 a18-20020a05600c349200b0041413d11838sm2020141wmq.26.2024.03.18.09.56.09
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 18 Mar 2024 09:56:09 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6bbc4195-e548-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710780970; x=1711385770; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=8vSVbaeX7MmaJBk10Hu8Qu/+WIlUUHoLJc0mR6P7msQ=;
        b=TyowofsPCCvt9Ocm+DukG/HMyZBju+IsUIwbNj1JHo+hXq54y3oUDUJ4N5sAcQdiZb
         Fus+Ct6cRW7kip7g/cMr1Q7GZ1vndbc/njqMXzLcGiEDjfeECue1jtZP9bCDHEU26+q/
         x4YVsw5vs3XK6V/EGS8BSVr6XTHzoR+i/O+L4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710780970; x=1711385770;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=8vSVbaeX7MmaJBk10Hu8Qu/+WIlUUHoLJc0mR6P7msQ=;
        b=q2IJD/IKOifQNjaWd6/neWcGTmhyL6hN5Au8Lrep0oNhcbtU2xYnIOA1VEp+zCoqjx
         LcSaPin7sAMnrOCKDj23P2sZvDaTfav0GPVqNXZyB9ezuUNAopnldDJZ8cG22fuctw6s
         qBOFCxizdepKj2S2Ny7W/xpNhx7I5bgwXp1/02vb1YR5nLDDQFlku1f8tNFmio///hOP
         6jz/w7KytQ1vlkydinnvmuHapcLcsinfhycs1bcrA4HpZS76Gkagq47ihcTY8XQHEyMZ
         0k0uSmPSYJ76E6qy+u1ZPJ0W4LrdUxD54KFI57W+8F20x5xRM94gZvXPFd+N0/kecfGs
         F1GQ==
X-Gm-Message-State: AOJu0YxRSRcDVUj3EsDaak5IJ2GZt+4z/VXAP6ZQC/ata+LtwQSMkMBB
	FZfyQtpC5o3k9/fuNWqpqQQPcR8DbmwNChphTwM2tbNpSFkpK8xWM6XR9o2/nCC0kG3PQOVq57C
	N
X-Google-Smtp-Source: AGHT+IHc6tEK6LHXMJQd7rlrLaf6dRX6GOnl9+9ew3zNLSZmb0XPcsMiFQNxTzFeNsTNHVFZ9f5mRw==
X-Received: by 2002:a05:600c:3549:b0:414:523f:90d2 with SMTP id i9-20020a05600c354900b00414523f90d2mr1042549wmq.34.1710780969870;
        Mon, 18 Mar 2024 09:56:09 -0700 (PDT)
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne 
Subject: [OSSTEST PATCH 22/36] setupboot_grub2: Parse arm64 uefi grub verbes
Date: Mon, 18 Mar 2024 16:55:31 +0000
Message-Id: <20240318165545.3898-23-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.39.2
In-Reply-To: <20240318165545.3898-1-anthony.perard@citrix.com>
References: <20240318165545.3898-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

20_linux_xen now uses "xen_hypervisor" and "xen_module" in place of
"multiboot2?" and "module2?" when generating a config file for
arm64-uefi.

Signed-off-by: Anthony PERARD 
---
 Osstest/Debian.pm | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 57f31977..4f07cdef 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -541,7 +541,7 @@ sub setupboot_grub2 ($$$$) {
                 $entry->{Hv}= $1;
                 $entry->{Chainload} = 1;
             }
-            if (m/^\s*multiboot2?\s+(?:\/boot)?\/(xen\-[0-9][-+.0-9a-z]*\S+)\s+(.*)/) {
+            if (m/^\s*(?:multiboot2?|xen_hypervisor)\s+(?:\/boot)?\/(xen\-[0-9][-+.0-9a-z]*\S+)\s+(.*)/) {
                 die unless $entry;
                 $entry->{Hv}= $1;
                 $entry->{Chainload} = 0;
@@ -553,16 +553,16 @@ sub setupboot_grub2 ($$$$) {
                 $entry->{KernVer}= $2;
                 $entry->{KernOpts}= $3;
             }
-            if (m/^\s*module2?\s*(?:\/boot)?\/(vmlinu[xz]-(\S+))\s+(.*)/) {
+            if (m/^\s*(?:module2?|xen_module)\s*(?:\/boot)?\/(vmlinu[xz]-(\S+))\s+(.*)/) {
                 die unless $entry;
                 $entry->{KernDom0}= $1;
                 $entry->{KernVer}= $2;
                 $entry->{KernOpts}= $3;
             }
-            if (m/^\s*module2?\s+(?:--nounzip\s+)*(?:\/boot)?\/(initrd\S+)/) {
+            if (m/^\s*(?:module2?|xen_module)\s+(?:--nounzip\s+)*(?:\/boot)?\/(initrd\S+)/) {
                 $entry->{Initrd}= $1;
             }
-	    if (m/^\s*module2?\s*\/(xenpolicy\S+)/) {
+	    if (m/^\s*(?:module2?|xen_module)\s*\/(xenpolicy\S+)/) {
                 $entry->{Xenpolicy}= $1;
             }
         }
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 17:00:01 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 17:00:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694970.1084454 (Exim 4.92)
	(envelope-from )
	id 1rmGLA-0005jz-V9; Mon, 18 Mar 2024 17:00:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694970.1084454; Mon, 18 Mar 2024 17:00:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmGLA-0005jo-SK; Mon, 18 Mar 2024 17:00:00 +0000
Received: by outflank-mailman (input) for mailman id 694970;
 Mon, 18 Mar 2024 17:00:00 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmGHe-0002gq-ML
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 16:56:22 +0000
Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com
 [2a00:1450:4864:20::329])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 707d6999-e548-11ee-afdd-a90da7624cb6;
 Mon, 18 Mar 2024 17:56:18 +0100 (CET)
Received: by mail-wm1-x329.google.com with SMTP id
 5b1f17b1804b1-41412411622so7208055e9.2
 for ; Mon, 18 Mar 2024 09:56:18 -0700 (PDT)
Received: from localhost.localdomain
 (cpc92320-cmbg19-2-0-cust35.5-4.cable.virginm.net. [82.13.64.36])
 by smtp.gmail.com with ESMTPSA id
 a18-20020a05600c349200b0041413d11838sm2020141wmq.26.2024.03.18.09.56.17
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 18 Mar 2024 09:56:17 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 707d6999-e548-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710780978; x=1711385778; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=lK2cvliT/wP/P+dntCPCcmtTOpkXUdusD9n6Lp67sAk=;
        b=tW3C9f30kdt60lR85/Am5g4IJvgOtwUMgxtW3HxkSCrVDqxiS1fL3SdRPWYpUx8BQJ
         w8iMNpwOxXy1WC5aLbl68W046fIFTwHYb9up60tqSKvy1hQKLp6Dj3aEX1E6LWTPkDpe
         dnq8Afhk7dBuxeF6YwdM/Xp5EAagIpKXOYGy8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710780978; x=1711385778;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=lK2cvliT/wP/P+dntCPCcmtTOpkXUdusD9n6Lp67sAk=;
        b=NFsdnL0Sna9GLYsLXiH4oev/w+40O30M0SubH8hJqSSVK11hb8OQwU2MCv0QhrNhER
         yzgV2503KqKm34cfL7fPNcro0o3JIUwq7aAGx8Cc/sLOgUiiH6o0P8yLV1tXKlwdqz/Y
         a5aJdP4U0ApGqGLFLVN12G+wVHTqQ12PgJsj6mkDmwXTN5IV9VTx1CA94n4XRkdeikQq
         xfOvqIQZEoRsJ9UhezQYT3S1QDxz1Fvu19wAANUZKfpvrOkZq0uGwpRouu0pXz8UykPY
         kQY0eX0CPks82dtbtnQnjBFKNFSDx+TIX8YYyJh+kdwRFglsY62qHYxLcUgdeObF2a4s
         FXSA==
X-Gm-Message-State: AOJu0YwCoTR2dFm+Kt+pCh9igngas1ikJ2zRL3q9Nih5kcmOCCVt2TVC
	/+lGw+8bFu05a7x0Lp2vdeWadShzuvcSt4v20sxpn6ZG59QQpQdPODvqhFZyvbtO0kI/U8lxxX2
	c
X-Google-Smtp-Source: AGHT+IFPTCcS1tWzDisEsT1f0NHG2uvx3CWNDZzxVre6NX5O2l2B7vmONi9UUzvm02FKWwJeRPV7Hw==
X-Received: by 2002:a05:600c:35cd:b0:413:286c:4fcf with SMTP id r13-20020a05600c35cd00b00413286c4fcfmr8561862wmq.32.1710780977800;
        Mon, 18 Mar 2024 09:56:17 -0700 (PDT)
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne 
Subject: [OSSTEST PATCH 31/36] ts-debian-*-install: Replace dots in hostnames by dashs
Date: Mon, 18 Mar 2024 16:55:40 +0000
Message-Id: <20240318165545.3898-32-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.39.2
In-Reply-To: <20240318165545.3898-1-anthony.perard@citrix.com>
References: <20240318165545.3898-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

When running ./ts-debian-di-install, hostname on the command line is
interpreted by the debian installer. As the installer find it to be a
FQDN, it uses part of the hostname as the domain, thus overwriting the
value from the DHCP and from d-i netcfg/get_domain setting (maybe).

But the result is that /etc/resolv.conf contains "search
bookworm.guest.osstest" and can't find an IP for "cache". So the
installation fails.

Also replace ".guest.osstest" in a few other places, even if it
may not be an issue.

Signed-off-by: Anthony PERARD 
---
 ts-debian-di-install  | 4 ++--
 ts-debian-hvm-install | 2 +-
 ts-debian-install     | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/ts-debian-di-install b/ts-debian-di-install
index d84407cf..06c7e1f4 100755
--- a/ts-debian-di-install
+++ b/ts-debian-di-install
@@ -68,8 +68,8 @@ our $ram_mb= $r{arch} =~ m/^armhf/ ? 768 : 2048;
 our $disk_mb= 10000;
 
 our $guesthost= $gn.
-    ($r{"${gn}_suite"} ? ".".$r{"${gn}_suite"} : "").
-    ".guest.osstest";
+    ($r{"${gn}_suite"} ? "-".$r{"${gn}_suite"} : "").
+    "-guest-osstest";
 our $gho;
 
 sub prep () {
diff --git a/ts-debian-hvm-install b/ts-debian-hvm-install
index 60c95b37..99e9acae 100755
--- a/ts-debian-hvm-install
+++ b/ts-debian-hvm-install
@@ -46,7 +46,7 @@ our $ho= selecthost($whhost);
 our $ram_mb;
 our $disk_mb= 10000;
 
-our $guesthost= "$gn.guest.osstest";
+our $guesthost= "$gn-guest-osstest";
 our $gho;
 
 our ($kernel, $ramdisk);
diff --git a/ts-debian-install b/ts-debian-install
index a737bec9..62db487a 100755
--- a/ts-debian-install
+++ b/ts-debian-install
@@ -34,7 +34,7 @@ our $ram_mb=    512;
 our $swap_mb=  1000;
 our $disk_mb= 10000;
 
-our $guesthost= "$gn.guest.osstest";
+our $guesthost= "$gn-guest-osstest";
 our $gho;
 
 sub prep () {
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 17:02:00 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 17:02:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694987.1084463 (Exim 4.92)
	(envelope-from )
	id 1rmGN2-0007af-9y; Mon, 18 Mar 2024 17:01:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694987.1084463; Mon, 18 Mar 2024 17:01:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmGN2-0007aY-6v; Mon, 18 Mar 2024 17:01:56 +0000
Received: by outflank-mailman (input) for mailman id 694987;
 Mon, 18 Mar 2024 17:01:55 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmGHc-0002f9-VH
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 16:56:20 +0000
Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com
 [2a00:1450:4864:20::336])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6f1a7b56-e548-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 17:56:16 +0100 (CET)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-414624a65beso23055e9.3
 for ; Mon, 18 Mar 2024 09:56:16 -0700 (PDT)
Received: from localhost.localdomain
 (cpc92320-cmbg19-2-0-cust35.5-4.cable.virginm.net. [82.13.64.36])
 by smtp.gmail.com with ESMTPSA id
 a18-20020a05600c349200b0041413d11838sm2020141wmq.26.2024.03.18.09.56.14
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 18 Mar 2024 09:56:15 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6f1a7b56-e548-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710780975; x=1711385775; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=UQG3ZS/KBjrX61gOBxTf9yeYNXKYHvM6r6BPx94cQKs=;
        b=fJK4BJ2mYlO7zN2Vef512nm9m3Uqv81Bmis0gqsEdCT4kE5bMgWrgNSslWytVDqwHs
         sGjRLf4T3H5tPZkJfWFB+kTTP76lGH/FwhYEh4PFdhurYexZrshmCvZOUI8phFoPSfrn
         5TIIYAGydoi7jERBCM29O3+T9qjXUwq1LATi4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710780975; x=1711385775;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=UQG3ZS/KBjrX61gOBxTf9yeYNXKYHvM6r6BPx94cQKs=;
        b=XGjMQshHKgBNUBVHcptEV/7rlZuh4s4dwjiPaINy2MLLqm2I50F5VOX3HCkgvDWhsE
         gEdoO8dXJRutNbF5TjLcrOBHW/UoX26wbUMXZJnTbt722ZOtktsdLA/tydUWbB0VCT01
         9ILahsh21pTo4eEyUQqgXfeIDnoDTKgC3IFP9a6ND9peXFIA1Gv44q5azczQctXhpB1k
         oixHYnGk9rlLDQq7ejmESaNFXgF2rBOoYeX45jPaqxwUKAt43uN1VrvjLN+G5csCpbyU
         EonMdt8p0VI/t7Ly59gC8/p+RUrpuEQULERH88ifVJ2yFtKwR0S6JUjsjaHyaIkpBbE6
         BxzQ==
X-Gm-Message-State: AOJu0YzeVLd1NTHCian01YUDdJqDtvI5XS2h8uW/S7mQIJt26AJOZdFm
	EYucUfwDX41xyfKEYvMNfePUvBcz1dmCZTyU1DrF9ZcoL+N+UwEb2x8uGJ+zCUvrrsLRpMG+3NU
	W
X-Google-Smtp-Source: AGHT+IFxPNgilfqdmRvgJO2Paa+HImA+CbRYKWFQN+pgq1nbnYiSEISR9mtJGNc7Acdzf42snqeVxQ==
X-Received: by 2002:a05:600c:3c99:b0:413:fa31:b9f6 with SMTP id bg25-20020a05600c3c9900b00413fa31b9f6mr9694564wmb.2.1710780975478;
        Mon, 18 Mar 2024 09:56:15 -0700 (PDT)
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne 
Subject: [OSSTEST PATCH 29/36] ts-debian-hvm-install: Increase min guest ram size
Date: Mon, 18 Mar 2024 16:55:38 +0000
Message-Id: <20240318165545.3898-30-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.39.2
In-Reply-To: <20240318165545.3898-1-anthony.perard@citrix.com>
References: <20240318165545.3898-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

768 MB for the guest isn't enough anymore for Debian Bookworm, at boot
it print this message:

    Low memory
    ----------

    Entering low memory mode

    This system has relatively little free memory, so it will enter low memory
    mode. Among other things, this means that this program will proceed in English.
    You should set up swap space as soon as possible.
    [Press enter to continue]

So, automatic installation fails. An empiric test shows that the min
was 817M for one particular situation (test-amd64-amd64-xl-qemuu-ovmf-amd64)
but we probably need some leg room, so increase to 1 GB.

Signed-off-by: Anthony PERARD 
---
 ts-debian-hvm-install | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ts-debian-hvm-install b/ts-debian-hvm-install
index 44eb3ab1..60c95b37 100755
--- a/ts-debian-hvm-install
+++ b/ts-debian-hvm-install
@@ -241,7 +241,7 @@ sub prep () {
          if ($host_freemem_mb > $ram_lots * 2 + $ram_minslop) {
               $ram_mb = $ram_lots;
          } else {
-              $ram_mb = 768;
+              $ram_mb = 1024;
          }
     }
     logm("Host has $host_freemem_mb MB free memory, setting guest memory size to $ram_mb MB");
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 17:03:10 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 17:03:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.694996.1084473 (Exim 4.92)
	(envelope-from )
	id 1rmGOD-0008HG-Jw; Mon, 18 Mar 2024 17:03:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 694996.1084473; Mon, 18 Mar 2024 17:03:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmGOD-0008H9-HU; Mon, 18 Mar 2024 17:03:09 +0000
Received: by outflank-mailman (input) for mailman id 694996;
 Mon, 18 Mar 2024 17:03:08 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmGOC-0008Gz-Cy
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 17:03:08 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 640fefa6-e549-11ee-afdd-a90da7624cb6;
 Mon, 18 Mar 2024 18:03:07 +0100 (CET)
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 by support.bugseng.com (Postfix) with ESMTPA id 8D9E84EE0744;
 Mon, 18 Mar 2024 18:03:06 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 640fefa6-e549-11ee-afdd-a90da7624cb6
MIME-Version: 1.0
Date: Mon, 18 Mar 2024 18:03:06 +0100
From: Nicola Vetrini 
To: Jan Beulich 
Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com,
 ayan.kumar.halder@amd.com, consulting@bugseng.com, Julien Grall
 , Bertrand Marquis , Volodymyr
 Babchuk , Andrew Cooper
 , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Wei Liu , xen-devel@lists.xenproject.org
Subject: Re: [XEN PATCH 07/10] xen/efi: efibind: address violations of MISRA C
 Rule 20.7
In-Reply-To: <28eaf480-4ed6-4c1d-9508-63e8d497d530@suse.com>
References: 
 
 <28eaf480-4ed6-4c1d-9508-63e8d497d530@suse.com>
Message-ID: 
X-Sender: nicola.vetrini@bugseng.com
Organization: BUGSENG s.r.l.
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit

On 2024-03-18 17:49, Jan Beulich wrote:
> On 18.03.2024 12:53, Nicola Vetrini wrote:
>> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
>> of macro parameters shall be enclosed in parentheses". Therefore, some
>> macro definitions should gain additional parentheses to ensure that 
>> all
>> current and future users will be safe with respect to expansions that
>> can possibly alter the semantics of the passed-in macro parameter.
>> 
>> No functional change.
>> 
>> Signed-off-by: Nicola Vetrini 
>> ---
>> This file is matched by exclude-list.json, but the fix is rather 
>> trivial
>> and impacts code that in under the scope of MISRA compliance.
> 
> On the same basis as the other change:
> Acked-by: Jan Beulich 
> 

Thanks.

> I wonder though: Where do we draw the line?
> 
> Jan

So far the policy, at least from my side, has been to submit a patch if 
the change is simple enough, to avoid adding a special case that needs 
to be documented and maintained.
In case concerns were raised, propose a deviation and follow up from 
there.

-- 
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)


From xen-devel-bounces@lists.xenproject.org Mon Mar 18 17:05:16 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 17:05:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695006.1084493 (Exim 4.92)
	(envelope-from )
	id 1rmGQG-0001A2-EJ; Mon, 18 Mar 2024 17:05:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695006.1084493; Mon, 18 Mar 2024 17:05:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmGQG-00019p-A0; Mon, 18 Mar 2024 17:05:16 +0000
Received: by outflank-mailman (input) for mailman id 695006;
 Mon, 18 Mar 2024 17:05:14 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmGHa-0002gq-LR
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 16:56:18 +0000
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com
 [2a00:1450:4864:20::32b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6da5e26c-e548-11ee-afdd-a90da7624cb6;
 Mon, 18 Mar 2024 17:56:13 +0100 (CET)
Received: by mail-wm1-x32b.google.com with SMTP id
 5b1f17b1804b1-4146172fb7eso2496295e9.1
 for ; Mon, 18 Mar 2024 09:56:13 -0700 (PDT)
Received: from localhost.localdomain
 (cpc92320-cmbg19-2-0-cust35.5-4.cable.virginm.net. [82.13.64.36])
 by smtp.gmail.com with ESMTPSA id
 a18-20020a05600c349200b0041413d11838sm2020141wmq.26.2024.03.18.09.56.12
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 18 Mar 2024 09:56:12 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6da5e26c-e548-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710780973; x=1711385773; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=WY92DPy9yyYuIttEfcRR/uDeQT6by35Csv+FqYw2GjU=;
        b=eArn6NbJmpAczZpML3zC1abdGqvh97TlQy7hvXiTRprI2FI1TLWSrn3MSaEI8xtt1Y
         aG3tabmiO56vZaSZHgqnYHwHWnbDutJVgtWf5DCuYYonPsASczOw+Q3PQiKrGuvN5U9z
         zJA4mCCTpFqi2oZl+mVJodVo4W4yg4daG/lAM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710780973; x=1711385773;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=WY92DPy9yyYuIttEfcRR/uDeQT6by35Csv+FqYw2GjU=;
        b=v+/z1zd6VsuuqHej1LXAwJ0ndfMqEN1yoFrf08SflUHt1FipEtZh5V6INnwhiEgnCa
         ToI4INZpTIlu9zsSyKlEaIJzGxxKaTjzfxT1pwKvshRYl8zBnqhwrxrdRtfZLHJOl+pJ
         S0Zt3rHz9qeQZssAJ2aHAB8LrVhbWH/6LrV4ftD6hQmPBkfLKH6dbTfh5J314KhrVpry
         UKpXZ8g4qWSskhoXHGsakY4YnrI/2gXfpN0RUo7+PiqZL+h29TF22uOHWuu7/Nr90shg
         IZYBXu/o0xR4K1IR/uia4iRgPEqgWqMZGKgs5nm2ORlc5oFpiv2Tt8p7ujOVqXuR9IME
         1etA==
X-Gm-Message-State: AOJu0YykAogdyXL33AYA8ZqnPL23vpvyjOnUy/4Ap58Ns5h3yITgk1k+
	YAetDG2PB06+7YBx37/vqBc1KZUGLfCtvk8Fo51Q+qkQJk7zkaYi2eX8D5GZq6nq9PTjKbVYicH
	y
X-Google-Smtp-Source: AGHT+IF1ebGGtocd78nErOHJCPWrOnYGjl/ISK3xVKDFteWa2f2at20onqeMu1D6Z9cpnv3faxcFdA==
X-Received: by 2002:a05:600c:19cd:b0:413:1688:2679 with SMTP id u13-20020a05600c19cd00b0041316882679mr7682967wmq.41.1710780972885;
        Mon, 18 Mar 2024 09:56:12 -0700 (PDT)
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne 
Subject: [OSSTEST PATCH 26/36] ts-debian-hvm-install: Allow udev failure in install media
Date: Mon, 18 Mar 2024 16:55:35 +0000
Message-Id: <20240318165545.3898-27-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.39.2
In-Reply-To: <20240318165545.3898-1-anthony.perard@citrix.com>
References: <20240318165545.3898-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Kernel in "debian-12.1.0-amd64-netinst.iso" prevent debian installer
from booting. Early on, it does `udevadm trigger --action=add`, which
fails, the same way as the following runes fails:

$ cat /sys/devices/virtual/input/input2/name
Xen Virtual Keyboard
$ echo add > /sys/devices/virtual/input/input2/uevent
[   25.884403] synth uevent: /devices/virtual/input/input2: failed to send uevent
[   25.916498] input input2: uevent: failed to send synthetic uevent: -12
sh: write error: Cannot allocate memory
$ uname -a
Linux (none) 6.1.0-10-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.38-1 (2023-07-14) x86_64 GNU/Linux

This doesn't looks like a new issue, Debian Buster ISO seems to do the
same thing (early boot command, and error in Linux logs), so it's
probable that now `udevadm trigger --action=add` return an error when
there's a failure.

Bug report in the kernel and in Debian:
    https://bugzilla.kernel.org/show_bug.cgi?id=207695
    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983357

One way to workaround the issue is to remove the vkb device, with xl's
"vkb_device=0", but libvirt doesn't have support for this config
option.

The second option is to edit the installation media, and allow the
failure.

Once installed, the guest boot fine.

Signed-off-by: Anthony PERARD 
---

Notes:
    There's a potential fix for the kernel:
    
    https://lore.kernel.org/xen-devel/20221209142615.33574-1-jandryuk@gmail.com/

 ts-debian-hvm-install | 17 ++++++++++++++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/ts-debian-hvm-install b/ts-debian-hvm-install
index 4deb443e..44eb3ab1 100755
--- a/ts-debian-hvm-install
+++ b/ts-debian-hvm-install
@@ -174,13 +174,14 @@ sub isolinux_cfg () {
 END
 }
 
-sub prepare_initrd ($$$) {
-    my ($initrddir,$newiso,$preseed_file_path) = @_;
+sub prepare_initrd ($$$$) {
+    my ($initrddir,$newiso,$preseed_file_path,$extra_rune) = @_;
     return <<"END";
       rm -rf $initrddir
       mkdir $initrddir
       cd $initrddir
       gzip -d < $newiso$ramdisk | cpio --extract --make-directories --no-absolute-filename
+      $extra_rune
       cp $preseed_file_path preseed.cfg
       find . | cpio -H newc --create | gzip -9 > $newiso$ramdisk
       cd -
@@ -268,7 +269,17 @@ sub prep () {
         target_putfilecontents_root_stash($ho, 10, preseed(),
                                           $preseed_file_path);
 
-        $cmds = prepare_initrd($initrddir,$newiso,$preseed_file_path);
+        my $extra_preseed_rune = '';
+        if ($gsuite =~ m/bookworm/) {
+            # Xen Virtual Keyboard initialisation fails and return ENOMEM
+            # https://bugzilla.kernel.org/show_bug.cgi?id=207695
+            # https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983357
+            $extra_preseed_rune .= <
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 17:05:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695007.1084497 (Exim 4.92)
	(envelope-from )
	id 1rmGQG-0001Gh-Mh; Mon, 18 Mar 2024 17:05:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695007.1084497; Mon, 18 Mar 2024 17:05:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmGQG-0001EE-HK; Mon, 18 Mar 2024 17:05:16 +0000
Received: by outflank-mailman (input) for mailman id 695007;
 Mon, 18 Mar 2024 17:05:16 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmGHf-0002gq-MT
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 16:56:23 +0000
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com
 [2a00:1450:4864:20::331])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 71039d29-e548-11ee-afdd-a90da7624cb6;
 Mon, 18 Mar 2024 17:56:19 +0100 (CET)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-41460512c25so3834195e9.0
 for ; Mon, 18 Mar 2024 09:56:19 -0700 (PDT)
Received: from localhost.localdomain
 (cpc92320-cmbg19-2-0-cust35.5-4.cable.virginm.net. [82.13.64.36])
 by smtp.gmail.com with ESMTPSA id
 a18-20020a05600c349200b0041413d11838sm2020141wmq.26.2024.03.18.09.56.17
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 18 Mar 2024 09:56:18 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 71039d29-e548-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710780978; x=1711385778; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=eqQ7r3Pddk0MZXZyItvqBWjUPFkKGqn9CfcnBLkApoY=;
        b=R82t1X7Hb2BXFNWAyMJJ6OMAY5LcdLg5UIFR6bop7gLZYgsJKqiIDfzrcu/qpao7dO
         RJWj2Ci4mQzcX2fyVGGdMZvBkqBtJFOgYS+1SMZrabpH11imGbAonFoO4DBIasuYVea5
         7b34yvgeGK5UO3btwjZT3lsOfN4K8bpP+X57U=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710780978; x=1711385778;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=eqQ7r3Pddk0MZXZyItvqBWjUPFkKGqn9CfcnBLkApoY=;
        b=tftK2BQMPHwW0Yl/wQGAoOzq1p7IZq+TO0N3cp9RT0tm7nzjl+CqZ4/gM3vWNwsEOx
         S9PJf+ysGBHE5l6PSTFoxDa2ols/g5Fcte8tmjM0UwH3MptKJ773VLw2hzNfwQ8Eg/Qr
         6tiCKDWv/3hDv7qGdeh0PD3XgIBv4kge4due22G4Bemo5YxEQK4M21TqKodRUly3o1YG
         AI29+7prVOuft1orDiQOSvgl/uNGCcvVDiqJHhYowVdUcKVDirqTySLYJV14nCGFcA39
         /nCNvJxDFxmM1xWUnTONusfg131cyhlj6PUvCPYhCC3JdAxxKaD8xfJ+QmoILgvDSIk3
         Hx5w==
X-Gm-Message-State: AOJu0YxZn+G4Z44fatGgrOgJiPWcL62U32a06MVtPPvV5Z2tTWM4G5XF
	UCBGLq0ov2PuUbOgbBDfcQQH2uI00k1rzFYRD6NDCMBZB/98S+TKopJvQ8HfqI9X2m95Oe6VLsU
	/
X-Google-Smtp-Source: AGHT+IH0aBLlGgXNfgE33Vjye1egy0i8b9q5S/eE5gjpBCD8+7jCZaD72rCLuHhv9Ye6YEzpQjWnzQ==
X-Received: by 2002:a05:600c:4f0d:b0:413:e19:337f with SMTP id l13-20020a05600c4f0d00b004130e19337fmr5780538wmq.22.1710780978639;
        Mon, 18 Mar 2024 09:56:18 -0700 (PDT)
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne 
Subject: [OSSTEST PATCH 32/36] ts-xen-install: Fix bridge setup, ask to copy MAC addr
Date: Mon, 18 Mar 2024 16:55:41 +0000
Message-Id: <20240318165545.3898-33-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.39.2
In-Reply-To: <20240318165545.3898-1-anthony.perard@citrix.com>
References: <20240318165545.3898-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

This ask to copy the MAC address from $physif on the bridge.

On Debian Bookworm, when running as a Xen guest for nested tests, the
bridge does get a random MAC address and a different IP address from
DHCP than before setting up the bridge, so the test fails.

Signed-off-by: Anthony PERARD 
---
 ts-xen-install | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/ts-xen-install b/ts-xen-install
index 3a913fce..645d8a79 100755
--- a/ts-xen-install
+++ b/ts-xen-install
@@ -312,6 +312,9 @@ sub ensurebridge () {
     bridge_ports $physif
     bridge_fd 0
     bridge_stp off
+END
+            $bridgex .= <{Suite} !~ m/wheezy|jessie|stretch|buster/);
+    bridge_hw $physif
 END
 	} else {
 	    $iface= $physif;
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 17:05:17 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 17:05:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695005.1084486 (Exim 4.92)
	(envelope-from )
	id 1rmGQG-00016d-4L; Mon, 18 Mar 2024 17:05:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695005.1084486; Mon, 18 Mar 2024 17:05:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmGQG-00016W-1j; Mon, 18 Mar 2024 17:05:16 +0000
Received: by outflank-mailman (input) for mailman id 695005;
 Mon, 18 Mar 2024 17:05:14 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmGHa-0002f9-VQ
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 16:56:18 +0000
Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com
 [2a00:1450:4864:20::132])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6eb2dc19-e548-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 17:56:15 +0100 (CET)
Received: by mail-lf1-x132.google.com with SMTP id
 2adb3069b0e04-513a08f2263so4760043e87.3
 for ; Mon, 18 Mar 2024 09:56:15 -0700 (PDT)
Received: from localhost.localdomain
 (cpc92320-cmbg19-2-0-cust35.5-4.cable.virginm.net. [82.13.64.36])
 by smtp.gmail.com with ESMTPSA id
 a18-20020a05600c349200b0041413d11838sm2020141wmq.26.2024.03.18.09.56.14
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 18 Mar 2024 09:56:14 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6eb2dc19-e548-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710780975; x=1711385775; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=xtK09ACQG18hKcj/CfOcQc0RzN2X4xDIkDXd97Aycqs=;
        b=Gk5sAZEaw880wIbY1Kj2tJpWzvQyyeKnGx1Y25Z0CmbLApnFztF6T/Jrq2Mrt6PmOD
         cVAbFM+TSffyU/zBwSBli5MVGpIT1b2Hp1jcacshWUIko2HSg84V69GBdGCJYbplA5XT
         d5Dqxi4KB2nDEcPl7P8vgozQP9ZE5OVaksvd0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710780975; x=1711385775;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=xtK09ACQG18hKcj/CfOcQc0RzN2X4xDIkDXd97Aycqs=;
        b=W8E+gvaba7QSeU2wnvDelFWW1ID4fx9jig3oCGjWgk3fQKyiSPbaOXs+f4Y+BoDkxP
         Tkh/7zROOQpqWNpL103JDLr/0T354ybDVSzX7Lww4V/iYTEbH59Adoz42JqbvtIliPAe
         mGVltRXqa3fQNXddNfg7iBy/Yv9UmXIdfJEcX9KSb/eFM+MGjmpV68q3ivfWH1pQa76t
         6fqjdxKcC0VUC6v0cHyVKEhdmOkuzi2kvZXuRQQiS7eDxOXmuJdayq7Pb+WjmhkwQrj8
         a2WvoEoKCUFP0XqW5tZsmfrLrtaXObQBiUqHkW1wtT2sRFMex61lBIQWVBREKqzh9rpz
         N3Pw==
X-Gm-Message-State: AOJu0YyG1EQLMp3H7xrAi8nn4QZhN9jWxdzQ5wPHydHZRtQM+rT94hev
	XtJ+ghJXtgoXEl5iSBmvi9saQNtm6gh8YSjROYhdnRFZOULkIWrTSEr/Bm79c4qxD3ZYlEBcFw5
	f
X-Google-Smtp-Source: AGHT+IHtV0W8DH+rETOlSbQbdh4ZKnXrJUKP2bDBbqlzw7bkDvsdXXsor8rNtP7qUqEKb7G7NdbOXw==
X-Received: by 2002:ac2:442e:0:b0:513:db34:7caf with SMTP id w14-20020ac2442e000000b00513db347cafmr61195lfl.17.1710780974782;
        Mon, 18 Mar 2024 09:56:14 -0700 (PDT)
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne 
Subject: [OSSTEST PATCH 28/36] ts-debian-install: keep avoiding to use pygrub
Date: Mon, 18 Mar 2024 16:55:37 +0000
Message-Id: <20240318165545.3898-29-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.39.2
In-Reply-To: <20240318165545.3898-1-anthony.perard@citrix.com>
References: <20240318165545.3898-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

xen-tools commit 83c37b476a75 ("Start all Debian releases since
Stretch (9) with pygrub by default") started to use pygrub by default.
Revert this.

With "pygrub" setting, xen-create-guest fails on armhf, the
80-install-kernel hook fails because it doesn't know about "armhf".

https://github.com/xen-tools/xen-tools/commit/83c37b476a7534c432ecc9941817aeb989677da6

There's "--nopygrub" but that doesn't work due to several issues, so
removing "pygrub" from "distributions.conf" is the only way.

Signed-off-by: Anthony PERARD 
---
 ts-debian-install | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/ts-debian-install b/ts-debian-install
index c42e8a37..a737bec9 100755
--- a/ts-debian-install
+++ b/ts-debian-install
@@ -78,6 +78,21 @@ sub ginstall () {
             fi
 END
     }
+
+    if ($ho->{Suite} =~ m/bookworm/) {
+        # remove "pygrub" from /etc/xen-tools/distributions.conf
+        # The "--nopygrub" option doesn't work.
+        # https://github.com/xen-tools/xen-tools/issues/67
+        # https://github.com/xen-tools/xen-tools/issues/68
+        target_editfile_root($ho, "/etc/xen-tools/distributions.conf", sub {
+            while (<::EI>) {
+                unless (m/^#/) {
+                    s/ pygrub\b//;
+                }
+                print ::EO or die $!;
+            }
+        });
+    }
     my $cmd = '';
     my $useproxy = $c{DebianMirrorProxy} // $c{HttpProxy};
     $cmd .= <
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 17:05:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695008.1084517 (Exim 4.92)
	(envelope-from )
	id 1rmGQS-00024T-SZ; Mon, 18 Mar 2024 17:05:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695008.1084517; Mon, 18 Mar 2024 17:05:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmGQS-00024J-Nx; Mon, 18 Mar 2024 17:05:28 +0000
Received: by outflank-mailman (input) for mailman id 695008;
 Mon, 18 Mar 2024 17:05:27 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmGHO-0002f9-RL
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 16:56:06 +0000
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com
 [2a00:1450:4864:20::135])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 686d457a-e548-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 17:56:04 +0100 (CET)
Received: by mail-lf1-x135.google.com with SMTP id
 2adb3069b0e04-512bde3d197so3808604e87.0
 for ; Mon, 18 Mar 2024 09:56:04 -0700 (PDT)
Received: from localhost.localdomain
 (cpc92320-cmbg19-2-0-cust35.5-4.cable.virginm.net. [82.13.64.36])
 by smtp.gmail.com with ESMTPSA id
 a18-20020a05600c349200b0041413d11838sm2020141wmq.26.2024.03.18.09.56.03
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 18 Mar 2024 09:56:03 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 686d457a-e548-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710780964; x=1711385764; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=zGc/tAE3LgxqS6yxs5mnzZ81H1ykyZF+fgjzTHt3zAQ=;
        b=Nd7SeoJXvkdESDP60rFSRMmR9KNgA2BYQDVen8y2Hda2mT39d+Q7LiGq/SVJiGQKw0
         ZIvMN/Crj4rTu0TWLSkZHf6575grTYzTFd2ESQEQe3MS/miTFBmaeDy1dEO1cS4rB/1r
         a/H+Rjlh4llPM/v69zR1xEq47cdp294e6HGOA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710780964; x=1711385764;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=zGc/tAE3LgxqS6yxs5mnzZ81H1ykyZF+fgjzTHt3zAQ=;
        b=XmOXhpPnU1edc43N1nj4BZH+rHF9EhP9DyysX5uEH1yaNQMnYC39ynFSk6/WuYiZ6O
         LQmglwagxJew03InhpgVyh2nXSTeqnVDP8FdeQOxeMJ7ST0DcJ1uCeblbpKTXDpiPjMF
         V0u3NYcALtL2Jt1x937cuLyE2tZVo22K6YuesRA9XzULVCYNuapmVP237nFN5zR1qyO/
         9q9Go6sku/dCKwlRBqdFcr+FDmxalj+8kG+oCvk9SFCx5Dg01J/Xu9t00m92nCj0TwkE
         1wduckaCOCOf9f7+bGVCnGP2uOaPCWg3Eo2+PtGocNkl/+QW5DSgh5HduyJo3uXhLs7G
         h79w==
X-Gm-Message-State: AOJu0YxezwlVrj9umP+jm4fuD3KPbyngdQy76fuHIVghV+0ZyIjtm8Xi
	jgwc77R7tFeQbcqPHSMmkvV8vmMeKv0PYHPTDH11y5XUbNIJQR/feL2nLoJtrO2yjqgAa8cyJWE
	S
X-Google-Smtp-Source: AGHT+IHv6ANcOL3/Tor8yfkblZa2vNFikZkiCQfGeZEkPIbXlpNbaAn/WfluD2+T4+nnF2yU4d5yaQ==
X-Received: by 2002:ac2:464c:0:b0:513:e27c:78f0 with SMTP id s12-20020ac2464c000000b00513e27c78f0mr49422lfo.46.1710780964279;
        Mon, 18 Mar 2024 09:56:04 -0700 (PDT)
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne 
Subject: [OSSTEST PATCH 16/36] bl_getmenu_open: Read grub.cfg as root
Date: Mon, 18 Mar 2024 16:55:25 +0000
Message-Id: <20240318165545.3898-17-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.39.2
In-Reply-To: <20240318165545.3898-1-anthony.perard@citrix.com>
References: <20240318165545.3898-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

On bookworm, "/boot/grub/grub.cfg" isn't accessible by user "osstest",
so read the file as user "root".

Signed-off-by: Anthony PERARD 
---
 Osstest/Debian.pm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 31d32d6f..57f31977 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -139,7 +139,7 @@ sub debian_boot_setup ($$$$$;$) {
 
 sub bl_getmenu_open ($$$) {
     my ($ho, $rmenu, $lmenu) = @_;
-    target_getfile($ho, 60, $rmenu, $lmenu);
+    target_getfile_root($ho, 60, $rmenu, $lmenu);
     my $f= new IO::File $lmenu, 'r' or die "$lmenu $?";
     return $f;
 }
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 17:05:41 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 17:05:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695013.1084527 (Exim 4.92)
	(envelope-from )
	id 1rmGQf-0002lN-3z; Mon, 18 Mar 2024 17:05:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695013.1084527; Mon, 18 Mar 2024 17:05:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmGQf-0002lD-0C; Mon, 18 Mar 2024 17:05:41 +0000
Received: by outflank-mailman (input) for mailman id 695013;
 Mon, 18 Mar 2024 17:05:40 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmGHi-0002f9-WF
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 16:56:27 +0000
Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com
 [2a00:1450:4864:20::133])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 716cf32a-e548-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 17:56:19 +0100 (CET)
Received: by mail-lf1-x133.google.com with SMTP id
 2adb3069b0e04-513d599dbabso5033435e87.1
 for ; Mon, 18 Mar 2024 09:56:19 -0700 (PDT)
Received: from localhost.localdomain
 (cpc92320-cmbg19-2-0-cust35.5-4.cable.virginm.net. [82.13.64.36])
 by smtp.gmail.com with ESMTPSA id
 a18-20020a05600c349200b0041413d11838sm2020141wmq.26.2024.03.18.09.56.18
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 18 Mar 2024 09:56:18 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 716cf32a-e548-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710780979; x=1711385779; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Q3vLBOSxqrdW1ZRlzp2JKO4obw5qcJjbVid5cQeTQ14=;
        b=WXwQLoXK73ObfQXEhFAIknmDFXH5xMhZQ+qxUDfEsWdGBnxHXhXvJ0+QMc3Qyry4XI
         67iD0PAx1iOreXMZOfkM2lfBct/PUYKGiwcBXtBM71bkMDUz0BhCGT4M41aCraoXTHbX
         MqcWM96h/+Fh19iU0Sb4cSZ7qzy7jtzwZpqbc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710780979; x=1711385779;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=Q3vLBOSxqrdW1ZRlzp2JKO4obw5qcJjbVid5cQeTQ14=;
        b=Go/pet0TA196x3hRyekhz2kXJFSWkdYqjL82nwqqYx/CzsV8L/oR/aagzh2ueOMwdb
         pUTj0HU80m0fkfUOAI3vYCKCL838wUFXDyfL85bukwqXOadq0boANrfrGpCE4cZiCVcN
         5PAMo4Kw12cu96oYSu2htdEUn6G+iH9K7K1ubcEFTuUNOZd79w2BZHES5ZP4E1GnQ9YC
         5fb74P2kG7YlyPSxVBKElq7Bz1qoyv3gP5lPRsGTtCYRZOCqRynGMZt9zyPDqa9uda1h
         OzOeQ2TqOrMMG3w45646vqPTys5g2FviigB6dviZjoWDepTiSUAtTndaTqbALVKhWcwI
         Ik8g==
X-Gm-Message-State: AOJu0YzwfadnqXIr5X0znizP1yqFLK/6BCKO4Eu12z8UBDy39MZyE4wi
	fo/asEZkXkAPcU+xOT84R8PXqIxR/aPazEaGcjBh5rziM7+xfRkYDtDdQJfucmek1M0zAqZXGQA
	j
X-Google-Smtp-Source: AGHT+IHTjDi3PCaX5GpW4hpbi7vkp6ckj5GyoCXCDwO2h82tEGArbcK7PZeZoQUmIY5Nf4BfEIhO+Q==
X-Received: by 2002:a19:2d5c:0:b0:513:c757:33d9 with SMTP id t28-20020a192d5c000000b00513c75733d9mr44876lft.53.1710780979365;
        Mon, 18 Mar 2024 09:56:19 -0700 (PDT)
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne 
Subject: [OSSTEST PATCH 33/36] make-flight: Keep using buster for L2 guest in nested tests
Date: Mon, 18 Mar 2024 16:55:42 +0000
Message-Id: <20240318165545.3898-34-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.39.2
In-Reply-To: <20240318165545.3898-1-anthony.perard@citrix.com>
References: <20240318165545.3898-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

When starting the installation of the L2 guest, L0 kills L1. Switching
the L2 guest back to Debian Buster works fine, so do that to prevent
regression in the test.

Part of the logs from the host L0:

> domain_crash called from arch/x86/hvm/vmx/vvmx.c:2770
> Domain 3 (vcpu#0) crashed on cpu#4:
> d3v0 vmentry failure (reason 0x80000021): Invalid guest state (2)

Signed-off-by: Anthony PERARD 
---
 make-flight | 15 ++++++++++++++-
 mfi-common  |  5 +++--
 2 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/make-flight b/make-flight
index 155a0c1f..d0c950bc 100755
--- a/make-flight
+++ b/make-flight
@@ -360,6 +360,19 @@ do_hvm_debian_nested_tests () {
     xen-4.3-testing)      return;;
   esac
 
+  local l2_runvar
+  case $guestsuite in
+      bookworm)
+          # Bookworm install image lead to a crash of l1, so keep using
+          # Buster's image.
+          l2_runvar=(l2_suite=buster)
+          l2_runvar+=(l2_image=$(usual_debianhvm_image amd64 buster))
+          ;;
+      *)
+          l2_runvar=(l2_image=$(usual_debianhvm_image amd64))
+          ;;
+  esac
+
   for cpuvendor in amd intel; do
 
     job_create_test test-$xenarch$kern-$dom0arch$qemuu_suffix-nested-$cpuvendor \
@@ -368,7 +381,7 @@ do_hvm_debian_nested_tests () {
             l1_vifmodel='e1000'                                    \
             l1_memsize='3072'                                      \
             l1_enable_nestedhvm='true'                             \
-            l2_image=$(usual_debianhvm_image amd64)                \
+            ${l2_runvar[@]}                                        \
             bios=$bios                                             \
             all_hostflags=$most_hostflags,hvm-$cpuvendor
 
diff --git a/mfi-common b/mfi-common
index 6dc39422..bbe714bf 100644
--- a/mfi-common
+++ b/mfi-common
@@ -547,18 +547,19 @@ job_create_test () {
 
 usual_debianhvm_image () {
   local arch=$1; shift
+  local suite=${1:-$guestsuite}
   if [ -n "$DEBIAN_IMAGE_FILE" ]; then
       echo $DEBIAN_IMAGE_FILE
       return
   fi
-  local file=`getconfig DebianImageFile_${guestsuite}_${arch}`
+  local file=`getconfig DebianImageFile_${suite}_${arch}`
   if [ -n "$file" ]; then
       echo $file
       return
   fi
   local ver=$DEBIAN_IMAGE_VERSION
   if [ -z "$ver" ] ; then
-      ver=`getconfig DebianImageVersion_$guestsuite`
+      ver=`getconfig DebianImageVersion_$suite`
   fi
   echo debian-$ver-$arch-CD-1.iso
 }
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 17:06:33 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 17:06:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695023.1084546 (Exim 4.92)
	(envelope-from )
	id 1rmGRU-00043h-NL; Mon, 18 Mar 2024 17:06:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695023.1084546; Mon, 18 Mar 2024 17:06:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmGRU-00043a-KX; Mon, 18 Mar 2024 17:06:32 +0000
Received: by outflank-mailman (input) for mailman id 695023;
 Mon, 18 Mar 2024 17:06:31 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmGHP-0002f9-QJ
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 16:56:07 +0000
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com
 [2a00:1450:4864:20::333])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6948a70f-e548-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 17:56:06 +0100 (CET)
Received: by mail-wm1-x333.google.com with SMTP id
 5b1f17b1804b1-4140edd58c9so10184745e9.2
 for ; Mon, 18 Mar 2024 09:56:06 -0700 (PDT)
Received: from localhost.localdomain
 (cpc92320-cmbg19-2-0-cust35.5-4.cable.virginm.net. [82.13.64.36])
 by smtp.gmail.com with ESMTPSA id
 a18-20020a05600c349200b0041413d11838sm2020141wmq.26.2024.03.18.09.56.04
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 18 Mar 2024 09:56:04 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6948a70f-e548-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710780965; x=1711385765; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=db9MIu6tq57fxX6+DJjHh0A6dPzIiHMhHEDPZhvZ7xg=;
        b=LkgZXuM1SpBKcsAvh9IeKLlWpMJPnrNprdW7qYCNgwMKo8nUC4cd+6vdRjVcu0p9Cu
         jvfxEoEfd3qSRWTOVXcqpMwj2Ft39yiPeQnpMGOrJCuiqyJUJESHF1jo7j6c2zM7TYHf
         JDlhpx7CFU1Y92RK7jjQ1RHHh5dooNzBLQfCw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710780965; x=1711385765;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=db9MIu6tq57fxX6+DJjHh0A6dPzIiHMhHEDPZhvZ7xg=;
        b=ldhSvICYvvTYJjAyP1poUYQGyGw/LgYHpYIDMcJ/63xqubrmP2j4rKuX6Xh//Lwf/Z
         QjAa3Q87LcpRXFVo+nRglkRXpw8WY8XsRyw/QdBYmNEDCgGjQ39+f69YwNqLvIkIL3A0
         i1RQcZl0iRzwafWjgJS6dfFzCoo4J6aL6ePxPxQQ7Tw09pt4Uk+Aq2oMOHj9spB26pCz
         p55djV9b1mDFtLWCJLacsm/hLeHSONCA3zqe8NVttIqTJQTrf2mZ3h+rdac7Tva2+IOG
         K+sZjX/6tvTyXZ6CjiezispXWiZyLs7ed80z0DGivRsH0XdT6J1A9ll/J+UiTlPoKM4r
         OOWA==
X-Gm-Message-State: AOJu0Yz4CuPJrkBd51H6h3NJr4xoPRIAlnSoJRsZww4vsr1PxNkIcZGY
	jHLSneHQOuUSEtqIZknk+NMpz6SWc1EERTZgyuGK0q4J4z7d3ZU0bCujU6tc6xIroVvYK3EzEuN
	4
X-Google-Smtp-Source: AGHT+IF8FyIuw7act4Lxdk6yYT/LfGC/uC/VONogW1shdNl6St4NFE1wpSNAwaKkYl2tlslm4JPc8g==
X-Received: by 2002:a05:600c:3c8a:b0:414:d95:cc47 with SMTP id bg10-20020a05600c3c8a00b004140d95cc47mr51909wmb.30.1710780965756;
        Mon, 18 Mar 2024 09:56:05 -0700 (PDT)
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne 
Subject: [OSSTEST PATCH 17/36] target_editfile: Use the same user to retrieve and send
Date: Mon, 18 Mar 2024 16:55:26 +0000
Message-Id: <20240318165545.3898-18-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.39.2
In-Reply-To: <20240318165545.3898-1-anthony.perard@citrix.com>
References: <20240318165545.3898-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

The file "/boot/grub/grub.cfg" on Debian Bookworm isn't accessible
from the "osstest" user, but target_editfile_root() tries to grab the
file as "osstest" then edit it as "root.

Change teditfileex() to use the same $user also to get the file. This
will fix ts-examine-serial-pre step.

Signed-off-by: Anthony PERARD 
---
 Osstest/TestSupport.pm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 0dded9b2..b86f1d96 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -783,7 +783,7 @@ sub teditfileex {
         logm("editing $rfile to $rdest as $lfile".'{,.new}');
     }
 
-    target_getfile($ho, 60, $rfile, $lfile);
+    tgetfileex($user, $ho, 60, $rfile, $lfile);
     open '::EI', "$lfile" or die "$lfile: $!";
     open '::EO', "> $lfile.new" or die "$lfile.new: $!";
 
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 17:06:34 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 17:06:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695022.1084536 (Exim 4.92)
	(envelope-from )
	id 1rmGRT-0003oz-CI; Mon, 18 Mar 2024 17:06:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695022.1084536; Mon, 18 Mar 2024 17:06:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmGRT-0003og-8a; Mon, 18 Mar 2024 17:06:31 +0000
Received: by outflank-mailman (input) for mailman id 695022;
 Mon, 18 Mar 2024 17:06:29 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmGHW-0002f9-AT
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 16:56:14 +0000
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com
 [2a00:1450:4864:20::331])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6d2c6923-e548-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 17:56:12 +0100 (CET)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-412e784060cso33043785e9.1
 for ; Mon, 18 Mar 2024 09:56:12 -0700 (PDT)
Received: from localhost.localdomain
 (cpc92320-cmbg19-2-0-cust35.5-4.cable.virginm.net. [82.13.64.36])
 by smtp.gmail.com with ESMTPSA id
 a18-20020a05600c349200b0041413d11838sm2020141wmq.26.2024.03.18.09.56.11
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 18 Mar 2024 09:56:11 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6d2c6923-e548-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710780972; x=1711385772; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=SBbVHKd33XiAFp8InfzQ2O67LvEG3SShn6jQ9u4dc00=;
        b=UbQXMy8T5/lG3/oJsZOCFhiRcKMWiuB+InpZZSD8TRPiBLAHDAvcZ+yASgz1V9aYhc
         O0asParQiz/bXyoqt9uSu09ZYFGSANlK6tvmaFA7eu/4piXMaPc7oAu/UCEjydpPfW4O
         VvFDMlxPUQNzQoGFHynQ8CNpVK7425XNq0/6E=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710780972; x=1711385772;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=SBbVHKd33XiAFp8InfzQ2O67LvEG3SShn6jQ9u4dc00=;
        b=TUzlozZ8VwmITNw5bu8tXCwG28YaOKpzvnZaq72L5AduQ2nVRwUX4uRnzqap0rKKDo
         sqtByOFQKRht8pd+C6vvOYMypEos5kobOoUBvRC+5zRn4Mk8gxx1u2nxsHj8YYpzw9pQ
         hBZFufdHMF9zHZhRlzLtTkq6MPuZpth8q+ycfGKr1Yz0al34kGWQRsCV9A8TRPT311Eh
         VPwtixhgEB8KcYCgq4t5HBmq+om/10MvKoP+7FlMqi9tpGdw03VnOYXuoBS6C4Tjfx+F
         DBtXVJSPz/12K6Jqsk4gdiv87xRiPzsEqIBVGuZnjy8WGg9G7HRh4mcH5thzeahhCUUi
         sEPw==
X-Gm-Message-State: AOJu0YydNKSkCxG0JiY77pS47/uep1bm+f/u09blQ9pshPCe1JQZGuWU
	XV13EDYRths3B0hLbQBzXxmCbTRivwIMRGvQ+1JhxWDoF3gxGP2/7/LIqS3WJDfVXF1nZeBE/om
	B
X-Google-Smtp-Source: AGHT+IFfh0fP08THlnhUSXWi3DRrqb/p6ND/O7OrjUcLuB0OwKT4+l4NGeM7Wx5+NVd/NrB1sz7YKw==
X-Received: by 2002:a05:600c:510a:b0:413:f3b2:d807 with SMTP id o10-20020a05600c510a00b00413f3b2d807mr183309wms.3.1710780972262;
        Mon, 18 Mar 2024 09:56:12 -0700 (PDT)
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne 
Subject: [OSSTEST PATCH 25/36] ts-leak-check: add new name for udevd workers
Date: Mon, 18 Mar 2024 16:55:34 +0000
Message-Id: <20240318165545.3898-26-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.39.2
In-Reply-To: <20240318165545.3898-1-anthony.perard@citrix.com>
References: <20240318165545.3898-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

udevd on Bookworm shows as "(udev-worker)" in the process list.
Suppress them.

Signed-off-by: Anthony PERARD 
---
 ts-leak-check | 1 +
 1 file changed, 1 insertion(+)

diff --git a/ts-leak-check b/ts-leak-check
index f3cca8aa..023a945f 100755
--- a/ts-leak-check
+++ b/ts-leak-check
@@ -203,6 +203,7 @@ xenstore /libxl
 
 process .* udevd
 process .* .*/systemd-udevd
+process .* \(udev-worker\)
 process .* /.+/systemd-shim
 
 file /var/run/xenstored/db
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 17:08:20 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 17:08:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695033.1084556 (Exim 4.92)
	(envelope-from )
	id 1rmGT9-0005P9-0g; Mon, 18 Mar 2024 17:08:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695033.1084556; Mon, 18 Mar 2024 17:08:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmGT8-0005P2-UK; Mon, 18 Mar 2024 17:08:14 +0000
Received: by outflank-mailman (input) for mailman id 695033;
 Mon, 18 Mar 2024 17:08:14 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmGHY-0002f9-50
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 16:56:16 +0000
Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com
 [2a00:1450:4864:20::32d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6e3d44a0-e548-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 17:56:14 +0100 (CET)
Received: by mail-wm1-x32d.google.com with SMTP id
 5b1f17b1804b1-4140efa16caso10029935e9.0
 for ; Mon, 18 Mar 2024 09:56:14 -0700 (PDT)
Received: from localhost.localdomain
 (cpc92320-cmbg19-2-0-cust35.5-4.cable.virginm.net. [82.13.64.36])
 by smtp.gmail.com with ESMTPSA id
 a18-20020a05600c349200b0041413d11838sm2020141wmq.26.2024.03.18.09.56.13
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 18 Mar 2024 09:56:13 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6e3d44a0-e548-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710780974; x=1711385774; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=HtBRI5q1ugGBdzMJ59lHIWI9JzPcvWqKCvzTLY9svUQ=;
        b=EE+xHZOAJhdSIh8NINBrfOwg2ccsxY8pxncDazLPiZQUpqUgPck3OEFXN3fjzxR5pi
         KUXJCy+hfpp1QqkF9ERwK+QQsvkQFZCPLPEcHqOn6x03epFLM4tS7gU3wrT+GjBBKJJ5
         +Ne+SGfWQRNinS/0TKKsSPXKtQSO9Y91zFwc8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710780974; x=1711385774;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=HtBRI5q1ugGBdzMJ59lHIWI9JzPcvWqKCvzTLY9svUQ=;
        b=WhDW3fxUIz4b7ymsCgVZkMLCCmzcdyzogZnLbPRqOuQRkgM/AdORPm3j2OpFU1RWpw
         rixjwt8E8y8L8zLsOGriJDoKqby/tRI3x9XIQ8qNcuAsnVinx2yXEjoVrrGpGbi+eicf
         y42D62jzZHWimSAnQHjOvXjMrKC7mfB1dmLcbpDP6lITLMo7TdiZB6b9sMOO+YEWkysB
         sYjD/y+scFR7TbqmiP4bOQFFwH5BGieHMh4Wg/95CBYJVLE8OTiMelwLraGkBA2qM8Kr
         JSwC16Sfla1nPT7uu+d1ju08doeHRrNTgPrIeFjsiQgqlEm5IZmU7AynFuD2jk24rjz3
         oRrg==
X-Gm-Message-State: AOJu0Ywj2Tb9c73QObJiVscowmKcJrkh4F0vH/gVWxkR8o+ZPKHPK7Lx
	czS2RyQfx6LZ0W6La7FmPNcMepQAwdsUPLN+SNK90KP/XEENIL0Ooms09w3ygOEo4OvCrz2cz4y
	d
X-Google-Smtp-Source: AGHT+IFYpwoT1G6V0oSTOM12VU2g8triWdGvu3YXT2EEYJ3eTddOLxI3qxKpKBcLlryHUBMfFt9Z5A==
X-Received: by 2002:a05:600c:a02:b0:414:8d7:8292 with SMTP id z2-20020a05600c0a0200b0041408d78292mr5089597wmp.0.1710780973942;
        Mon, 18 Mar 2024 09:56:13 -0700 (PDT)
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne 
Subject: [OSSTEST PATCH 27/36] ts-debian-fixup: Fix nic names for bookworm
Date: Mon, 18 Mar 2024 16:55:36 +0000
Message-Id: <20240318165545.3898-28-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.39.2
In-Reply-To: <20240318165545.3898-1-anthony.perard@citrix.com>
References: <20240318165545.3898-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

`xen-create-image` doesn't create image for bookworm with a working
network, we need to fix the interface name.

For reference, there's a bug report upstream:
    "UnPredictableNetworkInterfaceNames 'fun' with Bookworm domU: eth0 -> enX0"
    https://github.com/xen-tools/xen-tools/issues/65

Signed-off-by: Anthony PERARD 
---
 ts-debian-fixup | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/ts-debian-fixup b/ts-debian-fixup
index 810b3aba..4cf5f980 100755
--- a/ts-debian-fixup
+++ b/ts-debian-fixup
@@ -142,6 +142,20 @@ sub filesystems () {
 END
 }
 
+sub fix_networking () {
+    return if debian_guest_suite($gho) !~ m/bookworm/;
+
+    # `xen-create-image` doesn't setup network in a way that work with bookworm.
+    # The guest boots with "enX0" interface name, but it only try to setup "eth0".
+    # https://github.com/xen-tools/xen-tools/issues/65
+    target_editfile_root($ho, $mountpoint."/etc/network/interfaces", sub {
+        while (<::EI>) {
+            s/\beth0\b/enX0/g;
+            print ::EO or die $!;
+        }
+    });
+}
+
 sub unmount () {
     guest_umount_lv($ho, $gho);
 }
@@ -243,6 +257,7 @@ target_cmd_root($ho, debian_dhcp_rofs_fix($ho, $mountpoint));
 console();
 randomseed();
 filesystems();
+fix_networking();
 otherfixupcfg();
 writecfg();
 unmount();
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 17:08:45 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 17:08:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695035.1084566 (Exim 4.92)
	(envelope-from )
	id 1rmGTd-00060g-8r; Mon, 18 Mar 2024 17:08:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695035.1084566; Mon, 18 Mar 2024 17:08:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmGTd-00060Z-6J; Mon, 18 Mar 2024 17:08:45 +0000
Received: by outflank-mailman (input) for mailman id 695035;
 Mon, 18 Mar 2024 17:08:44 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmGHh-0002gq-My
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 16:56:25 +0000
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com
 [2a00:1450:4864:20::335])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 71e78ade-e548-11ee-afdd-a90da7624cb6;
 Mon, 18 Mar 2024 17:56:20 +0100 (CET)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-41413f7b2dfso5573675e9.2
 for ; Mon, 18 Mar 2024 09:56:20 -0700 (PDT)
Received: from localhost.localdomain
 (cpc92320-cmbg19-2-0-cust35.5-4.cable.virginm.net. [82.13.64.36])
 by smtp.gmail.com with ESMTPSA id
 a18-20020a05600c349200b0041413d11838sm2020141wmq.26.2024.03.18.09.56.19
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 18 Mar 2024 09:56:19 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 71e78ade-e548-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710780980; x=1711385780; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=kpV3y5oudWDxMbRb7L99Hd6enDOLIEEjJdtB4aBntcc=;
        b=db6ssZCUQVyUol5ukSBeJ5x9Awo95esHs4pLqSqhU9jU+TpuYMVQdynicHUeeib2yD
         /Wei8LCLSTRtimSO9fi71KwPuq08tVm/0/34o1WRanVc9F8abfZ5tzM90OfmcVSjPb9z
         DeISju6cREjBdMUbGSUPcbtOhsu0AufF/clhE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710780980; x=1711385780;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=kpV3y5oudWDxMbRb7L99Hd6enDOLIEEjJdtB4aBntcc=;
        b=iVZj427Lh19cyq2OST1CojWXmxvIWI8vO5BlDOyqgd+noIde5QYeBUSck5S3CXNv6w
         00FfFHbDoCcIvPeXiO27prMquwU8bU/pAsm3bDmtZ6l8zroF9t5YRaYi2jWO29yvkrrl
         JXpw5CkdcatDUbXlI19f8g8FGflsoZTjq1an3ifRh+/dcd0l4J1DvRSsMIjyaj/1FJxI
         6zvbmt5CctUmSUt1MyKWgpka1e9AP/RolbOZ7bh63htlER/i4NZouo1rFXsQPev99/zt
         JsDL5A8G2r4vqduHinye6+9JPXM2nxOVnxqEBBn25PdSb7JAjntq57ERhE179+xSeNHQ
         LrkA==
X-Gm-Message-State: AOJu0Yx4Yd0Q0l9iNcwqbaOQF55FlEZ9XcIIpxM/aCacb0a7ogUV1ZN1
	xncVBdUrfY6hLm7Inx3DU0hCshYRyh261gw46Z/5RATVj3bHaostOlzXmlKZ6Ne4owMryiO94tQ
	j
X-Google-Smtp-Source: AGHT+IG4Cmmc0rd0wtw3C3CQayvvKemrNI+DJdbL7oeBPz+ppHszenmK2b33mLfvVO7fciQ3SPGfDQ==
X-Received: by 2002:a05:600c:5105:b0:412:ed3f:1b4b with SMTP id o5-20020a05600c510500b00412ed3f1b4bmr8596847wms.11.1710780980145;
        Mon, 18 Mar 2024 09:56:20 -0700 (PDT)
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne 
Subject: [OSSTEST PATCH 34/36] Temporally switch "qemu-mainline" branch to Bookworm
Date: Mon, 18 Mar 2024 16:55:43 +0000
Message-Id: <20240318165545.3898-35-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.39.2
In-Reply-To: <20240318165545.3898-1-anthony.perard@citrix.com>
References: <20240318165545.3898-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

QEMU doesn't build on buster anymore.

This should be remove once bookworm is the default suite.

Signed-off-by: Anthony PERARD 
---
 make-flight | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/make-flight b/make-flight
index d0c950bc..6e88cb13 100755
--- a/make-flight
+++ b/make-flight
@@ -49,6 +49,11 @@ case "$xenbranch" in
     ;;
 esac
 
+# QEMU doesn't build on buster anymore, use bookworm for it.
+case "$branch" in
+    qemu-mainline) defsuite="bookworm" ;;
+esac
+
 # Pick default Debian Installer version to correspond to the chosen
 # suite.
 if [ -z "$defdi_version" ] ; then
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 17:09:35 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 17:09:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695045.1084580 (Exim 4.92)
	(envelope-from )
	id 1rmGUP-0006xB-Ih; Mon, 18 Mar 2024 17:09:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695045.1084580; Mon, 18 Mar 2024 17:09:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmGUP-0006x4-Fl; Mon, 18 Mar 2024 17:09:33 +0000
Received: by outflank-mailman (input) for mailman id 695045;
 Mon, 18 Mar 2024 17:09:31 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmGHf-0002f9-VT
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 16:56:23 +0000
Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com
 [2a00:1450:4864:20::12d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 701ff6ff-e548-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 17:56:17 +0100 (CET)
Received: by mail-lf1-x12d.google.com with SMTP id
 2adb3069b0e04-514a8259ec1so720216e87.1
 for ; Mon, 18 Mar 2024 09:56:17 -0700 (PDT)
Received: from localhost.localdomain
 (cpc92320-cmbg19-2-0-cust35.5-4.cable.virginm.net. [82.13.64.36])
 by smtp.gmail.com with ESMTPSA id
 a18-20020a05600c349200b0041413d11838sm2020141wmq.26.2024.03.18.09.56.15
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 18 Mar 2024 09:56:15 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 701ff6ff-e548-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710780977; x=1711385777; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=26YSZw65woreMekmmn6Dys3A1EFQ0HIUWGVRQycHsIA=;
        b=lDt3dD2YEOvV7jYoX+yOtRTa/U9GeAg230Ch6ClUKZNsNcKu93NAgoQIwUffXMAf7F
         eGx8K6DMb9TqwBqUi7S025YsDngwPorPycZtwYD0Q/OIhxRHbyhVPBa/39uYJzLisS7w
         iCdpA13Nm6+FY8V/qe+ItpKztQGDZJA8Wh49o=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710780977; x=1711385777;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=26YSZw65woreMekmmn6Dys3A1EFQ0HIUWGVRQycHsIA=;
        b=IjLgjRTsq1+y4mjjbIN2GUictcxCKdIitqnXi38IVfdDMUdxG/vXluXnoWSvgceCPu
         dBqoxslNlq42mR0AFSoTbq9AQDYX6SwrV4sxUeUgeGuJLaszBiXNWyg5QEb8jvYeFUUT
         9CHI18eSmyhA+RyaftDnE5e9RezQD2PBFieqYPKkuoyIOPwNTtGH/ycYZ+aV1XK9GH04
         l3T8g/7kZIYBOIou66zuYaBdGjtAkftLbo2ow5a2SdF4JcBUIgwluvw1ZfyBrlDe5s+d
         6v8q5PbkJBgTIE5bWYq0S3kW133STwtV/AM1o2s3n94U2kZcyEJ6AUjhtwldrFvzDzEv
         ycuA==
X-Gm-Message-State: AOJu0Yz+cA6vFAhf1XxUlyN0QiFsGyinAz5yyByFwbe0lD9NoBswqhxA
	7DwVs+P5zjBj+i7elll+m3YtFJJEKKio8AE2ZWyGoTA1L5B+paAK4KHn+wNA65G9Qx8ms1gpIcE
	9
X-Google-Smtp-Source: AGHT+IHNvBn6bt5Kf5bfRGG5GOc9SND8iAJEbFJzJD9VDG2AybdY+1uUbYspTd+5fAPaNfFNoJ+wkw==
X-Received: by 2002:a19:3802:0:b0:513:9dba:f32e with SMTP id f2-20020a193802000000b005139dbaf32emr7240835lfa.20.1710780976204;
        Mon, 18 Mar 2024 09:56:16 -0700 (PDT)
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne 
Subject: [OSSTEST PATCH 30/36] bookworm: Extend guest bootloader workaround
Date: Mon, 18 Mar 2024 16:55:39 +0000
Message-Id: <20240318165545.3898-31-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.39.2
In-Reply-To: <20240318165545.3898-1-anthony.perard@citrix.com>
References: <20240318165545.3898-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Signed-off-by: Anthony PERARD 
---
 Osstest/Debian.pm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 68f1be60..3545f3fd 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -1176,7 +1176,7 @@ END
     logm("\$arch is $arch, \$suite is $suite");
     if ($xopts{PvMenuLst} &&
 	$arch =~ /^arm/ &&
-	$suite =~ /wheezy|jessie|stretch|buster|sid/ ) {
+	$suite =~ /wheezy|jessie|stretch|buster|bookworm|sid/ ) {
 
 	# Debian doesn't currently know what bootloader to install in
 	# a Xen guest on ARM. We install pv-grub-menu above which
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 17:10:19 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 17:10:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695053.1084589 (Exim 4.92)
	(envelope-from )
	id 1rmGV8-0000M1-Rl; Mon, 18 Mar 2024 17:10:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695053.1084589; Mon, 18 Mar 2024 17:10:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmGV8-0000Lu-Od; Mon, 18 Mar 2024 17:10:18 +0000
Received: by outflank-mailman (input) for mailman id 695053;
 Mon, 18 Mar 2024 17:10:17 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmGHR-0002f9-TW
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 16:56:10 +0000
Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com
 [2a00:1450:4864:20::32c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6a5c7cb5-e548-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 17:56:08 +0100 (CET)
Received: by mail-wm1-x32c.google.com with SMTP id
 5b1f17b1804b1-4146172fb7eso2495315e9.1
 for ; Mon, 18 Mar 2024 09:56:08 -0700 (PDT)
Received: from localhost.localdomain
 (cpc92320-cmbg19-2-0-cust35.5-4.cable.virginm.net. [82.13.64.36])
 by smtp.gmail.com with ESMTPSA id
 a18-20020a05600c349200b0041413d11838sm2020141wmq.26.2024.03.18.09.56.06
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 18 Mar 2024 09:56:06 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6a5c7cb5-e548-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710780967; x=1711385767; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=CUXPAW3FLPo5B8zg0wxT5OYvS3EjbAdIkCVM/s4WpSc=;
        b=htBNCusyWccfWEdbMN4cXS3nrn8KySBg26OXxRrG3/2RBRtBhU5Zd9Kbeqt3r775OR
         l5xFnK7owEz6auWbaClv7Xwrq7Si1lYoVWsBGo3idXvh9YuAZYL4g8yhy2jG1GL120fa
         jKAQzvzw8YlCN0/n+UwVEKYWqD3c2JEIUoUlY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710780967; x=1711385767;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=CUXPAW3FLPo5B8zg0wxT5OYvS3EjbAdIkCVM/s4WpSc=;
        b=g0wfBbYmlCmuac8XqbKJMYm4z/cNHwGvA+wnr5rDUakKIErDhg6q1rMokz9BwqXR+0
         baAE3qoMRRlx2a2lPEekuQFISBYQuSh6Mzd1X4FGJavdcnKG5fbVmqlmEGWPT1bVqgu1
         wLhQJ7EARStSaYYBRRqZ37Sfj+ifw+JzwqqOzcU7BkcT+85+FsFir2sJqjz5+9zrpSc0
         8NFICuWfTx5/hF/gF9vd0Ox7k5ceqPYYVpKUUGRuAY0+JBcOvEkV7hkstFYbHJXwsTCE
         TTy7cm6POZ3pifep6gyuSmR5/FSe1/FRcPKAZzWry2BI9DqW6x6HqWI1+4moaGm5f3Vi
         vXHg==
X-Gm-Message-State: AOJu0YxHbQ9H/5C21WhflI84AyujH8ggOLJNLpVFGwm6DiiwR6E+GnMd
	f1q5fw8k96ElUo+y21IeKXWIi31QVDEvAAaBBemfL0+JooqS2wNjQa/T6vAYhYWjfjQKvAP0KSG
	c
X-Google-Smtp-Source: AGHT+IEMMYPv3Ei8t1HgtSeYV5cqaFPoLK/jY5+n5K+v01i5UX0uQMizZO6JTdhDa0O1u48GL+n9kA==
X-Received: by 2002:a05:600c:3b87:b0:413:2873:937 with SMTP id n7-20020a05600c3b8700b0041328730937mr5951899wms.35.1710780967257;
        Mon, 18 Mar 2024 09:56:07 -0700 (PDT)
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne 
Subject: [OSSTEST PATCH 19/36] overlay-bookworm: Import grub's 20_linux_xen from Debian Bookworm
Date: Mon, 18 Mar 2024 16:55:28 +0000
Message-Id: <20240318165545.3898-20-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.39.2
In-Reply-To: <20240318165545.3898-1-anthony.perard@citrix.com>
References: <20240318165545.3898-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

This is a copy of the file installed, from grub-common package.

We are going to edit it shortly.

Signed-off-by: Anthony PERARD 
---
 overlay-bookworm/etc/grub.d/20_linux_xen | 379 +++++++++++++++++++++++
 1 file changed, 379 insertions(+)
 create mode 100755 overlay-bookworm/etc/grub.d/20_linux_xen

diff --git a/overlay-bookworm/etc/grub.d/20_linux_xen b/overlay-bookworm/etc/grub.d/20_linux_xen
new file mode 100755
index 00000000..3a27fc6f
--- /dev/null
+++ b/overlay-bookworm/etc/grub.d/20_linux_xen
@@ -0,0 +1,379 @@
+#! /bin/sh
+set -e
+
+# grub-mkconfig helper script.
+# Copyright (C) 2006,2007,2008,2009,2010  Free Software Foundation, Inc.
+#
+# GRUB is free software: you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+#
+# GRUB is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GRUB.  If not, see .
+
+prefix="/usr"
+exec_prefix="/usr"
+datarootdir="/usr/share"
+
+. "$pkgdatadir/grub-mkconfig_lib"
+
+export TEXTDOMAIN=grub
+export TEXTDOMAINDIR="${datarootdir}/locale"
+
+CLASS="--class gnu-linux --class gnu --class os --class xen"
+SUPPORTED_INITS="sysvinit:/lib/sysvinit/init systemd:/lib/systemd/systemd upstart:/sbin/upstart"
+
+if [ "x${GRUB_DISTRIBUTOR}" = "x" ] ; then
+  OS=GNU/Linux
+else
+  OS="${GRUB_DISTRIBUTOR} GNU/Linux"
+  CLASS="--class $(echo ${GRUB_DISTRIBUTOR} | tr 'A-Z' 'a-z' | cut -d' ' -f1|LC_ALL=C sed 's,[^[:alnum:]_],_,g') ${CLASS}"
+fi
+
+# loop-AES arranges things so that /dev/loop/X can be our root device, but
+# the initrds that Linux uses don't like that.
+case ${GRUB_DEVICE} in
+  /dev/loop/*|/dev/loop[0-9])
+    GRUB_DEVICE=`losetup ${GRUB_DEVICE} | sed -e "s/^[^(]*(\([^)]\+\)).*/\1/"`
+    # We can't cope with devices loop-mounted from files here.
+    case ${GRUB_DEVICE} in
+      /dev/*) ;;
+      *) exit 0 ;;
+    esac
+  ;;
+esac
+
+# Default to disabling partition uuid support to maintian compatibility with
+# older kernels.
+GRUB_DISABLE_LINUX_PARTUUID=${GRUB_DISABLE_LINUX_PARTUUID-true}
+
+# btrfs may reside on multiple devices. We cannot pass them as value of root= parameter
+# and mounting btrfs requires user space scanning, so force UUID in this case.
+if ( [ "x${GRUB_DEVICE_UUID}" = "x" ] && [ "x${GRUB_DEVICE_PARTUUID}" = "x" ] ) \
+    || ( [ "x${GRUB_DISABLE_LINUX_UUID}" = "xtrue" ] \
+	&& [ "x${GRUB_DISABLE_LINUX_PARTUUID}" = "xtrue" ] ) \
+    || ( ! test -e "/dev/disk/by-uuid/${GRUB_DEVICE_UUID}" \
+	&& ! test -e "/dev/disk/by-partuuid/${GRUB_DEVICE_PARTUUID}" ) \
+    || ( test -e "${GRUB_DEVICE}" && uses_abstraction "${GRUB_DEVICE}" lvm ); then
+  LINUX_ROOT_DEVICE=${GRUB_DEVICE}
+elif [ "x${GRUB_DEVICE_UUID}" = "x" ] \
+    || [ "x${GRUB_DISABLE_LINUX_UUID}" = "xtrue" ]; then
+  LINUX_ROOT_DEVICE=PARTUUID=${GRUB_DEVICE_PARTUUID}
+else
+  LINUX_ROOT_DEVICE=UUID=${GRUB_DEVICE_UUID}
+fi
+
+# Allow overriding GRUB_CMDLINE_LINUX and GRUB_CMDLINE_LINUX_DEFAULT.
+if [ "${GRUB_CMDLINE_LINUX_XEN_REPLACE}" ]; then
+  GRUB_CMDLINE_LINUX="${GRUB_CMDLINE_LINUX_XEN_REPLACE}"
+fi
+if [ "${GRUB_CMDLINE_LINUX_XEN_REPLACE_DEFAULT}" ]; then
+  GRUB_CMDLINE_LINUX_DEFAULT="${GRUB_CMDLINE_LINUX_XEN_REPLACE_DEFAULT}"
+fi
+
+case x"$GRUB_FS" in
+    xbtrfs)
+	rootsubvol="`make_system_path_relative_to_its_root /`"
+	rootsubvol="${rootsubvol#/}"
+	if [ "x${rootsubvol}" != x ]; then
+	    GRUB_CMDLINE_LINUX="rootflags=subvol=${rootsubvol} ${GRUB_CMDLINE_LINUX}"
+	fi;;
+    xzfs)
+	rpool=`${grub_probe} --device ${GRUB_DEVICE} --target=fs_label 2>/dev/null || true`
+	bootfs="`make_system_path_relative_to_its_root / | sed -e "s,@$,,"`"
+	LINUX_ROOT_DEVICE="ZFS=${rpool}${bootfs%/}"
+	;;
+esac
+
+title_correction_code=
+
+linux_entry ()
+{
+  linux_entry_xsm "$@" false
+  linux_entry_xsm "$@" true
+}
+linux_entry_xsm ()
+{
+  os="$1"
+  version="$2"
+  xen_version="$3"
+  type="$4"
+  args="$5"
+  xen_args="$6"
+  xsm="$7"
+  # If user wants to enable XSM support, make sure there's
+  # corresponding policy file.
+  if ${xsm} ; then
+      xenpolicy="xenpolicy-$xen_version"
+      if test ! -e "${xen_dirname}/${xenpolicy}" ; then
+	  return
+      fi
+      xen_args="$xen_args flask=enforcing"
+      xen_version="$(gettext_printf "%s (XSM enabled)" "$xen_version")"
+      # xen_version is used for messages only; actual file is xen_basename
+  fi
+  if [ -z "$boot_device_id" ]; then
+      boot_device_id="$(grub_get_device_id "${GRUB_DEVICE}")"
+  fi
+  if [ x$type != xsimple ] ; then
+      if [ x$type = xrecovery ] ; then
+	  title="$(gettext_printf "%s, with Xen %s and Linux %s (%s)" "${os}" "${xen_version}" "${version}" "$(gettext "${GRUB_RECOVERY_TITLE}")")"
+      elif [ "${type#init-}" != "$type" ] ; then
+	  title="$(gettext_printf "%s, with Xen %s and Linux %s (%s)" "${os}" "${xen_version}" "${version}" "${type#init-}")"
+      else
+	  title="$(gettext_printf "%s, with Xen %s and Linux %s" "${os}" "${xen_version}" "${version}")"
+      fi
+      replacement_title="$(echo "Advanced options for ${OS}" | sed 's,>,>>,g')>$(echo "$title" | sed 's,>,>>,g')"
+      if [ x"Xen ${xen_version}>$title" = x"$GRUB_ACTUAL_DEFAULT" ]; then
+         quoted="$(echo "$GRUB_ACTUAL_DEFAULT" | grub_quote)"
+         title_correction_code="${title_correction_code}if [ \"x\$default\" = '$quoted' ]; then default='$(echo "$replacement_title" | grub_quote)'; fi;"
+         grub_warn "$(gettext_printf "Please don't use old title \`%s' for GRUB_DEFAULT, use \`%s' (for versions before 2.00) or \`%s' (for 2.00 or later)" "$GRUB_ACTUAL_DEFAULT" "$replacement_title" "gnulinux-advanced-$boot_device_id>gnulinux-$version-$type-$boot_device_id")"
+      fi
+      echo "menuentry '$(echo "$title" | grub_quote)' ${CLASS} \$menuentry_id_option 'xen-gnulinux-$version-$type-$boot_device_id' {" | sed "s/^/$submenu_indentation/"
+  else
+      title="$(gettext_printf "%s, with Xen hypervisor" "${os}")"
+      echo "menuentry '$(echo "$title" | grub_quote)' ${CLASS} \$menuentry_id_option 'xen-gnulinux-simple-$boot_device_id' {" | sed "s/^/$submenu_indentation/"
+  fi
+  if [ x$type != xrecovery ] ; then
+      save_default_entry | grub_add_tab | sed "s/^/$submenu_indentation/"
+  fi
+
+  if [ -z "${prepare_boot_cache}" ]; then
+    prepare_boot_cache="$(prepare_grub_to_access_device ${GRUB_DEVICE_BOOT} | grub_add_tab)"
+  fi
+  printf '%s\n' "${prepare_boot_cache}" | sed "s/^/$submenu_indentation/"
+  xmessage="$(gettext_printf "Loading Xen %s ..." ${xen_version})"
+  lmessage="$(gettext_printf "Loading Linux %s ..." ${version})"
+  sed "s/^/$submenu_indentation/" << EOF
+	echo	'$(echo "$xmessage" | grub_quote)'
+        if [ "\$grub_platform" = "pc" -o "\$grub_platform" = "" ]; then
+            xen_rm_opts=
+        else
+            xen_rm_opts="no-real-mode edd=off"
+        fi
+	${xen_loader}	${rel_xen_dirname}/${xen_basename} placeholder ${xen_args} \${xen_rm_opts}
+	echo	'$(echo "$lmessage" | grub_quote)'
+	${module_loader}	${rel_dirname}/${basename} placeholder root=${linux_root_device_thisversion} ro ${args}
+EOF
+  if test -n "${initrd}" ; then
+    # TRANSLATORS: ramdisk isn't identifier. Should be translated.
+    message="$(gettext_printf "Loading initial ramdisk ...")"
+    initrd_path=
+    for i in ${initrd}; do
+       initrd_path="${initrd_path} ${rel_dirname}/${i}"
+    done
+    sed "s/^/$submenu_indentation/" << EOF
+	echo	'$(echo "$message" | grub_quote)'
+	${module_loader}	--nounzip   $(echo $initrd_path)
+EOF
+  fi
+  if ${xsm} && test -n "${xenpolicy}" ; then
+    message="$(gettext_printf "Loading XSM policy ...")"
+    sed "s/^/$submenu_indentation/" << EOF
+	echo	'$(echo "$message" | grub_quote)'
+	${module_loader}     ${rel_dirname}/${xenpolicy}
+EOF
+  fi
+  sed "s/^/$submenu_indentation/" << EOF
+}
+EOF
+}
+
+linux_list=
+for i in /boot/vmlinu[xz]-* /vmlinu[xz]-* /boot/kernel-*; do
+    if grub_file_is_not_garbage "$i"; then
+    	basename=$(basename $i)
+	version=$(echo $basename | sed -e "s,^[^0-9]*-,,g")
+	dirname=$(dirname $i)
+	config=
+	for j in "${dirname}/config-${version}" "${dirname}/config-${alt_version}" "/etc/kernels/kernel-config-${version}" ; do
+	    if test -e "${j}" ; then
+		config="${j}"
+		break
+	    fi
+	done
+        if (grep -qx "CONFIG_XEN_DOM0=y" "${config}" 2> /dev/null || grep -qx "CONFIG_XEN_PRIVILEGED_GUEST=y" "${config}" 2> /dev/null); then linux_list="$linux_list $i" ; fi
+    fi
+done
+if [ "x${linux_list}" = "x" ] ; then
+    exit 0
+fi
+
+file_is_not_xen_garbage () {
+    case "$1" in
+	*/xen-syms-*)
+	    return 1;;
+	*/xenpolicy-*)
+	    return 1;;
+	*/*.config)
+	    return 1;;
+	*)
+	    return 0;;
+    esac
+}
+
+xen_list=
+for i in /boot/xen*; do
+    if grub_file_is_not_garbage "$i" && file_is_not_xen_garbage "$i" ; then xen_list="$xen_list $i" ; fi
+done
+prepare_boot_cache=
+boot_device_id=
+
+title_correction_code=
+
+machine=`uname -m`
+
+case "$machine" in
+    i?86) GENKERNEL_ARCH="x86" ;;
+    mips|mips64) GENKERNEL_ARCH="mips" ;;
+    mipsel|mips64el) GENKERNEL_ARCH="mipsel" ;;
+    arm*) GENKERNEL_ARCH="arm" ;;
+    *) GENKERNEL_ARCH="$machine" ;;
+esac
+
+# Extra indentation to add to menu entries in a submenu. We're not in a submenu
+# yet, so it's empty. In a submenu it will be equal to '\t' (one tab).
+submenu_indentation=""
+
+is_top_level=true
+
+while [ "x${xen_list}" != "x" ] ; do
+    list="${linux_list}"
+    current_xen=`version_find_latest $xen_list`
+    xen_basename=`basename ${current_xen}`
+    xen_dirname=`dirname ${current_xen}`
+    rel_xen_dirname=`make_system_path_relative_to_its_root $xen_dirname`
+    xen_version=`echo $xen_basename | sed -e "s,.gz$,,g;s,^xen-,,g"`
+    if [ -z "$boot_device_id" ]; then
+	boot_device_id="$(grub_get_device_id "${GRUB_DEVICE}")"
+    fi
+    if [ "x$is_top_level" != xtrue ]; then
+	echo "	submenu '$(gettext_printf "Xen hypervisor, version %s" "${xen_version}" | grub_quote)' \$menuentry_id_option 'xen-hypervisor-$xen_version-$boot_device_id' {"
+    fi
+    if ($grub_file --is-arm64-efi $current_xen); then
+	xen_loader="xen_hypervisor"
+	module_loader="xen_module"
+    else
+	if ($grub_file --is-x86-multiboot2 $current_xen); then
+	    xen_loader="multiboot2"
+	    module_loader="module2"
+	else
+	    xen_loader="multiboot"
+	    module_loader="module"
+        fi
+    fi
+
+    initrd_early=
+    for i in ${GRUB_EARLY_INITRD_LINUX_STOCK} \
+             ${GRUB_EARLY_INITRD_LINUX_CUSTOM}; do
+       if test -e "${xen_dirname}/${i}" ; then
+          initrd_early="${initrd_early} ${i}"
+       fi
+    done
+
+    while [ "x$list" != "x" ] ; do
+	linux=`version_find_latest $list`
+	gettext_printf "Found linux image: %s\n" "$linux" >&2
+	basename=`basename $linux`
+	dirname=`dirname $linux`
+	rel_dirname=`make_system_path_relative_to_its_root $dirname`
+	version=`echo $basename | sed -e "s,^[^0-9]*-,,g"`
+	alt_version=`echo $version | sed -e "s,\.old$,,g"`
+	linux_root_device_thisversion="${LINUX_ROOT_DEVICE}"
+
+	initrd_real=
+	for i in "initrd.img-${version}" "initrd-${version}.img" "initrd-${version}.gz" \
+	   "initrd-${version}" "initramfs-${version}.img" \
+	   "initrd.img-${alt_version}" "initrd-${alt_version}.img" \
+	   "initrd-${alt_version}" "initramfs-${alt_version}.img" \
+	   "initramfs-genkernel-${version}" \
+	   "initramfs-genkernel-${alt_version}" \
+	   "initramfs-genkernel-${GENKERNEL_ARCH}-${version}" \
+	   "initramfs-genkernel-${GENKERNEL_ARCH}-${alt_version}" ; do
+	    if test -e "${dirname}/${i}" ; then
+		initrd_real="$i"
+		break
+	    fi
+	done
+
+	initrd=
+	if test -n "${initrd_early}" || test -n "${initrd_real}"; then
+	    initrd="${initrd_early} ${initrd_real}"
+
+	    initrd_display=
+	    for i in ${initrd}; do
+		initrd_display="${initrd_display} ${dirname}/${i}"
+	    done
+	    gettext_printf "Found initrd image: %s\n" "$(echo $initrd_display)" >&2
+	fi
+
+	if test -z "${initrd_real}"; then
+    # "UUID=" magic is parsed by initrds.  Since there's no initrd, it can't work here.
+	    if [ "x${GRUB_DEVICE_PARTUUID}" = "x" ] \
+		|| [ "x${GRUB_DISABLE_LINUX_PARTUUID}" = "xtrue" ]; then
+
+		linux_root_device_thisversion=${GRUB_DEVICE}
+	    else
+		linux_root_device_thisversion=PARTUUID=${GRUB_DEVICE_PARTUUID}
+	    fi
+	fi
+
+	# The GRUB_DISABLE_SUBMENU option used to be different than others since it was
+	# mentioned in the documentation that has to be set to 'y' instead of 'true' to
+	# enable it. This caused a lot of confusion to users that set the option to 'y',
+	# 'yes' or 'true'. This was fixed but all of these values must be supported now.
+	if [ "x${GRUB_DISABLE_SUBMENU}" = xyes ] || [ "x${GRUB_DISABLE_SUBMENU}" = xy ]; then
+	    GRUB_DISABLE_SUBMENU="true"
+	fi
+
+	if [ "x$is_top_level" = xtrue ] && [ "x${GRUB_DISABLE_SUBMENU}" != xtrue ]; then
+	    linux_entry "${OS}" "${version}" "${xen_version}" simple \
+		"${GRUB_CMDLINE_LINUX} ${GRUB_CMDLINE_LINUX_DEFAULT}" "${GRUB_CMDLINE_XEN} ${GRUB_CMDLINE_XEN_DEFAULT}"
+
+	    submenu_indentation="$grub_tab$grub_tab"
+    
+	    if [ -z "$boot_device_id" ]; then
+		boot_device_id="$(grub_get_device_id "${GRUB_DEVICE}")"
+	    fi
+            # TRANSLATORS: %s is replaced with an OS name
+	    echo "submenu '$(gettext_printf "Advanced options for %s (with Xen hypervisor)" "${OS}" | grub_quote)' \$menuentry_id_option 'gnulinux-advanced-$boot_device_id' {"
+	echo "	submenu '$(gettext_printf "Xen hypervisor, version %s" "${xen_version}" | grub_quote)' \$menuentry_id_option 'xen-hypervisor-$xen_version-$boot_device_id' {"
+	   is_top_level=false
+	fi
+
+	linux_entry "${OS}" "${version}" "${xen_version}" advanced \
+	    "${GRUB_CMDLINE_LINUX} ${GRUB_CMDLINE_LINUX_DEFAULT}" "${GRUB_CMDLINE_XEN} ${GRUB_CMDLINE_XEN_DEFAULT}"
+	for supported_init in ${SUPPORTED_INITS}; do
+	    init_path="${supported_init#*:}"
+	    if [ -x "${init_path}" ] && [ "$(readlink -f /sbin/init)" != "$(readlink -f "${init_path}")" ]; then
+		linux_entry "${OS}" "${version}" "${xen_version}" "init-${supported_init%%:*}" \
+		    "${GRUB_CMDLINE_LINUX} ${GRUB_CMDLINE_LINUX_DEFAULT} init=${init_path}" "${GRUB_CMDLINE_XEN} ${GRUB_CMDLINE_XEN_DEFAULT}"
+
+	    fi
+	done
+	if [ "x${GRUB_DISABLE_RECOVERY}" != "xtrue" ]; then
+	    linux_entry "${OS}" "${version}" "${xen_version}" recovery \
+		"single ${GRUB_CMDLINE_LINUX}" "${GRUB_CMDLINE_XEN}"
+	fi
+
+	list=`echo $list | tr ' ' '\n' | fgrep -vx "$linux" | tr '\n' ' '`
+    done
+    if [ x"$is_top_level" != xtrue ]; then
+	echo '	}'
+    fi
+    xen_list=`echo $xen_list | tr ' ' '\n' | fgrep -vx "$current_xen" | tr '\n' ' '`
+done
+
+# If at least one kernel was found, then we need to
+# add a closing '}' for the submenu command.
+if [ x"$is_top_level" != xtrue ]; then
+  echo '}'
+fi
+
+echo "$title_correction_code"
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 17:10:54 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 17:10:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695058.1084601 (Exim 4.92)
	(envelope-from )
	id 1rmGVh-0001Ci-8o; Mon, 18 Mar 2024 17:10:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695058.1084601; Mon, 18 Mar 2024 17:10:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmGVh-0001Cb-4D; Mon, 18 Mar 2024 17:10:53 +0000
Received: by outflank-mailman (input) for mailman id 695058;
 Mon, 18 Mar 2024 17:10:51 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmGHk-0002f9-0A
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 16:56:28 +0000
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com
 [2a00:1450:4864:20::136])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 72dd039b-e548-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 17:56:22 +0100 (CET)
Received: by mail-lf1-x136.google.com with SMTP id
 2adb3069b0e04-512e4f4e463so5154828e87.1
 for ; Mon, 18 Mar 2024 09:56:22 -0700 (PDT)
Received: from localhost.localdomain
 (cpc92320-cmbg19-2-0-cust35.5-4.cable.virginm.net. [82.13.64.36])
 by smtp.gmail.com with ESMTPSA id
 a18-20020a05600c349200b0041413d11838sm2020141wmq.26.2024.03.18.09.56.20
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 18 Mar 2024 09:56:21 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 72dd039b-e548-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710780981; x=1711385781; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=a6SOJAPHzTw3MYpCL3W6xE70pNKEvpjBBoKho15ndy8=;
        b=kRiQYmPdBe14TBvTEtSjLETcNPXCowgqpeTGJcPEwXdFDJR91J0yECQqdn+NqMBp8x
         7qCrxiRuQdT2yIJ/wkX0RFP7iNjQBNw+arRnchNkGamF+lvLsOVHLzU8UpK7BJVRB3Cy
         F5BgwPAutrCrl2uxU0K44tJ2mWrDykzAM/1GY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710780981; x=1711385781;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=a6SOJAPHzTw3MYpCL3W6xE70pNKEvpjBBoKho15ndy8=;
        b=k3WIgaPNxd2Q0OM22lEKLjPyDF+JCUDVYOKIUH/Cqo+N7wieLVAPpzgFx6cf8xIYmo
         uzmyntnLVOX09nvU2By/qfgZacRDARMqiBUMkqnRlbO+0Hls6HBvtMsH3r2s7DoG9uqf
         Wcpu34gMZCwLxNJ6Fic8amwJhrqyoSQWzATVltOdH69UhxJxNGU/Pb6RhGZlWnRtw4vv
         zyB0P+VdVxvhHbObfUCqJEGYRE5crKgu8SIfbTIHKsCVX/KCijX2dcPQZsvF8K6ahi+7
         +N/gvpdJtm9ep0JSvM+edMjhW/axa1p3ht3Ur0rpET9k0VyJWxeF3rA5L5Hjx3hRbpmI
         nhDw==
X-Gm-Message-State: AOJu0Yy0nY9f960kBqkbNP+G+ErMk4FJKCUYqKluSPqLyyiSoo+LQq+m
	3UhdSWnbGkSWdvplyyrYT/0Yph2fxwyAaiKAPNpP18F5vzi/VAknBly4XPbknqmRY+Pco+pcJfc
	b
X-Google-Smtp-Source: AGHT+IFmG58z5oOeybe79OGRLnMNdyftivOKXgykL/ptl1wsy9WLHmGjr9kBMpbh1ubkmFjsj7ZC7A==
X-Received: by 2002:a19:9118:0:b0:513:d71e:eeb4 with SMTP id t24-20020a199118000000b00513d71eeeb4mr7066453lfd.18.1710780981703;
        Mon, 18 Mar 2024 09:56:21 -0700 (PDT)
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne 
Subject: [OSSTEST PATCH 36/36] make-hosts-flight: default to bookworm
Date: Mon, 18 Mar 2024 16:55:45 +0000
Message-Id: <20240318165545.3898-37-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.39.2
In-Reply-To: <20240318165545.3898-1-anthony.perard@citrix.com>
References: <20240318165545.3898-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Signed-off-by: Anthony PERARD 
---
 make-hosts-flight | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/make-hosts-flight b/make-hosts-flight
index 63ac7b71..0177f605 100755
--- a/make-hosts-flight
+++ b/make-hosts-flight
@@ -26,7 +26,7 @@ blessing=$4
 buildflight=$5
 
 : ${ALL_ARCHES:=amd64 i386 arm64 armhf}
-: ${ALL_SUITES:=buster stretch jessie}
+: ${ALL_SUITES:=bookworm buster stretch jessie}
 # ^ most preferred suite first
 
 : ${PERHOST_MAXWAIT:=20000} # seconds
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 17:11:03 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 17:11:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695060.1084610 (Exim 4.92)
	(envelope-from )
	id 1rmGVr-0001ZU-Ei; Mon, 18 Mar 2024 17:11:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695060.1084610; Mon, 18 Mar 2024 17:11:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmGVr-0001ZN-BG; Mon, 18 Mar 2024 17:11:03 +0000
Received: by outflank-mailman (input) for mailman id 695060;
 Mon, 18 Mar 2024 17:11:02 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmGHj-0002gq-NK
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 16:56:27 +0000
Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com
 [2a00:1450:4864:20::336])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 724c0068-e548-11ee-afdd-a90da7624cb6;
 Mon, 18 Mar 2024 17:56:21 +0100 (CET)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-413f76fcf41so33704655e9.3
 for ; Mon, 18 Mar 2024 09:56:21 -0700 (PDT)
Received: from localhost.localdomain
 (cpc92320-cmbg19-2-0-cust35.5-4.cable.virginm.net. [82.13.64.36])
 by smtp.gmail.com with ESMTPSA id
 a18-20020a05600c349200b0041413d11838sm2020141wmq.26.2024.03.18.09.56.20
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 18 Mar 2024 09:56:20 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 724c0068-e548-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710780981; x=1711385781; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=1sfVt8Xg23JpHHAPGe+eT+E0bwcscFUgALb2j8zZ/sQ=;
        b=M37dCuSMZTmRJh6f3u3SFKEzJPGbjvQg9Oj5X3bc0/6UTGnLDHsuIcWpM+EwxhPCSc
         PH/Laz8oE5ZQGzDE1IECLkajDO/JktHbuvcehMy+eV7fvXJgysVsn2HQJ0DikRxMB3Ir
         QeBcCtjmCDHrjusqMo24upertDPE/idlC8Rug=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710780981; x=1711385781;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=1sfVt8Xg23JpHHAPGe+eT+E0bwcscFUgALb2j8zZ/sQ=;
        b=Of3i9shqpgc2vPuXJCc/6PP9MECT5PjcVwAqGx/2F41yfqR6AbCxKl5hqYeLoOfPp2
         1DbB3LVkx/SnlOvId8PDwPyK6cmEHK3QO5vY+zAeaRwE6gV054TnBY2e27ecVxfXqgt6
         sNzZrQLSrg2+a07gvGTFCwW7YrEzD/VCW/rY7mkLPojrbFzrkiW4S4QR3DrrmeO4w/jJ
         rZNUHval4OirIBSc89aWzloqGbm5VgrYYc7E5wZLesqDYzXfvMSCnOdwV8YM62p3zZi7
         VejHBvz16HxYttqv6mGh6xRltJH0NnAWPnt67/DdqctxD+Ue1YwM2B2pnvmkttiRATnV
         FHWQ==
X-Gm-Message-State: AOJu0YyplUZJg+hwFvF3IFsLYzbNJg5fpAvXC6VweEjP2iy3bgUvzAX8
	tcvVXwNPRcO17ZnkcY3dl64rn7YR8NWBvjqm6wcH9yWc3Ic3n5VtEShG+2eCtp743Q2R+nwJs/8
	Q
X-Google-Smtp-Source: AGHT+IEMiO/AgdmTkpOqiPg6/8IU763h7xjEO1zx085zwYqqGt7cc1QJOnPJDF+WPxzm9Tujczh2FQ==
X-Received: by 2002:a05:600c:5490:b0:414:846:4469 with SMTP id iv16-20020a05600c549000b0041408464469mr7010wmb.38.1710780980802;
        Mon, 18 Mar 2024 09:56:20 -0700 (PDT)
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne 
Subject: [OSSTEST PATCH 35/36] Switch to Debian Bookworm as default suite
Date: Mon, 18 Mar 2024 16:55:44 +0000
Message-Id: <20240318165545.3898-36-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.39.2
In-Reply-To: <20240318165545.3898-1-anthony.perard@citrix.com>
References: <20240318165545.3898-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Xen 4.17 doesn't build with Debian Bookworm. It fails to build
IPXE/etherboot, on "amd64". So we keep using Debian Buster on Xen 4.18
and earlier branches. Xen 4.18 builds 4.17 via job "build-amd64-prev".

Xen 4.17 would needs 18a36b4a9b08 ("tools: ipxe: update for fixing
build with GCC12") which is only in Xen 4.18.

Signed-off-by: Anthony PERARD 
---
 Osstest.pm  | 2 +-
 make-flight | 6 +-----
 2 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/Osstest.pm b/Osstest.pm
index a559ca4e..9ac2dc5c 100644
--- a/Osstest.pm
+++ b/Osstest.pm
@@ -87,7 +87,7 @@ our %c = qw(
 
     Images images
 
-    DebianSuite buster
+    DebianSuite bookworm
     DebianMirrorSubpath debian
 
     TestHostKeypairPath id_rsa_osstest
diff --git a/make-flight b/make-flight
index 6e88cb13..0b528629 100755
--- a/make-flight
+++ b/make-flight
@@ -43,17 +43,13 @@ case "$xenbranch" in
   xen-4.3-testing) defsuite="wheezy"; defguestsuite="wheezy";;
   xen-4.9-testing)  defsuite="stretch"; defguestsuite="stretch";;
   xen-4.10-testing) defsuite="stretch"; defguestsuite="stretch";;
+  xen-4.1[1-8]-testing) defsuite="buster"; defguestsuite="buster";;
   *)
     defsuite=`getconfig DebianSuite`
     defguestsuite=`getconfig GuestDebianSuite`
     ;;
 esac
 
-# QEMU doesn't build on buster anymore, use bookworm for it.
-case "$branch" in
-    qemu-mainline) defsuite="bookworm" ;;
-esac
-
 # Pick default Debian Installer version to correspond to the chosen
 # suite.
 if [ -z "$defdi_version" ] ; then
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 17:11:09 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 17:11:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695063.1084620 (Exim 4.92)
	(envelope-from )
	id 1rmGVx-0001yW-Lw; Mon, 18 Mar 2024 17:11:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695063.1084620; Mon, 18 Mar 2024 17:11:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmGVx-0001yL-Hk; Mon, 18 Mar 2024 17:11:09 +0000
Received: by outflank-mailman (input) for mailman id 695063;
 Mon, 18 Mar 2024 17:11:08 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmGHY-0002gq-L9
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 16:56:16 +0000
Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com
 [2a00:1450:4864:20::336])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6ca5a649-e548-11ee-afdd-a90da7624cb6;
 Mon, 18 Mar 2024 17:56:12 +0100 (CET)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-41412253e71so7269575e9.0
 for ; Mon, 18 Mar 2024 09:56:11 -0700 (PDT)
Received: from localhost.localdomain
 (cpc92320-cmbg19-2-0-cust35.5-4.cable.virginm.net. [82.13.64.36])
 by smtp.gmail.com with ESMTPSA id
 a18-20020a05600c349200b0041413d11838sm2020141wmq.26.2024.03.18.09.56.10
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 18 Mar 2024 09:56:11 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6ca5a649-e548-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710780971; x=1711385771; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=NJaVDu1HMN8nfSe34Wd7KEfeD3d4HQ65vleYBfsnpac=;
        b=LMlaEySiRkJ4mjwpdzbRgXK6nMiASO/g0d+vCYRUluLIzGfESf+D5kA6aRwwrcZiVh
         cAvn2Zw7kJrtdqw500dJ51tNrdDd3OYnUgr6brkmKpNnt1QtgrpjO4xW00ZR//1Q8uEi
         xfTax9o+3l1NQ4MvifyU/ClSnyWD02tR+lWxw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710780971; x=1711385771;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=NJaVDu1HMN8nfSe34Wd7KEfeD3d4HQ65vleYBfsnpac=;
        b=FqgLC2R5M+qKumWVHQk96O/CJyAABDpF+7zxnVBv/9B/h/p4RkOd2ZAQu5MIbs19Xg
         F0g5slqWKgxe0mrOdKbcKiJ4rrASM/oqW8rRTyLqQBeGPg8sJdRQOJch4828G+rCPpYV
         4iqwyqBcRa0mEWsXGdVv9lZsfsz2BnWhMTT7mMS8GNla/vlqHZziDbm+kbcAQiWam7Wy
         bAw4NIGJEW8RMJTQuc+NPZ7cufQBtZALdMsw8P4sFEKpvWq3td2JnZoq43ak/Pm0QWqu
         pnIssaqyvzOSxxrx+GMRWCYPE8DagdaZsls7xepsKKcEvkkzdfcWxKIUxtnr7Xn+OFSs
         ahaw==
X-Gm-Message-State: AOJu0Yy6nLMID62VmgOsw+FpDqCsFNuPXag3HFtm+ywOcE0uQeGfMWIC
	JzYiXFnE1ilGZ4uJnSO0qcxbwkH0tcObVF6DwI2ovlQtNinWvvS9ISE+SD14Nxnrj73r/ZCFCMu
	W
X-Google-Smtp-Source: AGHT+IHaB/e3DTU/QGOuC0o0JPNOW3lrzTIeuYBU2yenLyQlwGyoquKV7itLuHb60AIA57Y7D3FACA==
X-Received: by 2002:a05:600c:1389:b0:413:ee4b:cd8e with SMTP id u9-20020a05600c138900b00413ee4bcd8emr9755387wmf.24.1710780971394;
        Mon, 18 Mar 2024 09:56:11 -0700 (PDT)
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne 
Subject: [OSSTEST PATCH 24/36] ts-nested-setup, setup l1 lvm volume groupe in guest
Date: Mon, 18 Mar 2024 16:55:33 +0000
Message-Id: <20240318165545.3898-25-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.39.2
In-Reply-To: <20240318165545.3898-1-anthony.perard@citrix.com>
References: <20240318165545.3898-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

LVM in l0 doesn't let us run pvcreate on the host LV, `pvcreate
$outer_lvdev` fails with:
    Cannot use /dev/$l0-vg/l1_gueststorage_outer_lv: device is an LV

Signed-off-by: Anthony PERARD 
---
 ts-nested-setup | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/ts-nested-setup b/ts-nested-setup
index be3d3733..7fc8beef 100755
--- a/ts-nested-setup
+++ b/ts-nested-setup
@@ -80,14 +80,14 @@ sub guest_storage () {
     target_cmd_root($l0, "vgremove -f $inner_vg ||:");
     my $outer_lvdev = lv_create($l0, $outer_vg, $outer_lv, $size);
 
-    target_cmd_root($l0, <block_attach($l1, "$outer_lvdev,raw,sdb,rw");
     # NB this does not update the l1 guest config so if the l1 is shut
     # down and recreated in the l0, this will vanish.
+
+    target_cmd_root($l1, <
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 17:11:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695073.1084629 (Exim 4.92)
	(envelope-from )
	id 1rmGWK-0002v5-TX; Mon, 18 Mar 2024 17:11:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695073.1084629; Mon, 18 Mar 2024 17:11:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmGWK-0002uy-Qa; Mon, 18 Mar 2024 17:11:32 +0000
Received: by outflank-mailman (input) for mailman id 695073;
 Mon, 18 Mar 2024 17:11:31 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmGHV-0002gq-Ka
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 16:56:13 +0000
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com
 [2a00:1450:4864:20::331])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6c40284e-e548-11ee-afdd-a90da7624cb6;
 Mon, 18 Mar 2024 17:56:11 +0100 (CET)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-41411421113so7765955e9.1
 for ; Mon, 18 Mar 2024 09:56:11 -0700 (PDT)
Received: from localhost.localdomain
 (cpc92320-cmbg19-2-0-cust35.5-4.cable.virginm.net. [82.13.64.36])
 by smtp.gmail.com with ESMTPSA id
 a18-20020a05600c349200b0041413d11838sm2020141wmq.26.2024.03.18.09.56.09
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 18 Mar 2024 09:56:10 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6c40284e-e548-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710780970; x=1711385770; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=a1FmchBsn53IniDlrcuaP8DsX+RYkOrmvm7uzgbbq7I=;
        b=GCIDuRpdPlNgeAGAnH0+/8OzTcPZufOurq4jpflyQ45brtbpbvt3QM6dExvcltJE45
         ZMEUZxYsaTTvLA+4WVQ1WmWMn5cQ3DcRPLOv59loa8u4Q7AQxBoDPlyaL+HC/CxosnWO
         eaI5J1Rut1cONFewmRLPZ5TfMduTSZcO5xuBo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710780970; x=1711385770;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=a1FmchBsn53IniDlrcuaP8DsX+RYkOrmvm7uzgbbq7I=;
        b=cl8FTVMZLI57AmhAkW0JHYMTYGfX2h7IloMVV50rrKZlLwhRbqKkd5+ThNQVVuEn7F
         EHmZomkCamrZ/MRfHAFK4daxhGASJYObQqCWbkgT71o8qVsMKMdxBJS6xTpxygykwG4R
         ONOVdmSWx8+fPDP2bFUel+46AJB4O3iMlXhXuHqbR2d4RDRRG89cayJ5q+Yhke8XHIM+
         A23VdXTws3plnXxx0O9t1eaKNjFYcA11SpQZo24JlYilKPW0/SQ+rXwtvK96c9k/4E4d
         T6NhJKilIfwzO3qi88Fq/SJxAN4i/4zszxiB4NUC0HUa6z92TNeRASPLItKG0+qf3pnQ
         wxzA==
X-Gm-Message-State: AOJu0YzeS6Ygj5q5uuDV9dVve1j2QWfZQziC5sn8d+KzKUfJ69JiijyD
	eDIxoyHVUWEzWwcZbo08vEsGxAHhki6TrA93Y3R7pIvgdyDUMvhhUCmNbJgLkE6DppxY6tcasG7
	k
X-Google-Smtp-Source: AGHT+IHUWsml3D4ikWb31YIkSLv/z6wgQgGRvJNqTp7bVNw7TXv3i6SHWlKhpDk7+qlnPGxvigH7tw==
X-Received: by 2002:a05:600c:1554:b0:414:39c:d9f0 with SMTP id f20-20020a05600c155400b00414039cd9f0mr27157wmg.2.1710780970663;
        Mon, 18 Mar 2024 09:56:10 -0700 (PDT)
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne 
Subject: [OSSTEST PATCH 23/36] bookworm: Extend ARM clock workaround
Date: Mon, 18 Mar 2024 16:55:32 +0000
Message-Id: <20240318165545.3898-24-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.39.2
In-Reply-To: <20240318165545.3898-1-anthony.perard@citrix.com>
References: <20240318165545.3898-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Still broken on arndale, serial stop working early, then the machine
timeout when working on creating a xen guest with xen-create-guest.

Signed-off-by: Anthony PERARD 
---
 Osstest/Debian.pm | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 4f07cdef..68f1be60 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -253,8 +253,10 @@ END
 	my @xenkopt = @kopt;
 	push @xenkopt, $xenkopt;
 	# https://bugs.xenproject.org/xen/bug/45
+	# #45 - arm: domain 0 disables clocks which are in fact being used
+	# https://lore.kernel.org/xen-devel/1414672390.2064.31.camel@citrix.com/
 	push @xenkopt, "clk_ignore_unused"
-	    if $ho->{Suite} =~ m/wheezy|jessie|stretch|buster/;
+	    if $ho->{Suite} =~ m/wheezy|jessie|stretch|buster|bookworm/;
 
 	$xenkopt = join ' ', @xenkopt;
 	logm("Dom0 Linux options: $xenkopt");
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 17:20:35 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 17:20:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695091.1084639 (Exim 4.92)
	(envelope-from )
	id 1rmGf1-0000Xl-Nh; Mon, 18 Mar 2024 17:20:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695091.1084639; Mon, 18 Mar 2024 17:20:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmGf1-0000Xe-Kp; Mon, 18 Mar 2024 17:20:31 +0000
Received: by outflank-mailman (input) for mailman id 695091;
 Mon, 18 Mar 2024 17:20:30 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmGez-0000XY-Uz
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 17:20:29 +0000
Received: from mail-oo1-xc29.google.com (mail-oo1-xc29.google.com
 [2607:f8b0:4864:20::c29])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d0d5c3e2-e54b-11ee-afdd-a90da7624cb6;
 Mon, 18 Mar 2024 18:20:29 +0100 (CET)
Received: by mail-oo1-xc29.google.com with SMTP id
 006d021491bc7-5a4a2d99598so867614eaf.2
 for ; Mon, 18 Mar 2024 10:20:29 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d0d5c3e2-e54b-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710782428; x=1711387228; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=MRFfA5psmxpI/SQG+I5c+atf9Gqhl39S47/tTYJbKvc=;
        b=Q2xys6GllBRK/2u/3EVT9+f6oF3wxm1YwqfAkie+ls8RHxn6FG5FV3sVNcvBVzhI3x
         +x9vmPv0HNhWG4rBuFEuo6oEuRXgFVC3NsvGGT54JhOtaw4Tm7LnE+RALUZaG8ZZWJSW
         R3zGPboxVN45Xm7t32btltgHVVISY7shj3WIk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710782428; x=1711387228;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=MRFfA5psmxpI/SQG+I5c+atf9Gqhl39S47/tTYJbKvc=;
        b=ex3n+Dor1JrpShRDravmOMcflsOzhUwK+mlVgjBrBtaG93/hUejislgzsV5WsH1+Bt
         PpIPIq4zWIbuqIOw36yNYf91stYVraXTI7uWam8ToHsoj1ZWDuLTKH+GrJKwItp4UCO3
         oRNxO1mhUi6zZ3+pE8iaBz036QF8m275Ng2ntOoJpnkuBAwuyc9Yp0RFKuFq8AZzvrhM
         AOtcAZvan26yto26a+IgcY51puu2pq2QAstZgsWYuPuKN9wnD8JjPmfh/CTqOF939snG
         v2faPPM78XN3xnlYeorgopNUxUEHd1j9Uimv07INxcZEFXpKoWykYAzSmx1ECzgOOmVA
         CRhA==
X-Gm-Message-State: AOJu0Yz6b+gAAJFNdAZJ2jg0c1AhmcKQx19neJdqQ/vLCUOM5S+eGRR/
	C0BwtnjyxwdTUDL/BsltVDzmtC5pBPdTzPwDhPLprDQ8heGAQCNi8AFVojHfg5AlqwIrg/F9w+3
	hM0bDgtt4VrXft13hmswBk9Qc14UFAXHT1SPW
X-Google-Smtp-Source: AGHT+IE0+3glIPabxQE8gkIiHq4hq+82ClKk4n+ky6RcZAIFss1sBo+HA/rESppmyhkUigeBtEMV6pKNgUk4mMdkY0k=
X-Received: by 2002:a05:6358:782:b0:17e:6954:5750 with SMTP id
 n2-20020a056358078200b0017e69545750mr7944930rwj.9.1710782427852; Mon, 18 Mar
 2024 10:20:27 -0700 (PDT)
MIME-Version: 1.0
References: <20240318110442.3653997-1-andrew.cooper3@citrix.com> <20240318110442.3653997-3-andrew.cooper3@citrix.com>
In-Reply-To: <20240318110442.3653997-3-andrew.cooper3@citrix.com>
From: Ross Lagerwall 
Date: Mon, 18 Mar 2024 17:20:15 +0000
Message-ID: 
Subject: Re: [PATCH 2/4] xen/virtual-region: Rework how bugframe linkage works
To: Andrew Cooper 
Cc: Xen-devel , Jan Beulich , 
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu , 
	Stefano Stabellini , Julien Grall , 
	Volodymyr Babchuk , Bertrand Marquis , 
	Michal Orzel , Oleksii Kurochko , 
	Shawn Anastasio , 
	Konrad Rzeszutek Wilk 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Mar 18, 2024 at 11:04=E2=80=AFAM Andrew Cooper
 wrote:
>
> The start/stop1/etc linkage scheme predates struct virtual_region, and as
> setup_virtual_regions() shows, it's awkward to express in the new scheme.
>
> Change the linker to provide explicit start/stop symbols for each bugfram=
e
> type, and change virtual_region to have a stop pointer rather than a coun=
t.
>
> This marginly simplifies both do_bug_frame()s and prepare_payload(), but =
it
> massively simplifies setup_virtual_regions() by allowing the compiler to
> initialise the .frame[] array at build time.
>
> virtual_region.c is the only user of the linker symbols, and this is unli=
kely
> to change given the purpose of struct virtual_region, so move their exter=
ns
> out of bug.h
>
> No functional change.
>
> Signed-off-by: Andrew Cooper 

Reviewed-by: Ross Lagerwall 


From xen-devel-bounces@lists.xenproject.org Mon Mar 18 18:13:52 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 18:13:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695113.1084656 (Exim 4.92)
	(envelope-from )
	id 1rmHUP-0002zm-P3; Mon, 18 Mar 2024 18:13:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695113.1084656; Mon, 18 Mar 2024 18:13:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmHUP-0002zf-Lu; Mon, 18 Mar 2024 18:13:37 +0000
Received: by outflank-mailman (input) for mailman id 695113;
 Mon, 18 Mar 2024 18:13:36 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmHUO-0002se-Ng
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 18:13:36 +0000
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com
 [2a00:1450:4864:20::536])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3c251899-e553-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 19:13:35 +0100 (CET)
Received: by mail-ed1-x536.google.com with SMTP id
 4fb4d7f45d1cf-5684ea117a3so6916759a12.0
 for ; Mon, 18 Mar 2024 11:13:35 -0700 (PDT)
Received: from andrewcoop.citrite.net (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 p8-20020a50cd88000000b0056851310a04sm5102928edi.16.2024.03.18.11.13.33
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 18 Mar 2024 11:13:33 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3c251899-e553-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710785614; x=1711390414; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:from:to:cc:subject:date:message-id:reply-to;
        bh=I5jTcKsMsCqCrjNyG868pQQ+v3sQiSH8rAadw9EdKLI=;
        b=qUMzjBoyHaQjCDvWJWi+MWSfRY4U0n1+QgNRo4JZ8eSIEoyQRP/gkwRm9FTEvYjKBG
         vbYrdwetX6RcL2Whh3NFy5Rf83ADmzX2zvpkV7hLxx10tjCNh6oUBMC12VwKDW/yTv6A
         +4xmCWzIp1+9weIN/kIPzSB9n7iqRFgXk+TsU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710785614; x=1711390414;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=I5jTcKsMsCqCrjNyG868pQQ+v3sQiSH8rAadw9EdKLI=;
        b=Xf/rjTEi1Gwbpr4yOGAv81mNE22Ea6NQY9knupjXVdGGAwDguryhgSO7zzGeHP+8jZ
         MBsLgCyKJmxopiKdSOtoq9Ul8i/PW8lo6lSfsdOoOdvMOYG52MM9HZ3PEI3UI3CEG/63
         w9Zne5ck13p6xbR5orZdr65D3wIdLtKb1hcNVOfDjtWiYdggXqZzALkatYJ61Dhog8x7
         Z458+StFfZob4yOD0EQ9HksRHys3bLqVTho1ZNwpVptGLGTuQWgYKYylxTUvaMCeHrQ7
         W80IpDkXOY1zqjIDlIGesHspiXxamedgapSZfQuZBbjm8noOjDTWT+RC70tYKQjlQjQM
         VG7A==
X-Gm-Message-State: AOJu0YzZS9IuwUQFI73Y2wu8k79hcCOZgnh5wc1QVTSfxl6JWnypvkig
	IuDHmOTxMW/pVLrCLcw0cOZSM8t6aYezJpP0tJDh39H5pKne8VyVZIWKzzIVfOzYgoejronwnw/
	I
X-Google-Smtp-Source: AGHT+IEVqkAVuUC43xKqBKiq9ZHbnwtpWzUTfk/Doj61qI9uNVeWzsOT41KaFLXz0MpWEdazflWPbQ==
X-Received: by 2002:a05:6402:3706:b0:56a:2b6b:42cd with SMTP id ek6-20020a056402370600b0056a2b6b42cdmr2456495edb.3.1710785613674;
        Mon, 18 Mar 2024 11:13:33 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH] x86/features: More AMD features
Date: Mon, 18 Mar 2024 18:13:32 +0000
Message-Id: <20240318181332.3817631-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.30.2
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

All of these are informational and require no further logic changes in Xen to
support.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 

I'm not sure about FSRSC as a name, but it definitely beats AMD's longhand
name of FAST_REP_SCASB.
---
 tools/misc/xen-cpuid.c                      | 5 +++++
 xen/include/public/arch-x86/cpufeatureset.h | 8 ++++++++
 2 files changed, 13 insertions(+)

diff --git a/tools/misc/xen-cpuid.c b/tools/misc/xen-cpuid.c
index 51efbff579e6..b562ee839d38 100644
--- a/tools/misc/xen-cpuid.c
+++ b/tools/misc/xen-cpuid.c
@@ -91,6 +91,7 @@ static const char *const str_e1c[32] =
     [24] = "perfctr-nb", /* [25] */
     [26] = "dbx",        [27] = "perftsc",
     [28] = "pcx-l2i",    [29] = "monitorx",
+    [30] = "dbext2",
 };
 
 static const char *const str_7b0[32] =
@@ -199,11 +200,15 @@ static const char *const str_7a1[32] =
 
 static const char *const str_e21a[32] =
 {
+    [ 0] = "no-nest-bp",    [ 1] = "fs-gs-ns",
     [ 2] = "lfence+",
     [ 6] = "nscb",
     [ 8] = "auto-ibrs",
+    [10] = "amd-fsrs",      [11] = "amd-fsrc",
 
     /* 16 */                [17] = "cpuid-user-dis",
+    [18] = "epsf",          [19] = "fsrsc",
+    [20] = "amd-prefetchi",
 
     /* 26 */                [27] = "sbpb",
     [28] = "ibpb-brtype",   [29] = "srso-no",
diff --git a/xen/include/public/arch-x86/cpufeatureset.h b/xen/include/public/arch-x86/cpufeatureset.h
index eb9f552948be..11287aaabe43 100644
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++ b/xen/include/public/arch-x86/cpufeatureset.h
@@ -168,6 +168,7 @@ XEN_CPUFEATURE(TBM,           3*32+21) /*A  trailing bit manipulations */
 XEN_CPUFEATURE(TOPOEXT,       3*32+22) /*   topology extensions CPUID leafs */
 XEN_CPUFEATURE(DBEXT,         3*32+26) /*A  data breakpoint extension */
 XEN_CPUFEATURE(MONITORX,      3*32+29) /*   MONITOR extension (MONITORX/MWAITX) */
+XEN_CPUFEATURE(DBEXT2,        3*32+30) /*A  Address Mask Extentions */
 
 /* Intel-defined CPU features, CPUID level 0x0000000D:1.eax, word 4 */
 XEN_CPUFEATURE(XSAVEOPT,      4*32+ 0) /*A  XSAVEOPT instruction */
@@ -290,10 +291,17 @@ XEN_CPUFEATURE(WRMSRNS,      10*32+19) /*S  WRMSR Non-Serialising */
 XEN_CPUFEATURE(AVX_IFMA,     10*32+23) /*A  AVX-IFMA Instructions */
 
 /* AMD-defined CPU features, CPUID level 0x80000021.eax, word 11 */
+XEN_CPUFEATURE(NO_NEST_BP,         11*32+ 0) /*A  No Nested Data Breakpoints */
+XEN_CPUFEATURE(FS_GS_NS,           11*32+ 1) /*S  FS/GS base MSRs non-serialising */
 XEN_CPUFEATURE(LFENCE_DISPATCH,    11*32+ 2) /*A  LFENCE always serializing */
 XEN_CPUFEATURE(NSCB,               11*32+ 6) /*A  Null Selector Clears Base (and limit too) */
 XEN_CPUFEATURE(AUTO_IBRS,          11*32+ 8) /*S  Automatic IBRS */
+XEN_CPUFEATURE(AMD_FSRS,           11*32+10) /*A  Fast Short REP STOSB */
+XEN_CPUFEATURE(AMD_FSRC,           11*32+11) /*A  Fast Short REP CMPSB */
 XEN_CPUFEATURE(CPUID_USER_DIS,     11*32+17) /*   CPUID disable for CPL > 0 software */
+XEN_CPUFEATURE(EPSF,               11*32+18) /*A  Enhanced Predictive Store Forwarding */
+XEN_CPUFEATURE(FSRSC,              11*32+19) /*A  Fast Short REP SCASB */
+XEN_CPUFEATURE(AMD_PREFETCHI,      11*32+20) /*A  PREFETCHIT{0,1} Instructions */
 XEN_CPUFEATURE(SBPB,               11*32+27) /*A  Selective Branch Predictor Barrier */
 XEN_CPUFEATURE(IBPB_BRTYPE,        11*32+28) /*A  IBPB flushes Branch Type predictions too */
 XEN_CPUFEATURE(SRSO_NO,            11*32+29) /*A  Hardware not vulenrable to Speculative Return Stack Overflow */

base-commit: 62018f08708a5ff6ef8fc8ff2aaaac46e5a60430
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Mon Mar 18 19:42:13 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 19:42:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695126.1084666 (Exim 4.92)
	(envelope-from )
	id 1rmIrt-00027K-4A; Mon, 18 Mar 2024 19:41:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695126.1084666; Mon, 18 Mar 2024 19:41:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmIrt-00027D-1J; Mon, 18 Mar 2024 19:41:57 +0000
Received: by outflank-mailman (input) for mailman id 695126;
 Mon, 18 Mar 2024 19:41:55 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmIrr-000277-AU
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 19:41:55 +0000
Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.4])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8fc9187f-e55f-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 20:41:50 +0100 (CET)
Received: from m5p.com (mailhost.m5p.com [IPv6:2001:470:1f07:15ff:0:0:0:f7])
 by mailhost.m5p.com (8.17.1/8.15.2) with ESMTPS id 42IJfcuZ028419
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
 Mon, 18 Mar 2024 15:41:43 -0400 (EDT) (envelope-from ehem@m5p.com)
Received: (from ehem@localhost)
 by m5p.com (8.17.1/8.15.2/Submit) id 42IJfZGO028418;
 Mon, 18 Mar 2024 12:41:35 -0700 (PDT) (envelope-from ehem)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8fc9187f-e55f-11ee-a1ee-f123f15fe8a2
Date: Mon, 18 Mar 2024 12:41:35 -0700
From: Elliott Mitchell 
To: xen-devel@lists.xenproject.org
Cc: Jan Beulich , Andrew Cooper ,
        Roger Pau =?iso-8859-1?Q?Monn=E9?= ,
        Wei Liu 
Subject: Re: Serious AMD-Vi(?) issue
Message-ID: 
References: 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-Spam-Status: No, score=0.0 required=10.0 tests=KHOP_HELO_FCRDNS
	autolearn=unavailable autolearn_force=no version=4.0.0
X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on mattapan.m5p.com

I sent a ping on this about 2 weeks ago.  Since the plan is to move x86
IOMMU under general x86, the other x86 maintainers should be aware of
this:

On Mon, Feb 12, 2024 at 03:23:00PM -0800, Elliott Mitchell wrote:
> On Thu, Jan 25, 2024 at 12:24:53PM -0800, Elliott Mitchell wrote:
> > Apparently this was first noticed with 4.14, but more recently I've been
> > able to reproduce the issue:
> > 
> > https://bugs.debian.org/988477
> > 
> > The original observation features MD-RAID1 using a pair of Samsung
> > SATA-attached flash devices.  The main line shows up in `xl dmesg`:
> > 
> > (XEN) AMD-Vi: IO_PAGE_FAULT: DDDD:bb:dd.f d0 addr ffffff???????000 flags 0x8 I
> > 
> > Where the device points at the SATA controller.  I've ended up
> > reproducing this with some noticable differences.
> > 
> > A major goal of RAID is to have different devices fail at different
> > times.  Hence my initial run had a Samsung device plus a device from
> > another reputable flash manufacturer.
> > 
> > I initially noticed this due to messages in domain 0's dmesg about
> > errors from the SATA device.  Wasn't until rather later that I noticed
> > the IOMMU warnings in Xen's dmesg (perhaps post-domain 0 messages should
> > be duplicated into domain 0's dmesg?).
> > 
> > All of the failures consistently pointed at the Samsung device.  Due to
> > the expectation it would fail first (lower quality offering with
> > lesser guarantees), I proceeded to replace it with a NVMe device.
> > 
> > With some monitoring I discovered the NVMe device was now triggering
> > IOMMU errors, though not nearly as many as the Samsung SATA device did.
> > As such looks like AMD-Vi plus MD-RAID1 appears to be exposing some sort
> > of IOMMU issue with Xen.
> > 
> > 
> > All I can do is offer speculation about the underlying cause.  There
> > does seem to be a pattern of higher-performance flash storage devices
> > being more severely effected.
> > 
> > I was speculating about the issue being the MD-RAID1 driver abusing
> > Linux's DMA infrastructure in some fashion.
> > 
> > Upon further consideration, I'm wondering if this is perhaps a latency
> > issue.  I imagine there is some sort of flush after the IOMMU tables are
> > modified.  Perhaps the Samsung SATA (and all NVMe) devices were trying to
> > execute commands before reloading the IOMMU tables is complete.
> 
> Ping!
> 
> The recipe seems to be Linux MD RAID1, plus Samsung SATA or any NVMe.
> 
> To make it explicit, when I tried Crucial SATA + Samsung SATA.  IOMMU
> errors matched the Samsung SATA (a number of times the SATA driver
> complained).
> 
> As stated, I'm speculating lower latency devices starting to execute
> commands before IOMMU tables have finished reloading.  When originally
> implemented fast flash devices were rare.

Both reproductions of this issue I'm aware of were on systems with AMD
processors.  I'm doubtul suspicion of flash storage hardware is unique
to owners of AMD systems.  As a result while this /could/ also effect
Intel systems, the lack of reports /suggests/ otherwise.

I've noticed two things when glancing at the original report.  LVM is not
in use here, so that doesn't seem to effect the problem.  The Phenom II
the original reporter tested as not having the issue might have lacked
proper BIOS support, hence IOMMU not being functional.

This being a latency issue is *speculation*, but would explain the
pattern of devices being effected.

This is rather serious as it can lead to data loss (phew!  glad I just
barely dodged this outcome).


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg@m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include  O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445




From xen-devel-bounces@lists.xenproject.org Mon Mar 18 21:04:11 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 21:04:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695132.1084676 (Exim 4.92)
	(envelope-from )
	id 1rmK9A-0004Gp-0I; Mon, 18 Mar 2024 21:03:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695132.1084676; Mon, 18 Mar 2024 21:03:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmK99-0004Gi-Sr; Mon, 18 Mar 2024 21:03:51 +0000
Received: by outflank-mailman (input) for mailman id 695132;
 Mon, 18 Mar 2024 21:03:51 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmK99-0004Gc-Ee
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 21:03:51 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on20600.outbound.protection.outlook.com
 [2a01:111:f403:2417::600])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 03328497-e56b-11ee-afdd-a90da7624cb6;
 Mon, 18 Mar 2024 22:03:48 +0100 (CET)
Received: from PA7P264CA0001.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:2d3::9)
 by SA0PR12MB4413.namprd12.prod.outlook.com (2603:10b6:806:9e::9) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.26; Mon, 18 Mar
 2024 21:03:45 +0000
Received: from SN1PEPF000252A1.namprd05.prod.outlook.com
 (2603:10a6:102:2d3:cafe::c4) by PA7P264CA0001.outlook.office365.com
 (2603:10a6:102:2d3::9) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.26 via Frontend
 Transport; Mon, 18 Mar 2024 21:03:43 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 SN1PEPF000252A1.mail.protection.outlook.com (10.167.242.8) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Mon, 18 Mar 2024 21:03:42 +0000
Received: from SATLEXMB08.amd.com (10.181.40.132) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Mon, 18 Mar
 2024 16:03:41 -0500
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB08.amd.com
 (10.181.40.132) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Mon, 18 Mar
 2024 14:03:41 -0700
Received: from [172.22.164.0] (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Mon, 18 Mar 2024 16:03:40 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 03328497-e56b-11ee-afdd-a90da7624cb6
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=CEjYYKsqsBRjMoKzzcL5HKtsUmF87Ir+n+uKak+3KG5TlZui0kP/5xD8Fis6j4sSB8ufmzWOkkuN7NZ+UQLdec86WStcPKjjxtbXQBdCTeZTZqYvjjvwJ9Jl7PimGUCVrBhVBQfsdBysuCi9V2UshqRD87lrQtH5Z28EOcouJpZ/dbKpxnE0iq7XFYhiWWVry1ey2r/Fg3+PHlnLkAQFG07+j3avYra4/0luRCZnwzwwPF+NjhY/WPPKUv6C9LqOhyN/V8cDHl89t/EXrySpI8oQR/H379BeMq+CKbixzijLqnpzJEqwx7PVkSoDpximUkfgdnBSI4alyj46Vt3xxA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=OqX99EhzTzI3Q6ELp8FMSA0vDL3ywxwbPu1ksn1z+d8=;
 b=oU8ToRvUvL+uWimpN0ChsqI7b1UGZNLxzUAlaGmK97MVvbrjFY3deEAK4Vx6Rik3A0qAn9J90YHSfo7Iz/5ld58lgZdQerDkqT4TLUiCnyrL9YCNkH6Z+BxbboSR5yzKKYSJmBkXgYWcztBbGJuDiydpZ+7yfxjRvyE6w3zozL0ZIlarJWo7oTc5Hdl4YxCQa+fGetQ3XIN/AUKskr429iR+PTuLvjWZfRrU67PPrit5IdmYTomT4lhOpJVPbxD9LqHuDVVPpHpFnYydB0iBeZaAC8l0IfploKEO0qjChyW4elk44vGpcFsveif1joLESV6WQzmZ8+KiDWkLIlLNkQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=OqX99EhzTzI3Q6ELp8FMSA0vDL3ywxwbPu1ksn1z+d8=;
 b=B/gaqIyH9gIf4u/EQo4KSCK8WpzKL7AQBiw7augeFGDSOCipItDjVetH9wgYzQixoU8ksNQMZUtGLoDJtNv8ClMGjAUUdgrPdIYRj6WSSLgWKsUxukP7NGkB+es+TWA9D4XGWoiV1TXOpCC9p7P5DwRiS7OvN8pzml92mEJm2Yo=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
Message-ID: <242f4ec0-c634-4044-833e-7df3c720abc5@amd.com>
Date: Mon, 18 Mar 2024 17:03:40 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Stewart Hildebrand 
Subject: Re: [PATCH v13 10/14] vpci/header: emulate PCI_COMMAND register for
 guests
To: Jan Beulich 
CC: Oleksandr Andrushchenko ,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Andrew Cooper
	, George Dunlap ,
	"Julien Grall" , Stefano Stabellini ,
	Wei Liu , Volodymyr Babchuk ,
	
References: <20240202213321.1920347-1-stewart.hildebrand@amd.com>
 <20240202213321.1920347-11-stewart.hildebrand@amd.com>
 <180cac00-e7c4-4bea-bd13-c5983da707d7@suse.com>
Content-Language: en-US
In-Reply-To: <180cac00-e7c4-4bea-bd13-c5983da707d7@suse.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF000252A1:EE_|SA0PR12MB4413:EE_
X-MS-Office365-Filtering-Correlation-Id: 7ac4824b-5c71-4c5e-45cd-08dc478ee496
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	Rrnt4itabgnVbY3dHwcg6H6xzw2xgk7RIThQV/c+JH66HKGzpkFTHOFW7OPFGspHg76BxzmCPjyg3rxhdV74C9m1s7BCdBVq3HyOmAxHV4j1kan/OmJ1QxyulbGD5Ir0a8scuG90NK69ofdon11M8Yim1yEKOSy5o1ftoPuRSdHYhTTPxfU6JJzZVd3F9ZEQ21QG8cEktvUO3Wj8NXU3BlFJhLyF9OV7Qv75yD3ab+S6IFKwjLKvErrD7+yWTbl9TJUZd7oBMp+9joKG88ZufdqvGs5IL3ZRtRM5D/bf24WYtCINeG5uGdrFlDplLP//A42jumCEWOEKBKmk8GAPsNPJvLXUxXoPVTFmO4ksHNHOOjw6y/TwlxuxW1ts4S64SUvTV6TaZ5OtIiqdTrJoozfVtTv9zwZKSCEwvzJlC0SnVi8fhQcrVpnXvbwGB7lwfMiYHsZoCmQSwa9106z8j7JipwexyLR0Y4jvjYnQnyy/iNxWnBR70hMm+hWyn67GxXiKPnMw4qOvxuYsOQkgNQLdLlJyeZH/+r1yqlJ8tEH7OFkGHhXVVd/bx12xBemMfcn2hubYxaDdarfj3j/zxv7ELDbNiODrtE7hGEuh7WrjNnKhKGxuxVZyrxI30SC6dNxto/OhvendX/DDGTu4riIp7aHXdV00/YvZx1mZvDMtN2eT6PuU9u3t8TScd7m6gkUhvc0BLhOOWUCyH3EmFA==
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(36860700004)(376005)(82310400014)(7416005)(1800799015);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Mar 2024 21:03:42.4655
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 7ac4824b-5c71-4c5e-45cd-08dc478ee496
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF000252A1.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR12MB4413

On 2/14/24 10:41, Jan Beulich wrote:
> On 02.02.2024 22:33, Stewart Hildebrand wrote:
>> @@ -836,9 +870,20 @@ static int cf_check init_header(struct pci_dev *pdev)
>>      if ( pdev->ignore_bars )
>>          return 0;
>>  
>> -    /* Disable memory decoding before sizing. */
>>      cmd = pci_conf_read16(pdev->sbdf, PCI_COMMAND);
>> -    if ( cmd & PCI_COMMAND_MEMORY )
>> +
>> +    /*
>> +     * Clear PCI_COMMAND_MEMORY and PCI_COMMAND_IO for DomUs, so they will
>> +     * always start with memory decoding disabled and to ensure that we will not
>> +     * call modify_bars() at the end of this function.
> 
> To achieve this, fiddling with PCI_COMMAND_IO isn't necessary. Which isn't
> to say its clearing should go away; quite the other way around: Why would
> we leave e.g. PCI_COMMAND_MASTER enabled? In fact wasn't it in an earlier
> version of the series that the guest view simply started out as zero? The
> patch description still says so.

Yep, clearing PCI_COMMAND_MASTER too for domUs makes sense to me, I'll
make this change in v14. I'll also try to improve the comment.

Roger suggested at [1] that we should reflect the state of the hardware
in the command register. I'll update the patch description accordingly.

Archaeology/notes/references follow, primarily for my own reference:

Note that the rsvdp_mask will be applied to the guest_cmd value before
being returned to the guest, so no need to apply masks here.

Clearing both PCI_COMMAND_MEMORY and PCI_COMMAND_IO for domUs was
suggested by Roger at [2] and [3]. It is currently problematic for
devices assigned to domUs to have memory decoding enabled at this stage
because we don't yet have a good/generic way to initialize
bar.guest_addr taking the domU memory layout into account.

Reminder that we want to leave the PCI_COMMAND_{MASTER,MEMORY,IO} bits
unchanged for devices assigned to dom0. A description of why can be
found in the commit message of:

53d9133638c3 ("pci: do not disable memory decoding for devices").

[1] https://lore.kernel.org/xen-devel/ZLqI65gmNj1XDBm4@MacBook-Air-de-Roger.local/
[2] https://lore.kernel.org/xen-devel/ZRquRcRz-K43WeMc@MacBookPdeRoger/
[3] https://lore.kernel.org/xen-devel/ZVy73iJ3E8nJHvgf@macbook.local/

>> --- a/xen/drivers/vpci/msi.c
>> +++ b/xen/drivers/vpci/msi.c
>> @@ -70,6 +70,13 @@ static void cf_check control_write(
>>  
>>          if ( vpci_msi_arch_enable(msi, pdev, vectors) )
>>              return;
>> +
>> +        /* Make sure domU doesn't enable INTx while enabling MSI. */
>> +        if ( !is_hardware_domain(pdev->domain) )
>> +        {
>> +            pci_intx(pdev, false);
>> +            pdev->vpci->header.guest_cmd |= PCI_COMMAND_INTX_DISABLE;
>> +        }
> 
> While here we're inside "if ( new_enabled )", ...
> 
>> --- a/xen/drivers/vpci/msix.c
>> +++ b/xen/drivers/vpci/msix.c
>> @@ -135,6 +135,13 @@ static void cf_check control_write(
>>          }
>>      }
>>  
>> +    /* Make sure domU doesn't enable INTx while enabling MSI-X. */
>> +    if ( new_enabled && !msix->enabled && !is_hardware_domain(pdev->domain) )
>> +    {
>> +        pci_intx(pdev, false);
>> +        pdev->vpci->header.guest_cmd |= PCI_COMMAND_INTX_DISABLE;
>> +    }
> 
> .. here you further check that it's actually a 0->1 transition? Why
> not alike for MSI?

Good catch, we should similarly check for a 0->1 transition for MSI.
I'll fix it.


From xen-devel-bounces@lists.xenproject.org Mon Mar 18 21:19:48 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 21:19:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695135.1084685 (Exim 4.92)
	(envelope-from )
	id 1rmKOU-0006UT-8q; Mon, 18 Mar 2024 21:19:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695135.1084685; Mon, 18 Mar 2024 21:19:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmKOU-0006UM-6C; Mon, 18 Mar 2024 21:19:42 +0000
Received: by outflank-mailman (input) for mailman id 695135;
 Mon, 18 Mar 2024 21:19:40 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmKOS-0006UG-UJ
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 21:19:40 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on20600.outbound.protection.outlook.com
 [2a01:111:f403:2418::600])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 38f70f5f-e56d-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 22:19:37 +0100 (CET)
Received: from BN9PR03CA0891.namprd03.prod.outlook.com (2603:10b6:408:13c::26)
 by CH3PR12MB7641.namprd12.prod.outlook.com (2603:10b6:610:150::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.27; Mon, 18 Mar
 2024 21:19:34 +0000
Received: from BN1PEPF00004688.namprd05.prod.outlook.com
 (2603:10b6:408:13c:cafe::1f) by BN9PR03CA0891.outlook.office365.com
 (2603:10b6:408:13c::26) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.26 via Frontend
 Transport; Mon, 18 Mar 2024 21:19:34 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN1PEPF00004688.mail.protection.outlook.com (10.167.243.133) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Mon, 18 Mar 2024 21:19:34 +0000
Received: from SATLEXMB06.amd.com (10.181.40.147) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Mon, 18 Mar
 2024 16:19:33 -0500
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB06.amd.com
 (10.181.40.147) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Mon, 18 Mar
 2024 16:19:33 -0500
Received: from [172.21.216.216] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Mon, 18 Mar 2024 16:19:32 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 38f70f5f-e56d-11ee-a1ee-f123f15fe8a2
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=cB/rDWXK9ZlmHYqGfM+WBjM16yLrEeoZh7DgChCv/6/nHj/qSbsIgvYkCU/pwXkzruaqwgLlg/WGmmZdhmbDBH9a3J15V005Mzu8IQtgihxlDASvtIUppUE/k3AbHWoiSOVwkNwfz6soEiNFDomt+CbUD9V7sR1fVDspYRy8xrXZcPAhWhG7zpEOouzk6hXI0VdyERVgRm1nCo4cSRGcbYmgTBj51davkjkTJO3zGoDHaDfcUSWRHreYDfgZZF5QcK5Jmlenf6CR71RwOU/qT+owR24MAibym11llHLE0b89fOpS2KdQDWXzkDBa7WFSIVW0CvBv/Hhh3MwkzWmXzw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Q+rZjqPCJXjW6MluSM4Nqyv82XjBn/kSPGLI+d6DwM8=;
 b=f3UDar920FfWgSb/SI1iz+voeC9aBjt+Jnm0486BNj0dGneTsjkjgJzJ1BkswzQBEIkruq/iGMzM8UC3pvnVlbT8jEIm/1wbRjdxOsTGod/sH+hZg0yykgo27Si2Wo0iqpXS/BLSmjP/tIOrriO6n0qzGg+ahgVUHlHuH5hflBH5Uy/HmHPNDAx3eIS0hk4hmC9AxWVAZ04sLA3F9QPI9NLg4THEVLcPxSE4jWaZ73+BOTANbOD8r3LR9EfjLHogH/b4QOK4cdrhcXk/siaA2xM7ESPUeWnlXiI7rTZvnSRKYlzKScr4v1hkjpVfCQ6EcB4A/s9lN/ZigFiyNH/dYg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=Q+rZjqPCJXjW6MluSM4Nqyv82XjBn/kSPGLI+d6DwM8=;
 b=x1RhcJrvM99cDKm6vhWh82kJjhim3UMiqWgkJTUrF/qDFik84R+L3+BdV9cK5XbxtLOEtKWLmwgPjnte76bIRlID99V2qZCPU0H1GKTphhb1A1XrOsQfeFolOAKVhKcvXwLqwGyLsEywebva7WK+PlY69hThEFd1hwGT0E2hEPA=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Message-ID: <769e4e95-1c76-4e07-b623-27b35ef388ef@amd.com>
Date: Mon, 18 Mar 2024 17:19:32 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Jason Andryuk 
Subject: Re: [PATCH v2 3/3] x86/PVH: Support relocatable dom0 kernels
To: Jan Beulich 
CC: Andrew Cooper ,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu
	, George Dunlap , Julien Grall
	, Stefano Stabellini ,
	
References: <20240313193021.241764-1-jason.andryuk@amd.com>
 <20240313193021.241764-4-jason.andryuk@amd.com>
 <945609d6-741e-4934-a4f2-6e5597ce5dcd@suse.com>
 
 <43c49aa6-d690-467e-8ce3-ca37b9d41e76@suse.com>
Content-Language: en-US
In-Reply-To: <43c49aa6-d690-467e-8ce3-ca37b9d41e76@suse.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN1PEPF00004688:EE_|CH3PR12MB7641:EE_
X-MS-Office365-Filtering-Correlation-Id: cded4abb-773f-4775-cd88-08dc47911c15
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	7PeIoTGlobISdYDo+XplnYPUxOJa5swlmqPqh/BQJ7PPLg0bDj1sVH88iLksgPHssREwAR010b3F5nmJAuWOfcMCq/mpTkJxtlEHgoleFX00h493ScbhhkHwIz9iaOQP3Z1B6AQr7JXgkbouruDq17VS8l1ORuwhskkvFZavyTH3K8qcsU8hwDtozw2D2AKeGGGVk/03tmmd6bxRSGpafWKfeBSO9xEHM3RlmzLUGphM9lXF1V6qCLjyb8S0vv3NWiTdTyJ89/s27cnMX6IIK2geO2WEuEQ/LuqadvqA2dQYWDEqdsUcPZEsIVM1Dfz014cecbWVqYx0TTfE/zKPyhHsX0HSWfC2GtlSWmQAzb5F3cFUffYEHkqmHe+QjbSuBpbMVfSYpqR+SpZaHCHvmAJ1TWaKj4YU5KF+Qvo7Ijgl2kuMij701qd6DJcjwxwATZ//XOmjvPmNnTSXg6ow55Fzq92MCaHBQJ5vrsM2Dp01OyH8PvPVIE/qafGkibgCT8cQHJ4Qz3HBIAgkCuZW+5vWEzmqvvZn6bUzjPy0AM/OLEDXPULdx9Q0x4owXA/NctyDPJI0meuDCZe3TBh6QbKE99KIN+6/xsTZFiA7SDqNQ/g3GSj9NxlAWcSrKTsEKNxGcURt41KaAI1TCAcKS+ZmyPAo2JLgzGrUEBAzFNwN/YoYn+OJb6BOmoY4uNF0k86CXcp37ajwUMFIVmWBcU+ofsVqaSreArTDazN2QR1FZ1U7/kpk7rrH7h7FkJLG
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(82310400014)(1800799015)(376005)(36860700004);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Mar 2024 21:19:34.5226
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: cded4abb-773f-4775-cd88-08dc47911c15
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN1PEPF00004688.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB7641

On 2024-03-14 10:19, Jan Beulich wrote:
> On 14.03.2024 15:13, Jason Andryuk wrote:
>> On 2024-03-14 09:21, Jan Beulich wrote:
>>> On 13.03.2024 20:30, Jason Andryuk wrote:
>>>> --- a/xen/include/public/elfnote.h
>>>> +++ b/xen/include/public/elfnote.h
>>>> @@ -194,6 +194,17 @@
>>>>     */
>>>>    #define XEN_ELFNOTE_PHYS32_ENTRY 18
>>>>    
>>>> +/*
>>>> + * Physical loading constraints for PVH kernels
>>>> + *
>>>> + * Used to place constraints on the guest physical loading addresses and
>>>> + * alignment for a PVH kernel.  This note's value is 3 64bit values in
>>>> + * the following order: minimum, maximum and alignment.
>>>
>>> Along the lines of what I said on another sub-thread, I think at least
>>> alignment wants to be optional here. Perhaps, with max going first, min
>>> could also be optional.
>>
>> Interesting idea.
>>
>>> As indicated in different context by Roger, the values being uniformly
>>> 64-bit ones also is questionable.
>>>
>>>> + * The presence of this note indicates the kernel is relocatable.
>>>
>>> I think it wants making explicit here that the act of relocating is still
>>> left to the kernel.
>>
>> Ok.
>>
>> How is this for a new description?
>>
>> """
>> Physical loading constraints for PVH kernels
>>
>> Used to place constraints on the guest physical loading addresses and
>> alignment for a PVH kernel.
>>
>> The presence of this note indicates the kernel supports relocating itself.
>>
>> The note may include up to three 32bit values.
> 
> I'm as unsure about always 32-bit as I am on it being uniformly 64-bit.
> One question here is whether this note is intended to be x86-specific.
> 
>>    - a maximum address for the entire image to be loaded below (default
>> 0xfffffff)
> 
> One f too few?

Whoops - yes.

>>    - a minimum address for the start of the image (default 0)
>>    - a required start alignment (default 1)

Jan, in the discussion of patch 1, you wrote "Hmm, shouldn't the order 
of attempts to figure the alignment be ELF note, ELF header, and then 
2Mb?"  My latest revision initializes phys_alignment to 1 and updates 
that if PHYS32_RELOC specifies an alignment.  Do you still want these 
other locations checked for alignment values?

Regards,
Jason


From xen-devel-bounces@lists.xenproject.org Mon Mar 18 21:21:33 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Mar 2024 21:21:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695137.1084697 (Exim 4.92)
	(envelope-from )
	id 1rmKQG-0007tr-MN; Mon, 18 Mar 2024 21:21:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695137.1084697; Mon, 18 Mar 2024 21:21:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmKQG-0007tk-I1; Mon, 18 Mar 2024 21:21:32 +0000
Received: by outflank-mailman (input) for mailman id 695137;
 Mon, 18 Mar 2024 21:21:31 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmKQF-0007tc-Ja
 for xen-devel@lists.xenproject.org; Mon, 18 Mar 2024 21:21:31 +0000
Received: from NAM02-BN1-obe.outbound.protection.outlook.com
 (mail-bn1nam02on20601.outbound.protection.outlook.com
 [2a01:111:f403:2407::601])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7bb6d9fb-e56d-11ee-a1ee-f123f15fe8a2;
 Mon, 18 Mar 2024 22:21:29 +0100 (CET)
Received: from BN9PR03CA0524.namprd03.prod.outlook.com (2603:10b6:408:131::19)
 by CYXPR12MB9277.namprd12.prod.outlook.com (2603:10b6:930:d8::19)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.27; Mon, 18 Mar
 2024 21:21:26 +0000
Received: from BN1PEPF0000468A.namprd05.prod.outlook.com
 (2603:10b6:408:131:cafe::eb) by BN9PR03CA0524.outlook.office365.com
 (2603:10b6:408:131::19) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.36 via Frontend
 Transport; Mon, 18 Mar 2024 21:21:26 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN1PEPF0000468A.mail.protection.outlook.com (10.167.243.135) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Mon, 18 Mar 2024 21:21:25 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Mon, 18 Mar
 2024 16:21:24 -0500
Received: from [172.21.216.216] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Mon, 18 Mar 2024 16:21:23 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7bb6d9fb-e56d-11ee-a1ee-f123f15fe8a2
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=Lfrd8JjV1yiilTqaZKSklb4zq3t65y4/cFE+L4VWjP4ya01F4PYRIC3N9xeNK0NT0OU7CpTba2VoaY5JS0d8jqxJptU8gwa9Azj8c10/m6j6iO+h5c+F+VYpci1tir4R93a82m7fB8PFs0Wwg57ptKuAvlm1tsIa68B90sQMOI+yXPv9yaLGKi7DffhWLTgbArbscf9AVUeMLwZY+j51fpc5VvcICiO2l+/o0TF5jnpR7Vo8PlZe1q27ndRzH9pxaSdTH58jdYybtzqKwFPQvu5FXIIwO1SgHaZhKPGWQ2Pb9s6qP82SuBKpuOyXqBreoI31Ssyyy9xix6sT6Sl/Zw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=n8V58abC6y7/v0VQJ//5e3QNkh8LLiiWKHsc9lSKePQ=;
 b=Yl1vujwS4ZSImBMAJnp5DA0hCv1kbk5H3ttj2ug/+CY6sFU5eSmuRoRmmaYvy7zzgmD3cK4TxO15Iy+j5Z8S8NcPQKyNxpHpaMlEk1TTF3SqClMUW+218X57k2ylqIpX0j0hgfghYSckzc13fckfLvMD0fbpnpbxBSmUSJcFCZh7vfP7lQPvoKi8ThQpb9Hktq/nG3luTolSK1F6QiinkzajoksjN8BeUgqXLRjkncPfHV2F0bLDXKx0T+BaLpN+HDcgwDXpiCOCA1FddHgOu3Ltp86fdQyPDvQfeNsHmGTQhZTUfMwvN8gKUG+kY2qDiUsdCckAAzmrY7zhELA3ww==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=n8V58abC6y7/v0VQJ//5e3QNkh8LLiiWKHsc9lSKePQ=;
 b=2uVtHXfoL9yTj7tP3ZLKAyK5Ie4iI7BWKAL+A7UNfdOvuHDWo/sBVHoq1Sl5Xsi1WRI9ysOakGMRp7YKUY0r6OT9IPiNWO9MloR/xi9NtAM1ZPmLIPkZt6ZAyB/giO7tjFeQcPiuoWM9hJJTd0HgCDCAD/GamoWMpLD7+byny5k=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Message-ID: 
Date: Mon, 18 Mar 2024 17:21:18 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Jason Andryuk 
Subject: Re: [PATCH v2 3/3] x86/PVH: Support relocatable dom0 kernels
To: Jan Beulich 
CC: Andrew Cooper ,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu
	, George Dunlap , Julien Grall
	, Stefano Stabellini ,
	
References: <20240313193021.241764-1-jason.andryuk@amd.com>
 <20240313193021.241764-4-jason.andryuk@amd.com>
 <12fe48a6-6957-49d7-adf5-1a3ac8b1bfaa@suse.com>
 <7506abe0-e3d4-44f7-b54d-592ae2e3fd3e@amd.com>
 <88bd8577-42e6-4087-9888-00cd73e7f0bc@suse.com>
Content-Language: en-US
In-Reply-To: <88bd8577-42e6-4087-9888-00cd73e7f0bc@suse.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB04.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN1PEPF0000468A:EE_|CYXPR12MB9277:EE_
X-MS-Office365-Filtering-Correlation-Id: 6dc3520f-50d6-4b90-e78a-08dc47915e84
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	bLllJIUzFYCMqSESLbw0j4cEIppspdEQYMBKd3VUU1sGiDliVAi+l9XdFrWe0Y75aJ8rgr8tj31/dDtCS6LXWtQCKq6zT36hJ68UdCjohoEdMYoclrS0luDsN+jwJM0ikpK2Vaw1pJeyHl+1gWO/zJlAEj2Rpf6fxCi2cePftxg7bVUUmvLPGe6GUsS1vuQ56uYcpHn4E1V+ClqwVRTYgQZ4zEpFv4KrzyOe16HHWOFseSn4eO/ntyGN9qC2PmjYm85dBoAdMntH27PKS0S4nrTWX07Y7riVqZQrqMc/9nqelNPHUfZSFQTkcfufyV0GGc612Hq9XWgIKY+72qrtlZPwAP95uCUg11Aymdp3EcqjtN033fHHx6q1d2g/d5pMGWKefdnsJJQcs/oXtnc31lU1U8yWRE5CJvC08ebWoUS3J86O50CCNfQaIcaLDRj9n/Hm5M0Qpp0lAwEzJj9VS0G8rbFj+mynm2in9EhFagJf0ymAmGgj97HCHbP2aJE6gUYNhOfaZntDT8Y5h80BO5G3os2Sh8V5QFVPvlhIcO9t4W1nowziyz8COhCbFR8bCTBFjeLn3Mv7D+jfRz0mynAEGdnItCPAH4Yci7uujMpnHf83fDFYusYGbKJWpsCMSwDEjXcVvWphU8w0KbLbVcP9p2gWZ9oLxK0YGMUsAaICew5UJbIol/c5Zd3mj7blId3M3SoBseRCOgyD5PuQAW3zCgCMircCxhJz48ONJ4mXHeYcgm/fp1CgIVnLQO6t
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(82310400014)(36860700004)(376005)(1800799015);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Mar 2024 21:21:25.9490
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 6dc3520f-50d6-4b90-e78a-08dc47915e84
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN1PEPF0000468A.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CYXPR12MB9277

On 2024-03-15 05:48, Jan Beulich wrote:
> On 14.03.2024 20:19, Jason Andryuk wrote:
>> On 2024-03-14 09:31, Jan Beulich wrote:
>>> On 13.03.2024 20:30, Jason Andryuk wrote:
>>>> --- a/xen/arch/x86/hvm/dom0_build.c
>>>> +++ b/xen/arch/x86/hvm/dom0_build.c
>>>> @@ -537,6 +537,108 @@ static paddr_t __init find_memory(
>>>>        return INVALID_PADDR;
>>>>    }
>>>>    
>>>> +static bool __init check_load_address(
>>>> +    const struct domain *d, const struct elf_binary *elf)
>>>> +{
>>>> +    paddr_t kernel_start = (paddr_t)elf->dest_base & PAGE_MASK;
>>>> +    paddr_t kernel_end = PAGE_ALIGN((paddr_t)elf->dest_base + elf->dest_size);
>>>
>>> Both casts act on a pointer value. Such cannot legitimately be converted
>>> to paddr_t; it only so happens that paddr_t is effectively the same as
>>> uintptr_t right now. (Same issue again further down.) That said, I notice
>>> we have pre-existing examples of this ...
>>
>> Yes, I followed existing code.  Do you want dest_base to be switched to
>> a uintptr_t?
> 
> I think it was deliberately switched to being a pointer at some point,
> maybe even in a security fix.

commit 65808a8ed41cc7c044f588bd6cab5af0fdc0e029 "libelf: check all 
pointer accesses", part of XSA-55, switched from a single dest pointer 
to dest_base & dest_size.

For libxenguest, it's a pointer to guest-mapped memory to copy in the 
kernel.  For PV dom0 creation, it's a pointer - Xen switches to the dom0 
page tables and performs the copy with it as-is.  For PVH dom0, it's a 
guest physical address.

Are you looking for this to be addressed in this series?

>>>> +/* Check the kernel load address, and adjust if necessary and possible. */
>>>> +static bool __init check_and_adjust_load_address(
>>>> +    const struct domain *d, struct elf_binary *elf, struct elf_dom_parms *parms)
>>>> +{
>>>> +    paddr_t reloc_base;
>>>> +
>>>> +    if ( check_load_address(d, elf) )
>>>> +        return true;
>>>> +
>>>> +    if ( parms->phys_align == UNSET_ADDR )
>>>> +    {
>>>> +        printk("Address conflict and %pd kernel is not relocatable\n", d);
>>>> +        return false;
>>>> +    }
>>>> +
>>>> +    reloc_base = find_kernel_memory(d, elf, parms);
>>>> +    if ( reloc_base == 0 )
>>>> +    {
>>>> +        printk("Failed find a load address for the kernel\n");
>>>> +        return false;
>>>> +    }
>>>> +
>>>> +    if ( opt_dom0_verbose )
>>>> +        printk("Relocating kernel from [%lx, %lx] -> [%lx, %lx]\n",
>>>> +               (paddr_t)elf->dest_base,
>>>> +               (paddr_t)elf->dest_base + elf->dest_size,
>>>
>>> By using %p you clearly can avoid the casts here.
>>
>> Ok.
>>
>>>> +               reloc_base, reloc_base + elf->dest_size);
>>>
>>> I'm not convinced %lx is really appropriate for paddr_t.
>>
>> PRIpaddr exists.  It's "016lx" for x86.  Using that and %p add lots of 0s:
>> (XEN) Relocating kernel from [0000000001000000, 000000000202ffff] ->
>> [0000000002200000, 000000000322ffff]
> 
> That's to be accepted, I guess.
> 
> Looking at it again, is "Relocating" in the log message perhaps misleading?
> We don't relocate it, that's something the kernel itself has to do. We only
> put it at other than the default position. Maybe "Moving" instead?

Yes, "Moving" sounds better.  I guess I'll drop the "from" and insert a 
%pd for:

(XEN) Moving d0 kernel [0000000001000000, 000000000202ffff] -> 
[0000000002200000, 000000000322ffff]

Regards,
Jason


From xen-devel-bounces@lists.xenproject.org Tue Mar 19 01:31:53 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 01:31:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695181.1084718 (Exim 4.92)
	(envelope-from )
	id 1rmOKF-00051r-Ka; Tue, 19 Mar 2024 01:31:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695181.1084718; Tue, 19 Mar 2024 01:31:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmOKF-00051j-DV; Tue, 19 Mar 2024 01:31:35 +0000
Received: by outflank-mailman (input) for mailman id 695181;
 Tue, 19 Mar 2024 01:31:34 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmOKE-00051Z-9u; Tue, 19 Mar 2024 01:31:34 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmOKE-00061P-4j; Tue, 19 Mar 2024 01:31:34 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmOKD-0000cD-AE; Tue, 19 Mar 2024 01:31:33 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rmOKD-0007uS-98; Tue, 19 Mar 2024 01:31:33 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=lCp5FiDIPjmXUG1pFMTG7ZkYC3cYQpKgIiIxBuqGiDk=; b=iu/85XcAzeep4ItrLbwCnPxQ+V
	8w1UPI7H90rK5d5rUdDbmKkwmkuFxfgBvZkJGIec0NpyHqlOQrVk3oExiwZXceh4cmUfxKWP5Okna
	LMv61vegvd267mIlkP0YPaqkLDdwaIV3Hqjx9ww95C1fa2C3a1qo02ieanqb9r3wekt8=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 185075: tolerable FAIL - PUSHED
X-Osstest-Failures:
    linux-linus:test-amd64-amd64-freebsd12-amd64:guest-start:fail:heisenbug
    linux-linus:test-amd64-amd64-pair:guest-migrate/dst_host/src_host/debian.repeat:fail:heisenbug
    linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    linux=f6cef5f8c37f58a3bc95b3754c3ae98e086631ca
X-Osstest-Versions-That:
    linux=906a93befec826475ab3d4facacc57a0b0a002a5
From: osstest service owner 
Date: Tue, 19 Mar 2024 01:31:33 +0000

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-freebsd12-amd64 13 guest-start     fail pass in 185086-retest
 test-amd64-amd64-pair 28 guest-migrate/dst_host/src_host/debian.repeat fail pass in 185086-retest

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

version targeted for testing:
 linux                f6cef5f8c37f58a3bc95b3754c3ae98e086631ca
baseline version:
 linux                906a93befec826475ab3d4facacc57a0b0a002a5

Last test of basis   185069  2024-03-17 21:12:38 Z    1 days
Testing same since   185075  2024-03-18 07:48:04 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Alexandre Belloni 
  Conor Dooley 
  Dylan Hung 
  Jeremy Kerr 
  Krzysztof Kozlowski 
  Linus Torvalds 
  Ricardo B. Marliere 

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-freebsd11-amd64                             pass    
 test-amd64-amd64-freebsd12-amd64                             fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        fail    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-libvirt-qcow2                               pass    
 test-armhf-armhf-libvirt-qcow2                               pass    
 test-amd64-amd64-libvirt-raw                                 pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-amd64-xl-vhd                                      pass    
 test-arm64-arm64-xl-vhd                                      pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

Explanation of these 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 :

hint: The 'hooks/update' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
hint: The 'hooks/post-receive' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
hint: The 'hooks/post-update' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
To xenbits.xen.org:/home/xen/git/linux-pvops.git
   906a93befec8..f6cef5f8c37f  f6cef5f8c37f58a3bc95b3754c3ae98e086631ca -> tested/linux-linus


From xen-devel-bounces@lists.xenproject.org Tue Mar 19 03:33:01 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 03:33:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695191.1084733 (Exim 4.92)
	(envelope-from )
	id 1rmQDa-0003x8-4v; Tue, 19 Mar 2024 03:32:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695191.1084733; Tue, 19 Mar 2024 03:32:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmQDa-0003x1-1m; Tue, 19 Mar 2024 03:32:50 +0000
Received: by outflank-mailman (input) for mailman id 695191;
 Tue, 19 Mar 2024 03:32:49 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmQDY-0003wv-Sc
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 03:32:48 +0000
Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 59631fb4-e5a1-11ee-a1ee-f123f15fe8a2;
 Tue, 19 Mar 2024 04:32:46 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sin.source.kernel.org (Postfix) with ESMTP id 8AAB5CE0121;
 Tue, 19 Mar 2024 03:32:43 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 85285C433C7;
 Tue, 19 Mar 2024 03:32:41 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 59631fb4-e5a1-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1710819162;
	bh=kmmOI6qXEjivvJs+ffFofBzmRsJOKb9z+WudcXWCX9w=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=n1Y25bTenLtIHyW9bOjWa0/pwYrzdBsVGp567b03FRGax6xDXon5dpNBlRZYlZl1R
	 6vaxCCUNYsgzRVEErq8EmyB3gqNd3p3FiNgM/iq/V1w41Su37PJ91tHLVyGAdD69ah
	 BQxAVGlE3ju3gvSjDhsfDfKYWr+Yq5aforAFJgdm4ycXNsJTOUYURb8gyb7rUF/wgy
	 PrgUmgEa1KlhACFsZwcwJWO0RIDxSas6TQtTNb+wW5xn2e3KR+COe2nzrJLs4bWFgm
	 lrxqXxEdrRsDZWsZMXFSCqBXqJqo2HB3ztcCZc8Hq46pT82q5znmML6Q/uMSoPAqMc
	 0UjGdYRHwAFjg==
Date: Mon, 18 Mar 2024 21:32:39 -0600 (MDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Nicola Vetrini 
cc: xen-devel@lists.xenproject.org, sstabellini@kernel.org, 
    michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, 
    consulting@bugseng.com, "Daniel P. Smith" 
Subject: Re: [XEN PATCH 03/10] xen/xsm: add parentheses to comply with MISRA
 C Rule 20.7
In-Reply-To: <4eeb9be581e3fa07378f5a7deb23c9066474638b.1710762555.git.nicola.vetrini@bugseng.com>
Message-ID: 
References:  <4eeb9be581e3fa07378f5a7deb23c9066474638b.1710762555.git.nicola.vetrini@bugseng.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Mon, 18 Mar 2024, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be safe with respect to expansions that
> can possibly alter the semantics of the passed-in macro parameter.
> 
> No functional change.
> 
> Signed-off-by: Nicola Vetrini 
 
Reviewed-by: Stefano Stabellini 


From xen-devel-bounces@lists.xenproject.org Tue Mar 19 03:33:01 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 03:33:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695192.1084744 (Exim 4.92)
	(envelope-from )
	id 1rmQDf-0004Co-By; Tue, 19 Mar 2024 03:32:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695192.1084744; Tue, 19 Mar 2024 03:32:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmQDf-0004Ch-8u; Tue, 19 Mar 2024 03:32:55 +0000
Received: by outflank-mailman (input) for mailman id 695192;
 Tue, 19 Mar 2024 03:32:54 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmQDe-0003wv-1T
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 03:32:54 +0000
Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5cf4ecd4-e5a1-11ee-a1ee-f123f15fe8a2;
 Tue, 19 Mar 2024 04:32:52 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sin.source.kernel.org (Postfix) with ESMTP id D5CA4CE0C06;
 Tue, 19 Mar 2024 03:32:49 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 44C79C433F1;
 Tue, 19 Mar 2024 03:32:47 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5cf4ecd4-e5a1-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1710819169;
	bh=lPj/oTZCgFBqvfjUslvjV05lRJo3jJ1F11An7BIiqQc=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=DVWW7Thro7CvBDHAtqjoiV5b5NFNEi0SPJsdaZUEru5Rr9WTdjMYHSUcodCWyTAHr
	 R+xhEgVX9+2TF6MevDpotctMAu4Hh/q7N75vPaKmOwJjN+oyszispDyOYxUSRfZRCE
	 aPqUQ2OeNgDIRPq+PRtW4E+Ox11z9cB/AsJvrw5UlI92ntz6g4Ur8JkJSYXQt7sdrc
	 3V8VjS4kdK0lhwX6YcRxN8ilMuw0fWTLVzFpeO01ADD4BFLfThwHepUSJ1RzpKDnGZ
	 4hqzN99WZIVp75K3F0Y/U/3tvRtmIEN0Fy7WdgKrowbXUM0Gy+UTbh7rWzhwBf9VjA
	 brbbcBBYTKM+w==
Date: Mon, 18 Mar 2024 21:32:45 -0600 (MDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Nicola Vetrini 
cc: xen-devel@lists.xenproject.org, sstabellini@kernel.org, 
    michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, 
    consulting@bugseng.com, Julien Grall , 
    Rahul Singh , 
    Bertrand Marquis , 
    Volodymyr Babchuk 
Subject: Re: [XEN PATCH 06/10] xen/arm: smmu: address violations of MISRA C
 Rule 20.7
In-Reply-To: <50ec3074772b0c58bef446d1c06aa41db04a66d0.1710762555.git.nicola.vetrini@bugseng.com>
Message-ID: 
References:  <50ec3074772b0c58bef446d1c06aa41db04a66d0.1710762555.git.nicola.vetrini@bugseng.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Mon, 18 Mar 2024, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be safe with respect to expansions that
> can possibly alter the semantics of the passed-in macro parameter.
> 
> No functional change.
> 
> Signed-off-by: Nicola Vetrini 

Reviewed-by: Stefano Stabellini 
 


From xen-devel-bounces@lists.xenproject.org Tue Mar 19 03:33:18 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 03:33:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695194.1084757 (Exim 4.92)
	(envelope-from )
	id 1rmQE2-0004pN-Kd; Tue, 19 Mar 2024 03:33:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695194.1084757; Tue, 19 Mar 2024 03:33:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmQE2-0004pE-I1; Tue, 19 Mar 2024 03:33:18 +0000
Received: by outflank-mailman (input) for mailman id 695194;
 Tue, 19 Mar 2024 03:33:17 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmQE1-0003wv-3P
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 03:33:17 +0000
Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6aa3a620-e5a1-11ee-a1ee-f123f15fe8a2;
 Tue, 19 Mar 2024 04:33:15 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sin.source.kernel.org (Postfix) with ESMTP id 0A066CE08D4;
 Tue, 19 Mar 2024 03:33:13 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id EDBCAC433F1;
 Tue, 19 Mar 2024 03:33:10 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6aa3a620-e5a1-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1710819192;
	bh=BhwU4HC5QYEwU9zq/KGOAxnObTvAl0v2AzcqP8ga7oI=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=R19cf63oLsm/tD6Fm0gso/oCSQStF7TQj5bqiLP4Sw8M7z4hYLZJ5PAfpTg6dpi1m
	 Qtn5rs3niB0q1EmmC0bJ9Ic7IoOopuQnpye+TCUnah5EPavfZQuvhBZRphguZSKdeR
	 i1MIS1uS3fEjhkEINqjoZHMwoccpZZkrOtilCJW3x8x2hwMofMBMLPANTaLdsvjEW1
	 YQxw85KHH8V9TKG5y+5lMO1SMw2zMY03yOs7tNgLgDBby7e2GjK3Gj7CHRRcGGARfl
	 x7E+PhqEC80Kn7dNZpkIDZ7V9660oaxGgecXUgTsYnQSkZEzaV6aPmOaZwEMFYDTyP
	 +pUfQM7HmeCAA==
Date: Mon, 18 Mar 2024 21:33:09 -0600 (MDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Nicola Vetrini 
cc: xen-devel@lists.xenproject.org, sstabellini@kernel.org, 
    michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, 
    consulting@bugseng.com, Julien Grall 
Subject: Re: [XEN PATCH 04/10] xen/device_tree: address violations of MISRA
 C Rule 20.7
In-Reply-To: <3845d2a318bdaab242a7fd67473b05198db1b111.1710762555.git.nicola.vetrini@bugseng.com>
Message-ID: 
References:  <3845d2a318bdaab242a7fd67473b05198db1b111.1710762555.git.nicola.vetrini@bugseng.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Mon, 18 Mar 2024, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be safe with respect to expansions that
> can possibly alter the semantics of the passed-in macro parameter.
> 
> No functional change.
> 
> Signed-off-by: Nicola Vetrini 
 

Reviewed-by: Stefano Stabellini 


From xen-devel-bounces@lists.xenproject.org Tue Mar 19 03:34:20 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 03:34:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695198.1084768 (Exim 4.92)
	(envelope-from )
	id 1rmQF1-0005WE-Ta; Tue, 19 Mar 2024 03:34:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695198.1084768; Tue, 19 Mar 2024 03:34:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmQF1-0005W7-Qd; Tue, 19 Mar 2024 03:34:19 +0000
Received: by outflank-mailman (input) for mailman id 695198;
 Tue, 19 Mar 2024 03:34:18 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmQF0-0005Vz-N9
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 03:34:18 +0000
Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8f6a3970-e5a1-11ee-afdd-a90da7624cb6;
 Tue, 19 Mar 2024 04:34:17 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sin.source.kernel.org (Postfix) with ESMTP id 7A69ECE0121;
 Tue, 19 Mar 2024 03:34:14 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id A1220C433C7;
 Tue, 19 Mar 2024 03:34:11 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8f6a3970-e5a1-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1710819253;
	bh=yYNG7cSPbnmEtmB+CRtd2MkjfHvFqvox03ay3lIvpRE=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=dsfmPD9KVhpUxgxxk5Uae1JTJy+vAtXBblzk3M57vqudh9A9Lfm/da1afSwEMHhlH
	 D9WBNwSTUdNNi6PEGJXozXutle+GGBqay7wyC9VQjlGxGa4zkHo3KLAzF7ehouR10F
	 YgZES0nniSotFMwDRQxtEcvAwVQJGfA0xWHRC37TjJ1yKHl2j9l1SzCylqQYImKtOq
	 X5U4I9HMML6T7QJKLt4Wc5xSFNbUGJq9QX/XqHLwxDLzdsYYoRGtqjnY7bkZhB0+u5
	 b6YzKq6rDzLw6nab2g4KKMDe1TVVVjEGAGavsHiqKE2+byUTjrPneC31t3fFIzeIRg
	 WtI3NDahXcKpA==
Date: Mon, 18 Mar 2024 21:34:10 -0600 (MDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich 
cc: Stefano Stabellini , consulting@bugseng.com, 
    Andrew Cooper , 
    George Dunlap , Julien Grall , 
    Wei Liu , Bertrand Marquis , 
    Michal Orzel , 
    Volodymyr Babchuk , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    xen-devel@lists.xenproject.org, 
    Simone Ballarin 
Subject: Re: [XEN PATCH v3 03/16] misra: add deviations for direct inclusion
 guards
In-Reply-To: <0513e505-5444-4a9f-9a77-ec9f359ddf27@suse.com>
Message-ID: 
References:  <1fdfec12fd2207c294f50d01d8ec32f890b915d7.1710145041.git.simone.ballarin@bugseng.com>  <6472eb42-157a-4d6e-b5bb-daa74fbbd97b@bugseng.com>
  <3e4bb597-3624-418e-93d0-b95042fd27a7@bugseng.com>  <077c0373-6eec-4403-b31e-574c8e8ae067@suse.com> 
 <0513e505-5444-4a9f-9a77-ec9f359ddf27@suse.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Mon, 18 Mar 2024, Jan Beulich wrote:
> On 16.03.2024 01:43, Stefano Stabellini wrote:
> > On Fri, 15 Mar 2024, Jan Beulich wrote:
> >> On 14.03.2024 23:59, Stefano Stabellini wrote:
> >>> On Mon, 11 Mar 2024, Simone Ballarin wrote:
> >>>> On 11/03/24 14:56, Jan Beulich wrote:
> >>>>> On 11.03.2024 13:00, Simone Ballarin wrote:
> >>>>>> On 11/03/24 11:08, Jan Beulich wrote:
> >>>>>>> On 11.03.2024 09:59, Simone Ballarin wrote:
> >>>>>>>> --- a/xen/arch/arm/include/asm/hypercall.h
> >>>>>>>> +++ b/xen/arch/arm/include/asm/hypercall.h
> >>>>>>>> @@ -1,3 +1,4 @@
> >>>>>>>> +/* SAF-5-safe direct inclusion guard before */
> >>>>>>>>    #ifndef __XEN_HYPERCALL_H__
> >>>>>>>>    #error "asm/hypercall.h should not be included directly - include
> >>>>>>>> xen/hypercall.h instead"
> >>>>>>>>    #endif
> >>>>>>>> --- a/xen/arch/x86/include/asm/hypercall.h
> >>>>>>>> +++ b/xen/arch/x86/include/asm/hypercall.h
> >>>>>>>> @@ -2,6 +2,7 @@
> >>>>>>>>     * asm-x86/hypercall.h
> >>>>>>>>     */
> >>>>>>>>    +/* SAF-5-safe direct inclusion guard before */
> >>>>>>>>    #ifndef __XEN_HYPERCALL_H__
> >>>>>>>>    #error "asm/hypercall.h should not be included directly - include
> >>>>>>>> xen/hypercall.h instead"
> >>>>>>>>    #endif
> >>>>>>>
> >>>>>>> Iirc it was said that this way checking for correct guards is suppressed
> >>>>>>> altogether in Eclair, which is not what we want. Can you clarify this,
> >>>>>>> please?
> >>>>>>>
> >>>>>>
> >>>>>> My first change was moving this check inside the guard.
> >>>>>> You commented my patch saying that this would be an error because someone
> >>>>>> can
> >>>>>> include it directly if it has already been included indirectly.
> >>>>>> I replied telling that this was the case also before the change.
> >>>>>> You agreed with me, and we decided that the correct thing would be fixing
> >>>>>> the
> >>>>>> check and not apply my temporary change to address the finding.
> >>>>>>
> >>>>>> Considering that the code should be amended, a SAF deviation seems to me
> >>>>>> the most appropriate way for suppressing these findings.
> >>>>>
> >>>>> Since I don't feel your reply addresses my question, asking differently:
> >>>>> With
> >>>>> your change in place, will failure to have proper guards (later) in these
> >>>>> headers still be reported by Eclair?
> >>>>
> >>>> No, if you put something between the check and the guard,
> >>>> no violation will be reported.
> >>>
> >>> From this email exchange I cannot under if Jan is OK with this patch or
> >>> not.
> >>
> >> Whether I'm okay(ish) with the patch here depends on our position towards
> >> the lost checking in Eclair mentioned above. To me it still looks relevant
> >> that checking for a guard occurs, even if that isn't first in a file for
> >> some specific reason.
> > 
> > More checking is better than less checking, but if we cannot find a
> > simple and actionable way forward on this violation, deviating it is
> > still a big improvement because it allows us to enable the ECLAIR Dir
> > 4.10 checks in xen.git overall (which again goes back to more checking
> > is better than less checking). 
> 
> You have a point here. I think though that at the very least the lost
> checking opportunity wants calling out quite explicitly.

All right, then maybe this patch can go in with a clarification in the
commit message?

Something like:

Note that with SAF-5-safe in place, failures to have proper guards later
in the header files will not be reported


> > Do you have a simple alternative suggestion? If not, this is still an
> > improvement.
> 
> I don't know the inner workings of Eclair. Without that I'm afraid I'm not
> in a position to make alternative suggestions.
 


From xen-devel-bounces@lists.xenproject.org Tue Mar 19 03:36:25 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 03:36:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695202.1084778 (Exim 4.92)
	(envelope-from )
	id 1rmQH1-0006B0-Db; Tue, 19 Mar 2024 03:36:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695202.1084778; Tue, 19 Mar 2024 03:36:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmQH1-0006At-9b; Tue, 19 Mar 2024 03:36:23 +0000
Received: by outflank-mailman (input) for mailman id 695202;
 Tue, 19 Mar 2024 03:36:21 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmQGz-0006Ah-9t; Tue, 19 Mar 2024 03:36:21 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmQGz-0000Ub-2j; Tue, 19 Mar 2024 03:36:21 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmQGy-0005v3-MK; Tue, 19 Mar 2024 03:36:20 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rmQGy-0006t3-Lr; Tue, 19 Mar 2024 03:36:20 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=MxlT59uwzykqtUTmIocIB2U2ie6uwj2z3zddBvUpqfo=; b=fhntEW6H6wJOS3If6HVBC2is6O
	pnNZ2BFD7hP4w8QrYYXJ87dPZNi9pR0VVTXXdvrv322eFkUx9KHGCU0bDo/AQOz02NHfm7GWKJPhR
	7exbcMwAwZ2HqLx2Nttrgs1pcOEWleuh4FYNq4Cf//NY7o0zsTZtxLd1KDymhIHq5Vdw=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-4.18-testing test] 185077: tolerable FAIL - PUSHED
X-Osstest-Failures:
    xen-4.18-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    xen-4.18-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    xen-4.18-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    xen-4.18-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-i386-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    xen=ea82c8cdbfe5a6e3bb6071cb71433502e3e565cf
X-Osstest-Versions-That:
    xen=4da8ca9cb9cfdb92c9dd09d5270ae16a3b2dbc89
From: osstest service owner 
Date: Tue, 19 Mar 2024 03:36:20 +0000

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen                  ea82c8cdbfe5a6e3bb6071cb71433502e3e565cf
baseline version:
 xen                  4da8ca9cb9cfdb92c9dd09d5270ae16a3b2dbc89

Last test of basis   185032  2024-03-14 10:46:48 Z    4 days
Testing same since   185077  2024-03-18 08:37:32 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich 

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-armhf-armhf-libvirt-qcow2                               pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-libvirt-raw                                  pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-arm64-arm64-xl-vhd                                      pass    
 test-armhf-armhf-xl-vhd                                      pass    
 test-amd64-i386-xl-vhd                                       pass    


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

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

Explanation of these 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
   4da8ca9cb9..ea82c8cdbf  ea82c8cdbfe5a6e3bb6071cb71433502e3e565cf -> stable-4.18


From xen-devel-bounces@lists.xenproject.org Tue Mar 19 03:37:20 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 03:37:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695207.1084787 (Exim 4.92)
	(envelope-from )
	id 1rmQHw-0006ht-My; Tue, 19 Mar 2024 03:37:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695207.1084787; Tue, 19 Mar 2024 03:37:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmQHw-0006hm-KK; Tue, 19 Mar 2024 03:37:20 +0000
Received: by outflank-mailman (input) for mailman id 695207;
 Tue, 19 Mar 2024 03:37:19 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmQHv-0006hc-9c
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 03:37:19 +0000
Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id fa9fe42e-e5a1-11ee-a1ee-f123f15fe8a2;
 Tue, 19 Mar 2024 04:37:17 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sin.source.kernel.org (Postfix) with ESMTP id 9442CCE0C06;
 Tue, 19 Mar 2024 03:37:14 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5FDADC433C7;
 Tue, 19 Mar 2024 03:37:12 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: fa9fe42e-e5a1-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1710819433;
	bh=Qp+ceH466MEmTf3psBBUjzqnLdC90VUOgisMKeZ0OEg=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=QlfEh+gzWweaf39N6dW+6DXLFnbbZgQlXn3ScCybA0UbSykhJym5z+wawbt3b+Awb
	 5CDuRI2fqIqYiiXwKUJYQiDbQiE+tK033DDIrCdY0KMei/hh/5tTTW3BLt/QKHGwM5
	 76WenIclII6SMqpeRHkbuajfxg00yS9IN7lRelwOE8rx6R/dK5HHy2aUYThZaT7mZS
	 BMc+qNRyGt7FVo0fJmUnTyfOUyFcCTRjXEvf2jlixU/muYmBhW3Mnrf6qNOLSitdeN
	 sPUDm3pdhYH0z/baY4JECXO/JhFJMUdOKEVw6iNnosBJJwr3n/Kum8ttpOMfm6U1sk
	 XaQ9L7lKUP9cw==
Date: Mon, 18 Mar 2024 21:37:10 -0600 (MDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich 
cc: Stefano Stabellini , andrew.cooper3@citrix.com, 
    bertrand.marquis@arm.com, george.dunlap@citrix.com, julien@xen.org, 
    michal.orzel@amd.com, roger.pau@citrix.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2] docs/misra: document the expected sizes of integer
 types
In-Reply-To: <7ab73379-b057-4568-9869-141cef185752@suse.com>
Message-ID: 
References:  <6a76723e-ba47-40b3-8f33-d68030b14299@suse.com>  <7ab73379-b057-4568-9869-141cef185752@suse.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Mon, 18 Mar 2024, Jan Beulich wrote:
> On 16.03.2024 01:07, Stefano Stabellini wrote:
> > On Fri, 15 Mar 2024, Jan Beulich wrote:
> >> On 14.03.2024 23:17, Stefano Stabellini wrote:
> >>> Xen makes assumptions about the size of integer types on the various
> >>> architectures. Document these assumptions.
> >>
> >> My prior reservation wrt exact vs minimum sizes remains.
> > 
> > We have to specify the exact size. In practice the size is predetermined
> > and exact with all our supported compilers given a architecture.
> 
> But that's not the purpose of this document; if it was down to what
> compilers offer, we could refer to compiler documentation (and iirc we
> already do for various aspects). The purpose of this document, aiui,
> is to document assumption we make in hypervisor code. And those should
> be >=, not ==.

Well... I guess the two of us are making different assumptions then :-)

Which is the reason why documenting assumptions is so important. More at
the bottom.


> > Most importantly, unfortunately we use non-fixed-size integer types in
> > C hypercall entry points and public ABIs. In my opinion, that is not
> > acceptable.
> 
> The problem is that I can't see the reason for you thinking so. The C
> entry points sit past assembly code doing (required to do) necessary
> adjustments, if any. If there was no assembly layer, whether to use
> fixed with types for such parameters would depend on what the
> architecture guarantees.

This could be the source of the disagreement. I see the little assembly
code as not important, I consider it just like a little trampoline to
me. As we describe the hypercalls in C header files, I consider the C
functions the "official" hypercall entry points.

Also, as this is an ABI, I consider mandatory to use clear width
definitions of all the types (whether with this document or with
fixed-width types, and fixed-width types are clearer and better) in both
the C header files that describe the ABI interfaces, as well as the C
entry points that corresponds to it. E.g. I think we have to use
the same types in both do_sched_op and the hypercall description in
xen/include/public/sched.h


> As to public ABIs - that's structure definitions, and I agree we ought
> to uniformly use fixed-width types there. We largely do; a few things
> still require fixing.

+1


> > We have two options:
> > 
> > 1) we go with this document, and we clarify that even if we specify
> >   "unsigned int", we actually mean a 32-bit integer
> > 
> > 2) we change all our public ABIs and C hypercall entry points to use
> >    fixed-size types (e.g. s/unsigned int/uint32_t/g)
> > 
> > 2) is preferred because it is clearer but it is more work. So I went
> > with 1). I also thought you would like 1) more.
> 
> For ABIs (i.e. structures) we ought to be making that change anyway.
> Leaving basic types in there is latently buggy.

I am glad we agree :-)

It is just that I also consinder the C hypercall entry points as part of
the ABI


> I'm happy to see a document like this added, for the purpose described
> above. But to me 1) and 2) and largely independent of one another.

Good that you are also happy with a document like this.

The remaining question is: what about the rest of the C functions in Xen
that are certainly not part of an ABI?

Those are less critical, still this document should apply uniformily to
them too. I don't understand why you are making the >= width assumption
you mentioned at the top of the file when actually it is impossible to
exercise or test this assumption on any compiler or any architecture
that works with Xen. If it cannot be enabled, it hasn't been tested, and
it probably won't work.



From xen-devel-bounces@lists.xenproject.org Tue Mar 19 03:39:32 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 03:39:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695209.1084797 (Exim 4.92)
	(envelope-from )
	id 1rmQK0-0007v4-1w; Tue, 19 Mar 2024 03:39:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695209.1084797; Tue, 19 Mar 2024 03:39:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmQJz-0007ux-Vh; Tue, 19 Mar 2024 03:39:27 +0000
Received: by outflank-mailman (input) for mailman id 695209;
 Tue, 19 Mar 2024 03:39:26 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmQJy-0007tZ-Ca
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 03:39:26 +0000
Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 462dd0d3-e5a2-11ee-a1ee-f123f15fe8a2;
 Tue, 19 Mar 2024 04:39:23 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sin.source.kernel.org (Postfix) with ESMTP id E1C5ECE0AAF;
 Tue, 19 Mar 2024 03:39:20 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7B6A0C433C7;
 Tue, 19 Mar 2024 03:39:18 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 462dd0d3-e5a2-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1710819560;
	bh=ipxwmoYe3sUV/2+U7vcS9yuguFs4t7xBD6cS3jUqb/0=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=hGTFaWOJGcxb/eEFT1cKauscJr67gg+c5TFm3NmKgf4xP0WLUfqpaaaxiPyf365xV
	 PvZiiAyjLdYR8+OJefBn1Buw25Ah2ZWhkE+yYFHcYgfdns//Qzy6woXV38vnoq33nY
	 cm9LAae3GEvfn2UF/pGhuFURMTqQ/ZMsV0cAj7mb0rgsFEtUQgAQx4ZGDd/WWhlcjc
	 0lOwSXrONSsWMI6+eeaQz7xfVtqIxtvqm8OURPFDvnZDN/EnmPOKy0jZvhGu5QJLnx
	 pUHzJJrjIuTM/+t5G+GK8ELwtpRcOI9oVtvExULJkxGHzvuMS9b0OHsIzTCjWtYkEJ
	 vPFMO1g6wuMMw==
Date: Mon, 18 Mar 2024 21:39:16 -0600 (MDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich 
cc: George Dunlap , Julien Grall , 
    Stefano Stabellini , federico.serafini@bugseng.com, 
    Andrew Cooper , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Bertrand Marquis , 
    xen-devel@lists.xenproject.org, michal.orzel@amd.com
Subject: Re: [PATCH] do_multicall and MISRA Rule 8.3
In-Reply-To: <5128255f-fe52-4425-b168-34946c0c901e@suse.com>
Message-ID: 
References:  <5a8f90d6-6502-4d93-9fd7-45fea0ede24a@suse.com>  
    
 <63891474-1dc4-4c86-aaf4-cc4d4c53a0ae@suse.com>   <3f27abc3-9809-4637-a29c-8aeafcd29ade@xen.org> <7109ef7e-040c-4d11-ba4b-d898ed2530ff@suse.com>
  <5128255f-fe52-4425-b168-34946c0c901e@suse.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Mon, 18 Mar 2024, Jan Beulich wrote:
> The named reasons simply aren't convincing to me, at all. There's no
> loss towards the "end goals" when "unsigned int" is used instead of
> "uint32_t". Plus I recall Andrew putting under question use of
> "unsigned int" for various hypercall parameter declarations, indicating
> his belief that "unsigned long" ought to be used. That's, to me, quite
> the opposite of using fixed-width types here, as there's no uniformly
> correct fixed-width type to use in that case.
> 
> So to me, besides there not having been technical arguments towards
> the need to use fixed width types here, there's actually added
> confusion about what's actually wanted. Imo if we started using fixed-
> width types for hypercall handler parameter declarations, (almost?) all
> non-handle ones would likely want to be converted. Consistency, after
> all, is part of the "easy to maintain code" goal. Plus without
> consistency how would one determine when to use what kind of types.

[...]

> The main use of fixed width types, to me, is in interface structure
> definitions - between Xen and hardware / firmware, or in hypercall
> structures. I'm afraid I have a hard time seeing good uses outside of
> that. Even in inline assembly, types of variables used for inputs or
> outputs don't strictly need to be fixed-width; I can somewhat accept
> their use there for documentation purposes.


Non-ABI interfaces are OK with native types.

Our ABI interfaces are, for better or for worse, described using C
header files. Looking at these header files, it should be clear the size
and alignment of all integer parameters.

To that end, I think we should use fixed-width types in all ABIs,
including hypercall entry points. In my opinion, C hypercall entry
points are part of the ABI and should match the integer types used in
the public header files. I don't consider the little assembly code on
hypercall entry as important. I think we should avoid having one
description of the hypercall types in sched.h and different types used
in do_sched_op.

Sometimes, we might have parameters that vary in size depending on the
architecture. For instance, a parameter could be 32-bit for 32-bit
architectures and 64-bit for 64-bit architectures.

For these cases, using "unsigned long", together with a document like
the one I submitted recently to xen-devel, is a good way forward: it
is semantically correct on all architectures, and it still comes with a
precise size and alignment as described in the document. In this
context, "unsigned long" means "register size" (on ARM we have
register_t). This is the one case where it makes sense not to use a
fixed-width type. Alternatively we would have to use #ifdefs.


From xen-devel-bounces@lists.xenproject.org Tue Mar 19 07:10:40 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 07:10:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695227.1084814 (Exim 4.92)
	(envelope-from )
	id 1rmTcA-0004Hy-LL; Tue, 19 Mar 2024 07:10:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695227.1084814; Tue, 19 Mar 2024 07:10:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmTcA-0004Hr-Hs; Tue, 19 Mar 2024 07:10:26 +0000
Received: by outflank-mailman (input) for mailman id 695227;
 Tue, 19 Mar 2024 07:10:25 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmTc9-0004Hl-8E
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 07:10:25 +0000
Received: from smtp-out2.suse.de (smtp-out2.suse.de
 [2a07:de40:b251:101:10:150:64:2])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c0fa819d-e5bf-11ee-afdd-a90da7624cb6;
 Tue, 19 Mar 2024 08:10:23 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org
 [IPv6:2a07:de40:b281:104:10:150:64:97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out2.suse.de (Postfix) with ESMTPS id DC69B5D25C;
 Tue, 19 Mar 2024 07:10:22 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id B21B8136A5;
 Tue, 19 Mar 2024 07:10:22 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id Gsr2KV46+WVJYwAAD6G6ig
 (envelope-from ); Tue, 19 Mar 2024 07:10:22 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c0fa819d-e5bf-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1710832223; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding;
	bh=60bEIDwx+NXczuoY7AFrsSbeXmm714yJjf0EPnqnQ6o=;
	b=TZfk+EKd+rpUzJAX7/cgQaDnSlrl68A0hnx/FbOIrgbzVPuemZlRN07Up0duvO+pTt0O6j
	K0yWbLG/fJKaJuBQY8mmiLU4cSYusYP1y74CIKCkFWru0KJXiTgZmeJhUN1E4oNA63utdD
	j1SJ0FmvH+XZXkP1xN/LXeCuiwzbA/U=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1710832222; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding;
	bh=60bEIDwx+NXczuoY7AFrsSbeXmm714yJjf0EPnqnQ6o=;
	b=kZtefftjM/Ld8PYQi5P+W736PuwztLTtFlY5/tF8FF/lwZUu/WRQ7NOzClDHOKOP1mecFC
	EsvdgpEzpgofq4DqqAkvoS0lHkVG5nuJv+TMbxwRlu2nZSS9eX7qt0dxVlQP2C7HCb3KXz
	LFZefv0pH38RoMN2DQ0hdy8kVzN51VE=
From: Juergen Gross 
To: torvalds@linux-foundation.org
Cc: linux-kernel@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	sstabellini@kernel.org
Subject: [GIT PULL] xen: branch for v6.9-rc1
Date: Tue, 19 Mar 2024 08:10:22 +0100
Message-Id: <20240319071022.7513-1-jgross@suse.com>
X-Mailer: git-send-email 2.35.3
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -5.01
X-Rspamd-Server: rspamd1.dmz-prg2.suse.org
X-Spam-Flag: NO
X-Spamd-Result: default: False [-5.01 / 50.00];
	 ARC_NA(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 R_DKIM_ALLOW(-0.20)[suse.com:s=susede1];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:106:10:150:64:167:received];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_DN_NONE(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 DWL_DNSWL_HI(-3.50)[suse.com:dkim];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_SIGNED(0.00)[suse.com:s=susede1];
	 DKIM_TRACE(0.00)[suse.com:+];
	 MX_GOOD(-0.01)[];
	 MID_CONTAINS_FROM(1.00)[];
	 DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:dkim];
	 FUZZY_BLOCKED(0.00)[rspamd.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 NEURAL_HAM_SHORT(-0.20)[-1.000];
	 RCVD_TLS_ALL(0.00)[];
	 BAYES_HAM(-1.00)[87.14%]
X-Spam-Level: 
Authentication-Results: smtp-out2.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b=kZtefftj
X-Rspamd-Queue-Id: DC69B5D25C

Linus,

Please git pull the following tag:

 git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-6.9-rc1-tag

xen: branch for v6.9-rc1

It contains the following patches:

- 2 patches for Xen event channel handling fixing a regression wit a
  rare kernel config and adding some hardening.

- A patch for better support of running Xen dom0 in PVH mode.

- A cleanup patch for the xen grant-dma-iommu driver.


Thanks.

Juergen

 arch/x86/include/asm/xen/hypervisor.h |  5 +++
 arch/x86/platform/pvh/enlighten.c     |  3 ++
 arch/x86/xen/enlighten.c              | 32 +++++++++++++++++
 arch/x86/xen/enlighten_pvh.c          | 68 +++++++++++++++++++++++++++++++++++
 arch/x86/xen/setup.c                  | 44 -----------------------
 arch/x86/xen/xen-ops.h                | 14 ++++++++
 drivers/xen/balloon.c                 |  2 --
 drivers/xen/events/events_base.c      | 22 +++++++-----
 drivers/xen/evtchn.c                  |  6 ++++
 drivers/xen/grant-dma-iommu.c         |  6 ++--
 10 files changed, 143 insertions(+), 59 deletions(-)

Juergen Gross (2):
      xen/evtchn: avoid WARN() when unbinding an event channel
      xen/events: increment refcnt only if event channel is refcounted

Roger Pau Monne (1):
      x86/xen: attempt to inflate the memory balloon on PVH

Uwe Kleine-König (1):
      xen/grant-dma-iommu: Convert to platform remove callback returning void


From xen-devel-bounces@lists.xenproject.org Tue Mar 19 07:34:11 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 07:34:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695233.1084827 (Exim 4.92)
	(envelope-from )
	id 1rmTz2-0007RW-H9; Tue, 19 Mar 2024 07:34:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695233.1084827; Tue, 19 Mar 2024 07:34:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmTz2-0007RP-DM; Tue, 19 Mar 2024 07:34:04 +0000
Received: by outflank-mailman (input) for mailman id 695233;
 Tue, 19 Mar 2024 07:34:03 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmTz1-0007RJ-3s
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 07:34:03 +0000
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com
 [2a00:1450:4864:20::536])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0e078f35-e5c3-11ee-afdd-a90da7624cb6;
 Tue, 19 Mar 2024 08:34:01 +0100 (CET)
Received: by mail-ed1-x536.google.com with SMTP id
 4fb4d7f45d1cf-563c403719cso6301751a12.2
 for ; Tue, 19 Mar 2024 00:34:01 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 i22-20020a17090671d600b00a46d58fbc11sm831770ejk.118.2024.03.19.00.34.00
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 19 Mar 2024 00:34:00 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0e078f35-e5c3-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710833641; x=1711438441; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=4Tbt14xyTFu8XXmumWNE8T7XrCfHAF7cozhh++uEE08=;
        b=T7ljbkHBHv49fpIqBBLLmYjuF+/oGfnCv+krscDk45i0PxbCzAzqw0dxuBBku3hCUO
         IYrufgbzR/WdhDrFO/rDJDozJzWNN8tX+N5bVLyhvCW9xsHQB6KN2FQulZnWyElxIFr+
         r2oKDnYbVV5LaqTN3s30P5sJmjqQ5TRLaQrn4xZVCI39apX+x3XJzH8cElgtDDSiiqjV
         IjgIWF9+2VY2EOa8abrb9fVWOxamnTgKE8aCtTO61rwLUkahqdannt65Vugd0gJUOQ34
         /TccxqmQFv/a8rIQ1wYMeAMF7NtnOjZnQ2SThl4mynBI6XryhBBdZ4m3XCll97z1gkSS
         pmWw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710833641; x=1711438441;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=4Tbt14xyTFu8XXmumWNE8T7XrCfHAF7cozhh++uEE08=;
        b=f9cerGhu9ViU6VV/RNgQITli2UfenK+Z7XdQeD3NgtZ8pGWmP7t+Wlk+z/j378mqmo
         13x0P8zwpNiFLUukbqaakX5/m+ioRZO25d+wV0mOpClhYgON0j4FeBm3cwN6u+Og/p3s
         smV741YTCx4FpgXNEOQd26Lw+xuJ4EFEv1OuCTclINXSX/SIhsUUsx175OBDqY3BHmC4
         RRkjXC4ea9lHqB+Ve3QZLdGWdOq/9rqCt2hK8I5WMJkLL0JUQQn29S3Vc8ukOXuIocSt
         KlQxHCDKGd0CFWmdoVG+BhSL6npUweWjTjdsdgYP8q8knc45ugGnBxwMHS/t5L9z1uW9
         XYBA==
X-Forwarded-Encrypted: i=1; AJvYcCX/UrWZ9b6tevwH3FB42G9U5aRgCRe7lDrIz6nnPAoFjOhx8WigYF4f4XFias43uGO5WjapErISW/bdJ7B7XeUtgrY0PJkwjZbM876fm7c=
X-Gm-Message-State: AOJu0YxXSSXIYMCWqO5Zz3kSyxFtr6xlOlgc3LGq8h/sVGdqV0LahdCi
	eWwyQYW+ZEdVP2nqLPuqDWxjL3ukNRipGEL+jcJM34oSD0Nttu6XxUWZ0NS1Qw==
X-Google-Smtp-Source: AGHT+IEIB1jx8MpUGbf+HVqTTpPb684QE4RTLck/YO6HieV6LnatfTf3PAXARAb8GEExZvrCjrtS2w==
X-Received: by 2002:a17:907:1707:b0:a46:7dc1:e4d1 with SMTP id le7-20020a170907170700b00a467dc1e4d1mr9581857ejc.73.1710833640804;
        Tue, 19 Mar 2024 00:34:00 -0700 (PDT)
Message-ID: 
Date: Tue, 19 Mar 2024 08:33:59 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/features: More AMD features
Content-Language: en-US
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Xen-devel 
References: <20240318181332.3817631-1-andrew.cooper3@citrix.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240318181332.3817631-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 18.03.2024 19:13, Andrew Cooper wrote:
> I'm not sure about FSRSC as a name, but it definitely beats AMD's longhand
> name of FAST_REP_SCASB.

With FSRS already used, I guess that's the closest we can get to keep
names for similar features similar.

> --- a/tools/misc/xen-cpuid.c
> +++ b/tools/misc/xen-cpuid.c
> @@ -91,6 +91,7 @@ static const char *const str_e1c[32] =
>      [24] = "perfctr-nb", /* [25] */
>      [26] = "dbx",        [27] = "perftsc",
>      [28] = "pcx-l2i",    [29] = "monitorx",
> +    [30] = "dbext2",
>  };

AMD calls this AddrMaskExt (PM) or AdMskExtn (PPR). I can see where your
different name choice is coming from, yet I still wonder whether we should
try to stay closer where possible.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Mar 19 07:45:10 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 07:45:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695238.1084836 (Exim 4.92)
	(envelope-from )
	id 1rmU9h-0000qX-FU; Tue, 19 Mar 2024 07:45:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695238.1084836; Tue, 19 Mar 2024 07:45:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmU9h-0000qQ-CE; Tue, 19 Mar 2024 07:45:05 +0000
Received: by outflank-mailman (input) for mailman id 695238;
 Tue, 19 Mar 2024 07:45:04 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmU9g-0000qK-24
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 07:45:04 +0000
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com
 [2a00:1450:4864:20::533])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9815c160-e5c4-11ee-afdd-a90da7624cb6;
 Tue, 19 Mar 2024 08:45:02 +0100 (CET)
Received: by mail-ed1-x533.google.com with SMTP id
 4fb4d7f45d1cf-56a0c0a7ebcso2258785a12.1
 for ; Tue, 19 Mar 2024 00:45:02 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ds11-20020a0564021ccb00b005689baaae61sm5445816edb.26.2024.03.19.00.45.01
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 19 Mar 2024 00:45:01 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9815c160-e5c4-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710834302; x=1711439102; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=OzP8GK1yyfxFlMfW8+ge1XFxBG/6uSp2j697TrAMWwE=;
        b=f4muVJCodDcg35D+VJeKdiGXZplYxinieUnkVlhq0kalxCx4sQESCeAJ4LLyB1hZHZ
         C6htBI4Els+pqs07ZGddoE86HTiHJVziAabeYGYawMvLPYkMQwm7TInhk56Mb/qWZXxx
         iP0mx3Kf8LM9AgrTMNmT1Xmv+/+50Jk8jfSmD/8Q07pqgbT1iyqDZ3Dj8UaJ0vRArSa3
         IuTPboHTH2WD++0/X6ZoJtXO9ICX5DOlpzM76m0/arRVrFtwkdxMc1QYWFiGI8MUwsoU
         7P7/vnGi7mukAsdNA6fekDanh55hgxNJ4zbxQgouErjgVgRrDVhZq9CeOMq82MGqSN4K
         p6LA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710834302; x=1711439102;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=OzP8GK1yyfxFlMfW8+ge1XFxBG/6uSp2j697TrAMWwE=;
        b=j7MvUCVc5BNQmBVzN5P0JlcGQBWlIt4hKaxOXKhq7t9bWxfStnSHyMEn6K5Mov3G5V
         pw/KUqNpInCFfR3zJm0ljbOULR72RjxG6+NDSr61F/AxyIrtqNvHfsyomtl3Go0Y5uq2
         7zOkks5xgJV3eDdhkRkc+hwhJ4vh0O2Lu5ntjDeuwv7UmnMDzh6KXYzLgvCKTEeCJxWQ
         SanBWwe4s3CrR/D18V+d9zgUOQ+YfZpBOgHLgiRF0pz+HUTm18RVM/sAWjJixtHc2dQ7
         aPjAWcc9Y5feKpRzEYrZgq5cZuUX92uuC5mhLuGkT+Ek87nNv/TR089zIQCHiP9NTPDS
         tBCg==
X-Forwarded-Encrypted: i=1; AJvYcCUU3f9s3ITSSqDfMvSEGr1lGoqTo0FuboDxV1Z9aDpbVvf17ejzPvMoyzjw9svQOsooAYMvIYeQ1C3JNnTuhPdLcRjtgQRN27qMKgQOi7E=
X-Gm-Message-State: AOJu0YyzGtpunQkHt/wu0yzijZpqwJWmFSTj+RD3IKKvZdi4m7Yw3uyC
	11BQaC1K7CQh55u50uEw8aJDRp+0zwHbZvCjDrQCXzPh1B/h6uHKYi88XPwl3A==
X-Google-Smtp-Source: AGHT+IGYweTOL94tLcs8pI/TkiuB2JUt9O8ZEb6N1glqcW2tJFPi9bKOk/rILxkmbnGIqT2k42skpw==
X-Received: by 2002:a05:6402:400e:b0:56b:9f3d:8f32 with SMTP id d14-20020a056402400e00b0056b9f3d8f32mr11931eda.12.1710834301847;
        Tue, 19 Mar 2024 00:45:01 -0700 (PDT)
Message-ID: 
Date: Tue, 19 Mar 2024 08:45:00 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH v3 03/16] misra: add deviations for direct inclusion
 guards
Content-Language: en-US
To: Stefano Stabellini 
Cc: consulting@bugseng.com, Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Wei Liu , Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org, Simone Ballarin 
References: 
 <1fdfec12fd2207c294f50d01d8ec32f890b915d7.1710145041.git.simone.ballarin@bugseng.com>
 
 <6472eb42-157a-4d6e-b5bb-daa74fbbd97b@bugseng.com>
 
 <3e4bb597-3624-418e-93d0-b95042fd27a7@bugseng.com>
 
 <077c0373-6eec-4403-b31e-574c8e8ae067@suse.com>
 
 <0513e505-5444-4a9f-9a77-ec9f359ddf27@suse.com>
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 19.03.2024 04:34, Stefano Stabellini wrote:
> On Mon, 18 Mar 2024, Jan Beulich wrote:
>> On 16.03.2024 01:43, Stefano Stabellini wrote:
>>> On Fri, 15 Mar 2024, Jan Beulich wrote:
>>>> On 14.03.2024 23:59, Stefano Stabellini wrote:
>>>>> On Mon, 11 Mar 2024, Simone Ballarin wrote:
>>>>>> On 11/03/24 14:56, Jan Beulich wrote:
>>>>>>> On 11.03.2024 13:00, Simone Ballarin wrote:
>>>>>>>> On 11/03/24 11:08, Jan Beulich wrote:
>>>>>>>>> On 11.03.2024 09:59, Simone Ballarin wrote:
>>>>>>>>>> --- a/xen/arch/arm/include/asm/hypercall.h
>>>>>>>>>> +++ b/xen/arch/arm/include/asm/hypercall.h
>>>>>>>>>> @@ -1,3 +1,4 @@
>>>>>>>>>> +/* SAF-5-safe direct inclusion guard before */
>>>>>>>>>>    #ifndef __XEN_HYPERCALL_H__
>>>>>>>>>>    #error "asm/hypercall.h should not be included directly - include
>>>>>>>>>> xen/hypercall.h instead"
>>>>>>>>>>    #endif
>>>>>>>>>> --- a/xen/arch/x86/include/asm/hypercall.h
>>>>>>>>>> +++ b/xen/arch/x86/include/asm/hypercall.h
>>>>>>>>>> @@ -2,6 +2,7 @@
>>>>>>>>>>     * asm-x86/hypercall.h
>>>>>>>>>>     */
>>>>>>>>>>    +/* SAF-5-safe direct inclusion guard before */
>>>>>>>>>>    #ifndef __XEN_HYPERCALL_H__
>>>>>>>>>>    #error "asm/hypercall.h should not be included directly - include
>>>>>>>>>> xen/hypercall.h instead"
>>>>>>>>>>    #endif
>>>>>>>>>
>>>>>>>>> Iirc it was said that this way checking for correct guards is suppressed
>>>>>>>>> altogether in Eclair, which is not what we want. Can you clarify this,
>>>>>>>>> please?
>>>>>>>>>
>>>>>>>>
>>>>>>>> My first change was moving this check inside the guard.
>>>>>>>> You commented my patch saying that this would be an error because someone
>>>>>>>> can
>>>>>>>> include it directly if it has already been included indirectly.
>>>>>>>> I replied telling that this was the case also before the change.
>>>>>>>> You agreed with me, and we decided that the correct thing would be fixing
>>>>>>>> the
>>>>>>>> check and not apply my temporary change to address the finding.
>>>>>>>>
>>>>>>>> Considering that the code should be amended, a SAF deviation seems to me
>>>>>>>> the most appropriate way for suppressing these findings.
>>>>>>>
>>>>>>> Since I don't feel your reply addresses my question, asking differently:
>>>>>>> With
>>>>>>> your change in place, will failure to have proper guards (later) in these
>>>>>>> headers still be reported by Eclair?
>>>>>>
>>>>>> No, if you put something between the check and the guard,
>>>>>> no violation will be reported.
>>>>>
>>>>> From this email exchange I cannot under if Jan is OK with this patch or
>>>>> not.
>>>>
>>>> Whether I'm okay(ish) with the patch here depends on our position towards
>>>> the lost checking in Eclair mentioned above. To me it still looks relevant
>>>> that checking for a guard occurs, even if that isn't first in a file for
>>>> some specific reason.
>>>
>>> More checking is better than less checking, but if we cannot find a
>>> simple and actionable way forward on this violation, deviating it is
>>> still a big improvement because it allows us to enable the ECLAIR Dir
>>> 4.10 checks in xen.git overall (which again goes back to more checking
>>> is better than less checking). 
>>
>> You have a point here. I think though that at the very least the lost
>> checking opportunity wants calling out quite explicitly.
> 
> All right, then maybe this patch can go in with a clarification in the
> commit message?
> 
> Something like:
> 
> Note that with SAF-5-safe in place, failures to have proper guards later
> in the header files will not be reported

That would be okay with me.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Mar 19 08:07:06 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 08:07:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695247.1084847 (Exim 4.92)
	(envelope-from )
	id 1rmUUt-0004kq-JW; Tue, 19 Mar 2024 08:06:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695247.1084847; Tue, 19 Mar 2024 08:06:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmUUt-0004kj-Fu; Tue, 19 Mar 2024 08:06:59 +0000
Received: by outflank-mailman (input) for mailman id 695247;
 Tue, 19 Mar 2024 08:06:58 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmUUr-0004kd-VH
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 08:06:57 +0000
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com
 [2a00:1450:4864:20::62e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a6e1c50f-e5c7-11ee-a1ee-f123f15fe8a2;
 Tue, 19 Mar 2024 09:06:55 +0100 (CET)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-a46dd7b4bcbso43727566b.3
 for ; Tue, 19 Mar 2024 01:06:55 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 di17-20020a170906731100b00a45aa7cb029sm5756003ejc.36.2024.03.19.01.06.54
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 19 Mar 2024 01:06:54 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a6e1c50f-e5c7-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710835615; x=1711440415; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=vNRWCo+o1B68GBRRcxYDYCJpuCK2Mo5BzztG9yF8XPU=;
        b=gl0n2OkZ//FVAdr5AfoHGGlekVQ2a0288jhJuRg/X5rt3K51R6dSrg0DLWlLWLbnj9
         0kkrKRj23ygIZOET4GJQ6a5U/3sIwppN8+oZl/FmR4025btuVtZqDBrU5Pagb9UOpglu
         qH2OlFWLPaipxwPgdq4uO2x2mqWD6VygVHMAH3n3X83iYA8sbVuFCCtewKZzbuGljp74
         bpAxovhIGWOU2IzEpLG7ul3C/2nPIigUjTQiano+jkSm3trxW+yUILdMI1doZJqMaPva
         ++69PpzFxoFkarbcicBEaISx7DylaiHZngy+1W1utLwXvoZFxYn1bNVa1VADudgQraDA
         KxPg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710835615; x=1711440415;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=vNRWCo+o1B68GBRRcxYDYCJpuCK2Mo5BzztG9yF8XPU=;
        b=swGMMX48PyJGfMiYjcxqcF3+eDHsaCDbNIJ/980UUYecNuR8e16Fl8yDwP9BivQY8a
         /6nCrHfMwYQV+pHZAPTtgQeOvxakU7zJDMeoKr8bKhMWLdDINH8FqF34aQ3wkIJQ6IzM
         VcXU/rkpdiYFIzueEzdaKiaT9/ReKQeKUpXbNHGMw9upjrSVmmhAhDW9cpN3+A1JKcAh
         IuULr5ned6N85PR6OLBRnhNG46WpO8OmYrD7PRQoexKUi6CN3NnWXwGrArZxFzFIad9D
         ywQaWLa0HsVARRMKBsX0aN3gZpqhj/AoSr2f40gB1TLnmwt9CNAFczS5KfrQfQy2GgBo
         STuw==
X-Forwarded-Encrypted: i=1; AJvYcCVeXVFgnKh/ZDIeLDCd11k4kzI1dQV8RXPKxj20XEj2W6YuKqSW6EmIhTANbHrlkGlXVi75TlJDDp9FEH3gOBoPUzf5UWExmUvY0bsxzkA=
X-Gm-Message-State: AOJu0YxUa8A9Q1zU9lXa1SB/zneTGK8nVMqHLC3krAq4kr927gJ9Bnux
	TAWHj7QIRF62hCBbAL3wrK6sSsoDQLUMbr+RKHW6QisDKEH9VP1f7RZjOJXoYg==
X-Google-Smtp-Source: AGHT+IHlY36jXRq5Ip1pxI3H7UpbW+X/Bt2GUgs04mLKuhGAluLrGQadGYxTet0RtcqdbwHxzVOT4w==
X-Received: by 2002:a17:907:174c:b0:a46:47d5:2851 with SMTP id lf12-20020a170907174c00b00a4647d52851mr8752702ejc.29.1710835615159;
        Tue, 19 Mar 2024 01:06:55 -0700 (PDT)
Message-ID: 
Date: Tue, 19 Mar 2024 09:06:54 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] docs/misra: document the expected sizes of integer
 types
Content-Language: en-US
To: Stefano Stabellini 
Cc: andrew.cooper3@citrix.com, bertrand.marquis@arm.com,
 george.dunlap@citrix.com, julien@xen.org, michal.orzel@amd.com,
 roger.pau@citrix.com, xen-devel@lists.xenproject.org
References: 
 <6a76723e-ba47-40b3-8f33-d68030b14299@suse.com>
 
 <7ab73379-b057-4568-9869-141cef185752@suse.com>
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 19.03.2024 04:37, Stefano Stabellini wrote:
> On Mon, 18 Mar 2024, Jan Beulich wrote:
>> On 16.03.2024 01:07, Stefano Stabellini wrote:
>>> On Fri, 15 Mar 2024, Jan Beulich wrote:
>>>> On 14.03.2024 23:17, Stefano Stabellini wrote:
>>>>> Xen makes assumptions about the size of integer types on the various
>>>>> architectures. Document these assumptions.
>>>>
>>>> My prior reservation wrt exact vs minimum sizes remains.
>>>
>>> We have to specify the exact size. In practice the size is predetermined
>>> and exact with all our supported compilers given a architecture.
>>
>> But that's not the purpose of this document; if it was down to what
>> compilers offer, we could refer to compiler documentation (and iirc we
>> already do for various aspects). The purpose of this document, aiui,
>> is to document assumption we make in hypervisor code. And those should
>> be >=, not ==.
> 
> Well... I guess the two of us are making different assumptions then :-)
> 
> Which is the reason why documenting assumptions is so important. More at
> the bottom.
> 
> 
>>> Most importantly, unfortunately we use non-fixed-size integer types in
>>> C hypercall entry points and public ABIs. In my opinion, that is not
>>> acceptable.
>>
>> The problem is that I can't see the reason for you thinking so. The C
>> entry points sit past assembly code doing (required to do) necessary
>> adjustments, if any. If there was no assembly layer, whether to use
>> fixed with types for such parameters would depend on what the
>> architecture guarantees.
> 
> This could be the source of the disagreement. I see the little assembly
> code as not important, I consider it just like a little trampoline to
> me. As we describe the hypercalls in C header files, I consider the C
> functions the "official" hypercall entry points.

Why would that be? Any code we execute in Xen is relevant.

> Also, as this is an ABI, I consider mandatory to use clear width
> definitions of all the types (whether with this document or with
> fixed-width types, and fixed-width types are clearer and better) in both
> the C header files that describe the ABI interfaces, as well as the C
> entry points that corresponds to it. E.g. I think we have to use
> the same types in both do_sched_op and the hypercall description in
> xen/include/public/sched.h

There are two entirely separate aspects to the ABI: One is what we
document towards consumers of it. The other is entirely internal, i.e.
an implementation detail - how we actually consume the data.
Documenting fixed-width types towards consumers is probably okay,
albeit (see below) imo still not strictly necessary (for being
needlessly limiting).

>> As to public ABIs - that's structure definitions, and I agree we ought
>> to uniformly use fixed-width types there. We largely do; a few things
>> still require fixing.
> 
> +1
> 
> 
>>> We have two options:
>>>
>>> 1) we go with this document, and we clarify that even if we specify
>>>   "unsigned int", we actually mean a 32-bit integer
>>>
>>> 2) we change all our public ABIs and C hypercall entry points to use
>>>    fixed-size types (e.g. s/unsigned int/uint32_t/g)
>>>
>>> 2) is preferred because it is clearer but it is more work. So I went
>>> with 1). I also thought you would like 1) more.
>>
>> For ABIs (i.e. structures) we ought to be making that change anyway.
>> Leaving basic types in there is latently buggy.
> 
> I am glad we agree :-)
> 
> It is just that I also consinder the C hypercall entry points as part of
> the ABI
> 
> 
>> I'm happy to see a document like this added, for the purpose described
>> above. But to me 1) and 2) and largely independent of one another.
> 
> Good that you are also happy with a document like this.
> 
> The remaining question is: what about the rest of the C functions in Xen
> that are certainly not part of an ABI?

As per above - anything internal isn't part of the ABI, C entry points
for hypercall handlers included. All we need to ensure is that we consume
the data according to what the ABI sets forth.

To use wording from George when he criticized my supposed lack of actual
arguments: While there's nothing technically wrong with using fixed
width types there (or in fact everywhere), there's also nothing technically
wrong with using plain C types there and almost everywhere else (ABI
structures excluded). With both technically equal, ./CODING_STYLE has the
only criteria to pick between the two. IOW that's what I view wrong in
George's argumentation: Demanding that I provide technical arguments when
the desire to use fixed width types for the purpose under discussion also
isn't backed by any.

> Those are less critical, still this document should apply uniformily to
> them too. I don't understand why you are making the >= width assumption
> you mentioned at the top of the file when actually it is impossible to
> exercise or test this assumption on any compiler or any architecture
> that works with Xen. If it cannot be enabled, it hasn't been tested, and
> it probably won't work.

Hmm, yes, that's one way to look at it. My perspective is different though:
By writing down assumptions that are more strict than necessary, we'd be
excluding ports to environments meeting the >= assumption, but not meeting
the == one. Unless of course you can point me at any place where - not
just by mistake / by being overly lax - we truly depend on the == that you
want to put in place. IOW yes, there likely would need to be adjustments
to code if such a port was to happen. Yet we shouldn't further harden
requirements that were never meant to be there.

Note that by writing down anything more strict than necessary, you'd also
encourage people to further wrongly treat e.g. uint32_t and unsigned int
as identical. Such wrong assumptions had been a severe hindrance in doing
ports from 32- to 64-bit processors some 20 years ago. I would have hoped
that we'd learn from such mistakes.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Mar 19 08:11:25 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 08:11:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695253.1084857 (Exim 4.92)
	(envelope-from )
	id 1rmUZ4-0006fV-6j; Tue, 19 Mar 2024 08:11:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695253.1084857; Tue, 19 Mar 2024 08:11:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmUZ4-0006fO-3u; Tue, 19 Mar 2024 08:11:18 +0000
Received: by outflank-mailman (input) for mailman id 695253;
 Tue, 19 Mar 2024 08:11:17 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmUZ3-0006fH-Ca
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 08:11:17 +0000
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com
 [2a00:1450:4864:20::52b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 423da8f4-e5c8-11ee-afdd-a90da7624cb6;
 Tue, 19 Mar 2024 09:11:16 +0100 (CET)
Received: by mail-ed1-x52b.google.com with SMTP id
 4fb4d7f45d1cf-56b9e5ed074so134771a12.3
 for ; Tue, 19 Mar 2024 01:11:16 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 de24-20020a056402309800b00568c604eea2sm3078781edb.55.2024.03.19.01.11.15
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 19 Mar 2024 01:11:15 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 423da8f4-e5c8-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710835876; x=1711440676; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=bsx6Lhr9MnXsGSnWlPS2nh2fG7nOaR0L7dRJ8WpTJKA=;
        b=blViKgS+TfD7AMf1O774sLVlxg2Mdpdl5pPoqjLzaWL2bK+pfOmdSTT6A2zdvXRpjX
         XYi6V5pCdTSnpp1fBiHyEH/kZt+TpU/4WY6+BD9rmUPqBjHjy2YOv9xqZtuBphzKz0kE
         2Car3KfP53qmAx/ujx5p1E/hPgBVLr+LpZgP5wt7NA7TcxYAjao5RpRsB5sRoB7Xj5Db
         EwUHX/dzT3+W1UeACGvwWq/oJBgGYhEj546sRWFIWo3Xpg7BeXoNwN3HiYN4DSOHDDhM
         wT/qvj9ozRWybnesgE3GMdElwl1yrc9bffghpgAlqa1oYjaT4hnkWCjvyUm1r+7fNDFt
         jPjw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710835876; x=1711440676;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=bsx6Lhr9MnXsGSnWlPS2nh2fG7nOaR0L7dRJ8WpTJKA=;
        b=DnQegxn6kswnljmUxHq9UG7p92Wh7zIQM8VTKKCrH0r1uVClRbxM+5e8oEnbsAIIbJ
         X1Pio0wfWRitUSvAWxWBDDV34bdgA9GrcX934o3CPG8zyHXWDc0In4XhkM5n0Umb4BF9
         FZycU+2jSs+w5TE7nSB2FooJkqoIhJ0VTJZEvy86AJHzytu+qTnDkXZ13m4kLstosv7C
         UrF4U+fZcTWZfQM66Le7+se9Z1p2/nxQZg2QB5g4Uz9rM7cQwaoegoi2FvFkoA0Qlyt0
         YdK9C5t9PvJjINWE6IpPOc9WHWeMB/2R+kI09J1kkAcbcTQf8P7d/2Ay9ouWh80WSel/
         XxNA==
X-Forwarded-Encrypted: i=1; AJvYcCX0NAP4nuErpHMLbKZthr/19dlFXAXwNUS7IpTG5i+lgbqz7YQ+2v56VCMQh6gPTcTmjtpNn8KovKjtffZtKoy/dp+TBOsLLzb0u+5SipM=
X-Gm-Message-State: AOJu0Yy+dbLoXbDjgyGTWPuoB4Tzc71zDpvIkWxtz5n8/IVs9X0wuPnt
	Z9punCIcHrM/1eIvwkLiW6NUSy7tBk2unGG4A8UvB7z0XZ33brmG9LFC/dvZ9Q==
X-Google-Smtp-Source: AGHT+IHR3kevxuKmzOiPRHaIrbEeSYk0WNDHhENbfpo1lUZCpeWs1AG6HMVYaBlY3SSysazVJ0Q8XQ==
X-Received: by 2002:a05:6402:3884:b0:568:9a2f:84b with SMTP id fd4-20020a056402388400b005689a2f084bmr1194647edb.10.1710835875798;
        Tue, 19 Mar 2024 01:11:15 -0700 (PDT)
Message-ID: 
Date: Tue, 19 Mar 2024 09:11:14 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 3/3] x86/PVH: Support relocatable dom0 kernels
Content-Language: en-US
To: Jason Andryuk 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu
 , George Dunlap ,
 Julien Grall , Stefano Stabellini ,
 xen-devel@lists.xenproject.org
References: <20240313193021.241764-1-jason.andryuk@amd.com>
 <20240313193021.241764-4-jason.andryuk@amd.com>
 <945609d6-741e-4934-a4f2-6e5597ce5dcd@suse.com>
 
 <43c49aa6-d690-467e-8ce3-ca37b9d41e76@suse.com>
 <769e4e95-1c76-4e07-b623-27b35ef388ef@amd.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <769e4e95-1c76-4e07-b623-27b35ef388ef@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 18.03.2024 22:19, Jason Andryuk wrote:
> On 2024-03-14 10:19, Jan Beulich wrote:
>> On 14.03.2024 15:13, Jason Andryuk wrote:
>>> On 2024-03-14 09:21, Jan Beulich wrote:
>>>> On 13.03.2024 20:30, Jason Andryuk wrote:
>>>>> --- a/xen/include/public/elfnote.h
>>>>> +++ b/xen/include/public/elfnote.h
>>>>> @@ -194,6 +194,17 @@
>>>>>     */
>>>>>    #define XEN_ELFNOTE_PHYS32_ENTRY 18
>>>>>    
>>>>> +/*
>>>>> + * Physical loading constraints for PVH kernels
>>>>> + *
>>>>> + * Used to place constraints on the guest physical loading addresses and
>>>>> + * alignment for a PVH kernel.  This note's value is 3 64bit values in
>>>>> + * the following order: minimum, maximum and alignment.
>>>>
>>>> Along the lines of what I said on another sub-thread, I think at least
>>>> alignment wants to be optional here. Perhaps, with max going first, min
>>>> could also be optional.
>>>
>>> Interesting idea.
>>>
>>>> As indicated in different context by Roger, the values being uniformly
>>>> 64-bit ones also is questionable.
>>>>
>>>>> + * The presence of this note indicates the kernel is relocatable.
>>>>
>>>> I think it wants making explicit here that the act of relocating is still
>>>> left to the kernel.
>>>
>>> Ok.
>>>
>>> How is this for a new description?
>>>
>>> """
>>> Physical loading constraints for PVH kernels
>>>
>>> Used to place constraints on the guest physical loading addresses and
>>> alignment for a PVH kernel.
>>>
>>> The presence of this note indicates the kernel supports relocating itself.
>>>
>>> The note may include up to three 32bit values.
>>
>> I'm as unsure about always 32-bit as I am on it being uniformly 64-bit.
>> One question here is whether this note is intended to be x86-specific.
>>
>>>    - a maximum address for the entire image to be loaded below (default
>>> 0xfffffff)
>>
>> One f too few?
> 
> Whoops - yes.
> 
>>>    - a minimum address for the start of the image (default 0)
>>>    - a required start alignment (default 1)
> 
> Jan, in the discussion of patch 1, you wrote "Hmm, shouldn't the order 
> of attempts to figure the alignment be ELF note, ELF header, and then 
> 2Mb?"  My latest revision initializes phys_alignment to 1 and updates 
> that if PHYS32_RELOC specifies an alignment.  Do you still want these 
> other locations checked for alignment values?

I think it would be prudent to do so, yet at the same time I guess I won't
insist. Defaulting to 1, though, looks overly lax. In order for the
alignment value to be sensible to omit, the default needs to be sensible
(no lower than 4k, and quite likely better 2M).

Jan


From xen-devel-bounces@lists.xenproject.org Tue Mar 19 08:15:53 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 08:15:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695256.1084866 (Exim 4.92)
	(envelope-from )
	id 1rmUdP-0007GM-NB; Tue, 19 Mar 2024 08:15:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695256.1084866; Tue, 19 Mar 2024 08:15:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmUdP-0007GF-KN; Tue, 19 Mar 2024 08:15:47 +0000
Received: by outflank-mailman (input) for mailman id 695256;
 Tue, 19 Mar 2024 08:15:47 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmUdP-0007G9-3C
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 08:15:47 +0000
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com
 [2a00:1450:4864:20::62f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e2da9c8d-e5c8-11ee-afdd-a90da7624cb6;
 Tue, 19 Mar 2024 09:15:45 +0100 (CET)
Received: by mail-ej1-x62f.google.com with SMTP id
 a640c23a62f3a-a46d9fbb5a5so64215566b.2
 for ; Tue, 19 Mar 2024 01:15:45 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 h25-20020a17090634d900b00a454438091fsm5760810ejb.70.2024.03.19.01.15.44
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 19 Mar 2024 01:15:45 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e2da9c8d-e5c8-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710836145; x=1711440945; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=uQye6Y4P+NXTkYUYsIvH1XldHouhJPvX6q245Jd1G4g=;
        b=URpeDlK5+E83eLnkqB/R969mVeqU8Fhh4IPZ3LxLq3X3blEXjMQAJou14gs2n67O0e
         HlZ5CaAyQfofw7HeXOQPHuVZfONGCTxHyc+0QddIM12LouMdxwbs997KLLppL9R6HYE+
         VsJfboYyjNtP5dH48YI3zL1GAjY1SpCNz9e0wmBK/0cgpOwjjA54qaRJnf/EsPb75Q9i
         A6FqCKGwOjm05GWd0POYNv6ciComw1BZU22RVubZKW7ddp+JG5eOk3xMpAKpobaA9IDj
         KAF8c1mOO1mPMGeRZxOheBezRZWHOqMwdB9OcSi34m/1pT4tIum/PVvJ14MeO6kDBZUo
         fJ9A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710836145; x=1711440945;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=uQye6Y4P+NXTkYUYsIvH1XldHouhJPvX6q245Jd1G4g=;
        b=sq9leNZMWLb+oc7h2PeKYZ5vE+yxyRXMYEM2m73x/cSnrdoY1CxnONmHY3gAQqmwax
         tMhVi5PCToNO6+HACc+knZoCqw/y9jZUB/sqjBsg7hCinSFyLOmFFDkDjbVntkOsmZMp
         llEGYo3KrMtPHNIh7GsnetEO6E4ORzcSPXKS2nRjbv0q/oCtWgYskfFDZ1fE1evFRjKm
         aDKRUrhYhSVj7sKIL5qCVwRP6rsp5oYkl0wadSrlCdf2Wu1Ejt6GRLa5tMS6j1VXBKlg
         Q18xVi+Y00c+4bzhlJKQO65N6OTAHlSVQoSz0C+aZuRwWNUZS8S4mXdsr7NVOMyWTu83
         ycTw==
X-Forwarded-Encrypted: i=1; AJvYcCVKKSwLdUK+/+F1SGAOpYq79Zte31qqHvWVuGreip8/VvCmz32kiZdm3gdopC82Nrqaoh/8Ogr8GNsABi9UBW44KKN0xuQtdA9lgU4UHQU=
X-Gm-Message-State: AOJu0Yy+zNuZuQMQYfAhvYTid/wbXX2DNxq3DeNt4fDKkTpjrYTaxtoz
	uoSohizUi4Gvt6R7wMG9dWd+nlngK3iRVuB4MOlFpok1q3kvKKvWbijx/1cWfg==
X-Google-Smtp-Source: AGHT+IFEmLPllDnQ+x8vIoJCX0JLXXFn0DfeNNfk6ktvbTiPvF82V77cXfd+c2+kgAMY1WEfY2iNSg==
X-Received: by 2002:a17:906:88d:b0:a46:b1b3:aba0 with SMTP id n13-20020a170906088d00b00a46b1b3aba0mr1036679eje.17.1710836145330;
        Tue, 19 Mar 2024 01:15:45 -0700 (PDT)
Message-ID: 
Date: Tue, 19 Mar 2024 09:15:44 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 3/3] x86/PVH: Support relocatable dom0 kernels
Content-Language: en-US
To: Jason Andryuk 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu
 , George Dunlap ,
 Julien Grall , Stefano Stabellini ,
 xen-devel@lists.xenproject.org
References: <20240313193021.241764-1-jason.andryuk@amd.com>
 <20240313193021.241764-4-jason.andryuk@amd.com>
 <12fe48a6-6957-49d7-adf5-1a3ac8b1bfaa@suse.com>
 <7506abe0-e3d4-44f7-b54d-592ae2e3fd3e@amd.com>
 <88bd8577-42e6-4087-9888-00cd73e7f0bc@suse.com>
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 18.03.2024 22:21, Jason Andryuk wrote:
> On 2024-03-15 05:48, Jan Beulich wrote:
>> On 14.03.2024 20:19, Jason Andryuk wrote:
>>> On 2024-03-14 09:31, Jan Beulich wrote:
>>>> On 13.03.2024 20:30, Jason Andryuk wrote:
>>>>> --- a/xen/arch/x86/hvm/dom0_build.c
>>>>> +++ b/xen/arch/x86/hvm/dom0_build.c
>>>>> @@ -537,6 +537,108 @@ static paddr_t __init find_memory(
>>>>>        return INVALID_PADDR;
>>>>>    }
>>>>>    
>>>>> +static bool __init check_load_address(
>>>>> +    const struct domain *d, const struct elf_binary *elf)
>>>>> +{
>>>>> +    paddr_t kernel_start = (paddr_t)elf->dest_base & PAGE_MASK;
>>>>> +    paddr_t kernel_end = PAGE_ALIGN((paddr_t)elf->dest_base + elf->dest_size);
>>>>
>>>> Both casts act on a pointer value. Such cannot legitimately be converted
>>>> to paddr_t; it only so happens that paddr_t is effectively the same as
>>>> uintptr_t right now. (Same issue again further down.) That said, I notice
>>>> we have pre-existing examples of this ...
>>>
>>> Yes, I followed existing code.  Do you want dest_base to be switched to
>>> a uintptr_t?
>>
>> I think it was deliberately switched to being a pointer at some point,
>> maybe even in a security fix.
> 
> commit 65808a8ed41cc7c044f588bd6cab5af0fdc0e029 "libelf: check all 
> pointer accesses", part of XSA-55, switched from a single dest pointer 
> to dest_base & dest_size.
> 
> For libxenguest, it's a pointer to guest-mapped memory to copy in the 
> kernel.  For PV dom0 creation, it's a pointer - Xen switches to the dom0 
> page tables and performs the copy with it as-is.  For PVH dom0, it's a 
> guest physical address.
> 
> Are you looking for this to be addressed in this series?

I'm sorry to ask, but what is "this" here? I'd like your change to leave
all types alone. I'd further like your change to preferably avoid cloning
questionable code (i.e. casts using the wrong type in particular). Plus,
where technically possible, adhere to the general principle of avoiding
casts (for typically being at least somewhat risky towards hiding
potential bugs).

Jan


From xen-devel-bounces@lists.xenproject.org Tue Mar 19 08:21:44 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 08:21:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695260.1084876 (Exim 4.92)
	(envelope-from )
	id 1rmUj4-0000sU-BU; Tue, 19 Mar 2024 08:21:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695260.1084876; Tue, 19 Mar 2024 08:21:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmUj4-0000sN-90; Tue, 19 Mar 2024 08:21:38 +0000
Received: by outflank-mailman (input) for mailman id 695260;
 Tue, 19 Mar 2024 08:21:36 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmUj2-0000sC-OP
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 08:21:36 +0000
Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com
 [2a00:1450:4864:20::132])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b3017166-e5c9-11ee-a1ee-f123f15fe8a2;
 Tue, 19 Mar 2024 09:21:35 +0100 (CET)
Received: by mail-lf1-x132.google.com with SMTP id
 2adb3069b0e04-513e6777af4so3536171e87.2
 for ; Tue, 19 Mar 2024 01:21:35 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 w17-20020a1709064a1100b00a466e772597sm5874386eju.177.2024.03.19.01.21.33
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 19 Mar 2024 01:21:34 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b3017166-e5c9-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710836494; x=1711441294; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=PUNrfdDIFs5xZBUKg7hTXblIk+RJr0DcGTEEHlMEjXE=;
        b=PcNBgh/XW/fUI+48Cb9vOwdhdmc8hx0onVIPFDustsWdW4pGFTsKsOB3xOLg596Ggf
         WwjxfBkBA1RxGaUEU0Ikq+WsPPNhxaxubbvyXgPdNHmCHgVpB2hpb9tSihM5Sn//cLpz
         7nGVuvlTSZpWNXji65CRs1FBaC3YTpHExsfydiB1h9zaeJJgV1mrVwFz3tpLzFXOipdx
         y87S0GE8MYYRnvz+F/UFCWt4+5F/QjDcyX0p2hsStgA49hkhUHQdOE74IiBWG925P4d/
         S6TVWtt71WYKZAwWS3r+5G0F1V3OjjAN4+UmWnyPHzv0EDJpoeuV6oDoRQ+GRlTx5VxS
         lrHQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710836494; x=1711441294;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=PUNrfdDIFs5xZBUKg7hTXblIk+RJr0DcGTEEHlMEjXE=;
        b=bz7Pk/90yIW+QaEbBS/rKFQ/1StZnBZmsRrEZQqWspnSHSmMlCf6/iepQhTBnAl/2C
         K4cy5T+x3XYxaRH0XVumacCywfzta2UhWYiJ8fbkBhemTtCRMqysHWebbbmJQtVcCy/d
         exKkuGiVAovsFy/ycMR680Vsz4FySRVY1JrO8iPm+Fhee4t9xpmzHeQxWPiHZj1rosSU
         fOeMvLMT5GZ/Orb7Z6lvoKf0gAv3oJuj9pRhyghGWz1bjMPqIblPnUzQx70q3nFrdi7v
         73ggUWSE40OZZ6NTQ8tuOvvG3u0w/lewVJElIuMvrsUwT+EtG4aBawlJyw0nqCKMH8Ng
         8Lwg==
X-Forwarded-Encrypted: i=1; AJvYcCVRvvuzJdODe3rLI4vXKcwKL8oFUoKWKzyqbXTmYWBIhku8TjKeBW5tWbTQdIqfg3mHDE3yhlNIbWpPI73gdCBjr8beszaxBbbvbvCBmNM=
X-Gm-Message-State: AOJu0Yz/3NVn1akHxwpywSLcenN9K3gGYBe1epWdnJyYHAyxzUI7rhH5
	vGm21l2VAR3MjD237I13R2Q/jLce19qYwM+yRHQC4dxfaaB9WT7XSeeAvEa9WFBewYZrTuvST28
	=
X-Google-Smtp-Source: AGHT+IFuvO+oPkVx4lkHnjBmwGwTd9ycuADoM3MKMOpIRRj/dfFCiwSBW60b5P8nl2kAmUZNY9cgDA==
X-Received: by 2002:a05:6512:3e1b:b0:513:e7a0:5aa5 with SMTP id i27-20020a0565123e1b00b00513e7a05aa5mr6594847lfv.51.1710836494412;
        Tue, 19 Mar 2024 01:21:34 -0700 (PDT)
Message-ID: <591646e8-56e8-4262-8061-cb320c359cd7@suse.com>
Date: Tue, 19 Mar 2024 09:21:33 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v13 10/14] vpci/header: emulate PCI_COMMAND register for
 guests
Content-Language: en-US
To: Stewart Hildebrand ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: Oleksandr Andrushchenko ,
 Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 Volodymyr Babchuk ,
 xen-devel@lists.xenproject.org
References: <20240202213321.1920347-1-stewart.hildebrand@amd.com>
 <20240202213321.1920347-11-stewart.hildebrand@amd.com>
 <180cac00-e7c4-4bea-bd13-c5983da707d7@suse.com>
 <242f4ec0-c634-4044-833e-7df3c720abc5@amd.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <242f4ec0-c634-4044-833e-7df3c720abc5@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 18.03.2024 22:03, Stewart Hildebrand wrote:
> On 2/14/24 10:41, Jan Beulich wrote:
>> On 02.02.2024 22:33, Stewart Hildebrand wrote:
>>> @@ -836,9 +870,20 @@ static int cf_check init_header(struct pci_dev *pdev)
>>>      if ( pdev->ignore_bars )
>>>          return 0;
>>>  
>>> -    /* Disable memory decoding before sizing. */
>>>      cmd = pci_conf_read16(pdev->sbdf, PCI_COMMAND);
>>> -    if ( cmd & PCI_COMMAND_MEMORY )
>>> +
>>> +    /*
>>> +     * Clear PCI_COMMAND_MEMORY and PCI_COMMAND_IO for DomUs, so they will
>>> +     * always start with memory decoding disabled and to ensure that we will not
>>> +     * call modify_bars() at the end of this function.
>>
>> To achieve this, fiddling with PCI_COMMAND_IO isn't necessary. Which isn't
>> to say its clearing should go away; quite the other way around: Why would
>> we leave e.g. PCI_COMMAND_MASTER enabled? In fact wasn't it in an earlier
>> version of the series that the guest view simply started out as zero? The
>> patch description still says so.
> 
> Yep, clearing PCI_COMMAND_MASTER too for domUs makes sense to me, I'll
> make this change in v14. I'll also try to improve the comment.
> 
> Roger suggested at [1] that we should reflect the state of the hardware
> in the command register. I'll update the patch description accordingly.

Roger's request can be carried out in several ways. But first of all state
reflected should be that of whatever is consistent in the virtualized view.
Any bits the guest may control ought to start out as zero, imo (which may
mean bringing hardware in sync with the guest view, not necessarily the
other way around). For bits the guest cannot control what the guest ought
to see depends.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Mar 19 08:51:12 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 08:51:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695267.1084893 (Exim 4.92)
	(envelope-from )
	id 1rmVBZ-00061R-Jt; Tue, 19 Mar 2024 08:51:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695267.1084893; Tue, 19 Mar 2024 08:51:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmVBZ-00061K-Fb; Tue, 19 Mar 2024 08:51:05 +0000
Received: by outflank-mailman (input) for mailman id 695267;
 Tue, 19 Mar 2024 08:51:04 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmVBY-00061E-3x
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 08:51:04 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on20600.outbound.protection.outlook.com
 [2a01:111:f403:2417::600])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id cdd2cea0-e5cd-11ee-a1ee-f123f15fe8a2;
 Tue, 19 Mar 2024 09:50:58 +0100 (CET)
Received: from SJ0PR03CA0183.namprd03.prod.outlook.com (2603:10b6:a03:2ef::8)
 by MN0PR12MB6366.namprd12.prod.outlook.com (2603:10b6:208:3c1::19)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.26; Tue, 19 Mar
 2024 08:50:55 +0000
Received: from MWH0EPF000989E8.namprd02.prod.outlook.com
 (2603:10b6:a03:2ef:cafe::a6) by SJ0PR03CA0183.outlook.office365.com
 (2603:10b6:a03:2ef::8) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7339.32 via Frontend
 Transport; Tue, 19 Mar 2024 08:50:54 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 MWH0EPF000989E8.mail.protection.outlook.com (10.167.241.135) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Tue, 19 Mar 2024 08:50:53 +0000
Received: from SATLEXMB08.amd.com (10.181.40.132) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Tue, 19 Mar
 2024 03:50:49 -0500
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB08.amd.com
 (10.181.40.132) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Tue, 19 Mar
 2024 01:50:49 -0700
Received: from XIR-MICHALO-L1.xilinx.com (10.180.168.240) by
 SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.35
 via Frontend Transport; Tue, 19 Mar 2024 03:50:47 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: cdd2cea0-e5cd-11ee-a1ee-f123f15fe8a2
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=DkDKMetPCb+IiWrMHQAzXdbIXIvP0u5RHWVjHVHdABOQn/hWSk/u384nZZES7rNd0Jv2ZhWC8wDWc/VJ+pVvvLh67f2fMCtB9jrXkcihKdksTw6iL4cJdmYG6zSp7ApSxrDYjFn9joebLj2FIRkEviXZFDy8jW8wkg2LHfx1Pbr7SJvFi1MiJRPhRi+zwJv6T43+2XiKMs5GCALAYJhokXLebaUXltqe3mFnRwYDvJFBEbxqh+zV372GaGGeFYsbg/aQRBW07p0qrpTzG8tKbmIwtW+K5CcBTM3ud5zopNRUnXcI8kyLzZsrPX6G3YwuTeoz6w0KueJvPj6I6rfpoA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=IdDJYdknS09+FYwajqYMbDGtPefBjlnA7m8a0jJp1AM=;
 b=MGPk7g1yX3SetnZ15KTDxMnEUr3Ib/yqdqF12GrdN3FIjv/LsOijUhhUaw6x1i/urVMav9N07wU7rxFZMc62s45ETphB4HSSBWDO4t15YlFseTl+lRXvIXkWiZRYpjrkddEWlAg/zRjqueUGtSpfQrgqTUW/xzowuA33PSse8GvACIV83b0pOIWafnv8fn53UtNE+bQ0lq3UlVlibKxXzAV8lZQn+GJcpIOxAS2nKMTBQBW+QAUxxA0BbW2f7gFkQyY8uMPftjImTcWXG+O1FWa5zOoBgxPcKMN3btLLBjoEsYeQu/fM8g07hoWiMnNda6qWEwZqMY0i+Zji+VoS5w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=IdDJYdknS09+FYwajqYMbDGtPefBjlnA7m8a0jJp1AM=;
 b=a/5y/Tzv933nrSz3J8EQ8YNmyLC53rXEG9CzDLy9JLnDgg7PBozVuv8nU611tYZIVIBFUNF+/VSA7NEaxOwv5nLY5+GHrvyv07u66cBdnVgkBioA0mtgFEGet7ValdBjjwLVifDqmjF6ZTwjQaaI1cPsy9nmFzfgcp3OoIdNO+o=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Michal Orzel 
To: 
CC: Michal Orzel , Andrew Cooper
	, George Dunlap , "Jan
 Beulich" , Julien Grall , "Stefano
 Stabellini" 
Subject: [PATCH] xen/nospec: Include 
Date: Tue, 19 Mar 2024 09:50:42 +0100
Message-ID: <20240319085042.28470-1-michal.orzel@amd.com>
X-Mailer: git-send-email 2.25.1
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: MWH0EPF000989E8:EE_|MN0PR12MB6366:EE_
X-MS-Office365-Filtering-Correlation-Id: 74134a8b-c3de-4ecf-7418-08dc47f1afbf
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	0nXG0hNw7Pwn0YRZdurIzE1JGZn2lZU4oDEb8Ci+WAHRABfTuwNqD//vTFs2Lc/ZUEcN0opQMX1Mlxwj3LvD7M0nvY5v/4LIahsy7o1JeUhc2ae7WOPqKW7ELMwdg+L6qvGKllMlMnzH1c3S9cfgZ4/8VQ1clJ4z39Ekcy6bwZ0SaBOwEQgWXvrCp6q+lSVz0WciYImB3CrNKDEpfucyRvhtBiCf933OwEKYWBh9iesR5inKUOnIsThFMuUUssY68zfEw/iNPcTUS90UFRHAIDU/zhjC7BB5E7dbyGZLASKB6lpN7/BShBamtFTSWPqpzPcqPVE5pcOZeZeQSKXwBZKcS/FSlokt90Lu+RIBrtqkJrd5MguUcHjtltK2i1WSY3IGfqqqcUXTb2tUSLzI4KGm1u8jRgtUoxObNF6Jbg8T09yndSQ+LmiD1W3ch78mea3UuyJn471wXutr11QvLUJtHeZad9JqsjOo9V9wbPf2MXYGjlw9cGJoS4U/h8G/Jf+YOAy3n9Ido+4L8a0FBQJ9/Wgiibdu8rq/fe9xckGM3I+lSfAjfv3WaDeXxjwjYDHRU/y8YR5ORZJ2VIH9TWSo73GICpIAgERWqppmrFAhO4y2cJonsdiGNSUS5MwHmhp2KYsPe/+r4QnL1Q02eSuo/uzYGB8jzA1LaAQzfU0P36GshVAyI5c++PAvkf++aFCY3f6D/YW+s+HLIA/myLS1e1dkVkSkjoQE7s9w0lcc9Dmi6PiJ1HSvg6/HpJad
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(82310400014)(1800799015)(36860700004)(376005);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Mar 2024 08:50:53.9455
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 74134a8b-c3de-4ecf-7418-08dc47f1afbf
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	MWH0EPF000989E8.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB6366

After introduction of lock_evaluate_nospec() using bool type, building
Xen on Arm with UBSAN enabled fails:

In file included from ./include/xen/spinlock.h:4,
                 from common/ubsan/ubsan.c:13:
./include/xen/nospec.h:79:22: error: unknown type name ‘bool’
   79 | static always_inline bool lock_evaluate_nospec(bool condition)

There is no issue on x86, as xen/stdbool.h is included somewhere along
the asm/nospec.h path, which is not the case for other architectures.

Fixes: 7ef0084418e1 ("x86/spinlock: introduce support for blocking speculation into critical regions")
Signed-off-by: Michal Orzel 
---
 xen/include/xen/nospec.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/xen/include/xen/nospec.h b/xen/include/xen/nospec.h
index e8d73f9538e5..9fb15aa26aa9 100644
--- a/xen/include/xen/nospec.h
+++ b/xen/include/xen/nospec.h
@@ -7,6 +7,8 @@
 #ifndef XEN_NOSPEC_H
 #define XEN_NOSPEC_H
 
+#include 
+
 #include 
 
 /**
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Tue Mar 19 09:40:40 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 09:40:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695278.1084902 (Exim 4.92)
	(envelope-from )
	id 1rmVxJ-0004zJ-4V; Tue, 19 Mar 2024 09:40:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695278.1084902; Tue, 19 Mar 2024 09:40:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmVxJ-0004zC-1X; Tue, 19 Mar 2024 09:40:25 +0000
Received: by outflank-mailman (input) for mailman id 695278;
 Tue, 19 Mar 2024 09:40:22 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmVxG-0004z1-T8
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 09:40:22 +0000
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com
 [2a00:1450:4864:20::632])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b3ba9d78-e5d4-11ee-afdd-a90da7624cb6;
 Tue, 19 Mar 2024 10:40:21 +0100 (CET)
Received: by mail-ej1-x632.google.com with SMTP id
 a640c23a62f3a-a46ce2bd562so204083666b.2
 for ; Tue, 19 Mar 2024 02:40:21 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 qk26-20020a170906d9da00b00a45bb14b1a5sm5830400ejb.89.2024.03.19.02.40.20
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 19 Mar 2024 02:40:20 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b3ba9d78-e5d4-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710841221; x=1711446021; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=QTPvaVegFJ2LuhO5jfpTtSRORxkQzXCjaDyWlMAScYY=;
        b=CIC6WdZqN29TuGy5ZolnrAu+QXjcK4uswh5VBqS9ff1pX7LwUgp2MMryJR+SlBBL9k
         E6NCUofaU1r/bGGumh+vuZWdetMHqFib9r4WU/i9Gc7YPgy4M3OXgUtCtNgyk5zp/4I8
         NwkUxQYcKI8E08W2+x/E/+/pAnr3NdxVWATxFfcIzBMRPtkyqRF6POsaryktbv+JoHPR
         /bFxLUB/n69EhQ6v9q7zbYH40vqgHUiHTBGcTpnGymLIfEpxzd4Yq8WXoQttPhhjfNwF
         Lx7C78NpWPJjFpqobXhwktolVpdZhvdFknS73DM7QeidPlAfk3zy9cIhxmlAfrgrUHPz
         JCmA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710841221; x=1711446021;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=QTPvaVegFJ2LuhO5jfpTtSRORxkQzXCjaDyWlMAScYY=;
        b=cooGxKOm5IuzUA4NejsJ5hwtR0Hv57rc2M7KS0ASlrtC2VNoI2/p6oJ8o2SumaWwBN
         djGTIltrU77vcEm1Lclwa/55uEHwxfsGLZqmP+8w7/JWBmu0K7dAPVR7kFlN32uE2rs6
         SP840McnGt9ylXFc5mI3g/y8d/PFD0PDRd9p25t+7V+zxB+Pmh2KPxJLgiHQA9seIU8p
         8gamJ4cMIq+RxQFGyQlq8BDtcUxbdm3V/+be6T4PQyqKC72OmjzlNRmBu3gcvQWi6bwK
         EBSfKjiUNNRCSM0aAP1hkp5EvbAWEsp0P4shr4aEl01DSaJrUyWUBwmVyZI3WJocaddn
         J7Sg==
X-Forwarded-Encrypted: i=1; AJvYcCXAtQ7CxGAM1VVFPWggURxVsqWIxdyDAhFtlgz3GgWCh7xcME2Fdh7abSAE+ACAltR5SdfOekd3JV+y8cVgi+Vv4EnCVzw1JXQvNnE5kLs=
X-Gm-Message-State: AOJu0Yzyd1g9VoKoy6C/vvSaAyTerAQK9cEJEDNvd7kNj+JMtOyjnmF8
	g0JQ5xpR1vzcc+u5kXlRnAyEBObWWvYJmoPO0LY2/s8xUNSReKRJNqGVQ3nm6Q==
X-Google-Smtp-Source: AGHT+IEWkNp6WE0KNHxxEcxbnlX3dWrP8+8ot59l0YyW17wIhN/6uYA95+BlRPJ/gMyHSV4qGySd+w==
X-Received: by 2002:a17:906:43c2:b0:a44:51c1:733c with SMTP id j2-20020a17090643c200b00a4451c1733cmr1430489ejn.39.1710841220912;
        Tue, 19 Mar 2024 02:40:20 -0700 (PDT)
Message-ID: 
Date: Tue, 19 Mar 2024 10:40:20 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/nospec: Include 
Content-Language: en-US
To: Michal Orzel 
Cc: Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20240319085042.28470-1-michal.orzel@amd.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240319085042.28470-1-michal.orzel@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 19.03.2024 09:50, Michal Orzel wrote:
> After introduction of lock_evaluate_nospec() using bool type, building
> Xen on Arm with UBSAN enabled fails:
> 
> In file included from ./include/xen/spinlock.h:4,
>                  from common/ubsan/ubsan.c:13:
> ./include/xen/nospec.h:79:22: error: unknown type name ‘bool’
>    79 | static always_inline bool lock_evaluate_nospec(bool condition)
> 
> There is no issue on x86, as xen/stdbool.h is included somewhere along
> the asm/nospec.h path, which is not the case for other architectures.
> 
> Fixes: 7ef0084418e1 ("x86/spinlock: introduce support for blocking speculation into critical regions")
> Signed-off-by: Michal Orzel 

Acked-by: Jan Beulich 




From xen-devel-bounces@lists.xenproject.org Tue Mar 19 10:07:28 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 10:07:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695283.1084913 (Exim 4.92)
	(envelope-from )
	id 1rmWNO-0008Kl-5m; Tue, 19 Mar 2024 10:07:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695283.1084913; Tue, 19 Mar 2024 10:07:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmWNO-0008Ke-32; Tue, 19 Mar 2024 10:07:22 +0000
Received: by outflank-mailman (input) for mailman id 695283;
 Tue, 19 Mar 2024 10:07:21 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmWNN-0008KW-90
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 10:07:21 +0000
Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com
 [2a00:1450:4864:20::336])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 78ac37aa-e5d8-11ee-afdd-a90da7624cb6;
 Tue, 19 Mar 2024 11:07:19 +0100 (CET)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-414645c349dso2528035e9.1
 for ; Tue, 19 Mar 2024 03:07:19 -0700 (PDT)
Received: from localhost ([85.31.135.62]) by smtp.gmail.com with ESMTPSA id
 r8-20020a05600c458800b0041409cabb39sm9594865wmo.18.2024.03.19.03.07.18
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 19 Mar 2024 03:07:18 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 78ac37aa-e5d8-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710842839; x=1711447639; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=22m8F5eHnsE6I2JCG0BhWJG1Y5otjS1Oa7T2DIPkqvQ=;
        b=aep+QgYuiYzfNl3pR1KfjiCaU8DNBl+OQXd89fsLIiXfa0z1nFOY6ejrBDFKTJhEaj
         kKw+8MU9vAC9CmOFnenVHBUcePER9DjXAonadFfprvofZievOaTkxUjCvYzr11XDHI04
         N8CWLg6oNQLVoF9JO+YDgOtKacH8UYksWVkPs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710842839; x=1711447639;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=22m8F5eHnsE6I2JCG0BhWJG1Y5otjS1Oa7T2DIPkqvQ=;
        b=naCiEA85LFGhaxB3jej943lP0p8L/OXoMyhMGyhzc5E3786XMPvs/qj5o9KbV/IyvK
         Tuvjig3flC2KR5VFgkW6JgAZZr1G9ep1uFMbsQizhOyjARLfX47qlj+iae0ZBdn0jhaH
         fOY6yn6sPlGHIbU5ANCQcsy/8o7QOuahGsMGS++K5r6Cph8/JKBkcNosmwvr5nkq8aK8
         YjnrmliUZmppmhEUmPtMPal2rBCqLjwZUOK99cC7KuJqIcafNJ+1/U91XLHNAw4QznSf
         jtCJhSNhW0cISVgjWtJbXhlI137P/XimGrRI/QxEkJd359JAJuLOxpWwMyxhfuKd53CI
         kubQ==
X-Forwarded-Encrypted: i=1; AJvYcCUwdZFiidprK9LOj70LVDsD/ahB8yXsI2DjwOGo66cRBv2CRKT/C9mg/cWTM3bEwwnQgjIR/vKbkLXVbo6qz+tZmD7zKqydVA4w9iGcX6Y=
X-Gm-Message-State: AOJu0Yz46WKZ1qfX0BpcqzktczhTdpafwB0y86UfEUCv0SS9j15ZwQKl
	G0lfBVCUOgmIMB/lbsKVz0VEri3PRsX+bNIj/88N7XsMvwMlU90Dz0LJYBGYQeU=
X-Google-Smtp-Source: AGHT+IECcFdhl0pRbNSvdU2cfGnY0CD+EqLRB7uBA/J+1I2E/bml/msXTE5CRyPb5CGdgRevL0VsUg==
X-Received: by 2002:a05:600c:5022:b0:414:e6e:756a with SMTP id n34-20020a05600c502200b004140e6e756amr2052727wmr.9.1710842839052;
        Tue, 19 Mar 2024 03:07:19 -0700 (PDT)
Date: Tue, 19 Mar 2024 11:07:18 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Ross Lagerwall 
Cc: grub-devel@gnu.org, xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Daniel Kiper 
Subject: Re: [PATCH 2/7] multiboot2: Allow 64-bit entry tags
Message-ID: 
References: <20240313150748.791236-1-ross.lagerwall@citrix.com>
 <20240313150748.791236-3-ross.lagerwall@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20240313150748.791236-3-ross.lagerwall@citrix.com>

On Wed, Mar 13, 2024 at 03:07:43PM +0000, Ross Lagerwall wrote:
> Binaries may be built with entry points above 4G. While bootloaders may
> relocate them below 4G, it should be possible for the binary to specify
> those entry points. Therefore, extend the multiboot2 protocol such that
> 64 bit addresses are allowed for entry points. The extension is done in
> a backwards-compatible way.
> 
> Signed-off-by: Ross Lagerwall 
> ---
>  doc/multiboot.texi | 32 +++++++++++++++++++-------------
>  doc/multiboot2.h   |  6 +++++-
>  2 files changed, 24 insertions(+), 14 deletions(-)
> 
> diff --git a/doc/multiboot.texi b/doc/multiboot.texi
> index d12719c744eb..049afab53c1f 100644
> --- a/doc/multiboot.texi
> +++ b/doc/multiboot.texi
> @@ -522,12 +522,12 @@ header.
>  
>  @example
>  @group
> -        +-------------------+
> -u16     | type = 3          |
> -u16     | flags             |
> -u32     | size              |
> -u32     | entry_addr        |
> -        +-------------------+
> +          +-------------------+
> +u16       | type = 3          |
> +u16       | flags             |
> +u32       | size              |
> +u32 / u64 | entry_addr        |
> +          +-------------------+

I might be confused, but this entry point is used in 32bit protected
mode, and hence a 64bit value is simply impossible to use according to
the protocol in "3.3 I386 machine state".

Unless that section is expanded to describe other protocols that use
the entry address in a way where 64bits could be meaningful it seems
pointless to expand the field.

>  @end group
>  @end example
>  
> @@ -538,7 +538,10 @@ The meaning of each is as follows:
>  
>  @item entry_addr
>  The physical address to which the boot loader should jump in order to
> -start running the operating system.
> +start running the operating system. @samp{entry_addr} may be specified
> +either as a @samp{u32} or @samp{u64}. The bootloader should use the
> +header size to determine the size of @samp{entry_addr}.
> +
>  @end table
>  
>  @subsection EFI i386 entry address tag of Multiboot2 header
> @@ -573,12 +576,12 @@ tag of Multiboot2 header are ignored.
>  
>  @example
>  @group
> -        +-------------------+
> -u16     | type = 9          |
> -u16     | flags             |
> -u32     | size              |
> -u32     | entry_addr        |
> -        +-------------------+
> +          +-------------------+
> +u16       | type = 9          |
> +u16       | flags             |
> +u32       | size              |
> +u32 / u64 | entry_addr        |
> +          +-------------------+

This does seem sensible.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Mar 19 10:58:03 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 10:58:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695303.1084974 (Exim 4.92)
	(envelope-from )
	id 1rmXAD-0007e8-7m; Tue, 19 Mar 2024 10:57:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695303.1084974; Tue, 19 Mar 2024 10:57:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmXAD-0007e1-55; Tue, 19 Mar 2024 10:57:49 +0000
Received: by outflank-mailman (input) for mailman id 695303;
 Tue, 19 Mar 2024 10:57:47 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmXAB-0007ds-Cf
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 10:57:47 +0000
Received: from NAM04-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam04on20601.outbound.protection.outlook.com
 [2a01:111:f403:2409::601])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 833ec2af-e5df-11ee-a1ee-f123f15fe8a2;
 Tue, 19 Mar 2024 11:57:45 +0100 (CET)
Received: from CH2PR10CA0001.namprd10.prod.outlook.com (2603:10b6:610:4c::11)
 by PH8PR12MB6889.namprd12.prod.outlook.com (2603:10b6:510:1c9::21)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.30; Tue, 19 Mar
 2024 10:57:39 +0000
Received: from CH2PEPF00000149.namprd02.prod.outlook.com
 (2603:10b6:610:4c:cafe::3d) by CH2PR10CA0001.outlook.office365.com
 (2603:10b6:610:4c::11) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.28 via Frontend
 Transport; Tue, 19 Mar 2024 10:57:38 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CH2PEPF00000149.mail.protection.outlook.com (10.167.244.106) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Tue, 19 Mar 2024 10:57:38 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Tue, 19 Mar
 2024 05:57:38 -0500
Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Tue, 19 Mar 2024 05:57:36 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 833ec2af-e5df-11ee-a1ee-f123f15fe8a2
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=aiEUBhMuXQsQ5H/zVngpgD6cPLACSRlpL4Lxq/JxprihtupXnycWVdnU94bdurpNCLBoUbX1zUK4eKYW1CrZjTeRJ3qq4VyilVT5c1raofLKnYUINYCquRtVXxXCEGMruW/RbOJEf/UqSGBjBLV38lmNLrzpMTW2oL1pTfPrzXkEQ9xKvCrKUnX04Yndg+Ebcc52j5hJR4FUKcOWzWldjqlBxc3YzWPMD3pc51NWeb+flei1AeUE61Z280aBlYYsaT6Cj04zzxDgy6K5SSbYH3lQNjEwVRR87/J7is6u705XUjo2Lq38Jir9dJB5D4H5MaSANCR3eq+rW9/9zWYXTw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=xv7+b4BDoffw7pFU2AlG+AUJAjNM6iLHSd6PgPsx4XU=;
 b=GxENmxeoiz4OZnI6E1uNuAXmttvM5/kh8hLcw9Pac8pitQLQSUG1ZISKtOatVIu610kuyETkXravcncoErl/RRB3Fp6Nxse0GMCWGJly8zCSEm+QIIeTfTVXsW3d4T04wiyW65u84Qdy3omiVLnkv9aLQo1JVxQWNcW1WEt3ZU/Ml3oyQNX0Suc7oS9BQd0F36mr41r2QXX+xpll7ysewPCvnkPG23tolTG5vQJu03YHtQfD/bDz3WFqYytWak5ZK7Gb8qKFUd796b6gqxggfwW7WWXpR7FBCt0NCryGjQfnyjkOp4oIuib33l7AWmm4FyhwMfYf2sJHF6reCZo3lw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=arm.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=xv7+b4BDoffw7pFU2AlG+AUJAjNM6iLHSd6PgPsx4XU=;
 b=tQpGvggTwPGMALEUH9SwqO9z0EaovnGggJQV3gfikMBQynRwGLeaRLPKXLUA1381mL0WwnCv0slzLdWo3mGwsjtibSrumVcGl8EtlRGIJl3z7E7532k3aOg2H0JDFKQCJS/jwoHeQp09jrQ6VYmERlAtL6EtiiwGbU5WjnQ0EDY=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Message-ID: <7238287a-0f5c-4045-bfb6-a58ec1873471@amd.com>
Date: Tue, 19 Mar 2024 11:57:36 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 02/11] xen/arm: avoid repetitive checking in
 process_shm_node
To: Luca Fancellu , 
CC: Penny Zheng , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Volodymyr Babchuk 
References: <20240312130331.78418-1-luca.fancellu@arm.com>
 <20240312130331.78418-3-luca.fancellu@arm.com>
Content-Language: en-US
From: Michal Orzel 
In-Reply-To: <20240312130331.78418-3-luca.fancellu@arm.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB04.amd.com: michal.orzel@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH2PEPF00000149:EE_|PH8PR12MB6889:EE_
X-MS-Office365-Filtering-Correlation-Id: c22d167c-f7fe-465d-9799-08dc48036451
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	y7pF3rSjPozbZB/Yc2q9+O81SNSWqxh84Oi6yaR9TZe6YT80Gvb164PC/21LNG2GTWrJx7dv+j/0cxueU2utcpTcrO8b45gDihFJ9Jt+XfPBZWWwYw1AApkFTbi6D4SfUPRR8ovtjUlvrGgZIRReLTuO8R8pQE9ap4CJ2IiAlcZpzm6/S/OrMRL//HaYFgOniVsVXn8MOsskAaC0CD4pgh5tiZYAPqVFHcwA2ZtDrI71LFBWPJeSWINiNUfCoX2npsDpGJ1+Tary36j3600vihUzYUHyxeO5wQjo+nQEnfuQRjkn/oUFLwcrw8POWtQ9lFULu5R5A6W7eawXvQ59xRd54Az16grfIWKF6Ni0UoKVydMSE2A9U8Ft2aH7BqmlTU/tHbHyVquYCgIOPFnyB/Hsy0J0lTxC0uBf/ZChkdOF74aqUSntp4o14XQvZOSx5PINVhiLCcYIaNlCeQ7lQgfkJEgE5sfFIzCvX//o5zOfEjthNyBCBe4AU+1rpQP6aM47mrSb2OmSC9H4Pe6eiYtuY8DpOjq7/HGg1ItD8/ebl2g43HgC++eZtbYkZltnmiIEGmTb5mqTtln0jpEuDcYNa2aQxG1Xz0KKBLvekAQk2sc0JgkIKDJpTuGnSu5fovLFZDjvc8i/SQTR4K+o6VRK7Bu/p+3PyQOoO1rXo1tujHa0pUoDwYQILhUhyZkq10bdXuI2pYrN9XqKZ5yjHQ==
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(82310400014)(36860700004)(1800799015)(376005);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Mar 2024 10:57:38.4313
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c22d167c-f7fe-465d-9799-08dc48036451
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH2PEPF00000149.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR12MB6889

Hi Luca,

On 12/03/2024 14:03, Luca Fancellu wrote:
> 
> 
> From: Penny Zheng 
> 
> Putting overlap and overflow checking in the loop is causing repetitive
> operation, so this commit extracts both checking outside the loop.
> 
> Signed-off-by: Penny Zheng 
> Signed-off-by: Luca Fancellu 
> ---
> v1:
>  - Rework of https://patchwork.kernel.org/project/xen-devel/patch/20231206090623.1932275-3-Penny.Zheng@arm.com/
>  - use strncmp to match the branch above
I don't understand why we need strncmp if we already validated that shm_id is NULL terminated within MAX_SHM_ID_LENGTH
at the beginning of the function with strnlen.

Other than that:
Reviewed-by: Michal Orzel 

~Michal


From xen-devel-bounces@lists.xenproject.org Tue Mar 19 11:30:34 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 11:30:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695330.1084987 (Exim 4.92)
	(envelope-from )
	id 1rmXfn-000540-Mz; Tue, 19 Mar 2024 11:30:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695330.1084987; Tue, 19 Mar 2024 11:30:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmXfn-00053t-K8; Tue, 19 Mar 2024 11:30:27 +0000
Received: by outflank-mailman (input) for mailman id 695330;
 Tue, 19 Mar 2024 11:30:26 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmXfm-00053n-KF
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 11:30:26 +0000
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com
 [2a00:1450:4864:20::531])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 137f0bab-e5e4-11ee-a1ee-f123f15fe8a2;
 Tue, 19 Mar 2024 12:30:23 +0100 (CET)
Received: by mail-ed1-x531.google.com with SMTP id
 4fb4d7f45d1cf-568a53d2ce0so6496996a12.0
 for ; Tue, 19 Mar 2024 04:30:23 -0700 (PDT)
Received: from andrewcoop.citrite.net (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 n6-20020a509346000000b0056b924663ecsm863967eda.59.2024.03.19.04.30.21
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 19 Mar 2024 04:30:22 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 137f0bab-e5e4-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710847822; x=1711452622; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:from:to:cc:subject:date:message-id:reply-to;
        bh=NDEnUgv4i8PUN86IfXiq7G6DNci7ZGUA6BUwFHP5UwI=;
        b=gdBhxiM4jPGBg6YgJQCKqRAzMCjNz2MsQVeIBm9+bDnqFmS8zete8QrFxHEt+tbpN5
         3CCBIItiYXXs0tRNmy2Z9/9TX2lPw6DavZmF5R/EZotCVLYxI8/gSHtM1KausICzzyR9
         WdRrnj8DX+GB6g7TLmZ1KLlQtcMIGZgo/NATg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710847822; x=1711452622;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=NDEnUgv4i8PUN86IfXiq7G6DNci7ZGUA6BUwFHP5UwI=;
        b=CQwRxwzD07k65BST4GTJ8LvaUb+Kh/WZ02PyquD0+R4Bzyh0SX40QRClcSdobnSIGP
         F5fpGzBDaE85iO5oTtdA0YtAU+aI4WwnNvYWnwRvU3e614+7u/ZjxF/2GrtRRtSWXHj6
         ryNUt5RUq8cTnDENIWKSzUVNzQQo3qiOiOwxcWomXB8/FZx6wP4o7hMy8mYjhk0qs+z6
         idzhGsH1KFqqeZmg0cj8NnJLrzA74Lj0YKPoVFKNz2i3XAHB5h7b+vHLxfNxgAB0urp6
         vd9YXIMhYHjSZZzjeGesPZBzpOE3MbkS38RD/1Yx6r3eguH/Kj4lFn+PbS9CfS4Q/AOA
         25UQ==
X-Gm-Message-State: AOJu0Yx2uBBCduNJDKPF6ogq7qjGZTcy4iddNemy7F2OCN/3mrKYKPzV
	jw17cm2OCVSieNiN6H0jrR6JGYy8Q5RPbAojJpJIt0sYHUJtw0ZsJJOQr445w8bixVO+DEjTlkb
	q
X-Google-Smtp-Source: AGHT+IFOLEG7tXMTSlla+4BWCx2CFF3aIwAB4cQ95y05YV40BijCXcLCePcbQRBfdCfy9rqghEoOAw==
X-Received: by 2002:a05:6402:2b87:b0:568:9ba8:8f1a with SMTP id fj7-20020a0564022b8700b005689ba88f1amr11555422edb.7.1710847822529;
        Tue, 19 Mar 2024 04:30:22 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Juergen Gross ,
	George Dunlap ,
	Jan Beulich ,
	Stefano Stabellini ,
	Julien Grall 
Subject: [PATCH] xen/rwlock: Don't perpeuatite broken API in new logic
Date: Tue, 19 Mar 2024 11:30:20 +0000
Message-Id: <20240319113020.3843309-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.30.2
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

The single user wants this the sane way around.  Write it as a normal static
inline just like rspin_lock().

Fixes: cc3e8df542ed ("xen/spinlock: add rspin_[un]lock_irq[save|restore]()")
Signed-off-by: Andrew Cooper 
---
CC: Juergen Gross 
CC: George Dunlap 
CC: Jan Beulich 
CC: Stefano Stabellini 
CC: Julien Grall 
---
 xen/drivers/char/console.c |  6 +-----
 xen/include/xen/spinlock.h | 14 ++++++++------
 2 files changed, 9 insertions(+), 11 deletions(-)

diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index ccd5f8cc149f..349ce2a50d96 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -1159,11 +1159,7 @@ void console_end_log_everything(void)
 
 unsigned long console_lock_recursive_irqsave(void)
 {
-    unsigned long flags;
-
-    rspin_lock_irqsave(&console_lock, flags);
-
-    return flags;
+    return rspin_lock_irqsave(&console_lock);
 }
 
 void console_unlock_recursive_irqrestore(unsigned long flags)
diff --git a/xen/include/xen/spinlock.h b/xen/include/xen/spinlock.h
index 593cba640ee6..f210aa77f581 100644
--- a/xen/include/xen/spinlock.h
+++ b/xen/include/xen/spinlock.h
@@ -278,12 +278,6 @@ static always_inline void spin_lock_if(bool condition, spinlock_t *l)
  */
 bool _rspin_trylock(rspinlock_t *lock);
 void _rspin_lock(rspinlock_t *lock);
-#define rspin_lock_irqsave(l, f)                                \
-    ({                                                          \
-        BUILD_BUG_ON(sizeof(f) != sizeof(unsigned long));       \
-        (f) = _rspin_lock_irqsave(l);                           \
-        block_lock_speculation();                               \
-    })
 unsigned long _rspin_lock_irqsave(rspinlock_t *lock);
 void _rspin_unlock(rspinlock_t *lock);
 void _rspin_unlock_irqrestore(rspinlock_t *lock, unsigned long flags);
@@ -294,6 +288,14 @@ static always_inline void rspin_lock(rspinlock_t *lock)
     block_lock_speculation();
 }
 
+static always_inline unsigned long rspin_lock_irqsave(rspinlock_t *lock)
+{
+    unsigned long flags = _rspin_lock_irqsave(lock);
+
+    block_lock_speculation();
+    return flags;
+}
+
 #define rspin_trylock(l)              lock_evaluate_nospec(_rspin_trylock(l))
 #define rspin_unlock(l)               _rspin_unlock(l)
 #define rspin_unlock_irqrestore(l, f) _rspin_unlock_irqrestore(l, f)

base-commit: d2276b86e5eb8dd2617d917f7b49cdd1f29ac299
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Tue Mar 19 11:31:22 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 11:31:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695332.1084997 (Exim 4.92)
	(envelope-from )
	id 1rmXgf-0005YA-W2; Tue, 19 Mar 2024 11:31:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695332.1084997; Tue, 19 Mar 2024 11:31:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmXgf-0005Y3-T7; Tue, 19 Mar 2024 11:31:21 +0000
Received: by outflank-mailman (input) for mailman id 695332;
 Tue, 19 Mar 2024 11:31:20 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmXge-0005Xk-08; Tue, 19 Mar 2024 11:31:20 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmXgd-00024n-KS; Tue, 19 Mar 2024 11:31:19 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmXgd-0001gR-8L; Tue, 19 Mar 2024 11:31:19 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rmXgd-0006vL-7k; Tue, 19 Mar 2024 11:31:19 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=GNxeg+thx2X01MNu6eiGQqC4TTYZNWeSHe2zCH7NxGQ=; b=Rzc8eKV4qgh8X6Gpie1LpQRoyc
	kdG7rVhymY6DBYYQe1j6odN8q30PM+YZxs0BnEIZOamLgY4dUN6fe1nK0O4bFMtXitFoL4J6o5SHt
	ReKXM3AAOJGCtRvPiBhELrG6rBxacqVKddO19P3VZ9iT1cn3r9ViujxyoCdg5i7zPseU=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-5.4 test] 185080: regressions - FAIL
X-Osstest-Failures:
    linux-5.4:test-armhf-armhf-xl-credit1:guest-start/debian.repeat:fail:regression
    linux-5.4:test-amd64-i386-xl-qemut-debianhvm-i386-xsm:debian-hvm-install:fail:heisenbug
    linux-5.4:test-armhf-armhf-libvirt-qcow2:guest-start/debian.repeat:fail:heisenbug
    linux-5.4:test-armhf-armhf-xl-credit1:guest-start:fail:heisenbug
    linux-5.4:test-armhf-armhf-xl-rtds:guest-start:fail:heisenbug
    linux-5.4:test-arm64-arm64-libvirt-raw:guest-start/debian.repeat:fail:heisenbug
    linux-5.4:test-armhf-armhf-libvirt-qcow2:guest-start:fail:heisenbug
    linux-5.4:test-armhf-armhf-xl-vhd:guest-start/debian.repeat:fail:heisenbug
    linux-5.4:test-armhf-armhf-xl-multivcpu:guest-start/debian.repeat:fail:heisenbug
    linux-5.4:test-armhf-armhf-xl-credit2:guest-start:fail:heisenbug
    linux-5.4:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    linux-5.4:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking
    linux-5.4:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
    linux-5.4:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking
    linux-5.4:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    linux-5.4:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    linux-5.4:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-5.4:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    linux-5.4:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
    linux-5.4:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
    linux-5.4:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    linux-5.4:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
    linux-5.4:test-amd64-i386-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-5.4:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    linux=84075826304f1a297838de6bcfd9bd84f566026e
X-Osstest-Versions-That:
    linux=3fec063b052e395f4920fbc59a8d0bb3c9666d76
From: osstest service owner 
Date: Tue, 19 Mar 2024 11:31:19 +0000

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-credit1 18 guest-start/debian.repeat fail REGR. vs. 184921

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail in 185058 pass in 185080
 test-armhf-armhf-libvirt-qcow2 17 guest-start/debian.repeat fail in 185058 pass in 185080
 test-armhf-armhf-xl-credit1  14 guest-start      fail in 185071 pass in 185080
 test-armhf-armhf-xl-rtds     14 guest-start      fail in 185071 pass in 185080
 test-arm64-arm64-libvirt-raw 17 guest-start/debian.repeat fail in 185071 pass in 185080
 test-armhf-armhf-libvirt-qcow2 13 guest-start    fail in 185071 pass in 185080
 test-armhf-armhf-xl-vhd 17 guest-start/debian.repeat fail in 185071 pass in 185080
 test-armhf-armhf-xl-multivcpu 18 guest-start/debian.repeat fail pass in 185058
 test-armhf-armhf-xl-credit2  14 guest-start                fail pass in 185071

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-credit2 15 migrate-support-check fail in 185071 never pass
 test-armhf-armhf-xl-credit2 16 saverestore-support-check fail in 185071 never pass
 test-armhf-armhf-libvirt     16 saverestore-support-check    fail  like 184921
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop            fail like 184921
 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop             fail like 184921
 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop             fail like 184921
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop            fail like 184921
 test-armhf-armhf-xl-rtds     18 guest-start/debian.repeat    fail  like 184921
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop            fail like 184921
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop            fail like 184921
 test-armhf-armhf-libvirt-raw 15 saverestore-support-check    fail  like 184921
 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop             fail like 184921
 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check   fail like 184921
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop             fail like 184921
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184921
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass
 test-amd64-i386-libvirt-xsm  15 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     15 migrate-support-check        fail   never pass
 test-amd64-i386-xl-pvshim    14 guest-start                  fail   never pass
 test-amd64-i386-libvirt      15 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          16 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-multivcpu 15 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-credit1  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-check    fail  never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass
 test-armhf-armhf-xl-rtds     15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     16 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  16 saverestore-support-check    fail   never pass
 test-amd64-i386-libvirt-raw  14 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-raw 14 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-raw 15 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-vhd      14 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-vhd      15 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-raw 14 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-qcow2 14 migrate-support-check        fail never pass
 test-armhf-armhf-xl-vhd      14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      15 saverestore-support-check    fail   never pass

version targeted for testing:
 linux                84075826304f1a297838de6bcfd9bd84f566026e
baseline version:
 linux                3fec063b052e395f4920fbc59a8d0bb3c9666d76

Last test of basis   184921  2024-03-06 14:47:02 Z   12 days
Testing same since   185054  2024-03-15 19:18:15 Z    3 days    6 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Morton 
  Andy Shevchenko 
  Andy Shevchenko 
  Ansuel Smith 
  Arnd Bergmann 
  Bjorn Andersson 
  Bjorn Andersson 
  Chandan Kumar Rout  (A Contingent Worker at Intel)
  Cosmin Tanislav 
  David S. Miller 
  Dexuan Cui 
  Dmitry Torokhov 
  Dylan Hatch 
  Edward Adam Davis 
  Eric Dumazet 
  Florian Fainelli 
  Florian Westphal 
  Greg Kroah-Hartman 
  Haiyang Zhang 
  Harshit Mogalapalli 
  Hugo Villeneuve 
  Jakub Kicinski 
  Jan Kundrát 
  Jason Xing 
  Johan Hovold 
  Johannes Berg 
  John Efstathiades 
  Juhee Kang 
  Lena Wang 
  Lina Iyer 
  Linux Kernel Functional Testing 
  Maciej Fijalkowski 
  Magnus Karlsson 
  Marek Vasut 
  Mark Brown 
  Nico Pache 
  Oleg Nesterov 
  Oleksij Rempel 
  Pablo Neira Ayuso 
  Paolo Abeni 
  Rand Deeb 
  Richard Weinberger 
  Sasha Levin 
  Shachar Raindel 
  Shradha Gupta 
  Stephen Hemminger 
  Tony Nguyen 
  Werner Sembach 

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-i386-examine-bios                                 pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  fail    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  fail    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-armhf-armhf-libvirt-qcow2                               pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-libvirt-raw                                  pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     fail    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-i386-examine-uefi                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-arm64-arm64-xl-vhd                                      pass    
 test-armhf-armhf-xl-vhd                                      pass    
 test-amd64-i386-xl-vhd                                       pass    


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

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

Explanation of these 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 1433 lines long.)


From xen-devel-bounces@lists.xenproject.org Tue Mar 19 12:12:46 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 12:12:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695349.1085008 (Exim 4.92)
	(envelope-from )
	id 1rmYKQ-0003Qs-DC; Tue, 19 Mar 2024 12:12:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695349.1085008; Tue, 19 Mar 2024 12:12:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmYKQ-0003Ql-AE; Tue, 19 Mar 2024 12:12:26 +0000
Received: by outflank-mailman (input) for mailman id 695349;
 Tue, 19 Mar 2024 12:12:25 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmYKP-0003Qd-2l
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 12:12:25 +0000
Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com
 [2607:f8b0:4864:20::735])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f131974e-e5e9-11ee-afdd-a90da7624cb6;
 Tue, 19 Mar 2024 13:12:23 +0100 (CET)
Received: by mail-qk1-x735.google.com with SMTP id
 af79cd13be357-789db18e169so410433785a.1
 for ; Tue, 19 Mar 2024 05:12:23 -0700 (PDT)
Received: from localhost ([85.31.135.62]) by smtp.gmail.com with ESMTPSA id
 c14-20020a37e10e000000b007883a49baeesm5393735qkm.4.2024.03.19.05.12.21
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 19 Mar 2024 05:12:22 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f131974e-e5e9-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710850343; x=1711455143; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=gQt0odOmvw5H6hpmT06UGP+RKK8QTRgUqYE6UvCuvfw=;
        b=X2xNKT3g8UkGnySnbq2iQ481af/9VyrLEeeJq+W/iXtcUKisjhGvItjOFqWiWbrchE
         6mQlyNNsq4z2EkY26t04HiFAXLU5CAcNDlI9I3o9Op4Gln3HVCZahk4Pqu1uv9iUH6DR
         j4gFhmGwqWbqmtc4evLD0rF9kD9GXTTDZa91M=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710850343; x=1711455143;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=gQt0odOmvw5H6hpmT06UGP+RKK8QTRgUqYE6UvCuvfw=;
        b=JIb2bvEmof6fks4SwpCw6xjWApPGW5/m6PKEN/pM82fc4lSDVNGSvolqKVRGBMsf5z
         uqi6xOeoR7tvDsuxSVtV4WTim68MtvwANXJpHVJ+JD5o+rMJpLFAaH2dwV6sxj48EEWh
         pvBZIKWfvS2gzlePEjBuMNcgQspajvcSdhrfFrK8XOsnu7o6uFAZffMtUK0UzDu2yHVD
         DHuIw9RLSPiA3Sz/5eMYNCKbwpDdF4WfewQqqLz3tLhhGP+fFvuoRQFDGaJCvRmHSZU1
         eBe0kdeo7zKbguyhiBCYLlvYfIx5dqP9FFlBH5c9FvaXD1ule8YpubtX46wK0Wo+8Qas
         uVPQ==
X-Forwarded-Encrypted: i=1; AJvYcCXs8V3mFb93rqqRPm7wHNCFb70KcvAGiMW2pic4QgqUiF+5opayhEjiIkoIo2LeCt1dMdnKSjTVZNXaTb52UC7b3VXjBHpegCrdgCB+1wk=
X-Gm-Message-State: AOJu0YxqK+uOCl6v1ETiE6U1SnPgQilvNl6PxIsWSi6xmBdF9P8kIGaD
	AdxY5AoW1hPV8kvXBpJ/yXvsLW3EYGJgZQ0ntg6vJyw3ZkjKoN25wloU8EJaRvUIbOoCzkIJisK
	U
X-Google-Smtp-Source: AGHT+IHujs1BIDKf3HnuE/+uXlGopEJkkf1KUyI/0UKnM59OyfByEdnWC59U0Xr2iWMQqy+fEMEi9Q==
X-Received: by 2002:a05:620a:2408:b0:788:2b2f:4d74 with SMTP id d8-20020a05620a240800b007882b2f4d74mr20664050qkn.18.1710850342651;
        Tue, 19 Mar 2024 05:12:22 -0700 (PDT)
Date: Tue, 19 Mar 2024 13:12:20 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Ross Lagerwall 
Cc: Jan Beulich , xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Daniel Kiper , grub-devel@gnu.org
Subject: Re: [PATCH 1/7] multiboot2: Add load type header and support for the
 PE binary type
Message-ID: 
References: <20240313150748.791236-1-ross.lagerwall@citrix.com>
 <20240313150748.791236-2-ross.lagerwall@citrix.com>
 
 
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Thu, Mar 14, 2024 at 02:24:31PM +0000, Ross Lagerwall wrote:
> On Thu, Mar 14, 2024 at 1:37 PM Jan Beulich  wrote:
> >
> > On 14.03.2024 10:30, Ross Lagerwall wrote:
> > > On Thu, Mar 14, 2024 at 7:24 AM Jan Beulich  wrote:
> > >>
> > >> On 13.03.2024 16:07, Ross Lagerwall wrote:
> > >>> In addition to the existing address and ELF load types, specify a new
> > >>> optional PE binary load type. This new type is a useful addition since
> > >>> PE binaries can be signed and verified (i.e. used with Secure Boot).
> > >>
> > >> And the consideration to have ELF signable (by whatever extension to
> > >> the ELF spec) went nowhere?
> > >>
> > >
> > > I'm not sure if you're referring to some ongoing work to create signable
> > > ELFs that I'm not aware of.
> >
> > Something must have been invented already to make Linux modules signable.
> 
> Linux module signatures operate outside of the ELF container. In fact,
> AFAIK the actual signed content could be anything. The file format is:
> 
> * Content (i.e. ELF binary)
> * Signature of content in PKCS7 format
> * Signature info, including signature length
> * Magic marker: "~Module signature appended~\n"
> 
> This kind of arrangement does indeed work but it is fragile. Since the
> signature is on the entire contents and tools that understand ELF don't
> parse the signature, any transformation of the binary (e.g. to
> strip out debuginfo) will cause the signature to be lost / invalidated.
> 
> Nevertheless, this could still be an option for Xen if this is
> deemed to be a preferred solution by others. It would be good to hear
> some opinions on this.

No, IMO the PE route is likely the best one, as there's already all
the tooling around it, and it's what other OSes use to perform secure
boot.

It would have been nice for ELF to grow an extension to the spec for
image integrity data, but I don't see myself doing the work TBH.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Mar 19 12:27:45 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 12:27:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695354.1085018 (Exim 4.92)
	(envelope-from )
	id 1rmYZ7-0005Sh-LY; Tue, 19 Mar 2024 12:27:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695354.1085018; Tue, 19 Mar 2024 12:27:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmYZ7-0005Sa-Ix; Tue, 19 Mar 2024 12:27:37 +0000
Received: by outflank-mailman (input) for mailman id 695354;
 Tue, 19 Mar 2024 12:27:36 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmYZ6-0005SQ-Ju; Tue, 19 Mar 2024 12:27:36 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmYZ6-00034x-4j; Tue, 19 Mar 2024 12:27:36 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmYZ5-0003Hf-PM; Tue, 19 Mar 2024 12:27:35 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rmYZ5-0002db-Oo; Tue, 19 Mar 2024 12:27:35 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=LsYTGBI2WMI9KhvtEv/tOjK7S3h+U+QyuEsbwV/8ILA=; b=Zjnby8KtiButM6MQaz7Q9RIMx1
	Xncfi5BmQZUNu2JnpVxsToP2Mw/nJUc6lkabbBJtCvwviJSZFCad2X1ieUIwDOuCahspdG9nmACEK
	/Yiw6xTsPf2b/rHQr1WVTZnAy+u/Xl1acF8E/Qy7C5/1RRFdHtooPGMone8EmeZqz/Zo=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [ovmf test] 185093: regressions - trouble: blocked/broken/pass
X-Osstest-Failures:
    ovmf:build-amd64-pvops::broken:regression
    ovmf:build-amd64-pvops:host-build-prep:fail:regression
    ovmf:test-amd64-amd64-xl-qemuu-ovmf-amd64:build-check(1):blocked:nonblocking
X-Osstest-Versions-This:
    ovmf=35f6a2780e5198315a9f100c07b3bc86187d20a8
X-Osstest-Versions-That:
    ovmf=3840c35e34d1c992268092b6366e26f2acc55a75
From: osstest service owner 
Date: Tue, 19 Mar 2024 12:27:35 +0000

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-pvops                                broken
 build-amd64-pvops             5 host-build-prep          fail REGR. vs. 185049

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1)             blocked n/a

version targeted for testing:
 ovmf                 35f6a2780e5198315a9f100c07b3bc86187d20a8
baseline version:
 ovmf                 3840c35e34d1c992268092b6366e26f2acc55a75

Last test of basis   185049  2024-03-15 12:41:10 Z    3 days
Testing same since   185093  2024-03-19 10:11:15 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Ceping Sun 

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-pvops                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    


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

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

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

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

broken-job build-amd64-pvops broken

Not pushing.

------------------------------------------------------------
commit 35f6a2780e5198315a9f100c07b3bc86187d20a8
Author: Ceping Sun 
Date:   Tue Feb 27 05:18:33 2024 +0800

    OvmfPkg/TdxDxe: Clear the registers before tdcall
    
    REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4696
    
    Refer to the [GHCI] spec, TDVF should clear the BIT5 for RBP in the mask.
    And TDVF should clear the regitsers to avoid leaking secrets to VMM.
    
    Reference:
    [GHCI]: TDX Guest-Host-Communication Interface v1.5
    https://cdrdv2.intel.com/v1/dl/getContent/726792
    
    Cc: Erdem Aktas 
    Cc: James Bottomley 
    Cc: Jiewen Yao 
    Cc: Min Xu 
    Cc: Tom Lendacky 
    Cc: Michael Roth 
    Cc: Gerd Hoffmann 
    Cc: Erdem Aktas 
    Cc: Isaku Yamahata 
    Signed-off-by: Ceping Sun 
    Reviewed-by: Jiewen Yao 
    Reviewed-by: Min Xu 

commit a1a6da80aa80baecfba71a4d8e4c38dbb8f2f4d3
Author: Ceping Sun 
Date:   Tue Feb 27 05:18:32 2024 +0800

    OvmfPkg/CcExitLib: Update TDVMCALL_EXPOSE_REGS_MASK
    
    REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4696
    
    Refer to the [GHCI] spec, TDVF should clear the BIT5 for RBP in the mask.
    
    Reference:
    [GHCI]: TDX Guest-Host-Communication Interface v1.5
    https://cdrdv2.intel.com/v1/dl/getContent/726792
    
    Cc: Erdem Aktas 
    Cc: James Bottomley 
    Cc: Jiewen Yao 
    Cc: Min Xu 
    Cc: Tom Lendacky 
    Cc: Michael Roth 
    Cc: Gerd Hoffmann 
    Cc: Isaku Yamahata 
    Signed-off-by: Ceping Sun 
    Reviewed-by: Jiewen Yao 
    Reviewed-by: Min Xu 

commit 07c49d5d402429ef4dbe1da5f8371a0a07bcc279
Author: Ceping Sun 
Date:   Tue Feb 27 05:18:31 2024 +0800

    MdePkg/BaseLib: Update TDVMCALL_EXPOSE_REGS_MASK
    
    REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4696
    
    Refer to the [GHCI] spec, TDVF should clear the BIT5 for RBP in the mask.
    
    Reference:
    [GHCI]: TDX Guest-Host-Communication Interface v1.5
    https://cdrdv2.intel.com/v1/dl/getContent/726792
    
    Cc: Liming Gao 
    Cc: Michael D Kinney 
    Cc: Erdem Aktas 
    Cc: James Bottomley 
    Cc: Jiewen Yao 
    Cc: Min Xu 
    Cc: Tom Lendacky 
    Cc: Michael Roth 
    Cc: Isaku Yamahata 
    Signed-off-by: Ceping Sun 
    Reviewed-by: Liming Gao 


From xen-devel-bounces@lists.xenproject.org Tue Mar 19 13:10:29 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 13:10:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695363.1085028 (Exim 4.92)
	(envelope-from )
	id 1rmZEW-0003yd-R0; Tue, 19 Mar 2024 13:10:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695363.1085028; Tue, 19 Mar 2024 13:10:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmZEW-0003yW-Np; Tue, 19 Mar 2024 13:10:24 +0000
Received: by outflank-mailman (input) for mailman id 695363;
 Tue, 19 Mar 2024 13:10:23 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmZEV-0003yL-Fq
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 13:10:23 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on20601.outbound.protection.outlook.com
 [2a01:111:f403:2414::601])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0985751e-e5f2-11ee-a1ee-f123f15fe8a2;
 Tue, 19 Mar 2024 14:10:20 +0100 (CET)
Received: from DM6PR14CA0037.namprd14.prod.outlook.com (2603:10b6:5:18f::14)
 by PH8PR12MB7328.namprd12.prod.outlook.com (2603:10b6:510:214::7) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.30; Tue, 19 Mar
 2024 13:10:15 +0000
Received: from CH1PEPF0000AD7D.namprd04.prod.outlook.com
 (2603:10b6:5:18f:cafe::b0) by DM6PR14CA0037.outlook.office365.com
 (2603:10b6:5:18f::14) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.27 via Frontend
 Transport; Tue, 19 Mar 2024 13:10:12 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CH1PEPF0000AD7D.mail.protection.outlook.com (10.167.244.86) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Tue, 19 Mar 2024 13:10:11 +0000
Received: from SATLEXMB06.amd.com (10.181.40.147) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Tue, 19 Mar
 2024 08:10:10 -0500
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB06.amd.com
 (10.181.40.147) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Tue, 19 Mar
 2024 08:10:09 -0500
Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Tue, 19 Mar 2024 08:10:08 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0985751e-e5f2-11ee-a1ee-f123f15fe8a2
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=i0u3VfrBJUsLY7MVX3BuSPkl1ubtqGskhoWfCnbE2O3pu2hVnhUqyWxF7Bi7gAZn/QRuB0nbI6vBVO4AGZ08zl7TDOqj/PnC+1O6gYAK7sCAkKvnE4c/68LfOVErSJrnZ211sTxxUk/czyu5xnEhiyDYtgrRgeEI7iBvGeHSddYwKo7tK2LKO+zZhQPTeWBzOttko2ftMu1YbAmIXJZkCN4JDSwb8Fw7PuTeoWkhBkNxkm/X6VghXU4XNy2LaE++jgc7m6uCdhDoZX06np2S38EjeYwjH23UAXo2l8PvCNB33dPOipjsBSBGyfwlFchjgJXWbrpA+OuqYc2dcGoIKA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=dsmyBd0bP8uAZJ09PLh60OBCZMw+z+H0XvEyAGsSFqQ=;
 b=O8TC0lcsyvyYIeks+Rb8JVlDWJVrvyAbBWHlICfKqjVRcE2tNStLmbyhaFK0KuFUK/W5rhT0tp8CsB2UMinqdKNNSJW2WNWDhbKaLukBtbykKEAEiMgfezADEgV1nae0UjO3PTAitbqsSKIZmmCFtvRQlE95TPHjrcYdEeV5+ePxrldbpbRuL1Pw5qaAwvkGz1frmYIlBAvcBsRiEljB7OcmRxV80Y3fXNQAzWJCSK+2s8hULqco1aAMuJU0lsQWUm+zzd85XtYUXQv/kVPEW2Mujg7xX+L3SzidNrAXKT2cR0jvYttOl480I2aa9Cdc7jeak4vsw/0njhlsvOLgfw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=arm.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=dsmyBd0bP8uAZJ09PLh60OBCZMw+z+H0XvEyAGsSFqQ=;
 b=K3kvRyRhWjaoAKexoAZPKSMwh4Q3fvdIA48fnkeDnEBOY47sNx3ovhSrObSh7EOhbWk595Aee6h+tVAR2VSlPvXq3sXzfieYL202sXTBPd7mMudTTgn6+nlcVITDx07R9xpsOzzRrd5g/x9C8Z+axAR66MB7E2w5FVvnAwTkEtw=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Message-ID: <73dbf297-31ed-4cf1-b081-c6f82c234de8@amd.com>
Date: Tue, 19 Mar 2024 14:10:08 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 03/11] xen/arm: Introduce a generic way to access memory
 bank structures
Content-Language: en-US
To: Luca Fancellu , 
CC: Stefano Stabellini , Julien Grall
	, Bertrand Marquis , "Volodymyr
 Babchuk" 
References: <20240312130331.78418-1-luca.fancellu@arm.com>
 <20240312130331.78418-4-luca.fancellu@arm.com>
From: Michal Orzel 
In-Reply-To: <20240312130331.78418-4-luca.fancellu@arm.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH1PEPF0000AD7D:EE_|PH8PR12MB7328:EE_
X-MS-Office365-Filtering-Correlation-Id: b7a94ba6-e445-4904-b268-08dc4815e8f3
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	L9ghwBFw7NJgRyz7TXNgG3zBnxKLlxvORK0jD/NV+dE/YbSVmUSw6IOPfpIYgWWO9JuDp1zmDMxio3mBVKIQymsz0Tj/n2cx6Jq0JeORrvLvEAMz7i4hxI6qKNmAxwUx2aNJdVHRZ6rd6dUFGwzj8RHusMvqV7HoF+WMR5PpZxil2AE3b/gLhy0ZM2NE7BoJNXpd6vnoJ6o/9/KKUATamXkJtll1qzzQ18AQS0hfg45beL7+ARZvXJ/XZKhzFxNc+7VDNS/7PzyK3mMHdSbGEWM6Q41yGToRHVPYGs2at9MnkOOT7fjI71eIphG7jbqKecBRnhEHXuzYHhK8ZU4f06yER51EkdpQ2xa9CtiRXVZAiETekhXFswoNb5ZcMte/hrGV2GlGr+8Hka1I0sr/K1jx6ooyn5ZVCTMBgVqkFBgKlTTTTgU0hDXRwLKaTQxKQ2m+8qFQ6pTG5zHz/rJD5n2aQDSadbg7bMwETag4omyMNz3Q0TvkQjW+k2rHMMpmoWtrs8NJgAqkhA021tSkmtfHMiGUsVlP+38u38BpqTyDEox845+vsr4xKkdCMEZ+3t+A6rpAQNzy20P/qo2Dt/z6io5PCKyl+49e6mXcHv6zKRW3IXj2DQg1bVT4mj6QYXk97bliUQYi0vUWJWr5tyypcb92FxsljkD/i72z5vqUjdpxGZLBv175XoP5LE8vxMu0+YKUcsIr6gOWw0R9SKFdZlq1r/RikJZ0/e/rHPqjsTH1Uacdo2GNs/YGk8Q+
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(34020700007)(82310400014)(36860700004)(1800799015)(376005);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Mar 2024 13:10:11.8940
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: b7a94ba6-e445-4904-b268-08dc4815e8f3
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH1PEPF0000AD7D.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR12MB7328

Hi Luca,

On 12/03/2024 14:03, Luca Fancellu wrote:
> 
> 
> Currently the 'stuct meminfo' is defining a static defined array of
> 'struct membank' of NR_MEM_BANKS elements, some feature like
> shared memory don't require such amount of memory allocation but
> might want to reuse existing code to manipulate this kind of
> structure that is just as 'struct meminfo' but less bulky.
> 
> For this reason introduce a generic way to access this kind of
> structure using a new stucture 'struct membanks', which implements
s/stucture/structure

> all the fields needed by a structure related to memory banks
> without the need to specify at build time the size of the
> 'struct membank' array.
Might be beneficial here to mention the use of FAM.

> 
> Modify 'struct meminfo' to implement the field related to the new
> introduced structure, given the change all usage of this structure
> are updated in this way:
>  - code accessing bootinfo.{mem,reserved_mem,acpi} field now uses
>    3 new introduced static inline helpers to access the new field
>    of 'struct meminfo' named 'common'.
>  - code accessing 'struct kernel_info *' member 'mem' now use the
>    new introduced macro 'kernel_info_get_mem(...)' to access the
>    new field of 'struct meminfo' named 'common'.
> 
> Constify pointers where needed.
> 
> Suggested-by: Julien Grall 
> Signed-off-by: Luca Fancellu 
> ---
>  xen/arch/arm/acpi/domain_build.c        |   6 +-
>  xen/arch/arm/arm32/mmu/mm.c             |  44 +++++-----
>  xen/arch/arm/arm64/mmu/mm.c             |   2 +-
>  xen/arch/arm/bootfdt.c                  |  27 +++---
>  xen/arch/arm/dom0less-build.c           |  18 ++--
>  xen/arch/arm/domain_build.c             | 106 +++++++++++++-----------
>  xen/arch/arm/efi/efi-boot.h             |   8 +-
>  xen/arch/arm/efi/efi-dom0.c             |  13 +--
>  xen/arch/arm/include/asm/domain_build.h |   2 +-
>  xen/arch/arm/include/asm/kernel.h       |   9 ++
>  xen/arch/arm/include/asm/setup.h        |  40 ++++++++-
>  xen/arch/arm/include/asm/static-shmem.h |   4 +-
>  xen/arch/arm/kernel.c                   |  12 +--
>  xen/arch/arm/setup.c                    |  58 +++++++------
>  xen/arch/arm/static-memory.c            |  27 +++---
>  xen/arch/arm/static-shmem.c             |  34 ++++----
>  16 files changed, 243 insertions(+), 167 deletions(-)
Lots of mechanical changes but in general I like this approach.
I'd like other maintainers to share their opinion.

[...]

> @@ -1157,10 +1163,12 @@ int __init make_hypervisor_node(struct domain *d,
>      }
>      else
>      {
> -        ext_regions = xzalloc(struct meminfo);
> +        ext_regions = (struct membanks *)xzalloc(struct meminfo);
You're making assumption that struct membanks is the first member of meminfo but there's no sanity check.
Why not xzalloc_flex_struct()?

>          if ( !ext_regions )
>              return -ENOMEM;

[...]
> diff --git a/xen/arch/arm/include/asm/kernel.h b/xen/arch/arm/include/asm/kernel.h
> index 0a23e86c2d37..d28b843c01a9 100644
> --- a/xen/arch/arm/include/asm/kernel.h
> +++ b/xen/arch/arm/include/asm/kernel.h
> @@ -78,6 +78,15 @@ struct kernel_info {
>      };
>  };
> 
> +#define kernel_info_get_mem(kinfo) \
> +    (&(kinfo)->mem.common)
Why this is a macro but for bootinfo you use static inline helpers?

> +
> +#define KERNEL_INFO_INIT \
NIT: in most places we prefer \ to be aligned (the same apply to other places)

> +{ \
> +    .mem.common.max_banks = NR_MEM_BANKS, \
> +    .shm_mem.common.max_banks = NR_MEM_BANKS, \
> +}
> +
>  /*
>   * Probe the kernel to detemine its type and select a loader.
>   *
> diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h
> index d15a88d2e0d1..a3e1dc8fdb6c 100644
> --- a/xen/arch/arm/include/asm/setup.h
> +++ b/xen/arch/arm/include/asm/setup.h
> @@ -56,8 +56,14 @@ struct membank {
>  #endif
>  };
> 
> -struct meminfo {
> +struct membanks {
>      unsigned int nr_banks;
> +    unsigned int max_banks;
> +    struct membank bank[];
> +};
> +
> +struct meminfo {
> +    struct membanks common;
You were supposed to make sure there is no extra padding here. I don't see any check in this patch.
I'd at least do sth like:
BUILD_BUG_ON((offsetof(struct membanks, bank)) != (offsetof(struct meminfo, bank)));

~Michal


From xen-devel-bounces@lists.xenproject.org Tue Mar 19 13:12:06 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 13:12:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695365.1085038 (Exim 4.92)
	(envelope-from )
	id 1rmZG0-0004VF-5f; Tue, 19 Mar 2024 13:11:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695365.1085038; Tue, 19 Mar 2024 13:11:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmZG0-0004V8-27; Tue, 19 Mar 2024 13:11:56 +0000
Received: by outflank-mailman (input) for mailman id 695365;
 Tue, 19 Mar 2024 13:11:55 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmZFz-0004V2-20
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 13:11:55 +0000
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com
 [2a00:1450:4864:20::52a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 415d328a-e5f2-11ee-afdd-a90da7624cb6;
 Tue, 19 Mar 2024 14:11:53 +0100 (CET)
Received: by mail-ed1-x52a.google.com with SMTP id
 4fb4d7f45d1cf-5687e7662a5so7237954a12.0
 for ; Tue, 19 Mar 2024 06:11:53 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 be7-20020a1709070a4700b00a46a9c38b16sm3784738ejc.138.2024.03.19.06.11.52
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 19 Mar 2024 06:11:52 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 415d328a-e5f2-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710853913; x=1711458713; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:references:cc:to
         :from:content-language:subject:user-agent:mime-version:date
         :message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=tnslb6UNJK9HMW3KOfGHoHtrc1Sd+dFeIjsLCImWtTE=;
        b=LHTkec1Suu9s3p27sM94D/1ULTBmIMA1EVLLt3Tm403/6qzUGm2czPOWbgDLK+ulC/
         riy8pN8BrTWXxsRqfOam/AwZrACoc96mUIDFyA1VAdNBQWLi1B5lwhaB4KQzn1+jSoQC
         PdCazpmXY2XaE+zBQFupg7iPO71zfRPe58lz3Mq97D9KHKzLMmCmsTVLZ/6fsB5Xts9R
         tXiB0veSnCoCS/xYSfPS838oGbpkrpDn4i7e9SMwxbw9hxzQYfh/AXblgTMNWKPvnmiy
         C8zMMhr6P5M7EAqsn+9TdrmgymxkiSHL60kZhLVZ/LtaAS+qaX0X6iYLIWsCpXn71nLP
         nJPg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710853913; x=1711458713;
        h=content-transfer-encoding:in-reply-to:autocrypt:references:cc:to
         :from:content-language:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=tnslb6UNJK9HMW3KOfGHoHtrc1Sd+dFeIjsLCImWtTE=;
        b=g5/ghR/S14aCBLvOzDdValxDLrx5qVbp4Dc4VOXYUhBQM5O2E6SFuoubpdVsVwMe+C
         TsIbUkS6InMRKjpiDBQ3gSCHahoDqzUytEG8ECbtJMjXVMxkJoEeWy7LaoKHjA0gJgpz
         diw2mgM/+ueyHVnzNA1FE0FeVvOoZ+XojU9YrlH0xVhpIZnjnkXxNk2aF6FY0GdIgG0c
         ftEkz7Ae0/p04LLXJXEOqFMtMHpVrsrutmendKG23n1Eziq2SuGiRuIJX9CML/7NCvwH
         v9cUXWJxAQXzoxL/2hegkPNjWZovzibtNMe8LC348rkIWAp1vT+ni8E8OHy08oOTBRSf
         2O6Q==
X-Forwarded-Encrypted: i=1; AJvYcCV2zRsbOaTxswg1lCrWPAyoo43U6QkiNzCxr5gXHFnv3i4aC4seim+rP+K9IBAOm+CdAZrQfHYJSIjFf30YVvlQ6Vp4u/y5mP0CNWep+l0=
X-Gm-Message-State: AOJu0YzOLDbIl59RRpe7TLH/igOemt1M9o5hX+zfx0ImX6AT+55hg8FP
	jpzcaOeOx/3lmLpSefy4TP1XV5M6fOIDJSHm/X+5A+M+3KEtZzDJkSEWLs03wg==
X-Google-Smtp-Source: AGHT+IFe4iGzVkoikinF0l8xiXHtnNhxcru1a62MGmd38asrA416nyqNhxr8REb/1Af7Q1H+4YduHQ==
X-Received: by 2002:a17:906:74e:b0:a46:d049:6de2 with SMTP id z14-20020a170906074e00b00a46d0496de2mr1485444ejb.70.1710853913220;
        Tue, 19 Mar 2024 06:11:53 -0700 (PDT)
Message-ID: <4aa2aced-d4dc-40d6-818b-8163657cd670@suse.com>
Date: Tue, 19 Mar 2024 14:11:52 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/features: More AMD features
Content-Language: en-US
From: Jan Beulich 
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Xen-devel 
References: <20240318181332.3817631-1-andrew.cooper3@citrix.com>
 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 19.03.2024 08:33, Jan Beulich wrote:
> On 18.03.2024 19:13, Andrew Cooper wrote:
>> I'm not sure about FSRSC as a name, but it definitely beats AMD's longhand
>> name of FAST_REP_SCASB.
> 
> With FSRS already used, I guess that's the closest we can get to keep
> names for similar features similar.
> 
>> --- a/tools/misc/xen-cpuid.c
>> +++ b/tools/misc/xen-cpuid.c
>> @@ -91,6 +91,7 @@ static const char *const str_e1c[32] =
>>      [24] = "perfctr-nb", /* [25] */
>>      [26] = "dbx",        [27] = "perftsc",
>>      [28] = "pcx-l2i",    [29] = "monitorx",
>> +    [30] = "dbext2",
>>  };
> 
> AMD calls this AddrMaskExt (PM) or AdMskExtn (PPR). I can see where your
> different name choice is coming from, yet I still wonder whether we should
> try to stay closer where possible.

Having located the corresponding doc,
Reviewed-by: Jan Beulich 
with a slight preference to adjusted names for this one feature.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Mar 19 13:18:44 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 13:18:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695369.1085048 (Exim 4.92)
	(envelope-from )
	id 1rmZMO-0005Gj-Um; Tue, 19 Mar 2024 13:18:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695369.1085048; Tue, 19 Mar 2024 13:18:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmZMO-0005Gc-Ru; Tue, 19 Mar 2024 13:18:32 +0000
Received: by outflank-mailman (input) for mailman id 695369;
 Tue, 19 Mar 2024 13:18:31 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmZMN-0005DG-5Y
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 13:18:31 +0000
Received: from mail-qv1-xf32.google.com (mail-qv1-xf32.google.com
 [2607:f8b0:4864:20::f32])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2cbf5615-e5f3-11ee-a1ee-f123f15fe8a2;
 Tue, 19 Mar 2024 14:18:29 +0100 (CET)
Received: by mail-qv1-xf32.google.com with SMTP id
 6a1803df08f44-69145fc4265so38007266d6.1
 for ; Tue, 19 Mar 2024 06:18:29 -0700 (PDT)
Received: from localhost ([85.31.135.62]) by smtp.gmail.com with ESMTPSA id
 cz8-20020a056214088800b00691663dbd4csm5984370qvb.78.2024.03.19.06.18.27
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 19 Mar 2024 06:18:27 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2cbf5615-e5f3-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710854308; x=1711459108; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=eEZL8Wp7PtGZZCztHBKQg2DIByzevBllOdV4RD3XbXA=;
        b=QuoEsKSq/14CIeCbGnzE/8S+H9zGJIaEALQOtABrEHoYqCTiFVVzMZtoBT7IeH82QU
         496o+gtF1jUp+qfHcARRj7dF5arSw5/IqNigODynrOEYA4esMG4m/pwTICxKLT6c8h1u
         q62EG+ZslwYDkXs57bcCoSPW+E6M91ZeMBhFc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710854308; x=1711459108;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=eEZL8Wp7PtGZZCztHBKQg2DIByzevBllOdV4RD3XbXA=;
        b=B83oHzndhJbS+6BMdzMwn+56Vv7NrPxlYlL+xrUJ5zFrczcq/XDF4s5wEBXBICs2UC
         gkIab4+ZPtvUusIurgZpXaKHECbTYkecLUNqILfivMOEtAg4urlkmqfp5+FmNCc/5Udm
         /YPsNtT06d4GppQyZBcY0zBPXN5+j/yfGJOj12+9x0x6/9xZLP3+M+4dTGt+sFk7YUWe
         u/x/VaTahUmzZsNJbNdhbvUD5+NGjPuyNp2ndASZ+UgfseYqi0QXYFWGYY1bybS2nFtm
         s3IwNHsZ2m9uCXec9daUW5jqgiQL4pprHQfVp+8kiwzWYQru5mRdUS0wUmsPQsUrr/uM
         qXew==
X-Forwarded-Encrypted: i=1; AJvYcCVKWms+wQ52ibn92FKoqY1duULDWT7ztCrJsUC3svGmTGTnEghr4Vrlm7VW09fLEv9CS5vNL+t1jzBUotONtCakA4/UUDYnGJGoGUCklDs=
X-Gm-Message-State: AOJu0Yy8o823hbtUYeuhDV8/ZcwpqXXFMAuTXou8GwOy0uJ8IC+lSVpl
	1gOzOcCs5KdUSJY4dME24ZTErSiJOyJ35vjiDVa6u8wlcfKzzz9nUGicsgygQ7U=
X-Google-Smtp-Source: AGHT+IHSRYQ/BxWWIyxOaaI9zA/WImLgEQdIFCzGFXrRn7xOf6XttcNfvOdEZOc/Xl3c1FD9rTWCdg==
X-Received: by 2002:ad4:58a4:0:b0:691:698e:9299 with SMTP id ea4-20020ad458a4000000b00691698e9299mr1938874qvb.61.1710854307946;
        Tue, 19 Mar 2024 06:18:27 -0700 (PDT)
Date: Tue, 19 Mar 2024 14:18:25 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Ross Lagerwall 
Cc: grub-devel@gnu.org, xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Daniel Kiper 
Subject: Re: [PATCH 1/7] multiboot2: Add load type header and support for the
 PE binary type
Message-ID: 
References: <20240313150748.791236-1-ross.lagerwall@citrix.com>
 <20240313150748.791236-2-ross.lagerwall@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20240313150748.791236-2-ross.lagerwall@citrix.com>

On Wed, Mar 13, 2024 at 03:07:42PM +0000, Ross Lagerwall wrote:
> Currently, multiboot2-compatible bootloaders can load ELF binaries and
> a.out binaries. The presence of the address header tag determines
> how the bootloader tries to interpret the binary (a.out if the address
> tag is present else ELF).
> 
> Add a new load type header tag that explicitly states the type of the
> binary. Bootloaders should use the binary type specified in the load
> type tag. If the load type tag is not present, the bootloader should
> fall back to the previous heuristics.
> 
> In addition to the existing address and ELF load types, specify a new
> optional PE binary load type. This new type is a useful addition since
> PE binaries can be signed and verified (i.e. used with Secure Boot).
> 
> Signed-off-by: Ross Lagerwall 
> ---
>  doc/multiboot.texi | 39 ++++++++++++++++++++++++++++++++++-----
>  doc/multiboot2.h   | 13 +++++++++++++
>  2 files changed, 47 insertions(+), 5 deletions(-)
> 
> diff --git a/doc/multiboot.texi b/doc/multiboot.texi
> index df8a0d056e76..d12719c744eb 100644
> --- a/doc/multiboot.texi
> +++ b/doc/multiboot.texi
> @@ -511,11 +511,12 @@ assumes that no bss segment is present.
>  
>  Note: This information does not need to be provided if the kernel image
>  is in @sc{elf} format, but it must be provided if the image is in a.out
> -format or in some other format. When the address tag is present it must
> -be used in order to load the image, regardless of whether an @sc{elf}
> -header is also present. Compliant boot loaders must be able to load
> -images that are either in @sc{elf} format or contain the address tag
> -embedded in the Multiboot2 header.
> +format or in some other format. If the load type tag is not specified
> +and the address tag is present it must be used in order to load the
> +image, regardless of whether an @sc{elf} header is also present.
> +Compliant boot loaders must be able to load images that are either in
> +@sc{elf} format or contain the address tag embedded in the Multiboot2
> +header.
>  
>  @subsection The entry address tag of Multiboot2 header
>  
> @@ -732,6 +733,34 @@ and @samp{2} means load image at highest possible address but not
>  higher than max_addr.
>  @end table
>  
> +@node Load type tag
> +@subsection Load type tag
> +
> +@example
> +@group
> +        +-------------------+
> +u16     | type = 11         |
> +u16     | flags             |
> +u32     | size = 12         |
> +u32     | load_type         |
> +        +-------------------+
> +@end group
> +@end example
> +
> +This tag indicates the type of the payload and how the boot loader
> +should load it.
> +
> +The meaning of each field is as follows:
> +
> +@table @code
> +@item load_type
> +Recognized load types are @samp{0} for address (i.e. load a.out using
> +the address tag), @samp{1} for ELF, and @samp{2} for PE. Compliant
> +bootloaders should implement support for a.out and ELF as a minimum.  If
> +this tag is not specified, the boot loader should attempt to load the
> +payload using the information specified in the address tag if present,
> +else it should load the payload as an ELF binary.  @end table

I wonder if it would be simpler to use the following order instead:

1. Address tag
2. Load type tag
3. ELF header

It's pointless to add a Loader type tag with load_type == 0, as that's
already mandated by the Address tag.  IOW: signaling the use of the
Address tag here is kind of pointless, if the fields in the Address
tag are set, that's the only signaling required for the data in the
Address tag to be used.

Or are we attempting to support images that set Address tag and Load
type tag != 0 in order to use the Address tag when the loader doesn't
recognize the Load type tag, and otherwise use a different format?

Would it be sensible for multiboot2 to use PE in preference to ELF if
present on the image?  (without requiring any signaling).  I would
think this could be troublesome if kernels are so far expecting the
ELF header to be used with multiboot2, even if they also expose a PE
header.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Mar 19 13:22:16 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 13:22:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695373.1085058 (Exim 4.92)
	(envelope-from )
	id 1rmZPy-0006zU-Cv; Tue, 19 Mar 2024 13:22:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695373.1085058; Tue, 19 Mar 2024 13:22:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmZPy-0006zN-AE; Tue, 19 Mar 2024 13:22:14 +0000
Received: by outflank-mailman (input) for mailman id 695373;
 Tue, 19 Mar 2024 13:22:13 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmZPx-0006zH-5I
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 13:22:13 +0000
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com
 [2a00:1450:4864:20::632])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b1fa7bb7-e5f3-11ee-afdd-a90da7624cb6;
 Tue, 19 Mar 2024 14:22:12 +0100 (CET)
Received: by mail-ej1-x632.google.com with SMTP id
 a640c23a62f3a-a46a7b8e07fso415358266b.2
 for ; Tue, 19 Mar 2024 06:22:12 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 o20-20020a170906289400b00a4668980c12sm6046479ejd.182.2024.03.19.06.22.11
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 19 Mar 2024 06:22:11 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b1fa7bb7-e5f3-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710854531; x=1711459331; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:subject:from:user-agent:mime-version:date
         :message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=iNHqaS4hCYlzXBeIJcF37JkLflryMYj84q8OtdKaqUc=;
        b=TLxRYrpLg2FVEDe/5B699AlyiAOFmsIdY3PCZoqTCQK3aD/FcDvzoTuOOtgA9B5tCF
         JB4mTUEMuPH1vzIIS+kItHVjKPFPsdtWet2zaSVG5n2q2Kd7oF39qlDHXfDw7PQFjuY2
         who01+1rVCU609V4cyc6rkdd56N/w/pwTwW+ET6gDPZTdeT9wZxS8pH1JOp9EtUMT84X
         NxD+LMWtgJKdBx4zz9gsyeW7T3QXq8xx9Zs0T1LznPCkqtXyuYe7ovyTzTWnvKylTGPy
         aCADYjcOPuEY7GFcz8TenpTvUiyV/5IM7NdMJNTT87kB25p0OCoTpMQF3VhLm13or/v1
         ZeGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710854531; x=1711459331;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:subject:from:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=iNHqaS4hCYlzXBeIJcF37JkLflryMYj84q8OtdKaqUc=;
        b=m0BBgbXkugHpdxlktv2tHPfGdidxsayFaq+qmCF+mJCUizW2fleA1JH3G/1KCyB137
         XLeNKkf72IQofN8+6k9WpvR+zzxZDL0Cia2WgbyWWIVxED/wHBoAp8oDZ3w0yRxZtnPj
         tvPQULOSKpo8SZSeJjrfsIiq8WB1Ao2g4AOrGeVw27qBpe9n1J3wLrWfNpsSdTGD2JZH
         GsiViBYlipXUqVsMtvdRXQqE5vGcNpXy4wQJvZvHxkR+6PemKArGthc2defqK4OQdIOR
         tUfpYz2J+kye3FAfWV9OdaJ7hCqYQ0cf9OkUWjx5DuhcVypF2ywtJlfeusbCfKIpDF0o
         4K0Q==
X-Gm-Message-State: AOJu0YyEezz7J5EFzUPP6zcnlXvFG6qjWTAqfjQCgdJkfor1J89/QwSk
	bMCj9bBW9jp0Pwa1Rj246sGmW1lS8ojVxpL12fgLozA80Fs/8Ko6PGzaFI0s9SaCi4udIPh3dVw
	=
X-Google-Smtp-Source: AGHT+IF5I93HlWa1k48yzQp5rLpOSD1GUXFpYyMPj6ExHw4qGKj5DTFa2ZHs6as+JVJ0AxG3nCOZ+A==
X-Received: by 2002:a17:906:7b8f:b0:a46:50ca:b318 with SMTP id s15-20020a1709067b8f00b00a4650cab318mr11159149ejo.16.1710854531640;
        Tue, 19 Mar 2024 06:22:11 -0700 (PDT)
Message-ID: <95699d2c-7e2a-40db-875f-907990797317@suse.com>
Date: Tue, 19 Mar 2024 14:22:10 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Jan Beulich 
Subject: [PATCH v5] x86/PoD: tie together P2M update and increment of entry
 count
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper , Wei Liu ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 George Dunlap 
References: 
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

When not holding the PoD lock across the entire region covering P2M
update and stats update, the entry count - if to be incorrect at all -
should indicate too large a value in preference to a too small one, to
avoid functions bailing early when they find the count is zero. However,
instead of moving the increment ahead (and adjust back upon failure),
extend the PoD-locked region.

Fixes: 99af3cd40b6e ("x86/mm: Rework locking in the PoD layer")
Signed-off-by: Jan Beulich 
---
v5: Re-arrange conditionals to have just a single unlock.
v4: Shrink locked region a little again, where possible.
v3: Extend locked region instead. Add Fixes: tag.
v2: Add comments.

--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -1348,19 +1348,28 @@ mark_populate_on_demand(struct domain *d
         }
     }
 
+    /*
+     * P2M update and stats increment need to collectively be under PoD lock,
+     * to prevent code elsewhere observing PoD entry count being zero despite
+     * there actually still being PoD entries (created by the p2m_set_entry()
+     * invocation below).
+     */
+    pod_lock(p2m);
+
     /* Now, actually do the two-way mapping */
     rc = p2m_set_entry(p2m, gfn, INVALID_MFN, order,
                        p2m_populate_on_demand, p2m->default_access);
     if ( rc == 0 )
     {
-        pod_lock(p2m);
         p2m->pod.entry_count += 1UL << order;
         p2m->pod.entry_count -= pod_count;
         BUG_ON(p2m->pod.entry_count < 0);
-        pod_unlock(p2m);
+    }
+
+    pod_unlock(p2m);
 
+    if ( rc == 0 )
         ioreq_request_mapcache_invalidate(d);
-    }
     else if ( order )
     {
         /*


From xen-devel-bounces@lists.xenproject.org Tue Mar 19 13:26:50 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 13:26:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695376.1085068 (Exim 4.92)
	(envelope-from )
	id 1rmZUK-0007Zj-Rh; Tue, 19 Mar 2024 13:26:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695376.1085068; Tue, 19 Mar 2024 13:26:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmZUK-0007Zc-OA; Tue, 19 Mar 2024 13:26:44 +0000
Received: by outflank-mailman (input) for mailman id 695376;
 Tue, 19 Mar 2024 13:26:43 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmZUJ-0007Z8-EF
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 13:26:43 +0000
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com
 [2a00:1450:4864:20::630])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 533be6d1-e5f4-11ee-afdd-a90da7624cb6;
 Tue, 19 Mar 2024 14:26:42 +0100 (CET)
Received: by mail-ej1-x630.google.com with SMTP id
 a640c23a62f3a-a46ba938de0so329424766b.3
 for ; Tue, 19 Mar 2024 06:26:42 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 bw9-20020a170906c1c900b00a4668970f74sm6127780ejb.108.2024.03.19.06.26.41
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 19 Mar 2024 06:26:42 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 533be6d1-e5f4-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710854802; x=1711459602; darn=lists.xenproject.org;
        h=content-transfer-encoding:autocrypt:subject:from:cc:to
         :content-language:user-agent:mime-version:date:message-id:from:to:cc
         :subject:date:message-id:reply-to;
        bh=qy3d7UI70UHqP4Vsxkko+WvDNZPB+pMg565jLu/AARc=;
        b=VUPaCrgbUn7YJD/qtiCwlZ/xWNCvoVmm9V02m66Hnj1Y6VCeHTA4eLsUru54uXona2
         yRKmU1J2cBldPH9v/8kxuUfAqJipBkv742dayKX/zQEopAgSNm7UJzLmtAfuZfH+vVq9
         CTwgFazE4W3kqVE3zy4xy290U+NyII5Z+cxfDc6zgH1Boyci+VYt2FjeNwkdSbYppp1z
         3ZQqQ070cALs+WKlDiCrLd6NzvPX6IS81WwIc3EZtAiht6liWA6CeENNVvUCzlRWQY/S
         amjZpV9wB68VTRmObZZuWgEE1V9to48zu9evkda/0SGk4evqs5Mxiy4x9HOrCs4PcQJD
         YLPg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710854802; x=1711459602;
        h=content-transfer-encoding:autocrypt:subject:from:cc:to
         :content-language:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=qy3d7UI70UHqP4Vsxkko+WvDNZPB+pMg565jLu/AARc=;
        b=busmMZgT+qw57Nnzu0EKFPhX9cry+CGfQjZAw/Urr6Mmpw94SLarN+0cCL4pWCrRVu
         GVB1keonLwLblPdB+ZSxaCLD2V8htUofPGiw1DSVTHZYX7f0hIm3EOaHNbyPiPMXALmZ
         U8R/Do9jNV+oZGHLT135jGZZ9qtUFRbbOUDKdCIGD0WCUd1/dfL/1NGDSKrT4yYjyccJ
         xg2RObxBT2G5r83mwNr66clr6asOKiBsTJOh2onVjMkLG/oi3WPmrRz5GrKCdgdLjXQr
         Zr8HSRs7fTFI0f5Mwn3OYCQGj+nYgG3qjWIPFK+kzfq/noKDomH9yOxggCb/sx0pCJCt
         gqxA==
X-Gm-Message-State: AOJu0YycdlJA9uVkxgOofG+aswsVuDtuu01CBiUk9BRYnGx9sz9LsRJS
	m5pldHxnaZzb4mKBJ+c1lKWMWKbh+f/pTv9mEk/PFNuCPFtlwTWQRo3hGuDewv+x02FLYeUOEls
	=
X-Google-Smtp-Source: AGHT+IF1OTh5iqBwuxtfrZEgug4XurD13QaPTDgc/hc9BmwOfTN9W1GX1rY1fWcNNu4erS74SO8r1A==
X-Received: by 2002:a17:907:940c:b0:a46:ea52:3ed2 with SMTP id dk12-20020a170907940c00b00a46ea523ed2mr311685ejc.44.1710854802208;
        Tue, 19 Mar 2024 06:26:42 -0700 (PDT)
Message-ID: <227fbeda-1690-4158-8404-53b4236c0235@suse.com>
Date: Tue, 19 Mar 2024 14:26:41 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
From: Jan Beulich 
Subject: [PATCH] avoid UB in guest handle arithmetic
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

At least XENMEM_memory_exchange can have huge values passed in the
nr_extents and nr_exchanged fields. Adding such values to pointers can
overflow, resulting in UB. Cast respective pointers to "unsigned long"
while at the same time making the necessary multiplication explicit.
Remaining arithmetic is, despite there possibly being mathematical
overflow, okay as per the C99 spec: "A computation involving unsigned
operands can never overflow, because a result that cannot be represented
by the resulting unsigned integer type is reduced modulo the number that
is one greater than the largest value that can be represented by the
resulting type." The overflow that we need to guard against is checked
for in array_access_ok().

Note that in / down from array_access_ok() the address value is only
ever cast to "unsigned long" anyway, which is why in the invocation from
guest_handle_subrange_okay() the value doesn't need casting back to
pointer type.

In compat grant table code change two guest_handle_add_offset() to avoid
passing in negative offsets.

Since {,__}clear_guest_offset() need touching anyway, also deal with
another (latent) issue there: They were losing the handle type, i.e. the
size of the individual objects accessed. Luckily the few users we
presently have all pass char or uint8 handles.

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

--- a/xen/arch/x86/include/asm/guest_access.h
+++ b/xen/arch/x86/include/asm/guest_access.h
@@ -43,7 +43,7 @@
      array_access_ok((hnd).p, (nr), sizeof(*(hnd).p)))
 #define guest_handle_subrange_okay(hnd, first, last)    \
     (paging_mode_external(current->domain) ||           \
-     array_access_ok((hnd).p + (first),                 \
+     array_access_ok((unsigned long)(hnd).p + (first) * sizeof(*(hnd).p), \
                      (last)-(first)+1,                  \
                      sizeof(*(hnd).p)))
 
--- a/xen/common/compat/grant_table.c
+++ b/xen/common/compat/grant_table.c
@@ -232,7 +232,7 @@ int (compat_grant_table_op)(
                 cnt_uop = guest_handle_cast(xfer, void);
                 while ( n-- )
                 {
-                    guest_handle_add_offset(xfer, -1);
+                    guest_handle_subtract_offset(xfer, 1);
                     if ( __copy_field_to_guest(xfer, nat.xfer + n, status) )
                         rc = -EFAULT;
                 }
@@ -277,7 +277,7 @@ int (compat_grant_table_op)(
                 cnt_uop = guest_handle_cast(copy, void);
                 while ( n-- )
                 {
-                    guest_handle_add_offset(copy, -1);
+                    guest_handle_subtract_offset(copy, 1);
                     if ( __copy_field_to_guest(copy, nat.copy + n, status) )
                         rc = -EFAULT;
                 }
--- a/xen/include/xen/guest_access.h
+++ b/xen/include/xen/guest_access.h
@@ -15,8 +15,10 @@
 #define guest_handle_is_null(hnd)        ((hnd).p == NULL)
 
 /* Offset the given guest handle into the array it refers to. */
-#define guest_handle_add_offset(hnd, nr) ((hnd).p += (nr))
-#define guest_handle_subtract_offset(hnd, nr) ((hnd).p -= (nr))
+#define guest_handle_add_offset(hnd, nr) ((hnd).p = \
+    (typeof((hnd).p))((unsigned long)(hnd).p + (nr) * sizeof(*(hnd).p)))
+#define guest_handle_subtract_offset(hnd, nr) ((hnd).p = \
+    (typeof((hnd).p))((unsigned long)(hnd).p - (nr) * sizeof(*(hnd).p)))
 
 /*
  * Cast a guest handle (either XEN_GUEST_HANDLE or XEN_GUEST_HANDLE_PARAM)
@@ -59,20 +61,22 @@
  */
 #define copy_to_guest_offset(hnd, off, ptr, nr) ({      \
     const typeof(*(ptr)) *_s = (ptr);                   \
-    char (*_d)[sizeof(*_s)] = (void *)(hnd).p;          \
+    unsigned long d_ = (unsigned long)(hnd).p;          \
     /* Check that the handle is not for a const type */ \
     void *__maybe_unused _t = (hnd).p;                  \
     (void)((hnd).p == _s);                              \
-    raw_copy_to_guest(_d+(off), _s, sizeof(*_s)*(nr));  \
+    raw_copy_to_guest((void *)(d_ + (off) * sizeof(*_s)), \
+                      _s, (nr) * sizeof(*_s));          \
 })
 
 /*
  * Clear an array of objects in guest context via a guest handle,
  * specifying an offset into the guest array.
  */
-#define clear_guest_offset(hnd, off, nr) ({    \
-    void *_d = (hnd).p;                        \
-    raw_clear_guest(_d+(off), nr);             \
+#define clear_guest_offset(hnd, off, nr) ({             \
+    unsigned long d_ = (unsigned long)(hnd).p;          \
+    raw_clear_guest((void *)(d_ + (off) * sizeof(*(hnd).p)), \
+                    (nr) * sizeof(*(hnd).p));           \
 })
 
 /*
@@ -80,9 +84,11 @@
  * specifying an offset into the guest array.
  */
 #define copy_from_guest_offset(ptr, hnd, off, nr) ({    \
-    const typeof(*(ptr)) *_s = (hnd).p;                 \
+    unsigned long s_ = (unsigned long)(hnd).p;          \
     typeof(*(ptr)) *_d = (ptr);                         \
-    raw_copy_from_guest(_d, _s+(off), sizeof(*_d)*(nr));\
+    raw_copy_from_guest(_d,                             \
+                        (const void *)(s_ + (off) * sizeof(*_d)), \
+                        (nr) * sizeof(*_d));            \
 })
 
 /* Copy sub-field of a structure to guest context via a guest handle. */
@@ -117,22 +123,26 @@
 
 #define __copy_to_guest_offset(hnd, off, ptr, nr) ({        \
     const typeof(*(ptr)) *_s = (ptr);                       \
-    char (*_d)[sizeof(*_s)] = (void *)(hnd).p;              \
+    unsigned long d_ = (unsigned long)(hnd).p;              \
     /* Check that the handle is not for a const type */     \
     void *__maybe_unused _t = (hnd).p;                      \
     (void)((hnd).p == _s);                                  \
-    __raw_copy_to_guest(_d + (off), _s, sizeof(*_s) * (nr));\
+    __raw_copy_to_guest((void *)(d_ + (off) * sizeof(*_s)), \
+                      _s, (nr) * sizeof(*_s));              \
 })
 
-#define __clear_guest_offset(hnd, off, nr) ({    \
-    void *_d = (hnd).p;                          \
-    __raw_clear_guest(_d + (off), nr);           \
+#define __clear_guest_offset(hnd, off, nr) ({               \
+    unsigned long d_ = (unsigned long)(hnd).p;              \
+    __raw_clear_guest((void *)(d_ + (off) * sizeof(*(hnd).p)), \
+                      (nr) * sizeof(*(hnd).p));             \
 })
 
 #define __copy_from_guest_offset(ptr, hnd, off, nr) ({          \
-    const typeof(*(ptr)) *_s = (hnd).p;                         \
+    unsigned long s_ = (unsigned long)(hnd).p;                  \
     typeof(*(ptr)) *_d = (ptr);                                 \
-    __raw_copy_from_guest(_d, _s + (off), sizeof (*_d) * (nr)); \
+    __raw_copy_from_guest(_d,                                   \
+                          (const void *)(s_ + (off) * sizeof(*_d)), \
+                          (nr) * sizeof(*_d));                  \
 })
 
 #define __copy_field_to_guest(hnd, ptr, field) ({       \


From xen-devel-bounces@lists.xenproject.org Tue Mar 19 13:28:17 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 13:28:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695378.1085077 (Exim 4.92)
	(envelope-from )
	id 1rmZVo-00087C-59; Tue, 19 Mar 2024 13:28:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695378.1085077; Tue, 19 Mar 2024 13:28:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmZVo-000875-2R; Tue, 19 Mar 2024 13:28:16 +0000
Received: by outflank-mailman (input) for mailman id 695378;
 Tue, 19 Mar 2024 13:28:15 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmZVn-00086x-AU
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 13:28:15 +0000
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com
 [2a00:1450:4864:20::629])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 893e7e7b-e5f4-11ee-a1ee-f123f15fe8a2;
 Tue, 19 Mar 2024 14:28:13 +0100 (CET)
Received: by mail-ej1-x629.google.com with SMTP id
 a640c23a62f3a-a467d8efe78so591257966b.3
 for ; Tue, 19 Mar 2024 06:28:13 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 bw9-20020a170906c1c900b00a4668970f74sm6127780ejb.108.2024.03.19.06.28.12
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 19 Mar 2024 06:28:12 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 893e7e7b-e5f4-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710854893; x=1711459693; darn=lists.xenproject.org;
        h=content-transfer-encoding:autocrypt:subject:from:cc:to
         :content-language:user-agent:mime-version:date:message-id:from:to:cc
         :subject:date:message-id:reply-to;
        bh=4kCUKBUd/0z/5BlQq1KKRdv2GUHOSaXTPvWFHMRtn9I=;
        b=FPBZCg4fIj5nOi4z0dVv0Cp6qQUKH9u6G16vdWgcTiI9jpSA9JeMIyKDRcZ5P0X4oA
         3/n99iBGdr2+8kVALBOVcDqNZAvfh4zCbVmq7vfR2sVqUirBmGCQnUo1to2c/YtRvwF4
         54RUvMaRYpKHiDB373O4BBiDpqRbtHchSD0OgYco1rgI/SERA1fKpkYK87ldH8vtNYM5
         anFJ0e8mkF6dVJJRaDNLeMuiSZ3pyeSy88E2ZIniX0Mb4OD9xe7ii6EJOeK/Fcwu5otG
         6cv7t5aGERpqHUaf0QFgDij6bKQkc2BN3fJ50UX5DRP1wyg0ZqU7G5+GnMn//fy6D0xL
         6T4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710854893; x=1711459693;
        h=content-transfer-encoding:autocrypt:subject:from:cc:to
         :content-language:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=4kCUKBUd/0z/5BlQq1KKRdv2GUHOSaXTPvWFHMRtn9I=;
        b=PpAO2ZAKs63t0jihT2S0arenqEV9x90hXtFB2oE0tXXC7vSx90our1wVukLPcnEuwf
         Ivx6O9fibNQJSPHykPlwJ66dOvgVnJps/SCy/ZIWWlF8mVqiu+uTj8pV2VhCFjZALrd2
         tY9TdjU5jGyC0FbuFJIlBSGrYcw2z8tO2uy/HDuC5w4tJBc3qYmdoIAxvqPBFfN3GUYo
         BE/wHR9gTB0gK7g95LNIJ77rlzL5BL1WCJ6uwrKhPXcx+s2gSuFmg4NSiSQaj5R/oc3L
         J+58hoNPNEJxlYOrQIFep9ASKUefAtbGXFqAytrFFgmt8JMcbDKeTN3JirtvGWeHAkC2
         MIcw==
X-Gm-Message-State: AOJu0Yy63Q5t9Xloq5mILjLOpKKewO/0R5lQ+SaIgmNenm0KG04xkx95
	QBmGTL2UD4neccru3xD02GzM7uhdrUgxPCGvmhyFaQabxZ1fTvIQrHnUCdnN1rumSouBn5U9Zr4
	=
X-Google-Smtp-Source: AGHT+IEKnsWavcdNmR9AUft1uEnvaVZWVHc0F+GYZCB0NWkPeSViP2P0cUMy448ihJ2hYkyGXYFu+Q==
X-Received: by 2002:a17:906:ddb:b0:a46:4d16:439b with SMTP id p27-20020a1709060ddb00b00a464d16439bmr1972392eji.43.1710854892808;
        Tue, 19 Mar 2024 06:28:12 -0700 (PDT)
Message-ID: <5eb98372-2992-4a93-846c-4e325c41af98@suse.com>
Date: Tue, 19 Mar 2024 14:28:12 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Nicola Vetrini 
From: Jan Beulich 
Subject: [PATCH] AMD/IOMMU: drop remaining guest-IOMMU bits too
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

With a02174c6c885 ("amd/iommu: clean up unused guest iommu related
functions") having removed the sole place where d->g_iommu would be set
to non-NULL, guest_iommu_add_ppr_log() will unconditionally bail the
latest from its 2nd if(). With it dropped, all other stuff in the file
is unused, too. Delete iommu_guest.c altogether.

Further delete struct guest{_buffer,_dev_table,_iommu{,_msi}} as well as
struct mmio_reg for being unused with the unused g_iommu also dropped
from struct arch_iommu.

Signed-off-by: Jan Beulich 
---
I wasn't sure how far to further go with removing the body of
parse_ppr_log_entry(), or perhaps even the entire function, and then
further up to all PPR logging code. Hence why for now I've merely
commented out the function call into the file being deleted (which of
course Misra isn't going to like). Thoughts / suggestions?

I further wonder whether set_iommu_guest_translation_control() should
have been invoked independent of guest-IOMMU actually being enabled. IOW
that may want purging, too. Along these lines iommuv2_enabled may also
want dropping, for not having any consumer left. Much like has_viommu()
and then also {XEN_,}X86_EMU_IOMMU, i.e. going as far as affecting the
public interface.

--- a/xen/arch/x86/include/asm/iommu.h
+++ b/xen/arch/x86/include/asm/iommu.h
@@ -52,7 +52,6 @@ struct arch_iommu
         struct {
             unsigned int paging_mode;
             struct page_info *root_table;
-            struct guest_iommu *g_iommu;
         } amd;
     };
 };
--- a/xen/drivers/passthrough/amd/Makefile
+++ b/xen/drivers/passthrough/amd/Makefile
@@ -5,4 +5,3 @@ obj-y += pci_amd_iommu.o
 obj-bin-y += iommu_acpi.init.o
 obj-y += iommu_intr.o
 obj-y += iommu_cmd.o
-obj-$(CONFIG_HVM) += iommu_guest.o
--- a/xen/drivers/passthrough/amd/iommu.h
+++ b/xen/drivers/passthrough/amd/iommu.h
@@ -145,57 +145,6 @@ int iterate_ivrs_entries(int (*handler)(
                                         struct ivrs_mappings *map,
                                         uint16_t bdf));
 
-/* iommu tables in guest space */
-struct mmio_reg {
-    uint32_t    lo;
-    uint32_t    hi;
-};
-
-struct guest_dev_table {
-    struct mmio_reg         reg_base;
-    uint32_t                size;
-};
-
-struct guest_buffer {
-    struct mmio_reg         reg_base;
-    struct mmio_reg         reg_tail;
-    struct mmio_reg         reg_head;
-    uint32_t                size;
-};
-
-struct guest_iommu_msi {
-    uint8_t                 vector;
-    uint8_t                 dest;
-    uint8_t                 dest_mode;
-    uint8_t                 delivery_mode;
-    uint8_t                 trig_mode;
-};
-
-/* virtual IOMMU structure */
-struct guest_iommu {
-
-    struct domain          *domain;
-    spinlock_t              lock;
-    bool                    enabled;
-
-    struct guest_dev_table  dev_table;
-    struct guest_buffer     cmd_buffer;
-    struct guest_buffer     event_log;
-    struct guest_buffer     ppr_log;
-
-    struct tasklet          cmd_buffer_tasklet;
-
-    uint64_t                mmio_base;             /* MMIO base address */
-
-    /* MMIO regs */
-    union amd_iommu_control reg_ctrl;              /* MMIO offset 0018h */
-    struct mmio_reg         reg_status;            /* MMIO offset 2020h */
-    union amd_iommu_ext_features reg_ext_feature;  /* MMIO offset 0030h */
-
-    /* guest interrupt settings */
-    struct guest_iommu_msi  msi;
-};
-
 extern bool iommuv2_enabled;
 
 struct acpi_ivrs_hardware;
@@ -344,13 +293,6 @@ void cf_check amd_iommu_resume(void);
 int __must_check cf_check amd_iommu_suspend(void);
 void cf_check amd_iommu_crash_shutdown(void);
 
-/* guest iommu support */
-#ifdef CONFIG_HVM
-void guest_iommu_add_ppr_log(struct domain *d, uint32_t entry[]);
-#else
-static inline void guest_iommu_add_ppr_log(struct domain *d, uint32_t entry[]) {}
-#endif
-
 static inline u32 get_field_from_reg_u32(u32 reg_value, u32 mask, u32 shift)
 {
     u32 field;
--- a/xen/drivers/passthrough/amd/iommu_guest.c
+++ /dev/null
@@ -1,120 +0,0 @@
-/*
- * Copyright (C) 2011 Advanced Micro Devices, Inc.
- * Author: Wei Wang 
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; If not, see .
- */
-
-#include 
-
-#include "iommu.h"
-
-#define reg_to_u64(reg) (((uint64_t)reg.hi << 32) | reg.lo )
-
-static uint16_t get_guest_bdf(struct domain *d, uint16_t machine_bdf)
-{
-    return machine_bdf;
-}
-
-static inline struct guest_iommu *domain_iommu(struct domain *d)
-{
-    return dom_iommu(d)->arch.amd.g_iommu;
-}
-
-static unsigned long get_gfn_from_base_reg(uint64_t base_raw)
-{
-    base_raw &= PADDR_MASK;
-    ASSERT ( base_raw != 0 );
-    return base_raw >> PAGE_SHIFT;
-}
-
-static void guest_iommu_deliver_msi(struct domain *d)
-{
-    uint8_t vector, dest, dest_mode, delivery_mode, trig_mode;
-    struct guest_iommu *iommu = domain_iommu(d);
-
-    vector = iommu->msi.vector;
-    dest = iommu->msi.dest;
-    dest_mode = iommu->msi.dest_mode;
-    delivery_mode = iommu->msi.delivery_mode;
-    trig_mode = iommu->msi.trig_mode;
-
-    vmsi_deliver(d, vector, dest, dest_mode, delivery_mode, trig_mode);
-}
-
-static unsigned long guest_iommu_get_table_mfn(struct domain *d,
-                                               uint64_t base_raw,
-                                               unsigned int pos)
-{
-    unsigned long idx, gfn, mfn;
-    p2m_type_t p2mt;
-
-    gfn = get_gfn_from_base_reg(base_raw);
-    idx = pos >> PAGE_SHIFT;
-
-    mfn = mfn_x(get_gfn(d, gfn + idx, &p2mt));
-    put_gfn(d, gfn);
-
-    return mfn;
-}
-
-void guest_iommu_add_ppr_log(struct domain *d, u32 entry[])
-{
-    uint16_t gdev_id;
-    unsigned long mfn, tail, head;
-    ppr_entry_t *log;
-    struct guest_iommu *iommu;
-
-    if ( !is_hvm_domain(d) )
-        return;
-
-    iommu = domain_iommu(d);
-    if ( !iommu )
-        return;
-
-    tail = iommu->ppr_log.reg_tail.lo;
-    head = iommu->ppr_log.reg_head.lo;
-
-    if ( tail >= iommu->ppr_log.size || head >= iommu->ppr_log.size )
-    {
-        AMD_IOMMU_DEBUG("Error: guest iommu ppr log overflows\n");
-        iommu->enabled = 0;
-        return;
-    }
-
-    mfn = guest_iommu_get_table_mfn(d, reg_to_u64(iommu->ppr_log.reg_base),
-                                    tail);
-    ASSERT(mfn_valid(_mfn(mfn)));
-
-    log = map_domain_page(_mfn(mfn)) + (tail & ~PAGE_MASK);
-
-    /* Convert physical device id back into virtual device id */
-    gdev_id = get_guest_bdf(d, iommu_get_devid_from_cmd(entry[0]));
-    iommu_set_devid_to_cmd(&entry[0], gdev_id);
-
-    memcpy(log, entry, sizeof(ppr_entry_t));
-
-    /* Now shift ppr log tail pointer */
-    tail += sizeof(ppr_entry_t);
-    if ( tail >= iommu->ppr_log.size )
-    {
-        tail = 0;
-        iommu->reg_status.lo |= IOMMU_STATUS_PPR_LOG_OVERFLOW;
-    }
-
-    iommu->ppr_log.reg_tail.lo = tail;
-    unmap_domain_page(log);
-
-    guest_iommu_deliver_msi(d);
-}
--- a/xen/drivers/passthrough/amd/iommu_init.c
+++ b/xen/drivers/passthrough/amd/iommu_init.c
@@ -646,7 +646,7 @@ static void cf_check parse_ppr_log_entry
     pcidevs_unlock();
 
     if ( pdev )
-        guest_iommu_add_ppr_log(pdev->domain, entry);
+        /* guest_iommu_add_ppr_log(pdev->domain, entry) */;
 }
 
 static void iommu_check_ppr_log(struct amd_iommu *iommu)


From xen-devel-bounces@lists.xenproject.org Tue Mar 19 13:30:50 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 13:30:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695381.1085088 (Exim 4.92)
	(envelope-from )
	id 1rmZYG-0001KN-NE; Tue, 19 Mar 2024 13:30:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695381.1085088; Tue, 19 Mar 2024 13:30:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmZYG-0001KG-K7; Tue, 19 Mar 2024 13:30:48 +0000
Received: by outflank-mailman (input) for mailman id 695381;
 Tue, 19 Mar 2024 13:30:47 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmZYF-0001KA-JU
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 13:30:47 +0000
Received: from EUR03-DBA-obe.outbound.protection.outlook.com
 (mail-dbaeur03on20601.outbound.protection.outlook.com
 [2a01:111:f403:260d::601])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e3f2c158-e5f4-11ee-a1ee-f123f15fe8a2;
 Tue, 19 Mar 2024 14:30:45 +0100 (CET)
Received: from DU2PR04CA0072.eurprd04.prod.outlook.com (2603:10a6:10:232::17)
 by DBBPR08MB5932.eurprd08.prod.outlook.com (2603:10a6:10:207::21)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.21; Tue, 19 Mar
 2024 13:30:41 +0000
Received: from DU6PEPF0000A7DF.eurprd02.prod.outlook.com
 (2603:10a6:10:232:cafe::df) by DU2PR04CA0072.outlook.office365.com
 (2603:10a6:10:232::17) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.27 via Frontend
 Transport; Tue, 19 Mar 2024 13:30:41 +0000
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by
 DU6PEPF0000A7DF.mail.protection.outlook.com (10.167.8.36) with
 Microsoft SMTP
 Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.7409.10 via Frontend Transport; Tue, 19 Mar 2024 13:30:41 +0000
Received: ("Tessian outbound e26069fc76b9:v300");
 Tue, 19 Mar 2024 13:30:41 +0000
Received: from 61ca9ac08ac0.2
 by 64aa7808-outbound-1.mta.getcheckrecipient.com id
 76783482-3899-41BF-951D-964F1F1557AE.1; 
 Tue, 19 Mar 2024 13:30:30 +0000
Received: from EUR03-AM7-obe.outbound.protection.outlook.com
 by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 61ca9ac08ac0.2
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384);
 Tue, 19 Mar 2024 13:30:30 +0000
Received: from AM6PR08MB3749.eurprd08.prod.outlook.com (2603:10a6:20b:8f::22)
 by DU0PR08MB9653.eurprd08.prod.outlook.com (2603:10a6:10:449::20)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.27; Tue, 19 Mar
 2024 13:30:26 +0000
Received: from AM6PR08MB3749.eurprd08.prod.outlook.com
 ([fe80::13e4:dd98:2513:db0]) by AM6PR08MB3749.eurprd08.prod.outlook.com
 ([fe80::13e4:dd98:2513:db0%7]) with mapi id 15.20.7386.023; Tue, 19 Mar 2024
 13:30:23 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e3f2c158-e5f4-11ee-a1ee-f123f15fe8a2
ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass;
 b=U94yqitzZC2l8sbz41cgdA85r6zP6xzRPMRllIwXhip7qbEz+0y4q2sSzYsAPoahkFNEC69tesXTZPCEcJdZO42p8XDbbsUEyVTINPsctGNoI0StkRYtQFlQJeRwBYOTE9/VTotax8Udt157GAtC+6kbg88kp6+ro3ZA6u0GSnmeZ+T0xurwUyr1MIO7gQBQfMltkuSCf1O3mkH+df/PpRXvZw8GvikYoAXU7EUdLZ5iHP1DBwGp02HMwEY5OS5I33IroqorMERrptWj7jgDn2um9Gz7ZxRR/khjnMEcEJ4qkyFi/VpXkb+aayX1a1kYf1eizR6T/RWsMz0J+zwRfw==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=oE4p0YzeWWuQDURuNHJmYDSPA+fd7dpTX3r/gdvxMKE=;
 b=nlux7D3PWykcZgV02WJIGKjV9qChHg37S7xjrzPudX5F3vpWNrh4w3gc0srfeDtZcbbgYgE7e8NwOxeRCQTbZIuQynUBily7vqfmBDRhDBEdW/HdQY+Mk/n7IEFKo92LUdBDDl1hzikr+Zky2e4VHfgdhnwTQJiopVP8W1erP9Cw6XBx7zm9bD7ZXkly5TXkUi5qgBKqdAdtHwRDyoyhfIRQMnIwU6GOiyrZ/dEsq0PhWDJHU3Wp8fXwTv4jiDlCP/tekQU59uD1/khTn5qfjsZQjA/K6YctJcKXCFcnfzvNd7nGlRLhERh3ibOfznEmJ36W1WU/Qp5de6QukG7b+g==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 63.35.35.123) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=arm.com;
 dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com;
 dkim=pass (signature was verified) header.d=armh.onmicrosoft.com; arc=pass (0
 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com]
 dmarc=[1,1,header.from=arm.com])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com;
 s=selector2-armh-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=oE4p0YzeWWuQDURuNHJmYDSPA+fd7dpTX3r/gdvxMKE=;
 b=AgjAgCioNMTgVLeVdkENir9n9PLRxkv0RTXmRToUF/sEtrVrWYlMna/60goiBAZggZfjitiHpSMnvQ7d/nWnYj39unuvluV9J4b9TJ8VK64LpN5FVYEOiRQb59GDKIheEZNNUFEU0XBocvENiTIrI1eKwmVcgRDoVZS3z94bQsc=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=armh.onmicrosoft.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 63.35.35.123 as permitted sender) receiver=protection.outlook.com;
 client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
 pr=C
X-CheckRecipientChecked: true
X-CR-MTA-CID: 7cb4c8c3ed7a5077
X-CR-MTA-TID: 64aa7808
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=ZaEbn72pNn1Jhp+B6rqHo7n/09ZiWR6UIOJ30LrXtJyW0CzV/srp/QVfcnXPy3lZUouovKWqsVGQYTnbDzvVQF6elizOF/+A1q9cHH8bpo+eLEyeK/irkt1dGyFuuzLXJ1GidpsuiuAib7Lq+jsWQGKtyc+eNlkcSGWnB0YfFtrmfu9IwurI5R9JOB2ifZgD3MlaIZVXkp+Jh67fzF6abJEh8Csxv8eF9Afl2zkCZqivC6Wwa0gBvo24n02Sb9soACEPxiBSQwPFAPI1Uh9XsMSLHyRR1IRi7Jnc5KeCM0ROOK+zkSLRkmbmn1NyQGJ6Wgjvja6YWNFPjFBFotDtbw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=oE4p0YzeWWuQDURuNHJmYDSPA+fd7dpTX3r/gdvxMKE=;
 b=Ngi/yRFkszOeEjdFp+/oLdETdSzsIA7DiL/t4t2t8F+T8Z9yMnLQsXBR2xpsMfBSAAwr5rr/F+/BPmFRJX/dLsZL9uJUUim4rcpZQyRxmOYr8upLsq2MkwkKRxOqqqhNoi0rE3uA2tZCRG77QMlfaYDSRqabor7Yd0LvFp3804/ZsaMvMeJ+aFev0sa5n0CbOEsx0ihcAGeO37Zwh7+hg+Thv6SGPc2VZ+yG+WuyGm8kI0+aUdMu5St6Gk9vBFYO5Cvqk01OvhZBDPG9h/rbl2+cEp/1a76gZT+nHFUchiPcz+OtFbbp1ztDTjHL3ZnB7lgklrBdZR4keiynEQXWlQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass
 header.d=arm.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com;
 s=selector2-armh-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=oE4p0YzeWWuQDURuNHJmYDSPA+fd7dpTX3r/gdvxMKE=;
 b=AgjAgCioNMTgVLeVdkENir9n9PLRxkv0RTXmRToUF/sEtrVrWYlMna/60goiBAZggZfjitiHpSMnvQ7d/nWnYj39unuvluV9J4b9TJ8VK64LpN5FVYEOiRQb59GDKIheEZNNUFEU0XBocvENiTIrI1eKwmVcgRDoVZS3z94bQsc=
From: Luca Fancellu 
To: Michal Orzel 
CC: Xen-devel , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Volodymyr Babchuk 
Subject: Re: [PATCH 03/11] xen/arm: Introduce a generic way to access memory
 bank structures
Thread-Topic: [PATCH 03/11] xen/arm: Introduce a generic way to access memory
 bank structures
Thread-Index: AQHadH3mFY6wZkuH8kG5zjUlnZxCHbE/FIwAgAAFnIA=
Date: Tue, 19 Mar 2024 13:30:23 +0000
Message-ID: <5ED2A5C8-3B82-4E74-9CE6-46BFBC117F23@arm.com>
References: <20240312130331.78418-1-luca.fancellu@arm.com>
 <20240312130331.78418-4-luca.fancellu@arm.com>
 <73dbf297-31ed-4cf1-b081-c6f82c234de8@amd.com>
In-Reply-To: <73dbf297-31ed-4cf1-b081-c6f82c234de8@amd.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3774.400.31)
x-ms-traffictypediagnostic:
	AM6PR08MB3749:EE_|DU0PR08MB9653:EE_|DU6PEPF0000A7DF:EE_|DBBPR08MB5932:EE_
x-checkrecipientrouted: true
nodisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted: BCL:0;
X-Microsoft-Antispam-Message-Info-Original:
 /ciwN+zMFodSpepd3O0w3lSK1jN1Rsei8ygzDdR0oXNCgNy+dE0kKqi9r1fsAlQbMxJ91DfYEgqAtjUb8HzdsJo+x4JZtpJlVV4qTArKqYggGitBINLo+t1Tb0/npY3DZJEDMLWe7l/Us+Nwt3mX6rvxCaNfi4q+akWNS7anOzcOkjQ/KHAX7k+RJDDG4J7Bcp/tSFr0x2MUgPOfYJ44Gjp1gWq3IIGwODClYA5eRjd9JpqbFxkJJfEvPzQB++IANbDzhYTCRju4QpHAPbV+3dbdm3f17WsGv7CitOqMDX5WrZUYo833ZL6Qp7RVA/CWpxioAmk3brTNNnu1smpNAhcsWoiZ2vyoeCGGoPEyBior1pQ9Tp9I7Nb6F4MgP9taRwb3G6wd6SwkKSdfdq4hy843vUjKXXDjTBskuohgOZdliROdUscskhrp3tegq9Bk70Pr8XFQ94X+RpTxxvluThUHtZUKNu6dslA20dJ0pAvgwUeHJu3R1xYP4qoDY5xRgGUi2jinMt3lj7I7z66WuGX9s41mVCVmNs8bXtomu2/qhPGoWTYbPxBia2134CHbEt23wxpQ/InsWwcpLZuosQGBjy/g2uD01QF1r6MXTivewk4Uh7NXcb0b091d0gbbN3Ps3kP/9iu84MuuPe/oxgy/n0fK7UWPxWW8ko9dMDk=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM6PR08MB3749.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(366007)(1800799015)(376005);DIR:OUT;SFP:1102;
Content-Type: text/plain; charset="utf-8"
Content-ID: <92C2B57C671C6040867175F8D99596D1@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR08MB9653
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 DU6PEPF0000A7DF.eurprd02.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: d8022e06-10a7-4524-0a16-08dc4818c5be
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	AoQcTDcJQI3rr9s9va3f+yOd7uYwgvzXXco1HA3SpUvD1ELdiXTQ4oCIZVHb7JQ0KgiNxEuO50RV9/+5bNNp3H2SQMH+NRxlP4JoOhANr+fwGhnLgqlpeVaB6g5DEEXPdvp+NKSA/u31h16OWyJrTuDRtcFJHRK1fWc2EEbB6ilZTx0wH8lS2r3xpYWkuFQc87xyYgJL60nShlznEBa33wnmtbtM87V6qr04tkrrnLoECQBpKzMAAnj5kZQlJaJ2gC+/zBQUzrgvMlbbmOrbdEgUNg/UxXO+LB7l7VuIJfoctacxusugOLh3Tdb9gUPIOT1tNjTMIbWME4Xs1U3X2XWXEQzG2BpPlQ2cLpDQuJlktrQhZDymhDJb4jOSPZK5mSOXXEOkiGSNxUZZL4abQK4Tq7wL5WNnTseDTZZF65mrcFqm/mY0GiFH5cRbh4/JUpO9A7CAcGx4oAICO7i6u5Pre2JUp/22UsD4ZMnDTZ8dsDGpVgeb+HNMrcl0KYwGxLm1FOlM6Ei8MZmBmPzjp5FSfnxrZ0w4Uk9VzGbhB2zntEBNhrtpcAPaZsDprFEIHO+RbvYl2IGmKVnkJ4HTx8zbBuNFV3q6PxybX58dso1avFjk/nPhAku81+oqRoTquTh/txholoZnEUXA2nWew3s2VyB6uw1moIlrQVvdLHEwnrXvYJfIZyYBZECN21rYgsKKrDiIPBdejFVb4sKLAlmTsyKCpr4bwZIprXnLE066ocIDQT4gPdbG6EGACntB
X-Forefront-Antispam-Report:
	CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com;CAT:NONE;SFS:(13230031)(82310400014)(1800799015)(376005)(36860700004);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Mar 2024 13:30:41.3748
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: d8022e06-10a7-4524-0a16-08dc4818c5be
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DU6PEPF0000A7DF.eurprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR08MB5932

DQoNCj4gT24gMTkgTWFyIDIwMjQsIGF0IDEzOjEwLCBNaWNoYWwgT3J6ZWwgPG1pY2hhbC5vcnpl
bEBhbWQuY29tPiB3cm90ZToNCj4gDQo+IEhpIEx1Y2EsDQoNCkhpIE1pY2hhbCwNCg0KVGhhbmtz
IGZvciBoYXZpbmcgYSBsb29rDQoNCj4gDQo+IE9uIDEyLzAzLzIwMjQgMTQ6MDMsIEx1Y2EgRmFu
Y2VsbHUgd3JvdGU6DQo+PiANCj4+IA0KPj4gQ3VycmVudGx5IHRoZSAnc3R1Y3QgbWVtaW5mbycg
aXMgZGVmaW5pbmcgYSBzdGF0aWMgZGVmaW5lZCBhcnJheSBvZg0KPj4gJ3N0cnVjdCBtZW1iYW5r
JyBvZiBOUl9NRU1fQkFOS1MgZWxlbWVudHMsIHNvbWUgZmVhdHVyZSBsaWtlDQo+PiBzaGFyZWQg
bWVtb3J5IGRvbid0IHJlcXVpcmUgc3VjaCBhbW91bnQgb2YgbWVtb3J5IGFsbG9jYXRpb24gYnV0
DQo+PiBtaWdodCB3YW50IHRvIHJldXNlIGV4aXN0aW5nIGNvZGUgdG8gbWFuaXB1bGF0ZSB0aGlz
IGtpbmQgb2YNCj4+IHN0cnVjdHVyZSB0aGF0IGlzIGp1c3QgYXMgJ3N0cnVjdCBtZW1pbmZvJyBi
dXQgbGVzcyBidWxreS4NCj4+IA0KPj4gRm9yIHRoaXMgcmVhc29uIGludHJvZHVjZSBhIGdlbmVy
aWMgd2F5IHRvIGFjY2VzcyB0aGlzIGtpbmQgb2YNCj4+IHN0cnVjdHVyZSB1c2luZyBhIG5ldyBz
dHVjdHVyZSAnc3RydWN0IG1lbWJhbmtzJywgd2hpY2ggaW1wbGVtZW50cw0KPiBzL3N0dWN0dXJl
L3N0cnVjdHVyZQ0KPiANCj4+IGFsbCB0aGUgZmllbGRzIG5lZWRlZCBieSBhIHN0cnVjdHVyZSBy
ZWxhdGVkIHRvIG1lbW9yeSBiYW5rcw0KPj4gd2l0aG91dCB0aGUgbmVlZCB0byBzcGVjaWZ5IGF0
IGJ1aWxkIHRpbWUgdGhlIHNpemUgb2YgdGhlDQo+PiAnc3RydWN0IG1lbWJhbmsnIGFycmF5Lg0K
PiBNaWdodCBiZSBiZW5lZmljaWFsIGhlcmUgdG8gbWVudGlvbiB0aGUgdXNlIG9mIEZBTS4NCj4g
DQo+PiANCj4+IE1vZGlmeSAnc3RydWN0IG1lbWluZm8nIHRvIGltcGxlbWVudCB0aGUgZmllbGQg
cmVsYXRlZCB0byB0aGUgbmV3DQo+PiBpbnRyb2R1Y2VkIHN0cnVjdHVyZSwgZ2l2ZW4gdGhlIGNo
YW5nZSBhbGwgdXNhZ2Ugb2YgdGhpcyBzdHJ1Y3R1cmUNCj4+IGFyZSB1cGRhdGVkIGluIHRoaXMg
d2F5Og0KPj4gLSBjb2RlIGFjY2Vzc2luZyBib290aW5mby57bWVtLHJlc2VydmVkX21lbSxhY3Bp
fSBmaWVsZCBub3cgdXNlcw0KPj4gICAzIG5ldyBpbnRyb2R1Y2VkIHN0YXRpYyBpbmxpbmUgaGVs
cGVycyB0byBhY2Nlc3MgdGhlIG5ldyBmaWVsZA0KPj4gICBvZiAnc3RydWN0IG1lbWluZm8nIG5h
bWVkICdjb21tb24nLg0KPj4gLSBjb2RlIGFjY2Vzc2luZyAnc3RydWN0IGtlcm5lbF9pbmZvICon
IG1lbWJlciAnbWVtJyBub3cgdXNlIHRoZQ0KPj4gICBuZXcgaW50cm9kdWNlZCBtYWNybyAna2Vy
bmVsX2luZm9fZ2V0X21lbSguLi4pJyB0byBhY2Nlc3MgdGhlDQo+PiAgIG5ldyBmaWVsZCBvZiAn
c3RydWN0IG1lbWluZm8nIG5hbWVkICdjb21tb24nLg0KPj4gDQo+PiBDb25zdGlmeSBwb2ludGVy
cyB3aGVyZSBuZWVkZWQuDQo+PiANCj4+IFN1Z2dlc3RlZC1ieTogSnVsaWVuIEdyYWxsIDxqdWxp
ZW5AeGVuLm9yZz4NCj4+IFNpZ25lZC1vZmYtYnk6IEx1Y2EgRmFuY2VsbHUgPGx1Y2EuZmFuY2Vs
bHVAYXJtLmNvbT4NCj4+IC0tLQ0KPj4geGVuL2FyY2gvYXJtL2FjcGkvZG9tYWluX2J1aWxkLmMg
ICAgICAgIHwgICA2ICstDQo+PiB4ZW4vYXJjaC9hcm0vYXJtMzIvbW11L21tLmMgICAgICAgICAg
ICAgfCAgNDQgKysrKystLS0tLQ0KPj4geGVuL2FyY2gvYXJtL2FybTY0L21tdS9tbS5jICAgICAg
ICAgICAgIHwgICAyICstDQo+PiB4ZW4vYXJjaC9hcm0vYm9vdGZkdC5jICAgICAgICAgICAgICAg
ICAgfCAgMjcgKysrLS0tDQo+PiB4ZW4vYXJjaC9hcm0vZG9tMGxlc3MtYnVpbGQuYyAgICAgICAg
ICAgfCAgMTggKystLQ0KPj4geGVuL2FyY2gvYXJtL2RvbWFpbl9idWlsZC5jICAgICAgICAgICAg
IHwgMTA2ICsrKysrKysrKysrKystLS0tLS0tLS0tLQ0KPj4geGVuL2FyY2gvYXJtL2VmaS9lZmkt
Ym9vdC5oICAgICAgICAgICAgIHwgICA4ICstDQo+PiB4ZW4vYXJjaC9hcm0vZWZpL2VmaS1kb20w
LmMgICAgICAgICAgICAgfCAgMTMgKy0tDQo+PiB4ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vZG9t
YWluX2J1aWxkLmggfCAgIDIgKy0NCj4+IHhlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS9rZXJuZWwu
aCAgICAgICB8ICAgOSArKw0KPj4geGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL3NldHVwLmggICAg
ICAgIHwgIDQwICsrKysrKysrLQ0KPj4geGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL3N0YXRpYy1z
aG1lbS5oIHwgICA0ICstDQo+PiB4ZW4vYXJjaC9hcm0va2VybmVsLmMgICAgICAgICAgICAgICAg
ICAgfCAgMTIgKy0tDQo+PiB4ZW4vYXJjaC9hcm0vc2V0dXAuYyAgICAgICAgICAgICAgICAgICAg
fCAgNTggKysrKysrKy0tLS0tLQ0KPj4geGVuL2FyY2gvYXJtL3N0YXRpYy1tZW1vcnkuYyAgICAg
ICAgICAgIHwgIDI3ICsrKy0tLQ0KPj4geGVuL2FyY2gvYXJtL3N0YXRpYy1zaG1lbS5jICAgICAg
ICAgICAgIHwgIDM0ICsrKystLS0tDQo+PiAxNiBmaWxlcyBjaGFuZ2VkLCAyNDMgaW5zZXJ0aW9u
cygrKSwgMTY3IGRlbGV0aW9ucygtKQ0KPiBMb3RzIG9mIG1lY2hhbmljYWwgY2hhbmdlcyBidXQg
aW4gZ2VuZXJhbCBJIGxpa2UgdGhpcyBhcHByb2FjaC4NCj4gSSdkIGxpa2Ugb3RoZXIgbWFpbnRh
aW5lcnMgdG8gc2hhcmUgdGhlaXIgb3Bpbmlvbi4NCj4gDQo+IFsuLi5dDQo+IA0KPj4gQEAgLTEx
NTcsMTAgKzExNjMsMTIgQEAgaW50IF9faW5pdCBtYWtlX2h5cGVydmlzb3Jfbm9kZShzdHJ1Y3Qg
ZG9tYWluICpkLA0KPj4gICAgIH0NCj4+ICAgICBlbHNlDQo+PiAgICAgew0KPj4gLSAgICAgICAg
ZXh0X3JlZ2lvbnMgPSB4emFsbG9jKHN0cnVjdCBtZW1pbmZvKTsNCj4+ICsgICAgICAgIGV4dF9y
ZWdpb25zID0gKHN0cnVjdCBtZW1iYW5rcyAqKXh6YWxsb2Moc3RydWN0IG1lbWluZm8pOw0KPiBZ
b3UncmUgbWFraW5nIGFzc3VtcHRpb24gdGhhdCBzdHJ1Y3QgbWVtYmFua3MgaXMgdGhlIGZpcnN0
IG1lbWJlciBvZiBtZW1pbmZvIGJ1dCB0aGVyZSdzIG5vIHNhbml0eSBjaGVjay4NCj4gV2h5IG5v
dCB4emFsbG9jX2ZsZXhfc3RydWN0KCk/DQoNCknigJlsbCB1c2UgdGhhdCwgYXMgd2VsbCBhcyB0
aGUgY2hlY2sgeW91IHN1Z2dlc3RlZCBiZWxvdw0KDQo+IA0KPj4gICAgICAgICBpZiAoICFleHRf
cmVnaW9ucyApDQo+PiAgICAgICAgICAgICByZXR1cm4gLUVOT01FTTsNCj4gDQo+IFsuLi5dDQo+
PiBkaWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL2tlcm5lbC5oIGIveGVuL2Fy
Y2gvYXJtL2luY2x1ZGUvYXNtL2tlcm5lbC5oDQo+PiBpbmRleCAwYTIzZTg2YzJkMzcuLmQyOGI4
NDNjMDFhOSAxMDA2NDQNCj4+IC0tLSBhL3hlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS9rZXJuZWwu
aA0KPj4gKysrIGIveGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL2tlcm5lbC5oDQo+PiBAQCAtNzgs
NiArNzgsMTUgQEAgc3RydWN0IGtlcm5lbF9pbmZvIHsNCj4+ICAgICB9Ow0KPj4gfTsNCj4+IA0K
Pj4gKyNkZWZpbmUga2VybmVsX2luZm9fZ2V0X21lbShraW5mbykgXA0KPj4gKyAgICAoJihraW5m
byktPm1lbS5jb21tb24pDQo+IFdoeSB0aGlzIGlzIGEgbWFjcm8gYnV0IGZvciBib290aW5mbyB5
b3UgdXNlIHN0YXRpYyBpbmxpbmUgaGVscGVycz8NCg0KU28gSSB0aGluayBJIHN0YXJ0ZWQgdXNp
bmcgc3RhdGljIGlubGluZSBoZWxwZXJzIGJ1dCBJIGhhZCB0byBoYXZlIG9uZSB0aGF0IGRpZG7i
gJl0DQpyZW1vdmUgdGhlIGNvbnN0IHF1YWxpZmllciwgYW5kIGl0IHdhcyB1c2VkIG9ubHkgb25j
ZS4gQW55d2F5IGlmIGl0IGlzIGFjY2VwdGFibGUNCkkgd2lsbCBnbyBmb3Igc3RhdGljIGlubGlu
ZSBhbHNvIGhlcmUuDQoNCj4gDQo+PiArDQo+PiArI2RlZmluZSBLRVJORUxfSU5GT19JTklUIFwN
Cj4gTklUOiBpbiBtb3N0IHBsYWNlcyB3ZSBwcmVmZXIgXCB0byBiZSBhbGlnbmVkICh0aGUgc2Ft
ZSBhcHBseSB0byBvdGhlciBwbGFjZXMpDQoNCmtrDQoNCj4gDQo+PiAreyBcDQo+PiArICAgIC5t
ZW0uY29tbW9uLm1heF9iYW5rcyA9IE5SX01FTV9CQU5LUywgXA0KPj4gKyAgICAuc2htX21lbS5j
b21tb24ubWF4X2JhbmtzID0gTlJfTUVNX0JBTktTLCBcDQo+PiArfQ0KPj4gKw0KPj4gLyoNCj4+
ICAqIFByb2JlIHRoZSBrZXJuZWwgdG8gZGV0ZW1pbmUgaXRzIHR5cGUgYW5kIHNlbGVjdCBhIGxv
YWRlci4NCj4+ICAqDQo+PiBkaWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL3Nl
dHVwLmggYi94ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vc2V0dXAuaA0KPj4gaW5kZXggZDE1YTg4
ZDJlMGQxLi5hM2UxZGM4ZmRiNmMgMTAwNjQ0DQo+PiAtLS0gYS94ZW4vYXJjaC9hcm0vaW5jbHVk
ZS9hc20vc2V0dXAuaA0KPj4gKysrIGIveGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL3NldHVwLmgN
Cj4+IEBAIC01Niw4ICs1NiwxNCBAQCBzdHJ1Y3QgbWVtYmFuayB7DQo+PiAjZW5kaWYNCj4+IH07
DQo+PiANCj4+IC1zdHJ1Y3QgbWVtaW5mbyB7DQo+PiArc3RydWN0IG1lbWJhbmtzIHsNCj4+ICAg
ICB1bnNpZ25lZCBpbnQgbnJfYmFua3M7DQo+PiArICAgIHVuc2lnbmVkIGludCBtYXhfYmFua3M7
DQo+PiArICAgIHN0cnVjdCBtZW1iYW5rIGJhbmtbXTsNCj4+ICt9Ow0KPj4gKw0KPj4gK3N0cnVj
dCBtZW1pbmZvIHsNCj4+ICsgICAgc3RydWN0IG1lbWJhbmtzIGNvbW1vbjsNCj4gWW91IHdlcmUg
c3VwcG9zZWQgdG8gbWFrZSBzdXJlIHRoZXJlIGlzIG5vIGV4dHJhIHBhZGRpbmcgaGVyZS4gSSBk
b24ndCBzZWUgYW55IGNoZWNrIGluIHRoaXMgcGF0Y2guDQo+IEknZCBhdCBsZWFzdCBkbyBzdGgg
bGlrZToNCj4gQlVJTERfQlVHX09OKChvZmZzZXRvZihzdHJ1Y3QgbWVtYmFua3MsIGJhbmspKSAh
PSAob2Zmc2V0b2Yoc3RydWN0IG1lbWluZm8sIGJhbmspKSk7DQoNCknigJlsbCBhZGQgdGhpcyBj
aGVjaywgdGhhbmtzIQ0KDQo+IA0KPiB+TWljaGFsDQoNCg==


From xen-devel-bounces@lists.xenproject.org Tue Mar 19 13:32:36 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 13:32:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695387.1085098 (Exim 4.92)
	(envelope-from )
	id 1rmZZv-00028T-1C; Tue, 19 Mar 2024 13:32:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695387.1085098; Tue, 19 Mar 2024 13:32:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmZZu-00028M-Ul; Tue, 19 Mar 2024 13:32:30 +0000
Received: by outflank-mailman (input) for mailman id 695387;
 Tue, 19 Mar 2024 13:32:29 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmZZt-00026d-HR; Tue, 19 Mar 2024 13:32:29 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmZZt-0004AC-62; Tue, 19 Mar 2024 13:32:29 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmZZs-0007WK-QR; Tue, 19 Mar 2024 13:32:29 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rmZZs-0007rY-Nu; Tue, 19 Mar 2024 13:32:28 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=bME7Y3upBzgRRk1uqc+BZyHQlZnZsg3+q6NZ5kMcg5I=; b=neGSGem+oNhTnzCL/P4z5c/b5f
	f7kTwjMjHKDNdoplSNN8qp4vh2GUBe1O85ZLeNJ8jpqmM0fsa4BTxQGYcEAil215qwKDg2PykG7mr
	jLGB33dNmqz9MdpA/FFvEkRGANoll1wBYULIcPy7SwYpBlWuTN8PhBXfdpEooDUtdtLI=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 185094: tolerable all pass - PUSHED
X-Osstest-Failures:
    xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    xen=d2276b86e5eb8dd2617d917f7b49cdd1f29ac299
X-Osstest-Versions-That:
    xen=62018f08708a5ff6ef8fc8ff2aaaac46e5a60430
From: osstest service owner 
Date: Tue, 19 Mar 2024 13:32:28 +0000

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          16 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  d2276b86e5eb8dd2617d917f7b49cdd1f29ac299
baseline version:
 xen                  62018f08708a5ff6ef8fc8ff2aaaac46e5a60430

Last test of basis   185081  2024-03-18 13:00:27 Z    1 days
Testing same since   185094  2024-03-19 11:00:26 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Alejandro Vallejo 
  Jan Beulich 
  Juergen Gross 
  Julien Grall 
  Marek Marczykowski-Górecki 
  Michal Orzel 
  Nicola Vetrini 

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-amd64                    pass    
 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
   62018f0870..d2276b86e5  d2276b86e5eb8dd2617d917f7b49cdd1f29ac299 -> smoke


From xen-devel-bounces@lists.xenproject.org Tue Mar 19 13:51:06 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 13:51:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695396.1085108 (Exim 4.92)
	(envelope-from )
	id 1rmZro-0005pb-KQ; Tue, 19 Mar 2024 13:51:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695396.1085108; Tue, 19 Mar 2024 13:51:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmZro-0005pU-FR; Tue, 19 Mar 2024 13:51:00 +0000
Received: by outflank-mailman (input) for mailman id 695396;
 Tue, 19 Mar 2024 13:50:59 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmZrn-0005pO-5z
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 13:50:59 +0000
Received: from NAM02-DM3-obe.outbound.protection.outlook.com
 (mail-dm3nam02on20600.outbound.protection.outlook.com
 [2a01:111:f403:2405::600])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b545c282-e5f7-11ee-a1ee-f123f15fe8a2;
 Tue, 19 Mar 2024 14:50:56 +0100 (CET)
Received: from DS7PR03CA0077.namprd03.prod.outlook.com (2603:10b6:5:3bb::22)
 by PH7PR12MB5952.namprd12.prod.outlook.com (2603:10b6:510:1db::6) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.30; Tue, 19 Mar
 2024 13:50:40 +0000
Received: from CY4PEPF0000FCBE.namprd03.prod.outlook.com
 (2603:10b6:5:3bb:cafe::ca) by DS7PR03CA0077.outlook.office365.com
 (2603:10b6:5:3bb::22) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.28 via Frontend
 Transport; Tue, 19 Mar 2024 13:50:39 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 CY4PEPF0000FCBE.mail.protection.outlook.com (10.167.242.100) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Tue, 19 Mar 2024 13:50:39 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Tue, 19 Mar
 2024 08:50:39 -0500
Received: from [172.21.115.105] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Tue, 19 Mar 2024 08:50:38 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b545c282-e5f7-11ee-a1ee-f123f15fe8a2
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=ksMnGQoHXRuTd7VJE8kSr1LiGxTbIncU0NG4Wj1YWvLtjgaFIO9kT4etf8yTzn7L2Z+tYxISa0Zb8DLy7KJQfRes2QHp4ShTMEEushJfOLTi+YSbLaJohjkPoMBsnZ20qxj6LGAYlTV7r/mwRrvQmIt3k8gFled8g/ogcSvWIJ2OCDal0SlcZjcvY2RAlavgJjvOuL2oL4T+XCgwDY/gd9c2K8AQziHodgaleWaGuPQ8kRGlrqyc85iCGAUW2FmCS/6nOaT8BgBSbAM95YCHCZFoj4ebKLRDigggmscuRh3UkR/MtOfEhCInQWCjn9ebDSdtYETOtF9cB/Eo68gDMQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=YxZJ1cpPIu3+aUkREpmAJNKOP0nGyjhxGXKT5XyKIWE=;
 b=DVndPCYxVHL+42N2fKvphUXgiNNTI4pEuvLOmpjUIhaWgOCO/FM5fVrXsZ4kAczdSmjafeJau32lP51fmoX+17WXV++LHNHkLH42vhH1XIJ43Co2XU6feQIzqtbnk5iPq7obE0Qi/Wkjzqp3uDkJKVzoX+WG7owwskuw/XaK6/mBczp3+/5TgdVWk614Myk3IIzTPSuqrP4fDxWD2ox5nu9GqnhoWdAYhvoHyN7AW3rx0P0GB5hRUSlS8zpbGrdopWbDDsJQJ1d97Mtmc6nnbP+FnhHppqKO6u7HHRbOCjkIM47h0dPGZA8QLD4Iyvx6I6p8jwgOq3qWugXDNQfYHw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=YxZJ1cpPIu3+aUkREpmAJNKOP0nGyjhxGXKT5XyKIWE=;
 b=yFl4S+OMFbUG+rP3cEBLlCz4D4Zi/++9RHGa5VkbNAe9gnD82QUXAhbeSmTHWCf4g8oVIdq0IGQBmGyVFK4CYyJf/xmdYBFi4TAfMJyq454Vzmh9WWSPu1Pt6Rbq3300alw0a3eldgbHJDcgzq0/KnMfgczv7mjVXhCYB08hq90=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
Message-ID: <3b06e858-7fb1-4f99-a235-b33ed48c0e32@amd.com>
Date: Tue, 19 Mar 2024 09:50:37 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Jason Andryuk 
Subject: Re: [PATCH v2 3/3] x86/PVH: Support relocatable dom0 kernels
To: Jan Beulich 
CC: Andrew Cooper ,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu
	, George Dunlap , Julien Grall
	, Stefano Stabellini ,
	
References: <20240313193021.241764-1-jason.andryuk@amd.com>
 <20240313193021.241764-4-jason.andryuk@amd.com>
 <12fe48a6-6957-49d7-adf5-1a3ac8b1bfaa@suse.com>
 <7506abe0-e3d4-44f7-b54d-592ae2e3fd3e@amd.com>
 <88bd8577-42e6-4087-9888-00cd73e7f0bc@suse.com>
 
 
Content-Language: en-US
In-Reply-To: 
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB03.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CY4PEPF0000FCBE:EE_|PH7PR12MB5952:EE_
X-MS-Office365-Filtering-Correlation-Id: f01b92e6-0506-40b1-9a8e-08dc481b9004
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	bimK15457pHidLw52jLhZtW1VajDrZAMz3SyXcLn1YnCOZjYhIIB0TcGS1Zm2A2S0xQfVY5uzvViGrlkD0xvmpfuagt5NSNt+fejY7muQnYc+/NVYMTLzIvobd6o2PWJjYqqr3ermYlKceAz1lP8oO6pY3U4zoAGggUdxJEZ8zCl1HQEQsLS6fFcKpbffmL8Kyap4Gu/wcAlR+Nh27L4NlI0rcyn9VASoivPq0QaBpzYwWhSbO8LKLZ89yOOZXBMuwKw01TSygZIVFlIsutMmxbROIgkSSawyZOsgNzzVGcceg3TgEdJcM6kt42BJMMkgXBBuQy7hFZ7rAykjzXDnuOksBBgHSzpBQmM8ty5hLo85aLVlgfTgQ74oPyX3SPcflCiFhlOJeKPaCJmcH21gzt/ZeGXjjiCRqmLztngodrb9ktcFF3MlrnrJyJz4Yx4Ejp72YaFzmaXoPqTEJBhYBK5jOGXP8Lf81v1CsXs8Xu9zsHlY45bv7QLUnd071DqNTEPHPQxWkKV+K6cYBL9kysKpIUDuZLH+lRkDayOHH35emrtV7wk2zAwwzSeL7r/cE6ht2Ho6RBZWMUBP8ecMiOa4ly172Q4TQRX9qO34nYJANS54/qRp3HOmbomwKEI6E0DXl1+tIomabXIdqoDXAtPZseETLBEhjfyhUaEi2HQ2cA4vm9Dzf9k67m/jsCm7SBk2/bfEoX/BXGliLfPza79EXYHKlFNCOLkkbI0Y0o07FsgK60BPBkyTkeK9Mn7
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(82310400014)(376005)(36860700004)(1800799015);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Mar 2024 13:50:39.6367
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: f01b92e6-0506-40b1-9a8e-08dc481b9004
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CY4PEPF0000FCBE.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB5952

On 2024-03-19 04:15, Jan Beulich wrote:
> On 18.03.2024 22:21, Jason Andryuk wrote:
>> On 2024-03-15 05:48, Jan Beulich wrote:
>>> On 14.03.2024 20:19, Jason Andryuk wrote:
>>>> On 2024-03-14 09:31, Jan Beulich wrote:
>>>>> On 13.03.2024 20:30, Jason Andryuk wrote:
>>>>>> --- a/xen/arch/x86/hvm/dom0_build.c
>>>>>> +++ b/xen/arch/x86/hvm/dom0_build.c
>>>>>> @@ -537,6 +537,108 @@ static paddr_t __init find_memory(
>>>>>>         return INVALID_PADDR;
>>>>>>     }
>>>>>>     
>>>>>> +static bool __init check_load_address(
>>>>>> +    const struct domain *d, const struct elf_binary *elf)
>>>>>> +{
>>>>>> +    paddr_t kernel_start = (paddr_t)elf->dest_base & PAGE_MASK;
>>>>>> +    paddr_t kernel_end = PAGE_ALIGN((paddr_t)elf->dest_base + elf->dest_size);
>>>>>
>>>>> Both casts act on a pointer value. Such cannot legitimately be converted
>>>>> to paddr_t; it only so happens that paddr_t is effectively the same as
>>>>> uintptr_t right now. (Same issue again further down.) That said, I notice
>>>>> we have pre-existing examples of this ...
>>>>
>>>> Yes, I followed existing code.  Do you want dest_base to be switched to
>>>> a uintptr_t?
>>>
>>> I think it was deliberately switched to being a pointer at some point,
>>> maybe even in a security fix.
>>
>> commit 65808a8ed41cc7c044f588bd6cab5af0fdc0e029 "libelf: check all
>> pointer accesses", part of XSA-55, switched from a single dest pointer
>> to dest_base & dest_size.
>>
>> For libxenguest, it's a pointer to guest-mapped memory to copy in the
>> kernel.  For PV dom0 creation, it's a pointer - Xen switches to the dom0
>> page tables and performs the copy with it as-is.  For PVH dom0, it's a
>> guest physical address.
>>
>> Are you looking for this to be addressed in this series?
> 
> I'm sorry to ask, but what is "this" here? I'd like your change to leave
> all types alone. I'd further like your change to preferably avoid cloning
> questionable code (i.e. casts using the wrong type in particular). Plus,
> where technically possible, adhere to the general principle of avoiding
> casts (for typically being at least somewhat risky towards hiding
> potential bugs).

I intended "this" to refer to changing dest_base's type.  I won't do 
that.  With some of your other suggestions, most castings are gone.

Thanks,
Jason


From xen-devel-bounces@lists.xenproject.org Tue Mar 19 14:47:30 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 14:47:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695418.1085117 (Exim 4.92)
	(envelope-from )
	id 1rmakG-0005fQ-42; Tue, 19 Mar 2024 14:47:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695418.1085117; Tue, 19 Mar 2024 14:47:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmakG-0005fJ-1C; Tue, 19 Mar 2024 14:47:16 +0000
Received: by outflank-mailman (input) for mailman id 695418;
 Tue, 19 Mar 2024 14:47:14 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmakE-0005fD-Ch
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 14:47:14 +0000
Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com
 [2607:f8b0:4864:20::429])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 91e7ce29-e5ff-11ee-afdd-a90da7624cb6;
 Tue, 19 Mar 2024 15:47:13 +0100 (CET)
Received: by mail-pf1-x429.google.com with SMTP id
 d2e1a72fcca58-6e6bee809b8so5192699b3a.1
 for ; Tue, 19 Mar 2024 07:47:13 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 91e7ce29-e5ff-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710859631; x=1711464431; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=8jsKJd82DUZkFP7wnygY+3TeSxyW9m/47rfwZdNiYZs=;
        b=KUEMBNn1WjtmiGnRVC3Kx1h4QEmLUXt9F5UwaMyR0jpOT7qa2VE6+XCqbovuDzIkhw
         2iN8gCpa7xyxnTWN8jx6wq+TF8dzd9RRSXPzBTVvzns8qLTXSMYjs526zNF/OZVYA5E/
         PimPsOyUn9Bx/Vp9oJSmn8vwX2HrMUsIKJ6CU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710859631; x=1711464431;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=8jsKJd82DUZkFP7wnygY+3TeSxyW9m/47rfwZdNiYZs=;
        b=I9Cqq45i6Ij3VEvMoVCTJGnul6Yw5RSPKEyiIP4AiPXeeUVkegLi0/j1GACvgqhB1E
         J9wgHHm0BqNi1U8magwhZmxy3DNP7wSqdzfMIIfxUKm++DU2YmOG2C/2SjdEiYwAbScN
         Gy2dTgzaYdOWfp/a7G9y0ZZ6zEs9tX9VyIURlPaU2s1rO5sFwwGh7vIGUFMnTaaQCry+
         DB7VYXfRzt5XpJFVIEM0WKCU2YybpbyugqqDIpZNsoj7myN3HrBo+afVzC1GfZTFNfeO
         unjUpTO5WquwxpERd06Wjo8b/sI48jC3pjnCGGAOQy1CPO0pqBUJOIJuvh+Ln4cZBlmI
         9CjA==
X-Forwarded-Encrypted: i=1; AJvYcCVDPheDiLn3bFtsQzVguMwwpv5CzpglO41MzmUne6lTLbr0urEkIM1lStC05whjmteAl7E2GioR0JJgGI/WGaYfI5Y1h98YorUlnJcEGCE=
X-Gm-Message-State: AOJu0YwS3t/kj6zJ7ugynsN2HJd/sKKUI8+xOAOJUJoiSBxzEmvwCtbP
	kBiUraIi0IHSXYaYRz5UcwpDVr5vrXftuUOyk6Vfb/WXaVsKTvl5+TsGbjeio/OYbHhQiBRyYTG
	czfL88izvCtBKIGTotHTIONqieOdZpw9bHguY
X-Google-Smtp-Source: AGHT+IHNRSHxTMVVlcshVQrkMNGe2s0Ed89GE9qM8/pjRO509T6EfpFtjLGxNzQ6EACmIblQYCZZNd6/gdQERW0uhQg=
X-Received: by 2002:a05:6a00:27aa:b0:6e7:f4:3661 with SMTP id
 bd42-20020a056a0027aa00b006e700f43661mr13672189pfb.13.1710859631537; Tue, 19
 Mar 2024 07:47:11 -0700 (PDT)
MIME-Version: 1.0
References: <20240313150748.791236-1-ross.lagerwall@citrix.com>
 <20240313150748.791236-2-ross.lagerwall@citrix.com> 
In-Reply-To: 
From: Ross Lagerwall 
Date: Tue, 19 Mar 2024 14:46:59 +0000
Message-ID: 
Subject: Re: [PATCH 1/7] multiboot2: Add load type header and support for the
 PE binary type
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: grub-devel@gnu.org, xen-devel@lists.xenproject.org, 
	Andrew Cooper , Daniel Kiper 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Mar 19, 2024 at 1:18=E2=80=AFPM Roger Pau Monn=C3=A9  wrote:
>
> On Wed, Mar 13, 2024 at 03:07:42PM +0000, Ross Lagerwall wrote:
> > Currently, multiboot2-compatible bootloaders can load ELF binaries and
> > a.out binaries. The presence of the address header tag determines
> > how the bootloader tries to interpret the binary (a.out if the address
> > tag is present else ELF).
> >
> > Add a new load type header tag that explicitly states the type of the
> > binary. Bootloaders should use the binary type specified in the load
> > type tag. If the load type tag is not present, the bootloader should
> > fall back to the previous heuristics.
> >
> > In addition to the existing address and ELF load types, specify a new
> > optional PE binary load type. This new type is a useful addition since
> > PE binaries can be signed and verified (i.e. used with Secure Boot).
> >
> > Signed-off-by: Ross Lagerwall 
> > ---
> >  doc/multiboot.texi | 39 ++++++++++++++++++++++++++++++++++-----
> >  doc/multiboot2.h   | 13 +++++++++++++
> >  2 files changed, 47 insertions(+), 5 deletions(-)
> >
> > diff --git a/doc/multiboot.texi b/doc/multiboot.texi
> > index df8a0d056e76..d12719c744eb 100644
> > --- a/doc/multiboot.texi
> > +++ b/doc/multiboot.texi
> > @@ -511,11 +511,12 @@ assumes that no bss segment is present.
> >
> >  Note: This information does not need to be provided if the kernel imag=
e
> >  is in @sc{elf} format, but it must be provided if the image is in a.ou=
t
> > -format or in some other format. When the address tag is present it mus=
t
> > -be used in order to load the image, regardless of whether an @sc{elf}
> > -header is also present. Compliant boot loaders must be able to load
> > -images that are either in @sc{elf} format or contain the address tag
> > -embedded in the Multiboot2 header.
> > +format or in some other format. If the load type tag is not specified
> > +and the address tag is present it must be used in order to load the
> > +image, regardless of whether an @sc{elf} header is also present.
> > +Compliant boot loaders must be able to load images that are either in
> > +@sc{elf} format or contain the address tag embedded in the Multiboot2
> > +header.
> >
> >  @subsection The entry address tag of Multiboot2 header
> >
> > @@ -732,6 +733,34 @@ and @samp{2} means load image at highest possible =
address but not
> >  higher than max_addr.
> >  @end table
> >
> > +@node Load type tag
> > +@subsection Load type tag
> > +
> > +@example
> > +@group
> > +        +-------------------+
> > +u16     | type =3D 11         |
> > +u16     | flags             |
> > +u32     | size =3D 12         |
> > +u32     | load_type         |
> > +        +-------------------+
> > +@end group
> > +@end example
> > +
> > +This tag indicates the type of the payload and how the boot loader
> > +should load it.
> > +
> > +The meaning of each field is as follows:
> > +
> > +@table @code
> > +@item load_type
> > +Recognized load types are @samp{0} for address (i.e. load a.out using
> > +the address tag), @samp{1} for ELF, and @samp{2} for PE. Compliant
> > +bootloaders should implement support for a.out and ELF as a minimum.  =
If
> > +this tag is not specified, the boot loader should attempt to load the
> > +payload using the information specified in the address tag if present,
> > +else it should load the payload as an ELF binary.  @end table
>
> I wonder if it would be simpler to use the following order instead:
>
> 1. Address tag
> 2. Load type tag
> 3. ELF header
>
> It's pointless to add a Loader type tag with load_type =3D=3D 0, as that'=
s
> already mandated by the Address tag.  IOW: signaling the use of the
> Address tag here is kind of pointless, if the fields in the Address
> tag are set, that's the only signaling required for the data in the
> Address tag to be used.
>
> Or are we attempting to support images that set Address tag and Load
> type tag !=3D 0 in order to use the Address tag when the loader doesn't
> recognize the Load type tag, and otherwise use a different format?

No, that wasn't my intention. My intention for the load type tag was
to have one tag that unambiguously describes the payload format and if
that is missing, fall back to the previous logic for compatibility.
It avoids more complicated heuristics if different payload types are
added in the future.

>
> Would it be sensible for multiboot2 to use PE in preference to ELF if
> present on the image?  (without requiring any signaling).  I would
> think this could be troublesome if kernels are so far expecting the
> ELF header to be used with multiboot2, even if they also expose a PE
> header.
>

AFAIK an ELF image can't also be a valid PE/COFF image since they have
different magic numbers at the start of the image. Perhaps it would
be simpler to avoid introducing the load type tag and just load the
payload based on the magic number?

Ross


From xen-devel-bounces@lists.xenproject.org Tue Mar 19 14:48:07 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 14:48:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695420.1085127 (Exim 4.92)
	(envelope-from )
	id 1rmal5-00068s-Dg; Tue, 19 Mar 2024 14:48:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695420.1085127; Tue, 19 Mar 2024 14:48:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmal5-00068l-B8; Tue, 19 Mar 2024 14:48:07 +0000
Received: by outflank-mailman (input) for mailman id 695420;
 Tue, 19 Mar 2024 14:48:06 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmal4-0005fD-8s
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 14:48:06 +0000
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com
 [2a00:1450:4864:20::62d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b1b4686c-e5ff-11ee-afdd-a90da7624cb6;
 Tue, 19 Mar 2024 15:48:05 +0100 (CET)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-a3fb8b0b7acso553897766b.2
 for ; Tue, 19 Mar 2024 07:48:05 -0700 (PDT)
Received: from andrewcoop.citrite.net (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 xi8-20020a170906dac800b00a46af0fbe83sm3335059ejb.76.2024.03.19.07.48.04
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 19 Mar 2024 07:48:04 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b1b4686c-e5ff-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710859685; x=1711464485; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:from:to:cc:subject:date:message-id:reply-to;
        bh=NHqVyHLUrPDfT7mviOp2ST2s9iKsUHLn9cXgoLEhrV0=;
        b=Rf2EQYzXqUNloTGGeA1luTlDeiNejudanWunuCe0Ew+nMTb4opjGhRmPfUBnziqTXl
         WpoHBg+TNJ7eM7Eib9DYht/QOIBuq5BkIdq8mUoFUqKd4IyqxiHRMTZqI/wqZh6XJBvw
         EhCJz/dcGT9Je7JcZN5kC21ccgKgEHDU/l55Y=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710859685; x=1711464485;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=NHqVyHLUrPDfT7mviOp2ST2s9iKsUHLn9cXgoLEhrV0=;
        b=VT9k+KG3zdO5UQzohShNMygTUGsUyCcnroftY0qNkPQxZYWstEe6ONZoSRy0IK8Md8
         /Vbsb1c0JW0UhkbpA3bUs6rLUxRwQDwi2JxtyB6mZGwByjPmmGGmwOGlipSmKQx+j2+C
         vzEBH4pIgauHAZP2B42BvpCFt+JsiAPK6pEpqCiuKN0wpDqZB8CMCzsDt0mkfPJFSg4Z
         LU/ppIkKe01vjBolcc32umCV5qI14bLTtSGkhFH2DTGW38ed3v3pJxx4OpZ65nb2GoDi
         gJQD9IfyfODRnnQkewh/3Ypro/TL+WC6XFz2htX2POXY9NO5oOiGshJsKgeHSntOVvdf
         9kog==
X-Gm-Message-State: AOJu0YyhCsJ62X3C48uo9IEI6itYJXAr/6V2Xd9vjhtClnR44FUtn5Zg
	/mlds1PwSm7lzX0K3Z9ghlatj4IpUypWvrsTQjJqxi+LPVWjJlLcrtTkrhmHO/f25aDRcV4ndI6
	v
X-Google-Smtp-Source: AGHT+IGF6onu9JpmMF67TiMpmEBXGcf/E25UVSF0RvOGq0Alon/sCKeCdIoM5MhRUjkXRUoP/69CCg==
X-Received: by 2002:a17:906:1b03:b0:a46:d913:bb7d with SMTP id o3-20020a1709061b0300b00a46d913bb7dmr1754912ejg.56.1710859684812;
        Tue, 19 Mar 2024 07:48:04 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH 0/2] x86/boot: More watchdog fixes
Date: Tue, 19 Mar 2024 14:48:00 +0000
Message-Id: <20240319144802.3894710-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.30.2
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Andrew Cooper (2):
  x86/boot: Fix setup_apic_nmi_watchdog() to fail more cleanly
  x86/boot: Support the watchdog on newer AMD systems

 xen/arch/x86/nmi.c | 36 ++++++++++++++++--------------------
 1 file changed, 16 insertions(+), 20 deletions(-)


base-commit: d2276b86e5eb8dd2617d917f7b49cdd1f29ac299
prerequisite-patch-id: 9595e30e0dde42b57dbad93a40db2cd338b26a58
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Tue Mar 19 14:48:09 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 14:48:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695421.1085138 (Exim 4.92)
	(envelope-from )
	id 1rmal7-0006O9-MH; Tue, 19 Mar 2024 14:48:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695421.1085138; Tue, 19 Mar 2024 14:48:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmal7-0006Nw-IR; Tue, 19 Mar 2024 14:48:09 +0000
Received: by outflank-mailman (input) for mailman id 695421;
 Tue, 19 Mar 2024 14:48:08 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmal6-0005fD-Sb
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 14:48:08 +0000
Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com
 [2a00:1450:4864:20::131])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b3598bfe-e5ff-11ee-afdd-a90da7624cb6;
 Tue, 19 Mar 2024 15:48:08 +0100 (CET)
Received: by mail-lf1-x131.google.com with SMTP id
 2adb3069b0e04-51381021af1so8201708e87.0
 for ; Tue, 19 Mar 2024 07:48:08 -0700 (PDT)
Received: from andrewcoop.citrite.net (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 xi8-20020a170906dac800b00a46af0fbe83sm3335059ejb.76.2024.03.19.07.48.06
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 19 Mar 2024 07:48:06 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b3598bfe-e5ff-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710859686; x=1711464486; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Eaw7etip514ivjOH3GhsXOD2/5lNzqfhjxpPNlIaVtY=;
        b=Z30m6RQoRuYn1d6NjJl23Xvx++bBlWtCpSfy2XgcdJsaCSBENWKU6wkeyVNLkWCPED
         X+gaF9a/e5ZncozNy4QOMt51dpQDC7rqmvVTKORmJO/TFEoICmr+/qALTQa9bzf8kWeJ
         grtcfWQGlIwPFB/pjFoemHiOuCDU2MY8QUuC4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710859686; x=1711464486;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=Eaw7etip514ivjOH3GhsXOD2/5lNzqfhjxpPNlIaVtY=;
        b=d+Cy6g6suiU5ikSSdx9nyxnUVqfE5sUc3bzHyR7xxqFz/iEgn8lEpNyORFUQ+K8aJG
         GmTqevwa1rLlBthlC2xo2c4E/CWDUBgIx51qbXDfPTswju3pLU1czAbVZWBDsUo0+Wi3
         1F/AJjvQB09IMHl+gc4rGuF23BaeVj2oLlgEnvltc/WiQESqaDhExYTU0nuqwmakrVZ6
         7psPP3Uulh75lqEilg0B4QXGl+uGglBtBg1iqYqGWTMANSMRQB6/0MghZ+Zt6XCJA6OT
         /U11uBY/MDMMuq/TzuMAJs4VD8LRhPegWhG0uFUa8DNtPST0wXqO5Q0NR+K52nhs5Ajf
         csag==
X-Gm-Message-State: AOJu0Yy2APYuwgKw9jH6itsWXXM8DPy0j4oqEHrjYVJM3vyXHBiwpOz8
	jf9cHJb7jF9LYjKPiXb5kSVf2+o9sUYDJI5pFGw1GCO2XrhJGTfIYbmi9HSAE6t66zaPYsTtlnc
	t
X-Google-Smtp-Source: AGHT+IFSwPYDc0ZA0xloOcC4DmRiqr+2k2oSPeyuavUrZ8xRya4nQ0h+DcfqTzDeEeb5R85aZ6DvEw==
X-Received: by 2002:ac2:5e9d:0:b0:513:cb89:82c1 with SMTP id b29-20020ac25e9d000000b00513cb8982c1mr7959551lfq.43.1710859686557;
        Tue, 19 Mar 2024 07:48:06 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH 2/2] x86/boot: Support the watchdog on newer AMD systems
Date: Tue, 19 Mar 2024 14:48:02 +0000
Message-Id: <20240319144802.3894710-3-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20240319144802.3894710-1-andrew.cooper3@citrix.com>
References: <20240319144802.3894710-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The MSRs used by setup_k7_watchdog() are architectural in 64bit.  The Unit
Select (0x76, cycles not in halt state) isn't, but it hasn't changed in 23
years, making this a trend likely to continue.

Drop the family check.  If the Unit Select does happen to change meaning in
the future, check_nmi_watchdog() will still notice the watchdog not operating
as expected.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
---
 xen/arch/x86/nmi.c | 11 ++++-------
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/xen/arch/x86/nmi.c b/xen/arch/x86/nmi.c
index 33f77a92047f..f6329cb0270e 100644
--- a/xen/arch/x86/nmi.c
+++ b/xen/arch/x86/nmi.c
@@ -387,15 +387,12 @@ void setup_apic_nmi_watchdog(void)
     if ( nmi_watchdog == NMI_NONE )
         return;
 
-    switch (boot_cpu_data.x86_vendor) {
+    switch ( boot_cpu_data.x86_vendor )
+    {
     case X86_VENDOR_AMD:
-        switch (boot_cpu_data.x86) {
-        case 6:
-        case 0xf ... 0x19:
-            setup_k7_watchdog();
-            break;
-        }
+        setup_k7_watchdog();
         break;
+
     case X86_VENDOR_INTEL:
         switch (boot_cpu_data.x86) {
         case 6:
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Tue Mar 19 14:48:12 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 14:48:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695422.1085148 (Exim 4.92)
	(envelope-from )
	id 1rmalA-0006gf-TS; Tue, 19 Mar 2024 14:48:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695422.1085148; Tue, 19 Mar 2024 14:48:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmalA-0006gW-Ql; Tue, 19 Mar 2024 14:48:12 +0000
Received: by outflank-mailman (input) for mailman id 695422;
 Tue, 19 Mar 2024 14:48:11 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmal9-0006Nt-61
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 14:48:11 +0000
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com
 [2a00:1450:4864:20::229])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b2d6c161-e5ff-11ee-a1ee-f123f15fe8a2;
 Tue, 19 Mar 2024 15:48:07 +0100 (CET)
Received: by mail-lj1-x229.google.com with SMTP id
 38308e7fff4ca-2d28051376eso93189501fa.0
 for ; Tue, 19 Mar 2024 07:48:07 -0700 (PDT)
Received: from andrewcoop.citrite.net (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 xi8-20020a170906dac800b00a46af0fbe83sm3335059ejb.76.2024.03.19.07.48.04
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 19 Mar 2024 07:48:05 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b2d6c161-e5ff-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710859686; x=1711464486; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=ICFn6HYHLdztYm+7ek+tVrqiDg89lcf+qeTaqhK3dQQ=;
        b=vA+H0DpVgIXq7cG0ogY8kgL4iQIwDwK35jDccpAj5GYxqVk0eoUmkvoiKGMTH3OmzD
         7rkELJtae+DQoPRE5JUz0JJ6mYEkl0sEkbQEMpXBGBfytZgktUxD0xnK1Zk3ouiYPOc7
         fVACjSze1tQ2jy4MnqnGC2FM28n3FPQPQoUDQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710859686; x=1711464486;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=ICFn6HYHLdztYm+7ek+tVrqiDg89lcf+qeTaqhK3dQQ=;
        b=WugJ7tZYF4yWnt9eHzP7xs3I6w70lTwRukW77h2d1c4TLHzSXo73R3EN19qGoyhsVR
         Abxgba2OubjF44iYBUFk7uRpbD5+EM4nem7Tby3ukFX6lMfop+x2Gzmf7MGG0QWoybWV
         PGxrdSKV4+etkaUUAGm0U8SpWFrnkc0Ii+KjtiQPyMoF6pyb015JRiVwhZIcR26Ly084
         Y/taDLEPyie0+DIzD1ZZnlZPiIQzvdC8ycfNbA5TfUaSBBo2d4MwZ2/6iy2UF7tS+j4p
         idxT+aQVrVbAgBlee3sePGMBjhNjm2ibzUjAtJUeY5Geupe9dB7X2vaJoE9GaJoWIbpq
         EySQ==
X-Gm-Message-State: AOJu0Yyi/Sat+RaQA2S8dTabHz6Ur7Z6hY55DK/F3Cyi3zI8ctOEbZ8Z
	LKTkMYn5khvbQ8yKEVD3VxfUIAwokysRCUKJS0CuEgZzHiN5WguSe+HINGPBbC+Iwt9gY++nHOX
	D
X-Google-Smtp-Source: AGHT+IF5i5JE7N6DFA/B6ja5buYfxvVRqAa9umaE58q7GRlamTXFyPIexgPfCbnLDlBLo5TAMLMR0w==
X-Received: by 2002:a05:651c:50f:b0:2d4:6d56:4aa9 with SMTP id o15-20020a05651c050f00b002d46d564aa9mr10785801ljp.33.1710859685932;
        Tue, 19 Mar 2024 07:48:05 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH 1/2] x86/boot: Fix setup_apic_nmi_watchdog() to fail more cleanly
Date: Tue, 19 Mar 2024 14:48:01 +0000
Message-Id: <20240319144802.3894710-2-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20240319144802.3894710-1-andrew.cooper3@citrix.com>
References: <20240319144802.3894710-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Right now, if the user requests the watchdog on the command line,
setup_apic_nmi_watchdog() will blindly assume that setting up the watchdog
worked.  Reuse nmi_perfctr_msr to identify when the watchdog has been set up.

Rearrange setup_p6_watchdog() to not set nmi_perfctr_msr until the sanity
checks are performed.  Turn setup_p4_watchdog() into a void function, matching
the others.

If the watchdog isn't set up, inform the user and override to NMI_NONE, which
will prevent check_nmi_watchdog() from claiming that all CPUs are stuck.

e.g.:

  (XEN) alt table ffff82d040697c38 -> ffff82d0406a97f0
  (XEN) Failed to configure NMI watchdog
  (XEN) Brought up 512 CPUs
  (XEN) Scheduling granularity: cpu, 1 CPU per sched-resource

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 

This is all horrible code.
---
 xen/arch/x86/nmi.c | 25 ++++++++++++-------------
 1 file changed, 12 insertions(+), 13 deletions(-)

diff --git a/xen/arch/x86/nmi.c b/xen/arch/x86/nmi.c
index 8994c50cb5e4..33f77a92047f 100644
--- a/xen/arch/x86/nmi.c
+++ b/xen/arch/x86/nmi.c
@@ -319,8 +319,6 @@ static void setup_p6_watchdog(unsigned counter)
 {
     unsigned int evntsel;
 
-    nmi_perfctr_msr = MSR_P6_PERFCTR(0);
-
     if ( !nmi_p6_event_width && current_cpu_data.cpuid_level >= 0xa )
         nmi_p6_event_width = MASK_EXTR(cpuid_eax(0xa), P6_EVENT_WIDTH_MASK);
     if ( !nmi_p6_event_width )
@@ -330,6 +328,8 @@ static void setup_p6_watchdog(unsigned counter)
          nmi_p6_event_width > BITS_PER_LONG )
         return;
 
+    nmi_perfctr_msr = MSR_P6_PERFCTR(0);
+
     clear_msr_range(MSR_P6_EVNTSEL(0), 2);
     clear_msr_range(MSR_P6_PERFCTR(0), 2);
 
@@ -345,13 +345,13 @@ static void setup_p6_watchdog(unsigned counter)
     wrmsr(MSR_P6_EVNTSEL(0), evntsel, 0);
 }
 
-static int setup_p4_watchdog(void)
+static void setup_p4_watchdog(void)
 {
     uint64_t misc_enable;
 
     rdmsrl(MSR_IA32_MISC_ENABLE, misc_enable);
     if (!(misc_enable & MSR_IA32_MISC_ENABLE_PERF_AVAIL))
-        return 0;
+        return;
 
     nmi_perfctr_msr = MSR_P4_IQ_PERFCTR0;
     nmi_p4_cccr_val = P4_NMI_IQ_CCCR0;
@@ -374,13 +374,12 @@ static int setup_p4_watchdog(void)
     clear_msr_range(0x3E0, 2);
     clear_msr_range(MSR_P4_BPU_CCCR0, 18);
     clear_msr_range(MSR_P4_BPU_PERFCTR0, 18);
-        
+
     wrmsrl(MSR_P4_CRU_ESCR0, P4_NMI_CRU_ESCR0);
     wrmsrl(MSR_P4_IQ_CCCR0, P4_NMI_IQ_CCCR0 & ~P4_CCCR_ENABLE);
     write_watchdog_counter("P4_IQ_COUNTER0");
     apic_write(APIC_LVTPC, APIC_DM_NMI);
     wrmsrl(MSR_P4_IQ_CCCR0, nmi_p4_cccr_val);
-    return 1;
 }
 
 void setup_apic_nmi_watchdog(void)
@@ -395,8 +394,6 @@ void setup_apic_nmi_watchdog(void)
         case 0xf ... 0x19:
             setup_k7_watchdog();
             break;
-        default:
-            return;
         }
         break;
     case X86_VENDOR_INTEL:
@@ -407,14 +404,16 @@ void setup_apic_nmi_watchdog(void)
                               : CORE_EVENT_CPU_CLOCKS_NOT_HALTED);
             break;
         case 15:
-            if (!setup_p4_watchdog())
-                return;
+            setup_p4_watchdog();
             break;
-        default:
-            return;
         }
         break;
-    default:
+    }
+
+    if ( nmi_perfctr_msr == 0 )
+    {
+        printk(XENLOG_WARNING "Failed to configure NMI watchdog\n");
+        nmi_watchdog = NMI_NONE;
         return;
     }
 
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Tue Mar 19 14:58:18 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 14:58:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695432.1085157 (Exim 4.92)
	(envelope-from )
	id 1rmauq-00010p-QI; Tue, 19 Mar 2024 14:58:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695432.1085157; Tue, 19 Mar 2024 14:58:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmauq-00010i-NX; Tue, 19 Mar 2024 14:58:12 +0000
Received: by outflank-mailman (input) for mailman id 695432;
 Tue, 19 Mar 2024 14:58:11 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmaup-0000z5-2v
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 14:58:11 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on20601.outbound.protection.outlook.com
 [2a01:111:f403:2415::601])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1879bea9-e601-11ee-a1ee-f123f15fe8a2;
 Tue, 19 Mar 2024 15:58:08 +0100 (CET)
Received: from MN2PR22CA0023.namprd22.prod.outlook.com (2603:10b6:208:238::28)
 by CY8PR12MB8362.namprd12.prod.outlook.com (2603:10b6:930:7e::19)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.27; Tue, 19 Mar
 2024 14:58:02 +0000
Received: from BN2PEPF000044A9.namprd04.prod.outlook.com
 (2603:10b6:208:238:cafe::da) by MN2PR22CA0023.outlook.office365.com
 (2603:10b6:208:238::28) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.27 via Frontend
 Transport; Tue, 19 Mar 2024 14:58:02 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 BN2PEPF000044A9.mail.protection.outlook.com (10.167.243.103) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Tue, 19 Mar 2024 14:58:02 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Tue, 19 Mar
 2024 09:58:02 -0500
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB05.amd.com
 (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Tue, 19 Mar
 2024 09:58:02 -0500
Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Tue, 19 Mar 2024 09:58:00 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1879bea9-e601-11ee-a1ee-f123f15fe8a2
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=CkWxsPbwapFMqkH1k5eCSd+TNL5ZLnJURvTytWbzAUBVYPVsRYqQTPzEMIvpzDEXADKN3sx7kzu3a5r1U+OPO6mKFwuUMdTD2XOq6PhipqPkhtWNkFK6ryfHC/QBKyJARfEa4oMShUmiBMZtLv/3L8wKeBtG7TKLrUOfHMmPbaJIiOBub8Nd2OySbsHj/twhFc/wGluAQRin53LIwPQBjjvw0u/w3CM3VOyep4Jj7W1SDcKA/EcOhwZDh70j93RBf4JOPrSvuv3RaBhe6YzO9aA+CfhUtJ8qemTNpgVDRsiQHJBOvfhluMOtB9C9xwUkosRA10pufa6qggH+Kx9RAg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Oh6tmfvN8fcDo+SfSU22ZT+cMk+cmr5zybKRLkkMs8E=;
 b=mcpHUkqIDNtOpip0mQ4ljqLuscm3HWZb8lgCLj7QiX2OkYAXg/M9wE0PUdVWKvA1ploesJEhy1wwYN9pt4MEeSCUEf0p6+7ZIuUxQ4K5NbPltj1g/VF6hBmNFXqKDq3vh5LbMKokn/SZtt9lklBg+9/T9zPDnqnDA3kCyXCQju7lW7IEj87bfoM/WyXe/PdU4OkkUb6Vce7ssrZAAK5XF8ysJ8qlpQDaHuE/r4He1V+FDrkemCMW/sUSJUkBKbcHKVUcfTI2bZdUcKHlkBgn+/d6806Vik6wxNBUQlMme9lS8Fnjxb4DpYT8qJW5jVww/1U02CgcFWHheZ+Jwmpzhg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=arm.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=Oh6tmfvN8fcDo+SfSU22ZT+cMk+cmr5zybKRLkkMs8E=;
 b=loL6JEqm/kFOX+KTboMxkLlAR/irhIIVbRy6j4xhkeJ0ToCCpKnMrym2yDbLJbUtHHK2DUBRn5xZC1/4gInZbGHdpm6skM3phnF0mtaFqim+GpcP4Gk+bVAm6dyX1bxrrIVOPOl6QgP8X9kkWYVCASxiFDMoAg1p3p3NwKOrS1A=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
Message-ID: <0dd4d824-068a-4975-a1af-e194337a64b9@amd.com>
Date: Tue, 19 Mar 2024 15:58:00 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 04/11] xen/arm: Conditional compilation of
 kernel_info.shm_mem member
Content-Language: en-US
To: Luca Fancellu , 
CC: Stefano Stabellini , Julien Grall
	, Bertrand Marquis , "Volodymyr
 Babchuk" 
References: <20240312130331.78418-1-luca.fancellu@arm.com>
 <20240312130331.78418-5-luca.fancellu@arm.com>
From: Michal Orzel 
In-Reply-To: <20240312130331.78418-5-luca.fancellu@arm.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB05.amd.com: michal.orzel@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN2PEPF000044A9:EE_|CY8PR12MB8362:EE_
X-MS-Office365-Filtering-Correlation-Id: 9deb9f31-0f01-4d36-8f26-08dc4824f9c7
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	jC2ZlGRpDPj0vt/We8sXD3w2g9I54PfbAyy1DDd5ZEMpScE7u8FcI4LkNLQwywYoRMRE+QBx76l5kv9SQikcyZDc6IDzKpi1HeR3/Xfn4773/or/cRYsLbrK2zD8O7TXeMQIrHEelVWrGUN3TKu1VQh+/n7QGwv/ldqcdIgYvWNKkoD8GolwvHDr5fi9cbFFo45SzeFFcInANMRS4L79Iykz2gxElZG2+sfzdzuMII2nyXUxZg+CxJsGMBkAaLuM5eC1dmFtdRqJKIzzW6NrGsM567A6r6+Xvc7RBjcYf9A1+eQXniARYb0nH90fk50Pln+oIPJ6o5e1eFzRgRuTu5JYokzA77dFhYsTW5BQaoS0KlLYvmAOqexVBI41aIzFbVPn4+ScCbxWeL3Ldkuczr3QD9dXRQhOwVE7lHr+howK6CcbU2E3TVvCTDqB5hy+lVyo5kgcXoCBTKezKP4ekdoLMUJybG8l2nuZWO4dtVUgHywozbTw3gvVQzr791eXRabJlvlpftTmdzXXvTYdTom+TF9+teDUTHd/KVUwXfd7bXobI+k9GtYPdfXxePGGeXKaVpugsSMmIgkL6ZQTqySY55nAUYuI5gIkq3vqAawFJ7yU9tt4bWIC1Jtm5LG11vquK3kMqzq8JUE38UvBuHSeUv7GDE3+Lv4LPHl9K1hPbOMXe5OdbBsZrlDJhbhgv0+7xcRnFeylZglt6t6Kgxy1uBQGO7Y1uTUmq/z5E3ELPz6q8gX47rZZ7wD5yPix
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(376005)(36860700004)(1800799015)(34020700007)(82310400014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Mar 2024 14:58:02.5926
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 9deb9f31-0f01-4d36-8f26-08dc4824f9c7
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN2PEPF000044A9.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB8362

Hi Luca,

On 12/03/2024 14:03, Luca Fancellu wrote:
> 
> 
> The user of shm_mem member of the 'struct kernel_info' is only
> the code managing the static shared memory feature, which can be
> compiled out using CONFIG_STATIC_SHM, so in case the feature is
> not requested, that member won't be used and will waste memory
> space.
> 
> To address this issue, protect the member with the Kconfig parameter
> and modify the signature of the only function using it to remove
> any reference to the member from outside the static-shmem module.
> 
> Signed-off-by: Luca Fancellu 
Reviewed-by: Michal Orzel 

NIT: I always wonder why we have hundreds of functions taking both struct domain and
struct kernel_info as arguments if the latter has the former as its member. As you are
revisiting the function and modifying parameter list, you could take the opportunity
to change it. But you don't have to.

~Michal



From xen-devel-bounces@lists.xenproject.org Tue Mar 19 14:58:41 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 14:58:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695435.1085168 (Exim 4.92)
	(envelope-from )
	id 1rmavJ-0001aK-5A; Tue, 19 Mar 2024 14:58:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695435.1085168; Tue, 19 Mar 2024 14:58:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmavJ-0001aD-2c; Tue, 19 Mar 2024 14:58:41 +0000
Received: by outflank-mailman (input) for mailman id 695435;
 Tue, 19 Mar 2024 14:58:40 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmavH-0000z5-UQ
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 14:58:40 +0000
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com
 [2a00:1450:4864:20::532])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2a91ebe8-e601-11ee-a1ee-f123f15fe8a2;
 Tue, 19 Mar 2024 15:58:38 +0100 (CET)
Received: by mail-ed1-x532.google.com with SMTP id
 4fb4d7f45d1cf-56a9f5694dcso2458139a12.1
 for ; Tue, 19 Mar 2024 07:58:38 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 z16-20020a170906669000b00a46e6affa44sm528793ejo.19.2024.03.19.07.58.36
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 19 Mar 2024 07:58:36 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2a91ebe8-e601-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710860317; x=1711465117; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=YbUW3ePII5ZAiaDBAEc4H/aS4xDzwNvro+S1RlWt2Dk=;
        b=PMa+4+prRSn37g8oOqV+UzFG1LArBkYEsSONQb1gs4ELkmWc8DlFVCT68zFspQrBVB
         LFfUZJryCLo09Hz8iTrcVnlW0sEPPMHDTJQXIF0DBoTbX3AZa06SYMhctS2/1FdNIMe2
         OhJ7jUPdUDWn0yIH7w/Oy5gihqcjL47rLrmP3AL+DiTA3Yb1jdK1qABTPO7YB057Cmjx
         byjLWF9rIcZ9LoDskga72XTQuTODhOdPpMKWuHiJJgOiRseCDeNxtLPc7vJG+WS4Yr6X
         cpAW0YTlgUCAsmDIhPsPtsRL+HB4rvWrY7XjEeRtYHaSl0SXlTaMUCMBbTujdo4k1g3d
         4pbQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710860317; x=1711465117;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=YbUW3ePII5ZAiaDBAEc4H/aS4xDzwNvro+S1RlWt2Dk=;
        b=WEtDtbKtaa6dJiTuweE7KUaYfqSy4qhPkx3pDAO3l5tyZjjE/G5xwsYCsBzxA2psPF
         8UmuoC8/Xwd08/EFFy8lwaiK7VziTOUFC3i7YZ8/E4ZNs/XAQyQ5Y9YXbiYnfsZ88ZtU
         af5p0KsDgXK1Q6jRgAkSDlcJmWVFPlji6IkSwoPZ0jTEcKXZaPqE1VFSsl6AS8KgJaCr
         zl/zEJsx8ABflyqvOfoFO91vkvIIy3zLdHm9otm7DpTDNiNBgLswbDtgilVrQOpo1hDa
         Xb/vh3QHR4cmdZVNx/nTgzn4qWKH94TSq4aFAf51+Goo1VauA19HCb2+0ZtaUZvWZJKf
         tNUA==
X-Forwarded-Encrypted: i=1; AJvYcCX25Q7crbW1WG9t0OfZeYvrLWE0v3s+qQRMDcfI7UXx/gSF7gDd2mGrRyo2yaYgRj/L1ilzb1fD/OuJheKMUQ16vP3rabL4dnyPCegDrtc=
X-Gm-Message-State: AOJu0YzzLxvwMi8kQL+ZbUvWuv7dHu18iT3vdSE4SsH7KoTyKwcw9pQD
	ZEbQmHpSe7HBdKLab9TnUXpqLVLXgKl5Y/PKsEUReAYZtexRhLjRqPI+sH2iLj9APL6d4PHq6FM
	=
X-Google-Smtp-Source: AGHT+IEF57ZO2P59NhfhyciFLk33Rzp6Ts8VD8aTzpZztFCqBMP+Yjis0zu66+KkZwdqGMq4zP1W7g==
X-Received: by 2002:a17:906:af07:b0:a46:b028:7dd2 with SMTP id lx7-20020a170906af0700b00a46b0287dd2mr1847759ejb.48.1710860317349;
        Tue, 19 Mar 2024 07:58:37 -0700 (PDT)
Message-ID: <05e4d3da-4130-4c57-9855-43b685ce5005@suse.com>
Date: Tue, 19 Mar 2024 15:58:35 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 01/14] xen/common: add cache coloring common code
Content-Language: en-US
To: Carlo Nonato 
Cc: Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 Marco Solieri , xen-devel@lists.xenproject.org
References: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
 <20240315105902.160047-2-carlo.nonato@minervasys.tech>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240315105902.160047-2-carlo.nonato@minervasys.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 15.03.2024 11:58, Carlo Nonato wrote:
> +Background
> +**********
> +
> +Cache hierarchy of a modern multi-core CPU typically has first levels dedicated
> +to each core (hence using multiple cache units), while the last level is shared
> +among all of them. Such configuration implies that memory operations on one
> +core (e.g. running a DomU) are able to generate interference on another core
> +(e.g. hosting another DomU). Cache coloring realizes per-set cache-partitioning
> +in software and mitigates this, guaranteeing higher and more predictable
> +performances for memory accesses.

Are you sure about "higher"? On an otherwise idle system, a single domain (or
vCPU) may perform better when not partitioned, as more cache would be available
to it overall.

> +How to compute the number of colors
> +###################################
> +
> +Given the linear mapping from physical memory to cache lines for granted, the
> +number of available colors for a specific platform is computed using three
> +parameters:
> +
> +- the size of the LLC.
> +- the number of the LLC ways.
> +- the page size used by Xen.
> +
> +The first two parameters can be found in the processor manual, while the third
> +one is the minimum mapping granularity. Dividing the cache size by the number of
> +its ways we obtain the size of a way. Dividing this number by the page size,
> +the number of total cache colors is found. So for example an Arm Cortex-A53
> +with a 16-ways associative 1 MiB LLC can isolate up to 16 colors when pages are
> +4 KiB in size.
> +
> +LLC size and number of ways are probed automatically by default so there's
> +should be no need to compute the number of colors by yourself.

Is this a leftover from the earlier (single) command line option?

> +Effective colors assignment
> +###########################
> +
> +When assigning colors:
> +
> +1. If one wants to avoid cache interference between two domains, different
> +   colors needs to be used for their memory.
> +
> +2. To improve spatial locality, color assignment should privilege continuity in

s/privilege/prefer/ ?

> +   the partitioning. E.g., assigning colors (0,1) to domain I and (2,3) to
> +   domain J is better than assigning colors (0,2) to I and (1,3) to J.

While I consider 1 obvious without further explanation, the same isn't
the case for 2: What's the benefit of spatial locality? If there was
support for allocating higher order pages, I could certainly see the
point, but iirc that isn't supported (yet).

> +Command line parameters
> +***********************
> +
> +Specific documentation is available at `docs/misc/xen-command-line.pandoc`.
> +
> ++----------------------+-------------------------------+
> +| **Parameter**        | **Description**               |
> ++----------------------+-------------------------------+
> +| ``llc-coloring``     | enable coloring at runtime    |
> ++----------------------+-------------------------------+
> +| ``llc-size``         | set the LLC size              |
> ++----------------------+-------------------------------+
> +| ``llc-nr-ways``      | set the LLC number of ways    |
> ++----------------------+-------------------------------+
> +
> +Auto-probing of LLC specs
> +#########################
> +
> +LLC size and number of ways are probed automatically by default.
> +
> +LLC specs can be manually set via the above command line parameters. This
> +bypasses any auto-probing and it's used to overcome failing situations or for
> +debugging/testing purposes.

As well as perhaps for cases where the auto-probing logic is flawed?

> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -1706,6 +1706,43 @@ This option is intended for debugging purposes only.  Enable MSR_DEBUGCTL.LBR
>  in hypervisor context to be able to dump the Last Interrupt/Exception To/From
>  record with other registers.
>  
> +### llc-coloring
> +> `= `
> +
> +> Default: `false`
> +
> +Flag to enable or disable LLC coloring support at runtime. This option is
> +available only when `CONFIG_LLC_COLORING` is enabled. See the general
> +cache coloring documentation for more info.
> +
> +### llc-nr-ways
> +> `= `
> +
> +> Default: `Obtained from hardware`
> +
> +Specify the number of ways of the Last Level Cache. This option is available
> +only when `CONFIG_LLC_COLORING` is enabled. LLC size and number of ways are used
> +to find the number of supported cache colors. By default the value is
> +automatically computed by probing the hardware, but in case of specific needs,
> +it can be manually set. Those include failing probing and debugging/testing
> +purposes so that it's possibile to emulate platforms with different number of
> +supported colors. If set, also "llc-size" must be set, otherwise the default
> +will be used.
> +
> +### llc-size
> +> `= `
> +
> +> Default: `Obtained from hardware`
> +
> +Specify the size of the Last Level Cache. This option is available only when
> +`CONFIG_LLC_COLORING` is enabled. LLC size and number of ways are used to find
> +the number of supported cache colors. By default the value is automatically
> +computed by probing the hardware, but in case of specific needs, it can be
> +manually set. Those include failing probing and debugging/testing purposes so
> +that it's possibile to emulate platforms with different number of supported
> +colors. If set, also "llc-nr-ways" must be set, otherwise the default will be
> +used.

Wouldn't it make sense to infer "llc-coloring" when both of the latter options
were supplied?

> --- a/xen/arch/Kconfig
> +++ b/xen/arch/Kconfig
> @@ -31,3 +31,23 @@ config NR_NUMA_NODES
>  	  associated with multiple-nodes management. It is the upper bound of
>  	  the number of NUMA nodes that the scheduler, memory allocation and
>  	  other NUMA-aware components can handle.
> +
> +config LLC_COLORING
> +	bool "Last Level Cache (LLC) coloring" if EXPERT
> +	depends on HAS_LLC_COLORING
> +	depends on !NUMA
> +
> +config NR_LLC_COLORS
> +	int "Maximum number of LLC colors"
> +	range 2 1024
> +	default 128
> +	depends on LLC_COLORING
> +	help
> +	  Controls the build-time size of various arrays associated with LLC
> +	  coloring. Refer to cache coloring documentation for how to compute the
> +	  number of colors supported by the platform. This is only an upper
> +	  bound. The runtime value is autocomputed or manually set via cmdline.
> +	  The default value corresponds to an 8 MiB 16-ways LLC, which should be
> +	  more than what's needed in the general case. Use only power of 2 values.

I think I said so before: Rather than telling people to pick only power-of-2
values (and it remaining unclear what happens if they don't), why don't you
simply keep them from specifying anything bogus, by having them pass in the
value to use as a power of 2? I.e. "range 1 10" and "default 7" for what
you're currently putting in place.

> +	  1024 is the number of colors that fit in a 4 KiB page when integers are 4
> +	  bytes long.

How's this relevant here? As a justification it would make sense to have in
the description.

I'm btw also not convinced this is a good place to put these options. Imo ...

> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -71,6 +71,9 @@ config HAS_IOPORTS
>  config HAS_KEXEC
>  	bool
>  
> +config HAS_LLC_COLORING
> +	bool
> +
>  config HAS_PMAP
>  	bool

... they'd better live further down from here.

> --- /dev/null
> +++ b/xen/common/llc-coloring.c
> @@ -0,0 +1,102 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Last Level Cache (LLC) coloring common code
> + *
> + * Copyright (C) 2022 Xilinx Inc.
> + */
> +#include 
> +#include 
> +#include 
> +
> +static bool __ro_after_init llc_coloring_enabled;
> +boolean_param("llc-coloring", llc_coloring_enabled);
> +
> +static unsigned int __initdata llc_size;
> +size_param("llc-size", llc_size);
> +static unsigned int __initdata llc_nr_ways;
> +integer_param("llc-nr-ways", llc_nr_ways);
> +/* Number of colors available in the LLC */
> +static unsigned int __ro_after_init max_nr_colors;
> +
> +static void print_colors(const unsigned int *colors, unsigned int num_colors)
> +{
> +    unsigned int i;
> +
> +    printk("{ ");
> +    for ( i = 0; i < num_colors; i++ )
> +    {
> +        unsigned int start = colors[i], end = start;
> +
> +        printk("%u", start);
> +
> +        for ( ; i < num_colors - 1 && end + 1 == colors[i + 1]; i++, end++ )
> +            ;
> +
> +        if ( start != end )
> +            printk("-%u", end);
> +
> +        if ( i < num_colors - 1 )
> +            printk(", ");
> +    }
> +    printk(" }\n");
> +}
> +
> +void __init llc_coloring_init(void)
> +{
> +    unsigned int way_size;
> +
> +    if ( !llc_coloring_enabled )
> +        return;
> +
> +    if ( llc_size && llc_nr_ways )
> +        way_size = llc_size / llc_nr_ways;
> +    else
> +    {
> +        way_size = get_llc_way_size();
> +        if ( !way_size )
> +            panic("LLC probing failed and 'llc-size' or 'llc-nr-ways' missing\n");
> +    }
> +
> +    /*
> +     * The maximum number of colors must be a power of 2 in order to correctly
> +     * map them to bits of an address.
> +     */
> +    max_nr_colors = way_size >> PAGE_SHIFT;
> +
> +    if ( max_nr_colors & (max_nr_colors - 1) )
> +        panic("Number of LLC colors (%u) isn't a power of 2\n", max_nr_colors);
> +
> +    if ( max_nr_colors < 2 || max_nr_colors > CONFIG_NR_LLC_COLORS )
> +        panic("Number of LLC colors (%u) not in range [2, %u]\n",
> +              max_nr_colors, CONFIG_NR_LLC_COLORS);

Rather than crashing when max_nr_colors is too large, couldn't you simply
halve it a number of times? That would still satisfy the requirement on
isolation, wouldn't it?

> +    arch_llc_coloring_init();
> +}
> +
> +void cf_check dump_llc_coloring_info(void)

I don't think cf_check is needed here nor ...

> +void cf_check domain_dump_llc_colors(const struct domain *d)

... here anymore. You're using direct calls now.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Mar 19 15:15:51 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 15:15:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695441.1085178 (Exim 4.92)
	(envelope-from )
	id 1rmbBo-0005TC-Gt; Tue, 19 Mar 2024 15:15:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695441.1085178; Tue, 19 Mar 2024 15:15:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmbBo-0005T5-Ds; Tue, 19 Mar 2024 15:15:44 +0000
Received: by outflank-mailman (input) for mailman id 695441;
 Tue, 19 Mar 2024 15:15:43 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmbBn-0005Sx-4x
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 15:15:43 +0000
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com
 [2a00:1450:4864:20::32b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8c3c2958-e603-11ee-a1ee-f123f15fe8a2;
 Tue, 19 Mar 2024 16:15:40 +0100 (CET)
Received: by mail-wm1-x32b.google.com with SMTP id
 5b1f17b1804b1-41463132ab1so6988225e9.1
 for ; Tue, 19 Mar 2024 08:15:40 -0700 (PDT)
Received: from localhost.localdomain
 (cpc92320-cmbg19-2-0-cust35.5-4.cable.virginm.net. [82.13.64.36])
 by smtp.gmail.com with ESMTPSA id
 bw11-20020a0560001f8b00b0033e7a204dc7sm1958672wrb.32.2024.03.19.08.15.38
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 19 Mar 2024 08:15:39 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8c3c2958-e603-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710861340; x=1711466140; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:from:to:cc:subject:date:message-id:reply-to;
        bh=3BiG0UhNIs2usMao99OGoLhSPN2huqVq8x8SIKyBwiU=;
        b=GL0jX7AVAqe0drXeKotsOtZzgO89TA31UcxtdHzc/lmu9xnfY7kj9ILEJjH6UTA0v3
         tVHCDp12ksbEiGknped8aQsfr38OYB5WN86rm8Io7LGQ33DrHX3PD8k1VsvYcw9adIca
         eKDUtBUlar3ZdHYkQai2Ei/V035v2IdkwiD7E=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710861340; x=1711466140;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=3BiG0UhNIs2usMao99OGoLhSPN2huqVq8x8SIKyBwiU=;
        b=mAtDqGzgAZPOA/GN8KUlK5Fa+eF1i3YfOgCwazUDjag0kKeI7GOGUCshXrBnoUylEo
         OWdMNPODWSKvKuMpw/YV08BjW99XUYDG2JB2OtiBYREf9XTkd0Ny32hAKxnMSidMnh/J
         89nngGfXa/syt0uLQJj3xihwDDwI7UFn335S14sUs0YGZlkiab2o2GN1nVRiXYndAPAN
         YlOjS9eVhP2XxRCU6Ff+/bVtzNqyjS3LF89X27XBI91xkTRshuGpupSPBaKxrM++dRWj
         HP7yxDUiEkQUld+V6mFuD5fqpta01qv/WlBZhXrHweb94CphSHf9R2cqCzTA8rSFXFlV
         jwPg==
X-Gm-Message-State: AOJu0YyGBwVQ6RuN0J/IS5YpZyQW/FF2/t81R9t5ljMJMpxQdPUGzwDz
	J44OzByeNlkq3D6mVjQI1v6otdLiUfyuhXsKNzfM89dSTLOK/okef6ZX//nZGvH2EOtoigCu9jp
	S
X-Google-Smtp-Source: AGHT+IFRuUeHTWVi5QdQLzXq7JuucKwHi/eLfywf0g3ysnSUEwEm3tp81Li9K/tBKQw1u8qchVortQ==
X-Received: by 2002:a05:600c:474c:b0:414:c42:e114 with SMTP id w12-20020a05600c474c00b004140c42e114mr5648183wmo.39.1710861340135;
        Tue, 19 Mar 2024 08:15:40 -0700 (PDT)
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: Julien Grall ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Stefano Stabellini 
Subject: [XEN PATCH] docs/parse-support-md: Handle BulletList
Date: Tue, 19 Mar 2024 15:15:09 +0000
Message-Id: <20240319151509.8937-1-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.39.2
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Commit d638e304f13a introduced a bullet list, but parse-support-md
choke on it as it doesn't know what to do about it.

Introduce ri_BulletList() so that r_content() will find this new
function and call it instead of calling process_unknown().

Reported-by: Julien Grall 
Fixes: d638e304f13a ("SUPPORT.MD: Fix matrix generation after 43c416d0d819 and 77c39a53cf5b")
Signed-off-by: Anthony PERARD 
---
 docs/parse-support-md | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/docs/parse-support-md b/docs/parse-support-md
index a397637639..b04f62da37 100755
--- a/docs/parse-support-md
+++ b/docs/parse-support-md
@@ -218,6 +218,13 @@ sub ri_DefinitionList {
     }
 }
 
+sub ri_BulletList {
+    # Assume a paragraph introduce this bullet list, which would mean that
+    # ri_Para() has already been called, and there's nothing else to do about
+    # the caveat.
+    return;
+}
+
 sub process_unknown {
     my ($c, $e) = @_;
     $had_unknown = Dumper($e);
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Tue Mar 19 15:31:02 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 15:31:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695445.1085188 (Exim 4.92)
	(envelope-from )
	id 1rmbQW-0000hY-PJ; Tue, 19 Mar 2024 15:30:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695445.1085188; Tue, 19 Mar 2024 15:30:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmbQW-0000hR-L7; Tue, 19 Mar 2024 15:30:56 +0000
Received: by outflank-mailman (input) for mailman id 695445;
 Tue, 19 Mar 2024 15:30:55 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmbQV-0000hI-9q
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 15:30:55 +0000
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com
 [2a00:1450:4864:20::535])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ac663525-e605-11ee-afdd-a90da7624cb6;
 Tue, 19 Mar 2024 16:30:53 +0100 (CET)
Received: by mail-ed1-x535.google.com with SMTP id
 4fb4d7f45d1cf-565c6cf4819so11592299a12.1
 for ; Tue, 19 Mar 2024 08:30:53 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a4-20020a170906368400b00a44936527b5sm6254121ejc.99.2024.03.19.08.30.52
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 19 Mar 2024 08:30:53 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ac663525-e605-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710862253; x=1711467053; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=9GKHkOjeZtheQAllbQFw4GKbVr65ZyXVC0TxSA7tP14=;
        b=d0B/nS7eAe//p2is8r5kF7zZGvP3tydIbH0aj6EK7dHnrSFPQs+euti83Ih/UVUFgG
         Hje2CnMJx9bKwqa83XV9520dybpN4dmPGf4JhVQzgpIPVQbuS/J9yBrfuw31OTZHO4Z6
         TB8IF259M4tO1D3YHMxlLcsqgz0h/PwFzPbN2oA9R0oEbg3kibQ3odIgPpAYPnzY0BI4
         1kdmK4ca0jpSmaNyCsgXE/YBQ+d5j8tySih7Z2zA0cHP+gDoFtC7BfuABtOLnH+6JTuB
         52bhfjy/h10YGNJg7DJwn9Ni41EaK93v7XzcLZQcc/95XRpPwGhh3ItbbfdjZ2SquQed
         oM5w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710862253; x=1711467053;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=9GKHkOjeZtheQAllbQFw4GKbVr65ZyXVC0TxSA7tP14=;
        b=UmpF9EdVUR88TBGw2z6gJw7Wsm1GMS5bhiwaAlM64Zv32JGM9MH9uWoiBvuXHPp9Ir
         YY+oDI3CgD+OBmmrNsIcwojbaQOQzl1ICOYfxKWSvqPqzq2syAH5IitWFGn8Q2IDTlCU
         jlzPP48Hz1O5+Co+cYmYB7RsmqfGkK5RjpzS+AJo2P+HO9NsvnjBq8xqEMVb9otKQDnR
         AU4UG5Kx9ALVBoNK+H6Bd+xgPnouwp4JyufriZzScqKVrXDezJzF7Xbbyv0U8/aRiS8T
         rHKd97lpX8p2+kSDG7nqi9GLf8GsvocujYw9WuwSB/w0H967WmvaI2vhgA2Dh0RHbVl8
         0BKg==
X-Forwarded-Encrypted: i=1; AJvYcCVDcEkLPponzdclH687ti7loqeBHY1lZ0gcFEhIQYljBzkw9weqSpzq2h/1QPLzMjCqz0AB7JaUPkZlW+4YMBLgGbpgpn+LwYKuUK/36Cc=
X-Gm-Message-State: AOJu0YyyzD29h/xPuPbALFCGJv5+hKMzvDcKtiHpTnMIJuiSj8ovr8qf
	ljjlKh2JGehS920KrKkDN1/lXGyvEaDI55x0x0XWH4U8Zzy9P+yOLOmv6jLPhA==
X-Google-Smtp-Source: AGHT+IEWmEb8X07JYPIvvrEm0fbTx2wYusvxHfRGZcorgvirUaZPzVE890C/A/L85ue5apze12Dqew==
X-Received: by 2002:a17:906:7314:b0:a46:bdfe:225b with SMTP id di20-20020a170906731400b00a46bdfe225bmr3436712ejc.11.1710862253276;
        Tue, 19 Mar 2024 08:30:53 -0700 (PDT)
Message-ID: 
Date: Tue, 19 Mar 2024 16:30:52 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 04/14] xen/arm: add Dom0 cache coloring support
Content-Language: en-US
To: Carlo Nonato 
Cc: Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Marco Solieri , xen-devel@lists.xenproject.org
References: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
 <20240315105902.160047-5-carlo.nonato@minervasys.tech>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240315105902.160047-5-carlo.nonato@minervasys.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 15.03.2024 11:58, Carlo Nonato wrote:
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -963,6 +963,15 @@ Controls for the dom0 IOMMU setup.
>  
>  Specify a list of IO ports to be excluded from dom0 access.
>  
> +### dom0-llc-colors
> +> `= List of [  | - ]`
> +
> +> Default: `All available LLC colors`
> +
> +Specify dom0 LLC color configuration. This option is available only when
> +`CONFIG_LLC_COLORING` is enabled. If the parameter is not set, all available
> +colors are used.

My reservation towards this being a top-level option remains.

> --- a/xen/common/llc-coloring.c
> +++ b/xen/common/llc-coloring.c
> @@ -18,6 +18,63 @@ integer_param("llc-nr-ways", llc_nr_ways);
>  /* Number of colors available in the LLC */
>  static unsigned int __ro_after_init max_nr_colors;
>  
> +static unsigned int __initdata dom0_colors[CONFIG_NR_LLC_COLORS];
> +static unsigned int __initdata dom0_num_colors;
> +
> +/*
> + * Parse the coloring configuration given in the buf string, following the
> + * syntax below.
> + *
> + * COLOR_CONFIGURATION ::= COLOR | RANGE,...,COLOR | RANGE
> + * RANGE               ::= COLOR-COLOR
> + *
> + * Example: "0,2-6,15-16" represents the set of colors: 0,2,3,4,5,6,15,16.
> + */
> +static int __init parse_color_config(const char *buf, unsigned int *colors,
> +                                     unsigned int max_num_colors,
> +                                     unsigned int *num_colors)
> +{
> +    const char *s = buf;
> +
> +    *num_colors = 0;
> +
> +    while ( *s != '\0' )
> +    {
> +        unsigned int color, start, end;
> +
> +        start = simple_strtoul(s, &s, 0);
> +
> +        if ( *s == '-' )    /* Range */
> +        {
> +            s++;
> +            end = simple_strtoul(s, &s, 0);
> +        }
> +        else                /* Single value */
> +            end = start;
> +
> +        if ( start > end || (end - start) > (UINT_MAX - *num_colors) ||
> +             (*num_colors + (end - start)) >= max_num_colors )
> +            return -EINVAL;
> +
> +        for ( color = start; color <= end; color++ )
> +            colors[(*num_colors)++] = color;

I can't spot any range check on start/end/color itself. In fact I was first
meaning to ask why the return value of simple_strtoul() is silently clipped
from unsigned long to unsigned int. Don't forget that a range specification
may easily degenerate into a negative number (due to a simple oversight or
typo), which would then be converted to a huge positive one.

> @@ -41,6 +98,22 @@ static void print_colors(const unsigned int *colors, unsigned int num_colors)
>      printk(" }\n");
>  }
>  
> +static bool check_colors(const unsigned int *colors, unsigned int num_colors)
> +{
> +    unsigned int i;
> +
> +    for ( i = 0; i < num_colors; i++ )
> +    {
> +        if ( colors[i] >= max_nr_colors )
> +        {
> +            printk(XENLOG_ERR "LLC color %u >= %u\n", colors[i], max_nr_colors);
> +            return false;
> +        }
> +    }
> +
> +    return true;
> +}

Oh, here's the range checking of the color values themselves. Perhaps
a comment in parse_color_config() would help.

> @@ -91,6 +164,61 @@ void cf_check domain_dump_llc_colors(const struct domain *d)
>      print_colors(d->llc_colors, d->num_llc_colors);
>  }
>  
> +static int domain_set_default_colors(struct domain *d)
> +{
> +    unsigned int *colors = xmalloc_array(unsigned int, max_nr_colors);
> +    unsigned int i;
> +
> +    if ( !colors )
> +        return -ENOMEM;
> +
> +    printk(XENLOG_WARNING
> +           "LLC color config not found for %pd, using all colors\n", d);
> +
> +    for ( i = 0; i < max_nr_colors; i++ )
> +        colors[i] = i;
> +
> +    d->llc_colors = colors;
> +    d->num_llc_colors = max_nr_colors;
> +
> +    return 0;
> +}

If this function is expected to actually come into play, wouldn't it
make sense to set up such an array just once, and re-use it wherever
necessary?

Also right here both this and check_colors() could be __init. I
understand that subsequent patches will also want to use the
functions at runtime, but until then this looks slightly wrong. I'd
like to ask that such aspects be mentioned in the description, to
avoid respective questions.

> +int __init dom0_set_llc_colors(struct domain *d)
> +{
> +    unsigned int *colors;
> +
> +    if ( !dom0_num_colors )
> +        return domain_set_default_colors(d);
> +
> +    if ( !check_colors(dom0_colors, dom0_num_colors) )
> +    {
> +        printk(XENLOG_ERR "Bad LLC color config for %pd\n", d);
> +        return -EINVAL;
> +    }
> +
> +    colors = xmalloc_array(unsigned int, dom0_num_colors);
> +    if ( !colors )
> +        return -ENOMEM;
> +
> +    /* Static type checking */
> +    (void)(colors == dom0_colors);

Btw, a means to avoid this would by to use typeof() in the declaration
of "colors".

Jan


From xen-devel-bounces@lists.xenproject.org Tue Mar 19 15:37:12 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 15:37:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695449.1085197 (Exim 4.92)
	(envelope-from )
	id 1rmbWW-0001Mp-Gl; Tue, 19 Mar 2024 15:37:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695449.1085197; Tue, 19 Mar 2024 15:37:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmbWW-0001Mi-Dq; Tue, 19 Mar 2024 15:37:08 +0000
Received: by outflank-mailman (input) for mailman id 695449;
 Tue, 19 Mar 2024 15:37:06 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmbWU-0001Mc-Ln
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 15:37:06 +0000
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com
 [2a00:1450:4864:20::62f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8a11de87-e606-11ee-afdd-a90da7624cb6;
 Tue, 19 Mar 2024 16:37:05 +0100 (CET)
Received: by mail-ej1-x62f.google.com with SMTP id
 a640c23a62f3a-a46aaf6081fso416531966b.2
 for ; Tue, 19 Mar 2024 08:37:05 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 z10-20020a170906714a00b00a46c39e6a47sm2216558ejj.148.2024.03.19.08.37.04
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 19 Mar 2024 08:37:05 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8a11de87-e606-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710862625; x=1711467425; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=yxmMfJKep6cdOjOBXJ+1uQB48ZQiNW+XkVD5iLhBlvI=;
        b=ZeEZD3qTsODZWKNoxW15M4sQVNcMoLFCyALySSvoJ+4H/co0+BiN842poMolA0Km2H
         AxzmBemuiA3ag+jxIv+VsNeF4ApmISaGheeIkE8WRWvkVPcsqHtJH/cgc7Wnj68anhYw
         F+RLNoE5RwWe4X2pBIgS4/ZAsGYZlwzkZVpTvBJjzBxdRrhZ4yU1ddy1oEaHdtxF2j5P
         3t5vFmCAP1CaPOii6rFgZQ/3T6iAg1lnBngXPW+1EI4dBQCTdiGboMAqok9DMdeXjyDU
         +kqhZHcOfDP/nIwO2xcoqF9E4nixQUIXI61Ct16TVuJ5hs1QUDYeZneVeSPhDjvdK0uF
         qm5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710862625; x=1711467425;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=yxmMfJKep6cdOjOBXJ+1uQB48ZQiNW+XkVD5iLhBlvI=;
        b=QYh96hJXYv0PRUdnT73Nnj6y897FLsCOeW3ZuDs4fnNKYPTZfVjM78y1rVIHnBxLf3
         vemSLy0fB82oXbL3BrCQC3AHKjiv2aWBSa3kX/85d0ipNuLta5fORsOuW0XV0LGnFMuk
         SqKuBKqoy+cIkZSTV+H/rH4eHDHOqkQF6p+h9wJD/4rJjdpLPf4XtOUI4eSI3zBjL5HQ
         1X4//UCjiM28zYBcQPfs9tnfpcK3+JM3oiZuwT0cuSUitqgRJrIzBKk5urnyiwvBu4O0
         0jPEc9i0YsHStbBirgutNP+istEV+oxMRfkrTrUgEwJSWBsjAYwmIY3wbfXhXJTIspus
         tWlw==
X-Forwarded-Encrypted: i=1; AJvYcCUBprV9C9qr0yaJq92crLNoI/oTKnq6zo+/VAZD6k2pEda0cfzwFiUZwGYwWfsJlhDTUJl0tV0bMEdtYR6ePIucexj9mreI3kUPox5EjwA=
X-Gm-Message-State: AOJu0Yw+Z2hzqu2Paf0e0UPtQm25+9edqc3fwAN5ruvUAWBi8qG+RH4a
	qjEnEKM8QRUSYMByBGhKng8WD3mNLM5Kr5us5JzuCZ9JpH13FlA8jAk0YbUsCA==
X-Google-Smtp-Source: AGHT+IHPpVabhpNCjDg5DU/0rCIbUF3xWyMJkyAs0KvhE5DgDzT8gFmkEUCuy9pCDQ90Z6bO09FdSg==
X-Received: by 2002:a17:906:2310:b0:a46:9681:9811 with SMTP id l16-20020a170906231000b00a4696819811mr2052467eja.33.1710862625217;
        Tue, 19 Mar 2024 08:37:05 -0700 (PDT)
Message-ID: 
Date: Tue, 19 Mar 2024 16:37:03 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 05/14] xen: extend domctl interface for cache coloring
Content-Language: en-US
To: Carlo Nonato 
Cc: Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 Marco Solieri , xen-devel@lists.xenproject.org
References: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
 <20240315105902.160047-6-carlo.nonato@minervasys.tech>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240315105902.160047-6-carlo.nonato@minervasys.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 15.03.2024 11:58, Carlo Nonato wrote:
> @@ -219,6 +220,39 @@ void domain_llc_coloring_free(struct domain *d)
>      xfree(__va(__pa(d->llc_colors)));
>  }
>  
> +int domain_set_llc_colors(struct domain *d,
> +                          const struct xen_domctl_set_llc_colors *config)
> +{
> +    unsigned int *colors;
> +
> +    if ( d->num_llc_colors )
> +        return -EEXIST;
> +
> +    if ( !config->num_llc_colors )
> +        return domain_set_default_colors(d);
> +
> +    if ( config->num_llc_colors > max_nr_colors || config->pad )

The check of "pad" wants carrying out in all cases; I expect it wants
moving to the caller.

> +        return -EINVAL;
> +
> +    colors = xmalloc_array(unsigned int, config->num_llc_colors);
> +    if ( !colors )
> +        return -ENOMEM;
> +
> +    if ( copy_from_guest(colors, config->llc_colors, config->num_llc_colors) )
> +        return -EFAULT;

You're leaking "colors" when taking this or ...

> +    if ( !check_colors(colors, config->num_llc_colors) )
> +    {
> +        printk(XENLOG_ERR "Bad LLC color config for %pd\n", d);
> +        return -EINVAL;

... this error path.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Mar 19 15:41:14 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 15:41:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695451.1085208 (Exim 4.92)
	(envelope-from )
	id 1rmbaS-0003P3-0K; Tue, 19 Mar 2024 15:41:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695451.1085208; Tue, 19 Mar 2024 15:41:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmbaR-0003Ow-Tz; Tue, 19 Mar 2024 15:41:11 +0000
Received: by outflank-mailman (input) for mailman id 695451;
 Tue, 19 Mar 2024 15:41:10 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmbaQ-0003Oq-BC
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 15:41:10 +0000
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com
 [2a00:1450:4864:20::535])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1b3d610f-e607-11ee-afdd-a90da7624cb6;
 Tue, 19 Mar 2024 16:41:09 +0100 (CET)
Received: by mail-ed1-x535.google.com with SMTP id
 4fb4d7f45d1cf-563bb51c36eso6668767a12.2
 for ; Tue, 19 Mar 2024 08:41:09 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 cn25-20020a0564020cb900b00568c3a2f4f8sm3648492edb.74.2024.03.19.08.41.08
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 19 Mar 2024 08:41:08 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1b3d610f-e607-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710862869; x=1711467669; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=5QuJiuZejgGbVVW4I7TxfPxzbgWfyKHNf+/xElfOkWk=;
        b=TutcFcM7pP6+47IXlKAYso8CY6iLL4p8EWYb5B4tRLHqkQzI64onRi9RZ70ATTmcpS
         8wiQiO5cjsTtvdLiY1L+7ZaIhPiKlNLRMfJv3Nhypb7m6h6w07Dfg87A2Mz1bnixGYgJ
         KV1MYV2pq2fhaGwL0c1isO1kINPJXJCYb9mcR6HKGeM2Lt3hCMLrHHx7fWGrMWWTSSbm
         VJdqsJswB5+XkrLaE+i8vtgJQ9cBzvCOT2ldRWdtSPeRxvAQ9POgUcf6MHYsK0hbUg7O
         ILIFoWTPOHRGAz3CFNztI4puEgiuc9hzf5rNDX/L4XIDmfr6NyKIPGmR/2ba56fwGFTA
         W6Xg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710862869; x=1711467669;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=5QuJiuZejgGbVVW4I7TxfPxzbgWfyKHNf+/xElfOkWk=;
        b=FdIXPyRyHyTL6WziFdXPFyjF/JU2UUGTlda0/3whjx9dYiYjSGt1Ly/Qh9SZ6m9E5I
         vRsWNHglJXxYoY6sL6BUWCkyjx6lAXhGJKmkTPEkF4CmZ8XlFQpWAtwVMu/kNFmgRYiV
         DgGegu/QO/8ZIQhdAucDYyMKanNkx5VWmXqPK9rxWM9DzB1Kn/NYWzb9fnPMVK0XEenw
         n2g+Gxjxb2jQNVNOv6WBvXn0j8mygDPdoFffGhEar+HyRjyZ72CPiv42nWb1MXlJHBfd
         6n7nE4sJU+eEnex7AXerSgVJSWS1pn6ZYww9LUAdu1qtzmNH8RJAt3RMSCu9jpFTj80k
         ionQ==
X-Forwarded-Encrypted: i=1; AJvYcCX5gRbuqKqBp2eiK7iqdZ2VR97Z/o0uiRgxv5MB/uoFybQ2++tMq1f8OFFZHslat8JMP3vUHzxfgXIFUrvA7T0SeTYwgIydcMdmw0q63UU=
X-Gm-Message-State: AOJu0Yy0Jka3A0ZRU8qG9iYdQ11IdHxZlQNu0jEN9eeaSG0FlUbH+rWT
	NhRu09TrXLLBgced+TZ6JsigMxtftQKofryJ1AsZtVyRCHzPMrj5FscZBK6YuQ==
X-Google-Smtp-Source: AGHT+IGYopEIA0RUKNyFYfgZ0p5xnnwkf23XGKeuXf36RWrKhRxybHMhHZesmI9kdDty+RKeMTDGRQ==
X-Received: by 2002:a05:6402:3604:b0:568:fb58:bc50 with SMTP id el4-20020a056402360400b00568fb58bc50mr2065098edb.25.1710862868742;
        Tue, 19 Mar 2024 08:41:08 -0700 (PDT)
Message-ID: <8194d91a-a71a-44f2-a498-61297ac2ee29@suse.com>
Date: Tue, 19 Mar 2024 16:41:07 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 07/14] xen/arm: add support for cache coloring
 configuration via device-tree
Content-Language: en-US
To: Carlo Nonato 
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 George Dunlap , Wei Liu ,
 Marco Solieri , xen-devel@lists.xenproject.org
References: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
 <20240315105902.160047-8-carlo.nonato@minervasys.tech>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240315105902.160047-8-carlo.nonato@minervasys.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 15.03.2024 11:58, Carlo Nonato wrote:
> --- a/xen/common/llc-coloring.c
> +++ b/xen/common/llc-coloring.c
> @@ -253,6 +253,37 @@ int domain_set_llc_colors(struct domain *d,
>      return 0;
>  }
>  
> +int __init domain_set_llc_colors_from_str(struct domain *d, const char *str)
> +{
> +    int err;
> +    unsigned int *colors, num_colors;
> +
> +    if ( !str )
> +        return domain_set_default_colors(d);
> +
> +    colors = xmalloc_array(unsigned int, max_nr_colors);
> +    if ( !colors )
> +        return -ENOMEM;
> +
> +    err = parse_color_config(str, colors, max_nr_colors, &num_colors);
> +    if ( err )
> +    {
> +        printk(XENLOG_ERR "Error parsing LLC color configuration");
> +        return err;
> +    }
> +
> +    if ( !check_colors(colors, num_colors) )
> +    {
> +        printk(XENLOG_ERR "Bad LLC color config for %pd\n", d);
> +        return -EINVAL;
> +    }

"colors" is again leaked on the error paths.

> +    d->llc_colors = colors;
> +    d->num_llc_colors = num_colors;

num_colors may be quite a bit smaller than max_nr_colors; worth re-
allocating the array to free up excess space?

Jan


From xen-devel-bounces@lists.xenproject.org Tue Mar 19 15:45:18 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 15:45:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695455.1085217 (Exim 4.92)
	(envelope-from )
	id 1rmbeL-0003zj-F0; Tue, 19 Mar 2024 15:45:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695455.1085217; Tue, 19 Mar 2024 15:45:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmbeL-0003zc-C9; Tue, 19 Mar 2024 15:45:13 +0000
Received: by outflank-mailman (input) for mailman id 695455;
 Tue, 19 Mar 2024 15:45:12 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmbeJ-0003zW-Vv
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 15:45:11 +0000
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com
 [2a00:1450:4864:20::529])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ab3dc132-e607-11ee-afdd-a90da7624cb6;
 Tue, 19 Mar 2024 16:45:10 +0100 (CET)
Received: by mail-ed1-x529.google.com with SMTP id
 4fb4d7f45d1cf-563c403719cso6974782a12.2
 for ; Tue, 19 Mar 2024 08:45:10 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ij11-20020a056402158b00b005688450c264sm5892611edb.91.2024.03.19.08.45.09
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 19 Mar 2024 08:45:10 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ab3dc132-e607-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710863110; x=1711467910; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=AXm82f/41fQJPFkPWTE5+4k70f5QuF7qFPegW52LF9s=;
        b=JPz8+C/2JUOp6Z1UjMexV7rGOVVMLS4qiTjQvz80NXn7liEmCCYc0gVpfjlCPl81vt
         K/aRQqBjyLCa7Lk9RA1V/hD4iIKwIzBxX26d1U0n6qDCnzWHvHw8eu/xol/C9mdLYyg9
         r72zn3KcFddbAPnTgDC+eFQc85moEafgQOgLOIpnH3PP/Hcx4PbjyLixIHEIt627IMN3
         rkyWcPjGpxc2GYA3waZppNQqHq/brz5rsybeRaKZlnB30h2B/q0wFpYvsUO/PtC4lEsi
         aJzevdb+K/p8rVqU8VwH1sl9h/FDBG7GVk6XPb3E1YRbgQ/hfinTfYosX+fbu3H5xfxO
         Nw+g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710863110; x=1711467910;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=AXm82f/41fQJPFkPWTE5+4k70f5QuF7qFPegW52LF9s=;
        b=DM1opTiRT2Wf1vxePa0qWRK4LdFTakW+pF0y0zf6fWEFiP3N782XxoFMYfHQ8mAtY6
         elTT1GEgi1T6cUMRYT9fe0gPHoAqCv2XBpT5n5ad4JwvvDmvePFu7l1PKLleltuKM7fw
         IbpBy2mKvwJzB43ugTzmQbHMX09ollbxs2phILGsOcNjvnOEnpUVq0fAinklMldwTlbx
         WpW2ZAfr9CiEt3se9WQDx0pzQx16BojdEchCGdsX3sTysHItLpWqulT+1Lo+2HWV5EIS
         Yznk92OVi8r4D/7tmne6hgOg/CFAtbJobgOi5g/IlOKk4cbO9evf2jn7ApdkS8ZtA1X/
         m+3A==
X-Forwarded-Encrypted: i=1; AJvYcCX6rwYfRFexPcCjXSWHosirB5dND46rm7N0e01CtRsMEmPgFMAm5/NO7wsi7Gbix8dZ921YcLNXO0Icsbwc7Lz4+Y4AeVRCCd/PKlLv2fo=
X-Gm-Message-State: AOJu0YyqPOcNgLis9PuvbLaui4VTnINuJ0k1wgexRC+kZ6Hl7bOoOJPN
	GBIj5BW1DHhl6lHjETrW9YrRWxTwPDMM99I/jAAy/iiMNSKvJUL4BAhe9LMnkQ==
X-Google-Smtp-Source: AGHT+IHRMJ5WoTQMcGBIYXnf4ljl/QW+q8PlaK1fdoY9TaeLlfCql04BJrThLogAFWQAoZXhKRSNog==
X-Received: by 2002:a05:6402:e10:b0:568:949b:e91f with SMTP id h16-20020a0564020e1000b00568949be91fmr11933713edh.36.1710863110299;
        Tue, 19 Mar 2024 08:45:10 -0700 (PDT)
Message-ID: 
Date: Tue, 19 Mar 2024 16:45:08 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 04/14] xen/arm: add Dom0 cache coloring support
Content-Language: en-US
To: Carlo Nonato 
Cc: Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Marco Solieri , xen-devel@lists.xenproject.org
References: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
 <20240315105902.160047-5-carlo.nonato@minervasys.tech>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240315105902.160047-5-carlo.nonato@minervasys.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 15.03.2024 11:58, Carlo Nonato wrote:
> --- a/xen/common/llc-coloring.c
> +++ b/xen/common/llc-coloring.c
> @@ -18,6 +18,63 @@ integer_param("llc-nr-ways", llc_nr_ways);
>  /* Number of colors available in the LLC */
>  static unsigned int __ro_after_init max_nr_colors;
>  
> +static unsigned int __initdata dom0_colors[CONFIG_NR_LLC_COLORS];
> +static unsigned int __initdata dom0_num_colors;
> +
> +/*
> + * Parse the coloring configuration given in the buf string, following the
> + * syntax below.
> + *
> + * COLOR_CONFIGURATION ::= COLOR | RANGE,...,COLOR | RANGE
> + * RANGE               ::= COLOR-COLOR
> + *
> + * Example: "0,2-6,15-16" represents the set of colors: 0,2,3,4,5,6,15,16.
> + */
> +static int __init parse_color_config(const char *buf, unsigned int *colors,
> +                                     unsigned int max_num_colors,
> +                                     unsigned int *num_colors)
> +{
> +    const char *s = buf;
> +
> +    *num_colors = 0;
> +
> +    while ( *s != '\0' )
> +    {
> +        unsigned int color, start, end;
> +
> +        start = simple_strtoul(s, &s, 0);
> +
> +        if ( *s == '-' )    /* Range */
> +        {
> +            s++;
> +            end = simple_strtoul(s, &s, 0);
> +        }
> +        else                /* Single value */
> +            end = start;
> +
> +        if ( start > end || (end - start) > (UINT_MAX - *num_colors) ||
> +             (*num_colors + (end - start)) >= max_num_colors )
> +            return -EINVAL;
> +
> +        for ( color = start; color <= end; color++ )
> +            colors[(*num_colors)++] = color;
> +
> +        if ( *s == ',' )
> +            s++;
> +        else if ( *s != '\0' )
> +            break;
> +    }
> +
> +    return *s ? -EINVAL : 0;
> +}
> +
> +static int __init parse_dom0_colors(const char *s)
> +{
> +    return parse_color_config(s, dom0_colors, ARRAY_SIZE(dom0_colors),

With it not being possible to pass max_nr_colors here (due to the value
not having been established yet), don't you need to check somewhere else
that ...

> +                              &dom0_num_colors);

... dom0_num_colors isn't too large?

Jan


From xen-devel-bounces@lists.xenproject.org Tue Mar 19 15:47:08 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 15:47:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695458.1085228 (Exim 4.92)
	(envelope-from )
	id 1rmbg9-0004Xf-Rj; Tue, 19 Mar 2024 15:47:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695458.1085228; Tue, 19 Mar 2024 15:47:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmbg9-0004XY-NZ; Tue, 19 Mar 2024 15:47:05 +0000
Received: by outflank-mailman (input) for mailman id 695458;
 Tue, 19 Mar 2024 15:47:05 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmbg9-0004X0-8N
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 15:47:05 +0000
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com
 [2a00:1450:4864:20::52a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ef25eecb-e607-11ee-afdd-a90da7624cb6;
 Tue, 19 Mar 2024 16:47:04 +0100 (CET)
Received: by mail-ed1-x52a.google.com with SMTP id
 4fb4d7f45d1cf-563bb51c36eso6677625a12.2
 for ; Tue, 19 Mar 2024 08:47:04 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 n8-20020aa7c788000000b00568d7b0a21csm2658326eds.61.2024.03.19.08.47.03
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 19 Mar 2024 08:47:04 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ef25eecb-e607-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710863224; x=1711468024; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=Dmu57qOCURrF2Or+9P0KP0qRJFn8qN3UEakHtXqfjX4=;
        b=UFgz2+Pot8ETF8V++FmJJu9TIq1Bh380KoHx4pOjsc7lZHKDvGJOiQ4rg8Fuzi94Yu
         iG6516sxUeI8FJBGGcHzULt0u2cJbXHukjGOZ9KC+K0bcDpyLpm2ujgdZPl7JuZ56KrG
         CTlbHXkv6CtbuhljQB4oN92pc4NyGNlMoTM0KjfKIMcopRVk+OvW0q0Cr0SFDZwD+DTl
         GGFfU6oglKyh5wvsikv6yPsShM43/tW7m2VIxz9+OyeUS7JBXT/tsF6nHmfjdOOs+cHJ
         8tUY4Y5FyswarWDT7SHdvRdiHL81lsZub3LQu4Rmlm2R055v2ENPQ/SiFXqNZNnzbI53
         g/iA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710863224; x=1711468024;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=Dmu57qOCURrF2Or+9P0KP0qRJFn8qN3UEakHtXqfjX4=;
        b=fS5TK605CUBlS036zTT3ppFcLCOJuym3BkC4OJ7AFYH+476ZV2WHgFQuAXwB2/cgMS
         T/EkJV5RvWMaEDSttqg03UJNGmEOtc7N7w44Rh4+/cbGJU8qybqMFJlNeFbed6cNJUjW
         mkn49WMPiOcEjNeaq7SMlg9dOR3+XWgUFKFoZ3ZvHknManw1aYo1qUJUqBg2GuBgzA71
         aGK09ZdmDM1G6H9wrsp9K2EF1n0QXencSfnhaiS42GMyx0DfX07f2t/tAmDDWsSixxjd
         2/56tijy/frpmaBmghYG8ULHM6s3kVM85ozEKaYQPj+b2jjhUg8PjnzKwgA6/pxMUA1d
         kveA==
X-Forwarded-Encrypted: i=1; AJvYcCUH62UkSLGvdQFObZBCuWgRUFjWxy/TtgqjkNGyO2+BJoGsOdat52iWzpKf9LCjcDgnM0tLT6J/GIRP1YH3bl2VHBemKMNOvKQf4H5e1GA=
X-Gm-Message-State: AOJu0YzVOMhYI2HQYJ1gY4SZhUI/uKYgL0oLf1FCcmHs968Lha7iHDP5
	DRjW+gSAjnn3NcTIgkJ9O78oXEdfVNRpfOMFMXxHnKNpb+8dQhHZAcTMCeZ2Jw==
X-Google-Smtp-Source: AGHT+IF10x037VIX4G5h3iEg38RKQHYLQdOZp4Ud8Af+KnYgkYpnN/Ew+iEa0FVFyfuMmco9NeSn2Q==
X-Received: by 2002:a05:6402:28cf:b0:568:cdd8:cf60 with SMTP id ef15-20020a05640228cf00b00568cdd8cf60mr2478291edb.8.1710863224278;
        Tue, 19 Mar 2024 08:47:04 -0700 (PDT)
Message-ID: <601540e3-c3c1-4dfc-98f5-aac846ab5d59@suse.com>
Date: Tue, 19 Mar 2024 16:47:03 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 08/14] xen/page_alloc: introduce preserved page flags
 macro
Content-Language: en-US
To: Carlo Nonato 
Cc: Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 xen-devel@lists.xenproject.org
References: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
 <20240315105902.160047-9-carlo.nonato@minervasys.tech>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240315105902.160047-9-carlo.nonato@minervasys.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 15.03.2024 11:58, Carlo Nonato wrote:
> PGC_static and PGC_extra needs to be preserved when assigning a page.
> Define a new macro that groups those flags and use it instead of or'ing
> every time.
> 
> To make preserved flags even more meaningful, they are kept also when
> switching state in mark_page_free().
> 
> Signed-off-by: Carlo Nonato 

Reviewed-by: Jan Beulich 




From xen-devel-bounces@lists.xenproject.org Tue Mar 19 15:49:51 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 15:49:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695461.1085238 (Exim 4.92)
	(envelope-from )
	id 1rmbig-0005kK-7P; Tue, 19 Mar 2024 15:49:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695461.1085238; Tue, 19 Mar 2024 15:49:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmbig-0005kD-46; Tue, 19 Mar 2024 15:49:42 +0000
Received: by outflank-mailman (input) for mailman id 695461;
 Tue, 19 Mar 2024 15:49:41 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmbif-0005k7-6K
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 15:49:41 +0000
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com
 [2a00:1450:4864:20::22c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4be009b2-e608-11ee-afdd-a90da7624cb6;
 Tue, 19 Mar 2024 16:49:40 +0100 (CET)
Received: by mail-lj1-x22c.google.com with SMTP id
 38308e7fff4ca-2d41d1bedc9so100718831fa.3
 for ; Tue, 19 Mar 2024 08:49:40 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 i22-20020a17090671d600b00a46d58fbc11sm1311805ejk.118.2024.03.19.08.49.39
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 19 Mar 2024 08:49:39 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4be009b2-e608-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710863380; x=1711468180; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=Z/Hjek9M5u6PXnQB/xTWo90Ep+NkhvngSyuPpPAmfQA=;
        b=P7fM/Yk2dnHj6h5dIZUCLRpQAdCTH4/EcVSrVrP4bVdGkFSWiB0QmpAUS/kp9QT28S
         BlxtdNXyITKBbp3iC6JyDuEq1UDDsEKopD8sIXFSbKOWDP9mZPbSwFN1zdjTtYKYWBic
         YuaRLEpeNaALRHx9wzqY0pqmdMvzYHyAa1fcxVKE/nw8ZxYaB3/EH31udqndHt1iTItM
         KSOsOMWQ4q2TKKGyv5LnLQfNVHeELZCJhbX3VqwGerm8q0cmVYybIgA1RDrPfFnFQgnP
         VOwBQXn9CguAW7cG0376e9sNjsunwSPCyeE5n7GllRGRPHcCmTwKjFJ05ZJnVZRTAspn
         XdEA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710863380; x=1711468180;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=Z/Hjek9M5u6PXnQB/xTWo90Ep+NkhvngSyuPpPAmfQA=;
        b=L9aznHtjiRjVl2+HcwsEhgH7UJjjX/eWhrNHV2DTrIbJxv7kvYfuBf6add7K2DiOUj
         XvxuE5TqAxFevyNk3VgKiHrPNuRzAd9TQb+RtGVGdT++WMlu18Qpew5STPHLyvb5d1/o
         WHPRbHYWVYIFtnczGritfuRKfcmVXIuwKCc6ye0bvBLSHU9yg/dwn4G/+/3qPowPrAPR
         2zciIRbSxqPQuC7aPlO9pRwiC2leBXF5HAnLffGKx24z4yiwK+TOJ9oPRJNUjy9wgkRm
         fMUKv/cGwjkWgy5kzyMmtqmlPrMR1pRtmyOCmfZlEtMaoNibm7lCN4P5cwHb57YN0j+5
         S9pg==
X-Forwarded-Encrypted: i=1; AJvYcCX92gjTSL6li32zNQY5RoIqd0QDWW7Wf4V0SU0itvjG5IcVOh7q2shr5+1fxuHMRjIA1b5n7pBKMTWuXiinoWTkU7XOXjD+4ZJtFcyUjKM=
X-Gm-Message-State: AOJu0YypdEAu1mA8KpWsLYulMtzHOveuBpWOydqZlWm//yQlMW0lcxQ/
	FuCBWF3Unic3/XpbumKmarSuePgJ2WHxaDbiLDygo16WnFyxwgMlVEyDYTwwMA==
X-Google-Smtp-Source: AGHT+IFkojn1gjw5YMM8QGlesMsoCbmwsfbV0CzjmxKGfGPmx+QM3QGeFtnoIJcwdhXsS/Nmp5FfFw==
X-Received: by 2002:a2e:8556:0:b0:2d4:49d1:38e with SMTP id u22-20020a2e8556000000b002d449d1038emr8212380ljj.28.1710863379785;
        Tue, 19 Mar 2024 08:49:39 -0700 (PDT)
Message-ID: 
Date: Tue, 19 Mar 2024 16:49:38 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 09/14] xen/page_alloc: introduce page flag to stop
 buddy merging
Content-Language: en-US
To: Carlo Nonato 
Cc: Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 xen-devel@lists.xenproject.org
References: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
 <20240315105902.160047-10-carlo.nonato@minervasys.tech>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240315105902.160047-10-carlo.nonato@minervasys.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 15.03.2024 11:58, Carlo Nonato wrote:
> Add a new PGC_no_buddy_merge flag that prevents the buddy algorithm in
> free_heap_pages() from merging pages that have it set. As of now, only
> PGC_static has this feature, but future work can extend it easier than
> before.
> 

Suggested-by: Jan Beulich 

> Signed-off-by: Carlo Nonato 

Reviewed-by: Jan Beulich 




From xen-devel-bounces@lists.xenproject.org Tue Mar 19 15:54:53 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 15:54:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695467.1085248 (Exim 4.92)
	(envelope-from )
	id 1rmbnc-0007NX-Sd; Tue, 19 Mar 2024 15:54:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695467.1085248; Tue, 19 Mar 2024 15:54:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmbnc-0007NQ-Pn; Tue, 19 Mar 2024 15:54:48 +0000
Received: by outflank-mailman (input) for mailman id 695467;
 Tue, 19 Mar 2024 15:54:47 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmbnb-0007NK-D1
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 15:54:47 +0000
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com
 [2a00:1450:4864:20::62e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0244902b-e609-11ee-afdd-a90da7624cb6;
 Tue, 19 Mar 2024 16:54:46 +0100 (CET)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-a46cc947929so268709366b.1
 for ; Tue, 19 Mar 2024 08:54:46 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ws4-20020a170907704400b00a46d001a259sm1648839ejb.52.2024.03.19.08.54.45
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 19 Mar 2024 08:54:45 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0244902b-e609-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710863686; x=1711468486; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=YCMG9o3i9SKD8VuuFfQOtBVuUDkjdhuaeGZRzJqdvDc=;
        b=SHrFnw6DAL7mVxa0OsGCXbiJFtHHV0tGr7wmSZP7oUnwpEGMRiBQCiNYzevhxv2UwG
         +1t6CBkuAhD1yjBZBGnZLcc7wxZbJqaXXOQsdlLobvRlbJjANqJzPS8K1IUkca1XYFg+
         QkSyFo7jycS0HEHC6rboQAC1q5byDGu89DibDPxGzV7Ie5g9Z0YmtWn5TUimKm1+aMJF
         Swogv6Le78EXUoIsuG4NQQEMlHbLYyg/MpPIlQro6mIVczEgWe+HztTYSX08bZwiTeLA
         7sUhKcq6zRqoY4kyRppJCCRlmwseJGOiAL2b4LQDxjtyLspsZGgtbU1ad+cPGgApgUrE
         /QAA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710863686; x=1711468486;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=YCMG9o3i9SKD8VuuFfQOtBVuUDkjdhuaeGZRzJqdvDc=;
        b=C8UqvRStmKDRo3L6fUSUEAFz5Ca4oJhinaciNErgODw2OLrdqnKSisxiy5FXSt+i+R
         8FcBwbKIpDOCDE3ucROGcbFMuh+MdpmuK8jcfPlXoqAIn6IYQLVUNoOjSBou6GlnZZxz
         ZYs+rp0oS16AMoUwiWWs3qnwkDnzYbKxVgmqmv/DXmx+qBj1f4+XuILByiz2NLifgp7P
         a8JiIbc26IGprial+BDwnWDvDmKQkkk1AHdYtni32ZA78cYzHNrPSoWSyUHah4tR51H1
         aaf7jDqXKqmWcPHQxmYddRbllAuwWu/Vr4/1JhKob1g7xDKlPMycldku1ohuE6+V/gQV
         9McA==
X-Forwarded-Encrypted: i=1; AJvYcCUL3c7FYLIY4CG+fbVSRtoGgJ8t+k8aYmQuIgxbLgzy+8pfe6h5SMwppj/OjOANITuLSIf3HG74ugC2W3wZ6luGnxO0r9RrZS3XdabIkoc=
X-Gm-Message-State: AOJu0YxKcaPYJuwRu2mEQja26Q9C4oSlFeMFguGIGv8nwAtub5FGWxeM
	RCXWiqbIKdG0C+oX1s2DsrwGRqRiEDClOO1l777BjI82M4uql9VcXcyDPWxsiQ==
X-Google-Smtp-Source: AGHT+IGtggdMIj0TfVDM92nwrSzR3gxOXogHrXoyTDIISwSHpdLVi52wiL9qXuS0uG2hdH5RuIjFig==
X-Received: by 2002:a17:906:d10e:b0:a46:d49d:eebb with SMTP id b14-20020a170906d10e00b00a46d49deebbmr2361766ejz.16.1710863685829;
        Tue, 19 Mar 2024 08:54:45 -0700 (PDT)
Message-ID: <094ace88-eea9-4527-b166-9cd83214928d@suse.com>
Date: Tue, 19 Mar 2024 16:54:44 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 12/14] xen/arm: add Xen cache colors command line
 parameter
Content-Language: en-US
To: Carlo Nonato 
Cc: Luca Miccio ,
 Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 Marco Solieri , xen-devel@lists.xenproject.org
References: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
 <20240315105902.160047-13-carlo.nonato@minervasys.tech>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240315105902.160047-13-carlo.nonato@minervasys.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 15.03.2024 11:59, Carlo Nonato wrote:
> From: Luca Miccio 
> 
> Add a new command line parameter to configure Xen cache colors.
> These colors can be dumped with the cache coloring info debug-key.
> 
> By default, Xen uses the first color.
> Benchmarking the VM interrupt response time provides an estimation of
> LLC usage by Xen's most latency-critical runtime task. Results on Arm
> Cortex-A53 on Xilinx Zynq UltraScale+ XCZU9EG show that one color, which
> reserves 64 KiB of L2, is enough to attain best responsiveness:
> - Xen 1 color latency:  3.1 us
> - Xen 2 color latency:  3.1 us
> 
> More colors are instead very likely to be needed on processors whose L1
> cache is physically-indexed and physically-tagged, such as Cortex-A57.
> In such cases, coloring applies to L1 also, and there typically are two
> distinct L1-colors. Therefore, reserving only one color for Xen would
> senselessly partitions a cache memory that is already private, i.e.
> underutilize it.

Here you say that using just a single color is undesirable on such systems.

> The default amount of Xen colors is thus set to one.

Yet then, without any further explanation you conclude that 1 is the
universal default.

> @@ -147,6 +159,21 @@ void __init llc_coloring_init(void)
>          panic("Number of LLC colors (%u) not in range [2, %u]\n",
>                max_nr_colors, CONFIG_NR_LLC_COLORS);
>  
> +    if ( !xen_num_colors )
> +    {
> +        unsigned int i;
> +
> +        xen_num_colors = MIN(XEN_DEFAULT_NUM_COLORS, max_nr_colors);
> +
> +        printk(XENLOG_WARNING
> +               "Xen LLC color config not found. Using first %u colors\n",
> +               xen_num_colors);
> +        for ( i = 0; i < xen_num_colors; i++ )
> +            xen_colors[i] = i;
> +    }
> +    else if ( !check_colors(xen_colors, xen_num_colors) )
> +        panic("Bad LLC color config for Xen\n");

This "else" branch again lacks a bounds check against max_nr_colors, if
I'm not mistaken.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Mar 19 15:55:16 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 15:55:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695469.1085257 (Exim 4.92)
	(envelope-from )
	id 1rmbo4-0007lS-3L; Tue, 19 Mar 2024 15:55:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695469.1085257; Tue, 19 Mar 2024 15:55:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmbo4-0007lL-0q; Tue, 19 Mar 2024 15:55:16 +0000
Received: by outflank-mailman (input) for mailman id 695469;
 Tue, 19 Mar 2024 15:55:14 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmbo2-0007l9-QC; Tue, 19 Mar 2024 15:55:14 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmbo2-00073N-LT; Tue, 19 Mar 2024 15:55:14 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmbo2-00063S-CM; Tue, 19 Mar 2024 15:55:14 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rmbo2-00076d-Bi; Tue, 19 Mar 2024 15:55:14 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=t/4tUPadefHj8sMiP/D1bR0Ufpg/VqItKS5Cr9c+Ga4=; b=MF4Zo0NJ+yidUfZsGly7mqcRqB
	9MzUc50ckPWYi3s4ESx41e11RBbBwnRnRsU13ZYVtLtVaSbSewnv/+SnP9Bk4aT3Md7oos4qpJTz7
	msQlPkaxI6wIInVyIYFmyFfeplZ9Bcl4GT/yjtVqNK32qHTq+6j/4qbo6KebA64AiJxY=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [ovmf test] 185098: all pass - PUSHED
X-Osstest-Versions-This:
    ovmf=35f6a2780e5198315a9f100c07b3bc86187d20a8
X-Osstest-Versions-That:
    ovmf=3840c35e34d1c992268092b6366e26f2acc55a75
From: osstest service owner 
Date: Tue, 19 Mar 2024 15:55:14 +0000

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf                 35f6a2780e5198315a9f100c07b3bc86187d20a8
baseline version:
 ovmf                 3840c35e34d1c992268092b6366e26f2acc55a75

Last test of basis   185049  2024-03-15 12:41:10 Z    4 days
Testing same since   185093  2024-03-19 10:11:15 Z    0 days    2 attempts

------------------------------------------------------------
People who touched revisions under test:
  Ceping Sun 

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-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   3840c35e34..35f6a2780e  35f6a2780e5198315a9f100c07b3bc86187d20a8 -> xen-tested-master


From xen-devel-bounces@lists.xenproject.org Tue Mar 19 15:58:46 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 15:58:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695478.1085268 (Exim 4.92)
	(envelope-from )
	id 1rmbrR-00009t-J4; Tue, 19 Mar 2024 15:58:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695478.1085268; Tue, 19 Mar 2024 15:58:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmbrR-00009m-GZ; Tue, 19 Mar 2024 15:58:45 +0000
Received: by outflank-mailman (input) for mailman id 695478;
 Tue, 19 Mar 2024 15:58:44 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmbrQ-000065-1l
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 15:58:44 +0000
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com
 [2a00:1450:4864:20::635])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8ed16f56-e609-11ee-a1ee-f123f15fe8a2;
 Tue, 19 Mar 2024 16:58:42 +0100 (CET)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-a46cd9e7fcaso246255766b.1
 for ; Tue, 19 Mar 2024 08:58:42 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 bk10-20020a170907360a00b00a46e2f89a9csm739689ejc.32.2024.03.19.08.58.41
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 19 Mar 2024 08:58:41 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8ed16f56-e609-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710863921; x=1711468721; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=EDfo9dp2beKkhcxcX+gQIIWYKul4uhwmLTf4Y6egGwE=;
        b=Fv3pIQdeVO26A4OZdDy6NAm6LFF8kvwasMRLD71vkrrbgQkE0qYoUbFAPW82GcSWYy
         861h3lxwDrGNZ3rR43wxbUbjSnnkhZj//o4/Y5W9IBCqrWRBvnJ3f5igZJkqc4o6Ka11
         8L5X1bUgZZv1jd2RIFZutgCMNZY6a19ulMDzujcG6S1is+AFetnSeA1k0Fv6kyO8e/UN
         FM7HHpd8pnb6yjnGZeHEoBwGHkT4ATxE/TPydt2YzN2OlELDik7o/V1QbOCpE94/CwW/
         xKQ46scHwMUCOL4iTJ0SEtmWK2Me2RMysx+IOsdQMrHZ8m6wHSeXJKRoNJ++pKyxnwDV
         Cwgw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710863921; x=1711468721;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=EDfo9dp2beKkhcxcX+gQIIWYKul4uhwmLTf4Y6egGwE=;
        b=DyR3Axsy+w19vwVrt8NUSuUqN9dM4i6Asbxqo52gw4Qw2B8xZtcry1XrRSWxts9Y2H
         QFlUzCJJWJzda4ovXnQcQzUYf7audQtBIfOHmkjjzJNrJSESYpPyiQj6x8DwVyMxQNdG
         T9khQSpHJa18WsRngzH6Q25Cz5p7NS/MDrcA7LF2g9t0/AxEOm+SYg3Bhnt1AiV1y8a6
         5hGfiKMemQ3RdnW5FmJEg43lY3h0u1SZK07sdyxb2rjVtz+yTJs8+lFiqFUMqx92e7qy
         ILgYeBZ7aVx3xY1gHyOWuao/1w0fSQeeYyF4ojnrzjlhY9+QUdmKbzXyFu6PfL/w2cgd
         yZBA==
X-Forwarded-Encrypted: i=1; AJvYcCVEMJSXgNGkrvuQG/5hWK2KR3ZdFrGOFdBaFRY4kNNr1rLigqhrbPfRwNJ4J8h4w0HikLvtTVF9mmHSzHqPm1YRZh8gEbvYdxky8zMBQ9E=
X-Gm-Message-State: AOJu0YwPV3tCxOu7ZSJeQtT9XAfpL0uAmPFT/nAKzTK335GRq5fwzH9T
	gFique2Ot/MxllLqmqc3+6eQtmI+NTMZsnCVprT4NP9Z0g6dwr4zdJzgD/48Ew==
X-Google-Smtp-Source: AGHT+IHwuHWyMVXmfcJf6/LhQyl+4N4FqW3NpqQEOd5910hrOhIXHjNnYHkWSZaehMA5TDpd8DIMyw==
X-Received: by 2002:a17:906:d8b2:b0:a44:b9e0:8592 with SMTP id qc18-20020a170906d8b200b00a44b9e08592mr2004099ejb.8.1710863921660;
        Tue, 19 Mar 2024 08:58:41 -0700 (PDT)
Message-ID: <147ba010-3776-4ebd-a871-894921bcd4c4@suse.com>
Date: Tue, 19 Mar 2024 16:58:40 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 14/14] xen/arm: add cache coloring support for Xen
Content-Language: en-US
To: Carlo Nonato 
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 George Dunlap , Wei Liu ,
 Marco Solieri , xen-devel@lists.xenproject.org
References: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
 <20240315105902.160047-15-carlo.nonato@minervasys.tech>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240315105902.160047-15-carlo.nonato@minervasys.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 15.03.2024 11:59, Carlo Nonato wrote:
> @@ -326,6 +328,27 @@ unsigned int get_max_nr_llc_colors(void)
>      return max_nr_colors;
>  }
>  
> +paddr_t __init xen_colored_map_size(void)
> +{
> +    return ROUNDUP((_end - _start) * max_nr_colors, XEN_PADDR_ALIGN);
> +}

XEN_PADDR_ALIGN is an inherently Arm thing. Such better wouldn't appear
in common code.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Mar 19 16:03:43 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 16:03:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695483.1085278 (Exim 4.92)
	(envelope-from )
	id 1rmbwB-0002tZ-5B; Tue, 19 Mar 2024 16:03:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695483.1085278; Tue, 19 Mar 2024 16:03:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmbwB-0002tS-2P; Tue, 19 Mar 2024 16:03:39 +0000
Received: by outflank-mailman (input) for mailman id 695483;
 Tue, 19 Mar 2024 16:03:37 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmbw9-0002tK-NM
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 16:03:37 +0000
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com
 [2a00:1450:4864:20::535])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3e5ca587-e60a-11ee-afdd-a90da7624cb6;
 Tue, 19 Mar 2024 17:03:36 +0100 (CET)
Received: by mail-ed1-x535.google.com with SMTP id
 4fb4d7f45d1cf-56b857bac38so973233a12.0
 for ; Tue, 19 Mar 2024 09:03:36 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ek20-20020a056402371400b0056b9754fa1fsm782402edb.60.2024.03.19.09.03.35
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 19 Mar 2024 09:03:35 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3e5ca587-e60a-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710864216; x=1711469016; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=EtHfdTvgfTJgk7m9Ttz2PcO/AOctE+1IurGzbgNC7xs=;
        b=bskAAJ6aSqRRDfG1aw0B02gDrNWbqoL0S/72Iw4KdgIe/meDUp+1zZpnewkjBV0pUP
         Pr/y+lMioiWr16nUUQpK2JDeE/UT4ucwQGpukTwSjy1nbdxxuHDZcHFEt/5fbsz5Kr2g
         2ZvUNrDn3w3bK41PT/Duaw9UhHC8Z9WOSIXXa80lMfN0VxsufuwTrE0tO1/OGTtsumf+
         /HbTDeU2PNLssS8E8DLS+Mixmp6kjBuSPszQSMSGbZGqrPdERMl+kktAgw1hCRnFjsvX
         fvkjI8qUyzZHOALcvOezPPGAzOvg0yShrDEa2SVqlDqm0FJvjHKhkDAy+SX1n+prn4tP
         +Zfg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710864216; x=1711469016;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=EtHfdTvgfTJgk7m9Ttz2PcO/AOctE+1IurGzbgNC7xs=;
        b=qkUX+Ur9mNOavJLB8NRM6Bfg/WxW/bbmsiuhqkwhBG+VESsfWhWi2G7KoSY4fp7bIg
         Rl7TJUdRk/egnY/zjst4q7l0s4k4sw9KFXXxebcJHy8vvioRCL79uhtYR6CYlrrSVj3T
         KeUmE9stl6cWMFE9QUJHFSItBmleeJARj6z4aCk/TmbDbPy78qnEJdiqf1mlEn60T2zW
         LOm1YaHGUJr5d7Bo4Uaf/QgoKf3W8rPbivGADgD/j/C3u8VVI4WFtU86RuWQKvDUNq2Z
         0DR7Q29t+LWT/rGadB8E/8idrDljPqttjwKHsQhKrCC/VR66lZSqj65zqC/Yg/CkFg+1
         6mpg==
X-Forwarded-Encrypted: i=1; AJvYcCWbCXStQk4wY+FWp1t9ol0paw7c3G8kyV2SC9bjzPDx+9fjPudmrImDO2csBISavDnSjWYkjzcv6A40Mt/p3SquKYpKpaU/AgLGXCSr6Lw=
X-Gm-Message-State: AOJu0Yywwb8tYX6YT0V8AUbdKik88zTkL3XcMPWCf7+s6B5TP8LbSDHQ
	7lzGeqvUPLFWsG2rdmaPLBy2LfneEJmPrI4hA+JxVCmwnKnUNanmuehJR3tGgPJT3JSPY3eV8LU
	=
X-Google-Smtp-Source: AGHT+IFkrW6OEWqYCE+I9uzhw2wyuVwG249wD7+3krzcAduz+Y37v03UC3sNPxCPkpm6y55IMZZ8Qw==
X-Received: by 2002:a05:6402:1f08:b0:565:f7c7:f23c with SMTP id b8-20020a0564021f0800b00565f7c7f23cmr8216926edb.3.1710864216190;
        Tue, 19 Mar 2024 09:03:36 -0700 (PDT)
Message-ID: <9dfd1629-e69f-40a9-a027-9e36add0a48f@suse.com>
Date: Tue, 19 Mar 2024 17:03:34 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 14/14] xen/arm: add cache coloring support for Xen
Content-Language: en-US
To: Carlo Nonato 
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 George Dunlap , Wei Liu ,
 Marco Solieri , xen-devel@lists.xenproject.org
References: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
 <20240315105902.160047-15-carlo.nonato@minervasys.tech>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240315105902.160047-15-carlo.nonato@minervasys.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 15.03.2024 11:59, Carlo Nonato wrote:
> @@ -62,7 +63,67 @@ unsigned int __init get_llc_way_size(void)
>      return line_size * num_sets;
>  }
>  
> -void __init arch_llc_coloring_init(void) {}

Btw, doing things this way isn't very nice. I was about to ask ...

> +/**
> + * get_xen_paddr - get physical address to relocate Xen to
> + *
> + * Xen is relocated to as near to the top of RAM as possible and
> + * aligned to a XEN_PADDR_ALIGN boundary.
> + */
> +static paddr_t __init get_xen_paddr(paddr_t xen_size)
> +{
> +    const struct meminfo *mi = &bootinfo.mem;
> +    paddr_t min_size;
> +    paddr_t paddr = 0;
> +    unsigned int i;
> +
> +    min_size = (xen_size + (XEN_PADDR_ALIGN-1)) & ~(XEN_PADDR_ALIGN-1);
> +
> +    /* Find the highest bank with enough space. */
> +    for ( i = 0; i < mi->nr_banks; i++ )
> +    {
> +        const struct membank *bank = &mi->bank[i];
> +        paddr_t s, e;
> +
> +        if ( bank->size >= min_size )
> +        {
> +            e = consider_modules(bank->start, bank->start + bank->size,
> +                                 min_size, XEN_PADDR_ALIGN, 0);
> +            if ( !e )
> +                continue;
> +
> +#ifdef CONFIG_ARM_32
> +            /* Xen must be under 4GB */
> +            if ( e > GB(4) )
> +                e = GB(4);
> +            if ( e < bank->start )
> +                continue;
> +#endif
> +
> +            s = e - min_size;
> +
> +            if ( s > paddr )
> +                paddr = s;
> +        }
> +    }
> +
> +    if ( !paddr )
> +        panic("Not enough memory to relocate Xen\n");
> +
> +    printk("Placing Xen at 0x%"PRIpaddr"-0x%"PRIpaddr"\n",
> +           paddr, paddr + min_size);
> +
> +    return paddr;
> +}
> +
> +void __init arch_llc_coloring_init(void)
> +{
> +    struct bootmodule *xen_bootmodule = boot_module_find_by_kind(BOOTMOD_XEN);
> +
> +    BUG_ON(!xen_bootmodule);
> +
> +    xen_bootmodule->size = xen_colored_map_size();
> +    xen_bootmodule->start = get_xen_paddr(xen_bootmodule->size);
> +}

... whether the build wouldn't have been broken until this function
is added. Since you know the function is going to gain a non-empty
body, please introduce it in the earlier patch as

void __init arch_llc_coloring_init(void)
{
}

instead.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Mar 19 16:16:12 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 16:16:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695489.1085287 (Exim 4.92)
	(envelope-from )
	id 1rmc8F-0005G6-5w; Tue, 19 Mar 2024 16:16:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695489.1085287; Tue, 19 Mar 2024 16:16:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmc8F-0005Fz-38; Tue, 19 Mar 2024 16:16:07 +0000
Received: by outflank-mailman (input) for mailman id 695489;
 Tue, 19 Mar 2024 16:16:05 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmc8D-0005Ft-RS
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 16:16:05 +0000
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com
 [2a00:1450:4864:20::62d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id fa8c5360-e60b-11ee-a1ee-f123f15fe8a2;
 Tue, 19 Mar 2024 17:16:01 +0100 (CET)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-a465ddc2c09so389516166b.2
 for ; Tue, 19 Mar 2024 09:16:01 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 s14-20020a056402014e00b0056b81da18c0sm1745979edu.17.2024.03.19.09.16.00
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 19 Mar 2024 09:16:01 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: fa8c5360-e60b-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710864961; x=1711469761; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:references:cc:to
         :from:content-language:subject:user-agent:mime-version:date
         :message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=ZAD2pA23WrR6O/crsHzWBoKV29m/NxlQoWgxo8hwufc=;
        b=b4Nw3kWnNSDBSq5YEpdzt65d1U/xhIrjQGNiG/4BpscqcBzvC0qhy3TnZjW/alyISU
         MdMaRTEcrw5+5zcd7tbAL9jGySUFRcxp7JmIzOpTkv55z/fvCwcOb1I/7Cf+ibSDXhkY
         a8euJ67BByEmxGl3Qqj6X7arzgUVCCfogrbHq8ueEQzzPJz6Ny+cEx76QgX3+uePfrqv
         Zp/Ua7aCBoVJcrYQNim23p8yEpghFADuTvEnwhcfkWIFNCjzDtIaG6Tt06HZigbessR3
         XfxggFXMZvPFKIpu24ChYKoYAvSsdRypH2gGW0hqrX3hCgRpfzkSCdDb8faO3XGMdJF/
         RnDg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710864961; x=1711469761;
        h=content-transfer-encoding:in-reply-to:autocrypt:references:cc:to
         :from:content-language:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=ZAD2pA23WrR6O/crsHzWBoKV29m/NxlQoWgxo8hwufc=;
        b=QVCE6fdqCfgGIaPXgqMB5EBiYG5QUSIt5Yr7T0gLuQGQwh/Z5t3Q5yacYDP1ssLXFa
         FDruJUhcMeavDGfKmswxkoYNkp+G/qABisG1CAvlT+hAim9Es2dX2EJplzjrweRC6ybd
         cedQpPWESdBfilxc0+rqkiEmIUsRzpx9VFq6rzF69w23EQSBAuf3ICT9bFQUcHlmlhrq
         +n5WUZzfCtLqZ08Vh9yPWnkgc6HTnM/Eup8eTVC8+KfvuobcXAXnDeqLCiv8yBAxy1NY
         M5ynjPd5VSqvu9Y/K3oZGKbwrFtEyp4VQ09OWJcerV4GFN9RhgyhX15Q8FQOB5XyS7St
         Xegg==
X-Forwarded-Encrypted: i=1; AJvYcCWDT+8pW0Xl4fykQKrbfILnyYZosH/VUMFtMsyFNGLgcjm7IZkByjcaEeZx0RkFNTJnLKt1P4LtJfyeVGzIDp/t30VHNfbXTlUn+yqnlBU=
X-Gm-Message-State: AOJu0YwVIMNJdNzwRwnz9MVDg6t3qBksQFro1iCQ9NoxUA3UlToAHIpa
	p1IHFBe4nGQoNniSGs8RYhijC+ehzKLDl1HzSnDTfzhlKh/2SCAJic9TGThTEQ==
X-Google-Smtp-Source: AGHT+IHVSaJvWmv6hpAzfqE2aEhcxREg9WiQZkQ4Wv36s5o83bWqZXrlnPYlTgdMIeVjTIHloo5fEg==
X-Received: by 2002:a05:6402:5d0:b0:565:6e34:da30 with SMTP id n16-20020a05640205d000b005656e34da30mr10889400edx.21.1710864961432;
        Tue, 19 Mar 2024 09:16:01 -0700 (PDT)
Message-ID: <5ebf9310-7815-45ca-ac8b-5acc98a9e3df@suse.com>
Date: Tue, 19 Mar 2024 17:15:59 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 14/14] xen/arm: add cache coloring support for Xen
Content-Language: en-US
From: Jan Beulich 
To: Carlo Nonato 
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 George Dunlap , Wei Liu ,
 Marco Solieri , xen-devel@lists.xenproject.org
References: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
 <20240315105902.160047-15-carlo.nonato@minervasys.tech>
 <147ba010-3776-4ebd-a871-894921bcd4c4@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <147ba010-3776-4ebd-a871-894921bcd4c4@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 19.03.2024 16:58, Jan Beulich wrote:
> On 15.03.2024 11:59, Carlo Nonato wrote:
>> @@ -326,6 +328,27 @@ unsigned int get_max_nr_llc_colors(void)
>>      return max_nr_colors;
>>  }
>>  
>> +paddr_t __init xen_colored_map_size(void)
>> +{
>> +    return ROUNDUP((_end - _start) * max_nr_colors, XEN_PADDR_ALIGN);
>> +}
> 
> XEN_PADDR_ALIGN is an inherently Arm thing. Such better wouldn't appear
> in common code.

And actually in patch 10 you introduce get_max_nr_llc_colors). With
that, this calculation can more to Arm code.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Mar 19 16:20:43 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 16:20:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695494.1085298 (Exim 4.92)
	(envelope-from )
	id 1rmcCf-0007g3-Py; Tue, 19 Mar 2024 16:20:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695494.1085298; Tue, 19 Mar 2024 16:20:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmcCf-0007fw-Mb; Tue, 19 Mar 2024 16:20:41 +0000
Received: by outflank-mailman (input) for mailman id 695494;
 Tue, 19 Mar 2024 16:20:40 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmcCe-0007fq-Lk
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 16:20:40 +0000
Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com
 [2607:f8b0:4864:20::22b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9f1fa3b2-e60c-11ee-afdd-a90da7624cb6;
 Tue, 19 Mar 2024 17:20:38 +0100 (CET)
Received: by mail-oi1-x22b.google.com with SMTP id
 5614622812f47-3c37d50adecso2523999b6e.0
 for ; Tue, 19 Mar 2024 09:20:38 -0700 (PDT)
Received: from localhost ([85.31.135.62]) by smtp.gmail.com with ESMTPSA id
 js7-20020a0562142aa700b00690aa73c1a8sm6602004qvb.45.2024.03.19.09.20.36
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 19 Mar 2024 09:20:36 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9f1fa3b2-e60c-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710865237; x=1711470037; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=New5yt4NA/Qxla66zz9V/j+2SjROsyPAVTT+6g6Pnj4=;
        b=gw4pJ8huV/X07ZbAasrUkpGrGmjbI7IqL2bNFVDrnMx0BtKEP6oSD1jlGPMHfF4fcX
         ns+e06QX39A2HJB8a9TPfR65m0wqwjxjT29a526uWyDyIAb1gn7uxJOqpeNvMF1iJafd
         s2CtdOKEF3zspSlkfiK1EDgSwvJL3EKvfRU+o=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710865237; x=1711470037;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=New5yt4NA/Qxla66zz9V/j+2SjROsyPAVTT+6g6Pnj4=;
        b=jDWglLm6DLW6eG20cBlVfVolx0jrXImXP0TUNLJj5RUQHd9D91MHrZYTq3ahSRExdf
         S5fl4aqoid+XiFZSYjHPYiiuuvEIitzVTg/+5FsOU07msoH5scd5YjRgOUDGH6C8W9d+
         oPnkGfkTJT+L2a/8A59xXMecuY+OG/GGXyftM7gTZLzEhuGJwyDqXJ93ILyENwgBCz2i
         Z36vYDQDdI/R7+mq1Nqh8VU5cmp6OJNsfjd/d7eMTH13rmK8lnnn/RJ0cl3WjQsE4n4o
         cwB0F3LB9GwV6rhg0lG687ROhRLsDenzGy7fr2xxdxU8U4vIxkFK2XstGDzB0/l2dGnm
         zcDA==
X-Gm-Message-State: AOJu0Yx6da50rN7eSf9my3/EQnJxSNDVXmFWqN3wE7Iv0INgUF8eBRGx
	WfCdLoOqwZcfKlfzxnpVNTQ81meFDs24QWLBYLmnwadRjj6sb8/SKBLQqnFItl0=
X-Google-Smtp-Source: AGHT+IEmwgabXb5Gqbn8YU7PFgf15iMA/J02xeneHUrceL0B8d31jc1SbM9GjtmjsldTNJFtg+r99Q==
X-Received: by 2002:a05:6808:3c91:b0:3c3:979c:a3ea with SMTP id gs17-20020a0568083c9100b003c3979ca3eamr2946297oib.58.1710865237252;
        Tue, 19 Mar 2024 09:20:37 -0700 (PDT)
Date: Tue, 19 Mar 2024 17:20:35 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Alejandro Vallejo 
Cc: Xen-devel ,
	Jan Beulich ,
	Andrew Cooper , Wei Liu 
Subject: Re: [PATCH 1/6] xen/x86: Add initial x2APIC ID to the per-vLAPIC
 save area
Message-ID: 
References: <20240109153834.4192-1-alejandro.vallejo@cloud.com>
 <20240109153834.4192-2-alejandro.vallejo@cloud.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20240109153834.4192-2-alejandro.vallejo@cloud.com>

On Tue, Jan 09, 2024 at 03:38:29PM +0000, Alejandro Vallejo wrote:
> This allows the initial x2APIC ID to be sent on the migration stream. The
> hardcoded mapping x2apic_id=2*vcpu_id is maintained for the time being.
> Given the vlapic data is zero-extended on restore, fix up migrations from
> hosts without the field by setting it to the old convention if zero.
> 
> x2APIC IDs are calculated from the CPU policy where the guest topology is
> defined. For the time being, the function simply returns the old
> relationship, but will eventually return results consistent with the
> topology.
> 
> Signed-off-by: Alejandro Vallejo 
> ---
>  xen/arch/x86/cpuid.c                   | 20 ++++---------------
>  xen/arch/x86/domain.c                  |  3 +++
>  xen/arch/x86/hvm/vlapic.c              | 27 ++++++++++++++++++++++++--
>  xen/arch/x86/include/asm/hvm/vlapic.h  |  2 ++
>  xen/include/public/arch-x86/hvm/save.h |  2 ++
>  xen/include/xen/lib/x86/cpu-policy.h   |  9 +++++++++
>  xen/lib/x86/policy.c                   | 11 +++++++++++
>  7 files changed, 56 insertions(+), 18 deletions(-)
> 
> diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
> index 7290a979c6..6e259785d0 100644
> --- a/xen/arch/x86/cpuid.c
> +++ b/xen/arch/x86/cpuid.c
> @@ -139,10 +139,9 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
>          const struct cpu_user_regs *regs;
>  
>      case 0x1:
> -        /* TODO: Rework topology logic. */
>          res->b &= 0x00ffffffu;
>          if ( is_hvm_domain(d) )
> -            res->b |= (v->vcpu_id * 2) << 24;
> +            res->b |= SET_xAPIC_ID(vlapic_x2apic_id(vcpu_vlapic(v)));

SET_xAPIC_ID() was intended to be used with the APIC_ID register,
which also shifts the ID.  Not sure it's logically correct to use
here, even if functionally equivalent (as is shifts left by 24).

>  
>          /* TODO: Rework vPMU control in terms of toolstack choices. */
>          if ( vpmu_available(v) &&
> @@ -311,20 +310,9 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
>          break;
>  
>      case 0xb:
> -        /*
> -         * In principle, this leaf is Intel-only.  In practice, it is tightly
> -         * coupled with x2apic, and we offer an x2apic-capable APIC emulation
> -         * to guests on AMD hardware as well.
> -         *
> -         * TODO: Rework topology logic.
> -         */
> -        if ( p->basic.x2apic )
> -        {
> -            *(uint8_t *)&res->c = subleaf;
> -
> -            /* Fix the x2APIC identifier. */
> -            res->d = v->vcpu_id * 2;
> -        }
> +        /* ecx != 0 if the subleaf is implemented */
> +        if ( res->c && p->basic.x2apic )
> +            res->d = vlapic_x2apic_id(vcpu_vlapic(v));

This needs to be protected so it's reachable by HVM guests only,
otherwise you will dereference v->arch.hvm.vlapic on a PV vCPU if it
happens to have p->basic.x2apic set.

Why not just return the x2apic_id field from the cpu_policy object?
(topo.subleaf[X].x2apic_id)

Also, I'm not sure I get why the setting of res->d is gated on res->c
!= 0, won't res->c be 0 when the guest %ecx is 0, yet %edx must be
valid for all %ecx inputs, the SDM states:

"The EDX output of leaf 0BH is always valid and does not vary with
input value in ECX."

I think you need to keep the previous logic that doesn't gate setting
->d on anything other than p->basic.x2apic.

>          break;
>  
>      case XSTATE_CPUID:
> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> index 8a31d18f69..e0c7ed8d5d 100644
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -288,7 +288,10 @@ void update_guest_memory_policy(struct vcpu *v,
>  static void cpu_policy_updated(struct vcpu *v)
>  {
>      if ( is_hvm_vcpu(v) )
> +    {
>          hvm_cpuid_policy_changed(v);
> +        vlapic_cpu_policy_changed(v);
> +    }
>  }
>  
>  void domain_cpu_policy_changed(struct domain *d)
> diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
> index cdb69d9742..f500d66543 100644
> --- a/xen/arch/x86/hvm/vlapic.c
> +++ b/xen/arch/x86/hvm/vlapic.c
> @@ -1069,7 +1069,7 @@ static uint32_t x2apic_ldr_from_id(uint32_t id)
>  static void set_x2apic_id(struct vlapic *vlapic)
>  {
>      const struct vcpu *v = vlapic_vcpu(vlapic);
> -    uint32_t apic_id = v->vcpu_id * 2;
> +    uint32_t apic_id = vlapic->hw.x2apic_id;
>      uint32_t apic_ldr = x2apic_ldr_from_id(apic_id);
>  
>      /*
> @@ -1083,6 +1083,22 @@ static void set_x2apic_id(struct vlapic *vlapic)
>      vlapic_set_reg(vlapic, APIC_LDR, apic_ldr);
>  }
>  
> +void vlapic_cpu_policy_changed(struct vcpu *v)
> +{
> +    struct vlapic *vlapic = vcpu_vlapic(v);
> +    struct cpu_policy *cp = v->domain->arch.cpu_policy;
> +
> +    /*
> +     * Don't override the initial x2APIC ID if we have migrated it or
> +     * if the domain doesn't have vLAPIC at all.
> +     */
> +    if ( !has_vlapic(v->domain) || vlapic->loaded.hw )
> +        return;
> +
> +    vlapic->hw.x2apic_id = x86_x2apic_id_from_vcpu_id(cp, v->vcpu_id);
> +    vlapic_set_reg(vlapic, APIC_ID, SET_xAPIC_ID(vlapic->hw.x2apic_id));
> +}
> +
>  int guest_wrmsr_apic_base(struct vcpu *v, uint64_t val)
>  {
>      const struct cpu_policy *cp = v->domain->arch.cpu_policy;
> @@ -1449,7 +1465,7 @@ void vlapic_reset(struct vlapic *vlapic)
>      if ( v->vcpu_id == 0 )
>          vlapic->hw.apic_base_msr |= APIC_BASE_BSP;
>  
> -    vlapic_set_reg(vlapic, APIC_ID, (v->vcpu_id * 2) << 24);
> +    vlapic_set_reg(vlapic, APIC_ID, SET_xAPIC_ID(vlapic->hw.x2apic_id));
>      vlapic_do_init(vlapic);
>  }
>  
> @@ -1514,6 +1530,13 @@ static void lapic_load_fixup(struct vlapic *vlapic)
>      const struct vcpu *v = vlapic_vcpu(vlapic);
>      uint32_t good_ldr = x2apic_ldr_from_id(vlapic->loaded.id);
>  
> +    /*
> +     * Guest with hardcoded assumptions about x2apic_id <-> vcpu_id
> +     * mappings. Recreate the mapping it used to have in old host.

Wouldn't it be more appropriate to state "Loading record without
hw.x2apic_id in the save stream, calculate using the vcpu_id * 2
relation" or some such.

Current comment makes it looks like the guest has some kind of
restriction with this relation, but that's just an internal Xen
limitation.

> +     */
> +    if ( !vlapic->hw.x2apic_id )
> +        vlapic->hw.x2apic_id = v->vcpu_id * 2;
> +
>      /* Skip fixups on xAPIC mode, or if the x2APIC LDR is already correct */
>      if ( !vlapic_x2apic_mode(vlapic) ||
>           (vlapic->loaded.ldr == good_ldr) )
> diff --git a/xen/arch/x86/include/asm/hvm/vlapic.h b/xen/arch/x86/include/asm/hvm/vlapic.h
> index 88ef945243..e8d41313ab 100644
> --- a/xen/arch/x86/include/asm/hvm/vlapic.h
> +++ b/xen/arch/x86/include/asm/hvm/vlapic.h
> @@ -44,6 +44,7 @@
>  #define vlapic_xapic_mode(vlapic)                               \
>      (!vlapic_hw_disabled(vlapic) && \
>       !((vlapic)->hw.apic_base_msr & APIC_BASE_EXTD))
> +#define vlapic_x2apic_id(vlapic) ((vlapic)->hw.x2apic_id)
>  
>  /*
>   * Generic APIC bitmap vector update & search routines.
> @@ -107,6 +108,7 @@ int vlapic_ack_pending_irq(struct vcpu *v, int vector, bool force_ack);
>  
>  int  vlapic_init(struct vcpu *v);
>  void vlapic_destroy(struct vcpu *v);
> +void vlapic_cpu_policy_changed(struct vcpu *v);
>  
>  void vlapic_reset(struct vlapic *vlapic);
>  
> diff --git a/xen/include/public/arch-x86/hvm/save.h b/xen/include/public/arch-x86/hvm/save.h
> index 7ecacadde1..1c2ec669ff 100644
> --- a/xen/include/public/arch-x86/hvm/save.h
> +++ b/xen/include/public/arch-x86/hvm/save.h
> @@ -394,6 +394,8 @@ struct hvm_hw_lapic {
>      uint32_t             disabled; /* VLAPIC_xx_DISABLED */
>      uint32_t             timer_divisor;
>      uint64_t             tdt_msr;
> +    uint32_t             x2apic_id;
> +    uint32_t             rsvd_zero;

Do we really to add a new field, couldn't we get the lapic IDs from
the cpu_policy?

>  };
>  
>  DECLARE_HVM_SAVE_TYPE(LAPIC, 5, struct hvm_hw_lapic);
> diff --git a/xen/include/xen/lib/x86/cpu-policy.h b/xen/include/xen/lib/x86/cpu-policy.h
> index d5e447e9dc..14724cedff 100644
> --- a/xen/include/xen/lib/x86/cpu-policy.h
> +++ b/xen/include/xen/lib/x86/cpu-policy.h
> @@ -542,6 +542,15 @@ int x86_cpu_policies_are_compatible(const struct cpu_policy *host,
>                                      const struct cpu_policy *guest,
>                                      struct cpu_policy_errors *err);
>  
> +/**
> + * Calculates the x2APIC ID of a vCPU given a CPU policy
> + *
> + * @param p          CPU policy of the domain.
> + * @param vcpu_id    vCPU ID of the vCPU.
> + * @returns x2APIC ID of the vCPU.
> + */
> +uint32_t x86_x2apic_id_from_vcpu_id(const struct cpu_policy *p, uint32_t vcpu_id);
> +
>  #endif /* !XEN_LIB_X86_POLICIES_H */
>  
>  /*
> diff --git a/xen/lib/x86/policy.c b/xen/lib/x86/policy.c
> index f033d22785..a3b24e6879 100644
> --- a/xen/lib/x86/policy.c
> +++ b/xen/lib/x86/policy.c
> @@ -2,6 +2,17 @@
>  
>  #include 
>  
> +uint32_t x86_x2apic_id_from_vcpu_id(const struct cpu_policy *p, uint32_t vcpu_id)
> +{
> +    /*
> +     * TODO: Derive x2APIC ID from the topology information inside `p`
> +     *       rather than from vCPU ID. This bodge is a temporary measure
> +     *       until all infra is in place to retrieve or derive the initial
> +     *       x2APIC ID from migrated domains.
> +     */
> +    return vcpu_id * 2;

As noted above, won't a suitable initial step would be to populate the
apic_id and x2apic_id fields in struct cpu_policy with this relation
(x{,2}apic_id == vcpu_id * 2), and avoid this extra handler?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Mar 19 16:32:40 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 16:32:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695499.1085309 (Exim 4.92)
	(envelope-from )
	id 1rmcO9-0001bt-S0; Tue, 19 Mar 2024 16:32:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695499.1085309; Tue, 19 Mar 2024 16:32:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmcO9-0001bm-Nl; Tue, 19 Mar 2024 16:32:33 +0000
Received: by outflank-mailman (input) for mailman id 695499;
 Tue, 19 Mar 2024 16:32:32 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmcO8-0001bf-8h
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 16:32:32 +0000
Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4638af73-e60e-11ee-afdd-a90da7624cb6;
 Tue, 19 Mar 2024 17:32:29 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sin.source.kernel.org (Postfix) with ESMTP id 7D0C0CE0EC7;
 Tue, 19 Mar 2024 16:32:26 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPS id B1588C433C7;
 Tue, 19 Mar 2024 16:32:25 +0000 (UTC)
Received: from aws-us-west-2-korg-oddjob-1.ci.codeaurora.org
 (localhost.localdomain [127.0.0.1])
 by aws-us-west-2-korg-oddjob-1.ci.codeaurora.org (Postfix) with ESMTP id
 AA2E8D84BA6; Tue, 19 Mar 2024 16:32:25 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4638af73-e60e-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1710865945;
	bh=thznYSl/RULrLuI/zS56kmqKZGuZNeDoORWBvdGwIrQ=;
	h=Subject:From:In-Reply-To:References:Date:To:Cc:From;
	b=EVywMTv1T8LmU8pLrqbhN3KB0Tjxm1ynvn8vr9rEGry566r3cnlITHyEQT37ukb+M
	 7NCa+nkF7qP2B+ZoESetk9riut7VP51dlE3Joh/F9AZeQFaTJ703Pqd1V0wO+cc4p1
	 gu+TsE/l/294+dfDW1RcaollOUut83o9espjDZv+xeBCmaZW1762lOI4oPqWXUzTgM
	 M/JCLancaMXuMKPa/S/+GgzZkG+HMSHT9TCdL8QNyrZbEjWQdpaponpgGLmtsTDBDr
	 mQ2gitEHVHY24bakpDPG4A/SKd4CU43ga5aN8N1n4VZJnT+y4sEnbu3QpKE93Ca4UO
	 MxfXp4vR6x/Fw==
Subject: Re: [GIT PULL] xen: branch for v6.9-rc1
From: pr-tracker-bot@kernel.org
In-Reply-To: <20240319071022.7513-1-jgross@suse.com>
References: <20240319071022.7513-1-jgross@suse.com>
X-PR-Tracked-List-Id: 
X-PR-Tracked-Message-Id: <20240319071022.7513-1-jgross@suse.com>
X-PR-Tracked-Remote: git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-6.9-rc1-tag
X-PR-Tracked-Commit-Id: d277f9d82802223f242cd9b60c988cfdda1d6be0
X-PR-Merge-Tree: torvalds/linux.git
X-PR-Merge-Refname: refs/heads/master
X-PR-Merge-Commit-Id: 0815d5cc7dfb4a2c6d02a6eb86974ab3992b803d
Message-Id: <171086594569.7768.14518623666259076339.pr-tracker-bot@kernel.org>
Date: Tue, 19 Mar 2024 16:32:25 +0000
To: Juergen Gross 
Cc: torvalds@linux-foundation.org, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, sstabellini@kernel.org

The pull request you sent on Tue, 19 Mar 2024 08:10:22 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-6.9-rc1-tag

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/0815d5cc7dfb4a2c6d02a6eb86974ab3992b803d

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html


From xen-devel-bounces@lists.xenproject.org Tue Mar 19 16:43:56 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 16:43:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695504.1085317 (Exim 4.92)
	(envelope-from )
	id 1rmcZ1-0003xv-Px; Tue, 19 Mar 2024 16:43:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695504.1085317; Tue, 19 Mar 2024 16:43:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmcZ1-0003xo-NH; Tue, 19 Mar 2024 16:43:47 +0000
Received: by outflank-mailman (input) for mailman id 695504;
 Tue, 19 Mar 2024 16:43:46 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmcZ0-0003xN-Ii
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 16:43:46 +0000
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com
 [2a00:1450:4864:20::534])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d9b26163-e60f-11ee-a1ee-f123f15fe8a2;
 Tue, 19 Mar 2024 17:43:44 +0100 (CET)
Received: by mail-ed1-x534.google.com with SMTP id
 4fb4d7f45d1cf-5684ea117a3so8526318a12.0
 for ; Tue, 19 Mar 2024 09:43:44 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a89-20020a509ee2000000b00568c299eaedsm3946856edf.81.2024.03.19.09.43.43
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 19 Mar 2024 09:43:44 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d9b26163-e60f-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710866624; x=1711471424; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=B7ziCVcpDDeUQjlCm66oq5vRfuhJ18TkciU8KxvLapU=;
        b=Nsw5faCTUfEoP/aIqAquN825WdqsEZhVmFA/sCLvkeItlkayTj6p2HuHf3zANoMGAA
         cQcM2plo+KK3W1Z75+ngqVjP9ap8/M2P54LoqN/ksC8B0iXJtYj428boTGAvTJ+9xR+J
         zc92AVRpjq+1JDq6S7sWwpBexqu5tmPfOM98xQCbZC5Fs4qO+TsosjQOQwchm1YsGUkQ
         cnioB0cYY6hdR89QarFSAV3JLJgLCJYQeOKKT7Z4drA/G+h35rBUmxps6w0Xto/xxhxo
         SDb3juGM5eLeT+S31zd+pT6RroVjUtphIqnYz8iytd7kXzNq2zU8oWFmztu5RQctQhjh
         tzBw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710866624; x=1711471424;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=B7ziCVcpDDeUQjlCm66oq5vRfuhJ18TkciU8KxvLapU=;
        b=Ct+M/MNtRDe3Tq5weg+/7g0Ta0GJuMe8/UOv9X0wDFHwXjQ4cyrUDYeP8a6XoIZhK5
         EDLkM0EUKA0RzVZC0S/LHe3uog09+It8FEqLA0pUWIGBDVfa5ynoF1UQ5w8TMiUFIQJR
         XyNdFt+hG8+Nfu3WQ1NbfKHg/6iKkhEr4oh5Fy2ME6txtWQY6pmePT+8vNuHvCGnfXZ4
         Arqxn9jF4FIIcT5Bf3CqLc3mX6Iul7L0rf25BHK0WBgkMl6fpyyqfA+OopHNo+6bVacj
         WIIrjv0K4K865V9go5AtxsMmHIHsDAqT3+pqvuK1LsTi/ZL8fwIpND1R17L4NFZqsE31
         yLpg==
X-Forwarded-Encrypted: i=1; AJvYcCXs2BtYE+7oOiIji3ND2m27uwciNQqeNd4dYiUurrMYeO90onp04Bwl96NROH4bL5hpZ5rnQLIKK8g0+y70Dig6NOS+BwiB4/LkukPgKmk=
X-Gm-Message-State: AOJu0Yz2363GArjFHn1fFVALCsO2Vji5xVRvzwe3SEMbw7YU91GxFc4C
	H11Dg8Eg8JmuRVHikdUUQplnLmK5jfKPrPQUFbsdt50Z9Md9wzjTz2ilemcJTg==
X-Google-Smtp-Source: AGHT+IGzzQuVqI4kOMfcWTK+Tbg6XiwLB1/LBVMIRkh/c/uaiAhhQMq9V41FARezVUQyAOR1SBcNbQ==
X-Received: by 2002:a05:6402:3589:b0:568:d315:b85e with SMTP id y9-20020a056402358900b00568d315b85emr5307576edc.36.1710866624241;
        Tue, 19 Mar 2024 09:43:44 -0700 (PDT)
Message-ID: 
Date: Tue, 19 Mar 2024 17:43:42 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 10/14] xen: add cache coloring allocator for domains
Content-Language: en-US
To: Carlo Nonato 
Cc: Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Marco Solieri , xen-devel@lists.xenproject.org
References: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
 <20240315105902.160047-11-carlo.nonato@minervasys.tech>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240315105902.160047-11-carlo.nonato@minervasys.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 15.03.2024 11:58, Carlo Nonato wrote:
> Add a new memory page allocator that implements the cache coloring mechanism.
> The allocation algorithm enforces equal frequency distribution of cache
> partitions, following the coloring configuration of a domain. This allows
> for an even utilization of cache sets for every domain.
> 
> Pages are stored in a color-indexed array of lists. Those lists are filled
> by a simple init function which computes the color of each page.
> When a domain requests a page, the allocator extract the page from the list
> with the maximum number of free pages between those that the domain can
> access, given its coloring configuration.

Minor remark: I'm not a native speaker, but "between" here reads odd to
me. I'd have expected perhaps "among".

> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -270,6 +270,20 @@ and not running softirqs. Reduce this if softirqs are not being run frequently
>  enough. Setting this to a high value may cause boot failure, particularly if
>  the NMI watchdog is also enabled.
>  
> +### buddy-alloc-size (arm64)
> +> `= `
> +
> +> Default: `64M`
> +
> +Amount of memory reserved for the buddy allocator when colored allocator is
> +active. This options is parsed only when LLC coloring support is enabled.

Nit: s/parsed/used/ - the option is always parsed as long as LLC_COLORING=y.

> @@ -1945,6 +1949,164 @@ static unsigned long avail_heap_pages(
>      return free_pages;
>  }
>  
> +/*************************
> + * COLORED SIDE-ALLOCATOR
> + *
> + * Pages are grouped by LLC color in lists which are globally referred to as the
> + * color heap. Lists are populated in end_boot_allocator().
> + * After initialization there will be N lists where N is the number of
> + * available colors on the platform.
> + */
> +static struct page_list_head *__ro_after_init _color_heap;
> +#define color_heap(color) (&_color_heap[color])
> +
> +static unsigned long *__ro_after_init free_colored_pages;
> +
> +/* Memory required for buddy allocator to work with colored one */
> +#ifdef CONFIG_LLC_COLORING
> +static unsigned long __initdata buddy_alloc_size =
> +    MB(CONFIG_BUDDY_ALLOCATOR_SIZE);
> +size_param("buddy-alloc-size", buddy_alloc_size);
> +
> +#define domain_num_llc_colors(d) (d)->num_llc_colors
> +#define domain_llc_color(d, i)   (d)->llc_colors[i]
> +#else
> +static unsigned long __initdata buddy_alloc_size;
> +
> +#define domain_num_llc_colors(d) 0
> +#define domain_llc_color(d, i)   0
> +#endif
> +
> +static void free_color_heap_page(struct page_info *pg, bool need_scrub)
> +{
> +    unsigned int color = page_to_llc_color(pg);
> +    struct page_list_head *head = color_heap(color);
> +
> +    spin_lock(&heap_lock);
> +
> +    mark_page_free(pg, page_to_mfn(pg));
> +
> +    if ( need_scrub )
> +    {
> +        pg->count_info |= PGC_need_scrub;
> +        poison_one_page(pg);
> +    }
> +
> +    free_colored_pages[color]++;
> +    page_list_add(pg, head);

May I please ask for a comment (or at least some wording in the description)
as to the choice made here between head or tail insertion? When assuming
that across a system there's no sharing of colors, preferably re-using
cache-hot pages is certainly good. Whereas when colors can reasonably be
expected to be shared, avoiding to quickly re-use a freed page can also
have benefits.

> +static struct page_info *alloc_color_heap_page(unsigned int memflags,
> +                                               const struct domain *d)
> +{
> +    struct page_info *pg = NULL;
> +    unsigned int i, color = 0;
> +    unsigned long max = 0;
> +    bool need_tlbflush = false;
> +    uint32_t tlbflush_timestamp = 0;
> +    bool need_scrub;
> +
> +    if ( memflags >> _MEMF_bits )
> +        return NULL;

By mentioning MEMF_bits earlier on I meant to give an example. What
about MEMF_node and in particular MEMF_exact_node? Certain other flags
also aren't obvious as to being okay to silently ignore.

> +    spin_lock(&heap_lock);
> +
> +    for ( i = 0; i < domain_num_llc_colors(d); i++ )
> +    {
> +        unsigned long free = free_colored_pages[domain_llc_color(d, i)];
> +
> +        if ( free > max )
> +        {
> +            color = domain_llc_color(d, i);
> +            pg = page_list_first(color_heap(color));
> +            max = free;
> +        }
> +    }
> +
> +    if ( !pg )
> +    {
> +        spin_unlock(&heap_lock);
> +        return NULL;
> +    }
> +
> +    need_scrub = pg->count_info & (PGC_need_scrub);
> +    pg->count_info = PGC_state_inuse | (pg->count_info & PGC_colored);

Better PGC_preserved?

> +static void __init init_color_heap_pages(struct page_info *pg,
> +                                         unsigned long nr_pages)
> +{
> +    unsigned int i;
> +    bool need_scrub = opt_bootscrub == BOOTSCRUB_IDLE;
> +
> +    if ( buddy_alloc_size )
> +    {
> +        unsigned long buddy_pages = min(PFN_DOWN(buddy_alloc_size), nr_pages);
> +
> +        init_heap_pages(pg, buddy_pages);

There's a corner case where init_heap_pages() would break when passed 0
as 2nd argument. I think you want to alter the enclosing if() to
"if ( buddy_alloc_size >= PAGE_SIZE )" to be entirely certain to avoid
that case.

> +static void dump_color_heap(void)
> +{
> +    unsigned int color;
> +
> +    printk("Dumping color heap info\n");
> +    for ( color = 0; color < get_max_nr_llc_colors(); color++ )
> +        if ( free_colored_pages[color] > 0 )
> +            printk("Color heap[%u]: %lu pages\n",
> +                   color, free_colored_pages[color]);
> +}

While having all of the code above from here outside of any #ifdef is
helpful to prevent unintended breakage when changes are made and tested
only on non-Arm64 targets, I'd still like to ask: Halfway recent
compilers manage to eliminate everything? I'd like to avoid e.g. x86
being left with traces of coloring despite not being able at all to use
it.

> @@ -2485,7 +2660,10 @@ struct page_info *alloc_domheap_pages(
>          }
>          if ( assign_page(pg, order, d, memflags) )
>          {
> -            free_heap_pages(pg, order, memflags & MEMF_no_scrub);
> +            if ( pg->count_info & PGC_colored )
> +                free_color_heap_page(pg, memflags & MEMF_no_scrub);
> +            else
> +                free_heap_pages(pg, order, memflags & MEMF_no_scrub);
>              return NULL;
>          }
>      }
> @@ -2568,7 +2746,10 @@ void free_domheap_pages(struct page_info *pg, unsigned int order)
>              scrub = 1;
>          }
>  
> -        free_heap_pages(pg, order, scrub);
> +        if ( pg->count_info & PGC_colored )
> +            free_color_heap_page(pg, scrub);
> +        else
> +            free_heap_pages(pg, order, scrub);
>      }

Instead of this, did you consider altering free_heap_pages() to forward
to free_color_heap_page()? That would then also allow to have a single,
central comment and/or assertion that the "order" value here isn't lost.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Mar 19 16:49:13 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 16:49:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695507.1085328 (Exim 4.92)
	(envelope-from )
	id 1rmceC-0004mS-GU; Tue, 19 Mar 2024 16:49:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695507.1085328; Tue, 19 Mar 2024 16:49:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmceC-0004mL-CR; Tue, 19 Mar 2024 16:49:08 +0000
Received: by outflank-mailman (input) for mailman id 695507;
 Tue, 19 Mar 2024 16:49:06 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmceA-0004j8-9N
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 16:49:06 +0000
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com
 [2a00:1450:4864:20::52c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 983de763-e610-11ee-a1ee-f123f15fe8a2;
 Tue, 19 Mar 2024 17:49:04 +0100 (CET)
Received: by mail-ed1-x52c.google.com with SMTP id
 4fb4d7f45d1cf-566e869f631so6629277a12.0
 for ; Tue, 19 Mar 2024 09:49:04 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 x1-20020a056402414100b00568d2d4e4besm2947416eda.54.2024.03.19.09.49.03
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 19 Mar 2024 09:49:03 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 983de763-e610-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710866944; x=1711471744; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=Ak6OBi7xOtHRafKXxTWNWHJwCs6mqQu4V0EKs1GUWCk=;
        b=glxM+z7pWX1s22IKBJzw6DgBBr+77XFKsby3zujCbuDCvJKxy3/yOa2wgoKMsOu9OW
         Itm+5FxnZMkelGy8PfDbiajspl9vwy+KwTBDkbjt3GRrbC3X/LM/QeTdSct/ssgmedYM
         05jcyMYxU5q1+UwF7d2X/dI5EZIzra9ocHZjU8xur+r4w/ki/pg028Il1LmRdn2G1tja
         wysxPRatjW+FAGXqw7cPpnTDpNUy61VP3Xr8alVxvPgkjh4/TZkkuRjcfsOoDRoJV58X
         IowrpvbE+u3PuOpN71Au/WxyOFxIMOebLiV7Xzawf97LTtNk8pmG5xdvnlzwXf0J+oug
         gHPw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710866944; x=1711471744;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=Ak6OBi7xOtHRafKXxTWNWHJwCs6mqQu4V0EKs1GUWCk=;
        b=dRuhtbApkq4G9DjmKY0EYUapDInnX166doPWbFE9I6D+8Nrj+tt0CW4ykYRGWxCaY2
         D1gmwHYWTZOkSjbjupg5MEqHgNKKqoF18xc41clGHNHUwxh2JmU0/0IJN/M/WnILoZJA
         AdFpPL6CXV9Ost7UyfXABWqstPQoFFDSHvB0r3g/tj6zqgcQPdxRZOnZbfv6yjx3ZZXg
         CpEkVhcLHI61vMbzs4qntNheyIyIj2pIQaQ79VUgdkkNXTvNkY9D5hScZKRZq7Dwg4Y8
         bnwgqW9UhqbbPaomhZI2cPYhgScrKVSkOhujx+YV0rDFuYOGZXXiXTbajt8SwxIxl/+X
         UTqg==
X-Forwarded-Encrypted: i=1; AJvYcCUHY+aSouV9NjL6nwblOHbrqXUbX/hI8N+6ECy6TY/memjocqP4rnXNuxp8sIzrMT1BhJ4q7lxrNketDqSXToQtrZjexyF6C4CHDZNU5fc=
X-Gm-Message-State: AOJu0Yz81AinJlL2BVlXNjf8sVKFLcsJkC7JeZBcgrULVCOIgAXPrJXw
	cVXPzD1hShaGQ/qpw7W/yIftpJyB2eYYBSNBIdTNRHAM3SGtmMrlxVN28yCFKQ==
X-Google-Smtp-Source: AGHT+IGAYEN5Kczb5Lz7KHcRf/+98ZXMvWFAjvH5S2gIZjbEiOKFPIJYoH0+wj+tW+24GMSxZQeNAg==
X-Received: by 2002:a05:6402:1f82:b0:566:6640:10e5 with SMTP id c2-20020a0564021f8200b00566664010e5mr2819072edc.12.1710866943977;
        Tue, 19 Mar 2024 09:49:03 -0700 (PDT)
Message-ID: 
Date: Tue, 19 Mar 2024 17:49:02 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/2] x86/boot: Fix setup_apic_nmi_watchdog() to fail more
 cleanly
Content-Language: en-US
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Xen-devel 
References: <20240319144802.3894710-1-andrew.cooper3@citrix.com>
 <20240319144802.3894710-2-andrew.cooper3@citrix.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240319144802.3894710-2-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 19.03.2024 15:48, Andrew Cooper wrote:
> Right now, if the user requests the watchdog on the command line,
> setup_apic_nmi_watchdog() will blindly assume that setting up the watchdog
> worked.  Reuse nmi_perfctr_msr to identify when the watchdog has been set up.
> 
> Rearrange setup_p6_watchdog() to not set nmi_perfctr_msr until the sanity
> checks are performed.  Turn setup_p4_watchdog() into a void function, matching
> the others.
> 
> If the watchdog isn't set up, inform the user and override to NMI_NONE, which
> will prevent check_nmi_watchdog() from claiming that all CPUs are stuck.
> 
> e.g.:
> 
>   (XEN) alt table ffff82d040697c38 -> ffff82d0406a97f0
>   (XEN) Failed to configure NMI watchdog
>   (XEN) Brought up 512 CPUs
>   (XEN) Scheduling granularity: cpu, 1 CPU per sched-resource
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 




From xen-devel-bounces@lists.xenproject.org Tue Mar 19 16:51:42 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 16:51:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695510.1085338 (Exim 4.92)
	(envelope-from )
	id 1rmcgX-0006pb-SH; Tue, 19 Mar 2024 16:51:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695510.1085338; Tue, 19 Mar 2024 16:51:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmcgX-0006pU-Oq; Tue, 19 Mar 2024 16:51:33 +0000
Received: by outflank-mailman (input) for mailman id 695510;
 Tue, 19 Mar 2024 16:51:33 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmcgX-0006pO-2B
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 16:51:33 +0000
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com
 [2a00:1450:4864:20::52b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f0336e48-e610-11ee-afdd-a90da7624cb6;
 Tue, 19 Mar 2024 17:51:32 +0100 (CET)
Received: by mail-ed1-x52b.google.com with SMTP id
 4fb4d7f45d1cf-568aa282ccdso5830781a12.3
 for ; Tue, 19 Mar 2024 09:51:32 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 z10-20020a170906714a00b00a46c39e6a47sm2288156ejj.148.2024.03.19.09.51.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 19 Mar 2024 09:51:31 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f0336e48-e610-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710867091; x=1711471891; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=5c1m0stHH+Uv4w1Vr3ysdaNPyDTZUTJ2KrUxuOTSVCc=;
        b=VWTcEWoXOOO0e+s26BE9ZaPx2438wSKYINDGYqiSpm1ym06VU8rvlLXeE3diSL2MQG
         S8ftJ+P0kL2ALc7USfeiWR0dM8cFL+jkkpdBgCGTiRZGv6e7OUG5TEi34Yr/F0iAIyae
         l4d/OrOY6IjzIBmYsU6Lm1gR1cy4wJf4PHCdghNn1fdQLyCpRCU63vwhHox82PMQrJSU
         7li9wE8a1xT14Ni9F3e6VCIzdoAfWDEObj6es33WCjWgX/8JDZ3pQh8pKgC3HF5J4rlz
         cRoWe9XumVqIgNeeoHjPZdvI9xz0S3P2vpJo9Gb2Z8kTfxMSyquJCoO/TrGVowrnOK+d
         brIg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710867091; x=1711471891;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=5c1m0stHH+Uv4w1Vr3ysdaNPyDTZUTJ2KrUxuOTSVCc=;
        b=YHNCCMEq3Nw/myU+1vbylDFQVgRNyhdRruQbPSAvY8MEAQjaq2DqrhHR7zUqaAYM76
         2d6OSNoXLTTRx8plbZd/dHptIqqo/79IIVjVDsEpESHsJoFrki8Z9TEdbubIlfNHG/Qt
         vlPVLLibHWPyaB+pHe1iHZhoJkb4pX/gu8R+l5iLb/2fDzB5qirQ8ISMuIyqYSmPKEDJ
         wQA6GV9toGLRspFTcOQH9ofkz2pdpj0Z2otBBEoAfyk8BC4f21+guwBOjoVjwWVij4LB
         UO1b2XqAyYfNpk5SCCR7Nj7xtZn0m/z/NTA6P6Hqw5ULTOCAVhoc4G244OxTRVFmvDuf
         Wpng==
X-Forwarded-Encrypted: i=1; AJvYcCUIc6TjvQtK+lrijMrmXYObuHGoe7kb+0PqgjYiQLLpgQgA4kFllBw3tNj7vZjrYVliEzYSiHxdKFt2/FTE72rY3VsfZTdHXBP4GLwlXDI=
X-Gm-Message-State: AOJu0YwNARVIzZsEbApvoi3mBf5tIpjlbxe4kO0wxc1M+8UXyy9Spr8X
	+jy+PL7Apgifm4Yt9PWSRPUysD2KUBYw7zlex5k7kA+e53T/RkUI9//ZoH2DRQ==
X-Google-Smtp-Source: AGHT+IF83qp78yQsypXnHscIK9CJiwAR8Zz9XRhQ9FDb4zeOZHTGNWST4Zu/yczgSxw3CkY76oVg7A==
X-Received: by 2002:a17:907:a70f:b0:a46:671a:75f1 with SMTP id vw15-20020a170907a70f00b00a46671a75f1mr11662858ejc.3.1710867091574;
        Tue, 19 Mar 2024 09:51:31 -0700 (PDT)
Message-ID: 
Date: Tue, 19 Mar 2024 17:51:30 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/2] x86/boot: Support the watchdog on newer AMD systems
Content-Language: en-US
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Xen-devel 
References: <20240319144802.3894710-1-andrew.cooper3@citrix.com>
 <20240319144802.3894710-3-andrew.cooper3@citrix.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240319144802.3894710-3-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 19.03.2024 15:48, Andrew Cooper wrote:
> The MSRs used by setup_k7_watchdog() are architectural in 64bit.  The Unit
> Select (0x76, cycles not in halt state) isn't, but it hasn't changed in 23
> years, making this a trend likely to continue.
> 
> Drop the family check.  If the Unit Select does happen to change meaning in
> the future, check_nmi_watchdog() will still notice the watchdog not operating
> as expected.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 

> --- a/xen/arch/x86/nmi.c
> +++ b/xen/arch/x86/nmi.c
> @@ -387,15 +387,12 @@ void setup_apic_nmi_watchdog(void)
>      if ( nmi_watchdog == NMI_NONE )
>          return;
>  
> -    switch (boot_cpu_data.x86_vendor) {
> +    switch ( boot_cpu_data.x86_vendor )
> +    {
>      case X86_VENDOR_AMD:
> -        switch (boot_cpu_data.x86) {
> -        case 6:

Just to mention it - this case label has been dead code anyway for about 10
years.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Mar 19 16:53:47 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 16:53:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695515.1085348 (Exim 4.92)
	(envelope-from )
	id 1rmcig-0007OT-7F; Tue, 19 Mar 2024 16:53:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695515.1085348; Tue, 19 Mar 2024 16:53:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmcig-0007OK-4Q; Tue, 19 Mar 2024 16:53:46 +0000
Received: by outflank-mailman (input) for mailman id 695515;
 Tue, 19 Mar 2024 16:53:45 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmcif-0007OE-3A
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 16:53:45 +0000
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com
 [2a00:1450:4864:20::531])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3ef278f4-e611-11ee-afdd-a90da7624cb6;
 Tue, 19 Mar 2024 17:53:44 +0100 (CET)
Received: by mail-ed1-x531.google.com with SMTP id
 4fb4d7f45d1cf-56a2bb1d84eso78168a12.1
 for ; Tue, 19 Mar 2024 09:53:44 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 c19-20020aa7d613000000b005686037bc12sm5883566edr.29.2024.03.19.09.53.43
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 19 Mar 2024 09:53:43 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3ef278f4-e611-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710867223; x=1711472023; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=dztUZcUkUpUlI5xmdYLIpeTJ1Nv5X2I93zVJ8FQqPRU=;
        b=V+WZ2H9DNIsQaGwa1HSKjfOpYnIiClHCwCCQmrvmbqZ5HFy7aQawrRhfA84C7Y0EvM
         66YNmLjfBkSm/bwzpxzXEmiqORuXXbQ8f34cgdUp0SoA2tHGc2q6JE0jw/d+bDWmMtgG
         LeVZeKku1uNW526dIwV8QROJ30vVMPjPpS4QJ00ib5PN0wpQkmtIqA8IoXnynLaHkxNn
         yh6m48BvsyTZvCl3HvTFJLgpln/NmEkDeVPSR0PohmdI7si5HltXanuJHWc9Z7q215cx
         QEspA1M/z7+AeZKOXa2GrnUJ+XKf538d8gOXr8j2sdBvbqTRHyQ6Mn5UrKKbB4grdlXQ
         lB4A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710867223; x=1711472023;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=dztUZcUkUpUlI5xmdYLIpeTJ1Nv5X2I93zVJ8FQqPRU=;
        b=IAW1wumznysGB43bqafJKvXKDRR9jARQ4U2xcErfHL3Wk/QrMM2+XtJ88naWLZaRn8
         cDyjdORTf6eC0qN8TF1lLoV45+lHyVhOGFz9kmrW3PjIHzEg4uXLdsemQ1SZEA4UUzjl
         9iA6vT1nc93nhKQvwjgUtCmNF39Kvl8uctCEiU2FFcXIlF8/Si+GJ13+TEBZKGZq7aOk
         UBmlavWBQw2oaarZ8+m1XKBFk15nu1Fy9D3FUZ29SJVQQBfTU4tJXe3u2dYCMQZEzM0h
         5u8TEBG37qkgT8SqzpDkjoen8wT6t7LGdyIM8SmzepTv5f28TkixJrIOPUyPSfLcX+xF
         +LRw==
X-Forwarded-Encrypted: i=1; AJvYcCUqUBk4gLlTHAVj8fR4/z7XeYfrzGhiF+pEiN+rou0bbYqD0nt62W7gx6Tytmy89/VNAjdOL27KH5nHm1rzvyAl4KCuZICtyMrAk7DKHdk=
X-Gm-Message-State: AOJu0YwcSou9nnXGZR0WRXF9Po8xEUKRSBCCJhX12OcgKLI4P45rbPT2
	iRRiwUbRDaoT3oHqbcq5w4CwAI903a1TMSTpgZH8E7SOd7+PO8AIQOXsA9NuDQ==
X-Google-Smtp-Source: AGHT+IHi/qoqUE4095/OI8jBNPR8SSTcnEJIhpseAABhBNEejfykUSysoM0bSpmkwLRB8QTNA7m+2g==
X-Received: by 2002:a05:6402:3710:b0:568:c6fd:4f50 with SMTP id ek16-20020a056402371000b00568c6fd4f50mr35928edb.7.1710867223677;
        Tue, 19 Mar 2024 09:53:43 -0700 (PDT)
Message-ID: 
Date: Tue, 19 Mar 2024 17:53:42 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 0/2] x86/boot: More watchdog fixes
Content-Language: en-US
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Xen-devel 
References: <20240319144802.3894710-1-andrew.cooper3@citrix.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240319144802.3894710-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 19.03.2024 15:48, Andrew Cooper wrote:
> Andrew Cooper (2):
>   x86/boot: Fix setup_apic_nmi_watchdog() to fail more cleanly
>   x86/boot: Support the watchdog on newer AMD systems
> 
>  xen/arch/x86/nmi.c | 36 ++++++++++++++++--------------------
>  1 file changed, 16 insertions(+), 20 deletions(-)

With the R-b-s provided, may I ask that in return you also look at my
watchdog related patches ("x86: adjust initial setting of watchdog kind"
and "x86: increase NMI timer frequency if necessary")? They've been
sitting there for soon 2 months ...

Jan


From xen-devel-bounces@lists.xenproject.org Tue Mar 19 16:54:17 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 16:54:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695517.1085358 (Exim 4.92)
	(envelope-from )
	id 1rmcj6-0007qj-G0; Tue, 19 Mar 2024 16:54:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695517.1085358; Tue, 19 Mar 2024 16:54:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmcj6-0007qa-Ck; Tue, 19 Mar 2024 16:54:12 +0000
Received: by outflank-mailman (input) for mailman id 695517;
 Tue, 19 Mar 2024 16:54:11 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmcj5-0007hl-6w
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 16:54:11 +0000
Received: from mail-qv1-xf32.google.com (mail-qv1-xf32.google.com
 [2607:f8b0:4864:20::f32])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4dd1b257-e611-11ee-a1ee-f123f15fe8a2;
 Tue, 19 Mar 2024 17:54:09 +0100 (CET)
Received: by mail-qv1-xf32.google.com with SMTP id
 6a1803df08f44-6962e6fbf60so11649786d6.1
 for ; Tue, 19 Mar 2024 09:54:09 -0700 (PDT)
Received: from [10.80.67.139] (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 f7-20020a0562141d2700b00690f0d7057esm6654927qvd.39.2024.03.19.09.54.07
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 19 Mar 2024 09:54:08 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4dd1b257-e611-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710867248; x=1711472048; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=cutktx+ICee1wOAHN/b2stNjsIly+eRSrL1CyxQSNSY=;
        b=t3Nf8E7NnFE4Sw0loM0D4KfOPN3bVELLklWY4hCdtDy0MrlDW33G5Xv5/WdiZiTU5L
         +j45CPm4Pg2sijm8iVMLqncwlEPL+o4bkgzBscdYLuxWetNZdGZ0eFJIDODd5Num/J4Y
         1wxHCxbfEkdp1N+RSvRbkZzqmrbfb7TFFXmbk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710867248; x=1711472048;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=cutktx+ICee1wOAHN/b2stNjsIly+eRSrL1CyxQSNSY=;
        b=AxSk/SieYTW4kVwma376gtc6gYv26DIKs1HZxgR5WYy+St6hWfUT2wFCOF361tKtL6
         TirytewgblJuBROCW4TLpsTMMe6Xg2N01QckqPHJRDz2lygNx05If4hXocbnCK93+uNX
         aeYNveopf2QqNe5xUGCuRTV5lEqTiG9dukIzFv30UC4rx2MiJOrY8Zgw7ElJykqQTg0n
         RB3reKSVfK9K6WuvY7ZoB8ropke5iXFeiakbmptwZQN0o/T3o4RX5GFu9FFaqnSioGBX
         n+HtQhRVFMnM9osBbeyCbjyZT9FJh73E1uZum9VQbhDzZHNyZ3hfTpOmkmIf9W3FJCed
         /rug==
X-Forwarded-Encrypted: i=1; AJvYcCWTaKslvHx2jeMuqpAZ/UfjoiW9VmcFcAtgXSgtxxnCROpyjy4Ec9kGp2/y/B0Z9F0KBtwTqDGJ1CTjPSS5Deg/cQKMaTGCptZ4cWJ5Npo=
X-Gm-Message-State: AOJu0YzrjpFYlikUuu8N4cgl1yADpCd50VYgVlcSYO7eTmNq0QeuNIKe
	mUjgylfiBTIDkU9oWd5WUixE7/Wf2yyrDFdTL6+3uQb4a2gWOVIOt5xf4S0OPPnN+3SLLpu1qJ1
	y
X-Google-Smtp-Source: AGHT+IFYmFA5/QWhfmnDwkW7P5s+XlmV13ZjXYQ35OAJKaDaBdMtRumBvBwUp8J6/yAk7pXY+uktkQ==
X-Received: by 2002:a0c:f912:0:b0:690:c79a:2d35 with SMTP id v18-20020a0cf912000000b00690c79a2d35mr15089006qvn.9.1710867248458;
        Tue, 19 Mar 2024 09:54:08 -0700 (PDT)
Message-ID: <31653616-35c0-4ad5-a9df-2a1496416f3f@citrix.com>
Date: Tue, 19 Mar 2024 16:54:06 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/2] x86/boot: Support the watchdog on newer AMD systems
Content-Language: en-GB
To: Jan Beulich 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Xen-devel 
References: <20240319144802.3894710-1-andrew.cooper3@citrix.com>
 <20240319144802.3894710-3-andrew.cooper3@citrix.com>
 
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 19/03/2024 4:51 pm, Jan Beulich wrote:
> On 19.03.2024 15:48, Andrew Cooper wrote:
>> The MSRs used by setup_k7_watchdog() are architectural in 64bit.  The Unit
>> Select (0x76, cycles not in halt state) isn't, but it hasn't changed in 23
>> years, making this a trend likely to continue.
>>
>> Drop the family check.  If the Unit Select does happen to change meaning in
>> the future, check_nmi_watchdog() will still notice the watchdog not operating
>> as expected.
>>
>> Signed-off-by: Andrew Cooper 
> Reviewed-by: Jan Beulich 

Thanks.

>
>> --- a/xen/arch/x86/nmi.c
>> +++ b/xen/arch/x86/nmi.c
>> @@ -387,15 +387,12 @@ void setup_apic_nmi_watchdog(void)
>>      if ( nmi_watchdog == NMI_NONE )
>>          return;
>>  
>> -    switch (boot_cpu_data.x86_vendor) {
>> +    switch ( boot_cpu_data.x86_vendor )
>> +    {
>>      case X86_VENDOR_AMD:
>> -        switch (boot_cpu_data.x86) {
>> -        case 6:
> Just to mention it - this case label has been dead code anyway for about 10
> years.

Yeah... I noticed that after writing the commit message, although it's
not very easy to slip in.

Also it's 25 years since the K7 was released (June 1999), because I
apparently can't count.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Mar 19 17:14:57 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 17:14:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695543.1085367 (Exim 4.92)
	(envelope-from )
	id 1rmd36-0003s6-4V; Tue, 19 Mar 2024 17:14:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695543.1085367; Tue, 19 Mar 2024 17:14:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmd36-0003rz-1e; Tue, 19 Mar 2024 17:14:52 +0000
Received: by outflank-mailman (input) for mailman id 695543;
 Tue, 19 Mar 2024 17:14:50 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmd34-0003rs-7k
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 17:14:50 +0000
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com
 [2a00:1450:4864:20::32a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 30ee9838-e614-11ee-afdd-a90da7624cb6;
 Tue, 19 Mar 2024 18:14:49 +0100 (CET)
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-41412e6b2cfso15788395e9.2
 for ; Tue, 19 Mar 2024 10:14:49 -0700 (PDT)
Received: from [10.80.67.139] (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 by19-20020a056000099300b0034174875850sm5493269wrb.70.2024.03.19.10.14.47
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 19 Mar 2024 10:14:47 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 30ee9838-e614-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710868488; x=1711473288; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=W6/a3b+fxTvBdKPc6QkA6k20Nwv60cgrdy6XCpTTdV4=;
        b=iG7FysCifNX6P6Ax5YWu3mlQXaqjcz5BzxGD6buLzvvNKl5tWoPiBC7B1n1X+RbGP6
         CSsdV3wJSoR/IjBZZGGOYcB/cRuf0FRzPWmzIk7p8Pe8KMIhwXFcpCmbRhvqoGNqeUEr
         1D1Gx1FzuyGGWci0bcRIhcosWhw1khWL/dBOM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710868488; x=1711473288;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=W6/a3b+fxTvBdKPc6QkA6k20Nwv60cgrdy6XCpTTdV4=;
        b=RGsrev/eaego75idkNePq2AhAJ++/ZmYWi0g4x8i1xd5ILWVN+v6gRr6gSLJhg4tdH
         6F3QOuCel4+SCOTzhOjSafjxPskfRBjv2XzcXqXSGHEAItixxTDT+rPaSIImzQwF8gRc
         v9rRROqHdBjizjF2VvThngadGEbiikfYTS8Az7/O09Vj+WUz4vO1SEA7uSY7gZphiWwx
         t5F1uNvwtr82HBBYO1w7LSKga1zOz9rq9Z9+Gny92KY9bhzkijGlHInHtpb3Wp45hveP
         xFzgNde/xp0DOvetl49M3sy+PavkBF0cC2YXiWyrsPvDuH2DzNrW/y4aji2T7zXDmIkO
         DHhw==
X-Forwarded-Encrypted: i=1; AJvYcCX58xVmnA/Npv57d4OgtCdkECKaMwmsejJDlzPcRLrS+hbQqA6w1+LGxENFEAMBRln+zqEtMM0OkXPD7EDkayOg6bHWL0fugwvJ8Rw4IAo=
X-Gm-Message-State: AOJu0YwFgmi7f6CBiJX6XmW2P3F18IHY5oDp6RRvaL2oNeg6Viq2z/gm
	NNOhjaowLyui05dHDFicjiETrSVLwb0GPagipk9oOmATK0Jx0UN7l9E8J7c2dAw=
X-Google-Smtp-Source: AGHT+IEWhF1WEEmo5ffkgUbVs9VOlMvVYiysFsQkLQ1uSJmao0h5BSiPUFRGwdLoJZb0syY7ZbI5cg==
X-Received: by 2002:a05:600c:3c86:b0:414:286:fd1f with SMTP id bg6-20020a05600c3c8600b004140286fd1fmr7705455wmb.11.1710868488528;
        Tue, 19 Mar 2024 10:14:48 -0700 (PDT)
Message-ID: 
Date: Tue, 19 Mar 2024 17:14:47 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/features: More AMD features
Content-Language: en-GB
To: Jan Beulich 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Xen-devel 
References: <20240318181332.3817631-1-andrew.cooper3@citrix.com>
 
 <4aa2aced-d4dc-40d6-818b-8163657cd670@suse.com>
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <4aa2aced-d4dc-40d6-818b-8163657cd670@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 19/03/2024 1:11 pm, Jan Beulich wrote:
> On 19.03.2024 08:33, Jan Beulich wrote:
>> On 18.03.2024 19:13, Andrew Cooper wrote:
>>> I'm not sure about FSRSC as a name, but it definitely beats AMD's longhand
>>> name of FAST_REP_SCASB.
>> With FSRS already used, I guess that's the closest we can get to keep
>> names for similar features similar.
>>
>>> --- a/tools/misc/xen-cpuid.c
>>> +++ b/tools/misc/xen-cpuid.c
>>> @@ -91,6 +91,7 @@ static const char *const str_e1c[32] =
>>>      [24] = "perfctr-nb", /* [25] */
>>>      [26] = "dbx",        [27] = "perftsc",
>>>      [28] = "pcx-l2i",    [29] = "monitorx",
>>> +    [30] = "dbext2",
>>>  };
>> AMD calls this AddrMaskExt (PM) or AdMskExtn (PPR). I can see where your
>> different name choice is coming from, yet I still wonder whether we should
>> try to stay closer where possible.
> Having located the corresponding doc,
> Reviewed-by: Jan Beulich 
> with a slight preference to adjusted names for this one feature.

Neither are great.  How about "addr-msk-ext" ?

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Mar 19 17:40:17 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 17:40:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695547.1085378 (Exim 4.92)
	(envelope-from )
	id 1rmdRb-0000VD-55; Tue, 19 Mar 2024 17:40:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695547.1085378; Tue, 19 Mar 2024 17:40:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmdRb-0000V6-2M; Tue, 19 Mar 2024 17:40:11 +0000
Received: by outflank-mailman (input) for mailman id 695547;
 Tue, 19 Mar 2024 17:40:10 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmdRa-0000V0-0O
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 17:40:10 +0000
Received: from mail-ua1-x933.google.com (mail-ua1-x933.google.com
 [2607:f8b0:4864:20::933])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ba0fd701-e617-11ee-afdd-a90da7624cb6;
 Tue, 19 Mar 2024 18:40:08 +0100 (CET)
Received: by mail-ua1-x933.google.com with SMTP id
 a1e0cc1a2514c-7e0a4b2d777so87994241.0
 for ; Tue, 19 Mar 2024 10:40:08 -0700 (PDT)
Received: from [10.80.67.139] (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 jn10-20020ad45dea000000b00690dd47a41csm6716887qvb.86.2024.03.19.10.40.04
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 19 Mar 2024 10:40:05 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ba0fd701-e617-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710870005; x=1711474805; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=rrL9Kz+ZKM/DM784P4UlmLyF0ehyJ9P9HDQ8QX8yhXk=;
        b=lgC1TV0l+nZM24pO5GBHU5DHkTjwd14IDwqEV9vHhPDmxcax7qhZw59d9RkUpSU5xo
         hyHPKgdjXHJaQQsZiA36hVZVbBOGOdPVtpHK/R1wtwh9OPttvQVuD1L8i1QWBGmHkxGt
         aspwmRxmU3rCalGTtKhutD+ayB7FFKP3CzDI0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710870005; x=1711474805;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=rrL9Kz+ZKM/DM784P4UlmLyF0ehyJ9P9HDQ8QX8yhXk=;
        b=pa8AMISoqVHZu7rv9ZYDOPXqnVO50SwlLCWFvB//5htUZGxA8c3KCu43G0/euW9q6y
         VPYyLu8pXEZmLN5KeGdHM9WvRB87uSz9du2bKyslLCrAlH7zg63Xly78uSj66jBv0nMF
         OoFC4ZtYG7sjV2QE+P2XP39gxmhjDROHr3ANdB6ug7tuE9ihwTtDUwMINgdo/6BMcSsU
         LwH48RIWTRq6lUW7A5Du4Slnxap1KtGrc4BEKZZ/YyADhNdJImWROh82An5EB8pzEAEr
         rx7vmQguuQMg78EYWOcgFoTUKXOoZ4NHAZyvv5Ci2rWs1f5Umxdk5OEnDk0lcSSUuuSC
         aoJQ==
X-Gm-Message-State: AOJu0Yw/h9GC1ejjxKsu9z+uwvk9yDhu4VzUcUh1Z637+VHI0AjAcRJC
	xHUn3P3CW7maZW+9H5QDNKZubpUkNyLv4LbVX9u+GYh73OS4rKLjt07wyMRm9Su/JtsOWID587K
	s
X-Google-Smtp-Source: AGHT+IH+czLzwWWnZk1urz4FDtf9C2NKC9ZwJiOIcHr+FcmaBdlBZJxL8Tet126APtKnudnCgmZAxg==
X-Received: by 2002:a67:b915:0:b0:476:6a20:bdd6 with SMTP id q21-20020a67b915000000b004766a20bdd6mr10493362vsn.31.1710870005506;
        Tue, 19 Mar 2024 10:40:05 -0700 (PDT)
Message-ID: <8eb3d0d4-daf2-40a4-83b6-d3726e02814f@citrix.com>
Date: Tue, 19 Mar 2024 17:40:03 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/features: More AMD features
Content-Language: en-GB
To: Xen-devel 
Cc: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 
References: <20240318181332.3817631-1-andrew.cooper3@citrix.com>
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <20240318181332.3817631-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 18/03/2024 6:13 pm, Andrew Cooper wrote:
> All of these are informational and require no further logic changes in Xen to
> support.
>
> Signed-off-by: Andrew Cooper 
> ---
> CC: Jan Beulich 
> CC: Roger Pau Monné 
>
> I'm not sure about FSRSC as a name, but it definitely beats AMD's longhand
> name of FAST_REP_SCASB.
> ---
>  tools/misc/xen-cpuid.c                      | 5 +++++
>  xen/include/public/arch-x86/cpufeatureset.h | 8 ++++++++
>  2 files changed, 13 insertions(+)
>
> diff --git a/tools/misc/xen-cpuid.c b/tools/misc/xen-cpuid.c
> index 51efbff579e6..b562ee839d38 100644
> --- a/tools/misc/xen-cpuid.c
> +++ b/tools/misc/xen-cpuid.c
> @@ -91,6 +91,7 @@ static const char *const str_e1c[32] =
>      [24] = "perfctr-nb", /* [25] */
>      [26] = "dbx",        [27] = "perftsc",
>      [28] = "pcx-l2i",    [29] = "monitorx",
> +    [30] = "dbext2",
>  };
>  
>  static const char *const str_7b0[32] =
> @@ -199,11 +200,15 @@ static const char *const str_7a1[32] =
>  
>  static const char *const str_e21a[32] =
>  {
> +    [ 0] = "no-nest-bp",    [ 1] = "fs-gs-ns",
>      [ 2] = "lfence+",
>      [ 6] = "nscb",
>      [ 8] = "auto-ibrs",
> +    [10] = "amd-fsrs",      [11] = "amd-fsrc",
>  
>      /* 16 */                [17] = "cpuid-user-dis",
> +    [18] = "epsf",          [19] = "fsrsc",

It occurs to me that I need this hunk too.

diff --git a/xen/tools/gen-cpuid.py b/xen/tools/gen-cpuid.py
index 25d329ce486f..bf3f9ec01e6e 100755
--- a/xen/tools/gen-cpuid.py
+++ b/xen/tools/gen-cpuid.py
@@ -329,6 +329,10 @@ def crunch_numbers(state):
         # In principle the TSXLDTRK insns could also be considered
independent.
         RTM: [TSXLDTRK],
 
+        # Enhanced Predictive Store-Forwarding is a informational note
on top
+        # of PSF.
+        PSFD: [EPSF],
+
         # The ARCH_CAPS CPUID bit enumerates the availability of the
whole register.
         ARCH_CAPS: list(range(RDCL_NO, RDCL_NO + 64)),
 

To cause EPSF to disappear properly when levelling.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Mar 19 17:45:44 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 17:45:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695550.1085388 (Exim 4.92)
	(envelope-from )
	id 1rmdWs-0001Zx-OB; Tue, 19 Mar 2024 17:45:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695550.1085388; Tue, 19 Mar 2024 17:45:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmdWs-0001Zq-KH; Tue, 19 Mar 2024 17:45:38 +0000
Received: by outflank-mailman (input) for mailman id 695550;
 Tue, 19 Mar 2024 17:45:37 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1rmdWr-0001ZU-Lq
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 17:45:37 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmdWr-00019x-C6; Tue, 19 Mar 2024 17:45:37 +0000
Received: from [15.248.3.92] (helo=[10.24.67.36])
 by xenbits.xenproject.org with esmtpsa
 (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92)
 (envelope-from )
 id 1rmdWr-0004fj-4k; Tue, 19 Mar 2024 17:45:37 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=BvFen0WvClk5egWfwknEsM7DYe3rRelZ8HEiYRYQ/QA=; b=lrnxoPCPExL2HEnqxjr4YE8yEd
	FXBDxxNnG54xLTEbX3wLRMJMlErVhPyxX/NN6FYVIwfvqp95VV9J3fSFX5OFxZ5TNfjU2Pbar/Pev
	5x1iCFXwKqe4Bhcdr8kVQv2JhB6xb4jzUKz02s3w0CE05RbekXaBYd6sLage+GE5Y2Dw=;
Message-ID: 
Date: Tue, 19 Mar 2024 17:45:35 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH] docs/parse-support-md: Handle BulletList
Content-Language: en-GB
To: Anthony PERARD , xen-devel@lists.xenproject.org
Cc: Andrew Cooper ,
 George Dunlap , Jan Beulich ,
 Stefano Stabellini 
References: <20240319151509.8937-1-anthony.perard@citrix.com>
From: Julien Grall 
In-Reply-To: <20240319151509.8937-1-anthony.perard@citrix.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Anthony,

On 19/03/2024 15:15, Anthony PERARD wrote:
> Commit d638e304f13a introduced a bullet list, but parse-support-md
> choke on it as it doesn't know what to do about it.
> 
> Introduce ri_BulletList() so that r_content() will find this new
> function and call it instead of calling process_unknown().
> 
> Reported-by: Julien Grall 
> Fixes: d638e304f13a ("SUPPORT.MD: Fix matrix generation after 43c416d0d819 and 77c39a53cf5b")
> Signed-off-by: Anthony PERARD 

My Perl knowledge is rubbish. But I tested the fix. So:

Tested-by: Julien Grall 
Acked-by: Julien Grall 

Cheers,

> ---
>   docs/parse-support-md | 7 +++++++
>   1 file changed, 7 insertions(+)
> 
> diff --git a/docs/parse-support-md b/docs/parse-support-md
> index a397637639..b04f62da37 100755
> --- a/docs/parse-support-md
> +++ b/docs/parse-support-md
> @@ -218,6 +218,13 @@ sub ri_DefinitionList {
>       }
>   }
>   
> +sub ri_BulletList {
> +    # Assume a paragraph introduce this bullet list, which would mean that
> +    # ri_Para() has already been called, and there's nothing else to do about
> +    # the caveat.
> +    return;
> +}
> +
>   sub process_unknown {
>       my ($c, $e) = @_;
>       $had_unknown = Dumper($e);

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Tue Mar 19 17:50:35 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 17:50:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695552.1085398 (Exim 4.92)
	(envelope-from )
	id 1rmdbd-0003h4-9S; Tue, 19 Mar 2024 17:50:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695552.1085398; Tue, 19 Mar 2024 17:50:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmdbd-0003gx-62; Tue, 19 Mar 2024 17:50:33 +0000
Received: by outflank-mailman (input) for mailman id 695552;
 Tue, 19 Mar 2024 17:50:32 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmdbc-0003gn-6o; Tue, 19 Mar 2024 17:50:32 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmdbc-0001GE-4S; Tue, 19 Mar 2024 17:50:32 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmdbb-0000XH-NT; Tue, 19 Mar 2024 17:50:31 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rmdbb-0007fZ-Mw; Tue, 19 Mar 2024 17:50:31 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=/HBk8YBIq7OzXhMEHVWMW2QSJ+x0P25vjjBFd4o3cWA=; b=w+06aiNika4Rpe3rIYtP6XlvoC
	6fuTmFmb0L79nsYKEOVZZMkQYYnN2lloipCVWuLLx3BqALNWAXMucEshqaq9vyplJgT45Sp5hLUp1
	Nc8MzgRK7Au7Jz1DSTZaDTcFx7ebwL26HJloSN05RuQ3NXfnwKrwGJjYYLMPTTS0kNAU=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 185083: regressions - trouble: blocked/broken/fail/pass
X-Osstest-Failures:
    xen-unstable:build-i386-libvirt::broken:regression
    xen-unstable:build-i386-libvirt:host-build-prep:fail:regression
    xen-unstable:test-armhf-armhf-xl-credit1:xen-boot:fail:regression
    xen-unstable:test-amd64-i386-libvirt:build-check(1):blocked:nonblocking
    xen-unstable:test-amd64-i386-libvirt-pair:build-check(1):blocked:nonblocking
    xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
    xen-unstable:test-amd64-i386-libvirt-raw:build-check(1):blocked:nonblocking
    xen-unstable:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking
    xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:windows-install:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
X-Osstest-Versions-This:
    xen=62018f08708a5ff6ef8fc8ff2aaaac46e5a60430
X-Osstest-Versions-That:
    xen=d638e304f13a5ef7d125de5ace5f7828a7b25bac
From: osstest service owner 
Date: Tue, 19 Mar 2024 17:50:31 +0000

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-libvirt                               broken
 build-i386-libvirt            5 host-build-prep          fail REGR. vs. 185072
 test-armhf-armhf-xl-credit1   8 xen-boot                 fail REGR. vs. 185072

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-raw   1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)               blocked  n/a
 test-armhf-armhf-libvirt     16 saverestore-support-check    fail  like 185072
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop            fail like 185072
 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop             fail like 185072
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop            fail like 185072
 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop             fail like 185072
 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop             fail like 185072
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop            fail like 185072
 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check   fail like 185072
 test-armhf-armhf-libvirt-raw 15 saverestore-support-check    fail  like 185072
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 185072
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop             fail like 185072
 test-amd64-amd64-xl-qemuu-win7-amd64 12 windows-install       fail like 185072
 test-amd64-amd64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     15 migrate-support-check        fail   never pass
 test-amd64-i386-xl-pvshim    14 guest-start                  fail   never pass
 test-arm64-arm64-xl-thunderx 15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      16 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass
 test-armhf-armhf-xl-rtds     15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 15 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-check    fail  never pass
 test-armhf-armhf-libvirt     15 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-raw 14 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-raw 15 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-vhd      14 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-vhd      15 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-vhd      14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      15 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          16 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-qcow2 14 migrate-support-check        fail never pass
 test-armhf-armhf-libvirt-raw 14 migrate-support-check        fail   never pass

version targeted for testing:
 xen                  62018f08708a5ff6ef8fc8ff2aaaac46e5a60430
baseline version:
 xen                  d638e304f13a5ef7d125de5ace5f7828a7b25bac

Last test of basis   185072  2024-03-18 01:54:35 Z    1 days
Testing same since   185083  2024-03-18 16:39:27 Z    1 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper 
  Federico Serafini 
  George Dunlap 
  Jan Beulich 
  Kevin Tian 
  Nicola Vetrini 
  Stefano Stabellini 
  Vaishali Thakkar 
  Wei Liu 

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           broken  
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            blocked 
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  blocked 
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-i386-examine-bios                                 pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  fail    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      blocked 
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 blocked 
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-armhf-armhf-libvirt-qcow2                               pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-libvirt-raw                                  blocked 
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-i386-examine-uefi                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-arm64-arm64-xl-vhd                                      pass    
 test-armhf-armhf-xl-vhd                                      pass    
 test-amd64-i386-xl-vhd                                       pass    


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

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

Explanation of these 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

broken-job build-i386-libvirt broken

Not pushing.

------------------------------------------------------------
commit 62018f08708a5ff6ef8fc8ff2aaaac46e5a60430
Author: Jan Beulich 
Date:   Mon Mar 18 13:53:37 2024 +0100

    x86/mm: use block_lock_speculation() in _mm_write_lock()
    
    I can only guess that using block_speculation() there was a leftover
    from, earlier on, SPECULATIVE_HARDEN_LOCK depending on
    SPECULATIVE_HARDEN_BRANCH.
    
    Fixes: 197ecd838a2a ("locking: attempt to ensure lock wrappers are always inline")
    Signed-off-by: Jan Beulich 
    Reviewed-by: Andrew Cooper 

commit d92a67b60c038ebb0f0b83a7f1ce5ad359e052d6
Author: Nicola Vetrini 
Date:   Mon Mar 18 13:53:07 2024 +0100

    xen/sched: address violations of MISRA C Rule 20.7
    
    MISRA C Rule 20.7 states: "Expressions resulting from the expansion
    of macro parameters shall be enclosed in parentheses". Therefore, some
    macro definitions should gain additional parentheses to ensure that all
    current and future users will be safe with respect to expansions that
    can possibly alter the semantics of the passed-in macro parameter.
    
    No functional change.
    
    Signed-off-by: Nicola Vetrini 
    Acked-by: George Dunlap 

commit f93d8dd5198c1ac0a4be5c7fb1b5a997d5c42a97
Author: Federico Serafini 
Date:   Mon Mar 18 13:52:53 2024 +0100

    automation/eclair: allow parameter name "unused"
    
    Update ECLAIR configuration of MISRA C:2012 Rule 8.3 to deviate
    violations involving parameter name "unused" (with an optional
    numeric suffix): it makes explicit the intention of not using such
    parameter within the function.
    
    Signed-off-by: Federico Serafini 
    Reviewed-by: Stefano Stabellini 

commit a5b90a90eee4709a3fe434e7da83b8421528e8fe
Author: Wei Liu 
Date:   Mon Mar 18 13:52:35 2024 +0100

    MAINTAINERS: remove myself from various positions
    
    I have not been active in the Xen community for some time. Update the
    MAINTAINERS file to reflect reality.
    
    Signed-off-by: Wei Liu 
    Acked-by: Stefano Stabellini 

commit ad52857efcd6e662f4ef75bc9d27368c8b99f1a5
Author: Jan Beulich 
Date:   Mon Mar 18 13:52:09 2024 +0100

    MAINTAINERS: drop AMD IOMMU and Intel VT-d sections
    
    We'd like to thank Kevin, so far the VT-d maintainer, for his past
    contributions, while at the same time we'd like to reflect reality as it
    has been for quite some time. Have VT-d maintainership (and for symmetry
    also AMD IOMMU's) fall back to the maintainers of general x86. This also
    brings things in sync with how they are for Arm.
    
    While touching the X86 section also append two so far missing slashes.
    
    Signed-off-by: Jan Beulich 
    Acked-by: Andrew Cooper 
    Acked-by: Kevin Tian 

commit 8a8d5c22afc515020669d9479b97e4ddda26d2b5
Author: Federico Serafini 
Date:   Mon Mar 18 13:51:17 2024 +0100

    perfc: add pseudo-keyword fallthrough
    
    Add pseudo-keyword fallthrough to make explicit the intention of the
    code and meet requirements to deviate MISRA C:2012 Rule 16.3
    ("An unconditional `break' statement shall terminate every
    switch-clause").
    
    No functional change.
    
    Signed-off-by: Federico Serafini 
    Acked-by: Jan Beulich 

commit 53b5208de8f3151be0729e6ac49c9b616c07c5ff
Author: Vaishali Thakkar 
Date:   Mon Mar 18 13:50:33 2024 +0100

    x86/svmdebug: Print np, sev and sev_es vmcb bits
    
    Currently only raw _np_ctrl is being printed. It can
    be informational to know about which particular bits
    are enabled. So, this commit adds the bit-by-bit decode
    for np, sev and sev_es bits.
    
    Note that while, only np is enabled in certain scenarios
    at the moment, work for enabling sev and sev_es is in
    progress. And it'll be useful to have this information as
    part of svmdebug.
    
    Signed-off-by: Vaishali Thakkar 
    Acked-by: Jan Beulich 

commit 2f09f797ba43f1182cf5ce24e9ef63cd148d385e
Author: Vaishali Thakkar 
Date:   Mon Mar 18 13:49:46 2024 +0100

    x86/svm: Drop the suffix _guest from vmcb bit
    
    The suffix _guest is redundant for asid bit. Drop it
    to avoid adding extra code volume.
    
    While we're here, replace 0/1 with false/true and use
    VMCB accessors instead of open coding.
    
    Suggested-by: Andrew Cooper 
    Signed-off-by: Vaishali Thakkar 
    Reviewed-by: Jan Beulich 
(qemu changes not included)


From xen-devel-bounces@lists.xenproject.org Tue Mar 19 17:55:31 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 17:55:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695558.1085408 (Exim 4.92)
	(envelope-from )
	id 1rmdgH-0004Ln-1Q; Tue, 19 Mar 2024 17:55:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695558.1085408; Tue, 19 Mar 2024 17:55:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmdgG-0004Lg-Us; Tue, 19 Mar 2024 17:55:20 +0000
Received: by outflank-mailman (input) for mailman id 695558;
 Tue, 19 Mar 2024 17:55:19 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmdgF-0004La-Pi
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 17:55:19 +0000
Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com
 [2a00:1450:4864:20::42c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d92ae894-e619-11ee-afdd-a90da7624cb6;
 Tue, 19 Mar 2024 18:55:18 +0100 (CET)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-33ff53528ceso2060897f8f.0
 for ; Tue, 19 Mar 2024 10:55:18 -0700 (PDT)
Received: from localhost ([85.31.135.62]) by smtp.gmail.com with ESMTPSA id
 z5-20020a5d44c5000000b0033b87c2725csm12838740wrr.104.2024.03.19.10.55.17
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 19 Mar 2024 10:55:18 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d92ae894-e619-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710870918; x=1711475718; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=pOorp9oPj27UM7coMUX9+JZpLzJHJalw1+cwFEHhakg=;
        b=HuGCQy3jiCohaW+qGkKcxIBiIZzAN/tXSPOVqndp+dKQbw+9EJHC/sgP787++e3MTQ
         ZtYPEpJGcPwmJbifvmZ/l/ceudQ9/HFiqiBXHNjZ1/nPV9PEs9/DWx9kwyOpBuLWd/5D
         RIB/aRJE+r/hmBUYaOA0WjpPBOjTkOP+psawg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710870918; x=1711475718;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=pOorp9oPj27UM7coMUX9+JZpLzJHJalw1+cwFEHhakg=;
        b=JVpdhowQc7bJgpYZjy0tYfMV1wi5zEtFhSGPNC8w8q1WpS9K3WtapoVlyamMtZaLSp
         xCbxLhxB6pNyA2tA2J30OfMvWFs9/PeUhbrrHCpKG48UEQG3ed0t6AUwI76D1DUjGgQN
         e4oAk1vVv0W87FZAR3IkvwuyCD6zIXsWjBXBHXX1GRQWEKP4xLYfVA1ejw+8dVvl0St6
         5Va18wrqeMyGrI97COJVr86oVsa019cieO+6NImEt/A7btyLU2I77i6a4z8uhScfMYw2
         0Eojuu6QaFMOOgKK7WbuOUdnRdaO+bkEw+uAcZLe98uuW1wDZyLr8tItKLRzZEQhIiqs
         6Djw==
X-Gm-Message-State: AOJu0YwqerdN1kHjDPwLfVNVmfOQU0OOaG8ViTgwZZPOygFRngf4sGP3
	+zGjmyQVIpYVe4CTiyQ0xM9xPL3ZP6ZY7LJjSezLf91OcyvY5H4mII4JMbb+M4U=
X-Google-Smtp-Source: AGHT+IECCSk49H6gp6UgFinGb3tXDmyb5T5o7xPSV/1U4MvK4o2xRAjHWBmtYxIx6BCOcBS+lwQouQ==
X-Received: by 2002:a5d:4607:0:b0:33e:7029:96bf with SMTP id t7-20020a5d4607000000b0033e702996bfmr10934084wrq.58.1710870918224;
        Tue, 19 Mar 2024 10:55:18 -0700 (PDT)
Date: Tue, 19 Mar 2024 18:55:17 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Alejandro Vallejo 
Cc: Xen-devel , Wei Liu ,
	Anthony PERARD ,
	Juergen Gross , Jan Beulich ,
	Andrew Cooper 
Subject: Re: [PATCH 2/6] tools/xc: Add xc_cpu_policy to the public xenctrl.h
 header
Message-ID: 
References: <20240109153834.4192-1-alejandro.vallejo@cloud.com>
 <20240109153834.4192-3-alejandro.vallejo@cloud.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20240109153834.4192-3-alejandro.vallejo@cloud.com>

On Tue, Jan 09, 2024 at 03:38:30PM +0000, Alejandro Vallejo wrote:
> Move struct xc_cpu_policy data structure out of xg_private.h and into
> the public xenguest.h so it can be used by libxl.

I will let Andrew comment on this one, IIRC the initial idea was to
not leak cpu_policy into libxl, and to instead have it as an opaque
object that libxl can interact with using helpers.

I haven't looked at followup patches - I assume this is done to
manipulate the cpuid data more easily from libxl, and ultimately drop
xc_xend_cpuid?

> Signed-off-by: Alejandro Vallejo 
> ---
>  tools/include/xenguest.h             |  8 +++++++-
>  tools/libs/guest/xg_private.h        | 10 ----------
>  xen/include/xen/lib/x86/cpu-policy.h |  5 +++++
>  3 files changed, 12 insertions(+), 11 deletions(-)
> 
> diff --git a/tools/include/xenguest.h b/tools/include/xenguest.h
> index e01f494b77..4e9078fdee 100644
> --- a/tools/include/xenguest.h
> +++ b/tools/include/xenguest.h
> @@ -784,7 +784,13 @@ xen_pfn_t *xc_map_m2p(xc_interface *xch,
>                        unsigned long *mfn0);
>  
>  #if defined(__i386__) || defined(__x86_64__)
> -typedef struct xc_cpu_policy xc_cpu_policy_t;
> +#include 
> +
> +typedef struct xc_cpu_policy {
> +    struct cpu_policy policy;
> +    xen_cpuid_leaf_t leaves[CPUID_MAX_SERIALISED_LEAVES];
> +    xen_msr_entry_t msrs[MSR_MAX_SERIALISED_ENTRIES];
> +} xc_cpu_policy_t;
>  
>  /* Create and free a xc_cpu_policy object. */
>  xc_cpu_policy_t *xc_cpu_policy_init(void);
> diff --git a/tools/libs/guest/xg_private.h b/tools/libs/guest/xg_private.h
> index d73947094f..d1940f1ea4 100644
> --- a/tools/libs/guest/xg_private.h
> +++ b/tools/libs/guest/xg_private.h
> @@ -170,14 +170,4 @@ int pin_table(xc_interface *xch, unsigned int type, unsigned long mfn,
>  #define M2P_SIZE(_m)    ROUNDUP(((_m) * sizeof(xen_pfn_t)), M2P_SHIFT)
>  #define M2P_CHUNKS(_m)  (M2P_SIZE((_m)) >> M2P_SHIFT)
>  
> -#if defined(__x86_64__) || defined(__i386__)
> -#include 
> -
> -struct xc_cpu_policy {
> -    struct cpu_policy policy;
> -    xen_cpuid_leaf_t leaves[CPUID_MAX_SERIALISED_LEAVES];
> -    xen_msr_entry_t msrs[MSR_MAX_SERIALISED_ENTRIES];
> -};
> -#endif /* x86 */
> -
>  #endif /* XG_PRIVATE_H */
> diff --git a/xen/include/xen/lib/x86/cpu-policy.h b/xen/include/xen/lib/x86/cpu-policy.h
> index 14724cedff..65f6335b32 100644
> --- a/xen/include/xen/lib/x86/cpu-policy.h
> +++ b/xen/include/xen/lib/x86/cpu-policy.h
> @@ -85,6 +85,11 @@ unsigned int x86_cpuid_lookup_vendor(uint32_t ebx, uint32_t ecx, uint32_t edx);
>   */
>  const char *x86_cpuid_vendor_to_str(unsigned int vendor);
>  
> +#ifndef __XEN__
> +/* Needed for MAX() */
> +#include 
> +#endif /* __XEN__ */

I think for this header it is up to the user to provide the required
context, iow: it should be tools/include/xenguest.h to include
xen-tools/common-macros.h ahead of cpu-policy.h.  Otherwise we should
likely do the same for #ifdef __XEN__ branch and include whatever
header that defines MAX().

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Mar 19 19:32:45 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 19:32:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695591.1085430 (Exim 4.92)
	(envelope-from )
	id 1rmfCF-0002cQ-W6; Tue, 19 Mar 2024 19:32:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695591.1085430; Tue, 19 Mar 2024 19:32:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmfCF-0002cJ-Sp; Tue, 19 Mar 2024 19:32:27 +0000
Received: by outflank-mailman (input) for mailman id 695591;
 Tue, 19 Mar 2024 19:32:26 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmfCE-0002c9-Lu
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 19:32:26 +0000
Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com
 [2a00:1450:4864:20::430])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 68b79038-e627-11ee-afdd-a90da7624cb6;
 Tue, 19 Mar 2024 20:32:23 +0100 (CET)
Received: by mail-wr1-x430.google.com with SMTP id
 ffacd0b85a97d-33e1d327595so3902048f8f.2
 for ; Tue, 19 Mar 2024 12:32:23 -0700 (PDT)
Received: from [10.80.67.139] (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 m2-20020a05600c3b0200b004142894df64sm5579299wms.5.2024.03.19.12.32.22
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 19 Mar 2024 12:32:22 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 68b79038-e627-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710876742; x=1711481542; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:subject:from:user-agent:mime-version:date
         :message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=QjBNX0X4WwogqDfb45E1kF0bril/tJaw/P9Q/Rx8MSI=;
        b=vRASjtQ8TUxzubkdn5hSfS67mgSZimGBcAGO3NUjmsM9hQQKLhUgYBNFwy66s0YsLF
         FmMhwiVWJBcPTeIfs8jZXEaw4vs+mkqJXyRkEi1rQ1Z+/ZlQtCuHW9WpVroKLHL6lqBc
         i0F29xJaHD9QQQ7FcHCg2P4xnUswB9q3tU35I=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710876742; x=1711481542;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:subject:from:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=QjBNX0X4WwogqDfb45E1kF0bril/tJaw/P9Q/Rx8MSI=;
        b=qhAVsSNANT6ZHOnWNNjoEP/VBOn0U40TsI9Wl7Bh0K2kISDqNo2M9MmIx/pCmTWs+Y
         vv3BpWjvyIQu4EDAZpuWcGUjScaqI9NX7+1KndPIefa5yI8JaN3/wCCzeYG5dl7dqbAN
         XR8331rf79kIjuCViKeDI6QQjcf3PMmjoeXd/B7I0rZDA6MdZrlhmsMJrTiafC+UOQCE
         bgjaCjfbJgHK1/ofXyJfWyeEXfW2wBN1MYfgZaOVs+yBV3cL1NR7vs9CvkCCS9J9NZRr
         T0oohWfwn4vuvA5qcexnGQ/BDlmJG4dqbn4/wFuZpA3iRwNAeSO3lZWCuSWlJjRayCvE
         Lc0Q==
X-Forwarded-Encrypted: i=1; AJvYcCXvprfjaQ0FGYAN/wNUaWRGiwcI6SqXhzuh3fJMSwaJ1SBo/nIeB0ppHobG9Ulrbnk9CdLltPnBVVyIQPMfp4F1mhhBc7l6Kh4m1g53r1c=
X-Gm-Message-State: AOJu0YzbreH6Ey8dvgt71K8ccEy7dZVNvm10oaIv50nJDgKzioBuvyOq
	rguBGzvufIdYrnPq7rQYY7LWBhH8cF4tr3PT/Aq2NPO5yxL1q8PbgXU+dKt/LbI=
X-Google-Smtp-Source: AGHT+IGAHXsT6sdsmLcdmOjdcLCUGGNTK3ONiJOuzzDKornYQ2xzyc0vt951QiV4T/juuu5KmNHGFw==
X-Received: by 2002:adf:e68c:0:b0:33e:1a96:2be7 with SMTP id r12-20020adfe68c000000b0033e1a962be7mr9084633wrm.11.1710876742565;
        Tue, 19 Mar 2024 12:32:22 -0700 (PDT)
Message-ID: <7f44c5cd-2e50-4262-a9bd-dacd313f82bc@citrix.com>
Date: Tue, 19 Mar 2024 19:32:21 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Andrew Cooper 
Subject: Re: [PATCH] x86/mm: fix detection of last L1 entry in
 modify_xen_mappings_lite()
To: Jan Beulich , Roger Pau Monne 
Cc: Wei Liu , xen-devel@lists.xenproject.org
References: <20240311105416.4556-1-roger.pau@citrix.com>
 
Content-Language: en-GB
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 11/03/2024 11:29 am, Jan Beulich wrote:
> On 11.03.2024 11:54, Roger Pau Monne wrote:
>> The current logic to detect when to switch to the next L1 table is incorrectly
>> using l2_table_offset() in order to notice when the last entry on the current
>> L1 table has been reached.
>>
>> It should instead use l1_table_offset() to check whether the index has wrapped
>> to point to the first entry, and so the next L1 table should be used.
>>
>> Fixes: 8676092a0f16 ('x86/livepatch: Fix livepatch application when CET is active')
>> Signed-off-by: Roger Pau Monné 
>> ---
>> This fixes the osstest livepatch related crash, we have been lucky so far that
>> the .text section didn't seem to have hit this.
> About half a megabyte more to go until .text could run into such an issue,
> I guess, just considering the core Xen image. Patches are presumably not
> large enough to stand a sufficient risk of hitting the issue.
>
> I think there's another latent problem though, related to this part of the
> comment ahead of the function:
>
>  * It is the callers responsibility to not pass s or e in the middle of
>  * superpages if changing the permission on the whole superpage is going to be
>  * a problem.
>
> This only suggests that for a pointer into the middle of a superpage the
> effect may be wider than intended. But with s misaligned modulo 2Mb the
> superpage part of the loop would keep v misaligned, and if the 2nd 2Mb
> range wasn't a superpage, part of the range wouldn't be touched at all.
> Right now with .text always 2Mb-aligned (and with there not being a
> superpage mapping across _srodata) there's no issue as long as superpages
> aren't used in patch loading. Yet recall that .text used to be only 1Mb
> aligned in older Xen versions, and this fact isn't entirely set in stone
> when !XEN_ALIGN_2M.

That comment was added at your request.

The start address is always going to a linker symbol in the main image,
or something allocated with MAP_SMALL_PAGES.

Xen's .text strictly is 2M aligned.  The boot time pagetable handling
doesn't otherwise.

But either way.  The two options are to either ASSERT() that v is 2M
aligned when finding PSE, or to realign it on each iteration.  I'd
prefer to go with the assert on the basis that I don't expect this
property to be violated in practice.

I also note that forcing page alignment on e is useless.  All it does is
force the caller to do pointless work.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Mar 19 19:59:09 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 19:59:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695596.1085439 (Exim 4.92)
	(envelope-from )
	id 1rmfbz-0005wO-St; Tue, 19 Mar 2024 19:59:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695596.1085439; Tue, 19 Mar 2024 19:59:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmfbz-0005wH-QJ; Tue, 19 Mar 2024 19:59:03 +0000
Received: by outflank-mailman (input) for mailman id 695596;
 Tue, 19 Mar 2024 19:59:02 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmfby-0005wB-Tp
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 19:59:02 +0000
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com
 [2a00:1450:4864:20::135])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2017d3ba-e62b-11ee-a1ee-f123f15fe8a2;
 Tue, 19 Mar 2024 20:58:59 +0100 (CET)
Received: by mail-lf1-x135.google.com with SMTP id
 2adb3069b0e04-513d717269fso6451611e87.0
 for ; Tue, 19 Mar 2024 12:58:59 -0700 (PDT)
Received: from andrewcoop.citrite.net (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 kh18-20020a170906f81200b00a46e56c8764sm842510ejb.114.2024.03.19.12.58.57
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 19 Mar 2024 12:58:57 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2017d3ba-e62b-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710878338; x=1711483138; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:from:to:cc:subject:date:message-id:reply-to;
        bh=Dnd2ncmF40q2ujF48d5KIjxHE2C/jzeKs+Sg+1pVP2A=;
        b=MYz77H4dl1+qh6JWn20dX6nh0ZPfbSAAF3sMGk/IEnbyZePAZrPXr0kEEvIMj11Fhy
         dFMwuEOJ323Vs2LnKNSmoDnpcfxvYECyMrSt1ijWrgXOfa76VORS1o9S8OfUqeyyfKg9
         1nGfiIdJsinpu68CBcWZon/rME5MWi7FMfBBY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710878338; x=1711483138;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=Dnd2ncmF40q2ujF48d5KIjxHE2C/jzeKs+Sg+1pVP2A=;
        b=BJmB1Wdgk6LecKanAsOWDUSgSmc8upNpsGMPcDlGYr2mmB3BNSKLBv/q0xtBqCRHOf
         paIRQ/xM9JZ3kkaCgLPGTcC706HIU6xbYlCjutWwZo4dRZcSdikdf05lTumPC0/ZdIUa
         2ASTMIYlwt52j/M8hKKvXroEBPQrWjfYSpHuy6ulDGnaDSDMpVWTsF0T7wejOMHauc3u
         uzgfqxoaFwaeBk6JVaJN7aAGKxjoqXQS4tu6I5wRZmrhSP/hw3chY4xOs/K/xREMUmj3
         l2LxIWHMcjs1RG+JRwW73QDRWSDMloEgWjKVTjp4xynHIoebOKuLITLrjEJ+ZwkfwOZR
         LIow==
X-Gm-Message-State: AOJu0YztVlWV4ui6ZfHtoAcF1n9O/H7AZ5JUolLVjWKspnaDRgIBXmWm
	4QlvAzi1tLlqybf1w3jPW/tzhc88Ou10FBsv9KnR2xWZJUqbOeDAmxgzkUPPh0PwjmZi4eJXjK+
	P
X-Google-Smtp-Source: AGHT+IHDX4URLJwlzFgDvpJkATEYmvJ+F7reMXfQ2WfDt1QXhQsJ3s7lWm/pr/IG9SM/PYMRHqRxVw==
X-Received: by 2002:a19:6417:0:b0:513:e945:e9a7 with SMTP id y23-20020a196417000000b00513e945e9a7mr119993lfb.4.1710878337841;
        Tue, 19 Mar 2024 12:58:57 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH] x86/mm: Refine address alignment checks in modify_xen_mappings_lite()
Date: Tue, 19 Mar 2024 19:58:56 +0000
Message-Id: <20240319195856.4172284-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.30.2
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Require 's' to be superpage aligned if given over a superpage mapping.  This
is expected to be the case in practice, and prevents the v getting misaligned
over superpages during the processing loop.

Rmove the requirement for 'e' to be page aligned.  All this is doing is
forcing work for the caller just to satisfy an assertion.

Reported-by: Jan Beulich 
Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
---
 xen/arch/x86/mm.c           | 10 ++++++----
 xen/common/virtual_region.c |  8 ++++----
 2 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 62f5b811bbe8..018d21f8bd92 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -5900,9 +5900,9 @@ int destroy_xen_mappings(unsigned long s, unsigned long e)
  *
  * Must be limited to XEN_VIRT_{START,END}, i.e. over l2_xenmap[].
  * Must be called with present flags, and over present mappings.
- * It is the callers responsibility to not pass s or e in the middle of
- * superpages if changing the permission on the whole superpage is going to be
- * a problem.
+ * It is the callers repsonsibility to pass 's' on a PAGE/SUPERPAGE boundary,
+ * and for there to not be anything interesting in the PAGE/SUPERPAGE
+ * following 'e'.
  */
 void init_or_livepatch modify_xen_mappings_lite(
     unsigned long s, unsigned long e, unsigned int nf)
@@ -5917,7 +5917,7 @@ void init_or_livepatch modify_xen_mappings_lite(
 
     ASSERT(flags & _PAGE_PRESENT);
     ASSERT(IS_ALIGNED(s, PAGE_SIZE) && s >= XEN_VIRT_START);
-    ASSERT(IS_ALIGNED(e, PAGE_SIZE) && e <= XEN_VIRT_END);
+    ASSERT(e <= XEN_VIRT_END);
 
     while ( v < e )
     {
@@ -5929,6 +5929,8 @@ void init_or_livepatch modify_xen_mappings_lite(
 
         if ( l2e_get_flags(l2e) & _PAGE_PSE )
         {
+            ASSERT(IS_ALIGNED(v, 1 << L2_PAGETABLE_SHIFT));
+
             l2e_write_atomic(pl2e, l2e_from_intpte((l2e.l2 & ~fm) | flags));
 
             v += 1UL << L2_PAGETABLE_SHIFT;
diff --git a/xen/common/virtual_region.c b/xen/common/virtual_region.c
index b4325bcda71e..142f21e18153 100644
--- a/xen/common/virtual_region.c
+++ b/xen/common/virtual_region.c
@@ -93,11 +93,11 @@ void relax_virtual_region_perms(void)
     list_for_each_entry_rcu( region, &virtual_region_list, list )
     {
         modify_xen_mappings_lite((unsigned long)region->text_start,
-                                 PAGE_ALIGN((unsigned long)region->text_end),
+                                 (unsigned long)region->text_end,
                                  PAGE_HYPERVISOR_RWX);
         if ( region->rodata_start )
             modify_xen_mappings_lite((unsigned long)region->rodata_start,
-                                     PAGE_ALIGN((unsigned long)region->rodata_end),
+                                     (unsigned long)region->rodata_end,
                                      PAGE_HYPERVISOR_RW);
     }
     rcu_read_unlock(&rcu_virtual_region_lock);
@@ -111,11 +111,11 @@ void tighten_virtual_region_perms(void)
     list_for_each_entry_rcu( region, &virtual_region_list, list )
     {
         modify_xen_mappings_lite((unsigned long)region->text_start,
-                                 PAGE_ALIGN((unsigned long)region->text_end),
+                                 (unsigned long)region->text_end,
                                  PAGE_HYPERVISOR_RX);
         if ( region->rodata_start )
             modify_xen_mappings_lite((unsigned long)region->rodata_start,
-                                     PAGE_ALIGN((unsigned long)region->rodata_end),
+                                     (unsigned long)region->rodata_end,
                                      PAGE_HYPERVISOR_RO);
     }
     rcu_read_unlock(&rcu_virtual_region_lock);

base-commit: 188fa82305e72b725473db9146e20cc9abf7bff3
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Tue Mar 19 20:04:17 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 20:04:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695599.1085450 (Exim 4.92)
	(envelope-from )
	id 1rmfgy-0007Sq-FE; Tue, 19 Mar 2024 20:04:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695599.1085450; Tue, 19 Mar 2024 20:04:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmfgy-0007Sj-Bu; Tue, 19 Mar 2024 20:04:12 +0000
Received: by outflank-mailman (input) for mailman id 695599;
 Tue, 19 Mar 2024 20:04:11 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmfgx-0007Sd-96
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 20:04:11 +0000
Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com
 [2607:f8b0:4864:20::831])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d8a55f9b-e62b-11ee-a1ee-f123f15fe8a2;
 Tue, 19 Mar 2024 21:04:09 +0100 (CET)
Received: by mail-qt1-x831.google.com with SMTP id
 d75a77b69052e-430acf667afso28043061cf.1
 for ; Tue, 19 Mar 2024 13:04:09 -0700 (PDT)
Received: from [10.80.67.139] (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 gc4-20020a05622a59c400b00430e8d3ecb0sm1025896qtb.14.2024.03.19.13.04.06
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 19 Mar 2024 13:04:07 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d8a55f9b-e62b-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710878647; x=1711483447; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=tObnPGozjIVJamnHKKQTDznJGiaX1sldN4GuDqnNO4Q=;
        b=keYF+pwk1FOjZ8k/G4mCny9T8To3eHR0In+788opdNx/jP80P6LMV2m29Y5JP/f/96
         MWxu8Uz1zG9AEiCvJx6JPxq/DXCu8YCpTpPqUq60KNqppyVxg9f2uK+sosApHBemO+G7
         npSRzhz7MCHkqsdOA/LHrw78Bi7v0v3YBqSQk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710878647; x=1711483447;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=tObnPGozjIVJamnHKKQTDznJGiaX1sldN4GuDqnNO4Q=;
        b=bKD1CR7tWeHfGXQ9qob3/TO+L6k/T3b55RQQz+adZkcexIM4FbeoxGof7RLoO/2mMP
         +e0PUkP7YkBjxMuusM2SHB70273GH6T5G/fk7m6EgSjICtnVwRh0+GU8yO5qrMyA5wwu
         A5ZF35gwLU7glgs3WPpV8mQxP826+7CF3ef0K1oZ3p2DjFS0p2zROnkE5+KzbDQReqnJ
         CjZzMM8KMzY1a28UPeSM2Qgk2cwxpswyjTzIF/jME4w8B/URt2kDHEuwRy1DVdD+MHwK
         hmrjIB9+L38feVCkh2owBKb+mlKiRQpgcdlDN9OTyBVTIqw5wCjsPoMJoWyjo/KEwdw5
         WMFA==
X-Gm-Message-State: AOJu0YzMQO4M+tP4xqTf8TJ1fU3ZM4fM32KcxnXeUxvkN3ARigHs1OU7
	831iajCevwiCPI/amfHEcqcHL0u/80aqN2dDflo5eEPkAnQgOEh//Pjt0mlvTlTXhE/hiS41tUr
	k
X-Google-Smtp-Source: AGHT+IE+HqTbAJX2Om/aBZgkdcnSmUFdvB70r0r0KU+sBvJttlhmv+96CSAWeUTXZULzbOwX4x46OQ==
X-Received: by 2002:ac8:5848:0:b0:430:b6e6:1c28 with SMTP id h8-20020ac85848000000b00430b6e61c28mr4038983qth.25.1710878647505;
        Tue, 19 Mar 2024 13:04:07 -0700 (PDT)
Message-ID: 
Date: Tue, 19 Mar 2024 20:04:05 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/mm: Refine address alignment checks in
 modify_xen_mappings_lite()
Content-Language: en-GB
To: Xen-devel 
Cc: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 
References: <20240319195856.4172284-1-andrew.cooper3@citrix.com>
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <20240319195856.4172284-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 19/03/2024 7:58 pm, Andrew Cooper wrote:
> Require 's' to be superpage aligned if given over a superpage mapping.  This
> is expected to be the case in practice, and prevents the v getting misaligned
> over superpages during the processing loop.
>
> Rmove the requirement for 'e' to be page aligned.  All this is doing is

"Remove".  Fixed locally.

> forcing work for the caller just to satisfy an assertion.
>
> Reported-by: Jan Beulich 
> Signed-off-by: Andrew Cooper 
> ---
> CC: Jan Beulich 
> CC: Roger Pau Monné 

Code-gen wise, this drops 2x

48 8d b0 ff 0f 00 00    lea    0xfff(%rax),%rsi
48 81 e6 00 f0 ff ff    and    $0xfffffffffffff000,%rsi

from {relax,tighten}_virtual_region_perms().

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Mar 19 20:36:13 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 20:36:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695603.1085459 (Exim 4.92)
	(envelope-from )
	id 1rmgBk-0003ZM-Vw; Tue, 19 Mar 2024 20:36:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695603.1085459; Tue, 19 Mar 2024 20:36:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmgBk-0003ZF-So; Tue, 19 Mar 2024 20:36:00 +0000
Received: by outflank-mailman (input) for mailman id 695603;
 Tue, 19 Mar 2024 20:36:00 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmgBj-0003Z9-V6
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 20:35:59 +0000
Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com
 [2a00:1450:4864:20::22e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4a5fc92f-e630-11ee-a1ee-f123f15fe8a2;
 Tue, 19 Mar 2024 21:35:57 +0100 (CET)
Received: by mail-lj1-x22e.google.com with SMTP id
 38308e7fff4ca-2d2505352e6so68116241fa.3
 for ; Tue, 19 Mar 2024 13:35:57 -0700 (PDT)
Received: from [10.80.67.139] (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 r7-20020a05600c35c700b0041409fa57c4sm10813404wmq.34.2024.03.19.13.35.56
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 19 Mar 2024 13:35:56 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4a5fc92f-e630-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710880557; x=1711485357; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=m7McJ6S66+ecWQRpPnVmoi5TAzuw97Xo7wL7THoklmQ=;
        b=pdTnQqbTsvHVF4GBp6brMmg9zFCLBxdyqDjWAWMRJcvxF9o3EUTt9J1FwIIjqf8UoF
         f8cgYm2J8I83xBGWPM7SvfxPLLkxjznxaDJ7RTcNQ/u2i0B5BTRLD5C0qG3HOl+NXu2D
         p9YoUD8m9tTarK4MGZyD8djWcqu3lJbUQbA4s=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710880557; x=1711485357;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=m7McJ6S66+ecWQRpPnVmoi5TAzuw97Xo7wL7THoklmQ=;
        b=NdB8ignnLyvLAXKWxbFLH1HQUWe1mIJcEZ/yJuvuN+7k9f6zXNegXz2baeSkAPW9fT
         USNV5gt52xwtYFWxnoAzuvPvQQWdohk4UoXdjBsomjN+6lWWbOepzfdBZbdudz0m1dPR
         SmYln+ugEPDtCy+uo4YuVqhhXhPRu3MOEgFEG1J5ZeeejqhU9ejKVDcHITWjdMcWiarI
         0dC5tQNrkKCp099XxSxoIxMKgWJHay+0NWSoyRqb9VZH0UJb5bglGcXKRG8XtWQ50l8E
         BINUA3oxvzqZHm58hO2aBiv4/LCp5wCWmuXtnv2kCezcU0vFeNlK8ME284KNAp+oVDVz
         Vmrg==
X-Forwarded-Encrypted: i=1; AJvYcCXri5DesEP6yWy/dPckUrfRUmr3eOr58Ir7cCIDuDgZ7WpsmFoGfOO2/0u+c7LwQrovJCsOL5MQccKHkHEfEvcxd7b/+RQSuJ0orJ7tlRs=
X-Gm-Message-State: AOJu0YyapgYg5/3KfodOvSGsOyfog82FV/6ZDSi14J8nPs62BpWPkbxn
	l6ilfggz4RTBM2OWrrV7qAfwF/dxquVQlDnzTtVpUVsrA/yjNHrmAobIeBbbcgU=
X-Google-Smtp-Source: AGHT+IGWusMg3EYh+yHBDa5ijJ5T0vjRiptIo66FZX2EiBxTXHLbtLOMtEYejZd4ytjp/m+wIVIoZg==
X-Received: by 2002:a2e:9019:0:b0:2d4:6e71:59ef with SMTP id h25-20020a2e9019000000b002d46e7159efmr10204905ljg.5.1710880557030;
        Tue, 19 Mar 2024 13:35:57 -0700 (PDT)
Message-ID: <1c3d790d-bdac-495a-868b-36e12d45c457@citrix.com>
Date: Tue, 19 Mar 2024 20:35:56 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86: adjust initial setting of watchdog kind
Content-Language: en-GB
To: Jan Beulich ,
 "xen-devel@lists.xenproject.org" 
Cc: George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: 
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 25/01/2024 2:12 pm, Jan Beulich wrote:
> "watchdog_timeout=0" is documented to disable the watchdog. Make sure
> this also is true when there's a subsequent "watchdog" command line
> option (and no further "watchdog_timeout=" one).

We also document that latest takes precedence, at which point "watchdog"
would re-activate.

>
> While there also switch watchdog_setup() to returning void, bringing it
> in line with the !CONFIG_WATCHDOG case. Further amend command line
> documentation to also mention the implicit effect of specifying a non-
> zero timeout.
>
> Signed-off-by: Jan Beulich 
> ---
> Alternatively "watchdog" following "watchdog_timeout=0" could be taken
> to mean to use the default timeout again.

I realise that watchdog_timeout is my fault, but in fairness it was an
early change of mine in Xen and didn't exactly get the kind of review it
would get these days.  It also wasn't used by XenServer in the end - we
just stayed at a default 5s.

I'm very tempted to suggest deleting watchdog_timeout, and extending
watchdog= to have `force |  | s` so you could specify e.g.
`watchdog=10s`.

The watchdog is off by default so I don't expect this will impact
people.  It is also more convenient for the end user, and means that we
don't have have the current split approach of two separate options
fighting for control over each other.

It also means we we can in principle support non-integer-second units of
time in a theoretical future when the NMI handler can count time properly.

> Really I think the comment in watchdog_setup() is wrong, and the
> function would hence better go away.

That comment dates from 2006.  I highly suspect it's not true any more,
and it certainly is odd to be running over all CPUs like that.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Mar 19 20:51:52 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 20:51:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695606.1085470 (Exim 4.92)
	(envelope-from )
	id 1rmgR1-0006sH-8y; Tue, 19 Mar 2024 20:51:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695606.1085470; Tue, 19 Mar 2024 20:51:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmgR1-0006sA-6B; Tue, 19 Mar 2024 20:51:47 +0000
Received: by outflank-mailman (input) for mailman id 695606;
 Tue, 19 Mar 2024 20:51:45 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmgQz-0006s4-Lw
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 20:51:45 +0000
Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com
 [2607:f8b0:4864:20::831])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7e417d2e-e632-11ee-afdd-a90da7624cb6;
 Tue, 19 Mar 2024 21:51:44 +0100 (CET)
Received: by mail-qt1-x831.google.com with SMTP id
 d75a77b69052e-430c41f3f89so2877631cf.0
 for ; Tue, 19 Mar 2024 13:51:44 -0700 (PDT)
Received: from [10.80.67.139] (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 bw7-20020a05622a098700b00430cc9ca5ffsm3251967qtb.81.2024.03.19.13.51.41
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 19 Mar 2024 13:51:42 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7e417d2e-e632-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710881503; x=1711486303; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=9ssBcy+nyWsJ8bmEaXd//Ag4IkIIyUhjb0uq6ZyMtjI=;
        b=auG+hlZPsUlqD8YibDK41xMUlbu1+VitJG8J0w2KmnldSLBxyMJuVmerjTU1WAQVV9
         aQhNkQUbxtgoPH6pWVb8mggjbtV6ZhNBxRV59IcqbCXnIil0Ox/5p5M67K+AQIG+C9mr
         vH85Sy3vNHT3jdO1kbKnNR+cnGAQZxImFZutE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710881503; x=1711486303;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=9ssBcy+nyWsJ8bmEaXd//Ag4IkIIyUhjb0uq6ZyMtjI=;
        b=qjeeBpDAI/fsx0olWTWIfG/nG7xj5BfrlEOdsMfeOhbcQzdqHMTRWIajW7/RZoRGRE
         xv0AqKiNrF0ZoeDFnd5xj0KIWbXMqPFB3Owc/UyX0DqN7qy9XWHYH/NJBBdA5KzQmGiX
         PJha4demosvLYPAeh0EAMSrk10JhdyYMM5HRHdNKIIhqEVb9GcfK9UfDornsZFoZv+dS
         TQUe1tyKsq8ImRY0ev20YTq4qaJgj5ceiysVrtdz3aiNU7Retl++ORc5wUhEE5A0kcZk
         j7fkq6LLuiolOeALjAzknEKt7xtFqNkxgPG+lT8Isd/1z6qFUpCkrmmVSRWGBr385eBD
         90TA==
X-Forwarded-Encrypted: i=1; AJvYcCW3A94azSVsnt6ISqlXiY51OWiUWNb9N3uqiO4ecNGAgNjm4Laif4/nkJaEui63DmZvgnYTCdgZTFYlr+dY93/dB83Xm3EvObfqiSwr1vQ=
X-Gm-Message-State: AOJu0YxSFJ7UFiOLUUjlB1c1g5mZQxp3QtLF24nv/pMCkvOQRcNA/8g4
	y74kVtudgXvecrPZsHfMEHtehO6qOeRyhlOJ8JJuesafvtmrF7zf4uzBTPz3vwk=
X-Google-Smtp-Source: AGHT+IEU/owLiZ1iXm5qel7/stcnGoWAYql2UkQey8BE6Q1zAN0tj5BvYg8+IVJBjyyhnHCn5ybDFA==
X-Received: by 2002:a05:622a:a091:b0:430:fff3:aa9f with SMTP id jv17-20020a05622aa09100b00430fff3aa9fmr307244qtb.18.1710881503130;
        Tue, 19 Mar 2024 13:51:43 -0700 (PDT)
Message-ID: <61b8e8a6-ab9d-434d-88dc-9ea4a082375b@citrix.com>
Date: Tue, 19 Mar 2024 20:51:40 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86: increase NMI timer frequency if necessary
Content-Language: en-GB
To: Jan Beulich ,
 "xen-devel@lists.xenproject.org" 
Cc: Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 
References: 
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 25/01/2024 4:55 pm, Jan Beulich wrote:
> Since the performance counters used for the NMI watchdog count non-
> halted cycles, they may count at a rate higher than cpu_khz.

Is this in theory, or observed in practice?

It is my understanding that perf counters count in P0 reference cycles,
and not at the Turbo/CBS rate.

>  Thus the
> watchdog tick may occur more frequently than invocations of the timer
> if we don't account for the ratio between nominal and maximum CPU clock
> speeds, which would be a problem in particular when "watchdog_timeout=1"
> is in effect (for high enough ratios even larger timout values may pose
> a problem).
>
> Leverage the so far display-only data we collect on newer Intel and AMD
> CPUs. On older CPUs we just have to (continue to) hope that the default
> frequency of 1 Hz is okay(-ish) to use.
>
> While adding the new variable, also move the (now adjacent) cpu_khz to
> .data.ro_after_init.
>
> Signed-off-by: Jan Beulich 
> ---
> This renders the "log" in the function names somewhat stale, but I don't
> think this strictly warrants renaming the functions right away.

I'm not comfortable with this change.  It's adding to a complicated
timing problem, rather than simplifying it.

The real problem we've got is that the NMI handler is guessing at the
timeout by counting NMIs, not by actually counting time.  There are
several ways to fix this even with the current rendezvous logic.  When
the NMI handler can actually say "if ( NOW() - last > timeout )", then
the exact frequently of NMIs becomes far less important.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Mar 19 20:59:06 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 20:59:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695610.1085490 (Exim 4.92)
	(envelope-from )
	id 1rmgY5-0007yI-5O; Tue, 19 Mar 2024 20:59:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695610.1085490; Tue, 19 Mar 2024 20:59:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmgY5-0007yB-2j; Tue, 19 Mar 2024 20:59:05 +0000
Received: by outflank-mailman (input) for mailman id 695610;
 Tue, 19 Mar 2024 20:59:04 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmgY4-0007xt-LO
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 20:59:04 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on20600.outbound.protection.outlook.com
 [2a01:111:f403:2009::600])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 83eae5a2-e633-11ee-afdd-a90da7624cb6;
 Tue, 19 Mar 2024 21:59:03 +0100 (CET)
Received: from DS7PR05CA0010.namprd05.prod.outlook.com (2603:10b6:5:3b9::15)
 by PH7PR12MB6720.namprd12.prod.outlook.com (2603:10b6:510:1b3::17) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.26; Tue, 19 Mar
 2024 20:59:00 +0000
Received: from DS2PEPF0000343F.namprd02.prod.outlook.com
 (2603:10b6:5:3b9:cafe::78) by DS7PR05CA0010.outlook.office365.com
 (2603:10b6:5:3b9::15) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.12 via Frontend
 Transport; Tue, 19 Mar 2024 20:59:00 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 DS2PEPF0000343F.mail.protection.outlook.com (10.167.18.42) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Tue, 19 Mar 2024 20:58:59 +0000
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Tue, 19 Mar
 2024 15:58:58 -0500
Received: from fedora.mshome.net (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Tue, 19 Mar 2024 15:58:57 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 83eae5a2-e633-11ee-afdd-a90da7624cb6
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=QP4kE3KnwdB6lhcrw2PbDmWLMdjKfDzlEXaqY18R1HCVWfZvT371alStIsDrIK7/eH8QyygOT3DntguKx+1yMipEIqDPnk2x5dsH7kaq2urbezQ3vlzz48Bmeb3mRW2rfSbquaqN9HLcnfjVbe7xbBk/8Imo+dbJmThGwvCv1RL2sHKW9jJhKgLXFkTqKtwxerehKA54TIISM2P2VcLlYJul99pi/lRAg0pl2Fww0tK72cVeIwWyoBazjp6yRXr41oawEf/acb6tp/AuMLjCeCR53pqNuDSLZttY1fuKPxj/H4U5Qme3yynhr9IWO3lpyvN93Heyoy/qCcGC9moylg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=lvOehq1EJKjZfWXBSzZg1ZZ1p5IUUk1AykmRfeyalZA=;
 b=PNCHOtDTdMxWeRKFvqUNxWU5nbQ+c+vQ9tn5TwxRenqmNtjD9wycLeGwRmzP5sDXm3wYF5Cuhu131QR2SOV0OPkml07VXm3IFCT9EzbU3YqR6Z+xaYZ2ZirtNqLrlg10sSCEUieTi0kEq0Nxj3MPMUvHyStmjZxwA+tB2Q2wN4PKreyOLg4iWTunA9kKq4wRgJJmaN8QFYhWP5h1DDPJJWSS8z4L//FbLSimY2VXU3rvk4PRXw+kIVLPJTcRoGXZ+Koa8aXviAJOgFTDgSAAGI6FUgdQrm+0Sd0QMjtdobuEoOk3nbPwGTCQfQSOYFBke/no4nxHBXOZ+cJ38x+Kgw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=lvOehq1EJKjZfWXBSzZg1ZZ1p5IUUk1AykmRfeyalZA=;
 b=dFwlsOiV0hwdksokGnZ4VQqmaIBeTPFwnS+lpUu6pL3/JlXCNC8Jn7NHYeIsKm7Df+hMPzoJXDWsKF+FeRZ4BX/RBdxuFzGDkk407MgiUfpH46+sYjrfhNBwsghQBY29+MWRbkVmo5c2O3wx5LtQhohvzkCxCnzI0ho4wXgtLNI=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
From: Jason Andryuk 
To: 
CC: Jason Andryuk , Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Wei Liu
	
Subject: [PATCH v3 1/3] Revert "xen/x86: bzImage parse kernel_alignment"
Date: Tue, 19 Mar 2024 16:58:47 -0400
Message-ID: <20240319205849.115884-2-jason.andryuk@amd.com>
X-Mailer: git-send-email 2.44.0
In-Reply-To: <20240319205849.115884-1-jason.andryuk@amd.com>
References: <20240319205849.115884-1-jason.andryuk@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB03.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DS2PEPF0000343F:EE_|PH7PR12MB6720:EE_
X-MS-Office365-Filtering-Correlation-Id: e1b8378e-132a-4a54-f0fd-08dc4857669a
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	r8OnCdXJb+tokcrlhn8iiEY+4Fun5Gr7Fg3nCYPHg5/CIaOrIJiqiuCcitCL/jifBkrffIJEvH9xt7w0GYklEghfFC3WZlEJov1UCm88RVXzkP6B+XxrizgSJfvY9CvMk9cKlfxA6+XEfpAfrhrbW9PfngFJC+mtkzHk7Iz6Bshedvtz4Rkh4XCCWRRz6IUyGDogAPV8juC2+gkXebA9cudyWYmRn6pPhMPU3GZwQZhC7qEbR8tot0Lb2zJHLoPif89xonVpk4exUpZqC9Fe3Evn15Xs7yA071uDjAeG2fFxGNRJkhYGPZcJdk0rFhnx9WSCwYTGMoNA/BSEegth7Y7uPCfc/t2Ql6qXsQAni+jPnpBKygCo7Ee+f4n+PwV7UDRzspCtEctH5s4weKDs32fGPplIVSsBv5LN6ZjM81YfExpLoF7RhNrC9iYvcviGYdrPmq0Cb4QG/rlA5lj/zmyWQSLWzmlhmGNtEVZB8bjw92kx5GPitY3RbjBndbiV7oCU2omdIwUcCkM2JZfWvDvruDqAD/7fjIHVJw6VGxN/Y5yVBAwd+i57eBU/sSPfkdfHiCctw0UNUUN96HrDd7GFIIgZnTMtoMW/O9pdn7TCSabMuH47/qgXkkktuBpn2kPZC/HJlhxBIFiJH1O9VmNTtzRGlhyHTQ/mQT/vxbPP0UswNm1tkHTYCtWPqKHIfy8cKEqNXUg00nDqdxBy+xDq1kVpfk9Qmy+vsWR3nHvRohIPNWm+62IcutNQKc4p
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(376005)(1800799015)(82310400014)(36860700004);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Mar 2024 20:58:59.9771
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: e1b8378e-132a-4a54-f0fd-08dc4857669a
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DS2PEPF0000343F.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB6720

A new ELF note will specify the alignment for a relocatable PVH kernel.
ELF notes are suitable for vmlinux and other ELF files, so this
Linux-specific bzImage parsing in unnecessary.

This reverts commit c44cac229067faeec8f49247d1cf281723ac2d40.

Signed-off-by: Jason Andryuk 
---
 xen/arch/x86/bzimage.c             | 4 +---
 xen/arch/x86/hvm/dom0_build.c      | 4 +---
 xen/arch/x86/include/asm/bzimage.h | 2 +-
 xen/arch/x86/pv/dom0_build.c       | 2 +-
 4 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/xen/arch/x86/bzimage.c b/xen/arch/x86/bzimage.c
index 0f4cfc49f7..ac4fd428be 100644
--- a/xen/arch/x86/bzimage.c
+++ b/xen/arch/x86/bzimage.c
@@ -105,7 +105,7 @@ unsigned long __init bzimage_headroom(void *image_start,
 }
 
 int __init bzimage_parse(void *image_base, void **image_start,
-                         unsigned long *image_len, unsigned int *align)
+                         unsigned long *image_len)
 {
     struct setup_header *hdr = (struct setup_header *)(*image_start);
     int err = bzimage_check(hdr, *image_len);
@@ -118,8 +118,6 @@ int __init bzimage_parse(void *image_base, void **image_start,
     {
         *image_start += (hdr->setup_sects + 1) * 512 + hdr->payload_offset;
         *image_len = hdr->payload_length;
-        if ( align )
-            *align = hdr->kernel_alignment;
     }
 
     if ( elf_is_elfbinary(*image_start, *image_len) )
diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index bbae8a5645..0ceda4140b 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -548,14 +548,12 @@ static int __init pvh_load_kernel(struct domain *d, const module_t *image,
     struct elf_binary elf;
     struct elf_dom_parms parms;
     paddr_t last_addr;
-    unsigned int align = 0;
     struct hvm_start_info start_info = { 0 };
     struct hvm_modlist_entry mod = { 0 };
     struct vcpu *v = d->vcpu[0];
     int rc;
 
-    rc = bzimage_parse(image_base, &image_start, &image_len, &align);
-    if ( rc != 0 )
+    if ( (rc = bzimage_parse(image_base, &image_start, &image_len)) != 0 )
     {
         printk("Error trying to detect bz compressed kernel\n");
         return rc;
diff --git a/xen/arch/x86/include/asm/bzimage.h b/xen/arch/x86/include/asm/bzimage.h
index 2e04f5cc7b..7ed69d3910 100644
--- a/xen/arch/x86/include/asm/bzimage.h
+++ b/xen/arch/x86/include/asm/bzimage.h
@@ -6,6 +6,6 @@
 unsigned long bzimage_headroom(void *image_start, unsigned long image_length);
 
 int bzimage_parse(void *image_base, void **image_start,
-                  unsigned long *image_len, unsigned int *align);
+                  unsigned long *image_len);
 
 #endif /* __X86_BZIMAGE_H__ */
diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c
index e9fa8a9a82..d8043fa58a 100644
--- a/xen/arch/x86/pv/dom0_build.c
+++ b/xen/arch/x86/pv/dom0_build.c
@@ -416,7 +416,7 @@ int __init dom0_construct_pv(struct domain *d,
 
     d->max_pages = ~0U;
 
-    if ( (rc = bzimage_parse(image_base, &image_start, &image_len, NULL)) != 0 )
+    if ( (rc = bzimage_parse(image_base, &image_start, &image_len)) != 0 )
         return rc;
 
     if ( (rc = elf_init(&elf, image_start, image_len)) != 0 )
-- 
2.44.0



From xen-devel-bounces@lists.xenproject.org Tue Mar 19 20:59:06 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 20:59:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695609.1085480 (Exim 4.92)
	(envelope-from )
	id 1rmgY2-0007jk-Vf; Tue, 19 Mar 2024 20:59:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695609.1085480; Tue, 19 Mar 2024 20:59:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmgY2-0007jd-Sp; Tue, 19 Mar 2024 20:59:02 +0000
Received: by outflank-mailman (input) for mailman id 695609;
 Tue, 19 Mar 2024 20:59:02 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmgY2-0007jV-6N
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 20:59:02 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on2062d.outbound.protection.outlook.com
 [2a01:111:f400:7e88::62d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 82344811-e633-11ee-a1ee-f123f15fe8a2;
 Tue, 19 Mar 2024 21:58:59 +0100 (CET)
Received: from CH0PR07CA0019.namprd07.prod.outlook.com (2603:10b6:610:32::24)
 by SA1PR12MB7366.namprd12.prod.outlook.com (2603:10b6:806:2b3::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.26; Tue, 19 Mar
 2024 20:58:56 +0000
Received: from CH1PEPF0000A345.namprd04.prod.outlook.com
 (2603:10b6:610:32:cafe::11) by CH0PR07CA0019.outlook.office365.com
 (2603:10b6:610:32::24) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.27 via Frontend
 Transport; Tue, 19 Mar 2024 20:58:55 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CH1PEPF0000A345.mail.protection.outlook.com (10.167.244.8) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Tue, 19 Mar 2024 20:58:54 +0000
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Tue, 19 Mar
 2024 15:58:54 -0500
Received: from fedora.mshome.net (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Tue, 19 Mar 2024 15:58:53 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 82344811-e633-11ee-a1ee-f123f15fe8a2
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=oCD51Sjl7PR/+Lu3KseQRF6qdvMH21K0FJ2c1SCh3OxJgaPuhh1WNhV2cYocClcqWZ2BIgpE8PkaXObAudQJ14Pa0WUQud+R2JQAdtXlJp3qgemJVTVxpsfi0mI0ywwHS/OFq9BMNOd5VImaqOeRvp3jCly3drDTYlmCJtwJcbuFFxFsCPZCdvHMC8mT/K6MKYp9tDMJ3Ue20IAqZBbmrGY0cjSjQpPRvaywQpy3afLUNo98v6Bx9pbaggdYn3kPRStYf6dNAXCh1KbwwhJRjaqrguijIF9SHgbKIN0+eUu3vskWAZoUVaBgHIUhz4ntGiw6EZlBfE4u3TUIDAkNIw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=B5YAuNKX+8+Yiih2W/K6aknxT/lxBQ5etRwHBsz3KVc=;
 b=eFWI8/Bd33p2so4weUn5Vta8lTWuOt3OXR6mNSwaWL+dO7Zecs8HMHuv7m9IZqdh0hU3Q4hJKIBCatQcSE6t3xpwQx8tDjnsGkFHEFxwC14FDV87Rkk3yzkRCoLkIFNkR6NJKdEtCr8xlgAD252eQ3/jdXVuFisPeWFzJGUf/K/1CeIIQYec9w+D02Tq8VoOHYhijFFquA5Z//xmeFP4RC4nPq2lumPdGokIvgaflwyqnVPbyyZ3AlJwMnsMftLhVVnxobUK/dMS24M5ju36B6nFmRRnEEs1IGFEGoLnkXe+ueaINh+/1aBZr8hWEbBUyuqEUN2sVHYO/Jke7sqnGw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=B5YAuNKX+8+Yiih2W/K6aknxT/lxBQ5etRwHBsz3KVc=;
 b=ifWSK4y9wNuWoilePtEXN4EeU/05cvTMe6Sw4cUjbTLbhqEzn7g/KqypDPP6F8GUZomejGq7utVUAaPJjLD9vHcrIFESJN5vsthz2cKBE1rfH81JKXXAokdQHTSQctg76rhQzxpK2ma9K8bPdG6QqZal53mZ8qthUa0nGDY1lw4=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Jason Andryuk 
To: 
CC: Jason Andryuk , Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Wei Liu
	, George Dunlap , Julien Grall
	, Stefano Stabellini 
Subject: [PATCH v3 0/3] x86/pvh: Support relocating dom0 kernel
Date: Tue, 19 Mar 2024 16:58:46 -0400
Message-ID: <20240319205849.115884-1-jason.andryuk@amd.com>
X-Mailer: git-send-email 2.44.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB04.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH1PEPF0000A345:EE_|SA1PR12MB7366:EE_
X-MS-Office365-Filtering-Correlation-Id: 1c9d7c9f-3467-4409-878a-08dc48576391
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	h/0fM7ufLsoPG5LDrpVJuCkdeNtjZ/T0k6/q4QFj71ppO8Gpl/B8uBbHNueXJFGtHgKS+yaLY0y/gX6TmYZcFviBrzeHU4upHxqHovls/Tdbag7TRlwtB4rVcEZGqZiGYwhDhYIlzmO75DPvBs/d9lviZWN1BtslOQroJ94+kHGLKUJJbtTfTuN24yQwgg23jiZi0laZ1wx/BCmh/e/b9eaRZZmgYlRK1bOD0qkHYmHYW6KpAZ9nc/o9z0ygqGqqznM6jHJTtBY8sH6piSuiMC5NVxpO7QwTmQesUuqFxuQR/kGZvoJ2RKbtN77sc4u5SDopehefuWkUk+VVPNPZDaZQpyiQH03kB6pX/ppNekRBg3mdqUyPVpy0KeOD/GT3QgYsU/rBese6HSCCiHzK3OGWkRJwbdMoUuK6Or0G/JUPmeBjo6Z1UZTqmDW4/yy1zh97YFC3oGdc3/Zs9tAUm6eTD3VrJHWlQunvn0bXSsxoIsguKROEo+14cVE0AodEXX6FuvHZERbD9dhI9w1I5J+uhYXGl8rM1JJxuoyG6CR+fCilwyQWElBMKO2PVvBs//5ewJuL+Qwkmi0Ky5NcjrrSo6VebIVgTztMoTGQitOnITtkjBB5cJDnF0dPEvoABvvZYAa4N2J+1wXZ2G6424IbQoBFDuiyMzPknAYfoxaHm0QL9FdkMc7CQv0+y7UKayjKichvkQYdeJS/tfptVUFCik3dahak1GuHJVVws2Pp5aq4PTyRrW3xCogMzjvk
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(36860700004)(1800799015)(376005)(82310400014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Mar 2024 20:58:54.8979
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 1c9d7c9f-3467-4409-878a-08dc48576391
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH1PEPF0000A345.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB7366

Xen tries to load a PVH dom0 kernel at the fixed guest physical address
from the elf headers.  For Linux, this defaults to 0x1000000 (16MB), but
it can be configured.

Unfortunately there exist firmwares that have reserved regions at this
address, so Xen fails to load the dom0 kernel since it's not RAM.

The other issue is that the Linux PVH entry point is not
position-independent.  It expects to run at the compiled
CONFIG_PHYSICAL_ADDRESS.

This patch set expands the PVH dom0 builder to try to relocate the
kernel if needed and possible.  XEN_ELFNOTE_PHYS32_RELOC is added for
kernels to indicate they are relocatable and their acceptable address
range and alignment.

The first patch reverts "xen/x86: bzImage parse kernel_alignment" since
the alignment will be specified by the ELF note.

The second patch expands ELF note printing beyond just printing
integers and strings.

The third patch expands the pvh dom0 kernel placement code.

I'll post an additional patch showing the Linux changes to make PVH
relocatable.

Jason Andryuk (3):
  Revert "xen/x86: bzImage parse kernel_alignment"
  libelf: Expand ELF note printing
  x86/PVH: Support relocatable dom0 kernels

 xen/arch/x86/bzimage.c             |  4 +-
 xen/arch/x86/hvm/dom0_build.c      | 98 +++++++++++++++++++++++++++++-
 xen/arch/x86/include/asm/bzimage.h |  2 +-
 xen/arch/x86/pv/dom0_build.c       |  2 +-
 xen/common/libelf/libelf-dominfo.c | 83 ++++++++++++++++++-------
 xen/include/public/elfnote.h       | 18 +++++-
 xen/include/xen/libelf.h           |  4 ++
 7 files changed, 181 insertions(+), 30 deletions(-)

-- 
2.44.0



From xen-devel-bounces@lists.xenproject.org Tue Mar 19 20:59:09 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 20:59:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695611.1085500 (Exim 4.92)
	(envelope-from )
	id 1rmgY9-0008He-HA; Tue, 19 Mar 2024 20:59:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695611.1085500; Tue, 19 Mar 2024 20:59:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmgY9-0008HU-Dw; Tue, 19 Mar 2024 20:59:09 +0000
Received: by outflank-mailman (input) for mailman id 695611;
 Tue, 19 Mar 2024 20:59:08 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmgY8-0007jV-Hg
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 20:59:08 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on20601.outbound.protection.outlook.com
 [2a01:111:f403:200a::601])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 865926d3-e633-11ee-a1ee-f123f15fe8a2;
 Tue, 19 Mar 2024 21:59:07 +0100 (CET)
Received: from CH2PR07CA0005.namprd07.prod.outlook.com (2603:10b6:610:20::18)
 by IA1PR12MB7736.namprd12.prod.outlook.com (2603:10b6:208:420::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.30; Tue, 19 Mar
 2024 20:59:02 +0000
Received: from CH1PEPF0000A346.namprd04.prod.outlook.com
 (2603:10b6:610:20:cafe::ba) by CH2PR07CA0005.outlook.office365.com
 (2603:10b6:610:20::18) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.19 via Frontend
 Transport; Tue, 19 Mar 2024 20:59:02 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CH1PEPF0000A346.mail.protection.outlook.com (10.167.244.11) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Tue, 19 Mar 2024 20:59:02 +0000
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Tue, 19 Mar
 2024 15:59:01 -0500
Received: from fedora.mshome.net (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Tue, 19 Mar 2024 15:59:00 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 865926d3-e633-11ee-a1ee-f123f15fe8a2
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=IBzRTvisDlefOi9ZyMK7LQIdFVUzW/fGjGCj4THYmsSQJ3jhYb5yVrqWiPDeziDY0w5kX4sQfpmvtchL180JErnKNGZlCA6177rgwVT3ZdKr3/67VBA6yHY7tnW8O2aAkwvVs98W7xE8YQ65LA1ynUTPXrXdmQQNY2MgoTUF8OCssc8oUE8EqaR/38IxkkPH1hs0ur3Wxg1IgDuWUZJqn7K0N7ws7GQuGh7tgnOB+rycM8AfmjtLIaySly8H6f4dnP5QEgJhQKfKAQvgIrdsOh1dvuvzpPYn6rGvyAAQKyUJdaF3ewLFaX84sDE8ZtiPxWDPyuDEhlyMFz/RAq4Wuw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=NDm0ZtVyDBysq2xkYmsebdtkUyX6X2/ReXcGS+SS/nU=;
 b=kwprMUzI8IFE5wjhqZDCqZtcY3a+sB8t9SUHJ+m3gfRtvfrhPoqodprbqXf+wOXmT8RpBRh9wcPGQLC39gtduH8Ln5/OjDKxfR4ALGAHqhvQbkc6uW+okAWOrIJ0nexrwZrAJ9n65ERKAMMpaXckXPlsACiCFVFMnF79S12M7rrMiP5RyEqQ87TbHpYKh/j2fgyj1xmVNiYrvI/o2g6/230+f4/sz08epA0tZZj3zoFMZhzK/3n88o/JHWLMoP4CNGCQzeEF4zkL49lKef9vpS3bJfbCKPGLYpDsB8NwUanbXsZQ16scJRQ6OSQHiQ7PCeCe2d0dsT4IaunQgtM92Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=NDm0ZtVyDBysq2xkYmsebdtkUyX6X2/ReXcGS+SS/nU=;
 b=XJlX0xIalPXa2OCZY/7xPbtPOtTvKRGDSQF3ScK9BxU9T+e7w3toQKCIoaas50Xwhbv0mqVC4MjoPKJZwkIw6lsRSoQL2ZyHCsXxNc2CmZ2iDEhqLpbOKZfyiXOUOn32JuGyndr5XFx5qzDPBQTaR9GzF+9OfU6FDRwknOPOG3w=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Jason Andryuk 
To: 
CC: Jason Andryuk , Andrew Cooper
	, George Dunlap , "Jan
 Beulich" , Julien Grall , "Stefano
 Stabellini" , Wei Liu 
Subject: [PATCH v3 2/3] libelf: Expand ELF note printing
Date: Tue, 19 Mar 2024 16:58:48 -0400
Message-ID: <20240319205849.115884-3-jason.andryuk@amd.com>
X-Mailer: git-send-email 2.44.0
In-Reply-To: <20240319205849.115884-1-jason.andryuk@amd.com>
References: <20240319205849.115884-1-jason.andryuk@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB04.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH1PEPF0000A346:EE_|IA1PR12MB7736:EE_
X-MS-Office365-Filtering-Correlation-Id: 955bdd22-30f8-4648-08f7-08dc4857680f
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	aPMiu3QItUiwzdgKym7VRj33rEQPotKrYMRnIbvy6DQt9e/SGYPVNXoSC586xV0Zen2Q8ZannXTJcLbfrIFsO6vAjE2LusAbUvxQBXVuzlEvhVVIDWybiLw8LahdyoQF/AT57kjy70D4EZh5VU0c9BGRoBCpXruB6IYa054TYlen9UG8J3URqORCyIbre2X5fXHqPyVTyCArcVkRbwVBn8sr82WEk6FJXqnGIIVDoblqzPeJ3RF/Z/ODdPXkXVRyvGGU0O8A88f9IxD883fQ2PCS8jESLQ8RRs0eatK7O9ORJaqE6wuGyeGv/jlM6WtXTFjeWnhyFg+yMgqeOfy6GrkOFCtntWzCYngCwx5qA3cE3i1trfcszFK6C9Dbu9HNxCobdbzRCOsQ3MbMOBllHkBbblhOJttFR5LBYo8oH5o74DAjKHsIgsy9RgFV6mf3LnJVqPLEJt8II47lRzAERRwKrbDMO6q9v/rK7TP9L2OMYXzg2QmInNCbkxAHg1GZJmSw5XGnEi2RkGS4M4dQ1YHzy3M4/scVq39ZCioNlOp2WcHPdTDN2ISv6y7YXF1Tk5aLGk4dXU7/q1Y3eLMByeEsXThUvPe8vQjwjtG+x34E02ZFg0pXWAGZbExUWBtvWvr39rkOMIoTTSjWuh8kTMpeCxuYg3nTSUpJ9KLoiIB3e+oHhGsdYKRkXO0OcPC8ZWaeOf30EDLmai9L1sWQr76ol9jNPi5hb06R/O42HyZ2Hl+BGwYIR3NxSSPF6zN6
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(82310400014)(36860700004)(376005)(1800799015);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Mar 2024 20:59:02.4313
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 955bdd22-30f8-4648-08f7-08dc4857680f
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH1PEPF0000A346.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB7736

The XEN_ELFNOTE_L1_MFN_VALID is an array of pairs of values, but it is
printed as:
(XEN) ELF: note: L1_MFN_VALID = 0

This is a limitation of only printing either string or numeric values.
Switch from the boolean to an enum which allows more flexibility in
printing the values.  Introduce ELFNOTE_NAME to only print the name
without a value like:
(XEN) ELF: note: L1_MFN_VALID

Signed-off-by: Jason Andryuk 
---
v3:
Remove fatal size check
Don't print values - just the name for presence
---
 xen/common/libelf/libelf-dominfo.c | 50 +++++++++++++++++-------------
 1 file changed, 29 insertions(+), 21 deletions(-)

diff --git a/xen/common/libelf/libelf-dominfo.c b/xen/common/libelf/libelf-dominfo.c
index a13a5e4db6..405510ead9 100644
--- a/xen/common/libelf/libelf-dominfo.c
+++ b/xen/common/libelf/libelf-dominfo.c
@@ -101,26 +101,30 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
 /* *INDENT-OFF* */
     static const struct {
         const char *name;
-        bool str;
+        enum {
+            ELFNOTE_INT,
+            ELFNOTE_STRING,
+            ELFNOTE_NAME,
+        } type;
     } note_desc[] = {
-        [XEN_ELFNOTE_ENTRY] = { "ENTRY", 0},
-        [XEN_ELFNOTE_HYPERCALL_PAGE] = { "HYPERCALL_PAGE", 0},
-        [XEN_ELFNOTE_VIRT_BASE] = { "VIRT_BASE", 0},
-        [XEN_ELFNOTE_INIT_P2M] = { "INIT_P2M", 0},
-        [XEN_ELFNOTE_PADDR_OFFSET] = { "PADDR_OFFSET", 0},
-        [XEN_ELFNOTE_HV_START_LOW] = { "HV_START_LOW", 0},
-        [XEN_ELFNOTE_XEN_VERSION] = { "XEN_VERSION", 1},
-        [XEN_ELFNOTE_GUEST_OS] = { "GUEST_OS", 1},
-        [XEN_ELFNOTE_GUEST_VERSION] = { "GUEST_VERSION", 1},
-        [XEN_ELFNOTE_LOADER] = { "LOADER", 1},
-        [XEN_ELFNOTE_PAE_MODE] = { "PAE_MODE", 1},
-        [XEN_ELFNOTE_FEATURES] = { "FEATURES", 1},
-        [XEN_ELFNOTE_SUPPORTED_FEATURES] = { "SUPPORTED_FEATURES", 0},
-        [XEN_ELFNOTE_BSD_SYMTAB] = { "BSD_SYMTAB", 1},
-        [XEN_ELFNOTE_L1_MFN_VALID] = { "L1_MFN_VALID", false },
-        [XEN_ELFNOTE_SUSPEND_CANCEL] = { "SUSPEND_CANCEL", 0 },
-        [XEN_ELFNOTE_MOD_START_PFN] = { "MOD_START_PFN", 0 },
-        [XEN_ELFNOTE_PHYS32_ENTRY] = { "PHYS32_ENTRY", 0 },
+        [XEN_ELFNOTE_ENTRY] = { "ENTRY", ELFNOTE_INT },
+        [XEN_ELFNOTE_HYPERCALL_PAGE] = { "HYPERCALL_PAGE", ELFNOTE_INT },
+        [XEN_ELFNOTE_VIRT_BASE] = { "VIRT_BASE", ELFNOTE_INT },
+        [XEN_ELFNOTE_INIT_P2M] = { "INIT_P2M", ELFNOTE_INT },
+        [XEN_ELFNOTE_PADDR_OFFSET] = { "PADDR_OFFSET", ELFNOTE_INT },
+        [XEN_ELFNOTE_HV_START_LOW] = { "HV_START_LOW", ELFNOTE_INT },
+        [XEN_ELFNOTE_XEN_VERSION] = { "XEN_VERSION", ELFNOTE_STRING },
+        [XEN_ELFNOTE_GUEST_OS] = { "GUEST_OS", ELFNOTE_STRING },
+        [XEN_ELFNOTE_GUEST_VERSION] = { "GUEST_VERSION", ELFNOTE_STRING },
+        [XEN_ELFNOTE_LOADER] = { "LOADER", ELFNOTE_STRING },
+        [XEN_ELFNOTE_PAE_MODE] = { "PAE_MODE", ELFNOTE_STRING },
+        [XEN_ELFNOTE_FEATURES] = { "FEATURES", ELFNOTE_STRING },
+        [XEN_ELFNOTE_SUPPORTED_FEATURES] = { "SUPPORTED_FEATURES", ELFNOTE_INT },
+        [XEN_ELFNOTE_BSD_SYMTAB] = { "BSD_SYMTAB", ELFNOTE_STRING },
+        [XEN_ELFNOTE_L1_MFN_VALID] = { "L1_MFN_VALID", ELFNOTE_NAME },
+        [XEN_ELFNOTE_SUSPEND_CANCEL] = { "SUSPEND_CANCEL", ELFNOTE_INT },
+        [XEN_ELFNOTE_MOD_START_PFN] = { "MOD_START_PFN", ELFNOTE_INT },
+        [XEN_ELFNOTE_PHYS32_ENTRY] = { "PHYS32_ENTRY", ELFNOTE_INT },
     };
 /* *INDENT-ON* */
 
@@ -136,7 +140,7 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
         return 0;
     }
 
-    if ( note_desc[type].str )
+    if ( note_desc[type].type == ELFNOTE_STRING )
     {
         str = elf_strval(elf, elf_note_desc(elf, note));
         if (str == NULL)
@@ -146,13 +150,17 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
         parms->elf_notes[type].type = XEN_ENT_STR;
         parms->elf_notes[type].data.str = str;
     }
-    else
+    else if ( note_desc[type].type == ELFNOTE_INT )
     {
         val = elf_note_numeric(elf, note);
         elf_msg(elf, "ELF: note: %s = %#" PRIx64 "\n", note_desc[type].name, val);
         parms->elf_notes[type].type = XEN_ENT_LONG;
         parms->elf_notes[type].data.num = val;
     }
+    else if ( note_desc[type].type == ELFNOTE_NAME )
+    {
+        elf_msg(elf, "ELF: note: %s\n", note_desc[type].name);
+    }
     parms->elf_notes[type].name = note_desc[type].name;
 
     switch ( type )
-- 
2.44.0



From xen-devel-bounces@lists.xenproject.org Tue Mar 19 20:59:11 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 20:59:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695612.1085510 (Exim 4.92)
	(envelope-from )
	id 1rmgYB-00009W-QP; Tue, 19 Mar 2024 20:59:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695612.1085510; Tue, 19 Mar 2024 20:59:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmgYB-00009O-Mr; Tue, 19 Mar 2024 20:59:11 +0000
Received: by outflank-mailman (input) for mailman id 695612;
 Tue, 19 Mar 2024 20:59:10 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmgY9-0007xt-Vm
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 20:59:10 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on20601.outbound.protection.outlook.com
 [2a01:111:f403:2412::601])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 86f97b9e-e633-11ee-afdd-a90da7624cb6;
 Tue, 19 Mar 2024 21:59:08 +0100 (CET)
Received: from CH5P221CA0012.NAMP221.PROD.OUTLOOK.COM (2603:10b6:610:1f2::16)
 by MW4PR12MB6852.namprd12.prod.outlook.com (2603:10b6:303:207::21)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.30; Tue, 19 Mar
 2024 20:59:05 +0000
Received: from CH1PEPF0000A348.namprd04.prod.outlook.com
 (2603:10b6:610:1f2:cafe::24) by CH5P221CA0012.outlook.office365.com
 (2603:10b6:610:1f2::16) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.28 via Frontend
 Transport; Tue, 19 Mar 2024 20:59:05 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CH1PEPF0000A348.mail.protection.outlook.com (10.167.244.4) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Tue, 19 Mar 2024 20:59:04 +0000
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Tue, 19 Mar
 2024 15:59:04 -0500
Received: from fedora.mshome.net (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Tue, 19 Mar 2024 15:59:03 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 86f97b9e-e633-11ee-afdd-a90da7624cb6
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=O77yB8uUAxJRIwxnzSCmsI7E+mctTib3+e9nx7TzSkspmgBLZnbSKNbUlA8ltngCjpJKfgEZYAznjlpHpPt24cl8DehSLpUP1caV3Y2uD/0ptJ9To9RjgOmsLDC6UqzNSp85nXgzlgnS5/LI1MEYsMDbsgg0OYayFdnUXEk12oJtrenVudhsSyVbYS2Fg0o4DbE8HheVlTIhUfxXWt/R+wpJwLQEwUeV82GxozcIoFuh6wJCMkBHr0EWBm3LVoTplpY806p3zwyKo273xsGj+xBGT3ga3hUaV/ayqjB0jDGo0Zaz367zF1jx+ILCQlLP7p4+GiBMqWcSsywrsXhr3g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ubecenY8h+cFWrLnty23ZPYxaQGRZIUEbcYcQZ6BJcU=;
 b=fwNLCu87IX6lsjsgTMK2vLsOkB1vWogb3uez3IxhvgM5V4NWz9jaPB2plRGxGCjPLsmcN4F65vsGwsHQGJU2bEC7zzeKnBDcpjcGsuMiJEZpun1WW26zkUMfF8E0d8PwF+vdakmPw+QWpMZcn7fKYlrW3iGTTBdJh/fjC3Sum4VW3rPRYto/wiSZ/sGR76WyrOQ0HaMYnzi0QuTDJ3ndT44ytldNnQ8+6I7RO5M8q2BY/th4dJxnnEdlTSleZa95/HJkIkfC/R6y8WytbJ7CVTiyuNU8Vv7N+rojm+JswQ0HJJONPFY6D0w0NdUGMFCcEqEDtPH2HdC2JpZanbcHjg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=ubecenY8h+cFWrLnty23ZPYxaQGRZIUEbcYcQZ6BJcU=;
 b=B111KHkg3vYZ9uvZP25R9kbpuc48iXiUdcuHGyJnbUVXGkiTPsvq0DuXKvOQf2OoKudolPNDTO0fN50DEDeRVxpmF1OCDUuDUA2J7F0hFdQm4hB2WKuAaMq4Rvt1gwcGFbrmnHRvLYu8LTObBx5+XTZmO436UO0lByIkY68LnFo=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Jason Andryuk 
To: 
CC: Jason Andryuk , Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Wei Liu
	, George Dunlap , Julien Grall
	, Stefano Stabellini 
Subject: [PATCH v3 3/3] x86/PVH: Support relocatable dom0 kernels
Date: Tue, 19 Mar 2024 16:58:49 -0400
Message-ID: <20240319205849.115884-4-jason.andryuk@amd.com>
X-Mailer: git-send-email 2.44.0
In-Reply-To: <20240319205849.115884-1-jason.andryuk@amd.com>
References: <20240319205849.115884-1-jason.andryuk@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB04.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH1PEPF0000A348:EE_|MW4PR12MB6852:EE_
X-MS-Office365-Filtering-Correlation-Id: dcf1f5f3-ff17-4de6-2640-08dc4857698d
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	bTB/la/v1Wb5p5uWuOAgg5iiJqtoM8bur8zfX/nyB/dtzXqULT4Qp80Crw1IMzm0SOOy31jTOB5IeOaIVdbq4CAky/adZ4HmcjEhigYCsa7Xcy2pAbYYO+KjF+uEN+oy9RWWXp9Nyq09ihAVYRu0mcGsXeIQS0jRKGJZFYO7LFZSCr7mMxYcz4QIVKjMWN6Bu6U/k9pzrmzOor4ihHFNHgDvVFHlOCpWwPGNMQ3gVTHEkBXKxClwDZDT1AH2Pb6/ntRoGSvC5V7Jc3rhw0U/Jhf1ROOzcnjQFFWUmc0l+vGi9fc9vlcue7lBl5eIlRdZQC4Ini8BFunkFu+BthfcEKmwQpF5CxmzMrbjNSqlp4I30Dh0maLHpTeyResWqJnyf0+cR+vKIyc+LrU08m4h6MCXU+en51080KspyMp9KKaDaWP0G84ng7N1tl79I/lSlND9BfmIS5u0+nyuuWo8kFJoTHS49KFIM4WElVSz6v7kKrQ3Y20bOSxcPh4+Vq36efKIU2BQbDMEuBkTLW/aVISk6+sQoD93sfFt4KSq9yAr0p/CpIl+lIeBjEJpVZAmYDizHDJB87EgdGCf0jrjSfuHq4u1+7gNTnQIH9v6di+HMvyee3sphaeroqRF+vAz2rBSpS4bA2OGVYpuTcXlQ49MAHvm4vwmxGJdkt0In0Tia3RxHlvINojwkl3nA8GuNsZo5uzPV8dKyNwtoEzSOg==
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(36860700004)(376005)(1800799015)(82310400014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Mar 2024 20:59:04.9355
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: dcf1f5f3-ff17-4de6-2640-08dc4857698d
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH1PEPF0000A348.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR12MB6852

Xen tries to load a PVH dom0 kernel at the fixed guest physical address
from the elf headers.  For Linux, this defaults to 0x1000000 (16MB), but
it can be configured.

Unfortunately there exist firmwares that have reserved regions at this
address, so Xen fails to load the dom0 kernel since it's not RAM.

The PVH entry code is not relocatable - it loads from absolute
addresses, which fail when the kernel is loaded at a different address.
With a suitably modified kernel, a reloctable entry point is possible.

Add XEN_ELFNOTE_PHYS32_RELOC which specifies optional minimum, maximum and
alignment needed for the kernel.  The presence of the NOTE indicates the
kernel supports a relocatable entry path.

Change the loading to check for an acceptable load address.  If the
kernel is relocatable, support finding an alternate load address.

Link: https://gitlab.com/xen-project/xen/-/issues/180
Signed-off-by: Jason Andryuk 
---
ELF Note printing looks like:
(XEN) ELF: note: PHYS32_RELOC = max: 0xffffffff min: 0x1000000 align: 0x200000

v2:
Use elfnote for min, max & align - use 64bit values.
Print original and relocated memory addresses
Use check_and_adjust_load_address() name
Return relocated base instead of offset
Use PAGE_ALIGN
Don't load above max_phys (expected to be 4GB in kernel elf note)
Use single line comments
Exit check_load_address loop earlier
Add __init to find_kernel_memory()

v3:
Remove kernel_start/end page rounding
Change loop comment to rely on a sorted memory map.
Reorder E820_RAM check first
Use %p for dest_base
Use PRIpaddr
Use 32bit phys_min/max/align
Consolidate to if ( x || y ) continue
Use max_t
Add parms->phys_reloc
Use common "%pd kernel: " prefix for messages
Re-order phys_entry assignment
Print range ends inclusively
Remove extra "Unable to load kernel" message
s/PVH_RELOCATION/PHYS32_RELOC/
Make PHYS32_RELOC contents optional
Use 2MB default alignment
Update ELF Note comment
Update XEN_ELFNOTE_MAX
---
 xen/arch/x86/hvm/dom0_build.c      | 94 ++++++++++++++++++++++++++++++
 xen/common/libelf/libelf-dominfo.c | 33 +++++++++++
 xen/include/public/elfnote.h       | 18 +++++-
 xen/include/xen/libelf.h           |  4 ++
 4 files changed, 148 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index 0ceda4140b..d2686318c3 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -537,6 +537,97 @@ static paddr_t __init find_memory(
     return INVALID_PADDR;
 }
 
+static bool __init check_load_address(
+    const struct domain *d, const struct elf_binary *elf)
+{
+    paddr_t kernel_start = (paddr_t)elf->dest_base;
+    paddr_t kernel_end = kernel_start + elf->dest_size;
+    unsigned int i;
+
+    /* Relies on a sorted memory map. */
+    for ( i = 0; i < d->arch.nr_e820; i++ )
+    {
+        paddr_t start = d->arch.e820[i].addr;
+        paddr_t end = d->arch.e820[i].addr + d->arch.e820[i].size;
+
+        if ( start >= kernel_end )
+            return false;
+
+        if ( d->arch.e820[i].type == E820_RAM  &&
+             start <= kernel_start &&
+             end >= kernel_end )
+            return true;
+    }
+
+    return false;
+}
+
+/* Find an e820 RAM region that fits the kernel at a suitable alignment. */
+static paddr_t __init find_kernel_memory(
+    const struct domain *d, struct elf_binary *elf,
+    const struct elf_dom_parms *parms)
+{
+    paddr_t kernel_size = elf->dest_size;
+    unsigned int i;
+
+    for ( i = 0; i < d->arch.nr_e820; i++ )
+    {
+        paddr_t start = d->arch.e820[i].addr;
+        paddr_t end = d->arch.e820[i].addr + d->arch.e820[i].size;
+        paddr_t kstart, kend;
+
+        if ( d->arch.e820[i].type != E820_RAM ||
+             d->arch.e820[i].size < kernel_size )
+            continue;
+
+        kstart = ROUNDUP(start, parms->phys_align);
+        kstart = max_t(paddr_t, kstart, parms->phys_min);
+        kend = kstart + kernel_size;
+
+        if ( kend > parms->phys_max )
+            return 0;
+
+        if ( kend <= end )
+            return kstart;
+    }
+
+    return 0;
+}
+
+/* Check the kernel load address, and adjust if necessary and possible. */
+static bool __init check_and_adjust_load_address(
+    const struct domain *d, struct elf_binary *elf, struct elf_dom_parms *parms)
+{
+    paddr_t reloc_base;
+
+    if ( check_load_address(d, elf) )
+        return true;
+
+    if ( !parms->phys_reloc )
+    {
+        printk("%pd kernel: Address conflict and not relocatable\n", d);
+        return false;
+    }
+
+    reloc_base = find_kernel_memory(d, elf, parms);
+    if ( reloc_base == 0 )
+    {
+        printk("%pd kernel: Failed find a load address\n", d);
+        return false;
+    }
+
+    if ( opt_dom0_verbose )
+        printk("%pd kernel: Moving [%p, %p] -> [%"PRIpaddr", %"PRIpaddr"]\n", d,
+               elf->dest_base, elf->dest_base + elf->dest_size - 1,
+               reloc_base, reloc_base + elf->dest_size - 1);
+
+    parms->phys_entry = reloc_base +
+                            (parms->phys_entry - (paddr_t)elf->dest_base);
+    elf->dest_base = (char *)reloc_base;
+
+    return true;
+}
+
 static int __init pvh_load_kernel(struct domain *d, const module_t *image,
                                   unsigned long image_headroom,
                                   module_t *initrd, void *image_base,
@@ -585,6 +676,9 @@ static int __init pvh_load_kernel(struct domain *d, const module_t *image,
     elf.dest_base = (void *)(parms.virt_kstart - parms.virt_base);
     elf.dest_size = parms.virt_kend - parms.virt_kstart;
 
+    if ( !check_and_adjust_load_address(d, &elf, &parms) )
+        return -ENOMEM;
+
     elf_set_vcpu(&elf, v);
     rc = elf_load_binary(&elf);
     if ( rc < 0 )
diff --git a/xen/common/libelf/libelf-dominfo.c b/xen/common/libelf/libelf-dominfo.c
index 405510ead9..7861e79658 100644
--- a/xen/common/libelf/libelf-dominfo.c
+++ b/xen/common/libelf/libelf-dominfo.c
@@ -105,6 +105,7 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
             ELFNOTE_INT,
             ELFNOTE_STRING,
             ELFNOTE_NAME,
+            ELFNOTE_CUSTOM,
         } type;
     } note_desc[] = {
         [XEN_ELFNOTE_ENTRY] = { "ENTRY", ELFNOTE_INT },
@@ -125,6 +126,7 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
         [XEN_ELFNOTE_SUSPEND_CANCEL] = { "SUSPEND_CANCEL", ELFNOTE_INT },
         [XEN_ELFNOTE_MOD_START_PFN] = { "MOD_START_PFN", ELFNOTE_INT },
         [XEN_ELFNOTE_PHYS32_ENTRY] = { "PHYS32_ENTRY", ELFNOTE_INT },
+        [XEN_ELFNOTE_PHYS32_RELOC] = { "PHYS32_RELOC", ELFNOTE_CUSTOM },
     };
 /* *INDENT-ON* */
 
@@ -132,6 +134,7 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
     uint64_t val = 0;
     unsigned int i;
     unsigned type = elf_uval(elf, note, type);
+    unsigned descsz = elf_uval(elf, note, descsz);
 
     if ( (type >= sizeof(note_desc) / sizeof(note_desc[0])) ||
          (note_desc[type].name == NULL) )
@@ -161,6 +164,10 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
     {
         elf_msg(elf, "ELF: note: %s\n", note_desc[type].name);
     }
+    else if ( note_desc[type].type == ELFNOTE_CUSTOM )
+    {
+        elf_msg(elf, "ELF: note: %s", note_desc[type].name);
+    }
     parms->elf_notes[type].name = note_desc[type].name;
 
     switch ( type )
@@ -225,6 +232,28 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
     case XEN_ELFNOTE_PHYS32_ENTRY:
         parms->phys_entry = val;
         break;
+
+    case XEN_ELFNOTE_PHYS32_RELOC:
+        parms->phys_reloc = true;
+
+        if ( descsz >= 4 )
+        {
+            parms->phys_max = elf_note_numeric_array(elf, note, 4, 0);
+            elf_msg(elf, " = max: %#"PRIx32, parms->phys_max);
+        }
+        if ( descsz >= 8 )
+        {
+            parms->phys_min = elf_note_numeric_array(elf, note, 4, 1);
+            elf_msg(elf, " min: %#"PRIx32, parms->phys_min);
+        }
+        if ( descsz >= 12 )
+        {
+            parms->phys_align = elf_note_numeric_array(elf, note, 4, 2);
+            elf_msg(elf, " align: %#"PRIx32, parms->phys_align);
+        }
+
+        elf_msg(elf, "\n");
+        break;
     }
     return 0;
 }
@@ -536,6 +565,10 @@ elf_errorstatus elf_xen_parse(struct elf_binary *elf,
     parms->p2m_base = UNSET_ADDR;
     parms->elf_paddr_offset = UNSET_ADDR;
     parms->phys_entry = UNSET_ADDR32;
+    parms->phys_min = 0;
+    parms->phys_max = 0xffffffff;
+    parms->phys_align = 0x200000;
+    parms->phys_reloc = false;
 
     /* Find and parse elf notes. */
     count = elf_phdr_count(elf);
diff --git a/xen/include/public/elfnote.h b/xen/include/public/elfnote.h
index 8bf54d035b..54362b907f 100644
--- a/xen/include/public/elfnote.h
+++ b/xen/include/public/elfnote.h
@@ -194,10 +194,26 @@
  */
 #define XEN_ELFNOTE_PHYS32_ENTRY 18
 
+/*
+ * Physical loading constraints for PVH kernels
+ *
+ * Used to place constraints on the guest physical loading addresses and
+ * alignment for a PVH kernel.
+ *
+ * The presence of this note indicates the kernel supports relocating itself.
+ *
+ * The note may include up to three 32bit values in the following order:
+ *  - a maximum address for the entire image to be loaded below (default
+ *      0xffffffff)
+ *  - a minimum address for the start of the image (default 0)
+ *  - a required start alignment (default 0x200000)
+ */
+#define XEN_ELFNOTE_PHYS32_RELOC 19
+
 /*
  * The number of the highest elfnote defined.
  */
-#define XEN_ELFNOTE_MAX XEN_ELFNOTE_PHYS32_ENTRY
+#define XEN_ELFNOTE_MAX XEN_ELFNOTE_PHYS32_RELOC
 
 /*
  * System information exported through crash notes.
diff --git a/xen/include/xen/libelf.h b/xen/include/xen/libelf.h
index 1c77e3df31..777c5008ca 100644
--- a/xen/include/xen/libelf.h
+++ b/xen/include/xen/libelf.h
@@ -434,10 +434,14 @@ struct elf_dom_parms {
     uint32_t f_supported[XENFEAT_NR_SUBMAPS];
     uint32_t f_required[XENFEAT_NR_SUBMAPS];
     uint32_t phys_entry;
+    uint32_t phys_min;
+    uint32_t phys_max;
+    uint32_t phys_align;
 
     /* calculated */
     uint64_t virt_kstart;
     uint64_t virt_kend;
+    bool phys_reloc;
 };
 
 static inline void elf_xen_feature_set(int nr, uint32_t * addr)
-- 
2.44.0



From xen-devel-bounces@lists.xenproject.org Tue Mar 19 21:17:03 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 21:17:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695624.1085520 (Exim 4.92)
	(envelope-from )
	id 1rmgpM-0004IU-79; Tue, 19 Mar 2024 21:16:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695624.1085520; Tue, 19 Mar 2024 21:16:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmgpM-0004IN-40; Tue, 19 Mar 2024 21:16:56 +0000
Received: by outflank-mailman (input) for mailman id 695624;
 Tue, 19 Mar 2024 21:16:54 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmgpJ-0004IH-Vu
 for xen-devel@lists.xenproject.org; Tue, 19 Mar 2024 21:16:54 +0000
Received: from NAM04-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam04on20601.outbound.protection.outlook.com
 [2a01:111:f403:240a::601])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 00a0d2b0-e636-11ee-afdd-a90da7624cb6;
 Tue, 19 Mar 2024 22:16:52 +0100 (CET)
Received: from BN9PR03CA0065.namprd03.prod.outlook.com (2603:10b6:408:fc::10)
 by SJ2PR12MB7964.namprd12.prod.outlook.com (2603:10b6:a03:4cf::7)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.27; Tue, 19 Mar
 2024 21:16:48 +0000
Received: from BN2PEPF000044A3.namprd02.prod.outlook.com
 (2603:10b6:408:fc:cafe::ce) by BN9PR03CA0065.outlook.office365.com
 (2603:10b6:408:fc::10) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.36 via Frontend
 Transport; Tue, 19 Mar 2024 21:16:48 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 BN2PEPF000044A3.mail.protection.outlook.com (10.167.243.154) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Tue, 19 Mar 2024 21:16:47 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Tue, 19 Mar
 2024 16:16:47 -0500
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB05.amd.com
 (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Tue, 19 Mar
 2024 16:16:47 -0500
Received: from fedora.mshome.net (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Tue, 19 Mar 2024 16:16:45 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 00a0d2b0-e636-11ee-afdd-a90da7624cb6
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=Kv0WpY+MfXV67jd440bY0IuYMQtGjFGdIQGC9nNxHSq9yFrXLhfvifhgSLancdbnAnOHbcK1NynlUmgWX5BiwOVHuVfdp7XfQ4UtRkJSbRGXhidMnKO/T6RmuPAOoLCBWEOuSfruT7eOSxAOsfYjk3sFNQdMf+ITrytgEAqAxlwa8W1ud+YnGbuoqcCiWE3puZm0jl3/gEk7XADG5bpHPN/tSmWFoDHq+30i6XEV7lq64gIATvyy4OMz4/7/jB/3OWSC4x5qUziAmuwwaMhUvI1gezOGHhhd7HpPVwAoAZX8Gxz3ftWXpR0PooQngdqa78wEpTpN3cy95wQ1gPglXw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=6PuMDGtUD/XLKJYe09YVh1jNPocEXZXSyjJVy0LVCdg=;
 b=IMz3LM/23Ht1w6XQWAFOjtpm1Ip/C24ZRDo7b/6fWc0kdURGOE5yMapQ7XP2Y9dtogEKTjrI1G0NXyP0183rpWPrFeLWx1EyFblF4es3L5jvjY/GHEAEdgVWzH+mrnBs9NEU/LNB99/Hj/5pD4rSZHeV9QqLBs8PuIVv6I1kMakQ50oTrruF4pHvru4GOdLCxEZGmVGfPc7wiH0NTlFeKWbP8nSyDBzgqYVpa9/3wb32dtq9u16FIjdpYGER+WxQDkzFaGeKdajZv2tjB6uHQnVd2XXEnJ6g4OLoc7j9HSjhFwZHCik+Yi2q8U87xszvs5g+7Vu2qO2sxbEDtxLEnQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=6PuMDGtUD/XLKJYe09YVh1jNPocEXZXSyjJVy0LVCdg=;
 b=Uez5F48TrGiwkfJeD3x4EFCdYnB1zx+VFrNbg0VeLihkmAnFg4zqGA2YFahnEx7YFjrmuNIw90J+GaHkVXryqytdDOYSAoS54o0cDotXvGK972y5IytV7COvVJvH74N/NTEKSgALWCrTVj3I/ajzwwUpCcWMsYU3tdOaXMGMkGY=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
From: Jason Andryuk 
To: 
CC: Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, Andrew Cooper , "Juergen
 Gross" , Boris Ostrovsky , Jason
 Andryuk 
Subject: [PATCH v3] RFC: x86/pvh: Make Xen PVH entrypoint PIC for x86-64
Date: Tue, 19 Mar 2024 17:16:32 -0400
Message-ID: <20240319211632.122596-1-jason.andryuk@amd.com>
X-Mailer: git-send-email 2.44.0
In-Reply-To: <20240319205849.115884-1-jason.andryuk@amd.com>
References: <20240319205849.115884-1-jason.andryuk@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB05.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN2PEPF000044A3:EE_|SJ2PR12MB7964:EE_
X-MS-Office365-Filtering-Correlation-Id: 4565a3d6-8338-4a3e-2546-08dc4859e314
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	+j009ctJ5iJ070zPrFLUcHxm+FVIVauWSFwwOFFwcDRrXFzS39CF5hsMzylQCfGmiP7GmGtHESzkAtleyRiLZJhuIRjn9SGG10uHX4AlXho0lUIhn8OnOByX5BzVP7CHLEsjHbCya133nQy9J4L+eNdqVNzbJzTlWrnXP1tKWnS01qmcspm+xCnS10J1gNn48D7/tAZfnZtbogP0Hvr/PbycynQ1YY4V7xo8xQWdVwx2so5Lp0Qkj3h3fNfplrypRHMeX9npOQ4T9tgULomt0eR9+VHnnl5k5kCvsS0IW1cUqB/DVY0fZPBecEojOBzjkfVFGydHKB5tiMisHB0qIzCtlrw7TyEDOLtoerr2hJqFpaedwyUoJ6ep+9VTVFBtwX5tZDEwxWGutR0CKi2/cVHG0Y5/N5uplOkSrMm1S/8M2+zoZVVFq8PtM2T/pOUXyhKrPwemBIEMfh6sVHEYEfbP2RKBMti4Yri6GP683mUdA4xD75dNmDPRnGYuJOrfbVFD8UzUFrh2s1/xh88IbotMjUKaI2AQH21tUqXKURFfG9WwR+cSJp4+GDlxiE4lb81RqJfmR3ps9VIKQSdBEAK9DIxnEEHsQAsBEckrKwmI5BKZ4eNGZ96fHBlaWOgnTXXttvFDvFqMVxtvEt3l0LPAd4GOuqzYWziMrhNgzAxX8XB/fhwpS+c9YA9qNStI+NRIOw8kkK0fyIDHn8jOfqqE8CPcxrJxhsEAMbjXMlThr+UixVSH5GL9UmP92+8u
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(1800799015)(376005)(36860700004)(82310400014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Mar 2024 21:16:47.8492
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 4565a3d6-8338-4a3e-2546-08dc4859e314
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN2PEPF000044A3.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB7964

The Xen PVH entrypoint is 32bit non-PIC code running at a default load
address of 0x1000000 (16MB) (CONFIG_PHYSICAL_START).  Xen loads the
kernel at that physical address inside the PVH container.

When running a PVH Dom0, the system reserved addresses are mapped 1-1
into the PVH container.  There exist system firmwares (Coreboot/EDK2)
with reserved memory at 16MB.  This creates a conflict where the PVH
kernel cannot be loaded at that address.

Modify the PVH entrypoint to be position-indepedent to allow flexibility
in load address.  Only the 64bit entry path is converted.  A 32bit
kernel is not PIC, so calling into other parts of the kernel, like
xen_prepare_pvh() and mk_pgtable_32(), don't work properly when
relocated.

Initial PVH entry runs at the physical addresses and then transitions to
the identity mapped address.  While executing xen_prepare_pvh() calls
through pv_ops function pointers transition to the high mapped
addresses.  Additionally, __va() is called on some hvm_start_info
physical addresses, we need the directmap address range is used.  So we
need to run page tables with all of those ranges mapped.

Modifying init_top_pgt tables ran into issue since
startup_64/__startup_64() will modify those page tables again.  Use a
dedicated set of page tables - pvh_init_top_pgt  - for the PVH entry to
avoid unwanted interactions.

In xen_pvh_init(), __pa() is called to find the physical address of the
hypercall page.  Set phys_base temporarily before calling into
xen_prepare_pvh(), which calls xen_pvh_init(), and clear it afterwards.
__startup_64() assumes phys_base is zero and adds load_delta to it.  If
phys_base is already set, the calculation results in an incorrect cr3.

TODO: Sync elfnote.h from xen.git commit xxxxxxxxxx when it is
commited.

Signed-off-by: Jason Andryuk 
---
Put this out as an example for the Xen modifications

Instead of setting and clearing phys_base, add a dedicated variable?
Clearing phys_base is a little weird, but it leaves the kernel more
consistent when running non-entry code.

Make __startup_64() exit if phys_base is already set to allow calling
multiple times, and use that and init_top_pgt instead of adding
additional page tables?  That won't work.  __startup_64 is 64bit code,
and pvh needs to create page tables in 32bit code before it can
transition to 64bit long mode.  Hence it can't be re-used to relocate
page tables.
---
 arch/x86/platform/pvh/head.S    | 184 +++++++++++++++++++++++++++++---
 include/xen/interface/elfnote.h |  18 +++-
 2 files changed, 189 insertions(+), 13 deletions(-)

diff --git a/arch/x86/platform/pvh/head.S b/arch/x86/platform/pvh/head.S
index f7235ef87bc3..ee7f69e2cb9d 100644
--- a/arch/x86/platform/pvh/head.S
+++ b/arch/x86/platform/pvh/head.S
@@ -50,11 +50,32 @@
 #define PVH_CS_SEL		(PVH_GDT_ENTRY_CS * 8)
 #define PVH_DS_SEL		(PVH_GDT_ENTRY_DS * 8)
 
+#define rva(x) ((x) - pvh_start_xen)
+
 SYM_CODE_START_LOCAL(pvh_start_xen)
 	UNWIND_HINT_END_OF_STACK
 	cld
 
-	lgdt (_pa(gdt))
+	/*
+	 * See the comment for startup_32 for more details.  We need to
+	 * execute a call to get the execution address to be position
+	 * independent, but we don't have a stack.  Save and restore the
+	 * magic field of start_info in ebx, and use that as the stack.
+	 */
+	mov	(%ebx), %eax
+	leal	4(%ebx), %esp
+	ANNOTATE_INTRA_FUNCTION_CALL
+	call	1f
+1:	popl	%ebp
+	mov	%eax, (%ebx)
+	subl	$ rva(1b), %ebp
+	movl	$0, %esp
+
+	leal	rva(gdt)(%ebp), %eax
+	movl	%eax, %ecx
+	leal	rva(gdt_start)(%ebp), %ecx
+	movl	%ecx, 2(%eax)
+	lgdt	(%eax)
 
 	mov $PVH_DS_SEL,%eax
 	mov %eax,%ds
@@ -62,14 +83,14 @@ SYM_CODE_START_LOCAL(pvh_start_xen)
 	mov %eax,%ss
 
 	/* Stash hvm_start_info. */
-	mov $_pa(pvh_start_info), %edi
+	leal rva(pvh_start_info)(%ebp), %edi
 	mov %ebx, %esi
-	mov _pa(pvh_start_info_sz), %ecx
+	movl rva(pvh_start_info_sz)(%ebp), %ecx
 	shr $2,%ecx
 	rep
 	movsl
 
-	mov $_pa(early_stack_end), %esp
+	leal rva(early_stack_end)(%ebp), %esp
 
 	/* Enable PAE mode. */
 	mov %cr4, %eax
@@ -83,29 +104,83 @@ SYM_CODE_START_LOCAL(pvh_start_xen)
 	btsl $_EFER_LME, %eax
 	wrmsr
 
+	mov %ebp, %ebx
+	subl $LOAD_PHYSICAL_ADDR, %ebx /* offset */
+	jz .Lpagetable_done
+
+	/* Fixup page-tables for relocation. */
+	leal rva(pvh_init_top_pgt)(%ebp), %edi
+	movl $512, %ecx
+2:
+	movl 0x00(%edi), %eax
+	addl 0x04(%edi), %eax
+	jz 1f
+	addl %ebx, 0x00(%edi)
+1:
+	addl $8, %edi
+	decl %ecx
+	jnz 2b
+
+	/* L3 ident has a single entry. */
+	leal rva(pvh_level3_ident_pgt)(%ebp), %edi
+	addl %ebx, 0x00(%edi)
+
+	leal rva(pvh_level3_kernel_pgt)(%ebp), %edi
+	addl %ebx, (4096 - 16)(%edi)
+	addl %ebx, (4096 - 8)(%edi)
+
+	/* pvh_level2_ident_pgt is fine - large pages */
+
+	/* pvh_level2_kernel_pgt needs adjustment - large pages */
+	leal rva(pvh_level2_kernel_pgt)(%ebp), %edi
+	movl $512, %ecx
+2:
+	movl 0x00(%edi), %eax
+	addl 0x04(%edi), %eax
+	jz 1f
+	addl %ebx, 0x00(%edi)
+1:
+	addl $8, %edi
+	decl %ecx
+	jnz 2b
+
+.Lpagetable_done:
 	/* Enable pre-constructed page tables. */
-	mov $_pa(init_top_pgt), %eax
+	leal rva(pvh_init_top_pgt)(%ebp), %eax
 	mov %eax, %cr3
 	mov $(X86_CR0_PG | X86_CR0_PE), %eax
 	mov %eax, %cr0
 
 	/* Jump to 64-bit mode. */
-	ljmp $PVH_CS_SEL, $_pa(1f)
+	pushl $PVH_CS_SEL
+	leal  rva(1f)(%ebp), %eax
+	pushl %eax
+	lretl
 
 	/* 64-bit entry point. */
 	.code64
 1:
 	/* Set base address in stack canary descriptor. */
 	mov $MSR_GS_BASE,%ecx
-	mov $_pa(canary), %eax
+	leal rva(canary)(%ebp), %eax
 	xor %edx, %edx
 	wrmsr
 
+	/* Calculate load offset from LOAD_PHYSICAL_ADDR and store in
+	 * phys_base.  __pa() needs phys_base set to calculate the the
+	 * hypercall page in xen_pvh_init(). */
+	movq %rbp, %rbx
+	subq $LOAD_PHYSICAL_ADDR, %rbx
+	movq %rbx, phys_base(%rip)
 	call xen_prepare_pvh
+	/* Clear phys_base.  startup_64/__startup_64 will *add* to its value,
+	   so start from 0. */
+	xor  %rbx, %rbx
+	movq %rbx, phys_base(%rip)
 
 	/* startup_64 expects boot_params in %rsi. */
-	mov $_pa(pvh_bootparams), %rsi
-	mov $_pa(startup_64), %rax
+	lea rva(pvh_bootparams)(%ebp), %rsi
+	lea rva(startup_64)(%ebp), %rax
 	ANNOTATE_RETPOLINE_SAFE
 	jmp *%rax
 
@@ -137,13 +212,14 @@ SYM_CODE_START_LOCAL(pvh_start_xen)
 
 	ljmp $PVH_CS_SEL, $_pa(startup_32)
 #endif
+
 SYM_CODE_END(pvh_start_xen)
 
 	.section ".init.data","aw"
 	.balign 8
 SYM_DATA_START_LOCAL(gdt)
-	.word gdt_end - gdt_start
-	.long _pa(gdt_start)
+	.word gdt_end - gdt_start - 1
+	.long _pa(gdt_start) /* x86-64 will overwrite if relocated. */
 	.word 0
 SYM_DATA_END(gdt)
 SYM_DATA_START_LOCAL(gdt_start)
@@ -163,5 +239,89 @@ SYM_DATA_START_LOCAL(early_stack)
 	.fill BOOT_STACK_SIZE, 1, 0
 SYM_DATA_END_LABEL(early_stack, SYM_L_LOCAL, early_stack_end)
 
+#ifdef CONFIG_X86_64
+/*
+ * We are not able to switch in one step to the final KERNEL ADDRESS SPACE
+ * because we need identity-mapped pages.
+ */
+#define l4_index(x)     (((x) >> 39) & 511)
+#define pud_index(x)    (((x) >> PUD_SHIFT) & (PTRS_PER_PUD-1))
+
+L4_PAGE_OFFSET  = l4_index(__PAGE_OFFSET_BASE_L4)
+L4_START_KERNEL = l4_index(__START_KERNEL_map)
+L3_START_KERNEL = pud_index(__START_KERNEL_map)
+
+#define SYM_DATA_START_PAGE_ALIGNED(name)			\
+	SYM_START(name, SYM_L_GLOBAL, .balign PAGE_SIZE)
+
+/* Automate the creation of 1 to 1 mapping pmd entries */
+#define PMDS(START, PERM, COUNT)			\
+	i = 0 ;						\
+	.rept (COUNT) ;					\
+	.quad	(START) + (i << PMD_SHIFT) + (PERM) ;	\
+	i = i + 1 ;					\
+	.endr
+
+/*
+ * Xen PVH needs a set of identity mapped and kernel high mapping
+ * page tables.  pvh_start_xen starts running on the identity mapped
+ * page tables, but xen_prepare_pvh calls into the high mapping.
+ * These page tables need to be relocatable and are only used until
+ * startup_64 transitions to init_top_pgt.
+ */
+SYM_DATA_START_PAGE_ALIGNED(pvh_init_top_pgt)
+	.quad   pvh_level3_ident_pgt - __START_KERNEL_map + _KERNPG_TABLE_NOENC
+	.org    pvh_init_top_pgt + L4_PAGE_OFFSET*8, 0
+	.quad   pvh_level3_ident_pgt - __START_KERNEL_map + _KERNPG_TABLE_NOENC
+	.org    pvh_init_top_pgt + L4_START_KERNEL*8, 0
+	/* (2^48-(2*1024*1024*1024))/(2^39) = 511 */
+	.quad   pvh_level3_kernel_pgt - __START_KERNEL_map + _PAGE_TABLE_NOENC
+SYM_DATA_END(pvh_init_top_pgt)
+
+SYM_DATA_START_PAGE_ALIGNED(pvh_level3_ident_pgt)
+	.quad	pvh_level2_ident_pgt - __START_KERNEL_map + _KERNPG_TABLE_NOENC
+	.fill	511, 8, 0
+SYM_DATA_END(pvh_level3_ident_pgt)
+SYM_DATA_START_PAGE_ALIGNED(pvh_level2_ident_pgt)
+	/*
+	 * Since I easily can, map the first 1G.
+	 * Don't set NX because code runs from these pages.
+	 *
+	 * Note: This sets _PAGE_GLOBAL despite whether
+	 * the CPU supports it or it is enabled.  But,
+	 * the CPU should ignore the bit.
+	 */
+	PMDS(0, __PAGE_KERNEL_IDENT_LARGE_EXEC, PTRS_PER_PMD)
+SYM_DATA_END(pvh_level2_ident_pgt)
+SYM_DATA_START_PAGE_ALIGNED(pvh_level3_kernel_pgt)
+	.fill	L3_START_KERNEL,8,0
+	/* (2^48-(2*1024*1024*1024)-((2^39)*511))/(2^30) = 510 */
+	.quad	pvh_level2_kernel_pgt - __START_KERNEL_map + _KERNPG_TABLE_NOENC
+	.quad	0 /* no fixmap */
+SYM_DATA_END(pvh_level3_kernel_pgt)
+
+SYM_DATA_START_PAGE_ALIGNED(pvh_level2_kernel_pgt)
+	/*
+	 * Kernel high mapping.
+	 *
+	 * The kernel code+data+bss must be located below KERNEL_IMAGE_SIZE in
+	 * virtual address space, which is 1 GiB if RANDOMIZE_BASE is enabled,
+	 * 512 MiB otherwise.
+	 *
+	 * (NOTE: after that starts the module area, see MODULES_VADDR.)
+	 *
+	 * This table is eventually used by the kernel during normal runtime.
+	 * Care must be taken to clear out undesired bits later, like _PAGE_RW
+	 * or _PAGE_GLOBAL in some cases.
+	 */
+	PMDS(0, __PAGE_KERNEL_LARGE_EXEC, KERNEL_IMAGE_SIZE/PMD_SIZE)
+SYM_DATA_END(pvh_level2_kernel_pgt)
+
+	ELFNOTE(Xen, XEN_ELFNOTE_PHYS32_RELOC,
+		     .long KERNEL_IMAGE_SIZE;
+		     .long LOAD_PHYSICAL_ADDR;
+		     .long CONFIG_PHYSICAL_ALIGN)
+#endif
+
 	ELFNOTE(Xen, XEN_ELFNOTE_PHYS32_ENTRY,
-	             _ASM_PTR (pvh_start_xen - __START_KERNEL_map))
+	             .long (pvh_start_xen - __START_KERNEL_map))
diff --git a/include/xen/interface/elfnote.h b/include/xen/interface/elfnote.h
index 38deb1214613..9ebd4e79bb41 100644
--- a/include/xen/interface/elfnote.h
+++ b/include/xen/interface/elfnote.h
@@ -185,9 +185,25 @@
  */
 #define XEN_ELFNOTE_PHYS32_ENTRY 18
 
+/*
+ * Physical loading constraints for PVH kernels
+ *
+ * Used to place constraints on the guest physical loading addresses and
+ * alignment for a PVH kernel.
+ *
+ * The presence of this note indicates the kernel supports relocating itself.
+ *
+ * The note may include up to three 32bit values in the following order:
+ *  - a maximum address for the entire image to be loaded below (default
+ *      0xffffffff)
+ *  - a minimum address for the start of the image (default 0)
+ *  - a required start alignment (default 0x200000)
+ */
+#define XEN_ELFNOTE_PHYS32_RELOC 19
+
 /*
  * The number of the highest elfnote defined.
  */
-#define XEN_ELFNOTE_MAX XEN_ELFNOTE_PHYS32_ENTRY
+#define XEN_ELFNOTE_MAX XEN_ELFNOTE_PHYS32_RELOC
 
 #endif /* __XEN_PUBLIC_ELFNOTE_H__ */
-- 
2.44.0



From xen-devel-bounces@lists.xenproject.org Tue Mar 19 21:53:30 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 21:53:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695629.1085530 (Exim 4.92)
	(envelope-from )
	id 1rmhOW-0002L8-3K; Tue, 19 Mar 2024 21:53:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695629.1085530; Tue, 19 Mar 2024 21:53:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmhOV-0002L1-Un; Tue, 19 Mar 2024 21:53:15 +0000
Received: by outflank-mailman (input) for mailman id 695629;
 Tue, 19 Mar 2024 21:53:14 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmhOU-0002Kr-P4; Tue, 19 Mar 2024 21:53:14 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmhOU-00061m-JB; Tue, 19 Mar 2024 21:53:14 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmhOU-0004hf-At; Tue, 19 Mar 2024 21:53:14 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rmhOU-0005k4-AT; Tue, 19 Mar 2024 21:53:14 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=Fjh+Yros+eeU1cMj4rQQ+wZpTWGVtK4NREdBLOXAFv0=; b=Fi4N2P9ODgP/JqC0luEbTMhBmm
	PQgv2DLuwv+3qILi7usHn15By0khH5PXHATEbvVxV6qBdYF2/Jkd586gWLQbZIY5PXG6mSz4k9eHc
	evZy0i5ZNmTbNk8HjBgQZck53qGcuAwnsdUYH6ASZ1C4Z7sltd3Al8DzaR7bV20YznH0=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 185100: tolerable all pass - PUSHED
X-Osstest-Failures:
    xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    xen=188fa82305e72b725473db9146e20cc9abf7bff3
X-Osstest-Versions-That:
    xen=d2276b86e5eb8dd2617d917f7b49cdd1f29ac299
From: osstest service owner 
Date: Tue, 19 Mar 2024 21:53:14 +0000

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          16 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  188fa82305e72b725473db9146e20cc9abf7bff3
baseline version:
 xen                  d2276b86e5eb8dd2617d917f7b49cdd1f29ac299

Last test of basis   185094  2024-03-19 11:00:26 Z    0 days
Testing same since   185100  2024-03-19 19:00:31 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper 

jobs:
 build-arm64-xsm                                              pass    
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-amd64-libvirt                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 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
   d2276b86e5..188fa82305  188fa82305e72b725473db9146e20cc9abf7bff3 -> smoke


From xen-devel-bounces@lists.xenproject.org Tue Mar 19 22:13:47 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Mar 2024 22:13:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695634.1085540 (Exim 4.92)
	(envelope-from )
	id 1rmhiG-0005W0-Nn; Tue, 19 Mar 2024 22:13:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695634.1085540; Tue, 19 Mar 2024 22:13:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmhiG-0005Vt-Jj; Tue, 19 Mar 2024 22:13:40 +0000
Received: by outflank-mailman (input) for mailman id 695634;
 Tue, 19 Mar 2024 22:13:40 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmhiG-0005VT-1i; Tue, 19 Mar 2024 22:13:40 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmhiF-0006Rj-RF; Tue, 19 Mar 2024 22:13:39 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmhiF-0005gt-Ff; Tue, 19 Mar 2024 22:13:39 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rmhiF-0007DY-F5; Tue, 19 Mar 2024 22:13:39 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=oRCo49364Mn4GUKuKfQ9W1YO24pfMaoM3ElieoBFgCI=; b=KBBNg//FMKfK3vRv5Eu37Etdw5
	hH8GqU60XfD0V19maAdeedEwo1P30XO17gPJuEDUQX9iC9Mo+gob9M+6RRJaEaDk4IKv0QokeTHun
	Glt6nme/m+XVZtlPg4HjRcPyf1IHJ0vT16NXZ6L6ffpiYU3rtjYZIgOOOoYtyJZH6PZA=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 185088: regressions - trouble: blocked/broken/fail/pass
X-Osstest-Failures:
    linux-linus:build-amd64-libvirt::broken:regression
    linux-linus:build-amd64-xsm::broken:regression
    linux-linus:build-armhf-pvops::broken:regression
    linux-linus:build-i386-xsm::broken:regression
    linux-linus:build-amd64-xsm:host-build-prep:fail:regression
    linux-linus:build-amd64-libvirt:host-build-prep:fail:regression
    linux-linus:build-armhf-pvops:host-build-prep:fail:regression
    linux-linus:build-i386-xsm:host-build-prep:fail:regression
    linux-linus:test-amd64-amd64-xl-xsm:build-check(1):blocked:nonblocking
    linux-linus:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:build-check(1):blocked:nonblocking
    linux-linus:test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
    linux-linus:test-amd64-amd64-xl-qemut-debianhvm-i386-xsm:build-check(1):blocked:nonblocking
    linux-linus:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking
    linux-linus:test-amd64-amd64-libvirt-pair:build-check(1):blocked:nonblocking
    linux-linus:test-amd64-amd64-libvirt-qcow2:build-check(1):blocked:nonblocking
    linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking
    linux-linus:test-amd64-amd64-libvirt-raw:build-check(1):blocked:nonblocking
    linux-linus:test-amd64-amd64-libvirt-xsm:build-check(1):blocked:nonblocking
    linux-linus:test-armhf-armhf-examine:build-check(1):blocked:nonblocking
    linux-linus:test-armhf-armhf-libvirt:build-check(1):blocked:nonblocking
    linux-linus:test-armhf-armhf-libvirt-qcow2:build-check(1):blocked:nonblocking
    linux-linus:test-armhf-armhf-libvirt-raw:build-check(1):blocked:nonblocking
    linux-linus:test-armhf-armhf-xl:build-check(1):blocked:nonblocking
    linux-linus:test-armhf-armhf-xl-arndale:build-check(1):blocked:nonblocking
    linux-linus:test-armhf-armhf-xl-credit1:build-check(1):blocked:nonblocking
    linux-linus:test-armhf-armhf-xl-credit2:build-check(1):blocked:nonblocking
    linux-linus:test-armhf-armhf-xl-multivcpu:build-check(1):blocked:nonblocking
    linux-linus:test-armhf-armhf-xl-rtds:build-check(1):blocked:nonblocking
    linux-linus:test-armhf-armhf-xl-vhd:build-check(1):blocked:nonblocking
    linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    linux=b3603fcb79b1036acae10602bffc4855a4b9af80
X-Osstest-Versions-That:
    linux=f6cef5f8c37f58a3bc95b3754c3ae98e086631ca
From: osstest service owner 
Date: Tue, 19 Mar 2024 22:13:39 +0000

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-libvirt                              broken
 build-amd64-xsm                                  broken
 build-armhf-pvops                                broken
 build-i386-xsm                                   broken
 build-amd64-xsm               5 host-build-prep          fail REGR. vs. 185075
 build-amd64-libvirt           5 host-build-prep          fail REGR. vs. 185075
 build-armhf-pvops             5 host-build-prep          fail REGR. vs. 185075
 build-i386-xsm                5 host-build-prep          fail REGR. vs. 185075

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-xsm       1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm  1 build-check(1)     blocked n/a
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm  1 build-check(1)     blocked n/a
 test-amd64-amd64-libvirt      1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt-qcow2  1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-raw  1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)               blocked  n/a
 test-armhf-armhf-examine      1 build-check(1)               blocked  n/a
 test-armhf-armhf-libvirt      1 build-check(1)               blocked  n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)               blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)               blocked  n/a
 test-armhf-armhf-xl           1 build-check(1)               blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)               blocked  n/a
 test-armhf-armhf-xl-credit1   1 build-check(1)               blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)               blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)               blocked  n/a
 test-armhf-armhf-xl-rtds      1 build-check(1)               blocked  n/a
 test-armhf-armhf-xl-vhd       1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop            fail like 185075
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop            fail like 185075
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop            fail like 185075
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop            fail like 185075
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 185075
 test-arm64-arm64-xl-thunderx 15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      16 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-raw 14 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-raw 15 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-vhd      14 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-vhd      15 saverestore-support-check    fail   never pass

version targeted for testing:
 linux                b3603fcb79b1036acae10602bffc4855a4b9af80
baseline version:
 linux                f6cef5f8c37f58a3bc95b3754c3ae98e086631ca

Last test of basis   185075  2024-03-18 07:48:04 Z    1 days
Testing same since   185088  2024-03-19 01:43:30 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Alexander Aring 
  Alexey Dobriyan 
  Alexey Kodanev 
  Alison Schofield 
  Amir Goldstein 
  Beau Belgrave 
  Borislav Petkov (AMD) 
  Chao Yu 
  Chengchang Tang 
  Christian Brauner 
  Christian Heusel 
  Chuck Lever 
  Daeho Jeong 
  Dan Williams 
  David Howells 
  David Teigland 
  Erick Archer 
  Feng Song 
  Guoqing Jiang 
  Gustavo A. R. Silva 
  Huang Yiwei 
  HuangXiaojia 
  Ian Murphy 
  Jack Wang 
  Jaegeuk Kim 
  Jason Gunthorpe 
  Jeff Layton 
  Jeffrey Hugo 
  Jichi Zhang 
  Joel Granados 
  John Garry 
  Junxian Huang 
  Kees Cook 
  Konstantin Taranov 
  Leon Romanovsky 
  Li Zhijian 
  linke li 
  Linus Torvalds 
  Luis Chamberlain 
  Luoyouming 
  Manjunath Patil 
  Masami Hiramatsu (Google) 
  Mike Marshall 
  Mustafa Ismail 
  Paolo Abeni 
  Randy Dunlap 
  Ricardo B. Marliere 
  Rodrigo Vivi 
  Samuel Holland 
  Sheng Yong 
  Shifeng Li 
  Shiraz Saleem 
  Sindhu Devale 
  Steven Rostedt (Google) 
  Steven Rostedt 
  Sunmin Jeong 
  Takashi Iwai 
  Takashi Sakamoto 
  Thomas Gleixner 
  Thomas Weißschuh 
  Thorsten Blum 
  Vincent Donnefort 
  Vlastimil Babka 
  wenglianfa 
  Wenjie Qi 
  William Kucharski 
  Wu Bo 
  Xiuhong Wang 
  Yi Zhang 
  Yonatan Nachum 
  Yongpeng Yang 
  Yunsheng Lin 
  Zhiguo Niu 
  Zhu Yanjun 

jobs:
 build-amd64-xsm                                              broken  
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               broken  
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          broken  
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          blocked 
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           blocked 
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        blocked 
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 blocked 
 test-amd64-amd64-libvirt-xsm                                 blocked 
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-amd64-xl-xsm                                      blocked 
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-freebsd11-amd64                             pass    
 test-amd64-amd64-freebsd12-amd64                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-armhf-armhf-xl-arndale                                  blocked 
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  blocked 
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  blocked 
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     blocked 
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     blocked 
 test-armhf-armhf-libvirt                                     blocked 
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                blocked 
 test-amd64-amd64-pair                                        pass    
 test-amd64-amd64-libvirt-pair                                blocked 
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-libvirt-qcow2                               blocked 
 test-armhf-armhf-libvirt-qcow2                               blocked 
 test-amd64-amd64-libvirt-raw                                 blocked 
 test-arm64-arm64-libvirt-raw                                 pass    
 test-armhf-armhf-libvirt-raw                                 blocked 
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-amd64-xl-vhd                                      pass    
 test-arm64-arm64-xl-vhd                                      pass    
 test-armhf-armhf-xl-vhd                                      blocked 


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

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

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    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

broken-job build-amd64-libvirt broken
broken-job build-amd64-xsm broken
broken-job build-armhf-pvops broken
broken-job build-i386-xsm broken

Not pushing.

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


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 05:56:31 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 05:56:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695681.1085571 (Exim 4.92)
	(envelope-from )
	id 1rmovu-0000T5-Km; Wed, 20 Mar 2024 05:56:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695681.1085571; Wed, 20 Mar 2024 05:56:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmovu-0000Sy-Hy; Wed, 20 Mar 2024 05:56:14 +0000
Received: by outflank-mailman (input) for mailman id 695681;
 Wed, 20 Mar 2024 05:56:13 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmovt-0000So-41; Wed, 20 Mar 2024 05:56:13 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmovs-0006Gz-TH; Wed, 20 Mar 2024 05:56:12 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmovs-0003nL-J2; Wed, 20 Mar 2024 05:56:12 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rmovs-0002eM-Ic; Wed, 20 Mar 2024 05:56:12 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=0KsPpT/TEIJ8fc/4NBdfHWrlY/e2jsPuo4Grczj6rxs=; b=6yOuePBOP0R3vdKmP8GAxooRvj
	MoNMQ3+HDFNCxAymY23UDU7X8LJLFqglxsmpQaceQMFZ3oNnpU6NSfjICi9iR9pxbpBeZNlBfMpW6
	hJuoLbAE+3NZdVBcifuDiF8eLAdGpNpsU3jMVnTSzgabMEc7dmkgTNbUfsi1Vy46jlhg=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [seabios test] 185103: tolerable FAIL - PUSHED
X-Osstest-Failures:
    seabios:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    seabios:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    seabios:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    seabios:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    seabios:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    seabios:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    seabios:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
X-Osstest-Versions-This:
    seabios=1588fd1437960d94cadc30c42243671e8c0f1281
X-Osstest-Versions-That:
    seabios=192e23b78418abc23a92a7174ae2294fabe4b8a3
From: osstest service owner 
Date: Wed, 20 Mar 2024 05:56:12 +0000

flight 185103 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185103/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop            fail like 185050
 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop             fail like 185050
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 185050
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop            fail like 185050
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop             fail like 185050
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass

version targeted for testing:
 seabios              1588fd1437960d94cadc30c42243671e8c0f1281
baseline version:
 seabios              192e23b78418abc23a92a7174ae2294fabe4b8a3

Last test of basis   185050  2024-03-15 14:41:08 Z    4 days
Testing same since   185103  2024-03-20 00:42:59 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Kevin O'Connor 

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-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/seabios.git
   192e23b..1588fd1  1588fd1437960d94cadc30c42243671e8c0f1281 -> xen-tested-master


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 06:01:28 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 06:01:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695686.1085582 (Exim 4.92)
	(envelope-from )
	id 1rmp0v-0002Ba-BF; Wed, 20 Mar 2024 06:01:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695686.1085582; Wed, 20 Mar 2024 06:01:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmp0v-0002BT-80; Wed, 20 Mar 2024 06:01:25 +0000
Received: by outflank-mailman (input) for mailman id 695686;
 Wed, 20 Mar 2024 06:01:23 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmp0t-0002BF-QO
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 06:01:23 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 465e7524-e67f-11ee-afdd-a90da7624cb6;
 Wed, 20 Mar 2024 07:01:22 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 612AD60DF0;
 Wed, 20 Mar 2024 06:01:20 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3AF21C433C7;
 Wed, 20 Mar 2024 06:01:18 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 465e7524-e67f-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1710914479;
	bh=YEvskiJv4b5eMlWYh4pUDKefgzPN8ylcsJhfV6+5lT0=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=IwkCDaAn4mXvnPqxyWqOIMNEzA3sRlJ8TOQ67D/ueHTkCFWG+mbyZFlRdPMFMSLn5
	 NS8mKmrj5NdH/i9GXk94oIcOyaITXjbQXZU8GuMASZ5aCJOS6rkryyRYFxDGkkepEu
	 pF2MKc0PpYoM1faB6JnquDnV1rPhZwqitWNXgGfPPvssi3exfYH7y5BDH8LtV52cjG
	 ZxRYJKeGRDddXhYyrPBuonXJNX/rq33oft4SCXO91W4FVm5vwzJUh23q78KT922LuG
	 /+dXAPOsutUOKumyX0gffDrUzCWYmDQI7v8xgoEpHN66fkBHiCRH9NB0TtejXaJh2+
	 IeYnwQyQe5Mmg==
Date: Tue, 19 Mar 2024 23:01:16 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich 
cc: Stefano Stabellini , andrew.cooper3@citrix.com, 
    bertrand.marquis@arm.com, george.dunlap@citrix.com, julien@xen.org, 
    michal.orzel@amd.com, roger.pau@citrix.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2] docs/misra: document the expected sizes of integer
 types
In-Reply-To: 
Message-ID: 
References:  <6a76723e-ba47-40b3-8f33-d68030b14299@suse.com>  <7ab73379-b057-4568-9869-141cef185752@suse.com>
  
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Tue, 19 Mar 2024, Jan Beulich wrote:
> On 19.03.2024 04:37, Stefano Stabellini wrote:
> > On Mon, 18 Mar 2024, Jan Beulich wrote:
> >> On 16.03.2024 01:07, Stefano Stabellini wrote:
> >>> On Fri, 15 Mar 2024, Jan Beulich wrote:
> >>>> On 14.03.2024 23:17, Stefano Stabellini wrote:
> >>>>> Xen makes assumptions about the size of integer types on the various
> >>>>> architectures. Document these assumptions.
> >>>>
> >>>> My prior reservation wrt exact vs minimum sizes remains.
> >>>
> >>> We have to specify the exact size. In practice the size is predetermined
> >>> and exact with all our supported compilers given a architecture.
> >>
> >> But that's not the purpose of this document; if it was down to what
> >> compilers offer, we could refer to compiler documentation (and iirc we
> >> already do for various aspects). The purpose of this document, aiui,
> >> is to document assumption we make in hypervisor code. And those should
> >> be >=, not ==.
> > 
> > Well... I guess the two of us are making different assumptions then :-)
> > 
> > Which is the reason why documenting assumptions is so important. More at
> > the bottom.
> > 
> > 
> >>> Most importantly, unfortunately we use non-fixed-size integer types in
> >>> C hypercall entry points and public ABIs. In my opinion, that is not
> >>> acceptable.
> >>
> >> The problem is that I can't see the reason for you thinking so. The C
> >> entry points sit past assembly code doing (required to do) necessary
> >> adjustments, if any. If there was no assembly layer, whether to use
> >> fixed with types for such parameters would depend on what the
> >> architecture guarantees.
> > 
> > This could be the source of the disagreement. I see the little assembly
> > code as not important, I consider it just like a little trampoline to
> > me. As we describe the hypercalls in C header files, I consider the C
> > functions the "official" hypercall entry points.
> 
> Why would that be? Any code we execute in Xen is relevant.

There are a few reasons:

- the public interface is described in a C header so it makes sense for
  the corresponding implementation to be in C

- the C entry point is often both the entry point in C and also common
  code

- depending on the architecture, there is typically always some minimal
  assembly entry code to prepare the environment before we can jump into
  C-land; still one wouldn't consider those minimal and routine assembly
  operations to be a meaningful hypercall entry point corresponding to
  the C declaration in the public headers

- as per MISRA and also general good practice, we need the declaration
  in the public header files to match the definition in C


> > Also, as this is an ABI, I consider mandatory to use clear width
> > definitions of all the types (whether with this document or with
> > fixed-width types, and fixed-width types are clearer and better) in both
> > the C header files that describe the ABI interfaces, as well as the C
> > entry points that corresponds to it. E.g. I think we have to use
> > the same types in both do_sched_op and the hypercall description in
> > xen/include/public/sched.h
> 
> There are two entirely separate aspects to the ABI: One is what we
> document towards consumers of it. The other is entirely internal, i.e.
> an implementation detail - how we actually consume the data.
> Documenting fixed-width types towards consumers is probably okay,
> albeit (see below) imo still not strictly necessary (for being
> needlessly limiting).

I don't see it this way.

As the Xen public interface description is in C and used during the
build, my opinion is that the public description and the C definition
need to match.

Also, I don't understand how you can say that public interfaces don't
strictly necessarily have to use fixed-width types.

Imagine that you use native types with different compilers that can
actually output different width interger sizes (which is not possible
today with gcc or clang). Imagine that a guest is written in a language
other than C (e.g. Java) based on the public interface description. It
cannot work correctly, can it?

I don't see how we can possibly have a public interface with anything
other than fixed-width integers.


> >> As to public ABIs - that's structure definitions, and I agree we ought
> >> to uniformly use fixed-width types there. We largely do; a few things
> >> still require fixing.
> > 
> > +1
> > 
> > 
> >>> We have two options:
> >>>
> >>> 1) we go with this document, and we clarify that even if we specify
> >>>   "unsigned int", we actually mean a 32-bit integer
> >>>
> >>> 2) we change all our public ABIs and C hypercall entry points to use
> >>>    fixed-size types (e.g. s/unsigned int/uint32_t/g)
> >>>
> >>> 2) is preferred because it is clearer but it is more work. So I went
> >>> with 1). I also thought you would like 1) more.
> >>
> >> For ABIs (i.e. structures) we ought to be making that change anyway.
> >> Leaving basic types in there is latently buggy.
> > 
> > I am glad we agree :-)
> > 
> > It is just that I also consinder the C hypercall entry points as part of
> > the ABI
> > 
> > 
> >> I'm happy to see a document like this added, for the purpose described
> >> above. But to me 1) and 2) and largely independent of one another.
> > 
> > Good that you are also happy with a document like this.
> > 
> > The remaining question is: what about the rest of the C functions in Xen
> > that are certainly not part of an ABI?
> 
> As per above - anything internal isn't part of the ABI, C entry points
> for hypercall handlers included. All we need to ensure is that we consume
> the data according to what the ABI sets forth.

It doesn't look like we'll convince one another on this point. But let
me try another way.

In my view, having mismatched types between declaration and definition
and having non-fixed-width types in C hypercall entry points is really
bad for a number of reasons, among them:
- correctness
- risk of ABI breakage
- mismatch of declaration and definition

In your view, the drawback is not following the CODING_STYLE.

The two points of views on this subject don't have the same to lose. If
I were you, I would probably not invest my energy to defend the
CODING_STYLE.


> To use wording from George when he criticized my supposed lack of actual
> arguments: While there's nothing technically wrong with using fixed
> width types there (or in fact everywhere), there's also nothing technically
> wrong with using plain C types there and almost everywhere else (ABI
> structures excluded). With both technically equal, ./CODING_STYLE has the
> only criteria to pick between the two. IOW that's what I view wrong in
> George's argumentation: Demanding that I provide technical arguments when
> the desire to use fixed width types for the purpose under discussion also
> isn't backed by any.

I don't think we are in violation of the CODING_STYLE as it explicitly
accounts for exceptions. Public interfaces declarations and definitions
(hypercalls C entry points included) are an exception.

In my opinion, using fixed-width integers in public headers and C
definitions (including C hypercall entry points) is top priority for
correctness. Correctness is more important than style. So, if we need to
change the CODING_STYLE to get there, let's change the CODING_STYLE.


> > Those are less critical, still this document should apply uniformily to
> > them too. I don't understand why you are making the >= width assumption
> > you mentioned at the top of the file when actually it is impossible to
> > exercise or test this assumption on any compiler or any architecture
> > that works with Xen. If it cannot be enabled, it hasn't been tested, and
> > it probably won't work.
> 
> Hmm, yes, that's one way to look at it. My perspective is different though:
> By writing down assumptions that are more strict than necessary, we'd be
> excluding ports to environments meeting the >= assumption, but not meeting
> the == one. Unless of course you can point me at any place where - not
> just by mistake / by being overly lax - we truly depend on the == that you
> want to put in place. IOW yes, there likely would need to be adjustments
> to code if such a port was to happen. Yet we shouldn't further harden
> requirements that were never meant to be there.

I have already shown that all the current implementations and tests only
check for ==. In my opinion, this is sufficient evidence that >= is not
supported.

If you admit it probably wouldn't work without fixes today, would you
security-support such a configuration? Would you safety-support it? I
wouldn't want to buy a car running Xen compiled with a compiler using
integer sizes different from the ones written in this document.

Let me summarize our positions on these topics.

Agreed points:
- public interfaces should use fixed-width types
- it is a good idea to have a document describing our assumptions about
  integer types

Open decision points and misalignments:
- Should the C hypercall entry points match the public header
  declarations and ideally use fixed-width integer types? 

I'd say yes and I would argue for it

- Should the document describing our assumptions about integer types
  specify == (unsigned int == uint32_t) or >= (unsigned int >=
  uint32_t)?

I'd say specify == and I would argue for it


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 06:35:44 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 06:35:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695691.1085591 (Exim 4.92)
	(envelope-from )
	id 1rmpY1-0006Qy-Rw; Wed, 20 Mar 2024 06:35:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695691.1085591; Wed, 20 Mar 2024 06:35:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmpY1-0006Qr-PB; Wed, 20 Mar 2024 06:35:37 +0000
Received: by outflank-mailman (input) for mailman id 695691;
 Wed, 20 Mar 2024 06:35:36 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmpY0-0006Ql-Lz
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 06:35:36 +0000
Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com
 [2a00:1450:4864:20::52f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0da2afef-e684-11ee-a1ee-f123f15fe8a2;
 Wed, 20 Mar 2024 07:35:34 +0100 (CET)
Received: by mail-ed1-x52f.google.com with SMTP id
 4fb4d7f45d1cf-56b8248e2d8so3366577a12.1
 for ; Tue, 19 Mar 2024 23:35:33 -0700 (PDT)
Received: from ?IPV6:2003:e5:873a:400:704b:6dbb:e7c0:786e?
 (p200300e5873a0400704b6dbbe7c0786e.dip0.t-ipconnect.de.
 [2003:e5:873a:400:704b:6dbb:e7c0:786e])
 by smtp.gmail.com with ESMTPSA id
 h7-20020a056402094700b00568abb329a3sm5555856edz.88.2024.03.19.23.35.32
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 19 Mar 2024 23:35:32 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0da2afef-e684-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710916533; x=1711521333; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:references:cc:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=+lDzr2w02rVl5i39iHJOGsPh/Br7Dg/rii9eZpfwt1M=;
        b=EP60K0yNx+v9KEsT1x0SWrmKY97eQz0QDeB1QC0+X1VzcSdn61Ipn+cdzcQ4IZRGai
         qS9B7z8s47oRIggCm8NoXTxGyp2Wcdi8TFLbLPaAYmO3KxbSzYt73gv2dt6dSAesN27N
         gGoIWPzWDHMendGF4RtcJUC9vXi5OCx18+xNZ/VpzMDyfA+Vv47/2QmyBCMmZbO8bVUj
         4yYwNBArRcayTzGXgYl2NLr6K5i+fBTB1XjP8Mi3K0Bc7y2TTYnKpc5bxyQrN/DF0MYY
         AaYEvx/SqoXxvHsrDzly/TOLclqDQggMXZYLDzHm3EIaEqiYBJFUEQNg6L3Kml8xLiPV
         3kQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710916533; x=1711521333;
        h=content-transfer-encoding:in-reply-to:from:references:cc:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=+lDzr2w02rVl5i39iHJOGsPh/Br7Dg/rii9eZpfwt1M=;
        b=e/8KLsKiKWf+knx0j7ypJnGfk0qnx9gbwb5OjnPUAcjPYkL9dPcAvRLXEztBAK8aJg
         gMpUBM8rJMjKVTIypERBrpdQzsaNu/8QXvL48GdaPxdyjuBjLq3KvNME55wKmcKQFB5h
         M+YUQH/lLEE+PwOlUqCpK8rIUFP9n96JsGj2dxKtk/G8enhZ7D0hHwNP0os3Ce8CIToo
         CEd0aMWDdG8QMrqFKsYRXnS/ew5YN99T343g20sXt1K/0Rf3VGakyuobTSoWtHeFjuhE
         rE/NiqWGXL+rQSGxxB3lv5y0wu3SHrO5Na45vVsrIyLtjZOR8xNfsAgGBoeAjWdFrVjy
         2W3g==
X-Forwarded-Encrypted: i=1; AJvYcCXTUX4gL8GF1lLE/N95TnWOcSJf2jm1FmwMPGrSvshenGxFmkMaQTKfUkRLUEpELJax94iA/ETDO8s+uBnbFL8XMC62kz8CStOWXgorNRE=
X-Gm-Message-State: AOJu0Yz7YS9UTiLUa4ubTuKtHSKAWuer43lcedWxW1TurpLWTQub/U/5
	4Nz4NvBbjRMYWmrbqODBEAtjPTK/uOwNKyk/HpywfKZBEFjGchbmV75qHVyro/Q=
X-Google-Smtp-Source: AGHT+IETFzu+HFRx/soYUPuG6RGaeJvJMFpY5Cqy84nbvtlZhn5eXhYPgU4OZja5Xyjy4WHVr2r9DQ==
X-Received: by 2002:a05:6402:5384:b0:568:ae7:bc0 with SMTP id ew4-20020a056402538400b005680ae70bc0mr12089603edb.34.1710916533023;
        Tue, 19 Mar 2024 23:35:33 -0700 (PDT)
Message-ID: <553a8bfb-94f3-4c3a-b1ae-17d0cb185737@suse.com>
Date: Wed, 20 Mar 2024 07:35:32 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/rwlock: Don't perpeuatite broken API in new logic
Content-Language: en-US
To: Andrew Cooper ,
 Xen-devel 
Cc: George Dunlap , Jan Beulich
 , Stefano Stabellini ,
 Julien Grall 
References: <20240319113020.3843309-1-andrew.cooper3@citrix.com>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
In-Reply-To: <20240319113020.3843309-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 19.03.24 12:30, Andrew Cooper wrote:
> The single user wants this the sane way around.  Write it as a normal static
> inline just like rspin_lock().
> 
> Fixes: cc3e8df542ed ("xen/spinlock: add rspin_[un]lock_irq[save|restore]()")
> Signed-off-by: Andrew Cooper 

Reviewed-by: Juergen Gross 

Maybe with the subject fixed (s/rwlock/spinlock/).


Juergen



From xen-devel-bounces@lists.xenproject.org Wed Mar 20 06:52:30 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 06:52:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695695.1085601 (Exim 4.92)
	(envelope-from )
	id 1rmpoH-00015R-Aj; Wed, 20 Mar 2024 06:52:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695695.1085601; Wed, 20 Mar 2024 06:52:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmpoH-00015K-7Y; Wed, 20 Mar 2024 06:52:25 +0000
Received: by outflank-mailman (input) for mailman id 695695;
 Wed, 20 Mar 2024 06:50:00 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmplw-0000AA-DY
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 06:50:00 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.133.124])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 10f34e00-e686-11ee-afdd-a90da7624cb6;
 Wed, 20 Mar 2024 07:49:59 +0100 (CET)
Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73])
 by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-650-erG_ZhkbPw68buUwpoSCoA-1; Wed,
 20 Mar 2024 02:49:53 -0400
Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com
 [10.11.54.7])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 963471C06901;
 Wed, 20 Mar 2024 06:49:52 +0000 (UTC)
Received: from corto.redhat.com (unknown [10.39.192.59])
 by smtp.corp.redhat.com (Postfix) with ESMTP id E851A1C060A6;
 Wed, 20 Mar 2024 06:49:48 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 10f34e00-e686-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1710917397;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=YdM+8DlBSfQGNojw2NWBbBFEkSwJYFiGvC2NciZ76U0=;
	b=Kv6r4ntuXWXBikreIho718NAxSQohzkXZvuTst3lQoH6ThWD70xx/z+vprNkCFfCei+22p
	RU5AvWgctABLMFy+BBsK6lsXQARd9v/8Zt214D/mKddyLqDa0hH1Z05kqaqk0Qi1KYHgvK
	nz45wayFTaGeSSqL5ZAP+YhEIKyp0cg=
X-MC-Unique: erG_ZhkbPw68buUwpoSCoA-1
From: =?UTF-8?q?C=C3=A9dric=20Le=20Goater?= 
To: qemu-devel@nongnu.org,
	Stefano Stabellini ,
	Anthony Perard ,
	Paul Durrant ,
	Paolo Bonzini ,
	Richard Henderson ,
	Eduardo Habkost ,
	"Michael S. Tsirkin" ,
	Marcel Apfelbaum ,
	Alex Williamson ,
	=?UTF-8?q?C=C3=A9dric=20Le=20Goater?= ,
	Peter Xu ,
	David Hildenbrand ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
Cc: Fabiano Rosas ,
	Avihai Horon ,
	Markus Armbruster ,
	Prasad Pandit ,
	xen-devel@lists.xenproject.org
Subject: [PATCH for-9.1 v5 09/14] memory: Add Error** argument to .log_global_start() handler
Date: Wed, 20 Mar 2024 07:49:05 +0100
Message-ID: <20240320064911.545001-10-clg@redhat.com>
In-Reply-To: <20240320064911.545001-1-clg@redhat.com>
References: <20240320064911.545001-1-clg@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.7

Modify all .log_global_start() handlers to take an Error** parameter
and return a bool. Adapt memory_global_dirty_log_start() to interrupt
on the first error the loop on handlers. In such case, a rollback is
performed to stop dirty logging on all listeners where it was
previously enabled.

Cc: Stefano Stabellini 
Cc: Anthony Perard 
Cc: Paul Durrant 
Cc: "Michael S. Tsirkin" 
Cc: Paolo Bonzini 
Cc: David Hildenbrand 
Signed-off-by: Cédric Le Goater 
---

 Changes in v5:

 - Removed memory_global_dirty_log_rollback
 - Introduced memory_global_dirty_log_do_start() to call
   .log_global_start() handlers and do the rollback in case of error.
 - Kept modification of the global_dirty_tracking flag within
   memory_global_dirty_log_start()  
 - Added an assert on error of a .log_global_start() handler in
   listener_add_address_space()

 include/exec/memory.h |  5 ++++-
 hw/i386/xen/xen-hvm.c |  3 ++-
 hw/vfio/common.c      |  4 +++-
 hw/virtio/vhost.c     |  3 ++-
 system/memory.c       | 37 +++++++++++++++++++++++++++++++++++--
 5 files changed, 46 insertions(+), 6 deletions(-)

diff --git a/include/exec/memory.h b/include/exec/memory.h
index 8626a355b310ed7b1a1db7978ba4b394032c2f15..5555567bc4c9fdb53e8f63487f1400980275687d 100644
--- a/include/exec/memory.h
+++ b/include/exec/memory.h
@@ -998,8 +998,11 @@ struct MemoryListener {
      * active at that time.
      *
      * @listener: The #MemoryListener.
+     * @errp: pointer to Error*, to store an error if it happens.
+     *
+     * Return: true on success, else false setting @errp with error.
      */
-    void (*log_global_start)(MemoryListener *listener);
+    bool (*log_global_start)(MemoryListener *listener, Error **errp);
 
     /**
      * @log_global_stop:
diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
index 7745cb39631ea423aeb6e5d3eb7f7bcbe27ec6fa..f6e9a1bc86491783077b5cb5aafdb19ab294e392 100644
--- a/hw/i386/xen/xen-hvm.c
+++ b/hw/i386/xen/xen-hvm.c
@@ -457,11 +457,12 @@ static void xen_log_sync(MemoryListener *listener, MemoryRegionSection *section)
                           int128_get64(section->size));
 }
 
-static void xen_log_global_start(MemoryListener *listener)
+static bool xen_log_global_start(MemoryListener *listener, Error **errp)
 {
     if (xen_enabled()) {
         xen_in_migration = true;
     }
+    return true;
 }
 
 static void xen_log_global_stop(MemoryListener *listener)
diff --git a/hw/vfio/common.c b/hw/vfio/common.c
index 011ceaab89433de4496dffadc737286e053f321d..8f9cbdc0264044ce587877a7d19d14b28527291b 100644
--- a/hw/vfio/common.c
+++ b/hw/vfio/common.c
@@ -1066,7 +1066,8 @@ out:
     return ret;
 }
 
-static void vfio_listener_log_global_start(MemoryListener *listener)
+static bool vfio_listener_log_global_start(MemoryListener *listener,
+                                           Error **errp)
 {
     VFIOContainerBase *bcontainer = container_of(listener, VFIOContainerBase,
                                                  listener);
@@ -1083,6 +1084,7 @@ static void vfio_listener_log_global_start(MemoryListener *listener)
                      ret, strerror(-ret));
         vfio_set_migration_error(ret);
     }
+    return !ret;
 }
 
 static void vfio_listener_log_global_stop(MemoryListener *listener)
diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c
index 2e4e040db87acf45166da86d268077f54511d82c..d405f03caf2fd3a5ea23bdc0392f4c6c072bc10b 100644
--- a/hw/virtio/vhost.c
+++ b/hw/virtio/vhost.c
@@ -1044,7 +1044,7 @@ check_dev_state:
     return r;
 }
 
-static void vhost_log_global_start(MemoryListener *listener)
+static bool vhost_log_global_start(MemoryListener *listener, Error **errp)
 {
     int r;
 
@@ -1052,6 +1052,7 @@ static void vhost_log_global_start(MemoryListener *listener)
     if (r < 0) {
         abort();
     }
+    return true;
 }
 
 static void vhost_log_global_stop(MemoryListener *listener)
diff --git a/system/memory.c b/system/memory.c
index a229a79988fce2aa3cb77e3a130db4c694e8cd49..ca4d91484fb3d06f4b902486fea49dba86dc141b 100644
--- a/system/memory.c
+++ b/system/memory.c
@@ -2914,9 +2914,33 @@ static unsigned int postponed_stop_flags;
 static VMChangeStateEntry *vmstate_change;
 static void memory_global_dirty_log_stop_postponed_run(void);
 
+static bool memory_global_dirty_log_do_start(Error **errp)
+{
+    MemoryListener *listener;
+
+    QTAILQ_FOREACH(listener, &memory_listeners, link) {
+        if (listener->log_global_start) {
+            if (!listener->log_global_start(listener, errp)) {
+                goto err;
+            }
+        }
+    }
+    return true;
+
+err:
+    while ((listener = QTAILQ_PREV(listener, link)) != NULL) {
+        if (listener->log_global_stop) {
+            listener->log_global_stop(listener);
+        }
+    }
+
+    return false;
+}
+
 void memory_global_dirty_log_start(unsigned int flags)
 {
     unsigned int old_flags;
+    Error *local_err = NULL;
 
     assert(flags && !(flags & (~GLOBAL_DIRTY_MASK)));
 
@@ -2936,7 +2960,13 @@ void memory_global_dirty_log_start(unsigned int flags)
     trace_global_dirty_changed(global_dirty_tracking);
 
     if (!old_flags) {
-        MEMORY_LISTENER_CALL_GLOBAL(log_global_start, Forward);
+        if (!memory_global_dirty_log_do_start(&local_err)) {
+            global_dirty_tracking &= ~flags;
+            trace_global_dirty_changed(global_dirty_tracking);
+            error_report_err(local_err);
+            return;
+        }
+
         memory_region_transaction_begin();
         memory_region_update_pending = true;
         memory_region_transaction_commit();
@@ -3014,8 +3044,11 @@ static void listener_add_address_space(MemoryListener *listener,
         listener->begin(listener);
     }
     if (global_dirty_tracking) {
+        /*
+         * Migration has already started. Assert on any error.
+         */
         if (listener->log_global_start) {
-            listener->log_global_start(listener);
+            listener->log_global_start(listener, &error_abort);
         }
     }
 
-- 
2.44.0



From xen-devel-bounces@lists.xenproject.org Wed Mar 20 06:52:30 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 06:52:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695697.1085608 (Exim 4.92)
	(envelope-from )
	id 1rmpoH-00018j-KN; Wed, 20 Mar 2024 06:52:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695697.1085608; Wed, 20 Mar 2024 06:52:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmpoH-00018Z-FL; Wed, 20 Mar 2024 06:52:25 +0000
Received: by outflank-mailman (input) for mailman id 695697;
 Wed, 20 Mar 2024 06:50:10 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmpm6-0000AA-12
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 06:50:10 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.129.124])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 17236479-e686-11ee-afdd-a90da7624cb6;
 Wed, 20 Mar 2024 07:50:09 +0100 (CET)
Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73])
 by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-611-81MjY4A2OjelT2_yDjhWkA-1; Wed,
 20 Mar 2024 02:50:00 -0400
Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com
 [10.11.54.7])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 723113CBDF6A;
 Wed, 20 Mar 2024 06:49:59 +0000 (UTC)
Received: from corto.redhat.com (unknown [10.39.192.59])
 by smtp.corp.redhat.com (Postfix) with ESMTP id 791411C060CE;
 Wed, 20 Mar 2024 06:49:55 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 17236479-e686-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1710917408;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=3+fu3I95chIk56zixXafJc0iqGViBh7Y5/UDMejOikQ=;
	b=hqwJ3WMzyZ81lxhV07xEIrgy0D/Mjwm3jSnG47q60IaXtQdwmCPpLPm1qbj+o2dZzfPVTs
	hGAQ825ydZd9DjepTnpVXkxcIXPJDEuInwrdGmbyUcAHmeNTFvtdNFpIcUniOo4vfM3kx8
	xRWMds4TL2C7MUhiX2RC0dukG5B8O4I=
X-MC-Unique: 81MjY4A2OjelT2_yDjhWkA-1
From: =?UTF-8?q?C=C3=A9dric=20Le=20Goater?= 
To: qemu-devel@nongnu.org,
	Stefano Stabellini ,
	Anthony Perard ,
	Paul Durrant ,
	Paolo Bonzini ,
	Richard Henderson ,
	Eduardo Habkost ,
	"Michael S. Tsirkin" ,
	Marcel Apfelbaum ,
	Peter Xu ,
	David Hildenbrand ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Hyman Huang ,
	Fabiano Rosas 
Cc: Alex Williamson ,
	Avihai Horon ,
	Markus Armbruster ,
	Prasad Pandit ,
	=?UTF-8?q?C=C3=A9dric=20Le=20Goater?= ,
	xen-devel@lists.xenproject.org
Subject: [PATCH for-9.1 v5 11/14] memory: Add Error** argument to the global_dirty_log routines
Date: Wed, 20 Mar 2024 07:49:07 +0100
Message-ID: <20240320064911.545001-12-clg@redhat.com>
In-Reply-To: <20240320064911.545001-1-clg@redhat.com>
References: <20240320064911.545001-1-clg@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.7

Now that the log_global*() handlers take an Error** parameter and
return a bool, do the same for memory_global_dirty_log_start() and
memory_global_dirty_log_stop(). The error is reported in the callers
for now and it will be propagated in the call stack in the next
changes.

To be noted a functional change in ram_init_bitmaps(), if the dirty
pages logger fails to start, there is no need to synchronize the dirty
pages bitmaps. colo_incoming_start_dirty_log() could be modified in a
similar way.

Cc: Stefano Stabellini 
Cc: Anthony Perard 
Cc: Paul Durrant 
Cc: "Michael S. Tsirkin" 
Cc: Paolo Bonzini 
Cc: David Hildenbrand 
Cc: Hyman Huang 
Signed-off-by: Cédric Le Goater 
---

 Changes in v5:

 - Removed Yong Huang's R-b 
 - Made use of ram_bitmaps_destroy() in ram_init_bitmaps() to cleanup
   allocated bitmaps
 
 include/exec/memory.h |  5 ++++-
 hw/i386/xen/xen-hvm.c |  2 +-
 migration/dirtyrate.c | 13 +++++++++++--
 migration/ram.c       | 23 +++++++++++++++++++++--
 system/memory.c       | 11 +++++------
 5 files changed, 42 insertions(+), 12 deletions(-)

diff --git a/include/exec/memory.h b/include/exec/memory.h
index 5555567bc4c9fdb53e8f63487f1400980275687d..c129ee6db7162504bd72d4cfc69b5affb2cd87e8 100644
--- a/include/exec/memory.h
+++ b/include/exec/memory.h
@@ -2570,8 +2570,11 @@ void memory_listener_unregister(MemoryListener *listener);
  * memory_global_dirty_log_start: begin dirty logging for all regions
  *
  * @flags: purpose of starting dirty log, migration or dirty rate
+ * @errp: pointer to Error*, to store an error if it happens.
+ *
+ * Return: true on success, else false setting @errp with error.
  */
-void memory_global_dirty_log_start(unsigned int flags);
+bool memory_global_dirty_log_start(unsigned int flags, Error **errp);
 
 /**
  * memory_global_dirty_log_stop: end dirty logging for all regions
diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
index f6e9a1bc86491783077b5cb5aafdb19ab294e392..006d219ad52d739cc406ad5f8082ca82c16c61cc 100644
--- a/hw/i386/xen/xen-hvm.c
+++ b/hw/i386/xen/xen-hvm.c
@@ -669,7 +669,7 @@ void xen_hvm_modified_memory(ram_addr_t start, ram_addr_t length)
 void qmp_xen_set_global_dirty_log(bool enable, Error **errp)
 {
     if (enable) {
-        memory_global_dirty_log_start(GLOBAL_DIRTY_MIGRATION);
+        memory_global_dirty_log_start(GLOBAL_DIRTY_MIGRATION, errp);
     } else {
         memory_global_dirty_log_stop(GLOBAL_DIRTY_MIGRATION);
     }
diff --git a/migration/dirtyrate.c b/migration/dirtyrate.c
index 1d2e85746fb7b10eb7f149976970f9a92125af8a..d02d70b7b4b86a29d4d5540ded416543536d8f98 100644
--- a/migration/dirtyrate.c
+++ b/migration/dirtyrate.c
@@ -90,9 +90,15 @@ static int64_t do_calculate_dirtyrate(DirtyPageRecord dirty_pages,
 
 void global_dirty_log_change(unsigned int flag, bool start)
 {
+    Error *local_err = NULL;
+    bool ret;
+
     bql_lock();
     if (start) {
-        memory_global_dirty_log_start(flag);
+        ret = memory_global_dirty_log_start(flag, &local_err);
+        if (!ret) {
+            error_report_err(local_err);
+        }
     } else {
         memory_global_dirty_log_stop(flag);
     }
@@ -608,9 +614,12 @@ static void calculate_dirtyrate_dirty_bitmap(struct DirtyRateConfig config)
 {
     int64_t start_time;
     DirtyPageRecord dirty_pages;
+    Error *local_err = NULL;
 
     bql_lock();
-    memory_global_dirty_log_start(GLOBAL_DIRTY_DIRTY_RATE);
+    if (!memory_global_dirty_log_start(GLOBAL_DIRTY_DIRTY_RATE, &local_err)) {
+        error_report_err(local_err);
+    }
 
     /*
      * 1'round of log sync may return all 1 bits with
diff --git a/migration/ram.c b/migration/ram.c
index f0bd71438a4f7212118593b51648b645737933d4..bade3e9281ae839578033524b800dcf3c6f486dc 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -2862,18 +2862,32 @@ static void migration_bitmap_clear_discarded_pages(RAMState *rs)
 
 static void ram_init_bitmaps(RAMState *rs)
 {
+    Error *local_err = NULL;
+    bool ret = true;
+
     qemu_mutex_lock_ramlist();
 
     WITH_RCU_READ_LOCK_GUARD() {
         ram_list_init_bitmaps();
         /* We don't use dirty log with background snapshots */
         if (!migrate_background_snapshot()) {
-            memory_global_dirty_log_start(GLOBAL_DIRTY_MIGRATION);
+            ret = memory_global_dirty_log_start(GLOBAL_DIRTY_MIGRATION,
+                                                &local_err);
+            if (!ret) {
+                error_report_err(local_err);
+                goto out_unlock;
+            }
             migration_bitmap_sync_precopy(rs, false);
         }
     }
+out_unlock:
     qemu_mutex_unlock_ramlist();
 
+    if (!ret) {
+        ram_bitmaps_destroy();
+        return;
+    }
+
     /*
      * After an eventual first bitmap sync, fixup the initial bitmap
      * containing all 1s to exclude any discarded pages from migration.
@@ -3665,6 +3679,8 @@ int colo_init_ram_cache(void)
 void colo_incoming_start_dirty_log(void)
 {
     RAMBlock *block = NULL;
+    Error *local_err = NULL;
+
     /* For memory_global_dirty_log_start below. */
     bql_lock();
     qemu_mutex_lock_ramlist();
@@ -3676,7 +3692,10 @@ void colo_incoming_start_dirty_log(void)
             /* Discard this dirty bitmap record */
             bitmap_zero(block->bmap, block->max_length >> TARGET_PAGE_BITS);
         }
-        memory_global_dirty_log_start(GLOBAL_DIRTY_MIGRATION);
+        if (!memory_global_dirty_log_start(GLOBAL_DIRTY_MIGRATION,
+                                           &local_err)) {
+            error_report_err(local_err);
+        }
     }
     ram_state->migration_dirty_pages = 0;
     qemu_mutex_unlock_ramlist();
diff --git a/system/memory.c b/system/memory.c
index ca4d91484fb3d06f4b902486fea49dba86dc141b..d7ca1de994f6c3d08820eae4f0b1922db0030831 100644
--- a/system/memory.c
+++ b/system/memory.c
@@ -2937,10 +2937,9 @@ err:
     return false;
 }
 
-void memory_global_dirty_log_start(unsigned int flags)
+bool memory_global_dirty_log_start(unsigned int flags, Error **errp)
 {
     unsigned int old_flags;
-    Error *local_err = NULL;
 
     assert(flags && !(flags & (~GLOBAL_DIRTY_MASK)));
 
@@ -2952,7 +2951,7 @@ void memory_global_dirty_log_start(unsigned int flags)
 
     flags &= ~global_dirty_tracking;
     if (!flags) {
-        return;
+        return true;
     }
 
     old_flags = global_dirty_tracking;
@@ -2960,17 +2959,17 @@ void memory_global_dirty_log_start(unsigned int flags)
     trace_global_dirty_changed(global_dirty_tracking);
 
     if (!old_flags) {
-        if (!memory_global_dirty_log_do_start(&local_err)) {
+        if (!memory_global_dirty_log_do_start(errp)) {
             global_dirty_tracking &= ~flags;
             trace_global_dirty_changed(global_dirty_tracking);
-            error_report_err(local_err);
-            return;
+            return false;
         }
 
         memory_region_transaction_begin();
         memory_region_update_pending = true;
         memory_region_transaction_commit();
     }
+    return true;
 }
 
 static void memory_global_dirty_log_do_stop(unsigned int flags)
-- 
2.44.0



From xen-devel-bounces@lists.xenproject.org Wed Mar 20 07:03:25 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 07:03:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695724.1085702 (Exim 4.92)
	(envelope-from )
	id 1rmpyl-0004h7-Jr; Wed, 20 Mar 2024 07:03:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695724.1085702; Wed, 20 Mar 2024 07:03:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmpyl-0004h0-FT; Wed, 20 Mar 2024 07:03:15 +0000
Received: by outflank-mailman (input) for mailman id 695724;
 Wed, 20 Mar 2024 07:03:14 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmpyk-0004gn-N7; Wed, 20 Mar 2024 07:03:14 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmpyk-0007jX-Ku; Wed, 20 Mar 2024 07:03:14 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmpyk-0005X7-BG; Wed, 20 Mar 2024 07:03:14 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rmpyk-0006Xq-Ao; Wed, 20 Mar 2024 07:03:14 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=lWsD9djDuMs8c2mqV3q2abiRfYS5EXQO7Ck9Bgwf3u0=; b=udfdkIAp1wwQomVQ5D1HiL2tQw
	AzViyjEfkObX9vRJ9Pbj+GV2lvNY1Iq2VSRw1C/3rJOMfDXDkXn2wzbKS09qhJGtIeGktrypLRKCc
	gNisryxpVlxsNn8TEO0//r/GJOUD891TMpaeTRnsgdB0nZ5TaAqLvw2SSJkiyXeGsSxM=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 185099: tolerable trouble: fail/pass/starved - PUSHED
X-Osstest-Failures:
    xen-unstable:test-amd64-i386-xl-qemut-debianhvm-i386-xsm:debian-hvm-install:fail:heisenbug
    xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:windows-install:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-i386-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl:hosts-allocate:starved:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit2:hosts-allocate:starved:nonblocking
    xen-unstable:test-arm64-arm64-xl-xsm:hosts-allocate:starved:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-xsm:hosts-allocate:starved:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit1:hosts-allocate:starved:nonblocking
    xen-unstable:test-arm64-arm64-xl-vhd:hosts-allocate:starved:nonblocking
    xen-unstable:test-arm64-arm64-xl-thunderx:hosts-allocate:starved:nonblocking
X-Osstest-Versions-This:
    xen=d2276b86e5eb8dd2617d917f7b49cdd1f29ac299
X-Osstest-Versions-That:
    xen=d638e304f13a5ef7d125de5ace5f7828a7b25bac
From: osstest service owner 
Date: Wed, 20 Mar 2024 07:03:14 +0000

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

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 185104-retest

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt     16 saverestore-support-check    fail  like 185072
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop            fail like 185072
 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop             fail like 185072
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop            fail like 185072
 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop             fail like 185072
 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop             fail like 185072
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop            fail like 185072
 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check   fail like 185072
 test-armhf-armhf-libvirt-raw 15 saverestore-support-check    fail  like 185072
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 185072
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop             fail like 185072
 test-amd64-amd64-xl-qemuu-win7-amd64 12 windows-install       fail like 185072
 test-amd64-amd64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     15 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      15 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  15 migrate-support-check        fail   never pass
 test-amd64-i386-xl-pvshim    14 guest-start                  fail   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-armhf-armhf-xl-rtds     15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 15 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-check    fail  never pass
 test-armhf-armhf-libvirt     15 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-raw 14 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-raw 15 saverestore-support-check    fail   never pass
 test-amd64-i386-libvirt-raw  14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      15 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-qcow2 14 migrate-support-check        fail never pass
 test-armhf-armhf-libvirt-raw 14 migrate-support-check        fail   never pass
 test-arm64-arm64-xl           3 hosts-allocate               starved  n/a
 test-arm64-arm64-xl-credit2   3 hosts-allocate               starved  n/a
 test-arm64-arm64-xl-xsm       3 hosts-allocate               starved  n/a
 test-arm64-arm64-libvirt-xsm  3 hosts-allocate               starved  n/a
 test-arm64-arm64-xl-credit1   3 hosts-allocate               starved  n/a
 test-arm64-arm64-xl-vhd       3 hosts-allocate               starved  n/a
 test-arm64-arm64-xl-thunderx  3 hosts-allocate               starved  n/a

version targeted for testing:
 xen                  d2276b86e5eb8dd2617d917f7b49cdd1f29ac299
baseline version:
 xen                  d638e304f13a5ef7d125de5ace5f7828a7b25bac

Last test of basis   185072  2024-03-18 01:54:35 Z    2 days
Failing since        185083  2024-03-18 16:39:27 Z    1 days    2 attempts
Testing same since   185099  2024-03-19 17:55:12 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Alejandro Vallejo 
  Andrew Cooper 
  Federico Serafini 
  George Dunlap 
  Jan Beulich 
  Juergen Gross 
  Julien Grall 
  Kevin Tian 
  Marek Marczykowski-Górecki 
  Michal Orzel 
  Nicola Vetrini 
  Stefano Stabellini 
  Vaishali Thakkar 
  Wei Liu 

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          starved 
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  fail    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 starved 
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      starved 
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-i386-examine-bios                                 pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  starved 
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  starved 
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-armhf-armhf-libvirt-qcow2                               pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-libvirt-raw                                  pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 starved 
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-i386-examine-uefi                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-arm64-arm64-xl-vhd                                      starved 
 test-armhf-armhf-xl-vhd                                      pass    
 test-amd64-i386-xl-vhd                                       pass    


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

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

Explanation of these 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
   d638e304f1..d2276b86e5  d2276b86e5eb8dd2617d917f7b49cdd1f29ac299 -> master


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 07:05:51 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 07:05:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695729.1085717 (Exim 4.92)
	(envelope-from )
	id 1rmq1G-0005KJ-2f; Wed, 20 Mar 2024 07:05:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695729.1085717; Wed, 20 Mar 2024 07:05:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmq1F-0005KC-UH; Wed, 20 Mar 2024 07:05:49 +0000
Received: by outflank-mailman (input) for mailman id 695729;
 Wed, 20 Mar 2024 07:05:48 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmq1E-0005Je-9Z
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 07:05:48 +0000
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com
 [2a00:1450:4864:20::52d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 44671512-e688-11ee-a1ee-f123f15fe8a2;
 Wed, 20 Mar 2024 08:05:43 +0100 (CET)
Received: by mail-ed1-x52d.google.com with SMTP id
 4fb4d7f45d1cf-568a53d2ce0so7768316a12.0
 for ; Wed, 20 Mar 2024 00:05:43 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ww5-20020a170907084500b00a46b8712654sm3634763ejb.31.2024.03.20.00.05.42
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 20 Mar 2024 00:05:42 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 44671512-e688-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710918343; x=1711523143; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=ruc+ryFZffynHzmvVdV//wt6vGEmi9cPm/fD9CQRO3I=;
        b=Fs2VjMQjiJmQXapz/Ok+YuA6f6MM08Z9tET7Duhy6wynSrVYTj4e0DyfPctCUr11uH
         1k9Qsnsj0JGUys2L3xMtmGnonWQGkusRjZ06vw5DnIkLLcczirP5uBPv+fsuNDU5cEf7
         UTf31ROYkiR0KBI3wQ/GCB6koL+xERh5yaBgyR5nJ7Bk+4Kh9tLtORG2iXldCtsFntP/
         JShWyRJ3r1Nea9GWAe6ddkW2Pitq4Hck1qQv31EYBz/d0slSsamWnHacF78QJ/OdX/AG
         zF3FCIShmMbOSUl7hxUjFL04WN5g5guDan+mN6QLNZbHwNviAtS/AAdeqW9EMRleGMDB
         XQvQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710918343; x=1711523143;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=ruc+ryFZffynHzmvVdV//wt6vGEmi9cPm/fD9CQRO3I=;
        b=nNXItw8c2sseufUDALVM3PiS00GHKiMz2RQdXtTeT2OFWZHJjyHoDKkjpXPZKYrbfo
         8c1hZZr1IBcEkcKoKjP/DHTdY0P816537y+uNczdRetNbXMV1VKXQbrcxZ5TS79+xelB
         Pp5rYncaIKRgPhkWWJolH4cCp6lawT8S3DCXPMB2Pww+0cm3JDmb4qNbp7FvN8yjEHN/
         nB9kfBucbIeBm7GFbUz3qMtmBjmJuzflKDNw7eWQSu9iVy3eroVKFTZTiur4hLjOJ0x+
         oj5TPdQXwPCtEAVMA6u8X6gR5/AkGkl6lcxkgiY5/tY0U62MUjbYSCKNXPiTYd8ePDkt
         FVJA==
X-Forwarded-Encrypted: i=1; AJvYcCX9SFsDpulv/C8A/PZaNe+UIjGgRDiE6d8It1XTv367aR2K29JpP2jtGnAxXBIKv5XU6gy9EMUPQCwt7f7SPD9IhIC1rW9vFqCALDsl9xo=
X-Gm-Message-State: AOJu0YxwiKlr+p5enqUbMmL2uxAkbVMM+NRDtXAG1neTOBggNpODbwqo
	WPfw0vM7EWnTwSrzK62D48ofPCpfZr/nVFOTOs+UecBAeVJjiII3rJ1XBORsrQ==
X-Google-Smtp-Source: AGHT+IH44RAUDw/DNr6j92phBmAGabo7T94zvHcEdNbGdLcqBJ8VA3qWgds0pAskT4nAQn+54Y3g/A==
X-Received: by 2002:a17:906:e294:b0:a46:ee56:cef4 with SMTP id gg20-20020a170906e29400b00a46ee56cef4mr1081212ejb.76.1710918342916;
        Wed, 20 Mar 2024 00:05:42 -0700 (PDT)
Message-ID: 
Date: Wed, 20 Mar 2024 08:05:41 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/features: More AMD features
Content-Language: en-US
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Xen-devel 
References: <20240318181332.3817631-1-andrew.cooper3@citrix.com>
 
 <4aa2aced-d4dc-40d6-818b-8163657cd670@suse.com>
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 19.03.2024 18:14, Andrew Cooper wrote:
> On 19/03/2024 1:11 pm, Jan Beulich wrote:
>> On 19.03.2024 08:33, Jan Beulich wrote:
>>> On 18.03.2024 19:13, Andrew Cooper wrote:
>>>> I'm not sure about FSRSC as a name, but it definitely beats AMD's longhand
>>>> name of FAST_REP_SCASB.
>>> With FSRS already used, I guess that's the closest we can get to keep
>>> names for similar features similar.
>>>
>>>> --- a/tools/misc/xen-cpuid.c
>>>> +++ b/tools/misc/xen-cpuid.c
>>>> @@ -91,6 +91,7 @@ static const char *const str_e1c[32] =
>>>>      [24] = "perfctr-nb", /* [25] */
>>>>      [26] = "dbx",        [27] = "perftsc",
>>>>      [28] = "pcx-l2i",    [29] = "monitorx",
>>>> +    [30] = "dbext2",
>>>>  };
>>> AMD calls this AddrMaskExt (PM) or AdMskExtn (PPR). I can see where your
>>> different name choice is coming from, yet I still wonder whether we should
>>> try to stay closer where possible.
>> Having located the corresponding doc,
>> Reviewed-by: Jan Beulich 
>> with a slight preference to adjusted names for this one feature.
> 
> Neither are great.  How about "addr-msk-ext" ?

I'd be okay with that.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 07:14:41 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 07:14:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695733.1085727 (Exim 4.92)
	(envelope-from )
	id 1rmq9h-0007SZ-VQ; Wed, 20 Mar 2024 07:14:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695733.1085727; Wed, 20 Mar 2024 07:14:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmq9h-0007SS-PT; Wed, 20 Mar 2024 07:14:33 +0000
Received: by outflank-mailman (input) for mailman id 695733;
 Wed, 20 Mar 2024 07:14:32 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmq9g-0007SG-TN; Wed, 20 Mar 2024 07:14:32 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmq9g-0007zM-Nm; Wed, 20 Mar 2024 07:14:32 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmq9g-0005nC-AY; Wed, 20 Mar 2024 07:14:32 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rmq9g-0003Ru-9s; Wed, 20 Mar 2024 07:14:32 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=I/XbWLIAogTIShAPFHfOCemn3Thkzsa7Tq5a5GCQZMs=; b=J0AM8VN7nI//blSSrX5MXEAx+l
	58vqm3/UsJmNxRAB5/9eE07xMItxjV8fKyYJFE2Y+/Koj5W//+KCgaARIk9ytDXVUZm9G8hTtiisT
	qmjNWHlBT5zPgK+yeuVW/Ee4JXWz1M0op1u4GcG0Xs5KIkeDGA+VxQWOnogpePnAge0Q=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-5.4 test] 185095: regressions - FAIL
X-Osstest-Failures:
    linux-5.4:test-armhf-armhf-xl-credit1:guest-start.2:fail:regression
    linux-5.4:test-armhf-armhf-libvirt-qcow2:guest-start/debian.repeat:fail:heisenbug
    linux-5.4:test-amd64-i386-xl-qemut-debianhvm-i386-xsm:debian-hvm-install:fail:heisenbug
    linux-5.4:test-armhf-armhf-xl-credit1:guest-start:fail:heisenbug
    linux-5.4:test-armhf-armhf-xl-rtds:guest-start:fail:heisenbug
    linux-5.4:test-armhf-armhf-xl-vhd:guest-start/debian.repeat:fail:heisenbug
    linux-5.4:test-armhf-armhf-xl-multivcpu:guest-start/debian.repeat:fail:heisenbug
    linux-5.4:test-armhf-armhf-xl-credit2:guest-start:fail:heisenbug
    linux-5.4:test-armhf-armhf-xl-credit1:guest-start/debian.repeat:fail:heisenbug
    linux-5.4:test-armhf-armhf-xl-credit2:guest-start/debian.repeat:fail:heisenbug
    linux-5.4:test-armhf-armhf-xl-multivcpu:guest-start:fail:heisenbug
    linux-5.4:test-arm64-arm64-libvirt-raw:guest-start/debian.repeat:fail:heisenbug
    linux-5.4:test-armhf-armhf-libvirt-qcow2:guest-start:fail:heisenbug
    linux-5.4:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking
    linux-5.4:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking
    linux-5.4:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
    linux-5.4:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    linux-5.4:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    linux-5.4:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    linux-5.4:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    linux-5.4:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
    linux-5.4:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
    linux-5.4:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-5.4:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-5.4:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
    linux-5.4:test-amd64-i386-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-5.4:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    linux=84075826304f1a297838de6bcfd9bd84f566026e
X-Osstest-Versions-That:
    linux=3fec063b052e395f4920fbc59a8d0bb3c9666d76
From: osstest service owner 
Date: Wed, 20 Mar 2024 07:14:32 +0000

flight 185095 linux-5.4 real [real]
flight 185105 linux-5.4 real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/185095/
http://logs.test-lab.xenproject.org/osstest/logs/185105/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-credit1  19 guest-start.2            fail REGR. vs. 184921

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt-qcow2 17 guest-start/debian.repeat fail in 185058 pass in 185080
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail in 185058 pass in 185095
 test-armhf-armhf-xl-credit1  14 guest-start      fail in 185071 pass in 185095
 test-armhf-armhf-xl-rtds     14 guest-start      fail in 185071 pass in 185095
 test-armhf-armhf-xl-vhd 17 guest-start/debian.repeat fail in 185071 pass in 185095
 test-armhf-armhf-xl-multivcpu 18 guest-start/debian.repeat fail in 185080 pass in 185058
 test-armhf-armhf-xl-credit2  14 guest-start      fail in 185080 pass in 185095
 test-armhf-armhf-xl-credit1 18 guest-start/debian.repeat fail in 185080 pass in 185095
 test-armhf-armhf-xl-credit2  18 guest-start/debian.repeat  fail pass in 185071
 test-armhf-armhf-xl-multivcpu 14 guest-start               fail pass in 185080
 test-arm64-arm64-libvirt-raw 17 guest-start/debian.repeat  fail pass in 185080
 test-armhf-armhf-libvirt-qcow2 13 guest-start              fail pass in 185080

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-rtds 18 guest-start/debian.repeat fail in 185080 like 184921
 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail in 185080 like 184921
 test-armhf-armhf-xl-multivcpu 15 migrate-support-check fail in 185080 never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-check fail in 185080 never pass
 test-armhf-armhf-libvirt-qcow2 14 migrate-support-check fail in 185080 never pass
 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop             fail like 184921
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop            fail like 184921
 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop             fail like 184921
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop            fail like 184921
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop            fail like 184921
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop            fail like 184921
 test-armhf-armhf-libvirt-raw 15 saverestore-support-check    fail  like 184921
 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop             fail like 184921
 test-armhf-armhf-libvirt     16 saverestore-support-check    fail  like 184921
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop             fail like 184921
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184921
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass
 test-amd64-amd64-libvirt     15 migrate-support-check        fail   never pass
 test-amd64-i386-xl-pvshim    14 guest-start                  fail   never pass
 test-amd64-i386-libvirt      15 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          16 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  16 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass
 test-armhf-armhf-xl-credit2  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  16 saverestore-support-check    fail   never pass
 test-amd64-i386-libvirt-raw  14 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-raw 14 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-raw 15 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-vhd      14 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-vhd      15 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-raw 14 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt     15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      15 saverestore-support-check    fail   never pass

version targeted for testing:
 linux                84075826304f1a297838de6bcfd9bd84f566026e
baseline version:
 linux                3fec063b052e395f4920fbc59a8d0bb3c9666d76

Last test of basis   184921  2024-03-06 14:47:02 Z   13 days
Testing same since   185054  2024-03-15 19:18:15 Z    4 days    7 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Morton 
  Andy Shevchenko 
  Andy Shevchenko 
  Ansuel Smith 
  Arnd Bergmann 
  Bjorn Andersson 
  Bjorn Andersson 
  Chandan Kumar Rout  (A Contingent Worker at Intel)
  Cosmin Tanislav 
  David S. Miller 
  Dexuan Cui 
  Dmitry Torokhov 
  Dylan Hatch 
  Edward Adam Davis 
  Eric Dumazet 
  Florian Fainelli 
  Florian Westphal 
  Greg Kroah-Hartman 
  Haiyang Zhang 
  Harshit Mogalapalli 
  Hugo Villeneuve 
  Jakub Kicinski 
  Jan Kundrát 
  Jason Xing 
  Johan Hovold 
  Johannes Berg 
  John Efstathiades 
  Juhee Kang 
  Lena Wang 
  Lina Iyer 
  Linux Kernel Functional Testing 
  Maciej Fijalkowski 
  Magnus Karlsson 
  Marek Vasut 
  Mark Brown 
  Nico Pache 
  Oleg Nesterov 
  Oleksij Rempel 
  Pablo Neira Ayuso 
  Paolo Abeni 
  Rand Deeb 
  Richard Weinberger 
  Sasha Levin 
  Shachar Raindel 
  Shradha Gupta 
  Stephen Hemminger 
  Tony Nguyen 
  Werner Sembach 

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-i386-examine-bios                                 pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  fail    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  fail    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-armhf-armhf-libvirt-qcow2                               fail    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-arm64-arm64-libvirt-raw                                 fail    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-libvirt-raw                                  pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-i386-examine-uefi                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-arm64-arm64-xl-vhd                                      pass    
 test-armhf-armhf-xl-vhd                                      pass    
 test-amd64-i386-xl-vhd                                       pass    


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

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

Explanation of these 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 1433 lines long.)


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 07:15:58 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 07:15:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695738.1085735 (Exim 4.92)
	(envelope-from )
	id 1rmqB3-00082H-Ac; Wed, 20 Mar 2024 07:15:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695738.1085735; Wed, 20 Mar 2024 07:15:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmqB3-00082A-86; Wed, 20 Mar 2024 07:15:57 +0000
Received: by outflank-mailman (input) for mailman id 695738;
 Wed, 20 Mar 2024 07:15:56 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmqB2-00081u-A8
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 07:15:56 +0000
Received: from EUR02-AM0-obe.outbound.protection.outlook.com
 (mail-am0eur02olkn20800.outbound.protection.outlook.com
 [2a01:111:f403:2e06::800])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b0f87e7f-e689-11ee-afdd-a90da7624cb6;
 Wed, 20 Mar 2024 08:15:55 +0100 (CET)
Received: from DU0P192MB1700.EURP192.PROD.OUTLOOK.COM (2603:10a6:10:3bf::6) by
 DB9P192MB1803.EURP192.PROD.OUTLOOK.COM (2603:10a6:10:39a::11) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.7386.26; Wed, 20 Mar 2024 07:15:53 +0000
Received: from DU0P192MB1700.EURP192.PROD.OUTLOOK.COM
 ([fe80::181e:3628:177d:1cf9]) by DU0P192MB1700.EURP192.PROD.OUTLOOK.COM
 ([fe80::181e:3628:177d:1cf9%4]) with mapi id 15.20.7386.017; Wed, 20 Mar 2024
 07:15:53 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b0f87e7f-e689-11ee-afdd-a90da7624cb6
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=VeWUvx8IAv88gUAy2Gn/HkU+61H9Bnu2XWuF/9wd2+RX7A7DOtFxqsdpWqlcEk4ZzV4ENrK1NmDZ0gLt76j1/f6YQQFS7uV2GVhUli43rnRlIxVe38mdad3Znk/pL5E1dT1mveBXlEvCOHKvyKci9Q6WJvcAK5HOyDjmMzoAalpoyfeQb3vdK7ku10xixIyO9HyRyY058q0IqYeeRUIPvmJojYEnRkxZ73OTUd67K+k+JjbBFVkeeNVQ2FJtSpAuCCRbA140rqVwDi8GXVg62QvE9MA3AfsJWzifgHvQw6hJsaLRM3RTb/a4mpNxsLKNJjT6CC2ByFIjh57RYY6y9w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=k3JTWayvp2zlA02kxwKIhXk56tn7xdGc9Ij7EIftKEw=;
 b=NvgSNjupjgTZyHPQ7zubG8MZvqscCJGWQ+EYPRgMevESnap5tTQ1/H11yd7tEzZfqU618G50qNaJmMRTLi1QEgeL2/3focXf044zojAd0eg0thhQI/QSJiyaDz0Klop9Lbp/EOZCenALyGhEAzE6/Qok5XL2BbQZJeN/EhDfVWPajePl/yAcubRXMsYNQiJAnzuDmGLOepiW3FYe5iC8f8pT3LcANshQSvJGKbcrwfLDo2EdiVg2rCZnB4B683Pl36tjhb/0qIENEQnn8h8mn0p1NOMmj9A03EKc+sGiFffolQ1aKRGad6rHamjsOA87DcO5jSa7mjZ3XVcuFDO8wA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=k3JTWayvp2zlA02kxwKIhXk56tn7xdGc9Ij7EIftKEw=;
 b=PFaztCKy9uO6S8OZO0T5S59i/P60GbbMUrYbkeCFOIjNRWULWLu6Z/szmoYFJrJMj/p3LqN10cxaJ46Y5w4dCDPWtrXZhbri4KOXUSPmlzY/Jb1yEbFQ6CLSxai1u7X5OoB6YuCpmMg/HqzRzyXQz95PeXTBye3pCmx3z1BKC8TBkcheKcoTbX2v2Owxaq7g8AYBF4t+aMB8vruzD+Qx8TLhUOuOIjDVukIIAbPBD47ve+BGVRgi+gunxlN3rJIjMSJYvlj8Q3+/5lQ7Kg0Rc8Mt1gPUu4wVwc46Qti6SaTOjdH0kNyS0jbdkDTjponKxnyKjKoBmNq+5K7Xg22AXA==
From: =?UTF-8?q?Rafa=C3=ABl=20Kooi?= 
To: dragoon@waifu-technologies.moe,
	xen-devel@lists.xenproject.org
Subject: [XEN PATCH 0/1] tools/xenstore: Add missing XENCONSOLED_ARGS
Date: Wed, 20 Mar 2024 08:15:45 +0100
Message-ID:
 
X-Mailer: git-send-email 2.44.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-TMN: [9BxNsNyN9ENCBg4Qhf9Or4LXtetWuoha6zAsSETpHbKddzyVVntSTih2op4xpgg7]
X-ClientProxiedBy: FR4P281CA0075.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:ce::20) To DU0P192MB1700.EURP192.PROD.OUTLOOK.COM
 (2603:10a6:10:3bf::6)
X-Microsoft-Original-Message-ID:
 
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DU0P192MB1700:EE_|DB9P192MB1803:EE_
X-MS-Office365-Filtering-Correlation-Id: b6205030-9c99-456c-ee1a-08dc48ad93d3
X-MS-Exchange-SLBlob-MailProps:
	qdrM8TqeFBsDoBs/oZrXuoWrSByezst7rX08iiK853llmEJoS9YRreFq0n4imtr+opg6nQNU6Lkx1mf19wQDOYrJ9nRrSzI84Y1XnZS/rEW9QmPQk6HiaZbTMGozsPUqEDuzzTqQ3/TF7r3YQoesyZZ26+OSExf1c5SMyfKrPQ9E+iUIFokxjOxXanjdcvPVMBlQVFdJqEIlYGq0lHq84V4ptX2FO+ou5rxjD68xW/+0tTHCHKTOKsHPzcGjYSCZ6xSJ4vAgGYKxPS/3alJqAnFnJlRKCwYk+Z8qXAm01eW+RM7PK9bvMpmj6bZMhuW3hlDtzdaidBnuOa+5Q/o/OAEWFu1qOlJ9UKNhq+ibtsq+FSQEdOvpXGX4oo+s9e611HEya1rGxt6HUvaBj1wqnlsOykcAXkhOJdQFSZuIK71sZL9/pQbmmXco/26QK1lqtG/WWAsFhVH93SyUC3K1Bh0inkyeEcRGwOo7FME9c4TnGkiiJF+7eyslKv3oH+WlAmrId052o2ZINy7wLuwD/vg6Nl/Zn7Q1QcH+GJfgq+ryHyyEVrlvayCBfVh7+ZWd3DhIiWpkzcevUvILEcHO93WQJth9I2f/zZ/n4EZmZyD3X5mkhYcq0lRVgC/XEw5lkHfUhEgR4MdA10XrCR6BTQRR13WLF8xwFH0dML745GEA0ehvO5lUhh71Z/6sg/sy7+LXcUOtJs0y2/SPiz2nknXH5HjTNk0/aImJuofW6fJqGD4K+O0xXA143tFY/pMFgfOAvp3hRg9HqgNa6WdVhoIl5vCpNsiH
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	ZIb8U3fmmGA/OQf+LNw/LAJXKeEAw4N7v8gvwSX/dPBFB1TYw3o90YOjVac0ALmGs+amzxMxLHxKNnsufJYoiQqTpap2dlwhQMPAfFfY/+lCtn96W315gaqG2jIRQYSc0yYqvxMViGjV/ADC5OTWOJRKGqT9dp/aybkC/D6sbA4iBTbaGIO2HjkvIdG1KSsVsKmJhyVGUDZFXbTs7B5xNF2DaoLd06kqby0ym8UOopPNQ2M7Fw+tFYIciEcAuDwo0DVbub6FWhSFKmtTkrGQLu/JCTled04+eAZWdngEeQxspTN4T8RiweWFPLo2xEJt6H1+HgELlsnyU4vzxVKzJrSLCZ+rzPNC734LkytH0nwIt0tfdlNhMOGViStk+8lsjnrYQ4WpyPNa39kea5NCokBq2VoPdLnXugwSecpqeUCniaPALcQv2AhNkLP12/yQnfNcZj9BvdpvhaFBXfu2XHnoWHJBXSJFgsAybEhIC/We3l2y0zVo72wVEXe5NjeBaBtplQfRjRNGI1P4ZibeaWqTwZbbQo8g7s3Rx/EP1Cl8uW7vKd9sdqi2UjIHW3pc
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?T21nYis5ZVhtMms4WXRMTVdXUGNpbHk0ZW42OXFJVzcwWERNQkRpTUFMMXZP?=
 =?utf-8?B?OXBJaUwxbU1RN0o5OVkwTTEyTk5zT1lnbmhVM283b3owS0ZFcWZEZFFzcXow?=
 =?utf-8?B?bUJ0d214VmdwTFRiWC9vcDcwUnZUT3BEK1dRVHo1VlpBUDd6SERDcmtNQWNO?=
 =?utf-8?B?anJhL0RGTkxUenNuMXFhcG93bXNWRk13SldqRFRGVHZqRlBCc2JFWUlscXQ0?=
 =?utf-8?B?QjNHVFRhMlllWnlLZlBWZDlKRFhhcXZrZFk1T1ZMSFViRElxQXlxdGljUitt?=
 =?utf-8?B?bUJ0cFdtU2xEMldCbVdoNXQvb2VONE10SXlDNVRqZ2RZZ3NpM2tjYUZpZzN0?=
 =?utf-8?B?MyswM3BvbWtaMkprT0RqMjBpcFlGUXZKdzlua1lDZWdwWFBKRDYrZTZCN2hD?=
 =?utf-8?B?K0RTMmxvM3lINnk1RmZFSWFYNWg0cEpFNmQ0NDMxWDNPNy8vSzRzeXJuT2lC?=
 =?utf-8?B?bkZCdUErUVRLQ0dDZ0o5bDJkTHZnSjR3RDZSNUFWK2RvRFI5NEZoTkFJL2lG?=
 =?utf-8?B?TTJaTi91cGM0YmsvQ2Exajk1OURTam81dlRiQk9ZS1pHUDQ2b3pEdUg0Yjda?=
 =?utf-8?B?QXNna0NrbkZ6L2xXcVpFWUMvamxwSWNxWk5rYWF3L0lmQVZ6QzFmb0ZudjI3?=
 =?utf-8?B?ek52dndqRkdSNmNhdmczMDcxcERxc1NxdTdpRHVOV0EyemcxODViem1XSzlS?=
 =?utf-8?B?ZGFtUnhlY0NVWi9wbDFyeHljb3AyVHQ3ZHVGUE1Xa3oxdkVDWkRzSUZzVmNH?=
 =?utf-8?B?OEYvMVQ0ZGE4Y3NwZklNZitmOGErWGJqTTdBT2haMlJYeFNsQnNVYmw0cDh4?=
 =?utf-8?B?UEhvT3NvdnZsZjlRbHRWUW9wSFZwZGt4czZGdEZ3dUNLeGFOYjNJbzhwcTdp?=
 =?utf-8?B?R3IzeXVGeWg1NDdDWkZzQnhZVzJkdkVORngyUWRIT0NuaGJ5ZUNSVCtNcG83?=
 =?utf-8?B?bUdKdy9aSVc2MTZtMFFsWi95R1FVVWdya0Yzckx5RUgrVHg3allHbmEzTTMr?=
 =?utf-8?B?czBiVXhENk9Pc1dkbCs4RkNZcFJLRUo3R2pZOUVjcG9jUWZEMDZkYk9ldzBU?=
 =?utf-8?B?Z1Q3eGN4OW9aaXduRlhnRGVCVmFXZ1pVRGNKNUpWMGVhTkRQNDlIeWZ2QWN0?=
 =?utf-8?B?eTVWQVluZ054eThMamwraWZUbTAra04yYWJ5clRCYTVyMVZYcmtRb2QvVEgx?=
 =?utf-8?B?cTAzeWxJZWc3YnZ5aEk4VUl5dnVKbytnbndLRmtxN0orRXJxclNrNy83MDVn?=
 =?utf-8?B?b0plL2FKempIa1AxOG12ejFmNVptVGZ2WnM3VDdMbk5vWkxHQS9Vc2U0T0Fp?=
 =?utf-8?B?aVhsK1FwcXZxbW4zeHB5ZHFTaFRiN1ZXUHZudVF6dzl1cjRRVVEya2IyaDFr?=
 =?utf-8?B?dFNnVmNrcUV0cm5KZmhnb280VzZMdEovUWV5a2xRMDJRMUV0UWNsNENEYy82?=
 =?utf-8?B?UnpvZDE2cndjZEltU2tyeEREaEo4U0p5Z05nRnRBVjgxQTR2NHMvSTM2RVdj?=
 =?utf-8?B?djl0S0dOWnJ3a2pzQlU3RzIyTjF0K0JEbmtFMnBFdkdzaHRuNXIyQ3lUUFpU?=
 =?utf-8?B?a0RGdzZwY21xZTV4WU0zMnNibUdFNHpMSFZKdlgvUldxZmFPNzZqc1FMWUly?=
 =?utf-8?B?RjhTUFV2RXdrK28vRXBxOTZnMlFSZWlFUDZRWVJPRXR0byt3bC9HSjYxR1ov?=
 =?utf-8?B?Z0NPZG5TYlBjRmorNVAySCtKM2RWM3Q5WmxwOTROcTVDMmtSWUQvVDVCVi9n?=
 =?utf-8?Q?XTAXLslzURpyElWnf+v2b3sdbUccJM7EZimjMG1?=
X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-fb43a.templateTenant
X-MS-Exchange-CrossTenant-Network-Message-Id: b6205030-9c99-456c-ee1a-08dc48ad93d3
X-MS-Exchange-CrossTenant-AuthSource: DU0P192MB1700.EURP192.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Mar 2024 07:15:53.1788
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg:
	00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9P192MB1803

I noticed that the systemd services referenced the XENCONSOLED_ARGS
variable, but it was missing from xencommons.
I actually ran into this when experimenting with a Qubes patch where I
thought I needed to modify this variable. It turned out to not be the
case, but I figure it's good to include this for sake of completeness.

Rafaël Kooi (1):
  tools/xenstore: Add missing XENCONSOLED_ARGS variable

 tools/hotplug/Linux/init.d/sysconfig.xencommons.in | 6 ++++++
 1 file changed, 6 insertions(+)

-- 
2.44.0



From xen-devel-bounces@lists.xenproject.org Wed Mar 20 07:15:58 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 07:15:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695739.1085740 (Exim 4.92)
	(envelope-from )
	id 1rmqB3-00085W-JV; Wed, 20 Mar 2024 07:15:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695739.1085740; Wed, 20 Mar 2024 07:15:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmqB3-00084s-FY; Wed, 20 Mar 2024 07:15:57 +0000
Received: by outflank-mailman (input) for mailman id 695739;
 Wed, 20 Mar 2024 07:15:57 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmqB2-00081u-VT
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 07:15:56 +0000
Received: from EUR02-AM0-obe.outbound.protection.outlook.com
 (mail-am0eur02olkn20800.outbound.protection.outlook.com
 [2a01:111:f403:2e06::800])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b1807fb9-e689-11ee-afdd-a90da7624cb6;
 Wed, 20 Mar 2024 08:15:55 +0100 (CET)
Received: from DU0P192MB1700.EURP192.PROD.OUTLOOK.COM (2603:10a6:10:3bf::6) by
 DB9P192MB1803.EURP192.PROD.OUTLOOK.COM (2603:10a6:10:39a::11) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.7386.26; Wed, 20 Mar 2024 07:15:54 +0000
Received: from DU0P192MB1700.EURP192.PROD.OUTLOOK.COM
 ([fe80::181e:3628:177d:1cf9]) by DU0P192MB1700.EURP192.PROD.OUTLOOK.COM
 ([fe80::181e:3628:177d:1cf9%4]) with mapi id 15.20.7386.017; Wed, 20 Mar 2024
 07:15:53 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b1807fb9-e689-11ee-afdd-a90da7624cb6
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=Bhg9Pt+9bdQHsV3sGqzpeuIMX/S0dQ2XrM227/aMPGOkfAyoABqzegmkuuSlrB0bTFKknTm2/85bpvRe3BSCHMwfh/ULZlBc3vid1+mX2PYvsovbkG0W5ddAyQYP7OiF6r1X6x5x+NFnadBJDB0EB5d+Q52ZOVMY9F+KVTi7Up3cQB+o5CyZt1Iw5fBOOwZp+WXne1TlsJSDaETwDvcA7s9zPAkH08EcMZ4Gl9JBwIqI0gEfcjo/nI12ZJ9UZbtX1gY9JmuWC2kpbVF1ZPfpoHPlzfkONExmwM99+CoVB4L/9reESGex70ghJ9InF3jlUT0gmm3kjOjF1d6VYKFczg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=L09xaIyDfPc1imD82wYwTmT8UcsJA4judxkiTTMaxjA=;
 b=K6TC/DYJw8CXznvYKMInlHlSYshBAmrYn3/Eo6YvLHGhf+wB/YNHvfTBqM8wVxoPhQQHB29SUuYRZ4Cr6fN5BFc1oaQ4ZY1jwiDYJT936klgusScmKoXV9kiBTF+VeQ+SnM6Pku56YZEqoASlAlBYE9WjKVx2yX3Kxbi9M8st1XBIO/iy+Fu26kaA0UCi8/EGU79wsk6Drsdr3aSSDBEmq0YTk1TU2jbT2nESLejn6Jnb+Nx8nGmW//tT0whyUgW9AeeHdlZ5JJjkLYo/EoHvyfXXJPl2G6+McYdclMUMANzUkxIDRgVwfBUV6LQs4qDSoSFjDDs9SeJ0MmhoaEEqA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=L09xaIyDfPc1imD82wYwTmT8UcsJA4judxkiTTMaxjA=;
 b=tgs9PvBYhXYILLNPfeyeCsKbRKIPbsppfu8HDKvqBpkqlWDeDoI8i4WS1rM3tatIc3uedo3DsTdAQt8s4rU6iIo0p34/++KKsddVbh0o2kDkt4YcSkvDByegH9ekbB+/A3Rov6TaEeSkSODEo2tWewSRd63Fwk3Z4IQoW824ZFMKF5DDoIk8VPVvSYcXChRst/a+7jTtklp0gnSLZkXrZfpSnchSsQCRUw/ykeca1AbGeLhuGlNvTz3jAKu4KL7X7yEezpm6pqFArOvZyV+Ux9rIWhsobjGRCc4ydEs8JdVEBHbqoW0dd0PYPhV5AxOhxctaUPCzkmn1IgjfoClMng==
From: =?UTF-8?q?Rafa=C3=ABl=20Kooi?= 
To: dragoon@waifu-technologies.moe,
	xen-devel@lists.xenproject.org
Subject: [XEN PATCH 1/1] tools/xenstore: Add missing XENCONSOLED_ARGS variable
Date: Wed, 20 Mar 2024 08:15:46 +0100
Message-ID:
 
X-Mailer: git-send-email 2.44.0
In-Reply-To: 
References: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-TMN: [y1Gw2ZI1CKmIfyxqXY5TDSGUuH5GL87D5lK7PFIyq/4K3j93zwONTfqZ652w/eq5]
X-ClientProxiedBy: FR4P281CA0075.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:ce::20) To DU0P192MB1700.EURP192.PROD.OUTLOOK.COM
 (2603:10a6:10:3bf::6)
X-Microsoft-Original-Message-ID:
 <4b50f894496298b8e1058641e45f339ae3cb513d.1710892585.git.rafael_andreas@hotmail.com>
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DU0P192MB1700:EE_|DB9P192MB1803:EE_
X-MS-Office365-Filtering-Correlation-Id: 15d0d9ae-6068-404b-c73b-08dc48ad944c
X-MS-Exchange-SLBlob-MailProps:
	qdrM8TqeFBsDoBs/oZrXuoWrSByezst704aY3uOTeGkffot19l2ErGRPgK4SoMGmvilXCA0kfdrEZc4+d5rHQ4ZH7xKgCErg3Fd3Zp0wGxyGhqL4RUmc8hem9jt8l/tbb0ttfUh61FtByQAn/rPoKsJjDYyuaEJRkFONJ4HUCtD7XCg966NofB282V7Eb4Ob7yLyxwFuz2sPpe6/taSarRM9Aa+TSHS8KW1IcyDzBuPUt7jXc6/lfG2h4OfyjjT9UVAkV0uiczZ2AqTpr0iiXnKJb4x5kuNcyDvt/EGad+dofwPGMa+EBdWcmIwfPP2VUX4lnHwyKi36CHufUZVdZwTLak1WU2xVQ65Rwc4+0oOSWDeeuEwqi9cuduEVqgBbTHel//Dg0f8AOYg7aGuHAnYu189d6dTu71PZgHzQAY862UfUNCvO4qwJRsNk+84GfOxSOJ03akysaXnt7Y+WKVQxlpNFDT6XknQSv98rEoGZOs3Fg86JDWTwyCNnMQC3wOKTIsv4OLWY+vbUjJSK9P8IG5g+qvDJT1aZDt/Nnl9FMduiCKAowJ2PDqby3H4i2WADnaSAheKAH2v6jg8v/GDGZfb9g/39KiTDlZ9adXv4K7DSbvGrZyxnOlphyxKu9KliGHISadZC4gUtGyOLGhEHvL/Ml2axNW85YnI9VMXFT6YDAEGI1rllthlCwucvZr6b7Gf4xlkB36y3WTKq6Ry4OAxBkWhl1k9xZRd6SEzLNOBV8vaq8NILcSbs3byyRJvdCm5fP/saop7sLuuxPHvxM5FV6354
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	j+UEt0Z/15xzlS1jGJhOLg+dWRkkRgwBipqx92z9Usbr2W4byJweYjz+3YggODSv7C5lOkwTih7skP+6LBD+W0fCbXoE51Zg/qhsucH8FJ+4JdIMnOw+ZJxcn9P8fXKyngnoGI90lTUsa34j6eQWCoyiuhvNTHwrH6h3OK3sZvjo+768HTo11WbzT4ltShq7vbIObnvpRLvCp7mEXh7PEcSUggGdExN3wrdcl6rcHa/1Gk/EI/RPxnfMOcA9uYrezFC3LEEGxIUP1Cv6WqUq+dssO27q4A3kxH0CtV5OYqSqnL7qPI3UZ+3si1umMoek+zEsfh13Et4WfXX7TuS9WoQrw1n+UEUPFG9YGuNqoKlxqQCc7AarHBqeHSz+r2vQEItdDy19xVH/AJMaDRV3iRnjSJBTJOr2LAlknrydlT8nm/DdtLvN5pkHWToduB2qI/9y2ZO53fLHGyl4qS5vGZBsirs86Y7ziSaXftzKtrJI2Qp90YjKYsKBcQ3SYufucCCTZcDO9ODKkiyajrE5mn9kjAdvpxxbtoUJ9hXXI7jMtEO5NdSId9BQJUWn1mW3
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?MzN6bnNTLytYNWJtN3RMLzU4blJHdW5DQTlmWkJ5UFRpeXFBdjZkTWhFekJS?=
 =?utf-8?B?V3dJTEZZTUZYMlVQUGhYQmFYNFk3QXBCTlhaNU9UVnpmV3VPbll0TUFSblR1?=
 =?utf-8?B?V25aVXc4RlFTZ3VVSklVRXo2TkwyV2JVUXQyYVg5dHdzU1YrcklWMUZ5Rlps?=
 =?utf-8?B?VVc0S1RYMUxHL1prSkpjcVJqNmRyY01KSEphMjdubFUyTUpSMGI5MlI1UkFh?=
 =?utf-8?B?L0JpM0lPRVo1ZG1seFRIRWhCSVpvMDlPaldaRkp6ZEVnTndhOXEvVUVXUFU0?=
 =?utf-8?B?bHZ0Q1NQQU5pMUVVWkVINFVuanM2allvdmdiY1VJN3ViYmpxSEFxRDl3Vkw4?=
 =?utf-8?B?b1kyMDFtQ1BSWlA0NVE3c205cEtnTmFLRTgwQzR2dUV5MHQvdUpWTE1IU1Fp?=
 =?utf-8?B?VkJWL2tVNXVHd1VESVNLYklDNjc4M0tHd2JlV0xtdWpPVjEreTQydStiQVZs?=
 =?utf-8?B?QlBhQWFjWWkvYXpuT1FmRkMxTE5IM2ZVR3EzYWE5ZzhMNzJRckczZ1VpcGpu?=
 =?utf-8?B?Z0twQmdNeUdvY2pLVEY0d3BCWkc3ckI1d1N0V2xxRldFSUhieTZaYkF2Y1B0?=
 =?utf-8?B?QkpTbEg0K0VDWC9uVTJ4Q1VoUnhidm9rVzExdDF4K3grRnNvSHEwN1BzYnhX?=
 =?utf-8?B?TzV2ZnJaQ0QwZVZoMWc3d2wzTkc5cjNFTFJKOVJ0R0FxLzIwcXdQUFdRamtP?=
 =?utf-8?B?dTJXOWFQNjgvTllwWVdRa2VjVTh0emdjWXEwQ3U3c1Qrd2hXcGNaUWtodC9j?=
 =?utf-8?B?bUoxOUNFekVFbG1CYkZVZXZSbWxhYmF6QWFDQXpMcnlrVlNHR2d5YWx6NTNk?=
 =?utf-8?B?aS9YallNZS9uaFNSQjBvQTNMNllUVFpyVmptVTNvQTVjOUdkYnh6dW1aNmlB?=
 =?utf-8?B?enRmZnZpS01DdzI4UVFacFBvSWdrSTJuSkMyb3cyQkRuWHZPTGlOOEtFbVR0?=
 =?utf-8?B?NEZEMzV4NEd4QURZTHJLYWV1a2d3c1FGUHc2Z1ZsdWMvenBVRWdMTTVId3F2?=
 =?utf-8?B?ZjBkdlZmV3RWT1NYL1lLaWg0d0VDREcyWDFEbjZyczdUQ3BONkdtWklpN3lK?=
 =?utf-8?B?Qmk0UVhDREd5Y0NrQURUVWRIQWtPd0xlRnZ4MFkwQXB2d3VRczBsTVlaMFI1?=
 =?utf-8?B?MlN1ZFRNMEt5bWtSTjdLd2dVRldxdjc0eGUxcUVKTzFtZ3RiSjdEVVFRdE5j?=
 =?utf-8?B?WXFHc0NxSk1QQWMwdkVtclo1bXo5Ukd0MTVXdzlhQnBKZWs3endMSWtqZWll?=
 =?utf-8?B?QklTMGgwc2RhbUlmQlBVMGpYQThVb3FKSW56ZytJZVlhM2tnM0U4SHBwL2dm?=
 =?utf-8?B?Rk0xTE9VRjJBZStocnNNKzViUHVwLysyRXhTMXhPNnpUeEN1WDk3SVJUYk5U?=
 =?utf-8?B?QUxyQnNlZXpBR1VpQVZ4ZExBQnBmZkNqVGpMRHdHVGozbkt5QTVITDBzclQz?=
 =?utf-8?B?SlF5L1lSbjRMNk54VDVqNzVSdEJ2azB3dGxtRHhUcU9pcFlNUE93OEhHcTVl?=
 =?utf-8?B?WjRjRE40OEFnMzI2U1kva1JtNlRoM0JFRDRRL2t5dHBpai83RFdWVm5kdVp3?=
 =?utf-8?B?Y2g5U3VYMG1kTklHOWl1ai8xMFY5ZUs4cytKQm1nYVcvK1FBUWFoV3Y5R3Rs?=
 =?utf-8?B?Y1ZTUDJrUTVZZTBQWHIxc2IwNDJnN2FZeENCczVPZUlGT25DL2Nma05oVTc4?=
 =?utf-8?B?dFBSL0ZKRlVPYnZHQ0swYk82eXBWT0wrYUhIZDIzRWM4ZUtxUGVZR3BGZnFs?=
 =?utf-8?Q?OixWXpx+8f9R+1j9cpq9LhFJJvJXaJUuNT4/7S2?=
X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-fb43a.templateTenant
X-MS-Exchange-CrossTenant-Network-Message-Id: 15d0d9ae-6068-404b-c73b-08dc48ad944c
X-MS-Exchange-CrossTenant-AuthSource: DU0P192MB1700.EURP192.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Mar 2024 07:15:53.9025
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg:
	00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9P192MB1803

The systemd xenconsoled.service uses the XENCONSOLED_ARGS variable, but
it was missing from the xencommons file.

Signed-off-by: Rafaël Kooi 
---
 tools/hotplug/Linux/init.d/sysconfig.xencommons.in | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/tools/hotplug/Linux/init.d/sysconfig.xencommons.in b/tools/hotplug/Linux/init.d/sysconfig.xencommons.in
index 1bdd830d8a..42104ecaa4 100644
--- a/tools/hotplug/Linux/init.d/sysconfig.xencommons.in
+++ b/tools/hotplug/Linux/init.d/sysconfig.xencommons.in
@@ -5,6 +5,12 @@
 # Log xenconsoled messages (cf xl dmesg)
 #XENCONSOLED_TRACE=[none|guest|hv|all]
 
+## Type: string
+## Default: ""
+#
+# Additional commandline arguments to start xenconsoled.
+XENCONSOLED_ARGS=
+
 ## Type: string
 ## Default: daemon
 #
-- 
2.44.0



From xen-devel-bounces@lists.xenproject.org Wed Mar 20 07:28:33 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 07:28:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695747.1085759 (Exim 4.92)
	(envelope-from )
	id 1rmqNA-0002YO-On; Wed, 20 Mar 2024 07:28:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695747.1085759; Wed, 20 Mar 2024 07:28:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmqNA-0002YH-Ky; Wed, 20 Mar 2024 07:28:28 +0000
Received: by outflank-mailman (input) for mailman id 695747;
 Wed, 20 Mar 2024 07:28:27 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmqN9-0002YB-5V
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 07:28:27 +0000
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com
 [2a00:1450:4864:20::62b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 70131dfc-e68b-11ee-afdd-a90da7624cb6;
 Wed, 20 Mar 2024 08:28:25 +0100 (CET)
Received: by mail-ej1-x62b.google.com with SMTP id
 a640c23a62f3a-a450bedffdfso779287566b.3
 for ; Wed, 20 Mar 2024 00:28:25 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 qx33-20020a170907b5a100b00a46baba1a0asm3481034ejc.100.2024.03.20.00.28.23
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 20 Mar 2024 00:28:24 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 70131dfc-e68b-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710919704; x=1711524504; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=s0LEgY1RjsJIakwBbbw3bdu6oVzf6ULLUGjZUk7F0xo=;
        b=c/KKEThM87WWKq3Z7Vija5Pxuz30MxqqmaZRUb6pJioPY/ZG4Tb3MeCB7Maeik1QX7
         X/yOwTY3En5TvghOW1sD7i8PkbC439m+OswSjtqq76Rxf1PWFmjLll6TdNrTSGqEvQyk
         /s1P51qzZXvBkQYt6WUHSRdVYevQwciaMLjRUXTP2XnHtXxoA3mtMLbur72RmFAL9t1N
         qyYVwlhNxY7pI8/Z9u90l78NSutAsYAyuIUPFgg95E9U/LIusPsIJ9//WZMVTg+lQqoj
         /Kgm0uqRRA7iQsfnJMhjBeRf8UMgk3FvduCZH0/N8fNStQE7B2m0w1fnGpfq4eINAwod
         d6Jw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710919704; x=1711524504;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=s0LEgY1RjsJIakwBbbw3bdu6oVzf6ULLUGjZUk7F0xo=;
        b=J/Px3L+NflLDzWJyYGwewRqm2j3vZmJEbruHshCeEM2wuL/dI82ijGDDTyliiYR//3
         exW36hpiPyG5nS7ahGSt6Qvd5hzlmk5CN1sjHj2A3NLUhGgcEdDMsiMgY5O/R+LyGer6
         KPgENlRqbbCe1uCdqzAJ93vr8J6uZZG5KCldeL75McZw6cEd4KTIfO9ot7BqJcbN5Q/f
         6xsfk6eJdBdcmXGWDOd169JSXXGD0ArgS7dhB0Ry7PgDbxTmHXJ2m4knurxWEHuZn0km
         tAkX7nuCVrSGSu6y/VQDWy2/EYux0If2EBiX71VH0y2YOqq0j40koZIHG7MJUzbJjxZG
         vSIw==
X-Forwarded-Encrypted: i=1; AJvYcCWm44Nsxiq/LUdVy+a8GFCnFHgdSQhHydU+hFkTdV5HvlPBLZpYNhwxmQHh7cEKV2Hlv+Xm6R4PdhaNAu39I8IoSHbt9IlLdyAvY3bq1ik=
X-Gm-Message-State: AOJu0Yx7V9dui1K6gjPgSW6G+RgAq5AjcluCfF83M2p8TCpKI1O2FLVP
	XePJxSQW2CRdHuah2FuDLaBY2GyxZ6JwRSgUEdNn0qvClQLmYNPvV+sSLjek+g==
X-Google-Smtp-Source: AGHT+IGAOVl6MYYeRG2wz/mmad70P4kBTBXEmWqrh64wZSCM40FdHOXcrbfu7CDsBnLkLzQOzzZlZg==
X-Received: by 2002:a17:906:c042:b0:a46:cf3e:c68f with SMTP id bm2-20020a170906c04200b00a46cf3ec68fmr3904267ejb.49.1710919704477;
        Wed, 20 Mar 2024 00:28:24 -0700 (PDT)
Message-ID: <1f65c061-1877-4c73-86f3-4a814f9a3e18@suse.com>
Date: Wed, 20 Mar 2024 08:28:23 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86: increase NMI timer frequency if necessary
Content-Language: en-US
To: Andrew Cooper 
Cc: Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 ,
 "xen-devel@lists.xenproject.org" 
References: 
 <61b8e8a6-ab9d-434d-88dc-9ea4a082375b@citrix.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <61b8e8a6-ab9d-434d-88dc-9ea4a082375b@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 19.03.2024 21:51, Andrew Cooper wrote:
> On 25/01/2024 4:55 pm, Jan Beulich wrote:
>> Since the performance counters used for the NMI watchdog count non-
>> halted cycles, they may count at a rate higher than cpu_khz.
> 
> Is this in theory, or observed in practice?

It's been over two months since doing the experiments, so I can only go
from memory, but my recollection is that I actually observed higher
rates, just not high enough (yet) for the watchdog (without this change)
to start malfunctioning.

> It is my understanding that perf counters count in P0 reference cycles,
> and not at the Turbo/CBS rate.
> 
>>  Thus the
>> watchdog tick may occur more frequently than invocations of the timer
>> if we don't account for the ratio between nominal and maximum CPU clock
>> speeds, which would be a problem in particular when "watchdog_timeout=1"
>> is in effect (for high enough ratios even larger timout values may pose
>> a problem).
>>
>> Leverage the so far display-only data we collect on newer Intel and AMD
>> CPUs. On older CPUs we just have to (continue to) hope that the default
>> frequency of 1 Hz is okay(-ish) to use.
>>
>> While adding the new variable, also move the (now adjacent) cpu_khz to
>> .data.ro_after_init.
>>
>> Signed-off-by: Jan Beulich 
>> ---
>> This renders the "log" in the function names somewhat stale, but I don't
>> think this strictly warrants renaming the functions right away.
> 
> I'm not comfortable with this change.  It's adding to a complicated
> timing problem, rather than simplifying it.

The actual change to the watchdog logic is minimal - a build-time constant
is replaced by a boot-time determined value.

> The real problem we've got is that the NMI handler is guessing at the
> timeout by counting NMIs, not by actually counting time.  There are
> several ways to fix this even with the current rendezvous logic.  When
> the NMI handler can actually say "if ( NOW() - last > timeout )", then
> the exact frequently of NMIs becomes far less important.

But that would come with its own downsides: The logic within the NMI
handler should be as simple as possible, involving as little as possible
other code. NOW(), for example, cannot really be used there without
first fiddling with the time rendezvous (to make sure an NMI hitting in
the middle of an update to the scaling values will know how to use
consistent data; that could e.g. be done by flip-flopping between two
instances of the data, with a "selector" always flipped last).

Jan


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 07:30:06 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 07:30:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695749.1085769 (Exim 4.92)
	(envelope-from )
	id 1rmqOj-0004CG-26; Wed, 20 Mar 2024 07:30:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695749.1085769; Wed, 20 Mar 2024 07:30:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmqOi-0004Bf-V5; Wed, 20 Mar 2024 07:30:04 +0000
Received: by outflank-mailman (input) for mailman id 695749;
 Wed, 20 Mar 2024 07:30:03 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmqOg-0003na-U0
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 07:30:03 +0000
Received: from EUR03-DBA-obe.outbound.protection.outlook.com
 (mail-dbaeur03olkn20801.outbound.protection.outlook.com
 [2a01:111:f403:2e0d::801])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a98e6809-e68b-11ee-afdd-a90da7624cb6;
 Wed, 20 Mar 2024 08:30:01 +0100 (CET)
Received: from DU0P192MB1700.EURP192.PROD.OUTLOOK.COM (2603:10a6:10:3bf::6) by
 DU0P192MB1844.EURP192.PROD.OUTLOOK.COM (2603:10a6:10:3b3::11) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.7386.31; Wed, 20 Mar 2024 07:30:00 +0000
Received: from DU0P192MB1700.EURP192.PROD.OUTLOOK.COM
 ([fe80::181e:3628:177d:1cf9]) by DU0P192MB1700.EURP192.PROD.OUTLOOK.COM
 ([fe80::181e:3628:177d:1cf9%4]) with mapi id 15.20.7386.017; Wed, 20 Mar 2024
 07:30:00 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a98e6809-e68b-11ee-afdd-a90da7624cb6
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=imYAOP8wLMA7v378eGHPL8P5DfZOkDRPQVWKRuUagiQTanuzzn1HIMjmij5WrISRchlZqVUiWn7usQECTQmwwnXVg+sRDjW3aUYoMoOWK+SMRl3Yy3BxUHnAl6amp0NCEz6ZaV+E8Fq5xTuRT3kvOw8ZsRCtAry1OfUvnzO51EkavEtB6tDWh5xxrnNOuT5q1fCshEADjKjpWYB5FGeuwaACheizrlbAKo3otiSqIhmaFam45HQsS95mOUg9GECYHw7Ks4e3O8cziYkLXtg3/uN1uAAhiYZln+icuthlcoNhtJiF2AHfOLf8wrYj7b5GFzy5EmT/vIJMuOvNs5m3FA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=OxLIUiM0054MdvrI8eeLLF2BMgfWdKU/mFub7eAj0wE=;
 b=A9n6izB/4D2wKW3ZS3X1vx0CrNBmaOarsOn3U3u7cwi1ODec7ZQylorLEZEctk03oQ3JBODaXdp/qqNekR35ZuQsDO2DpQ1h7XttcC8BTb3Ced5puwF3qUOaXcAVvI1cmRkGHGTQGs0lnP/uzSEeeoVGC0xXflp7fdzIe9IZm0n24DXcrmLdiK7oLh3O7Jii11hyt+z3UQiAA+ZwBKSBM3iEoEP66INMhdG2fIbeCAMniuCdXpudOA4ZSS9CZqLpK2dq1u+A0FYcX1ZbiBpp9nzPR4aS6B51smHBR208e2/mc1xlR3hsw24+W6MXdxxXIhUEBR4YN07jSKpqNc4NdQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=OxLIUiM0054MdvrI8eeLLF2BMgfWdKU/mFub7eAj0wE=;
 b=EeuqysqV3imK89N8ng1wdM38wqMBQ6qPz7EKAVjRlcjVetEQKhVQrXRFNRmsZ18gf9yUYP8cb01RKDMisB8xPDZjjTcLRCEXE9gR0GHGw2XIhNhh5ixnOhJw7x5AbAu4QAv1I6elaEsDCiGbUG2QcUqfEzw6hym3Fz39NksOrpPowf8oKAHly65fkJ/JzW9XI+93YX8DFBk/qZvOGjIjp2fa2MIKrog0XcVW6gXpqSq5GuzjKm/44r86GrCkJpFPImXIlwqExEDILOQ8RdCcj2r7G40n3GUHICfb8fReWrptgxyc4/51Moqlc7bPS3Xf8iKYU2/B6WdQyPQPXhZc0w==
Message-ID:
 
Date: Wed, 20 Mar 2024 08:29:58 +0100
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 0/1] tools/xenstore: Add missing XENCONSOLED_ARGS
To: xen-devel@lists.xenproject.org
References: 
Content-Language: en-US
Cc: Wei Liu , Anthony PERARD 
From: =?UTF-8?Q?Rafa=C3=ABl_Kooi?= 
Autocrypt: addr=rafael_andreas@hotmail.com; keydata=
 xjMEZHDtHhYJKwYBBAHaRw8BAQdA4C7O72UZHQbhHNm1BUkAM/7+KQKN3tupyuGVGyj2dIHN
 KVJhZmHDq2wgS29vaSA8cmFmYWVsX2FuZHJlYXNAaG90bWFpbC5jb20+wo8EExYIADcWIQTv
 ioHnE84MxV6adj/iFi3SALEToAUCZHDtHgUJA8JnAAIbAwQLCQgHBRUICQoLBRYCAwEAAAoJ
 EOIWLdIAsROgP80BAKeJdh3YQ5l3gxGp8R9wIvN9Ac3vsMfy8I4kZ6TXksLKAP9vLRV4G3yw
 z7/seKhWc27Jjl4uI/+lIWhWaWrUYZmjAM44BGRw7R8SCisGAQQBl1UBBQEBB0DE61lbAezY
 NhOlHgxdZ9V4klIhSajeU50O8wHIPQnCLgMBCAfCfgQYFggAJhYhBO+KgecTzgzFXpp2P+IW
 LdIAsROgBQJkcO0fBQkDwmcAAhsMAAoJEOIWLdIAsROghHgBANU4dj+WnuSaWemAHVkjERJg
 m0FQpmZzNI8hdolS3gYdAP9zGK65ilpHMDj4pGvfALabruZA4NPJYxSqeamHvOuhBA==
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-TMN: [bOaI1tFtjtIl8tumCIO7+pX+qdsA52Z/TDb9I9Xu2xbVf3Mzk6WEKCUSKeegnaXp]
X-ClientProxiedBy: LO4P265CA0253.GBRP265.PROD.OUTLOOK.COM
 (2603:10a6:600:37c::6) To DU0P192MB1700.EURP192.PROD.OUTLOOK.COM
 (2603:10a6:10:3bf::6)
X-Microsoft-Original-Message-ID:
 <27a2a7d3-647f-44dd-96b4-1771dd94d77f@hotmail.com>
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DU0P192MB1700:EE_|DU0P192MB1844:EE_
X-MS-Office365-Filtering-Correlation-Id: 1c406ff2-275d-4cf8-de07-08dc48af8cd8
X-MS-Exchange-SLBlob-MailProps:
	znQPCv1HvwVMHQwHL2Y6Z03kJoUnJnLRn98RWvgv4h4QAFNqzvOFEO1CBUDQU6PpQv0nVge7CA73tBsQyVcEiDFoIWv15xN/jnh607qoviTifikvLzmFd2WEpq3HOEfCjs1HOm6/T7ThP1tEeVPxCOyIleCnU9RlY4FSH5Q6U7xngxfMay22ATzpwY78xKxWrGjmDjNTjFbr4fmypG3lyNAUS1t35uTSkfZR5pKNP5rOJEG3ytan9XMLdXSmbzLDl4OVDeeB1WT7fABuicdOjVhWEFV42Xng98L3kl1O4p6DkNowbwqeKRB3BCmT/akEsfe58rJJkCiCkQCAOFbjPADXKhJ8ycA2TNyYQg9fa6LtcnntPV1tZ2nWewnw05Bj6QKm/+A2z6kZfq8abKqBvFsco/rERZf+wBwzXyUGHTgeZLkGpBtGqc9zzEW3Ee9Lsv77oqQ9qsMk6QnNjn4FgbEXs9FjIeLpOrVSFhyLW8N/Hgo6ARkBDXrv4v2hfqKvVhm7CQob56YMhrnIetixTofVywBCcZLHF/bENk25D8p0TQQMjCx6cWr+fv37PQzFLWrSpC23PwmBFJeO+aN7FZXAZ8hvzRpGtuJdvC2sWabr1EFmx2dokTaV0drKOQkuT2jSwl7KQwRXGIDwotIcgjHeo7YJxkufggTZguM59bq/iL1JmLVjhOt7p07Ux4i/DjnTXxpognlqHlHt9Z7vGupujCpJgWV5Z7PA5WCNVcNSjJCjRIKfj8Wy2RxZDb/RCRsPkdinD5Q=
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	D+u+k+yk2nMDmXxvePcE+pVrm0OBDbNWWDH567/G1QP+p/koruQZQqJKuLRJnvcKC9tIqi11qJ6D7+bJLw7yx7LNsWr6IIlrlRETo4itFbdeI0MiQP2Ql2pB9K6cLvtM6UE8SkO0pWjzGswD5HNbiAxJ88xIhoHHzaTf00xKUNAWsSl65YNGWUnGvS2iLXBLFpEFJe62Kuy5X3ABBhC1ImZMeq9rbA4SANZZMLkVaTJSWNEk9YgDWSfFQUJwbFgZmzSjC021+FwZ/vjXGB3XquPFFlbJjWJCk1+V0+CYQLWzfeP8UEA7Dr5atydjfKnVFEEEy01IpYlwLmPyZPPmG5tSnB20S0nxlZtSeQM1SNTBaImDChpyV+lJOPOAI02vsLsslym/FBAeAUBmfs4ICFWDjrEvX35ha7/kmwaM5LygqCt7jVZKSNzi3zYgebTNaLm/Tvmotr+1Q4sg0thBFKNh1IdcYu1KiQpQedh2rSADCJD/CUp90zMX+52NkhgAiegfkfpS13qi8cOsxvDwPnIZb4qVCBQL9FSa2ey8+QiY1Mc5BeEhnhQS1nmTDFC5
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?UEVDVktRajdFTzFhN05YeVJpZGt3UzR4STNyZ2ExVkxiT01Ba3NwWWd3NzNP?=
 =?utf-8?B?MmxCQ3BzelV3cDBwdHBFYkJyNWxMUkNjRUNsM0ROMlp3YWhuQjQvbkNNK1o5?=
 =?utf-8?B?MWV0TmtCdFRtRFRyM0hVN0pMdm5sZEVidUVZWERNOVJ4MGlwMVZMR2UrelF1?=
 =?utf-8?B?N1ZhbkNrZEpPby9HSzdEL1RZT0JXOWxTd3RHNWRHMXJkNGRWdHFEM0Zya25j?=
 =?utf-8?B?V28yYnp3WGNwSjZxNENCNjRveTVrd3d5dnc1U3JXTktqeUZPLzBqWEsrVWg4?=
 =?utf-8?B?UFllMTJsZUdrSFcyS1ZOVzdGTSt1M0d3ODQ0d0RaSDF3QjBkVHVJNmg4MER3?=
 =?utf-8?B?WXVXNFJ6eGZub2x1OUhOVk5JOE03Vkx5RDNYZXVrbXJVSUVIbmNiWDJmNzlr?=
 =?utf-8?B?K3ZTaEFEbzVxbUZEMUx0bW14WEsrcGp0V1A5NXhRY3dsSWJGOHRpeStzZlJM?=
 =?utf-8?B?Nzg1NEp4YkF0VFhoTlJsdFZESGNlajBneFIwZkFvR3JDYXdIUkZsdGFnQjVG?=
 =?utf-8?B?cGY0V0VTbGhteHhTMlNuQmJhV3ZuRmZYdEtKY2hRS2MvazFFODdQV3JacTJH?=
 =?utf-8?B?VHFINy9zZGVmT0p1TGZrVm9DcW5GQjJNdXdlOUNQWFk3R1gwZFdkODgycHNm?=
 =?utf-8?B?RHBXellOVmxJVmhKajRjTlV1ZHpiUytURUlNZm1wVTB2em8rNjUvbXJRaytt?=
 =?utf-8?B?MlZsTmVxTUVDM1ZKMVpYY2VLZUJOVUdtNW5pYldUZUpZRDVSWmtpUG9odjI4?=
 =?utf-8?B?WFl1UE1XQlc5Z04ydEtQdEsvMEQ0dUhDRVFBTVR1Y2NOT1pvZnNoNnIzUmxy?=
 =?utf-8?B?eTQ1bWw3R3A0WkJYYjNxT0FSZ2JndFJidy8rU3BYUkFsMTZCQStyVjdvL25i?=
 =?utf-8?B?b2htcW5ZSHByZ2p0T3BibFNJNnVlNTVWQnZFbXdkUmdCbVpLTnlaMXVSTE5z?=
 =?utf-8?B?RUdLZWRVakUzNWNCbkdIV2FsMW5UbmhDZUdlejk2a1doS3h0VUhrUDRFMFhI?=
 =?utf-8?B?TW4yVUFLdkU2dDh0b0ZrMk83Y3Z5b3BpQlRZeVN4MTU1Smc0OW5lREFzMTN5?=
 =?utf-8?B?SkFLQkRSN01oVy93cTg2UUNYZzZtSndsYS9rQXpBSVpRdjhYQ21OWk51M1NB?=
 =?utf-8?B?L2crN21WWGhzaUN6NmRqaGVXMXRucEdwckRJaTZCbjU2RDgrb3dQeldmZDVM?=
 =?utf-8?B?UW1pWEUrQ3N4aVdWUzVQeVFySHNxNlRvSHFQKzkreTFiN3ZkTTRpM0hZNmNn?=
 =?utf-8?B?aG9QRlAwOXRaa3Q1MDhOODBtdzFKOXBOcjJwNjh0THh0TXFEd0Mvd3plV1Z4?=
 =?utf-8?B?L25iRU1tUDRlUzNZakNaK2FUNjFZbWZLMGhwY2d6V3VXYS9mSGwwNElLZ2lw?=
 =?utf-8?B?WWMzVlBQMGxRTk1wRFdyRVFOY05BdGFPck5IRUZ4a1YzU2JFeGZiRTU5dW5W?=
 =?utf-8?B?TE9IYytxL1lIZnI4Nllia29ITEdQWGQrcVVwZDE3QXl1alp2bUc1UlQxQVJ4?=
 =?utf-8?B?WGRqdzFKR2g4NGU2aDRsd2ZRSHU3TWhXU2MyTVVrK0ZYVWp0NGxLY21pRWtI?=
 =?utf-8?B?R2RaanVzTzlKRmU4V3hCWWJDc1E4VnA3cmFyRXk5OUM4U21hWmJvQXpYbXhp?=
 =?utf-8?B?Z0ZKTG1udGdxWFlhSFp4UVlSVFhJUWFvcXlnM0VWVFh4bzM2V2o5aEd1WDUz?=
 =?utf-8?B?UkZxN0lOZTJHZXNVMUtEK2cxNkkyZlF5Q3ZVOU1IVUZLVGlyUmYxUFRqQmx2?=
 =?utf-8?Q?lvOEimrgcOUJqhs1Q1ZpJ39uJccGUIFJDAdQjSi?=
X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-fb43a.templateTenant
X-MS-Exchange-CrossTenant-Network-Message-Id: 1c406ff2-275d-4cf8-de07-08dc48af8cd8
X-MS-Exchange-CrossTenant-AuthSource: DU0P192MB1700.EURP192.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Mar 2024 07:30:00.3279
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg:
	00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0P192MB1844

Apologies, it looks like my test email ended up on the mailing list
regardless of my intentions. The title should have been:
Subject: [XEN PATCH 0/1] tools/xenstore: Add missing XENCONSOLED_ARGS variable to xencommons
And Wei Liu and Anthony Perard should've been CC'd.

I'll try to do it right next time.

Best regards,

Rafaël Kooi


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 07:30:23 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 07:30:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695751.1085779 (Exim 4.92)
	(envelope-from )
	id 1rmqP1-00050L-DN; Wed, 20 Mar 2024 07:30:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695751.1085779; Wed, 20 Mar 2024 07:30:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmqP1-00050E-9d; Wed, 20 Mar 2024 07:30:23 +0000
Received: by outflank-mailman (input) for mailman id 695751;
 Wed, 20 Mar 2024 07:30:21 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmqOz-0003na-ND
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 07:30:21 +0000
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com
 [2a00:1450:4864:20::52b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b4ef8c23-e68b-11ee-afdd-a90da7624cb6;
 Wed, 20 Mar 2024 08:30:21 +0100 (CET)
Received: by mail-ed1-x52b.google.com with SMTP id
 4fb4d7f45d1cf-56b0af675deso3224767a12.1
 for ; Wed, 20 Mar 2024 00:30:21 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 o3-20020aa7d3c3000000b00562d908daf4sm6522326edr.84.2024.03.20.00.30.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 20 Mar 2024 00:30:19 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b4ef8c23-e68b-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710919820; x=1711524620; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:cc:references
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=kfPNJaVNrRLUgq1G0xyXFXGJmVwgXHUj6PPli//ssF0=;
        b=FKoLRSyCGm/BdXa1T+38hw3diqgdeOpL0q7PwOLw4VeyIduv0sBdjH1i/Sg+c7b/GB
         JJMJCf4cuygec/jVK8vHYuzisExClUfRU/cnJa0+8fQMrQ0b/GyE1+zD/MWM+urd9BDH
         /yqaPQWhZ7bouDxbXJ7i2fSgGMLuqabxJeuQoycqjsTljP3l92rvqsP22qIyepT0bZbA
         gvptIMj053OEKWa6tyywQAJ+1G+I/xdn7IzlCEVe4KCxJHFeqO1bKhlscrNAuqJcschK
         9N4vxK6HN49I6aGHQqX53DW83E7GLdnfAN5ueKdc8skrBOF/BX4Z/NwVS7qgU8MYYoua
         32+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710919820; x=1711524620;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:cc:references
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=kfPNJaVNrRLUgq1G0xyXFXGJmVwgXHUj6PPli//ssF0=;
        b=creJNNj9xZKJD81Av7XgPy4JFrP9p8XNCRns3KdM/+Aheli8mLVvZE1QQtvaNqf8oY
         jfnLq8ZCYm1gvv9EKRvbO3S/HwqXQgcC08VZHBo1NCbPdkLYNDqlAAxDY+/NgHq9LCHj
         ifGWreWP9OCfsr5skyYUOinIqb3UfN8ql8JVAbDBSP9Q+tMYGRVijyp21IdWVd1mcXi5
         1zMHZiUm2zp1XA7iu+nMtSi3o0Zgf5fHgsnbQ2OebgFbzyNdhtNDnSAD9KbfeZWHHVWB
         9sxMbqpMAPG2m4CGLWfc8Y9yS8Y1LITqhKCcsiS6X2GxIQJYg2yNxJQ5/oy4yjH5382i
         lTMw==
X-Forwarded-Encrypted: i=1; AJvYcCVGwiFqRqFz6NOPzFuyIAnY8jibRcGGWzlUxJHDsuMn9aP+bvhCwCDsGGFZGq1VqbxU66bxbhtdgadhP0kPJF7vtC7+4GbfukbSBnbSw/0=
X-Gm-Message-State: AOJu0YyqJKsu4J/VuZH0zfzNWXvlA1WH0B1Go+VhQENxefKyhLgOKD7M
	790rhpXNhmRlYxpsyZMWrhsDs+QjHnjWxqy1zy6YvfkG4I/dK8T5nXWwHgBB6Q==
X-Google-Smtp-Source: AGHT+IHA9oLQQNfw4VCNq4/k5zzyN2AAeQPRvltWYQ/CghH8ATqqwsZccww7m8FsQ4x0pI59EviI+A==
X-Received: by 2002:a05:6402:3605:b0:56b:83ff:e044 with SMTP id el5-20020a056402360500b0056b83ffe044mr594699edb.1.1710919820154;
        Wed, 20 Mar 2024 00:30:20 -0700 (PDT)
Message-ID: <373304eb-ff38-411d-becf-99fc7c170ccc@suse.com>
Date: Wed, 20 Mar 2024 08:30:19 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 1/1] tools/xenstore: Add missing XENCONSOLED_ARGS
 variable
Content-Language: en-US
To: =?UTF-8?Q?Rafa=C3=ABl_Kooi?= 
References: 
 
Cc: dragoon@waifu-technologies.moe, xen-devel@lists.xenproject.org
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 20.03.2024 08:15, Rafaël Kooi wrote:
> The systemd xenconsoled.service uses the XENCONSOLED_ARGS variable, but
> it was missing from the xencommons file.

As to the title prefix: How does xenstore come into play here?

Jan


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 07:37:29 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 07:37:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695757.1085789 (Exim 4.92)
	(envelope-from )
	id 1rmqVn-0005qH-3r; Wed, 20 Mar 2024 07:37:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695757.1085789; Wed, 20 Mar 2024 07:37:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmqVm-0005qA-W2; Wed, 20 Mar 2024 07:37:22 +0000
Received: by outflank-mailman (input) for mailman id 695757;
 Wed, 20 Mar 2024 07:37:22 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmqVm-0005ox-1Y
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 07:37:22 +0000
Received: from EUR04-HE1-obe.outbound.protection.outlook.com
 (mail-he1eur04olkn2018.outbound.protection.outlook.com [40.92.73.18])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id aef4770a-e68c-11ee-afdd-a90da7624cb6;
 Wed, 20 Mar 2024 08:37:21 +0100 (CET)
Received: from DU0P192MB1700.EURP192.PROD.OUTLOOK.COM (2603:10a6:10:3bf::6) by
 AS2P192MB1984.EURP192.PROD.OUTLOOK.COM (2603:10a6:20b:557::10) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.7386.28; Wed, 20 Mar 2024 07:36:51 +0000
Received: from DU0P192MB1700.EURP192.PROD.OUTLOOK.COM
 ([fe80::181e:3628:177d:1cf9]) by DU0P192MB1700.EURP192.PROD.OUTLOOK.COM
 ([fe80::181e:3628:177d:1cf9%4]) with mapi id 15.20.7386.017; Wed, 20 Mar 2024
 07:36:51 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: aef4770a-e68c-11ee-afdd-a90da7624cb6
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=fFEIM7NB3Ts/iGIYCRwz3z8gJsHYom/Vow0MxUYhGaV2VekxS8ZGj/hBp/723GOQ7kO/+Bf9KiTFnaE7PpcsjSGlIvi9NHucCkn0UXa44jAyW0YbsCB79j2ezlfWepcPnAOosi5u1dTMJK8FQ0V0+uINp6lqjLFFUGEBHZMz0JLlGTBtI/2JBLNjEWC4OxIctIxjmkPUjviVV/r4OKFEoBlSlo7IlmK2x39Dt0NlO8Ze58AuN65pnjcX2AahUGr11DkKi0F1PDkpbUn4CeVTW2fAB5mtFefrOGRK2jY5JCIAlYE8vJzWdzJWu0pVUiB4jFEDqIGDe5wVBBoB7POxaw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=9cY7xZu6tKQkBnJEkMrnX9JbxrH/GT81vRAlOY9ec+E=;
 b=fIjyaT/+kEadzNt5lLiQOrTSemw0ADGcpCXNI1lUPlLqF8gVk9pkPXgg83m6D+UphvX366rHCX3kgX0+X2Dzc5EEhNJ/L6yDzU71n/wb5p73LlPlxoHDvhQRNUZQGootlhOkup2mCjt7supwvTyPPrOOAVBXArLvCTsgUPHHlyyA8LDEDcGSnlXj+Qu6O/LGlbcF6hhtNT0bzoF0Q1wi0xqZhl75c91fdrKvjZ7qDtBDi5liv4121DjpxjbwuekLCOFDLuJ/RsMfFIBzR9tHo9HD6H19s8jcbyfx1gBuR9TiyvAouWaeEhZudGAJfLJsMoD8UzKnMOrxe9APcwqIgg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=9cY7xZu6tKQkBnJEkMrnX9JbxrH/GT81vRAlOY9ec+E=;
 b=f43k8UIFyIJ2p/fGJ7VKuHVsWsgFX3KaMSZVndeEsnKv4Ody6bleBqszBzA1t2JnsHiW6QjNLUWTgrJdJFNijN563m6urIYeoCVxaae+EqFhWezyfNBxdtjoC5ykw25brMUqlfW0Sz5NQB8QIFZV37rwncm6Qgm+CuA1LEVKIfJ8ypbNBnHA4CO8kCRO87KSe//22IW76pqJdQcE8Gh2WVhj4TCLabogbRT7v9pAGr1PIf0KxJp0XWl2bXyUp+SbDsB6A98nYC72eFD7k+gBlBs7SveiXiPsn7u8hR060hJzdYTL8g/JJJx7a6VEoHjXveFHcvyxb4J0Ij11FdvPew==
Message-ID:
 
Date: Wed, 20 Mar 2024 08:36:43 +0100
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 1/1] tools/xenstore: Add missing XENCONSOLED_ARGS
 variable
Content-Language: en-US
To: Jan Beulich 
Cc: xen-devel@lists.xenproject.org
References: 
 
 <373304eb-ff38-411d-becf-99fc7c170ccc@suse.com>
From: =?UTF-8?Q?Rafa=C3=ABl_Kooi?= 
Autocrypt: addr=rafael_andreas@hotmail.com; keydata=
 xjMEZHDtHhYJKwYBBAHaRw8BAQdA4C7O72UZHQbhHNm1BUkAM/7+KQKN3tupyuGVGyj2dIHN
 KVJhZmHDq2wgS29vaSA8cmFmYWVsX2FuZHJlYXNAaG90bWFpbC5jb20+wo8EExYIADcWIQTv
 ioHnE84MxV6adj/iFi3SALEToAUCZHDtHgUJA8JnAAIbAwQLCQgHBRUICQoLBRYCAwEAAAoJ
 EOIWLdIAsROgP80BAKeJdh3YQ5l3gxGp8R9wIvN9Ac3vsMfy8I4kZ6TXksLKAP9vLRV4G3yw
 z7/seKhWc27Jjl4uI/+lIWhWaWrUYZmjAM44BGRw7R8SCisGAQQBl1UBBQEBB0DE61lbAezY
 NhOlHgxdZ9V4klIhSajeU50O8wHIPQnCLgMBCAfCfgQYFggAJhYhBO+KgecTzgzFXpp2P+IW
 LdIAsROgBQJkcO0fBQkDwmcAAhsMAAoJEOIWLdIAsROghHgBANU4dj+WnuSaWemAHVkjERJg
 m0FQpmZzNI8hdolS3gYdAP9zGK65ilpHMDj4pGvfALabruZA4NPJYxSqeamHvOuhBA==
In-Reply-To: <373304eb-ff38-411d-becf-99fc7c170ccc@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-TMN: [xTgT53uF+T7ONRchNxIKRPp+ySOD2xvWqbMTNCxwXmFCxqnQ7ai1xYfLh9uCw37R]
X-ClientProxiedBy: SI2PR01CA0020.apcprd01.prod.exchangelabs.com
 (2603:1096:4:192::6) To DU0P192MB1700.EURP192.PROD.OUTLOOK.COM
 (2603:10a6:10:3bf::6)
X-Microsoft-Original-Message-ID:
 <5979ca28-5a42-4e73-abe8-9a2f21df86e4@hotmail.com>
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DU0P192MB1700:EE_|AS2P192MB1984:EE_
X-MS-Office365-Filtering-Correlation-Id: 9cf479a8-b26f-4e00-8893-08dc48b0816a
X-MS-Exchange-SLBlob-MailProps:
	qdrM8TqeFBsDoBs/oZrXuoWrSByezst7VDYqxQw+b5ynGfzZrmTkxqxZ7fTUEPuAP45RwQ9Mxsc4s3zE0gZkWLwqwoQNdY6RW+RgWPAkXRNrqcsYSFb014SM7BK/loN6s3ZSvdhh4gt/9ov33DsoO5FNVm/aXRsPVbEbP44JEid7PjSb0ed/kGen8I4+Fhvo9/cGjw08nF3Fr/sAUj+Rwz95NhsG5coK2H7dDg4pGnVRI1H00mV9E2+qduVZoICaBs9FHidQsHOap8BxJ4KKxq6cwO4faors5Xhrf/duf27tArY9RHB98KS2nLKkfL1CrtItcPGLO6zwhgBfD5MjOIYc1yco4Xz/3dalvC5TTBDfOdqEHQKevtk/Xg/vSYbE9jvi2Qf/JKD3omKkRQeYoeuOE6nwvHf5noD1FAIc6fvu63RYSouXQnKvSxxuOSsTsadmzXwA77ynVRpYHpFwMt3xWcGHH7RmMI9aDJwMRWHPLMcx+qfY+M/fB5E+/jgOoTT0RiMkkwahfBlvFQiJCCHGxPnjEb1EcIXeLF/XDZdoLk3gKJTwKEytvO6gA+lNeSZImpgEtrW8+POBMxYVJqjW6LRVd7t+ZjVp3mzO7XJ9CrM30Xzovijomg6+e0eN2Pt9PdeAeTZ5BobhXA//IXNf8G0cQ2HyXkfXRb6NJ/A7bj3jpnmUv2mSRC1ThYIG7Io2+52t7q8o7AK0TtJmRU96Xvy5h+uMkRQXtmJbJ0GslRtzRnEEkeOILHLYV0PAiR0JoEyvi7lwY66I3du71TFEmXkpjclj
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	z/c17clEZmYu+peCHvoLjdByjsfRCL6P97A4Y8737SVRPfbMJ7WApxq/Z9PuAzCr3CqMjRvYvHJAG+Z+bC1+yAeGFRz9Sps8/lAGAckcttfK4A0U4B69+9QBCO87r5voKc/JCjIvPbeQtI4n6+6CDxL4x2XMotHEu6qvMTLHxJ1LhEKG8ru7k/G8hftM0btp5hBtQxGLIqbNA7tvxzzFvgMbVG5AoQIqHXH3PMfEmljftyJjw8YXGyxavpGqFNLTtUWHWns8FEI06OwQBF1Z/F17Yzjm1CyHXXP37sVr/4xuaVyk5/4SzDMcT3Z7k5sLDLvg1kv4PIJFuYI+PF7Gk2Bqege0opLgo2qJIQ2JwaF9S4Fd5qiWXS5hKb+BU86+1/kSW927rv8bSvbzyjCMIa7oEMxVh61v9bmwr6KOvQfn1xXpzqiP8Z8Qqsxe/ceX1OfXjXwIUaze9EJhpJpFmDyaQUAw4fnkMMUyojvHkmFjT4j1LRNyUhyqQQKW1zFmkYdy+Mp71tzCXeJ153Hx/Lp20QcJPfUvQGVteArHy9QMFQypVwhVAxs7Xg7YzeIP
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?WkZqRm9XYytjOEFLc0hJajdjTEsrSEt6Mjh2OFlvMjRzMXhVSUV6QXFJSU9D?=
 =?utf-8?B?YWtZS3IwUEI1VnhVQWtCMVNVL09yakhNOExmWUtlRURBQy9sQVNtSEpuaDFk?=
 =?utf-8?B?UUxCKzRnTGpIeVh4a0tCODBmVXJxbWFWZ3V2TCtFUWp1a3VqVnRmMFZGSnNt?=
 =?utf-8?B?V1lmUEhOSzMzcXRBNEJCOE16dE5YMGxPWHN6Tkkxbkh0UktwdFZSUVcxYy8v?=
 =?utf-8?B?VmVnd2Q2OThndWpOM2V1aXZDMGRYRkE4RGZ2clhuL2tnS0JjRVRYVUVHM1Nn?=
 =?utf-8?B?b3ppN2s4NVlLODFMNEhZWTJiQUdFUGVoS1ZVaFF5c2hEZlVSTFliMXpmd3Br?=
 =?utf-8?B?ditJcFg1RW8wb0dKZ3lDdFpQV2djODQraWNvMnJBLzNzTXY1cWNuQjYyTG5a?=
 =?utf-8?B?ZEhqWis3WWhKRUgrVjF5dTE2NzV5aGx3RWF5SW9KTEZmMXNkOTA1TUhhRFo4?=
 =?utf-8?B?N3Z3YU54OHd3cUFkZVI3bW0rczROalo3Q3lzR0FOdzFFK21aNWdhTUZZbU4v?=
 =?utf-8?B?a0N4TWpNNGpPanFiYk05TmdDbE1XWWJhSSsraXlBK0tYSHREQXVZa1YvMDho?=
 =?utf-8?B?TGVhRzQ2ZFVyTzF5Z09VZ3Uxc1ZBRkZRNmpqTEdoRHJJMDVIMW9aM0l2eVNF?=
 =?utf-8?B?d3VzVG90QzhFQjdJMklDWWQva2Y5N1llQ2tvdGtMbG16cHR6Nkcyc0dJRER2?=
 =?utf-8?B?V3NyU2ltazRVTndpU1FCKzgwbnpOOVl1ZXpsakVvMFA5VGZnVVY5NXlhY0Iz?=
 =?utf-8?B?WnlPajdKV0hwUEZPMWVCQkgwc0JuWmkvZlQycVZRZFZkQW4wd25QQi93eGpr?=
 =?utf-8?B?WE1tZStYRkw2RjZ0cm1iOEVHNmhCb2pYcjlYNWVrMFUxbUN6Z1dZSEd6aVR2?=
 =?utf-8?B?V3RQVTlLRkttOFJtSENWV0diSVR3L0YwZjdSa1MxaXlLT3ltTDZLNzBsZVUr?=
 =?utf-8?B?Tm9mSWc2MUxRejVVSmpnamZXNkp0aDNNblhuVmxhaGlXYjNZNTBRUjBhY2xI?=
 =?utf-8?B?LzNJejhhbU16VFozdVo4Sk9PUU0zbVVjejUrMWRjOERCWUFDT1R1MXo5Q0FG?=
 =?utf-8?B?UEJzckwxQSt2MHNpUG4zcjBwWWlGSW5iQWxkbXB1RjBvSE82OElKZjJwL3Y1?=
 =?utf-8?B?aUFGOXRVTGplOVJxbzZHaGc5ZEc4TG0wWEh6WU4xc2xBZWVmRDA2S1dmR0pX?=
 =?utf-8?B?eTcya0R5blVqelplWGVjTldRb2VFTWNtaUNjN241djVlYXVUZU9iMnBBU2pI?=
 =?utf-8?B?UnJhcFdROVdKQkJWNUkrU1NrK3cvSDJWdTB2VjNaWDFGOTlxbld1dWxkUVV6?=
 =?utf-8?B?c3k4TE9TSkJGS25zd3pHcktabVBPMUxLZmdSTmR3eFdXaVlLbGN5YnU1cHJZ?=
 =?utf-8?B?bEErY1BBdS9aOXhkSnVxdjl1K0Z3U0F0UTFidUNpazNkbU1DWTZoYnZ6U2wz?=
 =?utf-8?B?eFhLMFZCR2FBYmMranhYYnk5cDlBa09EZ1Uzdjk5TTI1SnhhMk1ZYzFjbVQr?=
 =?utf-8?B?N3drOWRoellXMXVkamU5b24reHNwWVJtNmgwSUZCZXY3TXV1WWRKUVR2SkxQ?=
 =?utf-8?B?WVlGeGQ4SlZyUmxqWFl1UmtLMXlYcWExcHdiWWlETTMxZ2lZZHJLUm5JNlEy?=
 =?utf-8?B?YVBIcytrWVRtNjJOZVFnMHNLaG1JcjcrbmlDMmVEN21IbmhzaHpMN3JFeHAx?=
 =?utf-8?B?QlZkb0lvajVnTEdpUlhicEVxd0hSa3h0V0h2enNPdXRCZWRyUllGQVY3dTVl?=
 =?utf-8?Q?IYIN2HeEfZ7eAkfwENcnB/ukJeM/ZgofRNw26Fu?=
X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-fb43a.templateTenant
X-MS-Exchange-CrossTenant-Network-Message-Id: 9cf479a8-b26f-4e00-8893-08dc48b0816a
X-MS-Exchange-CrossTenant-AuthSource: DU0P192MB1700.EURP192.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Mar 2024 07:36:51.5682
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg:
	00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2P192MB1984

On 20/03/2024 08:30, Jan Beulich wrote:
> On 20.03.2024 08:15, Rafaël Kooi wrote:
>> The systemd xenconsoled.service uses the XENCONSOLED_ARGS variable, but
>> it was missing from the xencommons file.
> As to the title prefix: How does xenstore come into play here?
>
> Jan
I don't actually remember, I may have done my git log incorrectly as I
don't see other people use that prefix for it. I probably should've
double checked before posting.

Should I use `tools: init scripts:` as the proper prefix?

Thanks,

Rafaël Kooi


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 07:50:36 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 07:50:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695761.1085799 (Exim 4.92)
	(envelope-from )
	id 1rmqiT-0001Dh-7I; Wed, 20 Mar 2024 07:50:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695761.1085799; Wed, 20 Mar 2024 07:50:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmqiT-0001Da-3Y; Wed, 20 Mar 2024 07:50:29 +0000
Received: by outflank-mailman (input) for mailman id 695761;
 Wed, 20 Mar 2024 07:50:27 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmqiR-0001DS-E8
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 07:50:27 +0000
Received: from EUR05-DB8-obe.outbound.protection.outlook.com
 (mail-db8eur05olkn20822.outbound.protection.outlook.com
 [2a01:111:f400:7e1a::822])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 837ee092-e68e-11ee-afdd-a90da7624cb6;
 Wed, 20 Mar 2024 08:50:26 +0100 (CET)
Received: from DU0P192MB1700.EURP192.PROD.OUTLOOK.COM (2603:10a6:10:3bf::6) by
 PR3P192MB0828.EURP192.PROD.OUTLOOK.COM (2603:10a6:102:45::10) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.7386.34; Wed, 20 Mar 2024 07:50:25 +0000
Received: from DU0P192MB1700.EURP192.PROD.OUTLOOK.COM
 ([fe80::181e:3628:177d:1cf9]) by DU0P192MB1700.EURP192.PROD.OUTLOOK.COM
 ([fe80::181e:3628:177d:1cf9%4]) with mapi id 15.20.7386.017; Wed, 20 Mar 2024
 07:50:25 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 837ee092-e68e-11ee-afdd-a90da7624cb6
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=EPh6sUEZoft7DbCubf8lEdYWia+TTfGdDyCxAQG+YST9aCon5PH962gIGjy405XqptcB94AaqMKFEMagOqY2UPdp6BCSmc/hr6cjGBXuB++9x5ROk/AZ21JGaj9yHbjtWvco8vlfz0+N4LNVd0cdRlzgUDT2mSLpYxrQDRhpAoio4COJUZczn8Fa9jqGNiP/36e6i6mLLdFdYwDtlMm3JMoc6dYeJj87h4oLsZ81WWJIoVzD2uxkJl2IbzpENsTg3qhaBJlZ6Ip56Bj0i+Zea6LLClc/8XHQtpF7AfrWMaXJTEERuEt1CxqZYXmg/ez0Rw0FkK//lDw8r7UTvBYaPA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=JSYeSAndKBPWjFc/iu3az3wJIFiMVk5/rcYAZYNPiT8=;
 b=ZDlospzqRFycyXgui5E++pdZJTYMxNaNTNnV9IfjmUpj51T2J5BRpQsTDRBJJQFnqAn83QWp3um3YPwDwcLVYrvSw7ljeipegp3w6yf/S4OWjUUOkXEEPieS7GEVSUnaLRMXL7PuLikPMoLbbDQqv3fqnGHs1ivE3U/5OemqcNWcrmwe66I3VHnX/bsjaw8IytaoOgorjQgFtuw62bkOlOWdKrKeGrLkeQVnLQ8bXYkNT9dGLYtZesdpK3H8cFmhnTBq6+TUiEtDomUx8VW6gD5eaokoaTg37W/ehO0/hNkMhwnDOkNiHB4bMmT855Wu1BbgsuRWlXMhL17KsdgOcQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=JSYeSAndKBPWjFc/iu3az3wJIFiMVk5/rcYAZYNPiT8=;
 b=gbs7GJlRBlKpTfiH80sUHwP74/4cQS9osWCQ7T7mRYpBR0SWk+c3iQhbH2G/V8/LtmQhNeQivOdzss3jcyThzv1HnA45Dp8LGUVbOPuh13zYqL2MdFVlR6mvvMbIYIqMjhcMOlo+pa+pGz2L801jbD56TxDSmk8JAN20i00Oa/dZxWCAfDwUcVSmCiyZPbhMvAqgIP8hLTmd375JkzbEdpWHxN1kWwJbr4Rl+Nv3K+R6W8w4mKvh+TgAIFiebfMyQ2u+9oJLAKa6sha1W2I/fW3uJs+WczfQzmVs/TRqyhlV9ypN5BdECfjScSMZnP6srVUKQ3fw12F9Fb7JDJOEYA==
From: =?UTF-8?q?Rafa=C3=ABl=20Kooi?= 
To: xen-devel@lists.xenproject.org
Cc: =?UTF-8?q?Rafa=C3=ABl=20Kooi?= ,
	Wei Liu ,
	Anthony PERARD 
Subject: [XEN PATCH v2 0/1] tools: init scripts: Add missing XENCONSOLED_ARGS variable to xencommons
Date: Wed, 20 Mar 2024 08:48:32 +0100
Message-ID:
 
X-Mailer: git-send-email 2.44.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-TMN: [fsv3Hz1Fr1Ul2d5Xru2Ov2r3g4Wf/rJI4JYxgckilQQxnc4fZjbuicmTHNxn23Hi]
X-ClientProxiedBy: FR4P281CA0360.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:f4::13) To DU0P192MB1700.EURP192.PROD.OUTLOOK.COM
 (2603:10a6:10:3bf::6)
X-Microsoft-Original-Message-ID:
 
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DU0P192MB1700:EE_|PR3P192MB0828:EE_
X-MS-Office365-Filtering-Correlation-Id: 08a75925-1b63-48d5-6ce3-08dc48b266dd
X-MS-Exchange-SLBlob-MailProps:
	laRBL560oLSDAxiCsf/0myDYsncr6f650xf3iTc8bJVH2GXdBR9eUjpcjLbYPSWuH9GUrxpZxQuc2T3u8KnQpw7V2ARkz1Z4OV3Jh0Hcr2+z4TQI9YjHWcMv+/94HQ9xgI15FLtW44zuGFNgaDnfEf0l7UIOxHb6rYIf5z62G4PEzw5/Iw6QseVpb5P6dWtxywcTYNKsWyBu6Qd6Op0osh1lrggaEO5HcHznW5IK7e7W1IgdkawwDx3K/C+OiZFlUP5LDcIubm2CYDI57L6RLkZoWIWmHrHhDd8EjIhHYBVPmgW62G+W5ANZYW0HGMkRuoVW4JrkMDJFgjUAUxFnstn4/LDIy68uNBawx0oT38vZ8+FA7ImmGr0pT/Sp/xxkcR6Cd4Sb5p/3o/qvtI0Ittfg9mjw6EvlJdWyd6DI78MJzMwXIWmjjkJf6SwJ9uMXEd2DbDKfHiwsKQrHEWSngyJGvzpa6U9mAL/gLY2VrhdellpGEN0rdrt+I8l57ik159I5xG04MHF3X+m4Lssoy1dGuNGuIXS+HTe5KtmkmD10W3+9Odi1J8J3MLEvtCcXd/N1QkTB+2rwiaKTLNlno1MU8RxAAqn+qoOy2iDHTMW1Kf9XPQd2Xptk42NY660Y34jITJbwUeo5oosLK7eXS84CgqSuFzuAioKqQ3FMODb9IUk88HrddN/Svs3BrMGPoSuiG7IXU3/8Nv0V3nqz44qlz8E4Q5kIj6NB4JNgSl+cWAn5X4NTrilVRGGC81N/224Hzn5jThHqKLUVk5qVpArW5FssV3RG
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	O7zSOWYl9iX7u71+5EPvKbxgyG/V4Um2Ut5oOeuiw+s5aEPb2AnAO4DnR/TdN+wSGGp2UDM9atM4MsvH/U88xMrhjcF6OB76RDUDABmFfoAN7bRCDj81zS+dTf9A7o76pgCb9bYGAT4S57GQ/Smk9gf4TorneoXYzAMRIXIpdLDag4wNTrVnhc78JyMAgea1F70QG3t0qkX5mTVF8rQ3MPClmFHRWfrAG7hMDMIbnJ3Sr4mXLxeQscdIhgwkgJmnLJSrSXJpn91e9iux4jaBsxbkfoaVWY/LVfOXtArD+FsF3pXHxhrNzCkZhS3Xowa92jQ9mVPbLlXrUd5WHih7zZbgIQ1CVO9JkDfRD93yIlk2/ePpe3dsKf70W0HFKDcqmRsa+eOzD3uBHTbrj2XjvKE7F6jYRlpcriMjs7E7JRaTJ67LtNpZkxNHdhMxfWq/0tEws6K09fYclREYtSCKxYLdE4xAXnkuS55XZyKBwttaFD65dZphXZotieG+aD0k0RkMP7dCEl6qpweYYEThiKrm08jPF0LSphO48QtNtdHsqOBdxXIl4M7tJhuovIhEneccyswQVQ8wNORp/t8HcmOLrq3CwmOczG8QT0LMw3YUCUAKgDyARQ5PJhqnD69G
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?NG5LcGkrUTRzMWxnOWZ3WFVydUpTS1V4bVhXTkwvV0lmSlZkcUx5dk05UkQ3?=
 =?utf-8?B?NjE2RGN6a1BSYUtOekFmYnQ0K2JmbjJWempuS29uMWZDTU1ROFZIcUNFaDR6?=
 =?utf-8?B?S2kwQWh3R3pnTXVjM0NaUjB1RDl4Z1hKaHFLdTFkSUFiZDhoMm5rMEJpc1p1?=
 =?utf-8?B?eFRUcUFKV04vTGEwTEdNSTFaRE9uVVI1Y2NLNmthL1VSZEFjZnB3MGt0WnEz?=
 =?utf-8?B?MFVZeWErODRkQjlIOCtsTTA2RnplSnlCcDVKcFNCMEVrUzllK2h6Vy9rK2tW?=
 =?utf-8?B?SzFnZlF0ZzBEUFk5ZERnT0U1UmZHd1krakNJcGtOajJpYUdUMlBpbTB2MUc0?=
 =?utf-8?B?ZUM5Vm93Q3p5eXRjdnBuMXYvb3JDME11aExqUmZnYmQrWDA4QzNGcC9KeGV4?=
 =?utf-8?B?VFhOZFN6NnU1Q0RHVHArNjJ3djlkRXAzZzk4QXpMaVBDTUp6UUZRNkY3REo5?=
 =?utf-8?B?NFRUcG16Q2lUbkhVQTBxckpqMmpjaGRCa25XV2JuTGFQQS9YSncrcFZCMFU1?=
 =?utf-8?B?Q0t2dkdZelBwYk9RSy9CeWd6VjJSUDRERy9BNjlwTGpscDhreUI4OTAzeWtk?=
 =?utf-8?B?aGpiUk1IeEJZYlA0NG5mNFNldUxuM1RRVmdrUGNlMGVCMXMvVmE1cmhDS1hi?=
 =?utf-8?B?VXFvUjlCa3J3aDZWZjVoaHYxdHpRTnNocG1Yd1VETmVveGk0d05oelNjNldN?=
 =?utf-8?B?TkQrQk83WVlxa1ZyQ1dJaHlkRE1LOUNuMHlBMWNvNUhKUEVaWDlpbnc2TzVt?=
 =?utf-8?B?OHhiaFFYYVdCRmphU0o4NFlBUUZNWk5CQ2N5dTJqYUFzWTl1WjRoT3poV29T?=
 =?utf-8?B?d2ZBSko3M0tCcXRCNFJjKzRuUkZoK1c4c1doQkdhWStHNHJuelJEbkkwSUdl?=
 =?utf-8?B?VXpzZHozdk5tSFpzdElEdDZFK2ZocjBLajNPcXpCdkdxM3ZXNFRPRGUyMlR3?=
 =?utf-8?B?TDVvQi9qZE00SDh5dDRvQUZ3TDhFOUk4Z1BZSXQ5V2grVmNqQUM3Q1R2V1BL?=
 =?utf-8?B?TFBqNTV1RWRGQm9WRWlmdHpRRHA5aGNVeW9BOGhnRHQzQ0FURGxQcjQ2aWNG?=
 =?utf-8?B?clhDQUF0UCtGRjZsdWs0WHpYL2c0bGlZbDRJMHNlZ3oyRkFDMG1USUdYNytF?=
 =?utf-8?B?QVJPWThpQ2NYT3BnTTVKb2NFaVZlYXY5dWgrb3VueDV4OVBqY05UdkREVnF4?=
 =?utf-8?B?OFZkUXFJaFlBQTBUeHhKMlY2a29tVG9hK3B0d0ZDbnUyMlFRTEkzcWozUURL?=
 =?utf-8?B?dHA2M3BFeE50NzI1enI1alNlL2hPU1V1RHUzL0dJV29Oam00bU9EUC9xVm9v?=
 =?utf-8?B?dmNsSUhlNDYxWkQyYXY0YkRoUXVXQzhHbjErY0djQWtkTFAxd3ByT0QvM1dS?=
 =?utf-8?B?ZlVKWmVLMWYxUW4wbVZDQm5Delo2Z1NFc0J0VklCT0poS3RCM000WjZWcHJw?=
 =?utf-8?B?eHBlMGlNSHNvWXpZNmhHaHZQN3hrQnpXcW1WbkljTDhSdWlnQzJmQ2JwdWsr?=
 =?utf-8?B?TzBBdWhWZm9Rd2c0dkZTTXpQTFdUSUlUMC9wY2s5czJ5bEs5T1phdUpteUpH?=
 =?utf-8?B?WEY0VENlZmZxb241NXM1M2orSFd1S010UFQrT21rcHVWbFBkK2E4Wnh6anFk?=
 =?utf-8?B?QnFGUzRVTFUrZTRsMHBhc1d2NWhDNlRWUVAzZmNtSXlJbDVzendVRGg0M2t1?=
 =?utf-8?B?Sk1OdDJ1b2dPWnlhTDNnaW83cnE1bHkyaTZ0WTlIQWlodTZOUjY5T2hkZi9h?=
 =?utf-8?Q?G3lo73byU+Ks89GW+ercYrsF1nUFDAuG7qpbyja?=
X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-fb43a.templateTenant
X-MS-Exchange-CrossTenant-Network-Message-Id: 08a75925-1b63-48d5-6ce3-08dc48b266dd
X-MS-Exchange-CrossTenant-AuthSource: DU0P192MB1700.EURP192.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Mar 2024 07:50:25.1180
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg:
	00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR3P192MB0828

V2: Now without test emails ending up on the mailing list. And with the
correct title prefix.

I noticed that the systemd services referenced the XENCONSOLED_ARGS
variable, but it was missing from xencommons.
I actually ran into this when experimenting with a Qubes patch where I
thought I needed to modify this variable. It turned out to not be the
case, but I figure it's good to include this for sake of completeness.

Rafaël Kooi (1):
  tools: init scripts: Add missing XENCONSOLED_ARGS variable

 tools/hotplug/Linux/init.d/sysconfig.xencommons.in | 6 ++++++
 1 file changed, 6 insertions(+)

-- 
2.44.0



From xen-devel-bounces@lists.xenproject.org Wed Mar 20 07:50:42 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 07:50:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695762.1085809 (Exim 4.92)
	(envelope-from )
	id 1rmqig-0001VT-DU; Wed, 20 Mar 2024 07:50:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695762.1085809; Wed, 20 Mar 2024 07:50:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmqig-0001VM-Ao; Wed, 20 Mar 2024 07:50:42 +0000
Received: by outflank-mailman (input) for mailman id 695762;
 Wed, 20 Mar 2024 07:50:41 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmqif-0001Uy-4c
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 07:50:41 +0000
Received: from EUR05-DB8-obe.outbound.protection.outlook.com
 (mail-db8eur05acsn20800.outbound.protection.outlook.com
 [2a01:111:f400:7e1a::800])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8ae5cd4c-e68e-11ee-a1ee-f123f15fe8a2;
 Wed, 20 Mar 2024 08:50:38 +0100 (CET)
Received: from DU0P192MB1700.EURP192.PROD.OUTLOOK.COM (2603:10a6:10:3bf::6) by
 PR3P192MB0828.EURP192.PROD.OUTLOOK.COM (2603:10a6:102:45::10) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.7386.34; Wed, 20 Mar 2024 07:50:38 +0000
Received: from DU0P192MB1700.EURP192.PROD.OUTLOOK.COM
 ([fe80::181e:3628:177d:1cf9]) by DU0P192MB1700.EURP192.PROD.OUTLOOK.COM
 ([fe80::181e:3628:177d:1cf9%4]) with mapi id 15.20.7386.017; Wed, 20 Mar 2024
 07:50:38 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8ae5cd4c-e68e-11ee-a1ee-f123f15fe8a2
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=MMGKSz2wMqPhSO6xqeZ30Med/ckEivdCi22ro7US5sXxDGKbI8kN4nGK/Qumy59ypBycBEg9ur7CrGJ4Y1bPg6V/frYFEnDcM1+YAxZZRuMzpf7F6e9dSrPneZSCUbXcMlBRyn7jjYLIB62JDa/viBjpDyvdkNdHMITcNuSv/LjJW0PUC7btJz3KXwJJjG3SLvmFp+va/g90FRgdR5l/mAuTCDsRFW3LK0jjuFKjOjRud8prRPlI/9+a29naRBuS5pGfuBCeGVbUUwKh0HsiEQHB2d3/ekO/a8Jo2DhqG16GXf1NiO+07jGHOVZZ+5+Tne5pf6avtJbCEoVl68U+Mw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=L09xaIyDfPc1imD82wYwTmT8UcsJA4judxkiTTMaxjA=;
 b=DL2/JVRVb+/iy/LHXeZACWGX6/gUk8wS1idWKaqMYFzfqJJAwiAe8Zu/G0Xgj74zjYQ5N6BMU3wRYG7i0VIATsZO3JIO+zE5AD9KwSLIuWg6NAANXzJ2kwf0338LDgWMPfGQu3hMTh1FynpZrRuRJwzTIs2P/gx4LW9/70289BEk+eZo7tdAApMXzFFFFeFOViEIHluVAOGgjntX4ic4fJ2iLxzsquRlo/96JGhO5ty87hvE5y/tKi/b7Bkormx3F6rIB+ogffgJU5sA3tOP/WFzg5/irC22jl2NVf6UaGZc7LkAZ68S5A5pzmC/Xrgj3uvCFFbEWpxrvLibCFp2dA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=L09xaIyDfPc1imD82wYwTmT8UcsJA4judxkiTTMaxjA=;
 b=uois+tdcleraLQ5xW87TAq5AYD7939tKYfGoEBXsSc03t9UDTV/nwSHoGOFiyxWvjss7UDhCh/3l1ZgX6oCSGurdFeV9ToTz+jO7NvD+L1FXpSzA/AFAokEioHjYH5KVddKvUQD4a9sQEESnqMVtbEaGGj1equyMTvsLzYki9lNw7o/GdcxKx9Evam/+rvH1//S/ewwcid3c/p02T6LPOk7HHj7UrNVgElfZS489hQbRewkGyoKh3ZCJ+2VP29IWg1tRzSQENhzzC+U9/G3UioyfNTPYTv++JjBuTlZFy9JnhH2EvoWT5W1vl8QiqkHy9yn3gm/jzsD04jKERtjEUg==
From: =?UTF-8?q?Rafa=C3=ABl=20Kooi?= 
To: xen-devel@lists.xenproject.org
Cc: =?UTF-8?q?Rafa=C3=ABl=20Kooi?= ,
	Wei Liu ,
	Anthony PERARD 
Subject: [XEN PATCH v2 1/1] tools: init scripts: Add missing XENCONSOLED_ARGS variable
Date: Wed, 20 Mar 2024 08:48:33 +0100
Message-ID:
 
X-Mailer: git-send-email 2.44.0
In-Reply-To: 
References: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-TMN: [XwTrKlg6f4ZATfloz9Fk/iU60x4veSBMf8mKytBR9Ce6Ht4Idhuv0UoRIyNBALfD]
X-ClientProxiedBy: FR4P281CA0360.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:f4::13) To DU0P192MB1700.EURP192.PROD.OUTLOOK.COM
 (2603:10a6:10:3bf::6)
X-Microsoft-Original-Message-ID:
 <963cbb19d73f3d7c7f1fadceac376dfae81beb19.1710920673.git.rafael_andreas@hotmail.com>
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DU0P192MB1700:EE_|PR3P192MB0828:EE_
X-MS-Office365-Filtering-Correlation-Id: 29f9d41a-f599-4def-e87b-08dc48b26e8a
X-MS-Exchange-SLBlob-MailProps:
	laRBL560oLSDAxiCsf/0myDYsncr6f65usFjG82Jg1Mkme1//TIjYHjzju0NSEsT3BOEcjuifrvDLpGRmGntEbBHYBtOszk4h+U9iCNGGZBeaHk01U9hbmSup5UtwbHfmyOD1gOH1W4u9+MY9fDCLGK9XESmEgyOeJ0p+12cbkxXBDsNxz0Q6Tr+DyrG7XSkor1wOEbN/vAIr/yhgSB0KMoD+rNjYsDZpzeMJEeMJRwUJBq/s3TW1XkWPAMCAsBEgx9W68Pfdn9W8xu4HrHfj8DC0zy2xVTaf5o7YylvyaoDW4nKfujeHAhIyeQXXk+YeNO2zfAR0KC5S45MJ9pKE3jqg55DCKO0ZHhmtUJ7fP9mHJkJ/76QeGbghd6iNOLUQKl8atFsoRyC/2gqV3o2Huxg8083jZgIgevff6CvS29IQ9LgcTY0rvdyMZvxUSKNyjiLUeZ9HvdwhtqRHDTnSIR1O6Ay2O3AGUVxAsJyEikgZ/LXrtN3OaCTY+bf/GT/GZkzQUu9eJac2xGyQc26v5dkAlqT70TcKibX+I/MlcFYjTE4sKDsGKS7AySL3+JdhGSVjA5pzUa9zCzgPCKOxvJ8UyDi7kU6ysTLIlfWDU9GZMkdodM88Qm52dHjBce8LYCh0QTIQlV1eCwl7v41VopEbp+bnYrj8/suMbOjD2v5qhyo9lNkneXn/wz1BtDyQO8GS/HrUS971NUoEpPqoZtwfb21o/A1axEPdnAxS0HrBJ0N9t81lBbrbMCZK+M9WUThglZjsMEAySmTsPt9Uq5brC9kkfec
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	0L7nBKHpBr5MLu54pcKEQRPlzu/xn4zw4sy8Q7MpMLc7B9cjXTUeVpHcbpK7Lm5+j9KSvGup+VzFb/Pr1aBAIncdO78JZ4QAXL9iMzY4cIW/R4hwJWnm9km5T2mS5kmNX7N735Tg4QDFgdNBN205KUiD6nnxfna4Lalgi4uqFbEsxMymdtLGW0XloDSdKXNXBKIKP2AO/KfJZA+QGA2XVPjfBB4tyiegDa73PKewcvpRFJ6jiwjVl3kZ+i1XGaqcBjzkqbQF8WptIBa7iksHdtqwnWOWYKt1NfFF54tEE9iMdNv25f/aQh8Pe0cXnfo+NDV1vGN+FSnajU115KxQAsfJ2duRdw04wIp+0HcX7dfIuBWLgHDzPRuoPXr6vdmDXWF/J2oNqo7yrlR8dMuInX2z8dh4RpbYKKIPjBF3//W6Xtoj5WhMtGqd6rnojxF9IcKHXhOv0v0We/q9tL0Lo9jBershfhdQoG/uwxLyQjFeK6p3Yh0ClWuxW1gVMkEkydPOKTXhIzn0MsoG8T4KKfjgFwE+i4dKvqQ3mjjZU0ejZTfrNq0ZXW5AdNO6uz+k8NrFo2Qc6eLLzrrMFcG/FWww4vNEs8v2I4xwR9qbDg85HLkqXaHOqRQr2FcugfAv
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?eGVPOFlhOVdmODdhcnRtd0M5VkJmR210eW1HaU1UcHpLNUNJREdFWHZMR1R6?=
 =?utf-8?B?MEFTL0tBVi9pV2RDUG5naG5tVTFvc0xWd3pFUUFsWjNaMS83dnh2Wm1Qb3Vo?=
 =?utf-8?B?WmFsZE9MR2U1UnFuVmwrN2pNZTdOU1hjZDlpZmsyYnhWek9UWUNwc3Q5NVBI?=
 =?utf-8?B?RFhldGZtMERhOVVOUVhtcGJENVpTOTRFelkvQjZRdG9zV0hPZmRhM1ErRFBH?=
 =?utf-8?B?V3hBUmFxakhNUnVpSU92M0MvNThLT3l2TER1cVJoZDcwcnBtL2pYNG1VdUR4?=
 =?utf-8?B?d3ZFTm1GUmJ2VHJ3K1JNSlFTU0I5TXVUUW1VdHkyM2FIMUN6MFgxM2gwZGNT?=
 =?utf-8?B?b09zOVE1WTBjekNzVDZxaUtWQ214Q3ZGSGg5NzBxbzFOUDhRSEplWGRUTGhj?=
 =?utf-8?B?SDloN2lFd3NyeFNqSTd3UU4wOEZPOHVPZ1hmVkRQV2RMemdkcDRBTlRRWlpM?=
 =?utf-8?B?ZHRLeHkvNUxoWjlDWUpKSHNmUDRXQ2I1VjBUaXlHTGZuOFhZSm04YWQ1aTE4?=
 =?utf-8?B?d2xFZzU4UHBzMmFsSnVjQlJ6R3VtQ1BSK2NKTTZlNHczejdxTUd5Y25MMkdI?=
 =?utf-8?B?VHRBTy9DU2RLUVl0NHIvRG4rajYzZC9iREJCVCtvVml2Yk1kTHRnOFoyZjRP?=
 =?utf-8?B?ZGE5VkRWdmdKaHhQbVg4QlE5U2dWRzRrVWY5azFhUjJDRjNJenFLYStlUXBK?=
 =?utf-8?B?a0pSMkRURkpaYks2cmJsSGh5NHFhS3Y4S1plRERhSHZKYW96eW5DQm1HQWRt?=
 =?utf-8?B?SDBrSFBkNk9tMXpnR3lkWGcvcEsrWmQvbysvbCtuRmJFeTJ0YkdNeWQ3Nlo3?=
 =?utf-8?B?ZGNqb0p1NFlMcVFlRFNINm0wWGxwTUZ2Q01JQ1YwTXNmNkxqMUxSWWZLSGU5?=
 =?utf-8?B?ZmJjZzU1REs0b3pwd3JUTWNscjlhSUpLOVdUdHR1WWphc0Y4c1JvOWpSYS9s?=
 =?utf-8?B?TWoyUU00KzRidHBTdjh1dzU0ck9VY1JnL095TithemFlSnplZjA1S2pCb1Bs?=
 =?utf-8?B?S1NBaWswUFJNTit3MHJCdWU5Uk1wMTI2c2R4SURIa0JucDlGUDZwYnFOK0E5?=
 =?utf-8?B?WmZTM0pPVVFyMklDUENXYzBvajY2ZTZFQ2hud25wNFppdXRTMExWc1lYZzZI?=
 =?utf-8?B?R3BtbXd3ZTRJQWdnM0pIMW1kWTRHRFJiZ3phdEwvSTBZSVN1cXlZV3BpRG9G?=
 =?utf-8?B?c2VNeGRHY1AxdlJwWm1vcHVIczBaOTFJYXc1bzlkL2s2NE5RSytpZHRWUUNt?=
 =?utf-8?B?WkpEL2o4dGQ1RXlVSmpkOW0vZFZLODJvV0Z6VHoxMGNCSGNadUE1aFZnMUlZ?=
 =?utf-8?B?UVVPRG1kVWJjNi9ncXR6dmIzWUtYS2tGZG54ZjliU1pPU1ZwZ2M5Z3dmcGRo?=
 =?utf-8?B?UER1YTZTM0NKS2J6Y2Q1ZDJvTGltcWlRWk81THJpR0FRZFRqaW5Kc2t0WHhs?=
 =?utf-8?B?TS9nSnZlSDZ3V3FCNytjT0s4QUYzaUlwTU0xbHdXVlFzU0NVaVVoekR0c2VP?=
 =?utf-8?B?SWpxOVNPenBSUkYyaVdlUitESXRnQWhPZ2FFRnVKajB3Umg0Mjh6ZzhyUll4?=
 =?utf-8?B?ZTVMVHBXZHFTdTdwYUYwK0t5RFJnV2Ywa3hjMEVvT1JXd1QrNkV2TWdaeHFa?=
 =?utf-8?B?cWh2L0JPa0hUd1RsYWNWZkJzVkg5dko3S29rQXV2R2p4UGUrU1h3QllDVHIx?=
 =?utf-8?B?VnJMYitCZmZOUndWR2pVd1pQSGZ4RzRPL044V09mUkV6SVBUQW03ckFDVFR6?=
 =?utf-8?Q?LvMIo73vAKa/XxCVEh8N55jdBEiJdh6+IrmWBY1?=
X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-fb43a.templateTenant
X-MS-Exchange-CrossTenant-Network-Message-Id: 29f9d41a-f599-4def-e87b-08dc48b26e8a
X-MS-Exchange-CrossTenant-AuthSource: DU0P192MB1700.EURP192.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Mar 2024 07:50:37.9057
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg:
	00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR3P192MB0828

The systemd xenconsoled.service uses the XENCONSOLED_ARGS variable, but
it was missing from the xencommons file.

Signed-off-by: Rafaël Kooi 
---
 tools/hotplug/Linux/init.d/sysconfig.xencommons.in | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/tools/hotplug/Linux/init.d/sysconfig.xencommons.in b/tools/hotplug/Linux/init.d/sysconfig.xencommons.in
index 1bdd830d8a..42104ecaa4 100644
--- a/tools/hotplug/Linux/init.d/sysconfig.xencommons.in
+++ b/tools/hotplug/Linux/init.d/sysconfig.xencommons.in
@@ -5,6 +5,12 @@
 # Log xenconsoled messages (cf xl dmesg)
 #XENCONSOLED_TRACE=[none|guest|hv|all]
 
+## Type: string
+## Default: ""
+#
+# Additional commandline arguments to start xenconsoled.
+XENCONSOLED_ARGS=
+
 ## Type: string
 ## Default: daemon
 #
-- 
2.44.0



From xen-devel-bounces@lists.xenproject.org Wed Mar 20 07:51:37 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 07:51:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695766.1085818 (Exim 4.92)
	(envelope-from )
	id 1rmqjY-0002Hx-Od; Wed, 20 Mar 2024 07:51:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695766.1085818; Wed, 20 Mar 2024 07:51:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmqjY-0002Hq-Ly; Wed, 20 Mar 2024 07:51:36 +0000
Received: by outflank-mailman (input) for mailman id 695766;
 Wed, 20 Mar 2024 07:51:35 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmqjX-0002Hb-Gb
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 07:51:35 +0000
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com
 [2a00:1450:4864:20::62d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id aafd2936-e68e-11ee-a1ee-f123f15fe8a2;
 Wed, 20 Mar 2024 08:51:32 +0100 (CET)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-a46a7208eedso531053966b.0
 for ; Wed, 20 Mar 2024 00:51:32 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ak8-20020a170906888800b00a46b4544da2sm3964527ejc.125.2024.03.20.00.51.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 20 Mar 2024 00:51:32 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: aafd2936-e68e-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710921092; x=1711525892; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=264kYHMNrCnzKREFunj4TW0vQGlF/lmI4/pk1dPm/GE=;
        b=M6Y2IRfku6TaCzQZiCGVZV83hJ0IgKqPtPkBwq3BGRHyUJWXm0cQz61vAXoRLpq1HW
         YWnoJpLTJBAvqON19cc9ATCtl7xr92FixrNU5cigIXs2V++ph9+MrYUiViIc0dx1mfJN
         OBWz60bpJ0xBF1lZil7+lu1D/8b6KHYgZLVJkuBFFxKvIcAUPkNzdel63TBCrjXjzR3h
         I1QmXtPXhEMZnp3tMUUQYehQXUr0l/EyfMmHNFWDNkYeQiFfhZxJ5YoYFOsIanSQfqQt
         zF+FE5hXp9P1KxEZu/ELMCs3+m8n2KSi6OyVysrnxbg8VuatNdb217CwdbZfD48SNLp6
         QiDw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710921092; x=1711525892;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=264kYHMNrCnzKREFunj4TW0vQGlF/lmI4/pk1dPm/GE=;
        b=CtETCzv4PLbtD6E6bClm9WjbPPM77z2ZkXY1ghLRe46PxgYlErZ6ADz1QOfZZWbLfz
         kuvd7VFGCbbomyAaYXnFE3b6gJ7vv400EGbSO44OlVDc+b5zGMHcRB73FMCdKBONVdwa
         eyaauJ8cKnTK3ULSNiFn2Uk8sCy+ORIqtDpBPGnUP4Ha8M86ePV8M1Qgc0Jd/za1IDvw
         uxDOjN8BLwFmTCpSg3ZWj9dJyuO5Vu5ZiSsrv38kVc56jB3FpeKlFDKN7h9yaI05ie9X
         aY/rmLKXWAdsJCW+Xafvx7uD41uVA8XQqwOLSrxWUentUxYOeRnBj9SvXrVIY0Y5J2aE
         Y2gQ==
X-Forwarded-Encrypted: i=1; AJvYcCV8Fm9Nw8wbxuKNhr4Zp+XwA7nHMsz6+SpYwUFVzdXgewK+c9WdB1iVpYeBS8p5ydWWyJdYifBotFtPL+73ZMebwhErIFmOCUPymoGdMTQ=
X-Gm-Message-State: AOJu0YxHkKVF/uh7fLem+TRUPmkMNQF0m4p2ykPPDrLRkkUbMB3Nwu4G
	gx1CR5bb+VR5/2Pu2HhEPYJDs5KZbyRhTMVF04U7gPWuWQWfhX9AfB/qx3/3bA==
X-Google-Smtp-Source: AGHT+IHtv+XzZNa/R00/jRtgycGltymphZM8VseCmYqQksNyeRocCY1USJXsZziK8RQ49YKe1FxeeQ==
X-Received: by 2002:a17:906:5292:b0:a46:2cc4:421 with SMTP id c18-20020a170906529200b00a462cc40421mr10285617ejm.74.1710921092354;
        Wed, 20 Mar 2024 00:51:32 -0700 (PDT)
Message-ID: <87234837-9fb3-40a9-849d-8b8574f2661c@suse.com>
Date: Wed, 20 Mar 2024 08:51:31 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] docs/misra: document the expected sizes of integer
 types
Content-Language: en-US
To: Stefano Stabellini 
Cc: andrew.cooper3@citrix.com, bertrand.marquis@arm.com,
 george.dunlap@citrix.com, julien@xen.org, michal.orzel@amd.com,
 roger.pau@citrix.com, xen-devel@lists.xenproject.org
References: 
 <6a76723e-ba47-40b3-8f33-d68030b14299@suse.com>
 
 <7ab73379-b057-4568-9869-141cef185752@suse.com>
 
 
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 20.03.2024 07:01, Stefano Stabellini wrote:
> On Tue, 19 Mar 2024, Jan Beulich wrote:
>> On 19.03.2024 04:37, Stefano Stabellini wrote:
>>> On Mon, 18 Mar 2024, Jan Beulich wrote:
>>>> On 16.03.2024 01:07, Stefano Stabellini wrote:
>>>>> On Fri, 15 Mar 2024, Jan Beulich wrote:
>>>>>> On 14.03.2024 23:17, Stefano Stabellini wrote:
>>>>>>> Xen makes assumptions about the size of integer types on the various
>>>>>>> architectures. Document these assumptions.
>>>>>>
>>>>>> My prior reservation wrt exact vs minimum sizes remains.
>>>>>
>>>>> We have to specify the exact size. In practice the size is predetermined
>>>>> and exact with all our supported compilers given a architecture.
>>>>
>>>> But that's not the purpose of this document; if it was down to what
>>>> compilers offer, we could refer to compiler documentation (and iirc we
>>>> already do for various aspects). The purpose of this document, aiui,
>>>> is to document assumption we make in hypervisor code. And those should
>>>> be >=, not ==.
>>>
>>> Well... I guess the two of us are making different assumptions then :-)
>>>
>>> Which is the reason why documenting assumptions is so important. More at
>>> the bottom.
>>>
>>>
>>>>> Most importantly, unfortunately we use non-fixed-size integer types in
>>>>> C hypercall entry points and public ABIs. In my opinion, that is not
>>>>> acceptable.
>>>>
>>>> The problem is that I can't see the reason for you thinking so. The C
>>>> entry points sit past assembly code doing (required to do) necessary
>>>> adjustments, if any. If there was no assembly layer, whether to use
>>>> fixed with types for such parameters would depend on what the
>>>> architecture guarantees.
>>>
>>> This could be the source of the disagreement. I see the little assembly
>>> code as not important, I consider it just like a little trampoline to
>>> me. As we describe the hypercalls in C header files, I consider the C
>>> functions the "official" hypercall entry points.
>>
>> Why would that be? Any code we execute in Xen is relevant.
> 
> There are a few reasons:
> 
> - the public interface is described in a C header so it makes sense for
>   the corresponding implementation to be in C
> 
> - the C entry point is often both the entry point in C and also common
>   code
> 
> - depending on the architecture, there is typically always some minimal
>   assembly entry code to prepare the environment before we can jump into
>   C-land; still one wouldn't consider those minimal and routine assembly
>   operations to be a meaningful hypercall entry point corresponding to
>   the C declaration in the public headers
> 
> - as per MISRA and also general good practice, we need the declaration
>   in the public header files to match the definition in C

Throughout, but especially with this last point, I feel there's confusion
(not sure on which side): There are no declarations of hypercall functions
in the public headers. Adding declarations there for the C entry points in
Xen would actually be wrong, as we don't provide such functions anywhere
(to consumers of the ABI).

>>> Also, as this is an ABI, I consider mandatory to use clear width
>>> definitions of all the types (whether with this document or with
>>> fixed-width types, and fixed-width types are clearer and better) in both
>>> the C header files that describe the ABI interfaces, as well as the C
>>> entry points that corresponds to it. E.g. I think we have to use
>>> the same types in both do_sched_op and the hypercall description in
>>> xen/include/public/sched.h
>>
>> There are two entirely separate aspects to the ABI: One is what we
>> document towards consumers of it. The other is entirely internal, i.e.
>> an implementation detail - how we actually consume the data.
>> Documenting fixed-width types towards consumers is probably okay,
>> albeit (see below) imo still not strictly necessary (for being
>> needlessly limiting).
> 
> I don't see it this way.
> 
> As the Xen public interface description is in C and used during the
> build, my opinion is that the public description and the C definition
> need to match.
> 
> Also, I don't understand how you can say that public interfaces don't
> strictly necessarily have to use fixed-width types.
> 
> Imagine that you use native types with different compilers that can
> actually output different width interger sizes (which is not possible
> today with gcc or clang). Imagine that a guest is written in a language
> other than C (e.g. Java) based on the public interface description. It
> cannot work correctly, can it?

They'd need to write appropriate hypercall invocation functions. As per
above - we don't provide these in the public headers, not even for C
consumers.

> I don't see how we can possibly have a public interface with anything
> other than fixed-width integers.

That's the consumer side of the ABI. It says nothing about the internal
implementation details in Xen. All we need to do there is respect the
ABI. That has no influence whatsoever on the C entry points when those
aren't the actual hypercall entrypoints into the hypervisor.

>>>> As to public ABIs - that's structure definitions, and I agree we ought
>>>> to uniformly use fixed-width types there. We largely do; a few things
>>>> still require fixing.
>>>
>>> +1
>>>
>>>
>>>>> We have two options:
>>>>>
>>>>> 1) we go with this document, and we clarify that even if we specify
>>>>>   "unsigned int", we actually mean a 32-bit integer
>>>>>
>>>>> 2) we change all our public ABIs and C hypercall entry points to use
>>>>>    fixed-size types (e.g. s/unsigned int/uint32_t/g)
>>>>>
>>>>> 2) is preferred because it is clearer but it is more work. So I went
>>>>> with 1). I also thought you would like 1) more.
>>>>
>>>> For ABIs (i.e. structures) we ought to be making that change anyway.
>>>> Leaving basic types in there is latently buggy.
>>>
>>> I am glad we agree :-)
>>>
>>> It is just that I also consinder the C hypercall entry points as part of
>>> the ABI
>>>
>>>
>>>> I'm happy to see a document like this added, for the purpose described
>>>> above. But to me 1) and 2) and largely independent of one another.
>>>
>>> Good that you are also happy with a document like this.
>>>
>>> The remaining question is: what about the rest of the C functions in Xen
>>> that are certainly not part of an ABI?
>>
>> As per above - anything internal isn't part of the ABI, C entry points
>> for hypercall handlers included. All we need to ensure is that we consume
>> the data according to what the ABI sets forth.
> 
> It doesn't look like we'll convince one another on this point. But let
> me try another way.
> 
> In my view, having mismatched types between declaration and definition
> and having non-fixed-width types in C hypercall entry points is really
> bad for a number of reasons, among them:
> - correctness
> - risk of ABI breakage
> - mismatch of declaration and definition

What mismatches are you talking about? There's nothing mismatched now,
and there cannot be any mismatch, because the consumers of the ABI don't
call Xen functions directly.

> In your view, the drawback is not following the CODING_STYLE.
> 
> The two points of views on this subject don't have the same to lose. If
> I were you, I would probably not invest my energy to defend the
> CODING_STYLE.
> 
> 
>> To use wording from George when he criticized my supposed lack of actual
>> arguments: While there's nothing technically wrong with using fixed
>> width types there (or in fact everywhere), there's also nothing technically
>> wrong with using plain C types there and almost everywhere else (ABI
>> structures excluded). With both technically equal, ./CODING_STYLE has the
>> only criteria to pick between the two. IOW that's what I view wrong in
>> George's argumentation: Demanding that I provide technical arguments when
>> the desire to use fixed width types for the purpose under discussion also
>> isn't backed by any.
> 
> I don't think we are in violation of the CODING_STYLE as it explicitly
> accounts for exceptions. Public interfaces declarations and definitions
> (hypercalls C entry points included) are an exception.

If that was technically necessary, I would surely agree to there being an
exception here.

> In my opinion, using fixed-width integers in public headers and C
> definitions (including C hypercall entry points) is top priority for
> correctness. Correctness is more important than style. So, if we need to
> change the CODING_STYLE to get there, let's change the CODING_STYLE.
> 
> 
>>> Those are less critical, still this document should apply uniformily to
>>> them too. I don't understand why you are making the >= width assumption
>>> you mentioned at the top of the file when actually it is impossible to
>>> exercise or test this assumption on any compiler or any architecture
>>> that works with Xen. If it cannot be enabled, it hasn't been tested, and
>>> it probably won't work.
>>
>> Hmm, yes, that's one way to look at it. My perspective is different though:
>> By writing down assumptions that are more strict than necessary, we'd be
>> excluding ports to environments meeting the >= assumption, but not meeting
>> the == one. Unless of course you can point me at any place where - not
>> just by mistake / by being overly lax - we truly depend on the == that you
>> want to put in place. IOW yes, there likely would need to be adjustments
>> to code if such a port was to happen. Yet we shouldn't further harden
>> requirements that were never meant to be there.
> 
> I have already shown that all the current implementations and tests only
> check for ==. In my opinion, this is sufficient evidence that >= is not
> supported.
> 
> If you admit it probably wouldn't work without fixes today, would you
> security-support such a configuration? Would you safety-support it? I
> wouldn't want to buy a car running Xen compiled with a compiler using
> integer sizes different from the ones written in this document.
> 
> Let me summarize our positions on these topics.
> 
> Agreed points:
> - public interfaces should use fixed-width types
> - it is a good idea to have a document describing our assumptions about
>   integer types
> 
> Open decision points and misalignments:
> - Should the C hypercall entry points match the public header
>   declarations and ideally use fixed-width integer types? 

As per above, this question just cannot be validly raised. There are
no public header declarations to match.

> I'd say yes and I would argue for it
> 
> - Should the document describing our assumptions about integer types
>   specify == (unsigned int == uint32_t) or >= (unsigned int >=
>   uint32_t)?
> 
> I'd say specify == and I would argue for it

Actually, I had a further thought here in the meantime: For particular
ports, using == is likely okay - they're conforming to particular
psABI-s, after all (and that's what the compilers used also implement).
I'd nevertheless expect >= to be used in common assumptions. That way
for existing ports you get what you want, and there would still be
provisions for new ports using, say, an ILP64 ABI. Common code would
need to adhere to the common assumptions only. Arch-specific code can
work from the more tight assumptions. (If future sub-arch variants are
to be expected, like RV128, arch-code may still be well advised to try
to avoid the more tight assumptions where possible, just to limit
eventual porting effort.)

Jan


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 07:55:29 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 07:55:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695768.1085829 (Exim 4.92)
	(envelope-from )
	id 1rmqnI-0003FO-82; Wed, 20 Mar 2024 07:55:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695768.1085829; Wed, 20 Mar 2024 07:55:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmqnI-0003FH-4c; Wed, 20 Mar 2024 07:55:28 +0000
Received: by outflank-mailman (input) for mailman id 695768;
 Wed, 20 Mar 2024 07:55:26 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmqnG-0003FB-PR
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 07:55:26 +0000
Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com
 [2a00:1450:4864:20::12d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 353f1931-e68f-11ee-a1ee-f123f15fe8a2;
 Wed, 20 Mar 2024 08:55:24 +0100 (CET)
Received: by mail-lf1-x12d.google.com with SMTP id
 2adb3069b0e04-513ccc70a6dso10959953e87.1
 for ; Wed, 20 Mar 2024 00:55:24 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 my10-20020a1709065a4a00b00a46268fce59sm6974727ejc.165.2024.03.20.00.55.23
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 20 Mar 2024 00:55:24 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 353f1931-e68f-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710921324; x=1711526124; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=pnC7FoDC6JS3mHBc5RDFcwLKNNOSMD1dWsTZHLrcoZ0=;
        b=AhHomp98LynDzlv8N9xer/Hq/NrnDqs2dONJ1F7q6Y1jotAGtoA3+4YgKY16zyuB4b
         pLLmoi8/u1V3OcrDO8dJfivV+id9xMWbd+604G0V72pceMtd1HQjz8eV2PKgmtsxrtXC
         beriPyfJX6E6sbh9wSE9GH/HGr7SCoI03bWp89GDuMjkXDuDtdu97je9A17hJrK85AMZ
         j5IIGQX+3M4tTa5TjZXP8h9IIYyMRxlXQ/vje6Xdja4NIE/V0gGtRjyVkt29Oc+FTS0P
         b3m6PZAPKuXSnJ4RAQuKnRTjbWVsWEvQ6NRulb1KPQuz21urWtz6N03XF0Ym09Rilqtx
         jgzA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710921324; x=1711526124;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=pnC7FoDC6JS3mHBc5RDFcwLKNNOSMD1dWsTZHLrcoZ0=;
        b=tNbxr2JLI1zxH+OKlb4h9TsfWWTVPoPROA8dshAF7yIzWp/vouJqS6y/dOL7Ns/1hH
         ZUwkoATk5rn42Sv7HGKf/g4J/X11h2bl8/Jy0RUJ8tLC1cRJ52EWk3V5h2G3TYMqPDot
         MFC09Gn28F++/+Vcpz3gMo8jQyEERrIwkk8iIDlAUq9jBalphr7lvFE2ZHUoxISOz0Eb
         a1zeempS33oi1TY7qJNKPO53YBLDuHgDNZLA6IA/0zhL2Ky4e2/BKjlAmYF8U7CZF5ur
         140e9awoFmTOb4o+6fsYSmnZulXl1iUI2KvuAyqbwOvlEm6UW5R8eacuCfbEfp1Mxg68
         nYpg==
X-Forwarded-Encrypted: i=1; AJvYcCXFandsltQDSLT0iotXGZmfnk4UGXmnhwCCk4/T4/kmC+5+KO7KT3m1dVZgbSdSSS1wuZ6fXpoqbiW9Bh5bxn2gHRjyDcYuLtiZikEBkEo=
X-Gm-Message-State: AOJu0YySWsPj2/KfdWAq/z9Dg8j7d7+zNvrnPTnBkl7UTKAUWQqsmpIr
	7hvNAYD+SG4DvNmo6xo0ufmfwamwf0caiREXoEmEWwqT2GGnx3JDyBIxyXVBQwmdEbKijAAS7A8
	=
X-Google-Smtp-Source: AGHT+IFGbZ5KbTk8kfo5oTW2S2PsRAzV+aFOmreCnx2mtnvtMVXbF60bUQvwMkUsPivLOwq0rfHJ7Q==
X-Received: by 2002:a19:3852:0:b0:513:cc7e:9919 with SMTP id d18-20020a193852000000b00513cc7e9919mr9121657lfj.7.1710921324319;
        Wed, 20 Mar 2024 00:55:24 -0700 (PDT)
Message-ID: 
Date: Wed, 20 Mar 2024 08:55:23 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH v2 0/1] tools: init scripts: Add missing
 XENCONSOLED_ARGS variable to xencommons
Content-Language: en-US
To: =?UTF-8?Q?Rafa=C3=ABl_Kooi?= 
Cc: Wei Liu , Anthony PERARD ,
 xen-devel@lists.xenproject.org
References: 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 20.03.2024 08:48, Rafaël Kooi wrote:
> V2: Now without test emails ending up on the mailing list. And with the
> correct title prefix.
> 
> I noticed that the systemd services referenced the XENCONSOLED_ARGS
> variable, but it was missing from xencommons.
> I actually ran into this when experimenting with a Qubes patch where I
> thought I needed to modify this variable. It turned out to not be the
> case, but I figure it's good to include this for sake of completeness.
> 
> Rafaël Kooi (1):
>   tools: init scripts: Add missing XENCONSOLED_ARGS variable
> 
>  tools/hotplug/Linux/init.d/sysconfig.xencommons.in | 6 ++++++
>  1 file changed, 6 insertions(+)

Two further remarks: Patch series want to have the patches sent "in reply to"
the cover letter, such that the whole thing appears as a single mail thread.
For singular patches, generally no cover letter is required (thus avoiding
the question of threading).

Jan


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 07:59:52 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 07:59:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695774.1085839 (Exim 4.92)
	(envelope-from )
	id 1rmqrT-0004h8-Os; Wed, 20 Mar 2024 07:59:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695774.1085839; Wed, 20 Mar 2024 07:59:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmqrT-0004h1-Kx; Wed, 20 Mar 2024 07:59:47 +0000
Received: by outflank-mailman (input) for mailman id 695774;
 Wed, 20 Mar 2024 07:59:46 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmqrS-0004fI-A0
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 07:59:46 +0000
Received: from EUR03-AM7-obe.outbound.protection.outlook.com
 (mail-am7eur03olkn20800.outbound.protection.outlook.com
 [2a01:111:f403:2e0e::800])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d0bb85c8-e68f-11ee-afdd-a90da7624cb6;
 Wed, 20 Mar 2024 08:59:45 +0100 (CET)
Received: from DU0P192MB1700.EURP192.PROD.OUTLOOK.COM (2603:10a6:10:3bf::6) by
 DBAP192MB0874.EURP192.PROD.OUTLOOK.COM (2603:10a6:10:1c3::14) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.7386.29; Wed, 20 Mar 2024 07:59:44 +0000
Received: from DU0P192MB1700.EURP192.PROD.OUTLOOK.COM
 ([fe80::181e:3628:177d:1cf9]) by DU0P192MB1700.EURP192.PROD.OUTLOOK.COM
 ([fe80::181e:3628:177d:1cf9%4]) with mapi id 15.20.7386.017; Wed, 20 Mar 2024
 07:59:44 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d0bb85c8-e68f-11ee-afdd-a90da7624cb6
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=HNvhJBdQu216tyXQ69qSuUMI/vqq9uO7+CBTcn0jD5CbPbgW9zFuGXcyTDQy7y3yqaPPcfFeoOV0JMsG8zoXYN+HXOYlW+ilcJgSLwWEHSDg3zdSLFI9pPwoU0PjoeDfLbpsfp3hRb8K9VKeGEOCVVXLVO7voxGGRsmSpCb9IFZehY82DR3IF7xRHAA6C9LkwphBfV5uWgb7ZGqHA9NnObZnAroMi2sgGXQE/sUUZQscLa+sQygpDThm+V9Z2hVZEn3tYcwKQERnW8DAcZe3Mm3AKqqwrRzGENv1PQKCAD2z7HCLUyau6yfTbRrZPNiQGlfx4/ZDi1SV92guXVCXcg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=FJNgPfgCjWQtDCDawue7cOj8VGYfozd4SWGE1P7Rf4A=;
 b=NgvQpowl3k+1ujp3aVyL1bXZ3QCEEoz2EffUQJoKFZrBPaALyqeSPPmt16KioiEH1u9Mf+MPhuIab6APh1ZYqDzexCPLHEpUxDTgQslqAwYFdo/JiUdsxT2x6krTnDMeKFuBqTFNhrxfRmlfGSFeUo/E8zF5K4jodXEYGfWjrxanzoQwVH67s1ik3cyxyElORPMoTUgeTKnCHvVh4WyUlmZqO6udyZFii6Oq04dvNadfdUed5Hy6cGAMYwBn6FP5D7NrjVcYzUSVRDS62tUk6K92gI8TpJ/hzHKKqn4BB1ZpO95HN4J2l1cYPmLM9r8mTP1qbFpOiMhn60entS/Rrg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=FJNgPfgCjWQtDCDawue7cOj8VGYfozd4SWGE1P7Rf4A=;
 b=QrlIY1lW3ecDlrz2i54Evs2TzANM+lXaPo8PAveKTxMQQnFUvpbEPANK/RhBLsZLP9ROYP02WpmgOqW0RfXq4YgNQ0D3H2T6EjYXT6HbIulgpUVLTzH4p4f1diDnTk5qdh4eROVzrs7+1bBGfIj/bDx8uqHeewoUfkgqyaoxL14torhc7s7C0U3G9QDnp+4IvVJYA7ks1jFkoH9fRtx8TAmyZun1vcvRZVQTsaJHR/CgzjDhvaBZ08zXg649vO7406oz1ovXZ3nwebw7I43Z6u+Yrp9rcw/hD/89STm/F5CQW6xAYOVpcJ7R12kxCml1K/Rx4P5rs+SOKsweLa5boA==
Message-ID:
 
Date: Wed, 20 Mar 2024 08:59:42 +0100
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH v2 0/1] tools: init scripts: Add missing
 XENCONSOLED_ARGS variable to xencommons
Content-Language: en-US
To: Jan Beulich 
Cc: Wei Liu , Anthony PERARD ,
 xen-devel@lists.xenproject.org
References: 
 
From: =?UTF-8?Q?Rafa=C3=ABl_Kooi?= 
Autocrypt: addr=rafael_andreas@hotmail.com; keydata=
 xjMEZHDtHhYJKwYBBAHaRw8BAQdA4C7O72UZHQbhHNm1BUkAM/7+KQKN3tupyuGVGyj2dIHN
 KVJhZmHDq2wgS29vaSA8cmFmYWVsX2FuZHJlYXNAaG90bWFpbC5jb20+wo8EExYIADcWIQTv
 ioHnE84MxV6adj/iFi3SALEToAUCZHDtHgUJA8JnAAIbAwQLCQgHBRUICQoLBRYCAwEAAAoJ
 EOIWLdIAsROgP80BAKeJdh3YQ5l3gxGp8R9wIvN9Ac3vsMfy8I4kZ6TXksLKAP9vLRV4G3yw
 z7/seKhWc27Jjl4uI/+lIWhWaWrUYZmjAM44BGRw7R8SCisGAQQBl1UBBQEBB0DE61lbAezY
 NhOlHgxdZ9V4klIhSajeU50O8wHIPQnCLgMBCAfCfgQYFggAJhYhBO+KgecTzgzFXpp2P+IW
 LdIAsROgBQJkcO0fBQkDwmcAAhsMAAoJEOIWLdIAsROghHgBANU4dj+WnuSaWemAHVkjERJg
 m0FQpmZzNI8hdolS3gYdAP9zGK65ilpHMDj4pGvfALabruZA4NPJYxSqeamHvOuhBA==
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-TMN: [o2Dv5Cz0zieNe8+srK0KuFvfaFQ3QvGOMg3mTlLxnq1g+D8sVAJjZ5X813uNsM0v]
X-ClientProxiedBy: LO2P265CA0308.GBRP265.PROD.OUTLOOK.COM
 (2603:10a6:600:a5::32) To DU0P192MB1700.EURP192.PROD.OUTLOOK.COM
 (2603:10a6:10:3bf::6)
X-Microsoft-Original-Message-ID:
 <5e10fb09-12a2-4500-85f5-de0b2140405a@hotmail.com>
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DU0P192MB1700:EE_|DBAP192MB0874:EE_
X-MS-Office365-Filtering-Correlation-Id: 98be0696-29d7-4e6b-c2d6-08dc48b3b42e
X-MS-Exchange-SLBlob-MailProps:
	YfhX3sd/0TVoUMj8BWYCuE6LiLTPpwRJv8uizpVsrIErp2ChADy58sPN0I79IB8IhVmfPFaxHKUrIrswQjSqkUWXlqdymPeuf9Ev6+fJ613+82ZFj38jCVNXhCuns11ct/31fl4XCiRw73QGdMXlYWkse3UiDp1UpNovnfAulGYy7fcjkZcSz8MRdJF7ekgFpu2M2vLUm9SqgtWihlqppOFIdyuMyr2h17BWwUpv70xgtNFKWVvRbYir+/vJ5ul5oshbVqokjZVd6Df6VhfGcDy8HOwksSBuPIwRoaXVCEsoaQ7YoPy2LbC0BK6fCwvdbR1aWp+RELb71Fd2YH7CuCaAxd+TfZN+37lsAHDkAMc6lJxTiQn3f7jx8M9EjwqDSIjMMl1tOtkr1dZ15OCFc1sYI8t/s1lMTQwhQqR4VniG8MfS8aJs8gSbz3PYg8L83n5CqlLBEI7RMkwkSElVif/T0cWB8eVOcEn4n35iYjLQSi5r8YplWVwwpAJujsjICXW/p9i+hUcz6gXObe/EwGBLAE06lMY9M55K5VRoejsnqc1ugslhLnKTfjIr+cknIqR4CQtArJ/TTJjf+0mdzlNq3yxOk7b1GqUSnC5W3Q/i2akMNlEF+jNhs+wIU2KUfFae2Sl1m5Lvowyk5eJOjgkLjyX8TLcQAOAX/bspZnHw6LOL85OU9mCCRuDx6mWsrlb99WZV+qeexMjiPc7vHmdD8uKOLgDamupfIpPR9ZIrfY+MjrNUbQ6pTfRkWA7NNHTiK5OTZq1wNb4gIRK6gNgfNOxOLvRlq77FKkqZqmw=
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	sWaOgCfOaJrc0owJgYxbPNI3V1y6wXtOQkkChsZ2MIt/DHv6ysyGStZgZl2JdhkA5Fqg+M5w/BMTeiShRagQnr4zM8wAgz7Xfy2R8jErBJDVMKlg0SEbq82WiLubRZ311IIf+kfo+LKn0uSpuzu3sHXBQYieODQK40RHYPjBnsSffJqDCnaa8Ld7Jt/XG0a2Zk/6CJt/d6AbQ9tpX216kwJcLtDmK2lyFx2yJpVgeysCIclsGyVwFGNv1VdT7eZAvshI7jL5WECIRbFpR3A8qNw/+k3V4uc4OxN9MnqyEJIKxDeGH7QGSgBNUkVnFDhvGHX3gxFOf3g+1MeDXWy4ciUxaVMbVIjXBAcFS/QooDRWwmrSuVBe2z0FxFkdzjGNf5mrXisjgpeZjOCSVuifclqdsii/UlopJQwAeXf+YWyagd+pYjayUNZmA56w/H9LW0ZKOiNe3WEwTq3HakVB9KJD8xcK62opmvFdg8HM8o/BkesengOuicjjgr1TFXAYqJymt4OcJt0Z1HB8tw4zM1YjyZvKRN1qrjZCIGMjtdfZif5iRFokNx7cpy+TpsxT
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?R3RGcm1qL3krS3htc3pxUDFwUWE2aGZ1QTlTYmw4QXJ6dzNJQllzYmFVb0RN?=
 =?utf-8?B?blFsZVJyMGlZQjBtRlFXbVlEQ1lxVFNLWlVJYWhLVk84V2cvN1Z5ZDl6dXdG?=
 =?utf-8?B?VGkxUGhCOWh4TXVtWElLakxXT0JnZklBOWhjOXRHSEpTY2o1YTVLZTMwMDJ2?=
 =?utf-8?B?enArcjVWRXJGQ1hSdFgxU0RqMk9WQnA3dkpZY0pRVUlFR0dCdzhLNko2aFBP?=
 =?utf-8?B?M0NtSC9xSlRMMSsvL3duL1pLSWUraWd4c1BhMGJIR0VIM2pYaUxhQWdOM25s?=
 =?utf-8?B?ZDhoWnJZTDlOZ0NYeDBWUjZLZ2xkUTRjNXFUNXJyUzFMclRScVBzV1hYbHZ1?=
 =?utf-8?B?clpWWmVOdGlFQVA5cDhJb2c1alpNa0JwREd4cUt5ZkRWTURVVFA4b01YUnhO?=
 =?utf-8?B?bkc1anRwVVNHc0syVEg3cXV2R3Q0dFBEZlgzaHZVOExPNGJ0d2FkL1Y5bDVv?=
 =?utf-8?B?TElrb0wyamVHOVd3Rmd6VXk2QWdtdnlVcERqQWl4RE1XeTd1cmoxTGcrS0Vz?=
 =?utf-8?B?Z0ZaNlB3enFob25zV25NbEFHVUhGUGxwdy9HZkh0RWpDZkRPM2dnUDFtUVJG?=
 =?utf-8?B?Yy8xdHdDZzJMUkF6dVJnRS9PbzlRN24zTzdHVHkzbVFoanpLV1BKbEplVjlB?=
 =?utf-8?B?ZWZHZ0hKSE1CL2wyWWRCZGJ1L2x2ZG8vRTNtUzMwVHVpbXA2Q2JJdDJWdWdo?=
 =?utf-8?B?SlU4UE5RNTZJNEJVOGtZOTRwNG1yOUdjUXJZdGZoalVweDY4MkZqYXhHUGM1?=
 =?utf-8?B?N3NucTBtUXlGam5SVk52dlZmWTVhclhhekI0VFVOZ0xqVDdVU3R4Zm1xQUwx?=
 =?utf-8?B?SUZ0UkZjU0xUQm5lUTY1NDVkZjNTT2t2ejNmc3d6Tmd3ZnNnMDB6bmtEaWZB?=
 =?utf-8?B?TkVHQlpnR2pObkJlS1dDSDVUaVVnRzRLYmpIc0xqLzQ1Q1hUZFpKRnZrNkdP?=
 =?utf-8?B?T1BuZmZEb0UzclVDbmtvZGpZNndlTVFEZUJNbkdobnZqSDZYQ0puc3JDZ1dz?=
 =?utf-8?B?eVI2UVlnY2p1dVU4djNFdFZoaXZuaTZ3bmg1aTZsMGxxOFhlSlVTdmx2bUtJ?=
 =?utf-8?B?YVVPT2t5QnFSaW03emJpaXNxS0xOOVJzK0Y5U3hQbHNRRUZBOGVlVGprTTFR?=
 =?utf-8?B?TWtoNGtVczVybE5qL1lObk5HVWFEVkZoWnVEMVVzSzk1cTFrRjRNNEF2NHdS?=
 =?utf-8?B?eU5EVHdKcUtKQlF5cUVidjJDY0IxYzJoRmgzUW5vWkEvMW8zVXo5UW5ZOG53?=
 =?utf-8?B?bFdrejcvT2tnamp6TnhKSHRQRndTeWZaVzFYM2MreFdlVHlJelNBNjF0SzJG?=
 =?utf-8?B?N0h2TEg0K2tGb2FaRk5mNlRza2tEdWRQRzIzRWQ1NXJZN1oyRDlUWHJ1NlRn?=
 =?utf-8?B?L1plTHpybi9HS01lR3BSNVlJdjh5WDB1NFZSbktqK1NkbG1IU1hrbXp5NHJP?=
 =?utf-8?B?WWFLbWxoSkxtcHltYXdXM29hVWcxN1BkUVdSR1ZFQldrRE0xaWo4SnV4OGpU?=
 =?utf-8?B?WjhsbmwyZnV5c1hNQmZyZjRrWnJEYmp6ZmJZa25qQTh0YnkrandXSlZiZm1w?=
 =?utf-8?B?cklhR2hkcDdZOHZQbTZyd0N1c2J1aEZOUmx4RHVwcGJYd0VRWHpDT1V2cUd4?=
 =?utf-8?B?OGFpb1JWVG1CNnpmdXFvRTJUUk53VkJBckhYZURNcXZuZUxSWE5FYVUrbXpC?=
 =?utf-8?B?ZExiTzBrLzJYMm85dDdkVjJOQUZqNys5R2cyOVNsNzdtb0FBaUUramdYcUJE?=
 =?utf-8?Q?aEljFMACTg44JifPpmRNFjJ7jg5ebadIXTQb+sf?=
X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-fb43a.templateTenant
X-MS-Exchange-CrossTenant-Network-Message-Id: 98be0696-29d7-4e6b-c2d6-08dc48b3b42e
X-MS-Exchange-CrossTenant-AuthSource: DU0P192MB1700.EURP192.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Mar 2024 07:59:44.2235
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg:
	00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBAP192MB0874

On 20/03/2024 08:55, Jan Beulich wrote:
> On 20.03.2024 08:48, Rafaël Kooi wrote:
>> V2: Now without test emails ending up on the mailing list. And with the
>> correct title prefix.
>>
>> I noticed that the systemd services referenced the XENCONSOLED_ARGS
>> variable, but it was missing from xencommons.
>> I actually ran into this when experimenting with a Qubes patch where I
>> thought I needed to modify this variable. It turned out to not be the
>> case, but I figure it's good to include this for sake of completeness.
>>
>> Rafaël Kooi (1):
>>    tools: init scripts: Add missing XENCONSOLED_ARGS variable
>>
>>   tools/hotplug/Linux/init.d/sysconfig.xencommons.in | 6 ++++++
>>   1 file changed, 6 insertions(+)
> 
> Two further remarks: Patch series want to have the patches sent "in reply to"
> the cover letter, such that the whole thing appears as a single mail thread.
> For singular patches, generally no cover letter is required (thus avoiding
> the question of threading).
> 
> Jan

I don't understand why it's not present on the mailing list, the
"In-Reply-To" header is present in the patch file. Maybe outlook is
stripping it, I'll have to look into it.

As for the second point, I'll make sure to keep that in mind.

Thanks,

Rafaël Kooi


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 08:11:50 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 08:11:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695782.1085850 (Exim 4.92)
	(envelope-from )
	id 1rmr2v-0008Ll-5X; Wed, 20 Mar 2024 08:11:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695782.1085850; Wed, 20 Mar 2024 08:11:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmr2v-0008Le-19; Wed, 20 Mar 2024 08:11:37 +0000
Received: by outflank-mailman (input) for mailman id 695782;
 Wed, 20 Mar 2024 08:11:35 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmr2t-0008LY-Pk
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 08:11:35 +0000
Received: from mail-yw1-x112f.google.com (mail-yw1-x112f.google.com
 [2607:f8b0:4864:20::112f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 77369291-e691-11ee-afdd-a90da7624cb6;
 Wed, 20 Mar 2024 09:11:34 +0100 (CET)
Received: by mail-yw1-x112f.google.com with SMTP id
 00721157ae682-609f060cbafso77308957b3.0
 for ; Wed, 20 Mar 2024 01:11:34 -0700 (PDT)
Received: from localhost ([85.31.135.62]) by smtp.gmail.com with ESMTPSA id
 cj5-20020a05622a258500b00430b9aecf7asm5161601qtb.40.2024.03.20.01.11.32
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 20 Mar 2024 01:11:33 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 77369291-e691-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710922293; x=1711527093; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=owEYcVK3rZp2I8kR5h1MMWipU/reZain9WHPFoHFS94=;
        b=ndybDDrYzniHt2UV3hz62Ev+QnSVLuHrVSBjKgcBfichWFhycKdKMEBJaRL88PoCs0
         Qj4msbnN9VNa0XvfIEwMjWyoy2aLt9X3gizV/fKk85vhAxdQ9iCVUoB9+/x0VYjw/2Y1
         5qkDit4eRuKkZoaLkdbLfPNNZIwshbJ0/cRjA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710922293; x=1711527093;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=owEYcVK3rZp2I8kR5h1MMWipU/reZain9WHPFoHFS94=;
        b=v89CQ3XYJuL08sryYoM5lqDDeEScqjjVELY4SR8IZKeCs52fByuqyvo0VSV5GkhlyD
         54SZmuJnWpMTEEoX+vrnE+XyVDoJF7F1f/sJ9ahKiXVWu4A+lrb9fVM2p0nkKO8Avnyc
         8wAoRYSg3WFIUX+nZQnscynLBRZn6/dKISIaOEhBb1jppupJZbdw4v7WQToP90VWzQKN
         fSL1c1MPTLXgRZ4QD0VvSw0cJj0p0qUyLmJgHfzY9xR01JHXkzYLpS1M3ITJeNbNaK3W
         DKOg8GdAEGqkhswpHnsw5TpWpuogiou7zFj2+fNmdTFBKmLaR+bBFxs/yZ+dUeWQTh1Z
         FeCg==
X-Gm-Message-State: AOJu0Yy/WYdrWXv9BrOQED4mivYCIqYH2UHRWzFvbs0gvggJ24nSbNQJ
	V6rh3UCojl8cLV+lysUYQGyiUdpSCZQJ6Sd6uzMcRbLGCuiLZ2HQUxxWb2/0rKL8WAhrWnwgkiu
	c
X-Google-Smtp-Source: AGHT+IH6lf1tqCwS9FlI6S9Ko/Gwnt551R7ltqkgYcGhdkYHDR0IcwErxKwaZzzGUx7QFGolIi8oug==
X-Received: by 2002:a81:ae05:0:b0:610:e1f5:64d with SMTP id m5-20020a81ae05000000b00610e1f5064dmr4120479ywh.23.1710922293390;
        Wed, 20 Mar 2024 01:11:33 -0700 (PDT)
Date: Wed, 20 Mar 2024 09:11:31 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Andrew Cooper 
Cc: Xen-devel ,
	Jan Beulich 
Subject: Re: [PATCH] x86/mm: Refine address alignment checks in
 modify_xen_mappings_lite()
Message-ID: 
References: <20240319195856.4172284-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20240319195856.4172284-1-andrew.cooper3@citrix.com>

On Tue, Mar 19, 2024 at 07:58:56PM +0000, Andrew Cooper wrote:
> Require 's' to be superpage aligned if given over a superpage mapping.  This
> is expected to be the case in practice, and prevents the v getting misaligned
> over superpages during the processing loop.
> 
> Rmove the requirement for 'e' to be page aligned.  All this is doing is
> forcing work for the caller just to satisfy an assertion.
> 
> Reported-by: Jan Beulich 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Roger Pau Monné 

One suggestion below.

> ---
> CC: Jan Beulich 
> CC: Roger Pau Monné 
> ---
>  xen/arch/x86/mm.c           | 10 ++++++----
>  xen/common/virtual_region.c |  8 ++++----
>  2 files changed, 10 insertions(+), 8 deletions(-)
> 
> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> index 62f5b811bbe8..018d21f8bd92 100644
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -5900,9 +5900,9 @@ int destroy_xen_mappings(unsigned long s, unsigned long e)
>   *
>   * Must be limited to XEN_VIRT_{START,END}, i.e. over l2_xenmap[].
>   * Must be called with present flags, and over present mappings.
> - * It is the callers responsibility to not pass s or e in the middle of
> - * superpages if changing the permission on the whole superpage is going to be
> - * a problem.
> + * It is the callers repsonsibility to pass 's' on a PAGE/SUPERPAGE boundary,
> + * and for there to not be anything interesting in the PAGE/SUPERPAGE
> + * following 'e'.

Instead of mentioning 'anything interesting' I would just state that
'e' will be extended to the next page/superpage boundary:

"It is the callers repsonsibility to pass 's' on a PAGE/SUPERPAGE boundary,
note that 'e' will be rounded up to the next PAGE/SUPERPAGE boundary."

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 08:12:07 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 08:12:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695783.1085858 (Exim 4.92)
	(envelope-from )
	id 1rmr3P-0000SR-BG; Wed, 20 Mar 2024 08:12:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695783.1085858; Wed, 20 Mar 2024 08:12:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmr3P-0000SK-8h; Wed, 20 Mar 2024 08:12:07 +0000
Received: by outflank-mailman (input) for mailman id 695783;
 Wed, 20 Mar 2024 08:12:05 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmr3N-0008LY-N0
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 08:12:05 +0000
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com
 [2a00:1450:4864:20::52b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 89923dd7-e691-11ee-afdd-a90da7624cb6;
 Wed, 20 Mar 2024 09:12:04 +0100 (CET)
Received: by mail-ed1-x52b.google.com with SMTP id
 4fb4d7f45d1cf-56bb5d61c5bso147419a12.3
 for ; Wed, 20 Mar 2024 01:12:04 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 cn25-20020a0564020cb900b00568c3a2f4f8sm4387488edb.74.2024.03.20.01.12.04
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 20 Mar 2024 01:12:04 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 89923dd7-e691-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710922324; x=1711527124; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=/CGxf3MycNptbTWncpX1giDQU+gSfOXIouCwo19AQUo=;
        b=XCermbZT4SCmbxM6Zi+emZbhhOVr6ZmR2kUNp/N9Cyefr1uhOkSuss4SDo05Prb+mk
         jNAoNRQeoenOZ3WhqL3Jhj/aj3xvsRlEOScFG9jRfxzKM0lEyd7EOreblZdbxi0YYjXd
         //LhzA9DpJOZTBLP65Qh6Bc9gd6paPF1XeuBmI2iu1wzqWXWNnhRFG2OBd8v4J0PJHIV
         rYQTch4LsjWFXVu+Qb+8t346JbT8dFbE6LSdsidTmjk2US3Ad87l3Z1e7K9vYPriyFa7
         JmKgPI8aIhg/WS0fZGXeiLo0gaJtZ8RKjhrESxQp+QdKE7infcjNXHfcaEIuaN9VI/Ft
         wFmA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710922324; x=1711527124;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=/CGxf3MycNptbTWncpX1giDQU+gSfOXIouCwo19AQUo=;
        b=oxJ4ZRAz1YN9doK99Lrxtk0Fj/3f4Y+PvY/uprZ2q3efjios4xo1umKeiOrx0dnS5l
         ad5iYnNJUTKNQRF0/3wOHQ3oQ0R21gvupk5zBRY67fgz88ouiM7j1vPZkN+P46NFojlF
         ZY36UweljwfuRCqvuRq66kpU2kVz10iNxhDdJFxn3h93N4zLYPSE2/fVYDbfPptq5QdB
         9NNPaM2ueslSE6kwF6WGnUGRde3YiH+ukFKv/PuKThl5d6l3lKDZGaEgc8VF6z1UwGHq
         b3Yi+yIz34SHz/5iQ45mi2SFas3KvsRdzaGL5KXjwH4IYULRjChKn62jpPWJv3gtx1mb
         TKtg==
X-Forwarded-Encrypted: i=1; AJvYcCUDuRtvaCSSsLUfUj0Dm7TxsEXy/ha9TK/XZ5F3l1Tml5bVRQdLPcGuwHXyjmFqSSzf44Jiy1SUi6l+K4xUJtLCHZFbIhFPUr3t03HhQKM=
X-Gm-Message-State: AOJu0Yy4Gizw/TVANUw6y5u8HumTKPH2ABGrj3SQ3ellRc3iuGdhJTJ4
	iUaxBtNYCO5xopj1JrdNvjs0Pns1EjqnJVTIFukmK/mtqlvYOUHOmjY2THC0UQ==
X-Google-Smtp-Source: AGHT+IHkaX6ndr3rADLs8AsbvcWPacZ76T78O6OKZbga7mD21DLVR9sdWIe8mf952tdfcX2Ge5Tfug==
X-Received: by 2002:a05:6402:159a:b0:568:9fc9:ec72 with SMTP id ij26-20020a056402159a00b005689fc9ec72mr780372edb.35.1710922324453;
        Wed, 20 Mar 2024 01:12:04 -0700 (PDT)
Message-ID: 
Date: Wed, 20 Mar 2024 09:12:03 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/features: More AMD features
Content-Language: en-US
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Xen-devel 
References: <20240318181332.3817631-1-andrew.cooper3@citrix.com>
 <8eb3d0d4-daf2-40a4-83b6-d3726e02814f@citrix.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <8eb3d0d4-daf2-40a4-83b6-d3726e02814f@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 19.03.2024 18:40, Andrew Cooper wrote:
> It occurs to me that I need this hunk too.
> 
> diff --git a/xen/tools/gen-cpuid.py b/xen/tools/gen-cpuid.py
> index 25d329ce486f..bf3f9ec01e6e 100755
> --- a/xen/tools/gen-cpuid.py
> +++ b/xen/tools/gen-cpuid.py
> @@ -329,6 +329,10 @@ def crunch_numbers(state):
>          # In principle the TSXLDTRK insns could also be considered
> independent.
>          RTM: [TSXLDTRK],
>  
> +        # Enhanced Predictive Store-Forwarding is a informational note
> on top
> +        # of PSF.
> +        PSFD: [EPSF],
> +
>          # The ARCH_CAPS CPUID bit enumerates the availability of the
> whole register.
>          ARCH_CAPS: list(range(RDCL_NO, RDCL_NO + 64)),
>  
> 
> To cause EPSF to disappear properly when levelling.

What exactly is wrong with exposing EPSF when PSFD is not there? (The PPR
I'm looking at has no mention of what exactly the bit means, and hence
whether e.g. it indicates PSFD can be avoided in certain use cases.) When
leveling across a pool, EPSF may need hiding, yes, but that would need to
be a result of admin activity, not by introducing a fake dependency. Just
consider a pool with PSFD supported everywhere, but not EPSF: The admin
would then still need to take action to make sure EPSF is uniformly
invisible to guests.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 08:31:37 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 08:31:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695791.1085868 (Exim 4.92)
	(envelope-from )
	id 1rmrMA-000502-TD; Wed, 20 Mar 2024 08:31:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695791.1085868; Wed, 20 Mar 2024 08:31:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmrMA-0004zv-Pz; Wed, 20 Mar 2024 08:31:30 +0000
Received: by outflank-mailman (input) for mailman id 695791;
 Wed, 20 Mar 2024 08:31:29 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmrM9-0004ya-AV
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 08:31:29 +0000
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com
 [2a00:1450:4864:20::629])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3e3c877c-e694-11ee-a1ee-f123f15fe8a2;
 Wed, 20 Mar 2024 09:31:27 +0100 (CET)
Received: by mail-ej1-x629.google.com with SMTP id
 a640c23a62f3a-a46cd9e7fcaso328270966b.1
 for ; Wed, 20 Mar 2024 01:31:27 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d26-20020a1709067f1a00b00a46a643b6fbsm4925045ejr.15.2024.03.20.01.31.26
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 20 Mar 2024 01:31:26 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3e3c877c-e694-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710923486; x=1711528286; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=EKJnFkvSNBPT334XIQUQeW5rAknaRr4uKjD1bF7fAHs=;
        b=LnoFC/Ks+IUbYWWqkKpQsUeLV7EFKHHyCg/E1pgFBZ3z3IJy6owYYbF4whbD+FX7mC
         rCco2qaCxF0IK0+0ceCDZI7RjZ4O6F0+TstWsUhR3c03LslqvuDQc6/jbkJ3Nk6O2bnx
         mqSO6VhxQzzDCu3bUM/+GFSnjlml5P8kEFJUbWY0Xg8/UuGe0SG5ebiLT06RXglPH2wq
         l0+oFnwVOGcuPvUNsXRnGXTipXQTeKKEcPP/zyNlOyjN6M5ZdPeemK/pMpMH/UVNdJga
         FNNQmtEwGK83IJE721BFTRWNwBNg9fwJZm4Axp1+MmPstXTs0y6GUUPkOAyF5HZ+X447
         /guw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710923486; x=1711528286;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=EKJnFkvSNBPT334XIQUQeW5rAknaRr4uKjD1bF7fAHs=;
        b=QgWs0VYk+h6HZPp1AWQrFZgsE5EKW8vix6FansynKoCtdhEIIsXOYEq6zuDeAieRvF
         widtLFd4HyYIpd6xjqRbrxbz15GM5AXRAYkEeP9rvld7+EzhluU4NIadawu44NDepyCq
         aIWM81r4DXJWTyJq85jJkpkJ4U8ofDxwvApHrLMvL8Tju2NwxSUBO7wLMSo7rg9ZdA+p
         XVMFsdO7bC31/d+v1EqTulKwSxjMAXyfNIS9m4oPi3c6wP+47azxaM2HO45i8eQNBA25
         hQVzVCLu6B9zuSvSkou29rtxgyHR7p1JcWCt+porn0gLvrZlRMNTp5ahBSQ3jIWRZv61
         0B2A==
X-Forwarded-Encrypted: i=1; AJvYcCWtr9oAdJcofpT3XyuZEJZS8bWnntDRVyrprzrrmc3czATL1rwAb4AykTqTJCTKiTLUv5ST+YHXnF4gPan9GL7Tw5J7SMpnjIXuyNwjdRM=
X-Gm-Message-State: AOJu0YxgVZxHTA9MGgPdOb556bX5uVCJNLZwzhlb509MCnxUyRXmkrPp
	up0Yt7/BdvaAzKxLTd5xCnSocRsY8WN2qlkamaoXTug6AVf3cYIO77vglC5DZg==
X-Google-Smtp-Source: AGHT+IH5v5P8qSn3E3i459hTEuflbj722KEwbN+Tg9NvRSGUzCYTzjv4V0dBXFyAm4HTP6HRXJG/vA==
X-Received: by 2002:a17:907:111b:b0:a46:d61f:c561 with SMTP id qu27-20020a170907111b00b00a46d61fc561mr791049ejb.27.1710923486499;
        Wed, 20 Mar 2024 01:31:26 -0700 (PDT)
Message-ID: <45ab1427-dc17-4881-9941-6372d2e23107@suse.com>
Date: Wed, 20 Mar 2024 09:31:25 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/rwlock: Don't perpeuatite broken API in new logic
Content-Language: en-US
To: Andrew Cooper 
Cc: Juergen Gross , George Dunlap
 , Stefano Stabellini ,
 Julien Grall , Xen-devel 
References: <20240319113020.3843309-1-andrew.cooper3@citrix.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240319113020.3843309-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 19.03.2024 12:30, Andrew Cooper wrote:
> The single user wants this the sane way around.  Write it as a normal static
> inline just like rspin_lock().
> 
> Fixes: cc3e8df542ed ("xen/spinlock: add rspin_[un]lock_irq[save|restore]()")
> Signed-off-by: Andrew Cooper 

Notwithstanding Jürgen's R-b I'd be quite a bit happier if (a) this and
spin_lock_irqsave() remained consistent with one another or at least
(b) the implications of doing the necessary transformation for the
latter towards Linux compatibility were visible to have been considered,
in particular with it in mind that Misra won't like

#define spin_lock_irqsave(l, f)                               \
    ({                                                        \
        BUILD_BUG_ON(sizeof(f) != sizeof(unsigned long));     \
        (f) = spin_lock_irqsave(l);                           \
    })

in linux-compat.h (and obviously with xen/spinlock.h included ahead of
this).

Jan


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 08:35:16 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 08:35:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695793.1085879 (Exim 4.92)
	(envelope-from )
	id 1rmrPn-0006Da-C2; Wed, 20 Mar 2024 08:35:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695793.1085879; Wed, 20 Mar 2024 08:35:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmrPn-0006DT-8K; Wed, 20 Mar 2024 08:35:15 +0000
Received: by outflank-mailman (input) for mailman id 695793;
 Wed, 20 Mar 2024 08:35:14 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmrPm-0006DN-H1
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 08:35:14 +0000
Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com
 [2a00:1450:4864:20::636])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c4a3cf45-e694-11ee-a1ee-f123f15fe8a2;
 Wed, 20 Mar 2024 09:35:12 +0100 (CET)
Received: by mail-ej1-x636.google.com with SMTP id
 a640c23a62f3a-a46cd9e7fcaso328806566b.1
 for ; Wed, 20 Mar 2024 01:35:12 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 af3-20020a170906998300b00a469604c464sm5509111ejc.160.2024.03.20.01.35.11
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 20 Mar 2024 01:35:11 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c4a3cf45-e694-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710923712; x=1711528512; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=aRSwBN3CTZjgtb3bsgfd3Ea4pmuLB28ZnZXAqYxZBL0=;
        b=fcFTyAihtrqR3oIib21FlrBjxrlM3UByKnWyCAOboCusegitSGLtifmmwGBrk7X8m5
         C1F3/O05IqiSyV44gKvNuG5kRk3+86T3V7zAiBCjWid+h5q2lNOMCkR/YVP/7MX7FxDh
         c8F/Uq5hJCExhpYkY0ZI1VKZtM7GtBqzOdqRmP30lEqzHAv9Fietw86e12APSswbNpc8
         6qnLmwNB/7x94H6Y51IQ39KBL9DDPmiq96UCFbYyvMWDbfKPS2f4T13PkXJ/DQUWZxCe
         MjHIaS1seiNKHQNdVJxy4/sN3VEzcsuFHKKtA5psY3z17vozg9+djVHPEXieZ+lyg1CJ
         BMyg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710923712; x=1711528512;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=aRSwBN3CTZjgtb3bsgfd3Ea4pmuLB28ZnZXAqYxZBL0=;
        b=dn0K9szrNbrvcI9u3Dd67wgpWYqcThBCwWldZb4l5rBMMsH+JASS2jbZCOWhTZYquJ
         XM9W+47Oiup8iJOV6TIrtxNpE8UmwuVLcMAoMrRgyuErC1f9fE8/ezZZPcGGwbhiyPna
         ceN+9vq+OALmgjr5isCYUANYigawiflBRcXzkw6/Y54XP0MnFSMnyKCPlu89enEFTfxm
         444R0LaPwEfxHRw0bZyausFLZx25o+kxoGKhZhd7oXiFGbU7+TqZEyYlbxexh4YeTiM9
         O873Wpbv1Y7RHBISYBIT5iuSLwM4y/xIz8vI6znqPUEme5cGdOLgq+yqnxLscSSTi1Ku
         kL+Q==
X-Forwarded-Encrypted: i=1; AJvYcCU/xk9R84eDn8fKbPjYXCwtmvzyK4l6uxj6kJ1jbsbkl09uah6L2Rrq52IZAgxHCiNNG0WLzLC5Y+2097R6O/BxwTsyCuC8OP8sQ2W9T+0=
X-Gm-Message-State: AOJu0YyQyeES3F/Eqyj0v7Ox5tYcvwO+3zHvtXKgyqQDwSiZPGb+H2xn
	8XUBoV9saSK+j5GaFIsluFrESbeBpyGCbnmAw94/dNPQRxTg5/o5Ytxm4LpkaA==
X-Google-Smtp-Source: AGHT+IEZo0bMa98428ndj0OJjRszhkyFPKuC+GjDZmx/gxXoa8nzgmKBO2Xh3w9zIf/NqfmRiGFLMw==
X-Received: by 2002:a17:906:9a1:b0:a46:ede0:2370 with SMTP id q1-20020a17090609a100b00a46ede02370mr808918eje.57.1710923712057;
        Wed, 20 Mar 2024 01:35:12 -0700 (PDT)
Message-ID: <2107eac4-3d59-497a-a682-ae38933ac6ae@suse.com>
Date: Wed, 20 Mar 2024 09:35:11 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH v2 0/1] tools: init scripts: Add missing
 XENCONSOLED_ARGS variable to xencommons
Content-Language: en-US
To: =?UTF-8?Q?Rafa=C3=ABl_Kooi?= 
Cc: Wei Liu , Anthony PERARD ,
 xen-devel@lists.xenproject.org
References: 
 
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 20.03.2024 08:59, Rafaël Kooi wrote:
> On 20/03/2024 08:55, Jan Beulich wrote:
>> On 20.03.2024 08:48, Rafaël Kooi wrote:
>>> V2: Now without test emails ending up on the mailing list. And with the
>>> correct title prefix.
>>>
>>> I noticed that the systemd services referenced the XENCONSOLED_ARGS
>>> variable, but it was missing from xencommons.
>>> I actually ran into this when experimenting with a Qubes patch where I
>>> thought I needed to modify this variable. It turned out to not be the
>>> case, but I figure it's good to include this for sake of completeness.
>>>
>>> Rafaël Kooi (1):
>>>    tools: init scripts: Add missing XENCONSOLED_ARGS variable
>>>
>>>   tools/hotplug/Linux/init.d/sysconfig.xencommons.in | 6 ++++++
>>>   1 file changed, 6 insertions(+)
>>
>> Two further remarks: Patch series want to have the patches sent "in reply to"
>> the cover letter, such that the whole thing appears as a single mail thread.
>> For singular patches, generally no cover letter is required (thus avoiding
>> the question of threading).
> 
> I don't understand why it's not present on the mailing list, the
> "In-Reply-To" header is present in the patch file. Maybe outlook is
> stripping it, I'll have to look into it.

If you send using Outlook, why don't you simply send the patch(es) as
replies to the cover letter? That's what I'm doing using Thunderbird
(i.e. like you I'm not using "git send-email").

Jan


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 08:52:01 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 08:52:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695797.1085889 (Exim 4.92)
	(envelope-from )
	id 1rmrfv-0001hy-NO; Wed, 20 Mar 2024 08:51:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695797.1085889; Wed, 20 Mar 2024 08:51:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmrfv-0001hr-JX; Wed, 20 Mar 2024 08:51:55 +0000
Received: by outflank-mailman (input) for mailman id 695797;
 Wed, 20 Mar 2024 08:51:55 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmrfu-0001fz-Ci
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 08:51:55 +0000
Received: from EUR04-HE1-obe.outbound.protection.outlook.com
 (mail-he1eur04olkn2100.outbound.protection.outlook.com [40.92.73.100])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 19316898-e697-11ee-afdd-a90da7624cb6;
 Wed, 20 Mar 2024 09:51:53 +0100 (CET)
Received: from DU0P192MB1700.EURP192.PROD.OUTLOOK.COM (2603:10a6:10:3bf::6) by
 DBAP192MB0939.EURP192.PROD.OUTLOOK.COM (2603:10a6:10:1c0::20) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.7386.31; Wed, 20 Mar 2024 08:51:24 +0000
Received: from DU0P192MB1700.EURP192.PROD.OUTLOOK.COM
 ([fe80::181e:3628:177d:1cf9]) by DU0P192MB1700.EURP192.PROD.OUTLOOK.COM
 ([fe80::181e:3628:177d:1cf9%4]) with mapi id 15.20.7386.017; Wed, 20 Mar 2024
 08:51:24 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 19316898-e697-11ee-afdd-a90da7624cb6
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=nchAQ4LPyqsYzePNmXkui1B5ag/cH5ZcqQvqVQP9Dz4Xwm7TcuGTnuBfGS1nyaVCzdyr4YK31a7OkZTCYGHppguZEIqa5FlU/9tWKmF2CvLTCjq37WZg7q2vMtHr46heZXCWHniDOmm/HSPTKNuxiDBwCodxCsA4MV1MlYJZC67WHfilaATwUSH29K+5ZNOuhb+iHqVFgoI2rDoCW7CdeEV8fszDYXE7s2nGQZCaEA1RVURhubk8+7EvsS329wDEQiOwkdTTmmBSTi2JBM80QUTjd2ySYxymw20VvX7loRiuztrWsnNUVaM9DsaN4uNALMyflEzFQdTlUjRpPIJmcQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=nF3m8aujpqKhs07cWSaBf1soqIptLE7Zu7ECKba8K7A=;
 b=PiqO3CAXWI9Q2pYdoCdgrl30naQBpTPkPHZM9H3yPA1Gs3Chz4O+1yU6CRnbBOws/QgQZpbj80fzZ1LiR2iTHjQQ3QOLeMrTtyMPzQB99MiLkFZaDtI4xVN1xVBRUrz60g5dqErJydegqhEfZDhOASaUXwh08YjYUgD/4wqspHhceKMaufUjHGlk7MzK9v1lbBZHC6ENR/XImOSLnGkLcslmFj8ibnmpiJUCNc2W8nbizh5hXlW7u8V8O6h4r1lbLTD0PW06cxdZwXw6yYbNK5m9ugrNBxfSuXOGV5eNl89jtUZEyWmrK+yH4QXnFP7kIM+fDf7bu9+vk4uOPVS2Sg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=nF3m8aujpqKhs07cWSaBf1soqIptLE7Zu7ECKba8K7A=;
 b=ZxGSlssBSG64Xc/d/kqiKe7GNx8OsaWTFnVvLVfYNl9fv6S/JmKxBs9HHnHGrW22I6GZMy/JMUwtRWwmZqbNZFbygmmepXiDHpcQNZ9aE8LB9Eq7uZ7W8Pz0Il/3wMdOGbCZZioIyPYHV1Xq8mLZlMUMIeiWf9fVVf+YyKPcymRFC6cxLHjOvGI6vcrHi9iB6PTByoqXqZnaNneZyEdIpCZTfmnWwPWdRnFvaY7Lm03GX8yQaS3vZeSSsfdkFPKXQc2yB19RlO4l1Ls6pXHGquhbR0ye+Bje4KAWUMpV5N8NDnR4LIYr4IeBKW3jSg4pUZlJ7ll0t0QyFr6E57fABw==
Message-ID:
 
Date: Wed, 20 Mar 2024 09:51:15 +0100
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH v2 0/1] tools: init scripts: Add missing
 XENCONSOLED_ARGS variable to xencommons
Content-Language: en-US
To: Jan Beulich 
Cc: Wei Liu , Anthony PERARD ,
 xen-devel@lists.xenproject.org
References: 
 
 
 <2107eac4-3d59-497a-a682-ae38933ac6ae@suse.com>
From: =?UTF-8?Q?Rafa=C3=ABl_Kooi?= 
Autocrypt: addr=rafael_andreas@hotmail.com; keydata=
 xjMEZHDtHhYJKwYBBAHaRw8BAQdA4C7O72UZHQbhHNm1BUkAM/7+KQKN3tupyuGVGyj2dIHN
 KVJhZmHDq2wgS29vaSA8cmFmYWVsX2FuZHJlYXNAaG90bWFpbC5jb20+wo8EExYIADcWIQTv
 ioHnE84MxV6adj/iFi3SALEToAUCZHDtHgUJA8JnAAIbAwQLCQgHBRUICQoLBRYCAwEAAAoJ
 EOIWLdIAsROgP80BAKeJdh3YQ5l3gxGp8R9wIvN9Ac3vsMfy8I4kZ6TXksLKAP9vLRV4G3yw
 z7/seKhWc27Jjl4uI/+lIWhWaWrUYZmjAM44BGRw7R8SCisGAQQBl1UBBQEBB0DE61lbAezY
 NhOlHgxdZ9V4klIhSajeU50O8wHIPQnCLgMBCAfCfgQYFggAJhYhBO+KgecTzgzFXpp2P+IW
 LdIAsROgBQJkcO0fBQkDwmcAAhsMAAoJEOIWLdIAsROghHgBANU4dj+WnuSaWemAHVkjERJg
 m0FQpmZzNI8hdolS3gYdAP9zGK65ilpHMDj4pGvfALabruZA4NPJYxSqeamHvOuhBA==
In-Reply-To: <2107eac4-3d59-497a-a682-ae38933ac6ae@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-TMN: [HSIVr6R8BWBwOteLx1p0nwYjJIkfyYSSzsvBE3iAbOk/bp08bQDUBnc7mKL2HUOD]
X-ClientProxiedBy: SI1PR02CA0040.apcprd02.prod.outlook.com
 (2603:1096:4:1f6::7) To DU0P192MB1700.EURP192.PROD.OUTLOOK.COM
 (2603:10a6:10:3bf::6)
X-Microsoft-Original-Message-ID:
 
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DU0P192MB1700:EE_|DBAP192MB0939:EE_
X-MS-Office365-Filtering-Correlation-Id: 685aa96f-1df3-4303-a225-08dc48baec0f
X-MS-Exchange-SLBlob-MailProps:
	YfhX3sd/0TVoUMj8BWYCuE6LiLTPpwRJv8uizpVsrIErp2ChADy58jk4R3X8I8jeQtkd4iD0oADoSdB9pQuTyM6ahDf7L3OqHQ+qExLb0KE+XxStsrhJuYIwS10w9Mk8aForfmntADK3bUpxtONiXaTSKh1uSCMJmEJ/v20GuudM5C51yGK2TMcJVLvyHwyoW5opvJcSjtJrnxVf+ylmbMX8TklTsIjuP58DYxZMT2ABsFqR/HRsNBnd6phhAX+yftyHqVMDRZIdrtLLQWx8fGqnPN8e4Ez2Chn7oPs7KJQM4A1E1duQ1trjEba4R8yzv7WPChdrU5i3NARXCtcIm8DGqA6owIwo1RRj6P+EFd76yuiiNhnyL2aCv+AGUCQ4/kWSNlmYstvkuH57MC79tuQV2m9aqlsSQSG+SstJQdaV34g40zEC7bcrso8LdaDwgeyi+CxWJR6th88b2wAP7+Dpb5cMY79YcK2afCOIa6nyrv/e35Iww5xz5/1I4hSyIcI0W689pUiseGTyX9T1nkuIvhLsVRtngJ0Bb5f/4G3DmlyNmRYeE12b3SmpR4heUg/LQGH1GIC9+zlwaG2G3EYKSqZeIKiGZJPrWbN5ZXLqgVq4/s5RNG1TgHsV9+uPFlRxFtVW/xj/Qgh8IqCTW7xsU4DoD+/XfOaa5RX3SGYgGwQXBx4wLjSoJsc54nHhtYGq3uavHMYu0XsJIOdBLWPfxHnhzrOFj1/sd0uBM1BLO5BK/VvZZ77FN8JqjqDR2JRy4Y+GfzjtBIZkyI2daP08J+l/XsnQ1eUQB9/AjVU=
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	HKTy14pYVZefszgMmHEOe23lYbVwpBVg3FpzI47qZnJrX/YaE5SUktW3aSv8ISpzGY5+mceAxnZSbHNxjz842PiYaPrCJ+sKl0W9uQpm/w+sTINzkoDIQuS+OmszHob0bM4GNtTEOO+uT0RpaRFtvnEvGzlHJR3yJWFv1I4mUtkUPK8g8mcDJnCT3yUA5exJ+LvNWQy3LkzK7I2dsSRueO7GXS22HDXrEKAZ3ln2cbWHfEHkrLoPQO56Ffq2kow3PTIvQrZlggWUXke9oKf/3fV8edQQOtuW0DSoEu8dnQWYuxLJoOtsslsHGgkL8En4MM0lAQ3f3omFyi+zr40zphbaw0EIf1CFabrleYvOH6oyO/6h+VqrwqiwfvpKifjMw0eFMzr7ZFcczijm1iFcY2kEjq8pVYmA3BwdEWpDVhrGOIq0ONpaJkKp9Zag7UOF5GQsqp3Jqz+HfLovRi4DYZO8Fk9tbW+BScrEUwEb/TNLmPBl/OWng8nwXRDIpvg19acNx1nD//hVCwFj/YUUUwKnzW4qQWdBlUdsgw1nwICq0kpgptOOKDn+CYsoNe9f
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?REFsaVp4aE92cm5KV2xmZnFoUzB2ZTlmd2tvZUIvVHpaTWhJeEFpQU55RjZw?=
 =?utf-8?B?WW5PcUtBTXFEZ1pPN0MwVDJiaTNsRTZOVU1TclREdHBaZDY0elRwbk9jeXpC?=
 =?utf-8?B?MjA1eWNUckZIZzhrdmxyYkNBRE5Kb2tQREhIVHFoT3FiVjBQV3gwNlhOWmVp?=
 =?utf-8?B?c3c4ZVhRRWhwaGU0bEdIZTJ1MkVTMVkySzlIcnNGUGdZZXlCSlVhTVdlVkxU?=
 =?utf-8?B?a2FlM1g1elpaN2RLdFp6cThJekpLUUV3emNGZkZ3ZlFMV1VVOTQzbjJadHd5?=
 =?utf-8?B?MnJWenhGV00zdVFRRE9lbkNlNWtqd25tc21mdTlKYXZsanBRWHpPNXp5bnJi?=
 =?utf-8?B?OWlKV1BLczhmYkNxQUNJd25RajVEYjRQQTZjT2RRRXUwNDNJU1VTTjdJZkla?=
 =?utf-8?B?WjNoSnNlYUo2Z2tFYUpIL1l3YTJORXhGbXFCdzFaUjlDY1NvaXhkVDV2R3A5?=
 =?utf-8?B?QXFOdWFQQjEzMHlzMCtOaXRpdDVJS1U2S2dtR2F0QjEwa0s0dCt2ODVPQlc0?=
 =?utf-8?B?Vy9WZUxKUVpTOTlrZ25KenREWC9PZTlzM3EveXp6Z1ZtQUN3a2dERm55cVJP?=
 =?utf-8?B?NnZOME44aGJNNE9vVTFUd21lbXBsWGpNSzF5VmF4LzVKRXFQc2JsdEhRbTlz?=
 =?utf-8?B?NHVUNHVodWg0ZzlMWUVwL2dFaGV1YUdVRGlrNVBwSWRpVDR5UFh4aFhSSGVH?=
 =?utf-8?B?R2llV3pPZDRBb1hpdHFjUms0N1prYXVZQUovOGdmdEZCOVBhNHZSZ2Z5YkVF?=
 =?utf-8?B?MUN6alhSLzBHWUROMkd4ZG9MR0Mwdll5WTJKM3FsdHRBMFdrWGV4RzRBbWlz?=
 =?utf-8?B?TmpHQ0FpcGdzTDdPS3lWM29wa05VQTlvYlpHWVBhZHZGSFNpbjc2VEhtZHM5?=
 =?utf-8?B?ZExxVE5Bd0ZyTmpBYXNqMEhCT0VoVXEvMGVUK0NtNHZHRnlXR0NDWGt2T3Qw?=
 =?utf-8?B?ODFMY2E4ZnlNUmlXWlErbDlNdk9hNFF4ZUJVT2x6eHpyei9qcU8zKzVTNkt2?=
 =?utf-8?B?NVZqNTAxTkpZaW43UGNDeUE0My9yVFFMaVVoYm0rbGdiRzNNK1lnWG15Z0VE?=
 =?utf-8?B?QTkra1dpN3Y3dktFRjJvWmM5VVhLMlJWVkk2UUs2S2FKbUd3TU12NFZsKzV0?=
 =?utf-8?B?djhyemlkVlBhUWgwcmI2NUlmM1EwTUpYUSsvb21IbjZid0IrcDIwVThZSEtQ?=
 =?utf-8?B?djZseExSN2VERE9FRUlBcElROGtIVnZ4d0wrWU9EYU1xOTlHL3NWWjkwYTA2?=
 =?utf-8?B?blhQTEk2bWd2bTVMTkJIZnlUZTJGdVBCZG1KTEl4MStvZzFBZkMyZVExblds?=
 =?utf-8?B?V243WlVtM25OY20wanlOaVM5ZXFCTTdYTnVLcXc1SDR3WFppbm9zajFpeVV1?=
 =?utf-8?B?cXNWMXJuUm1SY3p0Y2lrYVRvalVBZ0d6RzlZeGlPZ3ZQcmwzRE5uUmJQRVZW?=
 =?utf-8?B?aEJSWU5CNnU0aDZiWlFiUjlBWU0zNVptUm4rbkxOS0FmZEtNYnNjVnlNM3lz?=
 =?utf-8?B?TkNQRGpwVk41ZFVOcW5sT3ROcXF6Qy9LRDVrd2xpVUpLUlM3bFZyQUdpWHlv?=
 =?utf-8?B?ejJHdGd3WTZUdzIrUXZtMmpTSHhXcVRuTzNja0lrcWFSK05PdmZEbzNMQ05C?=
 =?utf-8?B?LzE5YmtZOG10Q254ei9PNFRxWE1uWk1UcGJKUkw1RTl5ZmsyZThpYWdjSU0w?=
 =?utf-8?B?djR5WnVBLys0RHhNbkZjMXp1K1Z3OG5SMHRSUVFqTjhqMmRDZzZYMy9xVDlF?=
 =?utf-8?Q?4imCWUe7/sYbmu8x2A5odFFwjIw6m25wNRGXzqL?=
X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-fb43a.templateTenant
X-MS-Exchange-CrossTenant-Network-Message-Id: 685aa96f-1df3-4303-a225-08dc48baec0f
X-MS-Exchange-CrossTenant-AuthSource: DU0P192MB1700.EURP192.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Mar 2024 08:51:24.6464
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg:
	00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBAP192MB0939

On 20/03/2024 09:35, Jan Beulich wrote:> If you send using Outlook, why don't you simply send the patch(es) as
> replies to the cover letter? That's what I'm doing using Thunderbird
> (i.e. like you I'm not using "git send-email").
> 
> Jan

I do use "git send-email" actually, I have it set up to use their SMTP
servers. I figured I would do as the Romans do, I assumed that
"git send-email" would be the path of least resistance.

I have figured out why the messages don't thread though. Outlook seems
to be rewriting the "Message-ID" header, but then fails to update the
"In-Reply-To" headers.

I'll make a gmail address for future patches, seeing Outlook is mailing
list unfriendly.

Rafaël


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 08:52:06 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 08:52:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695798.1085899 (Exim 4.92)
	(envelope-from )
	id 1rmrg6-00022Q-1p; Wed, 20 Mar 2024 08:52:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695798.1085899; Wed, 20 Mar 2024 08:52:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmrg5-00022J-V1; Wed, 20 Mar 2024 08:52:05 +0000
Received: by outflank-mailman (input) for mailman id 695798;
 Wed, 20 Mar 2024 08:52:04 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmrg4-000214-BV
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 08:52:04 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1e629165-e697-11ee-a1ee-f123f15fe8a2;
 Wed, 20 Mar 2024 09:52:02 +0100 (CET)
Received: from beta.station (net-93-144-106-196.cust.dsl.teletu.it
 [93.144.106.196])
 by support.bugseng.com (Postfix) with ESMTPSA id 941A34EE073D;
 Wed, 20 Mar 2024 09:52:00 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1e629165-e697-11ee-a1ee-f123f15fe8a2
From: Simone Ballarin 
To: xen-devel@lists.xenproject.org
Cc: consulting@bugseng.com,
	sstabellini@kernel.com,
	Simone Ballarin ,
	Doug Goldstein ,
	Stefano Stabellini ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Wei Liu ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [XEN PATCH 0/2] xen: address violations of MISRA C Rule 17.1
Date: Wed, 20 Mar 2024 09:50:58 +0100
Message-Id: 
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

MISRA C Rule 20.7 states: "The features of `' shall not be used".

The Xen community wants to avoid using variadic functions except for
specific circumstances where it feels appropriate by strict code review.

Functions hypercall_create_continuation and hypercall_xlat_continuation
are special hypercalls made to break long running hypercalls into multiple
calls. They take a variable number of arguments depending on the original
hypercall they are trying to continue. Add SAF deviations for the aforementioned
functions.

Add deviation for functions related to console output (printk and similar).

Simone Ballarin (2):
  automation/eclair: add deviation for MISRA C:2012 Rule 17.1
  xen: address violations of MISRA C Rule 17.1

 .../eclair_analysis/ECLAIR/deviations.ecl     | 26 +++++++++++++++++++
 docs/misra/deviations.rst                     |  5 ++++
 docs/misra/safe.json                          |  8 ++++++
 xen/arch/arm/domain.c                         |  1 +
 xen/arch/x86/hypercall.c                      |  2 ++
 5 files changed, 42 insertions(+)

-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed Mar 20 08:52:12 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 08:52:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695799.1085908 (Exim 4.92)
	(envelope-from )
	id 1rmrgC-0002Nc-AW; Wed, 20 Mar 2024 08:52:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695799.1085908; Wed, 20 Mar 2024 08:52:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmrgC-0002NV-6y; Wed, 20 Mar 2024 08:52:12 +0000
Received: by outflank-mailman (input) for mailman id 695799;
 Wed, 20 Mar 2024 08:52:10 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmrgA-000214-CK
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 08:52:10 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 22590b3f-e697-11ee-a1ee-f123f15fe8a2;
 Wed, 20 Mar 2024 09:52:08 +0100 (CET)
Received: from beta.station (net-93-144-106-196.cust.dsl.teletu.it
 [93.144.106.196])
 by support.bugseng.com (Postfix) with ESMTPSA id 0EC5A4EE073F;
 Wed, 20 Mar 2024 09:52:08 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 22590b3f-e697-11ee-a1ee-f123f15fe8a2
From: Simone Ballarin 
To: xen-devel@lists.xenproject.org
Cc: consulting@bugseng.com,
	sstabellini@kernel.com,
	Simone Ballarin ,
	Doug Goldstein ,
	Stefano Stabellini ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Wei Liu 
Subject: [XEN PATCH 1/2] automation/eclair: add deviation for MISRA C:2012 Rule 17.1
Date: Wed, 20 Mar 2024 09:50:59 +0100
Message-Id: <882b442c8c1f73f8116676ab9351defe5c9609ac.1710923235.git.simone.ballarin@bugseng.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

MISRA C:2012 Rule 17.1 states:
The features of `' shall not be used

The Xen community wants to avoid using variadic functions except for
specific circumstances where it feels appropriate by strict code review.

Add deviation for functions related to console output (printk and similar).

Signed-off-by: Simone Ballarin 
---
 .../eclair_analysis/ECLAIR/deviations.ecl     | 26 +++++++++++++++++++
 docs/misra/deviations.rst                     |  5 ++++
 2 files changed, 31 insertions(+)

diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
index 9ac3ee4dfd..7c3559a3a0 100644
--- a/automation/eclair_analysis/ECLAIR/deviations.ecl
+++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
@@ -382,6 +382,32 @@ explicit comment indicating the fallthrough intention is present."
 -config=MC3R1.R16.6,switch_clauses+={deliberate, "default(0)"}
 -doc_end
 
+#
+# Series 17.
+#
+
+-doc_begin="Functions related to console output are allowed to use the variadic features provided by stdarg.h."
+-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(debugtrace_printk)&&kind(function))))"}
+-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(dt_dprintk)&&kind(function))))"}
+-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(printk)&&kind(function))))"}
+-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(guest_printk)&&kind(function))))"}
+-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(panic)&&kind(function))))"}
+-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(dprintk)&&kind(function))))"}
+-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(gdprintk)&&kind(function))))"}
+-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(snprintf)&&kind(function))))"}
+-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(scnprintf)&&kind(function))))"}
+-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(xasprintf)&&kind(function))))"}
+-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(mm_printk)&&kind(function))))"}
+-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(dbgp_printk)&&kind(function))))"}
+-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(elf_call_log_callback)&&kind(function))))"}
+-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(vsnprintf)&&kind(function))))"}
+-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(vscnprintf)&&kind(function))))"}
+-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(xvasprintf)&&kind(function))))"}
+-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(vprintk_common)&&kind(function))))"}
+-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(guest_printk)&&kind(function))))"}
+-config=MC3R1.R17.1,macros+={hide , "^va_(arg|start|copy|end)$"}
+-doc_end
+
 #
 # Series 18.
 #
diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
index ce855ddae6..fa649a2024 100644
--- a/docs/misra/deviations.rst
+++ b/docs/misra/deviations.rst
@@ -328,6 +328,11 @@ Deviations related to MISRA C:2012 Rules:
        improve readability.
      - Tagged as `deliberate` for ECLAIR.
 
+   * - R17.1
+     - Functions related to console output are allowed to use the variadic
+       features provided by `stdarg.h`.
+     - Tagged as `deliberate` for ECLAIR.
+
    * - R20.7
      - Code violating Rule 20.7 is safe when macro parameters are used:
        (1) as function arguments;
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed Mar 20 08:52:45 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 08:52:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695804.1085919 (Exim 4.92)
	(envelope-from )
	id 1rmrgj-0003WG-Jd; Wed, 20 Mar 2024 08:52:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695804.1085919; Wed, 20 Mar 2024 08:52:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmrgj-0003W9-GQ; Wed, 20 Mar 2024 08:52:45 +0000
Received: by outflank-mailman (input) for mailman id 695804;
 Wed, 20 Mar 2024 08:52:45 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmrgj-000214-1K
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 08:52:45 +0000
Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com
 [2607:f8b0:4864:20::836])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 36909d9b-e697-11ee-a1ee-f123f15fe8a2;
 Wed, 20 Mar 2024 09:52:43 +0100 (CET)
Received: by mail-qt1-x836.google.com with SMTP id
 d75a77b69052e-42a0ba5098bso38070801cf.0
 for ; Wed, 20 Mar 2024 01:52:43 -0700 (PDT)
Received: from localhost ([85.31.135.62]) by smtp.gmail.com with ESMTPSA id
 ey22-20020a05622a4c1600b00430b22f5735sm5858345qtb.78.2024.03.20.01.52.40
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 20 Mar 2024 01:52:41 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 36909d9b-e697-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710924762; x=1711529562; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=5WGmL1cHF0FTChTrEJdhA2rD3/SU2TArjtWLZvEb/ag=;
        b=ViloRNxFa0SZrBUKcbKOfEz5PinW2tnNDNZN0VVwKOpXfjVhcFPhRcP8oIy9XrhUDJ
         zsFmzOS7xRU+PwMR4QSTOyLFUl1BfrtgyjIIhPVUVXo89zf9MN7tCZcNPkyIz+4nyuKX
         nb0ko4ngCRXYjL1F42WDZ/8YaaPPEl8+Fmf/c=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710924762; x=1711529562;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=5WGmL1cHF0FTChTrEJdhA2rD3/SU2TArjtWLZvEb/ag=;
        b=uENkafdqQA+2htJoltnK71IYCnw8Yiilk9MJfzY04l5L5oX/xkyDyg6qaFW5L98FHZ
         lUsCuDn4NNGs+mWX2ZLPokL3mIrn/TGB2F0EYvU5bxxkan7eMxwb8bekElZhvKVS5pG5
         XXqL58CvrlzeXismqqdWAujU2we2OS107R+zLX4YBvSfp3AtJg0O0LkTHMSLhvaSbl6J
         gejP9BljdNGGl+/aMUl0JLk5QVT9/EZtovcC3ENA/3C8AibkwkXle6lyiKZrYvFAWH6E
         Ym0V+OJmz1FolNkiavsRPhZOmCRKRRjWP4xyWTuqaOGtxaTRlPRVdIDsWlxBD8S6r7er
         a79Q==
X-Gm-Message-State: AOJu0YzR1has9ncRm2oeIEINVp9jPhx53eXa8uLygWVwO7mxIkfiahN+
	ZGIrHkcWWHdeLiZDxiHt8ueFfFKPyZhptfO9939M8KAxejDxnJJKYkp2a4SKAvo=
X-Google-Smtp-Source: AGHT+IFeYfU3bQvPW4z7n0HHKlmIUMpOJKh8isYEcR475d8shVlOA1SXXvCEf7iz7RlgB7js+PlJKA==
X-Received: by 2002:ac8:5789:0:b0:430:bd61:d5c with SMTP id v9-20020ac85789000000b00430bd610d5cmr4565848qta.34.1710924761834;
        Wed, 20 Mar 2024 01:52:41 -0700 (PDT)
Date: Wed, 20 Mar 2024 09:52:39 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Alejandro Vallejo 
Cc: Xen-devel ,
	Jan Beulich ,
	Andrew Cooper , Wei Liu ,
	Anthony PERARD ,
	Juergen Gross 
Subject: Re: [PATCH 4/6] tools/hvmloader: Use cpu_policy to determine APIC IDs
Message-ID: 
References: <20240109153834.4192-1-alejandro.vallejo@cloud.com>
 <20240109153834.4192-5-alejandro.vallejo@cloud.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20240109153834.4192-5-alejandro.vallejo@cloud.com>

On Tue, Jan 09, 2024 at 03:38:32PM +0000, Alejandro Vallejo wrote:
> As part of topology correction efforts, APIC IDs can no longer be derived
> strictly through the vCPU ID alone. Bring in the machinery for policy
> retrieval and parsing in order to generate the proper MADT table and wake
> the appropriate CPUs.

I'm kind of unsure about this last part of the sentence, as I see no
waking of CPUs in hvmloader.  Is this referring to something else?

I'm kind of unsure about bringing the cpu_policy machinery to
hvmloader.  Won't it be simpler to just pass the array of APIC IDs in
hvm_info_table?  The current size of this struct is 48bytes, and an
array of 128 32bit integers would be an additional 512bytes.

AFAICT there's plenty of room in hvm_info_table, it's
positioned at 0x9f800, and there's unused space up to 0x9fc00, so 1024
bytes of memory we could use.

I know this doesn't give us much room for expansion if we want to bump
past 128 vCPUs, but a more appropriate solution IMO would be to move
ACPI table creation to the toolstack.

It's possible I'm missing some aspects, so if this has been considered
and rejected would be good to note in the commit message.

> 
> Signed-off-by: Alejandro Vallejo 
> ---
>  tools/firmware/hvmloader/Makefile    |  7 +++++++
>  tools/firmware/hvmloader/config.h    |  5 ++++-
>  tools/firmware/hvmloader/hvmloader.c |  6 ++++++
>  tools/firmware/hvmloader/util.c      |  3 ++-
>  tools/libacpi/build.c                | 27 +++++++++++++++++++++------
>  tools/libacpi/libacpi.h              |  5 ++++-
>  tools/libs/light/libxl_x86_acpi.c    | 21 +++++++++++++++++++--
>  7 files changed, 63 insertions(+), 11 deletions(-)
> 
> diff --git a/tools/firmware/hvmloader/Makefile b/tools/firmware/hvmloader/Makefile
> index e5de1ade17..503ef2e219 100644
> --- a/tools/firmware/hvmloader/Makefile
> +++ b/tools/firmware/hvmloader/Makefile
> @@ -37,6 +37,13 @@ ifeq ($(debug),y)
>  OBJS += tests.o
>  endif
>  
> +CFLAGS += -I../../../xen/arch/x86/include/
> +
> +vpath cpuid.c ../../../xen/lib/x86/
> +OBJS += cpuid.o
> +vpath policy.c ../../../xen/lib/x86/
> +OBJS += policy.o
> +
>  CIRRUSVGA_DEBUG ?= n
>  
>  ROMBIOS_DIR := ../rombios
> diff --git a/tools/firmware/hvmloader/config.h b/tools/firmware/hvmloader/config.h
> index c82adf6dc5..3304b63cd8 100644
> --- a/tools/firmware/hvmloader/config.h
> +++ b/tools/firmware/hvmloader/config.h
> @@ -3,10 +3,13 @@
>  
>  #include 
>  #include 
> +#include 
>  
>  enum virtual_vga { VGA_none, VGA_std, VGA_cirrus, VGA_pt };
>  extern enum virtual_vga virtual_vga;
>  
> +extern struct cpu_policy cpu_policy;
> +
>  extern unsigned long igd_opregion_pgbase;
>  #define IGD_OPREGION_PAGES 3
>  
> @@ -50,7 +53,7 @@ extern uint8_t ioapic_version;
>  #define IOAPIC_ID           0x01
>  
>  #define LAPIC_BASE_ADDRESS  0xfee00000
> -#define LAPIC_ID(vcpu_id)   ((vcpu_id) * 2)
> +#define LAPIC_ID(vcpu_id) x86_x2apic_id_from_vcpu_id(&cpu_policy, vcpu_id)
>  
>  #define PCI_ISA_DEVFN       0x08    /* dev 1, fn 0 */
>  #define PCI_ISA_IRQ_MASK    0x0c20U /* ISA IRQs 5,10,11 are PCI connected */
> diff --git a/tools/firmware/hvmloader/hvmloader.c b/tools/firmware/hvmloader/hvmloader.c
> index c58841e5b5..8874165c66 100644
> --- a/tools/firmware/hvmloader/hvmloader.c
> +++ b/tools/firmware/hvmloader/hvmloader.c
> @@ -28,6 +28,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  const struct hvm_start_info *hvm_start_info;
> @@ -118,6 +119,9 @@ uint8_t ioapic_version;
>  
>  bool acpi_enabled;
>  
> +/* TODO: Remove after HVM ACPI building makes it to libxl */
> +struct cpu_policy cpu_policy;
> +
>  static void init_hypercalls(void)
>  {
>      uint32_t eax, ebx, ecx, edx;
> @@ -331,6 +335,8 @@ int main(void)
>      printf("HVM Loader\n");
>      BUG_ON(hvm_start_info->magic != XEN_HVM_START_MAGIC_VALUE);
>  
> +    x86_cpu_policy_fill_native(&cpu_policy);
> +
>      init_hypercalls();
>  
>      memory_map_setup();
> diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
> index e82047d993..25a0245c5c 100644
> --- a/tools/firmware/hvmloader/util.c
> +++ b/tools/firmware/hvmloader/util.c
> @@ -30,6 +30,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  /*
>   * Check whether there exists overlap in the specified memory range.
> @@ -1041,7 +1042,7 @@ void hvmloader_acpi_build_tables(struct acpi_config *config,
>      ctxt.mem_ops.free = acpi_mem_free;
>      ctxt.mem_ops.v2p = acpi_v2p;
>  
> -    acpi_build_tables(&ctxt, config);
> +    acpi_build_tables(&ctxt, config, &cpu_policy);
>  
>      hvm_param_set(HVM_PARAM_VM_GENERATION_ID_ADDR, config->vm_gid_addr);
>  }
> diff --git a/tools/libacpi/build.c b/tools/libacpi/build.c
> index 2f29863db1..ab05e54c96 100644
> --- a/tools/libacpi/build.c
> +++ b/tools/libacpi/build.c
> @@ -17,6 +17,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #define ACPI_MAX_SECONDARY_TABLES 16
>  
> @@ -65,7 +66,8 @@ static void set_checksum(
>  
>  static struct acpi_20_madt *construct_madt(struct acpi_ctxt *ctxt,
>                                             const struct acpi_config *config,
> -                                           struct acpi_info *info)
> +                                           struct acpi_info *info,
> +                                           const struct cpu_policy *policy)
>  {
>      struct acpi_20_madt           *madt;
>      struct acpi_20_madt_intsrcovr *intsrcovr;
> @@ -143,14 +145,25 @@ static struct acpi_20_madt *construct_madt(struct acpi_ctxt *ctxt,
>      info->madt_lapic0_addr = ctxt->mem_ops.v2p(ctxt, lapic);
>      for ( i = 0; i < hvminfo->nr_vcpus; i++ )
>      {
> +        uint32_t x2apic_id = x86_x2apic_id_from_vcpu_id(policy, i);
> +
>          memset(lapic, 0, sizeof(*lapic));
>          lapic->type    = ACPI_PROCESSOR_LOCAL_APIC;
>          lapic->length  = sizeof(*lapic);
>          /* Processor ID must match processor-object IDs in the DSDT. */
>          lapic->acpi_processor_id = i;
> -        lapic->apic_id = config->lapic_id(i);
> +        lapic->apic_id = x2apic_id;
>          lapic->flags = (test_bit(i, hvminfo->vcpu_online)
>                          ? ACPI_LOCAL_APIC_ENABLED : 0);
> +
> +        /*
> +         * Error-out if the x2APIC ID doesn't fit in the entry
> +         *
> +         * TODO: Use "x2apic" entries if biggest x2apic_id > 254

Nit: while it's true that we could fit bigger IDs by using x2apic
entries, there's a bit more to it.  Most OSes will refuse to use APIC
IDs >= 255 unless they have a way to target those CPUs as interrupt
destinations, either with interrupt remapping or with the extended
destination ID workaround [0].

[0] https://gitlab.com/xen-project/xen/-/issues/173

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 08:57:01 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 08:57:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695809.1085928 (Exim 4.92)
	(envelope-from )
	id 1rmrko-0004K9-2e; Wed, 20 Mar 2024 08:56:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695809.1085928; Wed, 20 Mar 2024 08:56:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmrkn-0004K2-WF; Wed, 20 Mar 2024 08:56:58 +0000
Received: by outflank-mailman (input) for mailman id 695809;
 Wed, 20 Mar 2024 08:56:57 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmrkn-0004Jw-3t
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 08:56:57 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id cd140b98-e697-11ee-a1ee-f123f15fe8a2;
 Wed, 20 Mar 2024 09:56:55 +0100 (CET)
Received: from beta.station (net-93-144-106-196.cust.dsl.teletu.it
 [93.144.106.196])
 by support.bugseng.com (Postfix) with ESMTPSA id 515034EE073D;
 Wed, 20 Mar 2024 09:56:54 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: cd140b98-e697-11ee-a1ee-f123f15fe8a2
From: Simone Ballarin 
To: xen-devel@lists.xenproject.org
Cc: consulting@bugseng.com,
	sstabellini@kernel.com,
	Simone Ballarin ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini ,
	Wei Liu ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [XEN PATCH 2/2] xen: address violations of MISRA C Rule 17.1
Date: Wed, 20 Mar 2024 09:51:00 +0100
Message-Id: 
X-Mailer: git-send-email 2.34.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

MISRA C Rule 20.7 states: "The features of `' shall not be used"

The Xen community wants to avoid using variadic functions except for
specific circumstances where it feels appropriate by strict code review.

Functions hypercall_create_continuation and hypercall_xlat_continuation
are special hypercalls made to break long running hypercalls into multiple
calls. They take a variable number of arguments depending on the original
hypercall they are trying to continue.

Add SAF deviations for the aforementioned functions.

Signed-off-by: Simone Ballarin 
---
 docs/misra/safe.json     | 8 ++++++++
 xen/arch/arm/domain.c    | 1 +
 xen/arch/x86/hypercall.c | 2 ++
 3 files changed, 11 insertions(+)

diff --git a/docs/misra/safe.json b/docs/misra/safe.json
index 952324f85c..65c90c7618 100644
--- a/docs/misra/safe.json
+++ b/docs/misra/safe.json
@@ -28,6 +28,14 @@
         },
         {
             "id": "SAF-3-safe",
+            "analyser": {
+                "eclair": "MC3R1.R17.1"
+            },
+            "name": "Rule 17.1: special hypercall made to break long running hypercalls into multiple calls.",
+            "text": "They need to take a variable number of arguments depending on the original hypercall they are trying to continue."
+        },
+        {
+            "id": "SAF-4-safe",
             "analyser": {},
             "name": "Sentinel",
             "text": "Next ID to be used"
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 5e7a7f3e7e..f5706bd5b8 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -382,6 +382,7 @@ unsigned long hypercall_create_continuation(
     const char *p = format;
     unsigned long arg, rc;
     unsigned int i;
+    /* SAF-3-safe allowed variadic function */
     va_list args;
 
     current->hcall_preempted = true;
diff --git a/xen/arch/x86/hypercall.c b/xen/arch/x86/hypercall.c
index 01cd73040d..18d8c75522 100644
--- a/xen/arch/x86/hypercall.c
+++ b/xen/arch/x86/hypercall.c
@@ -31,6 +31,7 @@ unsigned long hypercall_create_continuation(
     const char *p = format;
     unsigned long arg;
     unsigned int i;
+    /* SAF-3-safe allowed variadic function */
     va_list args;
 
     curr->hcall_preempted = true;
@@ -115,6 +116,7 @@ int hypercall_xlat_continuation(unsigned int *id, unsigned int nr,
     struct cpu_user_regs *regs;
     unsigned int i, cval = 0;
     unsigned long nval = 0;
+    /* SAF-3-safe allowed variadic function */
     va_list args;
 
     ASSERT(nr <= ARRAY_SIZE(mcs->call.args));
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed Mar 20 08:57:03 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 08:57:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695810.1085938 (Exim 4.92)
	(envelope-from )
	id 1rmrks-0004ZU-9Y; Wed, 20 Mar 2024 08:57:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695810.1085938; Wed, 20 Mar 2024 08:57:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmrks-0004ZL-6i; Wed, 20 Mar 2024 08:57:02 +0000
Received: by outflank-mailman (input) for mailman id 695810;
 Wed, 20 Mar 2024 08:57:01 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1rmrkr-0004Yw-Hf
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 08:57:01 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmrkr-00021b-2O; Wed, 20 Mar 2024 08:57:01 +0000
Received: from gw1.octic.net ([88.97.20.152] helo=[10.0.1.240])
 by xenbits.xenproject.org with esmtpsa
 (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92)
 (envelope-from )
 id 1rmrkq-0001HC-TW; Wed, 20 Mar 2024 08:57:01 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=emC8rffH3vnmHuHyLdxkyK1SBNSw+hOp77sCYuhO3qg=; b=PUXlXcc05CmqWuzEcpVXIlfcFE
	abS/UwwTTz4uE8VxI6UTB5ZiOQyhNDp+MWoy9kQyWwC6vzvDAB0y3JTO6t68lYcB+f6m5eElZBe8t
	//bHGYuqoaammnmf4rSbYz9bfK4qAFOLLaNMdW/Vl7py+h4aPpTlBxqpzZuHVVnQhjt0=;
Message-ID: <5ccdbad1-7610-45bf-878a-2d0f99cc805b@xen.org>
Date: Wed, 20 Mar 2024 08:56:59 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/rwlock: Don't perpeuatite broken API in new logic
Content-Language: en-GB
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= ,
 Andrew Cooper ,
 Xen-devel 
Cc: George Dunlap , Jan Beulich
 , Stefano Stabellini 
References: <20240319113020.3843309-1-andrew.cooper3@citrix.com>
 <553a8bfb-94f3-4c3a-b1ae-17d0cb185737@suse.com>
From: Julien Grall 
In-Reply-To: <553a8bfb-94f3-4c3a-b1ae-17d0cb185737@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit



On 20/03/2024 06:35, Jürgen Groß wrote:
> On 19.03.24 12:30, Andrew Cooper wrote:
>> The single user wants this the sane way around.  Write it as a normal 
>> static
>> inline just like rspin_lock().
>>
>> Fixes: cc3e8df542ed ("xen/spinlock: add 
>> rspin_[un]lock_irq[save|restore]()")
>> Signed-off-by: Andrew Cooper 
> 
> Reviewed-by: Juergen Gross 
> 
> Maybe with the subject fixed (s/rwlock/spinlock/).

And s/perpeuatite/perpetuate/ :).

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 08:59:36 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 08:59:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695813.1085949 (Exim 4.92)
	(envelope-from )
	id 1rmrnK-0006Ar-OG; Wed, 20 Mar 2024 08:59:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695813.1085949; Wed, 20 Mar 2024 08:59:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmrnK-0006Ak-K4; Wed, 20 Mar 2024 08:59:34 +0000
Received: by outflank-mailman (input) for mailman id 695813;
 Wed, 20 Mar 2024 08:59:33 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmrnJ-00069K-IL
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 08:59:33 +0000
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com
 [2a00:1450:4864:20::532])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 29fad84f-e698-11ee-a1ee-f123f15fe8a2;
 Wed, 20 Mar 2024 09:59:31 +0100 (CET)
Received: by mail-ed1-x532.google.com with SMTP id
 4fb4d7f45d1cf-568a53d2ce0so7908345a12.0
 for ; Wed, 20 Mar 2024 01:59:31 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 g17-20020a170906199100b00a46a49d661fsm4914494ejd.210.2024.03.20.01.59.29
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 20 Mar 2024 01:59:30 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 29fad84f-e698-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710925170; x=1711529970; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=NuW4BV4feiLlFcgba4D4nWoYUPZxvV4iNQtI5hWg7Dc=;
        b=ZVVPJ7GG+61xgc4TVIBqlY2zPkHb3maiUlTtDPzKxLf7Z3WFLOShKcYMxmuKgZpZgC
         qqaq5DtxAj4iBCuaTKBNE95foLr0NpVldqUyx58f4e85U1/MrmmHQqy/C7BzctO85w6r
         DdAN8IPBZ9aJDn/RAeoTzwOHOU7R9AA3nt+Cc8lMf7QVJfZ+gzJvYcAYs5P+mAnfMWLW
         f6nCcPGtCvOm7Kc40DkQMnzdk6gm0BuXLB/2OO/BaYmsvdXr5Hv9ey/INejmdLL11e2g
         lpn2DjdmfJBy/f0hcFP9lpz9HnNd5GnhEykOZygKNKwxjJHkACZCfHBzsnju1vnH7/B2
         qavg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710925170; x=1711529970;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=NuW4BV4feiLlFcgba4D4nWoYUPZxvV4iNQtI5hWg7Dc=;
        b=e7dBvx/8tLmh8frim3zgpqKLCoRiL/qahz8nWx+62hxlZLmpX2A9/KIjU00ALHywr6
         1ptY9VSaI4ixWkbT+AM4Uz7Da0oHqNhtH/kCErP1Bx+EYjgulZZY+2s85tWC0l70Tk2x
         K+wRwgEvg/12adVhvCum+SfCaVlEhaxPz3Tw3zX6ZsEGANyWsu1abATHORYLp+H+Nal/
         xqZNtjg82Wo27/SWGMcqtKg+NeSeGp0/y042S5vQRpN51/4S9EASqg1DBglXpABLrK7o
         xGUfanYZUtKctAxrIQzEzV754GxrAMyCvOcMoS/oCEc4kkQVPZ3IsuFe78YZC/Pv1Qn+
         ogPA==
X-Forwarded-Encrypted: i=1; AJvYcCUaQzbRifuVi6YZZxsKRJaVEtz5jwp/KVqkaRPf/0hxf10APJbgvOZuWoB/fZrRqP68SyuicCIfBNopzDRGCpl8prMDCYRv8GKjcrXXaMA=
X-Gm-Message-State: AOJu0Yx9Ez1/sikOtfBxbXW+VBAzEjCVb+3an2GzMlVagePgltxVzWRm
	FAdq0j+HNaeomGMNieiDyMKfUuT4jOoevS/NHQBhRVFRHzIQKH24Oz+GxBRawQ==
X-Google-Smtp-Source: AGHT+IEtYicCv3XcpOtVQDvzD9rkeX8Z1QWFwNGO7sAbiUYQfxmafI5LvGADPTYBNyIMlrVSNnZZJg==
X-Received: by 2002:a17:907:971c:b0:a46:9a9e:f3b0 with SMTP id jg28-20020a170907971c00b00a469a9ef3b0mr11572017ejc.67.1710925170531;
        Wed, 20 Mar 2024 01:59:30 -0700 (PDT)
Message-ID: 
Date: Wed, 20 Mar 2024 09:59:29 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86: adjust initial setting of watchdog kind
Content-Language: en-US
To: Andrew Cooper 
Cc: George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 "xen-devel@lists.xenproject.org" 
References: 
 <1c3d790d-bdac-495a-868b-36e12d45c457@citrix.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <1c3d790d-bdac-495a-868b-36e12d45c457@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 19.03.2024 21:35, Andrew Cooper wrote:
> On 25/01/2024 2:12 pm, Jan Beulich wrote:
>> "watchdog_timeout=0" is documented to disable the watchdog. Make sure
>> this also is true when there's a subsequent "watchdog" command line
>> option (and no further "watchdog_timeout=" one).
> 
> We also document that latest takes precedence, at which point "watchdog"
> would re-activate.

True, so perhaps ...

>> While there also switch watchdog_setup() to returning void, bringing it
>> in line with the !CONFIG_WATCHDOG case. Further amend command line
>> documentation to also mention the implicit effect of specifying a non-
>> zero timeout.
>>
>> Signed-off-by: Jan Beulich 
>> ---
>> Alternatively "watchdog" following "watchdog_timeout=0" could be taken
>> to mean to use the default timeout again.

... this alternative wants following.

> I realise that watchdog_timeout is my fault, but in fairness it was an
> early change of mine in Xen and didn't exactly get the kind of review it
> would get these days.  It also wasn't used by XenServer in the end - we
> just stayed at a default 5s.
> 
> I'm very tempted to suggest deleting watchdog_timeout, and extending
> watchdog= to have `force |  | s` so you could specify e.g.
> `watchdog=10s`.
> 
> The watchdog is off by default so I don't expect this will impact
> people.  It is also more convenient for the end user, and means that we
> don't have have the current split approach of two separate options
> fighting for control over each other.

While I'd be happy to fold the two options, I don't think the watchdog
being off by default is relevant here. People using just the
watchdog_timeout= option with a non-zero value will already have the
watchdog enabled. They'd need to pay attention to an eventual CHANGELOG
entry and change their command line.

Furthermore consolidating the two options isn't going to remove any
of the problems. What effect would e.g. "watchdog=off,10s" have? The
principle of "latest takes precedence" assigns clear meaning to
"watchdog=off watchdog=10s", but the above remains as ambiguous as
e.g. "watchdog=force,0s". I'd be inclined to follow those to the
letter, i.e. "watchdog=off,10s" sets the timeout to 10 but disables
the watchdog while "watchdog=force,0s" simply results in a non-
functioning watchdog (due to 0s effectively meaning 4 billion seconds
and hence for all practical purposes "never").

Jan


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 08:59:54 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 08:59:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695815.1085959 (Exim 4.92)
	(envelope-from )
	id 1rmrne-0006ln-1l; Wed, 20 Mar 2024 08:59:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695815.1085959; Wed, 20 Mar 2024 08:59:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmrnd-0006lg-Uz; Wed, 20 Mar 2024 08:59:53 +0000
Received: by outflank-mailman (input) for mailman id 695815;
 Wed, 20 Mar 2024 08:59:52 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1rmrnc-0006lO-Ph
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 08:59:52 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmrnc-000246-LX; Wed, 20 Mar 2024 08:59:52 +0000
Received: from gw1.octic.net ([88.97.20.152] helo=[10.0.1.240])
 by xenbits.xenproject.org with esmtpsa
 (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92)
 (envelope-from )
 id 1rmrnc-0001Lz-Gr; Wed, 20 Mar 2024 08:59:52 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
	References:Cc:To:From:Subject:MIME-Version:Date:Message-ID;
	bh=POeuv4ks2fDwz2BnRsfBteaYygmEZZEmiYCrQja7E5M=; b=D0L5NRhmQyEXUjA7AMNzCyQ+SN
	QcLPOVn22foOhgbI7GSzlUpPmYnzZrbCYMxRYoi6lK2AMW1vfkP77haIpEN3U0MTwAGqXN5IkB9IS
	lbKlmLQtwQ8Ygs/DmF4FIcdLrCYbnkXiOYnbhHEbjvbaXyOaLnDWQ3twLn+YGD2TPItc=;
Message-ID: <46810047-21ff-4821-a802-405431d4aae2@xen.org>
Date: Wed, 20 Mar 2024 08:59:50 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH] docs/parse-support-md: Handle BulletList
Content-Language: en-GB
From: Julien Grall 
To: Anthony PERARD , xen-devel@lists.xenproject.org
Cc: Andrew Cooper ,
 George Dunlap , Jan Beulich ,
 Stefano Stabellini 
References: <20240319151509.8937-1-anthony.perard@citrix.com>
 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit



On 19/03/2024 17:45, Julien Grall wrote:
> Hi Anthony,
> 
> On 19/03/2024 15:15, Anthony PERARD wrote:
>> Commit d638e304f13a introduced a bullet list, but parse-support-md
>> choke on it as it doesn't know what to do about it.
>>
>> Introduce ri_BulletList() so that r_content() will find this new
>> function and call it instead of calling process_unknown().
>>
>> Reported-by: Julien Grall 
>> Fixes: d638e304f13a ("SUPPORT.MD: Fix matrix generation after 
>> 43c416d0d819 and 77c39a53cf5b")
>> Signed-off-by: Anthony PERARD 
> 
> My Perl knowledge is rubbish. But I tested the fix. So:
> 
> Tested-by: Julien Grall 
> Acked-by: Julien Grall 

And committed.

Cheers,

> 
> Cheers,
> 
>> ---
>>   docs/parse-support-md | 7 +++++++
>>   1 file changed, 7 insertions(+)
>>
>> diff --git a/docs/parse-support-md b/docs/parse-support-md
>> index a397637639..b04f62da37 100755
>> --- a/docs/parse-support-md
>> +++ b/docs/parse-support-md
>> @@ -218,6 +218,13 @@ sub ri_DefinitionList {
>>       }
>>   }
>> +sub ri_BulletList {
>> +    # Assume a paragraph introduce this bullet list, which would mean 
>> that
>> +    # ri_Para() has already been called, and there's nothing else to 
>> do about
>> +    # the caveat.
>> +    return;
>> +}
>> +
>>   sub process_unknown {
>>       my ($c, $e) = @_;
>>       $had_unknown = Dumper($e);
> 

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 09:08:22 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 09:08:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695825.1085976 (Exim 4.92)
	(envelope-from )
	id 1rmrvj-0008Vd-Rm; Wed, 20 Mar 2024 09:08:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695825.1085976; Wed, 20 Mar 2024 09:08:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmrvj-0008VW-Ol; Wed, 20 Mar 2024 09:08:15 +0000
Received: by outflank-mailman (input) for mailman id 695825;
 Wed, 20 Mar 2024 09:08:14 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmrvi-0008VQ-Ky
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 09:08:14 +0000
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com
 [2a00:1450:4864:20::62d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 60e4f019-e699-11ee-a1ee-f123f15fe8a2;
 Wed, 20 Mar 2024 10:08:12 +0100 (CET)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-a46f0da1b4fso69824066b.2
 for ; Wed, 20 Mar 2024 02:08:12 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 g14-20020a170906198e00b00a46d049ff63sm2425212ejd.21.2024.03.20.02.08.11
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 20 Mar 2024 02:08:11 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 60e4f019-e699-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710925692; x=1711530492; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=D/ZwndSap+UjguGMNzzVmaq33gAVfBCyBcru2Ya/D5I=;
        b=IDCfwxexbt+az7o9k/FC2EWEk8pvQLURZbp+2xwv95YQ6uBgAwqXYDca9NXwkGtGqN
         OG/z+eZqGGMxgYlVMqSvbSJd+jv+aG7VcsRs5plGn6/zHKefWfLTcuzolCBQbadrxkEd
         hC7xLzVY3C8FUo2+r7mZNgaX5kqYJ0fpU/gllKZA5rXutmQYKXyn4/nNEXIPy/A8KfEx
         MpWgs+Nhj2Y409tI9CY7EC4tPMurORDw/OK4p+EnOdevmW2iuCyNz9lwqCaLCUZcd5Ok
         kDC1tk4ESXDJi0SC79EvWqUJWOL19+dNQCtZZlWVkOVQpdZOmdsc+1olAGYyL/jgGzxT
         o/IA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710925692; x=1711530492;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=D/ZwndSap+UjguGMNzzVmaq33gAVfBCyBcru2Ya/D5I=;
        b=RCovrkEIWlcAd7NdBFavnLMofu1LQSbGRTiGdufe/qNPsH6v1r+nmXmw3pvm7RGzDL
         3ZnZZC5LZ3a5IlJAiQJbhz4gr+b9EBkqLtBaC4BSFru2hNdfQgUjinCAyHLAS4i+odZv
         cCMiCFTnrSDvmcZqP6lyOMvxw8FNCPeaB/wUKNd/BkvWtYJaGB0aHKg5vP1t8H4tl/2n
         c8dsq3U79ad7tl+k4aYLKeG1s1QW8lfgA/EdxcZQPeX+iRfo8zl4+aipVLffoTsrdI6e
         HAiXgYnaQKMQTqpEEoIHubccsniX1I+DJztx3oG2ogJWNqfKycyHHPfDbiOic4NGXpwM
         3IdQ==
X-Forwarded-Encrypted: i=1; AJvYcCUPKNyynBG4xOBnAKGzU5XVDvxgV6YOy/VFPcDByWilexs4KMWQtUCwQQ786ZLBx+cXN89Ehou/YVY2Ajd4PlgRL5UGU0loMinO7UZ2KDA=
X-Gm-Message-State: AOJu0Yy4mO6thQBvkMdfJ8JBIur8shP8uqqrjycpiY5nOWna0CYTOPbH
	3rFMDLTxf2NriRnNhAWun1wJyl2/jZJFlAtOwrCADGNY7lTO/X3OoFjl9OYFsg==
X-Google-Smtp-Source: AGHT+IEi5QcEdgX9OfmpO5GHMu9SBhlRMR/xskEeRhCYZ9vemBd4NtsHAiuRkOVDoSCzFjah6zPJeg==
X-Received: by 2002:a17:906:c794:b0:a46:be85:4410 with SMTP id cw20-20020a170906c79400b00a46be854410mr5875104ejb.74.1710925692208;
        Wed, 20 Mar 2024 02:08:12 -0700 (PDT)
Message-ID: <9341a711-74c3-463f-8cc2-a54e19b4b2f4@suse.com>
Date: Wed, 20 Mar 2024 10:08:10 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 1/2] automation/eclair: add deviation for MISRA C:2012
 Rule 17.1
Content-Language: en-US
To: Simone Ballarin 
Cc: consulting@bugseng.com, Doug Goldstein ,
 Stefano Stabellini ,
 Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Wei Liu , xen-devel@lists.xenproject.org
References: 
 <882b442c8c1f73f8116676ab9351defe5c9609ac.1710923235.git.simone.ballarin@bugseng.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <882b442c8c1f73f8116676ab9351defe5c9609ac.1710923235.git.simone.ballarin@bugseng.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 20.03.2024 09:50, Simone Ballarin wrote:
> MISRA C:2012 Rule 17.1 states:
> The features of `' shall not be used
> 
> The Xen community wants to avoid using variadic functions except for
> specific circumstances where it feels appropriate by strict code review.
> 
> Add deviation for functions related to console output (printk and similar).
> 
> Signed-off-by: Simone Ballarin 
> ---
>  .../eclair_analysis/ECLAIR/deviations.ecl     | 26 +++++++++++++++++++
>  docs/misra/deviations.rst                     |  5 ++++
>  2 files changed, 31 insertions(+)
> 
> diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
> index 9ac3ee4dfd..7c3559a3a0 100644
> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> @@ -382,6 +382,32 @@ explicit comment indicating the fallthrough intention is present."
>  -config=MC3R1.R16.6,switch_clauses+={deliberate, "default(0)"}
>  -doc_end
>  
> +#
> +# Series 17.
> +#
> +
> +-doc_begin="Functions related to console output are allowed to use the variadic features provided by stdarg.h."
> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(debugtrace_printk)&&kind(function))))"}

This isn't concole output related.

> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(dt_dprintk)&&kind(function))))"}
> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(printk)&&kind(function))))"}
> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(guest_printk)&&kind(function))))"}
> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(panic)&&kind(function))))"}
> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(dprintk)&&kind(function))))"}
> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(gdprintk)&&kind(function))))"}
> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(snprintf)&&kind(function))))"}
> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(scnprintf)&&kind(function))))"}
> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(xasprintf)&&kind(function))))"}

These three and ...

> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(mm_printk)&&kind(function))))"}
> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(dbgp_printk)&&kind(function))))"}
> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(elf_call_log_callback)&&kind(function))))"}
> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(vsnprintf)&&kind(function))))"}
> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(vscnprintf)&&kind(function))))"}
> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(xvasprintf)&&kind(function))))"}

... these three aren't either.

> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(vprintk_common)&&kind(function))))"}
> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(guest_printk)&&kind(function))))"}
> +-config=MC3R1.R17.1,macros+={hide , "^va_(arg|start|copy|end)$"}
> +-doc_end

Further, is there a reason xyzprintk() are all listed individually?
Surely if we'd introduce a new flavor, we'd want that excluded too.

Finally, {,g}dprintk() in neither of their incarnation use any of the
va_* items listed. Why do they need mentioning here?

Jan


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 09:12:12 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 09:12:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695828.1085989 (Exim 4.92)
	(envelope-from )
	id 1rmrzO-0001qu-Dk; Wed, 20 Mar 2024 09:12:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695828.1085989; Wed, 20 Mar 2024 09:12:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmrzO-0001qn-9R; Wed, 20 Mar 2024 09:12:02 +0000
Received: by outflank-mailman (input) for mailman id 695828;
 Wed, 20 Mar 2024 09:12:00 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmrzM-0001qf-Pk
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 09:12:00 +0000
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com
 [2a00:1450:4864:20::631])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e7b5ea4c-e699-11ee-afdd-a90da7624cb6;
 Wed, 20 Mar 2024 10:11:59 +0100 (CET)
Received: by mail-ej1-x631.google.com with SMTP id
 a640c23a62f3a-a46d0a8399aso115369966b.1
 for ; Wed, 20 Mar 2024 02:11:58 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a4-20020a170906368400b00a46006bc7e9sm6978439ejc.159.2024.03.20.02.11.57
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 20 Mar 2024 02:11:58 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e7b5ea4c-e699-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710925918; x=1711530718; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=m8DgjMHAPNLrp/oH1catHKQq2B4nnG9SaOpJp6mkQRQ=;
        b=gAD3hJO0zllKbQUrQNdsR9f3PzmTQn2y3IfnVa7wZFOJVpJVnrmHNBu3JMlRa1D+Gl
         mFBxzyCECQJcZPks9pDNfUasFxfeH2fw7CP1oSeID6JaBzbo7GbDW2yHZwMBjM2mIUCA
         QiS4tHKd4Rta7BrVM68jMYEm3Wvl8T46iP1MfyWd4xuFbzItfDRDy8Wu6Rf+lMeJKWOB
         Xh3qVLjzdG0J5fY40qMq7wzY6sKe6EH97UxJMHaCBD5B/LNEUbrBkHzOFeEFqmbIXRmS
         0BaI67KyGe8T8qLRV7FIxTUskmAjf3qghGt5riNXKJK0LLQCkOLboZC6jE7cLkcEujhQ
         YCDg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710925918; x=1711530718;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=m8DgjMHAPNLrp/oH1catHKQq2B4nnG9SaOpJp6mkQRQ=;
        b=BxXRN+GubAqYkKym0AF939y4nRIQqqaSKALZVqkf3WKQcdufCOFRq1lnrl8D3jK/Ij
         bqzDQeFnBd1mYGfF2fxkbUoEKcdg3yDtzaEtaBOU7xdPqB2aQC2d3MVxKY8/7ud/L6Gn
         rSpSkRkba/MIB2NaXJNKW4jfmMfpm8/Gmi92kiQbsbke7WG8lBZC3Zo8yflXL8MCVvbS
         WDo9U8JsuU8Cl1mmvLJ4sjQKgFrHhnEpCFnUL7/iME4C5+g7K4i4IqWd2x8UaUks2TEA
         XmRBbHbYDTZWOV2tCQRyx+UFw3vPplj2LD2zxBFmNmCyWbS3g4ougpl2rAI7H8DgzgwC
         wOEw==
X-Forwarded-Encrypted: i=1; AJvYcCUgDA14OZ5TAiC++XwwtIb6GN85GVjuKpMHorpT9PuuwvPtZvxp+IeiWpRLpwxWT3BI/UYlRaI9jSevOMV7+CiURVLEmL/sAp/KnzTfI94=
X-Gm-Message-State: AOJu0YzuEQa1C5idHDjiJ8dP+q/tdIbLFlgJZ+7i8WTj8RD9+1dQk+/s
	y6DYg0uhplAZw6/R9HdLa0CT3xKHZil5QiefOlFsHVQj1bwmgeKvkDTMPG0gBg==
X-Google-Smtp-Source: AGHT+IGNAFWT1rc1h04T18SBS33wQpI3Tc3Svs8798sZs5l/ZSPowgYohaQYY98B8VYXjXTm2NxcJg==
X-Received: by 2002:a17:907:9449:b0:a46:f6f2:6861 with SMTP id dl9-20020a170907944900b00a46f6f26861mr964796ejc.36.1710925918342;
        Wed, 20 Mar 2024 02:11:58 -0700 (PDT)
Message-ID: <4ce30a38-5b5c-4d4c-a0c4-8c1a63759203@suse.com>
Date: Wed, 20 Mar 2024 10:11:57 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 2/2] xen: address violations of MISRA C Rule 17.1
Content-Language: en-US
To: Simone Ballarin 
Cc: consulting@bugseng.com, Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: 
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 20.03.2024 09:51, Simone Ballarin wrote:
> MISRA C Rule 20.7 states: "The features of `' shall not be used"
> 
> The Xen community wants to avoid using variadic functions except for
> specific circumstances where it feels appropriate by strict code review.
> 
> Functions hypercall_create_continuation and hypercall_xlat_continuation
> are special hypercalls made to break long running hypercalls into multiple
> calls.

Here and below: These aren't "special hypercalls". They're internal helper
functions.

> They take a variable number of arguments depending on the original
> hypercall they are trying to continue.

Am I misremembering or did Andrew outline a plan to eliminate the variadic-
ness from these? From certifiability perspective avoiding the need for a
deviation would likely be preferable?

Jan


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 09:30:37 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 09:30:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695832.1085999 (Exim 4.92)
	(envelope-from )
	id 1rmsHE-00063Q-SU; Wed, 20 Mar 2024 09:30:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695832.1085999; Wed, 20 Mar 2024 09:30:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmsHE-00063J-Ow; Wed, 20 Mar 2024 09:30:28 +0000
Received: by outflank-mailman (input) for mailman id 695832;
 Wed, 20 Mar 2024 09:30:27 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1rmsHD-00063D-3D
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 09:30:27 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmsHC-0002bc-JI; Wed, 20 Mar 2024 09:30:26 +0000
Received: from gw1.octic.net ([88.97.20.152] helo=[10.0.1.240])
 by xenbits.xenproject.org with esmtpsa
 (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92)
 (envelope-from )
 id 1rmsHC-0003As-Cp; Wed, 20 Mar 2024 09:30:26 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=4FbetOi/3Ab3QJN9s09ElkGp8JY7Pxge5atD5lan0Hk=; b=S5Anm6PWeyW4fj9moF2wedJ7Nu
	/OaaMyB+Dhca3EeImUaNfgQIXd5e3l38GUjHMBxs2HTT6tk/NAkNBqsrlYI6jlV6c3IHCAJXfMPPs
	ZDk2lb9foD2Ea3isumtlNXneu4bKkFzXSTxA/dpsA1RfqbDg2EcCKSBEZi5SmCWWSqdg=;
Message-ID: <72a2fa69-7e10-4282-ad7e-77b2f8f19548@xen.org>
Date: Wed, 20 Mar 2024 09:30:24 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 03/11] xen/arm: Introduce a generic way to access memory
 bank structures
Content-Language: en-GB
To: Michal Orzel , Luca Fancellu
 , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
 Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20240312130331.78418-1-luca.fancellu@arm.com>
 <20240312130331.78418-4-luca.fancellu@arm.com>
 <73dbf297-31ed-4cf1-b081-c6f82c234de8@amd.com>
From: Julien Grall 
In-Reply-To: <73dbf297-31ed-4cf1-b081-c6f82c234de8@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit



On 19/03/2024 13:10, Michal Orzel wrote:
> Hi Luca,
> 
> On 12/03/2024 14:03, Luca Fancellu wrote:
>>
>>
>> Currently the 'stuct meminfo' is defining a static defined array of
>> 'struct membank' of NR_MEM_BANKS elements, some feature like
>> shared memory don't require such amount of memory allocation but
>> might want to reuse existing code to manipulate this kind of
>> structure that is just as 'struct meminfo' but less bulky.
>>
>> For this reason introduce a generic way to access this kind of
>> structure using a new stucture 'struct membanks', which implements
> s/stucture/structure
> 
>> all the fields needed by a structure related to memory banks
>> without the need to specify at build time the size of the
>> 'struct membank' array.
> Might be beneficial here to mention the use of FAM.
I had to look it up online and there was no hit on Google. I guess you 
mean "Flexible Array Member".

>> Modify 'struct meminfo' to implement the field related to the new
>> introduced structure, given the change all usage of this structure
>> are updated in this way:
>>   - code accessing bootinfo.{mem,reserved_mem,acpi} field now uses
>>     3 new introduced static inline helpers to access the new field
>>     of 'struct meminfo' named 'common'.
>>   - code accessing 'struct kernel_info *' member 'mem' now use the
>>     new introduced macro 'kernel_info_get_mem(...)' to access the
>>     new field of 'struct meminfo' named 'common'.
>>
>> Constify pointers where needed.
>>
>> Suggested-by: Julien Grall 
>> Signed-off-by: Luca Fancellu 
>> ---
>>   xen/arch/arm/acpi/domain_build.c        |   6 +-
>>   xen/arch/arm/arm32/mmu/mm.c             |  44 +++++-----
>>   xen/arch/arm/arm64/mmu/mm.c             |   2 +-
>>   xen/arch/arm/bootfdt.c                  |  27 +++---
>>   xen/arch/arm/dom0less-build.c           |  18 ++--
>>   xen/arch/arm/domain_build.c             | 106 +++++++++++++-----------
>>   xen/arch/arm/efi/efi-boot.h             |   8 +-
>>   xen/arch/arm/efi/efi-dom0.c             |  13 +--
>>   xen/arch/arm/include/asm/domain_build.h |   2 +-
>>   xen/arch/arm/include/asm/kernel.h       |   9 ++
>>   xen/arch/arm/include/asm/setup.h        |  40 ++++++++-
>>   xen/arch/arm/include/asm/static-shmem.h |   4 +-
>>   xen/arch/arm/kernel.c                   |  12 +--
>>   xen/arch/arm/setup.c                    |  58 +++++++------
>>   xen/arch/arm/static-memory.c            |  27 +++---
>>   xen/arch/arm/static-shmem.c             |  34 ++++----
>>   16 files changed, 243 insertions(+), 167 deletions(-)
> Lots of mechanical changes but in general I like this approach.
> I'd like other maintainers to share their opinion.
I don't mind the churn so long we get a correct interface at the end. 
The current interface looks alright (I know I suggested it ;)).

> 
> [...]
> 
>> @@ -1157,10 +1163,12 @@ int __init make_hypervisor_node(struct domain *d,
>>       }
>>       else
>>       {
>> -        ext_regions = xzalloc(struct meminfo);
>> +        ext_regions = (struct membanks *)xzalloc(struct meminfo);
> You're making assumption that struct membanks is the first member of meminfo but there's no sanity check.
> Why not xzalloc_flex_struct()?
> 
>>           if ( !ext_regions )
>>               return -ENOMEM;
> 
> [...]
>> diff --git a/xen/arch/arm/include/asm/kernel.h b/xen/arch/arm/include/asm/kernel.h
>> index 0a23e86c2d37..d28b843c01a9 100644
>> --- a/xen/arch/arm/include/asm/kernel.h
>> +++ b/xen/arch/arm/include/asm/kernel.h
>> @@ -78,6 +78,15 @@ struct kernel_info {
>>       };
>>   };
>>
>> +#define kernel_info_get_mem(kinfo) \
>> +    (&(kinfo)->mem.common)
> Why this is a macro but for bootinfo you use static inline helpers?
> 
>> +
>> +#define KERNEL_INFO_INIT \
> NIT: in most places we prefer \ to be aligned (the same apply to other places)
> 
>> +{ \
>> +    .mem.common.max_banks = NR_MEM_BANKS, \
>> +    .shm_mem.common.max_banks = NR_MEM_BANKS, \
>> +}
>> +
>>   /*
>>    * Probe the kernel to detemine its type and select a loader.
>>    *
>> diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h
>> index d15a88d2e0d1..a3e1dc8fdb6c 100644
>> --- a/xen/arch/arm/include/asm/setup.h
>> +++ b/xen/arch/arm/include/asm/setup.h
>> @@ -56,8 +56,14 @@ struct membank {
>>   #endif
>>   };
>>
>> -struct meminfo {
>> +struct membanks {
>>       unsigned int nr_banks;
>> +    unsigned int max_banks;
>> +    struct membank bank[];
>> +};
>> +
>> +struct meminfo {
>> +    struct membanks common;
> You were supposed to make sure there is no extra padding here. I don't see any check in this patch.
> I'd at least do sth like:
> BUILD_BUG_ON((offsetof(struct membanks, bank)) != (offsetof(struct meminfo, bank)));

+1. You could also check that "struct membanks" is 8-byte aligned.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 09:33:50 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 09:33:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695834.1086009 (Exim 4.92)
	(envelope-from )
	id 1rmsKS-0007Hk-A4; Wed, 20 Mar 2024 09:33:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695834.1086009; Wed, 20 Mar 2024 09:33:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmsKS-0007Hd-6q; Wed, 20 Mar 2024 09:33:48 +0000
Received: by outflank-mailman (input) for mailman id 695834;
 Wed, 20 Mar 2024 09:33:47 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmsKR-0007F4-2C
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 09:33:47 +0000
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com
 [2a00:1450:4864:20::335])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f29a2a36-e69c-11ee-afdd-a90da7624cb6;
 Wed, 20 Mar 2024 10:33:45 +0100 (CET)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-4146a1b6faaso6670155e9.1
 for ; Wed, 20 Mar 2024 02:33:45 -0700 (PDT)
Received: from localhost ([85.31.135.62]) by smtp.gmail.com with ESMTPSA id
 r6-20020a05600c458600b00414108a1c55sm1633524wmo.16.2024.03.20.02.33.44
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 20 Mar 2024 02:33:44 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f29a2a36-e69c-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710927225; x=1711532025; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=Wov1slZmbAp2f5O4vnIaKKCu7WrBwjq873GuLyRqoUE=;
        b=M2Fls556LqEh/KZrvlmVKQToe/4m8vuM8g47jJXp+krieaD6oYKmecppSs3nIxduJZ
         /w7q+OGoDPw4SF5jL8hMwbfTjzX9osL+eCq0OBeBvOvotbxRWA0B3LFj6XEaUMxDwvvY
         tVVh6pQvF5aGLuC2p24W59bC1zWkhOMuVglmY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710927225; x=1711532025;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=Wov1slZmbAp2f5O4vnIaKKCu7WrBwjq873GuLyRqoUE=;
        b=Zp7H9WD40Y7xH/XFTsiU/eMq781bR5yiYjmsJDLQFSydhKMAu08GiP7rKfXt3p+VjC
         qLoNEuF6z161ha4BgjRZE8MLqRoggWFcHnSjVD6Jowb0kgm4V8MG+GeE2nesQ1S07plq
         3jKq/i5P8U+t2+1+faGpA7MdVRtpTIL0ai8DPsW/FlHN3pU5NwK9G35BfJVGC6jpFdhg
         npWff1p83qdxxHNbr9acpyNaj0Y7detAEzvZ0lP0WgB4PKfr7wDgfr2xfSUCOWX1Yla0
         45RszyMXmxH8HWQECF8KMrnC4Va+RwU1yJr9H0OwGub9alWNs3s9XIucxu/lcpMT9U7k
         4UgA==
X-Gm-Message-State: AOJu0YzQ1tXTvQkWfCf+lNqJgC6PK8TsdS0WcBMCzTl6mSh0MEpsyS21
	/3lJ/jyQAtd1ANXmVSqk+7ObindnXKO9GiAkBgzUgiPW3PA7xHbkuw1pOR6Rm6PB9ByrFIPbMbW
	H
X-Google-Smtp-Source: AGHT+IHmeLMTZJTuYf9kzj3bgxYVhI7NxlzoTIh7tpNJDxxjLgypfIG+JmENcZu22KjN7cm3QrAuIg==
X-Received: by 2002:a05:600c:314b:b0:413:7f3:8d5 with SMTP id h11-20020a05600c314b00b0041307f308d5mr11538791wmo.0.1710927224911;
        Wed, 20 Mar 2024 02:33:44 -0700 (PDT)
Date: Wed, 20 Mar 2024 10:33:43 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Alejandro Vallejo 
Cc: Xen-devel ,
	Jan Beulich ,
	Andrew Cooper , Wei Liu 
Subject: Re: [PATCH 1/6] xen/x86: Add initial x2APIC ID to the per-vLAPIC
 save area
Message-ID: 
References: <20240109153834.4192-1-alejandro.vallejo@cloud.com>
 <20240109153834.4192-2-alejandro.vallejo@cloud.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Tue, Mar 19, 2024 at 05:20:35PM +0100, Roger Pau Monné wrote:
> On Tue, Jan 09, 2024 at 03:38:29PM +0000, Alejandro Vallejo wrote:
> > This allows the initial x2APIC ID to be sent on the migration stream. The
> > hardcoded mapping x2apic_id=2*vcpu_id is maintained for the time being.
> > Given the vlapic data is zero-extended on restore, fix up migrations from
> > hosts without the field by setting it to the old convention if zero.
> > 
> > x2APIC IDs are calculated from the CPU policy where the guest topology is
> > defined. For the time being, the function simply returns the old
> > relationship, but will eventually return results consistent with the
> > topology.
> > 
> > Signed-off-by: Alejandro Vallejo 
> > ---
> >  xen/arch/x86/cpuid.c                   | 20 ++++---------------
> >  xen/arch/x86/domain.c                  |  3 +++
> >  xen/arch/x86/hvm/vlapic.c              | 27 ++++++++++++++++++++++++--
> >  xen/arch/x86/include/asm/hvm/vlapic.h  |  2 ++
> >  xen/include/public/arch-x86/hvm/save.h |  2 ++
> >  xen/include/xen/lib/x86/cpu-policy.h   |  9 +++++++++
> >  xen/lib/x86/policy.c                   | 11 +++++++++++
> >  7 files changed, 56 insertions(+), 18 deletions(-)
> > 
> > diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
> > index 7290a979c6..6e259785d0 100644
> > --- a/xen/arch/x86/cpuid.c
> > +++ b/xen/arch/x86/cpuid.c
> > @@ -139,10 +139,9 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
> >          const struct cpu_user_regs *regs;
> >  
> >      case 0x1:
> > -        /* TODO: Rework topology logic. */
> >          res->b &= 0x00ffffffu;
> >          if ( is_hvm_domain(d) )
> > -            res->b |= (v->vcpu_id * 2) << 24;
> > +            res->b |= SET_xAPIC_ID(vlapic_x2apic_id(vcpu_vlapic(v)));
> 
> SET_xAPIC_ID() was intended to be used with the APIC_ID register,
> which also shifts the ID.  Not sure it's logically correct to use
> here, even if functionally equivalent (as is shifts left by 24).
> 
> >  
> >          /* TODO: Rework vPMU control in terms of toolstack choices. */
> >          if ( vpmu_available(v) &&
> > @@ -311,20 +310,9 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
> >          break;
> >  
> >      case 0xb:
> > -        /*
> > -         * In principle, this leaf is Intel-only.  In practice, it is tightly
> > -         * coupled with x2apic, and we offer an x2apic-capable APIC emulation
> > -         * to guests on AMD hardware as well.
> > -         *
> > -         * TODO: Rework topology logic.
> > -         */
> > -        if ( p->basic.x2apic )
> > -        {
> > -            *(uint8_t *)&res->c = subleaf;
> > -
> > -            /* Fix the x2APIC identifier. */
> > -            res->d = v->vcpu_id * 2;
> > -        }
> > +        /* ecx != 0 if the subleaf is implemented */
> > +        if ( res->c && p->basic.x2apic )
> > +            res->d = vlapic_x2apic_id(vcpu_vlapic(v));
> 
> This needs to be protected so it's reachable by HVM guests only,
> otherwise you will dereference v->arch.hvm.vlapic on a PV vCPU if it
> happens to have p->basic.x2apic set.
> 
> Why not just return the x2apic_id field from the cpu_policy object?
> (topo.subleaf[X].x2apic_id)

Scratch that, the cpu policy is per-domain, not per-vcpu, and hence
cannot hold the x{,2}apic IDs.

> Also, I'm not sure I get why the setting of res->d is gated on res->c
> != 0, won't res->c be 0 when the guest %ecx is 0, yet %edx must be
> valid for all %ecx inputs, the SDM states:
> 
> "The EDX output of leaf 0BH is always valid and does not vary with
> input value in ECX."
> 
> I think you need to keep the previous logic that doesn't gate setting
> ->d on anything other than p->basic.x2apic.
> 
> >          break;
> >  
> >      case XSTATE_CPUID:
> > diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> > index 8a31d18f69..e0c7ed8d5d 100644
> > --- a/xen/arch/x86/domain.c
> > +++ b/xen/arch/x86/domain.c
> > @@ -288,7 +288,10 @@ void update_guest_memory_policy(struct vcpu *v,
> >  static void cpu_policy_updated(struct vcpu *v)
> >  {
> >      if ( is_hvm_vcpu(v) )
> > +    {
> >          hvm_cpuid_policy_changed(v);
> > +        vlapic_cpu_policy_changed(v);
> > +    }
> >  }
> >  
> >  void domain_cpu_policy_changed(struct domain *d)
> > diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
> > index cdb69d9742..f500d66543 100644
> > --- a/xen/arch/x86/hvm/vlapic.c
> > +++ b/xen/arch/x86/hvm/vlapic.c
> > @@ -1069,7 +1069,7 @@ static uint32_t x2apic_ldr_from_id(uint32_t id)
> >  static void set_x2apic_id(struct vlapic *vlapic)
> >  {
> >      const struct vcpu *v = vlapic_vcpu(vlapic);
> > -    uint32_t apic_id = v->vcpu_id * 2;
> > +    uint32_t apic_id = vlapic->hw.x2apic_id;
> >      uint32_t apic_ldr = x2apic_ldr_from_id(apic_id);
> >  
> >      /*
> > @@ -1083,6 +1083,22 @@ static void set_x2apic_id(struct vlapic *vlapic)
> >      vlapic_set_reg(vlapic, APIC_LDR, apic_ldr);
> >  }
> >  
> > +void vlapic_cpu_policy_changed(struct vcpu *v)
> > +{
> > +    struct vlapic *vlapic = vcpu_vlapic(v);
> > +    struct cpu_policy *cp = v->domain->arch.cpu_policy;
> > +
> > +    /*
> > +     * Don't override the initial x2APIC ID if we have migrated it or
> > +     * if the domain doesn't have vLAPIC at all.
> > +     */
> > +    if ( !has_vlapic(v->domain) || vlapic->loaded.hw )
> > +        return;
> > +
> > +    vlapic->hw.x2apic_id = x86_x2apic_id_from_vcpu_id(cp, v->vcpu_id);
> > +    vlapic_set_reg(vlapic, APIC_ID, SET_xAPIC_ID(vlapic->hw.x2apic_id));
> > +}
> > +
> >  int guest_wrmsr_apic_base(struct vcpu *v, uint64_t val)
> >  {
> >      const struct cpu_policy *cp = v->domain->arch.cpu_policy;
> > @@ -1449,7 +1465,7 @@ void vlapic_reset(struct vlapic *vlapic)
> >      if ( v->vcpu_id == 0 )
> >          vlapic->hw.apic_base_msr |= APIC_BASE_BSP;
> >  
> > -    vlapic_set_reg(vlapic, APIC_ID, (v->vcpu_id * 2) << 24);
> > +    vlapic_set_reg(vlapic, APIC_ID, SET_xAPIC_ID(vlapic->hw.x2apic_id));
> >      vlapic_do_init(vlapic);
> >  }
> >  
> > @@ -1514,6 +1530,13 @@ static void lapic_load_fixup(struct vlapic *vlapic)
> >      const struct vcpu *v = vlapic_vcpu(vlapic);
> >      uint32_t good_ldr = x2apic_ldr_from_id(vlapic->loaded.id);
> >  
> > +    /*
> > +     * Guest with hardcoded assumptions about x2apic_id <-> vcpu_id
> > +     * mappings. Recreate the mapping it used to have in old host.
> 
> Wouldn't it be more appropriate to state "Loading record without
> hw.x2apic_id in the save stream, calculate using the vcpu_id * 2
> relation" or some such.
> 
> Current comment makes it looks like the guest has some kind of
> restriction with this relation, but that's just an internal Xen
> limitation.
> 
> > +     */
> > +    if ( !vlapic->hw.x2apic_id )
> > +        vlapic->hw.x2apic_id = v->vcpu_id * 2;
> > +
> >      /* Skip fixups on xAPIC mode, or if the x2APIC LDR is already correct */
> >      if ( !vlapic_x2apic_mode(vlapic) ||
> >           (vlapic->loaded.ldr == good_ldr) )
> > diff --git a/xen/arch/x86/include/asm/hvm/vlapic.h b/xen/arch/x86/include/asm/hvm/vlapic.h
> > index 88ef945243..e8d41313ab 100644
> > --- a/xen/arch/x86/include/asm/hvm/vlapic.h
> > +++ b/xen/arch/x86/include/asm/hvm/vlapic.h
> > @@ -44,6 +44,7 @@
> >  #define vlapic_xapic_mode(vlapic)                               \
> >      (!vlapic_hw_disabled(vlapic) && \
> >       !((vlapic)->hw.apic_base_msr & APIC_BASE_EXTD))
> > +#define vlapic_x2apic_id(vlapic) ((vlapic)->hw.x2apic_id)
> >  
> >  /*
> >   * Generic APIC bitmap vector update & search routines.
> > @@ -107,6 +108,7 @@ int vlapic_ack_pending_irq(struct vcpu *v, int vector, bool force_ack);
> >  
> >  int  vlapic_init(struct vcpu *v);
> >  void vlapic_destroy(struct vcpu *v);
> > +void vlapic_cpu_policy_changed(struct vcpu *v);
> >  
> >  void vlapic_reset(struct vlapic *vlapic);
> >  
> > diff --git a/xen/include/public/arch-x86/hvm/save.h b/xen/include/public/arch-x86/hvm/save.h
> > index 7ecacadde1..1c2ec669ff 100644
> > --- a/xen/include/public/arch-x86/hvm/save.h
> > +++ b/xen/include/public/arch-x86/hvm/save.h
> > @@ -394,6 +394,8 @@ struct hvm_hw_lapic {
> >      uint32_t             disabled; /* VLAPIC_xx_DISABLED */
> >      uint32_t             timer_divisor;
> >      uint64_t             tdt_msr;
> > +    uint32_t             x2apic_id;
> > +    uint32_t             rsvd_zero;
> 
> Do we really to add a new field, couldn't we get the lapic IDs from
> the cpu_policy?

Since getting from the cpu_policy is not possible, what about getting
it from the registers itself?  It's already present in hvm_hw_lapic_regs.

Regards, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 09:51:01 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 09:51:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695839.1086019 (Exim 4.92)
	(envelope-from )
	id 1rmsb2-0002K2-Pe; Wed, 20 Mar 2024 09:50:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695839.1086019; Wed, 20 Mar 2024 09:50:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmsb2-0002Jv-My; Wed, 20 Mar 2024 09:50:56 +0000
Received: by outflank-mailman (input) for mailman id 695839;
 Wed, 20 Mar 2024 09:50:56 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmsb2-0002Jm-4Q
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 09:50:56 +0000
Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com
 [2607:f8b0:4864:20::22e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 57083d13-e69f-11ee-a1ee-f123f15fe8a2;
 Wed, 20 Mar 2024 10:50:53 +0100 (CET)
Received: by mail-oi1-x22e.google.com with SMTP id
 5614622812f47-3c398187b4dso940687b6e.0
 for ; Wed, 20 Mar 2024 02:50:54 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 57083d13-e69f-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1710928253; x=1711533053; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=KiGcr24ALFDS/AFNc6B2F+49LphSOS0U2lgmpSIjAGs=;
        b=FqTsi6htb4NSjsRSYoJmWbKaYktD3UmdD8JbR0K9g71do+Z0RzheGZB5kiRsVd09oY
         3ONQTOp8X7pn8h4/2lSZLxjZTEnn4vxTTT2oE7u4+KHSs2Y1BZsF2eLF4bHj+joBexOy
         f96xHRs6yLyvPbKoqIWQRNeJtwExThRMsxCwc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710928253; x=1711533053;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=KiGcr24ALFDS/AFNc6B2F+49LphSOS0U2lgmpSIjAGs=;
        b=YRBmE7WgNGVdTHqhboeXbj7IA+UExr2MWoe28QnrIm9TF6vyR4ElSsaTbdTPerLemJ
         2KYFkg4gTtD0y1alvREdV82VAfS870srfYzhDZ57/5ecAOvvMW+5BTkvuOswOXVaRJwC
         jM10ArcuMlT8c41O69lxIGX4+Ut41d/h048ShVCtnDbM9bGgFCUtsmgboE4zRVye+l/M
         K8EeLKfIeB5jGQopnpHSSqtaECw8P9bK4bwWbNO3H4kT3+fk/+mjT0lpL/Qpon1c/pug
         0xzq9v/oRfEIuNGJ8oDgD/7Py9b6n4uY6xe7791AsMl0//fir3hZd5OdULfXeppJRs+D
         IIDA==
X-Gm-Message-State: AOJu0YwEp8Q94NwB7WGw8H1C4XoZ+i/EIytA0NDDKrTcPajwY82cL6L4
	e6zHZcFdqb/G6FOyEjm0UEWMFGaYFLKJmRzpIb0siq1hLUokrIXNwC0LtcdLWAX7wYv/LyfhWuO
	tmL1FVXwaP4EJLpQ6iSe9hDn3s+HxxjIX4fy2lg==
X-Google-Smtp-Source: AGHT+IEtMsUCxFWtGS52erNN8sWe5cUHNtN3MipyAOnDBVHApmaVv32i6YQR4iN8riL2uGo9aExmUc3sYO3T/40S4fk=
X-Received: by 2002:a05:6870:503:b0:221:42a1:9457 with SMTP id
 j3-20020a056870050300b0022142a19457mr5391860oao.9.1710928252819; Wed, 20 Mar
 2024 02:50:52 -0700 (PDT)
MIME-Version: 1.0
References:  <95699d2c-7e2a-40db-875f-907990797317@suse.com>
In-Reply-To: <95699d2c-7e2a-40db-875f-907990797317@suse.com>
From: George Dunlap 
Date: Wed, 20 Mar 2024 09:50:41 +0000
Message-ID: 
Subject: Re: [PATCH v5] x86/PoD: tie together P2M update and increment of
 entry count
To: Jan Beulich 
Cc: "xen-devel@lists.xenproject.org" , 
	Andrew Cooper , Wei Liu , 
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Mar 19, 2024 at 1:22=E2=80=AFPM Jan Beulich  wro=
te:
>
> When not holding the PoD lock across the entire region covering P2M
> update and stats update, the entry count - if to be incorrect at all -
> should indicate too large a value in preference to a too small one, to
> avoid functions bailing early when they find the count is zero. However,
> instead of moving the increment ahead (and adjust back upon failure),
> extend the PoD-locked region.
>
> Fixes: 99af3cd40b6e ("x86/mm: Rework locking in the PoD layer")
> Signed-off-by: Jan Beulich 

Oh!  Thanks for doing this -- I hadn't responded because I wasn't sure
whether I was bikeshedding, and then it sort of fell off my radar.  At
any rate:

Reviewed-by: George Dunlap 


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 10:16:11 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 10:16:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695842.1086029 (Exim 4.92)
	(envelope-from )
	id 1rmszF-0006re-P1; Wed, 20 Mar 2024 10:15:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695842.1086029; Wed, 20 Mar 2024 10:15:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmszF-0006rX-KW; Wed, 20 Mar 2024 10:15:57 +0000
Received: by outflank-mailman (input) for mailman id 695842;
 Wed, 20 Mar 2024 10:15:57 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmszF-0006rM-0U
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 10:15:57 +0000
Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com
 [2607:f8b0:4864:20::72f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d489a695-e6a2-11ee-a1ee-f123f15fe8a2;
 Wed, 20 Mar 2024 11:15:52 +0100 (CET)
Received: by mail-qk1-x72f.google.com with SMTP id
 af79cd13be357-789f1b59a28so240029685a.3
 for ; Wed, 20 Mar 2024 03:15:52 -0700 (PDT)
Received: from localhost ([85.31.135.62]) by smtp.gmail.com with ESMTPSA id
 wj18-20020a05620a575200b00789e7ddf8a5sm4733604qkn.17.2024.03.20.03.15.50
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 20 Mar 2024 03:15:51 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d489a695-e6a2-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710929752; x=1711534552; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=c4HjjdW+jTvr14dLOqe97qddyAnOoGqhxHjAWy88ljo=;
        b=UQJZ3b0UPhQPMwF0VHXnK2VAO09oGfwc3YA+2eGO0hdyakppHIjB83zSQ3VL4of2br
         wH1vq/lQqd0FRc8kq+/dBoJlAYHUMi7mnGkh9AjzvZr018slrT8YPg9wyFsYSTd93b7N
         MZ7hT8jRsuDbg9a8OrxclXxKYJcs/x6Ac82SA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710929752; x=1711534552;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=c4HjjdW+jTvr14dLOqe97qddyAnOoGqhxHjAWy88ljo=;
        b=izj3Q315VTrYa62IM+uYnGGIiiw66mh/kNTjYafq80WCRIgrWj72832VvjIVSRrEf/
         5D0TfXgNFxLDeH9mnRdqkU002GwFwbkHLTcp7srY1DomdnasckFyE+LANNqhqcUFqsWU
         h3bkGTxr56+J5OcOLgEUl2HlTJ7ZHT0Rg51FqcyCgs7RUbCm+xgpy2064amk8/PCKxo2
         EAvBNk8lcBcmgJQI61ZswQi7BsorqrkIiWNXv9pKW1sF1NA+8ovCqXaKalFNOZ1bEwoC
         oZu6dkmqLuVyNFnHrtv8MYXO05ud4se+EmFcOcGr5fmmakep4k7HfnhI467nxnt0vrXL
         LvPw==
X-Gm-Message-State: AOJu0Yxi6oCXl+hJ7+kwgmHabunSwy2KbEHx1Pa+saKSK+Rempq3WRKV
	j557+79RJRn2he64o30VuMogDMy8CFQsdQJ5DpBlNPzCqyQzP0HD+7pqxPE0eA0=
X-Google-Smtp-Source: AGHT+IFabEO3CtLSxc0P/ZbUPjk1MoFAplibhlPpDrjEEC61aQzR+zwvJWmY1VRe+FQulquyb1C/bw==
X-Received: by 2002:a05:620a:13d1:b0:789:e703:675 with SMTP id g17-20020a05620a13d100b00789e7030675mr15003883qkl.15.1710929751720;
        Wed, 20 Mar 2024 03:15:51 -0700 (PDT)
Date: Wed, 20 Mar 2024 11:15:49 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Alejandro Vallejo 
Cc: Xen-devel ,
	Jan Beulich ,
	Andrew Cooper , Wei Liu ,
	Anthony PERARD 
Subject: Re: [PATCH 5/6] xen/x86: Derive topologically correct x2APIC IDs
 from the policy
Message-ID: 
References: <20240109153834.4192-1-alejandro.vallejo@cloud.com>
 <20240109153834.4192-6-alejandro.vallejo@cloud.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20240109153834.4192-6-alejandro.vallejo@cloud.com>

On Tue, Jan 09, 2024 at 03:38:33PM +0000, Alejandro Vallejo wrote:
> Implements the helper for mapping vcpu_id to x2apic_id given a valid
> topology in a policy. The algo is written with the intention of extending
> it to leaves 0x1f and e26 in the future.
> 
> Toolstack doesn't set leaf 0xb and the HVM default policy has it cleared,
> so the leaf is not implemented. In that case, the new helper just returns
> the legacy mapping.
> 
> Signed-off-by: Alejandro Vallejo 
> ---
>  tools/tests/cpu-policy/test-cpu-policy.c | 128 +++++++++++++++++++++++
>  xen/include/xen/lib/x86/cpu-policy.h     |   2 +
>  xen/lib/x86/policy.c                     |  75 +++++++++++--
>  3 files changed, 199 insertions(+), 6 deletions(-)
> 
> diff --git a/tools/tests/cpu-policy/test-cpu-policy.c b/tools/tests/cpu-policy/test-cpu-policy.c
> index 301df2c002..6ff5c1dd3d 100644
> --- a/tools/tests/cpu-policy/test-cpu-policy.c
> +++ b/tools/tests/cpu-policy/test-cpu-policy.c
> @@ -650,6 +650,132 @@ static void test_is_compatible_failure(void)
>      }
>  }
>  
> +static void test_x2apic_id_from_vcpu_id_success(void)
> +{
> +    static struct test {

const

> +        const char *name;
> +        uint32_t vcpu_id;
> +        uint32_t x2apic_id;
> +        struct cpu_policy policy;
> +    } tests[] = {
> +        {
> +            .name = "3v: 3 t/c, 8 c/s", .vcpu_id = 3, .x2apic_id = 1 << 2,
> +            .policy = {
> +                .x86_vendor = X86_VENDOR_AMD,
> +                .topo.subleaf = {
> +                    [0] = { .nr_logical = 3, .level = 0, .type = 1, .id_shift = 2, },
> +                    [1] = { .nr_logical = 8, .level = 1, .type = 2, .id_shift = 5, },
> +                },

Don't we need a helper that gets passed the number of cores per
socket and threads per core and fills this up?

I would introduce this first, add a test for it, and then do this
testing using the helper.

> +            },
> +        },
> +        {
> +            .name = "6v: 3 t/c, 8 c/s", .vcpu_id = 6, .x2apic_id = 2 << 2,
> +            .policy = {
> +                .x86_vendor = X86_VENDOR_AMD,
> +                .topo.subleaf = {
> +                    [0] = { .nr_logical = 3, .level = 0, .type = 1, .id_shift = 2, },
> +                    [1] = { .nr_logical = 8, .level = 1, .type = 2, .id_shift = 5, },
> +                },
> +            },
> +        },
> +        {
> +            .name = "24v: 3 t/c, 8 c/s", .vcpu_id = 24, .x2apic_id = 1 << 5,
> +            .policy = {
> +                .x86_vendor = X86_VENDOR_AMD,
> +                .topo.subleaf = {
> +                    [0] = { .nr_logical = 3, .level = 0, .type = 1, .id_shift = 2, },
> +                    [1] = { .nr_logical = 8, .level = 1, .type = 2, .id_shift = 5, },
> +                },
> +            },
> +        },
> +        {
> +            .name = "35v: 3 t/c, 8 c/s", .vcpu_id = 35,
> +            .x2apic_id = (35 % 3) | (((35 / 3) % 8)  << 2) | ((35 / 24) << 5),
> +            .policy = {
> +                .x86_vendor = X86_VENDOR_AMD,
> +                .topo.subleaf = {
> +                    [0] = { .nr_logical = 3, .level = 0, .type = 1, .id_shift = 2, },
> +                    [1] = { .nr_logical = 8, .level = 1, .type = 2, .id_shift = 5, },
> +                },
> +            },
> +        },
> +        {
> +            .name = "96v: 7 t/c, 3 c/s", .vcpu_id = 96,
> +            .x2apic_id = (96 % 7) | (((96 / 7) % 3)  << 3) | ((96 / 21) << 5),
> +            .policy = {
> +                .x86_vendor = X86_VENDOR_AMD,
> +                .topo.subleaf = {
> +                    [0] = { .nr_logical = 7, .level = 0, .type = 1, .id_shift = 3, },
> +                    [1] = { .nr_logical = 3, .level = 1, .type = 2, .id_shift = 5, },
> +                },
> +            },
> +        },
> +        {
> +            .name = "3v: 3 t/c, 8 c/s", .vcpu_id = 3, .x2apic_id = 1 << 2,
> +            .policy = {
> +                .x86_vendor = X86_VENDOR_INTEL,
> +                .topo.subleaf = {
> +                    [0] = { .nr_logical = 3,  .level = 0, .type = 1, .id_shift = 2, },
> +                    [1] = { .nr_logical = 24, .level = 1, .type = 2, .id_shift = 5, },
> +                },
> +            },
> +        },
> +        {
> +            .name = "6v: 3 t/c, 8 c/s", .vcpu_id = 6, .x2apic_id = 2 << 2,
> +            .policy = {
> +                .x86_vendor = X86_VENDOR_INTEL,
> +                .topo.subleaf = {
> +                    [0] = { .nr_logical = 3,  .level = 0, .type = 1, .id_shift = 2, },
> +                    [1] = { .nr_logical = 24, .level = 1, .type = 2, .id_shift = 5, },
> +                },
> +            },
> +        },
> +        {
> +            .name = "24v: 3 t/c, 8 c/s", .vcpu_id = 24, .x2apic_id = 1 << 5,
> +            .policy = {
> +                .x86_vendor = X86_VENDOR_INTEL,
> +                .topo.subleaf = {
> +                    [0] = { .nr_logical = 3,  .level = 0, .type = 1, .id_shift = 2, },
> +                    [1] = { .nr_logical = 24, .level = 1, .type = 2, .id_shift = 5, },
> +                },
> +            },
> +        },
> +        {
> +            .name = "35v: 3 t/c, 8 c/s", .vcpu_id = 35,
> +            .x2apic_id = (35 % 3) | (((35 / 3) % 8)  << 2) | ((35 / 24) << 5),
> +            .policy = {
> +                .x86_vendor = X86_VENDOR_INTEL,
> +                .topo.subleaf = {
> +                    [0] = { .nr_logical = 3,  .level = 0, .type = 1, .id_shift = 2, },
> +                    [1] = { .nr_logical = 24, .level = 1, .type = 2, .id_shift = 5, },
> +                },
> +            },
> +        },
> +        {
> +            .name = "96v: 7 t/c, 3 c/s", .vcpu_id = 96,
> +            .x2apic_id = (96 % 7) | (((96 / 7) % 3)  << 3) | ((96 / 21) << 5),
> +            .policy = {
> +                .x86_vendor = X86_VENDOR_INTEL,
> +                .topo.subleaf = {
> +                    [0] = { .nr_logical = 7,   .level = 0, .type = 1, .id_shift = 3, },
> +                    [1] = { .nr_logical = 21,  .level = 1, .type = 2, .id_shift = 5, },
> +                },
> +            },
> +        },
> +    };
> +
> +    printf("Testing x2apic id from vcpu id success:\n");
> +
> +    for ( size_t i = 0; i < ARRAY_SIZE(tests); ++i )
> +    {
> +        struct test *t = &tests[i];

const

> +        uint32_t x2apic_id = x86_x2apic_id_from_vcpu_id(&t->policy, t->vcpu_id);

Newline preferably.

> +        if ( x2apic_id != t->x2apic_id )
> +            fail("FAIL - '%s'. bad x2apic_id: expected=%u actual=%u\n",
> +                 t->name, t->x2apic_id, x2apic_id);
> +    }
> +}
> +
>  int main(int argc, char **argv)
>  {
>      printf("CPU Policy unit tests\n");
> @@ -667,6 +793,8 @@ int main(int argc, char **argv)
>      test_is_compatible_success();
>      test_is_compatible_failure();
>  
> +    test_x2apic_id_from_vcpu_id_success();
> +
>      if ( nr_failures )
>          printf("Done: %u failures\n", nr_failures);
>      else
> diff --git a/xen/include/xen/lib/x86/cpu-policy.h b/xen/include/xen/lib/x86/cpu-policy.h
> index 65f6335b32..d81ae2f47c 100644
> --- a/xen/include/xen/lib/x86/cpu-policy.h
> +++ b/xen/include/xen/lib/x86/cpu-policy.h
> @@ -550,6 +550,8 @@ int x86_cpu_policies_are_compatible(const struct cpu_policy *host,
>  /**
>   * Calculates the x2APIC ID of a vCPU given a CPU policy
>   *
> + * If the policy lacks leaf 0xb falls back to legacy mapping of apic_id=cpu*2
> + *
>   * @param p          CPU policy of the domain.
>   * @param vcpu_id    vCPU ID of the vCPU.
>   * @returns x2APIC ID of the vCPU.
> diff --git a/xen/lib/x86/policy.c b/xen/lib/x86/policy.c
> index a3b24e6879..2a50bc076a 100644
> --- a/xen/lib/x86/policy.c
> +++ b/xen/lib/x86/policy.c
> @@ -2,15 +2,78 @@
>  
>  #include 
>  
> -uint32_t x86_x2apic_id_from_vcpu_id(const struct cpu_policy *p, uint32_t vcpu_id)
> +static uint32_t parts_per_higher_scoped_level(const struct cpu_policy *p, size_t lvl)
>  {
>      /*
> -     * TODO: Derive x2APIC ID from the topology information inside `p`
> -     *       rather than from vCPU ID. This bodge is a temporary measure
> -     *       until all infra is in place to retrieve or derive the initial
> -     *       x2APIC ID from migrated domains.
> +     * `nr_logical` reported by Intel is the number of THREADS contained in
> +     * the next topological scope. For example, assuming a system with 2
> +     * threads/core and 3 cores/module in a fully symmetric topology,
> +     * `nr_logical` at the core level will report 6. Because it's reporting
> +     * the number of threads in a module.
> +     *
> +     * On AMD/Hygon, nr_logical is already normalized by the higher scoped
> +     * level (cores/complex, etc) so we can return it as-is.
>       */
> -    return vcpu_id * 2;
> +    if ( p->x86_vendor != X86_VENDOR_INTEL || !lvl )
> +        return p->topo.subleaf[lvl].nr_logical;
> +
> +    return p->topo.subleaf[lvl].nr_logical / p->topo.subleaf[lvl - 1].nr_logical;

I think this is an optimization because we only have 2 levels,
otherwise you would need a loop like:

unsigned int nr = p->topo.subleaf[lvl].nr_logical
for ( unsigned int i; i < lvl; i++ )
    nr /= p->topo.subleaf[i].nr_logical;

If that's the case I think we need a
BUILD_BUG_ON(ARRAY_SIZE(p->topo.subleaf) > 1);

> +}
> +
> +uint32_t x86_x2apic_id_from_vcpu_id(const struct cpu_policy *p, uint32_t id)

Can you keep the previous vcpu_id parameter name?  Or alternatively
adjust the prototype to also be id.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 10:30:02 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 10:30:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695845.1086039 (Exim 4.92)
	(envelope-from )
	id 1rmtCm-00012B-U7; Wed, 20 Mar 2024 10:29:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695845.1086039; Wed, 20 Mar 2024 10:29:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmtCm-000124-Q7; Wed, 20 Mar 2024 10:29:56 +0000
Received: by outflank-mailman (input) for mailman id 695845;
 Wed, 20 Mar 2024 10:29:55 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmtCl-00011y-T3
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 10:29:55 +0000
Received: from mail-qv1-xf36.google.com (mail-qv1-xf36.google.com
 [2607:f8b0:4864:20::f36])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ca686045-e6a4-11ee-afdd-a90da7624cb6;
 Wed, 20 Mar 2024 11:29:54 +0100 (CET)
Received: by mail-qv1-xf36.google.com with SMTP id
 6a1803df08f44-6962950c6bfso18391896d6.2
 for ; Wed, 20 Mar 2024 03:29:54 -0700 (PDT)
Received: from localhost ([85.31.135.62]) by smtp.gmail.com with ESMTPSA id
 ff7-20020a0562140bc700b00691823f0980sm6058550qvb.0.2024.03.20.03.29.52
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 20 Mar 2024 03:29:53 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ca686045-e6a4-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710930593; x=1711535393; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=1hmVZ4+5+0fNwvZlaQM/m0KtR/kGoLvMMhEnvLzTk54=;
        b=WS0dYfDKePmCjhdzmuxwj+MCniCvznJaA9WjE293Flr3uVrdMUuQScu3I1vzBksCjm
         mhGN4L936i2KPxdvpebwUa++4DwAD+LrcBjlZY9ExCOyXFdA/Dwv8J7SGwqSQfv0d/rS
         1F80G+/sYtpJFy9gCNvcykEVef+IPy9MfkVKM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710930593; x=1711535393;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=1hmVZ4+5+0fNwvZlaQM/m0KtR/kGoLvMMhEnvLzTk54=;
        b=J81ghsP8vGdNwOxz5ARYLLv26QdCZBrlsJ4yeRgHPZBUxBNVlcZPd28dfHp91wj2/N
         6MdWEZ1MbNgIT59ai9xeHTrxCAq0K7fY3nRjPScMecfqIp6vsHK2Guf8Yxikt5PhghJ7
         TZxlV/AiDlxyMuNfQ34jZV260sOlJHMrrIT7C2EjyirzE7eFf16kfDFkYKiQH8rhLJ8d
         aXX9J+SSG9pAEYEvFBrq9prJhv/ZBng5meBJKw3NL/xZ6OYTINE99jBI5SJhYLRHQo9H
         iA2QIGHYOlRGKaXCVg4tGs4pPBCRacCCTT6dKoKnAuNpgSgRyNCFypWqDQzNhW1bbe2+
         sXaw==
X-Gm-Message-State: AOJu0YyFwhnYeW20Wdb63L7IfciJA+9aaSFbfQBsD+ES27Kh9PpLvBIJ
	hZHQyEOFZQNn/3z6i/NKGz0Ohq8WVxOD2gyemWTjGgW0W1pmUvyP/SBwDAyr2w8=
X-Google-Smtp-Source: AGHT+IG51sWuWUQEL848x8erv1rYW1ylxELTIBf9Ry4ICLJktKO0EHkaR852yxGzVhNd2U3A+Q9IoA==
X-Received: by 2002:a05:6214:8d2:b0:691:51d4:c40c with SMTP id da18-20020a05621408d200b0069151d4c40cmr16417177qvb.18.1710930593357;
        Wed, 20 Mar 2024 03:29:53 -0700 (PDT)
Date: Wed, 20 Mar 2024 11:29:50 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Alejandro Vallejo 
Cc: Xen-devel , Wei Liu ,
	Anthony PERARD ,
	Juergen Gross , Jan Beulich ,
	Andrew Cooper 
Subject: Re: [PATCH 6/6] xen/x86: Add topology generator
Message-ID: 
References: <20240109153834.4192-1-alejandro.vallejo@cloud.com>
 <20240109153834.4192-7-alejandro.vallejo@cloud.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20240109153834.4192-7-alejandro.vallejo@cloud.com>

On Tue, Jan 09, 2024 at 03:38:34PM +0000, Alejandro Vallejo wrote:
> This allows toolstack to synthesise sensible topologies for guests. In
> particular, this patch causes x2APIC IDs to be packed according to the
> topology now exposed to the guests on leaf 0xb.
> 
> Signed-off-by: Alejandro Vallejo 
> ---
>  tools/include/xenguest.h        |  15 ++++
>  tools/libs/guest/xg_cpuid_x86.c | 144 ++++++++++++++++++++------------
>  xen/arch/x86/cpu-policy.c       |   6 +-
>  3 files changed, 107 insertions(+), 58 deletions(-)
> 
> diff --git a/tools/include/xenguest.h b/tools/include/xenguest.h
> index 4e9078fdee..f0043c559b 100644
> --- a/tools/include/xenguest.h
> +++ b/tools/include/xenguest.h
> @@ -843,5 +843,20 @@ enum xc_static_cpu_featuremask {
>      XC_FEATUREMASK_HVM_HAP_DEF,
>  };
>  const uint32_t *xc_get_static_cpu_featuremask(enum xc_static_cpu_featuremask);
> +
> +/**
> + * Synthesise topology information in `p` given high-level constraints
> + *
> + * Topology is given in various fields accross several leaves, some of
> + * which are vendor-specific. This function uses the policy itself to
> + * derive such leaves from threads/core and cores/package.
> + *
> + * @param p                   CPU policy of the domain.
> + * @param threads_per_core    threads/core. Doesn't need to be a power of 2.
> + * @param cores_per_package   cores/package. Doesn't need to be a power of 2.
> + */
> +void xc_topo_from_parts(struct cpu_policy *p,
> +                        uint32_t threads_per_core, uint32_t cores_per_pkg);

I think you can use plain unsigned int here.

> +
>  #endif /* __i386__ || __x86_64__ */
>  #endif /* XENGUEST_H */
> diff --git a/tools/libs/guest/xg_cpuid_x86.c b/tools/libs/guest/xg_cpuid_x86.c
> index 4453178100..7a622721be 100644
> --- a/tools/libs/guest/xg_cpuid_x86.c
> +++ b/tools/libs/guest/xg_cpuid_x86.c
> @@ -584,7 +584,7 @@ int xc_cpuid_apply_policy(xc_interface *xch, uint32_t domid, bool restore,
>      bool hvm;
>      xc_domaininfo_t di;
>      struct xc_cpu_policy *p = xc_cpu_policy_init();
> -    unsigned int i, nr_leaves = ARRAY_SIZE(p->leaves), nr_msrs = 0;
> +    unsigned int nr_leaves = ARRAY_SIZE(p->leaves), nr_msrs = 0;
>      uint32_t err_leaf = -1, err_subleaf = -1, err_msr = -1;
>      uint32_t host_featureset[FEATURESET_NR_ENTRIES] = {};
>      uint32_t len = ARRAY_SIZE(host_featureset);
> @@ -727,60 +727,8 @@ int xc_cpuid_apply_policy(xc_interface *xch, uint32_t domid, bool restore,
>      }
>      else
>      {
> -        /*
> -         * Topology for HVM guests is entirely controlled by Xen.  For now, we
> -         * hardcode APIC_ID = vcpu_id * 2 to give the illusion of no SMT.
> -         */
> -        p->policy.basic.htt = true;
> -        p->policy.extd.cmp_legacy = false;
> -
> -        /*
> -         * Leaf 1 EBX[23:16] is Maximum Logical Processors Per Package.
> -         * Update to reflect vLAPIC_ID = vCPU_ID * 2, but make sure to avoid
> -         * overflow.
> -         */
> -        if ( !p->policy.basic.lppp )
> -            p->policy.basic.lppp = 2;
> -        else if ( !(p->policy.basic.lppp & 0x80) )
> -            p->policy.basic.lppp *= 2;
> -
> -        switch ( p->policy.x86_vendor )
> -        {
> -        case X86_VENDOR_INTEL:
> -            for ( i = 0; (p->policy.cache.subleaf[i].type &&
> -                          i < ARRAY_SIZE(p->policy.cache.raw)); ++i )
> -            {
> -                p->policy.cache.subleaf[i].cores_per_package =
> -                    (p->policy.cache.subleaf[i].cores_per_package << 1) | 1;
> -                p->policy.cache.subleaf[i].threads_per_cache = 0;
> -            }
> -            break;
> -
> -        case X86_VENDOR_AMD:
> -        case X86_VENDOR_HYGON:
> -            /*
> -             * Leaf 0x80000008 ECX[15:12] is ApicIdCoreSize.
> -             * Leaf 0x80000008 ECX[7:0] is NumberOfCores (minus one).
> -             * Update to reflect vLAPIC_ID = vCPU_ID * 2.  But avoid
> -             * - overflow,
> -             * - going out of sync with leaf 1 EBX[23:16],
> -             * - incrementing ApicIdCoreSize when it's zero (which changes the
> -             *   meaning of bits 7:0).
> -             *
> -             * UPDATE: I addition to avoiding overflow, some
> -             * proprietary operating systems have trouble with
> -             * apic_id_size values greater than 7.  Limit the value to
> -             * 7 for now.
> -             */
> -            if ( p->policy.extd.nc < 0x7f )
> -            {
> -                if ( p->policy.extd.apic_id_size != 0 && p->policy.extd.apic_id_size < 0x7 )
> -                    p->policy.extd.apic_id_size++;
> -
> -                p->policy.extd.nc = (p->policy.extd.nc << 1) | 1;
> -            }
> -            break;
> -        }
> +        /* TODO: Expose the ability to choose a custom topology for HVM/PVH */
> +        xc_topo_from_parts(&p->policy, 1, di.max_vcpu_id + 1);

It would be better if this was split into two commits.  First commit
would move the code as-is into xc_topo_from_parts() without any
changes.  Second patch would do the functional changes.  That was it's
far easier to spot what are the relevant changes vs pure code
movement.

>      }
>  
>      nr_leaves = ARRAY_SIZE(p->leaves);
> @@ -1028,3 +976,89 @@ bool xc_cpu_policy_is_compatible(xc_interface *xch, xc_cpu_policy_t *host,
>  
>      return false;
>  }
> +
> +static uint32_t order(uint32_t n)
> +{
> +    return 32 - __builtin_clz(n);
> +}
> +
> +void xc_topo_from_parts(struct cpu_policy *p,
> +                        uint32_t threads_per_core, uint32_t cores_per_pkg)
> +{
> +    uint32_t threads_per_pkg = threads_per_core * cores_per_pkg;
> +    uint32_t apic_id_size;
> +
> +    if ( p->basic.max_leaf < 0xb )
> +        p->basic.max_leaf = 0xb;
> +
> +    memset(p->topo.raw, 0, sizeof(p->topo.raw));
> +
> +    /* thread level */
> +    p->topo.subleaf[0].nr_logical = threads_per_core;
> +    p->topo.subleaf[0].id_shift = 0;
> +    p->topo.subleaf[0].level = 0;
> +    p->topo.subleaf[0].type = 1;
> +    if ( threads_per_core > 1 )
> +        p->topo.subleaf[0].id_shift = order(threads_per_core - 1);
> +
> +    /* core level */
> +    p->topo.subleaf[1].nr_logical = cores_per_pkg;
> +    if ( p->x86_vendor == X86_VENDOR_INTEL )
> +        p->topo.subleaf[1].nr_logical = threads_per_pkg;
> +    p->topo.subleaf[1].id_shift = p->topo.subleaf[0].id_shift;
> +    p->topo.subleaf[1].level = 1;
> +    p->topo.subleaf[1].type = 2;
> +    if ( cores_per_pkg > 1 )
> +        p->topo.subleaf[1].id_shift += order(cores_per_pkg - 1);

I was kind of expecting this to be part of cpu-policy rather than xc,
as we could then also test this like you do test
x86_x2apic_id_from_vcpu_id().

It could also be used to populate the topologies in the tests
themselves.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 10:41:59 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 10:41:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695849.1086048 (Exim 4.92)
	(envelope-from )
	id 1rmtOJ-0003xU-UJ; Wed, 20 Mar 2024 10:41:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695849.1086048; Wed, 20 Mar 2024 10:41:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmtOJ-0003xN-RY; Wed, 20 Mar 2024 10:41:51 +0000
Received: by outflank-mailman (input) for mailman id 695849;
 Wed, 20 Mar 2024 10:41:50 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmtOI-0003xG-7B
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 10:41:50 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on20600.outbound.protection.outlook.com
 [2a01:111:f403:2414::600])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 72de5813-e6a6-11ee-a1ee-f123f15fe8a2;
 Wed, 20 Mar 2024 11:41:47 +0100 (CET)
Received: from MN2PR18CA0005.namprd18.prod.outlook.com (2603:10b6:208:23c::10)
 by CY8PR12MB7635.namprd12.prod.outlook.com (2603:10b6:930:9e::6) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.31; Wed, 20 Mar
 2024 10:41:44 +0000
Received: from BN3PEPF0000B078.namprd04.prod.outlook.com
 (2603:10b6:208:23c:cafe::e) by MN2PR18CA0005.outlook.office365.com
 (2603:10b6:208:23c::10) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.28 via Frontend
 Transport; Wed, 20 Mar 2024 10:41:44 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 BN3PEPF0000B078.mail.protection.outlook.com (10.167.243.123) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Wed, 20 Mar 2024 10:41:43 +0000
Received: from SATLEXMB08.amd.com (10.181.40.132) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Wed, 20 Mar
 2024 05:41:43 -0500
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB08.amd.com
 (10.181.40.132) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Wed, 20 Mar
 2024 03:41:43 -0700
Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Wed, 20 Mar 2024 05:41:42 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 72de5813-e6a6-11ee-a1ee-f123f15fe8a2
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=lXSmWGDpHWVU4QTneCknMpgRneWlzchX+EXwawKACnDViuF/0GfLeI9cusFkr3MmPABT+2XxYDJaICk51SZFR0GjFMq1cbSn1kqaP57XsneH2+Hrl5jeZX5/j6MOVPgeensebTUa2ctbUeDLAjZFpBm2QPYOz+9mjsi5BinI7BEKxJRn2GnXIrqyD6uNhU4Bnjb+k8sFnXAwden3DjcdCN1k+AGwH8VvmDt0PUbeItroQ+7Zw8RVcuXPvWmpFYSW/oyhkdXJmlizetubLHmaZHomPuYz4TEXxw2kZkAG28jEdtr0BaNVJxSFqtcd29yE1fciq9ziytrf/+BQsJH9BQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Ahkl+so/vWN4QFLNrbnQu94+YQ9o6SWrby7EpEPkVQA=;
 b=EuQi8uWEmdXww4xwwNbBdOftpAAhkEo8wrJw91DPXCbxqvt8GXn7N/PXyI9IHzLc5/Nu5s/l01nSsSCKgm8dpXRamEd8l0fnNH+knhZ9QF6p3Ozfmc2ZL1bg2m6Pk1//wq3VmQAM78btVMfYs4+W6rBBeYKzMztA3EcFVmIZDpinCiSOXi3AyLyc73Y04qF5SurudUZ0NvgukPbuXkUsusfz9XNw55bw6otNFnLh8ukQwVObFF7Ypbo+ZLnVNBFtV2yxhuYpebMQG/t3vw8OLUzjldL6MDeRZsNRNxozMlJ5BiwJAJ14Z6On2RfsoF+5V1dUZtdVDTovAhE9sDGb3w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=arm.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=Ahkl+so/vWN4QFLNrbnQu94+YQ9o6SWrby7EpEPkVQA=;
 b=zBnLxSAEe89KikQ+/pi6E5auYwi85DSCcAp6Z+QKJrni2JrlTvGn5YdSLznsTdrknR9cQFogEuxBRlOFlYVFirmXmqWTIwC70erjA249f9XCtLZFoK23fRn188qiUxX1vXmI+K3CXjY31fyJbpTLfgPyn3viAxno0xsJuPvHiMs=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
Message-ID: <0254141f-7751-41e0-a460-343cc500bc47@amd.com>
Date: Wed, 20 Mar 2024 11:41:36 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 05/11] xen/arm: Introduce helper for static memory pages
Content-Language: en-US
To: Luca Fancellu , 
CC: Stefano Stabellini , Julien Grall
	, Bertrand Marquis , "Volodymyr
 Babchuk" 
References: <20240312130331.78418-1-luca.fancellu@arm.com>
 <20240312130331.78418-6-luca.fancellu@arm.com>
From: Michal Orzel 
In-Reply-To: <20240312130331.78418-6-luca.fancellu@arm.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN3PEPF0000B078:EE_|CY8PR12MB7635:EE_
X-MS-Office365-Filtering-Correlation-Id: 2b7993ac-7c4d-4083-8506-08dc48ca55d0
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	QBXRbuluRXh7Y/K+mvC2kdgWPQiv00TozZYqGbxi9TRSPceJiVfKSh1yBKDKv6IfBoU6/7jo1pENXC/LNALRo4g8ZQXR98+4XV74XZgyZ+F+aymJUz46VosxgFQ8AhYhHIe0NrpfHBdYnq3dCTplII9IfhfCcrq4xKUOLFpXCCVlz9QeSs8pTHYujR7qIc1VufntQ1eXT2sFXKpYZRTTY0zO4jbPNXaVXXhMk0+avzcdaIqQAxWwed8TI48J34HKkUAdAzxYw34EmvZ2LpzONbuviQ4UTVcdGzt3gKgAPt59YzsOQbVi7Q5W8ED+Lj8PSDSj2/4vC+Dxx7ImVZMWgW/W7akZLAFW21bnJuZOq9GiOL40CQv/P62u757g87pJACleF0an3qyBZOn+z5XdQ9svkDVui1M17II93oahEPAGfhDrrzqnNuuwKIOlYRCJ/aZZQIWvPynPhSPgT0bJMzL++lKB0JpHUCbmCO568QrhIx4+pmcewVYX7jpyFZJ9yQ/fHb3hhRxb9khBBqrcl18D+5vsrMTh1hx3fXrrqqZaNxTGs8nWUmU/drd5PCKu5PKeS52tMDWHJVV9ri5xdrMnToo7hwvL8XVQbK8mFyGv+rpG+oQ+Gy44WUY3ze95RvibKWKKNQb+9soSps+vj2F+KjbEPLszDNWCs7QIHbPQ34q869W790AOnRbLWrxZcFiekbdQ0Au+tWgq9bgTQzISa4zAI0AgvVsYxPp3pjoh8rycwqAxpskjtu2/S4xv
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(1800799015)(376005)(82310400014)(36860700004);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Mar 2024 10:41:43.9777
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 2b7993ac-7c4d-4083-8506-08dc48ca55d0
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN3PEPF0000B078.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB7635

Hi Luca,

On 12/03/2024 14:03, Luca Fancellu wrote:
> 
> 
> Introduce a new helper function in the static-memory module
> that can be called to manage static memory banks, this is
> done to reuse the code when other modules would like to
> manage static memory banks that are not part of the
> reserved_mem structure.
The placement of this patch in a series is a bit strange given no use of init_staticmem_bank()
in the subsequent patch. I would move it right before patch #8.

Also, you could mention that this is because the information about shared memory regions
will no longer be stored in reserved_mem.

> 
> Signed-off-by: Luca Fancellu 
> ---
>  xen/arch/arm/include/asm/static-memory.h | 12 ++++++++++++
>  xen/arch/arm/static-memory.c             | 12 +-----------
>  2 files changed, 13 insertions(+), 11 deletions(-)
> 
> diff --git a/xen/arch/arm/include/asm/static-memory.h b/xen/arch/arm/include/asm/static-memory.h
> index 3e3efd70c38d..665d4df50eda 100644
> --- a/xen/arch/arm/include/asm/static-memory.h
> +++ b/xen/arch/arm/include/asm/static-memory.h
> @@ -7,6 +7,18 @@
> 
>  #ifdef CONFIG_STATIC_MEMORY
> 
> +static inline void init_staticmem_bank(const struct membank *bank)
> +{
> +    mfn_t bank_start = _mfn(PFN_UP(bank->start));
The header should be self-contained so you should add  that is not included in asm/kernel.h path.

Other than that:
Reviewed-by: Michal Orzel 

~Michal


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 10:46:56 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 10:46:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695853.1086059 (Exim 4.92)
	(envelope-from )
	id 1rmtTB-0004bv-LE; Wed, 20 Mar 2024 10:46:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695853.1086059; Wed, 20 Mar 2024 10:46:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmtTB-0004bo-Gx; Wed, 20 Mar 2024 10:46:53 +0000
Received: by outflank-mailman (input) for mailman id 695853;
 Wed, 20 Mar 2024 10:46:52 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmtTA-0004bi-3c
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 10:46:52 +0000
Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com
 [2a00:1450:4864:20::12f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 27ee46fd-e6a7-11ee-a1ee-f123f15fe8a2;
 Wed, 20 Mar 2024 11:46:50 +0100 (CET)
Received: by mail-lf1-x12f.google.com with SMTP id
 2adb3069b0e04-513e14b2bd9so5009551e87.2
 for ; Wed, 20 Mar 2024 03:46:50 -0700 (PDT)
Received: from localhost ([85.31.135.62]) by smtp.gmail.com with ESMTPSA id
 f14-20020a05600c4e8e00b0041413aefeb9sm1818726wmq.48.2024.03.20.03.46.49
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 20 Mar 2024 03:46:49 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 27ee46fd-e6a7-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710931609; x=1711536409; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=ceKuNjrEoY/wR6eGMrhm+IiYJyeYJXgPktVg6elNVZA=;
        b=jUZVrmdQVyCdpWibnno81/EXy8+/Qaq69KagzC7GlqP/N+rxGhoYV9gcAU4864jJBc
         iA222EmMeLCaJnkE/G6zqDddwOKtJhi/y4ez7iB1iVwvOXJ0wQg9dWmeeHdWCmXiZatu
         TfjeIgakO1+eM/69LPbmwDGRz+WpOQhgDenMw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710931609; x=1711536409;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=ceKuNjrEoY/wR6eGMrhm+IiYJyeYJXgPktVg6elNVZA=;
        b=Q+Dj5RCPP+u0BWQ+AQld+Nk044584pwGqlvhd1gS7qJlwDOXK+Gj8dYuqX0AMBXEhU
         OprQ8f1++v2i90SpUimB+y8qXXpUDYIcDuX4MJms86IitsotVq409dDlmPG3VKnvsg/I
         VoGOXwFAkzUtFgqf3oID9hIj5/hSBW9keMX9K0zpqAgq+NErmbKPVoIhRZx7YZiGlFQS
         K+mHpjo3GHhieFETePBnvEcdRMTHxcTLanzecm6qQZPmlxz5/J+M+Y2zSlIJmz/lK6qE
         mNtoUlfcAFoCR8OwPc94OEsLNrCxbolLktHjz7wLPYV2DMETbt5YOBeQiP4XA3vvO9mk
         EGuA==
X-Gm-Message-State: AOJu0Yx5/b1v8W8tgyb7d+SRW2lOGb/72LQxp3mwKwILEmkfqRxt6a9X
	hp+kvPro1o+R0fHd3ejvz0GynnPd+Riavj+mTF0eCVfySy26UH8YLtlGjUB6EOg=
X-Google-Smtp-Source: AGHT+IFTCgGouzsvJXo9SprsGY4wNcT3j41ZAKhQriZRu1QC4exLROJRspoO349YgY15R/56pXiDsw==
X-Received: by 2002:a19:ae17:0:b0:513:21a9:79a8 with SMTP id f23-20020a19ae17000000b0051321a979a8mr13050723lfc.62.1710931609413;
        Wed, 20 Mar 2024 03:46:49 -0700 (PDT)
Date: Wed, 20 Mar 2024 11:46:48 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: "xen-devel@lists.xenproject.org" ,
	Andrew Cooper ,
	Nicola Vetrini 
Subject: Re: [PATCH] AMD/IOMMU: drop remaining guest-IOMMU bits too
Message-ID: 
References: <5eb98372-2992-4a93-846c-4e325c41af98@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <5eb98372-2992-4a93-846c-4e325c41af98@suse.com>

On Tue, Mar 19, 2024 at 02:28:12PM +0100, Jan Beulich wrote:
> With a02174c6c885 ("amd/iommu: clean up unused guest iommu related
> functions") having removed the sole place where d->g_iommu would be set
> to non-NULL, guest_iommu_add_ppr_log() will unconditionally bail the
> latest from its 2nd if(). With it dropped, all other stuff in the file
> is unused, too. Delete iommu_guest.c altogether.
> 
> Further delete struct guest{_buffer,_dev_table,_iommu{,_msi}} as well as
> struct mmio_reg for being unused with the unused g_iommu also dropped
> from struct arch_iommu.
> 
> Signed-off-by: Jan Beulich 
> ---
> I wasn't sure how far to further go with removing the body of
> parse_ppr_log_entry(), or perhaps even the entire function, and then
> further up to all PPR logging code. Hence why for now I've merely
> commented out the function call into the file being deleted (which of
> course Misra isn't going to like). Thoughts / suggestions?
> 
> I further wonder whether set_iommu_guest_translation_control() should
> have been invoked independent of guest-IOMMU actually being enabled. IOW
> that may want purging, too. Along these lines iommuv2_enabled may also
> want dropping, for not having any consumer left. Much like has_viommu()
> and then also {XEN_,}X86_EMU_IOMMU, i.e. going as far as affecting the
> public interface.
> 
> --- a/xen/arch/x86/include/asm/iommu.h
> +++ b/xen/arch/x86/include/asm/iommu.h
> @@ -52,7 +52,6 @@ struct arch_iommu
>          struct {
>              unsigned int paging_mode;
>              struct page_info *root_table;
> -            struct guest_iommu *g_iommu;
>          } amd;
>      };
>  };
> --- a/xen/drivers/passthrough/amd/Makefile
> +++ b/xen/drivers/passthrough/amd/Makefile
> @@ -5,4 +5,3 @@ obj-y += pci_amd_iommu.o
>  obj-bin-y += iommu_acpi.init.o
>  obj-y += iommu_intr.o
>  obj-y += iommu_cmd.o
> -obj-$(CONFIG_HVM) += iommu_guest.o
> --- a/xen/drivers/passthrough/amd/iommu.h
> +++ b/xen/drivers/passthrough/amd/iommu.h
> @@ -145,57 +145,6 @@ int iterate_ivrs_entries(int (*handler)(
>                                          struct ivrs_mappings *map,
>                                          uint16_t bdf));
>  
> -/* iommu tables in guest space */
> -struct mmio_reg {
> -    uint32_t    lo;
> -    uint32_t    hi;
> -};
> -
> -struct guest_dev_table {
> -    struct mmio_reg         reg_base;
> -    uint32_t                size;
> -};
> -
> -struct guest_buffer {
> -    struct mmio_reg         reg_base;
> -    struct mmio_reg         reg_tail;
> -    struct mmio_reg         reg_head;
> -    uint32_t                size;
> -};
> -
> -struct guest_iommu_msi {
> -    uint8_t                 vector;
> -    uint8_t                 dest;
> -    uint8_t                 dest_mode;
> -    uint8_t                 delivery_mode;
> -    uint8_t                 trig_mode;
> -};
> -
> -/* virtual IOMMU structure */
> -struct guest_iommu {
> -
> -    struct domain          *domain;
> -    spinlock_t              lock;
> -    bool                    enabled;
> -
> -    struct guest_dev_table  dev_table;
> -    struct guest_buffer     cmd_buffer;
> -    struct guest_buffer     event_log;
> -    struct guest_buffer     ppr_log;
> -
> -    struct tasklet          cmd_buffer_tasklet;
> -
> -    uint64_t                mmio_base;             /* MMIO base address */
> -
> -    /* MMIO regs */
> -    union amd_iommu_control reg_ctrl;              /* MMIO offset 0018h */
> -    struct mmio_reg         reg_status;            /* MMIO offset 2020h */
> -    union amd_iommu_ext_features reg_ext_feature;  /* MMIO offset 0030h */
> -
> -    /* guest interrupt settings */
> -    struct guest_iommu_msi  msi;
> -};
> -
>  extern bool iommuv2_enabled;

I think iommuv2_enabled can also go away, since it's only used by
guest_iommu_init()?

It's set in amd_iommu_prepare() and amd_iommu_init_cleanup() but only
consumed by guest_iommu_init().

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 10:58:00 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 10:58:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695858.1086075 (Exim 4.92)
	(envelope-from )
	id 1rmtdn-0006l7-LG; Wed, 20 Mar 2024 10:57:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695858.1086075; Wed, 20 Mar 2024 10:57:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmtdn-0006l0-I2; Wed, 20 Mar 2024 10:57:51 +0000
Received: by outflank-mailman (input) for mailman id 695858;
 Wed, 20 Mar 2024 10:57:50 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmtdm-0006ku-Pl
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 10:57:50 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on20631.outbound.protection.outlook.com
 [2a01:111:f400:7e88::631])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b00912e2-e6a8-11ee-a1ee-f123f15fe8a2;
 Wed, 20 Mar 2024 11:57:48 +0100 (CET)
Received: from BN9PR03CA0782.namprd03.prod.outlook.com (2603:10b6:408:13f::7)
 by DS7PR12MB6070.namprd12.prod.outlook.com (2603:10b6:8:9e::14) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.31; Wed, 20 Mar
 2024 10:57:45 +0000
Received: from BN2PEPF0000449D.namprd02.prod.outlook.com
 (2603:10b6:408:13f:cafe::30) by BN9PR03CA0782.outlook.office365.com
 (2603:10b6:408:13f::7) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.27 via Frontend
 Transport; Wed, 20 Mar 2024 10:57:45 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 BN2PEPF0000449D.mail.protection.outlook.com (10.167.243.148) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Wed, 20 Mar 2024 10:57:45 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Wed, 20 Mar
 2024 05:57:45 -0500
Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Wed, 20 Mar 2024 05:57:43 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b00912e2-e6a8-11ee-a1ee-f123f15fe8a2
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=LLm4BWRzboT0NS9wOsa8S2IepABmjDRzOHQOQNloiKzU+YT7eOmqW3eSPcbuSOE6vUeXkjdH2WeZU7MGop9ujpChmHM/IEm92Vkl1gyWOWTEVZQyrt4CmTfk2zsHbzGIlMGHywP6dCTksqkP77Rs1p5XEVgdtxMZVz8Kf7a/Zu2ZM0cF0vGn+FFy0pG4QSIW2CB9bGpbT/Uy8aSnmN4Vcccj35xGvl+ULtfolVK2LIm02GOtWvTbLyg5H3K0wxsSjCDNt2A5IIoYduDZkOtX+Jufu36+9fdztDvjhhLcNa1TcBvQYpDHSu9yOfbgPssbDBpf3TkUG5P2L4hSKAjDYg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=kvdgdCX0JO2OJJqgjVsQE9DtjhL4RhkkK4YxD6xn6yE=;
 b=Dxp+XqcXyyQxrEx/z4dhb4oYxxZ34aL/PLFYp/E9X76jjyIk4LCWk5bztudsmXfJzWCSUy6iD0KxH7uCs5XlKqZuRLFPAqA7h01w1PAyj9V3KWHrEoU9PCMTDwJMZoB3sACWLVob33docdN0DVFhFxEztwSClA0bZj9CMikL4DXzoZzpfSAgk1zHyROM4MsxDqiN/2B4VCiJOlBXkLboLyb12Ul3V6Zg4uAuyxgH3XvdO2MotIGsW590mzLHacT+/zQL+tYd/8pLsPIuIjyl91+RFLGgjkQmRlKp7ymcLPCWmIErAV6flo4uiScNbAFo6Ap1z+IWOBrWi72DeYIhFA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=arm.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=kvdgdCX0JO2OJJqgjVsQE9DtjhL4RhkkK4YxD6xn6yE=;
 b=vct5GbqbyWl53rOKrfM6g5RQIY0hGk/AmTuaTT9VpijIJEmqWhSZ17cXtY6oOrv4DzxZXFXAZX4BPhfdxdkWFKdcN+dVbORh3fOO0iJ48ktga8HGDOYnv1lgPnNvvN8KLuy/na6MU5kZLnnUKdzgo1uzORomIcONifw617gZkUA=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
Message-ID: <3bd5d32c-d2e6-4e53-8b3e-aa7fdd058c71@amd.com>
Date: Wed, 20 Mar 2024 11:57:43 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 06/11] xen/arm: Avoid code duplication in
 find_unallocated_memory
Content-Language: en-US
To: Luca Fancellu , 
CC: Stefano Stabellini , Julien Grall
	, Bertrand Marquis , Volodymyr
 Babchuk 
References: <20240312130331.78418-1-luca.fancellu@arm.com>
 <20240312130331.78418-7-luca.fancellu@arm.com>
From: Michal Orzel 
In-Reply-To: <20240312130331.78418-7-luca.fancellu@arm.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB03.amd.com: michal.orzel@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN2PEPF0000449D:EE_|DS7PR12MB6070:EE_
X-MS-Office365-Filtering-Correlation-Id: c2ce9c74-945c-4467-0633-08dc48cc92e1
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	5E47cLq4cwmtJqcb/lsbqUNIqPLdgx78ONC0XyfquaQXptoN3K+b4uuULzVkI+TLJRd5iZqxsWXkAOQfAlU7Wkp9HKEBOB7WX/EnDOzg5HiOY6sUv+6mCtJXvdAlnWbOcWM3gn0B4ML6Db5qPj+YNXzBv92uZvmzE8Q2n1JWOdsRtmWkixafHPEeVDaA9DfCkwTxLfxKkDi4E9QZ/t/SDoarUdOrl61eKM7Vz/icG246U6k24/Jk8xoOS44z6EdgmL/uiQuw6zT5IfB7hUS/3yDRhmOQQ6LEV9RZStEYoeG3iU5KpE86jSOo1cUMJXs7L+8PPt9hXfgx60XOpKBVfMLMP8/juirbxdfxoPfY3EaIZyNE7luI+AAnZL/qjIRhaFNDZqmiFCGXtBpXdlnUicOj7eEfCyCuhBGHe004O2v/kKiCvuKf+XUzSYPFCt+NKg+IcNPBBPqOePADgy/qBu99LJ1g4DdgjnljAolWki5VJOXPTd4PQtmDuOENCZcAH3RHicqM2cWnBLpuzHuJQZaJ3a9GJATj968DgI1o44YIE72cguOrooOl1jPQLxlzETKFq7yYv7WYurJEKMfSM9tlRzrDQao9hDi8IAcKJurHoPWaVctiK13RGhZds9l5QrMlRFZheQYY2W1cs38f1bRX+aJTPOqqkvWEzDZ8Z71bRa2bv52QhV+zDJkLNspLxzdDPMh2T9C3KKTmAoZ5602HyT7STpbZmwnpTBukW8ybe3Gg/x6tDp4jKBP8PnXs
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(376005)(82310400014)(36860700004)(1800799015);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Mar 2024 10:57:45.4048
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c2ce9c74-945c-4467-0633-08dc48cc92e1
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN2PEPF0000449D.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR12MB6070

Hi Luca,

On 12/03/2024 14:03, Luca Fancellu wrote:
> 
> 
> The function find_unallocated_memory is using the same code to
> loop through 3 structure of the same type, in order to avoid
> code duplication, rework the code to have only one loop that
> goes through all the structures.
> 
> Signed-off-by: Luca Fancellu 
> ---
>  xen/arch/arm/domain_build.c | 62 ++++++++++---------------------------
>  1 file changed, 17 insertions(+), 45 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index b254f252e7cb..d0f2ac6060eb 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -869,12 +869,14 @@ static int __init add_ext_regions(unsigned long s_gfn, unsigned long e_gfn,
>  static int __init find_unallocated_memory(const struct kernel_info *kinfo,
>                                            struct membanks *ext_regions)
>  {
> -    const struct membanks *kinfo_mem = kernel_info_get_mem(kinfo);
> -    const struct membanks *mem = bootinfo_get_mem();
> -    const struct membanks *reserved_mem = bootinfo_get_reserved_mem();
> +    const struct membanks *mem_banks[] = {
> +        bootinfo_get_mem(),
> +        kernel_info_get_mem(kinfo),
> +        bootinfo_get_reserved_mem(),
> +    };
>      struct rangeset *unalloc_mem;
>      paddr_t start, end;
> -    unsigned int i;
> +    unsigned int i, j;
>      int res;
> 
>      dt_dprintk("Find unallocated memory for extended regions\n");
> @@ -883,50 +885,20 @@ static int __init find_unallocated_memory(const struct kernel_info *kinfo,
>      if ( !unalloc_mem )
>          return -ENOMEM;
> 
> -    /* Start with all available RAM */
> -    for ( i = 0; i < mem->nr_banks; i++ )
> -    {
> -        start = mem->bank[i].start;
> -        end = mem->bank[i].start + mem->bank[i].size;
> -        res = rangeset_add_range(unalloc_mem, PFN_DOWN(start),
> -                                 PFN_DOWN(end - 1));
> -        if ( res )
> -        {
> -            printk(XENLOG_ERR "Failed to add: %#"PRIpaddr"->%#"PRIpaddr"\n",
> -                   start, end);
> -            goto out;
> -        }
> -    }
> -
> -    /* Remove RAM assigned to Dom0 */
> -    for ( i = 0; i < kinfo_mem->nr_banks; i++ )
> -    {
> -        start = kinfo_mem->bank[i].start;
> -        end = kinfo_mem->bank[i].start + kinfo_mem->bank[i].size;
> -        res = rangeset_remove_range(unalloc_mem, PFN_DOWN(start),
> -                                    PFN_DOWN(end - 1));
> -        if ( res )
> +    for ( i = 0; i < ARRAY_SIZE(mem_banks); i++ )
> +        for ( j = 0; j < mem_banks[i]->nr_banks; j++ )
It might be a matter of personal opinion, but I would actually prefer the current code
that looks simpler/neater (the steps are clear) to me. I'd like to know other maintainers opinion.

~Michal


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 10:58:55 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 10:58:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695860.1086084 (Exim 4.92)
	(envelope-from )
	id 1rmteo-0007Ki-UO; Wed, 20 Mar 2024 10:58:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695860.1086084; Wed, 20 Mar 2024 10:58:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmteo-0007Kb-Rg; Wed, 20 Mar 2024 10:58:54 +0000
Received: by outflank-mailman (input) for mailman id 695860;
 Wed, 20 Mar 2024 10:58:53 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmten-0007KV-CN
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 10:58:53 +0000
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com
 [2a00:1450:4864:20::531])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d63167e1-e6a8-11ee-afdd-a90da7624cb6;
 Wed, 20 Mar 2024 11:58:51 +0100 (CET)
Received: by mail-ed1-x531.google.com with SMTP id
 4fb4d7f45d1cf-568d323e7fbso4513601a12.3
 for ; Wed, 20 Mar 2024 03:58:51 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 cr8-20020a056402222800b005695f3e396csm3387135edb.15.2024.03.20.03.58.50
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 20 Mar 2024 03:58:51 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d63167e1-e6a8-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710932331; x=1711537131; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=jmKgPtcC2iyLajPa9nCvIekWN+qzRfCSlozxXb75ryI=;
        b=DsAyYzkrMm6RMWzurS9oQ6lKShr7G0WKcLPYCE3Hh/8GB1emuezxkdNvVnlqmoBDiR
         Ra8Gu879mB8qcAmrkj91/CIYdDQvoDwYMJxChOSjJrLJEMUgbkHljSYSXQndKGqYtd1R
         vDC43iGAOT+zNaW6YkKeK3TjYPC2UQ1dbQVys3/8Z091IWFbTYwaetgbfsMXKNXtsMkd
         QGkaYpk+RNUqNNjIy3caJJd3/mxOcMWjaWELu9GeEgU3DeusfDdPj1XkDueMYdWfqSu1
         YESIflMU4ZpyEEdNsvxKQuAZF2ixan2K9CDASFCiaj07bAd390Wnwx3H1xOWSUkTWsUV
         dHLQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710932331; x=1711537131;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=jmKgPtcC2iyLajPa9nCvIekWN+qzRfCSlozxXb75ryI=;
        b=vEw4/03IVbOQnZqAdigyhXW4CSSF/JY4azVP78dE2LH0rkeCZ1xWGDdzDyIKGsLPcE
         YHoDvd/RkHR70ZGDe+9ECmNnLFq0NEEynRqV9x6U9jYDctFjYxUIAPkshCJv+5lbwAoA
         NJDrpCJJyURxV5CcnriLUwKMy3GMVmhtLtyoaWIYb4vuQrd/yJcW4Xioo3AS+7ZUXLdo
         pk5r1L55rhAhR7SReOOGQ3uVc67YrIoteOl+q743LFBPEo0ghQMBmZ160KuM5+tW+S+w
         oUJ+ZtAail6hLhYic5OY4Nb2OaxmncghorPp9Pe5OmgdRy8xjNq4nd/2uOZkZDRcgzMx
         OFUA==
X-Gm-Message-State: AOJu0YwmSFqJJyO7axvZM+ErVVDlJRHp2uSGAWxvPyMgEtNPF5FT1WrJ
	0oo+KFOTYa1JzW/lrLIbIZ8JZa/03+Uwx12Vn5M9gAM2Gms75DlY6XO1a2lcBQ==
X-Google-Smtp-Source: AGHT+IGBLTWWdMXlX5bzZsnuwXD1dW2QVkKqoXTdzPVo5+wyJRkrcJgKM8DG2iQSFBOFgCNK3AV2mw==
X-Received: by 2002:a05:6402:3607:b0:56b:a7e3:7426 with SMTP id el7-20020a056402360700b0056ba7e37426mr1708961edb.34.1710932331314;
        Wed, 20 Mar 2024 03:58:51 -0700 (PDT)
Message-ID: 
Date: Wed, 20 Mar 2024 11:58:50 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] AMD/IOMMU: drop remaining guest-IOMMU bits too
Content-Language: en-US
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: "xen-devel@lists.xenproject.org" ,
 Andrew Cooper ,
 Nicola Vetrini 
References: <5eb98372-2992-4a93-846c-4e325c41af98@suse.com>
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 20.03.2024 11:46, Roger Pau Monné wrote:
> On Tue, Mar 19, 2024 at 02:28:12PM +0100, Jan Beulich wrote:
>> With a02174c6c885 ("amd/iommu: clean up unused guest iommu related
>> functions") having removed the sole place where d->g_iommu would be set
>> to non-NULL, guest_iommu_add_ppr_log() will unconditionally bail the
>> latest from its 2nd if(). With it dropped, all other stuff in the file
>> is unused, too. Delete iommu_guest.c altogether.
>>
>> Further delete struct guest{_buffer,_dev_table,_iommu{,_msi}} as well as
>> struct mmio_reg for being unused with the unused g_iommu also dropped
>> from struct arch_iommu.
>>
>> Signed-off-by: Jan Beulich 
>> ---
>> I wasn't sure how far to further go with removing the body of
>> parse_ppr_log_entry(), or perhaps even the entire function, and then
>> further up to all PPR logging code. Hence why for now I've merely
>> commented out the function call into the file being deleted (which of
>> course Misra isn't going to like). Thoughts / suggestions?
>>
>> I further wonder whether set_iommu_guest_translation_control() should
>> have been invoked independent of guest-IOMMU actually being enabled. IOW
>> that may want purging, too. Along these lines iommuv2_enabled may also
>> want dropping, for not having any consumer left. Much like has_viommu()
>> and then also {XEN_,}X86_EMU_IOMMU, i.e. going as far as affecting the
>> public interface.
>>
>> --- a/xen/arch/x86/include/asm/iommu.h
>> +++ b/xen/arch/x86/include/asm/iommu.h
>> @@ -52,7 +52,6 @@ struct arch_iommu
>>          struct {
>>              unsigned int paging_mode;
>>              struct page_info *root_table;
>> -            struct guest_iommu *g_iommu;
>>          } amd;
>>      };
>>  };
>> --- a/xen/drivers/passthrough/amd/Makefile
>> +++ b/xen/drivers/passthrough/amd/Makefile
>> @@ -5,4 +5,3 @@ obj-y += pci_amd_iommu.o
>>  obj-bin-y += iommu_acpi.init.o
>>  obj-y += iommu_intr.o
>>  obj-y += iommu_cmd.o
>> -obj-$(CONFIG_HVM) += iommu_guest.o
>> --- a/xen/drivers/passthrough/amd/iommu.h
>> +++ b/xen/drivers/passthrough/amd/iommu.h
>> @@ -145,57 +145,6 @@ int iterate_ivrs_entries(int (*handler)(
>>                                          struct ivrs_mappings *map,
>>                                          uint16_t bdf));
>>  
>> -/* iommu tables in guest space */
>> -struct mmio_reg {
>> -    uint32_t    lo;
>> -    uint32_t    hi;
>> -};
>> -
>> -struct guest_dev_table {
>> -    struct mmio_reg         reg_base;
>> -    uint32_t                size;
>> -};
>> -
>> -struct guest_buffer {
>> -    struct mmio_reg         reg_base;
>> -    struct mmio_reg         reg_tail;
>> -    struct mmio_reg         reg_head;
>> -    uint32_t                size;
>> -};
>> -
>> -struct guest_iommu_msi {
>> -    uint8_t                 vector;
>> -    uint8_t                 dest;
>> -    uint8_t                 dest_mode;
>> -    uint8_t                 delivery_mode;
>> -    uint8_t                 trig_mode;
>> -};
>> -
>> -/* virtual IOMMU structure */
>> -struct guest_iommu {
>> -
>> -    struct domain          *domain;
>> -    spinlock_t              lock;
>> -    bool                    enabled;
>> -
>> -    struct guest_dev_table  dev_table;
>> -    struct guest_buffer     cmd_buffer;
>> -    struct guest_buffer     event_log;
>> -    struct guest_buffer     ppr_log;
>> -
>> -    struct tasklet          cmd_buffer_tasklet;
>> -
>> -    uint64_t                mmio_base;             /* MMIO base address */
>> -
>> -    /* MMIO regs */
>> -    union amd_iommu_control reg_ctrl;              /* MMIO offset 0018h */
>> -    struct mmio_reg         reg_status;            /* MMIO offset 2020h */
>> -    union amd_iommu_ext_features reg_ext_feature;  /* MMIO offset 0030h */
>> -
>> -    /* guest interrupt settings */
>> -    struct guest_iommu_msi  msi;
>> -};
>> -
>>  extern bool iommuv2_enabled;
> 
> I think iommuv2_enabled can also go away, since it's only used by
> guest_iommu_init()?
> 
> It's set in amd_iommu_prepare() and amd_iommu_init_cleanup() but only
> consumed by guest_iommu_init().

See the post-commit-message remarks: The main question is where to stop.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 11:01:23 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 11:01:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695863.1086095 (Exim 4.92)
	(envelope-from )
	id 1rmthC-0000bV-A1; Wed, 20 Mar 2024 11:01:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695863.1086095; Wed, 20 Mar 2024 11:01:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmthC-0000bN-6q; Wed, 20 Mar 2024 11:01:22 +0000
Received: by outflank-mailman (input) for mailman id 695863;
 Wed, 20 Mar 2024 11:01:20 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmthA-0000Zu-RC
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 11:01:20 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2e47b789-e6a9-11ee-afdd-a90da7624cb6;
 Wed, 20 Mar 2024 12:01:19 +0100 (CET)
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 by support.bugseng.com (Postfix) with ESMTPA id 416B04EE073D;
 Wed, 20 Mar 2024 12:01:19 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2e47b789-e6a9-11ee-afdd-a90da7624cb6
MIME-Version: 1.0
Date: Wed, 20 Mar 2024 12:01:19 +0100
From: Nicola Vetrini 
To: Andrew Cooper 
Cc: Xen-devel , =?UTF-8?Q?Roger_Pau_Monn?=
 =?UTF-8?Q?=C3=A9?= , George Dunlap
 , Jan Beulich , Stefano
 Stabellini , Julien Grall , Dario
 Faggioli , "consulting @ bugseng . com"
 
Subject: Re: [PATCH 0/7] xen/trace: Treewide API cleanup
In-Reply-To: <20240318163552.3808695-1-andrew.cooper3@citrix.com>
References: <20240318163552.3808695-1-andrew.cooper3@citrix.com>
Message-ID: <9a88b98aeb598b0889ab6b88fc06bdfc@bugseng.com>
X-Sender: nicola.vetrini@bugseng.com
Organization: BUGSENG s.r.l.
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit

On 2024-03-18 17:35, Andrew Cooper wrote:
> Rework the trace API to unify it (remove the HVM specific obfuscation), 
> and
> remove MISRA violations.
> 
> v3:
>  * Delete TRACE_PARAM64()
> 
> Andrew Cooper (7):
>   xen/trace: Introduce new API
>   xen/credit2: Clean up trace handling
>   xen/rt: Clean up trace handling
>   xen/sched: Clean up trace handling
>   xen: Switch to new TRACE() API
>   xen/trace: Update final {__,}trace_var() users to the new API
>   xen/trace: Drop old trace API

Hi Andrew,

thanks for the series. I'll run it trough ECLAIR when I have some spare 
time, so that we can assess the impact especially on Rule 20.7.

-- 
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 11:04:35 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 11:04:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695866.1086105 (Exim 4.92)
	(envelope-from )
	id 1rmtkF-0001WZ-R2; Wed, 20 Mar 2024 11:04:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695866.1086105; Wed, 20 Mar 2024 11:04:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmtkF-0001WS-Nq; Wed, 20 Mar 2024 11:04:31 +0000
Received: by outflank-mailman (input) for mailman id 695866;
 Wed, 20 Mar 2024 11:04:30 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmtkE-0001WM-FH
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 11:04:30 +0000
Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com
 [2607:f8b0:4864:20::731])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9ef061ea-e6a9-11ee-afdd-a90da7624cb6;
 Wed, 20 Mar 2024 12:04:29 +0100 (CET)
Received: by mail-qk1-x731.google.com with SMTP id
 af79cd13be357-78a13117a3dso62792985a.1
 for ; Wed, 20 Mar 2024 04:04:29 -0700 (PDT)
Received: from localhost ([85.31.135.62]) by smtp.gmail.com with ESMTPSA id
 bl41-20020a05620a1aa900b0078a2832b33esm163914qkb.13.2024.03.20.04.04.27
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 20 Mar 2024 04:04:27 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9ef061ea-e6a9-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710932668; x=1711537468; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=MfEKnJvmsG0Z5JM4ZXCPg+drObOdX7VSv7S0dQe7cbo=;
        b=HoDgAWrP9X+QnlOCXS+EBHVdDMW2yWV5GexZC2D9DKGsyWAV9wolABVf5APYALQjul
         CWjim3DAeFkFSeBD4bSATvaBplKS4dINd0/KnfwEzZ26eWfxDCFCbKUuiiBRZQS+XBso
         tIbheIfjPcvz5EP725v8qY3wXusPLi+cWbgqw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710932668; x=1711537468;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=MfEKnJvmsG0Z5JM4ZXCPg+drObOdX7VSv7S0dQe7cbo=;
        b=C6wiUDxx0JKusuI1DdTiOav09XA/M1BjpCp6pSptfq06bsBNF69a2IaZvK0o9PS6zj
         GwOPT2qJlNQ4kreOEbvh4Yu51NtkCItwV1YrZDAXRu1ttg4YNAsgrDB1stqUYiShgXS5
         0Q0kHVxJ2LtepYdyB607VJVbBHNYDgRB/scLFw5To0W6fZ+XVfOql5uO/HDux36c+gj+
         rMLZCYXZQOrMZQssrKU8b3rE5AvfCQ+Zs5MVwrxHF+brdK/BqpRviCxSMB6ZC7UXLvsx
         hCmTqjAgWrtzBuvbg4FpKKOPTFaNekJ2AYXqcFk2vHFPetaI1qIXpKxTbf/PRAlE0PtW
         F7CQ==
X-Forwarded-Encrypted: i=1; AJvYcCWAmn02PwZ0dy5qfod+O9zFPrReP1l0QmQYH00LZUxFzx980f+sAW5vVPhphT2uwoKUhX28oaajjCVHpCj2tI6VTrvD5991aTxgcYj6uSc=
X-Gm-Message-State: AOJu0YwlBTwP7B/dB4zGDe6CtZxlseGuxmEg7J7oirX2zYaJS7thBh/F
	vAaJaYr2haqaRLH0x0qZ7XKgLsvAHClgtgA4Tsk1bdvWxB89ZxDszVHtPtfAlxY=
X-Google-Smtp-Source: AGHT+IFIlKIN9h7rco0tQXX02EmOOfcUIOmTWuCTm7kt53nSlam7im/4ulWw9UcIPaxQ4HW23RGT4w==
X-Received: by 2002:a05:620a:3711:b0:788:3fac:b27a with SMTP id de17-20020a05620a371100b007883facb27amr3663404qkb.39.1710932667958;
        Wed, 20 Mar 2024 04:04:27 -0700 (PDT)
Date: Wed, 20 Mar 2024 12:04:25 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Ross Lagerwall 
Cc: grub-devel@gnu.org, xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Daniel Kiper 
Subject: Re: [PATCH 1/7] multiboot2: Add load type header and support for the
 PE binary type
Message-ID: 
References: <20240313150748.791236-1-ross.lagerwall@citrix.com>
 <20240313150748.791236-2-ross.lagerwall@citrix.com>
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Tue, Mar 19, 2024 at 02:46:59PM +0000, Ross Lagerwall wrote:
> On Tue, Mar 19, 2024 at 1:18 PM Roger Pau Monné  wrote:
> >
> > On Wed, Mar 13, 2024 at 03:07:42PM +0000, Ross Lagerwall wrote:
> > > Currently, multiboot2-compatible bootloaders can load ELF binaries and
> > > a.out binaries. The presence of the address header tag determines
> > > how the bootloader tries to interpret the binary (a.out if the address
> > > tag is present else ELF).
> > >
> > > Add a new load type header tag that explicitly states the type of the
> > > binary. Bootloaders should use the binary type specified in the load
> > > type tag. If the load type tag is not present, the bootloader should
> > > fall back to the previous heuristics.
> > >
> > > In addition to the existing address and ELF load types, specify a new
> > > optional PE binary load type. This new type is a useful addition since
> > > PE binaries can be signed and verified (i.e. used with Secure Boot).
> > >
> > > Signed-off-by: Ross Lagerwall 
> > > ---
> > >  doc/multiboot.texi | 39 ++++++++++++++++++++++++++++++++++-----
> > >  doc/multiboot2.h   | 13 +++++++++++++
> > >  2 files changed, 47 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/doc/multiboot.texi b/doc/multiboot.texi
> > > index df8a0d056e76..d12719c744eb 100644
> > > --- a/doc/multiboot.texi
> > > +++ b/doc/multiboot.texi
> > > @@ -511,11 +511,12 @@ assumes that no bss segment is present.
> > >
> > >  Note: This information does not need to be provided if the kernel image
> > >  is in @sc{elf} format, but it must be provided if the image is in a.out
> > > -format or in some other format. When the address tag is present it must
> > > -be used in order to load the image, regardless of whether an @sc{elf}
> > > -header is also present. Compliant boot loaders must be able to load
> > > -images that are either in @sc{elf} format or contain the address tag
> > > -embedded in the Multiboot2 header.
> > > +format or in some other format. If the load type tag is not specified
> > > +and the address tag is present it must be used in order to load the
> > > +image, regardless of whether an @sc{elf} header is also present.
> > > +Compliant boot loaders must be able to load images that are either in
> > > +@sc{elf} format or contain the address tag embedded in the Multiboot2
> > > +header.
> > >
> > >  @subsection The entry address tag of Multiboot2 header
> > >
> > > @@ -732,6 +733,34 @@ and @samp{2} means load image at highest possible address but not
> > >  higher than max_addr.
> > >  @end table
> > >
> > > +@node Load type tag
> > > +@subsection Load type tag
> > > +
> > > +@example
> > > +@group
> > > +        +-------------------+
> > > +u16     | type = 11         |
> > > +u16     | flags             |
> > > +u32     | size = 12         |
> > > +u32     | load_type         |
> > > +        +-------------------+
> > > +@end group
> > > +@end example
> > > +
> > > +This tag indicates the type of the payload and how the boot loader
> > > +should load it.
> > > +
> > > +The meaning of each field is as follows:
> > > +
> > > +@table @code
> > > +@item load_type
> > > +Recognized load types are @samp{0} for address (i.e. load a.out using
> > > +the address tag), @samp{1} for ELF, and @samp{2} for PE. Compliant
> > > +bootloaders should implement support for a.out and ELF as a minimum.  If
> > > +this tag is not specified, the boot loader should attempt to load the
> > > +payload using the information specified in the address tag if present,
> > > +else it should load the payload as an ELF binary.  @end table
> >
> > I wonder if it would be simpler to use the following order instead:
> >
> > 1. Address tag
> > 2. Load type tag
> > 3. ELF header
> >
> > It's pointless to add a Loader type tag with load_type == 0, as that's
> > already mandated by the Address tag.  IOW: signaling the use of the
> > Address tag here is kind of pointless, if the fields in the Address
> > tag are set, that's the only signaling required for the data in the
> > Address tag to be used.
> >
> > Or are we attempting to support images that set Address tag and Load
> > type tag != 0 in order to use the Address tag when the loader doesn't
> > recognize the Load type tag, and otherwise use a different format?
> 
> No, that wasn't my intention. My intention for the load type tag was
> to have one tag that unambiguously describes the payload format and if
> that is missing, fall back to the previous logic for compatibility.
> It avoids more complicated heuristics if different payload types are
> added in the future.
> 
> >
> > Would it be sensible for multiboot2 to use PE in preference to ELF if
> > present on the image?  (without requiring any signaling).  I would
> > think this could be troublesome if kernels are so far expecting the
> > ELF header to be used with multiboot2, even if they also expose a PE
> > header.
> >
> 
> AFAIK an ELF image can't also be a valid PE/COFF image since they have
> different magic numbers at the start of the image. Perhaps it would
> be simpler to avoid introducing the load type tag and just load the
> payload based on the magic number?

I would likely be fine with just handling it like we handle ELF, if a
PE header is found use it.  As long as ELF and PE headers are mutually
exclusive.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 11:45:20 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 11:45:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695876.1086115 (Exim 4.92)
	(envelope-from )
	id 1rmuNX-0008KX-TP; Wed, 20 Mar 2024 11:45:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695876.1086115; Wed, 20 Mar 2024 11:45:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmuNX-0008KQ-Pg; Wed, 20 Mar 2024 11:45:07 +0000
Received: by outflank-mailman (input) for mailman id 695876;
 Wed, 20 Mar 2024 11:45:07 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmuNX-0008KK-8d
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 11:45:07 +0000
Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com
 [2607:f8b0:4864:20::835])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4b5dc919-e6af-11ee-afdd-a90da7624cb6;
 Wed, 20 Mar 2024 12:45:06 +0100 (CET)
Received: by mail-qt1-x835.google.com with SMTP id
 d75a77b69052e-430a7497700so42375041cf.1
 for ; Wed, 20 Mar 2024 04:45:06 -0700 (PDT)
Received: from [10.80.67.139] (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 kk12-20020a05622a2c0c00b0042f3830ef2csm7380661qtb.33.2024.03.20.04.45.03
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 20 Mar 2024 04:45:04 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4b5dc919-e6af-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710935105; x=1711539905; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=CZAQvVoBCyzU/1oUrCyBVFll9V2JjiyFu0n8HcXYqGY=;
        b=ispV/x+UytR41XoT8wgEN/yogXz0kWHA8bylnYljgFVFpP8A+8nIu8ueQDAoypZT4w
         Y1NHS7dKY5REo879ndw5yxeg68PmMlAivnVMPzVJRQzfqLtq08cKPlsYtxwFQ/KErv1X
         3I8+rE+/S+HeImJ59PvZahpJA6jalXcLhfBfU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710935105; x=1711539905;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=CZAQvVoBCyzU/1oUrCyBVFll9V2JjiyFu0n8HcXYqGY=;
        b=IXUpCwlAxPtA+3nkPkQd7HCqfZtvm86lwakCWBV2H1/ves2rkIgE3KeeKJ5bg+jC/S
         O7bglRrfBUAlQzqoRkqdin87szjdjcLM6PIYM2ebY5utE9q1Z55bw+BFxpxAA0qlE3BJ
         213liODIVYSg8q4eYACDX3V5cFJWRC8tJeRC+w+m9mVU9oHCLV6MopWJRX/Oq1pOgXNt
         NC9tJC+iBVJTjlg2+XigisLM1A5Ark+JO8gPtDfuNTstp031DkFnET64MYOwDxrzXNGU
         wkTEN3KDtzLYLXqujRabnRe6WJPfXG9/Djnh+jz2dIq5TwMYIjnQzI1yZnl8JHMcnN2D
         Ws4g==
X-Forwarded-Encrypted: i=1; AJvYcCWtNxxABJa85fUDS332J82EGl0nLJRe1L9YNM+CZqG4Hyvbx71b69v48q9K5HDD6dZ5vVmJwLZfwWlmnGpOZSGtluB4AQILUAG0emULPIA=
X-Gm-Message-State: AOJu0YzhWgpHftElhtvaif23t83vrG9GVLFKZlWltpCbDLdEQIMhxcWn
	Zn9nq/aP6bCOSy7/PblpmvcuzWhlFRXZxygtyLK6tlJbrcL4UvnOIEctBDuIhFg=
X-Google-Smtp-Source: AGHT+IEGXKDiwBuYKTnNokF6SyW+hE1eh5rvw6/6Am3prwEXWp4Mxx9nGosk18+xcnzk/MrpTUfOaw==
X-Received: by 2002:a05:622a:650:b0:430:b5ab:28ef with SMTP id a16-20020a05622a065000b00430b5ab28efmr18689020qtb.47.1710935104789;
        Wed, 20 Mar 2024 04:45:04 -0700 (PDT)
Message-ID: <9268c7e4-afb5-485b-aaf5-818b3f21c6e3@citrix.com>
Date: Wed, 20 Mar 2024 11:45:02 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/features: More AMD features
Content-Language: en-GB
To: Jan Beulich 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Xen-devel 
References: <20240318181332.3817631-1-andrew.cooper3@citrix.com>
 <8eb3d0d4-daf2-40a4-83b6-d3726e02814f@citrix.com>
 
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 20/03/2024 8:12 am, Jan Beulich wrote:
> On 19.03.2024 18:40, Andrew Cooper wrote:
>> It occurs to me that I need this hunk too.
>>
>> diff --git a/xen/tools/gen-cpuid.py b/xen/tools/gen-cpuid.py
>> index 25d329ce486f..bf3f9ec01e6e 100755
>> --- a/xen/tools/gen-cpuid.py
>> +++ b/xen/tools/gen-cpuid.py
>> @@ -329,6 +329,10 @@ def crunch_numbers(state):
>>          # In principle the TSXLDTRK insns could also be considered
>> independent.
>>          RTM: [TSXLDTRK],
>>  
>> +        # Enhanced Predictive Store-Forwarding is a informational note
>> on top
>> +        # of PSF.
>> +        PSFD: [EPSF],
>> +
>>          # The ARCH_CAPS CPUID bit enumerates the availability of the
>> whole register.
>>          ARCH_CAPS: list(range(RDCL_NO, RDCL_NO + 64)),
>>  
>>
>> To cause EPSF to disappear properly when levelling.
> What exactly is wrong with exposing EPSF when PSFD is not there?

https://www.amd.com/content/dam/amd/en/documents/processor-tech-docs/white-papers/security-analysis-of-amd-predictive-store-forwarding.pdf

Final sentence before the conclusion:

"Software can determine the presence of EPSF through CPUID Fn8000_0021
EAX[18]. All processors that support EPSF will also support PSFD."

i.e. you'll never see anything about PSF without having the controls to
turn it off.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 11:58:37 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 11:58:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695879.1086124 (Exim 4.92)
	(envelope-from )
	id 1rmuaV-0001xX-UJ; Wed, 20 Mar 2024 11:58:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695879.1086124; Wed, 20 Mar 2024 11:58:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmuaV-0001xQ-Rl; Wed, 20 Mar 2024 11:58:31 +0000
Received: by outflank-mailman (input) for mailman id 695879;
 Wed, 20 Mar 2024 11:58:30 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmuaU-0001x2-HO
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 11:58:30 +0000
Received: from mail-oo1-xc2e.google.com (mail-oo1-xc2e.google.com
 [2607:f8b0:4864:20::c2e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 298f4ffd-e6b1-11ee-a1ee-f123f15fe8a2;
 Wed, 20 Mar 2024 12:58:28 +0100 (CET)
Received: by mail-oo1-xc2e.google.com with SMTP id
 006d021491bc7-5a4859178f1so2808460eaf.0
 for ; Wed, 20 Mar 2024 04:58:28 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 298f4ffd-e6b1-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1710935907; x=1711540707; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=MwDg9N7WXY+pLHX5aSrXLQ6rAFFbiypegGbJlQ4JH3M=;
        b=QfbNOeb3m63zXXHxr5h/vObWeAGEPTrftgB1W6y3U6zTQTY7Ql/jhuuttFDEEEw0P9
         7hrx2aMcs0OVFHJ+bxsT/wGhmKcFwNyxn9sn9u+AuF4S2B0VCEQFM70JC8sRNllp2fu4
         sgAN6EUvbgGmLER2L34qCTbU1OaUDdOx423TM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710935907; x=1711540707;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=MwDg9N7WXY+pLHX5aSrXLQ6rAFFbiypegGbJlQ4JH3M=;
        b=CrXflFUU92zlZcrVAsXDA2xlHdqaZ3BpwBnHyxXnDR5Jk3dPyOS2jhnDMJXghRzATv
         iHnS372DUQEbC89hBbIQ2zOlPDEKkwKgHMMOn1DwZ45ib/zmO0d69lJUOiQCGwj8tGyV
         9toR7hc2w8Ehe6D19PMqoXh4LSLVJXfI4ld2aQeWcbr7YYKLvbCxlFvwAPb/iELOJrqN
         1H2swtBVTyF26eiJhz29Ey7S0Dhu1WTfGni9Wu96HGYOMoyaKb0uLwvQ/wjVS8SyAGXh
         26yKaFOObSay88SEoTipm3So4C66CQRJQGJOWplbqBLVFdM13UdImy4/+xanCMM4szI1
         rp7A==
X-Gm-Message-State: AOJu0Ywkov8j3wotGpNNA/o8sSzTjPtln8x9YqCWvDKp8KaloRg74fKC
	MBh9Cf3wP3s+GaU8eW/vpnhVV7BKJHnFXMeKJiXuKZZdo5F4uuzPbRCr3SGtK5Q3aMgfzjktijs
	nRF9hL5dNTCuSLyOJS6Wx2FdAVpd4xwfAzESdFg==
X-Google-Smtp-Source: AGHT+IE1OCbnyRjjqUF3PHySVpNyX9surZMHdnkOu/WzT05yQbZU3C7ioQT5njm1Vna8j3BLSU0ES6pi1UpF28KK2Ws=
X-Received: by 2002:a05:6871:588b:b0:21e:e6d1:616c with SMTP id
 ok11-20020a056871588b00b0021ee6d1616cmr19993024oac.31.1710935907129; Wed, 20
 Mar 2024 04:58:27 -0700 (PDT)
MIME-Version: 1.0
References: <20240318163552.3808695-1-andrew.cooper3@citrix.com> <20240318163552.3808695-2-andrew.cooper3@citrix.com>
In-Reply-To: <20240318163552.3808695-2-andrew.cooper3@citrix.com>
From: George Dunlap 
Date: Wed, 20 Mar 2024 11:58:16 +0000
Message-ID: 
Subject: Re: [PATCH 1/7] xen/trace: Introduce new API
To: Andrew Cooper 
Cc: Xen-devel , 
	George Dunlap , Jan Beulich , 
	Stefano Stabellini , Julien Grall , 
	Nicola Vetrini , 
	"consulting @ bugseng . com" 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Mar 18, 2024 at 4:36=E2=80=AFPM Andrew Cooper  wrote:
>
> trace() and trace_time(), in function form for struct arguments, and macr=
o
> form for simple uint32_t list arguments.
>
> This will be used to clean up the mess of macros which exists throughout =
the
> codebase, as well as eventually dropping __trace_var().
>
> There is intentionally no macro to split a 64-bit parameter in the new AP=
I,
> for MISRA reasons.
>
> Signed-off-by: Andrew Cooper 

Thanks for doing this, it all looks good to me.

I'll note that last time this was posted, there were some questions.
One was regarding underscores in the macro parameters.  I don't care
about this enough to stop it going in.

The other question was about the use of ##__VA_ARGS__. I don't
actually understand what that comment was trying to say, as a quick
Google search it appears that 1) this will do what I think it should
do, and 2) it works both in gcc and clang.

We should give Jan a chance to explain his second point more clearly
before checking it in; but:

Reviewed-by: George Dunlap 


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 12:17:05 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 12:17:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695887.1086134 (Exim 4.92)
	(envelope-from )
	id 1rmusE-0005Wj-M5; Wed, 20 Mar 2024 12:16:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695887.1086134; Wed, 20 Mar 2024 12:16:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmusE-0005Wc-Je; Wed, 20 Mar 2024 12:16:50 +0000
Received: by outflank-mailman (input) for mailman id 695887;
 Wed, 20 Mar 2024 12:16:48 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmusC-0005WB-Tj
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 12:16:48 +0000
Received: from mail-oa1-x2b.google.com (mail-oa1-x2b.google.com
 [2001:4860:4864:20::2b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b7b1598e-e6b3-11ee-a1ee-f123f15fe8a2;
 Wed, 20 Mar 2024 13:16:46 +0100 (CET)
Received: by mail-oa1-x2b.google.com with SMTP id
 586e51a60fabf-2218da9620cso4127203fac.3
 for ; Wed, 20 Mar 2024 05:16:46 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b7b1598e-e6b3-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1710937004; x=1711541804; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=jxTehvAy01ef+xD6YVY/YpS6ickPDvxqOMXF4vv3hD8=;
        b=Nv/qLBFRHqacuRWRQmkotgfMFAc4Sobozb73esiHW9nltCXzlrRZwcHDrZjl+bjQr8
         hla+X/7LbKED4J3xxT7cOiIBnbOQvV3EeEz3uzrT04vxPCL88eM+ED6QmFbo4tOSwV2l
         Uta5UIR61j0zTgGwnGtDPOI7XR/IGyOXx9rDI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710937004; x=1711541804;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=jxTehvAy01ef+xD6YVY/YpS6ickPDvxqOMXF4vv3hD8=;
        b=PsV3t9cwOhBs3EZFNw1OO1niCP7x7hAnzwKKkP/R8+qHPlWFv7OQI3Xh6eDu64U8vg
         tph93aVn509Ol22FWToWeyU4nqUrattJP0iVrvpQLdNkHIsJBK0FSL/BzvmzT2YbPKdi
         9wQZbC9oc8N4hdbFvooM2hiWCV3x18Rnofpblf39HNSB2DVLjh2JPOAFUz6Vzl9EczlE
         c9vr7c5GqAyohmsxiyDejJJsuMemIIuMHkFRrNsxpcuGEDSd3Zs7EWSzf/qZiecdeMg9
         1DxoJjfeefBh1XUhlGQ6rKdu0j7ZZ6KPdWaipdqNGVH4V1Wo/yOZmgZLagauyx7S9fEi
         JuLw==
X-Gm-Message-State: AOJu0YyFEGGRDTiI9b4J78fl6IlR80MXYi/e+4O/NlhAqEsEOgKI7oOW
	33NCPqhySaZcwn2j61AzwDD9dVgj+38GaO+5TNrNt2WcaS7071XDB89ps2uxzBCBauYlobITlxJ
	oSRxDyab4UOd8sFNBIJJVca1zGBkwCR2b8LDcYQ==
X-Google-Smtp-Source: AGHT+IFd9gBqs6P8Egl/tb96SbBAUYGXBgrkrsKgvk6ABPS1BpTVmFy3xlhg5waCNLGzqrgRvzJWzC9HBu09bDLYKOE=
X-Received: by 2002:a05:6870:3101:b0:220:8d2e:c78d with SMTP id
 v1-20020a056870310100b002208d2ec78dmr19302983oaa.7.1710937004561; Wed, 20 Mar
 2024 05:16:44 -0700 (PDT)
MIME-Version: 1.0
References: <20240318163552.3808695-1-andrew.cooper3@citrix.com> <20240318163552.3808695-3-andrew.cooper3@citrix.com>
In-Reply-To: <20240318163552.3808695-3-andrew.cooper3@citrix.com>
From: George Dunlap 
Date: Wed, 20 Mar 2024 12:16:33 +0000
Message-ID: 
Subject: Re: [PATCH 2/7] xen/credit2: Clean up trace handling
To: Andrew Cooper 
Cc: Xen-devel , Jan Beulich , 
	Dario Faggioli , George Dunlap , 
	Stefano Stabellini , Julien Grall , 
	Nicola Vetrini , 
	"consulting @ bugseng . com" 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Mar 18, 2024 at 4:36=E2=80=AFPM Andrew Cooper  wrote:
>
> There is no need for bitfields anywhere - use more sensible types.  There=
 is
> also no need to cast 'd' to (unsigned char *) before passing it to a func=
tion
> taking void *.  Switch to new trace_time() API.
>
> No functional change.

Hey Andrew -- overall changes look great, thanks for doing this very
detailed work.

One issue here is that you've changed a number of signed values to
unsigned values; for example:

> @@ -1563,16 +1559,16 @@ static s_time_t tickle_score(const struct schedul=
er *ops, s_time_t now,
>      if ( unlikely(tb_init_done) )
>      {
>          struct {
> -            unsigned unit:16, dom:16;
> -            int credit, score;
> -        } d;
> -        d.dom =3D cur->unit->domain->domain_id;
> -        d.unit =3D cur->unit->unit_id;
> -        d.credit =3D cur->credit;
> -        d.score =3D score;
> -        __trace_var(TRC_CSCHED2_TICKLE_CHECK, 1,
> -                    sizeof(d),
> -                    (unsigned char *)&d);
> +            uint16_t unit, dom;
> +            uint32_t credit, score;

...here you change `int` to `unit32_t`; but `credit` and `score` are
both signed values, which may be negative.  There are a number of
other similar instances.  In general, if there's a signed value, it
was meant.

I don't want to delay this another 3 years, so if there's not a strong
argument in favor of converting the signed types into uint32_t, I can
make the change myself and re-submit the series.

(I'll probably end up making a change to xenalyze.c as well, to update
the structure definitions there to match what's in Xen, so it wouldn't
be any extra effort.)

 -George


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 12:19:45 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 12:19:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695889.1086145 (Exim 4.92)
	(envelope-from )
	id 1rmuv2-0006TB-4k; Wed, 20 Mar 2024 12:19:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695889.1086145; Wed, 20 Mar 2024 12:19:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmuv2-0006T4-0n; Wed, 20 Mar 2024 12:19:44 +0000
Received: by outflank-mailman (input) for mailman id 695889;
 Wed, 20 Mar 2024 12:19:42 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmuv0-0006Sy-Ay
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 12:19:42 +0000
Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com
 [2607:f8b0:4864:20::733])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1fc83bcb-e6b4-11ee-a1ee-f123f15fe8a2;
 Wed, 20 Mar 2024 13:19:40 +0100 (CET)
Received: by mail-qk1-x733.google.com with SMTP id
 af79cd13be357-789e83637e0so294055885a.2
 for ; Wed, 20 Mar 2024 05:19:40 -0700 (PDT)
Received: from [10.80.67.139] (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 j8-20020a37c248000000b00789e6cc73e6sm4987468qkm.48.2024.03.20.05.19.37
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 20 Mar 2024 05:19:38 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1fc83bcb-e6b4-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710937179; x=1711541979; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=0uERgRqE/pW0ekxHvJSU8DMKsA+1dq4drch8FXNrkDY=;
        b=hN4m0SqUVIr5ZmiP6f1VbkjwFNsp+gt1vDdLKSD3cPokl0xBKPVx6HdKum1XlJxqfO
         6Ap4SXUb+n5969BugEYq0q1nhsbkJB7a0J758GnayNjVAS0Kdtehd2+tp/vff4lc6POx
         SDeiY/pIdKBci+V67BEyV6UcYhQPBbGsY4dK0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710937179; x=1711541979;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=0uERgRqE/pW0ekxHvJSU8DMKsA+1dq4drch8FXNrkDY=;
        b=JF+wRNtY9Fr4Fr4F2wmfJZIzkd4EB64Ml8TThgTVOxesWRL5UAuc/PE8qe77xlGked
         E7fa7MwJ5gT5pQXUeutDmioxH+CwwMftPNU9rcQ9KFP77WZBnbeKak4vFxkWYD+IUVBc
         LmaSE+4HGTv9qPYcDPy4kDtilKT+jUOVPzDPC65t2OgS6H+ujHP+Uq7Xat5pccAwaGf8
         fFy66Yxa1ktjhLCqRNmEQy6qaR5EuT15U/ZIIikXLx8dAuDv0YZrBmA2b9ryeB/0aGyg
         k+bMjIIyZ1D65pQbgIbmqWDu65Opt7ci0pwqnd/oBiyGT9mIPwNJ8pT5ms4Oku1gNEuo
         1ipQ==
X-Gm-Message-State: AOJu0Yxe9BrcuTkgtpgUtnrV+8u+JWPEyzkmInh6fjA+I67f58VOTywG
	qhKZV2BwuzV4imKT+uEm1Xl8pTMsWXoC/E7UsZTFhsFdOInTHIzd7eYN5Nq3jR8=
X-Google-Smtp-Source: AGHT+IEcNUUrZgbjS8UTTfjq+0R1ojjrRFLdx1yqWSMjZNhZ8zR44I0PeZP2f6+aZZCZINGSUXuOtQ==
X-Received: by 2002:a05:620a:3b98:b0:78a:22ca:a31a with SMTP id ye24-20020a05620a3b9800b0078a22caa31amr1392679qkn.16.1710937179183;
        Wed, 20 Mar 2024 05:19:39 -0700 (PDT)
Message-ID: <19d9487e-67cf-4c1e-9dc6-419d9c5d0120@citrix.com>
Date: Wed, 20 Mar 2024 12:19:36 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/7] xen/credit2: Clean up trace handling
Content-Language: en-GB
To: George Dunlap 
Cc: Xen-devel ,
 Jan Beulich , Dario Faggioli ,
 George Dunlap ,
 Stefano Stabellini , Julien Grall ,
 Nicola Vetrini ,
 "consulting @ bugseng . com" 
References: <20240318163552.3808695-1-andrew.cooper3@citrix.com>
 <20240318163552.3808695-3-andrew.cooper3@citrix.com>
 
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 20/03/2024 12:16 pm, George Dunlap wrote:
> On Mon, Mar 18, 2024 at 4:36 PM Andrew Cooper  wrote:
>> There is no need for bitfields anywhere - use more sensible types.  There is
>> also no need to cast 'd' to (unsigned char *) before passing it to a function
>> taking void *.  Switch to new trace_time() API.
>>
>> No functional change.
> Hey Andrew -- overall changes look great, thanks for doing this very
> detailed work.
>
> One issue here is that you've changed a number of signed values to
> unsigned values; for example:
>
>> @@ -1563,16 +1559,16 @@ static s_time_t tickle_score(const struct scheduler *ops, s_time_t now,
>>      if ( unlikely(tb_init_done) )
>>      {
>>          struct {
>> -            unsigned unit:16, dom:16;
>> -            int credit, score;
>> -        } d;
>> -        d.dom = cur->unit->domain->domain_id;
>> -        d.unit = cur->unit->unit_id;
>> -        d.credit = cur->credit;
>> -        d.score = score;
>> -        __trace_var(TRC_CSCHED2_TICKLE_CHECK, 1,
>> -                    sizeof(d),
>> -                    (unsigned char *)&d);
>> +            uint16_t unit, dom;
>> +            uint32_t credit, score;
> ...here you change `int` to `unit32_t`; but `credit` and `score` are
> both signed values, which may be negative.  There are a number of
> other similar instances.  In general, if there's a signed value, it
> was meant.

Oh - this is a consequence of being reviewed that way in earlier iterations.

If they really can hold negative numbers, they can become int32_t's. 
What's important is that they have a clearly-specified width.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 12:30:28 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 12:30:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695894.1086155 (Exim 4.92)
	(envelope-from )
	id 1rmv5K-0000z4-W1; Wed, 20 Mar 2024 12:30:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695894.1086155; Wed, 20 Mar 2024 12:30:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmv5K-0000yw-Ss; Wed, 20 Mar 2024 12:30:22 +0000
Received: by outflank-mailman (input) for mailman id 695894;
 Wed, 20 Mar 2024 12:30:22 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmv5K-0000yn-Jq; Wed, 20 Mar 2024 12:30:22 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmv5K-00069o-EI; Wed, 20 Mar 2024 12:30:22 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmv5K-0007i6-2s; Wed, 20 Mar 2024 12:30:22 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rmv5K-0005Sj-2P; Wed, 20 Mar 2024 12:30:22 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=rGOMVXhjS8rzQsM/yFpMLjYl2+y17grofgfFZ+U/zFA=; b=gtEXL4Hrw+p6M8lE5aRfjD6qrm
	1SDgRYNDmlzlehcZM3Wd5CuMXU9BV2RklKvOwynGYyeTgtXW+biJe3ugZ6gBdkwOtGxPAG2Lyx/+p
	cnC+eVdwM5Kt5tp8FGtdcfjVDnjquFEa45MgSxqTr8ckX7ylyxoOOemHZRJULS8JWuHs=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 185109: tolerable all pass - PUSHED
X-Osstest-Failures:
    xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    xen=eaafbd11344a8ec32309fe58a6e529fe1c34d62e
X-Osstest-Versions-That:
    xen=188fa82305e72b725473db9146e20cc9abf7bff3
From: osstest service owner 
Date: Wed, 20 Mar 2024 12:30:22 +0000

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          16 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  eaafbd11344a8ec32309fe58a6e529fe1c34d62e
baseline version:
 xen                  188fa82305e72b725473db9146e20cc9abf7bff3

Last test of basis   185100  2024-03-19 19:00:31 Z    0 days
Testing same since   185109  2024-03-20 09:03:31 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Anthony PERARD 
  Julien Grall 

jobs:
 build-arm64-xsm                                              pass    
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-amd64-libvirt                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 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
   188fa82305..eaafbd1134  eaafbd11344a8ec32309fe58a6e529fe1c34d62e -> smoke


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 12:51:34 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 12:51:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695900.1086167 (Exim 4.92)
	(envelope-from )
	id 1rmvPd-0004Iw-JR; Wed, 20 Mar 2024 12:51:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695900.1086167; Wed, 20 Mar 2024 12:51:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmvPd-0004Ip-GO; Wed, 20 Mar 2024 12:51:21 +0000
Received: by outflank-mailman (input) for mailman id 695900;
 Wed, 20 Mar 2024 12:51:19 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmvPb-0004Ij-PR
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 12:51:19 +0000
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com
 [2a00:1450:4864:20::634])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8b6a9bbe-e6b8-11ee-afdd-a90da7624cb6;
 Wed, 20 Mar 2024 13:51:18 +0100 (CET)
Received: by mail-ej1-x634.google.com with SMTP id
 a640c23a62f3a-a46d9fbb5a5so267055166b.2
 for ; Wed, 20 Mar 2024 05:51:18 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 z23-20020a1709060f1700b00a46478fbbbesm7206031eji.153.2024.03.20.05.51.17
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 20 Mar 2024 05:51:17 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8b6a9bbe-e6b8-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710939078; x=1711543878; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=ZRJe4oTEQBLFAXfalqLcXnYU7K14oWigY+8BJS/reIg=;
        b=UHxiyx5L3GWGQQQU0PKxU9XAkWuPB320ncHEvo5pPf4NLuyxH7y7K1UevaVOz5fDci
         IICLiwMF4kSiFzlH3naGpP+8qOECT8INLYGYwsX3DffoMTis8h+W0nrRKiXtfXEYlEn1
         7MefFWULFInvbIeqhQ9W7AjTgTXDcoOXzMYf4wmclR37QoKLsv4AixdkmFCLXEbF2ad3
         YczR9FTaRF5sSwkwUUE6bEpUb/sMejEJPDtJYtQCT/RnaIxgkDHvuLeXYauOMDQykT/7
         z4QuDpjhCKBOqd1Jih3bJK+gPPGftbCg/5/Hyjm0/Yhg6kWjbV4IXKwduA2BS/tKs3Jz
         S+ng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710939078; x=1711543878;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=ZRJe4oTEQBLFAXfalqLcXnYU7K14oWigY+8BJS/reIg=;
        b=DYEeflDkfuMgODareFsOW7Bd4DBYXRZVOmRRIJt4f+L5XdrPIpOU06L+u9L7e/yJD3
         Eu+i52uId9jXGvcFQ86cSfFDBVxJQohsEHTSY3n2KViALDyHcxMmP9BhuTQWbCRNCBxn
         /900OEdfKSNRw9laiTQywVLd6tnz9MNq2kC+hcDf9AVI6UQI4hgKGW+HC7KQbbNT3A4k
         9a7QOVddHx25vmJiENyaopNh9tcG7NH3M1FsD2IBoeQD0zR56F+USRNe8gWoHoFn+DIS
         PA3CU1OXWWh3QCk+r3g8pXnsOCmDO+mNNC7tIKMQQq/FUMkOjIjgivhYOiM8Xj41yTd7
         ZUWQ==
X-Forwarded-Encrypted: i=1; AJvYcCXyZo3ki7xKpHmKd4WTh8bXCOiA0ym7z/u/wAaYrwI6cByckbPF/DIpyugROhSwW9p3I7cuSCWXz7CLG0760RhyfEapwQNb3E82i/WEuLM=
X-Gm-Message-State: AOJu0YzG4flOtgTA1PzjQLdgmcri+m+mRjlGIXNbPpaqBEkBpdnzhsDk
	zAuxiGPxBtr3qyt8axnOKTI+g83yvJOxn48FTAdfA71Uo6pPtpEUTTgRDlb55Zip/HlO5XSoh0k
	=
X-Google-Smtp-Source: AGHT+IGfnpl65eE1PBF0ifCr6zD1JaDJN0GjGH2neM7L76rE8HOmPZMDu/0ZMoOUbq6YHGkKM1EgcQ==
X-Received: by 2002:a17:907:369:b0:a46:22fc:74d3 with SMTP id rs9-20020a170907036900b00a4622fc74d3mr3380041ejb.72.1710939077856;
        Wed, 20 Mar 2024 05:51:17 -0700 (PDT)
Message-ID: 
Date: Wed, 20 Mar 2024 13:51:16 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/features: More AMD features
Content-Language: en-US
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Xen-devel 
References: <20240318181332.3817631-1-andrew.cooper3@citrix.com>
 <8eb3d0d4-daf2-40a4-83b6-d3726e02814f@citrix.com>
 
 <9268c7e4-afb5-485b-aaf5-818b3f21c6e3@citrix.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <9268c7e4-afb5-485b-aaf5-818b3f21c6e3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 20.03.2024 12:45, Andrew Cooper wrote:
> On 20/03/2024 8:12 am, Jan Beulich wrote:
>> On 19.03.2024 18:40, Andrew Cooper wrote:
>>> It occurs to me that I need this hunk too.
>>>
>>> diff --git a/xen/tools/gen-cpuid.py b/xen/tools/gen-cpuid.py
>>> index 25d329ce486f..bf3f9ec01e6e 100755
>>> --- a/xen/tools/gen-cpuid.py
>>> +++ b/xen/tools/gen-cpuid.py
>>> @@ -329,6 +329,10 @@ def crunch_numbers(state):
>>>          # In principle the TSXLDTRK insns could also be considered
>>> independent.
>>>          RTM: [TSXLDTRK],
>>>  
>>> +        # Enhanced Predictive Store-Forwarding is a informational note
>>> on top
>>> +        # of PSF.
>>> +        PSFD: [EPSF],
>>> +
>>>          # The ARCH_CAPS CPUID bit enumerates the availability of the
>>> whole register.
>>>          ARCH_CAPS: list(range(RDCL_NO, RDCL_NO + 64)),
>>>  
>>>
>>> To cause EPSF to disappear properly when levelling.
>> What exactly is wrong with exposing EPSF when PSFD is not there?
> 
> https://www.amd.com/content/dam/amd/en/documents/processor-tech-docs/white-papers/security-analysis-of-amd-predictive-store-forwarding.pdf
> 
> Final sentence before the conclusion:
> 
> "Software can determine the presence of EPSF through CPUID Fn8000_0021
> EAX[18]. All processors that support EPSF will also support PSFD."
> 
> i.e. you'll never see anything about PSF without having the controls to
> turn it off.

Ah, I only had an old copy of that. My R-b holds then with that addition.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 13:05:12 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 13:05:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695904.1086180 (Exim 4.92)
	(envelope-from )
	id 1rmvcx-0006NQ-Po; Wed, 20 Mar 2024 13:05:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695904.1086180; Wed, 20 Mar 2024 13:05:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmvcx-0006NJ-NJ; Wed, 20 Mar 2024 13:05:07 +0000
Received: by outflank-mailman (input) for mailman id 695904;
 Wed, 20 Mar 2024 13:05:06 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmvcw-0006ND-FX
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 13:05:06 +0000
Received: from mail-oa1-x2d.google.com (mail-oa1-x2d.google.com
 [2001:4860:4864:20::2d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 76403f2a-e6ba-11ee-a1ee-f123f15fe8a2;
 Wed, 20 Mar 2024 14:05:02 +0100 (CET)
Received: by mail-oa1-x2d.google.com with SMTP id
 586e51a60fabf-221a9e5484aso4436087fac.0
 for ; Wed, 20 Mar 2024 06:05:02 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 76403f2a-e6ba-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1710939901; x=1711544701; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=izQzpUbL1dpO3IoB7vXcaReCh2kIbRFcbdk/5mplQx4=;
        b=TQ637XUoEImu/9KnwttZoVma7vZD8dnjrbjWL0T+XN4DAl98C9eTS5Q97cirOaE5b4
         HWNH8tbnrMhD+l2OW4HQW+K5En8qGrckD4Oe4JFdn1JohLuOia9kQa+1zIv75970zPIS
         TcDfceE+T2vQT8DvB7xXz5Oh+LYnMtj8bhkaM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710939901; x=1711544701;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=izQzpUbL1dpO3IoB7vXcaReCh2kIbRFcbdk/5mplQx4=;
        b=DGodkmSwq4y8LYFK3BtqV2551QTtALc7tx1k4Xplm2qQMlbMVd0bollA6zOW1cfR1C
         wiZq6I56aYMMQkIfv59jR7ocSPy0fh2gmhsDWuuu2bRwuA0PPPaWvY1lX4/FtZj/Gkk0
         R7BZw2VXxMojCeaaf2PXiY3LDe2xPdSqyqnLMvpYuPW9KEg3N6T6mBhVcJKZ6eyQC6jf
         FwvVJ2T9VqA1eUOH6I1UGnXlEjK1BkT6YsmWisAJx9RWn6xF6/pzV6B2xY0s0WEKiuqS
         a1++/MfqPyJoe2Q7OaAttfwb5AqXZ9j5DwbDhaeSjdJ4ecnXl2V9+uD6dCqIL37MNsVK
         OKRQ==
X-Gm-Message-State: AOJu0Yx62hMWtVYXhBhLHmEIzkUD2uUfVNtTjiCRo3JJTHKPAeM/McbG
	XBs+MdASvJT5c1MqX4/ABBfv4zByWTeISS4851LZpXC/l5XMBFnfLWcVA22HVN+9rWoQwgQZjY1
	OcZKsb3JPsZagY6OK7GMSRt829/lG37f5M5mGEQ==
X-Google-Smtp-Source: AGHT+IGovfy95FbuhemsJdyxgQbq7yGz8amTU9+gWwj5ifvmfOWd0UnougtFkNqzKUTEKomfO4/zWQ6xWhPdBhgNLpw=
X-Received: by 2002:a05:6870:20f:b0:21e:6b95:fb2d with SMTP id
 j15-20020a056870020f00b0021e6b95fb2dmr19199336oad.18.1710939901138; Wed, 20
 Mar 2024 06:05:01 -0700 (PDT)
MIME-Version: 1.0
References: <20240318163552.3808695-1-andrew.cooper3@citrix.com>
 <20240318163552.3808695-3-andrew.cooper3@citrix.com> 
 <19d9487e-67cf-4c1e-9dc6-419d9c5d0120@citrix.com>
In-Reply-To: <19d9487e-67cf-4c1e-9dc6-419d9c5d0120@citrix.com>
From: George Dunlap 
Date: Wed, 20 Mar 2024 13:04:50 +0000
Message-ID: 
Subject: Re: [PATCH 2/7] xen/credit2: Clean up trace handling
To: Andrew Cooper 
Cc: Xen-devel , Jan Beulich , 
	Dario Faggioli , George Dunlap , 
	Stefano Stabellini , Julien Grall , 
	Nicola Vetrini , 
	"consulting @ bugseng . com" 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Mar 20, 2024 at 12:19=E2=80=AFPM Andrew Cooper
 wrote:
>
> On 20/03/2024 12:16 pm, George Dunlap wrote:
> > On Mon, Mar 18, 2024 at 4:36=E2=80=AFPM Andrew Cooper  wrote:
> >> There is no need for bitfields anywhere - use more sensible types.  Th=
ere is
> >> also no need to cast 'd' to (unsigned char *) before passing it to a f=
unction
> >> taking void *.  Switch to new trace_time() API.
> >>
> >> No functional change.
> > Hey Andrew -- overall changes look great, thanks for doing this very
> > detailed work.
> >
> > One issue here is that you've changed a number of signed values to
> > unsigned values; for example:
> >
> >> @@ -1563,16 +1559,16 @@ static s_time_t tickle_score(const struct sche=
duler *ops, s_time_t now,
> >>      if ( unlikely(tb_init_done) )
> >>      {
> >>          struct {
> >> -            unsigned unit:16, dom:16;
> >> -            int credit, score;
> >> -        } d;
> >> -        d.dom =3D cur->unit->domain->domain_id;
> >> -        d.unit =3D cur->unit->unit_id;
> >> -        d.credit =3D cur->credit;
> >> -        d.score =3D score;
> >> -        __trace_var(TRC_CSCHED2_TICKLE_CHECK, 1,
> >> -                    sizeof(d),
> >> -                    (unsigned char *)&d);
> >> +            uint16_t unit, dom;
> >> +            uint32_t credit, score;
> > ...here you change `int` to `unit32_t`; but `credit` and `score` are
> > both signed values, which may be negative.  There are a number of
> > other similar instances.  In general, if there's a signed value, it
> > was meant.
>
> Oh - this is a consequence of being reviewed that way in earlier iteratio=
ns.
>
> If they really can hold negative numbers, they can become int32_t's.
> What's important is that they have a clearly-specified width.

Oh yes, sorry if that wasn't clear -- I was suggesting int32_t, unless
there was some compelling reason to do otherwise.  I just realize that
the last time this series had some review comments, it took 3 years to
come back around, and it would be a shame if that happened again; so
I'm happy to go through and do the change.

 -George


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 13:10:00 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 13:10:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695908.1086191 (Exim 4.92)
	(envelope-from )
	id 1rmvhe-0007Mu-Gn; Wed, 20 Mar 2024 13:09:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695908.1086191; Wed, 20 Mar 2024 13:09:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmvhe-0007Mn-DP; Wed, 20 Mar 2024 13:09:58 +0000
Received: by outflank-mailman (input) for mailman id 695908;
 Wed, 20 Mar 2024 13:09:57 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmvhd-0007Mf-EI
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 13:09:57 +0000
Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com
 [2a00:1450:4864:20::12f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 25455601-e6bb-11ee-a1ee-f123f15fe8a2;
 Wed, 20 Mar 2024 14:09:55 +0100 (CET)
Received: by mail-lf1-x12f.google.com with SMTP id
 2adb3069b0e04-513ccc70a6dso11508189e87.1
 for ; Wed, 20 Mar 2024 06:09:55 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 qt11-20020a170906eceb00b00a46d2e9fd73sm2567415ejb.222.2024.03.20.06.09.54
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 20 Mar 2024 06:09:54 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 25455601-e6bb-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710940195; x=1711544995; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=GDAtE6pMunSN2aoshMW+PYqPKc8voG7r1xGtdTypMfo=;
        b=Acr5bSuAy7+YJOkL63dnjay7i5neGjmwVUfeqE/Vi+uYKvRMo6dCvgg6BKAzq7fB3Q
         8JJMfU70Tf1Rfdg/So3lGa1QDYCtV6lUtQ2+H5JgSjj1WJKpCMe4DZ855zxT8VA6Rt68
         /AZMh9/jTyGSIRzkG7lqQvqLHxn8sGHXn1tEwCbd25lrP66FO1bN/pd/wYdr2+QVBRxb
         jcCfuT4siDoyrLtW9rUzwR69ILeWwRCjbO9Pebvlkd7wrCoZ4hwqvdQgeYv/RVHjYFSy
         wnuAaT9Cw9YXXlOF7iJF+sktjYOL6OTdI2Uqa5mmuclaz/Apn+6gmBzzIDxbpwJ5ljsT
         QCZA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710940195; x=1711544995;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=GDAtE6pMunSN2aoshMW+PYqPKc8voG7r1xGtdTypMfo=;
        b=A9p/3Xpe54ydqAj7sDjw+944MsX3+XHvy2AOumm7xdrKFnxuJhysCjidpBGbsf0NYW
         ne0bp+qhrjW6IgtLit9ssbzqRlIwpc6onUXWcAze7xt+n8g8Zp4BdEMzFWdLcRHHmlkA
         ntISJqwNLm3ZQzxs2Ac7ZRahQLvyqmn49aWRG7B+zpmZoZ98Sgw3R7Xg/sj9rXSKTqUV
         8Lyayp5k8pK2aEK7n/IWxA9+2Em3EORQy3MC9r296ZW90jvp79NFJAr2iHPgvtB/Q/rC
         G8l9U84DrkSVcuHIG+PFCxmp+k/bq4BMOYWAEiIMaf1GaI/gEQ15beiJoQjnzp//Icf2
         hcKA==
X-Gm-Message-State: AOJu0YzLreiRWS0If8kQK5AdzLxA+99GE6ZxlCw19Msdo9EnB7iOpRr9
	sEAsbQIsA+64yL1vt22ASxGVDr/lGQYibmjb3fNE2b79hsJDu3DqhXrZpBfMYQ==
X-Google-Smtp-Source: AGHT+IGq/EARVD0JUtEy8N5UoOUNBjp13mNAGUQVPH9Av22FSZx4S+RxZ9tm3eKI5abvqgfmX6EAIw==
X-Received: by 2002:a19:2d10:0:b0:513:af27:df03 with SMTP id k16-20020a192d10000000b00513af27df03mr10540479lfj.5.1710940194797;
        Wed, 20 Mar 2024 06:09:54 -0700 (PDT)
Message-ID: 
Date: Wed, 20 Mar 2024 14:09:53 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/7] xen/trace: Introduce new API
Content-Language: en-US
To: George Dunlap ,
 Andrew Cooper 
Cc: Xen-devel ,
 George Dunlap ,
 Stefano Stabellini , Julien Grall ,
 Nicola Vetrini ,
 "consulting @ bugseng . com" 
References: <20240318163552.3808695-1-andrew.cooper3@citrix.com>
 <20240318163552.3808695-2-andrew.cooper3@citrix.com>
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 20.03.2024 12:58, George Dunlap wrote:
> On Mon, Mar 18, 2024 at 4:36 PM Andrew Cooper  wrote:
>>
>> trace() and trace_time(), in function form for struct arguments, and macro
>> form for simple uint32_t list arguments.
>>
>> This will be used to clean up the mess of macros which exists throughout the
>> codebase, as well as eventually dropping __trace_var().
>>
>> There is intentionally no macro to split a 64-bit parameter in the new API,
>> for MISRA reasons.
>>
>> Signed-off-by: Andrew Cooper 
> 
> Thanks for doing this, it all looks good to me.
> 
> I'll note that last time this was posted, there were some questions.
> One was regarding underscores in the macro parameters.  I don't care
> about this enough to stop it going in.

We ought to finally settle on our take on this, preferably recording
the outcome in ./CODING_STYLE.

> The other question was about the use of ##__VA_ARGS__. I don't
> actually understand what that comment was trying to say, as a quick
> Google search it appears that 1) this will do what I think it should
> do, and 2) it works both in gcc and clang.
> 
> We should give Jan a chance to explain his second point more clearly
> before checking it in;

Well. Gcc 13.2 documentation explicitly mentions this form; interestingly
with a quick search I couldn't find the original extension's documentation
anymore. It is possible that I didn't spot this 2.5 years ago. It is also
possible the their doc has changed in the meantime. In any event, my view
back at the time was that I'd preferably see us use the (long-standing)
gcc extension (args...) or use __VA_ARGS__ in a standard compliant way.
Yet with the original form no longer properly documented, maybe they have
a plan to remove that at some point. So while my preference stays for the
time being, I also don't mind if this code is left as is.

Jan

> but:
> 
> Reviewed-by: George Dunlap 



From xen-devel-bounces@lists.xenproject.org Wed Mar 20 13:13:19 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 13:13:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695910.1086200 (Exim 4.92)
	(envelope-from )
	id 1rmvko-0000VB-V7; Wed, 20 Mar 2024 13:13:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695910.1086200; Wed, 20 Mar 2024 13:13:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmvko-0000V4-Sc; Wed, 20 Mar 2024 13:13:14 +0000
Received: by outflank-mailman (input) for mailman id 695910;
 Wed, 20 Mar 2024 13:13:13 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmvkn-0000Uy-Ck
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 13:13:13 +0000
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com
 [2a00:1450:4864:20::531])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9a92a5ab-e6bb-11ee-afdd-a90da7624cb6;
 Wed, 20 Mar 2024 14:13:12 +0100 (CET)
Received: by mail-ed1-x531.google.com with SMTP id
 4fb4d7f45d1cf-566e869f631so7600497a12.0
 for ; Wed, 20 Mar 2024 06:13:12 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 g18-20020a056402091200b00568b6f73491sm5523208edz.14.2024.03.20.06.13.11
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 20 Mar 2024 06:13:11 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9a92a5ab-e6bb-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710940392; x=1711545192; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=D4Knu+N3h3s5QMvzeNSrDHIQP1y/gcNwYue6TG77bt8=;
        b=ItzZ1rgqS34aFAFs51EUdioIRhnIVto+BilT+FQRkXWfVqIB07KthY53ArGYfdclkd
         dq2PVOOHK/1gSsk2b/r9N347pc2RaYCgOIKa1m4do0A5m36yjrUtnRN39wcs7FhSU8oo
         wriC/VBLExqhP1Ak0Vc9J85Qg/ApFsLNghIDYo/eJUdA17kijZD9ZU1y6ow0jarXukJp
         FQfI8Raxg5E3sTq/iIYe2MO/SkiL8CpQdaEF968ChPPHJOVylZZf0wQex0e7EUK7ekeg
         z5aUlQeMkuXAvWotxWQMWetQ2377bdB8RQq+mDD+Zh66sE5j96WAG9yDCfddKZ7IXO1u
         clOQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710940392; x=1711545192;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=D4Knu+N3h3s5QMvzeNSrDHIQP1y/gcNwYue6TG77bt8=;
        b=xRPWsILgdYxqa8f9oZE0+DsxDmmk9rrajBHuEMSWCjCu3EFre0xttLyccGd/CyEeXL
         6PG8OIaOWqdVCLjginNlQeH7XVCHQxAY8oO2MB25yxJEQeYYIW1Mo3iNE1v0sPaHPHT/
         9veD4XNArMXC0mN0yZNZ52FoFAGspqa8WVB+eX1Sxl6Ol5roneyfjCDZx8RIpKAkROA+
         /egeuklEmWJuSsYeMD8Qii4jDpdqmzLPkkE+9zu8Fx06e8hODRRZmhKKJerjDnZJywE1
         pWeQ1/Ov10bagv9D/RtCoAU7jvfW30CHM1veQqIdY3tIaNEvElbemVL8TI8uCGKg1MlW
         uLBA==
X-Gm-Message-State: AOJu0Yzeu1gwa/6rbBxBjDtWLJX4N/T75RHKHcI5BhGl19khp1VdViVQ
	obHHSsR6EFRjo8SCPPd6d/Vrsj/Q693Av6/XgoTJVuXCXZzgRvAOFLeajQ7vTA==
X-Google-Smtp-Source: AGHT+IF4p505pV2rzIXObwWCPCriSjExyMKIcWfrtVXL561xq9VOABYXSWM1jYf8knfRLphzjRSQ1Q==
X-Received: by 2002:a05:6402:4499:b0:566:2aff:2d38 with SMTP id er25-20020a056402449900b005662aff2d38mr4255474edb.26.1710940391746;
        Wed, 20 Mar 2024 06:13:11 -0700 (PDT)
Message-ID: 
Date: Wed, 20 Mar 2024 14:13:10 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/7] xen/credit2: Clean up trace handling
Content-Language: en-US
To: Andrew Cooper ,
 George Dunlap 
Cc: Xen-devel ,
 Dario Faggioli ,
 George Dunlap ,
 Stefano Stabellini , Julien Grall ,
 Nicola Vetrini ,
 "consulting @ bugseng . com" 
References: <20240318163552.3808695-1-andrew.cooper3@citrix.com>
 <20240318163552.3808695-3-andrew.cooper3@citrix.com>
 
 <19d9487e-67cf-4c1e-9dc6-419d9c5d0120@citrix.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <19d9487e-67cf-4c1e-9dc6-419d9c5d0120@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 20.03.2024 13:19, Andrew Cooper wrote:
> On 20/03/2024 12:16 pm, George Dunlap wrote:
>> On Mon, Mar 18, 2024 at 4:36 PM Andrew Cooper  wrote:
>>> There is no need for bitfields anywhere - use more sensible types.  There is
>>> also no need to cast 'd' to (unsigned char *) before passing it to a function
>>> taking void *.  Switch to new trace_time() API.
>>>
>>> No functional change.
>> Hey Andrew -- overall changes look great, thanks for doing this very
>> detailed work.
>>
>> One issue here is that you've changed a number of signed values to
>> unsigned values; for example:
>>
>>> @@ -1563,16 +1559,16 @@ static s_time_t tickle_score(const struct scheduler *ops, s_time_t now,
>>>      if ( unlikely(tb_init_done) )
>>>      {
>>>          struct {
>>> -            unsigned unit:16, dom:16;
>>> -            int credit, score;
>>> -        } d;
>>> -        d.dom = cur->unit->domain->domain_id;
>>> -        d.unit = cur->unit->unit_id;
>>> -        d.credit = cur->credit;
>>> -        d.score = score;
>>> -        __trace_var(TRC_CSCHED2_TICKLE_CHECK, 1,
>>> -                    sizeof(d),
>>> -                    (unsigned char *)&d);
>>> +            uint16_t unit, dom;
>>> +            uint32_t credit, score;
>> ...here you change `int` to `unit32_t`; but `credit` and `score` are
>> both signed values, which may be negative.  There are a number of
>> other similar instances.  In general, if there's a signed value, it
>> was meant.
> 
> Oh - this is a consequence of being reviewed that way in earlier iterations.

Which in turn is a result of us still having way to many uses of plain
int when signed quantities aren't meant. Plus my suggestion to make
this explicit by saying "signed int" was rejected.

> If they really can hold negative numbers, they can become int32_t's. 
> What's important is that they have a clearly-specified width.

And please feel free to retain my R-b with any such adjustments.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 13:21:06 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 13:21:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695914.1086211 (Exim 4.92)
	(envelope-from )
	id 1rmvsB-0002TF-Mp; Wed, 20 Mar 2024 13:20:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695914.1086211; Wed, 20 Mar 2024 13:20:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmvsB-0002T8-KI; Wed, 20 Mar 2024 13:20:51 +0000
Received: by outflank-mailman (input) for mailman id 695914;
 Wed, 20 Mar 2024 13:20:50 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmvsA-0002T2-KO
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 13:20:50 +0000
Received: from mail-oo1-xc33.google.com (mail-oo1-xc33.google.com
 [2607:f8b0:4864:20::c33])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id aa1da123-e6bc-11ee-a1ee-f123f15fe8a2;
 Wed, 20 Mar 2024 14:20:48 +0100 (CET)
Received: by mail-oo1-xc33.google.com with SMTP id
 006d021491bc7-5a4f9f94e77so18060eaf.3
 for ; Wed, 20 Mar 2024 06:20:48 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: aa1da123-e6bc-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1710940847; x=1711545647; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=FsHdUwRpT3/MKsuJZCUcsvLi4kZKZQn6dmSkzhwcl8g=;
        b=iWnchXjm4Z5wGBZJSRX2k+39Y09Bp8oAN2+s21o45a+gOTsYJP3vlx6RIsO900Ss5Y
         ZBO4GaBhqwdimkqa2TimnQmHITPox4Vrgz9bi7qjnmC9PPUFCKJ9ts9sJQ36cl5v4i8b
         KrCZxGraeOI2XtAlvLWKRI+7CdEu0rJ0KYY34=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710940847; x=1711545647;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=FsHdUwRpT3/MKsuJZCUcsvLi4kZKZQn6dmSkzhwcl8g=;
        b=YqIxjvAIgRMvceLQP+utygJ5oa/0itiqHvYmbFa5Qe8UAmw623E7Mf40VlajNX6vl6
         DwAVarweFUGM1d4m6WiIdm68Dd1PwruDnHy56dajXX5AGGCSFMrtZsuLn7w2MUkONwIU
         CXMCuMZ6tESN1Etxn5x6ZVikWvr8Htupy63bCwuyczX89LaQQgizIfA/JiyaP4Ux+9Fo
         x9Z8hJPA9esziVhHO/2XX0IYjIXR1FryIT9rOHHlpiFqJBmiCXhjM0zBXA1Lvc7pUJuH
         QyYfxo1k3GfI68axGEZ2hUDVlf+pkYhYNXvwhm75cPY0qlLSEVFcYsMWxMC6OYYK4uA2
         JuOg==
X-Forwarded-Encrypted: i=1; AJvYcCWwu2Ro4UWwVoi2JpFE2x8z/L5VHQdZLJlcIfMY2Jd7tTClU0uw14u8wQ7poJZGCefC6tIsf6X0DVSK/YyUhkDQnu50+oDE8nKnv1Boc3k=
X-Gm-Message-State: AOJu0YwQKhLUfBT2zm7Mz3NjVzupIq6Fw/fNFvyaxgDQypgnLO4vGIuS
	PwVtTzK4O+anJxXjyn+q0bd0X1NMBrDx2bLXrM/L1CSxlhSN/7h0kGbvqql8XVhCK/tJnls0Bc0
	RzObJNq2P0nSGi5xmDi32mmdgtdtsmnWZ/NBEEg==
X-Google-Smtp-Source: AGHT+IE/+41NHq4D3WYPyGFbmzjc3BPqmdWUcQX1H+j1fZXG8U7rdKCVApoINHJ/woEFdcLI2dLNXsPKYuiRzsrbu8E=
X-Received: by 2002:a05:6870:648e:b0:21e:df8b:5280 with SMTP id
 cz14-20020a056870648e00b0021edf8b5280mr2217256oab.27.1710940847173; Wed, 20
 Mar 2024 06:20:47 -0700 (PDT)
MIME-Version: 1.0
References: <20240318163552.3808695-1-andrew.cooper3@citrix.com>
 <20240318163552.3808695-3-andrew.cooper3@citrix.com> 
 <19d9487e-67cf-4c1e-9dc6-419d9c5d0120@citrix.com> 
In-Reply-To: 
From: George Dunlap 
Date: Wed, 20 Mar 2024 13:20:36 +0000
Message-ID: 
Subject: Re: [PATCH 2/7] xen/credit2: Clean up trace handling
To: Jan Beulich 
Cc: Andrew Cooper , Xen-devel , 
	Dario Faggioli , George Dunlap , 
	Stefano Stabellini , Julien Grall , 
	Nicola Vetrini , 
	"consulting @ bugseng . com" 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Mar 20, 2024 at 1:13=E2=80=AFPM Jan Beulich  wro=
te:
>
> On 20.03.2024 13:19, Andrew Cooper wrote:
> > On 20/03/2024 12:16 pm, George Dunlap wrote:
> >> On Mon, Mar 18, 2024 at 4:36=E2=80=AFPM Andrew Cooper  wrote:
> >>> There is no need for bitfields anywhere - use more sensible types.  T=
here is
> >>> also no need to cast 'd' to (unsigned char *) before passing it to a =
function
> >>> taking void *.  Switch to new trace_time() API.
> >>>
> >>> No functional change.
> >> Hey Andrew -- overall changes look great, thanks for doing this very
> >> detailed work.
> >>
> >> One issue here is that you've changed a number of signed values to
> >> unsigned values; for example:
> >>
> >>> @@ -1563,16 +1559,16 @@ static s_time_t tickle_score(const struct sch=
eduler *ops, s_time_t now,
> >>>      if ( unlikely(tb_init_done) )
> >>>      {
> >>>          struct {
> >>> -            unsigned unit:16, dom:16;
> >>> -            int credit, score;
> >>> -        } d;
> >>> -        d.dom =3D cur->unit->domain->domain_id;
> >>> -        d.unit =3D cur->unit->unit_id;
> >>> -        d.credit =3D cur->credit;
> >>> -        d.score =3D score;
> >>> -        __trace_var(TRC_CSCHED2_TICKLE_CHECK, 1,
> >>> -                    sizeof(d),
> >>> -                    (unsigned char *)&d);
> >>> +            uint16_t unit, dom;
> >>> +            uint32_t credit, score;
> >> ...here you change `int` to `unit32_t`; but `credit` and `score` are
> >> both signed values, which may be negative.  There are a number of
> >> other similar instances.  In general, if there's a signed value, it
> >> was meant.
> >
> > Oh - this is a consequence of being reviewed that way in earlier iterat=
ions.
>
> Which in turn is a result of us still having way to many uses of plain
> int when signed quantities aren't meant. Plus my suggestion to make
> this explicit by saying "signed int" was rejected.

Not complaining, but just pointing out to maybe save some time in the
future:  The vast majority of fields in the trace records in this file
are unsigned; in fact, two of the fields in this structure are
unsigned.  That should have been a hint that being signed was likely
to be intentional in this code, and to look at the context before
removing it.  (In this case, for example just above here there's an
"if ( score < 0 )" showing that score might be negative.)

 -George


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 13:45:22 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 13:45:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695918.1086220 (Exim 4.92)
	(envelope-from )
	id 1rmwFo-0005pK-JN; Wed, 20 Mar 2024 13:45:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695918.1086220; Wed, 20 Mar 2024 13:45:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmwFo-0005pD-Gc; Wed, 20 Mar 2024 13:45:16 +0000
Received: by outflank-mailman (input) for mailman id 695918;
 Wed, 20 Mar 2024 13:45:14 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmwFm-0005p6-TY
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 13:45:14 +0000
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com
 [2a00:1450:4864:20::635])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 134936ef-e6c0-11ee-a1ee-f123f15fe8a2;
 Wed, 20 Mar 2024 14:45:12 +0100 (CET)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-a45f257b81fso884596566b.0
 for ; Wed, 20 Mar 2024 06:45:12 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 k23-20020a1709063e1700b00a4661caeed7sm7300279eji.48.2024.03.20.06.45.11
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 20 Mar 2024 06:45:12 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 134936ef-e6c0-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710942312; x=1711547112; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=MJHwRbdqumhmMAU912wFafkBvn6i8kLPZastUG278yc=;
        b=dqfhnpVx+HjTpxcNMKks2SDGuZWENAxVMmturoPL6+gNoTy+PrH0RwH8oeYh5d2qC3
         Ja4RsIqXSTNOmFYbBasvUION2O+P/cbUSlHfmBj4rfBqLsrRS9tR/Lcg4JEV4UZ0m87w
         5JqJA9GSUp9YRC86A4j26WM/sXtKuOUU14AIIVA5DKqHoxyYiLEHqqEB7Tbad05Of+Nt
         nJcDyhE5Od8n8KuIEn/uEnu0b5LJdKlIcUfoOFdf4LU5CFUjTi/aDNNZ/aP3Ie4vkb/U
         3NEQIWiYiCHv/IVj6GX+QslYQ1v6JzdKfbDXS4r/ZGoHCIdQ9DNdg490qJ4GGEahK6Sz
         egkA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710942312; x=1711547112;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=MJHwRbdqumhmMAU912wFafkBvn6i8kLPZastUG278yc=;
        b=qyT1pQpDWsiIO7yTHy2gC8Y0pazEt1pHnMidAT5fNrZxKIejV9LBCfTo/tZxWgdQHP
         83gOBmvqVk2XIs7+HWfG7ektSaGzANe9aEbnGIPilsG4nJba43AXN9DjKnoKZjwuNFKn
         YAkN7BA0j5yCerUgVPJukoNqEtsQQS/VSNtXltPM/bZMHipZ7kE9Ovf2JJjOHwMRcb/a
         eiugImec3XYYCo1ULCekk/RL8puDIKNvwrfPxwcDRJCj9wQ0TF5i4JWciEUCgv1/+vM8
         jsXSHUNL+6zPlu6SYV38W0MVK7mIrvGtPKTjX0H0R1UiUQV9G4+9+N6vFbTvdrctUE7r
         0hRg==
X-Forwarded-Encrypted: i=1; AJvYcCUFoXJXTPhWpYs7wzJ+QTZbHiDGjCIz1cge10gG5I/1/hzKCbxCZUVuqNAl4YpesPETlGyS3mf3tBFQGNo2JwunEolUBulhgz9oi63apk4=
X-Gm-Message-State: AOJu0YxC6VIJmzprOTFmCNdWY0Il5gyjiehFrAJW5XpefTSnhKxnSDLM
	Vw2ksn60M9AlIOuqKNe3bED5O1jv+uCmQr23sQiyRkgGA9pgLMzwBHTWZT6Emg==
X-Google-Smtp-Source: AGHT+IGDlr2Kz8YrdZBAUi3YzMckE2ASVw0i2DruNNgjHjRo8gnKtfbQ+kc6lCxjjlP0Ciz9hdJMQw==
X-Received: by 2002:a17:906:468f:b0:a46:d591:873c with SMTP id a15-20020a170906468f00b00a46d591873cmr1354441ejr.18.1710942312231;
        Wed, 20 Mar 2024 06:45:12 -0700 (PDT)
Message-ID: 
Date: Wed, 20 Mar 2024 14:45:11 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 5/7] xen: Switch to new TRACE() API
Content-Language: en-US
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 George Dunlap ,
 Stefano Stabellini , Julien Grall ,
 Nicola Vetrini ,
 "consulting @ bugseng . com" ,
 Xen-devel 
References: <20240318163552.3808695-1-andrew.cooper3@citrix.com>
 <20240318163552.3808695-6-andrew.cooper3@citrix.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240318163552.3808695-6-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 18.03.2024 17:35, Andrew Cooper wrote:
> @@ -736,9 +736,19 @@ static void vlapic_update_timer(struct vlapic *vlapic, uint32_t lvtt,
>              delta = delta * vlapic->hw.timer_divisor / old_divisor;
>          }
>  
> -        TRACE_2_LONG_3D(TRC_HVM_EMUL_LAPIC_START_TIMER, TRC_PAR_LONG(delta),
> -                        TRC_PAR_LONG(is_periodic ? period : 0),
> -                        vlapic->pt.irq);
> +        if ( unlikely(tb_init_done) )
> +        {
> +            struct {
> +                uint64_t delta, period;
> +                uint32_t irq;
> +            } __packed d = {
> +                .delta = delta,
> +                .period = is_periodic ? period : 0,
> +                .irq = vlapic->pt.irq,
> +            };
> +
> +            trace_time(TRC_HVM_EMUL_LAPIC_START_TIMER, sizeof(d), &d);
> +        }

Instead of this open-coding, how about

        if ( is_periodic )
            TRACE_TIME(TRC_HVM_EMUL_LAPIC_START_TIMER, delta, delta >> 32,
                       period, period >> 32, vlapic->pt.irq);
        else
            TRACE_TIME(TRC_HVM_EMUL_LAPIC_START_TIMER, delta, delta >> 32,
                       0, 0, vlapic->pt.irq);

thus improving similarity / grep-ability with ...

> @@ -1208,8 +1218,8 @@ void vlapic_tdt_msr_set(struct vlapic *vlapic, uint64_t value)
>  
>          vlapic->hw.tdt_msr = value;
>          /* .... reprogram tdt timer */
> -        TRACE_2_LONG_3D(TRC_HVM_EMUL_LAPIC_START_TIMER, TRC_PAR_LONG(delta),
> -                        TRC_PAR_LONG(0LL), vlapic->pt.irq);
> +        TRACE_TIME(TRC_HVM_EMUL_LAPIC_START_TIMER, delta, delta >> 32,
> +                   0, 0, vlapic->pt.irq);
>          create_periodic_time(v, &vlapic->pt, delta, 0,
>                               vlapic->pt.irq, vlapic_tdt_pt_cb,
>                               &vlapic->timer_last_update, false);
> @@ -1222,8 +1232,8 @@ void vlapic_tdt_msr_set(struct vlapic *vlapic, uint64_t value)
>          /* trigger a timer event if needed */
>          if ( value > 0 )
>          {
> -            TRACE_2_LONG_3D(TRC_HVM_EMUL_LAPIC_START_TIMER, TRC_PAR_LONG(0LL),
> -                            TRC_PAR_LONG(0LL), vlapic->pt.irq);
> +            TRACE_TIME(TRC_HVM_EMUL_LAPIC_START_TIMER, 0, 0,
> +                       0, 0, vlapic->pt.irq);
>              create_periodic_time(v, &vlapic->pt, 0, 0,
>                                   vlapic->pt.irq, vlapic_tdt_pt_cb,
>                                   &vlapic->timer_last_update, false);

... these.

> @@ -1476,8 +1486,19 @@ static void lapic_rearm(struct vlapic *s)
>                (uint32_t)tmict * s->hw.timer_divisor);
>      is_periodic = vlapic_lvtt_period(s);
>  
> -    TRACE_2_LONG_3D(TRC_HVM_EMUL_LAPIC_START_TIMER, TRC_PAR_LONG(period),
> -             TRC_PAR_LONG(is_periodic ? period : 0LL), s->pt.irq);
> +    if ( unlikely(tb_init_done) )
> +    {
> +         struct {
> +             uint64_t delta, period;
> +             uint32_t irq;
> +        } __packed d = {
> +             .delta = period,
> +             .period = is_periodic ? period : 0,
> +             .irq = s->pt.irq,
> +        };
> +
> +        trace_time(TRC_HVM_EMUL_LAPIC_START_TIMER, sizeof(d), &d);
> +    }

Same here then.

Other than that you had an ack from me for this already, which you may
very well retain / reinstate.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 13:52:24 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 13:52:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695922.1086231 (Exim 4.92)
	(envelope-from )
	id 1rmwMW-00081J-Cd; Wed, 20 Mar 2024 13:52:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695922.1086231; Wed, 20 Mar 2024 13:52:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmwMW-00081C-9Q; Wed, 20 Mar 2024 13:52:12 +0000
Received: by outflank-mailman (input) for mailman id 695922;
 Wed, 20 Mar 2024 13:52:11 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmwMV-0007zI-Rk
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 13:52:11 +0000
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com
 [2a00:1450:4864:20::52e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0bc71c52-e6c1-11ee-afdd-a90da7624cb6;
 Wed, 20 Mar 2024 14:52:10 +0100 (CET)
Received: by mail-ed1-x52e.google.com with SMTP id
 4fb4d7f45d1cf-5684db9147dso8706130a12.2
 for ; Wed, 20 Mar 2024 06:52:10 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 g18-20020a056402091200b00568b6f73491sm5557660edz.14.2024.03.20.06.52.08
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 20 Mar 2024 06:52:09 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0bc71c52-e6c1-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710942729; x=1711547529; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=II4y1E8zMQL5MTcZbckP76UZN6K9hkpvDxtIt/wDvpQ=;
        b=FdhwOykEaZosWE1cPhMmp4sZzu88/LoRI4KXJ4FhwIZ4Jfhmvw9orslIef2+Aa5p6d
         oezP040mqMRq/KKs43qfahwlsPy20H+4bewial2pq3Tt90Hr4HAkh1/dq2fbwDnVE1zp
         zj3ZheUF8NUQ/VEz8hT7+RyNOheBNrhS0LfZ/0/NJsx3c73OZFji49ZNuZjAp9L33yYj
         geBJ0LHLux/7ulQrR3GlBlPBsR3ZC6VioYxH+jS22j4WhBqCHBuQ49pYt80pA6+M8eqE
         n+NbNXQ/AG8vLxU6MCwALQHGtJCj/fZPrTBN/9ZhiEJZOjLaEXfKu0yWMIrMinBBWul3
         oULQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710942729; x=1711547529;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=II4y1E8zMQL5MTcZbckP76UZN6K9hkpvDxtIt/wDvpQ=;
        b=aQoRjRYX+5kN7h0G+FUzNDqoO6vlYQU6xfhyKNwVrT1yPC44wL/JHQT7xaTai92PK8
         V4tj7EAkSmRTAbWMTUMJ2ZX3LQxoMD33kgcxJL6xsb+Nv9XPN47R7ubWd6T+qKcFE2ZH
         iZi6Ik704zcPXG+3cwbhrfjJtcg07LvEzMmw1c4Jfkp60x+UMENBFWdREy4xeQ9fZ3Ax
         8EJbVaB2Vc2HlTvZFnBx2Nd7mCeEl7wKGKvpXnRnAodqcGhmcQAqTtV3zdUjzJp+VTZy
         +fdUqfQ7zHSJPQzT11aqNn2SLrjEMm5xY/scOF2U9ulOKempkkQEmPr6H6ZpjWy6DIz5
         f4eQ==
X-Forwarded-Encrypted: i=1; AJvYcCUPV7lFdx648zrwZzhJ/lRv+/7Vuoz38Gh7E2BGthCbgQbxLWRxFSQ2Cy52nyK5CF/M4fn16y+SFvzB+n30SUsFRHBqdKmbzuUqmnOWAL8=
X-Gm-Message-State: AOJu0Yyy4xo4BlpSVOVrTMxXLKfK1QeJvWQNrH0RldvMGV+MscYQoBcn
	io+5xCl+VtelunRPt6izgndWnDtZ8ik8/ym9IWCJ5qpeolhLH0sgKlmoxQvVLw==
X-Google-Smtp-Source: AGHT+IHSRRC09PlTdnLIJN9/ryDHQ2hyjK3k0+9BJMDreXQMBumLI2YfjRWSAdvFfcuA8IzFKMRKUg==
X-Received: by 2002:a05:6402:2b93:b0:568:a18:2eb3 with SMTP id fj19-20020a0564022b9300b005680a182eb3mr14129340edb.11.1710942729224;
        Wed, 20 Mar 2024 06:52:09 -0700 (PDT)
Message-ID: <961ffe23-a903-4da0-bc30-8918785101ef@suse.com>
Date: Wed, 20 Mar 2024 14:52:07 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 6/7] xen/trace: Update final {__,}trace_var() users to the
 new API
Content-Language: en-US
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 George Dunlap ,
 Stefano Stabellini , Julien Grall ,
 Nicola Vetrini ,
 "consulting @ bugseng . com" ,
 Xen-devel 
References: <20240318163552.3808695-1-andrew.cooper3@citrix.com>
 <20240318163552.3808695-7-andrew.cooper3@citrix.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240318163552.3808695-7-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 18.03.2024 17:35, Andrew Cooper wrote:
> This logically drops the cycles parameter, as it's now encoded directly in the
> event code.

That encoding is an internal detail of the new API; for the purposes of the
callers the pattern looks to be that ...

> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -67,7 +67,7 @@ static void hvmtrace_io_assist(const ioreq_t *p)
>          size *= 2;
>      }
>  
> -    trace_var(event, 0/*!cycles*/, size, buffer);
> +    trace(event, size, buffer);

... the respective parameter being 0 translates to trace(), while ...

> --- a/xen/arch/x86/irq.c
> +++ b/xen/arch/x86/irq.c
> @@ -135,7 +135,7 @@ static void _trace_irq_mask(uint32_t event, int irq, int vector,
>  
>      memcpy(d.mask, mask,
>             min(sizeof(d.mask), BITS_TO_LONGS(nr_cpu_ids) * sizeof(long)));
> -    trace_var(event, 1, sizeof(d), &d);
> +    trace_time(event, sizeof(d), &d);

... the parameter being 1 translates to trace_time(). Imo the description
would better express it that way. Irrespective, assuming that pattern is
what is meant to hold,
Reviewed-by: Jan Beulich 

Jan


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 13:54:53 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 13:54:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695924.1086242 (Exim 4.92)
	(envelope-from )
	id 1rmwP6-00008e-Ro; Wed, 20 Mar 2024 13:54:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695924.1086242; Wed, 20 Mar 2024 13:54:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmwP6-00008X-NF; Wed, 20 Mar 2024 13:54:52 +0000
Received: by outflank-mailman (input) for mailman id 695924;
 Wed, 20 Mar 2024 13:54:51 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmwP5-00008Q-Ns
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 13:54:51 +0000
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com
 [2a00:1450:4864:20::633])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6bd5d1cd-e6c1-11ee-afdd-a90da7624cb6;
 Wed, 20 Mar 2024 14:54:50 +0100 (CET)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-a46d0a8399aso163661066b.1
 for ; Wed, 20 Mar 2024 06:54:50 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 xj4-20020a170906db0400b00a46aba003eesm4886584ejb.215.2024.03.20.06.54.49
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 20 Mar 2024 06:54:50 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6bd5d1cd-e6c1-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710942890; x=1711547690; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=Qm21WwCwGeW+W2XQIszmwXT848dJr4l2ZZCaVHgRCVo=;
        b=CtmU+Z5uEc+3iXOt+rFV7Ios8nadZx3AaPeVtes3c7jpynO73nIpBlmFaVScVMd9hX
         eTPEB5pNz2TmOw6tXs+g+r087vmcvOV+3isy4gb1HQBVnqxst1iTQVP0kyPt4/BYCK1H
         1v8jLIVNAOJMq1bZRvK3HO3puxXPd11y1n8HnygCvjv92Cunif32hBiQYT0DoL0exQIO
         hLDyR/oOi7TKTQTGDQlOCOHG+wRFNpKWrbXFr2WG3/rjF0pfAzlzJXE9VANP1G5Oe6pi
         FtdrVCTj2Bz9NcihzAYdVKazMb5/1RiJWcabgI/o96XzDZgpoQKcBmDRV476BHNHF+W3
         wv6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710942890; x=1711547690;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=Qm21WwCwGeW+W2XQIszmwXT848dJr4l2ZZCaVHgRCVo=;
        b=WM1znAKKl5+zpLNlWVGnkydkD69xL+4LI+R98mYbGbSFlrhGKdEesM6RuJhBendzQU
         DlxvMaa7ofU92S2ZBPkceb64unMBvl1UyX3s2apjv8EBtfPCZ/G21mjwG+x4VfSDgQ5e
         0ygjR5L8dtPaWTc1Yy9h4watqj8ei8eEKC360LX1FqohFzOvApS9/+ungDYucT5afYUo
         48Pp2Uz4Q2c5sqLAIIPHENOdTOQMEmVzRkvol/GnxHG5venSuuT34BWhkCZnYknecerL
         BIrcrDQ0E62P050XFx1z6+x+mQX47jyrJuHihI/zNXsMGi2othMWuXFUSTFPctPa0Pz+
         k4Ig==
X-Forwarded-Encrypted: i=1; AJvYcCUiKzJ7cqyMpcm+8ckkgO62z58KfjHQzm9HDgRqjBdh2YZsTce4Hfgmv5iq4rRGc876ohy9uiHYwf6++VkTPaF3P6A1lMQFqVnjrnhQYrg=
X-Gm-Message-State: AOJu0Yw20lB8cyxbwHYQreHbtDtZLpNpmxVHdbLS2z3kzzIs31bjS2KW
	NpcOQUawkviC9kXZ54JimN17JeDnX7uQ/lSI+BOrAcmCNov3E39lTLAo0Gbgag==
X-Google-Smtp-Source: AGHT+IG75MirnZzKoOTf8EhJ/2m8xB+4LrjHAxI+IekJhpZ+2OK+j/7AGaqNKkgI2v9/v5MIXTIIig==
X-Received: by 2002:a17:906:2317:b0:a46:d759:d531 with SMTP id l23-20020a170906231700b00a46d759d531mr2132941eja.34.1710942890356;
        Wed, 20 Mar 2024 06:54:50 -0700 (PDT)
Message-ID: <0ae49632-3e14-425b-9140-826264fae14f@suse.com>
Date: Wed, 20 Mar 2024 14:54:49 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 7/7] xen/trace: Drop old trace API
Content-Language: en-US
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 George Dunlap ,
 Stefano Stabellini , Julien Grall ,
 Nicola Vetrini ,
 "consulting @ bugseng . com" ,
 Xen-devel 
References: <20240318163552.3808695-1-andrew.cooper3@citrix.com>
 <20240318163552.3808695-8-andrew.cooper3@citrix.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240318163552.3808695-8-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 18.03.2024 17:35, Andrew Cooper wrote:
> With all users updated to the new API, drop the old API.  This includes all of
> asm/hvm/trace.h, which allows us to drop some includes.
> 
> Signed-off-by: Andrew Cooper 
> ---
> CC: Jan Beulich 
> CC: Roger Pau Monné 
> CC: George Dunlap 
> CC: Stefano Stabellini 
> CC: Julien Grall 
> CC: Nicola Vetrini 
> CC: consulting@bugseng.com 
> 
> v2.1:
>  * New
> v3:
>  * Extend to drop __trace_var() too

And still
Acked-by: Jan Beulich 
(with the never responded to remark in [1] still holding)

Jan

[1] https://lists.xen.org/archives/html/xen-devel/2021-09/msg02154.html


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 13:58:33 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 13:58:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695928.1086251 (Exim 4.92)
	(envelope-from )
	id 1rmwSY-0000jw-8f; Wed, 20 Mar 2024 13:58:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695928.1086251; Wed, 20 Mar 2024 13:58:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmwSY-0000jp-5p; Wed, 20 Mar 2024 13:58:26 +0000
Received: by outflank-mailman (input) for mailman id 695928;
 Wed, 20 Mar 2024 13:58:24 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmwSW-0000jj-L7
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 13:58:24 +0000
Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com
 [2607:f8b0:4864:20::832])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ea4538bd-e6c1-11ee-afdd-a90da7624cb6;
 Wed, 20 Mar 2024 14:58:23 +0100 (CET)
Received: by mail-qt1-x832.google.com with SMTP id
 d75a77b69052e-430c32c04c7so27459821cf.0
 for ; Wed, 20 Mar 2024 06:58:23 -0700 (PDT)
Received: from localhost ([85.31.135.62]) by smtp.gmail.com with ESMTPSA id
 ev15-20020a05622a510f00b00430ea220b32sm1976799qtb.71.2024.03.20.06.58.20
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 20 Mar 2024 06:58:21 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ea4538bd-e6c1-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710943101; x=1711547901; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:from:to:cc:subject:date:message-id:reply-to;
        bh=PdPBqG47aaueb+ZzuI4mZsQ5oY2pC9/88VWb9N+cIZI=;
        b=OydYDUzL8B21PIfKzoRCOkcPhIlvoW7ONHjECbTN/+Aw/blh5nfITaEZ7NuNU8NOit
         nSCRL5Cg4lKdIWrR8sD+Z5VJ4rMxvqfSYBrWcxpUKrSWxU818NkGRFJLibl6dNUPoD/P
         upBTN7PuuCAfQKcAXBvzp1oicRO431o1SiMzM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710943101; x=1711547901;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=PdPBqG47aaueb+ZzuI4mZsQ5oY2pC9/88VWb9N+cIZI=;
        b=J8NazTdn5mcxkkk33jsFh6v5zIjeOM42A7qkh3q/FCDICaQM1JWg0IhiWPfK2KwTdD
         C5hgDwXx+vVhXvNEvI9Zne9/5AWeIiAHk03+RhAcdxayNzonO2wqVT/cWbMBC/7h8HHq
         XHFvHB37IS6I89cJgum0k1i1gmqXork5fK2H+eJSSqISFBkGq26HGBn374lMGGAtG2UM
         7ln93viTjh9x/siEgGuK9FgON2z6VyZA6fFxXT4Okht0IhBIjbHy57PGCgBsKHhhwTR9
         AD1uUMWhBJgKmuh2oD/C6UWyv05Uo+bnPXuwwKoZI/3XeJez7L6TvvgIubTRsowb3q+M
         djOg==
X-Gm-Message-State: AOJu0Yy3cex1ymLYMWCm+Hk/p0tCjjLX7I8USKLtmvKW4SmBJn1q6tUY
	VKlpiFdk3xJwe2vHPSYm4R+glymSByWXQ3lk/iUfnKxBz7bSO1DJzBz6WoamPbuKxOnrW2/3gSL
	E
X-Google-Smtp-Source: AGHT+IFRaC/mtYKrPH2Y8fC7/zgDT7MdTedS42YUk2f+z3XdWqpj+faQ7c+ve0RBbBIBmRe08BPR9g==
X-Received: by 2002:ac8:58d2:0:b0:430:ce8c:9581 with SMTP id u18-20020ac858d2000000b00430ce8c9581mr10706164qta.22.1710943101377;
        Wed, 20 Mar 2024 06:58:21 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini ,
	Wei Liu 
Subject: [PATCH] x86/vcpu: relax VCPUOP_initialise restriction for non-PV vCPUs
Date: Wed, 20 Mar 2024 14:57:20 +0100
Message-ID: <20240320135720.68894-1-roger.pau@citrix.com>
X-Mailer: git-send-email 2.44.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

There's no reason to force HVM guests to have a valid vcpu_info area when
initializing a vCPU, as the vCPU can also be brought online using the local
APIC, and on that path there's no requirement for vcpu_info to be setup ahead
of the bring up.  Note an HVM vCPU can operate normally without making use of
vcpu_info.

Restrict the check against dummy_vcpu_info to only apply to PV guests.

Fixes: 192df6f9122d ('x86: allow HVM guests to use hypercalls to bring up vCPUs')
Signed-off-by: Roger Pau Monné 
---
 xen/common/compat/domain.c | 2 +-
 xen/common/domain.c        | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/common/compat/domain.c b/xen/common/compat/domain.c
index 7ff238cc2656..6b4afc823217 100644
--- a/xen/common/compat/domain.c
+++ b/xen/common/compat/domain.c
@@ -49,7 +49,7 @@ int compat_common_vcpu_op(int cmd, struct vcpu *v,
     {
     case VCPUOP_initialise:
     {
-        if ( v->vcpu_info_area.map == &dummy_vcpu_info )
+        if ( is_pv_domain(d) && v->vcpu_info_area.map == &dummy_vcpu_info )
             return -EINVAL;
 
 #ifdef CONFIG_HVM
diff --git a/xen/common/domain.c b/xen/common/domain.c
index f6f557499660..d956dc09eca0 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -1817,7 +1817,7 @@ long common_vcpu_op(int cmd, struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg)
     switch ( cmd )
     {
     case VCPUOP_initialise:
-        if ( v->vcpu_info_area.map == &dummy_vcpu_info )
+        if ( is_pv_domain(d) && v->vcpu_info_area.map == &dummy_vcpu_info )
             return -EINVAL;
 
         rc = arch_initialise_vcpu(v, arg);
-- 
2.44.0



From xen-devel-bounces@lists.xenproject.org Wed Mar 20 14:00:46 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 14:00:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695930.1086260 (Exim 4.92)
	(envelope-from )
	id 1rmwUm-0002vj-JX; Wed, 20 Mar 2024 14:00:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695930.1086260; Wed, 20 Mar 2024 14:00:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmwUm-0002vc-H3; Wed, 20 Mar 2024 14:00:44 +0000
Received: by outflank-mailman (input) for mailman id 695930;
 Wed, 20 Mar 2024 14:00:43 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmwUl-0002vW-0m
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 14:00:43 +0000
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com
 [2a00:1450:4864:20::533])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3c83ffb9-e6c2-11ee-a1ee-f123f15fe8a2;
 Wed, 20 Mar 2024 15:00:40 +0100 (CET)
Received: by mail-ed1-x533.google.com with SMTP id
 4fb4d7f45d1cf-5684db9147dso8720267a12.2
 for ; Wed, 20 Mar 2024 07:00:40 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 l24-20020aa7cad8000000b005697d77570dsm3546299edt.66.2024.03.20.07.00.39
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 20 Mar 2024 07:00:40 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3c83ffb9-e6c2-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710943240; x=1711548040; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=7WfiZPg0fiMsbRlSXl6V4uqaiczIERho6c3psa+Xwvk=;
        b=bsdQryda8KsbgAX9XBERwLVb7p2tB/syBwEPW7r07GiqXXOWLELTAjQRAarbnALCRY
         k84U4XAOcGDm9PLdKP4zl4C9/DIKBAg/c1OsSds9XLEefKLti3PpKQo3sf1dojBIvD77
         +44JViGSYIZzaAUP1vr1WFCZb9wSGmtZjiws5argxhH62Fagnu+iqlAUFrNjM3aAdU8B
         hY37s/kqyTUk0FzPwiHoBCmf02FJq4N6gVP54xYnboFwpDR/AJTb7ABz8w05rEZ12YSP
         4Vn6n7dv3nSxV1pIw2X9TilHHEszB0Y7zEhM8eKuGbl9w3fxY+nV0WOdDyqghMh8oCYo
         ePcg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710943240; x=1711548040;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=7WfiZPg0fiMsbRlSXl6V4uqaiczIERho6c3psa+Xwvk=;
        b=hnp/ZRo9Yfpb+71iEEmvXTx7AD3hbS1N2EI6CRQKxnVjLHdm4wO7dUIDlhd6QxKtwO
         a6t8txjmGPmmf+AvXxj3w8DpZjTuF1TUpoiXUlyJSBP1veXq09uTTtzgLJOyEPkGkJBb
         YMWOXZMd0G9mYLp6zNOgZxfDgARrCZu5L7j/x0+9D4Bmh6jrPuHpGsfJAHXkU1qSQ3xM
         GGxBlJ9I1exNxhJaVAqFcJBaFDLGGnAnGcd3disJHWW5HnDQRGHCdVpUoU+B0dyrMibB
         jYr5bIt3ROSR5UnY+UtaZGjg9S7gxR+HCZ0epBejqYehqhZVO7+c+/ZatRxSsdn1dW/S
         IgHA==
X-Forwarded-Encrypted: i=1; AJvYcCUx3GIP7kLoCsuOFCwAy3rWS7+KvZSzfvKExM3ygR/5RNN2NpIp9fxTCXNATztR9svtsHxugz/aGOf+y8xXkJLlXZdfVkSDHBJvOyfzZoY=
X-Gm-Message-State: AOJu0YznQK+ftFXkoxOco+TeD+/MOm3rJ0s3kIXHzumRmf2g6hGj4q10
	DLrbtGoIhwYG4vIBQlXSlHqlOB+ZH7QaDtCucEZSqNFKZs7GPhfrUy4m4rMgWA==
X-Google-Smtp-Source: AGHT+IE5BbuaofE+vNMhzJlaLRkaRxbjmAL9+iQGAbLAhngBCrZ5fpK140/Y/0brJPrDOgqL51yhWg==
X-Received: by 2002:a05:6402:c50:b0:568:7c01:a4a2 with SMTP id cs16-20020a0564020c5000b005687c01a4a2mr14069314edb.13.1710943240321;
        Wed, 20 Mar 2024 07:00:40 -0700 (PDT)
Message-ID: <7f3a075c-1e0e-4a3c-a1f6-08d057914d9f@suse.com>
Date: Wed, 20 Mar 2024 15:00:39 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 2/3] libelf: Expand ELF note printing
Content-Language: en-US
To: Jason Andryuk 
Cc: Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 xen-devel@lists.xenproject.org
References: <20240319205849.115884-1-jason.andryuk@amd.com>
 <20240319205849.115884-3-jason.andryuk@amd.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240319205849.115884-3-jason.andryuk@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 19.03.2024 21:58, Jason Andryuk wrote:
> --- a/xen/common/libelf/libelf-dominfo.c
> +++ b/xen/common/libelf/libelf-dominfo.c
> @@ -101,26 +101,30 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
>  /* *INDENT-OFF* */
>      static const struct {
>          const char *name;
> -        bool str;
> +        enum {
> +            ELFNOTE_INT,
> +            ELFNOTE_STRING,
> +            ELFNOTE_NAME,

This last on could do with a comment, as there are two possible (but
distinct) purposes: Notes where the mere presence matters vs ones where
printing of the value(s) would simply be cumbersome.

> +        } type;
>      } note_desc[] = {
> -        [XEN_ELFNOTE_ENTRY] = { "ENTRY", 0},
> -        [XEN_ELFNOTE_HYPERCALL_PAGE] = { "HYPERCALL_PAGE", 0},
> -        [XEN_ELFNOTE_VIRT_BASE] = { "VIRT_BASE", 0},
> -        [XEN_ELFNOTE_INIT_P2M] = { "INIT_P2M", 0},
> -        [XEN_ELFNOTE_PADDR_OFFSET] = { "PADDR_OFFSET", 0},
> -        [XEN_ELFNOTE_HV_START_LOW] = { "HV_START_LOW", 0},
> -        [XEN_ELFNOTE_XEN_VERSION] = { "XEN_VERSION", 1},
> -        [XEN_ELFNOTE_GUEST_OS] = { "GUEST_OS", 1},
> -        [XEN_ELFNOTE_GUEST_VERSION] = { "GUEST_VERSION", 1},
> -        [XEN_ELFNOTE_LOADER] = { "LOADER", 1},
> -        [XEN_ELFNOTE_PAE_MODE] = { "PAE_MODE", 1},
> -        [XEN_ELFNOTE_FEATURES] = { "FEATURES", 1},
> -        [XEN_ELFNOTE_SUPPORTED_FEATURES] = { "SUPPORTED_FEATURES", 0},
> -        [XEN_ELFNOTE_BSD_SYMTAB] = { "BSD_SYMTAB", 1},
> -        [XEN_ELFNOTE_L1_MFN_VALID] = { "L1_MFN_VALID", false },
> -        [XEN_ELFNOTE_SUSPEND_CANCEL] = { "SUSPEND_CANCEL", 0 },
> -        [XEN_ELFNOTE_MOD_START_PFN] = { "MOD_START_PFN", 0 },
> -        [XEN_ELFNOTE_PHYS32_ENTRY] = { "PHYS32_ENTRY", 0 },
> +        [XEN_ELFNOTE_ENTRY] = { "ENTRY", ELFNOTE_INT },
> +        [XEN_ELFNOTE_HYPERCALL_PAGE] = { "HYPERCALL_PAGE", ELFNOTE_INT },
> +        [XEN_ELFNOTE_VIRT_BASE] = { "VIRT_BASE", ELFNOTE_INT },
> +        [XEN_ELFNOTE_INIT_P2M] = { "INIT_P2M", ELFNOTE_INT },
> +        [XEN_ELFNOTE_PADDR_OFFSET] = { "PADDR_OFFSET", ELFNOTE_INT },
> +        [XEN_ELFNOTE_HV_START_LOW] = { "HV_START_LOW", ELFNOTE_INT },
> +        [XEN_ELFNOTE_XEN_VERSION] = { "XEN_VERSION", ELFNOTE_STRING },
> +        [XEN_ELFNOTE_GUEST_OS] = { "GUEST_OS", ELFNOTE_STRING },
> +        [XEN_ELFNOTE_GUEST_VERSION] = { "GUEST_VERSION", ELFNOTE_STRING },
> +        [XEN_ELFNOTE_LOADER] = { "LOADER", ELFNOTE_STRING },
> +        [XEN_ELFNOTE_PAE_MODE] = { "PAE_MODE", ELFNOTE_STRING },
> +        [XEN_ELFNOTE_FEATURES] = { "FEATURES", ELFNOTE_STRING },
> +        [XEN_ELFNOTE_SUPPORTED_FEATURES] = { "SUPPORTED_FEATURES", ELFNOTE_INT },
> +        [XEN_ELFNOTE_BSD_SYMTAB] = { "BSD_SYMTAB", ELFNOTE_STRING },
> +        [XEN_ELFNOTE_L1_MFN_VALID] = { "L1_MFN_VALID", ELFNOTE_NAME },
> +        [XEN_ELFNOTE_SUSPEND_CANCEL] = { "SUSPEND_CANCEL", ELFNOTE_INT },
> +        [XEN_ELFNOTE_MOD_START_PFN] = { "MOD_START_PFN", ELFNOTE_INT },
> +        [XEN_ELFNOTE_PHYS32_ENTRY] = { "PHYS32_ENTRY", ELFNOTE_INT },
>      };
>  /* *INDENT-ON* */
>  
> @@ -136,7 +140,7 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
>          return 0;
>      }
>  
> -    if ( note_desc[type].str )
> +    if ( note_desc[type].type == ELFNOTE_STRING )
>      {
>          str = elf_strval(elf, elf_note_desc(elf, note));
>          if (str == NULL)
> @@ -146,13 +150,17 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
>          parms->elf_notes[type].type = XEN_ENT_STR;
>          parms->elf_notes[type].data.str = str;
>      }
> -    else
> +    else if ( note_desc[type].type == ELFNOTE_INT )
>      {
>          val = elf_note_numeric(elf, note);
>          elf_msg(elf, "ELF: note: %s = %#" PRIx64 "\n", note_desc[type].name, val);
>          parms->elf_notes[type].type = XEN_ENT_LONG;
>          parms->elf_notes[type].data.num = val;
>      }
> +    else if ( note_desc[type].type == ELFNOTE_NAME )
> +    {
> +        elf_msg(elf, "ELF: note: %s\n", note_desc[type].name);
> +    }

Imo this would better be expressed as (default-less) switch() now. That
would also save me from commenting on the excess braces in the last
"else if". I guess I wouldn't mind making both adjustments while
committing, so long as you agree. With them in place
Reviewed-by: Jan Beulich 

Jan


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 14:05:45 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 14:05:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695933.1086271 (Exim 4.92)
	(envelope-from )
	id 1rmwZa-0003ZY-8x; Wed, 20 Mar 2024 14:05:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695933.1086271; Wed, 20 Mar 2024 14:05:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmwZa-0003ZR-5h; Wed, 20 Mar 2024 14:05:42 +0000
Received: by outflank-mailman (input) for mailman id 695933;
 Wed, 20 Mar 2024 14:05:41 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmwZZ-0003ZH-Jr; Wed, 20 Mar 2024 14:05:41 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmwZZ-000844-DA; Wed, 20 Mar 2024 14:05:41 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmwZZ-0003Vl-2S; Wed, 20 Mar 2024 14:05:41 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rmwZZ-0002WM-21; Wed, 20 Mar 2024 14:05:41 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=fpFcqWLkFXi7o781ubV2F41tjFLgnHrOYE5ZzG5QFkI=; b=xH3covpSEIpwzaImiNG3zQ+qg1
	60lXDLV7f5lcbnSjaqg6+6zEUtoj/k8Z3ENQMKxf9xtTv01xa+aVuYKQpDd4h9f1rxJWA0sofnXiL
	jjHmrDq/tqKJVurOvzYAX1GyBAHlGxfVItNeAsLYle3TRAcT5OYG6MxUVN7eweKdP8BA=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 185101: tolerable FAIL - PUSHED
X-Osstest-Failures:
    linux-linus:test-armhf-armhf-examine:reboot:fail:heisenbug
    linux-linus:test-armhf-armhf-xl:xen-boot:fail:heisenbug
    linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    linux=78c3925c048c752334873f56c3a3d1c9d53e0416
X-Osstest-Versions-That:
    linux=f6cef5f8c37f58a3bc95b3754c3ae98e086631ca
From: osstest service owner 
Date: Wed, 20 Mar 2024 14:05:41 +0000

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-examine      8 reboot              fail pass in 185112-retest
 test-armhf-armhf-xl           8 xen-boot            fail pass in 185112-retest

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl         15 migrate-support-check fail in 185112 never pass
 test-armhf-armhf-xl     16 saverestore-support-check fail in 185112 never pass
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop            fail like 185075
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop            fail like 185075
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop            fail like 185075
 test-armhf-armhf-libvirt     16 saverestore-support-check    fail  like 185075
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop            fail like 185075
 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check   fail like 185075
 test-armhf-armhf-libvirt-raw 15 saverestore-support-check    fail  like 185075
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 185075
 test-amd64-amd64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 15 migrate-support-check        fail  never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit1  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  16 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qcow2 14 migrate-support-check        fail never pass
 test-amd64-amd64-libvirt-raw 14 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-raw 14 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-raw 15 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt     15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-vhd      14 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-vhd      15 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     16 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     15 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-qcow2 14 migrate-support-check        fail never pass
 test-armhf-armhf-libvirt-raw 14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      15 saverestore-support-check    fail   never pass

version targeted for testing:
 linux                78c3925c048c752334873f56c3a3d1c9d53e0416
baseline version:
 linux                f6cef5f8c37f58a3bc95b3754c3ae98e086631ca

Last test of basis   185075  2024-03-18 07:48:04 Z    2 days
Failing since        185088  2024-03-19 01:43:30 Z    1 days    2 attempts
Testing same since   185101  2024-03-19 22:19:19 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  "Ricardo B. Marliere" 
  Alexander Aring 
  Alexander Gordeev 
  Alexey Dobriyan 
  Alexey Kodanev 
  Alison Schofield 
  Amir Goldstein 
  Andre Przywara 
  Andrew Melnychenko 
  Andy Shevchenko 
  Arnd Bergmann 
  Bartosz Golaszewski 
  Beau Belgrave 
  Borislav Petkov (AMD) 
  Changhuang Liang 
  Chao Yu 
  Chen Wang 
  Chengchang Tang 
  Chris Packham 
  Christian Borntraeger 
  Christian Brauner 
  Christian Heusel 
  Christophe JAILLET 
  Chuck Lever 
  Conor Dooley 
  Conrad Kostecki 
  Cristian Ciocaltea 
  Daeho Jeong 
  Dan Williams 
  Daniel Golle 
  Daniel Lezcano 
  David Hildenbrand 
  David Howells 
  David Teigland 
  Demi Marie Obenour 
  Dragos Tatulea 
  Duy Nguyen 
  Emil Renner Berthing 
  Erick Archer 
  Eugenio Pérez 
  Fabio Estevam 
  Feng Song 
  Florian Fainelli 
  Frank Wunderlich 
  Geert Uytterhoeven 
  Gerald Schaefer 
  Guoqing Jiang 
  Gustavo A. R. Silva 
  Halil Pasic 
  Harald Freudenberger 
  Heiko Carstens 
  Heinrich Schuchardt 
  Huang Yiwei 
  HuangXiaojia 
  Ian Murphy 
  Jack Wang 
  Jaegeuk Kim 
  Jan Höppner 
  Jason Gunthorpe 
  Jason Wang 
  Jeff Layton 
  Jeffrey Hugo 
  Jernej Skrabec 
  Ji Sheng Teoh 
  Jichi Zhang 
  Joel Granados 
  John Garry 
  Jonah Palmer 
  Juergen Gross 
  Junxian Huang 
  Kees Cook 
  Konrad Dybcio 
  Konstantin Taranov 
  Krzysztof Kozlowski 
  Lei Yang 
  Leon Romanovsky 
  Ley Foon Tan 
  Li Zhijian 
  linke li 
  Linus Torvalds 
  Linus Walleij 
  Luis Chamberlain 
  Lukasz Luba 
  Luoyouming 
  Maksim Kiselev 
  Manjunath Patil 
  Marek Szyprowski 
  Mark Brown 
  Martin Botka 
  Masami Hiramatsu (Google) 
  Maxime Coquelin 
  Mete Durlu 
  Michael S. Tsirkin 
  Mike Marshall 
  Mustafa Ismail 
  Niklas Cassel 
  Paolo Abeni 
  Peng Fan 
  Philipp Zabel 
  Rafael J. Wysocki 
  Rafał Miłecki 
  Randy Dunlap 
  Ricardo B. Marliere 
  Rob Herring 
  Rodrigo Vivi 
  Roger Pau Monne 
  Roger Pau Monné 
  Samuel Holland 
  Saravana Kannan 
  Sascha Hauer 
  Shannon Nelson 
  Sheng Yong 
  Shifeng Li 
  Shiraz Saleem 
  Shravan Chippa 
  Sibi Sankar 
  Sindhu Devale 
  Stephen Boyd 
  Steve Sistare 
  Steven Rostedt (Google) 
  Steven Rostedt 
  Sunmin Jeong 
  Suzuki K Poulose 
  Sven Schnelle 
  Takashi Iwai 
  Takashi Sakamoto 
  Thomas Gleixner 
  Thomas Weißschuh 
  Thorsten Blum 
  Tony Lindgren 
  Uwe Kleine-König 
  Vasily Khoruzhick 
  Vincent Donnefort 
  Vineeth Vijayan 
  Viresh Kumar 
  Vlastimil Babka 
  wenglianfa 
  Wenjie Qi 
  William Kucharski 
  William Qiu 
  Wu Bo 
  Xiuhong Wang 
  Xuan Zhuo 
  Yang Li 
  Yi Zhang 
  Yonatan Nachum 
  Yongpeng Yang 
  Yunsheng Lin 
  Zhiguo Niu 
  Zhu Lingshan 
  Zhu Yanjun 

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-freebsd11-amd64                             pass    
 test-amd64-amd64-freebsd12-amd64                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     fail    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-libvirt-qcow2                               pass    
 test-armhf-armhf-libvirt-qcow2                               pass    
 test-amd64-amd64-libvirt-raw                                 pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-amd64-xl-vhd                                      pass    
 test-arm64-arm64-xl-vhd                                      pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

Explanation of these 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 :

hint: The 'hooks/update' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
hint: The 'hooks/post-receive' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
hint: The 'hooks/post-update' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
To xenbits.xen.org:/home/xen/git/linux-pvops.git
   f6cef5f8c37f..78c3925c048c  78c3925c048c752334873f56c3a3d1c9d53e0416 -> tested/linux-linus


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 14:06:30 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 14:06:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695938.1086281 (Exim 4.92)
	(envelope-from )
	id 1rmwaM-00042g-H4; Wed, 20 Mar 2024 14:06:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695938.1086281; Wed, 20 Mar 2024 14:06:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmwaM-00042X-EA; Wed, 20 Mar 2024 14:06:30 +0000
Received: by outflank-mailman (input) for mailman id 695938;
 Wed, 20 Mar 2024 14:06:28 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmwaK-00042D-UR
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 14:06:28 +0000
Received: from mail-qv1-xf31.google.com (mail-qv1-xf31.google.com
 [2607:f8b0:4864:20::f31])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0972849e-e6c3-11ee-a1ee-f123f15fe8a2;
 Wed, 20 Mar 2024 15:06:25 +0100 (CET)
Received: by mail-qv1-xf31.google.com with SMTP id
 6a1803df08f44-6918781a913so32374326d6.3
 for ; Wed, 20 Mar 2024 07:06:25 -0700 (PDT)
Received: from localhost ([85.31.135.62]) by smtp.gmail.com with ESMTPSA id
 r9-20020a056214124900b00690bee954fasm7837027qvv.98.2024.03.20.07.06.23
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 20 Mar 2024 07:06:23 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0972849e-e6c3-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710943584; x=1711548384; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=U+QDRk+amPbBKzZEemO6HkI/eqkqSQhCB2bFOtRbCSI=;
        b=CwMXKzd3A7vk7e70z1tTAd9/0NSHCGm1gSHCNJQU2f+eziKSu2G57nceXlaNC8XNzn
         C5n6Of9LQXMW9ZAbqPCRILBHoYIVa2edQv1e3Hc54oBfhro18TH6iG1ZKzelZhLLvXHG
         wSPbKNUX39/RBU/8TmbbIGQ8+lZvbPrSbCFEk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710943584; x=1711548384;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=U+QDRk+amPbBKzZEemO6HkI/eqkqSQhCB2bFOtRbCSI=;
        b=Ia3YkepD3pluj357SCU9UcBsbZHa+ynI7rzvkx1vkxi4JFB/QgbHnbNlvM8NKumVa3
         R3a1+pRtT1+Ap6BJWL0+JZ8NuanKCle60dTXXDHU/2Gv1FjEMl4UnMo+q/vIrwqWaB8U
         n5HhD9dUa7JTj4Hu6vk5wfydRVBsmeE4Mc4CNigZydpH04tXZNfubeKMZVwZOGkhD9hT
         viWL0cdOIhY4+XNXfL/Aiq62mni5zvlqbSdpNaf1wCo+4UkFP5KtIrogGzMV0ugQXZf8
         QmIhig5cRppgu0ep1DNG2hxGQAqIkCluB7mou6RNGKSdlzg+Kt0+m+AdDxAiynaznfGf
         laFw==
X-Gm-Message-State: AOJu0YzYcDtrFEhi+0d3LkN3oUVP88fwlyvWYuIBv1kRJqePL7PRsqM7
	DX36J4nbaR+inIj7DNyqBvdISAYxoy9sXZZKlQxe98dT6JcnHtJ9n/90CnIf3U4=
X-Google-Smtp-Source: AGHT+IHLlhNYXE/6kGIuOV8RyQJkz94+F4ngG91XstEjeLrP2GB6zVYg8utY4QOPO06XiJPBcAjhWQ==
X-Received: by 2002:a05:6214:12c7:b0:690:c13f:ebc5 with SMTP id s7-20020a05621412c700b00690c13febc5mr17218960qvv.63.1710943584066;
        Wed, 20 Mar 2024 07:06:24 -0700 (PDT)
Date: Wed, 20 Mar 2024 15:06:21 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: "xen-devel@lists.xenproject.org" ,
	Andrew Cooper ,
	Nicola Vetrini 
Subject: Re: [PATCH] AMD/IOMMU: drop remaining guest-IOMMU bits too
Message-ID: 
References: <5eb98372-2992-4a93-846c-4e325c41af98@suse.com>
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Wed, Mar 20, 2024 at 11:58:50AM +0100, Jan Beulich wrote:
> On 20.03.2024 11:46, Roger Pau Monné wrote:
> > On Tue, Mar 19, 2024 at 02:28:12PM +0100, Jan Beulich wrote:
> >> With a02174c6c885 ("amd/iommu: clean up unused guest iommu related
> >> functions") having removed the sole place where d->g_iommu would be set
> >> to non-NULL, guest_iommu_add_ppr_log() will unconditionally bail the
> >> latest from its 2nd if(). With it dropped, all other stuff in the file
> >> is unused, too. Delete iommu_guest.c altogether.
> >>
> >> Further delete struct guest{_buffer,_dev_table,_iommu{,_msi}} as well as
> >> struct mmio_reg for being unused with the unused g_iommu also dropped
> >> from struct arch_iommu.
> >>
> >> Signed-off-by: Jan Beulich 

Acked-by: Roger Pau Monné 

> >> ---
> >> I wasn't sure how far to further go with removing the body of
> >> parse_ppr_log_entry(), or perhaps even the entire function, and then
> >> further up to all PPR logging code. Hence why for now I've merely
> >> commented out the function call into the file being deleted (which of
> >> course Misra isn't going to like). Thoughts / suggestions?
> >>
> >> I further wonder whether set_iommu_guest_translation_control() should
> >> have been invoked independent of guest-IOMMU actually being enabled. IOW
> >> that may want purging, too. Along these lines iommuv2_enabled may also
> >> want dropping, for not having any consumer left. Much like has_viommu()
> >> and then also {XEN_,}X86_EMU_IOMMU, i.e. going as far as affecting the
> >> public interface.

I would drop it all.  The public interface part is not stable anyway,
as it's a domctl, but I would be fine if you want to keep the X86_EMU_IOMMU.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 14:06:33 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 14:06:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695939.1086290 (Exim 4.92)
	(envelope-from )
	id 1rmwaP-0004JN-NL; Wed, 20 Mar 2024 14:06:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695939.1086290; Wed, 20 Mar 2024 14:06:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmwaP-0004JG-Kd; Wed, 20 Mar 2024 14:06:33 +0000
Received: by outflank-mailman (input) for mailman id 695939;
 Wed, 20 Mar 2024 14:06:32 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmwaO-0003uK-6h
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 14:06:32 +0000
Received: from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com
 [2607:f8b0:4864:20::f33])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0d31de53-e6c3-11ee-afdd-a90da7624cb6;
 Wed, 20 Mar 2024 15:06:31 +0100 (CET)
Received: by mail-qv1-xf33.google.com with SMTP id
 6a1803df08f44-690caa6438aso39482686d6.0
 for ; Wed, 20 Mar 2024 07:06:31 -0700 (PDT)
Received: from [10.80.67.139] (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 gw15-20020a0562140f0f00b00690c14810c2sm7923491qvb.126.2024.03.20.07.06.28
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 20 Mar 2024 07:06:29 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0d31de53-e6c3-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710943590; x=1711548390; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=BkBnxVF0udR67jOfrrXIuKFXssEKOQ+DddsXbOEkiYY=;
        b=l8ubKoRBkRDSNZMrK45yBt4hVC4jImdt4Xx1XSXCNIQTDSVFktAmPGAysMiMlQdHJb
         plsEH3GGtNvn/9aHXOj26qFQV3YV7GTMX83bz6JG10VLJM8lXw9peUsRRHTwA8/4cx3w
         EQ6ODxwfolsTgCz3Jk3SRs7em4o7cRhEmol8E=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710943590; x=1711548390;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=BkBnxVF0udR67jOfrrXIuKFXssEKOQ+DddsXbOEkiYY=;
        b=GFHfu+/Gbm3beq7P/uxcN1ykxsHRdQjcI4cbeThXbFKLENrSIt1VK1gpm6YRJS2Hlj
         jE91qkzaSUz07leSprRZmH2XbO+LjxiyEbVsRR/SdDd/+di4DFM1aRfwMnQUcwkDgV16
         J/PPVJvtJkl2rUAiS8rYPtENEZP158z89zYqaRcgNbYh9n+3mv0+MQ81tlTxbU5L21T2
         WhRslPHmsGIQ39IAURFWqdCCpgTAOfRWjVMAkdp8jnOrZEwsnOyckRa96PHxkJnkE3RB
         HGQDplXkB5EDwb0OyXxJPq0XCuQZjZYVpFTmatJ0wPnUVhFyBwGGPGMCuL5nI3SFDeR9
         +U3w==
X-Forwarded-Encrypted: i=1; AJvYcCUsIYoSggvBO5bAar1ZPKzRDomKIHEKFkJfP9a/MjGx3pmf4MTC5hx1n24NgBDKFS0e3tTSkPYXnUMBekCoGL+15Bm08vULhX71QhdgJSI=
X-Gm-Message-State: AOJu0YwRe9locwWcV0CRSHw6jfDOcno/9dityOlDjqIeRQSTXrFSmd4/
	fxpl7NWwC7ijw9T35hxKj9COWQFyKcKfJ0RmUXi90JBRjlYOI8ylwU6ckzR2A80=
X-Google-Smtp-Source: AGHT+IEL/0diGZvBoMG3uEAC4L7D/n9IgLs4z0Xtv2oxKRWVCmRQdRWgQFg7uG2DCiddYPkWzFLNSA==
X-Received: by 2002:a05:6214:88a:b0:691:2356:e82f with SMTP id cz10-20020a056214088a00b006912356e82fmr18925824qvb.54.1710943590302;
        Wed, 20 Mar 2024 07:06:30 -0700 (PDT)
Message-ID: <1304a0d2-ff17-4823-9d31-c32eb7b79f30@citrix.com>
Date: Wed, 20 Mar 2024 14:06:27 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/vcpu: relax VCPUOP_initialise restriction for non-PV
 vCPUs
Content-Language: en-GB
To: Roger Pau Monne , xen-devel@lists.xenproject.org
Cc: George Dunlap , Jan Beulich
 , Julien Grall ,
 Stefano Stabellini , Wei Liu 
References: <20240320135720.68894-1-roger.pau@citrix.com>
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <20240320135720.68894-1-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 20/03/2024 1:57 pm, Roger Pau Monne wrote:
> There's no reason to force HVM guests to have a valid vcpu_info area when
> initializing a vCPU, as the vCPU can also be brought online using the local
> APIC, and on that path there's no requirement for vcpu_info to be setup ahead
> of the bring up.  Note an HVM vCPU can operate normally without making use of
> vcpu_info.
>
> Restrict the check against dummy_vcpu_info to only apply to PV guests.
>
> Fixes: 192df6f9122d ('x86: allow HVM guests to use hypercalls to bring up vCPUs')
> Signed-off-by: Roger Pau Monné 

Thanks for looking into this.  But, do we actually need to force this on
PV either?

The only interesting user of dummy_vcpu_info now is vcpu_info_populate()
which can cope with any arbitrary vCPU.

I have a suspicion that we can (now) delete these two checks, delete the
dummy_vcpu_info object, and use a regular NULL pointer in
vcpu_info_{populate,reset}(), and in doing so, remove one of the bigger
pieces of PV-absurdity from Xen.

I can entirely believe that this is only safe to do with Jan's physical
registration changes in place.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 14:12:42 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 14:12:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695945.1086301 (Exim 4.92)
	(envelope-from )
	id 1rmwgG-0006Y1-IO; Wed, 20 Mar 2024 14:12:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695945.1086301; Wed, 20 Mar 2024 14:12:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmwgG-0006Xu-FO; Wed, 20 Mar 2024 14:12:36 +0000
Received: by outflank-mailman (input) for mailman id 695945;
 Wed, 20 Mar 2024 14:12:35 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmwgF-0006Xo-Mk
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 14:12:35 +0000
Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com
 [2a00:1450:4864:20::334])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e56bed45-e6c3-11ee-a1ee-f123f15fe8a2;
 Wed, 20 Mar 2024 15:12:33 +0100 (CET)
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-41464711dc8so15694465e9.1
 for ; Wed, 20 Mar 2024 07:12:33 -0700 (PDT)
Received: from perard.uk.xensource.com (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 a8-20020a05600c348800b004146bee69aesm2199199wmq.40.2024.03.20.07.12.31
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 20 Mar 2024 07:12:32 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e56bed45-e6c3-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1710943953; x=1711548753; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=zdJGPufGtkDxHWs2/MUnkUOn4lWBJySe7/m0Tl/oGNg=;
        b=QAoKMM0pMQ8e5OP/oosB9AfbyQVE+0Cqz3+rQbpfxnCn9cJsU+tYJ4CjiocIfWmgrf
         8W92dwd9O4/Wv8Ha1dsnZq9BLTTjot3oLl1mpzLUKUAEkpnHOMQSkJ6QGvrO/9cAQRYQ
         HdDd256Z26556CoakIkuLUm4labifX9MfreVI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710943953; x=1711548753;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=zdJGPufGtkDxHWs2/MUnkUOn4lWBJySe7/m0Tl/oGNg=;
        b=NMYcXqFtKq/4E+3SlP5rOjCs23B1+mYQIiqrFRPGLtb4pEgYJCIdhxvhHPNppyNks2
         t5FMRphHyXMN1WlaUdblFXqnLKujCAwfBHXbvuSZol6hqonieXJjxfXTFeMnRMltFao1
         3nF6/OuDVgkt4uh1FWHdlv4oXvmfltVddeETQwJlHUw08xiLTdqqJR6iwP7NsmePAvL5
         W0OUOJJrGbnVaCVZkwLmhRoyhxzc7pb/SUUZcTdeAb0J+nQ1xaagqHDkZ6GXotKbCwbe
         zyZOA0om7sFiCEtaTp5vVwFjz5ZEyZHYfA3+UogINheJGtHenJlYqOz8dtFrwurggCbU
         PUtw==
X-Gm-Message-State: AOJu0Yw6csdbSYYRT3NYpDM2e4hHMvb5ZbShz+qwugnGy0UxrZXKdgru
	aBWgFlv6BYCvVtiKpr6BDMbJnHddNZUcc0VHOi0+wdS5zOPsMmMWs+nGlZaRh28ll344h8yMcO6
	s
X-Google-Smtp-Source: AGHT+IF+FF5Uj31cl6Yxo3LYHy0pEvKeopvl70YFi3zRCvil61qDe/nyc4U3rKwkcNAXjEFCEerWiw==
X-Received: by 2002:a05:600c:1f91:b0:413:f1c0:49a8 with SMTP id je17-20020a05600c1f9100b00413f1c049a8mr1674211wmb.9.1710943953190;
        Wed, 20 Mar 2024 07:12:33 -0700 (PDT)
Date: Wed, 20 Mar 2024 14:12:31 +0000
From: Anthony PERARD 
To: Elliott Mitchell 
Cc: xen-devel@lists.xenproject.org
Subject: Re: [PATCH RESEND] tools/xl_parse: remove message for tsc mode string
Message-ID: <12990d47-17fd-4bf8-a510-f77e7be7ec0b@perard>
References: <8891bdfb2378187cfcaa8ed6f49817404db15924.1690307465.git.ehem+xen@m5p.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <8891bdfb2378187cfcaa8ed6f49817404db15924.1690307465.git.ehem+xen@m5p.com>

On Thu, Jul 13, 2023 at 04:53:57PM -0700, Elliott Mitchell wrote:
> Normal behavior is to be silent.  Generating a message for the preferred
> input can be mistaken for an error.  As such remove this message to match
> other conditions.
> 
> Signed-off-by: Elliott Mitchell 

Acked-by: Anthony PERARD 

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 14:26:54 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 14:26:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695950.1086311 (Exim 4.92)
	(envelope-from )
	id 1rmwtz-0000z8-L7; Wed, 20 Mar 2024 14:26:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695950.1086311; Wed, 20 Mar 2024 14:26:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmwtz-0000z1-IM; Wed, 20 Mar 2024 14:26:47 +0000
Received: by outflank-mailman (input) for mailman id 695950;
 Wed, 20 Mar 2024 14:26:46 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmwty-0000yv-Bm
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 14:26:46 +0000
Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com
 [2607:f8b0:4864:20::229])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e00f52d4-e6c5-11ee-a1ee-f123f15fe8a2;
 Wed, 20 Mar 2024 15:26:44 +0100 (CET)
Received: by mail-oi1-x229.google.com with SMTP id
 5614622812f47-3c3775ce48fso3709101b6e.2
 for ; Wed, 20 Mar 2024 07:26:44 -0700 (PDT)
Received: from localhost ([85.31.135.62]) by smtp.gmail.com with ESMTPSA id
 iw14-20020a0562140f2e00b0069154e0670asm7936133qvb.90.2024.03.20.07.26.42
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 20 Mar 2024 07:26:42 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e00f52d4-e6c5-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710944803; x=1711549603; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=iRQBOFOQNXkfZj3H8gzR5SexlsVHOAyq+SBM60zqi8g=;
        b=aTPzXJfFKkfHUx7v9nlDkRsJ+LOyUbxZAaToyFYGHOdZG+5p9a/FldEyEhRTKZoOdE
         LWDFqP4DcSOXm7AUSY3JrdEqYfHUY9In0TkaRzvDwhYIYY5EVOzWurYAKZiPF7RVmI14
         2LcpoT/CSkaqg8VqpEz0cHJ6x6GF6i9j2nvE8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710944803; x=1711549603;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=iRQBOFOQNXkfZj3H8gzR5SexlsVHOAyq+SBM60zqi8g=;
        b=putX+cmgce68DE0NlAT5pbuwSMVO7oZw75Obq8pm+VX406dA+4pcsHTpIEi1YG9dMA
         qFyBF4XR6VCIf+OMFB5hA+cjDuA/VvDt3g+Y3L+qiLjRxQSEqo+6AB1UC5aelmUQ1WKb
         vI5f+0+xOBUlCzYY/nWki5pk0kSL1Sk5YggaahusVn+wVKMQZC8cgi6pB7TFnvUCEHG/
         2HJ7qEJNtBqTMnRXz693rR9cJxg5J/lPeayrLE4kFXbdyH0HHKBUklll/HqqyJZy8mw0
         ltFXCMVBNNX0jcgyhxTCRnMz5fSDQU6nvrndicW643b3GFVPqOMNxUu5ySi+uXOnu+Ch
         fMQw==
X-Gm-Message-State: AOJu0YxBczxptWH5zB0Aet/X7zS0g5wLzQ5fESWmH/iJZUDw9qIkR4uE
	Ft1diISfM5EIJ8/lo9nndU7h8NK/gr1nSnGQI1dxu4llKf1ZpyBxDAhP30C+3g0=
X-Google-Smtp-Source: AGHT+IHp7ZFrptBZHii3Y/XeLjLmBvUMj+HlNpj4p9Z2TAyl6uTzybqP+/FARn/w11DLTeeKM2wOoA==
X-Received: by 2002:a05:6808:4c8e:b0:3c2:39c8:435f with SMTP id lt14-20020a0568084c8e00b003c239c8435fmr18223845oib.51.1710944802970;
        Wed, 20 Mar 2024 07:26:42 -0700 (PDT)
Date: Wed, 20 Mar 2024 15:26:40 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Andrew Cooper 
Cc: xen-devel@lists.xenproject.org,
	George Dunlap ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini , Wei Liu 
Subject: Re: [PATCH] x86/vcpu: relax VCPUOP_initialise restriction for non-PV
 vCPUs
Message-ID: 
References: <20240320135720.68894-1-roger.pau@citrix.com>
 <1304a0d2-ff17-4823-9d31-c32eb7b79f30@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1304a0d2-ff17-4823-9d31-c32eb7b79f30@citrix.com>

On Wed, Mar 20, 2024 at 02:06:27PM +0000, Andrew Cooper wrote:
> On 20/03/2024 1:57 pm, Roger Pau Monne wrote:
> > There's no reason to force HVM guests to have a valid vcpu_info area when
> > initializing a vCPU, as the vCPU can also be brought online using the local
> > APIC, and on that path there's no requirement for vcpu_info to be setup ahead
> > of the bring up.  Note an HVM vCPU can operate normally without making use of
> > vcpu_info.
> >
> > Restrict the check against dummy_vcpu_info to only apply to PV guests.
> >
> > Fixes: 192df6f9122d ('x86: allow HVM guests to use hypercalls to bring up vCPUs')
> > Signed-off-by: Roger Pau Monné 
> 
> Thanks for looking into this.  But, do we actually need to force this on
> PV either?

Possibly, having now taken a look at the users it does seem they could
cope with unpopulated vcpu_info_area.

Part of my understanding was that this was some kind of courtesy to PV
guests in order to prevent starting them without a vcpu_info, which
strictly speaking is not mandatory, but otherwise the guest vCPU won't
be able to receive interrupts, not even IPIs.

> The only interesting user of dummy_vcpu_info now is vcpu_info_populate()
> which can cope with any arbitrary vCPU.
> 
> I have a suspicion that we can (now) delete these two checks, delete the
> dummy_vcpu_info object, and use a regular NULL pointer in
> vcpu_info_{populate,reset}(), and in doing so, remove one of the bigger
> pieces of PV-absurdity from Xen.

I was expecting this to be something we can backport.  OTOH removing
the check completely (or even getting rid of dummy_vcpu_info) is not
something that we would want to backport.

I would rather do the removal of dummy_vcpu_info as followup work.

> I can entirely believe that this is only safe to do with Jan's physical
> registration changes in place.

Quite possible.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 14:39:26 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 14:39:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695953.1086321 (Exim 4.92)
	(envelope-from )
	id 1rmx67-0003Qm-O8; Wed, 20 Mar 2024 14:39:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695953.1086321; Wed, 20 Mar 2024 14:39:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmx67-0003Qf-KB; Wed, 20 Mar 2024 14:39:19 +0000
Received: by outflank-mailman (input) for mailman id 695953;
 Wed, 20 Mar 2024 14:39:18 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmx65-0003QZ-W0
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 14:39:18 +0000
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com
 [2a00:1450:4864:20::531])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a075daf1-e6c7-11ee-afdd-a90da7624cb6;
 Wed, 20 Mar 2024 15:39:16 +0100 (CET)
Received: by mail-ed1-x531.google.com with SMTP id
 4fb4d7f45d1cf-56bb8f3227aso519181a12.1
 for ; Wed, 20 Mar 2024 07:39:16 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 my10-20020a1709065a4a00b00a4663d3b2bfsm7354785ejc.217.2024.03.20.07.39.14
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 20 Mar 2024 07:39:15 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a075daf1-e6c7-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710945555; x=1711550355; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=EoKlxf9sOHi4JkbA9q5u0OspUWK75YnLeNcXbtSLkdk=;
        b=B1WPY6zsgh3NPQBGqcIiDtdUSBOMQVCrVJ17SyUA06YXnTgPdds8ZfeQDho/CcChiz
         6/3vlq0Pa0Y5OxyJmbgo1SSjZ+amPRMKG9wfg5Z4kwySO9ggAlbJQG3VzyQuT3g5NxWP
         Llr2qwsPwAz2U6+ip8kWYydZ29CUEkyRGi2IFfwb2ddliAt9PXsyFTHWcoEc7vDY+Ao7
         BTTznVgiKtI1q2fL8AAeSceFKAHaaLyRNfDp88/PynTtH1uwJzK/O3NdMg7pE6i2AYx0
         sX/KmMhpMVu/0EBi+So7VOHBz+4t7iDDISrMv2Tko6s467JjmnesX+GWSGQMekxmLNnz
         L1gg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710945555; x=1711550355;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=EoKlxf9sOHi4JkbA9q5u0OspUWK75YnLeNcXbtSLkdk=;
        b=Io1RJx3q3OT4cIvcTln4Fe/Q3u/zS4ejU8sKZPlzO4uphvGU5Q+derezl39v5Cmbzi
         X/0H2tqcRCACyPbb/+bknbZnvYeN3XWjgZjZGf//kryKLyejLoCwtFf7vmwhCuhUaK7e
         XqiVvgO/d43+VJs3bcplQ8UDeeCWeInhxd9rwbqnmvmWQ0kabOLnFziJcTYpwRZov9FG
         5yfXEsHud3j1P8w5BhpmpL6Q2Ra5OTwSDS0RoSZtRxOe36jcpm8m+dXWqZvt1el7/+Dv
         rLa/zlzw+okIJnnlq1zmCHX23r9x5s/0t+TkzwPcQsTDvcC+6MI6rKpm8tGkYAyvk3U0
         3t9w==
X-Forwarded-Encrypted: i=1; AJvYcCWiFr9eUFuoi0CQLc+JleK+SOIPDEYaTByjF2PeCcwWoGnnUTGLFnqiyZO1SYo/ZL4zspDrCsN0HoRXxwVs2bKh9tLKBkR3IfUEku0707Q=
X-Gm-Message-State: AOJu0Yz4zyqpTQ6Kt6I+NInrVLDlderO9+1w6hHI3Gz5gKpUjV7n4il7
	+r8tvI9W3CVFfxOQrTn9rulo7+OKApZNlM2DoeDJLP1+gnwop6RXp/Mn/hVBdQ==
X-Google-Smtp-Source: AGHT+IHaYqyDYAqfMBJNZ1Qy/3bSNEUHdA5KsPW8/r+3QjV5TOS8PYPxdFexCPwOTUzwgBJaSC7UFg==
X-Received: by 2002:a17:906:1949:b0:a45:ff13:3626 with SMTP id b9-20020a170906194900b00a45ff133626mr9404711eje.25.1710945555577;
        Wed, 20 Mar 2024 07:39:15 -0700 (PDT)
Message-ID: 
Date: Wed, 20 Mar 2024 15:39:14 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 3/3] x86/PVH: Support relocatable dom0 kernels
Content-Language: en-US
To: Jason Andryuk 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu
 , George Dunlap ,
 Julien Grall , Stefano Stabellini ,
 xen-devel@lists.xenproject.org
References: <20240319205849.115884-1-jason.andryuk@amd.com>
 <20240319205849.115884-4-jason.andryuk@amd.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240319205849.115884-4-jason.andryuk@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 19.03.2024 21:58, Jason Andryuk wrote:
> --- a/xen/arch/x86/hvm/dom0_build.c
> +++ b/xen/arch/x86/hvm/dom0_build.c
> @@ -537,6 +537,97 @@ static paddr_t __init find_memory(
>      return INVALID_PADDR;
>  }
>  
> +static bool __init check_load_address(
> +    const struct domain *d, const struct elf_binary *elf)
> +{
> +    paddr_t kernel_start = (paddr_t)elf->dest_base;

As before I think it is illegitimate to cast a pointer to paddr_t. The
variable type wants to remain such, but the cast wants to be to
unsigned long or uintptr_t (or else at least a comment wants adding).

> +    paddr_t kernel_end = kernel_start + elf->dest_size;
> +    unsigned int i;
> +
> +    /* Relies on a sorted memory map. */
> +    for ( i = 0; i < d->arch.nr_e820; i++ )
> +    {
> +        paddr_t start = d->arch.e820[i].addr;
> +        paddr_t end = d->arch.e820[i].addr + d->arch.e820[i].size;

Nit: Shorter if you use "start" here (also again in the other function).

> +        if ( start >= kernel_end )
> +            return false;
> +
> +        if ( d->arch.e820[i].type == E820_RAM  &&

Nit: Excess blank before &&.

> +             start <= kernel_start &&
> +             end >= kernel_end )
> +            return true;

As to the comment ahead of the function: This further relies on adjacent
entries of the same type having got merged.

> +    }
> +
> +    return false;
> +}
> +
> +/* Find an e820 RAM region that fits the kernel at a suitable alignment. */
> +static paddr_t __init find_kernel_memory(
> +    const struct domain *d, struct elf_binary *elf,
> +    const struct elf_dom_parms *parms)
> +{
> +    paddr_t kernel_size = elf->dest_size;
> +    unsigned int i;
> +
> +    for ( i = 0; i < d->arch.nr_e820; i++ )
> +    {
> +        paddr_t start = d->arch.e820[i].addr;
> +        paddr_t end = d->arch.e820[i].addr + d->arch.e820[i].size;
> +        paddr_t kstart, kend;
> +
> +        if ( d->arch.e820[i].type != E820_RAM ||
> +             d->arch.e820[i].size < kernel_size )
> +            continue;
> +
> +        kstart = ROUNDUP(start, parms->phys_align);
> +        kstart = max_t(paddr_t, kstart, parms->phys_min);

I'd generally try to avoid max_t(), but I cannot think of any good way
of expressing this without using it.

> +        kend = kstart + kernel_size;
> +
> +        if ( kend > parms->phys_max )

So despite its default phys_max is exclusive aiui. Otherwise with
kend being exclusive too, this would look to be off by one.

> +            return 0;
> +
> +        if ( kend <= end )
> +            return kstart;
> +    }
> +
> +    return 0;
> +}
> +
> +/* Check the kernel load address, and adjust if necessary and possible. */
> +static bool __init check_and_adjust_load_address(
> +    const struct domain *d, struct elf_binary *elf, struct elf_dom_parms *parms)
> +{
> +    paddr_t reloc_base;
> +
> +    if ( check_load_address(d, elf) )
> +        return true;
> +
> +    if ( !parms->phys_reloc )
> +    {
> +        printk("%pd kernel: Address conflict and not relocatable\n", d);
> +        return false;

This better wouldn't result in -ENOMEM in the caller. Then again reasons
are logged, so the specific error code perhaos doesn't matter that much.

> +    }
> +
> +    reloc_base = find_kernel_memory(d, elf, parms);
> +    if ( reloc_base == 0 )

With ! used above please be consistent and do so here, too.

> +    {
> +        printk("%pd kernel: Failed find a load address\n", d);
> +        return false;
> +    }
> +
> +    if ( opt_dom0_verbose )
> +        printk("%pd kernel: Moving [%p, %p] -> [%"PRIpaddr", %"PRIpaddr"]\n", d,
> +               elf->dest_base, elf->dest_base + elf->dest_size - 1,
> +               reloc_base, reloc_base + elf->dest_size - 1);
> +
> +    parms->phys_entry = reloc_base +
> +                            (parms->phys_entry - (paddr_t)elf->dest_base);
> +    elf->dest_base = (char *)reloc_base;

Just as a remark, no request to change anything: We're not dealing with
strings here. Hence char * isn't quite right, just that "dest_base" is
of that type (for whatever reason).

> @@ -161,6 +164,10 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
>      {
>          elf_msg(elf, "ELF: note: %s\n", note_desc[type].name);
>      }
> +    else if ( note_desc[type].type == ELFNOTE_CUSTOM )
> +    {
> +        elf_msg(elf, "ELF: note: %s", note_desc[type].name);
> +    }

This could do with a brief comment, to make clear the \n isn't accidentally
missing here.

> @@ -225,6 +232,28 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
>      case XEN_ELFNOTE_PHYS32_ENTRY:
>          parms->phys_entry = val;
>          break;
> +
> +    case XEN_ELFNOTE_PHYS32_RELOC:
> +        parms->phys_reloc = true;
> +
> +        if ( descsz >= 4 )
> +        {
> +            parms->phys_max = elf_note_numeric_array(elf, note, 4, 0);
> +            elf_msg(elf, " = max: %#"PRIx32, parms->phys_max);
> +        }
> +        if ( descsz >= 8 )
> +        {
> +            parms->phys_min = elf_note_numeric_array(elf, note, 4, 1);
> +            elf_msg(elf, " min: %#"PRIx32, parms->phys_min);
> +        }
> +        if ( descsz >= 12 )
> +        {
> +            parms->phys_align = elf_note_numeric_array(elf, note, 4, 2);
> +            elf_msg(elf, " align: %#"PRIx32, parms->phys_align);
> +        }
> +
> +        elf_msg(elf, "\n");

Imo the newline wants adding outside of the switch(), for everything
set to ELFNOTE_CUSTOM. In fact with that I think ELFNOTE_CUSTOM and
ELFNOTE_NAME could be folded (with what's NAME right now simply
printing nothing in the switch here). Which suggests that I may
better not commit the (slightly adjusted) earlier patch, yet.

> @@ -536,6 +565,10 @@ elf_errorstatus elf_xen_parse(struct elf_binary *elf,
>      parms->p2m_base = UNSET_ADDR;
>      parms->elf_paddr_offset = UNSET_ADDR;
>      parms->phys_entry = UNSET_ADDR32;
> +    parms->phys_min = 0;
> +    parms->phys_max = 0xffffffff;
> +    parms->phys_align = 0x200000;

I think this wants to be MB(2) (requiring a pre-patch to centralize MB()
in the tool stack to tools/include/xen-tools/common-macros.h). And I
further think this needs to be an arch-specific constant, even if right
now the note is expected to be present only for x86. Which then also
needs saying ...

> --- a/xen/include/public/elfnote.h
> +++ b/xen/include/public/elfnote.h
> @@ -194,10 +194,26 @@
>   */
>  #define XEN_ELFNOTE_PHYS32_ENTRY 18
>  
> +/*
> + * Physical loading constraints for PVH kernels
> + *
> + * Used to place constraints on the guest physical loading addresses and
> + * alignment for a PVH kernel.
> + *
> + * The presence of this note indicates the kernel supports relocating itself.
> + *
> + * The note may include up to three 32bit values in the following order:
> + *  - a maximum address for the entire image to be loaded below (default
> + *      0xffffffff)
> + *  - a minimum address for the start of the image (default 0)
> + *  - a required start alignment (default 0x200000)
> + */
> +#define XEN_ELFNOTE_PHYS32_RELOC 19

... in the comment here. The reasoning behind not (intermediately) falling
back to the alignment in the ELF headers also wants adding to the patch
description (or a code comment, albeit there's no really good place to put
it, imo).

Additionally I think the pieces of the comment want re-ordering. The primary
purpose is indicating relocatability; when not relocating, the constraints
aren't applied in any way.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 14:39:30 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 14:39:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695954.1086331 (Exim 4.92)
	(envelope-from )
	id 1rmx6H-0003ik-U6; Wed, 20 Mar 2024 14:39:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695954.1086331; Wed, 20 Mar 2024 14:39:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmx6H-0003id-Qu; Wed, 20 Mar 2024 14:39:29 +0000
Received: by outflank-mailman (input) for mailman id 695954;
 Wed, 20 Mar 2024 14:39:28 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmx6G-0003i2-5n
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 14:39:28 +0000
Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com
 [2607:f8b0:4864:20::72f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a63846f6-e6c7-11ee-a1ee-f123f15fe8a2;
 Wed, 20 Mar 2024 15:39:26 +0100 (CET)
Received: by mail-qk1-x72f.google.com with SMTP id
 af79cd13be357-789dbd9a6f1so458939685a.1
 for ; Wed, 20 Mar 2024 07:39:26 -0700 (PDT)
Received: from [10.80.67.139] (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 fq9-20020a056214258900b00690d5310c55sm7898609qvb.114.2024.03.20.07.39.23
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 20 Mar 2024 07:39:24 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a63846f6-e6c7-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710945565; x=1711550365; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=Ajswfk2sjKRwa/19iHb95k1d/F0Cr7s1YL08KFECNhA=;
        b=nz3+l2oQiUKIzpQXxxdORJzxZb6zrorjkdt15ybLw7+sGC8Y3iCwWQBgRkn0WbOmWK
         XN1qCLCLaSrB8ic1LKVX3xl3LpW62xPN6r0+jeOesOj67ivbcBRkkjYa/VXflXT511g/
         c0lE9QhjW7hMezeybAc8gBtz9dBXgidZEj6SU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710945565; x=1711550365;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=Ajswfk2sjKRwa/19iHb95k1d/F0Cr7s1YL08KFECNhA=;
        b=FB4Jn4UeXV1k72+DNL+0LtlGfDn6/vhCMYlZMX9j/N6ziInsorp/IRk2kLXF5MiGx5
         RrvKWwl3olL4c+YrLnakJaVeYOeetQZGbMMN2L/rqlQ2D4VFkNpzhciidGVjfxVgO6a3
         6xEvuywCbvmnI/b6FNfyRXQrsfvz2s9e+fu6iJcjxf/IT+wzcvT+yVYxTbq1CCLaALeP
         ADECjUazSAS6WpFGhuLOomIdk2vAVd/FW1iMZtI9d1SIPVyPP+VEG9xvu7Jr9DhRPgdx
         /A51Rh2+hOH4HLmBIqJFgkdOwMalFVzTXasxIaX9IelH8GENYpe+x/wKhX+b8mL2ViTC
         beKQ==
X-Gm-Message-State: AOJu0YwvlivnC5O5tLchWnSlpf3ypN2sQtQM6wb1ojpcSnNw7OdkB57J
	iaNk+5L3anezCnAKaVqGJJ0rsXTlZU65o2L8Y9cnZcQ3tKeul8gkCsJbBqUebHU=
X-Google-Smtp-Source: AGHT+IHG16YNl0P89+u2+PyuZWl7wypLMWZSpuLYeJwgwgBJSA8W6vgxo8RTND/6W+G45RLQqgnTiw==
X-Received: by 2002:a0c:9c8c:0:b0:68f:2b35:5edf with SMTP id i12-20020a0c9c8c000000b0068f2b355edfmr17850085qvf.13.1710945565093;
        Wed, 20 Mar 2024 07:39:25 -0700 (PDT)
Message-ID: <815d5bd4-18af-4f5f-b6a5-6302a1d682a2@citrix.com>
Date: Wed, 20 Mar 2024 14:39:22 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/vcpu: relax VCPUOP_initialise restriction for non-PV
 vCPUs
Content-Language: en-GB
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: xen-devel@lists.xenproject.org, George Dunlap ,
 Jan Beulich , Julien Grall ,
 Stefano Stabellini , Wei Liu 
References: <20240320135720.68894-1-roger.pau@citrix.com>
 <1304a0d2-ff17-4823-9d31-c32eb7b79f30@citrix.com> 
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 20/03/2024 2:26 pm, Roger Pau Monné wrote:
> On Wed, Mar 20, 2024 at 02:06:27PM +0000, Andrew Cooper wrote:
>> On 20/03/2024 1:57 pm, Roger Pau Monne wrote:
>>> There's no reason to force HVM guests to have a valid vcpu_info area when
>>> initializing a vCPU, as the vCPU can also be brought online using the local
>>> APIC, and on that path there's no requirement for vcpu_info to be setup ahead
>>> of the bring up.  Note an HVM vCPU can operate normally without making use of
>>> vcpu_info.
>>>
>>> Restrict the check against dummy_vcpu_info to only apply to PV guests.
>>>
>>> Fixes: 192df6f9122d ('x86: allow HVM guests to use hypercalls to bring up vCPUs')
>>> Signed-off-by: Roger Pau Monné 
>> Thanks for looking into this.  But, do we actually need to force this on
>> PV either?
> Possibly, having now taken a look at the users it does seem they could
> cope with unpopulated vcpu_info_area.
>
> Part of my understanding was that this was some kind of courtesy to PV
> guests in order to prevent starting them without a vcpu_info, which
> strictly speaking is not mandatory, but otherwise the guest vCPU won't
> be able to receive interrupts, not even IPIs.

That's more of a stick than a carrot... "you must set up the area of a
CPU before you can bring it online". Except as we've seen, HVM has been
fine all along without it.
>> The only interesting user of dummy_vcpu_info now is vcpu_info_populate()
>> which can cope with any arbitrary vCPU.
>>
>> I have a suspicion that we can (now) delete these two checks, delete the
>> dummy_vcpu_info object, and use a regular NULL pointer in
>> vcpu_info_{populate,reset}(), and in doing so, remove one of the bigger
>> pieces of PV-absurdity from Xen.
> I was expecting this to be something we can backport.  OTOH removing
> the check completely (or even getting rid of dummy_vcpu_info) is not
> something that we would want to backport.
>
> I would rather do the removal of dummy_vcpu_info as followup work.

I was worried about ARM with your patch, because it's spelt HVM there,
rather than PV.

However, I'd forgotten that ARM's do_vcpu_op() filters ops down to just
VCPUOP_register_{vcpu_info,runstate_memory_area} so VCPUOP_initialise
isn't reachable.

Therefore, Reviewed-by: Andrew Cooper 

It also means ARM can't use any of the PHYS registration yet...

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 14:42:36 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 14:42:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695959.1086341 (Exim 4.92)
	(envelope-from )
	id 1rmx9G-0005qP-Fp; Wed, 20 Mar 2024 14:42:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695959.1086341; Wed, 20 Mar 2024 14:42:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmx9G-0005qI-DC; Wed, 20 Mar 2024 14:42:34 +0000
Received: by outflank-mailman (input) for mailman id 695959;
 Wed, 20 Mar 2024 14:42:33 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmx9F-0005qB-G3
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 14:42:33 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.129.124])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 145d1188-e6c8-11ee-a1ee-f123f15fe8a2;
 Wed, 20 Mar 2024 15:42:31 +0100 (CET)
Received: from mail-oi1-f200.google.com (mail-oi1-f200.google.com
 [209.85.167.200]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-691-Wxepv2U9OmeF6JRKW-vBwA-1; Wed, 20 Mar 2024 10:42:28 -0400
Received: by mail-oi1-f200.google.com with SMTP id
 5614622812f47-3c38e3efb8aso463510b6e.0
 for ; Wed, 20 Mar 2024 07:42:28 -0700 (PDT)
Received: from x1n ([99.254.121.117]) by smtp.gmail.com with ESMTPSA id
 ge16-20020a05622a5c9000b00430b79aaa1esm5775620qtb.94.2024.03.20.07.42.26
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 20 Mar 2024 07:42:27 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 145d1188-e6c8-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1710945750;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=lmYNCVj1qYxPr/KiXOpLo9If0W3ioxfEJHjY6ipJGAg=;
	b=KMkEieClrqdb1HKf3Rs+hXMmu5JxJ4BTs0AtWNHsIxLdz1R+PLslw7XQgcxvLzcgesAmF3
	OmVtqyI8dqs+DBnzDHy5fgt7rK8pk+sENHHJpYqY4hjQYmu8tij/REP/ivuynHSQ58Ruq+
	+k/ggYRwGX88KeJXTQGjnNOIyQcUyy0=
X-MC-Unique: Wxepv2U9OmeF6JRKW-vBwA-1
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710945748; x=1711550548;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=lmYNCVj1qYxPr/KiXOpLo9If0W3ioxfEJHjY6ipJGAg=;
        b=Vw48kg7hpVmrk/Vj2HsiP6eEzXtPk2g1IwQFXzrUXm3LP83j84L0NWO6xAtLfAhx4u
         1aWttGCobfo8qnXN7vvdY3C2tsy50C3WEfu/te68osrHhtLh43Te4XXDXR0PA62VT+Ly
         xZ3xtcoN5Y9bYzO+m1QbbXrQ2pl65DqNh8GwLYl49MAozisLeqhbWTfBfpOOjn+03hVx
         ROAllCxyrwrUNNZ73OcbrBN1dnu9k8zO8/SHvEakltxfQKprbbhvJSHb3aIDwT/JaPb3
         9XahMAKjD7hIoWe6H5ArKe2bvU8Cih4HrIeKIPlJeOC77nPvX85VyHM+8zM4nwI/wYmC
         +urg==
X-Forwarded-Encrypted: i=1; AJvYcCXUDF5bM33OUjfvx4RjuimI82RWAcOT71AoIoEIKZeU2HprO4bGjIxPOI1GT9DoucyuHJbBdW7Pdcq7IYBtlBSz0ftV0HWWdCtp1EkHCIU=
X-Gm-Message-State: AOJu0YxAuDQ/sWGMt80GTp6n2QEucrco8FhxX0PumO1M9VGIg/8Tu9g/
	7UZuBCdqxYgzRM3KfmOQ9NyV2QPnmXhtIuyhJkfePeflF2vXPdPrD5pbk4XWQINWqeLiJYBYqbb
	wzSKm+FrjXz0hKu7BUe7uHNmlMqTUEMTqLNJgltSiB7L4Sxajq8yEwDGkjvGoF5a8
X-Received: by 2002:a05:6808:1508:b0:3c3:62e8:b257 with SMTP id u8-20020a056808150800b003c362e8b257mr17461016oiw.2.1710945747861;
        Wed, 20 Mar 2024 07:42:27 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IGG1VX1WcbuhKZfwJ8zAztngTa7EDORJFVVDVVSW2Mx3OJakfgoqiSm2eUrIxhK5KuwSOm0dQ==
X-Received: by 2002:a05:6808:1508:b0:3c3:62e8:b257 with SMTP id u8-20020a056808150800b003c362e8b257mr17460978oiw.2.1710945747404;
        Wed, 20 Mar 2024 07:42:27 -0700 (PDT)
Date: Wed, 20 Mar 2024 10:42:24 -0400
From: Peter Xu 
To: =?utf-8?Q?C=C3=A9dric?= Le Goater 
Cc: qemu-devel@nongnu.org, Stefano Stabellini ,
	Anthony Perard ,
	Paul Durrant , Paolo Bonzini ,
	Richard Henderson ,
	Eduardo Habkost ,
	"Michael S. Tsirkin" ,
	Marcel Apfelbaum ,
	Alex Williamson ,
	David Hildenbrand ,
	Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= ,
	Fabiano Rosas , Avihai Horon ,
	Markus Armbruster ,
	Prasad Pandit ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH for-9.1 v5 09/14] memory: Add Error** argument to
 .log_global_start() handler
Message-ID: 
References: <20240320064911.545001-1-clg@redhat.com>
 <20240320064911.545001-10-clg@redhat.com>
MIME-Version: 1.0
In-Reply-To: <20240320064911.545001-10-clg@redhat.com>
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

On Wed, Mar 20, 2024 at 07:49:05AM +0100, Cédric Le Goater wrote:
> Modify all .log_global_start() handlers to take an Error** parameter
> and return a bool. Adapt memory_global_dirty_log_start() to interrupt
> on the first error the loop on handlers. In such case, a rollback is
> performed to stop dirty logging on all listeners where it was
> previously enabled.
> 
> Cc: Stefano Stabellini 
> Cc: Anthony Perard 
> Cc: Paul Durrant 
> Cc: "Michael S. Tsirkin" 
> Cc: Paolo Bonzini 
> Cc: David Hildenbrand 
> Signed-off-by: Cédric Le Goater 

Reviewed-by: Peter Xu 

Still one comment below:

> @@ -3014,8 +3044,11 @@ static void listener_add_address_space(MemoryListener *listener,
>          listener->begin(listener);
>      }
>      if (global_dirty_tracking) {
> +        /*
> +         * Migration has already started. Assert on any error.

If you won't mind, I can change this to:

  /*
   * Currently only VFIO can fail log_global_start(), and it's not allowed
   * to hotplug a VFIO device during migration, so this should never fail
   * when invoked.  If it can start to fail in the future, we need to be
   * able to fail the whole listener_add_address_space() and its callers.
   */

Thanks,

> +         */
>          if (listener->log_global_start) {
> -            listener->log_global_start(listener);
> +            listener->log_global_start(listener, &error_abort);
>          }
>      }
>  
> -- 
> 2.44.0
> 

-- 
Peter Xu



From xen-devel-bounces@lists.xenproject.org Wed Mar 20 14:52:03 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 14:52:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695965.1086354 (Exim 4.92)
	(envelope-from )
	id 1rmxIN-0008A4-CC; Wed, 20 Mar 2024 14:51:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695965.1086354; Wed, 20 Mar 2024 14:51:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmxIN-00089x-8r; Wed, 20 Mar 2024 14:51:59 +0000
Received: by outflank-mailman (input) for mailman id 695965;
 Wed, 20 Mar 2024 14:51:58 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmxIM-00089r-3c
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 14:51:58 +0000
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com
 [2a00:1450:4864:20::632])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 65e17366-e6c9-11ee-afdd-a90da7624cb6;
 Wed, 20 Mar 2024 15:51:56 +0100 (CET)
Received: by mail-ej1-x632.google.com with SMTP id
 a640c23a62f3a-a46f28f89baso141725866b.0
 for ; Wed, 20 Mar 2024 07:51:56 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 l8-20020a17090612c800b00a46aab70226sm5003222ejb.180.2024.03.20.07.51.55
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 20 Mar 2024 07:51:55 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 65e17366-e6c9-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710946316; x=1711551116; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=CFMfJtML86pv/21eEramWeq28DSOe+aESCcohJ1wgE0=;
        b=XalG+dpSwQnh4QNGQ7o+OSkr+d5jQBuIh/HOQIT1d1osWAEu0GygmcCTkXq0MuIToB
         FaA40f7Zp4/EyllQANw8civ60I3qlkpBinnSYxsekAxEboxhrDNwvXYmFSfdoPbUV0oz
         9nWDyXZM0IRBenL5OOu1SmRqb89srmSHGM6GzxDR/T8/UTrAF8Pf4f36fmOwzWEiIwlo
         PX7hh//SDtM384wQQUT77K6ODj19ZarOmAO76llY65TeKul5ahkBC5n4rOaNZoy8hp3B
         2qv/7LXNKr4dm0gC8Ww2TXFFCxSbtXtI/+zUI5s+Z53HS0bjJmi6PYKvlP4G7o4TY0xw
         wOew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710946316; x=1711551116;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=CFMfJtML86pv/21eEramWeq28DSOe+aESCcohJ1wgE0=;
        b=CKdpdGxeif5GBAcqry6JIxO/OSoR4UpeMbmr5GMo+FZPeBGmfCHgGqw4GG+QndssZA
         SwC9o3n0aqxTLB4yy26ZpZVceWY4/8s2PatBjAZGpLMmQviE0iOQeDhYENMvPbP4YX9f
         j0ecdvi6WnFwxHTQ0/Vs+qL9XQIG0zTXLasMK+XkW/IQPu9xsAH0gxWeYtWbUO9pNtuR
         TCcsuYnk/NHVbHcVR8J8nOoBzMa+o3m/6LAaVyvgNQswVSoCzGweJIcnxS4b07klmstL
         Sff7MVioupoW3i+Y7fu008dOoxLvYdLoFRCmRqz53GHcXPAn7ZETv4RhxXU4NYZoXiNz
         SXCg==
X-Gm-Message-State: AOJu0YzjqCMAK7f71FfvvLFg4Gia+zeI/U9vgvQcidN4FPl8Ynhfcvj6
	LxIyzZSFLvlCggXPdn35+yH6wAvX5ZjItxehFgaQ2SITcWHb7hpmFM/6J3vdow==
X-Google-Smtp-Source: AGHT+IHcp4QK7WOx2IlrUEzMjc53/wzNLiYSCjVLaXQFzSR3FMnfHyje/z1YoD45tHHveo7TTGtX7w==
X-Received: by 2002:a17:906:1152:b0:a46:ba8f:bcdc with SMTP id i18-20020a170906115200b00a46ba8fbcdcmr2531593eja.8.1710946316322;
        Wed, 20 Mar 2024 07:51:56 -0700 (PDT)
Message-ID: 
Date: Wed, 20 Mar 2024 15:51:55 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] AMD/IOMMU: drop remaining guest-IOMMU bits too
Content-Language: en-US
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: "xen-devel@lists.xenproject.org" ,
 Andrew Cooper ,
 Nicola Vetrini 
References: <5eb98372-2992-4a93-846c-4e325c41af98@suse.com>
  
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 20.03.2024 15:06, Roger Pau Monné wrote:
> On Wed, Mar 20, 2024 at 11:58:50AM +0100, Jan Beulich wrote:
>> On 20.03.2024 11:46, Roger Pau Monné wrote:
>>> On Tue, Mar 19, 2024 at 02:28:12PM +0100, Jan Beulich wrote:
>>>> With a02174c6c885 ("amd/iommu: clean up unused guest iommu related
>>>> functions") having removed the sole place where d->g_iommu would be set
>>>> to non-NULL, guest_iommu_add_ppr_log() will unconditionally bail the
>>>> latest from its 2nd if(). With it dropped, all other stuff in the file
>>>> is unused, too. Delete iommu_guest.c altogether.
>>>>
>>>> Further delete struct guest{_buffer,_dev_table,_iommu{,_msi}} as well as
>>>> struct mmio_reg for being unused with the unused g_iommu also dropped
>>>> from struct arch_iommu.
>>>>
>>>> Signed-off-by: Jan Beulich 
> 
> Acked-by: Roger Pau Monné 

Thanks.

>>>> ---
>>>> I wasn't sure how far to further go with removing the body of
>>>> parse_ppr_log_entry(), or perhaps even the entire function, and then
>>>> further up to all PPR logging code. Hence why for now I've merely
>>>> commented out the function call into the file being deleted (which of
>>>> course Misra isn't going to like). Thoughts / suggestions?
>>>>
>>>> I further wonder whether set_iommu_guest_translation_control() should
>>>> have been invoked independent of guest-IOMMU actually being enabled. IOW
>>>> that may want purging, too. Along these lines iommuv2_enabled may also
>>>> want dropping, for not having any consumer left. Much like has_viommu()
>>>> and then also {XEN_,}X86_EMU_IOMMU, i.e. going as far as affecting the
>>>> public interface.
> 
> I would drop it all.  The public interface part is not stable anyway,
> as it's a domctl, but I would be fine if you want to keep the X86_EMU_IOMMU.

By "all" you also mean the PPR logging code? That's where I felt I might
be going too far ...

Jan


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 14:54:20 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 14:54:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695967.1086363 (Exim 4.92)
	(envelope-from )
	id 1rmxKW-0000Ht-Nv; Wed, 20 Mar 2024 14:54:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695967.1086363; Wed, 20 Mar 2024 14:54:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmxKW-0000Hm-Kq; Wed, 20 Mar 2024 14:54:12 +0000
Received: by outflank-mailman (input) for mailman id 695967;
 Wed, 20 Mar 2024 14:54:11 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmxKV-0000Hb-7d
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 14:54:11 +0000
Received: from EUR03-DBA-obe.outbound.protection.outlook.com
 (mail-dbaeur03on20600.outbound.protection.outlook.com
 [2a01:111:f403:260d::600])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b4a1fdeb-e6c9-11ee-afdd-a90da7624cb6;
 Wed, 20 Mar 2024 15:54:09 +0100 (CET)
Received: from AS9P194CA0011.EURP194.PROD.OUTLOOK.COM (2603:10a6:20b:46d::16)
 by AM0PR08MB5428.eurprd08.prod.outlook.com (2603:10a6:208:182::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.31; Wed, 20 Mar
 2024 14:54:07 +0000
Received: from AM4PEPF00027A62.eurprd04.prod.outlook.com
 (2603:10a6:20b:46d:cafe::42) by AS9P194CA0011.outlook.office365.com
 (2603:10a6:20b:46d::16) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.26 via Frontend
 Transport; Wed, 20 Mar 2024 14:54:07 +0000
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by
 AM4PEPF00027A62.mail.protection.outlook.com (10.167.16.71) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.7409.10 via Frontend Transport; Wed, 20 Mar 2024 14:54:05 +0000
Received: ("Tessian outbound 1b0f2681ce6f:v300");
 Wed, 20 Mar 2024 14:54:05 +0000
Received: from d754fdb2c57d.1
 by 64aa7808-outbound-1.mta.getcheckrecipient.com id
 C436C516-8FE6-4B24-A1B9-A44B352E6C09.1; 
 Wed, 20 Mar 2024 14:53:54 +0000
Received: from EUR05-AM6-obe.outbound.protection.outlook.com
 by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id d754fdb2c57d.1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384);
 Wed, 20 Mar 2024 14:53:54 +0000
Received: from AM0PR08MB3745.eurprd08.prod.outlook.com (2603:10a6:208:ff::27)
 by AM8PR08MB6596.eurprd08.prod.outlook.com (2603:10a6:20b:369::24)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.30; Wed, 20 Mar
 2024 14:53:52 +0000
Received: from AM0PR08MB3745.eurprd08.prod.outlook.com
 ([fe80::446b:ac86:e80c:ffda]) by AM0PR08MB3745.eurprd08.prod.outlook.com
 ([fe80::446b:ac86:e80c:ffda%6]) with mapi id 15.20.7386.023; Wed, 20 Mar 2024
 14:53:52 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b4a1fdeb-e6c9-11ee-afdd-a90da7624cb6
ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass;
 b=Glh/jMTCwEsf9H8bvSa+7EISz4zxzUIIFuXNf82WaTjrVOupZdRgnoT1N0b5gw/C6JG4VYl/ZaVWAhjOKaRfe70axPYV5DU80TyzCGxrDgVDCGtcTYt1oyTwEjCb9XT1Qty+HhHKyqZRilVC0nunGl3az6YIapFzgNsil93qfezFMAYeJef8GkVYN3VwheHgH6Zn+8oBMM+/74QYBOv1f2WT16oOmf+huZKGehu/uK989ORHt1KYzvwAv2bYewr3GO57V9LnAP/5uMBP+KoZA7/nt4eZ0toxv1RtXQjI7HFhcCm+YnBw2TqE7fagacu2whtDpk0u8aTLVVg3M/tZ8A==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=hCrHcLBUoBzKyfc/QzlK3Dv+hNOybDPb78n0FUH4GQ8=;
 b=IqoJZWiTIhv9z9iOCIroJ0IIj2aRlct0+SfjCvrENolGsDx0ASR97+tve5KtYNGccbOEO/RujxNHX/TDrwMShi0DhI/HuIcJlX0GxXUt8FB4cN1EuyLx3XtRPunCcbfMziWXGoUDzshh3RsP24sq3NlSBGcrsJWkVQmcQJPBLRUqE0YAqVJIfO8rjxsyHz1ZJpP0CowTAkpEHvTEUHzh0OMDbOPYZ6MGGHrwNu8H452XXbh2vn3u6c6JRsaD2EtfhexrPEgEaq1uZhW7kB7qXY7AqNUg0apxqevwQI//Tpd9md99y9QOnLtoYLo3sq9/Lo6todXFa1qp5cgVzZYk7w==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 63.35.35.123) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=arm.com;
 dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com;
 dkim=pass (signature was verified) header.d=armh.onmicrosoft.com; arc=pass (0
 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com]
 dmarc=[1,1,header.from=arm.com])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com;
 s=selector2-armh-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=hCrHcLBUoBzKyfc/QzlK3Dv+hNOybDPb78n0FUH4GQ8=;
 b=wUfiqwMdZBFd8lTWeeEzg9GtkGZtyXPyXGByA76c0638JYOAeczVilK7oSqatN1m2o/CLRvwobVOUEQgAhuw6OV4ppKrWiFcxNBStbU27a6Om0CiyTg7qSqL2eJk8Q5q4gpsjapRpiwPfr54R3EBRv1GU/zLcbilDHf+LjP9llo=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=armh.onmicrosoft.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 63.35.35.123 as permitted sender) receiver=protection.outlook.com;
 client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
 pr=C
X-CheckRecipientChecked: true
X-CR-MTA-CID: f28c292ed61c27ef
X-CR-MTA-TID: 64aa7808
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=iYgCk/sHmlQQC0Nn4XmWDFSO7NIwZB3zH/jltDSBskBCVrxuoW0RhzbrtubpLgdIMUSmSLp3fu8DkmWZJl2x1Xj/iPtzgCMEaasTlttM8F8nXRcId9xjy0tT4t6uJ03IjB1DswqoWBIXbLNAE8lArowoPzd7wMvB1zfo4jVlD5px3kUlghd7maPus6QEevJopE7y1rEw5L9/tMP+l41KIeId43rV7ohXcocgSroEEEQ+v1t1ayYFBn4cQKXb0HNKfA4Gx1QViIyaXKppbHKOG/KXVVP5o3UjCvte1yzHOr4KiTiz6EyosYM1jBrSmvUaRVPNzdQHNuI/Xa12EjCfbQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=hCrHcLBUoBzKyfc/QzlK3Dv+hNOybDPb78n0FUH4GQ8=;
 b=KLdtc+VjU8qryW2bhqsv8Nq4PvkabqjP7nQEkYbSf/O+iPwV+ehox0s23vdy4ky34YIqoieDSNZBHdFhpfk1UOQMdGhivNYjns2EcXz3uKfyP2VjrLnU7fk9QSKUryRtZSrUtXmkrYbTih/oZx7CEKZpAqrMUPEOsubZYIf5ofwuBkrA76D/S0Gf6JHSMkJt4hHcXwFOqyAkMy6LtuKQ9vH0qLcrieG6obN0deCUeQfTllTZXMXZEf3/z3x6m9kLy06xRDdK1MSXAG5vFsdHFTSbk/1yLp8fMcLEiVV/CzDmLqJ/2LvBN23O5gXv75xIk3celFW+/pXJXhFCgi9w3g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass
 header.d=arm.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com;
 s=selector2-armh-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=hCrHcLBUoBzKyfc/QzlK3Dv+hNOybDPb78n0FUH4GQ8=;
 b=wUfiqwMdZBFd8lTWeeEzg9GtkGZtyXPyXGByA76c0638JYOAeczVilK7oSqatN1m2o/CLRvwobVOUEQgAhuw6OV4ppKrWiFcxNBStbU27a6Om0CiyTg7qSqL2eJk8Q5q4gpsjapRpiwPfr54R3EBRv1GU/zLcbilDHf+LjP9llo=
From: Luca Fancellu 
To: Michal Orzel 
CC: Xen-devel , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Volodymyr Babchuk 
Subject: Re: [PATCH 06/11] xen/arm: Avoid code duplication in
 find_unallocated_memory
Thread-Topic: [PATCH 06/11] xen/arm: Avoid code duplication in
 find_unallocated_memory
Thread-Index: AQHadH3Zl0JABPg3OE+1Nn9HTjmokLFAgeKAgABB7YA=
Date: Wed, 20 Mar 2024 14:53:52 +0000
Message-ID: <280936E1-27DC-41FA-8E3B-080CA562A7B8@arm.com>
References: <20240312130331.78418-1-luca.fancellu@arm.com>
 <20240312130331.78418-7-luca.fancellu@arm.com>
 <3bd5d32c-d2e6-4e53-8b3e-aa7fdd058c71@amd.com>
In-Reply-To: <3bd5d32c-d2e6-4e53-8b3e-aa7fdd058c71@amd.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3774.400.31)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	AM0PR08MB3745:EE_|AM8PR08MB6596:EE_|AM4PEPF00027A62:EE_|AM0PR08MB5428:EE_
X-MS-Office365-Filtering-Correlation-Id: 164dfd0a-b1cd-4845-bf1b-08dc48ed96ec
x-checkrecipientrouted: true
nodisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted: BCL:0;
X-Microsoft-Antispam-Message-Info-Original:
 zyilVJM0ZpJlDC66fCpCUO8FX7tiqq9G8pRtn8WKvYfcPSUdFx1im5qkd4II91i27yb/lsLy9sWH6X7xl3sYfS5wMsMvaZRlo07Or35934vslBeTi28cIaSJRd7z0z/jUTh9kTMKWSGk2NGTGeDeFuMUzv7HNQpVQOum8pvrcQl1RyF1MeqyJN01HPRgI688kMCsbuFrItp1O8YRX/Pngzf1V1TU0/o92ShNSi9SWTSNPXt+kgZwcnBEtcwUEgSwkiPJQ9IhZyvtpSZUKsacVkOQ77cpju46C4k0sgyHasJCJqjU8XwNGNg9y3N1Vug4dRHSObeC9ZJzMgA64oZpWHzfa2nU1TFwYBP+pw54l8HAyGfbhJxl5MeiAWoFPg6dlw2g5ppZqqoNrSi9H84GdDc/EGyT676KINEl/94P1bRLFKwvAY/huBPD2dyYyKeLpzFNcIS/rO6PTRTvNLhkOznVjJfuI7lmhhoMgOVkTDSqy/KCLxxUsjq5g3Cix+YOr/hPsAokrXa+W6eGDiJ0m4fyCsNmVxBdF8ZWfNpN7w6/SHAHhMWYT8xI9QYmQJLLn2HQ5V+XFkwXmB3TnL8OlcnIjh9bmWYvqcokwsQ1ryXDtN+jjQ9fD+1k/n8L4QNlyiJrovKqjydIK/N2YBqodgfJkWpaNM8WtApmf3eimn8PR/4WBVCPaqIbExg6O/ueejxrWJh+K2tYRCfha4nwohUnlQhbkB51BsEGxvfYcLc=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM0PR08MB3745.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(366007)(1800799015)(376005)(38070700009);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="utf-8"
Content-ID: <8E386B88CDACA547BF5711B5964709FA@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR08MB6596
Original-Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 AM4PEPF00027A62.eurprd04.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	42a6296d-d8ff-4fb0-bde7-08dc48ed8ef0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	VKTE54e6JZ62d4TwE+JCBpOYs1mn/9HTx8p9cGunpAV4Abznsl103Ar/ibr3LWNb/SUb2PakNzCUL6djsDyZpTzcpo/XKNB+0+5IySHS0aunOOltxmnefxU1dXHdvwx3jjoaniaXg7gmu0W3ycFnmrAEMufhvjCWUPPeO9Hwm1JuOI+RhHL3oR1hTepxch+B8x3BCH75cb5EKBEcMK1kwdwB5ZuR77Zeo5reG/WZVEu2D/xR1Ikb+D3uWh9NgoXOKpJFBrmkTLZ90CuOB1A0+xMDj7c6Bv3MEN6P/wOm/3R2b2OTgp7HvuJtXCjWMQeFFDxIkC/ajf6paEpKKPC5gM16Pw/xD/xmW0mWx6RnMAEqVv7QWDM9KDclKdfcn9GaUcIylacyUaLaVISBWT1Zoug8WnDwncWQoo6yeNk3MU9zLe8BeoKaQjvhEHl3W9SSxCx1XoRQBNETbYjwS+e6nS4E++qsxin0nt1hf/zo8herK3k8LJfLlHcoyGzVl49xxUwsEagT8C6O8i2jhG7+EImhqerEnN2I/AGkDvb4XeDqmQfaoNmPRh/JPV0TQzRSmpfzQHPf9MVWKa1+4lgLFbZRK7IqP+Cm1d9PeR4/8tQ4fRLUjzkGwkW7ONh8Mb7l9mSao7Y+jijGj3u30JpGOHWWs7Mn0VTyeNOcHRI5L270aBEE4MMZ7DKgo6zMEgEIVcS0K2LfyQl4b9e0IpznK2eiPTTpLX2K3+Gr148lVD3AtQyUTG/aAp7A2pLoWpS/
X-Forefront-Antispam-Report:
	CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com;CAT:NONE;SFS:(13230031)(36860700004)(82310400014)(376005)(1800799015);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Mar 2024 14:54:05.5689
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 164dfd0a-b1cd-4845-bf1b-08dc48ed96ec
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-AuthSource:
	AM4PEPF00027A62.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB5428

DQoNCj4gT24gMjAgTWFyIDIwMjQsIGF0IDEwOjU3LCBNaWNoYWwgT3J6ZWwgPG1pY2hhbC5vcnpl
bEBhbWQuY29tPiB3cm90ZToNCj4gDQo+IEhpIEx1Y2EsDQo+IA0KPiBPbiAxMi8wMy8yMDI0IDE0
OjAzLCBMdWNhIEZhbmNlbGx1IHdyb3RlOg0KPj4gDQo+PiANCj4+IFRoZSBmdW5jdGlvbiBmaW5k
X3VuYWxsb2NhdGVkX21lbW9yeSBpcyB1c2luZyB0aGUgc2FtZSBjb2RlIHRvDQo+PiBsb29wIHRo
cm91Z2ggMyBzdHJ1Y3R1cmUgb2YgdGhlIHNhbWUgdHlwZSwgaW4gb3JkZXIgdG8gYXZvaWQNCj4+
IGNvZGUgZHVwbGljYXRpb24sIHJld29yayB0aGUgY29kZSB0byBoYXZlIG9ubHkgb25lIGxvb3Ag
dGhhdA0KPj4gZ29lcyB0aHJvdWdoIGFsbCB0aGUgc3RydWN0dXJlcy4NCj4+IA0KPj4gU2lnbmVk
LW9mZi1ieTogTHVjYSBGYW5jZWxsdSA8bHVjYS5mYW5jZWxsdUBhcm0uY29tPg0KPj4gLS0tDQo+
PiB4ZW4vYXJjaC9hcm0vZG9tYWluX2J1aWxkLmMgfCA2MiArKysrKysrKysrLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tDQo+PiAxIGZpbGUgY2hhbmdlZCwgMTcgaW5zZXJ0aW9ucygrKSwgNDUg
ZGVsZXRpb25zKC0pDQo+PiANCj4+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0vZG9tYWluX2J1
aWxkLmMgYi94ZW4vYXJjaC9hcm0vZG9tYWluX2J1aWxkLmMNCj4+IGluZGV4IGIyNTRmMjUyZTdj
Yi4uZDBmMmFjNjA2MGViIDEwMDY0NA0KPj4gLS0tIGEveGVuL2FyY2gvYXJtL2RvbWFpbl9idWls
ZC5jDQo+PiArKysgYi94ZW4vYXJjaC9hcm0vZG9tYWluX2J1aWxkLmMNCj4+IEBAIC04NjksMTIg
Kzg2OSwxNCBAQCBzdGF0aWMgaW50IF9faW5pdCBhZGRfZXh0X3JlZ2lvbnModW5zaWduZWQgbG9u
ZyBzX2dmbiwgdW5zaWduZWQgbG9uZyBlX2dmbiwNCj4+IHN0YXRpYyBpbnQgX19pbml0IGZpbmRf
dW5hbGxvY2F0ZWRfbWVtb3J5KGNvbnN0IHN0cnVjdCBrZXJuZWxfaW5mbyAqa2luZm8sDQo+PiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHJ1Y3QgbWVtYmFua3Mg
KmV4dF9yZWdpb25zKQ0KPj4gew0KPj4gLSAgICBjb25zdCBzdHJ1Y3QgbWVtYmFua3MgKmtpbmZv
X21lbSA9IGtlcm5lbF9pbmZvX2dldF9tZW0oa2luZm8pOw0KPj4gLSAgICBjb25zdCBzdHJ1Y3Qg
bWVtYmFua3MgKm1lbSA9IGJvb3RpbmZvX2dldF9tZW0oKTsNCj4+IC0gICAgY29uc3Qgc3RydWN0
IG1lbWJhbmtzICpyZXNlcnZlZF9tZW0gPSBib290aW5mb19nZXRfcmVzZXJ2ZWRfbWVtKCk7DQo+
PiArICAgIGNvbnN0IHN0cnVjdCBtZW1iYW5rcyAqbWVtX2JhbmtzW10gPSB7DQo+PiArICAgICAg
ICBib290aW5mb19nZXRfbWVtKCksDQo+PiArICAgICAgICBrZXJuZWxfaW5mb19nZXRfbWVtKGtp
bmZvKSwNCj4+ICsgICAgICAgIGJvb3RpbmZvX2dldF9yZXNlcnZlZF9tZW0oKSwNCj4+ICsgICAg
fTsNCj4+ICAgICBzdHJ1Y3QgcmFuZ2VzZXQgKnVuYWxsb2NfbWVtOw0KPj4gICAgIHBhZGRyX3Qg
c3RhcnQsIGVuZDsNCj4+IC0gICAgdW5zaWduZWQgaW50IGk7DQo+PiArICAgIHVuc2lnbmVkIGlu
dCBpLCBqOw0KPj4gICAgIGludCByZXM7DQo+PiANCj4+ICAgICBkdF9kcHJpbnRrKCJGaW5kIHVu
YWxsb2NhdGVkIG1lbW9yeSBmb3IgZXh0ZW5kZWQgcmVnaW9uc1xuIik7DQo+PiBAQCAtODgzLDUw
ICs4ODUsMjAgQEAgc3RhdGljIGludCBfX2luaXQgZmluZF91bmFsbG9jYXRlZF9tZW1vcnkoY29u
c3Qgc3RydWN0IGtlcm5lbF9pbmZvICpraW5mbywNCj4+ICAgICBpZiAoICF1bmFsbG9jX21lbSAp
DQo+PiAgICAgICAgIHJldHVybiAtRU5PTUVNOw0KPj4gDQo+PiAtICAgIC8qIFN0YXJ0IHdpdGgg
YWxsIGF2YWlsYWJsZSBSQU0gKi8NCj4+IC0gICAgZm9yICggaSA9IDA7IGkgPCBtZW0tPm5yX2Jh
bmtzOyBpKysgKQ0KPj4gLSAgICB7DQo+PiAtICAgICAgICBzdGFydCA9IG1lbS0+YmFua1tpXS5z
dGFydDsNCj4+IC0gICAgICAgIGVuZCA9IG1lbS0+YmFua1tpXS5zdGFydCArIG1lbS0+YmFua1tp
XS5zaXplOw0KPj4gLSAgICAgICAgcmVzID0gcmFuZ2VzZXRfYWRkX3JhbmdlKHVuYWxsb2NfbWVt
LCBQRk5fRE9XTihzdGFydCksDQo+PiAtICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
UEZOX0RPV04oZW5kIC0gMSkpOw0KPj4gLSAgICAgICAgaWYgKCByZXMgKQ0KPj4gLSAgICAgICAg
ew0KPj4gLSAgICAgICAgICAgIHByaW50ayhYRU5MT0dfRVJSICJGYWlsZWQgdG8gYWRkOiAlIyJQ
UklwYWRkciItPiUjIlBSSXBhZGRyIlxuIiwNCj4+IC0gICAgICAgICAgICAgICAgICAgc3RhcnQs
IGVuZCk7DQo+PiAtICAgICAgICAgICAgZ290byBvdXQ7DQo+PiAtICAgICAgICB9DQo+PiAtICAg
IH0NCj4+IC0NCj4+IC0gICAgLyogUmVtb3ZlIFJBTSBhc3NpZ25lZCB0byBEb20wICovDQo+PiAt
ICAgIGZvciAoIGkgPSAwOyBpIDwga2luZm9fbWVtLT5ucl9iYW5rczsgaSsrICkNCj4+IC0gICAg
ew0KPj4gLSAgICAgICAgc3RhcnQgPSBraW5mb19tZW0tPmJhbmtbaV0uc3RhcnQ7DQo+PiAtICAg
ICAgICBlbmQgPSBraW5mb19tZW0tPmJhbmtbaV0uc3RhcnQgKyBraW5mb19tZW0tPmJhbmtbaV0u
c2l6ZTsNCj4+IC0gICAgICAgIHJlcyA9IHJhbmdlc2V0X3JlbW92ZV9yYW5nZSh1bmFsbG9jX21l
bSwgUEZOX0RPV04oc3RhcnQpLA0KPj4gLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIFBGTl9ET1dOKGVuZCAtIDEpKTsNCj4+IC0gICAgICAgIGlmICggcmVzICkNCj4+ICsgICAg
Zm9yICggaSA9IDA7IGkgPCBBUlJBWV9TSVpFKG1lbV9iYW5rcyk7IGkrKyApDQo+PiArICAgICAg
ICBmb3IgKCBqID0gMDsgaiA8IG1lbV9iYW5rc1tpXS0+bnJfYmFua3M7IGorKyApDQo+IEl0IG1p
Z2h0IGJlIGEgbWF0dGVyIG9mIHBlcnNvbmFsIG9waW5pb24sIGJ1dCBJIHdvdWxkIGFjdHVhbGx5
IHByZWZlciB0aGUgY3VycmVudCBjb2RlDQo+IHRoYXQgbG9va3Mgc2ltcGxlci9uZWF0ZXIgKHRo
ZSBzdGVwcyBhcmUgY2xlYXIpIHRvIG1lLiBJJ2QgbGlrZSB0byBrbm93IG90aGVyIG1haW50YWlu
ZXJzIG9waW5pb24uDQoNCk9rLCBJ4oCZbGwgd2FpdCB0aGUgb3RoZXIgbWFpbnRhaW5lcnMgdGhl
biwgSeKAmW0gZ29pbmcgdG8gdXNlIHRoaXMgY29uc3RydWN0IGluIG90aGVyIHBhcnQNCm9mIHRo
ZSBjb2RlIHRvIHNpbXBsaWZ5IGFuZCByZW1vdmUgZHVwbGljYXRpb24gc28gaXQgd291bGQgYmUg
aW1wb3J0YW50IHRvIGtub3cgaWYNCkl04oCZcyBkZXNpcmFibGUgb3Igbm90Lg0KDQpNYXliZSB5
b3VyIG9waW5pb24gY291bGQgY2hhbmdlIHdpdGggYSBwcm9wZXIgY29tbWVudCBvbiB0b3Agb2Yg
dGhlIHN0cnVjdHVyZSBhbmQgdGhlIGxvb3AsDQpsaXN0aW5nIHRoZSBvcGVyYXRpb24gcGVyZm9y
bWVkIGluIG9yZGVyPw0KDQoxKSBTdGFydCB3aXRoIGFsbCBhdmFpbGFibGUgUkFNDQoyKSBSZW1v
dmUgUkFNIGFzc2lnbmVkIHRvIERvbTANCjMpIFJlbW92ZSByZXNlcnZlZCBtZW0NCjxsYXRlcj4N
CjQpIFJlbW92ZSBzdGF0aWMgc2hhcmVkIG1lbW9yeSByZWdpb25zDQoNCkNoZWVycywNCkx1Y2EN
Cg0KDQo+IA0KPiB+TWljaGFsDQoNCg==


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 14:55:35 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 14:55:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695970.1086373 (Exim 4.92)
	(envelope-from )
	id 1rmxLq-0000ry-4c; Wed, 20 Mar 2024 14:55:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695970.1086373; Wed, 20 Mar 2024 14:55:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmxLq-0000rr-23; Wed, 20 Mar 2024 14:55:34 +0000
Received: by outflank-mailman (input) for mailman id 695970;
 Wed, 20 Mar 2024 14:55:32 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmxLn-0000rh-Qa
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 14:55:31 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e4afc3c9-e6c9-11ee-a1ee-f123f15fe8a2;
 Wed, 20 Mar 2024 15:55:29 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [10.150.64.97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id AE6C234648;
 Wed, 20 Mar 2024 14:55:28 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 2A799136CD;
 Wed, 20 Mar 2024 14:55:27 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id l/P3N9/4+mWBSAAAD6G6ig
 (envelope-from ); Wed, 20 Mar 2024 14:55:27 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e4afc3c9-e6c9-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1710946528; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=atLlVj706ZI1z+w2Od3Pb5liz1wqI2QrZufnWv/g0fI=;
	b=lESLmDPR2Vg9ewi+NFqrwm00GWuh4+Zdr+TeU2s32ZkHVKiR6/7UTkZFBrLnjyer5llefC
	ebUQHB2JnuQyTzv8nLMLbyl4XBC7p4RVoTCdxAX+GbfxwthNEDWBBPf8kvldUQbhzk6Sp8
	qBrvzbG1B4fH2jJpriEZ4CxZpYXuceQ=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1710946528;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=atLlVj706ZI1z+w2Od3Pb5liz1wqI2QrZufnWv/g0fI=;
	b=CckUtufh1Nlld6V2VNOCsSQTwFG8xNe028kv8bHuHoiyjoYgUDKXm7crkS3LRlhg6b7jSC
	9cGpVZ8bvEOUvQAg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1710946528; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=atLlVj706ZI1z+w2Od3Pb5liz1wqI2QrZufnWv/g0fI=;
	b=lESLmDPR2Vg9ewi+NFqrwm00GWuh4+Zdr+TeU2s32ZkHVKiR6/7UTkZFBrLnjyer5llefC
	ebUQHB2JnuQyTzv8nLMLbyl4XBC7p4RVoTCdxAX+GbfxwthNEDWBBPf8kvldUQbhzk6Sp8
	qBrvzbG1B4fH2jJpriEZ4CxZpYXuceQ=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1710946528;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=atLlVj706ZI1z+w2Od3Pb5liz1wqI2QrZufnWv/g0fI=;
	b=CckUtufh1Nlld6V2VNOCsSQTwFG8xNe028kv8bHuHoiyjoYgUDKXm7crkS3LRlhg6b7jSC
	9cGpVZ8bvEOUvQAg==
From: Fabiano Rosas 
To: =?utf-8?Q?C=C3=A9dric?= Le Goater ,
 qemu-devel@nongnu.org, Stefano
 Stabellini , Anthony Perard
 , Paul Durrant , Paolo Bonzini
 , Richard Henderson ,
 Eduardo Habkost , "Michael S. Tsirkin"
 , Marcel Apfelbaum , Peter Xu
 , David Hildenbrand , Philippe
 =?utf-8?Q?Mathieu-Daud=C3=A9?= , Hyman Huang
 
Cc: Alex Williamson , Avihai Horon
 , Markus Armbruster , Prasad Pandit
 , =?utf-8?Q?C=C3=A9dric?= Le Goater
 ,
 xen-devel@lists.xenproject.org
Subject: Re: [PATCH for-9.1 v5 11/14] memory: Add Error** argument to the
 global_dirty_log routines
In-Reply-To: <20240320064911.545001-12-clg@redhat.com>
References: <20240320064911.545001-1-clg@redhat.com>
 <20240320064911.545001-12-clg@redhat.com>
Date: Wed, 20 Mar 2024 11:53:14 -0300
Message-ID: <87msqtlztx.fsf@suse.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -2.69
X-Spamd-Result: default: False [-2.69 / 50.00];
	 ARC_NA(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_ENVRCPT(0.00)[gmail.com];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 TAGGED_RCPT(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 BAYES_HAM(-2.89)[99.52%];
	 R_RATELIMIT(0.00)[to_ip_from(RL1oca9pgz4y56ab8sgtboxc4y)];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	 NEURAL_HAM_SHORT(-0.20)[-1.000];
	 RCPT_COUNT_TWELVE(0.00)[20];
	 DBL_BLOCKED_OPENRESOLVER(0.00)[citrix.com:email,xen.org:email,suse.de:email];
	 FREEMAIL_TO(0.00)[redhat.com,nongnu.org,kernel.org,citrix.com,xen.org,linaro.org,habkost.net,gmail.com,smartx.com];
	 FUZZY_BLOCKED(0.00)[rspamd.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 RCVD_TLS_ALL(0.00)[];
	 SUSPICIOUS_RECIPS(1.50)[]
X-Spam-Level: 
Authentication-Results: smtp-out1.suse.de;
	none
X-Spam-Flag: NO

C=C3=A9dric Le Goater  writes:

> Now that the log_global*() handlers take an Error** parameter and
> return a bool, do the same for memory_global_dirty_log_start() and
> memory_global_dirty_log_stop(). The error is reported in the callers
> for now and it will be propagated in the call stack in the next
> changes.
>
> To be noted a functional change in ram_init_bitmaps(), if the dirty
> pages logger fails to start, there is no need to synchronize the dirty
> pages bitmaps. colo_incoming_start_dirty_log() could be modified in a
> similar way.
>
> Cc: Stefano Stabellini 
> Cc: Anthony Perard 
> Cc: Paul Durrant 
> Cc: "Michael S. Tsirkin" 
> Cc: Paolo Bonzini 
> Cc: David Hildenbrand 
> Cc: Hyman Huang 
> Signed-off-by: C=C3=A9dric Le Goater 

Reviewed-by: Fabiano Rosas 


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 15:03:39 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 15:03:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695976.1086386 (Exim 4.92)
	(envelope-from )
	id 1rmxTW-0003EW-W1; Wed, 20 Mar 2024 15:03:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695976.1086386; Wed, 20 Mar 2024 15:03:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmxTW-0003EP-TJ; Wed, 20 Mar 2024 15:03:30 +0000
Received: by outflank-mailman (input) for mailman id 695976;
 Wed, 20 Mar 2024 15:03:29 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmxTV-0003EJ-Nb
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 15:03:29 +0000
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com
 [2a00:1450:4864:20::632])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 018470b4-e6cb-11ee-a1ee-f123f15fe8a2;
 Wed, 20 Mar 2024 16:03:27 +0100 (CET)
Received: by mail-ej1-x632.google.com with SMTP id
 a640c23a62f3a-a46dd7b4bcbso272054766b.3
 for ; Wed, 20 Mar 2024 08:03:27 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 q21-20020a1709066b1500b00a461e206c00sm7274324ejr.20.2024.03.20.08.03.26
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 20 Mar 2024 08:03:26 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 018470b4-e6cb-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710947007; x=1711551807; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=SQNVHZFsncPCPSiSxSLqtqmJ6Rqxjlg24dSv9FA1u2o=;
        b=K18i2MDfc6cMfeAY79oIyFebmvblQXQsLPOjSVIJpLNhYXpJN82GdUbq6vNn3+KcVk
         0LzCxQZYJcmOHRuC+XgMAVElPvoRmmV218/7R6rK+nnV/+qFA3b7D/P/TMh7njMo8rar
         SPyBVI4BNQ5YAkicLL3cPYm5rQZUhreytjrnCHR2DxKmv1chP1PcEn+v5DmzqBADzAEB
         PuaRizVvgn2f5b3SXhvSnZGU2amGYm1pMCgsvyMt/UiRRfCJ6jrF8+vgpLSlWjsQ6AQj
         KFhYX2Z1Sgh7boSR6pqh2uZ+7205yCsJlQECWNho3fnNZAvGkn32VNVCG2BHD7y+hTnS
         ZX+g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710947007; x=1711551807;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=SQNVHZFsncPCPSiSxSLqtqmJ6Rqxjlg24dSv9FA1u2o=;
        b=OJsZNJNwLtLsivhHm5aXyDvEZTF32sDZ43wwsxUmSDP7Qk87z8mPd5mFj70QKVNIsp
         ipuajiJt2oIXwLF0jqxrlordNdN64lvxMnAzJQVlxYvdlSD04DCVZwnAzsMwJ486k1XM
         RKLp+W8n+5y9qakCJLKGyiuU1Ka1xWv4YWCiWPU9XBqPnj4yjB0TQ46meqJE1KItdwtK
         WCzsqljhTuXH9gsugt2IDUbj0hkwOLjLkkhUoL0ZXmIrrUozOdblZn/aT2oH8KG3SlKM
         VYfneSDWUm4XSzZg9dr2/XuaIRRHxUFn30QnuhQQRe5c0TNK0rwgr0OzCf39hUs1uExi
         oYsw==
X-Forwarded-Encrypted: i=1; AJvYcCWjDcac4c8NRrVv7AiQBkFIjwNVSe/EKPHRHmEffo7quu2dp0zyIiMXaXcm82nrJCBZEXSlCcszOE+H9US5e8Pj67/ppWwdIvHrUwoMxYU=
X-Gm-Message-State: AOJu0YwaHycQ+0unbk4TJlW/K7mKXGX86vhSvxiqI40jOBMtJqnFLfAS
	OjuGqLCoVkEU982gAA1iC8fs4WHzpBRu9857SiO3eEfECtfGJXxJEfHMXaDbpw==
X-Google-Smtp-Source: AGHT+IHK5jJxCTXHqo9EqsI06I/eeu8pdPC7SV2UQayJbYLECbFfgziQNe+HhqVzG5VLOQKSh9dhYg==
X-Received: by 2002:a17:907:7f87:b0:a46:a9db:1471 with SMTP id qk7-20020a1709077f8700b00a46a9db1471mr9172150ejc.16.1710947006822;
        Wed, 20 Mar 2024 08:03:26 -0700 (PDT)
Message-ID: 
Date: Wed, 20 Mar 2024 16:03:25 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/vcpu: relax VCPUOP_initialise restriction for non-PV
 vCPUs
Content-Language: en-US
To: Andrew Cooper ,
 Roger Pau Monne 
Cc: George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 xen-devel@lists.xenproject.org
References: <20240320135720.68894-1-roger.pau@citrix.com>
 <1304a0d2-ff17-4823-9d31-c32eb7b79f30@citrix.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <1304a0d2-ff17-4823-9d31-c32eb7b79f30@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 20.03.2024 15:06, Andrew Cooper wrote:
> On 20/03/2024 1:57 pm, Roger Pau Monne wrote:
>> There's no reason to force HVM guests to have a valid vcpu_info area when
>> initializing a vCPU, as the vCPU can also be brought online using the local
>> APIC, and on that path there's no requirement for vcpu_info to be setup ahead
>> of the bring up.  Note an HVM vCPU can operate normally without making use of
>> vcpu_info.
>>
>> Restrict the check against dummy_vcpu_info to only apply to PV guests.
>>
>> Fixes: 192df6f9122d ('x86: allow HVM guests to use hypercalls to bring up vCPUs')
>> Signed-off-by: Roger Pau Monné 
> 
> Thanks for looking into this.  But, do we actually need to force this on
> PV either?
> 
> The only interesting user of dummy_vcpu_info now is vcpu_info_populate()
> which can cope with any arbitrary vCPU.

Why would that be the only interesting user? If we were to ...

> I have a suspicion that we can (now) delete these two checks, delete the
> dummy_vcpu_info object, and use a regular NULL pointer in
> vcpu_info_{populate,reset}(), and in doing so, remove one of the bigger
> pieces of PV-absurdity from Xen.

... use NULL pointers instead, we'd need to audit all Xen's vcpu_info
accesses for properly avoiding to de-reference that NULL. The dummy
struct instance was really meant as a safety belt (besides also acting
as a sentinel).

> I can entirely believe that this is only safe to do with Jan's physical
> registration changes in place.

Which nobody uses just yet, afaik.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 15:05:43 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 15:05:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695978.1086396 (Exim 4.92)
	(envelope-from )
	id 1rmxVd-0003u6-Ae; Wed, 20 Mar 2024 15:05:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695978.1086396; Wed, 20 Mar 2024 15:05:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmxVd-0003tz-7u; Wed, 20 Mar 2024 15:05:41 +0000
Received: by outflank-mailman (input) for mailman id 695978;
 Wed, 20 Mar 2024 15:05:40 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmxVb-0003tt-Tw
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 15:05:39 +0000
Received: from mail-oa1-x32.google.com (mail-oa1-x32.google.com
 [2001:4860:4864:20::32])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4f72e27d-e6cb-11ee-afdd-a90da7624cb6;
 Wed, 20 Mar 2024 16:05:39 +0100 (CET)
Received: by mail-oa1-x32.google.com with SMTP id
 586e51a60fabf-222b6a05bb1so2798092fac.3
 for ; Wed, 20 Mar 2024 08:05:39 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4f72e27d-e6cb-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1710947137; x=1711551937; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=BJxegO5jY0m50eRvyJ6Rn52tnRBA4pRISA0GV0hamew=;
        b=aYB9Eoh4vxFHp5dkSEJZYW8RJUnM7bq6/dZCliWsMelgUvAd3wkJa5/2Z6FBflrCdb
         pMdPku2aLXeTV3yPXP3d+coD+J2huBBOH4OaGFmGjm2V3rnZffwQ5PeO3AzD4kT6CEr8
         QCb3CR8457nWowhQHC5V1/3C9eeBrowzCFO+o=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710947137; x=1711551937;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=BJxegO5jY0m50eRvyJ6Rn52tnRBA4pRISA0GV0hamew=;
        b=NmU7FC+Wo3KL8/YyO41BsPCiAfj+rhvqcdaSZ1q+HhcuGFJS3+IPIsUMFtJGXRBVou
         wDeJ4c6bjlSeelzuW1cmHDWe2Trkt3WtJmzOrMfwt1efNem30ZumNIeJm+5aqJDhvAlG
         j5zxFsJKDezac2+Y6qnnDoBGOlqESeA+5j3TGp5uL11S66LW9DniQJbeGh5G6uyIoyL6
         1pCxmQrcmysQIb4igl6gX+5EYwx48e0cPaRskVqKSJUCsy1wFpCXJW+o5eItRV5SmUpA
         Mx4npY3b2uW90nNAvQpns8FKbfeMZIZva0uk9BXfgMryxEDfy6e47lKBDUfZ+xsulx+8
         lzEg==
X-Gm-Message-State: AOJu0YzrgRwFwciB3Eg7/7JJI8x4+AmdLAZr36Zb+6BH96Q35917GgZs
	SuPqisezPXCvfpJTrV6JQzp3TqlmNI0le6kVrUb1PcM4tq+pMe9Xt7+wa3/lNbc/4cGZkMnN6pG
	+tBYunMCOgXJfv+gKp0z1pIB0gWDcO6QeGI+byQ==
X-Google-Smtp-Source: AGHT+IEjJLHsK1QNPng+l2IFJvjPqlg89PHWi6Wfe2pgMdmMaaTx47H0J5Cl6qrIavYl2WwQ1nwdjO+fDH3J2hgXiKo=
X-Received: by 2002:a05:6871:3a22:b0:220:f92f:5bf7 with SMTP id
 pu34-20020a0568713a2200b00220f92f5bf7mr19845707oac.50.1710947137569; Wed, 20
 Mar 2024 08:05:37 -0700 (PDT)
MIME-Version: 1.0
References: <20240318163552.3808695-1-andrew.cooper3@citrix.com>
 <20240318163552.3808695-3-andrew.cooper3@citrix.com> 
In-Reply-To: 
From: George Dunlap 
Date: Wed, 20 Mar 2024 15:05:26 +0000
Message-ID: 
Subject: Re: [PATCH 2/7] xen/credit2: Clean up trace handling
To: Andrew Cooper 
Cc: Xen-devel , Jan Beulich , 
	Dario Faggioli , George Dunlap , 
	Stefano Stabellini , Julien Grall , 
	Nicola Vetrini , 
	"consulting @ bugseng . com" 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Mar 20, 2024 at 12:16=E2=80=AFPM George Dunlap  wrote:
>
> On Mon, Mar 18, 2024 at 4:36=E2=80=AFPM Andrew Cooper  wrote:
> >
> > There is no need for bitfields anywhere - use more sensible types.  The=
re is
> > also no need to cast 'd' to (unsigned char *) before passing it to a fu=
nction
> > taking void *.  Switch to new trace_time() API.
> >
> > No functional change.
>
> Hey Andrew -- overall changes look great, thanks for doing this very
> detailed work.

For my own posterity later:

I've done a close review of the rest of the patch and didn't see any
issues other than the loss of sign in a handful of cases.

 -George


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 15:09:41 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 15:09:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695981.1086406 (Exim 4.92)
	(envelope-from )
	id 1rmxZR-0004lU-PB; Wed, 20 Mar 2024 15:09:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695981.1086406; Wed, 20 Mar 2024 15:09:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmxZR-0004lN-Me; Wed, 20 Mar 2024 15:09:37 +0000
Received: by outflank-mailman (input) for mailman id 695981;
 Wed, 20 Mar 2024 15:09:36 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmxZQ-0004lH-IP
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 15:09:36 +0000
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com
 [2a00:1450:4864:20::62d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id dce8ffa3-e6cb-11ee-afdd-a90da7624cb6;
 Wed, 20 Mar 2024 16:09:35 +0100 (CET)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-a467d8efe78so760849466b.3
 for ; Wed, 20 Mar 2024 08:09:35 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 u7-20020a17090626c700b00a46e56b181bsm1799100ejc.4.2024.03.20.08.09.34
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 20 Mar 2024 08:09:34 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: dce8ffa3-e6cb-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710947375; x=1711552175; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=5fWkWPnMdhkSD8eYem4ijP7X1u7JNbqBHCtvSL7Uxeo=;
        b=VKS9PFvLCBrkQhsikGJZKJQMj6VgAZFmOOLU22PMeRVRvEIrLQTN4rssBBnk7rlP5R
         X4rcYo0CORP51nFVuEqD5n2q2cO3ZtdflnIZNiLZMxizGlihDBr3/StO+LqYP/AvmIiq
         cOPT5j6kLruvsQRS6Y7U2PiE2QPwlxefm0rb/HOU3BaRGei4YMNoWem0mLtM5eUI+AKn
         6qwMYMXd2jHXlUDS806bGN1zjHeOqrKlm6p5AxRc/+nN4krBx+n/1IA5Vgx0ZOgfLSwY
         8w9ylsTRiUHwOVNzypOXCgiKFzPmNJnzs3KArXkq7vs0MPZ2gNLAA6sAh5oSKRaWRiqZ
         y+cg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710947375; x=1711552175;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=5fWkWPnMdhkSD8eYem4ijP7X1u7JNbqBHCtvSL7Uxeo=;
        b=uRAobbsZBJmJ9VauA5hrskkLh1r2I0fhP7/inwxzV9WeA46WnNLf6D839sTU5pcIfj
         LmwYqoqpPgAs8liE2eFjrCmd+2d+JnDRl+lXu4YPNV5HiOiEZoEybslQG54FUqRraUvw
         4sNda7c78cs7FDBt5vEMskdPi+C/una+hclPUse3nCQAlX6oyvnzJ7nmYobY3giVqE5A
         PnEJ6B/vt/R0XTgFulq5Zx7TJqLfMtERLAT2tgjtadxtZskvu1e3cwHLUjez5IirIxkH
         rtFOZ+V4cRbnlUD7XllEeAYj9KOab5acipsDCsduzrcjemNF4tZYs/nkOsd0ngv6G0nW
         JV9A==
X-Forwarded-Encrypted: i=1; AJvYcCUg43n0UVR7OrFV4sMLkSzHvOTAtnXVCbcPyzh7Lh/MHDvQ24FlZf74aQWhaJMt4GlBT7SdEuZhA2CE1K/+J16PTosUt7PeJcoh2GFuQY0=
X-Gm-Message-State: AOJu0YyCE7MeSD29/a53tLBtcZjWpL0CAx47j2HwpV4H2Pn5z5s+iWEe
	Q+JiEEIKbtePFt11AZBJJJicCCo7zbXCkh/0kBKePTs11O3hsGpcJBY9hRXdnA==
X-Google-Smtp-Source: AGHT+IF6AdUYewFCcc9PdxDShniczEzSSWIGGS8subtQtPMt8KhqvrhhM8q4+/K9xVvLQqJwemNaJg==
X-Received: by 2002:a17:906:124b:b0:a46:8846:5aa0 with SMTP id u11-20020a170906124b00b00a4688465aa0mr4536995eja.56.1710947374911;
        Wed, 20 Mar 2024 08:09:34 -0700 (PDT)
Message-ID: <73314dc5-0145-4aa7-a3cd-23c943235392@suse.com>
Date: Wed, 20 Mar 2024 16:09:33 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/vcpu: relax VCPUOP_initialise restriction for non-PV
 vCPUs
Content-Language: en-US
To: Roger Pau Monne 
Cc: Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 xen-devel@lists.xenproject.org
References: <20240320135720.68894-1-roger.pau@citrix.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240320135720.68894-1-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 20.03.2024 14:57, Roger Pau Monne wrote:
> There's no reason to force HVM guests to have a valid vcpu_info area when
> initializing a vCPU, as the vCPU can also be brought online using the local
> APIC, and on that path there's no requirement for vcpu_info to be setup ahead
> of the bring up.  Note an HVM vCPU can operate normally without making use of
> vcpu_info.

While I'd agree if you started with "There's no real need to force ...", I
still think there is a reason: If one wants to use paravirt interfaces (i.e.
hypercalls), they would better do so consistently. After all there's also
no need to use VCPUOP_initialise, yet you're not disabling its use.

As said in reply to Andrew's reply, besides acting as a sentinel that
structure instance also acts as a sink for Xen accesses to a vCPU's
vcpu_info. By removing the check, you switch that from being a safeguard to
being something that actually has to be expected to be accessed. Unless
you've audited all uses to prove that no such access exists.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 15:11:39 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 15:11:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695983.1086417 (Exim 4.92)
	(envelope-from )
	id 1rmxbO-0006kR-43; Wed, 20 Mar 2024 15:11:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695983.1086417; Wed, 20 Mar 2024 15:11:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmxbO-0006kK-1C; Wed, 20 Mar 2024 15:11:38 +0000
Received: by outflank-mailman (input) for mailman id 695983;
 Wed, 20 Mar 2024 15:11:36 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmxbM-0006io-Q7
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 15:11:36 +0000
Received: from mail-oa1-x2e.google.com (mail-oa1-x2e.google.com
 [2001:4860:4864:20::2e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 22ae35b7-e6cc-11ee-a1ee-f123f15fe8a2;
 Wed, 20 Mar 2024 16:11:33 +0100 (CET)
Received: by mail-oa1-x2e.google.com with SMTP id
 586e51a60fabf-2228c4c5ac3so9964fac.0
 for ; Wed, 20 Mar 2024 08:11:33 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 22ae35b7-e6cc-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1710947492; x=1711552292; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=0244I174yMserW4WriQI6+VQN+aADe3FDH8sxYcaRVU=;
        b=LWjzwIHXSjarJ3W041k4CIeeMHg6GGTw9CKYIQDvk+ZOn6nMPA1Sk5gfu+48xw1xCx
         0Upbmvm8yu91In04Do6c5GTM6Pgf9qdIRfNdVJFHtkFbwFA8IN6eliz3AyHChpfBXWja
         IXtdrA0FN8/zfaoPHMmX1T0h1cg+KNKzuorw4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710947492; x=1711552292;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=0244I174yMserW4WriQI6+VQN+aADe3FDH8sxYcaRVU=;
        b=IQRzBKVMzoqTHaOtn+rLZ/sdyTUpmqiOEXskkm6R6aYmmOAOMFgJ/M7R8m94+f+0DV
         sDDn81uO67mRgP6QjsafQ2WZdtmA/POOwPjnmqthmqaABdWNrXvRGyvPeFwq/T20CRKC
         tV9JNGY09W4NresxXtmutBNCakCuWKWbaLGoal8szC0zbtcjG3rduUXxnJFQw5iaTbMF
         6HGQZlhQZY798eiyi6DzB7Y4p9awSZDozpb07s/Z1QLMkJE0DAt2TMNFgbbPTXmvDiIY
         Z+P+fVC9M2abwLxME5mDN5f1VD3PxsY8kO1MgO+ANMWb/veRo6QjdqoIcpj4yYkw/9BO
         7t1Q==
X-Gm-Message-State: AOJu0YyjPHvGoL00TFYOQ58Wdn7r58/PQhe9jGuFqWcNnZeeSCaF2up1
	0k8qODOXycnxy24ErAbt3yjxliDnJH+EBmX2oK2EjyQcEX85aBZ3TZK9l2f2HXR038am45ZqmLl
	Si52VBgOzLsSFJeP6aedHum7jb1b1L+157wwX5A==
X-Google-Smtp-Source: AGHT+IH40+yX7ezao7mg8F4/9jENJs125mNUqMN9d3TgA6J1IhEGts0e38thHUw8oGuntYx1JoTNzFUi7BTFbXL2WmY=
X-Received: by 2002:a05:6871:7406:b0:222:4bde:fede with SMTP id
 nw6-20020a056871740600b002224bdefedemr22520812oac.13.1710947491914; Wed, 20
 Mar 2024 08:11:31 -0700 (PDT)
MIME-Version: 1.0
References: <20240318163552.3808695-1-andrew.cooper3@citrix.com> <20240318163552.3808695-4-andrew.cooper3@citrix.com>
In-Reply-To: <20240318163552.3808695-4-andrew.cooper3@citrix.com>
From: George Dunlap 
Date: Wed, 20 Mar 2024 15:11:21 +0000
Message-ID: 
Subject: Re: [PATCH 3/7] xen/rt: Clean up trace handling
To: Andrew Cooper 
Cc: Xen-devel , Dario Faggioli , 
	George Dunlap , Jan Beulich , 
	Stefano Stabellini , Julien Grall , 
	Nicola Vetrini , 
	"consulting @ bugseng . com" 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Mar 18, 2024 at 4:36=E2=80=AFPM Andrew Cooper  wrote:
>
> Most uses of bitfields and __packed are unnecessary.  There is also no ne=
ed to
> cast 'd' to (unsigned char *) before passing it to a function taking void=
 *.
> Switch to new trace_time() API.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper 
> Reviewed-by: Dario Faggioli 

Reviewed-by: George Dunlap 


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 15:19:08 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 15:19:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695989.1086426 (Exim 4.92)
	(envelope-from )
	id 1rmxiX-0007k2-UH; Wed, 20 Mar 2024 15:19:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695989.1086426; Wed, 20 Mar 2024 15:19:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmxiX-0007jt-RN; Wed, 20 Mar 2024 15:19:01 +0000
Received: by outflank-mailman (input) for mailman id 695989;
 Wed, 20 Mar 2024 15:19:00 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmxiW-0007jn-ID
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 15:19:00 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.133.124])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2c25b0d5-e6cd-11ee-afdd-a90da7624cb6;
 Wed, 20 Mar 2024 16:18:58 +0100 (CET)
Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com
 [209.85.219.72]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-516-VJeJH2OhPzS6Mj8uCoEixw-1; Wed, 20 Mar 2024 11:18:56 -0400
Received: by mail-qv1-f72.google.com with SMTP id
 6a1803df08f44-69152af7760so10847076d6.1
 for ; Wed, 20 Mar 2024 08:18:56 -0700 (PDT)
Received: from x1n ([99.254.121.117]) by smtp.gmail.com with ESMTPSA id
 gi6-20020a056214248600b0069068161388sm7946153qvb.131.2024.03.20.08.18.53
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 20 Mar 2024 08:18:54 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2c25b0d5-e6cd-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1710947937;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=s2DvitvJUAGQ+uBsIXNwcAKXy9/+kL0SU0v8MLPW744=;
	b=cbPI//N5XDlJFtuAdFX937qVYzi2C1kchSodgU1j2LIsH82MWq2dlBiVIPLYAAQKuw32M6
	F47imKviw18OCt3R8nTFMFVooJ0blk82Ul/zNjte3v1x+CzxWv3srvqWCuKWfSdHWISdog
	XLvui1+v7T3qQN7ILufm5IpRm3I7a94=
X-MC-Unique: VJeJH2OhPzS6Mj8uCoEixw-1
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710947935; x=1711552735;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=s2DvitvJUAGQ+uBsIXNwcAKXy9/+kL0SU0v8MLPW744=;
        b=VyR1r4CVDnX+qT6xMtSNcoH8kGLLGlK4Fs9VJQTvE8dPfSaYQVZe5OcVHb2XXFGub9
         BhUaTpApvGXAukvhN9cNcrht+yYud7GbH+Sq4tD9gXgiK678j8imW+12mQtZj5NMsB05
         dZy21KdAUJi2woWY+0Cpgh5seobYEIcWLsa5S91KFS5p/rMndJBjVMVx/wk0xwmLIbzB
         VdTAmximhpMR3NaoXNbQb2qzhMbNlwTOuhR8lQfA3lQdkctdiUuQKuME8pve/wYpIs2s
         /1TKHcxlr47xcCRRCatlQuLxYO5PJvFjgVm5vBOeIYU81f7dKxb0fv/X2gu/NGOfdj6K
         EXlQ==
X-Forwarded-Encrypted: i=1; AJvYcCVPiSX06fQMajNphkLaWm8vnsAXln+fCClvLw4dfAhbPK1pSN2QVNw4VxeX3DmRUFiaDlm7GjZKf1zNrwdiDNFwrVfM9vf/Rsv0pkE6ekw=
X-Gm-Message-State: AOJu0YwDzEFcz0+CV5OANt2kiF0Xzhugw4UkpDrRd97vK+XKLEcdwMbJ
	rYrTalAKy+IZuqGyKC1qK95CUSEmmPM8r+q1LzlwdVuaXLJFMaotgQ/CYIqnQzZ/nWOtzYwFq5q
	XOpduCRxnxrUiuS9xNBofvIprFmNEVm69zsYpAwlBYlMb1CLpYFmMfKpSCH6Ks0HK
X-Received: by 2002:a05:6214:2c0a:b0:691:ca1:ce8a with SMTP id qq10-20020a0562142c0a00b006910ca1ce8amr17165769qvb.6.1710947935427;
        Wed, 20 Mar 2024 08:18:55 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IHbL7zZQNMBAIJ0oNJjyY75oTWKW14gtRa4+lC6J/hUqhi8KWup2nqqLGWT4/foNMc/P4lVhQ==
X-Received: by 2002:a05:6214:2c0a:b0:691:ca1:ce8a with SMTP id qq10-20020a0562142c0a00b006910ca1ce8amr17165742qvb.6.1710947934926;
        Wed, 20 Mar 2024 08:18:54 -0700 (PDT)
Date: Wed, 20 Mar 2024 11:18:51 -0400
From: Peter Xu 
To: =?utf-8?Q?C=C3=A9dric?= Le Goater 
Cc: qemu-devel@nongnu.org, Stefano Stabellini ,
	Anthony Perard ,
	Paul Durrant , Paolo Bonzini ,
	Richard Henderson ,
	Eduardo Habkost ,
	"Michael S. Tsirkin" ,
	Marcel Apfelbaum ,
	David Hildenbrand ,
	Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= ,
	Hyman Huang ,
	Fabiano Rosas ,
	Alex Williamson ,
	Avihai Horon ,
	Markus Armbruster ,
	Prasad Pandit ,
	xen-devel@lists.xenproject.org,
	Hailiang Zhang 
Subject: Re: [PATCH for-9.1 v5 11/14] memory: Add Error** argument to the
 global_dirty_log routines
Message-ID: 
References: <20240320064911.545001-1-clg@redhat.com>
 <20240320064911.545001-12-clg@redhat.com>
MIME-Version: 1.0
In-Reply-To: <20240320064911.545001-12-clg@redhat.com>
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

On Wed, Mar 20, 2024 at 07:49:07AM +0100, Cédric Le Goater wrote:
> Now that the log_global*() handlers take an Error** parameter and
> return a bool, do the same for memory_global_dirty_log_start() and
> memory_global_dirty_log_stop(). The error is reported in the callers
> for now and it will be propagated in the call stack in the next
> changes.
> 
> To be noted a functional change in ram_init_bitmaps(), if the dirty
> pages logger fails to start, there is no need to synchronize the dirty
> pages bitmaps. colo_incoming_start_dirty_log() could be modified in a
> similar way.
> 
> Cc: Stefano Stabellini 
> Cc: Anthony Perard 
> Cc: Paul Durrant 
> Cc: "Michael S. Tsirkin" 
> Cc: Paolo Bonzini 
> Cc: David Hildenbrand 
> Cc: Hyman Huang 
> Signed-off-by: Cédric Le Goater 

Just to mention that for the rest users (dirtylimit/dirtyrate/colo) the
code still just keeps going even if start logging failed even after this
series applied as a whole.  Migration framework handles the failure
gracefully, not yet the rest.

That might be an issue for some, e.g., ideally we should be able to fail a
calc-dirty-rate request, but it's not supported so far.  Adding that could
add quite some burden to this series, so maybe that's fine to be done
later.  After all, having a VFIO device (that can fail a start_log()), plus
any of those features should be even rarer, I think?

It seems at least memory_global_dirty_log_sync() can be called even without
start logging, so I expect nothing should crash immediately. I spot one in
colo_incoming_start_dirty_log() already of such use.  My wild guess is it
relies on all log_sync*() hooks to cope with it, e.g. KVM ioctl() should
fail with -ENENT on most archs I think when it sees dirty log not ever
started.

For those bits, I'll wait and see whether Yong or Hailiang (cced) has any
comments. From generic migration/memory side, nothing I see wrong:

Acked-by: Peter Xu 

Thanks,

-- 
Peter Xu



From xen-devel-bounces@lists.xenproject.org Wed Mar 20 15:19:33 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 15:19:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695991.1086437 (Exim 4.92)
	(envelope-from )
	id 1rmxj3-0008LT-6H; Wed, 20 Mar 2024 15:19:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695991.1086437; Wed, 20 Mar 2024 15:19:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmxj3-0008LM-2s; Wed, 20 Mar 2024 15:19:33 +0000
Received: by outflank-mailman (input) for mailman id 695991;
 Wed, 20 Mar 2024 15:19:32 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmxj2-0008Eu-7m
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 15:19:32 +0000
Received: from mail-oa1-x31.google.com (mail-oa1-x31.google.com
 [2001:4860:4864:20::31])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3f27473d-e6cd-11ee-a1ee-f123f15fe8a2;
 Wed, 20 Mar 2024 16:19:30 +0100 (CET)
Received: by mail-oa1-x31.google.com with SMTP id
 586e51a60fabf-221a9e5484aso19363fac.0
 for ; Wed, 20 Mar 2024 08:19:30 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3f27473d-e6cd-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1710947969; x=1711552769; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Bu393cTx6QvaMvwbGbEh7W8EIbEAY62y8lPrC2ykeBM=;
        b=bc5VTf54J6AqfSojIGwAJUR9ryiAdUbpI4lTNqar0ZR5TBnX6FxDes9BrD32jr5X4E
         Hld3rEvX/F0M0dYkUOwhTyH3i9JzUVFO7mAc9/68AoOGPYVsvjTh5r5JNV3tQkLoMuLz
         yGEEq9f33Ank8ERYuZwtYRHR3h8Ff8Twn0EkU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710947969; x=1711552769;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=Bu393cTx6QvaMvwbGbEh7W8EIbEAY62y8lPrC2ykeBM=;
        b=aIv4FHQHmp56uUkQ3BUus1lp2NQ9RhcxQWE6cnF504IliRq1c3w4PkpAUNbrXkNI7v
         U3Bv8ytvzFGae5qHto4pZ3heCPFBXmbeLSCSLWjntRIEwlO5kFSg67KbHQsFxOmzaNvs
         TfieYJpm2aMyPk8q2vqLZ++RYJT/4EV3CM1dB/XiwS9AxRFe3rJxFN0KeV7c6WdoE+g2
         3tOS1RbqNVsT6VR791wbTfWeh9LCzAgDwcTW/hRSUJhStn8TwzYLIjmPuUUhbQLJr5bg
         PgblRXULuWEjtTP+0jN2QHSQDcwSBZsbH6hFu5hUm66CUB77/dI8JZJ0udbN5P3iNETR
         Ia9Q==
X-Gm-Message-State: AOJu0Yz+1fTzn+W+LENQmosCBpVUbEOywjAr1pHQmzlGLs1zhcj7HTBa
	HPaEqKwS9VU0T1STDLQ3G2ebOFia9vN56+J+11OSt0Km0ObXOpusY9nBgB6JaKN+jvcL7IcYFN4
	DTcbod48WSxvcGUoCJsBkByb2QItB3C4QEB/SsA==
X-Google-Smtp-Source: AGHT+IEi82yqno5eBgA7Sujeg4SmVLKEcvZEIkHLOAkysCPR+Wh9kv0Qhujv5MSeA2P1sJjbB1P1jXi7drly7b4Pg8c=
X-Received: by 2002:a05:6870:510:b0:221:8a03:6dea with SMTP id
 j16-20020a056870051000b002218a036deamr18679533oao.38.1710947969216; Wed, 20
 Mar 2024 08:19:29 -0700 (PDT)
MIME-Version: 1.0
References: <20240318163552.3808695-1-andrew.cooper3@citrix.com> <20240318163552.3808695-5-andrew.cooper3@citrix.com>
In-Reply-To: <20240318163552.3808695-5-andrew.cooper3@citrix.com>
From: George Dunlap 
Date: Wed, 20 Mar 2024 15:19:18 +0000
Message-ID: 
Subject: Re: [PATCH 4/7] xen/sched: Clean up trace handling
To: Andrew Cooper 
Cc: Xen-devel , Dario Faggioli , 
	George Dunlap , Jan Beulich , 
	Stefano Stabellini , Julien Grall , 
	Nicola Vetrini , 
	"consulting @ bugseng . com" 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Mar 18, 2024 at 4:36=E2=80=AFPM Andrew Cooper  wrote:
>
> There is no need for bitfields anywhere - use more sensible types.  There=
 is
> also no need to cast 'd' to (unsigned char *) before passing it to a func=
tion
> taking void *.  Switch to new trace_time() API.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper 
> Reviewed-by: Dario Faggioli 

Reviewed-by: George Dunlap 


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 15:20:07 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 15:20:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695993.1086446 (Exim 4.92)
	(envelope-from )
	id 1rmxja-0001JN-Ds; Wed, 20 Mar 2024 15:20:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695993.1086446; Wed, 20 Mar 2024 15:20:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmxja-0001JG-An; Wed, 20 Mar 2024 15:20:06 +0000
Received: by outflank-mailman (input) for mailman id 695993;
 Wed, 20 Mar 2024 15:20:05 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmxjZ-0008Eu-4N
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 15:20:05 +0000
Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com
 [2607:f8b0:4864:20::730])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 52f22566-e6cd-11ee-a1ee-f123f15fe8a2;
 Wed, 20 Mar 2024 16:20:03 +0100 (CET)
Received: by mail-qk1-x730.google.com with SMTP id
 af79cd13be357-789f50b3e40so81798885a.1
 for ; Wed, 20 Mar 2024 08:20:03 -0700 (PDT)
Received: from localhost ([85.31.135.62]) by smtp.gmail.com with ESMTPSA id
 jf14-20020a0562142a4e00b00690afbf56d5sm7875091qvb.66.2024.03.20.08.20.01
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 20 Mar 2024 08:20:02 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 52f22566-e6cd-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710948002; x=1711552802; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=AHbkqahN1wSn0BiQYUnDUhVtbBjifYZuCyICyoeS01Y=;
        b=cTQFv0FtELFhQQEcK5ilPzZdN0gcCgnXccVSDkiSQtPPBFWgdpNO2w1KMTYvfLWHSR
         M8pnie9/Kf2rHmNBVutMuN872x0Qa9Z5XcvGdpy67xtqQQgBrVqnlF0e7SOKcw8pPVEc
         hw8mYelvLIdRyIfqD1Q98r++c4RXbVr5FZGO4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710948002; x=1711552802;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=AHbkqahN1wSn0BiQYUnDUhVtbBjifYZuCyICyoeS01Y=;
        b=tOXh3bKRc2DoeGncpT5PMzdJm7PEB3dLtDm69Z8vdeeKqWiO6c+SGImbizBzNEwHKy
         tX4UcifNrweAR9mtiYnq2yb7GGV3Zzs2TYy/DSzJD14ZPVGPZQvu/mJAUVUn0fb/gUph
         3ryJvfaoKzPTNh/a5zMjyYxPPDwiNwwRg/gdSHn8zJKaA18CVUb27s59rCNCj9JClidt
         vAkVDuiwIFY+jq8gIiuCr5Rfxs49PKDzCYC1XAF3mBecFV5JyaK7ro5JwzriNagAc4Bx
         7jJAGpdZOwyWsqjDmiGx4l7oSzW9i7M81XSohy87CO89L8zYtEu9nAQQi5LFQx003fQA
         Z3jQ==
X-Gm-Message-State: AOJu0YyovUlQrYfXoZfbGPcnK6HrPiG4Gl8dxg3qRD+pz60J3jogH7Fu
	IoUN1n7FLBm2FuACDSM1jbAaruyAPR9Qda8+8o/SB4Q+t7QaSA8B76sa0awHMSM=
X-Google-Smtp-Source: AGHT+IHLPITz3dcd5Ofgn3kQkXvFDtliG5Ej/74OJiimgL312cvmYzgGI3XSlq2N4z5dqGyH4Z3m5Q==
X-Received: by 2002:a05:6214:401c:b0:68f:b825:9255 with SMTP id kd28-20020a056214401c00b0068fb8259255mr166122qvb.22.1710948002367;
        Wed, 20 Mar 2024 08:20:02 -0700 (PDT)
Date: Wed, 20 Mar 2024 16:20:00 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Anthony PERARD 
Cc: xen-devel@lists.xenproject.org
Subject: Re: [OSSTEST PATCH 02/36] ts-xen-build-prep: Only force git protocol
 v2 on buster
Message-ID: 
References: <20240318165545.3898-1-anthony.perard@citrix.com>
 <20240318165545.3898-3-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20240318165545.3898-3-anthony.perard@citrix.com>

On Mon, Mar 18, 2024 at 04:55:11PM +0000, Anthony PERARD wrote:
> Newer version of Debian and thus git would use this automatically, no
> need to force it.
> 
> Signed-off-by: Anthony PERARD 
> ---
>  Osstest/TestSupport.pm | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
> index f0e087aa..0dded9b2 100644
> --- a/Osstest/TestSupport.pm
> +++ b/Osstest/TestSupport.pm
> @@ -3257,7 +3257,7 @@ END
>  
>      # Adding mandadory use of Git protocol v2
>      # necessary on buster when building QEMU v8.1
> -    $gitcfg .= < +    $gitcfg .= <{Suite} =~ m/buster/;
>  [protocol]
>  	version = 2

Do we need to limit ourselves to version 2 for the git cache stuff, or
that doesn't matter?

I'm wondering whether it case version 3 of the protocol appears we
would be in trouble by not having version = 2 in the config file.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 15:20:56 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 15:20:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.695995.1086457 (Exim 4.92)
	(envelope-from )
	id 1rmxkN-00029a-NL; Wed, 20 Mar 2024 15:20:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 695995.1086457; Wed, 20 Mar 2024 15:20:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmxkN-00029T-Jb; Wed, 20 Mar 2024 15:20:55 +0000
Received: by outflank-mailman (input) for mailman id 695995;
 Wed, 20 Mar 2024 15:20:54 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmxkM-00029L-CP
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 15:20:54 +0000
Received: from mail-qv1-xf2c.google.com (mail-qv1-xf2c.google.com
 [2607:f8b0:4864:20::f2c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 70bf8469-e6cd-11ee-afdd-a90da7624cb6;
 Wed, 20 Mar 2024 16:20:53 +0100 (CET)
Received: by mail-qv1-xf2c.google.com with SMTP id
 6a1803df08f44-696499bd61eso189686d6.0
 for ; Wed, 20 Mar 2024 08:20:53 -0700 (PDT)
Received: from [10.80.67.139] (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 z17-20020a056214041100b0068ff8d75a90sm7993670qvx.19.2024.03.20.08.20.50
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 20 Mar 2024 08:20:51 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 70bf8469-e6cd-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710948052; x=1711552852; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=vOTF6kZ6FBZD7tJjnyTBwctBC1Fk5qrha5m3WONRLsY=;
        b=tOHkJk/25oHwluShufOOseob1bwId5MOXuE1tPZd95uEFOm8dcxBW3wDeQNRvW9/Dd
         l/A3Jkx0ZnfEy6Znw+CSvHyFTgNxrZDWX0UXLph69fDjJheBo1vWJ9UmtF9W/jMpMs/X
         DwxRUnImKqjxNTGoz57bcluzu0AqSQxfTxJyM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710948052; x=1711552852;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=vOTF6kZ6FBZD7tJjnyTBwctBC1Fk5qrha5m3WONRLsY=;
        b=Kuov6weloAxHexOrM5wXsf8f4ndUlJ/rtyUH40ArIxTM4GLzr9ya7VwPvsGAkb9YoC
         iRL2LGHDomhr0HL9JalTWSSLPQpraK/cvKypIXijIoriSb0B4Si/La4aOqkf2q+y/fnt
         wbt5AAX8E/H2aVgwBFenRMp5zv0vvkul8k3SWpBKTXpAnf4ghtzXx9Xk/eeGY+uAWtnk
         UAOhn9v7+dYAKAY599L1S7Bk/hEEOifyqx6/5VWl5Gw7ZhO6l9W1NlI1gYWcDDVgD7cy
         PyLsvOloDAH6tWEwNo/1UCKjIe/StLptf72t0kMv7mFYRPNn7cNo4aAfPYJkwXfZFD/R
         FaKg==
X-Forwarded-Encrypted: i=1; AJvYcCWh6d6Mj13JoRTp/Noh5c8G/86/xRazlj/HyrOoYzB/zycl7jlaUB2SKYjojiQk+0liHAsNTqZJ8akJAQHFpd2AD1ebhfhYSbAyzt3F67E=
X-Gm-Message-State: AOJu0YzyLbgeRlI0OA1z3Yph8rQ46Ol0wDbCIYf79YAB7Bov23sj6MSj
	Gwm/0NM3X1vcVhm397AnIXUuo/4rTSOYsGRNNIEj/ieliSgDbuUWJmKwIWoGBY8=
X-Google-Smtp-Source: AGHT+IE4GloOEz89snQBSYYTt9HxFold1Das25+/WLQUyu+o/v20u8saDBzrzBs+z+S2KLgxnrV96w==
X-Received: by 2002:a0c:dc14:0:b0:696:22ae:eb67 with SMTP id s20-20020a0cdc14000000b0069622aeeb67mr5462127qvk.33.1710948052418;
        Wed, 20 Mar 2024 08:20:52 -0700 (PDT)
Message-ID: 
Date: Wed, 20 Mar 2024 15:20:49 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/vcpu: relax VCPUOP_initialise restriction for non-PV
 vCPUs
Content-Language: en-GB
To: Jan Beulich , Roger Pau Monne 
Cc: George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 xen-devel@lists.xenproject.org
References: <20240320135720.68894-1-roger.pau@citrix.com>
 <73314dc5-0145-4aa7-a3cd-23c943235392@suse.com>
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <73314dc5-0145-4aa7-a3cd-23c943235392@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 20/03/2024 3:09 pm, Jan Beulich wrote:
> On 20.03.2024 14:57, Roger Pau Monne wrote:
>> There's no reason to force HVM guests to have a valid vcpu_info area when
>> initializing a vCPU, as the vCPU can also be brought online using the local
>> APIC, and on that path there's no requirement for vcpu_info to be setup ahead
>> of the bring up.  Note an HVM vCPU can operate normally without making use of
>> vcpu_info.
> While I'd agree if you started with "There's no real need to force ...", I
> still think there is a reason: If one wants to use paravirt interfaces (i.e.
> hypercalls), they would better do so consistently. After all there's also
> no need to use VCPUOP_initialise, yet you're not disabling its use.

I firmly disagree.

There are good reasons to use VCPUOP_initialise over INIT-SIPI-SIPI
(like avoiding 16bit mode - in the case we want it here, to fix APIC_ID
enumeration in a way that doesn't involve putting more complexity into
HVMLoader), and forcing us to set up a useless structure before we can
boot vCPU number 32 is just wrong.

It was dumb to design a hypercall like this in the first place for PV
guests, and it definitely isn't OK to keep guests broken because of it.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 15:30:23 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 15:30:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696001.1086466 (Exim 4.92)
	(envelope-from )
	id 1rmxtR-0004rZ-Ho; Wed, 20 Mar 2024 15:30:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696001.1086466; Wed, 20 Mar 2024 15:30:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmxtR-0004rS-FB; Wed, 20 Mar 2024 15:30:17 +0000
Received: by outflank-mailman (input) for mailman id 696001;
 Wed, 20 Mar 2024 15:30:16 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmxtQ-0004pR-33
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 15:30:16 +0000
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com
 [2a00:1450:4864:20::52a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id bf974059-e6ce-11ee-afdd-a90da7624cb6;
 Wed, 20 Mar 2024 16:30:14 +0100 (CET)
Received: by mail-ed1-x52a.google.com with SMTP id
 4fb4d7f45d1cf-568a53d2ce0so8646401a12.0
 for ; Wed, 20 Mar 2024 08:30:14 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 g14-20020a170906198e00b00a46d049ff63sm2795901ejd.21.2024.03.20.08.30.13
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 20 Mar 2024 08:30:14 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: bf974059-e6ce-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710948614; x=1711553414; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=VApuDQqrgJvlwg9vBixJseS5JxGZrA4GOg7tCwIYp50=;
        b=N5vTfkdBEqO0/UmaQI43YE2msaKEgawKsBWBMmiynCgRSwB4k62WK6OBxQBGwHRcYG
         /xkR5BXg0lvPWW++UCcuSbeVbu+9sUAHISLt8iJLnERdlsHAXH9aBheT6ycmoqjaAGlp
         +sYkQ6j3LGv4xBmN4guDdK+uBYkkkwDADezKssDEJME+Qk6fO74EV/P5zkkC39FOuECH
         E8LxtslbDB4Ugs+whm4MmZTc3z0mXBH1OIAdjaoDtOtt5Mv8VOnRahXy60oU15yXtBbL
         x2kkLRAJUJ9P6iTaM0gt0dOSnEyy1O3VYyEjum1yQ3aWc0ZlrZwaNcP6PQStc3IO7wXt
         cCbQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710948614; x=1711553414;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=VApuDQqrgJvlwg9vBixJseS5JxGZrA4GOg7tCwIYp50=;
        b=XPM7UoDb1t7Ezlhjx6a6YxbVAfjPybmTPMJ0xPTt9qE13rdrmYbY8zhIqzZLxkWQHV
         WLnvTXus/9lWTIJ4NXDKPDJJnoafo7V2sF7K36cVnTJ4Z5L0i86lr1XXZs+4L9qnop4/
         yIy5cAFa+IQ8Z9SomU4ehSzkXxeTjBTs3B53YW+9IME4UbAndX0f0/7+5hmvp2cw+MsB
         98nBpO2CdPSgjjc1p+1Da450/NohtJ94FUxcrjEKZKHBl376C6rfCNmY66bNpIP+xR5O
         SH3KT1uHFW5pbpcxByYp+gmrMQO05HCj2VC7X21FMnM8SS5JODOR86sUeitUCpIVwjMJ
         zbDQ==
X-Forwarded-Encrypted: i=1; AJvYcCXZoRWsaKXyyNJtBxxshTndiUqbWKZqCO/t74PY0HNo/S4QlH2CNj95kDneo3UqPXdWOQMU04zW6pGz1hpfZf8S7CsxOcN8ZHtivqlsboQ=
X-Gm-Message-State: AOJu0YxWmaje9Vu5uMhvKacDAVdndXEVVQL3Vd7B9QknZbxEav7rrG+d
	1C+iWDRRnLkR9Mhr5rxw1u6cvfDvLgzRR/nBoWpYd1GR7HiaXBvQkvtu14DOow==
X-Google-Smtp-Source: AGHT+IFAXmqkup65W+d2WEBHewlDJCDwRawBfEuFXa3BWXr+TKrRNA2v9pUYN9Rk03v+h0Gux4aq+g==
X-Received: by 2002:a17:906:34ca:b0:a46:1d4b:d81 with SMTP id h10-20020a17090634ca00b00a461d4b0d81mr11170474ejb.62.1710948614309;
        Wed, 20 Mar 2024 08:30:14 -0700 (PDT)
Message-ID: 
Date: Wed, 20 Mar 2024 16:30:12 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 04/20] xen/asm-generic: introduce generic non-atomic
 test_*bit()
Content-Language: en-US
To: Oleksii Kurochko 
Cc: Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 xen-devel@lists.xenproject.org
References: 
 <48b7dfafccc7a0ed814b5dfb0f109a0473a1b4b4.1710517542.git.oleksii.kurochko@gmail.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <48b7dfafccc7a0ed814b5dfb0f109a0473a1b4b4.1710517542.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 15.03.2024 19:06, Oleksii Kurochko wrote:
> The patch introduces the following generic functions:
> * test_bit
> * generic___test_and_set_bit
> * generic___test_and_clear_bit
> * generic___test_and_change_bit
> 
> Also, the patch introduces the following generics which are
> used by the functions mentioned above:
> * BITOP_BITS_PER_WORD
> * BITOP_MASK
> * BITOP_WORD
> * BITOP_TYPE
> 
> These functions and macros can be useful for architectures
> that don't have corresponding arch-specific instructions.
> 
> Signed-off-by: Oleksii Kurochko 

First of all: How much syncing has there been versus Andrew's plans?
I don't want to end up in the middle of two entirely different
approaches to the same generalization goal.

> --- /dev/null
> +++ b/xen/include/asm-generic/bitops/bitops-bits.h
> @@ -0,0 +1,21 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _ASM_GENERIC_BITOPS_BITS_H_
> +#define _ASM_GENERIC_BITOPS_BITS_H_
> +
> +#ifndef BITOP_BITS_PER_WORD
> +#define BITOP_BITS_PER_WORD     32
> +#endif
> +
> +#ifndef BITOP_MASK
> +#define BITOP_MASK(nr)          (1U << ((nr) % BITOP_BITS_PER_WORD))
> +#endif
> +
> +#ifndef BITOP_WORD
> +#define BITOP_WORD(nr)          ((nr) / BITOP_BITS_PER_WORD)
> +#endif
> +
> +#ifndef BITOP_TYPE
> +typedef uint32_t bitops_uint_t;
> +#endif

Is it of practical use to permit overriding of one of BITOP_TYPE and
BITOP_BITS_PER_WORD? I think both want tying together.

Is it further of any use to allow overriding of BITOP_{MASK,WORD}?
There's minimal generalization needed to allow an override of
BITOP_TYPE, though:

#define BITOP_MASK(nr)          ((bitop_uint_t)1 << ((nr) % BITOP_BITS_PER_WORD))

Note that I've omitted the 's' from the typedef name - the macros
all having no 'S', imo the type also shouldn't (or the other way
around).

> --- /dev/null
> +++ b/xen/include/asm-generic/bitops/generic-non-atomic.h
> @@ -0,0 +1,89 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * The file is based on Linux ( 6.4.0 ) header:
> + *   include/asm-generic/bitops/generic-non-atomic.h
> + * 
> + * Only functions that can be reused in Xen were left; others were removed.
> + * 
> + * Also, the following changes were done:
> + *  - it was updated the message inside #ifndef ... #endif.
> + *  - __always_inline -> always_inline to be align with definition in
> + *    xen/compiler.h.
> + *  - update function prototypes from
> + *    generic___test_and_*(unsigned long nr nr, volatile unsigned long *addr) to
> + *    generic___test_and_*(unsigned long nr, volatile void *addr) to be

What's the point of having a whopping 3 successive inner underscores?
Which btw ...

> + *    consistent with other related macros/defines.
> + *  - convert identations from tabs to spaces.
> + *  - inside generic__test_and_* use 'bitops_uint_t' instead of 'unsigned long'
> + *    to be generic.

... shrink to just 2 here.

Oh, and there's no generic__test_bit(), but just test_bit() in a separate
header.

> + */
> +
> +#ifndef __ASM_GENERIC_BITOPS_GENERIC_NON_ATOMIC_H
> +#define __ASM_GENERIC_BITOPS_GENERIC_NON_ATOMIC_H
> +
> +#include 
> +
> +#include 
> +
> +#ifndef XEN_BITOPS_H
> +#error only  can be included directly
> +#endif
> +
> +/*
> + * Generic definitions for bit operations, should not be used in regular code
> + * directly.
> + */
> +
> +/**
> + * generic___test_and_set_bit - Set a bit and return its old value
> + * @nr: Bit to set
> + * @addr: Address to count from
> + *
> + * This operation is non-atomic and can be reordered.
> + * If two examples of this operation race, one can appear to succeed
> + * but actually fail.  You must protect multiple accesses with a lock.
> + */
> +static always_inline bool
> +generic___test_and_set_bit(unsigned long nr, volatile void *addr)
> +{
> +    bitops_uint_t mask = BITOP_MASK(nr);
> +    bitops_uint_t *p = ((bitops_uint_t *)addr) + BITOP_WORD(nr);

If you cast away the volatile here, what's the point of having it in
the parameter declaration? Also such a cast doesn't need an outer
pair of parentheses.

> +    bitops_uint_t old = *p;
> +
> +    *p = old | mask;
> +    return (old & mask) != 0;

Minor: The function returning bool, the "!= 0" (and then also the
parentheses) could be omitted.

> --- /dev/null
> +++ b/xen/include/asm-generic/bitops/test-bit.h
> @@ -0,0 +1,18 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _ASM_GENERIC_BITOPS_TESTBIT_H_
> +#define _ASM_GENERIC_BITOPS_TESTBIT_H_
> +
> +#include 
> +
> +/**
> + * test_bit - Determine whether a bit is set
> + * @nr: bit number to test
> + * @addr: Address to start counting from
> + */
> +static inline int test_bit(int nr, const volatile void *addr)
> +{
> +    const volatile bitops_uint_t *p = addr;
> +    return 1 & (p[BITOP_WORD(nr)] >> (nr & (BITOP_BITS_PER_WORD - 1)));
> +}

Interestingly you don't lose the volatile here. Overall the way this
is written would likely benefit the other functions too. There's no
cast needed here and thus also not there.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 15:39:16 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 15:39:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696007.1086480 (Exim 4.92)
	(envelope-from )
	id 1rmy23-00069f-GY; Wed, 20 Mar 2024 15:39:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696007.1086480; Wed, 20 Mar 2024 15:39:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmy23-00069Y-DR; Wed, 20 Mar 2024 15:39:11 +0000
Received: by outflank-mailman (input) for mailman id 696007;
 Wed, 20 Mar 2024 15:39:09 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmy21-000682-CF
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 15:39:09 +0000
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com
 [2a00:1450:4864:20::62a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id fd806087-e6cf-11ee-afdd-a90da7624cb6;
 Wed, 20 Mar 2024 16:39:08 +0100 (CET)
Received: by mail-ej1-x62a.google.com with SMTP id
 a640c23a62f3a-a46d0a8399aso185282366b.1
 for ; Wed, 20 Mar 2024 08:39:08 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 dt22-20020a170906b79600b00a4669f6c2e2sm7364250ejb.44.2024.03.20.08.39.07
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 20 Mar 2024 08:39:07 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: fd806087-e6cf-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710949148; x=1711553948; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=sr6KrqljbfsGwtYhah3+YpUsKXZC0JiQScbtLwgpKMA=;
        b=AmvcJXE3+t0IWNXnJ05zkpD0x9U/zvCDy93ubcVlMIhQIyTiw8t8c5hgjbYFdY196H
         rKx4daNBuqBCBjpFE8iEMy+Im4MvUWipKX3jEThtet3rPrliY5qIimHDxoqWm5ZhTfcv
         Glns/E4HcBx8kXg+Dd7iuUes5+EezvghhllaTzoO+WcXttCdQUl3QGHsOnhMumkDP4YS
         MxQyXYfwL8mJUD0lskY0/UBK38c/kFMvp+tc10f1+9s/Fcwl3B1+piMnAcvQva3FPa41
         zX3B2l0Oln8+d31xDwIT/YPfDDvgjCBd4ENfMxcCPK8ZcTzxzLjwlWDefGSqR9+Grq2f
         ilTw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710949148; x=1711553948;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=sr6KrqljbfsGwtYhah3+YpUsKXZC0JiQScbtLwgpKMA=;
        b=hpO9/+A4gbH6CghePF+1A9k/pt1VwaBL9UGSxqBAhQ12zBH7DtTHnbJwTvM3qV6tgz
         kBoJZSkBJiYURx73K1kfRgR8wWoriCf3Bdf2wG4nLT3o3QWUFk8pEP1lBtCpArJ6pywv
         BJLe16EXEfz9ySJZnbJGgcwW4Ih5IkREv9ZHPLPg3D/WFJUNWZ5MpIFsFBxz0oyiLJb8
         cP7/Jhvs7Xdp1H5Sgz9cHvjiimI3f10ljoWsLo09OTeMoMI4xsvR4vsMZhWN7AxN8Vcs
         m++VM+HaWkQHdEEZL76fWuBtgKv8k59wqIJV5Uo0JMAk2mdr8eyzGgoezesuFnR5r/wd
         rOgA==
X-Forwarded-Encrypted: i=1; AJvYcCXwyfDAnCa58iDQQ7ym6vV5qXWvb2awQyPnId9neLSQcqt8Na2oqSnfTPlB0amfkHkunqYmNB6fVwMuuAo4YA1Cy555BJSsFalS0A9MFig=
X-Gm-Message-State: AOJu0YyM7FR1TfKx09JlvAXlZ4cenwXgGVWcS/2tAUY66D1dlSnVlx0z
	XkFZHO2Rz4fkioTBdlMxT5WRvSkTuFCT/sJ/CfKBPmYTJqqZDpAD3tVkwD9ijQ==
X-Google-Smtp-Source: AGHT+IFsBa/nkQrm62YC41Vb9H8Z9+gkCInx2JlJdqtODLldg4dLfA5Pt6yPyq+Mt8F6S7wI8neiZg==
X-Received: by 2002:a17:907:76c5:b0:a45:f9c5:3024 with SMTP id kf5-20020a17090776c500b00a45f9c53024mr37350ejc.11.1710949147752;
        Wed, 20 Mar 2024 08:39:07 -0700 (PDT)
Message-ID: <0f1dccc2-ef5e-40de-91de-c5ba70a09c42@suse.com>
Date: Wed, 20 Mar 2024 16:39:06 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 05/20] xen/bitops: implement fls{l}() in common logic
Content-Language: en-US
To: Oleksii Kurochko 
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 George Dunlap , Wei Liu ,
 Shawn Anastasio ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: 
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 15.03.2024 19:06, Oleksii Kurochko wrote:
> Return type was left 'int' because of the following compilation error:
> 
> ./include/xen/kernel.h:18:21: error: comparison of distinct pointer types lacks a cast [-Werror]
>        18 |         (void) (&_x == &_y);            \
>           |                     ^~
>     common/page_alloc.c:1843:34: note: in expansion of macro 'min'
>      1843 |         unsigned int inc_order = min(MAX_ORDER, flsl(e - s) - 1);
> 
> generic_fls{l} was used instead of __builtin_clz{l}(x) as if x is 0,
> the result in undefined.
> 
> Signed-off-by: Oleksii Kurochko 

Assuming Andrew's pending change goes in as posted, I'm okay with this to
(as simply following suit). Without that having happened, I can't very
well offer an ack here. Just one nit:

> --- a/xen/include/xen/bitops.h
> +++ b/xen/include/xen/bitops.h
> @@ -69,6 +69,30 @@ static inline int generic_flsl(unsigned long x)
>  
>  #include 
>  
> +static always_inline __pure int fls(unsigned int x)
> +{
> +    if (__builtin_constant_p(x))

Style (missing blanks immediately inside the parentheses), also again ...

> +        return generic_fls(x);
> +
> +#ifndef arch_fls
> +#define arch_fls generic_fls
> +#endif
> +
> +    return arch_fls(x);
> +}
> +
> +static always_inline __pure int flsl(unsigned long x)
> +{
> +    if (__builtin_constant_p(x))

... here.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 15:42:07 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 15:42:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696010.1086490 (Exim 4.92)
	(envelope-from )
	id 1rmy4r-0008JT-T9; Wed, 20 Mar 2024 15:42:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696010.1086490; Wed, 20 Mar 2024 15:42:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmy4r-0008JM-QO; Wed, 20 Mar 2024 15:42:05 +0000
Received: by outflank-mailman (input) for mailman id 696010;
 Wed, 20 Mar 2024 15:42:04 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmy4q-0008JC-Ub
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 15:42:04 +0000
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com
 [2a00:1450:4864:20::536])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 65d1cb2a-e6d0-11ee-afdd-a90da7624cb6;
 Wed, 20 Mar 2024 16:42:03 +0100 (CET)
Received: by mail-ed1-x536.google.com with SMTP id
 4fb4d7f45d1cf-56b8e4f38a2so3187020a12.3
 for ; Wed, 20 Mar 2024 08:42:03 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 h6-20020a1709060f4600b00a468be342bfsm6185503ejj.136.2024.03.20.08.42.02
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 20 Mar 2024 08:42:02 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 65d1cb2a-e6d0-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710949323; x=1711554123; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=jbwI7wpXLk3zANzvhdPkPLuSuz1KVcG4KeWWJSNch8k=;
        b=XtgQaTxnUJcaoXQMtomi9mkZHwePBiKTthLb/LJDi+eTPjle0Ef9HeGXddTQjOLGgE
         c/V4LJPxn94fX+RjSnxNSa9qiCX4FjmwQJ4oTZIvSYTD8k5UM1b3BSP65pLVZOrkWOPL
         DNqRRITUXfa457FOxbaOnjj/0fw8AZuXa4XClMgfZ/hKR+1XVr8ZY+Aj1GFCQN59Gou6
         awC7YqiO2Pz8AMB5twY39dDp1hYKskvFKgJQYOUUHVdIOToPl7vR6ruryEwuY0eSi3Xl
         g2eL7tQnrfkFajnVEvi7Ev+CqvYOO7FUn07xSBRp0e/NxixG5dMJZHcKTbRgnG4Sej61
         5u1w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710949323; x=1711554123;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=jbwI7wpXLk3zANzvhdPkPLuSuz1KVcG4KeWWJSNch8k=;
        b=G94fSNxH42iaz91IF5msE9VOxw5Nr+wO5MLUvxGt3fvs/sWqeveWtx/eWK5jQY8tIF
         3vm0ra2BEneSkMvn9kulHIjt5p4PSUDbMHe4xJ8LHRO/PEySziUyHDOKzIK+TrsJMgdQ
         hpHGB6fjn93DsCtGSCn3P8t4x2OyFcf8y2KrwEESP+B5+ZlKuG6PoaDMKUhsN/B6fsk7
         9UE8QMnk9lYDzxS1eif0KCf3C7INT3XyD7fbJ6C7IjykZu4r/Rn6Zm1DsoQEbwLbFph7
         vhytGP3VoHgw85+2MuvT6s5FEujt8hkyZAArj99lg7S1LGD13HSdvQxOHbIYeEmvMFx8
         17DQ==
X-Forwarded-Encrypted: i=1; AJvYcCXGuU7ZUR7bDXeYiCL1jOkxH/8aKKUxWCCELpu6rxYgQiqkZk33MOXYATwlTzG7K5wCO1PRihmPzhb60trdflXe9Ld0MJmE+p96HnVdrjQ=
X-Gm-Message-State: AOJu0Yxu8k64czPsvoMEnXl/ScetT+FGzrMuHAaQj4CCyu0dwCakGTG6
	g2Ryd/Hc4qE5Uo3DEbrnxCs0YM33ef17Ky5gYNfTK9w4ZsahtU6/Ie+7AxJEWA==
X-Google-Smtp-Source: AGHT+IFBRSI7o5yP8EJ/68uDpNtxpyEhTm1yrWvIbgXoozKtKOfQptqYzmH9TP3fogHqV61kUtqKcQ==
X-Received: by 2002:a17:906:6d59:b0:a46:e595:f357 with SMTP id a25-20020a1709066d5900b00a46e595f357mr3247536ejt.9.1710949322734;
        Wed, 20 Mar 2024 08:42:02 -0700 (PDT)
Message-ID: 
Date: Wed, 20 Mar 2024 16:42:01 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 06/20] xen/bitops: put __ffs() and ffz() into linux
 compatible header
Content-Language: en-US
To: Oleksii Kurochko 
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 George Dunlap , Wei Liu ,
 Shawn Anastasio ,
 Rahul Singh , xen-devel@lists.xenproject.org
References: 
 <8bc35da4a9fd44d2dcf9677dcc99334eb7142581.1710517542.git.oleksii.kurochko@gmail.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <8bc35da4a9fd44d2dcf9677dcc99334eb7142581.1710517542.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 15.03.2024 19:06, Oleksii Kurochko wrote:
> --- a/xen/lib/find-next-bit.c
> +++ b/xen/lib/find-next-bit.c
> @@ -9,6 +9,7 @@
>   * 2 of the License, or (at your option) any later version.
>   */
>  #include 
> +#include 
>  
>  #include 

Hmm, no, a library source would better not include this header. Surely
the ffz() can be taken care of locally here?

Jan


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 15:46:32 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 15:46:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696012.1086499 (Exim 4.92)
	(envelope-from )
	id 1rmy95-0000Sn-D2; Wed, 20 Mar 2024 15:46:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696012.1086499; Wed, 20 Mar 2024 15:46:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmy95-0000Sg-AL; Wed, 20 Mar 2024 15:46:27 +0000
Received: by outflank-mailman (input) for mailman id 696012;
 Wed, 20 Mar 2024 15:46:26 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmy94-0000Sa-CT
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 15:46:26 +0000
Received: from mail-oa1-x31.google.com (mail-oa1-x31.google.com
 [2001:4860:4864:20::31])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0116bcba-e6d1-11ee-a1ee-f123f15fe8a2;
 Wed, 20 Mar 2024 16:46:24 +0100 (CET)
Received: by mail-oa1-x31.google.com with SMTP id
 586e51a60fabf-222c0572eedso11800fac.3
 for ; Wed, 20 Mar 2024 08:46:24 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0116bcba-e6d1-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1710949583; x=1711554383; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=miw496bbDIatANlneGT6asc88zxT8lpacC8+/iUgDtU=;
        b=fSg2EC9Ox9P9U1/P/nNjvL0H7vipK/gHwDratTINXYslKxZadrv6ihPSwehQJ/kqyd
         Aj3LzBg2dMMwG9nKBsfKPSo3JIjPnijMOWkq2RurTVU13xsJoZ8ov2qnPB50shsy7z/d
         hxvA5NTdlfA8cZWcInpY535AGGqIGfWJeSOww=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710949583; x=1711554383;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=miw496bbDIatANlneGT6asc88zxT8lpacC8+/iUgDtU=;
        b=dqjsL0007jIHW94wSTSpROuDj27M9U08hj72BWje1l6qd9Z2Up4jLrUy8KXUip1zhh
         81l9gAuHFrK9Zaoryd+fv//jFGRU2RCmPyteSIriEjbYiNj1pouAwd2zyE8TZ/u3dvll
         AMVIEEmnyVuQ0eQ+YjTewKoVgaZRTKf8BrMG6VqEnrpla4OnLY3mLL1Qfx1Ez3K73Sv0
         ZeSKUXrtWBd08c/k0/ngrKetX9Ykc+F/Kvy9nJ0X2C2WaK7MjQMa3nWDA79HqWqII0Fd
         jssXj907Sw+LpUwvL1sX8jBAH2ZCjyx+fk/olhEVCzU+LHG6694FdTRqCAPqy8OD01op
         RrBg==
X-Forwarded-Encrypted: i=1; AJvYcCVJ8BhxL0ZW+Znd+dzDRsvselYa0ZD404pqu6secCiA9XTW3mY1A2aVFGlFbubSIgF1xnUKH3slUdjsu/jGQT+SeDcsU62QdCyvfH3c9Ow=
X-Gm-Message-State: AOJu0YyLQXVkIriGJWXabIwdJ8i4PY8ws1TJi5NexfO042ITRv9+Hzej
	nzOToezyTHykvbyCCdF8EYGgPW37X94qmZYctR1jLA+Gh5OocGXeeqOx/ZTPOYKwP32cLPOxkt+
	Q9jdB5zh19TBrG9dkVH3cDjo5/Zj29cx/oVz61Q==
X-Google-Smtp-Source: AGHT+IHaeXm09jAW4Jb0Kdg81FUOBjr9CiJaWdARDsccbnssZok8wnbf/I+y475DoBGV5hYL2D0ASlqe2WY5VNexCKk=
X-Received: by 2002:a05:6870:8286:b0:221:46ea:6790 with SMTP id
 q6-20020a056870828600b0022146ea6790mr6438838oae.56.1710949583063; Wed, 20 Mar
 2024 08:46:23 -0700 (PDT)
MIME-Version: 1.0
References: <20240318163552.3808695-1-andrew.cooper3@citrix.com>
 <20240318163552.3808695-6-andrew.cooper3@citrix.com> 
In-Reply-To: 
From: George Dunlap 
Date: Wed, 20 Mar 2024 15:46:11 +0000
Message-ID: 
Subject: Re: [PATCH 5/7] xen: Switch to new TRACE() API
To: Jan Beulich 
Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
	George Dunlap , Stefano Stabellini , 
	Julien Grall , Nicola Vetrini , 
	"consulting @ bugseng . com" , Xen-devel 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Mar 20, 2024 at 1:45=E2=80=AFPM Jan Beulich  wro=
te:
>
> On 18.03.2024 17:35, Andrew Cooper wrote:
> > @@ -736,9 +736,19 @@ static void vlapic_update_timer(struct vlapic *vla=
pic, uint32_t lvtt,
> >              delta =3D delta * vlapic->hw.timer_divisor / old_divisor;
> >          }
> >
> > -        TRACE_2_LONG_3D(TRC_HVM_EMUL_LAPIC_START_TIMER, TRC_PAR_LONG(d=
elta),
> > -                        TRC_PAR_LONG(is_periodic ? period : 0),
> > -                        vlapic->pt.irq);
> > +        if ( unlikely(tb_init_done) )
> > +        {
> > +            struct {
> > +                uint64_t delta, period;
> > +                uint32_t irq;
> > +            } __packed d =3D {
> > +                .delta =3D delta,
> > +                .period =3D is_periodic ? period : 0,
> > +                .irq =3D vlapic->pt.irq,
> > +            };
> > +
> > +            trace_time(TRC_HVM_EMUL_LAPIC_START_TIMER, sizeof(d), &d);
> > +        }
>
> Instead of this open-coding, how about
>
>         if ( is_periodic )
>             TRACE_TIME(TRC_HVM_EMUL_LAPIC_START_TIMER, delta, delta >> 32=
,
>                        period, period >> 32, vlapic->pt.irq);
>         else
>             TRACE_TIME(TRC_HVM_EMUL_LAPIC_START_TIMER, delta, delta >> 32=
,
>                        0, 0, vlapic->pt.irq);
>
> thus improving similarity / grep-ability with ...

Yuck -- I'm not keen on breaking the similarity, but I'm *really* not
a fan of duplicating code.  Both are kind of "code smell"-y to me, but
I think the second seems worse.

It sort of looks to me like the source of the problem is that the
`period` variable is overloaded somehow; in that it's used to update
some calculation even if !is_periodic, and so the two places it's used
as an actual period (the trace code, and the call to
`create_periodic_time()`) need to figure out if `periodic` is for them
to use or not.

What about adding a variable, "timer_period" for that purpose?
Something like the following?

diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
index dcbcf4a1fe..ea14fc1587 100644
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -729,6 +729,8 @@ static void vlapic_update_timer(struct vlapic
*vlapic, uint32_t lvtt,

     if ( delta && (is_oneshot || is_periodic) )
     {
+        uint64_t timer_period =3D 0;
+
         if ( vlapic->hw.timer_divisor !=3D old_divisor )
         {
             period =3D (uint64_t)vlapic_get_reg(vlapic, APIC_TMICT)
@@ -736,12 +738,15 @@ static void vlapic_update_timer(struct vlapic
*vlapic, uint32_t lvtt,
             delta =3D delta * vlapic->hw.timer_divisor / old_divisor;
         }

-        TRACE_2_LONG_3D(TRC_HVM_EMUL_LAPIC_START_TIMER, TRC_PAR_LONG(delta=
),
-                        TRC_PAR_LONG(is_periodic ? period : 0),
-                        vlapic->pt.irq);
+        if ( is_periodic )
+            timer_period =3D period;
+
+        TRACE_TIME(TRC_HVM_EMUL_LAPIC_START_TIMER, delta, delta >> 32,
+                   timer_period, timer_period >> 32,
+                   vlapic->pt.irq);

         create_periodic_time(current, &vlapic->pt, delta,
-                             is_periodic ? period : 0, vlapic->pt.irq,
+                             timer_period, vlapic->pt.irq,
                              is_periodic ? vlapic_pt_cb : NULL,
                              &vlapic->timer_last_update, false);


As with Jan, I'd be OK with checking it in the way it is if you prefer, so:

Reviewed-by: George Dunlap 


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 15:54:12 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 15:54:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696015.1086510 (Exim 4.92)
	(envelope-from )
	id 1rmyGV-0002oy-4b; Wed, 20 Mar 2024 15:54:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696015.1086510; Wed, 20 Mar 2024 15:54:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmyGV-0002or-1L; Wed, 20 Mar 2024 15:54:07 +0000
Received: by outflank-mailman (input) for mailman id 696015;
 Wed, 20 Mar 2024 15:54:06 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmyGU-0002oj-9Q
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 15:54:06 +0000
Received: from mail-oa1-x2c.google.com (mail-oa1-x2c.google.com
 [2001:4860:4864:20::2c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 13ca720a-e6d2-11ee-afdd-a90da7624cb6;
 Wed, 20 Mar 2024 16:54:05 +0100 (CET)
Received: by mail-oa1-x2c.google.com with SMTP id
 586e51a60fabf-2226572ccf8so24984fac.2
 for ; Wed, 20 Mar 2024 08:54:05 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 13ca720a-e6d2-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1710950044; x=1711554844; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=1TOHykfAL/kCC4j6Vw3RqkGAKOe4wbMBdK3lIMcedhk=;
        b=cR5TSg2BhUIefxSCoDHJJfDtLFdN9MaJR4kdALTyvWI3Dw+DUIU8IZYFDEWORp3Qc0
         rmg2wcbZTr/8S6FZojSwyXSdz+FenY9o4TJ4okoHigFjkB70+PGgJid0Dkc/Yus5ccJC
         Vgqbkl6QKyj39LBKa5KHdvlIz93uL3F4oTfDw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710950044; x=1711554844;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=1TOHykfAL/kCC4j6Vw3RqkGAKOe4wbMBdK3lIMcedhk=;
        b=ENyFQAVsQvysbxPoMIR3s7fj6C6EhuWQ0gEuNOpCMtOSfgGzPpMPI6FhET3BiuVACg
         /s9VX7m5irE8Eu5FvTvntWxbixvMUvXwsBWeXLcmi/xKuto5AoxBpdfwySvldqnLKyb/
         2theaWHVjPWtIsp6GfiSNCzf0KCyRKXDSnTX6NNA4VQcOY7r45dJFUbCVOsIj1mpzEJg
         B93ZzylFzMv/Z1EMaGdEvVq9FAH1td48bPqp5FNGsv9iUKLWSxdDl4dZI+lYLzoe0h9+
         1NxLAYof4mwTIjCab2+ttZ9oHhLJkqZHHNX4Ge+HOhnZ1ANsR7daW/5iE5Flb+AzcnZr
         4nYw==
X-Gm-Message-State: AOJu0Yw3SRGvYw1SOR+DuH7Ptc/eBmMNXyzb03QD2Fqx5PjZiVqsMM3D
	6ZYXjlzZ/3KKU+Xf5JpjfrxhIq+43+Zb37KWq2e5jmIdGMZY29UZYO6x2Pd00+0zK9Sp8f+Ia9o
	S0lcx6g+f/K1j/BZeD8mlv2LfFXuMrpzuRN68XQ==
X-Google-Smtp-Source: AGHT+IH0rISwZnZCZYe3jx2QhDSWzlax3ZWiXd4wDHoevctWA4aa4rgpNhfz/BGZleLvBihStS32mzOFTtcsR/YdrEQ=
X-Received: by 2002:a05:6871:33a8:b0:222:1353:ad0f with SMTP id
 ng40-20020a05687133a800b002221353ad0fmr22360821oac.24.1710950043940; Wed, 20
 Mar 2024 08:54:03 -0700 (PDT)
MIME-Version: 1.0
References: <20240318163552.3808695-1-andrew.cooper3@citrix.com> <20240318163552.3808695-7-andrew.cooper3@citrix.com>
In-Reply-To: <20240318163552.3808695-7-andrew.cooper3@citrix.com>
From: George Dunlap 
Date: Wed, 20 Mar 2024 15:53:52 +0000
Message-ID: 
Subject: Re: [PATCH 6/7] xen/trace: Update final {__,}trace_var() users to the
 new API
To: Andrew Cooper 
Cc: Xen-devel , Jan Beulich , 
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
	George Dunlap , Stefano Stabellini , 
	Julien Grall , Nicola Vetrini , 
	"consulting @ bugseng . com" 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Mar 18, 2024 at 4:36=E2=80=AFPM Andrew Cooper  wrote:
>
> This logically drops the cycles parameter, as it's now encoded directly i=
n the
> event code.

So to make Jan's comment more specific, what about something like this:

This primarily consists of converting the cycles parameter into the
appropriate function: 0 -> trace(), 1 -> trace_time().

> No functional change.
>
> Signed-off-by: Andrew Cooper 

Reviewed-by: George Dunlap 


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 16:03:40 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 16:03:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696021.1086520 (Exim 4.92)
	(envelope-from )
	id 1rmyPW-0005jf-1P; Wed, 20 Mar 2024 16:03:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696021.1086520; Wed, 20 Mar 2024 16:03:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmyPV-0005jY-TP; Wed, 20 Mar 2024 16:03:25 +0000
Received: by outflank-mailman (input) for mailman id 696021;
 Wed, 20 Mar 2024 16:03:24 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmyPU-0005jS-7L
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 16:03:24 +0000
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com
 [2a00:1450:4864:20::633])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 602120b0-e6d3-11ee-a1ee-f123f15fe8a2;
 Wed, 20 Mar 2024 17:03:22 +0100 (CET)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-a4644bde1d4so909826166b.3
 for ; Wed, 20 Mar 2024 09:03:22 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ci20-20020a170906c35400b00a46e92e583bsm1618788ejb.149.2024.03.20.09.03.21
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 20 Mar 2024 09:03:21 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 602120b0-e6d3-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710950601; x=1711555401; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=FMvK7/6i67x0qkuVoW3pX3tce7WnIPgWNejXMRkH5FU=;
        b=DlS6SkAFK4mGgTr3dNbRpAIAx5xFAyKAxirdM3PO7+gj/fv57C3Da9bEowg7+sOkqy
         DClwvI/x5nltFV/nbtw6Jp1fTiu6W94MSCfRR9MmLYFJeVL8ubcG5atJ+mhwZe7Tn2uD
         5jPHIr9Jh3WQuR4apQqeAolDeObE3pQ9K6DZoxyyqDAhCppGYjA2+8Hj2HmSdB/AGkBz
         sX6yS73w2p537cAwefCBpsyP6qCDaLn2jDCRf6jLExA4ioSPmAHdMqjgUbnaephENeZB
         OHTMvuxf7MwRagUy+FVXakS9/lr317sAxmLC2QCKpVllymB+qgtUNo82ILnakDWZZ1S5
         dBtQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710950601; x=1711555401;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=FMvK7/6i67x0qkuVoW3pX3tce7WnIPgWNejXMRkH5FU=;
        b=K2ZvEKR5pEqcc9uAkZhBTVJNyP6xQC0DhuhmLevscVfIr40UlDaPqaHXYcUwa16Rc9
         Ev6kmxqvB5IKkbs1g2vRM0S5YEHan5WZB4Ln5aGBqzcff1qqZg1UtCl3MkFMk/emxjnI
         4ExoTfqJkZZeXYCDed+JQWOTZ26dTF1v1ylDOr+Y/T3HLsf986gBlJ3PjM80CWOUK8LI
         pvX/AzqG4mJ0X298sytLVX7hh2qK3ViqRsSET74JLty8GFCW4Zo3tjZufxK4ytW+Clyd
         piHOassKVppevuzwy6mW2WYHmqzRgOsFnE26k+beCx6Ta2kcS1Y0OrCmoDIqvHEH9iQ7
         1mEQ==
X-Forwarded-Encrypted: i=1; AJvYcCWa2COl0lUMj66/AURpUP/EGapO+Zox4BcB+ttTUleLOWJpWW4xOqjAypo+4q4S0/51jZzy/5nR56EWLV9ZTDiB4mbyywKg9mox5geLPyU=
X-Gm-Message-State: AOJu0YxKk1ewR63dxs7audx9x9OA8Ayq+1NFv9KmyQJngLXikNUtL4iq
	nZsFOfq++i81ErTdvl/d3amZJc+QEaWvWl7dWzQaIRGcSNrIdngx1yeLWpphRw==
X-Google-Smtp-Source: AGHT+IH6hfmAu3XclXRlBMeFca4507gglRkvQQc/eTLSJnCEyTGap3d51QYhQPQ8vx6NcIoAbXOolQ==
X-Received: by 2002:a17:906:aacb:b0:a46:2a47:6f4c with SMTP id kt11-20020a170906aacb00b00a462a476f4cmr1538623ejb.60.1710950601637;
        Wed, 20 Mar 2024 09:03:21 -0700 (PDT)
Message-ID: <9724aa80-106d-45ea-bad0-f0f2b83632eb@suse.com>
Date: Wed, 20 Mar 2024 17:03:20 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 07/20] xen/riscv: introduce bitops.h
Content-Language: en-US
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 xen-devel@lists.xenproject.org
References: 
 <14c91e2ba2aeb6e49f9f7e549232244719fa6959.1710517542.git.oleksii.kurochko@gmail.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <14c91e2ba2aeb6e49f9f7e549232244719fa6959.1710517542.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 15.03.2024 19:06, Oleksii Kurochko wrote:
> Taken from Linux-6.4.0-rc1
> 
> Xen's bitops.h consists of several Linux's headers:
> * linux/arch/include/asm/bitops.h:
>   * The following function were removed as they aren't used in Xen:
>         * test_and_set_bit_lock
>         * clear_bit_unlock
>         * __clear_bit_unlock
>   * The following functions were renamed in the way how they are
>     used by common code:
>         * __test_and_set_bit
>         * __test_and_clear_bit
>   * The declaration and implementation of the following functios
>     were updated to make Xen build happy:
>         * clear_bit
>         * set_bit
>         * __test_and_clear_bit
>         * __test_and_set_bit
>   * linux/include/asm-generic/bitops/generic-non-atomic.h with the
>     following changes:
>      * Only functions that can be reused in Xen were left;
>        others were removed.
>      * it was updated the message inside #ifndef ... #endif.
>      * __always_inline -> always_inline to be align with definition in
>        xen/compiler.h.
>      * update function prototypes from
>        generic___test_and_*(unsigned long nr nr, volatile unsigned long *addr)
>        to
>        generic___test_and_*(unsigned long nr, volatile void *addr) to be
>        consistent with other related macros/defines.
>      * convert identations from tabs to spaces.
>      * inside generic__test_and_* use 'bitops_uint_t' instead of 'unsigned long'
>         to be generic.

This last middle level bullet point looks stale here here, with that header
now being introduced in a separate patch.

> --- /dev/null
> +++ b/xen/arch/riscv/include/asm/bitops.h
> @@ -0,0 +1,144 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/* Copyright (C) 2012 Regents of the University of California */
> +
> +#ifndef _ASM_RISCV_BITOPS_H
> +#define _ASM_RISCV_BITOPS_H
> +
> +#include 
> +
> +#define BITOP_BITS_PER_WORD BITS_PER_LONG
> +
> +#define BITOP_TYPE
> +typedef uint64_t bitops_uint_t;
> +
> +#include 
> +
> +#define __set_bit(n, p)      set_bit(n, p)
> +#define __clear_bit(n, p)    clear_bit(n, p)

If these cam with a TODO, I wouldn't say anything. But without I take it
they're meant to remain that way, at which point I'd like to ask about
the performance aspect: Surely the AMO insns are more expensive than
whatever more basic insns could be used instead? I'd even go as far as
wondering whether

#define __set_bit(n, p)      ((void)__test_and_set_bit(n, p))
#define __clear_bit(n, p)    ((void)__test_and_clear_bit(n, p))

wouldn't be cheaper (the compiler would recognize the unused result
and eliminate its calculation, I'm pretty sure).

> +/* Based on linux/arch/include/asm/bitops.h */
> +
> +#if BITS_PER_LONG == 64
> +#define __AMO(op)   "amo" #op ".d"
> +#elif BITS_PER_LONG == 32
> +#define __AMO(op)   "amo" #op ".w"

This isn't in line with bitops_uint_t above. With BITOP_BITS_PER_WORD 
also expanding to BITS_PER_LONG, I think you mean to use unsigned long
there. Or else you could move stuff into the conditional here (or
really move the conditional here further up).

However, if you look at Arm64 and x86 code, you will notice that they
avoid 64-bit operations here. I'm afraid I can't easily tell whether
the reason(s) for this have meanwhile disappeared; I fear some of that
is still around.

> +#else
> +#error "Unexpected BITS_PER_LONG"
> +#endif
> +
> +#define test_and_op_bit_ord(op, mod, nr, addr, ord)     \
> +({                                                      \
> +    unsigned long res, mask;                            \
> +    mask = BITOP_MASK(nr);                              \
> +    __asm__ __volatile__ (                              \
> +        __AMO(op) #ord " %0, %2, %1"                    \
> +        : "=r" (res), "+A" (addr[BITOP_WORD(nr)])       \
> +        : "r" (mod(mask))                               \
> +        : "memory");                                    \
> +    ((res & mask) != 0);                                \
> +})
> +
> +#define __op_bit_ord(op, mod, nr, addr, ord)    \
> +    __asm__ __volatile__ (                      \
> +        __AMO(op) #ord " zero, %1, %0"          \
> +        : "+A" (addr[BITOP_WORD(nr)])           \
> +        : "r" (mod(BITOP_MASK(nr)))             \
> +        : "memory");
> +
> +#define test_and_op_bit(op, mod, nr, addr)    \
> +    test_and_op_bit_ord(op, mod, nr, addr, .aqrl)
> +#define __op_bit(op, mod, nr, addr) \
> +    __op_bit_ord(op, mod, nr, addr, )

Why are double underscores left on the non-test_and_ macros? Even
without name space considerations that looks odd here, when talk
is of the atomic forms of the operations, which by convention have
no (double) underscore at their front.

> --- a/xen/arch/riscv/include/asm/config.h
> +++ b/xen/arch/riscv/include/asm/config.h
> @@ -113,6 +113,8 @@
>  # error "Unsupported RISCV variant"
>  #endif
>  
> +#define BITS_PER_BYTE 8
> +
>  #define BYTES_PER_LONG (1 << LONG_BYTEORDER)
>  #define BITS_PER_LONG  (BYTES_PER_LONG << 3)
>  #define POINTER_ALIGN  BYTES_PER_LONG

How's this addition related to the change at hand?

Jan


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 16:04:54 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 16:04:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696025.1086530 (Exim 4.92)
	(envelope-from )
	id 1rmyQt-0006Sm-E5; Wed, 20 Mar 2024 16:04:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696025.1086530; Wed, 20 Mar 2024 16:04:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmyQt-0006Sf-BH; Wed, 20 Mar 2024 16:04:51 +0000
Received: by outflank-mailman (input) for mailman id 696025;
 Wed, 20 Mar 2024 16:04:49 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmyQr-0006OX-GM
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 16:04:49 +0000
Received: from mail-oa1-x35.google.com (mail-oa1-x35.google.com
 [2001:4860:4864:20::35])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 92f66c93-e6d3-11ee-a1ee-f123f15fe8a2;
 Wed, 20 Mar 2024 17:04:48 +0100 (CET)
Received: by mail-oa1-x35.google.com with SMTP id
 586e51a60fabf-2220a3b3871so17681fac.2
 for ; Wed, 20 Mar 2024 09:04:48 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 92f66c93-e6d3-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1710950687; x=1711555487; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=x/pF0IWf32BHYD2uOrVEQw5CEwumJcetdL7Wb7AMkBs=;
        b=RoYV9TftstrSu+ar48406rN1rCn8ZRrViOaI2sGnESL8Lvvvkz9959Cpl0OPH5lpEf
         oJq7xWwj/8eOk05cFokatUc3bf/OSlRs3dM/fmxc14w9VvcToX1x4dlDe5uK4g3QhXFC
         ASuoWvFI8t81RkpgmIc+/WPr8RHsM9toVxYSw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710950687; x=1711555487;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=x/pF0IWf32BHYD2uOrVEQw5CEwumJcetdL7Wb7AMkBs=;
        b=W2/GVkt+Ewx7FnhS4/WPTd7qc4dv1fqXPdzU68bVCVaiRA+9Ysl7gZsYQEKO1i4/VQ
         dhmu0LivZx8nxSKvyhfL2OJd2tXSWgO75cHkT0Nt3ZmVB8XmQGHeHwyScjsdxBNY7fXP
         /iTRlgWAA3vdrTTFkU5HCrEjMEqHdV4m/bsdks2aGvYqcihqRXDsDkmrXrmgRjfKBDfZ
         mGLqsf4bf19EpHc8+qkSv9Lvb2g65cfMVlym83nDJEiEKF3Teiz6JXjEsG1mDsM4s841
         2eW+u5zzWHREc7/nDx9nbkR7wi+k6bVGxdzMCJ5pW6X1eOuzf1nszTwiasf1Hp8EItMZ
         A0TA==
X-Gm-Message-State: AOJu0YwpoUBC5RYDorFtRJ7m1k4HlDdfLtf7zZuwjkR3PCFYoTl9jRPF
	mrRrtZm55pvfuK65JibSAUcTY3ICKfo+ztws3iWo2nosorsgF4BSjnOn8fNpyeL0OoWcQpadKHj
	k9aXv7piq740EHo4t0V9x9ASik6Zjr9i569vprQ==
X-Google-Smtp-Source: AGHT+IHFJIyrLGdULx9WkCRvk7VkPcIKWGbMu/B6fHqWJq7auegFNHJf4l4dY2L1UGR33HM+5E4kn3h2dknuQ77dEGc=
X-Received: by 2002:a05:6871:7405:b0:220:99bf:c26d with SMTP id
 nw5-20020a056871740500b0022099bfc26dmr19939180oac.9.1710950686857; Wed, 20
 Mar 2024 09:04:46 -0700 (PDT)
MIME-Version: 1.0
References: <20240318163552.3808695-1-andrew.cooper3@citrix.com> <20240318163552.3808695-6-andrew.cooper3@citrix.com>
In-Reply-To: <20240318163552.3808695-6-andrew.cooper3@citrix.com>
From: George Dunlap 
Date: Wed, 20 Mar 2024 16:04:35 +0000
Message-ID: 
Subject: Re: [PATCH 5/7] xen: Switch to new TRACE() API
To: Andrew Cooper 
Cc: Xen-devel , Jan Beulich , 
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
	George Dunlap , Stefano Stabellini , 
	Julien Grall , Nicola Vetrini , 
	"consulting @ bugseng . com" 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Mar 18, 2024 at 4:36=E2=80=AFPM Andrew Cooper  wrote:
>
> (Almost) no functional change.
>
> irq_move_cleanup_interrupt() changes two smp_processor_id() calls to the =
'me'
> local variable which manifests as a minor code improvement.  All other
> differences in the compiled binary are to do with line numbers changing.

Probably also worth noting that (as Jan points out in 7/7) by
bypassing HTMTRACE_ND, we're also bypassing the whole DEFAULT_HVM_*
and DO_TRC_HVM_* thing, which in theory could streamline the code by
causing the compiler to elide certain trace points.

 -George


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 16:06:44 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 16:06:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696028.1086540 (Exim 4.92)
	(envelope-from )
	id 1rmySh-0007Kz-OI; Wed, 20 Mar 2024 16:06:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696028.1086540; Wed, 20 Mar 2024 16:06:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmySh-0007Kr-L7; Wed, 20 Mar 2024 16:06:43 +0000
Received: by outflank-mailman (input) for mailman id 696028;
 Wed, 20 Mar 2024 16:06:42 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmySg-0007Kf-Qk
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 16:06:42 +0000
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com
 [2a00:1450:4864:20::529])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d68f4705-e6d3-11ee-afdd-a90da7624cb6;
 Wed, 20 Mar 2024 17:06:41 +0100 (CET)
Received: by mail-ed1-x529.google.com with SMTP id
 4fb4d7f45d1cf-56890b533aaso7920428a12.3
 for ; Wed, 20 Mar 2024 09:06:41 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 i25-20020a05640200d900b00568803d97d1sm7114018edu.9.2024.03.20.09.06.39
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 20 Mar 2024 09:06:40 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d68f4705-e6d3-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1710950800; x=1711555600; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=1QvQ1Bm2u56fcVPgTr3DjmeZKP5Tnu/+NIWA8hQqe8c=;
        b=ZtFUcZr8RKSeNzEm80CyStWJUUFBMiYisdakOhwYKhpxjNaJ/CZ0LFXqdIHeyT97Xm
         YS9axIrBwvKt05LyziK7ZpFRtkCW4H2C6WXHl4tmxMWRMUa8mozqo5tJqQqPXq9F/3si
         pxfnCqhWKusYyg4wmwQjhdCjhSOIFnsOoHg5n2zdn7KZVEc8vjXahkUJNt6WoHSmEw1R
         gWvCtuYFnx1WxLJ+58oAJvr51fphhH58/cIvkhOg1ptlxrltXlRV7suYLGuxlpjkxRkg
         hnXWldcfNcv3POi6lWZ/YjPaBg4raAmtiQbDDoaanyc9O6V15jv8xuBw+Y2luWs9bIyW
         QcDQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710950800; x=1711555600;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=1QvQ1Bm2u56fcVPgTr3DjmeZKP5Tnu/+NIWA8hQqe8c=;
        b=eMtQw1erh5ITI3euIZKtoQAdWfZhOK66WyWg3vufq6iM4XbnEEffpR6ctI7UXnXYPJ
         90RdRaDGAxwjjdVVe3cIiWVmqFMKRSZZkU5+yD2f1SrVzHIUuyK7Dlv1cbvl0WwXnbee
         swpp3r+4ZVmJe3RDerVK53g51e/Coxiffapvy+iTygoxmWmYKo1Aag4ewzbmVqcos38O
         ZLdKOnKHpSNJuGQyQRQFeVkJUDd9pOM7vX5xj9XzGT175SpFclCZ77HQsZToEsh136Ml
         NxHPc83ZKPTxZbmEsYSjKCQncxAmUXNIYcsHZcRQS68wlsfwwfDPpCLfKxORB/obCnKG
         8ggg==
X-Forwarded-Encrypted: i=1; AJvYcCXlXEbNZwWXgAScB75A6FWtSg4gGDqbxvmEVsTnk6IRojB79PZL3PxfYXxR3Fc2VmpEEaqrrumNfsRYzmNEr8ABVH5WAiJ+TnWZqd52a28=
X-Gm-Message-State: AOJu0YzJiTnu41dOk/swqv/hr+T+8gSVea57ZPn4GUiUkZ1wZm7S9w8X
	6uB6CMMbnQ64jer18RHko6TTfmzlqQq60UjMmHBgHGYzQfzQPn8X/qEHNG0L4A==
X-Google-Smtp-Source: AGHT+IEMxi2HZWx3gKO+FO8X24X73331h3K2FY36+EzK/HwMm2v6ZYi0s5Fpd0+Yh+d9cN1OuiTj8g==
X-Received: by 2002:aa7:dac3:0:b0:56b:b5a2:f8bb with SMTP id x3-20020aa7dac3000000b0056bb5a2f8bbmr1079440eds.3.1710950800355;
        Wed, 20 Mar 2024 09:06:40 -0700 (PDT)
Message-ID: 
Date: Wed, 20 Mar 2024 17:06:39 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 5/7] xen: Switch to new TRACE() API
Content-Language: en-US
To: George Dunlap 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 George Dunlap ,
 Stefano Stabellini , Julien Grall ,
 Nicola Vetrini ,
 "consulting @ bugseng . com" ,
 Xen-devel 
References: <20240318163552.3808695-1-andrew.cooper3@citrix.com>
 <20240318163552.3808695-6-andrew.cooper3@citrix.com>
 
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 20.03.2024 16:46, George Dunlap wrote:
> On Wed, Mar 20, 2024 at 1:45 PM Jan Beulich  wrote:
>>
>> On 18.03.2024 17:35, Andrew Cooper wrote:
>>> @@ -736,9 +736,19 @@ static void vlapic_update_timer(struct vlapic *vlapic, uint32_t lvtt,
>>>              delta = delta * vlapic->hw.timer_divisor / old_divisor;
>>>          }
>>>
>>> -        TRACE_2_LONG_3D(TRC_HVM_EMUL_LAPIC_START_TIMER, TRC_PAR_LONG(delta),
>>> -                        TRC_PAR_LONG(is_periodic ? period : 0),
>>> -                        vlapic->pt.irq);
>>> +        if ( unlikely(tb_init_done) )
>>> +        {
>>> +            struct {
>>> +                uint64_t delta, period;
>>> +                uint32_t irq;
>>> +            } __packed d = {
>>> +                .delta = delta,
>>> +                .period = is_periodic ? period : 0,
>>> +                .irq = vlapic->pt.irq,
>>> +            };
>>> +
>>> +            trace_time(TRC_HVM_EMUL_LAPIC_START_TIMER, sizeof(d), &d);
>>> +        }
>>
>> Instead of this open-coding, how about
>>
>>         if ( is_periodic )
>>             TRACE_TIME(TRC_HVM_EMUL_LAPIC_START_TIMER, delta, delta >> 32,
>>                        period, period >> 32, vlapic->pt.irq);
>>         else
>>             TRACE_TIME(TRC_HVM_EMUL_LAPIC_START_TIMER, delta, delta >> 32,
>>                        0, 0, vlapic->pt.irq);
>>
>> thus improving similarity / grep-ability with ...
> 
> Yuck -- I'm not keen on breaking the similarity, but I'm *really* not
> a fan of duplicating code.

Neither am I, just that ...

>  Both are kind of "code smell"-y to me, but I think the second seems worse.

... it was the other way around to me.

> It sort of looks to me like the source of the problem is that the
> `period` variable is overloaded somehow; in that it's used to update
> some calculation even if !is_periodic, and so the two places it's used
> as an actual period (the trace code, and the call to
> `create_periodic_time()`) need to figure out if `periodic` is for them
> to use or not.
> 
> What about adding a variable, "timer_period" for that purpose?
> Something like the following?

Yeah, why not.

Jan

> diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
> index dcbcf4a1fe..ea14fc1587 100644
> --- a/xen/arch/x86/hvm/vlapic.c
> +++ b/xen/arch/x86/hvm/vlapic.c
> @@ -729,6 +729,8 @@ static void vlapic_update_timer(struct vlapic
> *vlapic, uint32_t lvtt,
> 
>      if ( delta && (is_oneshot || is_periodic) )
>      {
> +        uint64_t timer_period = 0;
> +
>          if ( vlapic->hw.timer_divisor != old_divisor )
>          {
>              period = (uint64_t)vlapic_get_reg(vlapic, APIC_TMICT)
> @@ -736,12 +738,15 @@ static void vlapic_update_timer(struct vlapic
> *vlapic, uint32_t lvtt,
>              delta = delta * vlapic->hw.timer_divisor / old_divisor;
>          }
> 
> -        TRACE_2_LONG_3D(TRC_HVM_EMUL_LAPIC_START_TIMER, TRC_PAR_LONG(delta),
> -                        TRC_PAR_LONG(is_periodic ? period : 0),
> -                        vlapic->pt.irq);
> +        if ( is_periodic )
> +            timer_period = period;
> +
> +        TRACE_TIME(TRC_HVM_EMUL_LAPIC_START_TIMER, delta, delta >> 32,
> +                   timer_period, timer_period >> 32,
> +                   vlapic->pt.irq);
> 
>          create_periodic_time(current, &vlapic->pt, delta,
> -                             is_periodic ? period : 0, vlapic->pt.irq,
> +                             timer_period, vlapic->pt.irq,
>                               is_periodic ? vlapic_pt_cb : NULL,
>                               &vlapic->timer_last_update, false);
> 
> 
> As with Jan, I'd be OK with checking it in the way it is if you prefer, so:
> 
> Reviewed-by: George Dunlap 



From xen-devel-bounces@lists.xenproject.org Wed Mar 20 16:06:45 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 16:06:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696029.1086550 (Exim 4.92)
	(envelope-from )
	id 1rmySi-0007ZP-Vy; Wed, 20 Mar 2024 16:06:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696029.1086550; Wed, 20 Mar 2024 16:06:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmySi-0007ZI-SM; Wed, 20 Mar 2024 16:06:44 +0000
Received: by outflank-mailman (input) for mailman id 696029;
 Wed, 20 Mar 2024 16:06:43 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmySh-0007Kf-GU
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 16:06:43 +0000
Received: from mail-oa1-x2e.google.com (mail-oa1-x2e.google.com
 [2001:4860:4864:20::2e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d6be5c5f-e6d3-11ee-afdd-a90da7624cb6;
 Wed, 20 Mar 2024 17:06:42 +0100 (CET)
Received: by mail-oa1-x2e.google.com with SMTP id
 586e51a60fabf-222ba2a19bdso28115fac.1
 for ; Wed, 20 Mar 2024 09:06:42 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d6be5c5f-e6d3-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1710950800; x=1711555600; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=z8OE54LHPd9uGphrLuqSE2+byM70JXcNFjjUmbbYksU=;
        b=TlmZu08NX8Be5KP/hh8PkTczVkc/YAUvtzymN9I2HKjvlEBl9WR1A/b1hFbnvjLVWR
         YyYbdo3e9fBiEQLq1vEOnbBGsWvOAZck21Se+tp3J5dJF+ZPElPGmuPgpQ93BkL6Bpkc
         ABTsgqceomMXaaD43nL9mMK9Hzmx7dlZZ1PuU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710950800; x=1711555600;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=z8OE54LHPd9uGphrLuqSE2+byM70JXcNFjjUmbbYksU=;
        b=dQWjy6uSyuR1ORunUSgbeAkj4Bi+MqYqQ/0Oc6PSXnUXXd57NVxUJ2Zv3cTBaSTS8s
         4gXyMDGD3tn7aR9wit6BlIaIJ18eypWSHNnegAq7opiBnVIgId3eaT40TjICSw5SoZxP
         vHbMyrT4FQHpWVtyhftwdCEon3CwnoL1UmT7/QLDusvjdx5Fib1tn3xBNkC1iwLPP4Kw
         wVE2+WwX7n9qpWtrSuj4FlnlhMQQpBL7zJex1ItxpK8/fZfw5Nk/qYEDWXTM58nyJN1o
         c9eKiqk3xFAswuEnLs4xrWjYGpmZh/bzLZJhv0fkmjH9HTnlIhYinTapNh/lhz31RRCu
         ixVw==
X-Gm-Message-State: AOJu0YyhaXgUmxjK3jX6j+/lBz5Q4A6A6OW+JMhaQTuMlQvIlAoIAEhZ
	CyBQFsaqDbQYPqOkvqQlMtz1Bm5+MppaeWnszcRJYpGQlhS9AWcMBi7v1tOmKDEKsPpQ/3twW9d
	LjhbwRuFGIm70bKSz0YOeS2y37KxzvM6MlDUAvCq0W3dLhC0kxso=
X-Google-Smtp-Source: AGHT+IEXeBtaUgfe7HNS9O/siWiVeNE/x5lb0KMvBssM8Vn//ZvUxP7i+evILmbnK0aagGLOUY/wRK4HlFM+j1ysq+k=
X-Received: by 2002:a05:6870:2494:b0:21e:df09:fbb6 with SMTP id
 s20-20020a056870249400b0021edf09fbb6mr19439828oaq.41.1710950799071; Wed, 20
 Mar 2024 09:06:39 -0700 (PDT)
MIME-Version: 1.0
References: <20240318163552.3808695-1-andrew.cooper3@citrix.com> <20240318163552.3808695-8-andrew.cooper3@citrix.com>
In-Reply-To: <20240318163552.3808695-8-andrew.cooper3@citrix.com>
From: George Dunlap 
Date: Wed, 20 Mar 2024 16:06:28 +0000
Message-ID: 
Subject: Re: [PATCH 7/7] xen/trace: Drop old trace API
To: Andrew Cooper 
Cc: Xen-devel , Jan Beulich , 
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
	George Dunlap , Stefano Stabellini , 
	Julien Grall , Nicola Vetrini , 
	"consulting @ bugseng . com" 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Mar 18, 2024 at 4:36=E2=80=AFPM Andrew Cooper  wrote:
>
> With all users updated to the new API, drop the old API.  This includes a=
ll of
> asm/hvm/trace.h, which allows us to drop some includes.
>
> Signed-off-by: Andrew Cooper 

Reviewed-by: George Dunlap 


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 16:08:27 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 16:08:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696033.1086559 (Exim 4.92)
	(envelope-from )
	id 1rmyUL-0008Q7-9z; Wed, 20 Mar 2024 16:08:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696033.1086559; Wed, 20 Mar 2024 16:08:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmyUL-0008Q0-7P; Wed, 20 Mar 2024 16:08:25 +0000
Received: by outflank-mailman (input) for mailman id 696033;
 Wed, 20 Mar 2024 16:08:23 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmyUJ-0008PC-Sq
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 16:08:23 +0000
Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com
 [2a00:1450:4864:20::332])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 130dfcb0-e6d4-11ee-a1ee-f123f15fe8a2;
 Wed, 20 Mar 2024 17:08:22 +0100 (CET)
Received: by mail-wm1-x332.google.com with SMTP id
 5b1f17b1804b1-4146d750dcdso354595e9.1
 for ; Wed, 20 Mar 2024 09:08:22 -0700 (PDT)
Received: from perard.uk.xensource.com (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 v7-20020a05600c444700b0041469869d11sm2642895wmn.47.2024.03.20.09.08.20
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 20 Mar 2024 09:08:21 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 130dfcb0-e6d4-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1710950902; x=1711555702; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=9ydCgfXZXN/lh3bnAqoOjUPtVfgXID7+JO/rNeRXEfg=;
        b=Sw4ojcy1fpnR3appZX3Z19qxDvh3YpQ+sMJa2+JbFqfN2sxaCDP3DbPRw51fAJZrOy
         4tXK2jFVZZ+/BjXdbyiFAEf6VoaYoG0gegCzlO4kYqRuRESqKiTkL+FER7jdaoUI0H4E
         vyVcTu0WjUfyvXFn7CW16ac+YgG2GskLdDZUo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710950902; x=1711555702;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=9ydCgfXZXN/lh3bnAqoOjUPtVfgXID7+JO/rNeRXEfg=;
        b=drcRqaqKt5klx/nImeG4QI5sSMjKB3ecRnh+QAaluAPfIjLL0aDA9V+oKMY/cDPZQ6
         fY8AHETqK07E+PfyRGgA35M2KMWa5kVPxN3K1PeJoAjZMPrLYuH+i8Rk/gFNZb/WwXH5
         R/r9zBMpk4EGw4+T/bbDqdhZ50ljwVBbhgu7d8eCm+JwdJH5buy6x1p+hM0I48vk4vfP
         2ckARFUJkyy/GgNWI/UfivUI+rRDKpn0i8KqtQ0ZWXc5XvRbEz92jHoHIVvfYWfI/yxE
         aKsSz02B44Jkz+EzZCs7mYCkNRVbkNGWvPfOw2L4hsq0NXp888xgHTa7t+K1N0MQYhpr
         FN9g==
X-Gm-Message-State: AOJu0YyfSuzgLcJloRw7VstD5BsaXm/7zJlqWihBL1ApXgs8OPp+6Jx5
	CZ8XJLg4Vg8bvGGAds/COc5jo58NWJnMPfmQXdIJc61htTF1rqo3aKixZ0m0XHw=
X-Google-Smtp-Source: AGHT+IGpwx+I3CN3YLrc7zIzvUFeBYMTuvVJc90Jx1S+kBKlIQ6qwlWc3728h4Co9hIdC9w8efqDCw==
X-Received: by 2002:a05:600c:4a96:b0:414:f4:c6c0 with SMTP id b22-20020a05600c4a9600b0041400f4c6c0mr82663wmp.20.1710950901790;
        Wed, 20 Mar 2024 09:08:21 -0700 (PDT)
Date: Wed, 20 Mar 2024 16:08:20 +0000
From: Anthony PERARD 
To: zithro / Cyril =?iso-8859-1?Q?R=E9bert?= 
Cc: xen-devel@lists.xenproject.org,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= ,
	Wei Liu 
Subject: Re: [PATCH v2] docs/man: add shutdown reasons to xl (list) man page
Message-ID: 
References: <0a2fcad111622431b8cd54c69adc3dedd24fb572.1709910923.git.slack@rabbit.lu>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <0a2fcad111622431b8cd54c69adc3dedd24fb572.1709910923.git.slack@rabbit.lu>

On Fri, Mar 08, 2024 at 04:19:20PM +0100, zithro / Cyril Rbert wrote:
> Questions (unblocking):
>  - why a double space between all sentences ?

It's an English thing maybe?

Wikipedia has an article about it: https://en.wikipedia.org/wiki/Sentence_spacing
But actually, single space seems like it used to be a french thing, even
called "French spacing":
https://en.wikipedia.org/wiki/History_of_sentence_spacing#French_and_English_spacing

I guess it doesn't really matter. I don't really pay attention to it
anyway.

>  - how to get a "simple LF" ? Ie. I want to use 
, not 

>    (a simple  has no effect, a double renders a 
)

That doesn't look to be possible, unless you actually managed to write
the paragraph for all targeted formats, with things like =begin html...,
but that would probably make things more complicated that necessary.

> ---
> diff --git a/docs/man/xl.1.pod.in b/docs/man/xl.1.pod.in
> index bed8393473..d37227ba58 100644
> --- a/docs/man/xl.1.pod.in
> +++ b/docs/man/xl.1.pod.in
> @@ -370,12 +370,50 @@ scheduling by the Xen hypervisor.
>  The guest OS has shut down (SCHEDOP_shutdown has been called) but the
>  domain is not dying yet.
>  
> -=item B
> +There are six shutdown reasons, which will be displayed after the "s" : B<-rscwS>.
> +
> +Note that some states will only be displayed if "on_poweroff=preserve" is set in
> +the config file, see L).
> +
> +=over 4
> +
> +=over 4
> +
> +=item B
> +
> +The domain exited normally, it will get destroyed.
> +
> +=item B
> +
> +The domain will reboot.

Well, that's not really true. I think to end up in this state, what
happen is that the domain shutdown and ask for a reboot. It's normally
the toolstack job to cleanup the domain then create a new domain for the
guest. I guess you might see this state if you have "on_reboot=preserve"
or you run `xl list` at the right time. Or the toolstack crashed and
fail to kill the domain before a reboot. So maybe a better to have
something like "The domain exited normally and ask for a reboot."

Same things for the other entries (poweroff and watchdog). The status is
just the current status of what is supposed to happen. But a few things
might mean that the domain stay in that state unless the admin does
something. This could be simply because there's "on_*=preserve" setting,
the toolstack crashed or we just happen to look while the toolstack is
cleaning thing up.

> +=item B
> +
> +The domain is suspended to disk or to RAM. If suspended to disk, the domain will
> +get destroyed.

I think in that state, the domain is just suspended, maybe to RAM? I
don't know if suspend to disk would end up in this state, my guess is
the domain will go to "poweroff" instead. But for suspend to "RAM", I
think the toolstack is supposed to save the guest memory and guest
config somewhere, maybe even on a different host for live migration?

This is a state that seems to happen as part of a live migration (or `xl
save` I guess).

I tried to suspend a guest (runnning `systemd suspend`), but xl never
reported `ss`, because there's nothing to do I guess. So this state is
probably really about migration.


Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 16:15:27 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 16:15:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696035.1086571 (Exim 4.92)
	(envelope-from )
	id 1rmyb4-000223-1X; Wed, 20 Mar 2024 16:15:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696035.1086571; Wed, 20 Mar 2024 16:15:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmyb3-00021w-TL; Wed, 20 Mar 2024 16:15:21 +0000
Received: by outflank-mailman (input) for mailman id 696035;
 Wed, 20 Mar 2024 16:15:20 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmyb2-00021q-Sn
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 16:15:20 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.133.124])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 09177410-e6d5-11ee-a1ee-f123f15fe8a2;
 Wed, 20 Mar 2024 17:15:16 +0100 (CET)
Received: from mail-ot1-f69.google.com (mail-ot1-f69.google.com
 [209.85.210.69]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-34-HXTIKzDRNoa80nrM3xgv7A-1; Wed, 20 Mar 2024 12:15:12 -0400
Received: by mail-ot1-f69.google.com with SMTP id
 46e09a7af769-6e678d894e9so6398829a34.2
 for ; Wed, 20 Mar 2024 09:15:12 -0700 (PDT)
Received: from ?IPV6:2a01:e0a:280:24f0:9db0:474c:ff43:9f5c?
 ([2a01:e0a:280:24f0:9db0:474c:ff43:9f5c])
 by smtp.gmail.com with ESMTPSA id
 x14-20020ae9e90e000000b00789ea3555acsm4666094qkf.19.2024.03.20.09.15.09
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 20 Mar 2024 09:15:11 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 09177410-e6d5-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1710951314;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=T4IhxAuWNgzsFqb6tIlcQFajJYSC/Su8joooqt+6RRU=;
	b=MhVWwfkRVTsHTL55ggC8jH3QlzeEdGBvtfP1jzvqOyuLa9kagWwNdfOo/dZiXD7+iaF8bs
	dkssLwOAQ2ubvPZ7l1VEAn1/dVrzEwPViGuD/J0hwaXltk1W3Ebcj5Wpn7ypm3fsFJ+EIP
	BJwXXog9MenSx7zuohcUf0P3i3dmzJo=
X-MC-Unique: HXTIKzDRNoa80nrM3xgv7A-1
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710951312; x=1711556112;
        h=content-transfer-encoding:in-reply-to:from:references:cc:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=T4IhxAuWNgzsFqb6tIlcQFajJYSC/Su8joooqt+6RRU=;
        b=AGg4PQtGx5faeEjU37vQHEc5btPBaj942wbUMUwoes4RpsQu+ktt2e3j3GMrFqpLYw
         5StgsHDb05CnClC7aSLfbWc5aQN9ZQrYuDjpM8jG2qV09BDdrGNZXEJkyj0juGvV15TZ
         B8X0DXwczyKRSNriP/rIDNuhRQP5bCxMK4cWCTGs0mvusYNqVU2LpsjLZnbxyscxd2gp
         i11AX9+PAC40dFcA1Rg6BSkkYQWuCOzGvWapkfSXTA3ljZI7pcjz+IHBoT5t8wBDJvXs
         U6cLct86jUa5lxN3I19+crw9z7qMuml1UP7VgiejL/2W8aCIqBaOZ4IWffm4fZhj3Ji/
         9i1w==
X-Forwarded-Encrypted: i=1; AJvYcCV3D0bxSyu7ZR+yFjBNcZhjcyW+BExwVBHiyvKn/jT7r4rAIJFZDoJUuXgmwUXcRb/wogGgm75dovfuVhddqrw7em3TIFWmNowrETNbIMQ=
X-Gm-Message-State: AOJu0Yyihz3BwWXtb5mmhIBGdIJpa/1u+rowvSzgJAVHZ2GD1bCajvVo
	3vZYEc88eU4clsaBCUtYAuAvHBKz6o3EtajsqFofFmlplSR71+9s+R5UHs8j0o2DWmBZeuJlq93
	q8gC3vmEB4nX6LHke1Jjtb9DHu1FcsQp0X8zBUoIDxxXUeqFAjUr9DVPq7w9zq771
X-Received: by 2002:a05:6830:1d70:b0:6e6:8516:4866 with SMTP id l16-20020a0568301d7000b006e685164866mr12600256oti.16.1710951312072;
        Wed, 20 Mar 2024 09:15:12 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IG5SXrLrO24aMjWMzHB6MM12ePW1/UUxpm7nPE1oUi+NjEX/CxeqywPujgO7EBLwXPakP49HA==
X-Received: by 2002:a05:6830:1d70:b0:6e6:8516:4866 with SMTP id l16-20020a0568301d7000b006e685164866mr12600232oti.16.1710951311827;
        Wed, 20 Mar 2024 09:15:11 -0700 (PDT)
Message-ID: 
Date: Wed, 20 Mar 2024 17:15:06 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for-9.1 v5 09/14] memory: Add Error** argument to
 .log_global_start() handler
To: Peter Xu 
Cc: qemu-devel@nongnu.org, Stefano Stabellini ,
 Anthony Perard , Paul Durrant ,
 Paolo Bonzini ,
 Richard Henderson ,
 Eduardo Habkost , "Michael S. Tsirkin"
 , Marcel Apfelbaum ,
 Alex Williamson ,
 David Hildenbrand ,
 =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= ,
 Fabiano Rosas , Avihai Horon ,
 Markus Armbruster , Prasad Pandit
 , xen-devel@lists.xenproject.org
References: <20240320064911.545001-1-clg@redhat.com>
 <20240320064911.545001-10-clg@redhat.com> 
From: =?UTF-8?Q?C=C3=A9dric_Le_Goater?= 
In-Reply-To: 
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Language: en-US, fr
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 3/20/24 15:42, Peter Xu wrote:
> On Wed, Mar 20, 2024 at 07:49:05AM +0100, Cédric Le Goater wrote:
>> Modify all .log_global_start() handlers to take an Error** parameter
>> and return a bool. Adapt memory_global_dirty_log_start() to interrupt
>> on the first error the loop on handlers. In such case, a rollback is
>> performed to stop dirty logging on all listeners where it was
>> previously enabled.
>>
>> Cc: Stefano Stabellini 
>> Cc: Anthony Perard 
>> Cc: Paul Durrant 
>> Cc: "Michael S. Tsirkin" 
>> Cc: Paolo Bonzini 
>> Cc: David Hildenbrand 
>> Signed-off-by: Cédric Le Goater 
> 
> Reviewed-by: Peter Xu 
> 
> Still one comment below:
> 
>> @@ -3014,8 +3044,11 @@ static void listener_add_address_space(MemoryListener *listener,
>>           listener->begin(listener);
>>       }
>>       if (global_dirty_tracking) {
>> +        /*
>> +         * Migration has already started. Assert on any error.
> 
> If you won't mind, I can change this to:
> 
>    /*
>     * Currently only VFIO can fail log_global_start(), and it's not allowed
>     * to hotplug a VFIO device during migration, so this should never fail
>     * when invoked.  If it can start to fail in the future, we need to be
>     * able to fail the whole listener_add_address_space() and its callers.
>     */

Sure, or I will in a v6. Markus had a comment on 8/14.

Thanks,

C.



From xen-devel-bounces@lists.xenproject.org Wed Mar 20 16:24:25 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 16:24:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696044.1086580 (Exim 4.92)
	(envelope-from )
	id 1rmyji-00055e-UU; Wed, 20 Mar 2024 16:24:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696044.1086580; Wed, 20 Mar 2024 16:24:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmyji-00055X-QG; Wed, 20 Mar 2024 16:24:18 +0000
Received: by outflank-mailman (input) for mailman id 696044;
 Wed, 20 Mar 2024 16:24:16 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmyjg-00055R-NF
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 16:24:16 +0000
Received: from mail.actia.se (mail.actia.se [212.181.117.226])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4b3ca8d6-e6d6-11ee-afdd-a90da7624cb6;
 Wed, 20 Mar 2024 17:24:15 +0100 (CET)
Received: from S036ANL.actianordic.se (10.12.31.117) by S036ANL.actianordic.se
 (10.12.31.117) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.37; Wed, 20 Mar
 2024 17:24:14 +0100
Received: from S036ANL.actianordic.se ([fe80::e13e:1feb:4ea6:ec69]) by
 S036ANL.actianordic.se ([fe80::e13e:1feb:4ea6:ec69%4]) with mapi id
 15.01.2507.037; Wed, 20 Mar 2024 17:24:14 +0100
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4b3ca8d6-e6d6-11ee-afdd-a90da7624cb6
From: John Ernberg 
To: Bertrand Marquis , Julien Grall 
CC: Peng Fan , Stefano Stabellini ,
	Michal Orzel , Volodymyr Babchuk
	, Jonas Blixt ,
	"xen-devel@lists.xenproject.org" 
Subject: Re: [PATCH 1/2] xen/arm: Add imx8q{m,x} platform glue
Thread-Topic: [PATCH 1/2] xen/arm: Add imx8q{m,x} platform glue
Thread-Index: AQHaVDuqVQ/kgxLZgUK/m8/hE0ez5bDzxxsAgAA1KwCAAVx5AIAAQjeAgAEdtQCAAyp5AIABm3uAgAZ8E4CAKNxDgIAApfwAgAKGQoCAAAbIgIAHmW8AgAtpcwA=
Date: Wed, 20 Mar 2024 16:24:14 +0000
Message-ID: 
References: <20240131114952.305805-1-john.ernberg@actia.se>
 <20240131114952.305805-2-john.ernberg@actia.se>
 
 <494d4961-ad8a-4d1d-aaa6-d1bfb9d6a137@actia.se>
 <167f0c7a-e037-446c-82f8-2584e35a7af1@xen.org>
 
 <012b5f83-2f9b-4477-965e-07b8506c0052@xen.org>
 
 <5a0c8f09-4f01-45e9-892c-86342c0d0ec5@xen.org>
 <08ae764c-3490-4dd1-ab70-7a855a98d16d@actia.se>
 <911ec1bb-3733-4f37-839e-673a88e408ff@actia.se>
 
 <848794f3-a337-49d9-84db-a969970f071b@actia.se>
 <48038c7f-d7cd-4100-a41b-8042bcb93208@xen.org>
 <967020E7-3D03-416A-8BFC-6F4E4BD9D7B5@arm.com>
In-Reply-To: <967020E7-3D03-416A-8BFC-6F4E4BD9D7B5@arm.com>
Accept-Language: en-US, sv-SE
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.12.12.30]
x-esetresult: clean, is OK
x-esetid: 37303A2958D729556D7C66
Content-Type: text/plain; charset="utf-8"
Content-ID: <163B6A671A3D5E4D812D00BB394BFED1@actia.se>
Content-Transfer-Encoding: base64
MIME-Version: 1.0

SGkgQmVydHJhbmQsDQoNCk9uIDMvMTMvMjQgMTE6MDcsIEJlcnRyYW5kIE1hcnF1aXMgd3JvdGU6
DQo+IEhpLA0KPiANCj4+IE9uIDggTWFyIDIwMjQsIGF0IDE1OjA0LCBKdWxpZW4gR3JhbGwgPGp1
bGllbkB4ZW4ub3JnPiB3cm90ZToNCj4+DQo+PiBIaSBKb2huLA0KPj4NCj4+IFRoYW5rIHlvdSBm
b3IgdGhlIHJlcGx5Lg0KPj4NCj4+IE9uIDA4LzAzLzIwMjQgMTM6NDAsIEpvaG4gRXJuYmVyZyB3
cm90ZToNCj4+PiBPbiAzLzcvMjQgMDA6MDcsIEp1bGllbiBHcmFsbCB3cm90ZToNCj4+Pj4gICA+
IFBpbmcgb24gdGhlIHdhdGNoZG9nIGRpc2N1c3Npb24gYml0cy4NCj4+Pj4NCj4+Pj4gU29ycnkg
Zm9yIHRoZSBsYXRlIHJlcGx5Lg0KPj4+Pg0KPj4+PiBPbiAwNi8wMy8yMDI0IDEzOjEzLCBKb2hu
IEVybmJlcmcgd3JvdGU6DQo+Pj4+PiBPbiAyLzkvMjQgMTQ6MTQsIEpvaG4gRXJuYmVyZyB3cm90
ZToNCj4+Pj4+Pg0KPj4+Pj4+PiAgICAgICogSU1YX1NJUF9USU1FUl8qOiAgVGhpcyBzZWVtcyB0
byBiZSByZWxhdGVkIHRvIHRoZSB3YXRjaGRvZy4NCj4+Pj4+Pj4gU2hvdWxkbid0IGRvbTAgcmVs
eSBvbiB0aGUgd2F0Y2hkb2cgcHJvdmlkZWQgYnkgWGVuIGluc3RlYWQ/IFNvIHRob3NlDQo+Pj4+
Pj4+IGNhbGwgd2lsbCBiZSB1c2VkIGJ5IFhlbi4NCj4+Pj4+Pg0KPj4+Pj4+IFRoYXQgaXMgaW5k
ZWVkIGEgd2F0Y2hkb2cgU0lQLCBhbmQgYWxzbyBmb3Igc2V0dGluZyB0aGUgU29DIGludGVybmFs
IFJUQw0KPj4+Pj4+IGlmIGl0IGlzIGJlaW5nIHVzZWQuDQo+Pj4+Pj4NCj4+Pj4+PiBJIGxvb2tl
ZCBhcm91bmQgaWYgdGhlcmUgd2FzIHByZXZpb3VzIGRpc2N1c3Npb24gYW5kIG9ubHkgcmVhbGx5
DQo+Pj4+Pj4gZm91bmQgWzNdLg0KPj4+Pj4+IElzIHRoZSB4ZW4veGVuL2luY2x1ZGUvd2F0Y2hk
b2cuaCBoZWFkZXIgbWVhbnQgdG8gYmUgZm9yIHRoaXMga2luZCBvZg0KPj4+Pj4+IHdhdGNoZG9n
IHN1cHBvcnQgb3IgaXMgdGhhdCBtb3JlIGZvciB0aGUgVk0gd2F0Y2hkb2c/IExvb2tpbmcgYXQg
dGhlIHg4Ng0KPj4+Pj4+IEFDUEkgTk1JIHdhdGNoZG9nIGl0IHNlZW1zIGxpa2UgdGhlIGZvcm1l
ciwgYnV0IEkgaGF2ZSBuZXZlciB3b3JrZWQgd2l0aA0KPj4+Pj4+IHg4NiBub3IgQUNQSS4NCj4+
Pj4NCj4+Pj4gaW5jbHVkZS93YXRjaGRvZy5oIGNvbnRhaW5zIGhlbHBlciB0byBjb25maWd1cmUg
dGhlIHdhdGNoZG9nIGZvciBYZW4uIFdlDQo+Pj4+IGFsc28gaGF2ZSBwZXItVk0gd2F0Y2hkb2cg
YW5kIHRoaXMgaXMgY29uZmlndXJlZCBieSB0aGUgaHlwZXJjYWxsDQo+Pj4+IFNDSEVET1Bfd2F0
Y2hkb2cuDQo+Pj4+DQo+Pj4+Pj4NCj4+Pj4+PiBDdXJyZW50bHkgZm9yd2FyZGluZyBpdCB0byBE
b20wIGhhcyBub3QgY2F1c2VkIGFueSB3YXRjaGRvZyByZXNldHMgd2l0aA0KPj4+Pj4+IG91ciB3
YXRjaGRvZyB0aW1lb3V0IHNldHRpbmdzLCBvdXIgc3BlY2lmaWMgRG9tMCBzZXR1cCBhbmQgVk0g
Y291bnQuDQo+Pj4+DQo+Pj4+IElJVUMsIHRoZSBTTUMgQVBJIGZvciB0aGUgd2F0Y2hkb2cgd291
bGQgYmUgc2ltaWxhciB0byB0aGUgQUNQSSBOTUkNCj4+Pj4gd2F0Y2hkb2cuIFNvIEkgdGhpbmsg
aXQgd291bGQgbWFrZSBtb3JlIHNlbnNlIGlmIHRoaXMgaXMgbm90IGV4cG9zZWQgdG8NCj4+Pj4g
ZG9tMCAoZXZlbiBpZiBYZW4gaXMgZG9pbmcgbm90aGluZyB3aXRoIGl0KS4NCj4+Pj4NCj4+Pj4g
Q2FuIHlvdSB0cnkgdG8gaGlkZSB0aGUgU01DcyBhbmQgY2hlY2sgaWYgZG9tMCBzdGlsbCBiZWhh
dmUgcHJvcGVybHk/DQo+Pj4+DQo+Pj4+IENoZWVycywNCj4+Pj4NCj4+PiBUaGlzIFNNQyBtYW5h
Z2VzIGEgaGFyZHdhcmUgd2F0Y2hkb2csIGlmIGl0J3Mgbm90IHBpbmdlZCB3aXRoaW4gYQ0KPj4+
IHNwZWNpZmljIGludGVydmFsIHRoZSBlbnRpcmUgYm9hcmQgcmVzZXRzLg0KPj4NCj4+IERvIHlv
dSBrbm93IHdoYXQncyB0aGUgZGVmYXVsdCBpbnRlcnZhbD8gSXMgaXQgbGFyZ2UgZW5vdWdoIHNv
IFhlbiArIGRvbTAgY2FuIGJvb3QgKGF0IGxlYXN0IHVwIHRvIHdoZW4gdGhlIHdhdGNoZG9nIGRy
aXZlciBpcyBpbml0aWFsaXplZCk/DQo+Pg0KPj4+IElmIEkgYmxvY2sgdGhlIFNNQ3MgdGhlIHdh
dGNoZG9nIGRyaXZlciBpbiBEb20wIHdpbGwgZmFpbCB0byBwaW5nIHRoZQ0KPj4+IHdhdGNoZG9n
LCB0cmlnZ2VyaW5nIGEgYm9hcmQgcmVzZXQgYmVjYXVzZSB0aGUgc3lzdGVtIGxvb2tzIHRvIGhh
dmUNCj4+PiBiZWNvbWUgdW5yZXNwb25zaXZlLiBUaGUgcmVhc29uIHRoaXMgcGF0Y2ggc2V0IHN0
YXJ0ZWQgaXMgYmVjYXVzZSB3ZQ0KPj4+IGNvdWxkbid0IHBpbmcgdGhlIHdhdGNoZG9nIHdoZW4g
cnVubmluZyB3aXRoIFhlbi4NCj4+PiBJbiBvdXIgc3BlY2lmaWMgc3lzdGVtIHRoZSBib290bG9h
ZGVyIGVuYWJsZXMgdGhlIHdhdGNoZG9nIGFzIGVhcmx5IGFzDQo+Pj4gcG9zc2libGUgc28gdGhh
dCB3ZSBjYW4gZ2V0IHdhdGNoZG9nIHByb3RlY3Rpb24gZm9yIGFzIG11Y2ggb2YgdGhlIGJvb3QN
Cj4+PiBhcyB3ZSBwb3NzaWJseSBjYW4uDQo+Pj4gU28sIGlmIHdlIGFyZSB0byBibG9jayB0aGUg
U01DIGZyb20gRG9tMCwgdGhlbiBYZW4gbmVlZHMgdG8gdGFrZSBvdmVyDQo+Pj4gdGhlIHBpbmdp
bmcuIEl0IGNvdWxkIGJlIGltcGxlbWVudGVkIHNpbWlsYXJseSB0byB0aGUgTk1JIHdhdGNoZG9n
LA0KPj4+IGV4Y2VwdCB0aGF0IHRoZSBzeXN0ZW0gd2lsbCByZXNldCBpZiB0aGUgcGluZyBpcyBt
aXNzZWQgcmF0aGVyIHRoYW4NCj4+PiBiYWNrdHJhY2UuDQo+Pj4gSXQgd291bGQgYWxzbyBtZWFu
IHRoYXQgWGVuIHdpbGwgZ2V0IGEgd2hvbGUgd2F0Y2hkb2cgZHJpdmVyLWNhdGVnb3J5DQo+Pj4g
ZHVlIHRvIHRoZSB3YXRjaGRvZyBiZWluZyB2ZW5kb3IgYW5kIHNvbWV0aW1lcyBldmVuIFNvQyBz
cGVjaWZpYyB3aGVuIGl0DQo+Pj4gY29tZXMgdG8gQXJtLg0KPj4+IE15IHVuZGVyc3RhbmRpbmcg
b2YgdGhlIGRvbWFpbiB3YXRjaGRvZyBjb2RlIGlzIHRoYXQgdG9kYXkgdGhlIGRvbWFpbg0KPj4+
IG5lZWRzIHRvIGNhbGwgU0NIRURPUF93YXRjaGRvZyBhdCBsZWFzdCBvbmNlIHRvIHN0YXJ0IHRo
ZSB3YXRjaGRvZw0KPj4+IHRpbWVyLiBTaW5jZSB3YXRjaGRvZyBwcm90ZWN0aW9uIHRocm91Z2gg
dGhlIHdob2xlIGJvb3QgcHJvY2VzcyBpcw0KPj4+IGRlc2lyYWJsZSB3ZSdkIG5lZWQgc29tZSBj
b3JlIGNoYW5nZXMsIHN1Y2ggYXMgYW4gb3B0aW9uIHRvIHN0YXJ0IHRoZQ0KPj4+IGRvbWFpbiB3
YXRjaGRvZyBvbiBpbml0LiA+DQo+Pj4gSXQncyBxdWl0ZSBhIGJpZyBjaGFuZ2UgdG8gbWFrZQ0K
Pj4NCj4+IEZvciBjbGFyaWZpY2F0aW9uLCBhYm92ZSB5b3Ugc2VlbSB0byBtZW50aW9uIHR3byBj
aGFuZ2VzOg0KPj4NCj4+IDEpIEFsbG93IFhlbiB0byB1c2UgdGhlIEhXIHdhdGNoZG9nDQo+PiAy
KSBBbGxvdyB0aGUgZG9tYWluIHRvIHVzZSB0aGUgd2F0Y2hkb2cgZWFybHkNCj4+DQo+PiBJIGFt
IGFzc3VtaW5nIGJ5IGJpZyBjaGFuZ2UsIHlvdSBhcmUgcmVmZXJyaW5nIHRvIDI/DQo+Pg0KPj4g
LCB3aGlsZSBJIGFtIG5vdCBhZ2FpbnN0IGRvaW5nIGl0IGlmIGl0DQo+Pj4gbWFrZXMgc2Vuc2Us
IEkgbm93IHdvbmRlciBpZiBYZW4gc2hvdWxkIG1hbmFnZSBoYXJkd2FyZSB3YXRjaGRvZ3MuDQo+
Pj4gTG9va2luZyBhdCB0aGUgZG9tYWluIHdhdGNoZG9nIGNvZGUgaXQgbG9va3MgbGlrZSBpZiBh
IGRvbWFpbiBkb2VzIG5vdA0KPj4+IGdldCBlbm91Z2ggZXhlY3V0aW9uIHRpbWUsIHRoZSB3YXRj
aGRvZyB3aWxsIG5vdCBiZSBwaW5nZWQgZW5vdWdoIGFuZA0KPj4+IHRoZSBndWVzdCB3aWxsIGJl
IHJlc2V0LiBTbyBlaXRoZXIgd2F0Y2hkb2cgYXBwcm9hY2ggcmVxdWlyZXMgRG9tMCB0bw0KPj4+
IGdldCBleGVjdXRpb24gdGltZS4gRG9tMCBhbHNvIG5lZWRzIHRvIHNlcnZpY2UgYWxsIHRoZSBQ
ViBiYWNrZW5kcyBpdCdzDQo+Pj4gcmVzcG9uc2libGUgZm9yLiBJJ20gbm90IHN1cmUgaXQncyB2
YWx1YWJsZSB0byBhZGQgYW5vdGhlciBsYXllciBvZg0KPj4+IHdhdGNoZG9nIGZvciB0aGlzIHNj
ZW5hcmlvIGFzIHRoZSBlbmQgcmVzdWx0IChjaGVja2luZyB0aGF0IHRoZSBlbnRpcmUNCj4+PiBz
eXN0ZW0gd29ya3MpIGlzIGFjaGlldmVkIHdpdGhvdXQgaXQgYXMgd2VsbC4NCj4+PiBTbywgYmVm
b3JlIEkgdHJ5IHRvIGZpbmQgdGhlIHRpbWUgdG8gbWFrZSBhIHByb3Bvc2FsIGZvciBtb3Zpbmcg
dGhlDQo+Pj4gaGFyZHdhcmUgd2F0Y2hkb2cgYml0IHRvIFhlbiwgZG8gd2UgcmVhbGx5IHdhbnQg
aXQ/DQo+Pg0KPj4gVGhhbmtzIGZvciB0aGUgZGV0YWlscy4gR2l2ZW4gdGhhdCB0aGUgd2F0Y2hk
b2cgaXMgZW5hYmxlZCBieSB0aGUgYm9vdGxvYWRlciwgSSB0aGluayB3ZSB3YW50IFhlbiB0byBk
cml2ZSB0aGUgd2F0Y2hkb2cgZm9yIHR3byByZWFzb25zOg0KPj4gMSkgSW4gdHJ1ZSBkb20wbGVz
cyBlbnZpcm9ubWVudCwgZG9tMCB3b3VsZCBub3QgZXhpc3QNCj4+IDIpIFlvdSBhcmUgcmVseWlu
ZyBvbiBYZW4gKyBEb20wIHRvIGJvb3QgKG9yIGF0IGxlYXN0IGVub3VnaCB0byBnZXQgdGhlIHdh
dGNoZG9nIHdvcmtpbmcpIHdpdGhpbiB0aGUgd2F0Y2hkb2cgaW50ZXJ2YWwuDQo+IA0KPiBEZWZp
bml0ZWx5IHdlIG5lZWQgdG8gY29uc2lkZXIgdGhlIGNhc2Ugd2hlcmUgdGhlcmUgaXMgbm8gRG9t
MC4NCj4gDQo+IEkgdGhpbmsgdGhlcmUgYXJlIGluIGZhY3QgMyBkaWZmZXJlbnQgdXNlIGNhc2Vz
IGhlcmU6DQo+IC0gd2F0Y2hkb2cgZnVsbHkgZHJpdmVuIGluIGEgZG9tYWluIChkb20wIG9yIGFu
b3RoZXIpOiB3b3VsZCB3b3JrIGlmIGl0IGlzIGV4cGVjdGVkDQo+ICAgIHRoYXQgWGVuICsgRG9t
YWluIGJvb3QgdGltZSBpcyB1bmRlciB0aGUgd2F0Y2hkb2cgaW5pdGlhbCByZWZyZXNoIHJhdGUu
IEkgdGhpbmsgdGhpcw0KPiAgICBjb3VsZCBtYWtlIHNlbnNlIG9uIHNvbWUgYXBwbGljYXRpb25z
IHdoZXJlIHlvdXIgc3lzdGVtIGRlcGVuZHMgb24gYSBzcGVjaWZpYw0KPiAgICBkb21haW4gdG8g
YmUgcHJvcGVybHkgYm9vdGVkIHRvIHdvcmsuIFRoaXMgd291bGQgcmVxdWlyZSBhbiBpbml0aWFs
IHJlZnJlc2ggdGltZQ0KPiAgICBjb25maWd1cmFibGUgaW4gdGhlIGJvb3QgbG9hZGVyIHByb2Jh
Ymx5Lg0KDQpUaGlzIGlzIG91ciB1c2UtY2FzZS4gXg0KDQpPdXIgZG9tMCBpcyBtb25pdG9yaW5n
IGFuZCBtYW5hZ2luZyB0aGUgb3RoZXIgZG9tYWlucyBpbiBvdXIgc3lzdGVtLg0KV2l0aG91dCBk
b20wIHdvcmtpbmcgdGhlIHN5c3RlbSBpc24ndCByZWFsbHkgd29ya2luZyBhcyBhIHdob2xlLg0K
DQpASnVsaWVuOiBXb3VsZCB5b3UgYmUgb2sgd2l0aCB0aGUgcGF0Y2ggc2V0IGNvbnRpbnVpbmcg
aW4gdGhlIGRpcmVjdGlvbiANCm9mIHRoZQ0Kb3JpZ2luYWwgcHJvcG9zYWwsIGxldHRpbmcgYW5v
dGhlciBwYXJ0eSAob3IgbWUgYXQgYSBsYXRlciB0aW1lKSBpbXBsZW1lbnQNCnRoZSBmdWxseSBk
cml2ZW4gYnkgWGVuIG9wdGlvbj8NCg0KPiAtIHdhdGNoZG9nIGZ1bGx5IGRyaXZlbiBieSBYZW4u
IE9uZSBtaWdodCB3YW50IHRvIGp1c3QgbWFrZSBzdXJlIHRoZSBoeXBlcnZpc29yIGlzIGFsaXZl
Lg0KPiAtIGh5YnJpZCBtb2RlbCB3aGVyZSB0aGUgd2F0Y2hkb2cgaXMgZHJpdmVuIGJ5IFhlbiB1
bnRpbCBhIGRvbWFpbiBjb21lcyB1cCB0byBkcml2ZSBpdC4NCj4gICAgVGhpcyBjb3VsZCBtYWtl
IHNlbnNlIHRvIHJlbGF4IHRoZSBzdHJlc3Mgb24gYm9vdCB0aW1lIGJ1dCB3b3VsZCByYWlzZSB0
aGUgcXVlc3Rpb24gb2YNCj4gICAgIHdoYXQgc2hvdWxkIGJlIGRvbmUgaWYgdGhlIGRvbWFpbiBk
aWVzLiBUaGlzIGlzIGFsc28ga2luZCBvZiBjb21wbGV4IGFzIFhlbiBzaG91bGQgc3RvcA0KPiAg
ICAgcmVmcmVzaGluZyB0aGUgd2F0Y2hkb2cgd2hlbiBhIGRvbWFpbiBzdGFydHMgZG9pbmcgaXQg
KG1pZ2h0IHJlcXVpcmUgYSB0cmFwIGFuZCBlbXVsYXRlDQo+ICAgICBpbml0aWFsbHkgdGhhdCBp
cyB0aGVuIG1hcHBlZCBkaXJlY3RseSB0byBhIGRvbWFpbikuIEkgYW0gbm90IGNvbXBsZXRlbHkg
c3VyZSB0aGlzIG1ha2VzIHNlbnNlLg0KPiANCj4gUmVnYXJkcw0KPiBCZXJ0cmFuZA0KPiANCg0K
VGhhbmtzIGFuZCBiZXN0IHJlZ2FyZHMgLy8gSm9obiBFcm5iZXJnDQo=


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 16:30:04 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 16:30:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696048.1086590 (Exim 4.92)
	(envelope-from )
	id 1rmypD-00068v-Ie; Wed, 20 Mar 2024 16:29:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696048.1086590; Wed, 20 Mar 2024 16:29:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmypD-00068F-Ej; Wed, 20 Mar 2024 16:29:59 +0000
Received: by outflank-mailman (input) for mailman id 696048;
 Wed, 20 Mar 2024 16:29:59 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmypC-000689-Th
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 16:29:58 +0000
Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com
 [2607:f8b0:4864:20::730])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 170721cd-e6d7-11ee-afdd-a90da7624cb6;
 Wed, 20 Mar 2024 17:29:58 +0100 (CET)
Received: by mail-qk1-x730.google.com with SMTP id
 af79cd13be357-78a16114b69so8092085a.0
 for ; Wed, 20 Mar 2024 09:29:57 -0700 (PDT)
Received: from localhost ([85.31.135.62]) by smtp.gmail.com with ESMTPSA id
 l9-20020ae9f009000000b0078861edc3bdsm6711040qkg.2.2024.03.20.09.29.55
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 20 Mar 2024 09:29:56 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 170721cd-e6d7-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710952197; x=1711556997; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=7r5Q7B8bIUOlAyeCcnPEwggJ2q1S0IrMTxc9KNn6ilU=;
        b=KdyO7vidIZit2E3TsJE8o8VgCWrTJ703t1RNvtZ0SY1E5lZAtCxsYwX7SsEgqs8JJg
         0+L/EjI8a8tB1bzLEuBrhSZkhJRCX52duQMnZAkQ3NLNsgt5UeVgPb3rXJd3E8ObKiQg
         WdPP2J+iJFw9HqarKBx0g9qNk/yLX2vt+TX14=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710952197; x=1711556997;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=7r5Q7B8bIUOlAyeCcnPEwggJ2q1S0IrMTxc9KNn6ilU=;
        b=E3G8MVMOD9ijY2QaS3Xlubh+1ClK+Gscf8zHZEf0u6KRiiJOcTJ/FywFGcoyGs3KWE
         pX832xuC7mAjm3X5h/8ObmSsJNoypit8A9p/g2OrNaXRAPceQlLqSwLGFJuByFgbK0JK
         G530wc4qx4grmiiz6e3EfbP+ODovwcgy8CozzCT6nJ3fqQ7BgfxH4rDxJu1RYYnL+Zaq
         37nzu1hI1MYsnD4WfBQHYUGAcfUovBC81duzRyTv9OtwVcscbjNgCayc2RFlLRCbc/Fo
         fYhy0vauFLD2sPQB7GSZubOrsMM51yn99L0jH5TZSzcLLU8zyOBBHA0oo4kY48by5IsI
         BFMw==
X-Forwarded-Encrypted: i=1; AJvYcCVO9aj1VHSqcEUK69zfOZSB6G6XhQstYS08Rynp/irt1DKTUMtaZJf/F1pmZv7ckjJ0ugR/ueK4MSTP8Iz8rmXANaIS6xxj35C08/iFmr8=
X-Gm-Message-State: AOJu0Yx8V5606KuBPWyzx6WgV+1uqYsU5GSTYeexZy5+gYUBxPPjnq/K
	EaVz9BuRks2aantU2HeAXVa1mj6RuMW9cziCt6hxaAYmYLvJyyaYxAa8NYg6+Ng=
X-Google-Smtp-Source: AGHT+IGflJ6/PjoGnpk2VtQ6G8sI57xM+h5WcOO0OrGdwwLunWMGSKcbU0NJcYUySiRw4WTbmZpnUA==
X-Received: by 2002:a05:620a:7f1:b0:78a:1fda:7f1d with SMTP id k17-20020a05620a07f100b0078a1fda7f1dmr243172qkk.29.1710952196690;
        Wed, 20 Mar 2024 09:29:56 -0700 (PDT)
Date: Wed, 20 Mar 2024 17:29:54 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: Andrew Cooper ,
	George Dunlap ,
	Julien Grall ,
	Stefano Stabellini , Wei Liu ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH] x86/vcpu: relax VCPUOP_initialise restriction for non-PV
 vCPUs
Message-ID: 
References: <20240320135720.68894-1-roger.pau@citrix.com>
 <73314dc5-0145-4aa7-a3cd-23c943235392@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <73314dc5-0145-4aa7-a3cd-23c943235392@suse.com>

On Wed, Mar 20, 2024 at 04:09:33PM +0100, Jan Beulich wrote:
> On 20.03.2024 14:57, Roger Pau Monne wrote:
> > There's no reason to force HVM guests to have a valid vcpu_info area when
> > initializing a vCPU, as the vCPU can also be brought online using the local
> > APIC, and on that path there's no requirement for vcpu_info to be setup ahead
> > of the bring up.  Note an HVM vCPU can operate normally without making use of
> > vcpu_info.
> 
> While I'd agree if you started with "There's no real need to force ...", I
> still think there is a reason: If one wants to use paravirt interfaces (i.e.
> hypercalls), they would better do so consistently. After all there's also
> no need to use VCPUOP_initialise, yet you're not disabling its use.
> 
> As said in reply to Andrew's reply, besides acting as a sentinel that
> structure instance also acts as a sink for Xen accesses to a vCPU's
> vcpu_info. By removing the check, you switch that from being a safeguard to
> being something that actually has to be expected to be accessed. Unless
> you've audited all uses to prove that no such access exists.

I'm kind of lost in this last paragraph, how is that different than
what currently happens when an HVM vCPU >= 32 is brought up using the
lapic and has no vpcu_info mapped?

Also, from a quick look it seems like sites do check whether vcpu_info
== dummy_vcpu_info, otherwise we would already be in trouble.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 16:34:18 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 16:34:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696052.1086599 (Exim 4.92)
	(envelope-from )
	id 1rmytN-000883-1E; Wed, 20 Mar 2024 16:34:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696052.1086599; Wed, 20 Mar 2024 16:34:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmytM-00087w-Uy; Wed, 20 Mar 2024 16:34:16 +0000
Received: by outflank-mailman (input) for mailman id 696052;
 Wed, 20 Mar 2024 16:34:16 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmytM-00087q-8t
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 16:34:16 +0000
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com
 [2a00:1450:4864:20::22c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b0c19259-e6d7-11ee-afdd-a90da7624cb6;
 Wed, 20 Mar 2024 17:34:15 +0100 (CET)
Received: by mail-lj1-x22c.google.com with SMTP id
 38308e7fff4ca-2d2509c66daso595551fa.3
 for ; Wed, 20 Mar 2024 09:34:15 -0700 (PDT)
Received: from perard.uk.xensource.com (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 ay18-20020a05600c1e1200b004146d785508sm2129380wmb.0.2024.03.20.09.34.13
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 20 Mar 2024 09:34:14 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b0c19259-e6d7-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1710952455; x=1711557255; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=uvMEuNr6O04CiFhFcy0dXvBSyQpFdx0edVtZKpJyXnE=;
        b=N2P8s/PBDaRU2pMhlNmwp1Aq9+6zUXcevgCh4bQVw3g6Xv0iPhr88Ie7hMtEHZHned
         BapIDNtQdZPunIHjb43woqaRFcleBUWbWcmPPH4W8aVNeuJ18jte1MjMfmffQ/Yycx3R
         BA5yJSEAsWM9ZWt5TJkYk2B4VZdMhya0dZtkY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710952455; x=1711557255;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=uvMEuNr6O04CiFhFcy0dXvBSyQpFdx0edVtZKpJyXnE=;
        b=mY5Z4w+OjLX1u9poE5FThCRBu8vS0acE9qhdtLfMQMW9+BmdcXm5PARGaiKdf67W4p
         5Q+NUiLvvcu5HAaH8WhaiJ4B6s3eEoL+zxJCGGkT9XXwVo4WFTZX/Au9GGYFfJRU1z9o
         OwdIdXCGYW7HE/pEzxLatk9zPp5Sr6bHjRzUelalajRTo2y2VaO8TJvSI3XT6KRopCT0
         P0Tr6k7Uus5Q8nNxX5/Lwf8dhoNA0Tp5VTT5E6/n8a/UdfDh91YKCgzz398B/gNmnhpn
         EezQ4TqSv9MFHK0DKaigBw2ftGktoBKc3WJBXdq1GIslgVd2xtdRyMqdAPj2mEU/PYwa
         GjLA==
X-Gm-Message-State: AOJu0Yz41WrGjK5QZAk4oiZrMeltV+yrqUf0U9EFQ5B6JJ3zzWdqMb6w
	ZcV3HRnYUnYrSj7dtFh66aMVsqWfWmM5LPqvouKYXzxvGCP7sqCQQ6cjowyeEsBnzb6vBTRMw5i
	c
X-Google-Smtp-Source: AGHT+IEzCkO5Fyo9QWXXnKguYupKnS636o1SmCj6ETK13Qm/YvMUOiTsECGL232xZOJ3/S7taL+WDw==
X-Received: by 2002:a2e:98c2:0:b0:2d3:d9fd:568d with SMTP id s2-20020a2e98c2000000b002d3d9fd568dmr12544051ljj.8.1710952454789;
        Wed, 20 Mar 2024 09:34:14 -0700 (PDT)
Date: Wed, 20 Mar 2024 16:34:13 +0000
From: Anthony PERARD 
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= 
Cc: xen-devel@lists.xenproject.org
Subject: Re: [OSSTEST PATCH 02/36] ts-xen-build-prep: Only force git protocol
 v2 on buster
Message-ID: <7a96afa1-8a91-4a2d-ac85-94950ae1f9e6@perard>
References: <20240318165545.3898-1-anthony.perard@citrix.com>
 <20240318165545.3898-3-anthony.perard@citrix.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Wed, Mar 20, 2024 at 04:20:00PM +0100, Roger Pau Monn wrote:
> On Mon, Mar 18, 2024 at 04:55:11PM +0000, Anthony PERARD wrote:
> > Newer version of Debian and thus git would use this automatically, no
> > need to force it.
> > 
> > Signed-off-by: Anthony PERARD 
> > ---
> >  Osstest/TestSupport.pm | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
> > index f0e087aa..0dded9b2 100644
> > --- a/Osstest/TestSupport.pm
> > +++ b/Osstest/TestSupport.pm
> > @@ -3257,7 +3257,7 @@ END
> >  
> >      # Adding mandadory use of Git protocol v2
> >      # necessary on buster when building QEMU v8.1
> > -    $gitcfg .= < > +    $gitcfg .= <{Suite} =~ m/buster/;
> >  [protocol]
> >  	version = 2
> 
> Do we need to limit ourselves to version 2 for the git cache stuff, or
> that doesn't matter?

It's not a limitation, this settings forces `git` to use an experimental
feature. In buster, git still default to version 1, which was an issue
for a single git repo, one of QEMU's meson wrap dependency.

In bookworm, git default to version 2, so I don't think there's need to
deviate from default beyond buster.

Once git-cache-proxy knows how to handle this version=2, and pass it on
to `git-upload-pack`, it will know how to handle v3 and beyond.

> I'm wondering whether it case version 3 of the protocol appears we
> would be in trouble by not having version = 2 in the config file.

No, git should be able to negotiate with itself. Even today, if a git
server only have protocol v1, it will just ignore that a client ask for
v2.

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 16:38:27 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 16:38:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696055.1086612 (Exim 4.92)
	(envelope-from )
	id 1rmyxL-0000nO-Hp; Wed, 20 Mar 2024 16:38:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696055.1086612; Wed, 20 Mar 2024 16:38:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmyxL-0000nH-FE; Wed, 20 Mar 2024 16:38:23 +0000
Received: by outflank-mailman (input) for mailman id 696055;
 Wed, 20 Mar 2024 16:38:22 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmyxK-0000nB-9a
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 16:38:22 +0000
Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com
 [2607:f8b0:4864:20::72f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 42810574-e6d8-11ee-a1ee-f123f15fe8a2;
 Wed, 20 Mar 2024 17:38:20 +0100 (CET)
Received: by mail-qk1-x72f.google.com with SMTP id
 af79cd13be357-789e70d7c07so4752485a.1
 for ; Wed, 20 Mar 2024 09:38:20 -0700 (PDT)
Received: from localhost ([85.31.135.62]) by smtp.gmail.com with ESMTPSA id
 k18-20020a05620a0b9200b00789fe83b050sm3280675qkh.78.2024.03.20.09.38.18
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 20 Mar 2024 09:38:19 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 42810574-e6d8-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710952699; x=1711557499; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=pwvBsWrTVhu00Fq5EFiwRJ76Vn375jjCvCvO5Vl/ebk=;
        b=Vzh02c9tcrOnJZZMX3lky40LmICrZDMVU59RINe/EsC2Jm4lUXxq/Lv0XcffAVnUVJ
         ku7FBeKWd37AO1d/SQsklLENKqfOrnb0f9hDsf/e0h/iBbnl97KQizq6P9PC1vx0tMIc
         X8YW9RRMM9N7ypAb9tnIvfy1TjFX7FFFJaV3s=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710952699; x=1711557499;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=pwvBsWrTVhu00Fq5EFiwRJ76Vn375jjCvCvO5Vl/ebk=;
        b=xPKgLNd8jFwMEp3CwAlK6ZidElJsDwJcG3SCJXC1vnV3ivJdZWLGV8PzJNF6KKaWd1
         xWr/f8dOE/zhhq6ZhpbawcsDEsMx5eYb8MSxXcj+6Dka3fcYwCeORNixHzVBmaNuxo83
         RL7NLv983lqKobl7asR0dxGuF3LNEf+/OCz/syWkAhqcw3AmqddHKFPFDFC65VBWbDoo
         wyvR8iTF468ADCOhUHl4wwNL5EvmUKLF88T4RG7s3C3XHNZOGNBeIQ6RAQvnxcCyiW3v
         tFnq1gg+one4a4hKGx6VzeezsoMxmtVMJ6cflUP3LmDrNjbbK8TRd1nLr93aB7CagssB
         bvHg==
X-Gm-Message-State: AOJu0YxritbeK7gzvnrdj0/5exmkwTUWE/9RM/xrc1rV1+i9jrKWSr+t
	2qmXMTZS4aIkrg1X/+O3Fbikmp5ZFH6ItA2JwWjW5GqWDm4CuFC/mfKqozt0Xxs=
X-Google-Smtp-Source: AGHT+IG8Jg/VQAnI4r9TtMjSaXzMRJ4tbz93uWeGqNFw4KyeWF1dV8f/KmdGbZCWhuBDHdJaznEJRQ==
X-Received: by 2002:a05:620a:1a1d:b0:788:2e94:ead8 with SMTP id bk29-20020a05620a1a1d00b007882e94ead8mr3065390qkb.42.1710952699365;
        Wed, 20 Mar 2024 09:38:19 -0700 (PDT)
Date: Wed, 20 Mar 2024 17:38:17 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Anthony PERARD 
Cc: xen-devel@lists.xenproject.org
Subject: Re: [OSSTEST PATCH 10/36] preseed_create: Workaround fail
 grub-install on arndale
Message-ID: 
References: <20240318165545.3898-1-anthony.perard@citrix.com>
 <20240318165545.3898-11-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20240318165545.3898-11-anthony.perard@citrix.com>

On Mon, Mar 18, 2024 at 04:55:19PM +0000, Anthony PERARD wrote:
> grub-installer on arndale-* machine fails with Debian Bookworm. It
> tries to install "grub-pc" which doesn't exist. Skip installation.
> 
> Somehow, cubietruck-* installation works fine.

I'm kind of puzzled by this, as cubietruck and arndales are both armhf
IIRC? (IOW: they should use the same repo?)

Does the install of grub-pc succeed on the cubietruck, or is skipped
for some other reason that doesn't require us to intervene?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 17:24:38 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 17:24:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696060.1086625 (Exim 4.92)
	(envelope-from )
	id 1rmzfr-0002ZT-V8; Wed, 20 Mar 2024 17:24:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696060.1086625; Wed, 20 Mar 2024 17:24:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmzfr-0002ZM-Rz; Wed, 20 Mar 2024 17:24:23 +0000
Received: by outflank-mailman (input) for mailman id 696060;
 Wed, 20 Mar 2024 17:24:22 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmzfq-0002ZG-3E
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 17:24:22 +0000
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com
 [2a00:1450:4864:20::333])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id afe7d836-e6de-11ee-afdd-a90da7624cb6;
 Wed, 20 Mar 2024 18:24:20 +0100 (CET)
Received: by mail-wm1-x333.google.com with SMTP id
 5b1f17b1804b1-4140aadfe2eso435415e9.1
 for ; Wed, 20 Mar 2024 10:24:20 -0700 (PDT)
Received: from localhost ([85.31.135.62]) by smtp.gmail.com with ESMTPSA id
 j14-20020a05600c190e00b004146bcdde06sm2768051wmq.6.2024.03.20.10.24.19
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 20 Mar 2024 10:24:19 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: afe7d836-e6de-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710955460; x=1711560260; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=+GSCW/et+/cuSC+C66lOB512CEMQEN1JIwWBev3CIlU=;
        b=tdV9aNYdPLyYboWWzRAkLCkX0EPnOH9Yx0gcgON93lxOCiuAqRyR41nZ3Monw7zfMk
         GHH3V9Kvn/SWgpZGAkHB2ar8ViYEBIk56tEWUTpoAs5WU+8OF3cb31kIh6lqwgiY8XPA
         Bz1YCSBBVwwnViJBK2amlPswZld6ys2Nkqz+Y=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710955460; x=1711560260;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=+GSCW/et+/cuSC+C66lOB512CEMQEN1JIwWBev3CIlU=;
        b=fD9ltznNlY0avJmnNytsNr+bFLBOI41TSxe6CS911QSfKZkMFY3RuUEmRIRuOEy5wo
         YYMptC8QDUQT2SmpkuQ6ND8iZpapTt7VXHH1uJIxdXKl0lHfVCtOvwHS6PUXaDG6P1zl
         Y9r4KlH5qiOj/XhbCtiAD0XLMkuPgxFI1rnUZf9I2CLSoPYDYir/ZoFdRyY2BDlc8Y+/
         n6oMvPt8mzMoW1enP0GRuZsAnS29Mgd3ViI51JNOqb5cYx4+URNHicTE42wlFFRRKqWb
         Dn5nAjdhAv5R12IhVuP1XlLeu34i9gVEgax6GL+Qgpg9dlC82I2R97KRiUzbaKBoWgHm
         SgFA==
X-Gm-Message-State: AOJu0YyxQ7GB5I8rpR7I549MU063Uxu+nwGaKGUt3KcgOFwCdVi3Kvje
	mRe7iSNEePfRZ0T7EdSQo7iZDoV64ESl7f01y99l6KVBFIHVV9caGtTflOea/ZI=
X-Google-Smtp-Source: AGHT+IFw7+JTWMwVL4XS7qMBohGuGZb734jJDXyLUx14qrZ56OLgJAbm4GT6bGl1ywjGm2yXn5ImkQ==
X-Received: by 2002:a05:600c:4f53:b0:414:ed4:e959 with SMTP id m19-20020a05600c4f5300b004140ed4e959mr8991505wmq.41.1710955459859;
        Wed, 20 Mar 2024 10:24:19 -0700 (PDT)
Date: Wed, 20 Mar 2024 18:24:18 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Anthony PERARD 
Cc: xen-devel@lists.xenproject.org
Subject: Re: [OSSTEST PATCH 33/36] make-flight: Keep using buster for L2
 guest in nested tests
Message-ID: 
References: <20240318165545.3898-1-anthony.perard@citrix.com>
 <20240318165545.3898-34-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20240318165545.3898-34-anthony.perard@citrix.com>

On Mon, Mar 18, 2024 at 04:55:42PM +0000, Anthony PERARD wrote:
> When starting the installation of the L2 guest, L0 kills L1. Switching
> the L2 guest back to Debian Buster works fine, so do that to prevent
> regression in the test.
> 
> Part of the logs from the host L0:
> 
> > domain_crash called from arch/x86/hvm/vmx/vvmx.c:2770
> > Domain 3 (vcpu#0) crashed on cpu#4:
> > d3v0 vmentry failure (reason 0x80000021): Invalid guest state (2)

Hm, I guess we need this as otherwise the changes themselves won't
past the self-push gate, but this is just masking a real issue.  I
would be tempted to (after the switch to bookworm has gone in) revert
this and force-push it into osstest, so that the failure is visible.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 17:25:45 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 17:25:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696063.1086635 (Exim 4.92)
	(envelope-from )
	id 1rmzhA-00038Q-BW; Wed, 20 Mar 2024 17:25:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696063.1086635; Wed, 20 Mar 2024 17:25:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmzhA-00038J-8u; Wed, 20 Mar 2024 17:25:44 +0000
Received: by outflank-mailman (input) for mailman id 696063;
 Wed, 20 Mar 2024 17:25:43 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmzh9-00037z-Cg
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 17:25:43 +0000
Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com
 [2a00:1450:4864:20::330])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id dd8bbb44-e6de-11ee-a1ee-f123f15fe8a2;
 Wed, 20 Mar 2024 18:25:37 +0100 (CET)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-4146e9e45c8so4173315e9.1
 for ; Wed, 20 Mar 2024 10:25:37 -0700 (PDT)
Received: from localhost ([85.31.135.62]) by smtp.gmail.com with ESMTPSA id
 t17-20020a05600c199100b004146e58cc32sm1911117wmq.12.2024.03.20.10.25.36
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 20 Mar 2024 10:25:36 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: dd8bbb44-e6de-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710955536; x=1711560336; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=/W91Cw2Z2fkYDLMg00evVnqcafw1of2POz2rXlgwAX4=;
        b=O4rWVsy35kmhYaLxmNJkq4cyuWSFYZiO65GrgNVtVL4kwXQKZ4gEKfrAKO7KFSC6LT
         xYszoLlQ3GeNssfnjbocFF8W1JIFPFWplhA/NPeyl06thLV1zRPK6mS23ILgKpW6PxwP
         Vtxuj3syQfK3w99TM39neDhjjtXXQI8d9zYCg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710955536; x=1711560336;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=/W91Cw2Z2fkYDLMg00evVnqcafw1of2POz2rXlgwAX4=;
        b=DZ/1O0pCGOiK9+OV9r7sQxG1KeAZWnc3CGyF4rjt5fpXSFPHVhonqSRp4Nk39Eb2L2
         h/Kk8KMURg1T/BwEPSdtFNMjpDbPqRusGosahW5KRzADbC9ggVRHkjBvQapnfKoe/a77
         j+7Ol9iqfVZVYPxlVfki6ZPx1T9N0fc+E48wt5C7k83MpMWLqxsNuVjbzOU7gBT8DEtp
         i+R1UGC3igXwqYcXri9kxu/KBkRKpOOcgHbGrtjeQohOvnCrREzptX00vpdzMX/6MZCI
         l4YtNMgC8AxM1nC4Fu1XAWPYPc1WeDg+wzcrBzM7huY93bUz1QgzPlXJKZ1y8fWWL/5q
         ct3g==
X-Gm-Message-State: AOJu0Yysz0zoAB6xOhylc3PFlrb0BkRXP3Ddhmwa5QWasc8UxAOHPisD
	ewl9Dk5xEZrJBr76gLUJvsm7OTP9f1jExJtVO1GsbPrQ9SqeLRL8Pm6U3xx2KwmhA/moHuf/yKv
	8
X-Google-Smtp-Source: AGHT+IFCenay4mVnklWkkQuoCbC4rGNxWIib9ryue8HZZ722Oqn9axQvatfND+xgcsyRie6vbQcl8w==
X-Received: by 2002:a05:600c:4e04:b0:414:ea1:451 with SMTP id b4-20020a05600c4e0400b004140ea10451mr308217wmq.2.1710955536470;
        Wed, 20 Mar 2024 10:25:36 -0700 (PDT)
Date: Wed, 20 Mar 2024 18:25:35 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Anthony PERARD 
Cc: xen-devel@lists.xenproject.org
Subject: Re: [OSSTEST PATCH 34/36] Temporally switch "qemu-mainline" branch
 to Bookworm
Message-ID: 
References: <20240318165545.3898-1-anthony.perard@citrix.com>
 <20240318165545.3898-35-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20240318165545.3898-35-anthony.perard@citrix.com>

On Mon, Mar 18, 2024 at 04:55:43PM +0000, Anthony PERARD wrote:
> QEMU doesn't build on buster anymore.
> 
> This should be remove once bookworm is the default suite.

Is this change required anymore, patch 35 makes bookworm the default,
hence it seems pointless to switch QEMU just one patch ahead.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 17:26:43 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 17:26:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696065.1086646 (Exim 4.92)
	(envelope-from )
	id 1rmzi7-0003fN-K0; Wed, 20 Mar 2024 17:26:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696065.1086646; Wed, 20 Mar 2024 17:26:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmzi7-0003fG-HQ; Wed, 20 Mar 2024 17:26:43 +0000
Received: by outflank-mailman (input) for mailman id 696065;
 Wed, 20 Mar 2024 17:26:42 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmzi6-0003f6-EA
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 17:26:42 +0000
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com
 [2a00:1450:4864:20::335])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 040c3d59-e6df-11ee-afdd-a90da7624cb6;
 Wed, 20 Mar 2024 18:26:41 +0100 (CET)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-4146a1b6faaso641025e9.1
 for ; Wed, 20 Mar 2024 10:26:41 -0700 (PDT)
Received: from localhost ([85.31.135.62]) by smtp.gmail.com with ESMTPSA id
 bd7-20020a05600c1f0700b004146ece5cf1sm1465612wmb.34.2024.03.20.10.26.40
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 20 Mar 2024 10:26:40 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 040c3d59-e6df-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710955601; x=1711560401; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=WdCRJa+U6ncczwulAwFsu6+kl26hXYbYFKcPPENVGjw=;
        b=gPrF4auBMjOT5zlV/AlMt8Zt5U3UmstZrXk8I5BZhsI6GTQFVbi4cizflQ+oFmIYTL
         diqIZsKxJ5gOyI/3Vy5bBZPO63O30loEDovMXdjjLuNkwoRA+lnG+qlwcGM5ctREtCIa
         DtdTkzduowd4t2JxOIgbto0i0WyXQ3gjeXlEg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710955601; x=1711560401;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=WdCRJa+U6ncczwulAwFsu6+kl26hXYbYFKcPPENVGjw=;
        b=U/pYwEzXv3ZuoUE/9p9lQ3Px7r/Fgo/s7DCHZDF1fn8oo+R/cEKBiTgVq4XzLNyKH6
         rb+haw7L8bI4gd5VW1Ivrf0nVFI7nJyEUdjmQafKZTWoftJRgWHExbu42Orz5btfGDa5
         gfMTyoJu7+5YuqfcsoWzk2JdTErvoHgy2X06nOisN4cdZ2E5y2lxEXEBT3o7ePSJNjwW
         FUAgWRiKd5OUp9QGckV0Ah7yhTW1ei+sLGvd1PSBkRHPJuVwhdF/excAUeJqirO7IZMd
         0gaZ2Tu9K23+jB9scUFG5q929Y7tMa9O69muMikTWs2DM/diGjeGa6MmJjEZDxIfdtHY
         N8qg==
X-Gm-Message-State: AOJu0Yy7HiG6Y4QbUTtdDYOjjF6ZMbE2FaIwFtIalBLFgZXGHfxkLAaG
	KklhFtTp8Xc7ZqFgaDqe+SonrZe1uV4netDN0ETFA9bZhnagpQZ126bOp4/6WVjlcv/zRIS1OdO
	K
X-Google-Smtp-Source: AGHT+IFAUiA9SbdG9DSwqwxiKUiVAqqFz6VeaFH3+f4BvkQWkutTfnZU86k67U6x4Fc2XrxO8vfuqQ==
X-Received: by 2002:a05:600c:a0b:b0:414:21b:9a92 with SMTP id z11-20020a05600c0a0b00b00414021b9a92mr12150552wmp.8.1710955601046;
        Wed, 20 Mar 2024 10:26:41 -0700 (PDT)
Date: Wed, 20 Mar 2024 18:26:40 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Anthony PERARD 
Cc: xen-devel@lists.xenproject.org
Subject: Re: [OSSTEST PATCH 35/36] Switch to Debian Bookworm as default suite
Message-ID: 
References: <20240318165545.3898-1-anthony.perard@citrix.com>
 <20240318165545.3898-36-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20240318165545.3898-36-anthony.perard@citrix.com>

On Mon, Mar 18, 2024 at 04:55:44PM +0000, Anthony PERARD wrote:
> Xen 4.17 doesn't build with Debian Bookworm. It fails to build
> IPXE/etherboot, on "amd64". So we keep using Debian Buster on Xen 4.18
> and earlier branches. Xen 4.18 builds 4.17 via job "build-amd64-prev".
> 
> Xen 4.17 would needs 18a36b4a9b08 ("tools: ipxe: update for fixing
> build with GCC12") which is only in Xen 4.18.

I would request the backport to 4.17.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 17:28:47 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 17:28:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696068.1086656 (Exim 4.92)
	(envelope-from )
	id 1rmzk6-0004M5-0V; Wed, 20 Mar 2024 17:28:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696068.1086656; Wed, 20 Mar 2024 17:28:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmzk5-0004Ly-Ss; Wed, 20 Mar 2024 17:28:45 +0000
Received: by outflank-mailman (input) for mailman id 696068;
 Wed, 20 Mar 2024 17:28:45 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmzk5-0004Ft-6w
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 17:28:45 +0000
Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com
 [2a00:1450:4864:20::330])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4d43b9bc-e6df-11ee-afdd-a90da7624cb6;
 Wed, 20 Mar 2024 18:28:44 +0100 (CET)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-4146a1b6faaso661415e9.1
 for ; Wed, 20 Mar 2024 10:28:44 -0700 (PDT)
Received: from localhost ([85.31.135.62]) by smtp.gmail.com with ESMTPSA id
 bj26-20020a0560001e1a00b0033ed84facdbsm11930968wrb.82.2024.03.20.10.28.43
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 20 Mar 2024 10:28:43 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4d43b9bc-e6df-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710955724; x=1711560524; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=I9dN+XTUUOK5ZHJ5lslw35YULw6D3k2GJmTl0TRjSnQ=;
        b=kGjMl9oGMpil/DvHuWC7LC6si/0tEpaxg8woiZ5+uElTphcutW2TJ4Yy2ddV4NwN3F
         QuLjBJmuLK/e1U7Fmp15HoCKqDkZHH1RincP7J5tCPxly9njcXbfh3wH3s2x/uPnowce
         l8u9pl+Pp8zqSqgnd4NK/n6XGOR5PhstGHi9E=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710955724; x=1711560524;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=I9dN+XTUUOK5ZHJ5lslw35YULw6D3k2GJmTl0TRjSnQ=;
        b=NGUcJ8bDJz2HXpZ+DXnuYDN2tSr53dSRea9Xcl8WhQA1cFXbXlyOu4CpXz9tXMGiip
         TMBnIT9xCS3t6PR9PBiwHLiALSXiNc+ewc7k0oi54eCYu6SWrIAHcqKtkdcRCbrYoKVY
         SXJfl19c+Cy9O5EWuIpzLlldTNa55hnuBQw2RrVcPo2lemr9Dy4ClVWbozAHubDLyqob
         7r8UBL83OfgVBaVuVvt0akARL6l8u0Dvx+INXtLrDyNfq3oLvNxIQyQdZFS8XdlV4hKr
         eBwVLmjJ6WheHRpI6e78KTXJJEixldJiugwxVjdMzOkgSZt7CGsnkaLU6IocTjgQQuCh
         gpXg==
X-Gm-Message-State: AOJu0Yxwsd7wgIayv93yyVi70Gpi2tS7mPtLDvF2QRaeXktm5UaLXkK3
	Y8rRmYCl2LKcqFJEdlR9kNJ0vEZgyfJ72qEiLW3B/16T8Sqi1NU4VOpVW1n09dANakZwK28f2wh
	3
X-Google-Smtp-Source: AGHT+IGzW3JppBGBwrkjXrmch7N+lAOKTCTxNy97HLWa2SiXPzKPaGHdw1xQg6Y0ANgI30RoyLjWjw==
X-Received: by 2002:a05:600c:4ed3:b0:413:f4d1:199e with SMTP id g19-20020a05600c4ed300b00413f4d1199emr13357327wmq.31.1710955723942;
        Wed, 20 Mar 2024 10:28:43 -0700 (PDT)
Date: Wed, 20 Mar 2024 18:28:42 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Anthony PERARD 
Cc: xen-devel@lists.xenproject.org
Subject: Re: [OSSTEST PATCH 00/36] Switch to Debian Bookworm
Message-ID: 
References: <20240318165545.3898-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20240318165545.3898-1-anthony.perard@citrix.com>

On Mon, Mar 18, 2024 at 04:55:09PM +0000, Anthony PERARD wrote:
> Patch series available in this git branch:
> https://xenbits.xen.org/git-http/people/aperard/osstest.git br.bookworm-v1
> 
> Hi,
> 
> I intend to push this series in two waves.
> 
> First, push up to commit "Temporally switch "qemu-mainline" branch to
> Bookworm". This is to test that osstest still works fine if we need to use
> "buster" for a branch. Also upstream QEMU doesn't build on buster anymore, so
> I've included a commit to use bookworm for it.
> 
> Second, push the remaning two patches, at least a week later, which will switch
> the default debian suite.
> 
> I did run many tests, but hopefully nothing breaks.
> 
> Cheers,
> 
> Anthony PERARD (36):
>   production-config: Add bookworm debian install media filename
>   ts-xen-build-prep: Only force git protocol v2 on buster
>   mgi-common: Fix fetch_debian_package error message
>   mg-debian-installer-update: Download non-free firmware from new repo.
>   ts-host-install: fix ntp.conf path on bookworm
>   ts-host-install: fix ntp server setting
>   ts-host-install: Restart ntp service
>   preseed_create: Use new "d-i grub-installer/update-nvram" for UEFI
>     installation
>   preseed_create: osstest-erase-other-disks: workaround creating
>     /dev/sdXD files
>   preseed_create: Workaround fail grub-install on arndale
>   ts-host-install,preseed_create: Do lvm vgextend at install time
>   di_installcmdline_core: Add link_wait_timeout to install cmdline
>   Disable persistent net generator on Bookworm
>   preseed_base, ts-host-install: Change NIC NamePolicy to "mac"
>   ts-xen-build-prep: Change package selection for Bookworm
>   bl_getmenu_open: Read grub.cfg as root
>   target_editfile: Use the same user to retrieve and send
>   ts-xen-install: remove "libc6-xen" package installation
>   overlay-bookworm: Import grub's 20_linux_xen from Debian Bookworm
>   overlay-bookworm: 20_linux_xen: Fix XSM entries generation
>   ts-xtf-install: Install python symlink
>   setupboot_grub2: Parse arm64 uefi grub verbes
>   bookworm: Extend ARM clock workaround
>   ts-nested-setup, setup l1 lvm volume groupe in guest
>   ts-leak-check: add new name for udevd workers
>   ts-debian-hvm-install: Allow udev failure in install media
>   ts-debian-fixup: Fix nic names for bookworm
>   ts-debian-install: keep avoiding to use pygrub
>   ts-debian-hvm-install: Increase min guest ram size
>   bookworm: Extend guest bootloader workaround
>   ts-debian-*-install: Replace dots in hostnames by dashs
>   ts-xen-install: Fix bridge setup, ask to copy MAC addr
>   make-flight: Keep using buster for L2 guest in nested tests
>   Temporally switch "qemu-mainline" branch to Bookworm
>   Switch to Debian Bookworm as default suite
>   make-hosts-flight: default to bookworm

Acked-by: Roger Pau Monné 

I just had a look over the commit messages mostly, as I'm not very
much into perl as to provide more accurate reviews, sorry.  LGTM, just
some comments/questions on a few patches.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 17:40:01 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 17:40:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696073.1086665 (Exim 4.92)
	(envelope-from )
	id 1rmzur-00075D-Um; Wed, 20 Mar 2024 17:39:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696073.1086665; Wed, 20 Mar 2024 17:39:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmzur-000756-S2; Wed, 20 Mar 2024 17:39:53 +0000
Received: by outflank-mailman (input) for mailman id 696073;
 Wed, 20 Mar 2024 17:39:52 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmzuq-00074i-FW
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 17:39:52 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.129.124])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d9a04aab-e6e0-11ee-a1ee-f123f15fe8a2;
 Wed, 20 Mar 2024 18:39:50 +0100 (CET)
Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com
 [209.85.219.72]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-627-lT-piUw6Oym9JcGnVqj80A-1; Wed, 20 Mar 2024 13:39:45 -0400
Received: by mail-qv1-f72.google.com with SMTP id
 6a1803df08f44-690c19ee50bso188526d6.0
 for ; Wed, 20 Mar 2024 10:39:45 -0700 (PDT)
Received: from x1n ([99.254.121.117]) by smtp.gmail.com with ESMTPSA id
 jn10-20020ad45dea000000b00690dd47a41csm8107560qvb.86.2024.03.20.10.39.43
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 20 Mar 2024 10:39:43 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d9a04aab-e6e0-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1710956389;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=LadTrEs32q6JuiUng9QgE0IesXnTjqGpv9qfMYEDVbA=;
	b=a5zRqAUfCmKNEazpk4etbOhASu7XmFuKj1DkCSaE+/+wiYCXIFkxN2g7+xA/a9aXTQOA2B
	2YkYPdl/UrDHRkiqm3/K4nZn2JvKza0b+jSnE2LIFzYKBQHj3Nbudsuj1Y0ATdSwyteqpP
	z5JEF23rVsdxkpv7prsbFKDVX2t1nVg=
X-MC-Unique: lT-piUw6Oym9JcGnVqj80A-1
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710956385; x=1711561185;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=LadTrEs32q6JuiUng9QgE0IesXnTjqGpv9qfMYEDVbA=;
        b=BhTIr3Bm7xpeZ416C8q/Cs+6vIjwwwpDZH9BU/0yIl03CSONBovmq2UH4JZnl6CkLi
         MY+JEFsgkqLzjOjkghMnFB/GZ/izJcyvLdt9D0baNaTBME8Og1r5B8xNg2uB8Y/ontT5
         tzPJwH61p46BYhLf9eorncYhWv5DN/7wiY7XhsPQb3saGtv//bdmfPyh5WtQKygpGZX3
         ufXOZxYC3MhgyQ8PrEozTqDtVOIw9rLVuaWxMIJFXmumuk4p2Z8E7nyYj4ZxoxTC4GMe
         kDH1z/wHGSgKMCY3b1KbaYMLgb8mukJMDWFrSYXS+bqWpRDr804Ahs1cYvsQNu9JTm2o
         nVfw==
X-Forwarded-Encrypted: i=1; AJvYcCWuw6MAmFb56hazRDDgDhjLZG5SgBAXl84pMWPmux8ZpaYXILvHEzqQh0PInfJ6/Blwk5v+M6Ff+nLOcgskO9tmW77244DTGDz3jgciq24=
X-Gm-Message-State: AOJu0YzEBRwSPhbyX1DPSFXGoxN9xU6q6ufaWm7BTEfMPbK+NWkUeNCL
	Yt/+IKexkLWxNxYVmvCrBNU9op3V9y8p7aqRAeYLExUUuTnndz1noUZEpGPnoFd1dltIqhwZXEB
	o/wrIVQcY+EdSKfCawLpWWK7uV/d6ZrFYGNPNM0WpU8g4V6J7Z0MsrSH/RyppDpjW
X-Received: by 2002:a05:6214:3f85:b0:690:9db6:f410 with SMTP id ow5-20020a0562143f8500b006909db6f410mr6764867qvb.3.1710956384655;
        Wed, 20 Mar 2024 10:39:44 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IFLZ2jRy2HZB5vFRERmbsQfn7UkuWfj7vRUfuSEG/rE4h7BJgEFptrr/T99J5Y/I3ZjhMxHSg==
X-Received: by 2002:a05:6214:3f85:b0:690:9db6:f410 with SMTP id ow5-20020a0562143f8500b006909db6f410mr6764835qvb.3.1710956384209;
        Wed, 20 Mar 2024 10:39:44 -0700 (PDT)
Date: Wed, 20 Mar 2024 13:39:41 -0400
From: Peter Xu 
To: =?utf-8?Q?C=C3=A9dric?= Le Goater 
Cc: qemu-devel@nongnu.org, Stefano Stabellini ,
	Anthony Perard ,
	Paul Durrant , Paolo Bonzini ,
	Richard Henderson ,
	Eduardo Habkost ,
	"Michael S. Tsirkin" ,
	Marcel Apfelbaum ,
	Alex Williamson ,
	David Hildenbrand ,
	Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= ,
	Fabiano Rosas , Avihai Horon ,
	Markus Armbruster ,
	Prasad Pandit ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH for-9.1 v5 09/14] memory: Add Error** argument to
 .log_global_start() handler
Message-ID: 
References: <20240320064911.545001-1-clg@redhat.com>
 <20240320064911.545001-10-clg@redhat.com>
 
 
MIME-Version: 1.0
In-Reply-To: 
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

On Wed, Mar 20, 2024 at 05:15:06PM +0100, Cédric Le Goater wrote:
> Sure, or I will in a v6. Markus had a comment on 8/14.

Yeah, I can handle both if they're the only ones.  Thanks,

-- 
Peter Xu



From xen-devel-bounces@lists.xenproject.org Wed Mar 20 17:40:39 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 17:40:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696075.1086676 (Exim 4.92)
	(envelope-from )
	id 1rmzvb-00009w-7M; Wed, 20 Mar 2024 17:40:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696075.1086676; Wed, 20 Mar 2024 17:40:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmzvb-00009p-4H; Wed, 20 Mar 2024 17:40:39 +0000
Received: by outflank-mailman (input) for mailman id 696075;
 Wed, 20 Mar 2024 17:40:37 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1rmzvZ-000087-Ni
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 17:40:37 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rmzvT-0003z7-Fn; Wed, 20 Mar 2024 17:40:31 +0000
Received: from 54-240-197-236.amazon.com ([54.240.197.236]
 helo=[192.168.19.64]) by xenbits.xenproject.org with esmtpsa
 (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92)
 (envelope-from )
 id 1rmzvT-0001HT-8M; Wed, 20 Mar 2024 17:40:31 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=ulaIoR54LBoqpK4Z4anTPfx7+lnGyqwCjrbO3ABQAmg=; b=uZUz4BczMcqgUnhfS/5IG0CsHw
	R4RzDPe+/pbb+iW8YtxFQZeVDk9z5VPwh0y6cK91g9ieycDhBgKgW1T1WpXHbNVIt6qo3GU6U0FPL
	Qtk+xRpkIGbVLdjx5jyHO1/RNWibzTMgDLZ5cX3G/745eu8f5hiBd9PaA30Dur9hLxyg=;
Message-ID: <849f3f5a-b960-444a-a10e-1f2df36c22a7@xen.org>
Date: Wed, 20 Mar 2024 17:40:29 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/2] xen/arm: Add imx8q{m,x} platform glue
Content-Language: en-GB
To: John Ernberg ,
 Bertrand Marquis 
Cc: Peng Fan , Stefano Stabellini ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Jonas Blixt ,
 "xen-devel@lists.xenproject.org" 
References: <20240131114952.305805-1-john.ernberg@actia.se>
 <20240131114952.305805-2-john.ernberg@actia.se>
 
 <494d4961-ad8a-4d1d-aaa6-d1bfb9d6a137@actia.se>
 <167f0c7a-e037-446c-82f8-2584e35a7af1@xen.org>
 
 <012b5f83-2f9b-4477-965e-07b8506c0052@xen.org>
 
 <5a0c8f09-4f01-45e9-892c-86342c0d0ec5@xen.org>
 <08ae764c-3490-4dd1-ab70-7a855a98d16d@actia.se>
 <911ec1bb-3733-4f37-839e-673a88e408ff@actia.se>
 
 <848794f3-a337-49d9-84db-a969970f071b@actia.se>
 <48038c7f-d7cd-4100-a41b-8042bcb93208@xen.org>
 <967020E7-3D03-416A-8BFC-6F4E4BD9D7B5@arm.com>
 
From: Julien Grall 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi John,

On 20/03/2024 16:24, John Ernberg wrote:
> Hi Bertrand,
> 
> On 3/13/24 11:07, Bertrand Marquis wrote:
>> Hi,
>>
>>> On 8 Mar 2024, at 15:04, Julien Grall  wrote:
>>>
>>> Hi John,
>>>
>>> Thank you for the reply.
>>>
>>> On 08/03/2024 13:40, John Ernberg wrote:
>>>> On 3/7/24 00:07, Julien Grall wrote:
>>>>>    > Ping on the watchdog discussion bits.
>>>>>
>>>>> Sorry for the late reply.
>>>>>
>>>>> On 06/03/2024 13:13, John Ernberg wrote:
>>>>>> On 2/9/24 14:14, John Ernberg wrote:
>>>>>>>
>>>>>>>>       * IMX_SIP_TIMER_*:  This seems to be related to the watchdog.
>>>>>>>> Shouldn't dom0 rely on the watchdog provided by Xen instead? So those
>>>>>>>> call will be used by Xen.
>>>>>>>
>>>>>>> That is indeed a watchdog SIP, and also for setting the SoC internal RTC
>>>>>>> if it is being used.
>>>>>>>
>>>>>>> I looked around if there was previous discussion and only really
>>>>>>> found [3].
>>>>>>> Is the xen/xen/include/watchdog.h header meant to be for this kind of
>>>>>>> watchdog support or is that more for the VM watchdog? Looking at the x86
>>>>>>> ACPI NMI watchdog it seems like the former, but I have never worked with
>>>>>>> x86 nor ACPI.
>>>>>
>>>>> include/watchdog.h contains helper to configure the watchdog for Xen. We
>>>>> also have per-VM watchdog and this is configured by the hypercall
>>>>> SCHEDOP_watchdog.
>>>>>
>>>>>>>
>>>>>>> Currently forwarding it to Dom0 has not caused any watchdog resets with
>>>>>>> our watchdog timeout settings, our specific Dom0 setup and VM count.
>>>>>
>>>>> IIUC, the SMC API for the watchdog would be similar to the ACPI NMI
>>>>> watchdog. So I think it would make more sense if this is not exposed to
>>>>> dom0 (even if Xen is doing nothing with it).
>>>>>
>>>>> Can you try to hide the SMCs and check if dom0 still behave properly?
>>>>>
>>>>> Cheers,
>>>>>
>>>> This SMC manages a hardware watchdog, if it's not pinged within a
>>>> specific interval the entire board resets.
>>>
>>> Do you know what's the default interval? Is it large enough so Xen + dom0 can boot (at least up to when the watchdog driver is initialized)?
>>>
>>>> If I block the SMCs the watchdog driver in Dom0 will fail to ping the
>>>> watchdog, triggering a board reset because the system looks to have
>>>> become unresponsive. The reason this patch set started is because we
>>>> couldn't ping the watchdog when running with Xen.
>>>> In our specific system the bootloader enables the watchdog as early as
>>>> possible so that we can get watchdog protection for as much of the boot
>>>> as we possibly can.
>>>> So, if we are to block the SMC from Dom0, then Xen needs to take over
>>>> the pinging. It could be implemented similarly to the NMI watchdog,
>>>> except that the system will reset if the ping is missed rather than
>>>> backtrace.
>>>> It would also mean that Xen will get a whole watchdog driver-category
>>>> due to the watchdog being vendor and sometimes even SoC specific when it
>>>> comes to Arm.
>>>> My understanding of the domain watchdog code is that today the domain
>>>> needs to call SCHEDOP_watchdog at least once to start the watchdog
>>>> timer. Since watchdog protection through the whole boot process is
>>>> desirable we'd need some core changes, such as an option to start the
>>>> domain watchdog on init. >
>>>> It's quite a big change to make
>>>
>>> For clarification, above you seem to mention two changes:
>>>
>>> 1) Allow Xen to use the HW watchdog
>>> 2) Allow the domain to use the watchdog early
>>>
>>> I am assuming by big change, you are referring to 2?
>>>
>>> , while I am not against doing it if it
>>>> makes sense, I now wonder if Xen should manage hardware watchdogs.
>>>> Looking at the domain watchdog code it looks like if a domain does not
>>>> get enough execution time, the watchdog will not be pinged enough and
>>>> the guest will be reset. So either watchdog approach requires Dom0 to
>>>> get execution time. Dom0 also needs to service all the PV backends it's
>>>> responsible for. I'm not sure it's valuable to add another layer of
>>>> watchdog for this scenario as the end result (checking that the entire
>>>> system works) is achieved without it as well.
>>>> So, before I try to find the time to make a proposal for moving the
>>>> hardware watchdog bit to Xen, do we really want it?
>>>
>>> Thanks for the details. Given that the watchdog is enabled by the bootloader, I think we want Xen to drive the watchdog for two reasons:
>>> 1) In true dom0less environment, dom0 would not exist
>>> 2) You are relying on Xen + Dom0 to boot (or at least enough to get the watchdog working) within the watchdog interval.
>>
>> Definitely we need to consider the case where there is no Dom0.
>>
>> I think there are in fact 3 different use cases here:
>> - watchdog fully driven in a domain (dom0 or another): would work if it is expected
>>     that Xen + Domain boot time is under the watchdog initial refresh rate. I think this
>>     could make sense on some applications where your system depends on a specific
>>     domain to be properly booted to work. This would require an initial refresh time
>>     configurable in the boot loader probably.
> 
> This is our use-case. ^
> 
> Our dom0 is monitoring and managing the other domains in our system.
> Without dom0 working the system isn't really working as a whole.
> 
> @Julien: Would you be ok with the patch set continuing in the direction
> of the
> original proposal, letting another party (or me at a later time) implement
> the fully driven by Xen option?
I am concerned about this particular point from Bertrand:

"would work if it is expected that Xen + Domain boot time is under the 
watchdog initial refresh rate."

How will a user be able to figure out how to initially configure the 
watchdog? Is this something you can easily configure in the bootloader 
at runtime?


Overall, I am not for this approach at least in the current status. I 
would be more inclined if there are some documentations explaining how 
this is supposed to be configured on NXP, so others can use the code.

Anyway, this is why we have multiple Arm maintainers for this kind of 
situation. If they other agrees with you, then they can ack the patch 
and this can be merged.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 17:42:44 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 17:42:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696080.1086686 (Exim 4.92)
	(envelope-from )
	id 1rmzxb-0001CU-NR; Wed, 20 Mar 2024 17:42:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696080.1086686; Wed, 20 Mar 2024 17:42:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rmzxb-0001CN-KK; Wed, 20 Mar 2024 17:42:43 +0000
Received: by outflank-mailman (input) for mailman id 696080;
 Wed, 20 Mar 2024 17:42:42 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rmzxa-0001CB-K3
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 17:42:42 +0000
Received: from mail-yb1-xb35.google.com (mail-yb1-xb35.google.com
 [2607:f8b0:4864:20::b35])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3f5b8f13-e6e1-11ee-a1ee-f123f15fe8a2;
 Wed, 20 Mar 2024 18:42:40 +0100 (CET)
Received: by mail-yb1-xb35.google.com with SMTP id
 3f1490d57ef6-dc6cbe1ac75so124111276.1
 for ; Wed, 20 Mar 2024 10:42:40 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3f5b8f13-e6e1-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1710956559; x=1711561359; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=4PNmrfeclRSaZ0piCvl3NPFSnMqmFKWwWU1pPxBzzB4=;
        b=nkRbUSfqlhxIGfWA4dFhT8hmEPqREEXhOxzv0gj0g4be49m8+rGuubh7ksgdeq+0XA
         M1zuipMyx2FDXzKMi+FRxu9KLwX/TkcaBGJNHNbZw9gH9/Ow/q58JhqezvpChyV50EtY
         5Nq1p/N2Ed1XxNBWAu+dMRqCegKoa3k1WF5zmwCLIn8Uv8JP5XWswaGdXZONz4jylK9c
         ya9U3R/KRq6BERxYTCwoaMJe4Y/mSfZQFFBLO1kL1Owu45qK1rKkQb2NXa6mr+y8X2RL
         Yq2ERtdVvn7QMd2UnwRUqbm0V3uO9JYnMNQocxKcrFMr2MSNKjxHATYUA5w22kScbl5N
         cbjg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710956559; x=1711561359;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=4PNmrfeclRSaZ0piCvl3NPFSnMqmFKWwWU1pPxBzzB4=;
        b=BWGharQ8kON+ml+zEQONl4VxS2AVHNpix/0aBmVtpRWxo6nrU0mvfY4KccYGk8HJsq
         p+L0uroe21VDNQsbOV7Xly8m1spqIx21iNdmWwcYXp0c9uTEQMrXXdE9KsYvxZ/v+PSX
         DNMxsVA2FFploTDDBbd3BNPmUsJ0FaWtpdeSc/qU9KmUuR/6TGOn3FVP2UZlgiqnmMst
         KjzTY7QqCeUk82l8jhE7T89DPxP+Gw0PYjH8Y9zWVbAaS04WTR1zsokZElowGxnMeVOM
         2IVNm3AXMcgtRrjWh+D6uBe9gBxgVOMKHU/V9/3RWkS46a+Uu+6DojYH1LyKhwRTsI09
         7Xbw==
X-Forwarded-Encrypted: i=1; AJvYcCXil3q3rHiPW1StUouBxsN6s165pz2IhYFL1x8LHhGPKOuzKLN3zhSmneylWnb0DBYLqD/QARakDdvxb40JIKpe71poosNCBPP0uMsl20I=
X-Gm-Message-State: AOJu0YzdPv+BJLFzPU/ed4g6Hqus3/g753t6lZhVIC3lBeHXnt04476F
	teHitar3am3bRBRfbjY8yuktizc5nRmohqizNXaRgHtbsw0rejuPghO1VRKO59LcPruxpH7jj7i
	mrqIDUbnxWzKDRrIpM/blbuolVSA=
X-Google-Smtp-Source: AGHT+IF1vHg3nWNn8XTf2zs//TlcE4NB9URz9j93fR3rDahcsKwH8Qh2oWbvidfw1UwEtC6WUuLogrROJAMX9zdn2KI=
X-Received: by 2002:a25:c747:0:b0:dd1:6cad:8fd3 with SMTP id
 w68-20020a25c747000000b00dd16cad8fd3mr284023ybe.27.1710956559522; Wed, 20 Mar
 2024 10:42:39 -0700 (PDT)
MIME-Version: 1.0
References: <20231011193444.81254-1-jandryuk@gmail.com> 
In-Reply-To: 
From: Jason Andryuk 
Date: Wed, 20 Mar 2024 13:42:27 -0400
Message-ID: 
Subject: Re: [PATCH v3] Input: xen-kbdfront - drop keys to shrink modalias
To: linux-kernel@vger.kernel.org, Dmitry Torokhov 
Cc: Phillip Susi , stable@vger.kernel.org, 
	Mattijs Korpershoek , linux-input@vger.kernel.org, 
	xen-devel , Juergen Gross 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Dmitry,

Do you have any feedback, or can you pick up this patch?  It solves a
real issue affecting udev, which crashes the Debian installer and
breaks the mouse for Gnome.

Or would you be okay if this patch went in via the Xen tree?

Thanks,
Jason

On Wed, Nov 1, 2023 at 10:11=E2=80=AFAM Jason Andryuk  =
wrote:
>
> Hi Dmitry,
>
> Do you have any feedback or can you pick this up?
>
> Thanks,
> Jason
>
> On Wed, Oct 11, 2023 at 3:34=E2=80=AFPM Jason Andryuk  wrote:
> >
> > xen kbdfront registers itself as being able to deliver *any* key since
> > it doesn't know what keys the backend may produce.
> >
> > Unfortunately, the generated modalias gets too large and uevent creatio=
n
> > fails with -ENOMEM.
> >
> > This can lead to gdm not using the keyboard since there is no seat
> > associated [1] and the debian installer crashing [2].
> >
> > Trim the ranges of key capabilities by removing some BTN_* ranges.
> > While doing this, some neighboring undefined ranges are removed to trim
> > it further.
> >
> > An upper limit of KEY_KBD_LCD_MENU5 is still too large.  Use an upper
> > limit of KEY_BRIGHTNESS_MENU.
> >
> > This removes:
> > BTN_DPAD_UP(0x220)..BTN_DPAD_RIGHT(0x223)
> > Empty space 0x224..0x229
> >
> > Empty space 0x28a..0x28f
> > KEY_MACRO1(0x290)..KEY_MACRO30(0x2ad)
> > KEY_MACRO_RECORD_START          0x2b0
> > KEY_MACRO_RECORD_STOP           0x2b1
> > KEY_MACRO_PRESET_CYCLE          0x2b2
> > KEY_MACRO_PRESET1(0x2b3)..KEY_MACRO_PRESET3(0xb5)
> > Empty space 0x2b6..0x2b7
> > KEY_KBD_LCD_MENU1(0x2b8)..KEY_KBD_LCD_MENU5(0x2bc)
> > Empty space 0x2bd..0x2bf
> > BTN_TRIGGER_HAPPY(0x2c0)..BTN_TRIGGER_HAPPY40(0x2e7)
> > Empty space 0x2e8..0x2ff
> >
> > The modalias shrinks from 2082 to 1550 bytes.
> >
> > A chunk of keys need to be removed to allow the keyboard to be used.
> > This may break some functionality, but the hope is these macro keys are
> > uncommon and don't affect any users.
> >
> > [1] https://github.com/systemd/systemd/issues/22944
> > [2] https://lore.kernel.org/xen-devel/87o8dw52jc.fsf@vps.thesusis.net/T=
/
> >
> > Cc: Phillip Susi 
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Jason Andryuk 
> > Reviewed-by: Mattijs Korpershoek 
> > ---
> > v3:
> > Add Mattijs R-b
> > Put /* and */ on separate lines
> > ---
> >  drivers/input/misc/xen-kbdfront.c | 11 ++++++++++-
> >  1 file changed, 10 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/input/misc/xen-kbdfront.c b/drivers/input/misc/xen=
-kbdfront.c
> > index 67f1c7364c95..d59ba8f9852e 100644
> > --- a/drivers/input/misc/xen-kbdfront.c
> > +++ b/drivers/input/misc/xen-kbdfront.c
> > @@ -256,7 +256,16 @@ static int xenkbd_probe(struct xenbus_device *dev,
> >                 __set_bit(EV_KEY, kbd->evbit);
> >                 for (i =3D KEY_ESC; i < KEY_UNKNOWN; i++)
> >                         __set_bit(i, kbd->keybit);
> > -               for (i =3D KEY_OK; i < KEY_MAX; i++)
> > +               /*
> > +                * In theory we want to go KEY_OK..KEY_MAX, but that gr=
ows the
> > +                * modalias line too long.  There is a gap of buttons f=
rom
> > +                * BTN_DPAD_UP..BTN_DPAD_RIGHT and KEY_ALS_TOGGLE is th=
e next
> > +                * defined. Then continue up to KEY_BRIGHTNESS_MENU as =
an upper
> > +                * limit.
> > +                */
> > +               for (i =3D KEY_OK; i < BTN_DPAD_UP; i++)
> > +                       __set_bit(i, kbd->keybit);
> > +               for (i =3D KEY_ALS_TOGGLE; i <=3D KEY_BRIGHTNESS_MENU; =
i++)
> >                         __set_bit(i, kbd->keybit);
> >
> >                 ret =3D input_register_device(kbd);
> > --
> > 2.41.0
> >


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 18:00:45 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 18:00:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696084.1086696 (Exim 4.92)
	(envelope-from )
	id 1rn0Ew-0004uz-6L; Wed, 20 Mar 2024 18:00:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696084.1086696; Wed, 20 Mar 2024 18:00:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rn0Ew-0004us-2W; Wed, 20 Mar 2024 18:00:38 +0000
Received: by outflank-mailman (input) for mailman id 696084;
 Wed, 20 Mar 2024 18:00:37 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rn0Ev-0004um-DL
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 18:00:37 +0000
Received: from raptorengineering.com (mail.raptorengineering.com
 [23.155.224.40]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id bee769d1-e6e3-11ee-a1ee-f123f15fe8a2;
 Wed, 20 Mar 2024 19:00:34 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
 by mail.rptsys.com (Postfix) with ESMTP id 9221D82854B3;
 Wed, 20 Mar 2024 13:00:32 -0500 (CDT)
Received: from mail.rptsys.com ([127.0.0.1])
 by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10032)
 with ESMTP id 4wCm0tXK1P70; Wed, 20 Mar 2024 13:00:31 -0500 (CDT)
Received: from localhost (localhost [127.0.0.1])
 by mail.rptsys.com (Postfix) with ESMTP id D634F82856C4;
 Wed, 20 Mar 2024 13:00:31 -0500 (CDT)
Received: from mail.rptsys.com ([127.0.0.1])
 by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10026)
 with ESMTP id DHjujYy71IOm; Wed, 20 Mar 2024 13:00:31 -0500 (CDT)
Received: from raptor-ewks-026.lan (5.edge.rptsys.com [23.155.224.38])
 by mail.rptsys.com (Postfix) with ESMTPSA id 7ECD582854B3;
 Wed, 20 Mar 2024 13:00:31 -0500 (CDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: bee769d1-e6e3-11ee-a1ee-f123f15fe8a2
DKIM-Filter: OpenDKIM Filter v2.10.3 mail.rptsys.com D634F82856C4
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=raptorengineering.com; s=B8E824E6-0BE2-11E6-931D-288C65937AAD;
	t=1710957631; bh=94W0o+FADbFYEfpLUI+OVM+ilIyFdZSfdMiHNwBLaZY=;
	h=From:To:Date:Message-Id:MIME-Version;
	b=nF4TxXy1/+qW8VvQoesw9HogKLglhs5jlxE8jI/DlPllrWKwZw3mGJyjAY6hoGZ0c
	 LN9snEOrlTJBrYyFo2rW9JQHD8c8NYeRlgXhxWZc8I6TFnKGAGjxVHsimm+ChP8Uu+
	 HpxGbnuO5ONwFiqMdA47SOFDKb8X+qbmlw1vdycQ=
X-Virus-Scanned: amavisd-new at rptsys.com
From: Shawn Anastasio 
To: xen-devel@lists.xenproject.org
Cc: tpearson@raptorengineering.com,
	Jan Beulich ,
	Shawn Anastasio 
Subject: [PATCH] xen/ppc: Ensure ELF sections' physical load addresses start at 0x0
Date: Wed, 20 Mar 2024 13:00:21 -0500
Message-Id: <20240320180021.70373-1-sanastasio@raptorengineering.com>
X-Mailer: git-send-email 2.30.2
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

Some boot mechanisms, including the new linux file_load kexec systemcall
used by system firmware v2.10 on RaptorCS systems will try to honor the
physical address field of the ELF LOAD section header, which will fail
when the address is based off of XEN_VIRT_START (0xc000000000000000).

To ensure that the physical address of the LOAD section header starts at
0x0, import the DECL_SECTION macro from x86's xen.lds.S.

Signed-off-by: Shawn Anastasio 
---
 xen/arch/ppc/xen.lds.S | 30 ++++++++++++++++++------------
 1 file changed, 18 insertions(+), 12 deletions(-)

diff --git a/xen/arch/ppc/xen.lds.S b/xen/arch/ppc/xen.lds.S
index 05b6db2728..0ed285f0a7 100644
--- a/xen/arch/ppc/xen.lds.S
+++ b/xen/arch/ppc/xen.lds.S
@@ -4,6 +4,12 @@
 OUTPUT_ARCH(powerpc:common64)
 ENTRY(start)
 
+#ifdef CONFIG_LD_IS_GNU
+# define DECL_SECTION(x) x : AT(ADDR(#x) - XEN_VIRT_START)
+#else
+# define DECL_SECTION(x) x : AT(ADDR(x) - XEN_VIRT_START)
+#endif
+
 PHDRS
 {
     text PT_LOAD ;
@@ -17,7 +23,7 @@ SECTIONS
     . = XEN_VIRT_START;
     _start = .;
 
-    .text : {
+    DECL_SECTION(.text) {
         _stext = .;            /* Text section */
         *(.text.header)
 
@@ -40,7 +46,7 @@ SECTIONS
     } :text
 
     . = ALIGN(PAGE_SIZE);
-    .rodata : {
+    DECL_SECTION(.rodata) {
         _srodata = .;          /* Read-only data */
         /* Bug frames table */
         __start_bug_frames = .;
@@ -64,7 +70,7 @@ SECTIONS
 
     #if defined(BUILD_ID)
     . = ALIGN(4);
-    .note.gnu.build-id : {
+    DECL_SECTION(.note.gnu.build-id) {
         __note_gnu_build_id_start = .;
         *(.note.gnu.build-id)
         __note_gnu_build_id_end = .;
@@ -73,19 +79,19 @@ SECTIONS
     _erodata = .;                /* End of read-only data */
 
     . = ALIGN(PAGE_SIZE);
-    .data.ro_after_init : {
+    DECL_SECTION(.data.ro_after_init) {
         __ro_after_init_start = .;
         *(.data.ro_after_init)
         . = ALIGN(PAGE_SIZE);
         __ro_after_init_end = .;
     } :text
 
-    .data.read_mostly : {
+    DECL_SECTION(.data.read_mostly) {
         *(.data.read_mostly)
     } :text
 
     . = ALIGN(PAGE_SIZE);
-    .data : {                    /* Data */
+    DECL_SECTION(.data) {                    /* Data */
         *(.data.page_aligned)
         . = ALIGN(8);
         __start_schedulers_array = .;
@@ -100,7 +106,7 @@ SECTIONS
 
     . = ALIGN(PAGE_SIZE);             /* Init code and data */
     __init_begin = .;
-    .init.text : {
+    DECL_SECTION(.init.text) {
         _sinittext = .;
         *(.init.text)
         _einittext = .;
@@ -108,7 +114,7 @@ SECTIONS
     } :text
 
     . = ALIGN(PAGE_SIZE);
-    .init.data : {
+    DECL_SECTION(init.data) {
         *(.init.rodata)
         *(.init.rodata.*)
 
@@ -137,18 +143,18 @@ SECTIONS
         __ctors_end = .;
     } :text
 
-    .got : {
+    DECL_SECTION(.got) {
         *(.got .toc)
     } :text
 
-    .got.plt : {
+    DECL_SECTION(.got.plt) {
         *(.got.plt)
     } :text
 
     . = ALIGN(POINTER_ALIGN);
     __init_end = .;
 
-    .bss : {                     /* BSS */
+    DECL_SECTION(.bss) {                     /* BSS */
         __bss_start = .;
         *(.bss.stack_aligned)
         *(.bss.page_aligned)
@@ -168,7 +174,7 @@ SECTIONS
     _end = . ;
 
     /* Section for the device tree blob (if any). */
-    .dtb : { *(.dtb) } :text
+    DECL_SECTION(.dtb) { *(.dtb) } :text
 
     DWARF2_DEBUG_SECTIONS
 
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Wed Mar 20 18:03:26 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 18:03:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696088.1086706 (Exim 4.92)
	(envelope-from )
	id 1rn0Hc-0005jy-HL; Wed, 20 Mar 2024 18:03:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696088.1086706; Wed, 20 Mar 2024 18:03:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rn0Hc-0005jr-Ej; Wed, 20 Mar 2024 18:03:24 +0000
Received: by outflank-mailman (input) for mailman id 696088;
 Wed, 20 Mar 2024 18:03:23 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rn0Hb-0005jl-4o
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 18:03:23 +0000
Received: from raptorengineering.com (mail.raptorengineering.com
 [23.155.224.40]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 22c0c8b6-e6e4-11ee-afdd-a90da7624cb6;
 Wed, 20 Mar 2024 19:03:21 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
 by mail.rptsys.com (Postfix) with ESMTP id 1790782854B3;
 Wed, 20 Mar 2024 13:03:20 -0500 (CDT)
Received: from mail.rptsys.com ([127.0.0.1])
 by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10032)
 with ESMTP id iGIJomhWCXi6; Wed, 20 Mar 2024 13:03:19 -0500 (CDT)
Received: from localhost (localhost [127.0.0.1])
 by mail.rptsys.com (Postfix) with ESMTP id 330FD82856C4;
 Wed, 20 Mar 2024 13:03:19 -0500 (CDT)
Received: from mail.rptsys.com ([127.0.0.1])
 by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10026)
 with ESMTP id bzzdeW9PvU1Q; Wed, 20 Mar 2024 13:03:19 -0500 (CDT)
Received: from [10.11.0.3] (5.edge.rptsys.com [23.155.224.38])
 by mail.rptsys.com (Postfix) with ESMTPSA id D6DBB82854B3;
 Wed, 20 Mar 2024 13:03:18 -0500 (CDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 22c0c8b6-e6e4-11ee-afdd-a90da7624cb6
DKIM-Filter: OpenDKIM Filter v2.10.3 mail.rptsys.com 330FD82856C4
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=raptorengineering.com; s=B8E824E6-0BE2-11E6-931D-288C65937AAD;
	t=1710957799; bh=KcSvGIaamdfvQf1F2LYHVibTUa2X0uPCe4IZx+pdkU4=;
	h=Message-ID:Date:MIME-Version:To:From;
	b=gYxiZkLizET5lbPcoqycHaSatrqS8hALYnmjSz1l/MwUEFWY6hKaI3xfsQUaOTU0T
	 5MVq7TYK1tKDiNQ5E8Z/nRX8UcnVEgKcX+NgTUSlECJK14jCAFrlwZqzqVoHCgD7Vx
	 ozwrfNE2cuWnr2CjAQ0z4mnXLPYnepc3XdIkOTsI=
X-Virus-Scanned: amavisd-new at rptsys.com
Message-ID: <2e51fe7e-1434-445a-8920-884152df4d37@raptorengineering.com>
Date: Wed, 20 Mar 2024 13:03:18 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 9/9] xen/ppc: mm-radix: Allocate all paging structures
 at runtime
Content-Language: en-US
To: xen-devel@lists.xenproject.org
Cc: tpearson@raptorengineering.com, Jan Beulich 
References: 
 <00f22a6a08451614179219fd430539fbb1e6e8cf.1710443965.git.sanastasio@raptorengineering.com>
From: Shawn Anastasio 
In-Reply-To: <00f22a6a08451614179219fd430539fbb1e6e8cf.1710443965.git.sanastasio@raptorengineering.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 3/14/24 5:15 PM, Shawn Anastasio wrote:
> In the initial mm-radix implementation, the in-memory partition and
> process tables required to configure the MMU, as well as the page tables
> themselves were all allocated statically since the boot allocator was
> not yet available.
> 
> Now that it is, allocate these structures at runtime and bump the size
> of the Process Table to its maximum supported value (on POWER9).

After some additional testing, I realized that it is necessary to clear
the memory allocated for these structures before using it, so a small
follow-up is necessary. I will include this with v4 if it is necessary.

diff --git a/xen/arch/ppc/mm-radix.c b/xen/arch/ppc/mm-radix.c
index edae41e0be..f425185259 100644
--- a/xen/arch/ppc/mm-radix.c
+++ b/xen/arch/ppc/mm-radix.c
@@ -37,6 +37,8 @@ static mfn_t __initdata max_alloc_mfn = {0};
  * minimum mfns that have been allocated. This information is used by
  * setup_initial_mapping to include the allocated pages in the initial
  * page mapping.
+ *
+ * Additionally, allocated pages are zeroed before return.
  */
 static mfn_t __init initial_page_alloc(unsigned long nr_pfns,
                                        unsigned long pfn_align)
@@ -49,6 +51,8 @@ static mfn_t __init initial_page_alloc(unsigned long
nr_pfns,
     min_alloc_mfn = _mfn(min(mfn_x(min_alloc_mfn), mfn_x(mfn_first)));
     max_alloc_mfn = _mfn(max(mfn_x(max_alloc_mfn), mfn_x(mfn_last)));

+    memset(__va(mfn_to_maddr(mfn_first)), 0, nr_pfns << PAGE_SHIFT);
+
     return mfn_first;
 }


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 18:08:02 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 18:08:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696090.1086715 (Exim 4.92)
	(envelope-from )
	id 1rn0M2-0006aI-1C; Wed, 20 Mar 2024 18:07:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696090.1086715; Wed, 20 Mar 2024 18:07:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rn0M1-0006aB-Uj; Wed, 20 Mar 2024 18:07:57 +0000
Received: by outflank-mailman (input) for mailman id 696090;
 Wed, 20 Mar 2024 18:07:56 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rn0M0-0006a5-D9
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 18:07:56 +0000
Received: from raptorengineering.com (mail.raptorengineering.com
 [23.155.224.40]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c59d1abd-e6e4-11ee-a1ee-f123f15fe8a2;
 Wed, 20 Mar 2024 19:07:54 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
 by mail.rptsys.com (Postfix) with ESMTP id 4D88D82856C4;
 Wed, 20 Mar 2024 13:07:53 -0500 (CDT)
Received: from mail.rptsys.com ([127.0.0.1])
 by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10032)
 with ESMTP id 2APMJkIbHipL; Wed, 20 Mar 2024 13:07:52 -0500 (CDT)
Received: from localhost (localhost [127.0.0.1])
 by mail.rptsys.com (Postfix) with ESMTP id 95BBC82856C6;
 Wed, 20 Mar 2024 13:07:52 -0500 (CDT)
Received: from mail.rptsys.com ([127.0.0.1])
 by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10026)
 with ESMTP id HyK9Or9_4KlZ; Wed, 20 Mar 2024 13:07:52 -0500 (CDT)
Received: from [10.11.0.3] (5.edge.rptsys.com [23.155.224.38])
 by mail.rptsys.com (Postfix) with ESMTPSA id E7DDD82856C4;
 Wed, 20 Mar 2024 13:07:51 -0500 (CDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c59d1abd-e6e4-11ee-a1ee-f123f15fe8a2
DKIM-Filter: OpenDKIM Filter v2.10.3 mail.rptsys.com 95BBC82856C6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=raptorengineering.com; s=B8E824E6-0BE2-11E6-931D-288C65937AAD;
	t=1710958072; bh=8hb9YAP2Xv2V9yaKIZYyZZmiTCjjcLm/CL7DwGzDizk=;
	h=Message-ID:Date:MIME-Version:To:From;
	b=YQKZyj1B7IHG9+F+GILLX0pmPRS4Oit33XcxF5AX4V5Tb4yYVBPCvvYq9U2FZ9M1h
	 1dLIz2sigiVAjhlErdHE613I7ouoIZkrccrxcFIg4zFYh3NeT3VzbBU49D+QTl3g0v
	 rlT1dANGx+NxuZ8K98NKx0RVt+AqCYOo8GwAu77M=
X-Virus-Scanned: amavisd-new at rptsys.com
Message-ID: <8adb6bf8-9804-4313-b1e1-5cf96d643d5e@raptorengineering.com>
Date: Wed, 20 Mar 2024 13:07:51 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 5/9] xen/device-tree: Move Arm's setup.c bootinfo
 functions to common
Content-Language: en-US
To: Jan Beulich 
Cc: tpearson@raptorengineering.com, Andrew Cooper
 , George Dunlap ,
 Julien Grall , Stefano Stabellini ,
 Wei Liu , Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 "Daniel P. Smith" ,
 xen-devel@lists.xenproject.org
References: 
 <039524d4157dddb2faf6887739a727f6e993b53f.1710443965.git.sanastasio@raptorengineering.com>
 <152e76ee-6e75-4881-aa88-313f0ae058be@suse.com>
From: Shawn Anastasio 
In-Reply-To: <152e76ee-6e75-4881-aa88-313f0ae058be@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 3/15/24 4:16 AM, Jan Beulich wrote:
> On 14.03.2024 23:15, Shawn Anastasio wrote:
>> Arm's setup.c contains a collection of functions for parsing memory map
>> and other boot information from a device tree. Since these routines are
>> generally useful on any architecture that supports device tree booting,
>> move them into xen/common/device-tree.
>>
>> Suggested-by: Julien Grall 
>> Signed-off-by: Shawn Anastasio 
>> ---
>>  MAINTAINERS                       |   1 +
>>  xen/arch/arm/setup.c              | 419 --------------------------
>>  xen/common/Makefile               |   1 +
>>  xen/common/device-tree/Makefile   |   1 +
>>  xen/common/device-tree/bootinfo.c | 469 ++++++++++++++++++++++++++++++
>>  5 files changed, 472 insertions(+), 419 deletions(-)
>>  create mode 100644 xen/common/device-tree/Makefile
>>  create mode 100644 xen/common/device-tree/bootinfo.c
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 56a6932037..e85fbe6737 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -301,6 +301,7 @@ M:	Stefano Stabellini 
>>  M:	Julien Grall 
>>  S:	Supported
>>  F:	xen/common/libfdt/
>> +F:	xen/common/device-tree/setup.c
> 
> Perhaps more generally
> 
> F:	xen/common/device-tree/
> 
> ?
>

This was done to allow bootfdt.c (next patch) to remain under ARM's
maintainership, which I believe was your suggestion in v2.

Perhaps it would make sense to leave both setup.c and bootfdt.c under
ARM's maintainership, or would it be acceptable to move both to device
tree?

> Jan

Thanks,
Shawn


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 18:24:54 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 18:24:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696094.1086726 (Exim 4.92)
	(envelope-from )
	id 1rn0cC-0002KC-Eb; Wed, 20 Mar 2024 18:24:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696094.1086726; Wed, 20 Mar 2024 18:24:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rn0cC-0002K5-BY; Wed, 20 Mar 2024 18:24:40 +0000
Received: by outflank-mailman (input) for mailman id 696094;
 Wed, 20 Mar 2024 18:24:39 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rn0cB-0002Jz-4E
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 18:24:39 +0000
Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com
 [2607:f8b0:4864:20::234])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1b0078fa-e6e7-11ee-a1ee-f123f15fe8a2;
 Wed, 20 Mar 2024 19:24:37 +0100 (CET)
Received: by mail-oi1-x234.google.com with SMTP id
 5614622812f47-3c398187b4dso156414b6e.0
 for ; Wed, 20 Mar 2024 11:24:37 -0700 (PDT)
Received: from [10.80.67.139] (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 ge16-20020a05622a5c9000b00430b79aaa1esm5963929qtb.94.2024.03.20.11.24.34
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 20 Mar 2024 11:24:34 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1b0078fa-e6e7-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1710959075; x=1711563875; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=TuZek9bnFjLuMH9tITh2oa+4tTdqpkIFYiXhJCJJmoI=;
        b=N5YxeFJkkMWSXgkOEEcvMCMFFB7vjWaa4aRfeITA5OX4jtIKySNF2tvh4mpzRUu0VO
         eqirPhoJ+Yr+du8Px5+aRHRkQPQGZXd87zBUnMC27r53nlLfU1z+9f4QUmUy1UyOe+6x
         f5HzdbOvcYkuhge3jQwHHWugBKPFce6VR7iVQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710959075; x=1711563875;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=TuZek9bnFjLuMH9tITh2oa+4tTdqpkIFYiXhJCJJmoI=;
        b=KPS8IUE6eAVA+OEsTDHb8Acv5ePsY9IcTVNe5ChDKTgqyCB3LmHnb2jpQkLJLB7zQ/
         HiNG0Qy+gTuxUcJwPYR0Yc+jsg7wSFqqXhaZm8HAD4zmUCLsVH5UuFPnVcsbkvykY7Ee
         jEZ7/lUPZRX++F/7ejH9Zq3KDcvAmFuaoFqsjvamSyIsS4agk5z+kd9SjG3Yx3C6KaZN
         5vaWSky+ueCSXohhwIggQaG+M7ALXYjlrRI5cX7u69ne9J6w8PKDToGB8lZ3MTF1Ym6R
         BhMNDI70v5zd8sQeL02GzJXJ9uz04VgXXWp57VLU7O/hfkcFFfvaR7QNujHJ9CLnX5CY
         dfpQ==
X-Forwarded-Encrypted: i=1; AJvYcCVXYdQk4qXyBeGIQPjHA2l4icZ8h5eLXPCx4KG19/ZMrCPvEAarhlF07ba/rMwasnqnftwFbAh5P3rL/g7K1QwMh7ZesU6u61gfjlEPmiA=
X-Gm-Message-State: AOJu0YwIl8N1+/SlwejvU0GO6MWg527EydF9ReVZRsmrI9wfBR8SEmwy
	u/PY+9MRQ+PNEctE74t9uu5zcayKdmAMgpzVQ/NYu8MRDL1QXWJCk7WqUkPVQ3Tyii8csjTre/p
	Q
X-Google-Smtp-Source: AGHT+IEOpB56/mKx2IyLKd38j6ThBujl9ke9z3ITgUhHQNQXEWtUpZWb6NMbNrISDmt4pO/wsODrJA==
X-Received: by 2002:a05:6808:1185:b0:3c3:9933:9afa with SMTP id j5-20020a056808118500b003c399339afamr5851687oil.24.1710959075555;
        Wed, 20 Mar 2024 11:24:35 -0700 (PDT)
Message-ID: <0dc5010b-a960-42af-b02f-c10da54f05ea@citrix.com>
Date: Wed, 20 Mar 2024 18:24:33 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/ppc: Ensure ELF sections' physical load addresses
 start at 0x0
Content-Language: en-GB
To: Shawn Anastasio ,
 xen-devel@lists.xenproject.org
Cc: tpearson@raptorengineering.com, Jan Beulich 
References: <20240320180021.70373-1-sanastasio@raptorengineering.com>
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <20240320180021.70373-1-sanastasio@raptorengineering.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 20/03/2024 6:00 pm, Shawn Anastasio wrote:
> Some boot mechanisms, including the new linux file_load kexec systemcall
> used by system firmware v2.10 on RaptorCS systems will try to honor the
> physical address field of the ELF LOAD section header, which will fail
> when the address is based off of XEN_VIRT_START (0xc000000000000000).
>
> To ensure that the physical address of the LOAD section header starts at
> 0x0, import the DECL_SECTION macro from x86's xen.lds.S.
>
> Signed-off-by: Shawn Anastasio 
> ---
>  xen/arch/ppc/xen.lds.S | 30 ++++++++++++++++++------------
>  1 file changed, 18 insertions(+), 12 deletions(-)
>
> diff --git a/xen/arch/ppc/xen.lds.S b/xen/arch/ppc/xen.lds.S
> index 05b6db2728..0ed285f0a7 100644
> --- a/xen/arch/ppc/xen.lds.S
> +++ b/xen/arch/ppc/xen.lds.S
> @@ -4,6 +4,12 @@
>  OUTPUT_ARCH(powerpc:common64)
>  ENTRY(start)
>  
> +#ifdef CONFIG_LD_IS_GNU
> +# define DECL_SECTION(x) x : AT(ADDR(#x) - XEN_VIRT_START)
> +#else
> +# define DECL_SECTION(x) x : AT(ADDR(x) - XEN_VIRT_START)
> +#endif

Could you put this in xen.lds.h please, and dedup it from x86 ?

With that done, Acked-by: Andrew Cooper 


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 18:55:20 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 18:55:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696121.1086755 (Exim 4.92)
	(envelope-from )
	id 1rn15m-00011M-8U; Wed, 20 Mar 2024 18:55:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696121.1086755; Wed, 20 Mar 2024 18:55:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rn15m-00011F-4o; Wed, 20 Mar 2024 18:55:14 +0000
Received: by outflank-mailman (input) for mailman id 696121;
 Wed, 20 Mar 2024 18:55:12 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rn15k-000119-Hg
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 18:55:12 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on20601.outbound.protection.outlook.com
 [2a01:111:f403:2414::601])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 60a23329-e6eb-11ee-afdd-a90da7624cb6;
 Wed, 20 Mar 2024 19:55:11 +0100 (CET)
Received: from PH7PR10CA0015.namprd10.prod.outlook.com (2603:10b6:510:23d::17)
 by DM4PR12MB9072.namprd12.prod.outlook.com (2603:10b6:8:be::6) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.7386.28; Wed, 20 Mar 2024 18:55:06 +0000
Received: from SA2PEPF000015C9.namprd03.prod.outlook.com
 (2603:10b6:510:23d:cafe::a7) by PH7PR10CA0015.outlook.office365.com
 (2603:10b6:510:23d::17) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.26 via Frontend
 Transport; Wed, 20 Mar 2024 18:55:06 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SA2PEPF000015C9.mail.protection.outlook.com (10.167.241.199) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Wed, 20 Mar 2024 18:55:05 +0000
Received: from SATLEXMB06.amd.com (10.181.40.147) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Wed, 20 Mar
 2024 13:55:05 -0500
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB06.amd.com
 (10.181.40.147) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Wed, 20 Mar
 2024 13:55:05 -0500
Received: from xcbayankuma40.xilinx.com (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.35 via
 Frontend Transport; Wed, 20 Mar 2024 13:55:04 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 60a23329-e6eb-11ee-afdd-a90da7624cb6
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=SzZlkhresZkNicUpzVSVkIpWh7MH51YfnDvlHskjoZBj24TFdNYT2ebSFVXfY2Jc+hQhYav0FF8zeDLKN1tTzPQnPZAEJ0ql+9lSXWl+mi23FRPozqHqiulqgTulcinSZ+F27iedSqUpi/TbAZjXPhUfVdKGRt8z7lYZg3PprUx0GoJ8R4p6ukI0Y3hLr/zRp3ZLjRS4IOqzLqznpAfV22qRAKVj2l41NaArP1dchXol20m1tmkXQGXp6LanknH6qBmk4JgZIcAJ/fKVsPPr3/MakGu8OAgkHhj9dXgHfNdX5r7FdEP8PMRTySkbuCVQGOMgN/SBUROqnwMRifr7cw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=cwZsh0Edhlli/f5Lbenp8QaPj7oDs9Yd5glvYjqLHFg=;
 b=bon2ZWRPVt+vMU6QzAf+TS6W4Y31XGSnRqRH3obdEhPFKF1QYnAiBlWgNinR+wGjSs5hsH/vxynV0GsclXm/zk80hLmPZBDJYFcZnpvxYruOFZwbaQ9vpxn/HuGRjKKZpQzF1C0RI7CZLRobvVgpo4JdeIPuMktpBNA8kwOvLKnfapf/kEXLXfgzT3S7sfW7OSQQAgUfL3EsWBCZAFc4VICV4UximfNFE2UrmaxlYBzYplLia9/VzKFeEwY1UYvjMrYuqA1UZnaBMPPt/JHpfWEAS6Nw/10QuapxsMhzFnZq3OSYud+9JuqY/PlbGd7dcfL/oQwv86p+mq6aPVXJMw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=cwZsh0Edhlli/f5Lbenp8QaPj7oDs9Yd5glvYjqLHFg=;
 b=n19sB6VFDaOgLGeEUF80Jjzt2y/TUyLWky/GlN+gvJA8oDVfEKuVjifR9ZkOkgthnLOKeiZF2EuNgffG9TYkhSwCHqNCKTci5WL3mjlNqbO8D2S2Pr3c0ph3PiVX/fC81xHwNDkshCYneXoKEcZlJsr7g8j8JTKLepWsr3mBPw4=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Ayan Kumar Halder 
To: 
CC: , , ,
	, ,
	, Ayan Kumar Halder 
Subject: [RFC PATCH v1] xen: arm: Set state to SYS_STATE_smp_boot before smp initialization
Date: Wed, 20 Mar 2024 18:54:55 +0000
Message-ID: <20240320185455.3409182-1-ayan.kumar.halder@amd.com>
X-Mailer: git-send-email 2.25.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SA2PEPF000015C9:EE_|DM4PR12MB9072:EE_
X-MS-Office365-Filtering-Correlation-Id: dc4402c4-7415-4b49-2474-08dc490f41ff
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	P2DKH+tSoLyaHDCG68fyGnQaG9eYxjppBn/196r4SQ0c5Fu58j9KhvdK3MLa9qaPLkNqCPkB7vWb4Cnar5WM04KblaNDVDbTIKBDSLAtl7fXsK3wzwI4/WVZlCRgyotisbwZD/NiUZpiJ+OV5dHBFuYcHLi7jBp09e8hnrSzdRCcyfiIpXbzmALa82k1C+SsEGkvtGLwjTmxdlKxYL+e/bxBdYTxN3kC/q7+nD7Xo8tpvgCRHVXzu9C2Og2ODk6I0//rKzncCg3RD2e3w97Jyz9kLKm5bHNxkE3FSXGX1p2n43IfVgA1rlXBJmCgA/jYP1CPuUYsiz4ezdrmfuSbz2TNi/TFgtZLrPIDQEsuVa5QRmf0IcD6Omx0fWzx7yy3iOH5f0patlJ5jHb/SFAc4jKtpI8IMfgLy6/5xDR8eKBJwjIrk/GmNbSjo2p+YQ6yVU4ETxVrjWHr6JEyTpU36/S5y4Vll52jp9LAHeeFWrtC8zR52ZdfV/QMUnun6THSRe93YNbliaHXStxYU+Cn4jbfLoQZrbxDkNFackxmQXf5ufvgYmnX7nnN1LO2sQ7S1lZ9Ji99RrXfvfNhvURqaRz5ie7ntOj8dqQg8dwHE7wvVp+axW7DMZBEbs31lMMVTeEnnuRWuPIdURbMn1pMqqj/XpVgpaOED3KkGRjz1sutGMkHy9bVIwn7xgHmaGfq+67on9YgzF0NvXYhJSuW9H4HbM/Nj+Aw1IPciWr4hBJTVQ5dbaC6E3BM9WE2mUbR
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(376005)(36860700004)(82310400014)(1800799015);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Mar 2024 18:55:05.9720
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: dc4402c4-7415-4b49-2474-08dc490f41ff
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SA2PEPF000015C9.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB9072

This is similar to what is being done on x86.

Signed-off-by: Ayan Kumar Halder 
---
 xen/arch/arm/setup.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 424744ad5e..3d110685bc 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -787,6 +787,8 @@ void asmlinkage __init start_xen(unsigned long boot_phys_offset,
 
     processor_id();
 
+    system_state = SYS_STATE_smp_boot;
+
     smp_init_cpus();
     nr_cpu_ids = smp_get_max_cpus();
     printk(XENLOG_INFO "SMP: Allowing %u CPUs\n", nr_cpu_ids);
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Wed Mar 20 18:58:10 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 18:58:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696124.1086764 (Exim 4.92)
	(envelope-from )
	id 1rn18b-0001Z4-L1; Wed, 20 Mar 2024 18:58:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696124.1086764; Wed, 20 Mar 2024 18:58:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rn18b-0001Yx-I6; Wed, 20 Mar 2024 18:58:09 +0000
Received: by outflank-mailman (input) for mailman id 696124;
 Wed, 20 Mar 2024 18:58:08 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rn18a-0001Xm-BG
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 18:58:08 +0000
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com
 [2a00:1450:4864:20::630])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c9f43a47-e6eb-11ee-afdd-a90da7624cb6;
 Wed, 20 Mar 2024 19:58:07 +0100 (CET)
Received: by mail-ej1-x630.google.com with SMTP id
 a640c23a62f3a-a450bedffdfso20141666b.3
 for ; Wed, 20 Mar 2024 11:58:07 -0700 (PDT)
Received: from [192.168.206.239] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 sa19-20020a1709076d1300b00a46bec6da9fsm3795696ejc.203.2024.03.20.11.58.05
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 20 Mar 2024 11:58:06 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c9f43a47-e6eb-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1710961087; x=1711565887; darn=lists.xenproject.org;
        h=mime-version:user-agent:content-transfer-encoding:references
         :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject
         :date:message-id:reply-to;
        bh=g7ezO4P6hTdJzD/Hdbfbir3L0UkUOPXiBwJVmB6lDSk=;
        b=j112ijamYT2pm4/qI5gJEyEXxZpzZFE3G9N3eny7VezdMjUrAyRCd96wmen5UxGMOa
         O9RoaHBRX5vb171UpGVwBz73kWRFKjSgFnsjwVZ0YIR+el4JIe3TWXuYwQVF+pEqagWj
         xHO+WZ2Inp/6t/1cchkOZEHjAF7VySS92H0pK630GwJBMs+MlNI0N4Eakts3zMv3VJXQ
         ndkkCodg58yqOV079j9Kh0T/QvQ3kOIaINanVMGw4L5ZTFZDNQHoxm0i+KM436brSS1s
         a79ihT7/jxzthe7CR10SnYyFEE9BInaX/W3KBP24KrpizQgw496SI/y6YcTqa/OSwfrM
         gYCQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710961087; x=1711565887;
        h=mime-version:user-agent:content-transfer-encoding:references
         :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=g7ezO4P6hTdJzD/Hdbfbir3L0UkUOPXiBwJVmB6lDSk=;
        b=Kc/HscnRjOW7pdvcEDiDUOh3P+zXdwxkmk/V7BQd3ule6e89Fygpr6+ovzg2RM+zyL
         GABLqWAK22YV+VCsNIY7kj9G2A4NU/BT1GuoUIElkxksoxCxPqy4knQpl+Ja0nArldNe
         zGYrYjgocD6hP5eOtY9oosxz9fhLPHztZWREnRFnqRJ2neFHMcv5q1r7MV19o6tOYWxi
         ZM6DjvHVTYe+gqku84PK61liptCX+oppkq568wQmjs08kVrjv7PhLf+ry49HJJc+zzov
         +IeyPxt2D8li0RRi2VVaVSeXzkxjIEf2SDm7BLnJ872IIK9SizDCxSChRVqkqEAiEs0m
         dGMA==
X-Forwarded-Encrypted: i=1; AJvYcCUisen5qkDdDEWYYaRbXpdZPPWEar6G0zY4aJmHyUgUZA+6yIiw1n/QScdsUSkPv3EF/wuOc0l5hUh0F1qBVvIbnK4d1KZaDDRAGLUYXAo=
X-Gm-Message-State: AOJu0YxmgqBSjaual5mWfUaE4BLwFz56uZWwb29qT/0N4/pL/BLczlkt
	e7tz5G6wfyn87DcP9asSxTGqjevZG4JsmoksEE1nlyBRPsLMFA2d
X-Google-Smtp-Source: AGHT+IHX/Eg3Bn7BtdCnoOWyhJgpwvP9erMV2+sfvPFgR+wafaU1btI/L2zoGYisDvq/qR7RoePY7g==
X-Received: by 2002:a17:906:3090:b0:a46:1817:6b35 with SMTP id 16-20020a170906309000b00a4618176b35mr10236357ejv.55.1710961086853;
        Wed, 20 Mar 2024 11:58:06 -0700 (PDT)
Message-ID: <04c1424cec1342dcfb849d361f5eb9f3e7f34734.camel@gmail.com>
Subject: Re: [PATCH v6 03/20] xen/riscv: introduce extenstion support check
 by compiler
From: Oleksii 
To: Jan Beulich 
Cc: Andrew Cooper , George Dunlap
 , Julien Grall , Stefano
 Stabellini , Wei Liu , Alistair Francis
 , Bob Eshleman , Connor
 Davis , xen-devel@lists.xenproject.org
Date: Wed, 20 Mar 2024 19:58:05 +0100
In-Reply-To: <6ddc9d8a-20e7-4e4d-ae1a-d2ea01479b38@suse.com>
References: 
	 
	 <6ddc9d8a-20e7-4e4d-ae1a-d2ea01479b38@suse.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.50.2 (3.50.2-1.fc39) 
MIME-Version: 1.0

On Mon, 2024-03-18 at 17:58 +0100, Jan Beulich wrote:
> On 15.03.2024 19:05, Oleksii Kurochko wrote:
> > Currently, RISC-V requires two extensions: _zbb and _zihintpause.
>=20
> Do we really require Zbb already?
After an introduction of Andrew C. patches [1] it is requited for
__builtin_ffs{l}

[1]
https://lore.kernel.org/xen-devel/20240313172716.2325427-1-andrew.cooper3@c=
itrix.com/T/#t
>=20
> > This patch introduces a compiler check to check if these extensions
> > are supported.
> > Additionally, it introduces the riscv/booting.txt file, which
> > contains
> > information about the extensions that should be supported by the
> > platform.
> >=20
> > In the future, a feature will be introduced to check whether an
> > extension
> > is supported at runtime.
> > However, this feature requires functionality for parsing device
> > tree
> > source (DTS), which is not yet available.
>=20
> Can't you query the CPU for its features?
I couldn't find such reg ( or SBI call ) in the spec.

SBI call sbi_probe_extension() exists, but it doesn't check for every
possible extension. As far as I understand it checks only for that one
which are present in SBI spec.

The most closest thing I see how to check that without dts is how it is
done in OpenSBI:
#define csr_read_allowed(csr_num, trap)				\
	({							\
	register ulong tinfo asm("a3") =3D (ulong)trap;		\
	register ulong ttmp asm("a4");				\
	register ulong mtvec =3D sbi_hart_expected_trap_addr();	\
	register ulong ret =3D
0;					\
	((struct sbi_trap_info *)(trap))->cause =3D 0;		\
	asm volatile(						\
		"add %[ttmp], %[tinfo],
zero\n"			\
		"csrrw %[mtvec], " STR(CSR_MTVEC) ", %[mtvec]\n"\
		"csrr %[ret],
%[csr]\n"				\
		"csrw " STR(CSR_MTVEC) ", %[mtvec]"		\
	    : [mtvec] "+&r"(mtvec), [tinfo] "+&r"(tinfo),	\
	      [ttmp] "+&r"(ttmp), [ret] "=3D&r" (ret)		\
	    : [csr] "i" (csr_num)				\
	    : "memory");					\
	ret;							\
	})							\
...
	/* Detect if hart supports stimecmp CSR(Sstc extension) */
	if (hfeatures->priv_version >=3D SBI_HART_PRIV_VER_1_12) {
		csr_read_allowed(CSR_STIMECMP, (unsigned long)&trap);
		if (!trap.cause)
			__sbi_hart_update_extension(hfeatures,
					SBI_HART_EXT_SSTC, true);
	}

~ Oleksii

>=20
> > --- a/xen/arch/riscv/arch.mk
> > +++ b/xen/arch/riscv/arch.mk
> > @@ -3,16 +3,22 @@
> > =C2=A0
> > =C2=A0$(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS))
> > =C2=A0
> > -CFLAGS-$(CONFIG_RISCV_64) +=3D -mabi=3Dlp64
> > +riscv-abi-$(CONFIG_RISCV_32) :=3D -mabi=3Dilp32
> > +riscv-abi-$(CONFIG_RISCV_64) :=3D -mabi=3Dlp64
> > =C2=A0
> > =C2=A0riscv-march-$(CONFIG_RISCV_ISA_RV64G) :=3D rv64g
> > =C2=A0riscv-march-$(CONFIG_RISCV_ISA_C)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 :=3D $(riscv-march-y)c
> > =C2=A0
> > +extensions :=3D $(call as-insn,$(CC) $(riscv-abi-y) -march=3D$(riscv-
> > march-y)_zbb,"",_zbb) \
> > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 $(call as-insn,$(CC) $(riscv-abi-y) -march=3D$(riscv-
> > march-y)_zihintpause,"pause",_zihintpause)
>=20
> Imo you want another helper macro here, where all one needs to pass
> in is
> the extension name (i.e. zbb and zihintpause as per above). That'll
> also
> help with line length, I hope.
>=20
> Jan



From xen-devel-bounces@lists.xenproject.org Wed Mar 20 19:11:33 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 19:11:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696127.1086775 (Exim 4.92)
	(envelope-from )
	id 1rn1LS-0005Hz-Ob; Wed, 20 Mar 2024 19:11:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696127.1086775; Wed, 20 Mar 2024 19:11:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rn1LS-0005Hs-Lm; Wed, 20 Mar 2024 19:11:26 +0000
Received: by outflank-mailman (input) for mailman id 696127;
 Wed, 20 Mar 2024 19:11:26 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rn1LS-0005Hm-0D
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 19:11:26 +0000
Received: from raptorengineering.com (mail.raptorengineering.com
 [23.155.224.40]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a438cc85-e6ed-11ee-a1ee-f123f15fe8a2;
 Wed, 20 Mar 2024 20:11:23 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
 by mail.rptsys.com (Postfix) with ESMTP id A959D8286A6D;
 Wed, 20 Mar 2024 14:11:22 -0500 (CDT)
Received: from mail.rptsys.com ([127.0.0.1])
 by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10032)
 with ESMTP id IJgJPPJVF8gv; Wed, 20 Mar 2024 14:11:21 -0500 (CDT)
Received: from localhost (localhost [127.0.0.1])
 by mail.rptsys.com (Postfix) with ESMTP id B9DA38286C88;
 Wed, 20 Mar 2024 14:11:21 -0500 (CDT)
Received: from mail.rptsys.com ([127.0.0.1])
 by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10026)
 with ESMTP id FZjd3Ij6uOd1; Wed, 20 Mar 2024 14:11:21 -0500 (CDT)
Received: from raptor-ewks-026.lan (5.edge.rptsys.com [23.155.224.38])
 by mail.rptsys.com (Postfix) with ESMTPSA id 54E918286A6D;
 Wed, 20 Mar 2024 14:11:21 -0500 (CDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a438cc85-e6ed-11ee-a1ee-f123f15fe8a2
DKIM-Filter: OpenDKIM Filter v2.10.3 mail.rptsys.com B9DA38286C88
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=raptorengineering.com; s=B8E824E6-0BE2-11E6-931D-288C65937AAD;
	t=1710961881; bh=qjDVerNvsyKF24rTniU+fXX2Dku1Mqf9+Trxaksp5R8=;
	h=From:To:Date:Message-Id:MIME-Version;
	b=ad+nnNfgnkhRdJiXGiSIDDTGEHFWwngbo8toN2vDdnzzFZutrrsETST/PKWuycM+g
	 snAuwvvhYj/eMQwOfBGcKYiuxUi/9mtJxmr446AjggrNu3oPULw15jw7Z0kURqdVx8
	 bjCENSEFHDx1nCTXTd8GLEWX36bCCFda24cKRMAs=
X-Virus-Scanned: amavisd-new at rptsys.com
From: Shawn Anastasio 
To: xen-devel@lists.xenproject.org
Cc: tpearson@raptorengineering.com,
	Jan Beulich ,
	Andrew Cooper ,
	Shawn Anastasio 
Subject: [PATCH v2] xen/ppc: Ensure ELF sections' physical load addresses start at 0x0
Date: Wed, 20 Mar 2024 14:11:05 -0500
Message-Id: <20240320191105.84369-1-sanastasio@raptorengineering.com>
X-Mailer: git-send-email 2.30.2
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

Some boot mechanisms, including the new linux file_load kexec systemcall
used by system firmware v2.10 on RaptorCS systems will try to honor the
physical address field of the ELF LOAD section header, which will fail
when the address is based off of XEN_VIRT_START (0xc000000000000000).

To ensure that the physical address of the LOAD section header starts at
0x0, move x86's DECL_SECTION macro to xen.lds.h and use it to declare
all sections.

Signed-off-by: Shawn Anastasio 
Acked-by: Andrew Cooper 
---
Changes in v2:
  - Move DECL_SECTION to xen.lds.h

 xen/arch/ppc/xen.lds.S    | 27 +++++++++++++++------------
 xen/arch/x86/xen.lds.S    |  6 +-----
 xen/include/xen/xen.lds.h | 10 ++++++++++
 3 files changed, 26 insertions(+), 17 deletions(-)

diff --git a/xen/arch/ppc/xen.lds.S b/xen/arch/ppc/xen.lds.S
index 05b6db2728..3cead1f980 100644
--- a/xen/arch/ppc/xen.lds.S
+++ b/xen/arch/ppc/xen.lds.S
@@ -4,6 +4,9 @@
 OUTPUT_ARCH(powerpc:common64)
 ENTRY(start)

+/* Used by the DECL_SECTION() macro to calculate physical load addresses */
+#define __XEN_VIRT_START XEN_VIRT_START
+
 PHDRS
 {
     text PT_LOAD ;
@@ -17,7 +20,7 @@ SECTIONS
     . = XEN_VIRT_START;
     _start = .;

-    .text : {
+    DECL_SECTION(.text) {
         _stext = .;            /* Text section */
         *(.text.header)

@@ -40,7 +43,7 @@ SECTIONS
     } :text

     . = ALIGN(PAGE_SIZE);
-    .rodata : {
+    DECL_SECTION(.rodata) {
         _srodata = .;          /* Read-only data */
         /* Bug frames table */
         __start_bug_frames = .;
@@ -64,7 +67,7 @@ SECTIONS

     #if defined(BUILD_ID)
     . = ALIGN(4);
-    .note.gnu.build-id : {
+    DECL_SECTION(.note.gnu.build-id) {
         __note_gnu_build_id_start = .;
         *(.note.gnu.build-id)
         __note_gnu_build_id_end = .;
@@ -73,19 +76,19 @@ SECTIONS
     _erodata = .;                /* End of read-only data */

     . = ALIGN(PAGE_SIZE);
-    .data.ro_after_init : {
+    DECL_SECTION(.data.ro_after_init) {
         __ro_after_init_start = .;
         *(.data.ro_after_init)
         . = ALIGN(PAGE_SIZE);
         __ro_after_init_end = .;
     } :text

-    .data.read_mostly : {
+    DECL_SECTION(.data.read_mostly) {
         *(.data.read_mostly)
     } :text

     . = ALIGN(PAGE_SIZE);
-    .data : {                    /* Data */
+    DECL_SECTION(.data) {                    /* Data */
         *(.data.page_aligned)
         . = ALIGN(8);
         __start_schedulers_array = .;
@@ -100,7 +103,7 @@ SECTIONS

     . = ALIGN(PAGE_SIZE);             /* Init code and data */
     __init_begin = .;
-    .init.text : {
+    DECL_SECTION(.init.text) {
         _sinittext = .;
         *(.init.text)
         _einittext = .;
@@ -108,7 +111,7 @@ SECTIONS
     } :text

     . = ALIGN(PAGE_SIZE);
-    .init.data : {
+    DECL_SECTION(init.data) {
         *(.init.rodata)
         *(.init.rodata.*)

@@ -137,18 +140,18 @@ SECTIONS
         __ctors_end = .;
     } :text

-    .got : {
+    DECL_SECTION(.got) {
         *(.got .toc)
     } :text

-    .got.plt : {
+    DECL_SECTION(.got.plt) {
         *(.got.plt)
     } :text

     . = ALIGN(POINTER_ALIGN);
     __init_end = .;

-    .bss : {                     /* BSS */
+    DECL_SECTION(.bss) {                     /* BSS */
         __bss_start = .;
         *(.bss.stack_aligned)
         *(.bss.page_aligned)
@@ -168,7 +171,7 @@ SECTIONS
     _end = . ;

     /* Section for the device tree blob (if any). */
-    .dtb : { *(.dtb) } :text
+    DECL_SECTION(.dtb) { *(.dtb) } :text

     DWARF2_DEBUG_SECTIONS

diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 8930e14fc4..1ef6645128 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -12,6 +12,7 @@

 #define FORMAT "pei-x86-64"
 #undef __XEN_VIRT_START
+#undef DECL_SECTION
 #define __XEN_VIRT_START __image_base__
 #define DECL_SECTION(x) x :

@@ -20,11 +21,6 @@ ENTRY(efi_start)
 #else /* !EFI */

 #define FORMAT "elf64-x86-64"
-#ifdef CONFIG_LD_IS_GNU
-# define DECL_SECTION(x) x : AT(ADDR(#x) - __XEN_VIRT_START)
-#else
-# define DECL_SECTION(x) x : AT(ADDR(x) - __XEN_VIRT_START)
-#endif

 ENTRY(start_pa)

diff --git a/xen/include/xen/xen.lds.h b/xen/include/xen/xen.lds.h
index 06b7110837..be90f5ca0f 100644
--- a/xen/include/xen/xen.lds.h
+++ b/xen/include/xen/xen.lds.h
@@ -5,6 +5,16 @@
  * Common macros to be used in architecture specific linker scripts.
  */

+/*
+ * Declare a section whose load address is based at PA 0 rather than
+ * Xen's virtual base address.
+ */
+#ifdef CONFIG_LD_IS_GNU
+# define DECL_SECTION(x) x : AT(ADDR(#x) - __XEN_VIRT_START)
+#else
+# define DECL_SECTION(x) x : AT(ADDR(x) - __XEN_VIRT_START)
+#endif
+
 /*
  * To avoid any confusion, please note that the EFI macro does not correspond
  * to EFI support and is used when linking a native EFI (i.e. PE/COFF) binary,
--
2.30.2



From xen-devel-bounces@lists.xenproject.org Wed Mar 20 19:44:44 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 19:44:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696138.1086785 (Exim 4.92)
	(envelope-from )
	id 1rn1rR-0002qX-7n; Wed, 20 Mar 2024 19:44:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696138.1086785; Wed, 20 Mar 2024 19:44:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rn1rR-0002qQ-3w; Wed, 20 Mar 2024 19:44:29 +0000
Received: by outflank-mailman (input) for mailman id 696138;
 Wed, 20 Mar 2024 19:44:28 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rn1rP-0002qK-Sl
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 19:44:27 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 41d1eb03-e6f2-11ee-afdd-a90da7624cb6;
 Wed, 20 Mar 2024 20:44:26 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 3F161610A1;
 Wed, 20 Mar 2024 19:44:25 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id C6A8BC433C7;
 Wed, 20 Mar 2024 19:44:22 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 41d1eb03-e6f2-11ee-afdd-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1710963865;
	bh=nchtvu7FyrnG5+8ZjCxOdqbxijBRFgG29pgMUueefj4=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=dq+2KQVqqpBQnXoimBBcfhDTj7RoP+EYdG/aEQxrd8VN3TCYgUMycznOe7BltO6S3
	 N++IciqUkRWvqTrkDQkYOLfX9FWUiAd1VqgNg6d5Eb3ojixm7PWzOaRAD9IbmcWFvq
	 4X0I8mGtuZs8j/bppsRWlm21GBWcFd6ViKjO2CQ/JbrRn0NVTdC+unMY0Bv9W3chHg
	 uyAdBHjBPFL5UIHIiTcavY7TcEvPM2BjUt0+H0p15mLE+61ttnifHo+6kDQHRJe2x5
	 hVma6Lfx2JrO1CbRkVFwagrrkYx7dfehIHKmkPQOFkSAHfJbBS/DfAnAyOWh3PFgrw
	 nSTaZnLV+sHOg==
Date: Wed, 20 Mar 2024 19:44:20 +0000
From: Conor Dooley 
To: Oleksii 
Cc: Jan Beulich ,
	Andrew Cooper ,
	George Dunlap ,
	Julien Grall ,
	Stefano Stabellini , Wei Liu ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v6 03/20] xen/riscv: introduce extenstion support check
 by compiler
Message-ID: <20240320-oak-uprising-db787f501695@spud>
References: 
 
 <6ddc9d8a-20e7-4e4d-ae1a-d2ea01479b38@suse.com>
 <04c1424cec1342dcfb849d361f5eb9f3e7f34734.camel@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="WuXc4XOhTO1ZLXjC"
Content-Disposition: inline
In-Reply-To: <04c1424cec1342dcfb849d361f5eb9f3e7f34734.camel@gmail.com>


--WuXc4XOhTO1ZLXjC
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Mar 20, 2024 at 07:58:05PM +0100, Oleksii wrote:
> On Mon, 2024-03-18 at 17:58 +0100, Jan Beulich wrote:
> > On 15.03.2024 19:05, Oleksii Kurochko wrote:
> > > Currently, RISC-V requires two extensions: _zbb and _zihintpause.
> >=20
> > Do we really require Zbb already?
> After an introduction of Andrew C. patches [1] it is requited for
> __builtin_ffs{l}
>=20
> [1]
> https://lore.kernel.org/xen-devel/20240313172716.2325427-1-andrew.cooper3=
@citrix.com/T/#t
> >=20
> > > This patch introduces a compiler check to check if these extensions
> > > are supported.
> > > Additionally, it introduces the riscv/booting.txt file, which
> > > contains
> > > information about the extensions that should be supported by the
> > > platform.
> > >=20
> > > In the future, a feature will be introduced to check whether an
> > > extension
> > > is supported at runtime.
> > > However, this feature requires functionality for parsing device
> > > tree
> > > source (DTS), which is not yet available.
> >=20
> > Can't you query the CPU for its features?
> I couldn't find such reg ( or SBI call ) in the spec.

There isn't.

> SBI call sbi_probe_extension() exists, but it doesn't check for every
> possible extension. As far as I understand it checks only for that one
> which are present in SBI spec.

Yeah, it only checks for SBI extensions, not ISA extensions.

> The most closest thing I see how to check that without dts is how it is
> done in OpenSBI:

IIRC this only "works" because the OpenSBI devs assume that there are no
non-normative behaviours and all CSRs have their ~God~ RVI defined
meanings. Reading a CSR to see if it traps is not behaviour you can really
rely on unless the platform claims to support Sstrict - but Sstrict you'd
have to detect from the DT so chicken and egg for you! It's one of these
new "extensions" from the profiles spec, so it doesn't even have support
in Linux's dt-bindings yet. Up to Xen devs if you guys want to make the
same assumptions as OpenSBI. Linux doesn't and when we discussed this
not too long ago on the U-Boot ML in the context of the rng CSR it was
also decided not to do make the assumption there either.

Personally I wonder if you can just apply the same policy here as you
did with Zbb in the other thread and assume that something with H will
have Zihintpause and leave implementing a "fake" pause as an exercise
for someone that introduces such a system?
If Jess is correct, and I do remember testing this, it's actually
"always" safe to call the pause instruction on CPUs where the extension
is not supported as it uses an encoding of fence that effectively makes
it a into a nop:
https://lore.kernel.org/linux-riscv/2E96A836-764D-4D07-AB79-3861B9CC2B1F@jr=
tc27.com/
At worst, that'd make cpu_relax() a nop if someone didn't meet that
requirement.

FWIW, Linux's cpu_relax() on RISC-V looks like:
	static inline void cpu_relax(void)
	{
	#ifdef __riscv_muldiv
		int dummy;
		/* In lieu of a halt instruction, induce a long-latency stall. */
		__asm__ __volatile__ ("div %0, %0, zero" : "=3Dr" (dummy));
	#endif
=09
	#ifdef CONFIG_TOOLCHAIN_HAS_ZIHINTPAUSE
		/*
		 * Reduce instruction retirement.
		 * This assumes the PC changes.
		 */
		__asm__ __volatile__ ("pause");
	#else
		/* Encoding of the pause instruction */
		__asm__ __volatile__ (".4byte 0x100000F");
	#endif
		barrier();
	}

I figure having div is part of your base requirements, so maybe you can
just do something similar in the !zihintpause case if making that
extension a requirement is problematic?=20
Doing that invalid div used to be conditional, but cpu_relax() is in the
vdso so the static branch it used to be gated with got removed and its
now unconditional. Probably that's not a constraint on Xen's cpu_relax()?

Oh ye, and we do the .4byte crap so that toolchain support wasn't needed
for Zihintpause given we are using it in exactly one place.

Cheers,
Conor.

> #define csr_read_allowed(csr_num, trap)				\
> 	({							\
> 	register ulong tinfo asm("a3") =3D (ulong)trap;		\
> 	register ulong ttmp asm("a4");				\
> 	register ulong mtvec =3D sbi_hart_expected_trap_addr();	\
> 	register ulong ret =3D
> 0;					\
> 	((struct sbi_trap_info *)(trap))->cause =3D 0;		\
> 	asm volatile(						\
> 		"add %[ttmp], %[tinfo],
> zero\n"			\
> 		"csrrw %[mtvec], " STR(CSR_MTVEC) ", %[mtvec]\n"\
> 		"csrr %[ret],
> %[csr]\n"				\
> 		"csrw " STR(CSR_MTVEC) ", %[mtvec]"		\
> 	    : [mtvec] "+&r"(mtvec), [tinfo] "+&r"(tinfo),	\
> 	      [ttmp] "+&r"(ttmp), [ret] "=3D&r" (ret)		\
> 	    : [csr] "i" (csr_num)				\
> 	    : "memory");					\
> 	ret;							\
> 	})							\
> ...
> 	/* Detect if hart supports stimecmp CSR(Sstc extension) */
> 	if (hfeatures->priv_version >=3D SBI_HART_PRIV_VER_1_12) {
> 		csr_read_allowed(CSR_STIMECMP, (unsigned long)&trap);
> 		if (!trap.cause)
> 			__sbi_hart_update_extension(hfeatures,
> 					SBI_HART_EXT_SSTC, true);
> 	}

--WuXc4XOhTO1ZLXjC
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCZfs8lAAKCRB4tDGHoIJi
0r3/AP4/vBGX2iN5mwOMnv3lpuWA8BP/zws5AN71Fjuw9yy97gEAretmOJDJLMZl
Y91Kogw5xVnQZFa9xmdM5VeRdsseKQ0=
=YKEu
-----END PGP SIGNATURE-----

--WuXc4XOhTO1ZLXjC--


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 22:36:59 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 22:36:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696152.1086806 (Exim 4.92)
	(envelope-from )
	id 1rn4YB-0008HY-6N; Wed, 20 Mar 2024 22:36:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696152.1086806; Wed, 20 Mar 2024 22:36:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rn4YB-0008HR-3g; Wed, 20 Mar 2024 22:36:47 +0000
Received: by outflank-mailman (input) for mailman id 696152;
 Wed, 20 Mar 2024 22:36:46 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rn4YA-0008HH-0L; Wed, 20 Mar 2024 22:36:46 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rn4Y9-00014S-Ub; Wed, 20 Mar 2024 22:36:45 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rn4Y9-0003ZT-LU; Wed, 20 Mar 2024 22:36:45 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rn4Y9-0005dT-LA; Wed, 20 Mar 2024 22:36:45 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=eC8RJc9N2K+796RhorPwBpDLtRZX4PVSsShuITN14d8=; b=Kro/jf8Fs5Fe23CbucUaEbK9cA
	BzU3i4ThWKa08wD6brwgjoQWMCYJ+g6n7RQWm42ke6oF63nZuRWDCAxuI4fN0CtDEqyhQLnaucNea
	Bv5YsqUvpX8csxYHAb6rWbA+XnahPwzcoYOXlHezgtDqIjaMpNLnFbkR5Oix1LQcdZZo=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 185106: tolerable FAIL - PUSHED
X-Osstest-Failures:
    xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-i386-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
X-Osstest-Versions-This:
    xen=188fa82305e72b725473db9146e20cc9abf7bff3
X-Osstest-Versions-That:
    xen=d2276b86e5eb8dd2617d917f7b49cdd1f29ac299
From: osstest service owner 
Date: Wed, 20 Mar 2024 22:36:45 +0000

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen                  188fa82305e72b725473db9146e20cc9abf7bff3
baseline version:
 xen                  d2276b86e5eb8dd2617d917f7b49cdd1f29ac299

Last test of basis   185099  2024-03-19 17:55:12 Z    1 days
Testing same since   185106  2024-03-20 07:05:54 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper 

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-i386-examine-bios                                 pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-i386-livepatch                                    pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-armhf-armhf-libvirt-qcow2                               pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-libvirt-raw                                  pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-i386-examine-uefi                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-arm64-arm64-xl-vhd                                      pass    
 test-armhf-armhf-xl-vhd                                      pass    
 test-amd64-i386-xl-vhd                                       pass    


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

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

Explanation of these 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
   d2276b86e5..188fa82305  188fa82305e72b725473db9146e20cc9abf7bff3 -> master


From xen-devel-bounces@lists.xenproject.org Wed Mar 20 23:53:35 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Mar 2024 23:53:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696159.1086816 (Exim 4.92)
	(envelope-from )
	id 1rn5kH-0001bC-KG; Wed, 20 Mar 2024 23:53:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696159.1086816; Wed, 20 Mar 2024 23:53:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rn5kH-0001b5-Hi; Wed, 20 Mar 2024 23:53:21 +0000
Received: by outflank-mailman (input) for mailman id 696159;
 Wed, 20 Mar 2024 23:53:20 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rn5kF-0001az-V9
 for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 23:53:20 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 05eb7649-e715-11ee-afde-a90da7624cb6;
 Thu, 21 Mar 2024 00:53:18 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id D237960C84;
 Wed, 20 Mar 2024 23:53:16 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 752CBC433C7;
 Wed, 20 Mar 2024 23:53:15 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 05eb7649-e715-11ee-afde-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1710978796;
	bh=gkd7ejGUwM4leY38+kndu78bO61qIqQLQ2AbPuP3s6M=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=gGQ2gKcdFpJdCSX4pA/wF6Na8O/PpEo1ln9+oxy5G77ZrTgs/iQbYAJY4hCU9rOj6
	 0uVKMfm26e9xZV3e0ST3o7oHupeAyVe4Sk90A/TcXVUSmsFvIUDR26Fn/NrQ5VaKdj
	 Ok+akfUjfH8p7ZIcGu0e5zb9Frcq1+j6fsvLi1HMMNRyQ7gQGRsLKiSjJxFu/JVoeh
	 4sji6gfJztkzZdJgKZBKW3VWKBaphvEtAEkjLjctWcov6M+NoIrc+h2ipGSD6PNUl+
	 z7VBIuZjxghdsSedkzC3cGmOM+2tNNhyDret0v6e/AH8/MSOg/QVr1YkkzAOQ1v9oy
	 hM1uu7bqe4OJg==
Date: Wed, 20 Mar 2024 16:53:13 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Julien Grall 
cc: John Ernberg , 
    Bertrand Marquis , Peng Fan , 
    Stefano Stabellini , 
    Michal Orzel , 
    Volodymyr Babchuk , 
    Jonas Blixt , 
    "xen-devel@lists.xenproject.org" 
Subject: Re: [PATCH 1/2] xen/arm: Add imx8q{m,x} platform glue
In-Reply-To: <849f3f5a-b960-444a-a10e-1f2df36c22a7@xen.org>
Message-ID: 
References: <20240131114952.305805-1-john.ernberg@actia.se> <20240131114952.305805-2-john.ernberg@actia.se>  <494d4961-ad8a-4d1d-aaa6-d1bfb9d6a137@actia.se> <167f0c7a-e037-446c-82f8-2584e35a7af1@xen.org>
  <012b5f83-2f9b-4477-965e-07b8506c0052@xen.org>  <5a0c8f09-4f01-45e9-892c-86342c0d0ec5@xen.org> <08ae764c-3490-4dd1-ab70-7a855a98d16d@actia.se>
 <911ec1bb-3733-4f37-839e-673a88e408ff@actia.se>  <848794f3-a337-49d9-84db-a969970f071b@actia.se> <48038c7f-d7cd-4100-a41b-8042bcb93208@xen.org> <967020E7-3D03-416A-8BFC-6F4E4BD9D7B5@arm.com>
  <849f3f5a-b960-444a-a10e-1f2df36c22a7@xen.org>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Wed, 20 Mar 2024, Julien Grall wrote:
> Hi John,
> 
> On 20/03/2024 16:24, John Ernberg wrote:
> > Hi Bertrand,
> > 
> > On 3/13/24 11:07, Bertrand Marquis wrote:
> > > Hi,
> > > 
> > > > On 8 Mar 2024, at 15:04, Julien Grall  wrote:
> > > > 
> > > > Hi John,
> > > > 
> > > > Thank you for the reply.
> > > > 
> > > > On 08/03/2024 13:40, John Ernberg wrote:
> > > > > On 3/7/24 00:07, Julien Grall wrote:
> > > > > >    > Ping on the watchdog discussion bits.
> > > > > > 
> > > > > > Sorry for the late reply.
> > > > > > 
> > > > > > On 06/03/2024 13:13, John Ernberg wrote:
> > > > > > > On 2/9/24 14:14, John Ernberg wrote:
> > > > > > > > 
> > > > > > > > >       * IMX_SIP_TIMER_*:  This seems to be related to the
> > > > > > > > > watchdog.
> > > > > > > > > Shouldn't dom0 rely on the watchdog provided by Xen instead?
> > > > > > > > > So those
> > > > > > > > > call will be used by Xen.
> > > > > > > > 
> > > > > > > > That is indeed a watchdog SIP, and also for setting the SoC
> > > > > > > > internal RTC
> > > > > > > > if it is being used.
> > > > > > > > 
> > > > > > > > I looked around if there was previous discussion and only really
> > > > > > > > found [3].
> > > > > > > > Is the xen/xen/include/watchdog.h header meant to be for this
> > > > > > > > kind of
> > > > > > > > watchdog support or is that more for the VM watchdog? Looking at
> > > > > > > > the x86
> > > > > > > > ACPI NMI watchdog it seems like the former, but I have never
> > > > > > > > worked with
> > > > > > > > x86 nor ACPI.
> > > > > > 
> > > > > > include/watchdog.h contains helper to configure the watchdog for
> > > > > > Xen. We
> > > > > > also have per-VM watchdog and this is configured by the hypercall
> > > > > > SCHEDOP_watchdog.
> > > > > > 
> > > > > > > > 
> > > > > > > > Currently forwarding it to Dom0 has not caused any watchdog
> > > > > > > > resets with
> > > > > > > > our watchdog timeout settings, our specific Dom0 setup and VM
> > > > > > > > count.
> > > > > > 
> > > > > > IIUC, the SMC API for the watchdog would be similar to the ACPI NMI
> > > > > > watchdog. So I think it would make more sense if this is not exposed
> > > > > > to
> > > > > > dom0 (even if Xen is doing nothing with it).
> > > > > > 
> > > > > > Can you try to hide the SMCs and check if dom0 still behave
> > > > > > properly?
> > > > > > 
> > > > > > Cheers,
> > > > > > 
> > > > > This SMC manages a hardware watchdog, if it's not pinged within a
> > > > > specific interval the entire board resets.
> > > > 
> > > > Do you know what's the default interval? Is it large enough so Xen +
> > > > dom0 can boot (at least up to when the watchdog driver is initialized)?
> > > > 
> > > > > If I block the SMCs the watchdog driver in Dom0 will fail to ping the
> > > > > watchdog, triggering a board reset because the system looks to have
> > > > > become unresponsive. The reason this patch set started is because we
> > > > > couldn't ping the watchdog when running with Xen.
> > > > > In our specific system the bootloader enables the watchdog as early as
> > > > > possible so that we can get watchdog protection for as much of the
> > > > > boot
> > > > > as we possibly can.
> > > > > So, if we are to block the SMC from Dom0, then Xen needs to take over
> > > > > the pinging. It could be implemented similarly to the NMI watchdog,
> > > > > except that the system will reset if the ping is missed rather than
> > > > > backtrace.
> > > > > It would also mean that Xen will get a whole watchdog driver-category
> > > > > due to the watchdog being vendor and sometimes even SoC specific when
> > > > > it
> > > > > comes to Arm.
> > > > > My understanding of the domain watchdog code is that today the domain
> > > > > needs to call SCHEDOP_watchdog at least once to start the watchdog
> > > > > timer. Since watchdog protection through the whole boot process is
> > > > > desirable we'd need some core changes, such as an option to start the
> > > > > domain watchdog on init. >
> > > > > It's quite a big change to make
> > > > 
> > > > For clarification, above you seem to mention two changes:
> > > > 
> > > > 1) Allow Xen to use the HW watchdog
> > > > 2) Allow the domain to use the watchdog early
> > > > 
> > > > I am assuming by big change, you are referring to 2?
> > > > 
> > > > , while I am not against doing it if it
> > > > > makes sense, I now wonder if Xen should manage hardware watchdogs.
> > > > > Looking at the domain watchdog code it looks like if a domain does not
> > > > > get enough execution time, the watchdog will not be pinged enough and
> > > > > the guest will be reset. So either watchdog approach requires Dom0 to
> > > > > get execution time. Dom0 also needs to service all the PV backends
> > > > > it's
> > > > > responsible for. I'm not sure it's valuable to add another layer of
> > > > > watchdog for this scenario as the end result (checking that the entire
> > > > > system works) is achieved without it as well.
> > > > > So, before I try to find the time to make a proposal for moving the
> > > > > hardware watchdog bit to Xen, do we really want it?
> > > > 
> > > > Thanks for the details. Given that the watchdog is enabled by the
> > > > bootloader, I think we want Xen to drive the watchdog for two reasons:
> > > > 1) In true dom0less environment, dom0 would not exist
> > > > 2) You are relying on Xen + Dom0 to boot (or at least enough to get the
> > > > watchdog working) within the watchdog interval.
> > > 
> > > Definitely we need to consider the case where there is no Dom0.
> > > 
> > > I think there are in fact 3 different use cases here:
> > > - watchdog fully driven in a domain (dom0 or another): would work if it is
> > > expected
> > >     that Xen + Domain boot time is under the watchdog initial refresh
> > > rate. I think this
> > >     could make sense on some applications where your system depends on a
> > > specific
> > >     domain to be properly booted to work. This would require an initial
> > > refresh time
> > >     configurable in the boot loader probably.
> > 
> > This is our use-case. ^
> > 
> > Our dom0 is monitoring and managing the other domains in our system.
> > Without dom0 working the system isn't really working as a whole.
> > 
> > @Julien: Would you be ok with the patch set continuing in the direction
> > of the
> > original proposal, letting another party (or me at a later time) implement
> > the fully driven by Xen option?
> I am concerned about this particular point from Bertrand:
> 
> "would work if it is expected that Xen + Domain boot time is under the
> watchdog initial refresh rate."
> 
> How will a user be able to figure out how to initially configure the watchdog?
> Is this something you can easily configure in the bootloader at runtime?
> 
> 
> Overall, I am not for this approach at least in the current status. I would be
> more inclined if there are some documentations explaining how this is supposed
> to be configured on NXP, so others can use the code.
>
> Anyway, this is why we have multiple Arm maintainers for this kind of
> situation. If they other agrees with you, then they can ack the patch and this
> can be merged.


The approach here would not be my choice either. However, I think it
would be nice to have better support for NXP imx8 boards in upstream
Xen. To that end, I would ack these patches but I would ask to add a
document under xen.git/docs/ explaining the approach, limitations, and
requirements, so that someone else can use the code effectively.


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 01:09:24 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 01:09:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696164.1086827 (Exim 4.92)
	(envelope-from )
	id 1rn6vh-0001XP-4C; Thu, 21 Mar 2024 01:09:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696164.1086827; Thu, 21 Mar 2024 01:09:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rn6vh-0001XI-1L; Thu, 21 Mar 2024 01:09:13 +0000
Received: by outflank-mailman (input) for mailman id 696164;
 Thu, 21 Mar 2024 01:09:11 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rn6vf-0001XC-Gt
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 01:09:11 +0000
Received: from EUR02-VI1-obe.outbound.protection.outlook.com
 (mail-vi1eur02on20601.outbound.protection.outlook.com
 [2a01:111:f403:2607::601])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9eb84775-e71f-11ee-afde-a90da7624cb6;
 Thu, 21 Mar 2024 02:09:09 +0100 (CET)
Received: from DU0PR04MB9417.eurprd04.prod.outlook.com (2603:10a6:10:358::11)
 by PA4PR04MB7502.eurprd04.prod.outlook.com (2603:10a6:102:ef::21)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.31; Thu, 21 Mar
 2024 01:09:07 +0000
Received: from DU0PR04MB9417.eurprd04.prod.outlook.com
 ([fe80::d30b:44e7:e78e:662d]) by DU0PR04MB9417.eurprd04.prod.outlook.com
 ([fe80::d30b:44e7:e78e:662d%4]) with mapi id 15.20.7386.017; Thu, 21 Mar 2024
 01:09:07 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9eb84775-e71f-11ee-afde-a90da7624cb6
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=MHHkJoOvp57rpEJ4byRyNUQ/GTrJltGglGzg9w0/pIk5klzZDWMTaEAylP3b+mmndIt0trTp4GZF3DPzGba4bMwQ4uLGMcCUcrpPX5WyLL2nusx3W/iUIHVLSpiT0ehnKvRFRze94KpYbjpw3t/xW9Dg9/ZcmHhMX5CGhPw0Ddov8fA1ZviU809fouZa3jw/L481fOcJUPV7rN0oNnu3ndRIVqzUt6ECSTA3BpZnXU7xhymvcEzvTl6JCBTNPkVSTBx4jskqAwnT0xh3tsJrTP6JHICJ1u0OdOS0NhANX6k0NUR+Dk/GPfEspJG9YYqsG3ggcUFqil16A9DjqgSbDw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=WPC8tcOLLyNldR3cBksJUbnSMAWC+aLJOmfR1iAiBfo=;
 b=I8/h9xJ28+pfvOxyob1jRHWV6QoXlEeFNb9zORhXdkcsOotL+ZYh+Xeyd/jnRPvgMckL6XumFGuL6pLDA8NMYaGH0DZsZFWQrnOKttQjzVBqSA//RrDGALIRB+ERjR/muB9L27Wc+LByd7GJ5WTEYRWeWAcQs49dVhU2lAJK+lEn8TKTSSHLGtFW0gaAqmO1bsEl/Q+965SrVmpAmJCHXi9Qi8VLs//h7r6pATkAkLXQXDXWyueyp7YUtrantiuDigb3Ss0Rqy5HhWN4Qb71TRDPyTz0tPf7VsSsaHQOrH8o4QquijExq/3O8OkAADTLSlG5ozC4rI8bz+IQSe6Nlw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=nxp.com; dmarc=pass action=none header.from=nxp.com; dkim=pass
 header.d=nxp.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector2;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=WPC8tcOLLyNldR3cBksJUbnSMAWC+aLJOmfR1iAiBfo=;
 b=htR3MmoPLgNTNct1AA7Hy3YZ3RR1jbyAyScT9CheTsgjBHlnB9dcs/8ZHM6NQMx7SkpMKikfXb5yxMuJLm4QxGwMu/9NFg/G1Q+rtiYPyQBSqdHCqIZwcQjHaZVbIq4oxcSmKmdgpJH+FDu+sWQ+IhNB4E0XoKTa6Q+Spwlo5Zo=
From: Peng Fan 
To: Stefano Stabellini , Julien Grall 
CC: John Ernberg , Bertrand Marquis
	, Michal Orzel , Volodymyr
 Babchuk , Jonas Blixt ,
	"xen-devel@lists.xenproject.org" 
Subject: RE: [PATCH 1/2] xen/arm: Add imx8q{m,x} platform glue
Thread-Topic: [PATCH 1/2] xen/arm: Add imx8q{m,x} platform glue
Thread-Index:
 AQHaVDuqVQ/kgxLZgUK/m8/hE0ez5bDz198AgAA1LICAAVx4AIAAQjaAgAEdtQCAAynKwIABnCuAgAZ8E4CAKNxCgIAApf0AgAKGQwCAAAbHgIAHmWEAgAtpgACAABVOgIAAaCSAgAAUn7A=
Date: Thu, 21 Mar 2024 01:09:06 +0000
Message-ID:
 
References: <20240131114952.305805-1-john.ernberg@actia.se>
 <20240131114952.305805-2-john.ernberg@actia.se>
 
 <494d4961-ad8a-4d1d-aaa6-d1bfb9d6a137@actia.se>
 <167f0c7a-e037-446c-82f8-2584e35a7af1@xen.org>
 
 <012b5f83-2f9b-4477-965e-07b8506c0052@xen.org>
 
 <5a0c8f09-4f01-45e9-892c-86342c0d0ec5@xen.org>
 <08ae764c-3490-4dd1-ab70-7a855a98d16d@actia.se>
 <911ec1bb-3733-4f37-839e-673a88e408ff@actia.se>
 
 <848794f3-a337-49d9-84db-a969970f071b@actia.se>
 <48038c7f-d7cd-4100-a41b-8042bcb93208@xen.org>
 <967020E7-3D03-416A-8BFC-6F4E4BD9D7B5@arm.com>
 
 <849f3f5a-b960-444a-a10e-1f2df36c22a7@xen.org>
 
In-Reply-To:
 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=nxp.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DU0PR04MB9417:EE_|PA4PR04MB7502:EE_
x-ms-office365-filtering-correlation-id: 0f432768-4acc-43ff-3d12-08dc494381db
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 VQaUQ5M9FIFo1DFy9dHg/ZZoGDF4sumapftbiQRlnesxwAIgQG89/KoweJ7zfgzINVfQ6NdpZiSgV1h41Vko7IHlV4NhRZjDDDw94TF+AhgLY2k7y1heXvhAEoz75WnjBSfxIUrxlljrOf7u7tjCqCyC5ZYsDpJFIWpf0fQ99ZBgi+QgDzgEZJR0ewnQGuazgm5iSxPDs6w2GgQdtOHJ0AA+qYkAaN9XXz7Hpf/bbIZKMJqZFgW2sJK5RcDRJM0gu9xPlEnU+Aqw1jhVOrEAB9YmBYvro3dVRq4fTTu7MZLmVc/tO6UJ7gb5XFaQlPwTPcS1888tMJGXTjBdABE+cEg0yv5AuHXxQ7QWCzXkJn25PCxbFNCnkbvFym/e/0H2QIcsprZ7GYN8g4J8olzZ6rEOdGF3rfgszC+MbNIa8R37QlqdkTTnNZCJe8vMLYI/Bwk1zjIb08UexJU1H5Y6tLzI9yjxAia+Z/OQowyxxnLW61H2gXcDdEgFQkiYQyjG8t+KdEnhieII4CxyeFdqRO4wxpQsmsQ826IZQdOr1QyH9wWWedZ3Ib+T6AJZcQ6/Lo1mLXD/sIMr7I7trEVZV7lmoWN4FxZKe9HOvj5smcbwA754by9Didc/t/7waQ71TbWftS7xWCA+cKj3C2oJ2JKWiooFMpleAydX/BhkJAM=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DU0PR04MB9417.eurprd04.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(376005)(366007)(1800799015)(38070700009);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?us-ascii?Q?M5dGvSoSa7jzI3R4RLajfWaWd2Jed+TOgZuLy864oNHZoTdr+Vq1NRK15E5y?=
 =?us-ascii?Q?8RxyV70PGLSlKNJhFMX4V7YSvGuCZLubUdpQXc/t/FuGYn/mYN39bKCD4y5G?=
 =?us-ascii?Q?BE6/C6412EUjub+gl33knTrPAdC/5vP8H3uH64UfsoRXB81GuyqfrtnqR76l?=
 =?us-ascii?Q?Pkzu49+KSO4vqI40FzQay3vh2MH5S2QIo0tDbbkAqxU/rriQxNDBhVy7uzyS?=
 =?us-ascii?Q?cyWwPxyNFIo1bOWOjkADZbNmjiRYByblh4QkSi0E44vBuTPwIuBnfTtl/eri?=
 =?us-ascii?Q?fCX0y+27pQ5sn137EybBEos599LQKgQZd8X8Ar+EO5BrUBHU7dJDFbUys5JT?=
 =?us-ascii?Q?huEZVnmvo+LDoignTh3hhZVYOslOa3PKV2uGYH1R3L832Su/Mysd7yV26zgd?=
 =?us-ascii?Q?ca8/FL1pZErAiPYEX4qka5JFmZHDr7krgwz11vdZ9Zvm1EtiF5jiV+J46lIY?=
 =?us-ascii?Q?drcMxWzxDI4y22KDOGaiI5FRZvF6fDPdftVvqEIlg9c6LLNIPtt4xvZzid8Q?=
 =?us-ascii?Q?CiBiOZiM8e4kpBIKE8kifNtUHCK9khMOezNF5LGOd5dPlLj5tJ8BtEWAGwXo?=
 =?us-ascii?Q?1/AFUox8YpGqjh0lUSfYt98i4WtrOlYLgyrT0EpK4542glleDAhDYlUBkR1r?=
 =?us-ascii?Q?7J8gHKhZWeO2f5ocOb1YV7K7LX2DvyVC4PPvAxToPUH15JA4QteBVLc1jwps?=
 =?us-ascii?Q?jtLkfN8bodaLhbT/dIdbNObp5voBzF70ifZPMD37MtDcCc34+jATqtx3237N?=
 =?us-ascii?Q?5ex7OeHhk2jldnKCg6FawRTsSNnp8HVZk+Isgn3isv6hrJYywse5wQ2hQMXy?=
 =?us-ascii?Q?oT8pZKEbyei/IaeOQVL9s77J/clBxZWGfvF1nLjc+K0B3x4GXsSlRP/+PhMv?=
 =?us-ascii?Q?tarD8k69eAdQTAbBaLVywtMLAUci3uc41g7BpXxGi9G1hSueNaSYP76H83Vn?=
 =?us-ascii?Q?x276CfYKXVlVNcYZsZHiJ8QwDyX5mqPaTWYkxPNm4Rs5bRlr3KzrHP+X2lx3?=
 =?us-ascii?Q?Slb/LqkrvNAO9GVPiWf6m3/QX+mhU6ndUjeOY5E+DNGKrHpBwqemBS9yxVq5?=
 =?us-ascii?Q?BhXeJHqfp1x89Uo1cyqgBGqiAe10+ZHqRbkDGXKY5OA5XpPel4k0s/l+Y89k?=
 =?us-ascii?Q?vxcAI6bc8IB6+IH2go2conIxRMjIDCBiAkKWVKQR8D9UrO4juMkZEhxeawPs?=
 =?us-ascii?Q?gvEv1LWycCQUxHgZmXadyT937Ydh6UfIJcC6VS6BTE0zqg7qmlRfk0tAGQkU?=
 =?us-ascii?Q?/9dnvWju2pmwC2MSEWEvO5Yd/pe8C0FDrjUVQ9OH6SKJ7+wPc+j4hRsEPmov?=
 =?us-ascii?Q?yrAaCgbEZ5A2BC8pcHwaIztPBcG2SxSiImUwvXUw9lptMiAEwCaWlOce/7Qq?=
 =?us-ascii?Q?X99QNC+q9A/gvcFkxFqssymxDwTsCzPvf2mjTzKrfdjM5wkZ1cJrViSkQuq1?=
 =?us-ascii?Q?cQ3pQ2Ys8do60xppwlYf4JxZbG3AeqppXWGzCLkiEhmIpkzag9kG7CzvsRq4?=
 =?us-ascii?Q?F9rq5Id4FfyRvsaJEOQ1DSPX8y0u4xLjkJXXnt69MDbbzQDUVUu9wIOcE4EA?=
 =?us-ascii?Q?Y7GV92HjScPDKlZZzM4=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nxp.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DU0PR04MB9417.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0f432768-4acc-43ff-3d12-08dc494381db
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Mar 2024 01:09:06.9520
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: qbei1gHSWS1GDBjLilnj9dsLwQGTuhhufx/kOktgtH8jNlL6JFDxXClTuBl/9QAqMeyieKVP8W8Wkn+DoFDdjQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR04MB7502

> Subject: Re: [PATCH 1/2] xen/arm: Add imx8q{m,x} platform glue
>=20
> On Wed, 20 Mar 2024, Julien Grall wrote:
> > Hi John,
> >
> > On 20/03/2024 16:24, John Ernberg wrote:
> > > Hi Bertrand,
> > >
> > > On 3/13/24 11:07, Bertrand Marquis wrote:
> > > > Hi,
> > > >
> > > > > On 8 Mar 2024, at 15:04, Julien Grall  wrote:
> > > > >
> > > > > Hi John,
> > > > >
> > > > > Thank you for the reply.
> > > > >
> > > > > On 08/03/2024 13:40, John Ernberg wrote:
> > > > > > On 3/7/24 00:07, Julien Grall wrote:
> > > > > > >    > Ping on the watchdog discussion bits.
> > > > > > >
> > > > > > > Sorry for the late reply.
> > > > > > >
> > > > > > > On 06/03/2024 13:13, John Ernberg wrote:
> > > > > > > > On 2/9/24 14:14, John Ernberg wrote:
> > > > > > > > >
> > > > > > > > > >       * IMX_SIP_TIMER_*:  This seems to be related to
> > > > > > > > > > the watchdog.
> > > > > > > > > > Shouldn't dom0 rely on the watchdog provided by Xen
> instead?
> > > > > > > > > > So those
> > > > > > > > > > call will be used by Xen.
> > > > > > > > >
> > > > > > > > > That is indeed a watchdog SIP, and also for setting the
> > > > > > > > > SoC internal RTC if it is being used.
> > > > > > > > >
> > > > > > > > > I looked around if there was previous discussion and
> > > > > > > > > only really found [3].
> > > > > > > > > Is the xen/xen/include/watchdog.h header meant to be for
> > > > > > > > > this kind of watchdog support or is that more for the VM
> > > > > > > > > watchdog? Looking at the x86 ACPI NMI watchdog it seems
> > > > > > > > > like the former, but I have never worked with
> > > > > > > > > x86 nor ACPI.
> > > > > > >
> > > > > > > include/watchdog.h contains helper to configure the watchdog
> > > > > > > for Xen. We also have per-VM watchdog and this is configured
> > > > > > > by the hypercall SCHEDOP_watchdog.
> > > > > > >
> > > > > > > > >
> > > > > > > > > Currently forwarding it to Dom0 has not caused any
> > > > > > > > > watchdog resets with our watchdog timeout settings, our
> > > > > > > > > specific Dom0 setup and VM count.
> > > > > > >
> > > > > > > IIUC, the SMC API for the watchdog would be similar to the
> > > > > > > ACPI NMI watchdog. So I think it would make more sense if
> > > > > > > this is not exposed to
> > > > > > > dom0 (even if Xen is doing nothing with it).
> > > > > > >
> > > > > > > Can you try to hide the SMCs and check if dom0 still behave
> > > > > > > properly?
> > > > > > >
> > > > > > > Cheers,
> > > > > > >
> > > > > > This SMC manages a hardware watchdog, if it's not pinged
> > > > > > within a specific interval the entire board resets.
> > > > >
> > > > > Do you know what's the default interval? Is it large enough so
> > > > > Xen +
> > > > > dom0 can boot (at least up to when the watchdog driver is initial=
ized)?
> > > > >
> > > > > > If I block the SMCs the watchdog driver in Dom0 will fail to
> > > > > > ping the watchdog, triggering a board reset because the system
> > > > > > looks to have become unresponsive. The reason this patch set
> > > > > > started is because we couldn't ping the watchdog when running w=
ith
> Xen.
> > > > > > In our specific system the bootloader enables the watchdog as
> > > > > > early as possible so that we can get watchdog protection for
> > > > > > as much of the boot as we possibly can.
> > > > > > So, if we are to block the SMC from Dom0, then Xen needs to
> > > > > > take over the pinging. It could be implemented similarly to
> > > > > > the NMI watchdog, except that the system will reset if the
> > > > > > ping is missed rather than backtrace.
> > > > > > It would also mean that Xen will get a whole watchdog
> > > > > > driver-category due to the watchdog being vendor and sometimes
> > > > > > even SoC specific when it comes to Arm.
> > > > > > My understanding of the domain watchdog code is that today the
> > > > > > domain needs to call SCHEDOP_watchdog at least once to start
> > > > > > the watchdog timer. Since watchdog protection through the
> > > > > > whole boot process is desirable we'd need some core changes,
> > > > > > such as an option to start the domain watchdog on init. > It's
> > > > > > quite a big change to make
> > > > >
> > > > > For clarification, above you seem to mention two changes:
> > > > >
> > > > > 1) Allow Xen to use the HW watchdog
> > > > > 2) Allow the domain to use the watchdog early
> > > > >
> > > > > I am assuming by big change, you are referring to 2?
> > > > >
> > > > > , while I am not against doing it if it
> > > > > > makes sense, I now wonder if Xen should manage hardware
> watchdogs.
> > > > > > Looking at the domain watchdog code it looks like if a domain
> > > > > > does not get enough execution time, the watchdog will not be
> > > > > > pinged enough and the guest will be reset. So either watchdog
> > > > > > approach requires Dom0 to get execution time. Dom0 also needs
> > > > > > to service all the PV backends it's responsible for. I'm not
> > > > > > sure it's valuable to add another layer of watchdog for this
> > > > > > scenario as the end result (checking that the entire system
> > > > > > works) is achieved without it as well.
> > > > > > So, before I try to find the time to make a proposal for
> > > > > > moving the hardware watchdog bit to Xen, do we really want it?
> > > > >
> > > > > Thanks for the details. Given that the watchdog is enabled by
> > > > > the bootloader, I think we want Xen to drive the watchdog for two
> reasons:
> > > > > 1) In true dom0less environment, dom0 would not exist
> > > > > 2) You are relying on Xen + Dom0 to boot (or at least enough to
> > > > > get the watchdog working) within the watchdog interval.
> > > >
> > > > Definitely we need to consider the case where there is no Dom0.
> > > >
> > > > I think there are in fact 3 different use cases here:
> > > > - watchdog fully driven in a domain (dom0 or another): would work
> > > > if it is expected
> > > >     that Xen + Domain boot time is under the watchdog initial
> > > > refresh rate. I think this
> > > >     could make sense on some applications where your system
> > > > depends on a specific
> > > >     domain to be properly booted to work. This would require an
> > > > initial refresh time
> > > >     configurable in the boot loader probably.
> > >
> > > This is our use-case. ^
> > >
> > > Our dom0 is monitoring and managing the other domains in our system.
> > > Without dom0 working the system isn't really working as a whole.
> > >
> > > @Julien: Would you be ok with the patch set continuing in the
> > > direction of the original proposal, letting another party (or me at
> > > a later time) implement the fully driven by Xen option?
> > I am concerned about this particular point from Bertrand:
> >
> > "would work if it is expected that Xen + Domain boot time is under the
> > watchdog initial refresh rate."
> >
> > How will a user be able to figure out how to initially configure the wa=
tchdog?
> > Is this something you can easily configure in the bootloader at runtime=
?
> >
> >
> > Overall, I am not for this approach at least in the current status. I
> > would be more inclined if there are some documentations explaining how
> > this is supposed to be configured on NXP, so others can use the code.

I will try to push inside NXP to release a documentation on SIP usage.
But not expect it will be released soon.
The SIP number is quite stable, and we not change the meaning.

Regards,
Peng.

> >
> > Anyway, this is why we have multiple Arm maintainers for this kind of
> > situation. If they other agrees with you, then they can ack the patch
> > and this can be merged.
>=20
>=20
> The approach here would not be my choice either. However, I think it woul=
d
> be nice to have better support for NXP imx8 boards in upstream Xen. To th=
at
> end, I would ack these patches but I would ask to add a document under
> xen.git/docs/ explaining the approach, limitations, and requirements, so =
that
> someone else can use the code effectively.


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 01:12:37 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 01:12:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696167.1086837 (Exim 4.92)
	(envelope-from )
	id 1rn6yy-0002uL-JH; Thu, 21 Mar 2024 01:12:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696167.1086837; Thu, 21 Mar 2024 01:12:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rn6yy-0002uE-GY; Thu, 21 Mar 2024 01:12:36 +0000
Received: by outflank-mailman (input) for mailman id 696167;
 Thu, 21 Mar 2024 01:12:35 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rn6yx-0002u6-9o
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 01:12:35 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 17f6e01b-e720-11ee-a1ee-f123f15fe8a2;
 Thu, 21 Mar 2024 02:12:33 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 56CB061118;
 Thu, 21 Mar 2024 01:12:31 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id C6D1FC433C7;
 Thu, 21 Mar 2024 01:12:29 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 17f6e01b-e720-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1710983551;
	bh=zoMUlM69DxV9enxAWbPgoyG7oftA8/YCaDAjcAhyPDA=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=XoJ5Qe99u4bCBvmfSKuZYMamBQNvPuagc2UX3CmbFfZZ+VrOpGVANwqK/6cKH3imG
	 dexmXFkzESNqxmU/3HVzxEwGL3MnZ8gwrhRpANOMZhTlwbc8HADpnOv5GcBlUGgyS7
	 Pd4iqNv/iomrZxgYyG++qLraAWgzgdrLnO3rjpOo/QFl+UP4yTU9YdWtHs7knM/u86
	 u0JPT8Mxdn1FEWx8VsdRDdunSArUukN4bfuK4tHRu0re+8k+lz57PjQGYQocM0hAEP
	 qmLaXz5sCB1VYz1LfpUQCCVmN291u91vaf7deysgJrE1N/n/O5dmupsxbpumBmqoQZ
	 P/l/90AKlgKsg==
Date: Wed, 20 Mar 2024 18:12:27 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich 
cc: Jason Andryuk , 
    Andrew Cooper , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Wei Liu , George Dunlap , 
    Julien Grall , Stefano Stabellini , 
    xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3 3/3] x86/PVH: Support relocatable dom0 kernels
In-Reply-To: 
Message-ID: 
References: <20240319205849.115884-1-jason.andryuk@amd.com> <20240319205849.115884-4-jason.andryuk@amd.com> 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Wed, 20 Mar 2024, Jan Beulich wrote:
> On 19.03.2024 21:58, Jason Andryuk wrote:
> > --- a/xen/arch/x86/hvm/dom0_build.c
> > +++ b/xen/arch/x86/hvm/dom0_build.c
> > @@ -537,6 +537,97 @@ static paddr_t __init find_memory(
> >      return INVALID_PADDR;
> >  }
> >  
> > +static bool __init check_load_address(
> > +    const struct domain *d, const struct elf_binary *elf)
> > +{
> > +    paddr_t kernel_start = (paddr_t)elf->dest_base;
> 
> As before I think it is illegitimate to cast a pointer to paddr_t. The
> variable type wants to remain such, but the cast wants to be to
> unsigned long or uintptr_t (or else at least a comment wants adding).

uintptr_t is a good suggestion. uintptr_t is the recommended way by the
C standard and MISRA by extension to cast integers to points and vice
versa. In Xen we have used unsigned long for the same purpose although it
is not the best way any longer (something else to document).


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 01:46:44 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 01:46:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696170.1086846 (Exim 4.92)
	(envelope-from )
	id 1rn7Vq-0007Yr-2K; Thu, 21 Mar 2024 01:46:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696170.1086846; Thu, 21 Mar 2024 01:46:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rn7Vp-0007Yk-Vr; Thu, 21 Mar 2024 01:46:33 +0000
Received: by outflank-mailman (input) for mailman id 696170;
 Thu, 21 Mar 2024 01:46:32 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rn7Vo-0007Ye-Dy
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 01:46:32 +0000
Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d5d428fc-e724-11ee-afdf-a90da7624cb6;
 Thu, 21 Mar 2024 02:46:30 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sin.source.kernel.org (Postfix) with ESMTP id 61946CE1282;
 Thu, 21 Mar 2024 01:46:27 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6D9ECC433F1;
 Thu, 21 Mar 2024 01:46:25 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d5d428fc-e724-11ee-afdf-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1710985586;
	bh=S8wrytfcIW89807vsPn2b7h0OhN+slgwgBdID7tNJu4=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=hUYuitUfkSVydIYjq9fchuJ8ENuesBqRYTXGtsdpnhQxJYko6v+uI2weNj6vg3a3x
	 Q6v3UyLKdN5ahl0BvRTCYUxYfWYhQvqu7/jqJ+RUf1mSvhdTp7EVKl8ykA0x7j4ZPt
	 TLEv+Ziot2Vor1vBRZfXhFN5wV4q9Cfenx6iYoTh3S9cay/qvYG7Iw36tk04AdS3j7
	 U6gYr7eOjuWUSwrpgSVRVzCqERsG8BmUBNqfWGe3RBJGIq0Jb/9X7lxPTQlyAPDdYF
	 wFew7A+eitaCLoVlaZIoZuvSg4k/KKFzvC7E/hoZG0MVe38BmAeYHghDkvtMDpu/Wd
	 FX8Tvgo36MBgg==
Date: Wed, 20 Mar 2024 18:46:23 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich 
cc: Stefano Stabellini , andrew.cooper3@citrix.com, 
    bertrand.marquis@arm.com, george.dunlap@citrix.com, julien@xen.org, 
    michal.orzel@amd.com, roger.pau@citrix.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2] docs/misra: document the expected sizes of integer
 types
In-Reply-To: <87234837-9fb3-40a9-849d-8b8574f2661c@suse.com>
Message-ID: 
References:  <6a76723e-ba47-40b3-8f33-d68030b14299@suse.com>  <7ab73379-b057-4568-9869-141cef185752@suse.com>
    <87234837-9fb3-40a9-849d-8b8574f2661c@suse.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Wed, 20 Mar 2024, Jan Beulich wrote:
> > - the public interface is described in a C header so it makes sense for
> >   the corresponding implementation to be in C
> > 
> > - the C entry point is often both the entry point in C and also common
> >   code
> > 
> > - depending on the architecture, there is typically always some minimal
> >   assembly entry code to prepare the environment before we can jump into
> >   C-land; still one wouldn't consider those minimal and routine assembly
> >   operations to be a meaningful hypercall entry point corresponding to
> >   the C declaration in the public headers
> > 
> > - as per MISRA and also general good practice, we need the declaration
> >   in the public header files to match the definition in C
> 
> Throughout, but especially with this last point, I feel there's confusion
> (not sure on which side): There are no declarations of hypercall functions
> in the public headers. Adding declarations there for the C entry points in
> Xen would actually be wrong, as we don't provide such functions anywhere
> (to consumers of the ABI).

I am copy/pasting text from sched.h:

 * The prototype for this hypercall is:
 * ` long HYPERVISOR_sched_op(enum sched_op cmd, void *arg, ...)
 *
 * @cmd == SCHEDOP_??? (scheduler operation).
 * @arg == Operation-specific extra argument(s), as described below.
 * ...  == Additional Operation-specific extra arguments, described below.
 *

from event_channel.h:

 * ` enum neg_errnoval
 * ` HYPERVISOR_event_channel_op(enum event_channel_op cmd, void *args)
 * `
 * @cmd  == EVTCHNOP_* (event-channel operation).
 * @args == struct evtchn_* Operation-specific extra arguments (NULL if none).

These are the hypercall declarations in public headers. Although they
are comments, they are the only description of the ABI that we have (as
far as I know). They are in C and use C types. 


> >>> Also, as this is an ABI, I consider mandatory to use clear width
> >>> definitions of all the types (whether with this document or with
> >>> fixed-width types, and fixed-width types are clearer and better) in both
> >>> the C header files that describe the ABI interfaces, as well as the C
> >>> entry points that corresponds to it. E.g. I think we have to use
> >>> the same types in both do_sched_op and the hypercall description in
> >>> xen/include/public/sched.h
> >>
> >> There are two entirely separate aspects to the ABI: One is what we
> >> document towards consumers of it. The other is entirely internal, i.e.
> >> an implementation detail - how we actually consume the data.
> >> Documenting fixed-width types towards consumers is probably okay,
> >> albeit (see below) imo still not strictly necessary (for being
> >> needlessly limiting).
> > 
> > I don't see it this way.
> > 
> > As the Xen public interface description is in C and used during the
> > build, my opinion is that the public description and the C definition
> > need to match.
> > 
> > Also, I don't understand how you can say that public interfaces don't
> > strictly necessarily have to use fixed-width types.
> > 
> > Imagine that you use native types with different compilers that can
> > actually output different width interger sizes (which is not possible
> > today with gcc or clang). Imagine that a guest is written in a language
> > other than C (e.g. Java) based on the public interface description. It
> > cannot work correctly, can it?
> 
> They'd need to write appropriate hypercall invocation functions. As per
> above - we don't provide these in the public headers, not even for C
> consumers.

See above


> > I don't see how we can possibly have a public interface with anything
> > other than fixed-width integers.
> 
> That's the consumer side of the ABI. It says nothing about the internal
> implementation details in Xen. All we need to do there is respect the
> ABI. That has no influence whatsoever on the C entry points when those
> aren't the actual hypercall entrypoints into the hypervisor.

If we go by the strictest definition, nothing is actually called directly
except for the target of a "b" instruction.

When you call a function in C, you are not actually calling a function.
Assembly is generated to save variables and do other things before "b".
Still, typically it is still considered a "direct" call.

It is not exactly the same thing with hypercall, but I hope I conveyed
the idea why I consider the C hypercall entry points part of the ABI.


> >>>> As to public ABIs - that's structure definitions, and I agree we ought
> >>>> to uniformly use fixed-width types there. We largely do; a few things
> >>>> still require fixing.
> >>>
> >>> +1
> >>>
> >>>
> >>>>> We have two options:
> >>>>>
> >>>>> 1) we go with this document, and we clarify that even if we specify
> >>>>>   "unsigned int", we actually mean a 32-bit integer
> >>>>>
> >>>>> 2) we change all our public ABIs and C hypercall entry points to use
> >>>>>    fixed-size types (e.g. s/unsigned int/uint32_t/g)
> >>>>>
> >>>>> 2) is preferred because it is clearer but it is more work. So I went
> >>>>> with 1). I also thought you would like 1) more.
> >>>>
> >>>> For ABIs (i.e. structures) we ought to be making that change anyway.
> >>>> Leaving basic types in there is latently buggy.
> >>>
> >>> I am glad we agree :-)
> >>>
> >>> It is just that I also consinder the C hypercall entry points as part of
> >>> the ABI
> >>>
> >>>
> >>>> I'm happy to see a document like this added, for the purpose described
> >>>> above. But to me 1) and 2) and largely independent of one another.
> >>>
> >>> Good that you are also happy with a document like this.
> >>>
> >>> The remaining question is: what about the rest of the C functions in Xen
> >>> that are certainly not part of an ABI?
> >>
> >> As per above - anything internal isn't part of the ABI, C entry points
> >> for hypercall handlers included. All we need to ensure is that we consume
> >> the data according to what the ABI sets forth.
> > 
> > It doesn't look like we'll convince one another on this point. But let
> > me try another way.
> > 
> > In my view, having mismatched types between declaration and definition
> > and having non-fixed-width types in C hypercall entry points is really
> > bad for a number of reasons, among them:
> > - correctness
> > - risk of ABI breakage
> > - mismatch of declaration and definition
> 
> What mismatches are you talking about? There's nothing mismatched now,
> and there cannot be any mismatch, because the consumers of the ABI don't
> call Xen functions directly.

Let me make an example:

- public header saying enum event_channel_op cmd
- 
- do_event_channel_op(int cmd, ...)

Do you think this is all good?

There are two pretty serious problems here:
- enum and int are not the same type
- enum and int are not fixed-width

Don't you think it should be:

- public header saying uint32_t cmd in a comment
- 
- do_something_op(uint32_t cmd, ...)

Or possibly unsigned long depending on the parameter.

?


> > In your view, the drawback is not following the CODING_STYLE.
> > 
> > The two points of views on this subject don't have the same to lose. If
> > I were you, I would probably not invest my energy to defend the
> > CODING_STYLE.
> > 
> > 
> >> To use wording from George when he criticized my supposed lack of actual
> >> arguments: While there's nothing technically wrong with using fixed
> >> width types there (or in fact everywhere), there's also nothing technically
> >> wrong with using plain C types there and almost everywhere else (ABI
> >> structures excluded). With both technically equal, ./CODING_STYLE has the
> >> only criteria to pick between the two. IOW that's what I view wrong in
> >> George's argumentation: Demanding that I provide technical arguments when
> >> the desire to use fixed width types for the purpose under discussion also
> >> isn't backed by any.
> > 
> > I don't think we are in violation of the CODING_STYLE as it explicitly
> > accounts for exceptions. Public interfaces declarations and definitions
> > (hypercalls C entry points included) are an exception.
> 
> If that was technically necessary, I would surely agree to there being an
> exception here.

Great, that's a start


> > In my opinion, using fixed-width integers in public headers and C
> > definitions (including C hypercall entry points) is top priority for
> > correctness. Correctness is more important than style. So, if we need to
> > change the CODING_STYLE to get there, let's change the CODING_STYLE.
> > 
> > 
> >>> Those are less critical, still this document should apply uniformily to
> >>> them too. I don't understand why you are making the >= width assumption
> >>> you mentioned at the top of the file when actually it is impossible to
> >>> exercise or test this assumption on any compiler or any architecture
> >>> that works with Xen. If it cannot be enabled, it hasn't been tested, and
> >>> it probably won't work.
> >>
> >> Hmm, yes, that's one way to look at it. My perspective is different though:
> >> By writing down assumptions that are more strict than necessary, we'd be
> >> excluding ports to environments meeting the >= assumption, but not meeting
> >> the == one. Unless of course you can point me at any place where - not
> >> just by mistake / by being overly lax - we truly depend on the == that you
> >> want to put in place. IOW yes, there likely would need to be adjustments
> >> to code if such a port was to happen. Yet we shouldn't further harden
> >> requirements that were never meant to be there.
> > 
> > I have already shown that all the current implementations and tests only
> > check for ==. In my opinion, this is sufficient evidence that >= is not
> > supported.
> > 
> > If you admit it probably wouldn't work without fixes today, would you
> > security-support such a configuration? Would you safety-support it? I
> > wouldn't want to buy a car running Xen compiled with a compiler using
> > integer sizes different from the ones written in this document.
> > 
> > Let me summarize our positions on these topics.
> > 
> > Agreed points:
> > - public interfaces should use fixed-width types
> > - it is a good idea to have a document describing our assumptions about
> >   integer types
> > 
> > Open decision points and misalignments:
> > - Should the C hypercall entry points match the public header
> >   declarations and ideally use fixed-width integer types? 
> 
> As per above, this question just cannot be validly raised. There are
> no public header declarations to match.

I clarified


> > I'd say yes and I would argue for it
> > 
> > - Should the document describing our assumptions about integer types
> >   specify == (unsigned int == uint32_t) or >= (unsigned int >=
> >   uint32_t)?
> > 
> > I'd say specify == and I would argue for it
> 
> Actually, I had a further thought here in the meantime: For particular
> ports, using == is likely okay - they're conforming to particular
> psABI-s, after all (and that's what the compilers used also implement).
> I'd nevertheless expect >= to be used in common assumptions. That way
> for existing ports you get what you want, and there would still be
> provisions for new ports using, say, an ILP64 ABI. Common code would
> need to adhere to the common assumptions only. Arch-specific code can
> work from the more tight assumptions. (If future sub-arch variants are
> to be expected, like RV128, arch-code may still be well advised to try
> to avoid the more tight assumptions where possible, just to limit
> eventual porting effort.)

I understand the aspirational goal of supporting >= but in reality it is
not tested, if it is not tested it cannot work, if it cannot work, we
cannot support it. If someone creates a compiler or other tool to check
for >= I would be happy to discuss expanding the document. Without any
tests, I don't think it would be useful to write down >=, not even as
an aspirational goal. A goal must be actionable.


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 01:48:05 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 01:48:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696173.1086857 (Exim 4.92)
	(envelope-from )
	id 1rn7XI-000882-FA; Thu, 21 Mar 2024 01:48:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696173.1086857; Thu, 21 Mar 2024 01:48:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rn7XI-00087v-CI; Thu, 21 Mar 2024 01:48:04 +0000
Received: by outflank-mailman (input) for mailman id 696173;
 Thu, 21 Mar 2024 01:48:02 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rn7XG-00087p-Q1
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 01:48:02 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0cbdc5ee-e725-11ee-afdf-a90da7624cb6;
 Thu, 21 Mar 2024 02:48:01 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 37F4E61135;
 Thu, 21 Mar 2024 01:48:00 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 15893C433C7;
 Thu, 21 Mar 2024 01:47:57 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0cbdc5ee-e725-11ee-afdf-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1710985679;
	bh=oy0jgCRFCq+F1iMwkJyDoi1QP4R5oXndVd0E1OzCq98=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=IBmEVjSS9n0C2R30h08le1/7DMmZOujF8+/b5ThxuXi8qGk/BfwseeKCK27N3Cb6p
	 m3VfT+zZkahvdEsG8SzFDF8S/Te4hoYW6D+9Uwwl6ltKceHBmqgsAMSgxlVlXJnsTo
	 Co+TRUo9H8c0XM3lxPV4mfo5RHyAH+n9HkTQZIRehOkhqWnEKAGApOJbnlxH0z5uBz
	 6K4rExu1eDHQ6k/7DW6rWicdgjC0gz84Plw2DF+PFurROj4XxqGrFFzlYeCI4U+OGS
	 +IyYrXmfI63azmnhkEPPA4bfbjluxuSDiV7LnMF/iQzKjSZJZEuviC65xZ14RR76D7
	 EoBsg7wO5xU9w==
Date: Wed, 20 Mar 2024 18:47:56 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich 
cc: Simone Ballarin , consulting@bugseng.com, 
    Andrew Cooper , 
    George Dunlap , Julien Grall , 
    Stefano Stabellini , Wei Liu , 
    Bertrand Marquis , 
    Michal Orzel , 
    Volodymyr Babchuk , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    xen-devel@lists.xenproject.org
Subject: Re: [XEN PATCH 2/2] xen: address violations of MISRA C Rule 17.1
In-Reply-To: <4ce30a38-5b5c-4d4c-a0c4-8c1a63759203@suse.com>
Message-ID: 
References:   <4ce30a38-5b5c-4d4c-a0c4-8c1a63759203@suse.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Wed, 20 Mar 2024, Jan Beulich wrote:
> On 20.03.2024 09:51, Simone Ballarin wrote:
> > MISRA C Rule 20.7 states: "The features of `' shall not be used"
> > 
> > The Xen community wants to avoid using variadic functions except for
> > specific circumstances where it feels appropriate by strict code review.
> > 
> > Functions hypercall_create_continuation and hypercall_xlat_continuation
> > are special hypercalls made to break long running hypercalls into multiple
> > calls.
> 
> Here and below: These aren't "special hypercalls". They're internal helper
> functions.

+1


> > They take a variable number of arguments depending on the original
> > hypercall they are trying to continue.
> 
> Am I misremembering or did Andrew outline a plan to eliminate the variadic-
> ness from these? From certifiability perspective avoiding the need for a
> deviation would likely be preferable?

For sure, it would be preferable. In the meantime we can have the SAF
comment?


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 01:50:58 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 01:50:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696175.1086868 (Exim 4.92)
	(envelope-from )
	id 1rn7a5-0001cK-U8; Thu, 21 Mar 2024 01:50:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696175.1086868; Thu, 21 Mar 2024 01:50:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rn7a5-0001cD-PO; Thu, 21 Mar 2024 01:50:57 +0000
Received: by outflank-mailman (input) for mailman id 696175;
 Thu, 21 Mar 2024 01:50:56 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rn7a4-0001c2-3N
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 01:50:56 +0000
Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 734bf2a4-e725-11ee-afdf-a90da7624cb6;
 Thu, 21 Mar 2024 02:50:54 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sin.source.kernel.org (Postfix) with ESMTP id 35C2BCE126F;
 Thu, 21 Mar 2024 01:50:52 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3AE1BC433C7;
 Thu, 21 Mar 2024 01:50:50 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 734bf2a4-e725-11ee-afdf-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1710985851;
	bh=zhlHJSAyn7yUNAuJKEyXBF9XeNfl89xSX4Ho/3C2geA=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=k870F1WFnZhPysmYBdTSskJmMu/FnfG/i+BtJGOJ5c7PrMYRTc9XIUxm58wDB3mUk
	 abzZ7wnoRf75TY4ovOOnlE8kBGAFPjztz2+GsyJNiAjbYIM7RhJcAk1sSXxc0OT9ip
	 5CuzbSAJqGgemz6RgMMk/4feBXBDgg/VdTEt3Kt1ydijeW8J1+pH2rhYtk4G1vx8J7
	 dQYdUEf2UebkTmSvWXQIAU0m9/nbbS+Ssn4fmAnHcgNJiprsrnoDwtEGw4V0YmG7si
	 Xy6JFzftNOMiviTCGayUXy/lm3SnOd46M0X4cKKRwC9YLKf+Ni0YA5AQTmPAZiCsil
	 58touNceBTLIg==
Date: Wed, 20 Mar 2024 18:50:48 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich 
cc: Simone Ballarin , consulting@bugseng.com, 
    Doug Goldstein , 
    Stefano Stabellini , 
    Andrew Cooper , 
    George Dunlap , Julien Grall , 
    Wei Liu , xen-devel@lists.xenproject.org
Subject: Re: [XEN PATCH 1/2] automation/eclair: add deviation for MISRA C:2012
 Rule 17.1
In-Reply-To: <9341a711-74c3-463f-8cc2-a54e19b4b2f4@suse.com>
Message-ID: 
References:  <882b442c8c1f73f8116676ab9351defe5c9609ac.1710923235.git.simone.ballarin@bugseng.com> <9341a711-74c3-463f-8cc2-a54e19b4b2f4@suse.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Wed, 20 Mar 2024, Jan Beulich wrote:
> On 20.03.2024 09:50, Simone Ballarin wrote:
> > MISRA C:2012 Rule 17.1 states:
> > The features of `' shall not be used
> > 
> > The Xen community wants to avoid using variadic functions except for
> > specific circumstances where it feels appropriate by strict code review.
> > 
> > Add deviation for functions related to console output (printk and similar).
> > 
> > Signed-off-by: Simone Ballarin 
> > ---
> >  .../eclair_analysis/ECLAIR/deviations.ecl     | 26 +++++++++++++++++++
> >  docs/misra/deviations.rst                     |  5 ++++
> >  2 files changed, 31 insertions(+)
> > 
> > diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
> > index 9ac3ee4dfd..7c3559a3a0 100644
> > --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> > +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> > @@ -382,6 +382,32 @@ explicit comment indicating the fallthrough intention is present."
> >  -config=MC3R1.R16.6,switch_clauses+={deliberate, "default(0)"}
> >  -doc_end
> >  
> > +#
> > +# Series 17.
> > +#
> > +
> > +-doc_begin="Functions related to console output are allowed to use the variadic features provided by stdarg.h."
> > +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(debugtrace_printk)&&kind(function))))"}
> 
> This isn't concole output related.

Should we say "related to console output or tracing" ?


> > +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(dt_dprintk)&&kind(function))))"}
> > +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(printk)&&kind(function))))"}
> > +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(guest_printk)&&kind(function))))"}
> > +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(panic)&&kind(function))))"}
> > +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(dprintk)&&kind(function))))"}
> > +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(gdprintk)&&kind(function))))"}
> > +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(snprintf)&&kind(function))))"}
> > +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(scnprintf)&&kind(function))))"}
> > +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(xasprintf)&&kind(function))))"}
> 
> These three and ...
> 
> > +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(mm_printk)&&kind(function))))"}
> > +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(dbgp_printk)&&kind(function))))"}
> > +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(elf_call_log_callback)&&kind(function))))"}
> > +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(vsnprintf)&&kind(function))))"}
> > +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(vscnprintf)&&kind(function))))"}
> > +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(xvasprintf)&&kind(function))))"}
> 
> ... these three aren't either.

Maybe it is better to write it as:

"Functions related printk, logging and tracing are allowed..."


> > +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(vprintk_common)&&kind(function))))"}
> > +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(guest_printk)&&kind(function))))"}
> > +-config=MC3R1.R17.1,macros+={hide , "^va_(arg|start|copy|end)$"}
> > +-doc_end
> 
> Further, is there a reason xyzprintk() are all listed individually?
> Surely if we'd introduce a new flavor, we'd want that excluded too.
> 
> Finally, {,g}dprintk() in neither of their incarnation use any of the
> va_* items listed. Why do they need mentioning here?



From xen-devel-bounces@lists.xenproject.org Thu Mar 21 02:36:11 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 02:36:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696180.1086876 (Exim 4.92)
	(envelope-from )
	id 1rn8He-0008Qz-5s; Thu, 21 Mar 2024 02:35:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696180.1086876; Thu, 21 Mar 2024 02:35:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rn8He-0008Qs-2v; Thu, 21 Mar 2024 02:35:58 +0000
Received: by outflank-mailman (input) for mailman id 696180;
 Thu, 21 Mar 2024 02:35:56 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rn8Hc-0008Qi-LD; Thu, 21 Mar 2024 02:35:56 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rn8Hc-0005M7-5L; Thu, 21 Mar 2024 02:35:56 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rn8Hb-0004PC-QT; Thu, 21 Mar 2024 02:35:55 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rn8Hb-00087K-Pu; Thu, 21 Mar 2024 02:35:55 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=HtGeZJugFrzbMJIfKWztaV9OKI+Hzy/c+p7Qs6jvoB0=; b=d2CrnTy8XddUSKf2VH1p5HW3hf
	tCVi5QwsIzhIlFTl6o6wcdcE4XWojAhmkio5OiYAwJALs7ve171nBiumOErCuxXhjjZs9A+b0YxWT
	S36UEUND/YolL/y+z74R9GbYvHQaSAKizwThl/TkWvc5s4StS9fWRp0A1/4v2nXDpGN4=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-5.4 test] 185108: tolerable FAIL - PUSHED
X-Osstest-Failures:
    linux-5.4:test-armhf-armhf-xl-credit1:guest-start:fail:heisenbug
    linux-5.4:test-armhf-armhf-xl-rtds:guest-start:fail:heisenbug
    linux-5.4:test-armhf-armhf-xl-multivcpu:guest-start/debian.repeat:fail:heisenbug
    linux-5.4:test-armhf-armhf-xl-vhd:guest-start/debian.repeat:fail:heisenbug
    linux-5.4:test-armhf-armhf-xl-multivcpu:guest-start:fail:heisenbug
    linux-5.4:test-armhf-armhf-xl-credit1:guest-start.2:fail:heisenbug
    linux-5.4:test-arm64-arm64-libvirt-raw:guest-start/debian.repeat:fail:heisenbug
    linux-5.4:test-armhf-armhf-libvirt-qcow2:guest-start:fail:heisenbug
    linux-5.4:test-armhf-armhf-xl-credit2:guest-start/debian.repeat:fail:heisenbug
    linux-5.4:test-armhf-armhf-xl-arndale:xen-boot:fail:heisenbug
    linux-5.4:test-armhf-armhf-libvirt-raw:guest-start/debian.repeat:fail:heisenbug
    linux-5.4:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
    linux-5.4:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking
    linux-5.4:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
    linux-5.4:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking
    linux-5.4:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    linux-5.4:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    linux-5.4:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    linux-5.4:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
    linux-5.4:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
    linux-5.4:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-5.4:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    linux-5.4:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    linux-5.4:test-amd64-i386-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-5.4:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    linux=84075826304f1a297838de6bcfd9bd84f566026e
X-Osstest-Versions-That:
    linux=3fec063b052e395f4920fbc59a8d0bb3c9666d76
From: osstest service owner 
Date: Thu, 21 Mar 2024 02:35:55 +0000

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-credit1  14 guest-start      fail in 185071 pass in 185108
 test-armhf-armhf-xl-rtds     14 guest-start      fail in 185071 pass in 185108
 test-armhf-armhf-xl-multivcpu 18 guest-start/debian.repeat fail in 185071 pass in 185108
 test-armhf-armhf-xl-vhd 17 guest-start/debian.repeat fail in 185071 pass in 185108
 test-armhf-armhf-xl-multivcpu 14 guest-start     fail in 185095 pass in 185108
 test-armhf-armhf-xl-credit1  19 guest-start.2    fail in 185095 pass in 185108
 test-arm64-arm64-libvirt-raw 17 guest-start/debian.repeat fail in 185095 pass in 185108
 test-armhf-armhf-libvirt-qcow2 13 guest-start    fail in 185095 pass in 185108
 test-armhf-armhf-xl-credit2  18 guest-start/debian.repeat  fail pass in 185071
 test-armhf-armhf-xl-arndale   8 xen-boot                   fail pass in 185095
 test-armhf-armhf-libvirt-raw 17 guest-start/debian.repeat  fail pass in 185095

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-arndale 15 migrate-support-check fail in 185095 never pass
 test-armhf-armhf-xl-arndale 16 saverestore-support-check fail in 185095 never pass
 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop             fail like 184921
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop            fail like 184921
 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop             fail like 184921
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop            fail like 184921
 test-armhf-armhf-xl-rtds     18 guest-start/debian.repeat    fail  like 184921
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop            fail like 184921
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop            fail like 184921
 test-armhf-armhf-libvirt-raw 15 saverestore-support-check    fail  like 184921
 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop             fail like 184921
 test-armhf-armhf-libvirt     16 saverestore-support-check    fail  like 184921
 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check   fail like 184921
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop             fail like 184921
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184921
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass
 test-amd64-amd64-libvirt     15 migrate-support-check        fail   never pass
 test-amd64-i386-xl-pvshim    14 guest-start                  fail   never pass
 test-amd64-i386-libvirt      15 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          16 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-multivcpu 15 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-credit1  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-check    fail  never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass
 test-armhf-armhf-xl-rtds     15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          16 saverestore-support-check    fail   never pass
 test-amd64-i386-libvirt-raw  14 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-raw 14 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-raw 15 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-vhd      14 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-vhd      15 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-raw 14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     15 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-qcow2 14 migrate-support-check        fail never pass
 test-armhf-armhf-xl-vhd      14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      15 saverestore-support-check    fail   never pass

version targeted for testing:
 linux                84075826304f1a297838de6bcfd9bd84f566026e
baseline version:
 linux                3fec063b052e395f4920fbc59a8d0bb3c9666d76

Last test of basis   184921  2024-03-06 14:47:02 Z   14 days
Testing same since   185054  2024-03-15 19:18:15 Z    5 days    8 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Morton 
  Andy Shevchenko 
  Andy Shevchenko 
  Ansuel Smith 
  Arnd Bergmann 
  Bjorn Andersson 
  Bjorn Andersson 
  Chandan Kumar Rout  (A Contingent Worker at Intel)
  Cosmin Tanislav 
  David S. Miller 
  Dexuan Cui 
  Dmitry Torokhov 
  Dylan Hatch 
  Edward Adam Davis 
  Eric Dumazet 
  Florian Fainelli 
  Florian Westphal 
  Greg Kroah-Hartman 
  Haiyang Zhang 
  Harshit Mogalapalli 
  Hugo Villeneuve 
  Jakub Kicinski 
  Jan Kundrát 
  Jason Xing 
  Johan Hovold 
  Johannes Berg 
  John Efstathiades 
  Juhee Kang 
  Lena Wang 
  Lina Iyer 
  Linux Kernel Functional Testing 
  Maciej Fijalkowski 
  Magnus Karlsson 
  Marek Vasut 
  Mark Brown 
  Nico Pache 
  Oleg Nesterov 
  Oleksij Rempel 
  Pablo Neira Ayuso 
  Paolo Abeni 
  Rand Deeb 
  Richard Weinberger 
  Sasha Levin 
  Shachar Raindel 
  Shradha Gupta 
  Stephen Hemminger 
  Tony Nguyen 
  Werner Sembach 

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  fail    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-i386-examine-bios                                 pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  fail    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-armhf-armhf-libvirt-qcow2                               pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-armhf-armhf-libvirt-raw                                 fail    
 test-amd64-i386-libvirt-raw                                  pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     fail    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-i386-examine-uefi                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-arm64-arm64-xl-vhd                                      pass    
 test-armhf-armhf-xl-vhd                                      pass    
 test-amd64-i386-xl-vhd                                       pass    


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

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

Explanation of these 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 :

hint: The 'hooks/update' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
hint: The 'hooks/post-receive' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
hint: The 'hooks/post-update' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
To xenbits.xen.org:/home/xen/git/linux-pvops.git
   3fec063b052e..84075826304f  84075826304f1a297838de6bcfd9bd84f566026e -> tested/linux-5.4


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 03:57:42 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 03:57:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696186.1086887 (Exim 4.92)
	(envelope-from )
	id 1rn9YV-0003vG-Vx; Thu, 21 Mar 2024 03:57:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696186.1086887; Thu, 21 Mar 2024 03:57:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rn9YV-0003v9-Rj; Thu, 21 Mar 2024 03:57:27 +0000
Received: by outflank-mailman (input) for mailman id 696186;
 Thu, 21 Mar 2024 03:57:26 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rn9YU-0003v3-Fo
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 03:57:26 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on20601.outbound.protection.outlook.com
 [2a01:111:f403:2412::601])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1e37527d-e737-11ee-afe0-a90da7624cb6;
 Thu, 21 Mar 2024 04:57:22 +0100 (CET)
Received: from SJ0PR03CA0352.namprd03.prod.outlook.com (2603:10b6:a03:39c::27)
 by CY8PR12MB7147.namprd12.prod.outlook.com (2603:10b6:930:5d::19)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.27; Thu, 21 Mar
 2024 03:57:18 +0000
Received: from SJ5PEPF000001CF.namprd05.prod.outlook.com
 (2603:10b6:a03:39c:cafe::7c) by SJ0PR03CA0352.outlook.office365.com
 (2603:10b6:a03:39c::27) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.28 via Frontend
 Transport; Thu, 21 Mar 2024 03:57:18 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 SJ5PEPF000001CF.mail.protection.outlook.com (10.167.242.43) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Thu, 21 Mar 2024 03:57:17 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Wed, 20 Mar
 2024 22:57:15 -0500
Received: from henry-MS-7D54.amd.com (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Wed, 20 Mar 2024 22:57:13 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1e37527d-e737-11ee-afe0-a90da7624cb6
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=f19+KbauiRVrpvQQMFPvEDWCJo6yynx6E2amGzvcSwpP4Y0c0ez/tYeOUZMvIghYM8bUUq8Ln2nFGPU4u05a+TJ2RLifdhnFCF15QbZ8ZPJcZ436cJkDDDENazicED2buu/fm4rYrXH0DEPZLtI3NupmjvCceYBQzzShxH1aYoOWo4AqJCAKNNWgB/IcIOnYDO2WUK8EKNaXwwJb0eFFR/32z9j671t25FFf29ZbsySa2yZEnhnGxWmOctEGU/0yozerjSBeqL4EerMz0UFYAcnu16FMx9NFf2dJ1yH/kpUTT3dBBLRWJB63TnLsUfiHUL2D7UO4zkcPNWxCFwS/cg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=t8hfISM2XkM3r0lcEr4nkF80dF0hOzqCEh+8aGyArzc=;
 b=j+luvLJGN13XfrE94y4un7LdmcGINw1wjCnka/ZmsLJxFaOzNPKHxeUVlkvT4pwDi/PY7xVFxUbT9yl9o2s01FpXKgk6hVZ1u/AGXXjIziRqfI6bxqn9/zO4xNgBlifL/wCzvcLynZfg3sSMJkkw5kgIjMnYgbkB9uJHtsqUlRD5J4GB/l70cNhbzdLQGuiLtk7Tr3WgxAiH0wQ+FwIZdGrcqJtqRJ029s/lEWigykEC0M3Pk8p8kwCajZ8bWuzYrqTlmgXIlbe4rMsMQGcyDZJc7lf94tpzISPA6jkVBX7tuoLjusdTdAET38h7lqdPQlaAP432GrBhOD4nDrGOjQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=t8hfISM2XkM3r0lcEr4nkF80dF0hOzqCEh+8aGyArzc=;
 b=SxLPGRPnVOxu09w5PymSraZpCFQ74MrcmcyHHKKfL8zHuixTJsCSI4YwE20Wu6wQQGZ7ooscxkpvKgfXYbUvQAqOHCg7HMEw28t29Lv+KVeSAXFDIMbziJeVP5iCaYPmPP9KM4ScRVIKkwH2Ox5C7alGYy2jUaQMgZbZY9IdwuY=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
From: Henry Wang 
To: 
CC: Henry Wang , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Volodymyr
 Babchuk" , Henry Wang 
Subject: [PATCH v3] xen/arm: Set correct per-cpu cpu_core_mask
Date: Thu, 21 Mar 2024 11:57:06 +0800
Message-ID: <20240321035706.165253-1-xin.wang2@amd.com>
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB03.amd.com: xin.wang2@amd.com does not designate
 permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ5PEPF000001CF:EE_|CY8PR12MB7147:EE_
X-MS-Office365-Filtering-Correlation-Id: e7e88845-359b-4406-fe50-08dc495b0095
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	soWUyJKT8cmj8zW135jvEDfOJ6Kp0fCNrV1Zlr+EHtNAuV3dTkUo9NFzkc4YLOuhsoXZlEYf4FHkTgbBE0vCbN7Wp6cvB2AiFgLDqf2q7agpLRW3c+D+bUXH1vaNoIw+Nk1ZpOy6hVFZW4YC2FiZLqN75U80O68zKvHjjFg+UxmRfGRRUbu81oHZZnruTqAlw2/dCthCniK9z2XA+eUlaUtwanbbSMJEyQHOTxUlvrf7hRPvPVzYKF0r6l5RNjBNkEi2ELCf1vH2FJqKUe4RUii+QQPVsw3D0VsHsJQtUZKypCS3xTmWM1X42TFup20rc3pBxU7iKwSqJ3KwUKeQGkhz9MjMQ2zZW2dCzRPspQVvzdVj8O4TL8wJScRSScaBv73c1ITfVLFifpbPRumTlDNnOU+OJhj1gwImj4ZZ6KwxKC7jMEZVTt9/xvv/UlHBQweLWpEaLSz09QHKXH04LGmGWJnHxkQbe0S5l0YRkYxMQPuAfd/vEDBRQqQGlCs8bZuzbEsOWH8PwxiEvEc8K0LQW/+/GI60G5IMGEq/kpiGtqUXBl7sEP1D/aE4ZKV+XnLMrkPHUDr9PzlDI9aHNV5B6jsy+bL+w9u25afEQuH6eUuN5V9PSfezC8NjmatUOJyqdfskxOfIM4ANTtFOJmc0/o/5gfeEdmNxg0xZqwlt34We7w9PKPmts4oJHoweb0nA75iUJhLt56tan/D1zWGDEL04X8fJfLKvOATnu9tF/3qeseyCfPEBzs56IwME
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(82310400014)(36860700004)(1800799015)(376005);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Mar 2024 03:57:17.9199
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: e7e88845-359b-4406-fe50-08dc495b0095
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ5PEPF000001CF.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB7147

In the common sysctl command XEN_SYSCTL_physinfo, the value of
cores_per_socket is calculated based on the cpu_core_mask of CPU0.
Currently on Arm this is a fixed value 1 (can be checked via xl info),
which is not correct. This is because during the Arm CPU online
process at boot time, setup_cpu_sibling_map() only sets the per-cpu
cpu_core_mask for itself.

cores_per_socket refers to the number of cores that belong to the same
socket (NUMA node). Currently Xen on Arm does not support physical
CPU hotplug and NUMA, also we assume there is no multithread. Therefore
cores_per_socket means all possible CPUs detected from the device
tree. Setting the per-cpu cpu_core_mask in setup_cpu_sibling_map()
accordingly. Modify the in-code comment which seems to be outdated. Add
a warning to users if Xen is running on processors with multithread
support.

Signed-off-by: Henry Wang 
Signed-off-by: Henry Wang 
---
v3:
- Use cpumask_copy() to set cpu_core_mask and drop the unnecessary
  cpumask_set_cpu(cpu, per_cpu(cpu_core_mask, cpu)).
- In-code comment adjustments.
- Add a warning for multithread.
v2:
- Do not do the multithread check.
---
 xen/arch/arm/smpboot.c | 18 +++++++++++++++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index a84e706d77..b6268be27a 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -66,7 +66,11 @@ static bool cpu_is_dead;
 
 /* ID of the PCPU we're running on */
 DEFINE_PER_CPU(unsigned int, cpu_id);
-/* XXX these seem awfully x86ish... */
+/*
+ * Although multithread is part of the Arm spec, there are not many
+ * processors support multithread and current Xen on Arm assumes there
+ * is no multithread.
+ */
 /* representing HT siblings of each logical CPU */
 DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_sibling_mask);
 /* representing HT and core siblings of each logical CPU */
@@ -85,9 +89,13 @@ static int setup_cpu_sibling_map(int cpu)
          !zalloc_cpumask_var(&per_cpu(cpu_core_mask, cpu)) )
         return -ENOMEM;
 
-    /* A CPU is a sibling with itself and is always on its own core. */
+    /*
+     * Currently we assume there is no multithread and NUMA, so
+     * a CPU is a sibling with itself, and the all possible CPUs
+     * are supposed to belong to the same socket (NUMA node).
+     */
     cpumask_set_cpu(cpu, per_cpu(cpu_sibling_mask, cpu));
-    cpumask_set_cpu(cpu, per_cpu(cpu_core_mask, cpu));
+    cpumask_copy(per_cpu(cpu_core_mask, cpu), &cpu_possible_map);
 
     return 0;
 }
@@ -277,6 +285,10 @@ void __init smp_init_cpus(void)
         warning_add("WARNING: HMP COMPUTING HAS BEEN ENABLED.\n"
                     "It has implications on the security and stability of the system,\n"
                     "unless the cpu affinity of all domains is specified.\n");
+
+    if ( system_cpuinfo.mpidr.mt == 1 )
+        warning_add("WARNING: MULTITHREADING HAS BEEN DETECTED ON THE PROCESSOR.\n"
+                    "It might impact the security of the system.\n");
 }
 
 unsigned int __init smp_get_max_cpus(void)
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Thu Mar 21 07:37:29 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 07:37:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696209.1086901 (Exim 4.92)
	(envelope-from )
	id 1rnCzC-0002lR-V6; Thu, 21 Mar 2024 07:37:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696209.1086901; Thu, 21 Mar 2024 07:37:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnCzC-0002lK-PV; Thu, 21 Mar 2024 07:37:14 +0000
Received: by outflank-mailman (input) for mailman id 696209;
 Thu, 21 Mar 2024 07:37:13 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnCzB-0002lA-LB; Thu, 21 Mar 2024 07:37:13 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnCzB-00035B-8H; Thu, 21 Mar 2024 07:37:13 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnCzA-0003sQ-UG; Thu, 21 Mar 2024 07:37:13 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rnCzA-00052U-Th; Thu, 21 Mar 2024 07:37:12 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=i2Kqk+ha0amFwx+gryFJFQ93H81mUAeaamNreYe5R6s=; b=Mj1/6G2VnK9Jhtx4DSYNh+U7cd
	6Q4jtdXMwqCcUSlV+2JCdRzdwFaFGzGmTZJevJnUw27e5c+g1E3ZErD6zFm17IpgQEAsvom3nRtcr
	W80bumuIqHNPQ2fHdbaVRlbcuetormyZfTLn+9UCTX61NpUAUxeAZMPQ1egCi+vlpEtM=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 185114: tolerable FAIL - PUSHED
X-Osstest-Failures:
    linux-linus:test-armhf-armhf-xl-arndale:xen-boot:fail:heisenbug
    linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    linux=a4145ce1e7bc247fd6f2846e8699473448717b37
X-Osstest-Versions-That:
    linux=78c3925c048c752334873f56c3a3d1c9d53e0416
From: osstest service owner 
Date: Thu, 21 Mar 2024 07:37:12 +0000

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-arndale   8 xen-boot            fail pass in 185118-retest

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-arndale 15 migrate-support-check fail in 185118 never pass
 test-armhf-armhf-xl-arndale 16 saverestore-support-check fail in 185118 never pass
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop            fail like 185101
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop            fail like 185101
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop            fail like 185101
 test-armhf-armhf-libvirt     16 saverestore-support-check    fail  like 185101
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop            fail like 185101
 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check   fail like 185101
 test-armhf-armhf-libvirt-raw 15 saverestore-support-check    fail  like 185101
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 185101
 test-amd64-amd64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 15 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit1  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          16 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qcow2 14 migrate-support-check        fail never pass
 test-amd64-amd64-libvirt-raw 14 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-raw 14 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-raw 15 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt     15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-vhd      14 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-vhd      15 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass
 test-armhf-armhf-xl-credit2  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     16 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     15 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-qcow2 14 migrate-support-check        fail never pass
 test-armhf-armhf-libvirt-raw 14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      15 saverestore-support-check    fail   never pass

version targeted for testing:
 linux                a4145ce1e7bc247fd6f2846e8699473448717b37
baseline version:
 linux                78c3925c048c752334873f56c3a3d1c9d53e0416

Last test of basis   185101  2024-03-19 22:19:19 Z    1 days
Testing same since   185114  2024-03-20 14:09:37 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Kent Overstreet 
  Linus Torvalds 

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-freebsd11-amd64                             pass    
 test-amd64-amd64-freebsd12-amd64                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-armhf-armhf-xl-arndale                                  fail    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-libvirt-qcow2                               pass    
 test-armhf-armhf-libvirt-qcow2                               pass    
 test-amd64-amd64-libvirt-raw                                 pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-amd64-xl-vhd                                      pass    
 test-arm64-arm64-xl-vhd                                      pass    
 test-armhf-armhf-xl-vhd                                      pass    


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

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

Explanation of these 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 :

hint: The 'hooks/update' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
hint: The 'hooks/post-receive' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
hint: The 'hooks/post-update' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
To xenbits.xen.org:/home/xen/git/linux-pvops.git
   78c3925c048c..a4145ce1e7bc  a4145ce1e7bc247fd6f2846e8699473448717b37 -> tested/linux-linus


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 07:42:14 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 07:42:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696213.1086910 (Exim 4.92)
	(envelope-from )
	id 1rnD40-0004Ne-Ed; Thu, 21 Mar 2024 07:42:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696213.1086910; Thu, 21 Mar 2024 07:42:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnD40-0004NX-Bg; Thu, 21 Mar 2024 07:42:12 +0000
Received: by outflank-mailman (input) for mailman id 696213;
 Thu, 21 Mar 2024 07:42:11 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnD3z-0004NR-1u
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 07:42:11 +0000
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com
 [2a00:1450:4864:20::532])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 85dc81ed-e756-11ee-afe0-a90da7624cb6;
 Thu, 21 Mar 2024 08:42:10 +0100 (CET)
Received: by mail-ed1-x532.google.com with SMTP id
 4fb4d7f45d1cf-56bcede226eso139785a12.1
 for ; Thu, 21 Mar 2024 00:42:09 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ht17-20020a170907609100b00a461b1e814asm8100759ejc.130.2024.03.21.00.42.08
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 21 Mar 2024 00:42:08 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 85dc81ed-e756-11ee-afe0-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711006929; x=1711611729; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=wcKuzrxoHdnias99bLqWOpEMPtTA0R5+Juke4jB9svk=;
        b=ca53vl93Dc9Z+63ZR2nzNEnR3n1omrrAePAXtPv2jrVNa6RO+N7bs+RstWstMpzP5x
         5eUmUBk4+c2W70MjDbrZ1hgDB3/u9rRYIdWK5hgrF2BXdWCYQ0G5QuZKjkS252yeovK0
         9TxqQoFr1EVi3nshbXxAFo1ERuOXe10ePxzNyjCJvQdH+CAZH0Y/KkYuEfffAdd7Wfl1
         iVMuIEG3TKuHGpOQ1NtZnoDi9tlRiAXbrP76XkknojWoh/IDDvIcv0XHcUTCahKZUAK4
         YNVCXy524YNVomRxNTdxm3dabFGqeP22+s3maD7BognNVoUk9MBjBmlnL32bMIAb4hxd
         iP4g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711006929; x=1711611729;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=wcKuzrxoHdnias99bLqWOpEMPtTA0R5+Juke4jB9svk=;
        b=tToElFTyXK/jrLq9zz41xp0UK0rzWXtYw+V6HG3kyvNSIuiPDBw1mkvnKpWGEoBrXu
         FIrJCGpFC34EHNQSBAR/MiIP9rDM+bFxf309PmAJ7eBGvEGYsqHXvc1wVKbABqyqlfEC
         EBqG3z4OpXp0Xc8kVG4/uSpjXjjlzYPaRvU+szOYHohgOV0T8Hxm12oMurpOK7y7NwBm
         B+5DGX24qmPD46gdcobS4h7mmJJfY7begUqRFQ2K9sKQ069Fyka+3JMVhj9pm9Efk7jc
         loDNSza64bzYYp7Fk7ZuVEdbsdxNhGN5QVW3fJtCJLJ6XGJx1sGueLxxIvyRkcvVUSB/
         G2mQ==
X-Forwarded-Encrypted: i=1; AJvYcCXqfPvnrwXg0kYUvtl3q3t+DJz11QYFbkx5wqHMTJ0ji4Je4BNUQLicpwtDVA8kY5DPorqCZ8fIBAAThfDPKAjyt3lxnN7/dEeNWUFIyFM=
X-Gm-Message-State: AOJu0YxeUtj6wjMM/vbsw78p0GmjMu6a9h9g8kk6Ap5ZhosPa9Wxi1Q0
	4c5g0McMG4amuU0YX2VD0PF8+cuc/xAvI1IDV+im/TFk56onafR1pGxrGxOwcw==
X-Google-Smtp-Source: AGHT+IHlR0WzSjB8MsDETDN+9F6oXFfwD8Lag54vS6TclocPxK79uO2FGYTyvxc8jZlaY/rDuU4yfg==
X-Received: by 2002:a17:907:6d1a:b0:a46:9ae2:1927 with SMTP id sa26-20020a1709076d1a00b00a469ae21927mr3243996ejc.67.1711006928969;
        Thu, 21 Mar 2024 00:42:08 -0700 (PDT)
Message-ID: <98996023-f47c-45fd-b804-77440f333fc6@suse.com>
Date: Thu, 21 Mar 2024 08:42:07 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 5/9] xen/device-tree: Move Arm's setup.c bootinfo
 functions to common
Content-Language: en-US
To: Shawn Anastasio 
Cc: tpearson@raptorengineering.com, Andrew Cooper
 , George Dunlap ,
 Julien Grall , Stefano Stabellini ,
 Wei Liu , Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 "Daniel P. Smith" ,
 xen-devel@lists.xenproject.org
References: 
 <039524d4157dddb2faf6887739a727f6e993b53f.1710443965.git.sanastasio@raptorengineering.com>
 <152e76ee-6e75-4881-aa88-313f0ae058be@suse.com>
 <8adb6bf8-9804-4313-b1e1-5cf96d643d5e@raptorengineering.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <8adb6bf8-9804-4313-b1e1-5cf96d643d5e@raptorengineering.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 20.03.2024 19:07, Shawn Anastasio wrote:
> On 3/15/24 4:16 AM, Jan Beulich wrote:
>> On 14.03.2024 23:15, Shawn Anastasio wrote:
>>> Arm's setup.c contains a collection of functions for parsing memory map
>>> and other boot information from a device tree. Since these routines are
>>> generally useful on any architecture that supports device tree booting,
>>> move them into xen/common/device-tree.
>>>
>>> Suggested-by: Julien Grall 
>>> Signed-off-by: Shawn Anastasio 
>>> ---
>>>  MAINTAINERS                       |   1 +
>>>  xen/arch/arm/setup.c              | 419 --------------------------
>>>  xen/common/Makefile               |   1 +
>>>  xen/common/device-tree/Makefile   |   1 +
>>>  xen/common/device-tree/bootinfo.c | 469 ++++++++++++++++++++++++++++++
>>>  5 files changed, 472 insertions(+), 419 deletions(-)
>>>  create mode 100644 xen/common/device-tree/Makefile
>>>  create mode 100644 xen/common/device-tree/bootinfo.c
>>>
>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>> index 56a6932037..e85fbe6737 100644
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -301,6 +301,7 @@ M:	Stefano Stabellini 
>>>  M:	Julien Grall 
>>>  S:	Supported
>>>  F:	xen/common/libfdt/
>>> +F:	xen/common/device-tree/setup.c
>>
>> Perhaps more generally
>>
>> F:	xen/common/device-tree/
>>
>> ?
>>
> 
> This was done to allow bootfdt.c (next patch) to remain under ARM's
> maintainership, which I believe was your suggestion in v2.
> 
> Perhaps it would make sense to leave both setup.c and bootfdt.c under
> ARM's maintainership, or would it be acceptable to move both to device
> tree?

What exactly is wanted needs to be sorted by the maintainers (Arm / DT).
To me, having everything DT under DT maintainership (which is a subset
of Arm maintainers anyway) would make most sense.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 07:42:47 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 07:42:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696216.1086920 (Exim 4.92)
	(envelope-from )
	id 1rnD4W-0004tl-QD; Thu, 21 Mar 2024 07:42:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696216.1086920; Thu, 21 Mar 2024 07:42:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnD4W-0004te-Mj; Thu, 21 Mar 2024 07:42:44 +0000
Received: by outflank-mailman (input) for mailman id 696216;
 Thu, 21 Mar 2024 07:42:43 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rnD4V-0004tW-Po
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 07:42:43 +0000
Received: from EUR01-HE1-obe.outbound.protection.outlook.com
 (mail-he1eur01on2054.outbound.protection.outlook.com [40.107.13.54])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 98e25d89-e756-11ee-a1ee-f123f15fe8a2;
 Thu, 21 Mar 2024 08:42:41 +0100 (CET)
Received: from DUZPR01CA0075.eurprd01.prod.exchangelabs.com
 (2603:10a6:10:3c2::7) by PAVPR08MB9650.eurprd08.prod.outlook.com
 (2603:10a6:102:31a::21) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.31; Thu, 21 Mar
 2024 07:42:07 +0000
Received: from DB1PEPF00039233.eurprd03.prod.outlook.com
 (2603:10a6:10:3c2:cafe::ee) by DUZPR01CA0075.outlook.office365.com
 (2603:10a6:10:3c2::7) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.36 via Frontend
 Transport; Thu, 21 Mar 2024 07:42:07 +0000
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by
 DB1PEPF00039233.mail.protection.outlook.com (10.167.8.106) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.7386.12 via Frontend Transport; Thu, 21 Mar 2024 07:42:06 +0000
Received: ("Tessian outbound ff4e98f65004:v300");
 Thu, 21 Mar 2024 07:42:06 +0000
Received: from 37657267ce1b.1
 by 64aa7808-outbound-1.mta.getcheckrecipient.com id
 7F9D0B0B-FAFE-4165-B8AF-CF129322B3A4.1; 
 Thu, 21 Mar 2024 07:42:00 +0000
Received: from EUR01-DB5-obe.outbound.protection.outlook.com
 by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 37657267ce1b.1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384);
 Thu, 21 Mar 2024 07:42:00 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com (2603:10a6:10:25a::24)
 by AS2PR08MB8310.eurprd08.prod.outlook.com (2603:10a6:20b:555::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.26; Thu, 21 Mar
 2024 07:41:57 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::7fb0:6621:56b:22d5]) by DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::7fb0:6621:56b:22d5%3]) with mapi id 15.20.7386.025; Thu, 21 Mar 2024
 07:41:57 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 98e25d89-e756-11ee-a1ee-f123f15fe8a2
ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass;
 b=inlfm12s9c5/+JuxtDprhFlfEZ+gQ1LhE5NJHRwq44FBViLh/b6yBJODTbaXn5XV1VVaKRDGkX02jEThnMFI9tfA2rL7ximWFuUj10LKsLx5E3XNpTx9c4w/xKFNeOJsspw9rC6hABrdtChl30/pgFv6YQ5jrR1Gd7e9v0m4jQPTmf4zDTf/ManZEofCsomG5W0BtbBJIF0mZVWLoPSn3HFKa7w6QnYHT7CDWcBHuXiX/edmC2jfnU+yONRWkd6AboGYRIyoJJ27rIHgWXWR5+u8CKlN0UynTu2FwnRxhDf/rd4WmG2GaL/HFC8Y8KwKFmAE0LBnFigqZncEX5+7mQ==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=+gMWqMyEG57HtI+Nne8AiZgBeldtDAfIj+AIysJCgmw=;
 b=mFcKrfiH6ooB//+JoK0ATjhOTR/Kp+RSkja6JgMqvT+TQ2NB9wKAffnDmKSGoL6PEkqEKD/IN/iNuozCtVfCWm8hLlA08kocvkx2MY/05ztLsFp7yAtXuNZEoOOucTdgD1DInpTpIb4kWg4AG5TB6zR2wWWlpMRoaVI0HlK5ZeAY7RTdlS+0vnCuhYfGbF7K6mb4L//8eag1BjATLcGfj0eYUNBTlbb8PJqXF8y7ip5Hn0HPxECsejo4wn61n98RsXgHCRknM4RnyHuXxwqmK99M6Z+LtwyaJPTZsVchKgN7qICLZw3WAdmfWxHvjNSyFMsqbuDYokgCWASE+JmUPA==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 63.35.35.123) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=arm.com;
 dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com;
 dkim=pass (signature was verified) header.d=armh.onmicrosoft.com; arc=pass (0
 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com]
 dmarc=[1,1,header.from=arm.com])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com;
 s=selector2-armh-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=+gMWqMyEG57HtI+Nne8AiZgBeldtDAfIj+AIysJCgmw=;
 b=553VnNlehY8bcvsIdisfi3guvkdXNFQOusnmkzoP9fDee/oo2kjX8XeRaPQDCNBOsdZW8Rxxspy3MQwSZtnIXRL6TBxyWRE91eMLy4A+1Z4SmCWVQsnn55cxFRabT3ek8drF+FYTORxg7L0x2dPDXlTgC3qZrKPWRywBzEtw2R8=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=armh.onmicrosoft.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 63.35.35.123 as permitted sender) receiver=protection.outlook.com;
 client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
 pr=C
X-CheckRecipientChecked: true
X-CR-MTA-CID: d0d2b899f0900ac2
X-CR-MTA-TID: 64aa7808
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=EnnGPfVZ3Wy5xfWW5sEZ4XmzlFxoZBSs8iW6lXJABIJH7dNvZej9J/ebdjbTtqRfWQ5qXHPy5Fx9de0HFE/ydR2jGyr0fxD5+zVnGT3OC8IXpP0ShSq6z81fIut4yPAj74YdlQiS3v0Emk7psd39sQ91YrAsT8NACtGPCMZpOg3XIjoMKl57QXMmozXqh2K1egl0vWDc1KL/AAhJDZ4cIxgRTb6mq2a4Me9zisT55yusKHt4eIPCaLsa9saCXWqqLEMci/3fNdrukyX4zO81XSqRurNHWP3MOeeoctemB/Tf9SZewaCL3u8YXSFUTt3f477F67PrXn7Mdgabmx9Ujw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=+gMWqMyEG57HtI+Nne8AiZgBeldtDAfIj+AIysJCgmw=;
 b=L6jHudM5NxUULmxYlMQaNvgDOY+TpOrRuy8LG70PbsooBfYaD8OuM3gv9brT1/x4/i3KJUMrhcJsEig9MLazL7TGkY1llyPSzSoIdx4/k796e6l++va8WMPDnN+rx07wJw0WbwrTQ8+xgpJp5ewNZj+nXqKGtnj4NB+r8+o6euMSp+gM9iJ/AOY+AYN31H2nEVu5II57Mv1uaM4pDbIwH39oCrSqIPql81loOd7PeBO4GaVox0sda8ZuStZvsGgjbL0oAcV84E4AXKqHy4OG3VBU0mTEWJ8S/Rpn3+6hKB9L7zpDkRzKcOxhy/cF9wBhowlsnxHlAiy8AYBMlDtuNQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass
 header.d=arm.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com;
 s=selector2-armh-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=+gMWqMyEG57HtI+Nne8AiZgBeldtDAfIj+AIysJCgmw=;
 b=553VnNlehY8bcvsIdisfi3guvkdXNFQOusnmkzoP9fDee/oo2kjX8XeRaPQDCNBOsdZW8Rxxspy3MQwSZtnIXRL6TBxyWRE91eMLy4A+1Z4SmCWVQsnn55cxFRabT3ek8drF+FYTORxg7L0x2dPDXlTgC3qZrKPWRywBzEtw2R8=
From: Bertrand Marquis 
To: Julien Grall 
CC: John Ernberg , Peng Fan , Stefano
 Stabellini , Michal Orzel ,
	Volodymyr Babchuk , Jonas Blixt
	, "xen-devel@lists.xenproject.org"
	
Subject: Re: [PATCH 1/2] xen/arm: Add imx8q{m,x} platform glue
Thread-Topic: [PATCH 1/2] xen/arm: Add imx8q{m,x} platform glue
Thread-Index:
 AQHaVDuqVQ/kgxLZgUK/m8/hE0ez5bDz198AgAA1LICAAVx4AIAAQjaAgAEdtQCAAynKwIABnCuAgAZ8E4CAKNxCgIAApf0AgAKGQwCAAAbHgIAHmWEAgAtpgACAABVOgIAA6w+A
Date: Thu, 21 Mar 2024 07:41:57 +0000
Message-ID: <2F07325F-428F-4570-BE14-B84DD0A1C9F7@arm.com>
References: <20240131114952.305805-1-john.ernberg@actia.se>
 <20240131114952.305805-2-john.ernberg@actia.se>
 
 <494d4961-ad8a-4d1d-aaa6-d1bfb9d6a137@actia.se>
 <167f0c7a-e037-446c-82f8-2584e35a7af1@xen.org>
 
 <012b5f83-2f9b-4477-965e-07b8506c0052@xen.org>
 
 <5a0c8f09-4f01-45e9-892c-86342c0d0ec5@xen.org>
 <08ae764c-3490-4dd1-ab70-7a855a98d16d@actia.se>
 <911ec1bb-3733-4f37-839e-673a88e408ff@actia.se>
 
 <848794f3-a337-49d9-84db-a969970f071b@actia.se>
 <48038c7f-d7cd-4100-a41b-8042bcb93208@xen.org>
 <967020E7-3D03-416A-8BFC-6F4E4BD9D7B5@arm.com>
 
 <849f3f5a-b960-444a-a10e-1f2df36c22a7@xen.org>
In-Reply-To: <849f3f5a-b960-444a-a10e-1f2df36c22a7@xen.org>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3774.200.91.1.1)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DB9PR08MB6588:EE_|AS2PR08MB8310:EE_|DB1PEPF00039233:EE_|PAVPR08MB9650:EE_
X-MS-Office365-Filtering-Correlation-Id: 0913460d-b7ad-43b3-51e8-08dc497a6877
x-checkrecipientrouted: true
nodisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted: BCL:0;
X-Microsoft-Antispam-Message-Info-Original:
 bo25xEzqqfDPPvfyfz3n7RzF8S6YxdwLMvXd6Iiai3odPknmjTj8zbN1PelpjYJnPy+RJpntT0137bGJ7Mr+pvY1Bo/2LizkXu5BcTuuC7U3PwuruL41oGpNGQmKoeRTsYL5vxHhBsLb2HZaReLnBlSR2OT8k4uqhg/+fw8SizgJOT8VcGPu7afAajaWSe46eE1rVGgFD319+d4fH4a7fr7x3mrV0Ewp2nJQK18ser88ciDt2uMnf6POOybDf+ah+hFm/inwjKjrl13AtXQB1L5y5IdBy8XhPl8tTnt8HzetH9Vq4ChGIrWPUEnDu4XI2KsXxGlrEXAE3wP7pO3tY1rUKm0WoFD3fYKtHXgXVcMgIv3cVTRZzSRXH89V+kW1WpYXwC5y0GFyN0YOSLGR/X+vtBtNVewnERFQmyG3xAHNbVl0e6V69mBpFIpy2yJ77oCl9uB/u0NkAjdxYGO+EszYO9Qz2Pa18f4NFZBrikb62qhFhFj9/OY1BsInkuGKxt05NjHFHMImHPolrlIeKiMabYGRqCkHCvmWDwvGGEFjMeg+2eS3obIAnaio5BYoJfBknMZAaHcWFW7BNta5AM1g0KRvyINofS8AclYNp8xG77eI/BcXnpu698vj3KU5HIlQKjtuu9XdXOe1m+J0N/UxYlDz3cRcFqRsmSSZkd/dFi1UbOwwkcT6BhnB3WRyLjyq6R1An9ZFy37kuuXqmPfnSVmOUBeJcumdrCAb62A=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB9PR08MB6588.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(1800799015)(376005)(366007)(38070700009);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR08MB8310
Original-Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 DB1PEPF00039233.eurprd03.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	8a9f64aa-afb2-4ce5-5558-08dc497a62f7
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	iCuyNteej8bwnKdZAvjdId+WLGRHEcgeYbJIzXTaCl/GxKew+vAAy3Q1fwfcHvSEF6EujzpV6dmJeeTaqgose/p5iQ7prp2s5qHNg7EiAOsWIW5EQOHOp7GKPVB5NhTy+u4HJDBgctzv7E8SZkIaQ1bJAs80h+1tzHZAXXiyLFYKqEBeHukOgRJifgfKysFtiEIAEJpPDA5l40v1/fRhx9HtQvfpw0BwfKGcTB6GH9WWpgqixPOGJauVU0TPnFB6/YoOpWJf3Rap6QoytWSyEEKXGKYjPL5s4HJcCgjncXFA1W7zXETZjkgoHzVWvHA9340gRTbDBShPrpgFAoxW6Y9q0M5+YMuBwm5b7yex4QIkMnJpVGYUs9yxYAyQz7pMcQEQB19lM7w0xqrPM4eU7wBfRESsqDGdOtPkBzXZoGc5/rBxMMWdkw8CG+X9RY6Ax3ROrNEnHUugU6dvAOEgdQIoeAwWPSMgOfV/Le4GcDV5uzFPtKMrt9LCmGdVvGELFsscaA0P/knnLN49AfsdSA9vuDQ4WYWaTr9G70paO/dbtKB/S6Am8MMJnLglB1m1ir5MIYO8uuC2Va4SVJNScr+BANlv6VB+0Xqpu8DJfudM8vXTRxFdvGyM9nvwSzTSrEBEX39ml3DaMyI736s4Fw2Qa87JzPz0f1GPFU+iu92RT/Ar2/D4pXu5XTyZD9PXOJg/caTgUXIVNT3Fzkxs6CcW8DkEk5Ap+oKPXfeo44wx6h/kvvIr76YILUxaUHqT
X-Forefront-Antispam-Report:
	CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com;CAT:NONE;SFS:(13230031)(1800799015)(82310400014)(36860700004)(376005);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Mar 2024 07:42:06.7099
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 0913460d-b7ad-43b3-51e8-08dc497a6877
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DB1PEPF00039233.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAVPR08MB9650

Hi,

> On 20 Mar 2024, at 18:40, Julien Grall  wrote:
>=20
> Hi John,
>=20
> On 20/03/2024 16:24, John Ernberg wrote:
>> Hi Bertrand,
>> On 3/13/24 11:07, Bertrand Marquis wrote:
>>> Hi,
>>>=20
>>>> On 8 Mar 2024, at 15:04, Julien Grall  wrote:
>>>>=20
>>>> Hi John,
>>>>=20
>>>> Thank you for the reply.
>>>>=20
>>>> On 08/03/2024 13:40, John Ernberg wrote:
>>>>> On 3/7/24 00:07, Julien Grall wrote:
>>>>>>   > Ping on the watchdog discussion bits.
>>>>>>=20
>>>>>> Sorry for the late reply.
>>>>>>=20
>>>>>> On 06/03/2024 13:13, John Ernberg wrote:
>>>>>>> On 2/9/24 14:14, John Ernberg wrote:
>>>>>>>>=20
>>>>>>>>>      * IMX_SIP_TIMER_*:  This seems to be related to the watchdog=
.
>>>>>>>>> Shouldn't dom0 rely on the watchdog provided by Xen instead? So t=
hose
>>>>>>>>> call will be used by Xen.
>>>>>>>>=20
>>>>>>>> That is indeed a watchdog SIP, and also for setting the SoC intern=
al RTC
>>>>>>>> if it is being used.
>>>>>>>>=20
>>>>>>>> I looked around if there was previous discussion and only really
>>>>>>>> found [3].
>>>>>>>> Is the xen/xen/include/watchdog.h header meant to be for this kind=
 of
>>>>>>>> watchdog support or is that more for the VM watchdog? Looking at t=
he x86
>>>>>>>> ACPI NMI watchdog it seems like the former, but I have never worke=
d with
>>>>>>>> x86 nor ACPI.
>>>>>>=20
>>>>>> include/watchdog.h contains helper to configure the watchdog for Xen=
. We
>>>>>> also have per-VM watchdog and this is configured by the hypercall
>>>>>> SCHEDOP_watchdog.
>>>>>>=20
>>>>>>>>=20
>>>>>>>> Currently forwarding it to Dom0 has not caused any watchdog resets=
 with
>>>>>>>> our watchdog timeout settings, our specific Dom0 setup and VM coun=
t.
>>>>>>=20
>>>>>> IIUC, the SMC API for the watchdog would be similar to the ACPI NMI
>>>>>> watchdog. So I think it would make more sense if this is not exposed=
 to
>>>>>> dom0 (even if Xen is doing nothing with it).
>>>>>>=20
>>>>>> Can you try to hide the SMCs and check if dom0 still behave properly=
?
>>>>>>=20
>>>>>> Cheers,
>>>>>>=20
>>>>> This SMC manages a hardware watchdog, if it's not pinged within a
>>>>> specific interval the entire board resets.
>>>>=20
>>>> Do you know what's the default interval? Is it large enough so Xen + d=
om0 can boot (at least up to when the watchdog driver is initialized)?
>>>>=20
>>>>> If I block the SMCs the watchdog driver in Dom0 will fail to ping the
>>>>> watchdog, triggering a board reset because the system looks to have
>>>>> become unresponsive. The reason this patch set started is because we
>>>>> couldn't ping the watchdog when running with Xen.
>>>>> In our specific system the bootloader enables the watchdog as early a=
s
>>>>> possible so that we can get watchdog protection for as much of the bo=
ot
>>>>> as we possibly can.
>>>>> So, if we are to block the SMC from Dom0, then Xen needs to take over
>>>>> the pinging. It could be implemented similarly to the NMI watchdog,
>>>>> except that the system will reset if the ping is missed rather than
>>>>> backtrace.
>>>>> It would also mean that Xen will get a whole watchdog driver-category
>>>>> due to the watchdog being vendor and sometimes even SoC specific when=
 it
>>>>> comes to Arm.
>>>>> My understanding of the domain watchdog code is that today the domain
>>>>> needs to call SCHEDOP_watchdog at least once to start the watchdog
>>>>> timer. Since watchdog protection through the whole boot process is
>>>>> desirable we'd need some core changes, such as an option to start the
>>>>> domain watchdog on init. >
>>>>> It's quite a big change to make
>>>>=20
>>>> For clarification, above you seem to mention two changes:
>>>>=20
>>>> 1) Allow Xen to use the HW watchdog
>>>> 2) Allow the domain to use the watchdog early
>>>>=20
>>>> I am assuming by big change, you are referring to 2?
>>>>=20
>>>> , while I am not against doing it if it
>>>>> makes sense, I now wonder if Xen should manage hardware watchdogs.
>>>>> Looking at the domain watchdog code it looks like if a domain does no=
t
>>>>> get enough execution time, the watchdog will not be pinged enough and
>>>>> the guest will be reset. So either watchdog approach requires Dom0 to
>>>>> get execution time. Dom0 also needs to service all the PV backends it=
's
>>>>> responsible for. I'm not sure it's valuable to add another layer of
>>>>> watchdog for this scenario as the end result (checking that the entir=
e
>>>>> system works) is achieved without it as well.
>>>>> So, before I try to find the time to make a proposal for moving the
>>>>> hardware watchdog bit to Xen, do we really want it?
>>>>=20
>>>> Thanks for the details. Given that the watchdog is enabled by the boot=
loader, I think we want Xen to drive the watchdog for two reasons:
>>>> 1) In true dom0less environment, dom0 would not exist
>>>> 2) You are relying on Xen + Dom0 to boot (or at least enough to get th=
e watchdog working) within the watchdog interval.
>>>=20
>>> Definitely we need to consider the case where there is no Dom0.
>>>=20
>>> I think there are in fact 3 different use cases here:
>>> - watchdog fully driven in a domain (dom0 or another): would work if it=
 is expected
>>>    that Xen + Domain boot time is under the watchdog initial refresh ra=
te. I think this
>>>    could make sense on some applications where your system depends on a=
 specific
>>>    domain to be properly booted to work. This would require an initial =
refresh time
>>>    configurable in the boot loader probably.
>> This is our use-case. ^
>> Our dom0 is monitoring and managing the other domains in our system.
>> Without dom0 working the system isn't really working as a whole.
>> @Julien: Would you be ok with the patch set continuing in the direction
>> of the
>> original proposal, letting another party (or me at a later time) impleme=
nt
>> the fully driven by Xen option?
> I am concerned about this particular point from Bertrand:
>=20
> "would work if it is expected that Xen + Domain boot time is under the wa=
tchdog initial refresh rate."
>=20
> How will a user be able to figure out how to initially configure the watc=
hdog? Is this something you can easily configure in the bootloader at runti=
me?

Definitely here it would be better to have the watchdog turned off by defau=
lt and document how to enable it in the firmware.

Even if a long timeout is configured by default, a user could run into trou=
ble if using a linux without watchdog or not running linux or using dom0les=
s without a linux having access to it.
I agree with Julien here that the concern could be that users would come to=
 us instead of NXP if there is system is doing a reset without reasons afte=
r some seconds or minutes.

>=20
>=20
> Overall, I am not for this approach at least in the current status. I wou=
ld be more inclined if there are some documentations explaining how this is=
 supposed to be configured on NXP, so others can use the code.
>=20
> Anyway, this is why we have multiple Arm maintainers for this kind of sit=
uation. If they other agrees with you, then they can ack the patch and this=
 can be merged.

I agree with Stefano that it would be good to have those board supported.

One thing i could suggest until there is a watchdog driver inside Xen is to=
 have a clear Warning at Xen boot on those boards in the console so that we=
 could at least identify the reason easily if a reset occurs for someone.

Cheers
Bertrand

>=20
> Cheers,
>=20
> --=20
> Julien Grall




From xen-devel-bounces@lists.xenproject.org Thu Mar 21 07:56:01 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 07:56:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696223.1086929 (Exim 4.92)
	(envelope-from )
	id 1rnDHH-0006se-Ud; Thu, 21 Mar 2024 07:55:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696223.1086929; Thu, 21 Mar 2024 07:55:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnDHH-0006sX-S3; Thu, 21 Mar 2024 07:55:55 +0000
Received: by outflank-mailman (input) for mailman id 696223;
 Thu, 21 Mar 2024 07:55:54 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnDHG-0006sR-9I
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 07:55:54 +0000
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com
 [2a00:1450:4864:20::635])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 70421db6-e758-11ee-a1ee-f123f15fe8a2;
 Thu, 21 Mar 2024 08:55:52 +0100 (CET)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-a467d8efe78so73849766b.3
 for ; Thu, 21 Mar 2024 00:55:52 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 f23-20020a170906049700b00a3efa4e033asm8181644eja.151.2024.03.21.00.55.51
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 21 Mar 2024 00:55:51 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 70421db6-e758-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711007752; x=1711612552; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=xFsfq2XdiK5U+JJvorNeH0Tn+9BirOXb7xnhq0Zatxk=;
        b=USt0OaiyzTQ+8OhLVNx0zcRtJSMsrRY6NbvnzVKVMOK3221YJmVGuPHQsQJ2ST6Stp
         DCK1B/JCCyLqt8A2sec2w4hu3XTx2j6uAFtSuWEcY07EOZJbRygTdE2mRBMno0ROzhQU
         W8t3bqq7F2BTp5gZRdKnXhvrS3MH+QcUVHsnsBwkxbVzx6awRN+ag5ZeOpdhpkFLTUIm
         ltLfdApWiR6sPhJDJX+wf3fR/yBqyaXRXBzwVLLuiDzthd3GFjU1VaOZPOnOLuiVZ9U5
         inVWBv4SNttEfx1uteWHq3dVqKtJjumPkOrVAnk+BJ1DjkCrNZp6BKvpXcamHEqFDpX4
         BfTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711007752; x=1711612552;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=xFsfq2XdiK5U+JJvorNeH0Tn+9BirOXb7xnhq0Zatxk=;
        b=SJ1e94GkBcFndPgUeg+i62rn52lF+C7Xnt+JWUngW1yjnqRW/+Kw2nZk1rJPHuYHmz
         Dow3BdJEqv2EH0bfOwchm4pVQybDQy/1JJVlcn+2OLwE6vsDZf/eflY/XM1A9DlGVHsK
         VuQe/S7k/WgdDQOn5Rq4B9/yIPqfKvmZ3me9Ts8CgvalOcE4mCOZay8WT2ExLlyN54Fa
         VXwB/qtZ9VxRMMPvjyNd/35DkvrkmxpwOSDROLR52lDx63iy3ww8GU9plbdXO2odN9SX
         GpM7nzNcUOUtoiEpzzXd6brqVoeCAdYISkB4FmcT21n309ye1D+26EkCOaLh3Ll6/0oV
         3c8A==
X-Forwarded-Encrypted: i=1; AJvYcCU0/LNGdSt7Ee13gLY5edmrHht/VZKC/pGe+11ZfFt1+yJfFqW7y2XREOhlWt7mBDzjYY4eHk8mQCEqjJg8IHfGlre6u5pVOMe0EQX2cz4=
X-Gm-Message-State: AOJu0Yx870YIP3MusiDsyobLojMvTilsxZkhA/9XsYQ7v1Ib/g5you2C
	F8tGOai/jPFThYlrwPrQh84BQBBjJBv4Klim58md1DoVPkC0ECRRWz8r2gNkMA==
X-Google-Smtp-Source: AGHT+IG8IfST3nyvYoCRvu1RFNryBOvD6Ec4YJrORE4tPz0VspLqSPsClCE0/QoVMDG9t5ZZF20FHQ==
X-Received: by 2002:a17:906:349a:b0:a46:dd30:7cb5 with SMTP id g26-20020a170906349a00b00a46dd307cb5mr5379016ejb.76.1711007751629;
        Thu, 21 Mar 2024 00:55:51 -0700 (PDT)
Message-ID: <68a00864-3bd3-445a-aa79-eb0511b4bea9@suse.com>
Date: Thu, 21 Mar 2024 08:55:50 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/vcpu: relax VCPUOP_initialise restriction for non-PV
 vCPUs
Content-Language: en-US
To: Andrew Cooper 
Cc: George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 xen-devel@lists.xenproject.org, Roger Pau Monne 
References: <20240320135720.68894-1-roger.pau@citrix.com>
 <73314dc5-0145-4aa7-a3cd-23c943235392@suse.com>
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 20.03.2024 16:20, Andrew Cooper wrote:
> On 20/03/2024 3:09 pm, Jan Beulich wrote:
>> On 20.03.2024 14:57, Roger Pau Monne wrote:
>>> There's no reason to force HVM guests to have a valid vcpu_info area when
>>> initializing a vCPU, as the vCPU can also be brought online using the local
>>> APIC, and on that path there's no requirement for vcpu_info to be setup ahead
>>> of the bring up.  Note an HVM vCPU can operate normally without making use of
>>> vcpu_info.
>> While I'd agree if you started with "There's no real need to force ...", I
>> still think there is a reason: If one wants to use paravirt interfaces (i.e.
>> hypercalls), they would better do so consistently. After all there's also
>> no need to use VCPUOP_initialise, yet you're not disabling its use.
> 
> I firmly disagree.
> 
> There are good reasons to use VCPUOP_initialise over INIT-SIPI-SIPI
> (like avoiding 16bit mode - in the case we want it here, to fix APIC_ID
> enumeration in a way that doesn't involve putting more complexity into
> HVMLoader), and forcing us to set up a useless structure before we can
> boot vCPU number 32 is just wrong.

Just to mention it: I can certainly accept this as one possible valid
viewpoint, and my looking at it differently is not an objection to the
patch. It's just that the other aspect mentioned needs sorting (perhaps
by just extending the patch description).

> It was dumb to design a hypercall like this in the first place for PV
> guests, and it definitely isn't OK to keep guests broken because of it.

And again just to mention it: Originally, with a vCPU limit of 32, all
vCPU-s would reliably have had vcpu_info (by way of that being embedded
in shared_info). When raising the limit, the goal was to not chance
overlooking any vcpu_info access in Xen. Hence why, instead of putting
a NULL pointer there (or perhaps some non-canonical sentinel), the
dummy approach was chosen. It then seemed quite desirable to prevent
vCPU-s coming online without them first being detached from that dummy
structure. And I think this firmly needs to continue to hold for PV.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 08:07:20 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 08:07:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696231.1086940 (Exim 4.92)
	(envelope-from )
	id 1rnDSG-0000sa-BX; Thu, 21 Mar 2024 08:07:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696231.1086940; Thu, 21 Mar 2024 08:07:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnDSG-0000sT-7h; Thu, 21 Mar 2024 08:07:16 +0000
Received: by outflank-mailman (input) for mailman id 696231;
 Thu, 21 Mar 2024 08:07:15 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnDSF-0000sL-Tt
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 08:07:15 +0000
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com
 [2a00:1450:4864:20::232])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 059f1688-e75a-11ee-a1ee-f123f15fe8a2;
 Thu, 21 Mar 2024 09:07:12 +0100 (CET)
Received: by mail-lj1-x232.google.com with SMTP id
 38308e7fff4ca-2d485886545so12215821fa.2
 for ; Thu, 21 Mar 2024 01:07:12 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 e25-20020a170906845900b00a449026672esm8183817ejy.81.2024.03.21.01.07.11
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 21 Mar 2024 01:07:11 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 059f1688-e75a-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711008432; x=1711613232; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=XNUZ3U/Fwfx76i0s24VQTCYrKYugniQ3n/ljjcXCIyo=;
        b=afeT+S3jg2MBCly37k7wNx+JFJKACyD41wIREqf8fnCJ358VfnsSuOl6RjGx2Aqln+
         msDnOzJKqruc8/E0R5fpWC4g4H1v+dFNtoKwwcclu2Fa3K3yHnh4ZWX6DlbxMvjOlIH2
         jghfUtEZMT2JFPKTnQrg2iHBFr3NCMu0HvZm8EMFpIkkD4pJID/Igw9S7MOPPQ6oYYAk
         U8Ijoa/DBXFgUZiO0dfv4HmruMZexDPaVlmQatSnt55HIwsRuHk41pD3mwiLRlo200T+
         oOzthloG9nzUyjHaLCmRwHNO2Sl7b1FU2+h/mUAwgJRdCA2bx+kZq99QPk40N9RjmvwY
         unSA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711008432; x=1711613232;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=XNUZ3U/Fwfx76i0s24VQTCYrKYugniQ3n/ljjcXCIyo=;
        b=Rrxc71+SM7OjAK6L/rSPgAhqa67zx/6hHH8+eopAfsZ1Sn/0BDSryCtofn9gsPOa1w
         3Nsb0Ao+TpZCryRRII8EjsatmDRlMHFfXymc8lpzI7mCuUuheuXcgM9OA9U3hHFXMFS+
         gfEUfNtivNDChuEHZL6SvfTENAL63TTLNY5sgk4Y8EfOiFcYV2YnmxH9/QvEoy7XxJ9/
         ofByLwMwbQ9ajSzQuAC0cCYwJosqHZ7FhqDq5SC5mBClPLiOKdpmuE3fYnzJqK2Chkak
         fGe0wBEv8Wd8c4BhbXplJriecs3DoaBvhN4Uv/PDmd9KeJ71FylRrAzzwWXT7f/hGuhS
         a4cw==
X-Forwarded-Encrypted: i=1; AJvYcCUw4T6QkwrdCRreRY47HW9E9d0dRFfavc+TS1zqW85Fo0+pcmHtv/VRGHZ5lH/7DsgJ+yYgdk3E38V6lvIIhP8LhbJ8nj8wyNiQyDAmFdQ=
X-Gm-Message-State: AOJu0YzMvlSf7yK6zYbAodk660k3f0ejxjNpxgAEAXzSZmpXNNsHlg1z
	WOPwtH1jjAuvrxdYTGrcpmvAOSZHnjTEKSFfb3D44KcXGPUSFf/3NH2SdtLmDg==
X-Google-Smtp-Source: AGHT+IFYqfChU4kOXeOyQPmKTGUiAsc1t/xKcUllqM5FF3YbAID5kB84xqcZFVq5hS0OZFMoT7o/WA==
X-Received: by 2002:a2e:2e0f:0:b0:2d3:3305:c37a with SMTP id u15-20020a2e2e0f000000b002d33305c37amr1061916lju.7.1711008431743;
        Thu, 21 Mar 2024 01:07:11 -0700 (PDT)
Message-ID: <4cc5d746-a50c-4819-a56e-512abf797ef2@suse.com>
Date: Thu, 21 Mar 2024 09:07:10 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/vcpu: relax VCPUOP_initialise restriction for non-PV
 vCPUs
Content-Language: en-US
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 xen-devel@lists.xenproject.org
References: <20240320135720.68894-1-roger.pau@citrix.com>
 <73314dc5-0145-4aa7-a3cd-23c943235392@suse.com> 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 20.03.2024 17:29, Roger Pau Monné wrote:
> On Wed, Mar 20, 2024 at 04:09:33PM +0100, Jan Beulich wrote:
>> On 20.03.2024 14:57, Roger Pau Monne wrote:
>>> There's no reason to force HVM guests to have a valid vcpu_info area when
>>> initializing a vCPU, as the vCPU can also be brought online using the local
>>> APIC, and on that path there's no requirement for vcpu_info to be setup ahead
>>> of the bring up.  Note an HVM vCPU can operate normally without making use of
>>> vcpu_info.
>>
>> While I'd agree if you started with "There's no real need to force ...", I
>> still think there is a reason: If one wants to use paravirt interfaces (i.e.
>> hypercalls), they would better do so consistently. After all there's also
>> no need to use VCPUOP_initialise, yet you're not disabling its use.
>>
>> As said in reply to Andrew's reply, besides acting as a sentinel that
>> structure instance also acts as a sink for Xen accesses to a vCPU's
>> vcpu_info. By removing the check, you switch that from being a safeguard to
>> being something that actually has to be expected to be accessed. Unless
>> you've audited all uses to prove that no such access exists.
> 
> I'm kind of lost in this last paragraph, how is that different than
> what currently happens when an HVM vCPU >= 32 is brought up using the
> lapic and has no vpcu_info mapped?

I think this aspect was simply missed back at the time. And I think it
wants mentioning explicitly to justify the change.

As said in reply to Andrew, I don't think the dummy structure can be got
rid of. Nor can the checks here be (easily) removed altogether, i.e. your
change cannot (easily) be extended to PV as well. Even conditional removal
of the structure in !PV builds would first require all vcpu_info accesses
to gain a suitable conditional. Which may be undesirable, as some of these
may be deemed fast paths.

> Also, from a quick look it seems like sites do check whether vcpu_info
> == dummy_vcpu_info, otherwise we would already be in trouble.

Such checks exist in code managing vcpu_info, but not - afaics - in places
actually accessing it.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 08:09:39 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 08:09:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696236.1086950 (Exim 4.92)
	(envelope-from )
	id 1rnDUX-0001pX-QE; Thu, 21 Mar 2024 08:09:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696236.1086950; Thu, 21 Mar 2024 08:09:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnDUX-0001pQ-NY; Thu, 21 Mar 2024 08:09:37 +0000
Received: by outflank-mailman (input) for mailman id 696236;
 Thu, 21 Mar 2024 08:09:36 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnDUW-0001pI-7l
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 08:09:36 +0000
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com
 [2a00:1450:4864:20::635])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5a2063bb-e75a-11ee-a1ee-f123f15fe8a2;
 Thu, 21 Mar 2024 09:09:34 +0100 (CET)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-a4675aaa2e8so87330166b.0
 for ; Thu, 21 Mar 2024 01:09:34 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 x10-20020a1709060eea00b00a46d786365esm3143356eji.94.2024.03.21.01.09.33
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 21 Mar 2024 01:09:33 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5a2063bb-e75a-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711008573; x=1711613373; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=dnEU5bnbob7D1jOsrxnf1DoG8D9eQYmIIlXmEYTuG4E=;
        b=IgVtwCpqsCTR8ecdhZPnqyLiVvu7hGNafpG05JwvBmdSuXSSoIqZ/xmNqULtcMq7E/
         x9jV2Vw/13rEUsQNif0iopyJx8BmJzab4GFEtNQrAFF3KgslkXaa1tvVB29bfBm8/W1u
         nHfqa3jyk72wfaIAcGyFaZqbJO7tCI3Lvoi1fOwG6MH3FHh+JBFvz9zlozPPmv3NYIdW
         /Ev9fZv7iBZ39QybDPZxTtoeU/jwEN8hDFd+btbeixsnAr5N511swjQuobcQd/438G/O
         fbz3AHku7ME667uUOjYcN5GUT2qjvT9Sq2U5GOV2rYTnljeaMSND1daIay2/mKSzvrUf
         joMw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711008573; x=1711613373;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=dnEU5bnbob7D1jOsrxnf1DoG8D9eQYmIIlXmEYTuG4E=;
        b=SOGpE3T9sBtJ3heLqMNGh0JOqg2YLdmFQrZMLC9+4X1pwnuVEiOLIgmWRO833fQyCt
         AkMsXUaEVgskfprfTet8qP6WhXVcDkiwtmtruA58rA7onpsKVa3TxfmnCdpRKZ2dQGqt
         DqoAgVQU/J6cT0MlBctDfWyM+pfOPVItQBcL0BF/UCgiiAtsaO573XoHwvjzrH2uHQiB
         CKMHEKC/l3mZ4an6CUpWu9aqU3W3Q0QqTBLp4IXn7cqufiijwNUtHmmrsW5UWK0q4oxv
         Q8y0rNohXNVhBk3Sd6m/l3PLS6AnuSZtRi+kfnTXgzi6RhfVpsSmNjGwbLyfWqmV1sHn
         b//w==
X-Forwarded-Encrypted: i=1; AJvYcCXnJ2IM79w1DUDJX9el9Yw1cX2Sz+H0bBFz57hZXlDp3YgYMJ0my/n+Sn8kLwcuq34IwQjEyJnK5Qb5a+1mGjMe9gvIcVuWcNyUNsaZFW0=
X-Gm-Message-State: AOJu0YyJNQgUHJBFngSYIoHPKmIzmYFqp6LuhWuQAShurkqjH9i9Z4Ra
	Pd3fAh6l5m7rlRCMv6vyjzdFM9BGvj9MdqCbJJRHi4hpom5FMBHLQnDyhPklKQ==
X-Google-Smtp-Source: AGHT+IHrwG2y+1MErksYWgPeDSd56uAnfznUyDt7bWONAVan4dlhsy7njChSCPCl6TiN3ULKjKc0Rw==
X-Received: by 2002:a17:907:7d8e:b0:a46:ba8e:c22b with SMTP id oz14-20020a1709077d8e00b00a46ba8ec22bmr894977ejc.77.1711008573620;
        Thu, 21 Mar 2024 01:09:33 -0700 (PDT)
Message-ID: 
Date: Thu, 21 Mar 2024 09:09:32 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 1/2] automation/eclair: add deviation for MISRA C:2012
 Rule 17.1
Content-Language: en-US
To: Stefano Stabellini 
Cc: Simone Ballarin , consulting@bugseng.com,
 Doug Goldstein , Andrew Cooper
 , George Dunlap ,
 Julien Grall , Wei Liu ,
 xen-devel@lists.xenproject.org
References: 
 <882b442c8c1f73f8116676ab9351defe5c9609ac.1710923235.git.simone.ballarin@bugseng.com>
 <9341a711-74c3-463f-8cc2-a54e19b4b2f4@suse.com>
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 21.03.2024 02:50, Stefano Stabellini wrote:
> On Wed, 20 Mar 2024, Jan Beulich wrote:
>> On 20.03.2024 09:50, Simone Ballarin wrote:
>>> MISRA C:2012 Rule 17.1 states:
>>> The features of `' shall not be used
>>>
>>> The Xen community wants to avoid using variadic functions except for
>>> specific circumstances where it feels appropriate by strict code review.
>>>
>>> Add deviation for functions related to console output (printk and similar).
>>>
>>> Signed-off-by: Simone Ballarin 
>>> ---
>>>  .../eclair_analysis/ECLAIR/deviations.ecl     | 26 +++++++++++++++++++
>>>  docs/misra/deviations.rst                     |  5 ++++
>>>  2 files changed, 31 insertions(+)
>>>
>>> diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
>>> index 9ac3ee4dfd..7c3559a3a0 100644
>>> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
>>> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
>>> @@ -382,6 +382,32 @@ explicit comment indicating the fallthrough intention is present."
>>>  -config=MC3R1.R16.6,switch_clauses+={deliberate, "default(0)"}
>>>  -doc_end
>>>  
>>> +#
>>> +# Series 17.
>>> +#
>>> +
>>> +-doc_begin="Functions related to console output are allowed to use the variadic features provided by stdarg.h."
>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(debugtrace_printk)&&kind(function))))"}
>>
>> This isn't concole output related.
> 
> Should we say "related to console output or tracing" ?
> 
> 
>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(dt_dprintk)&&kind(function))))"}
>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(printk)&&kind(function))))"}
>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(guest_printk)&&kind(function))))"}
>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(panic)&&kind(function))))"}
>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(dprintk)&&kind(function))))"}
>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(gdprintk)&&kind(function))))"}
>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(snprintf)&&kind(function))))"}
>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(scnprintf)&&kind(function))))"}
>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(xasprintf)&&kind(function))))"}
>>
>> These three and ...
>>
>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(mm_printk)&&kind(function))))"}
>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(dbgp_printk)&&kind(function))))"}
>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(elf_call_log_callback)&&kind(function))))"}
>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(vsnprintf)&&kind(function))))"}
>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(vscnprintf)&&kind(function))))"}
>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(xvasprintf)&&kind(function))))"}
>>
>> ... these three aren't either.
> 
> Maybe it is better to write it as:
> 
> "Functions related printk, logging and tracing are allowed..."

How about simply saying "printf()-like functions"? In what you suggest,
sprintf() and friends would still not be covered.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 08:27:37 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 08:27:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696241.1086959 (Exim 4.92)
	(envelope-from )
	id 1rnDls-0004nL-7t; Thu, 21 Mar 2024 08:27:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696241.1086959; Thu, 21 Mar 2024 08:27:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnDls-0004nE-5B; Thu, 21 Mar 2024 08:27:32 +0000
Received: by outflank-mailman (input) for mailman id 696241;
 Thu, 21 Mar 2024 08:27:30 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnDlq-0004n8-Gk
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 08:27:30 +0000
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com
 [2a00:1450:4864:20::535])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id dacfcccb-e75c-11ee-afe0-a90da7624cb6;
 Thu, 21 Mar 2024 09:27:29 +0100 (CET)
Received: by mail-ed1-x535.google.com with SMTP id
 4fb4d7f45d1cf-5684db9147dso627696a12.2
 for ; Thu, 21 Mar 2024 01:27:29 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 pv27-20020a170907209b00b00a46647b6496sm8190088ejb.155.2024.03.21.01.27.27
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 21 Mar 2024 01:27:28 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: dacfcccb-e75c-11ee-afe0-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711009648; x=1711614448; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=yONgQlY29QaCZwciLdVKvhAm4X16I+Qq4iFHdblrY80=;
        b=Pwo94cWKeRY45y02mfBGFRbR6EB6aChfMjA0QuqOvUju6TpLpY1b2WrJ7espXm2iWg
         dI3WeqG1Hg5CdFLM+oWYJjiY3vRFuVS9eUj/XL+TNxExE8BbcfiYoTjCz31YsRH1rzFk
         xg/u22FruG04Iee17GbmHjrcgpr6q34IovqJQGBmbqXC4tlJqSc1VoxUU9gSVRqh5QZ/
         +GevXeouKSvNS5sugB+MKqn4DNEpHoO5aaS6TNgzYS1dlnKl/O5BfjbNbwbTfuCiWt0V
         NH9wTbxIM4QYSIuJOZtaK9fxc0tiz0oPVMon8s9KGl+HCxcwUtlI2/23wlvbsTlX/LPN
         tXjQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711009648; x=1711614448;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=yONgQlY29QaCZwciLdVKvhAm4X16I+Qq4iFHdblrY80=;
        b=ZbotpeM7xow+iT0K8O1WV0AQc+FsJjYsoMYFTNi5l7pjYvxIhBHqvmDZI833ekixfm
         ePUQI2a8q8YAYfJeNT767ghbJBgoR2s9sxz5R9qLaBCHELskslw/nM8kBRWg7Z2tS9LG
         Lh6oGL4bayDnZorVBqmyuUqUcM4M5Kzi6rxi/I1HSoqFwgfOHGS2wYPRJZBRDE06aRgg
         xxBn/PlYV8igAn9Rv6euoCEjLDAAz0OGYFtCZxvhtpgI+FDIr7jZBN6Oww3h4qwDX13k
         nNmjt/1g6MFHyagJ/vZJakXllrlqp5WCTRRANtZSPgVq/HzaRxYAHWac9b2i3w4Jsx4M
         NZfg==
X-Forwarded-Encrypted: i=1; AJvYcCV/OAKAEzhBF1SCV7pSI9SsD0spYIUrSobksbXOWLkF6JtyeCXTpYZnQZ0AfJSRBunz0bcNTWVPzIua3MXJriz+PQiy9WcgBKjtzKv+06c=
X-Gm-Message-State: AOJu0Yw2++Gcc3vaAbzdYH2FWjvCw/Aa08Ev2jXiYtGCEyxZ/Qt7FBhN
	gPn7sv0Am4+gXt9pl4C4VsWy8Y90wSwOFkfJQg+WsPuHk0xUkFZIrirKiKqMag==
X-Google-Smtp-Source: AGHT+IG3Avg0rzZ7esdT/n3cKxPKAr2f9cHH68qKCLyiJpNdezFRjV7uJEpuhKhbxfShRJ9I0/4DqQ==
X-Received: by 2002:a17:907:7e94:b0:a46:ad7c:ccc7 with SMTP id qb20-20020a1709077e9400b00a46ad7cccc7mr10734178ejc.59.1711009648501;
        Thu, 21 Mar 2024 01:27:28 -0700 (PDT)
Message-ID: <198bade8-c6fc-4ae0-b721-3a9e2bd8acbe@suse.com>
Date: Thu, 21 Mar 2024 09:27:26 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] docs/misra: document the expected sizes of integer
 types
Content-Language: en-US
To: Stefano Stabellini 
Cc: andrew.cooper3@citrix.com, bertrand.marquis@arm.com,
 george.dunlap@citrix.com, julien@xen.org, michal.orzel@amd.com,
 roger.pau@citrix.com, xen-devel@lists.xenproject.org
References: 
 <6a76723e-ba47-40b3-8f33-d68030b14299@suse.com>
 
 <7ab73379-b057-4568-9869-141cef185752@suse.com>
 
 
 
 <87234837-9fb3-40a9-849d-8b8574f2661c@suse.com>
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 21.03.2024 02:46, Stefano Stabellini wrote:
> On Wed, 20 Mar 2024, Jan Beulich wrote:
>>> - the public interface is described in a C header so it makes sense for
>>>   the corresponding implementation to be in C
>>>
>>> - the C entry point is often both the entry point in C and also common
>>>   code
>>>
>>> - depending on the architecture, there is typically always some minimal
>>>   assembly entry code to prepare the environment before we can jump into
>>>   C-land; still one wouldn't consider those minimal and routine assembly
>>>   operations to be a meaningful hypercall entry point corresponding to
>>>   the C declaration in the public headers
>>>
>>> - as per MISRA and also general good practice, we need the declaration
>>>   in the public header files to match the definition in C
>>
>> Throughout, but especially with this last point, I feel there's confusion
>> (not sure on which side): There are no declarations of hypercall functions
>> in the public headers. Adding declarations there for the C entry points in
>> Xen would actually be wrong, as we don't provide such functions anywhere
>> (to consumers of the ABI).
> 
> I am copy/pasting text from sched.h:
> 
>  * The prototype for this hypercall is:
>  * ` long HYPERVISOR_sched_op(enum sched_op cmd, void *arg, ...)
>  *
>  * @cmd == SCHEDOP_??? (scheduler operation).
>  * @arg == Operation-specific extra argument(s), as described below.
>  * ...  == Additional Operation-specific extra arguments, described below.
>  *
> 
> from event_channel.h:
> 
>  * ` enum neg_errnoval
>  * ` HYPERVISOR_event_channel_op(enum event_channel_op cmd, void *args)
>  * `
>  * @cmd  == EVTCHNOP_* (event-channel operation).
>  * @args == struct evtchn_* Operation-specific extra arguments (NULL if none).
> 
> These are the hypercall declarations in public headers. Although they
> are comments, they are the only description of the ABI that we have (as
> far as I know). They are in C and use C types. 

>From their use of enum alone they don't qualify as declarations. They're
imo merely meant to provide minimal guidelines.

>>>>>>> We have two options:
>>>>>>>
>>>>>>> 1) we go with this document, and we clarify that even if we specify
>>>>>>>   "unsigned int", we actually mean a 32-bit integer
>>>>>>>
>>>>>>> 2) we change all our public ABIs and C hypercall entry points to use
>>>>>>>    fixed-size types (e.g. s/unsigned int/uint32_t/g)
>>>>>>>
>>>>>>> 2) is preferred because it is clearer but it is more work. So I went
>>>>>>> with 1). I also thought you would like 1) more.
>>>>>>
>>>>>> For ABIs (i.e. structures) we ought to be making that change anyway.
>>>>>> Leaving basic types in there is latently buggy.
>>>>>
>>>>> I am glad we agree :-)
>>>>>
>>>>> It is just that I also consinder the C hypercall entry points as part of
>>>>> the ABI
>>>>>
>>>>>
>>>>>> I'm happy to see a document like this added, for the purpose described
>>>>>> above. But to me 1) and 2) and largely independent of one another.
>>>>>
>>>>> Good that you are also happy with a document like this.
>>>>>
>>>>> The remaining question is: what about the rest of the C functions in Xen
>>>>> that are certainly not part of an ABI?
>>>>
>>>> As per above - anything internal isn't part of the ABI, C entry points
>>>> for hypercall handlers included. All we need to ensure is that we consume
>>>> the data according to what the ABI sets forth.
>>>
>>> It doesn't look like we'll convince one another on this point. But let
>>> me try another way.
>>>
>>> In my view, having mismatched types between declaration and definition
>>> and having non-fixed-width types in C hypercall entry points is really
>>> bad for a number of reasons, among them:
>>> - correctness
>>> - risk of ABI breakage
>>> - mismatch of declaration and definition
>>
>> What mismatches are you talking about? There's nothing mismatched now,
>> and there cannot be any mismatch, because the consumers of the ABI don't
>> call Xen functions directly.
> 
> Let me make an example:
> 
> - public header saying enum event_channel_op cmd
> - 
> - do_event_channel_op(int cmd, ...)
> 
> Do you think this is all good?
> 
> There are two pretty serious problems here:
> - enum and int are not the same type

See above. The issue I have with this is use of plain "int". Technically
that's not a problem either, but aiui we're aiming to use "unsigned int"
when negative values aren't possible.

And note that it was in 2012 when "int" there was changed to "enum", in an
effort to document things better.

> - enum and int are not fixed-width

Which I don't view as a problem, thanks to the assembly sitting in between.

> Don't you think it should be:
> 
> - public header saying uint32_t cmd in a comment
> - 
> - do_something_op(uint32_t cmd, ...)

The public header should say whatever is best suited to not misguide
people writing actual prototypes for their functions. I wouldn't mind
uint32_t being stated there. That has no influence whatsoever on
do__op(), though.

> Or possibly unsigned long depending on the parameter.

You're contradicting yourself: You mean to advocate for fixed-width types,
yet then you suggest "unsigned long". Perhaps because you realized that
there's no single fixed-width type fitting "unsigned long" for all
architectures. xen_ulong_t would likely come closest, but would - aiui -
still not be suitable for Arm32 when used in hypercall (handler)
prototypes; it's suitable for use (again) only in structure definitions.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 08:32:06 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 08:32:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696244.1086969 (Exim 4.92)
	(envelope-from )
	id 1rnDqG-0006kP-Ny; Thu, 21 Mar 2024 08:32:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696244.1086969; Thu, 21 Mar 2024 08:32:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnDqG-0006kI-LV; Thu, 21 Mar 2024 08:32:04 +0000
Received: by outflank-mailman (input) for mailman id 696244;
 Thu, 21 Mar 2024 08:32:03 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnDqF-0006k5-A6
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 08:32:03 +0000
Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com
 [2a00:1450:4864:20::12d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7d503815-e75d-11ee-a1ee-f123f15fe8a2;
 Thu, 21 Mar 2024 09:32:01 +0100 (CET)
Received: by mail-lf1-x12d.google.com with SMTP id
 2adb3069b0e04-513dd2d2415so738387e87.3
 for ; Thu, 21 Mar 2024 01:32:01 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 f6-20020a056402160600b005687f8721f9sm7718261edv.82.2024.03.21.01.32.00
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 21 Mar 2024 01:32:00 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7d503815-e75d-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711009921; x=1711614721; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=dm/4gsDR6jnwFhv6hnpaTx+UB+WvX38AWU60Azayg8A=;
        b=R2PhT2w4G+2X5MOo2Fuy4wzERaSLD58rhu/O8OYQF0VMtQZ6MAzgIVARYFoX/tljOx
         ePWdwwpd9YvO7loiMWwTU+tWE5TtObiR9s5JejgpWPAG2SNFP9YGkXp7r0LX9vYeRNva
         YbIkRXBkm3rBx9JZjGbbKteOVFTzOKiNy3YMDYI4CEOruYtTXK7fBk45w511uLry6e36
         CKeV7igtXt0wffTeVe5Adm9uvi35M/v/KN7xTNApQgLcNU75A4DCqYYDENmJY/u1NK8u
         E+dytXBQ4qZbSRJeCN3pFZcB9EkFwIPqlfY6Ecv5OzdDCy4s3LftIkRm9bX5GhkQ7jmU
         jGMg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711009921; x=1711614721;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=dm/4gsDR6jnwFhv6hnpaTx+UB+WvX38AWU60Azayg8A=;
        b=TLzBmEsZroL6ewkEphCNHD0TqZ+VONJZEp8P0iB0YWXgVB8q3mm1vnNmkSs4OMV8CM
         SqB/VkCxHcGTNCa6um7PQCjg51Q3ekK3rIU5zjWmgu0WKDzKZrR29/I8l7ersGHbUcEQ
         ro178rX2T1TxJ9r1/JsoFFqVzvehToLmXYHeygAyzZ0mgz3zpOoDkh50PAEHxy3+j7zg
         e+oJhsbQXnnLNSuBeDKqDqkNV1nuQLHg0qOuVVbS9pOtfcVObpEtgK9QtTcL8xJ0Ek2g
         NQqGJTaow4Y9hB0Y/MTKRkADi5fBFfaOIv5mwe0jEqHxyMNmTlM95YLKS2udXR+dmFJS
         6/gw==
X-Forwarded-Encrypted: i=1; AJvYcCXL1565eIQmw7fbKC0rR9VeyGzfjPEeRMZ9clN5V5r2vAtt8zKDim/fFNpx31hMYsU8qOsp5kcV4iTjxEqPGIBd4Ab76q6g9nImQZYaB30=
X-Gm-Message-State: AOJu0Yxr6JvTHRCAca01vKcO6GQs1YY9D+SlSf5aoatiV3GvsQK1bjs5
	w4ZSBF15I/Yim0NhS35TV1uaWagl/1wUefWruR0Aqdm8Kc0xb5SVCikEpzq7Ug==
X-Google-Smtp-Source: AGHT+IES2jxCIPi0mo6NnH0XUvuUbvhItRpYtsmv1l4y53vPZTV7UFbs5sFL+BUnUr9w5H4uPCLnyw==
X-Received: by 2002:ac2:4e8d:0:b0:513:5af1:33c1 with SMTP id o13-20020ac24e8d000000b005135af133c1mr881930lfr.6.1711009921063;
        Thu, 21 Mar 2024 01:32:01 -0700 (PDT)
Message-ID: 
Date: Thu, 21 Mar 2024 09:31:59 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 03/20] xen/riscv: introduce extenstion support check by
 compiler
Content-Language: en-US
To: Conor Dooley 
Cc: Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 Alistair Francis ,
 Bob Eshleman , Connor Davis
 , xen-devel@lists.xenproject.org,
 Oleksii 
References: 
 
 <6ddc9d8a-20e7-4e4d-ae1a-d2ea01479b38@suse.com>
 <04c1424cec1342dcfb849d361f5eb9f3e7f34734.camel@gmail.com>
 <20240320-oak-uprising-db787f501695@spud>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240320-oak-uprising-db787f501695@spud>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 20.03.2024 20:44, Conor Dooley wrote:
> On Wed, Mar 20, 2024 at 07:58:05PM +0100, Oleksii wrote:
>> On Mon, 2024-03-18 at 17:58 +0100, Jan Beulich wrote:
>>> On 15.03.2024 19:05, Oleksii Kurochko wrote:
>>>> Currently, RISC-V requires two extensions: _zbb and _zihintpause.
>>>
>>> Do we really require Zbb already?
>> After an introduction of Andrew C. patches [1] it is requited for
>> __builtin_ffs{l}
>>
>> [1]
>> https://lore.kernel.org/xen-devel/20240313172716.2325427-1-andrew.cooper3@citrix.com/T/#t
>>>
>>>> This patch introduces a compiler check to check if these extensions
>>>> are supported.
>>>> Additionally, it introduces the riscv/booting.txt file, which
>>>> contains
>>>> information about the extensions that should be supported by the
>>>> platform.
>>>>
>>>> In the future, a feature will be introduced to check whether an
>>>> extension
>>>> is supported at runtime.
>>>> However, this feature requires functionality for parsing device
>>>> tree
>>>> source (DTS), which is not yet available.
>>>
>>> Can't you query the CPU for its features?
>> I couldn't find such reg ( or SBI call ) in the spec.
> 
> There isn't.
> 
>> SBI call sbi_probe_extension() exists, but it doesn't check for every
>> possible extension. As far as I understand it checks only for that one
>> which are present in SBI spec.
> 
> Yeah, it only checks for SBI extensions, not ISA extensions.

And there was never a consideration to add, at the architecture level,
some straightforward way for all layers of software to be able to
easily detect availability of extensions? I find the lack thereof
pretty surprising ...

Jan


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 08:47:34 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 08:47:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696248.1086980 (Exim 4.92)
	(envelope-from )
	id 1rnE51-0000W4-25; Thu, 21 Mar 2024 08:47:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696248.1086980; Thu, 21 Mar 2024 08:47:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnE50-0000Vx-UX; Thu, 21 Mar 2024 08:47:18 +0000
Received: by outflank-mailman (input) for mailman id 696248;
 Thu, 21 Mar 2024 08:47:16 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rnE4y-0000Vr-Ra
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 08:47:16 +0000
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com
 [2a00:1450:4864:20::431])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9d558028-e75f-11ee-a1ee-f123f15fe8a2;
 Thu, 21 Mar 2024 09:47:14 +0100 (CET)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-33ddd1624beso421732f8f.1
 for ; Thu, 21 Mar 2024 01:47:14 -0700 (PDT)
Received: from localhost ([85.31.135.62]) by smtp.gmail.com with ESMTPSA id
 f6-20020a5d50c6000000b0033e891d97d6sm16586668wrt.107.2024.03.21.01.47.13
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 21 Mar 2024 01:47:13 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9d558028-e75f-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1711010834; x=1711615634; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=uMIPc+f6qWf6tFxu6Y08l44Ec9duM17QHH0kOb8tPo0=;
        b=jbWFo3dy+IlthVOomKuB+kz3zS9B1TrZ1ApRqq3+pqOb6ejV6ysywUjKqgevu5MkkU
         xnCAhxbahE/q/4YS0srPCU7qUrGiC1VY+eUe0c+R25QifiHbn5HcmwhBBHZ/rtmf/VJy
         FKSBUOfBZ+qg83WwKjndVjndbCv2Da5gs7XSQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711010834; x=1711615634;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=uMIPc+f6qWf6tFxu6Y08l44Ec9duM17QHH0kOb8tPo0=;
        b=s/7Y8RKfmozjVX3UafF0GiJGNOS5kTKqR590ASt7rl33P2ggRnzx/xy840yRLyhDST
         fTn/lbj2DruZMTd32VAXWgIfJlx5UkDgfYPNYQwiiLUf6uuWq1UJVwacrSoj32mmOVIK
         Hvj+eYsggIKi2MIDypBnEael9Eh+HUPvd/Pc+464xDEnqtQDH9T7cchmj2XYXVlrLYm5
         m640bcdLmXis+mbmsoEhIU6GaApngjsDCMh+DINmOm1H9cKxGOAmKw1Yrx2qqG3hD6LG
         rrYaUekYHH1b62oA0To1acKr43LVSLABfp6aV15ChqngW4KN6cU4kcFB8gQl3vKb9xCY
         B6XQ==
X-Gm-Message-State: AOJu0YzW9VokHROD2y22ZWGu+itubNqDKlNMtvm+5G4PQ+bkXSxq0Vfa
	56TR9cYubm7YXr9Umx5LS2/GrfGoVWPVlWWQiHUhalCiZDjbkE4WPI5JnFkMflA=
X-Google-Smtp-Source: AGHT+IEiWVGkCHwvR1kIM8qdaevEWdpAhdoYWkhx1355sDghoPJ/lZjjseztygtXpX5AZ7/rhAQ15w==
X-Received: by 2002:a05:6000:e4d:b0:33e:ce08:79b5 with SMTP id dy13-20020a0560000e4d00b0033ece0879b5mr1646686wrb.9.1711010833659;
        Thu, 21 Mar 2024 01:47:13 -0700 (PDT)
Date: Thu, 21 Mar 2024 09:47:12 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: "xen-devel@lists.xenproject.org" ,
	Andrew Cooper ,
	Nicola Vetrini 
Subject: Re: [PATCH] AMD/IOMMU: drop remaining guest-IOMMU bits too
Message-ID: 
References: <5eb98372-2992-4a93-846c-4e325c41af98@suse.com>
 
 
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Wed, Mar 20, 2024 at 03:51:55PM +0100, Jan Beulich wrote:
> On 20.03.2024 15:06, Roger Pau Monné wrote:
> > On Wed, Mar 20, 2024 at 11:58:50AM +0100, Jan Beulich wrote:
> >> On 20.03.2024 11:46, Roger Pau Monné wrote:
> >>> On Tue, Mar 19, 2024 at 02:28:12PM +0100, Jan Beulich wrote:
> >>>> With a02174c6c885 ("amd/iommu: clean up unused guest iommu related
> >>>> functions") having removed the sole place where d->g_iommu would be set
> >>>> to non-NULL, guest_iommu_add_ppr_log() will unconditionally bail the
> >>>> latest from its 2nd if(). With it dropped, all other stuff in the file
> >>>> is unused, too. Delete iommu_guest.c altogether.
> >>>>
> >>>> Further delete struct guest{_buffer,_dev_table,_iommu{,_msi}} as well as
> >>>> struct mmio_reg for being unused with the unused g_iommu also dropped
> >>>> from struct arch_iommu.
> >>>>
> >>>> Signed-off-by: Jan Beulich 
> > 
> > Acked-by: Roger Pau Monné 
> 
> Thanks.
> 
> >>>> ---
> >>>> I wasn't sure how far to further go with removing the body of
> >>>> parse_ppr_log_entry(), or perhaps even the entire function, and then
> >>>> further up to all PPR logging code. Hence why for now I've merely
> >>>> commented out the function call into the file being deleted (which of
> >>>> course Misra isn't going to like). Thoughts / suggestions?
> >>>>
> >>>> I further wonder whether set_iommu_guest_translation_control() should
> >>>> have been invoked independent of guest-IOMMU actually being enabled. IOW
> >>>> that may want purging, too. Along these lines iommuv2_enabled may also
> >>>> want dropping, for not having any consumer left. Much like has_viommu()
> >>>> and then also {XEN_,}X86_EMU_IOMMU, i.e. going as far as affecting the
> >>>> public interface.
> > 
> > I would drop it all.  The public interface part is not stable anyway,
> > as it's a domctl, but I would be fine if you want to keep the X86_EMU_IOMMU.
> 
> By "all" you also mean the PPR logging code? That's where I felt I might
> be going too far ...

It's up to you.  I've taken a look, and the PPR logging code seems to
be tied to guest IOMMU also?

Since PPR could be used for other purposes it's likely fine to leave
it in, albeit I won't oppose if you want to remove it (maybe there's
some purpose I'm missing).

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 09:02:49 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 09:02:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696259.1087014 (Exim 4.92)
	(envelope-from )
	id 1rnEJu-0004Qk-Jw; Thu, 21 Mar 2024 09:02:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696259.1087014; Thu, 21 Mar 2024 09:02:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnEJu-0004Qd-FW; Thu, 21 Mar 2024 09:02:42 +0000
Received: by outflank-mailman (input) for mailman id 696259;
 Thu, 21 Mar 2024 09:02:41 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rnEJt-0004QW-5w
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 09:02:41 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on20601.outbound.protection.outlook.com
 [2a01:111:f403:2412::601])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c38795bd-e761-11ee-a1ee-f123f15fe8a2;
 Thu, 21 Mar 2024 10:02:38 +0100 (CET)
Received: from BYAPR07CA0054.namprd07.prod.outlook.com (2603:10b6:a03:60::31)
 by DM4PR12MB6664.namprd12.prod.outlook.com (2603:10b6:8:bb::18) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.27; Thu, 21 Mar
 2024 09:02:35 +0000
Received: from MWH0EPF000A6730.namprd04.prod.outlook.com
 (2603:10b6:a03:60:cafe::24) by BYAPR07CA0054.outlook.office365.com
 (2603:10b6:a03:60::31) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.27 via Frontend
 Transport; Thu, 21 Mar 2024 09:02:34 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 MWH0EPF000A6730.mail.protection.outlook.com (10.167.249.22) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Thu, 21 Mar 2024 09:02:34 +0000
Received: from SATLEXMB06.amd.com (10.181.40.147) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 21 Mar
 2024 04:02:32 -0500
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB06.amd.com
 (10.181.40.147) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 21 Mar
 2024 04:02:32 -0500
Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Thu, 21 Mar 2024 04:02:31 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c38795bd-e761-11ee-a1ee-f123f15fe8a2
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=D96gxX9HCXLRXxAh4xnlSEY8JcIdwzmHbl4QITlWHM1jTdwFkHFBweFvt+cqKyWEYa9bOiBgcwxvt1we115KlKL39Agoe/j4NCNJ46DnnLJokDEPAn4Qg22ZnWd8wBLibd/NIV71QjYPa6Vl9fisRw9/w3pl/1nsmTPWXbC/nF77zOFKkbW2Hxreu4cR0GpjxyLYrqe1AnyNeIBTpk1mqAe9kYADQKHMsftafCmHKUJFeldmz2bvjVTpvhUN/JCicQKCm64yWBfjRlIrx/9aX6favxvR7c+2vxOMd7wfil2bnvkCZ+XoXx2bFvE8Dihn1FA3G7azrbb4Q4Ly5gU7fw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=aYrAFQWW78PjnbM8VlrzHlBGUVcsNSReRu4Aft2X2aY=;
 b=iFyXPAai/6ZVWlfuAxtNgSh36x21KtMMFE3YHVBXKS7OVNO9papMazfr9tV+LuFBiysIN1tNAnP3U69nZi1K9HEBmNq5z+CT4Liz/hS2NxvuBZj+nBSbB9xo9v8P+if0lPM6VrX2OT5+HbzQ/Dd6i0CNVX5DhNzw+syu6dBKkDRSmIgmNdHDOM3qtG1bp12R6Vw6IQAWlHGx3uSAKhMsr4r8aiAPTMHHbLytWSH2wWg5JxOQMcR3gOGoTsFQK7EyyqeYeizNHPbtCoWYNYGXo6qpogHHL2877Gw/YHccR45SRFMcurXPTlL4n7nVMQdIrjxJWzwzjquHLvGbaWkrcA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=arm.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=aYrAFQWW78PjnbM8VlrzHlBGUVcsNSReRu4Aft2X2aY=;
 b=nhG3KtPbsERaRtt9j+tS80s4rfsCwtDj/8FoM8xucekdXlm3iEYFIQSJouKghb0/95b9fRN8bepj13OhXu3W3jSH4lUM6l7S9HCqazOfDNCqc2Q+zXMsWyPfj3LK4UXahQiypExQhJ0z+iC3+3RcaqP6ctN2xI6Wfo6EHjxrPw8=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
Message-ID: 
Date: Thu, 21 Mar 2024 10:02:30 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 06/11] xen/arm: Avoid code duplication in
 find_unallocated_memory
Content-Language: en-US
To: Luca Fancellu 
CC: Xen-devel , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Volodymyr Babchuk 
References: <20240312130331.78418-1-luca.fancellu@arm.com>
 <20240312130331.78418-7-luca.fancellu@arm.com>
 <3bd5d32c-d2e6-4e53-8b3e-aa7fdd058c71@amd.com>
 <280936E1-27DC-41FA-8E3B-080CA562A7B8@arm.com>
From: Michal Orzel 
In-Reply-To: <280936E1-27DC-41FA-8E3B-080CA562A7B8@arm.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: MWH0EPF000A6730:EE_|DM4PR12MB6664:EE_
X-MS-Office365-Filtering-Correlation-Id: fb9b496e-ce1a-4328-21db-08dc4985a625
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	iFw6r9FopXOwbe+5EGX0YoCV1iUCIcTE5rzcIOMw/XJb0n1LtQAhao/GeQUVSB1XPHB7QthN5ngeiOfzgdbUefBLvIbksLCjfQwZP/tD6ZAklV8NsOh51L/s3I6V6QFOWHBVeQyib33KISK50NTUhjCLM3oxGSUJWY0VZ9NusV3m3beufHBQ9nNYZH3cQ5mmZjPzekOb0U6AKf4Qs+Hf4DN2RMlalvoQ7JA9x23Crr7feEwI3v6vuky0CHgO65U6QKNFbmrAkM28YbDsS6eC9XcZ+YfTyMgMjhfwPJEqlleBQOvjk60Brny5kafytFUlhK8FeXjuuW37IHwKbljoioWVRLNtWHmggT24dBBWp35Br4RZMSn0EAQENcGW57DOp6zvu7qaUTzEpZz4vIPgt757XkjSWKk0nXJiNPeG1kFKGpVSK0hciuO61m0pxZPFZueUeJSYgw57o2QKIW0uu7dm1EOTY1RJloPyNI2hDsshcldSJH7AZdTNtkRGruuTt9bEbhiXd+vuyLH0viFkyjmSZx+6rttcQL1jAg8TvnOc3zkjVBZkFRo4qiio2PbYMFQVvHIk+Ud3le+YPrrYStNLaVOrKXoItbAg3juUtrEw7nEaI6+u0RmNWAI9mCq2p+gKJytSpWWJi9MHdWREnlmqbjLeG7lpheQOzxW4VMoW7G3ihsEeBoeEYGy4qCGcuzr8wLBIRQkhF5k62ARIMndMztvdJ1cQZFKV8CQG8/l0g1V3IhDzf6RmToZvMBaB
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(36860700004)(376005)(1800799015)(82310400014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Mar 2024 09:02:34.5290
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: fb9b496e-ce1a-4328-21db-08dc4985a625
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	MWH0EPF000A6730.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB6664

Hi Luca,

On 20/03/2024 15:53, Luca Fancellu wrote:
> 
> 
>> On 20 Mar 2024, at 10:57, Michal Orzel  wrote:
>>
>> Hi Luca,
>>
>> On 12/03/2024 14:03, Luca Fancellu wrote:
>>>
>>>
>>> The function find_unallocated_memory is using the same code to
>>> loop through 3 structure of the same type, in order to avoid
>>> code duplication, rework the code to have only one loop that
>>> goes through all the structures.
>>>
>>> Signed-off-by: Luca Fancellu 
>>> ---
>>> xen/arch/arm/domain_build.c | 62 ++++++++++---------------------------
>>> 1 file changed, 17 insertions(+), 45 deletions(-)
>>>
>>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>>> index b254f252e7cb..d0f2ac6060eb 100644
>>> --- a/xen/arch/arm/domain_build.c
>>> +++ b/xen/arch/arm/domain_build.c
>>> @@ -869,12 +869,14 @@ static int __init add_ext_regions(unsigned long s_gfn, unsigned long e_gfn,
>>> static int __init find_unallocated_memory(const struct kernel_info *kinfo,
>>>                                           struct membanks *ext_regions)
>>> {
>>> -    const struct membanks *kinfo_mem = kernel_info_get_mem(kinfo);
>>> -    const struct membanks *mem = bootinfo_get_mem();
>>> -    const struct membanks *reserved_mem = bootinfo_get_reserved_mem();
>>> +    const struct membanks *mem_banks[] = {
>>> +        bootinfo_get_mem(),
>>> +        kernel_info_get_mem(kinfo),
>>> +        bootinfo_get_reserved_mem(),
>>> +    };
>>>     struct rangeset *unalloc_mem;
>>>     paddr_t start, end;
>>> -    unsigned int i;
>>> +    unsigned int i, j;
>>>     int res;
>>>
>>>     dt_dprintk("Find unallocated memory for extended regions\n");
>>> @@ -883,50 +885,20 @@ static int __init find_unallocated_memory(const struct kernel_info *kinfo,
>>>     if ( !unalloc_mem )
>>>         return -ENOMEM;
>>>
>>> -    /* Start with all available RAM */
>>> -    for ( i = 0; i < mem->nr_banks; i++ )
>>> -    {
>>> -        start = mem->bank[i].start;
>>> -        end = mem->bank[i].start + mem->bank[i].size;
>>> -        res = rangeset_add_range(unalloc_mem, PFN_DOWN(start),
>>> -                                 PFN_DOWN(end - 1));
>>> -        if ( res )
>>> -        {
>>> -            printk(XENLOG_ERR "Failed to add: %#"PRIpaddr"->%#"PRIpaddr"\n",
>>> -                   start, end);
>>> -            goto out;
>>> -        }
>>> -    }
>>> -
>>> -    /* Remove RAM assigned to Dom0 */
>>> -    for ( i = 0; i < kinfo_mem->nr_banks; i++ )
>>> -    {
>>> -        start = kinfo_mem->bank[i].start;
>>> -        end = kinfo_mem->bank[i].start + kinfo_mem->bank[i].size;
>>> -        res = rangeset_remove_range(unalloc_mem, PFN_DOWN(start),
>>> -                                    PFN_DOWN(end - 1));
>>> -        if ( res )
>>> +    for ( i = 0; i < ARRAY_SIZE(mem_banks); i++ )
>>> +        for ( j = 0; j < mem_banks[i]->nr_banks; j++ )
>> It might be a matter of personal opinion, but I would actually prefer the current code
>> that looks simpler/neater (the steps are clear) to me. I'd like to know other maintainers opinion.
> 
> Ok, I’ll wait the other maintainers then, I’m going to use this construct in other part
> of the code to simplify and remove duplication so it would be important to know if
> It’s desirable or not.
> 
> Maybe your opinion could change with a proper comment on top of the structure and the loop,
> listing the operation performed in order?
> 
> 1) Start with all available RAM
> 2) Remove RAM assigned to Dom0
> 3) Remove reserved mem
> 
> 4) Remove static shared memory regions
Yes, that would help with the overall readability.

~Michal


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 09:07:39 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 09:07:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696261.1087024 (Exim 4.92)
	(envelope-from )
	id 1rnEOg-00051F-44; Thu, 21 Mar 2024 09:07:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696261.1087024; Thu, 21 Mar 2024 09:07:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnEOg-000517-1G; Thu, 21 Mar 2024 09:07:38 +0000
Received: by outflank-mailman (input) for mailman id 696261;
 Thu, 21 Mar 2024 09:07:36 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rnEOe-00050u-Bh
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 09:07:36 +0000
Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com
 [2a00:1450:4864:20::636])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 73eda7fa-e762-11ee-a1ee-f123f15fe8a2;
 Thu, 21 Mar 2024 10:07:33 +0100 (CET)
Received: by mail-ej1-x636.google.com with SMTP id
 a640c23a62f3a-a46ba938de0so98033366b.3
 for ; Thu, 21 Mar 2024 02:07:33 -0700 (PDT)
Received: from [192.168.206.239] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 di9-20020a170906730900b00a462e166b9bsm8168704ejc.112.2024.03.21.02.07.31
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 21 Mar 2024 02:07:32 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 73eda7fa-e762-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1711012053; x=1711616853; darn=lists.xenproject.org;
        h=mime-version:user-agent:content-transfer-encoding:references
         :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject
         :date:message-id:reply-to;
        bh=eq9syIN272CbfFhniy4a+7MTtRGsuH0LlUnyFxg3v8M=;
        b=Fpc9vDtFn6+MDr/nAoBrKLTKHlPDhcqq467EejDpCUSWReZsXPbJrLgNmwzx7ZUqe2
         0lcPDDeOzPs4FllfVXh1A4qj4fP44ZK0UcO2WTuEN+gaC8r5Yb3+cVTFGarjwiaPHvI9
         1gTUS3kvV3A+qzMDtrbwJgtB8ZCPK0u1yGQoJLV1SwoLwq9Q9pBj31MLqPj8Iej6Ixx/
         4BzAwDDaJ5QP7lWVoVZJymY/pTN0/spHcA6L4r80s/K5HgsSVJR5Tx4sNEIwwQZPLJh4
         Mqki3Rb8THGho1EqqyFdItPQm2tVQFwFs0BVjMSnq06M8G4vlX9QxSLyFLXS97hDy3NX
         MwMw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711012053; x=1711616853;
        h=mime-version:user-agent:content-transfer-encoding:references
         :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=eq9syIN272CbfFhniy4a+7MTtRGsuH0LlUnyFxg3v8M=;
        b=UX2vetG6nivyV3LQn4P001awXqhfdrTjSHHWgnBoiXFH+IDvfLT7b3+5kv/lwGYNe+
         0MAFU6MA4MuQotpEqGceHbfJd3T2vCtc2e958OcTvRIym9sEaYZ77JgMZRNIVjrwX8lO
         9Fvr8VPU6D2YbczwRz7/ck/29uVvRjenfPsVKbXnkFYVlGnWZve5oAB/PNwe+Aa0WPjU
         6Df5rf+A+cZcew23N20PB0jz4gPyf4fey2vZYMQqqTlZXA2vlCL3zcPLTgLv6EYRjM5x
         K+5eHgE8n4vK1qqtazAePcSBXZsOiZE+hFU82S2BDvs78knT+A8M1gi6t7eD8DuGbkbP
         37ng==
X-Forwarded-Encrypted: i=1; AJvYcCUpzgZVAfxTk4LiKh5Y8YOSLjClIbJG+Xu95pgHD5UMIgZ0zPxNfza94/ImE2ttd8QiMX5dwCuLsoI49J8390O0jCKyU3UjBf0nNBHOMSc=
X-Gm-Message-State: AOJu0YxtCkEGoIQeunsrgjlqdJy7PFC0t/pZmcQbR8vZmptVvSLetwNw
	Pj/iekVjXqmyTQmEWMuQgHk/8UdR73Ozb4qSGBSJhWG4SFMxyxvKm1p02ly2yM0=
X-Google-Smtp-Source: AGHT+IFQ/NoqzPWooCFIYldznHaeO/OeD24p2EweEMAYM+IrycJaNLLdD03/xclGMDpOx1VZroyaWw==
X-Received: by 2002:a17:906:19d6:b0:a46:d2eb:1792 with SMTP id h22-20020a17090619d600b00a46d2eb1792mr5760190ejd.65.1711012052617;
        Thu, 21 Mar 2024 02:07:32 -0700 (PDT)
Message-ID: <0f91f4c773f7001f8b25cd18b08704a8884b8b19.camel@gmail.com>
Subject: Re: [PATCH v6 03/20] xen/riscv: introduce extenstion support check
 by compiler
From: Oleksii 
To: Conor Dooley 
Cc: Jan Beulich , Andrew Cooper
 ,  George Dunlap ,
 Julien Grall , Stefano Stabellini ,
 Wei Liu , Alistair Francis , Bob
 Eshleman , Connor Davis ,
 xen-devel@lists.xenproject.org
Date: Thu, 21 Mar 2024 10:07:25 +0100
In-Reply-To: <20240320-oak-uprising-db787f501695@spud>
References: 
	 
	 <6ddc9d8a-20e7-4e4d-ae1a-d2ea01479b38@suse.com>
	 <04c1424cec1342dcfb849d361f5eb9f3e7f34734.camel@gmail.com>
	 <20240320-oak-uprising-db787f501695@spud>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.50.2 (3.50.2-1.fc39) 
MIME-Version: 1.0

On Wed, 2024-03-20 at 19:44 +0000, Conor Dooley wrote:
> IIRC this only "works" because the OpenSBI devs assume that there are
> no
> non-normative behaviours and all CSRs have their ~God~ RVI defined
> meanings. Reading a CSR to see if it traps is not behaviour you can
> really
> rely on unless the platform claims to support Sstrict - but Sstrict
> you'd
> have to detect from the DT so chicken and egg for you! It's one of
> these
> new "extensions" from the profiles spec, so it doesn't even have
> support
> in Linux's dt-bindings yet. Up to Xen devs if you guys want to make
> the
> same assumptions as OpenSBI. Linux doesn't and when we discussed this
> not too long ago on the U-Boot ML in the context of the rng CSR it
> was
> also decided not to do make the assumption there either.
>=20
> Personally I wonder if you can just apply the same policy here as you
> did with Zbb in the other thread and assume that something with H
> will
> have Zihintpause and leave implementing a "fake" pause as an exercise
> for someone that introduces such a system?

If i understand you correctly, then it is done in this way now. Only
build time check is done, but it would be nice also have some runtime
check, and for now, for runtime the "check" is only exists in
booting.txt where it mentioned that Xen expects from CPU to support
some extenstions; otherwise "please implement the following functions".

Anyway, at the moment, the best one runtime check which we can provide
is detect availability of extensions from DT and what I mentioned in
commit message.

~ Oleksii


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 09:10:52 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 09:10:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696265.1087033 (Exim 4.92)
	(envelope-from )
	id 1rnERk-0006om-J8; Thu, 21 Mar 2024 09:10:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696265.1087033; Thu, 21 Mar 2024 09:10:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnERk-0006of-G9; Thu, 21 Mar 2024 09:10:48 +0000
Received: by outflank-mailman (input) for mailman id 696265;
 Thu, 21 Mar 2024 09:10:46 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rnERi-0006mF-Tm
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 09:10:46 +0000
Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com
 [2a00:1450:4864:20::32d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e61019c7-e762-11ee-a1ee-f123f15fe8a2;
 Thu, 21 Mar 2024 10:10:44 +0100 (CET)
Received: by mail-wm1-x32d.google.com with SMTP id
 5b1f17b1804b1-414700cffd6so5633725e9.1
 for ; Thu, 21 Mar 2024 02:10:44 -0700 (PDT)
Received: from localhost ([85.31.135.62]) by smtp.gmail.com with ESMTPSA id
 k4-20020adfe3c4000000b0033e48db23bdsm16685413wrm.100.2024.03.21.02.10.43
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 21 Mar 2024 02:10:43 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e61019c7-e762-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1711012244; x=1711617044; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=dxyRfSAZc2eKJn/fIAN0WDRa0aI5LU+mk7Q5QdRfDfg=;
        b=fVWBFhnMn3SbV5Az2jfxUc74WqJRNppPz0ZqhWK6lf/LoZ/dI7xiQAP4gjemefG75Q
         8yNTKBrhEu6wNMnU+QYvRSBYb4v5lFcx9lhkpRdakOYTDLQiIEImuwww6iMRq/m0Abzw
         BoeQF+jbW2gmX4Eu0lP5gbs7W1W6RlweoswVk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711012244; x=1711617044;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=dxyRfSAZc2eKJn/fIAN0WDRa0aI5LU+mk7Q5QdRfDfg=;
        b=IEjorjOTlEj3lxKP7R6hnmDsBIi6qrwVIYFINdXs4D9QIr+muTUYf/1vqnqBj6i3xl
         1QPtes34iYq6hF4FzmgH6S0mZlnHjM5BbyLZP9MDh31c46k4hEBE+/s0KrY8oMcuFW85
         br09z/7g0573wZqjMaRIcPkMYQWZ+czVQvinlABx6YLsgsnY7u/2UjHc8xF8Or9A9GAO
         PKohHIzQ95sLmsk60CJTSl6YIbSqgAQbvDFyWJGWlDWmJ9i5ZHPERCf74CEyVhft9fH4
         38w2DL8hCC56xzoR7dPSFSemdbCZIxuIlMLnDPnH3t94XnR/iIqKbdHDo0nIXn+ajrSl
         /7Sw==
X-Forwarded-Encrypted: i=1; AJvYcCUj++8YR8zHJGzkpVDukKw88nJrJ5a1uLoRWdGH3uIOciYoGDicPDhTBFVLqmpmrp/tXFLF7M66mDeNgcCyI08diEmajY7Lj4czysGZQwA=
X-Gm-Message-State: AOJu0YxOmkiHdh58wq921gg+ooSFRl2xiQUWoy4AdXc2HaHqiJiHsE8O
	WLyTXTeolEd6g5/KYMP8W0oazVsBhxBELlak17HjXitoTnZie65yjahu7ymX6Dw=
X-Google-Smtp-Source: AGHT+IE+dWjIJYvCHxqO43kxoTmPDBNIVJCkdwZeePaMwRgq4zDfzgeNV7sJiS4wiRcBgkzcHQqMwQ==
X-Received: by 2002:a05:600c:548c:b0:413:ff06:83cd with SMTP id iv12-20020a05600c548c00b00413ff0683cdmr3359546wmb.3.1711012244261;
        Thu, 21 Mar 2024 02:10:44 -0700 (PDT)
Date: Thu, 21 Mar 2024 10:10:43 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: Andrew Cooper ,
	George Dunlap ,
	Julien Grall ,
	Stefano Stabellini , Wei Liu ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH] x86/vcpu: relax VCPUOP_initialise restriction for non-PV
 vCPUs
Message-ID: 
References: <20240320135720.68894-1-roger.pau@citrix.com>
 <73314dc5-0145-4aa7-a3cd-23c943235392@suse.com>
 
 <4cc5d746-a50c-4819-a56e-512abf797ef2@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <4cc5d746-a50c-4819-a56e-512abf797ef2@suse.com>

On Thu, Mar 21, 2024 at 09:07:10AM +0100, Jan Beulich wrote:
> On 20.03.2024 17:29, Roger Pau Monné wrote:
> > On Wed, Mar 20, 2024 at 04:09:33PM +0100, Jan Beulich wrote:
> >> On 20.03.2024 14:57, Roger Pau Monne wrote:
> >>> There's no reason to force HVM guests to have a valid vcpu_info area when
> >>> initializing a vCPU, as the vCPU can also be brought online using the local
> >>> APIC, and on that path there's no requirement for vcpu_info to be setup ahead
> >>> of the bring up.  Note an HVM vCPU can operate normally without making use of
> >>> vcpu_info.
> >>
> >> While I'd agree if you started with "There's no real need to force ...", I
> >> still think there is a reason: If one wants to use paravirt interfaces (i.e.
> >> hypercalls), they would better do so consistently. After all there's also
> >> no need to use VCPUOP_initialise, yet you're not disabling its use.
> >>
> >> As said in reply to Andrew's reply, besides acting as a sentinel that
> >> structure instance also acts as a sink for Xen accesses to a vCPU's
> >> vcpu_info. By removing the check, you switch that from being a safeguard to
> >> being something that actually has to be expected to be accessed. Unless
> >> you've audited all uses to prove that no such access exists.
> > 
> > I'm kind of lost in this last paragraph, how is that different than
> > what currently happens when an HVM vCPU >= 32 is brought up using the
> > lapic and has no vpcu_info mapped?
> 
> I think this aspect was simply missed back at the time. And I think it
> wants mentioning explicitly to justify the change.

OK, I can add to the commit message:

"Note an HVM vCPU can operate normally without making use of
vcpu_info, and in fact does so when brought up from the local APIC."

> As said in reply to Andrew, I don't think the dummy structure can be got
> rid of. Nor can the checks here be (easily) removed altogether, i.e. your
> change cannot (easily) be extended to PV as well. Even conditional removal
> of the structure in !PV builds would first require all vcpu_info accesses
> to gain a suitable conditional. Which may be undesirable, as some of these
> may be deemed fast paths.

I didn't intended to do this here, as replied to Andrew.  If we want
to get rid of the check for PV also it needs to be done in a different
patch, and with a different justification and analysis.

> > Also, from a quick look it seems like sites do check whether vcpu_info
> > == dummy_vcpu_info, otherwise we would already be in trouble.
> 
> Such checks exist in code managing vcpu_info, but not - afaics - in places
> actually accessing it.

Quite possibly, I didn't look that close TBH, since my intention was
not to remove dummy_vcpu_info.  I've noticed however that
__update_vcpu_system_time() checks for v->vcpu_info_area.map == NULL,
which is fine, but shouldn't it also check for v->vcpu_info_area.map
== &dummy_vcpu_info, as it's pointless to update the vcpu system time
if pointing to the dummy_vcpu_info?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 09:17:35 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 09:17:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696272.1087043 (Exim 4.92)
	(envelope-from )
	id 1rnEYF-0007lF-C7; Thu, 21 Mar 2024 09:17:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696272.1087043; Thu, 21 Mar 2024 09:17:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnEYF-0007l8-9b; Thu, 21 Mar 2024 09:17:31 +0000
Received: by outflank-mailman (input) for mailman id 696272;
 Thu, 21 Mar 2024 09:17:29 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnEYD-0007l2-1y
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 09:17:29 +0000
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com
 [2a00:1450:4864:20::52e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d64fe173-e763-11ee-afe0-a90da7624cb6;
 Thu, 21 Mar 2024 10:17:27 +0100 (CET)
Received: by mail-ed1-x52e.google.com with SMTP id
 4fb4d7f45d1cf-568a53d2ce0so962530a12.0
 for ; Thu, 21 Mar 2024 02:17:27 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 h25-20020a17090634d900b00a454438091fsm8196272ejb.70.2024.03.21.02.17.26
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 21 Mar 2024 02:17:27 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d64fe173-e763-11ee-afe0-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711012647; x=1711617447; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=iSw81XpMzgQnaXcph5BuhvuoYGgfAfZ0qiu9jixVhX4=;
        b=Aw+7EQsk7MBAd2zcKz29oS3Y+vVNabMJSZR/UbC2w59nnvR2DZNiEIls74ZT+SxtNc
         03FqSIPPfad2dleqL+4GB1IPjgs+RMs/ca0fizQ5MvLd1DTFXVJ8ZLVSzfvXqikhZLAj
         wlTfteF5DG4tJDrB6qSBA8BVo+vKS5ODQ5u0dWNCUsfvg7zChbCWXvgkUs57lWrBrE5n
         IIHnrknf8Kzv5+Mewbjs1fjXicvEf1KTwq3zHYQxYmy/E22WgA/8y0cqtR5piNNvz4mV
         vC+GH7elodsvyd9h/NomybRUOeI5jCWmLrgFssWKMSJZKbLL80HYgMvwMieZhV5hT6Tn
         AYkQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711012647; x=1711617447;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=iSw81XpMzgQnaXcph5BuhvuoYGgfAfZ0qiu9jixVhX4=;
        b=YzWr4tBCJmUz0IhLwPfRznl6EpNcFxwKnBGeRbGv55dhOasB/auUPuITKdILD5E/Rl
         kagrenekZzIO4KjJpOshO+Kp22GJq/CL5BtsTG5RBtEZXbWXCvbe3Iev4oinmuqXh7z5
         6MLZZiieryBkVkn9M7065M7L0zn9J3jhl4DmusQkZhwRDDJW9g6iLsd3dAQBMJbsC0AG
         vjPI1Ck7YJK9X4aph173VERrd13njE0lhZMM4T+G9nW7QUvcPVP0cS754i4/CefFXtZy
         W9UI+N8kNuvqvdxbizoa12t3NptdanyYIUNreuXBkUU49iPEoATFkqGp8m/dzGvlM5Nc
         Z3Aw==
X-Forwarded-Encrypted: i=1; AJvYcCUJBn8xIatWZEjF/Nxk4mpHPrtdGBe8S/x//ET8Vr3dA3KiAzBdMWrZGKIcd/nErNrBcdqhD7ti7a8mqDePhQ5C7LWc6PtYqexkFvXEPUU=
X-Gm-Message-State: AOJu0YxRkXJmmQA5a0yTGJTUyu6WSDsQQ1IB4uD5ECcsVww+VJjq6jdY
	BbMqxFOZqcb79qdasblEqi1fMM52nro5nydiVxd7z9CB7c2Lcn57U/jBfghq4A==
X-Google-Smtp-Source: AGHT+IGQC/b0VKyY6omVLF1JeqX4/6++9r3C7HVzZNybYT7Xh7yUwjKZYWtKaCMLTg7JWJucX4aXlg==
X-Received: by 2002:a17:907:7f17:b0:a46:e3f4:4c0f with SMTP id qf23-20020a1709077f1700b00a46e3f44c0fmr1164038ejc.53.1711012647403;
        Thu, 21 Mar 2024 02:17:27 -0700 (PDT)
Message-ID: 
Date: Thu, 21 Mar 2024 10:17:25 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/vcpu: relax VCPUOP_initialise restriction for non-PV
 vCPUs
Content-Language: en-US
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 xen-devel@lists.xenproject.org
References: <20240320135720.68894-1-roger.pau@citrix.com>
 <73314dc5-0145-4aa7-a3cd-23c943235392@suse.com> 
 <4cc5d746-a50c-4819-a56e-512abf797ef2@suse.com> 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 21.03.2024 10:10, Roger Pau Monné wrote:
> On Thu, Mar 21, 2024 at 09:07:10AM +0100, Jan Beulich wrote:
>> On 20.03.2024 17:29, Roger Pau Monné wrote:
>>> On Wed, Mar 20, 2024 at 04:09:33PM +0100, Jan Beulich wrote:
>>>> On 20.03.2024 14:57, Roger Pau Monne wrote:
>>>>> There's no reason to force HVM guests to have a valid vcpu_info area when
>>>>> initializing a vCPU, as the vCPU can also be brought online using the local
>>>>> APIC, and on that path there's no requirement for vcpu_info to be setup ahead
>>>>> of the bring up.  Note an HVM vCPU can operate normally without making use of
>>>>> vcpu_info.
>>>>
>>>> While I'd agree if you started with "There's no real need to force ...", I
>>>> still think there is a reason: If one wants to use paravirt interfaces (i.e.
>>>> hypercalls), they would better do so consistently. After all there's also
>>>> no need to use VCPUOP_initialise, yet you're not disabling its use.
>>>>
>>>> As said in reply to Andrew's reply, besides acting as a sentinel that
>>>> structure instance also acts as a sink for Xen accesses to a vCPU's
>>>> vcpu_info. By removing the check, you switch that from being a safeguard to
>>>> being something that actually has to be expected to be accessed. Unless
>>>> you've audited all uses to prove that no such access exists.
>>>
>>> I'm kind of lost in this last paragraph, how is that different than
>>> what currently happens when an HVM vCPU >= 32 is brought up using the
>>> lapic and has no vpcu_info mapped?
>>
>> I think this aspect was simply missed back at the time. And I think it
>> wants mentioning explicitly to justify the change.
> 
> OK, I can add to the commit message:
> 
> "Note an HVM vCPU can operate normally without making use of
> vcpu_info, and in fact does so when brought up from the local APIC."

I'd be fine adding this (or having this added) while committing.

>> As said in reply to Andrew, I don't think the dummy structure can be got
>> rid of. Nor can the checks here be (easily) removed altogether, i.e. your
>> change cannot (easily) be extended to PV as well. Even conditional removal
>> of the structure in !PV builds would first require all vcpu_info accesses
>> to gain a suitable conditional. Which may be undesirable, as some of these
>> may be deemed fast paths.
> 
> I didn't intended to do this here, as replied to Andrew.  If we want
> to get rid of the check for PV also it needs to be done in a different
> patch, and with a different justification and analysis.
> 
>>> Also, from a quick look it seems like sites do check whether vcpu_info
>>> == dummy_vcpu_info, otherwise we would already be in trouble.
>>
>> Such checks exist in code managing vcpu_info, but not - afaics - in places
>> actually accessing it.
> 
> Quite possibly, I didn't look that close TBH, since my intention was
> not to remove dummy_vcpu_info.  I've noticed however that
> __update_vcpu_system_time() checks for v->vcpu_info_area.map == NULL,
> which is fine, but shouldn't it also check for v->vcpu_info_area.map
> == &dummy_vcpu_info, as it's pointless to update the vcpu system time
> if pointing to the dummy_vcpu_info?

The check is there to guard against NULL deref. As said, the aspect of a
vCPU being brought up the "native" way yet then still using its vCPU info
was, by mistake, neglected earlier on. So yes, such a check could be
added here, but it isn't strictly necessary as long as we don't avoid
accessing the dummy structure uniformly everywhere (which, as said, I'm
not sure we want to do).

Jan


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 09:22:19 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 09:22:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696274.1087054 (Exim 4.92)
	(envelope-from )
	id 1rnEcr-0001Rg-Uc; Thu, 21 Mar 2024 09:22:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696274.1087054; Thu, 21 Mar 2024 09:22:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnEcr-0001RZ-Qc; Thu, 21 Mar 2024 09:22:17 +0000
Received: by outflank-mailman (input) for mailman id 696274;
 Thu, 21 Mar 2024 09:22:16 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnEcq-0001RS-U4
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 09:22:16 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 80d84ac3-e764-11ee-afe0-a90da7624cb6;
 Thu, 21 Mar 2024 10:22:15 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 51D1261189;
 Thu, 21 Mar 2024 09:22:13 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id BAD5FC433C7;
 Thu, 21 Mar 2024 09:22:10 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 80d84ac3-e764-11ee-afe0-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1711012933;
	bh=qjQQK6j3m/jVOwIC8r/wFiiwGts62l6f+srMNq0rfGo=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=Zh9XA9tZPR7D24e7FmpEPBzSUZJ2wGbgGGTPrvJXn4aJvw5wSzoQi65T3I2I1YYbD
	 MXgGbo/umdTlO5IDswxBcMSOO1ylsnwo0bwyl1RVnJe1UBBVx0fdx70FL/NqkFr2dL
	 ppJ9HxqHByOv+PE0+l2/KBpyXN1KUGp54NFhbVS0wHuKpoME7YcQkBTieJo5bGjKRh
	 OkXAKS39j1zkcMlg0F6lOzBuvzFBk0KaX+5KzFmzm43zioFjEzPSdCPlXmak8QrAml
	 /vkkaP+FvO2ickK0KCVJ8CyvoXMJ27/eaXMJghXAudrnpVx2SIq9+6f8LzJU1gFGup
	 +DvvmaFpwW8vQ==
Date: Thu, 21 Mar 2024 09:22:08 +0000
From: Conor Dooley 
To: Jan Beulich 
Cc: Andrew Cooper ,
	George Dunlap ,
	Julien Grall ,
	Stefano Stabellini , Wei Liu ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	xen-devel@lists.xenproject.org,
	Oleksii 
Subject: Re: [PATCH v6 03/20] xen/riscv: introduce extenstion support check
 by compiler
Message-ID: <20240321-cranium-deluxe-77d762948b96@spud>
References: 
 
 <6ddc9d8a-20e7-4e4d-ae1a-d2ea01479b38@suse.com>
 <04c1424cec1342dcfb849d361f5eb9f3e7f34734.camel@gmail.com>
 <20240320-oak-uprising-db787f501695@spud>
 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="alPnOWaOvdc6lB6s"
Content-Disposition: inline
In-Reply-To: 


--alPnOWaOvdc6lB6s
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Mar 21, 2024 at 09:31:59AM +0100, Jan Beulich wrote:
> On 20.03.2024 20:44, Conor Dooley wrote:
> > On Wed, Mar 20, 2024 at 07:58:05PM +0100, Oleksii wrote:
> >> On Mon, 2024-03-18 at 17:58 +0100, Jan Beulich wrote:
> >>> On 15.03.2024 19:05, Oleksii Kurochko wrote:
> >>>> Currently, RISC-V requires two extensions: _zbb and _zihintpause.
> >>>
> >>> Do we really require Zbb already?
> >> After an introduction of Andrew C. patches [1] it is requited for
> >> __builtin_ffs{l}
> >>
> >> [1]
> >> https://lore.kernel.org/xen-devel/20240313172716.2325427-1-andrew.coop=
er3@citrix.com/T/#t
> >>>
> >>>> This patch introduces a compiler check to check if these extensions
> >>>> are supported.
> >>>> Additionally, it introduces the riscv/booting.txt file, which
> >>>> contains
> >>>> information about the extensions that should be supported by the
> >>>> platform.
> >>>>
> >>>> In the future, a feature will be introduced to check whether an
> >>>> extension
> >>>> is supported at runtime.
> >>>> However, this feature requires functionality for parsing device
> >>>> tree
> >>>> source (DTS), which is not yet available.
> >>>
> >>> Can't you query the CPU for its features?
> >> I couldn't find such reg ( or SBI call ) in the spec.
> >=20
> > There isn't.
> >=20
> >> SBI call sbi_probe_extension() exists, but it doesn't check for every
> >> possible extension. As far as I understand it checks only for that one
> >> which are present in SBI spec.
> >=20
> > Yeah, it only checks for SBI extensions, not ISA extensions.
>=20
> And there was never a consideration to add, at the architecture level,
> some straightforward way for all layers of software to be able to
> easily detect availability of extensions? I find the lack thereof
> pretty surprising ...

No, there sorta is. There's a "configuration structure" spec in the
works, but the (public?) documentation for it is very nascent:
https://github.com/riscv/configuration-structure/

It uses (what I seem to recall is an m-mode) CSR to give the address
of an ASN.1 structure in memory which is intended to encode a whole
raft of information. The CSR itself might be M-Mode, but that doesn't
prevent accessing the data itself at any layer in the stack. The last
time I read it I got the impression it was supposed to be usable for
describing an entire system (including things like i2c or spi
controllers). I don't think it ever explicitly says that in the spec,
but there's a note (IIRC) that mentions being unsuitable for describing
devices on dynamic buses like PCI, so that kinda implies anything else
is fair game.

Hope that helps?

--alPnOWaOvdc6lB6s
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCZfv8QAAKCRB4tDGHoIJi
0gH8AQDkq72OBEG0QTVAtRar04f1ATCvaDGKG+PhzPcn7TLnzAD9GyagSQmI9tri
tWADNzMq5fw1eXLfwSLkJlgWFOj7dQI=
=uVKi
-----END PGP SIGNATURE-----

--alPnOWaOvdc6lB6s--


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 09:27:52 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 09:27:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696278.1087064 (Exim 4.92)
	(envelope-from )
	id 1rnEiB-000241-Fu; Thu, 21 Mar 2024 09:27:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696278.1087064; Thu, 21 Mar 2024 09:27:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnEiB-00023u-DM; Thu, 21 Mar 2024 09:27:47 +0000
Received: by outflank-mailman (input) for mailman id 696278;
 Thu, 21 Mar 2024 09:27:46 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rnEiA-00023o-8g
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 09:27:46 +0000
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com
 [2a00:1450:4864:20::52c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 45afdb66-e765-11ee-a1ee-f123f15fe8a2;
 Thu, 21 Mar 2024 10:27:44 +0100 (CET)
Received: by mail-ed1-x52c.google.com with SMTP id
 4fb4d7f45d1cf-56b93b45779so857803a12.1
 for ; Thu, 21 Mar 2024 02:27:44 -0700 (PDT)
Received: from [192.168.206.239] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 b20-20020a0564021f1400b0056bb5538d02sm1419166edb.11.2024.03.21.02.27.42
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 21 Mar 2024 02:27:42 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 45afdb66-e765-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1711013264; x=1711618064; darn=lists.xenproject.org;
        h=mime-version:user-agent:content-transfer-encoding:references
         :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject
         :date:message-id:reply-to;
        bh=KVGtMiaRAX4o78Tx4uBWQqBDYScsT6jZpM01VLRGyGc=;
        b=RPFkMBBGKePOG2K2wD15Kz2HLcp71IK0sBcmnDg/Saz6+ugtTpuVoGQzGTNJrh0CVc
         OREJ1kh/Re4c+T6vPBwNtXiXO2MX4Qty/lV4vGdOwmUkAVjk6zz/KarTMdRuX//r9/hn
         2SZ73tLsz8nu6SFobl3xmEKFRq5lCajKaIc83hmfH/2vm/SsvauOPUGDz4kho0nyaCF3
         X7xZnEUBpiiskFa07jBuR3sOcFr/2yqf1SWbwNOfYLwXC6ymNrAsgZXedvYmhTD56ymu
         HUUjc2A6DCXeQiBTRmDkmPmGGEp3fDstDDRPa+3KdES9wygBPGIxM76w5m1M9rNqPMvn
         0fZg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711013264; x=1711618064;
        h=mime-version:user-agent:content-transfer-encoding:references
         :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=KVGtMiaRAX4o78Tx4uBWQqBDYScsT6jZpM01VLRGyGc=;
        b=iCHK2jm7gbyJ7gx8PGHX0NGEuxj4921h1DcKe+lCMc7cYeV8OkkCxsDnH4WJKP0icZ
         gSfQfCiJ4syG+nvjHmnCNbl5myOg56EvdTY1nBZrSJoLCD+MnSYOPQNqgHBGumC/SGKc
         +eLiZiGCHWzAzj7/o0stdN8umghZi6Jx7iC6dd1QtE36+Vl5q5W8aJ9GfON4IhfLNKHg
         j6/71W/NqyR5iEZjYDD/p5UY1kw6uxxi3nkiQ20+Ue4HLjA6XbUM9lo48XAooDULTCz3
         FpEKssFe3qnz6Ve/DzUXULkl+AHmOcNOu9nF+F0QsyTY/AATCe1Ok96dAN7hDKa7qo47
         34jg==
X-Forwarded-Encrypted: i=1; AJvYcCXIOUlrPv/YAtDGzTs2mTt+npiROS3+otAvvcRw3yMnYJsGQyRu0Vtft89k+dJ6fpYO5B08ei/H2ef7ESSbFnzvUY0lz83SyWCBJ1zwC6g=
X-Gm-Message-State: AOJu0YyZ5fep8jKNtjIbXEeiqH93JNYCsOnSBzLjSfMTCdjpmnKNNMiO
	dG276/62grRFHU6u347fjAxRb/0UdFJkO2K32xTapX1uxRYxIvjx
X-Google-Smtp-Source: AGHT+IG4lWoAVVKH3s0oZ7fjFFDVot5ly5OZyAPQkGIbUKipvV9LejJmvSJqTt2xf+eD6hiYOZUT0g==
X-Received: by 2002:a05:6402:c50:b0:568:93bb:d0c2 with SMTP id cs16-20020a0564020c5000b0056893bbd0c2mr17323535edb.20.1711013263466;
        Thu, 21 Mar 2024 02:27:43 -0700 (PDT)
Message-ID: <0bb22584b759207de0a4041bac9118fe43959b69.camel@gmail.com>
Subject: Re: [PATCH v6 04/20] xen/asm-generic: introduce generic non-atomic
 test_*bit()
From: Oleksii 
To: Jan Beulich 
Cc: Andrew Cooper , George Dunlap
 , Julien Grall , Stefano
 Stabellini , Wei Liu ,
 xen-devel@lists.xenproject.org
Date: Thu, 21 Mar 2024 10:27:42 +0100
In-Reply-To: 
References: 
	 <48b7dfafccc7a0ed814b5dfb0f109a0473a1b4b4.1710517542.git.oleksii.kurochko@gmail.com>
	 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.50.2 (3.50.2-1.fc39) 
MIME-Version: 1.0

On Wed, 2024-03-20 at 16:30 +0100, Jan Beulich wrote:
> On 15.03.2024 19:06, Oleksii Kurochko wrote:
> > The patch introduces the following generic functions:
> > * test_bit
> > * generic___test_and_set_bit
> > * generic___test_and_clear_bit
> > * generic___test_and_change_bit
> >=20
> > Also, the patch introduces the following generics which are
> > used by the functions mentioned above:
> > * BITOP_BITS_PER_WORD
> > * BITOP_MASK
> > * BITOP_WORD
> > * BITOP_TYPE
> >=20
> > These functions and macros can be useful for architectures
> > that don't have corresponding arch-specific instructions.
> >=20
> > Signed-off-by: Oleksii Kurochko 
>=20
> First of all: How much syncing has there been versus Andrew's plans?
> I don't want to end up in the middle of two entirely different
> approaches to the same generalization goal.
We don't have synced about bit operations mentioned in this patch, so I
decided to follow an approach I have for them. But if Andrew's approach
is better, or it would be better to follow one approach instead of
introducing two approaches, I will be happy to rework this patch.

Andrew, what do you think about this bit ops?

>=20
> > --- /dev/null
> > +++ b/xen/include/asm-generic/bitops/bitops-bits.h
> > @@ -0,0 +1,21 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +#ifndef _ASM_GENERIC_BITOPS_BITS_H_
> > +#define _ASM_GENERIC_BITOPS_BITS_H_
> > +
> > +#ifndef BITOP_BITS_PER_WORD
> > +#define BITOP_BITS_PER_WORD=C2=A0=C2=A0=C2=A0=C2=A0 32
> > +#endif
> > +
> > +#ifndef BITOP_MASK
> > +#define BITOP_MASK(nr)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 (1U << ((nr) %
> > BITOP_BITS_PER_WORD))
> > +#endif
> > +
> > +#ifndef BITOP_WORD
> > +#define BITOP_WORD(nr)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 ((nr) / BITOP_BITS_PER_WORD)
> > +#endif
> > +
> > +#ifndef BITOP_TYPE
> > +typedef uint32_t bitops_uint_t;
> > +#endif
>=20
> Is it of practical use to permit overriding of one of BITOP_TYPE and
> BITOP_BITS_PER_WORD? I think both want tying together.
>=20
> Is it further of any use to allow overriding of BITOP_{MASK,WORD}?
> There's minimal generalization needed to allow an override of
> BITOP_TYPE, though:
>=20
> #define BITOP_MASK(nr)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 ((bitop_uint_t)1 << ((nr) %
> BITOP_BITS_PER_WORD))
>=20
> Note that I've omitted the 's' from the typedef name - the macros
> all having no 'S', imo the type also shouldn't (or the other way
> around).
If to generalize BITOP_MASK in way you suggest, then there is no need
to allow overriding of BITOP_{MASK,WORD}. I'll update this part.

>=20
> > --- /dev/null
> > +++ b/xen/include/asm-generic/bitops/generic-non-atomic.h
> > @@ -0,0 +1,89 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only */
> > +/*
> > + * The file is based on Linux ( 6.4.0 ) header:
> > + *=C2=A0=C2=A0 include/asm-generic/bitops/generic-non-atomic.h
> > + *=20
> > + * Only functions that can be reused in Xen were left; others were
> > removed.
> > + *=20
> > + * Also, the following changes were done:
> > + *=C2=A0 - it was updated the message inside #ifndef ... #endif.
> > + *=C2=A0 - __always_inline -> always_inline to be align with definitio=
n
> > in
> > + *=C2=A0=C2=A0=C2=A0 xen/compiler.h.
> > + *=C2=A0 - update function prototypes from
> > + *=C2=A0=C2=A0=C2=A0 generic___test_and_*(unsigned long nr nr, volatil=
e unsigned
> > long *addr) to
> > + *=C2=A0=C2=A0=C2=A0 generic___test_and_*(unsigned long nr, volatile v=
oid *addr)
> > to be
>=20
> What's the point of having a whopping 3 successive inner underscores?
> Which btw ...
>=20
> > + *=C2=A0=C2=A0=C2=A0 consistent with other related macros/defines.
> > + *=C2=A0 - convert identations from tabs to spaces.
> > + *=C2=A0 - inside generic__test_and_* use 'bitops_uint_t' instead of
> > 'unsigned long'
> > + *=C2=A0=C2=A0=C2=A0 to be generic.
>=20
> ... shrink to just 2 here.
>=20
> Oh, and there's no generic__test_bit(), but just test_bit() in a
> separate
> header.
I just wanted to show that it is a generic version of __test_and_*
operations. If there is no sense in that, I am okay to update function
names.

~ Oleksii
>=20
> > + */
> > +
> > +#ifndef __ASM_GENERIC_BITOPS_GENERIC_NON_ATOMIC_H
> > +#define __ASM_GENERIC_BITOPS_GENERIC_NON_ATOMIC_H
> > +
> > +#include 
> > +
> > +#include 
> > +
> > +#ifndef XEN_BITOPS_H
> > +#error only  can be included directly
> > +#endif
> > +
> > +/*
> > + * Generic definitions for bit operations, should not be used in
> > regular code
> > + * directly.
> > + */
> > +
> > +/**
> > + * generic___test_and_set_bit - Set a bit and return its old value
> > + * @nr: Bit to set
> > + * @addr: Address to count from
> > + *
> > + * This operation is non-atomic and can be reordered.
> > + * If two examples of this operation race, one can appear to
> > succeed
> > + * but actually fail.=C2=A0 You must protect multiple accesses with a
> > lock.
> > + */
> > +static always_inline bool
> > +generic___test_and_set_bit(unsigned long nr, volatile void *addr)
> > +{
> > +=C2=A0=C2=A0=C2=A0 bitops_uint_t mask =3D BITOP_MASK(nr);
> > +=C2=A0=C2=A0=C2=A0 bitops_uint_t *p =3D ((bitops_uint_t *)addr) + BITO=
P_WORD(nr);
>=20
> If you cast away the volatile here, what's the point of having it in
> the parameter declaration? Also such a cast doesn't need an outer
> pair of parentheses.
>=20
> > +=C2=A0=C2=A0=C2=A0 bitops_uint_t old =3D *p;
> > +
> > +=C2=A0=C2=A0=C2=A0 *p =3D old | mask;
> > +=C2=A0=C2=A0=C2=A0 return (old & mask) !=3D 0;
>=20
> Minor: The function returning bool, the "!=3D 0" (and then also the
> parentheses) could be omitted.
>=20
> > --- /dev/null
> > +++ b/xen/include/asm-generic/bitops/test-bit.h
> > @@ -0,0 +1,18 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +#ifndef _ASM_GENERIC_BITOPS_TESTBIT_H_
> > +#define _ASM_GENERIC_BITOPS_TESTBIT_H_
> > +
> > +#include 
> > +
> > +/**
> > + * test_bit - Determine whether a bit is set
> > + * @nr: bit number to test
> > + * @addr: Address to start counting from
> > + */
> > +static inline int test_bit(int nr, const volatile void *addr)
> > +{
> > +=C2=A0=C2=A0=C2=A0 const volatile bitops_uint_t *p =3D addr;
> > +=C2=A0=C2=A0=C2=A0 return 1 & (p[BITOP_WORD(nr)] >> (nr & (BITOP_BITS_=
PER_WORD -
> > 1)));
> > +}
>=20
> Interestingly you don't lose the volatile here. Overall the way this
> is written would likely benefit the other functions too. There's no
> cast needed here and thus also not there.
>=20
> Jan



From xen-devel-bounces@lists.xenproject.org Thu Mar 21 09:33:48 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 09:33:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696280.1087073 (Exim 4.92)
	(envelope-from )
	id 1rnEnw-0004I7-3Q; Thu, 21 Mar 2024 09:33:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696280.1087073; Thu, 21 Mar 2024 09:33:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnEnw-0004I0-0o; Thu, 21 Mar 2024 09:33:44 +0000
Received: by outflank-mailman (input) for mailman id 696280;
 Thu, 21 Mar 2024 09:33:42 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rnEnu-0004Hu-C0
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 09:33:42 +0000
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com
 [2a00:1450:4864:20::635])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1a65be5e-e766-11ee-afe0-a90da7624cb6;
 Thu, 21 Mar 2024 10:33:41 +0100 (CET)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-a450bedffdfso86171166b.3
 for ; Thu, 21 Mar 2024 02:33:41 -0700 (PDT)
Received: from [192.168.206.239] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 h25-20020a17090634d900b00a46196a7faesm8213029ejb.57.2024.03.21.02.33.39
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 21 Mar 2024 02:33:40 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1a65be5e-e766-11ee-afe0-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1711013621; x=1711618421; darn=lists.xenproject.org;
        h=mime-version:user-agent:content-transfer-encoding:references
         :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject
         :date:message-id:reply-to;
        bh=6XxgONGD1Pq+jv5Fx9OjaGUQAF0zMYY2MbV/Bc5o+n0=;
        b=DNjqp+TQJRpFm7n7WtzpOrPJMNfb4fomWBFl1SCY4yXR4aaQnh/0NkiCKF67KmURZe
         RyC66LU1pbThklQfM8psYXGGrXQdIPq7wIXSjFQchmpPbX2qk0C9Gjh4sSjNm+Gbzaej
         zvtQAb5//XXC3kLiqjGLg+JZzs1htoy1Gp/WGAWtqTWlvKqD1nAWX0wMPDMWUwYE4cud
         TN7VjDo4EG3dBiMncal50mgXYjlTawv5hQE4dEA+sTXDLCAYxiqbz8HnNSeh2WA4m0GR
         ihHpt70UiTgVTkUS1aB/RHL6WZq6Idfqx3vByA5zY6XH3WFA9qbgiUi9J+JGYcsAdf+g
         GDYw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711013621; x=1711618421;
        h=mime-version:user-agent:content-transfer-encoding:references
         :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=6XxgONGD1Pq+jv5Fx9OjaGUQAF0zMYY2MbV/Bc5o+n0=;
        b=Mq0omD4ED8j+N33xaC1FZkbGZwIaXuYRDQgc7io2+Bu66MZIuxME+P18n2S44bErjB
         M43bCu8wh2D1kn+njMiBmewWeUylyTpre6ZA7J8N+LMDDrI4WU48Jx694eHE/aplX0Qg
         XymOqpsDq/ib4vuA3wGiJ4lQKLL1kXMZqM7x+M6rV0pSEHxFnYuAIA34SfsUS0ePGHmV
         ZnqQ355hQGLY3eAb+NP9+P8EqnmfPy7JwKSz8uuFJqJ3pW8mVxMRZWMTfIE20ULglt0O
         JpjY8ndRnjNkDuXZCWiBbbtP14FZ1jTDGWAcUa9KErnSN+I+ErpJx+1dRCNMAjrrerku
         IzoA==
X-Forwarded-Encrypted: i=1; AJvYcCUaEmIhQgogMIyuZ2zuO/O8wbDaTTwub6eziCNj1n0Qprkex6tMEc6OI7JONsbGr+r5DQkduIffpqj39Y32Y9nL0TQkHmtkhn3hCXEfB1s=
X-Gm-Message-State: AOJu0YwgqoH2PgDQGbPPJhUvKNhPhrOd8OEHwGDrxp3UaqSjH+PyfUms
	VoPAlN4RkvXufz2wP02CLBMhgAf45jJwjRGR4TCkFyGhnNz1tSfh
X-Google-Smtp-Source: AGHT+IEumABGjVGRwUUsUSS+WEV2jHgR07iYAQu5NaqjhulBOO8ny9uLFV2CCPntjUNKaSjG4Is8/w==
X-Received: by 2002:a17:906:ef0c:b0:a46:c01b:7e2c with SMTP id f12-20020a170906ef0c00b00a46c01b7e2cmr9375508ejs.75.1711013620569;
        Thu, 21 Mar 2024 02:33:40 -0700 (PDT)
Message-ID: 
Subject: Re: [PATCH v6 06/20] xen/bitops: put __ffs() and ffz() into linux
 compatible header
From: Oleksii 
To: Jan Beulich 
Cc: Stefano Stabellini , Julien Grall
 ,  Bertrand Marquis , Michal
 Orzel , Volodymyr Babchuk
 , Andrew Cooper , 
 George Dunlap , Wei Liu , Shawn
 Anastasio , Rahul Singh
 ,  xen-devel@lists.xenproject.org
Date: Thu, 21 Mar 2024 10:33:39 +0100
In-Reply-To: 
References: 
	 <8bc35da4a9fd44d2dcf9677dcc99334eb7142581.1710517542.git.oleksii.kurochko@gmail.com>
	 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.50.2 (3.50.2-1.fc39) 
MIME-Version: 1.0

On Wed, 2024-03-20 at 16:42 +0100, Jan Beulich wrote:
> On 15.03.2024 19:06, Oleksii Kurochko wrote:
> > --- a/xen/lib/find-next-bit.c
> > +++ b/xen/lib/find-next-bit.c
> > @@ -9,6 +9,7 @@
> > =C2=A0 * 2 of the License, or (at your option) any later version.
> > =C2=A0 */
> > =C2=A0#include 
> > +#include 
> > =C2=A0
> > =C2=A0#include 
>=20
> Hmm, no, a library source would better not include this header.
> Surely
> the ffz() can be taken care of locally here?
Considering that ffz() is only used here, then it makes sense to drop
ffz() from xen/linux-compat.h> and defines it here as:
#define ffz(x) ffsl(~(x)) - 1

~ Oleksii


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 09:39:45 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 09:39:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696287.1087084 (Exim 4.92)
	(envelope-from )
	id 1rnEtg-0005QZ-QP; Thu, 21 Mar 2024 09:39:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696287.1087084; Thu, 21 Mar 2024 09:39:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnEtg-0005QS-My; Thu, 21 Mar 2024 09:39:40 +0000
Received: by outflank-mailman (input) for mailman id 696287;
 Thu, 21 Mar 2024 09:39:39 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rnEtf-0005Nx-8J
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 09:39:39 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id eefff8be-e766-11ee-afe0-a90da7624cb6;
 Thu, 21 Mar 2024 10:39:38 +0100 (CET)
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 by support.bugseng.com (Postfix) with ESMTPA id 672B24EE0748;
 Thu, 21 Mar 2024 10:39:37 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: eefff8be-e766-11ee-afe0-a90da7624cb6
MIME-Version: 1.0
Date: Thu, 21 Mar 2024 10:39:37 +0100
From: Nicola Vetrini 
To: Andrew Cooper 
Cc: Xen-devel , =?UTF-8?Q?Roger_Pau_Monn?=
 =?UTF-8?Q?=C3=A9?= , George Dunlap
 , Jan Beulich , Stefano
 Stabellini , Julien Grall , Dario
 Faggioli , "consulting @ bugseng . com"
 
Subject: Re: [PATCH 0/7] xen/trace: Treewide API cleanup
In-Reply-To: <9a88b98aeb598b0889ab6b88fc06bdfc@bugseng.com>
References: <20240318163552.3808695-1-andrew.cooper3@citrix.com>
 <9a88b98aeb598b0889ab6b88fc06bdfc@bugseng.com>
Message-ID: 
X-Sender: nicola.vetrini@bugseng.com
Organization: BUGSENG s.r.l.
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit

On 2024-03-20 12:01, Nicola Vetrini wrote:
> On 2024-03-18 17:35, Andrew Cooper wrote:
>> Rework the trace API to unify it (remove the HVM specific 
>> obfuscation), and
>> remove MISRA violations.
>> 
>> v3:
>>  * Delete TRACE_PARAM64()
>> 
>> Andrew Cooper (7):
>>   xen/trace: Introduce new API
>>   xen/credit2: Clean up trace handling
>>   xen/rt: Clean up trace handling
>>   xen/sched: Clean up trace handling
>>   xen: Switch to new TRACE() API
>>   xen/trace: Update final {__,}trace_var() users to the new API
>>   xen/trace: Drop old trace API
> 
> Hi Andrew,
> 
> thanks for the series. I'll run it trough ECLAIR when I have some spare 
> time, so that we can assess the impact especially on Rule 20.7.

Everything is fine for Rule 20.7 in a differential run with respect to 
yesterday's staging branch

-- 
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 09:58:05 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 09:58:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696290.1087093 (Exim 4.92)
	(envelope-from )
	id 1rnFBI-0000Wv-8T; Thu, 21 Mar 2024 09:57:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696290.1087093; Thu, 21 Mar 2024 09:57:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnFBI-0000Wo-5G; Thu, 21 Mar 2024 09:57:52 +0000
Received: by outflank-mailman (input) for mailman id 696290;
 Thu, 21 Mar 2024 09:57:50 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rnFBG-0000Wf-2N
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 09:57:50 +0000
Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com
 [2a00:1450:4864:20::12b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7863af2e-e769-11ee-a1ee-f123f15fe8a2;
 Thu, 21 Mar 2024 10:57:47 +0100 (CET)
Received: by mail-lf1-x12b.google.com with SMTP id
 2adb3069b0e04-513dc99b709so1009294e87.1
 for ; Thu, 21 Mar 2024 02:57:47 -0700 (PDT)
Received: from localhost ([85.31.135.62]) by smtp.gmail.com with ESMTPSA id
 by1-20020a056000098100b0033e18421618sm13383647wrb.17.2024.03.21.02.57.46
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 21 Mar 2024 02:57:46 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7863af2e-e769-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1711015067; x=1711619867; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=+v2WOPdak9UU9ZOKqEI45K4ZzSE8WyWyHQsVBt7X5E0=;
        b=GbLsJSWEqitrpbRBshwCPCikGaP+22j74c0ATmt2DBCmZWiwIc44SGaXramI+DO+R5
         Doim3cx7WhAqgKSvFXK/Nq/RjCrGjsQgnaPeQlI4HsQ9PhAgr+uE7S1dhNtMtraOtIvK
         5jCAXdai3UIaDErh7mRy7uwDVQMTwrgeRbxP4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711015067; x=1711619867;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=+v2WOPdak9UU9ZOKqEI45K4ZzSE8WyWyHQsVBt7X5E0=;
        b=B3DiOxwPDOm5zEV0yYVh4xf77uBSFhcEIiBTnctCdIy5P9g3mJD4AUrhqIdcoI5yt8
         Wf0UBvmsasZBNoq/E1D3pmdpltL/8jiKfMFR7SqyL9cx0i//VUBZGbzVR1LTIpP4haRy
         +WapMGWHcnzfBDfqVuWH9iDnCz2bk2aHG6EWVb/V5vnZyipPMxBOruz3B+nsC4fRlHAb
         kwOHnAf+6YIicSGqrSxm6pw/H8c0sfSgp/XBlMYdIpoLKrA3mGUp8Twc5tfZh/KQYXk5
         paKWBwYYldzmGniPMBU4j21R8WHY7bhHjR17wtKJPofk1Z2G7PMpt/8/S5xRVbqDfS08
         uOeQ==
X-Forwarded-Encrypted: i=1; AJvYcCXbLhbzaU6UTKCFewkybZxct2D+aHviRt5wX9RtyMIlBd+ZzqDYgMyJAH0rYHomde2ychcEM2pZqyf+zHmQaWui/8w/NlQz4ofxs5UF3yM=
X-Gm-Message-State: AOJu0Yy6J52RClLIe6t33W6Nq+CCp/EZu4veliN7VnvkS5T0b5T3QjbX
	vsIluo7EkzjPKngfLedA8xWtRtP2hEXOwMCxTWm2QexGI5ISMgWSHQ4ULf3XGXA=
X-Google-Smtp-Source: AGHT+IH4iw4RRHUWsRvOGdW/NxJ5854srPaJIEkTxL5ssqge8CceIds5J1pGKYhOKJbR9IDFHupKwg==
X-Received: by 2002:a05:6512:328d:b0:513:177e:4254 with SMTP id p13-20020a056512328d00b00513177e4254mr6085054lfe.14.1711015066839;
        Thu, 21 Mar 2024 02:57:46 -0700 (PDT)
Date: Thu, 21 Mar 2024 10:57:45 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: Andrew Cooper ,
	George Dunlap ,
	Julien Grall ,
	Stefano Stabellini , Wei Liu ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH] x86/vcpu: relax VCPUOP_initialise restriction for non-PV
 vCPUs
Message-ID: 
References: <20240320135720.68894-1-roger.pau@citrix.com>
 <73314dc5-0145-4aa7-a3cd-23c943235392@suse.com>
 
 <4cc5d746-a50c-4819-a56e-512abf797ef2@suse.com>
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Thu, Mar 21, 2024 at 10:17:25AM +0100, Jan Beulich wrote:
> On 21.03.2024 10:10, Roger Pau Monné wrote:
> > On Thu, Mar 21, 2024 at 09:07:10AM +0100, Jan Beulich wrote:
> >> On 20.03.2024 17:29, Roger Pau Monné wrote:
> >>> On Wed, Mar 20, 2024 at 04:09:33PM +0100, Jan Beulich wrote:
> >>>> On 20.03.2024 14:57, Roger Pau Monne wrote:
> >>>>> There's no reason to force HVM guests to have a valid vcpu_info area when
> >>>>> initializing a vCPU, as the vCPU can also be brought online using the local
> >>>>> APIC, and on that path there's no requirement for vcpu_info to be setup ahead
> >>>>> of the bring up.  Note an HVM vCPU can operate normally without making use of
> >>>>> vcpu_info.
> >>>>
> >>>> While I'd agree if you started with "There's no real need to force ...", I
> >>>> still think there is a reason: If one wants to use paravirt interfaces (i.e.
> >>>> hypercalls), they would better do so consistently. After all there's also
> >>>> no need to use VCPUOP_initialise, yet you're not disabling its use.
> >>>>
> >>>> As said in reply to Andrew's reply, besides acting as a sentinel that
> >>>> structure instance also acts as a sink for Xen accesses to a vCPU's
> >>>> vcpu_info. By removing the check, you switch that from being a safeguard to
> >>>> being something that actually has to be expected to be accessed. Unless
> >>>> you've audited all uses to prove that no such access exists.
> >>>
> >>> I'm kind of lost in this last paragraph, how is that different than
> >>> what currently happens when an HVM vCPU >= 32 is brought up using the
> >>> lapic and has no vpcu_info mapped?
> >>
> >> I think this aspect was simply missed back at the time. And I think it
> >> wants mentioning explicitly to justify the change.
> > 
> > OK, I can add to the commit message:
> > 
> > "Note an HVM vCPU can operate normally without making use of
> > vcpu_info, and in fact does so when brought up from the local APIC."
> 
> I'd be fine adding this (or having this added) while committing.
> 
> >> As said in reply to Andrew, I don't think the dummy structure can be got
> >> rid of. Nor can the checks here be (easily) removed altogether, i.e. your
> >> change cannot (easily) be extended to PV as well. Even conditional removal
> >> of the structure in !PV builds would first require all vcpu_info accesses
> >> to gain a suitable conditional. Which may be undesirable, as some of these
> >> may be deemed fast paths.
> > 
> > I didn't intended to do this here, as replied to Andrew.  If we want
> > to get rid of the check for PV also it needs to be done in a different
> > patch, and with a different justification and analysis.
> > 
> >>> Also, from a quick look it seems like sites do check whether vcpu_info
> >>> == dummy_vcpu_info, otherwise we would already be in trouble.
> >>
> >> Such checks exist in code managing vcpu_info, but not - afaics - in places
> >> actually accessing it.

Is there anything else that needs adjusting then, or are you happy to
pick this up and adjust the commit message?

> > Quite possibly, I didn't look that close TBH, since my intention was
> > not to remove dummy_vcpu_info.  I've noticed however that
> > __update_vcpu_system_time() checks for v->vcpu_info_area.map == NULL,
> > which is fine, but shouldn't it also check for v->vcpu_info_area.map
> > == &dummy_vcpu_info, as it's pointless to update the vcpu system time
> > if pointing to the dummy_vcpu_info?
> 
> The check is there to guard against NULL deref. As said, the aspect of a
> vCPU being brought up the "native" way yet then still using its vCPU info
> was, by mistake, neglected earlier on. So yes, such a check could be
> added here, but it isn't strictly necessary as long as we don't avoid
> accessing the dummy structure uniformly everywhere (which, as said, I'm
> not sure we want to do).

I could add such a check in a separate patch, my main concern with
this is not correctness, it's just that we waste cycles updating the
contents of dummy_vcpu_info which is useless.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 10:07:34 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 10:07:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696293.1087104 (Exim 4.92)
	(envelope-from )
	id 1rnFKc-0002my-48; Thu, 21 Mar 2024 10:07:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696293.1087104; Thu, 21 Mar 2024 10:07:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnFKc-0002mr-12; Thu, 21 Mar 2024 10:07:30 +0000
Received: by outflank-mailman (input) for mailman id 696293;
 Thu, 21 Mar 2024 10:07:28 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rnFKa-0002ml-RI
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 10:07:28 +0000
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com
 [2a00:1450:4864:20::633])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id cd738781-e76a-11ee-a1ee-f123f15fe8a2;
 Thu, 21 Mar 2024 11:07:19 +0100 (CET)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-a4715991c32so35394766b.1
 for ; Thu, 21 Mar 2024 03:07:19 -0700 (PDT)
Received: from [192.168.206.239] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 d20-20020a1709067f1400b00a468bcde79bsm7048602ejr.109.2024.03.21.03.07.17
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 21 Mar 2024 03:07:18 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: cd738781-e76a-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1711015639; x=1711620439; darn=lists.xenproject.org;
        h=mime-version:user-agent:content-transfer-encoding:references
         :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject
         :date:message-id:reply-to;
        bh=wds2+Ebidzro+sd+zz3DnIo232uII0R6cu41IMTPTog=;
        b=mPHYhWdx7MGyzHNsPYI4ixkPy6PcF452nNmZGerx+ABuzM394ai2KzCQT9mkGaKSix
         UjyDzA4V3+nawWzl1zaaX/vzjKi+sFSSeFa5p21n/OyEi3/JdCv+kqqwOJCQM3e0YSJa
         SA/jqjTwO0I4SLR5CwfECCV/Ie0VR5P9eOPFOHzk3BaNY91FKwcSKyNUYac7xonJ/26R
         aNpIfW4OKRLxZxDABkPgouyezgKp0NvIko22Mr+G9gjGZRuzpL1Uh3v7hQMNj889Aget
         I2CZlKghD/4UY2NoVuZrYLPu0iZLQNzwGzVuUih/bLcZJT7qwO/uwnOaI5fe3S2eZ3d7
         BPdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711015639; x=1711620439;
        h=mime-version:user-agent:content-transfer-encoding:references
         :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=wds2+Ebidzro+sd+zz3DnIo232uII0R6cu41IMTPTog=;
        b=Lc/WN5+jr+zuHc/hqdVtGPlONi3c4g3bij01vvqn3pgJgrY2gkMHIuToAnr35Pqo/7
         zObLomzZrFBFRm3HDUJb8CtNDw0kzeLxzqDSw4f32vXastZHVrkpHLeato5ux7ZAAXl3
         SkaeeQ52io9ZUFXZmBB//YOg6UXnoWmOf5+3y3gOJOBPU//XrXKG2/lY39DyYdVGLK40
         3JHUHZTbiJYq2A+9oZghkOsjZgPFet2OdIOqfajhrgpwl5P4wWZ6SvaTo3qtCLnuP8qn
         /UVNgMbIJ62uQ09DqYQoX26tuMDPPr4gZaM7LHFzs5t7TedfuXm4QUYZ4ywiws0xcDAE
         jfCQ==
X-Forwarded-Encrypted: i=1; AJvYcCWnCm+gZ19IA8wIaAf4Kz4gYnSFwE/Gc+YlK9N6/QKHPjhUYFMdNix22E8afyBdE1FLA64J6veBz/J4Pnfcef0wajCEfm+0KZsZ66zcLAQ=
X-Gm-Message-State: AOJu0YwzYQp6EV86E0jCi7mKBdEjtRyifhVdG4gtoS0ekTWYh7tP1Zc9
	jPFaos6kbasluU4WPRGCSL3uwSM9b7h2K9mBQnDZaZBYk6NAMeIn
X-Google-Smtp-Source: AGHT+IGxJnQ0M1c70f8im62XWT/fL5WUxai52HXueCQCinbfTqlApMFT/IdSaHSj787wSS2Srg2ytQ==
X-Received: by 2002:a17:906:c446:b0:a46:5ee1:b9c with SMTP id ck6-20020a170906c44600b00a465ee10b9cmr1049562ejb.63.1711015639063;
        Thu, 21 Mar 2024 03:07:19 -0700 (PDT)
Message-ID: <6f9811f714d9f207409260851f2fef1f62f9cba8.camel@gmail.com>
Subject: Re: [PATCH v6 07/20] xen/riscv: introduce bitops.h
From: Oleksii 
To: Jan Beulich 
Cc: Alistair Francis , Bob Eshleman
 , Connor Davis , Andrew
 Cooper , George Dunlap
 ,  Julien Grall , Stefano
 Stabellini , Wei Liu , 
 xen-devel@lists.xenproject.org
Date: Thu, 21 Mar 2024 11:07:16 +0100
In-Reply-To: <9724aa80-106d-45ea-bad0-f0f2b83632eb@suse.com>
References: 
	 <14c91e2ba2aeb6e49f9f7e549232244719fa6959.1710517542.git.oleksii.kurochko@gmail.com>
	 <9724aa80-106d-45ea-bad0-f0f2b83632eb@suse.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.50.2 (3.50.2-1.fc39) 
MIME-Version: 1.0

On Wed, 2024-03-20 at 17:03 +0100, Jan Beulich wrote:
> On 15.03.2024 19:06, Oleksii Kurochko wrote:
> > Taken from Linux-6.4.0-rc1
> >=20
> > Xen's bitops.h consists of several Linux's headers:
> > * linux/arch/include/asm/bitops.h:
> > =C2=A0 * The following function were removed as they aren't used in Xen=
:
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * test_and_set_bit_lock
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * clear_bit_unlock
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * __clear_bit_unlock
> > =C2=A0 * The following functions were renamed in the way how they are
> > =C2=A0=C2=A0=C2=A0 used by common code:
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * __test_and_set_bit
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * __test_and_clear_bit
> > =C2=A0 * The declaration and implementation of the following functios
> > =C2=A0=C2=A0=C2=A0 were updated to make Xen build happy:
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * clear_bit
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * set_bit
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * __test_and_clear_bit
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * __test_and_set_bit
> > =C2=A0 * linux/include/asm-generic/bitops/generic-non-atomic.h with the
> > =C2=A0=C2=A0=C2=A0 following changes:
> > =C2=A0=C2=A0=C2=A0=C2=A0 * Only functions that can be reused in Xen wer=
e left;
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 others were removed.
> > =C2=A0=C2=A0=C2=A0=C2=A0 * it was updated the message inside #ifndef ..=
. #endif.
> > =C2=A0=C2=A0=C2=A0=C2=A0 * __always_inline -> always_inline to be align=
 with definition
> > in
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 xen/compiler.h.
> > =C2=A0=C2=A0=C2=A0=C2=A0 * update function prototypes from
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 generic___test_and_*(unsigned long=
 nr nr, volatile unsigned
> > long *addr)
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 to
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 generic___test_and_*(unsigned long=
 nr, volatile void *addr)
> > to be
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 consistent with other related macr=
os/defines.
> > =C2=A0=C2=A0=C2=A0=C2=A0 * convert identations from tabs to spaces.
> > =C2=A0=C2=A0=C2=A0=C2=A0 * inside generic__test_and_* use 'bitops_uint_=
t' instead of
> > 'unsigned long'
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 to be generic.
>=20
> This last middle level bullet point looks stale here here, with that
> header
> now being introduced in a separate patch.
>=20
> > --- /dev/null
> > +++ b/xen/arch/riscv/include/asm/bitops.h
> > @@ -0,0 +1,144 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/* Copyright (C) 2012 Regents of the University of California */
> > +
> > +#ifndef _ASM_RISCV_BITOPS_H
> > +#define _ASM_RISCV_BITOPS_H
> > +
> > +#include 
> > +
> > +#define BITOP_BITS_PER_WORD BITS_PER_LONG
> > +
> > +#define BITOP_TYPE
> > +typedef uint64_t bitops_uint_t;
> > +
> > +#include 
> > +
> > +#define __set_bit(n, p)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 set_bit(n, p)
> > +#define __clear_bit(n, p)=C2=A0=C2=A0=C2=A0 clear_bit(n, p)
>=20
> If these cam with a TODO, I wouldn't say anything. But without I take
> it
> they're meant to remain that way, at which point I'd like to ask
> about
> the performance aspect: Surely the AMO insns are more expensive than
> whatever more basic insns could be used instead? I'd even go as far
> as
> wondering whether
>=20
> #define __set_bit(n, p)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ((void)__test_and_s=
et_bit(n, p))
> #define __clear_bit(n, p)=C2=A0=C2=A0=C2=A0 ((void)__test_and_clear_bit(n=
, p))
>=20
> wouldn't be cheaper (the compiler would recognize the unused result
> and eliminate its calculation, I'm pretty sure).
It was implemented using atomic ops because of Arm:
/*
 * Non-atomic bit manipulation.
 *
 * Implemented using atomics to be interrupt safe. Could alternatively
 * implement with local interrupt masking.
 */
#define __set_bit(n,p)            set_bit(n,p)
#define __clear_bit(n,p)          clear_bit(n,p)

I though that the same comment is true for x86, but after your comment
I checked x86 implementation, I realized that x86 uses non-atomic
operations.

In this case, it seems to me there is a sense to use non-atomic for
RISC-V too.

> > +/* Based on linux/arch/include/asm/bitops.h */
> > +
> > +#if BITS_PER_LONG =3D=3D 64
> > +#define __AMO(op)=C2=A0=C2=A0 "amo" #op ".d"
> > +#elif BITS_PER_LONG =3D=3D 32
> > +#define __AMO(op)=C2=A0=C2=A0 "amo" #op ".w"
>=20
> This isn't in line with bitops_uint_t above. With BITOP_BITS_PER_WORD
> also expanding to BITS_PER_LONG, I think you mean to use unsigned
> long
> there. Or else you could move stuff into the conditional here (or
> really move the conditional here further up).
>=20
> However, if you look at Arm64 and x86 code, you will notice that they
> avoid 64-bit operations here. I'm afraid I can't easily tell whether
> the reason(s) for this have meanwhile disappeared; I fear some of
> that
> is still around.
>=20
> > +#else
> > +#error "Unexpected BITS_PER_LONG"
> > +#endif
> > +
> > +#define test_and_op_bit_ord(op, mod, nr, addr, ord)=C2=A0=C2=A0=C2=A0=
=C2=A0 \
> > +({=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 \
> > +=C2=A0=C2=A0=C2=A0 unsigned long res, mask;=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 \
> > +=C2=A0=C2=A0=C2=A0 mask =3D BITOP_MASK(nr);=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 \
> > +=C2=A0=C2=A0=C2=A0 __asm__ __volatile__ (=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 \
> > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 __AMO(op) #ord " %0, %2, %1=
"=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 \
> > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : "=3Dr" (res), "+A" (addr[=
BITOP_WORD(nr)])=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 \
> > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : "r" (mod(mask))=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 \
> > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : "memory");=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 \
> > +=C2=A0=C2=A0=C2=A0 ((res & mask) !=3D 0);=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 \
> > +})
> > +
> > +#define __op_bit_ord(op, mod, nr, addr, ord)=C2=A0=C2=A0=C2=A0 \
> > +=C2=A0=C2=A0=C2=A0 __asm__ __volatile__ (=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 \
> > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 __AMO(op) #ord " zero, %1, =
%0"=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 \
> > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : "+A" (addr[BITOP_WORD(nr)=
])=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 \
> > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : "r" (mod(BITOP_MASK(nr)))=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 \
> > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : "memory");
> > +
> > +#define test_and_op_bit(op, mod, nr, addr)=C2=A0=C2=A0=C2=A0 \
> > +=C2=A0=C2=A0=C2=A0 test_and_op_bit_ord(op, mod, nr, addr, .aqrl)
> > +#define __op_bit(op, mod, nr, addr) \
> > +=C2=A0=C2=A0=C2=A0 __op_bit_ord(op, mod, nr, addr, )
>=20
> Why are double underscores left on the non-test_and_ macros? Even
> without name space considerations that looks odd here, when talk
> is of the atomic forms of the operations, which by convention have
> no (double) underscore at their front.
Missed to update after Linux kernel. I'll take that into account.

>=20
> > --- a/xen/arch/riscv/include/asm/config.h
> > +++ b/xen/arch/riscv/include/asm/config.h
> > @@ -113,6 +113,8 @@
> > =C2=A0# error "Unsupported RISCV variant"
> > =C2=A0#endif
> > =C2=A0
> > +#define BITS_PER_BYTE 8
> > +
> > =C2=A0#define BYTES_PER_LONG (1 << LONG_BYTEORDER)
> > =C2=A0#define BITS_PER_LONG=C2=A0 (BYTES_PER_LONG << 3)
> > =C2=A0#define POINTER_ALIGN=C2=A0 BYTES_PER_LONG
>=20
> How's this addition related to the change at hand?
It should be a part of cmpxchg.h patch. Thanks.

~ Oleksii
>=20
> Jan



From xen-devel-bounces@lists.xenproject.org Thu Mar 21 10:18:09 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 10:18:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696296.1087113 (Exim 4.92)
	(envelope-from )
	id 1rnFUn-00052R-0D; Thu, 21 Mar 2024 10:18:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696296.1087113; Thu, 21 Mar 2024 10:18:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnFUm-00052K-Tr; Thu, 21 Mar 2024 10:18:00 +0000
Received: by outflank-mailman (input) for mailman id 696296;
 Thu, 21 Mar 2024 10:17:59 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnFUl-00052E-LF
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 10:17:59 +0000
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com
 [2a00:1450:4864:20::42e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4949fb00-e76c-11ee-a1ee-f123f15fe8a2;
 Thu, 21 Mar 2024 11:17:57 +0100 (CET)
Received: by mail-wr1-x42e.google.com with SMTP id
 ffacd0b85a97d-33ececeb19eso414165f8f.3
 for ; Thu, 21 Mar 2024 03:17:57 -0700 (PDT)
Received: from [192.168.2.1] (82-64-138-184.subs.proxad.net. [82.64.138.184])
 by smtp.googlemail.com with ESMTPSA id
 u8-20020a5d4688000000b0033e3c4e600asm16990081wrq.7.2024.03.21.03.17.55
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 21 Mar 2024 03:17:56 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4949fb00-e76c-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=rabbit-lu.20230601.gappssmtp.com; s=20230601; t=1711016276; x=1711621076; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:references:cc:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=7B1NwdKQNT344Q68FFSdw+cjq3T6sd7FqhjShBG2N58=;
        b=eyfPdlhwSA/UTo6qSHUpvCV1uS7Ha7NZN7xrNQXCXCz303XTyPjeSiyWwVIqalcyb0
         YTTlLgHwmYIyrduV+HwTBsHvldw8ToAqOkfhiMScBTyQi1AomDCtDVmuwn1tcg3VSh7Q
         Di37X/Yc8F7TsxCg1oYD5vKJpljFisuMmTZWKH2mz6RZMhZaNZu5+pBgc+Sjwz4mRr8J
         uJeb5OpBZvbkQ5zBoyBkMKUoWXdTlD8hFEbNCARvunexVEgqZizM7Fql3nvh6nwaT4ry
         zED1i0EXTL7/YU0zuja+bJ27ULk4mcPLeQUXctIeH3NkFoyArV/6GpjNYxSB9LGK4B+a
         I2+w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711016276; x=1711621076;
        h=content-transfer-encoding:in-reply-to:from:references:cc:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=7B1NwdKQNT344Q68FFSdw+cjq3T6sd7FqhjShBG2N58=;
        b=KPYqyP87KgFgHHu/mFj1lvFtbhzYb23nWfjkAHBs6jGqYYCXIO8rG9a8sQTOvdblWS
         GCTFogNXBdeV1yCQSNPQI18TWs7AxlPb5bQYbY0dN/q5hdcvT96oOoQuWxPrfeWXxd9X
         pemEHgQ7jnMcroPOL0pgnaBa3JkfTJnoJ2jg2JMeHnZcuZBYUsMhXakltIk/JqB8MEzM
         csa1EKLMfBuUaJfXfUXH7ozQMU0oYLGFRCR4m6hZK6QZ6A1yZqLdGXZgVv4WZT6aEB5B
         cBi+4UqIoaoIOq4kewc8I47Yuxkg9+9Nbcg0zovESgA5lCwtjb89V3wADkkrFz6EDZEb
         QPXg==
X-Gm-Message-State: AOJu0YxgUb2lvJCE+M67WJojQJeHEBgh1/EO+Q8Bz6AKL3pRZ9dIXd44
	ANv6bSb4mf7S1emoA3c11Cs0z9jjxkiZP36+EDLGJWehHcF7n48i1TsfrXjPtBg=
X-Google-Smtp-Source: AGHT+IHgSDnnDHZ1tvLGQMN6gwzMryuQnDRQQlN6Bmd/5q500BcuQZSa+1ZZdPQmfGau041j6UJ2CA==
X-Received: by 2002:a5d:4bc5:0:b0:33e:aab0:9984 with SMTP id l5-20020a5d4bc5000000b0033eaab09984mr1306799wrt.24.1711016276389;
        Thu, 21 Mar 2024 03:17:56 -0700 (PDT)
Message-ID: 
Date: Thu, 21 Mar 2024 11:17:55 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] docs/man: add shutdown reasons to xl (list) man page
Content-Language: en-US
To: Anthony PERARD 
Cc: xen-devel@lists.xenproject.org, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Wei Liu 
References: <0a2fcad111622431b8cd54c69adc3dedd24fb572.1709910923.git.slack@rabbit.lu>
 
From: zithro 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 20 Mar 2024 17:08, Anthony PERARD wrote:
> On Fri, Mar 08, 2024 at 04:19:20PM +0100, zithro / Cyril Rébert wrote:
>> Questions (unblocking):
>>   - why a double space between all sentences ?
> 
> It's an English thing maybe?
> 
> Wikipedia has an article about it: https://en.wikipedia.org/wiki/Sentence_spacing
> But actually, single space seems like it used to be a french thing, even
> called "French spacing":
> https://en.wikipedia.org/wiki/History_of_sentence_spacing#French_and_English_spacing
> 
> I guess it doesn't really matter. I don't really pay attention to it
> anyway.

Thanks for the links !
 From "https://en.wikipedia.org/wiki/Sentence_spacing#Computer_era" :
- "text-editing [...] in Emacs by default uses a double space following 
a period"
- "Troff uses two spaces to mark the end of a sentence"

I guess we at least know why ? :) Many man pages (not only Xen's) use 
double spaces. I just copied the format, good to know it's not 
mandatory. Let's save disk space, one space at a time.

(For fun, another quote from wiki : "Varying the spacing between 
sentences, and using the changing spacing to encode information, are a 
standard method of steganography, hiding secret information in public 
documents", so ... what are you doing guys ? ^^).


>>   - how to get a "simple LF" ? Ie. I want to use 
, not 

>>     (a simple  has no effect, a double renders a 
)
> 
> That doesn't look to be possible, unless you actually managed to write
> the paragraph for all targeted formats, with things like =begin html...,
> but that would probably make things more complicated that necessary.

Ok, nevermind then.
By the way, are "raw text" files (*.txt) still accepted as docs ?

> 
>> ---
>> diff --git a/docs/man/xl.1.pod.in b/docs/man/xl.1.pod.in
>> index bed8393473..d37227ba58 100644
>> --- a/docs/man/xl.1.pod.in
>> +++ b/docs/man/xl.1.pod.in
>> @@ -370,12 +370,50 @@ scheduling by the Xen hypervisor.
>>   The guest OS has shut down (SCHEDOP_shutdown has been called) but the
>>   domain is not dying yet.
>>   
>> -=item B
>> +There are six shutdown reasons, which will be displayed after the "s" : B<-rscwS>.
>> +
>> +Note that some states will only be displayed if "on_poweroff=preserve" is set in
>> +the config file, see L).
>> +
>> +=over 4
>> +
>> +=over 4
>> +
>> +=item B
>> +
>> +The domain exited normally, it will get destroyed.
>> +
>> +=item B
>> +
>> +The domain will reboot.
> 
> Well, that's not really true. I think to end up in this state, what
> happen is that the domain shutdown and ask for a reboot. It's normally
> the toolstack job to cleanup the domain then create a new domain for the
> guest. I guess you might see this state if you have "on_reboot=preserve"
> or you run `xl list` at the right time. Or the toolstack crashed and

(one may also use 'watch -n 1 xl list' to "follow states" during tests)

> fail to kill the domain before a reboot. So maybe a better to have
> something like "The domain exited normally and ask for a reboot."

Ok, will rephrase ! Although I'd have agreed you'd do such changes while 
committing, you better know the terminology than me ! ;)

> 
> Same things for the other entries (poweroff and watchdog). The status is
> just the current status of what is supposed to happen. But a few things
> might mean that the domain stay in that state unless the admin does
> something. This could be simply because there's "on_*=preserve" setting,
> the toolstack crashed or we just happen to look while the toolstack is
> cleaning thing up.

I also wanted to "normalize" the shutdown statuses between 'xl list' and 
'xl top'. I mainly use (and dev a bit in) xentop, and realized the 
shutdown statuses are not shown (only "s", not "sX").

> 
>> +=item B
>> +
>> +The domain is suspended to disk or to RAM. If suspended to disk, the domain will
>> +get destroyed.
> 
> I think in that state, the domain is just suspended, maybe to RAM? I
> don't know if suspend to disk would end up in this state, my guess is
> the domain will go to "poweroff" instead. But for suspend to "RAM", I
> think the toolstack is supposed to save the guest memory and guest
> config somewhere, maybe even on a different host for live migration?
> 
> This is a state that seems to happen as part of a live migration (or `xl
> save` I guess).
> 
> I tried to suspend a guest (runnning `systemd suspend`), but xl never
> reported `ss`, because there's nothing to do I guess. So this state is
> probably really about migration.

I'm not sure if you have seen my other patch "Add suspend-to-ram to xl" 
(posted 29 february, no answers yet).
It allows for a domain to be suspended from dom0, without systemd, using 
libxl. Libvirt can do this, and Qubes is using it to suspend domUs 
before suspending dom0.
It works, and better than pause/unpause for the domU, but there's a bug 
later, the domains don't get "destroy"ed after a correct shutdown, need 
to 'xl destroy' manually. I talked a bit about that on XenDevel, but 
didn't get a correct answer, so the patch is stalled ...

Anyways, "ss" would be seen in both cases, if I correctly read the code 
Roger showed me (I cannot use live migration) there is only one 
"suspend" reason.

Meanwhile, will provide v3 !

> 
> 
> Thanks,
> 

-- 
++
zithro / Cyril



From xen-devel-bounces@lists.xenproject.org Thu Mar 21 10:18:31 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 10:18:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696298.1087124 (Exim 4.92)
	(envelope-from )
	id 1rnFVH-0005ZW-Ae; Thu, 21 Mar 2024 10:18:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696298.1087124; Thu, 21 Mar 2024 10:18:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnFVH-0005ZP-7o; Thu, 21 Mar 2024 10:18:31 +0000
Received: by outflank-mailman (input) for mailman id 696298;
 Thu, 21 Mar 2024 10:18:30 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnFVG-0005Z6-2u
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 10:18:30 +0000
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com
 [2a00:1450:4864:20::62d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5be6351a-e76c-11ee-afe0-a90da7624cb6;
 Thu, 21 Mar 2024 11:18:28 +0100 (CET)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-a46d0a8399aso316917966b.1
 for ; Thu, 21 Mar 2024 03:18:28 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 lg21-20020a170906f89500b00a46cc25b550sm4012866ejb.5.2024.03.21.03.18.26
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 21 Mar 2024 03:18:26 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5be6351a-e76c-11ee-afe0-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711016307; x=1711621107; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=RiWCV8tVWxNCerrDRbBLR5n2ELqhTqhTtlciIkOJnzg=;
        b=RZWrbazLFUPzi6rdDrtOVbODtcmERMeb7IHmhEltpfC9JaOQvAEaCM3I6nQoO2dvFi
         +aXhXqMmpoYfGrlDxWV6D+mgw8j7Job5G6bzy5iAq7ewxa+SbmB5vOUihOmy/9BEqHef
         cobzlxFxVnPnTCpaQuRmrJz2GRWfywf6TSpWfUu+swjzaOzUk1sMqu/mfbCgDNgWCyjJ
         +6XD5sd0wdpvbRBWfld4BOMxi6QfPBfzuCzsRew3R2OurmQz63fA81v8SCDYdg9Eh3e5
         SlR3PlIjCO+rQdK3mq88i78ZhgwToYlsNQC5knkeLbIyR0mPePk/PKLOzfvdLvvcEO1J
         pRww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711016307; x=1711621107;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=RiWCV8tVWxNCerrDRbBLR5n2ELqhTqhTtlciIkOJnzg=;
        b=SzUZSbYvsSYUkDmxP15mG+p4BRe9xnydqmW0fbNuxFqOEy6VkrwliZRF/zCkyp7uJl
         OfGE7CrFFUmdM2qXnRDVQ1WKsz8I5Fd+/qk9HqY+0WInN3H4gV7qqvy5KhBJwmN8W8ZD
         mZsBVRPSHy6Todo6LSe0wDM0szlXeXRhkLxGUU3Y0sjCRpxwXoWXCyvQd3JZHyAN6XX3
         eirrnCNMvxpasZano2oxEmlujtNYVV9WF8s8ZNGGY/XiCRgBEpgS/MuPSK5dKUt1tehW
         Fy2vcIRYV1DxbdXLg/PeBWgO/UYQVobMSbu8MKbseU8opArw+id1fqrXHBhYz2bMTahu
         BJ+w==
X-Forwarded-Encrypted: i=1; AJvYcCV1xcTm7yp77qqIvG8sugw5NoXh22eC7JC4MQOXDT5n+ybtUGuCJn8+ECUrz/myA23wApB5kFzy9m/aS3zwds3OYCOVYI2tMMVMjagFn+k=
X-Gm-Message-State: AOJu0YyzjmqILpKvI0J7uiHU/Lkyt7ySdZ5RhocB7Edh3RM1Z57KbBr0
	qSBJ5V7UKWhxyMUTTVXF/UsVMC7/STBPp95bk7JSJ3kMp9bJnZkpErYpwKGdgPBWoQ9DZRxDwOA
	=
X-Google-Smtp-Source: AGHT+IHURNlhYI9sevEiBZd+FNrKqtyMa+CjSO0pGFlbIFotIgZ1/xjkMMK1BI2UN2JHggsYc8mFnw==
X-Received: by 2002:a17:907:9952:b0:a46:d04b:66e7 with SMTP id kl18-20020a170907995200b00a46d04b66e7mr1880034ejc.25.1711016307549;
        Thu, 21 Mar 2024 03:18:27 -0700 (PDT)
Message-ID: 
Date: Thu, 21 Mar 2024 11:18:25 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/vcpu: relax VCPUOP_initialise restriction for non-PV
 vCPUs
Content-Language: en-US
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 xen-devel@lists.xenproject.org
References: <20240320135720.68894-1-roger.pau@citrix.com>
 <73314dc5-0145-4aa7-a3cd-23c943235392@suse.com> 
 <4cc5d746-a50c-4819-a56e-512abf797ef2@suse.com> 
  
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 21.03.2024 10:57, Roger Pau Monné wrote:
> On Thu, Mar 21, 2024 at 10:17:25AM +0100, Jan Beulich wrote:
>> On 21.03.2024 10:10, Roger Pau Monné wrote:
>>> On Thu, Mar 21, 2024 at 09:07:10AM +0100, Jan Beulich wrote:
>>>> On 20.03.2024 17:29, Roger Pau Monné wrote:
>>>>> On Wed, Mar 20, 2024 at 04:09:33PM +0100, Jan Beulich wrote:
>>>>>> On 20.03.2024 14:57, Roger Pau Monne wrote:
>>>>>>> There's no reason to force HVM guests to have a valid vcpu_info area when
>>>>>>> initializing a vCPU, as the vCPU can also be brought online using the local
>>>>>>> APIC, and on that path there's no requirement for vcpu_info to be setup ahead
>>>>>>> of the bring up.  Note an HVM vCPU can operate normally without making use of
>>>>>>> vcpu_info.
>>>>>>
>>>>>> While I'd agree if you started with "There's no real need to force ...", I
>>>>>> still think there is a reason: If one wants to use paravirt interfaces (i.e.
>>>>>> hypercalls), they would better do so consistently. After all there's also
>>>>>> no need to use VCPUOP_initialise, yet you're not disabling its use.
>>>>>>
>>>>>> As said in reply to Andrew's reply, besides acting as a sentinel that
>>>>>> structure instance also acts as a sink for Xen accesses to a vCPU's
>>>>>> vcpu_info. By removing the check, you switch that from being a safeguard to
>>>>>> being something that actually has to be expected to be accessed. Unless
>>>>>> you've audited all uses to prove that no such access exists.
>>>>>
>>>>> I'm kind of lost in this last paragraph, how is that different than
>>>>> what currently happens when an HVM vCPU >= 32 is brought up using the
>>>>> lapic and has no vpcu_info mapped?
>>>>
>>>> I think this aspect was simply missed back at the time. And I think it
>>>> wants mentioning explicitly to justify the change.
>>>
>>> OK, I can add to the commit message:
>>>
>>> "Note an HVM vCPU can operate normally without making use of
>>> vcpu_info, and in fact does so when brought up from the local APIC."
>>
>> I'd be fine adding this (or having this added) while committing.
>>
>>>> As said in reply to Andrew, I don't think the dummy structure can be got
>>>> rid of. Nor can the checks here be (easily) removed altogether, i.e. your
>>>> change cannot (easily) be extended to PV as well. Even conditional removal
>>>> of the structure in !PV builds would first require all vcpu_info accesses
>>>> to gain a suitable conditional. Which may be undesirable, as some of these
>>>> may be deemed fast paths.
>>>
>>> I didn't intended to do this here, as replied to Andrew.  If we want
>>> to get rid of the check for PV also it needs to be done in a different
>>> patch, and with a different justification and analysis.
>>>
>>>>> Also, from a quick look it seems like sites do check whether vcpu_info
>>>>> == dummy_vcpu_info, otherwise we would already be in trouble.
>>>>
>>>> Such checks exist in code managing vcpu_info, but not - afaics - in places
>>>> actually accessing it.
> 
> Is there anything else that needs adjusting then, or are you happy to
> pick this up and adjust the commit message?

I'll pick this up and adjust (unless Andrew beats me).

Jan


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 10:28:39 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 10:28:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696308.1087133 (Exim 4.92)
	(envelope-from )
	id 1rnFf0-0007yB-95; Thu, 21 Mar 2024 10:28:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696308.1087133; Thu, 21 Mar 2024 10:28:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnFf0-0007y4-6c; Thu, 21 Mar 2024 10:28:34 +0000
Received: by outflank-mailman (input) for mailman id 696308;
 Thu, 21 Mar 2024 10:28:32 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnFey-0007v6-CS
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 10:28:32 +0000
Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com
 [2a00:1450:4864:20::52f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c357be32-e76d-11ee-afe0-a90da7624cb6;
 Thu, 21 Mar 2024 11:28:31 +0100 (CET)
Received: by mail-ed1-x52f.google.com with SMTP id
 4fb4d7f45d1cf-568a19fcc4eso434006a12.1
 for ; Thu, 21 Mar 2024 03:28:31 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 v17-20020a056402175100b005651ae4ac91sm7877339edx.41.2024.03.21.03.28.30
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 21 Mar 2024 03:28:30 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c357be32-e76d-11ee-afe0-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711016910; x=1711621710; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=j4/qTjYH1DcwTd8nnRm9/64Pym/nMZHZd2o2KLS/ULM=;
        b=KT++fGrhVVmyaZdDthcgZHRPnxm2Mv0u2Wa9nSB00BJOe7NkuB4bx9o81oGvnfLYOb
         cRM8PMpMd2fI8fRIdrPtC1qFrP+nwrI8V0dboP5DLwG92CrCCG4OhvDIJfZA/5uRtfD2
         rjja/bmuZ0WKmRTH2vBKKc/HcrvwIpQ2XqTUtW09h0uS8dH72rjQTFwZL+YNbQMqL/hF
         OQjyY3hustY+rbPL4DPt5A+C9/2je5ZZbheWDZ6cuMr7zaVapufqSqVb6Rrw4R0yWx5U
         0ZoqYrCHU0p4HygxMUkbX3tSRsDYDolk4rFkPc1//Lj3vn82wPxEui9bSjJYbDLdXdAU
         SXTw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711016910; x=1711621710;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=j4/qTjYH1DcwTd8nnRm9/64Pym/nMZHZd2o2KLS/ULM=;
        b=KaJV8fETT7P7p1yisoi7e5Oz/ii6kVSy4NAWDOjZEg8W+j6waOqt8aNqmg97UfOpQi
         s29hwqz8ZG07CIkIAbecdptVrA4B40Qlzna+m8N/1BsLKhB14kVxn2B/qVc+X6QTB3OD
         yF2hwmUL0UII8kKabWa2SS8NKidDDcgVpe72OFcv55ce5JQaM6RZm4AbwfpyCgDj8NQM
         a2yGTbqyIagpjKM/YVdTIE+57xyjfUrAsZV4GqxeSVjevuGp/RCGRmzTL5gKzG5k/yIK
         9UYTizWVkPOL0GvdewzAhAFqYxdQtj06LWlFHR1jYUTQS3+X8CkyarlCevsJaeVxGTdU
         VCZQ==
X-Forwarded-Encrypted: i=1; AJvYcCVWADzJPGqR094X1KBdsGka6uyv5h+u4iRn6Ti1Z2gpOST1UvFlo7vBuXd/cTYYP2CdiJ/1qn7JIOLPdZtUrrHkjZZ3HUXMH8HMjwJizJw=
X-Gm-Message-State: AOJu0YxF0Nkd+41mzkK5VN8vPnBc99jfIm7HcZHUgQWI0Wsie2zSUF3z
	reh5iPCs3hePNpWr6QjyYLe39VnZhr/QD/BQ+Tk3PMBwQrF4WERwhGjWspafVg==
X-Google-Smtp-Source: AGHT+IE7XIzxMCsswS2aaOtbzCWPCCLvruC4rCngVjiIw6Zethxd4ob9oUolE4PZ8GGnkPtuqqBekg==
X-Received: by 2002:a50:d75d:0:b0:568:d7fe:a768 with SMTP id i29-20020a50d75d000000b00568d7fea768mr1507405edj.25.1711016910561;
        Thu, 21 Mar 2024 03:28:30 -0700 (PDT)
Message-ID: <3fe788d3-3c49-4298-bd81-66fbb805bf91@suse.com>
Date: Thu, 21 Mar 2024 11:28:29 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 07/20] xen/riscv: introduce bitops.h
Content-Language: en-US
To: Oleksii 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 xen-devel@lists.xenproject.org
References: 
 <14c91e2ba2aeb6e49f9f7e549232244719fa6959.1710517542.git.oleksii.kurochko@gmail.com>
 <9724aa80-106d-45ea-bad0-f0f2b83632eb@suse.com>
 <6f9811f714d9f207409260851f2fef1f62f9cba8.camel@gmail.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <6f9811f714d9f207409260851f2fef1f62f9cba8.camel@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 21.03.2024 11:07, Oleksii wrote:
> On Wed, 2024-03-20 at 17:03 +0100, Jan Beulich wrote:
>> On 15.03.2024 19:06, Oleksii Kurochko wrote:
>>> --- /dev/null
>>> +++ b/xen/arch/riscv/include/asm/bitops.h
>>> @@ -0,0 +1,144 @@
>>> +/* SPDX-License-Identifier: GPL-2.0 */
>>> +/* Copyright (C) 2012 Regents of the University of California */
>>> +
>>> +#ifndef _ASM_RISCV_BITOPS_H
>>> +#define _ASM_RISCV_BITOPS_H
>>> +
>>> +#include 
>>> +
>>> +#define BITOP_BITS_PER_WORD BITS_PER_LONG
>>> +
>>> +#define BITOP_TYPE
>>> +typedef uint64_t bitops_uint_t;
>>> +
>>> +#include 
>>> +
>>> +#define __set_bit(n, p)      set_bit(n, p)
>>> +#define __clear_bit(n, p)    clear_bit(n, p)
>>
>> If these cam with a TODO, I wouldn't say anything. But without I take
>> it
>> they're meant to remain that way, at which point I'd like to ask
>> about
>> the performance aspect: Surely the AMO insns are more expensive than
>> whatever more basic insns could be used instead? I'd even go as far
>> as
>> wondering whether
>>
>> #define __set_bit(n, p)      ((void)__test_and_set_bit(n, p))
>> #define __clear_bit(n, p)    ((void)__test_and_clear_bit(n, p))
>>
>> wouldn't be cheaper (the compiler would recognize the unused result
>> and eliminate its calculation, I'm pretty sure).
> It was implemented using atomic ops because of Arm:
> /*
>  * Non-atomic bit manipulation.
>  *
>  * Implemented using atomics to be interrupt safe. Could alternatively
>  * implement with local interrupt masking.
>  */
> #define __set_bit(n,p)            set_bit(n,p)
> #define __clear_bit(n,p)          clear_bit(n,p)
> 
> I though that the same comment is true for x86, but after your comment
> I checked x86 implementation, I realized that x86 uses non-atomic
> operations.
> 
> In this case, it seems to me there is a sense to use non-atomic for
> RISC-V too.

Hmm, wait: There's an important difference between x86 on one side and
Arm/RISC-V/PPC and various other more or less RISC-like ones on the other.
x86 has read-modify-write (memory) insns. Therefore even without using
their atomic (LOCKed) forms, they do the update atomically as far as the
local CPU is concerned. That's not the case when you need to use a three
(or more) step load-op-store sequence.

Had you retained Arm's comment, I probably wouldn't even have asked.
Please add such a comment while sticking to this aliasing you have.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 10:41:25 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 10:41:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696316.1087143 (Exim 4.92)
	(envelope-from )
	id 1rnFrK-0003Ga-HZ; Thu, 21 Mar 2024 10:41:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696316.1087143; Thu, 21 Mar 2024 10:41:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnFrK-0003GT-El; Thu, 21 Mar 2024 10:41:18 +0000
Received: by outflank-mailman (input) for mailman id 696316;
 Thu, 21 Mar 2024 10:41:16 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnFrI-0003GL-CA
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 10:41:16 +0000
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com
 [2a00:1450:4864:20::629])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8ac267ac-e76f-11ee-afe0-a90da7624cb6;
 Thu, 21 Mar 2024 11:41:15 +0100 (CET)
Received: by mail-ej1-x629.google.com with SMTP id
 a640c23a62f3a-a46de423039so47841166b.0
 for ; Thu, 21 Mar 2024 03:41:15 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 q1-20020a056402040100b00568d762cb5asm4702737edv.35.2024.03.21.03.41.14
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 21 Mar 2024 03:41:14 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8ac267ac-e76f-11ee-afe0-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711017674; x=1711622474; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=aQwUxv85k60jx5TCPnj8y+/xwbLQvv8der3jLm2oF+Y=;
        b=Hni+ZtQPjrAYGqw1YlRNvDFrPneEMkBkTOK/KsDXg+ovmgN1oKvBxwTQsUYhYTEgUz
         oHgVEuGOHwpdVgUV8tpEV7nl1WjFnlTyhzUPCu6jo65TUX4USoQmirdTle6IB1a8cGMp
         kCtp9XOqs+xRUBdsLHxYDC1GKg/TptxbNyn0mTlVOHVd390HBomu2MngmbBD1VOCln72
         zrvNg0eywWoB9r2SDkZr101wzZ+0nYmIytv2SCMPq6aEvIYDg82wsPCEEWx2NYByC8tB
         k+IMDzCWfdDBTtjzkHk/hPSbDkExUhqKkojkrhttzl2lhE/JfYkALzKoxoFXHqe9wYGI
         sNNw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711017674; x=1711622474;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=aQwUxv85k60jx5TCPnj8y+/xwbLQvv8der3jLm2oF+Y=;
        b=UOrAMSwxldnK6TE8JywT2AeUWbyfIgr6DCIm4JhjGhKYoHHacf2jL3AxjAiQLSr2+I
         cr12VhBUs7SPiBsDk3s91vBtS44tRoWojr6EzWHnIAw8VA/rI9akCqOpVR/RIRE9BR4t
         MoZ8LJZ3X1snMUhubF8UQ/cDkAJSn6SjxochWyBabyJM07ZNa9Sqp/a2q/YadzqX7lQc
         9UhCvXy4RGvywx1k6HfVeuJaHgd4OIcsohrpAyBg10tswPmNmeh+jtS483b0ke3dOuki
         1oUFFulgEGr84mbz8TBXvmgnt7CrDeC2rV3xgD/1kNOWwH8CTS7z4uRfMjXQvXfecuAs
         XGCA==
X-Forwarded-Encrypted: i=1; AJvYcCV29qKffdKYX+71lMG09Ikdwn+5ScBDOXSKXcG9KA4eq5OsuxMopRju4Uc1Rv857Zddzsb2NTcJsekNSgM2vOVAO4DIt8iecwUrjdJBP1M=
X-Gm-Message-State: AOJu0YxRQ1VpB/58c90fOn+mB/9gvqKIVhk8EdNCA86r1vdJTnRBUBpT
	mlKWq7IBFH2JgXAtTbjl3uv9v9aDUd5wy1aUfn2LvdwuqyNLIqo/vbj8BCRzoQ==
X-Google-Smtp-Source: AGHT+IGZvCNiVLqj8Et8fkvJhc/PjrGXQecbgdGxoAnjv2w2ewK6Xlgi0OwgbRSMmlufRyMvGQLbXw==
X-Received: by 2002:a50:bae3:0:b0:56b:986b:b4e7 with SMTP id x90-20020a50bae3000000b0056b986bb4e7mr1502013ede.27.1711017674526;
        Thu, 21 Mar 2024 03:41:14 -0700 (PDT)
Message-ID: <6a9ab81f-451f-46bd-a875-b30eddc9a716@suse.com>
Date: Thu, 21 Mar 2024 11:41:13 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 2/3] AMD-Vi: Disable IOMMU if cx16 isn't supported
Content-Language: en-US
To: Teddy Astie 
Cc: Andrew Cooper ,
 xen-devel@lists.xenproject.org, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 
References: 
 <9c825255af5d3973b29c85cb6856c67b69aa0e4a.1711016106.git.teddy.astie@vates.tech>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <9c825255af5d3973b29c85cb6856c67b69aa0e4a.1711016106.git.teddy.astie@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 21.03.2024 11:28, Teddy Astie wrote:
> No hardware has VT-d support while not having cx16 support, consider disabling IOMMU in this case to avoid potentially buggy code.

VT-d? That's Intel, not AMD. Also alongside bare hardware you also want to
not completely leave out Xen running virtualized itself.

As a nit, please limit description lines to 80 chars.

> --- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
> +++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
> @@ -312,6 +312,12 @@ static int __init cf_check iov_detect(void)
>          return -ENODEV;
>      }
>  
> +    if ( unlikely(!cpu_has_cx16) )
> +    {
> +        printk("AMD-Vi: CPU doesn't support CMPXCHG16B, disabling\n");
> +        return -ENOSYS;

ENOSYS has a dedicated purpose and hence doesn't fit here. If no better
suitable error code can be identified, ENODEV is perhaps what ought to be
used.

I'd also like to note that while this says 2/3, I can't spot any other
part of such a 3-patch series anywhere. However, in particular
https://lists.xen.org/archives/html/xen-devel/2024-03/threads.html looks
to be lagging anyway.

Further please note that maintainership recently has changed some; please
make sure you use up-to-date information for composing the Cc: list.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 10:41:27 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 10:41:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696304.1087153 (Exim 4.92)
	(envelope-from )
	id 1rnFrT-0003Wv-OZ; Thu, 21 Mar 2024 10:41:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696304.1087153; Thu, 21 Mar 2024 10:41:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnFrT-0003Wm-M4; Thu, 21 Mar 2024 10:41:27 +0000
Received: by outflank-mailman (input) for mailman id 696304;
 Thu, 21 Mar 2024 10:28:30 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rnFew-0007v6-ND
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 10:28:30 +0000
Received: from mail135-12.atl141.mandrillapp.com
 (mail135-12.atl141.mandrillapp.com [198.2.135.12])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c1b71590-e76d-11ee-afe0-a90da7624cb6;
 Thu, 21 Mar 2024 11:28:29 +0100 (CET)
Received: from pmta14.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1])
 by mail135-12.atl141.mandrillapp.com (Mailchimp) with ESMTP id
 4V0hWG40jdz705xhc
 for ; Thu, 21 Mar 2024 10:28:26 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 b011fbae99164ddc94c4654e4770f1fb; Thu, 21 Mar 2024 10:28:26 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c1b71590-e76d-11ee-afe0-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1711016906; x=1711277406;
	bh=yNxbTqH2YJSkOiphdTLQC16uPnEcVvW/4yCo8FASxpc=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=GrXDwdCVooZpyvoMeitKyaQInEHVkymkKLBQm/8/YFPW1agW77sofv8ykeXjEho8g
	 u5SimoOzD2MoVVfYUSRwcqSgr4Fam1Ng0pi3BZB2o9NQfxijQV7BOKV06LZy2Cu+NU
	 NYeP87ojRy8A5zPoRQFh20LbtTWr887n1D1wtdInwzi3t2CQ+x1Pb2p3oOL6EV9jm0
	 pAbHMKWOLj3bzc/CnzE1uhctbPCVv5Hx51E7PzVeZnaAy4/WXI2sFgVSQpSIs0Xc5r
	 PfrLJOj5W49FZNJ+vgKoacoFnUaY/xhlX2NPKk7AdmNi13f3ylov/xuC1nImaMI/TN
	 NK7Kv4M3SV76g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1711016906; x=1711277406; i=teddy.astie@vates.tech;
	bh=yNxbTqH2YJSkOiphdTLQC16uPnEcVvW/4yCo8FASxpc=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=etazsW80scRAm8wHgdOSjH8kDbgDAeyvUpZMos0tZ0mdDJ0LzAuy5cMyeZvH+WmCp
	 rOqPtGtgryoMAAUvO6DoxuB4N35asD8zQHbffmX+3n9mX2Sgv4pkKAKBjdqJWMavW1
	 1Oss5ZpBCetnSacpcTggDFiRBou0uv0KDxdGHVbGYgrE3SBOtDMuA99NMzvdR4HWDD
	 fpYwAhye6BnLblvkAU5RyH2n5Fj8QFTb/mRKIJ9+A6GR2WZ1M50137sbBmVtaeKc57
	 13QwqXX260rq3QXmdC4TPEjcTCEC1dmxuohLdSuj0+kXYHCwz70mLXZNuouybF+/m0
	 R/70vpZbnFc4Q==
From: Teddy Astie 
Subject: =?utf-8?Q?[XEN=20PATCH=201/3]=20VT-d:=20Disable=20IOMMU=20if=20cx16=20isn't=20supported?=
X-Mailer: git-send-email 2.44.0
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1711016905606
To: xen-devel@lists.xenproject.org
Cc: Teddy Astie , Kevin Tian 
Message-Id: 
In-Reply-To: 
References: 
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.b011fbae99164ddc94c4654e4770f1fb?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20240321:md
Date: Thu, 21 Mar 2024 10:28:26 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

No hardware has VT-d support while not having cx16 support, consider disabling IOMMU in this case to avoid potentially buggy code.

Now that IOMMU is only enabled if cx16 is supported, drop dead code that handles cases where cx16 isn't supported.

Signed-off-by Teddy Astie 
---
 xen/drivers/passthrough/vtd/intremap.c | 67 +++++----------------
 xen/drivers/passthrough/vtd/iommu.c    | 80 +++++++++-----------------
 2 files changed, 41 insertions(+), 106 deletions(-)

diff --git a/xen/drivers/passthrough/vtd/intremap.c b/xen/drivers/passthrough/vtd/intremap.c
index c504852eb8..312b73e693 100644
--- a/xen/drivers/passthrough/vtd/intremap.c
+++ b/xen/drivers/passthrough/vtd/intremap.c
@@ -173,47 +173,26 @@ bool __init cf_check intel_iommu_supports_eim(void)
  * Assume iremap_lock has been acquired. It is to make sure software will not
  * change the same IRTE behind us. With this assumption, if only high qword or
  * low qword in IRTE is to be updated, this function's atomic variant can
- * present an atomic update to VT-d hardware even when cmpxchg16b
- * instruction is not supported.
+ * present an atomic update to VT-d hardware.
  */
 static void update_irte(struct vtd_iommu *iommu, struct iremap_entry *entry,
                         const struct iremap_entry *new_ire, bool atomic)
 {
-    ASSERT(spin_is_locked(&iommu->intremap.lock));
-
-    if ( cpu_has_cx16 )
-    {
-        __uint128_t ret;
-        struct iremap_entry old_ire;
+    __uint128_t ret;
+    struct iremap_entry old_ire;
 
-        old_ire = *entry;
-        ret = cmpxchg16b(entry, &old_ire, new_ire);
+    ASSERT(spin_is_locked(&iommu->intremap.lock));
+    
+    old_ire = *entry;
+    ret = cmpxchg16b(entry, &old_ire, new_ire);
 
-        /*
-         * In the above, we use cmpxchg16 to atomically update the 128-bit
-         * IRTE, and the hardware cannot update the IRTE behind us, so
-         * the return value of cmpxchg16 should be the same as old_ire.
-         * This ASSERT validate it.
-         */
-        ASSERT(ret == old_ire.val);
-    }
-    else
-    {
-        /*
-         * VT-d hardware doesn't update IRTEs behind us, nor the software
-         * since we hold iremap_lock. If the caller wants VT-d hardware to
-         * always see a consistent entry, but we can't meet it, a bug will
-         * be raised.
-         */
-        if ( entry->lo == new_ire->lo )
-            write_atomic(&entry->hi, new_ire->hi);
-        else if ( entry->hi == new_ire->hi )
-            write_atomic(&entry->lo, new_ire->lo);
-        else if ( !atomic )
-            *entry = *new_ire;
-        else
-            BUG();
-    }
+    /*
+     * In the above, we use cmpxchg16 to atomically update the 128-bit
+     * IRTE, and the hardware cannot update the IRTE behind us, so
+     * the return value of cmpxchg16 should be the same as old_ire.
+     * This ASSERT validate it.
+     */
+    ASSERT(ret == old_ire.val);
 }
 
 /* Mark specified intr remap entry as free */
@@ -394,8 +373,7 @@ static int ioapic_rte_to_remap_entry(struct vtd_iommu *iommu,
     remap_rte->reserved = 0;
     /* Indicate remap format. */
     remap_rte->format = 1;
-
-    /* If cmpxchg16b is not available the caller must mask the IO-APIC pin. */
+    
     update_irte(iommu, iremap_entry, &new_ire, !init && !masked);
     iommu_sync_cache(iremap_entry, sizeof(*iremap_entry));
     iommu_flush_iec_index(iommu, 0, index);
@@ -437,21 +415,6 @@ void cf_check io_apic_write_remap_rte(
     bool masked = true;
     int rc;
 
-    if ( !cpu_has_cx16 )
-    {
-       /*
-        * Cannot atomically update the IRTE entry: mask the IO-APIC pin to
-        * avoid interrupts seeing an inconsistent IRTE entry.
-        */
-        old_rte = __ioapic_read_entry(apic, pin, true);
-        if ( !old_rte.mask )
-        {
-            masked = false;
-            old_rte.mask = 1;
-            __ioapic_write_entry(apic, pin, true, old_rte);
-        }
-    }
-
     /* Not the initializer, for old gcc to cope. */
     new_rte.raw = rte;
 
diff --git a/xen/drivers/passthrough/vtd/iommu.c b/xen/drivers/passthrough/vtd/iommu.c
index c7110af7c9..47b56f37a9 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1482,7 +1482,7 @@ int domain_context_mapping_one(
 {
     struct domain_iommu *hd = dom_iommu(domain);
     struct context_entry *context, *context_entries, lctxt;
-    __uint128_t old;
+    __uint128_t res, old;
     uint64_t maddr;
     uint16_t seg = iommu->drhd->segment, prev_did = 0;
     struct domain *prev_dom = NULL;
@@ -1580,55 +1580,23 @@ int domain_context_mapping_one(
         ASSERT(!context_fault_disable(lctxt));
     }
 
-    if ( cpu_has_cx16 )
-    {
-        __uint128_t res = cmpxchg16b(context, &old, &lctxt.full);
+    res = cmpxchg16b(context, &old, &lctxt.full);
 
-        /*
-         * Hardware does not update the context entry behind our backs,
-         * so the return value should match "old".
-         */
-        if ( res != old )
-        {
-            if ( pdev )
-                check_cleanup_domid_map(domain, pdev, iommu);
-            printk(XENLOG_ERR
-                   "%pp: unexpected context entry %016lx_%016lx (expected %016lx_%016lx)\n",
-                   &PCI_SBDF(seg, bus, devfn),
-                   (uint64_t)(res >> 64), (uint64_t)res,
-                   (uint64_t)(old >> 64), (uint64_t)old);
-            rc = -EILSEQ;
-            goto unlock;
-        }
-    }
-    else if ( !prev_dom || !(mode & MAP_WITH_RMRR) )
-    {
-        context_clear_present(*context);
-        iommu_sync_cache(context, sizeof(*context));
-
-        write_atomic(&context->hi, lctxt.hi);
-        /* No barrier should be needed between these two. */
-        write_atomic(&context->lo, lctxt.lo);
-    }
-    else /* Best effort, updating DID last. */
+    /*
+     * Hardware does not update the context entry behind our backs,
+     * so the return value should match "old".
+     */
+    if ( res != old )
     {
-         /*
-          * By non-atomically updating the context entry's DID field last,
-          * during a short window in time TLB entries with the old domain ID
-          * but the new page tables may be inserted.  This could affect I/O
-          * of other devices using this same (old) domain ID.  Such updating
-          * therefore is not a problem if this was the only device associated
-          * with the old domain ID.  Diverting I/O of any of a dying domain's
-          * devices to the quarantine page tables is intended anyway.
-          */
-        if ( !(mode & (MAP_OWNER_DYING | MAP_SINGLE_DEVICE)) )
-            printk(XENLOG_WARNING VTDPREFIX
-                   " %pp: reassignment may cause %pd data corruption\n",
-                   &PCI_SBDF(seg, bus, devfn), prev_dom);
-
-        write_atomic(&context->lo, lctxt.lo);
-        /* No barrier should be needed between these two. */
-        write_atomic(&context->hi, lctxt.hi);
+        if ( pdev )
+            check_cleanup_domid_map(domain, pdev, iommu);
+        printk(XENLOG_ERR
+                "%pp: unexpected context entry %016lx_%016lx (expected %016lx_%016lx)\n",
+                &PCI_SBDF(seg, bus, devfn),
+                (uint64_t)(res >> 64), (uint64_t)res,
+                (uint64_t)(old >> 64), (uint64_t)old);
+        rc = -EILSEQ;
+        goto unlock;
     }
 
     iommu_sync_cache(context, sizeof(struct context_entry));
@@ -2630,6 +2598,15 @@ static int __init cf_check vtd_setup(void)
     int ret;
     bool reg_inval_supported = true;
 
+    if ( unlikely(!cpu_has_cx16) )
+    {
+        printk(XENLOG_ERR VTDPREFIX
+               "IOMMU: CPU doesn't support CMPXCHG16B, disabling\n");
+
+        ret = -ENOSYS;
+        goto error;
+    }
+
     if ( list_empty(&acpi_drhd_units) )
     {
         ret = -ENODEV;
@@ -2692,12 +2669,7 @@ static int __init cf_check vtd_setup(void)
             iommu_intremap = iommu_intremap_off;
 
 #ifndef iommu_intpost
-        /*
-         * We cannot use posted interrupt if X86_FEATURE_CX16 is
-         * not supported, since we count on this feature to
-         * atomically update 16-byte IRTE in posted format.
-         */
-        if ( !cap_intr_post(iommu->cap) || !iommu_intremap || !cpu_has_cx16 )
+        if ( !cap_intr_post(iommu->cap) || !iommu_intremap )
             iommu_intpost = false;
 #endif
 
-- 
2.44.0



Teddy Astie | Vates XCP-ng Intern

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 10:41:28 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 10:41:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696305.1087159 (Exim 4.92)
	(envelope-from )
	id 1rnFrU-0003aK-2X; Thu, 21 Mar 2024 10:41:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696305.1087159; Thu, 21 Mar 2024 10:41:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnFrT-0003ZO-TY; Thu, 21 Mar 2024 10:41:27 +0000
Received: by outflank-mailman (input) for mailman id 696305;
 Thu, 21 Mar 2024 10:28:31 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rnFex-0007v6-C7
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 10:28:31 +0000
Received: from mail135-12.atl141.mandrillapp.com
 (mail135-12.atl141.mandrillapp.com [198.2.135.12])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c1b4683c-e76d-11ee-afe0-a90da7624cb6;
 Thu, 21 Mar 2024 11:28:29 +0100 (CET)
Received: from pmta14.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1])
 by mail135-12.atl141.mandrillapp.com (Mailchimp) with ESMTP id
 4V0hWG0743z705xhC
 for ; Thu, 21 Mar 2024 10:28:26 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 eb479812074546b5afbb57b56b3defaa; Thu, 21 Mar 2024 10:28:25 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c1b4683c-e76d-11ee-afe0-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1711016906; x=1711277406;
	bh=bRgIlyJ6IbTuuXiog1EKxOiaZ1bQd5ybOrwG+UdBIvY=;
	h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version:
	 Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From;
	b=oifZv/JBfe9AzXx/S9lTFdeECrw8Zf7+gLOeKA3E38WdrsgQmqRvBECTFoN5wOBIW
	 Lu6DBseVRLBEKpBCR/dyl+31dxnxGzAxjNYhj/ALFoW2lleOrfjBpArcdny2gqMrNY
	 6xkdxTF69VpK4cz8lo5xn/ARfEX59Hy4TMf36n1hrfuihIzoDswPginQ9uWdE/8jQB
	 jOaNkPgpXkve0+mGzrJnFy+kI/6X01vTUBoZa0rvH/d+BKASmkvga1EZ2GFpATqf3h
	 7AEs0RDk2MMQEW6sWBB16SSCT8e3dyXr/tCyh2PIusKMVnoDubnLQ4bCij3rIiQio+
	 hfFnldYg5zLIw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1711016906; x=1711277406; i=teddy.astie@vates.tech;
	bh=bRgIlyJ6IbTuuXiog1EKxOiaZ1bQd5ybOrwG+UdBIvY=;
	h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version:
	 Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From;
	b=sGIm+cedcPgiusNjayVJc52YBK6yvRB6+Ls98mgPQ6G1046QfObBCY3yc1hG/ONUY
	 ucA8b4KB/BDomZGtu6R/olKpshS8IuQINENopQfjcaq/NhXe3J/t6Xhypovd6TpseA
	 aENVvz7kaINZgXkuvl+dADkgd07lXXyxTXJIX5LrA4QMar0UqZfxfIclwvFKS6TbwL
	 CdRYbsUYs72BI6tiIkCogAhRlk0CuIvVHoFsYTc7cvXyXB9dS7Km++VxF5YRE7Tu8W
	 RNVxzrIKiU3cRBy4Dz4KtP/AiMCIY/tZSKHx9cL/GIL9F/W27vwVN0RT94Oc/j2Etj
	 4aZuKt1lSf1hw==
From: Teddy Astie 
Subject: =?utf-8?Q?[XEN=20PATCH=200/3]=20x86/iommu:=20Drop=20IOMMU=20support=20when=20cpu=20doesn't=20support=20cx16.?=
X-Mailer: git-send-email 2.44.0
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1711016905266
To: xen-devel@lists.xenproject.org
Cc: Teddy Astie 
Message-Id: 
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.eb479812074546b5afbb57b56b3defaa?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20240321:md
Date: Thu, 21 Mar 2024 10:28:25 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

All hardware that supports VT-d/AMD-Vi that exists also supports cx16 (aside specifically crafted virtual machines).

Some IOMMU code paths in Xen consider cases where VT-d/AMD-Vi is supported while cx16 isn't, those paths may be bugged and are barely tested, dead code in practice.

Consider disabling IOMMU in case we have IOMMU hardware but no cx16, then cleanup no-cx16 handling logic from VT-d and AMD-Vi drivers.

Teddy Astie (3):
  VT-d: Disable IOMMU if cx16 isn't supported
  AMD-Vi: Disable IOMMU if cx16 isn't supported
  VT-d: Cleanup MAP_SINGLE_DEVICE and related dead code.

 xen/drivers/passthrough/amd/iommu_map.c     | 43 ++++------
 xen/drivers/passthrough/amd/pci_amd_iommu.c |  6 ++
 xen/drivers/passthrough/vtd/intremap.c      | 67 ++++-----------
 xen/drivers/passthrough/vtd/iommu.c         | 92 +++++++--------------
 xen/drivers/passthrough/vtd/vtd.h           |  5 +-
 5 files changed, 67 insertions(+), 146 deletions(-)

-- 
2.44.0



Teddy Astie | Vates XCP-ng Intern

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 10:41:28 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 10:41:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696306.1087165 (Exim 4.92)
	(envelope-from )
	id 1rnFrU-0003gx-Dx; Thu, 21 Mar 2024 10:41:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696306.1087165; Thu, 21 Mar 2024 10:41:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnFrU-0003fv-8G; Thu, 21 Mar 2024 10:41:28 +0000
Received: by outflank-mailman (input) for mailman id 696306;
 Thu, 21 Mar 2024 10:28:31 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rnFex-0007vj-Hi
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 10:28:31 +0000
Received: from mail179-23.suw41.mandrillapp.com
 (mail179-23.suw41.mandrillapp.com [198.2.179.23])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c1c6ba1d-e76d-11ee-a1ee-f123f15fe8a2;
 Thu, 21 Mar 2024 11:28:29 +0100 (CET)
Received: from pmta12.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail179-23.suw41.mandrillapp.com (Mailchimp) with ESMTP id
 4V0hWH34BNz35hmZb
 for ; Thu, 21 Mar 2024 10:28:27 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 4bf5dabb9933448fb19a3bb31f6c8228; Thu, 21 Mar 2024 10:28:27 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c1c6ba1d-e76d-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1711016907; x=1711277407;
	bh=HdgIKxPjdc3u8Z26L+lDF+6ART3gkpF8tDbHa+2flGw=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=hevxefiKTH4GmIB1XFzm1KIp10A4MDtR1pWk52jDDDEZrgXlMxsPOtNDx5cPliMiq
	 4HAKa7iwK0/QVGeW4xMxwbE8jRX2NA08l5yVUpEMvtY30vP8WsTpkvUb6hU91b57oR
	 WXX2dpCX+unxiDcJ9cCO3NgbWJBa1eYvdSwDQClA9wnSCPuuCsJu9AG5OwiIvYlFcu
	 grDPWjh7Fijcs5t+0z4vztnk3cVU4MynYleOekcv1HCsBHQqs4WMGvVpC8uqnRcs//
	 jQ5qqY6gMOq6rrYyDXPXR0GNokOnTrWr9dIabEvr7JeWiLHh0rHFpWpYx6kHbvDv35
	 AIKmJ2Ld7YFkw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1711016907; x=1711277407; i=teddy.astie@vates.tech;
	bh=HdgIKxPjdc3u8Z26L+lDF+6ART3gkpF8tDbHa+2flGw=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=Y6M+VqQ8Z6IIIrJA048roxjZ/wbg/Z8m/mYqIYEDHPedv+9Iqp59ucYX81f2Ck5Ep
	 7SQCrFrvbtSAEfzEOm0+pRDY3F2cTxw0NdRjWCuD2SqeBSexsffdnyAQYfzumBx+vX
	 1EnE61auAMUo1dV672xQU9Fax2hn37jK3dvd5x4mNW79DrkpVts8rdr7I0eKT1EfOB
	 vKXwXHuMWHryWiKBRuKzFOhZFF5PdMnwuhb2JXfOBb4EuAHzynczF2VOUzVNi4YF4C
	 VE5cqdVke/4d275rD/vOiT1lNFadfCTbnhYv7sVRzThSGMIMsXB8svflJNRQZA06BL
	 AbBXNuSTOhmXA==
From: Teddy Astie 
Subject: =?utf-8?Q?[XEN=20PATCH=203/3]=20VT-d:=20Cleanup=20MAP=5FSINGLE=5FDEVICE=20and=20related=20dead=20code.?=
X-Mailer: git-send-email 2.44.0
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1711016906361
To: xen-devel@lists.xenproject.org
Cc: Teddy Astie , Kevin Tian 
Message-Id: 
In-Reply-To: 
References: 
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.4bf5dabb9933448fb19a3bb31f6c8228?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20240321:md
Date: Thu, 21 Mar 2024 10:28:27 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

This flag was only used in case cx16 is not available, as those code paths no longer exist, this flag now does basically nothing.

Signed-off-by Teddy Astie 
---
 xen/drivers/passthrough/vtd/iommu.c | 12 +++---------
 xen/drivers/passthrough/vtd/vtd.h   |  5 ++---
 2 files changed, 5 insertions(+), 12 deletions(-)

diff --git a/xen/drivers/passthrough/vtd/iommu.c b/xen/drivers/passthrough/vtd/iommu.c
index 47b56f37a9..4b15e6da79 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1692,15 +1692,9 @@ static int domain_context_mapping(struct domain *domain, u8 devfn,
         break;
     }
 
-    if ( domain != pdev->domain && pdev->domain != dom_io )
-    {
-        if ( pdev->domain->is_dying )
-            mode |= MAP_OWNER_DYING;
-        else if ( drhd &&
-                  !any_pdev_behind_iommu(pdev->domain, pdev, drhd->iommu) &&
-                  !pdev->phantom_stride )
-            mode |= MAP_SINGLE_DEVICE;
-    }
+    if ( domain != pdev->domain && pdev->domain != dom_io &&
+         pdev->domain->is_dying )
+        mode |= MAP_OWNER_DYING;
 
     switch ( pdev->type )
     {
diff --git a/xen/drivers/passthrough/vtd/vtd.h b/xen/drivers/passthrough/vtd/vtd.h
index cb2df76eed..43f06a353d 100644
--- a/xen/drivers/passthrough/vtd/vtd.h
+++ b/xen/drivers/passthrough/vtd/vtd.h
@@ -28,9 +28,8 @@
  */
 #define MAP_WITH_RMRR         (1u << 0)
 #define MAP_OWNER_DYING       (1u << 1)
-#define MAP_SINGLE_DEVICE     (1u << 2)
-#define MAP_ERROR_RECOVERY    (1u << 3)
-#define UNMAP_ME_PHANTOM_FUNC (1u << 4)
+#define MAP_ERROR_RECOVERY    (1u << 2)
+#define UNMAP_ME_PHANTOM_FUNC (1u << 3)
 
 /* Allow for both IOAPIC and IOSAPIC. */
 #define IO_xAPIC_route_entry IO_APIC_route_entry
-- 
2.44.0



Teddy Astie | Vates XCP-ng Intern

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 10:41:29 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 10:41:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696309.1087172 (Exim 4.92)
	(envelope-from )
	id 1rnFrU-0003oH-TG; Thu, 21 Mar 2024 10:41:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696309.1087172; Thu, 21 Mar 2024 10:41:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnFrU-0003n1-Il; Thu, 21 Mar 2024 10:41:28 +0000
Received: by outflank-mailman (input) for mailman id 696309;
 Thu, 21 Mar 2024 10:28:32 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rnFey-0007vj-T9
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 10:28:32 +0000
Received: from mail135-12.atl141.mandrillapp.com
 (mail135-12.atl141.mandrillapp.com [198.2.135.12])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c2ed98ba-e76d-11ee-a1ee-f123f15fe8a2;
 Thu, 21 Mar 2024 11:28:31 +0100 (CET)
Received: from pmta14.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1])
 by mail135-12.atl141.mandrillapp.com (Mailchimp) with ESMTP id
 4V0hWH1Pjkz705xhf
 for ; Thu, 21 Mar 2024 10:28:27 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 1ab3eb7cf37d49e2920d69fec3c63cc9; Thu, 21 Mar 2024 10:28:27 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c2ed98ba-e76d-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1711016907; x=1711277407;
	bh=UcgkDzCzOUOiX6VvY3JJILSsBP2Bao7DTLrKO5nVeps=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=meB+PneUevspbTzSFXPNB89japidW+EyBe5i5/uY9XH/WP9XfqtiigR/GaSPOygzz
	 oyLm6xylrF4wzdjo7XTKy/24tv0JM0buy2Xkw58DE5/fiLo87c75lgpVeLox9jP5GJ
	 Mdmxdxc8JgOcB4egrZrzqDZl4f28m+XLdCpWGL6BOHxWOIVVYnrk8wsk87MLbDwOaK
	 D33SnHYB+sYN3f5/ST6ge3BRkpLx0BnbI8h0nhRZDNgG1BkjWFcREl2CwYp80h9bNj
	 jRABcYBLOnYieexd91r5vdorWvR71anP3Tr5RKbqisr9XxfMDn+y8quEskVHCcLIqB
	 vp7lGfesbATVg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1711016907; x=1711277407; i=teddy.astie@vates.tech;
	bh=UcgkDzCzOUOiX6VvY3JJILSsBP2Bao7DTLrKO5nVeps=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=KfF6dPK0WX7L30znmepadvH8riiTA39u0cK24nT/UQG1J2UzgddHd3doC8lDIogLd
	 ZSw8VgzMkqbqS53UDa8yNXIjB9em3kz2Nqtf7DbNyLPq0aYuwEHaCSEtpLwIlKv7cj
	 3hIU26EY1LMZLQCMI8LbRAhacNdoM+ejm1zHXTw1F0QNvoi3ALWGmvaayX2PlDPkYJ
	 wzZifqD5xhEPiEhNXlCwI2uAlbgAYvkt8QoCC+Boo1TFA8k+yApsxJp98BBHwYjxZc
	 P85p14QAft2Gbjp0CODYhvu8TlFQXylmrEasVpATUiSM9agFvfU8W7lQimr+fVKNWf
	 N463shyL/ILOg==
From: Teddy Astie 
Subject: =?utf-8?Q?[XEN=20PATCH=202/3]=20AMD-Vi:=20Disable=20IOMMU=20if=20cx16=20isn't=20supported?=
X-Mailer: git-send-email 2.44.0
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1711016906041
To: xen-devel@lists.xenproject.org
Cc: Teddy Astie , Jan Beulich , Andrew Cooper 
Message-Id: <9c825255af5d3973b29c85cb6856c67b69aa0e4a.1711016106.git.teddy.astie@vates.tech>
In-Reply-To: 
References: 
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.1ab3eb7cf37d49e2920d69fec3c63cc9?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20240321:md
Date: Thu, 21 Mar 2024 10:28:27 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

No hardware has VT-d support while not having cx16 support, consider disabling IOMMU in this case to avoid potentially buggy code.

Now that IOMMU is only enabled if cx16 is supported, drop dead code that handles cases where cx16 isn't supported.

Signed-off-by Teddy Astie 
---
 xen/drivers/passthrough/amd/iommu_map.c     | 43 +++++++--------------
 xen/drivers/passthrough/amd/pci_amd_iommu.c |  6 +++
 2 files changed, 21 insertions(+), 28 deletions(-)

diff --git a/xen/drivers/passthrough/amd/iommu_map.c b/xen/drivers/passthrough/amd/iommu_map.c
index e0f4fe736a..c8c1c0cfae 100644
--- a/xen/drivers/passthrough/amd/iommu_map.c
+++ b/xen/drivers/passthrough/amd/iommu_map.c
@@ -167,15 +167,14 @@ int amd_iommu_set_root_page_table(struct amd_iommu_dte *dte,
 {
     bool valid = flags & SET_ROOT_VALID;
 
-    if ( dte->v && dte->tv &&
-         (cpu_has_cx16 || (flags & SET_ROOT_WITH_UNITY_MAP)) )
+    if ( dte->v && dte->tv )
     {
         union {
             struct amd_iommu_dte dte;
             uint64_t raw64[4];
             __uint128_t raw128[2];
         } ldte = { .dte = *dte };
-        __uint128_t old = ldte.raw128[0];
+        __uint128_t res, old = ldte.raw128[0];
         int ret = 0;
 
         ldte.dte.domain_id = domain_id;
@@ -185,33 +184,21 @@ int amd_iommu_set_root_page_table(struct amd_iommu_dte *dte,
         ldte.dte.paging_mode = paging_mode;
         ldte.dte.v = valid;
 
-        if ( cpu_has_cx16 )
-        {
-            __uint128_t res = cmpxchg16b(dte, &old, &ldte.raw128[0]);
+    
+        res = cmpxchg16b(dte, &old, &ldte.raw128[0]);
 
-            /*
-             * Hardware does not update the DTE behind our backs, so the
-             * return value should match "old".
-             */
-            if ( res != old )
-            {
-                printk(XENLOG_ERR
-                       "Dom%d: unexpected DTE %016lx_%016lx (expected %016lx_%016lx)\n",
-                       domain_id,
-                       (uint64_t)(res >> 64), (uint64_t)res,
-                       (uint64_t)(old >> 64), (uint64_t)old);
-                ret = -EILSEQ;
-            }
-        }
-        else /* Best effort, updating domain_id last. */
+        /*
+         * Hardware does not update the DTE behind our backs, so the
+         * return value should match "old".
+         */
+        if ( res != old )
         {
-            uint64_t *ptr = (void *)dte;
-
-            write_atomic(ptr + 0, ldte.raw64[0]);
-            /* No barrier should be needed between these two. */
-            write_atomic(ptr + 1, ldte.raw64[1]);
-
-            ret = 1;
+            printk(XENLOG_ERR
+                   "Dom%d: unexpected DTE %016lx_%016lx (expected %016lx_%016lx)\n",
+                   domain_id,
+                   (uint64_t)(res >> 64), (uint64_t)res,
+                   (uint64_t)(old >> 64), (uint64_t)old);
+            ret = -EILSEQ;
         }
 
         return ret;
diff --git a/xen/drivers/passthrough/amd/pci_amd_iommu.c b/xen/drivers/passthrough/amd/pci_amd_iommu.c
index f6efd88e36..656c5eda5d 100644
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
@@ -312,6 +312,12 @@ static int __init cf_check iov_detect(void)
         return -ENODEV;
     }
 
+    if ( unlikely(!cpu_has_cx16) )
+    {
+        printk("AMD-Vi: CPU doesn't support CMPXCHG16B, disabling\n");
+        return -ENOSYS;
+    }
+
     init_done = 1;
 
     if ( !amd_iommu_perdev_intremap )
-- 
2.44.0



Teddy Astie | Vates XCP-ng Intern

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 10:51:49 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 10:51:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696328.1087195 (Exim 4.92)
	(envelope-from )
	id 1rnG1P-0007lg-Ve; Thu, 21 Mar 2024 10:51:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696328.1087195; Thu, 21 Mar 2024 10:51:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnG1P-0007lZ-RX; Thu, 21 Mar 2024 10:51:43 +0000
Received: by outflank-mailman (input) for mailman id 696328;
 Thu, 21 Mar 2024 10:51:42 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnG1O-0007lT-Dv
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 10:51:42 +0000
Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com
 [2a00:1450:4864:20::133])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ff594960-e770-11ee-a1ee-f123f15fe8a2;
 Thu, 21 Mar 2024 11:51:40 +0100 (CET)
Received: by mail-lf1-x133.google.com with SMTP id
 2adb3069b0e04-512f892500cso952779e87.3
 for ; Thu, 21 Mar 2024 03:51:40 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 s10-20020a1709060c0a00b00a44899a44ddsm8449326ejf.11.2024.03.21.03.51.39
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 21 Mar 2024 03:51:39 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ff594960-e770-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711018300; x=1711623100; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=+3WxriO6Uu9DKi+i9uSCc9XftNbhqvLeJRBNd7zSoiQ=;
        b=H2PwDRQDys5ufpJhx0jpS+FuwtnsM22hGNqJf9jOTjYzlGaWQhMSHwlJxT8Y+kR9Yv
         AtDMRGJ2od+XZYbFS4mv3vt2JMbSsPOMAu0olQMlOUWnalKIDL5yK65lOmAY587Z+5sk
         dXp+8AEH/kZYgIpokZY2pklvFuXVPFK1L9W3cTlurOrpxOlgsO5pO15zcXSWWhdrTpZY
         oabiimJ15fBIDBwE8d6zkoXaVrZ4eVZXY/s+uveHgAgXuJqdul5DusPcf5Gq3v+vXQQK
         zqLOi2H5ZF5lu/EPcdYbg0fLzcbRy+Tx+fyYs5sNsJu86mPzKNwgmqfX3CoiGDvXU2hr
         tNzA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711018300; x=1711623100;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=+3WxriO6Uu9DKi+i9uSCc9XftNbhqvLeJRBNd7zSoiQ=;
        b=mR+q5E4yF/2vS+wMS4nUDjnb+5kas7jkEWCSdeiRDRHTrEvNrOZKPuhmH0WazkbOge
         Ol4d859z7UzilKbf+DW72+qMLCX4XGhFJ1qTstveV6lbHxJqrjwEn1nUVn7SjMTNznK7
         l91VSYygAEQr2na9IMbNhBYSh5C4/0lx0JJG49J8/jIRVVmFK22P95C7SZgL6eY5ZX3d
         k8nv7pGKYLM8EG+upkuWvlmpxKVcK29pQQXm0vidEt2ds8beF5HfO76dIXWeq5TKHnu4
         pTp5zIwf5hJVNmtnfoCpI77COo+8wcoqAElRyv5W+o3nAaNdFtozQDpcNa1Gza/+LXvU
         7bcg==
X-Gm-Message-State: AOJu0Yz5h/H+AkrfaSkLVCCq+X6/pHzR6XGfaunehnLF91BWzGg3pPR1
	foeiIgIOIudkZkEZuBE/i+9twOAwe59/zezZtJ5YkaTgoOgwtWizXWoteSqI0g==
X-Google-Smtp-Source: AGHT+IHSWvoV0hKGUyBPLugS7SZ+eF7Mgt4TfisSQpQ82ky5i3H7PIz6IPWCSM3YJV1cdX05TIcg+w==
X-Received: by 2002:a19:5e1e:0:b0:513:cc18:d4c6 with SMTP id s30-20020a195e1e000000b00513cc18d4c6mr1567047lfb.41.1711018299766;
        Thu, 21 Mar 2024 03:51:39 -0700 (PDT)
Message-ID: <3cff3eaa-f05f-4a93-ac24-31975856827f@suse.com>
Date: Thu, 21 Mar 2024 11:51:38 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 1/3] VT-d: Disable IOMMU if cx16 isn't supported
Content-Language: en-US
To: Teddy Astie 
Cc: xen-devel@lists.xenproject.org, Andrew Cooper
 , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 
References: 
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 21.03.2024 11:28, Teddy Astie wrote:
> No hardware has VT-d support while not having cx16 support, consider disabling IOMMU in this case to avoid potentially buggy code.

Like in patch 2 (which for whatever reason made it through quite a bit earlier),
why "consider"? Your change does disable the IOMMU in that case, you don't merely
consider doing so.

> @@ -394,8 +373,7 @@ static int ioapic_rte_to_remap_entry(struct vtd_iommu *iommu,
>      remap_rte->reserved = 0;
>      /* Indicate remap format. */
>      remap_rte->format = 1;
> -
> -    /* If cmpxchg16b is not available the caller must mask the IO-APIC pin. */
> +    

Please don't introduce lines with trailing blanks.

> @@ -2630,6 +2598,15 @@ static int __init cf_check vtd_setup(void)
>      int ret;
>      bool reg_inval_supported = true;
>  
> +    if ( unlikely(!cpu_has_cx16) )
> +    {
> +        printk(XENLOG_ERR VTDPREFIX
> +               "IOMMU: CPU doesn't support CMPXCHG16B, disabling\n");
> +
> +        ret = -ENOSYS;
> +        goto error;
> +    }

One thing I forgot to mention when replying to patch 2, applying here
equally: vtd_setup() isn't necessarily the first bit of IOMMU setup done.
For x2APIC enabling earlier calls out of x2apic_bsp_setup() exist, which
also need taking care of.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 11:05:54 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 11:05:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696331.1087205 (Exim 4.92)
	(envelope-from )
	id 1rnGEs-0001b4-59; Thu, 21 Mar 2024 11:05:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696331.1087205; Thu, 21 Mar 2024 11:05:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnGEs-0001ax-0k; Thu, 21 Mar 2024 11:05:38 +0000
Received: by outflank-mailman (input) for mailman id 696331;
 Thu, 21 Mar 2024 11:05:37 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rnGEq-0001ar-UU
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 11:05:36 +0000
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com
 [2a00:1450:4864:20::32a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f0be5665-e772-11ee-a1ee-f123f15fe8a2;
 Thu, 21 Mar 2024 12:05:34 +0100 (CET)
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-4146a1ac117so5114985e9.0
 for ; Thu, 21 Mar 2024 04:05:34 -0700 (PDT)
Received: from localhost ([85.31.135.62]) by smtp.gmail.com with ESMTPSA id
 q18-20020adff792000000b0033ec9b26b7asm16943227wrp.25.2024.03.21.04.05.33
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 21 Mar 2024 04:05:33 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f0be5665-e772-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1711019133; x=1711623933; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:from:to:cc:subject:date:message-id:reply-to;
        bh=Q0RtmqqzFd4YUtX95+8cJsuMlOVlknAi1XayUzUdt2k=;
        b=cISF5faALJ6IRD1WaDsUMTc4y040Qh8DVscH3aBH038IIvyQRYnIAk5L0rsgFCZYHo
         jvn70fmnjbv7touRRM1lwfGmeb8I12aYKtuj2GEqG9BLbtpWCeGHPDHmBCk2p2cVEfDu
         SNx/hLSNRs3hBX3cODZzC3fN/uU+nTfTb/UAc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711019133; x=1711623933;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=Q0RtmqqzFd4YUtX95+8cJsuMlOVlknAi1XayUzUdt2k=;
        b=ipDtM0qjoV9ap6Iz0vyCYLqkrwBN0LfKj4zMHtgoOuRMFPr4RbZv4MC0g2Yd1knb0I
         B3r2JnF5PbUgJkXTJegnWEpikSNNSZHdG2ske5cBt207Stk5auQj4ssHuD0ylIJDAUNC
         va9BztloKfhM4D2b5AroiATrgA4e1Oj6/Hqwv2j98mYH2eSivRsf0OprZ7yqZP7b5IrH
         vDRErFRcONioz6PmGoeLiS4LRPInEMv1ieVFhmhMCC9H18IGTUfq0lB6cXLXWvxbSyOS
         qNXHd8CFoz8k+crvTPrUHR0q057AGSpXxdWLc96M0n7fxvUvsfRok6GuG7XomSowqDif
         H6cw==
X-Gm-Message-State: AOJu0YzsPyvXVVVqylpRqJjKwzaB2EpZP2jFpoba4iPiuaF4NsZ4Pv+g
	+9VxXW6MNVw4qbDFDgv49Duv1Vfzeg0ZCbhQbsKXOpvXALm/4NvzrZabNb1qlRwxVPLHoRTeas5
	4
X-Google-Smtp-Source: AGHT+IGewDTEX5eCSP+WcLGjdD9PesY412II1Kwnpspv5QujOnEl8L9XgUrrHyPfl1vyfJM1XPIzXw==
X-Received: by 2002:a05:600c:3149:b0:413:fdc2:d9da with SMTP id h9-20020a05600c314900b00413fdc2d9damr2144437wmo.12.1711019133582;
        Thu, 21 Mar 2024 04:05:33 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini ,
	Wei Liu 
Subject: [PATCH] xen/console: add comment about external console lock helper
Date: Thu, 21 Mar 2024 12:05:03 +0100
Message-ID: <20240321110503.72916-1-roger.pau@citrix.com>
X-Mailer: git-send-email 2.44.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The current console_lock_recursive_irqsave() implementation is not speculation
safe, however it's only used to prevent interleaved output.  Note this in the
function declaration in order for callers to be aware of the limitation.

No functional change.

Signed-off-by: Roger Pau Monné 
---
 xen/include/xen/console.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/include/xen/console.h b/xen/include/xen/console.h
index 68759862e88d..6dfbade3ece3 100644
--- a/xen/include/xen/console.h
+++ b/xen/include/xen/console.h
@@ -20,6 +20,7 @@ void console_init_postirq(void);
 void console_endboot(void);
 int console_has(const char *device);
 
+/* Not speculation safe - only used to prevent interleaving of output. */
 unsigned long console_lock_recursive_irqsave(void);
 void console_unlock_recursive_irqrestore(unsigned long flags);
 void console_force_unlock(void);
-- 
2.44.0



From xen-devel-bounces@lists.xenproject.org Thu Mar 21 12:08:01 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 12:08:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696369.1087238 (Exim 4.92)
	(envelope-from )
	id 1rnHCw-00058n-6x; Thu, 21 Mar 2024 12:07:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696369.1087238; Thu, 21 Mar 2024 12:07:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnHCw-00058g-41; Thu, 21 Mar 2024 12:07:42 +0000
Received: by outflank-mailman (input) for mailman id 696369;
 Thu, 21 Mar 2024 12:07:40 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnHCu-00058Z-Jc
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 12:07:40 +0000
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com
 [2a00:1450:4864:20::52e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9c8bf8e7-e77b-11ee-afe0-a90da7624cb6;
 Thu, 21 Mar 2024 13:07:39 +0100 (CET)
Received: by mail-ed1-x52e.google.com with SMTP id
 4fb4d7f45d1cf-56b85146589so1595086a12.0
 for ; Thu, 21 Mar 2024 05:07:38 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 f6-20020a056402194600b0056b98d7ba00sm2844903edz.90.2024.03.21.05.07.37
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 21 Mar 2024 05:07:38 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9c8bf8e7-e77b-11ee-afe0-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711022858; x=1711627658; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=Naf6fdsrjhZmarDA1/mhVYCS6cRC/yYk4xwHbjtdDZ4=;
        b=Rpa+Jo1670mCGXho32ql0SDOtcjjw3ly3T0QTPzyAaANjy3xhZJ7Fw1E1k2KaNAU9Z
         MrHbMUd3YaSQ+P8lwyDA2qj4n3a5vuF3siAII2o425C8i670FB9PFIFTS88+8olBB3pd
         v4VuSYRxv2oblaNfhmSKRhMQl3UvQ7DaAHpw2t4IuPzmYLQQQUvU6v55+8oGw9IUyJ2F
         9G/gpieDP0sZP7TW3f8A3UvNnoEor0YXXFMTEXmOuRaiawMiPCCD5ChDdfmHRjW5C8/J
         vReESjLY3Nsur4uQ3vR1FFj1d7T2iAs+t/inep9RpgqfMVdzXxbag6lhGaUktuN5ZKxf
         le6g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711022858; x=1711627658;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=Naf6fdsrjhZmarDA1/mhVYCS6cRC/yYk4xwHbjtdDZ4=;
        b=cRnpeyyVBSHztBRnJsesi5VAhlApEKDVDFCoWPtdFYiJv5Cm7OkitEYuL4rhvxyOGD
         aqgLw6eHPWxRgkdA2zxeuckjKAD+3vMxXOAMybZDp7C254DcU61dkRGqACHDBv2YZ853
         3tX5o65nGDTCx3DlUgpL6CClHVGeygVt4+cjLq82/j4Z4lLPOkKMGrCO9T0J29aV9kvx
         AQRa5mCVlUia6phN+WkwHpO3OtY9Hhji0nOYNJbJP7eieB18QANRuLGbDxPO1bxfMGF0
         C1Wp8C90imwOISM4X2HyYZt9xf1AK7LalYhG9Ss2e64du0lQV7I0SE7w4ktYmuCpN/8s
         hOMQ==
X-Forwarded-Encrypted: i=1; AJvYcCWxHCxO6MJbYIx+pd8pVG+fUqhtyb/O5Atf4fcJmraD5cs5Cw0O9a3do87qQK6gFNA2z6DutaEMbECokdhaHGTd0yY/6pibh3CzcQvhCw0=
X-Gm-Message-State: AOJu0YxaW9El6H5tvlBTu5ohGR6/F3ENSqdWdKnhtcW7CRh7lSnFcXr7
	7lI7kH6Ote8QsuyCggOsZI1lqqXF+RXWqPHY4rDoZRsHVppmu0Az7M6rs6mWnQ==
X-Google-Smtp-Source: AGHT+IGfmMDdaDceIWPeliVXAqupSLgPxvm98nkBQRdKdWxinxewKZaH8SNjKdJ6kOA11LBzeMGX6g==
X-Received: by 2002:a05:6402:5409:b0:568:d143:dab2 with SMTP id ev9-20020a056402540900b00568d143dab2mr2054972edb.19.1711022858351;
        Thu, 21 Mar 2024 05:07:38 -0700 (PDT)
Message-ID: <6f73368c-ea73-4d86-a6a1-8f9784c4b01f@suse.com>
Date: Thu, 21 Mar 2024 13:07:36 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 08/20] xen/riscv: introduce cmpxchg.h
Content-Language: en-US
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 xen-devel@lists.xenproject.org
References: 
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 15.03.2024 19:06, Oleksii Kurochko wrote:
> The header was taken from Linux kernl 6.4.0-rc1.
> 
> Addionally, were updated:
> * add emulation of {cmp}xchg for 1/2 byte types using 32-bit atomic
>   access.
> * replace tabs with spaces
> * replace __* variale with *__
> * introduce generic version of xchg_* and cmpxchg_*.
> * drop {cmp}xchg{release,relaxed,acquire} as Xen doesn't use them

With this, ...

> * drop barries and use instruction suffixices instead ( .aq, .rl, .aqrl )
> 
> Implementation of 4- and 8-byte cases were updated according to the spec:
> ```
>               ....
> Linux Construct         RVWMO AMO Mapping
> atomic  relaxed     amo.{w|d}
> atomic  acquire     amo.{w|d}.aq
> atomic  release     amo.{w|d}.rl
> atomic              amo.{w|d}.aqrl
> Linux Construct         RVWMO LR/SC Mapping
> atomic  relaxed     loop: lr.{w|d}; ; sc.{w|d}; bnez loop
> atomic  acquire     loop: lr.{w|d}.aq; ; sc.{w|d}; bnez loop
> atomic  release     loop: lr.{w|d}; ; sc.{w|d}.aqrl∗ ; bnez loop OR
>                         fence.tso; loop: lr.{w|d}; ; sc.{w|d}∗ ; bnez loop
> atomic              loop: lr.{w|d}.aq; ; sc.{w|d}.aqrl; bnez loop
> 
> Table A.5: Mappings from Linux memory primitives to RISC-V primitives
> 
> ```

... I consider quoting this table in full, without any further remarks, as
confusing: Three of the lines each are inapplicable now, aiui.

Further what are the two * telling us? Quite likely they aren't there just
accidentally.

Finally, why sc.{w|d}.aqrl when in principle one would expect just
sc.{w|d}.rl?

> --- /dev/null
> +++ b/xen/arch/riscv/include/asm/cmpxchg.h
> @@ -0,0 +1,209 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/* Copyright (C) 2014 Regents of the University of California */
> +
> +#ifndef _ASM_RISCV_CMPXCHG_H
> +#define _ASM_RISCV_CMPXCHG_H
> +
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +#define __amoswap_generic(ptr, new, ret, sfx) \

As before / elsewhere: Is there a strong need for two leading underscores
here? Using just one would already be standard compliant afaict.

> +({ \
> +    asm volatile ( \
> +        " amoswap" sfx " %0, %2, %1" \
> +        : "=r" (ret), "+A" (*ptr) \
> +        : "r" (new) \
> +        : "memory" ); \
> +})

This doesn't need the ({ }) (anymore?):

#define __amoswap_generic(ptr, new, ret, sfx) \
    asm volatile ( \
        " amoswap" sfx " %0, %2, %1" \
        : "=r" (ret), "+A" (*(ptr)) \
        : "r" (new) \
        : "memory" )

(note also the added parentheses).

> +/*
> + * For LR and SC, the A extension requires that the address held in rs1 be
> + * naturally aligned to the size of the operand (i.e., eight-byte aligned
> + * for 64-bit words and four-byte aligned for 32-bit words).
> + * If the address is not naturally aligned, an address-misaligned exception
> + * or an access-fault exception will be generated.
> + *
> + * Thereby:
> + * - for 1-byte xchg access the containing word by clearing low two bits
> + * - for 2-byte xchg ccess the containing word by clearing bit 1.

Nit: "access"

> + * If resulting 4-byte access is still misalgined, it will fault just as
> + * non-emulated 4-byte access would.
> + */
> +#define emulate_xchg_1_2(ptr, new, lr_sfx, sc_sfx) \
> +({ \
> +    uint32_t *aligned_ptr = (uint32_t *)((unsigned long)ptr & ~(0x4 - sizeof(*(ptr)))); \
> +    unsigned int new_val_pos = ((unsigned long)(ptr) & (0x4 - sizeof(*(ptr)))) * BITS_PER_BYTE; \

You parenthesize ptr here correctly, but not in the line above.

Instead of "_pos" in the name, maybe better "_bit"?

Finally, here and elsewhere, please limit line length to 80 chars. (Omitting
the 0x here would help a little, but not quite enough. Question is whether
these wouldn't better be sizeof(*aligned_ptr) anyway.)

> +    unsigned long mask = GENMASK(((sizeof(*(ptr))) * BITS_PER_BYTE) - 1, 0) << new_val_pos; \
> +    unsigned int new_ = new << new_val_pos; \

Similarly new wants parenthesizing here.

> +    unsigned int old; \
> +    unsigned int scratch; \
> +    \
> +    asm volatile ( \
> +        "0: lr.w" lr_sfx " %[old], %[aligned_ptr]\n" \
> +        "   and  %[scratch], %[old], %z[nmask]\n" \
> +        "   or   %[scratch], %[scratch], %z[new_]\n" \
> +        "   sc.w" sc_sfx " %[scratch], %[scratch], %[aligned_ptr]\n" \
> +        "   bnez %[scratch], 0b\n" \
> +        : [old] "=&r" (old), [scratch] "=&r" (scratch), [aligned_ptr] "+A" (*aligned_ptr) \

While for the variable name aligned_ptr is likely helpful, for the operand
name just ptr would certainly do?

> +        : [new_] "rJ" (new_), [nmask] "rJ" (~mask) \

Neither mask nor ~mask can be 0. Hence J here and the z modifier above
look pointless. (new_, otoh, can be 0, so allowing x0 to be used in that
case is certainly desirable.)

As to using ~mask here: Now that we look to have settled on requiring
Zbb, you could use andn instead of and, thus allowing the same register
to be used in the asm() and ...

> +        : "memory" ); \
> +    \
> +    (__typeof__(*(ptr)))((old & mask) >> new_val_pos); \

... for this calculation.

> +})
> +
> +static always_inline unsigned long __xchg(volatile void *ptr, unsigned long new, int size)
> +{
> +    unsigned long ret;
> +
> +    switch ( size )
> +    {
> +    case 1:
> +        ret = emulate_xchg_1_2((volatile uint8_t *)ptr, new, ".aq", ".aqrl");
> +        break;
> +    case 2:
> +        ret = emulate_xchg_1_2((volatile uint16_t *)ptr, new, ".aq", ".aqrl");
> +        break;
> +    case 4:
> +        __amoswap_generic((volatile uint32_t *)ptr, new, ret, ".w.aqrl");
> +        break;
> +#ifndef CONFIG_32BIT

There's no 32BIT Kconfig symbol; all we have is a 64BIT one.

> +    case 8:
> +        __amoswap_generic((volatile uint64_t *)ptr, new, ret, ".d.aqrl");
> +        break;
> +#endif
> +    default:
> +        STATIC_ASSERT_UNREACHABLE();
> +    }
> +
> +    return ret;
> +}
> +
> +#define xchg(ptr, x) \
> +({ \
> +    __typeof__(*(ptr)) n_ = (x); \
> +    (__typeof__(*(ptr))) \
> +        __xchg((ptr), (unsigned long)(n_), sizeof(*(ptr))); \

Nit: While excess parentheses "only" harm readability, they would
nevertheless better be omitted (here: the first argument passed).

> +})
> +
> +#define __generic_cmpxchg(ptr, old, new, ret, lr_sfx, sc_sfx)	\
> + ({ \
> +    register unsigned int rc; \

Nit: We don't normally use "register", unless accompanied by asm() tying
a variable to a specific one.

> +    __typeof__(*(ptr)) old__ = (__typeof__(*(ptr)))(old); \
> +    __typeof__(*(ptr)) new__ = (__typeof__(*(ptr)))(new); \

The casts aren't very nice to have here; I take they're needed for
cmpxchg_ptr() to compile?

> +    asm volatile( \

Nit: Missing blank once again. Would be really nice if you could go
through and sort this uniformly for the series.

> +        "0: lr" lr_sfx " %0, %2\n" \
> +        "   bne  %0, %z3, 1f\n" \
> +        "   sc" sc_sfx " %1, %z4, %2\n" \
> +        "   bnez %1, 0b\n" \
> +        "1:\n" \
> +        : "=&r" (ret), "=&r" (rc), "+A" (*ptr) \
> +        : "rJ" (old__), "rJ" (new__) \

Please could I talk you into using named operands here, too?

Also ptr here is lacking parentheses again.

> +        : "memory"); \

And yet another missing blank.

> + })

At the use site this construct having a normal return value (rather
than ret being passed in) would overall look more natural.

> +/*
> + * For LR and SC, the A extension requires that the address held in rs1 be
> + * naturally aligned to the size of the operand (i.e., eight-byte aligned
> + * for 64-bit words and four-byte aligned for 32-bit words).
> + * If the address is not naturally aligned, an address-misaligned exception
> + * or an access-fault exception will be generated.
> + *
> + * Thereby:
> + * - for 1-byte xchg access the containing word by clearing low two bits
> + * - for 2-byte xchg ccess the containing word by clearing first bit.
> + * 
> + * If resulting 4-byte access is still misalgined, it will fault just as
> + * non-emulated 4-byte access would.
> + *
> + * old_val was casted to unsigned long for cmpxchgptr()
> + */
> +#define emulate_cmpxchg_1_2(ptr, old, new, lr_sfx, sc_sfx) \
> +({ \
> +    uint32_t *aligned_ptr = (uint32_t *)((unsigned long)ptr & ~(0x4 - sizeof(*(ptr)))); \
> +    uint8_t new_val_pos = ((unsigned long)(ptr) & (0x4 - sizeof(*(ptr)))) * BITS_PER_BYTE; \
> +    unsigned long mask = GENMASK(((sizeof(*(ptr))) * BITS_PER_BYTE) - 1, 0) << new_val_pos; \
> +    unsigned int old_ = old << new_val_pos; \
> +    unsigned int new_ = new << new_val_pos; \
> +    unsigned int old_val; \
> +    unsigned int scratch; \
> +    \
> +    __asm__ __volatile__ ( \
> +        "0: lr.w" lr_sfx " %[scratch], %[aligned_ptr]\n" \
> +        "   and  %[old_val], %[scratch], %z[mask]\n" \
> +        "   bne  %[old_val], %z[old_], 1f\n" \
> +        "   xor  %[scratch], %[old_val], %[scratch]\n" \

To be honest I was hoping this line would come with a brief comment.

> +        "   or   %[scratch], %[scratch], %z[new_]\n" \
> +        "   sc.w" sc_sfx " %[scratch], %[scratch], %[aligned_ptr]\n" \
> +        "   bnez %[scratch], 0b\n" \
> +        "1:\n" \
> +        : [old_val] "=&r" (old_val), [scratch] "=&r" (scratch), [aligned_ptr] "+A" (*aligned_ptr) \
> +        : [old_] "rJ" (old_), [new_] "rJ" (new_), \
> +          [mask] "rJ" (mask) \
> +        : "memory" ); \
> +    \
> +    (__typeof__(*(ptr)))((unsigned long)old_val >> new_val_pos); \
> +})

A few of the comments for emulate_xchg_1_2() apply here as well.

> +/*
> + * Atomic compare and exchange.  Compare OLD with MEM, if identical,
> + * store NEW in MEM.  Return the initial value in MEM.  Success is
> + * indicated by comparing RETURN with OLD.
> + */
> +static always_inline unsigned long __cmpxchg(volatile void *ptr,
> +                         unsigned long old,
> +                         unsigned long new,
> +                         int size)

Nit: Inappropriate indentation.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 12:10:35 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 12:10:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696371.1087248 (Exim 4.92)
	(envelope-from )
	id 1rnHFf-0006ex-II; Thu, 21 Mar 2024 12:10:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696371.1087248; Thu, 21 Mar 2024 12:10:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnHFf-0006eq-Fe; Thu, 21 Mar 2024 12:10:31 +0000
Received: by outflank-mailman (input) for mailman id 696371;
 Thu, 21 Mar 2024 12:10:30 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnHFe-0006ee-D2; Thu, 21 Mar 2024 12:10:30 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnHFe-0000Dq-53; Thu, 21 Mar 2024 12:10:30 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnHFd-0005fK-SG; Thu, 21 Mar 2024 12:10:29 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rnHFd-0007eN-Rj; Thu, 21 Mar 2024 12:10:29 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=MNENGrNRR8FW8kOQu92X1INbCq2XgDYf7PijS6IJ7Fg=; b=BOAZ5AThQM3dPHlG85T+gYMYlu
	r0hkCU94JkT5tNTFPV00BfUHokpLBGbMqMKuZM2pzHzv0Mr2sUYXkhiSX2mIH7clx0TmXX0HOtWQj
	IrWVvKiIRoj4MFMNT8tAIHOe5cNpPakWhBaNBHjlzXSPuLxBZHNvH7aZjOtnBrq9iolk=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 185120: regressions - FAIL
X-Osstest-Failures:
    xen-unstable-smoke:test-amd64-amd64-xl-qemuu-debianhvm-amd64:debian-hvm-install:fail:regression
    xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    xen=97b90f9bf2e5c93e0f61c927fa2bc8a56a213faa
X-Osstest-Versions-That:
    xen=eaafbd11344a8ec32309fe58a6e529fe1c34d62e
From: osstest service owner 
Date: Thu, 21 Mar 2024 12:10:29 +0000

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          16 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  97b90f9bf2e5c93e0f61c927fa2bc8a56a213faa
baseline version:
 xen                  eaafbd11344a8ec32309fe58a6e529fe1c34d62e

Last test of basis   185109  2024-03-20 09:03:31 Z    1 days
Testing same since   185120  2024-03-21 09:03:04 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper 
  Anthony PERARD 
  Carlo Nonato 
  Elliott Mitchell 
  Jan Beulich 
  Roger Pau Monné 
  Shawn Anastasio 

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-amd64                    fail    
 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


Not pushing.

------------------------------------------------------------
commit 97b90f9bf2e5c93e0f61c927fa2bc8a56a213faa
Author: Shawn Anastasio 
Date:   Thu Mar 21 09:49:20 2024 +0100

    xen/ppc: Ensure ELF sections' physical load addresses start at 0x0
    
    Some boot mechanisms, including the new linux file_load kexec systemcall
    used by system firmware v2.10 on RaptorCS systems will try to honor the
    physical address field of the ELF LOAD section header, which will fail
    when the address is based off of XEN_VIRT_START (0xc000000000000000).
    
    To ensure that the physical address of the LOAD section header starts at
    0x0, move x86's DECL_SECTION macro to xen.lds.h and use it to declare
    all sections.
    
    Signed-off-by: Shawn Anastasio 
    Acked-by: Andrew Cooper 

commit 10e8d824b76f55dde7c1793f48d76d4ff9df5e0a
Author: Jan Beulich 
Date:   Thu Mar 21 09:48:49 2024 +0100

    AMD/IOMMU: drop remaining guest-IOMMU bits too
    
    With a02174c6c885 ("amd/iommu: clean up unused guest iommu related
    functions") having removed the sole place where d->g_iommu would be set
    to non-NULL, guest_iommu_add_ppr_log() will unconditionally bail the
    latest from its 2nd if(). With it dropped, all other stuff in the file
    is unused, too. Delete iommu_guest.c altogether.
    
    Further delete struct guest{_buffer,_dev_table,_iommu{,_msi}} as well as
    struct mmio_reg for being unused with the unused g_iommu also dropped
    from struct arch_iommu.
    
    Signed-off-by: Jan Beulich 
    Acked-by: Roger Pau Monné 

commit cc950c49ae6a6690f7fc3041a1f43122c250d250
Author: Jan Beulich 
Date:   Thu Mar 21 09:48:10 2024 +0100

    x86/PoD: tie together P2M update and increment of entry count
    
    When not holding the PoD lock across the entire region covering P2M
    update and stats update, the entry count - if to be incorrect at all -
    should indicate too large a value in preference to a too small one, to
    avoid functions bailing early when they find the count is zero. However,
    instead of moving the increment ahead (and adjust back upon failure),
    extend the PoD-locked region.
    
    Fixes: 99af3cd40b6e ("x86/mm: Rework locking in the PoD layer")
    Signed-off-by: Jan Beulich 
    Reviewed-by: George Dunlap 

commit f5c2b6da26d9becd5a1a03fcd3e5c950301030a2
Author: Carlo Nonato 
Date:   Thu Mar 21 09:47:21 2024 +0100

    xen/page_alloc: introduce page flag to stop buddy merging
    
    Add a new PGC_no_buddy_merge flag that prevents the buddy algorithm in
    free_heap_pages() from merging pages that have it set. As of now, only
    PGC_static has this feature, but future work can extend it easier than
    before.
    
    Suggested-by: Jan Beulich 
    Signed-off-by: Carlo Nonato 
    Reviewed-by: Jan Beulich 

commit 75214d5e53f60a7b19e90ebdb090c20044a052ca
Author: Carlo Nonato 
Date:   Thu Mar 21 09:46:42 2024 +0100

    xen/page_alloc: introduce preserved page flags macro
    
    PGC_static and PGC_extra needs to be preserved when assigning a page.
    Define a new macro that groups those flags and use it instead of or'ing
    every time.
    
    To make preserved flags even more meaningful, they are kept also when
    switching state in mark_page_free().
    
    Signed-off-by: Carlo Nonato 
    Reviewed-by: Jan Beulich 

commit 6eb13b6b1d984af87460f60f2c0cbc5c059b8402
Author: Elliott Mitchell 
Date:   Thu Mar 21 09:46:13 2024 +0100

    tools/xl_parse: remove message for tsc mode string
    
    Normal behavior is to be silent.  Generating a message for the preferred
    input can be mistaken for an error.  As such remove this message to match
    other conditions.
    
    Signed-off-by: Elliott Mitchell 
    Acked-by: Anthony PERARD 
(qemu changes not included)


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 12:10:58 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 12:10:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696374.1087258 (Exim 4.92)
	(envelope-from )
	id 1rnHG5-00076p-R0; Thu, 21 Mar 2024 12:10:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696374.1087258; Thu, 21 Mar 2024 12:10:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnHG5-00076f-OH; Thu, 21 Mar 2024 12:10:57 +0000
Received: by outflank-mailman (input) for mailman id 696374;
 Thu, 21 Mar 2024 12:10:56 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnHG4-00076Q-53
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 12:10:56 +0000
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com
 [2a00:1450:4864:20::633])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 10d435fb-e77c-11ee-a1ee-f123f15fe8a2;
 Thu, 21 Mar 2024 13:10:54 +0100 (CET)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-a4715d4c2cbso58111066b.1
 for ; Thu, 21 Mar 2024 05:10:54 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 pv27-20020a170907209b00b00a46647b6496sm8399681ejb.155.2024.03.21.05.10.53
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 21 Mar 2024 05:10:53 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 10d435fb-e77c-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711023053; x=1711627853; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=XO9k/htEkRMqn/gfxjgK3aNYoKETEQEK/Fl7s4Vm5ws=;
        b=IthY04j0ZcrynIQY41OS8kQA0c/2GHYHsyqpx72DkF8Ms0aeSbbD8iq6TDa9ZSF31r
         3liCb/7PTySdXd5yi9BDVFaNCju4vIEwftZ4RXFpuwDUExU5Ikv233AcXflUSrhTMvfl
         ZujK9NLpe63anrZV53g1lwe6KMzW4SWWU2oflZWcmZCRrTjSq+kCJz50XE4qKWoUnc1W
         iTlLiXcALaeKTowPpsVSqhD46Ud4Zq+5Sk/XxQvLYBTcBFY6NqBOLeg9VEwVY/EgY0aP
         h+kA5MuPqK9xZhrd1DxVOC5L6Xt6nCytocCkvPqCHEnAZS4p2zgJf01MpoFgqDOTvayR
         aaEA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711023053; x=1711627853;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=XO9k/htEkRMqn/gfxjgK3aNYoKETEQEK/Fl7s4Vm5ws=;
        b=EX+LkHsfWdOJpqaCwdqRkqbp7Hg7/AHh2fGqV+jbZWpJwfeUPfafHQch7Dv/CqSMd8
         rF3gMAU1lDFCRh1EQuRUIznRgbVs0mrUoASWQMpkeufHeFCkJ8HsDuIl2PaJLRSuMsvV
         H7Kb7xHxEm9iQ5J+phd8S0ZW57sKVr6aEEAWQjcroZjkMcWcpC4PpBllylAiNjyqFZXL
         4aPkkqdk+E1LGuhIw1pdmDAs/xSz9BTnbcdAr94sWsclhXOnrvrOUy3/J1mMizjDqlkf
         xPoSMtDBuHEwiFAjJPDHil7PkuBS+RJG208OiVxlWspvsEyuj4dzueBUAFDmHLwe+2YK
         BWrQ==
X-Forwarded-Encrypted: i=1; AJvYcCVVILik1zwbaBrM8GdklhQK7mdecM5Ep8FZ5rtRWFUNLA07VKrbMNbfLKbfARddd0Dkc3f96XY7YZ9khdbFT7TFBpNq55c/ARyrg6cmR88=
X-Gm-Message-State: AOJu0YzmaRtFOieuUUkYevQfJb82NV7oecVAdDzxpCAZedBA2m33wqfI
	Xj33Aoqhy8MW21hvACdFFAd9lG9ri/On/4q0H2gO6/gkQ1087gkORnBx5a9qOA==
X-Google-Smtp-Source: AGHT+IHz+gxleuGA1bMk/ILOUZ4m4koPgH5hSk8CX9Fcw/msQb6Y13nt8hYNoNsE1RNdBH6gRHqjLw==
X-Received: by 2002:a17:907:86a5:b0:a46:967b:7c94 with SMTP id qa37-20020a17090786a500b00a46967b7c94mr14371351ejc.18.1711023053670;
        Thu, 21 Mar 2024 05:10:53 -0700 (PDT)
Message-ID: 
Date: Thu, 21 Mar 2024 13:10:52 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/console: add comment about external console lock
 helper
Content-Language: en-US
To: Roger Pau Monne 
Cc: Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 xen-devel@lists.xenproject.org
References: <20240321110503.72916-1-roger.pau@citrix.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240321110503.72916-1-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 21.03.2024 12:05, Roger Pau Monne wrote:
> The current console_lock_recursive_irqsave() implementation is not speculation
> safe, however it's only used to prevent interleaved output.  Note this in the
> function declaration in order for callers to be aware of the limitation.
> 
> No functional change.
> 
> Signed-off-by: Roger Pau Monné 

Acked-by: Jan Beulich 




From xen-devel-bounces@lists.xenproject.org Thu Mar 21 12:27:30 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 12:27:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696383.1087268 (Exim 4.92)
	(envelope-from )
	id 1rnHVt-0001WF-9O; Thu, 21 Mar 2024 12:27:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696383.1087268; Thu, 21 Mar 2024 12:27:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnHVt-0001W8-6f; Thu, 21 Mar 2024 12:27:17 +0000
Received: by outflank-mailman (input) for mailman id 696383;
 Thu, 21 Mar 2024 12:27:16 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnHVs-0001W0-5W
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 12:27:16 +0000
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com
 [2a00:1450:4864:20::535])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 58a5ff57-e77e-11ee-a1ee-f123f15fe8a2;
 Thu, 21 Mar 2024 13:27:13 +0100 (CET)
Received: by mail-ed1-x535.google.com with SMTP id
 4fb4d7f45d1cf-56b857bac38so484889a12.0
 for ; Thu, 21 Mar 2024 05:27:13 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 x6-20020a056402414600b00568803d97d1sm674674eda.9.2024.03.21.05.27.12
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 21 Mar 2024 05:27:12 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 58a5ff57-e77e-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711024033; x=1711628833; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=0o1+SBcMgeogLeSgpnjSdauxk6lVd8QSvIuz9XJ6608=;
        b=SGevtqnkz/S83KPL3kTn3tj/oQZv2w/sInlU8dGG8xcPXjeoOReyqLAViBFYctGrr5
         QAa1hMMA1d9AbJZyZynAUUlGyZolf73gz7Bo/+QPkWVkcy+hi9fN3kYIljEsBBj1lZwi
         RWvnMZQtpNH3TO5E8TyFO5T8+EZ1IhuUf5HPsyXSLYsW1HNqdrrqNFR077etLRTApNvQ
         Pw1IMfTrUN6EB77h276jxINFE5y0uG4pQmrzzKdUvUefXfNXazCGPmuEpKn5b1IiGo08
         +PBNF8zKUUvW+mk128ABtJDj9p11ITrUvfPXU1y4NKCl2sWRrZi9QGbvCujf1Roiv+oO
         /GRw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711024033; x=1711628833;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=0o1+SBcMgeogLeSgpnjSdauxk6lVd8QSvIuz9XJ6608=;
        b=XAFAID0IQZJA8rHWX+DoUUm9O3sVgfa6MSI3oJRrFAxy/HEngog3l2mlYbYXrGVInX
         BnpSTj5rnROsE5DvVeu4PBtLgCnbl2yExC6wVb1Nz/VgYvy0BOjXim4s4z07cD2P7ct1
         /UigBnN+gMrD8jWZ3icmBTXJmOfQrALG4Z7xYGOpsRZfKV4wZBdt8Fqed/phBy46rswQ
         cuK0KrlDOfQPqTb/AgXtld4N0Cn4UpbWvznyJDTvFy2WNIhptHCYgLnLqLWBF4Gxeyc2
         B8WrP6BergytwZ6KjKF4NhFINzTHuj4wQU5NVobMDc7/thTzEq45J/lW4XO6NrzHXu6C
         u8Ag==
X-Forwarded-Encrypted: i=1; AJvYcCUXeh1i4ecTXHl6vuv52cUCsTwy1nTRxYZSb5TyKCFJFPHN3dW7Mt2Mm2ZvQeSw0KEyRpfKsdcqZOHk8wOyuUIc+NS8DpIjhf5+UW8rogQ=
X-Gm-Message-State: AOJu0YxcDAS/qYFN3L2zCMZaE7LFWdVbyYwNvEj5f03Oj9PF8HCzqlV1
	DRtGSMgLQfbE2EaEpmi7gD+cnu2iIo+GqiK0CqP41MLiksQSjkLhXtn0Bkequw==
X-Google-Smtp-Source: AGHT+IED+GktLOGS84LK1blPzWOrNneh6wYw07UjeFM8uXotVDHq7qzYFclqBKUFVDXcGPIWHbTJJg==
X-Received: by 2002:a50:c192:0:b0:565:6e34:da30 with SMTP id m18-20020a50c192000000b005656e34da30mr1583644edf.21.1711024032987;
        Thu, 21 Mar 2024 05:27:12 -0700 (PDT)
Message-ID: <49dd40b6-4558-4e0c-b6ab-eee5b814dd8d@suse.com>
Date: Thu, 21 Mar 2024 13:27:11 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 09/20] xen/riscv: introduce io.h
Content-Language: en-US
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 xen-devel@lists.xenproject.org
References: 
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 15.03.2024 19:06, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/arch/riscv/include/asm/io.h
> @@ -0,0 +1,167 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + *  The header taken form Linux 6.4.0-rc1 and is based on
> + *  arch/riscv/include/asm/mmio.h with the following changes:
> + *   - drop forcing of endianess for read*(), write*() functions as
> + *     no matter what CPU endianness, what endianness a particular device
> + *     (and hence its MMIO region(s)) is using is entirely independent.
> + *     Hence conversion, where necessary, needs to occur at a layer up.
> + *     Another one reason to drop endianess conversion is:
> + *     https://patchwork.kernel.org/project/linux-riscv/patch/20190411115623.5749-3-hch@lst.de/
> + *     One of the answers of the author of the commit:
> + *       And we don't know if Linux will be around if that ever changes.
> + *       The point is:
> + *        a) the current RISC-V spec is LE only
> + *        b) the current linux port is LE only except for this little bit
> + *       There is no point in leaving just this bitrotting code around.  It
> + *       just confuses developers, (very very slightly) slows down compiles
> + *      and will bitrot.  It also won't be any significant help to a future
> + *       developer down the road doing a hypothetical BE RISC-V Linux port.
> + *   - drop unused argument of __io_ar() macros.
> + *   - drop "#define _raw_{read,write}{b,w,l,d,q} _raw_{read,write}{b,w,l,d,q}"

In the commit message I'm not worried as much, but at least here the odd mention
of d as suffixes would better be purged.

> + *     as they are unnecessary.
> + *   - Adopt the Xen code style for this header, considering that significant
> + *     changes are not anticipated in the future.
> + *     In the event of any issues, adapting them to Xen style should be easily
> + *     manageable.
> + *   - drop unnecessary __r variables in macros read*_cpu()
> + *   - update inline assembler constraints for addr argument for
> + *     __raw_read{b,w,l,q} and __raw_write{b,w,l,q} to tell a compiler that
> + *     *addr will be accessed.
> + *
> + * Copyright (C) 1996-2000 Russell King
> + * Copyright (C) 2012 ARM Ltd.
> + * Copyright (C) 2014 Regents of the University of California
> + * Copyright (C) 2024 Vates
> + */
> +
> +#ifndef _ASM_RISCV_IO_H
> +#define _ASM_RISCV_IO_H
> +
> +#include 
> +
> +/*
> + * The RISC-V ISA doesn't yet specify how to query or modify PMAs, so we can't
> + * change the properties of memory regions.  This should be fixed by the
> + * upcoming platform spec.
> + */
> +#define ioremap_nocache(addr, size) ioremap(addr, size)
> +#define ioremap_wc(addr, size) ioremap(addr, size)
> +#define ioremap_wt(addr, size) ioremap(addr, size)
> +
> +/* Generic IO read/write.  These perform native-endian accesses. */
> +static inline void __raw_writeb(uint8_t val, volatile void __iomem *addr)
> +{
> +    asm volatile ( "sb %1, %0" : "=m" (*(volatile uint8_t __force *)addr) : "r" (val) );

Please respect line length restrictions.

> +}
> +
> +static inline void __raw_writew(uint16_t val, volatile void __iomem *addr)
> +{
> +    asm volatile ( "sh %1, %0" : "=m" (*(volatile uint16_t __force *)addr) : "r" (val) );
> +}
> +
> +static inline void __raw_writel(uint32_t val, volatile void __iomem *addr)
> +{
> +    asm volatile ( "sw %1, %0" : "=m" (*(volatile uint32_t __force *)addr) : "r" (val) );
> +}
> +
> +#ifdef CONFIG_RISCV_32
> +static inline void __raw_writeq(uint64_t val, volatile void __iomem *addr)
> +{
> +    BUILD_BUG_ON("unimplemented\n");
> +}
> +#else
> +static inline void __raw_writeq(uint64_t val, volatile void __iomem *addr)
> +{
> +    asm volatile ( "sd %1, %0" : "=m" (*(volatile uint64_t __force *)addr) : "r" (val) );
> +}
> +#endif

Please avoid code duplication if it easily can be avoided:

static inline void __raw_writeq(uint64_t val, volatile void __iomem *addr)
{
#ifdef CONFIG_RISCV_32
    BUILD_BUG_ON("unimplemented");
#else
    asm volatile ( "sd %1, %0" : "=m" (*(volatile uint64_t __force *)addr) : "r" (val) );
#endif
}

(Note also the dropped \n.)

> +static inline uint8_t __raw_readb(const volatile void __iomem *addr)
> +{
> +    uint8_t val;
> +
> +    asm volatile ( "lb %0, %1" : "=r" (val) : "m" (*(volatile uint8_t __force *)addr) );

Please don't cast away const.

> +    return val;
> +}
> +
> +static inline uint16_t __raw_readw(const volatile void __iomem *addr)
> +{
> +    uint16_t val;
> +
> +    asm volatile ( "lh %0, %1" : "=r" (val) : "m" (*(volatile uint16_t __force *)addr) );
> +    return val;
> +}
> +
> +static inline uint32_t __raw_readl(const volatile void __iomem *addr)
> +{
> +    uint32_t val;
> +
> +    asm volatile ( "lw %0, %1" : "=r" (val) : "m" (*(volatile uint32_t __force *)addr) );
> +    return val;
> +}
> +
> +#ifdef CONFIG_RISCV_32
> +static inline uint64_t __raw_readq(const volatile void __iomem *addr)
> +{
> +    BUILD_BUG_ON("unimplemented\n");
> +    return 0;
> +}
> +#else
> +static inline uint64_t __raw_readq(const volatile void __iomem *addr)
> +{
> +    uint64_t val;
> +
> +    asm volatile ( "ld %0, %1" : "=r" (val) : "m" (*(volatile uint64_t __force *)addr) );
> +    return val;
> +}
> +#endif
> +
> +/*
> + * Unordered I/O memory access primitives.  These are even more relaxed than
> + * the relaxed versions, as they don't even order accesses between successive
> + * operations to the I/O regions.
> + */
> +#define readb_cpu(c)        __raw_readb(c)
> +#define readw_cpu(c)        __raw_readw(c)
> +#define readl_cpu(c)        __raw_readl(c)
> +
> +#define writeb_cpu(v, c)    __raw_writeb(v, c)
> +#define writew_cpu(v, c)    __raw_writew(v, c)
> +#define writel_cpu(v, c)    __raw_writel(v, c)
> +
> +#define readq_cpu(c)        __raw_readq(c)
> +#define writeq_cpu(v, c)    __raw_writeq(v, c)

Since (now?) outside of any #ifdef (which is okay with me), why not each
grouped with their respective 3 siblings?

> +/*
> + * I/O memory access primitives. Reads are ordered relative to any
> + * following Normal memory access. Writes are ordered relative to any prior
> + * Normal memory access.  The memory barriers here are necessary as RISC-V
> + * doesn't define any ordering between the memory space and the I/O space.
> + */
> +#define __io_br()   do { } while (0)
> +#define __io_ar()   asm volatile ( "fence i,r" : : : "memory" );
> +#define __io_bw()   asm volatile ( "fence w,o" : : : "memory" );
> +#define __io_aw()   do { } while (0)
> +
> +#define readb(c)    ({ uint8_t  v; __io_br(); v = readb_cpu(c); __io_ar(); v; })

I'm wary of "v" as a macro local: What if at a use site there's

    x = readb(v);

? That'll fail to compile, provided at the use site v is actually a pointer,
but the reason for the error won't necessarily be obvious. (Hence why in the
past people did prefix underscores on such local variable names, while now
we're advocating for suffixes.)

> +#define readw(c)    ({ uint16_t v; __io_br(); v = readw_cpu(c); __io_ar(); v; })
> +#define readl(c)    ({ uint32_t v; __io_br(); v = readl_cpu(c); __io_ar(); v; })
> +
> +#define writeb(v, c)    ({ __io_bw(); writeb_cpu(v, c); __io_aw(); })
> +#define writew(v, c)    ({ __io_bw(); writew_cpu(v, c); __io_aw(); })
> +#define writel(v, c)    ({ __io_bw(); writel_cpu(v, c); __io_aw(); })
> +
> +#define readq(c)        ({ uint64_t v; __io_br(); v = readq_cpu(c); __io_ar(); v; })
> +#define writeq(v, c)    ({ __io_bw(); writeq_cpu(v, c); __io_aw(); })

Same here then.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 12:47:57 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 12:47:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696389.1087285 (Exim 4.92)
	(envelope-from )
	id 1rnHpi-00053q-0j; Thu, 21 Mar 2024 12:47:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696389.1087285; Thu, 21 Mar 2024 12:47:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnHph-00053j-TM; Thu, 21 Mar 2024 12:47:45 +0000
Received: by outflank-mailman (input) for mailman id 696389;
 Thu, 21 Mar 2024 12:47:43 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnHpf-00053Y-On; Thu, 21 Mar 2024 12:47:43 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnHpf-0000rA-NA; Thu, 21 Mar 2024 12:47:43 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnHpf-0006eI-CV; Thu, 21 Mar 2024 12:47:43 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rnHpf-0003LB-C5; Thu, 21 Mar 2024 12:47:43 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=dctBoclxYjAag9l2rQMhxHSA0/+9rY99c3SZwdoYgUE=; b=jkTtAy1G8vJ5A/EnRMH7bCOSzl
	f+7ra+ICMIjEQXu1LO3D1b1+I5zabnwBp3cUClH8fV8ZwNUa0CikMsgpzqL9g1qzOSKhQChAdpSvI
	zw6m0jGgro31XejZ6MCPziwYoUmSzbSlvh2fLvQVKheIq2QbEKUOIJvcvIx0Bg2LB4nQ=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 185117: tolerable FAIL - PUSHED
X-Osstest-Failures:
    xen-unstable:test-amd64-amd64-qemuu-freebsd12-amd64:guest-start/freebsd.repeat:fail:heisenbug
    xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-qcow2:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-qcow2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-raw:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-vhd:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    xen=eaafbd11344a8ec32309fe58a6e529fe1c34d62e
X-Osstest-Versions-That:
    xen=188fa82305e72b725473db9146e20cc9abf7bff3
From: osstest service owner 
Date: Thu, 21 Mar 2024 12:47:43 +0000

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-qemuu-freebsd12-amd64 21 guest-start/freebsd.repeat fail pass in 185122-retest

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

version targeted for testing:
 xen                  eaafbd11344a8ec32309fe58a6e529fe1c34d62e
baseline version:
 xen                  188fa82305e72b725473db9146e20cc9abf7bff3

Last test of basis   185106  2024-03-20 07:05:54 Z    1 days
Testing same since   185117  2024-03-20 23:10:53 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Anthony PERARD 
  Julien Grall 

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-libvirt-qcow2                               pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-xl-qcow2                                    pass    
 test-amd64-amd64-libvirt-raw                                 pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-amd64-amd64-xl-raw                                      pass    
 test-armhf-armhf-xl-raw                                      pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-libvirt-vhd                                 pass    
 test-amd64-amd64-xl-vhd                                      pass    
 test-arm64-arm64-xl-vhd                                      pass    


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

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

Explanation of these 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
   188fa82305..eaafbd1134  eaafbd11344a8ec32309fe58a6e529fe1c34d62e -> master


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 13:03:39 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 13:03:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696398.1087294 (Exim 4.92)
	(envelope-from )
	id 1rnI4y-0008U2-E7; Thu, 21 Mar 2024 13:03:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696398.1087294; Thu, 21 Mar 2024 13:03:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnI4y-0008Tv-B9; Thu, 21 Mar 2024 13:03:32 +0000
Received: by outflank-mailman (input) for mailman id 696398;
 Thu, 21 Mar 2024 13:03:30 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnI4w-0008Tp-P3
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 13:03:30 +0000
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com
 [2a00:1450:4864:20::533])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 68cbe05a-e783-11ee-a1ee-f123f15fe8a2;
 Thu, 21 Mar 2024 14:03:28 +0100 (CET)
Received: by mail-ed1-x533.google.com with SMTP id
 4fb4d7f45d1cf-5658082d2c4so1179345a12.1
 for ; Thu, 21 Mar 2024 06:03:28 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 eo12-20020a056402530c00b0056bced75f05sm427581edb.77.2024.03.21.06.03.26
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 21 Mar 2024 06:03:27 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 68cbe05a-e783-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711026207; x=1711631007; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=fPZw3NeSP7icVBlGeA7Bx7Y/cSSmhmpJ4ZWAtkFAa6s=;
        b=CKtnx7hTZk/DEXZRSsR28GUlKgg3WhYIIMdVfwRUE3nxGUt0o1UqtW5pppd7kvFVbX
         gU2BvbZw5aU+3nXpYXCcd3aRhL37QYKAPNpOtXrd82KRfNCxxlbaOtp/IgSXmuXmxgXa
         BxA0iwSSv4MKgGiZaz4lfRtTb2/7vDcjHznAjzhv+znweFgQiFUzK5EeEWJbpNgg/xHb
         6Hnbxd+pC9sgVw6X8h5IIujYYxyVi0IEWJ+JBNcqXnl6rmLmzn9JFeZCnDtTx9b8OtYQ
         2wTp17o+F4vRokTE8VDwubc3PBHOFf6A5ByhYwowIPrpFwZkdv8s5pmEo9D7qkKl3Rgt
         OqAw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711026207; x=1711631007;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=fPZw3NeSP7icVBlGeA7Bx7Y/cSSmhmpJ4ZWAtkFAa6s=;
        b=rSFafRCCSquaO5sm+wVxHOoXZ18Q1Ut+hLfFFe4FMyx+gGvR5QSH5P/54NIaBaKRcW
         jj84Cl5vtkcceKGGzAZD0Ir3AtURISx9jK8gr+2XbQOMx0u57pzJTjirAUjKTD0kjFSe
         M4MwL9L+0QNbNgo8mAkED8TD+OXYdGBVcakvK3CIaJrn17/wFM2OZCNcl2NXVBJ2bep7
         Rv2Hlucq6ksYqUvrIg1J743eTg2DOZw294d8ZPf+V58vyrJKWXW537s4azZvuS1dB90p
         0w1IXl7qfZly8sK1CSITOILpiC8bgxjacg6lkhY0JJ2hIJJ4eroNMKO1P10qWQeCXBv9
         hyLg==
X-Forwarded-Encrypted: i=1; AJvYcCXIKB+aT4drehZ4kFCWhs1wNP5q8R/E07C2fEUz1g6pLRTpQxl1o4KzdTkmOHcVJ+eQVulFhUezC+ECYuEO4ZQ6QmjEuyTqjW9HdprK6sc=
X-Gm-Message-State: AOJu0YwWI/DKth1SXgQOI5En3HlqeT1/zLqFO0Bgq9GaUwLJ4Y9piE6H
	+vBOsHa6nXc5FvA3jCALlnv2Jlu+jODRTNNIEDekqiIGRGRqc6KnNDf7VS/2yg==
X-Google-Smtp-Source: AGHT+IFox8XiI8dXU6lrOcSnqRZtVEqlR9mS7uofBcOrpSLH6QfV98LheEpcynaSMBeGLDNNFaPa6g==
X-Received: by 2002:a05:6402:e07:b0:567:4694:159 with SMTP id h7-20020a0564020e0700b0056746940159mr13265884edh.26.1711026207347;
        Thu, 21 Mar 2024 06:03:27 -0700 (PDT)
Message-ID: <78a86041-72e2-410f-b6a7-212656b0dba3@suse.com>
Date: Thu, 21 Mar 2024 14:03:25 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 10/20] xen/riscv: introduce atomic.h
Content-Language: en-US
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 xen-devel@lists.xenproject.org
References: 
 <22ee9c8cc62c76cfb799fed800636e7c8bf25a17.1710517542.git.oleksii.kurochko@gmail.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <22ee9c8cc62c76cfb799fed800636e7c8bf25a17.1710517542.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 15.03.2024 19:06, Oleksii Kurochko wrote:
> Initially the patch was introduced by Bobby, who takes the header from
> Linux kernel.
> 
> The following changes were done on top of Linux kernel header:
>  - atomic##prefix##_*xchg_*(atomic##prefix##_t *v, c_t n) were updated
>      to use__*xchg_generic()
>  - drop casts in write_atomic() as they are unnecessary
>  - drop introduction of WRITE_ONCE() and READ_ONCE().
>    Xen provides ACCESS_ONCE()

Here and in the code comment: While this may be describing what you did
on top of what Bobby had, here you're describing differences to the Linux
header.

>  - remove zero-length array access in read_atomic()
>  - drop defines similar to pattern

pattern? Which one? Oh, wait, ...

>  - #define atomic_add_return_relaxed   atomic_add_return_relaxed

... this line really isn't a separate bullet point.

> Changes in V6:
>  - drop atomic##prefix##_{cmp}xchg_{release, aquire, relaxed} as they aren't used
>    by Xen
>  - code style fixes.
>  - %s/__asm__ __volatile__/asm volatile

Btw, this is another activity that could do with being carried out
consistently through the series.

> --- /dev/null
> +++ b/xen/arch/riscv/include/asm/atomic.h
> @@ -0,0 +1,263 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Taken and modified from Linux.
> + *
> + * The following changes were done:
> + * - * atomic##prefix##_*xchg_*(atomic##prefix##_t *v, c_t n) were updated
> + *     to use__*xchg_generic()
> + * - drop casts in write_atomic() as they are unnecessary
> + * - drop introduction of WRITE_ONCE() and READ_ONCE().
> + *   Xen provides ACCESS_ONCE()
> + * - remove zero-length array access in read_atomic()
> + * - drop defines similar to pattern
> + *   #define atomic_add_return_relaxed   atomic_add_return_relaxed
> + * - move not RISC-V specific functions to asm-generic/atomics-ops.h
> + * 
> + * Copyright (C) 2007 Red Hat, Inc. All Rights Reserved.
> + * Copyright (C) 2012 Regents of the University of California
> + * Copyright (C) 2017 SiFive
> + * Copyright (C) 2024 Vates SAS
> + */
> +
> +#ifndef _ASM_RISCV_ATOMIC_H
> +#define _ASM_RISCV_ATOMIC_H
> +
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +void __bad_atomic_size(void);
> +
> +/*
> + * Legacy from Linux kernel. For some reason they wanted to have ordered
> + * read/write access. Thereby read* is used instead of read_cpu()

Either read and read_cpu() or read* and read*_cpu(), please.

> + */
> +static always_inline void read_atomic_size(const volatile void *p,
> +                                           void *res,
> +                                           unsigned int size)
> +{
> +    switch ( size )
> +    {
> +    case 1: *(uint8_t *)res = readb(p); break;
> +    case 2: *(uint16_t *)res = readw(p); break;
> +    case 4: *(uint32_t *)res = readl(p); break;
> +    case 8: *(uint32_t *)res  = readq(p); break;

Nit: Excess blank before =.

Also - no #ifdef here to be RV32-ready?

> +    default: __bad_atomic_size(); break;
> +    }
> +}
> +
> +#define read_atomic(p) ({                                   \
> +    union { typeof(*(p)) val; char c[sizeof(*(p))]; } x_;   \

One trailing underscore here, but ...

> +    read_atomic_size(p, x_.c, sizeof(*(p)));                \
> +    x_.val;                                                 \
> +})
> +
> +#define write_atomic(p, x)                              \
> +({                                                      \
> +    typeof(*(p)) x__ = (x);                             \

... two here and ...

> +    switch ( sizeof(*(p)) )                             \
> +    {                                                   \
> +    case 1: writeb(x__, p); break;                      \
> +    case 2: writew(x__, p); break;                      \
> +    case 4: writel(x__, p); break;                      \
> +    case 8: writeq(x__, p); break;                      \
> +    default: __bad_atomic_size(); break;                \
> +    }                                                   \
> +    x__;                                                \
> +})
> +
> +#define add_sized(p, x)                                 \
> +({                                                      \
> +    typeof(*(p)) x__ = (x);                             \

... here?

> +    switch ( sizeof(*(p)) )                             \
> +    {                                                   \
> +    case 1: writeb(read_atomic(p) + x__, p); break;     \
> +    case 2: writew(read_atomic(p) + x__, p); break;     \
> +    case 4: writel(read_atomic(p) + x__, p); break;     \
> +    case 8: writeq(read_atomic(p) + x__, p); break;     \
> +    default: __bad_atomic_size(); break;                \
> +    }                                                   \
> +})
> +
> +#define __atomic_acquire_fence() \
> +    asm volatile ( RISCV_ACQUIRE_BARRIER "" ::: "memory" )
> +
> +#define __atomic_release_fence() \
> +    asm volatile ( RISCV_RELEASE_BARRIER "" ::: "memory" )
> +
> +/*
> + * First, the atomic ops that have no ordering constraints and therefor don't
> + * have the AQ or RL bits set.  These don't return anything, so there's only
> + * one version to worry about.
> + */
> +#define ATOMIC_OP(op, asm_op, I, asm_type, c_type, prefix)  \
> +static inline                                               \
> +void atomic##prefix##_##op(c_type i, atomic##prefix##_t *v) \
> +{                                                           \
> +    asm volatile (                                          \
> +        "   amo" #asm_op "." #asm_type " zero, %1, %0"      \
> +        : "+A" (v->counter)                                 \
> +        : "r" (I)                                           \

Btw, I consider this pretty confusing. At the 1st and 2nd glance this
looks like a mistake, i.e. as if i was meant. Imo ...

> +        : "memory" );                                       \
> +}                                                           \
> +
> +/*
> + * Only CONFIG_GENERIC_ATOMIC64=y was ported to Xen that is the reason why
> + * last argument for ATOMIC_OP isn't used.
> + */
> +#define ATOMIC_OPS(op, asm_op, I)                           \
> +        ATOMIC_OP (op, asm_op, I, w, int,   )
> +
> +ATOMIC_OPS(add, add,  i)
> +ATOMIC_OPS(sub, add, -i)
> +ATOMIC_OPS(and, and,  i)
> +ATOMIC_OPS( or,  or,  i)
> +ATOMIC_OPS(xor, xor,  i)

... here you want to only pass the (unary) operator (and leaving that blank
is as fine as using +).

> +#undef ATOMIC_OP
> +#undef ATOMIC_OPS
> +
> +#include 
> +
> +/*
> + * Atomic ops that have ordered, relaxed, acquire, and release variants.

Only the first is implemented afaict; imo the comment would better reflect
that one way or another.

> + * There's two flavors of these: the arithmatic ops have both fetch and return
> + * versions, while the logical ops only have fetch versions.
> + */
> +#define ATOMIC_FETCH_OP(op, asm_op, I, asm_type, c_type, prefix)    \
> +static inline                                                       \
> +c_type atomic##prefix##_fetch_##op##_relaxed(c_type i,              \
> +                         atomic##prefix##_t *v)                     \
> +{                                                                   \
> +    register c_type ret;                                            \
> +    asm volatile (                                                  \
> +        "   amo" #asm_op "." #asm_type " %1, %2, %0"                \
> +        : "+A" (v->counter), "=r" (ret)                             \
> +        : "r" (I)                                                   \
> +        : "memory" );                                               \
> +    return ret;                                                     \
> +}                                                                   \

Actually a relaxed form is provided here, but does that have any user?

> +static inline                                                       \
> +c_type atomic##prefix##_fetch_##op(c_type i, atomic##prefix##_t *v) \
> +{                                                                   \
> +    register c_type ret;                                            \
> +    asm volatile (                                                  \
> +        "   amo" #asm_op "." #asm_type ".aqrl  %1, %2, %0"          \
> +        : "+A" (v->counter), "=r" (ret)                             \
> +        : "r" (I)                                                   \
> +        : "memory" );                                               \
> +    return ret;                                                     \
> +}
> +
> +#define ATOMIC_OP_RETURN(op, asm_op, c_op, I, asm_type, c_type, prefix) \
> +static inline                                                           \
> +c_type atomic##prefix##_##op##_return_relaxed(c_type i,                 \
> +                          atomic##prefix##_t *v)                        \
> +{                                                                       \
> +        return atomic##prefix##_fetch_##op##_relaxed(i, v) c_op I;      \
> +}                                                                       \
> +static inline                                                           \
> +c_type atomic##prefix##_##op##_return(c_type i, atomic##prefix##_t *v)  \
> +{                                                                       \
> +        return atomic##prefix##_fetch_##op(i, v) c_op I;                \

I (or whatever the replacement expression is going to be following the
earlier comment) wants parenthesizing here.

> +}
> +
> +/*
> + * Only CONFIG_GENERIC_ATOMIC64=y was ported to Xen that is the reason why
> + * last argument of ATOMIC_FETCH_OP, ATOMIC_OP_RETURN isn't used.
> + */
> +#define ATOMIC_OPS(op, asm_op, c_op, I)                                 \
> +        ATOMIC_FETCH_OP( op, asm_op,       I, w, int,   )               \
> +        ATOMIC_OP_RETURN(op, asm_op, c_op, I, w, int,   )
> +
> +ATOMIC_OPS(add, add, +,  i)
> +ATOMIC_OPS(sub, add, +, -i)
> +
> +#undef ATOMIC_OPS
> +
> +#define ATOMIC_OPS(op, asm_op, I) \
> +        ATOMIC_FETCH_OP(op, asm_op, I, w, int,   )
> +
> +ATOMIC_OPS(and, and, i)
> +ATOMIC_OPS( or,  or, i)
> +ATOMIC_OPS(xor, xor, i)
> +
> +#undef ATOMIC_OPS
> +
> +#undef ATOMIC_FETCH_OP
> +#undef ATOMIC_OP_RETURN
> +
> +/* This is required to provide a full barrier on success. */
> +static inline int atomic_add_unless(atomic_t *v, int a, int u)
> +{
> +       int prev, rc;
> +
> +    asm volatile (
> +        "0: lr.w     %[p],  %[c]\n"
> +        "   beq      %[p],  %[u], 1f\n"
> +        "   add      %[rc], %[p], %[a]\n"
> +        "   sc.w.rl  %[rc], %[rc], %[c]\n"
> +        "   bnez     %[rc], 0b\n"
> +        RISCV_FULL_BARRIER

With this and no .aq on the load, why the .rl on the store?

> +        "1:\n"
> +        : [p] "=&r" (prev), [rc] "=&r" (rc), [c] "+A" (v->counter)
> +        : [a] "r" (a), [u] "r" (u)
> +        : "memory");
> +    return prev;
> +}
> +
> +/*
> + * atomic_{cmp,}xchg is required to have exactly the same ordering semantics as
> + * {cmp,}xchg and the operations that return.
> + */
> +#define ATOMIC_OP(c_t, prefix, size)                            \
> +static inline                                                   \
> +c_t atomic##prefix##_xchg(atomic##prefix##_t *v, c_t n)         \
> +{                                                               \
> +    return __xchg(&(v->counter), n, size);                      \

No need for the inner parentheses, just like ...

> +}                                                               \
> +static inline                                                   \
> +c_t atomic##prefix##_cmpxchg(atomic##prefix##_t *v, c_t o, c_t n) \
> +{                                                               \
> +    return __cmpxchg(&v->counter, o, n, size);                  \

... you have it here.

> +}
> +
> +#define ATOMIC_OPS() \
> +    ATOMIC_OP(int,   , 4)
> +
> +ATOMIC_OPS()
> +
> +#undef ATOMIC_OPS
> +#undef ATOMIC_OP
> +
> +static inline int atomic_sub_if_positive(atomic_t *v, int offset)
> +{
> +       int prev, rc;
> +
> +    asm volatile (
> +        "0: lr.w     %[p],  %[c]\n"
> +        "   sub      %[rc], %[p], %[o]\n"
> +        "   bltz     %[rc], 1f\n"
> +        "   sc.w.rl  %[rc], %[rc], %[c]\n"
> +        "   bnez     %[rc], 0b\n"
> +        "   fence    rw, rw\n"
> +        "1:\n"
> +        : [p] "=&r" (prev), [rc] "=&r" (rc), [c] "+A" (v->counter)
> +        : [o] "r" (offset)
> +        : "memory" );
> +    return prev - offset;
> +}

This probably would be nicer if sitting next to atomic_add_unless().

> --- /dev/null
> +++ b/xen/include/asm-generic/atomic-ops.h
> @@ -0,0 +1,97 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * The header provides default implementations for every xen/atomic.h-provided
> + * forward inline declaration that can be synthesized from other atomic
> + * functions.

Or from scratch, as e.g. ...

> + */
> +#ifndef _ASM_GENERIC_ATOMIC_OPS_H_
> +#define _ASM_GENERIC_ATOMIC_OPS_H_
> +
> +#include 
> +#include 
> +
> +#ifndef ATOMIC_READ
> +static inline int atomic_read(const atomic_t *v)
> +{
> +    return ACCESS_ONCE(v->counter);
> +}
> +#endif
> +
> +#ifndef _ATOMIC_READ
> +static inline int _atomic_read(atomic_t v)
> +{
> +    return v.counter;
> +}
> +#endif
> +
> +#ifndef ATOMIC_SET
> +static inline void atomic_set(atomic_t *v, int i)
> +{
> +    ACCESS_ONCE(v->counter) = i;
> +}
> +#endif
> +
> +#ifndef _ATOMIC_SET
> +static inline void _atomic_set(atomic_t *v, int i)
> +{
> +    v->counter = i;
> +}
> +#endif

... all of these.

> +#ifndef ATOMIC_SUB_AND_TEST
> +static inline int atomic_sub_and_test(int i, atomic_t *v)
> +{
> +    return atomic_sub_return(i, v) == 0;
> +}
> +#endif
> +
> +#ifndef ATOMIC_INC
> +static inline void atomic_inc(atomic_t *v)
> +{
> +    atomic_add(1, v);
> +}
> +#endif
> +
> +#ifndef ATOMIC_INC_RETURN
> +static inline int atomic_inc_return(atomic_t *v)
> +{
> +    return atomic_add_return(1, v);
> +}
> +#endif
> +
> +#ifndef ATOMIC_DEC
> +static inline void atomic_dec(atomic_t *v)
> +{
> +    atomic_sub(1, v);
> +}
> +#endif
> +
> +#ifndef ATOMIC_DEC_RETURN
> +static inline int atomic_dec_return(atomic_t *v)
> +{
> +    return atomic_sub_return(1, v);
> +}
> +#endif
> +
> +#ifndef ATOMIC_DEC_AND_TEST
> +static inline int atomic_dec_and_test(atomic_t *v)
> +{
> +    return atomic_sub_return(1, v) == 0;
> +}
> +#endif
> +
> +#ifndef ATOMIC_ADD_NEGATIVE
> +static inline int atomic_add_negative(int i, atomic_t *v)
> +{
> +    return atomic_add_return(i, v) < 0;
> +}
> +#endif
> +
> +#ifndef ATOMIC_INC_AND_TEST
> +static inline int atomic_inc_and_test(atomic_t *v)
> +{
> +    return atomic_add_return(1, v) == 0;
> +}
> +#endif

Can this be moved up a little, perhaps next to the other inc-s (or else
next to dec_and_test), please?

Jan


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 13:26:40 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 13:26:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696407.1087310 (Exim 4.92)
	(envelope-from )
	id 1rnIR5-0003TB-7E; Thu, 21 Mar 2024 13:26:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696407.1087310; Thu, 21 Mar 2024 13:26:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnIR5-0003T4-4g; Thu, 21 Mar 2024 13:26:23 +0000
Received: by outflank-mailman (input) for mailman id 696407;
 Thu, 21 Mar 2024 13:26:21 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnIR3-0003Sy-Qv
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 13:26:21 +0000
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com
 [2a00:1450:4864:20::529])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9ae92bb1-e786-11ee-afe0-a90da7624cb6;
 Thu, 21 Mar 2024 14:26:20 +0100 (CET)
Received: by mail-ed1-x529.google.com with SMTP id
 4fb4d7f45d1cf-563c403719cso1143736a12.2
 for ; Thu, 21 Mar 2024 06:26:20 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 o13-20020aa7c50d000000b0056bda04d745sm22216edq.80.2024.03.21.06.26.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 21 Mar 2024 06:26:20 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9ae92bb1-e786-11ee-afe0-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711027580; x=1711632380; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=CVxPSMKD1lzwM7YafK4bG3T2U66+9r+T9THOgldtMxs=;
        b=V6swaD7s+aUvjnHMEaTOy3LPSQ8bCgPum0Rnc1t5OaxmKsWCAIAMGCrl6erHE/4ltH
         JYi/WariTCjs0wJWvNkO8DLv0b8eijbdP2v6cxj6mibkJwI6hIJ6B4hlWAW/yYcp8XWw
         GzLMMH8rDwBQjGHVmTUi1tz1xpeZqRqxs9G1sLEyCZC9LC7KAMWRbrWbp1eLyQclbeDh
         Xco5GigyFX1UDmXPLqoH6L6eIPSPheo/tPCc049bt8LoccDM1uEjzuh3mQtOd7226UOD
         +H3ZueiXrNKXKqPP8PEDjpioyRR0eHPl7raU8YhSvMdrT3h5snRbQ4dNClm8On68Cg5v
         RsJw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711027580; x=1711632380;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=CVxPSMKD1lzwM7YafK4bG3T2U66+9r+T9THOgldtMxs=;
        b=fR8Y5kwlb6xxtmqpmKIvjxurLDGhdzPE3nROoAo7/uS6Ez9SBDwk+zxqk8QrNlScF3
         6otX534lIfaIG/Ix4b/RDtbElCbNKhwbIAuwkjgl45yhfxXgCOBNRYjqBPu9IrwE6/FB
         d7LHP2Nv13F/7OlSAXcHMgB7w1SXdN5Whw4vjWLGj3gPXHMhX3GSdT7KaiByi9DetGC8
         TMCv7meuJX1pPXLazqzqGNurPwVfr0NpwE0fn8lCPEs/lv+FpoOYCjbGlbTqcBtjV9XO
         ETeuTb3SSkYBhrrulqU54H+cjIDX1uBDQdsiwBeWN81bS1ymSEgF7hDm/9JPfxJ7P38c
         hqJQ==
X-Forwarded-Encrypted: i=1; AJvYcCWZStaxqW1GYIEuBYZfxAJkGxbBWAOMUhVs2AhubNqOryQ7epkCoF6aUb3/py7SHYE1Loj5VaAVLfZgsgoJ/8Ost2ONdEa1RwFH7IWocGw=
X-Gm-Message-State: AOJu0YzwqupPzTciv/s8kYTBSgKkxUPH68G6qttaknhqbOfggAlHcjlT
	/swWV9RJ/URHJr5IITLep0mZzbViBUv/PpX6PQDt1N8SJ8qWq19za11v1cbw4A==
X-Google-Smtp-Source: AGHT+IHxy63jL0YXYB4fZTl0dsOn61VZZRDPqaMAd0usyojLOIihv3aUU6+3J9sM6kjh4WBSLL6unw==
X-Received: by 2002:a50:9e0a:0:b0:56b:cd66:52d2 with SMTP id z10-20020a509e0a000000b0056bcd6652d2mr1235925ede.23.1711027580218;
        Thu, 21 Mar 2024 06:26:20 -0700 (PDT)
Message-ID: <026c4245-5a8c-4e09-9026-44b8f3daca67@suse.com>
Date: Thu, 21 Mar 2024 14:26:18 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 15/20] xen/riscv: add minimal stuff to processor.h to
 build full Xen
Content-Language: en-US
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 xen-devel@lists.xenproject.org
References: 
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 15.03.2024 19:06, Oleksii Kurochko wrote:
> The cpu_relax() function, introduced in this commit, is anticipated to
> support _zihintpause by the CPU.
> 
> Signed-off-by: Oleksii Kurochko 

Acked-by: Jan Beulich 

Looks like this can go in ahead of the other 14 patches?

Jan


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 13:38:17 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 13:38:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696414.1087323 (Exim 4.92)
	(envelope-from )
	id 1rnIcL-0005SV-7x; Thu, 21 Mar 2024 13:38:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696414.1087323; Thu, 21 Mar 2024 13:38:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnIcL-0005SO-55; Thu, 21 Mar 2024 13:38:01 +0000
Received: by outflank-mailman (input) for mailman id 696414;
 Thu, 21 Mar 2024 13:38:00 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnIcK-0005S3-7K
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 13:38:00 +0000
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com
 [2a00:1450:4864:20::532])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3b6cce6e-e788-11ee-afe0-a90da7624cb6;
 Thu, 21 Mar 2024 14:37:59 +0100 (CET)
Received: by mail-ed1-x532.google.com with SMTP id
 4fb4d7f45d1cf-5658082d2c4so1247444a12.1
 for ; Thu, 21 Mar 2024 06:37:59 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 el9-20020a056402360900b0056a2cc5c868sm4411897edb.72.2024.03.21.06.37.58
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 21 Mar 2024 06:37:58 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3b6cce6e-e788-11ee-afe0-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711028279; x=1711633079; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=/nz1BoihA9E1gobI2ipoDOOvJQxw2BfteYL6iVUik+g=;
        b=ST/3/eTSM/b4gW45p5ug1U1FsW9vIb9GZsSVpe6aQgezvWHn1+Pv8vTSBFItmq6paH
         WWoPtvUa4VdBd5wl4IiWs7gPyfGDKCZY5Ni/CRsgEMeoYP51ic2/7Lv9SRhI3+838Fgx
         I3LLbOuwpHCdpbWD0/zOW24hZORNiX4saJwsggRQ66HOxf2Wh7kKW9YuzGiLHNboHahD
         3+EovdpbAtj1onZyGCp8wADS+KLLjH2vTIQU11Cq7+rrI6Mlrceuo9dC+XOU8yt9BfRy
         Hcc+Eet4WFO0RVr0+kUreR9/sLjJaOESiBg7glKQ+SPoWqpprvgSpBjDb1PVBw9VZUEb
         UIHA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711028279; x=1711633079;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=/nz1BoihA9E1gobI2ipoDOOvJQxw2BfteYL6iVUik+g=;
        b=d+L5dZVnZBdW9Zzl3KxYiu4WA4Z0tZr/s7JH4NAvXd1IzDZ906aVAjFC9rUfehzF4B
         X2xzYL+TIJ/eJ/UPAl6RyWHVwDU9lgO9RstGqHdZB/fN881k817plZosHmU23WpxPcUL
         FTWBPq+sG2sfavO++XGmCq+jOZoZJDPOlF/ohazb6wMCzwwpIO7Ry93tv3ZlTCnNk7aP
         5Zczccbt8jQIe+RLafPr4OTRT1hDnTOBW0WX5nRt6KZ6HT6qylmYtrE4mgkp3UxG6d+e
         BFBhWXtqUn+BkH0gmdeREyQz3NGFxD3mC+1YqWcM0XNNaSWmCdMfXcCbooSgWpLwp+3m
         B2Nw==
X-Forwarded-Encrypted: i=1; AJvYcCUzY5FR1cChRl90iOOh/Qi3hu3pCKo410KlF9d+Cdzm/czVj4SOTc+xv98vlls+4RFifYEVdjwwQXeqkhuOF213OZZzPWfPVXbViYyERJg=
X-Gm-Message-State: AOJu0YxQ0jgY1KJwuVN2nwNB1mNEeWbq3H7cU00+gAKF2BdwFuRXIDh5
	5dta2TbmNTOheXPgXAO3wig+4jHqUsJLprAiF2WFsq7L3Cy+FRYeufDSOk+A2KuVpC6QtAnm9G8
	=
X-Google-Smtp-Source: AGHT+IEOiBvv9fazJxmAV82RDPwI03jOzvlhlcdUrYhJ6b0zoykMaFiD3qNg46vVs3RAIVIdtgD24g==
X-Received: by 2002:a05:6402:43cb:b0:56b:8f6d:8a99 with SMTP id p11-20020a05640243cb00b0056b8f6d8a99mr5661130edc.22.1711028278970;
        Thu, 21 Mar 2024 06:37:58 -0700 (PDT)
Message-ID: 
Date: Thu, 21 Mar 2024 14:37:57 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 16/20] xen/riscv: add minimal stuff to mm.h to build
 full Xen
Content-Language: en-US
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 xen-devel@lists.xenproject.org
References: 
 <8d9c91cad5b548785780659599ea704f7fdba7a1.1710517542.git.oleksii.kurochko@gmail.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <8d9c91cad5b548785780659599ea704f7fdba7a1.1710517542.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 15.03.2024 19:06, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/include/asm/mm.h
> +++ b/xen/arch/riscv/include/asm/mm.h
> @@ -3,11 +3,246 @@
>  #ifndef _ASM_RISCV_MM_H
>  #define _ASM_RISCV_MM_H
>  
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
>  #include 
>  
>  #define pfn_to_paddr(pfn) ((paddr_t)(pfn) << PAGE_SHIFT)
>  #define paddr_to_pfn(pa)  ((unsigned long)((pa) >> PAGE_SHIFT))
>  
> +#define paddr_to_pdx(pa)    mfn_to_pdx(maddr_to_mfn(pa))
> +#define gfn_to_gaddr(gfn)   pfn_to_paddr(gfn_x(gfn))
> +#define gaddr_to_gfn(ga)    _gfn(paddr_to_pfn(ga))
> +#define mfn_to_maddr(mfn)   pfn_to_paddr(mfn_x(mfn))
> +#define maddr_to_mfn(ma)    _mfn(paddr_to_pfn(ma))
> +#define vmap_to_mfn(va)     maddr_to_mfn(virt_to_maddr((vaddr_t)(va)))
> +#define vmap_to_page(va)    mfn_to_page(vmap_to_mfn(va))
> +
> +static inline void *maddr_to_virt(unsigned long ma)

paddr_t as parameter type?

> +{
> +    BUG_ON("unimplemented");
> +    return NULL;
> +}
>[...]
> +#define PFN_ORDER(pfn) ((pfn)->v.free.order)

Would be nice if RISC-V wouldn't repeat the parameter mis-naming: Any of
p, pg, or page would be more suitable here.

With the adjustments:
Acked-by: Jan Beulich 

Jan


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 13:54:42 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 13:54:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696419.1087334 (Exim 4.92)
	(envelope-from )
	id 1rnIsN-0000Wt-N7; Thu, 21 Mar 2024 13:54:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696419.1087334; Thu, 21 Mar 2024 13:54:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnIsN-0000Wm-KI; Thu, 21 Mar 2024 13:54:35 +0000
Received: by outflank-mailman (input) for mailman id 696419;
 Thu, 21 Mar 2024 13:54:34 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rnIsM-0000Wg-2e
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 13:54:34 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on20600.outbound.protection.outlook.com
 [2a01:111:f403:2414::600])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8a0c2b1b-e78a-11ee-a1ee-f123f15fe8a2;
 Thu, 21 Mar 2024 14:54:31 +0100 (CET)
Received: from PH8PR21CA0004.namprd21.prod.outlook.com (2603:10b6:510:2ce::11)
 by PH0PR12MB7930.namprd12.prod.outlook.com (2603:10b6:510:283::7)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.27; Thu, 21 Mar
 2024 13:54:27 +0000
Received: from SA2PEPF000015C8.namprd03.prod.outlook.com
 (2603:10b6:510:2ce:cafe::4e) by PH8PR21CA0004.outlook.office365.com
 (2603:10b6:510:2ce::11) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.11 via Frontend
 Transport; Thu, 21 Mar 2024 13:54:27 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SA2PEPF000015C8.mail.protection.outlook.com (10.167.241.198) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Thu, 21 Mar 2024 13:54:26 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 21 Mar
 2024 08:54:26 -0500
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB05.amd.com
 (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 21 Mar
 2024 08:54:26 -0500
Received: from [172.24.153.109] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Thu, 21 Mar 2024 08:54:25 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8a0c2b1b-e78a-11ee-a1ee-f123f15fe8a2
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=DEcBvRYZDgMt7ybTxadkKvIwG4sixqb6wNsBVQovEgao4sX7ghmuLP+DAOj4DfoMawZx0UQ4H+f1kD7SIISyv9lM6u2aUj+JWERnib+sCGNGq6Tgkwg1zY8w2W5BljMAIFeAR+EK99kqjP0gVkpHB2a2RTr8xq3XaNIW5R6KP0kSL6xIIorzeJuC+0bSvOjYq9Hnddc59irUn9mwSZfYV7PJJJqRHP/6KffvcjBCy3VZQvR6Czh9djN8UYohsxmDvOWVc83f6kGX7YjORG2a+30P6H/idpce/gWkeMTQ621rd/5fQu1M8r5PBeGWhyTdY9QEwVmtLRYWh3X0UtB5Ug==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=fP8l0cdYuU1dl7qvwMTpxTd02D7J7iN/nE49vaIMgAI=;
 b=jVJeDRxuRxcU6WEMDm6LycF6p5lB8w0xspjVRc6jkeDay43SdhdxQfDx7sgw62DCI8rcMJ9s/bjOkJDJhc+2nIf7Qq71GT4KtV7U2g98Wm9T+5UEN7nOHwY5lIMp/QZbZ5nx1XV3G4+U0qzdqCgy8qM7sBOXoNxkMcefP1iWCmgHXbzzHC9/NopB5TdwUNqe9oo52YsZn47VJbCx4Hu7cCTSAZPxUuRzIbDZI/mJO5qt86vdrMz1zJpu9TdzDP6bPXZoDquzXaIdIdxphN0Yl4xnqFaFYu29sXm7ze6o8JA8yBmgwqo/I/RTTMl5KRi7Cha/VJMkjW5GToNJ9lUflA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=fP8l0cdYuU1dl7qvwMTpxTd02D7J7iN/nE49vaIMgAI=;
 b=POH0nmMkFoHGiE1DqcCviFUK2JN/M7LM4/kiDeGh7fO9fHrgMEawrncfHkXLFx0IZM1TIDrTDzd//PpfRqrzRn5ivPSaKvS/8LsYVNRPv7poDQg4pdB4JPCtJQxbfzcpuMz1wgMEodxOrZ0macdhyzR7yAhesEswo7QT026cjKo=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Message-ID: <183f17a2-cc7b-46c6-81b5-ac1f5daacb7b@amd.com>
Date: Thu, 21 Mar 2024 09:45:30 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 3/3] x86/PVH: Support relocatable dom0 kernels
To: Jan Beulich 
CC: Andrew Cooper ,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu
	, George Dunlap , Julien Grall
	, Stefano Stabellini ,
	
References: <20240319205849.115884-1-jason.andryuk@amd.com>
 <20240319205849.115884-4-jason.andryuk@amd.com>
 
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: 
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB05.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SA2PEPF000015C8:EE_|PH0PR12MB7930:EE_
X-MS-Office365-Filtering-Correlation-Id: 9f001ddc-222c-47c9-3ab4-08dc49ae6c61
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	8MSbTwtTyNpU2oW8pOoE/EnPJUtFs3A22bL6g9xRON8axM6PvbD0KaYRbxBxkflRq+etOuKHbIeiQ4EtlptVLvfeEolIkDormHIXfMyb09iyP/jUeCnma95IvdYJ7jpTUb6O9/6PI8eX4LX1kSPt1XN8Q0D32o5leu8s5lIVWmStlUi5HJbGXGn8YPsMD4zfb/tkHFrxU7mmKN/DbSbrjSobl/Hv481gX153iB1B2c5stg53ojxOxL4XPCZyPIlz0HJ3S9Emt7ceaHcr3o62yWHxu8BBAUcCaTSvvRkc4qHwqOiTdmlPlb2MGdtNZhDRDmDhF6zVnH5sWeqwnCQbQ0YikJMLUsDcuiFqdmXbwXyNWBEMXBITPd2I1fonLyc4Hp8QuESo6xdSuEcJA1vUTWlTFpA0KQx3ILoCrk3zBpX29pxFC5lAUJdmVcV8GKB/dhgEKf1K2frx1xjpUnkli9vOwMvBL87fDcu6Z8sEpeBd+ZFZH4wHGhcazH9TFeinoq11I8yYR7qP1wFnObFCNvok2UJvLCKAP40im/5OW0vkpXl2HM3Y1VLp/g6xl1Z/CrqiNsOr79W5h6utqntSS9/Hf12eo9RcOXp1+UDmAu+7H16GnPqS41F1Ulr6cw1uxrSmkFl2yZtSr6v6JMdSxAmgNE0f9RFeHvDsxnD1SQUL3o5gbXnA82lc91PfhofzwM3NCAevdyxAOboUKEwnwopksGZ/AmT+ngFRuNBXqXxmMySCTW0KsONQsfRUZEUE
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(82310400014)(36860700004)(1800799015)(376005);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Mar 2024 13:54:26.9810
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 9f001ddc-222c-47c9-3ab4-08dc49ae6c61
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SA2PEPF000015C8.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR12MB7930

On 2024-03-20 10:39, Jan Beulich wrote:
> On 19.03.2024 21:58, Jason Andryuk wrote:
>> --- a/xen/arch/x86/hvm/dom0_build.c
>> +++ b/xen/arch/x86/hvm/dom0_build.c
>> @@ -537,6 +537,97 @@ static paddr_t __init find_memory(
>>       return INVALID_PADDR;
>>   }
>>   
>> +static bool __init check_load_address(
>> +    const struct domain *d, const struct elf_binary *elf)
>> +{
>> +    paddr_t kernel_start = (paddr_t)elf->dest_base;
> 
> As before I think it is illegitimate to cast a pointer to paddr_t. The
> variable type wants to remain such, but the cast wants to be to
> unsigned long or uintptr_t (or else at least a comment wants adding).

Ok, thanks.  This explains it clearly.

>> +/* Find an e820 RAM region that fits the kernel at a suitable alignment. */
>> +static paddr_t __init find_kernel_memory(
>> +    const struct domain *d, struct elf_binary *elf,
>> +    const struct elf_dom_parms *parms)
>> +{
>> +    paddr_t kernel_size = elf->dest_size;
>> +    unsigned int i;
>> +
>> +    for ( i = 0; i < d->arch.nr_e820; i++ )
>> +    {
>> +        paddr_t start = d->arch.e820[i].addr;
>> +        paddr_t end = d->arch.e820[i].addr + d->arch.e820[i].size;
>> +        paddr_t kstart, kend;
>> +
>> +        if ( d->arch.e820[i].type != E820_RAM ||
>> +             d->arch.e820[i].size < kernel_size )
>> +            continue;
>> +
>> +        kstart = ROUNDUP(start, parms->phys_align);
>> +        kstart = max_t(paddr_t, kstart, parms->phys_min);
> 
> I'd generally try to avoid max_t(), but I cannot think of any good way
> of expressing this without using it.
> 
>> +        kend = kstart + kernel_size;
>> +
>> +        if ( kend > parms->phys_max )
> 
> So despite its default phys_max is exclusive aiui. Otherwise with
> kend being exclusive too, this would look to be off by one.

Yes, I'll fix the off-by-one.  Hmmm, phys_max being 32bit, we want it to 
be inclusive to represent the maximum range.

>> +            return 0;
>> +
>> +        if ( kend <= end )
>> +            return kstart;
>> +    }
>> +
>> +    return 0;
>> +}
>> +
>> +/* Check the kernel load address, and adjust if necessary and possible. */
>> +static bool __init check_and_adjust_load_address(
>> +    const struct domain *d, struct elf_binary *elf, struct elf_dom_parms *parms)
>> +{
>> +    paddr_t reloc_base;
>> +
>> +    if ( check_load_address(d, elf) )
>> +        return true;
>> +
>> +    if ( !parms->phys_reloc )
>> +    {
>> +        printk("%pd kernel: Address conflict and not relocatable\n", d);
>> +        return false;
> 
> This better wouldn't result in -ENOMEM in the caller. Then again reasons
> are logged, so the specific error code perhaos doesn't matter that much.

Failure here is turned into -ENOMEM by pvh_load_kernel().   -ENOMEM is 
already returned for later failure with find_memory(), so I thought it 
was acceptable.  Without this code, elf_load_binary() would failed with 
-1 and that would be returned.  I'll change it to whatever you prefer.

>> +    }
>> +
>> +    reloc_base = find_kernel_memory(d, elf, parms);
>> +    if ( reloc_base == 0 )
> 
> With ! used above please be consistent and do so here, too.

phys_reloc is a bool, and reloc_base is a paddr_t.

>> +    {
>> +        printk("%pd kernel: Failed find a load address\n", d);
>> +        return false;
>> +    }
>> +
>> +    if ( opt_dom0_verbose )
>> +        printk("%pd kernel: Moving [%p, %p] -> [%"PRIpaddr", %"PRIpaddr"]\n", d,
>> +               elf->dest_base, elf->dest_base + elf->dest_size - 1,
>> +               reloc_base, reloc_base + elf->dest_size - 1);
>> +
>> +    parms->phys_entry = reloc_base +
>> +                            (parms->phys_entry - (paddr_t)elf->dest_base);
>> +    elf->dest_base = (char *)reloc_base;
> 
> Just as a remark, no request to change anything: We're not dealing with
> strings here. Hence char * isn't quite right, just that "dest_base" is
> of that type (for whatever reason).

I think the reason is just to be byte addressable.

>> @@ -225,6 +232,28 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
>>       case XEN_ELFNOTE_PHYS32_ENTRY:
>>           parms->phys_entry = val;
>>           break;
>> +
>> +    case XEN_ELFNOTE_PHYS32_RELOC:
>> +        parms->phys_reloc = true;
>> +
>> +        if ( descsz >= 4 )
>> +        {
>> +            parms->phys_max = elf_note_numeric_array(elf, note, 4, 0);
>> +            elf_msg(elf, " = max: %#"PRIx32, parms->phys_max);
>> +        }
>> +        if ( descsz >= 8 )
>> +        {
>> +            parms->phys_min = elf_note_numeric_array(elf, note, 4, 1);
>> +            elf_msg(elf, " min: %#"PRIx32, parms->phys_min);
>> +        }
>> +        if ( descsz >= 12 )
>> +        {
>> +            parms->phys_align = elf_note_numeric_array(elf, note, 4, 2);
>> +            elf_msg(elf, " align: %#"PRIx32, parms->phys_align);
>> +        }
>> +
>> +        elf_msg(elf, "\n");
> 
> Imo the newline wants adding outside of the switch(), for everything
> set to ELFNOTE_CUSTOM. In fact with that I think ELFNOTE_CUSTOM and
> ELFNOTE_NAME could be folded (with what's NAME right now simply
> printing nothing in the switch here). Which suggests that I may
> better not commit the (slightly adjusted) earlier patch, yet.

Yes, please hold off and I'll re-work both.

>> @@ -536,6 +565,10 @@ elf_errorstatus elf_xen_parse(struct elf_binary *elf,
>>       parms->p2m_base = UNSET_ADDR;
>>       parms->elf_paddr_offset = UNSET_ADDR;
>>       parms->phys_entry = UNSET_ADDR32;
>> +    parms->phys_min = 0;
>> +    parms->phys_max = 0xffffffff;
>> +    parms->phys_align = 0x200000;
> 
> I think this wants to be MB(2) (requiring a pre-patch to centralize MB()
> in the tool stack to tools/include/xen-tools/common-macros.h). And I
> further think this needs to be an arch-specific constant, even if right
> now the note is expected to be present only for x86. Which then also
> needs saying ...

Ok, I'll look into this.

>> --- a/xen/include/public/elfnote.h
>> +++ b/xen/include/public/elfnote.h
>> @@ -194,10 +194,26 @@
>>    */
>>   #define XEN_ELFNOTE_PHYS32_ENTRY 18
>>   
>> +/*
>> + * Physical loading constraints for PVH kernels
>> + *
>> + * Used to place constraints on the guest physical loading addresses and
>> + * alignment for a PVH kernel.
>> + *
>> + * The presence of this note indicates the kernel supports relocating itself.
>> + *
>> + * The note may include up to three 32bit values in the following order:
>> + *  - a maximum address for the entire image to be loaded below (default
>> + *      0xffffffff)
>> + *  - a minimum address for the start of the image (default 0)
>> + *  - a required start alignment (default 0x200000)
>> + */
>> +#define XEN_ELFNOTE_PHYS32_RELOC 19
> 
> ... in the comment here. The reasoning behind not (intermediately) falling
> back to the alignment in the ELF headers also wants adding to the patch
> description (or a code comment, albeit there's no really good place to put
> it, imo).
> 
> Additionally I think the pieces of the comment want re-ordering. The primary
> purpose is indicating relocatability; when not relocating, the constraints
> aren't applied in any way.

Yes, this is a good point.

Thanks for the review.

-Jason


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 14:02:57 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 14:02:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696423.1087344 (Exim 4.92)
	(envelope-from )
	id 1rnJ0P-0002ZO-FX; Thu, 21 Mar 2024 14:02:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696423.1087344; Thu, 21 Mar 2024 14:02:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnJ0P-0002ZH-CZ; Thu, 21 Mar 2024 14:02:53 +0000
Received: by outflank-mailman (input) for mailman id 696423;
 Thu, 21 Mar 2024 14:02:51 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnJ0N-0002Z8-Jr
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 14:02:51 +0000
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com
 [2a00:1450:4864:20::533])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b3fa83d2-e78b-11ee-afe0-a90da7624cb6;
 Thu, 21 Mar 2024 15:02:50 +0100 (CET)
Received: by mail-ed1-x533.google.com with SMTP id
 4fb4d7f45d1cf-568a53d2ce0so1376754a12.0
 for ; Thu, 21 Mar 2024 07:02:50 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 q28-20020a056402249c00b0056baacff45csm2042320eda.69.2024.03.21.07.02.49
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 21 Mar 2024 07:02:49 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b3fa83d2-e78b-11ee-afe0-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711029770; x=1711634570; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=9qcs5T/9UKcSTJBFSOupU6oSe7Jnfu4QXEixl/YHj7I=;
        b=SqmP3RkNZXIAJBNQOeCeX+9BWGicdePIgDoo3qVA8+Dqp3S3v03YVmam/1mY5QRChJ
         JDK/OSzMpzeYAthv1MTCaTONwXydSOSMY3dIpicTUs8qic9YMFwaBknSjzQbT9Mi7JQu
         XeyER4lMJN+c+CUo0XkzbLHfYnsmK4fb3mrq1wL0KFzWIIGCcbsXU2hTIoYv3QCuKxdn
         kdbtLZ9oxIokvHf2VNmNzijIPVRHGlDpo9AKUBV+ihIw+I6Y6ra1NjV4Lctg9Dt7lgIH
         HuMuFOoaut4QtZ2J/uZgMsggNE76aBkyAG/IWgGuFdcqCokvLsp4nlPPh7KYH57z16Q3
         wMWw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711029770; x=1711634570;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=9qcs5T/9UKcSTJBFSOupU6oSe7Jnfu4QXEixl/YHj7I=;
        b=g4axyFbQ03J69wanUyv+epWuTE2INNQToK5URfsyIFROyoSDAwgy33fW5syK2M5mRt
         zOARlf2yVMadnCnQvh4+ObYt8cNp0VEXRQ20+MdDp2YmioTldbNOLopSFzhsiI5jfgb7
         Og/jxyAZp8aXZUoAbfVI/z3Q9bEdLH10pvPMhwH+S+CpqsAsPLslrXrTwfZ5Nd7KPGaD
         HpPpP3U2v8E7tQYaheXtFqQOYcMN/7HAcrrDr4Rmm2P7qx6E7wIdmZatK8HW0SwLBf12
         pYRo0EDvWrnTfdH1Lyx1C582hbg2N7gimPadmkBPdJeXVCDASx79sx9aB6MLbGwl8jgw
         NM7Q==
X-Forwarded-Encrypted: i=1; AJvYcCUnv3mRxRwD86FzSq5gkYLJNI/ZqyuDV/OJvdXOMqg1sARmAv+L3VkE91oQNXirM3xCIuBUjuVrvW1vVFdHQXGalm527qPK6Byhi1p7zUs=
X-Gm-Message-State: AOJu0YwPDzZZDxnPo65KGOvC6dWg3XYQyh6nJqZjW0BxbF3WixAVj1Kd
	2dwlJUHEnJzfqcZ4wNSO5YbyFdEr7z5Cq6KlDDyWJ1k4u4eSnNT4vfO5W0oHUQ==
X-Google-Smtp-Source: AGHT+IGebYP2ro9M5wdS0aBYF+zCCi+ghkOH/c/mz5l31m6VZxaTAbK6WV8BWazh9uJ248uUHTnNzg==
X-Received: by 2002:a50:d653:0:b0:568:13f5:81eb with SMTP id c19-20020a50d653000000b0056813f581ebmr1558745edj.38.1711029769677;
        Thu, 21 Mar 2024 07:02:49 -0700 (PDT)
Message-ID: <78b52558-b684-4197-899e-9359e44b1a50@suse.com>
Date: Thu, 21 Mar 2024 15:02:48 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 3/3] x86/PVH: Support relocatable dom0 kernels
Content-Language: en-US
To: Jason Andryuk 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu
 , George Dunlap ,
 Julien Grall , Stefano Stabellini ,
 xen-devel@lists.xenproject.org
References: <20240319205849.115884-1-jason.andryuk@amd.com>
 <20240319205849.115884-4-jason.andryuk@amd.com>
 
 <183f17a2-cc7b-46c6-81b5-ac1f5daacb7b@amd.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <183f17a2-cc7b-46c6-81b5-ac1f5daacb7b@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 21.03.2024 14:45, Jason Andryuk wrote:
> On 2024-03-20 10:39, Jan Beulich wrote:
>> On 19.03.2024 21:58, Jason Andryuk wrote:
>>> +/* Find an e820 RAM region that fits the kernel at a suitable alignment. */
>>> +static paddr_t __init find_kernel_memory(
>>> +    const struct domain *d, struct elf_binary *elf,
>>> +    const struct elf_dom_parms *parms)
>>> +{
>>> +    paddr_t kernel_size = elf->dest_size;
>>> +    unsigned int i;
>>> +
>>> +    for ( i = 0; i < d->arch.nr_e820; i++ )
>>> +    {
>>> +        paddr_t start = d->arch.e820[i].addr;
>>> +        paddr_t end = d->arch.e820[i].addr + d->arch.e820[i].size;
>>> +        paddr_t kstart, kend;
>>> +
>>> +        if ( d->arch.e820[i].type != E820_RAM ||
>>> +             d->arch.e820[i].size < kernel_size )
>>> +            continue;
>>> +
>>> +        kstart = ROUNDUP(start, parms->phys_align);
>>> +        kstart = max_t(paddr_t, kstart, parms->phys_min);
>>
>> I'd generally try to avoid max_t(), but I cannot think of any good way
>> of expressing this without using it.
>>
>>> +        kend = kstart + kernel_size;
>>> +
>>> +        if ( kend > parms->phys_max )
>>
>> So despite its default phys_max is exclusive aiui. Otherwise with
>> kend being exclusive too, this would look to be off by one.
> 
> Yes, I'll fix the off-by-one.  Hmmm, phys_max being 32bit, we want it to 
> be inclusive to represent the maximum range.

I specifically didn't ask for that, as I think it would end up a little
awkward. But I also don't mind you adjusting things to that effect.

>>> +            return 0;
>>> +
>>> +        if ( kend <= end )
>>> +            return kstart;
>>> +    }
>>> +
>>> +    return 0;
>>> +}
>>> +
>>> +/* Check the kernel load address, and adjust if necessary and possible. */
>>> +static bool __init check_and_adjust_load_address(
>>> +    const struct domain *d, struct elf_binary *elf, struct elf_dom_parms *parms)
>>> +{
>>> +    paddr_t reloc_base;
>>> +
>>> +    if ( check_load_address(d, elf) )
>>> +        return true;
>>> +
>>> +    if ( !parms->phys_reloc )
>>> +    {
>>> +        printk("%pd kernel: Address conflict and not relocatable\n", d);
>>> +        return false;
>>
>> This better wouldn't result in -ENOMEM in the caller. Then again reasons
>> are logged, so the specific error code perhaos doesn't matter that much.
> 
> Failure here is turned into -ENOMEM by pvh_load_kernel().   -ENOMEM is 
> already returned for later failure with find_memory(), so I thought it 
> was acceptable.  Without this code, elf_load_binary() would failed with 
> -1 and that would be returned.  I'll change it to whatever you prefer.

ENOSPC would likely make it easily distinguishable from anything else.

>>> +    }
>>> +
>>> +    reloc_base = find_kernel_memory(d, elf, parms);
>>> +    if ( reloc_base == 0 )
>>
>> With ! used above please be consistent and do so here, too.
> 
> phys_reloc is a bool, and reloc_base is a paddr_t.

Hmm, I see. But still - we generally prefer ! over "== 0" (or even "== NULL").

>>> +    {
>>> +        printk("%pd kernel: Failed find a load address\n", d);
>>> +        return false;
>>> +    }
>>> +
>>> +    if ( opt_dom0_verbose )
>>> +        printk("%pd kernel: Moving [%p, %p] -> [%"PRIpaddr", %"PRIpaddr"]\n", d,
>>> +               elf->dest_base, elf->dest_base + elf->dest_size - 1,
>>> +               reloc_base, reloc_base + elf->dest_size - 1);
>>> +
>>> +    parms->phys_entry = reloc_base +
>>> +                            (parms->phys_entry - (paddr_t)elf->dest_base);
>>> +    elf->dest_base = (char *)reloc_base;
>>
>> Just as a remark, no request to change anything: We're not dealing with
>> strings here. Hence char * isn't quite right, just that "dest_base" is
>> of that type (for whatever reason).
> 
> I think the reason is just to be byte addressable.

Sure, but that would call for void *, unsigned char *, or uint8_t *.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 15:04:02 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 15:04:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696433.1087360 (Exim 4.92)
	(envelope-from )
	id 1rnJxK-00032B-W5; Thu, 21 Mar 2024 15:03:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696433.1087360; Thu, 21 Mar 2024 15:03:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnJxK-000324-Sl; Thu, 21 Mar 2024 15:03:46 +0000
Received: by outflank-mailman (input) for mailman id 696433;
 Thu, 21 Mar 2024 15:03:46 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rnJxJ-00031w-SP
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 15:03:46 +0000
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com
 [2a00:1450:4864:20::531])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 35e0cc06-e794-11ee-afe0-a90da7624cb6;
 Thu, 21 Mar 2024 16:03:44 +0100 (CET)
Received: by mail-ed1-x531.google.com with SMTP id
 4fb4d7f45d1cf-56bcbad7ee2so874133a12.1
 for ; Thu, 21 Mar 2024 08:03:44 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 35e0cc06-e794-11ee-afe0-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1711033423; x=1711638223; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=qJ471QdbdomVThs/AZhYCLeWm0QKMxVE9383lGDlnkg=;
        b=Aa/rB64AprcJOE8ctmc+BLOVqoie2uSQQ/ZoqeAxZ9TcN2PprppyKNM6Cgo9By2B0L
         RfhWAyGVttaJX3fummiiIlrOGYOzJYBRMI9V9L5aLm0tX/qW58rx/4ZAI+u9M++ruhq+
         ysRxtm605TAcN7O+ZMUba+oDG1OMkIQWb1F/i3H9rJ39U3aNeqdfjGLJDISOuJEPceKk
         WiqgDAeO4KdQcTu/4a4pwW8IpKMV/JyM2T8hN7+m3J3bHc930zrPct9EqjS3EZGN8N9B
         p+PsDGi85CH99QmMbDXFQ7ekaGDPymBvW8UZOS2kBiAX+7Ct2/TDXewpqEAAkVCT0Ps8
         DWmA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711033423; x=1711638223;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=qJ471QdbdomVThs/AZhYCLeWm0QKMxVE9383lGDlnkg=;
        b=euZSj+nRPwhMzUTZ6eNFaP5ZDHU5zNrJ60nq7jWzcMlzDhnxtXa43Jj/nKfdltjPDP
         kQ9qEo0p9pOBNmKCo6Z9UEo2+flIgi8/dtDnXQ9Z1zxhXIE6VBZ9qCitBwMjDEQD8EUE
         j5r6jNsjIervEJW4SsccTcrjnjWRJm5He/PiK3Yr7aBi5MvII42XUXHQoYTbj0IAs5EN
         QvOehX2esRUcWHDRUafiBpWc1BVZUePa0jk6Nluy3uJS8Cn74UmtAgMEYR4KcylGN7Y3
         27EBUOGdqd1YChSxg0WwQtFJHJm8fmvpI0lRlM1aLPReqKG/S13LFwcN2qT91BY/zkRL
         Iv5Q==
X-Forwarded-Encrypted: i=1; AJvYcCWV13TGm9lBg7/yzaH6RE3jffkY/KawkYkgOL1dHM2/6Uq6nkpPDIOyeWMnY/kL8nfBdXrave4NzmGJLYsENlT5s8NcYyS98+63QLeY4I8=
X-Gm-Message-State: AOJu0Ywt4GJ1UyjF+Q54NG0OCG6/yKDN3CmPXQwj8kR+cAbvZx04iaI7
	uk0UHAvCDkXFQYLQ6uhVS0JjjSDv9SaSbKRUgFQdo67UDHpowcov7vDUhOYV16PUeT+nbL3KrJZ
	p0jZZwbvzpGsDfBBPs3O/pEDMQw3Cd27WW5AotQ==
X-Google-Smtp-Source: AGHT+IHuB98ig8yynu78T42PA1YSLU9bRswrfCBD74X2gUwfygEoKKEMQgNdUgFKYjpHDHcBVDwSpZ1UYRI9ANv6qQw=
X-Received: by 2002:a17:907:7248:b0:a46:e4dc:25ab with SMTP id
 ds8-20020a170907724800b00a46e4dc25abmr6507202ejc.47.1711033423375; Thu, 21
 Mar 2024 08:03:43 -0700 (PDT)
MIME-Version: 1.0
References: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
 <20240315105902.160047-2-carlo.nonato@minervasys.tech> <05e4d3da-4130-4c57-9855-43b685ce5005@suse.com>
In-Reply-To: <05e4d3da-4130-4c57-9855-43b685ce5005@suse.com>
From: Carlo Nonato 
Date: Thu, 21 Mar 2024 16:03:32 +0100
Message-ID: 
Subject: Re: [PATCH v7 01/14] xen/common: add cache coloring common code
To: Jan Beulich 
Cc: Andrea Bastoni , 
	Andrew Cooper , George Dunlap , 
	Julien Grall , Stefano Stabellini , Wei Liu , 
	Marco Solieri , xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Jan,

(adding Andrea Bastoni in cc)

On Tue, Mar 19, 2024 at 3:58=E2=80=AFPM Jan Beulich  wro=
te:
>
> On 15.03.2024 11:58, Carlo Nonato wrote:
> > +Background
> > +**********
> > +
> > +Cache hierarchy of a modern multi-core CPU typically has first levels =
dedicated
> > +to each core (hence using multiple cache units), while the last level =
is shared
> > +among all of them. Such configuration implies that memory operations o=
n one
> > +core (e.g. running a DomU) are able to generate interference on anothe=
r core
> > +(e.g. hosting another DomU). Cache coloring realizes per-set cache-par=
titioning
> > +in software and mitigates this, guaranteeing higher and more predictab=
le
> > +performances for memory accesses.
>
> Are you sure about "higher"? On an otherwise idle system, a single domain=
 (or
> vCPU) may perform better when not partitioned, as more cache would be ava=
ilable
> to it overall.

I'll drop "higher" and leave the rest.

> > +How to compute the number of colors
> > +###################################
> > +
> > +Given the linear mapping from physical memory to cache lines for grant=
ed, the
> > +number of available colors for a specific platform is computed using t=
hree
> > +parameters:
> > +
> > +- the size of the LLC.
> > +- the number of the LLC ways.
> > +- the page size used by Xen.
> > +
> > +The first two parameters can be found in the processor manual, while t=
he third
> > +one is the minimum mapping granularity. Dividing the cache size by the=
 number of
> > +its ways we obtain the size of a way. Dividing this number by the page=
 size,
> > +the number of total cache colors is found. So for example an Arm Corte=
x-A53
> > +with a 16-ways associative 1 MiB LLC can isolate up to 16 colors when =
pages are
> > +4 KiB in size.
> > +
> > +LLC size and number of ways are probed automatically by default so the=
re's
> > +should be no need to compute the number of colors by yourself.
>
> Is this a leftover from the earlier (single) command line option?

Nope, but I can drop it since it's already stated below.

> > +Effective colors assignment
> > +###########################
> > +
> > +When assigning colors:
> > +
> > +1. If one wants to avoid cache interference between two domains, diffe=
rent
> > +   colors needs to be used for their memory.
> > +
> > +2. To improve spatial locality, color assignment should privilege cont=
inuity in
>
> s/privilege/prefer/ ?
>
> > +   the partitioning. E.g., assigning colors (0,1) to domain I and (2,3=
) to
> > +   domain J is better than assigning colors (0,2) to I and (1,3) to J.
>
> While I consider 1 obvious without further explanation, the same isn't
> the case for 2: What's the benefit of spatial locality? If there was
> support for allocating higher order pages, I could certainly see the
> point, but iirc that isn't supported (yet).

I'll drop point 2.

> > +Command line parameters
> > +***********************
> > +
> > +Specific documentation is available at `docs/misc/xen-command-line.pan=
doc`.
> > +
> > ++----------------------+-------------------------------+
> > +| **Parameter**        | **Description**               |
> > ++----------------------+-------------------------------+
> > +| ``llc-coloring``     | enable coloring at runtime    |
> > ++----------------------+-------------------------------+
> > +| ``llc-size``         | set the LLC size              |
> > ++----------------------+-------------------------------+
> > +| ``llc-nr-ways``      | set the LLC number of ways    |
> > ++----------------------+-------------------------------+
> > +
> > +Auto-probing of LLC specs
> > +#########################
> > +
> > +LLC size and number of ways are probed automatically by default.
> > +
> > +LLC specs can be manually set via the above command line parameters. T=
his
> > +bypasses any auto-probing and it's used to overcome failing situations=
 or for
> > +debugging/testing purposes.
>
> As well as perhaps for cases where the auto-probing logic is flawed?

This is what I meant with "overcome failing situations", but I'll be more
explicit.

> > --- a/docs/misc/xen-command-line.pandoc
> > +++ b/docs/misc/xen-command-line.pandoc
> > @@ -1706,6 +1706,43 @@ This option is intended for debugging purposes o=
nly.  Enable MSR_DEBUGCTL.LBR
> >  in hypervisor context to be able to dump the Last Interrupt/Exception =
To/From
> >  record with other registers.
> >
> > +### llc-coloring
> > +> `=3D `
> > +
> > +> Default: `false`
> > +
> > +Flag to enable or disable LLC coloring support at runtime. This option=
 is
> > +available only when `CONFIG_LLC_COLORING` is enabled. See the general
> > +cache coloring documentation for more info.
> > +
> > +### llc-nr-ways
> > +> `=3D `
> > +
> > +> Default: `Obtained from hardware`
> > +
> > +Specify the number of ways of the Last Level Cache. This option is ava=
ilable
> > +only when `CONFIG_LLC_COLORING` is enabled. LLC size and number of way=
s are used
> > +to find the number of supported cache colors. By default the value is
> > +automatically computed by probing the hardware, but in case of specifi=
c needs,
> > +it can be manually set. Those include failing probing and debugging/te=
sting
> > +purposes so that it's possibile to emulate platforms with different nu=
mber of
> > +supported colors. If set, also "llc-size" must be set, otherwise the d=
efault
> > +will be used.
> > +
> > +### llc-size
> > +> `=3D `
> > +
> > +> Default: `Obtained from hardware`
> > +
> > +Specify the size of the Last Level Cache. This option is available onl=
y when
> > +`CONFIG_LLC_COLORING` is enabled. LLC size and number of ways are used=
 to find
> > +the number of supported cache colors. By default the value is automati=
cally
> > +computed by probing the hardware, but in case of specific needs, it ca=
n be
> > +manually set. Those include failing probing and debugging/testing purp=
oses so
> > +that it's possibile to emulate platforms with different number of supp=
orted
> > +colors. If set, also "llc-nr-ways" must be set, otherwise the default =
will be
> > +used.
>
> Wouldn't it make sense to infer "llc-coloring" when both of the latter op=
tions
> were supplied?

To me it looks a bit strange that specifying some attributes of the cache
automatically enables cache coloring. Also it would require some changes in
how to express the auto-probing for such attributes.

> > --- a/xen/arch/Kconfig
> > +++ b/xen/arch/Kconfig
> > @@ -31,3 +31,23 @@ config NR_NUMA_NODES
> >         associated with multiple-nodes management. It is the upper boun=
d of
> >         the number of NUMA nodes that the scheduler, memory allocation =
and
> >         other NUMA-aware components can handle.
> > +
> > +config LLC_COLORING
> > +     bool "Last Level Cache (LLC) coloring" if EXPERT
> > +     depends on HAS_LLC_COLORING
> > +     depends on !NUMA
> > +
> > +config NR_LLC_COLORS
> > +     int "Maximum number of LLC colors"
> > +     range 2 1024
> > +     default 128
> > +     depends on LLC_COLORING
> > +     help
> > +       Controls the build-time size of various arrays associated with =
LLC
> > +       coloring. Refer to cache coloring documentation for how to comp=
ute the
> > +       number of colors supported by the platform. This is only an upp=
er
> > +       bound. The runtime value is autocomputed or manually set via cm=
dline.
> > +       The default value corresponds to an 8 MiB 16-ways LLC, which sh=
ould be
> > +       more than what's needed in the general case. Use only power of =
2 values.
>
> I think I said so before: Rather than telling people to pick only power-o=
f-2
> values (and it remaining unclear what happens if they don't), why don't y=
ou
> simply keep them from specifying anything bogus, by having them pass in t=
he
> value to use as a power of 2? I.e. "range 1 10" and "default 7" for what
> you're currently putting in place.

I'll do that.

> > +       1024 is the number of colors that fit in a 4 KiB page when inte=
gers are 4
> > +       bytes long.
>
> How's this relevant here? As a justification it would make sense to have =
in
> the description.

I'll move it.

> I'm btw also not convinced this is a good place to put these options. Imo=
 ...
>
> > --- a/xen/common/Kconfig
> > +++ b/xen/common/Kconfig
> > @@ -71,6 +71,9 @@ config HAS_IOPORTS
> >  config HAS_KEXEC
> >       bool
> >
> > +config HAS_LLC_COLORING
> > +     bool
> > +
> >  config HAS_PMAP
> >       bool
>
> ... they'd better live further down from here.

Ok.

> > --- /dev/null
> > +++ b/xen/common/llc-coloring.c
> > @@ -0,0 +1,102 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only */
> > +/*
> > + * Last Level Cache (LLC) coloring common code
> > + *
> > + * Copyright (C) 2022 Xilinx Inc.
> > + */
> > +#include 
> > +#include 
> > +#include 
> > +
> > +static bool __ro_after_init llc_coloring_enabled;
> > +boolean_param("llc-coloring", llc_coloring_enabled);
> > +
> > +static unsigned int __initdata llc_size;
> > +size_param("llc-size", llc_size);
> > +static unsigned int __initdata llc_nr_ways;
> > +integer_param("llc-nr-ways", llc_nr_ways);
> > +/* Number of colors available in the LLC */
> > +static unsigned int __ro_after_init max_nr_colors;
> > +
> > +static void print_colors(const unsigned int *colors, unsigned int num_=
colors)
> > +{
> > +    unsigned int i;
> > +
> > +    printk("{ ");
> > +    for ( i =3D 0; i < num_colors; i++ )
> > +    {
> > +        unsigned int start =3D colors[i], end =3D start;
> > +
> > +        printk("%u", start);
> > +
> > +        for ( ; i < num_colors - 1 && end + 1 =3D=3D colors[i + 1]; i+=
+, end++ )
> > +            ;
> > +
> > +        if ( start !=3D end )
> > +            printk("-%u", end);
> > +
> > +        if ( i < num_colors - 1 )
> > +            printk(", ");
> > +    }
> > +    printk(" }\n");
> > +}
> > +
> > +void __init llc_coloring_init(void)
> > +{
> > +    unsigned int way_size;
> > +
> > +    if ( !llc_coloring_enabled )
> > +        return;
> > +
> > +    if ( llc_size && llc_nr_ways )
> > +        way_size =3D llc_size / llc_nr_ways;
> > +    else
> > +    {
> > +        way_size =3D get_llc_way_size();
> > +        if ( !way_size )
> > +            panic("LLC probing failed and 'llc-size' or 'llc-nr-ways' =
missing\n");
> > +    }
> > +
> > +    /*
> > +     * The maximum number of colors must be a power of 2 in order to c=
orrectly
> > +     * map them to bits of an address.
> > +     */
> > +    max_nr_colors =3D way_size >> PAGE_SHIFT;
> > +
> > +    if ( max_nr_colors & (max_nr_colors - 1) )
> > +        panic("Number of LLC colors (%u) isn't a power of 2\n", max_nr=
_colors);
> > +
> > +    if ( max_nr_colors < 2 || max_nr_colors > CONFIG_NR_LLC_COLORS )
> > +        panic("Number of LLC colors (%u) not in range [2, %u]\n",
> > +              max_nr_colors, CONFIG_NR_LLC_COLORS);
>
> Rather than crashing when max_nr_colors is too large, couldn't you simply
> halve it a number of times? That would still satisfy the requirement on
> isolation, wouldn't it?

Well I could simply set it to CONFIG_NR_LLC_COLORS at this point.

> > +    arch_llc_coloring_init();
> > +}
> > +
> > +void cf_check dump_llc_coloring_info(void)
>
> I don't think cf_check is needed here nor ...
>
> > +void cf_check domain_dump_llc_colors(const struct domain *d)
>
> ... here anymore. You're using direct calls now.

Ok.

> Jan

Thanks.


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 15:04:57 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 15:04:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696435.1087370 (Exim 4.92)
	(envelope-from )
	id 1rnJyT-0003XI-Ba; Thu, 21 Mar 2024 15:04:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696435.1087370; Thu, 21 Mar 2024 15:04:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnJyT-0003XB-8v; Thu, 21 Mar 2024 15:04:57 +0000
Received: by outflank-mailman (input) for mailman id 696435;
 Thu, 21 Mar 2024 15:04:56 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rnJyS-0003Wk-5v
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 15:04:56 +0000
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com
 [2a00:1450:4864:20::52e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5fb27f42-e794-11ee-a1ee-f123f15fe8a2;
 Thu, 21 Mar 2024 16:04:54 +0100 (CET)
Received: by mail-ed1-x52e.google.com with SMTP id
 4fb4d7f45d1cf-56b93b45779so1371630a12.1
 for ; Thu, 21 Mar 2024 08:04:54 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5fb27f42-e794-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1711033494; x=1711638294; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=+X4qvwVwINCAFDnjL2nwnt17LPJFaX2g4YgC73YiOZ4=;
        b=UVy2I9o4d2PNu4NwQNjdf9qSuw2tNXGXRVlqnK0cCk9tI+FtKn9CCOVeDm8Xxh9xUd
         klOjK0UU4a2EkTn+K56wRDg3dlOfvh/wA+oFVnMfdfY9hP5lHCVBvtUW+X52lvp8GmUq
         VvT3l7DIkRJYy3ViIKas/o4nZNr/hhMLiAdLj2DBwN4JoVZO7PcduC2FTiu/xqx0N45m
         CLjhPhfXOS7TdsEzT4nCMTVXMYLuffiuBqAfKJrSgJ87pc70+zeENqG3HLrNCDYf4NQT
         8aKtAxtxc7P0DHkMfq6Xe4Owpb+KcuzQ5bJCfhT/8ywm0Xg5Cf8WgJ3D8RbPP/DSWQQB
         vpnA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711033494; x=1711638294;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=+X4qvwVwINCAFDnjL2nwnt17LPJFaX2g4YgC73YiOZ4=;
        b=fSAZQOYIfbSMGDgBuDwq0EHFC1ya/XS+5dW2hYPt5ZEhojjbswVxdzMwGC47zSBCQo
         EwnQteUk4FLc3RAVWWByTefr+KFHw5YpxIcA4RN2c4Exo7Ksr0c38zkMyTYQKzVQhX3H
         yhJiM/IpRZCQPLPd9wkgDIrG0pIQJxU9bXtTrzJZ219T5Aee5C9dfhaPIkYZHYyKtn8V
         eg3y/DRR4Qcj33c6+q01uafieySxdgC/r1Ndl+XwYkuNwYmNuWb53JKgAP2gN+fCFM8Y
         tQ9jsXsv373b4V1rDlf9aGef9t12AeuCbeowkapgQVIkSNRZu+2wGKc17rZoaQMM/5mM
         OAfg==
X-Forwarded-Encrypted: i=1; AJvYcCVTqs6z9sVZFHpZIS2kd+gRc1/3XFkwgUKSkcWRDMgREYqgeCGCyLW0EbnabLtlq9w8ZcGl4WVqdf90psLF9M0BmIjcs/qWlfM6vU/WVSY=
X-Gm-Message-State: AOJu0YyT5FAyyp3aaLdPhWjcysd3G6ntopgO9S6KEmE4FcYNNENag33Q
	8y3ch4Vr3b7zFl2O2EekydaJQG8B7Gj2WDjNozZwdNxgHQt+IuskbQ2dDxxfrgWrNKmE+0r3mfo
	04rD7cT+eKvC5kfU8dFmE/AZ4XoK2Gg9hViktTQ==
X-Google-Smtp-Source: AGHT+IE4U3kv4KKVkn6K8Eno6bQn2mcZkh8pakJlr0wIpxbQQ1u+tivCmiQRexYyTG7v7mqiGpse3RDczpi/gzo+s8U=
X-Received: by 2002:a17:906:d8c:b0:a46:181f:c1c3 with SMTP id
 m12-20020a1709060d8c00b00a46181fc1c3mr13302182eji.70.1711033493806; Thu, 21
 Mar 2024 08:04:53 -0700 (PDT)
MIME-Version: 1.0
References: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
 <20240315105902.160047-5-carlo.nonato@minervasys.tech> 
In-Reply-To: 
From: Carlo Nonato 
Date: Thu, 21 Mar 2024 16:04:43 +0100
Message-ID: 
Subject: Re: [PATCH v7 04/14] xen/arm: add Dom0 cache coloring support
To: Jan Beulich 
Cc: Andrew Cooper , George Dunlap , 
	Julien Grall , Stefano Stabellini , Wei Liu , 
	Bertrand Marquis , Michal Orzel , 
	Volodymyr Babchuk , Marco Solieri , 
	xen-devel@lists.xenproject.org, 
	Andrea Bastoni 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Jan,

On Tue, Mar 19, 2024 at 4:30=E2=80=AFPM Jan Beulich  wro=
te:
>
> On 15.03.2024 11:58, Carlo Nonato wrote:
> > --- a/docs/misc/xen-command-line.pandoc
> > +++ b/docs/misc/xen-command-line.pandoc
> > @@ -963,6 +963,15 @@ Controls for the dom0 IOMMU setup.
> >
> >  Specify a list of IO ports to be excluded from dom0 access.
> >
> > +### dom0-llc-colors
> > +> `=3D List of [  | - ]`
> > +
> > +> Default: `All available LLC colors`
> > +
> > +Specify dom0 LLC color configuration. This option is available only wh=
en
> > +`CONFIG_LLC_COLORING` is enabled. If the parameter is not set, all ava=
ilable
> > +colors are used.
>
> My reservation towards this being a top-level option remains.

How can I turn this into a lower-level option? Moving it into "dom0=3D" doe=
sn't
seem possible to me. How can I express a list (llc-colors) inside another l=
ist
(dom0)? dom0=3Dllc-colors=3D0-3,12-15,other-param=3D... How can I stop pars=
ing
before reaching other-param?

> > --- a/xen/common/llc-coloring.c
> > +++ b/xen/common/llc-coloring.c
> > @@ -18,6 +18,63 @@ integer_param("llc-nr-ways", llc_nr_ways);
> >  /* Number of colors available in the LLC */
> >  static unsigned int __ro_after_init max_nr_colors;
> >
> > +static unsigned int __initdata dom0_colors[CONFIG_NR_LLC_COLORS];
> > +static unsigned int __initdata dom0_num_colors;
> > +
> > +/*
> > + * Parse the coloring configuration given in the buf string, following=
 the
> > + * syntax below.
> > + *
> > + * COLOR_CONFIGURATION ::=3D COLOR | RANGE,...,COLOR | RANGE
> > + * RANGE               ::=3D COLOR-COLOR
> > + *
> > + * Example: "0,2-6,15-16" represents the set of colors: 0,2,3,4,5,6,15=
,16.
> > + */
> > +static int __init parse_color_config(const char *buf, unsigned int *co=
lors,
> > +                                     unsigned int max_num_colors,
> > +                                     unsigned int *num_colors)
> > +{
> > +    const char *s =3D buf;
> > +
> > +    *num_colors =3D 0;
> > +
> > +    while ( *s !=3D '\0' )
> > +    {
> > +        unsigned int color, start, end;
> > +
> > +        start =3D simple_strtoul(s, &s, 0);
> > +
> > +        if ( *s =3D=3D '-' )    /* Range */
> > +        {
> > +            s++;
> > +            end =3D simple_strtoul(s, &s, 0);
> > +        }
> > +        else                /* Single value */
> > +            end =3D start;
> > +
> > +        if ( start > end || (end - start) > (UINT_MAX - *num_colors) |=
|
> > +             (*num_colors + (end - start)) >=3D max_num_colors )
> > +            return -EINVAL;
> > +
> > +        for ( color =3D start; color <=3D end; color++ )
> > +            colors[(*num_colors)++] =3D color;
>
> I can't spot any range check on start/end/color itself. In fact I was fir=
st
> meaning to ask why the return value of simple_strtoul() is silently clipp=
ed
> from unsigned long to unsigned int. Don't forget that a range specificati=
on
> may easily degenerate into a negative number (due to a simple oversight o=
r
> typo), which would then be converted to a huge positive one.
>
> > @@ -41,6 +98,22 @@ static void print_colors(const unsigned int *colors,=
 unsigned int num_colors)
> >      printk(" }\n");
> >  }
> >
> > +static bool check_colors(const unsigned int *colors, unsigned int num_=
colors)
> > +{
> > +    unsigned int i;
> > +
> > +    for ( i =3D 0; i < num_colors; i++ )
> > +    {
> > +        if ( colors[i] >=3D max_nr_colors )
> > +        {
> > +            printk(XENLOG_ERR "LLC color %u >=3D %u\n", colors[i], max=
_nr_colors);
> > +            return false;
> > +        }
> > +    }
> > +
> > +    return true;
> > +}
>
> Oh, here's the range checking of the color values themselves. Perhaps
> a comment in parse_color_config() would help.

I'll add it.

> > @@ -91,6 +164,61 @@ void cf_check domain_dump_llc_colors(const struct d=
omain *d)
> >      print_colors(d->llc_colors, d->num_llc_colors);
> >  }
> >
> > +static int domain_set_default_colors(struct domain *d)
> > +{
> > +    unsigned int *colors =3D xmalloc_array(unsigned int, max_nr_colors=
);
> > +    unsigned int i;
> > +
> > +    if ( !colors )
> > +        return -ENOMEM;
> > +
> > +    printk(XENLOG_WARNING
> > +           "LLC color config not found for %pd, using all colors\n", d=
);
> > +
> > +    for ( i =3D 0; i < max_nr_colors; i++ )
> > +        colors[i] =3D i;
> > +
> > +    d->llc_colors =3D colors;
> > +    d->num_llc_colors =3D max_nr_colors;
> > +
> > +    return 0;
> > +}
>
> If this function is expected to actually come into play, wouldn't it
> make sense to set up such an array just once, and re-use it wherever
> necessary?

Then how to distinguish when to free it in domain_destroy() and when not to=
 do
it?

> Also right here both this and check_colors() could be __init. I
> understand that subsequent patches will also want to use the
> functions at runtime, but until then this looks slightly wrong. I'd
> like to ask that such aspects be mentioned in the description, to
> avoid respective questions.

Ok, I'll do that.

> > +int __init dom0_set_llc_colors(struct domain *d)
> > +{
> > +    unsigned int *colors;
> > +
> > +    if ( !dom0_num_colors )
> > +        return domain_set_default_colors(d);
> > +
> > +    if ( !check_colors(dom0_colors, dom0_num_colors) )
> > +    {
> > +        printk(XENLOG_ERR "Bad LLC color config for %pd\n", d);
> > +        return -EINVAL;
> > +    }
> > +
> > +    colors =3D xmalloc_array(unsigned int, dom0_num_colors);
> > +    if ( !colors )
> > +        return -ENOMEM;
> > +
> > +    /* Static type checking */
> > +    (void)(colors =3D=3D dom0_colors);
>
> Btw, a means to avoid this would by to use typeof() in the declaration
> of "colors".

Right.

> > +static int __init parse_dom0_colors(const char *s)
> > +{
> > +    return parse_color_config(s, dom0_colors, ARRAY_SIZE(dom0_colors),
>
> With it not being possible to pass max_nr_colors here (due to the value
> not having been established yet), don't you need to check somewhere else
> that ...
>
> > +                              &dom0_num_colors);
>
> ... dom0_num_colors isn't too large?

I can add it in dom0_set_llc_colors().

> Jan

Thanks.


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 15:11:45 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 15:11:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696442.1087380 (Exim 4.92)
	(envelope-from )
	id 1rnK50-0005WZ-25; Thu, 21 Mar 2024 15:11:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696442.1087380; Thu, 21 Mar 2024 15:11:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnK4z-0005WS-Vp; Thu, 21 Mar 2024 15:11:41 +0000
Received: by outflank-mailman (input) for mailman id 696442;
 Thu, 21 Mar 2024 15:11:40 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rnK4y-0005WM-5K
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 15:11:40 +0000
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com
 [2a00:1450:4864:20::634])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5059ae92-e795-11ee-a1ee-f123f15fe8a2;
 Thu, 21 Mar 2024 16:11:38 +0100 (CET)
Received: by mail-ej1-x634.google.com with SMTP id
 a640c23a62f3a-a46cc947929so154684466b.1
 for ; Thu, 21 Mar 2024 08:11:38 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5059ae92-e795-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1711033897; x=1711638697; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=BCwDUGaPeMyFiB1CUk8FbxJ0O95IDAcfx5IQJ0Y4GEs=;
        b=R6JRLiwX9nDRNtsUbEhFWh+qajlfne0/bCgE2RLOK0xfZpRWtkzFyE1UUpZ7g43Ofy
         WA11/xnMzHsDpfm6Hw2fWXKVC81XOmq0IM1DpVXyi5LlbcV+lPkAUkYru1/Gaq3z8XLh
         TUOcocKIn3FB8xBaA8zDr/x9ottxgxSAo9S1dtlZ5eLK3+qKDy2asYk8rt5cUOKv4ZVH
         kteJp/KuWbP82lDbypN2Oj9oziL4lB9IBdqbmHtEe5MkHfH9uSbXKvOAsi488H0RoLXt
         y+OAmo8yCpn4G7uzjx99FiaS1WyEcmX06ZomjGUssUazioHRdA5r9TCmPQYJ7G+mMdTf
         gMng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711033897; x=1711638697;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=BCwDUGaPeMyFiB1CUk8FbxJ0O95IDAcfx5IQJ0Y4GEs=;
        b=KSgEwnmN9xbgwSjcEkTsWFoe3dlezJbk3pjxRXojrgACHjedBpM2zx8IlpKIbYS8Gq
         aAIYypuftt42ZoTyXCEa6hgsYETX1HLzsIEoh4Vuo08BlGNc9+KMeDfmSz3CgPngy+ea
         p09t6VTrQjQBrMNfh+Hzd7MdXx79ZGynlmUSMadDH4xOt2dpaeVP64Sdsz/N1XFEsaK2
         g7DRnVFH1oZc+5vjPG7ZUTw1S4JrL9xypjjFSYLPTmQGtRzaWr3bV/6tJQRw47gqy7H4
         AS+pO2E/kBl6y3LS442ZGPiX4yC5jScfoxFpF+Gv3bsGopWAdCh7Se5R9FhV5FvxY82v
         9bRw==
X-Forwarded-Encrypted: i=1; AJvYcCW9UiAMNA+vt//o6uAKG0HW+wsITF/5JDWf7B1h0sjBdhGV4mgPqTiBJ+l1W53aScUN8OVYKwpGCGczL5y7lPYF0yojN88LU7O1JEMVakE=
X-Gm-Message-State: AOJu0YxVeOEBDbhl1N+Rn9AQTXtWbhzrVuTt1YACRba09qWqIPsD8vR5
	H24cW092VAHnwZdXVrSlhNqcgteZrdvsQIiV6smTuj1vCHxXtHse0V9TSsRdKMx1YgTaHGA/crT
	NEqqgKHecGEkCJ5h5o/D4LvZQlFWpYFPUZ5Bu7A==
X-Google-Smtp-Source: AGHT+IHm3grAGohzksOvVuroHCiu8cuC2dN8SsQhJ6X0CMDMCNWhneMU9FC/ciN0JpoVIaj1WQZCwHdFMGzFKeUDZdQ=
X-Received: by 2002:a17:907:78c7:b0:a46:cc87:12f3 with SMTP id
 kv7-20020a17090778c700b00a46cc8712f3mr3732213ejc.75.1711033897580; Thu, 21
 Mar 2024 08:11:37 -0700 (PDT)
MIME-Version: 1.0
References: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
 <20240315105902.160047-6-carlo.nonato@minervasys.tech> 
In-Reply-To: 
From: Carlo Nonato 
Date: Thu, 21 Mar 2024 16:11:27 +0100
Message-ID: 
Subject: Re: [PATCH v7 05/14] xen: extend domctl interface for cache coloring
To: Jan Beulich 
Cc: Andrew Cooper , George Dunlap , 
	Julien Grall , Stefano Stabellini , Wei Liu , 
	Marco Solieri , xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Jan,

On Tue, Mar 19, 2024 at 4:37=E2=80=AFPM Jan Beulich  wro=
te:
>
> On 15.03.2024 11:58, Carlo Nonato wrote:
> > @@ -219,6 +220,39 @@ void domain_llc_coloring_free(struct domain *d)
> >      xfree(__va(__pa(d->llc_colors)));
> >  }
> >
> > +int domain_set_llc_colors(struct domain *d,
> > +                          const struct xen_domctl_set_llc_colors *conf=
ig)
> > +{
> > +    unsigned int *colors;
> > +
> > +    if ( d->num_llc_colors )
> > +        return -EEXIST;
> > +
> > +    if ( !config->num_llc_colors )
> > +        return domain_set_default_colors(d);
> > +
> > +    if ( config->num_llc_colors > max_nr_colors || config->pad )
>
> The check of "pad" wants carrying out in all cases; I expect it wants
> moving to the caller.

Ok.

> > +        return -EINVAL;
> > +
> > +    colors =3D xmalloc_array(unsigned int, config->num_llc_colors);
> > +    if ( !colors )
> > +        return -ENOMEM;
> > +
> > +    if ( copy_from_guest(colors, config->llc_colors, config->num_llc_c=
olors) )
> > +        return -EFAULT;
>
> You're leaking "colors" when taking this or ...
>
> > +    if ( !check_colors(colors, config->num_llc_colors) )
> > +    {
> > +        printk(XENLOG_ERR "Bad LLC color config for %pd\n", d);
> > +        return -EINVAL;
>
> ... this error path.

You're right.

> Jan

Thanks.

On Tue, Mar 19, 2024 at 4:37=E2=80=AFPM Jan Beulich  wro=
te:
>
> On 15.03.2024 11:58, Carlo Nonato wrote:
> > @@ -219,6 +220,39 @@ void domain_llc_coloring_free(struct domain *d)
> >      xfree(__va(__pa(d->llc_colors)));
> >  }
> >
> > +int domain_set_llc_colors(struct domain *d,
> > +                          const struct xen_domctl_set_llc_colors *conf=
ig)
> > +{
> > +    unsigned int *colors;
> > +
> > +    if ( d->num_llc_colors )
> > +        return -EEXIST;
> > +
> > +    if ( !config->num_llc_colors )
> > +        return domain_set_default_colors(d);
> > +
> > +    if ( config->num_llc_colors > max_nr_colors || config->pad )
>
> The check of "pad" wants carrying out in all cases; I expect it wants
> moving to the caller.
>
> > +        return -EINVAL;
> > +
> > +    colors =3D xmalloc_array(unsigned int, config->num_llc_colors);
> > +    if ( !colors )
> > +        return -ENOMEM;
> > +
> > +    if ( copy_from_guest(colors, config->llc_colors, config->num_llc_c=
olors) )
> > +        return -EFAULT;
>
> You're leaking "colors" when taking this or ...
>
> > +    if ( !check_colors(colors, config->num_llc_colors) )
> > +    {
> > +        printk(XENLOG_ERR "Bad LLC color config for %pd\n", d);
> > +        return -EINVAL;
>
> ... this error path.
>
> Jan


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 15:12:56 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 15:12:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696444.1087390 (Exim 4.92)
	(envelope-from )
	id 1rnK6B-000639-CM; Thu, 21 Mar 2024 15:12:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696444.1087390; Thu, 21 Mar 2024 15:12:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnK6B-000632-8u; Thu, 21 Mar 2024 15:12:55 +0000
Received: by outflank-mailman (input) for mailman id 696444;
 Thu, 21 Mar 2024 15:12:53 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rnK69-00062s-M3
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 15:12:53 +0000
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com
 [2a00:1450:4864:20::62a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7cf0cc4b-e795-11ee-afe0-a90da7624cb6;
 Thu, 21 Mar 2024 16:12:52 +0100 (CET)
Received: by mail-ej1-x62a.google.com with SMTP id
 a640c23a62f3a-a4675aaa2e8so151780566b.0
 for ; Thu, 21 Mar 2024 08:12:52 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7cf0cc4b-e795-11ee-afe0-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1711033972; x=1711638772; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=lZsjC4BWr9j80CiGoYlcjaFvLnxbw82JJtssygaJkjQ=;
        b=eDQJl6U1la+uEKCPF4dlErhru7XP9dUrebBTATetVXU8qhW6Xx6ofIHYve/ScjlGg8
         aREtrA9XxnONU+K+ImZ1hZN1+wkCVtS8UcOEfssLhThud5oVGvRrcEKcBXJDLXBriPy1
         Uv8ab6djSMaEAPARWgNY4RhVKDTCgGgyXhec/qxuw4yxa8CEhw6J/lfe/fCjagxa9Z/G
         iB6gaI/xh9suBgmhZcqshB09isGX92qZg7ZkPbAILrwRLz6THDfCDEc903QTtMCuiHdM
         L3dCtCPe+5Fa3oglzzdi+EscNke86tdgJfOF8+IxJV7POUlG+YT6KGDighmCQpFyVx8R
         9nVw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711033972; x=1711638772;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=lZsjC4BWr9j80CiGoYlcjaFvLnxbw82JJtssygaJkjQ=;
        b=S38NWKqfBcU+wMgUdB2EKv75ZbHtm6ffhTtDNjqNdHzmjZ5CF8TwzSWsLNbHxINuha
         S32OdT5TBFQRJYpnStOyveQVdePTp+sXhGL3mM+wNDFIy1SlmMZdlwxHoHhdTuMiw/lV
         DQRi7QS09BvL5DMY/6HTQyMSUoSZWMR7AHxWeYRzwRBzL1bovJR6nTn62B2KD9ye4wXS
         Bkf9ebHFhmkbbzd/DC0txHcVlr+Qt/7GpkRkIFQA07p9LTYhaYFZIFaDX3N/3gWZpPgP
         LLEzNE4e8eoObOzhMQbtu6hsUmDPPeZ4GJ02FacfGHC9QLN8sxpVxB8l1lMIgGMGDQd4
         FhHA==
X-Forwarded-Encrypted: i=1; AJvYcCV5uq7VtE0+dZ9UpWUWAiJk5fmhpkRBxk8gdUlPq6Gl7shcDjU7R1OAPZXwStisc+6opWYh9PRA64q7nMrY5YoJDs0pvbvIjRSuTzRtu+s=
X-Gm-Message-State: AOJu0YwDCGH+GIVglGGKPdjiCxS0Yt7kWBFoMCg0vh0erCBjap5v3bFh
	C52v0xDB+oIK+ukPpUfi2XcxrWCjePgVInEIXs62lx9NkJXV76Kg49mMsct76LeeehTBjSHIOLl
	OCvLzAgyYRxqcV8vCa2VXmzJ/vpljGGYP/YVECA==
X-Google-Smtp-Source: AGHT+IF0gnp8xH4UfAB5ouXJ19aQpTRgdeuHIWDgQ6q01PKXePDjOMFhY8LwHdTohmX7cfXzCgy12eW+GAlUD1N8AOI=
X-Received: by 2002:a17:906:fa1b:b0:a3f:33b2:5ce2 with SMTP id
 lo27-20020a170906fa1b00b00a3f33b25ce2mr1617853ejb.35.1711033972423; Thu, 21
 Mar 2024 08:12:52 -0700 (PDT)
MIME-Version: 1.0
References: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
 <20240315105902.160047-8-carlo.nonato@minervasys.tech> <8194d91a-a71a-44f2-a498-61297ac2ee29@suse.com>
In-Reply-To: <8194d91a-a71a-44f2-a498-61297ac2ee29@suse.com>
From: Carlo Nonato 
Date: Thu, 21 Mar 2024 16:12:41 +0100
Message-ID: 
Subject: Re: [PATCH v7 07/14] xen/arm: add support for cache coloring
 configuration via device-tree
To: Jan Beulich 
Cc: Stefano Stabellini , Julien Grall , 
	Bertrand Marquis , Michal Orzel , 
	Volodymyr Babchuk , Andrew Cooper , 
	George Dunlap , Wei Liu , 
	Marco Solieri , xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Jan,

On Tue, Mar 19, 2024 at 4:41=E2=80=AFPM Jan Beulich  wro=
te:
>
> On 15.03.2024 11:58, Carlo Nonato wrote:
> > --- a/xen/common/llc-coloring.c
> > +++ b/xen/common/llc-coloring.c
> > @@ -253,6 +253,37 @@ int domain_set_llc_colors(struct domain *d,
> >      return 0;
> >  }
> >
> > +int __init domain_set_llc_colors_from_str(struct domain *d, const char=
 *str)
> > +{
> > +    int err;
> > +    unsigned int *colors, num_colors;
> > +
> > +    if ( !str )
> > +        return domain_set_default_colors(d);
> > +
> > +    colors =3D xmalloc_array(unsigned int, max_nr_colors);
> > +    if ( !colors )
> > +        return -ENOMEM;
> > +
> > +    err =3D parse_color_config(str, colors, max_nr_colors, &num_colors=
);
> > +    if ( err )
> > +    {
> > +        printk(XENLOG_ERR "Error parsing LLC color configuration");
> > +        return err;
> > +    }
> > +
> > +    if ( !check_colors(colors, num_colors) )
> > +    {
> > +        printk(XENLOG_ERR "Bad LLC color config for %pd\n", d);
> > +        return -EINVAL;
> > +    }
>
> "colors" is again leaked on the error paths.

Yep.

> > +    d->llc_colors =3D colors;
> > +    d->num_llc_colors =3D num_colors;
>
> num_colors may be quite a bit smaller than max_nr_colors; worth re-
> allocating the array to free up excess space?

Don't know if it's worth it, but it's a very small change so I think I can =
add
it.

> Jan

Thanks.


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 15:36:42 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 15:36:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696450.1087401 (Exim 4.92)
	(envelope-from )
	id 1rnKT6-0001Gf-8Q; Thu, 21 Mar 2024 15:36:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696450.1087401; Thu, 21 Mar 2024 15:36:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnKT6-0001GY-3s; Thu, 21 Mar 2024 15:36:36 +0000
Received: by outflank-mailman (input) for mailman id 696450;
 Thu, 21 Mar 2024 15:36:35 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rnKT5-0001GS-Jw
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 15:36:35 +0000
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com
 [2a00:1450:4864:20::62c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id cc00d854-e798-11ee-afe0-a90da7624cb6;
 Thu, 21 Mar 2024 16:36:34 +0100 (CET)
Received: by mail-ej1-x62c.google.com with SMTP id
 a640c23a62f3a-a4644bde1d4so155202066b.3
 for ; Thu, 21 Mar 2024 08:36:34 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: cc00d854-e798-11ee-afe0-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1711035393; x=1711640193; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=KnqlUy7Ur0A23UUjZxjTHOStUMnKCmNJ5F5UJxdjgIw=;
        b=sr+8ObDGTqVL4ypE0Do9aaQiznaZMY4PkrWS3TrYQ86hrzFt92kqi+v8v/8HiSB69O
         tNGm1rCaZZNSAizHYrCBC5aYqkEL5i+v5bEDjAN9Xtl+O6jC1mEClSAPeiiNuw2znW9a
         lTTrj2SVEAlXPKx9+pv7GwEeUH0x5gL/wpRtR8vUFS617O6a9/UZif1qTSohK97ToyuM
         yGnxheYKL6hpPUDCd7Latd4p6sOrjHNy165VnjFTSOjLhb3pH2gn5MDcjpH4AB9uSqZM
         mFmsSJbD9WPjuc9/lI9C27u1YfiDFCyACQ5PBQh+vmULAhySZh5EUnmtVwSitOBRQHO5
         CG0w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711035393; x=1711640193;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=KnqlUy7Ur0A23UUjZxjTHOStUMnKCmNJ5F5UJxdjgIw=;
        b=Arof83/B6vnA3wYTs7YbR1RC7ZYbFlZG5AEzgZKJXbiQZzjZ12u8ZOfmkrug4ao2yW
         660hL6fljRgBae+xp+8RsprqY20ROa2e5L1oJCGdIOp52wlPRtItR2cQhpz4xlme9kLs
         yptcZD+maBXxFCSOqAOZUpISMrKe4SH1v9Mpyx1UN/XIB1gxyBVxN4xZhZWdpt0ZlpgH
         3Id8JF6XfxhA3e0l4nHJBN+cpBvppq3i3kLhYaULNPZmGt03pGY556w0FEQW8SYjp24t
         rxq2sCzn/eQ9vcY/yo594d5IFgUXfHvk5vuUci6LFo14SfHBzAy5fWXrotGQlUXKr1zb
         OwBA==
X-Forwarded-Encrypted: i=1; AJvYcCUgcyu5Ly8FNfJCtDZLELhmrGXySTe1w96nHC6z3etRPe53PkmApEY6XEy/1khalItYuznuOwQBRdIGGV4+CQWc14DJ/6IHb97x1MNlBoo=
X-Gm-Message-State: AOJu0YwNnB2pWFmz+a4asc+0k4i4RGFOQg3y+fdEzcRiJHqzdh0+aZ7/
	yiF3YGUNvnoh210Tp4pQCPc8OUqyXSkhxS/vmtTtSwgv5wH4bcBVfWPw9DfS+ob635j7Kty89eN
	wbRv9eVWNYM/wz4aAhf01g+q1Kzk3Iecgl++Y6w==
X-Google-Smtp-Source: AGHT+IF+b4z6TD+3LNrKZdZElHLWGv/Sx4ccr3IC7du7Ipbe6zJ9e7godBtp2HArsVb8wsgBhhArVzvRQtnTQgArf6M=
X-Received: by 2002:a17:906:f849:b0:a46:f955:3721 with SMTP id
 ks9-20020a170906f84900b00a46f9553721mr3689472ejb.58.1711035393490; Thu, 21
 Mar 2024 08:36:33 -0700 (PDT)
MIME-Version: 1.0
References: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
 <20240315105902.160047-11-carlo.nonato@minervasys.tech> 
In-Reply-To: 
From: Carlo Nonato 
Date: Thu, 21 Mar 2024 16:36:22 +0100
Message-ID: 
Subject: Re: [PATCH v7 10/14] xen: add cache coloring allocator for domains
To: Jan Beulich 
Cc: Andrew Cooper , George Dunlap , 
	Julien Grall , Stefano Stabellini , Wei Liu , 
	Bertrand Marquis , Michal Orzel , 
	Volodymyr Babchuk , Marco Solieri , 
	xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Jan,

On Tue, Mar 19, 2024 at 5:43=E2=80=AFPM Jan Beulich  wro=
te:
>
> On 15.03.2024 11:58, Carlo Nonato wrote:
> > Add a new memory page allocator that implements the cache coloring mech=
anism.
> > The allocation algorithm enforces equal frequency distribution of cache
> > partitions, following the coloring configuration of a domain. This allo=
ws
> > for an even utilization of cache sets for every domain.
> >
> > Pages are stored in a color-indexed array of lists. Those lists are fil=
led
> > by a simple init function which computes the color of each page.
> > When a domain requests a page, the allocator extract the page from the =
list
> > with the maximum number of free pages between those that the domain can
> > access, given its coloring configuration.
>
> Minor remark: I'm not a native speaker, but "between" here reads odd to
> me. I'd have expected perhaps "among".

Yes, I'm gonna change it.

> > --- a/docs/misc/xen-command-line.pandoc
> > +++ b/docs/misc/xen-command-line.pandoc
> > @@ -270,6 +270,20 @@ and not running softirqs. Reduce this if softirqs =
are not being run frequently
> >  enough. Setting this to a high value may cause boot failure, particula=
rly if
> >  the NMI watchdog is also enabled.
> >
> > +### buddy-alloc-size (arm64)
> > +> `=3D `
> > +
> > +> Default: `64M`
> > +
> > +Amount of memory reserved for the buddy allocator when colored allocat=
or is
> > +active. This options is parsed only when LLC coloring support is enabl=
ed.
>
> Nit: s/parsed/used/ - the option is always parsed as long as LLC_COLORING=
=3Dy.
>
> > @@ -1945,6 +1949,164 @@ static unsigned long avail_heap_pages(
> >      return free_pages;
> >  }
> >
> > +/*************************
> > + * COLORED SIDE-ALLOCATOR
> > + *
> > + * Pages are grouped by LLC color in lists which are globally referred=
 to as the
> > + * color heap. Lists are populated in end_boot_allocator().
> > + * After initialization there will be N lists where N is the number of
> > + * available colors on the platform.
> > + */
> > +static struct page_list_head *__ro_after_init _color_heap;
> > +#define color_heap(color) (&_color_heap[color])
> > +
> > +static unsigned long *__ro_after_init free_colored_pages;
> > +
> > +/* Memory required for buddy allocator to work with colored one */
> > +#ifdef CONFIG_LLC_COLORING
> > +static unsigned long __initdata buddy_alloc_size =3D
> > +    MB(CONFIG_BUDDY_ALLOCATOR_SIZE);
> > +size_param("buddy-alloc-size", buddy_alloc_size);
> > +
> > +#define domain_num_llc_colors(d) (d)->num_llc_colors
> > +#define domain_llc_color(d, i)   (d)->llc_colors[i]
> > +#else
> > +static unsigned long __initdata buddy_alloc_size;
> > +
> > +#define domain_num_llc_colors(d) 0
> > +#define domain_llc_color(d, i)   0
> > +#endif
> > +
> > +static void free_color_heap_page(struct page_info *pg, bool need_scrub=
)
> > +{
> > +    unsigned int color =3D page_to_llc_color(pg);
> > +    struct page_list_head *head =3D color_heap(color);
> > +
> > +    spin_lock(&heap_lock);
> > +
> > +    mark_page_free(pg, page_to_mfn(pg));
> > +
> > +    if ( need_scrub )
> > +    {
> > +        pg->count_info |=3D PGC_need_scrub;
> > +        poison_one_page(pg);
> > +    }
> > +
> > +    free_colored_pages[color]++;
> > +    page_list_add(pg, head);
>
> May I please ask for a comment (or at least some wording in the descripti=
on)
> as to the choice made here between head or tail insertion? When assuming
> that across a system there's no sharing of colors, preferably re-using
> cache-hot pages is certainly good. Whereas when colors can reasonably be
> expected to be shared, avoiding to quickly re-use a freed page can also
> have benefits.

I'll add it.

> > +static struct page_info *alloc_color_heap_page(unsigned int memflags,
> > +                                               const struct domain *d)
> > +{
> > +    struct page_info *pg =3D NULL;
> > +    unsigned int i, color =3D 0;
> > +    unsigned long max =3D 0;
> > +    bool need_tlbflush =3D false;
> > +    uint32_t tlbflush_timestamp =3D 0;
> > +    bool need_scrub;
> > +
> > +    if ( memflags >> _MEMF_bits )
> > +        return NULL;
>
> By mentioning MEMF_bits earlier on I meant to give an example. What
> about MEMF_node and in particular MEMF_exact_node? Certain other flags
> also aren't obvious as to being okay to silently ignore.

You're right.

> > +    spin_lock(&heap_lock);
> > +
> > +    for ( i =3D 0; i < domain_num_llc_colors(d); i++ )
> > +    {
> > +        unsigned long free =3D free_colored_pages[domain_llc_color(d, =
i)];
> > +
> > +        if ( free > max )
> > +        {
> > +            color =3D domain_llc_color(d, i);
> > +            pg =3D page_list_first(color_heap(color));
> > +            max =3D free;
> > +        }
> > +    }
> > +
> > +    if ( !pg )
> > +    {
> > +        spin_unlock(&heap_lock);
> > +        return NULL;
> > +    }
> > +
> > +    need_scrub =3D pg->count_info & (PGC_need_scrub);
> > +    pg->count_info =3D PGC_state_inuse | (pg->count_info & PGC_colored=
);
>
> Better PGC_preserved?

Yeah.

> > +static void __init init_color_heap_pages(struct page_info *pg,
> > +                                         unsigned long nr_pages)
> > +{
> > +    unsigned int i;
> > +    bool need_scrub =3D opt_bootscrub =3D=3D BOOTSCRUB_IDLE;
> > +
> > +    if ( buddy_alloc_size )
> > +    {
> > +        unsigned long buddy_pages =3D min(PFN_DOWN(buddy_alloc_size), =
nr_pages);
> > +
> > +        init_heap_pages(pg, buddy_pages);
>
> There's a corner case where init_heap_pages() would break when passed 0
> as 2nd argument.

I don't see it. There's just a for-loop that would be skipped in that case.=
..

> I think you want to alter the enclosing if() to
> "if ( buddy_alloc_size >=3D PAGE_SIZE )" to be entirely certain to avoid
> that case.

... anyway, ok.

> > +static void dump_color_heap(void)
> > +{
> > +    unsigned int color;
> > +
> > +    printk("Dumping color heap info\n");
> > +    for ( color =3D 0; color < get_max_nr_llc_colors(); color++ )
> > +        if ( free_colored_pages[color] > 0 )
> > +            printk("Color heap[%u]: %lu pages\n",
> > +                   color, free_colored_pages[color]);
> > +}
>
> While having all of the code above from here outside of any #ifdef is
> helpful to prevent unintended breakage when changes are made and tested
> only on non-Arm64 targets, I'd still like to ask: Halfway recent
> compilers manage to eliminate everything? I'd like to avoid e.g. x86
> being left with traces of coloring despite not being able at all to use
> it.

I don't know the answer to this, sorry.

> > @@ -2485,7 +2660,10 @@ struct page_info *alloc_domheap_pages(
> >          }
> >          if ( assign_page(pg, order, d, memflags) )
> >          {
> > -            free_heap_pages(pg, order, memflags & MEMF_no_scrub);
> > +            if ( pg->count_info & PGC_colored )
> > +                free_color_heap_page(pg, memflags & MEMF_no_scrub);
> > +            else
> > +                free_heap_pages(pg, order, memflags & MEMF_no_scrub);
> >              return NULL;
> >          }
> >      }
> > @@ -2568,7 +2746,10 @@ void free_domheap_pages(struct page_info *pg, un=
signed int order)
> >              scrub =3D 1;
> >          }
> >
> > -        free_heap_pages(pg, order, scrub);
> > +        if ( pg->count_info & PGC_colored )
> > +            free_color_heap_page(pg, scrub);
> > +        else
> > +            free_heap_pages(pg, order, scrub);
> >      }
>
> Instead of this, did you consider altering free_heap_pages() to forward
> to free_color_heap_page()? That would then also allow to have a single,
> central comment and/or assertion that the "order" value here isn't lost.

Yes this can be easily done.

> Jan

Thanks.


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 15:36:45 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 15:36:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696451.1087410 (Exim 4.92)
	(envelope-from )
	id 1rnKTF-0001XY-Go; Thu, 21 Mar 2024 15:36:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696451.1087410; Thu, 21 Mar 2024 15:36:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnKTF-0001XR-Dt; Thu, 21 Mar 2024 15:36:45 +0000
Received: by outflank-mailman (input) for mailman id 696451;
 Thu, 21 Mar 2024 15:36:44 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rnKTE-0001X0-K3
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 15:36:44 +0000
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com
 [2a00:1450:4864:20::62b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d0fb66c1-e798-11ee-a1ee-f123f15fe8a2;
 Thu, 21 Mar 2024 16:36:42 +0100 (CET)
Received: by mail-ej1-x62b.google.com with SMTP id
 a640c23a62f3a-a468226e135so136949466b.0
 for ; Thu, 21 Mar 2024 08:36:42 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d0fb66c1-e798-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1711035402; x=1711640202; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Y4GHRLapon4CXxUYbLR3Yah1Qo+858keL9qBn13Siuw=;
        b=1Az9qyOBl7AtCZphxvT3wEx9102/8AqFvckalD0A1NsktNydhT9kT1oTHSkgF3mfh0
         N4oGQ37bEuHZ3pXEQUhQIYjOkzfnpQN2qurzE2Per8ipWOiUx3wWtAC20gn+k9pKKPNd
         k+T39vH4q4hPima6wDuPLXdb20ADCoXjs+rBMnDOXMI1rlxzCrdLhVxtvwK1++xFFK3C
         KdaK+YhO4GToflFl/MY9/I/SW1WDGq4/zUseeX6A2V5uX5WWyoHCfTKIMbImSfQjf7vf
         IC0UyxJlDuL0scpbhFTpuRS/CbYZq92tZvvio20kSsZZvggiCwBE8O5TK+y6zsBP5RQH
         NMNg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711035402; x=1711640202;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=Y4GHRLapon4CXxUYbLR3Yah1Qo+858keL9qBn13Siuw=;
        b=H90L9vl93HRrz7AxFmRW0pH8EzCEWIfBl8muUqJ9vVSYKEl8hhjH0bwWS9isAkS1lI
         y/5N2Fo84vMmXDgOYYzxJmiUoFpRnNKxnj9dajjlmEqVbIAd4rxAzTOeuTVuH+c5rHjw
         oSHop+glHNTmOb7nW4TaI9eRijRbyuXigNviuJHnd7WHI7DxJz35I5ldA39WRc2TXagz
         T26cubbvuTIirPuXQbRV6KCidjCO7TkfG5nicVAERrxxSGS9aiWiNa7iBOvEKUdDtOMd
         HCxMZ9WxbcWRhdGeivx+f4/vrv/VidI/1zBgCiV04pynKgsrL9Udm/5+91A6kiUObiM0
         O/Cw==
X-Forwarded-Encrypted: i=1; AJvYcCV3bmTCeQjgTmQPfbSAvY7mlWjCFDjEdNRTiJjhpJd6oBUjrLhO35O/f7bIb+iX4GTnpfMZekcnzyYADl0z59aLbVANDA/6EL+TV2tfEV0=
X-Gm-Message-State: AOJu0Yw1wzMG+xEiYtO4MsvhiKqfiq1aohLlWQdhjg1VApqIt5pRJztq
	QpWWb5EdquraCXCW56QWug3oNAWWK6tEJPqmKJzPnlrqjOIbJhde5/uekQFY9Dx55spas3KBtF6
	xepjd5OzHPHjS6rwQLmbYNSr70ZjKlKFv4kAtXw==
X-Google-Smtp-Source: AGHT+IHn/0mojwAOAt47pcyKbDYRD72fCbHXzZc4cXxEXbWgGVT9UFeEDfOGKtj+d4PWNI5hjvQz1YfMlf+RZ0yegRc=
X-Received: by 2002:a17:907:9710:b0:a46:a3dc:3359 with SMTP id
 jg16-20020a170907971000b00a46a3dc3359mr14164136ejc.46.1711035401917; Thu, 21
 Mar 2024 08:36:41 -0700 (PDT)
MIME-Version: 1.0
References: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
 <20240315105902.160047-13-carlo.nonato@minervasys.tech> <094ace88-eea9-4527-b166-9cd83214928d@suse.com>
In-Reply-To: <094ace88-eea9-4527-b166-9cd83214928d@suse.com>
From: Carlo Nonato 
Date: Thu, 21 Mar 2024 16:36:31 +0100
Message-ID: 
Subject: Re: [PATCH v7 12/14] xen/arm: add Xen cache colors command line parameter
To: Jan Beulich 
Cc: Luca Miccio , Andrew Cooper , 
	George Dunlap , Julien Grall , 
	Stefano Stabellini , Wei Liu , 
	Marco Solieri , xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Jan

On Tue, Mar 19, 2024 at 4:54=E2=80=AFPM Jan Beulich  wro=
te:
>
> On 15.03.2024 11:59, Carlo Nonato wrote:
> > From: Luca Miccio 
> >
> > Add a new command line parameter to configure Xen cache colors.
> > These colors can be dumped with the cache coloring info debug-key.
> >
> > By default, Xen uses the first color.
> > Benchmarking the VM interrupt response time provides an estimation of
> > LLC usage by Xen's most latency-critical runtime task. Results on Arm
> > Cortex-A53 on Xilinx Zynq UltraScale+ XCZU9EG show that one color, whic=
h
> > reserves 64 KiB of L2, is enough to attain best responsiveness:
> > - Xen 1 color latency:  3.1 us
> > - Xen 2 color latency:  3.1 us
> >
> > More colors are instead very likely to be needed on processors whose L1
> > cache is physically-indexed and physically-tagged, such as Cortex-A57.
> > In such cases, coloring applies to L1 also, and there typically are two
> > distinct L1-colors. Therefore, reserving only one color for Xen would
> > senselessly partitions a cache memory that is already private, i.e.
> > underutilize it.
>
> Here you say that using just a single color is undesirable on such system=
s.
>
> > The default amount of Xen colors is thus set to one.
>
> Yet then, without any further explanation you conclude that 1 is the
> universal default.

A single default that suits every need doesn't exist, but we know that 1 is
good for the most widespread target we have (Cortex-A53). Having that said,
I think that a simple reorder of the description, while also making it more
explicit, solves the issue.

> > @@ -147,6 +159,21 @@ void __init llc_coloring_init(void)
> >          panic("Number of LLC colors (%u) not in range [2, %u]\n",
> >                max_nr_colors, CONFIG_NR_LLC_COLORS);
> >
> > +    if ( !xen_num_colors )
> > +    {
> > +        unsigned int i;
> > +
> > +        xen_num_colors =3D MIN(XEN_DEFAULT_NUM_COLORS, max_nr_colors);
> > +
> > +        printk(XENLOG_WARNING
> > +               "Xen LLC color config not found. Using first %u colors\=
n",
> > +               xen_num_colors);
> > +        for ( i =3D 0; i < xen_num_colors; i++ )
> > +            xen_colors[i] =3D i;
> > +    }
> > +    else if ( !check_colors(xen_colors, xen_num_colors) )
> > +        panic("Bad LLC color config for Xen\n");
>
> This "else" branch again lacks a bounds check against max_nr_colors, if
> I'm not mistaken.

Yep.

> Jan

Thanks.


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 15:53:22 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 15:53:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696461.1087420 (Exim 4.92)
	(envelope-from )
	id 1rnKjD-0005nU-So; Thu, 21 Mar 2024 15:53:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696461.1087420; Thu, 21 Mar 2024 15:53:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnKjD-0005nN-PM; Thu, 21 Mar 2024 15:53:15 +0000
Received: by outflank-mailman (input) for mailman id 696461;
 Thu, 21 Mar 2024 15:53:14 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnKjC-0005nB-NB
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 15:53:14 +0000
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com
 [2a00:1450:4864:20::532])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1f26a6d9-e79b-11ee-afe0-a90da7624cb6;
 Thu, 21 Mar 2024 16:53:12 +0100 (CET)
Received: by mail-ed1-x532.google.com with SMTP id
 4fb4d7f45d1cf-56b0af675deso1359530a12.1
 for ; Thu, 21 Mar 2024 08:53:12 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 x3-20020a05640226c300b0056851310a04sm19751edd.16.2024.03.21.08.53.11
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 21 Mar 2024 08:53:11 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1f26a6d9-e79b-11ee-afe0-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711036392; x=1711641192; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=qgj0ZJ8KZAy92Cb/7XwYPJOE6A/pJwKYnrMYa63ERBA=;
        b=dYh0vg/QyYeGlELY/bL9S5NS2akOdGs4IA7mJ884m1v1oV6Y/cBg9qc4297wR2mjXE
         jA7lzrRW7QiGDAkrj8iBxlxiR7i2jUd/qAJZAa9ZIugfAS9Fwlgd23BuUkpRn6qVDBHJ
         BBBvEb2CcRh70Ali9gdTkGR6GyIuV2qSxTdTv9Ty0NB6b/bclqk1QEGM0/wN7MzEg25h
         RudkHfAE4zPxpJ3vhm5t51Rz2BCRN/5Y6s83wcdbFkMPF7ZLtTCQdKjQBpHdQF+tTVFF
         P6tiWb+28KxYCYTYcEV62CVHtlrcfGaRaenrmD7J091jogH4aGTgx5j1B7z4Dp9+tfjr
         jk/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711036392; x=1711641192;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=qgj0ZJ8KZAy92Cb/7XwYPJOE6A/pJwKYnrMYa63ERBA=;
        b=SYf6FeP7cEndRkpuWQvuXSuh1meZ82iheu9UetCPj6HijugOQBSBCywXK7w8W8RXM6
         Y/2knfYHpmsW+i8aQdTs1sfyTtSzjDAT9rLR6dKQ4eZOpEgWpEXwjrU/azuO9e8gmi6u
         Fuy3OmgntRaCEoPxaKb9RlS39BKa/3Q8AKWF9+CSM0FbODMfR1exIuFH2eF0/es6kdhC
         ICYvD8Sz1PWL2DbyN4vcOJJjxnqFDRZLf8eY0RZIs1rshx4UDNhxm080fAYzc9yKnkSh
         kwA7CdPvsssKaWC6RDMUmgxfUMBRIu+yMQbHf+Qpg/LNil9rmNtYfkVPlhrRAj0KNsAi
         v/Aw==
X-Forwarded-Encrypted: i=1; AJvYcCWG7c3t3peCoD4gwXiZL7EgXgKDK8Hwwc0F0fpBaD7bTpOMQV25jGQq6jYTwRsddt0xIH1vQBUgrDFnvewXbvjtLzTx0hrELnZ6Hch9X04=
X-Gm-Message-State: AOJu0YzWeIKQHWBzO89qO98/EqCLHfv06AABN7kb4wYH57j0eo/7gp/+
	rfRazX4u7k8UbM/I7QwsZijyU/iTEFHJcDlpPSvxeziEKfZtu9atJ5f6Y9DRIg==
X-Google-Smtp-Source: AGHT+IEjyM7NWddGREwNi/evqBT8p1DomaLXw2yD4K6TA2EolVhHqm8bok99odJjK6b/gLUFYIGX8A==
X-Received: by 2002:a05:6402:3789:b0:568:bda1:9640 with SMTP id et9-20020a056402378900b00568bda19640mr3733364edb.13.1711036392000;
        Thu, 21 Mar 2024 08:53:12 -0700 (PDT)
Message-ID: <2b4d6e96-0f04-4327-9875-cd0587931621@suse.com>
Date: Thu, 21 Mar 2024 16:53:10 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 01/14] xen/common: add cache coloring common code
Content-Language: en-US
To: Carlo Nonato 
Cc: Andrea Bastoni ,
 Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 Marco Solieri , xen-devel@lists.xenproject.org
References: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
 <20240315105902.160047-2-carlo.nonato@minervasys.tech>
 <05e4d3da-4130-4c57-9855-43b685ce5005@suse.com>
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 21.03.2024 16:03, Carlo Nonato wrote:
> On Tue, Mar 19, 2024 at 3:58 PM Jan Beulich  wrote:
>> On 15.03.2024 11:58, Carlo Nonato wrote:
>>> --- a/docs/misc/xen-command-line.pandoc
>>> +++ b/docs/misc/xen-command-line.pandoc
>>> @@ -1706,6 +1706,43 @@ This option is intended for debugging purposes only.  Enable MSR_DEBUGCTL.LBR
>>>  in hypervisor context to be able to dump the Last Interrupt/Exception To/From
>>>  record with other registers.
>>>
>>> +### llc-coloring
>>> +> `= `
>>> +
>>> +> Default: `false`
>>> +
>>> +Flag to enable or disable LLC coloring support at runtime. This option is
>>> +available only when `CONFIG_LLC_COLORING` is enabled. See the general
>>> +cache coloring documentation for more info.
>>> +
>>> +### llc-nr-ways
>>> +> `= `
>>> +
>>> +> Default: `Obtained from hardware`
>>> +
>>> +Specify the number of ways of the Last Level Cache. This option is available
>>> +only when `CONFIG_LLC_COLORING` is enabled. LLC size and number of ways are used
>>> +to find the number of supported cache colors. By default the value is
>>> +automatically computed by probing the hardware, but in case of specific needs,
>>> +it can be manually set. Those include failing probing and debugging/testing
>>> +purposes so that it's possibile to emulate platforms with different number of
>>> +supported colors. If set, also "llc-size" must be set, otherwise the default
>>> +will be used.
>>> +
>>> +### llc-size
>>> +> `= `
>>> +
>>> +> Default: `Obtained from hardware`
>>> +
>>> +Specify the size of the Last Level Cache. This option is available only when
>>> +`CONFIG_LLC_COLORING` is enabled. LLC size and number of ways are used to find
>>> +the number of supported cache colors. By default the value is automatically
>>> +computed by probing the hardware, but in case of specific needs, it can be
>>> +manually set. Those include failing probing and debugging/testing purposes so
>>> +that it's possibile to emulate platforms with different number of supported
>>> +colors. If set, also "llc-nr-ways" must be set, otherwise the default will be
>>> +used.
>>
>> Wouldn't it make sense to infer "llc-coloring" when both of the latter options
>> were supplied?
> 
> To me it looks a bit strange that specifying some attributes of the cache
> automatically enables cache coloring. Also it would require some changes in
> how to express the auto-probing for such attributes.

Whereas to me it looks strange that, when having llc-size and llc-nr-ways
provided, I'd need to add a 3rd option. What purpose other than enabling
coloring could there be when specifying those parameters?

Jan


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 15:57:11 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 15:57:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696464.1087430 (Exim 4.92)
	(envelope-from )
	id 1rnKn0-0006Qs-Ad; Thu, 21 Mar 2024 15:57:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696464.1087430; Thu, 21 Mar 2024 15:57:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnKn0-0006Ql-7z; Thu, 21 Mar 2024 15:57:10 +0000
Received: by outflank-mailman (input) for mailman id 696464;
 Thu, 21 Mar 2024 15:57:08 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnKmy-0006QC-AQ
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 15:57:08 +0000
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com
 [2a00:1450:4864:20::531])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ab0f19b7-e79b-11ee-afe0-a90da7624cb6;
 Thu, 21 Mar 2024 16:57:07 +0100 (CET)
Received: by mail-ed1-x531.google.com with SMTP id
 4fb4d7f45d1cf-5684db9147dso1260498a12.2
 for ; Thu, 21 Mar 2024 08:57:07 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 s24-20020a508d18000000b0056a2cc5c868sm18057eds.72.2024.03.21.08.57.06
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 21 Mar 2024 08:57:06 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ab0f19b7-e79b-11ee-afe0-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711036627; x=1711641427; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=bH2tQdROdE1XJnuc3haR/Rw5X+zMBpbGttw2yxStdVU=;
        b=MX0q/GHAV/TQ4Cko8lJA0rnsbvNKPQNzxxUEoYEQwT9blkoyzITCvR9NsBCrS/PAe7
         oeU9KcNAEHKq8MZO8zgXtGFn8q11sfKTet5l22UExMOODGKDxjVgKaXeF6344Z4tuuXG
         02Ad28TfOLqJ1JDxei4MYc1z7S4qEKwe57uq4VLzk1mpzjX2f0qoR/hRqtBdtUIeTR0f
         6zFsaQ0L6bN99eP8XpxyVjFQQyU75ubaTcYqsyqr5e5UOX+DeZ3ygQWFewdHZyOk54Yg
         Csr9i4+Sx6dWnFVKkKTczwa/OHk7q6z9eJ7mMXsSpZ193kxX+9ginBSJCBgjM9rQh+PV
         f3ig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711036627; x=1711641427;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=bH2tQdROdE1XJnuc3haR/Rw5X+zMBpbGttw2yxStdVU=;
        b=iQFAgE+RuKEa++T3FTgFSAf3HHVoddRZmsJjKoyiwNq0iWT8nNV0N7nOBzFQ/ulSIJ
         Yk7AC8+caBfsQaMSAPyO0unf2H6X+dJwa9qQXpgZdnwTcmH99JKLa+APE593HmuwUuXr
         8CvkEEUQs9zcDh2e1bRcjPwJVNpqRLT+fAdCiEYhcNwLcp8/N3qtBT0PwsEpNS899k5r
         fqNa96exrUjoTplVSZQR4o1qayUWfY4PU/TbfpP5mb3NG5bJmBDU6nzDqOlXzlKhxxvi
         iPDFbCboVS4W9gfeBhQGMGVSLlJqsTXeIB8kUaKieTMBt4O1HTNyOYBVmlhMVdMqVmQy
         lI/A==
X-Forwarded-Encrypted: i=1; AJvYcCXizQvAvIuPAb6jBymXt7paRr0VhQt8u3Hl9C9BW5UQwUd+npX9y1ta6uA2eZHJG7AzAdoOSjQytAJlDDZMuWbtvi/RoN1705JbOsxvwIA=
X-Gm-Message-State: AOJu0YxQxKRgBdQwqPyTABbhTwPB4Jz4iC1tXLARBP/4MYxpDBh7waiN
	VdzbL4DxRWAitXx1k7oARh7Vb7y4ss4QEJtib5ZDtMeApqzq2PAmTnmhlvOpHQ==
X-Google-Smtp-Source: AGHT+IEobiYEqLZFbfW9djWqLoBbj/s2GIgtzBdF2fkaJYJJrI4znZtLOlfV+CDnMoYMSmniWa93Hw==
X-Received: by 2002:a05:6402:388c:b0:568:a523:a66f with SMTP id fd12-20020a056402388c00b00568a523a66fmr15543528edb.39.1711036626745;
        Thu, 21 Mar 2024 08:57:06 -0700 (PDT)
Message-ID: <3ff10fdd-5a85-43b3-853a-fe69c7388ca9@suse.com>
Date: Thu, 21 Mar 2024 16:57:05 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 04/14] xen/arm: add Dom0 cache coloring support
Content-Language: en-US
To: Carlo Nonato 
Cc: Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Marco Solieri ,
 xen-devel@lists.xenproject.org,
 Andrea Bastoni 
References: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
 <20240315105902.160047-5-carlo.nonato@minervasys.tech>
 
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 21.03.2024 16:04, Carlo Nonato wrote:
> On Tue, Mar 19, 2024 at 4:30 PM Jan Beulich  wrote:
>> On 15.03.2024 11:58, Carlo Nonato wrote:
>>> --- a/docs/misc/xen-command-line.pandoc
>>> +++ b/docs/misc/xen-command-line.pandoc
>>> @@ -963,6 +963,15 @@ Controls for the dom0 IOMMU setup.
>>>
>>>  Specify a list of IO ports to be excluded from dom0 access.
>>>
>>> +### dom0-llc-colors
>>> +> `= List of [  | - ]`
>>> +
>>> +> Default: `All available LLC colors`
>>> +
>>> +Specify dom0 LLC color configuration. This option is available only when
>>> +`CONFIG_LLC_COLORING` is enabled. If the parameter is not set, all available
>>> +colors are used.
>>
>> My reservation towards this being a top-level option remains.
> 
> How can I turn this into a lower-level option? Moving it into "dom0=" doesn't
> seem possible to me. How can I express a list (llc-colors) inside another list
> (dom0)? dom0=llc-colors=0-3,12-15,other-param=... How can I stop parsing
> before reaching other-param?

For example by using a different separator:

dom0=llc-colors=0-3+12-15,other-param=...

>>> @@ -91,6 +164,61 @@ void cf_check domain_dump_llc_colors(const struct domain *d)
>>>      print_colors(d->llc_colors, d->num_llc_colors);
>>>  }
>>>
>>> +static int domain_set_default_colors(struct domain *d)
>>> +{
>>> +    unsigned int *colors = xmalloc_array(unsigned int, max_nr_colors);
>>> +    unsigned int i;
>>> +
>>> +    if ( !colors )
>>> +        return -ENOMEM;
>>> +
>>> +    printk(XENLOG_WARNING
>>> +           "LLC color config not found for %pd, using all colors\n", d);
>>> +
>>> +    for ( i = 0; i < max_nr_colors; i++ )
>>> +        colors[i] = i;
>>> +
>>> +    d->llc_colors = colors;
>>> +    d->num_llc_colors = max_nr_colors;
>>> +
>>> +    return 0;
>>> +}
>>
>> If this function is expected to actually come into play, wouldn't it
>> make sense to set up such an array just once, and re-use it wherever
>> necessary?
> 
> Then how to distinguish when to free it in domain_destroy() and when not to do
> it?

By checking against that one special array instance.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 16:04:19 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 16:04:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696468.1087439 (Exim 4.92)
	(envelope-from )
	id 1rnKtg-0000sB-0C; Thu, 21 Mar 2024 16:04:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696468.1087439; Thu, 21 Mar 2024 16:04:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnKtf-0000s4-Tj; Thu, 21 Mar 2024 16:04:03 +0000
Received: by outflank-mailman (input) for mailman id 696468;
 Thu, 21 Mar 2024 16:04:02 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnKte-0000ru-NN
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 16:04:02 +0000
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com
 [2a00:1450:4864:20::530])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a1747b28-e79c-11ee-a1ee-f123f15fe8a2;
 Thu, 21 Mar 2024 17:04:00 +0100 (CET)
Received: by mail-ed1-x530.google.com with SMTP id
 4fb4d7f45d1cf-56bcede226eso874514a12.1
 for ; Thu, 21 Mar 2024 09:04:00 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 m22-20020a50ef16000000b00569a2f698d7sm26271eds.49.2024.03.21.09.03.59
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 21 Mar 2024 09:03:59 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a1747b28-e79c-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711037040; x=1711641840; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=M2AFIdCcA/T9XPCpHDgu1ZX7Nv4mvO8XCX39UZzBP9A=;
        b=f+BQ772FzYoHpCevAho7XgSWtL7Vd0GVjNbQwSTeWW5rZSvGsT0xjzMC/oh8nTiJAW
         PX71/aV0EGL9FGPkzAIdOsAprbxrDtNcjYBw3pxLXRWFqprho+M3dFfNAwWHETxG0/kj
         zhgVty68XQ9O152UiK2YBHW1xH/ApfAnDFRN/e8XVJy5wd6txk2zVWJBxKwOH/r8yE0H
         1p2XRekWpTD5IC6aNZOtXA+hiHCU1y3Sls5ZEHgptPjioAvClv2PHaupJcGMwpoieX/N
         F4KzVX4dxkcGyLOVrQ1+eZQREl23t7ek4xD0O9OulrVLYOkcLKrwWvhwebJOtDVlEKUQ
         2OGw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711037040; x=1711641840;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=M2AFIdCcA/T9XPCpHDgu1ZX7Nv4mvO8XCX39UZzBP9A=;
        b=ZarebplZyU30ejYznLWos3Mgi8xT0W8fLSbEuf1gU6Ip1l7Gjsm5Jhn858gi9J8598
         SMHb7TLR8OygmcFr+CRpV/Xbx6sryIQhEauoyycnqUuOQXRmMPCcM13ozy3MCGeFI+R8
         /v6uAHr385AYwpvhdm6fbYMbE5oOT0xwuvhtYQiBaijHcB3JWFB2F1ThXCnv8rR/rxHT
         qXtPKoLBaox5AT1nfEiee/RbUkjJ2TsO4XAaGieCkbemWPC3Lr5q/1DTemSRbDYy3qxs
         jRuWXvgL4mhdGuvl384AW1YRm4NtjG3TNjYh7uRjODnItozcOO++FhxObgm58nuNEO2Z
         7Bmg==
X-Forwarded-Encrypted: i=1; AJvYcCXxlmGLn2tmdo5tjBtjgfbKJ07XvvLQfRx/F8QSOyx/yZfGzoMB3EDnTz/G3BytpKeh05/Rzb/4bblgeR2xVExLVTjOyc8EbfHzAJ1NM3s=
X-Gm-Message-State: AOJu0YztYpCC6mmfM3hOTdah/1Xnkmfe2E+YPSqsRVtbW4erMgGG1Gov
	OPKLUoxCuZ19CSpZ62PXSE5W2iaNVSZSwTwtFvyu0B5m5Uo4xl1LefqYtFXfeA==
X-Google-Smtp-Source: AGHT+IEmDNwTz7WhbmompA0vh5i1mDCstUqa5eMSQCWUVWuFG2LhylHKAbSdd4T+nMB0ZEupkVYjJg==
X-Received: by 2002:a05:6402:2219:b0:568:cec0:2f84 with SMTP id cq25-20020a056402221900b00568cec02f84mr3417791edb.22.1711037040135;
        Thu, 21 Mar 2024 09:04:00 -0700 (PDT)
Message-ID: <4e1f10e3-c2b5-49b9-830d-e7582c714d43@suse.com>
Date: Thu, 21 Mar 2024 17:03:58 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 10/14] xen: add cache coloring allocator for domains
Content-Language: en-US
To: Carlo Nonato 
Cc: Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Marco Solieri , xen-devel@lists.xenproject.org
References: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
 <20240315105902.160047-11-carlo.nonato@minervasys.tech>
 
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 21.03.2024 16:36, Carlo Nonato wrote:
> On Tue, Mar 19, 2024 at 5:43 PM Jan Beulich  wrote:
>> On 15.03.2024 11:58, Carlo Nonato wrote:
>>> +static void __init init_color_heap_pages(struct page_info *pg,
>>> +                                         unsigned long nr_pages)
>>> +{
>>> +    unsigned int i;
>>> +    bool need_scrub = opt_bootscrub == BOOTSCRUB_IDLE;
>>> +
>>> +    if ( buddy_alloc_size )
>>> +    {
>>> +        unsigned long buddy_pages = min(PFN_DOWN(buddy_alloc_size), nr_pages);
>>> +
>>> +        init_heap_pages(pg, buddy_pages);
>>
>> There's a corner case where init_heap_pages() would break when passed 0
>> as 2nd argument.
> 
> I don't see it. There's just a for-loop that would be skipped in that case...

Look at the first comment in the function and the if() following it. I
don't think that code would work very well when nr_pages == 0.

>>> +static void dump_color_heap(void)
>>> +{
>>> +    unsigned int color;
>>> +
>>> +    printk("Dumping color heap info\n");
>>> +    for ( color = 0; color < get_max_nr_llc_colors(); color++ )
>>> +        if ( free_colored_pages[color] > 0 )
>>> +            printk("Color heap[%u]: %lu pages\n",
>>> +                   color, free_colored_pages[color]);
>>> +}
>>
>> While having all of the code above from here outside of any #ifdef is
>> helpful to prevent unintended breakage when changes are made and tested
>> only on non-Arm64 targets, I'd still like to ask: Halfway recent
>> compilers manage to eliminate everything? I'd like to avoid e.g. x86
>> being left with traces of coloring despite not being able at all to use
>> it.
> 
> I don't know the answer to this, sorry.

Yet it is important to have.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 16:05:41 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 16:05:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696472.1087450 (Exim 4.92)
	(envelope-from )
	id 1rnKvE-0001Uw-FV; Thu, 21 Mar 2024 16:05:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696472.1087450; Thu, 21 Mar 2024 16:05:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnKvE-0001Up-C4; Thu, 21 Mar 2024 16:05:40 +0000
Received: by outflank-mailman (input) for mailman id 696472;
 Thu, 21 Mar 2024 16:05:39 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rnKvD-0001Uc-9s
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 16:05:39 +0000
Received: from mail.actia.se (mail.actia.se [212.181.117.226])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id db8faad9-e79c-11ee-afe0-a90da7624cb6;
 Thu, 21 Mar 2024 17:05:38 +0100 (CET)
Received: from S036ANL.actianordic.se (10.12.31.117) by S036ANL.actianordic.se
 (10.12.31.117) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.37; Thu, 21 Mar
 2024 17:05:37 +0100
Received: from S036ANL.actianordic.se ([fe80::e13e:1feb:4ea6:ec69]) by
 S036ANL.actianordic.se ([fe80::e13e:1feb:4ea6:ec69%4]) with mapi id
 15.01.2507.037; Thu, 21 Mar 2024 17:05:37 +0100
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: db8faad9-e79c-11ee-afe0-a90da7624cb6
From: John Ernberg 
To: Bertrand Marquis , Julien Grall 
CC: Peng Fan , Stefano Stabellini ,
	Michal Orzel , Volodymyr Babchuk
	, Jonas Blixt ,
	"xen-devel@lists.xenproject.org" 
Subject: Re: [PATCH 1/2] xen/arm: Add imx8q{m,x} platform glue
Thread-Topic: [PATCH 1/2] xen/arm: Add imx8q{m,x} platform glue
Thread-Index: AQHaVDuqVQ/kgxLZgUK/m8/hE0ez5bDzxxsAgAA1KwCAAVx5AIAAQjeAgAEdtQCAAyp5AIABm3uAgAZ8E4CAKNxDgIAApfwAgAKGQoCAAAbIgIAHmW8AgAtpcwCAABVOgIAA6xqAgACMuAA=
Date: Thu, 21 Mar 2024 16:05:37 +0000
Message-ID: <1f5eba1a-7dc3-41f2-8986-26452c264770@actia.se>
References: <20240131114952.305805-1-john.ernberg@actia.se>
 <20240131114952.305805-2-john.ernberg@actia.se>
 
 <494d4961-ad8a-4d1d-aaa6-d1bfb9d6a137@actia.se>
 <167f0c7a-e037-446c-82f8-2584e35a7af1@xen.org>
 
 <012b5f83-2f9b-4477-965e-07b8506c0052@xen.org>
 
 <5a0c8f09-4f01-45e9-892c-86342c0d0ec5@xen.org>
 <08ae764c-3490-4dd1-ab70-7a855a98d16d@actia.se>
 <911ec1bb-3733-4f37-839e-673a88e408ff@actia.se>
 
 <848794f3-a337-49d9-84db-a969970f071b@actia.se>
 <48038c7f-d7cd-4100-a41b-8042bcb93208@xen.org>
 <967020E7-3D03-416A-8BFC-6F4E4BD9D7B5@arm.com>
 
 <849f3f5a-b960-444a-a10e-1f2df36c22a7@xen.org>
 <2F07325F-428F-4570-BE14-B84DD0A1C9F7@arm.com>
In-Reply-To: <2F07325F-428F-4570-BE14-B84DD0A1C9F7@arm.com>
Accept-Language: en-US, sv-SE
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.12.12.30]
x-esetresult: clean, is OK
x-esetid: 37303A2958D729556C7564
Content-Type: text/plain; charset="utf-8"
Content-ID: <5E1D41425BFFE644BA2671FC5FD0606B@actia.se>
Content-Transfer-Encoding: base64
MIME-Version: 1.0

SGkgQmVydHJhbmQsDQoNCk9uIDMvMjEvMjQgMDg6NDEsIEJlcnRyYW5kIE1hcnF1aXMgd3JvdGU6
DQo+IEhpLA0KPiANCj4+IE9uIDIwIE1hciAyMDI0LCBhdCAxODo0MCwgSnVsaWVuIEdyYWxsIDxq
dWxpZW5AeGVuLm9yZz4gd3JvdGU6DQo+Pg0KPj4gSGkgSm9obiwNCj4+DQo+PiBPbiAyMC8wMy8y
MDI0IDE2OjI0LCBKb2huIEVybmJlcmcgd3JvdGU6DQo+Pj4gSGkgQmVydHJhbmQsDQo+Pj4gT24g
My8xMy8yNCAxMTowNywgQmVydHJhbmQgTWFycXVpcyB3cm90ZToNCj4+Pj4gSGksDQo+Pj4+DQo+
Pj4+PiBPbiA4IE1hciAyMDI0LCBhdCAxNTowNCwgSnVsaWVuIEdyYWxsIDxqdWxpZW5AeGVuLm9y
Zz4gd3JvdGU6DQo+Pj4+Pg0KPj4+Pj4gSGkgSm9obiwNCj4+Pj4+DQo+Pj4+PiBUaGFuayB5b3Ug
Zm9yIHRoZSByZXBseS4NCj4+Pj4+DQo+Pj4+PiBPbiAwOC8wMy8yMDI0IDEzOjQwLCBKb2huIEVy
bmJlcmcgd3JvdGU6DQo+Pj4+Pj4gT24gMy83LzI0IDAwOjA3LCBKdWxpZW4gR3JhbGwgd3JvdGU6
DQo+Pj4+Pj4+ICAgID4gUGluZyBvbiB0aGUgd2F0Y2hkb2cgZGlzY3Vzc2lvbiBiaXRzLg0KPj4+
Pj4+Pg0KPj4+Pj4+PiBTb3JyeSBmb3IgdGhlIGxhdGUgcmVwbHkuDQo+Pj4+Pj4+DQo+Pj4+Pj4+
IE9uIDA2LzAzLzIwMjQgMTM6MTMsIEpvaG4gRXJuYmVyZyB3cm90ZToNCj4+Pj4+Pj4+IE9uIDIv
OS8yNCAxNDoxNCwgSm9obiBFcm5iZXJnIHdyb3RlOg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ICAg
ICAgICogSU1YX1NJUF9USU1FUl8qOiAgVGhpcyBzZWVtcyB0byBiZSByZWxhdGVkIHRvIHRoZSB3
YXRjaGRvZy4NCj4+Pj4+Pj4+Pj4gU2hvdWxkbid0IGRvbTAgcmVseSBvbiB0aGUgd2F0Y2hkb2cg
cHJvdmlkZWQgYnkgWGVuIGluc3RlYWQ/IFNvIHRob3NlDQo+Pj4+Pj4+Pj4+IGNhbGwgd2lsbCBi
ZSB1c2VkIGJ5IFhlbi4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IFRoYXQgaXMgaW5kZWVkIGEgd2F0
Y2hkb2cgU0lQLCBhbmQgYWxzbyBmb3Igc2V0dGluZyB0aGUgU29DIGludGVybmFsIFJUQw0KPj4+
Pj4+Pj4+IGlmIGl0IGlzIGJlaW5nIHVzZWQuDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBJIGxvb2tl
ZCBhcm91bmQgaWYgdGhlcmUgd2FzIHByZXZpb3VzIGRpc2N1c3Npb24gYW5kIG9ubHkgcmVhbGx5
DQo+Pj4+Pj4+Pj4gZm91bmQgWzNdLg0KPj4+Pj4+Pj4+IElzIHRoZSB4ZW4veGVuL2luY2x1ZGUv
d2F0Y2hkb2cuaCBoZWFkZXIgbWVhbnQgdG8gYmUgZm9yIHRoaXMga2luZCBvZg0KPj4+Pj4+Pj4+
IHdhdGNoZG9nIHN1cHBvcnQgb3IgaXMgdGhhdCBtb3JlIGZvciB0aGUgVk0gd2F0Y2hkb2c/IExv
b2tpbmcgYXQgdGhlIHg4Ng0KPj4+Pj4+Pj4+IEFDUEkgTk1JIHdhdGNoZG9nIGl0IHNlZW1zIGxp
a2UgdGhlIGZvcm1lciwgYnV0IEkgaGF2ZSBuZXZlciB3b3JrZWQgd2l0aA0KPj4+Pj4+Pj4+IHg4
NiBub3IgQUNQSS4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gaW5jbHVkZS93YXRjaGRvZy5oIGNvbnRhaW5z
IGhlbHBlciB0byBjb25maWd1cmUgdGhlIHdhdGNoZG9nIGZvciBYZW4uIFdlDQo+Pj4+Pj4+IGFs
c28gaGF2ZSBwZXItVk0gd2F0Y2hkb2cgYW5kIHRoaXMgaXMgY29uZmlndXJlZCBieSB0aGUgaHlw
ZXJjYWxsDQo+Pj4+Pj4+IFNDSEVET1Bfd2F0Y2hkb2cuDQo+Pj4+Pj4+DQo+Pj4+Pj4+Pj4NCj4+
Pj4+Pj4+PiBDdXJyZW50bHkgZm9yd2FyZGluZyBpdCB0byBEb20wIGhhcyBub3QgY2F1c2VkIGFu
eSB3YXRjaGRvZyByZXNldHMgd2l0aA0KPj4+Pj4+Pj4+IG91ciB3YXRjaGRvZyB0aW1lb3V0IHNl
dHRpbmdzLCBvdXIgc3BlY2lmaWMgRG9tMCBzZXR1cCBhbmQgVk0gY291bnQuDQo+Pj4+Pj4+DQo+
Pj4+Pj4+IElJVUMsIHRoZSBTTUMgQVBJIGZvciB0aGUgd2F0Y2hkb2cgd291bGQgYmUgc2ltaWxh
ciB0byB0aGUgQUNQSSBOTUkNCj4+Pj4+Pj4gd2F0Y2hkb2cuIFNvIEkgdGhpbmsgaXQgd291bGQg
bWFrZSBtb3JlIHNlbnNlIGlmIHRoaXMgaXMgbm90IGV4cG9zZWQgdG8NCj4+Pj4+Pj4gZG9tMCAo
ZXZlbiBpZiBYZW4gaXMgZG9pbmcgbm90aGluZyB3aXRoIGl0KS4NCj4+Pj4+Pj4NCj4+Pj4+Pj4g
Q2FuIHlvdSB0cnkgdG8gaGlkZSB0aGUgU01DcyBhbmQgY2hlY2sgaWYgZG9tMCBzdGlsbCBiZWhh
dmUgcHJvcGVybHk/DQo+Pj4+Pj4+DQo+Pj4+Pj4+IENoZWVycywNCj4+Pj4+Pj4NCj4+Pj4+PiBU
aGlzIFNNQyBtYW5hZ2VzIGEgaGFyZHdhcmUgd2F0Y2hkb2csIGlmIGl0J3Mgbm90IHBpbmdlZCB3
aXRoaW4gYQ0KPj4+Pj4+IHNwZWNpZmljIGludGVydmFsIHRoZSBlbnRpcmUgYm9hcmQgcmVzZXRz
Lg0KPj4+Pj4NCj4+Pj4+IERvIHlvdSBrbm93IHdoYXQncyB0aGUgZGVmYXVsdCBpbnRlcnZhbD8g
SXMgaXQgbGFyZ2UgZW5vdWdoIHNvIFhlbiArIGRvbTAgY2FuIGJvb3QgKGF0IGxlYXN0IHVwIHRv
IHdoZW4gdGhlIHdhdGNoZG9nIGRyaXZlciBpcyBpbml0aWFsaXplZCk/DQo+Pj4+Pg0KPj4+Pj4+
IElmIEkgYmxvY2sgdGhlIFNNQ3MgdGhlIHdhdGNoZG9nIGRyaXZlciBpbiBEb20wIHdpbGwgZmFp
bCB0byBwaW5nIHRoZQ0KPj4+Pj4+IHdhdGNoZG9nLCB0cmlnZ2VyaW5nIGEgYm9hcmQgcmVzZXQg
YmVjYXVzZSB0aGUgc3lzdGVtIGxvb2tzIHRvIGhhdmUNCj4+Pj4+PiBiZWNvbWUgdW5yZXNwb25z
aXZlLiBUaGUgcmVhc29uIHRoaXMgcGF0Y2ggc2V0IHN0YXJ0ZWQgaXMgYmVjYXVzZSB3ZQ0KPj4+
Pj4+IGNvdWxkbid0IHBpbmcgdGhlIHdhdGNoZG9nIHdoZW4gcnVubmluZyB3aXRoIFhlbi4NCj4+
Pj4+PiBJbiBvdXIgc3BlY2lmaWMgc3lzdGVtIHRoZSBib290bG9hZGVyIGVuYWJsZXMgdGhlIHdh
dGNoZG9nIGFzIGVhcmx5IGFzDQo+Pj4+Pj4gcG9zc2libGUgc28gdGhhdCB3ZSBjYW4gZ2V0IHdh
dGNoZG9nIHByb3RlY3Rpb24gZm9yIGFzIG11Y2ggb2YgdGhlIGJvb3QNCj4+Pj4+PiBhcyB3ZSBw
b3NzaWJseSBjYW4uDQo+Pj4+Pj4gU28sIGlmIHdlIGFyZSB0byBibG9jayB0aGUgU01DIGZyb20g
RG9tMCwgdGhlbiBYZW4gbmVlZHMgdG8gdGFrZSBvdmVyDQo+Pj4+Pj4gdGhlIHBpbmdpbmcuIEl0
IGNvdWxkIGJlIGltcGxlbWVudGVkIHNpbWlsYXJseSB0byB0aGUgTk1JIHdhdGNoZG9nLA0KPj4+
Pj4+IGV4Y2VwdCB0aGF0IHRoZSBzeXN0ZW0gd2lsbCByZXNldCBpZiB0aGUgcGluZyBpcyBtaXNz
ZWQgcmF0aGVyIHRoYW4NCj4+Pj4+PiBiYWNrdHJhY2UuDQo+Pj4+Pj4gSXQgd291bGQgYWxzbyBt
ZWFuIHRoYXQgWGVuIHdpbGwgZ2V0IGEgd2hvbGUgd2F0Y2hkb2cgZHJpdmVyLWNhdGVnb3J5DQo+
Pj4+Pj4gZHVlIHRvIHRoZSB3YXRjaGRvZyBiZWluZyB2ZW5kb3IgYW5kIHNvbWV0aW1lcyBldmVu
IFNvQyBzcGVjaWZpYyB3aGVuIGl0DQo+Pj4+Pj4gY29tZXMgdG8gQXJtLg0KPj4+Pj4+IE15IHVu
ZGVyc3RhbmRpbmcgb2YgdGhlIGRvbWFpbiB3YXRjaGRvZyBjb2RlIGlzIHRoYXQgdG9kYXkgdGhl
IGRvbWFpbg0KPj4+Pj4+IG5lZWRzIHRvIGNhbGwgU0NIRURPUF93YXRjaGRvZyBhdCBsZWFzdCBv
bmNlIHRvIHN0YXJ0IHRoZSB3YXRjaGRvZw0KPj4+Pj4+IHRpbWVyLiBTaW5jZSB3YXRjaGRvZyBw
cm90ZWN0aW9uIHRocm91Z2ggdGhlIHdob2xlIGJvb3QgcHJvY2VzcyBpcw0KPj4+Pj4+IGRlc2ly
YWJsZSB3ZSdkIG5lZWQgc29tZSBjb3JlIGNoYW5nZXMsIHN1Y2ggYXMgYW4gb3B0aW9uIHRvIHN0
YXJ0IHRoZQ0KPj4+Pj4+IGRvbWFpbiB3YXRjaGRvZyBvbiBpbml0LiA+DQo+Pj4+Pj4gSXQncyBx
dWl0ZSBhIGJpZyBjaGFuZ2UgdG8gbWFrZQ0KPj4+Pj4NCj4+Pj4+IEZvciBjbGFyaWZpY2F0aW9u
LCBhYm92ZSB5b3Ugc2VlbSB0byBtZW50aW9uIHR3byBjaGFuZ2VzOg0KPj4+Pj4NCj4+Pj4+IDEp
IEFsbG93IFhlbiB0byB1c2UgdGhlIEhXIHdhdGNoZG9nDQo+Pj4+PiAyKSBBbGxvdyB0aGUgZG9t
YWluIHRvIHVzZSB0aGUgd2F0Y2hkb2cgZWFybHkNCj4+Pj4+DQo+Pj4+PiBJIGFtIGFzc3VtaW5n
IGJ5IGJpZyBjaGFuZ2UsIHlvdSBhcmUgcmVmZXJyaW5nIHRvIDI/DQo+Pj4+Pg0KPj4+Pj4gLCB3
aGlsZSBJIGFtIG5vdCBhZ2FpbnN0IGRvaW5nIGl0IGlmIGl0DQo+Pj4+Pj4gbWFrZXMgc2Vuc2Us
IEkgbm93IHdvbmRlciBpZiBYZW4gc2hvdWxkIG1hbmFnZSBoYXJkd2FyZSB3YXRjaGRvZ3MuDQo+
Pj4+Pj4gTG9va2luZyBhdCB0aGUgZG9tYWluIHdhdGNoZG9nIGNvZGUgaXQgbG9va3MgbGlrZSBp
ZiBhIGRvbWFpbiBkb2VzIG5vdA0KPj4+Pj4+IGdldCBlbm91Z2ggZXhlY3V0aW9uIHRpbWUsIHRo
ZSB3YXRjaGRvZyB3aWxsIG5vdCBiZSBwaW5nZWQgZW5vdWdoIGFuZA0KPj4+Pj4+IHRoZSBndWVz
dCB3aWxsIGJlIHJlc2V0LiBTbyBlaXRoZXIgd2F0Y2hkb2cgYXBwcm9hY2ggcmVxdWlyZXMgRG9t
MCB0bw0KPj4+Pj4+IGdldCBleGVjdXRpb24gdGltZS4gRG9tMCBhbHNvIG5lZWRzIHRvIHNlcnZp
Y2UgYWxsIHRoZSBQViBiYWNrZW5kcyBpdCdzDQo+Pj4+Pj4gcmVzcG9uc2libGUgZm9yLiBJJ20g
bm90IHN1cmUgaXQncyB2YWx1YWJsZSB0byBhZGQgYW5vdGhlciBsYXllciBvZg0KPj4+Pj4+IHdh
dGNoZG9nIGZvciB0aGlzIHNjZW5hcmlvIGFzIHRoZSBlbmQgcmVzdWx0IChjaGVja2luZyB0aGF0
IHRoZSBlbnRpcmUNCj4+Pj4+PiBzeXN0ZW0gd29ya3MpIGlzIGFjaGlldmVkIHdpdGhvdXQgaXQg
YXMgd2VsbC4NCj4+Pj4+PiBTbywgYmVmb3JlIEkgdHJ5IHRvIGZpbmQgdGhlIHRpbWUgdG8gbWFr
ZSBhIHByb3Bvc2FsIGZvciBtb3ZpbmcgdGhlDQo+Pj4+Pj4gaGFyZHdhcmUgd2F0Y2hkb2cgYml0
IHRvIFhlbiwgZG8gd2UgcmVhbGx5IHdhbnQgaXQ/DQo+Pj4+Pg0KPj4+Pj4gVGhhbmtzIGZvciB0
aGUgZGV0YWlscy4gR2l2ZW4gdGhhdCB0aGUgd2F0Y2hkb2cgaXMgZW5hYmxlZCBieSB0aGUgYm9v
dGxvYWRlciwgSSB0aGluayB3ZSB3YW50IFhlbiB0byBkcml2ZSB0aGUgd2F0Y2hkb2cgZm9yIHR3
byByZWFzb25zOg0KPj4+Pj4gMSkgSW4gdHJ1ZSBkb20wbGVzcyBlbnZpcm9ubWVudCwgZG9tMCB3
b3VsZCBub3QgZXhpc3QNCj4+Pj4+IDIpIFlvdSBhcmUgcmVseWluZyBvbiBYZW4gKyBEb20wIHRv
IGJvb3QgKG9yIGF0IGxlYXN0IGVub3VnaCB0byBnZXQgdGhlIHdhdGNoZG9nIHdvcmtpbmcpIHdp
dGhpbiB0aGUgd2F0Y2hkb2cgaW50ZXJ2YWwuDQo+Pj4+DQo+Pj4+IERlZmluaXRlbHkgd2UgbmVl
ZCB0byBjb25zaWRlciB0aGUgY2FzZSB3aGVyZSB0aGVyZSBpcyBubyBEb20wLg0KPj4+Pg0KPj4+
PiBJIHRoaW5rIHRoZXJlIGFyZSBpbiBmYWN0IDMgZGlmZmVyZW50IHVzZSBjYXNlcyBoZXJlOg0K
Pj4+PiAtIHdhdGNoZG9nIGZ1bGx5IGRyaXZlbiBpbiBhIGRvbWFpbiAoZG9tMCBvciBhbm90aGVy
KTogd291bGQgd29yayBpZiBpdCBpcyBleHBlY3RlZA0KPj4+PiAgICAgdGhhdCBYZW4gKyBEb21h
aW4gYm9vdCB0aW1lIGlzIHVuZGVyIHRoZSB3YXRjaGRvZyBpbml0aWFsIHJlZnJlc2ggcmF0ZS4g
SSB0aGluayB0aGlzDQo+Pj4+ICAgICBjb3VsZCBtYWtlIHNlbnNlIG9uIHNvbWUgYXBwbGljYXRp
b25zIHdoZXJlIHlvdXIgc3lzdGVtIGRlcGVuZHMgb24gYSBzcGVjaWZpYw0KPj4+PiAgICAgZG9t
YWluIHRvIGJlIHByb3Blcmx5IGJvb3RlZCB0byB3b3JrLiBUaGlzIHdvdWxkIHJlcXVpcmUgYW4g
aW5pdGlhbCByZWZyZXNoIHRpbWUNCj4+Pj4gICAgIGNvbmZpZ3VyYWJsZSBpbiB0aGUgYm9vdCBs
b2FkZXIgcHJvYmFibHkuDQo+Pj4gVGhpcyBpcyBvdXIgdXNlLWNhc2UuIF4NCj4+PiBPdXIgZG9t
MCBpcyBtb25pdG9yaW5nIGFuZCBtYW5hZ2luZyB0aGUgb3RoZXIgZG9tYWlucyBpbiBvdXIgc3lz
dGVtLg0KPj4+IFdpdGhvdXQgZG9tMCB3b3JraW5nIHRoZSBzeXN0ZW0gaXNuJ3QgcmVhbGx5IHdv
cmtpbmcgYXMgYSB3aG9sZS4NCj4+PiBASnVsaWVuOiBXb3VsZCB5b3UgYmUgb2sgd2l0aCB0aGUg
cGF0Y2ggc2V0IGNvbnRpbnVpbmcgaW4gdGhlIGRpcmVjdGlvbg0KPj4+IG9mIHRoZQ0KPj4+IG9y
aWdpbmFsIHByb3Bvc2FsLCBsZXR0aW5nIGFub3RoZXIgcGFydHkgKG9yIG1lIGF0IGEgbGF0ZXIg
dGltZSkgaW1wbGVtZW50DQo+Pj4gdGhlIGZ1bGx5IGRyaXZlbiBieSBYZW4gb3B0aW9uPw0KPj4g
SSBhbSBjb25jZXJuZWQgYWJvdXQgdGhpcyBwYXJ0aWN1bGFyIHBvaW50IGZyb20gQmVydHJhbmQ6
DQo+Pg0KPj4gIndvdWxkIHdvcmsgaWYgaXQgaXMgZXhwZWN0ZWQgdGhhdCBYZW4gKyBEb21haW4g
Ym9vdCB0aW1lIGlzIHVuZGVyIHRoZSB3YXRjaGRvZyBpbml0aWFsIHJlZnJlc2ggcmF0ZS4iDQo+
Pg0KPj4gSG93IHdpbGwgYSB1c2VyIGJlIGFibGUgdG8gZmlndXJlIG91dCBob3cgdG8gaW5pdGlh
bGx5IGNvbmZpZ3VyZSB0aGUgd2F0Y2hkb2c/IElzIHRoaXMgc29tZXRoaW5nIHlvdSBjYW4gZWFz
aWx5IGNvbmZpZ3VyZSBpbiB0aGUgYm9vdGxvYWRlciBhdCBydW50aW1lPw0KDQpJZiB5b3UgZ28g
dGhyb3VnaCB0aGUgdHJvdWJsZSBvZiBlbmFibGluZyB0aGUgd2F0Y2hkb2cgaW4gdGhlIGJvb3Rs
b2FkZXIgeW91DQp1c3VhbGx5IGtub3cgd2hhdCB5b3UncmUgZG9pbmcgYW5kIHNldCB0aGUgdGlt
ZW91dCB5b3Vyc2VsZi4NCg0KU2luY2Ugb3VyIHN5c3RlbXMgY2FuIGJlIG1vdW50ZWQgaW4gcmVh
bGx5IGFubm95aW5nIGxvY2F0aW9ucyAoYm90aCBpbg0KaW5zdGFsbGF0aW9ucyBhbmQgd29ybGQt
d2lzZSkgd2UgbmVlZCBhcyBtdWNoIGF1dG8tcmVjb3ZlcnkgYXMgcG9zc2libGUgdG8NCmF2b2lk
IHBlb3BsZSBoYXZpbmcgdG8gdHJhdmVsIHRvIGNvbGxlY3QgYSB1bml0IHRoYXQganVzdCBuZWVk
ZWQgYSByZXNldCBkdWUNCnRvIHNvbWUgdW5leHBlY3RlZCBvYnNjdXJlIGlzc3VlIGF0IHN0YXJ0
dXAuDQo+IA0KPiBEZWZpbml0ZWx5IGhlcmUgaXQgd291bGQgYmUgYmV0dGVyIHRvIGhhdmUgdGhl
IHdhdGNoZG9nIHR1cm5lZCBvZmYgYnkgZGVmYXVsdCBhbmQgZG9jdW1lbnQgaG93IHRvIGVuYWJs
ZSBpdCBpbiB0aGUgZmlybXdhcmUuDQo+IA0KPiBFdmVuIGlmIGEgbG9uZyB0aW1lb3V0IGlzIGNv
bmZpZ3VyZWQgYnkgZGVmYXVsdCwgYSB1c2VyIGNvdWxkIHJ1biBpbnRvIHRyb3VibGUgaWYgdXNp
bmcgYSBsaW51eCB3aXRob3V0IHdhdGNoZG9nIG9yIG5vdCBydW5uaW5nIGxpbnV4IG9yIHVzaW5n
IGRvbTBsZXNzIHdpdGhvdXQgYSBsaW51eCBoYXZpbmcgYWNjZXNzIHRvIGl0Lg0KPiBJIGFncmVl
IHdpdGggSnVsaWVuIGhlcmUgdGhhdCB0aGUgY29uY2VybiBjb3VsZCBiZSB0aGF0IHVzZXJzIHdv
dWxkIGNvbWUgdG8gdXMgaW5zdGVhZCBvZiBOWFAgaWYgdGhlcmUgaXMgc3lzdGVtIGlzIGRvaW5n
IGEgcmVzZXQgd2l0aG91dCByZWFzb25zIGFmdGVyIHNvbWUgc2Vjb25kcyBvciBtaW51dGVzLg0K
DQpJIGNvdWxkIGFkZCBteXNlbGYgYXMgYSByZXZpZXdlciBmb3IgdGhlIGlNWCBwYXJ0cyBpZiB0
aGF0IGhlbHBzIHJvdXRpbmcgDQpzdWNoDQpxdWVzdGlvbnMgKGFuZCBmdXR1cmUgcGF0Y2hlcykg
YWxzbyB0byBtZS4gV2UgaGF2ZSBleHBlcmllbmNlIHdpdGggdGhlIFFYUCwNCmFuZCB0aGUgUU0g
KGZvciB0aGUgc3VwcG9ydGVkIHBhcnRzIGJ5IHRoaXMgcGF0Y2ggc2V0KSBpcyBpZGVudGljYWwu
DQoNCldvdWxkIHRoYXQgaGVscCB3aXRoIHRoZSBjb25jZXJucz8NCg0KPiANCj4+DQo+Pg0KPj4g
T3ZlcmFsbCwgSSBhbSBub3QgZm9yIHRoaXMgYXBwcm9hY2ggYXQgbGVhc3QgaW4gdGhlIGN1cnJl
bnQgc3RhdHVzLiBJIHdvdWxkIGJlIG1vcmUgaW5jbGluZWQgaWYgdGhlcmUgYXJlIHNvbWUgZG9j
dW1lbnRhdGlvbnMgZXhwbGFpbmluZyBob3cgdGhpcyBpcyBzdXBwb3NlZCB0byBiZSBjb25maWd1
cmVkIG9uIE5YUCwgc28gb3RoZXJzIGNhbiB1c2UgdGhlIGNvZGUuDQo+Pg0KPj4gQW55d2F5LCB0
aGlzIGlzIHdoeSB3ZSBoYXZlIG11bHRpcGxlIEFybSBtYWludGFpbmVycyBmb3IgdGhpcyBraW5k
IG9mIHNpdHVhdGlvbi4gSWYgdGhleSBvdGhlciBhZ3JlZXMgd2l0aCB5b3UsIHRoZW4gdGhleSBj
YW4gYWNrIHRoZSBwYXRjaCBhbmQgdGhpcyBjYW4gYmUgbWVyZ2VkLg0KPiANCj4gSSBhZ3JlZSB3
aXRoIFN0ZWZhbm8gdGhhdCBpdCB3b3VsZCBiZSBnb29kIHRvIGhhdmUgdGhvc2UgYm9hcmQgc3Vw
cG9ydGVkLg0KPiANCj4gT25lIHRoaW5nIGkgY291bGQgc3VnZ2VzdCB1bnRpbCB0aGVyZSBpcyBh
IHdhdGNoZG9nIGRyaXZlciBpbnNpZGUgWGVuIGlzIHRvIGhhdmUgYSBjbGVhciBXYXJuaW5nIGF0
IFhlbiBib290IG9uIHRob3NlIGJvYXJkcyBpbiB0aGUgY29uc29sZSBzbyB0aGF0IHdlIGNvdWxk
IGF0IGxlYXN0IGlkZW50aWZ5IHRoZSByZWFzb24gZWFzaWx5IGlmIGEgcmVzZXQgb2NjdXJzIGZv
ciBzb21lb25lLg0KDQpIb3cgZG8gb3RoZXIgU29DcyBkZWFsIHdpdGggdGhpcyBjdXJyZW50bHk/
IFRoZSBpTVggU29DcyBhcmVuJ3QgdGhlIG9ubHkgDQpvbmVzDQp3aXRoIGEgd2F0Y2hkb2csIGp1
c3QgdGhlIGZpcnN0IG9uZSBhZGRlZCB0byBYZW4gdGhhdCBwaW5ncyB0aGUgd2F0Y2hkb2cgDQpv
dmVyDQphbiBTTUMuIFdoYXQgYWJvdXQgdGhlIE9NQVBzLCB0aGUgUi1DYXJzLCBYaWxpbngncywg
RXh5bm9zJyBhbmQgc28gb24/DQoNClRoYW5rcyEgLy8gSm9obiBFcm5iZXJn


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 16:07:24 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 16:07:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696475.1087460 (Exim 4.92)
	(envelope-from )
	id 1rnKws-00028D-Q8; Thu, 21 Mar 2024 16:07:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696475.1087460; Thu, 21 Mar 2024 16:07:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnKws-000286-N9; Thu, 21 Mar 2024 16:07:22 +0000
Received: by outflank-mailman (input) for mailman id 696475;
 Thu, 21 Mar 2024 16:07:21 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1rnKwr-00027t-NY
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 16:07:21 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnKwq-0005Aq-6j; Thu, 21 Mar 2024 16:07:20 +0000
Received: from gw1.octic.net ([88.97.20.152] helo=[10.0.1.240])
 by xenbits.xenproject.org with esmtpsa
 (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92)
 (envelope-from )
 id 1rnKwp-0006wk-Qq; Thu, 21 Mar 2024 16:07:19 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=F/PkWrzwrSixS7uLLJlAD0k4KULXola2wB/zeBUqPGs=; b=npHBUCPKxesxWqCj77HXmQz1ov
	/bFPwNVkuVV/Q/q9Z8DWDsMYkLm2n1f6cRFpOqgxYwXlqtSW6g61oV7OACkj1AcQTaER6VITbTQGB
	wMEjNSPM0Cdp4FLQBhNOelEdSaH1B+SJ7lJL3x6DfOZuCmSGIjmfCosgy3/eKYBaAckc=;
Message-ID: <3f615066-a792-493f-ba33-7667a6557c23@xen.org>
Date: Thu, 21 Mar 2024 16:07:17 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 08/14] xen/page_alloc: introduce preserved page flags
 macro
Content-Language: en-GB
To: Carlo Nonato ,
 xen-devel@lists.xenproject.org
Cc: Andrew Cooper ,
 George Dunlap , Jan Beulich ,
 Stefano Stabellini , Wei Liu ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
 <20240315105902.160047-9-carlo.nonato@minervasys.tech>
From: Julien Grall 
In-Reply-To: <20240315105902.160047-9-carlo.nonato@minervasys.tech>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

(+ Roger)

Hi Carlo,

On 15/03/2024 10:58, Carlo Nonato wrote:
> PGC_static and PGC_extra needs to be preserved when assigning a page.
> Define a new macro that groups those flags and use it instead of or'ing
> every time.
> 
> To make preserved flags even more meaningful, they are kept also when
> switching state in mark_page_free().
> 
> Signed-off-by: Carlo Nonato 

This patch is introducing a regression in OSStest (and possibly gitlab?):

Mar 21 12:00:29.533676 (XEN) pg[0] MFN 2211c5 c=0x2c00000000000000 o=0 
v=0xe40000010007ffff t=0x24
Mar 21 12:00:42.829785 (XEN) Xen BUG at common/page_alloc.c:1033
Mar 21 12:00:42.829829 (XEN) ----[ Xen-4.19-unstable  x86_64  debug=y 
Not tainted ]----
Mar 21 12:00:42.829857 (XEN) CPU:    12
Mar 21 12:00:42.841571 (XEN) RIP:    e008:[] 
common/page_alloc.c#alloc_heap_pages+0x37f/0x6e2
Mar 21 12:00:42.841609 (XEN) RFLAGS: 0000000000010282   CONTEXT: 
hypervisor (d0v8)
Mar 21 12:00:42.853654 (XEN) rax: ffff83023e3ed06c   rbx: 
000000000007ffff   rcx: 0000000000000028
Mar 21 12:00:42.853689 (XEN) rdx: ffff83047bec7fff   rsi: 
ffff83023e3ea3e8   rdi: ffff83023e3ea3e0
Mar 21 12:00:42.865657 (XEN) rbp: ffff83047bec7c10   rsp: 
ffff83047bec7b98   r8:  0000000000000000
Mar 21 12:00:42.877647 (XEN) r9:  0000000000000001   r10: 
000000000000000c   r11: 0000000000000010
Mar 21 12:00:42.877682 (XEN) r12: 0000000000000001   r13: 
0000000000000000   r14: ffff82e0044238a0
Mar 21 12:00:42.889652 (XEN) r15: 0000000000000000   cr0: 
0000000080050033   cr4: 0000000000372660
Mar 21 12:00:42.901651 (XEN) cr3: 000000046fe34000   cr2: 00007fb72757610b
Mar 21 12:00:42.901685 (XEN) fsb: 00007fb726def380   gsb: 
ffff88801f200000   gss: 0000000000000000
Mar 21 12:00:42.913646 (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000 
ss: e010   cs: e008
Mar 21 12:00:42.913680 (XEN) Xen code around  
(common/page_alloc.c#alloc_heap_pages+0x37f/0x6e2):
Mar 21 12:00:42.925645 (XEN)  d1 1c 00 e8 ad dd 02 00 <0f> 0b 48 85 c9 
79 36 0f 0b 41 89 cd 48 c7 47 f0
Mar 21 12:00:42.937649 (XEN) Xen stack trace from rsp=ffff83047bec7b98:
Mar 21 12:00:42.937683 (XEN)    0000000000000024 000000007bec7c20 
0000000000000001 ffff83046ccda000
Mar 21 12:00:42.949653 (XEN)    ffff82e000000021 0000000000000016 
0000000000000000 0000000000000000
Mar 21 12:00:42.949687 (XEN)    0000000000000000 0000000000000000 
0000000000000028 0000000000000021
Mar 21 12:00:42.961652 (XEN)    ffff83046ccda000 0000000000000000 
00007d2000000000 ffff83047bec7c48
Mar 21 12:00:42.961687 (XEN)    ffff82d0402302ff ffff83046ccda000 
0000000000000100 0000000000000000
Mar 21 12:00:42.973655 (XEN)    ffff82d0405f0080 00007d2000000000 
ffff83047bec7c80 ffff82d0402f626c
Mar 21 12:00:42.985656 (XEN)    ffff83046ccda000 ffff83046ccda640 
0000000000000000 0000000000000000
Mar 21 12:00:42.985690 (XEN)    ffff83046ccda220 ffff83047bec7cb0 
ffff82d0402f65a0 ffff83046ccda000
Mar 21 12:00:42.997662 (XEN)    0000000000000000 0000000000000000 
0000000000000000 ffff83047bec7cc0
Mar 21 12:00:43.009660 (XEN)    ffff82d040311f8a ffff83047bec7ce0 
ffff82d0402bd543 ffff83046ccda000
Mar 21 12:00:43.009695 (XEN)    ffff83047bec7dc8 ffff83047bec7d08 
ffff82d04032c524 ffff83046ccda000
Mar 21 12:00:43.021653 (XEN)    ffff83047bec7dc8 0000000000000002 
ffff83047bec7d58 ffff82d040206750
Mar 21 12:00:43.033642 (XEN)    0000000000000000 ffff82d040233fe5 
ffff83047bec7d48 0000000000000000
Mar 21 12:00:43.033678 (XEN)    0000000000000002 00007fb72767f010 
ffff82d0405e9120 0000000000000001
Mar 21 12:00:43.045654 (XEN)    ffff83047bec7e70 ffff82d040240728 
0000000000000007 ffff83023e3b3000
Mar 21 12:00:43.045690 (XEN)    0000000000000246 ffff83023e2efa90 
ffff83023e38e000 ffff83023e2efb40
Mar 21 12:00:43.057609 (XEN)    0000000000000007 ffff83023e3afb80 
0000000000000206 ffff83047bec7dc0
Mar 21 12:00:43.069662 (XEN)    0000001600000001 000000000000ffff 
e75aaa8d0000000c ac0d6d864e487f62
Mar 21 12:00:43.069697 (XEN)    000000037fa48d76 0000000200000000 
ffffffff000003ff 00000002ffffffff
Mar 21 12:00:43.081647 (XEN)    0000000000000000 00000000000001ff 
0000000000000000 0000000000000000
Mar 21 12:00:43.093646 (XEN) Xen call trace:
Mar 21 12:00:43.093677 (XEN)    [] R 
common/page_alloc.c#alloc_heap_pages+0x37f/0x6e2
Mar 21 12:00:43.093705 (XEN)    [] F 
alloc_domheap_pages+0x17d/0x1e4
Mar 21 12:00:43.105652 (XEN)    [] F 
hap_set_allocation+0x73/0x23c
Mar 21 12:00:43.105685 (XEN)    [] F 
hap_enable+0x138/0x33c
Mar 21 12:00:43.117646 (XEN)    [] F 
paging_enable+0x2d/0x45
Mar 21 12:00:43.117679 (XEN)    [] F 
hvm_domain_initialise+0x185/0x428
Mar 21 12:00:43.129652 (XEN)    [] F 
arch_domain_create+0x3e7/0x4c1
Mar 21 12:00:43.129687 (XEN)    [] F 
domain_create+0x4cc/0x7e2
Mar 21 12:00:43.141665 (XEN)    [] F 
do_domctl+0x1850/0x192d
Mar 21 12:00:43.141699 (XEN)    [] F 
pv_hypercall+0x617/0x6b5
Mar 21 12:00:43.153656 (XEN)    [] F 
lstar_enter+0x13a/0x140
Mar 21 12:00:43.153689 (XEN)
Mar 21 12:00:43.153711 (XEN)
Mar 21 12:00:43.153731 (XEN) ****************************************
Mar 21 12:00:43.165647 (XEN) Panic on CPU 12:
Mar 21 12:00:43.165678 (XEN) Xen BUG at common/page_alloc.c:1033
Mar 21 12:00:43.165703 (XEN) ****************************************
Mar 21 12:00:43.177633 (XEN)
Mar 21 12:00:43.177662 (XEN) Manual reset required ('noreboot' specified)

The code around the BUG is:

         /* Reference count must continuously be zero for free pages. */
         if ( (pg[i].count_info & ~PGC_need_scrub) != PGC_state_free )
         {
             printk(XENLOG_ERR
                    "pg[%u] MFN %"PRI_mfn" c=%#lx o=%u v=%#lx t=%#x\n",
                    i, mfn_x(page_to_mfn(pg + i)),
                    pg[i].count_info, pg[i].v.free.order,
                    pg[i].u.free.val, pg[i].tlbflush_timestamp);
             BUG();
         }

Now that you are preserving some flags, you also want to modify the 
condition. I haven't checked the rest of the code, so there might be 
some adjustments necessary.

For now I have reverted the patch to unblock the CI.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 16:10:38 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 16:10:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696483.1087473 (Exim 4.92)
	(envelope-from )
	id 1rnKzy-0004MS-8P; Thu, 21 Mar 2024 16:10:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696483.1087473; Thu, 21 Mar 2024 16:10:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnKzy-0004ML-5P; Thu, 21 Mar 2024 16:10:34 +0000
Received: by outflank-mailman (input) for mailman id 696483;
 Thu, 21 Mar 2024 16:10:33 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1rnKzw-0004Kw-V1
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 16:10:32 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnKzw-0005F0-6d; Thu, 21 Mar 2024 16:10:32 +0000
Received: from gw1.octic.net ([88.97.20.152] helo=[10.0.1.240])
 by xenbits.xenproject.org with esmtpsa
 (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92)
 (envelope-from )
 id 1rnKzw-000776-1f; Thu, 21 Mar 2024 16:10:32 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
	References:Cc:To:From:Subject:MIME-Version:Date:Message-ID;
	bh=BH1SvWNFn+/0pXsiXRGsXt+pBKip9G+iv18Mri06eEo=; b=mUW/sYbnzfVNUKLHrovqpIIUdF
	82jIS6lIPL7u3OXTnd78rmXJ7GHUFMb+y9+WX2WTwFx3xVPBbIeAlBrY9967mQTnm6sMYvVF4Oq/c
	1La0uwxJcWbdZdH/ZpRlosfMGyELRpvP9YZeUkFz0xxxvTw6sFZmYqM9wwX4J9hTg2xc=;
Message-ID: <9e0f7ff3-5457-41e4-a1e4-bf75804fb900@xen.org>
Date: Thu, 21 Mar 2024 16:10:30 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 08/14] xen/page_alloc: introduce preserved page flags
 macro
Content-Language: en-GB
From: Julien Grall 
To: Carlo Nonato ,
 xen-devel@lists.xenproject.org
Cc: Andrew Cooper ,
 George Dunlap , Jan Beulich ,
 Stefano Stabellini , Wei Liu ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
 <20240315105902.160047-9-carlo.nonato@minervasys.tech>
 <3f615066-a792-493f-ba33-7667a6557c23@xen.org>
In-Reply-To: <3f615066-a792-493f-ba33-7667a6557c23@xen.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit



On 21/03/2024 16:07, Julien Grall wrote:
> (+ Roger)
> 
> Hi Carlo,
> 
> On 15/03/2024 10:58, Carlo Nonato wrote:
>> PGC_static and PGC_extra needs to be preserved when assigning a page.
>> Define a new macro that groups those flags and use it instead of or'ing
>> every time.
>>
>> To make preserved flags even more meaningful, they are kept also when
>> switching state in mark_page_free().
>>
>> Signed-off-by: Carlo Nonato 
> 
> This patch is introducing a regression in OSStest (and possibly gitlab?):
> 
> Mar 21 12:00:29.533676 (XEN) pg[0] MFN 2211c5 c=0x2c00000000000000 o=0 
> v=0xe40000010007ffff t=0x24
> Mar 21 12:00:42.829785 (XEN) Xen BUG at common/page_alloc.c:1033
> Mar 21 12:00:42.829829 (XEN) ----[ Xen-4.19-unstable  x86_64  debug=y 
> Not tainted ]----
> Mar 21 12:00:42.829857 (XEN) CPU:    12
> Mar 21 12:00:42.841571 (XEN) RIP:    e008:[] 
> common/page_alloc.c#alloc_heap_pages+0x37f/0x6e2
> Mar 21 12:00:42.841609 (XEN) RFLAGS: 0000000000010282   CONTEXT: 
> hypervisor (d0v8)
> Mar 21 12:00:42.853654 (XEN) rax: ffff83023e3ed06c   rbx: 
> 000000000007ffff   rcx: 0000000000000028
> Mar 21 12:00:42.853689 (XEN) rdx: ffff83047bec7fff   rsi: 
> ffff83023e3ea3e8   rdi: ffff83023e3ea3e0
> Mar 21 12:00:42.865657 (XEN) rbp: ffff83047bec7c10   rsp: 
> ffff83047bec7b98   r8:  0000000000000000
> Mar 21 12:00:42.877647 (XEN) r9:  0000000000000001   r10: 
> 000000000000000c   r11: 0000000000000010
> Mar 21 12:00:42.877682 (XEN) r12: 0000000000000001   r13: 
> 0000000000000000   r14: ffff82e0044238a0
> Mar 21 12:00:42.889652 (XEN) r15: 0000000000000000   cr0: 
> 0000000080050033   cr4: 0000000000372660
> Mar 21 12:00:42.901651 (XEN) cr3: 000000046fe34000   cr2: 00007fb72757610b
> Mar 21 12:00:42.901685 (XEN) fsb: 00007fb726def380   gsb: 
> ffff88801f200000   gss: 0000000000000000
> Mar 21 12:00:42.913646 (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000 
> ss: e010   cs: e008
> Mar 21 12:00:42.913680 (XEN) Xen code around  
> (common/page_alloc.c#alloc_heap_pages+0x37f/0x6e2):
> Mar 21 12:00:42.925645 (XEN)  d1 1c 00 e8 ad dd 02 00 <0f> 0b 48 85 c9 
> 79 36 0f 0b 41 89 cd 48 c7 47 f0
> Mar 21 12:00:42.937649 (XEN) Xen stack trace from rsp=ffff83047bec7b98:
> Mar 21 12:00:42.937683 (XEN)    0000000000000024 000000007bec7c20 
> 0000000000000001 ffff83046ccda000
> Mar 21 12:00:42.949653 (XEN)    ffff82e000000021 0000000000000016 
> 0000000000000000 0000000000000000
> Mar 21 12:00:42.949687 (XEN)    0000000000000000 0000000000000000 
> 0000000000000028 0000000000000021
> Mar 21 12:00:42.961652 (XEN)    ffff83046ccda000 0000000000000000 
> 00007d2000000000 ffff83047bec7c48
> Mar 21 12:00:42.961687 (XEN)    ffff82d0402302ff ffff83046ccda000 
> 0000000000000100 0000000000000000
> Mar 21 12:00:42.973655 (XEN)    ffff82d0405f0080 00007d2000000000 
> ffff83047bec7c80 ffff82d0402f626c
> Mar 21 12:00:42.985656 (XEN)    ffff83046ccda000 ffff83046ccda640 
> 0000000000000000 0000000000000000
> Mar 21 12:00:42.985690 (XEN)    ffff83046ccda220 ffff83047bec7cb0 
> ffff82d0402f65a0 ffff83046ccda000
> Mar 21 12:00:42.997662 (XEN)    0000000000000000 0000000000000000 
> 0000000000000000 ffff83047bec7cc0
> Mar 21 12:00:43.009660 (XEN)    ffff82d040311f8a ffff83047bec7ce0 
> ffff82d0402bd543 ffff83046ccda000
> Mar 21 12:00:43.009695 (XEN)    ffff83047bec7dc8 ffff83047bec7d08 
> ffff82d04032c524 ffff83046ccda000
> Mar 21 12:00:43.021653 (XEN)    ffff83047bec7dc8 0000000000000002 
> ffff83047bec7d58 ffff82d040206750
> Mar 21 12:00:43.033642 (XEN)    0000000000000000 ffff82d040233fe5 
> ffff83047bec7d48 0000000000000000
> Mar 21 12:00:43.033678 (XEN)    0000000000000002 00007fb72767f010 
> ffff82d0405e9120 0000000000000001
> Mar 21 12:00:43.045654 (XEN)    ffff83047bec7e70 ffff82d040240728 
> 0000000000000007 ffff83023e3b3000
> Mar 21 12:00:43.045690 (XEN)    0000000000000246 ffff83023e2efa90 
> ffff83023e38e000 ffff83023e2efb40
> Mar 21 12:00:43.057609 (XEN)    0000000000000007 ffff83023e3afb80 
> 0000000000000206 ffff83047bec7dc0
> Mar 21 12:00:43.069662 (XEN)    0000001600000001 000000000000ffff 
> e75aaa8d0000000c ac0d6d864e487f62
> Mar 21 12:00:43.069697 (XEN)    000000037fa48d76 0000000200000000 
> ffffffff000003ff 00000002ffffffff
> Mar 21 12:00:43.081647 (XEN)    0000000000000000 00000000000001ff 
> 0000000000000000 0000000000000000
> Mar 21 12:00:43.093646 (XEN) Xen call trace:
> Mar 21 12:00:43.093677 (XEN)    [] R 
> common/page_alloc.c#alloc_heap_pages+0x37f/0x6e2
> Mar 21 12:00:43.093705 (XEN)    [] F 
> alloc_domheap_pages+0x17d/0x1e4
> Mar 21 12:00:43.105652 (XEN)    [] F 
> hap_set_allocation+0x73/0x23c
> Mar 21 12:00:43.105685 (XEN)    [] F 
> hap_enable+0x138/0x33c
> Mar 21 12:00:43.117646 (XEN)    [] F 
> paging_enable+0x2d/0x45
> Mar 21 12:00:43.117679 (XEN)    [] F 
> hvm_domain_initialise+0x185/0x428
> Mar 21 12:00:43.129652 (XEN)    [] F 
> arch_domain_create+0x3e7/0x4c1
> Mar 21 12:00:43.129687 (XEN)    [] F 
> domain_create+0x4cc/0x7e2
> Mar 21 12:00:43.141665 (XEN)    [] F 
> do_domctl+0x1850/0x192d
> Mar 21 12:00:43.141699 (XEN)    [] F 
> pv_hypercall+0x617/0x6b5
> Mar 21 12:00:43.153656 (XEN)    [] F 
> lstar_enter+0x13a/0x140
> Mar 21 12:00:43.153689 (XEN)
> Mar 21 12:00:43.153711 (XEN)
> Mar 21 12:00:43.153731 (XEN) ****************************************
> Mar 21 12:00:43.165647 (XEN) Panic on CPU 12:
> Mar 21 12:00:43.165678 (XEN) Xen BUG at common/page_alloc.c:1033
> Mar 21 12:00:43.165703 (XEN) ****************************************
> Mar 21 12:00:43.177633 (XEN)
> Mar 21 12:00:43.177662 (XEN) Manual reset required ('noreboot' specified)
> 
> The code around the BUG is:
> 
>          /* Reference count must continuously be zero for free pages. */
>          if ( (pg[i].count_info & ~PGC_need_scrub) != PGC_state_free )
>          {
>              printk(XENLOG_ERR
>                     "pg[%u] MFN %"PRI_mfn" c=%#lx o=%u v=%#lx t=%#x\n",
>                     i, mfn_x(page_to_mfn(pg + i)),
>                     pg[i].count_info, pg[i].v.free.order,
>                     pg[i].u.free.val, pg[i].tlbflush_timestamp);
>              BUG();
>          }
> 
> Now that you are preserving some flags, you also want to modify the 
> condition. I haven't checked the rest of the code, so there might be 
> some adjustments necessary.

Actually maybe the condition should not be adjusted. I think it would be 
wrong if a free pages has the flag PGC_extra set. Any thoughts?

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 16:15:55 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 16:15:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696489.1087486 (Exim 4.92)
	(envelope-from )
	id 1rnL54-0005Ld-UL; Thu, 21 Mar 2024 16:15:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696489.1087486; Thu, 21 Mar 2024 16:15:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnL54-0005LW-Rh; Thu, 21 Mar 2024 16:15:50 +0000
Received: by outflank-mailman (input) for mailman id 696489;
 Thu, 21 Mar 2024 16:15:49 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rnL53-0005LH-7U
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 16:15:49 +0000
Received: from EUR05-VI1-obe.outbound.protection.outlook.com
 (mail-vi1eur05on20601.outbound.protection.outlook.com
 [2a01:111:f403:2613::601])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 45c00c35-e79e-11ee-a1ee-f123f15fe8a2;
 Thu, 21 Mar 2024 17:15:46 +0100 (CET)
Received: from DU2PR04CA0259.eurprd04.prod.outlook.com (2603:10a6:10:28e::24)
 by AS2PR08MB10055.eurprd08.prod.outlook.com (2603:10a6:20b:645::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.15; Thu, 21 Mar
 2024 16:15:42 +0000
Received: from DB5PEPF00014B88.eurprd02.prod.outlook.com
 (2603:10a6:10:28e:cafe::2e) by DU2PR04CA0259.outlook.office365.com
 (2603:10a6:10:28e::24) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.27 via Frontend
 Transport; Thu, 21 Mar 2024 16:15:42 +0000
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by
 DB5PEPF00014B88.mail.protection.outlook.com (10.167.8.196) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.7409.10 via Frontend Transport; Thu, 21 Mar 2024 16:15:42 +0000
Received: ("Tessian outbound ff4e98f65004:v300");
 Thu, 21 Mar 2024 16:15:42 +0000
Received: from ab85671fa26a.1
 by 64aa7808-outbound-1.mta.getcheckrecipient.com id
 B7A4E214-0E0F-450E-864F-94930694AA1B.1; 
 Thu, 21 Mar 2024 16:15:35 +0000
Received: from EUR04-VI1-obe.outbound.protection.outlook.com
 by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id ab85671fa26a.1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384);
 Thu, 21 Mar 2024 16:15:35 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com (2603:10a6:10:25a::24)
 by PAWPR08MB9996.eurprd08.prod.outlook.com (2603:10a6:102:35a::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.30; Thu, 21 Mar
 2024 16:15:33 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::7fb0:6621:56b:22d5]) by DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::7fb0:6621:56b:22d5%3]) with mapi id 15.20.7386.025; Thu, 21 Mar 2024
 16:15:33 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 45c00c35-e79e-11ee-a1ee-f123f15fe8a2
ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass;
 b=eYwBdgNdt6szFJnEV4pChF3MPDUP2rB9KtZV49kOGbjCQEnPP18i/qBovB1E4EoBJmXIGEo6eBBJ2s9B6zc4JU8HqrZleB/KED9+x4XvOIlbak6whA0w8Gh7D3l4Ff47sLxf2U5j4fHWGW4Lc+pVLWAoLggy7C/n4RxoN34+ZJXc920rZkwOeoWWFAePeCmc30X4Uu4beDcbQbBwjZtyPqc6ITMuTbbVLVLXqvVUCwMFYB5zCPhqcf0bHW4pmYV/p9MexibAFt5UX8yb/dTKD87jen4SolNslLZF8Z/TZcebEWYMKj/TMFU6oS7RPdLItAOLFJR9clyhZYabA+7mqQ==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=69aJvN153GSKxFDX3cPN7v7+CUGmUGaFIwQt6g7ryyo=;
 b=NfbOW9GYJwlMq50GPlJwmGkcR5Nlei53d2nUmUFpHiji9K52g6i7a4EcJByseww34ok3cK+NUnzNFtRFU8sLlqtwUqlMRXSmfGP07Ae6wlcK+PcnPOp5iA35Kt+4c6dzKAYJpMePmQHrGRbue8qzGun4Y5uD3tXDMtCMVqOq8TY+oroCe6XARRRHaNMExJ+bRwKZEd55AuzDRIo/dPVO8S33O1sAy0x4I+MTjzNzr9QkWoEE5c2CvuZrBeW3o0K1zhKTHBwfs2puj7cqLXp0Bu/GMj4XZzJOlqiKWOTe7SV7bJP+BkwEcBnNN7A9e3XUUOoOnjliH1JtVfOw4yARLQ==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 63.35.35.123) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=arm.com;
 dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com;
 dkim=pass (signature was verified) header.d=armh.onmicrosoft.com; arc=pass (0
 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com]
 dmarc=[1,1,header.from=arm.com])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com;
 s=selector2-armh-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=69aJvN153GSKxFDX3cPN7v7+CUGmUGaFIwQt6g7ryyo=;
 b=pBTKXMjquN+ItEOw5KLmbV2Li3E/S1FiFZzneIZbm0fc3I7z9r0L/mHi3SzbnI/CXfSjJyCgPsCNO3ohwc+UiQdnILa4WDR/jtTaoHz1yyIzNFlwvzaI/CSy2A4Qo5m9OgsrzEXsnMQvfL0odq+7bgmx4szEfzGKrwIfhFoscQU=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=armh.onmicrosoft.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 63.35.35.123 as permitted sender) receiver=protection.outlook.com;
 client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
 pr=C
X-CheckRecipientChecked: true
X-CR-MTA-CID: ce255519c07dc19a
X-CR-MTA-TID: 64aa7808
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=nnAELmX9XjTJBWFUzbENONjoQjDewai5H/ViaZ5WceEeptEwti6WD2WKOU+9GcMaFYsRRmaECNziKXcnAKHXyNxjTk7sEQqBb1gfv0/h24m9oyC6omcfSjiKQGqw+yp7jJkIWsJxcnCE3esHv/i3a0gO4dDzLLtq1rXafybl1YxbWJXHIx5DCHXc7GD3Ps6jQjr1UrDTOuwbyjdG/y+SX3crEcjm4HymqpB0UhwGCaQS3gWzJvAuY0ViWY0beHaxtw+mq2LW8CRLNbLJ+EndntM2nsMzZ2Fx2LOMJ4A2/8JAtj0JmVLH9WJor/okXhMDTMdq/n2K3sBxpWKee2RatQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=69aJvN153GSKxFDX3cPN7v7+CUGmUGaFIwQt6g7ryyo=;
 b=IyZkTQuUgzzaUUz7gKy9sYHzhhLQitPyIef1gZYktHf08CDgqEibE8bRVfuPKfxPqswJOm9R8r/vApwme9oWhtOKhPhPbfmHE12lSB/KSG3Pi7QonHZ7iZ5FIqC6Iec7ve0BctgRZUnYRMMCq07nxmY1o8tQDzeRXvthPFAhmIglLk8o7kuX6ZJ3BeqcpXnqpZ2us7gclYuylcJ5vnwL09mfrB1XGkvK8EkLRaukqrBrEzNy4s6TpiglMimaiD3oe/lFih+8K8ysDskLECAKQaOn52LbPIHGi+XrM2jggRYBA4qL2+92Glt1u5g/ykb2BeJtTbmTW7wF0YpozTglUA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass
 header.d=arm.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com;
 s=selector2-armh-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=69aJvN153GSKxFDX3cPN7v7+CUGmUGaFIwQt6g7ryyo=;
 b=pBTKXMjquN+ItEOw5KLmbV2Li3E/S1FiFZzneIZbm0fc3I7z9r0L/mHi3SzbnI/CXfSjJyCgPsCNO3ohwc+UiQdnILa4WDR/jtTaoHz1yyIzNFlwvzaI/CSy2A4Qo5m9OgsrzEXsnMQvfL0odq+7bgmx4szEfzGKrwIfhFoscQU=
From: Bertrand Marquis 
To: John Ernberg 
CC: Julien Grall , Peng Fan , Stefano
 Stabellini , Michal Orzel ,
	Volodymyr Babchuk , Jonas Blixt
	, "xen-devel@lists.xenproject.org"
	
Subject: Re: [PATCH 1/2] xen/arm: Add imx8q{m,x} platform glue
Thread-Topic: [PATCH 1/2] xen/arm: Add imx8q{m,x} platform glue
Thread-Index:
 AQHaVDuqVQ/kgxLZgUK/m8/hE0ez5bDz198AgAA1LICAAVx4AIAAQjaAgAEdtQCAAynKwIABnCuAgAZ8E4CAKNxCgIAApf0AgAKGQwCAAAbHgIAHmWEAgAtpgACAABVOgIAA6w+AgACMxYCAAAK5AA==
Date: Thu, 21 Mar 2024 16:15:33 +0000
Message-ID: 
References: <20240131114952.305805-1-john.ernberg@actia.se>
 <20240131114952.305805-2-john.ernberg@actia.se>
 
 <494d4961-ad8a-4d1d-aaa6-d1bfb9d6a137@actia.se>
 <167f0c7a-e037-446c-82f8-2584e35a7af1@xen.org>
 
 <012b5f83-2f9b-4477-965e-07b8506c0052@xen.org>
 
 <5a0c8f09-4f01-45e9-892c-86342c0d0ec5@xen.org>
 <08ae764c-3490-4dd1-ab70-7a855a98d16d@actia.se>
 <911ec1bb-3733-4f37-839e-673a88e408ff@actia.se>
 
 <848794f3-a337-49d9-84db-a969970f071b@actia.se>
 <48038c7f-d7cd-4100-a41b-8042bcb93208@xen.org>
 <967020E7-3D03-416A-8BFC-6F4E4BD9D7B5@arm.com>
 
 <849f3f5a-b960-444a-a10e-1f2df36c22a7@xen.org>
 <2F07325F-428F-4570-BE14-B84DD0A1C9F7@arm.com>
 <1f5eba1a-7dc3-41f2-8986-26452c264770@actia.se>
In-Reply-To: <1f5eba1a-7dc3-41f2-8986-26452c264770@actia.se>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3774.200.91.1.1)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DB9PR08MB6588:EE_|PAWPR08MB9996:EE_|DB5PEPF00014B88:EE_|AS2PR08MB10055:EE_
X-MS-Office365-Filtering-Correlation-Id: 2e96a875-1cef-48f7-ca26-08dc49c22804
x-checkrecipientrouted: true
nodisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted: BCL:0;
X-Microsoft-Antispam-Message-Info-Original:
 6Ht5S6qTfLg49ALgBqMTZ5z4MERPFcUN76tooHbAPtuFoxWLR/6w7elkx+KHaq4wdlPnJlh8LjpQcXvqme59OTk40b8aMmYnVZNes4isryQhEXHeawpGDLjRtLv471QQuWu8sb+/2Z8//tWkFmEj4lAHpzS2Rdqy/mhJ74E8vEyfssl8SzMceyD3cLPLpROieSrf9KQwmdheM1HklfP5LiRkqC9t8P2PynVVyPQLw53MdVMZ6iXTjB817BdyhevKlrGQSZY6eCnx0yw+GvKN/xXk7YXvk9TbyDjCr2Cop3gT6YB/ORE/3nCS3N5qyGLQR6OhL3Sff3qAC9jN8GxZLhsEJNPeD2tg5k2qExVrmT1cCj6Gq9xm2zsKuPNnygGJbAkZxrwXitLiW6hw09aHC5Y0GRXejq9IpEGXST20KadILbgSUshN70wEkosIVOTOs2IEYxkK+tqgQDGo0EzORbotjUfhelb3zwf8eKQllOTTi2nlB/D9Mjq2hu61KasVMxJUX5feA89c40kRkNw7SjhMBQlF5X8p2c/ly6GqKPq5wvshG8wi222XQkKLDoaV3YJvZlnZ8DUuNuxsIbbYTAYMVUnbZ61B6dIrKyRGY/XqT9pHQ/tXbMSYLGDYXmpbMEAHguQeCQiDH2OVrFbPnDzKdlbdjkwlq5FhpF/8FBfLcRs9cxCbAsoS6zeotINyV0cWgaMKeusoQWpn3kP5jUNo+4LSs9JzYYVWsDYP4QI=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB9PR08MB6588.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(376005)(1800799015)(366007)(38070700009);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="us-ascii"
Content-ID: <67925C69ECF4994D8E451A620D72DD31@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAWPR08MB9996
Original-Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 DB5PEPF00014B88.eurprd02.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	8e941129-b6c5-4680-aa5f-08dc49c22292
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	A2kq7EwSRLOjCW62+RmK8HL6YZFBieakHy0RNpL3SEzrS4RDBh0AUWAiZUtlItrjg4F32ZUxlicwYvdEFAYgj5SFRoYZlXCsYrxyaZTldDfNvG1p+SGfeLxc1i8OVgxFyXYqaAGOCLyGd/rYfQVByhsZ50R4KeZNUfwY5XTayh15s071TZFh9oMjhxleF4vIzGKqJTqUORiGrwn00UkwTK8YjnoPE6radVxcEj8cqRGbDi7UITI9mUFZftOp+cDrmTcT2PXTlLFO0VOR8YB5PIQpMiQrS2SsKsI2wI3FQ3vOcx9MlNTL8QgkRdz2/sRwtgtcDPFM9IW/bYrp2dPMz0NcUXu7r7lFy+0ks8qLl8fpVMEUrHqP2ov3/sEs4nUKf4BK09m41qp2OfyX3YWGdHkLYK+rq/cRuibSDyS2u/PTI/rLukyUga/DbPoBy1E0YBEFPyGulaZUT29Azc+84NLe6BkJPp+Z3wWZZ9H1IFsM1w1qUdJiG1TMb+xxUfPbaLZKnUx2kIxpa0BVUDnfcijTVK31AEBXtx74gpkxxuVjA8p+P4AqlKXLU6VFHp8VFXjROandMWl8Wddw0wlScH9k6p4zg/SGAP1WwUMsqhTFSFGKe2t9l1phQPvNKLqCNRzfcQCX4h42F//LyZciG28iyS2+CNAC+Cdo7VzcSat8wq/zL6MyoqYOG6AxFkwpD/ePfS6zFnTA3SqbjIiP+vuGR6eBH2ZB4BFMS2ENC1YQ7iG50EszLhGAu0XO27uO
X-Forefront-Antispam-Report:
	CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com;CAT:NONE;SFS:(13230031)(376005)(82310400014)(36860700004)(1800799015);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Mar 2024 16:15:42.3497
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 2e96a875-1cef-48f7-ca26-08dc49c22804
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DB5PEPF00014B88.eurprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR08MB10055

Hi John,

> On 21 Mar 2024, at 17:05, John Ernberg  wrote:
>=20
> Hi Bertrand,
>=20
> On 3/21/24 08:41, Bertrand Marquis wrote:
>> Hi,
>>=20
>>> On 20 Mar 2024, at 18:40, Julien Grall  wrote:
>>>=20
>>> Hi John,
>>>=20
>>> On 20/03/2024 16:24, John Ernberg wrote:
>>>> Hi Bertrand,
>>>> On 3/13/24 11:07, Bertrand Marquis wrote:
>>>>> Hi,
>>>>>=20
>>>>>> On 8 Mar 2024, at 15:04, Julien Grall  wrote:
>>>>>>=20
>>>>>> Hi John,
>>>>>>=20
>>>>>> Thank you for the reply.
>>>>>>=20
>>>>>> On 08/03/2024 13:40, John Ernberg wrote:
>>>>>>> On 3/7/24 00:07, Julien Grall wrote:
>>>>>>>>> Ping on the watchdog discussion bits.
>>>>>>>>=20
>>>>>>>> Sorry for the late reply.
>>>>>>>>=20
>>>>>>>> On 06/03/2024 13:13, John Ernberg wrote:
>>>>>>>>> On 2/9/24 14:14, John Ernberg wrote:
>>>>>>>>>>=20
>>>>>>>>>>>      * IMX_SIP_TIMER_*:  This seems to be related to the watchd=
og.
>>>>>>>>>>> Shouldn't dom0 rely on the watchdog provided by Xen instead? So=
 those
>>>>>>>>>>> call will be used by Xen.
>>>>>>>>>>=20
>>>>>>>>>> That is indeed a watchdog SIP, and also for setting the SoC inte=
rnal RTC
>>>>>>>>>> if it is being used.
>>>>>>>>>>=20
>>>>>>>>>> I looked around if there was previous discussion and only really
>>>>>>>>>> found [3].
>>>>>>>>>> Is the xen/xen/include/watchdog.h header meant to be for this ki=
nd of
>>>>>>>>>> watchdog support or is that more for the VM watchdog? Looking at=
 the x86
>>>>>>>>>> ACPI NMI watchdog it seems like the former, but I have never wor=
ked with
>>>>>>>>>> x86 nor ACPI.
>>>>>>>>=20
>>>>>>>> include/watchdog.h contains helper to configure the watchdog for X=
en. We
>>>>>>>> also have per-VM watchdog and this is configured by the hypercall
>>>>>>>> SCHEDOP_watchdog.
>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> Currently forwarding it to Dom0 has not caused any watchdog rese=
ts with
>>>>>>>>>> our watchdog timeout settings, our specific Dom0 setup and VM co=
unt.
>>>>>>>>=20
>>>>>>>> IIUC, the SMC API for the watchdog would be similar to the ACPI NM=
I
>>>>>>>> watchdog. So I think it would make more sense if this is not expos=
ed to
>>>>>>>> dom0 (even if Xen is doing nothing with it).
>>>>>>>>=20
>>>>>>>> Can you try to hide the SMCs and check if dom0 still behave proper=
ly?
>>>>>>>>=20
>>>>>>>> Cheers,
>>>>>>>>=20
>>>>>>> This SMC manages a hardware watchdog, if it's not pinged within a
>>>>>>> specific interval the entire board resets.
>>>>>>=20
>>>>>> Do you know what's the default interval? Is it large enough so Xen +=
 dom0 can boot (at least up to when the watchdog driver is initialized)?
>>>>>>=20
>>>>>>> If I block the SMCs the watchdog driver in Dom0 will fail to ping t=
he
>>>>>>> watchdog, triggering a board reset because the system looks to have
>>>>>>> become unresponsive. The reason this patch set started is because w=
e
>>>>>>> couldn't ping the watchdog when running with Xen.
>>>>>>> In our specific system the bootloader enables the watchdog as early=
 as
>>>>>>> possible so that we can get watchdog protection for as much of the =
boot
>>>>>>> as we possibly can.
>>>>>>> So, if we are to block the SMC from Dom0, then Xen needs to take ov=
er
>>>>>>> the pinging. It could be implemented similarly to the NMI watchdog,
>>>>>>> except that the system will reset if the ping is missed rather than
>>>>>>> backtrace.
>>>>>>> It would also mean that Xen will get a whole watchdog driver-catego=
ry
>>>>>>> due to the watchdog being vendor and sometimes even SoC specific wh=
en it
>>>>>>> comes to Arm.
>>>>>>> My understanding of the domain watchdog code is that today the doma=
in
>>>>>>> needs to call SCHEDOP_watchdog at least once to start the watchdog
>>>>>>> timer. Since watchdog protection through the whole boot process is
>>>>>>> desirable we'd need some core changes, such as an option to start t=
he
>>>>>>> domain watchdog on init. >
>>>>>>> It's quite a big change to make
>>>>>>=20
>>>>>> For clarification, above you seem to mention two changes:
>>>>>>=20
>>>>>> 1) Allow Xen to use the HW watchdog
>>>>>> 2) Allow the domain to use the watchdog early
>>>>>>=20
>>>>>> I am assuming by big change, you are referring to 2?
>>>>>>=20
>>>>>> , while I am not against doing it if it
>>>>>>> makes sense, I now wonder if Xen should manage hardware watchdogs.
>>>>>>> Looking at the domain watchdog code it looks like if a domain does =
not
>>>>>>> get enough execution time, the watchdog will not be pinged enough a=
nd
>>>>>>> the guest will be reset. So either watchdog approach requires Dom0 =
to
>>>>>>> get execution time. Dom0 also needs to service all the PV backends =
it's
>>>>>>> responsible for. I'm not sure it's valuable to add another layer of
>>>>>>> watchdog for this scenario as the end result (checking that the ent=
ire
>>>>>>> system works) is achieved without it as well.
>>>>>>> So, before I try to find the time to make a proposal for moving the
>>>>>>> hardware watchdog bit to Xen, do we really want it?
>>>>>>=20
>>>>>> Thanks for the details. Given that the watchdog is enabled by the bo=
otloader, I think we want Xen to drive the watchdog for two reasons:
>>>>>> 1) In true dom0less environment, dom0 would not exist
>>>>>> 2) You are relying on Xen + Dom0 to boot (or at least enough to get =
the watchdog working) within the watchdog interval.
>>>>>=20
>>>>> Definitely we need to consider the case where there is no Dom0.
>>>>>=20
>>>>> I think there are in fact 3 different use cases here:
>>>>> - watchdog fully driven in a domain (dom0 or another): would work if =
it is expected
>>>>>    that Xen + Domain boot time is under the watchdog initial refresh =
rate. I think this
>>>>>    could make sense on some applications where your system depends on=
 a specific
>>>>>    domain to be properly booted to work. This would require an initia=
l refresh time
>>>>>    configurable in the boot loader probably.
>>>> This is our use-case. ^
>>>> Our dom0 is monitoring and managing the other domains in our system.
>>>> Without dom0 working the system isn't really working as a whole.
>>>> @Julien: Would you be ok with the patch set continuing in the directio=
n
>>>> of the
>>>> original proposal, letting another party (or me at a later time) imple=
ment
>>>> the fully driven by Xen option?
>>> I am concerned about this particular point from Bertrand:
>>>=20
>>> "would work if it is expected that Xen + Domain boot time is under the =
watchdog initial refresh rate."
>>>=20
>>> How will a user be able to figure out how to initially configure the wa=
tchdog? Is this something you can easily configure in the bootloader at run=
time?
>=20
> If you go through the trouble of enabling the watchdog in the bootloader =
you
> usually know what you're doing and set the timeout yourself.
>=20
> Since our systems can be mounted in really annoying locations (both in
> installations and world-wise) we need as much auto-recovery as possible t=
o
> avoid people having to travel to collect a unit that just needed a reset =
due
> to some unexpected obscure issue at startup.

I definitely get the need do not get me wrong.
I am just concerned by potential users having target restarting when using =
Xen because of that and not knowing why.

>>=20
>> Definitely here it would be better to have the watchdog turned off by de=
fault and document how to enable it in the firmware.
>>=20
>> Even if a long timeout is configured by default, a user could run into t=
rouble if using a linux without watchdog or not running linux or using dom0=
less without a linux having access to it.
>> I agree with Julien here that the concern could be that users would come=
 to us instead of NXP if there is system is doing a reset without reasons a=
fter some seconds or minutes.
>=20
> I could add myself as a reviewer for the iMX parts if that helps routing=
=20
> such
> questions (and future patches) also to me. We have experience with the QX=
P,
> and the QM (for the supported parts by this patch set) is identical.
>=20
> Would that help with the concerns?

Definitely it could help.

>=20
>>=20
>>>=20
>>>=20
>>> Overall, I am not for this approach at least in the current status. I w=
ould be more inclined if there are some documentations explaining how this =
is supposed to be configured on NXP, so others can use the code.
>>>=20
>>> Anyway, this is why we have multiple Arm maintainers for this kind of s=
ituation. If they other agrees with you, then they can ack the patch and th=
is can be merged.
>>=20
>> I agree with Stefano that it would be good to have those board supported=
.
>>=20
>> One thing i could suggest until there is a watchdog driver inside Xen is=
 to have a clear Warning at Xen boot on those boards in the console so that=
 we could at least identify the reason easily if a reset occurs for someone=
.
>=20
> How do other SoCs deal with this currently? The iMX SoCs aren't the only=
=20
> ones
> with a watchdog, just the first one added to Xen that pings the watchdog=
=20
> over
> an SMC. What about the OMAPs, the R-Cars, Xilinx's, Exynos' and so on?

As far as I know the watchdog is usually not active until a driver activate=
s it.
Which means that by default it will not fire.
Having it activated by the bootloader by default is not usual.
Now definitely on a lot of use cases the users are activating it in the boo=
loader
but their systems are design for it.

Do I understand that the default boot loader configuration is not activatin=
g it on your side ?

Regards
Bertrand

>=20
> Thanks! // John Ernberg




From xen-devel-bounces@lists.xenproject.org Thu Mar 21 16:23:07 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 16:23:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696494.1087500 (Exim 4.92)
	(envelope-from )
	id 1rnLC2-0007tT-MW; Thu, 21 Mar 2024 16:23:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696494.1087500; Thu, 21 Mar 2024 16:23:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnLC2-0007tM-Jm; Thu, 21 Mar 2024 16:23:02 +0000
Received: by outflank-mailman (input) for mailman id 696494;
 Thu, 21 Mar 2024 16:23:01 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnLC1-0007tE-SY
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 16:23:01 +0000
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com
 [2a00:1450:4864:20::534])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 48d1c38c-e79f-11ee-afe0-a90da7624cb6;
 Thu, 21 Mar 2024 17:23:00 +0100 (CET)
Received: by mail-ed1-x534.google.com with SMTP id
 4fb4d7f45d1cf-56bcbad7ee2so1008940a12.1
 for ; Thu, 21 Mar 2024 09:23:00 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 z9-20020a05640235c900b00568a08a9aacsm39417edc.22.2024.03.21.09.22.59
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 21 Mar 2024 09:22:59 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 48d1c38c-e79f-11ee-afe0-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711038180; x=1711642980; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=KcXVG6yKKtIx3WJsUFf/lcfoFe5UD7bT9AOgM+nby5I=;
        b=PFLk36vNfQmdBYFGoLOe9D5pA5husyKkeC1XC0wo2fKROlKgBvEk2bCsJGF5XpE7ii
         GDt3LsjNVZGoP2O/z39NJVFoAgI3fH3P95Wcx09MA2pOjvGcZWa8D4CfvIBshmQyCVgz
         QH7t7lPCDnMZvxYAlQ+QE3WmMHummFKNvOGUIG8MbbbRNFAjV+Gefm4SizijFebRNLrY
         Ml6AHaZl+Lk1514CM86OlOcD3Ge+Gck4VenT4A0T88Y0HbVUBmrOxO9wI8DlrtahmtVX
         ux1J7ach+Nh3UngjiHfq+V8rWP2jarEb287HfIQ11rPpqn8H7BGJuHPo01P2XUQp2+bJ
         In6w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711038180; x=1711642980;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=KcXVG6yKKtIx3WJsUFf/lcfoFe5UD7bT9AOgM+nby5I=;
        b=CmjfFzkfF2qU4+CJ8QFQwrloLqL3BVYWku7XvRxiWoNzhV9mCoSPPON3FC30x6XXln
         /am4e4RbJsIkgiMUkhy3QF/m2Sn/Vd7A1Zbp5pcnU2Qccb4ScGg9bRePkQ360mSGE9tH
         cNNfDuoIvSv+GGlDJ+LmHX01N8mKYXVutXvI25fjf5tdsagIaKbKBf2j0qkPzafUU4rI
         Rvn1YVCXqJcHIUStE66RN5LSP/2Hyvl6nQRRH/94zdU0C0o+OoUqmeVbK11e/tp0DHu/
         aEFCOlukiJQojeZbOmSKZ3QpJD70zS6Xx8BKQDryWgVgwiijr6I3rdVYic8rTIhutsWS
         Tz0g==
X-Forwarded-Encrypted: i=1; AJvYcCWDMPG1gXGCzExXJUiDsYkLWP+QOZmka63gSGLuwwHRGDC+nuW0stI4P6tnywTzd6KmqAU8HJzBfN5sq5ZmyoyaDlEFepjNkNDAhooVZ/A=
X-Gm-Message-State: AOJu0YyP+BsmPCouwopE5SDUOR0gf2aOkCWdy3nk3cplLNroEQX+4Eru
	qHjFhCG1jnzhZw1l3rQnlO7Oknxa/NBqZcO/TZkZwB1Q8aLQkKQkuo6ZbvYhtA==
X-Google-Smtp-Source: AGHT+IH0DLoZq43+aKpopyxamuKoZEL4Y8tgR4Cc5tTNY+jUnS30OAmbOqRdRdFheGaBZUhjksMuDw==
X-Received: by 2002:a05:6402:5291:b0:568:d303:74dc with SMTP id en17-20020a056402529100b00568d30374dcmr5819663edb.38.1711038179837;
        Thu, 21 Mar 2024 09:22:59 -0700 (PDT)
Message-ID: <255be735-f9fe-4e39-a24e-2f6aff91acc5@suse.com>
Date: Thu, 21 Mar 2024 17:22:58 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 08/14] xen/page_alloc: introduce preserved page flags
 macro
Content-Language: en-US
To: Julien Grall 
Cc: Carlo Nonato ,
 Andrew Cooper ,
 George Dunlap ,
 Stefano Stabellini , Wei Liu ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
 <20240315105902.160047-9-carlo.nonato@minervasys.tech>
 <3f615066-a792-493f-ba33-7667a6557c23@xen.org>
 <9e0f7ff3-5457-41e4-a1e4-bf75804fb900@xen.org>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <9e0f7ff3-5457-41e4-a1e4-bf75804fb900@xen.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 21.03.2024 17:10, Julien Grall wrote:
> On 21/03/2024 16:07, Julien Grall wrote:
>> On 15/03/2024 10:58, Carlo Nonato wrote:
>>> PGC_static and PGC_extra needs to be preserved when assigning a page.
>>> Define a new macro that groups those flags and use it instead of or'ing
>>> every time.
>>>
>>> To make preserved flags even more meaningful, they are kept also when
>>> switching state in mark_page_free().
>>>
>>> Signed-off-by: Carlo Nonato 
>>
>> This patch is introducing a regression in OSStest (and possibly gitlab?):
>>
>> Mar 21 12:00:29.533676 (XEN) pg[0] MFN 2211c5 c=0x2c00000000000000 o=0 
>> v=0xe40000010007ffff t=0x24
>> Mar 21 12:00:42.829785 (XEN) Xen BUG at common/page_alloc.c:1033
>> Mar 21 12:00:42.829829 (XEN) ----[ Xen-4.19-unstable  x86_64  debug=y 
>> Not tainted ]----
>> Mar 21 12:00:42.829857 (XEN) CPU:    12
>> Mar 21 12:00:42.841571 (XEN) RIP:    e008:[] 
>> common/page_alloc.c#alloc_heap_pages+0x37f/0x6e2
>> Mar 21 12:00:42.841609 (XEN) RFLAGS: 0000000000010282   CONTEXT: 
>> hypervisor (d0v8)
>> Mar 21 12:00:42.853654 (XEN) rax: ffff83023e3ed06c   rbx: 
>> 000000000007ffff   rcx: 0000000000000028
>> Mar 21 12:00:42.853689 (XEN) rdx: ffff83047bec7fff   rsi: 
>> ffff83023e3ea3e8   rdi: ffff83023e3ea3e0
>> Mar 21 12:00:42.865657 (XEN) rbp: ffff83047bec7c10   rsp: 
>> ffff83047bec7b98   r8:  0000000000000000
>> Mar 21 12:00:42.877647 (XEN) r9:  0000000000000001   r10: 
>> 000000000000000c   r11: 0000000000000010
>> Mar 21 12:00:42.877682 (XEN) r12: 0000000000000001   r13: 
>> 0000000000000000   r14: ffff82e0044238a0
>> Mar 21 12:00:42.889652 (XEN) r15: 0000000000000000   cr0: 
>> 0000000080050033   cr4: 0000000000372660
>> Mar 21 12:00:42.901651 (XEN) cr3: 000000046fe34000   cr2: 00007fb72757610b
>> Mar 21 12:00:42.901685 (XEN) fsb: 00007fb726def380   gsb: 
>> ffff88801f200000   gss: 0000000000000000
>> Mar 21 12:00:42.913646 (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000 
>> ss: e010   cs: e008
>> Mar 21 12:00:42.913680 (XEN) Xen code around  
>> (common/page_alloc.c#alloc_heap_pages+0x37f/0x6e2):
>> Mar 21 12:00:42.925645 (XEN)  d1 1c 00 e8 ad dd 02 00 <0f> 0b 48 85 c9 
>> 79 36 0f 0b 41 89 cd 48 c7 47 f0
>> Mar 21 12:00:42.937649 (XEN) Xen stack trace from rsp=ffff83047bec7b98:
>> Mar 21 12:00:42.937683 (XEN)    0000000000000024 000000007bec7c20 
>> 0000000000000001 ffff83046ccda000
>> Mar 21 12:00:42.949653 (XEN)    ffff82e000000021 0000000000000016 
>> 0000000000000000 0000000000000000
>> Mar 21 12:00:42.949687 (XEN)    0000000000000000 0000000000000000 
>> 0000000000000028 0000000000000021
>> Mar 21 12:00:42.961652 (XEN)    ffff83046ccda000 0000000000000000 
>> 00007d2000000000 ffff83047bec7c48
>> Mar 21 12:00:42.961687 (XEN)    ffff82d0402302ff ffff83046ccda000 
>> 0000000000000100 0000000000000000
>> Mar 21 12:00:42.973655 (XEN)    ffff82d0405f0080 00007d2000000000 
>> ffff83047bec7c80 ffff82d0402f626c
>> Mar 21 12:00:42.985656 (XEN)    ffff83046ccda000 ffff83046ccda640 
>> 0000000000000000 0000000000000000
>> Mar 21 12:00:42.985690 (XEN)    ffff83046ccda220 ffff83047bec7cb0 
>> ffff82d0402f65a0 ffff83046ccda000
>> Mar 21 12:00:42.997662 (XEN)    0000000000000000 0000000000000000 
>> 0000000000000000 ffff83047bec7cc0
>> Mar 21 12:00:43.009660 (XEN)    ffff82d040311f8a ffff83047bec7ce0 
>> ffff82d0402bd543 ffff83046ccda000
>> Mar 21 12:00:43.009695 (XEN)    ffff83047bec7dc8 ffff83047bec7d08 
>> ffff82d04032c524 ffff83046ccda000
>> Mar 21 12:00:43.021653 (XEN)    ffff83047bec7dc8 0000000000000002 
>> ffff83047bec7d58 ffff82d040206750
>> Mar 21 12:00:43.033642 (XEN)    0000000000000000 ffff82d040233fe5 
>> ffff83047bec7d48 0000000000000000
>> Mar 21 12:00:43.033678 (XEN)    0000000000000002 00007fb72767f010 
>> ffff82d0405e9120 0000000000000001
>> Mar 21 12:00:43.045654 (XEN)    ffff83047bec7e70 ffff82d040240728 
>> 0000000000000007 ffff83023e3b3000
>> Mar 21 12:00:43.045690 (XEN)    0000000000000246 ffff83023e2efa90 
>> ffff83023e38e000 ffff83023e2efb40
>> Mar 21 12:00:43.057609 (XEN)    0000000000000007 ffff83023e3afb80 
>> 0000000000000206 ffff83047bec7dc0
>> Mar 21 12:00:43.069662 (XEN)    0000001600000001 000000000000ffff 
>> e75aaa8d0000000c ac0d6d864e487f62
>> Mar 21 12:00:43.069697 (XEN)    000000037fa48d76 0000000200000000 
>> ffffffff000003ff 00000002ffffffff
>> Mar 21 12:00:43.081647 (XEN)    0000000000000000 00000000000001ff 
>> 0000000000000000 0000000000000000
>> Mar 21 12:00:43.093646 (XEN) Xen call trace:
>> Mar 21 12:00:43.093677 (XEN)    [] R 
>> common/page_alloc.c#alloc_heap_pages+0x37f/0x6e2
>> Mar 21 12:00:43.093705 (XEN)    [] F 
>> alloc_domheap_pages+0x17d/0x1e4
>> Mar 21 12:00:43.105652 (XEN)    [] F 
>> hap_set_allocation+0x73/0x23c
>> Mar 21 12:00:43.105685 (XEN)    [] F 
>> hap_enable+0x138/0x33c
>> Mar 21 12:00:43.117646 (XEN)    [] F 
>> paging_enable+0x2d/0x45
>> Mar 21 12:00:43.117679 (XEN)    [] F 
>> hvm_domain_initialise+0x185/0x428
>> Mar 21 12:00:43.129652 (XEN)    [] F 
>> arch_domain_create+0x3e7/0x4c1
>> Mar 21 12:00:43.129687 (XEN)    [] F 
>> domain_create+0x4cc/0x7e2
>> Mar 21 12:00:43.141665 (XEN)    [] F 
>> do_domctl+0x1850/0x192d
>> Mar 21 12:00:43.141699 (XEN)    [] F 
>> pv_hypercall+0x617/0x6b5
>> Mar 21 12:00:43.153656 (XEN)    [] F 
>> lstar_enter+0x13a/0x140
>> Mar 21 12:00:43.153689 (XEN)
>> Mar 21 12:00:43.153711 (XEN)
>> Mar 21 12:00:43.153731 (XEN) ****************************************
>> Mar 21 12:00:43.165647 (XEN) Panic on CPU 12:
>> Mar 21 12:00:43.165678 (XEN) Xen BUG at common/page_alloc.c:1033
>> Mar 21 12:00:43.165703 (XEN) ****************************************
>> Mar 21 12:00:43.177633 (XEN)
>> Mar 21 12:00:43.177662 (XEN) Manual reset required ('noreboot' specified)
>>
>> The code around the BUG is:
>>
>>          /* Reference count must continuously be zero for free pages. */
>>          if ( (pg[i].count_info & ~PGC_need_scrub) != PGC_state_free )
>>          {
>>              printk(XENLOG_ERR
>>                     "pg[%u] MFN %"PRI_mfn" c=%#lx o=%u v=%#lx t=%#x\n",
>>                     i, mfn_x(page_to_mfn(pg + i)),
>>                     pg[i].count_info, pg[i].v.free.order,
>>                     pg[i].u.free.val, pg[i].tlbflush_timestamp);
>>              BUG();
>>          }
>>
>> Now that you are preserving some flags, you also want to modify the 
>> condition. I haven't checked the rest of the code, so there might be 
>> some adjustments necessary.
> 
> Actually maybe the condition should not be adjusted. I think it would be 
> wrong if a free pages has the flag PGC_extra set. Any thoughts?

I agree, yet I'm inclined to say PGC_extra should have been cleared
before trying to free the page.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 17:22:49 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 17:22:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696535.1087515 (Exim 4.92)
	(envelope-from )
	id 1rnM7g-0002TR-2K; Thu, 21 Mar 2024 17:22:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696535.1087515; Thu, 21 Mar 2024 17:22:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnM7f-0002TK-W0; Thu, 21 Mar 2024 17:22:35 +0000
Received: by outflank-mailman (input) for mailman id 696535;
 Thu, 21 Mar 2024 17:22:35 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rnM7f-0002TE-2C
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 17:22:35 +0000
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com
 [2a00:1450:4864:20::535])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 99e7d172-e7a7-11ee-a1ee-f123f15fe8a2;
 Thu, 21 Mar 2024 18:22:32 +0100 (CET)
Received: by mail-ed1-x535.google.com with SMTP id
 4fb4d7f45d1cf-568c714a9c7so1385578a12.2
 for ; Thu, 21 Mar 2024 10:22:32 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 99e7d172-e7a7-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1711041752; x=1711646552; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=85TxGiwza99wtn1DtjT+K1IsWZir75NwRzw/vclyqSw=;
        b=Nz8cLUpG80HNvqwfN3boLTbEJQ7oz5maV6SvlUwmvJz2zcdj2sIhtCIcXl84u7Esp4
         cE4W3gA15FVOaieWg9qKcT9GbA/bVXRMcs/gJaX+EBh5DKNerOMSwQlWBNDXObZ+pwYO
         pzkJ1Y18+5lyDGC+kOmnq4U2v/XEu/pKnfsP1CkAYYPrgA8XXD+14rJQFUrKW+4WiKpo
         gv8dB/vZjtQUTU3rRFPOUresUEtXiC5E01hYtYt8kfHBwPmJZpSveuf+gMiL9aKVm9du
         RG467dkAev5TzhM5utJ80BQXKMIy7nlOSp+3XnKmYvzyjL/mxwE3U8HbiCAogSCme+Bf
         R8fg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711041752; x=1711646552;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=85TxGiwza99wtn1DtjT+K1IsWZir75NwRzw/vclyqSw=;
        b=IIGLDNuj4+P8GrTRXJwQ7GMh8419NAv2SnScC5vQSb3m3T+6TM3JoUOCnAPXdde07G
         An2G5HcMIgBaFBhbRHcY+zA4+tjNsFBMBAn9Ewc8A2ooLWvwpf+zes4hTBcaXRFGISma
         Brj7Gya9f/Nf7CpIxFzbK2f28pcThQWkYNq83kvjK47D+CFjHtqgIufksh4DBfuAfAgr
         xZFfLsnwdQFQAYQZM5tbzKlugrbcCWaMJz4HlhnaVrkFeocFnC8Jf0xqiwKF8B9qlUll
         FC3nQ4AuE0auyNx2olbH7hdlF5CUSnMEVX4h8fCv8Hh8NFhhfgBXRiaDf2wtBomsk7g0
         5yAQ==
X-Forwarded-Encrypted: i=1; AJvYcCVcnsfl8ppz0z4yPgedjZ2thBjmwvBrsv8U1ed8iiF7bB0I3+QscYu7Hte3UKDXpzhyD2Msm9QlrnGCz4E+aEGzQNjEOVg1T2pdbab83hA=
X-Gm-Message-State: AOJu0YxGK5y3v5l12XnE8XcaW89p7OcQTvqHROQLlFLlrWizExgDvYsq
	P5jL2p+XcRBb7KowIdGPrO4rIHVVVc6dLU8mDd3BXCUXQC8PXA0MSZhFXiV1N9eSNcU3QSTxEHs
	FIZx75HNtYMTjwCrn+ikn7FrVGmnia5f/+/wSvfPokM50c77KdOU74w==
X-Google-Smtp-Source: AGHT+IFxuOPMnwTtSsJQyVHADhFPkyYr72krYF3I0RdJqX1e0mhpPGWYOFTIwmPFdtCA+AuIwdo1d+ErQBdUT5/3vno=
X-Received: by 2002:a17:906:46cc:b0:a46:ed8d:9e44 with SMTP id
 k12-20020a17090646cc00b00a46ed8d9e44mr60122ejs.33.1711041751911; Thu, 21 Mar
 2024 10:22:31 -0700 (PDT)
MIME-Version: 1.0
References: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
 <20240315105902.160047-2-carlo.nonato@minervasys.tech> <05e4d3da-4130-4c57-9855-43b685ce5005@suse.com>
  <2b4d6e96-0f04-4327-9875-cd0587931621@suse.com>
In-Reply-To: <2b4d6e96-0f04-4327-9875-cd0587931621@suse.com>
From: Carlo Nonato 
Date: Thu, 21 Mar 2024 18:22:20 +0100
Message-ID: 
Subject: Re: [PATCH v7 01/14] xen/common: add cache coloring common code
To: Jan Beulich 
Cc: Andrea Bastoni , 
	Andrew Cooper , George Dunlap , 
	Julien Grall , Stefano Stabellini , Wei Liu , 
	Marco Solieri , xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Jan,

On Thu, Mar 21, 2024 at 4:53=E2=80=AFPM Jan Beulich  wro=
te:
>
> On 21.03.2024 16:03, Carlo Nonato wrote:
> > On Tue, Mar 19, 2024 at 3:58=E2=80=AFPM Jan Beulich =
 wrote:
> >> On 15.03.2024 11:58, Carlo Nonato wrote:
> >>> --- a/docs/misc/xen-command-line.pandoc
> >>> +++ b/docs/misc/xen-command-line.pandoc
> >>> @@ -1706,6 +1706,43 @@ This option is intended for debugging purposes=
 only.  Enable MSR_DEBUGCTL.LBR
> >>>  in hypervisor context to be able to dump the Last Interrupt/Exceptio=
n To/From
> >>>  record with other registers.
> >>>
> >>> +### llc-coloring
> >>> +> `=3D `
> >>> +
> >>> +> Default: `false`
> >>> +
> >>> +Flag to enable or disable LLC coloring support at runtime. This opti=
on is
> >>> +available only when `CONFIG_LLC_COLORING` is enabled. See the genera=
l
> >>> +cache coloring documentation for more info.
> >>> +
> >>> +### llc-nr-ways
> >>> +> `=3D `
> >>> +
> >>> +> Default: `Obtained from hardware`
> >>> +
> >>> +Specify the number of ways of the Last Level Cache. This option is a=
vailable
> >>> +only when `CONFIG_LLC_COLORING` is enabled. LLC size and number of w=
ays are used
> >>> +to find the number of supported cache colors. By default the value i=
s
> >>> +automatically computed by probing the hardware, but in case of speci=
fic needs,
> >>> +it can be manually set. Those include failing probing and debugging/=
testing
> >>> +purposes so that it's possibile to emulate platforms with different =
number of
> >>> +supported colors. If set, also "llc-size" must be set, otherwise the=
 default
> >>> +will be used.
> >>> +
> >>> +### llc-size
> >>> +> `=3D `
> >>> +
> >>> +> Default: `Obtained from hardware`
> >>> +
> >>> +Specify the size of the Last Level Cache. This option is available o=
nly when
> >>> +`CONFIG_LLC_COLORING` is enabled. LLC size and number of ways are us=
ed to find
> >>> +the number of supported cache colors. By default the value is automa=
tically
> >>> +computed by probing the hardware, but in case of specific needs, it =
can be
> >>> +manually set. Those include failing probing and debugging/testing pu=
rposes so
> >>> +that it's possibile to emulate platforms with different number of su=
pported
> >>> +colors. If set, also "llc-nr-ways" must be set, otherwise the defaul=
t will be
> >>> +used.
> >>
> >> Wouldn't it make sense to infer "llc-coloring" when both of the latter=
 options
> >> were supplied?
> >
> > To me it looks a bit strange that specifying some attributes of the cac=
he
> > automatically enables cache coloring. Also it would require some change=
s in
> > how to express the auto-probing for such attributes.
>
> Whereas to me it looks strange that, when having llc-size and llc-nr-ways
> provided, I'd need to add a 3rd option. What purpose other than enabling
> coloring could there be when specifying those parameters?

Ok, I probably misunderstood you. You mean just to assume llc-coloring=3Don
when both llc-size and llc-nr-ways are present and not to remove
llc-coloring completely, right? I'm ok with this.

> Jan

Thanks.


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 17:25:19 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 17:25:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696537.1087526 (Exim 4.92)
	(envelope-from )
	id 1rnMAI-00030q-FC; Thu, 21 Mar 2024 17:25:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696537.1087526; Thu, 21 Mar 2024 17:25:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnMAI-00030j-BZ; Thu, 21 Mar 2024 17:25:18 +0000
Received: by outflank-mailman (input) for mailman id 696537;
 Thu, 21 Mar 2024 17:25:16 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnMAG-00030Z-KK; Thu, 21 Mar 2024 17:25:16 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnMAG-0006Z5-EX; Thu, 21 Mar 2024 17:25:16 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnMAG-0000cx-5B; Thu, 21 Mar 2024 17:25:16 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rnMAG-0002Jb-4i; Thu, 21 Mar 2024 17:25:16 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=8guZZjlH0GJPfModEouOTDAyxBmoVrLUmwILUBUpVnA=; b=KqKUU5XPX6KO7yG4S/gBy4P32i
	ZGRogLONhCcm0N6H1sSbN1zQDhWLVX57+K9UeDDe0DPNj1h09W/b9KVXuwbEJh33kiAn34mTJD4g8
	K6F9WhKxrFCEYHlOCBMmOZbMPAgrsFVhxRiIJmM+9NzFZsQL+gIxmJwp7bzofE03iYPA=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 185125: regressions - FAIL
X-Osstest-Failures:
    xen-unstable-smoke:test-amd64-amd64-xl-qemuu-debianhvm-amd64:debian-hvm-install:fail:regression
    xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    xen=ee973396f008ff0de2836b7ca100ce822740fa41
X-Osstest-Versions-That:
    xen=eaafbd11344a8ec32309fe58a6e529fe1c34d62e
From: osstest service owner 
Date: Thu, 21 Mar 2024 17:25:16 +0000

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          16 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  ee973396f008ff0de2836b7ca100ce822740fa41
baseline version:
 xen                  eaafbd11344a8ec32309fe58a6e529fe1c34d62e

Last test of basis   185109  2024-03-20 09:03:31 Z    1 days
Failing since        185120  2024-03-21 09:03:04 Z    0 days    2 attempts
Testing same since   185125  2024-03-21 13:00:23 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper 
  Anthony PERARD 
  Carlo Nonato 
  Elliott Mitchell 
  Jan Beulich 
  Roger Pau Monné 
  Shawn Anastasio 

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-amd64                    fail    
 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


Not pushing.

------------------------------------------------------------
commit ee973396f008ff0de2836b7ca100ce822740fa41
Author: Andrew Cooper 
Date:   Mon Mar 18 18:07:05 2024 +0000

    x86/cpuid: More AMD features
    
    All of these are informational and require no further logic changes in Xen to
    support.
    
    Signed-off-by: Andrew Cooper 
    Reviewed-by: Jan Beulich 

commit 5205bda5f11cc03ca62ad2bb6c34bf738bbb3247
Author: Andrew Cooper 
Date:   Mon Oct 22 14:53:26 2018 +0100

    x86/p2m: Coding style cleanup
    
    No functional change.
    
    Signed-off-by: Andrew Cooper 
    Reviewed-by: Jan Beulich 

commit 97b90f9bf2e5c93e0f61c927fa2bc8a56a213faa
Author: Shawn Anastasio 
Date:   Thu Mar 21 09:49:20 2024 +0100

    xen/ppc: Ensure ELF sections' physical load addresses start at 0x0
    
    Some boot mechanisms, including the new linux file_load kexec systemcall
    used by system firmware v2.10 on RaptorCS systems will try to honor the
    physical address field of the ELF LOAD section header, which will fail
    when the address is based off of XEN_VIRT_START (0xc000000000000000).
    
    To ensure that the physical address of the LOAD section header starts at
    0x0, move x86's DECL_SECTION macro to xen.lds.h and use it to declare
    all sections.
    
    Signed-off-by: Shawn Anastasio 
    Acked-by: Andrew Cooper 

commit 10e8d824b76f55dde7c1793f48d76d4ff9df5e0a
Author: Jan Beulich 
Date:   Thu Mar 21 09:48:49 2024 +0100

    AMD/IOMMU: drop remaining guest-IOMMU bits too
    
    With a02174c6c885 ("amd/iommu: clean up unused guest iommu related
    functions") having removed the sole place where d->g_iommu would be set
    to non-NULL, guest_iommu_add_ppr_log() will unconditionally bail the
    latest from its 2nd if(). With it dropped, all other stuff in the file
    is unused, too. Delete iommu_guest.c altogether.
    
    Further delete struct guest{_buffer,_dev_table,_iommu{,_msi}} as well as
    struct mmio_reg for being unused with the unused g_iommu also dropped
    from struct arch_iommu.
    
    Signed-off-by: Jan Beulich 
    Acked-by: Roger Pau Monné 

commit cc950c49ae6a6690f7fc3041a1f43122c250d250
Author: Jan Beulich 
Date:   Thu Mar 21 09:48:10 2024 +0100

    x86/PoD: tie together P2M update and increment of entry count
    
    When not holding the PoD lock across the entire region covering P2M
    update and stats update, the entry count - if to be incorrect at all -
    should indicate too large a value in preference to a too small one, to
    avoid functions bailing early when they find the count is zero. However,
    instead of moving the increment ahead (and adjust back upon failure),
    extend the PoD-locked region.
    
    Fixes: 99af3cd40b6e ("x86/mm: Rework locking in the PoD layer")
    Signed-off-by: Jan Beulich 
    Reviewed-by: George Dunlap 

commit f5c2b6da26d9becd5a1a03fcd3e5c950301030a2
Author: Carlo Nonato 
Date:   Thu Mar 21 09:47:21 2024 +0100

    xen/page_alloc: introduce page flag to stop buddy merging
    
    Add a new PGC_no_buddy_merge flag that prevents the buddy algorithm in
    free_heap_pages() from merging pages that have it set. As of now, only
    PGC_static has this feature, but future work can extend it easier than
    before.
    
    Suggested-by: Jan Beulich 
    Signed-off-by: Carlo Nonato 
    Reviewed-by: Jan Beulich 

commit 75214d5e53f60a7b19e90ebdb090c20044a052ca
Author: Carlo Nonato 
Date:   Thu Mar 21 09:46:42 2024 +0100

    xen/page_alloc: introduce preserved page flags macro
    
    PGC_static and PGC_extra needs to be preserved when assigning a page.
    Define a new macro that groups those flags and use it instead of or'ing
    every time.
    
    To make preserved flags even more meaningful, they are kept also when
    switching state in mark_page_free().
    
    Signed-off-by: Carlo Nonato 
    Reviewed-by: Jan Beulich 

commit 6eb13b6b1d984af87460f60f2c0cbc5c059b8402
Author: Elliott Mitchell 
Date:   Thu Mar 21 09:46:13 2024 +0100

    tools/xl_parse: remove message for tsc mode string
    
    Normal behavior is to be silent.  Generating a message for the preferred
    input can be mistaken for an error.  As such remove this message to match
    other conditions.
    
    Signed-off-by: Elliott Mitchell 
    Acked-by: Anthony PERARD 
(qemu changes not included)


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 17:30:53 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 17:30:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696545.1087535 (Exim 4.92)
	(envelope-from )
	id 1rnMFd-000526-1X; Thu, 21 Mar 2024 17:30:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696545.1087535; Thu, 21 Mar 2024 17:30:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnMFc-00051z-VA; Thu, 21 Mar 2024 17:30:48 +0000
Received: by outflank-mailman (input) for mailman id 696545;
 Thu, 21 Mar 2024 17:30:47 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1rnMFb-00051t-Mk
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 17:30:47 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnMFb-0006f8-6d; Thu, 21 Mar 2024 17:30:47 +0000
Received: from gw1.octic.net ([88.97.20.152] helo=[10.0.1.240])
 by xenbits.xenproject.org with esmtpsa
 (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92)
 (envelope-from )
 id 1rnMFa-0006uB-Vg; Thu, 21 Mar 2024 17:30:47 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=lbdeDOqJ+i2eL5Vu9dhHJJxJ64TSt4rCuK6fGgrq04Q=; b=NX/Vym/a804aTM7TCwCJKshSfT
	Eqd68b+iVDNg2YV9KHgT7Elf8xoRupi/ZBS0Eet8+68R0/Lg7fA/e1B4cjMMPvXZrbncYrcmxKe+M
	aUtkEFPI8ZWbl7mVsjx/sH7pHR5THQeFzJfOPHDyMqNIVcXryDTiS9gXQ/9bloYjg9Ac=;
Message-ID: 
Date: Thu, 21 Mar 2024 17:30:44 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 1/9] EFI: Introduce inline stub for efi_enabled on !X86
 && !ARM
Content-Language: en-GB
To: Shawn Anastasio ,
 xen-devel@lists.xenproject.org
Cc: tpearson@raptorengineering.com, Jan Beulich ,
 Andrew Cooper ,
 George Dunlap ,
 Stefano Stabellini , Wei Liu 
References: 
 <39069a589f9c4dc0db9b01b7412c1a99bea55f37.1710443965.git.sanastasio@raptorengineering.com>
From: Julien Grall 
In-Reply-To: <39069a589f9c4dc0db9b01b7412c1a99bea55f37.1710443965.git.sanastasio@raptorengineering.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Shawn,

On 14/03/2024 22:15, Shawn Anastasio wrote:
> On architectures with no EFI support, define an inline stub
> implementation of efi_enabled in efi.h that always returns false.
> 
> Suggested-by: Jan Beulich 
> Signed-off-by: Shawn Anastasio 

Acked-by: Julien Grall 

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 17:31:57 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 17:31:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696547.1087546 (Exim 4.92)
	(envelope-from )
	id 1rnMGg-0005XS-D9; Thu, 21 Mar 2024 17:31:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696547.1087546; Thu, 21 Mar 2024 17:31:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnMGg-0005XL-8x; Thu, 21 Mar 2024 17:31:54 +0000
Received: by outflank-mailman (input) for mailman id 696547;
 Thu, 21 Mar 2024 17:31:52 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rnMGe-0005XD-N9
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 17:31:52 +0000
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com
 [2a00:1450:4864:20::633])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e74e71a8-e7a8-11ee-afe0-a90da7624cb6;
 Thu, 21 Mar 2024 18:31:51 +0100 (CET)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-a450bedffdfso155548566b.3
 for ; Thu, 21 Mar 2024 10:31:51 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e74e71a8-e7a8-11ee-afe0-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1711042311; x=1711647111; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=W7yYWWwEJPQJZJoFRXLpRuq85VjgKMi1SEsDlACyueo=;
        b=1ObxNMyXWB/7iGxEP+bo3D5ydRDzxs2kL49Xby14+gAwt7bX7G8Yv+yupzwYorcSXO
         fUHfA80D9Q6iZqkJ6AXne8dVwlY6M90/q0M7FMapShV4D6KMId8pxxcO2GjNEjGrNSW1
         zfHe6WSNvUjZtDKybDcPoe43o5y2Ut3IrlpDyBLdVGx9PjziRLdsmf+C6ttM5HLqJk2W
         w76P96Bj+S/IIXS9zcSO81nOh84sDeIkAso7vg+b2YCyLPeawiCM69CRlFmflnYiDesm
         md/eQlMZW+qnFZ9r2pPRLOeUNZtzXcMVvLdWFuUWmYqlGUPaYafw07kPSC2pOFaVkWbt
         WmdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711042311; x=1711647111;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=W7yYWWwEJPQJZJoFRXLpRuq85VjgKMi1SEsDlACyueo=;
        b=XymQkQIOwySYs//qmUzPPpuP5HpOdMHfw6JDMsPtLAcION9+NYVmefpFKRg+X8N1C3
         xPR4yr+9kfRtwSUvArmSCh02IL1Qo8x1RiMCZJ/dHcsKs2CGu8xHaNeUXTFWC+q0Tp3L
         /LbHOwWcJwKG8LBv87/oE8N9iarAF3i6c2UwRryrAgJLQaWR/+r20z/ysn1f0nP2dYV3
         JpHwbaK+slzi4TrDunQOBtiAgA5WmN5cPQ2b3TzTuhXpW37+MHzfiwqPL111PfxKDAzo
         WuEmQ8dKOfslLJBapJF146VPLfSr3/qx/0mizzM+15YyQUYM//m8ZddCIRLqqdOHzHff
         zF/w==
X-Forwarded-Encrypted: i=1; AJvYcCVmt1hhxsc7iG2dSKHoeHfjgm8pXgzLWVoCwO3imxoKkkWVs8mbwraXOt/RtarrS38z1/EKizi5kltj4tEbq5j1zHCjyGPRSjiKlssfjhY=
X-Gm-Message-State: AOJu0YwjuDQ04weB+ZEp2oZrHJznvMrhDE/ViEeKxOloBXb/PCyrbcXa
	sJIZz3IiDvekp1Xw4+TtlWMJkVKgTDnDm/4h9d84XzPTlTQfl1GJOujZQtsmYwdCFi5Mb63wIhF
	vP3gquWPCo2yXbcVKEtwU91em0a1BtAdvYYN2/g==
X-Google-Smtp-Source: AGHT+IHsZHvJE9jiRlQH1loXN8L8hM6ROY7z54owlPQxguWU0JLSbpmi2sqMBTR47lyAtdlg08GQXilN1SEb6qc5mM8=
X-Received: by 2002:a17:906:130f:b0:a47:63d:e21a with SMTP id
 w15-20020a170906130f00b00a47063de21amr75934ejb.35.1711042311218; Thu, 21 Mar
 2024 10:31:51 -0700 (PDT)
MIME-Version: 1.0
References: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
 <20240315105902.160047-5-carlo.nonato@minervasys.tech> 
  <3ff10fdd-5a85-43b3-853a-fe69c7388ca9@suse.com>
In-Reply-To: <3ff10fdd-5a85-43b3-853a-fe69c7388ca9@suse.com>
From: Carlo Nonato 
Date: Thu, 21 Mar 2024 18:31:40 +0100
Message-ID: 
Subject: Re: [PATCH v7 04/14] xen/arm: add Dom0 cache coloring support
To: Jan Beulich 
Cc: Andrew Cooper , George Dunlap , 
	Julien Grall , Stefano Stabellini , Wei Liu , 
	Bertrand Marquis , Michal Orzel , 
	Volodymyr Babchuk , Marco Solieri , 
	xen-devel@lists.xenproject.org, 
	Andrea Bastoni 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Mar 21, 2024 at 4:57=E2=80=AFPM Jan Beulich  wro=
te:
>
> On 21.03.2024 16:04, Carlo Nonato wrote:
> > On Tue, Mar 19, 2024 at 4:30=E2=80=AFPM Jan Beulich =
 wrote:
> >> On 15.03.2024 11:58, Carlo Nonato wrote:
> >>> --- a/docs/misc/xen-command-line.pandoc
> >>> +++ b/docs/misc/xen-command-line.pandoc
> >>> @@ -963,6 +963,15 @@ Controls for the dom0 IOMMU setup.
> >>>
> >>>  Specify a list of IO ports to be excluded from dom0 access.
> >>>
> >>> +### dom0-llc-colors
> >>> +> `=3D List of [  | - ]`
> >>> +
> >>> +> Default: `All available LLC colors`
> >>> +
> >>> +Specify dom0 LLC color configuration. This option is available only =
when
> >>> +`CONFIG_LLC_COLORING` is enabled. If the parameter is not set, all a=
vailable
> >>> +colors are used.
> >>
> >> My reservation towards this being a top-level option remains.
> >
> > How can I turn this into a lower-level option? Moving it into "dom0=3D"=
 doesn't
> > seem possible to me. How can I express a list (llc-colors) inside anoth=
er list
> > (dom0)? dom0=3Dllc-colors=3D0-3,12-15,other-param=3D... How can I stop =
parsing
> > before reaching other-param?
>
> For example by using a different separator:
>
> dom0=3Dllc-colors=3D0-3+12-15,other-param=3D...

Ok, but that would mean to change the implementation of the parsing functio=
n
and to adopt this syntax also in other places, something that I would've
preferred to avoid. Anyway I'll follow your suggestion.

> >>> @@ -91,6 +164,61 @@ void cf_check domain_dump_llc_colors(const struct=
 domain *d)
> >>>      print_colors(d->llc_colors, d->num_llc_colors);
> >>>  }
> >>>
> >>> +static int domain_set_default_colors(struct domain *d)
> >>> +{
> >>> +    unsigned int *colors =3D xmalloc_array(unsigned int, max_nr_colo=
rs);
> >>> +    unsigned int i;
> >>> +
> >>> +    if ( !colors )
> >>> +        return -ENOMEM;
> >>> +
> >>> +    printk(XENLOG_WARNING
> >>> +           "LLC color config not found for %pd, using all colors\n",=
 d);
> >>> +
> >>> +    for ( i =3D 0; i < max_nr_colors; i++ )
> >>> +        colors[i] =3D i;
> >>> +
> >>> +    d->llc_colors =3D colors;
> >>> +    d->num_llc_colors =3D max_nr_colors;
> >>> +
> >>> +    return 0;
> >>> +}
> >>
> >> If this function is expected to actually come into play, wouldn't it
> >> make sense to set up such an array just once, and re-use it wherever
> >> necessary?
> >
> > Then how to distinguish when to free it in domain_destroy() and when no=
t to do
> > it?
>
> By checking against that one special array instance.

Ok.

> Jan

Thanks.


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 17:37:11 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 17:37:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696550.1087555 (Exim 4.92)
	(envelope-from )
	id 1rnMLi-0006Af-Tw; Thu, 21 Mar 2024 17:37:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696550.1087555; Thu, 21 Mar 2024 17:37:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnMLi-0006AY-RA; Thu, 21 Mar 2024 17:37:06 +0000
Received: by outflank-mailman (input) for mailman id 696550;
 Thu, 21 Mar 2024 17:37:05 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1rnMLh-0006AS-2J
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 17:37:05 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnMLg-0006ml-Kr; Thu, 21 Mar 2024 17:37:04 +0000
Received: from gw1.octic.net ([88.97.20.152] helo=[10.0.1.240])
 by xenbits.xenproject.org with esmtpsa
 (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92)
 (envelope-from )
 id 1rnMLg-0007Jw-Dz; Thu, 21 Mar 2024 17:37:04 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=8fziIsojyxAkAl9v5/6QiksQgxPJ93MzEwjPXDXxJBQ=; b=h4kL0Ma5I+XJ7AoP/i4Rwcdjh3
	iM3pmPR5HQvm+BCd52qY4az4x9WPva6T3ljS2yMKBeJSgMWW/BETgpWfhuk0qr1jPK41I7Z/ito1O
	88vbSz5B1LU5dhOgIvrcPVKOafiaMDZm6h64tB94Clom6UPOeV1/mHi1/LZyBtL3MCH0=;
Message-ID: <5126dec1-e416-4aef-a4cf-cff031569328@xen.org>
Date: Thu, 21 Mar 2024 17:37:03 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 4/9] xen/ppc: Update setup.h with required definitions
 for bootfdt
Content-Language: en-GB
To: Shawn Anastasio ,
 xen-devel@lists.xenproject.org
Cc: tpearson@raptorengineering.com, Jan Beulich 
References: 
 <2c14419bd9fbd5307fe4d5b079a9927e4d3ec9fc.1710443965.git.sanastasio@raptorengineering.com>
From: Julien Grall 
In-Reply-To: <2c14419bd9fbd5307fe4d5b079a9927e4d3ec9fc.1710443965.git.sanastasio@raptorengineering.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Shawn,

On 14/03/2024 22:15, Shawn Anastasio wrote:
> Add the definitions used by ARM's bootfdt.c, which will be moved into
> xen/common in a later patch, to PPC's setup.h

This read as the definition should be in include/xen/... rather than per 
arch. In particular, ...

> +/*
> + * bootinfo.c
> + */
> +bool check_reserved_regions_overlap(paddr_t region_start, paddr_t region_size);
> +struct bootmodule *add_boot_module(bootmodule_kind kind,
> +                                   paddr_t start, paddr_t size, bool domU);
> +void add_boot_cmdline(const char *name, const char *cmdline,
> +                      bootmodule_kind kind, paddr_t start, bool domU);
> +const char *boot_module_kind_as_string(bootmodule_kind kind);
> +struct bootcmdline *boot_cmdline_find_by_kind(bootmodule_kind kind);
> +void populate_boot_allocator(void);

... will be defined in common/*/bootfdt.c.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 17:39:29 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 17:39:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696553.1087566 (Exim 4.92)
	(envelope-from )
	id 1rnMO0-00071D-E5; Thu, 21 Mar 2024 17:39:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696553.1087566; Thu, 21 Mar 2024 17:39:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnMO0-000716-BI; Thu, 21 Mar 2024 17:39:28 +0000
Received: by outflank-mailman (input) for mailman id 696553;
 Thu, 21 Mar 2024 17:39:27 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1rnMNz-00070y-6f
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 17:39:27 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnMNt-0006oO-6C; Thu, 21 Mar 2024 17:39:21 +0000
Received: from gw1.octic.net ([88.97.20.152] helo=[10.0.1.240])
 by xenbits.xenproject.org with esmtpsa
 (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92)
 (envelope-from )
 id 1rnMNt-0007SE-0n; Thu, 21 Mar 2024 17:39:21 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=WjlG1/ZFIX5hlW4tsmLgEDxx/RinRxtOnJmQX5Ou/Mg=; b=3jryVX5RqLccj0I+Ie63QvUmvG
	r46SPrdyHo7n8SS/hvA80Q/At6tUzVBuFQkxjXb8nGGeZq8YeXnKeQ+BU1X1hb2At7iFYzIApdWyG
	33rbaR1ltT5RRNjaTLBJJOMk2wSxxYZIE/EUi1c+f3R1vYTW31r1SOcRRoM2B47mpOP0=;
Message-ID: 
Date: Thu, 21 Mar 2024 17:39:18 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 5/9] xen/device-tree: Move Arm's setup.c bootinfo
 functions to common
Content-Language: en-GB
To: Jan Beulich ,
 Shawn Anastasio 
Cc: tpearson@raptorengineering.com, Andrew Cooper
 , George Dunlap ,
 Stefano Stabellini , Wei Liu ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 "Daniel P. Smith" ,
 xen-devel@lists.xenproject.org
References: 
 <039524d4157dddb2faf6887739a727f6e993b53f.1710443965.git.sanastasio@raptorengineering.com>
 <152e76ee-6e75-4881-aa88-313f0ae058be@suse.com>
 <8adb6bf8-9804-4313-b1e1-5cf96d643d5e@raptorengineering.com>
 <98996023-f47c-45fd-b804-77440f333fc6@suse.com>
From: Julien Grall 
In-Reply-To: <98996023-f47c-45fd-b804-77440f333fc6@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Jan,

On 21/03/2024 07:42, Jan Beulich wrote:
> On 20.03.2024 19:07, Shawn Anastasio wrote:
>> On 3/15/24 4:16 AM, Jan Beulich wrote:
>>> On 14.03.2024 23:15, Shawn Anastasio wrote:
>>>> Arm's setup.c contains a collection of functions for parsing memory map
>>>> and other boot information from a device tree. Since these routines are
>>>> generally useful on any architecture that supports device tree booting,
>>>> move them into xen/common/device-tree.
>>>>
>>>> Suggested-by: Julien Grall 
>>>> Signed-off-by: Shawn Anastasio 
>>>> ---
>>>>   MAINTAINERS                       |   1 +
>>>>   xen/arch/arm/setup.c              | 419 --------------------------
>>>>   xen/common/Makefile               |   1 +
>>>>   xen/common/device-tree/Makefile   |   1 +
>>>>   xen/common/device-tree/bootinfo.c | 469 ++++++++++++++++++++++++++++++
>>>>   5 files changed, 472 insertions(+), 419 deletions(-)
>>>>   create mode 100644 xen/common/device-tree/Makefile
>>>>   create mode 100644 xen/common/device-tree/bootinfo.c
>>>>
>>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>>> index 56a6932037..e85fbe6737 100644
>>>> --- a/MAINTAINERS
>>>> +++ b/MAINTAINERS
>>>> @@ -301,6 +301,7 @@ M:	Stefano Stabellini 
>>>>   M:	Julien Grall 
>>>>   S:	Supported
>>>>   F:	xen/common/libfdt/
>>>> +F:	xen/common/device-tree/setup.c
>>>
>>> Perhaps more generally
>>>
>>> F:	xen/common/device-tree/
>>>
>>> ?
>>>
>>
>> This was done to allow bootfdt.c (next patch) to remain under ARM's
>> maintainership, which I believe was your suggestion in v2.
>>
>> Perhaps it would make sense to leave both setup.c and bootfdt.c under
>> ARM's maintainership, or would it be acceptable to move both to device
>> tree?
> 
> What exactly is wanted needs to be sorted by the maintainers (Arm / DT).
> To me, having everything DT under DT maintainership (which is a subset
> of Arm maintainers anyway) would make most sense.

I would say this should go under "Device Tree". So it will be easy to 
add PPC/RISC-V folks in the future.

I am also open to add Bertrand/Michal to the existing "Device Tree" 
category. But this can be sorted it out separately.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 17:47:26 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 17:47:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696561.1087575 (Exim 4.92)
	(envelope-from )
	id 1rnMVc-0000TU-8G; Thu, 21 Mar 2024 17:47:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696561.1087575; Thu, 21 Mar 2024 17:47:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnMVc-0000TN-5g; Thu, 21 Mar 2024 17:47:20 +0000
Received: by outflank-mailman (input) for mailman id 696561;
 Thu, 21 Mar 2024 17:47:19 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1rnMVb-0000TH-3p
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 17:47:19 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnMVa-0006yh-9p; Thu, 21 Mar 2024 17:47:18 +0000
Received: from gw1.octic.net ([88.97.20.152] helo=[10.0.1.240])
 by xenbits.xenproject.org with esmtpsa
 (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92)
 (envelope-from )
 id 1rnMVa-0007sP-1x; Thu, 21 Mar 2024 17:47:18 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=IR+QHsVGr8JdeqjgU7AzUzyn3zXONtccyiIU4l1cIKo=; b=1h4lN8JgBFW6Mjzk0WuueoX6Uw
	WUEdYqoZl3fkgPhMr43Dd70B20Bgkc0xfPzralkvWR436OlpQTj8eX37MX+OdTIJ0qFH7vEJTM+jb
	ZSwfFEg58v/AeCBPqTsqPnUyzULUPd+jR60VHoTw7EZ1ukHimi+dxWcPEfgzCfZ4/lcg=;
Message-ID: <19c4d0c2-c69c-4310-bf02-28d3894f8006@xen.org>
Date: Thu, 21 Mar 2024 17:47:15 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 5/9] xen/device-tree: Move Arm's setup.c bootinfo
 functions to common
Content-Language: en-GB
To: Shawn Anastasio ,
 xen-devel@lists.xenproject.org
Cc: tpearson@raptorengineering.com, Jan Beulich ,
 Andrew Cooper ,
 George Dunlap ,
 Stefano Stabellini , Wei Liu ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 "Daniel P. Smith" 
References: 
 <039524d4157dddb2faf6887739a727f6e993b53f.1710443965.git.sanastasio@raptorengineering.com>
From: Julien Grall 
In-Reply-To: <039524d4157dddb2faf6887739a727f6e993b53f.1710443965.git.sanastasio@raptorengineering.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Shawn,

On 14/03/2024 22:15, Shawn Anastasio wrote:
> Arm's setup.c contains a collection of functions for parsing memory map
> and other boot information from a device tree. Since these routines are
> generally useful on any architecture that supports device tree booting,
> move them into xen/common/device-tree.
> 
> Suggested-by: Julien Grall 
> Signed-off-by: Shawn Anastasio 
> ---
>   MAINTAINERS                       |   1 +
>   xen/arch/arm/setup.c              | 419 --------------------------
>   xen/common/Makefile               |   1 +
>   xen/common/device-tree/Makefile   |   1 +
>   xen/common/device-tree/bootinfo.c | 469 ++++++++++++++++++++++++++++++

The new bootinfo.c is exported quite a few functions. Please introduce
an generic header with the associated functions/structures.

[...]

> diff --git a/xen/common/Makefile b/xen/common/Makefile
> index e5eee19a85..3a39dd35f2 100644
> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -76,6 +76,7 @@ obj-$(CONFIG_UBSAN) += ubsan/
>   
>   obj-$(CONFIG_NEEDS_LIBELF) += libelf/
>   obj-$(CONFIG_HAS_DEVICE_TREE) += libfdt/
> +obj-$(CONFIG_HAS_DEVICE_TREE) += device-tree/
>   
>   CONF_FILE := $(if $(patsubst /%,,$(KCONFIG_CONFIG)),$(objtree)/)$(KCONFIG_CONFIG)
>   $(obj)/config.gz: $(CONF_FILE)
> diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile
> new file mode 100644
> index 0000000000..c97b2bd88c
> --- /dev/null
> +++ b/xen/common/device-tree/Makefile
> @@ -0,0 +1 @@
> +obj-y += bootinfo.o
> diff --git a/xen/common/device-tree/bootinfo.c b/xen/common/device-tree/bootinfo.c
> new file mode 100644
> index 0000000000..a6c0fe7917
> --- /dev/null
> +++ b/xen/common/device-tree/bootinfo.c
> @@ -0,0 +1,469 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +/*
> + * Derived from $xen/arch/arm/setup.c.
> + *
> + * Early device tree parsing and bookkeeping routines.
> + *
> + * Tim Deegan 
> + * Copyright (c) 2011 Citrix Systems.
> + * Copyright (c) 2024 Raptor Engineering LLC
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

setup.h seems duplicated. But this list of headers look suspiciously 
very long for the code you are moving. Can you look at reduce the number 
of includes?

Also, please take the opportunity to sort them out.

[...]

> +/*
> + * Populate the boot allocator.
> + * If a static heap was not provided by the admin, all the RAM but the
> + * following regions will be added:
> + *  - Modules (e.g., Xen, Kernel)
> + *  - Reserved regions
> + *  - Xenheap (arm32 only)
> + * If a static heap was provided by the admin, populate the boot
> + * allocator with the corresponding regions only, but with Xenheap excluded
> + * on arm32.
> + */
> +void __init populate_boot_allocator(void)
> +{
> +    unsigned int i;
> +    const struct meminfo *banks = &bootinfo.mem;
> +    paddr_t s, e;
> +
> +    if ( bootinfo.static_heap )
> +    {
> +        for ( i = 0 ; i < bootinfo.reserved_mem.nr_banks; i++ )
> +        {
> +            if ( bootinfo.reserved_mem.bank[i].type != MEMBANK_STATIC_HEAP )
> +                continue;
> +
> +            s = bootinfo.reserved_mem.bank[i].start;
> +            e = s + bootinfo.reserved_mem.bank[i].size;
> +#ifdef CONFIG_ARM_32

I think this wants to be replaced with #ifdef CONFIG_SEPARATE_XENHEAP 
same ...

> +            /* Avoid the xenheap, note that the xenheap cannot across a bank */
> +            if ( s <= mfn_to_maddr(directmap_mfn_start) &&
> +                 e >= mfn_to_maddr(directmap_mfn_end) )
> +            {
> +                init_boot_pages(s, mfn_to_maddr(directmap_mfn_start));
> +                init_boot_pages(mfn_to_maddr(directmap_mfn_end), e);
> +            }
> +            else
> +#endif
> +                init_boot_pages(s, e);
> +        }
> +
> +        return;
> +    }
> +
> +    for ( i = 0; i < banks->nr_banks; i++ )
> +    {
> +        const struct membank *bank = &banks->bank[i];
> +        paddr_t bank_end = bank->start + bank->size;
> +
> +        s = bank->start;
> +        while ( s < bank_end )
> +        {
> +            paddr_t n = bank_end;
> +
> +            e = next_module(s, &n);
> +
> +            if ( e == ~(paddr_t)0 )
> +                e = n = bank_end;
> +
> +            /*
> +             * Module in a RAM bank other than the one which we are
> +             * not dealing with here.
> +             */
> +            if ( e > bank_end )
> +                e = bank_end;
> +
> +#ifdef CONFIG_ARM_32

... here. This comment on top of the function would also need to be updated.

> +            /* Avoid the xenheap */
> +            if ( s < mfn_to_maddr(directmap_mfn_end) &&
> +                 mfn_to_maddr(directmap_mfn_start) < e )
> +            {
> +                e = mfn_to_maddr(directmap_mfn_start);
> +                n = mfn_to_maddr(directmap_mfn_end);
> +            }
> +#endif
> +
> +            fw_unreserved_regions(s, e, init_boot_pages, 0);
> +            s = n;
> +        }
> +    }
> +}
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * indent-tabs-mode: nil
> + * End:
> + */

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 17:50:41 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 17:50:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696564.1087589 (Exim 4.92)
	(envelope-from )
	id 1rnMYq-0002Kx-NG; Thu, 21 Mar 2024 17:50:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696564.1087589; Thu, 21 Mar 2024 17:50:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnMYq-0002Kq-K9; Thu, 21 Mar 2024 17:50:40 +0000
Received: by outflank-mailman (input) for mailman id 696564;
 Thu, 21 Mar 2024 17:50:39 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1rnMYp-0002Kk-Pf
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 17:50:39 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnMYp-00071p-8N; Thu, 21 Mar 2024 17:50:39 +0000
Received: from gw1.octic.net ([88.97.20.152] helo=[10.0.1.240])
 by xenbits.xenproject.org with esmtpsa
 (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92)
 (envelope-from )
 id 1rnMYp-0007wq-3T; Thu, 21 Mar 2024 17:50:39 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=1P3zCLTH2yN7EEJFWC9YGchWlVxdbo5LrNJcFyJFkKM=; b=ou4tTPW9hIbinF+nIdZds4EEWD
	96ysr73OQOYlfenbJ6n8CULfLQQpXxCTWKKdPIS9WL6wBLVX77K3gEe6jYTc8vdXSmauBscUSKE+Z
	1gl5/TM3FFtR3RRcI8mpZxzGJ0BokZDMTfjqngtVghfWuCFi2P0D7qrln1b4h4q9Rli8=;
Message-ID: <6069d3de-b298-46e6-a64b-895df3ea037b@xen.org>
Date: Thu, 21 Mar 2024 17:50:37 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 6/9] xen/common: Move Arm's bootfdt.c to common
Content-Language: en-GB
To: Shawn Anastasio ,
 xen-devel@lists.xenproject.org
Cc: tpearson@raptorengineering.com, Jan Beulich ,
 Andrew Cooper ,
 George Dunlap ,
 Stefano Stabellini , Wei Liu ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk 
References: 
 <908ea2d9bccf0b3455119cfd9af0597aee005fe8.1710443965.git.sanastasio@raptorengineering.com>
From: Julien Grall 
In-Reply-To: <908ea2d9bccf0b3455119cfd9af0597aee005fe8.1710443965.git.sanastasio@raptorengineering.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Shawn,

On 14/03/2024 22:15, Shawn Anastasio wrote:
> Move Arm's bootfdt.c to xen/common so that it can be used by other
> device tree architectures like PPC and RISCV.
> 
> Suggested-by: Julien Grall 
> Signed-off-by: Shawn Anastasio 
> Acked-by: Julien Grall 
> ---
> Changes in v2:
>    - Drop #if defined(CONFIG_ARM_EFI) now that efi_enabled is stubbed
> 
>   MAINTAINERS                                    | 1 +
>   xen/arch/arm/Makefile                          | 1 -
>   xen/common/device-tree/Makefile                | 1 +
>   xen/{arch/arm => common/device-tree}/bootfdt.c | 0
>   4 files changed, 2 insertions(+), 1 deletion(-)
>   rename xen/{arch/arm => common/device-tree}/bootfdt.c (100%)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e85fbe6737..20fdec9ffa 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -251,6 +251,7 @@ S:	Supported
>   L:	xen-devel@lists.xenproject.org
>   F:	docs/misc/arm/
>   F:	xen/arch/arm/
> +F:	xen/common/device-tree/bootfdt.c
>   F:	xen/drivers/char/arm-uart.c
>   F:	xen/drivers/char/cadence-uart.c
>   F:	xen/drivers/char/exynos4210-uart.c
> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
> index 7b1350e2ef..9e1548378c 100644
> --- a/xen/arch/arm/Makefile
> +++ b/xen/arch/arm/Makefile
> @@ -10,7 +10,6 @@ obj-$(CONFIG_TEE) += tee/
>   obj-$(CONFIG_HAS_VPCI) += vpci.o
> 
>   obj-$(CONFIG_HAS_ALTERNATIVE) += alternative.o
> -obj-y += bootfdt.init.o
>   obj-y += cpuerrata.o
>   obj-y += cpufeature.o
>   obj-y += decode.o
> diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile
> index c97b2bd88c..fa5beafd65 100644
> --- a/xen/common/device-tree/Makefile
> +++ b/xen/common/device-tree/Makefile
> @@ -1 +1,2 @@
> +obj-y += bootfdt.init.o
>   obj-y += bootinfo.o

Looking at the names, it is not entirely clear what would be the 
differences between bootfdt and bootinfo. Should they just be one file?

> diff --git a/xen/arch/arm/bootfdt.c b/xen/common/device-tree/bootfdt.c
> similarity index 100%
> rename from xen/arch/arm/bootfdt.c
> rename to xen/common/device-tree/bootfdt.c
> --
> 2.30.2
> 

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 17:53:45 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 17:53:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696566.1087599 (Exim 4.92)
	(envelope-from )
	id 1rnMbl-0003AO-3V; Thu, 21 Mar 2024 17:53:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696566.1087599; Thu, 21 Mar 2024 17:53:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnMbl-0003AH-0y; Thu, 21 Mar 2024 17:53:41 +0000
Received: by outflank-mailman (input) for mailman id 696566;
 Thu, 21 Mar 2024 17:53:39 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1rnMbj-0003AB-Sz
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 17:53:39 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnMbj-000762-0W; Thu, 21 Mar 2024 17:53:39 +0000
Received: from gw1.octic.net ([88.97.20.152] helo=[10.0.1.240])
 by xenbits.xenproject.org with esmtpsa
 (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92)
 (envelope-from )
 id 1rnMbi-00080B-QS; Thu, 21 Mar 2024 17:53:38 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=OeQPtn3PHVS5XG851Lm6+5d9UE8MUvnCNC6e7BaEiQo=; b=ZCr/rUdyD8KXABiqxhcly71a4d
	IG/emCoRQ1ALU86zMEwEl7priW4FUjmFX2QMetKcIReMfwuwJhlXDLsoyNIsEfhsXNOCCfoIvbnq5
	zqW6oYQ7aij9BtepDtw52U+UhKJx24cumSiRsOpOmQ/tFnipaPSZ7Ag0yax/m7jaHFFs=;
Message-ID: <3a3550a2-743f-4fda-8b15-70545d820f56@xen.org>
Date: Thu, 21 Mar 2024 17:53:36 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 5/9] xen/device-tree: Move Arm's setup.c bootinfo
 functions to common
Content-Language: en-GB
To: Shawn Anastasio ,
 xen-devel@lists.xenproject.org
Cc: tpearson@raptorengineering.com, Jan Beulich ,
 Andrew Cooper ,
 George Dunlap ,
 Stefano Stabellini , Wei Liu ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 "Daniel P. Smith" 
References: 
 <039524d4157dddb2faf6887739a727f6e993b53f.1710443965.git.sanastasio@raptorengineering.com>
From: Julien Grall 
In-Reply-To: <039524d4157dddb2faf6887739a727f6e993b53f.1710443965.git.sanastasio@raptorengineering.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

On 14/03/2024 22:15, Shawn Anastasio wrote:
> diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile
> new file mode 100644
> index 0000000000..c97b2bd88c
> --- /dev/null
> +++ b/xen/common/device-tree/Makefile
> @@ -0,0 +1 @@
> +obj-y += bootinfo.o

AFAICT everything in the new file is in init. So if you decide to keep 
it (see my comment on patch #6), then this should be "bootinfo.init.o" 
so the build system can check that all functions/data will live in init.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 18:00:24 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 18:00:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696571.1087608 (Exim 4.92)
	(envelope-from )
	id 1rnMiB-0005Ta-Oy; Thu, 21 Mar 2024 18:00:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696571.1087608; Thu, 21 Mar 2024 18:00:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnMiB-0005TT-MV; Thu, 21 Mar 2024 18:00:19 +0000
Received: by outflank-mailman (input) for mailman id 696571;
 Thu, 21 Mar 2024 18:00:18 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rnMi9-0005TN-QC
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 18:00:17 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id de69670f-e7ac-11ee-a1ee-f123f15fe8a2;
 Thu, 21 Mar 2024 19:00:15 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 5CE6D61217;
 Thu, 21 Mar 2024 18:00:13 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id C4702C433C7;
 Thu, 21 Mar 2024 18:00:11 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: de69670f-e7ac-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1711044013;
	bh=bIZxfWqmwJx/0DvvPek3iesJmNfFQbqii/uhtbdnHII=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=HHFHvrRl6GDIjzXb8oV0JVZ+Q8RKL/nuFC8XTusudRI+9lT1DCPvYifoKNZUAB3p+
	 wOqSicZHN13NZRWme32NhKSE0EVU6nChqN3lrqrSBHuMIu/9SRQii7HNrdxaq+Ig4B
	 ynEweg354WqwbE+pP0flxOOM53MrULpn7k9nsadgz0auK3ZtX6nYJ019hFHVw7+Bi4
	 ZPjSwXT4KFiUqd9gJ2gmchcFBY86yb1DJxsXXj2a7bvrWrPbZwnB/6uJSvyYzEjLrr
	 MoVa2kB+rORS5U59Dwp8xLvOUcsF0zrF77/M3dsZRUuNNqjKuu0KE+Q4Gwp8BJUsi9
	 nBWCqfuEQmp7Q==
Date: Thu, 21 Mar 2024 11:00:10 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich 
cc: Stefano Stabellini , 
    Simone Ballarin , consulting@bugseng.com, 
    Doug Goldstein , 
    Andrew Cooper , 
    George Dunlap , Julien Grall , 
    Wei Liu , xen-devel@lists.xenproject.org
Subject: Re: [XEN PATCH 1/2] automation/eclair: add deviation for MISRA C:2012
 Rule 17.1
In-Reply-To: 
Message-ID: 
References:  <882b442c8c1f73f8116676ab9351defe5c9609ac.1710923235.git.simone.ballarin@bugseng.com> <9341a711-74c3-463f-8cc2-a54e19b4b2f4@suse.com> 
 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Thu, 21 Mar 2024, Jan Beulich wrote:
> On 21.03.2024 02:50, Stefano Stabellini wrote:
> > On Wed, 20 Mar 2024, Jan Beulich wrote:
> >> On 20.03.2024 09:50, Simone Ballarin wrote:
> >>> MISRA C:2012 Rule 17.1 states:
> >>> The features of `' shall not be used
> >>>
> >>> The Xen community wants to avoid using variadic functions except for
> >>> specific circumstances where it feels appropriate by strict code review.
> >>>
> >>> Add deviation for functions related to console output (printk and similar).
> >>>
> >>> Signed-off-by: Simone Ballarin 
> >>> ---
> >>>  .../eclair_analysis/ECLAIR/deviations.ecl     | 26 +++++++++++++++++++
> >>>  docs/misra/deviations.rst                     |  5 ++++
> >>>  2 files changed, 31 insertions(+)
> >>>
> >>> diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
> >>> index 9ac3ee4dfd..7c3559a3a0 100644
> >>> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> >>> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> >>> @@ -382,6 +382,32 @@ explicit comment indicating the fallthrough intention is present."
> >>>  -config=MC3R1.R16.6,switch_clauses+={deliberate, "default(0)"}
> >>>  -doc_end
> >>>  
> >>> +#
> >>> +# Series 17.
> >>> +#
> >>> +
> >>> +-doc_begin="Functions related to console output are allowed to use the variadic features provided by stdarg.h."
> >>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(debugtrace_printk)&&kind(function))))"}
> >>
> >> This isn't concole output related.
> > 
> > Should we say "related to console output or tracing" ?
> > 
> > 
> >>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(dt_dprintk)&&kind(function))))"}
> >>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(printk)&&kind(function))))"}
> >>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(guest_printk)&&kind(function))))"}
> >>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(panic)&&kind(function))))"}
> >>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(dprintk)&&kind(function))))"}
> >>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(gdprintk)&&kind(function))))"}
> >>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(snprintf)&&kind(function))))"}
> >>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(scnprintf)&&kind(function))))"}
> >>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(xasprintf)&&kind(function))))"}
> >>
> >> These three and ...
> >>
> >>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(mm_printk)&&kind(function))))"}
> >>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(dbgp_printk)&&kind(function))))"}
> >>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(elf_call_log_callback)&&kind(function))))"}
> >>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(vsnprintf)&&kind(function))))"}
> >>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(vscnprintf)&&kind(function))))"}
> >>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(xvasprintf)&&kind(function))))"}
> >>
> >> ... these three aren't either.
> > 
> > Maybe it is better to write it as:
> > 
> > "Functions related printk, logging and tracing are allowed..."
> 
> How about simply saying "printf()-like functions"? In what you suggest,
> sprintf() and friends would still not be covered.

I like it


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 18:03:18 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 18:03:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696575.1087623 (Exim 4.92)
	(envelope-from )
	id 1rnMl2-00064E-9R; Thu, 21 Mar 2024 18:03:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696575.1087623; Thu, 21 Mar 2024 18:03:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnMl2-000647-4b; Thu, 21 Mar 2024 18:03:16 +0000
Received: by outflank-mailman (input) for mailman id 696575;
 Thu, 21 Mar 2024 18:03:15 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1rnMl0-000641-Vr
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 18:03:15 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnMl0-0007N0-As; Thu, 21 Mar 2024 18:03:14 +0000
Received: from gw1.octic.net ([88.97.20.152] helo=[10.0.1.240])
 by xenbits.xenproject.org with esmtpsa
 (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92)
 (envelope-from )
 id 1rnMl0-0000J2-3g; Thu, 21 Mar 2024 18:03:14 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=lNNGrCXeJaRUT19jrx8oQBBUBWHZ6cVfX+QhAvyBrB0=; b=ECTqHKzcnQquQj5LXv+ike60hf
	5qrqNpEUc2aTdbfUj8lF/1dH2K6G3bwmdb8QQgxoS43bLKZVKuL4tWhs1KUtTG2WwMk818CObpTcb
	9FR4KupxfpXEOIvKQNtOSvukEWFVsZPFj5187WjG+Icqs5uupCt9gQY5X3IleZQfeD0Y=;
Message-ID: <34e40b31-632a-46a5-94ad-768fe928d410@xen.org>
Date: Thu, 21 Mar 2024 18:03:12 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 7/9] xen/ppc: Enable bootfdt and boot allocator
Content-Language: en-GB
To: Shawn Anastasio ,
 xen-devel@lists.xenproject.org
Cc: tpearson@raptorengineering.com, Jan Beulich ,
 Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk 
References: 
 
From: Julien Grall 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Shawn,

On 14/03/2024 22:15, Shawn Anastasio wrote:
> Enable usage of bootfdt for populating the boot info struct from the
> firmware-provided device tree.  Also enable the Xen boot page allocator.
> 
> Includes minor changes to bootfdt.c's boot_fdt_info() to tolerate the
> scenario in which the FDT overlaps a reserved memory region, as is the
> case on PPC when booted directly from skiboot.
> 
> Signed-off-by: Shawn Anastasio 
> ---
>   xen/arch/ppc/include/asm/setup.h |  5 +++++
>   xen/arch/ppc/setup.c             | 21 ++++++++++++++++++++-
>   xen/common/device-tree/bootfdt.c | 11 +++++++++--
>   3 files changed, 34 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/arch/ppc/include/asm/setup.h b/xen/arch/ppc/include/asm/setup.h
> index 1b2d29c5b6..fe27f61fc3 100644
> --- a/xen/arch/ppc/include/asm/setup.h
> +++ b/xen/arch/ppc/include/asm/setup.h
> @@ -115,4 +115,9 @@ const char *boot_module_kind_as_string(bootmodule_kind kind);
>   struct bootcmdline *boot_cmdline_find_by_kind(bootmodule_kind kind);
>   void populate_boot_allocator(void);
>   
> +/*
> + * bootfdt.c
> + */
> +size_t boot_fdt_info(const void *fdt, paddr_t paddr);
> +
This function is common. So the prototype doesn't belong to a per-arch 
header.

>   #endif /* __ASM_PPC_SETUP_H__ */
> diff --git a/xen/arch/ppc/setup.c b/xen/arch/ppc/setup.c
> index 101bdd8bb6..946167a56f 100644
> --- a/xen/arch/ppc/setup.c
> +++ b/xen/arch/ppc/setup.c
> @@ -1,12 +1,14 @@
>   /* SPDX-License-Identifier: GPL-2.0-or-later */
>   #include 
>   #include 
> +#include 

None of the code below doesn't seem to use libfdt.h directly. So why do 
you need it?

>   #include 
>   #include 
>   #include 
>   #include 
>   #include 
>   #include 
> +#include 
>   
>   /* Xen stack for bringing up the first CPU. */
>   unsigned char __initdata cpu0_boot_stack[STACK_SIZE] __aligned(STACK_SIZE);
> @@ -24,6 +26,9 @@ void __init noreturn start_xen(unsigned long r3, unsigned long r4,
>                                  unsigned long r5, unsigned long r6,
>                                  unsigned long r7)
>   {
> +    void *boot_fdt;
boot_fdt is not meant to be modified. So this should be const.

> +    struct bootmodule *xen_bootmodule;

Same here I guess.

> +
>       if ( r5 )
>       {
>           /* Unsupported OpenFirmware boot protocol */
> @@ -32,11 +37,25 @@ void __init noreturn start_xen(unsigned long r3, unsigned long r4,
>       else
>       {
>           /* kexec boot protocol */
> -        boot_opal_init((void *)r3);
> +        boot_fdt = (void *)r3;
> +        boot_opal_init(boot_fdt);
>       }
>   
>       setup_exceptions();
>   
> +    device_tree_flattened = boot_fdt;
> +    boot_fdt_info(boot_fdt, r3);
> +
> +    /*
> +     * Xen relocates itself at the ppc64 entrypoint, so we need to manually mark
> +     * the kernel module.
> +     */
> +    xen_bootmodule = add_boot_module(BOOTMOD_XEN, __pa(_start),
> +                                     PAGE_ALIGN(__pa(_end)), false);
> +    BUG_ON(!xen_bootmodule);
> +
> +    populate_boot_allocator();
> +
>       setup_initial_pagetables();
>   
>       early_printk("Hello, ppc64le!\n");
> diff --git a/xen/common/device-tree/bootfdt.c b/xen/common/device-tree/bootfdt.c
> index 35dbdf3384..1985648b31 100644
> --- a/xen/common/device-tree/bootfdt.c
> +++ b/xen/common/device-tree/bootfdt.c
> @@ -543,12 +543,19 @@ size_t __init boot_fdt_info(const void *fdt, paddr_t paddr)
>       if ( ret < 0 )
>           panic("No valid device tree\n");
>   
> -    add_boot_module(BOOTMOD_FDT, paddr, fdt_totalsize(fdt), false);
> -
>       ret = device_tree_for_each_node(fdt, 0, early_scan_node, NULL);
>       if ( ret )
>           panic("Early FDT parsing failed (%d)\n", ret);
>   
> +    /*
> +     * Add module for the FDT itself after the device tree has been parsed. This
> +     * is required on ppc64le where the device tree passed to Xen may have been
> +     * allocated by skiboot, in which case it will exist within a reserved
> +     * region and this call will fail. This is fine, however, since either way
> +     * the allocator will know not to step on the device tree.
> +     */
> +    add_boot_module(BOOTMOD_FDT, paddr, fdt_totalsize(fdt), false);

I am still a little bit concerned with this change. If there is an 
overlap, then BOOTMOD_FDT will not be created yet Xen will continue. I 
think this needs to be explained in the commit message and in the code 
(maybe on top of BOOTMOD_FDT which should be common). So it will be 
clearer that we cannot rely on BOOTMOD_FDT.

Also, there was some recent discussion for MISRA to check all return or 
use (void) + a comment to explain this is ignored. I think you have part 
of the explanation (see above for the second part), but I would also add 
(void) to make clear this was on purpose.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 19:04:13 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 19:04:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696581.1087632 (Exim 4.92)
	(envelope-from )
	id 1rnNhp-0007w5-NE; Thu, 21 Mar 2024 19:04:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696581.1087632; Thu, 21 Mar 2024 19:04:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnNhp-0007vy-Jl; Thu, 21 Mar 2024 19:04:01 +0000
Received: by outflank-mailman (input) for mailman id 696581;
 Thu, 21 Mar 2024 19:04:00 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rnNho-0007vs-OD
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 19:04:00 +0000
Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c3b8499b-e7b5-11ee-a1ee-f123f15fe8a2;
 Thu, 21 Mar 2024 20:03:57 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sin.source.kernel.org (Postfix) with ESMTP id 8D2B7CE106A;
 Thu, 21 Mar 2024 19:03:51 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9A9E2C433F1;
 Thu, 21 Mar 2024 19:03:49 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c3b8499b-e7b5-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1711047830;
	bh=jmL5Y8dodgZCqk/gHCWpvwkkoZDvOziKdczegnst7wc=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=ZF3VF09A9utMu+igH1EGSXTs/nE3efMLKLwk4YYfj7nTzfI2p7L6hPccJlQmKv3q+
	 a8J7VmL8sVlVG+WMTxGKdiFYhNQniPHittOq0gpLn24NuL+t0NZZyQHOkgcYgWiDus
	 HOW0Z6yMQMJG0PxMnVFMi0NIBk/nchx8vvjcM0DSp48kfshlVY9AwE9AKqPXm1bV8X
	 EeXpCzMMcrNF5sjM1eAZFAQ8NzA7s6hfQwZCuLr/GeCvo9k+Cjfk+jI12uaKVSPXFX
	 YhTxr56/SwIKc0GBJj3PiFi/kwc8t+VkGoBhwzP2PF9gakCK5sqBt5TailJ5drQ+yt
	 7jiAdQr5m1Rfg==
Date: Thu, 21 Mar 2024 12:03:48 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich 
cc: Stefano Stabellini , andrew.cooper3@citrix.com, 
    bertrand.marquis@arm.com, george.dunlap@citrix.com, julien@xen.org, 
    michal.orzel@amd.com, roger.pau@citrix.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2] docs/misra: document the expected sizes of integer
 types
In-Reply-To: <198bade8-c6fc-4ae0-b721-3a9e2bd8acbe@suse.com>
Message-ID: 
References:  <6a76723e-ba47-40b3-8f33-d68030b14299@suse.com>  <7ab73379-b057-4568-9869-141cef185752@suse.com>
    <87234837-9fb3-40a9-849d-8b8574f2661c@suse.com>
  <198bade8-c6fc-4ae0-b721-3a9e2bd8acbe@suse.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Thu, 21 Mar 2024, Jan Beulich wrote:
> On 21.03.2024 02:46, Stefano Stabellini wrote:
> > On Wed, 20 Mar 2024, Jan Beulich wrote:
> >>> - the public interface is described in a C header so it makes sense for
> >>>   the corresponding implementation to be in C
> >>>
> >>> - the C entry point is often both the entry point in C and also common
> >>>   code
> >>>
> >>> - depending on the architecture, there is typically always some minimal
> >>>   assembly entry code to prepare the environment before we can jump into
> >>>   C-land; still one wouldn't consider those minimal and routine assembly
> >>>   operations to be a meaningful hypercall entry point corresponding to
> >>>   the C declaration in the public headers
> >>>
> >>> - as per MISRA and also general good practice, we need the declaration
> >>>   in the public header files to match the definition in C
> >>
> >> Throughout, but especially with this last point, I feel there's confusion
> >> (not sure on which side): There are no declarations of hypercall functions
> >> in the public headers. Adding declarations there for the C entry points in
> >> Xen would actually be wrong, as we don't provide such functions anywhere
> >> (to consumers of the ABI).
> > 
> > I am copy/pasting text from sched.h:
> > 
> >  * The prototype for this hypercall is:
> >  * ` long HYPERVISOR_sched_op(enum sched_op cmd, void *arg, ...)
> >  *
> >  * @cmd == SCHEDOP_??? (scheduler operation).
> >  * @arg == Operation-specific extra argument(s), as described below.
> >  * ...  == Additional Operation-specific extra arguments, described below.
> >  *
> > 
> > from event_channel.h:
> > 
> >  * ` enum neg_errnoval
> >  * ` HYPERVISOR_event_channel_op(enum event_channel_op cmd, void *args)
> >  * `
> >  * @cmd  == EVTCHNOP_* (event-channel operation).
> >  * @args == struct evtchn_* Operation-specific extra arguments (NULL if none).
> > 
> > These are the hypercall declarations in public headers. Although they
> > are comments, they are the only description of the ABI that we have (as
> > far as I know). They are in C and use C types. 
> 
> >From their use of enum alone they don't qualify as declarations. They're
> imo merely meant to provide minimal guidelines.

Even if we call them "minimal guidelines", my opinion is unchanged:
- they need to use fixed-width types
- they should match the C hypercall entry point types


> >>>>>>> We have two options:
> >>>>>>>
> >>>>>>> 1) we go with this document, and we clarify that even if we specify
> >>>>>>>   "unsigned int", we actually mean a 32-bit integer
> >>>>>>>
> >>>>>>> 2) we change all our public ABIs and C hypercall entry points to use
> >>>>>>>    fixed-size types (e.g. s/unsigned int/uint32_t/g)
> >>>>>>>
> >>>>>>> 2) is preferred because it is clearer but it is more work. So I went
> >>>>>>> with 1). I also thought you would like 1) more.
> >>>>>>
> >>>>>> For ABIs (i.e. structures) we ought to be making that change anyway.
> >>>>>> Leaving basic types in there is latently buggy.
> >>>>>
> >>>>> I am glad we agree :-)
> >>>>>
> >>>>> It is just that I also consinder the C hypercall entry points as part of
> >>>>> the ABI
> >>>>>
> >>>>>
> >>>>>> I'm happy to see a document like this added, for the purpose described
> >>>>>> above. But to me 1) and 2) and largely independent of one another.
> >>>>>
> >>>>> Good that you are also happy with a document like this.
> >>>>>
> >>>>> The remaining question is: what about the rest of the C functions in Xen
> >>>>> that are certainly not part of an ABI?
> >>>>
> >>>> As per above - anything internal isn't part of the ABI, C entry points
> >>>> for hypercall handlers included. All we need to ensure is that we consume
> >>>> the data according to what the ABI sets forth.
> >>>
> >>> It doesn't look like we'll convince one another on this point. But let
> >>> me try another way.
> >>>
> >>> In my view, having mismatched types between declaration and definition
> >>> and having non-fixed-width types in C hypercall entry points is really
> >>> bad for a number of reasons, among them:
> >>> - correctness
> >>> - risk of ABI breakage
> >>> - mismatch of declaration and definition
> >>
> >> What mismatches are you talking about? There's nothing mismatched now,
> >> and there cannot be any mismatch, because the consumers of the ABI don't
> >> call Xen functions directly.
> > 
> > Let me make an example:
> > 
> > - public header saying enum event_channel_op cmd
> > - 
> > - do_event_channel_op(int cmd, ...)
> > 
> > Do you think this is all good?
> > 
> > There are two pretty serious problems here:
> > - enum and int are not the same type
> 
> See above. The issue I have with this is use of plain "int". Technically
> that's not a problem either, but aiui we're aiming to use "unsigned int"
> when negative values aren't possible.

Yeah that is also a problem


> And note that it was in 2012 when "int" there was changed to "enum", in an
> effort to document things better.
> 
> > - enum and int are not fixed-width
> 
> Which I don't view as a problem, thanks to the assembly sitting in between.

I disagree. I view this as risky and error prone. We worked for hours
and hours on security issues and MISRA improvements. All this experience
is also meant to teach us what good code looks like, code that is
resilient to attacks, poses fewer safety issues, and it is clearer for
others to read and modify. After all of the above, I am surprised we are
not aligned on this issue.

I understand your point of view, as I think you understand mine. We are
not going to be able to convince each other. Having explored the
technical aspects in all their details, I think we need more opinions
from others to move forward.

I'll conclude with this. One doesn't have to agree with me to agree
that the suggestions I am making are to make the code and public
interfaces, clearer, more consistent, less error prone. Your suggestions
are to make the code follow CODING_STYLE? I made it clear the value
proposition of what I am suggesting and I fail to see yours.


> > Don't you think it should be:
> > 
> > - public header saying uint32_t cmd in a comment
> > - 
> > - do_something_op(uint32_t cmd, ...)
> 
> The public header should say whatever is best suited to not misguide
> people writing actual prototypes for their functions. I wouldn't mind
> uint32_t being stated there. That has no influence whatsoever on
> do__op(), though.

I understand what you are saying but I disagree. It is risky and error
prone. As above, I think we understand each other's points of view but
we won't be able to convince each other.


> > Or possibly unsigned long depending on the parameter.
> 
> You're contradicting yourself: You mean to advocate for fixed-width types,
> yet then you suggest "unsigned long".

No. I explained it in another thread a couple of days ago. There are
cases where we have fixed-width types but the type changes by
architecture: 32-bit for 32-bit archs and 64-bit for 64-bit archs.
Rather than having #ifdefs, which is also an option, that is the one
case where using "unsigned long" could be a decent compromise. In this
context "unsigned long" means register size (on ARM we even have
register_t). Once you pick an architecture, the size is actually meant
to be fixed. In fact, it is specified in this document. Which is one of
the reasons why we have to use == in this document and not >=. In
general, fixed-width types like uint32_t are better because they are
clearer and unambiguous. When possible I think they should be our first
choice in ABIs.


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 19:54:51 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 19:54:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696588.1087648 (Exim 4.92)
	(envelope-from )
	id 1rnOUu-00072q-GD; Thu, 21 Mar 2024 19:54:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696588.1087648; Thu, 21 Mar 2024 19:54:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnOUu-00072j-D3; Thu, 21 Mar 2024 19:54:44 +0000
Received: by outflank-mailman (input) for mailman id 696588;
 Thu, 21 Mar 2024 19:54:42 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rnOUs-00072d-It
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 19:54:42 +0000
Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com
 [2a00:1450:4864:20::435])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id daee05f8-e7bc-11ee-afe0-a90da7624cb6;
 Thu, 21 Mar 2024 20:54:41 +0100 (CET)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-33ec7e38b84so849526f8f.1
 for ; Thu, 21 Mar 2024 12:54:41 -0700 (PDT)
Received: from gmail.com (1F2EF04C.nat.pool.telekom.hu. [31.46.240.76])
 by smtp.gmail.com with ESMTPSA id
 r29-20020adfa15d000000b0033e79eca6dfsm355492wrr.50.2024.03.21.12.54.38
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 21 Mar 2024 12:54:39 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
X-Inumbo-ID: daee05f8-e7bc-11ee-afe0-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1711050880; x=1711655680; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:sender
         :from:to:cc:subject:date:message-id:reply-to;
        bh=jDZlJEtHFIm6Gl+7kSgG5qWF5bEblRoSU2T4MYJXNV8=;
        b=EW8rarvBglu1xrwkE7mqrjqX4R7kZJzdboMynl0sedgyabvnpqltSBY4fQ/nb2pCRu
         9Bg2ttev4zemXxO+Ds1Kq3odpdoeTAT4AAG11RHECHaACGKCCPNs03+4D6Mk/KGBOsO5
         cb8jq+9Td0Qhhv1yZo9rjiRgomkteMxqCYB7AmJcDewzgA7aOUP04IPZjaTw1ejC3Fiw
         QnR/SdrSGi2S0sKM13inW4SDrHubWXxruBeA0u7upCoxSFTZmZoSt1hildFlOTWWazNc
         foExE6PsxCYwOu2lU7FDptO0yTMB6JYK/emqc+J1cCKfR58jCPDT3Bf14y8DYHeQOzon
         uH/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711050880; x=1711655680;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:sender
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=jDZlJEtHFIm6Gl+7kSgG5qWF5bEblRoSU2T4MYJXNV8=;
        b=HlayWdz5M/Zy/SuDAZshvyxnZxzJ0uujz1QdKp17H0IhQHDNkck3tr6XhD7BWA9BBy
         YRRZvRy0venIl7cKa8ZP1929eVse+ie0ISYntnWdg6sSf7RA3/8yUobRAoWHtGca0C/w
         fZ9G66s3E0o1i+5CIaS409ZFX6NyZ35dAkZ2ihz4hZ9lW/Pou4VYQKa5AmbKbdMqOCUu
         L5JwIZ+VtW8SP4Lhckq+qEKDtxpn/wsLMbBfon3epIXXNX9Ks27mki3cY2oDd+Osag9a
         vx0rjAAcPFAh9Fruh503tDkqyhonlJdSD/hGLYFVF+0iBzYQ5ONsyN/MmfQOQRwuVtD2
         eaew==
X-Forwarded-Encrypted: i=1; AJvYcCUtsXRZkmj4zlyKpe90ob1Mh1tA9aSW/WGIDV2U/72GGGFqr2jCN+ge/wcCkXc0QwJkI4JR2pPG0VUrjt9QdQSZjx6o3kfA+ZrW/wUg92g=
X-Gm-Message-State: AOJu0Yx0ZNPfDVKqzl6yK3QvCviLtvSHZb8eh3Y0Ipp10ooHN9i0WHxM
	lLiMVGc0rOiM/N3q+/rL30E7VwJje8gJDNpqk8alrp63H8cJWq8n
X-Google-Smtp-Source: AGHT+IEOclJy/CKjgZg3kBSaqvyZWV4BNEYGoWmUbWBMk90pFzsmw4VkSdit7UdC6gAJ/ZWAiox1gg==
X-Received: by 2002:a05:6000:1843:b0:33d:c657:6ae3 with SMTP id c3-20020a056000184300b0033dc6576ae3mr125312wri.7.1711050879879;
        Thu, 21 Mar 2024 12:54:39 -0700 (PDT)
Sender: Ingo Molnar 
Date: Thu, 21 Mar 2024 20:54:37 +0100
From: Ingo Molnar 
To: "Xin Li (Intel)" 
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
	linux-arch@vger.kernel.org, tglx@linutronix.de, mingo@redhat.com,
	bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org,
	hpa@zytor.com, jgross@suse.com, boris.ostrovsky@oracle.com,
	arnd@arndb.de, Brian Gerst 
Subject: Re: [PATCH v2 1/1] x86: Rename __{start,end}_init_task to
 __{start,end}_init_stack
Message-ID: 
References: <20240318071429.910454-1-xin@zytor.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20240318071429.910454-1-xin@zytor.com>


* Xin Li (Intel)  wrote:

> The stack of a task has been separated from the memory of a task_struct
> struture for a long time on x86, as a result __{start,end}_init_task no
> longer mark the start and end of the init_task structure, but its stack
> only.
> 
> Rename __{start,end}_init_task to __{start,end}_init_stack.
> 
> Note other architectures are not affected because __{start,end}_init_task
> are used on x86 only.
> 
> Signed-off-by: Xin Li (Intel) 
> ---
> 
> Change since v1:
> * Revert an accident insane change, init_task to init_stack (Jrgen Gro).
> ---
>  arch/x86/include/asm/processor.h  | 4 ++--
>  arch/x86/kernel/head_64.S         | 2 +-
>  arch/x86/xen/xen-head.S           | 2 +-
>  include/asm-generic/vmlinux.lds.h | 6 +++---
>  4 files changed, 7 insertions(+), 7 deletions(-)

Note that this is now in conflict with this cleanup by Brian Gerst:

   2cb16181a1d1 x86/boot: Simplify boot stack setup

... which removed __end_init_task[] entirely.

Thanks,

	Ingo


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 20:50:30 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 20:50:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696599.1087664 (Exim 4.92)
	(envelope-from )
	id 1rnPMd-00075u-IB; Thu, 21 Mar 2024 20:50:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696599.1087664; Thu, 21 Mar 2024 20:50:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnPMd-00075n-Ej; Thu, 21 Mar 2024 20:50:15 +0000
Received: by outflank-mailman (input) for mailman id 696599;
 Thu, 21 Mar 2024 20:50:13 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnPMb-00075d-MC; Thu, 21 Mar 2024 20:50:13 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnPMb-0002H3-Fu; Thu, 21 Mar 2024 20:50:13 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnPMb-0006Nd-5b; Thu, 21 Mar 2024 20:50:13 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rnPMb-00019m-58; Thu, 21 Mar 2024 20:50:13 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=PEy6MgaO0ZdvO/Ijsnm7AfWRVOvAvzXM0HJxjh2fSx8=; b=6od974gzjEEjYEWwCnZqx4XCaO
	mvXI4/a1RLqsYvguOr9PzuwlfomxyJqj6PKlaANP4raWw0DlGWc7Z3FCNCtV+loPeIiGzXvjzrJvG
	3Yvh9290FZ1bz1YMYAjlbEDYd7XygANnJ35tWzyQ3uKzPcLpG4dM8kHVPn+N3lXjvj1k=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 185119: tolerable FAIL - PUSHED
X-Osstest-Failures:
    linux-linus:test-armhf-armhf-xl-multivcpu:xen-boot:fail:heisenbug
    linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-qcow2:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-qcow2:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-vhd:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-raw:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
X-Osstest-Versions-This:
    linux=23956900041d968f9ad0f30db6dede4daccd7aa9
X-Osstest-Versions-That:
    linux=a4145ce1e7bc247fd6f2846e8699473448717b37
From: osstest service owner 
Date: Thu, 21 Mar 2024 20:50:13 +0000

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-multivcpu  8 xen-boot           fail pass in 185134-retest

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-multivcpu 15 migrate-support-check fail in 185134 never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-check fail in 185134 never pass
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop            fail like 185114
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop            fail like 185114
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop            fail like 185114
 test-armhf-armhf-libvirt     16 saverestore-support-check    fail  like 185114
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop            fail like 185114
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 185114
 test-amd64-amd64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          16 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qcow2 14 migrate-support-check        fail never pass
 test-amd64-amd64-libvirt-raw 14 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-raw 14 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-raw 15 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt     15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-qcow2    14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-qcow2    15 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-vhd      14 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-vhd      15 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-vhd 14 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-vhd 15 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-raw      14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-raw      15 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass
 test-armhf-armhf-xl-credit2  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     16 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     15 migrate-support-check        fail   never pass

version targeted for testing:
 linux                23956900041d968f9ad0f30db6dede4daccd7aa9
baseline version:
 linux                a4145ce1e7bc247fd6f2846e8699473448717b37

Last test of basis   185114  2024-03-20 14:09:37 Z    1 days
Testing same since   185119  2024-03-21 07:40:49 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  "Nícolas F. R. A. Prado" 
  Colin Ian King 
  Daniel Bristot de Oliveira 
  Jonathan Corbet 
  Kendra Moore 
  Linus Torvalds 
  Maki Hatano 
  Marios Makassikis 
  Namjae Jeon 
  Nícolas F. R. A. Prado 
  Steve French 
  Thorsten Leemhuis 

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-libvirt-qcow2                               pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-xl-qcow2                                    pass    
 test-amd64-amd64-libvirt-raw                                 pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-amd64-amd64-xl-raw                                      pass    
 test-armhf-armhf-xl-raw                                      pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-libvirt-vhd                                 pass    
 test-amd64-amd64-xl-vhd                                      pass    
 test-arm64-arm64-xl-vhd                                      pass    


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

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

Explanation of these 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 :

hint: The 'hooks/update' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
hint: The 'hooks/post-receive' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
hint: The 'hooks/post-update' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
To xenbits.xen.org:/home/xen/git/linux-pvops.git
   a4145ce1e7bc..23956900041d  23956900041d968f9ad0f30db6dede4daccd7aa9 -> tested/linux-linus


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 21:24:48 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 21:24:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696608.1087674 (Exim 4.92)
	(envelope-from )
	id 1rnPty-00036j-7R; Thu, 21 Mar 2024 21:24:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696608.1087674; Thu, 21 Mar 2024 21:24:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnPty-00036c-3B; Thu, 21 Mar 2024 21:24:42 +0000
Received: by outflank-mailman (input) for mailman id 696608;
 Thu, 21 Mar 2024 21:24:40 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnPtw-00036S-5b; Thu, 21 Mar 2024 21:24:40 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnPtv-0002wE-Sd; Thu, 21 Mar 2024 21:24:39 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnPtv-0007FZ-Io; Thu, 21 Mar 2024 21:24:39 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rnPtv-0004ul-IO; Thu, 21 Mar 2024 21:24:39 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=Jb0fIsRBIE2usTYfplSee49mYQ4GhWvaEYJfgShSy/k=; b=tl6qn1+P83kvQGYMBBJjszHFal
	AWziFSNsMkIDIgNWuAlPZtH0U/3+vy6yHtGup9kp5AlbOQ6wK0NAbnxGE0wYE+kswjpFTK0Dt4GOS
	Q1A4+7INsC9JbrYapGw1Z4ctJmk0Yc3jPHxO+LP8DkvZkCUm9VsgdGykpUxG10IIziRA=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 185132: tolerable all pass - PUSHED
X-Osstest-Failures:
    xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    xen=cbe393b709e0c6c3e2b10c3ac69fbea0abd530fe
X-Osstest-Versions-That:
    xen=eaafbd11344a8ec32309fe58a6e529fe1c34d62e
From: osstest service owner 
Date: Thu, 21 Mar 2024 21:24:39 +0000

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          16 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  cbe393b709e0c6c3e2b10c3ac69fbea0abd530fe
baseline version:
 xen                  eaafbd11344a8ec32309fe58a6e529fe1c34d62e

Last test of basis   185109  2024-03-20 09:03:31 Z    1 days
Failing since        185120  2024-03-21 09:03:04 Z    0 days    3 attempts
Testing same since   185132  2024-03-21 18:02:16 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper 
  Anthony PERARD 
  Carlo Nonato 
  Elliott Mitchell 
  Jan Beulich 
  Julien Grall 
  Roger Pau Monné 
  Shawn Anastasio 

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-amd64                    pass    
 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
   eaafbd1134..cbe393b709  cbe393b709e0c6c3e2b10c3ac69fbea0abd530fe -> smoke


From xen-devel-bounces@lists.xenproject.org Thu Mar 21 23:18:16 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Mar 2024 23:18:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696618.1087687 (Exim 4.92)
	(envelope-from )
	id 1rnRfa-0000gD-U0; Thu, 21 Mar 2024 23:17:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696618.1087687; Thu, 21 Mar 2024 23:17:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnRfa-0000g6-R3; Thu, 21 Mar 2024 23:17:58 +0000
Received: by outflank-mailman (input) for mailman id 696618;
 Thu, 21 Mar 2024 23:17:57 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1rnRfZ-0000g0-Ns
 for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 23:17:57 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnRfV-0004y3-JJ; Thu, 21 Mar 2024 23:17:53 +0000
Received: from gw1.octic.net ([88.97.20.152] helo=[10.0.1.244])
 by xenbits.xenproject.org with esmtpsa
 (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92)
 (envelope-from )
 id 1rnRfV-0000Zb-Bw; Thu, 21 Mar 2024 23:17:53 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=pJzBb2iekzOvjrzlaLOHnN6Vvhc9ZcJigl9MDYJMjRM=; b=0V3G1vfVG5GqwpsnjXKn4eoFg6
	TBJS3lyHmB8QWq5WaTavEQU+4fhEj3zY0ebVgXvuSm04KppStVn+VmO/DjuC03DP9rGtV5pTxIaek
	4Z75SZJCAL3tALaIKnnm2Ad2W0hQrawrBdlzmxHY+ZqCxxqKaMeRRqH6klVlptbQ6yss=;
Message-ID: 
Date: Thu, 21 Mar 2024 23:17:51 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] docs/misra: document the expected sizes of integer
 types
Content-Language: en-GB
To: Stefano Stabellini ,
 Jan Beulich 
Cc: andrew.cooper3@citrix.com, bertrand.marquis@arm.com,
 george.dunlap@citrix.com, michal.orzel@amd.com, roger.pau@citrix.com,
 xen-devel@lists.xenproject.org
References: 
 <6a76723e-ba47-40b3-8f33-d68030b14299@suse.com>
 
 <7ab73379-b057-4568-9869-141cef185752@suse.com>
 
 
 
 <87234837-9fb3-40a9-849d-8b8574f2661c@suse.com>
 
 <198bade8-c6fc-4ae0-b721-3a9e2bd8acbe@suse.com>
 
From: Julien Grall 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Stefano,

I haven't fully read the thread. But I wanted to clarify something.

On 21/03/2024 19:03, Stefano Stabellini wrote:
>>> Or possibly unsigned long depending on the parameter.
>>
>> You're contradicting yourself: You mean to advocate for fixed-width types,
>> yet then you suggest "unsigned long".
> 
> No. I explained it in another thread a couple of days ago. There are
> cases where we have fixed-width types but the type changes by
> architecture: 32-bit for 32-bit archs and 64-bit for 64-bit archs.
> Rather than having #ifdefs, which is also an option, that is the one
> case where using "unsigned long" could be a decent compromise. In this
> context "unsigned long" means register size (on ARM we even have
> register_t). Once you pick an architecture, the size is actually meant
> to be fixed. In fact, it is specified in this document. Which is one of
> the reasons why we have to use == in this document and not >=. In
> general, fixed-width types like uint32_t are better because they are
> clearer and unambiguous. When possible I think they should be our first
> choice in ABIs.

"unsigned long" is not fixed in a given architecture. It will change 
base on the data model used by the OS. For instance, for Arm 64-bit, we 
have 3 models: ILP32, LP64, LLP64. Only on LP64, 'unsigned long' is 32-bit.

So effectively unsigned long can't be used in the ABI.

As a side note, Xen will use LP64, hence why we tend to use 'unsigned 
long' to describe 32-bit for Arm32 and 64-bit for Arm64.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Fri Mar 22 00:20:17 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Mar 2024 00:20:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696621.1087698 (Exim 4.92)
	(envelope-from )
	id 1rnSde-0001Vr-EB; Fri, 22 Mar 2024 00:20:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696621.1087698; Fri, 22 Mar 2024 00:20:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnSde-0001VO-8O; Fri, 22 Mar 2024 00:20:02 +0000
Received: by outflank-mailman (input) for mailman id 696621;
 Fri, 22 Mar 2024 00:20:02 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnSdd-0001Re-Vn; Fri, 22 Mar 2024 00:20:01 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnSdd-0006c0-Pa; Fri, 22 Mar 2024 00:20:01 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnSdd-0006Zc-Em; Fri, 22 Mar 2024 00:20:01 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rnSdd-0004S2-EK; Fri, 22 Mar 2024 00:20:01 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=UUijvl+vWOB9+acMWRhZ/A80ubDVv+nd/sX9nSfJQUg=; b=lGLvUq5nrccuUF8Z+qHMZvuF7d
	aRq1n07uq101SUOjCvbtzL6EreUFJpJzV5GhZnhqulwaS1VO1iNepDdbSCyXPuNKEiIcK1qXgRJbN
	rKaHrpycK0vOcY56u5a4yJzkxCzgcyOGjNqd3tJhMRsJxK9eXUT2G3eCC7OcA0wj3SDM=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 185124: tolerable FAIL
X-Osstest-Failures:
    xen-unstable:test-amd64-amd64-qemuu-freebsd12-amd64:guest-start/freebsd.repeat:fail:heisenbug
    xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:windows-install:fail:heisenbug
    xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-qcow2:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-qcow2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-vhd:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-raw:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    xen=eaafbd11344a8ec32309fe58a6e529fe1c34d62e
X-Osstest-Versions-That:
    xen=eaafbd11344a8ec32309fe58a6e529fe1c34d62e
From: osstest service owner 
Date: Fri, 22 Mar 2024 00:20:01 +0000

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-qemuu-freebsd12-amd64 21 guest-start/freebsd.repeat fail in 185117 pass in 185124
 test-amd64-amd64-xl-qemuu-win7-amd64 12 windows-install    fail pass in 185117

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop fail in 185117 blocked in 185124
 test-armhf-armhf-libvirt     16 saverestore-support-check    fail  like 185117
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop            fail like 185117
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop            fail like 185117
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop            fail like 185117
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 185117
 test-amd64-amd64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      16 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 16 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qcow2 14 migrate-support-check        fail never pass
 test-arm64-arm64-xl-credit1  15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  16 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-raw 14 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass
 test-armhf-armhf-xl-rtds     15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 15 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-check    fail  never pass
 test-armhf-armhf-libvirt     15 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-raw 14 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-raw 15 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-qcow2    14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-qcow2    15 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-vhd      14 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-vhd      15 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-vhd 14 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-vhd 15 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-raw      14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-raw      15 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  16 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  eaafbd11344a8ec32309fe58a6e529fe1c34d62e
baseline version:
 xen                  eaafbd11344a8ec32309fe58a6e529fe1c34d62e

Last test of basis   185124  2024-03-21 12:49:59 Z    0 days
Testing same since                          (not found)         0 attempts

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-libvirt-qcow2                               pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-xl-qcow2                                    pass    
 test-amd64-amd64-libvirt-raw                                 pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-amd64-amd64-xl-raw                                      pass    
 test-armhf-armhf-xl-raw                                      pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-libvirt-vhd                                 pass    
 test-amd64-amd64-xl-vhd                                      pass    
 test-arm64-arm64-xl-vhd                                      pass    


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

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

Explanation of these 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


Published tested tree is already up to date.



From xen-devel-bounces@lists.xenproject.org Fri Mar 22 01:55:59 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Mar 2024 01:55:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696632.1087707 (Exim 4.92)
	(envelope-from )
	id 1rnU8D-0003bw-Vi; Fri, 22 Mar 2024 01:55:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696632.1087707; Fri, 22 Mar 2024 01:55:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnU8D-0003bp-So; Fri, 22 Mar 2024 01:55:41 +0000
Received: by outflank-mailman (input) for mailman id 696632;
 Fri, 22 Mar 2024 01:55:40 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rnU8C-0003bj-K2
 for xen-devel@lists.xenproject.org; Fri, 22 Mar 2024 01:55:40 +0000
Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com
 [2607:f8b0:4864:20::530])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 45e419f2-e7ef-11ee-a1ee-f123f15fe8a2;
 Fri, 22 Mar 2024 02:55:36 +0100 (CET)
Received: by mail-pg1-x530.google.com with SMTP id
 41be03b00d2f7-5dbd519bde6so1046235a12.1
 for ; Thu, 21 Mar 2024 18:55:35 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 45e419f2-e7ef-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=smartx-com.20230601.gappssmtp.com; s=20230601; t=1711072534; x=1711677334; darn=lists.xenproject.org;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=EzIedkjP0LEiwr8PUCzEsIhUTFBbw9IsPgV6MMV2IDk=;
        b=TdNC6oroXVksr+MNbZxxWcAxVbI5+JIv8kFF9bCnkeNt8nUoI8JXsCfQf9TkNrZYvO
         GBZW75de0mCO0I8kSLrt7FUa9jhIJQcZHAHGVtAQzTb8GoVi7RlUtgrGY7T2W6MsMeI3
         DrXlwTcxRpEp6T3tmt+Kg1nRuE0EKlxAex5xQYkqcNbU8ryc2qB6T3Q5iFWTwX3mGDze
         HGfTS4VhMZ2KUvR4+3UfebVEDf5+Nl8j4ZvbZ49Nc1CK5d+O7stZVvgHdk5tvZb6mIEk
         BvyQF+9i31glQscUE2scyVcCQYj/SzQ1lrbp8cenx5fqkEdXMxOWZRQEk0VAu7FL/QZf
         xYTA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711072534; x=1711677334;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=EzIedkjP0LEiwr8PUCzEsIhUTFBbw9IsPgV6MMV2IDk=;
        b=wjGcUMjL6s8HwVic7DL1KHgyaan3e7a2C6raWKnQHxOwyqu7xmxfJLiP5sn9m0CPa3
         OgIX2YKoj5kbhHDfjYfaD5Yiuq/1qpe6+WA3+zyr4mdjwxtDzsbhfkV18K8egtG2iQhb
         f4m/eR16cU0ML4C4EuJE7EP4Wo+2HC40Ytpw2ixrjhpbKTh2bImy8X52rLQo7Ca+KCJ0
         rjT+ldTCfe9Sj3X97pFbU/ynyTI7jF8vDK62ErbGHPhmOd1gBfwq266unxgCQuEOr3ND
         unDkwLDOA/MeecHuckMu+xKFQ5oyn5qp+/A7wp9sDj56G7X8fkLhx3sEC/Xv1JJCvKk7
         4RVA==
X-Forwarded-Encrypted: i=1; AJvYcCW6mASJD35yk/SIh+a0fG4aZj4aw9UCnCFc0wQNW5iaggns1LHAHA+c1c+SGQUkd5Amk5KE2KvS9UMOyvR7p5zu0ApFlA7zu8af6InJ/oc=
X-Gm-Message-State: AOJu0YzNzR2FAXwXVnGEQud3uw0+wOF8bLoTc33fFHb7DiaOIW4kHlRY
	CYtfbufvvGzLoMaQpwS0pw0iwB2Jwl4XxitB9+hIkzrJAZHufaYwsq/Sb9OegvNZ7pLgdPlWQak
	t1hng7d+rH0rN5Ce9QRFhEwpcMMNULSdQ8aaNDQ==
X-Google-Smtp-Source: AGHT+IEbo5r7yzg00gqOHO1oaR9WuKR/d65AU7VaDJ8KqEEbxNGXkejY0G5rWbPV2hOyHqThe5iTa82tY2r5TYnRxNo=
X-Received: by 2002:a17:90a:d705:b0:2a0:2b14:9593 with SMTP id
 y5-20020a17090ad70500b002a02b149593mr1169651pju.6.1711072534302; Thu, 21 Mar
 2024 18:55:34 -0700 (PDT)
MIME-Version: 1.0
References: <20240320064911.545001-1-clg@redhat.com> <20240320064911.545001-12-clg@redhat.com>
 
In-Reply-To: 
From: Yong Huang 
Date: Fri, 22 Mar 2024 09:55:18 +0800
Message-ID: 
Subject: Re: [PATCH for-9.1 v5 11/14] memory: Add Error** argument to the
 global_dirty_log routines
To: Peter Xu 
Cc: =?UTF-8?Q?C=C3=A9dric_Le_Goater?= , qemu-devel@nongnu.org, 
	Stefano Stabellini , Anthony Perard , 
	Paul Durrant , Paolo Bonzini , 
	Richard Henderson , Eduardo Habkost , 
	"Michael S. Tsirkin" , Marcel Apfelbaum , 
	David Hildenbrand , =?UTF-8?Q?Philippe_Mathieu=2DDaud=C3=A9?= , 
	Fabiano Rosas , Alex Williamson , 
	Avihai Horon , Markus Armbruster , 
	Prasad Pandit , xen-devel@lists.xenproject.org, 
	Hailiang Zhang 
Content-Type: multipart/alternative; boundary="00000000000097d4950614361ece"

--00000000000097d4950614361ece
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Mar 20, 2024 at 11:19=E2=80=AFPM Peter Xu  wrote=
:

> On Wed, Mar 20, 2024 at 07:49:07AM +0100, C=C3=A9dric Le Goater wrote:
> > Now that the log_global*() handlers take an Error** parameter and
> > return a bool, do the same for memory_global_dirty_log_start() and
> > memory_global_dirty_log_stop(). The error is reported in the callers
> > for now and it will be propagated in the call stack in the next
> > changes.
> >
> > To be noted a functional change in ram_init_bitmaps(), if the dirty
> > pages logger fails to start, there is no need to synchronize the dirty
> > pages bitmaps. colo_incoming_start_dirty_log() could be modified in a
> > similar way.
> >
> > Cc: Stefano Stabellini 
> > Cc: Anthony Perard 
> > Cc: Paul Durrant 
> > Cc: "Michael S. Tsirkin" 
> > Cc: Paolo Bonzini 
> > Cc: David Hildenbrand 
> > Cc: Hyman Huang 
> > Signed-off-by: C=C3=A9dric Le Goater 
>
> Just to mention that for the rest users (dirtylimit/dirtyrate/colo) the
> code still just keeps going even if start logging failed even after this
> series applied as a whole.  Migration framework handles the failure
> gracefully, not yet the rest.
>
> That might be an issue for some, e.g., ideally we should be able to fail =
a
> calc-dirty-rate request, but it's not supported so far.  Adding that coul=
d
> add quite some burden to this series, so maybe that's fine to be done
>
Indeed, for the GLOBAL_DIRTY_DIRTY_RATE and GLOBAL_DIRTY_LIMIT
dirty tracking, they should handle the failure path of logging start.
The work may be done once the current patchset is merged.


> later.  After all, having a VFIO device (that can fail a start_log()), pl=
us
> any of those features should be even rarer, I think?
>
> It seems at least memory_global_dirty_log_sync() can be called even witho=
ut
> start logging, so I expect nothing should crash immediately. I spot one i=
n
> colo_incoming_start_dirty_log() already of such use.  My wild guess is it
> relies on all log_sync*() hooks to cope with it, e.g. KVM ioctl() should
> fail with -ENENT on most archs I think when it sees dirty log not ever
> started.
>
> For those bits, I'll wait and see whether Yong or Hailiang (cced) has any
> comments. From generic migration/memory side, nothing I see wrong:
>
> Acked-by: Peter Xu 
>
> Thanks,
>
> --
> Peter Xu
>
>

--=20
Best regards

--00000000000097d4950614361ece
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Wed, Mar 20, 20=
24 at 11:19=E2=80=AFPM Peter Xu <pe=
terx@redhat.com> wrote:
On Wed, Mar 20, 20=
24 at 07:49:07AM +0100, C=C3=A9dric Le Goater wrote:

> Now that the log_global*() handlers take an Error** parameter and

> return a bool, do the same for memory_global_dirty_log_start() and

> memory_global_dirty_log_stop(). The error is reported in the callers
> for now and it will be propagated in the call stack in the next

> changes.

> 

> To be noted a functional change in ram_init_bitmaps(), if the dirty
> pages logger fails to start, there is no need to synchronize the dirty=


> pages bitmaps. colo_incoming_start_dirty_log() could be modified in a<=
br>
> similar way.

> 

> Cc: Stefano Stabellini <sstabellini@kernel.org>

> Cc: Anthony Perard <anthony.perard@citrix.com>

> Cc: Paul Durrant <paul@xen.org>

> Cc: "Michael S. Tsirkin" <mst@redhat.com>

> Cc: Paolo Bonzini <pbonzini@redhat.com>

> Cc: David Hildenbrand <david@redhat.com>

> Cc: Hyman Huang <yong.huang@smartx.com>

> Signed-off-by: C=C3=A9dric Le Goater <clg@redhat.com>



Just to mention that for the rest users (dirtylimit/dirtyrate/colo) the

code still just keeps going even if start logging failed even after this
series applied as a whole.=C2=A0 Migration framework handles the failure
gracefully, not yet the rest.



That might be an issue for some, e.g., ideally we should be able to fail a<=
br>
calc-dirty-rate request, but it's not supported so far.=C2=A0 Adding th=
at could

add quite some burden to this series, so maybe that's fine to be done
Indeed, for the=C2=A0GLOBAL_DIRTY_DIRTY_RATE and=C2=
=A0GLOBAL_DIRTY_LIMIT
dirty tracking, they =
should handle the failure path of logging start.
The work may be done once the current patchset is merged.=C2=A0<=
/span>
=C2=A0

later.=C2=A0 After all, having a VFIO device (that can fail a start_log()),=
 plus

any of those features should be even rarer, I think?



It seems at least memory_global_dirty_log_sync() can be called even without=


start logging, so I expect nothing should crash immediately. I spot one in<=
br>
colo_incoming_start_dirty_log() already of such use.=C2=A0 My wild guess is=
 it

relies on all log_sync*() hooks to cope with it, e.g. KVM ioctl() should
fail with -ENENT on most archs I think when it sees dirty log not ever

started.



For those bits, I'll wait and see whether Yong or Hailiang (cced) has a=
ny

comments. From generic migration/memory side, nothing I see wrong:



Acked-by: Peter Xu <peterx@redhat.com>



Thanks,



-- 

Peter Xu






-- 
Best regards=



--00000000000097d4950614361ece--


From xen-devel-bounces@lists.xenproject.org Fri Mar 22 05:00:13 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Mar 2024 05:00:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696641.1087716 (Exim 4.92)
	(envelope-from )
	id 1rnX0Z-0001xA-8P; Fri, 22 Mar 2024 04:59:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696641.1087716; Fri, 22 Mar 2024 04:59:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnX0Z-0001x3-5p; Fri, 22 Mar 2024 04:59:59 +0000
Received: by outflank-mailman (input) for mailman id 696641;
 Fri, 22 Mar 2024 04:59:57 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnX0X-0001wx-AK
 for xen-devel@lists.xenproject.org; Fri, 22 Mar 2024 04:59:57 +0000
Received: from mail.zytor.com (unknown [2607:7c80:54:3::138])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0423bca6-e809-11ee-a1ee-f123f15fe8a2;
 Fri, 22 Mar 2024 05:59:53 +0100 (CET)
Received: from [192.168.7.187] ([71.202.166.45]) (authenticated bits=0)
 by mail.zytor.com (8.17.2/8.17.1) with ESMTPSA id 42M4xB6s3266343
 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO);
 Thu, 21 Mar 2024 21:59:11 -0700
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0423bca6-e809-11ee-a1ee-f123f15fe8a2
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 42M4xB6s3266343
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com;
	s=2024031401; t=1711083552;
	bh=fY4D2hQ2QLBqdcYPZo8wXFK6V0NwrraNImCOWbN9G1M=;
	h=Date:Subject:To:Cc:References:From:In-Reply-To:From;
	b=bLmwJ52HsZvjvwZI7xAbCQIwefstRlIDzfKRgERLFJENY/z/tyyTNNnTpqhuc/aiK
	 clxQ6EEbg1W6W4oZmlJ4AXH6Mpen27E8MndGauzBTm/imG795TlTnGphGvESnP2jR6
	 i6Kw9us1X678rgxJAaGd9aTDIbKXRADh2bnoSRl6srF1vOhuU/sbdyXOPETd1pgiBD
	 mHqxCTaJLA8lCvItq5BYoPViJ7D+6+noLPFrVtKtiyRoeasU9plXNDXDVqrOLBhLzK
	 0T/PxHOHJg8DbVTRC+i0y5h0uZQIeGYMTp7eeOoQWIa6EQ+tbDBFbFUIV+dPqpt8vo
	 OTyLQV4DLLnuA==
Message-ID: 
Date: Thu, 21 Mar 2024 21:59:08 -0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/1] x86: Rename __{start,end}_init_task to
 __{start,end}_init_stack
To: Ingo Molnar 
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
        linux-arch@vger.kernel.org, tglx@linutronix.de, mingo@redhat.com,
        bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org,
        hpa@zytor.com, jgross@suse.com, boris.ostrovsky@oracle.com,
        arnd@arndb.de, Brian Gerst 
References: <20240318071429.910454-1-xin@zytor.com>
 
Content-Language: en-US
From: Xin Li 
Autocrypt: addr=xin@zytor.com; keydata=
 xsDNBGUPz1cBDACS/9yOJGojBFPxFt0OfTWuMl0uSgpwk37uRrFPTTLw4BaxhlFL0bjs6q+0
 2OfG34R+a0ZCuj5c9vggUMoOLdDyA7yPVAJU0OX6lqpg6z/kyQg3t4jvajG6aCgwSDx5Kzg5
 Rj3AXl8k2wb0jdqRB4RvaOPFiHNGgXCs5Pkux/qr0laeFIpzMKMootGa4kfURgPhRzUaM1vy
 bsMsL8vpJtGUmitrSqe5dVNBH00whLtPFM7IbzKURPUOkRRiusFAsw0a1ztCgoFczq6VfAVu
 raTye0L/VXwZd+aGi401V2tLsAHxxckRi9p3mc0jExPc60joK+aZPy6amwSCy5kAJ/AboYtY
 VmKIGKx1yx8POy6m+1lZ8C0q9b8eJ8kWPAR78PgT37FQWKYS1uAroG2wLdK7FiIEpPhCD+zH
 wlslo2ETbdKjrLIPNehQCOWrT32k8vFNEMLP5G/mmjfNj5sEf3IOKgMTMVl9AFjsINLHcxEQ
 6T8nGbX/n3msP6A36FDfdSEAEQEAAc0WWGluIExpIDx4aW5Aenl0b3IuY29tPsLBDQQTAQgA
 NxYhBIUq/WFSDTiOvUIqv2u9DlcdrjdRBQJlD89XBQkFo5qAAhsDBAsJCAcFFQgJCgsFFgID
 AQAACgkQa70OVx2uN1HUpgv/cM2fsFCQodLArMTX5nt9yqAWgA5t1srri6EgS8W3F+3Kitge
 tYTBKu6j5BXuXaX3vyfCm+zajDJN77JHuYnpcKKr13VcZi1Swv6Jx1u0II8DOmoDYLb1Q2ZW
 v83W55fOWJ2g72x/UjVJBQ0sVjAngazU3ckc0TeNQlkcpSVGa/qBIHLfZraWtdrNAQT4A1fa
 sWGuJrChBFhtKbYXbUCu9AoYmmbQnsx2EWoJy3h7OjtfFapJbPZql+no5AJ3Mk9eE5oWyLH+
 QWqtOeJM7kKvn/dBudokFSNhDUw06e7EoVPSJyUIMbYtUO7g2+Atu44G/EPP0yV0J4lRO6EA
 wYRXff7+I1jIWEHpj5EFVYO6SmBg7zF2illHEW31JAPtdDLDHYcZDfS41caEKOQIPsdzQkaQ
 oW2hchcjcMPAfyhhRzUpVHLPxLCetP8vrVhTvnaZUo0xaVYb3+wjP+D5j/3+hwblu2agPsaE
 vgVbZ8Fx3TUxUPCAdr/p73DGg57oHjgezsDNBGUPz1gBDAD4Mg7hMFRQqlzotcNSxatlAQNL
 MadLfUTFz8wUUa21LPLrHBkUwm8RujehJrzcVbPYwPXIO0uyL/F///CogMNx7Iwo6by43KOy
 g89wVFhyy237EY76j1lVfLzcMYmjBoTH95fJC/lVb5Whxil6KjSN/R/y3jfG1dPXfwAuZ/4N
 cMoOslWkfZKJeEut5aZTRepKKF54T5r49H9F7OFLyxrC/uI9UDttWqMxcWyCkHh0v1Di8176
 jjYRNTrGEfYfGxSp+3jYL3PoNceIMkqM9haXjjGl0W1B4BidK1LVYBNov0rTEzyr0a1riUrp
 Qk+6z/LHxCM9lFFXnqH7KWeToTOPQebD2B/Ah5CZlft41i8L6LOF/LCuDBuYlu/fI2nuCc8d
 m4wwtkou1Y/kIwbEsE/6RQwRXUZhzO6llfoN96Fczr/RwvPIK5SVMixqWq4QGFAyK0m/1ap4
 bhIRrdCLVQcgU4glo17vqfEaRcTW5SgX+pGs4KIPPBE5J/ABD6pBnUUAEQEAAcLA/AQYAQgA
 JhYhBIUq/WFSDTiOvUIqv2u9DlcdrjdRBQJlD89ZBQkFo5qAAhsMAAoJEGu9DlcdrjdR4C0L
 /RcjolEjoZW8VsyxWtXazQPnaRvzZ4vhmGOsCPr2BPtMlSwDzTlri8BBG1/3t/DNK4JLuwEj
 OAIE3fkkm+UG4Kjud6aNeraDI52DRVCSx6xff3bjmJsJJMb12mWglN6LjdF6K+PE+OTJUh2F
 dOhslN5C2kgl0dvUuevwMgQF3IljLmi/6APKYJHjkJpu1E6luZec/lRbetHuNFtbh3xgFIJx
 2RpgVDP4xB3f8r0I+y6ua+p7fgOjDLyoFjubRGed0Be45JJQEn7A3CSb6Xu7NYobnxfkwAGZ
 Q81a2XtvNS7Aj6NWVoOQB5KbM4yosO5+Me1V1SkX2jlnn26JPEvbV3KRFcwV5RnDxm4OQTSk
 PYbAkjBbm+tuJ/Sm+5Yp5T/BnKz21FoCS8uvTiziHj2H7Cuekn6F8EYhegONm+RVg3vikOpn
 gao85i4HwQTK9/D1wgJIQkdwWXVMZ6q/OALaBp82vQ2U9sjTyFXgDjglgh00VRAHP7u1Rcu4
 l75w1xInsg==
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 3/21/2024 12:54 PM, Ingo Molnar wrote:
> 
> * Xin Li (Intel)  wrote:
> 
>> The stack of a task has been separated from the memory of a task_struct
>> struture for a long time on x86, as a result __{start,end}_init_task no
>> longer mark the start and end of the init_task structure, but its stack
>> only.
>>
>> Rename __{start,end}_init_task to __{start,end}_init_stack.
>>
>> Note other architectures are not affected because __{start,end}_init_task
>> are used on x86 only.
>>
>> Signed-off-by: Xin Li (Intel) 
>> ---
>>
>> Change since v1:
>> * Revert an accident insane change, init_task to init_stack (Jürgen Groß).
>> ---
>>   arch/x86/include/asm/processor.h  | 4 ++--
>>   arch/x86/kernel/head_64.S         | 2 +-
>>   arch/x86/xen/xen-head.S           | 2 +-
>>   include/asm-generic/vmlinux.lds.h | 6 +++---
>>   4 files changed, 7 insertions(+), 7 deletions(-)
> 
> Note that this is now in conflict with this cleanup by Brian Gerst:
> 
>     2cb16181a1d1 x86/boot: Simplify boot stack setup

I like this patch, which does something that I'm also doing, further 
x86_64 doesn't have the concept of TOP_OF_KERNEL_STACK_PADDING, and
I guess it was extended from x86_32 but defined to 0 just for code 
consistency.

Yes, FRED code uses TOP_OF_KERNEL_STACK_PADDING, but a FRED event frame 
could contain different amount of information for different event types,
e.g., #MCE could push extra bytes of information, or perhaps even for 
different instances of the same event type. Thus the size of an event 
frame pushed by a FRED CPU is not fixed and the address of the pt_regs 
structure that is used to save the user level context of current task is 
not at a fixed offset from the top of current task kernel stack.

> 
> .. which removed __end_init_task[] entirely.


Not really, but __end_init_task[] is only used to initialize 
__top_init_kernel_stack.

I will rebase and send v3.

Thanks!
     Xin








From xen-devel-bounces@lists.xenproject.org Fri Mar 22 06:05:03 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Mar 2024 06:05:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696647.1087726 (Exim 4.92)
	(envelope-from )
	id 1rnY1G-0002wx-QV; Fri, 22 Mar 2024 06:04:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696647.1087726; Fri, 22 Mar 2024 06:04:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnY1G-0002wq-Ni; Fri, 22 Mar 2024 06:04:46 +0000
Received: by outflank-mailman (input) for mailman id 696647;
 Fri, 22 Mar 2024 06:04:46 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnY1G-0002wg-8x; Fri, 22 Mar 2024 06:04:46 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnY1F-0003Mu-VY; Fri, 22 Mar 2024 06:04:46 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnY1F-0002Mm-Kc; Fri, 22 Mar 2024 06:04:45 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rnY1F-0000BT-K6; Fri, 22 Mar 2024 06:04:45 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=WB0CebYNAgmoSK9ZCRYjWFhtoICeLp4ousyC9oLjdlY=; b=nNQWnl/1ZHUp2cjrO8GO9jbSDm
	EBXIRi59qdkuZcusH0sQr+Z2nuNPYPFoSyc8YLVNZaaCfVT6Gdsv1zDnfETn7H+5PhVCUUCS4HViz
	jC0gLg0nGgm1n0HD6TUkek5ynpWRxoz1Wfs3xXn+q8WKBru+3DimeZRhJcAsjX0hj0Og=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 185136: regressions - FAIL
X-Osstest-Failures:
    linux-linus:build-arm64-xsm:xen-build:fail:regression
    linux-linus:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking
    linux-linus:test-arm64-arm64-xl-xsm:build-check(1):blocked:nonblocking
    linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-qcow2:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-qcow2:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-raw:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-vhd:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
X-Osstest-Versions-This:
    linux=241590e5a1d1b6219c8d3045c167f2fbcc076cbb
X-Osstest-Versions-That:
    linux=23956900041d968f9ad0f30db6dede4daccd7aa9
From: osstest service owner 
Date: Fri, 22 Mar 2024 06:04:45 +0000

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-xsm               6 xen-build                fail REGR. vs. 185119

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)               blocked  n/a
 test-arm64-arm64-xl-xsm       1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop            fail like 185119
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop            fail like 185119
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop            fail like 185119
 test-armhf-armhf-libvirt     16 saverestore-support-check    fail  like 185119
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop            fail like 185119
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 185119
 test-amd64-amd64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 15 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit1  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          16 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qcow2 14 migrate-support-check        fail never pass
 test-amd64-amd64-libvirt-raw 14 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-raw 14 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-raw 15 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt     15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-qcow2    14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-qcow2    15 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-vhd      14 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-vhd      15 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-raw      14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-raw      15 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-vhd 14 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-vhd 15 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass
 test-armhf-armhf-xl-credit2  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     16 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     15 migrate-support-check        fail   never pass

version targeted for testing:
 linux                241590e5a1d1b6219c8d3045c167f2fbcc076cbb
baseline version:
 linux                23956900041d968f9ad0f30db6dede4daccd7aa9

Last test of basis   185119  2024-03-21 07:40:49 Z    0 days
Testing same since   185136  2024-03-21 21:13:02 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  "Jiri Slaby (SUSE)" 
  "Moritz C. Weber" 
  "Nícolas F. R. A. Prado" 
  "Rafael J. Wysocki" 
  "Ricardo B. Marliere" 
  Abel Vesa 
  Abhijit Gangurde 
  Abhishek Pandit-Subedi 
  Adam Skladowski 
  Alan Stern 
  Alex Romosan 
  Alexander Tsoy 
  Alexander Usyskin 
  Alim Akhtar  # Samsung
  Amit Dhingra 
  Anand Jain 
  Andreas Klinger 
  Andrew Davis 
  Andrew Donnellan 
  Andrey Skvortsov 
  Andy Shevchenko 
  Andy Shevchenko 
  andy.shevchenko@gmail.com 
  AngeloGioacchino Del Regno 
  Antheas Kapenekakis 
  Arnaud Pouliquen 
  Arnd Bergmann 
  Artur Rojek 
  Arturas Moskvinas 
  Aurélien Jacobs 
  Bartosz Golaszewski 
  Basavaraj Natikar 
  Bjorn Andersson 
  Bjorn Helgaas 
  Bryan O'Donoghue 
  Cameron Williams 
  Carlos Llamas 
  CHECK_1234543212345@protonmail.com
  Chen-Yu Tsai 
  Chengming Zhou 
  ChiYuan Huang 
  Chris Leech 
  Christian Eggers 
  Christian Häggström 
  Christian König 
  Christoph Winklhofer 
  Christophe JAILLET 
  Colin Ian King 
  Colin Ian King 
  Conor Dooley 
  Dalton Durst 
  Dan Carpenter 
  Dan Williams 
  Daniel Vetter 
  Daniel Vogelbacher 
  Danila Tikhonov 
  David Lechner 
  David Sterba 
  Dawei Li 
  Denis Benato 
  Dimitri Fedrau 
  Dmitry Baryshkov 
  Dmitry Torokhov 
  Dorine Tipo 
  Douglas Anderson 
  Dumitru Ceclan 
  Elad Nachman 
  Elbert Mai 
  Eli Billauer 
  Eric Dumazet 
  Erick Archer 
  Florian Fainelli 
  Francesco Dolcini 
  Frank Li 
  Gabor Juhos 
  Geert Uytterhoeven 
  Geert Uytterhoeven 
  Georgi Djakov 
  Gil Fine 
  Greg Kroah-Hartman 
  Greg Ungerer 
  Guan-Yu Lin 
  Guanjun 
  Hans de Goede 
  Haotien Hsu 
  Heikki Krogerus 
  Helge Deller  # parisc STI console
  Hoorad Farrokh 
  Hugo Villeneuve 
  Ian Abbott 
  Icenowy Zheng 
  Ilpo Järvinen 
  Jakub Kicinski 
  James Clark 
  Jameson Thies 
  Jan Kundrát 
  Javier Carrasco 
  Javier Carrasco 
  Jean-Baptiste Maneyrol 
  Jeff Johnson 
  Jeffrey Hugo 
  Jerome Brunet 
  Jerrin Shaji George 
  Jesus Gonzalez 
  Jinlong Mao 
  Jiri Slaby (SUSE) 
  Joakim Zhang 
  Johan Hovold 
  Johannes Berg 
  Johannes Thumshirn 
  John Garry 
  John Paul Adrian Glaubitz 
  John Stultz 
  Jon Hunter 
  Jonas Gorski 
  Jonathan Bergh 
  Jonathan Cameron 
  Jonathan Cameron  #for-iio
  Jonathan LoBue 
  Josua Mayer 
  Julia Lawall 
  Jun Yan 
  Justin Stitt 
  Kalyani Akula 
  Karina Yankevich 
  Kees Cook 
  Keng-Yu Lin 
  Kim Seer Paller 
  Klara Modin 
  Konrad Dybcio 
  Krishna chaitanya chundru 
  Krishna Kurapati 
  Krzysztof Kozlowski 
  Krzysztof Kozlowski 
  Kunihiko Hayashi 
  Lee Jones 
  Li Zhijian 
  Linus Torvalds 
  Lizhe 
  Lorenzo Bianconi 
  Luca Weiss 
  Luca Weiss  # sdm632-fairphone-fp3
  Luis Chamberalin 
  Lukas Bulwahn 
  Luke D. Jones 
  Macpaul Lin 
  Madhan Sai 
  Manikanta Guntupalli 
  Manivannan Sadhasivam 
  Mao Jinlong 
  Marc Dietrich 
  Marc Herbert 
  Marco Felsch 
  Marco Pagani 
  Marius Cristea 
  Mark Brown 
  Mark Greer 
  Markus Schneider-Pargmann 
  Masahiro Yamada 
  Mathias Nyman 
  Mathieu Poirier 
  Matt Hsiao 
  Matthias Kaehlcke 
  Matthias Yee 
  Matti Vaittinen 
  Maximilian Luz   # for platform/surface
  Meir Elisha 
  Michael Grzeschik 
  Michael Kelley 
  Michael Straube 
  Michal Pecio 
  Michal Simek 
  Mika Westerberg 
  Mike Looijmans 
  Mohammad Rahimi 
  Mohammed Billoo 
  Moritz C. Weber 
  Mukesh Ojha 
  Mårten Lindahl 
  Nadav Amit 
  Namjae Jeon 
  Naresh Solanki 
  Neel Natu 
  Neil Armstrong 
  Nghia Nguyen 
  Nicolas Ferre 
  Nikhil Agarwal 
  Nikita Mikhailevich 
  Niklas Neronin 
  Niklas Neronin 
  Niklas Söderlund 
  Niko Mauno 
  Nilesh Javali 
  Nipun Gupta 
  Nuno Das Neves 
  Nuno Sa 
  Nícolas F. R. A. Prado 
  Oleksandr Natalenko 
  Oliver Neukum 
  Olivier Moysan 
  Ondrej Jirman 
  Ondřej Jirman 
  Paul Cercueil 
  Peng Fan 
  Peter Collingbourne 
  Peter Korsgaard 
  Petre Rodan 
  Philipp Hortmann 
  Philipp Zabel 
  Pranav Athreya 
  Prashanth K 
  Praveen Teja Kundanala 
  Purna Pavan Chandra Aekkaladevi 
  Quentin Schulz 
  Ramona Gradinariu 
  Ran Wang 
  Randy Dunlap 
  Raphael Gallais-Pou 
  RD Babiera 
  Rengarajan S 
  Ricardo B. Marliere 
  Rob Herring 
  Rodolfo Giometti 
  Roger Quadros 
  Rohan Kollambalath 
  Roman Žilka 
  Rui Miguel Silva 
  Sakari Ailus 
  Sam Protsenko 
  Samuel Thibault 
  Sanath S 
  Saravana Kannan 
  Saurabh Sengar 
  Sean Anderson 
  Sean Rhodes 
  Sebastian Andrzej Siewior 
  Serge Semin 
  Serge Semin 
  Sergey Shtylyov 
  Shahar Avidar 
  Shoji Keita 
  Sibi Sankar 
  Sing-Han Chen 
  Srinivas Kandagatla 
  Srinivas Pandruvada 
  Stanley Chang 
  Stefan Eichenberger 
  Stephan Gerhold 
  Stephen Boyd 
  Subhajit Ghosh 
  Suzuki K Poulose 
  Tamseel Shams 
  Tanmay Shah 
  Tao Zhang 
  Tarak Reddy 
  Tejun Heo 
  Thierry Reding  # Tegra
  Thinh Nguyen 
  Thomas Haemmerle 
  Thomas Huth 
  Thorsten Scherer 
  Tomas Winkler 
  Toru Katagiri 
  Tree Davies 
  Tudor Ambarus 
  Uday Bhat 
  Uday M Bhat 
  Uwe Kleine-König 
  Vaibhav Agarwal 
  Vaibhav Gupta 
  Valentin Caron 
  Vitaly Lubart 
  Wayne Chang 
  Wei Liu 
  Wesley Cheng 
  William-tw Lin 
  Wolfram Sang 
  Xu Yilun 
  Xu Yilun 
  Yang Jihong 
  Yang Xiwen 
  Yuezhang Mo 
  Yury Norov 

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              fail    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 blocked 
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      blocked 
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-libvirt-qcow2                               pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-xl-qcow2                                    pass    
 test-amd64-amd64-libvirt-raw                                 pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-amd64-amd64-xl-raw                                      pass    
 test-armhf-armhf-xl-raw                                      pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-libvirt-vhd                                 pass    
 test-amd64-amd64-xl-vhd                                      pass    
 test-arm64-arm64-xl-vhd                                      pass    


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

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

Explanation of these 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 17062 lines long.)


From xen-devel-bounces@lists.xenproject.org Fri Mar 22 06:40:21 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Mar 2024 06:40:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696654.1087737 (Exim 4.92)
	(envelope-from )
	id 1rnYZb-0008S9-Ki; Fri, 22 Mar 2024 06:40:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696654.1087737; Fri, 22 Mar 2024 06:40:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnYZb-0008S2-IG; Fri, 22 Mar 2024 06:40:15 +0000
Received: by outflank-mailman (input) for mailman id 696654;
 Fri, 22 Mar 2024 06:40:15 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rnYZa-0008Rw-8f
 for xen-devel@lists.xenproject.org; Fri, 22 Mar 2024 06:40:14 +0000
Received: from out30-112.freemail.mail.aliyun.com
 (out30-112.freemail.mail.aliyun.com [115.124.30.112])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 06d3bebd-e817-11ee-afe0-a90da7624cb6;
 Fri, 22 Mar 2024 07:40:11 +0100 (CET)
Received: from localhost(mailfrom:jiapeng.chong@linux.alibaba.com
 fp:SMTPD_---0W3160E1_1711089598) by smtp.aliyun-inc.com;
 Fri, 22 Mar 2024 14:40:07 +0800
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 06d3bebd-e817-11ee-afe0-a90da7624cb6
DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=linux.alibaba.com; s=default;
	t=1711089608; h=From:To:Subject:Date:Message-Id:MIME-Version;
	bh=zRQDJgJXoe1TeM1CcHUcSOSMdyyAF8An2Aiv5fBBZMg=;
	b=GHNbHChPdSZuSC4IIhOWOn4kgg6h0Nxq/BKdFxzOWOwTXypLV+fBNNbzvtsvzh0CJCVyZ1qLlqwwLrLI8jm+6eN63Qi3D9g2UOwDhIunl/FIdzRHJ1Aluv1pgphd6pzjcYSpx3XZrFt8Ui5eLCLINtwRs+PvdSiC/wJE5EYbuiw=
X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R201e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018045176;MF=jiapeng.chong@linux.alibaba.com;NM=1;PH=DS;RN=12;SR=0;TI=SMTPD_---0W3160E1_1711089598;
From: Jiapeng Chong 
To: jgross@suse.com
Cc: boris.ostrovsky@oracle.com,
	tglx@linutronix.de,
	mingo@redhat.com,
	bp@alien8.de,
	dave.hansen@linux.intel.com,
	x86@kernel.org,
	hpa@zytor.com,
	xen-devel@lists.xenproject.org,
	linux-kernel@vger.kernel.org,
	Jiapeng Chong ,
	Abaci Robot 
Subject: [PATCH] xen/x86: Remove duplicate include
Date: Fri, 22 Mar 2024 14:39:57 +0800
Message-Id: <20240322063957.94159-1-jiapeng.chong@linux.alibaba.com>
X-Mailer: git-send-email 2.20.1.7.g153144c
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

./arch/x86/xen/enlighten.c: linux/memblock.h is included more than once.

Reported-by: Abaci Robot 
Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=8610
Signed-off-by: Jiapeng Chong 
---
 arch/x86/xen/enlighten.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index a01ca255b0c6..5f3a69f6ec34 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1,8 +1,5 @@
 // SPDX-License-Identifier: GPL-2.0
 
-#ifdef CONFIG_XEN_BALLOON_MEMORY_HOTPLUG
-#include 
-#endif
 #include 
 #include 
 #include 
-- 
2.20.1.7.g153144c



From xen-devel-bounces@lists.xenproject.org Fri Mar 22 06:53:17 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Mar 2024 06:53:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696658.1087747 (Exim 4.92)
	(envelope-from )
	id 1rnYm8-0001uO-Ld; Fri, 22 Mar 2024 06:53:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696658.1087747; Fri, 22 Mar 2024 06:53:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnYm8-0001uG-It; Fri, 22 Mar 2024 06:53:12 +0000
Received: by outflank-mailman (input) for mailman id 696658;
 Fri, 22 Mar 2024 06:53:11 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnYm7-0001sK-Pi
 for xen-devel@lists.xenproject.org; Fri, 22 Mar 2024 06:53:11 +0000
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com
 [2a00:1450:4864:20::635])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d8b83d58-e818-11ee-afe0-a90da7624cb6;
 Fri, 22 Mar 2024 07:53:10 +0100 (CET)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-a4707502aafso308521966b.0
 for ; Thu, 21 Mar 2024 23:53:10 -0700 (PDT)
Received: from ?IPV6:2003:e5:873a:400:704b:6dbb:e7c0:786e?
 (p200300e5873a0400704b6dbbe7c0786e.dip0.t-ipconnect.de.
 [2003:e5:873a:400:704b:6dbb:e7c0:786e])
 by smtp.gmail.com with ESMTPSA id
 h10-20020a1709060f4a00b00a472c4b9486sm460730ejj.84.2024.03.21.23.53.09
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 21 Mar 2024 23:53:10 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d8b83d58-e818-11ee-afe0-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711090390; x=1711695190; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:references:cc:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=dqvOkYG7PGR/60T9a+vecv0YvaykQSrN8+SAoBmbKLY=;
        b=S1eNbyIDUJ6bbi9xHsp0pT+QF3ZZ7M7Ib7It7VSQNk6mHvNlXvW0NgjnN++ziqp3P0
         P+2RjmmYR1s2w0hbjBHRf5flSHHMOLuM92KDBlM3UvIELQUDcLvWukoEqIyU9pe3c11Y
         bo+qeGiLXqkTdeAn+KnC0RIEYPNLugF2vR+jDTwoXuo6VEAboIqDZWRR9RJqeRwg4HyD
         tAZF6a7dgbKnN/grKa9uQgu0acB1tUWeZYY/2dTk/bF7gxTtiG04B0EFVLurqPHMgcZ7
         3Cli4uZQKRH8Oeke/fHp/7nkmibBHhUI7m8A/s3LC1XAPud8lNxU+2YfoRTDYyMJ7cCb
         KSZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711090390; x=1711695190;
        h=content-transfer-encoding:in-reply-to:from:references:cc:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=dqvOkYG7PGR/60T9a+vecv0YvaykQSrN8+SAoBmbKLY=;
        b=eg2HGmiPX89weUDKyjrXnWv0IjFQekJ2Kq/JeCJaIuatlRlVI1qzny52T0Z9ccJM1t
         HaHkugOgUK6sPZJWCNKZlfBmJNhH/fH5YIvudaQHypGgLxg1Pf00f+PJAGVV89EYeZ/3
         qu8KS2cRc9+L3QxhuCaSNVOL52DltUC+2d4TrV3xL3OeLwGlIPqRu8O10Ig7wV7ebi4j
         z/2xuaRgL6YJADVZfH4giPnorfju2mFCeNAiodgUFmBQNHJ1PpoAcnCz4rlpWaSckOC4
         gVoBsZwiGW4H4Ckq5EbRePIJWMJxJ0S9T0zD9BOCzyVd41Nu66S5g8N7QYKHIEIk2vyz
         Hctw==
X-Forwarded-Encrypted: i=1; AJvYcCUcO44kSiztfx0Bu+q/A9QjZhWYK3AWJRDzYB/kSc6WzG2qXvASy72MUAPC2IxtnfZ81Iz2p3RBGDRHLahznr0Zrz9xGo3CRcCR0mfXKQ8=
X-Gm-Message-State: AOJu0YyYg6vDt6YvuE+u6MbfOgA+zmluCYvLGzQg9NqZr6yIN7BRP9SM
	RZTDu6RVw5TeZ65rkLrG2CDLwiHUkVsfV8HxjivUEZOveYtfIvr3466BmM1n4kc=
X-Google-Smtp-Source: AGHT+IFlkBu7bgRCcPm1ksy6ar+oWKKLT0QxCo9cXoRVYuAvIvMat/Nwchd03Pt+Yo+xx4szyR3oHw==
X-Received: by 2002:a17:907:940f:b0:a46:75d3:dd46 with SMTP id dk15-20020a170907940f00b00a4675d3dd46mr1107120ejc.17.1711090390380;
        Thu, 21 Mar 2024 23:53:10 -0700 (PDT)
Message-ID: <51389495-4b99-430b-9ae8-7f938af34bec@suse.com>
Date: Fri, 22 Mar 2024 07:53:09 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/x86: Remove duplicate include
Content-Language: en-US
To: Jiapeng Chong 
Cc: boris.ostrovsky@oracle.com, tglx@linutronix.de, mingo@redhat.com,
 bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com,
 xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org,
 Abaci Robot 
References: <20240322063957.94159-1-jiapeng.chong@linux.alibaba.com>
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
In-Reply-To: <20240322063957.94159-1-jiapeng.chong@linux.alibaba.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 22.03.24 07:39, Jiapeng Chong wrote:
> ./arch/x86/xen/enlighten.c: linux/memblock.h is included more than once.
> 
> Reported-by: Abaci Robot 
> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=8610
> Signed-off-by: Jiapeng Chong 

Reviewed-by: Juergen Gross 


Juergen



From xen-devel-bounces@lists.xenproject.org Fri Mar 22 07:25:34 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Mar 2024 07:25:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696666.1087756 (Exim 4.92)
	(envelope-from )
	id 1rnZHE-0006nf-IE; Fri, 22 Mar 2024 07:25:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696666.1087756; Fri, 22 Mar 2024 07:25:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnZHE-0006nY-FP; Fri, 22 Mar 2024 07:25:20 +0000
Received: by outflank-mailman (input) for mailman id 696666;
 Fri, 22 Mar 2024 07:25:19 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnZHD-0006n9-RG
 for xen-devel@lists.xenproject.org; Fri, 22 Mar 2024 07:25:19 +0000
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com
 [2a00:1450:4864:20::52a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 53219131-e81d-11ee-a1ee-f123f15fe8a2;
 Fri, 22 Mar 2024 08:25:17 +0100 (CET)
Received: by mail-ed1-x52a.google.com with SMTP id
 4fb4d7f45d1cf-56bcb9640bbso1817870a12.0
 for ; Fri, 22 Mar 2024 00:25:14 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 q2-20020a1709066b0200b00a46c1dd36f0sm716150ejr.173.2024.03.22.00.25.13
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 22 Mar 2024 00:25:13 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 53219131-e81d-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711092314; x=1711697114; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=7cqkKgy/Zn5jpOfJ1bdQHTOWUGXi+4Jyp41xQHSCUbw=;
        b=fHa2dfwlFHI7cwsln47G1+zg6FOR0y4L6wpwPQmHxgiEmZ0wqW53m2epcjOYMerYUT
         K1iFLNIdSmrBz0++It2DRsoiY1GQY+gsfTe0ZU66Pd48pe5DrK3MbLI/q2TntDCOhcvX
         yfD598Yk2cLhLuiCWroS2BwycxK6rSiPxgURBUPM1XYS8vNsE8QR+EjnWHkEI8mSEIdM
         kRcM4n2MjYx+3eMzCDpQIdNKFK7aJnR080Ge0EidUTd7fOtRfWP/LiRbSjNZ0eB6uM4M
         aq2EVuF64J7sGpjHJyMlYYN4GjtbKUT7aI3xaT1jCwh+djoxVqf+D8GzMAiadoonSLAz
         jhFw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711092314; x=1711697114;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=7cqkKgy/Zn5jpOfJ1bdQHTOWUGXi+4Jyp41xQHSCUbw=;
        b=QnMTHILwFjAg9DShxE2fBHExSTpQymRHIoohQr76hb9FnQzL8ZMCzjQZDuVR3cXYN0
         QLBdvPNzh1ODwENQDEJDgyn+RNDsd0ISWVU5UgYAbt6c352fSUpVY4rqp9MgroZmv5nx
         6fwNzPKFe/qWm91wARXIMqvgp41J2/H/ofW/Y7KSHDEUwlxu7rjl9csSBPThkouhNCHv
         npO5+8p3qzUyZzeOcOGDJGo5thIHe+XF1ArjcCed43Mkf9LsPpDiIU+2KuJDyX8xLnxT
         T6UvbAnVGiEoWOncCBsHHp1cUI3z07r8wBY4V3gwFov7jEuCeH5B0x7ZHU02sqNzfZRQ
         x5AA==
X-Forwarded-Encrypted: i=1; AJvYcCXph7gpUVu/f6HNnfuZqdmSts7vLeYRiO6VnZ1guo0/1qyVg5Qq/uI6ez9iFvc+uUyXWNMwvsKj6qHBU0xK0wfKb87cYDJP+8vwdCEipeI=
X-Gm-Message-State: AOJu0YxzCwmaiUY6+EwHOoHFNiteVy8doxHp7gcgkrEPABoyZnQTLX6H
	ZBmv2FbbSTHFlVQU0kckCFi68slPQR8GeY/Dc4X1ULtq2ANhHkQmJkT5Dl6cPA==
X-Google-Smtp-Source: AGHT+IHpOvuBsz1f7Yx87k/CnN+8q+mTbCMZBxGVLhIyJlGi+0/azOJuQc7wUKnE67l301nD52YpbA==
X-Received: by 2002:a17:906:714d:b0:a46:ba19:2e99 with SMTP id z13-20020a170906714d00b00a46ba192e99mr999886ejj.26.1711092313665;
        Fri, 22 Mar 2024 00:25:13 -0700 (PDT)
Message-ID: 
Date: Fri, 22 Mar 2024 08:25:12 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 01/14] xen/common: add cache coloring common code
Content-Language: en-US
To: Carlo Nonato 
Cc: Andrea Bastoni ,
 Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 Marco Solieri , xen-devel@lists.xenproject.org
References: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
 <20240315105902.160047-2-carlo.nonato@minervasys.tech>
 <05e4d3da-4130-4c57-9855-43b685ce5005@suse.com>
 
 <2b4d6e96-0f04-4327-9875-cd0587931621@suse.com>
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 21.03.2024 18:22, Carlo Nonato wrote:
> Hi Jan,
> 
> On Thu, Mar 21, 2024 at 4:53 PM Jan Beulich  wrote:
>>
>> On 21.03.2024 16:03, Carlo Nonato wrote:
>>> On Tue, Mar 19, 2024 at 3:58 PM Jan Beulich  wrote:
>>>> On 15.03.2024 11:58, Carlo Nonato wrote:
>>>>> --- a/docs/misc/xen-command-line.pandoc
>>>>> +++ b/docs/misc/xen-command-line.pandoc
>>>>> @@ -1706,6 +1706,43 @@ This option is intended for debugging purposes only.  Enable MSR_DEBUGCTL.LBR
>>>>>  in hypervisor context to be able to dump the Last Interrupt/Exception To/From
>>>>>  record with other registers.
>>>>>
>>>>> +### llc-coloring
>>>>> +> `= `
>>>>> +
>>>>> +> Default: `false`
>>>>> +
>>>>> +Flag to enable or disable LLC coloring support at runtime. This option is
>>>>> +available only when `CONFIG_LLC_COLORING` is enabled. See the general
>>>>> +cache coloring documentation for more info.
>>>>> +
>>>>> +### llc-nr-ways
>>>>> +> `= `
>>>>> +
>>>>> +> Default: `Obtained from hardware`
>>>>> +
>>>>> +Specify the number of ways of the Last Level Cache. This option is available
>>>>> +only when `CONFIG_LLC_COLORING` is enabled. LLC size and number of ways are used
>>>>> +to find the number of supported cache colors. By default the value is
>>>>> +automatically computed by probing the hardware, but in case of specific needs,
>>>>> +it can be manually set. Those include failing probing and debugging/testing
>>>>> +purposes so that it's possibile to emulate platforms with different number of
>>>>> +supported colors. If set, also "llc-size" must be set, otherwise the default
>>>>> +will be used.
>>>>> +
>>>>> +### llc-size
>>>>> +> `= `
>>>>> +
>>>>> +> Default: `Obtained from hardware`
>>>>> +
>>>>> +Specify the size of the Last Level Cache. This option is available only when
>>>>> +`CONFIG_LLC_COLORING` is enabled. LLC size and number of ways are used to find
>>>>> +the number of supported cache colors. By default the value is automatically
>>>>> +computed by probing the hardware, but in case of specific needs, it can be
>>>>> +manually set. Those include failing probing and debugging/testing purposes so
>>>>> +that it's possibile to emulate platforms with different number of supported
>>>>> +colors. If set, also "llc-nr-ways" must be set, otherwise the default will be
>>>>> +used.
>>>>
>>>> Wouldn't it make sense to infer "llc-coloring" when both of the latter options
>>>> were supplied?
>>>
>>> To me it looks a bit strange that specifying some attributes of the cache
>>> automatically enables cache coloring. Also it would require some changes in
>>> how to express the auto-probing for such attributes.
>>
>> Whereas to me it looks strange that, when having llc-size and llc-nr-ways
>> provided, I'd need to add a 3rd option. What purpose other than enabling
>> coloring could there be when specifying those parameters?
> 
> Ok, I probably misunderstood you. You mean just to assume llc-coloring=on
> when both llc-size and llc-nr-ways are present and not to remove
> llc-coloring completely, right?

Yes. The common thing, after all, will be to just have llc-coloring on the
command line.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Mar 22 07:26:28 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Mar 2024 07:26:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696669.1087767 (Exim 4.92)
	(envelope-from )
	id 1rnZIJ-0007I8-SJ; Fri, 22 Mar 2024 07:26:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696669.1087767; Fri, 22 Mar 2024 07:26:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnZIJ-0007I1-P8; Fri, 22 Mar 2024 07:26:27 +0000
Received: by outflank-mailman (input) for mailman id 696669;
 Fri, 22 Mar 2024 07:26:27 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnZIJ-0007Hi-56
 for xen-devel@lists.xenproject.org; Fri, 22 Mar 2024 07:26:27 +0000
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com
 [2a00:1450:4864:20::52a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7db527ef-e81d-11ee-afe0-a90da7624cb6;
 Fri, 22 Mar 2024 08:26:25 +0100 (CET)
Received: by mail-ed1-x52a.google.com with SMTP id
 4fb4d7f45d1cf-56890b533aaso2139107a12.3
 for ; Fri, 22 Mar 2024 00:26:25 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 q2-20020a1709066b0200b00a46c1dd36f0sm716150ejr.173.2024.03.22.00.26.24
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 22 Mar 2024 00:26:25 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7db527ef-e81d-11ee-afe0-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711092385; x=1711697185; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=eQMZ8de7SAwPfLPn7Gq5ffe7xaOgBVkw3zMTnDc8cMI=;
        b=RGALkCx2VQ9SYQ8hwcXPukfds8Z0gBAu/K/AKT8RJS/qp9hTjVUCFlkdn9pwcZpYqV
         n8Iq1rW0XSfKgJdFPMCr2uuJRmH3Slxb4HXYBQbaxi/A1WMOI6nm3TA//goTWBOtflmV
         QmhOYfovP6RRRVIGEck5reTNBGw6z3jyl7TtaRshsz2zwCidTZGyAPuA/642K5T3R5hs
         CDgRVNPwj7BPtM+N+HY1OsaZbk25EfKZPt5eeZ2cz1VFsr9etKUYx+IUAHEZmhdbklOC
         LfsX/cJCvBxP5ZEY0PXA5T3Ud9Hek5IbbNTJmLy91L2zCBD776b+Lnmr1sHavzMh8+kT
         8y3w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711092385; x=1711697185;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=eQMZ8de7SAwPfLPn7Gq5ffe7xaOgBVkw3zMTnDc8cMI=;
        b=wAFsNl7+tiiU0StxY+NGwI7Ymk7Q8mHjDRPLERypfO1lIgnqZdbJOQ9Jo6fDZm/PYn
         THQt5VWMKV1DXSYxjogzXSRF+dtCMRXxwD/C5ICksqLND3e73spydyCrgrgzDBFrD+pj
         6ZcAZvPP2UHPitqmbXa6ZQqbYyw/e49GCHjDFN2xPbIMebYQmvk+pIMgcOYWN9tThr4Y
         dM8F0kOBTdv9F9ocRLaY7B6D/CgWCXzD8EJgckK2li7BJ7Tjcl7D0qIs6pKicZUeph52
         Adeya8UDA2gATMK54XmjUuI6Dza3w7ObEI2LJXTapQcT6/gxcdDOqHuRiKEz5fKLFbju
         MZ2Q==
X-Forwarded-Encrypted: i=1; AJvYcCUyTEYAwL3dnqqg7G1JerNzGXAmXq27ni2m9+lCM1CCMHCAxwcOri9Z3nmpVpW/aSw8AmNqd3VpGuYHA+VhZ7JAvaJUA+qCF82K3xnEOKM=
X-Gm-Message-State: AOJu0Yy8Tz0TDutuZw23AKxmx0Thxj+1WQk/9RkWDSRrEsosGwym7t+U
	qNoNn+sCO6Gw9dTyubzhqLWgVFrrTNePj+f3Ha2ZKGCRf+W8wKtAKJC5dN1HFw==
X-Google-Smtp-Source: AGHT+IGrY0rpGEGZNbwFoDsaMbHyOVkCeJZ25gzMOEvjS53DH2f4Gqh20iTdn0baU8N2NiVpdnt7wg==
X-Received: by 2002:a17:906:2553:b0:a47:2087:c26f with SMTP id j19-20020a170906255300b00a472087c26fmr992755ejb.73.1711092385357;
        Fri, 22 Mar 2024 00:26:25 -0700 (PDT)
Message-ID: <22ab32bb-b0d0-4d68-8918-5fcb42cc0f88@suse.com>
Date: Fri, 22 Mar 2024 08:26:24 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 04/14] xen/arm: add Dom0 cache coloring support
Content-Language: en-US
To: Carlo Nonato 
Cc: Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Marco Solieri ,
 xen-devel@lists.xenproject.org,
 Andrea Bastoni 
References: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
 <20240315105902.160047-5-carlo.nonato@minervasys.tech>
 
 
 <3ff10fdd-5a85-43b3-853a-fe69c7388ca9@suse.com>
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 21.03.2024 18:31, Carlo Nonato wrote:
> On Thu, Mar 21, 2024 at 4:57 PM Jan Beulich  wrote:
>>
>> On 21.03.2024 16:04, Carlo Nonato wrote:
>>> On Tue, Mar 19, 2024 at 4:30 PM Jan Beulich  wrote:
>>>> On 15.03.2024 11:58, Carlo Nonato wrote:
>>>>> --- a/docs/misc/xen-command-line.pandoc
>>>>> +++ b/docs/misc/xen-command-line.pandoc
>>>>> @@ -963,6 +963,15 @@ Controls for the dom0 IOMMU setup.
>>>>>
>>>>>  Specify a list of IO ports to be excluded from dom0 access.
>>>>>
>>>>> +### dom0-llc-colors
>>>>> +> `= List of [  | - ]`
>>>>> +
>>>>> +> Default: `All available LLC colors`
>>>>> +
>>>>> +Specify dom0 LLC color configuration. This option is available only when
>>>>> +`CONFIG_LLC_COLORING` is enabled. If the parameter is not set, all available
>>>>> +colors are used.
>>>>
>>>> My reservation towards this being a top-level option remains.
>>>
>>> How can I turn this into a lower-level option? Moving it into "dom0=" doesn't
>>> seem possible to me. How can I express a list (llc-colors) inside another list
>>> (dom0)? dom0=llc-colors=0-3,12-15,other-param=... How can I stop parsing
>>> before reaching other-param?
>>
>> For example by using a different separator:
>>
>> dom0=llc-colors=0-3+12-15,other-param=...
> 
> Ok, but that would mean to change the implementation of the parsing function
> and to adopt this syntax also in other places, something that I would've
> preferred to avoid. Anyway I'll follow your suggestion.

Well, this is all used by Arm only for now. You will want to make sure Arm
folks are actually okay with this alternative approach.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Mar 22 07:28:57 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Mar 2024 07:28:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696670.1087776 (Exim 4.92)
	(envelope-from )
	id 1rnZKi-0007ve-7G; Fri, 22 Mar 2024 07:28:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696670.1087776; Fri, 22 Mar 2024 07:28:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnZKi-0007vX-4D; Fri, 22 Mar 2024 07:28:56 +0000
Received: by outflank-mailman (input) for mailman id 696670;
 Fri, 22 Mar 2024 07:28:55 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnZKh-0007vL-Ap; Fri, 22 Mar 2024 07:28:55 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnZKh-0004sb-6p; Fri, 22 Mar 2024 07:28:55 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnZKg-0005XC-Um; Fri, 22 Mar 2024 07:28:55 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rnZKg-0002pW-UF; Fri, 22 Mar 2024 07:28:54 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=9TZB8S0AevJRYVAbWJ4eSczJ5lgzkHn1UOKtWFNhks0=; b=CKphLNcs132cBqLJsjUN98EPu7
	wBosE6fP36ni2bdA0IaV5uAMheXD6/mESteDO8mkqcT09Z3vfM+rkWgxpbhv6D9DSdxZ29Gb8ykvn
	t5X+pV52TboMiX6iUxwUv4tMDxs+s27wd2OrHnaGHbS/qO8jEAf/rjgxTM8xSnpwcLgQ=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [ovmf test] 185138: all pass - PUSHED
X-Osstest-Versions-This:
    ovmf=7f1ffba5de3d9840dbeeba20fba165f2fb724941
X-Osstest-Versions-That:
    ovmf=35f6a2780e5198315a9f100c07b3bc86187d20a8
From: osstest service owner 
Date: Fri, 22 Mar 2024 07:28:54 +0000

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf                 7f1ffba5de3d9840dbeeba20fba165f2fb724941
baseline version:
 ovmf                 35f6a2780e5198315a9f100c07b3bc86187d20a8

Last test of basis   185098  2024-03-19 12:43:35 Z    2 days
Testing same since   185138  2024-03-22 05:12:55 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Dat Mach 

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-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   35f6a2780e..7f1ffba5de  7f1ffba5de3d9840dbeeba20fba165f2fb724941 -> xen-tested-master


From xen-devel-bounces@lists.xenproject.org Fri Mar 22 07:56:09 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Mar 2024 07:56:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696683.1087787 (Exim 4.92)
	(envelope-from )
	id 1rnZkw-0004va-B3; Fri, 22 Mar 2024 07:56:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696683.1087787; Fri, 22 Mar 2024 07:56:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnZkw-0004vT-8Q; Fri, 22 Mar 2024 07:56:02 +0000
Received: by outflank-mailman (input) for mailman id 696683;
 Fri, 22 Mar 2024 07:56:01 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnZkv-0004vN-Bj
 for xen-devel@lists.xenproject.org; Fri, 22 Mar 2024 07:56:01 +0000
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com
 [2a00:1450:4864:20::62a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9e97d003-e821-11ee-afe0-a90da7624cb6;
 Fri, 22 Mar 2024 08:56:00 +0100 (CET)
Received: by mail-ej1-x62a.google.com with SMTP id
 a640c23a62f3a-a44665605f3so212122266b.2
 for ; Fri, 22 Mar 2024 00:55:58 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 z27-20020a170906715b00b00a470dfe7e06sm733098ejj.118.2024.03.22.00.55.57
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 22 Mar 2024 00:55:58 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9e97d003-e821-11ee-afe0-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711094158; x=1711698958; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=YFxXQpkh7JGNlEyCKQ+2+VA78aIIL4f5uVYsQolcK+0=;
        b=fjzyu7kZZHEWvfv/ABGBQf45U9Nu4touu3KoAa11FDV4sNsRdnhkhOCkd0kzYoS0vi
         I8tN/37pU9ZLRqFfSC2Zd5V5JvRgR6srrsLIthHE/q2xZCVRu0MmsjPxIqAORs1WmAXu
         WdBgDw6mY0zwTEHFUuibqBefTkCxufkDTSTLmn5ltwjX5qVzPWz9JvswfxRUD8PEu4Lr
         KjnJkplBpKmxAlkOWtcC3QTjGDd9Huj7W8dW0v9OHbz7hX8h/BBjMsY51GChPG7FoOhF
         B4V0T0zDqkjh0G1E7BedEURmNdK6w6N0GuQJPtRoVGZjjctHXyALLxKgJjsJtM3SEpcd
         3O3g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711094158; x=1711698958;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=YFxXQpkh7JGNlEyCKQ+2+VA78aIIL4f5uVYsQolcK+0=;
        b=L0uy4Uirls/Sp2MZiqFcZ6XRqwv6ck7+7X57plmAnQaDitncEsy6nmF56z0tnzkC1s
         NfVHA+mItfJpJemEhktSWE62k1J83G11EsbAbR4orQwgLAxb08laTWJcVEknalz9qOvu
         zRf+7fvGoH2sNr9NDmesV1kAUqvXKgBVQXvKy/NuaYaPPkmOexDfCfH+vuUYoFbJYXFL
         F4xB8n3eHSJsXWZtww3zJOyWgk1iPSkO7FDWOGovKEullRrT+FzeKEXfGYhNwgY5hUvP
         IHpEvipcO03EjlSuq+bI2ee3e+UdGTiMeiT8cSEb12eJrA/3DBJAYvxgsEU2IgrAeglp
         WZwg==
X-Forwarded-Encrypted: i=1; AJvYcCXSjfNeNKVm/BEMPxSfbKxL3U5z5t46qtDW/e6fHin1ch5mO1CQIHYBAbOVG4mvjQBMKZb9hTj9AbOt9JP8pimUHdbNiVzYPOCWo49O3/4=
X-Gm-Message-State: AOJu0YyztZbGWU9KTYwklS5vl6TvcUgVLHUo4hEa8+YKdc8TLDl3Tzgi
	3CVt2Qp7i47J8KGdOTBErLIFpfh3/eOWzkvMX8PGI4LvRtUeB/syGBMGP7BaIQ==
X-Google-Smtp-Source: AGHT+IE/H8K8ML+12BQz94m7zC/R1jnshkZPpeOUkZc4s4yW+jrRZie0WdZEuXIofG0xwfz1bLDJRw==
X-Received: by 2002:a17:906:d9ca:b0:a47:ae0:160 with SMTP id qk10-20020a170906d9ca00b00a470ae00160mr1130903ejb.73.1711094158328;
        Fri, 22 Mar 2024 00:55:58 -0700 (PDT)
Message-ID: <4268b0de-e959-42aa-bc5c-0c48a359ea1d@suse.com>
Date: Fri, 22 Mar 2024 08:55:56 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 5/9] xen/device-tree: Move Arm's setup.c bootinfo
 functions to common
Content-Language: en-US
To: Julien Grall 
Cc: tpearson@raptorengineering.com, Andrew Cooper
 , George Dunlap ,
 Stefano Stabellini , Wei Liu ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 "Daniel P. Smith" ,
 Shawn Anastasio ,
 xen-devel@lists.xenproject.org
References: 
 <039524d4157dddb2faf6887739a727f6e993b53f.1710443965.git.sanastasio@raptorengineering.com>
 <19c4d0c2-c69c-4310-bf02-28d3894f8006@xen.org>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <19c4d0c2-c69c-4310-bf02-28d3894f8006@xen.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 21.03.2024 18:47, Julien Grall wrote:
> On 14/03/2024 22:15, Shawn Anastasio wrote:
>> Arm's setup.c contains a collection of functions for parsing memory map
>> and other boot information from a device tree. Since these routines are
>> generally useful on any architecture that supports device tree booting,
>> move them into xen/common/device-tree.
>>
>> Suggested-by: Julien Grall 
>> Signed-off-by: Shawn Anastasio 
>> ---
>>   MAINTAINERS                       |   1 +
>>   xen/arch/arm/setup.c              | 419 --------------------------
>>   xen/common/Makefile               |   1 +
>>   xen/common/device-tree/Makefile   |   1 +
>>   xen/common/device-tree/bootinfo.c | 469 ++++++++++++++++++++++++++++++
> 
> The new bootinfo.c is exported quite a few functions. Please introduce
> an generic header with the associated functions/structures.

By "generic" you don't mean a header in asm-generic/, do you?

Jan


From xen-devel-bounces@lists.xenproject.org Fri Mar 22 08:01:07 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Mar 2024 08:01:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696692.1087797 (Exim 4.92)
	(envelope-from )
	id 1rnZpp-0007Lg-CI; Fri, 22 Mar 2024 08:01:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696692.1087797; Fri, 22 Mar 2024 08:01:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnZpp-0007LZ-9Z; Fri, 22 Mar 2024 08:01:05 +0000
Received: by outflank-mailman (input) for mailman id 696692;
 Fri, 22 Mar 2024 08:01:03 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnZpn-0007LT-7y
 for xen-devel@lists.xenproject.org; Fri, 22 Mar 2024 08:01:03 +0000
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com
 [2a00:1450:4864:20::62d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 537b7f26-e822-11ee-afe0-a90da7624cb6;
 Fri, 22 Mar 2024 09:01:02 +0100 (CET)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-a471f77bf8eso123320766b.2
 for ; Fri, 22 Mar 2024 01:01:02 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 x19-20020a170906299300b00a46a2ac0dbasm728592eje.197.2024.03.22.01.01.01
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 22 Mar 2024 01:01:01 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 537b7f26-e822-11ee-afe0-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711094462; x=1711699262; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=1qtQH0sSUATxal0L789QdEHYXyPfcvXqfHEhjx3+QjU=;
        b=Lm6nRmHkHvc2n6+UIzj+zC90rUa/DqtMibbIuKni784R80N75Z5Zv3W8jokBYqFBN1
         Bdq65fO+Gcl4f7aLQuHUA3OZ0r0LHbzi4dWBNsNaIk7GwdNGKhp4VewjUhWOnGnXeFsH
         TtkdHmW5uGfQYqsliuECyij026veq2H/p50CztMAdYXAlamaeQtPkUTKAAmBvMws2CsR
         MB9Klx8bAuu64S7N8/UIOpIj37RqpPht4Be/pDXIVHaNS8w/7AnMrrIo9Dlje6sV19XR
         HdileNeou91Tm1zIvgmyDDJ/KzaGL6X8TJMqn42Y1yt4IQbfyBCNbOFojOUWDFD7/QGs
         jPwQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711094462; x=1711699262;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=1qtQH0sSUATxal0L789QdEHYXyPfcvXqfHEhjx3+QjU=;
        b=om6X1vTpSyJl5KTOPgmnzF1rTWjv/+4MGLYZfv+KMIF3ffscG0IfLj2W9IXc0NJfb2
         KUGKylk/5PM75h/bYPwXFj3qpyAcfblSRgFJkj0sS3HZCf5y8T8mw2ks5NQJ3wb/NBDO
         22rhDWpzmiLhGYVVPHZteFdOAK+OZW7QV9YEmRFFJTfxLHzXtBFUxQrhPAY+JoJMIGUK
         XPk4ZUgQ7FFeOre0DQ/2IrPyqucPbVkHrdl7GtqsYUeEWoca7STE28ihVlOagUxe5byK
         37h1ZIpPf4R/g7IAtEyil+MBXCpZ4ohh2ElSk103JGW6oiln+dqEG9ewic8rtKhb3+FV
         q4vw==
X-Forwarded-Encrypted: i=1; AJvYcCXWgBBvABwwIVM6KIuDxEWo1AJqjZupnkP2fEZQ89UHgVz60VEszBu+2kUg9EWy2tbPaN5R8x2skWXbcPyqtZRt1457jqc7Nqu5AyM1VYU=
X-Gm-Message-State: AOJu0YxrLv9jMveTOkrJmBLvwZQWVA6WxM81EYVaabXXjV2FZ//dUK/z
	3OI2D0szITLL6lmYETVfrpBXCrfu3iT6NbzSa5JMZfwc3Wz8lhwb8nrjTeDNqw==
X-Google-Smtp-Source: AGHT+IE6+WUqQQ5bKRNRF05eTh6gNQuJnXZx3CkNfXarpaR0WUCXMaBx++LNXEkUDG1/lo2iaXjJMQ==
X-Received: by 2002:a17:906:af0f:b0:a46:8d95:ff7e with SMTP id lx15-20020a170906af0f00b00a468d95ff7emr1156462ejb.21.1711094461866;
        Fri, 22 Mar 2024 01:01:01 -0700 (PDT)
Message-ID: <3a98757d-998e-4731-a508-5e7e1fc5aef2@suse.com>
Date: Fri, 22 Mar 2024 09:01:00 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 1/9] EFI: Introduce inline stub for efi_enabled on !X86
 && !ARM
Content-Language: en-US
To: Shawn Anastasio 
Cc: tpearson@raptorengineering.com, Andrew Cooper
 , George Dunlap ,
 Julien Grall , Stefano Stabellini ,
 Wei Liu , xen-devel@lists.xenproject.org
References: 
 <39069a589f9c4dc0db9b01b7412c1a99bea55f37.1710443965.git.sanastasio@raptorengineering.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <39069a589f9c4dc0db9b01b7412c1a99bea55f37.1710443965.git.sanastasio@raptorengineering.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 14.03.2024 23:15, Shawn Anastasio wrote:
> --- a/xen/include/xen/efi.h
> +++ b/xen/include/xen/efi.h
> @@ -31,7 +31,15 @@ union compat_pf_efi_info;
>  struct xenpf_efi_runtime_call;
>  struct compat_pf_efi_runtime_call;
>  
> +#if defined(CONFIG_X86) || defined(CONFIG_ARM)
>  bool efi_enabled(unsigned int feature);
> +#else
> +static inline bool efi_enabled(unsigned int feature)
> +{
> +    return false;
> +}
> +#endif

While fine as is for now, surely Arm32 could benefit from the inline stub,
too.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Mar 22 08:04:13 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Mar 2024 08:04:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696694.1087807 (Exim 4.92)
	(envelope-from )
	id 1rnZso-000834-Q3; Fri, 22 Mar 2024 08:04:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696694.1087807; Fri, 22 Mar 2024 08:04:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnZso-00082x-N0; Fri, 22 Mar 2024 08:04:10 +0000
Received: by outflank-mailman (input) for mailman id 696694;
 Fri, 22 Mar 2024 08:04:10 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnZso-00082p-7K
 for xen-devel@lists.xenproject.org; Fri, 22 Mar 2024 08:04:10 +0000
Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com
 [2a00:1450:4864:20::52f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c05206bc-e822-11ee-a1ee-f123f15fe8a2;
 Fri, 22 Mar 2024 09:04:05 +0100 (CET)
Received: by mail-ed1-x52f.google.com with SMTP id
 4fb4d7f45d1cf-56bdc2a2c96so833915a12.0
 for ; Fri, 22 Mar 2024 01:04:08 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 b12-20020a0564021f0c00b00568299df7f0sm753195edb.1.2024.03.22.01.04.06
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 22 Mar 2024 01:04:07 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c05206bc-e822-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711094647; x=1711699447; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=TusoSPZpWXAYeArHXRaN19wVsXpDy9CbKEn5rcCCNdk=;
        b=VfTLPeln1yobaDGTUHo33tdjkdBnWJCzLaq1smcJZuVhHOq1fbzCLyEQdu0knC9Rqp
         l066Y9xU0OHF9UFr0CIjpt/bXlxLudNGsopcxGjjP0Nq/Y3e/+dxpuvIJX/Df/6sb7dU
         x4ySGKL7PFYzatrwTMlqKOwrTZKrruX6JlVcPYM5t52lmFcpBvL48C0OrHvVzSkENl1e
         hUVdCAg1gEH62OJhs9XUM8UbnPNbXZZntg+lN9rTkVjmbAnPkPIryG+/d38MknaRwIuV
         v9G/kvke0jAozKW1/UF9FOJi3HHzSGTdXyWjtATFV/viLkNwqAB4EO0jKUcGc4jx+57z
         KA5g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711094647; x=1711699447;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=TusoSPZpWXAYeArHXRaN19wVsXpDy9CbKEn5rcCCNdk=;
        b=Dgpab0ETdRGuvw6BSOEGRBTOF6XQutLT7kOd53sLUMwjSUQ9uTw+Oj2GswkfIQeg8e
         /JqIXiRM1+aqLCGRS19Z4NasJUMM5dMuPMoMxuASFeOqXsL4PUU7NmJgfEAb2DRWq/I6
         44B1l5EKIEKTSmYKn5HuVrDkQyI//OquyeyBu5r5BcVShTGq9yFeKU1TphrHKUs6nf2j
         JaQZg8PaR33LkakpNxVibwwpoho3Y8oYG33lXw0Uw4hQ+tLbH8f8QBshNL6SaLtXVILB
         kvIvnJZi/Bx2VWi+CpzsQ0iXRhYXf37TPNlMIq/3AV59eePT+NjWvQELKgZq9N1yZCfX
         VkgQ==
X-Forwarded-Encrypted: i=1; AJvYcCWnbNPXyMSE/ogg/z+qJ2SNIdID1xskoHvSl4iCpq4heEXhrQbxk8Pm8euEIEVSbPX0jM6G/k30A7d7QTy+2H72fYGSDkW8Zj4I5jaPhx0=
X-Gm-Message-State: AOJu0YzWbefGudU9cqhYcy1rxUr47G2kP66lf2tIIF4sHNMLslghf4og
	dVrNayMlBlD4yyz2YFw/Hy44JuBIs6q2WRB0SbnF2FX87VykjTgqKAiRmfHEN6cY8a/3NpH7dSk
	=
X-Google-Smtp-Source: AGHT+IHX6oz4s6YHw/uR1W7YAP5t8PQKjHCqhyY1tMgbgGPT/tG8wIDHk8zzEPesaTVt+9YXxT2wqQ==
X-Received: by 2002:a50:d641:0:b0:564:5150:76a2 with SMTP id c1-20020a50d641000000b00564515076a2mr1035223edj.4.1711094647449;
        Fri, 22 Mar 2024 01:04:07 -0700 (PDT)
Message-ID: <6e8007b9-e1e9-4f3e-bef9-49a905d68fbf@suse.com>
Date: Fri, 22 Mar 2024 09:04:06 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 4/9] xen/ppc: Update setup.h with required definitions
 for bootfdt
Content-Language: en-US
To: Shawn Anastasio 
Cc: tpearson@raptorengineering.com, xen-devel@lists.xenproject.org
References: 
 <2c14419bd9fbd5307fe4d5b079a9927e4d3ec9fc.1710443965.git.sanastasio@raptorengineering.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <2c14419bd9fbd5307fe4d5b079a9927e4d3ec9fc.1710443965.git.sanastasio@raptorengineering.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 14.03.2024 23:15, Shawn Anastasio wrote:
> --- a/xen/arch/ppc/include/asm/setup.h
> +++ b/xen/arch/ppc/include/asm/setup.h
> @@ -3,4 +3,116 @@
>  
>  #define max_init_domid (0)
>  
> +#include 
> +#include 
> +#include 

Besides this not matching our aimed-at ordering (at least asm/ after xen/),
what for do you need asm/p2m.h here in the first place?

Jan


From xen-devel-bounces@lists.xenproject.org Fri Mar 22 08:08:22 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Mar 2024 08:08:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696698.1087816 (Exim 4.92)
	(envelope-from )
	id 1rnZwp-0000Ck-AP; Fri, 22 Mar 2024 08:08:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696698.1087816; Fri, 22 Mar 2024 08:08:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnZwp-0000Cd-7O; Fri, 22 Mar 2024 08:08:19 +0000
Received: by outflank-mailman (input) for mailman id 696698;
 Fri, 22 Mar 2024 08:08:18 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rnZwo-0000CX-Gk
 for xen-devel@lists.xenproject.org; Fri, 22 Mar 2024 08:08:18 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 54301543-e823-11ee-a1ee-f123f15fe8a2;
 Fri, 22 Mar 2024 09:08:13 +0100 (CET)
Received: from [192.168.1.9] (net-93-144-106-196.cust.dsl.teletu.it
 [93.144.106.196])
 by support.bugseng.com (Postfix) with ESMTPSA id 1C2784EE0742;
 Fri, 22 Mar 2024 09:08:15 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 54301543-e823-11ee-a1ee-f123f15fe8a2
Message-ID: <326f84ad-9c8f-47b5-b725-bf4f00e583e0@bugseng.com>
Date: Fri, 22 Mar 2024 09:08:14 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 1/2] automation/eclair: add deviation for MISRA C:2012
 Rule 17.1
To: Stefano Stabellini ,
 Jan Beulich 
Cc: consulting@bugseng.com, Doug Goldstein ,
 Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Wei Liu , xen-devel@lists.xenproject.org
References: 
 <882b442c8c1f73f8116676ab9351defe5c9609ac.1710923235.git.simone.ballarin@bugseng.com>
 <9341a711-74c3-463f-8cc2-a54e19b4b2f4@suse.com>
 
 
 
Content-Language: en-US
From: Simone Ballarin 
Organization: BUGSENG
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 21/03/24 19:00, Stefano Stabellini wrote:
> On Thu, 21 Mar 2024, Jan Beulich wrote:
>> On 21.03.2024 02:50, Stefano Stabellini wrote:
>>> On Wed, 20 Mar 2024, Jan Beulich wrote:
>>>> On 20.03.2024 09:50, Simone Ballarin wrote:
>>>>> MISRA C:2012 Rule 17.1 states:
>>>>> The features of `' shall not be used
>>>>>
>>>>> The Xen community wants to avoid using variadic functions except for
>>>>> specific circumstances where it feels appropriate by strict code review.
>>>>>
>>>>> Add deviation for functions related to console output (printk and similar).
>>>>>
>>>>> Signed-off-by: Simone Ballarin 
>>>>> ---
>>>>>   .../eclair_analysis/ECLAIR/deviations.ecl     | 26 +++++++++++++++++++
>>>>>   docs/misra/deviations.rst                     |  5 ++++
>>>>>   2 files changed, 31 insertions(+)
>>>>>
>>>>> diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
>>>>> index 9ac3ee4dfd..7c3559a3a0 100644
>>>>> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
>>>>> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
>>>>> @@ -382,6 +382,32 @@ explicit comment indicating the fallthrough intention is present."
>>>>>   -config=MC3R1.R16.6,switch_clauses+={deliberate, "default(0)"}
>>>>>   -doc_end
>>>>>   
>>>>> +#
>>>>> +# Series 17.
>>>>> +#
>>>>> +
>>>>> +-doc_begin="Functions related to console output are allowed to use the variadic features provided by stdarg.h."
>>>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(debugtrace_printk)&&kind(function))))"}
>>>>
>>>> This isn't concole output related.
>>>
>>> Should we say "related to console output or tracing" ?
>>>
>>>
>>>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(dt_dprintk)&&kind(function))))"}
>>>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(printk)&&kind(function))))"}
>>>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(guest_printk)&&kind(function))))"}
>>>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(panic)&&kind(function))))"}
>>>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(dprintk)&&kind(function))))"}
>>>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(gdprintk)&&kind(function))))"}
>>>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(snprintf)&&kind(function))))"}
>>>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(scnprintf)&&kind(function))))"}
>>>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(xasprintf)&&kind(function))))"}
>>>>
>>>> These three and ...
>>>>
>>>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(mm_printk)&&kind(function))))"}
>>>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(dbgp_printk)&&kind(function))))"}
>>>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(elf_call_log_callback)&&kind(function))))"}
>>>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(vsnprintf)&&kind(function))))"}
>>>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(vscnprintf)&&kind(function))))"}
>>>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(xvasprintf)&&kind(function))))"}
>>>>
>>>> ... these three aren't either.
>>>
>>> Maybe it is better to write it as:
>>>
>>> "Functions related printk, logging and tracing are allowed..."
>>
>> How about simply saying "printf()-like functions"? In what you suggest,
>> sprintf() and friends would still not be covered.
> 
> I like it
> 

Ok, great.

-- 
Simone Ballarin, M.Sc.

Field Application Engineer, BUGSENG (https://bugseng.com)



From xen-devel-bounces@lists.xenproject.org Fri Mar 22 08:17:01 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Mar 2024 08:17:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696704.1087826 (Exim 4.92)
	(envelope-from )
	id 1rna5A-0002M0-Te; Fri, 22 Mar 2024 08:16:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696704.1087826; Fri, 22 Mar 2024 08:16:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rna5A-0002Lt-R3; Fri, 22 Mar 2024 08:16:56 +0000
Received: by outflank-mailman (input) for mailman id 696704;
 Fri, 22 Mar 2024 08:16:55 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rna59-0002LY-8A
 for xen-devel@lists.xenproject.org; Fri, 22 Mar 2024 08:16:55 +0000
Received: from mail.zytor.com (unknown [2607:7c80:54:3::138])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8782feda-e824-11ee-a1ee-f123f15fe8a2;
 Fri, 22 Mar 2024 09:16:49 +0100 (CET)
Received: from terminus.zytor.com (terminus.zytor.com
 [IPv6:2607:7c80:54:3:0:0:0:136]) (authenticated bits=0)
 by mail.zytor.com (8.17.2/8.17.1) with ESMTPSA id 42M8GG9e3346191
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
 Fri, 22 Mar 2024 01:16:20 -0700
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8782feda-e824-11ee-a1ee-f123f15fe8a2
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 42M8GG9e3346191
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com;
	s=2024031401; t=1711095381;
	bh=k7eKfOcnuljC+WdHZ/WvG4Vv4XD7QPRuthF5whrgwF8=;
	h=From:To:Cc:Subject:Date:From;
	b=JuGtM0tfu2fMqhIFFArB2uZWF+01NrS3nd8DhPk1sXKePwN4vKwJm70aIdLap8sMt
	 bkSNerFhQQ257nyuye8Hd7DP+r2vcORa1bihR1bPrvDALT+J0KqxlXfg3hMFq3O4Fn
	 t1ynGTKCsGGFMh9bW0TCO/Q/8aeRhcN8ukr86ksHcMHFWq5eCvQVbXSDmR6tc8AjDE
	 TvuAclOnO93GMlohYvihnxb4fYZGdocn71wWdH6CqZXO9bISwZKIueiEhP33jCXTI/
	 bYTu7XZjgnuBvcECdB72tegow3CsDLVhb47IYC65XMLvkT7rYAX6zhyjMzNhuM8DP4
	 gh3QA90BSWvWA==
From: "Xin Li (Intel)" 
To: linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
        linux-arch@vger.kernel.org
Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de,
        dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com,
        jgross@suse.com, boris.ostrovsky@oracle.com, arnd@arndb.de
Subject: [PATCH v3 1/1] x86: Rename __{start,end}_init_task to __{start,end}_init_stack
Date: Fri, 22 Mar 2024 01:16:16 -0700
Message-ID: <20240322081616.3346181-1-xin@zytor.com>
X-Mailer: git-send-email 2.44.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The stack of a task has been separated from the memory of a task_struct
struture for a long time on x86, as a result __{start,end}_init_task no
longer mark the start and end of the init_task structure, but its stack
only.

Rename __{start,end}_init_task to __{start,end}_init_stack.

Note other architectures are not affected because __{start,end}_init_task
are used on x86 only.

Reviewed-by: Juergen Gross 
Signed-off-by: Xin Li (Intel) 
---

Change since v2:
* Rebase to the latest tip master branch.

Change since v1:
* Revert an accident insane change, init_task to init_stack (Jürgen Groß).
---
 arch/x86/kernel/vmlinux.lds.S     | 2 +-
 include/asm-generic/vmlinux.lds.h | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S
index d430880175f2..3509afc6a672 100644
--- a/arch/x86/kernel/vmlinux.lds.S
+++ b/arch/x86/kernel/vmlinux.lds.S
@@ -168,7 +168,7 @@ SECTIONS
 		INIT_TASK_DATA(THREAD_SIZE)
 
 		/* equivalent to task_pt_regs(&init_task) */
-		__top_init_kernel_stack = __end_init_task - TOP_OF_KERNEL_STACK_PADDING - PTREGS_SIZE;
+		__top_init_kernel_stack = __end_init_stack - TOP_OF_KERNEL_STACK_PADDING - PTREGS_SIZE;
 
 #ifdef CONFIG_X86_32
 		/* 32 bit has nosave before _edata */
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index cb46306d8305..9752eb420ffa 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -399,13 +399,13 @@
 
 #define INIT_TASK_DATA(align)						\
 	. = ALIGN(align);						\
-	__start_init_task = .;						\
+	__start_init_stack = .;						\
 	init_thread_union = .;						\
 	init_stack = .;							\
 	KEEP(*(.data..init_task))					\
 	KEEP(*(.data..init_thread_info))				\
-	. = __start_init_task + THREAD_SIZE;				\
-	__end_init_task = .;
+	. = __start_init_stack + THREAD_SIZE;				\
+	__end_init_stack = .;
 
 #define JUMP_TABLE_DATA							\
 	. = ALIGN(8);							\

base-commit: 93387dba36cc9033724d8b874a5cf6779ef084ab
-- 
2.44.0



From xen-devel-bounces@lists.xenproject.org Fri Mar 22 08:30:21 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Mar 2024 08:30:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696710.1087838 (Exim 4.92)
	(envelope-from )
	id 1rnaHv-0005vn-6r; Fri, 22 Mar 2024 08:30:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696710.1087838; Fri, 22 Mar 2024 08:30:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnaHv-0005v4-21; Fri, 22 Mar 2024 08:30:07 +0000
Received: by outflank-mailman (input) for mailman id 696710;
 Fri, 22 Mar 2024 08:30:05 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rnaHt-0005o0-Rs
 for xen-devel@lists.xenproject.org; Fri, 22 Mar 2024 08:30:05 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 61ed1463-e826-11ee-afe0-a90da7624cb6;
 Fri, 22 Mar 2024 09:30:04 +0100 (CET)
Received: from [192.168.1.9] (net-93-144-106-196.cust.vodafonedsl.it
 [93.144.106.196])
 by support.bugseng.com (Postfix) with ESMTPSA id 6B3434EE0742;
 Fri, 22 Mar 2024 09:30:03 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 61ed1463-e826-11ee-afe0-a90da7624cb6
Message-ID: 
Date: Fri, 22 Mar 2024 09:30:02 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 2/2] xen: address violations of MISRA C Rule 17.1
Content-Language: en-US
To: Stefano Stabellini ,
 Jan Beulich 
Cc: consulting@bugseng.com, Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Wei Liu , Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: 
 
 <4ce30a38-5b5c-4d4c-a0c4-8c1a63759203@suse.com>
 
From: Simone Ballarin 
Organization: BUGSENG
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 21/03/24 02:47, Stefano Stabellini wrote:
> On Wed, 20 Mar 2024, Jan Beulich wrote:
>> On 20.03.2024 09:51, Simone Ballarin wrote:
>>> MISRA C Rule 20.7 states: "The features of `' shall not be used"
>>>
>>> The Xen community wants to avoid using variadic functions except for
>>> specific circumstances where it feels appropriate by strict code review.
>>>
>>> Functions hypercall_create_continuation and hypercall_xlat_continuation
>>> are special hypercalls made to break long running hypercalls into multiple
>>> calls.
>>
>> Here and below: These aren't "special hypercalls". They're internal helper
>> functions.
> 
> +1
> 
> 
>>> They take a variable number of arguments depending on the original
>>> hypercall they are trying to continue.
>>
>> Am I misremembering or did Andrew outline a plan to eliminate the variadic-
>> ness from these? From certifiability perspective avoiding the need for a
>> deviation would likely be preferable?
> 
> For sure, it would be preferable. In the meantime we can have the SAF
> comment?

I agree in using the SAF comments as a temporary measure.
I'll propose a new patch with the fix requested by Jan.

-- 
Simone Ballarin, M.Sc.

Field Application Engineer, BUGSENG (https://bugseng.com)



From xen-devel-bounces@lists.xenproject.org Fri Mar 22 08:47:15 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Mar 2024 08:47:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696714.1087857 (Exim 4.92)
	(envelope-from )
	id 1rnaYR-0008LO-Ni; Fri, 22 Mar 2024 08:47:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696714.1087857; Fri, 22 Mar 2024 08:47:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnaYR-0008LH-KK; Fri, 22 Mar 2024 08:47:11 +0000
Received: by outflank-mailman (input) for mailman id 696714;
 Fri, 22 Mar 2024 08:47:09 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rnaYP-00086n-Pt
 for xen-devel@lists.xenproject.org; Fri, 22 Mar 2024 08:47:09 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c461f925-e828-11ee-afe0-a90da7624cb6;
 Fri, 22 Mar 2024 09:47:08 +0100 (CET)
Received: from beta.station (net-93-144-106-196.cust.dsl.teletu.it
 [93.144.106.196])
 by support.bugseng.com (Postfix) with ESMTPSA id 0A7724EE0C8A;
 Fri, 22 Mar 2024 09:47:07 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c461f925-e828-11ee-afe0-a90da7624cb6
From: Simone Ballarin 
To: xen-devel@lists.xenproject.org
Cc: consulting@bugseng.com,
	sstabellini@kernel.org,
	Simone Ballarin ,
	Doug Goldstein ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Wei Liu 
Subject: [XEN PATCH v2 1/2] automation/eclair: add deviation for MISRA C:2012 Rule 17.1
Date: Fri, 22 Mar 2024 09:46:17 +0100
Message-Id: 
X-Mailer: git-send-email 2.34.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

MISRA C:2012 Rule 17.1 states:
The features of `' shall not be used

The Xen community wants to avoid using variadic functions except for
specific circumstances where it feels appropriate by strict code review.

Add deviation for printf()-like functions.

Signed-off-by: Simone Ballarin 

---
Changes in v2:
- replace "console output related" with "printf()-like".
---
 .../eclair_analysis/ECLAIR/deviations.ecl     | 26 +++++++++++++++++++
 docs/misra/deviations.rst                     |  5 ++++
 2 files changed, 31 insertions(+)

diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
index 9ac3ee4dfd..334ee674c4 100644
--- a/automation/eclair_analysis/ECLAIR/deviations.ecl
+++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
@@ -382,6 +382,32 @@ explicit comment indicating the fallthrough intention is present."
 -config=MC3R1.R16.6,switch_clauses+={deliberate, "default(0)"}
 -doc_end
 
+#
+# Series 17.
+#
+
+-doc_begin="printf()-like functions are allowed to use the variadic features provided by stdarg.h."
+-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(debugtrace_printk)&&kind(function))))"}
+-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(dt_dprintk)&&kind(function))))"}
+-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(printk)&&kind(function))))"}
+-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(guest_printk)&&kind(function))))"}
+-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(panic)&&kind(function))))"}
+-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(dprintk)&&kind(function))))"}
+-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(gdprintk)&&kind(function))))"}
+-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(snprintf)&&kind(function))))"}
+-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(scnprintf)&&kind(function))))"}
+-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(xasprintf)&&kind(function))))"}
+-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(mm_printk)&&kind(function))))"}
+-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(dbgp_printk)&&kind(function))))"}
+-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(elf_call_log_callback)&&kind(function))))"}
+-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(vsnprintf)&&kind(function))))"}
+-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(vscnprintf)&&kind(function))))"}
+-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(xvasprintf)&&kind(function))))"}
+-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(vprintk_common)&&kind(function))))"}
+-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(guest_printk)&&kind(function))))"}
+-config=MC3R1.R17.1,macros+={hide , "^va_(arg|start|copy|end)$"}
+-doc_end
+
 #
 # Series 18.
 #
diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
index ce855ddae6..1e617f91f3 100644
--- a/docs/misra/deviations.rst
+++ b/docs/misra/deviations.rst
@@ -328,6 +328,11 @@ Deviations related to MISRA C:2012 Rules:
        improve readability.
      - Tagged as `deliberate` for ECLAIR.
 
+   * - R17.1
+     - printf()-like functions  are allowed to use the variadic features provided
+       by `stdarg.h`.
+     - Tagged as `deliberate` for ECLAIR.
+
    * - R20.7
      - Code violating Rule 20.7 is safe when macro parameters are used:
        (1) as function arguments;
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Mar 22 08:47:15 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Mar 2024 08:47:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696715.1087862 (Exim 4.92)
	(envelope-from )
	id 1rnaYS-0008Oj-01; Fri, 22 Mar 2024 08:47:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696715.1087862; Fri, 22 Mar 2024 08:47:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnaYR-0008Nt-Se; Fri, 22 Mar 2024 08:47:11 +0000
Received: by outflank-mailman (input) for mailman id 696715;
 Fri, 22 Mar 2024 08:47:11 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rnaYR-0008Hq-Es
 for xen-devel@lists.xenproject.org; Fri, 22 Mar 2024 08:47:11 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c2ffd4f2-e828-11ee-a1ee-f123f15fe8a2;
 Fri, 22 Mar 2024 09:47:06 +0100 (CET)
Received: from beta.station (net-93-144-106-196.cust.dsl.teletu.it
 [93.144.106.196])
 by support.bugseng.com (Postfix) with ESMTPSA id 9E44C4EE0C8D;
 Fri, 22 Mar 2024 09:47:08 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c2ffd4f2-e828-11ee-a1ee-f123f15fe8a2
From: Simone Ballarin 
To: xen-devel@lists.xenproject.org
Cc: consulting@bugseng.com,
	sstabellini@kernel.org,
	Simone Ballarin ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Wei Liu ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [XEN PATCH v2 2/2] xen: address violations of MISRA C Rule 17.1
Date: Fri, 22 Mar 2024 09:46:18 +0100
Message-Id: 
X-Mailer: git-send-email 2.34.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

MISRA C Rule 20.7 states: "The features of `' shall not be used"

The Xen community wants to avoid using variadic functions except for
specific circumstances where it feels appropriate by strict code review.

Functions hypercall_create_continuation and hypercall_xlat_continuation
are internal helper functions made to break long running hypercalls into
multiple calls. They take a variable number of arguments depending on the
original hypercall they are trying to continue.

Add SAF deviations for the aforementioned functions.

Signed-off-by: Simone Ballarin 

---
Changes in v2:
- replaced "special hypercalls" with "internal helper functions".
---
 docs/misra/safe.json     | 8 ++++++++
 xen/arch/arm/domain.c    | 1 +
 xen/arch/x86/hypercall.c | 2 ++
 3 files changed, 11 insertions(+)

diff --git a/docs/misra/safe.json b/docs/misra/safe.json
index 952324f85c..1145967213 100644
--- a/docs/misra/safe.json
+++ b/docs/misra/safe.json
@@ -28,6 +28,14 @@
         },
         {
             "id": "SAF-3-safe",
+            "analyser": {
+                "eclair": "MC3R1.R17.1"
+            },
+            "name": "Rule 17.1: internal helper functions made to break long running hypercalls into multiple calls.",
+            "text": "They need to take a variable number of arguments depending on the original hypercall they are trying to continue."
+        },
+        {
+            "id": "SAF-4-safe",
             "analyser": {},
             "name": "Sentinel",
             "text": "Next ID to be used"
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 5e7a7f3e7e..f5706bd5b8 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -382,6 +382,7 @@ unsigned long hypercall_create_continuation(
     const char *p = format;
     unsigned long arg, rc;
     unsigned int i;
+    /* SAF-3-safe allowed variadic function */
     va_list args;
 
     current->hcall_preempted = true;
diff --git a/xen/arch/x86/hypercall.c b/xen/arch/x86/hypercall.c
index 01cd73040d..18d8c75522 100644
--- a/xen/arch/x86/hypercall.c
+++ b/xen/arch/x86/hypercall.c
@@ -31,6 +31,7 @@ unsigned long hypercall_create_continuation(
     const char *p = format;
     unsigned long arg;
     unsigned int i;
+    /* SAF-3-safe allowed variadic function */
     va_list args;
 
     curr->hcall_preempted = true;
@@ -115,6 +116,7 @@ int hypercall_xlat_continuation(unsigned int *id, unsigned int nr,
     struct cpu_user_regs *regs;
     unsigned int i, cval = 0;
     unsigned long nval = 0;
+    /* SAF-3-safe allowed variadic function */
     va_list args;
 
     ASSERT(nr <= ARRAY_SIZE(mcs->call.args));
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Mar 22 08:47:16 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Mar 2024 08:47:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696713.1087847 (Exim 4.92)
	(envelope-from )
	id 1rnaYQ-000875-HE; Fri, 22 Mar 2024 08:47:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696713.1087847; Fri, 22 Mar 2024 08:47:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnaYQ-00086y-El; Fri, 22 Mar 2024 08:47:10 +0000
Received: by outflank-mailman (input) for mailman id 696713;
 Fri, 22 Mar 2024 08:47:09 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rnaYP-00086n-3u
 for xen-devel@lists.xenproject.org; Fri, 22 Mar 2024 08:47:09 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c4183ac8-e828-11ee-afe0-a90da7624cb6;
 Fri, 22 Mar 2024 09:47:08 +0100 (CET)
Received: from beta.station (net-93-144-106-196.cust.dsl.teletu.it
 [93.144.106.196])
 by support.bugseng.com (Postfix) with ESMTPSA id 2F06C4EE0742;
 Fri, 22 Mar 2024 09:47:07 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c4183ac8-e828-11ee-afe0-a90da7624cb6
From: Simone Ballarin 
To: xen-devel@lists.xenproject.org
Cc: consulting@bugseng.com,
	sstabellini@kernel.org,
	Simone Ballarin ,
	Doug Goldstein ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Wei Liu ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [XEN PATCH v2 0/2] xen: address violations of MISRA C Rule 17.1
Date: Fri, 22 Mar 2024 09:46:16 +0100
Message-Id: 
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

MISRA C Rule 20.7 states: "The features of `' shall not be used".

The Xen community wants to avoid using variadic functions except for
specific circumstances where it feels appropriate by strict code review.

Functions hypercall_create_continuation and hypercall_xlat_continuation
are internal helpers made to break long running hypercalls into multiple
calls. They take a variable number of arguments depending on the original
hypercall they are trying to continue. Add SAF deviations for the aforementioned
functions.

Add deviation for printf()-like functions.

---
Changes in v2:
- replace "related to console output" with "printf()-like functions";
- replace "special hypercalls" with "internal helpers".

Simone Ballarin (2):
  automation/eclair: add deviation for MISRA C:2012 Rule 17.1
  xen: address violations of MISRA C Rule 17.1

 .../eclair_analysis/ECLAIR/deviations.ecl     | 26 +++++++++++++++++++
 docs/misra/deviations.rst                     |  5 ++++
 docs/misra/safe.json                          |  8 ++++++
 xen/arch/arm/domain.c                         |  1 +
 xen/arch/x86/hypercall.c                      |  2 ++
 5 files changed, 42 insertions(+)

-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Mar 22 09:45:05 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Mar 2024 09:45:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696735.1087876 (Exim 4.92)
	(envelope-from )
	id 1rnbSG-0001Wl-9R; Fri, 22 Mar 2024 09:44:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696735.1087876; Fri, 22 Mar 2024 09:44:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnbSG-0001We-6x; Fri, 22 Mar 2024 09:44:52 +0000
Received: by outflank-mailman (input) for mailman id 696735;
 Fri, 22 Mar 2024 09:44:51 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnbSF-0001WX-BK
 for xen-devel@lists.xenproject.org; Fri, 22 Mar 2024 09:44:51 +0000
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com
 [2a00:1450:4864:20::62a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d2f3bd35-e830-11ee-a1ee-f123f15fe8a2;
 Fri, 22 Mar 2024 10:44:49 +0100 (CET)
Received: by mail-ej1-x62a.google.com with SMTP id
 a640c23a62f3a-a46de423039so115364266b.0
 for ; Fri, 22 Mar 2024 02:44:49 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 g3-20020a056402428300b0056be85c253fsm250579edc.95.2024.03.22.02.44.48
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 22 Mar 2024 02:44:48 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d2f3bd35-e830-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711100688; x=1711705488; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=Qw8S7K1Hm4gAHHaOUPt/F7r8qcv9cqpwWMiXnqfyoV0=;
        b=Tkz8M/yrbOEUwcI4B6WLwM1+vNDVQ3Tm896qx7A3CGQLMa5TYThnQJmwBTAR8BEtv2
         kpLfbnKYTNBVP9OTfOwjmm5v5XOttfKqtvqM2vPvU3BhSnMVDOtzmbEnEK1nKpbokrcw
         MtUxSz1VDzjXFjUt7+/OW/6yxej3mdjjPRpOBLPAGSWRRqRjfTqLgIQvl7/ltGZ+vcou
         w+YoHAoovgNK+qh4tR/K7dVhVZj2DUBGc2QEzV1gPXOXPP0ZtWQGUlcY9+p4/kAjdEkH
         J31m1nzTyxgnt1dmuiWNb7g20V6x1loXMleCZtqRd80T1mMLjsGrOxUsC2lu3WnE1SXp
         XJJg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711100688; x=1711705488;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=Qw8S7K1Hm4gAHHaOUPt/F7r8qcv9cqpwWMiXnqfyoV0=;
        b=uaHup0u8OziWTOs1WBIXOJnZ/dMla4Gw5uRuYNkBwBxP8D1c3rd62/8yq6nKiAa1uS
         FmBZyXvEEwZ/9EaAGmMdPln2Uj3PFm4SPdSwx55E+bmvKOHAH6WGAqCBNHfun7VaSs7L
         Ae67DqCRgE95GOmMDvkzBa7xbpSKteho9Tl4pVmjFHpCZpPAqcebwyA/P2xmSnuaU/dd
         PTrZ8M9Gbj4nz+gJYsLtfEQhVrm+h2cWEeSL8kOwd9VaqaUwPuXNtI/V/j8GqMQCUiU4
         o88h4T01fbwfKYt00JBgkACcrcdPLSkzUdyvppVh4ppo1sHVqOirUQRQgNmAx5N0o6Rt
         TJ+A==
X-Forwarded-Encrypted: i=1; AJvYcCU4945Am1feJePUv2m1APBP1zgPMLBdx8PI3AB0eWzLVxfvPNq+L5bxjn8JAa32H2xkWIdrAmy/qeE150yqT6b30Kj8EZDChLqpTuAn2UE=
X-Gm-Message-State: AOJu0YydW6eqbVep7UUHlnXnOGIh/+7v/VRn3ATiIXT5GvBoNqu8LUd7
	qWVrzdGCnwa34dCysP9GbBJJhbVEMLh6cLi7QudTlyD322+fHg5S1HlVGRpMDw==
X-Google-Smtp-Source: AGHT+IEquf/1Y0Q48cmuK2snk2JD7hr3KFcS/fWJ5wg7PRKkKaE4n28ReLHPoFBOM9PdtdXidu4OwA==
X-Received: by 2002:a50:8e56:0:b0:568:a90f:2e67 with SMTP id 22-20020a508e56000000b00568a90f2e67mr1511062edx.34.1711100688608;
        Fri, 22 Mar 2024 02:44:48 -0700 (PDT)
Message-ID: <9c6f4afd-00af-41f0-86dc-4f4558cb739c@suse.com>
Date: Fri, 22 Mar 2024 10:44:47 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH v2 1/2] automation/eclair: add deviation for MISRA
 C:2012 Rule 17.1
Content-Language: en-US
To: Simone Ballarin 
Cc: consulting@bugseng.com, sstabellini@kernel.org,
 Doug Goldstein , Andrew Cooper
 , George Dunlap ,
 Julien Grall , Wei Liu ,
 xen-devel@lists.xenproject.org
References: 
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 22.03.2024 09:46, Simone Ballarin wrote:
> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> @@ -382,6 +382,32 @@ explicit comment indicating the fallthrough intention is present."
>  -config=MC3R1.R16.6,switch_clauses+={deliberate, "default(0)"}
>  -doc_end
>  
> +#
> +# Series 17.
> +#
> +
> +-doc_begin="printf()-like functions are allowed to use the variadic features provided by stdarg.h."
> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(debugtrace_printk)&&kind(function))))"}
> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(dt_dprintk)&&kind(function))))"}
> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(printk)&&kind(function))))"}
> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(guest_printk)&&kind(function))))"}
> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(panic)&&kind(function))))"}
> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(dprintk)&&kind(function))))"}
> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(gdprintk)&&kind(function))))"}
> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(snprintf)&&kind(function))))"}
> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(scnprintf)&&kind(function))))"}
> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(xasprintf)&&kind(function))))"}
> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(mm_printk)&&kind(function))))"}
> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(dbgp_printk)&&kind(function))))"}
> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(elf_call_log_callback)&&kind(function))))"}
> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(vsnprintf)&&kind(function))))"}
> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(vscnprintf)&&kind(function))))"}
> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(xvasprintf)&&kind(function))))"}
> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(vprintk_common)&&kind(function))))"}
> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(guest_printk)&&kind(function))))"}
> +-config=MC3R1.R17.1,macros+={hide , "^va_(arg|start|copy|end)$"}
> +-doc_end

Repeating v1 comments which weren't addressed:

Is there a reason xyzprintk() are all listed individually? Surely if
we'd introduce a new flavor, we'd want that excluded too.

{,g}dprintk() in neither of their incarnation use any of the va_*
items listed. Why do they need mentioning here?

Jan


From xen-devel-bounces@lists.xenproject.org Fri Mar 22 09:53:49 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Mar 2024 09:53:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696738.1087886 (Exim 4.92)
	(envelope-from )
	id 1rnbas-0003Oq-40; Fri, 22 Mar 2024 09:53:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696738.1087886; Fri, 22 Mar 2024 09:53:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnbas-0003Oj-1G; Fri, 22 Mar 2024 09:53:46 +0000
Received: by outflank-mailman (input) for mailman id 696738;
 Fri, 22 Mar 2024 09:53:44 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnbaq-0003OZ-F1; Fri, 22 Mar 2024 09:53:44 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnbaq-0007ud-2H; Fri, 22 Mar 2024 09:53:44 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnbap-0003Aw-PC; Fri, 22 Mar 2024 09:53:43 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rnbap-0008Id-Od; Fri, 22 Mar 2024 09:53:43 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=bYnN43GDrPKESt7CNWMvFvKssS6YJ/FcpHs6fAV/Deg=; b=n5eRTRptRAFQq/PHb0Eok+7ep4
	lg7+QXr3/Ie5DdpVXZXrKPT1tQRmTqOMwsnuIEQpdIVXqwzZj6+ZZyhd9VnmmGZYZvvaq7QRYv059
	DNGd9Ry8FB5vP6buMjmayT6hT3XCdnXqdHVvRMFJc3EJzhgiLCgpN0Z5nIyUnL4jQfIw=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 185137: tolerable FAIL - PUSHED
X-Osstest-Failures:
    xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-qcow2:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-qcow2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-vhd:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-raw:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    xen=cbe393b709e0c6c3e2b10c3ac69fbea0abd530fe
X-Osstest-Versions-That:
    xen=eaafbd11344a8ec32309fe58a6e529fe1c34d62e
From: osstest service owner 
Date: Fri, 22 Mar 2024 09:53:43 +0000

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen                  cbe393b709e0c6c3e2b10c3ac69fbea0abd530fe
baseline version:
 xen                  eaafbd11344a8ec32309fe58a6e529fe1c34d62e

Last test of basis   185124  2024-03-21 12:49:59 Z    0 days
Testing same since   185137  2024-03-22 00:40:56 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper 
  Anthony PERARD 
  Carlo Nonato 
  Elliott Mitchell 
  Jan Beulich 
  Julien Grall 
  Roger Pau Monné 
  Shawn Anastasio 

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-libvirt-qcow2                               pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-xl-qcow2                                    pass    
 test-amd64-amd64-libvirt-raw                                 pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-amd64-amd64-xl-raw                                      pass    
 test-armhf-armhf-xl-raw                                      pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-libvirt-vhd                                 pass    
 test-amd64-amd64-xl-vhd                                      pass    
 test-arm64-arm64-xl-vhd                                      pass    


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

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

Explanation of these 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
   eaafbd1134..cbe393b709  cbe393b709e0c6c3e2b10c3ac69fbea0abd530fe -> master


From xen-devel-bounces@lists.xenproject.org Fri Mar 22 10:30:25 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Mar 2024 10:30:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696756.1087933 (Exim 4.92)
	(envelope-from )
	id 1rncAE-0001Bm-Ex; Fri, 22 Mar 2024 10:30:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696756.1087933; Fri, 22 Mar 2024 10:30:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rncAE-0001Bf-BC; Fri, 22 Mar 2024 10:30:18 +0000
Received: by outflank-mailman (input) for mailman id 696756;
 Fri, 22 Mar 2024 10:30:16 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rncAC-0001BZ-EO
 for xen-devel@lists.xenproject.org; Fri, 22 Mar 2024 10:30:16 +0000
Received: from NAM04-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam04on20600.outbound.protection.outlook.com
 [2a01:111:f403:240a::600])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2a5cd292-e837-11ee-afe0-a90da7624cb6;
 Fri, 22 Mar 2024 11:30:14 +0100 (CET)
Received: from BN9PR03CA0426.namprd03.prod.outlook.com (2603:10b6:408:113::11)
 by PH8PR12MB7159.namprd12.prod.outlook.com (2603:10b6:510:229::10)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.30; Fri, 22 Mar
 2024 10:30:08 +0000
Received: from BN1PEPF00004681.namprd03.prod.outlook.com
 (2603:10b6:408:113:cafe::a5) by BN9PR03CA0426.outlook.office365.com
 (2603:10b6:408:113::11) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.13 via Frontend
 Transport; Fri, 22 Mar 2024 10:30:07 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN1PEPF00004681.mail.protection.outlook.com (10.167.243.87) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Fri, 22 Mar 2024 10:30:07 +0000
Received: from SATLEXMB08.amd.com (10.181.40.132) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Fri, 22 Mar
 2024 05:30:06 -0500
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB08.amd.com
 (10.181.40.132) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Fri, 22 Mar
 2024 03:30:06 -0700
Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Fri, 22 Mar 2024 05:30:05 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2a5cd292-e837-11ee-afe0-a90da7624cb6
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=DvAakGqV2T7tpIb0aUHOLCtcqhYD+YShDu81mdiW7DN9Vn/jjd1oc6xFtuifHyGkgQ6cvk0B/0b5ja2bWzX2zZk8eDeR9zw8OPakT3bNdk6y2K6rwXi+0F6v+fZlsJuh8W1LCXg7recLtnOowaVnvdJRWEBDRUFOypsFLEiKIPa2JZfrst1mWzeUgFZ+JR6vCaMOwa0GHoT1r89xp8wMq8jfpWx+sJ+twYFvV0NxyiXkJlrsedzouqltQN6a69telb2l3XrSG2txomC2Z5vKgnUC3EyJh3bx9tCaAte+816P11rIQom823TGVFENJZlNyFDxBvw/GsPXZHrvisJ/Cg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=zELJwZbc7DZgcyAZiRYp9QmzK2AJTx2/K1xrP3rVSXc=;
 b=LIDfmQxTQuHM1n9PnVy29H9xuLBEI1vi2Vo1E1emolCV6QzbwaBHsLf4w7W2mV68u0+U6VDqE9v9Wp73bHh3dJ9BDWJOTmQ58B2qGfK5pxwYEpwMb2qWTlrv4Nx+tE4OjwwGqhL7P9OCA0xm/ADOoc/lLIbslB1AjWYAXHToOX5EtPyQ/FoB+BoOMApjDg6ozu3/cVzmsP8b9IKZ04+boqL/fR1leUsWagGSIT5cWkGiR3y8v0tSZpjv5os5QBaBgL8VtXaU8k5NzoutNVsmgyBLPyX6Av5OxPopJ9smr24Y/u0QHAsLfq2Ffb/T3/O14V3v3ySXCAPX1tb00yhEmQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=arm.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=zELJwZbc7DZgcyAZiRYp9QmzK2AJTx2/K1xrP3rVSXc=;
 b=I07stRSTdKfFsz47sxL70duqpzYUgKCvxid/PO1nf+SL4Ysk82xB005VXnUCaZh8kXp7dvhDjH/S/6mMWGQptR0min/Hqc0yIVvB4GncjVyBH9PP3P8uBy8jjGpy2UvaLjJkJIZ5SeTlaW+BiBjJ/kpam5CGRV1oesKCWZIlEBQ=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Message-ID: <1cfde34b-6d03-4a18-81af-2e2a0195190e@amd.com>
Date: Fri, 22 Mar 2024 11:30:04 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 08/11] xen/arm: Reduce struct membank size on static
 shared memory
Content-Language: en-US
To: Luca Fancellu , 
CC: Stefano Stabellini , Julien Grall
	, Bertrand Marquis , "Volodymyr
 Babchuk" 
References: <20240312130331.78418-1-luca.fancellu@arm.com>
 <20240312130331.78418-9-luca.fancellu@arm.com>
From: Michal Orzel 
In-Reply-To: <20240312130331.78418-9-luca.fancellu@arm.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN1PEPF00004681:EE_|PH8PR12MB7159:EE_
X-MS-Office365-Filtering-Correlation-Id: 042116e8-6bfb-4d6e-7409-08dc4a5b0b4a
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	dh8g30jpGVPg4vtTxQh66sv/H5qFXf+1M4CEOSJabMYivZ3Wpryo+PlJbL/rAffptgEemOD+EcY8cuysWCKUb0ZT5MjNBG9slt175LqqtCePOLlgxkLX3Ur2HDse/VX0aXQw2rBCTYb5gRdVWtIsKMFfeLcj07hbp6D/spqcrNJthvf1xbDVQ2yem1QzVGrr7eEXBH8sk3I5+v0erKumFHGC7LS+05Yq4QCQhGZgg+DOMefRTalbD6hjepXk435ILXIZCXvYCJOVSnZb+5EmKzJO/EYX5fv7JbxKsh3LMpyu+DohwWXE5Nw6xFc10wOkhxbBEJZRE1vDHjFz8//o3L61SYSfHULfnZR61ivhIi98jwGAw2huzIFSnQANCKBBu1shf6JDFTuFvuvSQnh6G3c6BOsoVnG+qQxvi49j8SQCUY5JFs79CvYcvYEfS3yHUBYC0dmdWOedgY/yALjGR4aTXePRho3fce/Hh/VcCoCJATSAzPGnJwGPTO1SeaBUs0NWBEIgDiLIACKThofQminFKrHNiXAXezP7ehYR1VAeOTLA35p7adUL52bJDBYURvsgsSqx5Y56NwTIUNyowi58AOpOWUR4U/5KNRcGflAO16rjXPoIewPX69J3UwCBi9+f6t7pcKqygf+/CZEEQsGvWjQhIPN4oKqWdNxAybJO58F4s0/mz2r8CRJx2suZpyfe3Q4+/AVZkD8HPYuL+yFFuNdh0WFDQRv8hmnLc0PSYHyxZRVMwIWAgaFg68Lm
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(36860700004)(82310400014)(376005)(1800799015);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Mar 2024 10:30:07.0894
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 042116e8-6bfb-4d6e-7409-08dc4a5b0b4a
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN1PEPF00004681.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR12MB7159

Hi Luca,

On 12/03/2024 14:03, Luca Fancellu wrote:
> 
> 
> Currently the memory footprint of the static shared memory feature
> is impacting all the struct meminfo instances with memory space
> that is not going to be used.
> 
> To solve this issue, rework the static shared memory extra
> information linked to the memory bank to another structure,
> struct shmem_membank_extra, and exploit the struct membank
> padding to host a pointer to that structure in a union with the
NIT: AFAICT the padding will be reused on Arm64 but on Arm32 there will still be 4B padding.

> enum membank_type, with this trick the 'struct membank' has the
> same size with or without the static shared memory, given that
> the 'type' and 'shmem_extra' are never used at the same time.
> 
> Afterwards, create a new structure 'struct shared_meminfo' which
> has the same interface of 'struct meminfo', but requires less
> banks and hosts the extra information for the static shared memory.
> The fields 'bank' and 'extra' of this structure are meant to be
> linked by the index (e.g. extra[idx] will have the information for
> the bank[idx], for i=0..NR_SHMEM_BANKS), the convinient pointer
> 'shmem_extra' of 'struct membank' is then linked to the related
> 'extra' bank to ease the fruition when a function has access only
> to the 'struct membanks common' of 'struct shared_meminfo'.
> 
> The last part of this work is to move the allocation of the
> static shared memory banks from the 'reserved_mem' to a new
> 'shmem' member of the 'struct bootinfo'.
> Change also the 'shm_mem' member type to be 'struct shared_meminfo'
> in order to match the above changes and allow a memory space
> reduction also in 'struct kernel_info'.
Ok, so from this point onwards, when dealing with "reserved" memory, one needs
to account for shmem as well, as it will no longer be part of bootinfo.reserved_mem
(unlike static-mem or static-heap). This is really the only disadvantage. The changes
LGTM, just a few comments below.

> 
> Signed-off-by: Luca Fancellu 
> ---
>  xen/arch/arm/arm32/mmu/mm.c             | 24 +++++++++
>  xen/arch/arm/arm64/mmu/mm.c             |  2 +
>  xen/arch/arm/bootfdt.c                  |  1 +
>  xen/arch/arm/domain_build.c             |  4 ++
>  xen/arch/arm/include/asm/kernel.h       |  4 +-
>  xen/arch/arm/include/asm/setup.h        | 41 +++++++++++++--
>  xen/arch/arm/include/asm/static-shmem.h |  8 +++
>  xen/arch/arm/setup.c                    | 25 ++++++++-
>  xen/arch/arm/static-shmem.c             | 69 ++++++++++++++++++-------
>  9 files changed, 154 insertions(+), 24 deletions(-)
> 
> diff --git a/xen/arch/arm/arm32/mmu/mm.c b/xen/arch/arm/arm32/mmu/mm.c
> index e6bb5d934c16..45e42b307e20 100644
> --- a/xen/arch/arm/arm32/mmu/mm.c
> +++ b/xen/arch/arm/arm32/mmu/mm.c
> @@ -7,6 +7,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  static unsigned long opt_xenheap_megabytes __initdata;
>  integer_param("xenheap_megabytes", opt_xenheap_megabytes);
> @@ -42,6 +43,9 @@ static paddr_t __init consider_modules(paddr_t s, paddr_t e,
>                                         int first_mod)
>  {
>      const struct membanks *reserved_mem = bootinfo_get_reserved_mem();
> +#ifdef CONFIG_STATIC_SHM
> +    const struct membanks *shmem = bootinfo_get_shmem();
> +#endif
>      const struct bootmodules *mi = &bootinfo.modules;
>      int i;
>      int nr;
> @@ -118,6 +122,25 @@ static paddr_t __init consider_modules(paddr_t s, paddr_t e,
>              return consider_modules(s, r_s, size, align, i + 1);
>          }
>      }
> +
> +#ifdef CONFIG_STATIC_SHM
> +    nr += reserved_mem->nr_banks;
> +    for ( ; i - nr < shmem->nr_banks; i++ )
> +    {
> +        paddr_t r_s = shmem->bank[i - nr].start;
> +        paddr_t r_e = r_s + shmem->bank[i - nr].size;
> +
> +        if ( s < r_e && r_s < e )
> +        {
> +            r_e = consider_modules(r_e, e, size, align, i + 1);
> +            if ( r_e )
> +                return r_e;
> +
> +            return consider_modules(s, r_s, size, align, i + 1);
> +        }
> +    }
> +#endif
> +
>      return e;
>  }
> 
> @@ -294,6 +317,7 @@ void __init setup_mm(void)
>                         mfn_to_maddr(directmap_mfn_end));
> 
>      init_staticmem_pages();
> +    init_sharedmem_pages();
>  }
> 
>  /*
> diff --git a/xen/arch/arm/arm64/mmu/mm.c b/xen/arch/arm/arm64/mmu/mm.c
> index f8aaf4ac18be..293acb67e09c 100644
> --- a/xen/arch/arm/arm64/mmu/mm.c
> +++ b/xen/arch/arm/arm64/mmu/mm.c
> @@ -6,6 +6,7 @@
> 
>  #include 
>  #include 
> +#include 
> 
>  /* Override macros from asm/page.h to make them work with mfn_t */
>  #undef virt_to_mfn
> @@ -236,6 +237,7 @@ void __init setup_mm(void)
>      max_page = PFN_DOWN(ram_end);
> 
>      init_staticmem_pages();
> +    init_sharedmem_pages();
>  }
> 
>  /*
> diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
> index ecbc80d6a112..f2344863062e 100644
> --- a/xen/arch/arm/bootfdt.c
> +++ b/xen/arch/arm/bootfdt.c
> @@ -499,6 +499,7 @@ static void __init early_print_info(void)
>                 mem_resv->bank[j].start,
>                 mem_resv->bank[j].start + mem_resv->bank[j].size - 1);
>      }
> +    early_print_info_shmem();
>      printk("\n");
>      for ( i = 0 ; i < cmds->nr_mods; i++ )
>          printk("CMDLINE[%"PRIpaddr"]:%s %s\n", cmds->cmdline[i].start,
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index d0f2ac6060eb..9fad9e8b2c40 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -864,6 +864,7 @@ static int __init add_ext_regions(unsigned long s_gfn, unsigned long e_gfn,
>   * regions we exclude every region assigned to Dom0 from the Host RAM:
>   * - domain RAM
>   * - reserved-memory
> + * - static shared memory
>   * - grant table space
>   */
>  static int __init find_unallocated_memory(const struct kernel_info *kinfo,
> @@ -873,6 +874,9 @@ static int __init find_unallocated_memory(const struct kernel_info *kinfo,
>          bootinfo_get_mem(),
>          kernel_info_get_mem(kinfo),
>          bootinfo_get_reserved_mem(),
> +#ifdef CONFIG_STATIC_SHM
> +        bootinfo_get_shmem(),
> +#endif
>      };
>      struct rangeset *unalloc_mem;
>      paddr_t start, end;
> diff --git a/xen/arch/arm/include/asm/kernel.h b/xen/arch/arm/include/asm/kernel.h
> index 5785da985ccf..937ffcefc73f 100644
> --- a/xen/arch/arm/include/asm/kernel.h
> +++ b/xen/arch/arm/include/asm/kernel.h
> @@ -40,7 +40,7 @@ struct kernel_info {
>      paddr_t unassigned_mem; /* RAM not (yet) assigned to a bank */
>      struct meminfo mem;
>  #ifdef CONFIG_STATIC_SHM
> -    struct meminfo shm_mem;
> +    struct shared_meminfo shm_mem;
>  #endif
> 
>      /* kernel entry point */
> @@ -84,7 +84,7 @@ struct kernel_info {
>      (&(kinfo)->mem.common)
> 
>  #ifdef CONFIG_STATIC_SHM
> -#define KERNEL_INFO_SHM_MEM_INIT .shm_mem.common.max_banks = NR_MEM_BANKS,
> +#define KERNEL_INFO_SHM_MEM_INIT .shm_mem.common.max_banks = NR_SHMEM_BANKS,
>  #else
>  #define KERNEL_INFO_SHM_MEM_INIT
>  #endif
> diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h
> index a3e1dc8fdb6c..07011bd776da 100644
> --- a/xen/arch/arm/include/asm/setup.h
> +++ b/xen/arch/arm/include/asm/setup.h
> @@ -9,6 +9,7 @@
>  #define MAX_FDT_SIZE SZ_2M
> 
>  #define NR_MEM_BANKS 256
> +#define NR_SHMEM_BANKS 32
> 
>  #define MAX_MODULES 32 /* Current maximum useful modules */
> 
> @@ -46,14 +47,20 @@ enum membank_type {
>  /* Indicates the maximum number of characters(\0 included) for shm_id */
>  #define MAX_SHM_ID_LENGTH 16
> 
> +struct shmem_membank_extra {
> +    char shm_id[MAX_SHM_ID_LENGTH];
> +    unsigned int nr_shm_borrowers;
> +};
> +
>  struct membank {
>      paddr_t start;
>      paddr_t size;
> -    enum membank_type type;
> +    union {
> +        enum membank_type type;
>  #ifdef CONFIG_STATIC_SHM
> -    char shm_id[MAX_SHM_ID_LENGTH];
> -    unsigned int nr_shm_borrowers;
> +        struct shmem_membank_extra *shmem_extra;
>  #endif
> +    };
>  };
> 
>  struct membanks {
> @@ -67,6 +74,12 @@ struct meminfo {
>      struct membank bank[NR_MEM_BANKS];
>  };
> 
> +struct shared_meminfo {
> +    struct membanks common;
> +    struct membank bank[NR_SHMEM_BANKS];
> +    struct shmem_membank_extra extra[NR_SHMEM_BANKS];
> +};
Same as with meminfo, please add a BUILD_BUG_ON for padding between common and bank.

> +
>  /*
>   * The domU flag is set for kernels and ramdisks of "xen,domain" nodes.
>   * The purpose of the domU flag is to avoid getting confused in
> @@ -109,6 +122,9 @@ struct bootinfo {
>      struct bootcmdlines cmdlines;
>  #ifdef CONFIG_ACPI
>      struct meminfo acpi;
> +#endif
> +#ifdef CONFIG_STATIC_SHM
> +    struct shared_meminfo shmem;
>  #endif
>      bool static_heap;
>  };
> @@ -119,11 +135,18 @@ struct bootinfo {
>  #define BOOTINFO_ACPI_INIT
>  #endif
> 
> +#ifdef CONFIG_STATIC_SHM
> +#define BOOTINFO_SHMEM_INIT .shmem.common.max_banks = NR_SHMEM_BANKS,
> +#else
> +#define BOOTINFO_SHMEM_INIT
> +#endif
> +
>  #define BOOTINFO_INIT \
>  { \
>      .mem.common.max_banks = NR_MEM_BANKS, \
>      .reserved_mem.common.max_banks = NR_MEM_BANKS, \
>      BOOTINFO_ACPI_INIT \
> +    BOOTINFO_SHMEM_INIT \
>  }
> 
>  struct map_range_data
> @@ -158,6 +181,18 @@ static inline struct membanks *bootinfo_get_acpi(void)
>  }
>  #endif
> 
> +#ifdef CONFIG_STATIC_SHM
> +static inline struct membanks *bootinfo_get_shmem(void)
> +{
> +    return &bootinfo.shmem.common;
> +}
> +
> +static inline struct shmem_membank_extra *bootinfo_get_shmem_extra(void)
> +{
> +    return bootinfo.shmem.extra;
> +}
> +#endif
> +
>  void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len);
> 
>  size_t estimate_efi_size(unsigned int mem_nr_banks);
> diff --git a/xen/arch/arm/include/asm/static-shmem.h b/xen/arch/arm/include/asm/static-shmem.h
> index 108cedb55a9f..c6fac9906656 100644
> --- a/xen/arch/arm/include/asm/static-shmem.h
> +++ b/xen/arch/arm/include/asm/static-shmem.h
> @@ -25,6 +25,10 @@ static inline int process_shm_chosen(struct domain *d,
>  int process_shm_node(const void *fdt, int node, uint32_t address_cells,
>                       uint32_t size_cells);
> 
> +void early_print_info_shmem(void);
> +
> +void init_sharedmem_pages(void);
> +
>  #else /* !CONFIG_STATIC_SHM */
> 
>  static inline int make_resv_memory_node(const struct domain *d,
> @@ -53,6 +57,10 @@ static inline int process_shm_node(const void *fdt, int node,
>      return -EINVAL;
>  }
> 
> +static inline void early_print_info_shmem(void) {};
> +
> +static inline void init_sharedmem_pages(void) {};
> +
>  #endif /* CONFIG_STATIC_SHM */
> 
>  #endif /* __ASM_STATIC_SHMEM_H_ */
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index cc719d508d63..111172a8c4b1 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -208,6 +208,9 @@ static void __init dt_unreserved_regions(paddr_t s, paddr_t e,
>                                           unsigned int first)
>  {
>      const struct membanks *reserved_mem = bootinfo_get_reserved_mem();
> +#ifdef CONFIG_STATIC_SHM
> +    const struct membanks *shmem = bootinfo_get_shmem();
> +#endif
>      unsigned int i, nr;
>      int rc;
> 
> @@ -258,6 +261,22 @@ static void __init dt_unreserved_regions(paddr_t s, paddr_t e,
>          }
>      }
> 
> +#ifdef CONFIG_STATIC_SHM
> +    nr += reserved_mem->nr_banks;
> +    for ( ; i - nr < shmem->nr_banks; i++ )
> +    {
> +        paddr_t r_s = shmem->bank[i - nr].start;
> +        paddr_t r_e = r_s + shmem->bank[i - nr].size;
> +
> +        if ( s < r_e && r_s < e )
> +        {
> +            dt_unreserved_regions(r_e, e, cb, i + 1);
> +            dt_unreserved_regions(s, r_s, cb, i + 1);
> +            return;
> +        }
> +    }
> +#endif
> +
>      cb(s, e);
>  }
> 
> @@ -344,13 +363,17 @@ bool __init check_reserved_regions_overlap(paddr_t region_start,
>          bootinfo_get_reserved_mem(),
>  #ifdef CONFIG_ACPI
>          bootinfo_get_acpi(),
> +#endif
> +#ifdef CONFIG_STATIC_SHM
> +        bootinfo_get_shmem(),
>  #endif
>      };
>      unsigned int i;
> 
>      /*
>       * Check if input region is overlapping with reserved memory banks or
> -     * ACPI EfiACPIReclaimMemory (when ACPI feature is enabled)
> +     * ACPI EfiACPIReclaimMemory (when ACPI feature is enabled) or static
> +     * shared memory banks (when static shared memory feature is enabled)
>       */
>      for ( i = 0; i < ARRAY_SIZE(mem_banks); i++ )
>          if ( meminfo_overlap_check(mem_banks[i], region_start, region_size) )
> diff --git a/xen/arch/arm/static-shmem.c b/xen/arch/arm/static-shmem.c
> index 8b7da952be6e..6143f52cb991 100644
> --- a/xen/arch/arm/static-shmem.c
> +++ b/xen/arch/arm/static-shmem.c
> @@ -4,29 +4,30 @@
>  #include 
> 
>  #include 
> +#include 
>  #include 
> 
>  static int __init acquire_nr_borrower_domain(struct domain *d,
>                                               paddr_t pbase, paddr_t psize,
>                                               unsigned long *nr_borrowers)
>  {
> -    const struct membanks *reserved_mem = bootinfo_get_reserved_mem();
> +    const struct membanks *shmem = bootinfo_get_shmem();
>      unsigned int bank;
> 
>      /* Iterate reserved memory to find requested shm bank. */
> -    for ( bank = 0 ; bank < reserved_mem->nr_banks; bank++ )
> +    for ( bank = 0 ; bank < shmem->nr_banks; bank++ )
>      {
> -        paddr_t bank_start = reserved_mem->bank[bank].start;
> -        paddr_t bank_size = reserved_mem->bank[bank].size;
> +        paddr_t bank_start = shmem->bank[bank].start;
> +        paddr_t bank_size = shmem->bank[bank].size;
> 
>          if ( (pbase == bank_start) && (psize == bank_size) )
>              break;
>      }
> 
> -    if ( bank == reserved_mem->nr_banks )
> +    if ( bank == shmem->nr_banks )
>          return -ENOENT;
> 
> -    *nr_borrowers = reserved_mem->bank[bank].nr_shm_borrowers;
> +    *nr_borrowers = shmem->bank[bank].shmem_extra->nr_shm_borrowers;
> 
>      return 0;
>  }
> @@ -158,16 +159,22 @@ static int __init assign_shared_memory(struct domain *d,
>      return ret;
>  }
> 
> -static int __init append_shm_bank_to_domain(struct membanks *shm_mem,
> -                                            paddr_t start, paddr_t size,
> -                                            const char *shm_id)
> +static int __init
> +append_shm_bank_to_domain(struct shared_meminfo *kinfo_shm_mem, paddr_t start,
Is there any particular reason to prepend the shm_mem name with kinfo?

~Michal


From xen-devel-bounces@lists.xenproject.org Fri Mar 22 10:32:32 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Mar 2024 10:32:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696758.1087942 (Exim 4.92)
	(envelope-from )
	id 1rncCM-0001iJ-QN; Fri, 22 Mar 2024 10:32:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696758.1087942; Fri, 22 Mar 2024 10:32:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rncCM-0001iC-NG; Fri, 22 Mar 2024 10:32:30 +0000
Received: by outflank-mailman (input) for mailman id 696758;
 Fri, 22 Mar 2024 10:32:30 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rncCM-0001i6-7V
 for xen-devel@lists.xenproject.org; Fri, 22 Mar 2024 10:32:30 +0000
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com
 [2a00:1450:4864:20::12a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7ba99201-e837-11ee-afe0-a90da7624cb6;
 Fri, 22 Mar 2024 11:32:29 +0100 (CET)
Received: by mail-lf1-x12a.google.com with SMTP id
 2adb3069b0e04-513e10a4083so2205721e87.1
 for ; Fri, 22 Mar 2024 03:32:29 -0700 (PDT)
Received: from [192.168.206.239] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 dx6-20020a0565122c0600b005159707b939sm295923lfb.44.2024.03.22.03.32.27
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 22 Mar 2024 03:32:27 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7ba99201-e837-11ee-afe0-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1711103548; x=1711708348; darn=lists.xenproject.org;
        h=mime-version:user-agent:content-transfer-encoding:references
         :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject
         :date:message-id:reply-to;
        bh=a9u7Q9QiS3vgg2KxcO4qw6TQI1IAv/H/ixv3P8r+ISc=;
        b=A/1N7OH3cJzjNrAWLrK2VAUvgsw2F/5u1vNMPhnPS7IKCZKwlPwWKEWHnwJgsmRBpd
         hEEmmsNJzvlTfR2a9UlbAz/40xmCAirD0M3W1WPdwhk26ij1P2pIgXb1/3m82FOW/5mR
         RMtPqIk/fu7J1RdMnK1MwlAlStFEjkUaa8r1UpIvRmtrVJwed2DyTImnplY6suDRRTu/
         Nf37yTb2+c104qp7CyXpM1AjK9sybaGSSZWFH9UQ7CGvb+1kcMpQkgnINjX3nU8a6TEs
         t9A7++2WijHJojjDpF+Y0h9UMLrSvKNUTpMPy9Maql2+ZkbaGANvKS1TDvT+7Kszr0VG
         wGGw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711103548; x=1711708348;
        h=mime-version:user-agent:content-transfer-encoding:references
         :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=a9u7Q9QiS3vgg2KxcO4qw6TQI1IAv/H/ixv3P8r+ISc=;
        b=oqgX1MkrP1KvwCn/qXSVeR7vlxt62HIYPv/ypHSnnCKJzjiQ7iureVoIgwjdg5raEZ
         LEeC7Qy8snOp2JATV1pMELJn+zduAt2qZRIczedAn/8P4uiZ//eGE5X8RC2Ek/NKzEED
         KO4/D8cziRmgJqLs9+J5Ts6JlkVy4EiYG0DbsUE3tC2v9eQuvKVoELbG6zxYLoW6ewKu
         iSUe2X1DxN8WEz5NHWUJxj2MR7t/g49wba7TKJXuiG5J2K08P1pNrYq/m/D/J+I5jeOU
         IdCVBfET47sbJG0jhOpijUephf3Hdst/1FWZ5rBRNDylCN3fO1SdKo7jkbperAqvPgAz
         qymg==
X-Forwarded-Encrypted: i=1; AJvYcCVFuWk958/AGscGzfGF1UQlWg2BjgnkH3A2/E+q4SVFlqDkHLYO/kvA7KBt9ocZGppC7X/8V6O+v7dVGnDde+FdujrhE1P3n6xJi67RrPw=
X-Gm-Message-State: AOJu0YxKyWVTbcgU+przxGLAYqpBVvkby+4WqNeSfm5poZlwj/b860Hb
	Ee8dzICbmrVg7J/ePSkp6am1YopSbdgv0li/5/FP/L3VzZv7K7u/
X-Google-Smtp-Source: AGHT+IFA7cbMuM/T25fkygNUP4s7WTFyMDH46Nedh12v7PYmENn6H2bWV8A+emF5+8P5sNfNE4zMmw==
X-Received: by 2002:a19:5e19:0:b0:513:5e6b:a191 with SMTP id s25-20020a195e19000000b005135e6ba191mr1334564lfb.50.1711103548226;
        Fri, 22 Mar 2024 03:32:28 -0700 (PDT)
Message-ID: 
Subject: Re: [PATCH v6 08/20] xen/riscv: introduce cmpxchg.h
From: Oleksii 
To: Jan Beulich 
Cc: Alistair Francis , Bob Eshleman
 , Connor Davis , Andrew
 Cooper , George Dunlap
 ,  Julien Grall , Stefano
 Stabellini , Wei Liu , 
 xen-devel@lists.xenproject.org
Date: Fri, 22 Mar 2024 11:32:27 +0100
In-Reply-To: <6f73368c-ea73-4d86-a6a1-8f9784c4b01f@suse.com>
References: 
	 
	 <6f73368c-ea73-4d86-a6a1-8f9784c4b01f@suse.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.50.2 (3.50.2-1.fc39) 
MIME-Version: 1.0

On Thu, 2024-03-21 at 13:07 +0100, Jan Beulich wrote:
> On 15.03.2024 19:06, Oleksii Kurochko wrote:
> > The header was taken from Linux kernl 6.4.0-rc1.
> >=20
> > Addionally, were updated:
> > * add emulation of {cmp}xchg for 1/2 byte types using 32-bit atomic
> > =C2=A0 access.
> > * replace tabs with spaces
> > * replace __* variale with *__
> > * introduce generic version of xchg_* and cmpxchg_*.
> > * drop {cmp}xchg{release,relaxed,acquire} as Xen doesn't use them
>=20
> With this, ...
>=20
> > * drop barries and use instruction suffixices instead ( .aq, .rl,
> > .aqrl )
> >=20
> > Implementation of 4- and 8-byte cases were updated according to the
> > spec:
> > ```
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 ....
> > Linux Construct=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RVWMO A=
MO Mapping
> > atomic  relaxed=C2=A0=C2=A0=C2=A0=C2=A0 amo.{w|d}
> > atomic  acquire=C2=A0=C2=A0=C2=A0=C2=A0 amo.{w|d}.aq
> > atomic  release=C2=A0=C2=A0=C2=A0=C2=A0 amo.{w|d}.rl
> > atomic =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 amo.{w|d}.aqrl
> > Linux Construct=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RVWMO L=
R/SC Mapping
> > atomic  relaxed=C2=A0=C2=A0=C2=A0=C2=A0 loop: lr.{w|d}; ; sc.{w=
|d}; bnez loop
> > atomic  acquire=C2=A0=C2=A0=C2=A0=C2=A0 loop: lr.{w|d}.aq; ; sc=
.{w|d}; bnez
> > loop
> > atomic  release=C2=A0=C2=A0=C2=A0=C2=A0 loop: lr.{w|d}; ; sc.{w=
|d}.aqrl=E2=88=97 ; bnez
> > loop OR
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 fence=
.tso; loop: lr.{w|d}; ; sc.{w|d}=E2=88=97
> > ; bnez loop
> > atomic =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 loop: lr.{w|d}.aq; ; sc.{w|d}.aqrl;
> > bnez loop
> >=20
> > Table A.5: Mappings from Linux memory primitives to RISC-V
> > primitives
> >=20
> > ```
>=20
> ... I consider quoting this table in full, without any further
> remarks, as
> confusing: Three of the lines each are inapplicable now, aiui.
I'll shorten the table then.

>=20
> Further what are the two * telling us? Quite likely they aren't there
> just
> accidentally.
>=20
> Finally, why sc.{w|d}.aqrl when in principle one would expect just
> sc.{w|d}.rl?
Because according to the last line of table A.5:
    atomic              loop: lr.{w|d}.aq; ; sc.{w|d}.aqrl;
Here it is used sc.{w|d}.aqrl form, so I decided to stick to the what
is mentioned in the table.

>=20
> > +})
> > +
> > +static always_inline unsigned long __xchg(volatile void *ptr,
> > unsigned long new, int size)
> > +{
> > +=C2=A0=C2=A0=C2=A0 unsigned long ret;
> > +
> > +=C2=A0=C2=A0=C2=A0 switch ( size )
> > +=C2=A0=C2=A0=C2=A0 {
> > +=C2=A0=C2=A0=C2=A0 case 1:
> > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ret =3D emulate_xchg_1_2((v=
olatile uint8_t *)ptr, new,
> > ".aq", ".aqrl");
> > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 break;
> > +=C2=A0=C2=A0=C2=A0 case 2:
> > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ret =3D emulate_xchg_1_2((v=
olatile uint16_t *)ptr, new,
> > ".aq", ".aqrl");
> > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 break;
> > +=C2=A0=C2=A0=C2=A0 case 4:
> > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 __amoswap_generic((volatile=
 uint32_t *)ptr, new, ret,
> > ".w.aqrl");
> > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 break;
> > +#ifndef CONFIG_32BIT
>=20
> There's no 32BIT Kconfig symbol; all we have is a 64BIT one.
I meant here CONFIG_RISCV_32.

>=20
> > +=C2=A0=C2=A0=C2=A0 case 8:
> > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 __amoswap_generic((volatile=
 uint64_t *)ptr, new, ret,
> > ".d.aqrl");
> > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 break;
> > +#endif
> > +=C2=A0=C2=A0=C2=A0 default:
> > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 STATIC_ASSERT_UNREACHABLE()=
;
> > +=C2=A0=C2=A0=C2=A0 }
> > +
> > +=C2=A0=C2=A0=C2=A0 return ret;
> > +}
> > +
> > +#define xchg(ptr, x) \
> > +({ \
> > +=C2=A0=C2=A0=C2=A0 __typeof__(*(ptr)) n_ =3D (x); \
> > +=C2=A0=C2=A0=C2=A0 (__typeof__(*(ptr))) \
> > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 __xchg((ptr), (unsigned lon=
g)(n_), sizeof(*(ptr))); \
>=20
> Nit: While excess parentheses "only" harm readability, they would
> nevertheless better be omitted (here: the first argument passed).
>=20
> > +})
> > +
> > +#define __generic_cmpxchg(ptr, old, new, ret, lr_sfx, sc_sfx)	\
> > + ({ \
> > +=C2=A0=C2=A0=C2=A0 register unsigned int rc; \
>=20
> Nit: We don't normally use "register", unless accompanied by asm()
> tying
> a variable to a specific one.
>=20
> > +=C2=A0=C2=A0=C2=A0 __typeof__(*(ptr)) old__ =3D (__typeof__(*(ptr)))(o=
ld); \
> > +=C2=A0=C2=A0=C2=A0 __typeof__(*(ptr)) new__ =3D (__typeof__(*(ptr)))(n=
ew); \
>=20
> The casts aren't very nice to have here; I take they're needed for
> cmpxchg_ptr() to compile?
Not really, I have not faced an compilation issue.
The reason why it was added is that lr instruction places the sign-
extended value in destination register, but if not to do cast value for
old and new were generated without sign extension, so, for example:
   u32=3D 0xbbbbbbbb;
   cmpxchg(&u32, 0xbbbbbbbb, 0xCCCCCCCC), u32);
Will fail because after:
       "0: lr" lr_sfx " %0, %2\n"=20
in %0 we will have 0xFFFFFFFFBBBBBBBB, but in %3 we will have
0xBBBBBBBB, so
       bne  %0, %z3, 1f\n"
%0 and %3 are always inequal in case when the most significat bit of
value read from %2 has 1.

But now I realized that it would be better just to use a mask and not
be dependent from compiler code generation, so it would be better to in
the following way ( of course, the macros should be updated accordingly
to remarks you give me ):
   #define __generic_cmpxchg(ptr, old, new, ret, lr_sfx, sc_sfx)	\
    ({ \
       register unsigned int rc; \
       unsigned long mask =3D GENMASK(((sizeof(*(ptr))) * BITS_PER_BYTE)
   - 1, 0); \
       asm volatile( \
           "0: lr" lr_sfx " %0, %2\n" \
           "   and  %0, %0, %z[mask]\n" \
           "   bne  %0, %z3, 1f\n" \
           "   sc" sc_sfx " %1, %z4, %2\n" \
           "   bnez %1, 0b\n" \
           "1:\n" \
           : "=3D&r" (ret), "=3D&r" (rc), "+A" (*ptr) \
           : "rJ" (old), "rJ" (new), [mask] "rJ" (mask)  \
           : "memory"); \
    })
  =20
>=20
> > +=C2=A0=C2=A0=C2=A0 asm volatile( \
>=20
> Nit: Missing blank once again. Would be really nice if you could go
> through and sort this uniformly for the series.
>=20
> > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "0: lr" lr_sfx " %0, %2\n" =
\
> > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "=C2=A0=C2=A0 bne=C2=A0 %0,=
 %z3, 1f\n" \
> > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "=C2=A0=C2=A0 sc" sc_sfx " =
%1, %z4, %2\n" \
> > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "=C2=A0=C2=A0 bnez %1, 0b\n=
" \
> > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "1:\n" \
> > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : "=3D&r" (ret), "=3D&r" (r=
c), "+A" (*ptr) \
> > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : "rJ" (old__), "rJ" (new__=
) \
>=20
> Please could I talk you into using named operands here, too?
Sure, I will add them.

~ Oleksii



From xen-devel-bounces@lists.xenproject.org Fri Mar 22 10:42:14 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Mar 2024 10:42:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696764.1087954 (Exim 4.92)
	(envelope-from )
	id 1rncLh-0003lL-Rt; Fri, 22 Mar 2024 10:42:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696764.1087954; Fri, 22 Mar 2024 10:42:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rncLh-0003lE-Na; Fri, 22 Mar 2024 10:42:09 +0000
Received: by outflank-mailman (input) for mailman id 696764;
 Fri, 22 Mar 2024 10:42:09 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rncLh-0003l8-18
 for xen-devel@lists.xenproject.org; Fri, 22 Mar 2024 10:42:09 +0000
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com
 [2a00:1450:4864:20::62e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d38c8c14-e838-11ee-a1ee-f123f15fe8a2;
 Fri, 22 Mar 2024 11:42:06 +0100 (CET)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-a46ba938de0so275418866b.3
 for ; Fri, 22 Mar 2024 03:42:06 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 pk2-20020a170906d7a200b00a471c6b3211sm879119ejb.175.2024.03.22.03.42.04
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 22 Mar 2024 03:42:05 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d38c8c14-e838-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711104125; x=1711708925; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=v1dJ1UrBAIQsxiQ+U2xQ2kU0tpjpVaJNO0/8/hVzi6M=;
        b=bJ0zbaT0TfJUZN2IEsCoMWUBXRsyX+X7CoutTqNFBdQ6qMIA/jl+4ibpMKsSPtvpX6
         xRFEkd218KaTV1HzoNURhyeEiG8H62+37YyTNn0msIGF4QvgPpmjMrwu42P0D6uUVSuq
         NsqQgWEUDupbYBHOBPtB+7EZZPh6jDqsAya5y07FlLXrkSzOWUUBGygn7MRgV1bxKpqC
         SOGe8wu7yrnq0hQlETRVknWJ7Ao0D08lKajafspNvHPOgUfv51chDZMtAQgtbnIE+iBk
         a/Ujr/Q0AFURDEdajSExYZ6Uor71inmXmuLYXRZvqZxlwOms2lIJNA/1CYnzpXUBOkXg
         EPjg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711104125; x=1711708925;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=v1dJ1UrBAIQsxiQ+U2xQ2kU0tpjpVaJNO0/8/hVzi6M=;
        b=JotcHMVpH5A2v5dmsLU4dnqNfd/VkpoB8Fo+sj3TF4OZHcIPtVXIc7f8CvXUqOxk4B
         WLd1Zq4J9/roEc8CMcfKGf6d9z7QhUz0DJVQgY+CuYaJf5ZMISzl1hJJagEoHXjAXzz9
         mNUXxFQ7EBuWwO+ilomZ403StB4kNQ3E8+K15WsE487AmpeCSaLgoYFbVGEuP7f9oo/o
         6oojFEdgXIZ3swJvtEx23/gLH2gJahpRIzVZiBiBtnZPom62TF52FiNM559R9fKxgbx9
         1m3fkxAT8UVZgirMVt5zcxRObd5wEMm5UUmTIIGJtgJEm+sT7jxAWH8cJAeT8B1/mx6Y
         uFqg==
X-Forwarded-Encrypted: i=1; AJvYcCWoPi/f9c7/XP9licXSlTi3tNPBzLBc+XVowJMa4dEwL8LQ0xPAh3ULjtt9+c6hdicVXg0DVUAewE/kUmAIfqxjwGzQ+vgUbpRqUAVCQ4E=
X-Gm-Message-State: AOJu0Yw3E0fZDbim5YyugkWzPq7t1RFAB4A6em8DUW1/yyA8WDK4PEcV
	QYAYV4/x/7zNmlqZAgQ7illWlNf4XqeIATsH+aMXyMENmiHBd79tEX4xLalcWg==
X-Google-Smtp-Source: AGHT+IGfyv7YqHl8PJbfweGRlx5EO50H9RpHsCVAcObUoKVB/sNET82a9ehcYQu6KTsVjHu1pxtENw==
X-Received: by 2002:a17:907:7ea1:b0:a47:2d4f:6fad with SMTP id qb33-20020a1709077ea100b00a472d4f6fadmr1449721ejc.39.1711104125557;
        Fri, 22 Mar 2024 03:42:05 -0700 (PDT)
Message-ID: 
Date: Fri, 22 Mar 2024 11:42:03 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 08/20] xen/riscv: introduce cmpxchg.h
Content-Language: en-US
To: Oleksii 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 xen-devel@lists.xenproject.org
References: 
 
 <6f73368c-ea73-4d86-a6a1-8f9784c4b01f@suse.com>
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 22.03.2024 11:32, Oleksii wrote:
> On Thu, 2024-03-21 at 13:07 +0100, Jan Beulich wrote:
>> On 15.03.2024 19:06, Oleksii Kurochko wrote:
>>> The header was taken from Linux kernl 6.4.0-rc1.
>>>
>>> Addionally, were updated:
>>> * add emulation of {cmp}xchg for 1/2 byte types using 32-bit atomic
>>>   access.
>>> * replace tabs with spaces
>>> * replace __* variale with *__
>>> * introduce generic version of xchg_* and cmpxchg_*.
>>> * drop {cmp}xchg{release,relaxed,acquire} as Xen doesn't use them
>>
>> With this, ...
>>
>>> * drop barries and use instruction suffixices instead ( .aq, .rl,
>>> .aqrl )
>>>
>>> Implementation of 4- and 8-byte cases were updated according to the
>>> spec:
>>> ```
>>>               ....
>>> Linux Construct         RVWMO AMO Mapping
>>> atomic  relaxed     amo.{w|d}
>>> atomic  acquire     amo.{w|d}.aq
>>> atomic  release     amo.{w|d}.rl
>>> atomic              amo.{w|d}.aqrl
>>> Linux Construct         RVWMO LR/SC Mapping
>>> atomic  relaxed     loop: lr.{w|d}; ; sc.{w|d}; bnez loop
>>> atomic  acquire     loop: lr.{w|d}.aq; ; sc.{w|d}; bnez
>>> loop
>>> atomic  release     loop: lr.{w|d}; ; sc.{w|d}.aqrl∗ ; bnez
>>> loop OR
>>>                         fence.tso; loop: lr.{w|d}; ; sc.{w|d}∗
>>> ; bnez loop
>>> atomic              loop: lr.{w|d}.aq; ; sc.{w|d}.aqrl;
>>> bnez loop
>>>
>>> Table A.5: Mappings from Linux memory primitives to RISC-V
>>> primitives
>>>
>>> ```
>>
>> ... I consider quoting this table in full, without any further
>> remarks, as
>> confusing: Three of the lines each are inapplicable now, aiui.
> I'll shorten the table then.
> 
>>
>> Further what are the two * telling us? Quite likely they aren't there
>> just
>> accidentally.
>>
>> Finally, why sc.{w|d}.aqrl when in principle one would expect just
>> sc.{w|d}.rl?
> Because according to the last line of table A.5:
>     atomic              loop: lr.{w|d}.aq; ; sc.{w|d}.aqrl;
> Here it is used sc.{w|d}.aqrl form, so I decided to stick to the what
> is mentioned in the table.

I understand it's mentioned that way in the table. But it being that way
is not explained anywhere. Hence my "Why?"

>>> +    __typeof__(*(ptr)) old__ = (__typeof__(*(ptr)))(old); \
>>> +    __typeof__(*(ptr)) new__ = (__typeof__(*(ptr)))(new); \
>>
>> The casts aren't very nice to have here; I take they're needed for
>> cmpxchg_ptr() to compile?
> Not really, I have not faced an compilation issue.
> The reason why it was added is that lr instruction places the sign-
> extended value in destination register, but if not to do cast value for
> old and new were generated without sign extension, so, for example:
>    u32= 0xbbbbbbbb;
>    cmpxchg(&u32, 0xbbbbbbbb, 0xCCCCCCCC), u32);
> Will fail because after:
>        "0: lr" lr_sfx " %0, %2\n" 
> in %0 we will have 0xFFFFFFFFBBBBBBBB, but in %3 we will have
> 0xBBBBBBBB, so
>        bne  %0, %z3, 1f\n"
> %0 and %3 are always inequal in case when the most significat bit of
> value read from %2 has 1.

I'm afraid I don't follow: It's the type conversion you're after, but
that would happen also with the casts omitted.

> But now I realized that it would be better just to use a mask and not
> be dependent from compiler code generation, so it would be better to in
> the following way ( of course, the macros should be updated accordingly
> to remarks you give me ):
>    #define __generic_cmpxchg(ptr, old, new, ret, lr_sfx, sc_sfx)	\
>     ({ \
>        register unsigned int rc; \
>        unsigned long mask = GENMASK(((sizeof(*(ptr))) * BITS_PER_BYTE)
>    - 1, 0); \
>        asm volatile( \
>            "0: lr" lr_sfx " %0, %2\n" \
>            "   and  %0, %0, %z[mask]\n" \
>            "   bne  %0, %z3, 1f\n" \
>            "   sc" sc_sfx " %1, %z4, %2\n" \
>            "   bnez %1, 0b\n" \
>            "1:\n" \
>            : "=&r" (ret), "=&r" (rc), "+A" (*ptr) \
>            : "rJ" (old), "rJ" (new), [mask] "rJ" (mask)  \
>            : "memory"); \
>     })

It'll be up to you whether to switch to such an alternative.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Mar 22 11:03:17 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Mar 2024 11:03:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696772.1087962 (Exim 4.92)
	(envelope-from )
	id 1rncfv-0007DW-Dx; Fri, 22 Mar 2024 11:03:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696772.1087962; Fri, 22 Mar 2024 11:03:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rncfv-0007DP-B9; Fri, 22 Mar 2024 11:03:03 +0000
Received: by outflank-mailman (input) for mailman id 696772;
 Fri, 22 Mar 2024 11:03:02 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rncfu-0007DJ-Fg
 for xen-devel@lists.xenproject.org; Fri, 22 Mar 2024 11:03:02 +0000
Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com
 [2a00:1450:4864:20::134])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id bfa9386e-e83b-11ee-afe0-a90da7624cb6;
 Fri, 22 Mar 2024 12:03:01 +0100 (CET)
Received: by mail-lf1-x134.google.com with SMTP id
 2adb3069b0e04-512b3b04995so1299319e87.3
 for ; Fri, 22 Mar 2024 04:03:01 -0700 (PDT)
Received: from [192.168.206.239] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 o5-20020a05651238a500b00513ba3e4d3fsm304268lft.151.2024.03.22.04.02.59
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 22 Mar 2024 04:03:00 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: bfa9386e-e83b-11ee-afe0-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1711105381; x=1711710181; darn=lists.xenproject.org;
        h=mime-version:user-agent:content-transfer-encoding:references
         :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject
         :date:message-id:reply-to;
        bh=ZBGzzfKAti0m9iCTRvKg4pTGzOqkEmldkPpLOpcV+9s=;
        b=jRkOx1h5oh0/HuBIesDmFX3MoTY9y2rI7nOTPhCGpTDgUuqiurBsP/gm4hDIzcnbPa
         AZgVK0M6ciOdu9M4RMgnB7QL93NKaKQz4EUNuPxl3XBGYRGNajccDsw8U0E0y3NC7yRv
         wh/SHB3ZzG4MF/pky5/e2kNqSDh6CqX4uU2oX+2ZrfIpHi4JpdlIcqUCbKYUYMN2S7iU
         HfoxGHyK4BpkdR6dOPKKfE6sFK/i/13gVlwFIndnB2AFBNq/TJofr8LN1jYD4heRTPYL
         x2fNIVjOw72vNGNwF+3zDbU1aNVnblY6e3202NW4p8ZBnweCa+A6GGUPHQja3SJibiT8
         c8Yw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711105381; x=1711710181;
        h=mime-version:user-agent:content-transfer-encoding:references
         :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=ZBGzzfKAti0m9iCTRvKg4pTGzOqkEmldkPpLOpcV+9s=;
        b=nFDp2asR2Z0xQ72RmnbziwLjYv04IB1rrGRTL7vAzm6vsCjo27ts++seYR6xWAHvO6
         lUt6huae6PSNkWvqG06Yi4OmJ2zuz94ma2nS0eHyERJHBTu/NcY0ViIDsZwO1KDWdB0p
         CBVTzdLSvayyRlagYIYuGnPOcyAJ65DmGpWnD60ie1x12tuRQNqErsnROr/gBMAzYVxl
         954tYqcUN8eJIOCatQhCycXV+YpxX22O+ImxKcb+2F66RDMH8JT5XnRaZxyqe6PN3/UO
         +AdoTDuaoMxrtMoGtVD2AIzM9lwJUDpzutqOuEnCJYkmCHwTskOP4zV0NF4GEvdKvlLF
         Ct9Q==
X-Forwarded-Encrypted: i=1; AJvYcCV7cjwQIoCoFPXtcfaXf/4vvPKkCTKt3r2yWnXlpLvSk0g1dta6yuorzanyGJV89OY8sN+mddBnwGJVkiwn3FWRsTkbboAOTx4rnVzoNFI=
X-Gm-Message-State: AOJu0YzjT7a4xX0vIewpUNRiuZL6GdfD9Gu93Ng4lNzKXCvYUCdojURK
	iXNY1xHJJiA2gbnp7HrlKpPd+MrUPYVZkNbR4B9X2/4g93ZMsrt6
X-Google-Smtp-Source: AGHT+IG85JTogqniqYXFM7ByxNPA1nK6Hw+arOzGvpBJ8zTeII4qQbatCAU70vC0/OypJJp5PpNDqg==
X-Received: by 2002:a05:6512:32a1:b0:513:af27:df1c with SMTP id q1-20020a05651232a100b00513af27df1cmr1388849lfe.11.1711105380437;
        Fri, 22 Mar 2024 04:03:00 -0700 (PDT)
Message-ID: <2a2779011db8ba6db04e8d2e4355479b50e48e01.camel@gmail.com>
Subject: Re: [PATCH v6 09/20] xen/riscv: introduce io.h
From: Oleksii 
To: Jan Beulich 
Cc: Alistair Francis , Bob Eshleman
 , Connor Davis , Andrew
 Cooper , George Dunlap
 ,  Julien Grall , Stefano
 Stabellini , Wei Liu , 
 xen-devel@lists.xenproject.org
Date: Fri, 22 Mar 2024 12:02:59 +0100
In-Reply-To: <49dd40b6-4558-4e0c-b6ab-eee5b814dd8d@suse.com>
References: 
	 
	 <49dd40b6-4558-4e0c-b6ab-eee5b814dd8d@suse.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.50.2 (3.50.2-1.fc39) 
MIME-Version: 1.0

On Thu, 2024-03-21 at 13:27 +0100, Jan Beulich wrote:
> On 15.03.2024 19:06, Oleksii Kurochko wrote:
> > --- /dev/null
> > +++ b/xen/arch/riscv/include/asm/io.h
> > @@ -0,0 +1,167 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only */
> > +/*
> > + *=C2=A0 The header taken form Linux 6.4.0-rc1 and is based on
> > + *=C2=A0 arch/riscv/include/asm/mmio.h with the following changes:
> > + *=C2=A0=C2=A0 - drop forcing of endianess for read*(), write*() funct=
ions
> > as
> > + *=C2=A0=C2=A0=C2=A0=C2=A0 no matter what CPU endianness, what endiann=
ess a particular
> > device
> > + *=C2=A0=C2=A0=C2=A0=C2=A0 (and hence its MMIO region(s)) is using is =
entirely
> > independent.
> > + *=C2=A0=C2=A0=C2=A0=C2=A0 Hence conversion, where necessary, needs to=
 occur at a
> > layer up.
> > + *=C2=A0=C2=A0=C2=A0=C2=A0 Another one reason to drop endianess conver=
sion is:
> > + *=C2=A0=C2=A0=C2=A0=C2=A0
> > https://patchwork.kernel.org/project/linux-riscv/patch/20190411115623.5=
749-3-hch@lst.de/
> > + *=C2=A0=C2=A0=C2=A0=C2=A0 One of the answers of the author of the com=
mit:
> > + *=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 And we don't know if Linux will=
 be around if that ever
> > changes.
> > + *=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The point is:
> > + *=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 a) the current RISC-V spe=
c is LE only
> > + *=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 b) the current linux port=
 is LE only except for this
> > little bit
> > + *=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 There is no point in leaving ju=
st this bitrotting code
> > around.=C2=A0 It
> > + *=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 just confuses developers, (very=
 very slightly) slows down
> > compiles
> > + *=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and will bitrot.=C2=A0 It also won't =
be any significant help to
> > a future
> > + *=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 developer down the road doing a=
 hypothetical BE RISC-V
> > Linux port.
> > + *=C2=A0=C2=A0 - drop unused argument of __io_ar() macros.
> > + *=C2=A0=C2=A0 - drop "#define _raw_{read,write}{b,w,l,d,q}
> > _raw_{read,write}{b,w,l,d,q}"
>=20
> In the commit message I'm not worried as much, but at least here the
> odd mention
> of d as suffixes would better be purged.
Probably, I use incorrect words, but what I meant that it was dropped:
   #define _raw_{read,write}{b,w,l,d,q} _raw_{read,write}{b,w,l,d,q}
before declaration/definition of inline functions (
__raw_{read,write}{b,w,l,d,q} ).

~ Oleksii




From xen-devel-bounces@lists.xenproject.org Fri Mar 22 11:36:50 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Mar 2024 11:36:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696782.1087972 (Exim 4.92)
	(envelope-from )
	id 1rndCV-0003iX-SE; Fri, 22 Mar 2024 11:36:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696782.1087972; Fri, 22 Mar 2024 11:36:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rndCV-0003iQ-PN; Fri, 22 Mar 2024 11:36:43 +0000
Received: by outflank-mailman (input) for mailman id 696782;
 Fri, 22 Mar 2024 11:36:42 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rndCU-0003iK-N2
 for xen-devel@lists.xenproject.org; Fri, 22 Mar 2024 11:36:42 +0000
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com
 [2a00:1450:4864:20::534])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 730f9125-e840-11ee-afe0-a90da7624cb6;
 Fri, 22 Mar 2024 12:36:40 +0100 (CET)
Received: by mail-ed1-x534.google.com with SMTP id
 4fb4d7f45d1cf-56bc8cfc19fso2101883a12.1
 for ; Fri, 22 Mar 2024 04:36:40 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d23-20020aa7c1d7000000b0056b8dcdaca5sm927938edp.73.2024.03.22.04.36.39
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 22 Mar 2024 04:36:39 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 730f9125-e840-11ee-afe0-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711107400; x=1711712200; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=Y/ddeNj19CFFs05J34nOmcAfdUFRG5CkBb26jcctDpU=;
        b=RbBXXd2CFPIzBr80WGncyM3eCGnU/I/qXW2MHPnfGf1lbB4M33Z5q/RDMW0ZMxmwTB
         V1srkuHNytv5nqUZV8nrUNh1rvbFIPKpAiwx4SZ8uyf5Yc5nR6YeUstRTcf4TrO+mtmJ
         z+7+siTd/UJo8LBv3l8kLFbRb6Ym08fGpN1QXr9LWUMeXZda0je6ar1heRk/TyevbqVS
         YrFlyNAvvLbqtCUK3TSVvzWezUx5t+DvsTJHX5i5rdq8Wd0twept9unR0q5GPkZqhrce
         Ckejo5oeHM+1TKk4H81kQih2jYD08v8Dv3efCJegphoOhHgX5Zmp2+4wEqoJ8gop3ih8
         eX2Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711107400; x=1711712200;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=Y/ddeNj19CFFs05J34nOmcAfdUFRG5CkBb26jcctDpU=;
        b=ectX3mwgoAj9jpLVET70Wk0iaMXBRtl9l1voT/gV8DCkQKurarkWZjucFSURxU6Evh
         jWvvUL55Mx4wihwSTtSgSPsahCRHean/baoNPGeqN9fBrcezt9Txr7tbccwSFr2OPVWm
         rzw5UGGfAJNmy29NtFrEJmrd2DCU84QWh6tOB4bdfyiMGfUzJ67/JioxAuchd4BiuXef
         FvXaO9Ly1yvrSmRTsAUwyUnA0NKUfsaQlGE5QWDy0H+3sEcW/3x/MKMeGUTXmIYKPFqB
         ZUUgqrVhtd762ZJlw2A4uU9XhNdWIDNiMRM1WyTlXEzjQoHG26Ptw98Gtqi01HeZTcjh
         DjsQ==
X-Forwarded-Encrypted: i=1; AJvYcCV+IkQmkXWVD3rMuZ+CgeHam2fT6o+Esa4letMIKLgMxK+BTz00weP3eGMZ2PajJ94wyzcNWtpXecyOlRn4wFhALanUrztlyxVtZcoZlqE=
X-Gm-Message-State: AOJu0Ywmp7aBfjrThH3IpMTHpMzVaj+oQrc7qabH69JbyD5Nm07gktQJ
	BrFlA8bgZuvmaPBPq7ZpKoIwKSTWJaibGaLmHdn1LMRc8DXwqPFKqNv6U7gSsA==
X-Google-Smtp-Source: AGHT+IGIqAn2hvS5D7oMpPvFqea4F7YDnzQBXuHmP+h6KKdQ/CnipSVvqewfvKg+BHSLJdS7TmQP2w==
X-Received: by 2002:a50:9998:0:b0:567:429f:7164 with SMTP id m24-20020a509998000000b00567429f7164mr1180181edb.32.1711107399721;
        Fri, 22 Mar 2024 04:36:39 -0700 (PDT)
Message-ID: <9b40aeeb-ca7a-47c0-acde-407631ae9db7@suse.com>
Date: Fri, 22 Mar 2024 12:36:38 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 09/20] xen/riscv: introduce io.h
Content-Language: en-US
To: Oleksii 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 xen-devel@lists.xenproject.org
References: 
 
 <49dd40b6-4558-4e0c-b6ab-eee5b814dd8d@suse.com>
 <2a2779011db8ba6db04e8d2e4355479b50e48e01.camel@gmail.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <2a2779011db8ba6db04e8d2e4355479b50e48e01.camel@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 22.03.2024 12:02, Oleksii wrote:
> On Thu, 2024-03-21 at 13:27 +0100, Jan Beulich wrote:
>> On 15.03.2024 19:06, Oleksii Kurochko wrote:
>>> --- /dev/null
>>> +++ b/xen/arch/riscv/include/asm/io.h
>>> @@ -0,0 +1,167 @@
>>> +/* SPDX-License-Identifier: GPL-2.0-only */
>>> +/*
>>> + *  The header taken form Linux 6.4.0-rc1 and is based on
>>> + *  arch/riscv/include/asm/mmio.h with the following changes:
>>> + *   - drop forcing of endianess for read*(), write*() functions
>>> as
>>> + *     no matter what CPU endianness, what endianness a particular
>>> device
>>> + *     (and hence its MMIO region(s)) is using is entirely
>>> independent.
>>> + *     Hence conversion, where necessary, needs to occur at a
>>> layer up.
>>> + *     Another one reason to drop endianess conversion is:
>>> + *    
>>> https://patchwork.kernel.org/project/linux-riscv/patch/20190411115623.5749-3-hch@lst.de/
>>> + *     One of the answers of the author of the commit:
>>> + *       And we don't know if Linux will be around if that ever
>>> changes.
>>> + *       The point is:
>>> + *        a) the current RISC-V spec is LE only
>>> + *        b) the current linux port is LE only except for this
>>> little bit
>>> + *       There is no point in leaving just this bitrotting code
>>> around.  It
>>> + *       just confuses developers, (very very slightly) slows down
>>> compiles
>>> + *      and will bitrot.  It also won't be any significant help to
>>> a future
>>> + *       developer down the road doing a hypothetical BE RISC-V
>>> Linux port.
>>> + *   - drop unused argument of __io_ar() macros.
>>> + *   - drop "#define _raw_{read,write}{b,w,l,d,q}
>>> _raw_{read,write}{b,w,l,d,q}"
>>
>> In the commit message I'm not worried as much, but at least here the
>> odd mention
>> of d as suffixes would better be purged.
> Probably, I use incorrect words, but what I meant that it was dropped:
>    #define _raw_{read,write}{b,w,l,d,q} _raw_{read,write}{b,w,l,d,q}
> before declaration/definition of inline functions (
> __raw_{read,write}{b,w,l,d,q} ).

But where did you find a raw_readd() or raw_writed() (with no matter how
many leading underscores)?

Jan


From xen-devel-bounces@lists.xenproject.org Fri Mar 22 12:06:08 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Mar 2024 12:06:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696798.1087983 (Exim 4.92)
	(envelope-from )
	id 1rndej-0000Di-2M; Fri, 22 Mar 2024 12:05:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696798.1087983; Fri, 22 Mar 2024 12:05:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rndei-0000Db-Vy; Fri, 22 Mar 2024 12:05:52 +0000
Received: by outflank-mailman (input) for mailman id 696798;
 Fri, 22 Mar 2024 12:05:51 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rndeh-0000DF-83
 for xen-devel@lists.xenproject.org; Fri, 22 Mar 2024 12:05:51 +0000
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com
 [2a00:1450:4864:20::52b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 85a66e1b-e844-11ee-a1ee-f123f15fe8a2;
 Fri, 22 Mar 2024 13:05:49 +0100 (CET)
Received: by mail-ed1-x52b.google.com with SMTP id
 4fb4d7f45d1cf-56bcb9640bbso2195567a12.0
 for ; Fri, 22 Mar 2024 05:05:49 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 85a66e1b-e844-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1711109148; x=1711713948; darn=lists.xenproject.org;
        h=to:subject:message-id:date:from:mime-version:from:to:cc:subject
         :date:message-id:reply-to;
        bh=VgOOwUO0PR7cdXwqLatf39deNDlV09pk6dcsKAWXI9E=;
        b=j8726WT3eYSNYRd66dCVoImDyLLcg9bTVFa+madBj5j3WRzgBo+UjRCP6Mqud1ivCh
         BqSbKV26ZOyhxhjhQXNj5DXAaDhcpoda/aTyV6YQw1DjSL8c6hwoAzvJYgCn57zbIYCy
         s5LBhUr7tMefwx1vt3CrXBXGNDUqTQyXFF+do=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711109148; x=1711713948;
        h=to:subject:message-id:date:from:mime-version:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=VgOOwUO0PR7cdXwqLatf39deNDlV09pk6dcsKAWXI9E=;
        b=Z7W73Rmh44wcSb3RdPGtiGjHiny/0Bl0LC46x6xMGKK2yH8bZ5An8rtH6uShmPoN9q
         06n4yRGxPXlQ6mULbZRmLtY7z12o1dSXoJ22CbqsG4VkZ48NfaEBdrsCjvY7t/QzVn9+
         qqbYMj13xMUA1O2fFoiSF2osiPqudDH0TmyIqC8Rlt+mw45tnx+V0VUDwo7IRJh2dsLa
         Q54/VsgPzj99gisOeNrjp1KQQAgHhe7YMPle+NT8mNBjMyWJ7KUvNq3HNkIQEMQg8mAP
         jx+qUxpyfQ3mgX5HzRGQlVPrKKkGRjW+MuA9qr3MqEVkoeGyPPnLGi98C/vsrAMU0co0
         SneQ==
X-Gm-Message-State: AOJu0YymEejwMX2S/IKz6MoQuC+wdgWEL34JSMGVADe/LlAVAEdnb2+7
	i5Kzr/uW+/LXXgUItWbE7Egd8Ff+fbbkAlMQitnqcjW8M9ilE7W1vSiYIA9V9HVtjHBqYmJY8dH
	YVTFdmYu4zckd5mBwLbA2ncmLxFSkL3po+IY5M3pL/FUVXwWHCDc=
X-Google-Smtp-Source: AGHT+IGo+tbU5QUEbxTmKo0YWOeBxxO8mYaq6iO0GcgHdok6BQU8glPJOi7bTqRu86k++KdOIrsWywWLtPfsvwNFyyI=
X-Received: by 2002:a50:8a84:0:b0:568:949b:e91f with SMTP id
 j4-20020a508a84000000b00568949be91fmr1439045edj.36.1711109148287; Fri, 22 Mar
 2024 05:05:48 -0700 (PDT)
MIME-Version: 1.0
From: Kelly Choi 
Date: Fri, 22 Mar 2024 12:05:12 +0000
Message-ID: 
Subject: Xen Summit Schedule announced!
To: xen-devel , xen-users@lists.xenproject.org, 
	xen-announce@lists.xenproject.org
Content-Type: multipart/alternative; boundary="000000000000f4c65b06143ea447"

--000000000000f4c65b06143ea447
Content-Type: text/plain; charset="UTF-8"

Hi all,

The much anticipated Xen Summit schedule

is live!
Check out what talks will be available. We also have plenty of slots for
design sessions at the event for you to get involved in.

*Don't forget to secure your early bird rates today! These rates will end
on 31st March 2024.*
https://events.linuxfoundation.org/xen-project-summit/register/#register-now

See you all there.

Many thanks,
Kelly Choi

Community Manager
Xen Project

--000000000000f4c65b06143ea447
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi all,

The much anticipated X=
en Summit schedule is live!=C2=A0
Check out what talks will b=
e available. We also have plenty of slots for design sessions at the event =
for you to get involved in.=C2=A0=C2=A0

Don'=
;t forget to secure your early bird rates today! These rates will end on 31=
st March 2024.

See you all there.=C2=A0

Many thanks,
Kelly Choi

Community Manager
Xen Project=C2=A0


--000000000000f4c65b06143ea447--


From xen-devel-bounces@lists.xenproject.org Fri Mar 22 12:25:53 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Mar 2024 12:25:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696849.1088025 (Exim 4.92)
	(envelope-from )
	id 1rndxu-0005ht-D8; Fri, 22 Mar 2024 12:25:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696849.1088025; Fri, 22 Mar 2024 12:25:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rndxu-0005hm-AU; Fri, 22 Mar 2024 12:25:42 +0000
Received: by outflank-mailman (input) for mailman id 696849;
 Fri, 22 Mar 2024 12:25:40 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rndxs-0005hg-N4
 for xen-devel@lists.xenproject.org; Fri, 22 Mar 2024 12:25:40 +0000
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com
 [2a00:1450:4864:20::62c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4ade683c-e847-11ee-afe0-a90da7624cb6;
 Fri, 22 Mar 2024 13:25:39 +0100 (CET)
Received: by mail-ej1-x62c.google.com with SMTP id
 a640c23a62f3a-a46f97b8a1bso274992766b.0
 for ; Fri, 22 Mar 2024 05:25:39 -0700 (PDT)
Received: from [192.168.206.239] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 p9-20020a17090653c900b00a473a0f3384sm55854ejo.16.2024.03.22.05.25.37
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 22 Mar 2024 05:25:38 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4ade683c-e847-11ee-afe0-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1711110339; x=1711715139; darn=lists.xenproject.org;
        h=mime-version:user-agent:content-transfer-encoding:references
         :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject
         :date:message-id:reply-to;
        bh=PlgFaWJucH3cShAvEpomCwS9We6t+uPVWKAy8DU2Fx8=;
        b=h+z2o/KwcZozX3Hj/K3bB0sMtWBZCWiCSy8cDoCwZnxsINJhEKwBWu5O1Tg1REcPby
         a59xuJrm/NP7z528t+KmB8koI8MRx/bTJHRZyrIpInmM/g8DMuGkeyQR4meShF+RNauQ
         XmJ+1sUf/MQI0w4xaKIDLYlHA+qSq1JETwtPePwxn2d35uT919cBVcWYKRGrUz2PfAjX
         0froEE3GFZCfpd2SJjBOX9JDtQ5h7iEOB8QMbtjB7GPqO/aOwRVJ6g2dzWBacTicV9KA
         xnoPrN5P2OkLmf59gFV/5cNi7zWX0wP4yWEHSJSiq2xAYUmETVJ1KW68SGieGpfjc3tJ
         jBnw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711110339; x=1711715139;
        h=mime-version:user-agent:content-transfer-encoding:references
         :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=PlgFaWJucH3cShAvEpomCwS9We6t+uPVWKAy8DU2Fx8=;
        b=QFUR+vXXVOCtfCaeqDGmve/sptcuykDyinhXOkcxru43cFCY+i9NwzJdgJvQHEQxYx
         OAUjmjd3+rrR69mrpGquuFBCl3OD6tmZGe7oXhixo9SsGxLPjXmtkLnXvDaBTvAs+H7L
         mVM1hMsP/0e+W72n+Bt1Ag19CkM0xTsUr+hQf9gR9xCL/x7KctHzlZkYLDHlFRRSdhDu
         zJhlBexnPGzdH9LdP9H1FOELPq2jrnUnhyZmxsZ89YK7rJ3ubGkbRYQDoi4DX8NerFn+
         Mt5jxMhrlerI9fGGX4BYoluxY/LeYZ37ZxQusGH/YEQbS3vPDL/s7EqqgN3wvgLDNb0I
         Qcgg==
X-Forwarded-Encrypted: i=1; AJvYcCUjsdglU629w4riMi0z+g8bihnKJtm1IB67dBX1OMzt/9dY9D3gnYxN5rLVuDcSMx4EulMxf9Zxk0/p8YKkPOn7HRguj6OeijwEEUBgDPA=
X-Gm-Message-State: AOJu0YzlDzrJFMlRzn38XJaBkKdeYi+mLxt4GO78YnMwT9b3/sRqJGQu
	IYzlcF7Ghf5jyokVjQkf6OH8ufeI0FxhYA34cMf0X9imz6na5Xik
X-Google-Smtp-Source: AGHT+IF7qXShIF4vWenAaeT8CM2frCTMQJ4zwxTRuVCGFsupo1YmRCIvEfR/Zd8MGov56pnfOZgCcw==
X-Received: by 2002:a17:907:86ab:b0:a47:36a7:d634 with SMTP id qa43-20020a17090786ab00b00a4736a7d634mr768840ejc.52.1711110338366;
        Fri, 22 Mar 2024 05:25:38 -0700 (PDT)
Message-ID: 
Subject: Re: [PATCH v6 10/20] xen/riscv: introduce atomic.h
From: Oleksii 
To: Jan Beulich 
Cc: Alistair Francis , Bob Eshleman
 , Connor Davis , Andrew
 Cooper , George Dunlap
 ,  Julien Grall , Stefano
 Stabellini , Wei Liu , 
 xen-devel@lists.xenproject.org
Date: Fri, 22 Mar 2024 13:25:37 +0100
In-Reply-To: <78a86041-72e2-410f-b6a7-212656b0dba3@suse.com>
References: 
	 <22ee9c8cc62c76cfb799fed800636e7c8bf25a17.1710517542.git.oleksii.kurochko@gmail.com>
	 <78a86041-72e2-410f-b6a7-212656b0dba3@suse.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
User-Agent: Evolution 3.50.2 (3.50.2-1.fc39) 
MIME-Version: 1.0

T24gVGh1LCAyMDI0LTAzLTIxIGF0IDE0OjAzICswMTAwLCBKYW4gQmV1bGljaCB3cm90ZToKPiBP
biAxNS4wMy4yMDI0IDE5OjA2LCBPbGVrc2lpIEt1cm9jaGtvIHdyb3RlOgo+ID4gSW5pdGlhbGx5
IHRoZSBwYXRjaCB3YXMgaW50cm9kdWNlZCBieSBCb2JieSwgd2hvIHRha2VzIHRoZSBoZWFkZXIK
PiA+IGZyb20KPiA+IExpbnV4IGtlcm5lbC4KPiA+IAo+ID4gVGhlIGZvbGxvd2luZyBjaGFuZ2Vz
IHdlcmUgZG9uZSBvbiB0b3Agb2YgTGludXgga2VybmVsIGhlYWRlcjoKPiA+IMKgLSBhdG9taWMj
I3ByZWZpeCMjXyp4Y2hnXyooYXRvbWljIyNwcmVmaXgjI190ICp2LCBjX3Qgbikgd2VyZQo+ID4g
dXBkYXRlZAo+ID4gwqDCoMKgwqAgdG8gdXNlX18qeGNoZ19nZW5lcmljKCkKPiA+IMKgLSBkcm9w
IGNhc3RzIGluIHdyaXRlX2F0b21pYygpIGFzIHRoZXkgYXJlIHVubmVjZXNzYXJ5Cj4gPiDCoC0g
ZHJvcCBpbnRyb2R1Y3Rpb24gb2YgV1JJVEVfT05DRSgpIGFuZCBSRUFEX09OQ0UoKS4KPiA+IMKg
wqAgWGVuIHByb3ZpZGVzIEFDQ0VTU19PTkNFKCkKPiAKPiBIZXJlIGFuZCBpbiB0aGUgY29kZSBj
b21tZW50OiBXaGlsZSB0aGlzIG1heSBiZSBkZXNjcmliaW5nIHdoYXQgeW91Cj4gZGlkCj4gb24g
dG9wIG9mIHdoYXQgQm9iYnkgaGFkLCBoZXJlIHlvdSdyZSBkZXNjcmliaW5nIGRpZmZlcmVuY2Vz
IHRvIHRoZQo+IExpbnV4Cj4gaGVhZGVyLgo+IAo+ID4gwqAtIHJlbW92ZSB6ZXJvLWxlbmd0aCBh
cnJheSBhY2Nlc3MgaW4gcmVhZF9hdG9taWMoKQo+ID4gwqAtIGRyb3AgZGVmaW5lcyBzaW1pbGFy
IHRvIHBhdHRlcm4KPiAKPiBwYXR0ZXJuPyBXaGljaCBvbmU/IE9oLCB3YWl0LCAuLi4KPiAKPiA+
IMKgLSAjZGVmaW5lIGF0b21pY19hZGRfcmV0dXJuX3JlbGF4ZWTCoMKgIGF0b21pY19hZGRfcmV0
dXJuX3JlbGF4ZWQKPiAKPiAuLi4gdGhpcyBsaW5lIHJlYWxseSBpc24ndCBhIHNlcGFyYXRlIGJ1
bGxldCBwb2ludC4KWWVzLCAnLScgaXMgbm90IG5lZWRlZCBpbiB0aGlzIHRleHQuCgo+IAo+ID4g
KyAqLwo+ID4gK3N0YXRpYyBhbHdheXNfaW5saW5lIHZvaWQgcmVhZF9hdG9taWNfc2l6ZShjb25z
dCB2b2xhdGlsZSB2b2lkICpwLAo+ID4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB2b2lk
ICpyZXMsCj4gPiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHVuc2lnbmVkIGludCBzaXpl
KQo+ID4gK3sKPiA+ICvCoMKgwqAgc3dpdGNoICggc2l6ZSApCj4gPiArwqDCoMKgIHsKPiA+ICvC
oMKgwqAgY2FzZSAxOiAqKHVpbnQ4X3QgKilyZXMgPSByZWFkYihwKTsgYnJlYWs7Cj4gPiArwqDC
oMKgIGNhc2UgMjogKih1aW50MTZfdCAqKXJlcyA9IHJlYWR3KHApOyBicmVhazsKPiA+ICvCoMKg
wqAgY2FzZSA0OiAqKHVpbnQzMl90ICopcmVzID0gcmVhZGwocCk7IGJyZWFrOwo+ID4gK8KgwqDC
oCBjYXNlIDg6ICoodWludDMyX3QgKilyZXPCoCA9IHJlYWRxKHApOyBicmVhazsKPiAKPiBOaXQ6
IEV4Y2VzcyBibGFuayBiZWZvcmUgPS4KPiAKPiBBbHNvIC0gbm8gI2lmZGVmIGhlcmUgdG8gYmUg
UlYzMi1yZWFkeT8KQmVjYXVzZSB0aGVyZSBpcyAjaWZkZWYgUlYzMiBpbiBpby5oIGZvciByZWFk
cSgpLgoKPiAKPiA+ICvCoMKgwqAgZGVmYXVsdDogX19iYWRfYXRvbWljX3NpemUoKTsgYnJlYWs7
Cj4gPiArwqDCoMKgIH0KPiA+ICt9Cj4gPiArCj4gPiArI2RlZmluZSByZWFkX2F0b21pYyhwKSAo
e8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgIFwKPiA+ICvCoMKgwqAgdW5pb24geyB0eXBlb2YoKihwKSkgdmFsOyBjaGFy
IGNbc2l6ZW9mKCoocCkpXTsgfSB4XzvCoMKgIFwKPiAKPiBPbmUgdHJhaWxpbmcgdW5kZXJzY29y
ZSBoZXJlLCBidXQgLi4uCj4gCj4gPiArwqDCoMKgIHJlYWRfYXRvbWljX3NpemUocCwgeF8uYywg
c2l6ZW9mKCoocCkpKTvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgXAo+ID4gK8KgwqDC
oCB4Xy52YWw7wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFwKPiA+ICt9
KQo+ID4gKwo+ID4gKyNkZWZpbmUgd3JpdGVfYXRvbWljKHAsIHgpwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBcCj4gPiArKHvCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFwKPiA+ICvCoMKgwqAg
dHlwZW9mKCoocCkpIHhfXyA9ICh4KTvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBcCj4gCj4gLi4uIHR3byBoZXJlIGFuZCAuLi4KPiAKPiA+
ICvCoMKgwqAgc3dpdGNoICggc2l6ZW9mKCoocCkpICnCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBcCj4gPiArwqDCoMKgIHvCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFwKPiA+ICvCoMKgwqAgY2FzZSAxOiB3
cml0ZWIoeF9fLCBwKTsgYnJlYWs7wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgIFwKPiA+ICvCoMKgwqAgY2FzZSAyOiB3cml0ZXcoeF9fLCBwKTsgYnJlYWs7wqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFwKPiA+ICvCoMKgwqAgY2FzZSA0
OiB3cml0ZWwoeF9fLCBwKTsgYnJlYWs7wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgIFwKPiA+ICvCoMKgwqAgY2FzZSA4OiB3cml0ZXEoeF9fLCBwKTsgYnJlYWs7wqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFwKPiA+ICvCoMKgwqAgZGVm
YXVsdDogX19iYWRfYXRvbWljX3NpemUoKTsgYnJlYWs7wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgIFwKPiA+ICvCoMKgwqAgfcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqAgXAo+ID4gK8KgwqDCoCB4X187wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoCBcCj4gPiArfSkKPiA+ICsKPiA+ICsjZGVmaW5lIGFkZF9zaXplZChwLCB4KcKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqAgXAo+ID4gKyh7wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoCBcCj4gPiArwqDCoMKgIHR5cGVvZigqKHApKSB4X18gPSAoeCk7wqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgXAo+IAo+IC4uLiBoZXJl
PwpJJ2xsIHVwZGF0ZSBpbiB0aGUgc2FtZSB3YXkuCgo+IAo+ID4gK8KgwqDCoCBzd2l0Y2ggKCBz
aXplb2YoKihwKSkgKcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgIFwKPiA+ICvCoMKgwqAge8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqAgXAo+ID4gK8KgwqDCoCBjYXNlIDE6IHdyaXRlYihyZWFkX2F0b21pYyhw
KSArIHhfXywgcCk7IGJyZWFrO8KgwqDCoMKgIFwKPiA+ICvCoMKgwqAgY2FzZSAyOiB3cml0ZXco
cmVhZF9hdG9taWMocCkgKyB4X18sIHApOyBicmVhazvCoMKgwqDCoCBcCj4gPiArwqDCoMKgIGNh
c2UgNDogd3JpdGVsKHJlYWRfYXRvbWljKHApICsgeF9fLCBwKTsgYnJlYWs7wqDCoMKgwqAgXAo+
ID4gK8KgwqDCoCBjYXNlIDg6IHdyaXRlcShyZWFkX2F0b21pYyhwKSArIHhfXywgcCk7IGJyZWFr
O8KgwqDCoMKgIFwKPiA+ICvCoMKgwqAgZGVmYXVsdDogX19iYWRfYXRvbWljX3NpemUoKTsgYnJl
YWs7wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFwKPiA+ICvCoMKgwqAgfcKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgXAo+ID4gK30pCj4gPiArCj4gPiAr
I2RlZmluZSBfX2F0b21pY19hY3F1aXJlX2ZlbmNlKCkgXAo+ID4gK8KgwqDCoCBhc20gdm9sYXRp
bGUgKCBSSVNDVl9BQ1FVSVJFX0JBUlJJRVIgIiIgOjo6ICJtZW1vcnkiICkKPiA+ICsKPiA+ICsj
ZGVmaW5lIF9fYXRvbWljX3JlbGVhc2VfZmVuY2UoKSBcCj4gPiArwqDCoMKgIGFzbSB2b2xhdGls
ZSAoIFJJU0NWX1JFTEVBU0VfQkFSUklFUiAiIiA6OjogIm1lbW9yeSIgKQo+ID4gKwo+ID4gKy8q
Cj4gPiArICogRmlyc3QsIHRoZSBhdG9taWMgb3BzIHRoYXQgaGF2ZSBubyBvcmRlcmluZyBjb25z
dHJhaW50cyBhbmQKPiA+IHRoZXJlZm9yIGRvbid0Cj4gPiArICogaGF2ZSB0aGUgQVEgb3IgUkwg
Yml0cyBzZXQuwqAgVGhlc2UgZG9uJ3QgcmV0dXJuIGFueXRoaW5nLCBzbwo+ID4gdGhlcmUncyBv
bmx5Cj4gPiArICogb25lIHZlcnNpb24gdG8gd29ycnkgYWJvdXQuCj4gPiArICovCj4gPiArI2Rl
ZmluZSBBVE9NSUNfT1Aob3AsIGFzbV9vcCwgSSwgYXNtX3R5cGUsIGNfdHlwZSwgcHJlZml4KcKg
IFwKPiA+ICtzdGF0aWMgaW5saW5lwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAg
XAo+ID4gK3ZvaWQgYXRvbWljIyNwcmVmaXgjI18jI29wKGNfdHlwZSBpLCBhdG9taWMjI3ByZWZp
eCMjX3QgKnYpIFwKPiA+ICt7wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqAgXAo+ID4gK8KgwqDCoCBhc20gdm9sYXRpbGUgKMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqAgXAo+ID4gK8KgwqDCoMKgwqDCoMKgICLCoMKgIGFtbyIgI2FzbV9v
cCAiLiIgI2FzbV90eXBlICIgemVybywgJTEsICUwIsKgwqDCoMKgwqAgXAo+ID4gK8KgwqDCoMKg
wqDCoMKgIDogIitBIiAodi0+Y291bnRlcinCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFwKPiA+ICvCoMKgwqDCoMKgwqDCoCA6
ICJyIiAoSSnCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgXAo+IAo+IEJ0dywgSSBjb25zaWRl
ciB0aGlzIHByZXR0eSBjb25mdXNpbmcuIEF0IHRoZSAxc3QgYW5kIDJuZCBnbGFuY2UgdGhpcwo+
IGxvb2tzIGxpa2UgYSBtaXN0YWtlLCBpLmUuIGFzIGlmIGkgd2FzIG1lYW50LiBJbW8gLi4uCj4g
Cj4gPiArwqDCoMKgwqDCoMKgwqAgOiAibWVtb3J5IiApO8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgXAo+
ID4gK33CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoCBcCj4gPiArCj4gPiArLyoKPiA+ICsgKiBPbmx5IENPTkZJR19HRU5FUklDX0FUT01J
QzY0PXkgd2FzIHBvcnRlZCB0byBYZW4gdGhhdCBpcyB0aGUKPiA+IHJlYXNvbiB3aHkKPiA+ICsg
KiBsYXN0IGFyZ3VtZW50IGZvciBBVE9NSUNfT1AgaXNuJ3QgdXNlZC4KPiA+ICsgKi8KPiA+ICsj
ZGVmaW5lIEFUT01JQ19PUFMob3AsIGFzbV9vcCwgSSnCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFwKPiA+ICvCoMKgwqDCoMKgwqDCoCBBVE9NSUNf
T1AgKG9wLCBhc21fb3AsIEksIHcsIGludCzCoMKgICkKPiA+ICsKPiA+ICtBVE9NSUNfT1BTKGFk
ZCwgYWRkLMKgIGkpCj4gPiArQVRPTUlDX09QUyhzdWIsIGFkZCwgLWkpCj4gPiArQVRPTUlDX09Q
UyhhbmQsIGFuZCzCoCBpKQo+ID4gK0FUT01JQ19PUFMoIG9yLMKgIG9yLMKgIGkpCj4gPiArQVRP
TUlDX09QUyh4b3IsIHhvcizCoCBpKQo+IAo+IC4uLiBoZXJlIHlvdSB3YW50IHRvIG9ubHkgcGFz
cyB0aGUgKHVuYXJ5KSBvcGVyYXRvciAoYW5kIGxlYXZpbmcgdGhhdAo+IGJsYW5rCj4gaXMgYXMg
ZmluZSBhcyB1c2luZyArKS4KSSBhZ3JlZSB0aGF0IGEgZ2FtZSB3aXRoICdpJyBhbmQgJ0knIGxv
b2tzIGNvbmZ1c2luZywgYnV0IEkgYW0gbm90CnJlYWxseSB1bmRlcnN0YW5kIHdoYXQgaXMgd3Jv
bmcgd2l0aCB1c2luZyAnIGknIGhlcmUuIEl0IHNlZW1zIHRoYXQKcHJlcHJvY2Vzc2VkIG1hY3Jv
cyBsb29rcyBmaW5lOgogICBzdGF0aWMgaW5saW5lIHZvaWQgYXRvbWljX2FkZChpbnQgaSwgYXRv
bWljX3QgKnYpIHsgYXNtIHZvbGF0aWxlICggIiAgCiAgIGFtbyIgImFkZCIgIi4iICJ3IiAiIHpl
cm8sICUxLCAlMCIgOiAiK0EiICh2LT5jb3VudGVyKSA6ICJyIiAoaSkgOgogICAibWVtb3J5IiAp
OyB9CiAgIAogICBzdGF0aWMgaW5saW5lIHZvaWQgYXRvbWljX3N1YihpbnQgaSwgYXRvbWljX3Qg
KnYpIHsgYXNtIHZvbGF0aWxlICggIiAgCiAgIGFtbyIgImFkZCIgIi4iICJ3IiAiIHplcm8sICUx
LCAlMCIgOiAiK0EiICh2LT5jb3VudGVyKSA6ICJyIiAoLWkpIDoKICAgIm1lbW9yeSIgKTsgfQoK
PiAKPiA+ICsjdW5kZWYgQVRPTUlDX09QCj4gPiArI3VuZGVmIEFUT01JQ19PUFMKPiA+ICsKPiA+
ICsjaW5jbHVkZSA8YXNtLWdlbmVyaWMvYXRvbWljLW9wcy5oPgo+ID4gKwo+ID4gKy8qCj4gPiAr
ICogQXRvbWljIG9wcyB0aGF0IGhhdmUgb3JkZXJlZCwgcmVsYXhlZCwgYWNxdWlyZSwgYW5kIHJl
bGVhc2UKPiA+IHZhcmlhbnRzLgo+IAo+IE9ubHkgdGhlIGZpcnN0IGlzIGltcGxlbWVudGVkIGFm
YWljdDsgaW1vIHRoZSBjb21tZW50IHdvdWxkIGJldHRlcgo+IHJlZmxlY3QKPiB0aGF0IG9uZSB3
YXkgb3IgYW5vdGhlci4KPiAKPiA+ICsgKiBUaGVyZSdzIHR3byBmbGF2b3JzIG9mIHRoZXNlOiB0
aGUgYXJpdGhtYXRpYyBvcHMgaGF2ZSBib3RoCj4gPiBmZXRjaCBhbmQgcmV0dXJuCj4gPiArICog
dmVyc2lvbnMsIHdoaWxlIHRoZSBsb2dpY2FsIG9wcyBvbmx5IGhhdmUgZmV0Y2ggdmVyc2lvbnMu
Cj4gPiArICovCj4gPiArI2RlZmluZSBBVE9NSUNfRkVUQ0hfT1Aob3AsIGFzbV9vcCwgSSwgYXNt
X3R5cGUsIGNfdHlwZSwKPiA+IHByZWZpeCnCoMKgwqAgXAo+ID4gK3N0YXRpYwo+ID4gaW5saW5l
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFwKPiA+
ICtjX3R5cGUgYXRvbWljIyNwcmVmaXgjI19mZXRjaF8jI29wIyNfcmVsYXhlZChjX3R5cGUKPiA+
IGkswqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgXAo+ID4gK8KgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBhdG9taWMjI3ByZWZpeCMjX3QKPiA+ICp2KcKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgXAo+ID4gK3vCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgCj4gPiDCoCBcCj4gPiArwqDCoMKgIHJlZ2lzdGVyIGNfdHlwZQo+ID4gcmV0O8KgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFwKPiA+ICvCoMKgwqAgYXNtIHZvbGF0aWxlCj4gPiAo
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgXAo+ID4gK8KgwqDCoMKg
wqDCoMKgICLCoMKgIGFtbyIgI2FzbV9vcCAiLiIgI2FzbV90eXBlICIgJTEsICUyLAo+ID4gJTAi
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFwKPiA+ICvCoMKgwqDCoMKgwqDCoCA6ICIr
QSIgKHYtPmNvdW50ZXIpLCAiPXIiCj4gPiAocmV0KcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFwKPiA+ICvCoMKgwqDCoMKgwqDCoCA6ICJy
Igo+ID4gKEkpwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBcCj4g
PiArwqDCoMKgwqDCoMKgwqAgOiAibWVtb3J5Igo+ID4gKTvCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoCBcCj4gPiArwqDCoMKgIHJldHVybgo+ID4gcmV0O8KgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFwKPiA+ICt9wqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oAo+ID4gwqAgXAo+IAo+IEFjdHVhbGx5IGEgcmVsYXhlZCBmb3JtIGlzIHByb3ZpZGVkIGhlcmUs
IGJ1dCBkb2VzIHRoYXQgaGF2ZSBhbnkKPiB1c2VyPwpUaGVyZSBpcyBubyB1c2VyIGZvciBhIHJl
bGF4ZWQgZm9ybSwganVzdCBvdmVybG9va2VkIHRoYXQuCgo+IAo+ID4gK3N0YXRpYwo+ID4gaW5s
aW5lwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFwK
PiA+ICtjX3R5cGUgYXRvbWljIyNwcmVmaXgjI19mZXRjaF8jI29wKGNfdHlwZSBpLCBhdG9taWMj
I3ByZWZpeCMjX3QKPiA+ICp2KSBcCj4gPiAre8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAKPiA+IMKgIFwKPiA+
ICvCoMKgwqAgcmVnaXN0ZXIgY190eXBlCj4gPiByZXQ7wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqAgXAo+ID4gK8KgwqDCoCBhc20gdm9sYXRpbGUKPiA+ICjCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBcCj4gPiArwqDCoMKgwqDCoMKgwqAgIsKgwqAgYW1vIiAj
YXNtX29wICIuIiAjYXNtX3R5cGUgIi5hcXJswqAgJTEsICUyLAo+ID4gJTAiwqDCoMKgwqDCoMKg
wqDCoMKgIFwKPiA+ICvCoMKgwqDCoMKgwqDCoCA6ICIrQSIgKHYtPmNvdW50ZXIpLCAiPXIiCj4g
PiAocmV0KcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgIFwKPiA+ICvCoMKgwqDCoMKgwqDCoCA6ICJyIgo+ID4gKEkpwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBcCj4gPiArwqDCoMKgwqDCoMKgwqAgOiAibWVt
b3J5Igo+ID4gKTvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBcCj4gPiArwqDC
oMKgIHJldHVybgo+ID4gcmV0O8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgIFwKPiA+ICt9Cj4gPiArCj4gPiArI2RlZmluZSBBVE9NSUNfT1BfUkVUVVJOKG9w
LCBhc21fb3AsIGNfb3AsIEksIGFzbV90eXBlLCBjX3R5cGUsCj4gPiBwcmVmaXgpIFwKPiA+ICtz
dGF0aWMKPiA+IGlubGluZcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgIFwKPiA+ICtjX3R5cGUgYXRvbWljIyNwcmVmaXgjI18jI29wIyNf
cmV0dXJuX3JlbGF4ZWQoY190eXBlCj4gPiBpLMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgIFwKPiA+ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoCBhdG9taWMjI3ByZWZpeCMjX3QKPiA+ICp2KcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqAgXAo+ID4gK3vCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgCj4gPiDCoMKgwqDC
oMKgIFwKPiA+ICvCoMKgwqDCoMKgwqDCoCByZXR1cm4gYXRvbWljIyNwcmVmaXgjI19mZXRjaF8j
I29wIyNfcmVsYXhlZChpLCB2KSBjX29wCj4gPiBJO8KgwqDCoMKgwqAgXAo+ID4gK33CoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgCj4gPiDCoMKgwqDCoMKgIFwKPiA+ICtzdGF0aWMKPiA+IGlubGluZcKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFwKPiA+
ICtjX3R5cGUgYXRvbWljIyNwcmVmaXgjI18jI29wIyNfcmV0dXJuKGNfdHlwZSBpLCBhdG9taWMj
I3ByZWZpeCMjX3QKPiA+ICp2KcKgIFwKPiA+ICt7wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoAo+ID4gwqDCoMKg
wqDCoCBcCj4gPiArwqDCoMKgwqDCoMKgwqAgcmV0dXJuIGF0b21pYyMjcHJlZml4IyNfZmV0Y2hf
IyNvcChpLCB2KSBjX29wCj4gPiBJO8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBcCj4g
Cj4gSSAob3Igd2hhdGV2ZXIgdGhlIHJlcGxhY2VtZW50IGV4cHJlc3Npb24gaXMgZ29pbmcgdG8g
YmUgZm9sbG93aW5nCj4gdGhlCj4gZWFybGllciBjb21tZW50KSB3YW50cyBwYXJlbnRoZXNpemlu
ZyBoZXJlLgo+IAo+ID4gK30KPiA+ICsKPiA+ICsvKgo+ID4gKyAqIE9ubHkgQ09ORklHX0dFTkVS
SUNfQVRPTUlDNjQ9eSB3YXMgcG9ydGVkIHRvIFhlbiB0aGF0IGlzIHRoZQo+ID4gcmVhc29uIHdo
eQo+ID4gKyAqIGxhc3QgYXJndW1lbnQgb2YgQVRPTUlDX0ZFVENIX09QLCBBVE9NSUNfT1BfUkVU
VVJOIGlzbid0IHVzZWQuCj4gPiArICovCj4gPiArI2RlZmluZSBBVE9NSUNfT1BTKG9wLCBhc21f
b3AsIGNfb3AsCj4gPiBJKcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgXAo+ID4gK8KgwqDCoMKgwqDCoMKgIEFUT01JQ19GRVRD
SF9PUCggb3AsIGFzbV9vcCzCoMKgwqDCoMKgwqAgSSwgdywgaW50LMKgwqAKPiA+ICnCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgIFwKPiA+ICvCoMKgwqDCoMKgwqDCoCBBVE9NSUNfT1BfUkVU
VVJOKG9wLCBhc21fb3AsIGNfb3AsIEksIHcsIGludCzCoMKgICkKPiA+ICsKPiA+ICtBVE9NSUNf
T1BTKGFkZCwgYWRkLCArLMKgIGkpCj4gPiArQVRPTUlDX09QUyhzdWIsIGFkZCwgKywgLWkpCj4g
PiArCj4gPiArI3VuZGVmIEFUT01JQ19PUFMKPiA+ICsKPiA+ICsjZGVmaW5lIEFUT01JQ19PUFMo
b3AsIGFzbV9vcCwgSSkgXAo+ID4gK8KgwqDCoMKgwqDCoMKgIEFUT01JQ19GRVRDSF9PUChvcCwg
YXNtX29wLCBJLCB3LCBpbnQswqDCoCApCj4gPiArCj4gPiArQVRPTUlDX09QUyhhbmQsIGFuZCwg
aSkKPiA+ICtBVE9NSUNfT1BTKCBvcizCoCBvciwgaSkKPiA+ICtBVE9NSUNfT1BTKHhvciwgeG9y
LCBpKQo+ID4gKwo+ID4gKyN1bmRlZiBBVE9NSUNfT1BTCj4gPiArCj4gPiArI3VuZGVmIEFUT01J
Q19GRVRDSF9PUAo+ID4gKyN1bmRlZiBBVE9NSUNfT1BfUkVUVVJOCj4gPiArCj4gPiArLyogVGhp
cyBpcyByZXF1aXJlZCB0byBwcm92aWRlIGEgZnVsbCBiYXJyaWVyIG9uIHN1Y2Nlc3MuICovCj4g
PiArc3RhdGljIGlubGluZSBpbnQgYXRvbWljX2FkZF91bmxlc3MoYXRvbWljX3QgKnYsIGludCBh
LCBpbnQgdSkKPiA+ICt7Cj4gPiArwqDCoMKgwqDCoMKgIGludCBwcmV2LCByYzsKPiA+ICsKPiA+
ICvCoMKgwqAgYXNtIHZvbGF0aWxlICgKPiA+ICvCoMKgwqDCoMKgwqDCoCAiMDogbHIud8KgwqDC
oMKgICVbcF0swqAgJVtjXVxuIgo+ID4gK8KgwqDCoMKgwqDCoMKgICLCoMKgIGJlccKgwqDCoMKg
wqAgJVtwXSzCoCAlW3VdLCAxZlxuIgo+ID4gK8KgwqDCoMKgwqDCoMKgICLCoMKgIGFkZMKgwqDC
oMKgwqAgJVtyY10sICVbcF0sICVbYV1cbiIKPiA+ICvCoMKgwqDCoMKgwqDCoCAiwqDCoCBzYy53
LnJswqAgJVtyY10sICVbcmNdLCAlW2NdXG4iCj4gPiArwqDCoMKgwqDCoMKgwqAgIsKgwqAgYm5l
esKgwqDCoMKgICVbcmNdLCAwYlxuIgo+ID4gK8KgwqDCoMKgwqDCoMKgIFJJU0NWX0ZVTExfQkFS
UklFUgo+IAo+IFdpdGggdGhpcyBhbmQgbm8gLmFxIG9uIHRoZSBsb2FkLCB3aHkgdGhlIC5ybCBv
biB0aGUgc3RvcmU/Ckl0IGlzIHNvbWV0aGluZyB0aGF0IExLTU0gcmVxdWlyZXMgWzFdLgoKVGhp
cyBpcyBub3QgZnVsbHkgY2xlYXIgdG8gbWUgd2hhdCBpcyBzbyBzcGVjaWZpYyBpbiBMS01NLCBi
dXQgYWNjb3JpbmcKdG8gdGhlIHNwZWM6CiAgIE9yZGVyaW5nIEFubm90YXRpb24gRmVuY2UtYmFz
ZWQgRXF1aXZhbGVudAogICBse2J8aHx3fGR8cn0uYXEgICAgIGx7YnxofHd8ZHxyfTsgZmVuY2Ug
cixydwogICBse2J8aHx3fGR8cn0uYXFybCAgIGZlbmNlIHJ3LHJ3OyBse2J8aHx3fGR8cn07IGZl
bmNlIHIscncKICAgc3tifGh8d3xkfGN9LnJsICAgICBmZW5jZSBydyx3OyBze2J8aHx3fGR8Y30K
ICAgc3tifGh8d3xkfGN9LmFxcmwgICBmZW5jZSBydyx3OyBze2J8aHx3fGR8Y30KICAgYW1vPG9w
Pi5hcSAgICAgICAgICBhbW88b3A+OyBmZW5jZSByLHJ3CiAgIGFtbzxvcD4ucmwgICAgICAgICAg
ZmVuY2UgcncsdzsgYW1vPG9wPgogICBhbW88b3A+LmFxcmwgICAgICAgIGZlbmNlIHJ3LHJ3OyBh
bW88b3A+OyBmZW5jZSBydyxydwogICBUYWJsZSAyLjI6IE1hcHBpbmdzIGZyb20gLmFxIGFuZC9v
ciAucmwgdG8gZmVuY2UtYmFzZWQgZXF1aXZhbGVudHMuCiAgIEFuIGFsdGVybmF0aXZlIG1hcHBp
bmcgcGxhY2VzIGEgZmVuY2UgcncscncgYWZ0ZXIgdGhlIGV4aXN0aW5nIAogICBze2J8aHx3fGR8
Y30gbWFwcGluZyByYXRoZXIgdGhhbiBhdCB0aGUgZnJvbnQgb2YgdGhlCiAgIGx7YnxofHd8ZHxy
fSBtYXBwaW5nLgogICAKICAgSXQgaXMgYWxzbyBzYWZlIHRvIHRyYW5zbGF0ZSBhbnkgLmFxLCAu
cmwsIG9yIC5hcXJsIGFubm90YXRpb24gaW50bwogICB0aGUgZmVuY2UtYmFzZWQgc25pcHBldHMg
b2YKICAgVGFibGUgMi4yLiBUaGVzZSBjYW4gYWxzbyBiZSB1c2VkIGFzIGEgbGVnYWwgaW1wbGVt
ZW50YXRpb24gb2YKICAgbHtifGh8d3xkfSBvciBze2J8aHx3fGR9IHBzZXUtCiAgIGRvaW5zdHJ1
Y3Rpb25zIGZvciBhcyBsb25nIGFzIHRob3NlIGluc3RydWN0aW9ucyBhcmUgbm90IGFkZGVkIHRv
CiAgIHRoZSBJU0EuCgpTbyBhY2NvcmRpbmcgdG8gdGhlIHNwZWMsIGl0IHNob3VsZCBiZToKIHNj
LncgLi4uCiBSSVNDVl9GVUxMX0JBUlJJRVIuCgpDb25zaWRlcmluZyBbMV0gYW5kIGhvdyB0aGlz
IGNvZGUgbG9va3MgYmVmb3JlLCBpdCBzZWVtcyB0byBtZSB0aGF0IGl0CmlzIHNhZmUgdG8gdXNl
IGxyLncuYXEvc2Mudy5ybCBoZXJlIG9yIGFuIGZlbmNlIGVxdWl2YWxlbnQuCgpCdXQgaW4gZ2Vu
ZXJhbCBpdCAoIGEgY29tYmluYXRpb24gb2YgZmVuY2UsIC5hcSwgLnJsICkgY2FuIGJlCmNvbnNp
ZGVyZWQgYXMgdGhlIHNhbWUgdGhpbmdzIGluIHRoaXMgY29udGV4dCwgc28gaXQgaXMgcG9zc2li
bGUgdG8KbGVhdmUgdGhpcyBmdW5jdGlvbiBhcyBpcyB0byBiZSBzeW5jZWQgaGVyZSB3aXRoIExp
bnV4IGtlcm5lbC4KClsxXWh0dHBzOi8vbG9yZS5rZXJuZWwub3JnL2xrbWwvMTUyMDI3NDI3Ni0y
MTg3MS0xLWdpdC1zZW5kLWVtYWlsLXBhcnJpLmFuZHJlYUBnbWFpbC5jb20vCgp+IE9sZWtzaWkK
Cj4gCj4gPiArwqDCoMKgwqDCoMKgwqAgIjE6XG4iCj4gPiArwqDCoMKgwqDCoMKgwqAgOiBbcF0g
Ij0mciIgKHByZXYpLCBbcmNdICI9JnIiIChyYyksIFtjXSAiK0EiICh2LT5jb3VudGVyKQo+ID4g
K8KgwqDCoMKgwqDCoMKgIDogW2FdICJyIiAoYSksIFt1XSAiciIgKHUpCj4gPiArwqDCoMKgwqDC
oMKgwqAgOiAibWVtb3J5Iik7Cj4gPiArwqDCoMKgIHJldHVybiBwcmV2Owo+ID4gK30KPiA+ICsK
PiA+ICsvKgo+ID4gKyAqIGF0b21pY197Y21wLH14Y2hnIGlzIHJlcXVpcmVkIHRvIGhhdmUgZXhh
Y3RseSB0aGUgc2FtZSBvcmRlcmluZwo+ID4gc2VtYW50aWNzIGFzCj4gPiArICoge2NtcCx9eGNo
ZyBhbmQgdGhlIG9wZXJhdGlvbnMgdGhhdCByZXR1cm4uCj4gPiArICovCj4gPiArI2RlZmluZSBB
VE9NSUNfT1AoY190LCBwcmVmaXgsIHNpemUpwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFwKPiA+ICtzdGF0aWMgaW5saW5lwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBcCj4gPiArY190IGF0b21pYyMjcHJlZml4
IyNfeGNoZyhhdG9taWMjI3ByZWZpeCMjX3QgKnYsIGNfdCBuKcKgwqDCoMKgwqDCoMKgwqAgXAo+
ID4gK3vCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgIFwKPiA+ICvCoMKgwqAgcmV0dXJuIF9feGNoZygmKHYtPmNvdW50ZXIp
LCBuLCBzaXplKTvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgXAo+
IAo+IE5vIG5lZWQgZm9yIHRoZSBpbm5lciBwYXJlbnRoZXNlcywganVzdCBsaWtlIC4uLgo+IAo+
ID4gK33CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgIFwKPiA+ICtzdGF0aWMgaW5saW5lwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBcCj4gPiArY190IGF0b21pYyMjcHJlZml4IyNfY21weGNo
ZyhhdG9taWMjI3ByZWZpeCMjX3QgKnYsIGNfdCBvLCBjX3QgbikKPiA+IFwKPiA+ICt7wqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoCBcCj4gPiArwqDCoMKgIHJldHVybiBfX2NtcHhjaGcoJnYtPmNvdW50ZXIsIG8sIG4sIHNp
emUpO8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgXAo+IAo+IC4uLiB5b3UgaGF2
ZSBpdCBoZXJlLgo+IAo+ID4gK30KPiA+ICsKPiA+ICsjZGVmaW5lIEFUT01JQ19PUFMoKSBcCj4g
PiArwqDCoMKgIEFUT01JQ19PUChpbnQswqDCoCAsIDQpCj4gPiArCj4gPiArQVRPTUlDX09QUygp
Cj4gPiArCj4gPiArI3VuZGVmIEFUT01JQ19PUFMKPiA+ICsjdW5kZWYgQVRPTUlDX09QCj4gPiAr
Cj4gPiArc3RhdGljIGlubGluZSBpbnQgYXRvbWljX3N1Yl9pZl9wb3NpdGl2ZShhdG9taWNfdCAq
diwgaW50IG9mZnNldCkKPiA+ICt7Cj4gPiArwqDCoMKgwqDCoMKgIGludCBwcmV2LCByYzsKPiA+
ICsKPiA+ICvCoMKgwqAgYXNtIHZvbGF0aWxlICgKPiA+ICvCoMKgwqDCoMKgwqDCoCAiMDogbHIu
d8KgwqDCoMKgICVbcF0swqAgJVtjXVxuIgo+ID4gK8KgwqDCoMKgwqDCoMKgICLCoMKgIHN1YsKg
wqDCoMKgwqAgJVtyY10sICVbcF0sICVbb11cbiIKPiA+ICvCoMKgwqDCoMKgwqDCoCAiwqDCoCBi
bHR6wqDCoMKgwqAgJVtyY10sIDFmXG4iCj4gPiArwqDCoMKgwqDCoMKgwqAgIsKgwqAgc2Mudy5y
bMKgICVbcmNdLCAlW3JjXSwgJVtjXVxuIgo+ID4gK8KgwqDCoMKgwqDCoMKgICLCoMKgIGJuZXrC
oMKgwqDCoCAlW3JjXSwgMGJcbiIKPiA+ICvCoMKgwqDCoMKgwqDCoCAiwqDCoCBmZW5jZcKgwqDC
oCBydywgcndcbiIKPiA+ICvCoMKgwqDCoMKgwqDCoCAiMTpcbiIKPiA+ICvCoMKgwqDCoMKgwqDC
oCA6IFtwXSAiPSZyIiAocHJldiksIFtyY10gIj0mciIgKHJjKSwgW2NdICIrQSIgKHYtPmNvdW50
ZXIpCj4gPiArwqDCoMKgwqDCoMKgwqAgOiBbb10gInIiIChvZmZzZXQpCj4gPiArwqDCoMKgwqDC
oMKgwqAgOiAibWVtb3J5IiApOwo+ID4gK8KgwqDCoCByZXR1cm4gcHJldiAtIG9mZnNldDsKPiA+
ICt9Cj4gCj4gVGhpcyBwcm9iYWJseSB3b3VsZCBiZSBuaWNlciBpZiBzaXR0aW5nIG5leHQgdG8g
YXRvbWljX2FkZF91bmxlc3MoKS4KPiAKPiA+IC0tLSAvZGV2L251bGwKPiA+ICsrKyBiL3hlbi9p
bmNsdWRlL2FzbS1nZW5lcmljL2F0b21pYy1vcHMuaAo+ID4gQEAgLTAsMCArMSw5NyBAQAo+ID4g
Ky8qIFNQRFgtTGljZW5zZS1JZGVudGlmaWVyOiBHUEwtMi4wICovCj4gPiArLyoKPiA+ICsgKiBU
aGUgaGVhZGVyIHByb3ZpZGVzIGRlZmF1bHQgaW1wbGVtZW50YXRpb25zIGZvciBldmVyeQo+ID4g
eGVuL2F0b21pYy5oLXByb3ZpZGVkCj4gPiArICogZm9yd2FyZCBpbmxpbmUgZGVjbGFyYXRpb24g
dGhhdCBjYW4gYmUgc3ludGhlc2l6ZWQgZnJvbSBvdGhlcgo+ID4gYXRvbWljCj4gPiArICogZnVu
Y3Rpb25zLgo+IAo+IE9yIGZyb20gc2NyYXRjaCwgYXMgZS5nLiAuLi4KPiAKPiA+ICsgKi8KPiA+
ICsjaWZuZGVmIF9BU01fR0VORVJJQ19BVE9NSUNfT1BTX0hfCj4gPiArI2RlZmluZSBfQVNNX0dF
TkVSSUNfQVRPTUlDX09QU19IXwo+ID4gKwo+ID4gKyNpbmNsdWRlIDx4ZW4vYXRvbWljLmg+Cj4g
PiArI2luY2x1ZGUgPHhlbi9saWIuaD4KPiA+ICsKPiA+ICsjaWZuZGVmIEFUT01JQ19SRUFECj4g
PiArc3RhdGljIGlubGluZSBpbnQgYXRvbWljX3JlYWQoY29uc3QgYXRvbWljX3QgKnYpCj4gPiAr
ewo+ID4gK8KgwqDCoCByZXR1cm4gQUNDRVNTX09OQ0Uodi0+Y291bnRlcik7Cj4gPiArfQo+ID4g
KyNlbmRpZgo+ID4gKwo+ID4gKyNpZm5kZWYgX0FUT01JQ19SRUFECj4gPiArc3RhdGljIGlubGlu
ZSBpbnQgX2F0b21pY19yZWFkKGF0b21pY190IHYpCj4gPiArewo+ID4gK8KgwqDCoCByZXR1cm4g
di5jb3VudGVyOwo+ID4gK30KPiA+ICsjZW5kaWYKPiA+ICsKPiA+ICsjaWZuZGVmIEFUT01JQ19T
RVQKPiA+ICtzdGF0aWMgaW5saW5lIHZvaWQgYXRvbWljX3NldChhdG9taWNfdCAqdiwgaW50IGkp
Cj4gPiArewo+ID4gK8KgwqDCoCBBQ0NFU1NfT05DRSh2LT5jb3VudGVyKSA9IGk7Cj4gPiArfQo+
ID4gKyNlbmRpZgo+ID4gKwo+ID4gKyNpZm5kZWYgX0FUT01JQ19TRVQKPiA+ICtzdGF0aWMgaW5s
aW5lIHZvaWQgX2F0b21pY19zZXQoYXRvbWljX3QgKnYsIGludCBpKQo+ID4gK3sKPiA+ICvCoMKg
wqAgdi0+Y291bnRlciA9IGk7Cj4gPiArfQo+ID4gKyNlbmRpZgo+IAo+IC4uLiBhbGwgb2YgdGhl
c2UuCj4gCj4gPiArI2lmbmRlZiBBVE9NSUNfU1VCX0FORF9URVNUCj4gPiArc3RhdGljIGlubGlu
ZSBpbnQgYXRvbWljX3N1Yl9hbmRfdGVzdChpbnQgaSwgYXRvbWljX3QgKnYpCj4gPiArewo+ID4g
K8KgwqDCoCByZXR1cm4gYXRvbWljX3N1Yl9yZXR1cm4oaSwgdikgPT0gMDsKPiA+ICt9Cj4gPiAr
I2VuZGlmCj4gPiArCj4gPiArI2lmbmRlZiBBVE9NSUNfSU5DCj4gPiArc3RhdGljIGlubGluZSB2
b2lkIGF0b21pY19pbmMoYXRvbWljX3QgKnYpCj4gPiArewo+ID4gK8KgwqDCoCBhdG9taWNfYWRk
KDEsIHYpOwo+ID4gK30KPiA+ICsjZW5kaWYKPiA+ICsKPiA+ICsjaWZuZGVmIEFUT01JQ19JTkNf
UkVUVVJOCj4gPiArc3RhdGljIGlubGluZSBpbnQgYXRvbWljX2luY19yZXR1cm4oYXRvbWljX3Qg
KnYpCj4gPiArewo+ID4gK8KgwqDCoCByZXR1cm4gYXRvbWljX2FkZF9yZXR1cm4oMSwgdik7Cj4g
PiArfQo+ID4gKyNlbmRpZgo+ID4gKwo+ID4gKyNpZm5kZWYgQVRPTUlDX0RFQwo+ID4gK3N0YXRp
YyBpbmxpbmUgdm9pZCBhdG9taWNfZGVjKGF0b21pY190ICp2KQo+ID4gK3sKPiA+ICvCoMKgwqAg
YXRvbWljX3N1YigxLCB2KTsKPiA+ICt9Cj4gPiArI2VuZGlmCj4gPiArCj4gPiArI2lmbmRlZiBB
VE9NSUNfREVDX1JFVFVSTgo+ID4gK3N0YXRpYyBpbmxpbmUgaW50IGF0b21pY19kZWNfcmV0dXJu
KGF0b21pY190ICp2KQo+ID4gK3sKPiA+ICvCoMKgwqAgcmV0dXJuIGF0b21pY19zdWJfcmV0dXJu
KDEsIHYpOwo+ID4gK30KPiA+ICsjZW5kaWYKPiA+ICsKPiA+ICsjaWZuZGVmIEFUT01JQ19ERUNf
QU5EX1RFU1QKPiA+ICtzdGF0aWMgaW5saW5lIGludCBhdG9taWNfZGVjX2FuZF90ZXN0KGF0b21p
Y190ICp2KQo+ID4gK3sKPiA+ICvCoMKgwqAgcmV0dXJuIGF0b21pY19zdWJfcmV0dXJuKDEsIHYp
ID09IDA7Cj4gPiArfQo+ID4gKyNlbmRpZgo+ID4gKwo+ID4gKyNpZm5kZWYgQVRPTUlDX0FERF9O
RUdBVElWRQo+ID4gK3N0YXRpYyBpbmxpbmUgaW50IGF0b21pY19hZGRfbmVnYXRpdmUoaW50IGks
IGF0b21pY190ICp2KQo+ID4gK3sKPiA+ICvCoMKgwqAgcmV0dXJuIGF0b21pY19hZGRfcmV0dXJu
KGksIHYpIDwgMDsKPiA+ICt9Cj4gPiArI2VuZGlmCj4gPiArCj4gPiArI2lmbmRlZiBBVE9NSUNf
SU5DX0FORF9URVNUCj4gPiArc3RhdGljIGlubGluZSBpbnQgYXRvbWljX2luY19hbmRfdGVzdChh
dG9taWNfdCAqdikKPiA+ICt7Cj4gPiArwqDCoMKgIHJldHVybiBhdG9taWNfYWRkX3JldHVybigx
LCB2KSA9PSAwOwo+ID4gK30KPiA+ICsjZW5kaWYKPiAKPiBDYW4gdGhpcyBiZSBtb3ZlZCB1cCBh
IGxpdHRsZSwgcGVyaGFwcyBuZXh0IHRvIHRoZSBvdGhlciBpbmMtcyAob3IKPiBlbHNlCj4gbmV4
dCB0byBkZWNfYW5kX3Rlc3QpLCBwbGVhc2U/Cj4gCj4gSmFuCgo=



From xen-devel-bounces@lists.xenproject.org Fri Mar 22 12:26:49 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Mar 2024 12:26:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696854.1088034 (Exim 4.92)
	(envelope-from )
	id 1rndyy-0006Gh-R6; Fri, 22 Mar 2024 12:26:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696854.1088034; Fri, 22 Mar 2024 12:26:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rndyy-0006Ga-OY; Fri, 22 Mar 2024 12:26:48 +0000
Received: by outflank-mailman (input) for mailman id 696854;
 Fri, 22 Mar 2024 12:26:48 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rndyy-0006GR-6d
 for xen-devel@lists.xenproject.org; Fri, 22 Mar 2024 12:26:48 +0000
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com
 [2a00:1450:4864:20::62e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 72e4bb44-e847-11ee-a1ee-f123f15fe8a2;
 Fri, 22 Mar 2024 13:26:46 +0100 (CET)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-a468004667aso293930066b.2
 for ; Fri, 22 Mar 2024 05:26:46 -0700 (PDT)
Received: from [192.168.206.239] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 j20-20020a170906475400b00a46cc48ab07sm965496ejs.221.2024.03.22.05.26.44
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 22 Mar 2024 05:26:45 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 72e4bb44-e847-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1711110406; x=1711715206; darn=lists.xenproject.org;
        h=mime-version:user-agent:content-transfer-encoding:references
         :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject
         :date:message-id:reply-to;
        bh=2r3y+dx+CyevSy20ZzcwhiqyVuOXpNZgGm5JdYb6VhE=;
        b=QNwkUz6JjZszLZsjUYjilZSYAE3cpmsx5CibGNCRafIyPW2mFAx/isGT/AtUv+yYc2
         Bb7LTVfoTiHhUcn7qu/06trlCfc3zgCJw25hkXDkAeOQDqOrgy0ZF5UrmQsxpI6+NUdv
         ZcEFUlZvkBVaz5250AbHOWT2nnivzz5LZ5vJZhqYYcAFGCqzflISQ/025/tp/+5q+phS
         lGq2niAi9sdmzVV0ABYswhV26n+vX8HVIFPaGMwt2tpS5Xif7sBD85jXzfaPm/rDgCkj
         U17sgljJEnUdgIKY+wM3qmUboVMoHcqqwJuGLN/sYoXY302O0+IwJlbRBz7wkXmNkEQP
         IHCA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711110406; x=1711715206;
        h=mime-version:user-agent:content-transfer-encoding:references
         :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=2r3y+dx+CyevSy20ZzcwhiqyVuOXpNZgGm5JdYb6VhE=;
        b=K4TM0LkZYozUXW3X9jRSQzaBl96Z5mrM/eFaOyOFKB9uG8niv1S2piMdsxR2DXlS3c
         2gL+TE2eXRGOAuOiB0gi1uZFu6JPerql/AQfWAi/r/noBI6r4JqXXnkKOget3cwAxzLC
         mLVVyFzM2QEjLDZUaoOkFx1ckFp8RCGkcSajAktUhQNbgbSjuhUn+dCIBEcWkOIf2/PI
         O6ZLWNPuIblzzUqvs+BuwvXdyhdffEDPU5lGrBeUPN0HCsuZarUpdRRdK+Z4dNjou6Q+
         FoW7Bmv2nYaLqWp0xjPNCpJ6uR2qfRF6HE8qtLiJ8AHERpGYg1xI7AVfW6/Ph9x7J2Xw
         VyBQ==
X-Forwarded-Encrypted: i=1; AJvYcCV2pa31HzptzZhJ8th7B/R1czF4eiICUJ6QKM5NBcE+0ura/6XHtEECJoSe2NAXillHV+NY0WIIoEHKHQtYPztSGVw0DEszbWvcXoCZEEo=
X-Gm-Message-State: AOJu0YznatofWzyAAzllIArgs2l0APymnW9IYa6SSnC75VafkQgis/9X
	4H0D6DbAYEQauRMWXlM8nJ+6eMnymBcQfdSm2pr5mtW1IiOntH4q
X-Google-Smtp-Source: AGHT+IF3FfXwJFKR+QlDi1JxhgEGOcCl+LBHS4ilrZ14dVU0Pv+7/gaji6dDMpVm1tylTGO+hBDh1A==
X-Received: by 2002:a17:907:bb8e:b0:a47:2f8c:7614 with SMTP id xo14-20020a170907bb8e00b00a472f8c7614mr1132524ejc.43.1711110405761;
        Fri, 22 Mar 2024 05:26:45 -0700 (PDT)
Message-ID: 
Subject: Re: [PATCH v6 15/20] xen/riscv: add minimal stuff to processor.h to
 build full Xen
From: Oleksii 
To: Jan Beulich 
Cc: Alistair Francis , Bob Eshleman
 , Connor Davis , Andrew
 Cooper , George Dunlap
 ,  Julien Grall , Stefano
 Stabellini , Wei Liu , 
 xen-devel@lists.xenproject.org
Date: Fri, 22 Mar 2024 13:26:44 +0100
In-Reply-To: <026c4245-5a8c-4e09-9026-44b8f3daca67@suse.com>
References: 
	 
	 <026c4245-5a8c-4e09-9026-44b8f3daca67@suse.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.50.2 (3.50.2-1.fc39) 
MIME-Version: 1.0

On Thu, 2024-03-21 at 14:26 +0100, Jan Beulich wrote:
> On 15.03.2024 19:06, Oleksii Kurochko wrote:
> > The cpu_relax() function, introduced in this commit, is anticipated
> > to
> > support _zihintpause by the CPU.
> >=20
> > Signed-off-by: Oleksii Kurochko 
>=20
> Acked-by: Jan Beulich 
Thanks.

>=20
> Looks like this can go in ahead of the other 14 patches?
Yes, it can. I'll rebase it ahead.

~ Oleksii


From xen-devel-bounces@lists.xenproject.org Fri Mar 22 12:52:33 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Mar 2024 12:52:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696862.1088044 (Exim 4.92)
	(envelope-from )
	id 1rneNm-0003bP-QE; Fri, 22 Mar 2024 12:52:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696862.1088044; Fri, 22 Mar 2024 12:52:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rneNm-0003bI-NZ; Fri, 22 Mar 2024 12:52:26 +0000
Received: by outflank-mailman (input) for mailman id 696862;
 Fri, 22 Mar 2024 12:52:25 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rneNl-0003bC-Cm
 for xen-devel@lists.xenproject.org; Fri, 22 Mar 2024 12:52:25 +0000
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com
 [2a00:1450:4864:20::22c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 071fdad1-e84b-11ee-afe0-a90da7624cb6;
 Fri, 22 Mar 2024 13:52:23 +0100 (CET)
Received: by mail-lj1-x22c.google.com with SMTP id
 38308e7fff4ca-2d68cf90ec4so34933151fa.1
 for ; Fri, 22 Mar 2024 05:52:23 -0700 (PDT)
Received: from [192.168.206.239] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 m12-20020a2eb6cc000000b002d51e0b73aesm325287ljo.25.2024.03.22.05.52.22
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 22 Mar 2024 05:52:22 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 071fdad1-e84b-11ee-afe0-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1711111943; x=1711716743; darn=lists.xenproject.org;
        h=mime-version:user-agent:content-transfer-encoding:references
         :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject
         :date:message-id:reply-to;
        bh=2AjX52arJOb3qX7Zkuo3O90zxeaE8rnXkhEP3gEk3SA=;
        b=SytTFkaVjI46NlfIiGz5UtrHDPUVvmrlOQ088X021GoxaySI9lHuiOH2MSMsgk7rcC
         4mBOmSwN8+ZLpNxvd+ltCxda9eey+PAb/0cm0XV4RxoyzIh253ZhuqSJQPCu6bh1rmuY
         bWX7tQrgXriC2MQgN7FaVSxCHSKm7KWG9DOTYVnDUwYdfjLgZckgjot8gg/WI8ppe9lT
         UcFHhsbsjtcZcfnYp33ivE/yAGDMKvvY+oUiNjySjqyyvGu1JASfPBlwnbth6l4jpI4G
         wXefLQzF8kWxZzJzL1R6FuK1X/2JGIz5EnthjFZQS2WmEpsoxw3fkslCMmQxHXQY+/tk
         D4zA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711111943; x=1711716743;
        h=mime-version:user-agent:content-transfer-encoding:references
         :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=2AjX52arJOb3qX7Zkuo3O90zxeaE8rnXkhEP3gEk3SA=;
        b=QhjZisGugfk0fMQdiDjwtCgae1iTqKVxfXYqRxvp7cCv0D4C6QpTAnYJc23106f57S
         6DWlGuyyKNlF1HKJRG1jPf8ykYcKh+X8/UvrZuCX7b8RodMvYmW0dEdp3gWWIpB0/Ht4
         MqSemw8HmvH1TnccOMzWtwGlkMPg9ndeahaN6zW/cWAk47Rc9eoPFZRp7A09VKjbvOhj
         heHwna2CUYvii9JpJ9am6u0Fuj/2UkIIGJ8y4Jv7yGoWAmmoilw3cMbsE7scnitplXx5
         zoLcvApELGnOA4PGxpmXrgvt6kK2hAPzjfd9Hub7X1Wfo08buNZyV9OjZ5OZe8YAIrfS
         J1Ww==
X-Forwarded-Encrypted: i=1; AJvYcCXtHhFieRLHbHnUlg/DcBFEbgYmfmFcSYGwKB3JAX56sdNsy4VODrzk+WibLwFnpETrBebJlhgGzoXl/8jwBZ2SI7JGQb6iHBk/ux0tDTE=
X-Gm-Message-State: AOJu0YyWDcxcwr63x4ZRqTofYhMMh4Miyonj8rQL6N2Yu1MZa6pKhgR2
	27z4MDNHUC2euC8GgNOXt4Y4lkUQIctXnXHV46jMre3F63GqtGSk
X-Google-Smtp-Source: AGHT+IFR/e/zL9q1swEqQsfD0Vwspax/xfSJIUfC6vLnBVzgkS8LeV4UYjCsfyCegIVZ2YGTpL7XIg==
X-Received: by 2002:a05:651c:1043:b0:2d4:2ef1:ed83 with SMTP id x3-20020a05651c104300b002d42ef1ed83mr1573346ljm.9.1711111942776;
        Fri, 22 Mar 2024 05:52:22 -0700 (PDT)
Message-ID: <00fde5befebeedcddd2e3d04cc9b00fddc00fc3b.camel@gmail.com>
Subject: Re: [PATCH v6 08/20] xen/riscv: introduce cmpxchg.h
From: Oleksii 
To: Jan Beulich 
Cc: Alistair Francis , Bob Eshleman
 , Connor Davis , Andrew
 Cooper , George Dunlap
 ,  Julien Grall , Stefano
 Stabellini , Wei Liu , 
 xen-devel@lists.xenproject.org
Date: Fri, 22 Mar 2024 13:52:21 +0100
In-Reply-To: 
References: 
	 
	 <6f73368c-ea73-4d86-a6a1-8f9784c4b01f@suse.com>
	 
	 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.50.2 (3.50.2-1.fc39) 
MIME-Version: 1.0

On Fri, 2024-03-22 at 11:42 +0100, Jan Beulich wrote:
> On 22.03.2024 11:32, Oleksii wrote:
> > On Thu, 2024-03-21 at 13:07 +0100, Jan Beulich wrote:
> > > On 15.03.2024 19:06, Oleksii Kurochko wrote:
> > > > The header was taken from Linux kernl 6.4.0-rc1.
> > > >=20
> > > > Addionally, were updated:
> > > > * add emulation of {cmp}xchg for 1/2 byte types using 32-bit
> > > > atomic
> > > > =C2=A0 access.
> > > > * replace tabs with spaces
> > > > * replace __* variale with *__
> > > > * introduce generic version of xchg_* and cmpxchg_*.
> > > > * drop {cmp}xchg{release,relaxed,acquire} as Xen doesn't use
> > > > them
> > >=20
> > > With this, ...
> > >=20
> > > > * drop barries and use instruction suffixices instead ( .aq,
> > > > .rl,
> > > > .aqrl )
> > > >=20
> > > > Implementation of 4- and 8-byte cases were updated according to
> > > > the
> > > > spec:
> > > > ```
> > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 ....
> > > > Linux Construct=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RVW=
MO AMO Mapping
> > > > atomic  relaxed=C2=A0=C2=A0=C2=A0=C2=A0 amo.{w|d}
> > > > atomic  acquire=C2=A0=C2=A0=C2=A0=C2=A0 amo.{w|d}.aq
> > > > atomic  release=C2=A0=C2=A0=C2=A0=C2=A0 amo.{w|d}.rl
> > > > atomic =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 amo.{w|d}.aqrl
> > > > Linux Construct=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RVW=
MO LR/SC Mapping
> > > > atomic  relaxed=C2=A0=C2=A0=C2=A0=C2=A0 loop: lr.{w|d}; ; s=
c.{w|d}; bnez
> > > > loop
> > > > atomic  acquire=C2=A0=C2=A0=C2=A0=C2=A0 loop: lr.{w|d}.aq; =
; sc.{w|d}; bnez
> > > > loop
> > > > atomic  release=C2=A0=C2=A0=C2=A0=C2=A0 loop: lr.{w|d}; ; s=
c.{w|d}.aqrl=E2=88=97 ;
> > > > bnez
> > > > loop OR
> > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 fe=
nce.tso; loop: lr.{w|d}; ;
> > > > sc.{w|d}=E2=88=97
> > > > ; bnez loop
> > > > atomic =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 loop: lr.{w|d}.aq; ; sc.{w|d}.aqrl;
> > > > bnez loop
> > > >=20
> > > > Table A.5: Mappings from Linux memory primitives to RISC-V
> > > > primitives
> > > >=20
> > > > ```
> > >=20
> > > ... I consider quoting this table in full, without any further
> > > remarks, as
> > > confusing: Three of the lines each are inapplicable now, aiui.
> > I'll shorten the table then.
> >=20
> > >=20
> > > Further what are the two * telling us? Quite likely they aren't
> > > there
> > > just
> > > accidentally.
> > >=20
> > > Finally, why sc.{w|d}.aqrl when in principle one would expect
> > > just
> > > sc.{w|d}.rl?
> > Because according to the last line of table A.5:
> > =C2=A0=C2=A0=C2=A0 atomic =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 loop: lr.{w|d}.aq; ; sc.{w|d}.aqrl;
> > Here it is used sc.{w|d}.aqrl form, so I decided to stick to the
> > what
> > is mentioned in the table.
>=20
> I understand it's mentioned that way in the table. But it being that
> way
> is not explained anywhere. Hence my "Why?"
>=20
> > > > +=C2=A0=C2=A0=C2=A0 __typeof__(*(ptr)) old__ =3D (__typeof__(*(ptr)=
))(old); \
> > > > +=C2=A0=C2=A0=C2=A0 __typeof__(*(ptr)) new__ =3D (__typeof__(*(ptr)=
))(new); \
> > >=20
> > > The casts aren't very nice to have here; I take they're needed
> > > for
> > > cmpxchg_ptr() to compile?
> > Not really, I have not faced an compilation issue.
> > The reason why it was added is that lr instruction places the sign-
> > extended value in destination register, but if not to do cast value
> > for
> > old and new were generated without sign extension, so, for example:
> > =C2=A0=C2=A0 u32=3D 0xbbbbbbbb;
> > =C2=A0=C2=A0 cmpxchg(&u32, 0xbbbbbbbb, 0xCCCCCCCC), u32);
> > Will fail because after:
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "0: lr" lr_sfx " %0, %2\n"=20
> > in %0 we will have 0xFFFFFFFFBBBBBBBB, but in %3 we will have
> > 0xBBBBBBBB, so
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 bne=C2=A0 %0, %z3, 1f\n"
> > %0 and %3 are always inequal in case when the most significat bit
> > of
> > value read from %2 has 1.
>=20
> I'm afraid I don't follow: It's the type conversion you're after, but
> that would happen also with the casts omitted.
Yes, agree it would happen also with the casts omitted, and it was pure
luck that the compiler that with casts the compiler used an immediate
with the most significant bit =3D 1:
ffffffffc00397f0:       bbbbc7b7                lui     a5,0xbbbbc
ffffffffc00397f4:       bbb78793                add     a5,a5,-1093 #
ffffffffbbbbbbbb 
ffffffffc00397f8:       fef42623                sw      a5,-20(s0)
ffffffffc00397fc:       ccccd737                lui     a4,0xccccd
ffffffffc0039800:       ccc7071b                addw    a4,a4,-820 #
ffffffffcccccccc <__bss_end+0xcc7ff44>
ffffffffc0039804:       56fd                    li      a3,-1
ffffffffc0039806:       9281                    srl     a3,a3,0x20
ffffffffc0039808:       fec40513                add     a0,s0,-20
ffffffffc003980c:       140525af                lr.w.aq a1,(a0)
ffffffffc0039810:       00f59563                bne   =20
a1,a5,ffffffffc003981a 
ffffffffc0039814:       1ee5262f                sc.w.aqrl     =20
a2,a4,(a0)

I will update the code with the mask mentioned below to be sure that a5
has always correct value.

~ Oleksii

>=20
> > But now I realized that it would be better just to use a mask and
> > not
> > be dependent from compiler code generation, so it would be better
> > to in
> > the following way ( of course, the macros should be updated
> > accordingly
> > to remarks you give me ):
> > =C2=A0=C2=A0 #define __generic_cmpxchg(ptr, old, new, ret, lr_sfx,
> > sc_sfx)	\
> > =C2=A0=C2=A0=C2=A0 ({ \
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 register unsigned int rc; \
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 unsigned long mask =3D GENMASK(((s=
izeof(*(ptr))) *
> > BITS_PER_BYTE)
> > =C2=A0=C2=A0 - 1, 0); \
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 asm volatile( \
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "0: lr" lr=
_sfx " %0, %2\n" \
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "=C2=A0=C2=
=A0 and=C2=A0 %0, %0, %z[mask]\n" \
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "=C2=A0=C2=
=A0 bne=C2=A0 %0, %z3, 1f\n" \
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "=C2=A0=C2=
=A0 sc" sc_sfx " %1, %z4, %2\n" \
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "=C2=A0=C2=
=A0 bnez %1, 0b\n" \
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "1:\n" \
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : "=3D&r" =
(ret), "=3D&r" (rc), "+A" (*ptr) \
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : "rJ" (ol=
d), "rJ" (new), [mask] "rJ" (mask)=C2=A0 \
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : "memory"=
); \
> > =C2=A0=C2=A0=C2=A0 })
>=20
> It'll be up to you whether to switch to such an alternative.
>=20
> Jan



From xen-devel-bounces@lists.xenproject.org Fri Mar 22 12:55:15 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Mar 2024 12:55:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696864.1088054 (Exim 4.92)
	(envelope-from )
	id 1rneQU-00048t-78; Fri, 22 Mar 2024 12:55:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696864.1088054; Fri, 22 Mar 2024 12:55:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rneQU-00048m-3i; Fri, 22 Mar 2024 12:55:14 +0000
Received: by outflank-mailman (input) for mailman id 696864;
 Fri, 22 Mar 2024 12:55:12 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rneQS-00048g-P0
 for xen-devel@lists.xenproject.org; Fri, 22 Mar 2024 12:55:12 +0000
Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com
 [2a00:1450:4864:20::12b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6b6cbc2f-e84b-11ee-afe0-a90da7624cb6;
 Fri, 22 Mar 2024 13:55:11 +0100 (CET)
Received: by mail-lf1-x12b.google.com with SMTP id
 2adb3069b0e04-513e6777af4so3870607e87.2
 for ; Fri, 22 Mar 2024 05:55:11 -0700 (PDT)
Received: from [192.168.206.239] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 j5-20020a05651231c500b005139cc8eac0sm341449lfe.106.2024.03.22.05.55.10
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 22 Mar 2024 05:55:10 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6b6cbc2f-e84b-11ee-afe0-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1711112111; x=1711716911; darn=lists.xenproject.org;
        h=mime-version:user-agent:content-transfer-encoding:references
         :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject
         :date:message-id:reply-to;
        bh=WTJEqnKqXXDTO52MW7q91FCQbF34RdBsK1V7FUEPR64=;
        b=DGleBpfcfspwN8cGwyTU2n468riM2UgZEljHT1XlUF35DNmKMg55PisMkXOVnMaPEm
         GUdm//7hb9JT2NTHGw1bROlmFJzTjA90RIJPDWI4LHGYDmVcnJF9nltLkj/fu3KV4bkG
         HBwgvC7v6AFQeiXQMoIkZx2G+X8EBUkaxv4sYYHAkUmsddFDRxEhbQrvgWA/NOfsbaBO
         p/rsHMwJU+pzjW7lRH33/UlNMeFbINfG1fYDQf/dPFKxLhIkLiGnUAvFBj1dPdoYQ4Ij
         kv2PObuATy2cKlT4emv22CxpOImuLe3YIF2STEZoxucp+P8LQT5DfrwttyRhmAyVHtD+
         88+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711112111; x=1711716911;
        h=mime-version:user-agent:content-transfer-encoding:references
         :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=WTJEqnKqXXDTO52MW7q91FCQbF34RdBsK1V7FUEPR64=;
        b=VQQoK6Vy5WxpeBsndWP8/PTcmLPfDg+5FVlcVZTnP1HYHvPYhhpUPnJXo+6jUyPEg4
         xDuapCRYyIeoVylaPJw8/93SRVlkvHnSygR9pl96p3mmU5cIV8E72/fxrKBTL9244EuJ
         5jnRpmEZx8W+WsyR31UBUgSLxEqu4oPQSZigwNytbrXHL51GZgnAsNbciLFAnaKfUGxo
         MczN55puswvbxn/780mR/R0Cc2d/74sGXPCErcFEuptJIODq4U6ivVzKivZe9ms707Gp
         aPflfh663cPyxF9csOK6a/g8D8h6NPMmpSIHxr604mAyTbvFqOZNVCn41eGza2y3XMGS
         663Q==
X-Forwarded-Encrypted: i=1; AJvYcCXbVOTllB29a4IovjwPnoii2iegHnpnXoP4705LuKPi3CKTLhDvxgtl7H5lH9dvDptzKbKQgnVPIDwb2N8TC53GQU9HaAdnFTfxbH7rDOg=
X-Gm-Message-State: AOJu0YwaLKK1UgxCvz9ui5ozhkBvL7lcJk7Hb+4PS0PVLpgUq/UCLI99
	JysA8chdWld9Qix0AOSJ08sxtwBK9+CvvJP2A2UoJGfy7//Tf7sP
X-Google-Smtp-Source: AGHT+IHMY7YtG+6STD16si7FERrV+f+Z53pS02/u9lq7fTSZLlmjqHjQOy8b1u8wAUmeQixS46QTgw==
X-Received: by 2002:ac2:5214:0:b0:513:c50d:db59 with SMTP id a20-20020ac25214000000b00513c50ddb59mr1888190lfl.15.1711112111232;
        Fri, 22 Mar 2024 05:55:11 -0700 (PDT)
Message-ID: 
Subject: Re: [PATCH v6 09/20] xen/riscv: introduce io.h
From: Oleksii 
To: Jan Beulich 
Cc: Alistair Francis , Bob Eshleman
 , Connor Davis , Andrew
 Cooper , George Dunlap
 ,  Julien Grall , Stefano
 Stabellini , Wei Liu , 
 xen-devel@lists.xenproject.org
Date: Fri, 22 Mar 2024 13:55:10 +0100
In-Reply-To: <9b40aeeb-ca7a-47c0-acde-407631ae9db7@suse.com>
References: 
	 
	 <49dd40b6-4558-4e0c-b6ab-eee5b814dd8d@suse.com>
	 <2a2779011db8ba6db04e8d2e4355479b50e48e01.camel@gmail.com>
	 <9b40aeeb-ca7a-47c0-acde-407631ae9db7@suse.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.50.2 (3.50.2-1.fc39) 
MIME-Version: 1.0

On Fri, 2024-03-22 at 12:36 +0100, Jan Beulich wrote:
> On 22.03.2024 12:02, Oleksii wrote:
> > On Thu, 2024-03-21 at 13:27 +0100, Jan Beulich wrote:
> > > On 15.03.2024 19:06, Oleksii Kurochko wrote:
> > > > --- /dev/null
> > > > +++ b/xen/arch/riscv/include/asm/io.h
> > > > @@ -0,0 +1,167 @@
> > > > +/* SPDX-License-Identifier: GPL-2.0-only */
> > > > +/*
> > > > + *=C2=A0 The header taken form Linux 6.4.0-rc1 and is based on
> > > > + *=C2=A0 arch/riscv/include/asm/mmio.h with the following changes:
> > > > + *=C2=A0=C2=A0 - drop forcing of endianess for read*(), write*()
> > > > functions
> > > > as
> > > > + *=C2=A0=C2=A0=C2=A0=C2=A0 no matter what CPU endianness, what end=
ianness a
> > > > particular
> > > > device
> > > > + *=C2=A0=C2=A0=C2=A0=C2=A0 (and hence its MMIO region(s)) is using=
 is entirely
> > > > independent.
> > > > + *=C2=A0=C2=A0=C2=A0=C2=A0 Hence conversion, where necessary, need=
s to occur at a
> > > > layer up.
> > > > + *=C2=A0=C2=A0=C2=A0=C2=A0 Another one reason to drop endianess co=
nversion is:
> > > > + *=C2=A0=C2=A0=C2=A0=C2=A0
> > > > https://patchwork.kernel.org/project/linux-riscv/patch/201904111156=
23.5749-3-hch@lst.de/
> > > > + *=C2=A0=C2=A0=C2=A0=C2=A0 One of the answers of the author of the=
 commit:
> > > > + *=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 And we don't know if Linux =
will be around if that
> > > > ever
> > > > changes.
> > > > + *=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The point is:
> > > > + *=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 a) the current RISC-V=
 spec is LE only
> > > > + *=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 b) the current linux =
port is LE only except for this
> > > > little bit
> > > > + *=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 There is no point in leavin=
g just this bitrotting
> > > > code
> > > > around.=C2=A0 It
> > > > + *=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 just confuses developers, (=
very very slightly) slows
> > > > down
> > > > compiles
> > > > + *=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and will bitrot.=C2=A0 It also wo=
n't be any significant
> > > > help to
> > > > a future
> > > > + *=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 developer down the road doi=
ng a hypothetical BE RISC-
> > > > V
> > > > Linux port.
> > > > + *=C2=A0=C2=A0 - drop unused argument of __io_ar() macros.
> > > > + *=C2=A0=C2=A0 - drop "#define _raw_{read,write}{b,w,l,d,q}
> > > > _raw_{read,write}{b,w,l,d,q}"
> > >=20
> > > In the commit message I'm not worried as much, but at least here
> > > the
> > > odd mention
> > > of d as suffixes would better be purged.
> > Probably, I use incorrect words, but what I meant that it was
> > dropped:
> > =C2=A0=C2=A0 #define _raw_{read,write}{b,w,l,d,q}
> > _raw_{read,write}{b,w,l,d,q}
> > before declaration/definition of inline functions (
> > __raw_{read,write}{b,w,l,d,q} ).
>=20
> But where did you find a raw_readd() or raw_writed() (with no matter
> how
> many leading underscores)?
Oh, {d} options didn't exist. Missed that, wrote it automatically.
Thanks I'll update the commit message and the header comment.

~ Oleksii


From xen-devel-bounces@lists.xenproject.org Fri Mar 22 13:14:51 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Mar 2024 13:14:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696872.1088065 (Exim 4.92)
	(envelope-from )
	id 1rnejI-00083k-Os; Fri, 22 Mar 2024 13:14:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696872.1088065; Fri, 22 Mar 2024 13:14:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnejI-00083d-M8; Fri, 22 Mar 2024 13:14:40 +0000
Received: by outflank-mailman (input) for mailman id 696872;
 Fri, 22 Mar 2024 13:14:39 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1rnejH-00083W-Fz
 for xen-devel@lists.xenproject.org; Fri, 22 Mar 2024 13:14:39 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnejF-0003L4-AQ; Fri, 22 Mar 2024 13:14:37 +0000
Received: from gw1.octic.net ([88.97.20.152] helo=[10.0.1.240])
 by xenbits.xenproject.org with esmtpsa
 (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92)
 (envelope-from )
 id 1rnejE-0005r3-Vr; Fri, 22 Mar 2024 13:14:37 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=jMaKi0n4yIK1PcStwAtuO10QNCGMBlt76ynXjpkPTl4=; b=4emIvnmvk2/dnhDcjDzGiXCd9X
	bdeMcsgMOmwrYlPCtX40fPmFzuQDXdfMLfl/TAbkrR3n/iyzcZuYn2pC42ufOO4Sd+jTyjftQe2Q9
	4YzAZBt57X9U3zjpAQeJhWIIV5w1oOnkPwru1CZy6I/WO1LX86ddoL54w09nAivtLimU=;
Message-ID: <1afd8f2a-7a60-435c-8b60-21721e2e8a44@xen.org>
Date: Fri, 22 Mar 2024 13:14:35 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 1/9] EFI: Introduce inline stub for efi_enabled on !X86
 && !ARM
Content-Language: en-GB
To: Jan Beulich ,
 Shawn Anastasio 
Cc: tpearson@raptorengineering.com, Andrew Cooper
 , George Dunlap ,
 Stefano Stabellini , Wei Liu ,
 xen-devel@lists.xenproject.org
References: 
 <39069a589f9c4dc0db9b01b7412c1a99bea55f37.1710443965.git.sanastasio@raptorengineering.com>
 <3a98757d-998e-4731-a508-5e7e1fc5aef2@suse.com>
From: Julien Grall 
In-Reply-To: <3a98757d-998e-4731-a508-5e7e1fc5aef2@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Jan,

On 22/03/2024 08:01, Jan Beulich wrote:
> On 14.03.2024 23:15, Shawn Anastasio wrote:
>> --- a/xen/include/xen/efi.h
>> +++ b/xen/include/xen/efi.h
>> @@ -31,7 +31,15 @@ union compat_pf_efi_info;
>>   struct xenpf_efi_runtime_call;
>>   struct compat_pf_efi_runtime_call;
>>   
>> +#if defined(CONFIG_X86) || defined(CONFIG_ARM)
>>   bool efi_enabled(unsigned int feature);
>> +#else
>> +static inline bool efi_enabled(unsigned int feature)
>> +{
>> +    return false;
>> +}
>> +#endif
> 
> While fine as is for now, surely Arm32 could benefit from the inline stub,
> too.

At least for now, Arm32 provides efi_enabled(). It would be possible to 
rework, but I think this should be left in a follow-up.

Also, ideally, we would have a common CONFIG_EFI (rather than 
CONFIG_ARM_EFI).

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Fri Mar 22 13:15:08 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Mar 2024 13:15:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696873.1088075 (Exim 4.92)
	(envelope-from )
	id 1rnejj-0008S3-VT; Fri, 22 Mar 2024 13:15:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696873.1088075; Fri, 22 Mar 2024 13:15:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnejj-0008Rw-Sz; Fri, 22 Mar 2024 13:15:07 +0000
Received: by outflank-mailman (input) for mailman id 696873;
 Fri, 22 Mar 2024 13:15:06 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1rneji-0008Rk-OE
 for xen-devel@lists.xenproject.org; Fri, 22 Mar 2024 13:15:06 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnejd-0003Lu-DJ; Fri, 22 Mar 2024 13:15:01 +0000
Received: from gw1.octic.net ([88.97.20.152] helo=[10.0.1.240])
 by xenbits.xenproject.org with esmtpsa
 (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92)
 (envelope-from )
 id 1rnejd-0005r3-85; Fri, 22 Mar 2024 13:15:01 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=C+gwDwhrEsv0KyU6I6tUWQNLG/3jx3IW5RAsB6mKI2g=; b=QMIYBWhH6UPUQvhD+UKiRkZkdB
	dirM+wjJSVDuYC7iewngmzO/Jarg8g4v184VROa6qulyqUbiwTACiuh0FQC7laziIHC1E4VaT7Yip
	ijlbzrSZuL9juVTE2Kk8W6cEEre6tGXwwSP66fn8eluJhVvOGU12ykPaNGJJygUsoftc=;
Message-ID: <5cd33075-3965-4c03-add0-ffbc5a994920@xen.org>
Date: Fri, 22 Mar 2024 13:14:59 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 5/9] xen/device-tree: Move Arm's setup.c bootinfo
 functions to common
Content-Language: en-GB
To: Jan Beulich 
Cc: tpearson@raptorengineering.com, Andrew Cooper
 , George Dunlap ,
 Stefano Stabellini , Wei Liu ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 "Daniel P. Smith" ,
 Shawn Anastasio ,
 xen-devel@lists.xenproject.org
References: 
 <039524d4157dddb2faf6887739a727f6e993b53f.1710443965.git.sanastasio@raptorengineering.com>
 <19c4d0c2-c69c-4310-bf02-28d3894f8006@xen.org>
 <4268b0de-e959-42aa-bc5c-0c48a359ea1d@suse.com>
From: Julien Grall 
In-Reply-To: <4268b0de-e959-42aa-bc5c-0c48a359ea1d@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Jan,

On 22/03/2024 07:55, Jan Beulich wrote:
> On 21.03.2024 18:47, Julien Grall wrote:
>> On 14/03/2024 22:15, Shawn Anastasio wrote:
>>> Arm's setup.c contains a collection of functions for parsing memory map
>>> and other boot information from a device tree. Since these routines are
>>> generally useful on any architecture that supports device tree booting,
>>> move them into xen/common/device-tree.
>>>
>>> Suggested-by: Julien Grall 
>>> Signed-off-by: Shawn Anastasio 
>>> ---
>>>    MAINTAINERS                       |   1 +
>>>    xen/arch/arm/setup.c              | 419 --------------------------
>>>    xen/common/Makefile               |   1 +
>>>    xen/common/device-tree/Makefile   |   1 +
>>>    xen/common/device-tree/bootinfo.c | 469 ++++++++++++++++++++++++++++++
>>
>> The new bootinfo.c is exported quite a few functions. Please introduce
>> an generic header with the associated functions/structures.
> 
> By "generic" you don't mean a header in asm-generic/, do you?

Right. I meant include/xen/*.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Fri Mar 22 13:39:49 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Mar 2024 13:39:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696883.1088085 (Exim 4.92)
	(envelope-from )
	id 1rnf7S-0004Pc-Pk; Fri, 22 Mar 2024 13:39:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696883.1088085; Fri, 22 Mar 2024 13:39:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnf7S-0004PV-Mv; Fri, 22 Mar 2024 13:39:38 +0000
Received: by outflank-mailman (input) for mailman id 696883;
 Fri, 22 Mar 2024 13:39:38 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rnf7R-0004PP-Qz
 for xen-devel@lists.xenproject.org; Fri, 22 Mar 2024 13:39:37 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on20601.outbound.protection.outlook.com
 [2a01:111:f403:2416::601])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9ed0fc9a-e851-11ee-afe0-a90da7624cb6;
 Fri, 22 Mar 2024 14:39:36 +0100 (CET)
Received: from SJ0PR03CA0043.namprd03.prod.outlook.com (2603:10b6:a03:33e::18)
 by SN7PR12MB6716.namprd12.prod.outlook.com (2603:10b6:806:270::20)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.28; Fri, 22 Mar
 2024 13:39:31 +0000
Received: from MWH0EPF000989E6.namprd02.prod.outlook.com
 (2603:10b6:a03:33e:cafe::25) by SJ0PR03CA0043.outlook.office365.com
 (2603:10b6:a03:33e::18) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.13 via Frontend
 Transport; Fri, 22 Mar 2024 13:39:30 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 MWH0EPF000989E6.mail.protection.outlook.com (10.167.241.133) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Fri, 22 Mar 2024 13:39:29 +0000
Received: from SATLEXMB08.amd.com (10.181.40.132) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Fri, 22 Mar
 2024 08:39:28 -0500
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB08.amd.com
 (10.181.40.132) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Fri, 22 Mar
 2024 06:39:28 -0700
Received: from [172.22.164.0] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Fri, 22 Mar 2024 08:39:27 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9ed0fc9a-e851-11ee-afe0-a90da7624cb6
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=FD4dzQOFCViWizcL+DsaS8o+PnbQ9XvFB1grJQbrPBYEP4EX23+6K6AgnTvqEI/Z4L5QDPQ9Sg7V46WG5i598YuvFJxbrIYbPCmt+WBvaNQv5cxbQXfjSIb67FAI9ld9PBRRwCpT5XzMnvDFZ1rgwYcZhl2bbAZO4rbB1wdBDcX0oh770Ojy1MtDP1NuQFFEXgsQS9rgE2mNg3UBWebtEpUkPDzSEsV/Xav3M77wzp3Yy/Mil7ofj8MBFofyxW4RCOx43DXdwD21yEZYuj9dMacmGRbJ/RV6FUurWzx47Z5IXcObqD6MygKbGytoUInDVYKxAIm8D9Ww5kZzRkVvmg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=0eoeqtHK5q+bZJQf+Nm+h9g5s48iuQ5hpi1d5iFOztc=;
 b=I8QzYgMZ7Yx0a7o5KUy7GbbvoVvd9u60/QsrMrTVQtN4d2aiFd57eMx5m0C8+bQ3o/qmTFN+27CQ8h8NPAZvYqM1Q5pVU017VLQK1rw96sN3cqYi/+lpCHPNadtwT7dGBcFc1tPQCR/nRWKz1Mjay8ulz0s4zlJ11X7nsFu5U+sLYF6PVPZbe4CiZhMUHIma1ucpY8qSnQvxEeI+vY5xbRQeLdwUKcQCK0BlMHmT6Ru+3nbs80D/XT09+pjSwacVcfBYrFQLVBV4MxVQoJKjbXnUtqKMlVJYNmPbOkWVSX/xpQiRwtrb/UPWAKPKtI0EkIGGgc8Zm6GsD7lr0/9V+A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=0eoeqtHK5q+bZJQf+Nm+h9g5s48iuQ5hpi1d5iFOztc=;
 b=QVVn8fFnh/s7Jt5EyfD2DnvKyJfnfPaShyBHDtYQ9FQYqj75LbSDvg8wFog13VzgafaJmsbzQfAPZhzyQXZn9g7ThWanTvGW7L6Hv/OTFQYIH5idztoS9q8/2yLb6PV3zJUWMwd8In7ne8b149gsbMJV4KLS0UasJw/Hi4Zb6dc=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Message-ID: <9060e4b9-93d1-45c2-9785-ccb4b3c3e4e2@amd.com>
Date: Fri, 22 Mar 2024 09:39:26 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] avoid UB in guest handle arithmetic
To: Jan Beulich , "xen-devel@lists.xenproject.org"
	
CC: Andrew Cooper , George Dunlap
	, Julien Grall , Stefano Stabellini
	, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
	
References: <227fbeda-1690-4158-8404-53b4236c0235@suse.com>
Content-Language: en-US
From: Stewart Hildebrand 
In-Reply-To: <227fbeda-1690-4158-8404-53b4236c0235@suse.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: MWH0EPF000989E6:EE_|SN7PR12MB6716:EE_
X-MS-Office365-Filtering-Correlation-Id: 3ebfb507-c53e-49bc-3242-08dc4a758015
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	DbUj4GPmZE6fCjCQHN72GXze8MQMaGpkW+KIA+pV+7Ena6dhSfRnFESs4LSscaofLl0r/Ir03S745E18jrtfdyDj9P9yB9fENwhMAyq4UPsZO/cS+tMRg9XIZUEPkaf4ob+sRqHd1ZJdljcPpYVSC5Aq6nfT0jsoLYADtwyH40ryiCAqP8AUn5n1XVvf09W4k1+koJ++tiJbMBLOpKVzQfOYgoHavXWvezEIUNHabROnkhqosd4wZfRuycANHEcSdZbqZkysdcp74gj0z1/TurNZtKPm7gi0gwFJjdF6WLzzOxdPGu4to1ZPane6hTyAdVfUX/HP8opb94x6hAkyIM1Vhj9OMxxhw9nLtspMtM35N+21d7+Pvnx/A4n6K54ZJZyNVNMk6PMTiauDyA3xZAI/rNT9MhQ7lvd7snLdBw3R/X3A1hlX9GZmnz1onUhh2Bme+RVRYcV39HjoMPzbjyNDH4UaqQemc7LDXQGpd4xPGN5P7bK33SRgNMHdzNusWaIW1+y5RpU4ne3G0DU/MAVmQU8mGI2tFkT4ZJp7m0qSmaBNtQXBS2rsaqXiJ4lZWiLAGNqHyljPB++nNQwBVaDYqfLZpgFOvm99l+OGixP0yX1Qx4XOubNwaooJ1TWSNolKWBk7bRq8JezmWv51PXnVj19DVA+78ZlH7cY7+LAQci7FyvQnssLloVZzJ+zz6tZm1mTuhiZGhF4nLE0lCmPW8DwALAfTRoxeU1VxkbtXybOiGWwT3YSEfGrMplF+
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(1800799015)(376005)(36860700004)(82310400014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Mar 2024 13:39:29.6675
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 3ebfb507-c53e-49bc-3242-08dc4a758015
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	MWH0EPF000989E6.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB6716

On 3/19/24 09:26, Jan Beulich wrote:
> At least XENMEM_memory_exchange can have huge values passed in the
> nr_extents and nr_exchanged fields. Adding such values to pointers can
> overflow, resulting in UB. Cast respective pointers to "unsigned long"

Why not uintptr_t?



From xen-devel-bounces@lists.xenproject.org Fri Mar 22 13:42:08 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Mar 2024 13:42:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696885.1088095 (Exim 4.92)
	(envelope-from )
	id 1rnf9i-0005uh-6i; Fri, 22 Mar 2024 13:41:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696885.1088095; Fri, 22 Mar 2024 13:41:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnf9i-0005ua-3H; Fri, 22 Mar 2024 13:41:58 +0000
Received: by outflank-mailman (input) for mailman id 696885;
 Fri, 22 Mar 2024 13:41:57 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnf9h-0005uS-Aj
 for xen-devel@lists.xenproject.org; Fri, 22 Mar 2024 13:41:57 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.133.124])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f1e03297-e851-11ee-a1ee-f123f15fe8a2;
 Fri, 22 Mar 2024 14:41:55 +0100 (CET)
Received: from mail-qt1-f198.google.com (mail-qt1-f198.google.com
 [209.85.160.198]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-76-knYgoxYHPT-1D277Ai0Gog-1; Fri, 22 Mar 2024 09:41:52 -0400
Received: by mail-qt1-f198.google.com with SMTP id
 d75a77b69052e-4311dd10102so7985991cf.0
 for ; Fri, 22 Mar 2024 06:41:52 -0700 (PDT)
Received: from x1n ([99.254.121.117]) by smtp.gmail.com with ESMTPSA id
 b16-20020ac844d0000000b00430b772f3dfsm869813qto.55.2024.03.22.06.41.50
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 22 Mar 2024 06:41:51 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f1e03297-e851-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1711114914;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references;
	bh=RJo7/irORUSfHBxyzyE4PWgRdMa4wnSQmwiLtA6ROhw=;
	b=LJmS/0bsUohjx0lR2PFruSgMaqDKzZqKUBhcNnEP4W3MqlMfRQfSMiV1V3roLDniXeCg1t
	A3ofJ+7gubJsvwlzYJlalXl44gTbLTk1z0YlI10aBAMnCsCc0elVOMHiFpZmImKDkhwECC
	cuPfrIIsXoK44Sc0mjHUzUL1QbjDK2g=
X-MC-Unique: knYgoxYHPT-1D277Ai0Gog-1
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711114912; x=1711719712;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=RJo7/irORUSfHBxyzyE4PWgRdMa4wnSQmwiLtA6ROhw=;
        b=rIWPWwtGUO6CnHbC+THccMWuL45RcvjJRoTBVWzkNzfuZBv7ivsAKXJfXsKv88l/GS
         IhATbgpRwKrBnQhtOiqnoBprCjfUavFn/rsuOv9sXYzAzEjb9hCUG4PlWzFB/bGcxmNK
         HM/+J8uYih43AARu23S8DN4qL5rTGAsoZ7moXt6aYK7MJK9WwFkTf3ez+9xkOiSF/52o
         7gjXKjYTpBMEyfSjJntItFmLnD8GVtBGLpKRFtNkUgxuTVrQQGd1fOTxv74XyTGtL7wJ
         1uxth8rz8kAe3aRqb/rDVRTpDI09bRPpub4LCUay8yrLqH741UU4pKbCRHi3e21ffHjW
         oVhA==
X-Forwarded-Encrypted: i=1; AJvYcCW/tmbLuScDr/RYr21VH/NVPxH010/cq7aNQ0K0mvJlKzJW1613WjTPLu4WvuDj+tSi8mwQuhur9urVvlicbm2RfGlAC3hU7GaZO4dIjJ4=
X-Gm-Message-State: AOJu0YwJiAvtoZZY7ktLtaumTOII867X8ZA8C6i0P+UuMr9qf+eW29Uk
	Ml/ANYehU34P/C6AzniVI9gus4in1IXktGi2wt7GvksPunJvbyabtV35tgYagUkamqjfAivohS4
	vbXkrk+eNEvsqfGnHpZFAOrficgRiTMEhBGhK8wigyP9S7vz827vVu4z3tOl0wka5
X-Received: by 2002:a05:622a:1828:b0:431:30cb:4fd2 with SMTP id t40-20020a05622a182800b0043130cb4fd2mr2022579qtc.0.1711114912081;
        Fri, 22 Mar 2024 06:41:52 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IF/0+yKyHflKpE6YElewzeWCB+HqYA1SbGgHWmnOQVycDPda2C/eX5ZaxeqW0tzatM+wiLZog==
X-Received: by 2002:a05:622a:1828:b0:431:30cb:4fd2 with SMTP id t40-20020a05622a182800b0043130cb4fd2mr2022539qtc.0.1711114911504;
        Fri, 22 Mar 2024 06:41:51 -0700 (PDT)
Date: Fri, 22 Mar 2024 09:41:49 -0400
From: Peter Xu 
To: Yong Huang 
Cc: =?utf-8?Q?C=C3=A9dric?= Le Goater ,
	qemu-devel@nongnu.org, Stefano Stabellini ,
	Anthony Perard ,
	Paul Durrant , Paolo Bonzini ,
	Richard Henderson ,
	Eduardo Habkost ,
	"Michael S. Tsirkin" ,
	Marcel Apfelbaum ,
	David Hildenbrand ,
	Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= ,
	Fabiano Rosas ,
	Alex Williamson ,
	Avihai Horon ,
	Markus Armbruster ,
	Prasad Pandit ,
	xen-devel@lists.xenproject.org,
	Hailiang Zhang 
Subject: Re: [PATCH for-9.1 v5 11/14] memory: Add Error** argument to the
 global_dirty_log routines
Message-ID: 
References: <20240320064911.545001-1-clg@redhat.com>
 <20240320064911.545001-12-clg@redhat.com>
 
 
MIME-Version: 1.0
In-Reply-To: 
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline

On Fri, Mar 22, 2024 at 09:55:18AM +0800, Yong Huang wrote:
> Indeed, for the GLOBAL_DIRTY_DIRTY_RATE and GLOBAL_DIRTY_LIMIT
> dirty tracking, they should handle the failure path of logging start.
> The work may be done once the current patchset is merged.

Thanks for confirming this, Yong.  I think I'll go ahead and queue it then.
It should be in the 1st migration pull for 9.1.  Thanks,

-- 
Peter Xu



From xen-devel-bounces@lists.xenproject.org Fri Mar 22 13:44:29 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Mar 2024 13:44:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696887.1088104 (Exim 4.92)
	(envelope-from )
	id 1rnfBy-0006UN-HK; Fri, 22 Mar 2024 13:44:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696887.1088104; Fri, 22 Mar 2024 13:44:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnfBy-0006UE-Ec; Fri, 22 Mar 2024 13:44:18 +0000
Received: by outflank-mailman (input) for mailman id 696887;
 Fri, 22 Mar 2024 13:44:17 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rnfBx-0006U8-Pk
 for xen-devel@lists.xenproject.org; Fri, 22 Mar 2024 13:44:17 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 467e83b4-e852-11ee-afe0-a90da7624cb6;
 Fri, 22 Mar 2024 14:44:16 +0100 (CET)
Received: from [192.168.1.9] (net-93-144-106-196.cust.dsl.teletu.it
 [93.144.106.196])
 by support.bugseng.com (Postfix) with ESMTPSA id 8001B4EE0742;
 Fri, 22 Mar 2024 14:44:15 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 467e83b4-e852-11ee-afe0-a90da7624cb6
Message-ID: <7b5bad43-88f2-4d91-abc4-6b527446cb4a@bugseng.com>
Date: Fri, 22 Mar 2024 14:44:14 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH v2 1/2] automation/eclair: add deviation for MISRA
 C:2012 Rule 17.1
To: Jan Beulich 
Cc: consulting@bugseng.com, sstabellini@kernel.org,
 Doug Goldstein , Andrew Cooper
 , George Dunlap ,
 Julien Grall , Wei Liu ,
 xen-devel@lists.xenproject.org
References: 
 
 <9c6f4afd-00af-41f0-86dc-4f4558cb739c@suse.com>
Content-Language: en-US
From: Simone Ballarin 
Organization: BUGSENG
In-Reply-To: <9c6f4afd-00af-41f0-86dc-4f4558cb739c@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 22/03/24 10:44, Jan Beulich wrote:
> On 22.03.2024 09:46, Simone Ballarin wrote:
>> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
>> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
>> @@ -382,6 +382,32 @@ explicit comment indicating the fallthrough intention is present."
>>   -config=MC3R1.R16.6,switch_clauses+={deliberate, "default(0)"}
>>   -doc_end
>>   
>> +#
>> +# Series 17.
>> +#
>> +
>> +-doc_begin="printf()-like functions are allowed to use the variadic features provided by stdarg.h."
>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(debugtrace_printk)&&kind(function))))"}
>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(dt_dprintk)&&kind(function))))"}
>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(printk)&&kind(function))))"}
>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(guest_printk)&&kind(function))))"}
>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(panic)&&kind(function))))"}
>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(dprintk)&&kind(function))))"}
>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(gdprintk)&&kind(function))))"}
>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(snprintf)&&kind(function))))"}
>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(scnprintf)&&kind(function))))"}
>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(xasprintf)&&kind(function))))"}
>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(mm_printk)&&kind(function))))"}
>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(dbgp_printk)&&kind(function))))"}
>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(elf_call_log_callback)&&kind(function))))"}
>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(vsnprintf)&&kind(function))))"}
>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(vscnprintf)&&kind(function))))"}
>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(xvasprintf)&&kind(function))))"}
>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(vprintk_common)&&kind(function))))"}
>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(guest_printk)&&kind(function))))"}
>> +-config=MC3R1.R17.1,macros+={hide , "^va_(arg|start|copy|end)$"}
>> +-doc_end
> 
> Repeating v1 comments which weren't addressed> 
> Is there a reason xyzprintk() are all listed individually? Surely if
> we'd introduce a new flavor, we'd want that excluded too.
> > {,g}dprintk() in neither of their incarnation use any of the va_*
> items listed. Why do they need mentioning here?
> 
> Jan

Sorry.

What do you mean with "xyzprintk()"? Maybe you mean a regex-based
deviation using ".*printk\(.*\)"?
That would unnecessarily deviate "{,g}dprintk()" as you said.

Moreover, to cover also "vprintk_common", we would instead need something like
"^.*printk.*\(.*\)$".

I'm fine in using "^.*printk.*\(.*\)$", I just preferred the individual
whitelisting to avoid unwanted exclusions.

P.S:
using regex I cannot match only the name, but I have to match
the entire signature.

-- 
Simone Ballarin, M.Sc.

Field Application Engineer, BUGSENG (https://bugseng.com)



From xen-devel-bounces@lists.xenproject.org Fri Mar 22 14:12:13 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Mar 2024 14:12:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696903.1088115 (Exim 4.92)
	(envelope-from )
	id 1rnfct-0003ZZ-L8; Fri, 22 Mar 2024 14:12:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696903.1088115; Fri, 22 Mar 2024 14:12:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnfct-0003ZS-Hz; Fri, 22 Mar 2024 14:12:07 +0000
Received: by outflank-mailman (input) for mailman id 696903;
 Fri, 22 Mar 2024 14:12:05 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnfcr-0003ZM-Rz
 for xen-devel@lists.xenproject.org; Fri, 22 Mar 2024 14:12:05 +0000
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com
 [2a00:1450:4864:20::62d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 283e4783-e856-11ee-a1ee-f123f15fe8a2;
 Fri, 22 Mar 2024 15:12:03 +0100 (CET)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-a47062136c0so272994566b.2
 for ; Fri, 22 Mar 2024 07:12:03 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ww9-20020a170907084900b00a4721dd8063sm1022951ejb.172.2024.03.22.07.12.01
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 22 Mar 2024 07:12:02 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 283e4783-e856-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711116723; x=1711721523; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=03iaJSx5gKNAx+dpX987/CTQrY1R8zCc7N+ZGoxeKY4=;
        b=PUyQEAMVdgqK0gaSgexC9X6CcAMMzjET0SkMdVyQJ50QTQ8DHOKcmVRbD30qkmKaCx
         PfU7/m5SbWLCmjHId40npBhiOdsYMQtZoz2U9NfqEDsOa1aupANi2VLudbkZQv9gtkjG
         ztJRL/cXydonykXg/yfMzUugApPmaN9iXvd/YGremqdqfHVLqjqR+LB1B3KVneMznQQJ
         odj2Ds+vKmH7GHKPU2QUKzKIvgiSzERCmZFJkrx5rWacEw4pDmLmWlCTzRvwqnIWKWWK
         1+LcABbp9Y0QrZ5Ph/jR51vjHlZMvz7O8aq+BuZspchd/LNRwHqy6acNvX8wFVks/6PD
         5aNw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711116723; x=1711721523;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=03iaJSx5gKNAx+dpX987/CTQrY1R8zCc7N+ZGoxeKY4=;
        b=TDKCTwdDK4RKzMuiOqBmnlpuluFdM6EsgVbXMnKW3+0o1lTmvlTOmEqcc+PTOVTmf8
         UFqKZgi32RRSKuu81ADG8IW2bNbDdzxQ/DmZ+Fb2umpVlqD510aKj78fwGc31T/SXXIH
         1/uUi8yxADX2bTtfBukiQ8eoOyDouyYFvgDIBNB72fcMYUviE68Jf87Z2hNIXLw9D1iJ
         +RuRq1vnYo2rIx8S8/icsp9v/1uvST0MuofQ5i2z+E4N4C2DjQybcclRi+hurM3tQ4mY
         xHHow0wdeh8braeBPz2vu5XNKkp75OVxkPfrARmNEf6JaaL0aGY+MDYOKwaVERI2F4Yl
         Mm4Q==
X-Forwarded-Encrypted: i=1; AJvYcCWEvCtcgBh21bmEmKt+x4BpDbYVAFYV9W6ZYFzGPJ+Q9AnMJERo5FrhLM2FFlI0n3unBbH3UYaiuOKkil+zKjoFy6TacNlahGZ7AYBVcKs=
X-Gm-Message-State: AOJu0Yxsu2C2Bna2cFBW3Qrvim15KBxV97lidyZjudSQw9kUescXTRRn
	b5oiQcqnPa4IXb0YR7Soo9l54o00xuXepBHX51VhhwkI/rRNiRT7fibnX97JHQ==
X-Google-Smtp-Source: AGHT+IFFMH6b7d7E+xFTz0eNYQsPZEiGPevAN5wAgSvZYQTgk+Pv/f788HjRzcgQnMCeDCQhA7XAKQ==
X-Received: by 2002:a17:906:2310:b0:a46:bd1d:d9c9 with SMTP id l16-20020a170906231000b00a46bd1dd9c9mr1837025eja.31.1711116723061;
        Fri, 22 Mar 2024 07:12:03 -0700 (PDT)
Message-ID: <60181473-501a-4f17-ac11-e1598ead8b29@suse.com>
Date: Fri, 22 Mar 2024 15:12:00 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH v2 1/2] automation/eclair: add deviation for MISRA
 C:2012 Rule 17.1
Content-Language: en-US
To: Simone Ballarin 
Cc: consulting@bugseng.com, sstabellini@kernel.org,
 Doug Goldstein , Andrew Cooper
 , George Dunlap ,
 Julien Grall , Wei Liu ,
 xen-devel@lists.xenproject.org
References: 
 
 <9c6f4afd-00af-41f0-86dc-4f4558cb739c@suse.com>
 <7b5bad43-88f2-4d91-abc4-6b527446cb4a@bugseng.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <7b5bad43-88f2-4d91-abc4-6b527446cb4a@bugseng.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 22.03.2024 14:44, Simone Ballarin wrote:
> On 22/03/24 10:44, Jan Beulich wrote:
>> On 22.03.2024 09:46, Simone Ballarin wrote:
>>> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
>>> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
>>> @@ -382,6 +382,32 @@ explicit comment indicating the fallthrough intention is present."
>>>   -config=MC3R1.R16.6,switch_clauses+={deliberate, "default(0)"}
>>>   -doc_end
>>>   
>>> +#
>>> +# Series 17.
>>> +#
>>> +
>>> +-doc_begin="printf()-like functions are allowed to use the variadic features provided by stdarg.h."
>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(debugtrace_printk)&&kind(function))))"}
>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(dt_dprintk)&&kind(function))))"}
>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(printk)&&kind(function))))"}
>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(guest_printk)&&kind(function))))"}
>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(panic)&&kind(function))))"}
>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(dprintk)&&kind(function))))"}
>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(gdprintk)&&kind(function))))"}
>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(snprintf)&&kind(function))))"}
>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(scnprintf)&&kind(function))))"}
>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(xasprintf)&&kind(function))))"}
>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(mm_printk)&&kind(function))))"}
>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(dbgp_printk)&&kind(function))))"}
>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(elf_call_log_callback)&&kind(function))))"}
>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(vsnprintf)&&kind(function))))"}
>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(vscnprintf)&&kind(function))))"}
>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(xvasprintf)&&kind(function))))"}
>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(vprintk_common)&&kind(function))))"}
>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(guest_printk)&&kind(function))))"}
>>> +-config=MC3R1.R17.1,macros+={hide , "^va_(arg|start|copy|end)$"}
>>> +-doc_end
>>
>> Repeating v1 comments which weren't addressed> 
>> Is there a reason xyzprintk() are all listed individually? Surely if
>> we'd introduce a new flavor, we'd want that excluded too.
>>> {,g}dprintk() in neither of their incarnation use any of the va_*
>> items listed. Why do they need mentioning here?
> 
> What do you mean with "xyzprintk()"? Maybe you mean a regex-based
> deviation using ".*printk\(.*\)"?

Regex or globbing, whatever is available.

> That would unnecessarily deviate "{,g}dprintk()" as you said.

Depends on how the regex would be written.

> Moreover, to cover also "vprintk_common", we would instead need something like
> "^.*printk.*\(.*\)$".

Or simply accept that such outliers need listing individually. That
would imo still be better than a dozen entries.

> I'm fine in using "^.*printk.*\(.*\)$", I just preferred the individual
> whitelisting to avoid unwanted exclusions.
> 
> P.S:
> using regex I cannot match only the name, but I have to match
> the entire signature.

Interesting. Is that a tool limitation?

Jan


From xen-devel-bounces@lists.xenproject.org Fri Mar 22 14:14:06 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Mar 2024 14:14:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696905.1088125 (Exim 4.92)
	(envelope-from )
	id 1rnfen-0004Ai-4A; Fri, 22 Mar 2024 14:14:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696905.1088125; Fri, 22 Mar 2024 14:14:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnfen-0004Ab-13; Fri, 22 Mar 2024 14:14:05 +0000
Received: by outflank-mailman (input) for mailman id 696905;
 Fri, 22 Mar 2024 14:14:04 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnfem-0004AV-JV
 for xen-devel@lists.xenproject.org; Fri, 22 Mar 2024 14:14:04 +0000
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com
 [2a00:1450:4864:20::531])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6fce26c3-e856-11ee-afe0-a90da7624cb6;
 Fri, 22 Mar 2024 15:14:03 +0100 (CET)
Received: by mail-ed1-x531.google.com with SMTP id
 4fb4d7f45d1cf-563bb51c36eso2625771a12.2
 for ; Fri, 22 Mar 2024 07:14:03 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 z9-20020a05640235c900b00568a08a9aacsm1056209edc.22.2024.03.22.07.14.02
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 22 Mar 2024 07:14:02 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6fce26c3-e856-11ee-afe0-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711116843; x=1711721643; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=tnOpRaRqYBEmpnvnxAAq6nYWwg9+xBBIuuGXIZdTkEo=;
        b=LpU5VtAamr79ecicGep3xJcMSD7B0fox+kz+TvOoB9g2X+faoz+AjZL99uDA31tdpl
         Z9iAmlxN7BmDxmOlNwm1pIM2ZQ7LVCV7afVNUQgfrlPTxWIZg/4W342i2g7FfqKtikZ8
         HUjbHS8/GW23Q8j59P9yFCTh5QChZyZT+bJ4xnErAntSYyqrKXoSR2PBRxpHWej9Erql
         iSjkEknxRgNhkvXOFxqi5NZ7cTOUklJgDpUxwJDzKjhaCk2I9u2DW4wc4e1/sp8/Mnc/
         +Oo6tGwH4j2UR+BBJhVipQ9HCUOd3BGu9M31idzn0BV0uoTryiOuAOEXgnBw9hK4Owe2
         H/Pw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711116843; x=1711721643;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=tnOpRaRqYBEmpnvnxAAq6nYWwg9+xBBIuuGXIZdTkEo=;
        b=anhSpM9moprUucqS6elyEp3HTU71t+od4CEaEYB3Xg0o3ZLjCaNP/IOOwE+QIDoFbQ
         /eOIMsNwi/kwn6tOxdW7pSXq8zTaIsenqpuYDnQmDelwGxy/hlclBLHhM5lmv82ls321
         B3Mg2LnoWU+k0SGWKBHsF26TkcIYfE8pLYyXXXrva4AsDgIz+Hzls4WGQtHSQp/MUuik
         ZobHkMrng7OvKQxK+lMyAa/H62qQxIzOsnNCDhK1yA3dbx4VFl0A6TZyFbODnE+d3ps9
         0txJMOQE7aeUIR+khSihHCMeUd7lG8/UuIMbbcUXIW5A5IS0XMjYl5r2v5bdSITJZ+YU
         bs5g==
X-Forwarded-Encrypted: i=1; AJvYcCXLahoiMU9WVAViOEs4BqpJVq3SfGKxdTitdanGOUQByW5Aosaduei/v9pD3DW560FjhE9r8eu7+2Kv7ZP2mN5J964U+jXjkUFG0PmS9zQ=
X-Gm-Message-State: AOJu0YzgVzpwtNPWjFWQccZdpaPnQ3jDLsRoI3beONsrlo8Fc5LpSbxg
	rOIHlqZdk/HrANcoiLPNBbr7MyfFjF0+uCSD4zn02Yh+SElgkp6R8Zc9O3tFo6nWefKKSrdTWgU
	=
X-Google-Smtp-Source: AGHT+IGtYfF+mctzASnH9u1/iYx7gVuei5hL0v8Abfy7mwDA8L58pNUy32B9BapD2H5/hkAR0WvLSg==
X-Received: by 2002:a50:a6d0:0:b0:56b:9162:8e6 with SMTP id f16-20020a50a6d0000000b0056b916208e6mr1763283edc.18.1711116843165;
        Fri, 22 Mar 2024 07:14:03 -0700 (PDT)
Message-ID: <15da6d51-ea4e-4459-8558-a6566091e3e7@suse.com>
Date: Fri, 22 Mar 2024 15:14:01 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] avoid UB in guest handle arithmetic
Content-Language: en-US
To: Stewart Hildebrand 
Cc: Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 "xen-devel@lists.xenproject.org" 
References: <227fbeda-1690-4158-8404-53b4236c0235@suse.com>
 <9060e4b9-93d1-45c2-9785-ccb4b3c3e4e2@amd.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <9060e4b9-93d1-45c2-9785-ccb4b3c3e4e2@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 22.03.2024 14:39, Stewart Hildebrand wrote:
> On 3/19/24 09:26, Jan Beulich wrote:
>> At least XENMEM_memory_exchange can have huge values passed in the
>> nr_extents and nr_exchanged fields. Adding such values to pointers can
>> overflow, resulting in UB. Cast respective pointers to "unsigned long"
> 
> Why not uintptr_t?

Because, like Linux, so far we've been using unsigned long in preference.
That might change ...

Jan


From xen-devel-bounces@lists.xenproject.org Fri Mar 22 14:24:33 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Mar 2024 14:24:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696909.1088135 (Exim 4.92)
	(envelope-from )
	id 1rnfom-0006rC-V8; Fri, 22 Mar 2024 14:24:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696909.1088135; Fri, 22 Mar 2024 14:24:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnfom-0006r5-SV; Fri, 22 Mar 2024 14:24:24 +0000
Received: by outflank-mailman (input) for mailman id 696909;
 Fri, 22 Mar 2024 14:24:23 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rnfol-0006qz-R9
 for xen-devel@lists.xenproject.org; Fri, 22 Mar 2024 14:24:23 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e0a95fa7-e857-11ee-afe0-a90da7624cb6;
 Fri, 22 Mar 2024 15:24:22 +0100 (CET)
Received: from [192.168.1.9] (net-93-144-106-196.cust.dsl.teletu.it
 [93.144.106.196])
 by support.bugseng.com (Postfix) with ESMTPSA id A0DF44EE0742;
 Fri, 22 Mar 2024 15:24:21 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e0a95fa7-e857-11ee-afe0-a90da7624cb6
Message-ID: <329ff232-1ea4-4df0-898b-17500496eaf2@bugseng.com>
Date: Fri, 22 Mar 2024 15:24:21 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH v2 1/2] automation/eclair: add deviation for MISRA
 C:2012 Rule 17.1
Content-Language: en-US
To: Jan Beulich 
Cc: consulting@bugseng.com, sstabellini@kernel.org,
 Doug Goldstein , Andrew Cooper
 , George Dunlap ,
 Julien Grall , Wei Liu ,
 xen-devel@lists.xenproject.org
References: 
 
 <9c6f4afd-00af-41f0-86dc-4f4558cb739c@suse.com>
 <7b5bad43-88f2-4d91-abc4-6b527446cb4a@bugseng.com>
 <60181473-501a-4f17-ac11-e1598ead8b29@suse.com>
From: Simone Ballarin 
Organization: BUGSENG
In-Reply-To: <60181473-501a-4f17-ac11-e1598ead8b29@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 22/03/24 15:12, Jan Beulich wrote:
> On 22.03.2024 14:44, Simone Ballarin wrote:
>> On 22/03/24 10:44, Jan Beulich wrote:
>>> On 22.03.2024 09:46, Simone Ballarin wrote:
>>>> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
>>>> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
>>>> @@ -382,6 +382,32 @@ explicit comment indicating the fallthrough intention is present."
>>>>    -config=MC3R1.R16.6,switch_clauses+={deliberate, "default(0)"}
>>>>    -doc_end
>>>>    
>>>> +#
>>>> +# Series 17.
>>>> +#
>>>> +
>>>> +-doc_begin="printf()-like functions are allowed to use the variadic features provided by stdarg.h."
>>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(debugtrace_printk)&&kind(function))))"}
>>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(dt_dprintk)&&kind(function))))"}
>>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(printk)&&kind(function))))"}
>>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(guest_printk)&&kind(function))))"}
>>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(panic)&&kind(function))))"}
>>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(dprintk)&&kind(function))))"}
>>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(gdprintk)&&kind(function))))"}
>>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(snprintf)&&kind(function))))"}
>>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(scnprintf)&&kind(function))))"}
>>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(xasprintf)&&kind(function))))"}
>>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(mm_printk)&&kind(function))))"}
>>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(dbgp_printk)&&kind(function))))"}
>>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(elf_call_log_callback)&&kind(function))))"}
>>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(vsnprintf)&&kind(function))))"}
>>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(vscnprintf)&&kind(function))))"}
>>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(xvasprintf)&&kind(function))))"}
>>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(vprintk_common)&&kind(function))))"}
>>>> +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(guest_printk)&&kind(function))))"}
>>>> +-config=MC3R1.R17.1,macros+={hide , "^va_(arg|start|copy|end)$"}
>>>> +-doc_end
>>>
>>> Repeating v1 comments which weren't addressed>
>>> Is there a reason xyzprintk() are all listed individually? Surely if
>>> we'd introduce a new flavor, we'd want that excluded too.
>>>> {,g}dprintk() in neither of their incarnation use any of the va_*
>>> items listed. Why do they need mentioning here?
>>
>> What do you mean with "xyzprintk()"? Maybe you mean a regex-based
>> deviation using ".*printk\(.*\)"?
> 
> Regex or globbing, whatever is available.
> 
>> That would unnecessarily deviate "{,g}dprintk()" as you said.
> 
> Depends on how the regex would be written.
> 
>> Moreover, to cover also "vprintk_common", we would instead need something like
>> "^.*printk.*\(.*\)$".
> 
> Or simply accept that such outliers need listing individually. That
> would imo still be better than a dozen entries.

Ok, I will propose a patch using "^.*printk\(.*\)$"


> 
>> I'm fine in using "^.*printk.*\(.*\)$", I just preferred the individual
>> whitelisting to avoid unwanted exclusions.
>>
>> P.S:
>> using regex I cannot match only the name, but I have to match
>> the entire signature.
> 
> Interesting. Is that a tool limitation?

Why limitation? I wrote the P.S. just to motivate why I've added the "\(.*\)".

"name(abc)&&kind(function)" will simply become "^abc\(.*\)$".

Please note that I've removed "kind(function)" since the regex can only
match functions.

> 
> Jan
> 

-- 
Simone Ballarin, M.Sc.

Field Application Engineer, BUGSENG (https://bugseng.com)



From xen-devel-bounces@lists.xenproject.org Fri Mar 22 14:25:04 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Mar 2024 14:25:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696911.1088145 (Exim 4.92)
	(envelope-from )
	id 1rnfpQ-0007Kk-6v; Fri, 22 Mar 2024 14:25:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696911.1088145; Fri, 22 Mar 2024 14:25:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnfpQ-0007Kd-47; Fri, 22 Mar 2024 14:25:04 +0000
Received: by outflank-mailman (input) for mailman id 696911;
 Fri, 22 Mar 2024 14:25:03 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rnfpO-0007Gb-WD
 for xen-devel@lists.xenproject.org; Fri, 22 Mar 2024 14:25:03 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on20600.outbound.protection.outlook.com
 [2a01:111:f403:2414::600])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f77d1a17-e857-11ee-a1ee-f123f15fe8a2;
 Fri, 22 Mar 2024 15:25:00 +0100 (CET)
Received: from CH0PR08CA0029.namprd08.prod.outlook.com (2603:10b6:610:33::34)
 by PH7PR12MB7162.namprd12.prod.outlook.com (2603:10b6:510:201::22)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.30; Fri, 22 Mar
 2024 14:24:57 +0000
Received: from CH3PEPF00000015.namprd21.prod.outlook.com
 (2603:10b6:610:33:cafe::37) by CH0PR08CA0029.outlook.office365.com
 (2603:10b6:610:33::34) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.19 via Frontend
 Transport; Fri, 22 Mar 2024 14:24:57 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 CH3PEPF00000015.mail.protection.outlook.com (10.167.244.120) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7430.0 via Frontend Transport; Fri, 22 Mar 2024 14:24:56 +0000
Received: from SATLEXMB08.amd.com (10.181.40.132) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Fri, 22 Mar
 2024 09:24:55 -0500
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB08.amd.com
 (10.181.40.132) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Fri, 22 Mar
 2024 07:24:55 -0700
Received: from [172.24.153.109] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Fri, 22 Mar 2024 09:24:54 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f77d1a17-e857-11ee-a1ee-f123f15fe8a2
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=QyakiNmcPFK+z/ATpBs7Kk9urmGMkHAFpdATjN38VECKYoilJHLOJ1KTffxlqVl53VMcHEfiYJPCt4VNg5m93hZaKKSkEEWYiIeMV4dKugQRg/a4eIjjWSh/ZEn/27XRu9ad4qMY6bXX9D3m8C0c4CdIAd7evm2Q43+zn/OZ0cQ0Qa7WT0H9crj5Fhk5OxhrqL25TNwDR80aFfLHipL7BliE1f6GpOUZTqXKapLzFMpYb/Oxe1GBu5acZg8evKLstMI53TJglanLXQvTPTiZ6vTXJGvWwyheSOIacf3spCL21gkY9pVFEV59fcQBrxDC4XTmTxAF1Vc6VqI9X0MkSg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=7+zLBygDoQy5LOS5f84CNPD8kLqL2PQj/RNpkH+1M30=;
 b=QcdzmkQqhuzgMv50eicPMLSZy4xTFAUWklYJgYbvN1I2Cj9y88ijxkPb1eDuN9I9mzRUkcqPEHzfZPH6iqXstKr67EZlO1KiCYgdqL4Epgvcg1TPK+t6n99Tfdbapvg9S+kVzGnU7LhFDzypqPEJVyHsn7o9m+XuuK/lOrAlU1dQq3Y5gmZzje62FJHfEpoTirB3t9PD2GduFC2ZYYBbvUu/Wqw2RkCjrH+9lG1YqlSpu21ozwu6V+o8nFjv5ppmNt9QbKKjMff6LD9fTT0+zUKCD+HK3e0On2D3ZW4BCqJ5hBFjqCKNjukJEzaJOxYdVwdSe74j9Y0kfXNOhEsTnA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=7+zLBygDoQy5LOS5f84CNPD8kLqL2PQj/RNpkH+1M30=;
 b=Q/l/7cXCP4EF82fyl8ubx7j2bpdgul+YQjw/VDvovu23d7OXIsMjeGOqIums/mGNl5XhpUZyxrV2ZqbJN7UjuamWw/2UZKCvEByfZb3TO4DELj2E17J64cCU+2MXQ8BwYjmEJom1/bzt/lpocabjSFkMNyakw4sKuwuarjavUJs=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
Message-ID: <63cad597-b48f-43df-8d53-0ee8c1aa744d@amd.com>
Date: Fri, 22 Mar 2024 10:24:51 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 3/3] x86/PVH: Support relocatable dom0 kernels
From: Jason Andryuk 
To: Jan Beulich 
CC: Andrew Cooper ,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu
	, George Dunlap , Julien Grall
	, Stefano Stabellini ,
	
References: <20240319205849.115884-1-jason.andryuk@amd.com>
 <20240319205849.115884-4-jason.andryuk@amd.com>
 
 <183f17a2-cc7b-46c6-81b5-ac1f5daacb7b@amd.com>
Content-Language: en-US
In-Reply-To: <183f17a2-cc7b-46c6-81b5-ac1f5daacb7b@amd.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH3PEPF00000015:EE_|PH7PR12MB7162:EE_
X-MS-Office365-Filtering-Correlation-Id: 005e7c19-b179-4508-7ed9-08dc4a7bd975
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	0CEqw3cMNe5wIRNDfeHxUj6DAr+1Qb12LitQIkYd6ksLZc0Jht07Y4M8sHW+tbAyo/K/4fvJIha3nFUdUjbHd880EcAMU+gldgRvjHMuBi7NB5/Q26UhiEdfvQSRKa96XOxSXc/zi62XRehwoe/7OlvcUeGvAE2I5XA/7MOhvcoxSe22W9ZYiAJhLbMq17JoXtgZYCVIx70gBd16dBNVHZ6uq9AyD3XHdiWnsEJDOHWhj+5JUpMU2+xJnYO48VAXCFuOTpj8ilxmGatx1G1IEaEewzjqd2RvGf/pPq/dYr/T6Xy5qGQWALkf31MT5e0qjPyt5Obov8Rq2ua7i1SDbKNESDrH37TcPvkuWQNpNKZN7Sdajj1PXauFP+po3niOfRsm5kfipr3W58JpOk+WgCpjp68iLEFrraGZVkUdbF+CSA5S0mNQTYvfC4M5rPm/WsfWwpdeGfr8TRc089AUEOWOoCq7iVcunydixVrgjqD7SoLCndsxZaRfukjYJqcnXYl9tFvNwllfi9xA/c71LG5TGkzaRrlKPgkIU958QwGSFR6cdPxB2N3rKZmIt1AOF0NnPwFfSmE7z2jtaqfq21uCdBI8rxfBB5DPbNUZhb6nXwE4EIHyWXMf6f5JvfQMytyjCdRXsXKhbLywYxQDpu1SLJPJxSHcnWazmPbQS/21B4g6T5VHRMSNe9cQO0kcxArAHVDeYw+ze3MIKPmGcUrI3w3r6LM/TfPSdK+IDwh68kNCPqg0twczJhl1JffN
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(36860700004)(376005)(1800799015)(82310400014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Mar 2024 14:24:56.7056
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 005e7c19-b179-4508-7ed9-08dc4a7bd975
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH3PEPF00000015.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB7162

On 2024-03-21 09:45, Jason Andryuk wrote:
> On 2024-03-20 10:39, Jan Beulich wrote:
>> On 19.03.2024 21:58, Jason Andryuk wrote:

>>> @@ -536,6 +565,10 @@ elf_errorstatus elf_xen_parse(struct elf_binary 
>>> *elf,
>>>       parms->p2m_base = UNSET_ADDR;
>>>       parms->elf_paddr_offset = UNSET_ADDR;
>>>       parms->phys_entry = UNSET_ADDR32;
>>> +    parms->phys_min = 0;
>>> +    parms->phys_max = 0xffffffff;
>>> +    parms->phys_align = 0x200000;
>>
>> I think this wants to be MB(2) (requiring a pre-patch to centralize MB()
>> in the tool stack to tools/include/xen-tools/common-macros.h). And I
>> further think this needs to be an arch-specific constant, even if right
>> now the note is expected to be present only for x86. Which then also
>> needs saying ...

Are you thinking something like the following in libelf-dominfo.c:

#define X86_PHYS_ALIGN_DEFAULT MB(2)
#define X86_PHYS_MAX_DEFAULT (GB(4) - 1)

and setting as:
parms->phys_max = X86_PHYS_MAX_DEFAULT;
parms->phys_align = X86_PHYS_ALIGN_DEFAULT;

libelf is arch neutral, so there isn't a natural place to introduce 
arch-specific defines.  Or were you looking for each arch to set it?  We 
only care about x86 right now, so we can do something like:

#if x86
#define ARCH_PHYS_MAX_DEFAULT   (GB(4) - 1)
#define ARCH_PHYS_ALIGN_DEFAULT MB(2)
#else
#define ARCH_PHYS_MAX_DEFAULT   0
#define ARCH_PHYS_ALIGN_DEFAULT 0
#endif

Thanks,
Jason


From xen-devel-bounces@lists.xenproject.org Fri Mar 22 15:07:58 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Mar 2024 15:07:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696926.1088158 (Exim 4.92)
	(envelope-from )
	id 1rngUm-0006On-Db; Fri, 22 Mar 2024 15:07:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696926.1088158; Fri, 22 Mar 2024 15:07:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rngUm-0006Od-Ap; Fri, 22 Mar 2024 15:07:48 +0000
Received: by outflank-mailman (input) for mailman id 696926;
 Fri, 22 Mar 2024 15:07:47 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rngUk-0006OX-S6
 for xen-devel@lists.xenproject.org; Fri, 22 Mar 2024 15:07:46 +0000
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com
 [2a00:1450:4864:20::62b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id eec3f16e-e85d-11ee-a1ee-f123f15fe8a2;
 Fri, 22 Mar 2024 16:07:43 +0100 (CET)
Received: by mail-ej1-x62b.google.com with SMTP id
 a640c23a62f3a-a47062136c0so281106566b.2
 for ; Fri, 22 Mar 2024 08:07:43 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: eec3f16e-e85d-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1711120062; x=1711724862; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=9GPIzfg3Tdo4oOPyNmPnGuswh61zm6kAYYK5uEDnjsU=;
        b=YaAh0aCaz/g5zkXQRXoR7vJyf7ruUc92QwNRwLPJX8GKblHlHFGt47l53rPjyX/4ht
         lNTTyUGZjC3guYtD3VLrV8YBNh30RkIct/va66C5Vae7GhcnTIbfDujSpuIOuJGzcTRn
         nBMgdJe6UCG7X34Mnx+oMxu4XaveY0AqffTKSBBnV7poE6zAhVH02hR5TYYWs3bzkEQs
         7hyf8wPUcfxq6TOcnLbTxpeRhDjFooIOCwHfmwYIs6gF4UAls1TuX8Y/vqoVaemeVC7G
         JT/D4GVZDL6vL1BH9rBr2HghlyLsl1zucEJKzXrjZOPKM/HZ1kIRC120VZ769L8dHE1C
         xccw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711120062; x=1711724862;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=9GPIzfg3Tdo4oOPyNmPnGuswh61zm6kAYYK5uEDnjsU=;
        b=xEpE6vT/R1P3hyp+Qlb5v78r/0uB/f4TyB66705sMUhxn9hJNbJpcEi9RTrWlFNfna
         N1gEauBnvADHlBrYMTG0JvvDNXX/4ffinzmcwug4CxpTeDhCqe4ZEuVML0oUEhuVurrj
         f0btdY9RhxfFyT+tbO9QiNbLlcfzSNsmu0vaOcTvWiEoAdjqiu4tCCmcXvxwlYBWsIXB
         +uJ3DpHC+mS1cg6BPd3qx0/7rVRMbx+y8K1EGNirFyS1iXWIZQKg6u1BYUI5aB/0Mq51
         pRtRppDxhSyBeTdA3+VVxxTnfxQupQlm3HrLHL41WUZMztCZc04GRZJt1ISrfU2qQ/7Z
         WJSA==
X-Forwarded-Encrypted: i=1; AJvYcCXnmzEWhn7OXy43IGgDddfiIBCF0IpUsiaysFRyaQXS96bcrP00TbjoM7wMUatcZTnllW1y1MedNW+vvZKu/HzNLWltV0fDenmuAKgA9Es=
X-Gm-Message-State: AOJu0Yx2dU0fQ/2jhxhPnLzJ8XnDO4Y5UWRqdJWhh5pjfSbtDJgJS00s
	hw4vzSOi8g6Fdm2u4sSsvPS0qV5eoLhT8mBHxdz/qtXFqw5M6eDvvh20bklAhulL/1p4ln8Sj/h
	clSDDaPgcOkNkB8Jr3cyBJ6/shUdsUf4xLBd9xw==
X-Google-Smtp-Source: AGHT+IGYJt56ZWt40So5HCR5pVTvACYWOQi8ATGGrtWIgkLAnWWST3fiFbb94xQaVQLIOGRuMFwZNH8jCvTYpUD4HAc=
X-Received: by 2002:a17:906:b808:b0:a47:347f:f0fd with SMTP id
 dv8-20020a170906b80800b00a47347ff0fdmr1162234ejb.53.1711120062621; Fri, 22
 Mar 2024 08:07:42 -0700 (PDT)
MIME-Version: 1.0
References: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
 <20240315105902.160047-9-carlo.nonato@minervasys.tech> <3f615066-a792-493f-ba33-7667a6557c23@xen.org>
 <9e0f7ff3-5457-41e4-a1e4-bf75804fb900@xen.org> <255be735-f9fe-4e39-a24e-2f6aff91acc5@suse.com>
In-Reply-To: <255be735-f9fe-4e39-a24e-2f6aff91acc5@suse.com>
From: Carlo Nonato 
Date: Fri, 22 Mar 2024 16:07:31 +0100
Message-ID: 
Subject: Re: [PATCH v7 08/14] xen/page_alloc: introduce preserved page flags macro
To: Jan Beulich 
Cc: Julien Grall , Andrew Cooper , 
	George Dunlap , Stefano Stabellini , Wei Liu , 
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
	xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi guys,

On Thu, Mar 21, 2024 at 5:23=E2=80=AFPM Jan Beulich  wro=
te:
>
> On 21.03.2024 17:10, Julien Grall wrote:
> > On 21/03/2024 16:07, Julien Grall wrote:
> >> On 15/03/2024 10:58, Carlo Nonato wrote:
> >>> PGC_static and PGC_extra needs to be preserved when assigning a page.
> >>> Define a new macro that groups those flags and use it instead of or'i=
ng
> >>> every time.
> >>>
> >>> To make preserved flags even more meaningful, they are kept also when
> >>> switching state in mark_page_free().
> >>>
> >>> Signed-off-by: Carlo Nonato 
> >>
> >> This patch is introducing a regression in OSStest (and possibly gitlab=
?):
> >>
> >> Mar 21 12:00:29.533676 (XEN) pg[0] MFN 2211c5 c=3D0x2c00000000000000 o=
=3D0
> >> v=3D0xe40000010007ffff t=3D0x24
> >> Mar 21 12:00:42.829785 (XEN) Xen BUG at common/page_alloc.c:1033
> >> Mar 21 12:00:42.829829 (XEN) ----[ Xen-4.19-unstable  x86_64  debug=3D=
y
> >> Not tainted ]----
> >> Mar 21 12:00:42.829857 (XEN) CPU:    12
> >> Mar 21 12:00:42.841571 (XEN) RIP:    e008:[]
> >> common/page_alloc.c#alloc_heap_pages+0x37f/0x6e2
> >> Mar 21 12:00:42.841609 (XEN) RFLAGS: 0000000000010282   CONTEXT:
> >> hypervisor (d0v8)
> >> Mar 21 12:00:42.853654 (XEN) rax: ffff83023e3ed06c   rbx:
> >> 000000000007ffff   rcx: 0000000000000028
> >> Mar 21 12:00:42.853689 (XEN) rdx: ffff83047bec7fff   rsi:
> >> ffff83023e3ea3e8   rdi: ffff83023e3ea3e0
> >> Mar 21 12:00:42.865657 (XEN) rbp: ffff83047bec7c10   rsp:
> >> ffff83047bec7b98   r8:  0000000000000000
> >> Mar 21 12:00:42.877647 (XEN) r9:  0000000000000001   r10:
> >> 000000000000000c   r11: 0000000000000010
> >> Mar 21 12:00:42.877682 (XEN) r12: 0000000000000001   r13:
> >> 0000000000000000   r14: ffff82e0044238a0
> >> Mar 21 12:00:42.889652 (XEN) r15: 0000000000000000   cr0:
> >> 0000000080050033   cr4: 0000000000372660
> >> Mar 21 12:00:42.901651 (XEN) cr3: 000000046fe34000   cr2: 00007fb72757=
610b
> >> Mar 21 12:00:42.901685 (XEN) fsb: 00007fb726def380   gsb:
> >> ffff88801f200000   gss: 0000000000000000
> >> Mar 21 12:00:42.913646 (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000
> >> ss: e010   cs: e008
> >> Mar 21 12:00:42.913680 (XEN) Xen code around 
> >> (common/page_alloc.c#alloc_heap_pages+0x37f/0x6e2):
> >> Mar 21 12:00:42.925645 (XEN)  d1 1c 00 e8 ad dd 02 00 <0f> 0b 48 85 c9
> >> 79 36 0f 0b 41 89 cd 48 c7 47 f0
> >> Mar 21 12:00:42.937649 (XEN) Xen stack trace from rsp=3Dffff83047bec7b=
98:
> >> Mar 21 12:00:42.937683 (XEN)    0000000000000024 000000007bec7c20
> >> 0000000000000001 ffff83046ccda000
> >> Mar 21 12:00:42.949653 (XEN)    ffff82e000000021 0000000000000016
> >> 0000000000000000 0000000000000000
> >> Mar 21 12:00:42.949687 (XEN)    0000000000000000 0000000000000000
> >> 0000000000000028 0000000000000021
> >> Mar 21 12:00:42.961652 (XEN)    ffff83046ccda000 0000000000000000
> >> 00007d2000000000 ffff83047bec7c48
> >> Mar 21 12:00:42.961687 (XEN)    ffff82d0402302ff ffff83046ccda000
> >> 0000000000000100 0000000000000000
> >> Mar 21 12:00:42.973655 (XEN)    ffff82d0405f0080 00007d2000000000
> >> ffff83047bec7c80 ffff82d0402f626c
> >> Mar 21 12:00:42.985656 (XEN)    ffff83046ccda000 ffff83046ccda640
> >> 0000000000000000 0000000000000000
> >> Mar 21 12:00:42.985690 (XEN)    ffff83046ccda220 ffff83047bec7cb0
> >> ffff82d0402f65a0 ffff83046ccda000
> >> Mar 21 12:00:42.997662 (XEN)    0000000000000000 0000000000000000
> >> 0000000000000000 ffff83047bec7cc0
> >> Mar 21 12:00:43.009660 (XEN)    ffff82d040311f8a ffff83047bec7ce0
> >> ffff82d0402bd543 ffff83046ccda000
> >> Mar 21 12:00:43.009695 (XEN)    ffff83047bec7dc8 ffff83047bec7d08
> >> ffff82d04032c524 ffff83046ccda000
> >> Mar 21 12:00:43.021653 (XEN)    ffff83047bec7dc8 0000000000000002
> >> ffff83047bec7d58 ffff82d040206750
> >> Mar 21 12:00:43.033642 (XEN)    0000000000000000 ffff82d040233fe5
> >> ffff83047bec7d48 0000000000000000
> >> Mar 21 12:00:43.033678 (XEN)    0000000000000002 00007fb72767f010
> >> ffff82d0405e9120 0000000000000001
> >> Mar 21 12:00:43.045654 (XEN)    ffff83047bec7e70 ffff82d040240728
> >> 0000000000000007 ffff83023e3b3000
> >> Mar 21 12:00:43.045690 (XEN)    0000000000000246 ffff83023e2efa90
> >> ffff83023e38e000 ffff83023e2efb40
> >> Mar 21 12:00:43.057609 (XEN)    0000000000000007 ffff83023e3afb80
> >> 0000000000000206 ffff83047bec7dc0
> >> Mar 21 12:00:43.069662 (XEN)    0000001600000001 000000000000ffff
> >> e75aaa8d0000000c ac0d6d864e487f62
> >> Mar 21 12:00:43.069697 (XEN)    000000037fa48d76 0000000200000000
> >> ffffffff000003ff 00000002ffffffff
> >> Mar 21 12:00:43.081647 (XEN)    0000000000000000 00000000000001ff
> >> 0000000000000000 0000000000000000
> >> Mar 21 12:00:43.093646 (XEN) Xen call trace:
> >> Mar 21 12:00:43.093677 (XEN)    [] R
> >> common/page_alloc.c#alloc_heap_pages+0x37f/0x6e2
> >> Mar 21 12:00:43.093705 (XEN)    [] F
> >> alloc_domheap_pages+0x17d/0x1e4
> >> Mar 21 12:00:43.105652 (XEN)    [] F
> >> hap_set_allocation+0x73/0x23c
> >> Mar 21 12:00:43.105685 (XEN)    [] F
> >> hap_enable+0x138/0x33c
> >> Mar 21 12:00:43.117646 (XEN)    [] F
> >> paging_enable+0x2d/0x45
> >> Mar 21 12:00:43.117679 (XEN)    [] F
> >> hvm_domain_initialise+0x185/0x428
> >> Mar 21 12:00:43.129652 (XEN)    [] F
> >> arch_domain_create+0x3e7/0x4c1
> >> Mar 21 12:00:43.129687 (XEN)    [] F
> >> domain_create+0x4cc/0x7e2
> >> Mar 21 12:00:43.141665 (XEN)    [] F
> >> do_domctl+0x1850/0x192d
> >> Mar 21 12:00:43.141699 (XEN)    [] F
> >> pv_hypercall+0x617/0x6b5
> >> Mar 21 12:00:43.153656 (XEN)    [] F
> >> lstar_enter+0x13a/0x140
> >> Mar 21 12:00:43.153689 (XEN)
> >> Mar 21 12:00:43.153711 (XEN)
> >> Mar 21 12:00:43.153731 (XEN) ****************************************
> >> Mar 21 12:00:43.165647 (XEN) Panic on CPU 12:
> >> Mar 21 12:00:43.165678 (XEN) Xen BUG at common/page_alloc.c:1033
> >> Mar 21 12:00:43.165703 (XEN) ****************************************
> >> Mar 21 12:00:43.177633 (XEN)
> >> Mar 21 12:00:43.177662 (XEN) Manual reset required ('noreboot' specifi=
ed)
> >>
> >> The code around the BUG is:
> >>
> >>          /* Reference count must continuously be zero for free pages. =
*/
> >>          if ( (pg[i].count_info & ~PGC_need_scrub) !=3D PGC_state_free=
 )
> >>          {
> >>              printk(XENLOG_ERR
> >>                     "pg[%u] MFN %"PRI_mfn" c=3D%#lx o=3D%u v=3D%#lx t=
=3D%#x\n",
> >>                     i, mfn_x(page_to_mfn(pg + i)),
> >>                     pg[i].count_info, pg[i].v.free.order,
> >>                     pg[i].u.free.val, pg[i].tlbflush_timestamp);
> >>              BUG();
> >>          }
> >>
> >> Now that you are preserving some flags, you also want to modify the
> >> condition. I haven't checked the rest of the code, so there might be
> >> some adjustments necessary.
> >
> > Actually maybe the condition should not be adjusted. I think it would b=
e
> > wrong if a free pages has the flag PGC_extra set. Any thoughts?
>
> I agree, yet I'm inclined to say PGC_extra should have been cleared
> before trying to free the page.

So what to do now? Should I drop this commit?

Thanks.


From xen-devel-bounces@lists.xenproject.org Fri Mar 22 15:09:39 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Mar 2024 15:09:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696931.1088167 (Exim 4.92)
	(envelope-from )
	id 1rngWY-00073s-Ru; Fri, 22 Mar 2024 15:09:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696931.1088167; Fri, 22 Mar 2024 15:09:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rngWY-00073l-PO; Fri, 22 Mar 2024 15:09:38 +0000
Received: by outflank-mailman (input) for mailman id 696931;
 Fri, 22 Mar 2024 15:09:37 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rngWX-00073f-2k
 for xen-devel@lists.xenproject.org; Fri, 22 Mar 2024 15:09:37 +0000
Received: from NAM02-BN1-obe.outbound.protection.outlook.com
 (mail-bn1nam02on20601.outbound.protection.outlook.com
 [2a01:111:f403:2407::601])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3062944b-e85e-11ee-a1ee-f123f15fe8a2;
 Fri, 22 Mar 2024 16:09:34 +0100 (CET)
Received: from PR0P264CA0090.FRAP264.PROD.OUTLOOK.COM (2603:10a6:100:18::30)
 by DM4PR12MB6160.namprd12.prod.outlook.com (2603:10b6:8:a7::13) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.24; Fri, 22 Mar
 2024 15:09:30 +0000
Received: from SN1PEPF00026369.namprd02.prod.outlook.com
 (2603:10a6:100:18:cafe::aa) by PR0P264CA0090.outlook.office365.com
 (2603:10a6:100:18::30) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.13 via Frontend
 Transport; Fri, 22 Mar 2024 15:09:29 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SN1PEPF00026369.mail.protection.outlook.com (10.167.241.134) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Fri, 22 Mar 2024 15:09:29 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Fri, 22 Mar
 2024 10:09:27 -0500
Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Fri, 22 Mar 2024 10:09:26 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3062944b-e85e-11ee-a1ee-f123f15fe8a2
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=Ei/A0iEx4xr4Ua8XSlgmqO4vrkggFR/mu/qZWokazr+28TjyVsB65/20viKFskU3nIfiPZRa18d7mppJjWDqxKqxn4zLhU2ERszP3q54kPdysDQFzOL0UI73cnmgcB3HD/1rX/ECMXbRBlnUUidpNVN58KiQ5ec5S/uRogD99kswSbsFCwNHg6Qzs4UdgwQnmwFtm3jXUY3U4VR40DGR4R3R3q8E8HAz6srtovsOlcDppdt0GIUkbrvHkQnARCGO7BZsldFqRbWc4vGfmhms5bBzJpjS0jgvgnbTmYr/d6AMqXpgK7NmKF4hGhmLggxAfgHnYmyxLpEWzWCXdxItRQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=lan5XMue9Z2MeH7IagdyYeJt/D0KfB5exFiH/6YnwcM=;
 b=ELzGvTfwBK2N7reUQ+QBqmt6ZeKo4GcVB1pYcWNWYE0/BfPcKOD3VHdMyHGXSRCNVEWBk47lFerCk3dheyarLK0pcBD50zAw7d3YWSu+WZcC2ZDaHUXEzSlUaV1ofEvmlWtt16ijTZdhF6BttuCWqkAcLuopNqy+xTdKenNltWoEV4Vx3DucmiG9az+C3g2e3CTqlOhK++VCtbr3sRNQggAeDr+bUGEoOzo+NkPG8lnV9CzN2tink64pUeEvGUMFzK7DkJNAmr9jO8o+HZy7CzYBKxtZvNgkOXHvFBYgUF0ujHges5MzxU4hfMPiLXxG5ZOv2/8UV6TBhq9VL3lvqg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=arm.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=lan5XMue9Z2MeH7IagdyYeJt/D0KfB5exFiH/6YnwcM=;
 b=2PInbwcq0BHClIT4p0S3peZQ10KRpIAs9JrqvuTE2WupvSwjfooOh3TsAM3mmQ6+VKoW3Tr+REaOslQItEnTfagDUIf/1oMvLEdBsyStzLbKoIH1VpJTYPo5Zdxz0kR3UA/b2XrM5rAgDVYvZCyU4Np2OItbuumPVSD673/evKw=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Message-ID: <9edf6716-77d9-445a-8f65-0914ffb97e3f@amd.com>
Date: Fri, 22 Mar 2024 16:09:26 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 09/11] xen/arm: remove shm holes for extended regions
Content-Language: en-US
To: Luca Fancellu , 
CC: Penny Zheng , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Volodymyr Babchuk 
References: <20240312130331.78418-1-luca.fancellu@arm.com>
 <20240312130331.78418-10-luca.fancellu@arm.com>
From: Michal Orzel 
In-Reply-To: <20240312130331.78418-10-luca.fancellu@arm.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB04.amd.com: michal.orzel@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF00026369:EE_|DM4PR12MB6160:EE_
X-MS-Office365-Filtering-Correlation-Id: 20399999-8153-4a68-93de-08dc4a821257
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	AF+sLU1pfo2KWnq7HbcBhk8jj3yrbWOqjpuRtasDoA47NbNbx9aKv0fZihAIdmW4K9wK8zwUOIgSvtO3Q0qrW/jhiJLXG7YoVz1mV12q/sr/xlDqJW5aow1zR+JB0Ulut/n/a+wVBSTGIAMCvcbDDMsCdtvAD4LVpcoVH56AIktqhhOGD1pYOIw4BlD0G5pdoZz3CuX+sJfEOzZ+D54CveEaiiJeimLU1NhZXdTRSWk8ex9ZiQRsEDpPM/CFfAN5WWuvj1ClcMm+0WnL5VC5kDPWTqq63Vgt6BHSrt9G3+jnLgBx5XEcRqHk/tfNDg2KEvtxD7DAF5RVg0NX/Z9w1RQVUTjz2eJ512uuEiFFuARsLAd14KUODpMIAGe2pP0yaBxUTegW86U9+bF9F6PqfUrDqKXNvH5CDxgSwLDBEInm4tsJ0EyF4qPdYVHVqdmpxZ6CfctJTNllVO7gqiO7sKhqpcX5d/Wublf9Yq7+7FTb5Fotl0phyUzsS75fu28wgCkQcBfFMz5GlHTOIJefxnQo/j1bg3FV0bJfilB4exEeKx6VVEpVrSeMw9eByoyFSPsY/CRP5o3Fytb/TfRbfxL3X2BL+hMoDKsrwCtEaEt9VA8Dat1NSoT9JaQWamfOzKoVA+U+8Rbzgec1o4Tv3RD9j9CTn1MVwH9dwkaE4eakwkGQo+4gkWrefMKfJhMWNSP2Ovd2AJ2uf2deN9uLDw==
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(376005)(82310400014)(1800799015)(36860700004);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Mar 2024 15:09:29.1357
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 20399999-8153-4a68-93de-08dc4a821257
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF00026369.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB6160

Hi Luca,

NIT: title s/for/from?

On 12/03/2024 14:03, Luca Fancellu wrote:
> 
> 
> From: Penny Zheng 
> 
> Static shared memory acts as reserved memory in guest, so it shall be
> excluded from extended regions.
> 
> Extended regions are taken care of under three different scenarios:
> normal DomU, direct-map domain with iommu on, and direct-map domain
> with iommu off.
> 
> For normal DomU, we create a new function "remove_shm_holes_for_domU",
> to firstly transfer original outputs into the format of
> "struct rangeset", then use "remove_shm_from_rangeset" to remove static
> shm from them.
> 
> For direct-map domain with iommu on, after we get guest shm info from "kinfo",
> we use "remove_shm_from_rangeset" to remove static shm.
> 
> For direct-map domain with iommu off, as static shm has already been taken
> care of through reserved memory banks, we do nothing.
> 
> Signed-off-by: Penny Zheng 
> Signed-off-by: Luca Fancellu 
> ---
> v1:
>  - Rework of https://patchwork.kernel.org/project/xen-devel/patch/20231206090623.1932275-8-Penny.Zheng@arm.com/
> ---
>  xen/arch/arm/domain_build.c             | 16 ++++-
>  xen/arch/arm/include/asm/domain_build.h |  2 +
>  xen/arch/arm/include/asm/static-shmem.h | 18 ++++++
>  xen/arch/arm/static-shmem.c             | 86 +++++++++++++++++++++++++
>  4 files changed, 119 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 9fad9e8b2c40..740c483ea2db 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -817,8 +817,8 @@ int __init make_memory_node(const struct domain *d,
>      return res;
>  }
> 
> -static int __init add_ext_regions(unsigned long s_gfn, unsigned long e_gfn,
> -                                  void *data)
> +int __init add_ext_regions(unsigned long s_gfn, unsigned long e_gfn,
> +                           void *data)
>  {
>      struct membanks *ext_regions = data;
>      paddr_t start, size;
> @@ -969,6 +969,8 @@ static int __init handle_pci_range(const struct dt_device_node *dev,
>   * - MMIO
>   * - Host RAM
>   * - PCI aperture
> + * - Static shared memory regions, which are described by special property
> + *   "xen,domain-shared-memory-v1"
I'm not sure if providing a compatible here makes sense. If at all, I would put "xen,shared-mem" which holds the addresses.

>   */
>  static int __init find_memory_holes(const struct kernel_info *kinfo,
>                                      struct membanks *ext_regions)
> @@ -985,6 +987,11 @@ static int __init find_memory_holes(const struct kernel_info *kinfo,
>      if ( !mem_holes )
>          return -ENOMEM;
> 
> +    /* Remove static shared memory regions */
> +    res = remove_shm_from_rangeset(kinfo, mem_holes);
> +    if ( res )
> +        goto out;
How can you remove from a rangeset without first adding to it?
This should be moved after rangeset_add_range().
Also, usually (and this is the case in this function) we pass frames
to rangeset and not addresses (argument is of type ul). However...

> +
>      /* Start with maximum possible addressable physical memory range */
>      start = 0;
>      end = (1ULL << p2m_ipa_bits) - 1;
> @@ -1089,7 +1096,10 @@ static int __init find_domU_holes(const struct kernel_info *kinfo,
>          res = 0;
>      }
> 
> -    return res;
> +    if ( res )
> +        return res;
> +
> +    return remove_shm_holes_for_domU(kinfo, ext_regions);
>  }
> 
>  int __init make_hypervisor_node(struct domain *d,
> diff --git a/xen/arch/arm/include/asm/domain_build.h b/xen/arch/arm/include/asm/domain_build.h
> index a6f276cc4263..026d975da28e 100644
> --- a/xen/arch/arm/include/asm/domain_build.h
> +++ b/xen/arch/arm/include/asm/domain_build.h
> @@ -51,6 +51,8 @@ static inline int prepare_acpi(struct domain *d, struct kernel_info *kinfo)
>  int prepare_acpi(struct domain *d, struct kernel_info *kinfo);
>  #endif
> 
> +int add_ext_regions(unsigned long s_gfn, unsigned long e_gfn, void *data);
> +
>  #endif
> 
>  /*
> diff --git a/xen/arch/arm/include/asm/static-shmem.h b/xen/arch/arm/include/asm/static-shmem.h
> index c6fac9906656..2f70aed53ac7 100644
> --- a/xen/arch/arm/include/asm/static-shmem.h
> +++ b/xen/arch/arm/include/asm/static-shmem.h
> @@ -29,6 +29,12 @@ void early_print_info_shmem(void);
> 
>  void init_sharedmem_pages(void);
> 
> +int remove_shm_from_rangeset(const struct kernel_info *kinfo,
> +                             struct rangeset *rangeset);
> +
> +int remove_shm_holes_for_domU(const struct kernel_info *kinfo,
> +                              struct membanks *ext_regions);
> +
>  #else /* !CONFIG_STATIC_SHM */
> 
>  static inline int make_resv_memory_node(const struct domain *d,
> @@ -61,6 +67,18 @@ static inline void early_print_info_shmem(void) {};
> 
>  static inline void init_sharedmem_pages(void) {};
> 
> +static inline int remove_shm_from_rangeset(const struct kernel_info *kinfo,
> +                                           struct rangeset *rangeset)
> +{
> +    return 0;
> +}
> +
> +static inline int remove_shm_holes_for_domU(const struct kernel_info *kinfo,
> +                                            struct membanks *ext_regions)
> +{
> +    return 0;
> +}
> +
>  #endif /* CONFIG_STATIC_SHM */
> 
>  #endif /* __ASM_STATIC_SHMEM_H_ */
> diff --git a/xen/arch/arm/static-shmem.c b/xen/arch/arm/static-shmem.c
> index 6143f52cb991..b3e2105dd3f2 100644
> --- a/xen/arch/arm/static-shmem.c
> +++ b/xen/arch/arm/static-shmem.c
> @@ -1,6 +1,7 @@
>  /* SPDX-License-Identifier: GPL-2.0-only */
> 
>  #include 
> +#include 
>  #include 
> 
>  #include 
> @@ -564,6 +565,91 @@ void __init init_sharedmem_pages(void)
>          init_staticmem_bank(&shmem->bank[bank]);
>  }
> 
> +int __init remove_shm_from_rangeset(const struct kernel_info *kinfo,
> +                                    struct rangeset *rangeset)
> +{
> +    const struct membanks *shm_mem = &kinfo->shm_mem.common;
> +    unsigned int i;
> +
> +    /* Remove static shared memory regions */
> +    for ( i = 0; i < shm_mem->nr_banks; i++ )
> +    {
> +        paddr_t start, end;
... here, these hold physical addresses and...

> +        int res;
> +
> +        start = shm_mem->bank[i].start;
> +        end = shm_mem->bank[i].start + shm_mem->bank[i].size - 1;
> +        res = rangeset_remove_range(rangeset, start, end);
you will end up in a mix which won't work. Switch to PFN_DOWN()

> +        if ( res )
What's the point of res variable if it is not printed below?

> +        {
> +            printk(XENLOG_ERR "Failed to remove: %#"PRIpaddr"->%#"PRIpaddr"\n",
> +                   start, end);
> +            return -EINVAL;
> +        }
> +    }
> +
> +    return 0;
> +}
> +
> +int __init remove_shm_holes_for_domU(const struct kernel_info *kinfo,
> +                                     struct membanks *ext_regions)
> +{
> +    const struct membanks *shm_mem = &kinfo->shm_mem.common;
> +    struct rangeset *guest_holes;
> +    unsigned int i;
> +    paddr_t start;
> +    paddr_t end;
> +    int res;
> +
> +    /* No static shared memory region. */
> +    if ( shm_mem->nr_banks == 0 )
> +        return 0;
> +
> +    dt_dprintk("Remove static shared memory holes for extended regions of DomU\n");
> +
> +    guest_holes = rangeset_new(NULL, NULL, 0);
> +    if ( !guest_holes )
> +        return -ENOMEM;
> +
> +    /* Copy extended regions sets into the rangeset */
> +    for ( i = 0; i < ext_regions->nr_banks; i++ )
> +    {
> +        start = ext_regions->bank[i].start;
> +        end = start + ext_regions->bank[i].size - 1;
> +
> +        res = rangeset_add_range(guest_holes, start, end);
Ditto, PFN_DOWN().

~Michal


From xen-devel-bounces@lists.xenproject.org Fri Mar 22 16:02:15 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Mar 2024 16:02:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696952.1088193 (Exim 4.92)
	(envelope-from )
	id 1rnhLO-0000gh-6z; Fri, 22 Mar 2024 16:02:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696952.1088193; Fri, 22 Mar 2024 16:02:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnhLO-0000fF-0K; Fri, 22 Mar 2024 16:02:10 +0000
Received: by outflank-mailman (input) for mailman id 696952;
 Fri, 22 Mar 2024 16:02:09 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rnhLN-0000WB-Cf
 for xen-devel@lists.xenproject.org; Fri, 22 Mar 2024 16:02:09 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 88dc9601-e865-11ee-afe0-a90da7624cb6;
 Fri, 22 Mar 2024 17:02:08 +0100 (CET)
Received: from nico.bugseng.com (unknown [46.228.253.194])
 by support.bugseng.com (Postfix) with ESMTPSA id C955C4EE0C8D;
 Fri, 22 Mar 2024 17:02:06 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 88dc9601-e865-11ee-afe0-a90da7624cb6
From: Nicola Vetrini 
To: nicola.vetrini@bugseng.com,
	xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org,
	michal.orzel@amd.com,
	xenia.ragiadakou@amd.com,
	ayan.kumar.halder@amd.com,
	consulting@bugseng.com,
	jbeulich@suse.com,
	andrew.cooper3@citrix.com,
	roger.pau@citrix.com,
	bertrand.marquis@arm.com,
	julien@xen.org,
	"Daniel P. Smith" 
Subject: [XEN PATCH 02/11] xen/xsm: add parentheses to comply with MISRA C Rule 20.7
Date: Fri, 22 Mar 2024 17:01:51 +0100
Message-Id: <6cb601ef46a699f95eda0e10f4f9d15f1af4353e.1711118582.git.nicola.vetrini@bugseng.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter the semantics of the passed-in macro parameter.

No functional change.

Signed-off-by: Nicola Vetrini 
Reviewed-by: Stefano Stabellini 
---
 xen/include/xsm/dummy.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 8671af1ba4d3..88039fdd227c 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -58,7 +58,7 @@ void __xsm_action_mismatch_detected(void);
 
 #define XSM_DEFAULT_ARG /* */
 #define XSM_DEFAULT_VOID void
-#define XSM_ASSERT_ACTION(def) xsm_default_t action = def; (void)action
+#define XSM_ASSERT_ACTION(def) xsm_default_t action = (def); (void)action
 
 #else /* CONFIG_XSM */
 
@@ -71,7 +71,7 @@ void __xsm_action_mismatch_detected(void);
 #define XSM_INLINE always_inline
 #define XSM_DEFAULT_ARG xsm_default_t action,
 #define XSM_DEFAULT_VOID xsm_default_t action
-#define XSM_ASSERT_ACTION(def) LINKER_BUG_ON(def != action)
+#define XSM_ASSERT_ACTION(def) LINKER_BUG_ON((def) != action)
 
 #endif /* CONFIG_XSM */
 
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Mar 22 16:02:15 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Mar 2024 16:02:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696954.1088217 (Exim 4.92)
	(envelope-from )
	id 1rnhLP-0001Gr-Ua; Fri, 22 Mar 2024 16:02:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696954.1088217; Fri, 22 Mar 2024 16:02:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnhLP-0001G1-Oh; Fri, 22 Mar 2024 16:02:11 +0000
Received: by outflank-mailman (input) for mailman id 696954;
 Fri, 22 Mar 2024 16:02:11 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rnhLP-0000WB-DB
 for xen-devel@lists.xenproject.org; Fri, 22 Mar 2024 16:02:11 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 89d1882e-e865-11ee-afe0-a90da7624cb6;
 Fri, 22 Mar 2024 17:02:09 +0100 (CET)
Received: from nico.bugseng.com (unknown [46.228.253.194])
 by support.bugseng.com (Postfix) with ESMTPSA id 0B02A4EE0C90;
 Fri, 22 Mar 2024 17:02:09 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 89d1882e-e865-11ee-afe0-a90da7624cb6
From: Nicola Vetrini 
To: nicola.vetrini@bugseng.com,
	xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org,
	michal.orzel@amd.com,
	xenia.ragiadakou@amd.com,
	ayan.kumar.halder@amd.com,
	consulting@bugseng.com,
	jbeulich@suse.com,
	andrew.cooper3@citrix.com,
	roger.pau@citrix.com,
	bertrand.marquis@arm.com,
	julien@xen.org,
	George Dunlap 
Subject: [XEN PATCH 04/11] xentrace: address violation of MISRA C Rule 20.7
Date: Fri, 22 Mar 2024 17:01:53 +0100
Message-Id: <06c112784c54fcd87792bb96515ecdf91b2109c3.1711118582.git.nicola.vetrini@bugseng.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter the semantics of the passed-in macro parameter.

No functional change.

Signed-off-by: Nicola Vetrini 
---
 xen/include/public/trace.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/include/public/trace.h b/xen/include/public/trace.h
index 62a179971d2a..3c9f9c3c18b2 100644
--- a/xen/include/public/trace.h
+++ b/xen/include/public/trace.h
@@ -67,7 +67,7 @@
 #define TRC_SCHED_CLASS_EVT(_c, _e) \
   ( ( TRC_SCHED_CLASS | \
       ((TRC_SCHED_##_c << TRC_SCHED_ID_SHIFT) & TRC_SCHED_ID_MASK) ) + \
-    (_e & TRC_SCHED_EVT_MASK) )
+    ((_e) & TRC_SCHED_EVT_MASK) )
 
 /* Trace classes for DOM0 operations */
 #define TRC_DOM0_DOMOPS     0x00041000   /* Domains manipulations */
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Mar 22 16:02:15 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Mar 2024 16:02:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696951.1088186 (Exim 4.92)
	(envelope-from )
	id 1rnhLN-0000a5-SB; Fri, 22 Mar 2024 16:02:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696951.1088186; Fri, 22 Mar 2024 16:02:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnhLN-0000Yk-NF; Fri, 22 Mar 2024 16:02:09 +0000
Received: by outflank-mailman (input) for mailman id 696951;
 Fri, 22 Mar 2024 16:02:08 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rnhLM-0000WB-Nu
 for xen-devel@lists.xenproject.org; Fri, 22 Mar 2024 16:02:08 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 881309f1-e865-11ee-afe0-a90da7624cb6;
 Fri, 22 Mar 2024 17:02:07 +0100 (CET)
Received: from nico.bugseng.com (unknown [46.228.253.194])
 by support.bugseng.com (Postfix) with ESMTPSA id 5419E4EE0C8A;
 Fri, 22 Mar 2024 17:02:05 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 881309f1-e865-11ee-afe0-a90da7624cb6
From: Nicola Vetrini 
To: nicola.vetrini@bugseng.com,
	xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org,
	michal.orzel@amd.com,
	xenia.ragiadakou@amd.com,
	ayan.kumar.halder@amd.com,
	consulting@bugseng.com,
	jbeulich@suse.com,
	andrew.cooper3@citrix.com,
	roger.pau@citrix.com,
	bertrand.marquis@arm.com,
	julien@xen.org,
	George Dunlap 
Subject: [XEN PATCH 01/11] xen/list: address violations of MISRA C Rule 20.7
Date: Fri, 22 Mar 2024 17:01:50 +0100
Message-Id: 
X-Mailer: git-send-email 2.34.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter the semantics of the passed-in macro parameter.

No functional change.

Signed-off-by: Nicola Vetrini 
---
Changes in v2:
- changes to list.h are all in this patch;
- Parenthesized some instances of "pos" and "n" even when already
covered by the deviation on the lhs of an assingment for consistency.
Changes in v3:
- Added more parentheses that were missed.
---
 xen/include/xen/list.h | 143 ++++++++++++++++++++---------------------
 1 file changed, 71 insertions(+), 72 deletions(-)

diff --git a/xen/include/xen/list.h b/xen/include/xen/list.h
index b5eab3a1eb6c..6506ac40893b 100644
--- a/xen/include/xen/list.h
+++ b/xen/include/xen/list.h
@@ -452,7 +452,7 @@ static inline void list_splice_init(struct list_head *list,
  * @head:    the head for your list.
  */
 #define list_for_each(pos, head)                                        \
-    for (pos = (head)->next; pos != (head); pos = pos->next)
+    for ((pos) = (head)->next; (pos) != (head); (pos) = (pos)->next)
 
 /**
  * list_for_each_prev - iterate over a list backwards
@@ -460,7 +460,7 @@ static inline void list_splice_init(struct list_head *list,
  * @head:   the head for your list.
  */
 #define list_for_each_prev(pos, head)                                   \
-    for (pos = (head)->prev; pos != (head); pos = pos->prev)
+    for ((pos) = (head)->prev; (pos) != (head); (pos) = (pos)->prev)
 
 /**
  * list_for_each_safe - iterate over a list safe against removal of list entry
@@ -468,9 +468,9 @@ static inline void list_splice_init(struct list_head *list,
  * @n:      another &struct list_head to use as temporary storage
  * @head:   the head for your list.
  */
-#define list_for_each_safe(pos, n, head)                        \
-    for (pos = (head)->next, n = pos->next; pos != (head);      \
-         pos = n, n = pos->next)
+#define list_for_each_safe(pos, n, head)                                \
+    for ((pos) = (head)->next, (n) = (pos)->next; (pos) != (head);      \
+         (pos) = (n), (n) = (pos)->next)
 
 /**
  * list_for_each_backwards_safe    -    iterate backwards over a list safe
@@ -479,9 +479,9 @@ static inline void list_splice_init(struct list_head *list,
  * @n:      another &struct list_head to use as temporary storage
  * @head:   the head for your list.
  */
-#define list_for_each_backwards_safe(pos, n, head)              \
-    for ( pos = (head)->prev, n = pos->prev; pos != (head);     \
-          pos = n, n = pos->prev )
+#define list_for_each_backwards_safe(pos, n, head)                   \
+    for ( (pos) = (head)->prev, (n) = (pos)->prev; (pos) != (head);  \
+          (pos) = (n), (n) = (pos)->prev )
 
 /**
  * list_for_each_entry - iterate over list of given type
@@ -490,9 +490,9 @@ static inline void list_splice_init(struct list_head *list,
  * @member: the name of the list_struct within the struct.
  */
 #define list_for_each_entry(pos, head, member)                          \
-    for (pos = list_entry((head)->next, typeof(*pos), member);          \
-         &pos->member != (head);                                        \
-         pos = list_entry(pos->member.next, typeof(*pos), member))
+    for ((pos) = list_entry((head)->next, typeof(*(pos)), member);      \
+         &(pos)->member != (head);                                      \
+         (pos) = list_entry((pos)->member.next, typeof(*(pos)), member))
 
 /**
  * list_for_each_entry_reverse - iterate backwards over list of given type.
@@ -501,9 +501,9 @@ static inline void list_splice_init(struct list_head *list,
  * @member: the name of the list_struct within the struct.
  */
 #define list_for_each_entry_reverse(pos, head, member)                  \
-    for (pos = list_entry((head)->prev, typeof(*pos), member);          \
-         &pos->member != (head);                                        \
-         pos = list_entry(pos->member.prev, typeof(*pos), member))
+    for ((pos) = list_entry((head)->prev, typeof(*(pos)), member);      \
+         &(pos)->member != (head);                                      \
+         (pos) = list_entry((pos)->member.prev, typeof(*(pos)), member))
 
 /**
  * list_prepare_entry - prepare a pos entry for use in
@@ -516,7 +516,7 @@ static inline void list_splice_init(struct list_head *list,
  * list_for_each_entry_continue.
  */
 #define list_prepare_entry(pos, head, member)           \
-    ((pos) ? : list_entry(head, typeof(*pos), member))
+    ((pos) ? : list_entry(head, typeof(*(pos)), member))
 
 /**
  * list_for_each_entry_continue - continue iteration over list of given type
@@ -527,10 +527,10 @@ static inline void list_splice_init(struct list_head *list,
  * Continue to iterate over list of given type, continuing after
  * the current position.
  */
-#define list_for_each_entry_continue(pos, head, member)                 \
-    for (pos = list_entry(pos->member.next, typeof(*pos), member);      \
-         &pos->member != (head);                                        \
-         pos = list_entry(pos->member.next, typeof(*pos), member))
+#define list_for_each_entry_continue(pos, head, member)                   \
+    for ((pos) = list_entry((pos)->member.next, typeof(*(pos)), member);  \
+         &(pos)->member != (head);                                        \
+         (pos) = list_entry((pos)->member.next, typeof(*(pos)), member))
 
 /**
  * list_for_each_entry_from - iterate over list of given type from the
@@ -542,8 +542,8 @@ static inline void list_splice_init(struct list_head *list,
  * Iterate over list of given type, continuing from current position.
  */
 #define list_for_each_entry_from(pos, head, member)                     \
-    for (; &pos->member != (head);                                      \
-         pos = list_entry(pos->member.next, typeof(*pos), member))
+    for (; &(pos)->member != (head);                                    \
+         (pos) = list_entry((pos)->member.next, typeof(*(pos)), member))
 
 /**
  * list_for_each_entry_safe - iterate over list of given type safe
@@ -554,10 +554,10 @@ static inline void list_splice_init(struct list_head *list,
  * @member: the name of the list_struct within the struct.
  */
 #define list_for_each_entry_safe(pos, n, head, member)                  \
-    for (pos = list_entry((head)->next, typeof(*pos), member),          \
-         n = list_entry(pos->member.next, typeof(*pos), member);        \
-         &pos->member != (head);                                        \
-         pos = n, n = list_entry(n->member.next, typeof(*n), member))
+    for ((pos) = list_entry((head)->next, typeof(*(pos)), member),      \
+         (n) = list_entry((pos)->member.next, typeof(*(pos)), member);  \
+         &(pos)->member != (head);                                      \
+         (pos) = (n), (n) = list_entry((n)->member.next, typeof(*(n)), member))
 
 /**
  * list_for_each_entry_safe_continue
@@ -569,11 +569,11 @@ static inline void list_splice_init(struct list_head *list,
  * Iterate over list of given type, continuing after current point,
  * safe against removal of list entry.
  */
-#define list_for_each_entry_safe_continue(pos, n, head, member)         \
-    for (pos = list_entry(pos->member.next, typeof(*pos), member),      \
-         n = list_entry(pos->member.next, typeof(*pos), member);        \
-         &pos->member != (head);                                        \
-         pos = n, n = list_entry(n->member.next, typeof(*n), member))
+#define list_for_each_entry_safe_continue(pos, n, head, member)           \
+    for ((pos) = list_entry((pos)->member.next, typeof(*(pos)), member),  \
+         (n) = list_entry((pos)->member.next, typeof(*(pos)), member);    \
+         &(pos)->member != (head);                                        \
+         (pos) = (n), (n) = list_entry((n)->member.next, typeof(*(n)), member))
 
 /**
  * list_for_each_entry_safe_from
@@ -586,9 +586,9 @@ static inline void list_splice_init(struct list_head *list,
  * removal of list entry.
  */
 #define list_for_each_entry_safe_from(pos, n, head, member)             \
-    for (n = list_entry(pos->member.next, typeof(*pos), member);        \
-         &pos->member != (head);                                        \
-         pos = n, n = list_entry(n->member.next, typeof(*n), member))
+    for ((n) = list_entry((pos)->member.next, typeof(*(pos)), member);  \
+         &(pos)->member != (head);                                      \
+         (pos) = (n), (n) = list_entry((n)->member.next, typeof(*(n)), member))
 
 /**
  * list_for_each_entry_safe_reverse
@@ -601,10 +601,10 @@ static inline void list_splice_init(struct list_head *list,
  * of list entry.
  */
 #define list_for_each_entry_safe_reverse(pos, n, head, member)          \
-    for (pos = list_entry((head)->prev, typeof(*pos), member),          \
-         n = list_entry(pos->member.prev, typeof(*pos), member);        \
-         &pos->member != (head);                                        \
-         pos = n, n = list_entry(n->member.prev, typeof(*n), member))
+    for ((pos) = list_entry((head)->prev, typeof(*(pos)), member),      \
+         (n) = list_entry((pos)->member.prev, typeof(*(pos)), member);  \
+         &(pos)->member != (head);                                      \
+         (pos) = (n), (n) = list_entry((n)->member.prev, typeof(*(n)), member))
 
 /**
  * list_for_each_rcu - iterate over an rcu-protected list
@@ -616,14 +616,14 @@ static inline void list_splice_init(struct list_head *list,
  * as long as the traversal is guarded by rcu_read_lock().
  */
 #define list_for_each_rcu(pos, head)                            \
-    for (pos = (head)->next;                                    \
+    for ((pos) = (head)->next;                                  \
          rcu_dereference(pos) != (head);                        \
-         pos = pos->next)
+         (pos) = (pos)->next)
 
 #define __list_for_each_rcu(pos, head)          \
-    for (pos = (head)->next;                    \
+    for ((pos) = (head)->next;                  \
          rcu_dereference(pos) != (head);        \
-         pos = pos->next)
+         (pos) = (pos)->next)
 
 /**
  * list_for_each_safe_rcu
@@ -638,9 +638,9 @@ static inline void list_splice_init(struct list_head *list,
  * as long as the traversal is guarded by rcu_read_lock().
  */
 #define list_for_each_safe_rcu(pos, n, head)            \
-    for (pos = (head)->next;                            \
-         n = rcu_dereference(pos)->next, pos != (head); \
-         pos = n)
+    for ((pos) = (head)->next;                          \
+         (n) = rcu_dereference(pos)->next, (pos) != (head); \
+         (pos) = (n))
 
 /**
  * list_for_each_entry_rcu - iterate over rcu list of given type
@@ -653,9 +653,9 @@ static inline void list_splice_init(struct list_head *list,
  * as long as the traversal is guarded by rcu_read_lock().
  */
 #define list_for_each_entry_rcu(pos, head, member)                      \
-    for (pos = list_entry((head)->next, typeof(*pos), member);          \
+    for ((pos) = list_entry((head)->next, typeof(*(pos)), member);      \
          &rcu_dereference(pos)->member != (head);                       \
-         pos = list_entry(pos->member.next, typeof(*pos), member))
+         (pos) = list_entry((pos)->member.next, typeof(*(pos)), member))
 
 /**
  * list_for_each_continue_rcu
@@ -899,11 +899,11 @@ static inline void hlist_add_after_rcu(struct hlist_node *prev,
 #define hlist_entry(ptr, type, member) container_of(ptr,type,member)
 
 #define hlist_for_each(pos, head)                                       \
-    for (pos = (head)->first; pos; pos = pos->next)
+    for ((pos) = (head)->first; (pos); (pos) = (pos)->next)
 
-#define hlist_for_each_safe(pos, n, head)                       \
-    for (pos = (head)->first; pos && ({ n = pos->next; 1; });   \
-         pos = n)
+#define hlist_for_each_safe(pos, n, head)                               \
+    for ((pos) = (head)->first; (pos) && ({ (n) = (pos)->next; 1; });   \
+         (pos) = (n))
 
 /**
  * hlist_for_each_entry    - iterate over list of given type
@@ -913,10 +913,10 @@ static inline void hlist_add_after_rcu(struct hlist_node *prev,
  * @member:    the name of the hlist_node within the struct.
  */
 #define hlist_for_each_entry(tpos, pos, head, member)                   \
-    for (pos = (head)->first;                                           \
-         pos &&                                                         \
-         ({ tpos = hlist_entry(pos, typeof(*tpos), member); 1;});       \
-         pos = pos->next)
+    for ((pos) = (head)->first;                                         \
+         (pos) &&                                                       \
+         ({ tpos = hlist_entry(pos, typeof(*(tpos)), member); 1;});     \
+         (pos) = (pos)->next)
 
 /**
  * hlist_for_each_entry_continue - iterate over a hlist continuing
@@ -925,11 +925,11 @@ static inline void hlist_add_after_rcu(struct hlist_node *prev,
  * @pos:    the &struct hlist_node to use as a loop cursor.
  * @member:    the name of the hlist_node within the struct.
  */
-#define hlist_for_each_entry_continue(tpos, pos, member)                \
-    for (pos = (pos)->next;                                             \
-         pos &&                                                         \
-         ({ tpos = hlist_entry(pos, typeof(*tpos), member); 1;});       \
-         pos = pos->next)
+#define hlist_for_each_entry_continue(tpos, pos, member)                  \
+    for ((pos) = (pos)->next;                                             \
+         (pos) &&                                                         \
+         ({ tpos = hlist_entry(pos, typeof(*(tpos)), member); 1;});       \
+         (pos) = (pos)->next)
 
 /**
  * hlist_for_each_entry_from - iterate over a hlist continuing from
@@ -938,10 +938,10 @@ static inline void hlist_add_after_rcu(struct hlist_node *prev,
  * @pos:    the &struct hlist_node to use as a loop cursor.
  * @member:    the name of the hlist_node within the struct.
  */
-#define hlist_for_each_entry_from(tpos, pos, member)                    \
-    for (; pos &&                                                       \
-         ({ tpos = hlist_entry(pos, typeof(*tpos), member); 1;});       \
-         pos = pos->next)
+#define hlist_for_each_entry_from(tpos, pos, member)                      \
+    for (; (pos) &&                                                       \
+         ({ tpos = hlist_entry(pos, typeof(*(tpos)), member); 1;});       \
+         (pos) = (pos)->next)
 
 /**
  * hlist_for_each_entry_safe - iterate over list of given type safe
@@ -952,11 +952,11 @@ static inline void hlist_add_after_rcu(struct hlist_node *prev,
  * @head:    the head for your list.
  * @member:    the name of the hlist_node within the struct.
  */
-#define hlist_for_each_entry_safe(tpos, pos, n, head, member)           \
-    for (pos = (head)->first;                                           \
-         pos && ({ n = pos->next; 1; }) &&                              \
-         ({ tpos = hlist_entry(pos, typeof(*tpos), member); 1;});       \
-         pos = n)
+#define hlist_for_each_entry_safe(tpos, pos, n, head, member)             \
+    for ((pos) = (head)->first;                                           \
+         (pos) && ({ n = (pos)->next; 1; }) &&                            \
+         ({ tpos = hlist_entry(pos, typeof(*(tpos)), member); 1;});       \
+         (pos) = (n))
 
 
 /**
@@ -971,10 +971,9 @@ static inline void hlist_add_after_rcu(struct hlist_node *prev,
  * as long as the traversal is guarded by rcu_read_lock().
  */
 #define hlist_for_each_entry_rcu(tpos, pos, head, member)               \
-     for (pos = (head)->first;                                          \
+     for ((pos) = (head)->first;                                        \
           rcu_dereference(pos) &&                                       \
-          ({ tpos = hlist_entry(pos, typeof(*tpos), member); 1;});      \
-          pos = pos->next)
+          ({ tpos = hlist_entry(pos, typeof(*(tpos)), member); 1;});    \
+          (pos) = (pos)->next)
 
 #endif /* __XEN_LIST_H__ */
-
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Mar 22 16:02:15 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Mar 2024 16:02:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696957.1088250 (Exim 4.92)
	(envelope-from )
	id 1rnhLS-0002Az-PJ; Fri, 22 Mar 2024 16:02:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696957.1088250; Fri, 22 Mar 2024 16:02:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnhLS-0002AK-Kv; Fri, 22 Mar 2024 16:02:14 +0000
Received: by outflank-mailman (input) for mailman id 696957;
 Fri, 22 Mar 2024 16:02:13 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rnhLR-0000W5-62
 for xen-devel@lists.xenproject.org; Fri, 22 Mar 2024 16:02:13 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8af4cae7-e865-11ee-a1ee-f123f15fe8a2;
 Fri, 22 Mar 2024 17:02:11 +0100 (CET)
Received: from nico.bugseng.com (unknown [46.228.253.194])
 by support.bugseng.com (Postfix) with ESMTPSA id EB4364EE074B;
 Fri, 22 Mar 2024 17:02:10 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8af4cae7-e865-11ee-a1ee-f123f15fe8a2
From: Nicola Vetrini 
To: nicola.vetrini@bugseng.com,
	xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org,
	michal.orzel@amd.com,
	xenia.ragiadakou@amd.com,
	ayan.kumar.halder@amd.com,
	consulting@bugseng.com,
	jbeulich@suse.com,
	andrew.cooper3@citrix.com,
	roger.pau@citrix.com,
	bertrand.marquis@arm.com,
	julien@xen.org,
	George Dunlap 
Subject: [XEN PATCH 07/11] xen/page_alloc: address violations of MISRA C Rule 20.7
Date: Fri, 22 Mar 2024 17:01:56 +0100
Message-Id: 
X-Mailer: git-send-email 2.34.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter the semantics of the passed-in macro parameter.

No functional change.

Signed-off-by: Nicola Vetrini 
---
 xen/common/page_alloc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 28c510d6669b..82dc55829f78 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -150,7 +150,7 @@
 #include 
 #else
 #define p2m_pod_offline_or_broken_hit(pg) 0
-#define p2m_pod_offline_or_broken_replace(pg) BUG_ON(pg != NULL)
+#define p2m_pod_offline_or_broken_replace(pg) BUG_ON((pg) != NULL)
 #endif
 
 #ifndef PGC_static
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Mar 22 16:02:15 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Mar 2024 16:02:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696950.1088181 (Exim 4.92)
	(envelope-from )
	id 1rnhLN-0000WW-KF; Fri, 22 Mar 2024 16:02:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696950.1088181; Fri, 22 Mar 2024 16:02:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnhLN-0000WN-GF; Fri, 22 Mar 2024 16:02:09 +0000
Received: by outflank-mailman (input) for mailman id 696950;
 Fri, 22 Mar 2024 16:02:07 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rnhLL-0000W5-OI
 for xen-devel@lists.xenproject.org; Fri, 22 Mar 2024 16:02:07 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 87438b5f-e865-11ee-a1ee-f123f15fe8a2;
 Fri, 22 Mar 2024 17:02:05 +0100 (CET)
Received: from nico.bugseng.com (unknown [46.228.253.194])
 by support.bugseng.com (Postfix) with ESMTPSA id 6171E4EE0742;
 Fri, 22 Mar 2024 17:02:03 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 87438b5f-e865-11ee-a1ee-f123f15fe8a2
From: Nicola Vetrini 
To: nicola.vetrini@bugseng.com,
	xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org,
	michal.orzel@amd.com,
	xenia.ragiadakou@amd.com,
	ayan.kumar.halder@amd.com,
	consulting@bugseng.com,
	jbeulich@suse.com,
	andrew.cooper3@citrix.com,
	roger.pau@citrix.com,
	bertrand.marquis@arm.com,
	julien@xen.org,
	George Dunlap ,
	"Daniel P. Smith" ,
	Volodymyr Babchuk 
Subject: [XEN PATCH 00/11] address some violations of MISRA C Rule 20.7
Date: Fri, 22 Mar 2024 17:01:49 +0100
Message-Id: 
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Hi all,

this series aims to refactor some macros that cause violations of MISRA C Rule
20.7 ("Expressions resulting from the expansion of macro parameters shall be
enclosed in parentheses"). All the macros touched by these patches are in some
way involved in violations, and the strategy adopted to bring them into
compliance is to add parentheses around macro arguments where needed.

Given that the community has previously requested a deviation from the rule, as
stated in docs/misra/deviations.rst, and reported below for convenience [1],
some macro parameters do not need any adjusting (e.g., when used as lhs to
an assignment in statement expressions).

Patch 1 is taken, with adjustments, from [2]. Patches 2 and 3 are taken from [3]
without any modifications. All other patches are new in this series and are
pairwise indipendent.

[1] - Code violating Rule 20.7 is safe when macro parameters are used:
       (1) as function arguments;
       (2) as macro arguments;
       (3) as array indices;
       (4) as lhs in assignments.

[2] https://lore.kernel.org/xen-devel/b93a64b93ef4210f5fe96368c2522e5e71e9c87c.1709896401.git.nicola.vetrini@bugseng.com/
[3] https://lore.kernel.org/xen-devel/cover.1710762555.git.nicola.vetrini@bugseng.com/

Nicola Vetrini (11):
  xen/list: address violations of MISRA C Rule 20.7
  xen/xsm: add parentheses to comply with MISRA C Rule 20.7
  xen/efi: efibind: address violations of MISRA C Rule 20.7
  xentrace: address violation of MISRA C Rule 20.7
  xen: address MISRA C Rule 20.7 violation in generated hypercall
  xen/efi: address violations of MISRA C Rule 20.7
  xen/page_alloc: address violations of MISRA C Rule 20.7
  x86/altcall: address violations of MISRA C Rule 20.7
  x86/msi: address violation of MISRA C Rule 20.7 and coding style
  x86/hvm: address violations of Rule 20.7
  x86/public: hvm: address violations of MISRA C Rule 20.7

 xen/arch/arm/include/asm/arm64/efibind.h  |   4 +-
 xen/arch/x86/hvm/hvm.c                    |   6 +-
 xen/arch/x86/include/asm/alternative.h    |  76 ++++++------
 xen/arch/x86/include/asm/hvm/save.h       |   4 +-
 xen/arch/x86/include/asm/msi.h            |  47 +++----
 xen/arch/x86/include/asm/x86_64/efibind.h |   4 +-
 xen/common/page_alloc.c                   |   2 +-
 xen/include/efi/efiapi.h                  |   3 +-
 xen/include/public/arch-x86/xen.h         |   2 +-
 xen/include/public/trace.h                |   2 +-
 xen/include/xen/list.h                    | 143 +++++++++++-----------
 xen/include/xsm/dummy.h                   |   4 +-
 xen/scripts/gen_hypercall.awk             |   4 +-
 13 files changed, 151 insertions(+), 150 deletions(-)

-- 
2.34.1


From xen-devel-bounces@lists.xenproject.org Fri Mar 22 16:02:15 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Mar 2024 16:02:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696956.1088236 (Exim 4.92)
	(envelope-from )
	id 1rnhLR-0001kL-GQ; Fri, 22 Mar 2024 16:02:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696956.1088236; Fri, 22 Mar 2024 16:02:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnhLR-0001jR-9e; Fri, 22 Mar 2024 16:02:13 +0000
Received: by outflank-mailman (input) for mailman id 696956;
 Fri, 22 Mar 2024 16:02:12 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rnhLQ-0000WB-DO
 for xen-devel@lists.xenproject.org; Fri, 22 Mar 2024 16:02:12 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8a922712-e865-11ee-afe0-a90da7624cb6;
 Fri, 22 Mar 2024 17:02:11 +0100 (CET)
Received: from nico.bugseng.com (unknown [46.228.253.194])
 by support.bugseng.com (Postfix) with ESMTPSA id 521E24EE0C92;
 Fri, 22 Mar 2024 17:02:10 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8a922712-e865-11ee-afe0-a90da7624cb6
From: Nicola Vetrini 
To: nicola.vetrini@bugseng.com,
	xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org,
	michal.orzel@amd.com,
	xenia.ragiadakou@amd.com,
	ayan.kumar.halder@amd.com,
	consulting@bugseng.com,
	jbeulich@suse.com,
	andrew.cooper3@citrix.com,
	roger.pau@citrix.com,
	bertrand.marquis@arm.com,
	julien@xen.org
Subject: [XEN PATCH 06/11] xen/efi: address violations of MISRA C Rule 20.7
Date: Fri, 22 Mar 2024 17:01:55 +0100
Message-Id: <2d3842a990189c37fa12672994b779ad42975235.1711118582.git.nicola.vetrini@bugseng.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter the semantics of the passed-in macro parameter.

No functional change.

Signed-off-by: Nicola Vetrini 
---
 xen/include/efi/efiapi.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/xen/include/efi/efiapi.h b/xen/include/efi/efiapi.h
index a616d1238aa4..6d4d4e340d9e 100644
--- a/xen/include/efi/efiapi.h
+++ b/xen/include/efi/efiapi.h
@@ -63,7 +63,8 @@ EFI_STATUS
     OUT UINT32                      *DescriptorVersion
     );
 
-#define NextMemoryDescriptor(Ptr,Size)  ((EFI_MEMORY_DESCRIPTOR *) (((UINT8 *) Ptr) + Size))
+#define NextMemoryDescriptor(Ptr,Size)  ((EFI_MEMORY_DESCRIPTOR *) \
+                                         ((UINT8 *)(Ptr) + (Size)))
 
 
 typedef
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Mar 22 16:02:15 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Mar 2024 16:02:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696955.1088231 (Exim 4.92)
	(envelope-from )
	id 1rnhLR-0001h6-3p; Fri, 22 Mar 2024 16:02:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696955.1088231; Fri, 22 Mar 2024 16:02:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnhLR-0001gF-0i; Fri, 22 Mar 2024 16:02:13 +0000
Received: by outflank-mailman (input) for mailman id 696955;
 Fri, 22 Mar 2024 16:02:12 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rnhLP-0000W5-V7
 for xen-devel@lists.xenproject.org; Fri, 22 Mar 2024 16:02:11 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8a331fa7-e865-11ee-a1ee-f123f15fe8a2;
 Fri, 22 Mar 2024 17:02:10 +0100 (CET)
Received: from nico.bugseng.com (unknown [46.228.253.194])
 by support.bugseng.com (Postfix) with ESMTPSA id A7A714EE0C91;
 Fri, 22 Mar 2024 17:02:09 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8a331fa7-e865-11ee-a1ee-f123f15fe8a2
From: Nicola Vetrini 
To: nicola.vetrini@bugseng.com,
	xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org,
	michal.orzel@amd.com,
	xenia.ragiadakou@amd.com,
	ayan.kumar.halder@amd.com,
	consulting@bugseng.com,
	jbeulich@suse.com,
	andrew.cooper3@citrix.com,
	roger.pau@citrix.com,
	bertrand.marquis@arm.com,
	julien@xen.org,
	George Dunlap 
Subject: [XEN PATCH 05/11] xen: address MISRA C Rule 20.7 violation in generated hypercall
Date: Fri, 22 Mar 2024 17:01:54 +0100
Message-Id: <323c77d56f8dcbd6bf8f60c84aacff162265807e.1711118582.git.nicola.vetrini@bugseng.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter the semantics of the passed-in macro parameter.

No functional change.

Signed-off-by: Nicola Vetrini 
---
 xen/scripts/gen_hypercall.awk | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/scripts/gen_hypercall.awk b/xen/scripts/gen_hypercall.awk
index 9f7cfa298a6d..1a7e051fde10 100644
--- a/xen/scripts/gen_hypercall.awk
+++ b/xen/scripts/gen_hypercall.awk
@@ -277,7 +277,7 @@ END {
                         if (call[i] == ca && call_prio[i] == p_list[pl]) {
                             fnd++;
                             if (fnd == 1)
-                                printf("        if ( num == __HYPERVISOR_%s ) \\\n", fn[call_fn[i]]);
+                                printf("        if ( (num) == __HYPERVISOR_%s ) \\\n", fn[call_fn[i]]);
                             else
                                 printf("        else \\\n");
                             do_call(call_fn[i], call_p[i]);
@@ -290,7 +290,7 @@ END {
             } else {
                 for (i = 1; i <= nc; i++)
                     if (call[i] == ca && call_prio[i] == p_list[pl]) {
-                        printf("if ( likely(num == __HYPERVISOR_%s) ) \\\n", fn[call_fn[i]]);
+                        printf("if ( likely((num) == __HYPERVISOR_%s) ) \\\n", fn[call_fn[i]]);
                         do_call(call_fn[i], call_p[i]);
                     }
             }
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Mar 22 16:02:15 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Mar 2024 16:02:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696958.1088257 (Exim 4.92)
	(envelope-from )
	id 1rnhLT-0002Hn-EJ; Fri, 22 Mar 2024 16:02:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696958.1088257; Fri, 22 Mar 2024 16:02:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnhLT-0002Fd-4m; Fri, 22 Mar 2024 16:02:15 +0000
Received: by outflank-mailman (input) for mailman id 696958;
 Fri, 22 Mar 2024 16:02:14 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rnhLS-0000W5-0a
 for xen-devel@lists.xenproject.org; Fri, 22 Mar 2024 16:02:14 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8b547583-e865-11ee-a1ee-f123f15fe8a2;
 Fri, 22 Mar 2024 17:02:12 +0100 (CET)
Received: from nico.bugseng.com (unknown [46.228.253.194])
 by support.bugseng.com (Postfix) with ESMTPSA id 961B34EE0C94;
 Fri, 22 Mar 2024 17:02:11 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8b547583-e865-11ee-a1ee-f123f15fe8a2
From: Nicola Vetrini 
To: nicola.vetrini@bugseng.com,
	xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org,
	michal.orzel@amd.com,
	xenia.ragiadakou@amd.com,
	ayan.kumar.halder@amd.com,
	consulting@bugseng.com,
	jbeulich@suse.com,
	andrew.cooper3@citrix.com,
	roger.pau@citrix.com,
	bertrand.marquis@arm.com,
	julien@xen.org
Subject: [XEN PATCH 08/11] x86/altcall: address violations of MISRA C Rule 20.7
Date: Fri, 22 Mar 2024 17:01:57 +0100
Message-Id: <653ead65966226f50b0e4ae0268912c9710f9dba.1711118582.git.nicola.vetrini@bugseng.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter the semantics of the passed-in macro parameter.

No functional change.

Signed-off-by: Nicola Vetrini 
---
 xen/arch/x86/include/asm/alternative.h | 76 +++++++++++++-------------
 1 file changed, 38 insertions(+), 38 deletions(-)

diff --git a/xen/arch/x86/include/asm/alternative.h b/xen/arch/x86/include/asm/alternative.h
index 0d3697f1de49..a3b7cbab8740 100644
--- a/xen/arch/x86/include/asm/alternative.h
+++ b/xen/arch/x86/include/asm/alternative.h
@@ -243,28 +243,28 @@ extern void alternative_branches(void);
 
 #define alternative_vcall0(func) ({             \
     ALT_CALL_NO_ARG1;                           \
-    (void)sizeof(func());                       \
+    (void)sizeof((func)());                     \
     (void)alternative_callN(0, int, func);      \
 })
 
-#define alternative_call0(func) ({              \
-    ALT_CALL_NO_ARG1;                           \
-    alternative_callN(0, typeof(func()), func); \
+#define alternative_call0(func) ({                \
+    ALT_CALL_NO_ARG1;                             \
+    alternative_callN(0, typeof((func)()), func); \
 })
 
 #define alternative_vcall1(func, arg) ({           \
     typeof(arg) v1_ = (arg);                       \
     ALT_CALL_ARG(v1_, 1);                          \
     ALT_CALL_NO_ARG2;                              \
-    (void)sizeof(func(arg));                       \
+    (void)sizeof((func)(arg));                     \
     (void)alternative_callN(1, int, func);         \
 })
 
-#define alternative_call1(func, arg) ({            \
-    typeof(arg) v1_ = (arg);                       \
-    ALT_CALL_ARG(v1_, 1);                          \
-    ALT_CALL_NO_ARG2;                              \
-    alternative_callN(1, typeof(func(arg)), func); \
+#define alternative_call1(func, arg) ({              \
+    typeof(arg) v1_ = (arg);                         \
+    ALT_CALL_ARG(v1_, 1);                            \
+    ALT_CALL_NO_ARG2;                                \
+    alternative_callN(1, typeof((func)(arg)), func); \
 })
 
 #define alternative_vcall2(func, arg1, arg2) ({           \
@@ -273,17 +273,17 @@ extern void alternative_branches(void);
     ALT_CALL_ARG(v1_, 1);                                 \
     ALT_CALL_ARG(v2_, 2);                                 \
     ALT_CALL_NO_ARG3;                                     \
-    (void)sizeof(func(arg1, arg2));                       \
+    (void)sizeof((func)(arg1, arg2));                     \
     (void)alternative_callN(2, int, func);                \
 })
 
-#define alternative_call2(func, arg1, arg2) ({            \
-    typeof(arg1) v1_ = (arg1);                            \
-    typeof(arg2) v2_ = (arg2);                            \
-    ALT_CALL_ARG(v1_, 1);                                 \
-    ALT_CALL_ARG(v2_, 2);                                 \
-    ALT_CALL_NO_ARG3;                                     \
-    alternative_callN(2, typeof(func(arg1, arg2)), func); \
+#define alternative_call2(func, arg1, arg2) ({              \
+    typeof(arg1) v1_ = (arg1);                              \
+    typeof(arg2) v2_ = (arg2);                              \
+    ALT_CALL_ARG(v1_, 1);                                   \
+    ALT_CALL_ARG(v2_, 2);                                   \
+    ALT_CALL_NO_ARG3;                                       \
+    alternative_callN(2, typeof((func)(arg1, arg2)), func); \
 })
 
 #define alternative_vcall3(func, arg1, arg2, arg3) ({    \
@@ -294,20 +294,20 @@ extern void alternative_branches(void);
     ALT_CALL_ARG(v2_, 2);                                \
     ALT_CALL_ARG(v3_, 3);                                \
     ALT_CALL_NO_ARG4;                                    \
-    (void)sizeof(func(arg1, arg2, arg3));                \
+    (void)sizeof((func)(arg1, arg2, arg3));              \
     (void)alternative_callN(3, int, func);               \
 })
 
-#define alternative_call3(func, arg1, arg2, arg3) ({     \
-    typeof(arg1) v1_ = (arg1);                            \
-    typeof(arg2) v2_ = (arg2);                           \
-    typeof(arg3) v3_ = (arg3);                           \
-    ALT_CALL_ARG(v1_, 1);                                \
-    ALT_CALL_ARG(v2_, 2);                                \
-    ALT_CALL_ARG(v3_, 3);                                \
-    ALT_CALL_NO_ARG4;                                    \
-    alternative_callN(3, typeof(func(arg1, arg2, arg3)), \
-                      func);                             \
+#define alternative_call3(func, arg1, arg2, arg3) ({       \
+    typeof(arg1) v1_ = (arg1);                             \
+    typeof(arg2) v2_ = (arg2);                             \
+    typeof(arg3) v3_ = (arg3);                             \
+    ALT_CALL_ARG(v1_, 1);                                  \
+    ALT_CALL_ARG(v2_, 2);                                  \
+    ALT_CALL_ARG(v3_, 3);                                  \
+    ALT_CALL_NO_ARG4;                                      \
+    alternative_callN(3, typeof((func)(arg1, arg2, arg3)), \
+                      func);                               \
 })
 
 #define alternative_vcall4(func, arg1, arg2, arg3, arg4) ({ \
@@ -320,7 +320,7 @@ extern void alternative_branches(void);
     ALT_CALL_ARG(v3_, 3);                                   \
     ALT_CALL_ARG(v4_, 4);                                   \
     ALT_CALL_NO_ARG5;                                       \
-    (void)sizeof(func(arg1, arg2, arg3, arg4));             \
+    (void)sizeof((func)(arg1, arg2, arg3, arg4));           \
     (void)alternative_callN(4, int, func);                  \
 })
 
@@ -334,8 +334,8 @@ extern void alternative_branches(void);
     ALT_CALL_ARG(v3_, 3);                                   \
     ALT_CALL_ARG(v4_, 4);                                   \
     ALT_CALL_NO_ARG5;                                       \
-    alternative_callN(4, typeof(func(arg1, arg2,            \
-                                     arg3, arg4)),          \
+    alternative_callN(4, typeof((func)(arg1, arg2,          \
+                                       arg3, arg4)),        \
                       func);                                \
 })
 
@@ -351,7 +351,7 @@ extern void alternative_branches(void);
     ALT_CALL_ARG(v4_, 4);                                         \
     ALT_CALL_ARG(v5_, 5);                                         \
     ALT_CALL_NO_ARG6;                                             \
-    (void)sizeof(func(arg1, arg2, arg3, arg4, arg5));             \
+    (void)sizeof((func)(arg1, arg2, arg3, arg4, arg5));           \
     (void)alternative_callN(5, int, func);                        \
 })
 
@@ -367,8 +367,8 @@ extern void alternative_branches(void);
     ALT_CALL_ARG(v4_, 4);                                         \
     ALT_CALL_ARG(v5_, 5);                                         \
     ALT_CALL_NO_ARG6;                                             \
-    alternative_callN(5, typeof(func(arg1, arg2, arg3,            \
-                                     arg4, arg5)),                \
+    alternative_callN(5, typeof((func)(arg1, arg2, arg3,          \
+                                       arg4, arg5)),              \
                       func);                                      \
 })
 
@@ -385,7 +385,7 @@ extern void alternative_branches(void);
     ALT_CALL_ARG(v4_, 4);                                               \
     ALT_CALL_ARG(v5_, 5);                                               \
     ALT_CALL_ARG(v6_, 6);                                               \
-    (void)sizeof(func(arg1, arg2, arg3, arg4, arg5, arg6));             \
+    (void)sizeof((func)(arg1, arg2, arg3, arg4, arg5, arg6));           \
     (void)alternative_callN(6, int, func);                              \
 })
 
@@ -402,8 +402,8 @@ extern void alternative_branches(void);
     ALT_CALL_ARG(v4_, 4);                                               \
     ALT_CALL_ARG(v5_, 5);                                               \
     ALT_CALL_ARG(v6_, 6);                                               \
-    alternative_callN(6, typeof(func(arg1, arg2, arg3,                  \
-                                     arg4, arg5, arg6)),                \
+    alternative_callN(6, typeof((func)(arg1, arg2, arg3,                \
+                                       arg4, arg5, arg6)),              \
                       func);                                            \
 })
 
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Mar 22 16:02:15 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Mar 2024 16:02:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696953.1088211 (Exim 4.92)
	(envelope-from )
	id 1rnhLP-0001DV-Ke; Fri, 22 Mar 2024 16:02:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696953.1088211; Fri, 22 Mar 2024 16:02:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnhLP-0001DO-Fh; Fri, 22 Mar 2024 16:02:11 +0000
Received: by outflank-mailman (input) for mailman id 696953;
 Fri, 22 Mar 2024 16:02:10 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rnhLO-0000WB-Cy
 for xen-devel@lists.xenproject.org; Fri, 22 Mar 2024 16:02:10 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 896d218f-e865-11ee-afe0-a90da7624cb6;
 Fri, 22 Mar 2024 17:02:09 +0100 (CET)
Received: from nico.bugseng.com (unknown [46.228.253.194])
 by support.bugseng.com (Postfix) with ESMTPSA id 32EEA4EE0C8F;
 Fri, 22 Mar 2024 17:02:08 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 896d218f-e865-11ee-afe0-a90da7624cb6
From: Nicola Vetrini 
To: nicola.vetrini@bugseng.com,
	xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org,
	michal.orzel@amd.com,
	xenia.ragiadakou@amd.com,
	ayan.kumar.halder@amd.com,
	consulting@bugseng.com,
	jbeulich@suse.com,
	andrew.cooper3@citrix.com,
	roger.pau@citrix.com,
	bertrand.marquis@arm.com,
	julien@xen.org,
	Volodymyr Babchuk 
Subject: [XEN PATCH 03/11] xen/efi: efibind: address violations of MISRA C Rule 20.7
Date: Fri, 22 Mar 2024 17:01:52 +0100
Message-Id: <9cadb45f9d200f3efbad0c5f602174728838d53e.1711118582.git.nicola.vetrini@bugseng.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter the semantics of the passed-in macro parameter.

No functional change.

Signed-off-by: Nicola Vetrini 
Acked-by: Jan Beulich 
---
This file is matched by exclude-list.json, but the fix is rather trivial
and impacts code that in under the scope of MISRA compliance.
---
 xen/arch/arm/include/asm/arm64/efibind.h  | 4 ++--
 xen/arch/x86/include/asm/x86_64/efibind.h | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/include/asm/arm64/efibind.h b/xen/arch/arm/include/asm/arm64/efibind.h
index f13eadd4f0ab..a1323d452e2e 100644
--- a/xen/arch/arm/include/asm/arm64/efibind.h
+++ b/xen/arch/arm/include/asm/arm64/efibind.h
@@ -22,9 +22,9 @@ Revision History
 #pragma pack()
 #endif
 
-#define EFIERR(a)           (0x8000000000000000ULL | a)
+#define EFIERR(a)           (0x8000000000000000ULL | (a))
 #define EFI_ERROR_MASK      0x8000000000000000ULL
-#define EFIERR_OEM(a)       (0xc000000000000000ULL | a)
+#define EFIERR_OEM(a)       (0xc000000000000000ULL | (a))
 
 #define BAD_POINTER         0xFBFBFBFBFBFBFBFBULL
 #define MAX_ADDRESS         0xFFFFFFFFFFFFFFFFULL
diff --git a/xen/arch/x86/include/asm/x86_64/efibind.h b/xen/arch/x86/include/asm/x86_64/efibind.h
index e23cd16cb6a0..28bc18c24bb3 100644
--- a/xen/arch/x86/include/asm/x86_64/efibind.h
+++ b/xen/arch/x86/include/asm/x86_64/efibind.h
@@ -117,9 +117,9 @@ typedef uint64_t   UINTN;
     #endif
 #endif
 
-#define EFIERR(a)           (0x8000000000000000 | a)
+#define EFIERR(a)           (0x8000000000000000 | (a))
 #define EFI_ERROR_MASK      0x8000000000000000
-#define EFIERR_OEM(a)       (0xc000000000000000 | a)
+#define EFIERR_OEM(a)       (0xc000000000000000 | (a))
 
 
 #define BAD_POINTER         0xFBFBFBFBFBFBFBFB
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Mar 22 16:02:17 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Mar 2024 16:02:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696959.1088270 (Exim 4.92)
	(envelope-from )
	id 1rnhLU-0002h2-Qz; Fri, 22 Mar 2024 16:02:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696959.1088270; Fri, 22 Mar 2024 16:02:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnhLU-0002gb-MG; Fri, 22 Mar 2024 16:02:16 +0000
Received: by outflank-mailman (input) for mailman id 696959;
 Fri, 22 Mar 2024 16:02:14 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rnhLS-0000WB-OF
 for xen-devel@lists.xenproject.org; Fri, 22 Mar 2024 16:02:14 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8c76c732-e865-11ee-afe0-a90da7624cb6;
 Fri, 22 Mar 2024 17:02:14 +0100 (CET)
Received: from nico.bugseng.com (unknown [46.228.253.194])
 by support.bugseng.com (Postfix) with ESMTPSA id 7267D4EE0C97;
 Fri, 22 Mar 2024 17:02:13 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8c76c732-e865-11ee-afe0-a90da7624cb6
From: Nicola Vetrini 
To: nicola.vetrini@bugseng.com,
	xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org,
	michal.orzel@amd.com,
	xenia.ragiadakou@amd.com,
	ayan.kumar.halder@amd.com,
	consulting@bugseng.com,
	jbeulich@suse.com,
	andrew.cooper3@citrix.com,
	roger.pau@citrix.com,
	bertrand.marquis@arm.com,
	julien@xen.org
Subject: [XEN PATCH 11/11] x86/public: hvm: address violations of MISRA C Rule 20.7
Date: Fri, 22 Mar 2024 17:02:00 +0100
Message-Id: 
X-Mailer: git-send-email 2.34.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter the semantics of the passed-in macro parameter.

No functional change.

Signed-off-by: Nicola Vetrini 
---
 xen/include/public/arch-x86/xen.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/include/public/arch-x86/xen.h b/xen/include/public/arch-x86/xen.h
index c0f4551247f4..a9a87d9b50de 100644
--- a/xen/include/public/arch-x86/xen.h
+++ b/xen/include/public/arch-x86/xen.h
@@ -36,7 +36,7 @@
 #define __XEN_GUEST_HANDLE(name)        __guest_handle_ ## name
 #define XEN_GUEST_HANDLE(name)          __XEN_GUEST_HANDLE(name)
 #define XEN_GUEST_HANDLE_PARAM(name)    XEN_GUEST_HANDLE(name)
-#define set_xen_guest_handle_raw(hnd, val)  do { (hnd).p = val; } while (0)
+#define set_xen_guest_handle_raw(hnd, val)  do { (hnd).p = (val); } while (0)
 #define set_xen_guest_handle(hnd, val) set_xen_guest_handle_raw(hnd, val)
 
 #if defined(__i386__)
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Mar 22 16:02:17 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Mar 2024 16:02:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696960.1088275 (Exim 4.92)
	(envelope-from )
	id 1rnhLV-0002nd-AD; Fri, 22 Mar 2024 16:02:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696960.1088275; Fri, 22 Mar 2024 16:02:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnhLV-0002l1-0m; Fri, 22 Mar 2024 16:02:17 +0000
Received: by outflank-mailman (input) for mailman id 696960;
 Fri, 22 Mar 2024 16:02:15 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rnhLS-0000W5-W0
 for xen-devel@lists.xenproject.org; Fri, 22 Mar 2024 16:02:14 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8bb2b0a1-e865-11ee-a1ee-f123f15fe8a2;
 Fri, 22 Mar 2024 17:02:12 +0100 (CET)
Received: from nico.bugseng.com (unknown [46.228.253.194])
 by support.bugseng.com (Postfix) with ESMTPSA id 38C994EE0C95;
 Fri, 22 Mar 2024 17:02:12 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8bb2b0a1-e865-11ee-a1ee-f123f15fe8a2
From: Nicola Vetrini 
To: nicola.vetrini@bugseng.com,
	xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org,
	michal.orzel@amd.com,
	xenia.ragiadakou@amd.com,
	ayan.kumar.halder@amd.com,
	consulting@bugseng.com,
	jbeulich@suse.com,
	andrew.cooper3@citrix.com,
	roger.pau@citrix.com,
	bertrand.marquis@arm.com,
	julien@xen.org
Subject: [XEN PATCH 09/11] x86/msi: address violation of MISRA C Rule 20.7 and coding style
Date: Fri, 22 Mar 2024 17:01:58 +0100
Message-Id: 
X-Mailer: git-send-email 2.34.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter the semantics of the passed-in macro parameter.

While at it, the style of these macros has been somewhat uniformed.

No functional change.

Signed-off-by: Nicola Vetrini 
---
 xen/arch/x86/include/asm/msi.h | 47 +++++++++++++++++-----------------
 1 file changed, 24 insertions(+), 23 deletions(-)

diff --git a/xen/arch/x86/include/asm/msi.h b/xen/arch/x86/include/asm/msi.h
index 997ccb87be0c..e24d46d95a02 100644
--- a/xen/arch/x86/include/asm/msi.h
+++ b/xen/arch/x86/include/asm/msi.h
@@ -147,33 +147,34 @@ int msi_free_irq(struct msi_desc *entry);
  */
 #define NR_HP_RESERVED_VECTORS 	20
 
-#define msi_control_reg(base)		(base + PCI_MSI_FLAGS)
-#define msi_lower_address_reg(base)	(base + PCI_MSI_ADDRESS_LO)
-#define msi_upper_address_reg(base)	(base + PCI_MSI_ADDRESS_HI)
-#define msi_data_reg(base, is64bit)	\
-	( (is64bit == 1) ? base+PCI_MSI_DATA_64 : base+PCI_MSI_DATA_32 )
-#define msi_mask_bits_reg(base, is64bit) \
-	( (is64bit == 1) ? base+PCI_MSI_MASK_BIT : base+PCI_MSI_MASK_BIT-4)
+#define msi_control_reg(base)        ((base) + PCI_MSI_FLAGS)
+#define msi_lower_address_reg(base)  ((base) + PCI_MSI_ADDRESS_LO)
+#define msi_upper_address_reg(base)  ((base) + PCI_MSI_ADDRESS_HI)
+#define msi_data_reg(base, is64bit) \
+    (((is64bit) == 1) ? (base) + PCI_MSI_DATA_64 : (base) + PCI_MSI_DATA_32)
+#define msi_mask_bits_reg(base, is64bit)                \
+    (((is64bit) == 1) ? (base) + PCI_MSI_MASK_BIT       \
+                      : (base) + PCI_MSI_MASK_BIT - 4)
 #define msi_pending_bits_reg(base, is64bit) \
-	((base) + PCI_MSI_MASK_BIT + ((is64bit) ? 4 : 0))
-#define msi_disable(control)		control &= ~PCI_MSI_FLAGS_ENABLE
+    ((base) + PCI_MSI_MASK_BIT + ((is64bit) ? 4 : 0))
+#define msi_disable(control) (control) &= ~PCI_MSI_FLAGS_ENABLE
 #define multi_msi_capable(control) \
-	(1 << ((control & PCI_MSI_FLAGS_QMASK) >> 1))
+    (1 << (((control) & PCI_MSI_FLAGS_QMASK) >> 1))
 #define multi_msi_enable(control, num) \
-	control |= (((fls(num) - 1) << 4) & PCI_MSI_FLAGS_QSIZE);
-#define is_64bit_address(control)	(!!(control & PCI_MSI_FLAGS_64BIT))
-#define is_mask_bit_support(control)	(!!(control & PCI_MSI_FLAGS_MASKBIT))
+    (control) |= (((fls(num) - 1) << 4) & PCI_MSI_FLAGS_QSIZE);
+#define is_64bit_address(control) (!!((control) & PCI_MSI_FLAGS_64BIT))
+#define is_mask_bit_support(control) (!!((control) & PCI_MSI_FLAGS_MASKBIT))
 #define msi_enable(control, num) multi_msi_enable(control, num); \
-	control |= PCI_MSI_FLAGS_ENABLE
-
-#define msix_control_reg(base)		(base + PCI_MSIX_FLAGS)
-#define msix_table_offset_reg(base)	(base + PCI_MSIX_TABLE)
-#define msix_pba_offset_reg(base)	(base + PCI_MSIX_PBA)
-#define msix_enable(control)	 	control |= PCI_MSIX_FLAGS_ENABLE
-#define msix_disable(control)	 	control &= ~PCI_MSIX_FLAGS_ENABLE
-#define msix_table_size(control) 	((control & PCI_MSIX_FLAGS_QSIZE)+1)
-#define msix_unmask(address)	 	(address & ~PCI_MSIX_VECTOR_BITMASK)
-#define msix_mask(address)		(address | PCI_MSIX_VECTOR_BITMASK)
+                                 (control) |= PCI_MSI_FLAGS_ENABLE
+
+#define msix_control_reg(base)       ((base) + PCI_MSIX_FLAGS)
+#define msix_table_offset_reg(base)  ((base) + PCI_MSIX_TABLE)
+#define msix_pba_offset_reg(base)    ((base) + PCI_MSIX_PBA)
+#define msix_enable(control)         (control) |= PCI_MSIX_FLAGS_ENABLE
+#define msix_disable(control)        (control) &= ~PCI_MSIX_FLAGS_ENABLE
+#define msix_table_size(control)     (((control) & PCI_MSIX_FLAGS_QSIZE) + 1)
+#define msix_unmask(address)         ((address) & ~PCI_MSIX_VECTOR_BITMASK)
+#define msix_mask(address)           ((address) | PCI_MSIX_VECTOR_BITMASK)
 
 /*
  * MSI Defined Data Structures
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Mar 22 16:02:18 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Mar 2024 16:02:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696961.1088284 (Exim 4.92)
	(envelope-from )
	id 1rnhLW-0002vv-2m; Fri, 22 Mar 2024 16:02:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696961.1088284; Fri, 22 Mar 2024 16:02:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnhLV-0002uW-Jt; Fri, 22 Mar 2024 16:02:17 +0000
Received: by outflank-mailman (input) for mailman id 696961;
 Fri, 22 Mar 2024 16:02:16 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rnhLT-0000W5-W7
 for xen-devel@lists.xenproject.org; Fri, 22 Mar 2024 16:02:15 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8c10b010-e865-11ee-a1ee-f123f15fe8a2;
 Fri, 22 Mar 2024 17:02:13 +0100 (CET)
Received: from nico.bugseng.com (unknown [46.228.253.194])
 by support.bugseng.com (Postfix) with ESMTPSA id D0A7D4EE0C93;
 Fri, 22 Mar 2024 17:02:12 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8c10b010-e865-11ee-a1ee-f123f15fe8a2
From: Nicola Vetrini 
To: nicola.vetrini@bugseng.com,
	xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org,
	michal.orzel@amd.com,
	xenia.ragiadakou@amd.com,
	ayan.kumar.halder@amd.com,
	consulting@bugseng.com,
	jbeulich@suse.com,
	andrew.cooper3@citrix.com,
	roger.pau@citrix.com,
	bertrand.marquis@arm.com,
	julien@xen.org
Subject: [XEN PATCH 10/11] x86/hvm: address violations of Rule 20.7
Date: Fri, 22 Mar 2024 17:01:59 +0100
Message-Id: 
X-Mailer: git-send-email 2.34.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter the semantics of the passed-in macro parameter.

No functional change.

Signed-off-by: Nicola Vetrini 
---
 xen/arch/x86/hvm/hvm.c              | 6 +++---
 xen/arch/x86/include/asm/hvm/save.h | 4 ++--
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index c75959588c0e..0ce45b177cf4 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1066,9 +1066,9 @@ static int cf_check hvm_load_cpu_ctxt(struct domain *d, hvm_domain_context_t *h)
     /* Older Xen versions used to save the segment arbytes directly 
      * from the VMCS on Intel hosts.  Detect this and rearrange them
      * into the struct segment_register format. */
-#define UNFOLD_ARBYTES(_r)                          \
-    if ( (_r & 0xf000) && !(_r & 0x0f00) )          \
-        _r = ((_r & 0xff) | ((_r >> 4) & 0xf00))
+#define UNFOLD_ARBYTES(_r)                              \
+    if ( ((_r) & 0xf000) && !((_r) & 0x0f00) )          \
+        (_r) = (((_r) & 0xff) | (((_r) >> 4) & 0xf00))
     UNFOLD_ARBYTES(ctxt.cs_arbytes);
     UNFOLD_ARBYTES(ctxt.ds_arbytes);
     UNFOLD_ARBYTES(ctxt.es_arbytes);
diff --git a/xen/arch/x86/include/asm/hvm/save.h b/xen/arch/x86/include/asm/hvm/save.h
index 04a47ffcc40a..2d4b591aa3e2 100644
--- a/xen/arch/x86/include/asm/hvm/save.h
+++ b/xen/arch/x86/include/asm/hvm/save.h
@@ -128,9 +128,9 @@ static int __init cf_check __hvm_register_##_x##_save_and_restore(void)   \
 {                                                                         \
     hvm_register_savevm(HVM_SAVE_CODE(_x),                                \
                         #_x,                                              \
-                        &_save,                                           \
+                        &(_save),                                         \
                         check,                                            \
-                        &_load,                                           \
+                        &(_load),                                         \
                         (_num) * (HVM_SAVE_LENGTH(_x)                     \
                                   + sizeof (struct hvm_save_descriptor)), \
                         _k);                                              \
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Mar 22 16:15:17 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Mar 2024 16:15:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.696997.1088301 (Exim 4.92)
	(envelope-from )
	id 1rnhXv-0000CC-T7; Fri, 22 Mar 2024 16:15:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 696997.1088301; Fri, 22 Mar 2024 16:15:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnhXv-0000C5-QI; Fri, 22 Mar 2024 16:15:07 +0000
Received: by outflank-mailman (input) for mailman id 696997;
 Fri, 22 Mar 2024 16:15:06 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnhXt-0000BC-VF
 for xen-devel@lists.xenproject.org; Fri, 22 Mar 2024 16:15:06 +0000
Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com
 [2a00:1450:4864:20::432])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 574b3679-e867-11ee-a1ee-f123f15fe8a2;
 Fri, 22 Mar 2024 17:15:04 +0100 (CET)
Received: by mail-wr1-x432.google.com with SMTP id
 ffacd0b85a97d-3416a975840so1408112f8f.0
 for ; Fri, 22 Mar 2024 09:15:04 -0700 (PDT)
Received: from m1x-phil.lan ([176.176.178.251])
 by smtp.gmail.com with ESMTPSA id
 b7-20020a056000054700b0033e7b05edf3sm2383822wrf.44.2024.03.22.09.15.00
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Fri, 22 Mar 2024 09:15:03 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 574b3679-e867-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1711124103; x=1711728903; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=s1qPut0NhGBzfRg42Qh5UyiazOmzOKukv5I7c5rLwvg=;
        b=cXoV4nw8TbI/81kie5ql3vsPMtH6m+2wX1UAqjkhuBTG4PMT0aNUKULt3utT4igec7
         IqNxX3FWMzYVDOhbEcuQmk1SE8pRBIce5By9XBBsGRQIR6fEcGDSvMeLZDwSE+UTS145
         bUE5K4t1z3dMq6JfiZ9mwtSP1CZ8053qrtoQZ5P2v6fMueVshWjiI0kbQ+y4PpkoLbln
         Va+GSmCdSVSUNLJ9cmhLCM9JjpxM1jDX//sqXZrWbrojMg1jg80xhx1vV0feSYQSHP4t
         DE+V2RxlZBp6JLXybXs0x3TBw3EMT6KOd/njHTANrpumaQMwBf+4ZykhYB1J6bQHdau+
         SfKA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711124103; x=1711728903;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=s1qPut0NhGBzfRg42Qh5UyiazOmzOKukv5I7c5rLwvg=;
        b=UOHwChUEjhn3ShqkYhAgh7ok6nNk8tvkV2XFLzLrHefz6q0AHsiSzyo/XUrs9vUenA
         f++mzuSxC4lBkw9GB/AFsHOmj8Ib4GHX/9gVzISC3cTAs9fH9RQOGo+wfLGQvPG1yaWn
         LmLXEJQ8xAEFMGZBdNJ9PQKtiWRyI6RqUCNl+NB7Rt7XKRD2rB+gTKpNdpocORLUfVZX
         swdPKDyU4EhMUoc0Vp1QlT6UIwMZVhNU9oJyE8+xe6JLHdPh6yuuBmdHacdC+aecf3SZ
         0HwyuZjepRS62PAw1dLa5PZhLQNdjUFfjsk5pO8GEjXIBRo5xvuWEzK8GRlaDLZVjkBG
         IR7g==
X-Forwarded-Encrypted: i=1; AJvYcCVKvT2uhNXMJr7ywFgEg933UpVGzwQ8FmpddXIg+1iUQfZvzm10FKEeBZrlS1swR+r2dbZdmrEbYPe62G0QVjq/ShadAXsoxIR8NfkLkuA=
X-Gm-Message-State: AOJu0Yw/a5SvuIzFmm5nTaBG4u2T1n6thxd/mH6aGlLgfewBd79Q/gi8
	J7+h1afdi3l4UL+YPgCZHpNACO/dgBRUB88J1hWunGhK04AqVW96AatISstjrAM=
X-Google-Smtp-Source: AGHT+IHlt+ox/CID64UUSwzrMDTeHUJbOcdvrgQZGJkSECtfnfLaNH6boam/8ucRh2a5UcSqVNTFgQ==
X-Received: by 2002:a05:6000:51:b0:33e:a1e3:87b3 with SMTP id k17-20020a056000005100b0033ea1e387b3mr1779324wrx.41.1711124103530;
        Fri, 22 Mar 2024 09:15:03 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org
Cc: Thomas Huth ,
	qemu-arm@nongnu.org,
	=?UTF-8?q?Alex=20Benn=C3=A9e?= ,
	Anton Johansson ,
	Richard Henderson ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Paolo Bonzini ,
	Peter Maydell ,
	Peter Xu ,
	David Hildenbrand ,
	Eduardo Habkost ,
	Marcel Apfelbaum ,
	Yanan Wang ,
	Cameron Esfahani ,
	Roman Bolshakov ,
	Reinoud Zandijk ,
	Sunil Muthuswamy ,
	Stefano Stabellini ,
	Anthony Perard ,
	Paul Durrant ,
	=?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= ,
	=?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= ,
	kvm@vger.kernel.org,
	xen-devel@lists.xenproject.org
Subject: [PATCH-for-9.1 v2 3/3] exec: Rename NEED_CPU_H -> COMPILING_PER_TARGET
Date: Fri, 22 Mar 2024 17:14:39 +0100
Message-ID: <20240322161439.6448-4-philmd@linaro.org>
X-Mailer: git-send-email 2.41.0
In-Reply-To: <20240322161439.6448-1-philmd@linaro.org>
References: <20240322161439.6448-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

'NEED_CPU_H' guard target-specific code; it is defined by meson
altogether with the 'CONFIG_TARGET' definition. Rename NEED_CPU_H
as COMPILING_PER_TARGET to clarify its meaning.

Mechanical change running:

 $ sed -i s/NEED_CPU_H/COMPILING_PER_TARGET/g $(git grep -l NEED_CPU_H)

then manually add a /* COMPILING_PER_TARGET */ comment
after the '#endif' when the block is large.

Inspired-by: Peter Maydell 
Signed-off-by: Philippe Mathieu-Daudé 
---
 meson.build                | 4 ++--
 include/exec/cpu-defs.h    | 2 +-
 include/exec/helper-head.h | 4 ++--
 include/exec/memop.h       | 4 ++--
 include/exec/memory.h      | 4 ++--
 include/exec/tswap.h       | 4 ++--
 include/gdbstub/helpers.h  | 2 +-
 include/hw/core/cpu.h      | 4 ++--
 include/qemu/osdep.h       | 2 +-
 include/sysemu/hvf.h       | 8 ++++----
 include/sysemu/kvm.h       | 6 +++---
 include/sysemu/nvmm.h      | 4 ++--
 include/sysemu/whpx.h      | 4 ++--
 include/sysemu/xen.h       | 4 ++--
 target/arm/kvm-consts.h    | 4 ++--
 scripts/analyze-inclusions | 6 +++---
 16 files changed, 33 insertions(+), 33 deletions(-)

diff --git a/meson.build b/meson.build
index b375248a76..f13ad52f5f 100644
--- a/meson.build
+++ b/meson.build
@@ -3637,7 +3637,7 @@ foreach d, list : target_modules
         if target.endswith('-softmmu')
           config_target = config_target_mak[target]
           target_inc = [include_directories('target' / config_target['TARGET_BASE_ARCH'])]
-          c_args = ['-DNEED_CPU_H',
+          c_args = ['-DCOMPILING_PER_TARGET',
                     '-DCONFIG_TARGET="@0@-config-target.h"'.format(target),
                     '-DCONFIG_DEVICES="@0@-config-devices.h"'.format(target)]
           target_module_ss = module_ss.apply(config_target, strict: false)
@@ -3820,7 +3820,7 @@ foreach target : target_dirs
   target_base_arch = config_target['TARGET_BASE_ARCH']
   arch_srcs = [config_target_h[target]]
   arch_deps = []
-  c_args = ['-DNEED_CPU_H',
+  c_args = ['-DCOMPILING_PER_TARGET',
             '-DCONFIG_TARGET="@0@-config-target.h"'.format(target),
             '-DCONFIG_DEVICES="@0@-config-devices.h"'.format(target)]
   link_args = emulator_link_args
diff --git a/include/exec/cpu-defs.h b/include/exec/cpu-defs.h
index 3915438b83..0dbef3010c 100644
--- a/include/exec/cpu-defs.h
+++ b/include/exec/cpu-defs.h
@@ -19,7 +19,7 @@
 #ifndef CPU_DEFS_H
 #define CPU_DEFS_H
 
-#ifndef NEED_CPU_H
+#ifndef COMPILING_PER_TARGET
 #error cpu.h included from common code
 #endif
 
diff --git a/include/exec/helper-head.h b/include/exec/helper-head.h
index 28ceab0a46..5ef467a79d 100644
--- a/include/exec/helper-head.h
+++ b/include/exec/helper-head.h
@@ -43,7 +43,7 @@
 #define dh_ctype_noreturn G_NORETURN void
 #define dh_ctype(t) dh_ctype_##t
 
-#ifdef NEED_CPU_H
+#ifdef COMPILING_PER_TARGET
 # ifdef TARGET_LONG_BITS
 #  if TARGET_LONG_BITS == 32
 #   define dh_alias_tl i32
@@ -54,7 +54,7 @@
 #  endif
 # endif
 # define dh_ctype_tl target_ulong
-#endif
+#endif /* COMPILING_PER_TARGET */
 
 /* We can't use glue() here because it falls foul of C preprocessor
    recursive expansion rules.  */
diff --git a/include/exec/memop.h b/include/exec/memop.h
index a86dc6743a..06417ff361 100644
--- a/include/exec/memop.h
+++ b/include/exec/memop.h
@@ -35,7 +35,7 @@ typedef enum MemOp {
     MO_LE    = 0,
     MO_BE    = MO_BSWAP,
 #endif
-#ifdef NEED_CPU_H
+#ifdef COMPILING_PER_TARGET
 #if TARGET_BIG_ENDIAN
     MO_TE    = MO_BE,
 #else
@@ -135,7 +135,7 @@ typedef enum MemOp {
     MO_BESL  = MO_BE | MO_SL,
     MO_BESQ  = MO_BE | MO_SQ,
 
-#ifdef NEED_CPU_H
+#ifdef COMPILING_PER_TARGET
     MO_TEUW  = MO_TE | MO_UW,
     MO_TEUL  = MO_TE | MO_UL,
     MO_TEUQ  = MO_TE | MO_UQ,
diff --git a/include/exec/memory.h b/include/exec/memory.h
index 8626a355b3..bb51e90fe1 100644
--- a/include/exec/memory.h
+++ b/include/exec/memory.h
@@ -3087,7 +3087,7 @@ address_space_write_cached(MemoryRegionCache *cache, hwaddr addr,
 MemTxResult address_space_set(AddressSpace *as, hwaddr addr,
                               uint8_t c, hwaddr len, MemTxAttrs attrs);
 
-#ifdef NEED_CPU_H
+#ifdef COMPILING_PER_TARGET
 /* enum device_endian to MemOp.  */
 static inline MemOp devend_memop(enum device_endian end)
 {
@@ -3105,7 +3105,7 @@ static inline MemOp devend_memop(enum device_endian end)
     return (end == non_host_endianness) ? MO_BSWAP : 0;
 #endif
 }
-#endif
+#endif /* COMPILING_PER_TARGET */
 
 /*
  * Inhibit technologies that require discarding of pages in RAM blocks, e.g.,
diff --git a/include/exec/tswap.h b/include/exec/tswap.h
index 68944a880b..5089cd6a4c 100644
--- a/include/exec/tswap.h
+++ b/include/exec/tswap.h
@@ -15,11 +15,11 @@
  * If we're in target-specific code, we can hard-code the swapping
  * condition, otherwise we have to do (slower) run-time checks.
  */
-#ifdef NEED_CPU_H
+#ifdef COMPILING_PER_TARGET
 #define target_needs_bswap()  (HOST_BIG_ENDIAN != TARGET_BIG_ENDIAN)
 #else
 #define target_needs_bswap()  (target_words_bigendian() != HOST_BIG_ENDIAN)
-#endif
+#endif /* COMPILING_PER_TARGET */
 
 static inline uint16_t tswap16(uint16_t s)
 {
diff --git a/include/gdbstub/helpers.h b/include/gdbstub/helpers.h
index 53e88d807c..6277a858a1 100644
--- a/include/gdbstub/helpers.h
+++ b/include/gdbstub/helpers.h
@@ -12,7 +12,7 @@
 #ifndef _GDBSTUB_HELPERS_H_
 #define _GDBSTUB_HELPERS_H_
 
-#ifndef NEED_CPU_H
+#ifndef COMPILING_PER_TARGET
 #error "gdbstub helpers should only be included by target specific code"
 #endif
 
diff --git a/include/hw/core/cpu.h b/include/hw/core/cpu.h
index ec14f74ce5..7f037b158e 100644
--- a/include/hw/core/cpu.h
+++ b/include/hw/core/cpu.h
@@ -1182,7 +1182,7 @@ bool target_words_bigendian(void);
 
 const char *target_name(void);
 
-#ifdef NEED_CPU_H
+#ifdef COMPILING_PER_TARGET
 
 #ifndef CONFIG_USER_ONLY
 
@@ -1197,7 +1197,7 @@ extern const VMStateDescription vmstate_cpu_common;
 }
 #endif /* !CONFIG_USER_ONLY */
 
-#endif /* NEED_CPU_H */
+#endif /* COMPILING_PER_TARGET */
 
 #define UNASSIGNED_CPU_INDEX -1
 #define UNASSIGNED_CLUSTER_INDEX -1
diff --git a/include/qemu/osdep.h b/include/qemu/osdep.h
index c7053cdc2b..f61edcfdc2 100644
--- a/include/qemu/osdep.h
+++ b/include/qemu/osdep.h
@@ -32,7 +32,7 @@
 #endif
 
 #include "config-host.h"
-#ifdef NEED_CPU_H
+#ifdef COMPILING_PER_TARGET
 #include CONFIG_TARGET
 #else
 #include "exec/poison.h"
diff --git a/include/sysemu/hvf.h b/include/sysemu/hvf.h
index 4a7c6af3a5..730f927f03 100644
--- a/include/sysemu/hvf.h
+++ b/include/sysemu/hvf.h
@@ -16,7 +16,7 @@
 #include "qemu/accel.h"
 #include "qom/object.h"
 
-#ifdef NEED_CPU_H
+#ifdef COMPILING_PER_TARGET
 #include "cpu.h"
 
 #ifdef CONFIG_HVF
@@ -26,7 +26,7 @@ extern bool hvf_allowed;
 #define hvf_enabled() 0
 #endif /* !CONFIG_HVF */
 
-#endif /* NEED_CPU_H */
+#endif /* COMPILING_PER_TARGET */
 
 #define TYPE_HVF_ACCEL ACCEL_CLASS_NAME("hvf")
 
@@ -34,7 +34,7 @@ typedef struct HVFState HVFState;
 DECLARE_INSTANCE_CHECKER(HVFState, HVF_STATE,
                          TYPE_HVF_ACCEL)
 
-#ifdef NEED_CPU_H
+#ifdef COMPILING_PER_TARGET
 struct hvf_sw_breakpoint {
     vaddr pc;
     vaddr saved_insn;
@@ -66,6 +66,6 @@ void hvf_arch_update_guest_debug(CPUState *cpu);
  * Return whether the guest supports debugging.
  */
 bool hvf_arch_supports_guest_debug(void);
-#endif /* NEED_CPU_H */
+#endif /* COMPILING_PER_TARGET */
 
 #endif
diff --git a/include/sysemu/kvm.h b/include/sysemu/kvm.h
index fad9a7e8ff..c618a59ba6 100644
--- a/include/sysemu/kvm.h
+++ b/include/sysemu/kvm.h
@@ -20,7 +20,7 @@
 #include "qemu/accel.h"
 #include "qom/object.h"
 
-#ifdef NEED_CPU_H
+#ifdef COMPILING_PER_TARGET
 # ifdef CONFIG_KVM
 #  include 
 #  define CONFIG_KVM_IS_POSSIBLE
@@ -210,7 +210,7 @@ bool kvm_arm_supports_user_irq(void);
 int kvm_on_sigbus_vcpu(CPUState *cpu, int code, void *addr);
 int kvm_on_sigbus(int code, void *addr);
 
-#ifdef NEED_CPU_H
+#ifdef COMPILING_PER_TARGET
 #include "cpu.h"
 
 void kvm_flush_coalesced_mmio_buffer(void);
@@ -435,7 +435,7 @@ void kvm_set_sigmask_len(KVMState *s, unsigned int sigmask_len);
 int kvm_physical_memory_addr_from_host(KVMState *s, void *ram_addr,
                                        hwaddr *phys_addr);
 
-#endif /* NEED_CPU_H */
+#endif /* COMPILING_PER_TARGET */
 
 void kvm_cpu_synchronize_state(CPUState *cpu);
 
diff --git a/include/sysemu/nvmm.h b/include/sysemu/nvmm.h
index be7bc9a62d..6971ddb3a5 100644
--- a/include/sysemu/nvmm.h
+++ b/include/sysemu/nvmm.h
@@ -12,7 +12,7 @@
 #ifndef QEMU_NVMM_H
 #define QEMU_NVMM_H
 
-#ifdef NEED_CPU_H
+#ifdef COMPILING_PER_TARGET
 
 #ifdef CONFIG_NVMM
 
@@ -24,6 +24,6 @@ int nvmm_enabled(void);
 
 #endif /* CONFIG_NVMM */
 
-#endif /* NEED_CPU_H */
+#endif /* COMPILING_PER_TARGET */
 
 #endif /* QEMU_NVMM_H */
diff --git a/include/sysemu/whpx.h b/include/sysemu/whpx.h
index 781ca5b2b6..00ff409b68 100644
--- a/include/sysemu/whpx.h
+++ b/include/sysemu/whpx.h
@@ -15,7 +15,7 @@
 #ifndef QEMU_WHPX_H
 #define QEMU_WHPX_H
 
-#ifdef NEED_CPU_H
+#ifdef COMPILING_PER_TARGET
 
 #ifdef CONFIG_WHPX
 
@@ -29,6 +29,6 @@ bool whpx_apic_in_platform(void);
 
 #endif /* CONFIG_WHPX */
 
-#endif /* NEED_CPU_H */
+#endif /* COMPILING_PER_TARGET */
 
 #endif /* QEMU_WHPX_H */
diff --git a/include/sysemu/xen.h b/include/sysemu/xen.h
index a9f591f26d..754ec2e6cb 100644
--- a/include/sysemu/xen.h
+++ b/include/sysemu/xen.h
@@ -16,13 +16,13 @@
 
 #include "exec/cpu-common.h"
 
-#ifdef NEED_CPU_H
+#ifdef COMPILING_PER_TARGET
 # ifdef CONFIG_XEN
 #  define CONFIG_XEN_IS_POSSIBLE
 # endif
 #else
 # define CONFIG_XEN_IS_POSSIBLE
-#endif
+#endif /* COMPILING_PER_TARGET */
 
 #ifdef CONFIG_XEN_IS_POSSIBLE
 
diff --git a/target/arm/kvm-consts.h b/target/arm/kvm-consts.h
index 7c6adc14f6..c44d23dbe7 100644
--- a/target/arm/kvm-consts.h
+++ b/target/arm/kvm-consts.h
@@ -14,13 +14,13 @@
 #ifndef ARM_KVM_CONSTS_H
 #define ARM_KVM_CONSTS_H
 
-#ifdef NEED_CPU_H
+#ifdef COMPILING_PER_TARGET
 #ifdef CONFIG_KVM
 #include 
 #include 
 #define MISMATCH_CHECK(X, Y) QEMU_BUILD_BUG_ON(X != Y)
 #endif
-#endif
+#endif /* COMPILING_PER_TARGET */
 
 #ifndef MISMATCH_CHECK
 #define MISMATCH_CHECK(X, Y) QEMU_BUILD_BUG_ON(0)
diff --git a/scripts/analyze-inclusions b/scripts/analyze-inclusions
index 45c821de32..b6280f25c8 100644
--- a/scripts/analyze-inclusions
+++ b/scripts/analyze-inclusions
@@ -92,7 +92,7 @@ echo trace/generated-tracers.h:
 analyze -include ../include/qemu/osdep.h trace/generated-tracers.h
 
 echo target/i386/cpu.h:
-analyze -DNEED_CPU_H -I../target/i386 -Ii386-softmmu -include ../include/qemu/osdep.h ../target/i386/cpu.h
+analyze -DCOMPILING_PER_TARGET -I../target/i386 -Ii386-softmmu -include ../include/qemu/osdep.h ../target/i386/cpu.h
 
-echo hw/hw.h + NEED_CPU_H:
-analyze -DNEED_CPU_H -I../target/i386 -Ii386-softmmu -include ../include/qemu/osdep.h ../include/hw/hw.h
+echo hw/hw.h + COMPILING_PER_TARGET:
+analyze -DCOMPILING_PER_TARGET -I../target/i386 -Ii386-softmmu -include ../include/qemu/osdep.h ../include/hw/hw.h
-- 
2.41.0



From xen-devel-bounces@lists.xenproject.org Fri Mar 22 16:42:33 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Mar 2024 16:42:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697018.1088311 (Exim 4.92)
	(envelope-from )
	id 1rnhyM-0005Lf-10; Fri, 22 Mar 2024 16:42:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697018.1088311; Fri, 22 Mar 2024 16:42:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnhyL-0005LY-UN; Fri, 22 Mar 2024 16:42:25 +0000
Received: by outflank-mailman (input) for mailman id 697018;
 Fri, 22 Mar 2024 16:42:24 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rnhyK-0005LO-9F
 for xen-devel@lists.xenproject.org; Fri, 22 Mar 2024 16:42:24 +0000
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com
 [2a00:1450:4864:20::130])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2798795b-e86b-11ee-a1ee-f123f15fe8a2;
 Fri, 22 Mar 2024 17:42:21 +0100 (CET)
Received: by mail-lf1-x130.google.com with SMTP id
 2adb3069b0e04-512b3b04995so1551807e87.3
 for ; Fri, 22 Mar 2024 09:42:21 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2798795b-e86b-11ee-a1ee-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1711125741; x=1711730541; darn=lists.xenproject.org;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=xTgT8zP2eQv5Wtx20Sndrdeyr3BrAAr5gt2PSwktbgA=;
        b=c5RHudcK03KkW3F9ETcpNIBhIOY5vVYAUEMmsEpm918Ze4cnKPhXh1T5oruoHackq+
         bBIGNH8Ks+upwpdJIpPqWBpY8goXpWDV5Zcc4aiV7Fs88dpivkH0rfWwTF4G3bIZcyi2
         fY6c+uwTYBAm8azf7kIfLiztsuCu+1rCvG1Do=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711125741; x=1711730541;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=xTgT8zP2eQv5Wtx20Sndrdeyr3BrAAr5gt2PSwktbgA=;
        b=wb+UvnUeR5+vmCTg3JgpsdBQXE1H3HSNKuJmCNqpVty2UEXc1SQnlOn7cY3jSqdT+b
         +g5Ftv6qOjvsN7PVtnDxQm8AdeTp732E0t4ujsWNMqWJ7aIkSqPimYGbKqIcbjn4E1wG
         92Yz7JvS5t+DpGnuomS/h+NVxpVV1by0ayxCWWgWXgus2AlpLzrBKD3jLj2koBt+Jn+q
         sXLuIx2dipDMNvQ1gQmILjt6UJXNOIdsxznm+AjCeUHxsgxO47Q/hisZ595O6yIaiTUS
         VrHIRUr51OsU98Cfvk65rBOyF8dEDqx9OaQtotLJGwBzE1UVjYcNXx6cUpf9nmheKs23
         tBaA==
X-Gm-Message-State: AOJu0Yw38WFEcs8CtR69hovVY2yLzVXSxu+sr+VrciUV5Av0rotuWM/a
	YTRDDv6knjJxzRq0Gt0HgGfC942A5+yfAHQOcwnEmEoXs9d4OrM+kkh9DEa6CG5MevjhZ9bEWIs
	Y3xGKAgttlimfLdSz5gi1wkL4wPIhOmaxZlHD6g==
X-Google-Smtp-Source: AGHT+IGpXUrDjdbG7vxAAS7FIolkeW4/+cbNkjFUmdGHjl6DCIawvBDiii616A3W4fqh1srOxhMInNtFe5IhIk21BE4=
X-Received: by 2002:a19:ae05:0:b0:513:c4b8:388b with SMTP id
 f5-20020a19ae05000000b00513c4b8388bmr2060156lfc.27.1711125741182; Fri, 22 Mar
 2024 09:42:21 -0700 (PDT)
MIME-Version: 1.0
References:  
 
In-Reply-To: 
From: Kelly Choi 
Date: Fri, 22 Mar 2024 16:41:45 +0000
Message-ID: 
Subject: Re: Serious AMD-Vi(?) issue
To: Elliott Mitchell 
Cc: xen-devel@lists.xenproject.org, Jan Beulich , 
	Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
	Wei Liu 
Content-Type: multipart/alternative; boundary="000000000000f847740614428159"

--000000000000f847740614428159
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Elliott,

I hope you're well.

I'm Kelly, the community manager at the Xen Project.

I can see you've recently engaged with our community with some issues you'd
like help with.
We love the fact you are participating in our project, however, our
developers aren't able to help if you do not provide the specific details.

As an open-source project, our developers are committed to helping and
contributing as much as possible. We welcome you to continue participating,
however, please refrain from requesting help without providing the
necessary details as this takes up a lot of our community's time to analyze
what is possible and what assistance you might need.

I'd recommend providing logs or specific information so the community can
help you further.

If you'd like to chat more, let me know.

Many thanks,
Kelly Choi

Community Manager
Xen Project


On Mon, Mar 18, 2024 at 7:42=E2=80=AFPM Elliott Mitchell =
 wrote:

> I sent a ping on this about 2 weeks ago.  Since the plan is to move x86
> IOMMU under general x86, the other x86 maintainers should be aware of
> this:
>
> On Mon, Feb 12, 2024 at 03:23:00PM -0800, Elliott Mitchell wrote:
> > On Thu, Jan 25, 2024 at 12:24:53PM -0800, Elliott Mitchell wrote:
> > > Apparently this was first noticed with 4.14, but more recently I've
> been
> > > able to reproduce the issue:
> > >
> > > https://bugs.debian.org/988477
> > >
> > > The original observation features MD-RAID1 using a pair of Samsung
> > > SATA-attached flash devices.  The main line shows up in `xl dmesg`:
> > >
> > > (XEN) AMD-Vi: IO_PAGE_FAULT: DDDD:bb:dd.f d0 addr ffffff???????000
> flags 0x8 I
> > >
> > > Where the device points at the SATA controller.  I've ended up
> > > reproducing this with some noticable differences.
> > >
> > > A major goal of RAID is to have different devices fail at different
> > > times.  Hence my initial run had a Samsung device plus a device from
> > > another reputable flash manufacturer.
> > >
> > > I initially noticed this due to messages in domain 0's dmesg about
> > > errors from the SATA device.  Wasn't until rather later that I notice=
d
> > > the IOMMU warnings in Xen's dmesg (perhaps post-domain 0 messages
> should
> > > be duplicated into domain 0's dmesg?).
> > >
> > > All of the failures consistently pointed at the Samsung device.  Due =
to
> > > the expectation it would fail first (lower quality offering with
> > > lesser guarantees), I proceeded to replace it with a NVMe device.
> > >
> > > With some monitoring I discovered the NVMe device was now triggering
> > > IOMMU errors, though not nearly as many as the Samsung SATA device di=
d.
> > > As such looks like AMD-Vi plus MD-RAID1 appears to be exposing some
> sort
> > > of IOMMU issue with Xen.
> > >
> > >
> > > All I can do is offer speculation about the underlying cause.  There
> > > does seem to be a pattern of higher-performance flash storage devices
> > > being more severely effected.
> > >
> > > I was speculating about the issue being the MD-RAID1 driver abusing
> > > Linux's DMA infrastructure in some fashion.
> > >
> > > Upon further consideration, I'm wondering if this is perhaps a latenc=
y
> > > issue.  I imagine there is some sort of flush after the IOMMU tables
> are
> > > modified.  Perhaps the Samsung SATA (and all NVMe) devices were tryin=
g
> to
> > > execute commands before reloading the IOMMU tables is complete.
> >
> > Ping!
> >
> > The recipe seems to be Linux MD RAID1, plus Samsung SATA or any NVMe.
> >
> > To make it explicit, when I tried Crucial SATA + Samsung SATA.  IOMMU
> > errors matched the Samsung SATA (a number of times the SATA driver
> > complained).
> >
> > As stated, I'm speculating lower latency devices starting to execute
> > commands before IOMMU tables have finished reloading.  When originally
> > implemented fast flash devices were rare.
>
> Both reproductions of this issue I'm aware of were on systems with AMD
> processors.  I'm doubtul suspicion of flash storage hardware is unique
> to owners of AMD systems.  As a result while this /could/ also effect
> Intel systems, the lack of reports /suggests/ otherwise.
>
> I've noticed two things when glancing at the original report.  LVM is not
> in use here, so that doesn't seem to effect the problem.  The Phenom II
> the original reporter tested as not having the issue might have lacked
> proper BIOS support, hence IOMMU not being functional.
>
> This being a latency issue is *speculation*, but would explain the
> pattern of devices being effected.
>
> This is rather serious as it can lead to data loss (phew!  glad I just
> barely dodged this outcome).
>
>
> --
> (\___(\___(\______          --=3D> 8-) EHM <=3D--          ______/)___/)_=
__/)
>  \BS (    |         ehem+sigmsg@m5p.com  PGP 87145445         |    )   /
>   \_CS\   |  _____  -O #include  O-   _____  |   /  _/
> 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
>
>
>
>

--000000000000f847740614428159
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi=C2=A0Elliott<=
/span>,

I hope you're well.=C2=A0

I'm Kelly, the community manager at the Xen Project.=C2=A0
=


I can see you've recently engaged with our communit=
y with some issues you'd like help with.
We love the fact you=
 are participating in our project, however, our developers aren't able =
to help if you do not provide the specific details.=C2=A0

As an open-source project, our developers are committed to helping =
and contributing as much as possible. We welcome you to continue participat=
ing, however, please refrain from requesting help without providing the nec=
essary details as this takes up a lot of our community's time to analyz=
e what is possible and what assistance you might need.=C2=A0

=

I'd recommend providing logs or specific information so the =
community can help you further.

If you'd like =
to chat more, let me know.

Many thanks,
Kelly Cho=
i

Community =
Manager
Xen Project=C2=A0


On Mon, Mar 18, 2024 at 7:42=E2=80=AFPM Elli=
ott Mitchell <ehem+xen@m5p.com=
> wrote:
I se=
nt a ping on this about 2 weeks ago.=C2=A0 Since the plan is to move x86
IOMMU under general x86, the other x86 maintainers should be aware of

this:



On Mon, Feb 12, 2024 at 03:23:00PM -0800, Elliott Mitchell wrote:

> On Thu, Jan 25, 2024 at 12:24:53PM -0800, Elliott Mitchell wrote:

> > Apparently this was first noticed with 4.14, but more recently I&=
#39;ve been

> > able to reproduce the issue:

> > 

> > https://bugs.debian.org/988477

> > 

> > The original observation features MD-RAID1 using a pair of Samsun=
g

> > SATA-attached flash devices.=C2=A0 The main line shows up in `xl =
dmesg`:

> > 

> > (XEN) AMD-Vi: IO_PAGE_FAULT: DDDD:bb:dd.f d0 addr ffffff???????00=
0 flags 0x8 I

> > 

> > Where the device points at the SATA controller.=C2=A0 I've en=
ded up

> > reproducing this with some noticable differences.

> > 

> > A major goal of RAID is to have different devices fail at differe=
nt

> > times.=C2=A0 Hence my initial run had a Samsung device plus a dev=
ice from

> > another reputable flash manufacturer.

> > 

> > I initially noticed this due to messages in domain 0's dmesg =
about

> > errors from the SATA device.=C2=A0 Wasn't until rather later =
that I noticed

> > the IOMMU warnings in Xen's dmesg (perhaps post-domain 0 mess=
ages should

> > be duplicated into domain 0's dmesg?).

> > 

> > All of the failures consistently pointed at the Samsung device.=
=C2=A0 Due to

> > the expectation it would fail first (lower quality offering with<=
br>
> > lesser guarantees), I proceeded to replace it with a NVMe device.=


> > 

> > With some monitoring I discovered the NVMe device was now trigger=
ing

> > IOMMU errors, though not nearly as many as the Samsung SATA devic=
e did.

> > As such looks like AMD-Vi plus MD-RAID1 appears to be exposing so=
me sort

> > of IOMMU issue with Xen.

> > 

> > 

> > All I can do is offer speculation about the underlying cause.=C2=
=A0 There

> > does seem to be a pattern of higher-performance flash storage dev=
ices

> > being more severely effected.

> > 

> > I was speculating about the issue being the MD-RAID1 driver abusi=
ng

> > Linux's DMA infrastructure in some fashion.

> > 

> > Upon further consideration, I'm wondering if this is perhaps =
a latency

> > issue.=C2=A0 I imagine there is some sort of flush after the IOMM=
U tables are

> > modified.=C2=A0 Perhaps the Samsung SATA (and all NVMe) devices w=
ere trying to

> > execute commands before reloading the IOMMU tables is complete.
> 

> Ping!

> 

> The recipe seems to be Linux MD RAID1, plus Samsung SATA or any NVMe.<=
br>
> 

> To make it explicit, when I tried Crucial SATA + Samsung SATA.=C2=A0 I=
OMMU

> errors matched the Samsung SATA (a number of times the SATA driver

> complained).

> 

> As stated, I'm speculating lower latency devices starting to execu=
te

> commands before IOMMU tables have finished reloading.=C2=A0 When origi=
nally

> implemented fast flash devices were rare.



Both reproductions of this issue I'm aware of were on systems with AMD<=
br>
processors.=C2=A0 I'm doubtul suspicion of flash storage hardware is un=
ique

to owners of AMD systems.=C2=A0 As a result while this /could/ also effect<=
br>
Intel systems, the lack of reports /suggests/ otherwise.



I've noticed two things when glancing at the original report.=C2=A0 LVM=
 is not

in use here, so that doesn't seem to effect the problem.=C2=A0 The Phen=
om II

the original reporter tested as not having the issue might have lacked

proper BIOS support, hence IOMMU not being functional.



This being a latency issue is *speculation*, but would explain the

pattern of devices being effected.



This is rather serious as it can lead to data loss (phew!=C2=A0 glad I just=


barely dodged this outcome).





-- 

(\___(\___(\______=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --=3D> 8-) EHM <=
=3D--=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ______/)___/)___/)

=C2=A0\BS (=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ehem+sigmsg@m5p.com=C2=A0 P=
GP 87145445=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 )=C2=A0 =C2=A0/=


=C2=A0 \_CS\=C2=A0 =C2=A0|=C2=A0 _____=C2=A0 -O #include <stddisclaimer.=
h> O-=C2=A0 =C2=A0_____=C2=A0 |=C2=A0 =C2=A0/=C2=A0 _/

8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/=
5445










--000000000000f847740614428159--


From xen-devel-bounces@lists.xenproject.org Fri Mar 22 17:26:04 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Mar 2024 17:26:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697068.1088321 (Exim 4.92)
	(envelope-from )
	id 1rnieM-00037D-2M; Fri, 22 Mar 2024 17:25:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697068.1088321; Fri, 22 Mar 2024 17:25:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnieL-000376-Tp; Fri, 22 Mar 2024 17:25:49 +0000
Received: by outflank-mailman (input) for mailman id 697068;
 Fri, 22 Mar 2024 17:25:48 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnieK-00036q-TR; Fri, 22 Mar 2024 17:25:48 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnieK-0000FN-J1; Fri, 22 Mar 2024 17:25:48 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnieK-0007JJ-8i; Fri, 22 Mar 2024 17:25:48 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rnieK-0000SH-86; Fri, 22 Mar 2024 17:25:48 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=BTlbWwWEJ8fcRAtU1Vcl+mPahxhYs8Kjhnd+zh57s8w=; b=jgwP3KF44wgvxOEZDJviEdVgyT
	qJJbhVYy6FWeMeXQeiWfocAt6tjFoqiEJh4RV5Tx6YOFU5kz39ZLT++dbfDrSbULtpG2gOXoQDdb5
	qIRembqJGprJhXVAyUrZspYtIRXppLXtuNsjm0tEb0JiHmBajKC7z+MO0n4DQEHmhjgc=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 185139: regressions - FAIL
X-Osstest-Failures:
    linux-linus:test-armhf-armhf-xl:xen-boot:fail:regression
    linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-qcow2:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-qcow2:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-raw:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-vhd:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
X-Osstest-Versions-This:
    linux=8e938e39866920ddc266898e6ae1fffc5c8f51aa
X-Osstest-Versions-That:
    linux=23956900041d968f9ad0f30db6dede4daccd7aa9
From: osstest service owner 
Date: Fri, 22 Mar 2024 17:25:48 +0000

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl           8 xen-boot                 fail REGR. vs. 185119

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

version targeted for testing:
 linux                8e938e39866920ddc266898e6ae1fffc5c8f51aa
baseline version:
 linux                23956900041d968f9ad0f30db6dede4daccd7aa9

Last test of basis   185119  2024-03-21 07:40:49 Z    1 days
Failing since        185136  2024-03-21 21:13:02 Z    0 days    2 attempts
Testing same since   185139  2024-03-22 06:08:37 Z    0 days    1 attempts

------------------------------------------------------------
413 people touched revisions under test,
not listing them all

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-libvirt-qcow2                               pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-xl-qcow2                                    pass    
 test-amd64-amd64-libvirt-raw                                 pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-amd64-amd64-xl-raw                                      pass    
 test-armhf-armhf-xl-raw                                      pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-libvirt-vhd                                 pass    
 test-amd64-amd64-xl-vhd                                      pass    
 test-arm64-arm64-xl-vhd                                      pass    


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

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

Explanation of these 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 23733 lines long.)


From xen-devel-bounces@lists.xenproject.org Fri Mar 22 19:22:38 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Mar 2024 19:22:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697087.1088330 (Exim 4.92)
	(envelope-from )
	id 1rnkTA-0001sa-88; Fri, 22 Mar 2024 19:22:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697087.1088330; Fri, 22 Mar 2024 19:22:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnkTA-0001sT-5b; Fri, 22 Mar 2024 19:22:24 +0000
Received: by outflank-mailman (input) for mailman id 697087;
 Fri, 22 Mar 2024 19:22:23 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnkT9-0001sN-Kr
 for xen-devel@lists.xenproject.org; Fri, 22 Mar 2024 19:22:23 +0000
Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.4])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 80149ce1-e881-11ee-a1ee-f123f15fe8a2;
 Fri, 22 Mar 2024 20:22:20 +0100 (CET)
Received: from m5p.com (mailhost.m5p.com [IPv6:2001:470:1f07:15ff:0:0:0:f7])
 by mailhost.m5p.com (8.17.1/8.15.2) with ESMTPS id 42MJM42A055590
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
 Fri, 22 Mar 2024 15:22:10 -0400 (EDT) (envelope-from ehem@m5p.com)
Received: (from ehem@localhost)
 by m5p.com (8.17.1/8.15.2/Submit) id 42MJM1fV055589;
 Fri, 22 Mar 2024 12:22:01 -0700 (PDT) (envelope-from ehem)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 80149ce1-e881-11ee-a1ee-f123f15fe8a2
Date: Fri, 22 Mar 2024 12:22:01 -0700
From: Elliott Mitchell 
To: Kelly Choi 
Cc: xen-devel@lists.xenproject.org, Jan Beulich ,
        Andrew Cooper ,
        Roger Pau =?iso-8859-1?Q?Monn=E9?= ,
        Wei Liu 
Subject: Re: Serious AMD-Vi(?) issue
Message-ID: 
References: 
 
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-Spam-Status: No, score=0.0 required=10.0 tests=KHOP_HELO_FCRDNS
	autolearn=unavailable autolearn_force=no version=4.0.0
X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on mattapan.m5p.com

On Fri, Mar 22, 2024 at 04:41:45PM +0000, Kelly Choi wrote:
> 
> I can see you've recently engaged with our community with some issues you'd
> like help with.
> We love the fact you are participating in our project, however, our
> developers aren't able to help if you do not provide the specific details.

Please point to specific details which have been omitted.  Fairly little
data has been provided as fairly little data is available.  The primary
observation is large numbers of:

(XEN) AMD-Vi: IO_PAGE_FAULT: DDDD:bb:dd.f d0 addr ffffff???????000 flags 0x8 I

Lines in Xen's ring buffer.  I recall spotting 3 messages from Linux's
SATA driver (which weren't saved due to other causes being suspected),
which would likely be associated with hundreds or thousands of the above
log messages.  I never observed any messages from the NVMe subsystem
during that phase.

The most overt sign was telling the Linux kernel to scan for
inconsistencies and the kernel finding some.  The domain didn't otherwise
appear to notice trouble.

This is from memory, it would take some time to discover whether any
messages were missed.  Present mitigation action is inhibiting the
messages, but the trouble is certainly still lurking.


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg@m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include  O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445




From xen-devel-bounces@lists.xenproject.org Fri Mar 22 20:11:31 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Mar 2024 20:11:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697103.1088341 (Exim 4.92)
	(envelope-from )
	id 1rnlEa-0000GG-NP; Fri, 22 Mar 2024 20:11:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697103.1088341; Fri, 22 Mar 2024 20:11:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnlEa-0000G1-Ki; Fri, 22 Mar 2024 20:11:24 +0000
Received: by outflank-mailman (input) for mailman id 697103;
 Fri, 22 Mar 2024 20:11:24 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rnlEZ-0000Fv-VZ
 for xen-devel@lists.xenproject.org; Fri, 22 Mar 2024 20:11:24 +0000
Received: from EUR05-VI1-obe.outbound.protection.outlook.com
 (mail-vi1eur05on20601.outbound.protection.outlook.com
 [2a01:111:f403:2613::601])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 59ac1bcf-e888-11ee-afe1-a90da7624cb6;
 Fri, 22 Mar 2024 21:11:22 +0100 (CET)
Received: from AM0PR02CA0013.eurprd02.prod.outlook.com (2603:10a6:208:3e::26)
 by VE1PR08MB5581.eurprd08.prod.outlook.com (2603:10a6:800:1a0::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.15; Fri, 22 Mar
 2024 20:11:14 +0000
Received: from AM4PEPF00025F9B.EURPRD83.prod.outlook.com
 (2603:10a6:208:3e:cafe::8d) by AM0PR02CA0013.outlook.office365.com
 (2603:10a6:208:3e::26) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.28 via Frontend
 Transport; Fri, 22 Mar 2024 20:11:14 +0000
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by
 AM4PEPF00025F9B.mail.protection.outlook.com (10.167.16.10) with
 Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.7430.0
 via Frontend Transport; Fri, 22 Mar 2024 20:11:13 +0000
Received: ("Tessian outbound ff4e98f65004:v300");
 Fri, 22 Mar 2024 20:11:13 +0000
Received: from 6ef7f41090f0.1
 by 64aa7808-outbound-1.mta.getcheckrecipient.com id
 0319E025-870A-41A4-8834-78A1EC7445BF.1; 
 Fri, 22 Mar 2024 20:11:02 +0000
Received: from EUR02-DB5-obe.outbound.protection.outlook.com
 by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 6ef7f41090f0.1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384);
 Fri, 22 Mar 2024 20:11:02 +0000
Received: from AM0PR08MB3745.eurprd08.prod.outlook.com (2603:10a6:208:ff::27)
 by DBBPR08MB5915.eurprd08.prod.outlook.com (2603:10a6:10:20d::17)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.24; Fri, 22 Mar
 2024 20:11:00 +0000
Received: from AM0PR08MB3745.eurprd08.prod.outlook.com
 ([fe80::446b:ac86:e80c:ffda]) by AM0PR08MB3745.eurprd08.prod.outlook.com
 ([fe80::446b:ac86:e80c:ffda%6]) with mapi id 15.20.7386.023; Fri, 22 Mar 2024
 20:11:00 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 59ac1bcf-e888-11ee-afe1-a90da7624cb6
ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass;
 b=GQcfoJrE1Jo4K3HvB9FaKp/nZwdjX9tuw9elym0C0p5B5JejwaHoKG/znUe1dKvrdld3jQ7NaFs7hS+GnGd7+62xhVPE/A267gqV4OzHvyughPGGekAeCp+w9XwicT9Ai2A/wMFZV087yhz7q6mGw0QD7yQ4INRyTlQBsajOBfnna/4w+2Qkp7RkYRN04YQDe2kv3dnJcOmHKS/NFyQCuNbNOU3uT/SM6BR4gJXyyX6bqTznPt1iK5PD/SAT1kSyefpIvJs4zoYmvugVAtbi2dHlG3yJ3lIXrl34B0t0JGTB6RB6GSg5TfCK+R4lWHf7ZPqN9uqqnEkmaxrjuNhTWA==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=9ZJwd0/0OVccJ9HQLwWiNeqWWYJyfEsKSnk0duZQupk=;
 b=E0cqXFQ8paHQ8cUmQt6JGdXmom8xHnxd1uXXTB93v40BqX00RRuGBPxJElSi1urguqqgRnzDW6exF7hop32JDfX7WZuUwqSX28HxlVCMDw8KxQwiEdutz4A18qlLih17E9pozWHByqjodWAvB5U4ScGF249lgg/JhtbmtO5CSYZ9YcpzQkGc1y/zcsuXmhuItZVUN1KGPUIdTQ+jFOUTWh9XRgRKbl18bBQEHHCpjNPT1UeluGEB1ADjro0rM/WIHRTKd1iVBqhtWpeO12gfohKmDhjqrL6A9OMfgSJkFRy5iFTRLjFEv5eIIF6LUn+c1aj3wR5iwqjRP00sxeVP9Q==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 63.35.35.123) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=arm.com;
 dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com;
 dkim=pass (signature was verified) header.d=armh.onmicrosoft.com; arc=pass (0
 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com]
 dmarc=[1,1,header.from=arm.com])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com;
 s=selector2-armh-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=9ZJwd0/0OVccJ9HQLwWiNeqWWYJyfEsKSnk0duZQupk=;
 b=pWJ63dlolgUbe7UPN9+SopWElRrP0sPptR7p+eEr5OABHpePCTuUA0+JokcNckwMzmxzviwT2C2ZU1hCqB5s3fGvQA6Td50l19bmLbbNWltgx4Vpp+r99zr/fNcjjYtKeOtwfW01kjz/+4+j4/0yy3jqomu1BExqDV1bNyDIYhs=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=armh.onmicrosoft.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 63.35.35.123 as permitted sender) receiver=protection.outlook.com;
 client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
 pr=C
X-CheckRecipientChecked: true
X-CR-MTA-CID: 00fde62563a4cf24
X-CR-MTA-TID: 64aa7808
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=dWtm2vx67guu1L76nP7a6ZGJJCKuV3/Qo2zsOe2xf++GRjHYdCTBbi4QOAJyWtLTNfrIWCNK4BNtzBJ9CqJA96tmrxWYOgNQdqX+WgGAwANILEZa9voGf9tbekKGccseuMdkELMt3Q3A4/qrJass+hdg01C4Or/1fhYoV1WCpZKfggodWfXbzLXRqn1TvL0lMTMMcQL/Uc8ClIJ0MNFNHhjA6et0A4w6j/Zqm/B/otnF4sIGJO5BI8KIuTdsJ1OV2hEpDYffo0FGuzEZzkYOmAxAuJbSrGaFGDv6Atfm2TqGUqExSxmjuzy8qkyMBc1BoXCdY4HOrIf7DmPx9Bixgw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=9ZJwd0/0OVccJ9HQLwWiNeqWWYJyfEsKSnk0duZQupk=;
 b=X4N/H42+KZrmIPVp2IRiOemv4MhE3YkjUOqf3zQ1tcNhMp+iu1f6607bc7XW3YE/eT2AydMC/zuOptZ1gf9AjE3vpRM7LhB53Phwv1+cOfTh8nq1+Uy8HEfRzbXHsyv1vdUzCq4FiRXhhwBNNo/Mk45IvCv+QsDfx8iXcC+vzbgXvUIRJk5wH4pztF+EZ6yJuVlmK5EfjiK4rTX//Cl7Y/B+n2aNV/BsdtQm8XzkBO7RL+1ALUWLr9oSxSyXlXja9B9FlwVorQdLhQzfepqUAYyvKbCh+ToblImUEpaHuZ6JqdJpOSswlVUjp3FkEsY1V5dtSpsceSn3u8LijVg//g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass
 header.d=arm.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com;
 s=selector2-armh-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=9ZJwd0/0OVccJ9HQLwWiNeqWWYJyfEsKSnk0duZQupk=;
 b=pWJ63dlolgUbe7UPN9+SopWElRrP0sPptR7p+eEr5OABHpePCTuUA0+JokcNckwMzmxzviwT2C2ZU1hCqB5s3fGvQA6Td50l19bmLbbNWltgx4Vpp+r99zr/fNcjjYtKeOtwfW01kjz/+4+j4/0yy3jqomu1BExqDV1bNyDIYhs=
From: Luca Fancellu 
To: Michal Orzel 
CC: Xen-devel , Penny Zheng
	, Stefano Stabellini , Julien
 Grall , Bertrand Marquis ,
	Volodymyr Babchuk 
Subject: Re: [PATCH 09/11] xen/arm: remove shm holes for extended regions
Thread-Topic: [PATCH 09/11] xen/arm: remove shm holes for extended regions
Thread-Index: AQHadH3uaMFqvhbywkGpOv3rQeVHMLFD7N8AgABUNYA=
Date: Fri, 22 Mar 2024 20:11:00 +0000
Message-ID: <7B692603-AE39-45CB-B45A-082A123F381C@arm.com>
References: <20240312130331.78418-1-luca.fancellu@arm.com>
 <20240312130331.78418-10-luca.fancellu@arm.com>
 <9edf6716-77d9-445a-8f65-0914ffb97e3f@amd.com>
In-Reply-To: <9edf6716-77d9-445a-8f65-0914ffb97e3f@amd.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3774.400.31)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	AM0PR08MB3745:EE_|DBBPR08MB5915:EE_|AM4PEPF00025F9B:EE_|VE1PR08MB5581:EE_
X-MS-Office365-Filtering-Correlation-Id: 628b1bef-b378-452d-48fe-08dc4aac398c
x-checkrecipientrouted: true
nodisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted: BCL:0;
X-Microsoft-Antispam-Message-Info-Original:
 x4NPyJrlEZmhiPZICtNwZuNseUOtCBrqOYHcD5XVoTmAIKIi70mKv7k5bYhXQvmrZDwaWq+lM7oaQtBTNrDwO+oLfPFtRrOpck3NLvkUnZXcf4q5dAKY8KxdH0oV/dC/FXqgoge7hnqzpBRDiD9yh8vSFTF/p0+NfJ5F6hnidOBizcGlquCTz0KnB/LYwt41mMbICIyfMyRVghUtTFamavUUDNEeCjlqZL4YN0pWZ4tusFwQ5YbH+2/Iwq47RVepVjLS+lEaIiQwl6M+NqtyLZg43DR3nMvrfppbnSLelcqkkr7Ij3T0nUGIXLwk/94SG4sGmPk2x/bzlRq4qr9sVmMJVxEfBsS0KeRN9HjFcf3wXaau3Kmb0ln3YVw7Lp8Czyp0oMXKglAiuSGr7ejeuBxW/2mPB/T1Q6a8Ali+yNrf1EBB8qMi/jYledTNYWddsAAxVz/ApAxJ+8qo02/adHpsFuz3hHVEhFHG7Rv2RVUaT2hUT9/TzaCUDZFvahaUlFc7m1hYogcwOrjmsMBkrYqWcrB93GdGU3kyZx9YnPriiRBOPkwYG8aftFi8AuW7RqW7UJ3UwHszOc8iAtvtPYfe+yuP12ZNQG06OdtVdCLhJjAIJiAq8EwAwc+0/7lVIalsRW5HA9Iua5TVmT4f82XXaFrgvefAmQj2VhXi2Bg=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM0PR08MB3745.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(1800799015)(376005)(366007)(38070700009);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="utf-8"
Content-ID: <36CB8BED529EBF4CB61EDFF6ADE659E1@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR08MB5915
Original-Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 AM4PEPF00025F9B.EURPRD83.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	f6bbd5e7-361d-42af-1616-08dc4aac316c
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	E6JUPe9W+Ybq2OYO1sOCFKuIE+L2/g0WMZwdQCfEP/MmKNfdEBltcFlp1/wYjILvrBdVZiAL1/HEuwLUvoTGipK6USMEXSb3eV0vgI3HsWnpnWlu911hZuyuOHJWeGGJFpu2lQP1GkiZjzSd2EVCy7t1npIAE/4/ji4WZEbCHaKVCMk+7kffWTFzHvHn2c/z06WYvABt5YpOTYh0SJ6ktTpzL922UFjuwczL0kTd5BMPfymJMcBF8GvJP1K5jKm360NI+d62LTVeeStmm4Rqe779CyYcjugdzUOFfeg0ymjADn/MGsmoZkpPZcCtHmfrG8qdG/+58tY+y2HvWw85upbKRz8FVJSFlDRZI7FAofFEzsBpLXmixom3qv9zcWtwt1mgErv0fumXr1iWsJRzMDYw5aOY+8IGQlrVbaXdyQlSqs/IlMLs/nJadJryxWaJBLnkSw1ekUOzrcGw75DyKPLyq2NWsJF1NjcJquQUfdbHmuWw49LDFjqAE4Qpk+vf2QfbRxQ5LnpoYvbKcZ52iVx2sQ4JfrU9UXklr7+sN4nT/Xc6hS8hNljM+1Dhse+qh5V7pcEfUdl8qKcEXNUeKWtqUxBw1xFEpnW2nxJhqhdLQuZXSTn+e3rednTj676OJnKenvciFWcg0EyfgZH6kx0nOHN9G30/xNruEJjVQcvHHlSV+z77oauC3rKYS4mRp9l+/2FQtnnCa2QaoykeSA==
X-Forefront-Antispam-Report:
	CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com;CAT:NONE;SFS:(13230031)(36860700004)(82310400014)(1800799015)(376005);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Mar 2024 20:11:13.9468
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 628b1bef-b378-452d-48fe-08dc4aac398c
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-AuthSource:
	AM4PEPF00025F9B.EURPRD83.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR08MB5581

DQoNCj4gT24gMjIgTWFyIDIwMjQsIGF0IDE1OjA5LCBNaWNoYWwgT3J6ZWwgPG1pY2hhbC5vcnpl
bEBhbWQuY29tPiB3cm90ZToNCj4gDQo+IEhpIEx1Y2EsDQo+IA0KPiBOSVQ6IHRpdGxlIHMvZm9y
L2Zyb20/DQo+IA0KPiBPbiAxMi8wMy8yMDI0IDE0OjAzLCBMdWNhIEZhbmNlbGx1IHdyb3RlOg0K
Pj4gDQo+PiANCj4+IEZyb206IFBlbm55IFpoZW5nIDxQZW5ueS5aaGVuZ0Bhcm0uY29tPg0KPj4g
DQo+PiBTdGF0aWMgc2hhcmVkIG1lbW9yeSBhY3RzIGFzIHJlc2VydmVkIG1lbW9yeSBpbiBndWVz
dCwgc28gaXQgc2hhbGwgYmUNCj4+IGV4Y2x1ZGVkIGZyb20gZXh0ZW5kZWQgcmVnaW9ucy4NCj4+
IA0KPj4gRXh0ZW5kZWQgcmVnaW9ucyBhcmUgdGFrZW4gY2FyZSBvZiB1bmRlciB0aHJlZSBkaWZm
ZXJlbnQgc2NlbmFyaW9zOg0KPj4gbm9ybWFsIERvbVUsIGRpcmVjdC1tYXAgZG9tYWluIHdpdGgg
aW9tbXUgb24sIGFuZCBkaXJlY3QtbWFwIGRvbWFpbg0KPj4gd2l0aCBpb21tdSBvZmYuDQo+PiAN
Cj4+IEZvciBub3JtYWwgRG9tVSwgd2UgY3JlYXRlIGEgbmV3IGZ1bmN0aW9uICJyZW1vdmVfc2ht
X2hvbGVzX2Zvcl9kb21VIiwNCj4+IHRvIGZpcnN0bHkgdHJhbnNmZXIgb3JpZ2luYWwgb3V0cHV0
cyBpbnRvIHRoZSBmb3JtYXQgb2YNCj4+ICJzdHJ1Y3QgcmFuZ2VzZXQiLCB0aGVuIHVzZSAicmVt
b3ZlX3NobV9mcm9tX3Jhbmdlc2V0IiB0byByZW1vdmUgc3RhdGljDQo+PiBzaG0gZnJvbSB0aGVt
Lg0KPj4gDQo+PiBGb3IgZGlyZWN0LW1hcCBkb21haW4gd2l0aCBpb21tdSBvbiwgYWZ0ZXIgd2Ug
Z2V0IGd1ZXN0IHNobSBpbmZvIGZyb20gImtpbmZvIiwNCj4+IHdlIHVzZSAicmVtb3ZlX3NobV9m
cm9tX3Jhbmdlc2V0IiB0byByZW1vdmUgc3RhdGljIHNobS4NCj4+IA0KPj4gRm9yIGRpcmVjdC1t
YXAgZG9tYWluIHdpdGggaW9tbXUgb2ZmLCBhcyBzdGF0aWMgc2htIGhhcyBhbHJlYWR5IGJlZW4g
dGFrZW4NCj4+IGNhcmUgb2YgdGhyb3VnaCByZXNlcnZlZCBtZW1vcnkgYmFua3MsIHdlIGRvIG5v
dGhpbmcuDQo+PiANCj4+IFNpZ25lZC1vZmYtYnk6IFBlbm55IFpoZW5nIDxwZW5ueS56aGVuZ0Bh
cm0uY29tPg0KPj4gU2lnbmVkLW9mZi1ieTogTHVjYSBGYW5jZWxsdSA8bHVjYS5mYW5jZWxsdUBh
cm0uY29tPg0KPj4gLS0tDQo+PiB2MToNCj4+IC0gUmV3b3JrIG9mIGh0dHBzOi8vcGF0Y2h3b3Jr
Lmtlcm5lbC5vcmcvcHJvamVjdC94ZW4tZGV2ZWwvcGF0Y2gvMjAyMzEyMDYwOTA2MjMuMTkzMjI3
NS04LVBlbm55LlpoZW5nQGFybS5jb20vDQo+PiAtLS0NCj4+IHhlbi9hcmNoL2FybS9kb21haW5f
YnVpbGQuYyAgICAgICAgICAgICB8IDE2ICsrKystDQo+PiB4ZW4vYXJjaC9hcm0vaW5jbHVkZS9h
c20vZG9tYWluX2J1aWxkLmggfCAgMiArDQo+PiB4ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vc3Rh
dGljLXNobWVtLmggfCAxOCArKysrKysNCj4+IHhlbi9hcmNoL2FybS9zdGF0aWMtc2htZW0uYyAg
ICAgICAgICAgICB8IDg2ICsrKysrKysrKysrKysrKysrKysrKysrKysNCj4+IDQgZmlsZXMgY2hh
bmdlZCwgMTE5IGluc2VydGlvbnMoKyksIDMgZGVsZXRpb25zKC0pDQo+PiANCj4+IGRpZmYgLS1n
aXQgYS94ZW4vYXJjaC9hcm0vZG9tYWluX2J1aWxkLmMgYi94ZW4vYXJjaC9hcm0vZG9tYWluX2J1
aWxkLmMNCj4+IGluZGV4IDlmYWQ5ZThiMmM0MC4uNzQwYzQ4M2VhMmRiIDEwMDY0NA0KPj4gLS0t
IGEveGVuL2FyY2gvYXJtL2RvbWFpbl9idWlsZC5jDQo+PiArKysgYi94ZW4vYXJjaC9hcm0vZG9t
YWluX2J1aWxkLmMNCj4+IEBAIC04MTcsOCArODE3LDggQEAgaW50IF9faW5pdCBtYWtlX21lbW9y
eV9ub2RlKGNvbnN0IHN0cnVjdCBkb21haW4gKmQsDQo+PiAgICAgcmV0dXJuIHJlczsNCj4+IH0N
Cj4+IA0KPj4gLXN0YXRpYyBpbnQgX19pbml0IGFkZF9leHRfcmVnaW9ucyh1bnNpZ25lZCBsb25n
IHNfZ2ZuLCB1bnNpZ25lZCBsb25nIGVfZ2ZuLA0KPj4gLSAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICB2b2lkICpkYXRhKQ0KPj4gK2ludCBfX2luaXQgYWRkX2V4dF9yZWdpb25zKHVu
c2lnbmVkIGxvbmcgc19nZm4sIHVuc2lnbmVkIGxvbmcgZV9nZm4sDQo+PiArICAgICAgICAgICAg
ICAgICAgICAgICAgICAgdm9pZCAqZGF0YSkNCj4+IHsNCj4+ICAgICBzdHJ1Y3QgbWVtYmFua3Mg
KmV4dF9yZWdpb25zID0gZGF0YTsNCj4+ICAgICBwYWRkcl90IHN0YXJ0LCBzaXplOw0KPj4gQEAg
LTk2OSw2ICs5NjksOCBAQCBzdGF0aWMgaW50IF9faW5pdCBoYW5kbGVfcGNpX3JhbmdlKGNvbnN0
IHN0cnVjdCBkdF9kZXZpY2Vfbm9kZSAqZGV2LA0KPj4gICogLSBNTUlPDQo+PiAgKiAtIEhvc3Qg
UkFNDQo+PiAgKiAtIFBDSSBhcGVydHVyZQ0KPj4gKyAqIC0gU3RhdGljIHNoYXJlZCBtZW1vcnkg
cmVnaW9ucywgd2hpY2ggYXJlIGRlc2NyaWJlZCBieSBzcGVjaWFsIHByb3BlcnR5DQo+PiArICog
ICAieGVuLGRvbWFpbi1zaGFyZWQtbWVtb3J5LXYxIg0KPiBJJ20gbm90IHN1cmUgaWYgcHJvdmlk
aW5nIGEgY29tcGF0aWJsZSBoZXJlIG1ha2VzIHNlbnNlLiBJZiBhdCBhbGwsIEkgd291bGQgcHV0
ICJ4ZW4sc2hhcmVkLW1lbSIgd2hpY2ggaG9sZHMgdGhlIGFkZHJlc3Nlcy4NCj4gDQo+PiAgKi8N
Cj4+IHN0YXRpYyBpbnQgX19pbml0IGZpbmRfbWVtb3J5X2hvbGVzKGNvbnN0IHN0cnVjdCBrZXJu
ZWxfaW5mbyAqa2luZm8sDQo+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBz
dHJ1Y3QgbWVtYmFua3MgKmV4dF9yZWdpb25zKQ0KPj4gQEAgLTk4NSw2ICs5ODcsMTEgQEAgc3Rh
dGljIGludCBfX2luaXQgZmluZF9tZW1vcnlfaG9sZXMoY29uc3Qgc3RydWN0IGtlcm5lbF9pbmZv
ICpraW5mbywNCj4+ICAgICBpZiAoICFtZW1faG9sZXMgKQ0KPj4gICAgICAgICByZXR1cm4gLUVO
T01FTTsNCj4+IA0KPj4gKyAgICAvKiBSZW1vdmUgc3RhdGljIHNoYXJlZCBtZW1vcnkgcmVnaW9u
cyAqLw0KPj4gKyAgICByZXMgPSByZW1vdmVfc2htX2Zyb21fcmFuZ2VzZXQoa2luZm8sIG1lbV9o
b2xlcyk7DQo+PiArICAgIGlmICggcmVzICkNCj4+ICsgICAgICAgIGdvdG8gb3V0Ow0KPiBIb3cg
Y2FuIHlvdSByZW1vdmUgZnJvbSBhIHJhbmdlc2V0IHdpdGhvdXQgZmlyc3QgYWRkaW5nIHRvIGl0
Pw0KPiBUaGlzIHNob3VsZCBiZSBtb3ZlZCBhZnRlciByYW5nZXNldF9hZGRfcmFuZ2UoKS4NCg0K
WW91IGFyZSB2ZXJ5IHJpZ2h0DQoNCj4gQWxzbywgdXN1YWxseSAoYW5kIHRoaXMgaXMgdGhlIGNh
c2UgaW4gdGhpcyBmdW5jdGlvbikgd2UgcGFzcyBmcmFtZXMNCj4gdG8gcmFuZ2VzZXQgYW5kIG5v
dCBhZGRyZXNzZXMgKGFyZ3VtZW50IGlzIG9mIHR5cGUgdWwpLiBIb3dldmVyLi4uDQo+IA0KPj4g
Kw0KPj4gICAgIC8qIFN0YXJ0IHdpdGggbWF4aW11bSBwb3NzaWJsZSBhZGRyZXNzYWJsZSBwaHlz
aWNhbCBtZW1vcnkgcmFuZ2UgKi8NCj4+ICAgICBzdGFydCA9IDA7DQo+PiAgICAgZW5kID0gKDFV
TEwgPDwgcDJtX2lwYV9iaXRzKSAtIDE7DQo+PiBAQCAtMTA4OSw3ICsxMDk2LDEwIEBAIHN0YXRp
YyBpbnQgX19pbml0IGZpbmRfZG9tVV9ob2xlcyhjb25zdCBzdHJ1Y3Qga2VybmVsX2luZm8gKmtp
bmZvLA0KPj4gICAgICAgICByZXMgPSAwOw0KPj4gICAgIH0NCj4+IA0KPj4gLSAgICByZXR1cm4g
cmVzOw0KPj4gKyAgICBpZiAoIHJlcyApDQo+PiArICAgICAgICByZXR1cm4gcmVzOw0KPj4gKw0K
Pj4gKyAgICByZXR1cm4gcmVtb3ZlX3NobV9ob2xlc19mb3JfZG9tVShraW5mbywgZXh0X3JlZ2lv
bnMpOw0KPj4gfQ0KPj4gDQo+PiBpbnQgX19pbml0IG1ha2VfaHlwZXJ2aXNvcl9ub2RlKHN0cnVj
dCBkb21haW4gKmQsDQo+PiBkaWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL2Rv
bWFpbl9idWlsZC5oIGIveGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL2RvbWFpbl9idWlsZC5oDQo+
PiBpbmRleCBhNmYyNzZjYzQyNjMuLjAyNmQ5NzVkYTI4ZSAxMDA2NDQNCj4+IC0tLSBhL3hlbi9h
cmNoL2FybS9pbmNsdWRlL2FzbS9kb21haW5fYnVpbGQuaA0KPj4gKysrIGIveGVuL2FyY2gvYXJt
L2luY2x1ZGUvYXNtL2RvbWFpbl9idWlsZC5oDQo+PiBAQCAtNTEsNiArNTEsOCBAQCBzdGF0aWMg
aW5saW5lIGludCBwcmVwYXJlX2FjcGkoc3RydWN0IGRvbWFpbiAqZCwgc3RydWN0IGtlcm5lbF9p
bmZvICpraW5mbykNCj4+IGludCBwcmVwYXJlX2FjcGkoc3RydWN0IGRvbWFpbiAqZCwgc3RydWN0
IGtlcm5lbF9pbmZvICpraW5mbyk7DQo+PiAjZW5kaWYNCj4+IA0KPj4gK2ludCBhZGRfZXh0X3Jl
Z2lvbnModW5zaWduZWQgbG9uZyBzX2dmbiwgdW5zaWduZWQgbG9uZyBlX2dmbiwgdm9pZCAqZGF0
YSk7DQo+PiArDQo+PiAjZW5kaWYNCj4+IA0KPj4gLyoNCj4+IGRpZmYgLS1naXQgYS94ZW4vYXJj
aC9hcm0vaW5jbHVkZS9hc20vc3RhdGljLXNobWVtLmggYi94ZW4vYXJjaC9hcm0vaW5jbHVkZS9h
c20vc3RhdGljLXNobWVtLmgNCj4+IGluZGV4IGM2ZmFjOTkwNjY1Ni4uMmY3MGFlZDUzYWM3IDEw
MDY0NA0KPj4gLS0tIGEveGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL3N0YXRpYy1zaG1lbS5oDQo+
PiArKysgYi94ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vc3RhdGljLXNobWVtLmgNCj4+IEBAIC0y
OSw2ICsyOSwxMiBAQCB2b2lkIGVhcmx5X3ByaW50X2luZm9fc2htZW0odm9pZCk7DQo+PiANCj4+
IHZvaWQgaW5pdF9zaGFyZWRtZW1fcGFnZXModm9pZCk7DQo+PiANCj4+ICtpbnQgcmVtb3ZlX3No
bV9mcm9tX3Jhbmdlc2V0KGNvbnN0IHN0cnVjdCBrZXJuZWxfaW5mbyAqa2luZm8sDQo+PiArICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBzdHJ1Y3QgcmFuZ2VzZXQgKnJhbmdlc2V0KTsNCj4+
ICsNCj4+ICtpbnQgcmVtb3ZlX3NobV9ob2xlc19mb3JfZG9tVShjb25zdCBzdHJ1Y3Qga2VybmVs
X2luZm8gKmtpbmZvLA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0cnVjdCBt
ZW1iYW5rcyAqZXh0X3JlZ2lvbnMpOw0KPj4gKw0KPj4gI2Vsc2UgLyogIUNPTkZJR19TVEFUSUNf
U0hNICovDQo+PiANCj4+IHN0YXRpYyBpbmxpbmUgaW50IG1ha2VfcmVzdl9tZW1vcnlfbm9kZShj
b25zdCBzdHJ1Y3QgZG9tYWluICpkLA0KPj4gQEAgLTYxLDYgKzY3LDE4IEBAIHN0YXRpYyBpbmxp
bmUgdm9pZCBlYXJseV9wcmludF9pbmZvX3NobWVtKHZvaWQpIHt9Ow0KPj4gDQo+PiBzdGF0aWMg
aW5saW5lIHZvaWQgaW5pdF9zaGFyZWRtZW1fcGFnZXModm9pZCkge307DQo+PiANCj4+ICtzdGF0
aWMgaW5saW5lIGludCByZW1vdmVfc2htX2Zyb21fcmFuZ2VzZXQoY29uc3Qgc3RydWN0IGtlcm5l
bF9pbmZvICpraW5mbywNCj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgc3RydWN0IHJhbmdlc2V0ICpyYW5nZXNldCkNCj4+ICt7DQo+PiArICAgIHJldHVybiAw
Ow0KPj4gK30NCj4+ICsNCj4+ICtzdGF0aWMgaW5saW5lIGludCByZW1vdmVfc2htX2hvbGVzX2Zv
cl9kb21VKGNvbnN0IHN0cnVjdCBrZXJuZWxfaW5mbyAqa2luZm8sDQo+PiArICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHJ1Y3QgbWVtYmFua3MgKmV4dF9yZWdp
b25zKQ0KPj4gK3sNCj4+ICsgICAgcmV0dXJuIDA7DQo+PiArfQ0KPj4gKw0KPj4gI2VuZGlmIC8q
IENPTkZJR19TVEFUSUNfU0hNICovDQo+PiANCj4+ICNlbmRpZiAvKiBfX0FTTV9TVEFUSUNfU0hN
RU1fSF8gKi8NCj4+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0vc3RhdGljLXNobWVtLmMgYi94
ZW4vYXJjaC9hcm0vc3RhdGljLXNobWVtLmMNCj4+IGluZGV4IDYxNDNmNTJjYjk5MS4uYjNlMjEw
NWRkM2YyIDEwMDY0NA0KPj4gLS0tIGEveGVuL2FyY2gvYXJtL3N0YXRpYy1zaG1lbS5jDQo+PiAr
KysgYi94ZW4vYXJjaC9hcm0vc3RhdGljLXNobWVtLmMNCj4+IEBAIC0xLDYgKzEsNyBAQA0KPj4g
LyogU1BEWC1MaWNlbnNlLUlkZW50aWZpZXI6IEdQTC0yLjAtb25seSAqLw0KPj4gDQo+PiAjaW5j
bHVkZSA8eGVuL2xpYmZkdC9saWJmZHQuaD4NCj4+ICsjaW5jbHVkZSA8eGVuL3Jhbmdlc2V0Lmg+
DQo+PiAjaW5jbHVkZSA8eGVuL3NjaGVkLmg+DQo+PiANCj4+ICNpbmNsdWRlIDxhc20vZG9tYWlu
X2J1aWxkLmg+DQo+PiBAQCAtNTY0LDYgKzU2NSw5MSBAQCB2b2lkIF9faW5pdCBpbml0X3NoYXJl
ZG1lbV9wYWdlcyh2b2lkKQ0KPj4gICAgICAgICBpbml0X3N0YXRpY21lbV9iYW5rKCZzaG1lbS0+
YmFua1tiYW5rXSk7DQo+PiB9DQo+PiANCj4+ICtpbnQgX19pbml0IHJlbW92ZV9zaG1fZnJvbV9y
YW5nZXNldChjb25zdCBzdHJ1Y3Qga2VybmVsX2luZm8gKmtpbmZvLA0KPj4gKyAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIHN0cnVjdCByYW5nZXNldCAqcmFuZ2VzZXQpDQo+PiAr
ew0KPj4gKyAgICBjb25zdCBzdHJ1Y3QgbWVtYmFua3MgKnNobV9tZW0gPSAma2luZm8tPnNobV9t
ZW0uY29tbW9uOw0KPj4gKyAgICB1bnNpZ25lZCBpbnQgaTsNCj4+ICsNCj4+ICsgICAgLyogUmVt
b3ZlIHN0YXRpYyBzaGFyZWQgbWVtb3J5IHJlZ2lvbnMgKi8NCj4+ICsgICAgZm9yICggaSA9IDA7
IGkgPCBzaG1fbWVtLT5ucl9iYW5rczsgaSsrICkNCj4+ICsgICAgew0KPj4gKyAgICAgICAgcGFk
ZHJfdCBzdGFydCwgZW5kOw0KPiAuLi4gaGVyZSwgdGhlc2UgaG9sZCBwaHlzaWNhbCBhZGRyZXNz
ZXMgYW5kLi4uDQo+IA0KPj4gKyAgICAgICAgaW50IHJlczsNCj4+ICsNCj4+ICsgICAgICAgIHN0
YXJ0ID0gc2htX21lbS0+YmFua1tpXS5zdGFydDsNCj4+ICsgICAgICAgIGVuZCA9IHNobV9tZW0t
PmJhbmtbaV0uc3RhcnQgKyBzaG1fbWVtLT5iYW5rW2ldLnNpemUgLSAxOw0KPj4gKyAgICAgICAg
cmVzID0gcmFuZ2VzZXRfcmVtb3ZlX3JhbmdlKHJhbmdlc2V0LCBzdGFydCwgZW5kKTsNCj4geW91
IHdpbGwgZW5kIHVwIGluIGEgbWl4IHdoaWNoIHdvbid0IHdvcmsuIFN3aXRjaCB0byBQRk5fRE9X
TigpDQoNCldpbGwgZml4DQoNCj4gDQo+PiArICAgICAgICBpZiAoIHJlcyApDQo+IFdoYXQncyB0
aGUgcG9pbnQgb2YgcmVzIHZhcmlhYmxlIGlmIGl0IGlzIG5vdCBwcmludGVkIGJlbG93Pw0KDQpJ
IGd1ZXNzIHRoaXMgcGFydCB3YXMgY29waWVkIGZyb20gZmluZF9tZW1vcnlfaG9sZXMgd2hpY2gg
ZG9lc27igJl0IHByaW50IG91dCByZXMsDQphbnl3YXkgeW91IGFyZSByaWdodCwgd2Ugc2hvdWxk
IHByaW50IGl0Lg0KDQo+IA0KPj4gKyAgICAgICAgew0KPj4gKyAgICAgICAgICAgIHByaW50ayhY
RU5MT0dfRVJSICJGYWlsZWQgdG8gcmVtb3ZlOiAlIyJQUklwYWRkciItPiUjIlBSSXBhZGRyIlxu
IiwNCj4+ICsgICAgICAgICAgICAgICAgICAgc3RhcnQsIGVuZCk7DQo+PiArICAgICAgICAgICAg
cmV0dXJuIC1FSU5WQUw7DQo+PiArICAgICAgICB9DQo+PiArICAgIH0NCj4+ICsNCj4+ICsgICAg
cmV0dXJuIDA7DQo+PiArfQ0KPj4gKw0KPj4gK2ludCBfX2luaXQgcmVtb3ZlX3NobV9ob2xlc19m
b3JfZG9tVShjb25zdCBzdHJ1Y3Qga2VybmVsX2luZm8gKmtpbmZvLA0KPj4gKyAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBzdHJ1Y3QgbWVtYmFua3MgKmV4dF9yZWdpb25zKQ0K
Pj4gK3sNCj4+ICsgICAgY29uc3Qgc3RydWN0IG1lbWJhbmtzICpzaG1fbWVtID0gJmtpbmZvLT5z
aG1fbWVtLmNvbW1vbjsNCj4+ICsgICAgc3RydWN0IHJhbmdlc2V0ICpndWVzdF9ob2xlczsNCj4+
ICsgICAgdW5zaWduZWQgaW50IGk7DQo+PiArICAgIHBhZGRyX3Qgc3RhcnQ7DQo+PiArICAgIHBh
ZGRyX3QgZW5kOw0KPj4gKyAgICBpbnQgcmVzOw0KPj4gKw0KPj4gKyAgICAvKiBObyBzdGF0aWMg
c2hhcmVkIG1lbW9yeSByZWdpb24uICovDQo+PiArICAgIGlmICggc2htX21lbS0+bnJfYmFua3Mg
PT0gMCApDQo+PiArICAgICAgICByZXR1cm4gMDsNCj4+ICsNCj4+ICsgICAgZHRfZHByaW50aygi
UmVtb3ZlIHN0YXRpYyBzaGFyZWQgbWVtb3J5IGhvbGVzIGZvciBleHRlbmRlZCByZWdpb25zIG9m
IERvbVVcbiIpOw0KPj4gKw0KPj4gKyAgICBndWVzdF9ob2xlcyA9IHJhbmdlc2V0X25ldyhOVUxM
LCBOVUxMLCAwKTsNCj4+ICsgICAgaWYgKCAhZ3Vlc3RfaG9sZXMgKQ0KPj4gKyAgICAgICAgcmV0
dXJuIC1FTk9NRU07DQo+PiArDQo+PiArICAgIC8qIENvcHkgZXh0ZW5kZWQgcmVnaW9ucyBzZXRz
IGludG8gdGhlIHJhbmdlc2V0ICovDQo+PiArICAgIGZvciAoIGkgPSAwOyBpIDwgZXh0X3JlZ2lv
bnMtPm5yX2JhbmtzOyBpKysgKQ0KPj4gKyAgICB7DQo+PiArICAgICAgICBzdGFydCA9IGV4dF9y
ZWdpb25zLT5iYW5rW2ldLnN0YXJ0Ow0KPj4gKyAgICAgICAgZW5kID0gc3RhcnQgKyBleHRfcmVn
aW9ucy0+YmFua1tpXS5zaXplIC0gMTsNCj4+ICsNCj4+ICsgICAgICAgIHJlcyA9IHJhbmdlc2V0
X2FkZF9yYW5nZShndWVzdF9ob2xlcywgc3RhcnQsIGVuZCk7DQo+IERpdHRvLCBQRk5fRE9XTigp
Lg0KDQpUaGFua3MgZm9yIHRoZSByZXZpZXcsIEkgd2lsbCBmaXggdGhlIGlzc3VlcyBpbiB0aGUg
bmV4dCBwdXNoLCBJ4oCZbGwganVzdCB3YWl0DQpmb3IgdGhlIHNlcmllIHRvIGJlIGZ1bGx5IHJl
dmlld2VkLCBvciBpZiB5b3UgZG9u4oCZdCB3YW50IHRvIGNoZWNrIHRoZSByZW1haW5pbmcNCnR3
byBwYXRjaGVzIGJlZm9yZSBJIGZpeCB0aGUgcHJldmlvdXMgY29tbWVudHMsIGp1c3QgbGV0IG1l
IGtub3cuDQoNCj4gDQo+IH5NaWNoYWwNCg0K


From xen-devel-bounces@lists.xenproject.org Sat Mar 23 01:29:38 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Mar 2024 01:29:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697119.1088351 (Exim 4.92)
	(envelope-from )
	id 1rnqCI-0005L7-CC; Sat, 23 Mar 2024 01:29:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697119.1088351; Sat, 23 Mar 2024 01:29:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnqCI-0005L0-98; Sat, 23 Mar 2024 01:29:22 +0000
Received: by outflank-mailman (input) for mailman id 697119;
 Sat, 23 Mar 2024 01:29:21 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rnqCH-0005Ku-5t
 for xen-devel@lists.xenproject.org; Sat, 23 Mar 2024 01:29:21 +0000
Received: from sender4-of-o51.zoho.com (sender4-of-o51.zoho.com
 [136.143.188.51]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c3a70c96-e8b4-11ee-afe1-a90da7624cb6;
 Sat, 23 Mar 2024 02:29:18 +0100 (CET)
Received: from [10.10.1.138] (static-72-81-132-2.bltmmd.fios.verizon.net
 [72.81.132.2]) by mx.zohomail.com
 with SMTPS id 1711157347375917.7851616263396;
 Fri, 22 Mar 2024 18:29:07 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c3a70c96-e8b4-11ee-afe1-a90da7624cb6
ARC-Seal: i=1; a=rsa-sha256; t=1711157349; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=J+MP7PdWsrbmno22Mc2jtHO8RSz/AlfSNoxcCSeawabULAnLf6G0l/xcuC5C2Km1CviWxRM3J69mfamqbiPkk17JbJFt9jtSx0qTlY1znavTOWCPqchqtaaw56C9jsguefb9yiNStzY019rFtkja69RYyFZgqzJvUttV2KKO9rY=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1711157349; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=CmnQVr8hWXf7ajkhItGlGUfJzZOBKLn7jl0qxfpf5+o=; 
	b=OOv5gV4HtFakiKc2yJbvwvwSOtHEnchVtSqt2+YEmZsJCsmEHL/8AyuaUxWTgBhZGq6DDDgsgislpKmllWoXNnUKMw9NY86q//Q0oFbalqU2wiooB1c3S2nQdez+itgJZzOzZPB8OOfgT4Sagw1vyDxN9qFYJ6KHnCvziUBzPJM=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=apertussolutions.com;
	spf=pass  smtp.mailfrom=dpsmith@apertussolutions.com;
	dmarc=pass header.from=
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1711157349;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=CmnQVr8hWXf7ajkhItGlGUfJzZOBKLn7jl0qxfpf5+o=;
	b=T75TmXJIq/huFiS/idwAkoAw83PmnxupMS7at7u+s9WvGSiJiwNzBLN5/zze9Dju
	zNZJGey+GD/pvT00LTFma3WaA6GTspTBGA59Tdy4SWFGJTqgNBdZ+KBska7YPm+am4G
	quQQ/7tk0rcy8JFmSmFMwZvZp+9VQ2yN9xAHW40E=
Message-ID: <2f66681a-8659-4735-be1f-370708da9f30@apertussolutions.com>
Date: Fri, 22 Mar 2024 21:29:05 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 02/11] xen/xsm: add parentheses to comply with MISRA C
 Rule 20.7
Content-Language: en-US
To: Nicola Vetrini ,
 xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com,
 ayan.kumar.halder@amd.com, consulting@bugseng.com, jbeulich@suse.com,
 andrew.cooper3@citrix.com, roger.pau@citrix.com, bertrand.marquis@arm.com,
 julien@xen.org
References: 
 <6cb601ef46a699f95eda0e10f4f9d15f1af4353e.1711118582.git.nicola.vetrini@bugseng.com>
From: "Daniel P. Smith" 
Autocrypt: addr=dpsmith@apertussolutions.com; keydata=
 xsJuBFYrueARCACPWL3r2bCSI6TrkIE/aRzj4ksFYPzLkJbWLZGBRlv7HQLvs6i/K4y/b4fs
 JDq5eL4e9BdfdnZm/b+K+Gweyc0Px2poDWwKVTFFRgxKWq9R7McwNnvuZ4nyXJBVn7PTEn/Z
 G7D08iZg94ZsnUdeXfgYdJrqmdiWA6iX9u84ARHUtb0K4r5WpLUMcQ8PVmnv1vVrs/3Wy/Rb
 foxebZNWxgUiSx+d02e3Ad0aEIur1SYXXv71mqKwyi/40CBSHq2jk9eF6zmEhaoFi5+MMMgX
 X0i+fcBkvmT0N88W4yCtHhHQds+RDbTPLGm8NBVJb7R5zbJmuQX7ADBVuNYIU8hx3dF3AQCm
 601w0oZJ0jGOV1vXQgHqZYJGHg5wuImhzhZJCRESIwf+PJxik7TJOgBicko1hUVOxJBZxoe0
 x+/SO6tn+s8wKlR1Yxy8gYN9ZRqV2I83JsWZbBXMG1kLzV0SAfk/wq0PAppA1VzrQ3JqXg7T
 MZ3tFgxvxkYqUP11tO2vrgys+InkZAfjBVMjqXWHokyQPpihUaW0a8mr40w9Qui6DoJj7+Gg
 DtDWDZ7Zcn2hoyrypuht88rUuh1JuGYD434Q6qwQjUDlY+4lgrUxKdMD8R7JJWt38MNlTWvy
 rMVscvZUNc7gxcmnFUn41NPSKqzp4DDRbmf37Iz/fL7i01y7IGFTXaYaF3nEACyIUTr/xxi+
 MD1FVtEtJncZNkRn7WBcVFGKMAf+NEeaeQdGYQ6mGgk++i/vJZxkrC/a9ZXme7BhWRP485U5
 sXpFoGjdpMn4VlC7TFk2qsnJi3yF0pXCKVRy1ukEls8o+4PF2JiKrtkCrWCimB6jxGPIG3lk
 3SuKVS/din3RHz+7Sr1lXWFcGYDENmPd/jTwr1A1FiHrSj+u21hnJEHi8eTa9029F1KRfocp
 ig+k0zUEKmFPDabpanI323O5Tahsy7hwf2WOQwTDLvQ+eqQu40wbb6NocmCNFjtRhNZWGKJS
 b5GrGDGu/No5U6w73adighEuNcCSNBsLyUe48CE0uTO7eAL6Vd+2k28ezi6XY4Y0mgASJslb
 NwW54LzSSM0uRGFuaWVsIFAuIFNtaXRoIDxkcHNtaXRoQGFwZXJ0dXNzb2x1dGlvbnMuY29t
 PsJ6BBMRCAAiBQJWK7ngAhsjBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRBTc6WbYpR8
 KrQ9AP94+xjtFfJ8gj5c7PVx06Zv9rcmFUqQspZ5wSEkvxOuQQEAg6qEsPYegI7iByLVzNEg
 7B7fUG7pqWIfMqFwFghYhQzOwU0EViu54BAIAL6MXXNlrJ5tRUf+KMBtVz1LJQZRt/uxWrCb
 T06nZjnbp2UcceuYNbISOVHGXTzu38r55YzpkEA8eURQf+5hjtvlrOiHxvpD+Z6WcpV6rrMB
 kcAKWiZTQihW2HoGgVB3gwG9dCh+n0X5OzliAMiGK2a5iqnIZi3o0SeW6aME94bSkTkuj6/7
 OmH9KAzK8UnlhfkoMg3tXW8L6/5CGn2VyrjbB/rcrbIR4mCQ+yCUlocuOjFCJhBd10AG1IcX
 OXUa/ux+/OAV9S5mkr5Fh3kQxYCTcTRt8RY7+of9RGBk10txi94dXiU2SjPbassvagvu/hEi
 twNHms8rpkSJIeeq0/cAAwUH/jV3tXpaYubwcL2tkk5ggL9Do+/Yo2WPzXmbp8vDiJPCvSJW
 rz2NrYkd/RoX+42DGqjfu8Y04F9XehN1zZAFmCDUqBMa4tEJ7kOT1FKJTqzNVcgeKNBGcT7q
 27+wsqbAerM4A0X/F/ctjYcKwNtXck1Bmd/T8kiw2IgyeOC+cjyTOSwKJr2gCwZXGi5g+2V8
 NhJ8n72ISPnOh5KCMoAJXmCF+SYaJ6hIIFARmnuessCIGw4ylCRIU/TiXK94soilx5aCqb1z
 ke943EIUts9CmFAHt8cNPYOPRd20pPu4VFNBuT4fv9Ys0iv0XGCEP+sos7/pgJ3gV3pCOric
 p15jV4PCYQQYEQgACQUCViu54AIbDAAKCRBTc6WbYpR8Khu7AP9NJrBUn94C/3PeNbtQlEGZ
 NV46Mx5HF0P27lH3sFpNrwD/dVdZ5PCnHQYBZ287ZxVfVr4Zuxjo5yJbRjT93Hl0vMY=
In-Reply-To: <6cb601ef46a699f95eda0e10f4f9d15f1af4353e.1711118582.git.nicola.vetrini@bugseng.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External

On 3/22/24 12:01, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be safe with respect to expansions that
> can possibly alter the semantics of the passed-in macro parameter.
> 
> No functional change.
> 
> Signed-off-by: Nicola Vetrini 
> Reviewed-by: Stefano Stabellini 
> ---
>   xen/include/xsm/dummy.h | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
> index 8671af1ba4d3..88039fdd227c 100644
> --- a/xen/include/xsm/dummy.h
> +++ b/xen/include/xsm/dummy.h
> @@ -58,7 +58,7 @@ void __xsm_action_mismatch_detected(void);
>   
>   #define XSM_DEFAULT_ARG /* */
>   #define XSM_DEFAULT_VOID void
> -#define XSM_ASSERT_ACTION(def) xsm_default_t action = def; (void)action
> +#define XSM_ASSERT_ACTION(def) xsm_default_t action = (def); (void)action
>   
>   #else /* CONFIG_XSM */
>   
> @@ -71,7 +71,7 @@ void __xsm_action_mismatch_detected(void);
>   #define XSM_INLINE always_inline
>   #define XSM_DEFAULT_ARG xsm_default_t action,
>   #define XSM_DEFAULT_VOID xsm_default_t action
> -#define XSM_ASSERT_ACTION(def) LINKER_BUG_ON(def != action)
> +#define XSM_ASSERT_ACTION(def) LINKER_BUG_ON((def) != action)
>   
>   #endif /* CONFIG_XSM */
>   

Acked-by: Daniel P. Smith 


From xen-devel-bounces@lists.xenproject.org Sat Mar 23 04:33:46 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Mar 2024 04:33:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697136.1088361 (Exim 4.92)
	(envelope-from )
	id 1rnt4V-0006Cp-OQ; Sat, 23 Mar 2024 04:33:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697136.1088361; Sat, 23 Mar 2024 04:33:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnt4V-0006Ci-L5; Sat, 23 Mar 2024 04:33:31 +0000
Received: by outflank-mailman (input) for mailman id 697136;
 Sat, 23 Mar 2024 04:33:29 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnt4T-0006CY-NE; Sat, 23 Mar 2024 04:33:29 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnt4T-0002c9-D9; Sat, 23 Mar 2024 04:33:29 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnt4S-0003xk-WF; Sat, 23 Mar 2024 04:33:29 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rnt4S-00072e-Vs; Sat, 23 Mar 2024 04:33:28 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=2HO1rOYMHpbdDe9AhE4rNgdKtE6ek948xapCe/YmrYE=; b=ME7QdNYutfOztYKucs6GzAzn7f
	QABFdefW1oHX/jvEp7YuTUvJZ2ZyYw+77jtV8/vFhjz4q5G6qolz18ZblcgebibLC3OhCv7o8K69J
	NM4TBcBFBJ+hzFCZzysofpk88oySQVS4ftgXqjRi9C7ACKmS7sROJMWCP4j0AYqeaTBE=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 185140: tolerable FAIL
X-Osstest-Failures:
    xen-unstable:test-amd64-amd64-qemuu-freebsd11-amd64:guest-start:fail:heisenbug
    xen-unstable:test-armhf-armhf-libvirt-vhd:guest-start/debian.repeat:fail:heisenbug
    xen-unstable:test-armhf-armhf-xl-qcow2:guest-start:fail:heisenbug
    xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:windows-install:fail:heisenbug
    xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-qcow2:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-qcow2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-vhd:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-raw:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    xen=cbe393b709e0c6c3e2b10c3ac69fbea0abd530fe
X-Osstest-Versions-That:
    xen=cbe393b709e0c6c3e2b10c3ac69fbea0abd530fe
From: osstest service owner 
Date: Sat, 23 Mar 2024 04:33:28 +0000

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-qemuu-freebsd11-amd64 13 guest-start      fail pass in 185137
 test-armhf-armhf-libvirt-vhd 17 guest-start/debian.repeat  fail pass in 185137
 test-armhf-armhf-xl-qcow2    13 guest-start                fail pass in 185137
 test-amd64-amd64-xl-qemuu-win7-amd64 12 windows-install    fail pass in 185137

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop fail in 185137 blocked in 185140
 test-armhf-armhf-xl-qcow2   14 migrate-support-check fail in 185137 never pass
 test-armhf-armhf-xl-qcow2 15 saverestore-support-check fail in 185137 never pass
 test-armhf-armhf-libvirt     16 saverestore-support-check    fail  like 185137
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop            fail like 185137
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop            fail like 185137
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop            fail like 185137
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 185137
 test-amd64-amd64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      16 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-raw 14 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass
 test-armhf-armhf-xl-rtds     15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 15 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-check    fail  never pass
 test-armhf-armhf-libvirt     15 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-raw 14 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-raw 15 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-vhd      14 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-vhd      15 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qcow2 14 migrate-support-check        fail never pass
 test-armhf-armhf-libvirt-vhd 14 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-vhd 15 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-raw      14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-raw      15 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  16 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  cbe393b709e0c6c3e2b10c3ac69fbea0abd530fe
baseline version:
 xen                  cbe393b709e0c6c3e2b10c3ac69fbea0abd530fe

Last test of basis   185140  2024-03-22 09:57:48 Z    0 days
Testing same since                          (not found)         0 attempts

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       fail    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-libvirt-qcow2                               pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-xl-qcow2                                    fail    
 test-amd64-amd64-libvirt-raw                                 pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-amd64-amd64-xl-raw                                      pass    
 test-armhf-armhf-xl-raw                                      pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-libvirt-vhd                                 fail    
 test-amd64-amd64-xl-vhd                                      pass    
 test-arm64-arm64-xl-vhd                                      pass    


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

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

Explanation of these 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


Published tested tree is already up to date.



From xen-devel-bounces@lists.xenproject.org Sat Mar 23 05:22:59 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Mar 2024 05:22:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697141.1088370 (Exim 4.92)
	(envelope-from )
	id 1rntqH-0005nc-Be; Sat, 23 Mar 2024 05:22:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697141.1088370; Sat, 23 Mar 2024 05:22:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rntqH-0005nV-8r; Sat, 23 Mar 2024 05:22:53 +0000
Received: by outflank-mailman (input) for mailman id 697141;
 Sat, 23 Mar 2024 05:22:51 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rntqF-0005nF-S1; Sat, 23 Mar 2024 05:22:51 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rntqF-0004Ar-N6; Sat, 23 Mar 2024 05:22:51 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rntqF-00057P-9D; Sat, 23 Mar 2024 05:22:51 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rntqF-00054L-8k; Sat, 23 Mar 2024 05:22:51 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=NwZUdfj+Aavc3ooWrNFGSxxS2PMJwWfbuW6OrJ6H+Ns=; b=n0Tnr9JX91KTHuO8EDlBCIFHDv
	tPag4F/PwvISBl7MmdtoGtYsYfBBFMRzvBFMUu57z7jU/d8sENH7uEhleBtqR5EEBFu6oB+sdFa4Q
	+lUQnffr8NxAWkYWeRzjMv+ubJibBcOVqB6chrgR0MeLsIphTq7Ubp/73xGCe8lnZSBY=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 185142: regressions - FAIL
X-Osstest-Failures:
    linux-linus:build-arm64:xen-build:fail:regression
    linux-linus:build-arm64-libvirt:build-check(1):blocked:nonblocking
    linux-linus:test-arm64-arm64-examine:build-check(1):blocked:nonblocking
    linux-linus:test-arm64-arm64-libvirt-raw:build-check(1):blocked:nonblocking
    linux-linus:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking
    linux-linus:test-arm64-arm64-xl:build-check(1):blocked:nonblocking
    linux-linus:test-arm64-arm64-xl-credit1:build-check(1):blocked:nonblocking
    linux-linus:test-arm64-arm64-xl-credit2:build-check(1):blocked:nonblocking
    linux-linus:test-arm64-arm64-xl-thunderx:build-check(1):blocked:nonblocking
    linux-linus:test-arm64-arm64-xl-vhd:build-check(1):blocked:nonblocking
    linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-qcow2:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-qcow2:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-raw:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-vhd:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    linux=4f55aa85a8746e5e255c46c98c031e143605e2a0
X-Osstest-Versions-That:
    linux=23956900041d968f9ad0f30db6dede4daccd7aa9
From: osstest service owner 
Date: Sat, 23 Mar 2024 05:22:51 +0000

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64                   6 xen-build                fail REGR. vs. 185119

Tests which did not succeed, but are not blocking:
 build-arm64-libvirt           1 build-check(1)               blocked  n/a
 test-arm64-arm64-examine      1 build-check(1)               blocked  n/a
 test-arm64-arm64-libvirt-raw  1 build-check(1)               blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)               blocked  n/a
 test-arm64-arm64-xl           1 build-check(1)               blocked  n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)               blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)               blocked  n/a
 test-arm64-arm64-xl-thunderx  1 build-check(1)               blocked  n/a
 test-arm64-arm64-xl-vhd       1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop            fail like 185119
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop            fail like 185119
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop            fail like 185119
 test-armhf-armhf-libvirt     16 saverestore-support-check    fail  like 185119
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop            fail like 185119
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 185119
 test-arm64-arm64-xl-xsm      15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      16 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-multivcpu 15 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-credit2  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit2  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          16 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qcow2 14 migrate-support-check        fail never pass
 test-amd64-amd64-libvirt-raw 14 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-qcow2    14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-qcow2    15 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-raw      14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-raw      15 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass
 test-armhf-armhf-xl-arndale  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     16 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     15 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-vhd 14 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-vhd 15 saverestore-support-check    fail   never pass

version targeted for testing:
 linux                4f55aa85a8746e5e255c46c98c031e143605e2a0
baseline version:
 linux                23956900041d968f9ad0f30db6dede4daccd7aa9

Last test of basis   185119  2024-03-21 07:40:49 Z    1 days
Failing since        185136  2024-03-21 21:13:02 Z    1 days    3 attempts
Testing same since   185142  2024-03-22 17:42:10 Z    0 days    1 attempts

------------------------------------------------------------
439 people touched revisions under test,
not listing them all

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-arm64                                                  fail    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          blocked 
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          blocked 
 test-armhf-armhf-xl                                          pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 blocked 
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  blocked 
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  blocked 
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     blocked 
 test-armhf-armhf-examine                                     pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-libvirt-qcow2                               pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-xl-qcow2                                    pass    
 test-amd64-amd64-libvirt-raw                                 pass    
 test-arm64-arm64-libvirt-raw                                 blocked 
 test-amd64-amd64-xl-raw                                      pass    
 test-armhf-armhf-xl-raw                                      pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-arm64-arm64-xl-thunderx                                 blocked 
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-libvirt-vhd                                 pass    
 test-amd64-amd64-xl-vhd                                      pass    
 test-arm64-arm64-xl-vhd                                      blocked 


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

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

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    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 24886 lines long.)


From xen-devel-bounces@lists.xenproject.org Sat Mar 23 11:30:23 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Mar 2024 11:30:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697212.1088380 (Exim 4.92)
	(envelope-from )
	id 1rnzZg-0004KI-M1; Sat, 23 Mar 2024 11:30:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697212.1088380; Sat, 23 Mar 2024 11:30:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rnzZg-0004KB-JO; Sat, 23 Mar 2024 11:30:08 +0000
Received: by outflank-mailman (input) for mailman id 697212;
 Sat, 23 Mar 2024 11:30:07 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnzZf-0004K1-GN; Sat, 23 Mar 2024 11:30:07 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnzZf-0003VZ-9P; Sat, 23 Mar 2024 11:30:07 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rnzZe-00058u-Vv; Sat, 23 Mar 2024 11:30:07 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rnzZe-0007oN-V8; Sat, 23 Mar 2024 11:30:06 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=LrmbwHqNbKlyPodG2SjqbYNQn/NqfVXkrdJV2wLgP7E=; b=kZVFJiOfkjvCACfAr6Tm6XuXWF
	38imwGMs0KkAVLIMk9pWWZDFSC9o/uFf8rn8K7NfoTrB8Mj8TpayVuXqLNt96z184Xso3kLYn2FHB
	UCUXJ6H5KZuzQpyZ1fDzE1Z9oKaFjyRgUkRLLfKErhnYJR9tQThLB/H/LEQDwy63sETg=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 185143: tolerable FAIL
X-Osstest-Failures:
    xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-qcow2:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-qcow2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-vhd:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-raw:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    xen=cbe393b709e0c6c3e2b10c3ac69fbea0abd530fe
X-Osstest-Versions-That:
    xen=cbe393b709e0c6c3e2b10c3ac69fbea0abd530fe
From: osstest service owner 
Date: Sat, 23 Mar 2024 11:30:06 +0000

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen                  cbe393b709e0c6c3e2b10c3ac69fbea0abd530fe
baseline version:
 xen                  cbe393b709e0c6c3e2b10c3ac69fbea0abd530fe

Last test of basis   185143  2024-03-23 04:37:39 Z    0 days
Testing same since                          (not found)         0 attempts

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-libvirt-qcow2                               pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-xl-qcow2                                    pass    
 test-amd64-amd64-libvirt-raw                                 pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-amd64-amd64-xl-raw                                      pass    
 test-armhf-armhf-xl-raw                                      pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-libvirt-vhd                                 pass    
 test-amd64-amd64-xl-vhd                                      pass    
 test-arm64-arm64-xl-vhd                                      pass    


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

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

Explanation of these 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


Published tested tree is already up to date.



From xen-devel-bounces@lists.xenproject.org Sat Mar 23 16:32:56 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Mar 2024 16:32:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697303.1088392 (Exim 4.92)
	(envelope-from )
	id 1ro4IM-0000uH-UA; Sat, 23 Mar 2024 16:32:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697303.1088392; Sat, 23 Mar 2024 16:32:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1ro4IM-0000uA-OX; Sat, 23 Mar 2024 16:32:34 +0000
Received: by outflank-mailman (input) for mailman id 697303;
 Sat, 23 Mar 2024 16:32:33 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1ro4IL-0000tz-Pn; Sat, 23 Mar 2024 16:32:33 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1ro4IL-0000iC-FE; Sat, 23 Mar 2024 16:32:33 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1ro4IL-0003yZ-2D; Sat, 23 Mar 2024 16:32:33 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1ro4IL-00019C-1a; Sat, 23 Mar 2024 16:32:33 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=Uw6wCCD5BKp5hyY6109Mf8vPeVNbJNlmM0Ftlmd9Qzo=; b=RIpuPhFua3TOgkcEgeNEJ0IOwJ
	1JSxZ2jKxGVj8/csXokH2zclLmVFy5Wb3DDLzvr0PT8v7mzzOu1zNpmGlHXndlh/pd+5FFdUb5p4M
	gRjYShrWSxVcmxbUGf1Cycp6tZzv0LoSMZf/jH11K8//jLXp+L5e7Qb+ekdY+3sorTQI=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 185144: tolerable FAIL - PUSHED
X-Osstest-Failures:
    linux-linus:test-armhf-armhf-xl-credit2:host-ping-check-xen:fail:heisenbug
    linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-qcow2:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-qcow2:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-raw:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-vhd:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    linux=bfa8f18691ed2e978e4dd51190569c434f93e268
X-Osstest-Versions-That:
    linux=23956900041d968f9ad0f30db6dede4daccd7aa9
From: osstest service owner 
Date: Sat, 23 Mar 2024 16:32:33 +0000

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

Failures :-/ but no regressions.

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

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-credit2 15 migrate-support-check fail in 185145 never pass
 test-armhf-armhf-xl-credit2 16 saverestore-support-check fail in 185145 never pass
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop            fail like 185119
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop            fail like 185119
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop            fail like 185119
 test-armhf-armhf-libvirt     16 saverestore-support-check    fail  like 185119
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop            fail like 185119
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 185119
 test-arm64-arm64-xl-thunderx 15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      16 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-multivcpu 15 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit1  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          16 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qcow2 14 migrate-support-check        fail never pass
 test-amd64-amd64-libvirt-raw 14 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-raw 14 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-raw 15 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt     15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-vhd      14 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-vhd      15 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-qcow2    14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-qcow2    15 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass
 test-armhf-armhf-xl-raw      14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-raw      15 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     16 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     15 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-vhd 14 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-vhd 15 saverestore-support-check    fail   never pass

version targeted for testing:
 linux                bfa8f18691ed2e978e4dd51190569c434f93e268
baseline version:
 linux                23956900041d968f9ad0f30db6dede4daccd7aa9

Last test of basis   185119  2024-03-21 07:40:49 Z    2 days
Failing since        185136  2024-03-21 21:13:02 Z    1 days    4 attempts
Testing same since   185144  2024-03-23 05:27:10 Z    0 days    1 attempts

------------------------------------------------------------
502 people touched revisions under test,
not listing them all

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  fail    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-libvirt-qcow2                               pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-xl-qcow2                                    pass    
 test-amd64-amd64-libvirt-raw                                 pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-amd64-amd64-xl-raw                                      pass    
 test-armhf-armhf-xl-raw                                      pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-libvirt-vhd                                 pass    
 test-amd64-amd64-xl-vhd                                      pass    
 test-arm64-arm64-xl-vhd                                      pass    


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

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

Explanation of these 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 :

hint: The 'hooks/update' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
hint: The 'hooks/post-receive' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
hint: The 'hooks/post-update' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
To xenbits.xen.org:/home/xen/git/linux-pvops.git
   23956900041d..bfa8f18691ed  bfa8f18691ed2e978e4dd51190569c434f93e268 -> tested/linux-linus


From xen-devel-bounces@lists.xenproject.org Sun Mar 24 00:45:51 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 24 Mar 2024 00:45:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697367.1088406 (Exim 4.92)
	(envelope-from )
	id 1roBzT-0002r2-Sp; Sun, 24 Mar 2024 00:45:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697367.1088406; Sun, 24 Mar 2024 00:45:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1roBzT-0002qv-PZ; Sun, 24 Mar 2024 00:45:35 +0000
Received: by outflank-mailman (input) for mailman id 697367;
 Sun, 24 Mar 2024 00:45:33 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1roBzR-0002ql-U4; Sun, 24 Mar 2024 00:45:33 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1roBzR-0001pP-MU; Sun, 24 Mar 2024 00:45:33 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1roBzR-0002HE-DM; Sun, 24 Mar 2024 00:45:33 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1roBzR-0003Sn-Cn; Sun, 24 Mar 2024 00:45:33 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=hhYPfi77vrjOKaicFhOOv+JOkVK4fjOfx9RZTZLfuOc=; b=08qvnsvmUMKJDMPPaELOewMlBg
	hd4wjZ6h8j4tovmS6BAVry3Z5gSCjA+aeZW0ANngplEXe+0DL42o9gVdjcZAvey1Tsd8axXtAlz+L
	FUTC1r77xrW2TPJUrbAHEicv/zWDo+1nkOIFquMUQ3psolZOySNWAfjJdz9KeThTltFU=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 185147: tolerable FAIL - PUSHED
X-Osstest-Failures:
    linux-linus:test-amd64-amd64-qemuu-freebsd11-amd64:guest-saverestore.2:fail:heisenbug
    linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-qcow2:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-qcow2:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-raw:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-vhd:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    linux=484193fecd2b6349a6fd1554d306aec646ae1a6a
X-Osstest-Versions-That:
    linux=bfa8f18691ed2e978e4dd51190569c434f93e268
From: osstest service owner 
Date: Sun, 24 Mar 2024 00:45:33 +0000

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-qemuu-freebsd11-amd64 18 guest-saverestore.2 fail pass in 185148-retest

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

version targeted for testing:
 linux                484193fecd2b6349a6fd1554d306aec646ae1a6a
baseline version:
 linux                bfa8f18691ed2e978e4dd51190569c434f93e268

Last test of basis   185144  2024-03-23 05:27:10 Z    0 days
Testing same since   185147  2024-03-23 16:40:43 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Ard Biesheuvel 
  Arnd Bergmann 
  Baoquan He 
  Christophe Leroy 
  Geert Uytterhoeven 
  Guenter Roeck 
  Hari Bathini 
  Kees Cook 
  Linus Torvalds 
  Linus Walleij 
  Liu Song 
  Mark Brown 
  Masahiro Yamada 
  Michael Ellerman 
  Nathan Chancellor 
  Nicolas Pitre 
  Randy Dunlap 
  Russell King (Oracle) 
  Yongqiang Liu 

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       fail    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-libvirt-qcow2                               pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-xl-qcow2                                    pass    
 test-amd64-amd64-libvirt-raw                                 pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-amd64-amd64-xl-raw                                      pass    
 test-armhf-armhf-xl-raw                                      pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-libvirt-vhd                                 pass    
 test-amd64-amd64-xl-vhd                                      pass    
 test-arm64-arm64-xl-vhd                                      pass    


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

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

Explanation of these 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 :

hint: The 'hooks/update' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
hint: The 'hooks/post-receive' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
hint: The 'hooks/post-update' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
To xenbits.xen.org:/home/xen/git/linux-pvops.git
   bfa8f18691ed..484193fecd2b  484193fecd2b6349a6fd1554d306aec646ae1a6a -> tested/linux-linus


From xen-devel-bounces@lists.xenproject.org Sun Mar 24 09:32:16 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 24 Mar 2024 09:32:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697432.1088416 (Exim 4.92)
	(envelope-from )
	id 1roKCw-0006hp-IU; Sun, 24 Mar 2024 09:32:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697432.1088416; Sun, 24 Mar 2024 09:32:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1roKCw-0006hi-EI; Sun, 24 Mar 2024 09:32:02 +0000
Received: by outflank-mailman (input) for mailman id 697432;
 Sun, 24 Mar 2024 09:32:01 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1roKCv-0006hY-B9; Sun, 24 Mar 2024 09:32:01 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1roKCu-00034a-Np; Sun, 24 Mar 2024 09:32:00 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1roKCu-000712-CC; Sun, 24 Mar 2024 09:32:00 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1roKCu-0004Qi-BD; Sun, 24 Mar 2024 09:32:00 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=LmgPpH/jHNpUKLmRti43lv1F3gcrsH2qv0wwhsrnVKo=; b=GpDawBSXJ0iUrQqp/lZizkN977
	NoliUM/7qIUKoXtzcv7RBdwkKlTR/IxEiCE3IdSuGu4muZYpCxxdxW8twH74j5iBBJEISkhZdwvNs
	Jye8UxdRFZ7e8Nqe08/9o34zVUHrSoWqmfqomaPccFjfVi0Ohhg3xpPU5mw16I6At9oo=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 185149: tolerable FAIL - PUSHED
X-Osstest-Failures:
    linux-linus:test-amd64-amd64-xl-shadow:guest-start/debian.repeat:fail:heisenbug
    linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-qcow2:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-qcow2:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-raw:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-vhd:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    linux=70293240c5ce675a67bfc48f419b093023b862b3
X-Osstest-Versions-That:
    linux=484193fecd2b6349a6fd1554d306aec646ae1a6a
From: osstest service owner 
Date: Sun, 24 Mar 2024 09:32:00 +0000

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

Failures :-/ but no regressions.

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

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

version targeted for testing:
 linux                70293240c5ce675a67bfc48f419b093023b862b3
baseline version:
 linux                484193fecd2b6349a6fd1554d306aec646ae1a6a

Last test of basis   185147  2024-03-23 16:40:43 Z    0 days
Testing same since   185149  2024-03-24 01:11:52 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  André Rösti 
  Biju Das 
  Conor Dooley 
  Daniel Lezcano 
  Frederic Weisbecker 
  Geert Uytterhoeven 
  Krzysztof Kozlowski 
  Lad Prabhakar 
  Ley Foon Tan 
  Linus Torvalds 
  Martin Blumenstingl 
  Mubin Sayyed 
  Peng Fan 
  Peter Griffin 
  Randy Dunlap 
  Samuel Holland 
  Sergio Paracuellos 
  Thomas Gleixner 

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-libvirt-qcow2                               pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-xl-qcow2                                    pass    
 test-amd64-amd64-libvirt-raw                                 pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-amd64-amd64-xl-raw                                      pass    
 test-armhf-armhf-xl-raw                                      pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-amd64-xl-shadow                                   fail    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-libvirt-vhd                                 pass    
 test-amd64-amd64-xl-vhd                                      pass    
 test-arm64-arm64-xl-vhd                                      pass    


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

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

Explanation of these 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 :

hint: The 'hooks/update' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
hint: The 'hooks/post-receive' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
hint: The 'hooks/post-update' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
To xenbits.xen.org:/home/xen/git/linux-pvops.git
   484193fecd2b..70293240c5ce  70293240c5ce675a67bfc48f419b093023b862b3 -> tested/linux-linus


From xen-devel-bounces@lists.xenproject.org Sun Mar 24 11:55:58 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 24 Mar 2024 11:55:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697454.1088426 (Exim 4.92)
	(envelope-from )
	id 1roMS0-0006hx-5F; Sun, 24 Mar 2024 11:55:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697454.1088426; Sun, 24 Mar 2024 11:55:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1roMS0-0006hq-1Q; Sun, 24 Mar 2024 11:55:44 +0000
Received: by outflank-mailman (input) for mailman id 697454;
 Sun, 24 Mar 2024 11:55:43 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1roMRz-0006he-3T; Sun, 24 Mar 2024 11:55:43 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1roMRy-0005da-O5; Sun, 24 Mar 2024 11:55:42 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1roMRy-00020g-Ba; Sun, 24 Mar 2024 11:55:42 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1roMRy-0005xr-BG; Sun, 24 Mar 2024 11:55:42 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=+/4NagJx7r7fvnnFoGylyNb+A0WebX6ZyzDURCwqT8U=; b=s2lwyPe3I26BNUzyDuajh98s8I
	VCI8akrK5QEsRGyiPvFSaiJakdIJSsvOJpk6uWYRcGvXJoqmkw1nvaLpLu7im7o70Go5HlwYZsjIW
	fPDd9l4iVIhx2Y8zwvxk3vSfCHH49fi+BW2dPv0D5FGuQ9IMIOTThZCk2WgaZ6UgC2uI=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 185150: tolerable FAIL
X-Osstest-Failures:
    xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:windows-install:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-qcow2:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-qcow2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-vhd:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-raw:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    xen=cbe393b709e0c6c3e2b10c3ac69fbea0abd530fe
X-Osstest-Versions-That:
    xen=cbe393b709e0c6c3e2b10c3ac69fbea0abd530fe
From: osstest service owner 
Date: Sun, 24 Mar 2024 11:55:42 +0000

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-win7-amd64 12 windows-install       fail like 185140
 test-armhf-armhf-libvirt     16 saverestore-support-check    fail  like 185143
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop            fail like 185143
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop            fail like 185143
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop            fail like 185143
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 185143
 test-amd64-amd64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      16 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass
 test-armhf-armhf-xl-rtds     15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 15 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-check    fail  never pass
 test-amd64-amd64-libvirt-raw 14 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt     15 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-raw 14 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-raw 15 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-vhd      14 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-vhd      15 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qcow2 14 migrate-support-check        fail never pass
 test-armhf-armhf-xl-qcow2    14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-qcow2    15 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-vhd 14 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-vhd 15 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-raw      14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-raw      15 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  16 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  cbe393b709e0c6c3e2b10c3ac69fbea0abd530fe
baseline version:
 xen                  cbe393b709e0c6c3e2b10c3ac69fbea0abd530fe

Last test of basis   185150  2024-03-24 01:53:22 Z    0 days
Testing same since                          (not found)         0 attempts

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-libvirt-qcow2                               pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-xl-qcow2                                    pass    
 test-amd64-amd64-libvirt-raw                                 pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-amd64-amd64-xl-raw                                      pass    
 test-armhf-armhf-xl-raw                                      pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-libvirt-vhd                                 pass    
 test-amd64-amd64-xl-vhd                                      pass    
 test-arm64-arm64-xl-vhd                                      pass    


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

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

Explanation of these 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


Published tested tree is already up to date.



From xen-devel-bounces@lists.xenproject.org Mon Mar 25 03:21:36 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 03:21:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697572.1088436 (Exim 4.92)
	(envelope-from )
	id 1roatf-0005ns-N1; Mon, 25 Mar 2024 03:21:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697572.1088436; Mon, 25 Mar 2024 03:21:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1roatf-0005ng-Hq; Mon, 25 Mar 2024 03:21:15 +0000
Received: by outflank-mailman (input) for mailman id 697572;
 Mon, 25 Mar 2024 03:21:14 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1roate-0005nW-RB; Mon, 25 Mar 2024 03:21:14 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1roate-00077Y-Ct; Mon, 25 Mar 2024 03:21:14 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1roatd-0001Fe-Uw; Mon, 25 Mar 2024 03:21:14 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1roatd-0003Mr-UB; Mon, 25 Mar 2024 03:21:13 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=s9wP0LzlQdsClDPtVMmQm8vRyhLig40TzFZ4wm3zFyE=; b=aB1wW53TTKVAAw4uwPsjAiL1Ac
	Wk6H/R6JoTBgGxQheGDBw7olH8CgzswSfc8lb9sFcNzKo5OBuQ3YWoipiMAGa8tfv41L1IyVHGnLs
	pqIcYonBiHYISjTbUBDulEx8BurbYajiNBAxCJ5/maaAh+TGXxPAQUx0EqzjH5SAKOE8=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 185152: tolerable FAIL - PUSHED
X-Osstest-Failures:
    linux-linus:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:heisenbug
    linux-linus:test-armhf-armhf-libvirt-vhd:xen-boot:fail:heisenbug
    linux-linus:test-armhf-armhf-libvirt-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-vhd:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-qcow2:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-qcow2:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-raw:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
X-Osstest-Versions-This:
    linux=5e74df2f8f15eaa1ebbdfc1f6fef27a26d789de8
X-Osstest-Versions-That:
    linux=70293240c5ce675a67bfc48f419b093023b862b3
From: osstest service owner 
Date: Mon, 25 Mar 2024 03:21:13 +0000

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 12 debian-hvm-install fail pass in 185153-retest
 test-armhf-armhf-libvirt-vhd  8 xen-boot            fail pass in 185153-retest

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-vhd 14 migrate-support-check fail in 185153 never pass
 test-armhf-armhf-libvirt-vhd 15 saverestore-support-check fail in 185153 never pass
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop            fail like 185149
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop            fail like 185149
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop            fail like 185149
 test-armhf-armhf-libvirt     16 saverestore-support-check    fail  like 185149
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop            fail like 185149
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 185149
 test-arm64-arm64-xl-thunderx 15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 15 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-check    fail  never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          16 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qcow2 14 migrate-support-check        fail never pass
 test-amd64-amd64-libvirt-raw 14 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-raw 14 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-raw 15 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-vhd      14 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-vhd      15 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-qcow2    14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-qcow2    15 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass
 test-armhf-armhf-xl-raw      14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-raw      15 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     16 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     15 migrate-support-check        fail   never pass

version targeted for testing:
 linux                5e74df2f8f15eaa1ebbdfc1f6fef27a26d789de8
baseline version:
 linux                70293240c5ce675a67bfc48f419b093023b862b3

Last test of basis   185149  2024-03-24 01:11:52 Z    1 days
Testing same since   185152  2024-03-24 18:41:47 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  "Rafael J. Wysocki" 
  Adamos Ttofari 
  Anton Altaparmakov 
  Borislav Petkov (AMD) 
  Chang S. Bae 
  Christoph Hellwig 
  Dave Young 
  Guenter Roeck 
  Ingo Molnar 
  Jinghao Jia 
  Linus Torvalds 
  Masahiro Yamada 
  Masami Hiramatsu (Google) 
  Michael Kelley 
  Mukesh Kumar Chaurasiya 
  Nicolin Chen 
  Robin Murphy 
  Thomas Gleixner 
  Tom Lendacky 
  Tony Luck 
  Will Deacon 

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 fail    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-libvirt-qcow2                               pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-xl-qcow2                                    pass    
 test-amd64-amd64-libvirt-raw                                 pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-amd64-amd64-xl-raw                                      pass    
 test-armhf-armhf-xl-raw                                      pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-libvirt-vhd                                 fail    
 test-amd64-amd64-xl-vhd                                      pass    
 test-arm64-arm64-xl-vhd                                      pass    


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

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

Explanation of these 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 :

hint: The 'hooks/update' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
hint: The 'hooks/post-receive' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
hint: The 'hooks/post-update' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
To xenbits.xen.org:/home/xen/git/linux-pvops.git
   70293240c5ce..5e74df2f8f15  5e74df2f8f15eaa1ebbdfc1f6fef27a26d789de8 -> tested/linux-linus


From xen-devel-bounces@lists.xenproject.org Mon Mar 25 07:19:55 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 07:19:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697581.1088446 (Exim 4.92)
	(envelope-from )
	id 1roecN-0007r7-LZ; Mon, 25 Mar 2024 07:19:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697581.1088446; Mon, 25 Mar 2024 07:19:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1roecN-0007r0-IY; Mon, 25 Mar 2024 07:19:39 +0000
Received: by outflank-mailman (input) for mailman id 697581;
 Mon, 25 Mar 2024 07:19:38 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1roecM-0007qu-Jr
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 07:19:38 +0000
Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com
 [2a00:1450:4864:20::636])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 07de3e36-ea78-11ee-a1ef-f123f15fe8a2;
 Mon, 25 Mar 2024 08:19:34 +0100 (CET)
Received: by mail-ej1-x636.google.com with SMTP id
 a640c23a62f3a-a466fc8fcccso522224466b.1
 for ; Mon, 25 Mar 2024 00:19:34 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 y4-20020a1709060a8400b00a46bec6da9fsm2719970ejf.203.2024.03.25.00.19.33
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 25 Mar 2024 00:19:33 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 07de3e36-ea78-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711351174; x=1711955974; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=mm1gw2ECZDbis5ZwKJcUwi50GULtM/d805mZIANAhvU=;
        b=OREVHkzUOzmSEPDO/5vwMcXqrd2IbpkWJfLUkYIDC+YvFgTsNybeOfqvMzF81FXHLF
         iDVwGYqMCEZ6wyqb8OXpmWu8ADVRZ0cVHiBIzTg63u//eZG6YkhqXbOqnm+HmknERzam
         ii56rH9wQsQGmyqb0ZVOVcieu/AH2vG9VVnsevTY9VeZPQAWJMwwC8MLiKoNZaKGB4vY
         +zb+pExx6DK+fEBMpcD0Xeh83zhcAEZ0bARDVJjZY4YwQJhTI1Gjsbja94d8hH/BUeVx
         4HuAJg3i09S2eU0sZ0Wq3+pnmnff2svIzuDm/FogB0nO7jqfo9wmJN9xNhmSvdBvoTKM
         GA8w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711351174; x=1711955974;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=mm1gw2ECZDbis5ZwKJcUwi50GULtM/d805mZIANAhvU=;
        b=d8MlL1nMKKKwgnI1aT1hY8+Vqw9ZTAyrGZn2V7VCMM0aFvPB9VhPxN9fx2B+rYs6Rt
         DTyDh107YXg/SCyS7vS3z9k64emDI1AhqJnHSh2kci694WnFuTVtWQ2MppuFluODgpM2
         SV8sQsJVzgxoE+9HdF033k3HOrmnY/+hANQdpisoYsa4iRKWShzeA+v40lEFgy3OHtWc
         M3nnP5Ygxx24m2qzQ+Vet1EbF3ZSxq43b0PX6SO4Vd3vHrKDxN7M9O6xoO/u2fx4Fc3Y
         NiWjd+/ANGIUHrDtM3SnyqCGsEdEKmpG/812QXffggkSHGeY8Z9CsUjKB0sQ3cPOUxCw
         p1vQ==
X-Forwarded-Encrypted: i=1; AJvYcCW8OMO3k7WmrecsNhsCzU3sDKxQmukiYu1j831Yavy8BhfCtA13uagxnFOoWPFWPFwfaHbSoiN/1+BcwnbHCs+dHxuDtMtGt5mvhuvmVN0=
X-Gm-Message-State: AOJu0YxPdcPkzzH7RgSnv52JNSrp/ASHZpDCsD8cdWVoOdT2VvonjcmT
	nvA/g6CF12IwEdrRsrPids7MFZ926KjTExXWUaZQnZ8k1d3UeDdCXAveZYRIxQ==
X-Google-Smtp-Source: AGHT+IHjZJsf1abORytkCGlcCovBSEc8rsfBM+s+GeMZ6yy8XsiVbvFNrzALo5G3s14X8Gs4KaADDA==
X-Received: by 2002:a17:906:408f:b0:a47:2036:dbc4 with SMTP id u15-20020a170906408f00b00a472036dbc4mr3591164ejj.25.1711351174158;
        Mon, 25 Mar 2024 00:19:34 -0700 (PDT)
Message-ID: <3427132d-9458-4447-b667-d2ef3c1f0569@suse.com>
Date: Mon, 25 Mar 2024 08:19:35 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 08/14] xen/page_alloc: introduce preserved page flags
 macro
Content-Language: en-US
To: Carlo Nonato 
Cc: Julien Grall , Andrew Cooper ,
 George Dunlap ,
 Stefano Stabellini , Wei Liu ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
 <20240315105902.160047-9-carlo.nonato@minervasys.tech>
 <3f615066-a792-493f-ba33-7667a6557c23@xen.org>
 <9e0f7ff3-5457-41e4-a1e4-bf75804fb900@xen.org>
 <255be735-f9fe-4e39-a24e-2f6aff91acc5@suse.com>
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 22.03.2024 16:07, Carlo Nonato wrote:
> Hi guys,
> 
> On Thu, Mar 21, 2024 at 5:23 PM Jan Beulich  wrote:
>>
>> On 21.03.2024 17:10, Julien Grall wrote:
>>> On 21/03/2024 16:07, Julien Grall wrote:
>>>> On 15/03/2024 10:58, Carlo Nonato wrote:
>>>>> PGC_static and PGC_extra needs to be preserved when assigning a page.
>>>>> Define a new macro that groups those flags and use it instead of or'ing
>>>>> every time.
>>>>>
>>>>> To make preserved flags even more meaningful, they are kept also when
>>>>> switching state in mark_page_free().
>>>>>
>>>>> Signed-off-by: Carlo Nonato 
>>>>
>>>> This patch is introducing a regression in OSStest (and possibly gitlab?):
>>>>
>>>> Mar 21 12:00:29.533676 (XEN) pg[0] MFN 2211c5 c=0x2c00000000000000 o=0
>>>> v=0xe40000010007ffff t=0x24
>>>> Mar 21 12:00:42.829785 (XEN) Xen BUG at common/page_alloc.c:1033
>>>> Mar 21 12:00:42.829829 (XEN) ----[ Xen-4.19-unstable  x86_64  debug=y
>>>> Not tainted ]----
>>>> Mar 21 12:00:42.829857 (XEN) CPU:    12
>>>> Mar 21 12:00:42.841571 (XEN) RIP:    e008:[]
>>>> common/page_alloc.c#alloc_heap_pages+0x37f/0x6e2
>>>> Mar 21 12:00:42.841609 (XEN) RFLAGS: 0000000000010282   CONTEXT:
>>>> hypervisor (d0v8)
>>>> Mar 21 12:00:42.853654 (XEN) rax: ffff83023e3ed06c   rbx:
>>>> 000000000007ffff   rcx: 0000000000000028
>>>> Mar 21 12:00:42.853689 (XEN) rdx: ffff83047bec7fff   rsi:
>>>> ffff83023e3ea3e8   rdi: ffff83023e3ea3e0
>>>> Mar 21 12:00:42.865657 (XEN) rbp: ffff83047bec7c10   rsp:
>>>> ffff83047bec7b98   r8:  0000000000000000
>>>> Mar 21 12:00:42.877647 (XEN) r9:  0000000000000001   r10:
>>>> 000000000000000c   r11: 0000000000000010
>>>> Mar 21 12:00:42.877682 (XEN) r12: 0000000000000001   r13:
>>>> 0000000000000000   r14: ffff82e0044238a0
>>>> Mar 21 12:00:42.889652 (XEN) r15: 0000000000000000   cr0:
>>>> 0000000080050033   cr4: 0000000000372660
>>>> Mar 21 12:00:42.901651 (XEN) cr3: 000000046fe34000   cr2: 00007fb72757610b
>>>> Mar 21 12:00:42.901685 (XEN) fsb: 00007fb726def380   gsb:
>>>> ffff88801f200000   gss: 0000000000000000
>>>> Mar 21 12:00:42.913646 (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000
>>>> ss: e010   cs: e008
>>>> Mar 21 12:00:42.913680 (XEN) Xen code around 
>>>> (common/page_alloc.c#alloc_heap_pages+0x37f/0x6e2):
>>>> Mar 21 12:00:42.925645 (XEN)  d1 1c 00 e8 ad dd 02 00 <0f> 0b 48 85 c9
>>>> 79 36 0f 0b 41 89 cd 48 c7 47 f0
>>>> Mar 21 12:00:42.937649 (XEN) Xen stack trace from rsp=ffff83047bec7b98:
>>>> Mar 21 12:00:42.937683 (XEN)    0000000000000024 000000007bec7c20
>>>> 0000000000000001 ffff83046ccda000
>>>> Mar 21 12:00:42.949653 (XEN)    ffff82e000000021 0000000000000016
>>>> 0000000000000000 0000000000000000
>>>> Mar 21 12:00:42.949687 (XEN)    0000000000000000 0000000000000000
>>>> 0000000000000028 0000000000000021
>>>> Mar 21 12:00:42.961652 (XEN)    ffff83046ccda000 0000000000000000
>>>> 00007d2000000000 ffff83047bec7c48
>>>> Mar 21 12:00:42.961687 (XEN)    ffff82d0402302ff ffff83046ccda000
>>>> 0000000000000100 0000000000000000
>>>> Mar 21 12:00:42.973655 (XEN)    ffff82d0405f0080 00007d2000000000
>>>> ffff83047bec7c80 ffff82d0402f626c
>>>> Mar 21 12:00:42.985656 (XEN)    ffff83046ccda000 ffff83046ccda640
>>>> 0000000000000000 0000000000000000
>>>> Mar 21 12:00:42.985690 (XEN)    ffff83046ccda220 ffff83047bec7cb0
>>>> ffff82d0402f65a0 ffff83046ccda000
>>>> Mar 21 12:00:42.997662 (XEN)    0000000000000000 0000000000000000
>>>> 0000000000000000 ffff83047bec7cc0
>>>> Mar 21 12:00:43.009660 (XEN)    ffff82d040311f8a ffff83047bec7ce0
>>>> ffff82d0402bd543 ffff83046ccda000
>>>> Mar 21 12:00:43.009695 (XEN)    ffff83047bec7dc8 ffff83047bec7d08
>>>> ffff82d04032c524 ffff83046ccda000
>>>> Mar 21 12:00:43.021653 (XEN)    ffff83047bec7dc8 0000000000000002
>>>> ffff83047bec7d58 ffff82d040206750
>>>> Mar 21 12:00:43.033642 (XEN)    0000000000000000 ffff82d040233fe5
>>>> ffff83047bec7d48 0000000000000000
>>>> Mar 21 12:00:43.033678 (XEN)    0000000000000002 00007fb72767f010
>>>> ffff82d0405e9120 0000000000000001
>>>> Mar 21 12:00:43.045654 (XEN)    ffff83047bec7e70 ffff82d040240728
>>>> 0000000000000007 ffff83023e3b3000
>>>> Mar 21 12:00:43.045690 (XEN)    0000000000000246 ffff83023e2efa90
>>>> ffff83023e38e000 ffff83023e2efb40
>>>> Mar 21 12:00:43.057609 (XEN)    0000000000000007 ffff83023e3afb80
>>>> 0000000000000206 ffff83047bec7dc0
>>>> Mar 21 12:00:43.069662 (XEN)    0000001600000001 000000000000ffff
>>>> e75aaa8d0000000c ac0d6d864e487f62
>>>> Mar 21 12:00:43.069697 (XEN)    000000037fa48d76 0000000200000000
>>>> ffffffff000003ff 00000002ffffffff
>>>> Mar 21 12:00:43.081647 (XEN)    0000000000000000 00000000000001ff
>>>> 0000000000000000 0000000000000000
>>>> Mar 21 12:00:43.093646 (XEN) Xen call trace:
>>>> Mar 21 12:00:43.093677 (XEN)    [] R
>>>> common/page_alloc.c#alloc_heap_pages+0x37f/0x6e2
>>>> Mar 21 12:00:43.093705 (XEN)    [] F
>>>> alloc_domheap_pages+0x17d/0x1e4
>>>> Mar 21 12:00:43.105652 (XEN)    [] F
>>>> hap_set_allocation+0x73/0x23c
>>>> Mar 21 12:00:43.105685 (XEN)    [] F
>>>> hap_enable+0x138/0x33c
>>>> Mar 21 12:00:43.117646 (XEN)    [] F
>>>> paging_enable+0x2d/0x45
>>>> Mar 21 12:00:43.117679 (XEN)    [] F
>>>> hvm_domain_initialise+0x185/0x428
>>>> Mar 21 12:00:43.129652 (XEN)    [] F
>>>> arch_domain_create+0x3e7/0x4c1
>>>> Mar 21 12:00:43.129687 (XEN)    [] F
>>>> domain_create+0x4cc/0x7e2
>>>> Mar 21 12:00:43.141665 (XEN)    [] F
>>>> do_domctl+0x1850/0x192d
>>>> Mar 21 12:00:43.141699 (XEN)    [] F
>>>> pv_hypercall+0x617/0x6b5
>>>> Mar 21 12:00:43.153656 (XEN)    [] F
>>>> lstar_enter+0x13a/0x140
>>>> Mar 21 12:00:43.153689 (XEN)
>>>> Mar 21 12:00:43.153711 (XEN)
>>>> Mar 21 12:00:43.153731 (XEN) ****************************************
>>>> Mar 21 12:00:43.165647 (XEN) Panic on CPU 12:
>>>> Mar 21 12:00:43.165678 (XEN) Xen BUG at common/page_alloc.c:1033
>>>> Mar 21 12:00:43.165703 (XEN) ****************************************
>>>> Mar 21 12:00:43.177633 (XEN)
>>>> Mar 21 12:00:43.177662 (XEN) Manual reset required ('noreboot' specified)
>>>>
>>>> The code around the BUG is:
>>>>
>>>>          /* Reference count must continuously be zero for free pages. */
>>>>          if ( (pg[i].count_info & ~PGC_need_scrub) != PGC_state_free )
>>>>          {
>>>>              printk(XENLOG_ERR
>>>>                     "pg[%u] MFN %"PRI_mfn" c=%#lx o=%u v=%#lx t=%#x\n",
>>>>                     i, mfn_x(page_to_mfn(pg + i)),
>>>>                     pg[i].count_info, pg[i].v.free.order,
>>>>                     pg[i].u.free.val, pg[i].tlbflush_timestamp);
>>>>              BUG();
>>>>          }
>>>>
>>>> Now that you are preserving some flags, you also want to modify the
>>>> condition. I haven't checked the rest of the code, so there might be
>>>> some adjustments necessary.
>>>
>>> Actually maybe the condition should not be adjusted. I think it would be
>>> wrong if a free pages has the flag PGC_extra set. Any thoughts?
>>
>> I agree, yet I'm inclined to say PGC_extra should have been cleared
>> before trying to free the page.
> 
> So what to do now? Should I drop this commit?

No, we need to get to the root of the issue. Since osstest has hit it quite
easily as it seems, I'm somewhat surprised you didn't hit it in your testing.
In any event, as per my earlier reply, my present guess is that your change
has merely uncovered a previously latent issue elsewhere.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Mar 25 07:46:08 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 07:46:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697586.1088456 (Exim 4.92)
	(envelope-from )
	id 1rof1u-0003HE-Q5; Mon, 25 Mar 2024 07:46:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697586.1088456; Mon, 25 Mar 2024 07:46:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rof1u-0003H7-MU; Mon, 25 Mar 2024 07:46:02 +0000
Received: by outflank-mailman (input) for mailman id 697586;
 Mon, 25 Mar 2024 07:46:01 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rof1t-0003H1-D3
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 07:46:01 +0000
Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com
 [2a00:1450:4864:20::12c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b8fe43e5-ea7b-11ee-afe3-a90da7624cb6;
 Mon, 25 Mar 2024 08:46:00 +0100 (CET)
Received: by mail-lf1-x12c.google.com with SMTP id
 2adb3069b0e04-51381021af1so6146273e87.0
 for ; Mon, 25 Mar 2024 00:46:00 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 n19-20020a170906119300b00a4660b63502sm2787957eja.12.2024.03.25.00.45.58
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 25 Mar 2024 00:45:59 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b8fe43e5-ea7b-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711352759; x=1711957559; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=yb8CcBgcLohDb7X/nt8CRDOZcP5NhK4eWvJ8+1TfBPY=;
        b=UaPfIpjMB9oNCYAA4KpoRfNNj8YefWb3MHJWYcBwojXT7fr762bhJMfOc+J+rlVTcR
         YN6p9zFYs0aHp4vJ81YJIsLncC8/9ybQNEwyTYejF9GpV4CMyyrWr3X4m8I3TcNLFoZ6
         2A4np5mikQyOZW4r7LqVvXe1RvmEy62eloQCWg/gPV04rnIbVzkH4se1aq3cNAVgANPX
         C5uzhGD8umdiefmLcyu6fptcA5l9lV5qnJLeFn9qXDVwaeZspZJgXQ5MQOU4Gv9HDQRW
         618hz9GriQP6OukE7vCJPJr7RynfAairXqgsO5vEFsUJXMW06t8ZwlXelQklyj1uh5Zw
         ogdw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711352759; x=1711957559;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=yb8CcBgcLohDb7X/nt8CRDOZcP5NhK4eWvJ8+1TfBPY=;
        b=AcbPlo7pPE8bfsix8EG13QPDfFmJAyL2ne5w1Mkxaz/9s0+7Cz6feEN+UBMpQzTz8+
         4ANdnpZqlU8AEfkDCxRFcoBj3RMIzHLsNcpnya0lQLUTeD6htpK2IUT/wifVIR2jk3PS
         3GAZbN/uyMk4eqwUcuOl40gsvG9f+nefkhS36j33NwmO+Oamc2AE7G6AnwA9i1SrO0SY
         ihNUdcqQXQ+7mZEGOg9O5sR6+Q9bAw6/yJADlzNyMiDS07uE2wBW3JB/sRLCYK/SPSxT
         uBu7BEfJSMekYis561Pt9XRsKXUat7xy/KdoSgRIZkbk6J5akaKE+0i2Kgck5Vzx03d9
         2FOA==
X-Forwarded-Encrypted: i=1; AJvYcCXZ3xeewSbzO9RBJK0131B4Tfp8+btESSnOPcXThi7b299snndcQ83i/6gRZL3sGZV6ranx3TbLQkJb9WHGN/MY+17AeGEvuZtzWnG1+gc=
X-Gm-Message-State: AOJu0Yy5wwpFaYPunEH2tJkE/c3xgjDxo5oXITWp4oUg8Ld63jwPJ5Bm
	9eLhN1NLzpY4JvP4hYU5vUL2fUsBozE6MN/qc/7o1fQx3f4ey6YHN8Tnvm6CKw==
X-Google-Smtp-Source: AGHT+IEltR00OIpIpmIOnz13CIUGNx3hzKHB7smB3WtwDwQpfqeODvSp1271FCXvqFSDH9KNXBuDNg==
X-Received: by 2002:ac2:446b:0:b0:515:8dd3:e94d with SMTP id y11-20020ac2446b000000b005158dd3e94dmr3949052lfl.68.1711352759472;
        Mon, 25 Mar 2024 00:45:59 -0700 (PDT)
Message-ID: 
Date: Mon, 25 Mar 2024 08:46:01 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 3/3] x86/PVH: Support relocatable dom0 kernels
Content-Language: en-US
To: Jason Andryuk 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu
 , George Dunlap ,
 Julien Grall , Stefano Stabellini ,
 xen-devel@lists.xenproject.org
References: <20240319205849.115884-1-jason.andryuk@amd.com>
 <20240319205849.115884-4-jason.andryuk@amd.com>
 
 <183f17a2-cc7b-46c6-81b5-ac1f5daacb7b@amd.com>
 <63cad597-b48f-43df-8d53-0ee8c1aa744d@amd.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <63cad597-b48f-43df-8d53-0ee8c1aa744d@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 22.03.2024 15:24, Jason Andryuk wrote:
> On 2024-03-21 09:45, Jason Andryuk wrote:
>> On 2024-03-20 10:39, Jan Beulich wrote:
>>> On 19.03.2024 21:58, Jason Andryuk wrote:
> 
>>>> @@ -536,6 +565,10 @@ elf_errorstatus elf_xen_parse(struct elf_binary 
>>>> *elf,
>>>>       parms->p2m_base = UNSET_ADDR;
>>>>       parms->elf_paddr_offset = UNSET_ADDR;
>>>>       parms->phys_entry = UNSET_ADDR32;
>>>> +    parms->phys_min = 0;
>>>> +    parms->phys_max = 0xffffffff;
>>>> +    parms->phys_align = 0x200000;
>>>
>>> I think this wants to be MB(2) (requiring a pre-patch to centralize MB()
>>> in the tool stack to tools/include/xen-tools/common-macros.h). And I
>>> further think this needs to be an arch-specific constant, even if right
>>> now the note is expected to be present only for x86. Which then also
>>> needs saying ...
> 
> Are you thinking something like the following in libelf-dominfo.c:
> 
> #define X86_PHYS_ALIGN_DEFAULT MB(2)
> #define X86_PHYS_MAX_DEFAULT (GB(4) - 1)
> 
> and setting as:
> parms->phys_max = X86_PHYS_MAX_DEFAULT;
> parms->phys_align = X86_PHYS_ALIGN_DEFAULT;
> 
> libelf is arch neutral, so there isn't a natural place to introduce 
> arch-specific defines.  Or were you looking for each arch to set it?  We 
> only care about x86 right now, so we can do something like:
> 
> #if x86
> #define ARCH_PHYS_MAX_DEFAULT   (GB(4) - 1)
> #define ARCH_PHYS_ALIGN_DEFAULT MB(2)
> #else
> #define ARCH_PHYS_MAX_DEFAULT   0
> #define ARCH_PHYS_ALIGN_DEFAULT 0
> #endif

More like the latter. The former only if the phys_* fields themselves were
to also become x86-only.

As you say, libelf in its present shape doesn't easily lend itself to such
arch-specifics.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Mar 25 07:56:05 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 07:56:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697590.1088466 (Exim 4.92)
	(envelope-from )
	id 1rofBX-000517-Lg; Mon, 25 Mar 2024 07:55:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697590.1088466; Mon, 25 Mar 2024 07:55:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rofBX-000510-Hp; Mon, 25 Mar 2024 07:55:59 +0000
Received: by outflank-mailman (input) for mailman id 697590;
 Mon, 25 Mar 2024 07:55:58 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rofBW-00050u-4m
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 07:55:58 +0000
Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com
 [2a00:1450:4864:20::636])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1c06950e-ea7d-11ee-a1ef-f123f15fe8a2;
 Mon, 25 Mar 2024 08:55:55 +0100 (CET)
Received: by mail-ej1-x636.google.com with SMTP id
 a640c23a62f3a-a2f22bfb4e6so524286566b.0
 for ; Mon, 25 Mar 2024 00:55:55 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 l13-20020a1709061c4d00b00a473780b012sm2747544ejg.156.2024.03.25.00.55.54
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 25 Mar 2024 00:55:55 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1c06950e-ea7d-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711353355; x=1711958155; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=lZvfPwCaeoSaUbow16/njPd6dB4EK4YynekTWLX4jqs=;
        b=A90efINCpCmT5DcRGqKL10rtXMoDBGFOJ2LvL2eX8Ca9APIYgC1VNUJcLTmadZ0/PM
         xSuOpfwujRYItgqlTORAkEZv35F/GnyZQYAeu2R0S90dGurweS0JRuldmV/kj1y6Goxg
         wynTXA2BoNq0h3WtE26hvJvat84ABbeTh87CBOZOMkSbLtcJ6Ql7UYn760bzlsjmgUvg
         YKBdASNFYWEgKsLZAArv3KwjzPpdQ7vxtMKg3/4WBjVu+vGpA+G1KercF5LayxdKbS3Z
         u+ukqCw+4FAt993qMz5MSBpXSTiUQIl201/N4+p1vpxiF5GylUkEqDg2fTqTvYQ7K1Hy
         +xcw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711353355; x=1711958155;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=lZvfPwCaeoSaUbow16/njPd6dB4EK4YynekTWLX4jqs=;
        b=EMA/4ZLeTfErV6pMW/6+HMaa7INK3biPFkU9KeyxY9VZnB/oZKAG9h+t515SGDNQz3
         wz4z97h0eGYp8Gv2mAFSXPKVsYWAAN0LVxYIj1uHpDrGYHwzXI39p5mHBkJIeBusnCO/
         FwfRNlGndZP1cW1W8MBFwxQwMPfp35Q0NIft7BHw8D1utjnIzJhxEUy8cExAYOqxuQHs
         cMfqF9Hgea/yYZ3R8n40X3f5g1bl7P7UFvqc8pEXwITIp/IS/lOvI/jqfqhnwYQ3Gctk
         NEQb8SsEskF2bjbor/FdIad16fI/YAyChj0g2RhpftC4QaTGrPKXGJQ0R9zN9cQmAhO8
         wk2Q==
X-Gm-Message-State: AOJu0YxmugjTsu0AU/5S03FEhs3A1zaBgefi/3Zx/nQpeRF0/K6U/P3p
	/zbHfZwHGdMcHmm0+kRJ1vBNI3ud0v7QWvGmfDn2GxB8xNGp64StrP+1g+ZJXQ==
X-Google-Smtp-Source: AGHT+IFEa7hx+xCjIU6B5shUkk9swU937qkHsPDzRvGy/rCbNFgQ38Fg6xmkXbIapZRoNKl75xBALg==
X-Received: by 2002:a17:906:f9d8:b0:a47:499b:d735 with SMTP id lj24-20020a170906f9d800b00a47499bd735mr3197856ejb.14.1711353355246;
        Mon, 25 Mar 2024 00:55:55 -0700 (PDT)
Message-ID: 
Date: Mon, 25 Mar 2024 08:55:56 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Serious AMD-Vi(?) issue
Content-Language: en-US
To: Elliott Mitchell 
Cc: xen-devel@lists.xenproject.org, Andrew Cooper
 , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Wei Liu ,
 Kelly Choi 
References: 
  
 
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 22.03.2024 20:22, Elliott Mitchell wrote:
> On Fri, Mar 22, 2024 at 04:41:45PM +0000, Kelly Choi wrote:
>>
>> I can see you've recently engaged with our community with some issues you'd
>> like help with.
>> We love the fact you are participating in our project, however, our
>> developers aren't able to help if you do not provide the specific details.
> 
> Please point to specific details which have been omitted.  Fairly little
> data has been provided as fairly little data is available.  The primary
> observation is large numbers of:
> 
> (XEN) AMD-Vi: IO_PAGE_FAULT: DDDD:bb:dd.f d0 addr ffffff???????000 flags 0x8 I
> 
> Lines in Xen's ring buffer.

Yet this is (part of) the problem: By providing only the messages that appear
relevant to you, you imply that you know that no other message is in any way
relevant. That's judgement you'd better leave to people actually trying to
investigate. Unless of course you were proposing an actual code change, with
suitable justification.

In fact when running into trouble, the usual course of action would be to
increase verbosity in both hypervisor and kernel, just to make sure no
potentially relevant message is missed.

>  I recall spotting 3 messages from Linux's
> SATA driver (which weren't saved due to other causes being suspected),
> which would likely be associated with hundreds or thousands of the above
> log messages.  I never observed any messages from the NVMe subsystem
> during that phase.
> 
> The most overt sign was telling the Linux kernel to scan for
> inconsistencies and the kernel finding some.  The domain didn't otherwise
> appear to notice trouble.
> 
> This is from memory, it would take some time to discover whether any
> messages were missed.  Present mitigation action is inhibiting the
> messages, but the trouble is certainly still lurking.

Iirc you were considering whether any of this might be a timing issue. Yet
beyond voicing that suspicion, you didn't provide any technical details as
to why you think so. Such technical details would include taking into
account how IOMMU mappings and associated IOMMU TLB flushing are carried
out. Right now, to me at least, your speculation in this regard fails
basic sanity checking. Therefore the scenario that you're thinking of
would need better describing, imo.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Mar 25 08:00:43 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 08:00:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697598.1088476 (Exim 4.92)
	(envelope-from )
	id 1rofG4-0007EB-HL; Mon, 25 Mar 2024 08:00:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697598.1088476; Mon, 25 Mar 2024 08:00:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rofG4-0007E4-El; Mon, 25 Mar 2024 08:00:40 +0000
Received: by outflank-mailman (input) for mailman id 697598;
 Mon, 25 Mar 2024 08:00:39 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rofG3-0007Dy-HA
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 08:00:39 +0000
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com
 [2a00:1450:4864:20::52c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c47c5de0-ea7d-11ee-afe3-a90da7624cb6;
 Mon, 25 Mar 2024 09:00:38 +0100 (CET)
Received: by mail-ed1-x52c.google.com with SMTP id
 4fb4d7f45d1cf-56be32b9775so3274897a12.1
 for ; Mon, 25 Mar 2024 01:00:38 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 m10-20020a50cc0a000000b0056b0af78d80sm2693558edi.34.2024.03.25.01.00.37
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 25 Mar 2024 01:00:37 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c47c5de0-ea7d-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711353638; x=1711958438; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=T3xtqaI6E5IJGgpu63j4LIE+WzlbHTlvZqtf48fDVaY=;
        b=CIx36ZFNIbDr0fGn6JAMiLhxnculB81+XxI646QfK6LBVCr9FU2QKrei/ftQ8pGDnL
         Y6wzB7reyrXRSI7o2yLD8UFtHWbxhC7i6mn4XpNTS04O9qcg4RG6AKcjcivz1tIRPxyX
         hl4Lz+Q1zMAbncFIA261afhCRXsdgOUNVRYBU6Y1xPwjLQptje8WR4DQy4GKwx5TUiVZ
         Ct+QwljvsLllwEkNfFIpnlXIqFE0MwtbtH+Kuh/mMAFHbXvvk4r4stxbafW6u/TIOPFW
         OkbVUpsraNldnfoaTHVaOLle6pnsS9ymlgDvupbcZSu9BBMTHix6HmxlTyHzHxzpfBpf
         jmTw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711353638; x=1711958438;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=T3xtqaI6E5IJGgpu63j4LIE+WzlbHTlvZqtf48fDVaY=;
        b=Grt6M2oLMJmY36TRMlcxDD848rnvQiYq35RIoq1Isgdle/mDuSXSlxP3sqkHsSRfBx
         NUqN23dnv+U2VH+kRk+Y7uZEeAOKnIrLFyLWjC5zE61p6ramvaEeeE2dut4sGlp2RJRE
         A2rWNqGIpLqI3Bo9+MOFD6qbYr8QY6Ot7i+T20GeU1ZiahHvtNr2X2A8JsYTcfhtjGB1
         4csW+/RqmBd+n7sM+aUTNob6vkradSYs+ZrhstIY2YOSOK8eURr0QV+e6nH7K66N2AWU
         RydfaadExKFRy5ZWRn1Jd9+Aa1jidc5RhKCODJt512er6avpJg+GV3HPj/9jMuWTrfG4
         6Vqw==
X-Forwarded-Encrypted: i=1; AJvYcCUM/HtSgVHe89W7qcJg+NS+UuZ32+6xjx12x5CkBnH7xs5ZQS/3+9EeNn9ECoQ4GyOihT00oGz37zwRw3k/mkpjW+kLe3phdBgV/ZcT1yk=
X-Gm-Message-State: AOJu0Yz0EDZKNH82OrZJqy8Ws7C/4FROjO2y/f24FW5kZ4dg/DwMbgHC
	50QhyqJyci64A4FLpSL0mkhDsjb1aST6e64bV7wCZ0REFI0IMCSc62CWQmWErA==
X-Google-Smtp-Source: AGHT+IEQbRbOqCds/lpBopflOuZv0IISC88KF2F+p2wSu0sJEKG3gHaoJeYRUpgJgIz+ZCrKpIrPhw==
X-Received: by 2002:a50:9fa5:0:b0:568:1444:a828 with SMTP id c34-20020a509fa5000000b005681444a828mr3726915edf.37.1711353637983;
        Mon, 25 Mar 2024 01:00:37 -0700 (PDT)
Message-ID: <9a9464de-f288-4f98-a194-22def7f2c4be@suse.com>
Date: Mon, 25 Mar 2024 09:00:39 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 00/11] address some violations of MISRA C Rule 20.7
Content-Language: en-US
To: Nicola Vetrini 
Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com,
 ayan.kumar.halder@amd.com, consulting@bugseng.com,
 andrew.cooper3@citrix.com, roger.pau@citrix.com, bertrand.marquis@arm.com,
 julien@xen.org, George Dunlap ,
 "Daniel P. Smith" ,
 Volodymyr Babchuk ,
 xen-devel@lists.xenproject.org
References: 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 22.03.2024 17:01, Nicola Vetrini wrote:
> Hi all,
> 
> this series aims to refactor some macros that cause violations of MISRA C Rule
> 20.7 ("Expressions resulting from the expansion of macro parameters shall be
> enclosed in parentheses"). All the macros touched by these patches are in some
> way involved in violations, and the strategy adopted to bring them into
> compliance is to add parentheses around macro arguments where needed.
> 
> Given that the community has previously requested a deviation from the rule, as
> stated in docs/misra/deviations.rst, and reported below for convenience [1],
> some macro parameters do not need any adjusting (e.g., when used as lhs to
> an assignment in statement expressions).
> 
> Patch 1 is taken, with adjustments, from [2]. Patches 2 and 3 are taken from [3]
> without any modifications. All other patches are new in this series and are
> pairwise indipendent.
> 
> [1] - Code violating Rule 20.7 is safe when macro parameters are used:
>        (1) as function arguments;
>        (2) as macro arguments;
>        (3) as array indices;
>        (4) as lhs in assignments.
> 
> [2] https://lore.kernel.org/xen-devel/b93a64b93ef4210f5fe96368c2522e5e71e9c87c.1709896401.git.nicola.vetrini@bugseng.com/
> [3] https://lore.kernel.org/xen-devel/cover.1710762555.git.nicola.vetrini@bugseng.com/
> 
> Nicola Vetrini (11):
>   xen/list: address violations of MISRA C Rule 20.7
>   xen/xsm: add parentheses to comply with MISRA C Rule 20.7
>   xen/efi: efibind: address violations of MISRA C Rule 20.7
>   xentrace: address violation of MISRA C Rule 20.7
>   xen: address MISRA C Rule 20.7 violation in generated hypercall
>   xen/efi: address violations of MISRA C Rule 20.7
>   xen/page_alloc: address violations of MISRA C Rule 20.7
>   x86/altcall: address violations of MISRA C Rule 20.7
>   x86/msi: address violation of MISRA C Rule 20.7 and coding style
>   x86/hvm: address violations of Rule 20.7
>   x86/public: hvm: address violations of MISRA C Rule 20.7

Just to clarify: While most of the patches here are new, two(?) I think
were submitted before. As such, to indicate that, the series as a whole
would want to be tagged v2.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Mar 25 08:08:02 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 08:08:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697601.1088485 (Exim 4.92)
	(envelope-from )
	id 1rofN7-0007y8-72; Mon, 25 Mar 2024 08:07:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697601.1088485; Mon, 25 Mar 2024 08:07:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rofN7-0007y1-4b; Mon, 25 Mar 2024 08:07:57 +0000
Received: by outflank-mailman (input) for mailman id 697601;
 Mon, 25 Mar 2024 08:07:56 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rofN6-0007xv-2x
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 08:07:56 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c7b451bb-ea7e-11ee-a1ef-f123f15fe8a2;
 Mon, 25 Mar 2024 09:07:53 +0100 (CET)
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 by support.bugseng.com (Postfix) with ESMTPA id 2808D4EE073E;
 Mon, 25 Mar 2024 09:07:53 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c7b451bb-ea7e-11ee-a1ef-f123f15fe8a2
MIME-Version: 1.0
Date: Mon, 25 Mar 2024 09:07:53 +0100
From: Nicola Vetrini 
To: Jan Beulich 
Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com,
 ayan.kumar.halder@amd.com, consulting@bugseng.com,
 andrew.cooper3@citrix.com, roger.pau@citrix.com, bertrand.marquis@arm.com,
 julien@xen.org, George Dunlap , "Daniel P. Smith"
 , Volodymyr Babchuk
 , xen-devel@lists.xenproject.org
Subject: Re: [XEN PATCH 00/11] address some violations of MISRA C Rule 20.7
In-Reply-To: <9a9464de-f288-4f98-a194-22def7f2c4be@suse.com>
References: 
 <9a9464de-f288-4f98-a194-22def7f2c4be@suse.com>
Message-ID: 
X-Sender: nicola.vetrini@bugseng.com
Organization: BUGSENG s.r.l.
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit

On 2024-03-25 09:00, Jan Beulich wrote:
> On 22.03.2024 17:01, Nicola Vetrini wrote:
>> Hi all,
>> 
>> this series aims to refactor some macros that cause violations of 
>> MISRA C Rule
>> 20.7 ("Expressions resulting from the expansion of macro parameters 
>> shall be
>> enclosed in parentheses"). All the macros touched by these patches are 
>> in some
>> way involved in violations, and the strategy adopted to bring them 
>> into
>> compliance is to add parentheses around macro arguments where needed.
>> 
>> Given that the community has previously requested a deviation from the 
>> rule, as
>> stated in docs/misra/deviations.rst, and reported below for 
>> convenience [1],
>> some macro parameters do not need any adjusting (e.g., when used as 
>> lhs to
>> an assignment in statement expressions).
>> 
>> Patch 1 is taken, with adjustments, from [2]. Patches 2 and 3 are 
>> taken from [3]
>> without any modifications. All other patches are new in this series 
>> and are
>> pairwise indipendent.
>> 
>> [1] - Code violating Rule 20.7 is safe when macro parameters are used:
>>        (1) as function arguments;
>>        (2) as macro arguments;
>>        (3) as array indices;
>>        (4) as lhs in assignments.
>> 
>> [2] 
>> https://lore.kernel.org/xen-devel/b93a64b93ef4210f5fe96368c2522e5e71e9c87c.1709896401.git.nicola.vetrini@bugseng.com/
>> [3] 
>> https://lore.kernel.org/xen-devel/cover.1710762555.git.nicola.vetrini@bugseng.com/
>> 
>> Nicola Vetrini (11):
>>   xen/list: address violations of MISRA C Rule 20.7
>>   xen/xsm: add parentheses to comply with MISRA C Rule 20.7
>>   xen/efi: efibind: address violations of MISRA C Rule 20.7
>>   xentrace: address violation of MISRA C Rule 20.7
>>   xen: address MISRA C Rule 20.7 violation in generated hypercall
>>   xen/efi: address violations of MISRA C Rule 20.7
>>   xen/page_alloc: address violations of MISRA C Rule 20.7
>>   x86/altcall: address violations of MISRA C Rule 20.7
>>   x86/msi: address violation of MISRA C Rule 20.7 and coding style
>>   x86/hvm: address violations of Rule 20.7
>>   x86/public: hvm: address violations of MISRA C Rule 20.7
> 
> Just to clarify: While most of the patches here are new, two(?) I think
> were submitted before. As such, to indicate that, the series as a whole
> would want to be tagged v2.
> 
> Jan

Ok, that was an oversight. Technically the list.h patch makes this a v3, 
then.

-- 
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)


From xen-devel-bounces@lists.xenproject.org Mon Mar 25 08:09:38 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 08:09:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697603.1088495 (Exim 4.92)
	(envelope-from )
	id 1rofOi-0000PB-Hz; Mon, 25 Mar 2024 08:09:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697603.1088495; Mon, 25 Mar 2024 08:09:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rofOi-0000P4-FN; Mon, 25 Mar 2024 08:09:36 +0000
Received: by outflank-mailman (input) for mailman id 697603;
 Mon, 25 Mar 2024 08:09:35 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rofOg-0000NX-Tv
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 08:09:35 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on20600.outbound.protection.outlook.com
 [2a01:111:f403:2412::600])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0337cad9-ea7f-11ee-afe3-a90da7624cb6;
 Mon, 25 Mar 2024 09:09:33 +0100 (CET)
Received: from DM6PR18CA0034.namprd18.prod.outlook.com (2603:10b6:5:15b::47)
 by DS7PR12MB6070.namprd12.prod.outlook.com (2603:10b6:8:9e::14) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.31; Mon, 25 Mar
 2024 08:09:29 +0000
Received: from CY4PEPF0000EE3C.namprd03.prod.outlook.com
 (2603:10b6:5:15b:cafe::1c) by DM6PR18CA0034.outlook.office365.com
 (2603:10b6:5:15b::47) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.13 via Frontend
 Transport; Mon, 25 Mar 2024 08:09:29 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CY4PEPF0000EE3C.mail.protection.outlook.com (10.167.242.16) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Mon, 25 Mar 2024 08:09:28 +0000
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Mon, 25 Mar
 2024 03:09:27 -0500
Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Mon, 25 Mar 2024 03:09:26 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0337cad9-ea7f-11ee-afe3-a90da7624cb6
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=jN1pE6z/OX8Kc5m1SX3UsIIbW9pMZ3oi76ysGWe2+1yOUwDo3n6hY6JD0HLwmTpYcFOq746Qn3iW5txEObiwtedmltX6nN3Dcx0Dh+9mt+4cPv7JekV21k1v5Gdtpjtloc44Hn5guB9Qr/Xin/q6HNaK6q3LzO1RSyEcK3ndyrmqzZd2IeqGS9JLFFOzD5FLUKBUPf06vCY6MdmOqgV8a15XOeuO1r8sVmxoZZwmSXpyOZLLKQmxIp4UEyKrbye1628wi5XimhYoU08/c+CCzQEyaP4ZdQRXIaC+9Aa+qMy51VjDz00sKUAE6ABHlKn4dqPSZfir/shWehtzGXm//Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=9qqCeHiGxcnKtEmwLOpaSsREI/g5oQTNBqhU0BNwswI=;
 b=DIIaC8F27Vfet681OAWpNQQidzI16LKbCEM7muWJ6TN2iSSS+q0zX2BNv59E3mnmkLe9Ws+qoM9Ifn7kyTAAq8O59+8ddcb9545YPWd25S9SfUO34Zpd3VasXYsBXF1wp3OysXBoauD6/wdnZzgOt68PNYKh9veief6UW7JekqE1mpn5tv431PQwaR94BHlPkZ8cPK9f1aZOzbdkoOXj4TRtrxz5jCo+/Br8kr4FMX/Jcsd/U8fE6AoGy0WYfg1bf6V/1f+QpgFFOWyq5pWuZHvZQzm6RpAmBSut6vaB+Z9pMaI0SGti2lxTsQji7Fds5pkkAI+YjV7Se08gr4c2mg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=arm.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=9qqCeHiGxcnKtEmwLOpaSsREI/g5oQTNBqhU0BNwswI=;
 b=y5LxeBu+66Gd+fDF/iKhdnYj7oEflcBZKoSXRex+r/wIiKWOoW1FmH8FS4AOQUN4YWztzpAKOgXrwjqrTGXq9mdwRwPiuioAIdczaiPznIEs25opMRgWRfpCHLiJSuaKRAx7ymaclAo+fRhNcCbZWy/GF896InuSgRZkIXedEEk=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Message-ID: <48ac6c83-a907-4442-ad3d-15653caaf64a@amd.com>
Date: Mon, 25 Mar 2024 09:09:26 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 10/11] xen/arm: fix duplicate /reserved-memory node in
 Dom0
To: Luca Fancellu , 
CC: Penny Zheng , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Volodymyr Babchuk 
References: <20240312130331.78418-1-luca.fancellu@arm.com>
 <20240312130331.78418-11-luca.fancellu@arm.com>
Content-Language: en-US
From: Michal Orzel 
In-Reply-To: <20240312130331.78418-11-luca.fancellu@arm.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB04.amd.com: michal.orzel@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CY4PEPF0000EE3C:EE_|DS7PR12MB6070:EE_
X-MS-Office365-Filtering-Correlation-Id: 976408e8-a81a-4f97-f9a9-08dc4ca2e52f
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	I5IgkQQCinrGcH+sxAQrVBUA8ZmT9zkGXVEXf8X6Xuar56CeI7nvXblXoOE3+Xvjmzkoic8aDLBcHXXpUL9Hf9OZHsJBYEgK8GyEMjkp6CtBcwe+cxypyhEWioGx5tPrJvpyde9pM0RpTNcWdzWrueX6rCpPjXAkdj5Y5RGN7scM3NFIrBWH6rtMxgffUSD8r1jhjgXUan9bybk+8I21QPfEt4n0PGuRtMr8tDuEC+fkLAEm4AGIF09Lzw/cRocUtexWK/yMSIGFl4frUpKMofwQ4u01tcf6GzeYhgtwJ6URRboi93PZMf6fr6ZuskLd5kxzQPi2H6AVObcx6FTuNJePim3zpHwbDIipmEXnz1mYEDhxfFC9c92HVmtaLER5f/jJGNpYJGJNwkYnnynRz0rdgwiQ7mkpe9fWWHfQ3tK5GIfu2DGl/uoqB8agtKvyH+/+5V7nAPLcWMNiiEYaCP8FP/nuTGw19DQY7GXVhm8VsssLMYbOBU0poWIFNYM8ulBAQmCn74AS3paKWjhMhyavBOYNS2BUC9cKatXa8L63tqrxEsDVT2TE8Mtv8XgXhtaYmNwmcey6uFok437NUOk3N8yLDp60odq2rIg9WJ79t/D4Vs6Z4Kyo01YyrT/ODr51oa+fOk0DIL/fzglegegNCVhBBT7ZEZ4iD3wkQ/vQ7THXubvF/v0AwMcYhp0nNJbl8q1pYdjUx7TE0Af/7Q==
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(1800799015)(376005)(36860700004)(82310400014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Mar 2024 08:09:28.7057
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 976408e8-a81a-4f97-f9a9-08dc4ca2e52f
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CY4PEPF0000EE3C.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR12MB6070

Hi Luca,

On 12/03/2024 14:03, Luca Fancellu wrote:
> 
> 
> From: Penny Zheng 
> 
> In case there is a /reserved-memory node already present in the host dtb,
> current Xen codes would create yet another /reserved-memory node when
> the static shared memory feature is enabled and static shared memory
> region are present, this would result in an incorrect device tree
s/region/regions, please add full stop after present.

> generation and guest would not be able to detect the static shared memory
s/guest/hwdom to make it clear when the issue can be observed

> region.
> 
> Avoid this issue checking the presence of the /reserved-memory node and
by checking

> appending the nodes instead of generating a duplicate /reserved-memory.
> 
> Signed-off-by: Penny Zheng 
> Signed-off-by: Luca Fancellu 
> ---
> v1:
>  - Rework of https://patchwork.kernel.org/project/xen-devel/patch/20231206090623.1932275-11-Penny.Zheng@arm.com/
> ---
>  xen/arch/arm/domain_build.c             | 23 ++++++++++++++++++++---
>  xen/arch/arm/include/asm/static-shmem.h | 11 +++++++++++
>  xen/arch/arm/static-shmem.c             | 12 +++++++-----
>  3 files changed, 38 insertions(+), 8 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 740c483ea2db..575e906d81a6 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -1620,6 +1620,7 @@ static int __init handle_node(struct domain *d, struct kernel_info *kinfo,
>          DT_MATCH_PATH("/hypervisor"),
>          { /* sentinel */ },
>      };
> +    static __initdata bool res_mem_node_found = false;
>      struct dt_device_node *child;
>      int res, i, nirq, irq_id;
>      const char *name;
> @@ -1714,6 +1715,19 @@ static int __init handle_node(struct domain *d, struct kernel_info *kinfo,
>      if ( res )
>          return res;
> 
> +    if ( dt_node_path_is_equal(node, "/reserved-memory") )
> +    {
> +        res_mem_node_found = true;
> +        /*
> +         * Avoid duplicate /reserved-memory nodes in Device Tree, so list the
s/list/add

> +         * static shared memory nodes there.
> +         */
> +        res = make_shm_memory_node(d, kinfo, dt_n_addr_cells(node),
> +                                   dt_n_size_cells(node));
> +        if ( res )
> +            return res;
> +    }
> +
>      for ( child = node->child; child != NULL; child = child->sibling )
>      {
>          res = handle_node(d, kinfo, child, p2mt);
> @@ -1766,9 +1780,12 @@ static int __init handle_node(struct domain *d, struct kernel_info *kinfo,
>                  return res;
>          }
> 
> -        res = make_resv_memory_node(d, kinfo, addrcells, sizecells);
> -        if ( res )
> -            return res;
> +        if ( !res_mem_node_found )
> +        {
> +            res = make_resv_memory_node(d, kinfo, addrcells, sizecells);
> +            if ( res )
> +                return res;
> +        }
>      }
> 
>      res = fdt_end_node(kinfo->fdt);
> diff --git a/xen/arch/arm/include/asm/static-shmem.h b/xen/arch/arm/include/asm/static-shmem.h
> index 2f70aed53ac7..d28b9540d49b 100644
> --- a/xen/arch/arm/include/asm/static-shmem.h
> +++ b/xen/arch/arm/include/asm/static-shmem.h
> @@ -35,6 +35,10 @@ int remove_shm_from_rangeset(const struct kernel_info *kinfo,
>  int remove_shm_holes_for_domU(const struct kernel_info *kinfo,
>                                struct membanks *ext_regions);
> 
> +int make_shm_memory_node(const struct domain *d,
> +                         const struct kernel_info *kinfo, int addrcells,
> +                         int sizecells);
> +
>  #else /* !CONFIG_STATIC_SHM */
> 
>  static inline int make_resv_memory_node(const struct domain *d,
> @@ -79,6 +83,13 @@ static inline int remove_shm_holes_for_domU(const struct kernel_info *kinfo,
>      return 0;
>  }
> 
> +static inline int make_shm_memory_node(const struct domain *d,
> +                                       const struct kernel_info *kinfo,
> +                                       int addrcells, int sizecells)
> +{
> +    return 0;
> +}
> +
>  #endif /* CONFIG_STATIC_SHM */
> 
>  #endif /* __ASM_STATIC_SHMEM_H_ */
> diff --git a/xen/arch/arm/static-shmem.c b/xen/arch/arm/static-shmem.c
> index b3e2105dd3f2..67d5fa3b5d25 100644
> --- a/xen/arch/arm/static-shmem.c
> +++ b/xen/arch/arm/static-shmem.c
> @@ -287,15 +287,17 @@ int __init process_shm(struct domain *d, struct kernel_info *kinfo,
>      return 0;
>  }
> 
> -static int __init make_shm_memory_node(const struct domain *d, void *fdt,
> -                                       int addrcells, int sizecells,
> -                                       const struct membanks *mem)
> +int __init make_shm_memory_node(const struct domain *d,
> +                                const struct kernel_info *kinfo, int addrcells,
> +                                int sizecells)
Strictly speaking, changing the function signature is not mandatory for this change, so I would
at least mention it in the commit msg.

Other than that:
Reviewed-by: Michal Orzel 

~Michal



From xen-devel-bounces@lists.xenproject.org Mon Mar 25 08:18:11 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 08:18:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697610.1088506 (Exim 4.92)
	(envelope-from )
	id 1rofWw-0001xl-Gh; Mon, 25 Mar 2024 08:18:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697610.1088506; Mon, 25 Mar 2024 08:18:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rofWw-0001xe-Dz; Mon, 25 Mar 2024 08:18:06 +0000
Received: by outflank-mailman (input) for mailman id 697610;
 Mon, 25 Mar 2024 08:18:05 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rofWv-0001xY-6M
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 08:18:05 +0000
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com
 [2a00:1450:4864:20::62f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 32bc4bfe-ea80-11ee-a1ef-f123f15fe8a2;
 Mon, 25 Mar 2024 09:18:02 +0100 (CET)
Received: by mail-ej1-x62f.google.com with SMTP id
 a640c23a62f3a-a46d0a8399aso848972166b.1
 for ; Mon, 25 Mar 2024 01:18:02 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a5-20020a1709065f8500b00a46478fbbbesm2756165eju.153.2024.03.25.01.18.01
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 25 Mar 2024 01:18:02 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 32bc4bfe-ea80-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711354682; x=1711959482; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=E3Lkiln8exDA5vqgtQzTSrGCUHrNJVV3YoVoI+pFmhA=;
        b=d8UT94UoN8s/fQDWD//gq2bZq2zVgQuVuqHlQVB884kK6/U5JuAHfr0UfKhQyn+tDk
         76cUYxOoIox7VQaV4YYKGuaf6pjPhwpP1ZcvLY0p9ZPq41f3Fw23ZLbFxa7PqhCbOo8u
         eb7acKSIjFkR53M6z0r6StGnq92F26iseSH0Ro3S8XxfGSh6MZmP6WbfQ94fi/M3qiRs
         TyjYtq/FYfvoQJbQOF9zKR2BBc3t6Sb+k2C5mVOso46vhOsyz5Zw6naDg2E/bP4ISi81
         yVUEAc6lsHKhztRClieYCIkNSNO/sk1zjMHYspoI2VjKCqopwy+h60NMjmK4VFwiJskg
         CmBQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711354682; x=1711959482;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=E3Lkiln8exDA5vqgtQzTSrGCUHrNJVV3YoVoI+pFmhA=;
        b=d8gpEFYvESNnwfS1nHIl2evarm5CDXNi8t5xsEpa7qv+JYwBZ3KrMCq4XLHHF6cHBN
         alGLHxyXrDwAk8q/zr4LpbCVjpC/lgjtS3NZkyNfhtndEqkCoslRkSgCZZK7WnKebNBQ
         +cax4hyeFgAmKPpUS8jPLCtg+K1zRRUO8NgWhm6WgBNz7GDqyjCuW3DlJ8/qzQgEa3FC
         FIamHKhVbrwCLSibRw8bMOwpybe32bpRi4AfHaf8p38BYyXh8E0Hijn/ZjDMiGK4yDPK
         ahMKGtDDCxMkR4g6IWzSiCgFrMZS+UPET1BozudcHSqXiUCVFYwDazq2Pq30hw+7Wn9m
         Xk0w==
X-Forwarded-Encrypted: i=1; AJvYcCWRQQMHD6lcm8KQkbpWN4tG9B8rrE1+T1ERUfHiFcg2P/fehR4Ppx5vz4oU/iEdXOXzDvMkdjjmendcjJU6tV7P91OCwtHAbMQ3P6cz+P8=
X-Gm-Message-State: AOJu0YwfDKezCanDmuUcqIz+stVFK4OYa5PR/5IC9s51CwbpxahtaBz/
	NHzkrStX2iZD3q6cRqYnrr8g77JC5SkMUDbU5QSR/dutfotKgwTUbBvGwQADwQ==
X-Google-Smtp-Source: AGHT+IEFD3GL7ybjjAhay4B6OaPNFKZ2fLn2/4T26BPxlbGO7yCExd6QHV2T+1pSRCNvhTnJrUT99A==
X-Received: by 2002:a17:907:944c:b0:a47:322b:c94d with SMTP id dl12-20020a170907944c00b00a47322bc94dmr6511198ejc.6.1711354682230;
        Mon, 25 Mar 2024 01:18:02 -0700 (PDT)
Message-ID: <1a440fbf-f37c-41fe-b31c-0afe0fd77c8e@suse.com>
Date: Mon, 25 Mar 2024 09:18:03 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 10/20] xen/riscv: introduce atomic.h
Content-Language: en-US
To: Oleksii 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 xen-devel@lists.xenproject.org
References: 
 <22ee9c8cc62c76cfb799fed800636e7c8bf25a17.1710517542.git.oleksii.kurochko@gmail.com>
 <78a86041-72e2-410f-b6a7-212656b0dba3@suse.com>
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 22.03.2024 13:25, Oleksii wrote:
> On Thu, 2024-03-21 at 14:03 +0100, Jan Beulich wrote:
>> On 15.03.2024 19:06, Oleksii Kurochko wrote:
>>> + */
>>> +static always_inline void read_atomic_size(const volatile void *p,
>>> +                                           void *res,
>>> +                                           unsigned int size)
>>> +{
>>> +    switch ( size )
>>> +    {
>>> +    case 1: *(uint8_t *)res = readb(p); break;
>>> +    case 2: *(uint16_t *)res = readw(p); break;
>>> +    case 4: *(uint32_t *)res = readl(p); break;
>>> +    case 8: *(uint32_t *)res  = readq(p); break;
>>
>> Nit: Excess blank before =.
>>
>> Also - no #ifdef here to be RV32-ready?
> Because there is #ifdef RV32 in io.h for readq().

There you'd run into __raw_readq()'s BUILD_BUG_ON(), afaict even for
1-, 2-, or 4-byte accesses. That's not quite what we want here.

>>> +/*
>>> + * First, the atomic ops that have no ordering constraints and
>>> therefor don't
>>> + * have the AQ or RL bits set.  These don't return anything, so
>>> there's only
>>> + * one version to worry about.
>>> + */
>>> +#define ATOMIC_OP(op, asm_op, I, asm_type, c_type, prefix)  \
>>> +static inline                                               \
>>> +void atomic##prefix##_##op(c_type i, atomic##prefix##_t *v) \
>>> +{                                                           \
>>> +    asm volatile (                                          \
>>> +        "   amo" #asm_op "." #asm_type " zero, %1, %0"      \
>>> +        : "+A" (v->counter)                                 \
>>> +        : "r" (I)                                           \
>>
>> Btw, I consider this pretty confusing. At the 1st and 2nd glance this
>> looks like a mistake, i.e. as if i was meant. Imo ...
>>
>>> +        : "memory" );                                       \
>>> +}                                                           \
>>> +
>>> +/*
>>> + * Only CONFIG_GENERIC_ATOMIC64=y was ported to Xen that is the
>>> reason why
>>> + * last argument for ATOMIC_OP isn't used.
>>> + */
>>> +#define ATOMIC_OPS(op, asm_op, I)                           \
>>> +        ATOMIC_OP (op, asm_op, I, w, int,   )
>>> +
>>> +ATOMIC_OPS(add, add,  i)
>>> +ATOMIC_OPS(sub, add, -i)
>>> +ATOMIC_OPS(and, and,  i)
>>> +ATOMIC_OPS( or,  or,  i)
>>> +ATOMIC_OPS(xor, xor,  i)
>>
>> ... here you want to only pass the (unary) operator (and leaving that
>> blank
>> is as fine as using +).
> I agree that a game with 'i' and 'I' looks confusing, but I am not
> really understand what is wrong with using ' i' here. It seems that
> preprocessed macros looks fine:
>    static inline void atomic_add(int i, atomic_t *v) { asm volatile ( "  
>    amo" "add" "." "w" " zero, %1, %0" : "+A" (v->counter) : "r" (i) :
>    "memory" ); }
>    
>    static inline void atomic_sub(int i, atomic_t *v) { asm volatile ( "  
>    amo" "add" "." "w" " zero, %1, %0" : "+A" (v->counter) : "r" (-i) :
>    "memory" ); }

I didn't question the pre-processed result being correct. Instead I said
that I consider the construct confusing to the reader, for looking as if
there was a mistake (in the case of the letter i used). Note also in
particular how the macro invocations need to be in sync with the macro
implementation, for lower case i being used both in the macro and in its
invocations. Anything parameterized would better be fully so, at the
very least to avoid, as said, confusion. (Having macros depend on
context at their use sites _may_ be okay for local helper macros, but
here we're talking about a not even private header file.)

>>> +/* This is required to provide a full barrier on success. */
>>> +static inline int atomic_add_unless(atomic_t *v, int a, int u)
>>> +{
>>> +       int prev, rc;
>>> +
>>> +    asm volatile (
>>> +        "0: lr.w     %[p],  %[c]\n"
>>> +        "   beq      %[p],  %[u], 1f\n"
>>> +        "   add      %[rc], %[p], %[a]\n"
>>> +        "   sc.w.rl  %[rc], %[rc], %[c]\n"
>>> +        "   bnez     %[rc], 0b\n"
>>> +        RISCV_FULL_BARRIER
>>
>> With this and no .aq on the load, why the .rl on the store?
> It is something that LKMM requires [1].
> 
> This is not fully clear to me what is so specific in LKMM, but accoring
> to the spec:
>    Ordering Annotation Fence-based Equivalent
>    l{b|h|w|d|r}.aq     l{b|h|w|d|r}; fence r,rw
>    l{b|h|w|d|r}.aqrl   fence rw,rw; l{b|h|w|d|r}; fence r,rw
>    s{b|h|w|d|c}.rl     fence rw,w; s{b|h|w|d|c}
>    s{b|h|w|d|c}.aqrl   fence rw,w; s{b|h|w|d|c}
>    amo.aq          amo; fence r,rw
>    amo.rl          fence rw,w; amo
>    amo.aqrl        fence rw,rw; amo; fence rw,rw
>    Table 2.2: Mappings from .aq and/or .rl to fence-based equivalents.
>    An alternative mapping places a fence rw,rw after the existing 
>    s{b|h|w|d|c} mapping rather than at the front of the
>    l{b|h|w|d|r} mapping.

I'm afraid I can't spot the specific case in this table. None of the
stores in the right column have a .rl suffix.

>    It is also safe to translate any .aq, .rl, or .aqrl annotation into
>    the fence-based snippets of
>    Table 2.2. These can also be used as a legal implementation of
>    l{b|h|w|d} or s{b|h|w|d} pseu-
>    doinstructions for as long as those instructions are not added to
>    the ISA.
> 
> So according to the spec, it should be:
>  sc.w ...
>  RISCV_FULL_BARRIER.
> 
> Considering [1] and how this code looks before, it seems to me that it
> is safe to use lr.w.aq/sc.w.rl here or an fence equivalent.

Here you say "or". Then why dos the code use sc.?.rl _and_ a fence?

> But in general it ( a combination of fence, .aq, .rl ) can be
> considered as the same things in this context, so it is possible to
> leave this function as is to be synced here with Linux kernel.

In turn I also don't understand this. Yes, the excess .rl certainly
doesn't render things unsafe. But what's the purpose of the .rl? That's
what my original question boiled down to.

Jan

> [1]https://lore.kernel.org/lkml/1520274276-21871-1-git-send-email-parri.andrea@gmail.com/
> 
> ~ Oleksii



From xen-devel-bounces@lists.xenproject.org Mon Mar 25 08:59:23 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 08:59:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697613.1088516 (Exim 4.92)
	(envelope-from )
	id 1rogAg-000860-Eu; Mon, 25 Mar 2024 08:59:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697613.1088516; Mon, 25 Mar 2024 08:59:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rogAg-00085t-BZ; Mon, 25 Mar 2024 08:59:10 +0000
Received: by outflank-mailman (input) for mailman id 697613;
 Mon, 25 Mar 2024 08:59:09 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rogAf-00085V-3g
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 08:59:09 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on20601.outbound.protection.outlook.com
 [2a01:111:f403:200a::601])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id eea26485-ea85-11ee-afe3-a90da7624cb6;
 Mon, 25 Mar 2024 09:59:06 +0100 (CET)
Received: from DM5PR07CA0111.namprd07.prod.outlook.com (2603:10b6:4:ae::40) by
 PH0PR12MB7983.namprd12.prod.outlook.com (2603:10b6:510:28e::8) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.7409.31; Mon, 25 Mar 2024 08:59:02 +0000
Received: from CH3PEPF00000014.namprd21.prod.outlook.com
 (2603:10b6:4:ae:cafe::c7) by DM5PR07CA0111.outlook.office365.com
 (2603:10b6:4:ae::40) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.13 via Frontend
 Transport; Mon, 25 Mar 2024 08:59:02 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 CH3PEPF00000014.mail.protection.outlook.com (10.167.244.119) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7452.0 via Frontend Transport; Mon, 25 Mar 2024 08:59:02 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Mon, 25 Mar
 2024 03:59:01 -0500
Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Mon, 25 Mar 2024 03:58:59 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: eea26485-ea85-11ee-afe3-a90da7624cb6
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=YfNgrUG9g+DHdtC0T5DQXbJ3LSeO8pAvFhkgmlLedlxs9NJ9pln+fh3EXkw3FcBSLFRutR+WstNcQqY62ZNFV5pb1OQ9M+04CEFOuwedrHKvsGlMaAtxAuI9nyxVret1dnX057idt4A0gXHrecjw6hnbjRbXwMLlsATsgSN3Y/SNnYBWL57zWo3wJeYPIgYvdBl7cwoLhsWkwqEmbU5vaIC80/uULqMOJ3sTNeYTs61mCWIbsTTvv21pRmH2Shy8pxrrnLygnOJ3Guh66XoiPcdknnrNruhRd4HNZz0izdgTroCKpp0JbChpiWaKR6rb6XOUHFAnKcLbdjTuyRvjZw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=b4H9KjaFfUVYMideOenLmn3bhD7kmltbtFAZOlSa/Co=;
 b=fI3LVZH/2gJaNH4N6WnhkS2MMZO4vZVlPOcRXZMF2DEsEZ+dcT3K+7P5bRHUa8vwX6iy/qxptgWoJQVCL80aW1dVCaS1Y8QckHspWkBX57moZsUttFYILl/3XmeL0basi78tp/JCzpsYljZ6RoMeiHyPBEe5Hft9XCuZmp38dzkNgRHgA0mQYOxSZCfh+3kEz34VCsqZSiHM/1Znol0w/MDOSQh2g/ARqnVs/zeAbolBF0+tU2UClZbFRLMHbPq4h5PRCM72bPHs3UHWI3rGuEOKq29XvnyhcNtt4YlTzqVh+vHIl9gCq69aXyua9pLr2JauL5OVXd8NIUxWvnNblQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=arm.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=b4H9KjaFfUVYMideOenLmn3bhD7kmltbtFAZOlSa/Co=;
 b=HRLF+7Y8FFwYbIvccAbNVHWRoyd1dMRLFzazE2JCC7NTmB8y2hrZyD/uhrFXAsspLtkzdJ4/zy/mO1H0Fh6Jha59NBngEPTbPrx2qiDsRVxR/mj5S01fsbRZd7XR3fT9IxNorXZmP/pyxjXxmEo5IAJEnlCg/CuYHt4mSKzqQ8M=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
Message-ID: <3a9e8323-9eb3-4c06-9ef1-e85c8bf2aefd@amd.com>
Date: Mon, 25 Mar 2024 09:58:59 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 11/11] xen/arm: List static shared memory regions as
 /memory nodes
To: Luca Fancellu , 
CC: Stefano Stabellini , Julien Grall
	, Bertrand Marquis , Volodymyr
 Babchuk 
References: <20240312130331.78418-1-luca.fancellu@arm.com>
 <20240312130331.78418-12-luca.fancellu@arm.com>
Content-Language: en-US
From: Michal Orzel 
In-Reply-To: <20240312130331.78418-12-luca.fancellu@arm.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB03.amd.com: michal.orzel@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH3PEPF00000014:EE_|PH0PR12MB7983:EE_
X-MS-Office365-Filtering-Correlation-Id: 30a2c145-5acd-43df-81d1-08dc4ca9d124
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	qKRGCT3ZiIJXc4htL89UCzEaz6SchndALC3lFhkNwcptL10gx/YtqTOHor2kC0cejGTgwcrx+m4i/SPciLk7+e+gZIi3Kz2odCsaEgJyLU+ttOnQn5N9uiuq3JsubaI0ggcFUufUKgRNCE2ucI9rvXrZfqBPcyHLU8VUZ8G7317kGJ5UHmgC1pfDuvZUkyAn902DVOe5VIcoj0qSqLGozKCbxVSYYmrlb6Xq7rW78ofsMcur33EYCc08fQmIHJTzpqI9C/Kf+DD7qG27bGYWF6a9LAxPZBdV96zOya8A5ZvzYsF9KQ1WDvooTAnpmQYB2D+7J5kB6b8jdhcwNP0z4fDFnpN1pbAOy7IgyUjwfHSOlI86T1OGzQmxPl3cZljAbmpxdAyZpUm1PUWWF3zhdIQiH/0R6UklGDXBuuj//DG2dxNAxKyBLmQayMxpmqRZovMtlOakpxm2+FizTZlFI2osktTCeKHR9UswIUu2VvpufQvx9wro5js4hhqGlf9+oNrIrVEyuDWvzL1iBrTSufMZ392i+KvTdDyo7EyBWoPJic3G1hM9xt0QAzGaEgw/Xazz8/gQkvBfl/ugVqbmIBvS5k2I1kthvRT7dkSc8HJvzv4x8teqcT/s1j9R65pPJe7dL1GzPswyR2lQUBFN96b1Uwnv1WvJf5zYn7iI9k5EdSghozrwcH7n6FU1c3sPwZUWWgyUeGQvDYSs5XqtFNr21HG2of/aGS/kxfSp7ir42+FkB+PSrW0hPdArbl2J
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(1800799015)(376005)(36860700004)(82310400014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Mar 2024 08:59:02.1157
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 30a2c145-5acd-43df-81d1-08dc4ca9d124
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH3PEPF00000014.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR12MB7983

Hi Luca,

On 12/03/2024 14:03, Luca Fancellu wrote:
> 
> 
> Currently Xen is not exporting the static shared memory regions
> to the device tree as /memory node, this commit is fixing this
> issue.
Looking at the implementation, you will always call make_shm_memory_node() twice. For the first
time, to create /memory node and for the second time to create entry under /reserved-memory. Also,
you will create a separate /memory node for every single shmem region instead of combining them
in a single /memory region like make_memory_node() would do. Can't we reuse this function for simplicity?

Also, afaict it is not forbidden to specify shmem range (correct me if I'm wrong), where guest address will be
within with RAM allocated by Xen (e.g. GPA RAM range 0x40000000 - 0x60000000 and shmem is at 0x50000000). In this case,
you would create yet another /memory node that would result in overlap (i.e. more than one /memory node specifying the same range).

~Michal


From xen-devel-bounces@lists.xenproject.org Mon Mar 25 09:00:14 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 09:00:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697614.1088526 (Exim 4.92)
	(envelope-from )
	id 1rogBh-0001CC-Oe; Mon, 25 Mar 2024 09:00:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697614.1088526; Mon, 25 Mar 2024 09:00:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rogBh-0001C5-Lp; Mon, 25 Mar 2024 09:00:13 +0000
Received: by outflank-mailman (input) for mailman id 697614;
 Mon, 25 Mar 2024 09:00:12 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rogBg-0001Bt-Aq; Mon, 25 Mar 2024 09:00:12 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rogBg-00064Q-23; Mon, 25 Mar 2024 09:00:12 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rogBf-0000Qf-Ic; Mon, 25 Mar 2024 09:00:11 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rogBf-0003GA-I1; Mon, 25 Mar 2024 09:00:11 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=Q6pFocF3DiIjsUmN4kR5QL2voIm3sOX60J4xylIIE/o=; b=gaHWhQ/uTJEvVeb9Exhf3ASEAu
	CFTLXWjlKAZQViDkPWjvJN5qggm5yPyBycJeHTKHCtmYLBEIugsvg5P0H3a1ipopiCQr2GvdBvs12
	+HI6nK6QlhfO1Sv7Q3PnVKzS2lGzgWlAjCDRnvCtsuoeKc9N24u34EhmonUudLRuxgMM=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 185154: tolerable FAIL
X-Osstest-Failures:
    xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-qcow2:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-qcow2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-vhd:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-raw:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    xen=cbe393b709e0c6c3e2b10c3ac69fbea0abd530fe
X-Osstest-Versions-That:
    xen=cbe393b709e0c6c3e2b10c3ac69fbea0abd530fe
From: osstest service owner 
Date: Mon, 25 Mar 2024 09:00:11 +0000

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen                  cbe393b709e0c6c3e2b10c3ac69fbea0abd530fe
baseline version:
 xen                  cbe393b709e0c6c3e2b10c3ac69fbea0abd530fe

Last test of basis   185154  2024-03-25 01:52:11 Z    0 days
Testing same since                          (not found)         0 attempts

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-libvirt-qcow2                               pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-xl-qcow2                                    pass    
 test-amd64-amd64-libvirt-raw                                 pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-amd64-amd64-xl-raw                                      pass    
 test-armhf-armhf-xl-raw                                      pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-libvirt-vhd                                 pass    
 test-amd64-amd64-xl-vhd                                      pass    
 test-arm64-arm64-xl-vhd                                      pass    


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

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

Explanation of these 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


Published tested tree is already up to date.



From xen-devel-bounces@lists.xenproject.org Mon Mar 25 09:19:32 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 09:19:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697621.1088535 (Exim 4.92)
	(envelope-from )
	id 1rogUF-0003NG-EC; Mon, 25 Mar 2024 09:19:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697621.1088535; Mon, 25 Mar 2024 09:19:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rogUF-0003N9-BG; Mon, 25 Mar 2024 09:19:23 +0000
Received: by outflank-mailman (input) for mailman id 697621;
 Mon, 25 Mar 2024 09:19:22 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rogUE-0003N3-Bj
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 09:19:22 +0000
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com
 [2a00:1450:4864:20::52a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c3726191-ea88-11ee-afe3-a90da7624cb6;
 Mon, 25 Mar 2024 10:19:21 +0100 (CET)
Received: by mail-ed1-x52a.google.com with SMTP id
 4fb4d7f45d1cf-56c0d1bddc1so879403a12.3
 for ; Mon, 25 Mar 2024 02:19:21 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 h27-20020a0564020e9b00b0056bf6287f32sm2652302eda.26.2024.03.25.02.19.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 25 Mar 2024 02:19:20 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c3726191-ea88-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711358361; x=1711963161; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=GAfcqGCRxepAg7AVdXv8r0pD9kLR3bV2QzuVMdtPw64=;
        b=XIAvlhy+CZd1Kdww5uH/rjwOfBzmupB64b8Cbi5L1NY8bsValMpi6kYAQprKVZ+tKn
         KP7ZZyIh2G0zGyNPPa7x9vpX2+YicJpKVw4zpbQjnY3o/S0X9Wc8l0lehP17+Wqsd1et
         NBiw76pJgDoPUaP/7Qz4zcYOEoYvre4lQP3k3pJt6XIMxEjqGzuvBv3wXN75mCQaTqHw
         PnE9rpF+yzAx1dbrfmB0S11D/N8LQ+04zwEK+40J8w86b3dh6z5I4awsBHok9Ozal14R
         V670Vhx5o7QWL/ZBI2USpJb7tvYUSKrl0p4GpWG8t3xHeAeF9ZrB2P4mmxytpqPdPW/t
         LIFQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711358361; x=1711963161;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=GAfcqGCRxepAg7AVdXv8r0pD9kLR3bV2QzuVMdtPw64=;
        b=CKNTxwdwAHSB4uNoJGvitinguVoyC8meK17b2bcvxRvi3+RtBMFe2toj9drIlyn4JL
         ABgWavQbGcCPAu5wc0CSUbCHgsCxN8/XtBlUv34abvU9ilaxUmoO/I8bTISsBSMOJVTJ
         3lZb/HEHSFgOXGHCEonKhGNPf+Mz/k0wxKS5ZrNrGjQjCOPivJh00fLHSLTNXWV1jxXS
         Y6JWhbFS1lRPZ+aXWckWCEfzXouoRKSu2CyMpbTqVrpFgi0EjVekPkrV9bY/rUY06GiZ
         yDvR4r8W7nxYqn11ZG5qKfcM/4iyhZe2+E5uoW2t5AyVwyvwpT6gl2XtjGF2dFduOF38
         laiQ==
X-Forwarded-Encrypted: i=1; AJvYcCXmnE55TrqgSBKe4do0/EX3Z3cdBx+pJZ36SWF6ofpHGhlauGptsa603pvq4tN+Eldck6Se9mnRvNHEqqMyYMGVVXb/Z/ucCotYFhVwBM0=
X-Gm-Message-State: AOJu0YyaSJodvQrlzNh4SeyTHI+/tZJ6KIkLYFii+YaBaonF79h+vYw6
	AWJ2DXJ6sLecQNTh8BX7hT1rrAjWEsjXmxscRISUoHWlHJtdRWgCRBqSHfO6Mg==
X-Google-Smtp-Source: AGHT+IHLBI/s4Urmmo5SP0JH+uao/KRvS2d4I20iB2Kv3LZtbIfPiRztOIO+7zXAiqTtHECivp7LEw==
X-Received: by 2002:a50:c309:0:b0:56b:a91c:65a4 with SMTP id a9-20020a50c309000000b0056ba91c65a4mr4645514edb.7.1711358360693;
        Mon, 25 Mar 2024 02:19:20 -0700 (PDT)
Message-ID: 
Date: Mon, 25 Mar 2024 10:19:19 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 01/11] xen/list: address violations of MISRA C Rule
 20.7
Content-Language: en-US
To: Nicola Vetrini 
Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com,
 ayan.kumar.halder@amd.com, consulting@bugseng.com,
 andrew.cooper3@citrix.com, roger.pau@citrix.com, bertrand.marquis@arm.com,
 julien@xen.org, George Dunlap ,
 xen-devel@lists.xenproject.org
References: 
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 22.03.2024 17:01, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be safe with respect to expansions that
> can possibly alter the semantics of the passed-in macro parameter.
> 
> No functional change.
> 
> Signed-off-by: Nicola Vetrini 

Reviewed-by: Jan Beulich 




From xen-devel-bounces@lists.xenproject.org Mon Mar 25 09:20:23 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 09:20:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697623.1088546 (Exim 4.92)
	(envelope-from )
	id 1rogVC-0004s6-PH; Mon, 25 Mar 2024 09:20:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697623.1088546; Mon, 25 Mar 2024 09:20:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rogVC-0004rz-ML; Mon, 25 Mar 2024 09:20:22 +0000
Received: by outflank-mailman (input) for mailman id 697623;
 Mon, 25 Mar 2024 09:20:21 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rogVB-0004qD-8q
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 09:20:21 +0000
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com
 [2a00:1450:4864:20::62a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e5e1889d-ea88-11ee-a1ef-f123f15fe8a2;
 Mon, 25 Mar 2024 10:20:18 +0100 (CET)
Received: by mail-ej1-x62a.google.com with SMTP id
 a640c23a62f3a-a466a1f9ea0so246617466b.1
 for ; Mon, 25 Mar 2024 02:20:18 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 h27-20020a0564020e9b00b0056bf6287f32sm2652302eda.26.2024.03.25.02.20.17
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 25 Mar 2024 02:20:18 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e5e1889d-ea88-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711358418; x=1711963218; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=DdaEKuCAKwKYemJzNlkYhpxFzcP0nn/dPemydzn2UIg=;
        b=EZ2DkPNJo6ZPpyXQCj18r18ct2Io4mf3grwzKtNJV7sEmsIFFvILNtAAwWnIznDpaV
         7wauTMF7eMnlr6ewLMmVkSRc7UHhZzZEFd+ElBZGv/xEa7+0sCmQldY0GeA0xm2FAu7F
         XhFvTUDvC1G1FCn9zCsQF7vlJIIbPIIlz/8NDpYMvXtzoEMZdeXIIctn372tOewAdSZR
         GzNsYtxamdtZqL9VGyu7pf1kKFRIyliojXTdXU66IdDcEuRB/vlBGwVAINaQoYJOiix9
         rdXKkxcnok1O6/FynSP3T2Ly6mxPHqyApMiPThWiJXkD4rMmnKavqEAR3u2qYjLyq9i8
         OA0w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711358418; x=1711963218;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=DdaEKuCAKwKYemJzNlkYhpxFzcP0nn/dPemydzn2UIg=;
        b=PSBdMJZMuiStpugf4oIYaLO6SpBdLGchRfHs6ihfhJ4/Y0nv93HgYc+x1Uc6/Mg+C2
         tXYk6OkpL3F3+X9Sm3e3FtPHo5CUxYJl8hYmdUa29glrKklDrUchHxMykbf/xHqOkg4B
         85696H+IVIyBMho202n49fJTMOFshCMENAguxMP+SkjuFrGnj8SPR3r3swS1jxFQaGnh
         E+qK/yqJ3reyRZWDkgdMshi1gknTsB9kboZOnUukjRaIF4Z8EfUi81rYUB47Ndgfqvj8
         Ejj2efreom+oK7+3vUtCxrv3y7PVAaWmc/3Vbz6vXDAWpOgInrpxmsuewkqJZWFTheb0
         iATw==
X-Forwarded-Encrypted: i=1; AJvYcCVo0tNJrTTQ8GdHhiq5cy85ekvgBgBZyFrRaqANJ41zU/7OGVO/tuYly2asnH+jO6PTUd6RzVbTDFnxUhpTlgzDE05E9pMFpyHPEdDzuGI=
X-Gm-Message-State: AOJu0YxfBU4+EjvVye+PbCp81RKgtJSb0K9LPyp4uQhlu+2sw/SjbbwH
	PGj7JSwGA1A/ObHOGt6VIAbLZe+q40mWKqw0NIpMeH05ahl0wyywDPLlLpNSmQ==
X-Google-Smtp-Source: AGHT+IEU58a/4Bfyh+fZiFmk6y/g2F4EHzj6x1ygaCbR+9dYJNmsHMaQjSYKd2vspBPQFESX7qDHLw==
X-Received: by 2002:a50:bb6b:0:b0:56b:d92f:32c6 with SMTP id y98-20020a50bb6b000000b0056bd92f32c6mr5456644ede.5.1711358418408;
        Mon, 25 Mar 2024 02:20:18 -0700 (PDT)
Message-ID: <5dcd688f-dbd5-4335-aa84-cd4ed3e177a4@suse.com>
Date: Mon, 25 Mar 2024 10:20:17 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 04/11] xentrace: address violation of MISRA C Rule
 20.7
Content-Language: en-US
To: Nicola Vetrini 
Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com,
 ayan.kumar.halder@amd.com, consulting@bugseng.com,
 andrew.cooper3@citrix.com, roger.pau@citrix.com, bertrand.marquis@arm.com,
 julien@xen.org, George Dunlap ,
 xen-devel@lists.xenproject.org
References: 
 <06c112784c54fcd87792bb96515ecdf91b2109c3.1711118582.git.nicola.vetrini@bugseng.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <06c112784c54fcd87792bb96515ecdf91b2109c3.1711118582.git.nicola.vetrini@bugseng.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 22.03.2024 17:01, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be safe with respect to expansions that
> can possibly alter the semantics of the passed-in macro parameter.
> 
> No functional change.
> 
> Signed-off-by: Nicola Vetrini 

Acked-by: Jan Beulich 




From xen-devel-bounces@lists.xenproject.org Mon Mar 25 09:23:14 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 09:23:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697625.1088556 (Exim 4.92)
	(envelope-from )
	id 1rogXx-0005Zx-61; Mon, 25 Mar 2024 09:23:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697625.1088556; Mon, 25 Mar 2024 09:23:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rogXx-0005Zq-3E; Mon, 25 Mar 2024 09:23:13 +0000
Received: by outflank-mailman (input) for mailman id 697625;
 Mon, 25 Mar 2024 09:23:12 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rogXw-0005Zk-R1
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 09:23:12 +0000
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com
 [2a00:1450:4864:20::529])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4c465cdb-ea89-11ee-a1ef-f123f15fe8a2;
 Mon, 25 Mar 2024 10:23:10 +0100 (CET)
Received: by mail-ed1-x529.google.com with SMTP id
 4fb4d7f45d1cf-56845954ffeso5554479a12.2
 for ; Mon, 25 Mar 2024 02:23:10 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 i2-20020a17090639c200b00a471cbc4ddbsm2852188eje.26.2024.03.25.02.23.09
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 25 Mar 2024 02:23:10 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4c465cdb-ea89-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711358590; x=1711963390; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=GAfcqGCRxepAg7AVdXv8r0pD9kLR3bV2QzuVMdtPw64=;
        b=K+Zz0/5B8DhHHSLAo8Qsb1ERQBu+teJ6y0FHd4vA9Yu/sb5iRHLWDHPyEVYPZl4phd
         lPg1K8kMUO+NDkP6okgEcOHcKKTEO4+vwgfKtPzp/UkmryXkp66mOsVZy7hEp/6TcImx
         SCZgwEJ4+nniKwCXyaCO7POjg0SRM1yBlypHWDmgYxblp26bCoTErfYgqyEhyqD+725a
         ECtF1N6QZPrbSKZMjaswNJVPa7L+h42ruCUjht4uKHaweUPqjnq+8orZRBHoAVf1+TIc
         8MlIzrVDSn9zc3u6uHXNcxYmvXJ5BvSRQykZY7KL5NzabRaWLdMF1wqlOlmSCkgtFZgJ
         Zqdw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711358590; x=1711963390;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=GAfcqGCRxepAg7AVdXv8r0pD9kLR3bV2QzuVMdtPw64=;
        b=E3wSGQrEx1M0u8HDQ7AdTwDh04jiWecvsGAZT+c138aRQIn0RMvCmyKfweAhD7FHHN
         WV/t01fRDtew8MW4ODIgygGMNE3WlRFkyCnPUe3ZvlQ8jKq304ZIxs1KKPjlvxV/CvQO
         3UkSWfq0oBmaStk2NdXJg4iMhejPuB5eEVowutjBe8+ob34UOTEaGCN+GJY/ifhqeWFv
         rSnmVSYudGojpDOmlq0nJJCh30KtTqWpe2f0N7O0NIdZTOL67dtWkMa6Upo7qwBiY87t
         hnEp6E/BAaN+0X7ehSQo10J3PwfxmsSxplSfTVd8jsfRlolrkYWEKdXvtoDXd2V4p20z
         DAgw==
X-Forwarded-Encrypted: i=1; AJvYcCWDW/cfU8W8BnIevv20OdnDjIhgyfPex5eawyb7q4an28Pf/JoUfNzF0P1jSmxseOEQ/XJzlMuwGWqEYs/cid66OCP7ShLqCxZ9Co80XmU=
X-Gm-Message-State: AOJu0YxmldJBaYVrmvWBKYpjn8BK7WuwY90Ra/vYnrme2fKsN9QMQT70
	SsYh0bcFHPAppmATibBfZqhEMTgu5cjSziQWWROpXf4e7X+b9y93a4efSI+3+Q==
X-Google-Smtp-Source: AGHT+IHVlE1UYgmkyxYr//Grmdv30ddMt9o/VrIzo6tqQhiGVTUhuK5pi+N5N2KkcCXC2wGFrEHQrQ==
X-Received: by 2002:a17:906:dacd:b0:a4d:2021:32e5 with SMTP id xi13-20020a170906dacd00b00a4d202132e5mr223038ejb.50.1711358590266;
        Mon, 25 Mar 2024 02:23:10 -0700 (PDT)
Message-ID: <80f05150-2c7f-400e-bbea-c48f2ee81d46@suse.com>
Date: Mon, 25 Mar 2024 10:23:09 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 05/11] xen: address MISRA C Rule 20.7 violation in
 generated hypercall
Content-Language: en-US
To: Nicola Vetrini 
Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com,
 ayan.kumar.halder@amd.com, consulting@bugseng.com,
 andrew.cooper3@citrix.com, roger.pau@citrix.com, bertrand.marquis@arm.com,
 julien@xen.org, George Dunlap ,
 xen-devel@lists.xenproject.org
References: 
 <323c77d56f8dcbd6bf8f60c84aacff162265807e.1711118582.git.nicola.vetrini@bugseng.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <323c77d56f8dcbd6bf8f60c84aacff162265807e.1711118582.git.nicola.vetrini@bugseng.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 22.03.2024 17:01, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be safe with respect to expansions that
> can possibly alter the semantics of the passed-in macro parameter.
> 
> No functional change.
> 
> Signed-off-by: Nicola Vetrini 

Reviewed-by: Jan Beulich 




From xen-devel-bounces@lists.xenproject.org Mon Mar 25 09:25:43 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 09:25:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697626.1088566 (Exim 4.92)
	(envelope-from )
	id 1rogaI-00066t-IE; Mon, 25 Mar 2024 09:25:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697626.1088566; Mon, 25 Mar 2024 09:25:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rogaI-00066m-F6; Mon, 25 Mar 2024 09:25:38 +0000
Received: by outflank-mailman (input) for mailman id 697626;
 Mon, 25 Mar 2024 09:25:37 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rogaH-00066g-Cz
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 09:25:37 +0000
Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com
 [2a00:1450:4864:20::134])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a3108187-ea89-11ee-afe3-a90da7624cb6;
 Mon, 25 Mar 2024 10:25:36 +0100 (CET)
Received: by mail-lf1-x134.google.com with SMTP id
 2adb3069b0e04-513ccc70a6dso6983019e87.1
 for ; Mon, 25 Mar 2024 02:25:36 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 y4-20020a1709060a8400b00a46bec6da9fsm2829237ejf.203.2024.03.25.02.25.35
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 25 Mar 2024 02:25:35 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a3108187-ea89-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711358736; x=1711963536; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=kznjib0G8AwkMhdOq/UeLdrZcZUiMNdPT+KZdSJAyc8=;
        b=Tedbn79cWcUddWE6UjOXX3pZdbj7ppqDSszgFOeaebCsGrRDxVbWJdNpUgF+0jFB7w
         CZfABWKdK28DjTF6lA1sBVsnc8AfL1sJSL5if+xPi9ARU+hSesNlTJ4pFq3bPovCUEgO
         34b60PqG3pPYTYT17xnmKBhN2Ra2V7hrKUp/pCwwtolvouBzj5huaUi/3eNKyieD0R84
         IiOu56FE98WqULyymvXOmDKM80e87pI9UEM40YwhAsCzpccQ1DmkOnR+Gr4qIKz/hHJ8
         6m//TSkJsU+1Is5Pm3mQmjrrRgiP2rlvD5wloFUB3L096BtCRvkXFO4zvDW6VM7O+R2W
         Ml2A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711358736; x=1711963536;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=kznjib0G8AwkMhdOq/UeLdrZcZUiMNdPT+KZdSJAyc8=;
        b=mwUU4B2HGuIF80Z4G2okQSYaipbrVU8L9ukYSu+v9pDPsu2yMIqQ1QqC8DCXBoao/k
         LLthRNWQtLkxnJhEom5IAhdxyTHvZ2DX5JDbxQ0Gv8iY6qkQ4KGlcLc6SJ4Z3vs0LYls
         JYybd/vicn42fJotJ52UPmMWCWU+cOr6VVrPDIiLVHeatQthBSSySsKXXXerDZ9szE4Q
         OPIWN+1qVJHpnPMiza/YYk8Go1S5109uavz46OYCc1/xHbQqVItfKIe7CnMkFsHuMReF
         fqSCqrKFTXl5Hel3EJ7jJoChH59M051W8ocb1GzBct3pCT+RvFOBdch7Vkd3c+1m4oqr
         dv4A==
X-Forwarded-Encrypted: i=1; AJvYcCWbo8Ew+k5tgQFz5NTmPtA1b+avwwiMd3Yi1GlpkVY8okNfLINX8mD3hUqP/gyGJlWBf/pZrpy6p9Whk9GoQ2NftgZG2tKDBh8zXgWM3lA=
X-Gm-Message-State: AOJu0Yyu5Tn7snSz2f4vYNgc8qoQmg+RgnvRHGb6tIh7Y0pD1jLGWwjW
	z4TG4ZJArwaYb+875SXTSR7t3BsOlYWVirrgqyrR963ywZ//+ZcIoLIMt+26Ew==
X-Google-Smtp-Source: AGHT+IGYk8B2oGXMErBDFSXbGDMwMAbn3XVEL0PebZhGV8qHRxS6Nqu5tidnna3KjA1zWfpWZfel/A==
X-Received: by 2002:a19:3807:0:b0:513:e4e0:8e12 with SMTP id f7-20020a193807000000b00513e4e08e12mr5091797lfa.12.1711358735838;
        Mon, 25 Mar 2024 02:25:35 -0700 (PDT)
Message-ID: 
Date: Mon, 25 Mar 2024 10:25:34 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 06/11] xen/efi: address violations of MISRA C Rule
 20.7
Content-Language: en-US
To: Nicola Vetrini 
Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com,
 ayan.kumar.halder@amd.com, consulting@bugseng.com,
 andrew.cooper3@citrix.com, roger.pau@citrix.com, bertrand.marquis@arm.com,
 julien@xen.org, xen-devel@lists.xenproject.org
References: 
 <2d3842a990189c37fa12672994b779ad42975235.1711118582.git.nicola.vetrini@bugseng.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <2d3842a990189c37fa12672994b779ad42975235.1711118582.git.nicola.vetrini@bugseng.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 22.03.2024 17:01, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be safe with respect to expansions that
> can possibly alter the semantics of the passed-in macro parameter.
> 
> No functional change.
> 
> Signed-off-by: Nicola Vetrini 

Seeing this is again touching an imported header, we finally need to settle
on where to draw the line. The way this is going is that you're proposing
many small changes which individually all look "small enough". Yet when
doing so for long enough, the entire header may end up different from its
original.

Jan

> --- a/xen/include/efi/efiapi.h
> +++ b/xen/include/efi/efiapi.h
> @@ -63,7 +63,8 @@ EFI_STATUS
>      OUT UINT32                      *DescriptorVersion
>      );
>  
> -#define NextMemoryDescriptor(Ptr,Size)  ((EFI_MEMORY_DESCRIPTOR *) (((UINT8 *) Ptr) + Size))
> +#define NextMemoryDescriptor(Ptr,Size)  ((EFI_MEMORY_DESCRIPTOR *) \
> +                                         ((UINT8 *)(Ptr) + (Size)))
>  
>  
>  typedef



From xen-devel-bounces@lists.xenproject.org Mon Mar 25 09:27:35 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 09:27:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697631.1088575 (Exim 4.92)
	(envelope-from )
	id 1rogcA-0006dy-SG; Mon, 25 Mar 2024 09:27:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697631.1088575; Mon, 25 Mar 2024 09:27:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rogcA-0006dr-Pl; Mon, 25 Mar 2024 09:27:34 +0000
Received: by outflank-mailman (input) for mailman id 697631;
 Mon, 25 Mar 2024 09:27:33 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rogc9-0006di-HG
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 09:27:33 +0000
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com
 [2a00:1450:4864:20::534])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e7b5a8db-ea89-11ee-a1ef-f123f15fe8a2;
 Mon, 25 Mar 2024 10:27:31 +0100 (CET)
Received: by mail-ed1-x534.google.com with SMTP id
 4fb4d7f45d1cf-56829f41f81so5045717a12.2
 for ; Mon, 25 Mar 2024 02:27:31 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 v17-20020aa7d9d1000000b00569aed32c32sm2786770eds.75.2024.03.25.02.27.30
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 25 Mar 2024 02:27:30 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e7b5a8db-ea89-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711358851; x=1711963651; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=Q5v05DNnxs6PLE79qJAwhDX8JtgpYeGz+J8/mIxNXFI=;
        b=MFwjzeAN+pk/aM1kBDBLfRm8VVd9W09IzAlnK6ffmp+Q1R2YEaVxyQsCRgJxXUW8yM
         +Gj7xmML+0MZwg6dHH9izDvaFQyIcXSrs8tBUB5UYt/ICOWBWSRmn+x9pAbuN8kOeztw
         tEDrJ5DKXc7gED+hvvNgPyQIzCB2bu++8dPJm32YBHv6qNm1FvBx69jsLlRIfGTB5lpw
         VH0kjqgqhLjglB6t5yxC1iIHUqlkwwd0eLyqIM7OkN1mwh2Dlrxzg4s5zPGKsrAsNW13
         XXbD5CSvJeTugFMkJm3p4mzAzTCihKJuUN4BWlVTxQJ3cz5PxaSNJr6HO4aDuaJztUAf
         rYfQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711358851; x=1711963651;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=Q5v05DNnxs6PLE79qJAwhDX8JtgpYeGz+J8/mIxNXFI=;
        b=sazFy+TAhExWeB7B6U4OnwlTXQ6IHhKgSFGYql4v537mVD3+/SqJInYILoOBtqYAAA
         kX4y0dkHvsSC3ZHgDU//XK2bYGAKXXqmi+B0dUIaFP+yaLsgEcxHDK68XQ4NmV99HIJh
         fa3w7GfCoFgRFO2h8aBbs2Sgt+dOPVve/T1OVFbZhBg6GH1JMVLVOjWaMzmlu4yDWO5A
         AI+rW9ZDzneCK0B54ZaRQoRpaVBHZOssH+6YbD8aSTw4tDVzVnfjfA2oIedwJZrc+JAg
         0V1p8lZRUrqFCgfk64puZy48vbBe8asTTx+mzhtM35hlZtKlxI41TqO8+hI1N19P5lWr
         L8lg==
X-Forwarded-Encrypted: i=1; AJvYcCWepX8ROZvoQYBpdSU0Ozk8pMSp8JE9XS4sF5QDUzt7SgJKoT6t3uRb4z1D+JDBrXWCEIFQWQ7gtYnL8qB+o32QTmTVxiV0pE+s54pJ08o=
X-Gm-Message-State: AOJu0YxBOKyyoCO+GfZYva9YmG2N74T3T1Br8DWN+7kvEUTeD26iKXxl
	EYkO+cVz7sPe+68Jrw/BTOdxZGJhIu7d0e4FZa46D4saCZKoBB57MsD3Mwf8QQ==
X-Google-Smtp-Source: AGHT+IHvMZtZuTL0Y7mjYyTzcbjiT0EUH8mHymiXHH2eqXMZgcb6Gn2Suh2Wx12+kleHh3Ry1hHpeA==
X-Received: by 2002:a50:c316:0:b0:56b:b0aa:5103 with SMTP id a22-20020a50c316000000b0056bb0aa5103mr3886006edb.5.1711358851093;
        Mon, 25 Mar 2024 02:27:31 -0700 (PDT)
Message-ID: 
Date: Mon, 25 Mar 2024 10:27:30 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 07/11] xen/page_alloc: address violations of MISRA C
 Rule 20.7
Content-Language: en-US
To: Nicola Vetrini 
Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com,
 ayan.kumar.halder@amd.com, consulting@bugseng.com,
 andrew.cooper3@citrix.com, roger.pau@citrix.com, bertrand.marquis@arm.com,
 julien@xen.org, George Dunlap ,
 xen-devel@lists.xenproject.org
References: 
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 22.03.2024 17:01, Nicola Vetrini wrote:
> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -150,7 +150,7 @@
>  #include 
>  #else
>  #define p2m_pod_offline_or_broken_hit(pg) 0

Seeing this in context: Does Misra also have a rule demanding evaluation
of macro arguments?

> -#define p2m_pod_offline_or_broken_replace(pg) BUG_ON(pg != NULL)
> +#define p2m_pod_offline_or_broken_replace(pg) BUG_ON((pg) != NULL)

Or easier

#define p2m_pod_offline_or_broken_replace(pg) BUG_ON(pg)

?

Jan




From xen-devel-bounces@lists.xenproject.org Mon Mar 25 09:38:18 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 09:38:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697644.1088590 (Exim 4.92)
	(envelope-from )
	id 1rogmO-0000YA-U1; Mon, 25 Mar 2024 09:38:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697644.1088590; Mon, 25 Mar 2024 09:38:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rogmO-0000Y3-R9; Mon, 25 Mar 2024 09:38:08 +0000
Received: by outflank-mailman (input) for mailman id 697644;
 Mon, 25 Mar 2024 09:38:07 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rogmN-0000Xd-HO
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 09:38:07 +0000
Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com
 [2a00:1450:4864:20::636])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 61fb70fb-ea8b-11ee-afe3-a90da7624cb6;
 Mon, 25 Mar 2024 10:38:06 +0100 (CET)
Received: by mail-ej1-x636.google.com with SMTP id
 a640c23a62f3a-a468004667aso558711766b.2
 for ; Mon, 25 Mar 2024 02:38:06 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 w17-20020a170906385100b00a46d8e5a031sm2837813ejc.209.2024.03.25.02.38.05
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 25 Mar 2024 02:38:05 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 61fb70fb-ea8b-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711359486; x=1711964286; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=6vwaw3dVIguQ9/7TLOaJw0+8ePZ6Q+QR/NoqSGh05YE=;
        b=beuG3E8Xj1h9DTiLWMCNbHzuZIwdMdJMSuNorhKEUS0QmBOvHK2rhrky4+A5oayilO
         6MUJXTf6eUuYAlyAO/4CAfXW8xLWWGDYOuH2eA21CMxRUJoYI7DbZos7B8LdMZMXDPRg
         /uV3bXrd5KiAQkeaLt7Q1ZZOm9wfPWhT11pzJ69WfMfTrJVTlTF5xfpmLA4iFgS0Lclw
         rrvc/6cNu1AV+HF6qa8dkfnWDejhZbf5M8LFcpe+otQDVvVEwyviL/pMjQEFwU8BXdGK
         c/zSYWx/YlyDLYnaUka9cWG9R7Lidnc5xIdTwkhWTdw9TLfh8bIewHPmdn38oWLXJUFc
         Bupw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711359486; x=1711964286;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=6vwaw3dVIguQ9/7TLOaJw0+8ePZ6Q+QR/NoqSGh05YE=;
        b=Qs+mYrby2k4ARJoUHtG3vI/F7TeJZtp+CY09PAWCC3acvYQ/yE6b2hNtmavX3HKypS
         6YhmRb/V8t7lFZUZ9UstOa0f7k//LVGp4lDIR1Zef3/TYIM2160GjYGKvWPGj8OG5YjC
         77xs038TV/p35YB81ggvgMxR6eZs57PpYS40u02dfWkqQPnNXUyBKvholw38jBYXyCU+
         yusQ39zwR3sXlfo/My4LKAtv8z/hui5j7kmlq40K67WTVPc50i8hU145pTCjCK20RnCZ
         Dun5i4D+NhypmHSxfDtWwiWjxx/QoQ/A0aVAy3IGxvm90PtG8atd5Gr2CJMoLtv2YQ1x
         O7jQ==
X-Forwarded-Encrypted: i=1; AJvYcCUAprec8hwN/QXJBvx5BeGhp0WQc69XikJ42QdarPHQfXeTtQUUHe+B+t7VctE0CykIWTpRC7KmjsZPs/Fi1KRLJk0M1O/cxErAWmDJ5vg=
X-Gm-Message-State: AOJu0YxldAXirn2jYjBgNHK5bQTJDgO4IvDhIWZkJpkQkpmfGkhTNX1R
	xwYDjNvaa+0j4fXR1Yx22nLLa7hGrPzl+GnrifrnOOdECfxDL6W5sY4af4BbwA==
X-Google-Smtp-Source: AGHT+IG1obWENz1W09UCCvPX6NOT9QiiG2Z4mMTw/utSz/9xf9a2VylJp0cIfXGvEbGiMM3L46HfuA==
X-Received: by 2002:a17:906:1401:b0:a46:635b:bb3e with SMTP id p1-20020a170906140100b00a46635bbb3emr3587557ejc.52.1711359485820;
        Mon, 25 Mar 2024 02:38:05 -0700 (PDT)
Message-ID: <072aa89b-2a03-4823-af72-28a2a882b373@suse.com>
Date: Mon, 25 Mar 2024 10:38:04 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 08/11] x86/altcall: address violations of MISRA C Rule
 20.7
Content-Language: en-US
To: Nicola Vetrini 
Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com,
 ayan.kumar.halder@amd.com, consulting@bugseng.com,
 andrew.cooper3@citrix.com, roger.pau@citrix.com, bertrand.marquis@arm.com,
 julien@xen.org, xen-devel@lists.xenproject.org
References: 
 <653ead65966226f50b0e4ae0268912c9710f9dba.1711118582.git.nicola.vetrini@bugseng.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <653ead65966226f50b0e4ae0268912c9710f9dba.1711118582.git.nicola.vetrini@bugseng.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 22.03.2024 17:01, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be safe with respect to expansions that
> can possibly alter the semantics of the passed-in macro parameter.
> 
> No functional change.
> 
> Signed-off-by: Nicola Vetrini 

Hmm. These macros are, at least in part, hard to read already. The added
parentheses, while necessary when following the rule to the letter, are
making things worse, even if just slightly. I therefore have a proposal /
question:

> --- a/xen/arch/x86/include/asm/alternative.h
> +++ b/xen/arch/x86/include/asm/alternative.h
> @@ -243,28 +243,28 @@ extern void alternative_branches(void);
>  
>  #define alternative_vcall0(func) ({             \
>      ALT_CALL_NO_ARG1;                           \
> -    (void)sizeof(func());                       \
> +    (void)sizeof((func)());                     \

Like this, all that's touched here are (syntactical, but not real) function
invocations. Function calls, like all postfix operators, are highest
precedence. Hence by omitting parentheses in that case no breakage can
happen as a result: If the passed expression is another postfix one, that'll
be evaluated first anyway. If any other expression is passed (aside primary
ones, of course), that'll be evaluated afterwards only due to being lower
precedence, irrespective of the presence/absence of parentheses.

Therefore, where harmful to readability, can we perhaps leave postfix
expressions alone?

Jan


From xen-devel-bounces@lists.xenproject.org Mon Mar 25 09:39:12 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 09:39:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697646.1088601 (Exim 4.92)
	(envelope-from )
	id 1rognQ-0001AI-8x; Mon, 25 Mar 2024 09:39:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697646.1088601; Mon, 25 Mar 2024 09:39:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rognQ-0001AB-43; Mon, 25 Mar 2024 09:39:12 +0000
Received: by outflank-mailman (input) for mailman id 697646;
 Mon, 25 Mar 2024 09:39:10 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rognO-000193-Fn
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 09:39:10 +0000
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com
 [2a00:1450:4864:20::62f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 87a3be87-ea8b-11ee-afe3-a90da7624cb6;
 Mon, 25 Mar 2024 10:39:09 +0100 (CET)
Received: by mail-ej1-x62f.google.com with SMTP id
 a640c23a62f3a-a46ea03c2a5so711615366b.1
 for ; Mon, 25 Mar 2024 02:39:09 -0700 (PDT)
Received: from rayden.urgonet (h-217-31-164-171.A175.priv.bahnhof.se.
 [217.31.164.171]) by smtp.gmail.com with ESMTPSA id
 bw26-20020a170906c1da00b00a4650ec48d0sm2891067ejb.140.2024.03.25.02.39.07
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 25 Mar 2024 02:39:08 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 87a3be87-ea8b-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1711359549; x=1711964349; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:from:to:cc:subject:date:message-id:reply-to;
        bh=m57OTQRG0PX7lRQkWmVOqph6CJkRf0tF8xNFRUpeNRA=;
        b=wkHWt12tv0Rel/mdM0vFn03w0ArgxSvswMIdeTzrQUZqM3Q5ajqC++H0f16S/8rxFV
         KTIiltYeea+TMm7/cjKo/c1a8pS9aRLzb3VLTJv+ppzh4XX/Sk3NOQLqXZLYS9N/2jFy
         B2NSvA/Z/z6FmXkNtQrgUv1Evq+kN7yjEHXfoMiaXYaQI0YripSBgFh3oaF57eWSnPdD
         dYir208Oo9Qfal5tH4LxXCaJLnnqTDqZO1dE2RYFDv4LjtQprjjsIhTmb27V38KUxIHz
         yb8kHywClF4ma/feUSiHLHq7Sy+OO6pt/y3wyNferUhSaEkd85zFD4GKY5CHhNqUCQFB
         wDlg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711359549; x=1711964349;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=m57OTQRG0PX7lRQkWmVOqph6CJkRf0tF8xNFRUpeNRA=;
        b=FE9/gZx0/8SP1iBG86LD6zRt+zIvcNMvsAcUIxMuqQLZyzm+YN7eYZZKCmjxnDFv9S
         Q77zD/4ysL7cHzDazgEZk7lNqAiU9Y67raQmNM0NbjT0fYVols7szWI4WUIIcYLeRoEN
         9zRfeDa4uWn73ZypK1m+gHkHEUnGajd3eEWGFBAlfQTh/jr6QBrapKEaOI6fRDmV0X79
         7gLmh1YkjAHqUx3TZ0TSqhMxRA7KjWeJNEUumVeldMbHyWGGVe/+1jcT1RszJy8z3aoi
         i0Unucaq9fb8IzYRS04qjoEBthTiBdpj9nHztC6DTlw1iM9Mbg61AiYXxKuuRiNHA70/
         Jr1w==
X-Gm-Message-State: AOJu0YxVon8cQD8bVVa5zVXkF4X+MJAZI41A2HmDiO6niuM5QBT3+NSJ
	OjP/OjN5JkO/xti5noRXDvamXxkvvAdaz5cnXSQMSI4iZCbQr8bCDDr5/awALZBgIxWHCaYh/Lj
	f
X-Google-Smtp-Source: AGHT+IEjC/ZMHgNDj8fTanPQ+kmtnsMP+XVs9QDvGyc7Lvjva8mwLVFDIayMTvPeqJWU/EL5gxlnDQ==
X-Received: by 2002:a17:906:7817:b0:a47:35df:3d40 with SMTP id u23-20020a170906781700b00a4735df3d40mr5246479ejm.4.1711359548793;
        Mon, 25 Mar 2024 02:39:08 -0700 (PDT)
From: Jens Wiklander 
To: xen-devel@lists.xenproject.org
Cc: patches@linaro.org,
	Jens Wiklander ,
	Volodymyr Babchuk ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel 
Subject: [XEN PATCH 0/6] FF-A mediator reorganisation
Date: Mon, 25 Mar 2024 10:38:58 +0100
Message-Id: <20240325093904.3466092-1-jens.wiklander@linaro.org>
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Hi,

The FF-A mediator is reorganized into modules for easier maintenance and to
prepare for future changes. This patch set is not expected add any changed
behaviour, except for the "xen/arm: ffa: support FFA_FEATURES" patch.

Thanks,
Jens

Jens Wiklander (6):
  xen/arm: ffa: rename functions to use ffa_ prefix
  xen/arm: ffa: move common things to ffa_private.h
  xen/arm: ffa: separate memory sharing routines
  xen/arm: ffa: separate partition info get routines
  xen/arm: ffa: separate rxtx buffer routines
  xen/arm: ffa: support FFA_FEATURES

 xen/arch/arm/tee/Makefile       |    3 +
 xen/arch/arm/tee/ffa.c          | 1629 ++-----------------------------
 xen/arch/arm/tee/ffa_partinfo.c |  373 +++++++
 xen/arch/arm/tee/ffa_private.h  |  347 +++++++
 xen/arch/arm/tee/ffa_rxtx.c     |  216 ++++
 xen/arch/arm/tee/ffa_shm.c      |  708 ++++++++++++++
 6 files changed, 1750 insertions(+), 1526 deletions(-)
 create mode 100644 xen/arch/arm/tee/ffa_partinfo.c
 create mode 100644 xen/arch/arm/tee/ffa_private.h
 create mode 100644 xen/arch/arm/tee/ffa_rxtx.c
 create mode 100644 xen/arch/arm/tee/ffa_shm.c

-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Mon Mar 25 09:39:12 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 09:39:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697647.1088604 (Exim 4.92)
	(envelope-from )
	id 1rognQ-0001Cx-GQ; Mon, 25 Mar 2024 09:39:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697647.1088604; Mon, 25 Mar 2024 09:39:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rognQ-0001C2-B4; Mon, 25 Mar 2024 09:39:12 +0000
Received: by outflank-mailman (input) for mailman id 697647;
 Mon, 25 Mar 2024 09:39:11 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rognP-000193-BF
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 09:39:11 +0000
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com
 [2a00:1450:4864:20::62b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 883ef379-ea8b-11ee-afe3-a90da7624cb6;
 Mon, 25 Mar 2024 10:39:10 +0100 (CET)
Received: by mail-ej1-x62b.google.com with SMTP id
 a640c23a62f3a-a4a39ab1a10so66662966b.1
 for ; Mon, 25 Mar 2024 02:39:10 -0700 (PDT)
Received: from rayden.urgonet (h-217-31-164-171.A175.priv.bahnhof.se.
 [217.31.164.171]) by smtp.gmail.com with ESMTPSA id
 bw26-20020a170906c1da00b00a4650ec48d0sm2891067ejb.140.2024.03.25.02.39.08
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 25 Mar 2024 02:39:09 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 883ef379-ea8b-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1711359550; x=1711964350; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=XIM5k3CjT9Nw1rXmWFG3LUyacrKSLr0M9YlhGWJO8pY=;
        b=XJVMo5SHh75akJAC/nEUOl8MhUoevTSYzAYJv4ueURl6qt7FHPowsmD3Lo07GB4m1C
         S/kyxqVRTb8DVPSbplOSbz+ZiZhHlCtGF91yRYKCRM0oDorM3/RfTYBMxase4mUOEnQD
         GBtrgRKQzCjtn9YdMYaY5WVV66sUWgHjrPASEMRiA+ouDYxRauOAg4+EJ46uWo0/NMnn
         oeBceEyEiS/90x1Rz0R2mHl6rOD0G+BLHXJs3exMGJBU8BIKxHVFLX+Kff058I4TIH/h
         RKsIcxQ0LgBowlxES+LQwz0I2jJLZci3O0Ak/9t9Uw5XZpNheGpJt5/kfHcwQo1KYUQV
         KyHw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711359550; x=1711964350;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=XIM5k3CjT9Nw1rXmWFG3LUyacrKSLr0M9YlhGWJO8pY=;
        b=ry7x2QdZeZlS8hqvcFho3hLSb3f+m3350UVaF0uh+WZ8MtMV5kXF3OTfV6jTsWZKQ3
         poQ5ssfd/AthnuLLnL2YGWwWf5zUWNZQEKPdBG8asIn8IlAmaXmW1kkYOSKL8DrUHuna
         1BSEfgJwy/JlQTyxLZ5D+A0I40JJIE6q1xwCU3kuieLWcDNQx6P9GzWdBDfTSLOvKPdE
         XNhoZvor6rz9JKZ+/gb0EWs4vwnpHsYwZ3hOXTj91NMGEqeAeSyqI5+Odim6cTSHXWTY
         ldJ2suNKJoTX0rcxTWvuLJ8NugGusu9HvH9ZbOD23YekmRtkrVSnO7lYmAYLy+fx6Trw
         rmxQ==
X-Gm-Message-State: AOJu0YzwPIVQExQZU7lt9rKMCtkkQzws/UDFeiwMnmRVTED0kruo6S8w
	3Twc93VtYHJI/6Eb4511wRPThNDP2y0MouQZoRHQfXl2kdp3COa7v5p7Mol4Bobw/A7PK6ik8Tf
	w
X-Google-Smtp-Source: AGHT+IFFM3XCbhGI12K+dE83gxQ3Se0cUgVXLDD58NPg/RxLYIuvc1dMnqatdb6UpHFlryNry75PSQ==
X-Received: by 2002:a17:906:8cb:b0:a47:ae0:160 with SMTP id o11-20020a17090608cb00b00a470ae00160mr4125668eje.73.1711359549783;
        Mon, 25 Mar 2024 02:39:09 -0700 (PDT)
From: Jens Wiklander 
To: xen-devel@lists.xenproject.org
Cc: patches@linaro.org,
	Jens Wiklander ,
	Volodymyr Babchuk ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel 
Subject: [XEN PATCH 1/6] xen/arm: ffa: rename functions to use ffa_ prefix
Date: Mon, 25 Mar 2024 10:38:59 +0100
Message-Id: <20240325093904.3466092-2-jens.wiklander@linaro.org>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20240325093904.3466092-1-jens.wiklander@linaro.org>
References: <20240325093904.3466092-1-jens.wiklander@linaro.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Prepare to separate into modules by renaming functions that will need
new names when becoming non-static in the following commit.

Signed-off-by: Jens Wiklander 
---
 xen/arch/arm/tee/ffa.c | 125 +++++++++++++++++++++--------------------
 1 file changed, 65 insertions(+), 60 deletions(-)

diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
index 9a05dcede17a..0344a0f17e72 100644
--- a/xen/arch/arm/tee/ffa.c
+++ b/xen/arch/arm/tee/ffa.c
@@ -4,7 +4,7 @@
  *
  * Arm Firmware Framework for ARMv8-A (FF-A) mediator
  *
- * Copyright (C) 2023  Linaro Limited
+ * Copyright (C) 2023-2024  Linaro Limited
  *
  * References:
  * FF-A-1.0-REL: FF-A specification version 1.0 available at
@@ -473,7 +473,7 @@ static bool ffa_get_version(uint32_t *vers)
     return true;
 }
 
-static int32_t get_ffa_ret_code(const struct arm_smccc_1_2_regs *resp)
+static int32_t ffa_get_ret_code(const struct arm_smccc_1_2_regs *resp)
 {
     switch ( resp->a0 )
     {
@@ -504,7 +504,7 @@ static int32_t ffa_simple_call(uint32_t fid, register_t a1, register_t a2,
 
     arm_smccc_1_2_smc(&arg, &resp);
 
-    return get_ffa_ret_code(&resp);
+    return ffa_get_ret_code(&resp);
 }
 
 static int32_t ffa_features(uint32_t id)
@@ -546,7 +546,7 @@ static int32_t ffa_partition_info_get(uint32_t w1, uint32_t w2, uint32_t w3,
 
     arm_smccc_1_2_smc(&arg, &resp);
 
-    ret = get_ffa_ret_code(&resp);
+    ret = ffa_get_ret_code(&resp);
     if ( !ret )
     {
         *count = resp.a2;
@@ -654,15 +654,16 @@ static int32_t ffa_direct_req_send_vm(uint16_t sp_id, uint16_t vm_id,
     return res;
 }
 
-static uint16_t get_vm_id(const struct domain *d)
+static uint16_t ffa_get_vm_id(const struct domain *d)
 {
     /* +1 since 0 is reserved for the hypervisor in FF-A */
     return d->domain_id + 1;
 }
 
-static void set_regs(struct cpu_user_regs *regs, register_t v0, register_t v1,
-                     register_t v2, register_t v3, register_t v4, register_t v5,
-                     register_t v6, register_t v7)
+static void ffa_set_regs(struct cpu_user_regs *regs, register_t v0,
+                         register_t v1, register_t v2, register_t v3,
+                         register_t v4, register_t v5, register_t v6,
+                         register_t v7)
 {
         set_user_reg(regs, 0, v0);
         set_user_reg(regs, 1, v1);
@@ -674,15 +675,15 @@ static void set_regs(struct cpu_user_regs *regs, register_t v0, register_t v1,
         set_user_reg(regs, 7, v7);
 }
 
-static void set_regs_error(struct cpu_user_regs *regs, uint32_t error_code)
+static void ffa_set_regs_error(struct cpu_user_regs *regs, uint32_t error_code)
 {
-    set_regs(regs, FFA_ERROR, 0, error_code, 0, 0, 0, 0, 0);
+    ffa_set_regs(regs, FFA_ERROR, 0, error_code, 0, 0, 0, 0, 0);
 }
 
-static void set_regs_success(struct cpu_user_regs *regs, uint32_t w2,
+static void ffa_set_regs_success(struct cpu_user_regs *regs, uint32_t w2,
                              uint32_t w3)
 {
-    set_regs(regs, FFA_SUCCESS_32, 0, w2, w3, 0, 0, 0, 0);
+    ffa_set_regs(regs, FFA_SUCCESS_32, 0, w2, w3, 0, 0, 0, 0);
 }
 
 static void handle_version(struct cpu_user_regs *regs)
@@ -697,11 +698,11 @@ static void handle_version(struct cpu_user_regs *regs)
         vers = FFA_VERSION_1_1;
 
     ctx->guest_vers = vers;
-    set_regs(regs, vers, 0, 0, 0, 0, 0, 0, 0);
+    ffa_set_regs(regs, vers, 0, 0, 0, 0, 0, 0, 0);
 }
 
-static uint32_t handle_rxtx_map(uint32_t fid, register_t tx_addr,
-                                register_t rx_addr, uint32_t page_count)
+static uint32_t ffa_handle_rxtx_map(uint32_t fid, register_t tx_addr,
+				    register_t rx_addr, uint32_t page_count)
 {
     uint32_t ret = FFA_RET_INVALID_PARAMETERS;
     struct domain *d = current->domain;
@@ -789,7 +790,7 @@ static void rxtx_unmap(struct ffa_ctx *ctx)
     ctx->rx_is_free = false;
 }
 
-static uint32_t handle_rxtx_unmap(void)
+static uint32_t ffa_handle_rxtx_unmap(void)
 {
     struct domain *d = current->domain;
     struct ffa_ctx *ctx = d->arch.tee;
@@ -802,9 +803,10 @@ static uint32_t handle_rxtx_unmap(void)
     return FFA_RET_OK;
 }
 
-static int32_t handle_partition_info_get(uint32_t w1, uint32_t w2, uint32_t w3,
-                                         uint32_t w4, uint32_t w5,
-                                         uint32_t *count, uint32_t *fpi_size)
+static int32_t ffa_handle_partition_info_get(uint32_t w1, uint32_t w2,
+                                             uint32_t w3, uint32_t w4,
+                                             uint32_t w5, uint32_t *count,
+                                             uint32_t *fpi_size)
 {
     int32_t ret = FFA_RET_DENIED;
     struct domain *d = current->domain;
@@ -883,7 +885,7 @@ out:
     return ret;
 }
 
-static int32_t handle_rx_release(void)
+static int32_t ffa_handle_rx_release(void)
 {
     int32_t ret = FFA_RET_DENIED;
     struct domain *d = current->domain;
@@ -916,7 +918,7 @@ static void handle_msg_send_direct_req(struct cpu_user_regs *regs, uint32_t fid)
         mask = GENMASK_ULL(31, 0);
 
     src_dst = get_user_reg(regs, 1);
-    if ( (src_dst >> 16) != get_vm_id(d) )
+    if ( (src_dst >> 16) != ffa_get_vm_id(d) )
     {
         resp.a0 = FFA_ERROR;
         resp.a2 = FFA_RET_INVALID_PARAMETERS;
@@ -949,8 +951,9 @@ static void handle_msg_send_direct_req(struct cpu_user_regs *regs, uint32_t fid)
     }
 
 out:
-    set_regs(regs, resp.a0, resp.a1 & mask, resp.a2 & mask, resp.a3 & mask,
-             resp.a4 & mask, resp.a5 & mask, resp.a6 & mask, resp.a7 & mask);
+    ffa_set_regs(regs, resp.a0, resp.a1 & mask, resp.a2 & mask, resp.a3 & mask,
+                 resp.a4 & mask, resp.a5 & mask, resp.a6 & mask,
+                 resp.a7 & mask);
 }
 
 /*
@@ -1249,7 +1252,7 @@ static int read_mem_transaction(uint32_t ffa_vers, const void *buf, size_t blen,
     return 0;
 }
 
-static void handle_mem_share(struct cpu_user_regs *regs)
+static void ffa_handle_mem_share(struct cpu_user_regs *regs)
 {
     uint32_t tot_len = get_user_reg(regs, 1);
     uint32_t frag_len = get_user_reg(regs, 2);
@@ -1318,7 +1321,7 @@ static void handle_mem_share(struct cpu_user_regs *regs)
         goto out_unlock;
     }
 
-    if ( trans.sender_id != get_vm_id(d) )
+    if ( trans.sender_id != ffa_get_vm_id(d) )
     {
         ret = FFA_RET_INVALID_PARAMETERS;
         goto out_unlock;
@@ -1402,9 +1405,9 @@ out_unlock:
 
 out_set_ret:
     if ( ret == 0)
-            set_regs_success(regs, handle_lo, handle_hi);
+            ffa_set_regs_success(regs, handle_lo, handle_hi);
     else
-            set_regs_error(regs, ret);
+            ffa_set_regs_error(regs, ret);
 }
 
 /* Must only be called with ctx->lock held */
@@ -1419,7 +1422,7 @@ static struct ffa_shm_mem *find_shm_mem(struct ffa_ctx *ctx, uint64_t handle)
     return NULL;
 }
 
-static int handle_mem_reclaim(uint64_t handle, uint32_t flags)
+static int ffa_handle_mem_reclaim(uint64_t handle, uint32_t flags)
 {
     struct domain *d = current->domain;
     struct ffa_ctx *ctx = d->arch.tee;
@@ -1471,41 +1474,42 @@ static bool ffa_handle_call(struct cpu_user_regs *regs)
         handle_version(regs);
         return true;
     case FFA_ID_GET:
-        set_regs_success(regs, get_vm_id(d), 0);
+        ffa_set_regs_success(regs, ffa_get_vm_id(d), 0);
         return true;
     case FFA_RXTX_MAP_32:
     case FFA_RXTX_MAP_64:
-        e = handle_rxtx_map(fid, get_user_reg(regs, 1), get_user_reg(regs, 2),
-                            get_user_reg(regs, 3));
+        e = ffa_handle_rxtx_map(fid, get_user_reg(regs, 1),
+				get_user_reg(regs, 2), get_user_reg(regs, 3));
         if ( e )
-            set_regs_error(regs, e);
+            ffa_set_regs_error(regs, e);
         else
-            set_regs_success(regs, 0, 0);
+            ffa_set_regs_success(regs, 0, 0);
         return true;
     case FFA_RXTX_UNMAP:
-        e = handle_rxtx_unmap();
+        e = ffa_handle_rxtx_unmap();
         if ( e )
-            set_regs_error(regs, e);
+            ffa_set_regs_error(regs, e);
         else
-            set_regs_success(regs, 0, 0);
+            ffa_set_regs_success(regs, 0, 0);
         return true;
     case FFA_PARTITION_INFO_GET:
-        e = handle_partition_info_get(get_user_reg(regs, 1),
-                                      get_user_reg(regs, 2),
-                                      get_user_reg(regs, 3),
-                                      get_user_reg(regs, 4),
-                                      get_user_reg(regs, 5), &count, &fpi_size);
+        e = ffa_handle_partition_info_get(get_user_reg(regs, 1),
+                                          get_user_reg(regs, 2),
+                                          get_user_reg(regs, 3),
+                                          get_user_reg(regs, 4),
+                                          get_user_reg(regs, 5), &count,
+                                          &fpi_size);
         if ( e )
-            set_regs_error(regs, e);
+            ffa_set_regs_error(regs, e);
         else
-            set_regs_success(regs, count, fpi_size);
+            ffa_set_regs_success(regs, count, fpi_size);
         return true;
     case FFA_RX_RELEASE:
-        e = handle_rx_release();
+        e = ffa_handle_rx_release();
         if ( e )
-            set_regs_error(regs, e);
+            ffa_set_regs_error(regs, e);
         else
-            set_regs_success(regs, 0, 0);
+            ffa_set_regs_success(regs, 0, 0);
         return true;
     case FFA_MSG_SEND_DIRECT_REQ_32:
     case FFA_MSG_SEND_DIRECT_REQ_64:
@@ -1513,21 +1517,21 @@ static bool ffa_handle_call(struct cpu_user_regs *regs)
         return true;
     case FFA_MEM_SHARE_32:
     case FFA_MEM_SHARE_64:
-        handle_mem_share(regs);
+        ffa_handle_mem_share(regs);
         return true;
     case FFA_MEM_RECLAIM:
-        e = handle_mem_reclaim(regpair_to_uint64(get_user_reg(regs, 2),
-                                                 get_user_reg(regs, 1)),
-                               get_user_reg(regs, 3));
+        e = ffa_handle_mem_reclaim(regpair_to_uint64(get_user_reg(regs, 2),
+                                                     get_user_reg(regs, 1)),
+                                   get_user_reg(regs, 3));
         if ( e )
-            set_regs_error(regs, e);
+            ffa_set_regs_error(regs, e);
         else
-            set_regs_success(regs, 0, 0);
+            ffa_set_regs_success(regs, 0, 0);
         return true;
 
     default:
         gprintk(XENLOG_ERR, "ffa: unhandled fid 0x%x\n", fid);
-        set_regs_error(regs, FFA_RET_NOT_SUPPORTED);
+        ffa_set_regs_error(regs, FFA_RET_NOT_SUPPORTED);
         return true;
     }
 }
@@ -1593,12 +1597,12 @@ static int ffa_domain_init(struct domain *d)
 
     for ( n = 0; n < subscr_vm_created_count; n++ )
     {
-        res = ffa_direct_req_send_vm(subscr_vm_created[n], get_vm_id(d),
+        res = ffa_direct_req_send_vm(subscr_vm_created[n], ffa_get_vm_id(d),
                                      FFA_MSG_SEND_VM_CREATED);
         if ( res )
         {
             printk(XENLOG_ERR "ffa: Failed to report creation of vm_id %u to  %u: res %d\n",
-                   get_vm_id(d), subscr_vm_created[n], res);
+                   ffa_get_vm_id(d), subscr_vm_created[n], res);
             break;
         }
     }
@@ -1620,13 +1624,13 @@ static void send_vm_destroyed(struct domain *d)
         if ( !test_bit(n, ctx->vm_destroy_bitmap) )
             continue;
 
-        res = ffa_direct_req_send_vm(subscr_vm_destroyed[n], get_vm_id(d),
+        res = ffa_direct_req_send_vm(subscr_vm_destroyed[n], ffa_get_vm_id(d),
                                      FFA_MSG_SEND_VM_DESTROYED);
 
         if ( res )
         {
             printk(XENLOG_ERR "%pd: ffa: Failed to report destruction of vm_id %u to %u: res %d\n",
-                   d, get_vm_id(d), subscr_vm_destroyed[n], res);
+                   d, ffa_get_vm_id(d), subscr_vm_destroyed[n], res);
         }
 
         /*
@@ -1640,7 +1644,7 @@ static void send_vm_destroyed(struct domain *d)
     }
 }
 
-static void reclaim_shms(struct domain *d)
+static void ffa_reclaim_shms(struct domain *d)
 {
     struct ffa_ctx *ctx = d->arch.tee;
     struct ffa_shm_mem *shm, *tmp;
@@ -1699,7 +1703,7 @@ static void ffa_domain_teardown_continue(struct ffa_ctx *ctx, bool first_time)
     struct ffa_ctx *next_ctx = NULL;
 
     send_vm_destroyed(ctx->teardown_d);
-    reclaim_shms(ctx->teardown_d);
+    ffa_reclaim_shms(ctx->teardown_d);
 
     if ( ctx->shm_count ||
          !bitmap_empty(ctx->vm_destroy_bitmap, subscr_vm_destroyed_count) )
@@ -1719,7 +1723,8 @@ static void ffa_domain_teardown_continue(struct ffa_ctx *ctx, bool first_time)
     {
         /*
          * domain_destroy() might have been called (via put_domain() in
-         * reclaim_shms()), so we can't touch the domain structure anymore.
+         * ffa_reclaim_shms()), so we can't touch the domain structure
+         * anymore.
          */
         xfree(ctx);
 
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Mon Mar 25 09:39:16 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 09:39:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697648.1088620 (Exim 4.92)
	(envelope-from )
	id 1rognT-0001iQ-Ta; Mon, 25 Mar 2024 09:39:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697648.1088620; Mon, 25 Mar 2024 09:39:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rognT-0001iH-Pn; Mon, 25 Mar 2024 09:39:15 +0000
Received: by outflank-mailman (input) for mailman id 697648;
 Mon, 25 Mar 2024 09:39:14 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rognS-0001fs-N3
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 09:39:14 +0000
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com
 [2a00:1450:4864:20::529])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8925edf5-ea8b-11ee-a1ef-f123f15fe8a2;
 Mon, 25 Mar 2024 10:39:11 +0100 (CET)
Received: by mail-ed1-x529.google.com with SMTP id
 4fb4d7f45d1cf-56845954ffeso5582588a12.2
 for ; Mon, 25 Mar 2024 02:39:11 -0700 (PDT)
Received: from rayden.urgonet (h-217-31-164-171.A175.priv.bahnhof.se.
 [217.31.164.171]) by smtp.gmail.com with ESMTPSA id
 bw26-20020a170906c1da00b00a4650ec48d0sm2891067ejb.140.2024.03.25.02.39.09
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 25 Mar 2024 02:39:10 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8925edf5-ea8b-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1711359551; x=1711964351; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=UtKMkPrD3bbUTAe9JMaiR4498NfrGxZFJfJBgZJEUYQ=;
        b=IGxEWobmXXsZdvIiw0NIf7+pJIJHOGY7/90CM8G29bMe4cI1h1t0bM/SniO+rddRx1
         +sazB+I3t0KdgeqCRVBZ2Zi1n/47pTO/mEhU1937BRLm3ecr644aIVl6Pj+w0PDP750o
         lXBEfye3QuRaAxkSbr6GuVwPa3uauhuDEljy7ZYlA+n7rHwAr9cdjrZDQZZ1d/eVtGIQ
         J3lM2QJkAMQsX9CeiUSdF+dEVqzfW0CTDCp/yn5tTHVXQf5P1pSIoJppHPsBs05/88Uf
         dDZKxKKXhkHKS+hZFq3wapdVIo2NBLACKFsuO9LlcZ+LOSET92bFaT/8XhYACpyQ+z7C
         J1CQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711359551; x=1711964351;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=UtKMkPrD3bbUTAe9JMaiR4498NfrGxZFJfJBgZJEUYQ=;
        b=Hexw0IheVfmFQd/tfm6g2PFb1CuROAt25qKspOVv8kJWOgAwTM6e5iAac29oe3gCyn
         wx9q+20V4hs+s7Pet60p8ohN9Sz3Gc54mb42KXqNLnQAjseNHDh9GNufCKq13Za5lmlT
         YNKFwTm+hXjGTwiKEhfkRbXkBkrl988sb56uh5IyrUPTpW+rO6KJrcHaP+tJMSi4rvI8
         rzUEZmpnq5AfI0URMyAP/iIp3rLb7mF4Dwgp+XYpKGWPwPAIH8gdfqIXeP1lzabzKRzM
         FWd3+4AjTalRjxmpohA3Bjsuo6CgkRKzTLXbuAc5hlPZch72dmube7UVbz1Fns93RrKj
         hDkw==
X-Gm-Message-State: AOJu0YyyAiT1eejzQWYNIQHg+EIgJbaJh8IjzXMAgtUeJDUAR+ydlKUx
	LYB/CmPsasw8LVoALEMiEoXgfBSs1NYg1eOXoegBISVy1H0VzE7RYrIWjSC5/BJm+SwmbJ+xac5
	L
X-Google-Smtp-Source: AGHT+IFEshPJz3eT1WpnGM/g8jA36vOf7jHJ/wJtxEy4DoWw66uuIwvxTVFyr8bGG52dsEvMmzOn+A==
X-Received: by 2002:a17:907:1002:b0:a46:e921:ae3f with SMTP id ox2-20020a170907100200b00a46e921ae3fmr4067032ejb.13.1711359550939;
        Mon, 25 Mar 2024 02:39:10 -0700 (PDT)
From: Jens Wiklander 
To: xen-devel@lists.xenproject.org
Cc: patches@linaro.org,
	Jens Wiklander ,
	Volodymyr Babchuk ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel 
Subject: [XEN PATCH 2/6] xen/arm: ffa: move common things to ffa_private.h
Date: Mon, 25 Mar 2024 10:39:00 +0100
Message-Id: <20240325093904.3466092-3-jens.wiklander@linaro.org>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20240325093904.3466092-1-jens.wiklander@linaro.org>
References: <20240325093904.3466092-1-jens.wiklander@linaro.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Prepare to separate ffa.c into modules by moving common things into the
new internal header file ffa_private.h.

Signed-off-by: Jens Wiklander 
---
 xen/arch/arm/tee/ffa.c         | 298 +-----------------------------
 xen/arch/arm/tee/ffa_private.h | 318 +++++++++++++++++++++++++++++++++
 2 files changed, 319 insertions(+), 297 deletions(-)
 create mode 100644 xen/arch/arm/tee/ffa_private.h

diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
index 0344a0f17e72..259851f20bdb 100644
--- a/xen/arch/arm/tee/ffa.c
+++ b/xen/arch/arm/tee/ffa.c
@@ -63,204 +63,7 @@
 #include 
 #include 
 
-/* Error codes */
-#define FFA_RET_OK                      0
-#define FFA_RET_NOT_SUPPORTED           -1
-#define FFA_RET_INVALID_PARAMETERS      -2
-#define FFA_RET_NO_MEMORY               -3
-#define FFA_RET_BUSY                    -4
-#define FFA_RET_INTERRUPTED             -5
-#define FFA_RET_DENIED                  -6
-#define FFA_RET_RETRY                   -7
-#define FFA_RET_ABORTED                 -8
-
-/* FFA_VERSION helpers */
-#define FFA_VERSION_MAJOR_SHIFT         16U
-#define FFA_VERSION_MAJOR_MASK          0x7FFFU
-#define FFA_VERSION_MINOR_SHIFT         0U
-#define FFA_VERSION_MINOR_MASK          0xFFFFU
-#define MAKE_FFA_VERSION(major, minor)  \
-        ((((major) & FFA_VERSION_MAJOR_MASK) << FFA_VERSION_MAJOR_SHIFT) | \
-         ((minor) & FFA_VERSION_MINOR_MASK))
-
-#define FFA_VERSION_1_0         MAKE_FFA_VERSION(1, 0)
-#define FFA_VERSION_1_1         MAKE_FFA_VERSION(1, 1)
-/* The minimal FF-A version of the SPMC that can be supported */
-#define FFA_MIN_SPMC_VERSION    FFA_VERSION_1_1
-
-/*
- * This is the version we want to use in communication with guests and SPs.
- * During negotiation with a guest or a SP we may need to lower it for
- * that particular guest or SP.
- */
-#define FFA_MY_VERSION_MAJOR    1U
-#define FFA_MY_VERSION_MINOR    1U
-#define FFA_MY_VERSION          MAKE_FFA_VERSION(FFA_MY_VERSION_MAJOR, \
-                                                 FFA_MY_VERSION_MINOR)
-
-/*
- * The FF-A specification explicitly works with 4K pages as a measure of
- * memory size, for example, FFA_RXTX_MAP takes one parameter "RX/TX page
- * count" which is the number of contiguous 4K pages allocated. Xen may use
- * a different page size depending on the configuration to avoid confusion
- * with PAGE_SIZE use a special define when it's a page size as in the FF-A
- * specification.
- */
-#define FFA_PAGE_SIZE                   SZ_4K
-
-/*
- * The number of pages used for each of the RX and TX buffers shared with
- * the SPMC.
- */
-#define FFA_RXTX_PAGE_COUNT             1
-
-/*
- * Limit the number of pages RX/TX buffers guests can map.
- * TODO support a larger number.
- */
-#define FFA_MAX_RXTX_PAGE_COUNT         1
-
-/*
- * Limit for shared buffer size. Please note that this define limits
- * number of pages.
- *
- * FF-A doesn't have any direct requirements on GlobalPlatform or vice
- * versa, but an implementation can very well use FF-A in order to provide
- * a GlobalPlatform interface on top.
- *
- * Global Platform specification for TEE requires that any TEE
- * implementation should allow to share buffers with size of at least
- * 512KB, defined in TEEC-1.0C page 24, Table 4-1,
- * TEEC_CONFIG_SHAREDMEM_MAX_SIZE.
- * Due to overhead which can be hard to predict exactly, double this number
- * to give a safe margin.
- */
-#define FFA_MAX_SHM_PAGE_COUNT          (2 * SZ_512K / FFA_PAGE_SIZE)
-
-/*
- * Limits the number of shared buffers that guest can have at once. This
- * is to prevent case, when guests trick XEN into exhausting its own
- * memory by allocating many small buffers. This value has been chosen
- * arbitrarily.
- */
-#define FFA_MAX_SHM_COUNT               32
-
-/*
- * The time we wait until trying to tear down a domain again if it was
- * blocked initially.
- */
-#define FFA_CTX_TEARDOWN_DELAY          SECONDS(1)
-
-/* FF-A-1.1-REL0 section 10.9.2 Memory region handle, page 167 */
-#define FFA_HANDLE_HYP_FLAG             BIT(63, ULL)
-#define FFA_HANDLE_INVALID              0xffffffffffffffffULL
-
-/*
- * Memory attributes: Normal memory, Write-Back cacheable, Inner shareable
- * Defined in FF-A-1.1-REL0 Table 10.18 at page 175.
- */
-#define FFA_NORMAL_MEM_REG_ATTR         0x2fU
-/*
- * Memory access permissions: Read-write
- * Defined in FF-A-1.1-REL0 Table 10.15 at page 168.
- */
-#define FFA_MEM_ACC_RW                  0x2U
-
-/* FF-A-1.1-REL0 section 10.11.4 Flags usage, page 184-187 */
-/* Clear memory before mapping in receiver */
-#define FFA_MEMORY_REGION_FLAG_CLEAR            BIT(0, U)
-/* Relayer may time slice this operation */
-#define FFA_MEMORY_REGION_FLAG_TIME_SLICE       BIT(1, U)
-/* Clear memory after receiver relinquishes it */
-#define FFA_MEMORY_REGION_FLAG_CLEAR_RELINQUISH BIT(2, U)
-/* Share memory transaction */
-#define FFA_MEMORY_REGION_TRANSACTION_TYPE_SHARE (1U << 3)
-
-/*
- * Flags and field values used for the MSG_SEND_DIRECT_REQ/RESP:
- * BIT(31): Framework or partition message
- * BIT(7-0): Message type for frameworks messages
- */
-#define FFA_MSG_FLAG_FRAMEWORK          BIT(31, U)
-#define FFA_MSG_TYPE_MASK               0xFFU;
-#define FFA_MSG_PSCI                    0x0U
-#define FFA_MSG_SEND_VM_CREATED         0x4U
-#define FFA_MSG_RESP_VM_CREATED         0x5U
-#define FFA_MSG_SEND_VM_DESTROYED       0x6U
-#define FFA_MSG_RESP_VM_DESTROYED       0x7U
-
-/*
- * Flags to determine partition properties in FFA_PARTITION_INFO_GET return
- * message:
- * BIT(0): Supports receipt of direct requests
- * BIT(1): Can send direct requests
- * BIT(2): Can send and receive indirect messages
- * BIT(3): Supports receipt of notifications
- * BIT(4-5): Partition ID is a PE endpoint ID
- * BIT(6): Partition must be informed about each VM that is created by
- *         the Hypervisor
- * BIT(7): Partition must be informed about each VM that is destroyed by
- *         the Hypervisor
- * BIT(8): Partition runs in the AArch64 execution state else AArch32
- *         execution state
- */
-#define FFA_PART_PROP_DIRECT_REQ_RECV   BIT(0, U)
-#define FFA_PART_PROP_DIRECT_REQ_SEND   BIT(1, U)
-#define FFA_PART_PROP_INDIRECT_MSGS     BIT(2, U)
-#define FFA_PART_PROP_RECV_NOTIF        BIT(3, U)
-#define FFA_PART_PROP_IS_TYPE_MASK      (3U << 4)
-#define FFA_PART_PROP_IS_PE_ID          (0U << 4)
-#define FFA_PART_PROP_IS_SEPID_INDEP    (1U << 4)
-#define FFA_PART_PROP_IS_SEPID_DEP      (2U << 4)
-#define FFA_PART_PROP_IS_AUX_ID         (3U << 4)
-#define FFA_PART_PROP_NOTIF_CREATED     BIT(6, U)
-#define FFA_PART_PROP_NOTIF_DESTROYED   BIT(7, U)
-#define FFA_PART_PROP_AARCH64_STATE     BIT(8, U)
-
-/*
- * Flag used as parameter to FFA_PARTITION_INFO_GET to return partition
- * count only.
- */
-#define FFA_PARTITION_INFO_GET_COUNT_FLAG BIT(0, U)
-
-/* Function IDs */
-#define FFA_ERROR                       0x84000060U
-#define FFA_SUCCESS_32                  0x84000061U
-#define FFA_SUCCESS_64                  0xC4000061U
-#define FFA_INTERRUPT                   0x84000062U
-#define FFA_VERSION                     0x84000063U
-#define FFA_FEATURES                    0x84000064U
-#define FFA_RX_ACQUIRE                  0x84000084U
-#define FFA_RX_RELEASE                  0x84000065U
-#define FFA_RXTX_MAP_32                 0x84000066U
-#define FFA_RXTX_MAP_64                 0xC4000066U
-#define FFA_RXTX_UNMAP                  0x84000067U
-#define FFA_PARTITION_INFO_GET          0x84000068U
-#define FFA_ID_GET                      0x84000069U
-#define FFA_SPM_ID_GET                  0x84000085U
-#define FFA_MSG_WAIT                    0x8400006BU
-#define FFA_MSG_YIELD                   0x8400006CU
-#define FFA_RUN                         0x8400006DU
-#define FFA_MSG_SEND2                   0x84000086U
-#define FFA_MSG_SEND_DIRECT_REQ_32      0x8400006FU
-#define FFA_MSG_SEND_DIRECT_REQ_64      0xC400006FU
-#define FFA_MSG_SEND_DIRECT_RESP_32     0x84000070U
-#define FFA_MSG_SEND_DIRECT_RESP_64     0xC4000070U
-#define FFA_MEM_DONATE_32               0x84000071U
-#define FFA_MEM_DONATE_64               0xC4000071U
-#define FFA_MEM_LEND_32                 0x84000072U
-#define FFA_MEM_LEND_64                 0xC4000072U
-#define FFA_MEM_SHARE_32                0x84000073U
-#define FFA_MEM_SHARE_64                0xC4000073U
-#define FFA_MEM_RETRIEVE_REQ_32         0x84000074U
-#define FFA_MEM_RETRIEVE_REQ_64         0xC4000074U
-#define FFA_MEM_RETRIEVE_RESP           0x84000075U
-#define FFA_MEM_RELINQUISH              0x84000076U
-#define FFA_MEM_RECLAIM                 0x84000077U
-#define FFA_MEM_FRAG_RX                 0x8400007AU
-#define FFA_MEM_FRAG_TX                 0x8400007BU
-#define FFA_MSG_SEND                    0x8400006EU
-#define FFA_MSG_POLL                    0x8400006AU
+#include "ffa_private.h"
 
 /*
  * Structs below ending with _1_0 are defined in FF-A-1.0-REL and
@@ -382,39 +185,6 @@ struct ffa_endpoint_rxtx_descriptor_1_1 {
     uint32_t tx_region_offs;
 };
 
-struct ffa_ctx {
-    void *rx;
-    const void *tx;
-    struct page_info *rx_pg;
-    struct page_info *tx_pg;
-    /* Number of 4kB pages in each of rx/rx_pg and tx/tx_pg */
-    unsigned int page_count;
-    /* FF-A version used by the guest */
-    uint32_t guest_vers;
-    bool rx_is_free;
-    /* Used shared memory objects, struct ffa_shm_mem */
-    struct list_head shm_list;
-    /* Number of allocated shared memory object */
-    unsigned int shm_count;
-    /*
-     * tx_lock is used to serialize access to tx
-     * rx_lock is used to serialize access to rx
-     * lock is used for the rest in this struct
-     */
-    spinlock_t tx_lock;
-    spinlock_t rx_lock;
-    spinlock_t lock;
-    /* Used if domain can't be torn down immediately */
-    struct domain *teardown_d;
-    struct list_head teardown_list;
-    s_time_t teardown_expire;
-    /*
-     * Used for ffa_domain_teardown() to keep track of which SPs should be
-     * notified that this guest is being destroyed.
-     */
-    unsigned long vm_destroy_bitmap[];
-};
-
 struct ffa_shm_mem {
     struct list_head list;
     uint16_t sender_id;
@@ -473,40 +243,6 @@ static bool ffa_get_version(uint32_t *vers)
     return true;
 }
 
-static int32_t ffa_get_ret_code(const struct arm_smccc_1_2_regs *resp)
-{
-    switch ( resp->a0 )
-    {
-    case FFA_ERROR:
-        if ( resp->a2 )
-            return resp->a2;
-        else
-            return FFA_RET_NOT_SUPPORTED;
-    case FFA_SUCCESS_32:
-    case FFA_SUCCESS_64:
-        return FFA_RET_OK;
-    default:
-        return FFA_RET_NOT_SUPPORTED;
-    }
-}
-
-static int32_t ffa_simple_call(uint32_t fid, register_t a1, register_t a2,
-                               register_t a3, register_t a4)
-{
-    const struct arm_smccc_1_2_regs arg = {
-        .a0 = fid,
-        .a1 = a1,
-        .a2 = a2,
-        .a3 = a3,
-        .a4 = a4,
-    };
-    struct arm_smccc_1_2_regs resp;
-
-    arm_smccc_1_2_smc(&arg, &resp);
-
-    return ffa_get_ret_code(&resp);
-}
-
 static int32_t ffa_features(uint32_t id)
 {
     return ffa_simple_call(FFA_FEATURES, id, 0, 0, 0);
@@ -654,38 +390,6 @@ static int32_t ffa_direct_req_send_vm(uint16_t sp_id, uint16_t vm_id,
     return res;
 }
 
-static uint16_t ffa_get_vm_id(const struct domain *d)
-{
-    /* +1 since 0 is reserved for the hypervisor in FF-A */
-    return d->domain_id + 1;
-}
-
-static void ffa_set_regs(struct cpu_user_regs *regs, register_t v0,
-                         register_t v1, register_t v2, register_t v3,
-                         register_t v4, register_t v5, register_t v6,
-                         register_t v7)
-{
-        set_user_reg(regs, 0, v0);
-        set_user_reg(regs, 1, v1);
-        set_user_reg(regs, 2, v2);
-        set_user_reg(regs, 3, v3);
-        set_user_reg(regs, 4, v4);
-        set_user_reg(regs, 5, v5);
-        set_user_reg(regs, 6, v6);
-        set_user_reg(regs, 7, v7);
-}
-
-static void ffa_set_regs_error(struct cpu_user_regs *regs, uint32_t error_code)
-{
-    ffa_set_regs(regs, FFA_ERROR, 0, error_code, 0, 0, 0, 0, 0);
-}
-
-static void ffa_set_regs_success(struct cpu_user_regs *regs, uint32_t w2,
-                             uint32_t w3)
-{
-    ffa_set_regs(regs, FFA_SUCCESS_32, 0, w2, w3, 0, 0, 0, 0);
-}
-
 static void handle_version(struct cpu_user_regs *regs)
 {
     struct domain *d = current->domain;
diff --git a/xen/arch/arm/tee/ffa_private.h b/xen/arch/arm/tee/ffa_private.h
new file mode 100644
index 000000000000..8352b6b55a9a
--- /dev/null
+++ b/xen/arch/arm/tee/ffa_private.h
@@ -0,0 +1,318 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2023  Linaro Limited
+ */
+
+#ifndef __FFA_PRIVATE_H__
+#define __FFA_PRIVATE_H__
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Error codes */
+#define FFA_RET_OK                      0
+#define FFA_RET_NOT_SUPPORTED           -1
+#define FFA_RET_INVALID_PARAMETERS      -2
+#define FFA_RET_NO_MEMORY               -3
+#define FFA_RET_BUSY                    -4
+#define FFA_RET_INTERRUPTED             -5
+#define FFA_RET_DENIED                  -6
+#define FFA_RET_RETRY                   -7
+#define FFA_RET_ABORTED                 -8
+
+/* FFA_VERSION helpers */
+#define FFA_VERSION_MAJOR_SHIFT         16U
+#define FFA_VERSION_MAJOR_MASK          0x7FFFU
+#define FFA_VERSION_MINOR_SHIFT         0U
+#define FFA_VERSION_MINOR_MASK          0xFFFFU
+#define MAKE_FFA_VERSION(major, minor)  \
+        ((((major) & FFA_VERSION_MAJOR_MASK) << FFA_VERSION_MAJOR_SHIFT) | \
+         ((minor) & FFA_VERSION_MINOR_MASK))
+
+#define FFA_VERSION_1_0         MAKE_FFA_VERSION(1, 0)
+#define FFA_VERSION_1_1         MAKE_FFA_VERSION(1, 1)
+/* The minimal FF-A version of the SPMC that can be supported */
+#define FFA_MIN_SPMC_VERSION    FFA_VERSION_1_1
+
+/*
+ * This is the version we want to use in communication with guests and SPs.
+ * During negotiation with a guest or a SP we may need to lower it for
+ * that particular guest or SP.
+ */
+#define FFA_MY_VERSION_MAJOR    1U
+#define FFA_MY_VERSION_MINOR    1U
+#define FFA_MY_VERSION          MAKE_FFA_VERSION(FFA_MY_VERSION_MAJOR, \
+                                                 FFA_MY_VERSION_MINOR)
+
+/*
+ * The FF-A specification explicitly works with 4K pages as a measure of
+ * memory size, for example, FFA_RXTX_MAP takes one parameter "RX/TX page
+ * count" which is the number of contiguous 4K pages allocated. Xen may use
+ * a different page size depending on the configuration to avoid confusion
+ * with PAGE_SIZE use a special define when it's a page size as in the FF-A
+ * specification.
+ */
+#define FFA_PAGE_SIZE                   SZ_4K
+
+/*
+ * The number of pages used for each of the RX and TX buffers shared with
+ * the SPMC.
+ */
+#define FFA_RXTX_PAGE_COUNT             1
+
+/*
+ * Limit the number of pages RX/TX buffers guests can map.
+ * TODO support a larger number.
+ */
+#define FFA_MAX_RXTX_PAGE_COUNT         1
+
+/*
+ * Limit for shared buffer size. Please note that this define limits
+ * number of pages.
+ *
+ * FF-A doesn't have any direct requirements on GlobalPlatform or vice
+ * versa, but an implementation can very well use FF-A in order to provide
+ * a GlobalPlatform interface on top.
+ *
+ * Global Platform specification for TEE requires that any TEE
+ * implementation should allow to share buffers with size of at least
+ * 512KB, defined in TEEC-1.0C page 24, Table 4-1,
+ * TEEC_CONFIG_SHAREDMEM_MAX_SIZE.
+ * Due to overhead which can be hard to predict exactly, double this number
+ * to give a safe margin.
+ */
+#define FFA_MAX_SHM_PAGE_COUNT          (2 * SZ_512K / FFA_PAGE_SIZE)
+
+/*
+ * Limits the number of shared buffers that guest can have at once. This
+ * is to prevent case, when guests trick XEN into exhausting its own
+ * memory by allocating many small buffers. This value has been chosen
+ * arbitrarily.
+ */
+#define FFA_MAX_SHM_COUNT               32
+
+/*
+ * The time we wait until trying to tear down a domain again if it was
+ * blocked initially.
+ */
+#define FFA_CTX_TEARDOWN_DELAY          SECONDS(1)
+
+/* FF-A-1.1-REL0 section 10.9.2 Memory region handle, page 167 */
+#define FFA_HANDLE_HYP_FLAG             BIT(63, ULL)
+#define FFA_HANDLE_INVALID              0xffffffffffffffffULL
+
+/*
+ * Memory attributes: Normal memory, Write-Back cacheable, Inner shareable
+ * Defined in FF-A-1.1-REL0 Table 10.18 at page 175.
+ */
+#define FFA_NORMAL_MEM_REG_ATTR         0x2fU
+/*
+ * Memory access permissions: Read-write
+ * Defined in FF-A-1.1-REL0 Table 10.15 at page 168.
+ */
+#define FFA_MEM_ACC_RW                  0x2U
+
+/* FF-A-1.1-REL0 section 10.11.4 Flags usage, page 184-187 */
+/* Clear memory before mapping in receiver */
+#define FFA_MEMORY_REGION_FLAG_CLEAR            BIT(0, U)
+/* Relayer may time slice this operation */
+#define FFA_MEMORY_REGION_FLAG_TIME_SLICE       BIT(1, U)
+/* Clear memory after receiver relinquishes it */
+#define FFA_MEMORY_REGION_FLAG_CLEAR_RELINQUISH BIT(2, U)
+/* Share memory transaction */
+#define FFA_MEMORY_REGION_TRANSACTION_TYPE_SHARE (1U << 3)
+
+/*
+ * Flags and field values used for the MSG_SEND_DIRECT_REQ/RESP:
+ * BIT(31): Framework or partition message
+ * BIT(7-0): Message type for frameworks messages
+ */
+#define FFA_MSG_FLAG_FRAMEWORK          BIT(31, U)
+#define FFA_MSG_TYPE_MASK               0xFFU;
+#define FFA_MSG_PSCI                    0x0U
+#define FFA_MSG_SEND_VM_CREATED         0x4U
+#define FFA_MSG_RESP_VM_CREATED         0x5U
+#define FFA_MSG_SEND_VM_DESTROYED       0x6U
+#define FFA_MSG_RESP_VM_DESTROYED       0x7U
+
+/*
+ * Flags to determine partition properties in FFA_PARTITION_INFO_GET return
+ * message:
+ * BIT(0): Supports receipt of direct requests
+ * BIT(1): Can send direct requests
+ * BIT(2): Can send and receive indirect messages
+ * BIT(3): Supports receipt of notifications
+ * BIT(4-5): Partition ID is a PE endpoint ID
+ * BIT(6): Partition must be informed about each VM that is created by
+ *         the Hypervisor
+ * BIT(7): Partition must be informed about each VM that is destroyed by
+ *         the Hypervisor
+ * BIT(8): Partition runs in the AArch64 execution state else AArch32
+ *         execution state
+ */
+#define FFA_PART_PROP_DIRECT_REQ_RECV   BIT(0, U)
+#define FFA_PART_PROP_DIRECT_REQ_SEND   BIT(1, U)
+#define FFA_PART_PROP_INDIRECT_MSGS     BIT(2, U)
+#define FFA_PART_PROP_RECV_NOTIF        BIT(3, U)
+#define FFA_PART_PROP_IS_TYPE_MASK      (3U << 4)
+#define FFA_PART_PROP_IS_PE_ID          (0U << 4)
+#define FFA_PART_PROP_IS_SEPID_INDEP    (1U << 4)
+#define FFA_PART_PROP_IS_SEPID_DEP      (2U << 4)
+#define FFA_PART_PROP_IS_AUX_ID         (3U << 4)
+#define FFA_PART_PROP_NOTIF_CREATED     BIT(6, U)
+#define FFA_PART_PROP_NOTIF_DESTROYED   BIT(7, U)
+#define FFA_PART_PROP_AARCH64_STATE     BIT(8, U)
+
+/*
+ * Flag used as parameter to FFA_PARTITION_INFO_GET to return partition
+ * count only.
+ */
+#define FFA_PARTITION_INFO_GET_COUNT_FLAG BIT(0, U)
+
+/* Function IDs */
+#define FFA_ERROR                       0x84000060U
+#define FFA_SUCCESS_32                  0x84000061U
+#define FFA_SUCCESS_64                  0xC4000061U
+#define FFA_INTERRUPT                   0x84000062U
+#define FFA_VERSION                     0x84000063U
+#define FFA_FEATURES                    0x84000064U
+#define FFA_RX_ACQUIRE                  0x84000084U
+#define FFA_RX_RELEASE                  0x84000065U
+#define FFA_RXTX_MAP_32                 0x84000066U
+#define FFA_RXTX_MAP_64                 0xC4000066U
+#define FFA_RXTX_UNMAP                  0x84000067U
+#define FFA_PARTITION_INFO_GET          0x84000068U
+#define FFA_ID_GET                      0x84000069U
+#define FFA_SPM_ID_GET                  0x84000085U
+#define FFA_MSG_WAIT                    0x8400006BU
+#define FFA_MSG_YIELD                   0x8400006CU
+#define FFA_RUN                         0x8400006DU
+#define FFA_MSG_SEND2                   0x84000086U
+#define FFA_MSG_SEND_DIRECT_REQ_32      0x8400006FU
+#define FFA_MSG_SEND_DIRECT_REQ_64      0xC400006FU
+#define FFA_MSG_SEND_DIRECT_RESP_32     0x84000070U
+#define FFA_MSG_SEND_DIRECT_RESP_64     0xC4000070U
+#define FFA_MEM_DONATE_32               0x84000071U
+#define FFA_MEM_DONATE_64               0xC4000071U
+#define FFA_MEM_LEND_32                 0x84000072U
+#define FFA_MEM_LEND_64                 0xC4000072U
+#define FFA_MEM_SHARE_32                0x84000073U
+#define FFA_MEM_SHARE_64                0xC4000073U
+#define FFA_MEM_RETRIEVE_REQ_32         0x84000074U
+#define FFA_MEM_RETRIEVE_REQ_64         0xC4000074U
+#define FFA_MEM_RETRIEVE_RESP           0x84000075U
+#define FFA_MEM_RELINQUISH              0x84000076U
+#define FFA_MEM_RECLAIM                 0x84000077U
+#define FFA_MEM_FRAG_RX                 0x8400007AU
+#define FFA_MEM_FRAG_TX                 0x8400007BU
+#define FFA_MSG_SEND                    0x8400006EU
+#define FFA_MSG_POLL                    0x8400006AU
+
+struct ffa_ctx {
+    void *rx;
+    const void *tx;
+    struct page_info *rx_pg;
+    struct page_info *tx_pg;
+    /* Number of 4kB pages in each of rx/rx_pg and tx/tx_pg */
+    unsigned int page_count;
+    /* FF-A version used by the guest */
+    uint32_t guest_vers;
+    bool rx_is_free;
+    /* Used shared memory objects, struct ffa_shm_mem */
+    struct list_head shm_list;
+    /* Number of allocated shared memory object */
+    unsigned int shm_count;
+    /*
+     * tx_lock is used to serialize access to tx
+     * rx_lock is used to serialize access to rx
+     * lock is used for the rest in this struct
+     */
+    spinlock_t tx_lock;
+    spinlock_t rx_lock;
+    spinlock_t lock;
+    /* Used if domain can't be torn down immediately */
+    struct domain *teardown_d;
+    struct list_head teardown_list;
+    s_time_t teardown_expire;
+    /*
+     * Used for ffa_domain_teardown() to keep track of which SPs should be
+     * notified that this guest is being destroyed.
+     */
+    unsigned long vm_destroy_bitmap[];
+};
+
+static inline uint16_t ffa_get_vm_id(const struct domain *d)
+{
+    /* +1 since 0 is reserved for the hypervisor in FF-A */
+    return d->domain_id + 1;
+}
+
+static inline void ffa_set_regs(struct cpu_user_regs *regs, register_t v0,
+                                register_t v1, register_t v2, register_t v3,
+                                register_t v4, register_t v5, register_t v6,
+                                register_t v7)
+{
+        set_user_reg(regs, 0, v0);
+        set_user_reg(regs, 1, v1);
+        set_user_reg(regs, 2, v2);
+        set_user_reg(regs, 3, v3);
+        set_user_reg(regs, 4, v4);
+        set_user_reg(regs, 5, v5);
+        set_user_reg(regs, 6, v6);
+        set_user_reg(regs, 7, v7);
+}
+
+static inline void ffa_set_regs_error(struct cpu_user_regs *regs,
+                                      uint32_t error_code)
+{
+    ffa_set_regs(regs, FFA_ERROR, 0, error_code, 0, 0, 0, 0, 0);
+}
+
+static inline void ffa_set_regs_success(struct cpu_user_regs *regs,
+                                        uint32_t w2, uint32_t w3)
+{
+    ffa_set_regs(regs, FFA_SUCCESS_32, 0, w2, w3, 0, 0, 0, 0);
+}
+
+static inline int32_t ffa_get_ret_code(const struct arm_smccc_1_2_regs *resp)
+{
+    switch ( resp->a0 )
+    {
+    case FFA_ERROR:
+        if ( resp->a2 )
+            return resp->a2;
+        else
+            return FFA_RET_NOT_SUPPORTED;
+    case FFA_SUCCESS_32:
+    case FFA_SUCCESS_64:
+        return FFA_RET_OK;
+    default:
+        return FFA_RET_NOT_SUPPORTED;
+    }
+}
+
+static inline int32_t ffa_simple_call(uint32_t fid, register_t a1,
+                                      register_t a2, register_t a3,
+                                      register_t a4)
+{
+    const struct arm_smccc_1_2_regs arg = {
+        .a0 = fid,
+        .a1 = a1,
+        .a2 = a2,
+        .a3 = a3,
+        .a4 = a4,
+    };
+    struct arm_smccc_1_2_regs resp;
+
+    arm_smccc_1_2_smc(&arg, &resp);
+
+    return ffa_get_ret_code(&resp);
+}
+
+#endif /*__FFA_PRIVATE_H__*/
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Mon Mar 25 09:39:18 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 09:39:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697649.1088630 (Exim 4.92)
	(envelope-from )
	id 1rognW-0001zV-61; Mon, 25 Mar 2024 09:39:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697649.1088630; Mon, 25 Mar 2024 09:39:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rognW-0001zO-1o; Mon, 25 Mar 2024 09:39:18 +0000
Received: by outflank-mailman (input) for mailman id 697649;
 Mon, 25 Mar 2024 09:39:16 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rognT-0001fs-V0
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 09:39:16 +0000
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com
 [2a00:1450:4864:20::631])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 89e588ca-ea8b-11ee-a1ef-f123f15fe8a2;
 Mon, 25 Mar 2024 10:39:13 +0100 (CET)
Received: by mail-ej1-x631.google.com with SMTP id
 a640c23a62f3a-a450bedffdfso470714866b.3
 for ; Mon, 25 Mar 2024 02:39:13 -0700 (PDT)
Received: from rayden.urgonet (h-217-31-164-171.A175.priv.bahnhof.se.
 [217.31.164.171]) by smtp.gmail.com with ESMTPSA id
 bw26-20020a170906c1da00b00a4650ec48d0sm2891067ejb.140.2024.03.25.02.39.11
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 25 Mar 2024 02:39:11 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 89e588ca-ea8b-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1711359552; x=1711964352; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=nzCul7k3D57gESYQgpCIbwin6Did4XgqdPdjpsHyeJY=;
        b=jsTJJ+Y9EZcIRQSfs7MItETalSyv9nHKTkRJFwPGHkN3Bs4V80gXOXGWPngWLMx1SK
         eKfiRwd7re5ldEOkwlfDiYR5haw9ItdIX7pp0bU6dCfH+8RtVvk2jpblVf8TYIbU6PnM
         L2rrw2jik6uFd1T/3+Ztj1xf4R6VSuBv6KBw3MEezt+jqx9UiLc+SWnotGH2NJadOf91
         XNcBZLK7Extxiu2lslizum9BSkN7vwjmis77dejr/ujAWA8EOB/vOz9NH592qEifLwK1
         95E6Pp47W0y2o8Cn3gkwAHcpEnNPMh0DRXQsjTdZ0Pnr5pBNe8hYRy0F6yGhUPljTPgI
         h1Tw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711359552; x=1711964352;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=nzCul7k3D57gESYQgpCIbwin6Did4XgqdPdjpsHyeJY=;
        b=a3OFVT6sXQS/9AASEsHfSkLHoUvPLjO20HYi2Cb+1VIaPw4uE0pWAEnqHRygR3tfg8
         ptvBJGO7ErMuvKjlO0F+afIx5UDjWVS9094eA8Zucj8ih4d5pvAc0YeZrwNAFPcdhTqg
         Phxun3JBBUgjjqrB4Vxg8mtfKAJnWKJsjDF5YbhphkjvTF5Qsi9dxOayzqndE2qEopKp
         R28J2nBs9g1dTzJ/Ufvl1veG53lW9KeByS2EMVcS6UYj34wZimlXkxSSa9bk8HaIQnwG
         gL/i59NHqHFsQDdITVfMH2ema0kmv3tch/4JKfJIUISbEzl03uHLpFnFMEy1HHvYLz23
         0kQQ==
X-Gm-Message-State: AOJu0YwBG/AdC63u126lQPnUS8GfXf7BDbRRbkPUV5WX0mzWAVM4TJtS
	IiVLH8RwWDskADrf5Z7ZBIGiZYEimn9HaZGw7+BP3g/Oi2hxLXo/sDAYejKtFL58foGnr+S+Gpg
	f
X-Google-Smtp-Source: AGHT+IFacWpCJpsBCJwjyNcQco8asQriniIkagrQoRxZOBm+9AFJe+nscUTWYVBfBVetS6bcbOEBpg==
X-Received: by 2002:a17:907:7214:b0:a47:50c5:15b2 with SMTP id dr20-20020a170907721400b00a4750c515b2mr2799238ejc.6.1711359552067;
        Mon, 25 Mar 2024 02:39:12 -0700 (PDT)
From: Jens Wiklander 
To: xen-devel@lists.xenproject.org
Cc: patches@linaro.org,
	Jens Wiklander ,
	Volodymyr Babchuk ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel 
Subject: [XEN PATCH 3/6] xen/arm: ffa: separate memory sharing routines
Date: Mon, 25 Mar 2024 10:39:01 +0100
Message-Id: <20240325093904.3466092-4-jens.wiklander@linaro.org>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20240325093904.3466092-1-jens.wiklander@linaro.org>
References: <20240325093904.3466092-1-jens.wiklander@linaro.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Move memory sharing routines into a separate file for easier navigation
in the source code.

Add ffa_shm_domain_destroy() to isolate the ffa_shm things in
ffa_domain_teardown_continue().

Signed-off-by: Jens Wiklander 
---
 xen/arch/arm/tee/Makefile      |   1 +
 xen/arch/arm/tee/ffa.c         | 708 +--------------------------------
 xen/arch/arm/tee/ffa_private.h |  10 +
 xen/arch/arm/tee/ffa_shm.c     | 708 +++++++++++++++++++++++++++++++++
 4 files changed, 729 insertions(+), 698 deletions(-)
 create mode 100644 xen/arch/arm/tee/ffa_shm.c

diff --git a/xen/arch/arm/tee/Makefile b/xen/arch/arm/tee/Makefile
index 58a1015e40e0..0e683d23aa9d 100644
--- a/xen/arch/arm/tee/Makefile
+++ b/xen/arch/arm/tee/Makefile
@@ -1,3 +1,4 @@
 obj-$(CONFIG_FFA) += ffa.o
+obj-$(CONFIG_FFA) += ffa_shm.o
 obj-y += tee.o
 obj-$(CONFIG_OPTEE) += optee.o
diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
index 259851f20bdb..db36292dc52f 100644
--- a/xen/arch/arm/tee/ffa.c
+++ b/xen/arch/arm/tee/ffa.c
@@ -84,92 +84,6 @@ struct ffa_partition_info_1_1 {
     uint8_t uuid[16];
 };
 
-/* Constituent memory region descriptor */
-struct ffa_address_range {
-    uint64_t address;
-    uint32_t page_count;
-    uint32_t reserved;
-};
-
-/* Composite memory region descriptor */
-struct ffa_mem_region {
-    uint32_t total_page_count;
-    uint32_t address_range_count;
-    uint64_t reserved;
-    struct ffa_address_range address_range_array[];
-};
-
-/* Memory access permissions descriptor */
-struct ffa_mem_access_perm {
-    uint16_t endpoint_id;
-    uint8_t perm;
-    uint8_t flags;
-};
-
-/* Endpoint memory access descriptor */
-struct ffa_mem_access {
-    struct ffa_mem_access_perm access_perm;
-    uint32_t region_offs;
-    uint64_t reserved;
-};
-
-/* Lend, donate or share memory transaction descriptor */
-struct ffa_mem_transaction_1_0 {
-    uint16_t sender_id;
-    uint8_t mem_reg_attr;
-    uint8_t reserved0;
-    uint32_t flags;
-    uint64_t handle;
-    uint64_t tag;
-    uint32_t reserved1;
-    uint32_t mem_access_count;
-    struct ffa_mem_access mem_access_array[];
-};
-
-struct ffa_mem_transaction_1_1 {
-    uint16_t sender_id;
-    uint16_t mem_reg_attr;
-    uint32_t flags;
-    uint64_t handle;
-    uint64_t tag;
-    uint32_t mem_access_size;
-    uint32_t mem_access_count;
-    uint32_t mem_access_offs;
-    uint8_t reserved[12];
-};
-
-/* Calculate offset of struct ffa_mem_access from start of buffer */
-#define MEM_ACCESS_OFFSET(access_idx) \
-    ( sizeof(struct ffa_mem_transaction_1_1) + \
-      ( access_idx ) * sizeof(struct ffa_mem_access) )
-
-/* Calculate offset of struct ffa_mem_region from start of buffer */
-#define REGION_OFFSET(access_count, region_idx) \
-    ( MEM_ACCESS_OFFSET(access_count) + \
-      ( region_idx ) * sizeof(struct ffa_mem_region) )
-
-/* Calculate offset of struct ffa_address_range from start of buffer */
-#define ADDR_RANGE_OFFSET(access_count, region_count, range_idx) \
-    ( REGION_OFFSET(access_count, region_count) + \
-      ( range_idx ) * sizeof(struct ffa_address_range) )
-
-/*
- * The parts needed from struct ffa_mem_transaction_1_0 or struct
- * ffa_mem_transaction_1_1, used to provide an abstraction of difference in
- * data structures between version 1.0 and 1.1. This is just an internal
- * interface and can be changed without changing any ABI.
- */
-struct ffa_mem_transaction_int {
-    uint16_t sender_id;
-    uint8_t mem_reg_attr;
-    uint8_t flags;
-    uint8_t mem_access_size;
-    uint8_t mem_access_count;
-    uint16_t mem_access_offs;
-    uint64_t handle;
-    uint64_t tag;
-};
-
 /* Endpoint RX/TX descriptor */
 struct ffa_endpoint_rxtx_descriptor_1_0 {
     uint16_t sender_id;
@@ -185,15 +99,6 @@ struct ffa_endpoint_rxtx_descriptor_1_1 {
     uint32_t tx_region_offs;
 };
 
-struct ffa_shm_mem {
-    struct list_head list;
-    uint16_t sender_id;
-    uint16_t ep_id;     /* endpoint, the one lending */
-    uint64_t handle;    /* FFA_HANDLE_INVALID if not set yet */
-    unsigned int page_count;
-    struct page_info *pages[];
-};
-
 /* Negotiated FF-A version to use with the SPMC */
 static uint32_t __ro_after_init ffa_version;
 
@@ -212,10 +117,10 @@ static uint16_t subscr_vm_destroyed_count __read_mostly;
  * for calls which uses our RX buffer to deliver a result we must call
  * ffa_rx_release() to let the SPMC know that we're done with the buffer.
  */
-static void *ffa_rx __read_mostly;
-static void *ffa_tx __read_mostly;
-static DEFINE_SPINLOCK(ffa_rx_buffer_lock);
-static DEFINE_SPINLOCK(ffa_tx_buffer_lock);
+void *ffa_rx __read_mostly;
+void *ffa_tx __read_mostly;
+DEFINE_SPINLOCK(ffa_rx_buffer_lock);
+DEFINE_SPINLOCK(ffa_tx_buffer_lock);
 
 
 /* Used to track domains that could not be torn down immediately. */
@@ -297,47 +202,6 @@ static int32_t ffa_rx_release(void)
     return ffa_simple_call(FFA_RX_RELEASE, 0, 0, 0, 0);
 }
 
-static int32_t ffa_mem_share(uint32_t tot_len, uint32_t frag_len,
-                             register_t addr, uint32_t pg_count,
-                             uint64_t *handle)
-{
-    struct arm_smccc_1_2_regs arg = {
-        .a0 = FFA_MEM_SHARE_64,
-        .a1 = tot_len,
-        .a2 = frag_len,
-        .a3 = addr,
-        .a4 = pg_count,
-    };
-    struct arm_smccc_1_2_regs resp;
-
-    arm_smccc_1_2_smc(&arg, &resp);
-
-    switch ( resp.a0 )
-    {
-    case FFA_ERROR:
-        if ( resp.a2 )
-            return resp.a2;
-        else
-            return FFA_RET_NOT_SUPPORTED;
-    case FFA_SUCCESS_32:
-        *handle = regpair_to_uint64(resp.a3, resp.a2);
-        return FFA_RET_OK;
-    case FFA_MEM_FRAG_RX:
-        *handle = regpair_to_uint64(resp.a2, resp.a1);
-        if ( resp.a3 > INT32_MAX ) /* Impossible value */
-            return FFA_RET_ABORTED;
-        return resp.a3 & INT32_MAX;
-    default:
-        return FFA_RET_NOT_SUPPORTED;
-    }
-}
-
-static int32_t ffa_mem_reclaim(uint32_t handle_lo, uint32_t handle_hi,
-                               uint32_t flags)
-{
-    return ffa_simple_call(FFA_MEM_RECLAIM, handle_lo, handle_hi, flags, 0);
-}
-
 static int32_t ffa_direct_req_send_vm(uint16_t sp_id, uint16_t vm_id,
                                       uint8_t msg)
 {
@@ -660,506 +524,6 @@ out:
                  resp.a7 & mask);
 }
 
-/*
- * Gets all page and assigns them to the supplied shared memory object. If
- * this function fails then the caller is still expected to call
- * put_shm_pages() as a cleanup.
- */
-static int get_shm_pages(struct domain *d, struct ffa_shm_mem *shm,
-                         const struct ffa_address_range *range,
-                         uint32_t range_count, unsigned int start_page_idx,
-                         unsigned int *last_page_idx)
-{
-    unsigned int pg_idx = start_page_idx;
-    gfn_t gfn;
-    unsigned int n;
-    unsigned int m;
-    p2m_type_t t;
-    uint64_t addr;
-    uint64_t page_count;
-
-    for ( n = 0; n < range_count; n++ )
-    {
-        page_count = read_atomic(&range[n].page_count);
-        addr = read_atomic(&range[n].address);
-        for ( m = 0; m < page_count; m++ )
-        {
-            if ( pg_idx >= shm->page_count )
-                return FFA_RET_INVALID_PARAMETERS;
-
-            gfn = gaddr_to_gfn(addr + m * FFA_PAGE_SIZE);
-            shm->pages[pg_idx] = get_page_from_gfn(d, gfn_x(gfn), &t,
-						   P2M_ALLOC);
-            if ( !shm->pages[pg_idx] )
-                return FFA_RET_DENIED;
-            /* Only normal RW RAM for now */
-            if ( t != p2m_ram_rw )
-                return FFA_RET_DENIED;
-            pg_idx++;
-        }
-    }
-
-    *last_page_idx = pg_idx;
-
-    return FFA_RET_OK;
-}
-
-static void put_shm_pages(struct ffa_shm_mem *shm)
-{
-    unsigned int n;
-
-    for ( n = 0; n < shm->page_count && shm->pages[n]; n++ )
-    {
-        put_page(shm->pages[n]);
-        shm->pages[n] = NULL;
-    }
-}
-
-static bool inc_ctx_shm_count(struct domain *d, struct ffa_ctx *ctx)
-{
-    bool ret = true;
-
-    spin_lock(&ctx->lock);
-
-    if ( ctx->shm_count >= FFA_MAX_SHM_COUNT )
-    {
-        ret = false;
-    }
-    else
-    {
-        /*
-         * If this is the first shm added, increase the domain reference
-         * counter as we need to keep domain around a bit longer to reclaim
-         * the shared memory in the teardown path.
-         */
-        if ( !ctx->shm_count )
-            get_knownalive_domain(d);
-
-        ctx->shm_count++;
-    }
-
-    spin_unlock(&ctx->lock);
-
-    return ret;
-}
-
-static void dec_ctx_shm_count(struct domain *d, struct ffa_ctx *ctx)
-{
-    bool drop_ref;
-
-    spin_lock(&ctx->lock);
-
-    ASSERT(ctx->shm_count > 0);
-    ctx->shm_count--;
-
-    /*
-     * If this was the last shm removed, let go of the domain reference we
-     * took in inc_ctx_shm_count() above.
-     */
-    drop_ref = !ctx->shm_count;
-
-    spin_unlock(&ctx->lock);
-
-    if ( drop_ref )
-        put_domain(d);
-}
-
-static struct ffa_shm_mem *alloc_ffa_shm_mem(struct domain *d,
-                                             unsigned int page_count)
-{
-    struct ffa_ctx *ctx = d->arch.tee;
-    struct ffa_shm_mem *shm;
-
-    if ( page_count >= FFA_MAX_SHM_PAGE_COUNT )
-        return NULL;
-    if ( !inc_ctx_shm_count(d, ctx) )
-        return NULL;
-
-    shm = xzalloc_flex_struct(struct ffa_shm_mem, pages, page_count);
-    if ( shm )
-        shm->page_count = page_count;
-    else
-        dec_ctx_shm_count(d, ctx);
-
-    return shm;
-}
-
-static void free_ffa_shm_mem(struct domain *d, struct ffa_shm_mem *shm)
-{
-    struct ffa_ctx *ctx = d->arch.tee;
-
-    if ( !shm )
-        return;
-
-    dec_ctx_shm_count(d, ctx);
-    put_shm_pages(shm);
-    xfree(shm);
-}
-
-static void init_range(struct ffa_address_range *addr_range,
-                       paddr_t pa)
-{
-    memset(addr_range, 0, sizeof(*addr_range));
-    addr_range->address = pa;
-    addr_range->page_count = 1;
-}
-
-/*
- * This function uses the ffa_tx buffer to transmit the memory transaction
- * descriptor. The function depends ffa_tx_buffer_lock to be used to guard
- * the buffer from concurrent use.
- */
-static int share_shm(struct ffa_shm_mem *shm)
-{
-    const uint32_t max_frag_len = FFA_RXTX_PAGE_COUNT * FFA_PAGE_SIZE;
-    struct ffa_mem_access *mem_access_array;
-    struct ffa_mem_transaction_1_1 *descr;
-    struct ffa_address_range *addr_range;
-    struct ffa_mem_region *region_descr;
-    const unsigned int region_count = 1;
-    void *buf = ffa_tx;
-    uint32_t frag_len;
-    uint32_t tot_len;
-    paddr_t last_pa;
-    unsigned int n;
-    paddr_t pa;
-
-    ASSERT(spin_is_locked(&ffa_tx_buffer_lock));
-    ASSERT(shm->page_count);
-
-    descr = buf;
-    memset(descr, 0, sizeof(*descr));
-    descr->sender_id = shm->sender_id;
-    descr->handle = shm->handle;
-    descr->mem_reg_attr = FFA_NORMAL_MEM_REG_ATTR;
-    descr->mem_access_count = 1;
-    descr->mem_access_size = sizeof(*mem_access_array);
-    descr->mem_access_offs = MEM_ACCESS_OFFSET(0);
-
-    mem_access_array = buf + descr->mem_access_offs;
-    memset(mem_access_array, 0, sizeof(*mem_access_array));
-    mem_access_array[0].access_perm.endpoint_id = shm->ep_id;
-    mem_access_array[0].access_perm.perm = FFA_MEM_ACC_RW;
-    mem_access_array[0].region_offs = REGION_OFFSET(descr->mem_access_count, 0);
-
-    region_descr = buf + mem_access_array[0].region_offs;
-    memset(region_descr, 0, sizeof(*region_descr));
-    region_descr->total_page_count = shm->page_count;
-
-    region_descr->address_range_count = 1;
-    last_pa = page_to_maddr(shm->pages[0]);
-    for ( n = 1; n < shm->page_count; last_pa = pa, n++ )
-    {
-        pa = page_to_maddr(shm->pages[n]);
-        if ( last_pa + FFA_PAGE_SIZE == pa )
-            continue;
-        region_descr->address_range_count++;
-    }
-
-    tot_len = ADDR_RANGE_OFFSET(descr->mem_access_count, region_count,
-                                region_descr->address_range_count);
-    if ( tot_len > max_frag_len )
-        return FFA_RET_NOT_SUPPORTED;
-
-    addr_range = region_descr->address_range_array;
-    frag_len = ADDR_RANGE_OFFSET(descr->mem_access_count, region_count, 1);
-    last_pa = page_to_maddr(shm->pages[0]);
-    init_range(addr_range, last_pa);
-    for ( n = 1; n < shm->page_count; last_pa = pa, n++ )
-    {
-        pa = page_to_maddr(shm->pages[n]);
-        if ( last_pa + FFA_PAGE_SIZE == pa )
-        {
-            addr_range->page_count++;
-            continue;
-        }
-
-        frag_len += sizeof(*addr_range);
-        addr_range++;
-        init_range(addr_range, pa);
-    }
-
-    return ffa_mem_share(tot_len, frag_len, 0, 0, &shm->handle);
-}
-
-static int read_mem_transaction(uint32_t ffa_vers, const void *buf, size_t blen,
-                                struct ffa_mem_transaction_int *trans)
-{
-    uint16_t mem_reg_attr;
-    uint32_t flags;
-    uint32_t count;
-    uint32_t offs;
-    uint32_t size;
-
-    if ( ffa_vers >= FFA_VERSION_1_1 )
-    {
-        const struct ffa_mem_transaction_1_1 *descr;
-
-        if ( blen < sizeof(*descr) )
-            return FFA_RET_INVALID_PARAMETERS;
-
-        descr = buf;
-        trans->sender_id = descr->sender_id;
-        mem_reg_attr = descr->mem_reg_attr;
-        flags = descr->flags;
-        trans->handle = descr->handle;
-        trans->tag = descr->tag;
-
-        count = descr->mem_access_count;
-        size = descr->mem_access_size;
-        offs = descr->mem_access_offs;
-    }
-    else
-    {
-        const struct ffa_mem_transaction_1_0 *descr;
-
-        if ( blen < sizeof(*descr) )
-            return FFA_RET_INVALID_PARAMETERS;
-
-        descr = buf;
-        trans->sender_id = descr->sender_id;
-        mem_reg_attr = descr->mem_reg_attr;
-        flags = descr->flags;
-        trans->handle = descr->handle;
-        trans->tag = descr->tag;
-
-        count = descr->mem_access_count;
-        size = sizeof(struct ffa_mem_access);
-        offs = offsetof(struct ffa_mem_transaction_1_0, mem_access_array);
-    }
-    /*
-     * Make sure that "descr" which is shared with the guest isn't accessed
-     * again after this point.
-     */
-    barrier();
-
-    /*
-     * We're doing a rough check to see that no information is lost when
-     * tranfering the values into a struct ffa_mem_transaction_int below.
-     * The fields in struct ffa_mem_transaction_int are wide enough to hold
-     * any valid value so being out of range means that something is wrong.
-     */
-    if ( mem_reg_attr > UINT8_MAX || flags > UINT8_MAX || size > UINT8_MAX ||
-        count > UINT8_MAX || offs > UINT16_MAX )
-        return FFA_RET_INVALID_PARAMETERS;
-
-    /* Check that the endpoint memory access descriptor array fits */
-    if ( size * count + offs > blen )
-        return FFA_RET_INVALID_PARAMETERS;
-
-    trans->mem_reg_attr = mem_reg_attr;
-    trans->flags = flags;
-    trans->mem_access_size = size;
-    trans->mem_access_count = count;
-    trans->mem_access_offs = offs;
-
-    return 0;
-}
-
-static void ffa_handle_mem_share(struct cpu_user_regs *regs)
-{
-    uint32_t tot_len = get_user_reg(regs, 1);
-    uint32_t frag_len = get_user_reg(regs, 2);
-    uint64_t addr = get_user_reg(regs, 3);
-    uint32_t page_count = get_user_reg(regs, 4);
-    const struct ffa_mem_region *region_descr;
-    const struct ffa_mem_access *mem_access;
-    struct ffa_mem_transaction_int trans;
-    struct domain *d = current->domain;
-    struct ffa_ctx *ctx = d->arch.tee;
-    struct ffa_shm_mem *shm = NULL;
-    unsigned int last_page_idx = 0;
-    register_t handle_hi = 0;
-    register_t handle_lo = 0;
-    int ret = FFA_RET_DENIED;
-    uint32_t range_count;
-    uint32_t region_offs;
-
-    /*
-     * We're only accepting memory transaction descriptors via the rx/tx
-     * buffer.
-     */
-    if ( addr )
-    {
-        ret = FFA_RET_NOT_SUPPORTED;
-        goto out_set_ret;
-    }
-
-    /* Check that fragment length doesn't exceed total length */
-    if ( frag_len > tot_len )
-    {
-        ret = FFA_RET_INVALID_PARAMETERS;
-        goto out_set_ret;
-    }
-
-    /* We currently only support a single fragment */
-    if ( frag_len != tot_len )
-    {
-        ret = FFA_RET_NOT_SUPPORTED;
-        goto out_set_ret;
-    }
-
-    if ( !spin_trylock(&ctx->tx_lock) )
-    {
-        ret = FFA_RET_BUSY;
-        goto out_set_ret;
-    }
-
-    if ( frag_len > ctx->page_count * FFA_PAGE_SIZE )
-        goto out_unlock;
-
-    ret = read_mem_transaction(ctx->guest_vers, ctx->tx, frag_len, &trans);
-    if ( ret )
-        goto out_unlock;
-
-    if ( trans.mem_reg_attr != FFA_NORMAL_MEM_REG_ATTR )
-    {
-        ret = FFA_RET_NOT_SUPPORTED;
-        goto out_unlock;
-    }
-
-    /* Only supports sharing it with one SP for now */
-    if ( trans.mem_access_count != 1 )
-    {
-        ret = FFA_RET_NOT_SUPPORTED;
-        goto out_unlock;
-    }
-
-    if ( trans.sender_id != ffa_get_vm_id(d) )
-    {
-        ret = FFA_RET_INVALID_PARAMETERS;
-        goto out_unlock;
-    }
-
-    /* Check that it fits in the supplied data */
-    if ( trans.mem_access_offs + trans.mem_access_size > frag_len )
-        goto out_unlock;
-
-    mem_access = ctx->tx + trans.mem_access_offs;
-    if ( read_atomic(&mem_access->access_perm.perm) != FFA_MEM_ACC_RW )
-    {
-        ret = FFA_RET_NOT_SUPPORTED;
-        goto out_unlock;
-    }
-
-    region_offs = read_atomic(&mem_access->region_offs);
-    if ( sizeof(*region_descr) + region_offs > frag_len )
-    {
-        ret = FFA_RET_NOT_SUPPORTED;
-        goto out_unlock;
-    }
-
-    region_descr = ctx->tx + region_offs;
-    range_count = read_atomic(®ion_descr->address_range_count);
-    page_count = read_atomic(®ion_descr->total_page_count);
-
-    if ( !page_count )
-    {
-        ret = FFA_RET_INVALID_PARAMETERS;
-        goto out_unlock;
-    }
-
-    shm = alloc_ffa_shm_mem(d, page_count);
-    if ( !shm )
-    {
-        ret = FFA_RET_NO_MEMORY;
-        goto out_unlock;
-    }
-    shm->sender_id = trans.sender_id;
-    shm->ep_id = read_atomic(&mem_access->access_perm.endpoint_id);
-
-    /*
-     * Check that the Composite memory region descriptor fits.
-     */
-    if ( sizeof(*region_descr) + region_offs +
-         range_count * sizeof(struct ffa_address_range) > frag_len )
-    {
-        ret = FFA_RET_INVALID_PARAMETERS;
-        goto out;
-    }
-
-    ret = get_shm_pages(d, shm, region_descr->address_range_array, range_count,
-                        0, &last_page_idx);
-    if ( ret )
-        goto out;
-    if ( last_page_idx != shm->page_count )
-    {
-        ret = FFA_RET_INVALID_PARAMETERS;
-        goto out;
-    }
-
-    /* Note that share_shm() uses our tx buffer */
-    spin_lock(&ffa_tx_buffer_lock);
-    ret = share_shm(shm);
-    spin_unlock(&ffa_tx_buffer_lock);
-    if ( ret )
-        goto out;
-
-    spin_lock(&ctx->lock);
-    list_add_tail(&shm->list, &ctx->shm_list);
-    spin_unlock(&ctx->lock);
-
-    uint64_to_regpair(&handle_hi, &handle_lo, shm->handle);
-
-out:
-    if ( ret )
-        free_ffa_shm_mem(d, shm);
-out_unlock:
-    spin_unlock(&ctx->tx_lock);
-
-out_set_ret:
-    if ( ret == 0)
-            ffa_set_regs_success(regs, handle_lo, handle_hi);
-    else
-            ffa_set_regs_error(regs, ret);
-}
-
-/* Must only be called with ctx->lock held */
-static struct ffa_shm_mem *find_shm_mem(struct ffa_ctx *ctx, uint64_t handle)
-{
-    struct ffa_shm_mem *shm;
-
-    list_for_each_entry(shm, &ctx->shm_list, list)
-        if ( shm->handle == handle )
-            return shm;
-
-    return NULL;
-}
-
-static int ffa_handle_mem_reclaim(uint64_t handle, uint32_t flags)
-{
-    struct domain *d = current->domain;
-    struct ffa_ctx *ctx = d->arch.tee;
-    struct ffa_shm_mem *shm;
-    register_t handle_hi;
-    register_t handle_lo;
-    int ret;
-
-    spin_lock(&ctx->lock);
-    shm = find_shm_mem(ctx, handle);
-    if ( shm )
-        list_del(&shm->list);
-    spin_unlock(&ctx->lock);
-    if ( !shm )
-        return FFA_RET_INVALID_PARAMETERS;
-
-    uint64_to_regpair(&handle_hi, &handle_lo, handle);
-    ret = ffa_mem_reclaim(handle_lo, handle_hi, flags);
-
-    if ( ret )
-    {
-        spin_lock(&ctx->lock);
-        list_add_tail(&shm->list, &ctx->shm_list);
-        spin_unlock(&ctx->lock);
-    }
-    else
-    {
-        free_ffa_shm_mem(d, shm);
-    }
-
-    return ret;
-}
-
 static bool ffa_handle_call(struct cpu_user_regs *regs)
 {
     uint32_t fid = get_user_reg(regs, 0);
@@ -1284,8 +648,8 @@ static int ffa_domain_init(struct domain *d)
     if ( !ffa_version )
         return -ENODEV;
      /*
-      * We can't use that last possible domain ID or get_vm_id() would cause
-      * an overflow.
+      * We can't use that last possible domain ID or ffa_get_vm_id() would
+      * cause an overflow.
       */
     if ( d->domain_id >= UINT16_MAX)
         return -ERANGE;
@@ -1348,68 +712,16 @@ static void send_vm_destroyed(struct domain *d)
     }
 }
 
-static void ffa_reclaim_shms(struct domain *d)
-{
-    struct ffa_ctx *ctx = d->arch.tee;
-    struct ffa_shm_mem *shm, *tmp;
-    int32_t res;
-
-    list_for_each_entry_safe(shm, tmp, &ctx->shm_list, list)
-    {
-        register_t handle_hi;
-        register_t handle_lo;
-
-        uint64_to_regpair(&handle_hi, &handle_lo, shm->handle);
-        res = ffa_mem_reclaim(handle_lo, handle_hi, 0);
-        switch ( res ) {
-        case FFA_RET_OK:
-            printk(XENLOG_G_DEBUG "%pd: ffa: Reclaimed handle %#lx\n",
-                   d, shm->handle);
-            list_del(&shm->list);
-            free_ffa_shm_mem(d, shm);
-            break;
-        case FFA_RET_DENIED:
-            /*
-             * A temporary error that may get resolved a bit later, it's
-             * worth retrying.
-             */
-            printk(XENLOG_G_INFO "%pd: ffa: Failed to reclaim handle %#lx : %d\n",
-                   d, shm->handle, res);
-            break; /* We will retry later */
-        default:
-            /*
-             * The rest of the error codes are not expected and are assumed
-             * to be of a permanent nature. It not in our control to handle
-             * the error properly so the object in this case is to try to
-             * minimize the damage.
-             *
-             * FFA_RET_NO_MEMORY might be a temporary error as it it could
-             * succeed if retried later, but treat it as permanent for now.
-             */
-            printk(XENLOG_G_INFO "%pd: ffa: Permanent failure to reclaim handle %#lx : %d\n",
-                   d, shm->handle, res);
-
-            /*
-             * Remove the shm from the list and free it, but don't drop
-             * references. This results in having the shared physical pages
-             * permanently allocate and also keeps the domain as a zombie
-             * domain.
-             */
-            list_del(&shm->list);
-            xfree(shm);
-            break;
-        }
-    }
-}
-
 static void ffa_domain_teardown_continue(struct ffa_ctx *ctx, bool first_time)
 {
     struct ffa_ctx *next_ctx = NULL;
+    bool retry = false;
 
     send_vm_destroyed(ctx->teardown_d);
-    ffa_reclaim_shms(ctx->teardown_d);
+    if ( !ffa_shm_domain_destroy(ctx->teardown_d) )
+        retry = true;
 
-    if ( ctx->shm_count ||
+    if ( retry ||
          !bitmap_empty(ctx->vm_destroy_bitmap, subscr_vm_destroyed_count) )
     {
         printk(XENLOG_G_INFO "%pd: ffa: Remaining cleanup, retrying\n", ctx->teardown_d);
diff --git a/xen/arch/arm/tee/ffa_private.h b/xen/arch/arm/tee/ffa_private.h
index 8352b6b55a9a..f3e2f42e573e 100644
--- a/xen/arch/arm/tee/ffa_private.h
+++ b/xen/arch/arm/tee/ffa_private.h
@@ -247,6 +247,16 @@ struct ffa_ctx {
     unsigned long vm_destroy_bitmap[];
 };
 
+extern void *ffa_rx;
+extern void *ffa_tx;
+extern spinlock_t ffa_rx_buffer_lock;
+extern spinlock_t ffa_tx_buffer_lock;
+
+bool ffa_shm_domain_destroy(struct domain *d);
+void ffa_handle_mem_share(struct cpu_user_regs *regs);
+int ffa_handle_mem_reclaim(uint64_t handle, uint32_t flags);
+
+
 static inline uint16_t ffa_get_vm_id(const struct domain *d)
 {
     /* +1 since 0 is reserved for the hypervisor in FF-A */
diff --git a/xen/arch/arm/tee/ffa_shm.c b/xen/arch/arm/tee/ffa_shm.c
new file mode 100644
index 000000000000..13dc44683b45
--- /dev/null
+++ b/xen/arch/arm/tee/ffa_shm.c
@@ -0,0 +1,708 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2023  Linaro Limited
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include "ffa_private.h"
+
+/* Constituent memory region descriptor */
+struct ffa_address_range {
+    uint64_t address;
+    uint32_t page_count;
+    uint32_t reserved;
+};
+
+/* Composite memory region descriptor */
+struct ffa_mem_region {
+    uint32_t total_page_count;
+    uint32_t address_range_count;
+    uint64_t reserved;
+    struct ffa_address_range address_range_array[];
+};
+
+/* Memory access permissions descriptor */
+struct ffa_mem_access_perm {
+    uint16_t endpoint_id;
+    uint8_t perm;
+    uint8_t flags;
+};
+
+/* Endpoint memory access descriptor */
+struct ffa_mem_access {
+    struct ffa_mem_access_perm access_perm;
+    uint32_t region_offs;
+    uint64_t reserved;
+};
+
+/* Lend, donate or share memory transaction descriptor */
+struct ffa_mem_transaction_1_0 {
+    uint16_t sender_id;
+    uint8_t mem_reg_attr;
+    uint8_t reserved0;
+    uint32_t flags;
+    uint64_t handle;
+    uint64_t tag;
+    uint32_t reserved1;
+    uint32_t mem_access_count;
+    struct ffa_mem_access mem_access_array[];
+};
+
+struct ffa_mem_transaction_1_1 {
+    uint16_t sender_id;
+    uint16_t mem_reg_attr;
+    uint32_t flags;
+    uint64_t handle;
+    uint64_t tag;
+    uint32_t mem_access_size;
+    uint32_t mem_access_count;
+    uint32_t mem_access_offs;
+    uint8_t reserved[12];
+};
+
+/* Calculate offset of struct ffa_mem_access from start of buffer */
+#define MEM_ACCESS_OFFSET(access_idx) \
+    ( sizeof(struct ffa_mem_transaction_1_1) + \
+      ( access_idx ) * sizeof(struct ffa_mem_access) )
+
+/* Calculate offset of struct ffa_mem_region from start of buffer */
+#define REGION_OFFSET(access_count, region_idx) \
+    ( MEM_ACCESS_OFFSET(access_count) + \
+      ( region_idx ) * sizeof(struct ffa_mem_region) )
+
+/* Calculate offset of struct ffa_address_range from start of buffer */
+#define ADDR_RANGE_OFFSET(access_count, region_count, range_idx) \
+    ( REGION_OFFSET(access_count, region_count) + \
+      ( range_idx ) * sizeof(struct ffa_address_range) )
+
+/*
+ * The parts needed from struct ffa_mem_transaction_1_0 or struct
+ * ffa_mem_transaction_1_1, used to provide an abstraction of difference in
+ * data structures between version 1.0 and 1.1. This is just an internal
+ * interface and can be changed without changing any ABI.
+ */
+struct ffa_mem_transaction_int {
+    uint16_t sender_id;
+    uint8_t mem_reg_attr;
+    uint8_t flags;
+    uint8_t mem_access_size;
+    uint8_t mem_access_count;
+    uint16_t mem_access_offs;
+    uint64_t handle;
+    uint64_t tag;
+};
+
+struct ffa_shm_mem {
+    struct list_head list;
+    uint16_t sender_id;
+    uint16_t ep_id;     /* endpoint, the one lending */
+    uint64_t handle;    /* FFA_HANDLE_INVALID if not set yet */
+    unsigned int page_count;
+    struct page_info *pages[];
+};
+
+static int32_t ffa_mem_share(uint32_t tot_len, uint32_t frag_len,
+                             register_t addr, uint32_t pg_count,
+                             uint64_t *handle)
+{
+    struct arm_smccc_1_2_regs arg = {
+        .a0 = FFA_MEM_SHARE_64,
+        .a1 = tot_len,
+        .a2 = frag_len,
+        .a3 = addr,
+        .a4 = pg_count,
+    };
+    struct arm_smccc_1_2_regs resp;
+
+    arm_smccc_1_2_smc(&arg, &resp);
+
+    switch ( resp.a0 )
+    {
+    case FFA_ERROR:
+        if ( resp.a2 )
+            return resp.a2;
+        else
+            return FFA_RET_NOT_SUPPORTED;
+    case FFA_SUCCESS_32:
+        *handle = regpair_to_uint64(resp.a3, resp.a2);
+        return FFA_RET_OK;
+    case FFA_MEM_FRAG_RX:
+        *handle = regpair_to_uint64(resp.a2, resp.a1);
+        if ( resp.a3 > INT32_MAX ) /* Impossible value */
+            return FFA_RET_ABORTED;
+        return resp.a3 & INT32_MAX;
+    default:
+        return FFA_RET_NOT_SUPPORTED;
+    }
+}
+
+static int32_t ffa_mem_reclaim(uint32_t handle_lo, uint32_t handle_hi,
+                               uint32_t flags)
+{
+    return ffa_simple_call(FFA_MEM_RECLAIM, handle_lo, handle_hi, flags, 0);
+}
+
+/*
+ * Gets all page and assigns them to the supplied shared memory object. If
+ * this function fails then the caller is still expected to call
+ * put_shm_pages() as a cleanup.
+ */
+static int get_shm_pages(struct domain *d, struct ffa_shm_mem *shm,
+                         const struct ffa_address_range *range,
+                         uint32_t range_count, unsigned int start_page_idx,
+                         unsigned int *last_page_idx)
+{
+    unsigned int pg_idx = start_page_idx;
+    gfn_t gfn;
+    unsigned int n;
+    unsigned int m;
+    p2m_type_t t;
+    uint64_t addr;
+    uint64_t page_count;
+
+    for ( n = 0; n < range_count; n++ )
+    {
+        page_count = read_atomic(&range[n].page_count);
+        addr = read_atomic(&range[n].address);
+        for ( m = 0; m < page_count; m++ )
+        {
+            if ( pg_idx >= shm->page_count )
+                return FFA_RET_INVALID_PARAMETERS;
+
+            gfn = gaddr_to_gfn(addr + m * FFA_PAGE_SIZE);
+            shm->pages[pg_idx] = get_page_from_gfn(d, gfn_x(gfn), &t,
+						   P2M_ALLOC);
+            if ( !shm->pages[pg_idx] )
+                return FFA_RET_DENIED;
+            /* Only normal RW RAM for now */
+            if ( t != p2m_ram_rw )
+                return FFA_RET_DENIED;
+            pg_idx++;
+        }
+    }
+
+    *last_page_idx = pg_idx;
+
+    return FFA_RET_OK;
+}
+
+static void put_shm_pages(struct ffa_shm_mem *shm)
+{
+    unsigned int n;
+
+    for ( n = 0; n < shm->page_count && shm->pages[n]; n++ )
+    {
+        put_page(shm->pages[n]);
+        shm->pages[n] = NULL;
+    }
+}
+
+static bool inc_ctx_shm_count(struct domain *d, struct ffa_ctx *ctx)
+{
+    bool ret = true;
+
+    spin_lock(&ctx->lock);
+
+    if ( ctx->shm_count >= FFA_MAX_SHM_COUNT )
+    {
+        ret = false;
+    }
+    else
+    {
+        /*
+         * If this is the first shm added, increase the domain reference
+         * counter as we need to keep domain around a bit longer to reclaim
+         * the shared memory in the teardown path.
+         */
+        if ( !ctx->shm_count )
+            get_knownalive_domain(d);
+
+        ctx->shm_count++;
+    }
+
+    spin_unlock(&ctx->lock);
+
+    return ret;
+}
+
+static void dec_ctx_shm_count(struct domain *d, struct ffa_ctx *ctx)
+{
+    bool drop_ref;
+
+    spin_lock(&ctx->lock);
+
+    ASSERT(ctx->shm_count > 0);
+    ctx->shm_count--;
+
+    /*
+     * If this was the last shm removed, let go of the domain reference we
+     * took in inc_ctx_shm_count() above.
+     */
+    drop_ref = !ctx->shm_count;
+
+    spin_unlock(&ctx->lock);
+
+    if ( drop_ref )
+        put_domain(d);
+}
+
+static struct ffa_shm_mem *alloc_ffa_shm_mem(struct domain *d,
+                                             unsigned int page_count)
+{
+    struct ffa_ctx *ctx = d->arch.tee;
+    struct ffa_shm_mem *shm;
+
+    if ( page_count >= FFA_MAX_SHM_PAGE_COUNT )
+        return NULL;
+    if ( !inc_ctx_shm_count(d, ctx) )
+        return NULL;
+
+    shm = xzalloc_flex_struct(struct ffa_shm_mem, pages, page_count);
+    if ( shm )
+        shm->page_count = page_count;
+    else
+        dec_ctx_shm_count(d, ctx);
+
+    return shm;
+}
+
+static void free_ffa_shm_mem(struct domain *d, struct ffa_shm_mem *shm)
+{
+    struct ffa_ctx *ctx = d->arch.tee;
+
+    if ( !shm )
+        return;
+
+    dec_ctx_shm_count(d, ctx);
+    put_shm_pages(shm);
+    xfree(shm);
+}
+
+static void init_range(struct ffa_address_range *addr_range,
+                       paddr_t pa)
+{
+    memset(addr_range, 0, sizeof(*addr_range));
+    addr_range->address = pa;
+    addr_range->page_count = 1;
+}
+
+/*
+ * This function uses the ffa_tx buffer to transmit the memory transaction
+ * descriptor. The function depends ffa_tx_buffer_lock to be used to guard
+ * the buffer from concurrent use.
+ */
+static int share_shm(struct ffa_shm_mem *shm)
+{
+    const uint32_t max_frag_len = FFA_RXTX_PAGE_COUNT * FFA_PAGE_SIZE;
+    struct ffa_mem_access *mem_access_array;
+    struct ffa_mem_transaction_1_1 *descr;
+    struct ffa_address_range *addr_range;
+    struct ffa_mem_region *region_descr;
+    const unsigned int region_count = 1;
+    void *buf = ffa_tx;
+    uint32_t frag_len;
+    uint32_t tot_len;
+    paddr_t last_pa;
+    unsigned int n;
+    paddr_t pa;
+
+    ASSERT(spin_is_locked(&ffa_tx_buffer_lock));
+    ASSERT(shm->page_count);
+
+    descr = buf;
+    memset(descr, 0, sizeof(*descr));
+    descr->sender_id = shm->sender_id;
+    descr->handle = shm->handle;
+    descr->mem_reg_attr = FFA_NORMAL_MEM_REG_ATTR;
+    descr->mem_access_count = 1;
+    descr->mem_access_size = sizeof(*mem_access_array);
+    descr->mem_access_offs = MEM_ACCESS_OFFSET(0);
+
+    mem_access_array = buf + descr->mem_access_offs;
+    memset(mem_access_array, 0, sizeof(*mem_access_array));
+    mem_access_array[0].access_perm.endpoint_id = shm->ep_id;
+    mem_access_array[0].access_perm.perm = FFA_MEM_ACC_RW;
+    mem_access_array[0].region_offs = REGION_OFFSET(descr->mem_access_count, 0);
+
+    region_descr = buf + mem_access_array[0].region_offs;
+    memset(region_descr, 0, sizeof(*region_descr));
+    region_descr->total_page_count = shm->page_count;
+
+    region_descr->address_range_count = 1;
+    last_pa = page_to_maddr(shm->pages[0]);
+    for ( n = 1; n < shm->page_count; last_pa = pa, n++ )
+    {
+        pa = page_to_maddr(shm->pages[n]);
+        if ( last_pa + FFA_PAGE_SIZE == pa )
+            continue;
+        region_descr->address_range_count++;
+    }
+
+    tot_len = ADDR_RANGE_OFFSET(descr->mem_access_count, region_count,
+                                region_descr->address_range_count);
+    if ( tot_len > max_frag_len )
+        return FFA_RET_NOT_SUPPORTED;
+
+    addr_range = region_descr->address_range_array;
+    frag_len = ADDR_RANGE_OFFSET(descr->mem_access_count, region_count, 1);
+    last_pa = page_to_maddr(shm->pages[0]);
+    init_range(addr_range, last_pa);
+    for ( n = 1; n < shm->page_count; last_pa = pa, n++ )
+    {
+        pa = page_to_maddr(shm->pages[n]);
+        if ( last_pa + FFA_PAGE_SIZE == pa )
+        {
+            addr_range->page_count++;
+            continue;
+        }
+
+        frag_len += sizeof(*addr_range);
+        addr_range++;
+        init_range(addr_range, pa);
+    }
+
+    return ffa_mem_share(tot_len, frag_len, 0, 0, &shm->handle);
+}
+
+static int read_mem_transaction(uint32_t ffa_vers, const void *buf, size_t blen,
+                                struct ffa_mem_transaction_int *trans)
+{
+    uint16_t mem_reg_attr;
+    uint32_t flags;
+    uint32_t count;
+    uint32_t offs;
+    uint32_t size;
+
+    if ( ffa_vers >= FFA_VERSION_1_1 )
+    {
+        const struct ffa_mem_transaction_1_1 *descr;
+
+        if ( blen < sizeof(*descr) )
+            return FFA_RET_INVALID_PARAMETERS;
+
+        descr = buf;
+        trans->sender_id = descr->sender_id;
+        mem_reg_attr = descr->mem_reg_attr;
+        flags = descr->flags;
+        trans->handle = descr->handle;
+        trans->tag = descr->tag;
+
+        count = descr->mem_access_count;
+        size = descr->mem_access_size;
+        offs = descr->mem_access_offs;
+    }
+    else
+    {
+        const struct ffa_mem_transaction_1_0 *descr;
+
+        if ( blen < sizeof(*descr) )
+            return FFA_RET_INVALID_PARAMETERS;
+
+        descr = buf;
+        trans->sender_id = descr->sender_id;
+        mem_reg_attr = descr->mem_reg_attr;
+        flags = descr->flags;
+        trans->handle = descr->handle;
+        trans->tag = descr->tag;
+
+        count = descr->mem_access_count;
+        size = sizeof(struct ffa_mem_access);
+        offs = offsetof(struct ffa_mem_transaction_1_0, mem_access_array);
+    }
+    /*
+     * Make sure that "descr" which is shared with the guest isn't accessed
+     * again after this point.
+     */
+    barrier();
+
+    /*
+     * We're doing a rough check to see that no information is lost when
+     * tranfering the values into a struct ffa_mem_transaction_int below.
+     * The fields in struct ffa_mem_transaction_int are wide enough to hold
+     * any valid value so being out of range means that something is wrong.
+     */
+    if ( mem_reg_attr > UINT8_MAX || flags > UINT8_MAX || size > UINT8_MAX ||
+        count > UINT8_MAX || offs > UINT16_MAX )
+        return FFA_RET_INVALID_PARAMETERS;
+
+    /* Check that the endpoint memory access descriptor array fits */
+    if ( size * count + offs > blen )
+        return FFA_RET_INVALID_PARAMETERS;
+
+    trans->mem_reg_attr = mem_reg_attr;
+    trans->flags = flags;
+    trans->mem_access_size = size;
+    trans->mem_access_count = count;
+    trans->mem_access_offs = offs;
+
+    return 0;
+}
+
+void ffa_handle_mem_share(struct cpu_user_regs *regs)
+{
+    uint32_t tot_len = get_user_reg(regs, 1);
+    uint32_t frag_len = get_user_reg(regs, 2);
+    uint64_t addr = get_user_reg(regs, 3);
+    uint32_t page_count = get_user_reg(regs, 4);
+    const struct ffa_mem_region *region_descr;
+    const struct ffa_mem_access *mem_access;
+    struct ffa_mem_transaction_int trans;
+    struct domain *d = current->domain;
+    struct ffa_ctx *ctx = d->arch.tee;
+    struct ffa_shm_mem *shm = NULL;
+    unsigned int last_page_idx = 0;
+    register_t handle_hi = 0;
+    register_t handle_lo = 0;
+    int ret = FFA_RET_DENIED;
+    uint32_t range_count;
+    uint32_t region_offs;
+
+    /*
+     * We're only accepting memory transaction descriptors via the rx/tx
+     * buffer.
+     */
+    if ( addr )
+    {
+        ret = FFA_RET_NOT_SUPPORTED;
+        goto out_set_ret;
+    }
+
+    /* Check that fragment length doesn't exceed total length */
+    if ( frag_len > tot_len )
+    {
+        ret = FFA_RET_INVALID_PARAMETERS;
+        goto out_set_ret;
+    }
+
+    /* We currently only support a single fragment */
+    if ( frag_len != tot_len )
+    {
+        ret = FFA_RET_NOT_SUPPORTED;
+        goto out_set_ret;
+    }
+
+    if ( !spin_trylock(&ctx->tx_lock) )
+    {
+        ret = FFA_RET_BUSY;
+        goto out_set_ret;
+    }
+
+    if ( frag_len > ctx->page_count * FFA_PAGE_SIZE )
+        goto out_unlock;
+
+    ret = read_mem_transaction(ctx->guest_vers, ctx->tx, frag_len, &trans);
+    if ( ret )
+        goto out_unlock;
+
+    if ( trans.mem_reg_attr != FFA_NORMAL_MEM_REG_ATTR )
+    {
+        ret = FFA_RET_NOT_SUPPORTED;
+        goto out_unlock;
+    }
+
+    /* Only supports sharing it with one SP for now */
+    if ( trans.mem_access_count != 1 )
+    {
+        ret = FFA_RET_NOT_SUPPORTED;
+        goto out_unlock;
+    }
+
+    if ( trans.sender_id != ffa_get_vm_id(d) )
+    {
+        ret = FFA_RET_INVALID_PARAMETERS;
+        goto out_unlock;
+    }
+
+    /* Check that it fits in the supplied data */
+    if ( trans.mem_access_offs + trans.mem_access_size > frag_len )
+        goto out_unlock;
+
+    mem_access = ctx->tx + trans.mem_access_offs;
+    if ( read_atomic(&mem_access->access_perm.perm) != FFA_MEM_ACC_RW )
+    {
+        ret = FFA_RET_NOT_SUPPORTED;
+        goto out_unlock;
+    }
+
+    region_offs = read_atomic(&mem_access->region_offs);
+    if ( sizeof(*region_descr) + region_offs > frag_len )
+    {
+        ret = FFA_RET_NOT_SUPPORTED;
+        goto out_unlock;
+    }
+
+    region_descr = ctx->tx + region_offs;
+    range_count = read_atomic(®ion_descr->address_range_count);
+    page_count = read_atomic(®ion_descr->total_page_count);
+
+    if ( !page_count )
+    {
+        ret = FFA_RET_INVALID_PARAMETERS;
+        goto out_unlock;
+    }
+
+    shm = alloc_ffa_shm_mem(d, page_count);
+    if ( !shm )
+    {
+        ret = FFA_RET_NO_MEMORY;
+        goto out_unlock;
+    }
+    shm->sender_id = trans.sender_id;
+    shm->ep_id = read_atomic(&mem_access->access_perm.endpoint_id);
+
+    /*
+     * Check that the Composite memory region descriptor fits.
+     */
+    if ( sizeof(*region_descr) + region_offs +
+         range_count * sizeof(struct ffa_address_range) > frag_len )
+    {
+        ret = FFA_RET_INVALID_PARAMETERS;
+        goto out;
+    }
+
+    ret = get_shm_pages(d, shm, region_descr->address_range_array, range_count,
+                        0, &last_page_idx);
+    if ( ret )
+        goto out;
+    if ( last_page_idx != shm->page_count )
+    {
+        ret = FFA_RET_INVALID_PARAMETERS;
+        goto out;
+    }
+
+    /* Note that share_shm() uses our tx buffer */
+    spin_lock(&ffa_tx_buffer_lock);
+    ret = share_shm(shm);
+    spin_unlock(&ffa_tx_buffer_lock);
+    if ( ret )
+        goto out;
+
+    spin_lock(&ctx->lock);
+    list_add_tail(&shm->list, &ctx->shm_list);
+    spin_unlock(&ctx->lock);
+
+    uint64_to_regpair(&handle_hi, &handle_lo, shm->handle);
+
+out:
+    if ( ret )
+        free_ffa_shm_mem(d, shm);
+out_unlock:
+    spin_unlock(&ctx->tx_lock);
+
+out_set_ret:
+    if ( ret == 0)
+            ffa_set_regs_success(regs, handle_lo, handle_hi);
+    else
+            ffa_set_regs_error(regs, ret);
+}
+
+/* Must only be called with ctx->lock held */
+static struct ffa_shm_mem *find_shm_mem(struct ffa_ctx *ctx, uint64_t handle)
+{
+    struct ffa_shm_mem *shm;
+
+    list_for_each_entry(shm, &ctx->shm_list, list)
+        if ( shm->handle == handle )
+            return shm;
+
+    return NULL;
+}
+
+int ffa_handle_mem_reclaim(uint64_t handle, uint32_t flags)
+{
+    struct domain *d = current->domain;
+    struct ffa_ctx *ctx = d->arch.tee;
+    struct ffa_shm_mem *shm;
+    register_t handle_hi;
+    register_t handle_lo;
+    int ret;
+
+    spin_lock(&ctx->lock);
+    shm = find_shm_mem(ctx, handle);
+    if ( shm )
+        list_del(&shm->list);
+    spin_unlock(&ctx->lock);
+    if ( !shm )
+        return FFA_RET_INVALID_PARAMETERS;
+
+    uint64_to_regpair(&handle_hi, &handle_lo, handle);
+    ret = ffa_mem_reclaim(handle_lo, handle_hi, flags);
+
+    if ( ret )
+    {
+        spin_lock(&ctx->lock);
+        list_add_tail(&shm->list, &ctx->shm_list);
+        spin_unlock(&ctx->lock);
+    }
+    else
+    {
+        free_ffa_shm_mem(d, shm);
+    }
+
+    return ret;
+}
+
+bool ffa_shm_domain_destroy(struct domain *d)
+{
+    struct ffa_ctx *ctx = d->arch.tee;
+    struct ffa_shm_mem *shm, *tmp;
+    int32_t res;
+
+    list_for_each_entry_safe(shm, tmp, &ctx->shm_list, list)
+    {
+        register_t handle_hi;
+        register_t handle_lo;
+
+        uint64_to_regpair(&handle_hi, &handle_lo, shm->handle);
+        res = ffa_mem_reclaim(handle_lo, handle_hi, 0);
+        switch ( res ) {
+        case FFA_RET_OK:
+            printk(XENLOG_G_DEBUG "%pd: ffa: Reclaimed handle %#lx\n",
+                   d, shm->handle);
+            list_del(&shm->list);
+            free_ffa_shm_mem(d, shm);
+            break;
+        case FFA_RET_DENIED:
+            /*
+             * A temporary error that may get resolved a bit later, it's
+             * worth retrying.
+             */
+            printk(XENLOG_G_INFO "%pd: ffa: Failed to reclaim handle %#lx : %d\n",
+                   d, shm->handle, res);
+            break; /* We will retry later */
+        default:
+            /*
+             * The rest of the error codes are not expected and are assumed
+             * to be of a permanent nature. It not in our control to handle
+             * the error properly so the object in this case is to try to
+             * minimize the damage.
+             *
+             * FFA_RET_NO_MEMORY might be a temporary error as it it could
+             * succeed if retried later, but treat it as permanent for now.
+             */
+            printk(XENLOG_G_INFO "%pd: ffa: Permanent failure to reclaim handle %#lx : %d\n",
+                   d, shm->handle, res);
+
+            /*
+             * Remove the shm from the list and free it, but don't drop
+             * references. This results in having the shared physical pages
+             * permanently allocate and also keeps the domain as a zombie
+             * domain.
+             */
+            list_del(&shm->list);
+            xfree(shm);
+            break;
+        }
+    }
+
+    return !ctx->shm_count;
+}
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Mon Mar 25 09:39:18 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 09:39:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697650.1088634 (Exim 4.92)
	(envelope-from )
	id 1rognW-00021a-Gt; Mon, 25 Mar 2024 09:39:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697650.1088634; Mon, 25 Mar 2024 09:39:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rognW-00020j-9F; Mon, 25 Mar 2024 09:39:18 +0000
Received: by outflank-mailman (input) for mailman id 697650;
 Mon, 25 Mar 2024 09:39:16 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rognU-000193-9Z
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 09:39:16 +0000
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com
 [2a00:1450:4864:20::62d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8b2f9576-ea8b-11ee-afe3-a90da7624cb6;
 Mon, 25 Mar 2024 10:39:15 +0100 (CET)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-a4715991c32so482271366b.1
 for ; Mon, 25 Mar 2024 02:39:15 -0700 (PDT)
Received: from rayden.urgonet (h-217-31-164-171.A175.priv.bahnhof.se.
 [217.31.164.171]) by smtp.gmail.com with ESMTPSA id
 bw26-20020a170906c1da00b00a4650ec48d0sm2891067ejb.140.2024.03.25.02.39.13
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 25 Mar 2024 02:39:14 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8b2f9576-ea8b-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1711359555; x=1711964355; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=ktHTOHPhZw2ERZCbIiZrCqqyY587Z370raI9TG92v+s=;
        b=yEP6T+18eaYVZdoALuo/IDevPszFdavJnEEp7t4W8RHG+A4C4+8Bs/JM1zrQg/kxpp
         3h2vGVGEA9qAyt/laghm1HGnuvUzgwYbReiofyEq/t2BdnX8WhkEBCMwYyxj8GaFgM7u
         G4FwFh1QiLCG5d6+KpPOnKFLBq/uhejPrFyK9VNF3RVRokgAWjVOgRIq+RaprxRiWZJs
         3ZUyVm1w3IJO0g4ZbhBHXd5rGl/Tgnb6s/R0MOHBC9IcQc1WMxZuYwlvS+bP39XS7a0c
         +p2qrdK1uFtveO9VUcH3UTNTVrMo01V6qYs+I22JZEPjSRKjKHec2Y/SmjlBsSPAcYj5
         55CA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711359555; x=1711964355;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=ktHTOHPhZw2ERZCbIiZrCqqyY587Z370raI9TG92v+s=;
        b=W1fIUGrAa1FKVTfbO0b+u44NBiK/+vO6dX1f9DYV0Dn+VPD8IHtd0F5ay2pwsd2YBY
         BU3n4zdhq8yuX712k53iRinEq7jY7rwLP063EDm3WBDuKIz1k76A0SMQm+sZ0TJc0mbP
         8t1ES+SNTkMFhsTBvH1Iy7ZvcO/qbGHnMtwS6iiB6AMy5WOifdH0JP+eQ0GujuIBLJWA
         a7bgURZ9vgntMyGoAtbHipC4dku3Em4zew8a6gxU34puH9a+XC2UOdEdbEiIoegsuBv2
         kjeQeM/4DobNp48kX4qx5Fq3BH8qyem9vbctZf5On5TncHBb+Wj33IXipAWoss/YsNWU
         9WQQ==
X-Gm-Message-State: AOJu0YwL5XtV917M9EU84MSMIcYv/AeEPUm6G6wtsDWQEV+4JVlVMxx7
	F7Q31satr+l41FV3tfwJMbcwV/0flug1xG5wgmzdZd9T7LlBwex6NLegUdtYBxmi+Hz9a0lM07S
	X
X-Google-Smtp-Source: AGHT+IEOGVY6EyKr+I/yJdd39jUyvRqBVgESrP7PFiLL/4YlDZRoDQR0ajVYjp5mXVwH3HmNwSEKUw==
X-Received: by 2002:a17:907:944f:b0:a49:56d4:d643 with SMTP id dl15-20020a170907944f00b00a4956d4d643mr2186112ejc.36.1711359554661;
        Mon, 25 Mar 2024 02:39:14 -0700 (PDT)
From: Jens Wiklander 
To: xen-devel@lists.xenproject.org
Cc: patches@linaro.org,
	Jens Wiklander ,
	Volodymyr Babchuk ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel 
Subject: [XEN PATCH 5/6] xen/arm: ffa: separate rxtx buffer routines
Date: Mon, 25 Mar 2024 10:39:03 +0100
Message-Id: <20240325093904.3466092-6-jens.wiklander@linaro.org>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20240325093904.3466092-1-jens.wiklander@linaro.org>
References: <20240325093904.3466092-1-jens.wiklander@linaro.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Move rxtx buffer routines into a spearate file for easier navigation in
the source code.

Add ffa_rxtx_init(), ffa_rxtx_destroy(), and ffa_rxtx_domain_destroy() to
handle the ffa_rxtx internal things on initialization and teardown.

Signed-off-by: Jens Wiklander 
---
 xen/arch/arm/tee/Makefile      |   1 +
 xen/arch/arm/tee/ffa.c         | 174 +-------------------------
 xen/arch/arm/tee/ffa_private.h |   7 ++
 xen/arch/arm/tee/ffa_rxtx.c    | 216 +++++++++++++++++++++++++++++++++
 4 files changed, 229 insertions(+), 169 deletions(-)
 create mode 100644 xen/arch/arm/tee/ffa_rxtx.c

diff --git a/xen/arch/arm/tee/Makefile b/xen/arch/arm/tee/Makefile
index be644fba8055..f0112a2f922d 100644
--- a/xen/arch/arm/tee/Makefile
+++ b/xen/arch/arm/tee/Makefile
@@ -1,5 +1,6 @@
 obj-$(CONFIG_FFA) += ffa.o
 obj-$(CONFIG_FFA) += ffa_shm.o
 obj-$(CONFIG_FFA) += ffa_partinfo.o
+obj-$(CONFIG_FFA) += ffa_rxtx.o
 obj-y += tee.o
 obj-$(CONFIG_OPTEE) += optee.o
diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
index 7a2803881420..4f7775b8c890 100644
--- a/xen/arch/arm/tee/ffa.c
+++ b/xen/arch/arm/tee/ffa.c
@@ -65,26 +65,6 @@
 
 #include "ffa_private.h"
 
-/*
- * Structs below ending with _1_0 are defined in FF-A-1.0-REL and
- * structs ending with _1_1 are defined in FF-A-1.1-REL0.
- */
-
-/* Endpoint RX/TX descriptor */
-struct ffa_endpoint_rxtx_descriptor_1_0 {
-    uint16_t sender_id;
-    uint16_t reserved;
-    uint32_t rx_range_count;
-    uint32_t tx_range_count;
-};
-
-struct ffa_endpoint_rxtx_descriptor_1_1 {
-    uint16_t sender_id;
-    uint16_t reserved;
-    uint32_t rx_region_offs;
-    uint32_t tx_region_offs;
-};
-
 /* Negotiated FF-A version to use with the SPMC */
 static uint32_t __ro_after_init ffa_version;
 
@@ -145,12 +125,6 @@ static bool check_mandatory_feature(uint32_t id)
     return !ret;
 }
 
-static int32_t ffa_rxtx_map(paddr_t tx_addr, paddr_t rx_addr,
-                            uint32_t page_count)
-{
-    return ffa_simple_call(FFA_RXTX_MAP_64, tx_addr, rx_addr, page_count, 0);
-}
-
 static void handle_version(struct cpu_user_regs *regs)
 {
     struct domain *d = current->domain;
@@ -166,127 +140,6 @@ static void handle_version(struct cpu_user_regs *regs)
     ffa_set_regs(regs, vers, 0, 0, 0, 0, 0, 0, 0);
 }
 
-static uint32_t ffa_handle_rxtx_map(uint32_t fid, register_t tx_addr,
-				    register_t rx_addr, uint32_t page_count)
-{
-    uint32_t ret = FFA_RET_INVALID_PARAMETERS;
-    struct domain *d = current->domain;
-    struct ffa_ctx *ctx = d->arch.tee;
-    struct page_info *tx_pg;
-    struct page_info *rx_pg;
-    p2m_type_t t;
-    void *rx;
-    void *tx;
-
-    if ( !smccc_is_conv_64(fid) )
-    {
-        /*
-         * Calls using the 32-bit calling convention must ignore the upper
-         * 32 bits in the argument registers.
-         */
-        tx_addr &= UINT32_MAX;
-        rx_addr &= UINT32_MAX;
-    }
-
-    if ( page_count > FFA_MAX_RXTX_PAGE_COUNT )
-    {
-        printk(XENLOG_ERR "ffa: RXTX_MAP: error: %u pages requested (limit %u)\n",
-               page_count, FFA_MAX_RXTX_PAGE_COUNT);
-        return FFA_RET_INVALID_PARAMETERS;
-    }
-
-    /* Already mapped */
-    if ( ctx->rx )
-        return FFA_RET_DENIED;
-
-    tx_pg = get_page_from_gfn(d, gfn_x(gaddr_to_gfn(tx_addr)), &t, P2M_ALLOC);
-    if ( !tx_pg )
-        return FFA_RET_INVALID_PARAMETERS;
-
-    /* Only normal RW RAM for now */
-    if ( t != p2m_ram_rw )
-        goto err_put_tx_pg;
-
-    rx_pg = get_page_from_gfn(d, gfn_x(gaddr_to_gfn(rx_addr)), &t, P2M_ALLOC);
-    if ( !tx_pg )
-        goto err_put_tx_pg;
-
-    /* Only normal RW RAM for now */
-    if ( t != p2m_ram_rw )
-        goto err_put_rx_pg;
-
-    tx = __map_domain_page_global(tx_pg);
-    if ( !tx )
-        goto err_put_rx_pg;
-
-    rx = __map_domain_page_global(rx_pg);
-    if ( !rx )
-        goto err_unmap_tx;
-
-    ctx->rx = rx;
-    ctx->tx = tx;
-    ctx->rx_pg = rx_pg;
-    ctx->tx_pg = tx_pg;
-    ctx->page_count = page_count;
-    ctx->rx_is_free = true;
-    return FFA_RET_OK;
-
-err_unmap_tx:
-    unmap_domain_page_global(tx);
-err_put_rx_pg:
-    put_page(rx_pg);
-err_put_tx_pg:
-    put_page(tx_pg);
-
-    return ret;
-}
-
-static void rxtx_unmap(struct ffa_ctx *ctx)
-{
-    unmap_domain_page_global(ctx->rx);
-    unmap_domain_page_global(ctx->tx);
-    put_page(ctx->rx_pg);
-    put_page(ctx->tx_pg);
-    ctx->rx = NULL;
-    ctx->tx = NULL;
-    ctx->rx_pg = NULL;
-    ctx->tx_pg = NULL;
-    ctx->page_count = 0;
-    ctx->rx_is_free = false;
-}
-
-static uint32_t ffa_handle_rxtx_unmap(void)
-{
-    struct domain *d = current->domain;
-    struct ffa_ctx *ctx = d->arch.tee;
-
-    if ( !ctx->rx )
-        return FFA_RET_INVALID_PARAMETERS;
-
-    rxtx_unmap(ctx);
-
-    return FFA_RET_OK;
-}
-
-static int32_t ffa_handle_rx_release(void)
-{
-    int32_t ret = FFA_RET_DENIED;
-    struct domain *d = current->domain;
-    struct ffa_ctx *ctx = d->arch.tee;
-
-    if ( !spin_trylock(&ctx->rx_lock) )
-        return FFA_RET_BUSY;
-
-    if ( !ctx->page_count || ctx->rx_is_free )
-        goto out;
-    ret = FFA_RET_OK;
-    ctx->rx_is_free = true;
-out:
-    spin_unlock(&ctx->rx_lock);
-
-    return ret;
-}
-
 static void handle_msg_send_direct_req(struct cpu_user_regs *regs, uint32_t fid)
 {
     struct arm_smccc_1_2_regs arg = { .a0 = fid, };
@@ -522,8 +375,7 @@ static int ffa_domain_teardown(struct domain *d)
     if ( !ctx )
         return 0;
 
-    if ( ctx->rx )
-        rxtx_unmap(ctx);
+    ffa_rxtx_domain_destroy(d);
 
     ffa_domain_teardown_continue(ctx, true /* first_time */);
 
@@ -538,7 +390,6 @@ static int ffa_relinquish_resources(struct domain *d)
 static bool ffa_probe(void)
 {
     uint32_t vers;
-    int e;
     unsigned int major_vers;
     unsigned int minor_vers;
 
@@ -596,36 +447,21 @@ static bool ffa_probe(void)
          !check_mandatory_feature(FFA_MSG_SEND_DIRECT_REQ_32) )
         return false;
 
-    ffa_rx = alloc_xenheap_pages(get_order_from_pages(FFA_RXTX_PAGE_COUNT), 0);
-    if ( !ffa_rx )
+    if ( !ffa_rxtx_init() )
         return false;
 
-    ffa_tx = alloc_xenheap_pages(get_order_from_pages(FFA_RXTX_PAGE_COUNT), 0);
-    if ( !ffa_tx )
-        goto err_free_ffa_rx;
-
-    e = ffa_rxtx_map(__pa(ffa_tx), __pa(ffa_rx), FFA_RXTX_PAGE_COUNT);
-    if ( e )
-    {
-        printk(XENLOG_ERR "ffa: Failed to map rxtx: error %d\n", e);
-        goto err_free_ffa_tx;
-    }
     ffa_version = vers;
 
     if ( !ffa_partinfo_init() )
-        goto err_free_ffa_tx;
+        goto err_rxtx_destroy;
 
     INIT_LIST_HEAD(&ffa_teardown_head);
     init_timer(&ffa_teardown_timer, ffa_teardown_timer_callback, NULL, 0);
 
     return true;
 
-err_free_ffa_tx:
-    free_xenheap_pages(ffa_tx, 0);
-    ffa_tx = NULL;
-err_free_ffa_rx:
-    free_xenheap_pages(ffa_rx, 0);
-    ffa_rx = NULL;
+err_rxtx_destroy:
+    ffa_rxtx_destroy();
     ffa_version = 0;
 
     return false;
diff --git a/xen/arch/arm/tee/ffa_private.h b/xen/arch/arm/tee/ffa_private.h
index 6b32b69cfe90..98236cbf14a3 100644
--- a/xen/arch/arm/tee/ffa_private.h
+++ b/xen/arch/arm/tee/ffa_private.h
@@ -263,6 +263,13 @@ int32_t ffa_handle_partition_info_get(uint32_t w1, uint32_t w2, uint32_t w3,
                                       uint32_t w4, uint32_t w5, uint32_t *count,
                                       uint32_t *fpi_size);
 
+bool ffa_rxtx_init(void);
+void ffa_rxtx_destroy(void);
+void ffa_rxtx_domain_destroy(struct domain *d);
+uint32_t ffa_handle_rxtx_map(uint32_t fid, register_t tx_addr,
+			     register_t rx_addr, uint32_t page_count);
+uint32_t ffa_handle_rxtx_unmap(void);
+int32_t ffa_handle_rx_release(void);
 
 static inline uint16_t ffa_get_vm_id(const struct domain *d)
 {
diff --git a/xen/arch/arm/tee/ffa_rxtx.c b/xen/arch/arm/tee/ffa_rxtx.c
new file mode 100644
index 000000000000..661764052e67
--- /dev/null
+++ b/xen/arch/arm/tee/ffa_rxtx.c
@@ -0,0 +1,216 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2024  Linaro Limited
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include "ffa_private.h"
+
+/* Endpoint RX/TX descriptor defined in FF-A-1.0-REL */
+struct ffa_endpoint_rxtx_descriptor_1_0 {
+    uint16_t sender_id;
+    uint16_t reserved;
+    uint32_t rx_range_count;
+    uint32_t tx_range_count;
+};
+
+/* Endpoint RX/TX descriptor defined in FF-A-1.1-REL0 */
+struct ffa_endpoint_rxtx_descriptor_1_1 {
+    uint16_t sender_id;
+    uint16_t reserved;
+    uint32_t rx_region_offs;
+    uint32_t tx_region_offs;
+};
+
+uint32_t ffa_handle_rxtx_map(uint32_t fid, register_t tx_addr,
+			     register_t rx_addr, uint32_t page_count)
+{
+    uint32_t ret = FFA_RET_INVALID_PARAMETERS;
+    struct domain *d = current->domain;
+    struct ffa_ctx *ctx = d->arch.tee;
+    struct page_info *tx_pg;
+    struct page_info *rx_pg;
+    p2m_type_t t;
+    void *rx;
+    void *tx;
+
+    if ( !smccc_is_conv_64(fid) )
+    {
+        /*
+         * Calls using the 32-bit calling convention must ignore the upper
+         * 32 bits in the argument registers.
+         */
+        tx_addr &= UINT32_MAX;
+        rx_addr &= UINT32_MAX;
+    }
+
+    if ( page_count > FFA_MAX_RXTX_PAGE_COUNT )
+    {
+        printk(XENLOG_ERR "ffa: RXTX_MAP: error: %u pages requested (limit %u)\n",
+               page_count, FFA_MAX_RXTX_PAGE_COUNT);
+        return FFA_RET_INVALID_PARAMETERS;
+    }
+
+    /* Already mapped */
+    if ( ctx->rx )
+        return FFA_RET_DENIED;
+
+    tx_pg = get_page_from_gfn(d, gfn_x(gaddr_to_gfn(tx_addr)), &t, P2M_ALLOC);
+    if ( !tx_pg )
+        return FFA_RET_INVALID_PARAMETERS;
+
+    /* Only normal RW RAM for now */
+    if ( t != p2m_ram_rw )
+        goto err_put_tx_pg;
+
+    rx_pg = get_page_from_gfn(d, gfn_x(gaddr_to_gfn(rx_addr)), &t, P2M_ALLOC);
+    if ( !tx_pg )
+        goto err_put_tx_pg;
+
+    /* Only normal RW RAM for now */
+    if ( t != p2m_ram_rw )
+        goto err_put_rx_pg;
+
+    tx = __map_domain_page_global(tx_pg);
+    if ( !tx )
+        goto err_put_rx_pg;
+
+    rx = __map_domain_page_global(rx_pg);
+    if ( !rx )
+        goto err_unmap_tx;
+
+    ctx->rx = rx;
+    ctx->tx = tx;
+    ctx->rx_pg = rx_pg;
+    ctx->tx_pg = tx_pg;
+    ctx->page_count = page_count;
+    ctx->rx_is_free = true;
+    return FFA_RET_OK;
+
+err_unmap_tx:
+    unmap_domain_page_global(tx);
+err_put_rx_pg:
+    put_page(rx_pg);
+err_put_tx_pg:
+    put_page(tx_pg);
+
+    return ret;
+}
+
+static void rxtx_unmap(struct ffa_ctx *ctx)
+{
+    unmap_domain_page_global(ctx->rx);
+    unmap_domain_page_global(ctx->tx);
+    put_page(ctx->rx_pg);
+    put_page(ctx->tx_pg);
+    ctx->rx = NULL;
+    ctx->tx = NULL;
+    ctx->rx_pg = NULL;
+    ctx->tx_pg = NULL;
+    ctx->page_count = 0;
+    ctx->rx_is_free = false;
+}
+
+uint32_t ffa_handle_rxtx_unmap(void)
+{
+    struct domain *d = current->domain;
+    struct ffa_ctx *ctx = d->arch.tee;
+
+    if ( !ctx->rx )
+        return FFA_RET_INVALID_PARAMETERS;
+
+    rxtx_unmap(ctx);
+
+    return FFA_RET_OK;
+}
+
+int32_t ffa_handle_rx_release(void)
+{
+    int32_t ret = FFA_RET_DENIED;
+    struct domain *d = current->domain;
+    struct ffa_ctx *ctx = d->arch.tee;
+
+    if ( !spin_trylock(&ctx->rx_lock) )
+        return FFA_RET_BUSY;
+
+    if ( !ctx->page_count || ctx->rx_is_free )
+        goto out;
+    ret = FFA_RET_OK;
+    ctx->rx_is_free = true;
+out:
+    spin_unlock(&ctx->rx_lock);
+
+    return ret;
+}
+
+static int32_t ffa_rxtx_map(paddr_t tx_addr, paddr_t rx_addr,
+                            uint32_t page_count)
+{
+    return ffa_simple_call(FFA_RXTX_MAP_64, tx_addr, rx_addr, page_count, 0);
+}
+
+static int32_t ffa_rxtx_unmap(void)
+{
+    return ffa_simple_call(FFA_RXTX_UNMAP, 0, 0, 0, 0);
+}
+
+void ffa_rxtx_domain_destroy(struct domain *d)
+{
+    struct ffa_ctx *ctx = d->arch.tee;
+
+    if ( ctx->rx )
+        rxtx_unmap(ctx);
+}
+
+void ffa_rxtx_destroy(void)
+{
+    bool need_unmap = ffa_tx && ffa_rx;
+
+    if ( ffa_tx )
+    {
+        free_xenheap_pages(ffa_tx, 0);
+        ffa_tx = NULL;
+    }
+    if ( ffa_rx )
+    {
+        free_xenheap_pages(ffa_rx, 0);
+        ffa_rx = NULL;
+    }
+
+    if ( need_unmap )
+        ffa_rxtx_unmap();
+}
+
+bool ffa_rxtx_init(void)
+{
+    int e;
+
+    ffa_rx = alloc_xenheap_pages(get_order_from_pages(FFA_RXTX_PAGE_COUNT), 0);
+    if ( !ffa_rx )
+        return false;
+
+    ffa_tx = alloc_xenheap_pages(get_order_from_pages(FFA_RXTX_PAGE_COUNT), 0);
+    if ( !ffa_tx )
+        goto err;
+
+    e = ffa_rxtx_map(__pa(ffa_tx), __pa(ffa_rx), FFA_RXTX_PAGE_COUNT);
+    if ( e )
+    {
+        printk(XENLOG_ERR "ffa: Failed to map rxtx: error %d\n", e);
+        goto err;
+    }
+    return true;
+
+err:
+    ffa_rxtx_destroy();
+
+    return false;
+}
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Mon Mar 25 09:39:18 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 09:39:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697651.1088640 (Exim 4.92)
	(envelope-from )
	id 1rognW-00027I-SY; Mon, 25 Mar 2024 09:39:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697651.1088640; Mon, 25 Mar 2024 09:39:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rognW-00025R-Mt; Mon, 25 Mar 2024 09:39:18 +0000
Received: by outflank-mailman (input) for mailman id 697651;
 Mon, 25 Mar 2024 09:39:17 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rognU-0001fs-Tg
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 09:39:17 +0000
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com
 [2a00:1450:4864:20::631])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8aab2411-ea8b-11ee-a1ef-f123f15fe8a2;
 Mon, 25 Mar 2024 10:39:14 +0100 (CET)
Received: by mail-ej1-x631.google.com with SMTP id
 a640c23a62f3a-a46dd7b4bcbso502636966b.3
 for ; Mon, 25 Mar 2024 02:39:14 -0700 (PDT)
Received: from rayden.urgonet (h-217-31-164-171.A175.priv.bahnhof.se.
 [217.31.164.171]) by smtp.gmail.com with ESMTPSA id
 bw26-20020a170906c1da00b00a4650ec48d0sm2891067ejb.140.2024.03.25.02.39.12
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 25 Mar 2024 02:39:12 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8aab2411-ea8b-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1711359554; x=1711964354; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=PzsRxNmHMhveXO5ZjFcn97aQMNBLyTGR+eqStIm9hyM=;
        b=rr5WKUBA02YLv9EjwUfd131Nma4cHflQPJihm+rK41c4eUNdM+rgRHFMXxZGH/ezeN
         zaNxqEi86IWNlFsZWKQQJ5zoMnA0bC1W9g5rE+Nr++J2Ql+enibZwJO1eUZ4F6Bfnvn6
         4eSOt5vw7GqP3yI0OgOt7qgRujklIwCG3Mty5MCHXLOexq+IAN/LtDiKCDq7TYpZMqS8
         inVC0rbvG1LqVtjaYXZ7tzaf1pQxcyYFpjMRVM8fjVsCBcL2kQtzayoDUNcsIqXcFnQJ
         pYEbSF6LIwXfQpcOatknI0qXsWiXrVU1NpTgyexu2Ed7nG9KSolFyFtQjABY2q1IOxFv
         BwZw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711359554; x=1711964354;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=PzsRxNmHMhveXO5ZjFcn97aQMNBLyTGR+eqStIm9hyM=;
        b=HZT7+GSuEgCINGcW9KvJNAPShkcukTIUwoJtVNTVr2jFqdelf/icdCPGjtLeP0N01l
         clzCyr4EZvCQfDPYIUIDs0Avb1wq1Z87JCiLeOEtYkYxMUyEHpkqXQgwCZ8mp5Xybq4w
         Wk5L/MhyfZ08v/hO5dwHMhjQU4IL3G704QLe73kwKDtjyGqtVM36SfiXjt9VqYxqyTR3
         b/xWoK+omRi6NRRCegaq51rupEN5PX/Wm591R82San9oPJR9Rpz7ne0fiah/kmfK9GZr
         Mn6uoAh79XNDhfkqBuiWHKCrZPxqxIEciG3vyLUp13LNlcV2sxLuXu5hhhlSWXTUUXce
         S4FA==
X-Gm-Message-State: AOJu0Yxm2t5mWdWi8VHWjsa9vCFKGWbpcmaybk3dqc1h8MAGXb7X73U0
	WFk9U3TMyhrp4lLaaJhMeSdPZX55MedR4HwpkQlKreQ6uGkwT+e7JtjkJKz3E+whKkbXIcXxiQr
	y
X-Google-Smtp-Source: AGHT+IHh5mGkgaIVnascEeRce7dQf+zvLCaRAKvMxcd/yEHFecAID8bjugZZ7vmws1WWtbw8XLtUjg==
X-Received: by 2002:a17:906:2a07:b0:a47:ea3:9a09 with SMTP id j7-20020a1709062a0700b00a470ea39a09mr4201697eje.46.1711359553364;
        Mon, 25 Mar 2024 02:39:13 -0700 (PDT)
From: Jens Wiklander 
To: xen-devel@lists.xenproject.org
Cc: patches@linaro.org,
	Jens Wiklander ,
	Volodymyr Babchuk ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel 
Subject: [XEN PATCH 4/6] xen/arm: ffa: separate partition info get routines
Date: Mon, 25 Mar 2024 10:39:02 +0100
Message-Id: <20240325093904.3466092-5-jens.wiklander@linaro.org>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20240325093904.3466092-1-jens.wiklander@linaro.org>
References: <20240325093904.3466092-1-jens.wiklander@linaro.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Move partition info get routines into a separate file for easier
navigation in the source code.

Add ffa_partinfo_init(), ffa_partinfo_domain_init(), and
ffa_partinfo_domain_destroy() to handle the ffa_partinfo internal things
on initialization and teardown.

Signed-off-by: Jens Wiklander 
---
 xen/arch/arm/tee/Makefile       |   1 +
 xen/arch/arm/tee/ffa.c          | 359 +-----------------------------
 xen/arch/arm/tee/ffa_partinfo.c | 373 ++++++++++++++++++++++++++++++++
 xen/arch/arm/tee/ffa_private.h  |  14 +-
 4 files changed, 398 insertions(+), 349 deletions(-)
 create mode 100644 xen/arch/arm/tee/ffa_partinfo.c

diff --git a/xen/arch/arm/tee/Makefile b/xen/arch/arm/tee/Makefile
index 0e683d23aa9d..be644fba8055 100644
--- a/xen/arch/arm/tee/Makefile
+++ b/xen/arch/arm/tee/Makefile
@@ -1,4 +1,5 @@
 obj-$(CONFIG_FFA) += ffa.o
 obj-$(CONFIG_FFA) += ffa_shm.o
+obj-$(CONFIG_FFA) += ffa_partinfo.o
 obj-y += tee.o
 obj-$(CONFIG_OPTEE) += optee.o
diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
index db36292dc52f..7a2803881420 100644
--- a/xen/arch/arm/tee/ffa.c
+++ b/xen/arch/arm/tee/ffa.c
@@ -70,20 +70,6 @@
  * structs ending with _1_1 are defined in FF-A-1.1-REL0.
  */
 
-/* Partition information descriptor */
-struct ffa_partition_info_1_0 {
-    uint16_t id;
-    uint16_t execution_context;
-    uint32_t partition_properties;
-};
-
-struct ffa_partition_info_1_1 {
-    uint16_t id;
-    uint16_t execution_context;
-    uint32_t partition_properties;
-    uint8_t uuid[16];
-};
-
 /* Endpoint RX/TX descriptor */
 struct ffa_endpoint_rxtx_descriptor_1_0 {
     uint16_t sender_id;
@@ -102,11 +88,6 @@ struct ffa_endpoint_rxtx_descriptor_1_1 {
 /* Negotiated FF-A version to use with the SPMC */
 static uint32_t __ro_after_init ffa_version;
 
-/* SPs subscribing to VM_CREATE and VM_DESTROYED events */
-static uint16_t *subscr_vm_created __read_mostly;
-static uint16_t subscr_vm_created_count __read_mostly;
-static uint16_t *subscr_vm_destroyed __read_mostly;
-static uint16_t subscr_vm_destroyed_count __read_mostly;
 
 /*
  * Our rx/tx buffers shared with the SPMC. FFA_RXTX_PAGE_COUNT is the
@@ -170,90 +151,6 @@ static int32_t ffa_rxtx_map(paddr_t tx_addr, paddr_t rx_addr,
     return ffa_simple_call(FFA_RXTX_MAP_64, tx_addr, rx_addr, page_count, 0);
 }
 
-static int32_t ffa_partition_info_get(uint32_t w1, uint32_t w2, uint32_t w3,
-                                      uint32_t w4, uint32_t w5,
-                                      uint32_t *count, uint32_t *fpi_size)
-{
-    const struct arm_smccc_1_2_regs arg = {
-        .a0 = FFA_PARTITION_INFO_GET,
-        .a1 = w1,
-        .a2 = w2,
-        .a3 = w3,
-        .a4 = w4,
-        .a5 = w5,
-    };
-    struct arm_smccc_1_2_regs resp;
-    uint32_t ret;
-
-    arm_smccc_1_2_smc(&arg, &resp);
-
-    ret = ffa_get_ret_code(&resp);
-    if ( !ret )
-    {
-        *count = resp.a2;
-        *fpi_size = resp.a3;
-    }
-
-    return ret;
-}
-
-static int32_t ffa_rx_release(void)
-{
-    return ffa_simple_call(FFA_RX_RELEASE, 0, 0, 0, 0);
-}
-
-static int32_t ffa_direct_req_send_vm(uint16_t sp_id, uint16_t vm_id,
-                                      uint8_t msg)
-{
-    uint32_t exp_resp = FFA_MSG_FLAG_FRAMEWORK;
-    unsigned int retry_count = 0;
-    int32_t res;
-
-    if ( msg == FFA_MSG_SEND_VM_CREATED )
-        exp_resp |= FFA_MSG_RESP_VM_CREATED;
-    else if ( msg == FFA_MSG_SEND_VM_DESTROYED )
-        exp_resp |= FFA_MSG_RESP_VM_DESTROYED;
-    else
-        return FFA_RET_INVALID_PARAMETERS;
-
-    do {
-        const struct arm_smccc_1_2_regs arg = {
-            .a0 = FFA_MSG_SEND_DIRECT_REQ_32,
-            .a1 = sp_id,
-            .a2 = FFA_MSG_FLAG_FRAMEWORK | msg,
-            .a5 = vm_id,
-        };
-        struct arm_smccc_1_2_regs resp;
-
-        arm_smccc_1_2_smc(&arg, &resp);
-        if ( resp.a0 != FFA_MSG_SEND_DIRECT_RESP_32 || resp.a2 != exp_resp )
-        {
-            /*
-             * This is an invalid response, likely due to some error in the
-             * implementation of the ABI.
-             */
-            return FFA_RET_INVALID_PARAMETERS;
-        }
-        res = resp.a3;
-        if ( ++retry_count > 10 )
-        {
-            /*
-             * TODO
-             * FFA_RET_INTERRUPTED means that the SPMC has a pending
-             * non-secure interrupt, we need a way of delivering that
-             * non-secure interrupt.
-             * FFA_RET_RETRY is the SP telling us that it's temporarily
-             * blocked from handling the direct request, we need a generic
-             * way to deal with this.
-             * For now in both cases, give up after a few retries.
-             */
-            return res;
-        }
-    } while ( res == FFA_RET_INTERRUPTED || res == FFA_RET_RETRY );
-
-    return res;
-}
-
 static void handle_version(struct cpu_user_regs *regs)
 {
     struct domain *d = current->domain;
@@ -371,88 +268,6 @@ static uint32_t ffa_handle_rxtx_unmap(void)
     return FFA_RET_OK;
 }
 
-static int32_t ffa_handle_partition_info_get(uint32_t w1, uint32_t w2,
-                                             uint32_t w3, uint32_t w4,
-                                             uint32_t w5, uint32_t *count,
-                                             uint32_t *fpi_size)
-{
-    int32_t ret = FFA_RET_DENIED;
-    struct domain *d = current->domain;
-    struct ffa_ctx *ctx = d->arch.tee;
-
-    /*
-     * FF-A v1.0 has w5 MBZ while v1.1 allows
-     * FFA_PARTITION_INFO_GET_COUNT_FLAG to be non-zero.
-     *
-     * FFA_PARTITION_INFO_GET_COUNT is only using registers and not the
-     * rxtx buffer so do the partition_info_get directly.
-     */
-    if ( w5 == FFA_PARTITION_INFO_GET_COUNT_FLAG &&
-         ctx->guest_vers == FFA_VERSION_1_1 )
-        return ffa_partition_info_get(w1, w2, w3, w4, w5, count, fpi_size);
-    if ( w5 )
-        return FFA_RET_INVALID_PARAMETERS;
-
-    if ( !ffa_rx )
-        return FFA_RET_DENIED;
-
-    if ( !spin_trylock(&ctx->rx_lock) )
-        return FFA_RET_BUSY;
-
-    if ( !ctx->page_count || !ctx->rx_is_free )
-        goto out;
-    spin_lock(&ffa_rx_buffer_lock);
-    ret = ffa_partition_info_get(w1, w2, w3, w4, w5, count, fpi_size);
-    if ( ret )
-        goto out_rx_buf_unlock;
-    /*
-     * ffa_partition_info_get() succeeded so we now own the RX buffer we
-     * share with the SPMC. We must give it back using ffa_rx_release()
-     * once we've copied the content.
-     */
-
-    if ( ctx->guest_vers == FFA_VERSION_1_0 )
-    {
-        size_t n;
-        struct ffa_partition_info_1_1 *src = ffa_rx;
-        struct ffa_partition_info_1_0 *dst = ctx->rx;
-
-        if ( ctx->page_count * FFA_PAGE_SIZE < *count * sizeof(*dst) )
-        {
-            ret = FFA_RET_NO_MEMORY;
-            goto out_rx_release;
-        }
-
-        for ( n = 0; n < *count; n++ )
-        {
-            dst[n].id = src[n].id;
-            dst[n].execution_context = src[n].execution_context;
-            dst[n].partition_properties = src[n].partition_properties;
-        }
-    }
-    else
-    {
-        size_t sz = *count * *fpi_size;
-
-        if ( ctx->page_count * FFA_PAGE_SIZE < sz )
-        {
-            ret = FFA_RET_NO_MEMORY;
-            goto out_rx_release;
-        }
-
-        memcpy(ctx->rx, ffa_rx, sz);
-    }
-    ctx->rx_is_free = false;
-out_rx_release:
-    ffa_rx_release();
-out_rx_buf_unlock:
-    spin_unlock(&ffa_rx_buffer_lock);
-out:
-    spin_unlock(&ctx->rx_lock);
-
-    return ret;
-}
-
 static int32_t ffa_handle_rx_release(void)
 {
     int32_t ret = FFA_RET_DENIED;
@@ -604,46 +419,9 @@ static bool ffa_handle_call(struct cpu_user_regs *regs)
     }
 }
 
-static bool is_in_subscr_list(const uint16_t *subscr, uint16_t start,
-                              uint16_t end, uint16_t sp_id)
-{
-    unsigned int n;
-
-    for ( n = start; n < end; n++ )
-    {
-        if ( subscr[n] == sp_id )
-            return true;
-    }
-
-    return false;
-}
-
-static void vm_destroy_bitmap_init(struct ffa_ctx *ctx,
-                                   unsigned int create_signal_count)
-{
-    unsigned int n;
-
-    for ( n = 0; n < subscr_vm_destroyed_count; n++ )
-    {
-        /*
-         * Skip SPs subscribed to the VM created event that never was
-         * notified of the VM creation due to an error during
-         * ffa_domain_init().
-         */
-        if ( is_in_subscr_list(subscr_vm_created, create_signal_count,
-                               subscr_vm_created_count,
-                               subscr_vm_destroyed[n]) )
-            continue;
-
-        set_bit(n, ctx->vm_destroy_bitmap);
-    }
-}
-
 static int ffa_domain_init(struct domain *d)
 {
     struct ffa_ctx *ctx;
-    unsigned int n;
-    int32_t res;
 
     if ( !ffa_version )
         return -ENODEV;
@@ -654,8 +432,7 @@ static int ffa_domain_init(struct domain *d)
     if ( d->domain_id >= UINT16_MAX)
         return -ERANGE;
 
-    ctx = xzalloc_flex_struct(struct ffa_ctx, vm_destroy_bitmap,
-                              BITS_TO_LONGS(subscr_vm_destroyed_count));
+    ctx = xzalloc(struct ffa_ctx);
     if ( !ctx )
         return -ENOMEM;
 
@@ -663,66 +440,28 @@ static int ffa_domain_init(struct domain *d)
     ctx->teardown_d = d;
     INIT_LIST_HEAD(&ctx->shm_list);
 
-    for ( n = 0; n < subscr_vm_created_count; n++ )
-    {
-        res = ffa_direct_req_send_vm(subscr_vm_created[n], ffa_get_vm_id(d),
-                                     FFA_MSG_SEND_VM_CREATED);
-        if ( res )
-        {
-            printk(XENLOG_ERR "ffa: Failed to report creation of vm_id %u to  %u: res %d\n",
-                   ffa_get_vm_id(d), subscr_vm_created[n], res);
-            break;
-        }
-    }
-    vm_destroy_bitmap_init(ctx, n);
-    if ( n != subscr_vm_created_count )
+    /*
+     * ffa_domain_teardown() will be called if ffa_domain_init() returns an
+     * error, so no need for cleanup in this function.
+     */
+
+    if ( !ffa_partinfo_domain_init(d) )
         return -EIO;
 
     return 0;
 }
 
-static void send_vm_destroyed(struct domain *d)
-{
-    struct ffa_ctx *ctx = d->arch.tee;
-    unsigned int n;
-    int32_t res;
-
-    for ( n = 0; n < subscr_vm_destroyed_count; n++ )
-    {
-        if ( !test_bit(n, ctx->vm_destroy_bitmap) )
-            continue;
-
-        res = ffa_direct_req_send_vm(subscr_vm_destroyed[n], ffa_get_vm_id(d),
-                                     FFA_MSG_SEND_VM_DESTROYED);
-
-        if ( res )
-        {
-            printk(XENLOG_ERR "%pd: ffa: Failed to report destruction of vm_id %u to %u: res %d\n",
-                   d, ffa_get_vm_id(d), subscr_vm_destroyed[n], res);
-        }
-
-        /*
-         * For these two error codes the hypervisor is expected to resend
-         * the destruction message. For the rest it is expected that the
-         * error is permanent and that is doesn't help to resend the
-         * destruction message.
-         */
-        if ( res != FFA_RET_INTERRUPTED && res != FFA_RET_RETRY )
-            clear_bit(n, ctx->vm_destroy_bitmap);
-    }
-}
-
 static void ffa_domain_teardown_continue(struct ffa_ctx *ctx, bool first_time)
 {
     struct ffa_ctx *next_ctx = NULL;
     bool retry = false;
 
-    send_vm_destroyed(ctx->teardown_d);
+    if ( !ffa_partinfo_domain_destroy(ctx->teardown_d) )
+        retry = true;
     if ( !ffa_shm_domain_destroy(ctx->teardown_d) )
         retry = true;
 
-    if ( retry ||
-         !bitmap_empty(ctx->vm_destroy_bitmap, subscr_vm_destroyed_count) )
+    if ( retry )
     {
         printk(XENLOG_G_INFO "%pd: ffa: Remaining cleanup, retrying\n", ctx->teardown_d);
 
@@ -796,82 +535,6 @@ static int ffa_relinquish_resources(struct domain *d)
     return 0;
 }
 
-static void uninit_subscribers(void)
-{
-        subscr_vm_created_count = 0;
-        subscr_vm_destroyed_count = 0;
-        XFREE(subscr_vm_created);
-        XFREE(subscr_vm_destroyed);
-}
-
-static bool init_subscribers(struct ffa_partition_info_1_1 *fpi, uint16_t count)
-{
-    uint16_t n;
-    uint16_t c_pos;
-    uint16_t d_pos;
-
-    subscr_vm_created_count = 0;
-    subscr_vm_destroyed_count = 0;
-    for ( n = 0; n < count; n++ )
-    {
-        if ( fpi[n].partition_properties & FFA_PART_PROP_NOTIF_CREATED )
-            subscr_vm_created_count++;
-        if ( fpi[n].partition_properties & FFA_PART_PROP_NOTIF_DESTROYED )
-            subscr_vm_destroyed_count++;
-    }
-
-    if ( subscr_vm_created_count )
-        subscr_vm_created = xzalloc_array(uint16_t, subscr_vm_created_count);
-    if ( subscr_vm_destroyed_count )
-        subscr_vm_destroyed = xzalloc_array(uint16_t,
-                                            subscr_vm_destroyed_count);
-    if ( (subscr_vm_created_count && !subscr_vm_created) ||
-         (subscr_vm_destroyed_count && !subscr_vm_destroyed) )
-    {
-        printk(XENLOG_ERR "ffa: Failed to allocate subscription lists\n");
-        uninit_subscribers();
-        return false;
-    }
-
-    for ( c_pos = 0, d_pos = 0, n = 0; n < count; n++ )
-    {
-        if ( fpi[n].partition_properties & FFA_PART_PROP_NOTIF_CREATED )
-            subscr_vm_created[c_pos++] = fpi[n].id;
-        if ( fpi[n].partition_properties & FFA_PART_PROP_NOTIF_DESTROYED )
-            subscr_vm_destroyed[d_pos++] = fpi[n].id;
-    }
-
-    return true;
-}
-
-static bool init_sps(void)
-{
-    bool ret = false;
-    uint32_t fpi_size;
-    uint32_t count;
-    int e;
-
-    e = ffa_partition_info_get(0, 0, 0, 0, 0, &count, &fpi_size);
-    if ( e )
-    {
-        printk(XENLOG_ERR "ffa: Failed to get list of SPs: %d\n", e);
-        goto out;
-    }
-
-    if ( count >= UINT16_MAX )
-    {
-        printk(XENLOG_ERR "ffa: Impossible number of SPs: %u\n", count);
-        goto out;
-    }
-
-    ret = init_subscribers(ffa_rx, count);
-
-out:
-    ffa_rx_release();
-
-    return ret;
-}
-
 static bool ffa_probe(void)
 {
     uint32_t vers;
@@ -949,7 +612,7 @@ static bool ffa_probe(void)
     }
     ffa_version = vers;
 
-    if ( !init_sps() )
+    if ( !ffa_partinfo_init() )
         goto err_free_ffa_tx;
 
     INIT_LIST_HEAD(&ffa_teardown_head);
diff --git a/xen/arch/arm/tee/ffa_partinfo.c b/xen/arch/arm/tee/ffa_partinfo.c
new file mode 100644
index 000000000000..dc1059584828
--- /dev/null
+++ b/xen/arch/arm/tee/ffa_partinfo.c
@@ -0,0 +1,373 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2024  Linaro Limited
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include "ffa_private.h"
+
+/* Partition information descriptor defined in FF-A-1.0-REL */
+struct ffa_partition_info_1_0 {
+    uint16_t id;
+    uint16_t execution_context;
+    uint32_t partition_properties;
+};
+
+/* Partition information descriptor defined in FF-A-1.1-REL0 */
+struct ffa_partition_info_1_1 {
+    uint16_t id;
+    uint16_t execution_context;
+    uint32_t partition_properties;
+    uint8_t uuid[16];
+};
+
+/* SPs subscribing to VM_CREATE and VM_DESTROYED events */
+static uint16_t *subscr_vm_created __read_mostly;
+static uint16_t subscr_vm_created_count __read_mostly;
+static uint16_t *subscr_vm_destroyed __read_mostly;
+static uint16_t subscr_vm_destroyed_count __read_mostly;
+
+static int32_t ffa_partition_info_get(uint32_t w1, uint32_t w2, uint32_t w3,
+                                      uint32_t w4, uint32_t w5, uint32_t *count,
+                                      uint32_t *fpi_size)
+{
+    const struct arm_smccc_1_2_regs arg = {
+        .a0 = FFA_PARTITION_INFO_GET,
+        .a1 = w1,
+        .a2 = w2,
+        .a3 = w3,
+        .a4 = w4,
+        .a5 = w5,
+    };
+    struct arm_smccc_1_2_regs resp;
+    uint32_t ret;
+
+    arm_smccc_1_2_smc(&arg, &resp);
+
+    ret = ffa_get_ret_code(&resp);
+    if ( !ret )
+    {
+        *count = resp.a2;
+        *fpi_size = resp.a3;
+    }
+
+    return ret;
+}
+
+int32_t ffa_handle_partition_info_get(uint32_t w1, uint32_t w2, uint32_t w3,
+                                      uint32_t w4, uint32_t w5, uint32_t *count,
+                                      uint32_t *fpi_size)
+{
+    int32_t ret = FFA_RET_DENIED;
+    struct domain *d = current->domain;
+    struct ffa_ctx *ctx = d->arch.tee;
+
+    /*
+     * FF-A v1.0 has w5 MBZ while v1.1 allows
+     * FFA_PARTITION_INFO_GET_COUNT_FLAG to be non-zero.
+     *
+     * FFA_PARTITION_INFO_GET_COUNT is only using registers and not the
+     * rxtx buffer so do the partition_info_get directly.
+     */
+    if ( w5 == FFA_PARTITION_INFO_GET_COUNT_FLAG &&
+         ctx->guest_vers == FFA_VERSION_1_1 )
+        return ffa_partition_info_get(w1, w2, w3, w4, w5, count, fpi_size);
+    if ( w5 )
+        return FFA_RET_INVALID_PARAMETERS;
+
+    if ( !ffa_rx )
+        return FFA_RET_DENIED;
+
+    if ( !spin_trylock(&ctx->rx_lock) )
+        return FFA_RET_BUSY;
+
+    if ( !ctx->page_count || !ctx->rx_is_free )
+        goto out;
+    spin_lock(&ffa_rx_buffer_lock);
+    ret = ffa_partition_info_get(w1, w2, w3, w4, w5, count, fpi_size);
+    if ( ret )
+        goto out_rx_buf_unlock;
+    /*
+     * ffa_partition_info_get() succeeded so we now own the RX buffer we
+     * share with the SPMC. We must give it back using ffa_rx_release()
+     * once we've copied the content.
+     */
+
+    if ( ctx->guest_vers == FFA_VERSION_1_0 )
+    {
+        size_t n;
+        struct ffa_partition_info_1_1 *src = ffa_rx;
+        struct ffa_partition_info_1_0 *dst = ctx->rx;
+
+        if ( ctx->page_count * FFA_PAGE_SIZE < *count * sizeof(*dst) )
+        {
+            ret = FFA_RET_NO_MEMORY;
+            goto out_rx_release;
+        }
+
+        for ( n = 0; n < *count; n++ )
+        {
+            dst[n].id = src[n].id;
+            dst[n].execution_context = src[n].execution_context;
+            dst[n].partition_properties = src[n].partition_properties;
+        }
+    }
+    else
+    {
+        size_t sz = *count * *fpi_size;
+
+        if ( ctx->page_count * FFA_PAGE_SIZE < sz )
+        {
+            ret = FFA_RET_NO_MEMORY;
+            goto out_rx_release;
+        }
+
+        memcpy(ctx->rx, ffa_rx, sz);
+    }
+    ctx->rx_is_free = false;
+out_rx_release:
+    ffa_rx_release();
+out_rx_buf_unlock:
+    spin_unlock(&ffa_rx_buffer_lock);
+out:
+    spin_unlock(&ctx->rx_lock);
+
+    return ret;
+}
+
+static int32_t ffa_direct_req_send_vm(uint16_t sp_id, uint16_t vm_id,
+                                      uint8_t msg)
+{
+    uint32_t exp_resp = FFA_MSG_FLAG_FRAMEWORK;
+    unsigned int retry_count = 0;
+    int32_t res;
+
+    if ( msg == FFA_MSG_SEND_VM_CREATED )
+        exp_resp |= FFA_MSG_RESP_VM_CREATED;
+    else if ( msg == FFA_MSG_SEND_VM_DESTROYED )
+        exp_resp |= FFA_MSG_RESP_VM_DESTROYED;
+    else
+        return FFA_RET_INVALID_PARAMETERS;
+
+    do {
+        const struct arm_smccc_1_2_regs arg = {
+            .a0 = FFA_MSG_SEND_DIRECT_REQ_32,
+            .a1 = sp_id,
+            .a2 = FFA_MSG_FLAG_FRAMEWORK | msg,
+            .a5 = vm_id,
+        };
+        struct arm_smccc_1_2_regs resp;
+
+        arm_smccc_1_2_smc(&arg, &resp);
+        if ( resp.a0 != FFA_MSG_SEND_DIRECT_RESP_32 || resp.a2 != exp_resp )
+        {
+            /*
+             * This is an invalid response, likely due to some error in the
+             * implementation of the ABI.
+             */
+            return FFA_RET_INVALID_PARAMETERS;
+        }
+        res = resp.a3;
+        if ( ++retry_count > 10 )
+        {
+            /*
+             * TODO
+             * FFA_RET_INTERRUPTED means that the SPMC has a pending
+             * non-secure interrupt, we need a way of delivering that
+             * non-secure interrupt.
+             * FFA_RET_RETRY is the SP telling us that it's temporarily
+             * blocked from handling the direct request, we need a generic
+             * way to deal with this.
+             * For now in both cases, give up after a few retries.
+             */
+            return res;
+        }
+    } while ( res == FFA_RET_INTERRUPTED || res == FFA_RET_RETRY );
+
+    return res;
+}
+
+static void uninit_subscribers(void)
+{
+        subscr_vm_created_count = 0;
+        subscr_vm_destroyed_count = 0;
+        XFREE(subscr_vm_created);
+        XFREE(subscr_vm_destroyed);
+}
+
+static bool init_subscribers(struct ffa_partition_info_1_1 *fpi, uint16_t count)
+{
+    uint16_t n;
+    uint16_t c_pos;
+    uint16_t d_pos;
+
+    subscr_vm_created_count = 0;
+    subscr_vm_destroyed_count = 0;
+    for ( n = 0; n < count; n++ )
+    {
+        if ( fpi[n].partition_properties & FFA_PART_PROP_NOTIF_CREATED )
+            subscr_vm_created_count++;
+        if ( fpi[n].partition_properties & FFA_PART_PROP_NOTIF_DESTROYED )
+            subscr_vm_destroyed_count++;
+    }
+
+    if ( subscr_vm_created_count )
+        subscr_vm_created = xzalloc_array(uint16_t, subscr_vm_created_count);
+    if ( subscr_vm_destroyed_count )
+        subscr_vm_destroyed = xzalloc_array(uint16_t,
+                                            subscr_vm_destroyed_count);
+    if ( (subscr_vm_created_count && !subscr_vm_created) ||
+         (subscr_vm_destroyed_count && !subscr_vm_destroyed) )
+    {
+        printk(XENLOG_ERR "ffa: Failed to allocate subscription lists\n");
+        uninit_subscribers();
+        return false;
+    }
+
+    for ( c_pos = 0, d_pos = 0, n = 0; n < count; n++ )
+    {
+        if ( fpi[n].partition_properties & FFA_PART_PROP_NOTIF_CREATED )
+            subscr_vm_created[c_pos++] = fpi[n].id;
+        if ( fpi[n].partition_properties & FFA_PART_PROP_NOTIF_DESTROYED )
+            subscr_vm_destroyed[d_pos++] = fpi[n].id;
+    }
+
+    return true;
+}
+
+
+
+bool ffa_partinfo_init(void)
+{
+    bool ret = false;
+    uint32_t fpi_size;
+    uint32_t count;
+    int e;
+
+    e = ffa_partition_info_get(0, 0, 0, 0, 0, &count, &fpi_size);
+    if ( e )
+    {
+        printk(XENLOG_ERR "ffa: Failed to get list of SPs: %d\n", e);
+        goto out;
+    }
+
+    if ( count >= UINT16_MAX )
+    {
+        printk(XENLOG_ERR "ffa: Impossible number of SPs: %u\n", count);
+        goto out;
+    }
+
+    ret = init_subscribers(ffa_rx, count);
+
+out:
+    ffa_rx_release();
+
+    return ret;
+}
+
+static bool is_in_subscr_list(const uint16_t *subscr, uint16_t start,
+                              uint16_t end, uint16_t sp_id)
+{
+    unsigned int n;
+
+    for ( n = start; n < end; n++ )
+    {
+        if ( subscr[n] == sp_id )
+            return true;
+    }
+
+    return false;
+}
+
+static void vm_destroy_bitmap_init(struct ffa_ctx *ctx,
+                                   unsigned int create_signal_count)
+{
+    unsigned int n;
+
+    for ( n = 0; n < subscr_vm_destroyed_count; n++ )
+    {
+        /*
+         * Skip SPs subscribed to the VM created event that never was
+         * notified of the VM creation due to an error during
+         * ffa_domain_init().
+         */
+        if ( is_in_subscr_list(subscr_vm_created, create_signal_count,
+                               subscr_vm_created_count,
+                               subscr_vm_destroyed[n]) )
+            continue;
+
+        set_bit(n, ctx->vm_destroy_bitmap);
+    }
+}
+
+bool ffa_partinfo_domain_init(struct domain *d)
+{
+    unsigned int count = BITS_TO_LONGS(subscr_vm_destroyed_count);
+    struct ffa_ctx *ctx = d->arch.tee;
+    unsigned int n;
+    int32_t res;
+
+    ctx->vm_destroy_bitmap = xzalloc_array(unsigned long, count);
+    if ( !ctx->vm_destroy_bitmap )
+        return false;
+
+    for ( n = 0; n < subscr_vm_created_count; n++ )
+    {
+        res = ffa_direct_req_send_vm(subscr_vm_created[n], ffa_get_vm_id(d),
+                                     FFA_MSG_SEND_VM_CREATED);
+        if ( res )
+        {
+            printk(XENLOG_ERR "ffa: Failed to report creation of vm_id %u to  %u: res %d\n",
+                   ffa_get_vm_id(d), subscr_vm_created[n], res);
+            break;
+        }
+    }
+    vm_destroy_bitmap_init(ctx, n);
+
+    return n == subscr_vm_created_count;
+}
+
+bool ffa_partinfo_domain_destroy(struct domain *d)
+{
+    struct ffa_ctx *ctx = d->arch.tee;
+    unsigned int n;
+    int32_t res;
+
+    if ( !ctx->vm_destroy_bitmap )
+        return true;
+
+    for ( n = 0; n < subscr_vm_destroyed_count; n++ )
+    {
+        if ( !test_bit(n, ctx->vm_destroy_bitmap) )
+            continue;
+
+        res = ffa_direct_req_send_vm(subscr_vm_destroyed[n], ffa_get_vm_id(d),
+                                     FFA_MSG_SEND_VM_DESTROYED);
+
+        if ( res )
+        {
+            printk(XENLOG_ERR "%pd: ffa: Failed to report destruction of vm_id %u to %u: res %d\n",
+                   d, ffa_get_vm_id(d), subscr_vm_destroyed[n], res);
+        }
+
+        /*
+         * For these two error codes the hypervisor is expected to resend
+         * the destruction message. For the rest it is expected that the
+         * error is permanent and that is doesn't help to resend the
+         * destruction message.
+         */
+        if ( res != FFA_RET_INTERRUPTED && res != FFA_RET_RETRY )
+            clear_bit(n, ctx->vm_destroy_bitmap);
+    }
+
+    if ( bitmap_empty(ctx->vm_destroy_bitmap, subscr_vm_destroyed_count) )
+        XFREE(ctx->vm_destroy_bitmap);
+
+    return !ctx->vm_destroy_bitmap;
+}
diff --git a/xen/arch/arm/tee/ffa_private.h b/xen/arch/arm/tee/ffa_private.h
index f3e2f42e573e..6b32b69cfe90 100644
--- a/xen/arch/arm/tee/ffa_private.h
+++ b/xen/arch/arm/tee/ffa_private.h
@@ -244,7 +244,7 @@ struct ffa_ctx {
      * Used for ffa_domain_teardown() to keep track of which SPs should be
      * notified that this guest is being destroyed.
      */
-    unsigned long vm_destroy_bitmap[];
+    unsigned long *vm_destroy_bitmap;
 };
 
 extern void *ffa_rx;
@@ -256,6 +256,13 @@ bool ffa_shm_domain_destroy(struct domain *d);
 void ffa_handle_mem_share(struct cpu_user_regs *regs);
 int ffa_handle_mem_reclaim(uint64_t handle, uint32_t flags);
 
+bool ffa_partinfo_init(void);
+bool ffa_partinfo_domain_init(struct domain *d);
+bool ffa_partinfo_domain_destroy(struct domain *d);
+int32_t ffa_handle_partition_info_get(uint32_t w1, uint32_t w2, uint32_t w3,
+                                      uint32_t w4, uint32_t w5, uint32_t *count,
+                                      uint32_t *fpi_size);
+
 
 static inline uint16_t ffa_get_vm_id(const struct domain *d)
 {
@@ -325,4 +332,9 @@ static inline int32_t ffa_simple_call(uint32_t fid, register_t a1,
     return ffa_get_ret_code(&resp);
 }
 
+static inline int32_t ffa_rx_release(void)
+{
+    return ffa_simple_call(FFA_RX_RELEASE, 0, 0, 0, 0);
+}
+
 #endif /*__FFA_PRIVATE_H__*/
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Mon Mar 25 09:39:23 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 09:39:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697652.1088650 (Exim 4.92)
	(envelope-from )
	id 1rognX-0002Oo-Oy; Mon, 25 Mar 2024 09:39:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697652.1088650; Mon, 25 Mar 2024 09:39:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rognX-0002Nk-HK; Mon, 25 Mar 2024 09:39:19 +0000
Received: by outflank-mailman (input) for mailman id 697652;
 Mon, 25 Mar 2024 09:39:17 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rognV-000193-9s
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 09:39:17 +0000
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com
 [2a00:1450:4864:20::536])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8bbe3675-ea8b-11ee-afe3-a90da7624cb6;
 Mon, 25 Mar 2024 10:39:16 +0100 (CET)
Received: by mail-ed1-x536.google.com with SMTP id
 4fb4d7f45d1cf-56c0652d37aso1717002a12.0
 for ; Mon, 25 Mar 2024 02:39:16 -0700 (PDT)
Received: from rayden.urgonet (h-217-31-164-171.A175.priv.bahnhof.se.
 [217.31.164.171]) by smtp.gmail.com with ESMTPSA id
 bw26-20020a170906c1da00b00a4650ec48d0sm2891067ejb.140.2024.03.25.02.39.14
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 25 Mar 2024 02:39:15 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8bbe3675-ea8b-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1711359555; x=1711964355; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=R//dqaezYULgu2Zm/BSccIHOclqXeRZ8nf6tghKZQ5k=;
        b=qMYZmF6oVlXJqcG0QDCjjaSzW1Xgjn89xzHduMJ3p1I7irq19zN1tFgWeVyOo5uzK/
         u0beJcrkGD7KHQmsyWLafnUfUGPuptioju1gdlGch5n3PFkXAAr2Zzy8L6/jCHhDFHhk
         FlE1a0T8mhQ/grkWCvvsYuHXBtdMnUl+GSvoRpWhNAOo1dQfiioHmTPvKZ3aksUCJn4V
         t28JfW/jSsboV+3Ph5nWHwTd2iNptvE335tCzMjoqTVl2SXwjiWNtUr0eL7vjgh5bfUO
         EBj3WYJhn6W3KWekKYKSv5AAAc49wDwOj0zM+WBw4pL7vDeGGcPDk8tugXVKmHpHmxGS
         5Tsw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711359555; x=1711964355;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=R//dqaezYULgu2Zm/BSccIHOclqXeRZ8nf6tghKZQ5k=;
        b=jeRgnkzL2qWCx5zDpluExoqwAOxpXOMBWHjOG0s/bRTM9E0hyEF1GhcE5kTdrBhIak
         d+OeyVKRRvjYUrbcHFQmzYhOAJM1zRjeEtYD3V9ncLTVWAYtBSuf/kZ7rI8kUArjoB9/
         b0EheR/ygs4C5EDbW4GKIvxzpwI5aJGIrRwUmUaYszYGhnkmM9+vXDXH/6Je4D0WQ7y3
         tcJSZsGzBOb6ccSX6X3QDr2xtfzFzDvwIGC1hdko2a5uBVWJf1B5nGdgBoBh016FpsXJ
         ZMb183u7kdyahbiSfr0EhJqgCRV+8c5ym2+HBFwytR5BTNE7DX1YZeetB85XypiNdUtX
         PmRw==
X-Gm-Message-State: AOJu0Yy8au7oOFTQtF4Zb2ltoX4SvtCpOSe3sYWusAVpu4CkfYSL/+RX
	hkuA5aLR0oSqFDQkaYzP//kM1I+ZUKzyYeCj9mVG0vIfMoSnWecrwHtWgKcbAvT6lR+WGGbvCzD
	N
X-Google-Smtp-Source: AGHT+IHp+/+QUpPfntMFxFrKsbtXhYig9yZ1giP9wj9Kd44YJk/MCgWMOMMAmO3Q/Q0QMZLd9qU6Sw==
X-Received: by 2002:a17:906:4a12:b0:a47:3a99:87c with SMTP id w18-20020a1709064a1200b00a473a99087cmr4982726eju.18.1711359555664;
        Mon, 25 Mar 2024 02:39:15 -0700 (PDT)
From: Jens Wiklander 
To: xen-devel@lists.xenproject.org
Cc: patches@linaro.org,
	Jens Wiklander ,
	Volodymyr Babchuk ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel 
Subject: [XEN PATCH 6/6] xen/arm: ffa: support FFA_FEATURES
Date: Mon, 25 Mar 2024 10:39:04 +0100
Message-Id: <20240325093904.3466092-7-jens.wiklander@linaro.org>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20240325093904.3466092-1-jens.wiklander@linaro.org>
References: <20240325093904.3466092-1-jens.wiklander@linaro.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Add support for the mandatory FF-A ABI function FFA_FEATURES.

Signed-off-by: Jens Wiklander 
---
 xen/arch/arm/tee/ffa.c | 57 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 57 insertions(+)

diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
index 4f7775b8c890..8665201e34a9 100644
--- a/xen/arch/arm/tee/ffa.c
+++ b/xen/arch/arm/tee/ffa.c
@@ -192,6 +192,60 @@ out:
                  resp.a7 & mask);
 }
 
+static void handle_features(struct cpu_user_regs *regs)
+{
+    uint32_t a1 = get_user_reg(regs, 1);
+    unsigned int n;
+
+    for ( n = 2; n <= 7; n++ )
+    {
+        if ( get_user_reg(regs, n) )
+        {
+            ffa_set_regs_error(regs, FFA_RET_NOT_SUPPORTED);
+            return;
+        }
+    }
+
+    switch ( a1 )
+    {
+    case FFA_ERROR:
+    case FFA_VERSION:
+    case FFA_SUCCESS_32:
+    case FFA_SUCCESS_64:
+    case FFA_FEATURES:
+    case FFA_ID_GET:
+    case FFA_RX_RELEASE:
+    case FFA_RXTX_UNMAP:
+    case FFA_MEM_RECLAIM:
+    case FFA_PARTITION_INFO_GET:
+    case FFA_MSG_SEND_DIRECT_REQ_32:
+    case FFA_MSG_SEND_DIRECT_REQ_64:
+        ffa_set_regs_success(regs, 0, 0);
+        break;
+    case FFA_MEM_SHARE_64:
+    case FFA_MEM_SHARE_32:
+        /*
+         * We currently don't support dynamically allocated buffers. Report
+         * that with 0 in bit[0] of w2.
+         */
+        ffa_set_regs_success(regs, 0, 0);
+        break;
+    case FFA_RXTX_MAP_64:
+    case FFA_RXTX_MAP_32:
+        /*
+         * We currently support 4k pages only, report that as 00 in
+         * bit[0:1] in w0. This needs to be revised if Xen page size
+         * differs from FFA_PAGE_SIZE (SZ_4K).
+         */
+        BUILD_BUG_ON(PAGE_SIZE != FFA_PAGE_SIZE);
+        ffa_set_regs_success(regs, 0, 0);
+        break;
+    default:
+        ffa_set_regs_error(regs, FFA_RET_NOT_SUPPORTED);
+        break;
+    }
+}
+
 static bool ffa_handle_call(struct cpu_user_regs *regs)
 {
     uint32_t fid = get_user_reg(regs, 0);
@@ -212,6 +266,9 @@ static bool ffa_handle_call(struct cpu_user_regs *regs)
     case FFA_ID_GET:
         ffa_set_regs_success(regs, ffa_get_vm_id(d), 0);
         return true;
+    case FFA_FEATURES:
+        handle_features(regs);
+        return true;
     case FFA_RXTX_MAP_32:
     case FFA_RXTX_MAP_64:
         e = ffa_handle_rxtx_map(fid, get_user_reg(regs, 1),
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Mon Mar 25 10:11:41 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 10:11:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697680.1088689 (Exim 4.92)
	(envelope-from )
	id 1rohIe-00047B-8B; Mon, 25 Mar 2024 10:11:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697680.1088689; Mon, 25 Mar 2024 10:11:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rohIe-000474-5d; Mon, 25 Mar 2024 10:11:28 +0000
Received: by outflank-mailman (input) for mailman id 697680;
 Mon, 25 Mar 2024 10:11:27 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rohId-00046u-6Z; Mon, 25 Mar 2024 10:11:27 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rohId-0007WM-0c; Mon, 25 Mar 2024 10:11:27 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rohIc-0002K8-MY; Mon, 25 Mar 2024 10:11:26 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rohIc-0000Yt-MB; Mon, 25 Mar 2024 10:11:26 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=kYxl7vZ40ZJCf/p3IYhB3lYQt0v7VdKeOc1qE7LUU20=; b=GAIS9rHE8bxzYkc7NU3UJQUEWJ
	z0xtujfV6WjmtNreD0WwzZN+iCy6w8rds13f+cFcy017FCaLaNtCwmSSoTnvNg32LXxfKtgN8rxXS
	CHY5Jxdmq5QJH8mg2Tt6ztufcKKpl/+y2aDDPvsJHO2alRx7+bkh0qUWcRzyiy8jKh/Q=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [ovmf test] 185156: all pass - PUSHED
X-Osstest-Versions-This:
    ovmf=cf58f47623c40a66b160face4f04e08efb4c7f5b
X-Osstest-Versions-That:
    ovmf=7f1ffba5de3d9840dbeeba20fba165f2fb724941
From: osstest service owner 
Date: Mon, 25 Mar 2024 10:11:26 +0000

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf                 cf58f47623c40a66b160face4f04e08efb4c7f5b
baseline version:
 ovmf                 7f1ffba5de3d9840dbeeba20fba165f2fb724941

Last test of basis   185138  2024-03-22 05:12:55 Z    3 days
Testing same since   185156  2024-03-25 08:12:54 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Abdul Lateef Attar 

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-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   7f1ffba5de..cf58f47623  cf58f47623c40a66b160face4f04e08efb4c7f5b -> xen-tested-master


From xen-devel-bounces@lists.xenproject.org Mon Mar 25 10:17:23 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 10:17:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697683.1088700 (Exim 4.92)
	(envelope-from )
	id 1rohOI-0004hc-SO; Mon, 25 Mar 2024 10:17:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697683.1088700; Mon, 25 Mar 2024 10:17:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rohOI-0004hV-Pr; Mon, 25 Mar 2024 10:17:18 +0000
Received: by outflank-mailman (input) for mailman id 697683;
 Mon, 25 Mar 2024 10:17:17 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rohOH-0004hP-SX
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 10:17:17 +0000
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com
 [2a00:1450:4864:20::534])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id da6d4915-ea90-11ee-afe3-a90da7624cb6;
 Mon, 25 Mar 2024 11:17:15 +0100 (CET)
Received: by mail-ed1-x534.google.com with SMTP id
 4fb4d7f45d1cf-56c12c73ed8so917904a12.2
 for ; Mon, 25 Mar 2024 03:17:15 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 fd20-20020a056402389400b0056be0d1cd83sm2784122edb.97.2024.03.25.03.17.14
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 25 Mar 2024 03:17:15 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: da6d4915-ea90-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711361835; x=1711966635; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=jmhhDUrgoZx/6SWnfQp+/r4QZSDmInPKyhk3TTbH2e8=;
        b=PSYoiM/jCN4pgZ8wjaeK3LrlF7E2USlJWKs9NOUyd/Wdc7OgCty89SMpJmeqxBOEpm
         RAUwnYggP/KruaOtPsfaHrXqWl4CLiDd4S9is06FDY8kFyBRYo9FGp4wsZzf5GQ10e09
         o7ZfCQIidG12CypEa74El1XwKuHcN3q+Xr4ZigNCp/gDRe3+FwxTngSP2PfWuNtbcskh
         HRXIJH7MLjka3ZDjuwsgmXOI1+FNacRGC84c9fEcf/ro/mxdgURFl71SCKuMkt4wz0K4
         P8kBaD0xRqC9qLc0l5AT6ZSar/XsNfa1hPFw93lPexDe5Na8I4xwVNSGQ9vbcs3B6ZRK
         gO0g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711361835; x=1711966635;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=jmhhDUrgoZx/6SWnfQp+/r4QZSDmInPKyhk3TTbH2e8=;
        b=OrVS09cJlueyf+rfl92ancwi9t8eDrWZXHgopB5PELG5IzQFwbTzGl5bJ0y/RWur1N
         k1paK7d3/N/KY6xOXmT/oflKojZ3SA42u9/amvoGJMwHz2stUrUn7hKWreIoA688zuW2
         fRaSqQJSsERxeGQyPGHpfG+1Wkt5r2jBdDVONIjOu0oRDeYRNURLZth8vhvFqNhmFpj9
         iv1qmMvRW136lLoRDdlZO7vOQvobDlOeZgtaX3HiC7rVg3ynJEcw8D8v6FR10FN+ANPc
         iTit/bJ8jK8XYTyoTsCzQwU9Blvf2v8KkBt0e2TzhJnHsICBC34hMzRds7RnMqJM2i1A
         zAyw==
X-Forwarded-Encrypted: i=1; AJvYcCX0J8n806zznuaUJZBZGlWzCizOTAeSyV8G/96bDY0Qw5A5htraLVuClbA7BMp0OnrVvL0De8AVXimS0l+dCu0/nfUFnbY11qI3oYEjdWQ=
X-Gm-Message-State: AOJu0YzjGqN9HxIVNpof7CNI3Mo2jnFwF1IXiRN5ZuKUlAvp9hkJBSxM
	z8SMq/fhIMq+HmkMoecCSceH6RzF9NvvhEdKbkUDCPvMjakBhd4XyNDn+gSTHQ==
X-Google-Smtp-Source: AGHT+IG9jaBlqDOGuRNFZeSLQnIQfedFcTBXFJma0CZ9AaOTjuOE08MUzx96uK2t9Jhf0A9KH+HwoA==
X-Received: by 2002:a50:cdde:0:b0:56b:9162:8e6 with SMTP id h30-20020a50cdde000000b0056b916208e6mr4817414edj.18.1711361835492;
        Mon, 25 Mar 2024 03:17:15 -0700 (PDT)
Message-ID: <0aa5a1a8-2b7d-4cdd-bcf1-530bedcd09a9@suse.com>
Date: Mon, 25 Mar 2024 11:17:14 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/vcpu: relax VCPUOP_initialise restriction for non-PV
 vCPUs
Content-Language: en-US
To: Roger Pau Monne ,
 Andrew Cooper 
Cc: George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 xen-devel@lists.xenproject.org
References: <20240320135720.68894-1-roger.pau@citrix.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240320135720.68894-1-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 20.03.2024 14:57, Roger Pau Monne wrote:
> There's no reason to force HVM guests to have a valid vcpu_info area when
> initializing a vCPU, as the vCPU can also be brought online using the local
> APIC, and on that path there's no requirement for vcpu_info to be setup ahead
> of the bring up.  Note an HVM vCPU can operate normally without making use of
> vcpu_info.
> 
> Restrict the check against dummy_vcpu_info to only apply to PV guests.
> 
> Fixes: 192df6f9122d ('x86: allow HVM guests to use hypercalls to bring up vCPUs')
> Signed-off-by: Roger Pau Monné 

Despite the Fixes: tag I have to admit I'm uncertain of backporting here.
HVM guests need to be prepared anyway that they may be denied use of this
sub-op without first setting up vCPU info.

Jan



From xen-devel-bounces@lists.xenproject.org Mon Mar 25 10:31:54 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 10:31:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697687.1088710 (Exim 4.92)
	(envelope-from )
	id 1rohcI-0008Ss-W6; Mon, 25 Mar 2024 10:31:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697687.1088710; Mon, 25 Mar 2024 10:31:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rohcI-0008Sl-Se; Mon, 25 Mar 2024 10:31:46 +0000
Received: by outflank-mailman (input) for mailman id 697687;
 Mon, 25 Mar 2024 10:31:46 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rohcI-0008Sf-7t
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 10:31:46 +0000
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com
 [2a00:1450:4864:20::534])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e094ef5a-ea92-11ee-afe3-a90da7624cb6;
 Mon, 25 Mar 2024 11:31:45 +0100 (CET)
Received: by mail-ed1-x534.google.com with SMTP id
 4fb4d7f45d1cf-5684db9147dso4797588a12.2
 for ; Mon, 25 Mar 2024 03:31:45 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 r10-20020a508d8a000000b0056ba017ca7fsm2767231edh.87.2024.03.25.03.31.43
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 25 Mar 2024 03:31:44 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e094ef5a-ea92-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711362704; x=1711967504; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=kQ0545G1JCpez8HYFxvWrnz/2I+hE/zYwBuCVnrnlB4=;
        b=HwN0rgrsZf+06kaCkoHqc9Xo9b34dHxcD7QresPnvJlFMng4IjSU38HUeoBaLKJ1m2
         +W43qP8+63o9uwhuNV48SCFn4x+4mYHnJU2XvbTJ3X8N3F3CTKbyon74yKWFsjRCvJDL
         jf8Ki3MpAnIPZ7wy4gUwISwEqvwceIAF9NtAwu9LZsuU1Lxhz34YPzaJCKI5Qh8ge+Mj
         rWi2aaDscOeByPW7mnUp1LoS3dqgUItUEyj62uXSV/g8V3HkvNwJiyIcca3+ZXtai0W9
         gqaFEBUmUu1EdX360W9+syNxplKxc6IabO+oL+lppB+rb9jLT+2M1Gep90axdfBJO28i
         1rYA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711362704; x=1711967504;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=kQ0545G1JCpez8HYFxvWrnz/2I+hE/zYwBuCVnrnlB4=;
        b=ZeIZo+kcw8H8zv+t+Yjo9fcCh6AeSqalyl08LK3GlCjA9vreyT+MaXykWOjCqcXbud
         8myehuzcUPCKo2SOF2W5joCRtceUCbevddegbLwNM0VnMYWp0rHW2XCY7Ci5yomW4Mud
         /2kR697INY0k63MK+sSUcwaTsyXsliYB1iv0iAQK7MXm4uHarrG9QD+0WVzbjU8wl3dH
         hgCgGIuVgRZNQluNkJEWVzcClWCFq6Aw6xCIccsPdwcw3pIcTJgoJ4Ln1N/6pkTXHEpX
         z69Tf2WoT3RBBq92KiCRrw4AuDwcrM4S2XgyHkcEB7z+YlaHcO8EJNres+5moGzJ+PCV
         Uo2w==
X-Forwarded-Encrypted: i=1; AJvYcCWKhsMQa1ejstlhmI3UzC9k7T+a4Q17DRSLGwcRT+QsJ+qVlBHBjysOmdZIXb+BOdn846ZtDMRDBgjfbnGBbiv+2EpS9fJXMRLsDdqkoHQ=
X-Gm-Message-State: AOJu0Yy0+PJXgC76ZDb35PI0KlaF3i9BJx7G32snB289tJxNu/SS6bu0
	3QQzn9MOoa8FGGv+OkCFDPR+YknNwMk6paa6IPvPMZwb1NTdV+xwx7xxm07czA==
X-Google-Smtp-Source: AGHT+IEcp5ycQyo2VBcv3rPPJY3x14ECmy4D1uoWewt+ONQsu3yS4MB7MQi2DNmT/aI3pfzJxkDlJQ==
X-Received: by 2002:a05:6402:202a:b0:56c:be3:7cef with SMTP id ay10-20020a056402202a00b0056c0be37cefmr1924420edb.11.1711362704526;
        Mon, 25 Mar 2024 03:31:44 -0700 (PDT)
Message-ID: <6d8d5bf3-3e16-435b-8701-ea57c8e01a08@suse.com>
Date: Mon, 25 Mar 2024 11:31:42 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 (resend) 00/27] Remove the directmap
To: Elias El Yandouzi 
Cc: julien@xen.org, pdurrant@amazon.com, dwmw@amazon.com,
 Andrew Cooper ,
 George Dunlap ,
 Stefano Stabellini , Wei Liu ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Lukasz Hawrylko ,
 "Daniel P. Smith" ,
 =?UTF-8?Q?Mateusz_M=C3=B3wka?= ,
 xen-devel@lists.xenproject.org
References: <20240116192611.41112-1-eliasely@amazon.com>
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240116192611.41112-1-eliasely@amazon.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 16.01.2024 20:25, Elias El Yandouzi wrote:
> Elias El Yandouzi (3):
>   xen/x86: Add build assertion for fixmap entries
>   Rename mfn_to_virt() calls
>   Rename maddr_to_virt() calls
> 
> Hongyan Xia (13):
>   acpi: vmap pages in acpi_os_alloc_memory
>   xen/numa: vmap the pages for memnodemap
>   x86/srat: vmap the pages for acpi_slit
>   x86: Map/unmap pages in restore_all_guests
>   x86/pv: Rewrite how building PV dom0 handles domheap mappings
>   x86/pv: Map L4 page table for shim domain
>   x86/mapcache: Initialise the mapcache for the idle domain
>   x86: Add a boot option to enable and disable the direct map
>   x86/domain_page: Remove the fast paths when mfn is not in the
>     directmap
>   xen/page_alloc: Add a path for xenheap when there is no direct map
>   x86/setup: Leave early boot slightly earlier
>   x86/setup: vmap heap nodes when they are outside the direct map
>   x86/setup: Do not create valid mappings when directmap=no
> 
> Julien Grall (8):
>   xen/vmap: Check the page has been mapped in vm_init_type()
>   xen/vmap: Introduce vmap_size() and use it
>   xen/arm: fixmap: Rename the fixmap slots to follow the x86 convention
>   xen/x86: Add support for the PMAP
>   xen/arm32: mm: Rename 'first' to 'root' in init_secondary_pagetables()
>   xen/arm64: mm: Use per-pCPU page-tables
>   xen/arm64: Implement a mapcache for arm64
>   xen/arm64: Allow the admin to enable/disable the directmap
> 
> Wei Liu (3):
>   x86/setup: Move vm_init() before acpi calls
>   x86/pv: Domheap pages should be mapped while relocating initrd
>   x86: Lift mapcache variable to the arch level

Just to mention it explicitly: Before hearing back on the comments given up
to patch 13 I'm not intending to put time into looking at the remaining
patches in this series.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Mar 25 10:32:53 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 10:32:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697689.1088720 (Exim 4.92)
	(envelope-from )
	id 1rohdM-0000XF-9O; Mon, 25 Mar 2024 10:32:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697689.1088720; Mon, 25 Mar 2024 10:32:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rohdM-0000X8-5L; Mon, 25 Mar 2024 10:32:52 +0000
Received: by outflank-mailman (input) for mailman id 697689;
 Mon, 25 Mar 2024 10:32:51 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rohdL-0000Wx-8k
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 10:32:51 +0000
Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com
 [2a00:1450:4864:20::42f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 06dffd55-ea93-11ee-a1ef-f123f15fe8a2;
 Mon, 25 Mar 2024 11:32:49 +0100 (CET)
Received: by mail-wr1-x42f.google.com with SMTP id
 ffacd0b85a97d-34175878e3cso2982372f8f.0
 for ; Mon, 25 Mar 2024 03:32:49 -0700 (PDT)
Received: from perard.uk.xensource.com (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 w17-20020adfcd11000000b0033e786abf84sm9137754wrm.54.2024.03.25.03.32.48
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 25 Mar 2024 03:32:48 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 06dffd55-ea93-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1711362769; x=1711967569; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=8Xi3DDIyqugFT6qQDdl59fqNIMfUCuqXq0wSkDBvCXs=;
        b=B2g35PgFsPVu/8WeX8nAYl5QKJko2HReUHckxcV71ac8HVZmRV5O5BVSQJdv6bGQ/P
         Un/OHOW666XzhMYhmZ2NN2s5NPbcOgoNm1e6nKHms4UuhTzdfz5/KdTHxcP5UBw5QcTJ
         0EGAuhrZtoPcfhsTHVp6OyxgRnOKyq6zhL9DY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711362769; x=1711967569;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=8Xi3DDIyqugFT6qQDdl59fqNIMfUCuqXq0wSkDBvCXs=;
        b=lB7//n725vMAtRcITsfpCdpqRFi3gkWeEZel+3YJJ/W3A6kkVwNHENXGqpmSq21PAs
         ViEroFy8qGafdh2SiyM63R+ujUdxHaGqzM8//kh26F4cBe6cyn/XGl5FFoQqH00je5kJ
         1KOIZQfVIzAr/a1K1Avf6SwZdacZjhYCoLDSBE58EGH9bMrAPooefd6auaivTvbFcwi9
         xdoKDTdDrbWmeY6n6XBIxvrsBP/dHLBVMNKwSQkBLGJdHTzydzikTlAD1eF3ceKuIIrJ
         hzAP51dq4X3pxqW3wtQLJ+Q/uLLabToEvK3klSIps5NX9Pg5xfQNwKtBat4yKXruN1qJ
         yY5g==
X-Gm-Message-State: AOJu0YyomlJDuOsVDaJuFYDYH1/EkV7RhM8WF5gMwVH2RGysY5JFG5HP
	rYuZue7045c+ce6RR2aygfGLjJD6uklQqKQD4EWDSvGoTc/h86JkDBCqgQsGVaDCHxBZrhI0g9A
	K
X-Google-Smtp-Source: AGHT+IFq0r0u9PHYgs+Q0N9sdrglcVJU9CrHN2vrqK/O+HB1ib3fOrwBfQwVRD3Y9mUcB5nU/Hvz2Q==
X-Received: by 2002:adf:f290:0:b0:33e:c7e7:cc6 with SMTP id k16-20020adff290000000b0033ec7e70cc6mr3714858wro.2.1711362768724;
        Mon, 25 Mar 2024 03:32:48 -0700 (PDT)
Date: Mon, 25 Mar 2024 10:32:47 +0000
From: Anthony PERARD 
To: =?iso-8859-1?Q?Rafa=EBl?= Kooi 
Cc: xen-devel@lists.xenproject.org
Subject: Re: [XEN PATCH v2 1/1] tools: init scripts: Add missing
 XENCONSOLED_ARGS variable
Message-ID: 
References: 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Wed, Mar 20, 2024 at 08:48:33AM +0100, Rafal Kooi wrote:
> The systemd xenconsoled.service uses the XENCONSOLED_ARGS variable, but
> it was missing from the xencommons file.

Actually, I'm tempted to go the other way and remove XENCONSOLED_ARGS
from the systemd's service file. In the other service files (openrc,
sysvinit) for Linux/FreeBSD/NetBSD, XENCONSOLED_ARGS is simply used to
construct the command line for `xenconsoled`. For the Linux one, if you
set XENCONSOLED_TRACE, XENCONSOLED_ARGS from xencommons won't be used.

On the other end, with systemd, it is very easy to modified a service
file, to add an argument to the command line. So removing
XENCONSOLED_ARGS would make more sense. But some user might have notice
it exist and start using it, so it's probably too late to remove it.

So overall, I don't think it's a good idea to advertise
XENCONSOLED_ARGS, first because it's kind of useless for systemd, and
second because it's broken for "tools/hotplug/Linux/init.d/xencommons.in"



Side note: looks like on my test machine I've used systemd instead of
editing /etc/default/xencommons to change XENCONSOLED_TRACE, so there's
really no need for "xencommons" config file on systemd:

    # /etc/systemd/system/xenconsoled.service.d/trace_all.conf
    [Service]
    Environment=XENCONSOLED_TRACE=all

That "xencommons" config file is just there to be compatible with both
init system.

Cheers,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Mon Mar 25 10:55:33 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 10:55:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697697.1088730 (Exim 4.92)
	(envelope-from )
	id 1rohzC-0004SF-3T; Mon, 25 Mar 2024 10:55:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697697.1088730; Mon, 25 Mar 2024 10:55:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rohzC-0004S8-0L; Mon, 25 Mar 2024 10:55:26 +0000
Received: by outflank-mailman (input) for mailman id 697697;
 Mon, 25 Mar 2024 10:55:24 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rohzA-0004S2-Nr
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 10:55:24 +0000
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com
 [2a00:1450:4864:20::32b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2d8c225a-ea96-11ee-a1ef-f123f15fe8a2;
 Mon, 25 Mar 2024 11:55:22 +0100 (CET)
Received: by mail-wm1-x32b.google.com with SMTP id
 5b1f17b1804b1-41489d4ffccso3528055e9.0
 for ; Mon, 25 Mar 2024 03:55:22 -0700 (PDT)
Received: from perard.uk.xensource.com (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 m29-20020a05600c3b1d00b004146750314csm8161736wms.3.2024.03.25.03.55.20
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 25 Mar 2024 03:55:21 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2d8c225a-ea96-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1711364122; x=1711968922; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=fG8ab83+epcOhpN60/FO5lsPTNoc4E38TF6qkSiKQEA=;
        b=HV52vrwxvZqxR1Zsx6X2rNfNOzQhYTGVL6ej3M1QMiE27mhoQ+FfnEcX1M4RHbPt+L
         d4f3BUAdwrIZr50JUXqvDDOiwgVg7aaaZw7DNiTmW4DSQZSpB+iKHxpWNBPoYBvc66PE
         9VQYmFbYyRHPRwrTuCDPlNEjSGGS7iR2iw4VI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711364122; x=1711968922;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=fG8ab83+epcOhpN60/FO5lsPTNoc4E38TF6qkSiKQEA=;
        b=wzfUiiqip3F2bGm8mYS3CqDmk1f30zoUZcjQUH/olmAVDNYedkQRF43HKSe1oL6rWq
         GT4jO4I0/3yAmMynsv8O15M0xoGMoWP8pAm11wi4FdB8/wGmM94KsM9S+5lJKWIwTo+X
         u2Le+Y+qXPdr+Ij0Ldse4bdeiBRUdqqu1pNvIkxNtQ5UTyB9UAo7qBKhRPzMl3j9HFhs
         ZzRAPcAJcrDL5NuUH0ClGSNbPBXPGKdb8pDO63xvYv6ZbG05y8pW5OMhY/u5kTz9ni0Q
         q+fssW/1pMjAM46NtituDY8XQwS+pOniNH2pjB8W3FLVgDx6qU5hvEChOW8ahny7DXqp
         UMYw==
X-Gm-Message-State: AOJu0Yw015SMGSDGzIHN1IiQvK//nQCPdcf3aFyjcSwbcy4I4XX+TcLV
	Z9ncaka1wFcLpv0dtm78n3JIuRqf3v2gC+DVS/a9h+AJoKZBot5N2CG1V3HiE+0=
X-Google-Smtp-Source: AGHT+IG5LARGj0Z6NpWTCBgcWxqmtLB7RQuz+YRFvBKA+FdDo/xyJwi9LO4oxFS4CCrqUVk1s4KLdw==
X-Received: by 2002:a05:600c:198c:b0:414:3b1:82ed with SMTP id t12-20020a05600c198c00b0041403b182edmr4852238wmq.23.1711364122121;
        Mon, 25 Mar 2024 03:55:22 -0700 (PDT)
Date: Mon, 25 Mar 2024 10:55:20 +0000
From: Anthony PERARD 
To: Carlo Nonato 
Cc: xen-devel@lists.xenproject.org, Juergen Gross ,
	Marco Solieri 
Subject: Re: [PATCH v7 06/14] tools: add support for cache coloring
 configuration
Message-ID: <9784c247-592b-460a-b6d4-3ab4cdf87b77@perard>
References: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
 <20240315105902.160047-7-carlo.nonato@minervasys.tech>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240315105902.160047-7-carlo.nonato@minervasys.tech>

On Fri, Mar 15, 2024 at 11:58:54AM +0100, Carlo Nonato wrote:
> diff --git a/tools/libs/light/libxl_create.c b/tools/libs/light/libxl_create.c
> index 5546335973..79f206f616 100644
> --- a/tools/libs/light/libxl_create.c
> +++ b/tools/libs/light/libxl_create.c
> @@ -726,6 +726,15 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config,
>              /* A new domain now exists */
>              *domid = local_domid;
>  
> +            ret = xc_domain_set_llc_colors(ctx->xch, local_domid,
> +                                           b_info->llc_colors,
> +                                           b_info->num_llc_colors);
> +            if (ret < 0 && errno != EOPNOTSUPP) {

Wait, this additional check on EOPNOTSUPP, does that mean we ignore
"llc_colors" configure by the admin of the VM if the system doesn't
support it? Shouldn't we also report an error in this case? At least if
`num_llc_colors > 0`.

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Mon Mar 25 11:09:52 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 11:09:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697709.1088744 (Exim 4.92)
	(envelope-from )
	id 1roiD5-0006pa-B9; Mon, 25 Mar 2024 11:09:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697709.1088744; Mon, 25 Mar 2024 11:09:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1roiD5-0006pT-8U; Mon, 25 Mar 2024 11:09:47 +0000
Received: by outflank-mailman (input) for mailman id 697709;
 Mon, 25 Mar 2024 11:09:46 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1roiD3-0006pJ-Lt
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 11:09:46 +0000
Received: from EUR01-DB5-obe.outbound.protection.outlook.com
 (mail-db5eur01olkn0810.outbound.protection.outlook.com
 [2a01:111:f400:fe02::810])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2e76b9b7-ea98-11ee-a1ef-f123f15fe8a2;
 Mon, 25 Mar 2024 12:09:43 +0100 (CET)
Received: from DU0P192MB1700.EURP192.PROD.OUTLOOK.COM (2603:10a6:10:3bf::6) by
 DB3P192MB2060.EURP192.PROD.OUTLOOK.COM (2603:10a6:10:432::13) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.7409.31; Mon, 25 Mar 2024 11:09:42 +0000
Received: from DU0P192MB1700.EURP192.PROD.OUTLOOK.COM
 ([fe80::181e:3628:177d:1cf9]) by DU0P192MB1700.EURP192.PROD.OUTLOOK.COM
 ([fe80::181e:3628:177d:1cf9%4]) with mapi id 15.20.7409.023; Mon, 25 Mar 2024
 11:09:41 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2e76b9b7-ea98-11ee-a1ef-f123f15fe8a2
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=TKip9s3J2Rh0mpKY/LbKF9mUyt5avRHw290Fnpe93BVFsEpe/Trrk2h8PAsQpEojWBKtDPibiAWO2Sy2XHhLxAxT79S4FbPbEyQaZZbM2G6NKdYjCxLJMUpo70I9UkAGdaOt7RdQOQ7PrMdoWo/SRRkpyE4McZPMfWWCU+8+Qn404WIdULBaJYzurQBQ2YrM9p/XtuKB5NoT2EbM9UZU3xITh5wU+H4E0NLXe8XUbPZSFTe3qvR6og2HpDsvJ2vpJPJoKTuPbDJewZqKmWgVU/Dccwx69PTeqP8C9W9FGbEDD0kTUeH9rqsfBGOwFt9BGYzo3EjJIiniDGQIUJLZLw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=13O3vWjujuICVCMCryvtTZnNiI43HEuqbfs30qmqdho=;
 b=Fp36MXhnwMxPwzKuEwRma7H2cueaslms90GeIWCL+kBZjpBC8da2459ogXiAl+3hgUODNK0mSpIG5lmKLRwWfbY/qGtVCr4t0zO0rquGzKMMnHKIF/txoNZ0nqB2YU+EzAT9s9tYxB8LKhsDm+rbMpehK/XUaRsh6gn/20SYTBjKS89OQmc0gP5jebE3Nrrx8/u7Zk/7ssJIIDSrrJnbV6cylRLUvUvw+BcEuDE3OSyy162ePHOnCn6jDl2dPZsidLTIlYZ5pEy1fcO2wt8gBDGy77sDL0vQwFRRXH7rhDLvy21KgbLD9JR4I44UJm3//jPUjs4d85TllWIKJ6okxw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=13O3vWjujuICVCMCryvtTZnNiI43HEuqbfs30qmqdho=;
 b=E5cY24yTDPxA1Mlj3DK9Zrq/tNTl1j6eRAT6oRjoduozMe6+5O2RB581oHWdUjQj2bYCyZtYlxXPXpzBwoai9dvtdfCNwy+LFr/MKx2cQgY8fFMi1DDgMPx4i6z6heTJe5OSJfYQPf+5lNrow/sieiYqL8eaJnTzxioXQBETqvQHaF0HL3LnG2uuggbPaBBwvC/u6rq7qzN7Ht2Ljz+yClaIgaSDcXGSyk0yoaq6GcHig1BxykIMTJsS3scqX0JbFV4UKQpjr6JQ2ZF0kbHnA5VRQChTQ6CJMZht1WMRriSqaAtylw0lQrQOVriBvL71q1Sn0pc9L7BCf3QNE/Y4hA==
Message-ID:
 
Date: Mon, 25 Mar 2024 12:09:40 +0100
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH v2 1/1] tools: init scripts: Add missing
 XENCONSOLED_ARGS variable
To: Anthony PERARD 
Cc: xen-devel@lists.xenproject.org
References: 
 
 
Content-Language: en-US
From: =?UTF-8?Q?Rafa=C3=ABl_Kooi?= 
Autocrypt: addr=rafael_andreas@hotmail.com; keydata=
 xjMEZHDtHhYJKwYBBAHaRw8BAQdA4C7O72UZHQbhHNm1BUkAM/7+KQKN3tupyuGVGyj2dIHN
 KVJhZmHDq2wgS29vaSA8cmFmYWVsX2FuZHJlYXNAaG90bWFpbC5jb20+wo8EExYIADcWIQTv
 ioHnE84MxV6adj/iFi3SALEToAUCZHDtHgUJA8JnAAIbAwQLCQgHBRUICQoLBRYCAwEAAAoJ
 EOIWLdIAsROgP80BAKeJdh3YQ5l3gxGp8R9wIvN9Ac3vsMfy8I4kZ6TXksLKAP9vLRV4G3yw
 z7/seKhWc27Jjl4uI/+lIWhWaWrUYZmjAM44BGRw7R8SCisGAQQBl1UBBQEBB0DE61lbAezY
 NhOlHgxdZ9V4klIhSajeU50O8wHIPQnCLgMBCAfCfgQYFggAJhYhBO+KgecTzgzFXpp2P+IW
 LdIAsROgBQJkcO0fBQkDwmcAAhsMAAoJEOIWLdIAsROghHgBANU4dj+WnuSaWemAHVkjERJg
 m0FQpmZzNI8hdolS3gYdAP9zGK65ilpHMDj4pGvfALabruZA4NPJYxSqeamHvOuhBA==
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-TMN: [3JxXAktAODLT6vKlQnO9ghwN+eW995DqLnMzCwfscDeabb17eBzVFo9p/Mj1Hkm0]
X-ClientProxiedBy: LO3P123CA0026.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:388::6) To DU0P192MB1700.EURP192.PROD.OUTLOOK.COM
 (2603:10a6:10:3bf::6)
X-Microsoft-Original-Message-ID:
 <2e49710d-cd5c-465f-a4ad-54548c0b207c@hotmail.com>
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DU0P192MB1700:EE_|DB3P192MB2060:EE_
X-MS-Office365-Filtering-Correlation-Id: c2a3decc-9a00-44f9-571c-08dc4cbc117f
X-MS-Exchange-SLBlob-MailProps:
	qdrM8TqeFBvZAU3gE70DxtLQxW3YuafP7V8ojlLPEz6KlGUKPny5HuMqdmLAuw7zLB0xVwK85Fg/eG2KzNpuMHHBZBmBLsuoWPh0qDZ2/iIKy6WWfXKBf4/a/16FVqof0M3DGJ02YJRjag2uEwdvRS8FED5rGLhcmTRhfYPlY2o7oWBJuDZK4clpAOPXC6/9n95fAFl9vHn3UoPmmOyUAa+aiInJTunPov8XxnkyU8sYoeRMTZ2YDxo/9lcKQWFbzIxPqpbYR3wmhP+EqQDWxUoiVK+pUwSfqQTCVA+l77gt0KD4J5JVdBq8XlaqmU3z2QAgtFr0uWtwSiuTWhLSoZdzC8uHHXO84wCoqXjVYnYR2hoKLla45jrY3KBiV+aBk7IW9aDIV+U8DBxnkmjXu3x4AKXgqqip0spg54bQultUX3G7YV1Ft4tBb4wQvBHKgd3s9tDs4zhu3fCELE2WjuwzUyrFyI22uoXX1d8TRqbREy9MWRsebKLxmm8EcABqWPEIL1inZklJIriUxB1zBmSJfSMpF4RhRMhqB2tHVMnNQh6c4XnKGMTxX+me/tG8iswTjJnvlIZp968oy627p7KLxu59hx6HVTqlmw5MC3tZV3hg0GWriX9etgqBhzibrGe7GGjycC9CpGjAZv+u/VssdZ3jUcUsmN6dnK4LvV0ynU17CXzX8vMb3rs37xvm4VdA157FgNIuTIBoQFCR6QfO3CLyaUV402wolEuTMYJ3BNPbfvoH7uKGVeIT6ar8cY9vWERzoLAHaz5bKiN2JemfF7WMgArM
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	oHJLFBSR9z5klvclngf3kWXQfc8UEeDQzA6XvYCjUiRp0w8enRRo/8wyPudRtC7xysByv/Sa0wDoNBk0dis4Nbf0WjgLgpxCNihKFFQxgxbCHW7SO67e985snDHiU6dJ3A5h/lG51G0C79JHkE3KHoj37OTD8tYtuYWTzTNw7pAzpLrk8pWftoA2DSRCYF7GqX1M/eq6vkKATmWra9tggSEPcKhuNXq1kBQvFzgAyAOB2xsIR7UJQZuLeNdyv4eRK9Eg/1lxAmZ7lqAoxMW6wOcQBv6Akc2EbgswVgzUaYk6OjFeEw/fi60dCo7/RnIa6hKtgHvJjLZG2BRfs86q6CYxrmii/9MuYVpyNXVISet8guxPi+QYoZSqEDyYJg4R/TjZarOBcSH8a/nyZVsxVpQIwPXiad0Nk5notbJjL0WkXiet+vcpgDOn8epxmQf0i+rJeetrYK8ngDRa9Vc7VRBqoF1tJdAlxer4+dIb0EbxCZW9r0e6epA8EMUNwBuxPOeojkMDJvgL7KKaCHMZVVMNxH1y5r+D8/N3p9OyC/WpFGR+xa9FWCPoHPVHrwt5
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?SklRVHhBOGpEMlEybVlyU1ZJMmVmdG8veC9kT3ZKUXBtbnJsaGN1YjJvNXli?=
 =?utf-8?B?bkNsOU5pU3dmc3R1OGZVQ3FqbDJJUG5EVkdodVRrRW0yaDRLT0ZkZmxsa0tN?=
 =?utf-8?B?UTlVbmVHZzR6aGwwb0g4emgvbjNZc1V6WEhWc2g0TzErR01Bb2hMOGF4Njdl?=
 =?utf-8?B?VnFaaGhOZVFmak9JYlpVd3ZndWVOUFU3TkJNRmVnam1lUDFBQ3JCRlB2Sk5Z?=
 =?utf-8?B?cVZmTU5JOWg5V29UVXJKNUNyZWtSbEswdnVkS3Q4d0hjemJQT2krK3BRclQy?=
 =?utf-8?B?L3lIS1NlSk1STjhpT2NmTTZLRGtTQVRVUEpiMUh3emtDcWZwUDBVMkZEMFJT?=
 =?utf-8?B?VkJWZDJqUmRGZmlqUXlIL080RHloQU9lUHdCNkNoUS9GVkRzN3ZzMEQ0d2R0?=
 =?utf-8?B?NlIzQkhUYXYyZTRmWFE3azFpN2NtVXVVdXp1cUFKcnlvSzZ1Ny9DcWZQOTNp?=
 =?utf-8?B?ZkZZeUJvQXdKa2ZxVjVVRXNEUURTK2pTMVJxTnZNOW1scDFMMFVOUzF0d2hX?=
 =?utf-8?B?dEJKOENTY3BOeHdzeVhEdXN4YUlUbkx1MzBvQlc1M2I5WEdVZ1R0WDFuMDAw?=
 =?utf-8?B?WHd4aXdqMEJVbG10VnFRUU1vMGZuUHBNNksxMGt0U05EZnBDeGhrR21VOG9r?=
 =?utf-8?B?d0piZjM1b08rZ2NuZzgzdS85eFMvSkNRUnJxLzFxS21WaEtIRTRYRDBFM0c0?=
 =?utf-8?B?WXZ6OFNVcDloK2VXR29YcTF4eTBSNVNuS2Y1c2dwLzNDd0ZXUkZyN1hpUHJF?=
 =?utf-8?B?VVgyMFFON0NJRWhXUWFBZUROZXJtTWZkekpJaWhHeXJCQ1h4elhScDJ1bkNB?=
 =?utf-8?B?SkRXdWNHaDg0ZFFKdkltcTlDMWZ5eklmelJmWUIzOFlSMVFVNHhQUE1EdlZs?=
 =?utf-8?B?S3BWbDNTbmx6ajMzeVBtT3g5L1V3MzBFVnhCbC9ZYU14enhXTWpIRXh2QWpB?=
 =?utf-8?B?NCtKSFg4bklrWHBoTXVIRHpuOXYxN3c1Z1k1Ni94aTVLL0FTVG5nOHB5cUJJ?=
 =?utf-8?B?N3FTWVNMc1lJR1VQTmFtNmRVUCtGTVBGZWIyaXZXV012eWNSYitoVk5vcllS?=
 =?utf-8?B?dStJNk5NRm5rblJVNS9sOCtZQ2hIWVhEczRyem5NUGUxczQwQTlEN3NQWHI0?=
 =?utf-8?B?MEd5Z1Q5ejgrS0RXb01zazF5VnVKK0c1RERacXhoaEo1bFUzNVBuNVYxdzZD?=
 =?utf-8?B?YVM5S1pxUXpYcTFCd0l2WG5Mbjl4MGVtRlREUVJncUxycjBocEFRbGdZYngz?=
 =?utf-8?B?Vy9ncG9uMzEzaVVKTEVmSnBrUUpCanFlOWFpQ1d0VXd5blZyU0kvVmNmeDli?=
 =?utf-8?B?SVhmcTlIaThHSGltN3l3YkFrZVVNT3I3ZTg1SjhHbloyS0JnUnUzMUdQSC9Z?=
 =?utf-8?B?SW9uZ09FU1FYMDFZS0k5TThXblJtelUzajBIekFoQ3ZXNjRSc0cvUGJEMGNV?=
 =?utf-8?B?SUIxdXRrWVRGRDBJMzlrSEg4QVQ4SW1NbzVXTnQxc2FjRW1Oem1ReDA5Mkhk?=
 =?utf-8?B?VHNxM09ZSDNvcTh4UkxZdEVwRDF5bWhUbzdhU1BhMk9kZ3RXcW5yOEErMElR?=
 =?utf-8?B?NkNYM1lWZG9qNGZha3JaMlhaaXNPQWFBaTBSTFpSdHliWkQzWTVQQmVRUGhI?=
 =?utf-8?B?ZzhMSTJDUUdoQVFNUUZBa1AzcWJjbnZCTEd2cThlVXo4NXlDelJzRm1LdjBO?=
 =?utf-8?B?bFdOdWE2Ym45Rno2ZndDcjI0cythYkpGUlZwM0JhTWlmUmJkUE51VHhESUdI?=
 =?utf-8?Q?N59uoszqSbs1+92Fm9ADFmvbXcGtBgWUk0HqgGF?=
X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-fb43a.templateTenant
X-MS-Exchange-CrossTenant-Network-Message-Id: c2a3decc-9a00-44f9-571c-08dc4cbc117f
X-MS-Exchange-CrossTenant-AuthSource: DU0P192MB1700.EURP192.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Mar 2024 11:09:41.5320
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg:
	00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3P192MB2060

On 25/03/2024 11:32, Anthony PERARD wrote:
> On Wed, Mar 20, 2024 at 08:48:33AM +0100, Rafaël Kooi wrote:
>> The systemd xenconsoled.service uses the XENCONSOLED_ARGS variable, but
>> it was missing from the xencommons file.
> 
> Actually, I'm tempted to go the other way and remove XENCONSOLED_ARGS
> from the systemd's service file. In the other service files (openrc,
> sysvinit) for Linux/FreeBSD/NetBSD, XENCONSOLED_ARGS is simply used to
> construct the command line for `xenconsoled`. For the Linux one, if you
> set XENCONSOLED_TRACE, XENCONSOLED_ARGS from xencommons won't be used.

I assume you mean the OpenRC/SysV init script?

> > On the other end, with systemd, it is very easy to modified a service
> file, to add an argument to the command line. So removing
> XENCONSOLED_ARGS would make more sense. But some user might have notice
> it exist and start using it, so it's probably too late to remove it.> 
> So overall, I don't think it's a good idea to advertise
> XENCONSOLED_ARGS, first because it's kind of useless for systemd, and
> second because it's broken for "tools/hotplug/Linux/init.d/xencommons.in"
> 
> 
> 
> Side note: looks like on my test machine I've used systemd instead of
> editing /etc/default/xencommons to change XENCONSOLED_TRACE, so there's
> really no need for "xencommons" config file on systemd:
> 
>      # /etc/systemd/system/xenconsoled.service.d/trace_all.conf
>      [Service]
>      Environment=XENCONSOLED_TRACE=all
> 
> That "xencommons" config file is just there to be compatible with both
> init system.
> 
> Cheers,
> 

Makes sense. To be honest I don't even know what arguments one would pass
to xenconsoled other than setting the log level to begin with. I would
assume this to be a niche enough use case where very few users would be
affected if we do decided to remove the variable. Maybe we could opt to
advertise it as something that we will be removing in a later release?
Maybe either through an "ExecStartPre" message, or by updating the comment
in xencommons.

Thanks,

Rafaël Kooi


From xen-devel-bounces@lists.xenproject.org Mon Mar 25 11:17:01 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 11:17:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697712.1088753 (Exim 4.92)
	(envelope-from )
	id 1roiJt-0008PX-1D; Mon, 25 Mar 2024 11:16:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697712.1088753; Mon, 25 Mar 2024 11:16:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1roiJs-0008PQ-UF; Mon, 25 Mar 2024 11:16:48 +0000
Received: by outflank-mailman (input) for mailman id 697712;
 Mon, 25 Mar 2024 11:16:48 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1roiJs-0008PK-2K
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 11:16:48 +0000
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com
 [2a00:1450:4864:20::52e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2a710e57-ea99-11ee-a1ef-f123f15fe8a2;
 Mon, 25 Mar 2024 12:16:45 +0100 (CET)
Received: by mail-ed1-x52e.google.com with SMTP id
 4fb4d7f45d1cf-56845954ffeso5741126a12.2
 for ; Mon, 25 Mar 2024 04:16:45 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 dk5-20020a170907940500b00a4750b2e0f0sm1767163ejc.164.2024.03.25.04.16.44
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 25 Mar 2024 04:16:45 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2a710e57-ea99-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711365405; x=1711970205; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=dJvOqfaL61RqNqnl4Xv4E+cdJ3iNN1Bg7KaIBcfEhFs=;
        b=Cq+W68asoBWboMP9LE2u4vXxDCj2N0vQiOOUqIp1Js+/5+dujCbc9IWgaEAu7H4LEW
         9Fk6+x6/HPpC4jEZgWHQ633KRZGIofkyh8216z464QWLr3phJeyPI6q6cmKf/xqY5ica
         H5fWkry2VJQQJyL7HvdBfwvd3ep+hB/nE665ZKiodRdL16SzaMpcdGzeW1HesoDu89I+
         jsUJiZ2jQfX7PVPbSdk3Ss95XPmRdpdP0Yk5nAYrRqgoPiAVQQtVbL+mgRGDx6OSp/Uz
         VfVTHN9h/eh0X59zBpC6W3WCWDKtKta+ULr+NuWdTS9jrliRZQkO9k+Nl6WUgHXYFGBm
         JMkw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711365405; x=1711970205;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=dJvOqfaL61RqNqnl4Xv4E+cdJ3iNN1Bg7KaIBcfEhFs=;
        b=Mgznm98GYFf1GXQbCE6tTlDuC3vj+3flVHTajGm4Zsu3BQz0QTb3fcmR3oMdgFOlhL
         4Qu51qALFYhwaJ8+8StzeP0ajNaqt+wOubJ7PwF77Scv1hL7gimHXLQ142gasx14IXfP
         0oSUuvgdpvXcD4KbJg16PLtZB+SDscm6ZfPSXcMgx+P0hUiJ5fOYJe9EjjZvpvQV3hLg
         0S+g4LKcn79c4GDRlDsb7sJrjgLNiUY0Ha6wYugpkSMInqCQ7w/sP6eiNJ3qJtbrErCD
         SKPQPPnmOFkBj8x5S9JC0IykP0gqRxIzySz3rdd/Lq1tTuMBju2+YTvnsz/DHuJkPbMk
         Ysxg==
X-Forwarded-Encrypted: i=1; AJvYcCWjg/9mZxaVIyA2HnzVkrDrPiaFkpfVD6dumnYA2iqsd8KnOvWpDrjyMTzHEC2HlJkZT6sfbH4BEH8TLoGsjCZKJjhH7Af/9Hx2V6Ru2dU=
X-Gm-Message-State: AOJu0Yx+eVF1HjCMsGjM3kVmYDhsITJNUjza0Ai7lojzRDjDTL/HwSPW
	NZxzIW1iAO1zhtGuOHrOOB9U99aMW1UDv+BORSPulnuF9E5Aa7wkvSOUOTIpNg==
X-Google-Smtp-Source: AGHT+IFLmEoBBHw5JYW/7DUzCI09LutYSWcl/cNvHNrhG52EY/200nAOt0jhTNSWSZf3U2UHQmYvTQ==
X-Received: by 2002:a17:906:2486:b0:a47:3a99:89e with SMTP id e6-20020a170906248600b00a473a99089emr4138245ejb.12.1711365405456;
        Mon, 25 Mar 2024 04:16:45 -0700 (PDT)
Message-ID: 
Date: Mon, 25 Mar 2024 12:16:44 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] docs/misra: document the expected sizes of integer
 types
Content-Language: en-US
To: Julien Grall 
Cc: andrew.cooper3@citrix.com, bertrand.marquis@arm.com,
 george.dunlap@citrix.com, michal.orzel@amd.com, roger.pau@citrix.com,
 xen-devel@lists.xenproject.org, Stefano Stabellini 
References: 
 <6a76723e-ba47-40b3-8f33-d68030b14299@suse.com>
 
 <7ab73379-b057-4568-9869-141cef185752@suse.com>
 
 
 
 <87234837-9fb3-40a9-849d-8b8574f2661c@suse.com>
 
 <198bade8-c6fc-4ae0-b721-3a9e2bd8acbe@suse.com>
 
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 22.03.2024 00:17, Julien Grall wrote:
> Hi Stefano,
> 
> I haven't fully read the thread. But I wanted to clarify something.
> 
> On 21/03/2024 19:03, Stefano Stabellini wrote:
>>>> Or possibly unsigned long depending on the parameter.
>>>
>>> You're contradicting yourself: You mean to advocate for fixed-width types,
>>> yet then you suggest "unsigned long".
>>
>> No. I explained it in another thread a couple of days ago. There are
>> cases where we have fixed-width types but the type changes by
>> architecture: 32-bit for 32-bit archs and 64-bit for 64-bit archs.
>> Rather than having #ifdefs, which is also an option, that is the one
>> case where using "unsigned long" could be a decent compromise. In this
>> context "unsigned long" means register size (on ARM we even have
>> register_t). Once you pick an architecture, the size is actually meant
>> to be fixed. In fact, it is specified in this document. Which is one of
>> the reasons why we have to use == in this document and not >=. In
>> general, fixed-width types like uint32_t are better because they are
>> clearer and unambiguous. When possible I think they should be our first
>> choice in ABIs.
> 
> "unsigned long" is not fixed in a given architecture. It will change 
> base on the data model used by the OS. For instance, for Arm 64-bit, we 
> have 3 models: ILP32, LP64, LLP64. Only on LP64, 'unsigned long' is 32-bit.

"... is 64-bit" you mean?

Jan

> So effectively unsigned long can't be used in the ABI.
> 
> As a side note, Xen will use LP64, hence why we tend to use 'unsigned 
> long' to describe 32-bit for Arm32 and 64-bit for Arm64.
> 
> Cheers,
> 



From xen-devel-bounces@lists.xenproject.org Mon Mar 25 11:17:47 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 11:17:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697713.1088764 (Exim 4.92)
	(envelope-from )
	id 1roiKp-0000TS-Al; Mon, 25 Mar 2024 11:17:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697713.1088764; Mon, 25 Mar 2024 11:17:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1roiKp-0000TL-6z; Mon, 25 Mar 2024 11:17:47 +0000
Received: by outflank-mailman (input) for mailman id 697713;
 Mon, 25 Mar 2024 11:17:45 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1roiKn-0000T9-UH
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 11:17:45 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1roiKl-0000Eh-BE; Mon, 25 Mar 2024 11:17:43 +0000
Received: from gw1.octic.net ([88.97.20.152] helo=[10.0.1.240])
 by xenbits.xenproject.org with esmtpsa
 (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92)
 (envelope-from )
 id 1roiKl-0007iY-37; Mon, 25 Mar 2024 11:17:43 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=mpn8L1ljf7AtccoZRkolubYU3MEj+wmmtgKXEnHgWAg=; b=rN/aybtuVxZKYOuzh7CkwwEsCL
	sJT8SVhURYmtOI/MWy6+QgNFugAHCU8MPD9Y2VBjFOVmHb9LcXrpBT1Ib1eJ21RJe8emnrUBWsOSt
	koAMIHsUJrOrV8/txVLBdLMWj3Cvig1j2MyUB3xPDbSr1a1M7sMVykwy+IbI8Swvo5SM=;
Message-ID: <1a13510a-6085-411d-8d7a-788da9a16e09@xen.org>
Date: Mon, 25 Mar 2024 11:17:41 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] docs/misra: document the expected sizes of integer
 types
Content-Language: en-GB
To: Jan Beulich 
Cc: andrew.cooper3@citrix.com, bertrand.marquis@arm.com,
 george.dunlap@citrix.com, michal.orzel@amd.com, roger.pau@citrix.com,
 xen-devel@lists.xenproject.org, Stefano Stabellini 
References: 
 <6a76723e-ba47-40b3-8f33-d68030b14299@suse.com>
 
 <7ab73379-b057-4568-9869-141cef185752@suse.com>
 
 
 
 <87234837-9fb3-40a9-849d-8b8574f2661c@suse.com>
 
 <198bade8-c6fc-4ae0-b721-3a9e2bd8acbe@suse.com>
 
 
 
From: Julien Grall 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Jan,

On 25/03/2024 11:16, Jan Beulich wrote:
> On 22.03.2024 00:17, Julien Grall wrote:
>> Hi Stefano,
>>
>> I haven't fully read the thread. But I wanted to clarify something.
>>
>> On 21/03/2024 19:03, Stefano Stabellini wrote:
>>>>> Or possibly unsigned long depending on the parameter.
>>>>
>>>> You're contradicting yourself: You mean to advocate for fixed-width types,
>>>> yet then you suggest "unsigned long".
>>>
>>> No. I explained it in another thread a couple of days ago. There are
>>> cases where we have fixed-width types but the type changes by
>>> architecture: 32-bit for 32-bit archs and 64-bit for 64-bit archs.
>>> Rather than having #ifdefs, which is also an option, that is the one
>>> case where using "unsigned long" could be a decent compromise. In this
>>> context "unsigned long" means register size (on ARM we even have
>>> register_t). Once you pick an architecture, the size is actually meant
>>> to be fixed. In fact, it is specified in this document. Which is one of
>>> the reasons why we have to use == in this document and not >=. In
>>> general, fixed-width types like uint32_t are better because they are
>>> clearer and unambiguous. When possible I think they should be our first
>>> choice in ABIs.
>>
>> "unsigned long" is not fixed in a given architecture. It will change
>> base on the data model used by the OS. For instance, for Arm 64-bit, we
>> have 3 models: ILP32, LP64, LLP64. Only on LP64, 'unsigned long' is 32-bit.
> 
> "... is 64-bit" you mean?

Whoops. Yes!

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Mon Mar 25 11:45:05 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 11:45:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697718.1088774 (Exim 4.92)
	(envelope-from )
	id 1roil7-0005QS-D2; Mon, 25 Mar 2024 11:44:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697718.1088774; Mon, 25 Mar 2024 11:44:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1roil7-0005QL-9L; Mon, 25 Mar 2024 11:44:57 +0000
Received: by outflank-mailman (input) for mailman id 697718;
 Mon, 25 Mar 2024 11:44:56 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1roil5-0005QF-UQ
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 11:44:56 +0000
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com
 [2a00:1450:4864:20::633])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 18543bc8-ea9d-11ee-a1ef-f123f15fe8a2;
 Mon, 25 Mar 2024 12:44:53 +0100 (CET)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-a4715991c32so499466966b.1
 for ; Mon, 25 Mar 2024 04:44:53 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 18543bc8-ea9d-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1711367093; x=1711971893; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=LE5XB28Iczv3N/UcJQCK/MEXMasyR2c3aHyOGGrlwow=;
        b=VjSkQsIpqtg3lXlnPop6rr43g22CLWNdDXiAOlbDSU8uySMo3Ecsi0OHvmcR20c+HQ
         exwWzi/wG7N2o3mVjb05KsCTKkSCSb0YMJbfFJwEhlYxKighxNbdzj4Fude9gzRaTrcE
         epZmi5QzGdtJs+g4eU6e3mOr8ar7EJEI7KZHNBh2VkQLmRv98tUFE0KAveqHqQJ1cBX1
         9EK4UQEGAKcJnK3aIxg0UNTlJ7fytJ44lWkdanqAEnUIprQUta3eruKy5RQbsgBbTt9F
         VxTsmUVTAUaig7eZP2qu7V7wE4NfN6bdmy7Yh6hKgxcs09rwBJB8WwJYv7F+dueISzIY
         vr5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711367093; x=1711971893;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=LE5XB28Iczv3N/UcJQCK/MEXMasyR2c3aHyOGGrlwow=;
        b=IhlX4NXEDp4auToExbpxlCfhynekpP17hMlNlB3LiTUyXui10csl9h3kn/c4hvr9oI
         ldcB8tJqDk4xNhfhMX7+KmQsGxRdE7KlFDViYMfjrqxxTDOdTiqVg0Ag+jSpXQ3CKxoB
         Y95DkCFfYe5w/dwiquIwh/RwzpTa9Za01+7N5FW2DgApUI8EYe0ZjI/94dHSVt+KOAWM
         8/1l5pzkb77nFVFViNXVhGFnve4G0j1B7Ps0HvPEdWDJOELUfetIpmfADkkA0hBRl64P
         f3iFfg7EMLNVIpClYrJm0KCfeTOZ3Sild3rtt8Qky5vl2ZzmaAPEJ68bEi+g3Bcbc9y5
         U3KA==
X-Gm-Message-State: AOJu0YwmnPwdngh3woFTS7tcw0DVqR2G2Fr+FJQW1XTQdybVmNdb5u2m
	DUarl+OXB/kpENWxBCe/8uNOxS2H1WIOAjLIqxf+pfZrmRTR7ziLEU4cP9J66nhn7qL1KPVHcES
	vAExGbYChNLLhsxF78dvw/fL2EMzsesJhRsenjQ==
X-Google-Smtp-Source: AGHT+IHegjAsgruA0BqeGIAU7seMgiVtbzBR285e6jnfyK2qSEhptEXOZ5HImQgwQdzMtXmtmfaosF0oQLoclzafGLM=
X-Received: by 2002:a17:906:7709:b0:a47:3953:f8e4 with SMTP id
 q9-20020a170906770900b00a473953f8e4mr4370726ejm.6.1711367093039; Mon, 25 Mar
 2024 04:44:53 -0700 (PDT)
MIME-Version: 1.0
References: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
 <20240315105902.160047-7-carlo.nonato@minervasys.tech> <9784c247-592b-460a-b6d4-3ab4cdf87b77@perard>
In-Reply-To: <9784c247-592b-460a-b6d4-3ab4cdf87b77@perard>
From: Carlo Nonato 
Date: Mon, 25 Mar 2024 12:44:42 +0100
Message-ID: 
Subject: Re: [PATCH v7 06/14] tools: add support for cache coloring configuration
To: Anthony PERARD 
Cc: xen-devel@lists.xenproject.org, Juergen Gross , 
	Marco Solieri 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Anthony,

On Mon, Mar 25, 2024 at 11:55=E2=80=AFAM Anthony PERARD
 wrote:
>
> On Fri, Mar 15, 2024 at 11:58:54AM +0100, Carlo Nonato wrote:
> > diff --git a/tools/libs/light/libxl_create.c b/tools/libs/light/libxl_c=
reate.c
> > index 5546335973..79f206f616 100644
> > --- a/tools/libs/light/libxl_create.c
> > +++ b/tools/libs/light/libxl_create.c
> > @@ -726,6 +726,15 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain=
_config *d_config,
> >              /* A new domain now exists */
> >              *domid =3D local_domid;
> >
> > +            ret =3D xc_domain_set_llc_colors(ctx->xch, local_domid,
> > +                                           b_info->llc_colors,
> > +                                           b_info->num_llc_colors);
> > +            if (ret < 0 && errno !=3D EOPNOTSUPP) {
>
> Wait, this additional check on EOPNOTSUPP, does that mean we ignore
> "llc_colors" configure by the admin of the VM if the system doesn't
> support it? Shouldn't we also report an error in this case? At least if
> `num_llc_colors > 0`.

You're right. The problem was that I didn't want to log because coloring is=
 a
very niche feature and I need to indiscriminately try to color a domain. Do=
ing
that only when `num_llc_colors > 0` is fine though.

Thanks.

> Thanks,
>
> --
> Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Mon Mar 25 12:18:31 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 12:18:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697727.1088785 (Exim 4.92)
	(envelope-from )
	id 1rojHO-0001gb-4c; Mon, 25 Mar 2024 12:18:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697727.1088785; Mon, 25 Mar 2024 12:18:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rojHN-0001gU-WC; Mon, 25 Mar 2024 12:18:18 +0000
Received: by outflank-mailman (input) for mailman id 697727;
 Mon, 25 Mar 2024 12:18:17 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rojHN-0001gO-Ji
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 12:18:17 +0000
Received: from mail.actia.se (mail.actia.se [212.181.117.226])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c2096a2f-eaa1-11ee-afe3-a90da7624cb6;
 Mon, 25 Mar 2024 13:18:16 +0100 (CET)
Received: from S036ANL.actianordic.se (10.12.31.117) by S035ANL.actianordic.se
 (10.12.31.116) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.37; Mon, 25 Mar
 2024 13:18:15 +0100
Received: from S036ANL.actianordic.se ([fe80::e13e:1feb:4ea6:ec69]) by
 S036ANL.actianordic.se ([fe80::e13e:1feb:4ea6:ec69%4]) with mapi id
 15.01.2507.037; Mon, 25 Mar 2024 13:18:15 +0100
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c2096a2f-eaa1-11ee-afe3-a90da7624cb6
From: John Ernberg 
To: Bertrand Marquis 
CC: Julien Grall , Peng Fan , "Stefano
 Stabellini" , Michal Orzel ,
	Volodymyr Babchuk , Jonas Blixt
	, "xen-devel@lists.xenproject.org"
	
Subject: Re: [PATCH 1/2] xen/arm: Add imx8q{m,x} platform glue
Thread-Topic: [PATCH 1/2] xen/arm: Add imx8q{m,x} platform glue
Thread-Index: AQHaVDuqVQ/kgxLZgUK/m8/hE0ez5bDzxxsAgAA1KwCAAVx5AIAAQjeAgAEdtQCAAyp5AIABm3uAgAZ8E4CAKNxDgIAApfwAgAKGQoCAAAbIgIAHmW8AgAtpcwCAABVOgIAA6xqAgACMuACAAALIgIAGBwUA
Date: Mon, 25 Mar 2024 12:18:15 +0000
Message-ID: 
References: <20240131114952.305805-1-john.ernberg@actia.se>
 <20240131114952.305805-2-john.ernberg@actia.se>
 
 <494d4961-ad8a-4d1d-aaa6-d1bfb9d6a137@actia.se>
 <167f0c7a-e037-446c-82f8-2584e35a7af1@xen.org>
 
 <012b5f83-2f9b-4477-965e-07b8506c0052@xen.org>
 
 <5a0c8f09-4f01-45e9-892c-86342c0d0ec5@xen.org>
 <08ae764c-3490-4dd1-ab70-7a855a98d16d@actia.se>
 <911ec1bb-3733-4f37-839e-673a88e408ff@actia.se>
 
 <848794f3-a337-49d9-84db-a969970f071b@actia.se>
 <48038c7f-d7cd-4100-a41b-8042bcb93208@xen.org>
 <967020E7-3D03-416A-8BFC-6F4E4BD9D7B5@arm.com>
 
 <849f3f5a-b960-444a-a10e-1f2df36c22a7@xen.org>
 <2F07325F-428F-4570-BE14-B84DD0A1C9F7@arm.com>
 <1f5eba1a-7dc3-41f2-8986-26452c264770@actia.se>
 
In-Reply-To: 
Accept-Language: en-US, sv-SE
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.12.12.30]
x-esetresult: clean, is OK
x-esetid: 37303A2921D729556C7166
Content-Type: text/plain; charset="utf-8"
Content-ID: <95D82F3EDB02794989C32F1AB0E1EAEA@actia.se>
Content-Transfer-Encoding: base64
MIME-Version: 1.0

SGkgQmVydHJhbmQsDQoNCk9uIDMvMjEvMjQgMTc6MTUsIEJlcnRyYW5kIE1hcnF1aXMgd3JvdGU6
DQo+IEhpIEpvaG4sDQo+IA0KPj4gT24gMjEgTWFyIDIwMjQsIGF0IDE3OjA1LCBKb2huIEVybmJl
cmcgPGpvaG4uZXJuYmVyZ0BhY3RpYS5zZT4gd3JvdGU6DQo+Pg0KPj4gSGkgQmVydHJhbmQsDQo+
Pg0KPj4gT24gMy8yMS8yNCAwODo0MSwgQmVydHJhbmQgTWFycXVpcyB3cm90ZToNCj4+PiBIaSwN
Cj4+Pg0KPj4+PiBPbiAyMCBNYXIgMjAyNCwgYXQgMTg6NDAsIEp1bGllbiBHcmFsbCA8anVsaWVu
QHhlbi5vcmc+IHdyb3RlOg0KPj4+Pg0KPj4+PiBIaSBKb2huLA0KPj4+Pg0KPj4+PiBPbiAyMC8w
My8yMDI0IDE2OjI0LCBKb2huIEVybmJlcmcgd3JvdGU6DQo+Pj4+PiBIaSBCZXJ0cmFuZCwNCj4+
Pj4+IE9uIDMvMTMvMjQgMTE6MDcsIEJlcnRyYW5kIE1hcnF1aXMgd3JvdGU6DQo+Pj4+Pj4gSGks
DQo+Pj4+Pj4NCj4+Pj4+Pj4gT24gOCBNYXIgMjAyNCwgYXQgMTU6MDQsIEp1bGllbiBHcmFsbCA8
anVsaWVuQHhlbi5vcmc+IHdyb3RlOg0KPj4+Pj4+Pg0KPj4+Pj4+PiBIaSBKb2huLA0KPj4+Pj4+
Pg0KPj4+Pj4+PiBUaGFuayB5b3UgZm9yIHRoZSByZXBseS4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gT24g
MDgvMDMvMjAyNCAxMzo0MCwgSm9obiBFcm5iZXJnIHdyb3RlOg0KPj4+Pj4+Pj4gT24gMy83LzI0
IDAwOjA3LCBKdWxpZW4gR3JhbGwgd3JvdGU6DQo+Pj4+Pj4+Pj4+IFBpbmcgb24gdGhlIHdhdGNo
ZG9nIGRpc2N1c3Npb24gYml0cy4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IFNvcnJ5IGZvciB0aGUg
bGF0ZSByZXBseS4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IE9uIDA2LzAzLzIwMjQgMTM6MTMsIEpv
aG4gRXJuYmVyZyB3cm90ZToNCj4+Pj4+Pj4+Pj4gT24gMi85LzI0IDE0OjE0LCBKb2huIEVybmJl
cmcgd3JvdGU6DQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+ICAgICAgICogSU1YX1NJUF9USU1F
Ul8qOiAgVGhpcyBzZWVtcyB0byBiZSByZWxhdGVkIHRvIHRoZSB3YXRjaGRvZy4NCj4+Pj4+Pj4+
Pj4+PiBTaG91bGRuJ3QgZG9tMCByZWx5IG9uIHRoZSB3YXRjaGRvZyBwcm92aWRlZCBieSBYZW4g
aW5zdGVhZD8gU28gdGhvc2UNCj4+Pj4+Pj4+Pj4+PiBjYWxsIHdpbGwgYmUgdXNlZCBieSBYZW4u
DQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4gVGhhdCBpcyBpbmRlZWQgYSB3YXRjaGRvZyBTSVAs
IGFuZCBhbHNvIGZvciBzZXR0aW5nIHRoZSBTb0MgaW50ZXJuYWwgUlRDDQo+Pj4+Pj4+Pj4+PiBp
ZiBpdCBpcyBiZWluZyB1c2VkLg0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+IEkgbG9va2VkIGFy
b3VuZCBpZiB0aGVyZSB3YXMgcHJldmlvdXMgZGlzY3Vzc2lvbiBhbmQgb25seSByZWFsbHkNCj4+
Pj4+Pj4+Pj4+IGZvdW5kIFszXS4NCj4+Pj4+Pj4+Pj4+IElzIHRoZSB4ZW4veGVuL2luY2x1ZGUv
d2F0Y2hkb2cuaCBoZWFkZXIgbWVhbnQgdG8gYmUgZm9yIHRoaXMga2luZCBvZg0KPj4+Pj4+Pj4+
Pj4gd2F0Y2hkb2cgc3VwcG9ydCBvciBpcyB0aGF0IG1vcmUgZm9yIHRoZSBWTSB3YXRjaGRvZz8g
TG9va2luZyBhdCB0aGUgeDg2DQo+Pj4+Pj4+Pj4+PiBBQ1BJIE5NSSB3YXRjaGRvZyBpdCBzZWVt
cyBsaWtlIHRoZSBmb3JtZXIsIGJ1dCBJIGhhdmUgbmV2ZXIgd29ya2VkIHdpdGgNCj4+Pj4+Pj4+
Pj4+IHg4NiBub3IgQUNQSS4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IGluY2x1ZGUvd2F0Y2hkb2cu
aCBjb250YWlucyBoZWxwZXIgdG8gY29uZmlndXJlIHRoZSB3YXRjaGRvZyBmb3IgWGVuLiBXZQ0K
Pj4+Pj4+Pj4+IGFsc28gaGF2ZSBwZXItVk0gd2F0Y2hkb2cgYW5kIHRoaXMgaXMgY29uZmlndXJl
ZCBieSB0aGUgaHlwZXJjYWxsDQo+Pj4+Pj4+Pj4gU0NIRURPUF93YXRjaGRvZy4NCj4+Pj4+Pj4+
Pg0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+IEN1cnJlbnRseSBmb3J3YXJkaW5nIGl0IHRvIERv
bTAgaGFzIG5vdCBjYXVzZWQgYW55IHdhdGNoZG9nIHJlc2V0cyB3aXRoDQo+Pj4+Pj4+Pj4+PiBv
dXIgd2F0Y2hkb2cgdGltZW91dCBzZXR0aW5ncywgb3VyIHNwZWNpZmljIERvbTAgc2V0dXAgYW5k
IFZNIGNvdW50Lg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gSUlVQywgdGhlIFNNQyBBUEkgZm9yIHRo
ZSB3YXRjaGRvZyB3b3VsZCBiZSBzaW1pbGFyIHRvIHRoZSBBQ1BJIE5NSQ0KPj4+Pj4+Pj4+IHdh
dGNoZG9nLiBTbyBJIHRoaW5rIGl0IHdvdWxkIG1ha2UgbW9yZSBzZW5zZSBpZiB0aGlzIGlzIG5v
dCBleHBvc2VkIHRvDQo+Pj4+Pj4+Pj4gZG9tMCAoZXZlbiBpZiBYZW4gaXMgZG9pbmcgbm90aGlu
ZyB3aXRoIGl0KS4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IENhbiB5b3UgdHJ5IHRvIGhpZGUgdGhl
IFNNQ3MgYW5kIGNoZWNrIGlmIGRvbTAgc3RpbGwgYmVoYXZlIHByb3Blcmx5Pw0KPj4+Pj4+Pj4+
DQo+Pj4+Pj4+Pj4gQ2hlZXJzLA0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBUaGlzIFNNQyBtYW5hZ2Vz
IGEgaGFyZHdhcmUgd2F0Y2hkb2csIGlmIGl0J3Mgbm90IHBpbmdlZCB3aXRoaW4gYQ0KPj4+Pj4+
Pj4gc3BlY2lmaWMgaW50ZXJ2YWwgdGhlIGVudGlyZSBib2FyZCByZXNldHMuDQo+Pj4+Pj4+DQo+
Pj4+Pj4+IERvIHlvdSBrbm93IHdoYXQncyB0aGUgZGVmYXVsdCBpbnRlcnZhbD8gSXMgaXQgbGFy
Z2UgZW5vdWdoIHNvIFhlbiArIGRvbTAgY2FuIGJvb3QgKGF0IGxlYXN0IHVwIHRvIHdoZW4gdGhl
IHdhdGNoZG9nIGRyaXZlciBpcyBpbml0aWFsaXplZCk/DQo+Pj4+Pj4+DQo+Pj4+Pj4+PiBJZiBJ
IGJsb2NrIHRoZSBTTUNzIHRoZSB3YXRjaGRvZyBkcml2ZXIgaW4gRG9tMCB3aWxsIGZhaWwgdG8g
cGluZyB0aGUNCj4+Pj4+Pj4+IHdhdGNoZG9nLCB0cmlnZ2VyaW5nIGEgYm9hcmQgcmVzZXQgYmVj
YXVzZSB0aGUgc3lzdGVtIGxvb2tzIHRvIGhhdmUNCj4+Pj4+Pj4+IGJlY29tZSB1bnJlc3BvbnNp
dmUuIFRoZSByZWFzb24gdGhpcyBwYXRjaCBzZXQgc3RhcnRlZCBpcyBiZWNhdXNlIHdlDQo+Pj4+
Pj4+PiBjb3VsZG4ndCBwaW5nIHRoZSB3YXRjaGRvZyB3aGVuIHJ1bm5pbmcgd2l0aCBYZW4uDQo+
Pj4+Pj4+PiBJbiBvdXIgc3BlY2lmaWMgc3lzdGVtIHRoZSBib290bG9hZGVyIGVuYWJsZXMgdGhl
IHdhdGNoZG9nIGFzIGVhcmx5IGFzDQo+Pj4+Pj4+PiBwb3NzaWJsZSBzbyB0aGF0IHdlIGNhbiBn
ZXQgd2F0Y2hkb2cgcHJvdGVjdGlvbiBmb3IgYXMgbXVjaCBvZiB0aGUgYm9vdA0KPj4+Pj4+Pj4g
YXMgd2UgcG9zc2libHkgY2FuLg0KPj4+Pj4+Pj4gU28sIGlmIHdlIGFyZSB0byBibG9jayB0aGUg
U01DIGZyb20gRG9tMCwgdGhlbiBYZW4gbmVlZHMgdG8gdGFrZSBvdmVyDQo+Pj4+Pj4+PiB0aGUg
cGluZ2luZy4gSXQgY291bGQgYmUgaW1wbGVtZW50ZWQgc2ltaWxhcmx5IHRvIHRoZSBOTUkgd2F0
Y2hkb2csDQo+Pj4+Pj4+PiBleGNlcHQgdGhhdCB0aGUgc3lzdGVtIHdpbGwgcmVzZXQgaWYgdGhl
IHBpbmcgaXMgbWlzc2VkIHJhdGhlciB0aGFuDQo+Pj4+Pj4+PiBiYWNrdHJhY2UuDQo+Pj4+Pj4+
PiBJdCB3b3VsZCBhbHNvIG1lYW4gdGhhdCBYZW4gd2lsbCBnZXQgYSB3aG9sZSB3YXRjaGRvZyBk
cml2ZXItY2F0ZWdvcnkNCj4+Pj4+Pj4+IGR1ZSB0byB0aGUgd2F0Y2hkb2cgYmVpbmcgdmVuZG9y
IGFuZCBzb21ldGltZXMgZXZlbiBTb0Mgc3BlY2lmaWMgd2hlbiBpdA0KPj4+Pj4+Pj4gY29tZXMg
dG8gQXJtLg0KPj4+Pj4+Pj4gTXkgdW5kZXJzdGFuZGluZyBvZiB0aGUgZG9tYWluIHdhdGNoZG9n
IGNvZGUgaXMgdGhhdCB0b2RheSB0aGUgZG9tYWluDQo+Pj4+Pj4+PiBuZWVkcyB0byBjYWxsIFND
SEVET1Bfd2F0Y2hkb2cgYXQgbGVhc3Qgb25jZSB0byBzdGFydCB0aGUgd2F0Y2hkb2cNCj4+Pj4+
Pj4+IHRpbWVyLiBTaW5jZSB3YXRjaGRvZyBwcm90ZWN0aW9uIHRocm91Z2ggdGhlIHdob2xlIGJv
b3QgcHJvY2VzcyBpcw0KPj4+Pj4+Pj4gZGVzaXJhYmxlIHdlJ2QgbmVlZCBzb21lIGNvcmUgY2hh
bmdlcywgc3VjaCBhcyBhbiBvcHRpb24gdG8gc3RhcnQgdGhlDQo+Pj4+Pj4+PiBkb21haW4gd2F0
Y2hkb2cgb24gaW5pdC4gPg0KPj4+Pj4+Pj4gSXQncyBxdWl0ZSBhIGJpZyBjaGFuZ2UgdG8gbWFr
ZQ0KPj4+Pj4+Pg0KPj4+Pj4+PiBGb3IgY2xhcmlmaWNhdGlvbiwgYWJvdmUgeW91IHNlZW0gdG8g
bWVudGlvbiB0d28gY2hhbmdlczoNCj4+Pj4+Pj4NCj4+Pj4+Pj4gMSkgQWxsb3cgWGVuIHRvIHVz
ZSB0aGUgSFcgd2F0Y2hkb2cNCj4+Pj4+Pj4gMikgQWxsb3cgdGhlIGRvbWFpbiB0byB1c2UgdGhl
IHdhdGNoZG9nIGVhcmx5DQo+Pj4+Pj4+DQo+Pj4+Pj4+IEkgYW0gYXNzdW1pbmcgYnkgYmlnIGNo
YW5nZSwgeW91IGFyZSByZWZlcnJpbmcgdG8gMj8NCj4+Pj4+Pj4NCj4+Pj4+Pj4gLCB3aGlsZSBJ
IGFtIG5vdCBhZ2FpbnN0IGRvaW5nIGl0IGlmIGl0DQo+Pj4+Pj4+PiBtYWtlcyBzZW5zZSwgSSBu
b3cgd29uZGVyIGlmIFhlbiBzaG91bGQgbWFuYWdlIGhhcmR3YXJlIHdhdGNoZG9ncy4NCj4+Pj4+
Pj4+IExvb2tpbmcgYXQgdGhlIGRvbWFpbiB3YXRjaGRvZyBjb2RlIGl0IGxvb2tzIGxpa2UgaWYg
YSBkb21haW4gZG9lcyBub3QNCj4+Pj4+Pj4+IGdldCBlbm91Z2ggZXhlY3V0aW9uIHRpbWUsIHRo
ZSB3YXRjaGRvZyB3aWxsIG5vdCBiZSBwaW5nZWQgZW5vdWdoIGFuZA0KPj4+Pj4+Pj4gdGhlIGd1
ZXN0IHdpbGwgYmUgcmVzZXQuIFNvIGVpdGhlciB3YXRjaGRvZyBhcHByb2FjaCByZXF1aXJlcyBE
b20wIHRvDQo+Pj4+Pj4+PiBnZXQgZXhlY3V0aW9uIHRpbWUuIERvbTAgYWxzbyBuZWVkcyB0byBz
ZXJ2aWNlIGFsbCB0aGUgUFYgYmFja2VuZHMgaXQncw0KPj4+Pj4+Pj4gcmVzcG9uc2libGUgZm9y
LiBJJ20gbm90IHN1cmUgaXQncyB2YWx1YWJsZSB0byBhZGQgYW5vdGhlciBsYXllciBvZg0KPj4+
Pj4+Pj4gd2F0Y2hkb2cgZm9yIHRoaXMgc2NlbmFyaW8gYXMgdGhlIGVuZCByZXN1bHQgKGNoZWNr
aW5nIHRoYXQgdGhlIGVudGlyZQ0KPj4+Pj4+Pj4gc3lzdGVtIHdvcmtzKSBpcyBhY2hpZXZlZCB3
aXRob3V0IGl0IGFzIHdlbGwuDQo+Pj4+Pj4+PiBTbywgYmVmb3JlIEkgdHJ5IHRvIGZpbmQgdGhl
IHRpbWUgdG8gbWFrZSBhIHByb3Bvc2FsIGZvciBtb3ZpbmcgdGhlDQo+Pj4+Pj4+PiBoYXJkd2Fy
ZSB3YXRjaGRvZyBiaXQgdG8gWGVuLCBkbyB3ZSByZWFsbHkgd2FudCBpdD8NCj4+Pj4+Pj4NCj4+
Pj4+Pj4gVGhhbmtzIGZvciB0aGUgZGV0YWlscy4gR2l2ZW4gdGhhdCB0aGUgd2F0Y2hkb2cgaXMg
ZW5hYmxlZCBieSB0aGUgYm9vdGxvYWRlciwgSSB0aGluayB3ZSB3YW50IFhlbiB0byBkcml2ZSB0
aGUgd2F0Y2hkb2cgZm9yIHR3byByZWFzb25zOg0KPj4+Pj4+PiAxKSBJbiB0cnVlIGRvbTBsZXNz
IGVudmlyb25tZW50LCBkb20wIHdvdWxkIG5vdCBleGlzdA0KPj4+Pj4+PiAyKSBZb3UgYXJlIHJl
bHlpbmcgb24gWGVuICsgRG9tMCB0byBib290IChvciBhdCBsZWFzdCBlbm91Z2ggdG8gZ2V0IHRo
ZSB3YXRjaGRvZyB3b3JraW5nKSB3aXRoaW4gdGhlIHdhdGNoZG9nIGludGVydmFsLg0KPj4+Pj4+
DQo+Pj4+Pj4gRGVmaW5pdGVseSB3ZSBuZWVkIHRvIGNvbnNpZGVyIHRoZSBjYXNlIHdoZXJlIHRo
ZXJlIGlzIG5vIERvbTAuDQo+Pj4+Pj4NCj4+Pj4+PiBJIHRoaW5rIHRoZXJlIGFyZSBpbiBmYWN0
IDMgZGlmZmVyZW50IHVzZSBjYXNlcyBoZXJlOg0KPj4+Pj4+IC0gd2F0Y2hkb2cgZnVsbHkgZHJp
dmVuIGluIGEgZG9tYWluIChkb20wIG9yIGFub3RoZXIpOiB3b3VsZCB3b3JrIGlmIGl0IGlzIGV4
cGVjdGVkDQo+Pj4+Pj4gICAgIHRoYXQgWGVuICsgRG9tYWluIGJvb3QgdGltZSBpcyB1bmRlciB0
aGUgd2F0Y2hkb2cgaW5pdGlhbCByZWZyZXNoIHJhdGUuIEkgdGhpbmsgdGhpcw0KPj4+Pj4+ICAg
ICBjb3VsZCBtYWtlIHNlbnNlIG9uIHNvbWUgYXBwbGljYXRpb25zIHdoZXJlIHlvdXIgc3lzdGVt
IGRlcGVuZHMgb24gYSBzcGVjaWZpYw0KPj4+Pj4+ICAgICBkb21haW4gdG8gYmUgcHJvcGVybHkg
Ym9vdGVkIHRvIHdvcmsuIFRoaXMgd291bGQgcmVxdWlyZSBhbiBpbml0aWFsIHJlZnJlc2ggdGlt
ZQ0KPj4+Pj4+ICAgICBjb25maWd1cmFibGUgaW4gdGhlIGJvb3QgbG9hZGVyIHByb2JhYmx5Lg0K
Pj4+Pj4gVGhpcyBpcyBvdXIgdXNlLWNhc2UuIF4NCj4+Pj4+IE91ciBkb20wIGlzIG1vbml0b3Jp
bmcgYW5kIG1hbmFnaW5nIHRoZSBvdGhlciBkb21haW5zIGluIG91ciBzeXN0ZW0uDQo+Pj4+PiBX
aXRob3V0IGRvbTAgd29ya2luZyB0aGUgc3lzdGVtIGlzbid0IHJlYWxseSB3b3JraW5nIGFzIGEg
d2hvbGUuDQo+Pj4+PiBASnVsaWVuOiBXb3VsZCB5b3UgYmUgb2sgd2l0aCB0aGUgcGF0Y2ggc2V0
IGNvbnRpbnVpbmcgaW4gdGhlIGRpcmVjdGlvbg0KPj4+Pj4gb2YgdGhlDQo+Pj4+PiBvcmlnaW5h
bCBwcm9wb3NhbCwgbGV0dGluZyBhbm90aGVyIHBhcnR5IChvciBtZSBhdCBhIGxhdGVyIHRpbWUp
IGltcGxlbWVudA0KPj4+Pj4gdGhlIGZ1bGx5IGRyaXZlbiBieSBYZW4gb3B0aW9uPw0KPj4+PiBJ
IGFtIGNvbmNlcm5lZCBhYm91dCB0aGlzIHBhcnRpY3VsYXIgcG9pbnQgZnJvbSBCZXJ0cmFuZDoN
Cj4+Pj4NCj4+Pj4gIndvdWxkIHdvcmsgaWYgaXQgaXMgZXhwZWN0ZWQgdGhhdCBYZW4gKyBEb21h
aW4gYm9vdCB0aW1lIGlzIHVuZGVyIHRoZSB3YXRjaGRvZyBpbml0aWFsIHJlZnJlc2ggcmF0ZS4i
DQo+Pj4+DQo+Pj4+IEhvdyB3aWxsIGEgdXNlciBiZSBhYmxlIHRvIGZpZ3VyZSBvdXQgaG93IHRv
IGluaXRpYWxseSBjb25maWd1cmUgdGhlIHdhdGNoZG9nPyBJcyB0aGlzIHNvbWV0aGluZyB5b3Ug
Y2FuIGVhc2lseSBjb25maWd1cmUgaW4gdGhlIGJvb3Rsb2FkZXIgYXQgcnVudGltZT8NCj4+DQo+
PiBJZiB5b3UgZ28gdGhyb3VnaCB0aGUgdHJvdWJsZSBvZiBlbmFibGluZyB0aGUgd2F0Y2hkb2cg
aW4gdGhlIGJvb3Rsb2FkZXIgeW91DQo+PiB1c3VhbGx5IGtub3cgd2hhdCB5b3UncmUgZG9pbmcg
YW5kIHNldCB0aGUgdGltZW91dCB5b3Vyc2VsZi4NCj4+DQo+PiBTaW5jZSBvdXIgc3lzdGVtcyBj
YW4gYmUgbW91bnRlZCBpbiByZWFsbHkgYW5ub3lpbmcgbG9jYXRpb25zIChib3RoIGluDQo+PiBp
bnN0YWxsYXRpb25zIGFuZCB3b3JsZC13aXNlKSB3ZSBuZWVkIGFzIG11Y2ggYXV0by1yZWNvdmVy
eSBhcyBwb3NzaWJsZSB0bw0KPj4gYXZvaWQgcGVvcGxlIGhhdmluZyB0byB0cmF2ZWwgdG8gY29s
bGVjdCBhIHVuaXQgdGhhdCBqdXN0IG5lZWRlZCBhIHJlc2V0IGR1ZQ0KPj4gdG8gc29tZSB1bmV4
cGVjdGVkIG9ic2N1cmUgaXNzdWUgYXQgc3RhcnR1cC4NCj4gDQo+IEkgZGVmaW5pdGVseSBnZXQg
dGhlIG5lZWQgZG8gbm90IGdldCBtZSB3cm9uZy4NCj4gSSBhbSBqdXN0IGNvbmNlcm5lZCBieSBw
b3RlbnRpYWwgdXNlcnMgaGF2aW5nIHRhcmdldCByZXN0YXJ0aW5nIHdoZW4gdXNpbmcgWGVuIGJl
Y2F1c2Ugb2YgdGhhdCBhbmQgbm90IGtub3dpbmcgd2h5Lg0KPiANCj4+Pg0KPj4+IERlZmluaXRl
bHkgaGVyZSBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gaGF2ZSB0aGUgd2F0Y2hkb2cgdHVybmVkIG9m
ZiBieSBkZWZhdWx0IGFuZCBkb2N1bWVudCBob3cgdG8gZW5hYmxlIGl0IGluIHRoZSBmaXJtd2Fy
ZS4NCj4+Pg0KPj4+IEV2ZW4gaWYgYSBsb25nIHRpbWVvdXQgaXMgY29uZmlndXJlZCBieSBkZWZh
dWx0LCBhIHVzZXIgY291bGQgcnVuIGludG8gdHJvdWJsZSBpZiB1c2luZyBhIGxpbnV4IHdpdGhv
dXQgd2F0Y2hkb2cgb3Igbm90IHJ1bm5pbmcgbGludXggb3IgdXNpbmcgZG9tMGxlc3Mgd2l0aG91
dCBhIGxpbnV4IGhhdmluZyBhY2Nlc3MgdG8gaXQuDQo+Pj4gSSBhZ3JlZSB3aXRoIEp1bGllbiBo
ZXJlIHRoYXQgdGhlIGNvbmNlcm4gY291bGQgYmUgdGhhdCB1c2VycyB3b3VsZCBjb21lIHRvIHVz
IGluc3RlYWQgb2YgTlhQIGlmIHRoZXJlIGlzIHN5c3RlbSBpcyBkb2luZyBhIHJlc2V0IHdpdGhv
dXQgcmVhc29ucyBhZnRlciBzb21lIHNlY29uZHMgb3IgbWludXRlcy4NCj4+DQo+PiBJIGNvdWxk
IGFkZCBteXNlbGYgYXMgYSByZXZpZXdlciBmb3IgdGhlIGlNWCBwYXJ0cyBpZiB0aGF0IGhlbHBz
IHJvdXRpbmcNCj4+IHN1Y2gNCj4+IHF1ZXN0aW9ucyAoYW5kIGZ1dHVyZSBwYXRjaGVzKSBhbHNv
IHRvIG1lLiBXZSBoYXZlIGV4cGVyaWVuY2Ugd2l0aCB0aGUgUVhQLA0KPj4gYW5kIHRoZSBRTSAo
Zm9yIHRoZSBzdXBwb3J0ZWQgcGFydHMgYnkgdGhpcyBwYXRjaCBzZXQpIGlzIGlkZW50aWNhbC4N
Cj4+DQo+PiBXb3VsZCB0aGF0IGhlbHAgd2l0aCB0aGUgY29uY2VybnM/DQo+IA0KPiBEZWZpbml0
ZWx5IGl0IGNvdWxkIGhlbHAuDQoNCkknbGwgZmlndXJlIG91dCBob3cgdG8gaW5jbHVkZSBteXNl
bGYgaW4gdGhlIE1BSU5UQUlORVJTIGZpbGUgZm9yIHRoZSANCm5leHQgc3Bpbi4NCg0KPiANCj4+
DQo+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4gT3ZlcmFsbCwgSSBhbSBub3QgZm9yIHRoaXMgYXBwcm9h
Y2ggYXQgbGVhc3QgaW4gdGhlIGN1cnJlbnQgc3RhdHVzLiBJIHdvdWxkIGJlIG1vcmUgaW5jbGlu
ZWQgaWYgdGhlcmUgYXJlIHNvbWUgZG9jdW1lbnRhdGlvbnMgZXhwbGFpbmluZyBob3cgdGhpcyBp
cyBzdXBwb3NlZCB0byBiZSBjb25maWd1cmVkIG9uIE5YUCwgc28gb3RoZXJzIGNhbiB1c2UgdGhl
IGNvZGUuDQo+Pj4+DQo+Pj4+IEFueXdheSwgdGhpcyBpcyB3aHkgd2UgaGF2ZSBtdWx0aXBsZSBB
cm0gbWFpbnRhaW5lcnMgZm9yIHRoaXMga2luZCBvZiBzaXR1YXRpb24uIElmIHRoZXkgb3RoZXIg
YWdyZWVzIHdpdGggeW91LCB0aGVuIHRoZXkgY2FuIGFjayB0aGUgcGF0Y2ggYW5kIHRoaXMgY2Fu
IGJlIG1lcmdlZC4NCj4+Pg0KPj4+IEkgYWdyZWUgd2l0aCBTdGVmYW5vIHRoYXQgaXQgd291bGQg
YmUgZ29vZCB0byBoYXZlIHRob3NlIGJvYXJkIHN1cHBvcnRlZC4NCj4+Pg0KPj4+IE9uZSB0aGlu
ZyBpIGNvdWxkIHN1Z2dlc3QgdW50aWwgdGhlcmUgaXMgYSB3YXRjaGRvZyBkcml2ZXIgaW5zaWRl
IFhlbiBpcyB0byBoYXZlIGEgY2xlYXIgV2FybmluZyBhdCBYZW4gYm9vdCBvbiB0aG9zZSBib2Fy
ZHMgaW4gdGhlIGNvbnNvbGUgc28gdGhhdCB3ZSBjb3VsZCBhdCBsZWFzdCBpZGVudGlmeSB0aGUg
cmVhc29uIGVhc2lseSBpZiBhIHJlc2V0IG9jY3VycyBmb3Igc29tZW9uZS4NCj4+DQo+PiBIb3cg
ZG8gb3RoZXIgU29DcyBkZWFsIHdpdGggdGhpcyBjdXJyZW50bHk/IFRoZSBpTVggU29DcyBhcmVu
J3QgdGhlIG9ubHkNCj4+IG9uZXMNCj4+IHdpdGggYSB3YXRjaGRvZywganVzdCB0aGUgZmlyc3Qg
b25lIGFkZGVkIHRvIFhlbiB0aGF0IHBpbmdzIHRoZSB3YXRjaGRvZw0KPj4gb3Zlcg0KPj4gYW4g
U01DLiBXaGF0IGFib3V0IHRoZSBPTUFQcywgdGhlIFItQ2FycywgWGlsaW54J3MsIEV4eW5vcycg
YW5kIHNvIG9uPw0KPiANCj4gQXMgZmFyIGFzIEkga25vdyB0aGUgd2F0Y2hkb2cgaXMgdXN1YWxs
eSBub3QgYWN0aXZlIHVudGlsIGEgZHJpdmVyIGFjdGl2YXRlcyBpdC4NCj4gV2hpY2ggbWVhbnMg
dGhhdCBieSBkZWZhdWx0IGl0IHdpbGwgbm90IGZpcmUuDQo+IEhhdmluZyBpdCBhY3RpdmF0ZWQg
YnkgdGhlIGJvb3Rsb2FkZXIgYnkgZGVmYXVsdCBpcyBub3QgdXN1YWwuDQo+IE5vdyBkZWZpbml0
ZWx5IG9uIGEgbG90IG9mIHVzZSBjYXNlcyB0aGUgdXNlcnMgYXJlIGFjdGl2YXRpbmcgaXQgaW4g
dGhlIGJvb2xvYWRlcg0KPiBidXQgdGhlaXIgc3lzdGVtcyBhcmUgZGVzaWduIGZvciBpdC4NCj4g
DQo+IERvIEkgdW5kZXJzdGFuZCB0aGF0IHRoZSBkZWZhdWx0IGJvb3QgbG9hZGVyIGNvbmZpZ3Vy
YXRpb24gaXMgbm90IGFjdGl2YXRpbmcgaXQgb24geW91ciBzaWRlID8NCg0KV2UgYXJlIHVzaW5n
IGEgYm9vdGxvYWRlciBjYWxsZWQgUHVuY2hib290IFsxXSBkZXZlbG9wZWQgYnkgb25lIG9mIG91
ciANCmVtcGxveWVlcy4gV2l0aCBQdW5jaGJvb3QgeW91IGhhdmUgdG8gZXhwbGljaXRseSB3cml0
ZSB0aGUgY29kZSB0byANCmVuYWJsZSB0aGUgd2F0Y2hkb2cgeW91cnNlbGYuIEluIHUtYm9vdCB5
b3UgbmVlZCB0byBlbmFibGUgdGhlIHdhdGNoZG9nIA0KZHJpdmVycyBhbmQgY29uZmlndXJlIHRo
ZSB3YXRjaGRvZyBmaXJzdCBiZWZvcmUgaXQgaXMgc3RhcnRlZC4gSSBkb24ndCANCmtub3cgaG93
IHRoZSBzaXR1YXRpb24gaXMgaW4gb3RoZXIgYm9vdGxvYWRlcnMgc3VjaCBhcyBCYXJlQm94Lg0K
DQpCZXN0IHJlZ2FyZHMgLy8gSm9obiBFcm5iZXJnDQoNClsxXTogaHR0cHM6Ly9naXRodWIuY29t
L2pvbmFzYmxpeHQvcHVuY2hib290


From xen-devel-bounces@lists.xenproject.org Mon Mar 25 12:21:58 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 12:21:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697731.1088794 (Exim 4.92)
	(envelope-from )
	id 1rojKu-0003Ke-Ie; Mon, 25 Mar 2024 12:21:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697731.1088794; Mon, 25 Mar 2024 12:21:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rojKu-0003KX-F0; Mon, 25 Mar 2024 12:21:56 +0000
Received: by outflank-mailman (input) for mailman id 697731;
 Mon, 25 Mar 2024 12:21:55 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rojKt-0003KR-7T
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 12:21:55 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 42c2051f-eaa2-11ee-a1ef-f123f15fe8a2;
 Mon, 25 Mar 2024 13:21:52 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 6592060DC4;
 Mon, 25 Mar 2024 12:21:51 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6EB70C433F1;
 Mon, 25 Mar 2024 12:21:49 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 42c2051f-eaa2-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1711369311;
	bh=AE1dlvv5b1X/poInI7A8TX+ny663XWX7KjBuB1GkxY4=;
	h=Date:Subject:To:References:Cc:From:In-Reply-To:From;
	b=kGwx5TGgfuiYR8ZX8r/AtMyeLggJuegzjC9l/G4X1/Qzv21sh0fTjWZqaC+7XhUf/
	 mZ8cDfDBiUyad17Kal5Xpn9pP1ANsySpsyBLggwXMOef21eBYDRQEsF9qo4FcX3tAp
	 qFz55xt+zFT5zA5whauc4NEZrdQFfTvtAMRFawak1XDU+iC6UGn1NyT86COpmBJYDS
	 9o3qM3Q5YkVM0zzt3qvraD0vBneBuJvjJcjYujUibVLhZeOW7BS5k+3STXip5HjKg9
	 SVUKIO53oQGGji6/gB8keEPd9PeyP+zi13tSRs3Ri4OQkisGd5BiWOtEEoH/WDLG5i
	 UqoCOROiIbH6A==
Message-ID: <1cde0059-d319-4a4f-a68d-3b3ffeb3da20@kernel.org>
Date: Mon, 25 Mar 2024 13:21:47 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Xen NIC driver have page_pool memory leaks
Content-Language: en-US
To: Arthur Borsboom ,
 Ilias Apalodimas 
References: 
Cc: Netdev , Paul Durrant ,
 Wei Liu ,
 "xen-devel@lists.xenproject.org" 
From: Jesper Dangaard Brouer 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Arthur,

(Answer inlined below, which is custom on this mailing list)

On 23/03/2024 14.23, Arthur Borsboom wrote:
> Hi Jesper,
> 
> After a recent kernel upgrade 6.7.6 > 6.8.1 all my Xen guests on Arch
> Linux are dumping kernel traces.
> It seems to be indirectly caused by the page pool memory leak
> mechanism, which is probably a good thing.
> 
> I have created a bug report, but there is no response.
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=218618
> 
> I am uncertain where and to whom I need to report this page leak.
> Can you help me get this issue fixed?

I'm the page_pool maintainer, but as you say yourself in comment 2 then
since dba1b8a7ab68 ("mm/page_pool: catch page_pool memory leaks") this
indicated there is a problem in the xen_netfront driver, which was
previously not visible.

Cc'ing the "XEN NETWORK BACKEND DRIVER" maintainers, as this is a driver
bug.  What confuses me it that I cannot find any modules named
"xen_netfront" in the upstream tree.

IPSEC recently had a similar leak bug. That was fixed in commmit [1]
c3198822c6cb ("net: esp: fix bad handling of pages from page_pool").
This xen_netfront driver likely needs a similar fix.

--Jesper

[1] https://git.kernel.org/torvalds/c/c3198822c6cb


Text copied from bugzilla.kernel.org:
-------------------------------------
[88847.284348] Call Trace:
[88847.284354]  
[88847.284361]  dump_stack_lvl+0x47/0x60
[88847.284378]  bad_page+0x71/0x100
[88847.284393]  free_unref_page_prepare+0x236/0x390
[88847.284405]  free_unref_page+0x34/0x180
[88847.284416]  __pskb_pull_tail+0x3ff/0x4a0
[88847.284432]  xennet_poll+0x909/0xa40 [xen_netfront 
12c02fdcf84c692965d9cd6ca5a6ff0a530b4ce9]
[88847.284470]  __napi_poll+0x28/0x1b0
[88847.284483]  net_rx_action+0x2b5/0x370
[88847.284495]  ? handle_irq_desc+0x3e/0x60
[88847.284511]  __do_softirq+0xc9/0x2c8
[88847.284523]  __irq_exit_rcu+0xa3/0xc0
[88847.284536]  sysvec_xen_hvm_callback+0x72/0x90
[88847.284545]  
[88847.284549]  
[88847.284552]  asm_sysvec_xen_hvm_callback+0x1a/0x20
[88847.284562] RIP: 0010:pv_native_safe_halt+0xf/0x20
[88847.284572] Code: 22 d7 c3 cc cc cc cc 0f 1f 40 00 90 90 90 90 90 90 
90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 66 90 0f 00 2d e3 13 27 00 fb 
f4  cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90
[88847.284579] RSP: 0018:ffffb2a1800c3e58 EFLAGS: 00000246
[88847.284587] RAX: 0000000000004000 RBX: ffff91358033b864 RCX: 
000051404aebd79d
[88847.284594] RDX: ffff9136f9b00000 RSI: ffff91358033b800 RDI: 
0000000000000001
[88847.284599] RBP: ffff91358033b864 R08: ffffffff9b94dca0 R09: 
0000000000000001
[88847.284604] R10: 0000000000000018 R11: ffff9136f9b331a4 R12: 
ffffffff9b94dca0
[88847.284609] R13: ffffffff9b94dd20 R14: 0000000000000001 R15: 
0000000000000000
[88847.284623]  acpi_safe_halt+0x15/0x30
[88847.284634]  acpi_idle_do_entry+0x2f/0x50
[88847.284644]  acpi_idle_enter+0x7f/0xd0
[88847.284655]  cpuidle_enter_state+0x81/0x440
[88847.284667]  cpuidle_enter+0x2d/0x40
[88847.284678]  do_idle+0x1d8/0x230
[88847.284688]  cpu_startup_entry+0x2a/0x30
[88847.284695]  start_secondary+0x11e/0x140
[88847.284705]  secondary_startup_64_no_verify+0x184/0x18b
[88847.284725]  


From xen-devel-bounces@lists.xenproject.org Mon Mar 25 12:30:08 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 12:30:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697735.1088804 (Exim 4.92)
	(envelope-from )
	id 1rojSl-0004Xp-A0; Mon, 25 Mar 2024 12:30:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697735.1088804; Mon, 25 Mar 2024 12:30:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rojSl-0004XR-6M; Mon, 25 Mar 2024 12:30:03 +0000
Received: by outflank-mailman (input) for mailman id 697735;
 Mon, 25 Mar 2024 12:30:02 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rojSk-0004LT-0Y; Mon, 25 Mar 2024 12:30:02 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rojSj-0001T9-Ql; Mon, 25 Mar 2024 12:30:01 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rojSj-0005kT-Dp; Mon, 25 Mar 2024 12:30:01 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rojSj-0002zF-DU; Mon, 25 Mar 2024 12:30:01 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=WmAUwQ3ttVR4RyZlvC3KE/d9cANINbTo6uLTYwWh4OE=; b=3kivTrh+nOqhi/dMrbCxxV9Ono
	REYFE9Ay4ffncyPLibyJDw824RKF6VXMOj26i34CX6K3vPLYJP12T/+V7LdnwA0Bt1adt/DTAj/h3
	6kRY4Oe70VUVMW5RJP4jl/F8Q80tK7wozXEvR/P231nQhh9MWROznK2nAPhMN0tCkPQo=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 185157: tolerable all pass - PUSHED
X-Osstest-Failures:
    xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    xen=6f6de10ade5ade907f9e3f3c72b7b18f7852d9ff
X-Osstest-Versions-That:
    xen=cbe393b709e0c6c3e2b10c3ac69fbea0abd530fe
From: osstest service owner 
Date: Mon, 25 Mar 2024 12:30:01 +0000

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          16 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  6f6de10ade5ade907f9e3f3c72b7b18f7852d9ff
baseline version:
 xen                  cbe393b709e0c6c3e2b10c3ac69fbea0abd530fe

Last test of basis   185132  2024-03-21 18:02:16 Z    3 days
Testing same since   185157  2024-03-25 10:03:48 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Daniel P. Smith 
  Jan Beulich 
  Julien Grall 
  Nicola Vetrini 
  Oleksii Kurochko 
  Roger Pau Monné 
  Shawn Anastasio 

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-amd64                    pass    
 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
   cbe393b709..6f6de10ade  6f6de10ade5ade907f9e3f3c72b7b18f7852d9ff -> smoke


From xen-devel-bounces@lists.xenproject.org Mon Mar 25 12:33:35 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 12:33:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697741.1088814 (Exim 4.92)
	(envelope-from )
	id 1rojWA-0005gF-PV; Mon, 25 Mar 2024 12:33:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697741.1088814; Mon, 25 Mar 2024 12:33:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rojWA-0005g8-MP; Mon, 25 Mar 2024 12:33:34 +0000
Received: by outflank-mailman (input) for mailman id 697741;
 Mon, 25 Mar 2024 12:33:34 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rojWA-0005g2-4X
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 12:33:34 +0000
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com
 [2a00:1450:4864:20::32a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e4308d4d-eaa3-11ee-afe3-a90da7624cb6;
 Mon, 25 Mar 2024 13:33:32 +0100 (CET)
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-4148a6cc488so4684895e9.3
 for ; Mon, 25 Mar 2024 05:33:32 -0700 (PDT)
Received: from [192.168.21.70] (54-240-197-225.amazon.com. [54.240.197.225])
 by smtp.gmail.com with ESMTPSA id
 l21-20020a05600c4f1500b004148ab95c36sm1780656wmq.41.2024.03.25.05.33.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 25 Mar 2024 05:33:31 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e4308d4d-eaa3-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1711370012; x=1711974812; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:organization:content-language
         :references:cc:to:subject:reply-to:user-agent:mime-version:date
         :message-id:from:from:to:cc:subject:date:message-id:reply-to;
        bh=vmsNGz/SjS01nd2DN2qF7dW1osscxRz3VTWdKl4iAko=;
        b=SZ8cYYu1igi2ClpCeKKb221l4QwBpjCgLQtHoe1+VDSkuXn4+3KFZK1eEUuOBR7yLZ
         8p5dWZiohXinK+3Tmt2QxJeFoYenY9Eol9lEfRUqmaWpmuZuRErQQ1q5kPFaDtAxb2AO
         yki1Vy5NcJmQD7q12t+tbWDk5G/hVO/AxN7G+bNAuOvFyotiDAtnpwtJ5E2E813l4EAj
         MkssD77dpbilp+aGivL+aVUs9QfZgSwXoah95l6eAizMMl1mW1OfYOIaI+Tf5ajAaVWo
         tMmHpMmmKmZ1pFOsqI2/8E8b2W+Ze8u12FCzwLRzQW8s64rM8Szz4AVvh7dewftKAm7A
         Gs2Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711370012; x=1711974812;
        h=content-transfer-encoding:in-reply-to:organization:content-language
         :references:cc:to:subject:reply-to:user-agent:mime-version:date
         :message-id:from:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=vmsNGz/SjS01nd2DN2qF7dW1osscxRz3VTWdKl4iAko=;
        b=htLdeA7H3Ovo5AHkqSdtp+vzHOI594BxsC4JwkuiYwCYCtqmpAMmIKVHnN3c9cCMCw
         VxeN6k4WBOhd/cEmyE5gh0AsSX5vpzy26YTcKprKJ4GW4d19pFHbtRqzAiCEmZFV5hf2
         g1w0nsAQEDGPSrPWC393uTHruHXeoLVg9WjwxmgyNlhJ/kaPfs/K08psAi5Bv6Qk9GHU
         RCBHyh2ktDCkbjzIlHdr4RHed9BYL/pq4hqRaGtYvJnm+Yc4ca0t09pPYGmjZ2Hzbza7
         bZasp7vh6yeKYVewiWkKgUdXNuhixsSX6B1dO7rZ3EQR9JN9+zthPfmOUbFBXNYcV2bn
         m8tQ==
X-Forwarded-Encrypted: i=1; AJvYcCVGLZBT193pgNenD1t9mNo09BXezqrCyBTWEld5wGpAD8GVQrsz67XpYi7pU8kbfMOmFFqyeul0C0PEETQVMrzx8NxGiMLU3g0ENhrkRyw=
X-Gm-Message-State: AOJu0YxY19pGRv3DOr062ik1pc6dmaSLqw5ETHDa7hI9pMx8LMJhMHqy
	UAGYCkEATYaQKlGG+YEguiCDs/KP9+0OTp48w2XueOBveGkk2NHo
X-Google-Smtp-Source: AGHT+IG+27VzqWLIHxcr5Aj7meKj47pkoq0+ixCtIODoAioj8TBpbct8mifSSWcSJFFdnpr7uaRQ4g==
X-Received: by 2002:a05:600c:4792:b0:413:e8db:2c9b with SMTP id k18-20020a05600c479200b00413e8db2c9bmr5309307wmo.40.1711370011823;
        Mon, 25 Mar 2024 05:33:31 -0700 (PDT)
From: Paul Durrant 
X-Google-Original-From: Paul Durrant 
Message-ID: <857282f5-5df6-4ed7-b17e-92aae0cf484a@xen.org>
Date: Mon, 25 Mar 2024 12:33:30 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Reply-To: paul@xen.org
Subject: Re: Xen NIC driver have page_pool memory leaks
To: Jesper Dangaard Brouer ,
 Arthur Borsboom ,
 Ilias Apalodimas 
Cc: Netdev , Wei Liu ,
 "xen-devel@lists.xenproject.org" 
References: 
 <1cde0059-d319-4a4f-a68d-3b3ffeb3da20@kernel.org>
Content-Language: en-US
Organization: Xen Project
In-Reply-To: <1cde0059-d319-4a4f-a68d-3b3ffeb3da20@kernel.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 25/03/2024 12:21, Jesper Dangaard Brouer wrote:
> Hi Arthur,
> 
> (Answer inlined below, which is custom on this mailing list)
> 
> On 23/03/2024 14.23, Arthur Borsboom wrote:
>> Hi Jesper,
>>
>> After a recent kernel upgrade 6.7.6 > 6.8.1 all my Xen guests on Arch
>> Linux are dumping kernel traces.
>> It seems to be indirectly caused by the page pool memory leak
>> mechanism, which is probably a good thing.
>>
>> I have created a bug report, but there is no response.
>>
>> https://bugzilla.kernel.org/show_bug.cgi?id=218618
>>
>> I am uncertain where and to whom I need to report this page leak.
>> Can you help me get this issue fixed?
> 
> I'm the page_pool maintainer, but as you say yourself in comment 2 then
> since dba1b8a7ab68 ("mm/page_pool: catch page_pool memory leaks") this
> indicated there is a problem in the xen_netfront driver, which was
> previously not visible.
> 
> Cc'ing the "XEN NETWORK BACKEND DRIVER" maintainers, as this is a driver
> bug.  What confuses me it that I cannot find any modules named
> "xen_netfront" in the upstream tree.
> 

You should have tried '-' rather than '_' :-)

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/xen-netfront.c




From xen-devel-bounces@lists.xenproject.org Mon Mar 25 13:07:39 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 13:07:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697747.1088824 (Exim 4.92)
	(envelope-from )
	id 1rok32-0001mG-ED; Mon, 25 Mar 2024 13:07:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697747.1088824; Mon, 25 Mar 2024 13:07:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rok32-0001m9-B0; Mon, 25 Mar 2024 13:07:32 +0000
Received: by outflank-mailman (input) for mailman id 697747;
 Mon, 25 Mar 2024 13:07:31 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rok31-0001m3-CL
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 13:07:31 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a1a24664-eaa8-11ee-afe3-a90da7624cb6;
 Mon, 25 Mar 2024 14:07:28 +0100 (CET)
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 by support.bugseng.com (Postfix) with ESMTPA id B24894EE0739;
 Mon, 25 Mar 2024 14:07:27 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a1a24664-eaa8-11ee-afe3-a90da7624cb6
MIME-Version: 1.0
Date: Mon, 25 Mar 2024 14:07:27 +0100
From: Nicola Vetrini 
To: Jan Beulich 
Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com,
 ayan.kumar.halder@amd.com, consulting@bugseng.com,
 andrew.cooper3@citrix.com, roger.pau@citrix.com, bertrand.marquis@arm.com,
 julien@xen.org, xen-devel@lists.xenproject.org
Subject: Re: [XEN PATCH 06/11] xen/efi: address violations of MISRA C Rule
 20.7
In-Reply-To: 
References: 
 <2d3842a990189c37fa12672994b779ad42975235.1711118582.git.nicola.vetrini@bugseng.com>
 
Message-ID: 
X-Sender: nicola.vetrini@bugseng.com
Organization: BUGSENG s.r.l.
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit

On 2024-03-25 10:25, Jan Beulich wrote:
> On 22.03.2024 17:01, Nicola Vetrini wrote:
>> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
>> of macro parameters shall be enclosed in parentheses". Therefore, some
>> macro definitions should gain additional parentheses to ensure that 
>> all
>> current and future users will be safe with respect to expansions that
>> can possibly alter the semantics of the passed-in macro parameter.
>> 
>> No functional change.
>> 
>> Signed-off-by: Nicola Vetrini 
> 
> Seeing this is again touching an imported header, we finally need to 
> settle
> on where to draw the line. The way this is going is that you're 
> proposing
> many small changes which individually all look "small enough". Yet when
> doing so for long enough, the entire header may end up different from 
> its
> original.
> 
> Jan
> 

Ok, if you feel that these (and possibly others) are too many, then I'll 
leave xen/include/efi/* alone and deviate those violations resulting 
from the use of these macros in files that are in scope. I don't think 
there are others from imported headers outside efi, but I'm not 100% 
sure.

>> --- a/xen/include/efi/efiapi.h
>> +++ b/xen/include/efi/efiapi.h
>> @@ -63,7 +63,8 @@ EFI_STATUS
>>      OUT UINT32                      *DescriptorVersion
>>      );
>> 
>> -#define NextMemoryDescriptor(Ptr,Size)  ((EFI_MEMORY_DESCRIPTOR *) 
>> (((UINT8 *) Ptr) + Size))
>> +#define NextMemoryDescriptor(Ptr,Size)  ((EFI_MEMORY_DESCRIPTOR *) \
>> +                                         ((UINT8 *)(Ptr) + (Size)))
>> 
>> 
>>  typedef

-- 
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)


From xen-devel-bounces@lists.xenproject.org Mon Mar 25 14:02:07 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 14:02:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697757.1088833 (Exim 4.92)
	(envelope-from )
	id 1roktd-0000sZ-9H; Mon, 25 Mar 2024 14:01:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697757.1088833; Mon, 25 Mar 2024 14:01:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1roktd-0000sS-6g; Mon, 25 Mar 2024 14:01:53 +0000
Received: by outflank-mailman (input) for mailman id 697757;
 Mon, 25 Mar 2024 14:01:52 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1roktc-0000sI-9e; Mon, 25 Mar 2024 14:01:52 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1roktb-0003Ti-Vv; Mon, 25 Mar 2024 14:01:52 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1roktb-00006t-Jk; Mon, 25 Mar 2024 14:01:51 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1roktb-0004mY-JS; Mon, 25 Mar 2024 14:01:51 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=LUKq9EwmL73kBmIfrFeYq8zq9mGS9B3tz9N7zgf8bi0=; b=LmtHqAO0ltAUp9T41CJLhFYfAv
	4+PdXozKN54v86Sqx8mLKOi8h1XkXoClb45ugk75zPYqMrQOh6sJ0DSInOJt6+tOOgBXCBc/GtZjg
	9Wx4O4yfbv0OXYqyeuIghcruIY1RLqjKC7fnkIUX0KX5USqunhdCb4pA7pC5mJ1idYqQ=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 185155: tolerable FAIL - PUSHED
X-Osstest-Failures:
    linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-qcow2:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-qcow2:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-raw:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-vhd:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    linux=4cece764965020c22cff7665b18a012006359095
X-Osstest-Versions-That:
    linux=5e74df2f8f15eaa1ebbdfc1f6fef27a26d789de8
From: osstest service owner 
Date: Mon, 25 Mar 2024 14:01:51 +0000

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

Failures :-/ but no regressions.

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

version targeted for testing:
 linux                4cece764965020c22cff7665b18a012006359095
baseline version:
 linux                5e74df2f8f15eaa1ebbdfc1f6fef27a26d789de8

Last test of basis   185152  2024-03-24 18:41:47 Z    0 days
Testing same since   185155  2024-03-25 03:25:27 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Ard Biesheuvel 
  Kazuma Kondo 
  KONDO KAZUMA(近藤　和真) 
  Linus Torvalds 
  Oleksandr Tymoshenko 

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-libvirt-qcow2                               pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-xl-qcow2                                    pass    
 test-amd64-amd64-libvirt-raw                                 pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-amd64-amd64-xl-raw                                      pass    
 test-armhf-armhf-xl-raw                                      pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-libvirt-vhd                                 pass    
 test-amd64-amd64-xl-vhd                                      pass    
 test-arm64-arm64-xl-vhd                                      pass    


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

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

Explanation of these 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 :

hint: The 'hooks/update' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
hint: The 'hooks/post-receive' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
hint: The 'hooks/post-update' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
To xenbits.xen.org:/home/xen/git/linux-pvops.git
   5e74df2f8f15..4cece7649650  4cece764965020c22cff7665b18a012006359095 -> tested/linux-linus


From xen-devel-bounces@lists.xenproject.org Mon Mar 25 14:30:44 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 14:30:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697766.1088844 (Exim 4.92)
	(envelope-from )
	id 1rolLT-0004b2-GO; Mon, 25 Mar 2024 14:30:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697766.1088844; Mon, 25 Mar 2024 14:30:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rolLT-0004av-CD; Mon, 25 Mar 2024 14:30:39 +0000
Received: by outflank-mailman (input) for mailman id 697766;
 Mon, 25 Mar 2024 14:30:38 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rolLS-0004ap-7p
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 14:30:38 +0000
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com
 [2a00:1450:4864:20::52a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3f3bbab6-eab4-11ee-afe3-a90da7624cb6;
 Mon, 25 Mar 2024 15:30:37 +0100 (CET)
Received: by mail-ed1-x52a.google.com with SMTP id
 4fb4d7f45d1cf-56bdf81706aso4227877a12.2
 for ; Mon, 25 Mar 2024 07:30:37 -0700 (PDT)
Received: from [10.80.5.21] (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 k3-20020a17090627c300b00a45ffe583acsm3117597ejc.187.2024.03.25.07.30.36
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 25 Mar 2024 07:30:36 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3f3bbab6-eab4-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1711377037; x=1711981837; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=FUFGRGZGIt4FLE2TwoZp+n1GWyfWt97B0lI685Irlvk=;
        b=V/Tgq7e3n1MVQ+8djUJbWmZBuXy4EWVcnFtsDZ6TXiXnVd7GOvnlQM1nXaLN8lWhpe
         KOKax+pUK7/My1RogMhFmrXpH22kaqXHQIvRXFWVJbOAoUSeI8bxscq6N1MDmag84vpW
         kor1jewpy+JZ1PF4ivIJGoe7hzrRybpal2h6s=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711377037; x=1711981837;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=FUFGRGZGIt4FLE2TwoZp+n1GWyfWt97B0lI685Irlvk=;
        b=J2LDjI/CxSgkTl6JaV6FQM+nQERWYaj789xfhu/TNrQTObQT1YdjlpHDW/3NyOcg93
         MYfQvIUbDeYN2rOpzz+PDYQ8/3cZQUEABb3/T+I7oQVCFGAgOmMa/jHUnjvUa3wdfCgU
         EOeMM22RyskYuR6IDUkc5ar1+6b8Bu4ykOzTbQS+DmmCsN9+PtuJbjxYNT8KHmr+1u5l
         5G+3gIOvt/dw7rGb7yZwOPQ9S/RY6ctwNrP4smpokRErL5MtnFG3HLJRcNQMFfahkReV
         KL+i/HRmTqK5Aie5qr8I23mVvZXn5BYVJkoqs+092L+QsP1ENI4VWig22/vXypA6i5XU
         plmQ==
X-Forwarded-Encrypted: i=1; AJvYcCUuFEVKvjFi9giP4AqGBpZgB8nf1i9l42/zP3NFgcTXsRwsZ4fxtZdiXIHpNwwpMUXP0i84IoQvne+pXIVhkhtcSqNG2v+6fLFoKKeOM50=
X-Gm-Message-State: AOJu0Yz2aY1btux+fimOgpiFW5PS7CZWSfTiAVdmEm5apN63Pq9QZ0GF
	sP6qyO6QtAHqSvAhOyYuGqhIWy4DaHZAAaPZtY9UP0OXEA1EDRsp0WoHrFTpqHI=
X-Google-Smtp-Source: AGHT+IGL9I45aEre7LYYvf81v6lrp1wsE4W2N58aVft77d0lVnQc8TXx9OCrt+TaW6wI+xZ6DzJOaA==
X-Received: by 2002:a17:906:a197:b0:a47:3437:7fe8 with SMTP id s23-20020a170906a19700b00a4734377fe8mr4818212ejy.51.1711377036710;
        Mon, 25 Mar 2024 07:30:36 -0700 (PDT)
Message-ID: <8895fcce-3738-4bd6-9127-56296369e3e6@cloud.com>
Date: Mon, 25 Mar 2024 14:30:35 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH] tools: add x2APIC entries in MADT based on APIC ID
To: Jan Beulich , Matthew Barnes 
Cc: Wei Liu , Anthony PERARD ,
 Xen-devel 
References: 
 <32a4de1e-94fe-4b44-b95c-55cd1ec7e7e4@suse.com>
Content-Language: en-GB
From: Alejandro Vallejo 
In-Reply-To: <32a4de1e-94fe-4b44-b95c-55cd1ec7e7e4@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Hi,

On 14/03/2024 13:50, Jan Beulich wrote:
> On 13.03.2024 16:35, Matthew Barnes wrote:
>> libacpi is a tool that is used by libxl (for PVH guests) and hvmloader
>> (for HVM guests) to construct ACPI tables for guests.
>>
>> Currently, libacpi only uses APIC entries to enumerate processors for
>> guests in the MADT.
>>
>> The APIC ID field in APIC entries is an octet big, which is fine for
>> xAPIC IDs, but not so for sufficiently large x2APIC IDs.
> 
> Yet where would those come from? I can see that down the road we will
> have such, but right now I don't think we do. Without saying so, this
> change could be mistaken for a fix of an active bug.

It's worth adding some context here.

You're quite right in that it's not immediately needed now, but with the
work done on improving the state of CPU topologies exposed to guests[1]
the strict binding between APIC ID and vCPU ID breaks. It's not hard to
imagine sparsity in the APIC ID space forcing the maximum one to peak
beyond 254. The generator present in that series tries to be
conservative and avoid it, but general topologies can theoretically
waste copious amounts of APIC ID space (i.e: by reserving more width
than strictly required to represent IDs of a certain level), and
exposing the host topology sensibly becomes difficult if we're subject
to limitations the host does not have.

[1]
https://lore.kernel.org/xen-devel/20240109153834.4192-1-alejandro.vallejo@cloud.com/

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Mon Mar 25 14:48:03 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 14:48:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697770.1088854 (Exim 4.92)
	(envelope-from )
	id 1rolcD-0006L9-Tr; Mon, 25 Mar 2024 14:47:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697770.1088854; Mon, 25 Mar 2024 14:47:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rolcD-0006L2-Q0; Mon, 25 Mar 2024 14:47:57 +0000
Received: by outflank-mailman (input) for mailman id 697770;
 Mon, 25 Mar 2024 14:47:56 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rolcC-0006Kw-0Z
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 14:47:56 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a85cb61f-eab6-11ee-a1ef-f123f15fe8a2;
 Mon, 25 Mar 2024 15:47:52 +0100 (CET)
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 by support.bugseng.com (Postfix) with ESMTPA id 0CD1B4EE0739;
 Mon, 25 Mar 2024 15:47:52 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a85cb61f-eab6-11ee-a1ef-f123f15fe8a2
MIME-Version: 1.0
Date: Mon, 25 Mar 2024 15:47:52 +0100
From: Nicola Vetrini 
To: Jan Beulich 
Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com,
 ayan.kumar.halder@amd.com, consulting@bugseng.com,
 andrew.cooper3@citrix.com, roger.pau@citrix.com, bertrand.marquis@arm.com,
 julien@xen.org, xen-devel@lists.xenproject.org
Subject: Re: [XEN PATCH 08/11] x86/altcall: address violations of MISRA C Rule
 20.7
In-Reply-To: <072aa89b-2a03-4823-af72-28a2a882b373@suse.com>
References: 
 <653ead65966226f50b0e4ae0268912c9710f9dba.1711118582.git.nicola.vetrini@bugseng.com>
 <072aa89b-2a03-4823-af72-28a2a882b373@suse.com>
Message-ID: 
X-Sender: nicola.vetrini@bugseng.com
Organization: BUGSENG s.r.l.
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit

On 2024-03-25 10:38, Jan Beulich wrote:
> On 22.03.2024 17:01, Nicola Vetrini wrote:
>> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
>> of macro parameters shall be enclosed in parentheses". Therefore, some
>> macro definitions should gain additional parentheses to ensure that 
>> all
>> current and future users will be safe with respect to expansions that
>> can possibly alter the semantics of the passed-in macro parameter.
>> 
>> No functional change.
>> 
>> Signed-off-by: Nicola Vetrini 
> 
> Hmm. These macros are, at least in part, hard to read already. The 
> added
> parentheses, while necessary when following the rule to the letter, are
> making things worse, even if just slightly. I therefore have a proposal 
> /
> question:
> 
>> --- a/xen/arch/x86/include/asm/alternative.h
>> +++ b/xen/arch/x86/include/asm/alternative.h
>> @@ -243,28 +243,28 @@ extern void alternative_branches(void);
>> 
>>  #define alternative_vcall0(func) ({             \
>>      ALT_CALL_NO_ARG1;                           \
>> -    (void)sizeof(func());                       \
>> +    (void)sizeof((func)());                     \
> 
> Like this, all that's touched here are (syntactical, but not real) 
> function
> invocations. Function calls, like all postfix operators, are highest
> precedence. Hence by omitting parentheses in that case no breakage can
> happen as a result: If the passed expression is another postfix one, 
> that'll
> be evaluated first anyway. If any other expression is passed (aside 
> primary
> ones, of course), that'll be evaluated afterwards only due to being 
> lower
> precedence, irrespective of the presence/absence of parentheses.
> 
> Therefore, where harmful to readability, can we perhaps leave postfix
> expressions alone?
> 
> Jan

While I can understand the benefits of this, and the reasoning on 
postfix expressions, what about, for instance (modulo the actual 
invocation, this is just an example)

alternative_vcall0(2 + f) or similar scenarios?

-- 
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)


From xen-devel-bounces@lists.xenproject.org Mon Mar 25 14:58:14 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 14:58:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697775.1088863 (Exim 4.92)
	(envelope-from )
	id 1rolm6-00083u-0w; Mon, 25 Mar 2024 14:58:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697775.1088863; Mon, 25 Mar 2024 14:58:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rolm5-00083n-UK; Mon, 25 Mar 2024 14:58:09 +0000
Received: by outflank-mailman (input) for mailman id 697775;
 Mon, 25 Mar 2024 14:58:09 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rolm5-00083h-8A
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 14:58:09 +0000
Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com
 [2a00:1450:4864:20::636])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 17123b2b-eab8-11ee-afe3-a90da7624cb6;
 Mon, 25 Mar 2024 15:58:07 +0100 (CET)
Received: by mail-ej1-x636.google.com with SMTP id
 a640c23a62f3a-a474c4faf5eso174975366b.2
 for ; Mon, 25 Mar 2024 07:58:07 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 x20-20020a170906b09400b00a469e55767dsm3125682ejy.214.2024.03.25.07.58.06
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 25 Mar 2024 07:58:07 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 17123b2b-eab8-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711378687; x=1711983487; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=huJjcNoZ7SphTouJw8YE47BK1mjEvt25On/jfB4rk8w=;
        b=NgqU16jQLRvOj7rliwLYfZPaHwYIhtiuFXDxEP7HCbHazpeeojZh2JA3rXALUQ/aoV
         dy8rqPVQHBpocSaMo740X0JsIqs+qqbWgZBxLkojg4SzrETn2bLA47HDbHsbCOzxOMzP
         kX3EgdU1zYpo+KjHC/SzS+oHrd+r/gyleTxvTzoRAufGjoZN2S/exqRfBYfa1fLND7Zt
         coMvJSJ6j6dIxYY3Ug0fQLV634nDImq6sQl3ptvhveOucdJqkQvNZjM7l/sLenrzsLlu
         YqVzgZ5YhLv9vip+XVd00eeBtDSz2lOBhCQ14MHxNH2clVnyLdVVV8npK70t5+FEUOo2
         5X2w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711378687; x=1711983487;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=huJjcNoZ7SphTouJw8YE47BK1mjEvt25On/jfB4rk8w=;
        b=XaT1aewnh1dCQ0W6Ce+3bEOZQ48DjQlQWMtMUzRRKtn7S8DdkMDgHkNis0EiXoHbPK
         QuB5X2LH8pF6mBtYN6HSj3vxZ4PkEql9RStGMX3ePkkJ5tpaogKXy9jAXnuEGW00+mW1
         hURlhXdSMIzSUUf1t4Y0XDJTzGryaSDaiLnjFvY6pyRTVCpaNyy3s1ohYg6qvMeljSs4
         wCEZvre1vVoV38B+ey5pqm982bZPd4CpGIxyJHjFlNxVC13JnQmB469l5ESycIDBwu4C
         khXKiyDrFDJGZOkpOt22X+OMxImqHXUtZz++M5kZaD5Fm0mHPjLjN4xfh5QRJoJ8rVq5
         X4Sw==
X-Forwarded-Encrypted: i=1; AJvYcCUuhBc9mDQCn7VYpXiBtKuTCOn0+1O8V6hSA1Cna8zBLUMAlmkiDdVOMAGaQsS3dmaSRte0zwZKgraPRwKxtuapV4SB9o1LLUFrD03bbdE=
X-Gm-Message-State: AOJu0Yx3z2DbPqhpdIBTK5OhygH2Cujv8kbaayhBJLmWWTFRNhApFxkQ
	Kr5YGQaO5DF8YNbvR4XbKes6BVLwZ+NdXr1WM7nSQy3c0XrGWYT9HNhnFsYZeg==
X-Google-Smtp-Source: AGHT+IHovogu8MivfcpidG1ZM+5E4UrE654S/pyvmLBeLyVeP15cruCT4aBgpGE6MEy+izDVLfhLgg==
X-Received: by 2002:a17:906:f9d8:b0:a47:499b:d735 with SMTP id lj24-20020a170906f9d800b00a47499bd735mr4048576ejb.14.1711378687295;
        Mon, 25 Mar 2024 07:58:07 -0700 (PDT)
Message-ID: 
Date: Mon, 25 Mar 2024 15:58:06 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 08/11] x86/altcall: address violations of MISRA C Rule
 20.7
Content-Language: en-US
To: Nicola Vetrini 
Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com,
 ayan.kumar.halder@amd.com, consulting@bugseng.com,
 andrew.cooper3@citrix.com, roger.pau@citrix.com, bertrand.marquis@arm.com,
 julien@xen.org, xen-devel@lists.xenproject.org
References: 
 <653ead65966226f50b0e4ae0268912c9710f9dba.1711118582.git.nicola.vetrini@bugseng.com>
 <072aa89b-2a03-4823-af72-28a2a882b373@suse.com>
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 25.03.2024 15:47, Nicola Vetrini wrote:
> On 2024-03-25 10:38, Jan Beulich wrote:
>> On 22.03.2024 17:01, Nicola Vetrini wrote:
>>> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
>>> of macro parameters shall be enclosed in parentheses". Therefore, some
>>> macro definitions should gain additional parentheses to ensure that 
>>> all
>>> current and future users will be safe with respect to expansions that
>>> can possibly alter the semantics of the passed-in macro parameter.
>>>
>>> No functional change.
>>>
>>> Signed-off-by: Nicola Vetrini 
>>
>> Hmm. These macros are, at least in part, hard to read already. The 
>> added
>> parentheses, while necessary when following the rule to the letter, are
>> making things worse, even if just slightly. I therefore have a proposal 
>> /
>> question:
>>
>>> --- a/xen/arch/x86/include/asm/alternative.h
>>> +++ b/xen/arch/x86/include/asm/alternative.h
>>> @@ -243,28 +243,28 @@ extern void alternative_branches(void);
>>>
>>>  #define alternative_vcall0(func) ({             \
>>>      ALT_CALL_NO_ARG1;                           \
>>> -    (void)sizeof(func());                       \
>>> +    (void)sizeof((func)());                     \
>>
>> Like this, all that's touched here are (syntactical, but not real) 
>> function
>> invocations. Function calls, like all postfix operators, are highest
>> precedence. Hence by omitting parentheses in that case no breakage can
>> happen as a result: If the passed expression is another postfix one, 
>> that'll
>> be evaluated first anyway. If any other expression is passed (aside 
>> primary
>> ones, of course), that'll be evaluated afterwards only due to being 
>> lower
>> precedence, irrespective of the presence/absence of parentheses.
>>
>> Therefore, where harmful to readability, can we perhaps leave postfix
>> expressions alone?
> 
> While I can understand the benefits of this, and the reasoning on 
> postfix expressions, what about, for instance (modulo the actual 
> invocation, this is just an example)
> 
> alternative_vcall0(2 + f) or similar scenarios?

Any kind of such expression will break with alternative_callN()'s
using of [addr] "i" (&(func)) as an asm() operand. Which clarifies
that even of the postfix expressions only some (in particular not
increment, decrement, and function call) could potentially be used
with the altcall machinery.

That said, you have a point in (indirectly) expressing that my
earlier description wasn't quite right (as in: too generic, when
it really needs tying to the specific case here).

Jan


From xen-devel-bounces@lists.xenproject.org Mon Mar 25 15:11:57 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 15:11:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697778.1088874 (Exim 4.92)
	(envelope-from )
	id 1rolzE-0002V7-5W; Mon, 25 Mar 2024 15:11:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697778.1088874; Mon, 25 Mar 2024 15:11:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rolzE-0002V0-2H; Mon, 25 Mar 2024 15:11:44 +0000
Received: by outflank-mailman (input) for mailman id 697778;
 Mon, 25 Mar 2024 15:11:43 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rolzD-0002Uu-Gr
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 15:11:43 +0000
Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com
 [2a00:1450:4864:20::329])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id fc07fdf8-eab9-11ee-a1ef-f123f15fe8a2;
 Mon, 25 Mar 2024 16:11:41 +0100 (CET)
Received: by mail-wm1-x329.google.com with SMTP id
 5b1f17b1804b1-4148c04396dso2944675e9.2
 for ; Mon, 25 Mar 2024 08:11:41 -0700 (PDT)
Received: from perard.uk.xensource.com (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 bf12-20020a0560001ccc00b0033e745b8bcfsm9742542wrb.88.2024.03.25.08.11.39
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 25 Mar 2024 08:11:40 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: fc07fdf8-eab9-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1711379501; x=1711984301; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=LR1gIfisqV2Ai3B2/p8+IhtMSDuKYubozQErFrhg05A=;
        b=HIEPXOCUZ9d/DQMiEBcSOYU4eTpnIVoybqi2tkXBUWogbipLJI8PehvTv0mvy3r48p
         1KM+REDvX9KgRx/4albTqqoU0Gcw7yRRWduVMAQXa96QQTORGD+VpbwNy3K7YrtCt1Cc
         DJJE2x8SFJ2cOYsEmOnw7K1Pt+x4yIFU7H4BU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711379501; x=1711984301;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=LR1gIfisqV2Ai3B2/p8+IhtMSDuKYubozQErFrhg05A=;
        b=eEN8uxIq4eMNM/bNBmISMwyRvQxlfYT8ViLBwrly+zovdXdUqpcmV0YFzVm0h1H79Q
         f4xkrQ5uq38jY/IB1N6X1zIW+a+LiB0zkGmz4/uSPWc1qojuWT+eCnPoiN/BBa9vVNOn
         CsOqLDVKbQtNfHXXHLEqHXOtM5dmUewPDAEp0yV/MPsDtCPo+B3ufJHcj8SQO4hMZ34l
         N/THPpLpHXH4Nl+Y2cDbQWAmsLrUwVof4oTWyFRAoxftrZZY8SWFcP/JjMYKlZHZodtN
         VIbkm0fpWd7RyRPfmHT/7h787opKCtfMiHe/CeVAAqzP9E3gHaJzIkQ5jRReMeC5jQvP
         pvwQ==
X-Gm-Message-State: AOJu0YzC0YG4b8ng1GXej6i28sTELZEPfQSKLATg1sP72/fqX1jtChSN
	3bMYN65ZfC30bewlS272epQ/bQ2kJoRApAUY8mOIsCOtGRsEDcGKREq1TPxipIE=
X-Google-Smtp-Source: AGHT+IHILC5kHaXsTbpE5RfJZWb7Yjx1c8xOuVTdAsvya6sIvr5JZSj5PNIiyirtFdSvM4ecQLBt3A==
X-Received: by 2002:a05:600c:198c:b0:414:48f:a7ab with SMTP id t12-20020a05600c198c00b00414048fa7abmr4945999wmq.30.1711379500813;
        Mon, 25 Mar 2024 08:11:40 -0700 (PDT)
Date: Mon, 25 Mar 2024 15:11:39 +0000
From: Anthony PERARD 
To: =?iso-8859-1?Q?Rafa=EBl?= Kooi 
Cc: xen-devel@lists.xenproject.org
Subject: Re: [XEN PATCH v2 1/1] tools: init scripts: Add missing
 XENCONSOLED_ARGS variable
Message-ID: <9b762ce5-ddd4-4213-af34-6364cd1fa74e@perard>
References: 
 
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Mon, Mar 25, 2024 at 12:09:40PM +0100, Rafal Kooi wrote:
> Makes sense. To be honest I don't even know what arguments one would pass
> to xenconsoled other than setting the log level to begin with. I would
> assume this to be a niche enough use case where very few users would be
> affected if we do decided to remove the variable. Maybe we could opt to
> advertise it as something that we will be removing in a later release?

I think it's fine to leave the variable where it is. On a systemd service
file, it's kind of nice to be able to add new arguments without
overwriting the whole command, as it means that we get the command line
on an update if it changed.

Cheers,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Mon Mar 25 15:19:43 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 15:19:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697783.1088884 (Exim 4.92)
	(envelope-from )
	id 1rom6r-0003M1-Tw; Mon, 25 Mar 2024 15:19:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697783.1088884; Mon, 25 Mar 2024 15:19:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rom6r-0003Lu-QG; Mon, 25 Mar 2024 15:19:37 +0000
Received: by outflank-mailman (input) for mailman id 697783;
 Mon, 25 Mar 2024 15:19:37 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rom6r-0003Lo-0M
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 15:19:37 +0000
Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com
 [2a00:1450:4864:20::12b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 16acb7f2-eabb-11ee-afe3-a90da7624cb6;
 Mon, 25 Mar 2024 16:19:35 +0100 (CET)
Received: by mail-lf1-x12b.google.com with SMTP id
 2adb3069b0e04-515a68d45faso1844008e87.3
 for ; Mon, 25 Mar 2024 08:19:35 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 m10-20020a170906234a00b00a46ee3c31afsm3112270eja.154.2024.03.25.08.19.34
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 25 Mar 2024 08:19:34 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 16acb7f2-eabb-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711379975; x=1711984775; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=YkD5xjq/lPrBeG2KyUl1he/l9o1Obf7BcHZmc61sR2A=;
        b=fafIrFCPR7tabjClRLyYZEDRvxn3oheKR4HiKWGYrgNtDFB4tYz7QJA2Fnru5kkaCV
         tvWZXVldyLyUxmDA4g6/azDeuyy9f8HKnFEa0Gr03hOKxm7K1fTtWEL8NSf6SW0oZ7Sh
         9RdciXxoqP+vQxwsUFg0CyMcnsrgCj+UA5FqJds9GVgTPi5Db5IcDppNLheTpOBmSb7X
         G1f8in9Yy5IQPE7xu2d+W/N/4SilKgPj1vH5bstztPbu6SJGacRe84t78FLQGb9sjo1P
         wvw2e3dTwr0L+FLB432bV4cONaNlXgrRLegOthhDH2Y04/hI0IlNOL/9wviTLiXpRHnB
         exng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711379975; x=1711984775;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=YkD5xjq/lPrBeG2KyUl1he/l9o1Obf7BcHZmc61sR2A=;
        b=Y/MVpcj46nZJ7GPthiVtfGd3EoP16I8iWDOyJmVLlzpQmvP3RqOHwcdrWn4EgUEgQX
         jq3NV2ib3+M8tDfjR6XocEJ7G8Lxm/VS9Xyc63CdX9tk1UoybB2z570egNdK1+fzoeUb
         kzl5gYM+Pbo4Kvf/Ev2p0pk1LlE1vYEktL0LX/0F12t8fo50ec97ej4Zq5/UV+5Qh5CV
         RAWjYMxIEDXtVsZD7hqM73gigSamfh+z6NLlCHIFrzIuvkwttosHHDmM8apoxrBefi+r
         YEx3sr+A3aZphR15wYyTrie4cy08R3ygpT/nlJronC0dpfcWVFR0Sq+BqBzXEPJC0oRc
         gWHg==
X-Forwarded-Encrypted: i=1; AJvYcCUlcikMF364GoaSa0ofXQOjwhmdkNae9QECdZZ/xr0JL/Af6zRbMTbhvim7CaEbvJXx5yfciN76kyuwM5Nbzz94zu14gz2sPdB1uAsNvKA=
X-Gm-Message-State: AOJu0Yyxjnvt6IWwODvHBEMQgcaBggwiBpCbvO/vwzUbyjSyo6WLWu0y
	ukIpcCT/L0Q0xwTx9p1CgY44qmOTowVctHoEbUf2RyX+k9WrGHIID1Q+mJ/C8Q==
X-Google-Smtp-Source: AGHT+IF6+t7EsKL4ves9dwN5Bf851GclUKe5HUVTqNZRakjJFPwWVQIJhUW+z0Xq+LRlX1gDHJbcFA==
X-Received: by 2002:a05:6512:4845:b0:514:b4ca:f478 with SMTP id ep5-20020a056512484500b00514b4caf478mr4575458lfb.39.1711379975128;
        Mon, 25 Mar 2024 08:19:35 -0700 (PDT)
Message-ID: 
Date: Mon, 25 Mar 2024 16:19:33 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 2/9] xen/asm-generic: Introduce generic acpi.h
Content-Language: en-US
To: Shawn Anastasio 
Cc: tpearson@raptorengineering.com, Andrew Cooper
 , George Dunlap ,
 Julien Grall , Stefano Stabellini ,
 Wei Liu , xen-devel@lists.xenproject.org
References: 
 <794e46b16475c0b4f482cdc8560ebb2f37875715.1710443965.git.sanastasio@raptorengineering.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <794e46b16475c0b4f482cdc8560ebb2f37875715.1710443965.git.sanastasio@raptorengineering.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 14.03.2024 23:15, Shawn Anastasio wrote:
> Introduce a generic acpi.h header that provides the required definitions
> to allow files including xen/acpi.h to be compiled. The definitions were
> largely derived from the !CONFIG_ACPI parts of ARM's acpi.h.

As said a couple of times in discussion with Oleksii on his work towards
populating asm-generic/, I view a use like this as an abuse of this
asm-generic machinery. Instead imo said !CONFIG_ACPI parts from Arm's header
want moving to xen/acpi.h, eliminating the need for asm/acpi.h for
architectures / configurations not supporting ACPI. Much like was done
with e.g. xen/numa.h.

Jan

> --- a/xen/arch/ppc/include/asm/Makefile
> +++ b/xen/arch/ppc/include/asm/Makefile
> @@ -1,4 +1,5 @@
>  # SPDX-License-Identifier: GPL-2.0-only
> +generic-y += acpi.h
>  generic-y += altp2m.h
>  generic-y += device.h
>  generic-y += div64.h
> --- /dev/null
> +++ b/xen/include/asm-generic/acpi.h
> @@ -0,0 +1,20 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef __ASM_GENERIC_ACPI_H
> +#define __ASM_GENERIC_ACPI_H
> +
> +#include 
> +#include 
> +
> +#ifdef CONFIG_ACPI
> +#error "asm-generic acpi.h can't be used with CONFIG_ACPI set"
> +#endif
> +
> +#define COMPILER_DEPENDENT_INT64   int64_t
> +#define COMPILER_DEPENDENT_UINT64  uint64_t
> +#define ACPI_MAP_MEM_ATTR          PAGE_HYPERVISOR
> +
> +#define acpi_disabled (true)
> +#define disable_acpi()
> +#define enable_acpi()
> +
> +#endif /* __ASM_GENERIC_ACPI_H */



From xen-devel-bounces@lists.xenproject.org Mon Mar 25 15:24:36 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 15:24:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697786.1088895 (Exim 4.92)
	(envelope-from )
	id 1romBd-0004rE-GR; Mon, 25 Mar 2024 15:24:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697786.1088895; Mon, 25 Mar 2024 15:24:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1romBd-0004r7-C4; Mon, 25 Mar 2024 15:24:33 +0000
Received: by outflank-mailman (input) for mailman id 697786;
 Mon, 25 Mar 2024 15:24:32 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1romBc-0004r1-Dx
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 15:24:32 +0000
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com
 [2a00:1450:4864:20::52a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c570c38b-eabb-11ee-a1ef-f123f15fe8a2;
 Mon, 25 Mar 2024 16:24:30 +0100 (CET)
Received: by mail-ed1-x52a.google.com with SMTP id
 4fb4d7f45d1cf-56bf6591865so3135865a12.0
 for ; Mon, 25 Mar 2024 08:24:28 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 8-20020a170906308800b00a4652efd795sm3137795ejv.83.2024.03.25.08.24.27
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 25 Mar 2024 08:24:27 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c570c38b-eabb-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711380268; x=1711985068; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=EYo/I9l9EypwVCPAeKyFM3D59t3JwJaIWWILJVcw/Ag=;
        b=PLFfxm9xY2oTF8eObk1bPsa3mui+PxB7BmWPtWExAwWvyQ+tIbwNV9PtwNQAH/RBU7
         dCavlyL9hNlQ5gUqSO3B8wryXMRAiIvRgCojfzwNLGScdFL/nJKXals3s1MxI0g8lL3/
         7a9xrvLGVfZsUZ9K4hS88FOetckmGUf2doqiarbCiORojfWv1f3EZQMNY1t7EE/hwE3m
         7YrMGi/HZgz2BOctL5XnyfWqHBewuJctFbwiO713OoKsgpiuibr58kMVz2Nre6XkA/X+
         6/g6Zg0ws5W2Mwz29VT7OAPnaKYoyatqc9vcgFXf1pKjOrsFoMOV8xHjmIGx6QgyxNrc
         TaWw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711380268; x=1711985068;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=EYo/I9l9EypwVCPAeKyFM3D59t3JwJaIWWILJVcw/Ag=;
        b=ogxWYf/NamyhmL5hSkAIUdpwQb0ld5B/ar9q5tv0CrbUoO56Fmvh0kjFm/cvjZANhi
         i35J8ug+u516kMQA594nantDMqnz1rkfwUdau9cYmJv7NE08x1acwL2X1xZyq4bfdTrv
         qUzzSqHeL87R+0D2ZnyGetpo+xF8CwFt+OZqrP08dXniw3wusC5YY3pwG6JKQUQAPSug
         NzytlMdDd+bs9xzn4Ehg1E57ML6YbSGJqnbUibp/3VJZdX4qtIe2AVArr/9VILWD/Xq6
         sNCe7cb94Ik3yH6PELwwVtNUyuQFxkacWJ2XTgn1eHEbgmi75T8jUT5q/lZzVcy5P2fl
         /FOw==
X-Forwarded-Encrypted: i=1; AJvYcCXUzlpaMi/zsKqsRTRmlNmXB+R9OqhgSdvuUNsH9Bi5rezzIuYZfNMg//Cr5THzoqvsfRpYZltTYDDFLr693zkeJLYxu3gR2x2wVAuQcH4=
X-Gm-Message-State: AOJu0YxrD9y39MjrWCrhqGWOSUcP3WOzl1cXfJWaRybWkavlzhPk2r20
	ohpXMZ6o7awMdvQYmtZUylIoL548x+OBsKiu71m2z+p+QdQSm8Auaoo082jD1g==
X-Google-Smtp-Source: AGHT+IEIGMHGuZB3lRbQfRXhxDRwJpthoqR1jHb9vfXCm6QOxrzyE0iDWDKieaP2LPTnyri+GDGUPA==
X-Received: by 2002:a17:906:fa14:b0:a46:c8e3:c9b9 with SMTP id lo20-20020a170906fa1400b00a46c8e3c9b9mr4521728ejb.42.1711380268212;
        Mon, 25 Mar 2024 08:24:28 -0700 (PDT)
Message-ID: 
Date: Mon, 25 Mar 2024 16:24:26 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 3/9] xen/ppc: Introduce stub asm/static-shmem.h
Content-Language: en-US
To: Shawn Anastasio 
Cc: tpearson@raptorengineering.com, xen-devel@lists.xenproject.org
References: 
 <0cf8286269a1c5cdc63e2c19d832a4923cd14f39.1710443965.git.sanastasio@raptorengineering.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <0cf8286269a1c5cdc63e2c19d832a4923cd14f39.1710443965.git.sanastasio@raptorengineering.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 14.03.2024 23:15, Shawn Anastasio wrote:
> Required for bootfdt.c to build.
> 
> Signed-off-by: Shawn Anastasio 

As a temporary workaround this may be okay, but was the alternative
considered to properly provide stubs in a single central place for
anything !CONFIG_STATIC_SHM?

Jan

> --- /dev/null
> +++ b/xen/arch/ppc/include/asm/static-shmem.h
> @@ -0,0 +1,12 @@
> +/* SPDX-License-Identifier:  GPL-2.0-only */
> +
> +#ifndef __ASM_PPC_STATIC_SHMEM_H__
> +#define __ASM_PPC_STATIC_SHMEM_H__
> +
> +static inline int process_shm_node(const void *fdt, int node,
> +                                   uint32_t address_cells, uint32_t size_cells)
> +{
> +    return -EINVAL;
> +}
> +
> +#endif /* __ASM_PPC_STATIC_SHMEM_H__ */



From xen-devel-bounces@lists.xenproject.org Mon Mar 25 15:30:00 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 15:30:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697789.1088904 (Exim 4.92)
	(envelope-from )
	id 1romGp-0005pY-1y; Mon, 25 Mar 2024 15:29:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697789.1088904; Mon, 25 Mar 2024 15:29:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1romGo-0005pR-VY; Mon, 25 Mar 2024 15:29:54 +0000
Received: by outflank-mailman (input) for mailman id 697789;
 Mon, 25 Mar 2024 15:29:53 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1romGn-0005pL-L0
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 15:29:53 +0000
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com
 [2a00:1450:4864:20::630])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 866ec6bb-eabc-11ee-afe3-a90da7624cb6;
 Mon, 25 Mar 2024 16:29:52 +0100 (CET)
Received: by mail-ej1-x630.google.com with SMTP id
 a640c23a62f3a-a467d8efe78so533079866b.3
 for ; Mon, 25 Mar 2024 08:29:52 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 s10-20020a170906354a00b00a47a33b3aa2sm1634987eja.157.2024.03.25.08.29.51
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 25 Mar 2024 08:29:51 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 866ec6bb-eabc-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711380592; x=1711985392; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=hseUhSsmJKVNraENiB+Z6BqcV/Ua5vxGM6CtyHtBBS4=;
        b=HxV0y+adbH/CWMFm8zIA7SPt8TcCF/2mDhzaBH/9YReruLxLkE8HgJ82fak+FNBbZ9
         2Z7aMDhaQEsPTrXwKoGRj2fNtGtLoGrWDSUzR4Kf7P/rw956HeEnjya5node1sa6Vzhz
         iCOmRNSWKMEZBAW+1sojr8LvINbzm8cA9w78t1RgPtW4DgTwcVswnYtyllaxoqX7TeYB
         NVkUu5J3cvvz1c7Na5Oj02lgeMBlEbRGNV2ifZ08svnshMTaVqW4yrOTLIjV245fgR/j
         TnHZWA1HVtnbNwPuOqi8kJ82AJlW81OoQaI2F4wYp4ni4wotlmokoBHRnDtOd5jkFU44
         6SSA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711380592; x=1711985392;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=hseUhSsmJKVNraENiB+Z6BqcV/Ua5vxGM6CtyHtBBS4=;
        b=rG4YIfshhpVuEBw3afcHJhOKkRUYpQZKtZKbRu6cfv1i4NRofYYu7hi2IMDCpfY5mN
         mno/RnYitoZEvJNBe+fd/paxBfyyyCl4KIMLHD1AI/mz3ZSIHagcZT8Hg1T4eF/2wp7V
         k2+eDboYBOBkYTDYF+eaX0Dz6HndBwS3QhI0VVQgCwCgiyzugxKPi1BFlY/BU9Pf357V
         9tynSdHB6dFGvZuMNj9TStO6x7tXatquqyqP98stPXLr5m8Dmz9dPsT74W4qfaJRbESq
         NxuFnmEXmmlJKQKDaTQ2a1sp64UXtUxS4IMT9wPI3jPfkv4opnvTp5IkEd2/OPl4gsYd
         GKxw==
X-Forwarded-Encrypted: i=1; AJvYcCUxUFo+gWlftub0j0txjQPr7qf3cNXg4NSVDYirqK4kA9Wi5YBo7Uw/ckcKKRhLuCA8wMQSpNh/Eoeuwks41jHyQ8Db1Y4+9TbrBgl9G9w=
X-Gm-Message-State: AOJu0Yzd80aSgTK8kOXPrn/OncJReVi2JMqE6Mrh5Nj4x0AgnD22B7CY
	4BF41KrZVVLC65oJC0DreINZYfuTrfaKE+kvwytA3P2Ukfxkbru+L/uyIcUmdQ==
X-Google-Smtp-Source: AGHT+IE+CC1m0t0JPKIcrcUtfVL1KYYF1qeX3Bx6PJ9O1BMMFf800uv4FwzOPwZtjdFE5ruEOWAOdA==
X-Received: by 2002:a17:906:c190:b0:a46:22a3:479f with SMTP id g16-20020a170906c19000b00a4622a3479fmr5794928ejz.21.1711380592182;
        Mon, 25 Mar 2024 08:29:52 -0700 (PDT)
Message-ID: <9d62ae85-87e2-4645-a43d-1a978c8083fc@suse.com>
Date: Mon, 25 Mar 2024 16:29:51 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 8/9] xen/ppc: mm-radix: Replace debug printing code
 with printk
Content-Language: en-US
To: Shawn Anastasio 
Cc: tpearson@raptorengineering.com, xen-devel@lists.xenproject.org
References: 
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 14.03.2024 23:15, Shawn Anastasio wrote:
> Now that we have common code building, there's no need to keep the old
> itoa64+debug print function in mm-radix.c
> 
> Signed-off-by: Shawn Anastasio 

Reviewed-by: Jan Beulich 

Just to clarify: Is this dependent upon any of the earlier patches in this
series? If not, it could be committed right away.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Mar 25 15:35:59 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 15:35:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697793.1088914 (Exim 4.92)
	(envelope-from )
	id 1romMa-0007Ko-Qi; Mon, 25 Mar 2024 15:35:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697793.1088914; Mon, 25 Mar 2024 15:35:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1romMa-0007Kh-N9; Mon, 25 Mar 2024 15:35:52 +0000
Received: by outflank-mailman (input) for mailman id 697793;
 Mon, 25 Mar 2024 15:35:51 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1romMZ-0007Kb-BE
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 15:35:51 +0000
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com
 [2a00:1450:4864:20::331])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5b203f1c-eabd-11ee-a1ef-f123f15fe8a2;
 Mon, 25 Mar 2024 16:35:49 +0100 (CET)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-4148c681e3bso1455305e9.0
 for ; Mon, 25 Mar 2024 08:35:49 -0700 (PDT)
Received: from perard.uk.xensource.com (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 ay19-20020a05600c1e1300b004148a667953sm2622330wmb.8.2024.03.25.08.35.47
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 25 Mar 2024 08:35:48 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5b203f1c-eabd-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1711380949; x=1711985749; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=buP1+Ge855Sd7bv2LVUKWUJRTB9ZGBqIG29F5rApJYg=;
        b=Aezh/A0NQAcVmTy5QheTcUWca4XurMpSbxhW+zTtJTaMMTlxOcDm1vH88oOQoGLTkH
         Jx1rf6AJDP47nlL5zO4Lt/vfBE6j2PmEStlrFGhIHNGWDNG18/aA0e8hdzsR5z8euzCR
         VdeAl9wesf9vmHAVaIjWd0yjsY74SJFO/eL6w=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711380949; x=1711985749;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=buP1+Ge855Sd7bv2LVUKWUJRTB9ZGBqIG29F5rApJYg=;
        b=VchMGEI76CHDou+ruo8aQR1QKb9ntnpuwNHlbZfibhCRAid27Cxsir4lpDN6SPZPG5
         I0K5qFKF3jqnKynWysWn0PjhMu5rFwxpvqiQgf37RbQ+AlJlOXigbCxbOW0+x1G0fVM3
         HH/1zucYqIyml+2qUKzhjbebbPuQlUfYlcvnpQ4UA/6IklFwEiPZ5y8/gcTt6OGa5ZBB
         lMBznvJuqNOV7QWMHvbWomehHOYRPgQNicRCQqKGRmLuHKvFkjOiy2RyOZ2Wz+285rTH
         hHXxFivQh6mmyRFQp1jEVrtCYUPKhG91uyiKxofoDuEaw5QI2s+dHgf558EIXqgw7wCY
         2/uw==
X-Gm-Message-State: AOJu0Yzy6VnZbIV2qgn+VVvOL0eIJCipTipPFIXlLQuSCHhphbOuIu+w
	HelR2FtScxm/mj0gcVPm24geAtdTY/11UIVkZpGD1Awf+/tkKlOr4KQ8YHHjFhM=
X-Google-Smtp-Source: AGHT+IGu+STknhlfeLWRgahb2ONynsTNg8rJdUW8VCcmC/kngvR4rDZ002y2a0lYYZ49325E0NniMA==
X-Received: by 2002:a05:600c:1d28:b0:414:6a1d:2013 with SMTP id l40-20020a05600c1d2800b004146a1d2013mr6022575wms.16.1711380948854;
        Mon, 25 Mar 2024 08:35:48 -0700 (PDT)
Date: Mon, 25 Mar 2024 15:35:47 +0000
From: Anthony PERARD 
To: Henry Wang 
Cc: xen-devel@lists.xenproject.org, Wei Liu ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini ,
	Alec Kwapis 
Subject: Re: [PATCH v2 5/5] xen/memory, tools: Make init-dom0less consume
 XEN_DOMCTL_get_mem_map
Message-ID: <9162a331-645c-4e45-b5d0-57c6b9b4f79b@perard>
References: <20240308015435.4044339-1-xin.wang2@amd.com>
 <20240308015435.4044339-6-xin.wang2@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240308015435.4044339-6-xin.wang2@amd.com>

On Fri, Mar 08, 2024 at 09:54:35AM +0800, Henry Wang wrote:
> diff --git a/tools/helpers/init-dom0less.c b/tools/helpers/init-dom0less.c
> index fee93459c4..92c612f6da 100644
> --- a/tools/helpers/init-dom0less.c
> +++ b/tools/helpers/init-dom0less.c
> @@ -23,16 +23,30 @@ static int alloc_xs_page(struct xc_interface_core *xch,
>                           libxl_dominfo *info,
>                           uint64_t *xenstore_pfn)
>  {
> -    int rc;
> -    const xen_pfn_t base = GUEST_MAGIC_BASE >> XC_PAGE_SHIFT;
> -    xen_pfn_t p2m = (GUEST_MAGIC_BASE >> XC_PAGE_SHIFT) + XENSTORE_PFN_OFFSET;
> +    int rc, i;
> +    xen_pfn_t base = ((xen_pfn_t)-1);
> +    xen_pfn_t p2m = ((xen_pfn_t)-1);
> +    uint32_t nr_regions = XEN_MAX_MEM_REGIONS;
> +    struct xen_mem_region mem_regions[XEN_MAX_MEM_REGIONS] = {0};
> +
> +    rc = xc_get_domain_mem_map(xch, info->domid, mem_regions, &nr_regions);

Shouldn't you check the value of in `rc`?

> +    for ( i = 0; i < nr_regions; i++ )
> +    {
> +        if ( mem_regions[i].type == GUEST_MEM_REGION_MAGIC )
> +        {
> +            base = mem_regions[i].start >> XC_PAGE_SHIFT;
> +            p2m = (mem_regions[i].start >> XC_PAGE_SHIFT) + XENSTORE_PFN_OFFSET;
> +        }
> +    }

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Mon Mar 25 15:39:15 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 15:39:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697794.1088924 (Exim 4.92)
	(envelope-from )
	id 1romPq-00084x-9O; Mon, 25 Mar 2024 15:39:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697794.1088924; Mon, 25 Mar 2024 15:39:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1romPq-00084q-5H; Mon, 25 Mar 2024 15:39:14 +0000
Received: by outflank-mailman (input) for mailman id 697794;
 Mon, 25 Mar 2024 15:39:13 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1romPp-00084k-3j
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 15:39:13 +0000
Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com
 [2a00:1450:4864:20::12f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d32b72ef-eabd-11ee-afe3-a90da7624cb6;
 Mon, 25 Mar 2024 16:39:11 +0100 (CET)
Received: by mail-lf1-x12f.google.com with SMTP id
 2adb3069b0e04-515a86daf09so2017311e87.3
 for ; Mon, 25 Mar 2024 08:39:11 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 k11-20020a1709067acb00b00a4a36e4c3fbsm1089189ejo.182.2024.03.25.08.39.09
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 25 Mar 2024 08:39:09 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d32b72ef-eabd-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711381150; x=1711985950; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=wfnK3jW8pfZ76J+659Erv1jkv6D8oNEGgAQsZk2zsxs=;
        b=ZNLAbRl4WP8wxDTLuWBZG4b2ch54hlBUaUUZR+WU3DTqPxk56rzvjYV96gTNLpcs/3
         VpXux+d9YU8ZQEw9f8ZBlagLEMu88Cz2uwK0n5Rve7gMGaxVxGuv1/VxQmcpiPzvELUk
         0bRLTUcyCGJoki1FAbMs1VElxkPfYDY+GqvdL50qN36Wc45mAyOUWwoxRr3IrXkIxPG8
         Io0rzP6NKKVv5erDDZyl2RD2Plo8P5pS8KdF1BT04SvqCR4a++q4OZ9SH4/Eiv6N5YCJ
         yDl3HuhGiPTl6TAorgTJIFmmH0DfdxIqNlkq+++vj0/A8XDdg0WrqGFO7hUVRIn8FVCx
         emMg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711381150; x=1711985950;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=wfnK3jW8pfZ76J+659Erv1jkv6D8oNEGgAQsZk2zsxs=;
        b=oDPQENDRQZp2oFCon6QsEOuYRL3fh0Bw8Lbw2hTOJ5gcMjDis5CSbPt83PzRunDXAr
         Ha2zbd0Y5D676JcZlUzYSKLOzuu13uh5fh1QZ2Eg4GxgetEODNjIluMu2X3q4Uxpdb78
         LizTF3nvbwAkuAWnPlVJJRa1L/e+JCs4aSqPVSWVoafjB3XCEpwQcgkurpj5qksBv1HN
         2H7A5G615VuH5nPqBwdf6UTXbfbjpSjRqW8MVAdVEGnSimKKzXEBgaoeoMZLckHjvHnT
         AsfQR1qKGmX5p34C+cs2yNUQfbhk1m8M4qsrNOWEal/WNH5Je1cAB3XN2xvtklAYC5s3
         N0hw==
X-Forwarded-Encrypted: i=1; AJvYcCVbO9Y3dmg1fP1XpkfNjmnWynxwPqCPs2EBFpV/hs9dzFuqPZcnnskJs07pzUKf3Cm2Hbb82QLBLiIDAxFjMcMyTSaWgJEuvEm8wT3KXWw=
X-Gm-Message-State: AOJu0YzMS4ZSFmWcHFIUV187I5xTLVXOYRZs/Q/NESmgoJO5Kwe4dyCL
	jvUn52D8yzs1npEZi7vC2gEZYH5LohNh9MImeflPEAuPJKFHYKs1tqwdi6WqTQ==
X-Google-Smtp-Source: AGHT+IFo01yy2+F2mDoW8OCiTTkAD/qXP/cwIsd5WWOmsIPCFqd/MkEkMo6CJD9K5dFJEP09OjBZZQ==
X-Received: by 2002:ac2:4db6:0:b0:514:88df:88b9 with SMTP id h22-20020ac24db6000000b0051488df88b9mr4686201lfe.45.1711381150234;
        Mon, 25 Mar 2024 08:39:10 -0700 (PDT)
Message-ID: 
Date: Mon, 25 Mar 2024 16:39:09 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 9/9] xen/ppc: mm-radix: Allocate all paging structures
 at runtime
Content-Language: en-US
To: Shawn Anastasio 
Cc: tpearson@raptorengineering.com, xen-devel@lists.xenproject.org
References: 
 <00f22a6a08451614179219fd430539fbb1e6e8cf.1710443965.git.sanastasio@raptorengineering.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <00f22a6a08451614179219fd430539fbb1e6e8cf.1710443965.git.sanastasio@raptorengineering.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 14.03.2024 23:15, Shawn Anastasio wrote:
> --- a/xen/arch/ppc/mm-radix.c
> +++ b/xen/arch/ppc/mm-radix.c
> @@ -21,69 +21,101 @@ void enable_mmu(void);
>  #define radix_dprintk(...)
>  #endif
> 
> -#define INITIAL_LVL1_PD_COUNT      1
> -#define INITIAL_LVL2_LVL3_PD_COUNT 2
> -#define INITIAL_LVL4_PT_COUNT      256
> -
> -static size_t __initdata initial_lvl1_pd_pool_used;
> -static struct lvl1_pd initial_lvl1_pd_pool[INITIAL_LVL1_PD_COUNT];
> -
> -static size_t __initdata initial_lvl2_lvl3_pd_pool_used;
> -static struct lvl2_pd initial_lvl2_lvl3_pd_pool[INITIAL_LVL2_LVL3_PD_COUNT];
> -
> -static size_t __initdata initial_lvl4_pt_pool_used;
> -static struct lvl4_pt initial_lvl4_pt_pool[INITIAL_LVL4_PT_COUNT];
> -
> -/* Only reserve minimum Partition and Process tables  */
>  #define PATB_SIZE_LOG2 16 /* Only supported partition table size on POWER9 */
>  #define PATB_SIZE      (1UL << PATB_SIZE_LOG2)
> -#define PRTB_SIZE_LOG2 12
> +#define PRTB_SIZE_LOG2 24 /* Maximum process table size on POWER9 */
>  #define PRTB_SIZE      (1UL << PRTB_SIZE_LOG2)
> 
> -static struct patb_entry
> -    __aligned(PATB_SIZE) initial_patb[PATB_SIZE / sizeof(struct patb_entry)];
> +static struct patb_entry *initial_patb;
> +static struct prtb_entry *initial_prtb;
> 
> -static struct prtb_entry
> -    __aligned(PRTB_SIZE) initial_prtb[PRTB_SIZE / sizeof(struct prtb_entry)];
> +static mfn_t __initdata min_alloc_mfn = {-1};
> +static mfn_t __initdata max_alloc_mfn = {0};
> 
> -static __init struct lvl1_pd *lvl1_pd_pool_alloc(void)
> +/*
> + * A thin wrapper for alloc_boot_pages that keeps track of the maximum and
> + * minimum mfns that have been allocated. This information is used by
> + * setup_initial_mapping to include the allocated pages in the initial
> + * page mapping.
> + */
> +static mfn_t __init initial_page_alloc(unsigned long nr_pfns,
> +                                       unsigned long pfn_align)
>  {
> -    if ( initial_lvl1_pd_pool_used >= INITIAL_LVL1_PD_COUNT )
> -    {
> -        early_printk("Ran out of space for LVL1 PD!\n");
> -        die();
> -    }
> +    mfn_t mfn_first, mfn_last;
> 
> -    return &initial_lvl1_pd_pool[initial_lvl1_pd_pool_used++];
> -}
> +    mfn_first = alloc_boot_pages(nr_pfns, pfn_align);
> +    mfn_last = _mfn(mfn_x(mfn_first) + nr_pfns - 1);

Please can you use mfn_add() here?

> -static __init struct lvl2_pd *lvl2_pd_pool_alloc(void)
> -{
> -    if ( initial_lvl2_lvl3_pd_pool_used >= INITIAL_LVL2_LVL3_PD_COUNT )
> -    {
> -        early_printk("Ran out of space for LVL2/3 PD!\n");
> -        die();
> -    }
> +    min_alloc_mfn = _mfn(min(mfn_x(min_alloc_mfn), mfn_x(mfn_first)));
> +    max_alloc_mfn = _mfn(max(mfn_x(max_alloc_mfn), mfn_x(mfn_last)));

Together with the comment ahead of the function - is there some kind of
assumption here that this range won't span almost all of system memory?
E.g. expecting allocations to be almost contiguous? If so, I wonder how
reliable this is, and whether using a rangeset wouldn't be better here.

> @@ -105,81 +138,47 @@ static void __init setup_initial_mapping(struct lvl1_pd *lvl1,
>          die();
>      }
> 
> +    /* Identity map Xen itself */
>      for ( page_addr = map_start; page_addr < map_end; page_addr += PAGE_SIZE )
>      {
> -        struct lvl2_pd *lvl2;
> -        struct lvl3_pd *lvl3;
> -        struct lvl4_pt *lvl4;
> -        pde_t *pde;
> -        pte_t *pte;
> -
> -        /* Allocate LVL 2 PD if necessary */
> -        pde = pt_entry(lvl1, page_addr);
> -        if ( !pde_is_valid(*pde) )
> -        {
> -            lvl2 = lvl2_pd_pool_alloc();
> -            *pde = paddr_to_pde(__pa(lvl2), PDE_VALID,
> -                                XEN_PT_ENTRIES_LOG2_LVL_2);
> -        }
> -        else
> -            lvl2 = __va(pde_to_paddr(*pde));
> +        unsigned long flags;
> 
> -        /* Allocate LVL 3 PD if necessary */
> -        pde = pt_entry(lvl2, page_addr);
> -        if ( !pde_is_valid(*pde) )
> +        if ( is_kernel_text(page_addr) || is_kernel_inittext(page_addr) )
>          {
> -            lvl3 = lvl3_pd_pool_alloc();
> -            *pde = paddr_to_pde(__pa(lvl3), PDE_VALID,
> -                                XEN_PT_ENTRIES_LOG2_LVL_3);
> +            radix_dprintk("%016lx being marked as TEXT (RX)\n", page_addr);
> +            flags = PTE_XEN_RX;
>          }
> -        else
> -            lvl3 = __va(pde_to_paddr(*pde));
> -
> -        /* Allocate LVL 4 PT if necessary */
> -        pde = pt_entry(lvl3, page_addr);
> -        if ( !pde_is_valid(*pde) )
> +        else if ( is_kernel_rodata(page_addr) )
>          {
> -            lvl4 = lvl4_pt_pool_alloc();
> -            *pde = paddr_to_pde(__pa(lvl4), PDE_VALID,
> -                                XEN_PT_ENTRIES_LOG2_LVL_4);
> +            radix_dprintk("%016lx being marked as RODATA (RO)\n", page_addr);
> +            flags = PTE_XEN_RO;
>          }
>          else
> -            lvl4 = __va(pde_to_paddr(*pde));
> -
> -        /* Finally, create PTE in LVL 4 PT */
> -        pte = pt_entry(lvl4, page_addr);
> -        if ( !pte_is_valid(*pte) )
>          {
> -            unsigned long paddr = (page_addr - map_start) + phys_base;
> -            unsigned long flags;
> -
> -            radix_dprintk("%016lx being mapped to %016lx\n", paddr, page_addr);
> -            if ( is_kernel_text(page_addr) || is_kernel_inittext(page_addr) )
> -            {
> -                radix_dprintk("%016lx being marked as TEXT (RX)\n", page_addr);
> -                flags = PTE_XEN_RX;
> -            }
> -            else if ( is_kernel_rodata(page_addr) )
> -            {
> -                radix_dprintk("%016lx being marked as RODATA (RO)\n", page_addr);
> -                flags = PTE_XEN_RO;
> -            }
> -            else
> -            {
> -                radix_dprintk("%016lx being marked as DEFAULT (RW)\n", page_addr);
> -                flags = PTE_XEN_RW;
> -            }
> -
> -            *pte = paddr_to_pte(paddr, flags);
> -            radix_dprintk("%016lx is the result of PTE map\n",
> -                paddr_to_pte(paddr, flags).pte);
> -        }
> -        else
> -        {
> -            early_printk("BUG: Tried to create PTE for already-mapped page!");
> -            die();
> +            radix_dprintk("%016lx being marked as DEFAULT (RW)\n", page_addr);
> +            flags = PTE_XEN_RW;
>          }
> +
> +        map_page_initial(lvl1, page_addr, (page_addr - map_start) + phys_base, flags);
> +    }
> +
> +    previous_max_alloc_mfn = max_alloc_mfn;
> +
> +    /*
> +     * Identity map all pages we've allocated for paging structures. This act
> +     * itself will allocate more pages, so continue until we've mapped from
> +     * `max_alloc_mfn` down to `min_alloc_mfn`. This assumes that the heap grows
> +     * downwards, which matches the behavior of alloc_boot_pages.
> +     */
> +    for ( page_addr = (vaddr_t)__va(mfn_to_maddr(max_alloc_mfn));
> +          mfn_to_maddr(min_alloc_mfn) <= __pa(page_addr);
> +          page_addr -= PAGE_SIZE)
> +    {
> +        map_page_initial(lvl1, page_addr, __pa(page_addr), PTE_XEN_RW);
>      }
> +
> +    if ( mfn_x(previous_max_alloc_mfn) != mfn_x(max_alloc_mfn) )
> +        panic("Early page heap unexpectedly grew upwards\n");
>  }

Oh, yet another assumption on allocator behavior.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Mar 25 15:45:00 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 15:45:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697800.1088934 (Exim 4.92)
	(envelope-from )
	id 1romVL-0001Vb-RI; Mon, 25 Mar 2024 15:44:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697800.1088934; Mon, 25 Mar 2024 15:44:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1romVL-0001VU-Of; Mon, 25 Mar 2024 15:44:55 +0000
Received: by outflank-mailman (input) for mailman id 697800;
 Mon, 25 Mar 2024 15:44:54 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1romVK-0001VO-11
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 15:44:54 +0000
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com
 [2a00:1450:4864:20::52b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9e93f526-eabe-11ee-a1ef-f123f15fe8a2;
 Mon, 25 Mar 2024 16:44:52 +0100 (CET)
Received: by mail-ed1-x52b.google.com with SMTP id
 4fb4d7f45d1cf-56bb22ff7baso5279404a12.3
 for ; Mon, 25 Mar 2024 08:44:52 -0700 (PDT)
Received: from [10.80.5.21] (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 t25-20020a056402241900b0056bd13ce50esm3066658eda.44.2024.03.25.08.44.50
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 25 Mar 2024 08:44:50 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9e93f526-eabe-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1711381491; x=1711986291; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=pif++eEEYvvEp58HeT4WvtkGCSD1np+rt0TaXbTQYqw=;
        b=HHkaIvOqnCVz7ZLtGqi+VPd1OuPO8eaTx2z7pxBDgHoGSTPcfVDXNeHKkg3e86rKgH
         mDoDRl2yQh3qeI4FuLB1vf8EG27fzOxoHxnkcNbkGPmGSCkShLBq07a+QLvI564XA5Fo
         b27OkLla/gykzAom3Bkui+4xXjnOi9HO8VsZ8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711381491; x=1711986291;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=pif++eEEYvvEp58HeT4WvtkGCSD1np+rt0TaXbTQYqw=;
        b=LdgboVwpzU2c7pWMY7cZdx6M1EXsKoD7ecF99FK2gHXj0JLUgWM0sdkzgG1WkeLt10
         8nBG0SN3eUUdDEcmt0iskDRBdznw26F+dpGyY5reMpoXglzvi/aOzYy26PgcBDeJsp2S
         q+OZI5S8slGyLhFrEAcsHpdED3nOBVYdTVlUth8lcG6WxkjVi2pzDOBrErjh6QpVsEyT
         /G+KCIp6BCrNX6rXWc3up6N83VpDL9hxS/YDH9U1l7jjOXbL8HTIdgm0ziL+Dbf01P0Y
         TOeu5jEgAh5ipM/Z0sNrXhrwEbfq+9fTzn+7B0hqeVKPETozweF64SQh81G+CgsBwKDq
         nPlw==
X-Gm-Message-State: AOJu0Yws5/R/t9cPRlMOU0qCRrQs2qLbFf/xVrbCmgWJ7FF+DHksUI1E
	baFRGAclvD558O4E7SCBMd+pZR3Z3ubUBotrLfoMnV5TdMdfg9khWks2yGKmFoQ=
X-Google-Smtp-Source: AGHT+IGFk/cyBAn+F511ANUmWb04LwZszBbBkWsY9Sjwyu/Xlr3YG2819EtI0fl2hGavl4vHYIK+vg==
X-Received: by 2002:a50:ab51:0:b0:56b:eb90:f3a2 with SMTP id t17-20020a50ab51000000b0056beb90f3a2mr4278952edc.16.1711381491339;
        Mon, 25 Mar 2024 08:44:51 -0700 (PDT)
Message-ID: <0d0b0174-48dd-4b26-8b54-6eefefac33f6@cloud.com>
Date: Mon, 25 Mar 2024 15:44:50 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/6] xen/x86: Add initial x2APIC ID to the per-vLAPIC save
 area
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: Xen-devel ,
 Jan Beulich , Andrew Cooper ,
 Wei Liu 
References: <20240109153834.4192-1-alejandro.vallejo@cloud.com>
 <20240109153834.4192-2-alejandro.vallejo@cloud.com>
 
Content-Language: en-GB
From: Alejandro Vallejo 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Hi,

I'll answer the policy-related feedback in the next email, as you
corrected yourself for that.

On 19/03/2024 16:20, Roger Pau Monné wrote:
> On Tue, Jan 09, 2024 at 03:38:29PM +0000, Alejandro Vallejo wrote:
>> This allows the initial x2APIC ID to be sent on the migration stream. The
>> hardcoded mapping x2apic_id=2*vcpu_id is maintained for the time being.
>> Given the vlapic data is zero-extended on restore, fix up migrations from
>> hosts without the field by setting it to the old convention if zero.
>>
>> x2APIC IDs are calculated from the CPU policy where the guest topology is
>> defined. For the time being, the function simply returns the old
>> relationship, but will eventually return results consistent with the
>> topology.
>>
>> Signed-off-by: Alejandro Vallejo 
>> ---
>>  xen/arch/x86/cpuid.c                   | 20 ++++---------------
>>  xen/arch/x86/domain.c                  |  3 +++
>>  xen/arch/x86/hvm/vlapic.c              | 27 ++++++++++++++++++++++++--
>>  xen/arch/x86/include/asm/hvm/vlapic.h  |  2 ++
>>  xen/include/public/arch-x86/hvm/save.h |  2 ++
>>  xen/include/xen/lib/x86/cpu-policy.h   |  9 +++++++++
>>  xen/lib/x86/policy.c                   | 11 +++++++++++
>>  7 files changed, 56 insertions(+), 18 deletions(-)
>>
>> diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
>> index 7290a979c6..6e259785d0 100644
>> --- a/xen/arch/x86/cpuid.c
>> +++ b/xen/arch/x86/cpuid.c
>> @@ -139,10 +139,9 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
>>          const struct cpu_user_regs *regs;
>>  
>>      case 0x1:
>> -        /* TODO: Rework topology logic. */
>>          res->b &= 0x00ffffffu;
>>          if ( is_hvm_domain(d) )
>> -            res->b |= (v->vcpu_id * 2) << 24;
>> +            res->b |= SET_xAPIC_ID(vlapic_x2apic_id(vcpu_vlapic(v)));
> 
> SET_xAPIC_ID() was intended to be used with the APIC_ID register,
> which also shifts the ID.  Not sure it's logically correct to use
> here, even if functionally equivalent (as is shifts left by 24).
Ack.

> 
>>  
>>          /* TODO: Rework vPMU control in terms of toolstack choices. */
>>          if ( vpmu_available(v) &&
>> @@ -311,20 +310,9 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
>>          break;
>>  
>>      case 0xb:
>> -        /*
>> -         * In principle, this leaf is Intel-only.  In practice, it is tightly
>> -         * coupled with x2apic, and we offer an x2apic-capable APIC emulation
>> -         * to guests on AMD hardware as well.
>> -         *
>> -         * TODO: Rework topology logic.
>> -         */
>> -        if ( p->basic.x2apic )
>> -        {
>> -            *(uint8_t *)&res->c = subleaf;
>> -
>> -            /* Fix the x2APIC identifier. */
>> -            res->d = v->vcpu_id * 2;
>> -        }
>> +        /* ecx != 0 if the subleaf is implemented */
>> +        if ( res->c && p->basic.x2apic )
>> +            res->d = vlapic_x2apic_id(vcpu_vlapic(v));
> 
> This needs to be protected so it's reachable by HVM guests only,
> otherwise you will dereference v->arch.hvm.vlapic on a PV vCPU if it
> happens to have p->basic.x2apic set.
Very true. Ack.

> 
> Why not just return the x2apic_id field from the cpu_policy object?
> (topo.subleaf[X].x2apic_id)
> 
> Also, I'm not sure I get why the setting of res->d is gated on res->c
> != 0, won't res->c be 0 when the guest %ecx is 0, yet %edx must be
> valid for all %ecx inputs, the SDM states:
> 
> "The EDX output of leaf 0BH is always valid and does not vary with
> input value in ECX."
> 
> I think you need to keep the previous logic that doesn't gate setting
> ->d on anything other than p->basic.x2apic.
> 

Ack.

Real HW says you're right. Oddly enough that quote is (AFAICS) for leaf
1FH, but it appears to also hold for 0BH.


>>          break;
>>  
>>      case XSTATE_CPUID:
>> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
>> index 8a31d18f69..e0c7ed8d5d 100644
>> --- a/xen/arch/x86/domain.c
>> +++ b/xen/arch/x86/domain.c
>> @@ -288,7 +288,10 @@ void update_guest_memory_policy(struct vcpu *v,
>>  static void cpu_policy_updated(struct vcpu *v)
>>  {
>>      if ( is_hvm_vcpu(v) )
>> +    {
>>          hvm_cpuid_policy_changed(v);
>> +        vlapic_cpu_policy_changed(v);
>> +    }
>>  }
>>  
>>  void domain_cpu_policy_changed(struct domain *d)
>> diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
>> index cdb69d9742..f500d66543 100644
>> --- a/xen/arch/x86/hvm/vlapic.c
>> +++ b/xen/arch/x86/hvm/vlapic.c
>> @@ -1069,7 +1069,7 @@ static uint32_t x2apic_ldr_from_id(uint32_t id)
>>  static void set_x2apic_id(struct vlapic *vlapic)
>>  {
>>      const struct vcpu *v = vlapic_vcpu(vlapic);
>> -    uint32_t apic_id = v->vcpu_id * 2;
>> +    uint32_t apic_id = vlapic->hw.x2apic_id;
>>      uint32_t apic_ldr = x2apic_ldr_from_id(apic_id);
>>  
>>      /*
>> @@ -1083,6 +1083,22 @@ static void set_x2apic_id(struct vlapic *vlapic)
>>      vlapic_set_reg(vlapic, APIC_LDR, apic_ldr);
>>  }
>>  
>> +void vlapic_cpu_policy_changed(struct vcpu *v)
>> +{
>> +    struct vlapic *vlapic = vcpu_vlapic(v);
>> +    struct cpu_policy *cp = v->domain->arch.cpu_policy;
>> +
>> +    /*
>> +     * Don't override the initial x2APIC ID if we have migrated it or
>> +     * if the domain doesn't have vLAPIC at all.
>> +     */
>> +    if ( !has_vlapic(v->domain) || vlapic->loaded.hw )
>> +        return;
>> +
>> +    vlapic->hw.x2apic_id = x86_x2apic_id_from_vcpu_id(cp, v->vcpu_id);
>> +    vlapic_set_reg(vlapic, APIC_ID, SET_xAPIC_ID(vlapic->hw.x2apic_id));
>> +}
>> +
>>  int guest_wrmsr_apic_base(struct vcpu *v, uint64_t val)
>>  {
>>      const struct cpu_policy *cp = v->domain->arch.cpu_policy;
>> @@ -1449,7 +1465,7 @@ void vlapic_reset(struct vlapic *vlapic)
>>      if ( v->vcpu_id == 0 )
>>          vlapic->hw.apic_base_msr |= APIC_BASE_BSP;
>>  
>> -    vlapic_set_reg(vlapic, APIC_ID, (v->vcpu_id * 2) << 24);
>> +    vlapic_set_reg(vlapic, APIC_ID, SET_xAPIC_ID(vlapic->hw.x2apic_id));
>>      vlapic_do_init(vlapic);
>>  }
>>  
>> @@ -1514,6 +1530,13 @@ static void lapic_load_fixup(struct vlapic *vlapic)
>>      const struct vcpu *v = vlapic_vcpu(vlapic);
>>      uint32_t good_ldr = x2apic_ldr_from_id(vlapic->loaded.id);
>>  
>> +    /*
>> +     * Guest with hardcoded assumptions about x2apic_id <-> vcpu_id
>> +     * mappings. Recreate the mapping it used to have in old host.
> 
> Wouldn't it be more appropriate to state "Loading record without
> hw.x2apic_id in the save stream, calculate using the vcpu_id * 2
> relation" or some such.>
> Current comment makes it looks like the guest has some kind of
> restriction with this relation, but that's just an internal Xen
> limitation.

Sure.

> 
>> +     */
>> +    if ( !vlapic->hw.x2apic_id )
>> +        vlapic->hw.x2apic_id = v->vcpu_id * 2;
>> +
>>      /* Skip fixups on xAPIC mode, or if the x2APIC LDR is already correct */
>>      if ( !vlapic_x2apic_mode(vlapic) ||
>>           (vlapic->loaded.ldr == good_ldr) )
>> diff --git a/xen/arch/x86/include/asm/hvm/vlapic.h b/xen/arch/x86/include/asm/hvm/vlapic.h
>> index 88ef945243..e8d41313ab 100644
>> --- a/xen/arch/x86/include/asm/hvm/vlapic.h
>> +++ b/xen/arch/x86/include/asm/hvm/vlapic.h
>> @@ -44,6 +44,7 @@
>>  #define vlapic_xapic_mode(vlapic)                               \
>>      (!vlapic_hw_disabled(vlapic) && \
>>       !((vlapic)->hw.apic_base_msr & APIC_BASE_EXTD))
>> +#define vlapic_x2apic_id(vlapic) ((vlapic)->hw.x2apic_id)
>>  
>>  /*
>>   * Generic APIC bitmap vector update & search routines.
>> @@ -107,6 +108,7 @@ int vlapic_ack_pending_irq(struct vcpu *v, int vector, bool force_ack);
>>  
>>  int  vlapic_init(struct vcpu *v);
>>  void vlapic_destroy(struct vcpu *v);
>> +void vlapic_cpu_policy_changed(struct vcpu *v);
>>  
>>  void vlapic_reset(struct vlapic *vlapic);
>>  
>> diff --git a/xen/include/public/arch-x86/hvm/save.h b/xen/include/public/arch-x86/hvm/save.h
>> index 7ecacadde1..1c2ec669ff 100644
>> --- a/xen/include/public/arch-x86/hvm/save.h
>> +++ b/xen/include/public/arch-x86/hvm/save.h
>> @@ -394,6 +394,8 @@ struct hvm_hw_lapic {
>>      uint32_t             disabled; /* VLAPIC_xx_DISABLED */
>>      uint32_t             timer_divisor;
>>      uint64_t             tdt_msr;
>> +    uint32_t             x2apic_id;
>> +    uint32_t             rsvd_zero;
> 
> Do we really to add a new field, couldn't we get the lapic IDs from
> the cpu_policy>
>>  };
>>  
>>  DECLARE_HVM_SAVE_TYPE(LAPIC, 5, struct hvm_hw_lapic);
>> diff --git a/xen/include/xen/lib/x86/cpu-policy.h b/xen/include/xen/lib/x86/cpu-policy.h
>> index d5e447e9dc..14724cedff 100644
>> --- a/xen/include/xen/lib/x86/cpu-policy.h
>> +++ b/xen/include/xen/lib/x86/cpu-policy.h
>> @@ -542,6 +542,15 @@ int x86_cpu_policies_are_compatible(const struct cpu_policy *host,
>>                                      const struct cpu_policy *guest,
>>                                      struct cpu_policy_errors *err);
>>  
>> +/**
>> + * Calculates the x2APIC ID of a vCPU given a CPU policy
>> + *
>> + * @param p          CPU policy of the domain.
>> + * @param vcpu_id    vCPU ID of the vCPU.
>> + * @returns x2APIC ID of the vCPU.
>> + */
>> +uint32_t x86_x2apic_id_from_vcpu_id(const struct cpu_policy *p, uint32_t vcpu_id);
>> +
>>  #endif /* !XEN_LIB_X86_POLICIES_H */
>>  
>>  /*
>> diff --git a/xen/lib/x86/policy.c b/xen/lib/x86/policy.c
>> index f033d22785..a3b24e6879 100644
>> --- a/xen/lib/x86/policy.c
>> +++ b/xen/lib/x86/policy.c
>> @@ -2,6 +2,17 @@
>>  
>>  #include 
>>  
>> +uint32_t x86_x2apic_id_from_vcpu_id(const struct cpu_policy *p, uint32_t vcpu_id)
>> +{
>> +    /*
>> +     * TODO: Derive x2APIC ID from the topology information inside `p`
>> +     *       rather than from vCPU ID. This bodge is a temporary measure
>> +     *       until all infra is in place to retrieve or derive the initial
>> +     *       x2APIC ID from migrated domains.
>> +     */
>> +    return vcpu_id * 2;
> 
> As noted above, won't a suitable initial step would be to populate the
> apic_id and x2apic_id fields in struct cpu_policy with this relation
> (x{,2}apic_id == vcpu_id * 2), and avoid this extra handler?
> 
> Thanks, Roger.

Cheers,
Alejandro



From xen-devel-bounces@lists.xenproject.org Mon Mar 25 16:13:13 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 16:13:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697812.1088944 (Exim 4.92)
	(envelope-from )
	id 1romwT-0007Et-Vz; Mon, 25 Mar 2024 16:12:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697812.1088944; Mon, 25 Mar 2024 16:12:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1romwT-0007Em-SN; Mon, 25 Mar 2024 16:12:57 +0000
Received: by outflank-mailman (input) for mailman id 697812;
 Mon, 25 Mar 2024 16:12:56 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1romwS-0007Eg-SW
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 16:12:56 +0000
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com
 [2a00:1450:4864:20::530])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 883f332f-eac2-11ee-a1ef-f123f15fe8a2;
 Mon, 25 Mar 2024 17:12:52 +0100 (CET)
Received: by mail-ed1-x530.google.com with SMTP id
 4fb4d7f45d1cf-55a179f5fa1so5840133a12.0
 for ; Mon, 25 Mar 2024 09:12:52 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 t25-20020a056402241900b0056bd13ce50esm3088408eda.44.2024.03.25.09.12.51
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 25 Mar 2024 09:12:51 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 883f332f-eac2-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711383172; x=1711987972; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=cSdtkagSlMJYslTrdnlqUwgM847MIlDlTf6vMwIncT8=;
        b=giz7NdDIoPxoH2DIpFsrvuF8Ii70n7WQ9KlAoHhORB3EuxuKffESXsHqvefkz4Hfw7
         VN/IeaGKJw/oUyBRd/Gc3YwN4tH029kSFGBNeEr4lrEX5TZgybg8ZioFcbR9JpBVOjNe
         BSJtYC1w91tO9MvzHYz/HTIZXQYjC8tYZ663YCQDBeqhDtV9ko7CbN8Xwui1d7Ii9O1B
         BMPIIiNV4Kbie+vDm4hRMFBKH2aEN3+rFxlT6zPLdkMqpAjY1V9+SbL6gqcpfEhh1Y34
         5jpjTU6JwnxsirCK6dLXuvbjw9jKNzyGL+mNN1kDitGb9jtWCnIN7SeWVovWHQJOeXhn
         QEng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711383172; x=1711987972;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=cSdtkagSlMJYslTrdnlqUwgM847MIlDlTf6vMwIncT8=;
        b=FG4ksGGWh496U5QphDoacwP3lkUP1mm/MKHZljuk/EDIt9PZKyWEu0ANcdtgYJtX4I
         M7Al1tO7HumnuJT6HzEvaWB1NqX3DXXwrQpH9hchxjFKMx0FDNmA8L0QyfeS32fx0pVj
         qUOSGAxNCEAVqv0LjGcszENjyMZQMhbhCUXX7BO18BKw/jTmiz50hIfEm9UVgWDlOM8j
         uL5RudSZR+p6fmAM5XqMlOV8zd5oUZ3LbDVS2dCamLuHe0W7vlyvzgKhYGannaGJs6Qt
         0BFfHE+8QFPUZ6nYbM90CSFshZvCLZOUtk1ne8kzX2uDpDBck1ZAjsy/eRGcuYkTj2Ze
         nQcQ==
X-Forwarded-Encrypted: i=1; AJvYcCXIMx/wnPMHKQboS0TkaHletpuG61AevQh5X2OXve69z5tdmTcuy0OGgkM5i3u00igaebgaGxlxakLeQf3aPcRCWSoAzl2p+VzcHq9VBz4=
X-Gm-Message-State: AOJu0YxRQqvz5iYjKJyYrRdoCLaUoAXUvw0x2fV+qWTc14KS0pOwcJm8
	CaKXYCgnccjNVuvbBBilYEuJJe0TUbNDWI5UlAHSWdhz6/9NoRQeazsutxRp2g==
X-Google-Smtp-Source: AGHT+IHd94nFOT4l4bMrpReZ+8UQUA0RJdv7ZUbWCySOTRYBxPNj3bcvhWhMmuGIC2Sj7aX8eqzShw==
X-Received: by 2002:a50:9e2d:0:b0:565:6c72:40a9 with SMTP id z42-20020a509e2d000000b005656c7240a9mr5472035ede.28.1711383171989;
        Mon, 25 Mar 2024 09:12:51 -0700 (PDT)
Message-ID: <9d665a86-3867-4347-9e17-839cf4762f20@suse.com>
Date: Mon, 25 Mar 2024 17:12:50 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 1/2] x86: Enable BLD and handle #DB traps
Content-Language: en-US
To: Matthew Barnes 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Xen-devel 
References: 
 <5c0c2fd252f425a397981546496438ebac439db2.1710524011.git.matthew.barnes@cloud.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <5c0c2fd252f425a397981546496438ebac439db2.1710524011.git.matthew.barnes@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 15.03.2024 18:52, Matthew Barnes wrote:
> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -623,6 +623,11 @@ void identify_cpu(struct cpuinfo_x86 *c)
>  	}
>  
>  	setup_doitm();
> +
> +	if (cpu_has(c, X86_FEATURE_BLD)) {
> +		host_msr_debugctl |= IA32_DEBUGCTLMSR_BLD;
> +		wrmsrl(MSR_IA32_DEBUGCTLMSR, host_msr_debugctl);
> +	}

With the exception only occurring for CPL > 0, is this of any use in !PV
builds?

I'm also unconvinced of the use of cpu_has() here: We expect symmetry
(as can also be seen by you not using a per-CPU variable to hold the
designated register value). Perhaps boot_cpu_has() would be better here.

Together with the change to percpu_traps_init(), perhaps worth introducing
something like set_in_debugctl()?

> --- a/xen/arch/x86/hvm/vmx/entry.S
> +++ b/xen/arch/x86/hvm/vmx/entry.S
> @@ -46,8 +46,8 @@ ENTRY(vmx_asm_vmexit_handler)
>          /* WARNING! `ret`, `call *`, `jmp *` not safe before this point. */
>  
>          /* Hardware clears MSR_DEBUGCTL on VMExit.  Reinstate it if debugging Xen. */
> +        mov host_msr_debugctl(%rip), %eax
>          .macro restore_lbr
> -            mov $IA32_DEBUGCTLMSR_LBR, %eax
>              mov $MSR_IA32_DEBUGCTLMSR, %ecx
>              xor %edx, %edx
>              wrmsr

The alternative just out of context is

        ALTERNATIVE "", restore_lbr, X86_FEATURE_XEN_LBR

i.e. the restore won't happen if XEN_LBR isn't active.

Together with the !PV question above I'd then like to ask whether playing
with the BLD bit is necessary at all while running a HVM vCPU. The bit
could be turned back on from the PV context-switch-in path instead. Which
would in turn remove the need for e.g. the wrmsrl() in identify_cpu(), I
believe.

In fact with us not using the "load debug controls" VM entry control I'm
having a hard time seeing how the carefully established VMCS field would
ever make it into the MSR. Instead we look to be running the guest with
the value we put there last. That wouldn't be quite right with the BLD
bit set in there unconditionally (the LBR one at least would only be set
when the respective command line option was used).

> --- a/xen/arch/x86/include/asm/debugreg.h
> +++ b/xen/arch/x86/include/asm/debugreg.h
> @@ -19,6 +19,7 @@
>  #define DR_TRAP1        (0x2)           /* db1 */
>  #define DR_TRAP2        (0x4)           /* db2 */
>  #define DR_TRAP3        (0x8)           /* db3 */
> +#define DR_TRAP11       (0x800)         /* db11 */

This isn't the flag for %dr11, so wants naming differently. Perhaps simply
DR_BLD.

> --- a/xen/arch/x86/msr.c
> +++ b/xen/arch/x86/msr.c
> @@ -24,6 +24,8 @@
>  
>  #include 
>  
> +uint32_t host_msr_debugctl;

This wants to be __ro_after_init, with appropriate care applied in
identify_cpu().

> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -1936,9 +1936,12 @@ void asmlinkage do_debug(struct cpu_user_regs *regs)
>       */
>      write_debugreg(6, X86_DR6_DEFAULT);
>  
> +    if ( !( dr6 & DR_TRAP11 ) )
> +        return;

Nit: Stray blanks immediately inside the inner parentheses.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Mar 25 16:17:15 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 16:17:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697815.1088953 (Exim 4.92)
	(envelope-from )
	id 1ron0c-0007oS-Ev; Mon, 25 Mar 2024 16:17:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697815.1088953; Mon, 25 Mar 2024 16:17:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1ron0c-0007oL-CQ; Mon, 25 Mar 2024 16:17:14 +0000
Received: by outflank-mailman (input) for mailman id 697815;
 Mon, 25 Mar 2024 16:17:12 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1ron0a-0007nx-AF
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 16:17:12 +0000
Received: from wfhigh5-smtp.messagingengine.com
 (wfhigh5-smtp.messagingengine.com [64.147.123.156])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2064b01c-eac3-11ee-a1ef-f123f15fe8a2;
 Mon, 25 Mar 2024 17:17:09 +0100 (CET)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43])
 by mailfhigh.west.internal (Postfix) with ESMTP id 49B7F18000E4
 for ; Mon, 25 Mar 2024 12:17:06 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163])
 by compute3.internal (MEProxy); Mon, 25 Mar 2024 12:17:06 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA for
 ; Mon, 25 Mar 2024 12:17:05 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2064b01c-eac3-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:content-type:content-type:date:date
	:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to; s=fm2; t=1711383425;
	 x=1711469825; bh=+4KN1/QbA1tmpIA3PCvp2PBb4ilCi4RWpfddFhSMt/0=; b=
	a2VQWWYMFp+O5a41kT4u8rP3bW6PAH/XpFp6Kiz8pUh2ptbRUIPh7yRvRGEi3RdI
	4A5tElZ0b2T7/gOxoEwZrbAJCnjWlf06naT7zUV/XYlM46sLqsm6fM4kp+eKOPXK
	g9HKAUdlp1D6yJrf0jF+oYCiNu3FThYXvsAqi3fDgHlLDDVd/ehmmnrTB1mScvrr
	mRNkInBz0qfJHEBTeex4YogKWu0LAwU84XcKfIym9Q4zflaTGuGLdud3ryAX9r7m
	pnQOaJWzHHjHcAL/B4jYuNv/d2SOGRSNPZ4shCldS7tBHI0Oc4KGk+9zxsrE/24P
	TZ+PNVIHBY7UxIF506DdXw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:content-type:content-type:date:date
	:feedback-id:feedback-id:from:from:in-reply-to:in-reply-to
	:message-id:mime-version:references:reply-to:subject:subject:to
	:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=
	fm2; t=1711383425; x=1711469825; bh=+4KN1/QbA1tmpIA3PCvp2PBb4ilC
	i4RWpfddFhSMt/0=; b=pmmCXAJmNl5qHs0Z5LsP1X8sUV+XYecX843Bnt280REc
	ez+c9pfY5JMUzjyjPVMobIs3EEWFM7mhXxPKcGQP7okwfRspW1OE37mK4nGuYaFg
	8sbcWG091WNCvWLG2To7K+UkZoy6wCXv8HaCBO+kPbMci0h3VDn85GkVUY/hTRuZ
	MgOhvTZKB7byoUG/aurwxvcxg4YdaHTjX2RYCgct6nk4xlx1g38CRTpgLW0wxpPI
	Oxm4JhntbLngHKxFErhxaPCDkaUCPOmEIq+gj3zpWCGJOt7CtJf6AefA2Co86dqN
	P2RUV4kB1UYfheBcGb6SptjEcPJk7j1/xVVRy5xjtg==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrudduuddgvdeiucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
    uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesghdtre
    ertddtjeenucfhrhhomhepofgrrhgvkhcuofgrrhgtiiihkhhofihskhhiqdfikphrvggt
    khhiuceomhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomh
    eqnecuggftrfgrthhtvghrnhepjedutdeivdduleeikeevveeggfeivdefgfejfefgteej
    teefleeileelieektddvnecuffhomhgrihhnpehophgvnhhsuhhsvgdrohhrghdpqhhusg
    gvshdqohhsrdhorhhgpdhgihhthhhusgdrtghomhenucevlhhushhtvghrufhiiigvpedt
    necurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhesihhnvhhishhisghlvg
    hthhhinhhgshhlrggsrdgtohhm
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Mon, 25 Mar 2024 17:17:02 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: xen-devel 
Subject: Re: NULL pointer dereference in xenbus_thread->...
Message-ID: 
References: 
 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="QFJG0LqIoqPJKlrM"
Content-Disposition: inline
In-Reply-To: 


--QFJG0LqIoqPJKlrM
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Mon, 25 Mar 2024 17:17:02 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: xen-devel 
Subject: Re: NULL pointer dereference in xenbus_thread->...

On Sun, Oct 22, 2023 at 04:14:30PM +0200, Marek Marczykowski-G=C3=B3recki w=
rote:
> On Mon, Aug 28, 2023 at 11:50:36PM +0200, Marek Marczykowski-G=C3=B3recki=
 wrote:
> > Hi,
> >=20
> > I've noticed in Qubes's CI failure like this:
> >=20
> > [  871.271292] BUG: kernel NULL pointer dereference, address: 000000000=
0000000
> > [  871.275290] #PF: supervisor read access in kernel mode
> > [  871.277282] #PF: error_code(0x0000) - not-present page
> > [  871.279182] PGD 106fdb067 P4D 106fdb067 PUD 106fdc067 PMD 0=20
> > [  871.281071] Oops: 0000 [#1] PREEMPT SMP NOPTI
> > [  871.282698] CPU: 1 PID: 28 Comm: xenbus Not tainted 6.1.43-1.qubes.f=
c37.x86_64 #1
> > [  871.285222] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), B=
IOS rel-1.16.0-0-gd239552-rebuilt.opensuse.org 04/01/2014
> > [  871.288883] RIP: e030:__wake_up_common+0x4c/0x180
> > [  871.292838] Code: 24 0c 89 4c 24 08 4d 85 c9 74 0a 41 f6 01 04 0f 85=
 a3 00 00 00 48 8b 43 08 4c 8d 40 e8 48 83 c3 08 49 8d 40 18 48 39 c3 74 5b=
 <49> 8b 40 18 31 ed 4c 8d 70 e8 45 8b 28 41 f6 c5 04 75 5f 49 8b 40
> > [  871.299776] RSP: e02b:ffffc900400f7e10 EFLAGS: 00010082
> > [  871.301656] RAX: 0000000000000000 RBX: ffff88810541ce98 RCX: 0000000=
000000000
> > [  871.304255] RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffff888=
10541ce90
> > [  871.306714] RBP: ffffc900400f0280 R08: ffffffffffffffe8 R09: ffffc90=
0400f7e68
> > [  871.309937] R10: 0000000000007ff0 R11: ffff888100ad3000 R12: ffffc90=
0400f7e68
> > [  871.312326] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000=
000000000
> > [  871.314647] FS:  0000000000000000(0000) GS:ffff88813ff00000(0000) kn=
lGS:0000000000000000
> > [  871.317677] CS:  10000e030 DS: 0000 ES: 0000 CR0: 0000000080050033
> > [  871.319644] CR2: 0000000000000000 CR3: 00000001067fe000 CR4: 0000000=
000040660
> > [  871.321973] Call Trace:
> > [  871.322782]  
> > [  871.323494]  ? show_trace_log_lvl+0x1d3/0x2ef
> > [  871.324901]  ? show_trace_log_lvl+0x1d3/0x2ef
> > [  871.326310]  ? show_trace_log_lvl+0x1d3/0x2ef
> > [  871.327721]  ? __wake_up_common_lock+0x82/0xd0
> > [  871.329147]  ? __die_body.cold+0x8/0xd
> > [  871.330378]  ? page_fault_oops+0x163/0x1a0
> > [  871.331691]  ? exc_page_fault+0x70/0x170
> > [  871.332946]  ? asm_exc_page_fault+0x22/0x30
> > [  871.334454]  ? __wake_up_common+0x4c/0x180
> > [  871.335777]  __wake_up_common_lock+0x82/0xd0
> > [  871.337183]  ? process_writes+0x240/0x240
> > [  871.338461]  process_msg+0x18e/0x2f0
> > [  871.339627]  xenbus_thread+0x165/0x1c0
> > [  871.340830]  ? cpuusage_read+0x10/0x10
> > [  871.342032]  kthread+0xe9/0x110
> > [  871.343317]  ? kthread_complete_and_exit+0x20/0x20
> > [  871.345020]  ret_from_fork+0x22/0x30
> > [  871.346239]  
> > [  871.347060] Modules linked in: snd_hda_codec_generic ledtrig_audio s=
nd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec snd_hda_core=
 snd_hwdep snd_seq snd_seq_device joydev snd_pcm intel_rapl_msr ppdev intel=
_rapl_common snd_timer pcspkr e1000e snd soundcore i2c_piix4 parport_pc par=
port loop fuse xenfs dm_crypt crct10dif_pclmul crc32_pclmul crc32c_intel po=
lyval_clmulni polyval_generic floppy ghash_clmulni_intel sha512_ssse3 serio=
_raw virtio_scsi virtio_console bochs xhci_pci xhci_pci_renesas xhci_hcd qe=
mu_fw_cfg drm_vram_helper drm_ttm_helper ttm ata_generic pata_acpi xen_priv=
cmd xen_pciback xen_blkback xen_gntalloc xen_gntdev xen_evtchn scsi_dh_rdac=
 scsi_dh_emc scsi_dh_alua uinput dm_multipath
> > [  871.368892] CR2: 0000000000000000
> > [  871.370160] ---[ end trace 0000000000000000 ]---
> > [  871.371719] RIP: e030:__wake_up_common+0x4c/0x180
> > [  871.373273] Code: 24 0c 89 4c 24 08 4d 85 c9 74 0a 41 f6 01 04 0f 85=
 a3 00 00 00 48 8b 43 08 4c 8d 40 e8 48 83 c3 08 49 8d 40 18 48 39 c3 74 5b=
 <49> 8b 40 18 31 ed 4c 8d 70 e8 45 8b 28 41 f6 c5 04 75 5f 49 8b 40
> > [  871.379866] RSP: e02b:ffffc900400f7e10 EFLAGS: 00010082
> > [  871.381689] RAX: 0000000000000000 RBX: ffff88810541ce98 RCX: 0000000=
000000000
> > [  871.383971] RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffff888=
10541ce90
> > [  871.386235] RBP: ffffc900400f0280 R08: ffffffffffffffe8 R09: ffffc90=
0400f7e68
> > [  871.388521] R10: 0000000000007ff0 R11: ffff888100ad3000 R12: ffffc90=
0400f7e68
> > [  871.390789] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000=
000000000
> > [  871.393101] FS:  0000000000000000(0000) GS:ffff88813ff00000(0000) kn=
lGS:0000000000000000
> > [  871.395671] CS:  10000e030 DS: 0000 ES: 0000 CR0: 0000000080050033
> > [  871.397863] CR2: 0000000000000000 CR3: 00000001067fe000 CR4: 0000000=
000040660
> > [  871.400441] Kernel panic - not syncing: Fatal exception
> > [  871.402171] Kernel Offset: disabled
> > (XEN) Hardware Dom0 crashed: rebooting machine in 5 seconds.
> >=20
> > It isn't the first time I see similar crash, but I can't really
> > reproduce it reliably. Restarted test usually passes.
> > Note this is Xen nested in KVM, so it could very well be some oddity
> > about nested virt, although looking at the stack trace, it's unlikely
> > and more likely some race condition hit only on slower system.
>=20
> Recently I've got the same crash on a real system in domU too. And also
> on nested on newer kernel 6.1.57 (here it happened in dom0). So, this is
> still an issue and affects not only nested case :/
>=20
> > Unfortunately I don't have symbols for this kernel handy, but there is a
> > single wake_up() call in process_writes(), so it shouldn't be an issue.
> >=20
> > Any ideas?
> >=20
> > Full log at https://openqa.qubes-os.org/tests/80779/logfile?filename=3D=
serial0.txt
>=20
> More links at https://github.com/QubesOS/qubes-issues/issues/8638,
> including more recent stack trace.

Happens on 6.1.75 too (new stack trace I've added to the issue above,
but it's pretty similar).

--=20
Best Regards,
Marek Marczykowski-G=C3=B3recki
Invisible Things Lab

--QFJG0LqIoqPJKlrM
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYBo38ACgkQ24/THMrX
1ywnegf9GG8xk/ikGtyJTvfUknyYM41+prC5YEE1XkvzkDqICPweKbVgOcKQc7+j
iBIb63p7vD2aKZJLaRpsczhfQnC43VEUi4uSGbYpsZhO8HRq2dEosO/qNgtFxRPg
RyXTvdfRmbK502GaeD6rSKWWd/bodgTIv1kLWqOWFvFQD5uq1tStNWG+TBWWtvvB
IBbXmBSxX+OhpKaICxe2WoZwS8GGFLQa2RxZc6mhILBz3yj1e65ZxTSkPbCmqMSL
lsZeIFQAxiKINLkOg+BTS5RVxwPR9XGXa5ryXBhYFfKZbTxTeZN4F7RHDpTvS+K1
sQte0oE3QDX090KaHtTLGJv0QlrIQQ==
=op5g
-----END PGP SIGNATURE-----

--QFJG0LqIoqPJKlrM--


From xen-devel-bounces@lists.xenproject.org Mon Mar 25 16:29:27 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 16:29:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697820.1088963 (Exim 4.92)
	(envelope-from )
	id 1ronCL-0001RW-G6; Mon, 25 Mar 2024 16:29:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697820.1088963; Mon, 25 Mar 2024 16:29:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1ronCL-0001RP-DF; Mon, 25 Mar 2024 16:29:21 +0000
Received: by outflank-mailman (input) for mailman id 697820;
 Mon, 25 Mar 2024 16:29:20 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1ronCK-0001RJ-SP
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 16:29:20 +0000
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com
 [2a00:1450:4864:20::12a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d48902ab-eac4-11ee-afe3-a90da7624cb6;
 Mon, 25 Mar 2024 17:29:19 +0100 (CET)
Received: by mail-lf1-x12a.google.com with SMTP id
 2adb3069b0e04-5159f9de7fbso2710802e87.1
 for ; Mon, 25 Mar 2024 09:29:19 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 p12-20020a05640243cc00b00568afb0e731sm3125505edc.63.2024.03.25.09.29.18
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 25 Mar 2024 09:29:18 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d48902ab-eac4-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711384159; x=1711988959; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=2N9eBXLMBlXsRNH82awHVSsQHNH8RgBb8IQ7LI5k6aM=;
        b=L36S+gx5hYeCBj2KtrHsZsGjoMvgUgDM94BkwfNzMNUz2HjYsducoMXRpOW8G9nWZ0
         hny1AL6Ivd0AQMRGa9iFhBRNgAjpN7SnbjsOWtpLYuMu5Wa4X1wcyOKRm1Wrd4mnU3d6
         ttKZXmut7RxVSWXJQjdoKDIFkN/UvVm40jsh4NZ331A29MH3cx45cQ/60Rk2ErBAgzzR
         idNc9KXZUCh91m1fSAfT6cZ3NEVHHhTMmv0/O1/cVb3wmZZdcKYYmk96amOA9ELfk1wo
         pp2GAhB1BMpn6C8vaqVDSykm4t23szzciY6pLlrZAeDXaZHHPoC9oZWAqFfiNAOrPSu0
         +YHA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711384159; x=1711988959;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=2N9eBXLMBlXsRNH82awHVSsQHNH8RgBb8IQ7LI5k6aM=;
        b=F1E0viffy00BtCvy6FYJV8yvcllwPQofKV9yVRqGinYKR0lfwYLLHedOLOVts4rMIS
         YQeQ6J4XD4VDBTssK6nSj9bAswUmYhEKqar2IJ7S8u6oPwjOLWgpiVpGdX4J1qWzdUg7
         SM86Uf1prhrzcYIcYtSITc5xDSL1ZryRpaOi7HEiD1jr0BljtP+5UCsypvRmKBGASBd/
         6AEhnas4146gtg3DZZRm+0P429Xnl4XnUD0+dzTRBxWRne8g5wnvFmhXY0SHyzxlzpAW
         IAjUXN1uCol1SYwVPA23y0CpmCYOt8OfCRblPiWnUfh7+QtgDBBliaARK15cMLKpegcw
         FAow==
X-Forwarded-Encrypted: i=1; AJvYcCVdaqCShBh9rF5UKbnFIF7a0BBohBGddnTNcGInUwBoNAjRgCWgfnVq6yOfgnGfyC8Ey5pRPM1Z9nlDpeZoDalWno4rN6NWcTjH6o1vGrA=
X-Gm-Message-State: AOJu0YxEsI0Pf1jyGQy7c+ZAQ0R7CavAL04h+z3kYKlljP9CjclNPmM+
	EkKYLtg5Gl60oBmpGIi+L7ES/Z06LqBOUpuz2i1+uTvqL+ZdzLGijW7mIdl13Q==
X-Google-Smtp-Source: AGHT+IHW6Gb9m2DU1jo92YOMCIuxIp/YltamAgw1Z1WXoa6CoPJQn3HQQEjW67cwnnaSvpfhHXqsAA==
X-Received: by 2002:a05:6512:1cc:b0:513:cf52:3c15 with SMTP id f12-20020a05651201cc00b00513cf523c15mr4971677lfp.49.1711384159145;
        Mon, 25 Mar 2024 09:29:19 -0700 (PDT)
Message-ID: <4648a287-7d65-4a55-9800-4389229b79a7@suse.com>
Date: Mon, 25 Mar 2024 17:29:18 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 2/2] x86: Refactor LBR feature to MSR_DEBUGCTL feature
Content-Language: en-US
To: Matthew Barnes 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Xen-devel 
References: 
 <2f690a115fc78989bfc2e331221d7e10b5dcb196.1710524011.git.matthew.barnes@cloud.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <2f690a115fc78989bfc2e331221d7e10b5dcb196.1710524011.git.matthew.barnes@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 15.03.2024 18:52, Matthew Barnes wrote:
> Last Branch Record and Bus Lock Detect both belong to the same MSR.
> 
> The same mechanism that restores LBR also restores BLD.
> 
> Therefore, the name of the feature that enables this mechanism should
> reflect restoring the MSR, instead of one field.
> 
> No functional change.
> 
> Signed-off-by: Matthew Barnes 

So this in part is what I asked about in reply to patch 1. However,
afaict the order of patches wants flipping and ...

> @@ -2129,10 +2129,10 @@ void percpu_traps_init(void)
>              return;
>          }
>  
> -        setup_force_cpu_cap(X86_FEATURE_XEN_LBR);
> +        setup_force_cpu_cap(X86_FEATURE_XEN_MSR_DEBUGCTL);

... besides here you also want to engage the feature when using BLD
(in the other patch, once that comes comes on top of this one).

>      }
>  
> -    if ( cpu_has_xen_lbr )
> +    if ( cpu_has_xen_msr_debugctl )
>      {
>          host_msr_debugctl |= IA32_DEBUGCTLMSR_LBR;
>          wrmsrl(MSR_IA32_DEBUGCTLMSR, host_msr_debugctl);

This can't be quite right - LBR shouldn't be enabled without the
respective command line option present.

And btw - I don't think there's a need for the _msr_ infix in the new
names you use.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Mar 25 16:45:49 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 16:45:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697825.1088974 (Exim 4.92)
	(envelope-from )
	id 1ronS8-0004m3-Rv; Mon, 25 Mar 2024 16:45:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697825.1088974; Mon, 25 Mar 2024 16:45:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1ronS8-0004lw-PD; Mon, 25 Mar 2024 16:45:40 +0000
Received: by outflank-mailman (input) for mailman id 697825;
 Mon, 25 Mar 2024 16:45:39 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1ronS7-0004lq-Qh
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 16:45:39 +0000
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com
 [2a00:1450:4864:20::535])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1c13da5b-eac7-11ee-afe3-a90da7624cb6;
 Mon, 25 Mar 2024 17:45:38 +0100 (CET)
Received: by mail-ed1-x535.google.com with SMTP id
 4fb4d7f45d1cf-56bf6418434so2689068a12.0
 for ; Mon, 25 Mar 2024 09:45:38 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 o22-20020aa7dd56000000b0056c07b6924csm2074248edw.41.2024.03.25.09.45.37
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 25 Mar 2024 09:45:37 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1c13da5b-eac7-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711385138; x=1711989938; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=ebxxSQhH4DQUrHi2mWFUfMsXFjTw2goRkbA68HaT/lA=;
        b=GEYGIv2JuDBsGnBDWxl1OEO7pSu3pCIZQ5GL6WanIhuApcvMFaPmYjvLct3Hpo6VIj
         7SzejXLqKfshevRDFDjPcnG1VBUg3ZASOCxe6S/wdBUQwKs9U87IeYKjKfSEGQB8WffE
         v2gAK4H8fFSU6ujiNKofJudw89hWpkJ3iUYsoOcZDYEWg0bdS/I1IDhWeX1mJKG05lCl
         jPh47ulgMV4CBF4JqgPHTQj5T8XsmyTsQjB5TGPjQ9Ju9wCVFEip+A8qQX+crpXB1wvp
         Qmrx21BhywbsX+/ZNBsJMtFuj+5R44YqW9Cz2moZTx/4BbeBWsn9PDZu0TWA0fG9Gd7P
         k0KA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711385138; x=1711989938;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=ebxxSQhH4DQUrHi2mWFUfMsXFjTw2goRkbA68HaT/lA=;
        b=B4EuRqb7AuT4/G1EhsOT1pR8Kkpx/fhaygsM68AtcprHtMet+Vx1P1WN4Pd05O1fQw
         KNxRCqfjj/RInNyAdhPGyB1qs94d7pQHUAk0tajyfMeU0cJxaV5ggEXMstCqPAVT66y4
         jZmKZoTjs0cMaTmg9OfffjTQT//tLshBucsqOkqVGO5iWUqujqd1HjzLiePmjarH86+n
         kOXmLYZCXNsJd23qLmr/anvco3jJcauAaLWahuRV4GlfSuQOxdhCmJwYVxZ2uoM8AxFH
         dbdcXVTFaYwBLv9V7+P4qmc4e3Ve86xiZJhvNP554TzK7Tr7qKp19/g10tdYB2lduxW/
         lSlQ==
X-Forwarded-Encrypted: i=1; AJvYcCVBE/jBCyh5/Qqtm7om8fW+0ohGUlBqmfwaaZ8iRFP8nwr9QRiq/qsASZ3A+gkH44FUPivi+qffbCQM83HAv3sbxSx+p2YVfV7hdAxov2M=
X-Gm-Message-State: AOJu0YwT8x6j3dXTF+Ep7xJafWC6RrpgLngaOTKXDC1jc+8nOry9GKvD
	qq0DBLU9RXBjNEl1IfmaYLefFmI/PkozpeiB5OlScmeMsCTf6XV+Z8kCkN7FHQ==
X-Google-Smtp-Source: AGHT+IGzhgjJLFfoafS2jGh/RAfKcRyn/OZfKqVTBfsKckThOHMeopa3ir4ic49vb97Wetgxd1eDZA==
X-Received: by 2002:a50:955a:0:b0:568:c608:8058 with SMTP id v26-20020a50955a000000b00568c6088058mr5378324eda.17.1711385138209;
        Mon, 25 Mar 2024 09:45:38 -0700 (PDT)
Message-ID: <2e7fe91e-b483-4d61-9783-0cfa3753911f@suse.com>
Date: Mon, 25 Mar 2024 17:45:37 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/6] xen/x86: Add initial x2APIC ID to the per-vLAPIC save
 area
Content-Language: en-US
To: Alejandro Vallejo 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Xen-devel 
References: <20240109153834.4192-1-alejandro.vallejo@cloud.com>
 <20240109153834.4192-2-alejandro.vallejo@cloud.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240109153834.4192-2-alejandro.vallejo@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 09.01.2024 16:38, Alejandro Vallejo wrote:
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -288,7 +288,10 @@ void update_guest_memory_policy(struct vcpu *v,
>  static void cpu_policy_updated(struct vcpu *v)
>  {
>      if ( is_hvm_vcpu(v) )
> +    {
>          hvm_cpuid_policy_changed(v);
> +        vlapic_cpu_policy_changed(v);
> +    }
>  }

This is a layering violation imo; hvm_cpuid_policy_changed() wants
to call vlapic_cpu_policy_changed().

> @@ -1083,6 +1083,22 @@ static void set_x2apic_id(struct vlapic *vlapic)
>      vlapic_set_reg(vlapic, APIC_LDR, apic_ldr);
>  }
>  
> +void vlapic_cpu_policy_changed(struct vcpu *v)
> +{
> +    struct vlapic *vlapic = vcpu_vlapic(v);
> +    struct cpu_policy *cp = v->domain->arch.cpu_policy;

const please

> @@ -1514,6 +1530,13 @@ static void lapic_load_fixup(struct vlapic *vlapic)
>      const struct vcpu *v = vlapic_vcpu(vlapic);
>      uint32_t good_ldr = x2apic_ldr_from_id(vlapic->loaded.id);
>  
> +    /*
> +     * Guest with hardcoded assumptions about x2apic_id <-> vcpu_id
> +     * mappings. Recreate the mapping it used to have in old host.
> +     */
> +    if ( !vlapic->hw.x2apic_id )
> +        vlapic->hw.x2apic_id = v->vcpu_id * 2;

This looks to depend upon it only ever being vCPU which may get a (new
style) APIC ID of 0. I think such at least wants mentioning in the
comment.

> --- a/xen/include/public/arch-x86/hvm/save.h
> +++ b/xen/include/public/arch-x86/hvm/save.h
> @@ -394,6 +394,8 @@ struct hvm_hw_lapic {
>      uint32_t             disabled; /* VLAPIC_xx_DISABLED */
>      uint32_t             timer_divisor;
>      uint64_t             tdt_msr;
> +    uint32_t             x2apic_id;
> +    uint32_t             rsvd_zero;
>  };

I can't spot any checking of this last field indeed being zero.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Mar 25 16:55:24 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 16:55:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697827.1088984 (Exim 4.92)
	(envelope-from )
	id 1ronbU-0006nI-SM; Mon, 25 Mar 2024 16:55:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697827.1088984; Mon, 25 Mar 2024 16:55:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1ronbU-0006nB-Ph; Mon, 25 Mar 2024 16:55:20 +0000
Received: by outflank-mailman (input) for mailman id 697827;
 Mon, 25 Mar 2024 16:55:19 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1ronbT-0006n3-Jd
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 16:55:19 +0000
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com
 [2a00:1450:4864:20::130])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 75cecf45-eac8-11ee-afe3-a90da7624cb6;
 Mon, 25 Mar 2024 17:55:18 +0100 (CET)
Received: by mail-lf1-x130.google.com with SMTP id
 2adb3069b0e04-51588f70d2dso5335693e87.3
 for ; Mon, 25 Mar 2024 09:55:18 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 bo11-20020a170906d04b00b00a46d049ff63sm3189474ejb.21.2024.03.25.09.55.17
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 25 Mar 2024 09:55:17 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 75cecf45-eac8-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711385718; x=1711990518; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=6fBFRiMyDcDyxWVMQ7fN5I7w3R3dLwQwYPuiPeHhxtc=;
        b=Gru5fFcPoRqAcr95n1CMmGx0xgOugeCa2okBmAVYV+atj7qmRbHlYIUyqNPjsS+ZRg
         efr3/DDbvjAdaKOLti9uoHGm14BLjzG3edzt05HY099cKK2kL2uQ2ttkniN0uoXJABBz
         i803QY8OBISghvERJDfe7lj0lY6ZlP/MEEYcOWAEl26o9QDoA/KG1VwJTrWPuM9AeQku
         pCS2v6DGU6JyO5N8y3HW0f0T2umvn6CVfHLzHoSJ2l/tdoD9Y2czTlPseb9sP4UQUYPg
         ThX4Pg9o4LAYYkUg/zYFqAy4KHqzY3pacQ6MxBoT5vQPWI+5y5AysbEpNxAj4kj/2X3N
         up2g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711385718; x=1711990518;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=6fBFRiMyDcDyxWVMQ7fN5I7w3R3dLwQwYPuiPeHhxtc=;
        b=vA9ndwbQUwvgpUj97BvFAQToQsVC/VPG7FY4AMUWLMBY83muVHV1hqPH5vNOh2xXP/
         tIKLT+Q2oCvmuk2iPZ1JcoKadRfzXaGnx+/Vz0w/ziQcqPYrtZ3htHGj3iyIzg+4D4PS
         47reyy09jLZXOHiPRF7KVw/0fPvkp287b51avq+f0bwkeUN89k9vpweZ/ias99tzcJzS
         ceSYIoD62s4/MjzLWUGpBGq8ukocZbNKXdirq68FyW08llKVyeQoWbi0aVDJ/CmIkO4d
         u2j3KyLzd/2vlZ450uZI7I6kwCmDQOMdNoHevpN0+HVJGCO0pB223RAM+AcSHpipUzVt
         tb1w==
X-Forwarded-Encrypted: i=1; AJvYcCVWg9J6mvdzw4Mt1IzmwpSNw6654yx1aiT0dlpKCnIpY/Dn/js1jf4P5jcGQ/QXViLzahvQ3mEd8cJn8USD7LP/xvTw/a/DyxDaJNJVkRw=
X-Gm-Message-State: AOJu0Yy9TMBB1agPAe2ZGbXFYISJ8nod26kq7RDyR/rkjZDqvfODw/UF
	Cfdny1ITlLh4APN4GCEbft4Hb0TL3KLZ2cYKCISzRKQfIOWrdTGJSFzIvLf97Q==
X-Google-Smtp-Source: AGHT+IFw6DaAcwXsBtWswqCQz2XCHoxAp2EtodMnuAYkm5lCg2O99nav4OWnxoAfncBd+1TDa3+NAA==
X-Received: by 2002:a05:6512:3511:b0:515:9eaf:5c21 with SMTP id h17-20020a056512351100b005159eaf5c21mr4144862lfs.36.1711385718141;
        Mon, 25 Mar 2024 09:55:18 -0700 (PDT)
Message-ID: <321321da-ec46-46d4-98ad-bda192bbdf7e@suse.com>
Date: Mon, 25 Mar 2024 17:55:17 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 3/6] xen/x86: Refactor xen/lib/x86 so it can be linked in
 hvmloader
Content-Language: en-US
To: Alejandro Vallejo 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Xen-devel 
References: <20240109153834.4192-1-alejandro.vallejo@cloud.com>
 <20240109153834.4192-4-alejandro.vallejo@cloud.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240109153834.4192-4-alejandro.vallejo@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 09.01.2024 16:38, Alejandro Vallejo wrote:
> A future patch will use these in hvmloader, which is freestanding, but
> lacks the Xen code. The following changes fix the compilation errors.
> 
> * string.h => Remove memset() usages and bzero through assignments

But hvmloader does have memset(). It's just that it doesn't have string.h.
Yet it doesn't have e.g. stdint.h either.

> * inttypes.h => Use stdint.h (it's what it should've been to begin with)
> * errno.h => Use xen/errno.h instead
> 
> No functional change intended.
> 
> Signed-off-by: Alejandro Vallejo 
> ---
>  xen/lib/x86/cpuid.c   | 12 ++++++------
>  xen/lib/x86/private.h |  8 +++++---
>  2 files changed, 11 insertions(+), 9 deletions(-)
> 
> diff --git a/xen/lib/x86/cpuid.c b/xen/lib/x86/cpuid.c
> index eb7698dc73..4a138c3a11 100644
> --- a/xen/lib/x86/cpuid.c
> +++ b/xen/lib/x86/cpuid.c
> @@ -5,8 +5,8 @@
>  static void zero_leaves(struct cpuid_leaf *l,
>                          unsigned int first, unsigned int last)
>  {
> -    if ( first <= last )
> -        memset(&l[first], 0, sizeof(*l) * (last - first + 1));
> +    for (l = &l[first]; first <= last; first++, l++ )
> +        *l = (struct cpuid_leaf){};
>  }

Even if memset() was to be replaced here, we already have two instances
of an EMPTY_LEAF #define. Those will want moving to a single header and
hen using here, I expect. Presumably code further down could then use it,
too.

> --- a/xen/lib/x86/private.h
> +++ b/xen/lib/x86/private.h
> @@ -17,12 +17,14 @@
>  
>  #else
>  
> -#include 
> -#include 
> +#include 
>  #include 
>  #include 
> -#include 
>  
> +enum {
> +#define XEN_ERRNO(ident, rc) ident = (rc),
> +#include 
> +};
>  #include 
>  #include 

As to the comment at the top - we're in a block of code conditional upon
!Xen here already. Would there be anything wrong with simply recognizing
hvmloader here, too, and then including its util.h in place of string.h?

Jan


From xen-devel-bounces@lists.xenproject.org Mon Mar 25 16:56:10 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 16:56:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697829.1088994 (Exim 4.92)
	(envelope-from )
	id 1roncH-0007HQ-3j; Mon, 25 Mar 2024 16:56:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697829.1088994; Mon, 25 Mar 2024 16:56:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1roncH-0007HJ-10; Mon, 25 Mar 2024 16:56:09 +0000
Received: by outflank-mailman (input) for mailman id 697829;
 Mon, 25 Mar 2024 16:56:07 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1roncF-0007GT-1e
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 16:56:07 +0000
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com
 [2a00:1450:4864:20::633])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 90ad90b5-eac8-11ee-a1ef-f123f15fe8a2;
 Mon, 25 Mar 2024 17:56:03 +0100 (CET)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-a46cd9e7fcaso542863666b.1
 for ; Mon, 25 Mar 2024 09:56:03 -0700 (PDT)
Received: from [10.80.5.21] (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 pv25-20020a170907209900b00a4c9b39b726sm540564ejb.75.2024.03.25.09.56.02
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 25 Mar 2024 09:56:02 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 90ad90b5-eac8-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1711385763; x=1711990563; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=kwxPnU4HzF7M9AD7HGhaRm5AkIZQQ7rGSy5JODKNiCE=;
        b=e39cgXT+xBcw8pHM2KVKB6aqZC94UQh7Fk/r7FKtf9fsfur/L0FdyLOmKEeDiyCP0I
         1VizR8nYwxjQs5nKDgyRqdQ8cRcFNp87cXZeVQqPcVfsfgqB3yopAhp81df3QxnM4QVC
         hxaFkWSv0X4fJWNjSk91jtNtiMJoxAOj1Wnus=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711385763; x=1711990563;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=kwxPnU4HzF7M9AD7HGhaRm5AkIZQQ7rGSy5JODKNiCE=;
        b=FI5PuBx3nX9zw/zQYjfKBJfiP6Qosq9Or/sW/IrkRsgNEMvUx80focpo9EGsuhQ4Xc
         kcJxDNMcMrROZgylQoBYAfbRbjWV9TZcLZkVoS9JAru3YNF//zmCnB0VLfWPr4qMtKge
         6KPGIuGsR/1x+vA0B9zGy34E01wHywzcJJDSAd/Wt44lSQy/I7ToglO+uE0RzE8DFrfS
         bkdE9igDw/fagN9zDcTr4MAoWjgrWd0Chz1xtaYLD+VWL0DBiwJtmYqxe7Otv1hlSi5F
         LH5T4lFVzlB6aUTr74Rt02Zwv8k1DdIfuoCt6R7ofpNBR74P5V50QgM9SV6UkLdDzqH+
         cFlA==
X-Gm-Message-State: AOJu0YwvP1VGJKpwtxtuUSOLnocufirpNh1t2pRGJvCqWvTMMSdmbOVA
	ulCBZgXKIGuPWHWwpxBghnZzEalf4SgSs2GM69O+KLTpoEzcP0hLUgU6GD1OfTQ=
X-Google-Smtp-Source: AGHT+IFuKLuHQt+vTbh6/uffj+vEe1zArYGCGNptmyiME88KD++zZYFnq3KETyGXEuzQhl9DAl7Flw==
X-Received: by 2002:a17:906:5288:b0:a46:13d5:46fe with SMTP id c8-20020a170906528800b00a4613d546femr5305304ejm.11.1711385763106;
        Mon, 25 Mar 2024 09:56:03 -0700 (PDT)
Message-ID: <2cd55a39-9f02-411b-ac85-59ab5ccb5df3@cloud.com>
Date: Mon, 25 Mar 2024 16:56:01 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/6] xen/x86: Add initial x2APIC ID to the per-vLAPIC save
 area
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: Xen-devel ,
 Jan Beulich , Andrew Cooper ,
 Wei Liu 
References: <20240109153834.4192-1-alejandro.vallejo@cloud.com>
 <20240109153834.4192-2-alejandro.vallejo@cloud.com>
  
Content-Language: en-GB
From: Alejandro Vallejo 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 20/03/2024 09:33, Roger Pau Monné wrote:
>>
>> Why not just return the x2apic_id field from the cpu_policy object?
>> (topo.subleaf[X].x2apic_id)
> 
> Scratch that, the cpu policy is per-domain, not per-vcpu, and hence
> cannot hold the x{,2}apic IDs.
Yes, that :)

Originally I tried to make the policy per-vCPU, tbf, but that's a very,
very deep and complicated hole that was very hard to deal with and I'm
not tempted to try that again.

>>> diff --git a/xen/include/public/arch-x86/hvm/save.h b/xen/include/public/arch-x86/hvm/save.h
>>> index 7ecacadde1..1c2ec669ff 100644
>>> --- a/xen/include/public/arch-x86/hvm/save.h
>>> +++ b/xen/include/public/arch-x86/hvm/save.h
>>> @@ -394,6 +394,8 @@ struct hvm_hw_lapic {
>>>      uint32_t             disabled; /* VLAPIC_xx_DISABLED */
>>>      uint32_t             timer_divisor;
>>>      uint64_t             tdt_msr;
>>> +    uint32_t             x2apic_id;
>>> +    uint32_t             rsvd_zero;
>>
>> Do we really to add a new field, couldn't we get the lapic IDs from
>> the cpu_policy?
> 
> Since getting from the cpu_policy is not possible, what about getting
> it from the registers itself?  It's already present in hvm_hw_lapic_regs.
> 
> Regards, Roger.

If every APIC is in x2APIC mode, yes. But if any of them is in xAPIC
mode there's problems. The xAPIC ID is overridable by the guest simply
by writing into it, so it's tricky to know whether it's sane or not.
This new field is effectively an immutable "initial APIC ID", which we
can recreate to the old convention when not present in the stream.

If you can think of an alternative that doesn't involve adding a field
or fixing in stone the mapping strategy I'm happy to do that instead,
but I think this is the lesser evil.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Mon Mar 25 17:00:43 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 17:00:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697833.1089004 (Exim 4.92)
	(envelope-from )
	id 1rongc-0000xB-Jw; Mon, 25 Mar 2024 17:00:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697833.1089004; Mon, 25 Mar 2024 17:00:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rongc-0000x4-HC; Mon, 25 Mar 2024 17:00:38 +0000
Received: by outflank-mailman (input) for mailman id 697833;
 Mon, 25 Mar 2024 17:00:38 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rongc-0000wy-6h
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 17:00:38 +0000
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com
 [2a00:1450:4864:20::52e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 32f76368-eac9-11ee-a1ef-f123f15fe8a2;
 Mon, 25 Mar 2024 18:00:36 +0100 (CET)
Received: by mail-ed1-x52e.google.com with SMTP id
 4fb4d7f45d1cf-5688eaf1165so6365959a12.1
 for ; Mon, 25 Mar 2024 10:00:36 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 hy8-20020a1709068a6800b00a46c0191306sm3226380ejc.213.2024.03.25.10.00.34
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 25 Mar 2024 10:00:35 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 32f76368-eac9-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711386035; x=1711990835; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=tdS/vHacyGMqo6yaRa2yn9iACJgpMf0sS5JEcmk3Yu0=;
        b=RGNxSwdT23to1dpCg1gD9PK6HscCe1VpgN89hQZLJSTLRYkYm7XGI4Pa7WQT7Jhm3n
         oS19Ve9QEoAvnSFvYXZlLMFOU/00HImFF+3Qvhrqa87HNmEXTkEWLa0BOiCqcxVNT4zx
         T5kgGedqCikfeDFEeivCHNKn49MxxRrIu38BLBe09eVx/voXFcB48VaAJLyIHY27vINp
         /aO/Q26lqORcGHgq1L+w1yehUk7Azl+jw/j5IOjrqIEdKNBxoYPC3LOTef5X+R/QwqFl
         rZRCAlXa5sOmUPL8BFHvG1skJr4iQrVw88Y6Y6igXv5iMJ8LD5o9BvRFltw7Ey9xxtdf
         vkbA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711386035; x=1711990835;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=tdS/vHacyGMqo6yaRa2yn9iACJgpMf0sS5JEcmk3Yu0=;
        b=TnLTv6KZnlgt5ASpgyQFGmNbKckBoAEHHBUdgrOk4BMCMsq3u0rTWxi92jReoKOT4s
         4pGIj1uCcGcMfV3nrSe23hyD8NNtVB6NtFMIM2OTgfkfzVuDOU6q0PFz5qn8mrrt3eXf
         dq1Zg3igksUpmjl/0VWe1Fr27IsKCKWsoYdPgbxx1fWZ1JHqPxmU5e57rQOR464W6qO1
         HjqDvlpKKkL9A4xDryRf3A2+IjIdXgvdGKzsobnB09TkvZ9M2ZrCdaEVJTKxUjKLZYMo
         AhKX78O3JrYiwPq7v6Jog5HWLYQGnCMLzZNJ/7YLTjAfWd37rkDvcl4GI62inq8HLwo9
         /tJQ==
X-Gm-Message-State: AOJu0YxMGQa172MWSLSm0YSwCeSmyAj0FWB7tYk+ldMscwYTDWdv4Hne
	gFK8DipskCfwIftUDH6biE3O5uzMI9l6U5bfTCT+4ZK4voclXTbwQ3DK4kmO6g==
X-Google-Smtp-Source: AGHT+IGLAfWfaFDF1Hf7Bv+fxfbLBUM3uVi9er67ZMdgc+hJeEQB0d8tgarWsGhDDskghcq1tRwkhQ==
X-Received: by 2002:a17:906:f592:b0:a4a:3d08:bd7b with SMTP id cm18-20020a170906f59200b00a4a3d08bd7bmr2030873ejd.26.1711386035494;
        Mon, 25 Mar 2024 10:00:35 -0700 (PDT)
Message-ID: <84561e33-625a-4858-b34f-ee41eadd66a4@suse.com>
Date: Mon, 25 Mar 2024 18:00:34 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 4/6] tools/hvmloader: Use cpu_policy to determine APIC IDs
Content-Language: en-US
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Alejandro Vallejo 
Cc: Xen-devel ,
 Andrew Cooper , Wei Liu ,
 Anthony PERARD , Juergen Gross 
References: <20240109153834.4192-1-alejandro.vallejo@cloud.com>
 <20240109153834.4192-5-alejandro.vallejo@cloud.com>
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 20.03.2024 09:52, Roger Pau Monné wrote:
> On Tue, Jan 09, 2024 at 03:38:32PM +0000, Alejandro Vallejo wrote:
>> As part of topology correction efforts, APIC IDs can no longer be derived
>> strictly through the vCPU ID alone. Bring in the machinery for policy
>> retrieval and parsing in order to generate the proper MADT table and wake
>> the appropriate CPUs.
> 
> I'm kind of unsure about this last part of the sentence, as I see no
> waking of CPUs in hvmloader.  Is this referring to something else?
> 
> I'm kind of unsure about bringing the cpu_policy machinery to
> hvmloader.

I share this concern and ...

>  Won't it be simpler to just pass the array of APIC IDs in
> hvm_info_table?  The current size of this struct is 48bytes, and an
> array of 128 32bit integers would be an additional 512bytes.
> 
> AFAICT there's plenty of room in hvm_info_table, it's
> positioned at 0x9f800, and there's unused space up to 0x9fc00, so 1024
> bytes of memory we could use.
> 
> I know this doesn't give us much room for expansion if we want to bump
> past 128 vCPUs, but a more appropriate solution IMO would be to move
> ACPI table creation to the toolstack.
> 
> It's possible I'm missing some aspects, so if this has been considered
> and rejected would be good to note in the commit message.

... it being at least clarified whether alternatives were considered
and why they cannot / should not be used.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Mar 25 17:02:49 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 17:02:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697837.1089013 (Exim 4.92)
	(envelope-from )
	id 1ronih-0001Uv-Ul; Mon, 25 Mar 2024 17:02:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697837.1089013; Mon, 25 Mar 2024 17:02:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1ronih-0001Uo-SC; Mon, 25 Mar 2024 17:02:47 +0000
Received: by outflank-mailman (input) for mailman id 697837;
 Mon, 25 Mar 2024 17:02:47 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1ronig-0001Ub-Uc
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 17:02:46 +0000
Received: from mail-yw1-x1134.google.com (mail-yw1-x1134.google.com
 [2607:f8b0:4864:20::1134])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8031caff-eac9-11ee-afe3-a90da7624cb6;
 Mon, 25 Mar 2024 18:02:46 +0100 (CET)
Received: by mail-yw1-x1134.google.com with SMTP id
 00721157ae682-607c5679842so45062557b3.2
 for ; Mon, 25 Mar 2024 10:02:46 -0700 (PDT)
Received: from perard.uk.xensource.com (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 o201-20020a0dccd2000000b00611861f0586sm419130ywd.95.2024.03.25.10.02.43
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 25 Mar 2024 10:02:44 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8031caff-eac9-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1711386165; x=1711990965; darn=lists.xenproject.org;
        h=content-disposition:mime-version:message-id:subject:cc:to:from:date
         :from:to:cc:subject:date:message-id:reply-to;
        bh=wNR/Hc+JgRsug0tncVmwC7D8BSBAH0d9T637K6uSBEQ=;
        b=Z1AvWRFRUeEYUhxZY8ZeHAX+QWe96TUFwq9dTGRBL3N6TzuUSSL06prReSMsJ8Okhn
         cvBKRv0CBobO0c6zqFuVmyZwbpoDTTFnCIQgg6iTC5GToy+lKefbwaGXIkZgGpuNzozW
         kUS3krr+9jR8JOPau3grbw4aaM7J5wmi2HYZY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711386165; x=1711990965;
        h=content-disposition:mime-version:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=wNR/Hc+JgRsug0tncVmwC7D8BSBAH0d9T637K6uSBEQ=;
        b=q+vnVL1ZjjpQ2DmkDlip3PrPlqiIaib/de8U0xmu86aeQDk61Y3SPTPeBhizjMLbC6
         0OSL3nZ+6XX17v36VBgvasTsWYYYTMN7Hs9H4Pc7L5p3jICdKMNYSZdD1c2QiUj+LKGH
         k9o9oupLrNaHCqEf+ovL3ZNE5ZrM0V7LiOLsGOUT2f8ZZz4lb43rNXAhhcH21SmLLgnm
         UDWPwYkqfpY/tjfARqqAxqLpmb8F5aeGR4Br94sq1IZXBEKvp9jW8Wi+HzFzABuZioIK
         3fU2vJeK3/umRzysJ+t3M5NUbc58dD+8lpdLj2rowpCNSJL7d/fUqzWgUOiDj+MyVJFJ
         pwsA==
X-Gm-Message-State: AOJu0YyFHndGYXH9cyIESOcHm408gu7KCAAJcA4K/tBLjEoAkQzcfvhS
	XgU3UIyldqMlzXdx9Ep8B3CnTVvEOQtUfAoppS5otTP1JLQrI/8v9KCnexcw3Ym5M8OROTaPLSx
	N
X-Google-Smtp-Source: AGHT+IFz3j2ciSbigLI2qC9ilOaSd2251zUd4QfGpo9+gT8KeG49c6vi9glXytff3zEhlmZKsOkCeA==
X-Received: by 2002:a81:83d3:0:b0:609:fec8:7789 with SMTP id t202-20020a8183d3000000b00609fec87789mr6372576ywf.20.1711386164787;
        Mon, 25 Mar 2024 10:02:44 -0700 (PDT)
Date: Mon, 25 Mar 2024 17:02:42 +0000
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: Jan Beulich 
Subject: Backport request for 4.17
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hi,

Would it be possible to backport 18a36b4a9b08 ("tools: ipxe: update for
fixing build with GCC12") to Xen 4.17 ?

This would be to allow building Xen 4.17 on Debian Bookworm, and to allow
osstest to test Xen 4.18 with Debian Bookworm. osstest always tries to
migration from N-1 to N, so it would need to be able to build both 4.17
and 4.18 to actually test 4.18. Otherwise, I can tell osstest to keep
using Debian Buster to test 4.18.

For context:
    https://lore.kernel.org/xen-devel/20240318165545.3898-36-anthony.perard@citrix.com/

That commit pulls a newer version of IPXE, I don't think there's be
compatibility issue with Xen, and hopefully nothing breaks.

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Mon Mar 25 18:01:11 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 18:01:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697848.1089024 (Exim 4.92)
	(envelope-from )
	id 1rood2-0002LD-3O; Mon, 25 Mar 2024 18:01:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697848.1089024; Mon, 25 Mar 2024 18:01:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rood2-0002L6-0O; Mon, 25 Mar 2024 18:01:00 +0000
Received: by outflank-mailman (input) for mailman id 697848;
 Mon, 25 Mar 2024 18:00:58 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rood0-0002L0-CU
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 18:00:58 +0000
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com
 [2a00:1450:4864:20::530])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a1682e65-ead1-11ee-afe3-a90da7624cb6;
 Mon, 25 Mar 2024 19:00:57 +0100 (CET)
Received: by mail-ed1-x530.google.com with SMTP id
 4fb4d7f45d1cf-56a2bb1d84eso8259612a12.1
 for ; Mon, 25 Mar 2024 11:00:57 -0700 (PDT)
Received: from [10.80.5.21] (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 a9-20020a50ff09000000b0056c0a3d91easm1795741edu.12.2024.03.25.11.00.56
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 25 Mar 2024 11:00:56 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a1682e65-ead1-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1711389657; x=1711994457; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=aP0ZpNKtKlAkByp1dzhjCpHP/UfIO209SVVumQjZthQ=;
        b=PDZseObbhfOaQ9ecSa9s9ipwc5hnkVyii76jOpi0pF6naWtcwq2cvfSTXaV/z72RJ3
         8OiPY/2xT9jMqbY1yJuy/uzb2jE79t/lUusKXLI+wI0XEGuNZ9vsN8ddcXl7gcW0NsFS
         /WTwddxbPn6XPT+Fh3Ys8B7zcSIhwgvE/Xtrw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711389657; x=1711994457;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=aP0ZpNKtKlAkByp1dzhjCpHP/UfIO209SVVumQjZthQ=;
        b=kiRhBwLYLwKjHz0XMp30JwlZI0uZi4c1efNr0iEQMV/G4/FZV2JlnboOOHSlVt4D60
         GmR4KrO73VQHkWKLME+Z12PFYTSIIteYzGfp7FiinYFQffjUuyxlt7NguobJkU6jnQSj
         qotB0M6icE526KIo9aDdet5RL/OVqi/UiCTJ5M7Xf4Vc+qu0g4SDvJzow8fh44kB+VqD
         L7mMoua5ljczQfLP2Fte+7ijxmnfgsyjohUSb6Lip+RCgIj2fZkm9814Yx+6h01YRHiE
         gSFyUfVV11U/35YiGu/AzFZjsOJBRPutfPjudfWg3/x15ZKodNIXlr/k3v2dha3brJCr
         Mfvw==
X-Forwarded-Encrypted: i=1; AJvYcCVpzqMSjJufnDXbaRwEbQsm6Psxpnm6Ut7Duptva5O9V8ux37ETydlyPsauJdVMl5ZuPsbBADDvNeogXEm8vebnZX1PlSBR/HkptWFrUCY=
X-Gm-Message-State: AOJu0YwgiVhNggi3d8NduKZ9gGDtGLNz8WTRTq9iEunVd3y9LQHAdMt9
	L3p4m+/2lQw9rVKQxu7yiVrqQgAAiqcS9AcUzzKpXKVuNQS9mJnzc1LPvb1R2YQ=
X-Google-Smtp-Source: AGHT+IFphpmizD55FcDLpcGO4ioU0kmMwR79jG7qC40hdh2nP2zAPy0EmgJoZMRju3EVE5gg79RZtQ==
X-Received: by 2002:a50:9fcf:0:b0:566:72b0:286a with SMTP id c73-20020a509fcf000000b0056672b0286amr7147639edf.2.1711389656756;
        Mon, 25 Mar 2024 11:00:56 -0700 (PDT)
Message-ID: <19a4cf14-92c9-47e5-b8f0-f07a92a1ffd8@cloud.com>
Date: Mon, 25 Mar 2024 18:00:55 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/6] xen/x86: Add initial x2APIC ID to the per-vLAPIC save
 area
To: Jan Beulich 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Xen-devel 
References: <20240109153834.4192-1-alejandro.vallejo@cloud.com>
 <20240109153834.4192-2-alejandro.vallejo@cloud.com>
 <2e7fe91e-b483-4d61-9783-0cfa3753911f@suse.com>
Content-Language: en-GB
From: Alejandro Vallejo 
In-Reply-To: <2e7fe91e-b483-4d61-9783-0cfa3753911f@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Hi,

On 25/03/2024 16:45, Jan Beulich wrote:
> On 09.01.2024 16:38, Alejandro Vallejo wrote:
>> --- a/xen/arch/x86/domain.c
>> +++ b/xen/arch/x86/domain.c
>> @@ -288,7 +288,10 @@ void update_guest_memory_policy(struct vcpu *v,
>>  static void cpu_policy_updated(struct vcpu *v)
>>  {
>>      if ( is_hvm_vcpu(v) )
>> +    {
>>          hvm_cpuid_policy_changed(v);
>> +        vlapic_cpu_policy_changed(v);
>> +    }
>>  }
> 
> This is a layering violation imo; hvm_cpuid_policy_changed() wants
> to call vlapic_cpu_policy_changed().

Sure.

> 
>> @@ -1083,6 +1083,22 @@ static void set_x2apic_id(struct vlapic *vlapic)
>>      vlapic_set_reg(vlapic, APIC_LDR, apic_ldr);
>>  }
>>  
>> +void vlapic_cpu_policy_changed(struct vcpu *v)
>> +{
>> +    struct vlapic *vlapic = vcpu_vlapic(v);
>> +    struct cpu_policy *cp = v->domain->arch.cpu_policy;
> 
> const please

Ack

> 
>> @@ -1514,6 +1530,13 @@ static void lapic_load_fixup(struct vlapic *vlapic)
>>      const struct vcpu *v = vlapic_vcpu(vlapic);
>>      uint32_t good_ldr = x2apic_ldr_from_id(vlapic->loaded.id);
>>  
>> +    /*
>> +     * Guest with hardcoded assumptions about x2apic_id <-> vcpu_id
>> +     * mappings. Recreate the mapping it used to have in old host.
>> +     */
>> +    if ( !vlapic->hw.x2apic_id )
>> +        vlapic->hw.x2apic_id = v->vcpu_id * 2;
> 
> This looks to depend upon it only ever being vCPU which may get a (new
> style) APIC ID of 0. I think such at least wants mentioning in the
> comment.

I don't quite follow you, I'm afraid. There is an implicit control flow
assumption that I can extract into a comment (I assume you were going
for that angle?). The implicit assumption that "vCPU0 always has
APIC_ID=0", which makes vCPU0 go through that path even when no
corrections are necessary. It's benign because it resolves to APIC_ID 0.

Is that what you meant? If so, I'll add it to v2.

> 
>> --- a/xen/include/public/arch-x86/hvm/save.h
>> +++ b/xen/include/public/arch-x86/hvm/save.h
>> @@ -394,6 +394,8 @@ struct hvm_hw_lapic {
>>      uint32_t             disabled; /* VLAPIC_xx_DISABLED */
>>      uint32_t             timer_divisor;
>>      uint64_t             tdt_msr;
>> +    uint32_t             x2apic_id;
>> +    uint32_t             rsvd_zero;
>>  };
> 
> I can't spot any checking of this last field indeed being zero.
> 
> Jan

Huh. I was sure I zeroed that on vlapic_init(), but it must've been on a
previous discarded series. Good catch.

Do we also want a check on migrate so a migration from a future Xen in
which it's not zero fails?

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Mon Mar 25 18:18:44 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 18:18:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697854.1089034 (Exim 4.92)
	(envelope-from )
	id 1roou5-0004R2-JE; Mon, 25 Mar 2024 18:18:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697854.1089034; Mon, 25 Mar 2024 18:18:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1roou5-0004Qv-GR; Mon, 25 Mar 2024 18:18:37 +0000
Received: by outflank-mailman (input) for mailman id 697854;
 Mon, 25 Mar 2024 18:18:35 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1roou3-0004Nr-QK
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 18:18:35 +0000
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com
 [2a00:1450:4864:20::529])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 171c0e48-ead4-11ee-a1ef-f123f15fe8a2;
 Mon, 25 Mar 2024 19:18:33 +0100 (CET)
Received: by mail-ed1-x529.google.com with SMTP id
 4fb4d7f45d1cf-5684db9147dso5418197a12.2
 for ; Mon, 25 Mar 2024 11:18:33 -0700 (PDT)
Received: from andrewcoop.citrite.net (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 c36-20020a509fa7000000b0056bdec673c3sm3353969edf.38.2024.03.25.11.18.31
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 25 Mar 2024 11:18:31 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 171c0e48-ead4-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1711390712; x=1711995512; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:from:to:cc:subject:date:message-id:reply-to;
        bh=mCQaZ2vEVw3LDT3hBoi3CjYKe2i19cOeP080dPUKgzQ=;
        b=TmTvo0/jXZvjuJP5Et2/3vaZHUqa5r6wNcZsgAOCA+j6ijWfkVzsk4W4VnzvLeOBgH
         CWahUA+aYhnnIhVuextDZHgbxjJwx57/tZETz8cjT2MRFddRmS8zE0I1eK89cOA1BhNg
         oHUxL64Tsd8ojCDL7HoBrUkmVLA3CKeYWbZJs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711390712; x=1711995512;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=mCQaZ2vEVw3LDT3hBoi3CjYKe2i19cOeP080dPUKgzQ=;
        b=O2GvZ87a9ujObbQFRAsez2nKQUxvowVcrF5l+PnNkhNz0wvEcmRQHPMG4pa9qm5hSx
         sACahciacoINLy8MSGLbDMDygJ2Hte1XTRVA4TzUXUWkI2f5v5r1V67NZAt7AIhCar+x
         Ho1HoenGzRolYgTudPZfEabd7WItBKLzxFlAnm3Jiq/sQGldZ4K6DMKkbYHor3OTT0BE
         txCYMKnoP+zWgvzS3ffrjHEUf39nCIrVsKq6+Yti0kglETskDjvlHR4PCPR3HzpQkxTh
         TT3XpCBq1ag7htX1kaWCEMPnGOvmnQknk5k+ZxiTuiWvHwUQHo+qZYkZ/Zr7HZIUiPXr
         Dx8g==
X-Gm-Message-State: AOJu0YwYGap/leAn8v4ILfzy05ATkRby8nVBQcYhcNry7jbN0vVdEgpx
	PmUzIXxsrKxR2tH/etAy5jw1/9Xg9SmlTIbFE/PrLnA+E7CIXf/9vGEW6jwVChPo/HPSLlNHQ3b
	w
X-Google-Smtp-Source: AGHT+IG1rKPZ+DgNqS+fD/u8DIaVGb/O+3r9gcOk0odwEJqwnrNMVbAB1vJ+dlwm+FAkBQhflMOw+A==
X-Received: by 2002:a50:8e5d:0:b0:56b:a155:4b39 with SMTP id 29-20020a508e5d000000b0056ba1554b39mr5202593edx.28.1711390712366;
        Mon, 25 Mar 2024 11:18:32 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH] x86/spec-ctrl: Support for SRSO_US_NO and SRSO_MSR_FIX
Date: Mon, 25 Mar 2024 18:18:30 +0000
Message-Id: <20240325181830.638680-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.30.2
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

AMD have updated the SRSO whitepaper[1] with further information.

There's a new SRSO_U/S_NO enumeration saying that SRSO attacks can't cross the
user/supervisor boundary.  i.e. we don't need to use IBPB-on-entry for PV.

There's also a new SRSO_MSR_FIX identifying that the BP_SPEC_REDUCE bit is
available in MSR_BP_CFG.  When set, SRSO attacks can't cross the host/guest
boundary.  i.e. we don't need to use IBPB-on-entry for HVM.

Extend ibpb_calculations() to account for these when calculating
opt_ibpb_entry_{pv,hvm} defaults.  Add a bp-spec-reduce option to control the
use of BP_SPEC_REDUCE, but activate it by default.

Because MSR_BP_CFG is core-scoped with a race condition updating it, repurpose
amd_check_erratum_1485() into amd_check_bp_cfg() and calculate all updates at
once.

Fix a typo in the SRSO_NO's comment.

[1] https://www.amd.com/content/dam/amd/en/documents/corporate/cr/speculative-return-stack-overflow-whitepaper.pdf
Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 

Slightly RFC.  This is all speculative coding.
---
 docs/misc/xen-command-line.pandoc           |  9 ++++-
 tools/misc/xen-cpuid.c                      |  1 +
 xen/arch/x86/cpu/amd.c                      | 27 ++++++++++----
 xen/arch/x86/include/asm/msr-index.h        |  1 +
 xen/arch/x86/include/asm/spec_ctrl.h        |  1 +
 xen/arch/x86/spec_ctrl.c                    | 39 ++++++++++++++++-----
 xen/include/public/arch-x86/cpufeatureset.h |  4 ++-
 7 files changed, 66 insertions(+), 16 deletions(-)

diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
index 14cafb462a9a..5d114514cc8f 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -2377,7 +2377,8 @@ By default SSBD will be mitigated at runtime (i.e `ssbd=runtime`).
 >              {msr-sc,rsb,verw,ibpb-entry}=|{pv,hvm}=,
 >              bti-thunk=retpoline|lfence|jmp, {ibrs,ibpb,ssbd,psfd,
 >              eager-fpu,l1d-flush,branch-harden,srb-lock,
->              unpriv-mmio,gds-mit,div-scrub,lock-harden}= ]`
+>              unpriv-mmio,gds-mit,div-scrub,lock-harden,
+>              bp-spec-reduce}= ]`
 
 Controls for speculative execution sidechannel mitigations.  By default, Xen
 will pick the most appropriate mitigations based on compiled in support,
@@ -2509,6 +2510,12 @@ boolean can be used to force or prevent Xen from using speculation barriers to
 protect lock critical regions.  This mitigation won't be engaged by default,
 and needs to be explicitly enabled on the command line.
 
+On hardware supporting SRSO_MSR_FIX, the `bp-spec-reduce=` option can be used
+to force or prevent Xen from using MSR_BP_CFG.BP_SPEC_REDUCE to mitigate the
+SRSO (Speculative Return Stack Overflow) vulnerability.  By default, Xen will
+use bp-spec-reduce when available, as it preferable to using `ibpb-entry=hvm`
+to mitigate SRSO.
+
 ### sync_console
 > `= `
 
diff --git a/tools/misc/xen-cpuid.c b/tools/misc/xen-cpuid.c
index 8893547bebce..ec24a16086c6 100644
--- a/tools/misc/xen-cpuid.c
+++ b/tools/misc/xen-cpuid.c
@@ -212,6 +212,7 @@ static const char *const str_e21a[32] =
 
     /* 26 */                [27] = "sbpb",
     [28] = "ibpb-brtype",   [29] = "srso-no",
+    [30] = "srso-us-no",    [31] = "srso-msr-fix",
 };
 
 static const char *const str_7b1[32] =
diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c
index ab92333673b9..9247a4e65734 100644
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -1009,16 +1009,31 @@ static void cf_check fam17_disable_c6(void *arg)
 	wrmsrl(MSR_AMD_CSTATE_CFG, val & mask);
 }
 
-static void amd_check_erratum_1485(void)
+static void amd_check_bp_cfg(void)
 {
-	uint64_t val, chickenbit = (1 << 5);
+	uint64_t val, new = 0;
 
-	if (cpu_has_hypervisor || boot_cpu_data.x86 != 0x19 || !is_zen4_uarch())
+	/*
+	 * AMD Erratum #1485.  Set bit 5, as instructed.
+	 */
+	if (!cpu_has_hypervisor && boot_cpu_data.x86 == 0x19 && is_zen4_uarch())
+		new |= (1 << 5);
+
+	/*
+	 * On hardware supporting SRSO_MSR_FIX, we prefer BP_SPEC_REDUCE to
+	 * IBPB-on-entry to mitigate SRSO for HVM guests.
+	 */
+	if (IS_ENABLED(CONFIG_HVM) && boot_cpu_has(X86_FEATURE_SRSO_US_NO) &&
+            opt_bp_spec_reduce)
+		new |= BP_CFG_SPEC_REDUCE;
+
+	/* Avoid reading BP_CFG if we don't intend to change anything. */
+	if (!new)
 		return;
 
 	rdmsrl(MSR_AMD64_BP_CFG, val);
 
-	if (val & chickenbit)
+	if ((val & new) == new)
 		return;
 
 	/*
@@ -1027,7 +1042,7 @@ static void amd_check_erratum_1485(void)
 	 * same time before the chickenbit is set. It's benign because the
 	 * value being written is the same on both.
 	 */
-	wrmsrl(MSR_AMD64_BP_CFG, val | chickenbit);
+	wrmsrl(MSR_AMD64_BP_CFG, val | new);
 }
 
 static void cf_check init_amd(struct cpuinfo_x86 *c)
@@ -1297,7 +1312,7 @@ static void cf_check init_amd(struct cpuinfo_x86 *c)
 		disable_c1_ramping();
 
 	amd_check_zenbleed();
-	amd_check_erratum_1485();
+	amd_check_bp_cfg();
 
 	if (fam17_c6_disabled)
 		fam17_disable_c6(NULL);
diff --git a/xen/arch/x86/include/asm/msr-index.h b/xen/arch/x86/include/asm/msr-index.h
index 92dd9fa4962c..c6b11c8c96dc 100644
--- a/xen/arch/x86/include/asm/msr-index.h
+++ b/xen/arch/x86/include/asm/msr-index.h
@@ -412,6 +412,7 @@
 #define AMD64_DE_CFG_LFENCE_SERIALISE	(_AC(1, ULL) << 1)
 #define MSR_AMD64_EX_CFG		0xc001102cU
 #define MSR_AMD64_BP_CFG		0xc001102eU
+#define  BP_CFG_SPEC_REDUCE		(_AC(1, ULL) << 4)
 #define MSR_AMD64_DE_CFG2		0xc00110e3U
 
 #define MSR_AMD64_DR0_ADDRESS_MASK	0xc0011027U
diff --git a/xen/arch/x86/include/asm/spec_ctrl.h b/xen/arch/x86/include/asm/spec_ctrl.h
index 011ab1db2709..58e47cac57db 100644
--- a/xen/arch/x86/include/asm/spec_ctrl.h
+++ b/xen/arch/x86/include/asm/spec_ctrl.h
@@ -88,6 +88,7 @@ extern int8_t opt_xpti_hwdom, opt_xpti_domu;
 
 extern bool cpu_has_bug_l1tf;
 extern int8_t opt_pv_l1tf_hwdom, opt_pv_l1tf_domu;
+extern bool opt_bp_spec_reduce;
 
 /*
  * The L1D address mask, which might be wider than reported in CPUID, and the
diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
index 0b670c3ca753..abd778e7f992 100644
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -71,6 +71,7 @@ static bool __initdata opt_unpriv_mmio;
 static bool __ro_after_init opt_verw_mmio;
 static int8_t __initdata opt_gds_mit = -1;
 static int8_t __initdata opt_div_scrub = -1;
+bool __ro_after_init opt_bp_spec_reduce = true;
 
 static int __init cf_check parse_spec_ctrl(const char *s)
 {
@@ -127,6 +128,7 @@ static int __init cf_check parse_spec_ctrl(const char *s)
             opt_unpriv_mmio = false;
             opt_gds_mit = 0;
             opt_div_scrub = 0;
+            opt_bp_spec_reduce = false;
         }
         else if ( val > 0 )
             rc = -EINVAL;
@@ -306,6 +308,8 @@ static int __init cf_check parse_spec_ctrl(const char *s)
             opt_gds_mit = val;
         else if ( (val = parse_boolean("div-scrub", s, ss)) >= 0 )
             opt_div_scrub = val;
+        else if ( (val = parse_boolean("bp-spec-reduce", s, ss)) >= 0 )
+            opt_bp_spec_reduce = val;
         else
             rc = -EINVAL;
 
@@ -1053,7 +1057,7 @@ static void __init div_calculations(bool hw_smt_enabled)
 
 static void __init ibpb_calculations(void)
 {
-    bool def_ibpb_entry = false;
+    bool def_ibpb_entry_pv = false, def_ibpb_entry_hvm = false;
 
     /* Check we have hardware IBPB support before using it... */
     if ( !boot_cpu_has(X86_FEATURE_IBRSB) && !boot_cpu_has(X86_FEATURE_IBPB) )
@@ -1078,22 +1082,41 @@ static void __init ibpb_calculations(void)
          * Confusion.  Mitigate with IBPB-on-entry.
          */
         if ( !boot_cpu_has(X86_FEATURE_BTC_NO) )
-            def_ibpb_entry = true;
+            def_ibpb_entry_pv = def_ibpb_entry_hvm = true;
 
         /*
-         * Further to BTC, Zen3/4 CPUs suffer from Speculative Return Stack
-         * Overflow in most configurations.  Mitigate with IBPB-on-entry if we
-         * have the microcode that makes this an effective option.
+         * Further to BTC, Zen3 and later CPUs suffer from Speculative Return
+         * Stack Overflow in most configurations.  Mitigate with IBPB-on-entry
+         * if we have the microcode that makes this an effective option,
+         * except where there are other mitigating factors available.
          */
         if ( !boot_cpu_has(X86_FEATURE_SRSO_NO) &&
              boot_cpu_has(X86_FEATURE_IBPB_BRTYPE) )
-            def_ibpb_entry = true;
+        {
+            /*
+             * SRSO_U/S_NO is a subset of SRSO_NO, identifying that SRSO isn't
+             * possible across the user/supervisor boundary.  We only need to
+             * use IBPB-on-entry for PV guests on hardware which doesn't
+             * enumerate SRSO_US_NO.
+             */
+            if ( !boot_cpu_has(X86_FEATURE_SRSO_US_NO) )
+                def_ibpb_entry_pv = true;
+
+            /*
+             * SRSO_MSR_FIX enumerates that we can use MSR_BP_CFG.SPEC_REDUCE
+             * to mitigate SRSO across the host/guest boundary.  We only need
+             * to use IBPB-on-entry for HVM guests if we haven't enabled this
+             * control.
+             */
+            if ( !boot_cpu_has(X86_FEATURE_SRSO_MSR_FIX) || !opt_bp_spec_reduce )
+                def_ibpb_entry_hvm = true;
+        }
     }
 
     if ( opt_ibpb_entry_pv == -1 )
-        opt_ibpb_entry_pv = IS_ENABLED(CONFIG_PV) && def_ibpb_entry;
+        opt_ibpb_entry_pv = IS_ENABLED(CONFIG_PV) && def_ibpb_entry_pv;
     if ( opt_ibpb_entry_hvm == -1 )
-        opt_ibpb_entry_hvm = IS_ENABLED(CONFIG_HVM) && def_ibpb_entry;
+        opt_ibpb_entry_hvm = IS_ENABLED(CONFIG_HVM) && def_ibpb_entry_hvm;
 
     if ( opt_ibpb_entry_pv )
     {
diff --git a/xen/include/public/arch-x86/cpufeatureset.h b/xen/include/public/arch-x86/cpufeatureset.h
index 3de7c0383f0e..815fedc1a93e 100644
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++ b/xen/include/public/arch-x86/cpufeatureset.h
@@ -304,7 +304,9 @@ XEN_CPUFEATURE(FSRSC,              11*32+19) /*A  Fast Short REP SCASB */
 XEN_CPUFEATURE(AMD_PREFETCHI,      11*32+20) /*A  PREFETCHIT{0,1} Instructions */
 XEN_CPUFEATURE(SBPB,               11*32+27) /*A  Selective Branch Predictor Barrier */
 XEN_CPUFEATURE(IBPB_BRTYPE,        11*32+28) /*A  IBPB flushes Branch Type predictions too */
-XEN_CPUFEATURE(SRSO_NO,            11*32+29) /*A  Hardware not vulenrable to Speculative Return Stack Overflow */
+XEN_CPUFEATURE(SRSO_NO,            11*32+29) /*A  Hardware not vulnerable to Speculative Return Stack Overflow */
+XEN_CPUFEATURE(SRSO_US_NO,         11*32+30) /*A  Hardware not vulnerable to SRSO across the User/Supervisor boundary */
+XEN_CPUFEATURE(SRSO_MSR_FIX,       11*32+31) /*   MSR_BP_CFG.BP_SPEC_REDUCE available */
 
 /* Intel-defined CPU features, CPUID level 0x00000007:1.ebx, word 12 */
 XEN_CPUFEATURE(INTEL_PPIN,         12*32+ 0) /*   Protected Processor Inventory Number */

base-commit: 6f6de10ade5ade907f9e3f3c72b7b18f7852d9ff
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Mon Mar 25 18:19:33 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 18:19:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697856.1089044 (Exim 4.92)
	(envelope-from )
	id 1roouy-0004y5-RV; Mon, 25 Mar 2024 18:19:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697856.1089044; Mon, 25 Mar 2024 18:19:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1roouy-0004xy-OG; Mon, 25 Mar 2024 18:19:32 +0000
Received: by outflank-mailman (input) for mailman id 697856;
 Mon, 25 Mar 2024 18:19:31 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rooux-0004xo-8u
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 18:19:31 +0000
Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com
 [2a00:1450:4864:20::436])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 387737b7-ead4-11ee-afe3-a90da7624cb6;
 Mon, 25 Mar 2024 19:19:29 +0100 (CET)
Received: by mail-wr1-x436.google.com with SMTP id
 ffacd0b85a97d-341cf77b86dso939225f8f.2
 for ; Mon, 25 Mar 2024 11:19:29 -0700 (PDT)
Received: from [10.80.5.21] (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 bh9-20020a170906a0c900b00a461b1e814asm3296707ejb.130.2024.03.25.11.19.28
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 25 Mar 2024 11:19:28 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 387737b7-ead4-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1711390769; x=1711995569; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=ZvBsIoalMhTbP8dXubwTtIrROadED8ydufDKo1YTCFQ=;
        b=IcBLQ+1whxcEgN8ekMqPcsmXCb7ycgYeY73WW63iACta1qWpsASP1uNc84R8zndXfS
         7zxnbCglskx1tW7XLSIeYip/MOEGzblaItUTPA1AMdFSf3qlo7J2v0aPrgC6fBiU7dDu
         rfQuYau026mjeFurqFaKJ7mtH93b/uJVTc6ZU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711390769; x=1711995569;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=ZvBsIoalMhTbP8dXubwTtIrROadED8ydufDKo1YTCFQ=;
        b=vW5tKecn3qY+Xp32OMtO4G9+LpnNdr/I4nf+JPAaJJNp9tpDUVybU7XhwT51FnJqHK
         PnfqbCt3egiFu7of86unpTjdLxqH+bffvul1nPw4UY8xZ0VI1LyC+qVYViiv1IlXdWnq
         C+H0PpwMn7eJxC63P2TPBvL1GWqgMq905XqlAQ+co3bMIeeSJr8uVmuU0yHNGrbpI7ab
         mVhB1WYv3CexjdqEXnVkv8tSqM11lgUz5XdIkDQ4EHliMcrwqprBoH/m0WkyOWstNGOX
         /oxGxnD29O6lCHMHU3vBhItaBrjGmWXtVIFJ3G/JqihRWXdIzZ6XAPaynKMNN2pfxHSN
         1Lhw==
X-Gm-Message-State: AOJu0YydWHACluJds1FCC5l/Ry4427QeRmmYBo08zK38EUGmDcfgVxV/
	DxMKpMWMuYYBsKrJ2osz//Lt3Lokfq2Moo5H02Vl8e21POU0o6YZqR0rLSjYedc=
X-Google-Smtp-Source: AGHT+IHR7OS8odIdUvdlcnt1s5cCa3aiP5NwShIR40+jSNQ9BzCWjSAgnd/3qch7pwvJR9uyJhIyRQ==
X-Received: by 2002:a05:6000:4009:b0:341:cd0d:b78a with SMTP id cp9-20020a056000400900b00341cd0db78amr3925279wrb.48.1711390769180;
        Mon, 25 Mar 2024 11:19:29 -0700 (PDT)
Message-ID: <142a2b55-371a-4401-9dec-161c0cabcf07@cloud.com>
Date: Mon, 25 Mar 2024 18:19:27 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/6] tools/xc: Add xc_cpu_policy to the public xenctrl.h
 header
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: Xen-devel , Wei Liu ,
 Anthony PERARD , Juergen Gross ,
 Jan Beulich , Andrew Cooper 
References: <20240109153834.4192-1-alejandro.vallejo@cloud.com>
 <20240109153834.4192-3-alejandro.vallejo@cloud.com>
 
Content-Language: en-GB
From: Alejandro Vallejo 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 19/03/2024 17:55, Roger Pau Monné wrote:
> On Tue, Jan 09, 2024 at 03:38:30PM +0000, Alejandro Vallejo wrote:
>> Move struct xc_cpu_policy data structure out of xg_private.h and into
>> the public xenguest.h so it can be used by libxl.
> 
> I will let Andrew comment on this one, IIRC the initial idea was to
> not leak cpu_policy into libxl, and to instead have it as an opaque
> object that libxl can interact with using helpers.

I wrote this a while ago, and can't quite remember why I left this here.
Looking closely I think it's leftover from something else I eventually
turned into its own series[1]. I don't _think_ it's needed for this
series, so I'll just drop it in v2. If everything blows up I'll tell you
why I needed it :)

[1]
https://lore.kernel.org/xen-devel/20240207173957.19811-1-alejandro.vallejo@cloud.com/

> 
> I haven't looked at followup patches - I assume this is done to
> manipulate the cpuid data more easily from libxl, and ultimately drop
> xc_xend_cpuid?

Yes, we can't drop that altogether because xl exposes an interface
allowing fine-grained manipulation of CPUID/MSR data, but it becomes
minimal. The general idea is to is to stop moving separate buffers
around in tandem and use a single data structure instead whenever possible.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Mon Mar 25 19:33:55 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 19:33:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697867.1089075 (Exim 4.92)
	(envelope-from )
	id 1roq4n-000780-AN; Mon, 25 Mar 2024 19:33:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697867.1089075; Mon, 25 Mar 2024 19:33:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1roq4n-00077t-54; Mon, 25 Mar 2024 19:33:45 +0000
Received: by outflank-mailman (input) for mailman id 697867;
 Mon, 25 Mar 2024 19:33:44 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1roq4m-00077Z-44; Mon, 25 Mar 2024 19:33:44 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1roq4m-0001Cz-2Y; Mon, 25 Mar 2024 19:33:44 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1roq4l-0003Op-Mm; Mon, 25 Mar 2024 19:33:43 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1roq4l-00075q-MP; Mon, 25 Mar 2024 19:33:43 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=sT1A2PldSph5EbGyE4ZfvCPbehSJEEQ7DPLg0hBnoac=; b=UtJIau7/UC7su077rR8tqka2Z3
	os+AMTSDk20xGBfiwcsI5xhapht68zhI81BJnWZ39dqgEY80WR3EDWefBNPbq03nAUZtyF71Jp9TF
	wjUMqwncAgdLlQ3yot+pWYvsFoLvmMWWsXj2zLPTlJ7a34morfwKez9nsGkCoSqBnlM0=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 185158: tolerable FAIL - PUSHED
X-Osstest-Failures:
    xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-qcow2:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-qcow2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-vhd:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-raw:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    xen=6f6de10ade5ade907f9e3f3c72b7b18f7852d9ff
X-Osstest-Versions-That:
    xen=cbe393b709e0c6c3e2b10c3ac69fbea0abd530fe
From: osstest service owner 
Date: Mon, 25 Mar 2024 19:33:43 +0000

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen                  6f6de10ade5ade907f9e3f3c72b7b18f7852d9ff
baseline version:
 xen                  cbe393b709e0c6c3e2b10c3ac69fbea0abd530fe

Last test of basis   185154  2024-03-25 01:52:11 Z    0 days
Testing same since   185158  2024-03-25 12:37:14 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Daniel P. Smith 
  Jan Beulich 
  Julien Grall 
  Nicola Vetrini 
  Oleksii Kurochko 
  Roger Pau Monné 
  Shawn Anastasio 

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-libvirt-qcow2                               pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-xl-qcow2                                    pass    
 test-amd64-amd64-libvirt-raw                                 pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-amd64-amd64-xl-raw                                      pass    
 test-armhf-armhf-xl-raw                                      pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-libvirt-vhd                                 pass    
 test-amd64-amd64-xl-vhd                                      pass    
 test-arm64-arm64-xl-vhd                                      pass    


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

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

Explanation of these 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
   cbe393b709..6f6de10ade  6f6de10ade5ade907f9e3f3c72b7b18f7852d9ff -> master


From xen-devel-bounces@lists.xenproject.org Mon Mar 25 20:45:38 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 20:45:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697877.1089090 (Exim 4.92)
	(envelope-from )
	id 1rorCD-0007OS-TS; Mon, 25 Mar 2024 20:45:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697877.1089090; Mon, 25 Mar 2024 20:45:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rorCD-0007Nz-Mk; Mon, 25 Mar 2024 20:45:29 +0000
Received: by outflank-mailman (input) for mailman id 697877;
 Mon, 25 Mar 2024 20:45:28 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rorCC-0007L7-Lw
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 20:45:28 +0000
Received: from NAM04-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam04on20601.outbound.protection.outlook.com
 [2a01:111:f403:2409::601])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 99b24552-eae8-11ee-afe3-a90da7624cb6;
 Mon, 25 Mar 2024 21:45:26 +0100 (CET)
Received: from BL1PR13CA0185.namprd13.prod.outlook.com (2603:10b6:208:2be::10)
 by SA1PR12MB6702.namprd12.prod.outlook.com (2603:10b6:806:252::22)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.24; Mon, 25 Mar
 2024 20:45:20 +0000
Received: from BL02EPF0001A104.namprd05.prod.outlook.com
 (2603:10b6:208:2be:cafe::41) by BL1PR13CA0185.outlook.office365.com
 (2603:10b6:208:2be::10) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.12 via Frontend
 Transport; Mon, 25 Mar 2024 20:45:20 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 BL02EPF0001A104.mail.protection.outlook.com (10.167.241.135) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Mon, 25 Mar 2024 20:45:20 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Mon, 25 Mar
 2024 15:45:19 -0500
Received: from fedora.mshome.net (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Mon, 25 Mar 2024 15:45:19 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 99b24552-eae8-11ee-afe3-a90da7624cb6
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=RPQNL2DC5zxCju1KPPFw8cxGFVWlYUeb5aTIvhP2fWxK+t0bXwMvoOpsTNGvR+DrXcL7XRRDUT7qSMsV4JQta4yMLnuqrHJtgj+ob1JdZz4/bwyc0Myy6H+EntYA2YVYxXf+1FwL2U6shZlvHcQkvLoskKSK6DyEuCDdYhjlluGJL2kqqEXnwD/41isPfOT3ZTDCIUenHSkblaZEAjoFlxx2yhCagQ01ji2meI4XF2YVO8jG0R2wHJ2n1xewxn8Nfz9CoJoaiTHS7TH5x+Gq5wBslWBfN7VI0KIysRdhVlQfbpupF7vQT/QFOA4b8psJiSgY4CnbSilZCt1G0xJ97g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=lvOehq1EJKjZfWXBSzZg1ZZ1p5IUUk1AykmRfeyalZA=;
 b=hzdirreQkDkZYY+CWHIa3D0nvuZLqA00CviNj+SkLTqXcqI0kQEwoF72686F6ENpwNafW7VkCNqliwZg5nAz2iC6VX45pTy6O3mqI4HEDEc7Z9EFYx12C1qkbux3z5iwAIpgZZ+qhHwRBCTxticLwP8BsooUQWvzxnrS41OVsrIs3BjOxZQGt1U9oG+Q3pZ/V2xbQL7jR/R5uIZBDD3qGHwOQ1QJQu6qVeVQsni1SZcGEPXEvnKwyIPbjCXzSeydhMKMeYsJt/mPyktHWtw34LNO3pmnFy7OfzdX/a/aAQlyzt+vs8NR0oA2BbWPNWBthjofBnfLANtqvJrmzQPowQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=lvOehq1EJKjZfWXBSzZg1ZZ1p5IUUk1AykmRfeyalZA=;
 b=HectG3N0H33WZo8H4mwBJ2m7nABhWdL53zg7oCVmN0pe/wh+0ayK4goy1sPl6uuF5XhGjoQrijINi2vmfBAEJkc2snlrT68sET19kcLwCDMlIhKt9pkIC6To0FaNo+7hWtGhWx6KRtRtKGalng+HVsNtmB8Az3teoH1pPDGVixM=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
From: Jason Andryuk 
To: 
CC: Jason Andryuk , Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v4 1/5] Revert "xen/x86: bzImage parse kernel_alignment"
Date: Mon, 25 Mar 2024 16:45:11 -0400
Message-ID: <20240325204515.250203-2-jason.andryuk@amd.com>
X-Mailer: git-send-email 2.44.0
In-Reply-To: <20240325204515.250203-1-jason.andryuk@amd.com>
References: <20240325204515.250203-1-jason.andryuk@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB03.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BL02EPF0001A104:EE_|SA1PR12MB6702:EE_
X-MS-Office365-Filtering-Correlation-Id: ec3560fb-a2b7-4468-bfc7-08dc4d0c7c78
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	tiir/iKRdDYx8IkrWcWOmvWqx9tJgv4x5IVTdIwcIQfEesk0fMeULuCisMpWf6/1qbbTzn/XttJbmOh04L+gnVtKjolvpQvzc3XW0c69A5maED2soxCrIgXjTgJtkIeeijMyEZ0xg69LoV1SGFUDsAQ3D/V4kqMr098sp3jzS/XEEkvHfZxFEocwRO3lyEaKy9Mi11w9/BJfJ3wwBFYiqXNa3b3ygbjsODuVC2CWNTLU7A3Spmb+SpyiPrV9xhtQUn8etVS4sNqXTlhlfrUvSkKN6B7V20OJpBP8pDPSb4OGTY7Hj58gjefLlRfB4v5tI/ik+cEp//WVjobzXGnqoVQ2INN+RiJk2u8BGdQb759xB6gMGJvHSlhfoBffF+kwEBSYSa04sR/U5TgbBZf6DPLO4Y7kOXL7YDRMdizW3Jo/IlWSWcsmQRnzrs76wEG9C41vLrLN639nc1Cvtus1SWz52ntqIOYYpDYqO0CkcczvUu/Y64g7Su+3SASUfwvlKDTQALSc8qEefav/dH2ZbEygakbD/iBZca2iJaN5LMbeH8vg0rstqXf1tILN+GIh52KCTu13IGKKWH7vIgdZjAeHUwZSiPF4qNV/klwfJeE03LvMfEw6fDzI3t7OJ4vr6NxKYRisC5Sb+rEAIn2jl33AHI7rKxnHLWawMIovCC2PMeFbjITQ/s4hn9uFxWIAEbZZsJtgSQ0S1DZ/HVvGBRs0yDLZK+Dt+GwIA1eYcbl1m6mXUhQeRyMXdqcPvZGN
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(1800799015)(36860700004)(376005)(82310400014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Mar 2024 20:45:20.2533
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: ec3560fb-a2b7-4468-bfc7-08dc4d0c7c78
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BL02EPF0001A104.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB6702

A new ELF note will specify the alignment for a relocatable PVH kernel.
ELF notes are suitable for vmlinux and other ELF files, so this
Linux-specific bzImage parsing in unnecessary.

This reverts commit c44cac229067faeec8f49247d1cf281723ac2d40.

Signed-off-by: Jason Andryuk 
---
 xen/arch/x86/bzimage.c             | 4 +---
 xen/arch/x86/hvm/dom0_build.c      | 4 +---
 xen/arch/x86/include/asm/bzimage.h | 2 +-
 xen/arch/x86/pv/dom0_build.c       | 2 +-
 4 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/xen/arch/x86/bzimage.c b/xen/arch/x86/bzimage.c
index 0f4cfc49f7..ac4fd428be 100644
--- a/xen/arch/x86/bzimage.c
+++ b/xen/arch/x86/bzimage.c
@@ -105,7 +105,7 @@ unsigned long __init bzimage_headroom(void *image_start,
 }
 
 int __init bzimage_parse(void *image_base, void **image_start,
-                         unsigned long *image_len, unsigned int *align)
+                         unsigned long *image_len)
 {
     struct setup_header *hdr = (struct setup_header *)(*image_start);
     int err = bzimage_check(hdr, *image_len);
@@ -118,8 +118,6 @@ int __init bzimage_parse(void *image_base, void **image_start,
     {
         *image_start += (hdr->setup_sects + 1) * 512 + hdr->payload_offset;
         *image_len = hdr->payload_length;
-        if ( align )
-            *align = hdr->kernel_alignment;
     }
 
     if ( elf_is_elfbinary(*image_start, *image_len) )
diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index bbae8a5645..0ceda4140b 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -548,14 +548,12 @@ static int __init pvh_load_kernel(struct domain *d, const module_t *image,
     struct elf_binary elf;
     struct elf_dom_parms parms;
     paddr_t last_addr;
-    unsigned int align = 0;
     struct hvm_start_info start_info = { 0 };
     struct hvm_modlist_entry mod = { 0 };
     struct vcpu *v = d->vcpu[0];
     int rc;
 
-    rc = bzimage_parse(image_base, &image_start, &image_len, &align);
-    if ( rc != 0 )
+    if ( (rc = bzimage_parse(image_base, &image_start, &image_len)) != 0 )
     {
         printk("Error trying to detect bz compressed kernel\n");
         return rc;
diff --git a/xen/arch/x86/include/asm/bzimage.h b/xen/arch/x86/include/asm/bzimage.h
index 2e04f5cc7b..7ed69d3910 100644
--- a/xen/arch/x86/include/asm/bzimage.h
+++ b/xen/arch/x86/include/asm/bzimage.h
@@ -6,6 +6,6 @@
 unsigned long bzimage_headroom(void *image_start, unsigned long image_length);
 
 int bzimage_parse(void *image_base, void **image_start,
-                  unsigned long *image_len, unsigned int *align);
+                  unsigned long *image_len);
 
 #endif /* __X86_BZIMAGE_H__ */
diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c
index e9fa8a9a82..d8043fa58a 100644
--- a/xen/arch/x86/pv/dom0_build.c
+++ b/xen/arch/x86/pv/dom0_build.c
@@ -416,7 +416,7 @@ int __init dom0_construct_pv(struct domain *d,
 
     d->max_pages = ~0U;
 
-    if ( (rc = bzimage_parse(image_base, &image_start, &image_len, NULL)) != 0 )
+    if ( (rc = bzimage_parse(image_base, &image_start, &image_len)) != 0 )
         return rc;
 
     if ( (rc = elf_init(&elf, image_start, image_len)) != 0 )
-- 
2.44.0



From xen-devel-bounces@lists.xenproject.org Mon Mar 25 20:45:38 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 20:45:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697880.1089124 (Exim 4.92)
	(envelope-from )
	id 1rorCG-0008HI-NL; Mon, 25 Mar 2024 20:45:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697880.1089124; Mon, 25 Mar 2024 20:45:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rorCG-0008H5-K0; Mon, 25 Mar 2024 20:45:32 +0000
Received: by outflank-mailman (input) for mailman id 697880;
 Mon, 25 Mar 2024 20:45:31 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rorCE-0007LI-V2
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 20:45:30 +0000
Received: from NAM02-DM3-obe.outbound.protection.outlook.com
 (mail-dm3nam02on20601.outbound.protection.outlook.com
 [2a01:111:f403:2405::601])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9cb74f27-eae8-11ee-a1ef-f123f15fe8a2;
 Mon, 25 Mar 2024 21:45:27 +0100 (CET)
Received: from MW4PR03CA0341.namprd03.prod.outlook.com (2603:10b6:303:dc::16)
 by SN7PR12MB7201.namprd12.prod.outlook.com (2603:10b6:806:2a8::22)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.31; Mon, 25 Mar
 2024 20:45:23 +0000
Received: from CO1PEPF000042AB.namprd03.prod.outlook.com
 (2603:10b6:303:dc:cafe::19) by MW4PR03CA0341.outlook.office365.com
 (2603:10b6:303:dc::16) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.13 via Frontend
 Transport; Mon, 25 Mar 2024 20:45:23 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CO1PEPF000042AB.mail.protection.outlook.com (10.167.243.40) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Mon, 25 Mar 2024 20:45:22 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Mon, 25 Mar
 2024 15:45:21 -0500
Received: from fedora.mshome.net (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Mon, 25 Mar 2024 15:45:20 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9cb74f27-eae8-11ee-a1ef-f123f15fe8a2
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=h8c9LXgrQixHW3dAYWgw/rqZ7cHqAt8cAdh31W2RurJpVS+qFY/D9EhCZbBfCBXaLgGBXdzBKanf2I8KQU8VzAM5foVb3RcZzUOrBLyqVk3EQzx8TNGKCZezzfSLIDvdVwuTu0Y2XHZ5cf1zN/TaLgS/9oc/tZmY9iiRUH2Nz0xLch1iLumBVqkNBT9QoLYkNzSMJgofYYuPdP1p5sIz49dAEYqmp++s2OZhrbG12hqbsLKlnyr1w8dDc1ITx2J5G6mqaZojpGnwwR2GDM1sTckA2+XabLSB28NY3znfb4HFLfKPPVonKXvmoytoEFlTlgAbAegcwGZIkpxnus6LqQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=kpYFdzJHkuO60SpR1aTtd436m2Cbip6KFJuG8vrlzio=;
 b=jADnyZeSgMJbTcIXMPTsMtEgjC4VggM4IvtHgeH+4aZjpOrmL9zp9rcrOQ++TioYMv3kwhRspU61W1z9Smh9ClttRw4PBUChEev6ikwJOVGdfXjmiEa070GxnP9vKrX1ZDbN5yeDuT/KW+gpVildZ1jS5+3CTJH15JUBvWtG5z6E9Hg27mMOcwf4Vq+Y1Kpdb4rzTLbUL+L+cCy9BPsJJryN2i2UsO11EuMHnhTAX9fmSdPc10WcuAlFh6tHj3qoTdUW5EqZ281f4EGNSkBiQcVo3AptMJmJt8a8zEl8i9y7aGMniFndrepEXqpJUtxy8lUzdtM82oc19tyqLrkUHg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=kpYFdzJHkuO60SpR1aTtd436m2Cbip6KFJuG8vrlzio=;
 b=wqUjck3XdPfpxL13G3wWkzd84346G+3E9HojdQDIJjmxlNfD+NknuXUeaA6kq5wRR7qGs09vfkYtLvfXLwapSa+gmnqAFnefBiGoVi4GQeyLSwt+ivDo3xJvo/4LaV89UdZopfmq5wCkkFxv7pd0GDtarPTRHK3QmVK/jyMiCXQ=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Jason Andryuk 
To: 
CC: Jason Andryuk , Juergen Gross ,
	Julien Grall , Anthony PERARD 
Subject: [PATCH v4 2/5] tools/init-xenstore-domain: Replace variable MB() usage
Date: Mon, 25 Mar 2024 16:45:12 -0400
Message-ID: <20240325204515.250203-3-jason.andryuk@amd.com>
X-Mailer: git-send-email 2.44.0
In-Reply-To: <20240325204515.250203-1-jason.andryuk@amd.com>
References: <20240325204515.250203-1-jason.andryuk@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB04.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CO1PEPF000042AB:EE_|SN7PR12MB7201:EE_
X-MS-Office365-Filtering-Correlation-Id: b6343f0d-23c3-4c4b-c6c6-08dc4d0c7dfa
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	Fdqdb6bVXcZsQl/xfkuIAW+XN6JEY3SlFK8Lbs7nuXVmjC2L6rGQSz4u0SV4UrrAZV0ChRx44KXn0nh+0IA+8EN3QuEHDQqON6rsk5Hu3//hIRkWHYzlD7tccIQEcYETu5ruNSx751sjTsUp74ht1X4Hp6ws2g3N2gHdIM2lLq1hNJ/6mifBuqoCS5+NA3HQshKlJnktUtpevGVJEiWgWB7Gq562I1Q85jRgpVJxgG2XhjUf0qApuqDRf+X9W6UdebJgNumZ9O4i7A1ZhhLtgsm7PhDrEEIFOWJRcTE3nudFWI1nZxd4p7CZBtvQ3y0Fq2S02xILUF410ByU+CEVT7Jzg1UgaA78e2cb9F1UKTIhCJ9bx/BJBV7PZmmisz9DzdjfA30PLdeqanrC3ybAlKIg2LmKb0ARfPYCJsYQZ7zftMqLDw9vNWE/GcH4VAKKBRK+kkjJ/DlT+FW0YPXto9HmMcnio+uVYzc8DmAJUoYzkjRJnYtVZa84EqIakM6UD/HHggUro8mu+JTD+Sea0ACm1gDvcT4LsaSfNU5Gu7M8DHHiQjaskUyUrJ4gjUaSZzaZOa/2a85rYLU+xaSHaMDM1TFTND/bfve2pYe7bapkWvvPiV6pvevSPqpT+qeSLIKHN/4xeN/vAtf+p9TLrot+koj7v9DuEUwMmpevMtaRX7YgBSscS8XUY9LMiOTrOLlsbzj+4aHoAWCyq49fVP18K4BNoF1boXc8r9mwToQpu6tZNmaz+7TgQR5pH3/b
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(1800799015)(82310400014)(376005)(36860700004);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Mar 2024 20:45:22.6582
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: b6343f0d-23c3-4c4b-c6c6-08dc4d0c7dfa
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CO1PEPF000042AB.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB7201

The local MB() & GB() macros will be replaced with a common
implementation, but those only work with constant values.  Introduce a
static inline mb_to_bytes() in place of the MB() macro to convert the
variable values.

Signed-off-by: Jason Andryuk 
---
v4:
New
---
 tools/helpers/init-xenstore-domain.c | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/tools/helpers/init-xenstore-domain.c b/tools/helpers/init-xenstore-domain.c
index 1683438c5c..5405842dfe 100644
--- a/tools/helpers/init-xenstore-domain.c
+++ b/tools/helpers/init-xenstore-domain.c
@@ -20,7 +20,6 @@
 #include "init-dom-json.h"
 
 #define LAPIC_BASE_ADDRESS  0xfee00000UL
-#define MB(x)               ((uint64_t)x << 20)
 #define GB(x)               ((uint64_t)x << 30)
 
 static uint32_t domid = ~0;
@@ -36,6 +35,11 @@ static xc_evtchn_port_or_error_t console_evtchn;
 static xentoollog_level minmsglevel = XTL_PROGRESS;
 static void *logger;
 
+static inline uint64_t mb_to_bytes(int mem)
+{
+	return (uint64_t)mem << 20;
+}
+
 static struct option options[] = {
     { "kernel", 1, NULL, 'k' },
     { "memory", 1, NULL, 'm' },
@@ -76,8 +80,8 @@ static int build(xc_interface *xch)
     int rv, xs_fd;
     struct xc_dom_image *dom = NULL;
     int limit_kb = (maxmem ? : memory) * 1024 + X86_HVM_NR_SPECIAL_PAGES * 4;
-    uint64_t mem_size = MB(memory);
-    uint64_t max_size = MB(maxmem ? : memory);
+    uint64_t mem_size = mb_to_bytes(memory);
+    uint64_t max_size = mb_to_bytes(maxmem ? : memory);
     struct e820entry e820[3];
     struct xen_domctl_createdomain config = {
         .ssidref = SECINITSID_DOMU,
-- 
2.44.0



From xen-devel-bounces@lists.xenproject.org Mon Mar 25 20:45:38 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 20:45:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697878.1089104 (Exim 4.92)
	(envelope-from )
	id 1rorCF-0007nw-3e; Mon, 25 Mar 2024 20:45:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697878.1089104; Mon, 25 Mar 2024 20:45:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rorCE-0007nl-Va; Mon, 25 Mar 2024 20:45:30 +0000
Received: by outflank-mailman (input) for mailman id 697878;
 Mon, 25 Mar 2024 20:45:29 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rorCD-0007L7-LC
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 20:45:29 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on20600.outbound.protection.outlook.com
 [2a01:111:f403:200a::600])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9c3767aa-eae8-11ee-afe3-a90da7624cb6;
 Mon, 25 Mar 2024 21:45:28 +0100 (CET)
Received: from MW4PR03CA0360.namprd03.prod.outlook.com (2603:10b6:303:dc::35)
 by IA1PR12MB6163.namprd12.prod.outlook.com (2603:10b6:208:3e9::22)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.31; Mon, 25 Mar
 2024 20:45:24 +0000
Received: from CO1PEPF000042AB.namprd03.prod.outlook.com
 (2603:10b6:303:dc:cafe::e4) by MW4PR03CA0360.outlook.office365.com
 (2603:10b6:303:dc::35) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.13 via Frontend
 Transport; Mon, 25 Mar 2024 20:45:24 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CO1PEPF000042AB.mail.protection.outlook.com (10.167.243.40) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Mon, 25 Mar 2024 20:45:24 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Mon, 25 Mar
 2024 15:45:23 -0500
Received: from fedora.mshome.net (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Mon, 25 Mar 2024 15:45:22 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9c3767aa-eae8-11ee-afe3-a90da7624cb6
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=SBBBzBlv2j3OYjZ8COtt3j43bwf03MgZCe9Z5R3DdlJxPNIDIUPgPTcBtKK/6TSAZTNqjlNyLdncsLa++3N6RwGOKiuSSPL6wcJLNzs7K2sbgVbUaFmT8UhOJTI7Slk+Jy9ZEysENsmeWI0p7PHZMMNxFUevaUwdYrXCYyddzdpS1QM4Ix5/C8p2doGAyYrOMfpCs+XzGSvatwOiyBq1DcxyWizEiVQvsbKAR7lyOCfD+YsogFdik/XTHjWPABZ3fHE+xUFbqvupiNaZtqbgkgZdOIevgmV+LUOkZTBJqddWOg4W8jd4tL3Nh8AxxPmpgXJsrCnB4FMzI3f6HaVzgw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=NWxzGLWg8rpT9SvmC6RSHVGPVmiDtkENizt4I3Gzge8=;
 b=BRrWN3d2bhmCNUeq6Auyi5EtjV3WNGOP0suuivF/vwpfBrKL9k2wXeRUOggoRgPnAKG4qwKMc+f2nvlMtH6O5LuBxQXsJ4hZFFqOmav85JHNrVEQPLLjQG7E/rj5gkaq45JRVc+g0aDeZD23z/gfJp9WBty8I2HyR3iufwUu2ifRxzOknLyOEVtgN0H2TipUwFh5Colq6I8a0Mw7LKzMsy8W9TmGfJgY54kNknoCAc7uPxdQttL5kD8YOViYryhT/98vA6midR5t3GlyOBsH8Im6EYm4NYiHpvtadZJNZnukPhC9vsjlvDxPad8XMZ+Dvcm9Yq98hwG8fR/fPlYHsA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=NWxzGLWg8rpT9SvmC6RSHVGPVmiDtkENizt4I3Gzge8=;
 b=ghuyiCh0uS3ZdksSvCLq3U+CVORRt5T6EEHxHFub3UflXzXTjmqWWhRqSkqjaRhR5ARgzV3n+JFTxV1cV5VN2OI25bCmjJKRiE1Vfd4LNPRc//GeBQ+0Iur1inxk4bSrtQG/Ix+fqRz5Sq+Ndpm4nBdMf7UobELuQKghmgFVkBo=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Jason Andryuk 
To: 
CC: Jason Andryuk , Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Anthony PERARD
	, Juergen Gross , Julien Grall
	
Subject: [PATCH v4 3/5] tools: Move MB/GB() to common-macros.h
Date: Mon, 25 Mar 2024 16:45:13 -0400
Message-ID: <20240325204515.250203-4-jason.andryuk@amd.com>
X-Mailer: git-send-email 2.44.0
In-Reply-To: <20240325204515.250203-1-jason.andryuk@amd.com>
References: <20240325204515.250203-1-jason.andryuk@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB04.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CO1PEPF000042AB:EE_|IA1PR12MB6163:EE_
X-MS-Office365-Filtering-Correlation-Id: 7f85f710-2bbe-4cdc-59ae-08dc4d0c7ef0
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	yHULqzfyCbHZTqZTGlLgk3UeRaHEfqfRAnBAwyi59qApHIvz6+5iVoMT7UQI/Hbgb5MTBAEnCoB/EhT9xd7bv8of0RzEwloyXuESu8lI2n02ZjFF59lTdHmq4u/z543sBynLGNfJg6TqeOTW+HG36BOjrmuIlRMcggepLIGiktI5Pg58FNcHJXVXhWqiMc/ECQdR3dFNuPbwA4SumDPFoZXPoS7Pvq0500o85l7k8k3MO9kZEAoklNWRLePDo0VSVB4wvgcayygNflR5vGzKq7Afq1KsdhpSSEelJUPjZrtl3BvToZOU+3fqV8Alq/eI3gNJ4Pep9pf7DYsuNOHbT8TGYO2qOa62oqCjezSZnpWZ6TkI8omxtYQo1c3MUPKC2sqS6aqlh29l6DgHdlLPlrbcYkh9HgY+oICdRvmeQHOdODvLt/0aW9cJEa7LDMcmEMkQoKEB1jfRwLzkCq+ojD0obw/kI49pYDNOZEp4rbzYPtUFMtfsWotjpOrtrbVvYBAkYxPiJqT2ZegYP17fOmMyN+whR+wiKDmVI+9CWKLitfdStb6UtRJTS7Z1rMA9qwTkawnqw0rrocbWx5TT29DUUWm9FM5sl5JC606Clc351TmrMpuO5taM9xDLi/n/dGVN6Vo1I7N/TIQ5NoO+ZU6BsU3psjHd1FHgYWCzFzeleVf6kMdkBXNDcKHMZnLUUpYc105JEW+RlzAq6o794owjs/V4Mc5WO60OjKivwVPkITEpcWqu4doVT96R9VQH
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(36860700004)(82310400014)(1800799015)(376005);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Mar 2024 20:45:24.2676
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 7f85f710-2bbe-4cdc-59ae-08dc4d0c7ef0
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CO1PEPF000042AB.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB6163

Consolidate to a single set of common macros for tools.

MB() will gain another use in libelf, so this movement makes it
available.

Signed-off-by: Jason Andryuk 
---
v4:
New
---
 tools/firmware/hvmloader/util.h         | 3 ---
 tools/helpers/init-xenstore-domain.c    | 1 -
 tools/include/xen-tools/common-macros.h | 4 ++++
 tools/libs/light/libxl_internal.h       | 4 ----
 4 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/tools/firmware/hvmloader/util.h b/tools/firmware/hvmloader/util.h
index 87be213dec..14078bde1e 100644
--- a/tools/firmware/hvmloader/util.h
+++ b/tools/firmware/hvmloader/util.h
@@ -38,9 +38,6 @@ void __bug(const char *file, int line) __attribute__((noreturn));
 #define BUG() __bug(__FILE__, __LINE__)
 #define BUG_ON(p) do { if (p) BUG(); } while (0)
 
-#define MB(mb) (mb##ULL << 20)
-#define GB(gb) (gb##ULL << 30)
-
 static inline int test_bit(unsigned int b, const void *p)
 {
     return !!(((const uint8_t *)p)[b>>3] & (1u<<(b&7)));
diff --git a/tools/helpers/init-xenstore-domain.c b/tools/helpers/init-xenstore-domain.c
index 5405842dfe..f38ba8d6b5 100644
--- a/tools/helpers/init-xenstore-domain.c
+++ b/tools/helpers/init-xenstore-domain.c
@@ -20,7 +20,6 @@
 #include "init-dom-json.h"
 
 #define LAPIC_BASE_ADDRESS  0xfee00000UL
-#define GB(x)               ((uint64_t)x << 30)
 
 static uint32_t domid = ~0;
 static char *kernel;
diff --git a/tools/include/xen-tools/common-macros.h b/tools/include/xen-tools/common-macros.h
index 81fba2e9f5..07aed92684 100644
--- a/tools/include/xen-tools/common-macros.h
+++ b/tools/include/xen-tools/common-macros.h
@@ -91,6 +91,10 @@
 #define __AC(X, Y)   (X ## Y)
 #define _AC(X, Y)    __AC(X, Y)
 
+/* Size macros. */
+#define MB(_mb)     (_AC(_mb, ULL) << 20)
+#define GB(_gb)     (_AC(_gb, ULL) << 30)
+
 #define get_unaligned_t(type, ptr) ({                               \
     const struct { type x; } __packed *ptr_ = (typeof(ptr_))(ptr);  \
     ptr_->x;                                                        \
diff --git a/tools/libs/light/libxl_internal.h b/tools/libs/light/libxl_internal.h
index 094d0df9b1..803dbc1a03 100644
--- a/tools/libs/light/libxl_internal.h
+++ b/tools/libs/light/libxl_internal.h
@@ -126,10 +126,6 @@
 #define PVSHIM_BASENAME "xen-shim"
 #define PVSHIM_CMDLINE "pv-shim console=xen,pv"
 
-/* Size macros. */
-#define MB(_mb)     (_AC(_mb, ULL) << 20)
-#define GB(_gb)     (_AC(_gb, ULL) << 30)
-
 #define DIV_ROUNDUP(n, d) (((n) + (d) - 1) / (d))
 
 #define LIBXL__LOGGING_ENABLED
-- 
2.44.0



From xen-devel-bounces@lists.xenproject.org Mon Mar 25 20:45:38 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 20:45:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697881.1089134 (Exim 4.92)
	(envelope-from )
	id 1rorCJ-00008C-1O; Mon, 25 Mar 2024 20:45:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697881.1089134; Mon, 25 Mar 2024 20:45:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rorCI-00007u-U9; Mon, 25 Mar 2024 20:45:34 +0000
Received: by outflank-mailman (input) for mailman id 697881;
 Mon, 25 Mar 2024 20:45:33 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rorCH-0007LI-3l
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 20:45:33 +0000
Received: from NAM04-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam04on20601.outbound.protection.outlook.com
 [2a01:111:f403:2408::601])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9e7e685b-eae8-11ee-a1ef-f123f15fe8a2;
 Mon, 25 Mar 2024 21:45:31 +0100 (CET)
Received: from BL1PR13CA0146.namprd13.prod.outlook.com (2603:10b6:208:2bb::31)
 by DS0PR12MB8072.namprd12.prod.outlook.com (2603:10b6:8:dd::11) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.31; Mon, 25 Mar
 2024 20:45:27 +0000
Received: from BL02EPF0001A102.namprd05.prod.outlook.com
 (2603:10b6:208:2bb:cafe::b) by BL1PR13CA0146.outlook.office365.com
 (2603:10b6:208:2bb::31) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.12 via Frontend
 Transport; Mon, 25 Mar 2024 20:45:27 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 BL02EPF0001A102.mail.protection.outlook.com (10.167.241.134) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Mon, 25 Mar 2024 20:45:27 +0000
Received: from SATLEXMB06.amd.com (10.181.40.147) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Mon, 25 Mar
 2024 15:45:26 -0500
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB06.amd.com
 (10.181.40.147) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Mon, 25 Mar
 2024 15:45:27 -0500
Received: from fedora.mshome.net (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Mon, 25 Mar 2024 15:45:26 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9e7e685b-eae8-11ee-a1ef-f123f15fe8a2
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=jBGv2hcspRiQHthjVTJTgY1Zo38ZLY70+o5naEC3vguv2fi6CQ+ME7sm1NXMmCxjoXzevypECaD2/5AUh30UNw4JUnkoWwBiKywssBoyBobIakMEWgwWX3Uw76zFEjIR7OUY6p69SzO9Cpf7QgLkQpXO3+4ZwE12tpfoIDPC7uX1HBL5oJlfVPmWhHbpYNjIbR39KriS69Z67uGzKm0k4ckPw1MR7KqJIDIY8gpHjx2bpz2Dl6gu9MbL4uDnSTLJZcBGzilToX6q1wNPTL0I1CIaNu1fMxEzKya+1PNv0HhtxynUOH4zoRRHqj7J2UGfLrblSEJX/uZdJh/kGsenEw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=5jacF0UMoGSb9RVAfT7Engwk4ViDuVVXCvP4NVs29k4=;
 b=JBjYaa3ekfLgK2vCQuVsmzl8cQis7dnRuYMGSG3wqe1Pw17Taz+wg/5udvp9nh+eLjeTT6j0ZVWZlLAN0bJKIinyQzvPcUdxhSK+RUGEK0J/sWJZM10NcAFd45mNdiLMhhvpxrkVwcLL6ySjE78eDZ+lDPPU7P9DkXyBxkYfxFA2wDFltp/2z7uelk+99Cu2NTiPh+rt2fCbb05cvOdDr4FDHYArLbJIHKxcgqM9Wv7ydtrZOYFX7ScSFpxxK31rinE3z4FNY1ORCVUyaVcE9GfE2OKOwglIA4RrctwbjuR57NYrRxJpB/GO6rTHeKG0g2FzFyscS8nY7l9ThZwSNg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=5jacF0UMoGSb9RVAfT7Engwk4ViDuVVXCvP4NVs29k4=;
 b=TrVGA/rnCSgDkDZIBcHkccCCFsDjqOaVcK0anDpmTEykpDJftdmpkLtNPpO/2xebyI5BNR305DrnSYxuvOhOdMChU19wWIt/KbpS2PAQbs8HO+s3mK6Cz9+zoPCrYYL4skkyMZaNS9Dqvv2vE+LaEiTk4R/+rCLavAKfnO2lNQU=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
From: Jason Andryuk 
To: 
CC: Jason Andryuk , Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , George Dunlap
	, Julien Grall , Stefano Stabellini
	
Subject: [PATCH v4 5/5] x86/PVH: Support relocatable dom0 kernels
Date: Mon, 25 Mar 2024 16:45:15 -0400
Message-ID: <20240325204515.250203-6-jason.andryuk@amd.com>
X-Mailer: git-send-email 2.44.0
In-Reply-To: <20240325204515.250203-1-jason.andryuk@amd.com>
References: <20240325204515.250203-1-jason.andryuk@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BL02EPF0001A102:EE_|DS0PR12MB8072:EE_
X-MS-Office365-Filtering-Correlation-Id: 267fe8e6-2916-4351-93dd-08dc4d0c80e1
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	46O/zpqTVIwGdxJ1STSHiFPium+6F+9V7jNn86RY55y5zc99JOXPBaP1L+W45inlSxQiJwVSfhyfThJ/lwYrWLZ+iVpwdaqOXcmpN5oKCuRC5x2ub9ynD50R2taxoOEoUcQfH38IQ1xRSUDdBwaW3z901gsCJHPMimfbtzDEMCnJ9PTnQu6oYuEwa37h8e/pwH5exlTolMcRmijU0A/33G0N35CPddpzD4WWAidtFNI9+gESXbzV3s9YbMowMgu+jyH29ePi32xSzC3zAuicN0fNVdty6647JRh7hqAreBoDFzVk+/sDLZYMhxtH29cHZqAIVjeIGmiaK5szJ9OyCSXzqBaYyw3kPYuSHdUTkAr7XewCv1eN9dBsqKD0RStpxCzQv/HO6kWfUPohlK2VOcpGCrwmd7dU7MfsIH3d2yzLBp2a4CTSo7vKD/zINCpxTZjZ39F4W8s5ewf6EqTRfBQ9H9aBZ3TXeBhlRJRy4j85CkiaGnk9kvHzdquxctKmSRYlqSmOdK+fAgyQhqqJ9S6v1HQEbNa5/SbO/VnjuZoZT/wqSy2TASg4C0DWq5M/UUwSjRAFF9zFDcjGo9K90kXg1LH+7QrdeViGce16WXz/Skr/2uDJhT/E7gNW9Rjn24cSebLiYmuumgg9WCEH+3C06J4tk4AB+qskgUgXBwI95hbfYwdk6Aw5aezgykd6ghA8nykkUri07y0WUncJgM+WV8ovxmUXe8Dom7n2EYZyZvKWR4/Y1KHn96gFxgre
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(376005)(82310400014)(36860700004)(1800799015);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Mar 2024 20:45:27.6512
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 267fe8e6-2916-4351-93dd-08dc4d0c80e1
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BL02EPF0001A102.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB8072

Xen tries to load a PVH dom0 kernel at the fixed guest physical address
from the elf headers.  For Linux, this defaults to 0x1000000 (16MB), but
it can be configured.

Unfortunately there exist firmwares that have reserved regions at this
address, so Xen fails to load the dom0 kernel since it's not RAM.

The PVH entry code is not relocatable - it loads from absolute
addresses, which fail when the kernel is loaded at a different address.
With a suitably modified kernel, a reloctable entry point is possible.

Add XEN_ELFNOTE_PHYS32_RELOC which specifies optional minimum, maximum and
alignment needed for the kernel.  The presence of the NOTE indicates the
kernel supports a relocatable entry path.

Change the loading to check for an acceptable load address.  If the
kernel is relocatable, support finding an alternate load address.

The primary motivation for an explicit align field is that Linux has a
configurable CONFIG_PHYSICAL_ALIGN field.  This value is present in the
bzImage setup header, but not the ELF program headers p_align, which
report 2MB even when CONFIG_PHYSICAL_ALIGN is greater.  Since a kernel
is only considered relocatable if the PHYS32_RELOC elf note is present,
the alignment contraints can just be specified within the note instead
of searching for an alignment value via a heuristic.

libelf-private.h includes common-macros.h to satisfy the fuzzer build.

Link: https://gitlab.com/xen-project/xen/-/issues/180
Signed-off-by: Jason Andryuk 
---
ELF Note printing looks like:
(XEN) ELF: note: PHYS32_RELOC = max: 0xffffffff min: 0x1000000 align: 0x200000

v2:
Use elfnote for min, max & align - use 64bit values.
Print original and relocated memory addresses
Use check_and_adjust_load_address() name
Return relocated base instead of offset
Use PAGE_ALIGN
Don't load above max_phys (expected to be 4GB in kernel elf note)
Use single line comments
Exit check_load_address loop earlier
Add __init to find_kernel_memory()

v3:
Remove kernel_start/end page rounding
Change loop comment to rely on a sorted memory map.
Reorder E820_RAM check first
Use %p for dest_base
Use PRIpaddr
Use 32bit phys_min/max/align
Consolidate to if ( x || y ) continue
Use max_t
Add parms->phys_reloc
Use common "%pd kernel: " prefix for messages
Re-order phys_entry assignment
Print range ends inclusively
Remove extra "Unable to load kernel" message
s/PVH_RELOCATION/PHYS32_RELOC/
Make PHYS32_RELOC contents optional
Use 2MB default alignment
Update ELF Note comment
Update XEN_ELFNOTE_MAX

v4:
Cast dest_base to uintptr_t
Use local start variable
Mention e820 requiring adjacent entries merged
Remove extra whitespace
Re-word elfnote comment & mention x86
Use ELFNOTE_NAME
Return -ENOSPC
Use ! instead of == 0
Check kend - 1 to avoid off by one
libelf: Use MB/GB() to define the size.
Use ARCH_PHYS_* defines
---
 xen/arch/x86/hvm/dom0_build.c      | 94 ++++++++++++++++++++++++++++++
 xen/common/libelf/libelf-dominfo.c | 37 ++++++++++++
 xen/common/libelf/libelf-private.h |  1 +
 xen/include/public/elfnote.h       | 19 +++++-
 xen/include/xen/libelf.h           |  4 ++
 5 files changed, 154 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index 0ceda4140b..d925fc7417 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -537,6 +537,97 @@ static paddr_t __init find_memory(
     return INVALID_PADDR;
 }
 
+static bool __init check_load_address(
+    const struct domain *d, const struct elf_binary *elf)
+{
+    paddr_t kernel_start = (uintptr_t)elf->dest_base;
+    paddr_t kernel_end = kernel_start + elf->dest_size;
+    unsigned int i;
+
+    /* Relies on a sorted memory map with adjacent entries merged. */
+    for ( i = 0; i < d->arch.nr_e820; i++ )
+    {
+        paddr_t start = d->arch.e820[i].addr;
+        paddr_t end = start + d->arch.e820[i].size;
+
+        if ( start >= kernel_end )
+            return false;
+
+        if ( d->arch.e820[i].type == E820_RAM &&
+             start <= kernel_start &&
+             end >= kernel_end )
+            return true;
+    }
+
+    return false;
+}
+
+/* Find an e820 RAM region that fits the kernel at a suitable alignment. */
+static paddr_t __init find_kernel_memory(
+    const struct domain *d, struct elf_binary *elf,
+    const struct elf_dom_parms *parms)
+{
+    paddr_t kernel_size = elf->dest_size;
+    unsigned int i;
+
+    for ( i = 0; i < d->arch.nr_e820; i++ )
+    {
+        paddr_t start = d->arch.e820[i].addr;
+        paddr_t end = start + d->arch.e820[i].size;
+        paddr_t kstart, kend;
+
+        if ( d->arch.e820[i].type != E820_RAM ||
+             d->arch.e820[i].size < kernel_size )
+            continue;
+
+        kstart = ROUNDUP(start, parms->phys_align);
+        kstart = max_t(paddr_t, kstart, parms->phys_min);
+        kend = kstart + kernel_size;
+
+        if ( kend - 1 > parms->phys_max )
+            return 0;
+
+        if ( kend <= end )
+            return kstart;
+    }
+
+    return 0;
+}
+
+/* Check the kernel load address, and adjust if necessary and possible. */
+static bool __init check_and_adjust_load_address(
+    const struct domain *d, struct elf_binary *elf, struct elf_dom_parms *parms)
+{
+    paddr_t reloc_base;
+
+    if ( check_load_address(d, elf) )
+        return true;
+
+    if ( !parms->phys_reloc )
+    {
+        printk("%pd kernel: Address conflict and not relocatable\n", d);
+        return false;
+    }
+
+    reloc_base = find_kernel_memory(d, elf, parms);
+    if ( !reloc_base )
+    {
+        printk("%pd kernel: Failed find a load address\n", d);
+        return false;
+    }
+
+    if ( opt_dom0_verbose )
+        printk("%pd kernel: Moving [%p, %p] -> [%"PRIpaddr", %"PRIpaddr"]\n", d,
+               elf->dest_base, elf->dest_base + elf->dest_size - 1,
+               reloc_base, reloc_base + elf->dest_size - 1);
+
+    parms->phys_entry = reloc_base +
+                            (parms->phys_entry - (uintptr_t)elf->dest_base);
+    elf->dest_base = (char *)reloc_base;
+
+    return true;
+}
+
 static int __init pvh_load_kernel(struct domain *d, const module_t *image,
                                   unsigned long image_headroom,
                                   module_t *initrd, void *image_base,
@@ -585,6 +676,9 @@ static int __init pvh_load_kernel(struct domain *d, const module_t *image,
     elf.dest_base = (void *)(parms.virt_kstart - parms.virt_base);
     elf.dest_size = parms.virt_kend - parms.virt_kstart;
 
+    if ( !check_and_adjust_load_address(d, &elf, &parms) )
+        return -ENOSPC;
+
     elf_set_vcpu(&elf, v);
     rc = elf_load_binary(&elf);
     if ( rc < 0 )
diff --git a/xen/common/libelf/libelf-dominfo.c b/xen/common/libelf/libelf-dominfo.c
index e7b44d238b..b47d540023 100644
--- a/xen/common/libelf/libelf-dominfo.c
+++ b/xen/common/libelf/libelf-dominfo.c
@@ -17,6 +17,16 @@
 
 #include "libelf-private.h"
 
+#if defined(__i386__) || defined(__x86_64__)
+#define ARCH_PHYS_MIN_DEFAULT   0;
+#define ARCH_PHYS_MAX_DEFAULT   (GB(4) - 1);
+#define ARCH_PHYS_ALIGN_DEFAULT MB(2);
+#else
+#define ARCH_PHYS_MIN_DEFAULT   0;
+#define ARCH_PHYS_MAX_DEFAULT   0;
+#define ARCH_PHYS_ALIGN_DEFAULT 0;
+#endif
+
 /* ------------------------------------------------------------------------ */
 /* xen features                                                             */
 
@@ -125,6 +135,7 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
         [XEN_ELFNOTE_SUSPEND_CANCEL] = { "SUSPEND_CANCEL", ELFNOTE_INT },
         [XEN_ELFNOTE_MOD_START_PFN] = { "MOD_START_PFN", ELFNOTE_INT },
         [XEN_ELFNOTE_PHYS32_ENTRY] = { "PHYS32_ENTRY", ELFNOTE_INT },
+        [XEN_ELFNOTE_PHYS32_RELOC] = { "PHYS32_RELOC", ELFNOTE_NAME },
     };
 /* *INDENT-ON* */
 
@@ -132,6 +143,7 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
     uint64_t val = 0;
     unsigned int i;
     unsigned type = elf_uval(elf, note, type);
+    unsigned descsz = elf_uval(elf, note, descsz);
 
     if ( (type >= sizeof(note_desc) / sizeof(note_desc[0])) ||
          (note_desc[type].name == NULL) )
@@ -227,6 +239,27 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
     case XEN_ELFNOTE_PHYS32_ENTRY:
         parms->phys_entry = val;
         break;
+
+    case XEN_ELFNOTE_PHYS32_RELOC:
+        parms->phys_reloc = true;
+
+        if ( descsz >= 4 )
+        {
+            parms->phys_max = elf_note_numeric_array(elf, note, 4, 0);
+            elf_msg(elf, " = max: %#"PRIx32, parms->phys_max);
+        }
+        if ( descsz >= 8 )
+        {
+            parms->phys_min = elf_note_numeric_array(elf, note, 4, 1);
+            elf_msg(elf, " min: %#"PRIx32, parms->phys_min);
+        }
+        if ( descsz >= 12 )
+        {
+            parms->phys_align = elf_note_numeric_array(elf, note, 4, 2);
+            elf_msg(elf, " align: %#"PRIx32, parms->phys_align);
+        }
+
+        break;
     }
 
     if ( note_desc[type].type == ELFNOTE_NAME)
@@ -542,6 +575,10 @@ elf_errorstatus elf_xen_parse(struct elf_binary *elf,
     parms->p2m_base = UNSET_ADDR;
     parms->elf_paddr_offset = UNSET_ADDR;
     parms->phys_entry = UNSET_ADDR32;
+    parms->phys_min = ARCH_PHYS_MIN_DEFAULT;
+    parms->phys_max = ARCH_PHYS_MAX_DEFAULT;
+    parms->phys_align = ARCH_PHYS_ALIGN_DEFAULT;
+    parms->phys_reloc = false;
 
     /* Find and parse elf notes. */
     count = elf_phdr_count(elf);
diff --git a/xen/common/libelf/libelf-private.h b/xen/common/libelf/libelf-private.h
index 47db679966..98cac65bc5 100644
--- a/xen/common/libelf/libelf-private.h
+++ b/xen/common/libelf/libelf-private.h
@@ -71,6 +71,7 @@
 #endif
 #include 
 #include 
+#include 
 
 #ifndef FUZZ_NO_LIBXC
 #include "xenctrl.h"
diff --git a/xen/include/public/elfnote.h b/xen/include/public/elfnote.h
index 8bf54d035b..ed87d5575d 100644
--- a/xen/include/public/elfnote.h
+++ b/xen/include/public/elfnote.h
@@ -194,10 +194,27 @@
  */
 #define XEN_ELFNOTE_PHYS32_ENTRY 18
 
+/*
+ * Physical loading constraints for PVH kernels
+ *
+ * The presence of this note indicates the kernel supports relocating itself.
+ *
+ * The note may include up to three 32bit values to place constraints on the
+ * guest physical loading addresses and alignment for a PVH kernel.  Values
+ * are read in the following order:
+ *  - a maximum address for the entire image to be loaded below (default
+ *      0xffffffff)
+ *  - a minimum address for the start of the image (default 0)
+ *  - a required start alignment (default 0x200000)
+ *
+ *  This note is only valid for x86 binaries.
+ */
+#define XEN_ELFNOTE_PHYS32_RELOC 19
+
 /*
  * The number of the highest elfnote defined.
  */
-#define XEN_ELFNOTE_MAX XEN_ELFNOTE_PHYS32_ENTRY
+#define XEN_ELFNOTE_MAX XEN_ELFNOTE_PHYS32_RELOC
 
 /*
  * System information exported through crash notes.
diff --git a/xen/include/xen/libelf.h b/xen/include/xen/libelf.h
index 1c77e3df31..777c5008ca 100644
--- a/xen/include/xen/libelf.h
+++ b/xen/include/xen/libelf.h
@@ -434,10 +434,14 @@ struct elf_dom_parms {
     uint32_t f_supported[XENFEAT_NR_SUBMAPS];
     uint32_t f_required[XENFEAT_NR_SUBMAPS];
     uint32_t phys_entry;
+    uint32_t phys_min;
+    uint32_t phys_max;
+    uint32_t phys_align;
 
     /* calculated */
     uint64_t virt_kstart;
     uint64_t virt_kend;
+    bool phys_reloc;
 };
 
 static inline void elf_xen_feature_set(int nr, uint32_t * addr)
-- 
2.44.0



From xen-devel-bounces@lists.xenproject.org Mon Mar 25 20:45:38 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 20:45:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697879.1089109 (Exim 4.92)
	(envelope-from )
	id 1rorCF-0007rW-Eq; Mon, 25 Mar 2024 20:45:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697879.1089109; Mon, 25 Mar 2024 20:45:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rorCF-0007rA-9O; Mon, 25 Mar 2024 20:45:31 +0000
Received: by outflank-mailman (input) for mailman id 697879;
 Mon, 25 Mar 2024 20:45:30 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rorCE-0007L7-LC
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 20:45:30 +0000
Received: from NAM04-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam04on20600.outbound.protection.outlook.com
 [2a01:111:f403:2408::600])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9cab45cf-eae8-11ee-afe3-a90da7624cb6;
 Mon, 25 Mar 2024 21:45:28 +0100 (CET)
Received: from BL1PR13CA0138.namprd13.prod.outlook.com (2603:10b6:208:2bb::23)
 by LV3PR12MB9234.namprd12.prod.outlook.com (2603:10b6:408:1a0::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.32; Mon, 25 Mar
 2024 20:45:26 +0000
Received: from BL02EPF0001A102.namprd05.prod.outlook.com
 (2603:10b6:208:2bb:cafe::c0) by BL1PR13CA0138.outlook.office365.com
 (2603:10b6:208:2bb::23) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.12 via Frontend
 Transport; Mon, 25 Mar 2024 20:45:26 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 BL02EPF0001A102.mail.protection.outlook.com (10.167.241.134) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Mon, 25 Mar 2024 20:45:25 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Mon, 25 Mar
 2024 15:45:24 -0500
Received: from fedora.mshome.net (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Mon, 25 Mar 2024 15:45:24 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9cab45cf-eae8-11ee-afe3-a90da7624cb6
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=YW42aADAmMPGR9Pgh+6NlXpd9cbDaA85hex+5vgSzKweK9BCz1eTsuXosmSAvJrrYwP1Zq8XO2IK23QNYE4lmWOyK7mePeeAHFeof0Fw6FmuMJKWq8P42tZ3OHJX+Qmbe3NOAm7zdDndHXD3431AIhcuZyJph13jFcXz8aTkllm7ekPZ7tn83ZjWiGmA1jvJy39DN0OEA1zAqf9DmmKvQG0NlAINrY0NdQQW/yLSMAY4nNu3MHbZ7Nwg20iE5MzYRqdXqXJeOdrXD3qTnLiW+7KGSB5fI2Dg4B8NIL2AYlQmRpIo+MSKH3iv5nO4MI81Ul7gVKy+1YCUcZtMhs0x5w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ePBeoHAZ89v7gvk2hxDlL5ktUBtUjVi0i6hIkMIc1ds=;
 b=QbLf5G0PUPeOiVT1J2cPAVppwzzd5tvUgfXEtvydoKiOh3UZZWcfU5Qp6K8IFBNSePVHAH8GyKVOMsyD+2+UolHP/JFMIzTHa8v7yKSWwLcezabmeIKV9OsHPWl18NP+P59mbhHoEJ6Bf859se14hrr/3W8nHIXWUaKgkUTXDd/OmioBv+Oo4ce8SbVpn9N/mT6PpvZQyzNJD9GpSsec40VNJCBi8n/jNYJCpBxnvLuUcJw4HP4oi9jIGRUDvBBVSakKWIVLow0aKnlIzyY5Jf+uFva6n8eT+u4tyydZhuv+VP4c6HTBaIZNfnkNkiYf96sE1Dc+9NDAb+NVQ99JBg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=ePBeoHAZ89v7gvk2hxDlL5ktUBtUjVi0i6hIkMIc1ds=;
 b=5O4lp8aseLPPRGcci8B3nEEhF4JCRp7wPezA5Og/K+H+PyEQx+e9nnztU6JdSZo9jClhC04cvRYPNYt5fVB2JOQFoQYOux7Qoai+OT3F58lURXlb+cH21znZD8KqT7BnmYm+acFp7TTcFPYhFBPCkiSJTIDYUYfwN9E69CFlLxs=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
From: Jason Andryuk 
To: 
CC: Jason Andryuk , Andrew Cooper
	, George Dunlap , "Jan
 Beulich" , Julien Grall , "Stefano
 Stabellini" 
Subject: [PATCH v4 4/5] libelf: Expand ELF note printing
Date: Mon, 25 Mar 2024 16:45:14 -0400
Message-ID: <20240325204515.250203-5-jason.andryuk@amd.com>
X-Mailer: git-send-email 2.44.0
In-Reply-To: <20240325204515.250203-1-jason.andryuk@amd.com>
References: <20240325204515.250203-1-jason.andryuk@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB03.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BL02EPF0001A102:EE_|LV3PR12MB9234:EE_
X-MS-Office365-Filtering-Correlation-Id: 3ba94830-f9ca-4a6a-3df1-08dc4d0c7fa9
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	f5BqoaUWWbLZO3K2yNThcgZZ/IENu0PLQ6N8rz3FkhjaGMcOXXp6eIryWbLRe5EVXKik/VeYaAgiErVukDpOSOeDfV9uJCTGzNYEUrR6J2D1puHsgzoiusmJmQ5Y+78/O5HpoFKhVlHg69uhCdYVDEuO9wMGNZx27r8yCUQKcklOM5qMO8U4EAPhYMS8oXVfPFFm1ZoKr3UroSXKiTwTSKjKWd0i4zclJ5BG2M5zwYCIVasNOIeRIE8hD8zmsJKhclZxEmvI0d7VmlyX2GTdu6lLxZbwdzAtD2mlEoLQUS7MBlCfwRFWW4qiTftD2/J9yumyUrANspuqcjI9XuV+MgovYvj0D0HXXoj52+ewiq8JsG2djv60sPXN3LTN6LE9fYh6DJaw0mVCqY2Jf+ojgGuL3IPGptH9L0yvpxzVVh+1kjJs5LPKWeuec0GnzvmdWz2k61U53/rzQHf8uOchf0zR6i3AJLtoR3L+51GtIGh2V2eUymp+ks4T7xKaLi6xSK5KQJiJu/XYAsgTEzLMJS9ftdwV7hEYnR+E8SwQDGvLdFFLkLwkFJAI+WeKLE+99qIq34dZZvhqnuV++qSlvmnoua7Cy13niPAixe5KE58P7Wc8m3SRXTTAfQujxV00D240CK9SqyDwOfeEagPWbhOJ/k6AKXejeslorZWEwHPkktCzSjkTNQmbjuiLZizA1ALuATPncsu1+As7qUG7Nc3E2niTrL6lIt4XkzV9qwirE4LD9ePhCeNZtkHjRjDW
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(36860700004)(82310400014)(1800799015)(376005);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Mar 2024 20:45:25.6043
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 3ba94830-f9ca-4a6a-3df1-08dc4d0c7fa9
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BL02EPF0001A102.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR12MB9234

The XEN_ELFNOTE_L1_MFN_VALID is an array of pairs of values, but it is
printed as:
(XEN) ELF: note: L1_MFN_VALID = 0

This is a limitation of only printing either string or numeric values.
Switch from the boolean to an enum which allows more flexibility in
printing the values.  Introduce ELFNOTE_NAME to only print the name
without a value like:
(XEN) ELF: note: L1_MFN_VALID

Details can optionally be printed for specific notes.

Signed-off-by: Jason Andryuk 
---
v3:
Remove fatal size check
Don't print values - just the name for presence

v4:
Use switch
Always print newline for ELFNOTE_NAME
---
 xen/common/libelf/libelf-dominfo.c | 60 ++++++++++++++++++------------
 1 file changed, 37 insertions(+), 23 deletions(-)

diff --git a/xen/common/libelf/libelf-dominfo.c b/xen/common/libelf/libelf-dominfo.c
index a13a5e4db6..e7b44d238b 100644
--- a/xen/common/libelf/libelf-dominfo.c
+++ b/xen/common/libelf/libelf-dominfo.c
@@ -101,26 +101,30 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
 /* *INDENT-OFF* */
     static const struct {
         const char *name;
-        bool str;
+        enum {
+            ELFNOTE_INT,
+            ELFNOTE_STRING,
+            ELFNOTE_NAME,
+        } type;
     } note_desc[] = {
-        [XEN_ELFNOTE_ENTRY] = { "ENTRY", 0},
-        [XEN_ELFNOTE_HYPERCALL_PAGE] = { "HYPERCALL_PAGE", 0},
-        [XEN_ELFNOTE_VIRT_BASE] = { "VIRT_BASE", 0},
-        [XEN_ELFNOTE_INIT_P2M] = { "INIT_P2M", 0},
-        [XEN_ELFNOTE_PADDR_OFFSET] = { "PADDR_OFFSET", 0},
-        [XEN_ELFNOTE_HV_START_LOW] = { "HV_START_LOW", 0},
-        [XEN_ELFNOTE_XEN_VERSION] = { "XEN_VERSION", 1},
-        [XEN_ELFNOTE_GUEST_OS] = { "GUEST_OS", 1},
-        [XEN_ELFNOTE_GUEST_VERSION] = { "GUEST_VERSION", 1},
-        [XEN_ELFNOTE_LOADER] = { "LOADER", 1},
-        [XEN_ELFNOTE_PAE_MODE] = { "PAE_MODE", 1},
-        [XEN_ELFNOTE_FEATURES] = { "FEATURES", 1},
-        [XEN_ELFNOTE_SUPPORTED_FEATURES] = { "SUPPORTED_FEATURES", 0},
-        [XEN_ELFNOTE_BSD_SYMTAB] = { "BSD_SYMTAB", 1},
-        [XEN_ELFNOTE_L1_MFN_VALID] = { "L1_MFN_VALID", false },
-        [XEN_ELFNOTE_SUSPEND_CANCEL] = { "SUSPEND_CANCEL", 0 },
-        [XEN_ELFNOTE_MOD_START_PFN] = { "MOD_START_PFN", 0 },
-        [XEN_ELFNOTE_PHYS32_ENTRY] = { "PHYS32_ENTRY", 0 },
+        [XEN_ELFNOTE_ENTRY] = { "ENTRY", ELFNOTE_INT },
+        [XEN_ELFNOTE_HYPERCALL_PAGE] = { "HYPERCALL_PAGE", ELFNOTE_INT },
+        [XEN_ELFNOTE_VIRT_BASE] = { "VIRT_BASE", ELFNOTE_INT },
+        [XEN_ELFNOTE_INIT_P2M] = { "INIT_P2M", ELFNOTE_INT },
+        [XEN_ELFNOTE_PADDR_OFFSET] = { "PADDR_OFFSET", ELFNOTE_INT },
+        [XEN_ELFNOTE_HV_START_LOW] = { "HV_START_LOW", ELFNOTE_INT },
+        [XEN_ELFNOTE_XEN_VERSION] = { "XEN_VERSION", ELFNOTE_STRING },
+        [XEN_ELFNOTE_GUEST_OS] = { "GUEST_OS", ELFNOTE_STRING },
+        [XEN_ELFNOTE_GUEST_VERSION] = { "GUEST_VERSION", ELFNOTE_STRING },
+        [XEN_ELFNOTE_LOADER] = { "LOADER", ELFNOTE_STRING },
+        [XEN_ELFNOTE_PAE_MODE] = { "PAE_MODE", ELFNOTE_STRING },
+        [XEN_ELFNOTE_FEATURES] = { "FEATURES", ELFNOTE_STRING },
+        [XEN_ELFNOTE_SUPPORTED_FEATURES] = { "SUPPORTED_FEATURES", ELFNOTE_INT },
+        [XEN_ELFNOTE_BSD_SYMTAB] = { "BSD_SYMTAB", ELFNOTE_STRING },
+        [XEN_ELFNOTE_L1_MFN_VALID] = { "L1_MFN_VALID", ELFNOTE_NAME },
+        [XEN_ELFNOTE_SUSPEND_CANCEL] = { "SUSPEND_CANCEL", ELFNOTE_INT },
+        [XEN_ELFNOTE_MOD_START_PFN] = { "MOD_START_PFN", ELFNOTE_INT },
+        [XEN_ELFNOTE_PHYS32_ENTRY] = { "PHYS32_ENTRY", ELFNOTE_INT },
     };
 /* *INDENT-ON* */
 
@@ -136,8 +140,9 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
         return 0;
     }
 
-    if ( note_desc[type].str )
+    switch ( note_desc[type].type )
     {
+    case ELFNOTE_STRING :
         str = elf_strval(elf, elf_note_desc(elf, note));
         if (str == NULL)
             /* elf_strval will mark elf broken if it fails so no need to log */
@@ -145,13 +150,18 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
         elf_msg(elf, "ELF: note: %s = \"%s\"\n", note_desc[type].name, str);
         parms->elf_notes[type].type = XEN_ENT_STR;
         parms->elf_notes[type].data.str = str;
-    }
-    else
-    {
+        break;
+
+    case ELFNOTE_INT:
         val = elf_note_numeric(elf, note);
         elf_msg(elf, "ELF: note: %s = %#" PRIx64 "\n", note_desc[type].name, val);
         parms->elf_notes[type].type = XEN_ENT_LONG;
         parms->elf_notes[type].data.num = val;
+        break;
+
+    case ELFNOTE_NAME:
+        elf_msg(elf, "ELF: note: %s", note_desc[type].name);
+        break;
     }
     parms->elf_notes[type].name = note_desc[type].name;
 
@@ -218,6 +228,10 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
         parms->phys_entry = val;
         break;
     }
+
+    if ( note_desc[type].type == ELFNOTE_NAME)
+        elf_msg(elf, "\n");
+
     return 0;
 }
 
-- 
2.44.0



From xen-devel-bounces@lists.xenproject.org Mon Mar 25 20:45:38 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 20:45:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697876.1089084 (Exim 4.92)
	(envelope-from )
	id 1rorCD-0007LQ-JA; Mon, 25 Mar 2024 20:45:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697876.1089084; Mon, 25 Mar 2024 20:45:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rorCD-0007LJ-FG; Mon, 25 Mar 2024 20:45:29 +0000
Received: by outflank-mailman (input) for mailman id 697876;
 Mon, 25 Mar 2024 20:45:28 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rorCC-0007L7-Dn
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 20:45:28 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on20600.outbound.protection.outlook.com
 [2a01:111:f403:2412::600])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 99cd7e94-eae8-11ee-afe3-a90da7624cb6;
 Mon, 25 Mar 2024 21:45:26 +0100 (CET)
Received: from SJ0PR03CA0159.namprd03.prod.outlook.com (2603:10b6:a03:338::14)
 by SJ2PR12MB7821.namprd12.prod.outlook.com (2603:10b6:a03:4d2::21)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.31; Mon, 25 Mar
 2024 20:45:19 +0000
Received: from CO1PEPF000042AE.namprd03.prod.outlook.com
 (2603:10b6:a03:338:cafe::ac) by SJ0PR03CA0159.outlook.office365.com
 (2603:10b6:a03:338::14) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.13 via Frontend
 Transport; Mon, 25 Mar 2024 20:45:19 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CO1PEPF000042AE.mail.protection.outlook.com (10.167.243.43) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Mon, 25 Mar 2024 20:45:18 +0000
Received: from SATLEXMB06.amd.com (10.181.40.147) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Mon, 25 Mar
 2024 15:45:18 -0500
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB06.amd.com
 (10.181.40.147) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Mon, 25 Mar
 2024 15:45:17 -0500
Received: from fedora.mshome.net (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Mon, 25 Mar 2024 15:45:16 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 99cd7e94-eae8-11ee-afe3-a90da7624cb6
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=d2H6DGwLWkgS9BpczdGu6La7aNft0ZYMWAobnXiG/YOR1wWF9jQdAHjKwZhRdjOcQ6aDWf16mDDnRMqTrygTdKRateLa19Y+fc5fyTtjI6EnKiIE9v4KDLFdoBPRRUwiYvuSMDLPvoRsKRbld48oewaVc7IvZdNFDTduIUQX2gqmAiycWbjIFa0kIjv2eEMeAXhf/gzQfpk29ETM9stjyNJjLJqVE+iM+lROj3QZEEatobRUcpj6KfgcVeTEYi/I9P/HnAJ7K8IZPfhBcJIkCaBWKCUVtxB8sIG2otRzyPs7cvitEVXjafBeYxemXqXJ2if/N8JU4AarQekO7x9aCA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=BVIhZ2xHZdP1BNOcu89kmSvypYbpjEehnkVKCvRnSFQ=;
 b=kopnGztjHt91LuKWXajCm14mBDw6+OIM6ZhFdPlT0jnL38IGn39t4O5ioJZ3Q0aGqb8xOs9QVt0UsM9x+mHIUyBFRyJJLjqGV5C/fwe076RxXUwxi+CEhn4EKsISzb9pHOt1AM83CPUC9IIMP87cU0aaTUM+RI9asRkfVGGYlvRAzfvmZLjXFhlObj44Vvedny9bxKqXxzt1aAe/LFmSBbE+Dbkvc6FyOp7WCVIUXavrOR+qiAxqGa43qyRCAahRXv5yvdMPaU4AJaCEZBl2pQ2hQNarLZtCO8kp/dkaF9gJehHE7ZdFcDXfQW0dWLyWf/MxK2SG//kNJ4IHyCKnsw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=BVIhZ2xHZdP1BNOcu89kmSvypYbpjEehnkVKCvRnSFQ=;
 b=ycQXLov3tn5C9E9QcWvljSp76U7HjrBtBLsh3AwMbemviRlIYX+UBBv8jAAto25gxVTAd29N2Ag965+nHuM7svcw74mqlOdcWmc2hopv/PNVpxFyDffyju+Roic0e5k1QGC4CXwTsu1pOlRgm9JbhdtJdWqShsKdiYBIv8P8BFY=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Jason Andryuk 
To: 
CC: Jason Andryuk , Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Juergen Gross
	, Julien Grall , Anthony PERARD
	, George Dunlap ,
	Stefano Stabellini 
Subject: [PATCH v4 0/5] x86/pvh: Support relocating dom0 kernel
Date: Mon, 25 Mar 2024 16:45:10 -0400
Message-ID: <20240325204515.250203-1-jason.andryuk@amd.com>
X-Mailer: git-send-email 2.44.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CO1PEPF000042AE:EE_|SJ2PR12MB7821:EE_
X-MS-Office365-Filtering-Correlation-Id: bae5e3af-9f19-4df3-b16f-08dc4d0c7b92
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	QoWDtB29oD+tbpcmQ3JpM7xBMSoGO/AsriQvvjnNWH8eNyBBhChHQmjxgUK2vJYVgQOC3RvQ5bgyGQOx2eO9PbQs2ygNMvqsKFiyJbAZZ8jmn3BrVuGqdYzDdgPmWiZw+bYdgDcL86ikMzZSFOx4ZCS24cRn6pvlTrlcVYMpmfNMps7J/mQFDZ1MoQMN1Wkgpl3I8EhXKRnBpzxCa8ow6KrRfTFpyF22wSkuBhp/7r6VHgxofmYopDQnVqfstaoQGr9tQOrUSB5c6s8R1slpRKoZG+9gAucQfForMZjYZ52Bq57Z9Bbf4tvMXvuWTlnuWC94aecPJMf1PCaHXR93qZaDLqt8M2HTYISGBbCXKZbGk+4S6plcc/zuwNMjRxnHLT9jBk61qcdkeeuViuQZqnZhHGHLZm2TS/0kDVao7T+Ih0DPr+j2eu4NxNkzqiOzccmy1JqjL5xThbU4BECd57uztE/pZ2smKzbP2WbdbfrKgzIoEMmVjtiwk6uHpZubzrfPmoiczjNR7P51QBOYryeyLMShEfayR+qxx9kuxcPG40IqinuQH7f1a+2ViUsIs+g5G3AbaxLJN6NvVJQg8sBPRxvFYN6TZPXA+EXv3fuZm8yMWz+GjgcTA9q5aEzq0zHGkkMYs51IzFVkQCCskdG+n3DD4GXt/jThuj53BaBUNsmtP4p/BuGh+4gVYkQI9D579yOgm+OGeg6w4EStVTzcYBSkRq5csFfL9DgxUd4qH/3F1tbHqx2RXnl7npZ+
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(376005)(82310400014)(36860700004)(1800799015);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Mar 2024 20:45:18.6519
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: bae5e3af-9f19-4df3-b16f-08dc4d0c7b92
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CO1PEPF000042AE.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB7821

Xen tries to load a PVH dom0 kernel at the fixed guest physical address
from the elf headers.  For Linux, this defaults to 0x1000000 (16MB), but
it can be configured.

Unfortunately there exist firmwares that have reserved regions at this
address, so Xen fails to load the dom0 kernel since it's not RAM.

The other issue is that the Linux PVH entry point is not
position-independent.  It expects to run at the compiled
CONFIG_PHYSICAL_ADDRESS.

This patch set expands the PVH dom0 builder to try to relocate the
kernel if needed and possible.  XEN_ELFNOTE_PHYS32_RELOC is added for
kernels to indicate they are relocatable and their acceptable address
range and alignment.

The first patch reverts "xen/x86: bzImage parse kernel_alignment" since
the alignment will be specified by the ELF note.

The second and third patches move MB/GB() to common-macros.h.

The fourth patch expands ELF note printing beyond just printing
integers and strings.

The fifth patch expands the pvh dom0 kernel placement code.

I'll post an additional patch showing the Linux changes to make PVH
relocatable.

Jason Andryuk (5):
  Revert "xen/x86: bzImage parse kernel_alignment"
  tools/init-xenstore-domain: Replace variable MB() usage
  tools: Move MB/GB() to common-macros.h
  libelf: Expand ELF note printing
  x86/PVH: Support relocatable dom0 kernels

 tools/firmware/hvmloader/util.h         |  3 -
 tools/helpers/init-xenstore-domain.c    | 11 ++-
 tools/include/xen-tools/common-macros.h |  4 +
 tools/libs/light/libxl_internal.h       |  4 -
 xen/arch/x86/bzimage.c                  |  4 +-
 xen/arch/x86/hvm/dom0_build.c           | 98 ++++++++++++++++++++++++-
 xen/arch/x86/include/asm/bzimage.h      |  2 +-
 xen/arch/x86/pv/dom0_build.c            |  2 +-
 xen/common/libelf/libelf-dominfo.c      | 97 ++++++++++++++++++------
 xen/common/libelf/libelf-private.h      |  1 +
 xen/include/public/elfnote.h            | 19 ++++-
 xen/include/xen/libelf.h                |  4 +
 12 files changed, 206 insertions(+), 43 deletions(-)

-- 
2.44.0



From xen-devel-bounces@lists.xenproject.org Mon Mar 25 21:44:11 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Mar 2024 21:44:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697898.1089143 (Exim 4.92)
	(envelope-from )
	id 1ros6v-0001sW-Aa; Mon, 25 Mar 2024 21:44:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697898.1089143; Mon, 25 Mar 2024 21:44:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1ros6v-0001sP-85; Mon, 25 Mar 2024 21:44:05 +0000
Received: by outflank-mailman (input) for mailman id 697898;
 Mon, 25 Mar 2024 21:44:04 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1ros6u-0001sJ-2F
 for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 21:44:04 +0000
Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.4])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c9f9bfc9-eaf0-11ee-a1ef-f123f15fe8a2;
 Mon, 25 Mar 2024 22:44:01 +0100 (CET)
Received: from m5p.com (mailhost.m5p.com [IPv6:2001:470:1f07:15ff:0:0:0:f7])
 by mailhost.m5p.com (8.17.1/8.15.2) with ESMTPS id 42PLhjIc069561
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
 Mon, 25 Mar 2024 17:43:50 -0400 (EDT) (envelope-from ehem@m5p.com)
Received: (from ehem@localhost)
 by m5p.com (8.17.1/8.15.2/Submit) id 42PLhiqK069560;
 Mon, 25 Mar 2024 14:43:44 -0700 (PDT) (envelope-from ehem)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c9f9bfc9-eaf0-11ee-a1ef-f123f15fe8a2
Date: Mon, 25 Mar 2024 14:43:44 -0700
From: Elliott Mitchell 
To: Jan Beulich 
Cc: xen-devel@lists.xenproject.org, Andrew Cooper ,
        Roger Pau =?iso-8859-1?Q?Monn=E9?= ,
        Wei Liu , Kelly Choi 
Subject: Re: Serious AMD-Vi(?) issue
Message-ID: 
References: 
 
 
 
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
X-Spam-Status: No, score=0.0 required=10.0 tests=KHOP_HELO_FCRDNS
	autolearn=unavailable autolearn_force=no version=4.0.0
X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on mattapan.m5p.com

On Mon, Mar 25, 2024 at 08:55:56AM +0100, Jan Beulich wrote:
> On 22.03.2024 20:22, Elliott Mitchell wrote:
> > On Fri, Mar 22, 2024 at 04:41:45PM +0000, Kelly Choi wrote:
> >>
> >> I can see you've recently engaged with our community with some issues you'd
> >> like help with.
> >> We love the fact you are participating in our project, however, our
> >> developers aren't able to help if you do not provide the specific details.
> > 
> > Please point to specific details which have been omitted.  Fairly little
> > data has been provided as fairly little data is available.  The primary
> > observation is large numbers of:
> > 
> > (XEN) AMD-Vi: IO_PAGE_FAULT: DDDD:bb:dd.f d0 addr ffffff???????000 flags 0x8 I
> > 
> > Lines in Xen's ring buffer.
> 
> Yet this is (part of) the problem: By providing only the messages that appear
> relevant to you, you imply that you know that no other message is in any way
> relevant. That's judgement you'd better leave to people actually trying to
> investigate. Unless of course you were proposing an actual code change, with
> suitable justification.

Honestly, I forgot about the very small number of messages from the SATA
subsystem.  The question of whether the current mitigation actions are
effective right now was a bigger issue.  As such monitoring `xl dmesg`
was a priority to looking at SATA messages which failed to reliably
indicate status.

I *thought* I would be able to retrieve those via other slow means, but a
different and possibly overlapping issue has shown up.  Unfortunately
this means those are no longer retrievable.   :-(

> In fact when running into trouble, the usual course of action would be to
> increase verbosity in both hypervisor and kernel, just to make sure no
> potentially relevant message is missed.

More/better information might have been obtained if I'd been engaged
earlier.

> > The most overt sign was telling the Linux kernel to scan for
> > inconsistencies and the kernel finding some.  The domain didn't otherwise
> > appear to notice trouble.
> > 
> > This is from memory, it would take some time to discover whether any
> > messages were missed.  Present mitigation action is inhibiting the
> > messages, but the trouble is certainly still lurking.
> 
> Iirc you were considering whether any of this might be a timing issue. Yet
> beyond voicing that suspicion, you didn't provide any technical details as
> to why you think so. Such technical details would include taking into
> account how IOMMU mappings and associated IOMMU TLB flushing are carried
> out. Right now, to me at least, your speculation in this regard fails
> basic sanity checking. Therefore the scenario that you're thinking of
> would need better describing, imo.

True.  Mostly I'm analyzing the known information and considering what
the patterns suggest.

Presently I'm aware of two reports (Imre Szőllősi and mine).

Both of these feature AMD processor machines.  Could be people with AMD
processors are less trustful of flash storage or could be an AMD-only
IOMMU issue.  Ideally someone would test and confirm there is no issue
with Linux software RAID1 on flash on an Intel machine.

Both reports feature two flash storage devices being run through Linux
MD RAID1.  Could be the MD RAID1 subsystem is abusing the DMA interface
in some fashion.  While Imre Szőllősi reported this not occuring with a
single device, the report does not explicitly state whether that was a
degenerate RAID1 versus non-RAID.  I'm unaware of any testing with 3x
devices in RAID1.


Both reports feature Samsung SATA flash devices.  My case also includes a
Crucial NVMe device.  My case also features a Crucial SATA flash device
for which the problem did NOT occur.  So the question becomes, why did
the problem not occur for this Crucial SATA device?

According to the specifications, the Crucial SATA device is roughly on
par with the Samsung SATA devices in terms of read/write speeds.  The
NVMe device's specifications are massively better.

What comes to mind is the Crucial SATA device might have higher latency
before executing commands.  Specifications don't mention command
execution latency, so it isn't possible to know whether this is the
issue.


Yes, latency/timing is speculation.  Does seem a good fit for the pattern
though.

This could be a Linux MD RAID1 bug or a Xen bug.

Unfortunately data loss is a very serious type of bug so I'm highly
reluctant to let go of mitigations without hope for progress.


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg@m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include  O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445




From xen-devel-bounces@lists.xenproject.org Tue Mar 26 01:21:39 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Mar 2024 01:21:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697909.1089153 (Exim 4.92)
	(envelope-from )
	id 1rovVE-0000M0-Lo; Tue, 26 Mar 2024 01:21:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697909.1089153; Tue, 26 Mar 2024 01:21:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rovVE-0000Lt-JA; Tue, 26 Mar 2024 01:21:24 +0000
Received: by outflank-mailman (input) for mailman id 697909;
 Tue, 26 Mar 2024 01:21:23 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rovVD-0000Ln-LI
 for xen-devel@lists.xenproject.org; Tue, 26 Mar 2024 01:21:23 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on20601.outbound.protection.outlook.com
 [2a01:111:f403:2414::601])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2707c99a-eb0f-11ee-a1ef-f123f15fe8a2;
 Tue, 26 Mar 2024 02:21:20 +0100 (CET)
Received: from BN9PR03CA0193.namprd03.prod.outlook.com (2603:10b6:408:f9::18)
 by PH7PR12MB9074.namprd12.prod.outlook.com (2603:10b6:510:2f4::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.31; Tue, 26 Mar
 2024 01:21:16 +0000
Received: from BN3PEPF0000B06D.namprd21.prod.outlook.com
 (2603:10b6:408:f9:cafe::1a) by BN9PR03CA0193.outlook.office365.com
 (2603:10b6:408:f9::18) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.13 via Frontend
 Transport; Tue, 26 Mar 2024 01:21:16 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN3PEPF0000B06D.mail.protection.outlook.com (10.167.243.72) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7452.0 via Frontend Transport; Tue, 26 Mar 2024 01:21:15 +0000
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Mon, 25 Mar
 2024 20:21:15 -0500
Received: from [10.65.148.173] (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Mon, 25 Mar 2024 20:21:13 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2707c99a-eb0f-11ee-a1ef-f123f15fe8a2
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=FzBQVSc2HlodjdFf5ivch/0919EResrLKWfLwR1XPZS9UiN4nALXkMf7uU7nUf0SBZb3smrIeI2Aa0+/NA6vttQCFGpyIyHSfo2WwU0aqSeDU359Nfc1WZf+sZwTDJMnagajo8/krA2xvB8pQoX1gO3nrPTQCpZ9yYgNDwOQEkHIRJxbROe2wFQ97QfDNIhY/O7rD5Q+Sf3IDWANFOHy8uqoJp0iBPp95guXD+f9ohPBnUUlm2H4rFP3YYiHxU7k27kzgqIDUBuXRb3BBbxvf2eSj1a2ssNkodvgYKP73XjyhInrczppF5+9jAkOMyidqm7RelJBJEUIzTpIMXmA6A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=56rv5jIdsX1029ySILFkHJT6Sgd+/aGmIVOaS3UsWYg=;
 b=Z0gPc+tyYECXTLGyDAkiooRkmLoKSUo33ZjJbY6ODmrPLUr8ZlSIAJMmFFqQDKjtQihblSY19LuNJ8cpAyHvt+nO7/5mMKmu1Q8h14SZuEq5II0sBYOmHfMbKPyNL2EX+xsc93eA93XI7SNmgFJl3YDZRCuahwh07vwGBBxT0VHTbOR4EG5Q0KlcY3RtAV7sq8dPT5WS3jAHusQZr8X+st/zPt5mL+rM2+qp0RLsl+nFD8cpSP2qp3lV/hBgRvkIEpbgHPPo36tevJrVkp/iDBlzvndS4PLW5LHB1wvyAZQvOPB+l8ja4452wWoaplXYX+qd4hSvr6CPpM1o2H/jWg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=cloud.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=56rv5jIdsX1029ySILFkHJT6Sgd+/aGmIVOaS3UsWYg=;
 b=WQrzklNTkBcu0ZwubTROuZxnsrDw0JFJCAOwnx3FJNCvChNi7yexJKvML+CuDd64+y+SwMvm2q/XwAKNpYYkRWOJDO+0Ks9PnCbPRBHzXjERRBpACRalaDTsfezza6d7DgaAQi/VvkVsVBxIgzVEtnEndmx5cWVDQ3xa83nnXBc=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Message-ID: <0518ae64-3139-4aaf-bbac-8e553481f4e4@amd.com>
Date: Tue, 26 Mar 2024 09:21:14 +0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 5/5] xen/memory, tools: Make init-dom0less consume
 XEN_DOMCTL_get_mem_map
To: Anthony PERARD 
CC: , Wei Liu , Andrew Cooper
	, George Dunlap , Jan
 Beulich , Julien Grall , Stefano
 Stabellini , Alec Kwapis 
References: <20240308015435.4044339-1-xin.wang2@amd.com>
 <20240308015435.4044339-6-xin.wang2@amd.com>
 <9162a331-645c-4e45-b5d0-57c6b9b4f79b@perard>
Content-Language: en-US
From: Henry Wang 
In-Reply-To: <9162a331-645c-4e45-b5d0-57c6b9b4f79b@perard>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB04.amd.com: xin.wang2@amd.com does not designate
 permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN3PEPF0000B06D:EE_|PH7PR12MB9074:EE_
X-MS-Office365-Filtering-Correlation-Id: a8658293-beb0-4bb4-50a1-08dc4d33085d
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	k5gpcc2DW0KD2j3SuMsOtPgwRiSxslfn06YDH70M1+nKsDrNpHbqZExZpSmlvlyQGKATmehkFnjilMMQDluRUv/1S3BeadPJXHzBF1a1Zi+F+MhCPgyoh98DrPFaWdD5i9pF3V9Myfo/1DuiomptKBwFDOGTAYWWFZzg0ZVEd/M22axf1P9oGop9TgSoYfUWB1u/U9TD7QhSCTr4M8cI6LBso7Uz4p7JwNr7rLeLOz8/AVZ9DMeg5Dpjl2OUa13B3zscaHnnQn2T87HYpz0nLsCNYIHfo8NDTBqrT8yNZ24Q1V5lwxMFTtD6CL50N4p8G8ddZE1KVi7zMvm2mSliK5ob2vSDv2nusxnzNtPum2eprmoxhmgab8AZ/Et+l6qb1LV4+nSStiYpW4SQ8ZRq7Kv24lDS5HQ04JMwW/Bgr+aWRojIav828F7kiETOQnIs19yxFWyvwUHOoh5rz1JQ5b6FyZEAsRH8Asokfycc41SXTogIzHYGgKEH/m7tvFISCNjvMvLZOUjblz+dapKNopHLa4yR+TYEuCCPA1ZSwwoha+IWPEV/Z28U3nzMC/KXS/tVt5H/vy4ZtkbgIZ4FtqsFriV99JYA1+gQPSYTVnkChuXk3HycB17ZWssDPEcQdPNo5fCRk3c9EQUfLKoV03nTBA7ueNAdGdgmaWhlQaszzc+Re2KdpnsYAujcLR6AUaVtUeHCSBkyO352swFWeyLs1KmfEhsyS85mPyVrSlgiQsJbtt+Q5bN/oTMRPAHd
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(36860700004)(1800799015)(82310400014)(376005);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Mar 2024 01:21:15.8303
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: a8658293-beb0-4bb4-50a1-08dc4d33085d
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN3PEPF0000B06D.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB9074

Hi Anthony,

On 3/25/2024 11:35 PM, Anthony PERARD wrote:
> On Fri, Mar 08, 2024 at 09:54:35AM +0800, Henry Wang wrote:
>> diff --git a/tools/helpers/init-dom0less.c b/tools/helpers/init-dom0less.c
>> index fee93459c4..92c612f6da 100644
>> --- a/tools/helpers/init-dom0less.c
>> +++ b/tools/helpers/init-dom0less.c
>> @@ -23,16 +23,30 @@ static int alloc_xs_page(struct xc_interface_core *xch,
>>                            libxl_dominfo *info,
>>                            uint64_t *xenstore_pfn)
>>   {
>> -    int rc;
>> -    const xen_pfn_t base = GUEST_MAGIC_BASE >> XC_PAGE_SHIFT;
>> -    xen_pfn_t p2m = (GUEST_MAGIC_BASE >> XC_PAGE_SHIFT) + XENSTORE_PFN_OFFSET;
>> +    int rc, i;
>> +    xen_pfn_t base = ((xen_pfn_t)-1);
>> +    xen_pfn_t p2m = ((xen_pfn_t)-1);
>> +    uint32_t nr_regions = XEN_MAX_MEM_REGIONS;
>> +    struct xen_mem_region mem_regions[XEN_MAX_MEM_REGIONS] = {0};
>> +
>> +    rc = xc_get_domain_mem_map(xch, info->domid, mem_regions, &nr_regions);
> Shouldn't you check the value of in `rc`?
Yes I should have done so. I will do that in the next version. Thanks! 
Kind regards, Henry


From xen-devel-bounces@lists.xenproject.org Tue Mar 26 05:16:33 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Mar 2024 05:16:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697915.1089164 (Exim 4.92)
	(envelope-from )
	id 1rozAP-0002D7-42; Tue, 26 Mar 2024 05:16:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697915.1089164; Tue, 26 Mar 2024 05:16:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rozAP-0002D0-1K; Tue, 26 Mar 2024 05:16:09 +0000
Received: by outflank-mailman (input) for mailman id 697915;
 Tue, 26 Mar 2024 05:16:08 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rozAO-0002Cu-AQ
 for xen-devel@lists.xenproject.org; Tue, 26 Mar 2024 05:16:08 +0000
Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com
 [2a00:1450:4864:20::32f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f299071f-eb2f-11ee-afe3-a90da7624cb6;
 Tue, 26 Mar 2024 06:16:06 +0100 (CET)
Received: by mail-wm1-x32f.google.com with SMTP id
 5b1f17b1804b1-4148c72db39so5059325e9.0
 for ; Mon, 25 Mar 2024 22:16:06 -0700 (PDT)
Received: from localhost.localdomain (82-64-138-184.subs.proxad.net.
 [82.64.138.184]) by smtp.googlemail.com with ESMTPSA id
 w9-20020a05600c474900b00414896b61e4sm5454883wmo.16.2024.03.25.22.16.04
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 25 Mar 2024 22:16:05 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f299071f-eb2f-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=rabbit-lu.20230601.gappssmtp.com; s=20230601; t=1711430166; x=1712034966; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:from:to:cc:subject:date:message-id:reply-to;
        bh=GczBXsnaLCm9zzJ7Qenf5gqQ5Emssgxzk7laDgeG0r8=;
        b=X4uoSCd9ZifbO1jZZotAvzIHL02OwfIASLlb0XoMGYW1de7+NjXEYuz6vaTVSKlS3u
         VaZSQ47DxgVqEDH6SZh7ysP/MN54kzSodq6eZaREmxYaOXnBLRh29jBi4ucEdY+9wjBH
         6fWa6Q471UNeMdUFWPtfuBmaTyA/sqYYHKE+R7rilDgx4VQRHPdSsd402BjJeK5XfT34
         X/eiimWAqglrkqkyvFk10hH489PlXe2xWRI+ZyR/+KULosv5adL4oCQBfDwXwAsWS9uI
         24dvlitEHuPfpOIRoYETrzoWpina6KNy2STfQ7yv4p4xfpa+wC+ogLRDiiHRcVqKmZJF
         V1Cw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711430166; x=1712034966;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=GczBXsnaLCm9zzJ7Qenf5gqQ5Emssgxzk7laDgeG0r8=;
        b=ivdVT49wN3cRYY5/Y3tr1QvllA3Kiykg65tJOVo9XHh7Igo2Dcf4T3EeLhGduQK7Xf
         cMHv92y4QZGnjv5uJCxT6DhNpjbLXBN4cxfvtdyUINJGQYALEdAN++x3J9RhxwDSMpwl
         88ddPQJet+dVwRtJKgPx3b15BbeESQxW1/1tWu+G10IqpCUUTQ1J5ye2VPxGh0vQmkpQ
         VXHKYfwQgJTMCBehE7a1V0yLjMW8jbOcWgIfu6cRPfssG9o0jJWZpU9U6Aj1PQbbTv/g
         H51lvR5fY7hm7/XMIXcbCQKiiS+beJQBRoKI0A5PakHf275I9BsG0CKnwy3kaT/EOTmz
         3IOA==
X-Gm-Message-State: AOJu0YwY3qneojsN78jb09nAUJc1BsfHmQ6GtGbowN2kCnlaL4iNDe57
	FqsBjYPwixRzLq+BJg+2SuLGJysS0qFG1OL7MyiIZiXgDW/lXhaBZwstCpzclk7FXpNVVL1AYV3
	G
X-Google-Smtp-Source: AGHT+IF0iOmiWS03lS2E6p2hcmprpl1Hcf/kBWFSmIvEUB2BD26U56rKwWAvmxCReLpsnnDtYQiS9Q==
X-Received: by 2002:a05:600c:1d14:b0:414:7431:6983 with SMTP id l20-20020a05600c1d1400b0041474316983mr47463wms.25.1711430165600;
        Mon, 25 Mar 2024 22:16:05 -0700 (PDT)
From: =?UTF-8?q?zithro=20/=20Cyril=20R=C3=A9bert?= 
To: xen-devel@lists.xenproject.org
Cc: =?UTF-8?q?zithro=20/=20Cyril=20R=C3=A9bert?= ,
	Leigh Brown ,
	Andrew Cooper ,
	Anthony PERARD 
Subject: [PATCH] tools/misc: fix xenwatchdogd invocation
Date: Tue, 26 Mar 2024 06:15:45 +0100
Message-Id: <6f5b09d7bdc555227e7a5e55aa090171fba070f8.1711430145.git.slack@rabbit.lu>
X-Mailer: git-send-email 2.39.2
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

When xenwatchdogd is invoked with -h/--help (or any non-number), the
argument value is converted to 0, which immediately shutdowns dom0.

So make sure only numbers are passed to the program, otherwise fail.
For the help, use getopt_long as suggested.
While there, reformat the code a bit (s/tabs/spaces/, indentation, etc).

Bug fix only, no functional change intended.

Reported-by: Leigh Brown 
Suggested-by: Andrew Cooper 
Signed-off-by: Cyril Rébert / zithro 
---
- Not sure about the preprocessor stanzas, copied them from xentop.
- A small explanation about what the program does could be helpful,
  like some kind of synopsis ? Purpose, gotchas, etc. I can do the
  writing, but please be specific !
- Built on 4.17 and unstable, tested on 4.17.
---
 tools/misc/xenwatchdogd.c | 77 +++++++++++++++++++++++++++++----------
 1 file changed, 57 insertions(+), 20 deletions(-)

diff --git a/tools/misc/xenwatchdogd.c b/tools/misc/xenwatchdogd.c
index 254117b554..6ef5eaf45c 100644
--- a/tools/misc/xenwatchdogd.c
+++ b/tools/misc/xenwatchdogd.c
@@ -8,26 +8,34 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
+#define _GNU_SOURCE
+#include 
+#if !defined(__GNUC__) && !defined(__GNUG__)
+#define __attribute__(arg) /* empty */
+#endif
+
 xc_interface *h;
 int id = 0;
 
 void daemonize(void)
 {
     switch (fork()) {
-    case -1:
-	err(1, "fork");
-    case 0:
-	break;
-    default:
-	exit(0);
+        case -1:
+            err(1, "fork");
+        case 0:
+            break;
+        default:
+            exit(0);
     }
+
     umask(0);
     if (setsid() < 0)
-	err(1, "setsid");
+        err(1, "setsid");
     if (chdir("/") < 0)
-	err(1, "chdir /");
+        err(1, "chdir /");
     if (freopen("/dev/null", "r", stdin) == NULL)
         err(1, "reopen stdin");
     if(freopen("/dev/null", "w", stdout) == NULL)
@@ -52,39 +60,68 @@ void catch_usr1(int sig)
 
 int main(int argc, char **argv)
 {
+
     int t, s;
     int ret;
+    
+    char *usage = "usage: %s  ";
+    int opt, optind = 0;
+
+    struct option lopts[] = {
+        { "help",          no_argument,       NULL, 'h' },
+    };
+    const char *sopts = "h";
+
+    while ((opt = getopt_long(argc, argv, sopts, lopts, &optind)) != -1) {
+        switch (opt) {
+        case '?':
+        case 'h':
+            errx(1, usage, argv[0]);
+            break;
+        default:
+            errx(1, usage, argv[0]);
+        }
+    }
 
     if (argc < 2)
-	errx(1, "usage: %s  ", argv[0]);
+        errx(1, usage, argv[0]);
 
     daemonize();
 
     h = xc_interface_open(NULL, NULL, 0);
     if (h == NULL)
-	err(1, "xc_interface_open");
+        err(1, "xc_interface_open");
+
+    t = strtoul(argv[1], &argv[1], 0);
+    
+    // argv1 NaN
+    if ( *argv[1] != '\0' )
+        errx(1, "Error: timeout must be a number, got '%s'", argv[1]);
 
-    t = strtoul(argv[1], NULL, 0);
     if (t == ULONG_MAX)
-	err(1, "strtoul");
+        err(1, "strtoul");
 
     s = t / 2;
     if (argc == 3) {
-	s = strtoul(argv[2], NULL, 0);
-	if (s == ULONG_MAX)
-	    err(1, "strtoul");
+        s = strtoul(argv[2], &argv[2], 0);
+        // argv2 NaN
+        if ( *argv[2] != '\0' ){
+            errx(1, "Error: sleep must be a number, got '%s'", argv[2]);
+        }
+        if (s == ULONG_MAX)
+            err(1, "strtoul");
     }
 
     if (signal(SIGHUP, &catch_exit) == SIG_ERR)
-	err(1, "signal");
+        err(1, "signal");
     if (signal(SIGINT, &catch_exit) == SIG_ERR)
-	err(1, "signal");
+        err(1, "signal");
     if (signal(SIGQUIT, &catch_exit) == SIG_ERR)
-	err(1, "signal");
+        err(1, "signal");
     if (signal(SIGTERM, &catch_exit) == SIG_ERR)
-	err(1, "signal");
+        err(1, "signal");
     if (signal(SIGUSR1, &catch_usr1) == SIG_ERR)
-	err(1, "signal");
+        err(1, "signal");
 
     id = xc_watchdog(h, 0, t);
     if (id <= 0)
-- 
2.39.2



From xen-devel-bounces@lists.xenproject.org Tue Mar 26 06:51:45 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Mar 2024 06:51:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697922.1089174 (Exim 4.92)
	(envelope-from )
	id 1rp0eh-0005QI-RF; Tue, 26 Mar 2024 06:51:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697922.1089174; Tue, 26 Mar 2024 06:51:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rp0eh-0005QB-Nd; Tue, 26 Mar 2024 06:51:31 +0000
Received: by outflank-mailman (input) for mailman id 697922;
 Tue, 26 Mar 2024 06:51:31 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rp0eh-0005Q1-83; Tue, 26 Mar 2024 06:51:31 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rp0eg-0005QY-Si; Tue, 26 Mar 2024 06:51:30 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rp0eg-0004Hu-HA; Tue, 26 Mar 2024 06:51:30 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rp0eg-0003PF-Gf; Tue, 26 Mar 2024 06:51:30 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=iJn5myygnxtHSrBUgILfSIE+NqUKpEVuF3nyPOspYjI=; b=KFcTnbeaO6TDqnoeupISUoguUm
	Jz2F269LoaaQfywdFM0b7y5kuX2+bB8BIchPHhKdaCuugUCpBHNyyb+4VY4pjTGUkJVUOlyKlh0A0
	h8/NJZ/GeBF32iCMGiw7Fv+2n66pfic6XErdY4piDYBYgg5mPa+qqbyMZrgRweKOZwX8=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 185160: tolerable FAIL - PUSHED
X-Osstest-Failures:
    linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-qcow2:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-qcow2:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-raw:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-vhd:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    linux=928a87efa42302a23bb9554be081a28058495f22
X-Osstest-Versions-That:
    linux=4cece764965020c22cff7665b18a012006359095
From: osstest service owner 
Date: Tue, 26 Mar 2024 06:51:30 +0000

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

Failures :-/ but no regressions.

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

version targeted for testing:
 linux                928a87efa42302a23bb9554be081a28058495f22
baseline version:
 linux                4cece764965020c22cff7665b18a012006359095

Last test of basis   185155  2024-03-25 03:25:27 Z    1 days
Testing same since   185160  2024-03-25 18:44:17 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andreas Gruenbacher 
  Andrew Price 
  Eric Biggers 
  Herbert Xu 
  Karel Balej 
  Linus Torvalds 
  Tom Zanussi 

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-libvirt-qcow2                               pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-xl-qcow2                                    pass    
 test-amd64-amd64-libvirt-raw                                 pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-amd64-amd64-xl-raw                                      pass    
 test-armhf-armhf-xl-raw                                      pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-libvirt-vhd                                 pass    
 test-amd64-amd64-xl-vhd                                      pass    
 test-arm64-arm64-xl-vhd                                      pass    


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

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

Explanation of these 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 :

hint: The 'hooks/update' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
hint: The 'hooks/post-receive' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
hint: The 'hooks/post-update' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
To xenbits.xen.org:/home/xen/git/linux-pvops.git
   4cece7649650..928a87efa423  928a87efa42302a23bb9554be081a28058495f22 -> tested/linux-linus


From xen-devel-bounces@lists.xenproject.org Tue Mar 26 07:16:51 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Mar 2024 07:16:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697929.1089184 (Exim 4.92)
	(envelope-from )
	id 1rp134-0008It-T8; Tue, 26 Mar 2024 07:16:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697929.1089184; Tue, 26 Mar 2024 07:16:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rp134-0008Im-QM; Tue, 26 Mar 2024 07:16:42 +0000
Received: by outflank-mailman (input) for mailman id 697929;
 Tue, 26 Mar 2024 07:16:42 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rp134-0008Ig-Aw
 for xen-devel@lists.xenproject.org; Tue, 26 Mar 2024 07:16:42 +0000
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com
 [2a00:1450:4864:20::229])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ca1fd531-eb40-11ee-a1ef-f123f15fe8a2;
 Tue, 26 Mar 2024 08:16:40 +0100 (CET)
Received: by mail-lj1-x229.google.com with SMTP id
 38308e7fff4ca-2d28051376eso96243151fa.0
 for ; Tue, 26 Mar 2024 00:16:40 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 o1-20020a1709061d4100b00a46b4c09670sm3861077ejh.131.2024.03.26.00.16.11
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 26 Mar 2024 00:16:11 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ca1fd531-eb40-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711437399; x=1712042199; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=j0fpi6fkdr8wOE7Wb0Lo5jHxkynaY+qqzi3trvAnl7Q=;
        b=fBXS4AcFYR2PVaY0GfSAGHHsHc8AuyWU2Ciqahu8KV+m1IxSt5LZYpRffwFHGkvMLq
         K/aXYCMSxhL8wPg6EyVkOmvWFoQUgGlj/s+J05NCjrHmZtvkvASydKEF5kuhVM1XQ46j
         5SjuZr/uglR6ivUJ5Evt/gY7iJLOhH/PTwr2ycAqEnyTcIhfzlIxBqtguZ1fb7GkSh5w
         oD5MgWIWuAUntj10hHU0Df2mHECTa/W07peBmtf4MdRpE6f2CKXbzHBBj39c3KmYbtrI
         0cQSiNQQgkZGz5Ro39UAc1193ZLMN0TGTll04pfJg1RJuV6JTMrAquL0C2wQxWHw1e//
         Ok7Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711437399; x=1712042199;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=j0fpi6fkdr8wOE7Wb0Lo5jHxkynaY+qqzi3trvAnl7Q=;
        b=hM6RiZk2Se+jezJ7Qd32p9fSPBDv8BpOnW8cetUv//ItzmpBE9YudJLIwwNjzHHm+W
         +71VpE0QghUHb1DSXfLQjcfGFH+jO/iEkB5R+VQIM8fJd5bbg7lrOfY6BzvgxcjTDJl8
         LHdwfKOK8ghv/4ioKavjeLxXP4PKtofVPEV2jwlQHd8kDnFTyh3ElkzWJSDgfDjSgV8F
         2AjT7lBZZlQKSu3iN6Fv5i6ufjBYt9y53wq3Dq4F08PPmspom59ViSxYbpS0zaKH2TOk
         JFd4zuhhcIE3iUmNm1J+ke4oJoHPbgnhPBtPL5BzZUQ9a4SNLv5ciAa/arxRjaXBM0Qa
         LS5Q==
X-Forwarded-Encrypted: i=1; AJvYcCUbUe7+h3pe9mxRdwcMEcQOFY9WmU5Tcr2Zh6x4Dntil3Vr3Anw0ips6Xnvsftvpif6Nw5PeYdHGVmvUtufRqc5TOR8CU/2CEolE6dPBKY=
X-Gm-Message-State: AOJu0YzbZRRFqrO7wr92RV/Ja3cyw0Up1clMN8xCU5zN7T3E/1B855sn
	z8BJrKJkB/3M6OLpPSGilB5O0MDt496NYRjN3JBx0KckWLC+ZkE7VYlSLkNZl8MV4TsUCNtcSWA
	=
X-Google-Smtp-Source: AGHT+IFYGaFReatHIA/LQ/B6eMCy0VXk52Hu6A0IvtFwAg+xs4+uIYszzOLQ2I+spECAGvdypUX5bA==
X-Received: by 2002:a05:6512:21c:b0:513:e031:739a with SMTP id a28-20020a056512021c00b00513e031739amr7261843lfo.22.1711437373372;
        Tue, 26 Mar 2024 00:16:13 -0700 (PDT)
Message-ID: 
Date: Tue, 26 Mar 2024 08:16:10 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/6] xen/x86: Add initial x2APIC ID to the per-vLAPIC save
 area
Content-Language: en-US
To: Alejandro Vallejo 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Xen-devel 
References: <20240109153834.4192-1-alejandro.vallejo@cloud.com>
 <20240109153834.4192-2-alejandro.vallejo@cloud.com>
 <2e7fe91e-b483-4d61-9783-0cfa3753911f@suse.com>
 <19a4cf14-92c9-47e5-b8f0-f07a92a1ffd8@cloud.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <19a4cf14-92c9-47e5-b8f0-f07a92a1ffd8@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 25.03.2024 19:00, Alejandro Vallejo wrote:
> On 25/03/2024 16:45, Jan Beulich wrote:
>> On 09.01.2024 16:38, Alejandro Vallejo wrote:
>>> @@ -1514,6 +1530,13 @@ static void lapic_load_fixup(struct vlapic *vlapic)
>>>      const struct vcpu *v = vlapic_vcpu(vlapic);
>>>      uint32_t good_ldr = x2apic_ldr_from_id(vlapic->loaded.id);
>>>  
>>> +    /*
>>> +     * Guest with hardcoded assumptions about x2apic_id <-> vcpu_id
>>> +     * mappings. Recreate the mapping it used to have in old host.
>>> +     */
>>> +    if ( !vlapic->hw.x2apic_id )
>>> +        vlapic->hw.x2apic_id = v->vcpu_id * 2;
>>
>> This looks to depend upon it only ever being vCPU which may get a (new
>> style) APIC ID of 0. I think such at least wants mentioning in the
>> comment.
> 
> I don't quite follow you, I'm afraid. There is an implicit control flow
> assumption that I can extract into a comment (I assume you were going
> for that angle?). The implicit assumption that "vCPU0 always has
> APIC_ID=0", which makes vCPU0 go through that path even when no
> corrections are necessary. It's benign because it resolves to APIC_ID 0.
> 
> Is that what you meant? If so, I'll add it to v2.

Yes, and even in your reply you make the same assumption without further
explanation. It does not go without saying that vCPU 0 necessarily has
APIC ID 0. On bare metal that may be what one can typically observe, but
I'm unaware of any architectural guarantees to this effect.

>>> --- a/xen/include/public/arch-x86/hvm/save.h
>>> +++ b/xen/include/public/arch-x86/hvm/save.h
>>> @@ -394,6 +394,8 @@ struct hvm_hw_lapic {
>>>      uint32_t             disabled; /* VLAPIC_xx_DISABLED */
>>>      uint32_t             timer_divisor;
>>>      uint64_t             tdt_msr;
>>> +    uint32_t             x2apic_id;
>>> +    uint32_t             rsvd_zero;
>>>  };
>>
>> I can't spot any checking of this last field indeed being zero.
> 
> Huh. I was sure I zeroed that on vlapic_init(), but it must've been on a
> previous discarded series. Good catch.

No, explicit zeroing isn't needed, simply because all of struct vcpu
starts out zeroed.

> Do we also want a check on migrate so a migration from a future Xen in
> which it's not zero fails?

It's really only this that I meant. Recall we now even have a dedicated
checking hook, running ahead of any state loading.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Mar 26 07:30:57 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Mar 2024 07:30:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697934.1089193 (Exim 4.92)
	(envelope-from )
	id 1rp1Gm-0002j6-0b; Tue, 26 Mar 2024 07:30:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697934.1089193; Tue, 26 Mar 2024 07:30:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rp1Gl-0002iz-UL; Tue, 26 Mar 2024 07:30:51 +0000
Received: by outflank-mailman (input) for mailman id 697934;
 Tue, 26 Mar 2024 07:30:50 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rp1Gk-0002it-Tx
 for xen-devel@lists.xenproject.org; Tue, 26 Mar 2024 07:30:50 +0000
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com
 [2a00:1450:4864:20::635])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c4b31124-eb42-11ee-afe3-a90da7624cb6;
 Tue, 26 Mar 2024 08:30:49 +0100 (CET)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-a467d8efe78so615122466b.3
 for ; Tue, 26 Mar 2024 00:30:49 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 m21-20020a17090679d500b00a4739efd7cesm3946656ejo.60.2024.03.26.00.30.48
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 26 Mar 2024 00:30:49 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c4b31124-eb42-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711438249; x=1712043049; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=vY6lfL+FD2/BZpYC8TH1rYKbp15hqcnqajBcGqcjOzw=;
        b=Alt2hDJgN3sH6Q6bHOxpF/yBwOTd7SJ3YuwHfpOc2SlVnQyIEw9chb3fM5mPGlMWF3
         zPhd4F4yv9Eon9JaKiKLq3u0taTsRlqZQZUCt7rM6Q9wmXVfKEJEvaNK/lhIuBuNJvJs
         Xr2yVzERvDJ6R0h69DLMZ/FTCSy8QQEyvbVIagrs/XW3ik9/mokK76EDcPFEVpME93XT
         RE9BW1rs7s6kkm64TCZORJ7BDg5jORR5gW+umYIikBCHF2s5eJn1ZKWjDDPScOG6HqMv
         /ZVJ/DVEAU6mbiUiHngQWji/ijbjI7OiWx+5Xra7ptSCnTaM+nhFzGeklEyKqxes77hN
         y7Lg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711438249; x=1712043049;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=vY6lfL+FD2/BZpYC8TH1rYKbp15hqcnqajBcGqcjOzw=;
        b=l1qAKRqEbzBdD8rNwU5OkY8dOErVopGLx9a38lNq9dKEN2Cm4XQVhJ00IfCK+45WYp
         5PBVIUt3eG5NevW6FSVDObHbt8x4ezLIlC/g7xFs0CYEHy4y3sLtwMLyvFyXqWhA5FJ8
         ydvLz/c3VpPseLbY+ahT3Y3DXyqLOnJV17NQlKW1g9cm7ftWkHouYK35EMDFy/gSo6XW
         vRsYpWH487moLpFIwCPo7y2Qa56OICZo3Tr/Gz6mWo4NeozZ/fwUrLSPtPYSkGTSIh8j
         e24bRv7sXnWpp1QHhxBTzRhmBTf/oV9JRRrS3Vc4FCgjXQQtxhu97y3MVzd9fwl+NGfH
         eeHg==
X-Forwarded-Encrypted: i=1; AJvYcCXT53gRjZA5/ilFHHRzHnD5352D83+TaZkwCth6yk1ITXBushdDKdawI+bolTxDl24tgN+OwJeAjAKDNHUb3mVynzM6nEaz47OSLFYar0M=
X-Gm-Message-State: AOJu0YyIxVe0zgxHF1vuUrBf/wcOCOVRxgPcq5tGpJMKt+fP5DFb+nzM
	GrWoE/Q1Xq22u3WYvXIPfZTUL36AJb5ddg2Xwc6OXrAteoH13iScRBkvf0Y1rg==
X-Google-Smtp-Source: AGHT+IFuPHrzEvS6fePHcXM5JcU5A75Uvc6euw9Oh3jUe6qCu7nsExuaixLLYdmTq1KuwIafsHOOTg==
X-Received: by 2002:a17:906:2555:b0:a46:420f:8ecb with SMTP id j21-20020a170906255500b00a46420f8ecbmr5593295ejb.62.1711438249215;
        Tue, 26 Mar 2024 00:30:49 -0700 (PDT)
Message-ID: <2d39b5da-8d9f-41de-a0aa-25f0d9ac8f31@suse.com>
Date: Tue, 26 Mar 2024 08:30:48 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 3/5] tools: Move MB/GB() to common-macros.h
Content-Language: en-US
To: Jason Andryuk 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Anthony PERARD , Juergen Gross ,
 Julien Grall , xen-devel@lists.xenproject.org
References: <20240325204515.250203-1-jason.andryuk@amd.com>
 <20240325204515.250203-4-jason.andryuk@amd.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240325204515.250203-4-jason.andryuk@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 25.03.2024 21:45, Jason Andryuk wrote:
> Consolidate to a single set of common macros for tools.
> 
> MB() will gain another use in libelf, so this movement makes it
> available.
> 
> Signed-off-by: Jason Andryuk 

Reviewed-by: Jan Beulich 
(and perhaps also Requested-by: or some such)



From xen-devel-bounces@lists.xenproject.org Tue Mar 26 07:50:17 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Mar 2024 07:50:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697938.1089204 (Exim 4.92)
	(envelope-from )
	id 1rp1ZU-0005bS-Gg; Tue, 26 Mar 2024 07:50:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697938.1089204; Tue, 26 Mar 2024 07:50:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rp1ZU-0005bL-Di; Tue, 26 Mar 2024 07:50:12 +0000
Received: by outflank-mailman (input) for mailman id 697938;
 Tue, 26 Mar 2024 07:50:11 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rp1ZT-0005bF-2t
 for xen-devel@lists.xenproject.org; Tue, 26 Mar 2024 07:50:11 +0000
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com
 [2a00:1450:4864:20::530])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7825fa13-eb45-11ee-afe3-a90da7624cb6;
 Tue, 26 Mar 2024 08:50:09 +0100 (CET)
Received: by mail-ed1-x530.google.com with SMTP id
 4fb4d7f45d1cf-55a179f5fa1so6642592a12.0
 for ; Tue, 26 Mar 2024 00:50:09 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ef3-20020a05640228c300b0056bfb4a94e9sm3400666edb.59.2024.03.26.00.50.08
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 26 Mar 2024 00:50:08 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7825fa13-eb45-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711439409; x=1712044209; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=f/jmwi6rAQXG/0H9SKQLSZy/Ddk3hDPj7z/9OHxZvmk=;
        b=YeIYakldCyl+VQcY7HhjP9+EsiMjGWPOfjds8Eb4kdZpH3sZP/VRGafITzRcE8T/zb
         rXoudVMZ/TtrgoCrVe+ZlA917mx+HBh6sgBGIVLc5j8jLUALquSqf+yXoOOjBpvx1UXc
         vkr+JZT9inQ3hDOizqeo1i/pl8QEv228zQJdnhyR3ymQGUgcHYVrZ27yZlv/Zc9zbkzb
         ebt/Z+N03An+/GzM8A0SbLZVETvsojRCV9xINimGhjBnS8H50Zk8/Xpa9f+TGq85bl2I
         GgpMnUx4Qk1hSbJ68pqrOkof+cdalCP9jyc56CWgrkh3KbcHejCpwVUBmkUgcYLts6bn
         0ZdQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711439409; x=1712044209;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=f/jmwi6rAQXG/0H9SKQLSZy/Ddk3hDPj7z/9OHxZvmk=;
        b=c8HVR9BxM8sMdnF5ByJfZgO9SdhTFkq/kSo01lhpqxkxiXJfxxOW+ffv6uKXqXE+Qz
         swIhLmB5jAtOV0X0rOtE6ud+E5rHvqoDUpHwljRX1bLu4N734fIr0iIlx6IYwOa3chr2
         wPfy5ajvzMQmSwLZ8u6RR1qNfYuAqMM78ek+wM9+4DHNBPzxu6hEp4Cs1be3Ok+RX8bT
         21wYg6TE5Kp6vvaR/ZlaFf6Q1NiOOGPvJP2GaKOg8DGsQuHQfOAGAHmGCGNp8GwRtXoR
         PlX/y72d4EsoWz8fTbsGme3V5O/uwllbqCUcRwoW8e7qOkiYAZ9H4roNJfN6nY4ePS/H
         w6ig==
X-Forwarded-Encrypted: i=1; AJvYcCVcf/3OW+/EIVNValkcQBuYoUIW6efsP8ZR6jTdGVvh3/Y8Sg2MLlhDlUGrCVO/Hh1RvfXtZzCOY2vQtZvtJeKRtFxOCT5b27tT68KlzM8=
X-Gm-Message-State: AOJu0YyV6v3EgwoS9v3RF3nHEAZuMOI7d8gZOfAfoqPZpQ8LbyXQzzhI
	I7XrbM08qoEmZHXuILShV6EAZOVcdWrtjMAFTV1Dyrg82iAR7mlJjTENQU89iOtXey2Enu6yzDI
	=
X-Google-Smtp-Source: AGHT+IHVuPyI/ClmafiKfWlADKP95sUlVrInKalfasJJi55vx8p9g4k30SwpFGD5vMAFT6ASfaBmjQ==
X-Received: by 2002:a50:9341:0:b0:566:e3c7:921f with SMTP id n1-20020a509341000000b00566e3c7921fmr7865313eda.22.1711439409197;
        Tue, 26 Mar 2024 00:50:09 -0700 (PDT)
Message-ID: <770d3292-34cf-4e21-acb6-bd1f9caf5fef@suse.com>
Date: Tue, 26 Mar 2024 08:50:07 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 5/5] x86/PVH: Support relocatable dom0 kernels
Content-Language: en-US
To: Jason Andryuk 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20240325204515.250203-1-jason.andryuk@amd.com>
 <20240325204515.250203-6-jason.andryuk@amd.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240325204515.250203-6-jason.andryuk@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 25.03.2024 21:45, Jason Andryuk wrote:
> +/* Find an e820 RAM region that fits the kernel at a suitable alignment. */
> +static paddr_t __init find_kernel_memory(
> +    const struct domain *d, struct elf_binary *elf,
> +    const struct elf_dom_parms *parms)
> +{
> +    paddr_t kernel_size = elf->dest_size;
> +    unsigned int i;
> +
> +    for ( i = 0; i < d->arch.nr_e820; i++ )
> +    {
> +        paddr_t start = d->arch.e820[i].addr;
> +        paddr_t end = start + d->arch.e820[i].size;
> +        paddr_t kstart, kend;
> +
> +        if ( d->arch.e820[i].type != E820_RAM ||
> +             d->arch.e820[i].size < kernel_size )
> +            continue;
> +
> +        kstart = ROUNDUP(start, parms->phys_align);
> +        kstart = max_t(paddr_t, kstart, parms->phys_min);
> +        kend = kstart + kernel_size;
> +
> +        if ( kend - 1 > parms->phys_max )
> +            return 0;
> +
> +        if ( kend <= end )
> +            return kstart;

IOW within a suitable region the lowest suitable part is selected. Often
low memory is deemed more precious than higher one, so if this choice is
indeed intentional, I'd like to ask for a brief comment towards the
reasons.

> --- a/xen/common/libelf/libelf-dominfo.c
> +++ b/xen/common/libelf/libelf-dominfo.c
> @@ -17,6 +17,16 @@
>  
>  #include "libelf-private.h"
>  
> +#if defined(__i386__) || defined(__x86_64__)
> +#define ARCH_PHYS_MIN_DEFAULT   0;
> +#define ARCH_PHYS_MAX_DEFAULT   (GB(4) - 1);
> +#define ARCH_PHYS_ALIGN_DEFAULT MB(2);
> +#else
> +#define ARCH_PHYS_MIN_DEFAULT   0;
> +#define ARCH_PHYS_MAX_DEFAULT   0;
> +#define ARCH_PHYS_ALIGN_DEFAULT 0;
> +#endif

None of the semicolons should really be here.

> @@ -227,6 +239,27 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
>      case XEN_ELFNOTE_PHYS32_ENTRY:
>          parms->phys_entry = val;
>          break;
> +
> +    case XEN_ELFNOTE_PHYS32_RELOC:
> +        parms->phys_reloc = true;
> +
> +        if ( descsz >= 4 )
> +        {
> +            parms->phys_max = elf_note_numeric_array(elf, note, 4, 0);
> +            elf_msg(elf, " = max: %#"PRIx32, parms->phys_max);

As indicated before, I consider the = here a little odd.

> +        }
> +        if ( descsz >= 8 )
> +        {
> +            parms->phys_min = elf_note_numeric_array(elf, note, 4, 1);
> +            elf_msg(elf, " min: %#"PRIx32, parms->phys_min);
> +        }
> +        if ( descsz >= 12 )
> +        {
> +            parms->phys_align = elf_note_numeric_array(elf, note, 4, 2);
> +            elf_msg(elf, " align: %#"PRIx32, parms->phys_align);
> +        }

I'd like us to reconsider this ordering: I'm inclined to say that MAX isn't
the most likely one a guest may find a need to use. Instead I'd expect both
MIN and ALIGN wanting to be given higher priority; what I'm less certain
about is the ordering between the two. To keep MIN and MAX adjacent, how
about ALIGN, MIN, MAX?

> --- a/xen/include/public/elfnote.h
> +++ b/xen/include/public/elfnote.h
> @@ -194,10 +194,27 @@
>   */
>  #define XEN_ELFNOTE_PHYS32_ENTRY 18
>  
> +/*
> + * Physical loading constraints for PVH kernels
> + *
> + * The presence of this note indicates the kernel supports relocating itself.
> + *
> + * The note may include up to three 32bit values to place constraints on the
> + * guest physical loading addresses and alignment for a PVH kernel.  Values
> + * are read in the following order:
> + *  - a maximum address for the entire image to be loaded below (default
> + *      0xffffffff)

"below" isn't exactly true anymore with this now being an inclusive value.
Perhaps "up to", or perhaps more of a re-wording.

I also think the wrapped line's indentation is too deep (by 2 blanks).

> + *  - a minimum address for the start of the image (default 0)
> + *  - a required start alignment (default 0x200000)
> + *
> + *  This note is only valid for x86 binaries.

Maybe s/valid/recognized/ (or honored or some such)?

Jan


From xen-devel-bounces@lists.xenproject.org Tue Mar 26 07:52:05 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Mar 2024 07:52:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697940.1089214 (Exim 4.92)
	(envelope-from )
	id 1rp1bB-00067Q-Rk; Tue, 26 Mar 2024 07:51:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697940.1089214; Tue, 26 Mar 2024 07:51:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rp1bB-00067J-Oq; Tue, 26 Mar 2024 07:51:57 +0000
Received: by outflank-mailman (input) for mailman id 697940;
 Tue, 26 Mar 2024 07:51:56 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rp1bA-00067D-1h
 for xen-devel@lists.xenproject.org; Tue, 26 Mar 2024 07:51:56 +0000
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com
 [2a00:1450:4864:20::136])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b7111c04-eb45-11ee-afe3-a90da7624cb6;
 Tue, 26 Mar 2024 08:51:55 +0100 (CET)
Received: by mail-lf1-x136.google.com with SMTP id
 2adb3069b0e04-513ccc70a6dso8937963e87.1
 for ; Tue, 26 Mar 2024 00:51:55 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 v5-20020a1709061dc500b00a46e2f89a9csm3919559ejh.32.2024.03.26.00.51.54
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 26 Mar 2024 00:51:54 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b7111c04-eb45-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711439515; x=1712044315; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=nY62mL7e9ntXnjEq/w6d5JyG5A14j1SSjlMr7TSXSvQ=;
        b=BvY5qdMlP24WQLvjQ6Z45g1wGKuG2J38rnbOc0Zk0iKaUYvqeEnH3Vse9+uS8oZ+Hf
         JNPXfPEa2b0vqKzmtnBe4eK0xO4Y7AvR+uKph+axlb2w+fsnF932Pwy6BAjPJKEPiSE0
         oFRK4QvoDgXaJHcCOd6H/7tnDqUberKmtbvx4vtToEzjtjWmMZajd5YX1pWo8PyhJLLJ
         FP6cg0Tl2jVTyyGFWtUfHGKJREu+6newtD4ikM0tH1zobycPeYrNbyg0fa3/88TsKuwX
         x56GOV87mDGLBtfN3biRbxklRrQ9o3+3Mh0efWNPibGJUrj6H5PL1lcIrRYAbe4i6Qfm
         oFVg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711439515; x=1712044315;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=nY62mL7e9ntXnjEq/w6d5JyG5A14j1SSjlMr7TSXSvQ=;
        b=gB+EZBEdm0qetfThmB+3dP2tR50CM6l0v7EtnebJ4hZzBTLCYOR4qwk/HZK5x+0ts5
         DnVoH6/mjMNO61A/zFMfsqJ+/0tCYYFfAJHp+vKSCjeTk9SvQoydLYDbooOgsmjH6fR3
         VMsQSdkiM6r08H2FV62KATtdzoOzxmaBgSsTWkBHILFqAYWQuHNwGxozdt07cqOfqsDL
         LA8HgEzaIWwNSlZ4KaeaYk2BTJ646dCSGGBNECgjKRbbNvATSuBGlPLsRdpk5UtbN837
         2dhbWFyTled3BghGcz85fUzCU5QrXRbbNeYJDs9W4b0kP13B+uuInE3q5ENtdLlAo4km
         E8Sw==
X-Forwarded-Encrypted: i=1; AJvYcCWpRMZ7GIAQO7jlDT81oRszh7aiA5zf+7R8M3RMjuv+3ra//mZaHM1khOWwS/YSDzSY29pxAS/iHXE5sZzZ3Eo8XSqm0JOIwLREyr0Ernw=
X-Gm-Message-State: AOJu0YzZvrZ3wELvuAE4qVTiatawXLWKT7fyqn7gPYwKco9aqMHzwLqp
	XWUe/9ugRk8s4oFE9c6OMmTVw6JVlICzW1FPXaGBkjscLj7SLZ/6Pkvbhrw6sg==
X-Google-Smtp-Source: AGHT+IFjpbyPg8uCPw4em4hExXOf11NkBqohnkarrkSXUG/+JnUe2XFqBK0iqhf43CQe6caBer0K1A==
X-Received: by 2002:ac2:504c:0:b0:513:c223:f0e4 with SMTP id a12-20020ac2504c000000b00513c223f0e4mr7701277lfm.10.1711439514776;
        Tue, 26 Mar 2024 00:51:54 -0700 (PDT)
Message-ID: 
Date: Tue, 26 Mar 2024 08:51:53 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 4/5] libelf: Expand ELF note printing
Content-Language: en-US
To: Jason Andryuk 
Cc: Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20240325204515.250203-1-jason.andryuk@amd.com>
 <20240325204515.250203-5-jason.andryuk@amd.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240325204515.250203-5-jason.andryuk@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 25.03.2024 21:45, Jason Andryuk wrote:
> @@ -145,13 +150,18 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
>          elf_msg(elf, "ELF: note: %s = \"%s\"\n", note_desc[type].name, str);
>          parms->elf_notes[type].type = XEN_ENT_STR;
>          parms->elf_notes[type].data.str = str;
> -    }
> -    else
> -    {
> +        break;
> +
> +    case ELFNOTE_INT:
>          val = elf_note_numeric(elf, note);
>          elf_msg(elf, "ELF: note: %s = %#" PRIx64 "\n", note_desc[type].name, val);
>          parms->elf_notes[type].type = XEN_ENT_LONG;
>          parms->elf_notes[type].data.num = val;
> +        break;
> +
> +    case ELFNOTE_NAME:
> +        elf_msg(elf, "ELF: note: %s", note_desc[type].name);
> +        break;

As indicated before, I think a brief comment is warranted here towards
the seemingly missing newline. With that added
Reviewed-by: Jan Beulich 

Jan


From xen-devel-bounces@lists.xenproject.org Tue Mar 26 08:08:20 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Mar 2024 08:08:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697951.1089224 (Exim 4.92)
	(envelope-from )
	id 1rp1qv-0000Jr-Nc; Tue, 26 Mar 2024 08:08:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697951.1089224; Tue, 26 Mar 2024 08:08:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rp1qv-0000Jk-KT; Tue, 26 Mar 2024 08:08:13 +0000
Received: by outflank-mailman (input) for mailman id 697951;
 Tue, 26 Mar 2024 08:08:12 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rp1qu-0000JQ-NK
 for xen-devel@lists.xenproject.org; Tue, 26 Mar 2024 08:08:12 +0000
Received: from EUR02-DB5-obe.outbound.protection.outlook.com
 (mail-db5eur02on20600.outbound.protection.outlook.com
 [2a01:111:f403:2608::600])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id fbea71b0-eb47-11ee-a1ef-f123f15fe8a2;
 Tue, 26 Mar 2024 09:08:10 +0100 (CET)
Received: from AS9PR04CA0177.eurprd04.prod.outlook.com (2603:10a6:20b:530::10)
 by PA4PR08MB6000.eurprd08.prod.outlook.com (2603:10a6:102:ed::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.31; Tue, 26 Mar
 2024 08:08:05 +0000
Received: from AM1PEPF000252E0.eurprd07.prod.outlook.com
 (2603:10a6:20b:530:cafe::18) by AS9PR04CA0177.outlook.office365.com
 (2603:10a6:20b:530::10) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.13 via Frontend
 Transport; Tue, 26 Mar 2024 08:08:05 +0000
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by
 AM1PEPF000252E0.mail.protection.outlook.com (10.167.16.58) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.7409.10 via Frontend Transport; Tue, 26 Mar 2024 08:08:05 +0000
Received: ("Tessian outbound dc0a9029eb2c:v300");
 Tue, 26 Mar 2024 08:08:04 +0000
Received: from 7015bd1dd42b.1
 by 64aa7808-outbound-1.mta.getcheckrecipient.com id
 C1EE44BE-5DC9-4A8E-8FEA-7A925E6FEFCE.1; 
 Tue, 26 Mar 2024 08:07:58 +0000
Received: from EUR02-VI1-obe.outbound.protection.outlook.com
 by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 7015bd1dd42b.1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384);
 Tue, 26 Mar 2024 08:07:58 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com (2603:10a6:10:25a::24)
 by DU0PR08MB8186.eurprd08.prod.outlook.com (2603:10a6:10:3ed::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.31; Tue, 26 Mar
 2024 08:07:55 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::7fb0:6621:56b:22d5]) by DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::7fb0:6621:56b:22d5%3]) with mapi id 15.20.7409.031; Tue, 26 Mar 2024
 08:07:53 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: fbea71b0-eb47-11ee-a1ef-f123f15fe8a2
ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass;
 b=RfSEO5gQkimBQL3DbaIFe2GUeF7oLYSXkoED2IYp05KBTGyAkdu5FcxVVPZW5wiJ2PpSdcnhK1GyBNUxODN32f5IiodfxPpRclOhCWQNbNRCgiOCwpGjTMRgmlhS0CO1jz8py+9oSQHXMZ5x9rCRCDCE6g1fmghwOQIQg/G4ROoAa0ODj+ZwP2KIxyEMz+PuQcuz13zmf9BcmSiKR9rLEyNIydrprP0g1wb9VT7ONc+3W2KqZtS96aWKiM4Z4/1JPDWyzsDhtsPRXCMaeLjGkrMPwhGl8/4LPhfn4oDIQigf+e4eKjwYj8vCQ0z/RKP8VAMn3KptF21SyOXDyPs3cQ==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=JS5iLLRTyrPouY0YN9euUlT00CYkyOGxLqQLb+2/I14=;
 b=Rnaa8x66Jf0nCZWJbSU2hB/X0F7cwIdH3/V2z0pNdtZuWahR0EDqaWbwL1bSA+E2oiOYBImIC8b8rbMxdzbSjAfaQLHc/7DzevJTpl1dvdS6RBk+2KkEdiTioR5UoGnVuUGOm8Ym9AV3j4b9YyT3u70YT5Un8s7dX1gXJNrdsqzKMWD2ES0TAjF2+yef45n29vXgae3KuOYFj+JdqOX1D8pRfJC7fv/GrLhn6+JWlUgjAqwWOqhpqCFCnxBYU3gOZK5Kpkt+JMTGclHWNWSx0YbFi4v/I3r+iJHBKyio7MUCIYPm8XdGlo+2pokyMZ9eeGuJ31lylrZKVgeTwAmgrg==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 63.35.35.123) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=arm.com;
 dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com;
 dkim=pass (signature was verified) header.d=armh.onmicrosoft.com; arc=pass (0
 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com]
 dmarc=[1,1,header.from=arm.com])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com;
 s=selector2-armh-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=JS5iLLRTyrPouY0YN9euUlT00CYkyOGxLqQLb+2/I14=;
 b=BilmBtJBZ6yXJtCgFQWCK0pFUDZUw8+ez3mFpm8gwrtkvVYeiFO3GC5UJrGQKDsSWEeEUr9tHrMOIeDVGw8guncF3V+prV/oBg8bm9SogNSQ23i9HB1buigRdJLnn4DSOBFoKVnAncPoc+K1Ku8IGLCG0s0lX4G5Q5MIDkkMeH4=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=armh.onmicrosoft.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 63.35.35.123 as permitted sender) receiver=protection.outlook.com;
 client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
 pr=C
X-CheckRecipientChecked: true
X-CR-MTA-CID: ba0b5fa4ce2857d4
X-CR-MTA-TID: 64aa7808
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=eSVoG8Q6CJJ5Tn9ZrCuEO4jBYrBnj+7twxMZHfmAXX6J6wdkuH7u5JG5GUmQqlSPy7LUpQbR1MtEyeXPwi6RBEzsVVR8a62/ffwFAPO7ly2VJfYdCuIdYfS5WqIew4crQutziZUhyJViPCYhaaDi7j9IlW1OCb+xtSXr/lSTZSYyvMt0Y3Qu66r6PstjNgfk1pzo8s4xefBvxGWaIXwtNOpQLdeZ858uBbF6Gkz4bpLXbFOa5Wo/kGKO76tYCy5nNmyZUnZFsn0wctRmaAsYR51/yIzj0kg1sq+curTfuC+BNVz2OR5tPGAQ06gZbE+NiQGWFWgx6ZbFyW60IcTaVw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=JS5iLLRTyrPouY0YN9euUlT00CYkyOGxLqQLb+2/I14=;
 b=j0j09to8R7hEfnyjZ3Solya7DPhxI0eNLGEXonZdoSg171W9o4RSTuaOOzCK7X65kXTw3k/Z3x/NKXH+Q0osOY2pCKcxO6l3mwoBH66uLyZihSBKtG9rgfYQ3CxBDcwltKOUwy68AFtNAqKLeuWy7UzqDBX6pDnO86Cs/s5PV7ZeThTeLN88nG8BgUZqdLjwnEhedyrJ9MQRCmS2aIEXHSWHk+H0Mfmy250xeCclkCGOOcCc+mWOMGpFktb3bIz+2m4+7qn8NLvd/e85AK8yoH0IN8O1vMpSFPMNz10x2HqF7RW64WPOdK7FA4YPhsP5FD+Q4plv0RyJKE0FzKmdDQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass
 header.d=arm.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com;
 s=selector2-armh-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=JS5iLLRTyrPouY0YN9euUlT00CYkyOGxLqQLb+2/I14=;
 b=BilmBtJBZ6yXJtCgFQWCK0pFUDZUw8+ez3mFpm8gwrtkvVYeiFO3GC5UJrGQKDsSWEeEUr9tHrMOIeDVGw8guncF3V+prV/oBg8bm9SogNSQ23i9HB1buigRdJLnn4DSOBFoKVnAncPoc+K1Ku8IGLCG0s0lX4G5Q5MIDkkMeH4=
From: Bertrand Marquis 
To: John Ernberg 
CC: Julien Grall , Peng Fan , Stefano
 Stabellini , Michal Orzel ,
	Volodymyr Babchuk , Jonas Blixt
	, "xen-devel@lists.xenproject.org"
	
Subject: Re: [PATCH 1/2] xen/arm: Add imx8q{m,x} platform glue
Thread-Topic: [PATCH 1/2] xen/arm: Add imx8q{m,x} platform glue
Thread-Index:
 AQHaVDuqVQ/kgxLZgUK/m8/hE0ez5bDz198AgAA1LICAAVx4AIAAQjaAgAEdtQCAAynKwIABnCuAgAZ8E4CAKNxCgIAApf0AgAKGQwCAAAbHgIAHmWEAgAtpgACAABVOgIAA6w+AgACMxYCAAAK5AIAGBxOAgAFMVAA=
Date: Tue, 26 Mar 2024 08:07:53 +0000
Message-ID: <051EF77F-18F1-42A5-B8E0-BE4AF0ED6B8C@arm.com>
References: <20240131114952.305805-1-john.ernberg@actia.se>
 <20240131114952.305805-2-john.ernberg@actia.se>
 
 <494d4961-ad8a-4d1d-aaa6-d1bfb9d6a137@actia.se>
 <167f0c7a-e037-446c-82f8-2584e35a7af1@xen.org>
 
 <012b5f83-2f9b-4477-965e-07b8506c0052@xen.org>
 
 <5a0c8f09-4f01-45e9-892c-86342c0d0ec5@xen.org>
 <08ae764c-3490-4dd1-ab70-7a855a98d16d@actia.se>
 <911ec1bb-3733-4f37-839e-673a88e408ff@actia.se>
 
 <848794f3-a337-49d9-84db-a969970f071b@actia.se>
 <48038c7f-d7cd-4100-a41b-8042bcb93208@xen.org>
 <967020E7-3D03-416A-8BFC-6F4E4BD9D7B5@arm.com>
 
 <849f3f5a-b960-444a-a10e-1f2df36c22a7@xen.org>
 <2F07325F-428F-4570-BE14-B84DD0A1C9F7@arm.com>
 <1f5eba1a-7dc3-41f2-8986-26452c264770@actia.se>
 
 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3774.200.91.1.1)
x-ms-traffictypediagnostic:
	DB9PR08MB6588:EE_|DU0PR08MB8186:EE_|AM1PEPF000252E0:EE_|PA4PR08MB6000:EE_
x-checkrecipientrouted: true
nodisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted: BCL:0;
X-Microsoft-Antispam-Message-Info-Original:
 C+KI95eqMcmCMg2pLdy/OX9kks7KEcIlM7a0MLzCddaL/5kPnaHhspZ5XwNSgMQFc+TkxdoDS8eV2ViAFySGZUtRk9emR9InqnjFIOtasQ3BgqYY634UebNCArWABA2kVySDcDkjNvGe3wvUwoUri6eaH5o+fLhsSLWKidoHqKRZsYhlxe/bn5ogC36vjvbwtNQDHvqYG+hFj7W/jwGuWCb2QaDURpdK/8SLAKTKsHjTNMpOwa8BtLfNjVtFVmJuZ++O7fUM9RGSprCK0MRQfyoeB59YLlrOr2I9ODrIJ9jhSaTPGnEYsXUsnPyvTGtuN+g9NF/9ruGgD+yUgmtsyDRH6MZcJvG5bz/+gnAaCAp21zVOd59HEOO4sigoyxIgpo8Tm6h9xJORXk3UwoD++mW77zLWshHTQ34VXdk8N2zkeFklrQbdqOj5jB2if2OO31bMAEk4a1Wez1V2DBknggehch6hJOVOCa5TF8vKf96XzqF9jT5jXnISRzo0hzQ+oOugQ5qOILbmz9j05jVUgLZtefi+wFBwkvFMpaMv/4aoz0Jeytd/6SYgw3vu9JZ+yjzWLm4ZwCGyEepW7yWVj09AL6q/gIuoYuPVQ4QxX4E=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB9PR08MB6588.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(366007)(376005)(1800799015);DIR:OUT;SFP:1102;
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR08MB8186
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 AM1PEPF000252E0.eurprd07.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 6126f6d1-053d-4d4f-ff0b-08dc4d6bdd69
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	LGQBrKfUut486su3QnSRjsjfl/Thx+GclndSk1bnOQld5xyC4NShnIQ5x942ZA/DcaqFctI4pbZVuzSUpgpmLuSvse4ao8Pvxa9IL8J7xsGgmhEuMUuOWGyXDKJvkg7euIbomkW7j0ZeMQ8l2JjKYL3s61kE2HKt+2yE9Eo/L0H5FVDySXRVUX3cjRC8tIvDjiER1BO6xHZh93aNp7Rq6Dri/nv0iHuGKi1S4sMJSL8udEZSEMEexOpT3M6VmGAlSR86fL5+vmBPcaO3BHzRn6+9dZbXqh8dWSoK5jODL+aWiE9ouPadIZyPdHDzK3RK1P7l1WWLnF972iyUgAWBaZekAnNLmLMRkvGX13xkLncRW1op9/dO9AhhiLOoT08dyIC25J9kfIqAJ+qBqI50h9Ui8SoTqq2uNyTjCFlXZ06K599g+G76StZmHRgYc0ArRexrXJHeyGh5u/5nARMWEE84N6HGH84bp/FlqLfJsda8n9AkdGF/B1I+9dqSqrSiu1aeJW7T2JADEDlT5WGvxapf/WJZ/cqTEjWAtu/ncdB6jGbPndM7Y08DUlzooZKaVRPM9qg2HINKAZv4al0I4is3M9bBlWzLuFUgSdmr7bAScTDVv9NjRYsNeecKbpOUJERDYukM9n97tOMUO4BWy9nxfzTM+EYTLuE5FGXL9lWrWls64bIxkPidIBSMYSobqdxVc2pWFj2WOGpu1DscEg==
X-Forefront-Antispam-Report:
	CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com;CAT:NONE;SFS:(13230031)(36860700004)(82310400014)(1800799015)(376005);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Mar 2024 08:08:05.0537
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 6126f6d1-053d-4d4f-ff0b-08dc4d6bdd69
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-AuthSource:
	AM1PEPF000252E0.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR08MB6000

Hi John,

> On 25 Mar 2024, at 13:18, John Ernberg  wrote:
>=20
> Hi Bertrand,
>=20
> On 3/21/24 17:15, Bertrand Marquis wrote:
>> Hi John,
>>=20
>>> On 21 Mar 2024, at 17:05, John Ernberg  wrote:
>>>=20
>>> Hi Bertrand,
>>>=20
>>> On 3/21/24 08:41, Bertrand Marquis wrote:
>>>> Hi,
>>>>=20
>>>>> On 20 Mar 2024, at 18:40, Julien Grall  wrote:
>>>>>=20
>>>>> Hi John,
>>>>>=20
>>>>> On 20/03/2024 16:24, John Ernberg wrote:
>>>>>> Hi Bertrand,
>>>>>> On 3/13/24 11:07, Bertrand Marquis wrote:
>>>>>>> Hi,
>>>>>>>=20
>>>>>>>> On 8 Mar 2024, at 15:04, Julien Grall  wrote:
>>>>>>>>=20
>>>>>>>> Hi John,
>>>>>>>>=20
>>>>>>>> Thank you for the reply.
>>>>>>>>=20
>>>>>>>> On 08/03/2024 13:40, John Ernberg wrote:
>>>>>>>>> On 3/7/24 00:07, Julien Grall wrote:
>>>>>>>>>>> Ping on the watchdog discussion bits.
>>>>>>>>>>=20
>>>>>>>>>> Sorry for the late reply.
>>>>>>>>>>=20
>>>>>>>>>> On 06/03/2024 13:13, John Ernberg wrote:
>>>>>>>>>>> On 2/9/24 14:14, John Ernberg wrote:
>>>>>>>>>>>>=20
>>>>>>>>>>>>>      * IMX_SIP_TIMER_*:  This seems to be related to the watc=
hdog.
>>>>>>>>>>>>> Shouldn't dom0 rely on the watchdog provided by Xen instead? =
So those
>>>>>>>>>>>>> call will be used by Xen.
>>>>>>>>>>>>=20
>>>>>>>>>>>> That is indeed a watchdog SIP, and also for setting the SoC in=
ternal RTC
>>>>>>>>>>>> if it is being used.
>>>>>>>>>>>>=20
>>>>>>>>>>>> I looked around if there was previous discussion and only real=
ly
>>>>>>>>>>>> found [3].
>>>>>>>>>>>> Is the xen/xen/include/watchdog.h header meant to be for this =
kind of
>>>>>>>>>>>> watchdog support or is that more for the VM watchdog? Looking =
at the x86
>>>>>>>>>>>> ACPI NMI watchdog it seems like the former, but I have never w=
orked with
>>>>>>>>>>>> x86 nor ACPI.
>>>>>>>>>>=20
>>>>>>>>>> include/watchdog.h contains helper to configure the watchdog for=
 Xen. We
>>>>>>>>>> also have per-VM watchdog and this is configured by the hypercal=
l
>>>>>>>>>> SCHEDOP_watchdog.
>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>> Currently forwarding it to Dom0 has not caused any watchdog re=
sets with
>>>>>>>>>>>> our watchdog timeout settings, our specific Dom0 setup and VM =
count.
>>>>>>>>>>=20
>>>>>>>>>> IIUC, the SMC API for the watchdog would be similar to the ACPI =
NMI
>>>>>>>>>> watchdog. So I think it would make more sense if this is not exp=
osed to
>>>>>>>>>> dom0 (even if Xen is doing nothing with it).
>>>>>>>>>>=20
>>>>>>>>>> Can you try to hide the SMCs and check if dom0 still behave prop=
erly?
>>>>>>>>>>=20
>>>>>>>>>> Cheers,
>>>>>>>>>>=20
>>>>>>>>> This SMC manages a hardware watchdog, if it's not pinged within a
>>>>>>>>> specific interval the entire board resets.
>>>>>>>>=20
>>>>>>>> Do you know what's the default interval? Is it large enough so Xen=
 + dom0 can boot (at least up to when the watchdog driver is initialized)?
>>>>>>>>=20
>>>>>>>>> If I block the SMCs the watchdog driver in Dom0 will fail to ping=
 the
>>>>>>>>> watchdog, triggering a board reset because the system looks to ha=
ve
>>>>>>>>> become unresponsive. The reason this patch set started is because=
 we
>>>>>>>>> couldn't ping the watchdog when running with Xen.
>>>>>>>>> In our specific system the bootloader enables the watchdog as ear=
ly as
>>>>>>>>> possible so that we can get watchdog protection for as much of th=
e boot
>>>>>>>>> as we possibly can.
>>>>>>>>> So, if we are to block the SMC from Dom0, then Xen needs to take =
over
>>>>>>>>> the pinging. It could be implemented similarly to the NMI watchdo=
g,
>>>>>>>>> except that the system will reset if the ping is missed rather th=
an
>>>>>>>>> backtrace.
>>>>>>>>> It would also mean that Xen will get a whole watchdog driver-cate=
gory
>>>>>>>>> due to the watchdog being vendor and sometimes even SoC specific =
when it
>>>>>>>>> comes to Arm.
>>>>>>>>> My understanding of the domain watchdog code is that today the do=
main
>>>>>>>>> needs to call SCHEDOP_watchdog at least once to start the watchdo=
g
>>>>>>>>> timer. Since watchdog protection through the whole boot process i=
s
>>>>>>>>> desirable we'd need some core changes, such as an option to start=
 the
>>>>>>>>> domain watchdog on init. >
>>>>>>>>> It's quite a big change to make
>>>>>>>>=20
>>>>>>>> For clarification, above you seem to mention two changes:
>>>>>>>>=20
>>>>>>>> 1) Allow Xen to use the HW watchdog
>>>>>>>> 2) Allow the domain to use the watchdog early
>>>>>>>>=20
>>>>>>>> I am assuming by big change, you are referring to 2?
>>>>>>>>=20
>>>>>>>> , while I am not against doing it if it
>>>>>>>>> makes sense, I now wonder if Xen should manage hardware watchdogs=
.
>>>>>>>>> Looking at the domain watchdog code it looks like if a domain doe=
s not
>>>>>>>>> get enough execution time, the watchdog will not be pinged enough=
 and
>>>>>>>>> the guest will be reset. So either watchdog approach requires Dom=
0 to
>>>>>>>>> get execution time. Dom0 also needs to service all the PV backend=
s it's
>>>>>>>>> responsible for. I'm not sure it's valuable to add another layer =
of
>>>>>>>>> watchdog for this scenario as the end result (checking that the e=
ntire
>>>>>>>>> system works) is achieved without it as well.
>>>>>>>>> So, before I try to find the time to make a proposal for moving t=
he
>>>>>>>>> hardware watchdog bit to Xen, do we really want it?
>>>>>>>>=20
>>>>>>>> Thanks for the details. Given that the watchdog is enabled by the =
bootloader, I think we want Xen to drive the watchdog for two reasons:
>>>>>>>> 1) In true dom0less environment, dom0 would not exist
>>>>>>>> 2) You are relying on Xen + Dom0 to boot (or at least enough to ge=
t the watchdog working) within the watchdog interval.
>>>>>>>=20
>>>>>>> Definitely we need to consider the case where there is no Dom0.
>>>>>>>=20
>>>>>>> I think there are in fact 3 different use cases here:
>>>>>>> - watchdog fully driven in a domain (dom0 or another): would work i=
f it is expected
>>>>>>>    that Xen + Domain boot time is under the watchdog initial refres=
h rate. I think this
>>>>>>>    could make sense on some applications where your system depends =
on a specific
>>>>>>>    domain to be properly booted to work. This would require an init=
ial refresh time
>>>>>>>    configurable in the boot loader probably.
>>>>>> This is our use-case. ^
>>>>>> Our dom0 is monitoring and managing the other domains in our system.
>>>>>> Without dom0 working the system isn't really working as a whole.
>>>>>> @Julien: Would you be ok with the patch set continuing in the direct=
ion
>>>>>> of the
>>>>>> original proposal, letting another party (or me at a later time) imp=
lement
>>>>>> the fully driven by Xen option?
>>>>> I am concerned about this particular point from Bertrand:
>>>>>=20
>>>>> "would work if it is expected that Xen + Domain boot time is under th=
e watchdog initial refresh rate."
>>>>>=20
>>>>> How will a user be able to figure out how to initially configure the =
watchdog? Is this something you can easily configure in the bootloader at r=
untime?
>>>=20
>>> If you go through the trouble of enabling the watchdog in the bootloade=
r you
>>> usually know what you're doing and set the timeout yourself.
>>>=20
>>> Since our systems can be mounted in really annoying locations (both in
>>> installations and world-wise) we need as much auto-recovery as possible=
 to
>>> avoid people having to travel to collect a unit that just needed a rese=
t due
>>> to some unexpected obscure issue at startup.
>>=20
>> I definitely get the need do not get me wrong.
>> I am just concerned by potential users having target restarting when usi=
ng Xen because of that and not knowing why.
>>=20
>>>>=20
>>>> Definitely here it would be better to have the watchdog turned off by =
default and document how to enable it in the firmware.
>>>>=20
>>>> Even if a long timeout is configured by default, a user could run into=
 trouble if using a linux without watchdog or not running linux or using do=
m0less without a linux having access to it.
>>>> I agree with Julien here that the concern could be that users would co=
me to us instead of NXP if there is system is doing a reset without reasons=
 after some seconds or minutes.
>>>=20
>>> I could add myself as a reviewer for the iMX parts if that helps routin=
g
>>> such
>>> questions (and future patches) also to me. We have experience with the =
QXP,
>>> and the QM (for the supported parts by this patch set) is identical.
>>>=20
>>> Would that help with the concerns?
>>=20
>> Definitely it could help.
>=20
> I'll figure out how to include myself in the MAINTAINERS file for the=20
> next spin.
>=20

Thanks.

>>=20
>>>=20
>>>>=20
>>>>>=20
>>>>>=20
>>>>> Overall, I am not for this approach at least in the current status. I=
 would be more inclined if there are some documentations explaining how thi=
s is supposed to be configured on NXP, so others can use the code.
>>>>>=20
>>>>> Anyway, this is why we have multiple Arm maintainers for this kind of=
 situation. If they other agrees with you, then they can ack the patch and =
this can be merged.
>>>>=20
>>>> I agree with Stefano that it would be good to have those board support=
ed.
>>>>=20
>>>> One thing i could suggest until there is a watchdog driver inside Xen =
is to have a clear Warning at Xen boot on those boards in the console so th=
at we could at least identify the reason easily if a reset occurs for someo=
ne.
>>>=20
>>> How do other SoCs deal with this currently? The iMX SoCs aren't the onl=
y
>>> ones
>>> with a watchdog, just the first one added to Xen that pings the watchdo=
g
>>> over
>>> an SMC. What about the OMAPs, the R-Cars, Xilinx's, Exynos' and so on?
>>=20
>> As far as I know the watchdog is usually not active until a driver activ=
ates it.
>> Which means that by default it will not fire.
>> Having it activated by the bootloader by default is not usual.
>> Now definitely on a lot of use cases the users are activating it in the =
booloader
>> but their systems are design for it.
>>=20
>> Do I understand that the default boot loader configuration is not activa=
ting it on your side ?
>=20
> We are using a bootloader called Punchboot [1] developed by one of our=20
> employees. With Punchboot you have to explicitly write the code to=20
> enable the watchdog yourself. In u-boot you need to enable the watchdog=20
> drivers and configure the watchdog first before it is started. I don't=20
> know how the situation is in other bootloaders such as BareBox.

Then a user not knowing will not have it activated and will not encounter i=
ssues.
So all good from my point of view :-)

Regards
Bertrand


>=20
> Best regards // John Ernberg
>=20
> [1]: https://github.com/jonasblixt/punchboot




From xen-devel-bounces@lists.xenproject.org Tue Mar 26 08:19:33 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Mar 2024 08:19:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697959.1089234 (Exim 4.92)
	(envelope-from )
	id 1rp21l-0002Sa-OD; Tue, 26 Mar 2024 08:19:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697959.1089234; Tue, 26 Mar 2024 08:19:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rp21l-0002ST-Jy; Tue, 26 Mar 2024 08:19:25 +0000
Received: by outflank-mailman (input) for mailman id 697959;
 Tue, 26 Mar 2024 08:19:24 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rp21k-0002S2-6g
 for xen-devel@lists.xenproject.org; Tue, 26 Mar 2024 08:19:24 +0000
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com
 [2a00:1450:4864:20::62a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8cdc9ae4-eb49-11ee-a1ef-f123f15fe8a2;
 Tue, 26 Mar 2024 09:19:22 +0100 (CET)
Received: by mail-ej1-x62a.google.com with SMTP id
 a640c23a62f3a-a474c4faf5eso257657266b.2
 for ; Tue, 26 Mar 2024 01:19:22 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 k11-20020a1709067acb00b00a4a36e4c3fbsm1875634ejo.182.2024.03.26.01.19.21
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 26 Mar 2024 01:19:21 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8cdc9ae4-eb49-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711441162; x=1712045962; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=I2Qcyp06X39D73dDP5Z5225X3XCbdlsp8tXnJrL2XrE=;
        b=QpfNM7fKp2OGkZnqpnBE2kuPzUv8jxRt7/GW2xVGHY++TNUCrdx5m1qGiYzdA91PXu
         RYcEmnvtTPZfp7cVXuTSZqaSRkBnHCPkeai/4ZPtq00Vtf+m7KL3Hsygyjf30FTZgKMG
         jTolz5qsDgzPwko2c4Zy4i8ylgTTfPRE9RF89Xco3qqtHb8E2Eex1MyHMVmyNTOexYN7
         lGHC0twoHIDmK8oEwQhgTe6sv8O/C2lopR/MZ0jctguhQjWVdvxArFmINKgLtkvT5WtE
         NkDIF31ZBb6hGkzLIurw7M2oMCrAZlR5PBsDC/b+DbDnoIaOiJ0TP0mOZ71PsIAKCe/U
         j9+w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711441162; x=1712045962;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=I2Qcyp06X39D73dDP5Z5225X3XCbdlsp8tXnJrL2XrE=;
        b=bVs4DjCjfmMd/SPa/giyF8JhpGtpvwmDqPrZvVd38X2EldIlujBoNi22P1TNLe7XXJ
         l5cd82p6fpaEM9UraY5OJ5ppBEUc3cecUs1/HCHQlZnnrO28KzF9tIuesVa0QdDRHPnz
         VwasiKWIKvVT9fQY8jmlM3savK/4CT0BNOiM/9ZGhsM1dsLtXLJ6xdJDQtps+qTr8bIQ
         i4nyjjXAIRzxAzQeYqHZztPrkG8QIEirC6SHOQ4C+9AvBtXcMhNd4wEeHEHLz65YdHDE
         mDcrsK99NL/OXX4iIsGevTKHHkm0JULqOp0KNG5Wn7SbMxZFzDX7WYDEvL8ngLP1wKag
         cy8Q==
X-Forwarded-Encrypted: i=1; AJvYcCUnPrx77nwc/LcVfYoVb+1ov6bozsYsGEJATPV9t9A+I0TobagXv4TH377jAtFayOL2lxjvtPZA8E/f91yHH4F2XfHpNuihUvuvJEn5uNU=
X-Gm-Message-State: AOJu0YzeT4K4drIS45hmWku7BcZbnLc3DS1X78ab8pia/FBWjLUN9RSc
	5OFwLkb2r60Xyzj08cxZhZliVrGRsq5PN/UcW2ZaT8F/9t0JxzjgUWy5E/2tIA==
X-Google-Smtp-Source: AGHT+IG8FYEkCB4CeeUAasu5gPheLtH3tHiXV50mz/zDXRp69qXpI0ufSe3uqurmizL4JVleIeY4Mg==
X-Received: by 2002:a17:906:3e4a:b0:a46:5e1b:58a3 with SMTP id t10-20020a1709063e4a00b00a465e1b58a3mr5845209eji.35.1711441161916;
        Tue, 26 Mar 2024 01:19:21 -0700 (PDT)
Message-ID: <55416d60-cae7-4e79-8bde-bc07ee9e3830@suse.com>
Date: Tue, 26 Mar 2024 09:19:20 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] tools/misc: fix xenwatchdogd invocation
Content-Language: en-US
To: =?UTF-8?Q?zithro_/_Cyril_R=C3=A9bert?= 
Cc: Leigh Brown ,
 Andrew Cooper ,
 Anthony PERARD , xen-devel@lists.xenproject.org
References: <6f5b09d7bdc555227e7a5e55aa090171fba070f8.1711430145.git.slack@rabbit.lu>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <6f5b09d7bdc555227e7a5e55aa090171fba070f8.1711430145.git.slack@rabbit.lu>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 26.03.2024 06:15, zithro / Cyril Rébert wrote:
> --- a/tools/misc/xenwatchdogd.c
> +++ b/tools/misc/xenwatchdogd.c
> @@ -8,26 +8,34 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
> +#define _GNU_SOURCE

This wants defining first thing in a file (or even on the compiler command
line), to (properly) affect all headers.

> +#include 
> +#if !defined(__GNUC__) && !defined(__GNUG__)

Why __GNUG__ in a C file? And anyway, why is this construct needed? You
don't ...

> +#define __attribute__(arg) /* empty */

... use any attributes down from here.

You mention xentop as where you've taken them from. I view those as
questionable. If in fact you had used any other utility's source for
reference, you wouldn't have encountered such.

> +#endif
> +
>  xc_interface *h;
>  int id = 0;
>  
>  void daemonize(void)
>  {
>      switch (fork()) {
> -    case -1:
> -	err(1, "fork");
> -    case 0:
> -	break;
> -    default:
> -	exit(0);
> +        case -1:
> +            err(1, "fork");
> +        case 0:
> +            break;
> +        default:
> +            exit(0);
>      }

The case labels were properly indented, weren't they? And all other re-
indentation you do wants splitting from the functional change.

> @@ -52,39 +60,68 @@ void catch_usr1(int sig)
>  
>  int main(int argc, char **argv)
>  {
> +
>      int t, s;

What would this new blank line be good for?

>      int ret;
> +    

I'd even question this one.

> +    char *usage = "usage: %s  ";

static const char[]

> +    int opt, optind = 0;
> +
> +    struct option lopts[] = {

static const

> +        { "help",          no_argument,       NULL, 'h' },
> +    };
> +    const char *sopts = "h";
> +
> +    while ((opt = getopt_long(argc, argv, sopts, lopts, &optind)) != -1) {
> +        switch (opt) {
> +        case '?':
> +        case 'h':
> +            errx(1, usage, argv[0]);

This isn't an error and hence wants to produce an exit code of 0.

> +            break;
> +        default:
> +            errx(1, usage, argv[0]);
> +        }

Please be consistent with break statements: Either you omit them
uniformly when a noreturn function is call, or you put them there
in all cases.

> +    }
>  
>      if (argc < 2)
> -	errx(1, "usage: %s  ", argv[0]);
> +        errx(1, usage, argv[0]);
>  
>      daemonize();
>  
>      h = xc_interface_open(NULL, NULL, 0);
>      if (h == NULL)
> -	err(1, "xc_interface_open");
> +        err(1, "xc_interface_open");
> +
> +    t = strtoul(argv[1], &argv[1], 0);
> +    
> +    // argv1 NaN

NaN is a term normally used for floating point values only.

> +    if ( *argv[1] != '\0' )
> +        errx(1, "Error: timeout must be a number, got '%s'", argv[1]);

This still doesn't guarantee a numeric: An empty string as argument
would still yield a value of 0 if I'm not mistaken. As would a
string consisting of just blanks.

> -    t = strtoul(argv[1], NULL, 0);
>      if (t == ULONG_MAX)
> -	err(1, "strtoul");
> +        err(1, "strtoul");
>  
>      s = t / 2;
>      if (argc == 3) {
> -	s = strtoul(argv[2], NULL, 0);
> -	if (s == ULONG_MAX)
> -	    err(1, "strtoul");
> +        s = strtoul(argv[2], &argv[2], 0);
> +        // argv2 NaN
> +        if ( *argv[2] != '\0' ){
> +            errx(1, "Error: sleep must be a number, got '%s'", argv[2]);
> +        }

Like above you don't really need braces here. If, however, you add
them, the opening one wants to be separated by a blank from the
closing parenthesis. And following other style in this file, there
do not want to be blanks immediately inside the parentheses.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Mar 26 08:54:13 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Mar 2024 08:54:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697969.1089243 (Exim 4.92)
	(envelope-from )
	id 1rp2ZA-0008Jo-EY; Tue, 26 Mar 2024 08:53:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697969.1089243; Tue, 26 Mar 2024 08:53:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rp2ZA-0008Jh-Bv; Tue, 26 Mar 2024 08:53:56 +0000
Received: by outflank-mailman (input) for mailman id 697969;
 Tue, 26 Mar 2024 08:53:54 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rp2Z7-0008Jb-Jw
 for xen-devel@lists.xenproject.org; Tue, 26 Mar 2024 08:53:54 +0000
Received: from mail.damsy.net (mail.damsy.net [85.90.245.9])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5dc1ba34-eb4e-11ee-a1ef-f123f15fe8a2;
 Tue, 26 Mar 2024 09:53:51 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5dc1ba34-eb4e-11ee-a1ef-f123f15fe8a2
Message-ID: <20ca2a39-cf41-4a7b-8c94-c4e193018147@damsy.net>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=damsy.net; s=201803;
	t=1711443228;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=xFjPbfFF8Mxh31f2Q1P0/8J/bltLrrx4Y06I0UEXuv8=;
	b=dnaIRgc23uUz3xOG60/r013Vp2tnh7Wlez3aTAw55DqebDQn1DXohc6w+WiJ7P9fqvUm3n
	ErhlNgNpy2Hwz6flWDNTXLr3nIIXrU9iTsHpXQiODCsRNfqVpI30wW8zVsA8sAg4V8n4yk
	b0nhMtG/5G3Pd2EFbgw9fwHwhSZ2xYfBJAVpKfbsw9yNGnBTGh9g3bo7ZczCj8D+jaVjPs
	lEkfVHNJNMQhykAbJm1fg5zwkB8ZNmWoxN08e7ANWkqJ/YiMvg9eHjOpMxVY3BWdM2GW0b
	P1Xm3wgh44ETKCBHNLg2G+KQpcVwKZQ0yEk//+xOVWxhjM620qw5kgdQAweJvw==
Date: Tue, 26 Mar 2024 09:53:47 +0100
MIME-Version: 1.0
Subject: Re: [PATCH v6 10/11] virtio-gpu: Initialize Venus
To: Huang Rui ,
 =?UTF-8?Q?Marc-Andr=C3=A9_Lureau?= 
Cc: Akihiko Odaki ,
 =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= ,
 Gerd Hoffmann , "Michael S . Tsirkin" ,
 Stefano Stabellini ,
 Anthony PERARD ,
 Antonio Caggiano ,
 "Dr . David Alan Gilbert" ,
 Robert Beckett ,
 Dmitry Osipenko ,
 Gert Wollny , =?UTF-8?Q?Alex_Benn=C3=A9e?=
 , "qemu-devel@nongnu.org" ,
 "xen-devel@lists.xenproject.org" ,
 Gurchetan Singh ,
 "ernunes@redhat.com" , Alyssa Ross ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 "Deucher, Alexander" ,
 "Stabellini, Stefano" ,
 "Koenig, Christian" ,
 "Ragiadakou, Xenia" ,
 "Pelloux-Prayer, Pierre-Eric" ,
 "Huang, Honglei1" ,
 "Zhang, Julia" , "Chen, Jiqian" ,
 Antonio Caggiano 
References: <20231219075320.165227-1-ray.huang@amd.com>
 <20231219075320.165227-11-ray.huang@amd.com>
 
 
Content-Language: fr
From: Pierre-Eric Pelloux-Prayer 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit



Le 23/02/2024 à 10:15, Huang Rui a écrit :
> On Tue, Jan 02, 2024 at 09:33:11PM +0800, Marc-André Lureau wrote:
>> Hi
>>
>> On Tue, Dec 19, 2023 at 11:55 AM Huang Rui  wrote:
>>>
>>> From: Antonio Caggiano 
>>>
>>> Request Venus when initializing VirGL.
>>>
>>> Signed-off-by: Antonio Caggiano 
>>> Signed-off-by: Huang Rui 
>>> ---
>>>
>>> Changes in v6:
>>> - Remove the unstable API flags check because virglrenderer is already 1.0.
>>> - Squash the render server flag support into "Initialize Venus".
>>>
>>>   hw/display/virtio-gpu-virgl.c | 4 ++++
>>>   1 file changed, 4 insertions(+)
>>>
>>> diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
>>> index f35a751824..c523a6717a 100644
>>> --- a/hw/display/virtio-gpu-virgl.c
>>> +++ b/hw/display/virtio-gpu-virgl.c
>>> @@ -964,6 +964,10 @@ int virtio_gpu_virgl_init(VirtIOGPU *g)
>>>       }
>>>   #endif
>>>
>>> +#ifdef VIRGL_RENDERER_VENUS
>>> +    flags |= VIRGL_RENDERER_VENUS | VIRGL_RENDERER_RENDER_SERVER;
>>> +#endif
>>> +
>>
>> I wonder if it's a good idea to initialize venus by default. It
>> doesn't seem to require vulkan during initialization, but this may
>> evolve. Make it optional?
>>
> 
> I am fine. In fact, vulkan is widely used for graphic area such as gaming,
> compute, VR/AR, etc.

Actually, making it optional is useful because Venus support is optional in
virglrenderer (= having VIRGL_RENDERER_VENUS defined doesn't mean that
Venus is supported).

Thanks,
Pierre-Eric


> 
> Thanks,
> Ray
> 
>>>       ret = virgl_renderer_init(g, flags, &virtio_gpu_3d_cbs);
>>>       if (ret != 0) {
>>>           error_report("virgl could not be initialized: %d", ret);
>>> --
>>> 2.25.1
>>>
>>
>>
>> -- 
>> Marc-André Lureau
> 


From xen-devel-bounces@lists.xenproject.org Tue Mar 26 09:13:58 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Mar 2024 09:13:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697972.1089255 (Exim 4.92)
	(envelope-from )
	id 1rp2sS-0003En-1x; Tue, 26 Mar 2024 09:13:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697972.1089255; Tue, 26 Mar 2024 09:13:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rp2sR-0003Eg-TV; Tue, 26 Mar 2024 09:13:51 +0000
Received: by outflank-mailman (input) for mailman id 697972;
 Tue, 26 Mar 2024 09:13:51 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rp2sR-0003Ea-7n
 for xen-devel@lists.xenproject.org; Tue, 26 Mar 2024 09:13:51 +0000
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com
 [2a00:1450:4864:20::631])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 27d251f1-eb51-11ee-a1ef-f123f15fe8a2;
 Tue, 26 Mar 2024 10:13:49 +0100 (CET)
Received: by mail-ej1-x631.google.com with SMTP id
 a640c23a62f3a-a450bedffdfso605585466b.3
 for ; Tue, 26 Mar 2024 02:13:48 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 k18-20020a1709060cb200b00a455d78be5bsm3995703ejh.9.2024.03.26.02.13.47
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 26 Mar 2024 02:13:48 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 27d251f1-eb51-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711444428; x=1712049228; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=Jepw7wLR0iwECnFAAX4iH8JzmbdW3yPW366bFphKlX8=;
        b=D7gW2D1qhUZuhxoR5pcYJ0mTjB4WWTBUolqHu7bXTY+Y012VrrO+P7U3oKfhjCPJjP
         LqPkB9kelhOXnj7DxBbIC/HfH3BA/UkmHcqcSCW8xFp5AejCo04OWb19hooqKmkwhE7T
         NSuBFWsb10mt4w6AFDqJzcvHmho5HEBqNqrHh6gtqE3yLjJPBj7MzjVVWO+8GXtlYSDv
         vkt6CbP7KHG+/6uGhdNAtXCNkYn1YYe3YcoetC3QkofebNQRaWj/MAj9AteE4hdUqTnP
         wLTcpOuDsRtJ013JvJfQTo3hDRWeyKyyBwEfKCQbosHTZhuikjbEdLuTNPhcu1uz1F9O
         h3GA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711444428; x=1712049228;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=Jepw7wLR0iwECnFAAX4iH8JzmbdW3yPW366bFphKlX8=;
        b=EJi7B4H7nb3Vm345zzZLHJRgj/m3Ggf2t5BIry+6/va8CxNm/hdP8c7dcM5g1RtLrB
         JOM+TnRC082thE2UGQC3zpgrhTbRANtokWG72mSIQgDm20H6dJC37jtXPCb/g+hHmQ4n
         8mEHZWiFwW2uyXPeB5EN2vwjN8Fuac3ZgS9inZr3bXDs4I1JJX4ap7zqsL8m5/MAhEy5
         J+t4x0yRbHkJz7CjsAycAWUYzM6hNB9p0m12hBJQqrttgGP1gqG2jke/WPMmAW4LOwLx
         u1+8kWKBfoCkThrIZnuMfGUOiMkkokoyoXWj8kOsiQ8D9/h3eoKEIuNsG5mvNmNsZh5q
         QciQ==
X-Forwarded-Encrypted: i=1; AJvYcCXSOHbPvvkXBMf/SuPciphGTbLox41FTr9dYomXkkNncZN+245PvQIn7J5j7CvE0PkbC1SKO+pBlG4OSpBMcLBr3Hpuh3vEv5M9FfOjieo=
X-Gm-Message-State: AOJu0YwN0QABehXJWDRdK+ctbOx1pR5y617bznoHXYrVDpSdw4CdFryU
	pdI17lrtgCWFITegTMc+WdNdbF0uBTkqm04TfYKI4cyP4aEXqtdxbxHgLG/lEA==
X-Google-Smtp-Source: AGHT+IFqAnvDd3bu4CNbIJQukQwfj3N3vBm5idyKfXXEI4K1s93hRkZ+3d195PX5XvLw5MZI/QX9Mg==
X-Received: by 2002:a17:906:f287:b0:a47:4836:6609 with SMTP id gu7-20020a170906f28700b00a4748366609mr436099ejb.60.1711444428304;
        Tue, 26 Mar 2024 02:13:48 -0700 (PDT)
Message-ID: 
Date: Tue, 26 Mar 2024 10:13:47 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/spec-ctrl: Support for SRSO_US_NO and SRSO_MSR_FIX
Content-Language: en-US
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Xen-devel 
References: <20240325181830.638680-1-andrew.cooper3@citrix.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240325181830.638680-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 25.03.2024 19:18, Andrew Cooper wrote:
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -2377,7 +2377,8 @@ By default SSBD will be mitigated at runtime (i.e `ssbd=runtime`).
>  >              {msr-sc,rsb,verw,ibpb-entry}=|{pv,hvm}=,
>  >              bti-thunk=retpoline|lfence|jmp, {ibrs,ibpb,ssbd,psfd,
>  >              eager-fpu,l1d-flush,branch-harden,srb-lock,
> ->              unpriv-mmio,gds-mit,div-scrub,lock-harden}= ]`
> +>              unpriv-mmio,gds-mit,div-scrub,lock-harden,
> +>              bp-spec-reduce}= ]`
>  
>  Controls for speculative execution sidechannel mitigations.  By default, Xen
>  will pick the most appropriate mitigations based on compiled in support,
> @@ -2509,6 +2510,12 @@ boolean can be used to force or prevent Xen from using speculation barriers to
>  protect lock critical regions.  This mitigation won't be engaged by default,
>  and needs to be explicitly enabled on the command line.
>  
> +On hardware supporting SRSO_MSR_FIX, the `bp-spec-reduce=` option can be used
> +to force or prevent Xen from using MSR_BP_CFG.BP_SPEC_REDUCE to mitigate the
> +SRSO (Speculative Return Stack Overflow) vulnerability.

"... against HVM guests" to avoid things being left ambiguous, and to also ...

>  By default, Xen will
> +use bp-spec-reduce when available, as it preferable to using `ibpb-entry=hvm`
> +to mitigate SRSO.

... correlate with the `ibpb-entry=hvm` here?

Maybe at the start of the paragraph also add "AMD"?

> --- a/xen/arch/x86/cpu/amd.c
> +++ b/xen/arch/x86/cpu/amd.c
> @@ -1009,16 +1009,31 @@ static void cf_check fam17_disable_c6(void *arg)
>  	wrmsrl(MSR_AMD_CSTATE_CFG, val & mask);
>  }
>  
> -static void amd_check_erratum_1485(void)
> +static void amd_check_bp_cfg(void)
>  {
> -	uint64_t val, chickenbit = (1 << 5);
> +	uint64_t val, new = 0;
>  
> -	if (cpu_has_hypervisor || boot_cpu_data.x86 != 0x19 || !is_zen4_uarch())
> +	/*
> +	 * AMD Erratum #1485.  Set bit 5, as instructed.
> +	 */
> +	if (!cpu_has_hypervisor && boot_cpu_data.x86 == 0x19 && is_zen4_uarch())
> +		new |= (1 << 5);
> +
> +	/*
> +	 * On hardware supporting SRSO_MSR_FIX, we prefer BP_SPEC_REDUCE to
> +	 * IBPB-on-entry to mitigate SRSO for HVM guests.
> +	 */
> +	if (IS_ENABLED(CONFIG_HVM) && boot_cpu_has(X86_FEATURE_SRSO_US_NO) &&
> +            opt_bp_spec_reduce)

Nit: Indentation is odd here (wants to be a tab followed by a few spaces).

> +		new |= BP_CFG_SPEC_REDUCE;

I take it that this goes from the assumption that it is deemed pretty unlikely
that nowadays people would only run PV guests on a host? Otherwise, assuming
that - like almost any such mitigation - its use costs performance, enabling
the mitigation only as long as there are any HVM guests around might be better.

> +	/* Avoid reading BP_CFG if we don't intend to change anything. */
> +	if (!new)
>  		return;
>  
>  	rdmsrl(MSR_AMD64_BP_CFG, val);
>  
> -	if (val & chickenbit)
> +	if ((val & new) == new)
>  		return;

Since bits may also need turning off:

	if (!((val ^ new) & (BP_CFG_SPEC_REDUCE | (1 << 5))))
		return;

and the !new early-out dropped, too? Looks like this wasn't quite right
before, either. 

> @@ -1078,22 +1082,41 @@ static void __init ibpb_calculations(void)
>           * Confusion.  Mitigate with IBPB-on-entry.
>           */
>          if ( !boot_cpu_has(X86_FEATURE_BTC_NO) )
> -            def_ibpb_entry = true;
> +            def_ibpb_entry_pv = def_ibpb_entry_hvm = true;
>  
>          /*
> -         * Further to BTC, Zen3/4 CPUs suffer from Speculative Return Stack
> -         * Overflow in most configurations.  Mitigate with IBPB-on-entry if we
> -         * have the microcode that makes this an effective option.
> +         * Further to BTC, Zen3 and later CPUs suffer from Speculative Return
> +         * Stack Overflow in most configurations.  Mitigate with IBPB-on-entry
> +         * if we have the microcode that makes this an effective option,
> +         * except where there are other mitigating factors available.
>           */

Hmm, is "Zen3 and later" really appropriate? Isn't your "speculative coding"
remark related to perhaps both of the new bits becoming available on Zen5
(meaning that the vulnerability would be limited to the guest/host boundary,
as long as the MSR-based mitigation isn't used)?

>          if ( !boot_cpu_has(X86_FEATURE_SRSO_NO) &&
>               boot_cpu_has(X86_FEATURE_IBPB_BRTYPE) )
> -            def_ibpb_entry = true;
> +        {
> +            /*
> +             * SRSO_U/S_NO is a subset of SRSO_NO, identifying that SRSO isn't
> +             * possible across the user/supervisor boundary.  We only need to
> +             * use IBPB-on-entry for PV guests on hardware which doesn't
> +             * enumerate SRSO_US_NO.
> +             */
> +            if ( !boot_cpu_has(X86_FEATURE_SRSO_US_NO) )
> +                def_ibpb_entry_pv = true;

opt_rsb_pv continues to take opt_pv32 into account, despite us having
removed security support for 32-bit PV guests (by wording that's sadly a
little ambiguous). Shouldn't that be done here too then, seeing that the
flag only covers transitions from ring3?

> --- a/xen/include/public/arch-x86/cpufeatureset.h
> +++ b/xen/include/public/arch-x86/cpufeatureset.h
> @@ -304,7 +304,9 @@ XEN_CPUFEATURE(FSRSC,              11*32+19) /*A  Fast Short REP SCASB */
>  XEN_CPUFEATURE(AMD_PREFETCHI,      11*32+20) /*A  PREFETCHIT{0,1} Instructions */
>  XEN_CPUFEATURE(SBPB,               11*32+27) /*A  Selective Branch Predictor Barrier */
>  XEN_CPUFEATURE(IBPB_BRTYPE,        11*32+28) /*A  IBPB flushes Branch Type predictions too */
> -XEN_CPUFEATURE(SRSO_NO,            11*32+29) /*A  Hardware not vulenrable to Speculative Return Stack Overflow */
> +XEN_CPUFEATURE(SRSO_NO,            11*32+29) /*A  Hardware not vulnerable to Speculative Return Stack Overflow */
> +XEN_CPUFEATURE(SRSO_US_NO,         11*32+30) /*A  Hardware not vulnerable to SRSO across the User/Supervisor boundary */

Can we validly expose this to 64-bit PV guests, where there's no CPL
boundary? Or else isn't my "x86/PV: issue branch prediction barrier
when switching 64-bit guest to kernel mode" needed as a prereq?

Jan


From xen-devel-bounces@lists.xenproject.org Tue Mar 26 10:06:02 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Mar 2024 10:06:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697982.1089264 (Exim 4.92)
	(envelope-from )
	id 1rp3gg-0001sM-J9; Tue, 26 Mar 2024 10:05:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697982.1089264; Tue, 26 Mar 2024 10:05:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rp3gg-0001sF-GI; Tue, 26 Mar 2024 10:05:46 +0000
Received: by outflank-mailman (input) for mailman id 697982;
 Tue, 26 Mar 2024 10:05:45 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rp3gf-0001s9-6f
 for xen-devel@lists.xenproject.org; Tue, 26 Mar 2024 10:05:45 +0000
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com
 [2a00:1450:4864:20::12e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 68773b80-eb58-11ee-afe3-a90da7624cb6;
 Tue, 26 Mar 2024 11:05:43 +0100 (CET)
Received: by mail-lf1-x12e.google.com with SMTP id
 2adb3069b0e04-512b3b04995so2864623e87.3
 for ; Tue, 26 Mar 2024 03:05:43 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 c15-20020a0564021f8f00b0056bfca6f1c0sm3389282edc.15.2024.03.26.03.05.42
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 26 Mar 2024 03:05:42 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 68773b80-eb58-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711447543; x=1712052343; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=YPEiTiOsp+UsOaJB/JITiMnayatA/5cfh+lrsTMq7oY=;
        b=RDzw0M3/ZhuY4VzUJQ6rfMuGXUhEkSsv376V2nzDX1e4RiyoG/mS9zOKYkAyz/bUyg
         qL9lfG0iRh8dOGEtiHd2PzqDfe3szwxr5b5M8DzcuJoP2NbVIp+VYJZ0h6lvDnq6Vg0I
         o/2Z8m/DuxOD4C0wfhlhULjpH40+7qXXyZwI0XQ28SrdGrzBBnP/M1L2bNe9k3RomP7U
         L+D61j6/a/RAvXN2Hk4N92018YyYUTRLcdNqrg6H8iZwctpLnerRtlC9iMG8FfD+N2/s
         T1ZpqM7O8cVMSekq56oU0y/06CClSAuoDlvvbHQQO68pqEJLlc7a6pTYdrTueZPiunNt
         4Bsg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711447543; x=1712052343;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=YPEiTiOsp+UsOaJB/JITiMnayatA/5cfh+lrsTMq7oY=;
        b=e9HS1aF2/ETi62kWs0LzkDlicNQDPTVsyk/mf15z+rqV6hoJnwZ/NN90PqtoYOJetk
         pdnUuG/e2lXrdxilv7bPLv/Uti1A1UouOp0c988OZf5cxKCdyERVc+s4+wkBpeUol0yr
         sdzQTD0mOW/nX8wqI8Ez7zh/5g1svNVGw4kfPSjyKwysQ3TPNQgb4yAGsgEe0+7uFwvq
         58w0Zgzdv5ijJ2eLkK9s5anttdjQghJMoP1qTX4Kug4Q/PXR7lZpchbFzD0IvfEZsvzH
         nwW5w4Q1g6vNk485b8jgYhyjcN6EEGjooJKcAqmZPI75nU2KzSTSTkrrvEl6/kTu4kok
         qGww==
X-Forwarded-Encrypted: i=1; AJvYcCWWNWIimcQqjYx4AFw9WfQGMJxSrJwFrdfTbcsJW+YB+K0dSPxzdnxkBNMCOtVl3eQHI1JogKiyS5fiv+qWQSlvBwxgZbKKgeB+c20jfWI=
X-Gm-Message-State: AOJu0Yyb36rSmJ23rivxjPoPBxH6SXVS9fX96l7FxDtYR/iKcAzN9ueZ
	uozOuLnNYZ6aAgtknVj5oB2SNjB5HI6Ybl3XWYqMrH7nWEXZ9J+RZpAjCKOtYQ==
X-Google-Smtp-Source: AGHT+IEr5nIWGdEjH99dww77jtGjl62HuoTFwus9njS7+Yo/TgTTR3WKktuWgNsO71FC+5IdaT0ejA==
X-Received: by 2002:a19:e046:0:b0:513:d1c7:7d37 with SMTP id g6-20020a19e046000000b00513d1c77d37mr5875950lfj.51.1711447543154;
        Tue, 26 Mar 2024 03:05:43 -0700 (PDT)
Message-ID: 
Date: Tue, 26 Mar 2024 11:05:41 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 09/11] x86/msi: address violation of MISRA C Rule 20.7
 and coding style
Content-Language: en-US
To: Nicola Vetrini 
Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com,
 ayan.kumar.halder@amd.com, consulting@bugseng.com,
 andrew.cooper3@citrix.com, roger.pau@citrix.com, bertrand.marquis@arm.com,
 julien@xen.org, xen-devel@lists.xenproject.org
References: 
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 22.03.2024 17:01, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be safe with respect to expansions that
> can possibly alter the semantics of the passed-in macro parameter.
> 
> While at it, the style of these macros has been somewhat uniformed.

Hmm, yes, but they then still leave more to be desired. I guess I can see
though why you don't want to e.g. ...

> --- a/xen/arch/x86/include/asm/msi.h
> +++ b/xen/arch/x86/include/asm/msi.h
> @@ -147,33 +147,34 @@ int msi_free_irq(struct msi_desc *entry);
>   */
>  #define NR_HP_RESERVED_VECTORS 	20
>  
> -#define msi_control_reg(base)		(base + PCI_MSI_FLAGS)
> -#define msi_lower_address_reg(base)	(base + PCI_MSI_ADDRESS_LO)
> -#define msi_upper_address_reg(base)	(base + PCI_MSI_ADDRESS_HI)
> -#define msi_data_reg(base, is64bit)	\
> -	( (is64bit == 1) ? base+PCI_MSI_DATA_64 : base+PCI_MSI_DATA_32 )
> -#define msi_mask_bits_reg(base, is64bit) \
> -	( (is64bit == 1) ? base+PCI_MSI_MASK_BIT : base+PCI_MSI_MASK_BIT-4)
> +#define msi_control_reg(base)        ((base) + PCI_MSI_FLAGS)
> +#define msi_lower_address_reg(base)  ((base) + PCI_MSI_ADDRESS_LO)
> +#define msi_upper_address_reg(base)  ((base) + PCI_MSI_ADDRESS_HI)
> +#define msi_data_reg(base, is64bit) \
> +    (((is64bit) == 1) ? (base) + PCI_MSI_DATA_64 : (base) + PCI_MSI_DATA_32)
> +#define msi_mask_bits_reg(base, is64bit)                \
> +    (((is64bit) == 1) ? (base) + PCI_MSI_MASK_BIT       \
> +                      : (base) + PCI_MSI_MASK_BIT - 4)

... drop the bogus == 1 in these two, making them similar to ...

>  #define msi_pending_bits_reg(base, is64bit) \
> -	((base) + PCI_MSI_MASK_BIT + ((is64bit) ? 4 : 0))
> -#define msi_disable(control)		control &= ~PCI_MSI_FLAGS_ENABLE
> +    ((base) + PCI_MSI_MASK_BIT + ((is64bit) ? 4 : 0))

... this.

> +#define msi_disable(control) (control) &= ~PCI_MSI_FLAGS_ENABLE

Doesn't this need an outer pair of parentheses, too?

>  #define multi_msi_capable(control) \
> -	(1 << ((control & PCI_MSI_FLAGS_QMASK) >> 1))
> +    (1 << (((control) & PCI_MSI_FLAGS_QMASK) >> 1))
>  #define multi_msi_enable(control, num) \
> -	control |= (((fls(num) - 1) << 4) & PCI_MSI_FLAGS_QSIZE);
> -#define is_64bit_address(control)	(!!(control & PCI_MSI_FLAGS_64BIT))
> -#define is_mask_bit_support(control)	(!!(control & PCI_MSI_FLAGS_MASKBIT))
> +    (control) |= (((fls(num) - 1) << 4) & PCI_MSI_FLAGS_QSIZE);

And this, together with dropping the bogus semicolon?

There also look to be cases where MASK_EXTR() / MASK_INSR() would want using,
in favor of using open-coded numbers.

> +#define is_64bit_address(control) (!!((control) & PCI_MSI_FLAGS_64BIT))
> +#define is_mask_bit_support(control) (!!((control) & PCI_MSI_FLAGS_MASKBIT))
>  #define msi_enable(control, num) multi_msi_enable(control, num); \
> -	control |= PCI_MSI_FLAGS_ENABLE
> -
> -#define msix_control_reg(base)		(base + PCI_MSIX_FLAGS)
> -#define msix_table_offset_reg(base)	(base + PCI_MSIX_TABLE)
> -#define msix_pba_offset_reg(base)	(base + PCI_MSIX_PBA)
> -#define msix_enable(control)	 	control |= PCI_MSIX_FLAGS_ENABLE
> -#define msix_disable(control)	 	control &= ~PCI_MSIX_FLAGS_ENABLE
> -#define msix_table_size(control) 	((control & PCI_MSIX_FLAGS_QSIZE)+1)
> -#define msix_unmask(address)	 	(address & ~PCI_MSIX_VECTOR_BITMASK)
> -#define msix_mask(address)		(address | PCI_MSIX_VECTOR_BITMASK)
> +                                 (control) |= PCI_MSI_FLAGS_ENABLE

This again is suspiciously missing outer parentheses; really here, with
the earlier statement, it look like do { ... } while ( 0 ) or ({ ... })
are wanted.

> +#define msix_control_reg(base)       ((base) + PCI_MSIX_FLAGS)
> +#define msix_table_offset_reg(base)  ((base) + PCI_MSIX_TABLE)
> +#define msix_pba_offset_reg(base)    ((base) + PCI_MSIX_PBA)
> +#define msix_enable(control)         (control) |= PCI_MSIX_FLAGS_ENABLE
> +#define msix_disable(control)        (control) &= ~PCI_MSIX_FLAGS_ENABLE

Outer parentheses missing for these two again?

Jan


From xen-devel-bounces@lists.xenproject.org Tue Mar 26 10:13:24 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Mar 2024 10:13:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697986.1089274 (Exim 4.92)
	(envelope-from )
	id 1rp3o0-0003ez-BH; Tue, 26 Mar 2024 10:13:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697986.1089274; Tue, 26 Mar 2024 10:13:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rp3o0-0003es-7T; Tue, 26 Mar 2024 10:13:20 +0000
Received: by outflank-mailman (input) for mailman id 697986;
 Tue, 26 Mar 2024 10:13:19 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rp3nz-0003ek-Eg
 for xen-devel@lists.xenproject.org; Tue, 26 Mar 2024 10:13:19 +0000
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com
 [2a00:1450:4864:20::62a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7762b915-eb59-11ee-afe3-a90da7624cb6;
 Tue, 26 Mar 2024 11:13:18 +0100 (CET)
Received: by mail-ej1-x62a.google.com with SMTP id
 a640c23a62f3a-a4715991c32so636630866b.1
 for ; Tue, 26 Mar 2024 03:13:18 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 u6-20020a1709063b8600b00a48f5845a7esm2390130ejf.150.2024.03.26.03.13.17
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 26 Mar 2024 03:13:17 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7762b915-eb59-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711447998; x=1712052798; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=pVo68FUrf3uH8D+4OGDxHtWdjPBnMPaOX7NViIqKKH4=;
        b=XESdNFxj3zElL1hQmEiFQtq4HrkbKWv/Bq82RxSA2H3nb/KpSED8FpuWAvOnPPajoC
         jKAowK3YvBrGlx71myYfKt/uLlH3OUU35pzRhfbU0GySojnOMPYxDCbkfP76+Nlw5tmB
         Lri6+JPUNQ74sbQ7P/BYFskaub5LVgj+3hWElbXWJ5oP8jQEsfuTheo0fSZu9ghgMIEc
         Ha5gfxZC8V1zGcJoYTy/diL14lEmBRTdeI8rnvU6szX8U2BqbEsgtWo4kzdLCnA4LaPt
         VczsU2f5ioSNEp17RxYIEW+/tqOo25nXCTHyg8qmDkeh+S2hSSXQ7uJpCRhyaWJchu0K
         +mTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711447998; x=1712052798;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=pVo68FUrf3uH8D+4OGDxHtWdjPBnMPaOX7NViIqKKH4=;
        b=TDNmlBK0YT3VxDj9hSmvHKMAmHrfunphF8U8OSfSf2xBDU/7ZvNlR+qTzm40NNT46L
         6npP04YKtHN5PzGL6Sr9XA8eV3Q1uliUQphrdemmfFsZfHf66f+E4MOQHH/zaZkGR+DK
         qJ8BSMkVsxmzmc5ItL2mb5Ic6FIJvGpbWJLio8jaOkDm3WXuI57x733l/zvbOQBXw3ts
         r805c3gmJXyo8Eo2g8hCHnjtWO9qyDQViY7BfT2NkbqklJ/3htu7q7nNejNyX37YkumT
         1sZju+KibVEgXzxJHb6sYmmzAQfV2c87wIhcwgaakunPRlmQjSP4Or58V389b8fGXbfP
         TPyw==
X-Forwarded-Encrypted: i=1; AJvYcCVbC31PsLreooqwoqWnlmPhBgzMY/RSYOgnkt5VnxM6sbqco/SqB5+TCFXPwViehzBwY+/jNP6k4A2ggq6zJt7SjAyt+9WtV7lpMAiMiwg=
X-Gm-Message-State: AOJu0YxjtkD9W7W2rDoLl3x97UaWHAAR5GIWK9PKnANdN0uqlikruz/N
	OICQrFZPnCe4OFVKnpTGrbHORMusMlcs5xG6ciO0aJDYUiGoWByZCYPhoiwqog==
X-Google-Smtp-Source: AGHT+IEqH3uUIY/JxHqswfMwO7Pi6ILNPrd+SIG/seYqnfKciSB+IFxO4wGDsFTGfrONZ/WVeLMyPA==
X-Received: by 2002:a17:907:944f:b0:a49:56d4:d643 with SMTP id dl15-20020a170907944f00b00a4956d4d643mr4703530ejc.36.1711447997919;
        Tue, 26 Mar 2024 03:13:17 -0700 (PDT)
Message-ID: <1c7475d7-b4ac-492f-8abd-2ab3b60c2a29@suse.com>
Date: Tue, 26 Mar 2024 11:13:16 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 10/11] x86/hvm: address violations of Rule 20.7
Content-Language: en-US
To: Nicola Vetrini 
Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com,
 ayan.kumar.halder@amd.com, consulting@bugseng.com,
 andrew.cooper3@citrix.com, roger.pau@citrix.com, bertrand.marquis@arm.com,
 julien@xen.org, xen-devel@lists.xenproject.org
References: 
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 22.03.2024 17:01, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be safe with respect to expansions that
> can possibly alter the semantics of the passed-in macro parameter.
> 
> No functional change.
> 
> Signed-off-by: Nicola Vetrini 

Acked-by: Jan Beulich 
albeit preferably with ...

> --- a/xen/arch/x86/include/asm/hvm/save.h
> +++ b/xen/arch/x86/include/asm/hvm/save.h
> @@ -128,9 +128,9 @@ static int __init cf_check __hvm_register_##_x##_save_and_restore(void)   \
>  {                                                                         \
>      hvm_register_savevm(HVM_SAVE_CODE(_x),                                \
>                          #_x,                                              \
> -                        &_save,                                           \
> +                        &(_save),                                         \
>                          check,                                            \
> -                        &_load,                                           \
> +                        &(_load),                                         \

... the &s dropped rather than parentheses added, as we already have it
for (the recently added) "check".

Jan


From xen-devel-bounces@lists.xenproject.org Tue Mar 26 10:15:56 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Mar 2024 10:15:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697989.1089284 (Exim 4.92)
	(envelope-from )
	id 1rp3qU-0004G1-Sw; Tue, 26 Mar 2024 10:15:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697989.1089284; Tue, 26 Mar 2024 10:15:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rp3qU-0004Fu-PD; Tue, 26 Mar 2024 10:15:54 +0000
Received: by outflank-mailman (input) for mailman id 697989;
 Tue, 26 Mar 2024 10:15:53 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rp3qT-0004Fo-79
 for xen-devel@lists.xenproject.org; Tue, 26 Mar 2024 10:15:53 +0000
Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com
 [2a00:1450:4864:20::52f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d2554d85-eb59-11ee-a1ef-f123f15fe8a2;
 Tue, 26 Mar 2024 11:15:51 +0100 (CET)
Received: by mail-ed1-x52f.google.com with SMTP id
 4fb4d7f45d1cf-56bdf81706aso5352125a12.2
 for ; Tue, 26 Mar 2024 03:15:51 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 fg15-20020a056402548f00b0056bff5bc492sm3207811edb.8.2024.03.26.03.15.50
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 26 Mar 2024 03:15:50 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d2554d85-eb59-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711448151; x=1712052951; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=Y6RyjBNLe/K7sFGgYxD45aFc5w1lg2bAYE2382XAceY=;
        b=FlUkR04LMrzEA33wAVR0dV6Gx7HJj6aH7gVqX1gNfYVo1VgA6GNcreMfG+poXF6WRX
         S7rLT8rllx07uBqUa4VrapG4HLcn6J5uHarK3Q4xNVIUQJdYUUWmVk0VvtalSOiHuSbW
         mCoGV4/pXc0dR35BUYOKOmYgp7ePlSQPJF3i4CIfutFbA90RY9WjnAOm0YUue5xJSYgf
         9Uv2jl2KMpCdxd818LaFEK/PxsrXAb/fxALBrvYIBH3aPpG/li4Ir+62a+iLnDapww+7
         EchfdzqofQhjUqkDi3PPhZ9qyc2UJJSM1IwGSTGFrX95Vs68f8f9sKV7u8SbIXIoh/Cn
         DHIg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711448151; x=1712052951;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=Y6RyjBNLe/K7sFGgYxD45aFc5w1lg2bAYE2382XAceY=;
        b=TNsF4WcNOLQEc912wb3GVSlCXoowtOwUtImgLFQO+saH19V6YS/XpyjUe542b0KU0I
         Z64dwReyP0ioSXl0q7NIXMfIak0xqG6T56CAOWpLHvgQBj9BY+vEusmM5iseA03rLo4+
         DmEDNHNaNA+Xgd8h0wQKsXw8B3Wd+mGkL0YHjqbWFLmsHABribq6+CpxcuYDVotPTOvq
         w0bkVwHU4F8CVhreuuMuj9LAYXkRKJzGxptVOmzEHQaB1CRvUyvDUnf6FTJwTz5K9Hb8
         jpqZS+4hvzHaD9+cmDOcCNaalbJ7blI31DO9S6ONGJ95WUTUm7BxwoWDQ7wZ/I9T+us+
         Wz+A==
X-Forwarded-Encrypted: i=1; AJvYcCW+ujpiNz1iusveJ7FiXXCoRE71TzKKdu2cOaDMj6MOLudzAW36BI0mOj61djCtiuCwRLVMoKFEZIYMKHcpqWUi3GZWaVkt+xo17QsWYuc=
X-Gm-Message-State: AOJu0Ywwv6unr4TdOBVUZOMqNmtfyBWOsNjuRxrpwS1c/4b/dKwrUNLs
	dFw4REUGS+iVtEy8PAvf69tJ/CGzoyUz/dFwYxhdqX/6xLknvQxqkzg0KGGLgw==
X-Google-Smtp-Source: AGHT+IHBG0F/lU4wrrO0FdkWmaQOTNcnwUm14w7QuLFAt6acVBB9E0fgM+GEav07HtFgX0gmoMDnOA==
X-Received: by 2002:a50:8706:0:b0:56c:19d2:85b2 with SMTP id i6-20020a508706000000b0056c19d285b2mr637000edb.35.1711448150622;
        Tue, 26 Mar 2024 03:15:50 -0700 (PDT)
Message-ID: <77f8990e-5809-4429-92d6-53bbddc89caa@suse.com>
Date: Tue, 26 Mar 2024 11:15:49 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 11/11] x86/public: hvm: address violations of MISRA C
 Rule 20.7
Content-Language: en-US
To: Nicola Vetrini 
Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com,
 ayan.kumar.halder@amd.com, consulting@bugseng.com,
 andrew.cooper3@citrix.com, roger.pau@citrix.com, bertrand.marquis@arm.com,
 julien@xen.org, xen-devel@lists.xenproject.org
References: 
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 22.03.2024 17:02, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be safe with respect to expansions that
> can possibly alter the semantics of the passed-in macro parameter.
> 
> No functional change.
> 
> Signed-off-by: Nicola Vetrini 

Acked-by: Jan Beulich 

> --- a/xen/include/public/arch-x86/xen.h
> +++ b/xen/include/public/arch-x86/xen.h
> @@ -36,7 +36,7 @@
>  #define __XEN_GUEST_HANDLE(name)        __guest_handle_ ## name
>  #define XEN_GUEST_HANDLE(name)          __XEN_GUEST_HANDLE(name)
>  #define XEN_GUEST_HANDLE_PARAM(name)    XEN_GUEST_HANDLE(name)
> -#define set_xen_guest_handle_raw(hnd, val)  do { (hnd).p = val; } while (0)
> +#define set_xen_guest_handle_raw(hnd, val)  do { (hnd).p = (val); } while (0)
>  #define set_xen_guest_handle(hnd, val) set_xen_guest_handle_raw(hnd, val)
>  
>  #if defined(__i386__)

Would have been nice though to do the same thing for Arm at the same time.
PPC and RISC-V already have "val" parenthesized there.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Mar 26 10:30:55 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Mar 2024 10:30:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.697994.1089295 (Exim 4.92)
	(envelope-from )
	id 1rp44w-0007VX-4m; Tue, 26 Mar 2024 10:30:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 697994.1089295; Tue, 26 Mar 2024 10:30:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rp44w-0007VQ-0Q; Tue, 26 Mar 2024 10:30:50 +0000
Received: by outflank-mailman (input) for mailman id 697994;
 Tue, 26 Mar 2024 10:30:48 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rp44u-0007VC-2U
 for xen-devel@lists.xenproject.org; Tue, 26 Mar 2024 10:30:48 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e7c0b778-eb5b-11ee-afe3-a90da7624cb6;
 Tue, 26 Mar 2024 11:30:46 +0100 (CET)
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 by support.bugseng.com (Postfix) with ESMTPA id 31E544EE0739;
 Tue, 26 Mar 2024 11:30:45 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e7c0b778-eb5b-11ee-afe3-a90da7624cb6
MIME-Version: 1.0
Date: Tue, 26 Mar 2024 11:30:45 +0100
From: Nicola Vetrini 
To: Jan Beulich 
Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com,
 ayan.kumar.halder@amd.com, consulting@bugseng.com,
 andrew.cooper3@citrix.com, roger.pau@citrix.com, bertrand.marquis@arm.com,
 julien@xen.org, xen-devel@lists.xenproject.org
Subject: Re: [XEN PATCH 08/11] x86/altcall: address violations of MISRA C Rule
 20.7
In-Reply-To: 
References: 
 <653ead65966226f50b0e4ae0268912c9710f9dba.1711118582.git.nicola.vetrini@bugseng.com>
 <072aa89b-2a03-4823-af72-28a2a882b373@suse.com>
 
 
Message-ID: <7394d0e65c4de7399bbace9e9a3fe38f@bugseng.com>
X-Sender: nicola.vetrini@bugseng.com
Organization: BUGSENG s.r.l.
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit

On 2024-03-25 15:58, Jan Beulich wrote:
> On 25.03.2024 15:47, Nicola Vetrini wrote:
>> On 2024-03-25 10:38, Jan Beulich wrote:
>>> On 22.03.2024 17:01, Nicola Vetrini wrote:
>>>> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
>>>> of macro parameters shall be enclosed in parentheses". Therefore, 
>>>> some
>>>> macro definitions should gain additional parentheses to ensure that
>>>> all
>>>> current and future users will be safe with respect to expansions 
>>>> that
>>>> can possibly alter the semantics of the passed-in macro parameter.
>>>> 
>>>> No functional change.
>>>> 
>>>> Signed-off-by: Nicola Vetrini 
>>> 
>>> Hmm. These macros are, at least in part, hard to read already. The
>>> added
>>> parentheses, while necessary when following the rule to the letter, 
>>> are
>>> making things worse, even if just slightly. I therefore have a 
>>> proposal
>>> /
>>> question:
>>> 
>>>> --- a/xen/arch/x86/include/asm/alternative.h
>>>> +++ b/xen/arch/x86/include/asm/alternative.h
>>>> @@ -243,28 +243,28 @@ extern void alternative_branches(void);
>>>> 
>>>>  #define alternative_vcall0(func) ({             \
>>>>      ALT_CALL_NO_ARG1;                           \
>>>> -    (void)sizeof(func());                       \
>>>> +    (void)sizeof((func)());                     \
>>> 
>>> Like this, all that's touched here are (syntactical, but not real)
>>> function
>>> invocations. Function calls, like all postfix operators, are highest
>>> precedence. Hence by omitting parentheses in that case no breakage 
>>> can
>>> happen as a result: If the passed expression is another postfix one,
>>> that'll
>>> be evaluated first anyway. If any other expression is passed (aside
>>> primary
>>> ones, of course), that'll be evaluated afterwards only due to being
>>> lower
>>> precedence, irrespective of the presence/absence of parentheses.
>>> 
>>> Therefore, where harmful to readability, can we perhaps leave postfix
>>> expressions alone?
>> 
>> While I can understand the benefits of this, and the reasoning on
>> postfix expressions, what about, for instance (modulo the actual
>> invocation, this is just an example)
>> 
>> alternative_vcall0(2 + f) or similar scenarios?
> 
> Any kind of such expression will break with alternative_callN()'s
> using of [addr] "i" (&(func)) as an asm() operand. Which clarifies
> that even of the postfix expressions only some (in particular not
> increment, decrement, and function call) could potentially be used
> with the altcall machinery.
> 
> That said, you have a point in (indirectly) expressing that my
> earlier description wasn't quite right (as in: too generic, when
> it really needs tying to the specific case here).
> 
> Jan

Ok, I see what you meant now. I'll deviate these two macros.

-- 
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)


From xen-devel-bounces@lists.xenproject.org Tue Mar 26 10:57:43 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Mar 2024 10:57:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698004.1089312 (Exim 4.92)
	(envelope-from )
	id 1rp4Ur-0002OW-HE; Tue, 26 Mar 2024 10:57:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698004.1089312; Tue, 26 Mar 2024 10:57:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rp4Ur-0002Nn-Dj; Tue, 26 Mar 2024 10:57:37 +0000
Received: by outflank-mailman (input) for mailman id 698004;
 Tue, 26 Mar 2024 10:57:36 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rp4Uq-0002JT-AZ
 for xen-devel@lists.xenproject.org; Tue, 26 Mar 2024 10:57:36 +0000
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com
 [2a00:1450:4864:20::62c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a66a23db-eb5f-11ee-a1ef-f123f15fe8a2;
 Tue, 26 Mar 2024 11:57:34 +0100 (CET)
Received: by mail-ej1-x62c.google.com with SMTP id
 a640c23a62f3a-a46cca2a979so313226766b.3
 for ; Tue, 26 Mar 2024 03:57:34 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a66a23db-eb5f-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1711450653; x=1712055453; darn=lists.xenproject.org;
        h=to:subject:message-id:date:from:mime-version:from:to:cc:subject
         :date:message-id:reply-to;
        bh=Lh6B8CHuzyOOd1+Ai6KB5EaERHcxQgMVWPPoH2rBX/0=;
        b=iW2+K23Od2YpCrQ4xMxdXtWNd32YMR+vkX9yUSBvzuOmBHupnBpRwWjjib8cw7HdVW
         qcJuYo0kWrqBgrGze6HXKD7uVNyw2YQCSJ25ManWDrT+PcnMYfjnyzVEXUkJDL0DRjz4
         bc/kkdK2wJS6A8gt6W9AerwjTlcmmZNC8qfmQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711450653; x=1712055453;
        h=to:subject:message-id:date:from:mime-version:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=Lh6B8CHuzyOOd1+Ai6KB5EaERHcxQgMVWPPoH2rBX/0=;
        b=tafUbTqX0kqgA6mPONhwAFy7IMKOhuF2c3W6TwpAPvbMdsma18mYhzqx25Vb0PAVJL
         SAYbwlGJXJSpcz6lZYHwsrud/QkT0HgNwEtrLyLMgwRD8RcBavKyOE3oLp46R/q7irke
         49QB2z8vB3SXKFNc4vxTj3j+TVeoSLvwnYgiWLA6no1qvgHWzaW4nba8f8aCO7X/yH/5
         En8nnZ4DSAHZe4kKVlPHuItL1PnpCOomka421mCX8gjDshY59UzKGF/N/QizvqQZFyBF
         SHoh1fRQusOMZCGISJJGPMOA3cYEKRCfej1JXytYBCdKiIdgteNHwpL24KMtZpuAfiUv
         7DNQ==
X-Gm-Message-State: AOJu0YymsUY5kYzs6hoHZ2d6XyrV3Vjf4CXpk4JGqrN4iEcu5AAzwwZR
	OUzfJFOWiExvvHoM8i3b+s6nJu5yu9o/6lyyMLQh0vsuzoueOdI2wppS8tXUH5leAlx4Z0BFpTe
	vQcIH/DIS6bk6FqpNw941f+PancDF+Fb8+Z4+Py3e7eX0jzRyfD98Nw==
X-Google-Smtp-Source: AGHT+IFLCUe8qdyPQRnk9kvh8FnKocukw1RUsoSwW2IG35UNzuxL1QyR9FTIFi1BLSbZ4ZErLTpxnDlyehLiUey/sXc=
X-Received: by 2002:a50:d651:0:b0:566:ab2b:e1ce with SMTP id
 c17-20020a50d651000000b00566ab2be1cemr8266493edj.18.1711450653418; Tue, 26
 Mar 2024 03:57:33 -0700 (PDT)
MIME-Version: 1.0
From: Kelly Choi 
Date: Tue, 26 Mar 2024 10:56:57 +0000
Message-ID: 
Subject: Join the conversation on Matrix
To: xen-devel , xen-users@lists.xenproject.org
Content-Type: multipart/alternative; boundary="0000000000003f8e9e06148e284e"

--0000000000003f8e9e06148e284e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello Xen Community,

We welcome all new and existing members to join the conversation.

Other than mailing lists, most of us are active on Matrix.

Join us below:

*XenProject* 
For general queries and updates about the software. This channel is mainly
for users and community members.

*XenDevel* 
For developers =E2=80=93 if you have submitted patches to the developer mai=
ling
lists or are otherwise active on them, this channel is for you. It=E2=80=99=
s also
the best place to ask development-related questions to the Xen Project.

*XenSocial* 
For community introductions, tech news, and your watercooler chats.

Don't forget to introduce yourself!

Many thanks,
Kelly Choi

Community Manager
Xen Project

--0000000000003f8e9e06148e284e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hello Xen Community,

We welcome all new=
 and existing members to join the conversation.

Ot=
her than mailing lists, most of us are active on Matrix.=C2=A0
Join us below:

For genera=
l queries and updates about the software. This channel is mainly for users =
and community members.

For developers =E2=
=80=93 if you have submitted patches to the developer mailing lists or are =
otherwise active on them, this channel is for you. It=E2=80=99s also the be=
st place to ask development-related questions to the Xen Project.

For community introductions, tech news, and your =
watercooler chats.

Don't forget to introduce y=
ourself!

Many thanks,
Kelly Choi

Community Manager
X=
en Project=C2=A0


--0000000000003f8e9e06148e284e--


From xen-devel-bounces@lists.xenproject.org Tue Mar 26 11:00:56 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Mar 2024 11:00:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698022.1089332 (Exim 4.92)
	(envelope-from )
	id 1rp4Y2-00055h-WA; Tue, 26 Mar 2024 11:00:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698022.1089332; Tue, 26 Mar 2024 11:00:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rp4Y2-00055a-Td; Tue, 26 Mar 2024 11:00:54 +0000
Received: by outflank-mailman (input) for mailman id 698022;
 Tue, 26 Mar 2024 11:00:53 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1rp4Y1-00055Q-2j
 for xen-devel@lists.xenproject.org; Tue, 26 Mar 2024 11:00:53 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rp4Y0-0002UI-Kc; Tue, 26 Mar 2024 11:00:52 +0000
Received: from [15.248.2.236] (helo=[10.24.67.40])
 by xenbits.xenproject.org with esmtpsa
 (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92)
 (envelope-from )
 id 1rp4Y0-0006D0-DW; Tue, 26 Mar 2024 11:00:52 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Cc:
	References:To:Subject:MIME-Version:Date:Message-ID;
	bh=QWZofwvmlVWbl5uv5eb9W6/ukSSMKSt7x/77RKFCzpE=; b=bYMz4l5YHYh1WXqnDJJDTNSFTi
	TSAyyiEDGhkPszNy/708sipL7Yb3xPxxkgaBEFmRcshEmYz6YLpEnvMea85U+cA/fKYqvrAmQ27Ns
	qJb3mdyadBab6leB93uDIs+nYxSDadZ5DT7cH3kX9xvpiY9pbiQzvR7ABHfsJ/eW6PGo=;
Message-ID: <0f8c0e27-e60d-4e64-bc8a-6cb407c67ab2@xen.org>
Date: Tue, 26 Mar 2024 11:00:50 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: NULL pointer dereference in xenbus_thread->...
Content-Language: en-GB
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 , xen-devel 
References:  
 
Cc: Juergen Gross 
From: Julien Grall 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Marek,

+Juergen for visibility

When sending a bug report, I would suggest to CC relevant people as 
otherwise it can get lost (not may people monitors Xen devel if they are 
not CCed).

Cheers,

On 25/03/2024 16:17, Marek Marczykowski-Górecki wrote:
> On Sun, Oct 22, 2023 at 04:14:30PM +0200, Marek Marczykowski-Górecki wrote:
>> On Mon, Aug 28, 2023 at 11:50:36PM +0200, Marek Marczykowski-Górecki wrote:
>>> Hi,
>>>
>>> I've noticed in Qubes's CI failure like this:
>>>
>>> [  871.271292] BUG: kernel NULL pointer dereference, address: 0000000000000000
>>> [  871.275290] #PF: supervisor read access in kernel mode
>>> [  871.277282] #PF: error_code(0x0000) - not-present page
>>> [  871.279182] PGD 106fdb067 P4D 106fdb067 PUD 106fdc067 PMD 0
>>> [  871.281071] Oops: 0000 [#1] PREEMPT SMP NOPTI
>>> [  871.282698] CPU: 1 PID: 28 Comm: xenbus Not tainted 6.1.43-1.qubes.fc37.x86_64 #1
>>> [  871.285222] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552-rebuilt.opensuse.org 04/01/2014
>>> [  871.288883] RIP: e030:__wake_up_common+0x4c/0x180
>>> [  871.292838] Code: 24 0c 89 4c 24 08 4d 85 c9 74 0a 41 f6 01 04 0f 85 a3 00 00 00 48 8b 43 08 4c 8d 40 e8 48 83 c3 08 49 8d 40 18 48 39 c3 74 5b <49> 8b 40 18 31 ed 4c 8d 70 e8 45 8b 28 41 f6 c5 04 75 5f 49 8b 40
>>> [  871.299776] RSP: e02b:ffffc900400f7e10 EFLAGS: 00010082
>>> [  871.301656] RAX: 0000000000000000 RBX: ffff88810541ce98 RCX: 0000000000000000
>>> [  871.304255] RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffff88810541ce90
>>> [  871.306714] RBP: ffffc900400f0280 R08: ffffffffffffffe8 R09: ffffc900400f7e68
>>> [  871.309937] R10: 0000000000007ff0 R11: ffff888100ad3000 R12: ffffc900400f7e68
>>> [  871.312326] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
>>> [  871.314647] FS:  0000000000000000(0000) GS:ffff88813ff00000(0000) knlGS:0000000000000000
>>> [  871.317677] CS:  10000e030 DS: 0000 ES: 0000 CR0: 0000000080050033
>>> [  871.319644] CR2: 0000000000000000 CR3: 00000001067fe000 CR4: 0000000000040660
>>> [  871.321973] Call Trace:
>>> [  871.322782]  
>>> [  871.323494]  ? show_trace_log_lvl+0x1d3/0x2ef
>>> [  871.324901]  ? show_trace_log_lvl+0x1d3/0x2ef
>>> [  871.326310]  ? show_trace_log_lvl+0x1d3/0x2ef
>>> [  871.327721]  ? __wake_up_common_lock+0x82/0xd0
>>> [  871.329147]  ? __die_body.cold+0x8/0xd
>>> [  871.330378]  ? page_fault_oops+0x163/0x1a0
>>> [  871.331691]  ? exc_page_fault+0x70/0x170
>>> [  871.332946]  ? asm_exc_page_fault+0x22/0x30
>>> [  871.334454]  ? __wake_up_common+0x4c/0x180
>>> [  871.335777]  __wake_up_common_lock+0x82/0xd0
>>> [  871.337183]  ? process_writes+0x240/0x240
>>> [  871.338461]  process_msg+0x18e/0x2f0
>>> [  871.339627]  xenbus_thread+0x165/0x1c0
>>> [  871.340830]  ? cpuusage_read+0x10/0x10
>>> [  871.342032]  kthread+0xe9/0x110
>>> [  871.343317]  ? kthread_complete_and_exit+0x20/0x20
>>> [  871.345020]  ret_from_fork+0x22/0x30
>>> [  871.346239]  
>>> [  871.347060] Modules linked in: snd_hda_codec_generic ledtrig_audio snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec snd_hda_core snd_hwdep snd_seq snd_seq_device joydev snd_pcm intel_rapl_msr ppdev intel_rapl_common snd_timer pcspkr e1000e snd soundcore i2c_piix4 parport_pc parport loop fuse xenfs dm_crypt crct10dif_pclmul crc32_pclmul crc32c_intel polyval_clmulni polyval_generic floppy ghash_clmulni_intel sha512_ssse3 serio_raw virtio_scsi virtio_console bochs xhci_pci xhci_pci_renesas xhci_hcd qemu_fw_cfg drm_vram_helper drm_ttm_helper ttm ata_generic pata_acpi xen_privcmd xen_pciback xen_blkback xen_gntalloc xen_gntdev xen_evtchn scsi_dh_rdac scsi_dh_emc scsi_dh_alua uinput dm_multipath
>>> [  871.368892] CR2: 0000000000000000
>>> [  871.370160] ---[ end trace 0000000000000000 ]---
>>> [  871.371719] RIP: e030:__wake_up_common+0x4c/0x180
>>> [  871.373273] Code: 24 0c 89 4c 24 08 4d 85 c9 74 0a 41 f6 01 04 0f 85 a3 00 00 00 48 8b 43 08 4c 8d 40 e8 48 83 c3 08 49 8d 40 18 48 39 c3 74 5b <49> 8b 40 18 31 ed 4c 8d 70 e8 45 8b 28 41 f6 c5 04 75 5f 49 8b 40
>>> [  871.379866] RSP: e02b:ffffc900400f7e10 EFLAGS: 00010082
>>> [  871.381689] RAX: 0000000000000000 RBX: ffff88810541ce98 RCX: 0000000000000000
>>> [  871.383971] RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffff88810541ce90
>>> [  871.386235] RBP: ffffc900400f0280 R08: ffffffffffffffe8 R09: ffffc900400f7e68
>>> [  871.388521] R10: 0000000000007ff0 R11: ffff888100ad3000 R12: ffffc900400f7e68
>>> [  871.390789] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
>>> [  871.393101] FS:  0000000000000000(0000) GS:ffff88813ff00000(0000) knlGS:0000000000000000
>>> [  871.395671] CS:  10000e030 DS: 0000 ES: 0000 CR0: 0000000080050033
>>> [  871.397863] CR2: 0000000000000000 CR3: 00000001067fe000 CR4: 0000000000040660
>>> [  871.400441] Kernel panic - not syncing: Fatal exception
>>> [  871.402171] Kernel Offset: disabled
>>> (XEN) Hardware Dom0 crashed: rebooting machine in 5 seconds.
>>>
>>> It isn't the first time I see similar crash, but I can't really
>>> reproduce it reliably. Restarted test usually passes.
>>> Note this is Xen nested in KVM, so it could very well be some oddity
>>> about nested virt, although looking at the stack trace, it's unlikely
>>> and more likely some race condition hit only on slower system.
>>
>> Recently I've got the same crash on a real system in domU too. And also
>> on nested on newer kernel 6.1.57 (here it happened in dom0). So, this is
>> still an issue and affects not only nested case :/
>>
>>> Unfortunately I don't have symbols for this kernel handy, but there is a
>>> single wake_up() call in process_writes(), so it shouldn't be an issue.
>>>
>>> Any ideas?
>>>
>>> Full log at https://openqa.qubes-os.org/tests/80779/logfile?filename=serial0.txt
>>
>> More links at https://github.com/QubesOS/qubes-issues/issues/8638,
>> including more recent stack trace.
> 
> Happens on 6.1.75 too (new stack trace I've added to the issue above,
> but it's pretty similar).
> 

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Tue Mar 26 11:28:39 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Mar 2024 11:28:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698036.1089343 (Exim 4.92)
	(envelope-from )
	id 1rp4yh-0000PT-4V; Tue, 26 Mar 2024 11:28:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698036.1089343; Tue, 26 Mar 2024 11:28:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rp4yh-0000PM-1J; Tue, 26 Mar 2024 11:28:27 +0000
Received: by outflank-mailman (input) for mailman id 698036;
 Tue, 26 Mar 2024 11:28:25 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rp4yf-0000Op-9Q; Tue, 26 Mar 2024 11:28:25 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rp4yf-0002vl-0X; Tue, 26 Mar 2024 11:28:25 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rp4ye-0002TC-M6; Tue, 26 Mar 2024 11:28:24 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rp4ye-0004uY-Le; Tue, 26 Mar 2024 11:28:24 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=Qr11I2Ehw9WIS1pRCxEUdyB09QLKqYzih7QGv8+WKzo=; b=ZxfXUFynq1DovrjGQLxiAgPhza
	Luerb/Yxbe+F3badu/46JLiRQJhNUvcKycT4ZEtYQ61C2qPuXbPBq6UJGSqCQNmwyt7Y2Ta3cINLg
	yRyDCD0QG0AzVwBZtIUUo5t6nOYVqmZKiHT68j/jMCi4pCw0kjXP/MVv/nljQXqteEsg=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 185162: tolerable FAIL
X-Osstest-Failures:
    xen-unstable:test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict:xen-install:fail:heisenbug
    xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-qcow2:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-qcow2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-vhd:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-raw:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    xen=6f6de10ade5ade907f9e3f3c72b7b18f7852d9ff
X-Osstest-Versions-That:
    xen=6f6de10ade5ade907f9e3f3c72b7b18f7852d9ff
From: osstest service owner 
Date: Tue, 26 Mar 2024 11:28:24 +0000

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-install fail pass in 185158

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

version targeted for testing:
 xen                  6f6de10ade5ade907f9e3f3c72b7b18f7852d9ff
baseline version:
 xen                  6f6de10ade5ade907f9e3f3c72b7b18f7852d9ff

Last test of basis   185162  2024-03-26 01:55:35 Z    0 days
Testing same since                          (not found)         0 attempts

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        fail    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-libvirt-qcow2                               pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-xl-qcow2                                    pass    
 test-amd64-amd64-libvirt-raw                                 pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-amd64-amd64-xl-raw                                      pass    
 test-armhf-armhf-xl-raw                                      pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-libvirt-vhd                                 pass    
 test-amd64-amd64-xl-vhd                                      pass    
 test-arm64-arm64-xl-vhd                                      pass    


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

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

Explanation of these 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


Published tested tree is already up to date.



From xen-devel-bounces@lists.xenproject.org Tue Mar 26 11:33:49 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Mar 2024 11:33:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698041.1089353 (Exim 4.92)
	(envelope-from )
	id 1rp53n-0002NJ-Rm; Tue, 26 Mar 2024 11:33:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698041.1089353; Tue, 26 Mar 2024 11:33:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rp53n-0002NC-Or; Tue, 26 Mar 2024 11:33:43 +0000
Received: by outflank-mailman (input) for mailman id 698041;
 Tue, 26 Mar 2024 11:33:42 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rp53m-0002N6-4k
 for xen-devel@lists.xenproject.org; Tue, 26 Mar 2024 11:33:42 +0000
Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com
 [2a00:1450:4864:20::131])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b0df6841-eb64-11ee-a1ef-f123f15fe8a2;
 Tue, 26 Mar 2024 12:33:39 +0100 (CET)
Received: by mail-lf1-x131.google.com with SMTP id
 2adb3069b0e04-515a81928faso2771957e87.1
 for ; Tue, 26 Mar 2024 04:33:39 -0700 (PDT)
Received: from [10.80.67.139] (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 u14-20020a056402110e00b0056bfc48406csm3570825edv.7.2024.03.26.04.33.37
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 26 Mar 2024 04:33:38 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b0df6841-eb64-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1711452819; x=1712057619; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=DFihbIHx519vetj8heH7cI1+jYi3MJxoJ9N464/WuLY=;
        b=nTHxUsnLI7WCA8qddhi3WJrzR36+KSgqOKh6q1JAz8CRpgp33nkSSqfSEW6+jKjZnD
         rahIiw8PxrD8mLDFelsc+Or7qRDlGLHzOqLLOyHZEeSzhcTNHXgVysVbj+jpVpvZOGsA
         N6rJVEyDhZWvUgRZ/WmeGtvvWF94siHkzxknw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711452819; x=1712057619;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=DFihbIHx519vetj8heH7cI1+jYi3MJxoJ9N464/WuLY=;
        b=CxIWRAQnHfDG9neM7M9rofAimWb1MqNXUQjs/STQ6ZiIvAwI5viulIx07Lavw1VKrx
         VGgo1JCbgg47JgC2oZGz2O58xqnzWegUWiQEGiZ1KgyTCKxZES6EuL0KtfeCvwVmXA8m
         qXz/04V5Oie6BwJhVUB3IYs/8Rkp4QaKrCYtNY/MmKM/VmmGLNJgni3Cu9jHSyOTDyR4
         aUOtWrqrIa1KWYLWLB8ic+G1k6veINf7piTq97+dO06p2x1G2VXOxL0UrdeYmuZts6OP
         7JGR8lvMkLzlNUm/E0cG/LOT1tq5kAMz7VsiRHGmb01hoF8qre1hmHZcL71OHy4WdjCH
         5KSA==
X-Forwarded-Encrypted: i=1; AJvYcCXZzMB05xz3zIs5xqHc1udGANiJuts6ih5+DAPG8YL6g1OpEimnphk6IdwDm69GKuv9gORyY3XIdsS4FIuRBZVeKGSIpfP8Ke4tP+Gtyso=
X-Gm-Message-State: AOJu0Yy1OAlVmHTXoMU4VACaBjY89bbf7l76uBfSbYYh3xgK53Jam/Qg
	B5Gmw6gbJb9w9EPC5z/9+kbFpVnD17qu4y2wgTS36AQejHLjokCgdYeR0x7E8Gw=
X-Google-Smtp-Source: AGHT+IE9guz682ae5nwhIVGQbiEVR0ZelppmFhDTjh07D3Cs5qUGMCkOrmVpbSoM46s5BRrE3RN+kg==
X-Received: by 2002:a19:5f14:0:b0:513:27a1:24cb with SMTP id t20-20020a195f14000000b0051327a124cbmr646780lfb.51.1711452818541;
        Tue, 26 Mar 2024 04:33:38 -0700 (PDT)
Message-ID: <78be9d6c-2b3d-43ad-92fe-23d58767e2d6@citrix.com>
Date: Tue, 26 Mar 2024 11:33:37 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/spec-ctrl: Support for SRSO_US_NO and SRSO_MSR_FIX
Content-Language: en-GB
To: Jan Beulich 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Xen-devel 
References: <20240325181830.638680-1-andrew.cooper3@citrix.com>
 
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 26/03/2024 9:13 am, Jan Beulich wrote:
> On 25.03.2024 19:18, Andrew Cooper wrote:
>> --- a/docs/misc/xen-command-line.pandoc
>> +++ b/docs/misc/xen-command-line.pandoc
>> @@ -2377,7 +2377,8 @@ By default SSBD will be mitigated at runtime (i.e `ssbd=runtime`).
>>  >              {msr-sc,rsb,verw,ibpb-entry}=|{pv,hvm}=,
>>  >              bti-thunk=retpoline|lfence|jmp, {ibrs,ibpb,ssbd,psfd,
>>  >              eager-fpu,l1d-flush,branch-harden,srb-lock,
>> ->              unpriv-mmio,gds-mit,div-scrub,lock-harden}= ]`
>> +>              unpriv-mmio,gds-mit,div-scrub,lock-harden,
>> +>              bp-spec-reduce}= ]`
>>  
>>  Controls for speculative execution sidechannel mitigations.  By default, Xen
>>  will pick the most appropriate mitigations based on compiled in support,
>> @@ -2509,6 +2510,12 @@ boolean can be used to force or prevent Xen from using speculation barriers to
>>  protect lock critical regions.  This mitigation won't be engaged by default,
>>  and needs to be explicitly enabled on the command line.
>>  
>> +On hardware supporting SRSO_MSR_FIX, the `bp-spec-reduce=` option can be used
>> +to force or prevent Xen from using MSR_BP_CFG.BP_SPEC_REDUCE to mitigate the
>> +SRSO (Speculative Return Stack Overflow) vulnerability.
> "... against HVM guests" to avoid things being left ambiguous, and to also ...
>
>>  By default, Xen will
>> +use bp-spec-reduce when available, as it preferable to using `ibpb-entry=hvm`
>> +to mitigate SRSO.
> ... correlate with the `ibpb-entry=hvm` here?

Ok.

> Maybe at the start of the paragraph also add "AMD"?

The rest of the text specifically doesn't mention vendors, in an attempt
to prevent it going stale.

Although now I re-read it, it makes the statements about microcode drops
ambiguous.

>
>> --- a/xen/arch/x86/cpu/amd.c
>> +++ b/xen/arch/x86/cpu/amd.c
>> @@ -1009,16 +1009,31 @@ static void cf_check fam17_disable_c6(void *arg)
>>  	wrmsrl(MSR_AMD_CSTATE_CFG, val & mask);
>>  }
>>  
>> -static void amd_check_erratum_1485(void)
>> +static void amd_check_bp_cfg(void)
>>  {
>> -	uint64_t val, chickenbit = (1 << 5);
>> +	uint64_t val, new = 0;
>>  
>> -	if (cpu_has_hypervisor || boot_cpu_data.x86 != 0x19 || !is_zen4_uarch())
>> +	/*
>> +	 * AMD Erratum #1485.  Set bit 5, as instructed.
>> +	 */
>> +	if (!cpu_has_hypervisor && boot_cpu_data.x86 == 0x19 && is_zen4_uarch())
>> +		new |= (1 << 5);
>> +
>> +	/*
>> +	 * On hardware supporting SRSO_MSR_FIX, we prefer BP_SPEC_REDUCE to
>> +	 * IBPB-on-entry to mitigate SRSO for HVM guests.
>> +	 */
>> +	if (IS_ENABLED(CONFIG_HVM) && boot_cpu_has(X86_FEATURE_SRSO_US_NO) &&
>> +            opt_bp_spec_reduce)
> Nit: Indentation is odd here (wants to be a tab followed by a few spaces).
>
>> +		new |= BP_CFG_SPEC_REDUCE;
> I take it that this goes from the assumption that it is deemed pretty unlikely
> that nowadays people would only run PV guests on a host? Otherwise, assuming
> that - like almost any such mitigation - its use costs performance, enabling
> the mitigation only as long as there are any HVM guests around might be better.

I have no idea what the perf cost is.  Native systems are expected not
to use this.

However, I have no care to try and make this dynamic based on having HVM
guests active.  For one, it would need a real spinlock to avoid the MSR
race, or a stop machine context, and anyone running PV guests on this
hardware really oughtn't to be.

[Edit, See later, but we need this for PV too]

>
>> +	/* Avoid reading BP_CFG if we don't intend to change anything. */
>> +	if (!new)
>>  		return;
>>  
>>  	rdmsrl(MSR_AMD64_BP_CFG, val);
>>  
>> -	if (val & chickenbit)
>> +	if ((val & new) == new)
>>  		return;
> Since bits may also need turning off:
>
> 	if (!((val ^ new) & (BP_CFG_SPEC_REDUCE | (1 << 5))))
> 		return;
>
> and the !new early-out dropped, too? Looks like this wasn't quite right
> before, either. 

That's adding unnecessary complexity.  It's unlikely that we'll ever
need to clear bits like this.

>
>> @@ -1078,22 +1082,41 @@ static void __init ibpb_calculations(void)
>>           * Confusion.  Mitigate with IBPB-on-entry.
>>           */
>>          if ( !boot_cpu_has(X86_FEATURE_BTC_NO) )
>> -            def_ibpb_entry = true;
>> +            def_ibpb_entry_pv = def_ibpb_entry_hvm = true;
>>  
>>          /*
>> -         * Further to BTC, Zen3/4 CPUs suffer from Speculative Return Stack
>> -         * Overflow in most configurations.  Mitigate with IBPB-on-entry if we
>> -         * have the microcode that makes this an effective option.
>> +         * Further to BTC, Zen3 and later CPUs suffer from Speculative Return
>> +         * Stack Overflow in most configurations.  Mitigate with IBPB-on-entry
>> +         * if we have the microcode that makes this an effective option,
>> +         * except where there are other mitigating factors available.
>>           */
> Hmm, is "Zen3 and later" really appropriate?

Yes.

SRSO isn't fixed until SRSO_NO is enumerated.

> Isn't your "speculative coding"
> remark related to perhaps both of the new bits becoming available on Zen5
> (meaning that the vulnerability would be limited to the guest/host boundary,
> as long as the MSR-based mitigation isn't used)?

Both of these are interim fixes.
>>          if ( !boot_cpu_has(X86_FEATURE_SRSO_NO) &&
>>               boot_cpu_has(X86_FEATURE_IBPB_BRTYPE) )
>> -            def_ibpb_entry = true;
>> +        {
>> +            /*
>> +             * SRSO_U/S_NO is a subset of SRSO_NO, identifying that SRSO isn't
>> +             * possible across the user/supervisor boundary.  We only need to
>> +             * use IBPB-on-entry for PV guests on hardware which doesn't
>> +             * enumerate SRSO_US_NO.
>> +             */
>> +            if ( !boot_cpu_has(X86_FEATURE_SRSO_US_NO) )
>> +                def_ibpb_entry_pv = true;
> opt_rsb_pv continues to take opt_pv32 into account, despite us having
> removed security support for 32-bit PV guests (by wording that's sadly a
> little ambiguous). Shouldn't that be done here too then, seeing that the
> flag only covers transitions from ring3?

Hmm, probably.

In practice, all these systems have CET so PV32 will be off-by-default,
but if people really want to run PV32 guests, we might as well do our best.

>
>> --- a/xen/include/public/arch-x86/cpufeatureset.h
>> +++ b/xen/include/public/arch-x86/cpufeatureset.h
>> @@ -304,7 +304,9 @@ XEN_CPUFEATURE(FSRSC,              11*32+19) /*A  Fast Short REP SCASB */
>>  XEN_CPUFEATURE(AMD_PREFETCHI,      11*32+20) /*A  PREFETCHIT{0,1} Instructions */
>>  XEN_CPUFEATURE(SBPB,               11*32+27) /*A  Selective Branch Predictor Barrier */
>>  XEN_CPUFEATURE(IBPB_BRTYPE,        11*32+28) /*A  IBPB flushes Branch Type predictions too */
>> -XEN_CPUFEATURE(SRSO_NO,            11*32+29) /*A  Hardware not vulenrable to Speculative Return Stack Overflow */
>> +XEN_CPUFEATURE(SRSO_NO,            11*32+29) /*A  Hardware not vulnerable to Speculative Return Stack Overflow */
>> +XEN_CPUFEATURE(SRSO_US_NO,         11*32+30) /*A  Hardware not vulnerable to SRSO across the User/Supervisor boundary */
> Can we validly expose this to 64-bit PV guests, where there's no CPL
> boundary? Or else isn't my "x86/PV: issue branch prediction barrier
> when switching 64-bit guest to kernel mode" needed as a prereq?

Based on uarch details, if BP-SPEC-REDUCE is active, we can advertise
SRSO_US_NO to PV guests.

But I doubt I'll be able to persuade AMD to put the safety details
behind this in writing.


I also missed the hunks adding SRSO_US_NO and SRSO_MSR_FIX to
print_details().  Fixed locally.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Mar 26 12:29:09 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Mar 2024 12:29:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698063.1089364 (Exim 4.92)
	(envelope-from )
	id 1rp5vE-0001w5-4S; Tue, 26 Mar 2024 12:28:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698063.1089364; Tue, 26 Mar 2024 12:28:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rp5vD-0001vy-VR; Tue, 26 Mar 2024 12:28:55 +0000
Received: by outflank-mailman (input) for mailman id 698063;
 Tue, 26 Mar 2024 12:28:54 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rp5vC-0001vs-Nc
 for xen-devel@lists.xenproject.org; Tue, 26 Mar 2024 12:28:54 +0000
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com
 [2a00:1450:4864:20::335])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 68658603-eb6c-11ee-afe3-a90da7624cb6;
 Tue, 26 Mar 2024 13:28:53 +0100 (CET)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-4148c5de23fso7647445e9.1
 for ; Tue, 26 Mar 2024 05:28:53 -0700 (PDT)
Received: from perard.uk.xensource.com (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 h19-20020a05600c315300b004146a1bf590sm11474364wmo.32.2024.03.26.05.28.52
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 26 Mar 2024 05:28:52 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 68658603-eb6c-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1711456133; x=1712060933; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=mkMAk9/rqgY4mERx4ZT5H+A9HUYOAOACv8KMOJ8WR14=;
        b=Z8NE8ydY6hfm4XROqt6u9UQI76B/1WeJB730TfF3i2VkT/JBY0ufH4Meu6cJ2PqQ0p
         zvxnSFBTIc8a9ex19bxVS+UYs40M2pauElTQyytcLlgOp9vBYjWOx1Hf+DV8431mfZL9
         ByJg/ymQRMC5WKuxZTtQXr3/kciTSBRQ+l0yM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711456133; x=1712060933;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=mkMAk9/rqgY4mERx4ZT5H+A9HUYOAOACv8KMOJ8WR14=;
        b=oGK5SuS9Z0Y+BfUFDvymxXxIT3dVrJiqJDl0SmjAH1WKrp0KfYJo9c7Jt6GRqHqhjf
         xL904CHM7rOqKWiBId0gqi1ANEqsh8Vi1POT3rFsSxnP1sv8TWXuzYEQwWdM+WQae4bc
         cD5kt5fLdYvlS/470CR6WDqZRwyy+d7u93IijQiqaWbE2oAlcZ49Xx9B4i8gsBQI3S9C
         Y70Njy+cxcQ4Ju51ncSG66erLPDkBjUeNC67DnvACjM1YzXkaLIEWt0+OOeENYsHaWFp
         3jow0uKVP3ITt6xoBol+eZDbtEMCY8WW3lDyoqWyV8QNu3/rvCtg12twNiYdPKM2WPQG
         nfpQ==
X-Gm-Message-State: AOJu0Yxk9vXLJPBIK0Pbw2q7vGgLKdL5EaL72n6KZ783ecb0p97KBQNl
	a7ngQKwBqGy8E5w8U/nrJemYEdlqqOvzDHa3NscD65mf8P/KfaRvBCQ/m6FogEs=
X-Google-Smtp-Source: AGHT+IFJ0amuASLJGNlO7AL2H4DHgvlDTj4VN1K1r6S/vWZLgt4yiPQOPyG67uc3++z1Yw2ejr/K/w==
X-Received: by 2002:a05:600c:1911:b0:414:1363:53a4 with SMTP id j17-20020a05600c191100b00414136353a4mr7270968wmq.15.1711456133153;
        Tue, 26 Mar 2024 05:28:53 -0700 (PDT)
Date: Tue, 26 Mar 2024 12:28:51 +0000
From: Anthony PERARD 
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= 
Cc: xen-devel@lists.xenproject.org
Subject: Re: [OSSTEST PATCH 10/36] preseed_create: Workaround fail
 grub-install on arndale
Message-ID: 
References: <20240318165545.3898-1-anthony.perard@citrix.com>
 <20240318165545.3898-11-anthony.perard@citrix.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Wed, Mar 20, 2024 at 05:38:17PM +0100, Roger Pau Monn wrote:
> On Mon, Mar 18, 2024 at 04:55:19PM +0000, Anthony PERARD wrote:
> > grub-installer on arndale-* machine fails with Debian Bookworm. It
> > tries to install "grub-pc" which doesn't exist. Skip installation.
> > 
> > Somehow, cubietruck-* installation works fine.
> 
> I'm kind of puzzled by this, as cubietruck and arndales are both armhf
> IIRC? (IOW: they should use the same repo?)
> 
> Does the install of grub-pc succeed on the cubietruck, or is skipped
> for some other reason that doesn't require us to intervene?

It's skipped.

The difference I can see is that, on the cubietruck, there's an extra
step. And it's due to this extra logging:
    debconf: --> METAGET debian-installer/flash-kernel-installer/title Description
    debconf: <-- 0 Make the system bootable

On the cubietruck, there would be these installation step:
    ..., Select and install software, Make the system bootable, Install the GRUB boot loader, ...
But on the arndale, it would be instead:
    ..., Select and install software, Install the GRUB boot loader, ...

Somehow, flash-kernel-installer does something different on both
machine.

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Tue Mar 26 12:30:50 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Mar 2024 12:30:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698065.1089373 (Exim 4.92)
	(envelope-from )
	id 1rp5x2-0003IY-DL; Tue, 26 Mar 2024 12:30:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698065.1089373; Tue, 26 Mar 2024 12:30:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rp5x2-0003IR-9h; Tue, 26 Mar 2024 12:30:48 +0000
Received: by outflank-mailman (input) for mailman id 698065;
 Tue, 26 Mar 2024 12:30:47 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rp5x1-0003IF-5p
 for xen-devel@lists.xenproject.org; Tue, 26 Mar 2024 12:30:47 +0000
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com
 [2a00:1450:4864:20::431])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id aabba542-eb6c-11ee-a1ef-f123f15fe8a2;
 Tue, 26 Mar 2024 13:30:45 +0100 (CET)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-34175878e3cso3834613f8f.0
 for ; Tue, 26 Mar 2024 05:30:45 -0700 (PDT)
Received: from perard.uk.xensource.com (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 n7-20020a056000170700b00341cfa5f16fsm4489995wrc.30.2024.03.26.05.30.44
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 26 Mar 2024 05:30:44 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: aabba542-eb6c-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1711456244; x=1712061044; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=9TsJzQDax/ckC8yYv+YLh+kCHWUXJ4dhYhH8AtZwWT0=;
        b=IpZJJhHBLnqJRukcNnfCtuPWNzYjpy+xfKxTduNIUPVZS1JBWTwqMLm66yOwQ3AVl0
         +cWDjxWaJZuzcR+3wthD6nfnR9s2myV+zUCHbSJ39zLj5LKK7goADQCGucRo3/RGPQTp
         x3GMK68Kg3o51536UGSSy9w90O5/lhrwT85BY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711456244; x=1712061044;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=9TsJzQDax/ckC8yYv+YLh+kCHWUXJ4dhYhH8AtZwWT0=;
        b=QQlhXjn6w643FfQ2WAvDZxEWoL0snlri9kDxOYOjA6/wEG2wk3BffVAS2EiTpjPIWW
         fQa3b2r4VNVf+NwbLDuX1ewIcU8ge5tP9P70IiXT0JV9+fgy3X4TygyXrcpVggriaSJx
         gDqr1GAlrEf71+imDDKWXBNb8UO7BvI5FNQE4IaG/tqp9akUzarYb/gMfQuWmXrESNgP
         wTqAZ8ldfttguJoSSv2+z3bgxkiOnWfZgRkMU3X3v/zP1V1POQGfJaW/Q88wTKo8xowb
         k9hDU6jCYPuDJivU9NdQxX4qTnrkIqq8yhS4qLzTV7B1o9E0XolVaSFo1cgMRvhWL+0Z
         jH/w==
X-Gm-Message-State: AOJu0YzsN9klgOvjQtyakx5mQCOiMblIJ3ownE2ha8E9Od4siaLs/HLr
	enSPedJvO2x3BgBxQ4m/VW9upP1ojSRX5iUbl/0pXlIx3fBZ5MYYnxeHJYKew5Y=
X-Google-Smtp-Source: AGHT+IFNUVrXNvsA0hzt0eFJCExyVxn5qiu02GM/wJCWe7e4DR8AUoC1Iv/dy3AgCd0MQVYX44f7IQ==
X-Received: by 2002:a5d:628f:0:b0:33e:4d34:f40f with SMTP id k15-20020a5d628f000000b0033e4d34f40fmr7588499wru.46.1711456244599;
        Tue, 26 Mar 2024 05:30:44 -0700 (PDT)
Date: Tue, 26 Mar 2024 12:30:43 +0000
From: Anthony PERARD 
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= 
Cc: xen-devel@lists.xenproject.org
Subject: Re: [OSSTEST PATCH 34/36] Temporally switch "qemu-mainline" branch
 to Bookworm
Message-ID: <0412f0af-071f-4e7a-80b8-69d9401f6723@perard>
References: <20240318165545.3898-1-anthony.perard@citrix.com>
 <20240318165545.3898-35-anthony.perard@citrix.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Wed, Mar 20, 2024 at 06:25:35PM +0100, Roger Pau Monn wrote:
> On Mon, Mar 18, 2024 at 04:55:43PM +0000, Anthony PERARD wrote:
> > QEMU doesn't build on buster anymore.
> > 
> > This should be remove once bookworm is the default suite.
> 
> Is this change required anymore, patch 35 makes bookworm the default,
> hence it seems pointless to switch QEMU just one patch ahead.

You didn't read the cover letter?

But I guess I can skip this patch, it's not that important.

Cheers,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Tue Mar 26 12:36:17 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Mar 2024 12:36:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698069.1089383 (Exim 4.92)
	(envelope-from )
	id 1rp62F-0003uf-Vk; Tue, 26 Mar 2024 12:36:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698069.1089383; Tue, 26 Mar 2024 12:36:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rp62F-0003uY-Sg; Tue, 26 Mar 2024 12:36:11 +0000
Received: by outflank-mailman (input) for mailman id 698069;
 Tue, 26 Mar 2024 12:36:10 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rp62E-0003uS-7S
 for xen-devel@lists.xenproject.org; Tue, 26 Mar 2024 12:36:10 +0000
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com
 [2a00:1450:4864:20::42e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6c011c50-eb6d-11ee-afe3-a90da7624cb6;
 Tue, 26 Mar 2024 13:36:09 +0100 (CET)
Received: by mail-wr1-x42e.google.com with SMTP id
 ffacd0b85a97d-33ed4dd8659so4016843f8f.0
 for ; Tue, 26 Mar 2024 05:36:09 -0700 (PDT)
Received: from perard.uk.xensource.com (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 h8-20020adffd48000000b0033e9d9f891csm12050734wrs.58.2024.03.26.05.36.08
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 26 Mar 2024 05:36:08 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6c011c50-eb6d-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1711456569; x=1712061369; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=Y+hwKwu0ruHBXxrEFzZRjvvf/lXSF9n+LBaptyNnfWM=;
        b=bkYEY7f41qnbcS94V16wCAhzkeoFY/gK4EqiiddmqiZOitJ94L4qlnLNbuW7+imqn5
         iIy+liO5CVZSvqutvTJ/hxQPm05i2LK+9dOala5sv/+ecuTuldJ9wBwgKLQ0euTCDNHM
         dNVizolWakMJW8j22Vl0aPTQgJco4k1Tx2Xig=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711456569; x=1712061369;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=Y+hwKwu0ruHBXxrEFzZRjvvf/lXSF9n+LBaptyNnfWM=;
        b=fk9crRTFv1HPe+K0kes2m+dDS0XKNRqc53yK/gCxWCA6SVQj9L19q9aezc8P01ydM7
         DljMhYYjW1DjqHbYP4UdD7DKtAzsK0xw871wlvU40YSb7k2bxW4EBSLy5qfMYton3onS
         /u/U/buus8GvAAq4qK2+HdL5VSpxdfFhpIPT7+2u1FBTUT+y2FUYtvSoE6mZTAuTN62C
         dkXtQIviecwG7MQkDftD+haep38OoYo+vbY5nwyXgZo5IMLqvcRiFEQlahUG0aThgQKQ
         VozTKbBujAc5pJqeDNizFm/N+eUuZSVzxzuCTHeF/hluxVosXcb2yqpWU7qyBQXZpJM+
         jTyw==
X-Gm-Message-State: AOJu0YwQxsjXRzRkvqBdYGieLVpxSRmUfmzQvMDug3SDtr/UijLl1Btv
	if2bLwveO1tIVsr7CvOd/E25aYOgWT70Xfa1rKoyBm4UksnG8gWXXKjmjyxvvQM=
X-Google-Smtp-Source: AGHT+IGCvPFlnWFHY9SDZ3aI6Yq1801F2+hIdWw+MiAsvaIxj3eWv7UlWMUbQN3jbQ+/D8huizg1FA==
X-Received: by 2002:adf:fa41:0:b0:33d:82d3:42ff with SMTP id y1-20020adffa41000000b0033d82d342ffmr1086032wrr.21.1711456568706;
        Tue, 26 Mar 2024 05:36:08 -0700 (PDT)
Date: Tue, 26 Mar 2024 12:36:07 +0000
From: Anthony PERARD 
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= 
Cc: xen-devel@lists.xenproject.org
Subject: Re: [OSSTEST PATCH 33/36] make-flight: Keep using buster for L2
 guest in nested tests
Message-ID: <5dc0e5ad-497c-4906-84d4-4f248ab01578@perard>
References: <20240318165545.3898-1-anthony.perard@citrix.com>
 <20240318165545.3898-34-anthony.perard@citrix.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Wed, Mar 20, 2024 at 06:24:18PM +0100, Roger Pau Monn wrote:
> On Mon, Mar 18, 2024 at 04:55:42PM +0000, Anthony PERARD wrote:
> > When starting the installation of the L2 guest, L0 kills L1. Switching
> > the L2 guest back to Debian Buster works fine, so do that to prevent
> > regression in the test.
> > 
> > Part of the logs from the host L0:
> > 
> > > domain_crash called from arch/x86/hvm/vmx/vvmx.c:2770
> > > Domain 3 (vcpu#0) crashed on cpu#4:
> > > d3v0 vmentry failure (reason 0x80000021): Invalid guest state (2)
> 
> Hm, I guess we need this as otherwise the changes themselves won't
> past the self-push gate, but this is just masking a real issue.  I
> would be tempted to (after the switch to bookworm has gone in) revert
> this and force-push it into osstest, so that the failure is visible.

That means that we might have to force-push on every branches. Or fix
Xen.

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Tue Mar 26 13:15:44 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Mar 2024 13:15:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698077.1089393 (Exim 4.92)
	(envelope-from )
	id 1rp6eP-0001nH-UL; Tue, 26 Mar 2024 13:15:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698077.1089393; Tue, 26 Mar 2024 13:15:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rp6eP-0001nA-RG; Tue, 26 Mar 2024 13:15:37 +0000
Received: by outflank-mailman (input) for mailman id 698077;
 Tue, 26 Mar 2024 13:15:36 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rp6eO-0001n4-FI
 for xen-devel@lists.xenproject.org; Tue, 26 Mar 2024 13:15:36 +0000
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com
 [2a00:1450:4864:20::634])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ed526455-eb72-11ee-a1ef-f123f15fe8a2;
 Tue, 26 Mar 2024 14:15:33 +0100 (CET)
Received: by mail-ej1-x634.google.com with SMTP id
 a640c23a62f3a-a46ba938de0so739281666b.3
 for ; Tue, 26 Mar 2024 06:15:33 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a27-20020a170906191b00b00a46bd891b5bsm4221340eje.225.2024.03.26.06.15.32
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 26 Mar 2024 06:15:32 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ed526455-eb72-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711458933; x=1712063733; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=2VDQ7ue7i5LpVN9CFjhO5zilWhINPYQ7Zsi1e5bbjbo=;
        b=d9qVkhqEdylHjrlFaYTaMdJ+9ZkgX5KwSK83I9b0cci8SrxPS69bAFOEiMP2boE6Js
         GuYNPnuGK0TAhP9UfUEaaCdGzd56bMB9IYRsDX7RQMXzgyRpriaQ5lZdv4eaovoq39hp
         R6B1wIWRalm172yAZIC4u10UphKRuclF2K4SMHawkvZjLniEBMfIMuHuRFckWXq/FM4t
         9k+Ly/3EBbARKPTZ6UBA0xBvyU+qo1z2dYnT+Se20RFpv4LbU3O1Hro5V67L0QZlwlqx
         0keXGmAGWrAcHMu6JlBTJyUVLg4oNctr4bQCfEfPEAVnxKq57UATwbvzTouUnmVTkxaz
         v/vw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711458933; x=1712063733;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=2VDQ7ue7i5LpVN9CFjhO5zilWhINPYQ7Zsi1e5bbjbo=;
        b=h9voY4DaAg8T///2bM9YR8nB8KjE55aK6nXaOWlAng78TYiz7uTILsIF3ekoQFGeoG
         r2YT/NHKK53M1BDABtMp+s0A5ascSu1UJzfM3V6sLERHjKabF2BiybWMyd7FramhjEra
         WGvjlCJnn6siQHnRm9QSg3gLcGU7vK/c4CwsUfVRigRtYVzbXSN61JsKeSigYKxqymNF
         6QOfwV0/ZN8CMqyqvnNlshUl4BH8en93ePaO/yWQ7pBPgPon0hRRZjyJuiYPw+VhTCMM
         xVSeHBhANSBZ0XClhSalEiCsUIBGUxjVC8dS3ZJLK3k/T5wloOI8Y1qkjl/CEl/LA1RS
         vrOQ==
X-Forwarded-Encrypted: i=1; AJvYcCWieY9jt9fuMYWKC1tlFueeO6g9SaQuIjObtbRhZm4pMcOF+kcD74fSnYlO9hKV2qqKQxXFpGn1L6EuImZyoDpyp570f9iEGJooSXrMkmA=
X-Gm-Message-State: AOJu0YxPHZxGCF0u5oQ4ytgTr/rGaQZvHQ2Vfp7Qz8g5KMYC0f+enHg4
	qNJplXUTqQTik95IAeHOtWVNHkQuRu2RZWYthsUb8SS8NgwHEfxIMa1oxoQ1dw==
X-Google-Smtp-Source: AGHT+IHRK/jG/ZDVJ3AkFWkq1Sg7y1PT3UU2fxtVpo2cMsbGXSm1/Ft7Qu8L5nRq0KB1/kuBKqk/hQ==
X-Received: by 2002:a17:906:15c2:b0:a47:35c6:910c with SMTP id l2-20020a17090615c200b00a4735c6910cmr1896643ejd.22.1711458933033;
        Tue, 26 Mar 2024 06:15:33 -0700 (PDT)
Message-ID: 
Date: Tue, 26 Mar 2024 14:15:31 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/spec-ctrl: Support for SRSO_US_NO and SRSO_MSR_FIX
Content-Language: en-US
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Xen-devel 
References: <20240325181830.638680-1-andrew.cooper3@citrix.com>
 
 <78be9d6c-2b3d-43ad-92fe-23d58767e2d6@citrix.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <78be9d6c-2b3d-43ad-92fe-23d58767e2d6@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 26.03.2024 12:33, Andrew Cooper wrote:
> On 26/03/2024 9:13 am, Jan Beulich wrote:
>> On 25.03.2024 19:18, Andrew Cooper wrote:
>>> +	/* Avoid reading BP_CFG if we don't intend to change anything. */
>>> +	if (!new)
>>>  		return;
>>>  
>>>  	rdmsrl(MSR_AMD64_BP_CFG, val);
>>>  
>>> -	if (val & chickenbit)
>>> +	if ((val & new) == new)
>>>  		return;
>> Since bits may also need turning off:
>>
>> 	if (!((val ^ new) & (BP_CFG_SPEC_REDUCE | (1 << 5))))
>> 		return;
>>
>> and the !new early-out dropped, too? Looks like this wasn't quite right
>> before, either. 
> 
> That's adding unnecessary complexity.  It's unlikely that we'll ever
> need to clear bits like this.

Okay. Half a sentence in a comment would be nice, to make clear the
behavior is intended to only ever set bits.

>>> @@ -1078,22 +1082,41 @@ static void __init ibpb_calculations(void)
>>>           * Confusion.  Mitigate with IBPB-on-entry.
>>>           */
>>>          if ( !boot_cpu_has(X86_FEATURE_BTC_NO) )
>>> -            def_ibpb_entry = true;
>>> +            def_ibpb_entry_pv = def_ibpb_entry_hvm = true;
>>>  
>>>          /*
>>> -         * Further to BTC, Zen3/4 CPUs suffer from Speculative Return Stack
>>> -         * Overflow in most configurations.  Mitigate with IBPB-on-entry if we
>>> -         * have the microcode that makes this an effective option.
>>> +         * Further to BTC, Zen3 and later CPUs suffer from Speculative Return
>>> +         * Stack Overflow in most configurations.  Mitigate with IBPB-on-entry
>>> +         * if we have the microcode that makes this an effective option,
>>> +         * except where there are other mitigating factors available.
>>>           */
>> Hmm, is "Zen3 and later" really appropriate?
> 
> Yes.
> 
> SRSO isn't fixed until SRSO_NO is enumerated.

IOW even on Zen5 that's going to be only by ucode update?

>>> --- a/xen/include/public/arch-x86/cpufeatureset.h
>>> +++ b/xen/include/public/arch-x86/cpufeatureset.h
>>> @@ -304,7 +304,9 @@ XEN_CPUFEATURE(FSRSC,              11*32+19) /*A  Fast Short REP SCASB */
>>>  XEN_CPUFEATURE(AMD_PREFETCHI,      11*32+20) /*A  PREFETCHIT{0,1} Instructions */
>>>  XEN_CPUFEATURE(SBPB,               11*32+27) /*A  Selective Branch Predictor Barrier */
>>>  XEN_CPUFEATURE(IBPB_BRTYPE,        11*32+28) /*A  IBPB flushes Branch Type predictions too */
>>> -XEN_CPUFEATURE(SRSO_NO,            11*32+29) /*A  Hardware not vulenrable to Speculative Return Stack Overflow */
>>> +XEN_CPUFEATURE(SRSO_NO,            11*32+29) /*A  Hardware not vulnerable to Speculative Return Stack Overflow */
>>> +XEN_CPUFEATURE(SRSO_US_NO,         11*32+30) /*A  Hardware not vulnerable to SRSO across the User/Supervisor boundary */
>> Can we validly expose this to 64-bit PV guests, where there's no CPL
>> boundary? Or else isn't my "x86/PV: issue branch prediction barrier
>> when switching 64-bit guest to kernel mode" needed as a prereq?
> 
> Based on uarch details, if BP-SPEC-REDUCE is active, we can advertise
> SRSO_US_NO to PV guests.

Which would make it at best !A, for the PV exposure then depending on
the HVM side choice.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Mar 26 13:24:44 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Mar 2024 13:24:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698082.1089403 (Exim 4.92)
	(envelope-from )
	id 1rp6n8-0003k3-O7; Tue, 26 Mar 2024 13:24:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698082.1089403; Tue, 26 Mar 2024 13:24:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rp6n8-0003jw-Ky; Tue, 26 Mar 2024 13:24:38 +0000
Received: by outflank-mailman (input) for mailman id 698082;
 Tue, 26 Mar 2024 13:24:37 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rp6n7-0003jq-At
 for xen-devel@lists.xenproject.org; Tue, 26 Mar 2024 13:24:37 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on20601.outbound.protection.outlook.com
 [2a01:111:f403:200a::601])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2f0659f1-eb74-11ee-a1ef-f123f15fe8a2;
 Tue, 26 Mar 2024 14:24:34 +0100 (CET)
Received: from BYAPR07CA0063.namprd07.prod.outlook.com (2603:10b6:a03:60::40)
 by PH8PR12MB7230.namprd12.prod.outlook.com (2603:10b6:510:226::17)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.33; Tue, 26 Mar
 2024 13:24:27 +0000
Received: from SJ5PEPF000001CA.namprd05.prod.outlook.com
 (2603:10b6:a03:60:cafe::e7) by BYAPR07CA0063.outlook.office365.com
 (2603:10b6:a03:60::40) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.13 via Frontend
 Transport; Tue, 26 Mar 2024 13:24:27 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 SJ5PEPF000001CA.mail.protection.outlook.com (10.167.242.39) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Tue, 26 Mar 2024 13:24:27 +0000
Received: from SATLEXMB06.amd.com (10.181.40.147) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Tue, 26 Mar
 2024 08:24:26 -0500
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB06.amd.com
 (10.181.40.147) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Tue, 26 Mar
 2024 08:24:26 -0500
Received: from [172.17.142.167] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Tue, 26 Mar 2024 08:24:25 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2f0659f1-eb74-11ee-a1ef-f123f15fe8a2
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=aUzaPKlqyIW3zmJq3I9Ro+Mz2UNaVJ0ryCx4lvofnzOQ9EqkNINVphtvY+Awl3wjDW5UC6xbuATwgnMIXUclTMsULhp2bAHFjh65tqqJkQv3L2zTN/Tb6cD6ZCnJdcbu6+WWXVQ0FkLxZozIRlY2dEP5mhjN5o7+T0lVZfLi76Cdu+78+URz0mnRPzZW7Cdq299Mm1HD+QRU+yxjWd7LvgralUJrr930RxgaoIhM9oJS7tq4Fg7LFZEEnS/OMBBOGTMhVVK0u8q9qYWeAsyKuMJiMxU86pzVeMGUq2mkEQz8LV5ubG9ckD0e0Lmk/0OXRC9Nd8lLmtbYmG5CSvcufA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=+eQAh4f6pENxbQZE4wX30pkVcRTyLg8j1iMzyV8xNWY=;
 b=mjSRtJsS7sku22R/jon4DkEtBAWHH9sLVPj5hfVz4kGnp6PfDeHW9IOjEUvdVNbJSed4BHs+tCBRSs+191AI2XZV0dbzCE01g2dQTRkyjswBCojgwvMGI3QBhtPraOwSN2JN+hkA/vu8ym7ypFCnycXCOG7QkAc7fdbjb8+ULD/Triln0Poeblg95uwgFcmv2lMPqyvur8BWiHm8RYMdh52L3PeSXeN2Dkm77CjJkGfgGATmi/MheUILmN8YD9Ha0RRU5G8qsyh8Jv4cxp5ma3dFduG9UlPU+KvBnJb0uLiHc7R7sUTLiMpNC20HMir++lulXqFJ2aeBlUOzsrwUNg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=+eQAh4f6pENxbQZE4wX30pkVcRTyLg8j1iMzyV8xNWY=;
 b=oszOfmsdLvDuTiJ9U9bIPlKxOLTclKLKKoEP8hw0aNJEiLM/3yySXF2DEDxjjRPfCTa/DTvklwyvEFLF+ukqtjx5kkouB+uwZT1UTJqALFyhLCec686PYiBxNXtS/uJCuBCQwdZd4bVFDVuyOUjOFbC2hR0zyU0P7Dxu+ryaw18=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
Message-ID: 
Date: Tue, 26 Mar 2024 09:24:24 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 5/5] x86/PVH: Support relocatable dom0 kernels
To: Jan Beulich 
CC: Andrew Cooper ,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , George Dunlap
	, Julien Grall , Stefano Stabellini
	, 
References: <20240325204515.250203-1-jason.andryuk@amd.com>
 <20240325204515.250203-6-jason.andryuk@amd.com>
 <770d3292-34cf-4e21-acb6-bd1f9caf5fef@suse.com>
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: <770d3292-34cf-4e21-acb6-bd1f9caf5fef@suse.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ5PEPF000001CA:EE_|PH8PR12MB7230:EE_
X-MS-Office365-Filtering-Correlation-Id: 8b44ed2e-72c5-4d94-8ebe-08dc4d980fb2
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	LScVw/Vc/kBbKBH0gU0RrygnEL/ek8uFo9F6hwMPGsQjc07mf4ksCN4h8Kghky6NmiqsLbulMzXQUhG/2VjmFeyjB6zrD8TcWaoOQGnfsw1rSjN2fM3C7Sqe7jWiitoBqKW0nn2eWiAn2JyfgKdYL9ecG3Aj9MsaigRFvGre86uysmtddMAcFUlzGR91O/SvdAqoAtnVPs3DeguM9alhptxcRvMeYwvf+kywxX5GBiMOdmC3tl9ap5sBSJa998kiWG9NTJ76WlCZZkCtxOONKKDlXHObWjJiDAM4aKtJvB5UyL/Xo3N0XJ3xDxCEmAhyFGAB3v0rKV3ADE08qEqFGZIwWC9aUnHKJiclWURCEKqR5gs+9wecf8CSlgiwoy6mlq2+TymTkmFsYQ1V5BFUSAj0GmgZDwJPtY8MRmfuWk1iZzFNcaA6jZYHevm5Dy4vxRP8oG6yN6u5yhdmC88PmfEMM1t4qR8+EgNyKPAsI6RG5wJKJS5/t1YSRnM/VskBQEbVNKPn4TfbtwEChBkzes5Uwj/U+IIwBY5QbfwEe4AnzgNLV6/4RekZwevRGGajEOPMnGa/v8P9Ca3qevdVNIyUoI4xh3p39Eb18AkqkLrUozpRaMKjPZ3dZhgwSSYVqiAfb/rXjZSTRJtKNp6madwgPuKtrfsXweaAzpl4wv/p2zrFVfy6KyR4wEkHu71nZznKR7hfn+gsGJB34Aj/BTzTSTcvq/mZVhpeug1gBfJa0ZOQlSxTvkG6mbpqWOZx
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(376005)(82310400014)(36860700004)(1800799015);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Mar 2024 13:24:27.2245
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 8b44ed2e-72c5-4d94-8ebe-08dc4d980fb2
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ5PEPF000001CA.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR12MB7230

On 2024-03-26 03:50, Jan Beulich wrote:
> On 25.03.2024 21:45, Jason Andryuk wrote:
>> +/* Find an e820 RAM region that fits the kernel at a suitable alignment. */
>> +static paddr_t __init find_kernel_memory(
>> +    const struct domain *d, struct elf_binary *elf,
>> +    const struct elf_dom_parms *parms)
>> +{
>> +    paddr_t kernel_size = elf->dest_size;
>> +    unsigned int i;
>> +
>> +    for ( i = 0; i < d->arch.nr_e820; i++ )
>> +    {
>> +        paddr_t start = d->arch.e820[i].addr;
>> +        paddr_t end = start + d->arch.e820[i].size;
>> +        paddr_t kstart, kend;
>> +
>> +        if ( d->arch.e820[i].type != E820_RAM ||
>> +             d->arch.e820[i].size < kernel_size )
>> +            continue;
>> +
>> +        kstart = ROUNDUP(start, parms->phys_align);
>> +        kstart = max_t(paddr_t, kstart, parms->phys_min);
>> +        kend = kstart + kernel_size;
>> +
>> +        if ( kend - 1 > parms->phys_max )
>> +            return 0;
>> +
>> +        if ( kend <= end )
>> +            return kstart;
> 
> IOW within a suitable region the lowest suitable part is selected. Often
> low memory is deemed more precious than higher one, so if this choice is
> indeed intentional, I'd like to ask for a brief comment towards the
> reasons.

It is not particularly intentional.  I'll look into locating at a higher 
address.

>> --- a/xen/common/libelf/libelf-dominfo.c
>> +++ b/xen/common/libelf/libelf-dominfo.c
>> @@ -17,6 +17,16 @@
>>   
>>   #include "libelf-private.h"
>>   
>> +#if defined(__i386__) || defined(__x86_64__)
>> +#define ARCH_PHYS_MIN_DEFAULT   0;
>> +#define ARCH_PHYS_MAX_DEFAULT   (GB(4) - 1);
>> +#define ARCH_PHYS_ALIGN_DEFAULT MB(2);
>> +#else
>> +#define ARCH_PHYS_MIN_DEFAULT   0;
>> +#define ARCH_PHYS_MAX_DEFAULT   0;
>> +#define ARCH_PHYS_ALIGN_DEFAULT 0;
>> +#endif
> 
> None of the semicolons should really be here.

Yes, sorry.  I inadvertently retained them when reworking this.

>> @@ -227,6 +239,27 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
>>       case XEN_ELFNOTE_PHYS32_ENTRY:
>>           parms->phys_entry = val;
>>           break;
>> +
>> +    case XEN_ELFNOTE_PHYS32_RELOC:
>> +        parms->phys_reloc = true;
>> +
>> +        if ( descsz >= 4 )
>> +        {
>> +            parms->phys_max = elf_note_numeric_array(elf, note, 4, 0);
>> +            elf_msg(elf, " = max: %#"PRIx32, parms->phys_max);
> 
> As indicated before, I consider the = here a little odd.

I retained = for consistency with other notes:
ELF: note: PHYS32_RELOC = max: 0x40000000 min: 0x1000000 align: 0x200000
ELF: note: PHYS32_ENTRY = 0x1000000
ELF: note: GUEST_OS = "linux"

I guess whitespace and labels makes it clear, so I'll drop the '='.

>> +        }
>> +        if ( descsz >= 8 )
>> +        {
>> +            parms->phys_min = elf_note_numeric_array(elf, note, 4, 1);
>> +            elf_msg(elf, " min: %#"PRIx32, parms->phys_min);
>> +        }
>> +        if ( descsz >= 12 )
>> +        {
>> +            parms->phys_align = elf_note_numeric_array(elf, note, 4, 2);
>> +            elf_msg(elf, " align: %#"PRIx32, parms->phys_align);
>> +        }
> 
> I'd like us to reconsider this ordering: I'm inclined to say that MAX isn't
> the most likely one a guest may find a need to use. Instead I'd expect both
> MIN and ALIGN wanting to be given higher priority; what I'm less certain
> about is the ordering between the two. To keep MIN and MAX adjacent, how
> about ALIGN, MIN, MAX?

ALIGN, MIN, MAX works for me.

On the Linux side, I'm expecting them all to be set:
ALIGN = CONFIG_PHYSICAL_ALIGN
MIN = LOAD_PHYSICAL_ADDR
MAX = KERNEL_IMAGE_SIZE

You need enough identity page tables to cover up to MAX. 
LOAD_PHYSICAL_ADDR is used as a minimum, so requesting placement above 
MIN makes sense to me.

>> --- a/xen/include/public/elfnote.h
>> +++ b/xen/include/public/elfnote.h
>> @@ -194,10 +194,27 @@
>>    */
>>   #define XEN_ELFNOTE_PHYS32_ENTRY 18
>>   
>> +/*
>> + * Physical loading constraints for PVH kernels
>> + *
>> + * The presence of this note indicates the kernel supports relocating itself.
>> + *
>> + * The note may include up to three 32bit values to place constraints on the
>> + * guest physical loading addresses and alignment for a PVH kernel.  Values
>> + * are read in the following order:
>> + *  - a maximum address for the entire image to be loaded below (default
>> + *      0xffffffff)
> 
> "below" isn't exactly true anymore with this now being an inclusive value.
> Perhaps "up to", or perhaps more of a re-wording.

Yes, good point.

> I also think the wrapped line's indentation is too deep (by 2 blanks).

Yes, thanks.

>> + *  - a minimum address for the start of the image (default 0)
>> + *  - a required start alignment (default 0x200000)
>> + *
>> + *  This note is only valid for x86 binaries.
> 
> Maybe s/valid/recognized/ (or honored or some such)?

Would a comment at the top of the file saying Notes are only used with 
x86 be better instead of this one-off comment?  Roger already said that, 
and elf_xen_note_check() has a successful early exit with "ELF: Not 
bothering with notes on ARM\n"

Thanks,
Jason


From xen-devel-bounces@lists.xenproject.org Tue Mar 26 13:30:22 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Mar 2024 13:30:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698088.1089413 (Exim 4.92)
	(envelope-from )
	id 1rp6sT-0005OZ-FC; Tue, 26 Mar 2024 13:30:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698088.1089413; Tue, 26 Mar 2024 13:30:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rp6sT-0005OS-C0; Tue, 26 Mar 2024 13:30:09 +0000
Received: by outflank-mailman (input) for mailman id 698088;
 Tue, 26 Mar 2024 13:30:08 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rp6sS-0005Mm-6t
 for xen-devel@lists.xenproject.org; Tue, 26 Mar 2024 13:30:08 +0000
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com
 [2a00:1450:4864:20::535])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f54e563b-eb74-11ee-a1ef-f123f15fe8a2;
 Tue, 26 Mar 2024 14:30:06 +0100 (CET)
Received: by mail-ed1-x535.google.com with SMTP id
 4fb4d7f45d1cf-56b8e4f38a2so7105285a12.3
 for ; Tue, 26 Mar 2024 06:30:06 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 k18-20020a1709060cb200b00a455d78be5bsm4222735ejh.9.2024.03.26.06.30.04
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 26 Mar 2024 06:30:05 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f54e563b-eb74-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711459805; x=1712064605; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=fwgQQBmfLrCnvgHbA6SDQOn+05jz7V40LGNuVpzMnMI=;
        b=cRILbYiAMVGWkxoijHiRSV2kI/vjeklghBlFzzLxRKxID1j6YttSVKJylNZuIBnDPg
         mvVMx8JQl9XIpyny4Wue0B8nATBzHiXZNhNQ51tCZqrzYB0xj5Mw9EuQusjbTO8G41DS
         z57IcPvRzAW5N6s9DbipanOnWPnliLfre77uZGl4WZjYU2VaSOzNPM8IW8FpG6Rn7WlM
         7ESTsnha5oSfVvcVKZ/w5UdOfiyskswwS12nLfKrs8BZQmuwiLkHGX+bw4Nm/IHA4xUe
         UZhOMkTmKawOIjyimQS8uMNaHPGOtY+u5cd1ud6o05RZ23VLdikedh1TGUje07HqO2hs
         qg8g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711459805; x=1712064605;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=fwgQQBmfLrCnvgHbA6SDQOn+05jz7V40LGNuVpzMnMI=;
        b=dqvLR4YG0iW4SLzJ6v7mv/WIL9v2xTj1f+DffYjOMAfshAjD8G0sN5aHspdOfFv51y
         5w6mhDiO2UgnWG7kRH6pgSS2NSME4TQfPMKuwj0lK5rVc/XIFRxCs258Abq4+6kH83DY
         qisA43DMVzJ5BPdxn+AXHPugngNa5i7KNaP0JOQ38Ow2HHjfZuxr+/ThSWzGTkH70Paf
         a3azYfsAR7UnnSRsqdQYQ3nByfyQeh41baOF9hvZf/uE5hgP2L4lIGdBCBlpDlLEmvyZ
         DpRnZF4FQxYP9iADtTET1ZYy/6F7CPs6EaKOCVPXXxOgObLYvSzpq84nmV5SQ3nYlirz
         Tz3w==
X-Forwarded-Encrypted: i=1; AJvYcCWnNmGHkI2/YLdiAi3scTduO2IEUmGWVRYVTQtwtGgiLOR05vLGdYTRan9QatzqTMB2qPOSDLzUcqo/0WAUosbQ6WbxRE2CoNmTsnnB8qM=
X-Gm-Message-State: AOJu0Yw92xMHfY10M4ek2DOqoxU1WIqslurCFJ7dQg2PC7opQMv1GLjq
	aH3PXXbzIiUG5R4cdt4A+jbkr8HwIF32o20tF7RC/jsrJT1A2qn+y2dDiqGUOg==
X-Google-Smtp-Source: AGHT+IEenydUmc1YwkZ8vVOJ+pdqij8XdTV8qTJI0OUe+kQXldFjEeeUQ2hftFj6B/DTp5KgKLdQ/g==
X-Received: by 2002:a17:906:e296:b0:a47:355f:6dd1 with SMTP id gg22-20020a170906e29600b00a47355f6dd1mr915615ejb.6.1711459805618;
        Tue, 26 Mar 2024 06:30:05 -0700 (PDT)
Message-ID: <5b9d07ad-159d-4384-924e-e772e6ec4ede@suse.com>
Date: Tue, 26 Mar 2024 14:30:03 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 5/5] x86/PVH: Support relocatable dom0 kernels
Content-Language: en-US
To: Jason Andryuk 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20240325204515.250203-1-jason.andryuk@amd.com>
 <20240325204515.250203-6-jason.andryuk@amd.com>
 <770d3292-34cf-4e21-acb6-bd1f9caf5fef@suse.com>
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 26.03.2024 14:24, Jason Andryuk wrote:
> On 2024-03-26 03:50, Jan Beulich wrote:
>> On 25.03.2024 21:45, Jason Andryuk wrote:
>>> + *  - a minimum address for the start of the image (default 0)
>>> + *  - a required start alignment (default 0x200000)
>>> + *
>>> + *  This note is only valid for x86 binaries.
>>
>> Maybe s/valid/recognized/ (or honored or some such)?
> 
> Would a comment at the top of the file saying Notes are only used with 
> x86 be better instead of this one-off comment?  Roger already said that, 
> and elf_xen_note_check() has a successful early exit with "ELF: Not 
> bothering with notes on ARM\n"

If truly none of the notes are of interest for Arm, then yes, such a more
general comment would likely make sense.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Mar 26 13:40:21 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Mar 2024 13:40:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698091.1089422 (Exim 4.92)
	(envelope-from )
	id 1rp72D-0007bH-AU; Tue, 26 Mar 2024 13:40:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698091.1089422; Tue, 26 Mar 2024 13:40:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rp72D-0007bA-7l; Tue, 26 Mar 2024 13:40:13 +0000
Received: by outflank-mailman (input) for mailman id 698091;
 Tue, 26 Mar 2024 13:40:11 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rp72B-0007b2-Tn
 for xen-devel@lists.xenproject.org; Tue, 26 Mar 2024 13:40:11 +0000
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com
 [2a00:1450:4864:20::62c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5c774a6c-eb76-11ee-a1ef-f123f15fe8a2;
 Tue, 26 Mar 2024 14:40:08 +0100 (CET)
Received: by mail-ej1-x62c.google.com with SMTP id
 a640c23a62f3a-a4a387ff7acso253526266b.2
 for ; Tue, 26 Mar 2024 06:40:08 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 k18-20020a1709060cb200b00a455d78be5bsm4231683ejh.9.2024.03.26.06.40.07
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 26 Mar 2024 06:40:07 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5c774a6c-eb76-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711460408; x=1712065208; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=Tg4pmVtm0wTT/oaYBTUaW3mAFjbFCuxbtaRqrXwufLs=;
        b=eg7xzmCOZ6yVWbGswmnlu+leCZZyW0NKxSXOT/sV8g1QXQJ1l7DJoVBoYA8joyU+Gb
         r7u6Ao5MfXd+nEmAkJ6n1Vb1surt7yioWa11vwzRw4zNyAuZnExIms4iENs66wrWcQcg
         8ElDE282WA0myYJjgmAwmFErjdSW3wy412QI152kSB2BMcee9Oyd5G87REKpyj/bvzgf
         RqTdjvgmxzr8YLxRd+s00SAGF8zyAUH3YQSxZBYgMs5E5hzYfURdmDDui2l7bDWM6w/v
         fZ9ZYsElZvBVreHAMJqcZqnF8MvNJ8PxgQ855V72YToTCIv5H7k1Yv+9/DYLDqhV71d4
         94tw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711460408; x=1712065208;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=Tg4pmVtm0wTT/oaYBTUaW3mAFjbFCuxbtaRqrXwufLs=;
        b=Ire/ty4EE62BGKx/7KxEHuqXDqb6WYJ+yoJx199Rw87rsmpYfLCQRbB/XgOPkIHniM
         B4BUof0vV79cuQm+O6rKO2WtBti/4oglNPFjUR6IOQill78vNUZ1er7uzwFWq4o1q3lX
         c9Kze6YSQEjwr5SUgC5XOlhPL2zt+dZ4eC1a/lbok8CBsQDzeCvV66tih2l+T97q6IcE
         ShU3+1LSU9Azbpmoun2gM5YJD6TfEuMbz2nQlj9BtKZkbbdBx57tZcjglBFESbAH6XKm
         nCHYMhpQeLkJ5H5z1CE6N0Om7HksRAzNdGRfHv2Odm4lDvZg9AXpCgstj4fB5MX5Sb8f
         opQw==
X-Forwarded-Encrypted: i=1; AJvYcCUrNu5nlJJDcQxovqzOpf+PSzd735O0Lr3FeomLN+/8deRpNsEMNjr/U6VrvGqiV1n1osRLxzNMqNL5DdYI5fXrXtbisuQTqPV2YL/yZMw=
X-Gm-Message-State: AOJu0YwI02DpRv1+X3Yxunew+9tJtZavMze7RF7SaR1MgUyza1TDO3Vi
	MA+hNkvd1Q/1W+pa/QDZU0PqTRUsRh5nrdktW/v14QTCktWu0s1UvsK6zsgGpw==
X-Google-Smtp-Source: AGHT+IGLFmztb+e5weZ9ebVyGjnGCgYS+pjJkXdwKwl9/DFPC0AXMNQybaT+3iv3XGS6ZB6LXj1jcw==
X-Received: by 2002:a17:906:a859:b0:a47:53c9:f5b with SMTP id dx25-20020a170906a85900b00a4753c90f5bmr950726ejb.65.1711460408191;
        Tue, 26 Mar 2024 06:40:08 -0700 (PDT)
Message-ID: 
Date: Tue, 26 Mar 2024 14:40:06 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 5/5] x86/PVH: Support relocatable dom0 kernels
Content-Language: en-US
To: Jason Andryuk 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20240325204515.250203-1-jason.andryuk@amd.com>
 <20240325204515.250203-6-jason.andryuk@amd.com>
 <770d3292-34cf-4e21-acb6-bd1f9caf5fef@suse.com>
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 26.03.2024 14:24, Jason Andryuk wrote:
> On 2024-03-26 03:50, Jan Beulich wrote:
>> On 25.03.2024 21:45, Jason Andryuk wrote:
>>> @@ -227,6 +239,27 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
>>>       case XEN_ELFNOTE_PHYS32_ENTRY:
>>>           parms->phys_entry = val;
>>>           break;
>>> +
>>> +    case XEN_ELFNOTE_PHYS32_RELOC:
>>> +        parms->phys_reloc = true;
>>> +
>>> +        if ( descsz >= 4 )
>>> +        {
>>> +            parms->phys_max = elf_note_numeric_array(elf, note, 4, 0);
>>> +            elf_msg(elf, " = max: %#"PRIx32, parms->phys_max);
>>
>> As indicated before, I consider the = here a little odd.
> 
> I retained = for consistency with other notes:
> ELF: note: PHYS32_RELOC = max: 0x40000000 min: 0x1000000 align: 0x200000
> ELF: note: PHYS32_ENTRY = 0x1000000
> ELF: note: GUEST_OS = "linux"
> 
> I guess whitespace and labels makes it clear, so I'll drop the '='.
> 
>>> +        }
>>> +        if ( descsz >= 8 )
>>> +        {
>>> +            parms->phys_min = elf_note_numeric_array(elf, note, 4, 1);
>>> +            elf_msg(elf, " min: %#"PRIx32, parms->phys_min);
>>> +        }
>>> +        if ( descsz >= 12 )
>>> +        {
>>> +            parms->phys_align = elf_note_numeric_array(elf, note, 4, 2);
>>> +            elf_msg(elf, " align: %#"PRIx32, parms->phys_align);
>>> +        }
>>
>> I'd like us to reconsider this ordering: I'm inclined to say that MAX isn't
>> the most likely one a guest may find a need to use. Instead I'd expect both
>> MIN and ALIGN wanting to be given higher priority; what I'm less certain
>> about is the ordering between the two. To keep MIN and MAX adjacent, how
>> about ALIGN, MIN, MAX?
> 
> ALIGN, MIN, MAX works for me.
> 
> On the Linux side, I'm expecting them all to be set:
> ALIGN = CONFIG_PHYSICAL_ALIGN
> MIN = LOAD_PHYSICAL_ADDR
> MAX = KERNEL_IMAGE_SIZE
> 
> You need enough identity page tables to cover up to MAX. 
> LOAD_PHYSICAL_ADDR is used as a minimum, so requesting placement above 
> MIN makes sense to me.

Hmm, setting MIN like this means moving down is precluded. Why would it
not be possible to move a kernel to lower than the default of 16M, when
CONFIG_PHYSICAL_START can be as low as 0? (In fact, I doubt 0 would work
if chosen, but 2M surely does work, as I build some of my Dom0 kernels
that way.)

MAX, otoh, I guess really wants setting as you say, for KERNEL_IMAGE_SIZE
actually being commented upon as mis-named. Just that it now really wants
to be KERNEL_IMAGE_SIZE-1.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Mar 26 14:19:43 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Mar 2024 14:19:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698101.1089433 (Exim 4.92)
	(envelope-from )
	id 1rp7eM-00047N-6I; Tue, 26 Mar 2024 14:19:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698101.1089433; Tue, 26 Mar 2024 14:19:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rp7eM-00047G-3I; Tue, 26 Mar 2024 14:19:38 +0000
Received: by outflank-mailman (input) for mailman id 698101;
 Tue, 26 Mar 2024 14:19:36 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rp7eK-00047A-Cs
 for xen-devel@lists.xenproject.org; Tue, 26 Mar 2024 14:19:36 +0000
Received: from EUR01-DB5-obe.outbound.protection.outlook.com
 (mail-db5eur01on061d.outbound.protection.outlook.com
 [2a01:111:f400:fe02::61d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id debeed21-eb7b-11ee-afe3-a90da7624cb6;
 Tue, 26 Mar 2024 15:19:34 +0100 (CET)
Received: from DU7PR01CA0037.eurprd01.prod.exchangelabs.com
 (2603:10a6:10:50e::27) by DBBPR08MB10841.eurprd08.prod.outlook.com
 (2603:10a6:10:533::16) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.31; Tue, 26 Mar
 2024 14:19:32 +0000
Received: from DU2PEPF00028D13.eurprd03.prod.outlook.com
 (2603:10a6:10:50e:cafe::6e) by DU7PR01CA0037.outlook.office365.com
 (2603:10a6:10:50e::27) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.13 via Frontend
 Transport; Tue, 26 Mar 2024 14:19:32 +0000
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by
 DU2PEPF00028D13.mail.protection.outlook.com (10.167.242.27) with
 Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.7409.10
 via Frontend Transport; Tue, 26 Mar 2024 14:19:32 +0000
Received: ("Tessian outbound 1b0f2681ce6f:v300");
 Tue, 26 Mar 2024 14:19:31 +0000
Received: from c19ff881ff38.2
 by 64aa7808-outbound-1.mta.getcheckrecipient.com id
 8B81EFC4-418D-4289-B86B-C3AF66658A0F.1; 
 Tue, 26 Mar 2024 14:19:25 +0000
Received: from EUR02-DB5-obe.outbound.protection.outlook.com
 by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id c19ff881ff38.2
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384);
 Tue, 26 Mar 2024 14:19:25 +0000
Received: from AM6PR08MB3749.eurprd08.prod.outlook.com (2603:10a6:20b:8f::22)
 by AS2PR08MB10055.eurprd08.prod.outlook.com (2603:10a6:20b:645::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.32; Tue, 26 Mar
 2024 14:19:23 +0000
Received: from AM6PR08MB3749.eurprd08.prod.outlook.com
 ([fe80::3716:2f81:3984:f186]) by AM6PR08MB3749.eurprd08.prod.outlook.com
 ([fe80::3716:2f81:3984:f186%3]) with mapi id 15.20.7409.028; Tue, 26 Mar 2024
 14:19:23 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: debeed21-eb7b-11ee-afe3-a90da7624cb6
ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass;
 b=TEwintZXPnOIzpiwbyWE04CVa/Hyti2gyQtsOcqasYpWGU8/znzLp74ImTcS57l9llqZriqek+I0R2qF13Q+T1JBfH5h7zg78WcNW0CJxkmty8NAdWZA8VgHxIMBLcdgYryRqNMeVjO/OSj6LOS8n2MAZLaIHcIu4qnG3o8Hc0P2RC4Go6+VMMCikUAVKT5xgQ6u0RLH1xy2WGugoBSpmf/93/gszdFMYj1m0XM/SLR58AGUQuuR3y3n4v2O+4cKNl/WWMqJfLPlxXHx2bvBlr+l7ewsga6lJByw9gTwAh/bEyn6v1UESEl1/YynvXyw9mDRpYjZfWW77ypGt5SKwA==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Z+tYe4elhZdJp+BiMVTqTs9S+x6YORR9gCYEcIpP5hk=;
 b=HNxcGru1NLElXHBtn2d8Qo/UJEGbzANSiP/9Yg4vHsT2lrTJU+AQ7K2/WNlfb+Cn1Gn2Ety3+p0BWW/l0DdER9PcWHf/mVhZJTAxnUH9AGcuKPEdgZdEhD7M2zhrt/s9beWlx0lMarsCVIC6UWAc+c7oohr8z+hhV3ZsADwp4v5UjQESwEUyq8npNplZhnL0cq9/rhwF/mWkZnzsYHLxRTUMXJALrlrbfnb1xc/E2FqdxvcAnMWkWlAvjrQLyRW8Ibt2T+6BN8OeBKpbX9JzjXUq+SLiS/wQ/RPHZlHhLp90M+alfZNweM89qYqOxUYpQx1709RmELXmiPqs88bn2A==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 63.35.35.123) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=arm.com;
 dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com;
 dkim=pass (signature was verified) header.d=armh.onmicrosoft.com; arc=pass (0
 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com]
 dmarc=[1,1,header.from=arm.com])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com;
 s=selector2-armh-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=Z+tYe4elhZdJp+BiMVTqTs9S+x6YORR9gCYEcIpP5hk=;
 b=poTUVoAurBjNCbTa6An+7kQJpoFpzwEY9I7Uc3L5uoai5zheldyBhhu8inO5VeI55c7tjOemXxS1WsZo4+2dvL9tETugjjBH6t4rd6YUze0urlFG414EhF9G9EhMeY+C4aLI7DP36LwE8SE7DwYmmgEaDAytYfozzUYac6EhMyo=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=armh.onmicrosoft.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 63.35.35.123 as permitted sender) receiver=protection.outlook.com;
 client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
 pr=C
X-CheckRecipientChecked: true
X-CR-MTA-CID: 6ea786dc3d807939
X-CR-MTA-TID: 64aa7808
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=RfzbmzTNejDD+wKeAaEZlKWRi/PO2O+eQO3vYq4WUhm2W8tiW0smlC9ZcRTu90b/mOd6jULuXMmB124/5ZSTW25CZNlNrNsu7TX9/VTZvDbzCCht/mXtO1hxhMuX8xnY+EHhWHG3TDH5dIIyBIaypkUx8ZfzpYM07Vt1bfQDRLmiuzB0lZzJTfkIcrlOvtI80xS69CQcbjBbGW1/pYkeI+9pnwE3zMPLXHybGfJCCE0hdiSb7HWtbyNq9lry8dbP7sIatngY/gcLrUHqJJa4yIzkypY9ZswKVHrjvdLNHmcx0jHTDwSPk4cNvx945X+WgCHIrkiS6ygUTvLOiAiXjg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Z+tYe4elhZdJp+BiMVTqTs9S+x6YORR9gCYEcIpP5hk=;
 b=lIzwr0BXk8lLvbWHShXfMTJWuv3dIIzKP+cKaHDFOAbEMFLZa2kcLHJ5R2TythkZaXkB6XX/lZuiIytnd+VX+satsaydKPZJpfgVB9G5ApM7BBGnOuyMEZJRN5zviS68Xn2NtUIuJf0onETfaeZYvZaXt2ZUcj68Sd0/Q6S2paPWQXyraBfdTyt1jRgX7HqEy4i5UwYisVhctQA3VGadzLqKaCrlra+Ockhir0EoxFql76Un6Ic2V5Ehzu0SOhV6+nxKxKveMuRNPELVFisYMaOBq8PYmfR//gO7WqITsSl80YPFqY8QtlOZ9GiRGgN8KI4pPfzvAVoLTSfLKLvIbw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass
 header.d=arm.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com;
 s=selector2-armh-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=Z+tYe4elhZdJp+BiMVTqTs9S+x6YORR9gCYEcIpP5hk=;
 b=poTUVoAurBjNCbTa6An+7kQJpoFpzwEY9I7Uc3L5uoai5zheldyBhhu8inO5VeI55c7tjOemXxS1WsZo4+2dvL9tETugjjBH6t4rd6YUze0urlFG414EhF9G9EhMeY+C4aLI7DP36LwE8SE7DwYmmgEaDAytYfozzUYac6EhMyo=
From: Luca Fancellu 
To: Michal Orzel 
CC: Xen-devel , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Volodymyr Babchuk 
Subject: Re: [PATCH 11/11] xen/arm: List static shared memory regions as
 /memory nodes
Thread-Topic: [PATCH 11/11] xen/arm: List static shared memory regions as
 /memory nodes
Thread-Index: AQHadH3e45Ool8yPzEGouaBUJ1T0kbFIPF2AgAHrzQA=
Date: Tue, 26 Mar 2024 14:19:23 +0000
Message-ID: 
References: <20240312130331.78418-1-luca.fancellu@arm.com>
 <20240312130331.78418-12-luca.fancellu@arm.com>
 <3a9e8323-9eb3-4c06-9ef1-e85c8bf2aefd@amd.com>
In-Reply-To: <3a9e8323-9eb3-4c06-9ef1-e85c8bf2aefd@amd.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3774.400.31)
x-ms-traffictypediagnostic:
	AM6PR08MB3749:EE_|AS2PR08MB10055:EE_|DU2PEPF00028D13:EE_|DBBPR08MB10841:EE_
x-checkrecipientrouted: true
nodisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted: BCL:0;
X-Microsoft-Antispam-Message-Info-Original:
 04PSlS5EiNYwJYpTb51Z7E2PqgGZjOL95asfuKglf06PGtuz7s44ae+wCa7w6CvJ9uPRqvXiGHCMK3kogTTmokl/odJ5tMhxOI69VKQ22LxDihX1rdwmEzb+MP4Ne4hpL2aD3ZjLfVQiAsDMxeb8fdt8Rj5/AG/pGKuLoXySW0KGz2HNxryo/C/Ob9V84ZB0VipI1cjzjNYaeCkLxXiW7sMhuN3upt99iyVw71ryrWeucVgfXceqgA/fqanh5O1dyDe9UgIYHJmOEea3SN/w7CVwGt3vx3pbvh14xOzf97SJqyp9rFNbN4n92CGYUt/T9SfLA1G3H6GysqAMh6wTEp/V2zUIiMlzl5/IAxzEX8TktsSx0krKF1a6f7cN1mXnE3vxvAivmqPDyfqFHg73A1eyG1HZqp3N1XliKBkJgNASTUX7Sc4WYzH2wBtMg90hQEB2EzmMTecd+hNqYw0PACmRziBRcLWciSGujcxhCjDFqqV6woD+mGKk5BmLNhQCk2zE06anf/xk86ox3oSgbj3mzjvflpmhX6/T99CxqDLm65uKMBcuEphGTvNGanRWht1kO3LNLjva6fv1M2XjQZCNiX1mJS38IidW3hy6qjEJEny3kFN1uO9/49M5mfQFCW/+7PqdTSTTz25YJx3rSuCVBI5DJ3RafpRuMPg5JyQ=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM6PR08MB3749.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(366007)(1800799015)(376005);DIR:OUT;SFP:1102;
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR08MB10055
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 DU2PEPF00028D13.eurprd03.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 977fa108-eb4a-4f0a-f787-08dc4d9fc172
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	r07tT/eR/KeD5c5aVszWFBMrkGMYQ7au04AljskMKiS0Wgq1Dub/dYboKxbpwBCodh/2PUo/q6Vvu64ziyNq4Wfgb72QK9zBSkwJ+T28NTXhXMXzbF0sgowyxNEioq7cKzSocRNtQGwm7b7ndy2ME99Ecek8QDTDEzDdNFGfvSUGtk8hBGtRJ8zQoWTbHzc6po+Z1CY9hXDWdRV0TwqbghXrNRhzVtw4aPhx3lTDCUtQC1V2maUOhp+Fljg/tlEUhvahRpSt92eegonXVxaeKZoUY0MWVQktdt85MLUXaOnft1aNBg5vNczEScGQ3tGBfCCUYwwkC0GArWHQiOILY1J0hMcT27kj61IhU3Xxo2HktQXX+I15fp668iSkNVhTd/Wz285VDpv1BqCoYhk1YRDU02lm/k4yFp4wP/vzQSBrNWU0E+u81tlN7SkKXiik51V20/QoBY/TNSuAYaU/2+7f1wYvw1JvaS7jhgBArc3w6XUoehCGW1psL3hyAkqXmDiGxOKweE7orRplNOA7C+MXMw5ubf7LDx/dKk7A2+NrQexkaq+6sTNDjFNeQ4kLC0QuDp/jwo8pnkV+DRGJmhmFLQLBuvjGEzadqJPP5A3UcdZ6oFHSGyHMKOz9QemjR3SuqTowkHurYuYC2O9Sw+RmERKHkXzed1shJGelW4EH21DBfVowYEPS54aKBvDuFi9uei+CEuxkAQD+e5MULElCvVmgSkbNQe/KMNdaCZH7YroGq3u659RgCp50XuZ9
X-Forefront-Antispam-Report:
	CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com;CAT:NONE;SFS:(13230031)(82310400014)(36860700004)(1800799015)(376005);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Mar 2024 14:19:32.0287
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 977fa108-eb4a-4f0a-f787-08dc4d9fc172
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DU2PEPF00028D13.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR08MB10841

DQoNCj4gT24gMjUgTWFyIDIwMjQsIGF0IDA4OjU4LCBNaWNoYWwgT3J6ZWwgPG1pY2hhbC5vcnpl
bEBhbWQuY29tPiB3cm90ZToNCj4gDQo+IEhpIEx1Y2EsDQo+IA0KDQpIaSBNaWNoYWwsDQoNCj4g
T24gMTIvMDMvMjAyNCAxNDowMywgTHVjYSBGYW5jZWxsdSB3cm90ZToNCj4+IA0KPj4gDQo+PiBD
dXJyZW50bHkgWGVuIGlzIG5vdCBleHBvcnRpbmcgdGhlIHN0YXRpYyBzaGFyZWQgbWVtb3J5IHJl
Z2lvbnMNCj4+IHRvIHRoZSBkZXZpY2UgdHJlZSBhcyAvbWVtb3J5IG5vZGUsIHRoaXMgY29tbWl0
IGlzIGZpeGluZyB0aGlzDQo+PiBpc3N1ZS4NCj4gTG9va2luZyBhdCB0aGUgaW1wbGVtZW50YXRp
b24sIHlvdSB3aWxsIGFsd2F5cyBjYWxsIG1ha2Vfc2htX21lbW9yeV9ub2RlKCkgdHdpY2UuIEZv
ciB0aGUgZmlyc3QNCj4gdGltZSwgdG8gY3JlYXRlIC9tZW1vcnkgbm9kZSBhbmQgZm9yIHRoZSBz
ZWNvbmQgdGltZSB0byBjcmVhdGUgZW50cnkgdW5kZXIgL3Jlc2VydmVkLW1lbW9yeS4gQWxzbywN
Cj4geW91IHdpbGwgY3JlYXRlIGEgc2VwYXJhdGUgL21lbW9yeSBub2RlIGZvciBldmVyeSBzaW5n
bGUgc2htZW0gcmVnaW9uIGluc3RlYWQgb2YgY29tYmluaW5nIHRoZW0NCj4gaW4gYSBzaW5nbGUg
L21lbW9yeSByZWdpb24gbGlrZSBtYWtlX21lbW9yeV9ub2RlKCkgd291bGQgZG8uIENhbid0IHdl
IHJldXNlIHRoaXMgZnVuY3Rpb24gZm9yIHNpbXBsaWNpdHk/DQoNCllvdSBtZWFuIHVzaW5nIG1h
a2VfbWVtb3J5X25vZGUoKSB0byBwb3B1bGF0ZSAvcmVzZXJ2ZWQtbWVtb3J5IGFuZCAvbWVtb3J5
PyBJIGZlZWwgdGhleSBhcmUgdmVyeSBkaWZmZXJlbnQNCkluIHRlcm1zIG9mIHByb3BlcnRpZXMg
dG8gYmUgY3JlYXRlZCwgc28gSSBkb27igJl0IHRoaW5rIHdlIHNob3VsZCBjcmVhdGUgYSBtYWtl
X21lbW9yeV9ub2RlKCkgdGhhdCBkb2VzIGJvdGguDQoNCk90aGVyd2lzZSBpZiB5b3Ugd2VyZSBz
dWdnZXN0aW5nIHRvIG1vZGlmeSBtYWtlX21lbW9yeV9ub2RlKCkgb25seSBmb3Igd2hhdCBjb25j
ZXJucyB0aGUgL21lbW9yeSBub2RlcywNCml0IG1pZ2h0IGJlIGZlYXNpYmxlLCBob3dldmVyIHRo
ZXJlIGFyZSBzb21lIHBhcnRzIHRoYXQgbmVlZCB0byBiZSBza2lwcGVkIHdpdGggc29tZSBmbGFn
cyAoYWxsIHRoZSBjb2RlIGFjY2Vzc2luZyAudHlwZQ0KbWVtYmVyKSwgaWYgSSB1bmRlcnN0YW5k
IGNvcnJlY3RseSB5b3UgbGlrZSB0aGlzIGZ1bmN0aW9uIGJlY2F1c2UgaXQgZG9lc27igJl0IGNy
ZWF0ZSBvbmUgbm9kZSBmb3IgZXZlcnkgYmFuaywgYnV0IGl0IGNyZWF0ZXMNCnJlZyBhZGRyZXNz
ZXMgaW5zdGVhZCwgaW4gdGhhdCBjYXNlIEkgY291bGQgbW9kaWZ5IHRoZSBjdXJyZW50IG1ha2Vf
c2htX21lbW9yeV9ub2RlKCkgdG8gZG8gdGhlIHNhbWUuDQoNCj4gDQo+IEFsc28sIGFmYWljdCBp
dCBpcyBub3QgZm9yYmlkZGVuIHRvIHNwZWNpZnkgc2htZW0gcmFuZ2UgKGNvcnJlY3QgbWUgaWYg
SSdtIHdyb25nKSwgd2hlcmUgZ3Vlc3QgYWRkcmVzcyB3aWxsIGJlDQo+IHdpdGhpbiB3aXRoIFJB
TSBhbGxvY2F0ZWQgYnkgWGVuIChlLmcuIEdQQSBSQU0gcmFuZ2UgMHg0MDAwMDAwMCAtIDB4NjAw
MDAwMDAgYW5kIHNobWVtIGlzIGF0IDB4NTAwMDAwMDApLiBJbiB0aGlzIGNhc2UsDQo+IHlvdSB3
b3VsZCBjcmVhdGUgeWV0IGFub3RoZXIgL21lbW9yeSBub2RlIHRoYXQgd291bGQgcmVzdWx0IGlu
IG92ZXJsYXAgKGkuZS4gbW9yZSB0aGFuIG9uZSAvbWVtb3J5IG5vZGUgc3BlY2lmeWluZyB0aGUg
c2FtZSByYW5nZSkuDQoNClRoaXMgaXMgYSBnb29kIHBvaW50IEkgZGlkbuKAmXQgdGhpbmsgYWJv
dXQsIHllcyBjdXJyZW50bHkgdGhlIGNvZGUgaXMgY3JlYXRpbmcgb3ZlcmxhcHBpbmcgbm9kZXMg
aW4gdGhhdCBjYXNlLCB3b3cgc28gaXQgbWVhbnMgSQ0KbmVlZCB0byBjb21wdXRlIHRoZSBub24g
b3ZlcmxhcHBpbmcgcmVnaW9ucyBhbmQgZW1pdCBhIC9tZW1vcnkgbm9kZSB0aGVuISA6KSBvdWNo
DQoNClBsZWFzZSBsZXQgbWUga25vdyBpZiBJIHVuZGVyc3Rvb2QgY29ycmVjdGx5IHlvdXIgY29t
bWVudHMuDQoNCkNoZWVycywNCkx1Y2ENCg0KPiANCj4gfk1pY2hhbA0KDQo=


From xen-devel-bounces@lists.xenproject.org Tue Mar 26 14:31:07 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Mar 2024 14:31:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698107.1089443 (Exim 4.92)
	(envelope-from )
	id 1rp7pI-00076G-9q; Tue, 26 Mar 2024 14:30:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698107.1089443; Tue, 26 Mar 2024 14:30:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rp7pI-000769-5o; Tue, 26 Mar 2024 14:30:56 +0000
Received: by outflank-mailman (input) for mailman id 698107;
 Tue, 26 Mar 2024 14:30:54 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rp7pG-000761-JH
 for xen-devel@lists.xenproject.org; Tue, 26 Mar 2024 14:30:54 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7296f0b1-eb7d-11ee-a1ef-f123f15fe8a2;
 Tue, 26 Mar 2024 15:30:52 +0100 (CET)
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 by support.bugseng.com (Postfix) with ESMTPA id C7A904EE0739;
 Tue, 26 Mar 2024 15:30:51 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7296f0b1-eb7d-11ee-a1ef-f123f15fe8a2
MIME-Version: 1.0
Date: Tue, 26 Mar 2024 15:30:51 +0100
From: Nicola Vetrini 
To: Jan Beulich 
Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com,
 ayan.kumar.halder@amd.com, consulting@bugseng.com,
 andrew.cooper3@citrix.com, roger.pau@citrix.com, bertrand.marquis@arm.com,
 julien@xen.org, xen-devel@lists.xenproject.org
Subject: Re: [XEN PATCH 09/11] x86/msi: address violation of MISRA C Rule 20.7
 and coding style
In-Reply-To: 
References: 
 
 
Message-ID: 
X-Sender: nicola.vetrini@bugseng.com
Organization: BUGSENG s.r.l.
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit

On 2024-03-26 11:05, Jan Beulich wrote:
> On 22.03.2024 17:01, Nicola Vetrini wrote:
>> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
>> of macro parameters shall be enclosed in parentheses". Therefore, some
>> macro definitions should gain additional parentheses to ensure that 
>> all
>> current and future users will be safe with respect to expansions that
>> can possibly alter the semantics of the passed-in macro parameter.
>> 
>> While at it, the style of these macros has been somewhat uniformed.
> 
> Hmm, yes, but they then still leave more to be desired. I guess I can 
> see
> though why you don't want to e.g. ...
> 
>> --- a/xen/arch/x86/include/asm/msi.h
>> +++ b/xen/arch/x86/include/asm/msi.h
>> @@ -147,33 +147,34 @@ int msi_free_irq(struct msi_desc *entry);
>>   */
>>  #define NR_HP_RESERVED_VECTORS 	20
>> 
>> -#define msi_control_reg(base)		(base + PCI_MSI_FLAGS)
>> -#define msi_lower_address_reg(base)	(base + PCI_MSI_ADDRESS_LO)
>> -#define msi_upper_address_reg(base)	(base + PCI_MSI_ADDRESS_HI)
>> -#define msi_data_reg(base, is64bit)	\
>> -	( (is64bit == 1) ? base+PCI_MSI_DATA_64 : base+PCI_MSI_DATA_32 )
>> -#define msi_mask_bits_reg(base, is64bit) \
>> -	( (is64bit == 1) ? base+PCI_MSI_MASK_BIT : base+PCI_MSI_MASK_BIT-4)
>> +#define msi_control_reg(base)        ((base) + PCI_MSI_FLAGS)
>> +#define msi_lower_address_reg(base)  ((base) + PCI_MSI_ADDRESS_LO)
>> +#define msi_upper_address_reg(base)  ((base) + PCI_MSI_ADDRESS_HI)
>> +#define msi_data_reg(base, is64bit) \
>> +    (((is64bit) == 1) ? (base) + PCI_MSI_DATA_64 : (base) + 
>> PCI_MSI_DATA_32)
>> +#define msi_mask_bits_reg(base, is64bit)                \
>> +    (((is64bit) == 1) ? (base) + PCI_MSI_MASK_BIT       \
>> +                      : (base) + PCI_MSI_MASK_BIT - 4)
> 
> ... drop the bogus == 1 in these two, making them similar to ...
> 
>>  #define msi_pending_bits_reg(base, is64bit) \
>> -	((base) + PCI_MSI_MASK_BIT + ((is64bit) ? 4 : 0))
>> -#define msi_disable(control)		control &= ~PCI_MSI_FLAGS_ENABLE
>> +    ((base) + PCI_MSI_MASK_BIT + ((is64bit) ? 4 : 0))
> 
> ... this.
> 
>> +#define msi_disable(control) (control) &= ~PCI_MSI_FLAGS_ENABLE
> 
> Doesn't this need an outer pair of parentheses, too?
> 

Not necessarily. I'm in favour of a consistent style to be converted in. 
This also applies below.

>>  #define multi_msi_capable(control) \
>> -	(1 << ((control & PCI_MSI_FLAGS_QMASK) >> 1))
>> +    (1 << (((control) & PCI_MSI_FLAGS_QMASK) >> 1))
>>  #define multi_msi_enable(control, num) \
>> -	control |= (((fls(num) - 1) << 4) & PCI_MSI_FLAGS_QSIZE);
>> -#define is_64bit_address(control)	(!!(control & PCI_MSI_FLAGS_64BIT))
>> -#define is_mask_bit_support(control)	(!!(control & 
>> PCI_MSI_FLAGS_MASKBIT))
>> +    (control) |= (((fls(num) - 1) << 4) & PCI_MSI_FLAGS_QSIZE);
> 
> And this, together with dropping the bogus semicolon?
> 

I'll drop the semicolon.

> There also look to be cases where MASK_EXTR() / MASK_INSR() would want 
> using,
> in favor of using open-coded numbers.
> 

Yes, perhaps. However, the risk that I make some mistakes in doing so 
are quite high, though.

>> +#define is_64bit_address(control) (!!((control) & 
>> PCI_MSI_FLAGS_64BIT))
>> +#define is_mask_bit_support(control) (!!((control) & 
>> PCI_MSI_FLAGS_MASKBIT))
>>  #define msi_enable(control, num) multi_msi_enable(control, num); \
>> -	control |= PCI_MSI_FLAGS_ENABLE
>> -
>> -#define msix_control_reg(base)		(base + PCI_MSIX_FLAGS)
>> -#define msix_table_offset_reg(base)	(base + PCI_MSIX_TABLE)
>> -#define msix_pba_offset_reg(base)	(base + PCI_MSIX_PBA)
>> -#define msix_enable(control)	 	control |= PCI_MSIX_FLAGS_ENABLE
>> -#define msix_disable(control)	 	control &= ~PCI_MSIX_FLAGS_ENABLE
>> -#define msix_table_size(control) 	((control & 
>> PCI_MSIX_FLAGS_QSIZE)+1)
>> -#define msix_unmask(address)	 	(address & ~PCI_MSIX_VECTOR_BITMASK)
>> -#define msix_mask(address)		(address | PCI_MSIX_VECTOR_BITMASK)
>> +                                 (control) |= PCI_MSI_FLAGS_ENABLE
> 
> This again is suspiciously missing outer parentheses; really here, with
> the earlier statement, it look like do { ... } while ( 0 ) or ({ ... })
> are wanted.
> 
>> +#define msix_control_reg(base)       ((base) + PCI_MSIX_FLAGS)
>> +#define msix_table_offset_reg(base)  ((base) + PCI_MSIX_TABLE)
>> +#define msix_pba_offset_reg(base)    ((base) + PCI_MSIX_PBA)
>> +#define msix_enable(control)         (control) |= 
>> PCI_MSIX_FLAGS_ENABLE
>> +#define msix_disable(control)        (control) &= 
>> ~PCI_MSIX_FLAGS_ENABLE
> 
> Outer parentheses missing for these two again?
> 
> Jan

-- 
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)


From xen-devel-bounces@lists.xenproject.org Tue Mar 26 14:31:54 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Mar 2024 14:31:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698108.1089454 (Exim 4.92)
	(envelope-from )
	id 1rp7qE-0007f6-Jv; Tue, 26 Mar 2024 14:31:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698108.1089454; Tue, 26 Mar 2024 14:31:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rp7qE-0007ez-Eg; Tue, 26 Mar 2024 14:31:54 +0000
Received: by outflank-mailman (input) for mailman id 698108;
 Tue, 26 Mar 2024 14:31:53 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rp7qD-0007er-SX
 for xen-devel@lists.xenproject.org; Tue, 26 Mar 2024 14:31:53 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9690cc16-eb7d-11ee-afe3-a90da7624cb6;
 Tue, 26 Mar 2024 15:31:52 +0100 (CET)
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 by support.bugseng.com (Postfix) with ESMTPA id 5946D4EE0739;
 Tue, 26 Mar 2024 15:31:52 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9690cc16-eb7d-11ee-afe3-a90da7624cb6
MIME-Version: 1.0
Date: Tue, 26 Mar 2024 15:31:52 +0100
From: Nicola Vetrini 
To: Jan Beulich 
Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com,
 ayan.kumar.halder@amd.com, consulting@bugseng.com,
 andrew.cooper3@citrix.com, roger.pau@citrix.com, bertrand.marquis@arm.com,
 julien@xen.org, xen-devel@lists.xenproject.org
Subject: Re: [XEN PATCH 10/11] x86/hvm: address violations of Rule 20.7
In-Reply-To: <1c7475d7-b4ac-492f-8abd-2ab3b60c2a29@suse.com>
References: 
 
 <1c7475d7-b4ac-492f-8abd-2ab3b60c2a29@suse.com>
Message-ID: <59c7cf8e513f07680703b2c90449a50c@bugseng.com>
X-Sender: nicola.vetrini@bugseng.com
Organization: BUGSENG s.r.l.
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit

On 2024-03-26 11:13, Jan Beulich wrote:
> On 22.03.2024 17:01, Nicola Vetrini wrote:
>> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
>> of macro parameters shall be enclosed in parentheses". Therefore, some
>> macro definitions should gain additional parentheses to ensure that 
>> all
>> current and future users will be safe with respect to expansions that
>> can possibly alter the semantics of the passed-in macro parameter.
>> 
>> No functional change.
>> 
>> Signed-off-by: Nicola Vetrini 
> 
> Acked-by: Jan Beulich 
> albeit preferably with ...
> 
>> --- a/xen/arch/x86/include/asm/hvm/save.h
>> +++ b/xen/arch/x86/include/asm/hvm/save.h
>> @@ -128,9 +128,9 @@ static int __init cf_check 
>> __hvm_register_##_x##_save_and_restore(void)   \
>>  {                                                                     
>>     \
>>      hvm_register_savevm(HVM_SAVE_CODE(_x),                            
>>     \
>>                          #_x,                                          
>>     \
>> -                        &_save,                                       
>>     \
>> +                        &(_save),                                     
>>     \
>>                          check,                                        
>>     \
>> -                        &_load,                                       
>>     \
>> +                        &(_load),                                     
>>     \
> 
> ... the &s dropped rather than parentheses added, as we already have it
> for (the recently added) "check".
> 
> Jan

Sounds good

-- 
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)


From xen-devel-bounces@lists.xenproject.org Tue Mar 26 14:34:06 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Mar 2024 14:34:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698110.1089463 (Exim 4.92)
	(envelope-from )
	id 1rp7sL-0008HC-TI; Tue, 26 Mar 2024 14:34:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698110.1089463; Tue, 26 Mar 2024 14:34:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rp7sL-0008H5-QY; Tue, 26 Mar 2024 14:34:05 +0000
Received: by outflank-mailman (input) for mailman id 698110;
 Tue, 26 Mar 2024 14:34:04 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rp7sK-0008Gx-Lt
 for xen-devel@lists.xenproject.org; Tue, 26 Mar 2024 14:34:04 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e419437f-eb7d-11ee-a1ef-f123f15fe8a2;
 Tue, 26 Mar 2024 15:34:02 +0100 (CET)
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 by support.bugseng.com (Postfix) with ESMTPA id 7777E4EE0739;
 Tue, 26 Mar 2024 15:34:02 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e419437f-eb7d-11ee-a1ef-f123f15fe8a2
MIME-Version: 1.0
Date: Tue, 26 Mar 2024 15:34:02 +0100
From: Nicola Vetrini 
To: Jan Beulich 
Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com,
 ayan.kumar.halder@amd.com, consulting@bugseng.com,
 andrew.cooper3@citrix.com, roger.pau@citrix.com, bertrand.marquis@arm.com,
 julien@xen.org, xen-devel@lists.xenproject.org
Subject: Re: [XEN PATCH 11/11] x86/public: hvm: address violations of MISRA C
 Rule 20.7
In-Reply-To: <77f8990e-5809-4429-92d6-53bbddc89caa@suse.com>
References: 
 
 <77f8990e-5809-4429-92d6-53bbddc89caa@suse.com>
Message-ID: 
X-Sender: nicola.vetrini@bugseng.com
Organization: BUGSENG s.r.l.
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit

On 2024-03-26 11:15, Jan Beulich wrote:
> On 22.03.2024 17:02, Nicola Vetrini wrote:
>> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
>> of macro parameters shall be enclosed in parentheses". Therefore, some
>> macro definitions should gain additional parentheses to ensure that 
>> all
>> current and future users will be safe with respect to expansions that
>> can possibly alter the semantics of the passed-in macro parameter.
>> 
>> No functional change.
>> 
>> Signed-off-by: Nicola Vetrini 
> 
> Acked-by: Jan Beulich 
> 
>> --- a/xen/include/public/arch-x86/xen.h
>> +++ b/xen/include/public/arch-x86/xen.h
>> @@ -36,7 +36,7 @@
>>  #define __XEN_GUEST_HANDLE(name)        __guest_handle_ ## name
>>  #define XEN_GUEST_HANDLE(name)          __XEN_GUEST_HANDLE(name)
>>  #define XEN_GUEST_HANDLE_PARAM(name)    XEN_GUEST_HANDLE(name)
>> -#define set_xen_guest_handle_raw(hnd, val)  do { (hnd).p = val; } 
>> while (0)
>> +#define set_xen_guest_handle_raw(hnd, val)  do { (hnd).p = (val); } 
>> while (0)
>>  #define set_xen_guest_handle(hnd, val) set_xen_guest_handle_raw(hnd, 
>> val)
>> 
>>  #if defined(__i386__)
> 
> Would have been nice though to do the same thing for Arm at the same 
> time.
> PPC and RISC-V already have "val" parenthesized there.
> 
> Jan

Ok, no problem.

-- 
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)


From xen-devel-bounces@lists.xenproject.org Tue Mar 26 15:13:39 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Mar 2024 15:13:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698118.1089472 (Exim 4.92)
	(envelope-from )
	id 1rp8UW-0005Af-Nl; Tue, 26 Mar 2024 15:13:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698118.1089472; Tue, 26 Mar 2024 15:13:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rp8UW-0005AY-LC; Tue, 26 Mar 2024 15:13:32 +0000
Received: by outflank-mailman (input) for mailman id 698118;
 Tue, 26 Mar 2024 15:13:31 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rp8UV-0005AS-4e
 for xen-devel@lists.xenproject.org; Tue, 26 Mar 2024 15:13:31 +0000
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com
 [2a00:1450:4864:20::533])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6663218b-eb83-11ee-a1ef-f123f15fe8a2;
 Tue, 26 Mar 2024 16:13:28 +0100 (CET)
Received: by mail-ed1-x533.google.com with SMTP id
 4fb4d7f45d1cf-56bf63af770so1547759a12.3
 for ; Tue, 26 Mar 2024 08:13:28 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 c15-20020a0564021f8f00b0056bfca6f1c0sm3653022edc.15.2024.03.26.08.13.27
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 26 Mar 2024 08:13:27 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6663218b-eb83-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711466008; x=1712070808; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=3PmQ0DJUU4ufZOF32ltaaX6qJTuFLYcOLujM5fW4QJ8=;
        b=gxn9TCFVi16wb5Fx9l4QYWkcUlol4nfiFWgkRsEbUIjfFKEM49BBdA92kkyPoPD+VN
         ZU2tgUAYykwlA2pK24rcCwOll5jI49I6SZjJRBOLZvc5xA/dgAn1uvr/aw17t0ezB6v2
         yk9qmsPr45xXDablO7GpHgASlEGoBbtVu6diNmx2+FeMj/5m/d7d6yTyQvU8mhdikYnz
         wmW+BTz9rZqVafqXNrv6G7wo5tX773p+/BNWFTlvtkRYSAFxbjlfmYPdxiUwPwTKmf8n
         /YKRNTvOlbVK7oDUaIH5bq83sqDwCsNxh0vk4MsU1gcQoRqZfXEKZncAYH1FCZSTGekE
         plPQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711466008; x=1712070808;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=3PmQ0DJUU4ufZOF32ltaaX6qJTuFLYcOLujM5fW4QJ8=;
        b=w15Rpd417mQrFPSop7wMJr5M4h8nkXl3EDCUbWmoKi5DoqJqQJ7I2pbT0dlZrwKeYS
         Pb6Wu8FyXS2AhtvHdM8GOw3AdH4QzakA/7k8Qoycc9rNn49ozMoTGRwpj3RMR/KwARAI
         xy0oyDg4QnyF+RIiPXg3GBmXva8eIwZRAC1vVMtLiPega78gEaJkiiDGEFzJ9ar+9DFI
         jX1ARDEmhZKAnTPPHhLGt6dB6z8x41fDEN+bMGSlfeOHgdamo3RNY8fP82iYJRUzqDea
         LrekJ+M3mm5v6Gjw/jCTMpN1c5bcgEfKVDBzKqP1WSqRgXeQR282VBrvGb+ZV8XR1bOy
         SUxw==
X-Forwarded-Encrypted: i=1; AJvYcCWKGz9pczHFPMwditvXGS6goCBvGE/MCN0+hP0IBYeuNvWoxn6fuE1dLHBXxHYUGLnlyEpdQevpV/02Z3JIBs5vnHN+1QTGiO9NuAHzYBU=
X-Gm-Message-State: AOJu0YwTmAxKQMJHI/7r6drmBOvhPenc1JIgmnSHFblJbSiiVNqw3+0k
	TYvb8P1sA9t1IGSlr6FG7rYeRbIMZ1XjEJ/PPDNiYeEa79GA+Wx2d3/62gm/9Q==
X-Google-Smtp-Source: AGHT+IE3ExsgPiOr8VzO6XpF5zPttfq8GeYBorVOip47Al9AQcVh2R9+3ieqKMXz9ajoyVmcdBLeiA==
X-Received: by 2002:a50:9510:0:b0:56b:d21f:2790 with SMTP id u16-20020a509510000000b0056bd21f2790mr87354eda.41.1711466008280;
        Tue, 26 Mar 2024 08:13:28 -0700 (PDT)
Message-ID: <465034fd-d2bc-4fe1-8c04-bdb1d60bfafc@suse.com>
Date: Tue, 26 Mar 2024 16:13:26 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 09/11] x86/msi: address violation of MISRA C Rule 20.7
 and coding style
Content-Language: en-US
To: Nicola Vetrini 
Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com,
 ayan.kumar.halder@amd.com, consulting@bugseng.com,
 andrew.cooper3@citrix.com, roger.pau@citrix.com, bertrand.marquis@arm.com,
 julien@xen.org, xen-devel@lists.xenproject.org
References: 
 
 
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 26.03.2024 15:30, Nicola Vetrini wrote:
> On 2024-03-26 11:05, Jan Beulich wrote:
>> On 22.03.2024 17:01, Nicola Vetrini wrote:
>>> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
>>> of macro parameters shall be enclosed in parentheses". Therefore, some
>>> macro definitions should gain additional parentheses to ensure that 
>>> all
>>> current and future users will be safe with respect to expansions that
>>> can possibly alter the semantics of the passed-in macro parameter.
>>>
>>> While at it, the style of these macros has been somewhat uniformed.
>>
>> Hmm, yes, but they then still leave more to be desired. I guess I can 
>> see
>> though why you don't want to e.g. ...
>>
>>> --- a/xen/arch/x86/include/asm/msi.h
>>> +++ b/xen/arch/x86/include/asm/msi.h
>>> @@ -147,33 +147,34 @@ int msi_free_irq(struct msi_desc *entry);
>>>   */
>>>  #define NR_HP_RESERVED_VECTORS 	20
>>>
>>> -#define msi_control_reg(base)		(base + PCI_MSI_FLAGS)
>>> -#define msi_lower_address_reg(base)	(base + PCI_MSI_ADDRESS_LO)
>>> -#define msi_upper_address_reg(base)	(base + PCI_MSI_ADDRESS_HI)
>>> -#define msi_data_reg(base, is64bit)	\
>>> -	( (is64bit == 1) ? base+PCI_MSI_DATA_64 : base+PCI_MSI_DATA_32 )
>>> -#define msi_mask_bits_reg(base, is64bit) \
>>> -	( (is64bit == 1) ? base+PCI_MSI_MASK_BIT : base+PCI_MSI_MASK_BIT-4)
>>> +#define msi_control_reg(base)        ((base) + PCI_MSI_FLAGS)
>>> +#define msi_lower_address_reg(base)  ((base) + PCI_MSI_ADDRESS_LO)
>>> +#define msi_upper_address_reg(base)  ((base) + PCI_MSI_ADDRESS_HI)
>>> +#define msi_data_reg(base, is64bit) \
>>> +    (((is64bit) == 1) ? (base) + PCI_MSI_DATA_64 : (base) + 
>>> PCI_MSI_DATA_32)
>>> +#define msi_mask_bits_reg(base, is64bit)                \
>>> +    (((is64bit) == 1) ? (base) + PCI_MSI_MASK_BIT       \
>>> +                      : (base) + PCI_MSI_MASK_BIT - 4)
>>
>> ... drop the bogus == 1 in these two, making them similar to ...
>>
>>>  #define msi_pending_bits_reg(base, is64bit) \
>>> -	((base) + PCI_MSI_MASK_BIT + ((is64bit) ? 4 : 0))
>>> -#define msi_disable(control)		control &= ~PCI_MSI_FLAGS_ENABLE
>>> +    ((base) + PCI_MSI_MASK_BIT + ((is64bit) ? 4 : 0))
>>
>> ... this.
>>
>>> +#define msi_disable(control) (control) &= ~PCI_MSI_FLAGS_ENABLE
>>
>> Doesn't this need an outer pair of parentheses, too?
>>
> 
> Not necessarily.

And use of msi_disable() in another expression would then likely not do
what's expected?

> I'm in favour of a consistent style to be converted in. 
> This also applies below.

I'm all for consistency; I just don't know what you want to be consistent
with, here.

>>>  #define multi_msi_capable(control) \
>>> -	(1 << ((control & PCI_MSI_FLAGS_QMASK) >> 1))
>>> +    (1 << (((control) & PCI_MSI_FLAGS_QMASK) >> 1))
>>>  #define multi_msi_enable(control, num) \
>>> -	control |= (((fls(num) - 1) << 4) & PCI_MSI_FLAGS_QSIZE);
>>> -#define is_64bit_address(control)	(!!(control & PCI_MSI_FLAGS_64BIT))
>>> -#define is_mask_bit_support(control)	(!!(control & 
>>> PCI_MSI_FLAGS_MASKBIT))
>>> +    (control) |= (((fls(num) - 1) << 4) & PCI_MSI_FLAGS_QSIZE);
>>
>> And this, together with dropping the bogus semicolon?
>>
> 
> I'll drop the semicolon.
> 
>> There also look to be cases where MASK_EXTR() / MASK_INSR() would want 
>> using,
>> in favor of using open-coded numbers.
> 
> Yes, perhaps. However, the risk that I make some mistakes in doing so 
> are quite high, though.

Right, hence how I started my earlier reply. Question is - do we want to
go just half the way here, or would we better tidy things all in one go?
In the latter case I could see about getting to that (whether to take
your patch as basis or instead do it from scratch isn't quite clear to
me at this point).

Jan


From xen-devel-bounces@lists.xenproject.org Tue Mar 26 15:27:37 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Mar 2024 15:27:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698122.1089483 (Exim 4.92)
	(envelope-from )
	id 1rp8i4-0006yo-T9; Tue, 26 Mar 2024 15:27:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698122.1089483; Tue, 26 Mar 2024 15:27:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rp8i4-0006yh-PD; Tue, 26 Mar 2024 15:27:32 +0000
Received: by outflank-mailman (input) for mailman id 698122;
 Tue, 26 Mar 2024 15:27:31 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rp8i3-0006ya-Kn
 for xen-devel@lists.xenproject.org; Tue, 26 Mar 2024 15:27:31 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5aa81742-eb85-11ee-a1ef-f123f15fe8a2;
 Tue, 26 Mar 2024 16:27:28 +0100 (CET)
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 by support.bugseng.com (Postfix) with ESMTPA id 8BCEA4EE0739;
 Tue, 26 Mar 2024 16:27:27 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5aa81742-eb85-11ee-a1ef-f123f15fe8a2
MIME-Version: 1.0
Date: Tue, 26 Mar 2024 16:27:27 +0100
From: Nicola Vetrini 
To: Jan Beulich 
Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com,
 ayan.kumar.halder@amd.com, consulting@bugseng.com,
 andrew.cooper3@citrix.com, roger.pau@citrix.com, bertrand.marquis@arm.com,
 julien@xen.org, George Dunlap ,
 xen-devel@lists.xenproject.org
Subject: Re: [XEN PATCH 07/11] xen/page_alloc: address violations of MISRA C
 Rule 20.7
In-Reply-To: 
References: 
 
 
Message-ID: 
X-Sender: nicola.vetrini@bugseng.com
Organization: BUGSENG s.r.l.
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit

Hi Jan,

sorry, forgot to reply.

On 2024-03-25 10:27, Jan Beulich wrote:
> On 22.03.2024 17:01, Nicola Vetrini wrote:
>> --- a/xen/common/page_alloc.c
>> +++ b/xen/common/page_alloc.c
>> @@ -150,7 +150,7 @@
>>  #include 
>>  #else
>>  #define p2m_pod_offline_or_broken_hit(pg) 0
> 
> Seeing this in context: Does Misra also have a rule demanding 
> evaluation
> of macro arguments?
> 

No such rule. There is one for unused function parameters, though.

>> -#define p2m_pod_offline_or_broken_replace(pg) BUG_ON(pg != NULL)
>> +#define p2m_pod_offline_or_broken_replace(pg) BUG_ON((pg) != NULL)
> 
> Or easier
> 
> #define p2m_pod_offline_or_broken_replace(pg) BUG_ON(pg)
> 
> ?
> 

Good point. I'll modify it.

> Jan

-- 
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)


From xen-devel-bounces@lists.xenproject.org Tue Mar 26 15:36:04 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Mar 2024 15:36:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698126.1089492 (Exim 4.92)
	(envelope-from )
	id 1rp8q8-0000Jb-LI; Tue, 26 Mar 2024 15:35:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698126.1089492; Tue, 26 Mar 2024 15:35:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rp8q8-0000JU-IZ; Tue, 26 Mar 2024 15:35:52 +0000
Received: by outflank-mailman (input) for mailman id 698126;
 Tue, 26 Mar 2024 15:35:51 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rp8q7-0000JO-De
 for xen-devel@lists.xenproject.org; Tue, 26 Mar 2024 15:35:51 +0000
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com
 [2a00:1450:4864:20::632])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 86093720-eb86-11ee-afe3-a90da7624cb6;
 Tue, 26 Mar 2024 16:35:50 +0100 (CET)
Received: by mail-ej1-x632.google.com with SMTP id
 a640c23a62f3a-a4702457ccbso728700566b.3
 for ; Tue, 26 Mar 2024 08:35:50 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 f12-20020a170906084c00b00a42f6d17123sm4312017ejd.46.2024.03.26.08.35.49
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 26 Mar 2024 08:35:49 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 86093720-eb86-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711467350; x=1712072150; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=x5tlE2Lgt5hafUbY7kklfIB9+yT3fJaSoqSNj/1aQfM=;
        b=Iq2mLLXdDv6EJj39dFu/l5V3O+7k2SO6hnTCZWJOmVabpVUiK8NvYn9hylXG815ZsZ
         HmAwB5e5Bpk7lj87/+Scb5YkG8E0bLHBFTO7f8wX1Iwd3GumoA83XxtrpNvfxqg3cqGz
         0V6P1zPRAZ77AOfndEE2Z6w3ZuwzPBq3TTMdiZ8L2teL1RrTMmdbsUzLl3wO9ForN708
         dPHJPS/3vQgCbH0fF+P1ar+zbANgpTWHYjbj0Lkc67v+77KiFNRmojvROXVUo9PL7Ecy
         8hKVLiclvm9Edc3lgXlp9iE66hGNfk09is+9XOQBLtqzuyIpLS2vL4wQzreEzr/uHjy4
         SwSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711467350; x=1712072150;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=x5tlE2Lgt5hafUbY7kklfIB9+yT3fJaSoqSNj/1aQfM=;
        b=QtCDVTyVuf5VIZo+kLSjTihGM9pN7YfeOvKELXY4MIvMpWnIoy5QDF7niYHS/4MC60
         LxiVyJV3xMxobAngDlMxZamY/G4YEIjspf2mYZe9iIccFkvvi/YzRSDkK/6EGtAeYIRl
         0hqe1ELS5eGQgpZaQKd9L0DdAQc3wyi2X/lSPYfawIklOrF35yYemTNhqOMbm4D07HvE
         N8WlKtO5OhA1xhspupWqDW4UtKBC+fJNU3S/EI1adOJiIUuSA/USARIcq2ap2ofEYabj
         aoiWTTFCURz3oNABssv1cvx7PtzcSMthmVqui4sItXntBCVX/CEd0W06Yj7AVVGF/Fhz
         G5BA==
X-Forwarded-Encrypted: i=1; AJvYcCVdRIBUxDKsAjpyAMYQul4nIIqybcTDiwP1K4UnioMEvesHnZgfBKTqGd9b8krNcNO2871q2kAWnUdzIksszbna8U1ka51+ZIrLsry3M0Y=
X-Gm-Message-State: AOJu0Yy5wF3vQbJm4ZDMw2xSp7DkjY5vr8c64bj8+P8dI4iMRVOFdngc
	JDwoum08JxZcwTTZEpsA1J/FTwXY0MZbke+OmNT5l0N4Gmd9owAVV1Jq9DDlYQ==
X-Google-Smtp-Source: AGHT+IHPx7Y9I8yNU81jy74m565ywY0IRwD+kXRS7/l1lKDaditjD/FGVja1tns/LqqNWzdEq44s0Q==
X-Received: by 2002:a17:906:1d04:b0:a47:34c8:900b with SMTP id n4-20020a1709061d0400b00a4734c8900bmr7001061ejh.0.1711467349742;
        Tue, 26 Mar 2024 08:35:49 -0700 (PDT)
Message-ID: 
Date: Tue, 26 Mar 2024 16:35:48 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 07/11] xen/page_alloc: address violations of MISRA C
 Rule 20.7
Content-Language: en-US
To: Nicola Vetrini 
Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com,
 ayan.kumar.halder@amd.com, consulting@bugseng.com,
 andrew.cooper3@citrix.com, roger.pau@citrix.com, bertrand.marquis@arm.com,
 julien@xen.org, George Dunlap ,
 xen-devel@lists.xenproject.org
References: 
 
 
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 26.03.2024 16:27, Nicola Vetrini wrote:
> On 2024-03-25 10:27, Jan Beulich wrote:
>> On 22.03.2024 17:01, Nicola Vetrini wrote:
>>> --- a/xen/common/page_alloc.c
>>> +++ b/xen/common/page_alloc.c
>>> @@ -150,7 +150,7 @@
>>>  #include 
>>>  #else
>>>  #define p2m_pod_offline_or_broken_hit(pg) 0
>>
>> Seeing this in context: Does Misra also have a rule demanding 
>> evaluation
>> of macro arguments?
> 
> No such rule. There is one for unused function parameters, though.

Interesting. Are there no concerns regarding side effects not taking
place, as one might expect when looking just at the call site?

>>> -#define p2m_pod_offline_or_broken_replace(pg) BUG_ON(pg != NULL)
>>> +#define p2m_pod_offline_or_broken_replace(pg) BUG_ON((pg) != NULL)
>>
>> Or easier
>>
>> #define p2m_pod_offline_or_broken_replace(pg) BUG_ON(pg)
>>
>> ?
>>
> 
> Good point. I'll modify it.

I can do that as well while committing. With that adjustment
Acked-by: Jan Beulich 

Jan


From xen-devel-bounces@lists.xenproject.org Tue Mar 26 15:41:23 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Mar 2024 15:41:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698128.1089504 (Exim 4.92)
	(envelope-from )
	id 1rp8vO-0001wV-EJ; Tue, 26 Mar 2024 15:41:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698128.1089504; Tue, 26 Mar 2024 15:41:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rp8vO-0001wO-9R; Tue, 26 Mar 2024 15:41:18 +0000
Received: by outflank-mailman (input) for mailman id 698128;
 Tue, 26 Mar 2024 15:41:17 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rp8vN-0001wI-Q0
 for xen-devel@lists.xenproject.org; Tue, 26 Mar 2024 15:41:17 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on20601.outbound.protection.outlook.com
 [2a01:111:f403:2417::601])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4797ff49-eb87-11ee-afe3-a90da7624cb6;
 Tue, 26 Mar 2024 16:41:16 +0100 (CET)
Received: from SJ0PR13CA0042.namprd13.prod.outlook.com (2603:10b6:a03:2c2::17)
 by MW6PR12MB8866.namprd12.prod.outlook.com (2603:10b6:303:24c::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.33; Tue, 26 Mar
 2024 15:41:12 +0000
Received: from MWH0EPF000A6733.namprd04.prod.outlook.com
 (2603:10b6:a03:2c2:cafe::dd) by SJ0PR13CA0042.outlook.office365.com
 (2603:10b6:a03:2c2::17) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.11 via Frontend
 Transport; Tue, 26 Mar 2024 15:41:12 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 MWH0EPF000A6733.mail.protection.outlook.com (10.167.249.25) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Tue, 26 Mar 2024 15:41:11 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Tue, 26 Mar
 2024 10:41:10 -0500
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB05.amd.com
 (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Tue, 26 Mar
 2024 10:41:10 -0500
Received: from [172.17.142.167] (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Tue, 26 Mar 2024 10:41:10 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4797ff49-eb87-11ee-afe3-a90da7624cb6
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=moWLFd+BjmNxHTYpMw0pY/TjDxQ/H4V//nzShskvaD3In9qiFhkkEStq4BvtvMPMhLBxSszo1bPjRl4GSX9xCKpPCqutQPwi4A7DYoY0tp2LgtCsEv6VGRmFXga4x7wpuQdtNjP5/WBBF3UYM/hsagSKG6cpY3DESy0cUHnmQ1xo4pQXJMm1K5Eqp973dva/bCHwf9lP7T2CRIjdpqPv6KfOwnfLoFFPzirt+Y3hoj8t+lLmMqEziQ2DR8uLlBlklPtwTA1nSSVs0f6Fu5eU8/2Mmyf4sYHCWpufG4SoT1yp7k8+EekXW6OTWGDpbGbJ4vVYnK9fj2YSma9cATOH0g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=kqz6WtpC2WFvumPUlI5Rith8nY3wEMhcg4UYq9Kao2I=;
 b=dY/d/IlgeucSsiowhn77f2IWaM7P3eG3DeXXED68U6cWz6P+c+Sm2QZHAI2bHbKSC4OsuAAa3wVpwdpY/SiAw82S/4A9W6KTXBJQt2O0P7eu8IIqsrRPePyWe9IVN66XDZadvPCYZhty3PoKcKEIBJ0zzpdxiWd6XVz8Me1TZTBoSV4mSbev+nljqf+98grlfbNsJnvkDergWZWIdzpHF6r+3FClu+g+9GvFbMwws10ER0U4bmlnV+zeJkDpRMpy7VzzZFb8X7BBWdIyZAEiZaAItDFfTk8efU77QFnZ5XC3SMoZeRtjo7ELL6bNZnOAumL45k3OHEtis+bDLxGGng==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=kqz6WtpC2WFvumPUlI5Rith8nY3wEMhcg4UYq9Kao2I=;
 b=hka2hU6ER2efxb73gjQd6RHTLlm6m5mPBk8MtP1bJh9T5mE2QS+oe6C3XHnSjbKn3/FPOCWQfaI3QUqCz3gSmKZUMR7+Ff+Gnbx/1W/Ico67CHb3JLdmr7+rqN/qtD/3lOPt3jAvSUB2g0GOyYRsF0PbzUsMocfRpMzCD5MFzTI=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Message-ID: 
Date: Tue, 26 Mar 2024 11:41:12 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 5/5] x86/PVH: Support relocatable dom0 kernels
To: Jan Beulich 
CC: Andrew Cooper ,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , George Dunlap
	, Julien Grall , Stefano Stabellini
	, 
References: <20240325204515.250203-1-jason.andryuk@amd.com>
 <20240325204515.250203-6-jason.andryuk@amd.com>
 <770d3292-34cf-4e21-acb6-bd1f9caf5fef@suse.com>
 
 
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: 
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB05.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: MWH0EPF000A6733:EE_|MW6PR12MB8866:EE_
X-MS-Office365-Filtering-Correlation-Id: 6a048ec0-5915-4f13-c57b-08dc4dab2a1d
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	hK0uu9+G+T2Xj3qYun1m0kBYspqMjIEAg3eFg1nLDIOaMTznFiShGxzZwGgt7ILD1QOZo5/A2k3dP3wfXhQV3zwf7XfgsSsaQsHsGoz66WJJVVWmFVWC3TJycCIgy4t4ULF6Jnc87rP7MiZO4PBsKk5oiAPCUPfKVQJgo7Mo1D2Qe3w1IMV0afXxO1Ynl9/J6zbPgJTEXClLGkEbUb+2DqXYaQ3nVY0mQlwu666NaHlpVK16KdRxMb7+txin/OlLur1seNr8bbEFfActMD2+se+JwWkoCZ1pa5NJmvlurgCFfW94zFIJxW13NOCj5eb7D63/6RHXqoMjmIohY+BajHImcES0ZkVxJoLUBUPNQz+buv+vArH1oNXz45eefiimXzTJjCV7ZLJbjWVcS/rCZ8KyN3Kv3H6/IDSvBmwWig1bUoPJjdnYOXb5SeXDvaluwf50iKK10+7gaR21WH9ZcGxTl2zWMqjzEhTbT8HpO4MtY3gU/X6yXBOY6cYEqj14YejccG/0p4J1PnoMLsUR1LAqYBTAVOyp2rdHqRvYnjj09376Mj0wFgO5oDKEL/l0vRRCo3XJHXHfs0SeyRJOMNrHyRUejsf3MZwfvC0srMzbC3Uj3c/oEACbu9qcDGe0AnoUvdHhqLbIe1NDpTejEkaT3DHvJCPIWMzKltp2Jsrhijtzs6/n5OjXA5Yk+nxjPOHp6KFJnTdgxnxKZoltnCML9JRN3ergIOeeGno6TisYJzlu2+F8EC2he74LBqJu
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(376005)(36860700004)(82310400014)(1800799015);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Mar 2024 15:41:11.8608
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 6a048ec0-5915-4f13-c57b-08dc4dab2a1d
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	MWH0EPF000A6733.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW6PR12MB8866

On 2024-03-26 09:40, Jan Beulich wrote:
> On 26.03.2024 14:24, Jason Andryuk wrote:
>> On 2024-03-26 03:50, Jan Beulich wrote:
>>> On 25.03.2024 21:45, Jason Andryuk wrote:
>>>> @@ -227,6 +239,27 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,

>>>> +        }
>>>> +        if ( descsz >= 8 )
>>>> +        {
>>>> +            parms->phys_min = elf_note_numeric_array(elf, note, 4, 1);
>>>> +            elf_msg(elf, " min: %#"PRIx32, parms->phys_min);
>>>> +        }
>>>> +        if ( descsz >= 12 )
>>>> +        {
>>>> +            parms->phys_align = elf_note_numeric_array(elf, note, 4, 2);
>>>> +            elf_msg(elf, " align: %#"PRIx32, parms->phys_align);
>>>> +        }
>>>
>>> I'd like us to reconsider this ordering: I'm inclined to say that MAX isn't
>>> the most likely one a guest may find a need to use. Instead I'd expect both
>>> MIN and ALIGN wanting to be given higher priority; what I'm less certain
>>> about is the ordering between the two. To keep MIN and MAX adjacent, how
>>> about ALIGN, MIN, MAX?
>>
>> ALIGN, MIN, MAX works for me.
>>
>> On the Linux side, I'm expecting them all to be set:
>> ALIGN = CONFIG_PHYSICAL_ALIGN
>> MIN = LOAD_PHYSICAL_ADDR
>> MAX = KERNEL_IMAGE_SIZE
>>
>> You need enough identity page tables to cover up to MAX.
>> LOAD_PHYSICAL_ADDR is used as a minimum, so requesting placement above
>> MIN makes sense to me.
> 
> Hmm, setting MIN like this means moving down is precluded. Why would it
> not be possible to move a kernel to lower than the default of 16M, when
> CONFIG_PHYSICAL_START can be as low as 0? (In fact, I doubt 0 would work
> if chosen, but 2M surely does work, as I build some of my Dom0 kernels
> that way.)

I successfully booted at a lower address when testing, so it's possible. 
  The bzImage early boot code uses LOAD_PHYSICAL_ADDR as a minimum for 
extracting vmlinux, so I matched that.  It's not clear to me exactly why 
that is used, though it avoids using the 16MB ISA DMA region.

Kconfig RELOCATABLE has this:
Note: If CONFIG_RELOCATABLE=y, then the kernel runs from the address
it has been loaded at and the compile time physical address
(CONFIG_PHYSICAL_START) is used as the minimum location.

Which is again why I thought to use it as MIN.

> MAX, otoh, I guess really wants setting as you say, for KERNEL_IMAGE_SIZE
> actually being commented upon as mis-named. Just that it now really wants
> to be KERNEL_IMAGE_SIZE-1.

Yes.

If placement changes to favor higher addresses, then ALIGN, MAX, MIN 
becomes a little more important since that should be consulted first.

Thanks,
Jason


From xen-devel-bounces@lists.xenproject.org Tue Mar 26 15:41:31 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Mar 2024 15:41:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698129.1089513 (Exim 4.92)
	(envelope-from )
	id 1rp8vb-0002GW-Jq; Tue, 26 Mar 2024 15:41:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698129.1089513; Tue, 26 Mar 2024 15:41:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rp8vb-0002GP-HB; Tue, 26 Mar 2024 15:41:31 +0000
Received: by outflank-mailman (input) for mailman id 698129;
 Tue, 26 Mar 2024 15:41:30 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rp8va-0001wI-F2
 for xen-devel@lists.xenproject.org; Tue, 26 Mar 2024 15:41:30 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 502feedf-eb87-11ee-afe3-a90da7624cb6;
 Tue, 26 Mar 2024 16:41:29 +0100 (CET)
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 by support.bugseng.com (Postfix) with ESMTPA id 05EBA4EE0739;
 Tue, 26 Mar 2024 16:41:29 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 502feedf-eb87-11ee-afe3-a90da7624cb6
MIME-Version: 1.0
Date: Tue, 26 Mar 2024 16:41:28 +0100
From: Nicola Vetrini 
To: Jan Beulich 
Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com,
 ayan.kumar.halder@amd.com, consulting@bugseng.com,
 andrew.cooper3@citrix.com, roger.pau@citrix.com, bertrand.marquis@arm.com,
 julien@xen.org, xen-devel@lists.xenproject.org
Subject: Re: [XEN PATCH 09/11] x86/msi: address violation of MISRA C Rule 20.7
 and coding style
In-Reply-To: <465034fd-d2bc-4fe1-8c04-bdb1d60bfafc@suse.com>
References: 
 
 
 
 <465034fd-d2bc-4fe1-8c04-bdb1d60bfafc@suse.com>
Message-ID: 
X-Sender: nicola.vetrini@bugseng.com
Organization: BUGSENG s.r.l.
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit

On 2024-03-26 16:13, Jan Beulich wrote:
> On 26.03.2024 15:30, Nicola Vetrini wrote:
>> On 2024-03-26 11:05, Jan Beulich wrote:
>>> On 22.03.2024 17:01, Nicola Vetrini wrote:
>>>> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
>>>> of macro parameters shall be enclosed in parentheses". Therefore, 
>>>> some
>>>> macro definitions should gain additional parentheses to ensure that
>>>> all
>>>> current and future users will be safe with respect to expansions 
>>>> that
>>>> can possibly alter the semantics of the passed-in macro parameter.
>>>> 
>>>> While at it, the style of these macros has been somewhat uniformed.
>>> 
>>> Hmm, yes, but they then still leave more to be desired. I guess I can
>>> see
>>> though why you don't want to e.g. ...
>>> 
>>>> --- a/xen/arch/x86/include/asm/msi.h
>>>> +++ b/xen/arch/x86/include/asm/msi.h
>>>> @@ -147,33 +147,34 @@ int msi_free_irq(struct msi_desc *entry);
>>>>   */
>>>>  #define NR_HP_RESERVED_VECTORS 	20
>>>> 
>>>> -#define msi_control_reg(base)		(base + PCI_MSI_FLAGS)
>>>> -#define msi_lower_address_reg(base)	(base + PCI_MSI_ADDRESS_LO)
>>>> -#define msi_upper_address_reg(base)	(base + PCI_MSI_ADDRESS_HI)
>>>> -#define msi_data_reg(base, is64bit)	\
>>>> -	( (is64bit == 1) ? base+PCI_MSI_DATA_64 : base+PCI_MSI_DATA_32 )
>>>> -#define msi_mask_bits_reg(base, is64bit) \
>>>> -	( (is64bit == 1) ? base+PCI_MSI_MASK_BIT : 
>>>> base+PCI_MSI_MASK_BIT-4)
>>>> +#define msi_control_reg(base)        ((base) + PCI_MSI_FLAGS)
>>>> +#define msi_lower_address_reg(base)  ((base) + PCI_MSI_ADDRESS_LO)
>>>> +#define msi_upper_address_reg(base)  ((base) + PCI_MSI_ADDRESS_HI)
>>>> +#define msi_data_reg(base, is64bit) \
>>>> +    (((is64bit) == 1) ? (base) + PCI_MSI_DATA_64 : (base) +
>>>> PCI_MSI_DATA_32)
>>>> +#define msi_mask_bits_reg(base, is64bit)                \
>>>> +    (((is64bit) == 1) ? (base) + PCI_MSI_MASK_BIT       \
>>>> +                      : (base) + PCI_MSI_MASK_BIT - 4)
>>> 
>>> ... drop the bogus == 1 in these two, making them similar to ...
>>> 
>>>>  #define msi_pending_bits_reg(base, is64bit) \
>>>> -	((base) + PCI_MSI_MASK_BIT + ((is64bit) ? 4 : 0))
>>>> -#define msi_disable(control)		control &= ~PCI_MSI_FLAGS_ENABLE
>>>> +    ((base) + PCI_MSI_MASK_BIT + ((is64bit) ? 4 : 0))
>>> 
>>> ... this.
>>> 
>>>> +#define msi_disable(control) (control) &= ~PCI_MSI_FLAGS_ENABLE
>>> 
>>> Doesn't this need an outer pair of parentheses, too?
>>> 
>> 
>> Not necessarily.
> 
> And use of msi_disable() in another expression would then likely not do
> what's expected?
> 

Actually I just noticed that some of these macros are never used 
(msi_disable being one of them), as far as I can tell.

>> I'm in favour of a consistent style to be converted in.
>> This also applies below.
> 
> I'm all for consistency; I just don't know what you want to be 
> consistent
> with, here.
> 

I would propose adding parentheses around assignments to control, so 
that all macros are consistently parenthesized.

>>>>  #define multi_msi_capable(control) \
>>>> -	(1 << ((control & PCI_MSI_FLAGS_QMASK) >> 1))
>>>> +    (1 << (((control) & PCI_MSI_FLAGS_QMASK) >> 1))
>>>>  #define multi_msi_enable(control, num) \
>>>> -	control |= (((fls(num) - 1) << 4) & PCI_MSI_FLAGS_QSIZE);
>>>> -#define is_64bit_address(control)	(!!(control & 
>>>> PCI_MSI_FLAGS_64BIT))
>>>> -#define is_mask_bit_support(control)	(!!(control &
>>>> PCI_MSI_FLAGS_MASKBIT))
>>>> +    (control) |= (((fls(num) - 1) << 4) & PCI_MSI_FLAGS_QSIZE);
>>> 
>>> And this, together with dropping the bogus semicolon?
>>> 
>> 
>> I'll drop the semicolon.
>> 
>>> There also look to be cases where MASK_EXTR() / MASK_INSR() would 
>>> want
>>> using,
>>> in favor of using open-coded numbers.
>> 
>> Yes, perhaps. However, the risk that I make some mistakes in doing so
>> are quite high, though.
> 
> Right, hence how I started my earlier reply. Question is - do we want 
> to
> go just half the way here, or would we better tidy things all in one 
> go?
> In the latter case I could see about getting to that (whether to take
> your patch as basis or instead do it from scratch isn't quite clear to
> me at this point).
> 
> Jan

How about I revise this patch with parentheses added where needed, as 
suggested earlier, and then you can submit a further cleanup patch to 
remove e.g. the open coding?

-- 
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)


From xen-devel-bounces@lists.xenproject.org Tue Mar 26 15:57:40 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Mar 2024 15:57:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698135.1089523 (Exim 4.92)
	(envelope-from )
	id 1rp9B7-0004VU-O7; Tue, 26 Mar 2024 15:57:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698135.1089523; Tue, 26 Mar 2024 15:57:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rp9B7-0004VN-LN; Tue, 26 Mar 2024 15:57:33 +0000
Received: by outflank-mailman (input) for mailman id 698135;
 Tue, 26 Mar 2024 15:57:32 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rp9B6-0004VG-Th
 for xen-devel@lists.xenproject.org; Tue, 26 Mar 2024 15:57:32 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8cda9ac1-eb89-11ee-a1ef-f123f15fe8a2;
 Tue, 26 Mar 2024 16:57:30 +0100 (CET)
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 by support.bugseng.com (Postfix) with ESMTPA id BD9DF4EE0739;
 Tue, 26 Mar 2024 16:57:29 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8cda9ac1-eb89-11ee-a1ef-f123f15fe8a2
MIME-Version: 1.0
Date: Tue, 26 Mar 2024 16:57:29 +0100
From: Nicola Vetrini 
To: Jan Beulich 
Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com,
 ayan.kumar.halder@amd.com, consulting@bugseng.com,
 andrew.cooper3@citrix.com, roger.pau@citrix.com, bertrand.marquis@arm.com,
 julien@xen.org, George Dunlap ,
 xen-devel@lists.xenproject.org
Subject: Re: [XEN PATCH 07/11] xen/page_alloc: address violations of MISRA C
 Rule 20.7
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 
X-Sender: nicola.vetrini@bugseng.com
Organization: BUGSENG s.r.l.
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit

On 2024-03-26 16:35, Jan Beulich wrote:
> On 26.03.2024 16:27, Nicola Vetrini wrote:
>> On 2024-03-25 10:27, Jan Beulich wrote:
>>> On 22.03.2024 17:01, Nicola Vetrini wrote:
>>>> --- a/xen/common/page_alloc.c
>>>> +++ b/xen/common/page_alloc.c
>>>> @@ -150,7 +150,7 @@
>>>>  #include 
>>>>  #else
>>>>  #define p2m_pod_offline_or_broken_hit(pg) 0
>>> 
>>> Seeing this in context: Does Misra also have a rule demanding
>>> evaluation
>>> of macro arguments?
>> 
>> No such rule. There is one for unused function parameters, though.
> 
> Interesting. Are there no concerns regarding side effects not taking
> place, as one might expect when looking just at the call site?
> 

I don't know. Either it was never discussed or it never made it to the 
final revisions, I guess.

>>>> -#define p2m_pod_offline_or_broken_replace(pg) BUG_ON(pg != NULL)
>>>> +#define p2m_pod_offline_or_broken_replace(pg) BUG_ON((pg) != NULL)
>>> 
>>> Or easier
>>> 
>>> #define p2m_pod_offline_or_broken_replace(pg) BUG_ON(pg)
>>> 
>>> ?
>>> 
>> 
>> Good point. I'll modify it.
> 
> I can do that as well while committing. With that adjustment
> Acked-by: Jan Beulich 
> 
> Jan

Thanks

-- 
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)


From xen-devel-bounces@lists.xenproject.org Tue Mar 26 15:58:07 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Mar 2024 15:58:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698136.1089532 (Exim 4.92)
	(envelope-from )
	id 1rp9Bf-0004wB-06; Tue, 26 Mar 2024 15:58:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698136.1089532; Tue, 26 Mar 2024 15:58:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rp9Be-0004w4-Tr; Tue, 26 Mar 2024 15:58:06 +0000
Received: by outflank-mailman (input) for mailman id 698136;
 Tue, 26 Mar 2024 15:58:05 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rp9Bd-0004vs-Oc
 for xen-devel@lists.xenproject.org; Tue, 26 Mar 2024 15:58:05 +0000
Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com
 [2607:f8b0:4864:20::732])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a0b8e92b-eb89-11ee-afe3-a90da7624cb6;
 Tue, 26 Mar 2024 16:58:04 +0100 (CET)
Received: by mail-qk1-x732.google.com with SMTP id
 af79cd13be357-789e6e1d96eso382541585a.3
 for ; Tue, 26 Mar 2024 08:58:04 -0700 (PDT)
Received: from EMEAENGAAD91498 ([160.101.131.1])
 by smtp.gmail.com with ESMTPSA id
 w15-20020a05620a148f00b00789f3e53d04sm3121726qkj.126.2024.03.26.08.58.01
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 26 Mar 2024 08:58:02 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a0b8e92b-eb89-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1711468683; x=1712073483; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=c2G8XtjFfIX8eX+c1Z74JQK5HAFUvy9DvIqvRyQc860=;
        b=QD6F/pv6Hxv+oR7ZD+CH7YcUOiXKZqOHQTohWePtjyK59CRMt5JWc0OnZYmK6Sm8lY
         hZjNfALBwsM8kuPfGztz1YSqCVTVe8kLY7P3qLqmtg9SoBb53tN2Nbh62cQTNO87oVPn
         70+eY0t5WCspZzjzPcVJjxjHNrEQ6TD7hmqhs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711468683; x=1712073483;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=c2G8XtjFfIX8eX+c1Z74JQK5HAFUvy9DvIqvRyQc860=;
        b=eYNhmGdPaPBZdTURNVKhDNEOyU/oDjmnLM+bk3GQQST63BxDDuW312NZvNRbKoY//s
         2996DhZtjKlLrDxyBD3k6hPTfBzrUInQCTpTubXbRWC9R2DrOobhAYO9qn0HPYruKPQs
         THdcgLQK1U/uXCnri/2xNvST7E1MLgVreeVTY2tmwDqPJXN87ypv7FagiwAIk01KOhGr
         fqI0jWkIgpM2mH8htUaMT4n3a9S7xX20Kiuk8YpvueDdi+z0UCjc7lHfcUYU2etX2YtI
         CiIBcNlyIUpDnYImp9XU4z0N1d5+PR+jrOZiVLtlholHFYqIwQ19IZ9NbfrC5b4FzDhR
         ObgQ==
X-Forwarded-Encrypted: i=1; AJvYcCVQFia2SHZNRCljWBH0MDoYYSeykrNV4Z7Gps6HN3FQ854lMelspYkB8waYdX5w4eAdq6snAqE9c+4Ho97MU1D1JKalm+sPEZlFlvJQkCU=
X-Gm-Message-State: AOJu0Ywb/kDAPBVlR2MEggnb6/CHn/yImLMic3DsKvl8OP+doBlUx1pb
	jfFFqYrJtErUhB4oqstnB3GTki0eLZeIBUJ1pCyIreLltQCaaRfwnYtXpljzc7g=
X-Google-Smtp-Source: AGHT+IHJAAPCveKBgT2q54F3lc4fTPnZqsyYgMJdH26Rn2nlSSRbe7LGK8XkdxD4eqXrhr5y6Hcsvw==
X-Received: by 2002:a05:620a:4154:b0:78a:30d2:c3d2 with SMTP id k20-20020a05620a415400b0078a30d2c3d2mr199407qko.4.1711468682953;
        Tue, 26 Mar 2024 08:58:02 -0700 (PDT)
Date: Tue, 26 Mar 2024 15:57:58 +0000
From: Matthew Barnes 
To: Jan Beulich 
Cc: Wei Liu , Anthony PERARD , 
	Xen-devel 
Subject: Re: [XEN PATCH] tools: add x2APIC entries in MADT based on APIC ID
Message-ID: 
References: 
 <32a4de1e-94fe-4b44-b95c-55cd1ec7e7e4@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <32a4de1e-94fe-4b44-b95c-55cd1ec7e7e4@suse.com>

> > This patch scans each APIC ID before constructing the MADT, and uses the
> > x2APIC entry for each vCPU whose APIC ID exceeds the size limit imposed
> > by regular APIC entries.
> 
> It is my understanding that if you use any x2APIC entry, every CPU needs
> to have one.

In the ACPI 6.4 specification, section 5.2.12.12, the note says the following:

[Compatibility note] On some legacy OSes, Logical processors with APIC ID
values less than 255 (whether in XAPIC or X2APIC mode) must use the Processor
Local APIC structure to convey their APIC information to OSPM, and those
processors must be declared in the DSDT using the Processor() keyword.

Therefore, even in X2APIC mode, it's better to represent processors with APIC
ID values less than 255 with APIC entries for legacy reasons.

> > @@ -134,27 +151,45 @@ static struct acpi_20_madt *construct_madt(struct acpi_ctxt *ctxt,
> >          io_apic->ioapic_id   = config->ioapic_id;
> >          io_apic->ioapic_addr = config->ioapic_base_address;
> >  
> > -        lapic = (struct acpi_20_madt_lapic *)(io_apic + 1);
> > +        apicid_entry = io_apic + 1;
> >      }
> >      else
> > -        lapic = (struct acpi_20_madt_lapic *)(madt + 1);
> > +        apicid_entry = madt + 1;
> >  
> >      info->nr_cpus = hvminfo->nr_vcpus;
> > -    info->madt_lapic0_addr = ctxt->mem_ops.v2p(ctxt, lapic);
> > +    info->madt_lapic0_addr = ctxt->mem_ops.v2p(ctxt, apicid_entry);
> >      for ( i = 0; i < hvminfo->nr_vcpus; i++ )
> >      {
> > -        memset(lapic, 0, sizeof(*lapic));
> > -        lapic->type    = ACPI_PROCESSOR_LOCAL_APIC;
> > -        lapic->length  = sizeof(*lapic);
> > -        /* Processor ID must match processor-object IDs in the DSDT. */
> > -        lapic->acpi_processor_id = i;
> > -        lapic->apic_id = config->lapic_id(i);
> > -        lapic->flags = (test_bit(i, hvminfo->vcpu_online)
> > -                        ? ACPI_LOCAL_APIC_ENABLED : 0);
> > -        lapic++;
> > +        uint32_t apic_id = config->lapic_id(i);
> > +        if ( apic_id < 255 )
> 
> Nit (here and below): This file uses hypervisor coding style. and hence a
> blank line is wanted between declaration(s) and statement(s).

I will add this in patch V2

> > +        {
> > +            struct acpi_20_madt_lapic *lapic = apicid_entry;
> > +            memset(lapic, 0, sizeof(*lapic));
> > +            lapic->type    = ACPI_PROCESSOR_LOCAL_APIC;
> > +            lapic->length  = sizeof(*lapic);
> > +            /* Processor ID must match processor-object IDs in the DSDT. */
> > +            lapic->acpi_processor_id = i;
> > +            lapic->apic_id = apic_id;
> > +            lapic->flags = (test_bit(i, hvminfo->vcpu_online)
> > +                            ? ACPI_LOCAL_APIC_ENABLED : 0);
> > +            apicid_entry = lapic + 1;
> > +        }
> > +        else
> > +        {
> > +            struct acpi_20_madt_x2apic *x2apic = apicid_entry;
> > +            memset(x2apic, 0, sizeof(*x2apic));
> > +            x2apic->type    = ACPI_PROCESSOR_LOCAL_X2APIC;
> > +            x2apic->length  = sizeof(*x2apic);
> > +            x2apic->apic_id = apic_id;
> > +            x2apic->flags   = (test_bit(i, hvminfo->vcpu_online)
> > +                                ? ACPI_LOCAL_APIC_ENABLED : 0);
> 
> Nit: Indentation off by 1.

I will add this in patch V2

Matt


From xen-devel-bounces@lists.xenproject.org Tue Mar 26 16:06:30 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Mar 2024 16:06:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698141.1089542 (Exim 4.92)
	(envelope-from )
	id 1rp9Ji-0007Mg-QG; Tue, 26 Mar 2024 16:06:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698141.1089542; Tue, 26 Mar 2024 16:06:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rp9Ji-0007MZ-Nh; Tue, 26 Mar 2024 16:06:26 +0000
Received: by outflank-mailman (input) for mailman id 698141;
 Tue, 26 Mar 2024 16:06:25 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rp9Jh-0007MT-53
 for xen-devel@lists.xenproject.org; Tue, 26 Mar 2024 16:06:25 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id cb153ec7-eb8a-11ee-afe3-a90da7624cb6;
 Tue, 26 Mar 2024 17:06:24 +0100 (CET)
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 by support.bugseng.com (Postfix) with ESMTPA id B8EAA4EE0739;
 Tue, 26 Mar 2024 17:06:23 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: cb153ec7-eb8a-11ee-afe3-a90da7624cb6
MIME-Version: 1.0
Date: Tue, 26 Mar 2024 17:06:23 +0100
From: Nicola Vetrini 
To: Jan Beulich 
Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com,
 ayan.kumar.halder@amd.com, consulting@bugseng.com,
 andrew.cooper3@citrix.com, roger.pau@citrix.com, bertrand.marquis@arm.com,
 julien@xen.org, xen-devel@lists.xenproject.org
Subject: Re: [XEN PATCH 09/11] x86/msi: address violation of MISRA C Rule 20.7
 and coding style
In-Reply-To: 
References: 
 
 
 
 <465034fd-d2bc-4fe1-8c04-bdb1d60bfafc@suse.com>
 
Message-ID: <70cc48ca512aec508c87eebe2bea2ebb@bugseng.com>
X-Sender: nicola.vetrini@bugseng.com
Organization: BUGSENG s.r.l.
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit


>>>>> +#define msi_disable(control) (control) &= ~PCI_MSI_FLAGS_ENABLE
>>>> 
>>>> Doesn't this need an outer pair of parentheses, too?
>>>> 
>>> 
>>> Not necessarily.
>> 
>> And use of msi_disable() in another expression would then likely not 
>> do
>> what's expected?
>> 
> 
> Actually I just noticed that some of these macros are never used 
> (msi_disable being one of them), as far as I can tell.
> 

I see why. The bodies of the macros are open-coded in multiple places in 
msi.c. I can't really tell whether that's intentional or not, but this 
is an opportunity to do a more general cleanup I guess, beyond the scope 
of this patch.

>>> I'm in favour of a consistent style to be converted in.
>>> This also applies below.
>> 
>> I'm all for consistency; I just don't know what you want to be 
>> consistent
>> with, here.
>> 
> 
> I would propose adding parentheses around assignments to control, so 
> that all macros are consistently parenthesized.
> 
>>>>>  #define multi_msi_capable(control) \
>>>>> -	(1 << ((control & PCI_MSI_FLAGS_QMASK) >> 1))
>>>>> +    (1 << (((control) & PCI_MSI_FLAGS_QMASK) >> 1))
>>>>>  #define multi_msi_enable(control, num) \
>>>>> -	control |= (((fls(num) - 1) << 4) & PCI_MSI_FLAGS_QSIZE);
>>>>> -#define is_64bit_address(control)	(!!(control & 
>>>>> PCI_MSI_FLAGS_64BIT))
>>>>> -#define is_mask_bit_support(control)	(!!(control &
>>>>> PCI_MSI_FLAGS_MASKBIT))
>>>>> +    (control) |= (((fls(num) - 1) << 4) & PCI_MSI_FLAGS_QSIZE);
>>>> 
>>>> And this, together with dropping the bogus semicolon?
>>>> 
>>> 
>>> I'll drop the semicolon.
>>> 
>>>> There also look to be cases where MASK_EXTR() / MASK_INSR() would 
>>>> want
>>>> using,
>>>> in favor of using open-coded numbers.
>>> 
>>> Yes, perhaps. However, the risk that I make some mistakes in doing so
>>> are quite high, though.
>> 
>> Right, hence how I started my earlier reply. Question is - do we want 
>> to
>> go just half the way here, or would we better tidy things all in one 
>> go?
>> In the latter case I could see about getting to that (whether to take
>> your patch as basis or instead do it from scratch isn't quite clear to
>> me at this point).
>> 
>> Jan
> 
> How about I revise this patch with parentheses added where needed, as 
> suggested earlier, and then you can submit a further cleanup patch to 
> remove e.g. the open coding?

-- 
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)


From xen-devel-bounces@lists.xenproject.org Tue Mar 26 16:15:57 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Mar 2024 16:15:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698153.1089552 (Exim 4.92)
	(envelope-from )
	id 1rp9Sp-0000il-Qi; Tue, 26 Mar 2024 16:15:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698153.1089552; Tue, 26 Mar 2024 16:15:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rp9Sp-0000ie-Ny; Tue, 26 Mar 2024 16:15:51 +0000
Received: by outflank-mailman (input) for mailman id 698153;
 Tue, 26 Mar 2024 16:15:50 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rp9So-0000iY-OQ
 for xen-devel@lists.xenproject.org; Tue, 26 Mar 2024 16:15:50 +0000
Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com
 [2a00:1450:4864:20::636])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1b8954c5-eb8c-11ee-a1ef-f123f15fe8a2;
 Tue, 26 Mar 2024 17:15:48 +0100 (CET)
Received: by mail-ej1-x636.google.com with SMTP id
 a640c23a62f3a-a470d7f77eeso727477166b.3
 for ; Tue, 26 Mar 2024 09:15:48 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 jz7-20020a17090775e700b00a4576dd5a8csm4337546ejc.201.2024.03.26.09.15.47
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 26 Mar 2024 09:15:47 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1b8954c5-eb8c-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711469748; x=1712074548; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=E+ZyQGRkIt39N2dsC/B303eMYpZ1hVmIdk9h9dCVJ6Y=;
        b=NQv9EjJb9rkGUHWKcpPiwTsm00oUqC1/LMa8BTxZ35XbTqFIKjYmu2rVp3VnbiobGT
         rnllEI9uqC4Xg+hQsr4disTIMItMyhr39RKK4hAyVAY9jtP+WtysiH+KBFzuZ1etIgzE
         YmjaF7yofdpae/5cfIQvf+RNei2K901Rh2Wxf1cd6k7jeB7MCHhp0CEiH6o4NNEVb3aD
         MmCZJtKyaTvofWEfcxDkRAL0VjvSWgmzn3CrPKFB+1IuGGQqK0OdS6IkN0GLEwW7bhLW
         611jokYdS1guhpbtz9xZ+xJ1wD/JEWw1Y5XKj0lbJiIY5BOa9fqfngZSphHjC+oXDRVy
         f6pg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711469748; x=1712074548;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=E+ZyQGRkIt39N2dsC/B303eMYpZ1hVmIdk9h9dCVJ6Y=;
        b=koxDoYztFESR7xWasUP56U7TpO9SDHr71QBP4Qpqr3G0YvcqSVzd2/ermE75P73Uqz
         JV6sPz61TeIxgdwK4CwIIKMX+LcngAgxkScCTnuLvg3cFOfTnt315F4EkYBCYDAJbwYY
         kNJGYYCK5DvwPDehp4DGRF0Csx9tDCh96+cNfZIjcZc1l7Pdz7MY0SmyMBXNxC8Ndvka
         SsqalycdThmdgtGffdBR8H6vakwSptqdXRlFYerY0lN8XB0lSIaBCJfWagUtSf2mC8aO
         VA1nRWqwKhm3hh+8gt1G9rJUqxur8V29TXtHl4Hoj4Z+vETh6dGNd7zcQMth2rcHyoxS
         p+uQ==
X-Forwarded-Encrypted: i=1; AJvYcCWhOCOIwayj7rvcfmr7VTyXDucAoYQ8W/zl51FAnqscC3lJzIlNhkj6sy4ZuQIlIPynfg+W5lsltIW8A+fhhG7FXgh3aPJyCAHjX6Sl8oI=
X-Gm-Message-State: AOJu0Yw6CRLcxwJ7FdA8MKYPCHGBhP1FSatRjJQNDBSoWVh8U5x5Uh0E
	SseipMlnJ1J7fKZ5NVibImdWJPA62hWyW9OZG3KRs3I9AvaFQzZUSYG53Zl4/A==
X-Google-Smtp-Source: AGHT+IEaml6U7roUYh/oEp7Irl+QQ4sKfzv34MuilTLID+uZ0ypTt6JsLqxl13pa3KYGOsrohsZOmA==
X-Received: by 2002:a17:906:4541:b0:a46:cf63:d96b with SMTP id s1-20020a170906454100b00a46cf63d96bmr7855037ejq.51.1711469748144;
        Tue, 26 Mar 2024 09:15:48 -0700 (PDT)
Message-ID: 
Date: Tue, 26 Mar 2024 17:15:46 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH] tools: add x2APIC entries in MADT based on APIC ID
Content-Language: en-US
To: Matthew Barnes 
Cc: Wei Liu , Anthony PERARD ,
 Xen-devel 
References: 
 <32a4de1e-94fe-4b44-b95c-55cd1ec7e7e4@suse.com>
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 26.03.2024 16:57, Matthew Barnes wrote:
>>> This patch scans each APIC ID before constructing the MADT, and uses the
>>> x2APIC entry for each vCPU whose APIC ID exceeds the size limit imposed
>>> by regular APIC entries.
>>
>> It is my understanding that if you use any x2APIC entry, every CPU needs
>> to have one.
> 
> In the ACPI 6.4 specification, section 5.2.12.12, the note says the following:
> 
> [Compatibility note] On some legacy OSes, Logical processors with APIC ID
> values less than 255 (whether in XAPIC or X2APIC mode) must use the Processor
> Local APIC structure to convey their APIC information to OSPM, and those
> processors must be declared in the DSDT using the Processor() keyword.
> 
> Therefore, even in X2APIC mode, it's better to represent processors with APIC
> ID values less than 255 with APIC entries for legacy reasons.

Well, my reading of that is different: All CPUs need to have x2APIC entries
if one has, and CPUs with small enough APIC IDs _additionally_ need xAPIC
entries. That's what I've been observing on real hardware, too.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Mar 26 16:38:46 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Mar 2024 16:38:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698164.1089562 (Exim 4.92)
	(envelope-from )
	id 1rp9on-000476-KY; Tue, 26 Mar 2024 16:38:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698164.1089562; Tue, 26 Mar 2024 16:38:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rp9on-00046z-I0; Tue, 26 Mar 2024 16:38:33 +0000
Received: by outflank-mailman (input) for mailman id 698164;
 Tue, 26 Mar 2024 16:38:32 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rp9om-00046t-81
 for xen-devel@lists.xenproject.org; Tue, 26 Mar 2024 16:38:32 +0000
Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com
 [2607:f8b0:4864:20::234])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 46ce3e7d-eb8f-11ee-a1ef-f123f15fe8a2;
 Tue, 26 Mar 2024 17:38:30 +0100 (CET)
Received: by mail-oi1-x234.google.com with SMTP id
 5614622812f47-3c397193878so3250722b6e.3
 for ; Tue, 26 Mar 2024 09:38:30 -0700 (PDT)
Received: from EMEAENGAAD91498 ([160.101.131.1])
 by smtp.gmail.com with ESMTPSA id
 bw20-20020a05622a099400b00430eb19dd06sm3822212qtb.91.2024.03.26.09.38.27
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 26 Mar 2024 09:38:28 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 46ce3e7d-eb8f-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1711471109; x=1712075909; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=83gN2jSnR0VX0vRMrDP8Yj5OsE6zl4FjNqjh1MpSu8o=;
        b=P5WGeGN1YQynXEXK8eNyQJnxIuaXioVbOaNZPrnRPebt7iLKY1JQBKmidjbMD7T6bt
         uEB0iQuSMw+RrJ/9AVQGlK9vm4M5wJTLHCsF4f3YOVT0EgNxkMOILEvxkj0g8pzBm1VR
         59vDI7VIJmGGq8MMO10ujB+eWcsptqkNxgUZ8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711471109; x=1712075909;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=83gN2jSnR0VX0vRMrDP8Yj5OsE6zl4FjNqjh1MpSu8o=;
        b=HsvcHJRXYiSiB40gVtTf5vkhbsE5wCK2gvUdu7SRbRNhdDNcJ9mftiKF6KEPL393OK
         bpA1RMQ9cer69AT495xsRNCGA+vkvWFki7CmmHX2lp6p0qbnV6oSesmIVnBrhnTtqIDg
         49/kSFvNqdoySayokL37XP24Nlrg2x6GNhOHMTshcNtsE3afyjbpiApvWdjfhP6Qq+f3
         ODv1dAmzCWgtIvHaa4R3qh57e9NW34h4ud60kuP9tVzvr3eBkz7aboVW4yKZRwsmNSFV
         VLvcNzKlMcVfPxgIQbMYRdZ0nSNrrhUq/sVK5ykVzyug0T8egU51IlcpVLBRISeQ9u0E
         5Qhg==
X-Forwarded-Encrypted: i=1; AJvYcCXPjh3pjJBJPQAIr8nU3D/p9DbMslqHtULySdGjWeSKjkhIu6MuiJrRvB5kdymooYShoqhX1lPFHNZQGB/Uz/DQ3gqr41LjAQ/3789Xos4=
X-Gm-Message-State: AOJu0YyDzUeMRAXEhy32i8aNaA8mU5+2f/8Ltw+taNZ+2GDEcDxazvar
	giUmGNGAKDqttGOW+vAwOfH96++ToBo6JfDjVF30ieoNrG47+44JT79IAxKKsxc=
X-Google-Smtp-Source: AGHT+IHNosMFb1qIa4yv23Ea3+nvFYF2E7KCTFI0XlQsAc3g06CvQnL+xtajX0HF0LWFnLIjEdH1pw==
X-Received: by 2002:a05:6808:3194:b0:3c3:cd50:2914 with SMTP id cd20-20020a056808319400b003c3cd502914mr8616654oib.55.1711471108936;
        Tue, 26 Mar 2024 09:38:28 -0700 (PDT)
Date: Tue, 26 Mar 2024 16:38:23 +0000
From: Matthew Barnes 
To: Jan Beulich 
Cc: Matthew Barnes , Wei Liu , 
	Anthony PERARD , Xen-devel 
Subject: Re: [XEN PATCH] tools: add x2APIC entries in MADT based on APIC ID
Message-ID: 
References: 
 <32a4de1e-94fe-4b44-b95c-55cd1ec7e7e4@suse.com>
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 

On Tue, Mar 26, 2024 at 05:15:46PM +0100, Jan Beulich wrote:
> On 26.03.2024 16:57, Matthew Barnes wrote:
> >>> This patch scans each APIC ID before constructing the MADT, and uses the
> >>> x2APIC entry for each vCPU whose APIC ID exceeds the size limit imposed
> >>> by regular APIC entries.
> >>
> >> It is my understanding that if you use any x2APIC entry, every CPU needs
> >> to have one.
> > 
> > In the ACPI 6.4 specification, section 5.2.12.12, the note says the following:
> > 
> > [Compatibility note] On some legacy OSes, Logical processors with APIC ID
> > values less than 255 (whether in XAPIC or X2APIC mode) must use the Processor
> > Local APIC structure to convey their APIC information to OSPM, and those
> > processors must be declared in the DSDT using the Processor() keyword.
> > 
> > Therefore, even in X2APIC mode, it's better to represent processors with APIC
> > ID values less than 255 with APIC entries for legacy reasons.
> 
> Well, my reading of that is different: All CPUs need to have x2APIC entries
> if one has, and CPUs with small enough APIC IDs _additionally_ need xAPIC
> entries. That's what I've been observing on real hardware, too.

Understood. Patch v2 will reflect this

Matt


From xen-devel-bounces@lists.xenproject.org Tue Mar 26 16:40:07 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Mar 2024 16:40:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698166.1089573 (Exim 4.92)
	(envelope-from )
	id 1rp9qH-0005M8-VO; Tue, 26 Mar 2024 16:40:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698166.1089573; Tue, 26 Mar 2024 16:40:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rp9qH-0005Lb-Ra; Tue, 26 Mar 2024 16:40:05 +0000
Received: by outflank-mailman (input) for mailman id 698166;
 Tue, 26 Mar 2024 16:40:04 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rp9qG-00052j-9C
 for xen-devel@lists.xenproject.org; Tue, 26 Mar 2024 16:40:04 +0000
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com
 [2a00:1450:4864:20::62c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7db71ffd-eb8f-11ee-a1ef-f123f15fe8a2;
 Tue, 26 Mar 2024 17:40:01 +0100 (CET)
Received: by mail-ej1-x62c.google.com with SMTP id
 a640c23a62f3a-a46f0da1b4fso736151266b.2
 for ; Tue, 26 Mar 2024 09:40:01 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7db71ffd-eb8f-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1711471201; x=1712076001; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=A4kscqhA4wQKYFZQg5F9AixatVOaZ6VNf6lMqab+PpE=;
        b=XGQAu8UNUgIxuKJUJ15+PdZmNMh3e96qD7yMuVNnfxs2lydSHwKjgUs57zhX3FEeUB
         RA6WpuN8vMPzgbR0YW+8Dy4eqQMHsh4hTCbw/gM6cf6f2y4i3eD/+kBVp71eSi0wU9KY
         DHUT4wHGWENhcaG4PHyyKi4YvHxntTZqAheauJXvQzf53Y4PzIg4C1xhTK7ORd/rMQ05
         py+QvL0eLuKKN7bL0EPqZ1A/ZXLAZC9aCLdfgKFetoc7PeRlBIeIzfjvB5kcuLtRrYhy
         vZUrBu+qOHKrEZsvtE+ozg4n6oLnHMc0pv8cdODVvGPSfPP/PSo9yoxydk6lq+neAOSC
         TEaw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711471201; x=1712076001;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=A4kscqhA4wQKYFZQg5F9AixatVOaZ6VNf6lMqab+PpE=;
        b=IfkUM2ZDQzchJfxjSVNywsWFeVfCE1K3a+jtGAPNNsrHH9AEjYvSt/JtguQZnEjjLy
         hNpUQpNsnib59g1LbCXgTkz1KGjRDj9F3OFny2ZjnY8u87ZKFa43Lz99UfEpeDGaYvC9
         l674B5WpCXhCEL/xQG8dXfG9J94BL5iFWAtgsDnlpTVL1trwCM2CdSXEOhK/LAskvOH1
         3n7xoMwwV87R/B+2j2aw4k0jx9HBq9HqPQm7bwI4oUx8Jhvgp2y1QShTfLCfPsYcEscn
         5a3hNoIGvsJ1/1dCs/3NNEQ6u8frL7PhX0VUVhqA69RKVirGfQvu3Cfrjhxk+uGmmouL
         A2Eg==
X-Forwarded-Encrypted: i=1; AJvYcCXFhcf2f4X5OkAYVsvI0htUuMmi0dTZmz9dPqVPeS8igi1nIz38fSoiA7b8MB0NRMeOEWjurKSlhRGOLmeOfWgvF9z6vY4jdN1XIbVGNhs=
X-Gm-Message-State: AOJu0YyhlMIkAjT2ky9niMUpIqtz5/lnzbRonR6uOcziBtkwJBL73Kyy
	kgPeo6Hh6pBrHQxxiSgKHhWrgsYn1e9lt+0WCLxs6p7z6duxj4ZBNex/da/id6hZ9EYVM3Fn7Mn
	YJ3lF23VY+qVG5Fqohr/Iu/JD64ajHSowq65kFw==
X-Google-Smtp-Source: AGHT+IE+i4dau6E3P4Z73Nw5NUKQuQvu5GIL5e48qmm1rp4J038UU7kPvXwfAxXnIwH18UcIB8ch5fYRuT/Axvybk5k=
X-Received: by 2002:a17:906:1d59:b0:a46:be3d:1ed8 with SMTP id
 o25-20020a1709061d5900b00a46be3d1ed8mr160337ejh.54.1711471201307; Tue, 26 Mar
 2024 09:40:01 -0700 (PDT)
MIME-Version: 1.0
References: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
 <20240315105902.160047-9-carlo.nonato@minervasys.tech> <3f615066-a792-493f-ba33-7667a6557c23@xen.org>
 <9e0f7ff3-5457-41e4-a1e4-bf75804fb900@xen.org> <255be735-f9fe-4e39-a24e-2f6aff91acc5@suse.com>
  <3427132d-9458-4447-b667-d2ef3c1f0569@suse.com>
In-Reply-To: <3427132d-9458-4447-b667-d2ef3c1f0569@suse.com>
From: Carlo Nonato 
Date: Tue, 26 Mar 2024 17:39:50 +0100
Message-ID: 
Subject: Re: [PATCH v7 08/14] xen/page_alloc: introduce preserved page flags macro
To: Jan Beulich 
Cc: Julien Grall , Andrew Cooper , 
	George Dunlap , Stefano Stabellini , Wei Liu , 
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
	xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Jan,

On Mon, Mar 25, 2024 at 8:19=E2=80=AFAM Jan Beulich  wro=
te:
>
> On 22.03.2024 16:07, Carlo Nonato wrote:
> > Hi guys,
> >
> > On Thu, Mar 21, 2024 at 5:23=E2=80=AFPM Jan Beulich =
 wrote:
> >>
> >> On 21.03.2024 17:10, Julien Grall wrote:
> >>> On 21/03/2024 16:07, Julien Grall wrote:
> >>>> On 15/03/2024 10:58, Carlo Nonato wrote:
> >>>>> PGC_static and PGC_extra needs to be preserved when assigning a pag=
e.
> >>>>> Define a new macro that groups those flags and use it instead of or=
'ing
> >>>>> every time.
> >>>>>
> >>>>> To make preserved flags even more meaningful, they are kept also wh=
en
> >>>>> switching state in mark_page_free().
> >>>>>
> >>>>> Signed-off-by: Carlo Nonato 
> >>>>
> >>>> This patch is introducing a regression in OSStest (and possibly gitl=
ab?):
> >>>>
> >>>> Mar 21 12:00:29.533676 (XEN) pg[0] MFN 2211c5 c=3D0x2c00000000000000=
 o=3D0
> >>>> v=3D0xe40000010007ffff t=3D0x24
> >>>> Mar 21 12:00:42.829785 (XEN) Xen BUG at common/page_alloc.c:1033
> >>>> Mar 21 12:00:42.829829 (XEN) ----[ Xen-4.19-unstable  x86_64  debug=
=3Dy
> >>>> Not tainted ]----
> >>>> Mar 21 12:00:42.829857 (XEN) CPU:    12
> >>>> Mar 21 12:00:42.841571 (XEN) RIP:    e008:[]
> >>>> common/page_alloc.c#alloc_heap_pages+0x37f/0x6e2
> >>>> Mar 21 12:00:42.841609 (XEN) RFLAGS: 0000000000010282   CONTEXT:
> >>>> hypervisor (d0v8)
> >>>> Mar 21 12:00:42.853654 (XEN) rax: ffff83023e3ed06c   rbx:
> >>>> 000000000007ffff   rcx: 0000000000000028
> >>>> Mar 21 12:00:42.853689 (XEN) rdx: ffff83047bec7fff   rsi:
> >>>> ffff83023e3ea3e8   rdi: ffff83023e3ea3e0
> >>>> Mar 21 12:00:42.865657 (XEN) rbp: ffff83047bec7c10   rsp:
> >>>> ffff83047bec7b98   r8:  0000000000000000
> >>>> Mar 21 12:00:42.877647 (XEN) r9:  0000000000000001   r10:
> >>>> 000000000000000c   r11: 0000000000000010
> >>>> Mar 21 12:00:42.877682 (XEN) r12: 0000000000000001   r13:
> >>>> 0000000000000000   r14: ffff82e0044238a0
> >>>> Mar 21 12:00:42.889652 (XEN) r15: 0000000000000000   cr0:
> >>>> 0000000080050033   cr4: 0000000000372660
> >>>> Mar 21 12:00:42.901651 (XEN) cr3: 000000046fe34000   cr2: 00007fb727=
57610b
> >>>> Mar 21 12:00:42.901685 (XEN) fsb: 00007fb726def380   gsb:
> >>>> ffff88801f200000   gss: 0000000000000000
> >>>> Mar 21 12:00:42.913646 (XEN) ds: 0000   es: 0000   fs: 0000   gs: 00=
00
> >>>> ss: e010   cs: e008
> >>>> Mar 21 12:00:42.913680 (XEN) Xen code around 
> >>>> (common/page_alloc.c#alloc_heap_pages+0x37f/0x6e2):
> >>>> Mar 21 12:00:42.925645 (XEN)  d1 1c 00 e8 ad dd 02 00 <0f> 0b 48 85 =
c9
> >>>> 79 36 0f 0b 41 89 cd 48 c7 47 f0
> >>>> Mar 21 12:00:42.937649 (XEN) Xen stack trace from rsp=3Dffff83047bec=
7b98:
> >>>> Mar 21 12:00:42.937683 (XEN)    0000000000000024 000000007bec7c20
> >>>> 0000000000000001 ffff83046ccda000
> >>>> Mar 21 12:00:42.949653 (XEN)    ffff82e000000021 0000000000000016
> >>>> 0000000000000000 0000000000000000
> >>>> Mar 21 12:00:42.949687 (XEN)    0000000000000000 0000000000000000
> >>>> 0000000000000028 0000000000000021
> >>>> Mar 21 12:00:42.961652 (XEN)    ffff83046ccda000 0000000000000000
> >>>> 00007d2000000000 ffff83047bec7c48
> >>>> Mar 21 12:00:42.961687 (XEN)    ffff82d0402302ff ffff83046ccda000
> >>>> 0000000000000100 0000000000000000
> >>>> Mar 21 12:00:42.973655 (XEN)    ffff82d0405f0080 00007d2000000000
> >>>> ffff83047bec7c80 ffff82d0402f626c
> >>>> Mar 21 12:00:42.985656 (XEN)    ffff83046ccda000 ffff83046ccda640
> >>>> 0000000000000000 0000000000000000
> >>>> Mar 21 12:00:42.985690 (XEN)    ffff83046ccda220 ffff83047bec7cb0
> >>>> ffff82d0402f65a0 ffff83046ccda000
> >>>> Mar 21 12:00:42.997662 (XEN)    0000000000000000 0000000000000000
> >>>> 0000000000000000 ffff83047bec7cc0
> >>>> Mar 21 12:00:43.009660 (XEN)    ffff82d040311f8a ffff83047bec7ce0
> >>>> ffff82d0402bd543 ffff83046ccda000
> >>>> Mar 21 12:00:43.009695 (XEN)    ffff83047bec7dc8 ffff83047bec7d08
> >>>> ffff82d04032c524 ffff83046ccda000
> >>>> Mar 21 12:00:43.021653 (XEN)    ffff83047bec7dc8 0000000000000002
> >>>> ffff83047bec7d58 ffff82d040206750
> >>>> Mar 21 12:00:43.033642 (XEN)    0000000000000000 ffff82d040233fe5
> >>>> ffff83047bec7d48 0000000000000000
> >>>> Mar 21 12:00:43.033678 (XEN)    0000000000000002 00007fb72767f010
> >>>> ffff82d0405e9120 0000000000000001
> >>>> Mar 21 12:00:43.045654 (XEN)    ffff83047bec7e70 ffff82d040240728
> >>>> 0000000000000007 ffff83023e3b3000
> >>>> Mar 21 12:00:43.045690 (XEN)    0000000000000246 ffff83023e2efa90
> >>>> ffff83023e38e000 ffff83023e2efb40
> >>>> Mar 21 12:00:43.057609 (XEN)    0000000000000007 ffff83023e3afb80
> >>>> 0000000000000206 ffff83047bec7dc0
> >>>> Mar 21 12:00:43.069662 (XEN)    0000001600000001 000000000000ffff
> >>>> e75aaa8d0000000c ac0d6d864e487f62
> >>>> Mar 21 12:00:43.069697 (XEN)    000000037fa48d76 0000000200000000
> >>>> ffffffff000003ff 00000002ffffffff
> >>>> Mar 21 12:00:43.081647 (XEN)    0000000000000000 00000000000001ff
> >>>> 0000000000000000 0000000000000000
> >>>> Mar 21 12:00:43.093646 (XEN) Xen call trace:
> >>>> Mar 21 12:00:43.093677 (XEN)    [] R
> >>>> common/page_alloc.c#alloc_heap_pages+0x37f/0x6e2
> >>>> Mar 21 12:00:43.093705 (XEN)    [] F
> >>>> alloc_domheap_pages+0x17d/0x1e4
> >>>> Mar 21 12:00:43.105652 (XEN)    [] F
> >>>> hap_set_allocation+0x73/0x23c
> >>>> Mar 21 12:00:43.105685 (XEN)    [] F
> >>>> hap_enable+0x138/0x33c
> >>>> Mar 21 12:00:43.117646 (XEN)    [] F
> >>>> paging_enable+0x2d/0x45
> >>>> Mar 21 12:00:43.117679 (XEN)    [] F
> >>>> hvm_domain_initialise+0x185/0x428
> >>>> Mar 21 12:00:43.129652 (XEN)    [] F
> >>>> arch_domain_create+0x3e7/0x4c1
> >>>> Mar 21 12:00:43.129687 (XEN)    [] F
> >>>> domain_create+0x4cc/0x7e2
> >>>> Mar 21 12:00:43.141665 (XEN)    [] F
> >>>> do_domctl+0x1850/0x192d
> >>>> Mar 21 12:00:43.141699 (XEN)    [] F
> >>>> pv_hypercall+0x617/0x6b5
> >>>> Mar 21 12:00:43.153656 (XEN)    [] F
> >>>> lstar_enter+0x13a/0x140
> >>>> Mar 21 12:00:43.153689 (XEN)
> >>>> Mar 21 12:00:43.153711 (XEN)
> >>>> Mar 21 12:00:43.153731 (XEN) ***************************************=
*
> >>>> Mar 21 12:00:43.165647 (XEN) Panic on CPU 12:
> >>>> Mar 21 12:00:43.165678 (XEN) Xen BUG at common/page_alloc.c:1033
> >>>> Mar 21 12:00:43.165703 (XEN) ***************************************=
*
> >>>> Mar 21 12:00:43.177633 (XEN)
> >>>> Mar 21 12:00:43.177662 (XEN) Manual reset required ('noreboot' speci=
fied)
> >>>>
> >>>> The code around the BUG is:
> >>>>
> >>>>          /* Reference count must continuously be zero for free pages=
. */
> >>>>          if ( (pg[i].count_info & ~PGC_need_scrub) !=3D PGC_state_fr=
ee )
> >>>>          {
> >>>>              printk(XENLOG_ERR
> >>>>                     "pg[%u] MFN %"PRI_mfn" c=3D%#lx o=3D%u v=3D%#lx =
t=3D%#x\n",
> >>>>                     i, mfn_x(page_to_mfn(pg + i)),
> >>>>                     pg[i].count_info, pg[i].v.free.order,
> >>>>                     pg[i].u.free.val, pg[i].tlbflush_timestamp);
> >>>>              BUG();
> >>>>          }
> >>>>
> >>>> Now that you are preserving some flags, you also want to modify the
> >>>> condition. I haven't checked the rest of the code, so there might be
> >>>> some adjustments necessary.
> >>>
> >>> Actually maybe the condition should not be adjusted. I think it would=
 be
> >>> wrong if a free pages has the flag PGC_extra set. Any thoughts?
> >>
> >> I agree, yet I'm inclined to say PGC_extra should have been cleared
> >> before trying to free the page.
> >
> > So what to do now? Should I drop this commit?
>
> No, we need to get to the root of the issue. Since osstest has hit it qui=
te
> easily as it seems, I'm somewhat surprised you didn't hit it in your test=
ing.
> In any event, as per my earlier reply, my present guess is that your chan=
ge
> has merely uncovered a previously latent issue elsewhere.

Ok, what about removing PGC_extra in free_heap_pages() before the
mark_page_free() call?

Thanks.

> Jan


From xen-devel-bounces@lists.xenproject.org Tue Mar 26 16:41:44 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Mar 2024 16:41:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698168.1089583 (Exim 4.92)
	(envelope-from )
	id 1rp9rq-00061l-9N; Tue, 26 Mar 2024 16:41:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698168.1089583; Tue, 26 Mar 2024 16:41:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rp9rq-00061e-5U; Tue, 26 Mar 2024 16:41:42 +0000
Received: by outflank-mailman (input) for mailman id 698168;
 Tue, 26 Mar 2024 16:41:40 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rp9ro-00061Y-Kz
 for xen-devel@lists.xenproject.org; Tue, 26 Mar 2024 16:41:40 +0000
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com
 [2a00:1450:4864:20::629])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b7f87a57-eb8f-11ee-afe3-a90da7624cb6;
 Tue, 26 Mar 2024 17:41:39 +0100 (CET)
Received: by mail-ej1-x629.google.com with SMTP id
 a640c23a62f3a-a450bedffdfso668130066b.3
 for ; Tue, 26 Mar 2024 09:41:39 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 t25-20020a056402241900b0056bd13ce50esm4275291eda.44.2024.03.26.09.41.37
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 26 Mar 2024 09:41:37 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b7f87a57-eb8f-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711471299; x=1712076099; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=SToh4zNsyC5pjRRjCJUQKKin0JHu8SHHJfgcIBucdqs=;
        b=RRRb4bfyep5Lt12TiGIwWthi2H52+R2tK12QpF55ERpdAvYenyjvpyTDK+nEW+bOFA
         OmzRGMPkCvvCjwLTloflcK7vwwCQfVF1jV1IT44go9C/+LX7vLjckhtDIuaKKGYkvml8
         ejOekTb0p6AUZMDWLQoyCYv6Xw1GzasxPf/ZjeKawE2wq07ibvY1QAYJ7J24+yYP16PM
         hz8DuZadq65xd904TmbLNiTa3jMNJJTnHkddlHm4/dgw3fGyzxnRTnMOaN5ok1rZOVFO
         5Ooy4KzSulV/GpBepx6hTL+8fKhn+l3Pkx6QZCY6rUz35oDb2yBZ5r8M8KPMxna7eC56
         VLrQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711471299; x=1712076099;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=SToh4zNsyC5pjRRjCJUQKKin0JHu8SHHJfgcIBucdqs=;
        b=okM9pPxcBZIRWE5Gguz0XTl263rbyE92csfZA5pqWXtZiOu8TnqqRdnrBxqsmrtnGZ
         j834UvnOUtGiTaNDATgyMPsILo00nrWw2+x1z3g4GVjSQRwtmkjoXTYq0T/HD42wKXb/
         O23BChu08J5ibfqiLpYTzBgcg/8U2kRisulrC0jCpCcPVlyaGSHXZN7F2/wb/P01laPm
         RPxl9YLg5GgJwB89nv8iRAwV8Q58htbVAoDrpYAOXq1Yiqpig96lVtQwJTAH/7OXZRn+
         D3M1d/zq48LM6yvt4aX5b+qMlU/vGwYdzNacxNGBHGBvp49xnCuS8fr9ygW3RrzrpAPT
         tk6w==
X-Forwarded-Encrypted: i=1; AJvYcCWYDoufzQrcDVZBkop3SoLQl+4Pzt5eLfgB2AWXzA0zEJrH/X0R2i63s1ZaUyFkq4Z1P8t1gS0JNxgQ9fxiZhBciWOQu3WF25rf7DHfZ40=
X-Gm-Message-State: AOJu0Yw/1YBCL4C3BHESecDEFNFafGsYoupiOs+JWZ69YSuqGcxE5bYM
	g1Z8wj/Lsh7rYNNd0jfCDK+dRldtCPnxDdpM5cVA+YX3kq381hOBnrvlt+4Ej2bExoLOpajer3s
	=
X-Google-Smtp-Source: AGHT+IHDZsvA+Y5qr3l07fRvqfaMLdrVXKqNExCorZl7gUbey1lfvSqJ12RFwp9BHC30CxnGeCWing==
X-Received: by 2002:a17:906:f816:b0:a47:4862:7fef with SMTP id kh22-20020a170906f81600b00a4748627fefmr1149668ejb.76.1711471298106;
        Tue, 26 Mar 2024 09:41:38 -0700 (PDT)
Message-ID: <14891d02-e9e9-4650-b572-e6f071f1506c@suse.com>
Date: Tue, 26 Mar 2024 17:41:36 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 5/6] xen/x86: Derive topologically correct x2APIC IDs from
 the policy
Content-Language: en-US
To: Alejandro Vallejo 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Liu
 , Anthony PERARD ,
 Xen-devel 
References: <20240109153834.4192-1-alejandro.vallejo@cloud.com>
 <20240109153834.4192-6-alejandro.vallejo@cloud.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240109153834.4192-6-alejandro.vallejo@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 09.01.2024 16:38, Alejandro Vallejo wrote:
> --- a/xen/lib/x86/policy.c
> +++ b/xen/lib/x86/policy.c
> @@ -2,15 +2,78 @@
>  
>  #include 
>  
> -uint32_t x86_x2apic_id_from_vcpu_id(const struct cpu_policy *p, uint32_t vcpu_id)
> +static uint32_t parts_per_higher_scoped_level(const struct cpu_policy *p, size_t lvl)
>  {
>      /*
> -     * TODO: Derive x2APIC ID from the topology information inside `p`
> -     *       rather than from vCPU ID. This bodge is a temporary measure
> -     *       until all infra is in place to retrieve or derive the initial
> -     *       x2APIC ID from migrated domains.
> +     * `nr_logical` reported by Intel is the number of THREADS contained in
> +     * the next topological scope. For example, assuming a system with 2
> +     * threads/core and 3 cores/module in a fully symmetric topology,
> +     * `nr_logical` at the core level will report 6. Because it's reporting
> +     * the number of threads in a module.
> +     *
> +     * On AMD/Hygon, nr_logical is already normalized by the higher scoped
> +     * level (cores/complex, etc) so we can return it as-is.
>       */
> -    return vcpu_id * 2;
> +    if ( p->x86_vendor != X86_VENDOR_INTEL || !lvl )
> +        return p->topo.subleaf[lvl].nr_logical;

Is "!= Intel" really appropriate here? I'd rather see this being "AMD || Hygon".

Jan

> +    return p->topo.subleaf[lvl].nr_logical / p->topo.subleaf[lvl - 1].nr_logical;
> +}



From xen-devel-bounces@lists.xenproject.org Tue Mar 26 16:51:37 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Mar 2024 16:51:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698173.1089594 (Exim 4.92)
	(envelope-from )
	id 1rpA1M-0008Gl-9t; Tue, 26 Mar 2024 16:51:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698173.1089594; Tue, 26 Mar 2024 16:51:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpA1M-0008Ge-4Y; Tue, 26 Mar 2024 16:51:32 +0000
Received: by outflank-mailman (input) for mailman id 698173;
 Tue, 26 Mar 2024 16:51:30 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpA1K-0008GY-FP
 for xen-devel@lists.xenproject.org; Tue, 26 Mar 2024 16:51:30 +0000
Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com
 [2607:f8b0:4864:20::233])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 166e6a14-eb91-11ee-a1ef-f123f15fe8a2;
 Tue, 26 Mar 2024 17:51:28 +0100 (CET)
Received: by mail-oi1-x233.google.com with SMTP id
 5614622812f47-3c3ceeb2d04so1194241b6e.1
 for ; Tue, 26 Mar 2024 09:51:28 -0700 (PDT)
Received: from localhost ([85.31.135.62]) by smtp.gmail.com with ESMTPSA id
 z9-20020ac875c9000000b00430c76f0c86sm3823648qtq.80.2024.03.26.09.51.26
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 26 Mar 2024 09:51:26 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 166e6a14-eb91-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1711471887; x=1712076687; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=YjHGX484TMae616qYM8ci2l4h5LW2pC4715uDmVWPb8=;
        b=Ylky9z4L0acuLA31XEorux+xZ9tKFL/7KbVmFgDZbq8WyQOWFtB3knIxT+Pwklz6ed
         4ybrUEcJzwP0E7UDJrnDA/T4/ovar0P5Pn1CnZ+eexBgVQLfi6zj5hzyyLcez//if4pu
         7necTCEZKiVgCKgoRcR5TBicU/g+WzcWipzeQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711471887; x=1712076687;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=YjHGX484TMae616qYM8ci2l4h5LW2pC4715uDmVWPb8=;
        b=TcRyOj9Wk62FKQ3AJMt8LXuCuMOpMZn0njP+NKzrrv6AgxInWzQAYKNBh8I/qtHPc+
         r6C9MUAN5vXfs+KSdfRF9byy+5xBijKhy5lbweag5yIFagG74rNtFVnK6JsV6DfHDxb0
         sm5svpPIngSkAm4NaqsVfuHOojtde2xVU6ErO/PinKn4aTXSccTM5+CubUpK5RM+TDC4
         VrHgYJn3OTPm6J90U7BVG2JWvLSDYLsqujPNu1J6OfOb6tSPnB7RqAeBv22r5P6bw4sZ
         6ETQMtqIHWKA+lmTO2cswYfUsw2Nq6+FSbVMeK1ZjtD/LFvZeFxCyKWlXF4WUIAgKtSw
         LLGQ==
X-Forwarded-Encrypted: i=1; AJvYcCWE71f7+HlTjmdbtghBvn5R6Q+H8DvZOvSEbfzo2B4ovKpE1sxzYQyUVd1V0bvAdMeONaffbbH3Jd+zcCacapJYZftA4A37Ya5lfwL64UM=
X-Gm-Message-State: AOJu0YzOuogeDT30I66qMzkSg/wM8fnBe64DR2WgOjCR7CZGnHNbt2vQ
	zeDs5qZL91g1suW3dsX1TfSbYKTXioYwXgttZyRwxCMg24HIucnlanPIayWLR1Q=
X-Google-Smtp-Source: AGHT+IFmHr35PwtSrzx9AmnO6/x//vXaJOGTolW0SIUcmldnxph3hqwZmR8LqJGbAeEXh173AaaYfQ==
X-Received: by 2002:a05:6808:3a0a:b0:3c3:a606:8084 with SMTP id gr10-20020a0568083a0a00b003c3a6068084mr4494980oib.46.1711471886855;
        Tue, 26 Mar 2024 09:51:26 -0700 (PDT)
Date: Tue, 26 Mar 2024 17:51:24 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Alejandro Vallejo 
Cc: Jan Beulich ,
	Matthew Barnes , Wei Liu ,
	Anthony PERARD ,
	Xen-devel 
Subject: Re: [XEN PATCH] tools: add x2APIC entries in MADT based on APIC ID
Message-ID: 
References: 
 <32a4de1e-94fe-4b44-b95c-55cd1ec7e7e4@suse.com>
 <8895fcce-3738-4bd6-9127-56296369e3e6@cloud.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <8895fcce-3738-4bd6-9127-56296369e3e6@cloud.com>

On Mon, Mar 25, 2024 at 02:30:35PM +0000, Alejandro Vallejo wrote:
> Hi,
> 
> On 14/03/2024 13:50, Jan Beulich wrote:
> > On 13.03.2024 16:35, Matthew Barnes wrote:
> >> libacpi is a tool that is used by libxl (for PVH guests) and hvmloader
> >> (for HVM guests) to construct ACPI tables for guests.
> >>
> >> Currently, libacpi only uses APIC entries to enumerate processors for
> >> guests in the MADT.
> >>
> >> The APIC ID field in APIC entries is an octet big, which is fine for
> >> xAPIC IDs, but not so for sufficiently large x2APIC IDs.
> > 
> > Yet where would those come from? I can see that down the road we will
> > have such, but right now I don't think we do. Without saying so, this
> > change could be mistaken for a fix of an active bug.
> 
> It's worth adding some context here.
> 
> You're quite right in that it's not immediately needed now, but with the
> work done on improving the state of CPU topologies exposed to guests[1]
> the strict binding between APIC ID and vCPU ID breaks. It's not hard to
> imagine sparsity in the APIC ID space forcing the maximum one to peak
> beyond 254. The generator present in that series tries to be
> conservative and avoid it, but general topologies can theoretically
> waste copious amounts of APIC ID space (i.e: by reserving more width
> than strictly required to represent IDs of a certain level), and
> exposing the host topology sensibly becomes difficult if we're subject
> to limitations the host does not have.

Most guest OSes will refuse to bring up APs with APIC ID > 254, unless
there's support for interrupt remapping or Extended Destination ID
[0].  So while adding the entries in the MADT is fine, I wonder how we
can sensibly test this.

IMO, we should first add support for Extended Destination ID, and then
expose APs with APIC ID > 254.

Have you been able to test this with APIC IDs > 254, and can confirm
that an OS is capable of bringing those APs up with the ID in the
x2APIC MADT entry?

I think at a minimum you need some changes to the vlapic code in Xen,
so that when a vLAPIC gets assigned an ID > 254 it automatically
switches to x2APIC mode, as vlapic_init() unconditionally inits the
lapic in xAPIC mode.  Otherwise the INTI-SIPI-SIPI sequence won't find
the intended destination.

Thanks, Roger.

[0] https://gitlab.com/xen-project/xen/-/issues/173


From xen-devel-bounces@lists.xenproject.org Tue Mar 26 17:02:12 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Mar 2024 17:02:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698178.1089602 (Exim 4.92)
	(envelope-from )
	id 1rpABb-0001tM-5W; Tue, 26 Mar 2024 17:02:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698178.1089602; Tue, 26 Mar 2024 17:02:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpABb-0001tF-2h; Tue, 26 Mar 2024 17:02:07 +0000
Received: by outflank-mailman (input) for mailman id 698178;
 Tue, 26 Mar 2024 17:02:06 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpABa-0001t9-M3
 for xen-devel@lists.xenproject.org; Tue, 26 Mar 2024 17:02:06 +0000
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com
 [2a00:1450:4864:20::530])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 926fbf4b-eb92-11ee-afe3-a90da7624cb6;
 Tue, 26 Mar 2024 18:02:05 +0100 (CET)
Received: by mail-ed1-x530.google.com with SMTP id
 4fb4d7f45d1cf-56be32b9775so5618914a12.1
 for ; Tue, 26 Mar 2024 10:02:05 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 f2-20020a50d542000000b00568c2ea2cefsm4535247edj.51.2024.03.26.10.02.03
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 26 Mar 2024 10:02:04 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 926fbf4b-eb92-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711472524; x=1712077324; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=y1B8qLTsvJuggG/6NUKRHlPw7/Jff/UNOH2aXWdvsY8=;
        b=YMlL1+4mnE7Y8ZDIEVt6FCQE8ROIhFNsd3jbBECRFtFcMOi0/lPtDyL3TtVTXG4lAe
         r6nSfu+ikyBKDFRA3vqbMUCr7uL2pQ9vGT6NdHZWxNt2TrSXzc4FHS9jtVHpMq5SN49o
         VwjI/gnXtfeiT5/KOV3/eHKlo/tDgA/MMunqyUFhTzsVXmEQPgPN+rckX7pylhZrP/zn
         FYckiudZ3mTdpqpABiKQewautPDY+JB4frMLJX75Nu9xtzR7cArwoIWFNbDiDTDuMunc
         YBb5gbH6+CpJmShgLbX3Rhurkf5yieMK5tERdJuC6Sbcq4K7FNWtaxsYE94hRMvtdnNh
         PXHQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711472524; x=1712077324;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=y1B8qLTsvJuggG/6NUKRHlPw7/Jff/UNOH2aXWdvsY8=;
        b=jBRS3aDnwqKmTpN1nPjuWS0LPT5SSDu9HInXcflGUsdcyS3ijZYLZQMWDcuslj2bIB
         HW7522eI0fWUGiCJWOwkE2wSZCJJKuaaxcSdCIYbJ5HE6gwtIzPHHOpxG2LL31onLs3K
         bHiXan0QA5Q8El+D/zFDIO43Y+L1Y3DhFG22PwzsmQRUx83A+kPRdnaWFZrTll9OkOHT
         r9WI0Y38n3J5YsWZru7E3BfScz2Qtb7TlZSuspJgrUBqlHseijs98BMw6QJfGepW/47d
         xnDIUZLES9ViV0ho6hH7ige7sg81rGSHB2mbhIXF3slfn3RlTLbNnNim1s98kg1GiSH2
         noDg==
X-Forwarded-Encrypted: i=1; AJvYcCWjHUl9NNcr0TNPsq964oE7dFRgGcrlKbmlGT5X+27GuKyItcHa1dJ8jfAHS23UB8rzTWbcMFwyuvRn/+D5PNNhbLUCJT7VSJ77W3il9rE=
X-Gm-Message-State: AOJu0YyBR4uz10+XwfKBdrw53cTURDoqTwVhpdwGjbOF+n6icza+/wjv
	tDFRRf7+Tq9LD86TJQHcx+ehYNiRjF/scoykNAXfNoaw+tDgFAf65iq2bu8wJQ==
X-Google-Smtp-Source: AGHT+IGFW/wqKA+KYrdIuXIeBQwxbKPLldzmtxtdejKcgg+hLSzTmMJ/lH+o9G3RLx38cKaFGUBJWw==
X-Received: by 2002:a50:d51c:0:b0:56b:f5ae:ae58 with SMTP id u28-20020a50d51c000000b0056bf5aeae58mr1384154edi.29.1711472524408;
        Tue, 26 Mar 2024 10:02:04 -0700 (PDT)
Message-ID: 
Date: Tue, 26 Mar 2024 18:02:03 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 6/6] xen/x86: Add topology generator
Content-Language: en-US
To: Alejandro Vallejo 
Cc: Wei Liu , Anthony PERARD ,
 Juergen Gross , Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Xen-devel 
References: <20240109153834.4192-1-alejandro.vallejo@cloud.com>
 <20240109153834.4192-7-alejandro.vallejo@cloud.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240109153834.4192-7-alejandro.vallejo@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 09.01.2024 16:38, Alejandro Vallejo wrote:
> --- a/tools/include/xenguest.h
> +++ b/tools/include/xenguest.h
> @@ -843,5 +843,20 @@ enum xc_static_cpu_featuremask {
>      XC_FEATUREMASK_HVM_HAP_DEF,
>  };
>  const uint32_t *xc_get_static_cpu_featuremask(enum xc_static_cpu_featuremask);
> +
> +/**
> + * Synthesise topology information in `p` given high-level constraints
> + *
> + * Topology is given in various fields accross several leaves, some of
> + * which are vendor-specific. This function uses the policy itself to
> + * derive such leaves from threads/core and cores/package.
> + *
> + * @param p                   CPU policy of the domain.
> + * @param threads_per_core    threads/core. Doesn't need to be a power of 2.
> + * @param cores_per_package   cores/package. Doesn't need to be a power of 2.
> + */
> +void xc_topo_from_parts(struct cpu_policy *p,
> +                        uint32_t threads_per_core, uint32_t cores_per_pkg);

Do we really want to constrain things to just two (or in fact any fixed number
of) levels? Iirc on AMD there already can be up to 4.

> @@ -1028,3 +976,89 @@ bool xc_cpu_policy_is_compatible(xc_interface *xch, xc_cpu_policy_t *host,
>  
>      return false;
>  }
> +
> +static uint32_t order(uint32_t n)
> +{
> +    return 32 - __builtin_clz(n);
> +}

This isn't really portable. __builtin_clz() takes an unsigned int, which may
in principle be wider than 32 bits. I also can't see a reason for the
function to have a fixed-width return type. Perhaps

static unsigned int order(unsigned int n)
{
    return sizeof(n) * CHAR_BIT - __builtin_clz(n);
}

?

> +void xc_topo_from_parts(struct cpu_policy *p,
> +                        uint32_t threads_per_core, uint32_t cores_per_pkg)
> +{
> +    uint32_t threads_per_pkg = threads_per_core * cores_per_pkg;
> +    uint32_t apic_id_size;
> +
> +    if ( p->basic.max_leaf < 0xb )
> +        p->basic.max_leaf = 0xb;
> +
> +    memset(p->topo.raw, 0, sizeof(p->topo.raw));
> +
> +    /* thread level */
> +    p->topo.subleaf[0].nr_logical = threads_per_core;
> +    p->topo.subleaf[0].id_shift = 0;
> +    p->topo.subleaf[0].level = 0;
> +    p->topo.subleaf[0].type = 1;
> +    if ( threads_per_core > 1 )
> +        p->topo.subleaf[0].id_shift = order(threads_per_core - 1);
> +
> +    /* core level */
> +    p->topo.subleaf[1].nr_logical = cores_per_pkg;
> +    if ( p->x86_vendor == X86_VENDOR_INTEL )
> +        p->topo.subleaf[1].nr_logical = threads_per_pkg;

Same concern as in the other patch regarding "== Intel".

> +    p->topo.subleaf[1].id_shift = p->topo.subleaf[0].id_shift;
> +    p->topo.subleaf[1].level = 1;
> +    p->topo.subleaf[1].type = 2;
> +    if ( cores_per_pkg > 1 )
> +        p->topo.subleaf[1].id_shift += order(cores_per_pkg - 1);

Don't you want to return an error when any of the X_per_Y values is 0?

> +    apic_id_size = p->topo.subleaf[1].id_shift;
> +
> +    /*
> +     * Contrary to what the name might seem to imply. HTT is an enabler for
> +     * SMP and there's no harm in setting it even with a single vCPU.
> +     */
> +    p->basic.htt = true;
> +
> +    p->basic.lppp = 0xff;
> +    if ( threads_per_pkg < 0xff )
> +        p->basic.lppp = threads_per_pkg;
> +
> +    switch ( p->x86_vendor )
> +    {
> +        case X86_VENDOR_INTEL:
> +            struct cpuid_cache_leaf *sl = p->cache.subleaf;
> +            for ( size_t i = 0; sl->type &&
> +                                i < ARRAY_SIZE(p->cache.raw); i++, sl++ )
> +            {
> +                sl->cores_per_package = cores_per_pkg - 1;
> +                sl->threads_per_cache = threads_per_core - 1;

IOW the names in struct cpuid_cache_leaf aren't quite correct.

> +                if ( sl->type == 3 /* unified cache */ )
> +                    sl->threads_per_cache = threads_per_pkg - 1;
> +            }
> +            break;
> +
> +        case X86_VENDOR_AMD:
> +        case X86_VENDOR_HYGON:
> +            /* Expose p->basic.lppp */
> +            p->extd.cmp_legacy = true;
> +
> +            /* Clip NC to the maximum value it can hold */
> +            p->extd.nc = 0xff;
> +            if ( threads_per_pkg <= 0xff )
> +                p->extd.nc = threads_per_pkg - 1;
> +
> +            /* TODO: Expose leaf e1E */
> +            p->extd.topoext = false;
> +
> +            /*
> +             * Clip APIC ID to 8, as that's what high core-count machines do

Nit: "... to 8 bits, ..."

> +             *
> +             * That what AMD EPYC 9654 does with >256 CPUs
> +             */
> +            p->extd.apic_id_size = 8;
> +            if ( apic_id_size < 8 )
> +                p->extd.apic_id_size = apic_id_size;

Use min(), with apic_id_size's type suitably adjusted?

> --- a/xen/arch/x86/cpu-policy.c
> +++ b/xen/arch/x86/cpu-policy.c
> @@ -278,9 +278,6 @@ static void recalculate_misc(struct cpu_policy *p)
>  
>      p->basic.raw[0x8] = EMPTY_LEAF;
>  
> -    /* TODO: Rework topology logic. */
> -    memset(p->topo.raw, 0, sizeof(p->topo.raw));
> -
>      p->basic.raw[0xc] = EMPTY_LEAF;
>  
>      p->extd.e1d &= ~CPUID_COMMON_1D_FEATURES;
> @@ -387,6 +384,9 @@ static void __init calculate_host_policy(void)
>      recalculate_xstate(p);
>      recalculate_misc(p);
>  
> +    /* Wipe host topology. Toolstack is expected to synthesise a sensible one */
> +    memset(p->topo.raw, 0, sizeof(p->topo.raw));

I don't think this should be zapped from the host policy. It wants zapping
from the guest ones instead, imo. The host policy may (will) want using in
Xen itself, and hence it should reflect reality.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Mar 26 17:05:02 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Mar 2024 17:05:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698182.1089613 (Exim 4.92)
	(envelope-from )
	id 1rpAEO-0002SA-Ix; Tue, 26 Mar 2024 17:05:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698182.1089613; Tue, 26 Mar 2024 17:05:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpAEO-0002S3-Fv; Tue, 26 Mar 2024 17:05:00 +0000
Received: by outflank-mailman (input) for mailman id 698182;
 Tue, 26 Mar 2024 17:04:59 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpAEN-0002RU-TU
 for xen-devel@lists.xenproject.org; Tue, 26 Mar 2024 17:04:59 +0000
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com
 [2a00:1450:4864:20::629])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id fa31d948-eb92-11ee-afe3-a90da7624cb6;
 Tue, 26 Mar 2024 18:04:59 +0100 (CET)
Received: by mail-ej1-x629.google.com with SMTP id
 a640c23a62f3a-a4702457ccbso742881566b.3
 for ; Tue, 26 Mar 2024 10:04:59 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 jy12-20020a170907762c00b00a46ab3adea5sm4421333ejc.113.2024.03.26.10.04.57
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 26 Mar 2024 10:04:57 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: fa31d948-eb92-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711472698; x=1712077498; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=uuzKZXxFf1+GQZFr7QU0Vuyclxmq77t6KiD8r093TN4=;
        b=SR4JQMVvKmCAwb05ZwD/gPJzSHEcU3b1f9bPNYnv6s1zo+uWatVVpMdkQFjmx8UEsY
         EpuyTtAjz2tNWpzObCTgCT19UjfWpD9knj+q0atmApgliQ8wjKh/svx79unB187ePZ7Z
         qYpDyTwYENLFvnLo4DGtA4GwDRvfHwrw8vUIOPeSsTw2GhvOfpR2YWLV4CLNm2sgzazU
         c8MnP4+kcR5QIn98RpBpzmqPfy3hRb2frcVW5CEF48FR3VxhXC8JpWdf4AGeBVG7DxIO
         OLK0Uy3ctEtfLDitnEVbgQeQisAc2lsFuzcz+ozMVMttKkh0/Z5FiqYuRI9ove8fDuhy
         Bwlg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711472698; x=1712077498;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=uuzKZXxFf1+GQZFr7QU0Vuyclxmq77t6KiD8r093TN4=;
        b=TL92eqMQN/Wn9LFravgqEKZ2AyJaLv6sx5EFV1fL25V/xfmfNX3jUcMmlxKMhVQ38e
         KMN3bS1Hdo0MfCLnCoMm/VvdAOFZh1krTrMXlkQVUg6hseaP9KRGW29ACvZwpskAVGc/
         smbYoozuzfVHdFrImekpuFH5YtlrgOIzq5y8p7Ee8kQaYgUEs88g40eLTRVt2IWdybBj
         4/5nthNcbhSO3Y60lTSngyNKB1z6R7f+HupWmcuc+GIcoMi4alsIMpxcXmftH/BcD+J6
         PmBvGD2vjyzjXc53ixUOubrKF5XjsLQoksOqlKbTU20baVSCrvOPXHO8zZ+9L16sbL65
         Ackw==
X-Forwarded-Encrypted: i=1; AJvYcCUw7oqttyxv/Bn/7x/WKC2z0O3yzbdQXJlc1631MXqJ83vHfYfbzftf3C7EHyAd0s9JVPAk8H3qigtbqtqDbQIeGPVyG0M458v6XduNKNU=
X-Gm-Message-State: AOJu0YxdKNaRvJhWLZO/ZGY37Yv3/o4jBb+4o8sxDbMt2ohCGLPdIpAY
	FsN+CacYqoexNLbWhdUf8LQtuQ7Ej3PeeosstQPaqNV4HxJWtHXAnoKLQNenMw==
X-Google-Smtp-Source: AGHT+IGxAwXxM6QM9qn1kaONeqAZchDBFk6O9UGjcc767t+hOvMBcOI7ZzpyA9mHLiFosWU3mjmKnQ==
X-Received: by 2002:a17:906:b243:b0:a47:1d01:bb8f with SMTP id ce3-20020a170906b24300b00a471d01bb8fmr6011171ejb.31.1711472698161;
        Tue, 26 Mar 2024 10:04:58 -0700 (PDT)
Message-ID: 
Date: Tue, 26 Mar 2024 18:04:57 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 08/14] xen/page_alloc: introduce preserved page flags
 macro
Content-Language: en-US
To: Carlo Nonato 
Cc: Julien Grall , Andrew Cooper ,
 George Dunlap ,
 Stefano Stabellini , Wei Liu ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
 <20240315105902.160047-9-carlo.nonato@minervasys.tech>
 <3f615066-a792-493f-ba33-7667a6557c23@xen.org>
 <9e0f7ff3-5457-41e4-a1e4-bf75804fb900@xen.org>
 <255be735-f9fe-4e39-a24e-2f6aff91acc5@suse.com>
 
 <3427132d-9458-4447-b667-d2ef3c1f0569@suse.com>
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 26.03.2024 17:39, Carlo Nonato wrote:
> On Mon, Mar 25, 2024 at 8:19 AM Jan Beulich  wrote:
>> On 22.03.2024 16:07, Carlo Nonato wrote:
>>> On Thu, Mar 21, 2024 at 5:23 PM Jan Beulich  wrote:
>>>> On 21.03.2024 17:10, Julien Grall wrote:
>>>>> On 21/03/2024 16:07, Julien Grall wrote:
>>>>>> On 15/03/2024 10:58, Carlo Nonato wrote:
>>>>>>> PGC_static and PGC_extra needs to be preserved when assigning a page.
>>>>>>> Define a new macro that groups those flags and use it instead of or'ing
>>>>>>> every time.
>>>>>>>
>>>>>>> To make preserved flags even more meaningful, they are kept also when
>>>>>>> switching state in mark_page_free().
>>>>>>>
>>>>>>> Signed-off-by: Carlo Nonato 
>>>>>>
>>>>>> This patch is introducing a regression in OSStest (and possibly gitlab?):
>>>>>>
>>>>>> Mar 21 12:00:29.533676 (XEN) pg[0] MFN 2211c5 c=0x2c00000000000000 o=0
>>>>>> v=0xe40000010007ffff t=0x24
>>>>>> Mar 21 12:00:42.829785 (XEN) Xen BUG at common/page_alloc.c:1033
>>>>>> Mar 21 12:00:42.829829 (XEN) ----[ Xen-4.19-unstable  x86_64  debug=y
>>>>>> Not tainted ]----
>>>>>> Mar 21 12:00:42.829857 (XEN) CPU:    12
>>>>>> Mar 21 12:00:42.841571 (XEN) RIP:    e008:[]
>>>>>> common/page_alloc.c#alloc_heap_pages+0x37f/0x6e2
>>>>>> Mar 21 12:00:42.841609 (XEN) RFLAGS: 0000000000010282   CONTEXT:
>>>>>> hypervisor (d0v8)
>>>>>> Mar 21 12:00:42.853654 (XEN) rax: ffff83023e3ed06c   rbx:
>>>>>> 000000000007ffff   rcx: 0000000000000028
>>>>>> Mar 21 12:00:42.853689 (XEN) rdx: ffff83047bec7fff   rsi:
>>>>>> ffff83023e3ea3e8   rdi: ffff83023e3ea3e0
>>>>>> Mar 21 12:00:42.865657 (XEN) rbp: ffff83047bec7c10   rsp:
>>>>>> ffff83047bec7b98   r8:  0000000000000000
>>>>>> Mar 21 12:00:42.877647 (XEN) r9:  0000000000000001   r10:
>>>>>> 000000000000000c   r11: 0000000000000010
>>>>>> Mar 21 12:00:42.877682 (XEN) r12: 0000000000000001   r13:
>>>>>> 0000000000000000   r14: ffff82e0044238a0
>>>>>> Mar 21 12:00:42.889652 (XEN) r15: 0000000000000000   cr0:
>>>>>> 0000000080050033   cr4: 0000000000372660
>>>>>> Mar 21 12:00:42.901651 (XEN) cr3: 000000046fe34000   cr2: 00007fb72757610b
>>>>>> Mar 21 12:00:42.901685 (XEN) fsb: 00007fb726def380   gsb:
>>>>>> ffff88801f200000   gss: 0000000000000000
>>>>>> Mar 21 12:00:42.913646 (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000
>>>>>> ss: e010   cs: e008
>>>>>> Mar 21 12:00:42.913680 (XEN) Xen code around 
>>>>>> (common/page_alloc.c#alloc_heap_pages+0x37f/0x6e2):
>>>>>> Mar 21 12:00:42.925645 (XEN)  d1 1c 00 e8 ad dd 02 00 <0f> 0b 48 85 c9
>>>>>> 79 36 0f 0b 41 89 cd 48 c7 47 f0
>>>>>> Mar 21 12:00:42.937649 (XEN) Xen stack trace from rsp=ffff83047bec7b98:
>>>>>> Mar 21 12:00:42.937683 (XEN)    0000000000000024 000000007bec7c20
>>>>>> 0000000000000001 ffff83046ccda000
>>>>>> Mar 21 12:00:42.949653 (XEN)    ffff82e000000021 0000000000000016
>>>>>> 0000000000000000 0000000000000000
>>>>>> Mar 21 12:00:42.949687 (XEN)    0000000000000000 0000000000000000
>>>>>> 0000000000000028 0000000000000021
>>>>>> Mar 21 12:00:42.961652 (XEN)    ffff83046ccda000 0000000000000000
>>>>>> 00007d2000000000 ffff83047bec7c48
>>>>>> Mar 21 12:00:42.961687 (XEN)    ffff82d0402302ff ffff83046ccda000
>>>>>> 0000000000000100 0000000000000000
>>>>>> Mar 21 12:00:42.973655 (XEN)    ffff82d0405f0080 00007d2000000000
>>>>>> ffff83047bec7c80 ffff82d0402f626c
>>>>>> Mar 21 12:00:42.985656 (XEN)    ffff83046ccda000 ffff83046ccda640
>>>>>> 0000000000000000 0000000000000000
>>>>>> Mar 21 12:00:42.985690 (XEN)    ffff83046ccda220 ffff83047bec7cb0
>>>>>> ffff82d0402f65a0 ffff83046ccda000
>>>>>> Mar 21 12:00:42.997662 (XEN)    0000000000000000 0000000000000000
>>>>>> 0000000000000000 ffff83047bec7cc0
>>>>>> Mar 21 12:00:43.009660 (XEN)    ffff82d040311f8a ffff83047bec7ce0
>>>>>> ffff82d0402bd543 ffff83046ccda000
>>>>>> Mar 21 12:00:43.009695 (XEN)    ffff83047bec7dc8 ffff83047bec7d08
>>>>>> ffff82d04032c524 ffff83046ccda000
>>>>>> Mar 21 12:00:43.021653 (XEN)    ffff83047bec7dc8 0000000000000002
>>>>>> ffff83047bec7d58 ffff82d040206750
>>>>>> Mar 21 12:00:43.033642 (XEN)    0000000000000000 ffff82d040233fe5
>>>>>> ffff83047bec7d48 0000000000000000
>>>>>> Mar 21 12:00:43.033678 (XEN)    0000000000000002 00007fb72767f010
>>>>>> ffff82d0405e9120 0000000000000001
>>>>>> Mar 21 12:00:43.045654 (XEN)    ffff83047bec7e70 ffff82d040240728
>>>>>> 0000000000000007 ffff83023e3b3000
>>>>>> Mar 21 12:00:43.045690 (XEN)    0000000000000246 ffff83023e2efa90
>>>>>> ffff83023e38e000 ffff83023e2efb40
>>>>>> Mar 21 12:00:43.057609 (XEN)    0000000000000007 ffff83023e3afb80
>>>>>> 0000000000000206 ffff83047bec7dc0
>>>>>> Mar 21 12:00:43.069662 (XEN)    0000001600000001 000000000000ffff
>>>>>> e75aaa8d0000000c ac0d6d864e487f62
>>>>>> Mar 21 12:00:43.069697 (XEN)    000000037fa48d76 0000000200000000
>>>>>> ffffffff000003ff 00000002ffffffff
>>>>>> Mar 21 12:00:43.081647 (XEN)    0000000000000000 00000000000001ff
>>>>>> 0000000000000000 0000000000000000
>>>>>> Mar 21 12:00:43.093646 (XEN) Xen call trace:
>>>>>> Mar 21 12:00:43.093677 (XEN)    [] R
>>>>>> common/page_alloc.c#alloc_heap_pages+0x37f/0x6e2
>>>>>> Mar 21 12:00:43.093705 (XEN)    [] F
>>>>>> alloc_domheap_pages+0x17d/0x1e4
>>>>>> Mar 21 12:00:43.105652 (XEN)    [] F
>>>>>> hap_set_allocation+0x73/0x23c
>>>>>> Mar 21 12:00:43.105685 (XEN)    [] F
>>>>>> hap_enable+0x138/0x33c
>>>>>> Mar 21 12:00:43.117646 (XEN)    [] F
>>>>>> paging_enable+0x2d/0x45
>>>>>> Mar 21 12:00:43.117679 (XEN)    [] F
>>>>>> hvm_domain_initialise+0x185/0x428
>>>>>> Mar 21 12:00:43.129652 (XEN)    [] F
>>>>>> arch_domain_create+0x3e7/0x4c1
>>>>>> Mar 21 12:00:43.129687 (XEN)    [] F
>>>>>> domain_create+0x4cc/0x7e2
>>>>>> Mar 21 12:00:43.141665 (XEN)    [] F
>>>>>> do_domctl+0x1850/0x192d
>>>>>> Mar 21 12:00:43.141699 (XEN)    [] F
>>>>>> pv_hypercall+0x617/0x6b5
>>>>>> Mar 21 12:00:43.153656 (XEN)    [] F
>>>>>> lstar_enter+0x13a/0x140
>>>>>> Mar 21 12:00:43.153689 (XEN)
>>>>>> Mar 21 12:00:43.153711 (XEN)
>>>>>> Mar 21 12:00:43.153731 (XEN) ****************************************
>>>>>> Mar 21 12:00:43.165647 (XEN) Panic on CPU 12:
>>>>>> Mar 21 12:00:43.165678 (XEN) Xen BUG at common/page_alloc.c:1033
>>>>>> Mar 21 12:00:43.165703 (XEN) ****************************************
>>>>>> Mar 21 12:00:43.177633 (XEN)
>>>>>> Mar 21 12:00:43.177662 (XEN) Manual reset required ('noreboot' specified)
>>>>>>
>>>>>> The code around the BUG is:
>>>>>>
>>>>>>          /* Reference count must continuously be zero for free pages. */
>>>>>>          if ( (pg[i].count_info & ~PGC_need_scrub) != PGC_state_free )
>>>>>>          {
>>>>>>              printk(XENLOG_ERR
>>>>>>                     "pg[%u] MFN %"PRI_mfn" c=%#lx o=%u v=%#lx t=%#x\n",
>>>>>>                     i, mfn_x(page_to_mfn(pg + i)),
>>>>>>                     pg[i].count_info, pg[i].v.free.order,
>>>>>>                     pg[i].u.free.val, pg[i].tlbflush_timestamp);
>>>>>>              BUG();
>>>>>>          }
>>>>>>
>>>>>> Now that you are preserving some flags, you also want to modify the
>>>>>> condition. I haven't checked the rest of the code, so there might be
>>>>>> some adjustments necessary.
>>>>>
>>>>> Actually maybe the condition should not be adjusted. I think it would be
>>>>> wrong if a free pages has the flag PGC_extra set. Any thoughts?
>>>>
>>>> I agree, yet I'm inclined to say PGC_extra should have been cleared
>>>> before trying to free the page.
>>>
>>> So what to do now? Should I drop this commit?
>>
>> No, we need to get to the root of the issue. Since osstest has hit it quite
>> easily as it seems, I'm somewhat surprised you didn't hit it in your testing.
>> In any event, as per my earlier reply, my present guess is that your change
>> has merely uncovered a previously latent issue elsewhere.
> 
> Ok, what about removing PGC_extra in free_heap_pages() before the
> mark_page_free() call?

Question is: How would you justify such a change? IOW I'm not convinced
(yet) this wants doing there.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Mar 26 17:06:57 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Mar 2024 17:06:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698185.1089622 (Exim 4.92)
	(envelope-from )
	id 1rpAGG-00032m-0t; Tue, 26 Mar 2024 17:06:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698185.1089622; Tue, 26 Mar 2024 17:06:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpAGF-00032f-UR; Tue, 26 Mar 2024 17:06:55 +0000
Received: by outflank-mailman (input) for mailman id 698185;
 Tue, 26 Mar 2024 17:06:54 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpAGE-00032X-Hx
 for xen-devel@lists.xenproject.org; Tue, 26 Mar 2024 17:06:54 +0000
Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com
 [2a00:1450:4864:20::22e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3dd6425e-eb93-11ee-a1ef-f123f15fe8a2;
 Tue, 26 Mar 2024 18:06:52 +0100 (CET)
Received: by mail-lj1-x22e.google.com with SMTP id
 38308e7fff4ca-2d24a727f78so64861701fa.0
 for ; Tue, 26 Mar 2024 10:06:52 -0700 (PDT)
Received: from perard.uk.xensource.com (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 u2-20020a05600c138200b004146bcdde06sm12186029wmf.6.2024.03.26.10.06.51
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 26 Mar 2024 10:06:51 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3dd6425e-eb93-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1711472812; x=1712077612; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=7Lil4XHHupH9pVMZOy3d4NrDmD8ftMIDsaMKq9dwcYo=;
        b=afRNlXrMS9Y9o6SnilYBNyuvqoZ1S90Hlp+UNkYh6stHknUHDf2+TBq54szsS7z3GF
         h+AUxvGFeyIeKTAq27Om33E/qoDqpm/q2P/UuwOSlKKYI1GhIYFOae2BttqCR9NjcCOY
         BbP3HylmNTDVQ9Doco4byMjqY3P066qhLMtHg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711472812; x=1712077612;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=7Lil4XHHupH9pVMZOy3d4NrDmD8ftMIDsaMKq9dwcYo=;
        b=HE67MZ7aUXcM6YCyG50jdLwZEeVL5B4GGgn7j0M/ZJd1p7DPKomHiSYXCbamAO63h4
         jkYi/A1AqqYGAogsG+A7UWFCZXpbMbEVaQy56irKnFE6ew0Q98PP6ftMnwvAhQoQD5pE
         aBAQ948deU3TYAfT4L+g5YswPjJfNK650ADeZqLyqVM5rnkJJTu1VurhIL2G1K/PVNzf
         nVvw3P+FD4Lm1HuAuv08tPDdJqaig2v4/gqvUUQWAxCx4V65nqoW0AXqOphOrP3vmCzA
         BVyM9oTDxI0qpClKBta82vqNi2oqr69pWJjXy0k2Z7i02VAeC7uaqu35F0e4L1l7y0hX
         LNMQ==
X-Forwarded-Encrypted: i=1; AJvYcCXGuhF5R5K450doXIzQysWs6WubZayqzW0rb/LH0UV9YZK7cpPw1XPhIEBEU30UkSBQbJnw2H9kF8+d4AXo97S7UCI+0bEGAINK1N4PS1U=
X-Gm-Message-State: AOJu0Ywerq/lTPo2fBSJpnhAayY09lzJ2K5JnY1ORAFY7CKdvzGVCtuN
	RENn55gFOfbuBVaCf5j6P233vCDvS8p0QdsbS301KGLtP9uGUTJMh4YocN8ThGc=
X-Google-Smtp-Source: AGHT+IHv4uNFDY0BUyZmHrj5BK8Xw5p0BQXHUgMeT4rCoeC67uEPB3r/L3ngTN3jBvyPa6LPOwQjKA==
X-Received: by 2002:a05:651c:1502:b0:2d2:c8ff:d2b6 with SMTP id e2-20020a05651c150200b002d2c8ffd2b6mr3155025ljf.1.1711472812034;
        Tue, 26 Mar 2024 10:06:52 -0700 (PDT)
Date: Tue, 26 Mar 2024 17:06:50 +0000
From: Anthony PERARD 
To: Marek =?iso-8859-1?Q?Marczykowski-G=F3recki?= 
Cc: qemu-devel@nongnu.org, Jason Andryuk ,
	Stefano Stabellini ,
	Paul Durrant ,
	"open list:X86 Xen CPUs" 
Subject: Re: [PATCH v2 1/2] hw/xen: detect when running inside stubdomain
Message-ID: 
References: <20240305191312.321127-1-marmarek@invisiblethingslab.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20240305191312.321127-1-marmarek@invisiblethingslab.com>

On Tue, Mar 05, 2024 at 08:12:29PM +0100, Marek Marczykowski-Grecki wrote:
> diff --git a/hw/xen/xen-legacy-backend.c b/hw/xen/xen-legacy-backend.c
> index 124dd5f3d6..6bd4e6eb2f 100644
> --- a/hw/xen/xen-legacy-backend.c
> +++ b/hw/xen/xen-legacy-backend.c
> @@ -603,6 +603,20 @@ static void xen_set_dynamic_sysbus(void)
>      machine_class_allow_dynamic_sysbus_dev(mc, TYPE_XENSYSDEV);
>  }
>  
> +static bool xen_check_stubdomain(void)
> +{
> +    char *dm_path = g_strdup_printf("/local/domain/%d/image", xen_domid);
> +    int32_t dm_domid;
> +    bool is_stubdom = false;
> +
> +    if (!xenstore_read_int(dm_path, "device-model-domid", &dm_domid)) {
> +        is_stubdom = dm_domid != 0;
> +    }
> +
> +    g_free(dm_path);
> +    return is_stubdom;
> +}
> +
>  void xen_be_init(void)
>  {
>      xenstore = qemu_xen_xs_open();
> @@ -616,6 +630,8 @@ void xen_be_init(void)
>          exit(1);
>      }
>  
> +    xen_is_stubdomain = xen_check_stubdomain();

This isn't really a backend specific information, and xen_be_init() is
all about old backend implementation support. (qdisk which have been the
first to be rewritten doesn't need xen_be_init(), or shouldn't). Could
we move the initialisation elsewhere?

Is this relevant PV guests? If not, we could move the initialisation to
xen_hvm_init_pc().

Also, avoid having xen_check_stubdomain() depending on
"xen-legacy-backend", if possible.

(In xen_hvm_init_pc(), a call to xen_register_ioreq() opens another
xenstore, as `state->xenstore`.)

(There's already been effort to build QEMU without legacy backends, that
stubdom check would break in this scenario.)

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Tue Mar 26 17:30:29 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Mar 2024 17:30:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698192.1089636 (Exim 4.92)
	(envelope-from )
	id 1rpAcw-0007n9-08; Tue, 26 Mar 2024 17:30:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698192.1089636; Tue, 26 Mar 2024 17:30:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpAcv-0007n2-SO; Tue, 26 Mar 2024 17:30:21 +0000
Received: by outflank-mailman (input) for mailman id 698192;
 Tue, 26 Mar 2024 17:30:20 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpAcu-0007mw-Fe
 for xen-devel@lists.xenproject.org; Tue, 26 Mar 2024 17:30:20 +0000
Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com
 [2a00:1450:4864:20::52f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 83b1369c-eb96-11ee-a1ef-f123f15fe8a2;
 Tue, 26 Mar 2024 18:30:18 +0100 (CET)
Received: by mail-ed1-x52f.google.com with SMTP id
 4fb4d7f45d1cf-56c3689ad2cso476117a12.1
 for ; Tue, 26 Mar 2024 10:30:18 -0700 (PDT)
Received: from perard.uk.xensource.com (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 u1-20020a1709063b8100b00a46fbff47a6sm4421282ejf.168.2024.03.26.10.30.16
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 26 Mar 2024 10:30:17 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 83b1369c-eb96-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1711474218; x=1712079018; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=uNR6ZmVTy1I7k4lM5R/62hpX5yWv9KwM07BigfA2l7o=;
        b=a9ZmXuCLBlvdeyaHqs0Vn+WYgGS38DRWv+56y8+9u9+JUChRj7l+0bnSp88fovIiqa
         P+zojua3gdBaubX24Qe2dZ2X0DVqmKbi6vNa8cvO5owbzQm01cqhA4ywkz+ax76YGKWE
         6u27MYNOvB41O1oqojMQkGSKgZBP4UdOZ+aww=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711474218; x=1712079018;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=uNR6ZmVTy1I7k4lM5R/62hpX5yWv9KwM07BigfA2l7o=;
        b=sJgZSq4MxslS9LVYB8BRMg00oMRnDwJWnccDrphvUBZj29a7Fgnl6SAeW1/W2u0IRq
         VNKDJz5MB9xdX4Q0hR1V2vaIJHtOojNZxCz1P+z0d1BWRU8lCAs0HVaUtxdRJmEfamZb
         85FbzloWsNJjTYFXtZg0X5cJ2ygp7+/PSzbLpenUJtYVKwu3FoFzq/RKhSPSwFLWo/uc
         86I3fmNO8opSNAZ1z1bP2aLWRDf3NtgvXORO+P7bM4Y2dgiLQaUE1pztf6xRG3qwL5bt
         b+agJ1qvrxWwwjZzPwR6KQhEXFHX4tKmSCXPT9OwKczOhWU3T1HTwgt7arv/wIBYbY+K
         ofkQ==
X-Forwarded-Encrypted: i=1; AJvYcCWK8CTF4tWQaYDqBKgS6CJmOoQdt4SJK+IduwQ/zhHVxg3GqyUsaOd16VrKQPDoguEoqkR37P5C40aINSYosTLI9iKT1wcbeRGfBWMT1tY=
X-Gm-Message-State: AOJu0YzSYjhl31X7ZkFPFG/S4WtCmD7eCuBmeuavO4JGBn8+9jsGur6w
	MNnEwcBwBqTB6CHpkHvLP0EU41VsMbYf6dyM+7c1ua0kx/SLL9OntPVjFOzDmew=
X-Google-Smtp-Source: AGHT+IED9REL4AtbJHtg5KJCIkZv/TLyb2w+DD5qURrER6A4z01CVxLs3y3++VhhpbvvZ6RL62iyHw==
X-Received: by 2002:a17:906:29cd:b0:a47:5103:2d3 with SMTP id y13-20020a17090629cd00b00a47510302d3mr2629185eje.9.1711474217734;
        Tue, 26 Mar 2024 10:30:17 -0700 (PDT)
Date: Tue, 26 Mar 2024 17:30:16 +0000
From: Anthony PERARD 
To: Marek =?iso-8859-1?Q?Marczykowski-G=F3recki?= 
Cc: qemu-devel@nongnu.org, Jason Andryuk ,
	=?iso-8859-1?Q?Fr=E9d=E9ric_Pierret_=28fepitre=29?= ,
	Stefano Stabellini ,
	Paul Durrant ,
	"open list:X86 Xen CPUs" 
Subject: Re: [PATCH v2 2/2] xen: fix stubdom PCI addr
Message-ID: <26006034-dc36-48ff-991b-898596bc2351@perard>
References: <20240305191312.321127-1-marmarek@invisiblethingslab.com>
 <20240305191312.321127-2-marmarek@invisiblethingslab.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20240305191312.321127-2-marmarek@invisiblethingslab.com>

First things first, could you fix the coding style?

Run something like `./scripts/checkpatch.pl @^..` or
`./scripts/checkpatch.pl master..`. Patchew might have run that for you
if the patch series had a cover letter.

On Tue, Mar 05, 2024 at 08:12:30PM +0100, Marek Marczykowski-Grecki wrote:
> diff --git a/hw/xen/xen-host-pci-device.c b/hw/xen/xen-host-pci-device.c
> index 8c6e9a1716..8ea2a5a4af 100644
> --- a/hw/xen/xen-host-pci-device.c
> +++ b/hw/xen/xen-host-pci-device.c
> @@ -9,6 +9,8 @@
>  #include "qemu/osdep.h"
>  #include "qapi/error.h"
>  #include "qemu/cutils.h"
> +#include "hw/xen/xen-legacy-backend.h"

I'd like to avoid this header here, that would be complicated at the
moment, as the global variable `xenstore` would be missing. So for now,
that's fine. I guess that could be rework if something like Philippe
talked about at
https://lore.kernel.org/qemu-devel/429a5a27-21b9-45bd-a1a6-a1c2ccc484c9@linaro.org/
materialise.


Beside the coding style, the patch looks file.

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Tue Mar 26 19:02:32 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Mar 2024 19:02:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698196.1089646 (Exim 4.92)
	(envelope-from )
	id 1rpC3t-00047z-A9; Tue, 26 Mar 2024 19:02:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698196.1089646; Tue, 26 Mar 2024 19:02:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpC3t-00047s-79; Tue, 26 Mar 2024 19:02:17 +0000
Received: by outflank-mailman (input) for mailman id 698196;
 Tue, 26 Mar 2024 19:02:16 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpC3s-00047k-GG
 for xen-devel@lists.xenproject.org; Tue, 26 Mar 2024 19:02:16 +0000
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com
 [2a00:1450:4864:20::633])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5aef4a9d-eba3-11ee-a1ef-f123f15fe8a2;
 Tue, 26 Mar 2024 20:02:13 +0100 (CET)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-a46cd9e7fcaso707244366b.1
 for ; Tue, 26 Mar 2024 12:02:13 -0700 (PDT)
Received: from [172.20.10.2] (public-gprs369548.centertel.pl. [37.47.74.205])
 by smtp.gmail.com with ESMTPSA id
 ef7-20020a17090697c700b00a474df4cda5sm3503810ejb.167.2024.03.26.12.02.11
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 26 Mar 2024 12:02:12 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5aef4a9d-eba3-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1711479733; x=1712084533; darn=lists.xenproject.org;
        h=mime-version:user-agent:content-transfer-encoding:references
         :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject
         :date:message-id:reply-to;
        bh=6kwv/k7oQgPWypCKyfa0Rg16DfxZ8s4+mjKEOz4Eh8c=;
        b=SWXUlAc+JpX1l7b9HaQduw+EAVxF+hW1bpWfh/FI8iz+o4ifitvnY96EL4ZH1nRttM
         wkv9LGciT2zQI5WNswd9s4/WnkylRByRH0TEUceTvbUhwgJrLSstn33/8UpQBfyFJIut
         BG9KWs11gvS/iPszobZzmD3+gwg/xS4pc/xEyD3nL9n6QnxbKF89k7+eOgNrSh8PVrQa
         LcjeeQcMJhKO8Z7Qd5p21VNlscq5XizbTk2Jom7VZ9RsN4uTRksrrxL2AXgStzdu2neq
         Ay2nnxj1EiAwjc/5mh8hgmWw8893YU3hlPrRORo23s93Wb9enbHOWU8Y2LzfhMb78r71
         tvhw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711479733; x=1712084533;
        h=mime-version:user-agent:content-transfer-encoding:references
         :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=6kwv/k7oQgPWypCKyfa0Rg16DfxZ8s4+mjKEOz4Eh8c=;
        b=edXUb2ROuQ/VeyzlhOAmLg69TGXFUwjX7X8z4AZfPqP02jj4f2nAdB3MwqSvf9OP0C
         RJIBSNf2cI30H5lkrvJ+QIZn2qDFHFFnhS6zMzqpwA8Nt501l/R735rG/mEd7iua/IGw
         DdVUkN/BxOx16VXLUXjXebthVwrUy1MXpWKQCnGNw5WI1RQ/OeFgGog/RqL9lIRsS3c5
         2+LihAAY/QYlxRNGqFDqHxwHvIj32o+Xz4F2ar2m2ibqIEJLbi5EYmmnsg6H4YMHpYls
         KePGTB/oQ4F/iElTV5HAlBYW6OTd+kP2yLr0eVjnXmL0zY4G7z26XONXCxbYH+Biu42s
         vHIQ==
X-Forwarded-Encrypted: i=1; AJvYcCWtEL3PlE/exlVMFgPUPIk7nZvr/YBoScwegh9hjSFepLtlBdFBdpr7sUkgjCisUocQ1Wp3UWTmv5edDlaldCb5Zi0mx/3R2Im+yzFn7PQ=
X-Gm-Message-State: AOJu0YykfnvkF4ySyC9fEai28haMPz22qKzDEvqw0cJ3UTTWmrIZFG9M
	BrX4HVeRzl+k20k2AGx0ItzmCYx6qKUxgU9doNrukjK7hrwwFClH
X-Google-Smtp-Source: AGHT+IFtr91q2nm2bDIdkjl9YqMo4+3iNDzj1EtCEvxT4y1yvjBBr6riJ0YobALsfWS3XSCHxowGPg==
X-Received: by 2002:a17:906:6d91:b0:a47:669:d0f2 with SMTP id h17-20020a1709066d9100b00a470669d0f2mr8734393ejt.50.1711479732443;
        Tue, 26 Mar 2024 12:02:12 -0700 (PDT)
Message-ID: <38de6dd8e9555fe4b573f9c2134a618a60c224df.camel@gmail.com>
Subject: Re: [PATCH v6 10/20] xen/riscv: introduce atomic.h
From: Oleksii 
To: Jan Beulich 
Cc: Alistair Francis , Bob Eshleman
 , Connor Davis , Andrew
 Cooper , George Dunlap
 ,  Julien Grall , Stefano
 Stabellini , Wei Liu , 
 xen-devel@lists.xenproject.org
Date: Tue, 26 Mar 2024 20:02:10 +0100
In-Reply-To: <1a440fbf-f37c-41fe-b31c-0afe0fd77c8e@suse.com>
References: 
	 <22ee9c8cc62c76cfb799fed800636e7c8bf25a17.1710517542.git.oleksii.kurochko@gmail.com>
	 <78a86041-72e2-410f-b6a7-212656b0dba3@suse.com>
	 
	 <1a440fbf-f37c-41fe-b31c-0afe0fd77c8e@suse.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.50.2 (3.50.2-1.fc39) 
MIME-Version: 1.0

On Mon, 2024-03-25 at 09:18 +0100, Jan Beulich wrote:
> On 22.03.2024 13:25, Oleksii wrote:
> > On Thu, 2024-03-21 at 14:03 +0100, Jan Beulich wrote:
> > > On 15.03.2024 19:06, Oleksii Kurochko wrote:
> > > > + */
> > > > +static always_inline void read_atomic_size(const volatile void
> > > > *p,
> > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 void *res,
> > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 unsigned int size)
> > > > +{
> > > > +=C2=A0=C2=A0=C2=A0 switch ( size )
> > > > +=C2=A0=C2=A0=C2=A0 {
> > > > +=C2=A0=C2=A0=C2=A0 case 1: *(uint8_t *)res =3D readb(p); break;
> > > > +=C2=A0=C2=A0=C2=A0 case 2: *(uint16_t *)res =3D readw(p); break;
> > > > +=C2=A0=C2=A0=C2=A0 case 4: *(uint32_t *)res =3D readl(p); break;
> > > > +=C2=A0=C2=A0=C2=A0 case 8: *(uint32_t *)res=C2=A0 =3D readq(p); br=
eak;
> > >=20
> > > Nit: Excess blank before =3D.
> > >=20
> > > Also - no #ifdef here to be RV32-ready?
> > Because there is #ifdef RV32 in io.h for readq().
>=20
> There you'd run into __raw_readq()'s BUILD_BUG_ON(), afaict even for
> 1-, 2-, or 4-byte accesses. That's not quite what we want here.
Do you mean that if someone will redefine readq() in another way and
not wrap it by #ifdef RV32? Except this I am not sure that there is an
issue as it will be still a compilation error, so anyway it will be
needed to provide an implementation for __raw_readq().

One of the reason why I decided to wrap with #ifdef RV32 in io.h to not
go over the source code and add wrapping. Also for some code it will be
needed to rewrite it. For example, I am not sure that I can add #ifdef
inside macros, f.e.:
   #define write_atomic(p, x)                              \
   ({                                                      \
       typeof(*(p)) x__ =3D (x);                             \
       switch ( sizeof(*(p)) )                             \
       {                                                   \
       case 1: writeb(x__, p); break;                      \
       case 2: writew(x__, p); break;                      \
       case 4: writel(x__, p); break;                      \
       case 8: writeq(x__, p); break;                      \
       default: __bad_atomic_size(); break;                \
       }                                                   \
       x__;                                                \
   })

>=20
> > > > +/*
> > > > + * First, the atomic ops that have no ordering constraints and
> > > > therefor don't
> > > > + * have the AQ or RL bits set.=C2=A0 These don't return anything,
> > > > so
> > > > there's only
> > > > + * one version to worry about.
> > > > + */
> > > > +#define ATOMIC_OP(op, asm_op, I, asm_type, c_type, prefix)=C2=A0 \
> > > > +static inline=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 \
> > > > +void atomic##prefix##_##op(c_type i, atomic##prefix##_t *v) \
> > > > +{=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 \
> > > > +=C2=A0=C2=A0=C2=A0 asm volatile (=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 \
> > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "=C2=A0=C2=A0 amo" #asm=
_op "." #asm_type " zero, %1, %0"=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 \
> > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : "+A" (v->counter)=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 \
> > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : "r" (I)=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 \
> > >=20
> > > Btw, I consider this pretty confusing. At the 1st and 2nd glance
> > > this
> > > looks like a mistake, i.e. as if i was meant. Imo ...
> > >=20
> > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : "memory" );=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 \
> > > > +}=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 \
> > > > +
> > > > +/*
> > > > + * Only CONFIG_GENERIC_ATOMIC64=3Dy was ported to Xen that is
> > > > the
> > > > reason why
> > > > + * last argument for ATOMIC_OP isn't used.
> > > > + */
> > > > +#define ATOMIC_OPS(op, asm_op, I)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 \
> > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ATOMIC_OP (op, asm_op, =
I, w, int,=C2=A0=C2=A0 )
> > > > +
> > > > +ATOMIC_OPS(add, add,=C2=A0 i)
> > > > +ATOMIC_OPS(sub, add, -i)
> > > > +ATOMIC_OPS(and, and,=C2=A0 i)
> > > > +ATOMIC_OPS( or,=C2=A0 or,=C2=A0 i)
> > > > +ATOMIC_OPS(xor, xor,=C2=A0 i)
> > >=20
> > > ... here you want to only pass the (unary) operator (and leaving
> > > that
> > > blank
> > > is as fine as using +).
> > I agree that a game with 'i' and 'I' looks confusing, but I am not
> > really understand what is wrong with using ' i' here. It seems that
> > preprocessed macros looks fine:
> > =C2=A0=C2=A0 static inline void atomic_add(int i, atomic_t *v) { asm vo=
latile
> > ( "=C2=A0=20
> > =C2=A0=C2=A0 amo" "add" "." "w" " zero, %1, %0" : "+A" (v->counter) : "=
r" (i)
> > :
> > =C2=A0=C2=A0 "memory" ); }
> > =C2=A0=C2=A0=20
> > =C2=A0=C2=A0 static inline void atomic_sub(int i, atomic_t *v) { asm vo=
latile
> > ( "=C2=A0=20
> > =C2=A0=C2=A0 amo" "add" "." "w" " zero, %1, %0" : "+A" (v->counter) : "=
r" (-
> > i) :
> > =C2=A0=C2=A0 "memory" ); }
>=20
> I didn't question the pre-processed result being correct. Instead I
> said
> that I consider the construct confusing to the reader, for looking as
> if
> there was a mistake (in the case of the letter i used). Note also in
> particular how the macro invocations need to be in sync with the
> macro
> implementation, for lower case i being used both in the macro and in
> its
> invocations. Anything parameterized would better be fully so, at the
> very least to avoid, as said, confusion. (Having macros depend on
> context at their use sites _may_ be okay for local helper macros, but
> here we're talking about a not even private header file.)
I am not sure then I understand how mentioning '+i' will help
significantly remove confusion.

>=20
> > > > +/* This is required to provide a full barrier on success. */
> > > > +static inline int atomic_add_unless(atomic_t *v, int a, int u)
> > > > +{
> > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int prev, rc;
> > > > +
> > > > +=C2=A0=C2=A0=C2=A0 asm volatile (
> > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "0: lr.w=C2=A0=C2=A0=C2=
=A0=C2=A0 %[p],=C2=A0 %[c]\n"
> > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "=C2=A0=C2=A0 beq=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 %[p],=C2=A0 %[u], 1f\n"
> > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "=C2=A0=C2=A0 add=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 %[rc], %[p], %[a]\n"
> > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "=C2=A0=C2=A0 sc.w.rl=
=C2=A0 %[rc], %[rc], %[c]\n"
> > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "=C2=A0=C2=A0 bnez=C2=
=A0=C2=A0=C2=A0=C2=A0 %[rc], 0b\n"
> > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RISCV_FULL_BARRIER
> > >=20
> > > With this and no .aq on the load, why the .rl on the store?
> > It is something that LKMM requires [1].
> >=20
> > This is not fully clear to me what is so specific in LKMM, but
> > accoring
> > to the spec:
> > =C2=A0=C2=A0 Ordering Annotation Fence-based Equivalent
> > =C2=A0=C2=A0 l{b|h|w|d|r}.aq=C2=A0=C2=A0=C2=A0=C2=A0 l{b|h|w|d|r}; fenc=
e r,rw
> > =C2=A0=C2=A0 l{b|h|w|d|r}.aqrl=C2=A0=C2=A0 fence rw,rw; l{b|h|w|d|r}; f=
ence r,rw
> > =C2=A0=C2=A0 s{b|h|w|d|c}.rl=C2=A0=C2=A0=C2=A0=C2=A0 fence rw,w; s{b|h|=
w|d|c}
> > =C2=A0=C2=A0 s{b|h|w|d|c}.aqrl=C2=A0=C2=A0 fence rw,w; s{b|h|w|d|c}
> > =C2=A0=C2=A0 amo.aq=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 amo; fence r,rw
> > =C2=A0=C2=A0 amo.rl=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 fence rw,w; amo
> > =C2=A0=C2=A0 amo.aqrl=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 fen=
ce rw,rw; amo; fence rw,rw
> > =C2=A0=C2=A0 Table 2.2: Mappings from .aq and/or .rl to fence-based
> > equivalents.
> > =C2=A0=C2=A0 An alternative mapping places a fence rw,rw after the exis=
ting=20
> > =C2=A0=C2=A0 s{b|h|w|d|c} mapping rather than at the front of the
> > =C2=A0=C2=A0 l{b|h|w|d|r} mapping.
>=20
> I'm afraid I can't spot the specific case in this table. None of the
> stores in the right column have a .rl suffix.
Yes, it is expected.

I am reading this table as (f.e.) amo.rl is an equivalent of fence
rw,w; amo. (without .rl)=20

>=20
> > =C2=A0=C2=A0 It is also safe to translate any .aq, .rl, or .aqrl annota=
tion
> > into
> > =C2=A0=C2=A0 the fence-based snippets of
> > =C2=A0=C2=A0 Table 2.2. These can also be used as a legal implementatio=
n of
> > =C2=A0=C2=A0 l{b|h|w|d} or s{b|h|w|d} pseu-
> > =C2=A0=C2=A0 doinstructions for as long as those instructions are not a=
dded
> > to
> > =C2=A0=C2=A0 the ISA.
> >=20
> > So according to the spec, it should be:
> > =C2=A0sc.w ...
> > =C2=A0RISCV_FULL_BARRIER.
> >=20
> > Considering [1] and how this code looks before, it seems to me that
> > it
> > is safe to use lr.w.aq/sc.w.rl here or an fence equivalent.
>=20
> Here you say "or". Then why dos the code use sc.?.rl _and_ a fence?
I confused this line with amo.aqrl, so based on the table 2.2 above
s{b|h|w|d|c}.aqrl is transformed to "fence rw,w; s{b|h|w|d|c}", but
Linux kernel decided to strengthen it with full barrier:
   -              "0:\n\t"
   -              "lr.w.aqrl  %[p],  %[c]\n\t"
   -              "beq        %[p],  %[u], 1f\n\t"
   -              "add       %[rc],  %[p], %[a]\n\t"
   -              "sc.w.aqrl %[rc], %[rc], %[c]\n\t"
   -              "bnez      %[rc], 0b\n\t"
   -              "1:"
   +               "0:     lr.w     %[p],  %[c]\n"
   +               "       beq      %[p],  %[u], 1f\n"
   +               "       add      %[rc], %[p], %[a]\n"
   +               "       sc.w.rl  %[rc], %[rc], %[c]\n"
   +               "       bnez     %[rc], 0b\n"
   +               "       fence    rw, rw\n"
   +               "1:\n"
As they have the following issue:
   implementations of atomics such as atomic_cmpxchg() and
   atomic_add_unless() rely on LR/SC pairs,
   which do not give full-ordering with .aqrl; for example, current
   implementations allow the "lr-sc-aqrl-pair-vs-full-barrier" test
   below to end up with the state indicated in the "exists" clause.

>=20
> > But in general it ( a combination of fence, .aq, .rl ) can be
> > considered as the same things in this context, so it is possible to
> > leave this function as is to be synced here with Linux kernel.
>=20
> In turn I also don't understand this. Yes, the excess .rl certainly
> doesn't render things unsafe. But what's the purpose of the .rl?
> That's
> what my original question boiled down to.
I don't know, either. As I mentioned before, it is enough ( in my
opinion ) to have a FULL barrier or .aq,.rl or .aqrl/.aqrl ( if it
needed to be strengthened) like it was done before in Linux.
It seems to me it is LKMM specific that they need more to be more
strengthened as it RISC-V Memory model requires because:
"sc.w ; fence rw, rw" does not guarantee that all previous reads and
writes finish before the sc itself is globally visible, which might
matter if the sc is unlocking a lock or something.

Despite of the fact, for compare-and-swap loops, RISC-V international
recommends lr.w.aq/lr.d.aq followed by sc.w.rl/sc.d.rl ( as it was
implemeted before in Linux kernel ) I am okay just for safety reasons
and for the reason I mentioned at the last sentence of previous
paragraph to strengthen implementations with fences.

~ Oleksii
>=20
> Jan
>=20
> > [1]
> > https://lore.kernel.org/lkml/1520274276-21871-1-git-send-email-parri.an=
drea@gmail.com
> > /
> >=20
> > ~ Oleksii
>=20



From xen-devel-bounces@lists.xenproject.org Tue Mar 26 21:24:50 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Mar 2024 21:24:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698204.1089655 (Exim 4.92)
	(envelope-from )
	id 1rpEHc-0003kZ-3P; Tue, 26 Mar 2024 21:24:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698204.1089655; Tue, 26 Mar 2024 21:24:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpEHc-0003kS-0q; Tue, 26 Mar 2024 21:24:36 +0000
Received: by outflank-mailman (input) for mailman id 698204;
 Tue, 26 Mar 2024 21:24:34 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpEHa-0003kM-8b
 for xen-devel@lists.xenproject.org; Tue, 26 Mar 2024 21:24:34 +0000
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com
 [2a00:1450:4864:20::52a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3c223017-ebb7-11ee-a1ef-f123f15fe8a2;
 Tue, 26 Mar 2024 22:24:31 +0100 (CET)
Received: by mail-ed1-x52a.google.com with SMTP id
 4fb4d7f45d1cf-56c36c67deaso544437a12.0
 for ; Tue, 26 Mar 2024 14:24:31 -0700 (PDT)
Received: from [192.168.206.239] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 bw2-20020a170906c1c200b00a471b5b25b9sm4617355ejb.127.2024.03.26.14.24.29
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 26 Mar 2024 14:24:30 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3c223017-ebb7-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1711488271; x=1712093071; darn=lists.xenproject.org;
        h=mime-version:user-agent:content-transfer-encoding:references
         :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject
         :date:message-id:reply-to;
        bh=WY1plg6vAUH+iSezpTOXhV/uopE5bo1lAWMA+3zmDio=;
        b=mlG2ajhmEEGlcf9iBIwncdcZjNfUTjrMSmeLWrVL8Wbj51oSgjuDRf467HLPLpeU4t
         3chPD0VbxSDNhkjMr+rMPS6ub4vmRfp5U0dfiAjczrR1jRbCBERyJc8xpBtieivK+scT
         uzk71wogWmstcdb4ynou6Y+5o+vQacEaeiWKE0Q4oY72Y90R151mO+OlnNft1TEwTFR3
         uLln2iyvFqh2RcxxiLbF5M/0D04rv9svCDO14NWsZm2wa3EGomgCxlw8GjBGsHAo+apk
         LBa61HQ5wxZ2wUIykYgfhc8juHcnSv1H2di0W/o6+geZZtqO9R509tDYtNtbyQ0u0JFe
         buRA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711488271; x=1712093071;
        h=mime-version:user-agent:content-transfer-encoding:references
         :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=WY1plg6vAUH+iSezpTOXhV/uopE5bo1lAWMA+3zmDio=;
        b=apzoV7UFAjkwdRBHdi59UeQuaBGn63+mQCQiqWdoU3rFNoTjQeGEOECj6rUcO0sUW+
         8u18fS+wOylmMoptaPKv5CsKU5+GvJcgLUCWIXeUYGPYgDA8x3B46oVPysHAGUc539Wf
         vLTdBoDlL/7P7XceOOKcqLunn8kvESr6zRcIrKYTwN26igvSF7GAASlUwtr4B4iQksjo
         HQsRdGTWB5gIQATDbGBn7v2brVIDr6qFZBuj841rDrP0LZMFxYW9d2H/15qwOBeqa1Z+
         MnUBSxL5Wd4JVmXF4ZBZCIeGKYNkBcYBGKJ1h8TNVCLEMHg8Zwi1dMa6u8ynP+fE/hPA
         zFgw==
X-Forwarded-Encrypted: i=1; AJvYcCV9DKH1LFTZb4Kc2ahciYE8ZM+wWFUakqtEvEXOfj8CjzV37S5RT8vaT3R2T6QxbYQjsv5/Jtw0rOyrUG/2cPBJtvMTHPH6PQ61DZ/Dy2Y=
X-Gm-Message-State: AOJu0YwrPB4kvn1uDkcnJ+yxS4eH7roZxC5sOj7VSMB7WiFXgVFcT5xy
	8k83lhpunSuJP+4psjgEqLoNYjLjy3zVf3lcvDKOraCmTn3/mrnx
X-Google-Smtp-Source: AGHT+IHhtl26SpS9za6GayDnle17gDEFDOaD4Fmj9eJ1BvpoQo3ubUQq1fpiTTcMcK0pk/c0qSzx7Q==
X-Received: by 2002:a17:906:5914:b0:a47:3651:a302 with SMTP id h20-20020a170906591400b00a473651a302mr7049654ejq.42.1711488270807;
        Tue, 26 Mar 2024 14:24:30 -0700 (PDT)
Message-ID: <5839517e4e36234b4a0ed189b12eb1210c1a56e2.camel@gmail.com>
Subject: Re: [PATCH v6 10/20] xen/riscv: introduce atomic.h
From: Oleksii 
To: Jan Beulich 
Cc: Alistair Francis , Bob Eshleman
 , Connor Davis , Andrew
 Cooper , George Dunlap
 ,  Julien Grall , Stefano
 Stabellini , Wei Liu , 
 xen-devel@lists.xenproject.org
Date: Tue, 26 Mar 2024 22:24:29 +0100
In-Reply-To: <38de6dd8e9555fe4b573f9c2134a618a60c224df.camel@gmail.com>
References: 
	 <22ee9c8cc62c76cfb799fed800636e7c8bf25a17.1710517542.git.oleksii.kurochko@gmail.com>
	 <78a86041-72e2-410f-b6a7-212656b0dba3@suse.com>
	 
	 <1a440fbf-f37c-41fe-b31c-0afe0fd77c8e@suse.com>
	 <38de6dd8e9555fe4b573f9c2134a618a60c224df.camel@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
User-Agent: Evolution 3.50.2 (3.50.2-1.fc39) 
MIME-Version: 1.0

T24gVHVlLCAyMDI0LTAzLTI2IGF0IDIwOjAyICswMTAwLCBPbGVrc2lpIHdyb3RlOgo+IE9uIE1v
biwgMjAyNC0wMy0yNSBhdCAwOToxOCArMDEwMCwgSmFuIEJldWxpY2ggd3JvdGU6Cj4gPiBPbiAy
Mi4wMy4yMDI0IDEzOjI1LCBPbGVrc2lpIHdyb3RlOgo+ID4gPiBPbiBUaHUsIDIwMjQtMDMtMjEg
YXQgMTQ6MDMgKzAxMDAsIEphbiBCZXVsaWNoIHdyb3RlOgo+ID4gPiA+IE9uIDE1LjAzLjIwMjQg
MTk6MDYsIE9sZWtzaWkgS3Vyb2Noa28gd3JvdGU6Cj4gPiA+ID4gPiArICovCj4gPiA+ID4gPiAr
c3RhdGljIGFsd2F5c19pbmxpbmUgdm9pZCByZWFkX2F0b21pY19zaXplKGNvbnN0IHZvbGF0aWxl
Cj4gPiA+ID4gPiB2b2lkCj4gPiA+ID4gPiAqcCwKPiA+ID4gPiA+ICvCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqAgdm9pZCAqcmVzLAo+ID4gPiA+ID4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoCB1bnNpZ25lZCBpbnQKPiA+ID4gPiA+IHNpemUpCj4gPiA+ID4gPiArewo+ID4gPiA+ID4g
K8KgwqDCoCBzd2l0Y2ggKCBzaXplICkKPiA+ID4gPiA+ICvCoMKgwqAgewo+ID4gPiA+ID4gK8Kg
wqDCoCBjYXNlIDE6ICoodWludDhfdCAqKXJlcyA9IHJlYWRiKHApOyBicmVhazsKPiA+ID4gPiA+
ICvCoMKgwqAgY2FzZSAyOiAqKHVpbnQxNl90ICopcmVzID0gcmVhZHcocCk7IGJyZWFrOwo+ID4g
PiA+ID4gK8KgwqDCoCBjYXNlIDQ6ICoodWludDMyX3QgKilyZXMgPSByZWFkbChwKTsgYnJlYWs7
Cj4gPiA+ID4gPiArwqDCoMKgIGNhc2UgODogKih1aW50MzJfdCAqKXJlc8KgID0gcmVhZHEocCk7
IGJyZWFrOwo+ID4gPiA+IAo+ID4gPiA+IE5pdDogRXhjZXNzIGJsYW5rIGJlZm9yZSA9Lgo+ID4g
PiA+IAo+ID4gPiA+IEFsc28gLSBubyAjaWZkZWYgaGVyZSB0byBiZSBSVjMyLXJlYWR5Pwo+ID4g
PiBCZWNhdXNlIHRoZXJlIGlzICNpZmRlZiBSVjMyIGluIGlvLmggZm9yIHJlYWRxKCkuCj4gPiAK
PiA+IFRoZXJlIHlvdSdkIHJ1biBpbnRvIF9fcmF3X3JlYWRxKCkncyBCVUlMRF9CVUdfT04oKSwg
YWZhaWN0IGV2ZW4KPiA+IGZvcgo+ID4gMS0sIDItLCBvciA0LWJ5dGUgYWNjZXNzZXMuIFRoYXQn
cyBub3QgcXVpdGUgd2hhdCB3ZSB3YW50IGhlcmUuCj4gRG8geW91IG1lYW4gdGhhdCBpZiBzb21l
b25lIHdpbGwgcmVkZWZpbmUgcmVhZHEoKSBpbiBhbm90aGVyIHdheSBhbmQKPiBub3Qgd3JhcCBp
dCBieSAjaWZkZWYgUlYzMj8gRXhjZXB0IHRoaXMgSSBhbSBub3Qgc3VyZSB0aGF0IHRoZXJlIGlz
Cj4gYW4KPiBpc3N1ZSBhcyBpdCB3aWxsIGJlIHN0aWxsIGEgY29tcGlsYXRpb24gZXJyb3IsIHNv
IGFueXdheSBpdCB3aWxsIGJlCj4gbmVlZGVkIHRvIHByb3ZpZGUgYW4gaW1wbGVtZW50YXRpb24g
Zm9yIF9fcmF3X3JlYWRxKCkuCj4gCj4gT25lIG9mIHRoZSByZWFzb24gd2h5IEkgZGVjaWRlZCB0
byB3cmFwIHdpdGggI2lmZGVmIFJWMzIgaW4gaW8uaCB0bwo+IG5vdAo+IGdvIG92ZXIgdGhlIHNv
dXJjZSBjb2RlIGFuZCBhZGQgd3JhcHBpbmcuIEFsc28gZm9yIHNvbWUgY29kZSBpdCB3aWxsCj4g
YmUKPiBuZWVkZWQgdG8gcmV3cml0ZSBpdC4gRm9yIGV4YW1wbGUsIEkgYW0gbm90IHN1cmUgdGhh
dCBJIGNhbiBhZGQKPiAjaWZkZWYKPiBpbnNpZGUgbWFjcm9zLCBmLmUuOgo+IMKgwqAgI2RlZmlu
ZSB3cml0ZV9hdG9taWMocCwgeCnCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgIFwKPiDCoMKgICh7wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBcCj4gwqDCoMKgwqDCoMKgIHR5cGVvZigqKHApKSB4
X18gPSAoeCk7wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqAgXAo+IMKgwqDCoMKgwqDCoCBzd2l0Y2ggKCBzaXplb2YoKihwKSkgKcKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFwKPiDCoMKg
wqDCoMKgwqAge8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgXAo+
IMKgwqDCoMKgwqDCoCBjYXNlIDE6IHdyaXRlYih4X18sIHApOyBicmVhazvCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgXAo+IMKgwqDCoMKgwqDCoCBjYXNlIDI6IHdy
aXRldyh4X18sIHApOyBicmVhazvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqAgXAo+IMKgwqDCoMKgwqDCoCBjYXNlIDQ6IHdyaXRlbCh4X18sIHApOyBicmVhazvCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgXAo+IMKgwqDCoMKgwqDCoCBj
YXNlIDg6IHdyaXRlcSh4X18sIHApOyBicmVhazvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqAgXAo+IMKgwqDCoMKgwqDCoCBkZWZhdWx0OiBfX2JhZF9hdG9taWNfc2l6
ZSgpOyBicmVhazvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgXAo+IMKgwqDCoMKgwqDC
oCB9wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBcCj4gwqDCoMKg
wqDCoMKgIHhfXzvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFwKPiDCoMKg
IH0pCj4gCj4gPiAKPiA+ID4gPiA+ICsvKgo+ID4gPiA+ID4gKyAqIEZpcnN0LCB0aGUgYXRvbWlj
IG9wcyB0aGF0IGhhdmUgbm8gb3JkZXJpbmcgY29uc3RyYWludHMKPiA+ID4gPiA+IGFuZAo+ID4g
PiA+ID4gdGhlcmVmb3IgZG9uJ3QKPiA+ID4gPiA+ICsgKiBoYXZlIHRoZSBBUSBvciBSTCBiaXRz
IHNldC7CoCBUaGVzZSBkb24ndCByZXR1cm4gYW55dGhpbmcsCj4gPiA+ID4gPiBzbwo+ID4gPiA+
ID4gdGhlcmUncyBvbmx5Cj4gPiA+ID4gPiArICogb25lIHZlcnNpb24gdG8gd29ycnkgYWJvdXQu
Cj4gPiA+ID4gPiArICovCj4gPiA+ID4gPiArI2RlZmluZSBBVE9NSUNfT1Aob3AsIGFzbV9vcCwg
SSwgYXNtX3R5cGUsIGNfdHlwZSwgcHJlZml4KcKgCj4gPiA+ID4gPiBcCj4gPiA+ID4gPiArc3Rh
dGljIGlubGluZcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgCj4gPiA+ID4gPiBc
Cj4gPiA+ID4gPiArdm9pZCBhdG9taWMjI3ByZWZpeCMjXyMjb3AoY190eXBlIGksIGF0b21pYyMj
cHJlZml4IyNfdCAqdikKPiA+ID4gPiA+IFwKPiA+ID4gPiA+ICt7wqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAKPiA+ID4gPiA+IFwKPiA+
ID4gPiA+ICvCoMKgwqAgYXNtIHZvbGF0aWxlICjCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgCj4g
PiA+ID4gPiBcCj4gPiA+ID4gPiArwqDCoMKgwqDCoMKgwqAgIsKgwqAgYW1vIiAjYXNtX29wICIu
IiAjYXNtX3R5cGUgIiB6ZXJvLCAlMSwgJTAiwqDCoMKgwqDCoAo+ID4gPiA+ID4gXAo+ID4gPiA+
ID4gK8KgwqDCoMKgwqDCoMKgIDogIitBIiAodi0+Y291bnRlcinCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgCj4gPiA+ID4gPiBc
Cj4gPiA+ID4gPiArwqDCoMKgwqDCoMKgwqAgOiAiciIgKEkpwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgCj4gPiA+ID4gPiBcCj4gPiA+ID4gCj4gPiA+ID4gQnR3LCBJIGNvbnNpZGVyIHRoaXMg
cHJldHR5IGNvbmZ1c2luZy4gQXQgdGhlIDFzdCBhbmQgMm5kCj4gPiA+ID4gZ2xhbmNlCj4gPiA+
ID4gdGhpcwo+ID4gPiA+IGxvb2tzIGxpa2UgYSBtaXN0YWtlLCBpLmUuIGFzIGlmIGkgd2FzIG1l
YW50LiBJbW8gLi4uCj4gPiA+ID4gCj4gPiA+ID4gPiArwqDCoMKgwqDCoMKgwqAgOiAibWVtb3J5
IiApO8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAKPiA+ID4gPiA+IFwKPiA+ID4gPiA+ICt9wqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAKPiA+ID4g
PiA+IFwKPiA+ID4gPiA+ICsKPiA+ID4gPiA+ICsvKgo+ID4gPiA+ID4gKyAqIE9ubHkgQ09ORklH
X0dFTkVSSUNfQVRPTUlDNjQ9eSB3YXMgcG9ydGVkIHRvIFhlbiB0aGF0IGlzCj4gPiA+ID4gPiB0
aGUKPiA+ID4gPiA+IHJlYXNvbiB3aHkKPiA+ID4gPiA+ICsgKiBsYXN0IGFyZ3VtZW50IGZvciBB
VE9NSUNfT1AgaXNuJ3QgdXNlZC4KPiA+ID4gPiA+ICsgKi8KPiA+ID4gPiA+ICsjZGVmaW5lIEFU
T01JQ19PUFMob3AsIGFzbV9vcCwgSSnCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgCj4gPiA+ID4gPiBcCj4gPiA+ID4gPiArwqDCoMKgwqDCoMKgwqAg
QVRPTUlDX09QIChvcCwgYXNtX29wLCBJLCB3LCBpbnQswqDCoCApCj4gPiA+ID4gPiArCj4gPiA+
ID4gPiArQVRPTUlDX09QUyhhZGQsIGFkZCzCoCBpKQo+ID4gPiA+ID4gK0FUT01JQ19PUFMoc3Vi
LCBhZGQsIC1pKQo+ID4gPiA+ID4gK0FUT01JQ19PUFMoYW5kLCBhbmQswqAgaSkKPiA+ID4gPiA+
ICtBVE9NSUNfT1BTKCBvcizCoCBvcizCoCBpKQo+ID4gPiA+ID4gK0FUT01JQ19PUFMoeG9yLCB4
b3IswqAgaSkKPiA+ID4gPiAKPiA+ID4gPiAuLi4gaGVyZSB5b3Ugd2FudCB0byBvbmx5IHBhc3Mg
dGhlICh1bmFyeSkgb3BlcmF0b3IgKGFuZAo+ID4gPiA+IGxlYXZpbmcKPiA+ID4gPiB0aGF0Cj4g
PiA+ID4gYmxhbmsKPiA+ID4gPiBpcyBhcyBmaW5lIGFzIHVzaW5nICspLgo+ID4gPiBJIGFncmVl
IHRoYXQgYSBnYW1lIHdpdGggJ2knIGFuZCAnSScgbG9va3MgY29uZnVzaW5nLCBidXQgSSBhbQo+
ID4gPiBub3QKPiA+ID4gcmVhbGx5IHVuZGVyc3RhbmQgd2hhdCBpcyB3cm9uZyB3aXRoIHVzaW5n
ICcgaScgaGVyZS4gSXQgc2VlbXMKPiA+ID4gdGhhdAo+ID4gPiBwcmVwcm9jZXNzZWQgbWFjcm9z
IGxvb2tzIGZpbmU6Cj4gPiA+IMKgwqAgc3RhdGljIGlubGluZSB2b2lkIGF0b21pY19hZGQoaW50
IGksIGF0b21pY190ICp2KSB7IGFzbQo+ID4gPiB2b2xhdGlsZQo+ID4gPiAoICLCoCAKPiA+ID4g
wqDCoCBhbW8iICJhZGQiICIuIiAidyIgIiB6ZXJvLCAlMSwgJTAiIDogIitBIiAodi0+Y291bnRl
cikgOiAiciIKPiA+ID4gKGkpCj4gPiA+IDoKPiA+ID4gwqDCoCAibWVtb3J5IiApOyB9Cj4gPiA+
IMKgwqAgCj4gPiA+IMKgwqAgc3RhdGljIGlubGluZSB2b2lkIGF0b21pY19zdWIoaW50IGksIGF0
b21pY190ICp2KSB7IGFzbQo+ID4gPiB2b2xhdGlsZQo+ID4gPiAoICLCoCAKPiA+ID4gwqDCoCBh
bW8iICJhZGQiICIuIiAidyIgIiB6ZXJvLCAlMSwgJTAiIDogIitBIiAodi0+Y291bnRlcikgOiAi
ciIKPiA+ID4gKC0KPiA+ID4gaSkgOgo+ID4gPiDCoMKgICJtZW1vcnkiICk7IH0KPiA+IAo+ID4g
SSBkaWRuJ3QgcXVlc3Rpb24gdGhlIHByZS1wcm9jZXNzZWQgcmVzdWx0IGJlaW5nIGNvcnJlY3Qu
IEluc3RlYWQgSQo+ID4gc2FpZAo+ID4gdGhhdCBJIGNvbnNpZGVyIHRoZSBjb25zdHJ1Y3QgY29u
ZnVzaW5nIHRvIHRoZSByZWFkZXIsIGZvciBsb29raW5nCj4gPiBhcwo+ID4gaWYKPiA+IHRoZXJl
IHdhcyBhIG1pc3Rha2UgKGluIHRoZSBjYXNlIG9mIHRoZSBsZXR0ZXIgaSB1c2VkKS4gTm90ZSBh
bHNvCj4gPiBpbgo+ID4gcGFydGljdWxhciBob3cgdGhlIG1hY3JvIGludm9jYXRpb25zIG5lZWQg
dG8gYmUgaW4gc3luYyB3aXRoIHRoZQo+ID4gbWFjcm8KPiA+IGltcGxlbWVudGF0aW9uLCBmb3Ig
bG93ZXIgY2FzZSBpIGJlaW5nIHVzZWQgYm90aCBpbiB0aGUgbWFjcm8gYW5kCj4gPiBpbgo+ID4g
aXRzCj4gPiBpbnZvY2F0aW9ucy4gQW55dGhpbmcgcGFyYW1ldGVyaXplZCB3b3VsZCBiZXR0ZXIg
YmUgZnVsbHkgc28sIGF0Cj4gPiB0aGUKPiA+IHZlcnkgbGVhc3QgdG8gYXZvaWQsIGFzIHNhaWQs
IGNvbmZ1c2lvbi4gKEhhdmluZyBtYWNyb3MgZGVwZW5kIG9uCj4gPiBjb250ZXh0IGF0IHRoZWly
IHVzZSBzaXRlcyBfbWF5XyBiZSBva2F5IGZvciBsb2NhbCBoZWxwZXIgbWFjcm9zLAo+ID4gYnV0
Cj4gPiBoZXJlIHdlJ3JlIHRhbGtpbmcgYWJvdXQgYSBub3QgZXZlbiBwcml2YXRlIGhlYWRlciBm
aWxlLikKPiBJIGFtIG5vdCBzdXJlIHRoZW4gSSB1bmRlcnN0YW5kIGhvdyBtZW50aW9uaW5nICcr
aScgd2lsbCBoZWxwCj4gc2lnbmlmaWNhbnRseSByZW1vdmUgY29uZnVzaW9uLgo+IAo+ID4gCj4g
PiA+ID4gPiArLyogVGhpcyBpcyByZXF1aXJlZCB0byBwcm92aWRlIGEgZnVsbCBiYXJyaWVyIG9u
IHN1Y2Nlc3MuICovCj4gPiA+ID4gPiArc3RhdGljIGlubGluZSBpbnQgYXRvbWljX2FkZF91bmxl
c3MoYXRvbWljX3QgKnYsIGludCBhLCBpbnQKPiA+ID4gPiA+IHUpCj4gPiA+ID4gPiArewo+ID4g
PiA+ID4gK8KgwqDCoMKgwqDCoCBpbnQgcHJldiwgcmM7Cj4gPiA+ID4gPiArCj4gPiA+ID4gPiAr
wqDCoMKgIGFzbSB2b2xhdGlsZSAoCj4gPiA+ID4gPiArwqDCoMKgwqDCoMKgwqAgIjA6IGxyLnfC
oMKgwqDCoCAlW3BdLMKgICVbY11cbiIKPiA+ID4gPiA+ICvCoMKgwqDCoMKgwqDCoCAiwqDCoCBi
ZXHCoMKgwqDCoMKgICVbcF0swqAgJVt1XSwgMWZcbiIKPiA+ID4gPiA+ICvCoMKgwqDCoMKgwqDC
oCAiwqDCoCBhZGTCoMKgwqDCoMKgICVbcmNdLCAlW3BdLCAlW2FdXG4iCj4gPiA+ID4gPiArwqDC
oMKgwqDCoMKgwqAgIsKgwqAgc2Mudy5ybMKgICVbcmNdLCAlW3JjXSwgJVtjXVxuIgo+ID4gPiA+
ID4gK8KgwqDCoMKgwqDCoMKgICLCoMKgIGJuZXrCoMKgwqDCoCAlW3JjXSwgMGJcbiIKPiA+ID4g
PiA+ICvCoMKgwqDCoMKgwqDCoCBSSVNDVl9GVUxMX0JBUlJJRVIKPiA+ID4gPiAKPiA+ID4gPiBX
aXRoIHRoaXMgYW5kIG5vIC5hcSBvbiB0aGUgbG9hZCwgd2h5IHRoZSAucmwgb24gdGhlIHN0b3Jl
Pwo+ID4gPiBJdCBpcyBzb21ldGhpbmcgdGhhdCBMS01NIHJlcXVpcmVzIFsxXS4KPiA+ID4gCj4g
PiA+IFRoaXMgaXMgbm90IGZ1bGx5IGNsZWFyIHRvIG1lIHdoYXQgaXMgc28gc3BlY2lmaWMgaW4g
TEtNTSwgYnV0Cj4gPiA+IGFjY29yaW5nCj4gPiA+IHRvIHRoZSBzcGVjOgo+ID4gPiDCoMKgIE9y
ZGVyaW5nIEFubm90YXRpb24gRmVuY2UtYmFzZWQgRXF1aXZhbGVudAo+ID4gPiDCoMKgIGx7Ynxo
fHd8ZHxyfS5hccKgwqDCoMKgIGx7YnxofHd8ZHxyfTsgZmVuY2Ugcixydwo+ID4gPiDCoMKgIGx7
YnxofHd8ZHxyfS5hcXJswqDCoCBmZW5jZSBydyxydzsgbHtifGh8d3xkfHJ9OyBmZW5jZSByLHJ3
Cj4gPiA+IMKgwqAgc3tifGh8d3xkfGN9LnJswqDCoMKgwqAgZmVuY2Ugcncsdzsgc3tifGh8d3xk
fGN9Cj4gPiA+IMKgwqAgc3tifGh8d3xkfGN9LmFxcmzCoMKgIGZlbmNlIHJ3LHc7IHN7YnxofHd8
ZHxjfQo+ID4gPiDCoMKgIGFtbzxvcD4uYXHCoMKgwqDCoMKgwqDCoMKgwqAgYW1vPG9wPjsgZmVu
Y2Ugcixydwo+ID4gPiDCoMKgIGFtbzxvcD4ucmzCoMKgwqDCoMKgwqDCoMKgwqAgZmVuY2Ugcncs
dzsgYW1vPG9wPgo+ID4gPiDCoMKgIGFtbzxvcD4uYXFybMKgwqDCoMKgwqDCoMKgIGZlbmNlIHJ3
LHJ3OyBhbW88b3A+OyBmZW5jZSBydyxydwo+ID4gPiDCoMKgIFRhYmxlIDIuMjogTWFwcGluZ3Mg
ZnJvbSAuYXEgYW5kL29yIC5ybCB0byBmZW5jZS1iYXNlZAo+ID4gPiBlcXVpdmFsZW50cy4KPiA+
ID4gwqDCoCBBbiBhbHRlcm5hdGl2ZSBtYXBwaW5nIHBsYWNlcyBhIGZlbmNlIHJ3LHJ3IGFmdGVy
IHRoZSBleGlzdGluZwo+ID4gPiDCoMKgIHN7YnxofHd8ZHxjfSBtYXBwaW5nIHJhdGhlciB0aGFu
IGF0IHRoZSBmcm9udCBvZiB0aGUKPiA+ID4gwqDCoCBse2J8aHx3fGR8cn0gbWFwcGluZy4KPiA+
IAo+ID4gSSdtIGFmcmFpZCBJIGNhbid0IHNwb3QgdGhlIHNwZWNpZmljIGNhc2UgaW4gdGhpcyB0
YWJsZS4gTm9uZSBvZgo+ID4gdGhlCj4gPiBzdG9yZXMgaW4gdGhlIHJpZ2h0IGNvbHVtbiBoYXZl
IGEgLnJsIHN1ZmZpeC4KPiBZZXMsIGl0IGlzIGV4cGVjdGVkLgo+IAo+IEkgYW0gcmVhZGluZyB0
aGlzIHRhYmxlIGFzIChmLmUuKSBhbW88b3A+LnJsIGlzIGFuIGVxdWl2YWxlbnQgb2YKPiBmZW5j
ZQo+IHJ3LHc7IGFtbzxvcD4uICh3aXRob3V0IC5ybCkgCj4gCj4gPiAKPiA+ID4gwqDCoCBJdCBp
cyBhbHNvIHNhZmUgdG8gdHJhbnNsYXRlIGFueSAuYXEsIC5ybCwgb3IgLmFxcmwgYW5ub3RhdGlv
bgo+ID4gPiBpbnRvCj4gPiA+IMKgwqAgdGhlIGZlbmNlLWJhc2VkIHNuaXBwZXRzIG9mCj4gPiA+
IMKgwqAgVGFibGUgMi4yLiBUaGVzZSBjYW4gYWxzbyBiZSB1c2VkIGFzIGEgbGVnYWwgaW1wbGVt
ZW50YXRpb24gb2YKPiA+ID4gwqDCoCBse2J8aHx3fGR9IG9yIHN7YnxofHd8ZH0gcHNldS0KPiA+
ID4gwqDCoCBkb2luc3RydWN0aW9ucyBmb3IgYXMgbG9uZyBhcyB0aG9zZSBpbnN0cnVjdGlvbnMg
YXJlIG5vdCBhZGRlZAo+ID4gPiB0bwo+ID4gPiDCoMKgIHRoZSBJU0EuCj4gPiA+IAo+ID4gPiBT
byBhY2NvcmRpbmcgdG8gdGhlIHNwZWMsIGl0IHNob3VsZCBiZToKPiA+ID4gwqBzYy53IC4uLgo+
ID4gPiDCoFJJU0NWX0ZVTExfQkFSUklFUi4KPiA+ID4gCj4gPiA+IENvbnNpZGVyaW5nIFsxXSBh
bmQgaG93IHRoaXMgY29kZSBsb29rcyBiZWZvcmUsIGl0IHNlZW1zIHRvIG1lCj4gPiA+IHRoYXQK
PiA+ID4gaXQKPiA+ID4gaXMgc2FmZSB0byB1c2UgbHIudy5hcS9zYy53LnJsIGhlcmUgb3IgYW4g
ZmVuY2UgZXF1aXZhbGVudC4KPiA+IAo+ID4gSGVyZSB5b3Ugc2F5ICJvciIuIFRoZW4gd2h5IGRv
cyB0aGUgY29kZSB1c2Ugc2MuPy5ybCBfYW5kXyBhIGZlbmNlPwo+IEkgY29uZnVzZWQgdGhpcyBs
aW5lIHdpdGggYW1vPG9wPi5hcXJsLCBzbyBiYXNlZCBvbiB0aGUgdGFibGUgMi4yCj4gYWJvdmUK
PiBze2J8aHx3fGR8Y30uYXFybCBpcyB0cmFuc2Zvcm1lZCB0byAiZmVuY2Ugcncsdzsgc3tifGh8
d3xkfGN9IiwgYnV0Cj4gTGludXgga2VybmVsIGRlY2lkZWQgdG8gc3RyZW5ndGhlbiBpdCB3aXRo
IGZ1bGwgYmFycmllcjoKPiDCoMKgIC3CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAiMDpcblx0
Igo+IMKgwqAgLcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgICJsci53LmFxcmzCoCAlW3BdLMKg
ICVbY11cblx0Igo+IMKgwqAgLcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgICJiZXHCoMKgwqDC
oMKgwqDCoCAlW3BdLMKgICVbdV0sIDFmXG5cdCIKPiDCoMKgIC3CoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoCAiYWRkwqDCoMKgwqDCoMKgICVbcmNdLMKgICVbcF0sICVbYV1cblx0Igo+IMKgwqAg
LcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgICJzYy53LmFxcmwgJVtyY10sICVbcmNdLCAlW2Nd
XG5cdCIKPiDCoMKgIC3CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAiYm5lesKgwqDCoMKgwqAg
JVtyY10sIDBiXG5cdCIKPiDCoMKgIC3CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAiMToiCj4g
wqDCoCArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAiMDrCoMKgwqDCoCBsci53wqDCoMKg
wqAgJVtwXSzCoCAlW2NdXG4iCj4gwqDCoCArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAi
wqDCoMKgwqDCoMKgIGJlccKgwqDCoMKgwqAgJVtwXSzCoCAlW3VdLCAxZlxuIgo+IMKgwqAgK8Kg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgIsKgwqDCoMKgwqDCoCBhZGTCoMKgwqDCoMKgICVb
cmNdLCAlW3BdLCAlW2FdXG4iCj4gwqDCoCArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAi
wqDCoMKgwqDCoMKgIHNjLncucmzCoCAlW3JjXSwgJVtyY10sICVbY11cbiIKPiDCoMKgICvCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgICLCoMKgwqDCoMKgwqAgYm5lesKgwqDCoMKgICVbcmNd
LCAwYlxuIgo+IMKgwqAgK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgIsKgwqDCoMKgwqDC
oCBmZW5jZcKgwqDCoCBydywgcndcbiIKPiDCoMKgICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgICIxOlxuIgo+IEFzIHRoZXkgaGF2ZSB0aGUgZm9sbG93aW5nIGlzc3VlOgo+IMKgwqAgaW1w
bGVtZW50YXRpb25zIG9mIGF0b21pY3Mgc3VjaCBhcyBhdG9taWNfY21weGNoZygpIGFuZAo+IMKg
wqAgYXRvbWljX2FkZF91bmxlc3MoKSByZWx5IG9uIExSL1NDIHBhaXJzLAo+IMKgwqAgd2hpY2gg
ZG8gbm90IGdpdmUgZnVsbC1vcmRlcmluZyB3aXRoIC5hcXJsOyBmb3IgZXhhbXBsZSwgY3VycmVu
dAo+IMKgwqAgaW1wbGVtZW50YXRpb25zIGFsbG93IHRoZSAibHItc2MtYXFybC1wYWlyLXZzLWZ1
bGwtYmFycmllciIgdGVzdAo+IMKgwqAgYmVsb3cgdG8gZW5kIHVwIHdpdGggdGhlIHN0YXRlIGlu
ZGljYXRlZCBpbiB0aGUgImV4aXN0cyIgY2xhdXNlLgo+IAo+ID4gCj4gPiA+IEJ1dCBpbiBnZW5l
cmFsIGl0ICggYSBjb21iaW5hdGlvbiBvZiBmZW5jZSwgLmFxLCAucmwgKSBjYW4gYmUKPiA+ID4g
Y29uc2lkZXJlZCBhcyB0aGUgc2FtZSB0aGluZ3MgaW4gdGhpcyBjb250ZXh0LCBzbyBpdCBpcyBw
b3NzaWJsZQo+ID4gPiB0bwo+ID4gPiBsZWF2ZSB0aGlzIGZ1bmN0aW9uIGFzIGlzIHRvIGJlIHN5
bmNlZCBoZXJlIHdpdGggTGludXgga2VybmVsLgo+ID4gCj4gPiBJbiB0dXJuIEkgYWxzbyBkb24n
dCB1bmRlcnN0YW5kIHRoaXMuIFllcywgdGhlIGV4Y2VzcyAucmwgY2VydGFpbmx5Cj4gPiBkb2Vz
bid0IHJlbmRlciB0aGluZ3MgdW5zYWZlLiBCdXQgd2hhdCdzIHRoZSBwdXJwb3NlIG9mIHRoZSAu
cmw/Cj4gPiBUaGF0J3MKPiA+IHdoYXQgbXkgb3JpZ2luYWwgcXVlc3Rpb24gYm9pbGVkIGRvd24g
dG8uCj4gSSBkb24ndCBrbm93LCBlaXRoZXIuIEFzIEkgbWVudGlvbmVkIGJlZm9yZSwgaXQgaXMg
ZW5vdWdoICggaW4gbXkKPiBvcGluaW9uICkgdG8gaGF2ZSBhIEZVTEwgYmFycmllciBvciAuYXEs
LnJsIG9yIC5hcXJsLy5hcXJsICggaWYgaXQKPiBuZWVkZWQgdG8gYmUgc3RyZW5ndGhlbmVkKSBs
aWtlIGl0IHdhcyBkb25lIGJlZm9yZSBpbiBMaW51eC4KPiBJdCBzZWVtcyB0byBtZSBpdCBpcyBM
S01NIHNwZWNpZmljIHRoYXQgdGhleSBuZWVkIG1vcmUgdG8gYmUgbW9yZQo+IHN0cmVuZ3RoZW5l
ZCBhcyBpdCBSSVNDLVYgTWVtb3J5IG1vZGVsIHJlcXVpcmVzIGJlY2F1c2U6Cj4gInNjLncgOyBm
ZW5jZSBydywgcnciIGRvZXMgbm90IGd1YXJhbnRlZSB0aGF0IGFsbCBwcmV2aW91cyByZWFkcyBh
bmQKPiB3cml0ZXMgZmluaXNoIGJlZm9yZSB0aGUgc2MgaXRzZWxmIGlzIGdsb2JhbGx5IHZpc2li
bGUsIHdoaWNoIG1pZ2h0Cj4gbWF0dGVyIGlmIHRoZSBzYyBpcyB1bmxvY2tpbmcgYSBsb2NrIG9y
IHNvbWV0aGluZy4KPiAKPiBEZXNwaXRlIG9mIHRoZSBmYWN0LCBmb3IgY29tcGFyZS1hbmQtc3dh
cCBsb29wcywgUklTQy1WIGludGVybmF0aW9uYWwKPiByZWNvbW1lbmRzIGxyLncuYXEvbHIuZC5h
cSBmb2xsb3dlZCBieSBzYy53LnJsL3NjLmQucmwgKCBhcyBpdCB3YXMKPiBpbXBsZW1ldGVkIGJl
Zm9yZSBpbiBMaW51eCBrZXJuZWwgKSBJIGFtIG9rYXkganVzdCBmb3Igc2FmZXR5IHJlYXNvbnMK
PiBhbmQgZm9yIHRoZSByZWFzb24gSSBtZW50aW9uZWQgYXQgdGhlIGxhc3Qgc2VudGVuY2Ugb2Yg
cHJldmlvdXMKPiBwYXJhZ3JhcGggdG8gc3RyZW5ndGhlbiBpbXBsZW1lbnRhdGlvbnMgd2l0aCBm
ZW5jZXMuClJlZ2FyZGluZyB0aGUgbmVjZXNzaXR5IG9mIGZlbmNlIHJ3LHJ3LCB0aGVyZSBpcyBh
IGNvbW1pdCB0aGF0IGlzIHByb3Bvc2luZ3RvIHJlbW92ZSBmZW5jZXM6IFsyXS4KQWRkaXRpb25h
bGx5LCBpdCBzZWVtcyB0aGVyZSBpcyBhbm90aGVyIHJlYXNvbiB3aHkgdGhlIGZlbmNlcyB3ZXJl
CmFkZGVkLgpBdCB0aGUgdGltZSB3aGVuIHRoZSBwYXRjaCBpbnRyb2R1Y2luZyB0aGUgdXNhZ2Ug
b2YgZmVuY2VzIHdhcwppbXBsZW1lbnRlZCwKdGhlcmUgd2VyZSBubyBydWxlcyBpbiBSVldNTyB3
aGljaCBhbGxvd2VkIGxkLmFxK3NjLmFxcmwgdG8gYmUKY29uc2lkZXJlZAphcyBhIGZ1bGwgYmFy
cmllciBbM10uCiAgID4gPiBub3RlIHRoYXQgTW9kZWwgMjAxOCBleHBsaWNpdGx5IHNheXMgdGhh
dCAibGQuYXErc2MuYXFybCIgaXMKICAgb3JkZXJlZAogICA+ID4gYWdhaW5zdCAiZWFybGllciBv
ciBsYXRlciBtZW1vcnkgb3BlcmF0aW9ucyBmcm9tIHRoZSBzYW1lIGhhcnQiLAogICBhbmQKICAg
PiA+IHRoaXMgc3RhdGVtZW50IHdhcyBub3QgaW4gTW9kZWwgMjAxNy4KICAgPiA+IAogICA+ID4g
U28gbXkgdW5kZXJzdGFuZGluZyBvZiB0aGUgc3RvcnkgaXMgdGhhdCBhdCBzb21lIHBvaW50IGJl
dHdlZW4KICAgTWFyY2ggYW5kCiAgID4gPiBNYXkgMjAxOCwgUklTViBtZW1vcnkgbW9kZWwgZm9s
a3MgZGVjaWRlZCB0byBhZGQgdGhpcyBydWxlLAp3aGljaAogICBkb2VzCiAgID4gPiBsb29rIG1v
cmUgY29uc2lzdGVudCB3aXRoIG90aGVyIHBhcnRzIG9mIHRoZSBtb2RlbCBhbmQgaXMKdXNlZnVs
LgogICA+ID4gCiAgID4gPiBBbmQgdGhpcyBpcyB3aHkgKGFuZCB3aGVuKSAibGQuYXErc2MuYXFy
bCIgY2FuIGJlIHVzZWQgYXMgYQpmdWxseS0KICAgb3JkZXJlZAogICA+ID4gYmFycmllciA7LSkK
ICAgPiA+IAogICA+ID4gTm93IGlmIG15IHVuZGVyc3RhbmRpbmcgaXMgY29ycmVjdCwgdG8gbW92
ZSBmb3J3YXJkLCBpdCdzIGJldHRlcgogICB0aGF0IDEpCiAgID4gPiB0aGlzIHBhdGNoIGdldHMg
cmVzZW5kIHdpdGggdGhlIGFib3ZlIGluZm9ybWF0aW9uIChiZXR0ZXIKcmV3b3JkaW5nCiAgIGEK
ICAgPiA+IGJpdCksIGFuZCAyKSBnZXRzIGFuIEFja2VkLWJ5IGZyb20gRGFuIHRvIGNvbmZpcm0g
dGhpcyBpcyBhCmNvcnJlY3QKICAgPiA+IGhpc3RvcnkgOy0pCgpCYXNlZCBvbiBwYXRjaCBbMl0s
IGl0IG1heSBiZSBwb3NzaWJsZSB0byByZW1vdmUgdGhlIGZ1bGwgYmFycmllciBhbmQKc3dpdGNo
IGZyb20gc2MuLnJsIHRvIHNjLi5hcXJsLiBIb3dldmVyLCBJIG5lZWQgdG8gZmluaXNoIHJlYWRp
bmcgdGhlCkxpbnV4IGtlcm5lbCBtYWlsaW5nIHRocmVhZCB0byB1bmRlcnN0YW5kIHdoeSBhIHNp
bWlsYXIgY2hhbmdlIHdhc24ndAptYWRlIGZvciB0aGUgbHIgaW5zdHJ1Y3Rpb24gKCBsciAtPiBs
ci5hcSBvciBsci5hcXJsIGFzIGl0IHdhcyBiZWZvcmUKKS4KCkRvZXMgdGhhdCBtYWtlIHNlbnNl
IHRvIHlvdT8KClsyXQpodHRwczovL2xvcmUua2VybmVsLm9yZy9saW51eC1yaXNjdi8yMDIyMDUw
NTAzNTUyNi4yOTc0MzgyLTYtZ3VvcmVuQGtlcm5lbC5vcmcvClszXWh0dHBzOi8vbG9yZS5rZXJu
ZWwub3JnL2xpbnV4LXJpc2N2L1lyU28lMkYzaVV1TzBBTDc2VEBib3F1bi1hcmNobGludXgvCgp+
IE9sZWtzaWkKPiAKPiB+IE9sZWtzaWkKPiA+IAo+ID4gSmFuCj4gPiAKPiA+ID4gWzFdCj4gPiA+
Cmh0dHBzOi8vbG9yZS5rZXJuZWwub3JnL2xrbWwvMTUyMDI3NDI3Ni0yMTg3MS0xLWdpdC1zZW5k
LWVtYWlsLXBhcnJpLmFuZHJlYUBnbWFpbC5jb20KPiA+ID4gLwo+ID4gPiAKPiA+ID4gfiBPbGVr
c2lpCj4gPiAKPiAKCgo=



From xen-devel-bounces@lists.xenproject.org Tue Mar 26 21:39:07 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Mar 2024 21:39:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698210.1089681 (Exim 4.92)
	(envelope-from )
	id 1rpEVe-0005ug-VD; Tue, 26 Mar 2024 21:39:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698210.1089681; Tue, 26 Mar 2024 21:39:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpEVe-0005uP-Qi; Tue, 26 Mar 2024 21:39:06 +0000
Received: by outflank-mailman (input) for mailman id 698210;
 Tue, 26 Mar 2024 21:39:05 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpEVd-0005qH-G6
 for xen-devel@lists.xenproject.org; Tue, 26 Mar 2024 21:39:05 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on20601.outbound.protection.outlook.com
 [2a01:111:f403:200a::601])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 43218716-ebb9-11ee-a1ef-f123f15fe8a2;
 Tue, 26 Mar 2024 22:39:03 +0100 (CET)
Received: from SJ0PR03CA0007.namprd03.prod.outlook.com (2603:10b6:a03:33a::12)
 by SJ0PR12MB6926.namprd12.prod.outlook.com (2603:10b6:a03:485::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.33; Tue, 26 Mar
 2024 21:38:59 +0000
Received: from SJ5PEPF000001D7.namprd05.prod.outlook.com
 (2603:10b6:a03:33a:cafe::d5) by SJ0PR03CA0007.outlook.office365.com
 (2603:10b6:a03:33a::12) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.13 via Frontend
 Transport; Tue, 26 Mar 2024 21:38:59 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 SJ5PEPF000001D7.mail.protection.outlook.com (10.167.242.59) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Tue, 26 Mar 2024 21:38:59 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Tue, 26 Mar
 2024 16:38:57 -0500
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB05.amd.com
 (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Tue, 26 Mar
 2024 16:38:56 -0500
Received: from fedora.mshome.net (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Tue, 26 Mar 2024 16:38:56 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 43218716-ebb9-11ee-a1ef-f123f15fe8a2
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=mhdFu1xwgU2D7StoOxnoKiJIJxxVApjrqOX4pnrDvU1v3ExHYFc3FKWfS/F7S6gMBFDrPCvLBdnpnyWYcqmEiyGxZRiLWPBnfHogy6awVu8AqxU11imMYxRO6X7+9BcQgAENpWjS2Zfu5QrHJ3+k5Uu+azWcV+ciwmztU5J2XRpadGdqZTmZgpdNJ7bMAcWj3Y0GChhAuhnJdjH7SVHveiGI3DT8lmB09Dkxij+8tM0qZpbShutgcpVt07ItrMfOIVu9HyXAdXT/0ZsChbq4B7zrtBREAlNacAsjZi3Yy9doVeXcG9/ZOc4J4oIb1edmTUIAZ6m8uXsicU6IWPlSmA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=kpYFdzJHkuO60SpR1aTtd436m2Cbip6KFJuG8vrlzio=;
 b=R2IcNaMHFc339T1mzpptb+zUnbdVNwgXfJsc39lJjHIik6TRtlYWh1akeiXdqzdJ1D2xVSFWoFaZ2/IYcVAjl31DLyuotpnC5izN/SOCTKcdNu/GAXt8FuY/GGM4qXQySEPs75feCrjNTmFNylATyaCTuwZNZrYpOaHaUERjJjXSZpRbkQ/MLolkMwMXRTMM/GUaE7FK4cq9rD9Zr3eYEUPmWqit7xnWc4xCeuZbBRxv2SA6ox5Glg9wO4XCvNVYe2cT1mY8WwWPCmfF3Tkgr23tj/ylntFIbGxthxV/osQTZq4fxWwg38J5gz582qBMQGQpdUf8BJWa5HSam+pH1A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=kpYFdzJHkuO60SpR1aTtd436m2Cbip6KFJuG8vrlzio=;
 b=K8Cm1S/axfTTIolhv3oJof5OqJ67b8WhVQWLeOV1ZnZ+bf0UtyIr1E6Zy3rSLomo6bZdUW0L+qlERVvVvtJerBSMaTs5m7yBWPSQZX8C/eNzNaDg/RCdtx3rPdYUftyeDuhwAjh3MSyLPxi1etHePjq3Dd5gut8aqf6zIpk88Bg=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
From: Jason Andryuk 
To: 
CC: Jason Andryuk , Juergen Gross ,
	Julien Grall , Anthony PERARD 
Subject: [PATCH v5 2/6] tools/init-xenstore-domain: Replace variable MB() usage
Date: Tue, 26 Mar 2024 17:38:43 -0400
Message-ID: <20240326213847.3944-3-jason.andryuk@amd.com>
X-Mailer: git-send-email 2.44.0
In-Reply-To: <20240326213847.3944-1-jason.andryuk@amd.com>
References: <20240326213847.3944-1-jason.andryuk@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB05.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ5PEPF000001D7:EE_|SJ0PR12MB6926:EE_
X-MS-Office365-Filtering-Correlation-Id: 278345a7-6735-4fc6-e4d2-08dc4ddd2597
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	NWpdKKn4Iyc2x7lf13yxcQzDyk7RRN0tqHJbWUVK/WUIoh/H75TQyy5Rf9Gb8KOZNDyBQzBDd+9EjYmAdM2XFKgISaDhq95l7MCgAjyvwq+Q0WSlUWmhyI6znL5Dqc4ZVFv8alJl13SAezXAQK2yLBuOuHjmSVWDZT1NZodc3TsTkal9oIu1sEb+goMq2DjO7JZMf+wwRjnsOR+6j8J+/Z4+XbtwlGwiAzX5ft/+zU6sJRZsgqP4hgzSK4vY2ksx5Bx5n4j7N/sKH2JJeH7wl5xMKMSdDZPOtRewncBoR9vLAi+c1F7BRFhf0GHzC8H3+6LHrcs4bvLzTuUy3hPMyPbuodKAro/Bn7eAjfRxOZQO3g43EcxBzss+T2x82QziNOc47UTQOkJPF0j0TQFhmKxruaqzmfMOQFiBkVE0i9mbVwTAWi0Sf4lzJj5aX2YLtrmDgzPYx1jIdMKrGyAYgslAhgtPSq6kxHwqb7DzEx4kYQ8OD9fACapr1Wf2fGz/NCvLxcoVsg21yw0GQE2hXdLz0zO+WBO8SxcyWLT++o8hvU+2z0fKQVL3W1+K0+RGklzuUzfztGlGoPYvCxCU0+TXoBa0GNCQUCHSVtl0cAQ7/hX7XhwCNJGDU5Mzuos+iV4wMUFnCF/Nh5ip/ZpLl4He9mXBK47ckNsEyRUav4FQoVpxRiyjNu+YLwpC3xwDfYEUBkeiYU1jCZQmD8wCV1jtv8i5ZC5H4mI7PmVVEqFwK4h/khCx3/ZcWE7N6yx/
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(376005)(82310400014)(36860700004)(1800799015);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Mar 2024 21:38:59.2027
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 278345a7-6735-4fc6-e4d2-08dc4ddd2597
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ5PEPF000001D7.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR12MB6926

The local MB() & GB() macros will be replaced with a common
implementation, but those only work with constant values.  Introduce a
static inline mb_to_bytes() in place of the MB() macro to convert the
variable values.

Signed-off-by: Jason Andryuk 
---
v4:
New
---
 tools/helpers/init-xenstore-domain.c | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/tools/helpers/init-xenstore-domain.c b/tools/helpers/init-xenstore-domain.c
index 1683438c5c..5405842dfe 100644
--- a/tools/helpers/init-xenstore-domain.c
+++ b/tools/helpers/init-xenstore-domain.c
@@ -20,7 +20,6 @@
 #include "init-dom-json.h"
 
 #define LAPIC_BASE_ADDRESS  0xfee00000UL
-#define MB(x)               ((uint64_t)x << 20)
 #define GB(x)               ((uint64_t)x << 30)
 
 static uint32_t domid = ~0;
@@ -36,6 +35,11 @@ static xc_evtchn_port_or_error_t console_evtchn;
 static xentoollog_level minmsglevel = XTL_PROGRESS;
 static void *logger;
 
+static inline uint64_t mb_to_bytes(int mem)
+{
+	return (uint64_t)mem << 20;
+}
+
 static struct option options[] = {
     { "kernel", 1, NULL, 'k' },
     { "memory", 1, NULL, 'm' },
@@ -76,8 +80,8 @@ static int build(xc_interface *xch)
     int rv, xs_fd;
     struct xc_dom_image *dom = NULL;
     int limit_kb = (maxmem ? : memory) * 1024 + X86_HVM_NR_SPECIAL_PAGES * 4;
-    uint64_t mem_size = MB(memory);
-    uint64_t max_size = MB(maxmem ? : memory);
+    uint64_t mem_size = mb_to_bytes(memory);
+    uint64_t max_size = mb_to_bytes(maxmem ? : memory);
     struct e820entry e820[3];
     struct xen_domctl_createdomain config = {
         .ssidref = SECINITSID_DOMU,
-- 
2.44.0



From xen-devel-bounces@lists.xenproject.org Tue Mar 26 21:39:07 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Mar 2024 21:39:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698211.1089686 (Exim 4.92)
	(envelope-from )
	id 1rpEVf-00061J-9r; Tue, 26 Mar 2024 21:39:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698211.1089686; Tue, 26 Mar 2024 21:39:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpEVf-0005yf-43; Tue, 26 Mar 2024 21:39:07 +0000
Received: by outflank-mailman (input) for mailman id 698211;
 Tue, 26 Mar 2024 21:39:06 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpEVe-0005br-8g
 for xen-devel@lists.xenproject.org; Tue, 26 Mar 2024 21:39:06 +0000
Received: from NAM02-BN1-obe.outbound.protection.outlook.com
 (mail-bn1nam02on20600.outbound.protection.outlook.com
 [2a01:111:f403:2407::600])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4471adf7-ebb9-11ee-afe3-a90da7624cb6;
 Tue, 26 Mar 2024 22:39:05 +0100 (CET)
Received: from DS7PR03CA0334.namprd03.prod.outlook.com (2603:10b6:8:55::11) by
 SJ2PR12MB8033.namprd12.prod.outlook.com (2603:10b6:a03:4c7::19) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.33; Tue, 26 Mar
 2024 21:39:02 +0000
Received: from DS3PEPF000099DF.namprd04.prod.outlook.com
 (2603:10b6:8:55:cafe::aa) by DS7PR03CA0334.outlook.office365.com
 (2603:10b6:8:55::11) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.13 via Frontend
 Transport; Tue, 26 Mar 2024 21:39:02 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 DS3PEPF000099DF.mail.protection.outlook.com (10.167.17.202) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Tue, 26 Mar 2024 21:39:01 +0000
Received: from SATLEXMB08.amd.com (10.181.40.132) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Tue, 26 Mar
 2024 16:39:01 -0500
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB08.amd.com
 (10.181.40.132) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Tue, 26 Mar
 2024 14:39:00 -0700
Received: from fedora.mshome.net (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Tue, 26 Mar 2024 16:39:00 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4471adf7-ebb9-11ee-afe3-a90da7624cb6
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=fEGfIXnKzDHv2ZrMSbPJ4KoFsMVLBkbRoseXrlA9cRqGE7Bo+10Eqyz//ZOR1cfLxK7TU6N89kjw9OKRzi117gaPUWx/nqiP6+pV+RiHzDwvHSzBd+3cAmmRzDhus4FQVL4NpuWLl+P18a/HkJWoTjCurE+4fLtNoMY2KRfaOxSKaM6Bnt6MZKpTiIwptVmyO3iJXDz8nP4yLbL898pcExlmLO1xipgnSFeoJKr7MjJc3HwD8/C5Wtyfz6kkEpuyAW1BGgjY8SPuJA+aOFA1cjkYRi5oFWS3nFtauiq/7wFG8ZMMRXgnmkdCTlwpmJkzBKSbPRld9kn0oiq0H+dPFw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=cAWSRBxqx9TWCT5t93ONlKSjz28ZclhdZGQsIXJ8iMY=;
 b=cePQPKntSFaPO+lOrfItCFLDEun72N3VrvM73B6GhOG00L6+VVEiSzjJ5CLCQ9G2G8ZF8ZT0HbpSxcq3MDujw4AHepW/ABVkz/hBQ29Qou9H9fAUCKEz76FGAy+g5/rSvuJWwiDWfd0e4aWzyj4LJp4N9kgFTBY6iEAF4DfyxXU0/acyCf9W5+49vnt01GDoeATys4T9dqEjI/ZlRkTRxOBnebD1MUH2UXWEK5+ZRZvJglI1esMPYQPvxtfaFMC65g5XzN48Y3HduE++ztsSJ5hyc4u3Q4in3mU3/rDiuzgnwuQPbJHHDAzjXaiMhKedhESMvOs+WM9newZgLvCkOQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=cAWSRBxqx9TWCT5t93ONlKSjz28ZclhdZGQsIXJ8iMY=;
 b=gsYPCml7wTVlrfrO/4jyvXXJm9yAd6b9kvdCEnZW5mXlUQOgXhzPUj1q/UWYXS7dPmcrV6PgmKyuwGyCjXl3rThPwkaFiY1swi7SIgnd2GtbeqV6xAzJoePew8X3cMFfpqG0xrwhZGQSXerf65QY0NWzqVtntl9MdPnmDbpiOoI=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Jason Andryuk 
To: 
CC: Jason Andryuk , Andrew Cooper
	, George Dunlap , "Jan
 Beulich" , Julien Grall , "Stefano
 Stabellini" 
Subject: [PATCH v5 4/6] libelf: Expand ELF note printing
Date: Tue, 26 Mar 2024 17:38:45 -0400
Message-ID: <20240326213847.3944-5-jason.andryuk@amd.com>
X-Mailer: git-send-email 2.44.0
In-Reply-To: <20240326213847.3944-1-jason.andryuk@amd.com>
References: <20240326213847.3944-1-jason.andryuk@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DS3PEPF000099DF:EE_|SJ2PR12MB8033:EE_
X-MS-Office365-Filtering-Correlation-Id: 5818a040-0896-46d3-7ae1-08dc4ddd2748
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	qFry+tKo3Z3kenPU9t52oavXVSw50loeziGAxNBhHM4Qrzt+UTlZPz/vrJiVe6JF2Vr3wBDPIfaI9OZiOtf0zF+D+locEeYZWtHQ8DmevtTT5nnyQpA6K6slvbgeYcy+VhtjMzU5v2/EgFK3lZTY9fwjJNRp4wySKRlJO+IZQ0bm76zAJBWQHArmQlkmqGr80hiw+ct/tuygoEuSFej3yN3XGcVOBgeB5Bflzma7LnXCmxud06QXiYejzgqaJR5derHN3pE+XWjJzhk+upl9zAkC/2wvqIZbAsT+suskNcGJW0NWYu2iAlFwHVDMDNLI7FbUZWswUzkqrlmnVIcjSXzRKrA6G4AYCqKU5MxppOaES1jgIP1iySBOzWA9qJ5KMv9Y7sfUN45g40/YzQl4xg6VrjBxyAUQJIp7JU6OnE+DF2qNL52oxjlSXvElayitmYwesRTBuBfjgSnc24MTuYYRz6/mzBsgbUi+kp1WA6gDI+Fl7hPEO3m+onZRU+hjGsUJa+XVTNotJ1To9TZGSy7ve9zsfEa2oJQrJQEMKb11PBOUAVIVGNZziH9L+urPJKkwyr/PcgxA2fxgBTWHqf2qa9HESi9A4YSW9pbWBf1dny9jhzT5xgHUIdsBmHhtqPHKrBxwXmDb6LuemiEoUhWPzRN6LTvjbCDPI7cWanuPLE44eHABGZ8p3kkTuUnzH7sur6l3eNeMP/z1V78nrmivrnmosoeJVEVll5gwiS1u32Oy8oLOMWwBjKRW4AGV
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(36860700004)(376005)(82310400014)(1800799015);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Mar 2024 21:39:01.9596
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 5818a040-0896-46d3-7ae1-08dc4ddd2748
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DS3PEPF000099DF.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB8033

The XEN_ELFNOTE_L1_MFN_VALID is an array of pairs of values, but it is
printed as:
(XEN) ELF: note: L1_MFN_VALID = 0

This is a limitation of only printing either string or numeric values.
Switch from the boolean to an enum which allows more flexibility in
printing the values.  Introduce ELFNOTE_NAME to only print the name
without a value like:
(XEN) ELF: note: L1_MFN_VALID

Details can optionally be printed for specific notes.

Signed-off-by: Jason Andryuk 
Reviewed-by: Jan Beulich 
---
v3:
Remove fatal size check
Don't print values - just the name for presence

v4:
Use switch
Always print newline for ELFNOTE_NAME

v5:
Add comment about newline printing
Add Jan's R-b
---
 xen/common/libelf/libelf-dominfo.c | 62 +++++++++++++++++++-----------
 1 file changed, 39 insertions(+), 23 deletions(-)

diff --git a/xen/common/libelf/libelf-dominfo.c b/xen/common/libelf/libelf-dominfo.c
index a13a5e4db6..77bd582a37 100644
--- a/xen/common/libelf/libelf-dominfo.c
+++ b/xen/common/libelf/libelf-dominfo.c
@@ -101,26 +101,30 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
 /* *INDENT-OFF* */
     static const struct {
         const char *name;
-        bool str;
+        enum {
+            ELFNOTE_INT,
+            ELFNOTE_STRING,
+            ELFNOTE_NAME,
+        } type;
     } note_desc[] = {
-        [XEN_ELFNOTE_ENTRY] = { "ENTRY", 0},
-        [XEN_ELFNOTE_HYPERCALL_PAGE] = { "HYPERCALL_PAGE", 0},
-        [XEN_ELFNOTE_VIRT_BASE] = { "VIRT_BASE", 0},
-        [XEN_ELFNOTE_INIT_P2M] = { "INIT_P2M", 0},
-        [XEN_ELFNOTE_PADDR_OFFSET] = { "PADDR_OFFSET", 0},
-        [XEN_ELFNOTE_HV_START_LOW] = { "HV_START_LOW", 0},
-        [XEN_ELFNOTE_XEN_VERSION] = { "XEN_VERSION", 1},
-        [XEN_ELFNOTE_GUEST_OS] = { "GUEST_OS", 1},
-        [XEN_ELFNOTE_GUEST_VERSION] = { "GUEST_VERSION", 1},
-        [XEN_ELFNOTE_LOADER] = { "LOADER", 1},
-        [XEN_ELFNOTE_PAE_MODE] = { "PAE_MODE", 1},
-        [XEN_ELFNOTE_FEATURES] = { "FEATURES", 1},
-        [XEN_ELFNOTE_SUPPORTED_FEATURES] = { "SUPPORTED_FEATURES", 0},
-        [XEN_ELFNOTE_BSD_SYMTAB] = { "BSD_SYMTAB", 1},
-        [XEN_ELFNOTE_L1_MFN_VALID] = { "L1_MFN_VALID", false },
-        [XEN_ELFNOTE_SUSPEND_CANCEL] = { "SUSPEND_CANCEL", 0 },
-        [XEN_ELFNOTE_MOD_START_PFN] = { "MOD_START_PFN", 0 },
-        [XEN_ELFNOTE_PHYS32_ENTRY] = { "PHYS32_ENTRY", 0 },
+        [XEN_ELFNOTE_ENTRY] = { "ENTRY", ELFNOTE_INT },
+        [XEN_ELFNOTE_HYPERCALL_PAGE] = { "HYPERCALL_PAGE", ELFNOTE_INT },
+        [XEN_ELFNOTE_VIRT_BASE] = { "VIRT_BASE", ELFNOTE_INT },
+        [XEN_ELFNOTE_INIT_P2M] = { "INIT_P2M", ELFNOTE_INT },
+        [XEN_ELFNOTE_PADDR_OFFSET] = { "PADDR_OFFSET", ELFNOTE_INT },
+        [XEN_ELFNOTE_HV_START_LOW] = { "HV_START_LOW", ELFNOTE_INT },
+        [XEN_ELFNOTE_XEN_VERSION] = { "XEN_VERSION", ELFNOTE_STRING },
+        [XEN_ELFNOTE_GUEST_OS] = { "GUEST_OS", ELFNOTE_STRING },
+        [XEN_ELFNOTE_GUEST_VERSION] = { "GUEST_VERSION", ELFNOTE_STRING },
+        [XEN_ELFNOTE_LOADER] = { "LOADER", ELFNOTE_STRING },
+        [XEN_ELFNOTE_PAE_MODE] = { "PAE_MODE", ELFNOTE_STRING },
+        [XEN_ELFNOTE_FEATURES] = { "FEATURES", ELFNOTE_STRING },
+        [XEN_ELFNOTE_SUPPORTED_FEATURES] = { "SUPPORTED_FEATURES", ELFNOTE_INT },
+        [XEN_ELFNOTE_BSD_SYMTAB] = { "BSD_SYMTAB", ELFNOTE_STRING },
+        [XEN_ELFNOTE_L1_MFN_VALID] = { "L1_MFN_VALID", ELFNOTE_NAME },
+        [XEN_ELFNOTE_SUSPEND_CANCEL] = { "SUSPEND_CANCEL", ELFNOTE_INT },
+        [XEN_ELFNOTE_MOD_START_PFN] = { "MOD_START_PFN", ELFNOTE_INT },
+        [XEN_ELFNOTE_PHYS32_ENTRY] = { "PHYS32_ENTRY", ELFNOTE_INT },
     };
 /* *INDENT-ON* */
 
@@ -136,8 +140,9 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
         return 0;
     }
 
-    if ( note_desc[type].str )
+    switch ( note_desc[type].type )
     {
+    case ELFNOTE_STRING :
         str = elf_strval(elf, elf_note_desc(elf, note));
         if (str == NULL)
             /* elf_strval will mark elf broken if it fails so no need to log */
@@ -145,13 +150,20 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
         elf_msg(elf, "ELF: note: %s = \"%s\"\n", note_desc[type].name, str);
         parms->elf_notes[type].type = XEN_ENT_STR;
         parms->elf_notes[type].data.str = str;
-    }
-    else
-    {
+        break;
+
+    case ELFNOTE_INT:
         val = elf_note_numeric(elf, note);
         elf_msg(elf, "ELF: note: %s = %#" PRIx64 "\n", note_desc[type].name, val);
         parms->elf_notes[type].type = XEN_ENT_LONG;
         parms->elf_notes[type].data.num = val;
+        break;
+
+    case ELFNOTE_NAME:
+        /* ELFNOTE_NAME has a newline printed at the end of the function to
+         * optionally allow printing customized details. */
+        elf_msg(elf, "ELF: note: %s", note_desc[type].name);
+        break;
     }
     parms->elf_notes[type].name = note_desc[type].name;
 
@@ -218,6 +230,10 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
         parms->phys_entry = val;
         break;
     }
+
+    if ( note_desc[type].type == ELFNOTE_NAME)
+        elf_msg(elf, "\n");
+
     return 0;
 }
 
-- 
2.44.0



From xen-devel-bounces@lists.xenproject.org Tue Mar 26 21:39:07 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Mar 2024 21:39:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698209.1089676 (Exim 4.92)
	(envelope-from )
	id 1rpEVe-0005rK-Lo; Tue, 26 Mar 2024 21:39:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698209.1089676; Tue, 26 Mar 2024 21:39:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpEVe-0005rB-HY; Tue, 26 Mar 2024 21:39:06 +0000
Received: by outflank-mailman (input) for mailman id 698209;
 Tue, 26 Mar 2024 21:39:04 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpEVc-0005qH-QV
 for xen-devel@lists.xenproject.org; Tue, 26 Mar 2024 21:39:04 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on20601.outbound.protection.outlook.com
 [2a01:111:f403:2414::601])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 428672ba-ebb9-11ee-a1ef-f123f15fe8a2;
 Tue, 26 Mar 2024 22:39:02 +0100 (CET)
Received: from CH5P220CA0012.NAMP220.PROD.OUTLOOK.COM (2603:10b6:610:1ef::24)
 by DS7PR12MB6142.namprd12.prod.outlook.com (2603:10b6:8:9a::11) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.33; Tue, 26 Mar
 2024 21:38:56 +0000
Received: from DS3PEPF000099DC.namprd04.prod.outlook.com
 (2603:10b6:610:1ef:cafe::15) by CH5P220CA0012.outlook.office365.com
 (2603:10b6:610:1ef::24) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.13 via Frontend
 Transport; Tue, 26 Mar 2024 21:38:56 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 DS3PEPF000099DC.mail.protection.outlook.com (10.167.17.198) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Tue, 26 Mar 2024 21:38:55 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Tue, 26 Mar
 2024 16:38:55 -0500
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB05.amd.com
 (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Tue, 26 Mar
 2024 16:38:54 -0500
Received: from fedora.mshome.net (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Tue, 26 Mar 2024 16:38:54 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 428672ba-ebb9-11ee-a1ef-f123f15fe8a2
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=BO7GPVLwvJ7Xvz5tfBjY0xcPZenJ6do9Iwm9imK6zOv5zm+o4H6JZzF3ZgrTou/lp/lIaigcf1wj8g9HNh1chXYjeMf/gWbZ0Sq0i6r4o2qLRozU4K0Z43Ca0WqLeYWoCpe+GnRPVCucW4iTV0eZQ4VL09dlSferX6OSL0xOnZtXPi1k6spTGnbYrA3QjKy4MWtq3clRvzaektq2JY9tItLCcJBvuAuqssGWnkYB9PxnFzU+1t3YJuXkPi8F4hfg2V8Lx9Z/2xpCbrTKICbjLJBooYY+tmNgmGRg/kLwCi/l9m37mwaTvQAFD0Q0VHeil46RVKebBLUsT3++szLmfA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=lvOehq1EJKjZfWXBSzZg1ZZ1p5IUUk1AykmRfeyalZA=;
 b=EwGunQdVd4L3KhiHRWPESV8SeC31bR4fnnb3PjIRStJV5lIoccrf7a7W8STPCA4e7qQ79gj+TL6TPy8agESTNsi5AcUkKQEXwzKDZjqj5v8kgEyACe9YM++deJBVXyH/Ccc95GOh79xnmjyBMTCE9dC6WLtw4OAHR2z0vPoOe0U9q7/hWXviuEiG3+WDzP/jHZPCSxI7XFUo1Hd7tVsGARV4bIPMv2HH053whpTnaqJ5glJ4w+TUPm1N8IDxDskVd+pJnT4oVsLda+1KN0CBSOPil/CWFXT2wpo04ExntOFP+2/g/53uHoOchciWKaoBeRO7YipenNhD3CNnMQ3xNw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=lvOehq1EJKjZfWXBSzZg1ZZ1p5IUUk1AykmRfeyalZA=;
 b=CiI6iW//3UFG327VgSO1xLv1nHZe5zfpiXJox7lK51fzzGybI3VeGq7J13v1bOxx4rpANBQHKjGZqC+trmfLMLCHF8pZLeVfpylixsZykYP1UFUnnNLZifoYwzBGqSjPC+eKivX2v52qpZJH0v8xTzdBuBcM60nr6a1y1dTkDcg=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Jason Andryuk 
To: 
CC: Jason Andryuk , Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v5 1/6] Revert "xen/x86: bzImage parse kernel_alignment"
Date: Tue, 26 Mar 2024 17:38:42 -0400
Message-ID: <20240326213847.3944-2-jason.andryuk@amd.com>
X-Mailer: git-send-email 2.44.0
In-Reply-To: <20240326213847.3944-1-jason.andryuk@amd.com>
References: <20240326213847.3944-1-jason.andryuk@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB05.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DS3PEPF000099DC:EE_|DS7PR12MB6142:EE_
X-MS-Office365-Filtering-Correlation-Id: 2c7f5574-5b72-4005-0e8c-08dc4ddd2374
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	LcQv0PL+JTEmhWb1u28GVlPqoKyjVkmrc/p9ljoBrmXOSTIrmy38qdknzMHglDsTGCCuOY/M3qlcZLkTQohkUtIhbQNuOvBi1dHszlg7PnmWVmfHAnMLOkSmnEOmnS9EfkXdnMWUGYJLCRC5camgBixx6kDMi//R30VxhRjlGTcAxLbNrtAjCpS9F94ARkjuBjHN8PfUh10b+03FT9+hYIcGykZ1ltdWZnDYCFvMLP3uVCJ3p/ldnvfTyypEFfFn/XGPOBlYnvqxqljfD6w/yVrGhsVaWlMWIL8yx6FIwCkT3+ZJyoUQL73g6/zXd4Bz2XjY9VRxTVbIXnrITw8KQ88Rqm/XcBq1qso9/VbvXNJsHr3oWHU0AzX5d1EKayDLWoKP9HndD9G7zyswykj1g/LdvMKLaQcca8En42ykcQ4cSjPp1lfe5E9vFzN2THFTOiI/EaQJ/oHQeLiEVZfG477+5Vs1eXJSGayaSrit29+0wu1D9TrRju4TtSikWwNNvxU3OfEYg1CoNFDTvVzgZ1+StRUqcGOE6HhIJyH8j6ETHd861yGkY5C66sFiArc6b3GyE7++KOwofsygEhGk64f/2Ip5d+MdyxV9n0Yj3RKy2AkPN89aBTdTurZM47KqxX6SyfR1Bj07jwkjhVbts9+9aySDOBRKizw3A9ZmzQXHVeIj6msWtIPlCFdZCtBTl5R6b6jyON0w7dbVglc0R9BbF5xOrVGGYRY7lsdXK2ujUDSgZQw4KZF0ZRrqL9R4
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(36860700004)(82310400014)(376005)(1800799015);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Mar 2024 21:38:55.6906
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 2c7f5574-5b72-4005-0e8c-08dc4ddd2374
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DS3PEPF000099DC.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR12MB6142

A new ELF note will specify the alignment for a relocatable PVH kernel.
ELF notes are suitable for vmlinux and other ELF files, so this
Linux-specific bzImage parsing in unnecessary.

This reverts commit c44cac229067faeec8f49247d1cf281723ac2d40.

Signed-off-by: Jason Andryuk 
---
 xen/arch/x86/bzimage.c             | 4 +---
 xen/arch/x86/hvm/dom0_build.c      | 4 +---
 xen/arch/x86/include/asm/bzimage.h | 2 +-
 xen/arch/x86/pv/dom0_build.c       | 2 +-
 4 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/xen/arch/x86/bzimage.c b/xen/arch/x86/bzimage.c
index 0f4cfc49f7..ac4fd428be 100644
--- a/xen/arch/x86/bzimage.c
+++ b/xen/arch/x86/bzimage.c
@@ -105,7 +105,7 @@ unsigned long __init bzimage_headroom(void *image_start,
 }
 
 int __init bzimage_parse(void *image_base, void **image_start,
-                         unsigned long *image_len, unsigned int *align)
+                         unsigned long *image_len)
 {
     struct setup_header *hdr = (struct setup_header *)(*image_start);
     int err = bzimage_check(hdr, *image_len);
@@ -118,8 +118,6 @@ int __init bzimage_parse(void *image_base, void **image_start,
     {
         *image_start += (hdr->setup_sects + 1) * 512 + hdr->payload_offset;
         *image_len = hdr->payload_length;
-        if ( align )
-            *align = hdr->kernel_alignment;
     }
 
     if ( elf_is_elfbinary(*image_start, *image_len) )
diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index bbae8a5645..0ceda4140b 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -548,14 +548,12 @@ static int __init pvh_load_kernel(struct domain *d, const module_t *image,
     struct elf_binary elf;
     struct elf_dom_parms parms;
     paddr_t last_addr;
-    unsigned int align = 0;
     struct hvm_start_info start_info = { 0 };
     struct hvm_modlist_entry mod = { 0 };
     struct vcpu *v = d->vcpu[0];
     int rc;
 
-    rc = bzimage_parse(image_base, &image_start, &image_len, &align);
-    if ( rc != 0 )
+    if ( (rc = bzimage_parse(image_base, &image_start, &image_len)) != 0 )
     {
         printk("Error trying to detect bz compressed kernel\n");
         return rc;
diff --git a/xen/arch/x86/include/asm/bzimage.h b/xen/arch/x86/include/asm/bzimage.h
index 2e04f5cc7b..7ed69d3910 100644
--- a/xen/arch/x86/include/asm/bzimage.h
+++ b/xen/arch/x86/include/asm/bzimage.h
@@ -6,6 +6,6 @@
 unsigned long bzimage_headroom(void *image_start, unsigned long image_length);
 
 int bzimage_parse(void *image_base, void **image_start,
-                  unsigned long *image_len, unsigned int *align);
+                  unsigned long *image_len);
 
 #endif /* __X86_BZIMAGE_H__ */
diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c
index e9fa8a9a82..d8043fa58a 100644
--- a/xen/arch/x86/pv/dom0_build.c
+++ b/xen/arch/x86/pv/dom0_build.c
@@ -416,7 +416,7 @@ int __init dom0_construct_pv(struct domain *d,
 
     d->max_pages = ~0U;
 
-    if ( (rc = bzimage_parse(image_base, &image_start, &image_len, NULL)) != 0 )
+    if ( (rc = bzimage_parse(image_base, &image_start, &image_len)) != 0 )
         return rc;
 
     if ( (rc = elf_init(&elf, image_start, image_len)) != 0 )
-- 
2.44.0



From xen-devel-bounces@lists.xenproject.org Tue Mar 26 21:39:08 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Mar 2024 21:39:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698208.1089666 (Exim 4.92)
	(envelope-from )
	id 1rpEVa-0005c4-Df; Tue, 26 Mar 2024 21:39:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698208.1089666; Tue, 26 Mar 2024 21:39:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpEVa-0005bx-Av; Tue, 26 Mar 2024 21:39:02 +0000
Received: by outflank-mailman (input) for mailman id 698208;
 Tue, 26 Mar 2024 21:39:01 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpEVZ-0005br-1O
 for xen-devel@lists.xenproject.org; Tue, 26 Mar 2024 21:39:01 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on20600.outbound.protection.outlook.com
 [2a01:111:f403:2415::600])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 408339bb-ebb9-11ee-afe3-a90da7624cb6;
 Tue, 26 Mar 2024 22:38:59 +0100 (CET)
Received: from SJ0PR13CA0089.namprd13.prod.outlook.com (2603:10b6:a03:2c4::34)
 by IA1PR12MB6652.namprd12.prod.outlook.com (2603:10b6:208:38a::10)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.33; Tue, 26 Mar
 2024 21:38:55 +0000
Received: from SJ5PEPF000001D6.namprd05.prod.outlook.com
 (2603:10b6:a03:2c4:cafe::44) by SJ0PR13CA0089.outlook.office365.com
 (2603:10b6:a03:2c4::34) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.12 via Frontend
 Transport; Tue, 26 Mar 2024 21:38:55 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 SJ5PEPF000001D6.mail.protection.outlook.com (10.167.242.58) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Tue, 26 Mar 2024 21:38:54 +0000
Received: from SATLEXMB08.amd.com (10.181.40.132) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Tue, 26 Mar
 2024 16:38:53 -0500
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB08.amd.com
 (10.181.40.132) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Tue, 26 Mar
 2024 14:38:52 -0700
Received: from fedora.mshome.net (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Tue, 26 Mar 2024 16:38:52 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 408339bb-ebb9-11ee-afe3-a90da7624cb6
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=Y4ukPyC5A00Oyk2ZaHpqKCu1UPS0pz4mWPU8f25UuQoYSuHxEN+9NAo+uUWX9cDT+we5OBOrC11Lar6RllwrddlPxeLt7hSa4amGAfMWHi+/GUY9B/uMp2Ehu9ffy6d0Px65CgBI6SjQ7Vzn+E2yvJY84LbIh3mBjh5hGBwxw293Ui81YFPqIrGd+GCmNvRlgih8j0XgXgwEVO7bb2P/gE+S2A+2kxKzvEQrsvEmfmYlRv+wXmANp9C6KB6E44s3mxYVUujJkHrjUrUPqiHpWJ18UkPDYvYqvuuie7lq8Ym5WgmriAFaPJBnpdMyYLMyYLwC/G28jxNZfT7oSLmR0g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=LwtkrJN7ACGn2gJq6icIRADQJTBXKuFjDY6R+BJAPc0=;
 b=f3ASPla7EPbWmZzcMgx4MAiZ7jI18HmZ6ffgNmmCddJTu/wNEv9ETqPodbE5IfbKDlcQSV14p57TU0mHPv5BoTqmNogOsU31E+pFhYdrxcJQsa4yw1ptPvjNyswY/84UKjInvngd6EhCVtb+OBk63dMWBaLXPFrsXFhKmLiYyXyDL9havsJ9XuR/MwAo71a0SseKAMyxdX9u/swD3/yAUFthS+oAHE0QfFuL6OXWD1gkRa3zcbfLxMTeMXE9ffBMK57kicIm8buowWjqC5hDXAk1KkckLRe/N/RoEUVkp3ekDY6hIWlUV6c8e5pP74Qa+HdaHEU6DZ2jmvjSWTlWFg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=LwtkrJN7ACGn2gJq6icIRADQJTBXKuFjDY6R+BJAPc0=;
 b=bZfMD31N0bj2m+Px5wffwXfVO56CpL/XFdQ0Qqp7O88gnfU55yz7Klp24ytL041zhYi/ZYmDEtRG6JmVcXyBWEfA2yoe0rpI8db+Lo4aZ6xlyWb0pxCy1NR0T7kvU27znYdlyFFl3cv6k/tQVhKxOngoogodA9Az+B0TXAwm/5g=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
From: Jason Andryuk 
To: 
CC: Jason Andryuk , Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Juergen Gross
	, Julien Grall , Anthony PERARD
	, George Dunlap ,
	Stefano Stabellini 
Subject: [PATCH v5 0/6] x86/pvh: Support relocating dom0 kernel
Date: Tue, 26 Mar 2024 17:38:41 -0400
Message-ID: <20240326213847.3944-1-jason.andryuk@amd.com>
X-Mailer: git-send-email 2.44.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ5PEPF000001D6:EE_|IA1PR12MB6652:EE_
X-MS-Office365-Filtering-Correlation-Id: df90bb95-5e46-486c-e398-08dc4ddd22b2
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	sLaUO67LZjY/qrL/SDnRjHfHsHDs/7NZAkzLcwidNhc8kKR7jeq598A4vWN2bMsnpmnA2h44mQIhWHOfN1rKvWNbKzFlQ5Lj16mkkUNTEGCiFA0y8U/MBoV3GbRoVv6wI4QM2YQsSE8E+Y+EZZwFzAfGQ5qj7t6gM6wvUhfjHxVPj6s2i3lkHVgaNkRRc2SJaRykQn482hy4oWxAnEgCWVhBU/HDDl0mt5I2Xi14sJALEFWproqM1HYXHVGhgGn/ersEi4aJzVnZQgoVhpi9RaL2inWFGLKxUJHXJ+3kBpdwmILbeUlP6lHhQu5z8qpywXRkfR42zlAKF52Bpc3MNcry/AClvlGGJpIL04/yhsjnkkkUat5MzBFp7+rU+hBd+VSF7INsZjxhlVCzCgACOcsGxzdi1rq6UrE4p1l4phJGdKJ6c/1sUbsuwFz/UV3RTG7zZNom7Mxs4D7z6j0DK417qtLECPf8+Oijk7QA04nyKuUP4cqF69B5Fc9612CSxzluVRk9v24tTwkrhKIEK1CpIJD/8bvKt0ibuZtfPYhh7KOKGf612cA6CXAYNdGXiwDQraAUxQMD8uHjg3p3K3fwdLWJKIxjIyDrLtU6Alyj6RWmujUf2hcsuZ8/FZgbzf9GBCvhOytvVBr7Hi0XEAyA4uqz6YHZc1wNo6cAC7282YZ3Ip0ZZCMRXt4ctp+mzJcnVztfg0KNOGprD9J7ooVFJqfWPHUXjmfCgSmRxrMtub0K7Dnp8XxutgC5Jt3x
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(376005)(82310400014)(36860700004)(1800799015);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Mar 2024 21:38:54.2371
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: df90bb95-5e46-486c-e398-08dc4ddd22b2
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ5PEPF000001D6.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB6652

Xen tries to load a PVH dom0 kernel at the fixed guest physical address
from the elf headers.  For Linux, this defaults to 0x1000000 (16MB), but
it can be configured.

Unfortunately there exist firmwares that have reserved regions at this
address, so Xen fails to load the dom0 kernel since it's not RAM.

The other issue is that the Linux PVH entry point is not
position-independent.  It expects to run at the compiled
CONFIG_PHYSICAL_ADDRESS.

This patch set expands the PVH dom0 builder to try to relocate the
kernel if needed and possible.  XEN_ELFNOTE_PHYS32_RELOC is added for
kernels to indicate they are relocatable and their acceptable address
range and alignment.

The first patch reverts "xen/x86: bzImage parse kernel_alignment" since
the alignment will be specified by the ELF note.

The second and third patches move MB/GB() to common-macros.h.

The fourth patch expands ELF note printing beyond just printing
integers and strings.

The fifth patch expands specifies the Xen ELF Notes are x86-specific.

The sixth patch expands the pvh dom0 kernel placement code.

I'll post an additional patch showing the Linux changes to make PVH
relocatable.

Jason Andryuk (6):
  Revert "xen/x86: bzImage parse kernel_alignment"
  tools/init-xenstore-domain: Replace variable MB() usage
  tools: Move MB/GB() to common-macros.h
  libelf: Expand ELF note printing
  xen/elfnote: Specify ELF Notes are x86-specific
  x86/PVH: Support relocatable dom0 kernels

 tools/firmware/hvmloader/util.h         |   3 -
 tools/helpers/init-xenstore-domain.c    |  11 ++-
 tools/include/xen-tools/common-macros.h |   4 +
 tools/libs/light/libxl_internal.h       |   4 -
 xen/arch/x86/bzimage.c                  |   4 +-
 xen/arch/x86/hvm/dom0_build.c           | 104 +++++++++++++++++++++++-
 xen/arch/x86/include/asm/bzimage.h      |   2 +-
 xen/arch/x86/pv/dom0_build.c            |   2 +-
 xen/common/libelf/libelf-dominfo.c      |  99 ++++++++++++++++------
 xen/common/libelf/libelf-private.h      |   1 +
 xen/include/public/elfnote.h            |  18 +++-
 xen/include/xen/libelf.h                |   4 +
 12 files changed, 213 insertions(+), 43 deletions(-)

-- 
2.44.0



From xen-devel-bounces@lists.xenproject.org Tue Mar 26 21:39:08 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Mar 2024 21:39:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698212.1089705 (Exim 4.92)
	(envelope-from )
	id 1rpEVg-0006Yt-On; Tue, 26 Mar 2024 21:39:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698212.1089705; Tue, 26 Mar 2024 21:39:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpEVg-0006XR-L2; Tue, 26 Mar 2024 21:39:08 +0000
Received: by outflank-mailman (input) for mailman id 698212;
 Tue, 26 Mar 2024 21:39:06 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpEVe-0005qH-G8
 for xen-devel@lists.xenproject.org; Tue, 26 Mar 2024 21:39:06 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on20601.outbound.protection.outlook.com
 [2a01:111:f403:2412::601])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 439217fb-ebb9-11ee-a1ef-f123f15fe8a2;
 Tue, 26 Mar 2024 22:39:04 +0100 (CET)
Received: from SJ0PR03CA0024.namprd03.prod.outlook.com (2603:10b6:a03:33a::29)
 by CH2PR12MB4311.namprd12.prod.outlook.com (2603:10b6:610:a8::21)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.33; Tue, 26 Mar
 2024 21:39:00 +0000
Received: from SJ5PEPF000001D7.namprd05.prod.outlook.com
 (2603:10b6:a03:33a:cafe::47) by SJ0PR03CA0024.outlook.office365.com
 (2603:10b6:a03:33a::29) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.13 via Frontend
 Transport; Tue, 26 Mar 2024 21:39:00 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 SJ5PEPF000001D7.mail.protection.outlook.com (10.167.242.59) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Tue, 26 Mar 2024 21:39:00 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Tue, 26 Mar
 2024 16:38:58 -0500
Received: from fedora.mshome.net (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Tue, 26 Mar 2024 16:38:58 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 439217fb-ebb9-11ee-a1ef-f123f15fe8a2
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=j/aUWTxxnB+4ADVXpIXQhAlyWQDDi4wtL8QXqIDF8pwuKEGwTOaN2U2q4UAWgGi+cvFvLcEtrSNH4ouJiZ6KMghTknMUo4Ze2y0GdiPDBFuikwXh6e7QEoR6iulDpy+jEDrHAY2JKvSFNZ9gitjoEKIM7AH+Y4a8ttIv9vCod61piz0ZMkN9jF6ZyKqnFustXBWVFfIP3wnV2hvr1KI9yHMpB6+3eP3+hNvzqxbieQq+szW+9tmEQux4KGIzSFyaWl1OgUO6kVuTegHqbKdtEgGd1Fd5Cdx384AbEQO+83WsC2D/ekkCEezcB9Vhg27g4V5FYn1Y5HHceqsYcUkZrg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=sQPi9MnxIxYvNcw+aMSnS9BZzf8Q8kjV58jecRQgAtM=;
 b=mMb9gnMVKCrlD2zrXMBwuW5D1fOxk45Yk/xVmVJDjxisS8dq0WlRxUP/5jfyF2lwskskoPlIe93bVIDRSLXZEanEOqmMtEqj/R5f+iF/vDKI4dmQPt3pQizTdL1UutWolWQWlmC+dOwP0RcG3UrjstVeVW4d9NwrhupKTzNDi7xwQ4REWiYgqxXL+njee0ZmGqt1iKEKTjymQRw7qfUB/x1zhep/XRfKzcrdE8Emvv1keaIDLGIQ6UUn6IQvAgopWcjZVN5JVk4wL0AWekQgrXtwbxtOrJVX56txr1p7OkPF2MB4aHyCEFVriQlifUUchap48ADAUlCxnG08jUdRPQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=sQPi9MnxIxYvNcw+aMSnS9BZzf8Q8kjV58jecRQgAtM=;
 b=ra1ACj2y/OKG+FBW7Op5nZew7G4bZFeh3BoL8xN+BNSLfVCWd3uvSm2Jy9qH0Yt5pH9Oa0mwh4PV20m1OTFkxjFQT653YkQwjUdrWOresDLyooY/u1NJ5O2ahxKIU4NPBiXNlEE3DVcSyMletC3W2Ilzdu5HBUceP8oJ+eNMAy4=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
From: Jason Andryuk 
To: 
CC: Jason Andryuk , Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Anthony PERARD
	, Juergen Gross , Julien Grall
	
Subject: [PATCH v5 3/6] tools: Move MB/GB() to common-macros.h
Date: Tue, 26 Mar 2024 17:38:44 -0400
Message-ID: <20240326213847.3944-4-jason.andryuk@amd.com>
X-Mailer: git-send-email 2.44.0
In-Reply-To: <20240326213847.3944-1-jason.andryuk@amd.com>
References: <20240326213847.3944-1-jason.andryuk@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB03.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ5PEPF000001D7:EE_|CH2PR12MB4311:EE_
X-MS-Office365-Filtering-Correlation-Id: 45580c16-8562-4a35-2c2e-08dc4ddd2641
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	b2sMrpm8SgUg2h8oMvx7/yxjFe+H1fuXfBLhmSZzST9EcIYwajvyDmDXknr4jMCuWlLsjIe3w1N92gxDEUT4rWNGAUtGLjwuq1ff4Mt/iouXdTIEOkk2jgl7pmBZtWTaBIKI0Mh8uAPnS7C6mNEnE7ByDZzN/0pnsf/Br06zTdG2BeZO2Ku1N/+WRhrEDSc8vWmeT5hSGkZPg2gs1BzXNTWr00MWhfCBRLw8FwmQX+YTKn2+lF3z4eY7e3/JxpMHQQO+L4g7Sj77bnLp5UqFJpdNaO5ZWXGRalTv3NkLmDZzV3nNh5URIEjCwaZxJ+knZczBip8q31fxHjtKt4VnQ8DgPANSNJ6WKObnqU7GLwVVS/PnKN0fiMok7V0a+VC7eDCC3AzVDtEVgq4MckLSs9Sy4o8nhDW4oNozq+Hns4h5pFs6DiKK6636OoxnWmBEcmQLX2181wIbjXjKqdEhMkg+gkSr6tQqW3bdU2Jmn/2EgjvesB85umugxTJkvsYTefpPdkFbR/rf53KBkmp6utVi1nOItDsCz0QsbRUsI1UwV1xNq4mkuJn0hITpGMx5T38UEgEgkmZhIpT46c5tJ86Wdu9zspAKKvcgGzCacxDPQWIMh2rHzUsvQta7dLIdKWGpuI7UYi1Lw/xZk4dmv1jGvQ38kpfugvWFh8r3fEzS7cHbljwj49XkK55nKwiQ+tUKxkR3U4Pmaoj3TjKJbVhw1G2mSGknh4L5J+g5LpsycDAGGhLCtISQdb9Vff5l
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(1800799015)(376005)(82310400014)(36860700004);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Mar 2024 21:39:00.2340
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 45580c16-8562-4a35-2c2e-08dc4ddd2641
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ5PEPF000001D7.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR12MB4311

Consolidate to a single set of common macros for tools.

MB() will gain another use in libelf, so this movement makes it
available.

Requested-by: Jan Beulich 
Signed-off-by: Jason Andryuk 
Reviewed-by: Jan Beulich 
---
v4:
New

v5:
Add Jan's R-b & Req-b
---
 tools/firmware/hvmloader/util.h         | 3 ---
 tools/helpers/init-xenstore-domain.c    | 1 -
 tools/include/xen-tools/common-macros.h | 4 ++++
 tools/libs/light/libxl_internal.h       | 4 ----
 4 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/tools/firmware/hvmloader/util.h b/tools/firmware/hvmloader/util.h
index 87be213dec..14078bde1e 100644
--- a/tools/firmware/hvmloader/util.h
+++ b/tools/firmware/hvmloader/util.h
@@ -38,9 +38,6 @@ void __bug(const char *file, int line) __attribute__((noreturn));
 #define BUG() __bug(__FILE__, __LINE__)
 #define BUG_ON(p) do { if (p) BUG(); } while (0)
 
-#define MB(mb) (mb##ULL << 20)
-#define GB(gb) (gb##ULL << 30)
-
 static inline int test_bit(unsigned int b, const void *p)
 {
     return !!(((const uint8_t *)p)[b>>3] & (1u<<(b&7)));
diff --git a/tools/helpers/init-xenstore-domain.c b/tools/helpers/init-xenstore-domain.c
index 5405842dfe..f38ba8d6b5 100644
--- a/tools/helpers/init-xenstore-domain.c
+++ b/tools/helpers/init-xenstore-domain.c
@@ -20,7 +20,6 @@
 #include "init-dom-json.h"
 
 #define LAPIC_BASE_ADDRESS  0xfee00000UL
-#define GB(x)               ((uint64_t)x << 30)
 
 static uint32_t domid = ~0;
 static char *kernel;
diff --git a/tools/include/xen-tools/common-macros.h b/tools/include/xen-tools/common-macros.h
index 81fba2e9f5..07aed92684 100644
--- a/tools/include/xen-tools/common-macros.h
+++ b/tools/include/xen-tools/common-macros.h
@@ -91,6 +91,10 @@
 #define __AC(X, Y)   (X ## Y)
 #define _AC(X, Y)    __AC(X, Y)
 
+/* Size macros. */
+#define MB(_mb)     (_AC(_mb, ULL) << 20)
+#define GB(_gb)     (_AC(_gb, ULL) << 30)
+
 #define get_unaligned_t(type, ptr) ({                               \
     const struct { type x; } __packed *ptr_ = (typeof(ptr_))(ptr);  \
     ptr_->x;                                                        \
diff --git a/tools/libs/light/libxl_internal.h b/tools/libs/light/libxl_internal.h
index 094d0df9b1..803dbc1a03 100644
--- a/tools/libs/light/libxl_internal.h
+++ b/tools/libs/light/libxl_internal.h
@@ -126,10 +126,6 @@
 #define PVSHIM_BASENAME "xen-shim"
 #define PVSHIM_CMDLINE "pv-shim console=xen,pv"
 
-/* Size macros. */
-#define MB(_mb)     (_AC(_mb, ULL) << 20)
-#define GB(_gb)     (_AC(_gb, ULL) << 30)
-
 #define DIV_ROUNDUP(n, d) (((n) + (d) - 1) / (d))
 
 #define LIBXL__LOGGING_ENABLED
-- 
2.44.0



From xen-devel-bounces@lists.xenproject.org Tue Mar 26 21:39:11 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Mar 2024 21:39:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698213.1089716 (Exim 4.92)
	(envelope-from )
	id 1rpEVj-0006tN-3L; Tue, 26 Mar 2024 21:39:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698213.1089716; Tue, 26 Mar 2024 21:39:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpEVi-0006tA-WF; Tue, 26 Mar 2024 21:39:11 +0000
Received: by outflank-mailman (input) for mailman id 698213;
 Tue, 26 Mar 2024 21:39:09 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpEVh-0005qH-Jw
 for xen-devel@lists.xenproject.org; Tue, 26 Mar 2024 21:39:09 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on2060c.outbound.protection.outlook.com
 [2a01:111:f400:7e88::60c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 45bb9f4e-ebb9-11ee-a1ef-f123f15fe8a2;
 Tue, 26 Mar 2024 22:39:07 +0100 (CET)
Received: from BYAPR01CA0043.prod.exchangelabs.com (2603:10b6:a03:94::20) by
 SJ2PR12MB7799.namprd12.prod.outlook.com (2603:10b6:a03:4d3::12) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.28; Tue, 26 Mar
 2024 21:39:04 +0000
Received: from SJ5PEPF000001D1.namprd05.prod.outlook.com
 (2603:10b6:a03:94:cafe::32) by BYAPR01CA0043.outlook.office365.com
 (2603:10b6:a03:94::20) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.13 via Frontend
 Transport; Tue, 26 Mar 2024 21:39:04 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 SJ5PEPF000001D1.mail.protection.outlook.com (10.167.242.53) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Tue, 26 Mar 2024 21:39:03 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Tue, 26 Mar
 2024 16:39:02 -0500
Received: from fedora.mshome.net (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Tue, 26 Mar 2024 16:39:01 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 45bb9f4e-ebb9-11ee-a1ef-f123f15fe8a2
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=hw6oZ3dbFjT78Uq8gPrlFnjvHDrr8oFTozbQkUpX11+de4mwTS+EKS4FyZ/ivQcZjSpG8ekzILF2bk+i5dqrVXxK00QB5bg6uHMOyMR3/t4yVcnb/TqZxbfN41tUv/eg86ajBJZpz6qcVlj7cqxXlS1xvDfZUnm9sUlITE5KNQEoWW7aIw03x4I6P0I6R31e3fENRDxI0HwEtJ2StDQxUydviAx2Rg0/gFPt1jRlVgg9hSYbJG4kd0mMFUzttvqt2N38vR/bVmOQil14mk+hEu0Sc21k3zTmKekyl/SHMMfsOuc1NnTyr4JwhnzgkLUni0JlWfbv8Gjyq1ieE2dICg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=TUHahSKteoMzLlSudCvzefdtpHOZ4svXrCedT2722Zc=;
 b=HuHpV+LxuynrTNOoWg51b/y5xYh+tRmwzVEbnhlyKqEXNBrb66u20qqKdIl8XGCmg0yWE+AcwXP+jXMEzYaQvyrQsMU9BDe9Fhkl50ibEzjHfnsRDO/KiLKurUaXB+P1H3XqZslFJJvvCUb6Hj9BzUZznyzNhfYm2+y+8N1b5XBGKFbpcrbkAZg7Ep13kToklvURy7yvfj3gCBVTZGDKucLlL1I95TZ1HZCHiqNO3RBQ15DHPcvFXnAsEjLQSUfmK71VDldz+QIBGlxQYWL77505rhZ7uu6JHxd0SZk5H1hPtNAbmzL+I7Lxp32I0L0OX+Lu/O6weytg1nUb4KKplA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=TUHahSKteoMzLlSudCvzefdtpHOZ4svXrCedT2722Zc=;
 b=ZNq2YrdAVCpyFimtJkDeYIUEWaSXA9hm4d8r3rgHa2E2WaFu6rvQqM91vE2RBSrMjP6FQ8Mx2xtbirvvwniZq9hGP1z2ukMYf7yPZ/hsdnTC7Yhi9rgKOFB9EOEl98wtNv5DIHpgBIy2a+Xe2p7q1qWPe3bwQDVYSJYG+upfdIc=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
From: Jason Andryuk 
To: 
CC: Jason Andryuk , Andrew Cooper
	, George Dunlap , "Jan
 Beulich" , Julien Grall , "Stefano
 Stabellini" 
Subject: [PATCH v5 5/6] xen/elfnote: Specify ELF Notes are x86-specific
Date: Tue, 26 Mar 2024 17:38:46 -0400
Message-ID: <20240326213847.3944-6-jason.andryuk@amd.com>
X-Mailer: git-send-email 2.44.0
In-Reply-To: <20240326213847.3944-1-jason.andryuk@amd.com>
References: <20240326213847.3944-1-jason.andryuk@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB03.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ5PEPF000001D1:EE_|SJ2PR12MB7799:EE_
X-MS-Office365-Filtering-Correlation-Id: 1093dde7-b8e2-4534-6c27-08dc4ddd2827
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	/mA7qSIhMpCL9jKqXHz54+2tHRlGxMN+H7hNYfjfTHk1cBi25venHSjdJ9OT9XHPBSdQSwF658Fq7bwDsl2weLYtrlygG0coQOOOmXWEXPIS9IiC+OuLmtXNG7ebryD3Fgkwr4HWwG6h8oQzJvcjabt8gWN41NJKeZ5N6QATe/pfLo+8LZQgrFBdIU7+gvWoFRYr2aEZfYTX87MKEJ3PuXRl3M5zSOyXQxYP5xgRq+aV16BCn+BI2KHzmLN59E7BvzTK2bYEv0Xa/MD3/Wz1mYEr6nRdKb700lJ9DTMxwQqs6/V/tm8nTp9hX0D0Jrl1hhoaXLy4tP9P7DZgQur3StsnOmbf4HWUu97jHvct+FWopImw8HxZosaW7qeJyJ4hXvlpIlZRNlX3Zv40TYLy4RHq7On9BdRjNYRuKMYFFiACZjtoVNYt/juZqjZs3eFco4jrqF3qLG3zCgdxhDF+FYx8kDI+YQmrQT8VZK3748mkfkr4y8n4IpPaMPWknpct2ci0H+HJB1Jp31EVSMq84inQ9ytaBeIDanQRIGG0xPI1jsBv/XcahF4NFU52nJf64kW1n5WGfNvghOCXIqpEPS4EwyGltxKg2V3oLKhRaokk1KnxnJcTsYIHETq1t7iAxWxXTsSko0n2ac6gbIG0fUE7KJVtfgKpaSsslBWphim4gVPp6v4X7yD05LDBRwic2kOBhCx00TxpKahyc5MOVzLEzRU6JNQSYhqellHrrvIv4L860bLJTzrl0T7j/j/T
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(376005)(1800799015)(36860700004)(82310400014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Mar 2024 21:39:03.4051
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 1093dde7-b8e2-4534-6c27-08dc4ddd2827
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ5PEPF000001D1.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB7799

The Xen ELF Notes are only used with x86.  libelf's elf_xen_note_check()
exits early for ARM binaries with "ELF: Not bothering with notes on
ARM".

Add a comment to the top of elfnote.h specifying that Notes are only used
with x86 binaries.  This is to avoid adding disclaimers for individual
notes.

Signed-off-by: Jason Andryuk 
---
 xen/include/public/elfnote.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/xen/include/public/elfnote.h b/xen/include/public/elfnote.h
index 8bf54d035b..1d84b05f44 100644
--- a/xen/include/public/elfnote.h
+++ b/xen/include/public/elfnote.h
@@ -24,6 +24,8 @@
  *
  * String values (for non-legacy) are NULL terminated ASCII, also known
  * as ASCIZ type.
+ *
+ * Xen only uses ELF Notes contained in x86 binaries.
  */
 
 /*
-- 
2.44.0



From xen-devel-bounces@lists.xenproject.org Tue Mar 26 21:39:13 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Mar 2024 21:39:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698214.1089726 (Exim 4.92)
	(envelope-from )
	id 1rpEVl-0007Cs-Co; Tue, 26 Mar 2024 21:39:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698214.1089726; Tue, 26 Mar 2024 21:39:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpEVl-0007Ch-9d; Tue, 26 Mar 2024 21:39:13 +0000
Received: by outflank-mailman (input) for mailman id 698214;
 Tue, 26 Mar 2024 21:39:12 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpEVk-0005qH-7C
 for xen-devel@lists.xenproject.org; Tue, 26 Mar 2024 21:39:12 +0000
Received: from NAM04-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam04on20600.outbound.protection.outlook.com
 [2a01:111:f403:2409::600])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 471d072e-ebb9-11ee-a1ef-f123f15fe8a2;
 Tue, 26 Mar 2024 22:39:10 +0100 (CET)
Received: from BYAPR01CA0071.prod.exchangelabs.com (2603:10b6:a03:94::48) by
 IA0PR12MB8931.namprd12.prod.outlook.com (2603:10b6:208:48a::14) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.32; Tue, 26 Mar
 2024 21:39:06 +0000
Received: from SJ5PEPF000001D1.namprd05.prod.outlook.com
 (2603:10b6:a03:94:cafe::61) by BYAPR01CA0071.outlook.office365.com
 (2603:10b6:a03:94::48) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.13 via Frontend
 Transport; Tue, 26 Mar 2024 21:39:06 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 SJ5PEPF000001D1.mail.protection.outlook.com (10.167.242.53) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Tue, 26 Mar 2024 21:39:05 +0000
Received: from SATLEXMB08.amd.com (10.181.40.132) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Tue, 26 Mar
 2024 16:39:04 -0500
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB08.amd.com
 (10.181.40.132) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Tue, 26 Mar
 2024 14:39:03 -0700
Received: from fedora.mshome.net (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Tue, 26 Mar 2024 16:39:03 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 471d072e-ebb9-11ee-a1ef-f123f15fe8a2
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=Vk4tTFBwzfm3WrZwxh1fbXAgp0oFWVzVwG9sGFHrwwedZXpFIM89Jghyp7xdDYSsiU9yRBiyRyr/1w23KxOil5au5bOHTmjgrVp+K6VvfOhA+urA2lacNhbrKE7WVW9ZIumBYHGfc7WTvT1ZELSnJdD2mElKKye+wVDpV9HuCfC7Em0tVbdNHBw3py50SD+j6ix+eozFb+A0ahrdAk5ohjkatEsMyNAPZGNYXeE4r1nX3cxWS5R4oVuepzRGtk1VJ+6ejwSr5v+Bnzflo0aV7b1DGM2qo/o7J96T+ZNBUgFCBsJSNVumiJVleGNkku8/5HZhRnu7f8ItEWsqqFbsuQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=f1Kzo5ZXCrluOqITBGR/d/TY+cxOJ4iyMxaQjfrpEA8=;
 b=cmQo1NiiClGGSkJL41cLXbuGCKhx3iMh71jdyFIlgRwSaNGcaiarMt2HbsMaO8qLiqbEmHvW2Is52t+i8zllBjY4INeroOw/WRMce4++h7QMTXJVr3MWimCuV1HcoNb/EhHAoCeHdTN8w50WcY5QfG+kdvVnc/+GQC5b12Z6fOkwzV8pl+714Ji6SlQvJ28AY63hL75HnuG/UZsHoUXZJKAabQQVaqCN6QsrnqQtOYRtmj5Sii1ZOf2TlyFh6NSwfkixU3IZiOnsWpkDzs8fts6L9KSm4WENBtfR2nwoKcs/XNCxgvyTeNs+joCkItmIWuQnyrNB8/olAO0NbpDCsg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=f1Kzo5ZXCrluOqITBGR/d/TY+cxOJ4iyMxaQjfrpEA8=;
 b=FGgP/CnARkBExCjDgJraLLFw/IP2dpA17ANPG80OF0nrhuYt5EVoBjs0lbym+oH+L9Yu6O/VZmQXr08GgQ+jWtbR8sDYIY74jOrAEWuZphx0nOh611WdhcDBYihAQHKuZ0bSDH4EpfjEGuISAlBF51deQOYC4CYb5Odf57MTFZA=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
From: Jason Andryuk 
To: 
CC: Jason Andryuk , Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , George Dunlap
	, Julien Grall , Stefano Stabellini
	
Subject: [PATCH v5 6/6] x86/PVH: Support relocatable dom0 kernels
Date: Tue, 26 Mar 2024 17:38:47 -0400
Message-ID: <20240326213847.3944-7-jason.andryuk@amd.com>
X-Mailer: git-send-email 2.44.0
In-Reply-To: <20240326213847.3944-1-jason.andryuk@amd.com>
References: <20240326213847.3944-1-jason.andryuk@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ5PEPF000001D1:EE_|IA0PR12MB8931:EE_
X-MS-Office365-Filtering-Correlation-Id: 000b88ba-4044-4e0e-5be5-08dc4ddd299b
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	6aH2XGw6pkh7K6z0hRVr24oMv/ZmJlgQIX2OdfBD8hHfq+36tIH7rjDHqdpOcmKlPQ2LdHTguzHE9IClSG16gElVyVKMg7zXdTF6Pf6a4d6fsHCKVcCuoFapLkScAwJubVibaz4+IXXE4bUkujnaaAN2OBIX7ENKRlc1XdJFzQATX5Gzw+1z2+he5G88LsMF0r4jSllw77PSVaQ8dYqsCFp+VVXEmKaI/4xZFIEI7cwdXEaIhnuSFpKRnHg/wNc+brETztdEA6YLaBuL7zDMZcJDW8Wd7QpT1jyDmYSKwW8TS/ZfEGYfQsI6IaoJZCA7NZ/zt9nXcnxbbY+AKH/8hwb5ncVeqTqYQpN6VH06zvgUizyBGXq4svXMMXccttiJeW3SnG4y25clGsNsTQ+2qm0p/buemwHG6re2xrnC5XJh1oKW8CvNCkSpsk9vUkiKBPqDTRI7OtujMLfY1pvP40endqk9rE9ZzfXP0Nhav7akOJRbcP1pBqEyXFsdcs29h4JrD8DLgTikXXUaEi8PXhbEHcTbF1zXuMTii5I8qTVqXbTukhqwpe4jXrW3/a5ImbXeluh6VYSPPJnue6mVZX4+Slsg70FFCMrZoJcAV9WYd6AGM7Q4RAWB2o+ZIxaOamKPnIb7Bk70mfNQL0gUirGtWprr0yEM/DeLzk7S5OGLpDEnNuY1MAlz6oO8+D63DMsLA2DysFCAVDOwom0pNKFrzQoOLCsQjADSS2Yn6OmwVTsRiLW7X/lebB/DOERV
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(36860700004)(82310400014)(376005)(1800799015);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Mar 2024 21:39:05.8582
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 000b88ba-4044-4e0e-5be5-08dc4ddd299b
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ5PEPF000001D1.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR12MB8931

Xen tries to load a PVH dom0 kernel at the fixed guest physical address
from the elf headers.  For Linux, this defaults to 0x1000000 (16MB), but
it can be configured.

Unfortunately there exist firmwares that have reserved regions at this
address, so Xen fails to load the dom0 kernel since it's not RAM.

The PVH entry code is not relocatable - it loads from absolute
addresses, which fail when the kernel is loaded at a different address.
With a suitably modified kernel, a reloctable entry point is possible.

Add XEN_ELFNOTE_PHYS32_RELOC which specifies optional alignment,
minimum, and maximum addresses needed for the kernel.  The presence of
the NOTE indicates the kernel supports a relocatable entry path.

Change the loading to check for an acceptable load address.  If the
kernel is relocatable, support finding an alternate load address.

The primary motivation for an explicit align field is that Linux has a
configurable CONFIG_PHYSICAL_ALIGN field.  This value is present in the
bzImage setup header, but not the ELF program headers p_align, which
report 2MB even when CONFIG_PHYSICAL_ALIGN is greater.  Since a kernel
is only considered relocatable if the PHYS32_RELOC elf note is present,
the alignment contraints can just be specified within the note instead
of searching for an alignment value via a heuristic.

libelf-private.h includes common-macros.h to satisfy the fuzzer build.

Link: https://gitlab.com/xen-project/xen/-/issues/180
Signed-off-by: Jason Andryuk 
---
ELF Note printing looks like:
(XEN) ELF: note: PHYS32_RELOC align: 0x200000 min: 0x1000000 max: 0x3fffffff

v2:
Use elfnote for min, max & align - use 64bit values.
Print original and relocated memory addresses
Use check_and_adjust_load_address() name
Return relocated base instead of offset
Use PAGE_ALIGN
Don't load above max_phys (expected to be 4GB in kernel elf note)
Use single line comments
Exit check_load_address loop earlier
Add __init to find_kernel_memory()

v3:
Remove kernel_start/end page rounding
Change loop comment to rely on a sorted memory map.
Reorder E820_RAM check first
Use %p for dest_base
Use PRIpaddr
Use 32bit phys_min/max/align
Consolidate to if ( x || y ) continue
Use max_t
Add parms->phys_reloc
Use common "%pd kernel: " prefix for messages
Re-order phys_entry assignment
Print range ends inclusively
Remove extra "Unable to load kernel" message
s/PVH_RELOCATION/PHYS32_RELOC/
Make PHYS32_RELOC contents optional
Use 2MB default alignment
Update ELF Note comment
Update XEN_ELFNOTE_MAX

v4:
Cast dest_base to uintptr_t
Use local start variable
Mention e820 requiring adjacent entries merged
Remove extra whitespace
Re-word elfnote comment & mention x86
Use ELFNOTE_NAME
Return -ENOSPC
Use ! instead of == 0
Check kend - 1 to avoid off by one
libelf: Use MB/GB() to define the size.
Use ARCH_PHYS_* defines

v5:
Place kernel in higher memory addresses
Remove stray semicolons
ELFNOTE_NAME comment about newline
Make PHYS32_RELOC element order align, min, max
Re-word PHYS32_RELOC comment
Move phys_align next to other bool variables
---
 xen/arch/x86/hvm/dom0_build.c      | 100 +++++++++++++++++++++++++++++
 xen/common/libelf/libelf-dominfo.c |  41 +++++++++++-
 xen/common/libelf/libelf-private.h |   1 +
 xen/include/public/elfnote.h       |  16 ++++-
 xen/include/xen/libelf.h           |   4 ++
 5 files changed, 159 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index 0ceda4140b..b34cb638da 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -537,6 +537,103 @@ static paddr_t __init find_memory(
     return INVALID_PADDR;
 }
 
+static bool __init check_load_address(
+    const struct domain *d, const struct elf_binary *elf)
+{
+    paddr_t kernel_start = (uintptr_t)elf->dest_base;
+    paddr_t kernel_end = kernel_start + elf->dest_size;
+    unsigned int i;
+
+    /* Relies on a sorted memory map with adjacent entries merged. */
+    for ( i = 0; i < d->arch.nr_e820; i++ )
+    {
+        paddr_t start = d->arch.e820[i].addr;
+        paddr_t end = start + d->arch.e820[i].size;
+
+        if ( start >= kernel_end )
+            return false;
+
+        if ( d->arch.e820[i].type == E820_RAM &&
+             start <= kernel_start &&
+             end >= kernel_end )
+            return true;
+    }
+
+    return false;
+}
+
+/* Find an e820 RAM region that fits the kernel at a suitable alignment. */
+static paddr_t __init find_kernel_memory(
+    const struct domain *d, struct elf_binary *elf,
+    const struct elf_dom_parms *parms)
+{
+    paddr_t kernel_size = elf->dest_size;
+    int i;
+
+    /* Search backwards to find the highest address. */
+    for ( i = d->arch.nr_e820 - 1; i >= 0 ; i-- )
+    {
+        paddr_t start = d->arch.e820[i].addr;
+        paddr_t end = start + d->arch.e820[i].size;
+        paddr_t kstart, kend;
+
+        if ( d->arch.e820[i].type != E820_RAM ||
+             d->arch.e820[i].size < kernel_size )
+            continue;
+
+        if ( start > parms->phys_max )
+            continue;
+
+        if ( end - 1 > parms->phys_max )
+            end = parms->phys_max + 1;
+
+        kstart = (end - kernel_size) & ~(parms->phys_align - 1);
+        kend = kstart + kernel_size;
+
+        if ( kstart < parms->phys_min )
+            return 0;
+
+        if ( kstart >= start && kend <= end )
+            return kstart;
+    }
+
+    return 0;
+}
+
+/* Check the kernel load address, and adjust if necessary and possible. */
+static bool __init check_and_adjust_load_address(
+    const struct domain *d, struct elf_binary *elf, struct elf_dom_parms *parms)
+{
+    paddr_t reloc_base;
+
+    if ( check_load_address(d, elf) )
+        return true;
+
+    if ( !parms->phys_reloc )
+    {
+        printk("%pd kernel: Address conflict and not relocatable\n", d);
+        return false;
+    }
+
+    reloc_base = find_kernel_memory(d, elf, parms);
+    if ( !reloc_base )
+    {
+        printk("%pd kernel: Failed find a load address\n", d);
+        return false;
+    }
+
+    if ( opt_dom0_verbose )
+        printk("%pd kernel: Moving [%p, %p] -> [%"PRIpaddr", %"PRIpaddr"]\n", d,
+               elf->dest_base, elf->dest_base + elf->dest_size - 1,
+               reloc_base, reloc_base + elf->dest_size - 1);
+
+    parms->phys_entry = reloc_base +
+                            (parms->phys_entry - (uintptr_t)elf->dest_base);
+    elf->dest_base = (char *)reloc_base;
+
+    return true;
+}
+
 static int __init pvh_load_kernel(struct domain *d, const module_t *image,
                                   unsigned long image_headroom,
                                   module_t *initrd, void *image_base,
@@ -585,6 +682,9 @@ static int __init pvh_load_kernel(struct domain *d, const module_t *image,
     elf.dest_base = (void *)(parms.virt_kstart - parms.virt_base);
     elf.dest_size = parms.virt_kend - parms.virt_kstart;
 
+    if ( !check_and_adjust_load_address(d, &elf, &parms) )
+        return -ENOSPC;
+
     elf_set_vcpu(&elf, v);
     rc = elf_load_binary(&elf);
     if ( rc < 0 )
diff --git a/xen/common/libelf/libelf-dominfo.c b/xen/common/libelf/libelf-dominfo.c
index 77bd582a37..08573c51e0 100644
--- a/xen/common/libelf/libelf-dominfo.c
+++ b/xen/common/libelf/libelf-dominfo.c
@@ -17,6 +17,16 @@
 
 #include "libelf-private.h"
 
+#if defined(__i386__) || defined(__x86_64__)
+#define ARCH_PHYS_ALIGN_DEFAULT MB(2)
+#define ARCH_PHYS_MIN_DEFAULT   0
+#define ARCH_PHYS_MAX_DEFAULT   (GB(4) - 1)
+#else
+#define ARCH_PHYS_ALIGN_DEFAULT 0
+#define ARCH_PHYS_MIN_DEFAULT   0
+#define ARCH_PHYS_MAX_DEFAULT   0
+#endif
+
 /* ------------------------------------------------------------------------ */
 /* xen features                                                             */
 
@@ -125,6 +135,7 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
         [XEN_ELFNOTE_SUSPEND_CANCEL] = { "SUSPEND_CANCEL", ELFNOTE_INT },
         [XEN_ELFNOTE_MOD_START_PFN] = { "MOD_START_PFN", ELFNOTE_INT },
         [XEN_ELFNOTE_PHYS32_ENTRY] = { "PHYS32_ENTRY", ELFNOTE_INT },
+        [XEN_ELFNOTE_PHYS32_RELOC] = { "PHYS32_RELOC", ELFNOTE_NAME },
     };
 /* *INDENT-ON* */
 
@@ -132,6 +143,7 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
     uint64_t val = 0;
     unsigned int i;
     unsigned type = elf_uval(elf, note, type);
+    unsigned descsz = elf_uval(elf, note, descsz);
 
     if ( (type >= sizeof(note_desc) / sizeof(note_desc[0])) ||
          (note_desc[type].name == NULL) )
@@ -160,8 +172,8 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
         break;
 
     case ELFNOTE_NAME:
-        /* ELFNOTE_NAME has a newline printed at the end of the function to
-         * optionally allow printing customized details. */
+        /* ELFNOTE_NAME has a newline printed at the end of the function and
+         * optionally allows printing custom formatted details below. */
         elf_msg(elf, "ELF: note: %s", note_desc[type].name);
         break;
     }
@@ -229,6 +241,27 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
     case XEN_ELFNOTE_PHYS32_ENTRY:
         parms->phys_entry = val;
         break;
+
+    case XEN_ELFNOTE_PHYS32_RELOC:
+        parms->phys_reloc = true;
+
+        if ( descsz >= 4 )
+        {
+            parms->phys_align = elf_note_numeric_array(elf, note, 4, 0);
+            elf_msg(elf, " align: %#"PRIx32, parms->phys_align);
+        }
+        if ( descsz >= 8 )
+        {
+            parms->phys_min = elf_note_numeric_array(elf, note, 4, 1);
+            elf_msg(elf, " min: %#"PRIx32, parms->phys_min);
+        }
+        if ( descsz >= 12 )
+        {
+            parms->phys_max = elf_note_numeric_array(elf, note, 4, 2);
+            elf_msg(elf, " max: %#"PRIx32, parms->phys_max);
+        }
+
+        break;
     }
 
     if ( note_desc[type].type == ELFNOTE_NAME)
@@ -544,6 +577,10 @@ elf_errorstatus elf_xen_parse(struct elf_binary *elf,
     parms->p2m_base = UNSET_ADDR;
     parms->elf_paddr_offset = UNSET_ADDR;
     parms->phys_entry = UNSET_ADDR32;
+    parms->phys_align = ARCH_PHYS_ALIGN_DEFAULT;
+    parms->phys_min = ARCH_PHYS_MIN_DEFAULT;
+    parms->phys_max = ARCH_PHYS_MAX_DEFAULT;
+    parms->phys_reloc = false;
 
     /* Find and parse elf notes. */
     count = elf_phdr_count(elf);
diff --git a/xen/common/libelf/libelf-private.h b/xen/common/libelf/libelf-private.h
index 47db679966..98cac65bc5 100644
--- a/xen/common/libelf/libelf-private.h
+++ b/xen/common/libelf/libelf-private.h
@@ -71,6 +71,7 @@
 #endif
 #include 
 #include 
+#include 
 
 #ifndef FUZZ_NO_LIBXC
 #include "xenctrl.h"
diff --git a/xen/include/public/elfnote.h b/xen/include/public/elfnote.h
index 1d84b05f44..a2f89bdc40 100644
--- a/xen/include/public/elfnote.h
+++ b/xen/include/public/elfnote.h
@@ -196,10 +196,24 @@
  */
 #define XEN_ELFNOTE_PHYS32_ENTRY 18
 
+/*
+ * Physical loading constraints for PVH kernels
+ *
+ * The presence of this note indicates the kernel supports relocating itself.
+ *
+ * The note may include up to three 32bit values to place constraints on the
+ * guest physical loading addresses and alignment for a PVH kernel.  Values
+ * are read in the following order:
+ *  - a required start alignment (default 0x200000)
+ *  - a minimum address for the start of the image (default 0)
+ *  - a maximum address for the last byte of the image (default 0xffffffff)
+ */
+#define XEN_ELFNOTE_PHYS32_RELOC 19
+
 /*
  * The number of the highest elfnote defined.
  */
-#define XEN_ELFNOTE_MAX XEN_ELFNOTE_PHYS32_ENTRY
+#define XEN_ELFNOTE_MAX XEN_ELFNOTE_PHYS32_RELOC
 
 /*
  * System information exported through crash notes.
diff --git a/xen/include/xen/libelf.h b/xen/include/xen/libelf.h
index 1c77e3df31..00e02c27cc 100644
--- a/xen/include/xen/libelf.h
+++ b/xen/include/xen/libelf.h
@@ -425,6 +425,7 @@ struct elf_dom_parms {
     enum xen_pae_type pae;
     bool bsd_symtab;
     bool unmapped_initrd;
+    bool phys_reloc;
     uint64_t virt_base;
     uint64_t virt_entry;
     uint64_t virt_hypercall;
@@ -434,6 +435,9 @@ struct elf_dom_parms {
     uint32_t f_supported[XENFEAT_NR_SUBMAPS];
     uint32_t f_required[XENFEAT_NR_SUBMAPS];
     uint32_t phys_entry;
+    uint32_t phys_align;
+    uint32_t phys_min;
+    uint32_t phys_max;
 
     /* calculated */
     uint64_t virt_kstart;
-- 
2.44.0



From xen-devel-bounces@lists.xenproject.org Tue Mar 26 21:47:19 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Mar 2024 21:47:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698231.1089735 (Exim 4.92)
	(envelope-from )
	id 1rpEdV-0001uw-Ee; Tue, 26 Mar 2024 21:47:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698231.1089735; Tue, 26 Mar 2024 21:47:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpEdV-0001up-C1; Tue, 26 Mar 2024 21:47:13 +0000
Received: by outflank-mailman (input) for mailman id 698231;
 Tue, 26 Mar 2024 21:47:11 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpEdT-0001uj-As
 for xen-devel@lists.xenproject.org; Tue, 26 Mar 2024 21:47:11 +0000
Received: from NAM02-SN1-obe.outbound.protection.outlook.com
 (mail-sn1nam02on2062d.outbound.protection.outlook.com
 [2a01:111:f400:7ea9::62d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 656ade44-ebba-11ee-afe3-a90da7624cb6;
 Tue, 26 Mar 2024 22:47:09 +0100 (CET)
Received: from SJ0PR05CA0046.namprd05.prod.outlook.com (2603:10b6:a03:33f::21)
 by CH2PR12MB4136.namprd12.prod.outlook.com (2603:10b6:610:a4::14)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.33; Tue, 26 Mar
 2024 21:47:06 +0000
Received: from DS1PEPF0001709B.namprd05.prod.outlook.com
 (2603:10b6:a03:33f:cafe::24) by SJ0PR05CA0046.outlook.office365.com
 (2603:10b6:a03:33f::21) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.12 via Frontend
 Transport; Tue, 26 Mar 2024 21:47:05 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 DS1PEPF0001709B.mail.protection.outlook.com (10.167.18.105) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Tue, 26 Mar 2024 21:47:04 +0000
Received: from SATLEXMB08.amd.com (10.181.40.132) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Tue, 26 Mar
 2024 16:47:04 -0500
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB08.amd.com
 (10.181.40.132) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Tue, 26 Mar
 2024 14:47:03 -0700
Received: from fedora.mshome.net (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Tue, 26 Mar 2024 16:47:03 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 656ade44-ebba-11ee-afe3-a90da7624cb6
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=EIGkrGhWmpvynLcicn4Lxei9AbDz49sPDP7jLgZ3ju0iISR41C4GL531YkXNRJ8dkeGUPonBLbl7B1flA8MkZfmqAEZqEwu6N0ExtRk2xA8IPgpVQvw820rPxh2VmxwmQSMPj7Pf+rRDXlpVtMZN0uK7cp9/HC6On/1YOtoy4mpKWGIadLHI7+HTYY3Hs34eQxrqOOmuM1FYtW/gIE0whSlB0iQZAJ9YLv1zE1c1UjttrkOrOtc8jihm/ybqfIENLzcuB8WKWofcipMtChm4swxAd/4iSyXH0+Y1DRLKzr1MJxrfcnbdy76qO9+xdWdZ3bkHAMAG4pzIZptLyS8QXw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=WrdRcWgadoJZx7idcbsBD1hlDQIwTc10NcY4KAVoW78=;
 b=a8Rb7DNm7rIuQ1JUh1cnCkzxBgtNfcO6wPKGyUwoVt54c0WYALL5wvKPstUngPG7bzcR5xEF8rjW0DD/87C6NbQCiyC8ER4uqbIX96O0e7QvGxOobZu2RQ1a8jQdwvtUzBr8dUHbyQvCLlkR7pTMVNVBNObxmgIDIHXal/XthZfrB376zZevI8IAJ2sxFKBrHIuot9rtPWKbwVWZoAHSs60ZL0FJq6kEgDc/APMG+UqXS4DGlFOuJGd7a41qz8jv1cBtV7kIhrl2hDxFsc4nrdPgbIgYeAJlPuvjsdUSZDrvQX79jTmwEiBWuZnbyRtdze4eSC+WLfsGslRSUpIFpA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=WrdRcWgadoJZx7idcbsBD1hlDQIwTc10NcY4KAVoW78=;
 b=k300JpgyDKNP1QncUEPfskJJpjLIoYWFMqTsuDTM2+7DLJuE3SltN8jedVQctYeiIaibLT2qIH1Kr3tTnQC9OWa+gig4LV5UI0xPx+IXmCKEq32qsqDpImIYRjScXLWn381hM6pZCQUiF7LcLu1Las6kvikujCutcIUr85dHyNE=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Jason Andryuk 
To: 
CC: Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, Andrew Cooper , "Juergen
 Gross" , Boris Ostrovsky , Jason
 Andryuk 
Subject: [PATCH v5] RFC: x86/pvh: Make Xen PVH entrypoint PIC for x86-64
Date: Tue, 26 Mar 2024 17:47:01 -0400
Message-ID: <20240326214701.7015-1-jason.andryuk@amd.com>
X-Mailer: git-send-email 2.44.0
In-Reply-To: <20240326213847.3944-1-jason.andryuk@amd.com>
References: <20240326213847.3944-1-jason.andryuk@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DS1PEPF0001709B:EE_|CH2PR12MB4136:EE_
X-MS-Office365-Filtering-Correlation-Id: 6ca7d519-6fea-431a-54e6-08dc4dde4717
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	4kSDNCS93tjvfNSdnQQQLH42Le67hEn6T+nB9/sH5h+H6jHkxf5MJ2Uh18k6p221W8o67GPIQ7QuNZctleEcvM0Tbpp3xH5NRbRPzPycFivHbHY1VH/LfKZXGZ4D3DUle3gbPbEVrtdMbhr0YE/jMYuU+Y4miqd9ks4oIpVE7pzYUjOaYMGgEI45rh/6LDur7eCU0lxlO1vJriAZKWIT252quRrJ3nJd9hhZWZ4EmDVgDVSOtoe61FIpiv6oj3KqLubZrpt20UPPrCoIZVBaUKMLBXdcrNrQIiEBmjeZ0Lvp+JlnPnUm87aXcoiAqABL6Ph6fM8hl8xf/xBM0xAjIcN6c3+qE4WtAZooimVLVodOuE+YlZ8yevHuktyqkHZ1SKnfjpDKQkZ/mn/BGpQmefvg3gdpuzMTDv0y+JGQ2PXYhi4Hl4/xhXg6DYyGQl2VuoEx7ukM985v9cWvqz1d7eDaVkvCVxmvuL5AyFp4XZY7NRLYWnCXvX9R15fZLZAWzpw1leqDiJP0m6DqXa7QPjfgUf993BQ8o8JihRfXMXP7TWqhhU2+p7uGBtiNfGeNjkV1vVIqHUTC7swGNX0aE1fnRsJCGKFcRptr/GTcDv0AgMeKfSUVEWMe3y+RHpBW4ImTrnBVOSwBL9VnLXQMAwKU2ugpNemLtyJXHo8X2UyxirPOjrrjA70cQEIDIX7EsgXK2QMh0By+lLnorrFwUVdQYReb7GYBXaGHzRhRDfedXKrj2xybgtQ1UVwbjV3M
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(1800799015)(82310400014)(36860700004)(376005);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Mar 2024 21:47:04.9620
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 6ca7d519-6fea-431a-54e6-08dc4dde4717
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DS1PEPF0001709B.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR12MB4136

The Xen PVH entrypoint is 32bit non-PIC code running at a default load
address of 0x1000000 (16MB) (CONFIG_PHYSICAL_START).  Xen loads the
kernel at that physical address inside the PVH container.

When running a PVH Dom0, the system reserved addresses are mapped 1-1
into the PVH container.  There exist system firmwares (Coreboot/EDK2)
with reserved memory at 16MB.  This creates a conflict where the PVH
kernel cannot be loaded at that address.

Modify the PVH entrypoint to be position-indepedent to allow flexibility
in load address.  Only the 64bit entry path is converted.  A 32bit
kernel is not PIC, so calling into other parts of the kernel, like
xen_prepare_pvh() and mk_pgtable_32(), don't work properly when
relocated.

Initial PVH entry runs at the physical addresses and then transitions to
the identity mapped address.  While executing xen_prepare_pvh() calls
through pv_ops function pointers transition to the high mapped
addresses.  Additionally, __va() is called on some hvm_start_info
physical addresses, we need the directmap address range is used.  So we
need to run page tables with all of those ranges mapped.

Modifying init_top_pgt tables ran into issue since
startup_64/__startup_64() will modify those page tables again.  Use a
dedicated set of page tables - pvh_init_top_pgt  - for the PVH entry to
avoid unwanted interactions.

In xen_pvh_init(), __pa() is called to find the physical address of the
hypercall page.  Set phys_base temporarily before calling into
xen_prepare_pvh(), which calls xen_pvh_init(), and clear it afterwards.
__startup_64() assumes phys_base is zero and adds load_delta to it.  If
phys_base is already set, the calculation results in an incorrect cr3.

TODO: Sync elfnote.h from xen.git commit xxxxxxxxxx when it is
commited.

Signed-off-by: Jason Andryuk 
---
Put this out as an example for the Xen modifications

Instead of setting and clearing phys_base, add a dedicated variable?
Clearing phys_base is a little weird, but it leaves the kernel more
consistent when running non-entry code.

Make __startup_64() exit if phys_base is already set to allow calling
multiple times, and use that and init_top_pgt instead of adding
additional page tables?  That won't work.  __startup_64 is 64bit code,
and pvh needs to create page tables in 32bit code before it can
transition to 64bit long mode.  Hence it can't be re-used to relocate
page tables.
---
 arch/x86/platform/pvh/head.S    | 184 +++++++++++++++++++++++++++++---
 include/xen/interface/elfnote.h |  18 +++-
 2 files changed, 189 insertions(+), 13 deletions(-)

diff --git a/arch/x86/platform/pvh/head.S b/arch/x86/platform/pvh/head.S
index f7235ef87bc3..13cfd4a35462 100644
--- a/arch/x86/platform/pvh/head.S
+++ b/arch/x86/platform/pvh/head.S
@@ -50,11 +50,32 @@
 #define PVH_CS_SEL		(PVH_GDT_ENTRY_CS * 8)
 #define PVH_DS_SEL		(PVH_GDT_ENTRY_DS * 8)
 
+#define rva(x) ((x) - pvh_start_xen)
+
 SYM_CODE_START_LOCAL(pvh_start_xen)
 	UNWIND_HINT_END_OF_STACK
 	cld
 
-	lgdt (_pa(gdt))
+	/*
+	 * See the comment for startup_32 for more details.  We need to
+	 * execute a call to get the execution address to be position
+	 * independent, but we don't have a stack.  Save and restore the
+	 * magic field of start_info in ebx, and use that as the stack.
+	 */
+	mov	(%ebx), %eax
+	leal	4(%ebx), %esp
+	ANNOTATE_INTRA_FUNCTION_CALL
+	call	1f
+1:	popl	%ebp
+	mov	%eax, (%ebx)
+	subl	$ rva(1b), %ebp
+	movl	$0, %esp
+
+	leal	rva(gdt)(%ebp), %eax
+	movl	%eax, %ecx
+	leal	rva(gdt_start)(%ebp), %ecx
+	movl	%ecx, 2(%eax)
+	lgdt	(%eax)
 
 	mov $PVH_DS_SEL,%eax
 	mov %eax,%ds
@@ -62,14 +83,14 @@ SYM_CODE_START_LOCAL(pvh_start_xen)
 	mov %eax,%ss
 
 	/* Stash hvm_start_info. */
-	mov $_pa(pvh_start_info), %edi
+	leal rva(pvh_start_info)(%ebp), %edi
 	mov %ebx, %esi
-	mov _pa(pvh_start_info_sz), %ecx
+	movl rva(pvh_start_info_sz)(%ebp), %ecx
 	shr $2,%ecx
 	rep
 	movsl
 
-	mov $_pa(early_stack_end), %esp
+	leal rva(early_stack_end)(%ebp), %esp
 
 	/* Enable PAE mode. */
 	mov %cr4, %eax
@@ -83,29 +104,83 @@ SYM_CODE_START_LOCAL(pvh_start_xen)
 	btsl $_EFER_LME, %eax
 	wrmsr
 
+	mov %ebp, %ebx
+	subl $LOAD_PHYSICAL_ADDR, %ebx /* offset */
+	jz .Lpagetable_done
+
+	/* Fixup page-tables for relocation. */
+	leal rva(pvh_init_top_pgt)(%ebp), %edi
+	movl $512, %ecx
+2:
+	movl 0x00(%edi), %eax
+	addl 0x04(%edi), %eax
+	jz 1f
+	addl %ebx, 0x00(%edi)
+1:
+	addl $8, %edi
+	decl %ecx
+	jnz 2b
+
+	/* L3 ident has a single entry. */
+	leal rva(pvh_level3_ident_pgt)(%ebp), %edi
+	addl %ebx, 0x00(%edi)
+
+	leal rva(pvh_level3_kernel_pgt)(%ebp), %edi
+	addl %ebx, (4096 - 16)(%edi)
+	addl %ebx, (4096 - 8)(%edi)
+
+	/* pvh_level2_ident_pgt is fine - large pages */
+
+	/* pvh_level2_kernel_pgt needs adjustment - large pages */
+	leal rva(pvh_level2_kernel_pgt)(%ebp), %edi
+	movl $512, %ecx
+2:
+	movl 0x00(%edi), %eax
+	addl 0x04(%edi), %eax
+	jz 1f
+	addl %ebx, 0x00(%edi)
+1:
+	addl $8, %edi
+	decl %ecx
+	jnz 2b
+
+.Lpagetable_done:
 	/* Enable pre-constructed page tables. */
-	mov $_pa(init_top_pgt), %eax
+	leal rva(pvh_init_top_pgt)(%ebp), %eax
 	mov %eax, %cr3
 	mov $(X86_CR0_PG | X86_CR0_PE), %eax
 	mov %eax, %cr0
 
 	/* Jump to 64-bit mode. */
-	ljmp $PVH_CS_SEL, $_pa(1f)
+	pushl $PVH_CS_SEL
+	leal  rva(1f)(%ebp), %eax
+	pushl %eax
+	lretl
 
 	/* 64-bit entry point. */
 	.code64
 1:
 	/* Set base address in stack canary descriptor. */
 	mov $MSR_GS_BASE,%ecx
-	mov $_pa(canary), %eax
+	leal rva(canary)(%ebp), %eax
 	xor %edx, %edx
 	wrmsr
 
+	/* Calculate load offset from LOAD_PHYSICAL_ADDR and store in
+	 * phys_base.  __pa() needs phys_base set to calculate the the
+	 * hypercall page in xen_pvh_init(). */
+	movq %rbp, %rbx
+	subq $LOAD_PHYSICAL_ADDR, %rbx
+	movq %rbx, phys_base(%rip)
 	call xen_prepare_pvh
+	/* Clear phys_base.  startup_64/__startup_64 will *add* to its value,
+	   so start from 0. */
+	xor  %rbx, %rbx
+	movq %rbx, phys_base(%rip)
 
 	/* startup_64 expects boot_params in %rsi. */
-	mov $_pa(pvh_bootparams), %rsi
-	mov $_pa(startup_64), %rax
+	lea rva(pvh_bootparams)(%ebp), %rsi
+	lea rva(startup_64)(%ebp), %rax
 	ANNOTATE_RETPOLINE_SAFE
 	jmp *%rax
 
@@ -137,13 +212,14 @@ SYM_CODE_START_LOCAL(pvh_start_xen)
 
 	ljmp $PVH_CS_SEL, $_pa(startup_32)
 #endif
+
 SYM_CODE_END(pvh_start_xen)
 
 	.section ".init.data","aw"
 	.balign 8
 SYM_DATA_START_LOCAL(gdt)
-	.word gdt_end - gdt_start
-	.long _pa(gdt_start)
+	.word gdt_end - gdt_start - 1
+	.long _pa(gdt_start) /* x86-64 will overwrite if relocated. */
 	.word 0
 SYM_DATA_END(gdt)
 SYM_DATA_START_LOCAL(gdt_start)
@@ -163,5 +239,89 @@ SYM_DATA_START_LOCAL(early_stack)
 	.fill BOOT_STACK_SIZE, 1, 0
 SYM_DATA_END_LABEL(early_stack, SYM_L_LOCAL, early_stack_end)
 
+#ifdef CONFIG_X86_64
+/*
+ * We are not able to switch in one step to the final KERNEL ADDRESS SPACE
+ * because we need identity-mapped pages.
+ */
+#define l4_index(x)     (((x) >> 39) & 511)
+#define pud_index(x)    (((x) >> PUD_SHIFT) & (PTRS_PER_PUD-1))
+
+L4_PAGE_OFFSET  = l4_index(__PAGE_OFFSET_BASE_L4)
+L4_START_KERNEL = l4_index(__START_KERNEL_map)
+L3_START_KERNEL = pud_index(__START_KERNEL_map)
+
+#define SYM_DATA_START_PAGE_ALIGNED(name)			\
+	SYM_START(name, SYM_L_GLOBAL, .balign PAGE_SIZE)
+
+/* Automate the creation of 1 to 1 mapping pmd entries */
+#define PMDS(START, PERM, COUNT)			\
+	i = 0 ;						\
+	.rept (COUNT) ;					\
+	.quad	(START) + (i << PMD_SHIFT) + (PERM) ;	\
+	i = i + 1 ;					\
+	.endr
+
+/*
+ * Xen PVH needs a set of identity mapped and kernel high mapping
+ * page tables.  pvh_start_xen starts running on the identity mapped
+ * page tables, but xen_prepare_pvh calls into the high mapping.
+ * These page tables need to be relocatable and are only used until
+ * startup_64 transitions to init_top_pgt.
+ */
+SYM_DATA_START_PAGE_ALIGNED(pvh_init_top_pgt)
+	.quad   pvh_level3_ident_pgt - __START_KERNEL_map + _KERNPG_TABLE_NOENC
+	.org    pvh_init_top_pgt + L4_PAGE_OFFSET*8, 0
+	.quad   pvh_level3_ident_pgt - __START_KERNEL_map + _KERNPG_TABLE_NOENC
+	.org    pvh_init_top_pgt + L4_START_KERNEL*8, 0
+	/* (2^48-(2*1024*1024*1024))/(2^39) = 511 */
+	.quad   pvh_level3_kernel_pgt - __START_KERNEL_map + _PAGE_TABLE_NOENC
+SYM_DATA_END(pvh_init_top_pgt)
+
+SYM_DATA_START_PAGE_ALIGNED(pvh_level3_ident_pgt)
+	.quad	pvh_level2_ident_pgt - __START_KERNEL_map + _KERNPG_TABLE_NOENC
+	.fill	511, 8, 0
+SYM_DATA_END(pvh_level3_ident_pgt)
+SYM_DATA_START_PAGE_ALIGNED(pvh_level2_ident_pgt)
+	/*
+	 * Since I easily can, map the first 1G.
+	 * Don't set NX because code runs from these pages.
+	 *
+	 * Note: This sets _PAGE_GLOBAL despite whether
+	 * the CPU supports it or it is enabled.  But,
+	 * the CPU should ignore the bit.
+	 */
+	PMDS(0, __PAGE_KERNEL_IDENT_LARGE_EXEC, PTRS_PER_PMD)
+SYM_DATA_END(pvh_level2_ident_pgt)
+SYM_DATA_START_PAGE_ALIGNED(pvh_level3_kernel_pgt)
+	.fill	L3_START_KERNEL,8,0
+	/* (2^48-(2*1024*1024*1024)-((2^39)*511))/(2^30) = 510 */
+	.quad	pvh_level2_kernel_pgt - __START_KERNEL_map + _KERNPG_TABLE_NOENC
+	.quad	0 /* no fixmap */
+SYM_DATA_END(pvh_level3_kernel_pgt)
+
+SYM_DATA_START_PAGE_ALIGNED(pvh_level2_kernel_pgt)
+	/*
+	 * Kernel high mapping.
+	 *
+	 * The kernel code+data+bss must be located below KERNEL_IMAGE_SIZE in
+	 * virtual address space, which is 1 GiB if RANDOMIZE_BASE is enabled,
+	 * 512 MiB otherwise.
+	 *
+	 * (NOTE: after that starts the module area, see MODULES_VADDR.)
+	 *
+	 * This table is eventually used by the kernel during normal runtime.
+	 * Care must be taken to clear out undesired bits later, like _PAGE_RW
+	 * or _PAGE_GLOBAL in some cases.
+	 */
+	PMDS(0, __PAGE_KERNEL_LARGE_EXEC, KERNEL_IMAGE_SIZE/PMD_SIZE)
+SYM_DATA_END(pvh_level2_kernel_pgt)
+
+	ELFNOTE(Xen, XEN_ELFNOTE_PHYS32_RELOC,
+		     .long CONFIG_PHYSICAL_ALIGN;
+		     .long LOAD_PHYSICAL_ADDR;
+		     .long KERNEL_IMAGE_SIZE - 1)
+#endif
+
 	ELFNOTE(Xen, XEN_ELFNOTE_PHYS32_ENTRY,
-	             _ASM_PTR (pvh_start_xen - __START_KERNEL_map))
+	             .long (pvh_start_xen - __START_KERNEL_map))
diff --git a/include/xen/interface/elfnote.h b/include/xen/interface/elfnote.h
index 38deb1214613..9ebd4e79bb41 100644
--- a/include/xen/interface/elfnote.h
+++ b/include/xen/interface/elfnote.h
@@ -185,9 +185,25 @@
  */
 #define XEN_ELFNOTE_PHYS32_ENTRY 18
 
+/*
+ * Physical loading constraints for PVH kernels
+ *
+ * Used to place constraints on the guest physical loading addresses and
+ * alignment for a PVH kernel.
+ *
+ * The presence of this note indicates the kernel supports relocating itself.
+ *
+ * The note may include up to three 32bit values in the following order:
+ *  - a maximum address for the entire image to be loaded below (default
+ *      0xffffffff)
+ *  - a minimum address for the start of the image (default 0)
+ *  - a required start alignment (default 0x200000)
+ */
+#define XEN_ELFNOTE_PHYS32_RELOC 19
+
 /*
  * The number of the highest elfnote defined.
  */
-#define XEN_ELFNOTE_MAX XEN_ELFNOTE_PHYS32_ENTRY
+#define XEN_ELFNOTE_MAX XEN_ELFNOTE_PHYS32_RELOC
 
 #endif /* __XEN_PUBLIC_ELFNOTE_H__ */
-- 
2.44.0



From xen-devel-bounces@lists.xenproject.org Tue Mar 26 21:55:15 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Mar 2024 21:55:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698233.1089746 (Exim 4.92)
	(envelope-from )
	id 1rpElB-00041t-71; Tue, 26 Mar 2024 21:55:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698233.1089746; Tue, 26 Mar 2024 21:55:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpElB-00041m-4A; Tue, 26 Mar 2024 21:55:09 +0000
Received: by outflank-mailman (input) for mailman id 698233;
 Tue, 26 Mar 2024 21:55:08 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1rpElA-00041g-6H
 for xen-devel@lists.xenproject.org; Tue, 26 Mar 2024 21:55:08 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpEl7-0006OF-6q; Tue, 26 Mar 2024 21:55:05 +0000
Received: from gw1.octic.net ([88.97.20.152] helo=[10.0.1.244])
 by xenbits.xenproject.org with esmtpsa
 (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92)
 (envelope-from )
 id 1rpEl7-0003WD-0G; Tue, 26 Mar 2024 21:55:05 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=a2I+LiowI5Pxt3N7weEJEMDDFjutY0zx6MhCw1LuKew=; b=IltuEQaz0IJHZpi5DUvwh3SVw3
	2B7vrn8jq9k1tIxx0PKDp12l8j8pQk5v1sgrTU5hoDhFnsB7m2h1OepOAYGKyFS+a66/LrWoLDe6o
	eWwHpvT9DF2lOCsu2f+IIR18zj7i/31OwRB2f8jSKg6yqf3rVDheSYV5k+qxOJleJujc=;
Message-ID: 
Date: Tue, 26 Mar 2024 21:55:03 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 08/14] xen/page_alloc: introduce preserved page flags
 macro
To: Jan Beulich ,
 Carlo Nonato 
Cc: Andrew Cooper ,
 George Dunlap ,
 Stefano Stabellini , Wei Liu ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
 <20240315105902.160047-9-carlo.nonato@minervasys.tech>
 <3f615066-a792-493f-ba33-7667a6557c23@xen.org>
 <9e0f7ff3-5457-41e4-a1e4-bf75804fb900@xen.org>
 <255be735-f9fe-4e39-a24e-2f6aff91acc5@suse.com>
 
 <3427132d-9458-4447-b667-d2ef3c1f0569@suse.com>
 
 
Content-Language: en-GB
From: Julien Grall 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Carlo & Jan,

On 26/03/2024 17:04, Jan Beulich wrote:
>>> No, we need to get to the root of the issue. Since osstest has hit it quite
>>> easily as it seems, I'm somewhat surprised you didn't hit it in your testing.
>>> In any event, as per my earlier reply, my present guess is that your change
>>> has merely uncovered a previously latent issue elsewhere.
>>
>> Ok, what about removing PGC_extra in free_heap_pages() before the
>> mark_page_free() call?
> 
> Question is: How would you justify such a change? IOW I'm not convinced
> (yet) this wants doing there.

Looking at the code, the flag is originally set in 
alloc_domheap_pages(). So I guess it would make sense to do it in 
free_domheap_pages().

For PGC_static, I don't think we can reach free_domheap_pages() with the 
flag set (the pages should live in a separate pool). So I believe there 
is nothing to do for them.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Tue Mar 26 22:08:20 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Mar 2024 22:08:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698236.1089755 (Exim 4.92)
	(envelope-from )
	id 1rpExp-0006DS-9G; Tue, 26 Mar 2024 22:08:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698236.1089755; Tue, 26 Mar 2024 22:08:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpExp-0006DL-6T; Tue, 26 Mar 2024 22:08:13 +0000
Received: by outflank-mailman (input) for mailman id 698236;
 Tue, 26 Mar 2024 22:08:11 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1rpExn-0006CT-Ng
 for xen-devel@lists.xenproject.org; Tue, 26 Mar 2024 22:08:11 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpExn-0006em-Ds; Tue, 26 Mar 2024 22:08:11 +0000
Received: from gw1.octic.net ([88.97.20.152] helo=[10.0.1.244])
 by xenbits.xenproject.org with esmtpsa
 (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92)
 (envelope-from )
 id 1rpExn-0004UE-5U; Tue, 26 Mar 2024 22:08:11 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=PmZiu6h+NRrcIPtEyj9+wBBFtJL1lfxp6eHUB76tu7s=; b=EkGie+hxr2FiA8+5a0+nvcIwzT
	oDPCvNm3OC6G1FO/4z7WdAtPmh0UAic6HlEjeypAUQA+9U2E6oxhbtONx6hRik9yLk98u8AIZmOOI
	IQO0BwaXVFJQ+kQPrdh6Pm7d8ghqv3+0gHzHBw4Noakyy//hGODj2aNmHIQdTR9mrbCk=;
Message-ID: 
Date: Tue, 26 Mar 2024 22:08:09 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/vcpu: relax VCPUOP_initialise restriction for non-PV
 vCPUs
Content-Language: en-GB
To: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: xen-devel@lists.xenproject.org, George Dunlap ,
 Jan Beulich , Stefano Stabellini
 , Wei Liu 
References: <20240320135720.68894-1-roger.pau@citrix.com>
 <1304a0d2-ff17-4823-9d31-c32eb7b79f30@citrix.com> 
 <815d5bd4-18af-4f5f-b6a5-6302a1d682a2@citrix.com>
From: Julien Grall 
In-Reply-To: <815d5bd4-18af-4f5f-b6a5-6302a1d682a2@citrix.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Andrew,

On 20/03/2024 14:39, Andrew Cooper wrote:
> On 20/03/2024 2:26 pm, Roger Pau Monné wrote:
>> On Wed, Mar 20, 2024 at 02:06:27PM +0000, Andrew Cooper wrote:
>>> On 20/03/2024 1:57 pm, Roger Pau Monne wrote:
>>>> There's no reason to force HVM guests to have a valid vcpu_info area when
>>>> initializing a vCPU, as the vCPU can also be brought online using the local
>>>> APIC, and on that path there's no requirement for vcpu_info to be setup ahead
>>>> of the bring up.  Note an HVM vCPU can operate normally without making use of
>>>> vcpu_info.
>>>>
>>>> Restrict the check against dummy_vcpu_info to only apply to PV guests.
>>>>
>>>> Fixes: 192df6f9122d ('x86: allow HVM guests to use hypercalls to bring up vCPUs')
>>>> Signed-off-by: Roger Pau Monné 
>>> Thanks for looking into this.  But, do we actually need to force this on
>>> PV either?
>> Possibly, having now taken a look at the users it does seem they could
>> cope with unpopulated vcpu_info_area.
>>
>> Part of my understanding was that this was some kind of courtesy to PV
>> guests in order to prevent starting them without a vcpu_info, which
>> strictly speaking is not mandatory, but otherwise the guest vCPU won't
>> be able to receive interrupts, not even IPIs.
> 
> That's more of a stick than a carrot... "you must set up the area of a
> CPU before you can bring it online". Except as we've seen, HVM has been
> fine all along without it.
>>> The only interesting user of dummy_vcpu_info now is vcpu_info_populate()
>>> which can cope with any arbitrary vCPU.
>>>
>>> I have a suspicion that we can (now) delete these two checks, delete the
>>> dummy_vcpu_info object, and use a regular NULL pointer in
>>> vcpu_info_{populate,reset}(), and in doing so, remove one of the bigger
>>> pieces of PV-absurdity from Xen.
>> I was expecting this to be something we can backport.  OTOH removing
>> the check completely (or even getting rid of dummy_vcpu_info) is not
>> something that we would want to backport.
>>
>> I would rather do the removal of dummy_vcpu_info as followup work.
> 
> I was worried about ARM with your patch, because it's spelt HVM there,
> rather than PV.
> 
> However, I'd forgotten that ARM's do_vcpu_op() filters ops down to just
> VCPUOP_register_{vcpu_info,runstate_memory_area} so VCPUOP_initialise
> isn't reachable.
> 
> Therefore, Reviewed-by: Andrew Cooper 
> 
> It also means ARM can't use any of the PHYS registration yet...

Whoops. I don't think this was intended. Jan, I don't seem to find any 
use in Linux. Do you have any patches you could share? I would like to 
give a try on Arm before sending a patch?

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Wed Mar 27 01:13:28 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 01:13:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698278.1089767 (Exim 4.92)
	(envelope-from )
	id 1rpHqr-0004SQ-Ne; Wed, 27 Mar 2024 01:13:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698278.1089767; Wed, 27 Mar 2024 01:13:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpHqr-0004SJ-Iz; Wed, 27 Mar 2024 01:13:13 +0000
Received: by outflank-mailman (input) for mailman id 698278;
 Wed, 27 Mar 2024 01:13:11 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpHqp-0004Qf-Eq
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 01:13:11 +0000
Received: from fhigh5-smtp.messagingengine.com
 (fhigh5-smtp.messagingengine.com [103.168.172.156])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2adcace1-ebd7-11ee-a1ef-f123f15fe8a2;
 Wed, 27 Mar 2024 02:13:07 +0100 (CET)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.48])
 by mailfhigh.nyi.internal (Postfix) with ESMTP id 1315D11400F5;
 Tue, 26 Mar 2024 21:13:06 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162])
 by compute7.internal (MEProxy); Tue, 26 Mar 2024 21:13:06 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 26 Mar 2024 21:13:04 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2adcace1-ebd7-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-type:content-type:date
	:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to; s=fm2; t=1711501986;
	 x=1711588386; bh=duPM4l7vESI6W2wpgUYG6yFDLRrQw0j3QbzzhqkGPoI=; b=
	XUMS7BfJqc1oRqz15fu7rAlbhGdaGgYiIB/JyZRGJCsA/fCdYy2xLCGKHw4WHi3p
	5abMFAq+Ztstn7j1G3hfI4d06Me4Gqshv0M4d8MAkOJzCmLMCyqLnrSj1+5S1nis
	r4mIKk/q9HAEIz3I6lWgbSiWuZ+Dh1pOSphUL1fnE2ZagS8n6ZwoDOXydPCVcOVv
	A08Q7UpzIrTBi+QnYK20IkG2YIJhHYcVKr8IkYet6hWKVcEE/TLzzx4Y1D4SwtuN
	pYWbUBOkOcvVj17EqkZDtrsbiNw0POofGB/VH8BmlA79Wlg8thLxs3QxvkZBJjq4
	eX+aROXwf7wAJOzhHX4jcg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-type:content-type:date:date
	:feedback-id:feedback-id:from:from:in-reply-to:in-reply-to
	:message-id:mime-version:references:reply-to:subject:subject:to
	:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=
	fm2; t=1711501986; x=1711588386; bh=duPM4l7vESI6W2wpgUYG6yFDLRrQ
	w0j3QbzzhqkGPoI=; b=rNV+BPWovfV2TSrKVM0JPoIY3AdEdAEUBOnw434PCKG8
	hF2R4TnNDJXZ8qgqsCXOqMychXD0VZ/ZCsMRTwGngjBPY1N9b7EjPioZaZrU4vM8
	VOKXQgT8P12SSLysjy4BWXoYlXtKRIthjDJhXPN5I0Km8KC9GVBBDYYf4WfnJ4rl
	feW5DjbiwA3LCvIJGXp0FCPuhmMbK78JX3lResk3anZI0mL7XtqVHqX8wdWxYRzC
	aI5lY8qHkHwmD1V8RGtS1XFlBfoAV+MkV3C19okIMAG0lCf7gzEVWobUQnai4T/Z
	oGEdZ8gyvOnjdAR4Fx7bc909mThk4BRZuucHTNHVFg==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledruddugedgfeefucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
    uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
    cujfgurhepfffhvfevuffkfhggtggujgesghdtreertddtjeenucfhrhhomhepofgrrhgv
    khcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinh
    hvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepgfdu
    leetfeevhfefheeiteeliefhjefhleduveetteekveettddvgeeuteefjedunecuvehluh
    hsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghk
    sehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Wed, 27 Mar 2024 02:13:02 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Anthony PERARD 
Cc: qemu-devel@nongnu.org, Jason Andryuk ,
	Stefano Stabellini ,
	Paul Durrant ,
	"open list:X86 Xen CPUs" 
Subject: Re: [PATCH v2 1/2] hw/xen: detect when running inside stubdomain
Message-ID: 
References: <20240305191312.321127-1-marmarek@invisiblethingslab.com>
 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="L+9mmUR3Q4Dfquvs"
Content-Disposition: inline
In-Reply-To: 


--L+9mmUR3Q4Dfquvs
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Wed, 27 Mar 2024 02:13:02 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Anthony PERARD 
Cc: qemu-devel@nongnu.org, Jason Andryuk ,
	Stefano Stabellini ,
	Paul Durrant ,
	"open list:X86 Xen CPUs" 
Subject: Re: [PATCH v2 1/2] hw/xen: detect when running inside stubdomain

On Tue, Mar 26, 2024 at 05:06:50PM +0000, Anthony PERARD wrote:
> On Tue, Mar 05, 2024 at 08:12:29PM +0100, Marek Marczykowski-G=C3=B3recki=
 wrote:
> > diff --git a/hw/xen/xen-legacy-backend.c b/hw/xen/xen-legacy-backend.c
> > index 124dd5f3d6..6bd4e6eb2f 100644
> > --- a/hw/xen/xen-legacy-backend.c
> > +++ b/hw/xen/xen-legacy-backend.c
> > @@ -603,6 +603,20 @@ static void xen_set_dynamic_sysbus(void)
> >      machine_class_allow_dynamic_sysbus_dev(mc, TYPE_XENSYSDEV);
> >  }
> > =20
> > +static bool xen_check_stubdomain(void)
> > +{
> > +    char *dm_path =3D g_strdup_printf("/local/domain/%d/image", xen_do=
mid);
> > +    int32_t dm_domid;
> > +    bool is_stubdom =3D false;
> > +
> > +    if (!xenstore_read_int(dm_path, "device-model-domid", &dm_domid)) {
> > +        is_stubdom =3D dm_domid !=3D 0;
> > +    }
> > +
> > +    g_free(dm_path);
> > +    return is_stubdom;
> > +}
> > +
> >  void xen_be_init(void)
> >  {
> >      xenstore =3D qemu_xen_xs_open();
> > @@ -616,6 +630,8 @@ void xen_be_init(void)
> >          exit(1);
> >      }
> > =20
> > +    xen_is_stubdomain =3D xen_check_stubdomain();
>=20
> This isn't really a backend specific information, and xen_be_init() is
> all about old backend implementation support. (qdisk which have been the
> first to be rewritten doesn't need xen_be_init(), or shouldn't). Could
> we move the initialisation elsewhere?

I can try to move it, sure.

> Is this relevant PV guests? If not, we could move the initialisation to
> xen_hvm_init_pc().
>=20
> Also, avoid having xen_check_stubdomain() depending on
> "xen-legacy-backend", if possible.
>=20
> (In xen_hvm_init_pc(), a call to xen_register_ioreq() opens another
> xenstore, as `state->xenstore`.)

And xen_register_ioreq() calls xen_be_init() anyway, so it wouldn't
change much in practice (at least for now)...

> (There's already been effort to build QEMU without legacy backends, that
> stubdom check would break in this scenario.)

--=20
Best Regards,
Marek Marczykowski-G=C3=B3recki
Invisible Things Lab

--L+9mmUR3Q4Dfquvs
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYDcp4ACgkQ24/THMrX
1yxUTwf9GlCojUIfNlirgs+bpCQz7TgUrggQ4b7Pspee9vb/Eer1+K6qseZ9wyNj
s15Pjnp+BjHBeisOJ1a5QP0JZ/eqzm1ygdRDzkNgLjLUn0SwT+v1BqWSgGLGDIFg
l28LFGFWaWwauzehqi8v8uoQxJrlGksAEpHZaKumd2DniCw1TJHX832oz5Nlxhhx
ND1OkAQYDyf6VpW8VpJP7R+eM/A6sMGCkDRaoQGmRNeszAsEaM5vXYb9I1A5mKAR
S+Hjp4GF4mSshXfKQozp92CCjIF+rOFaDeaMUsyuNQybtHWVxVFFAmPSW0xpecDq
Jz49s+i/TPT79jUnVWmkMfpng6x4dg==
=kQYH
-----END PGP SIGNATURE-----

--L+9mmUR3Q4Dfquvs--


From xen-devel-bounces@lists.xenproject.org Wed Mar 27 02:34:17 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 02:34:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698283.1089776 (Exim 4.92)
	(envelope-from )
	id 1rpJ75-0006BZ-KA; Wed, 27 Mar 2024 02:34:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698283.1089776; Wed, 27 Mar 2024 02:34:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpJ75-0006BS-H1; Wed, 27 Mar 2024 02:34:03 +0000
Received: by outflank-mailman (input) for mailman id 698283;
 Wed, 27 Mar 2024 02:34:02 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpJ73-0006BM-Qf
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 02:34:02 +0000
Received: from fout3-smtp.messagingengine.com (fout3-smtp.messagingengine.com
 [103.168.172.146]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 764720db-ebe2-11ee-a1ef-f123f15fe8a2;
 Wed, 27 Mar 2024 03:33:58 +0100 (CET)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.46])
 by mailfout.nyi.internal (Postfix) with ESMTP id F32AC1380178;
 Tue, 26 Mar 2024 22:33:56 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163])
 by compute2.internal (MEProxy); Tue, 26 Mar 2024 22:33:56 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 26 Mar 2024 22:33:55 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 764720db-ebe2-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-type:content-type:date
	:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to; s=fm2; t=1711506836;
	 x=1711593236; bh=E7aAgdvO75mggR3x5H4bZ6aJFCvNIKsUDAzOI7Nh3aQ=; b=
	YPHC2KsDENfY3I43g355ZE3/flfFzRU+/t9LlVJaK0vWLBOBAU5Z4kmSVZXzMLFl
	kZX0bRM0NxCiWHCvnp96NSSCqany538TsymZou43ywH8C+DqeIpalefEjKi5CUmU
	mJFkhr2yDWy0BgjjiB96APs4KMh5Fr5DxDoSVw97nQGyfZdQVZ1whU5dzjUTBCLz
	iNfv5WaoU5b9eMLRpgYsXJYcdBise+feCPrKYx43K/oCmbxRRMkan1Ycr5849pQy
	44EMECdFswoDauTqMUSaiHo4qlyxABQrnMGnwKGN8X+VwJy7O4uh2jYO2vn7y/Yt
	ADJEeBPGMzkgD9oahEmrbQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-type:content-type:date:date
	:feedback-id:feedback-id:from:from:in-reply-to:in-reply-to
	:message-id:mime-version:references:reply-to:subject:subject:to
	:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=
	fm2; t=1711506836; x=1711593236; bh=E7aAgdvO75mggR3x5H4bZ6aJFCvN
	IKsUDAzOI7Nh3aQ=; b=v46wYyVUQTj6mVsij51NhHY6hezlh5Gm8DX0i5ZhGdvZ
	p9AAQ0XK2FGYOARexUg1VD7DpSRSmTvp+uxSis/o2wshue2s3ZFIb+Gsuqq5Znja
	fHyGEDDNoswsTI7Sy+nF6QK7AkD0qHcxlGHC/GSfbcqCpQQTw0qMEfYsL2FnIfLP
	gYrvc/OTlymYf3dzMxPo0n/caq6VSrUy2z8faNBdEkkftr9g+vcm1UT73Yip4gEc
	CzCySdMHXINbHXwpNzgVRL6qpd3L8bjkI70rkckOWO6it45dnODI6YxVZnJpm0g4
	1+yWibOeiBoLv7+k+10zds5CWJRpRXipFUu701JPTA==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledruddugedggeelucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
    uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
    cujfgurhepfffhvfevuffkfhggtggujgesghdtreertddtjeenucfhrhhomhepofgrrhgv
    khcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinh
    hvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepgfdu
    leetfeevhfefheeiteeliefhjefhleduveetteekveettddvgeeuteefjedunecuvehluh
    hsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghk
    sehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Wed, 27 Mar 2024 03:33:52 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Jan Beulich 
Cc: Paul Durrant ,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 2/2] drivers/char: mark extra reserved device memory
 in memory map
Message-ID: 
References: <20240312162541.384793-1-marmarek@invisiblethingslab.com>
 <20240312162541.384793-2-marmarek@invisiblethingslab.com>
 <351eebc2-7da3-4082-830b-d8e764e2066a@suse.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="O4P5yuvFpJTGEmtt"
Content-Disposition: inline
In-Reply-To: <351eebc2-7da3-4082-830b-d8e764e2066a@suse.com>


--O4P5yuvFpJTGEmtt
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Wed, 27 Mar 2024 03:33:52 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Jan Beulich 
Cc: Paul Durrant ,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 2/2] drivers/char: mark extra reserved device memory
 in memory map

On Mon, Mar 18, 2024 at 02:48:09PM +0100, Jan Beulich wrote:
> On 12.03.2024 17:25, Marek Marczykowski-G=C3=B3recki wrote:
> > The IOMMU driver checks if RMRR/IVMD are marked as reserved in memory
> > map. This should be true for addresses coming from the firmware, but
> > when extra pages used by Xen itself are included in the mapping, those
> > are taken from usable RAM used. Mark those pages as reserved too.
> >=20
> > Not marking the pages as reserved didn't caused issues before due to
> > another a bug in IOMMU driver code, that was fixed in 83afa3135830
> > ("amd-vi: fix IVMD memory type checks").
> >=20
> > Failing to reserve memory will lead to panic in IOMMU setup code. And
> > not including the page in IOMMU mapping will lead to broken console (due
> > to IOMMU faults). The pages chosen by the XHCI console driver should
> > still be usable by the CPU though, and the console code already can deal
> > with too slow console by dropping characters (and console not printing
> > anything is a special case of "slow"). When reserving fails print an er=
ror
> > message showing which pages failed and who requested them. This should
> > be enough hint to find why XHCI console doesn't work.
> >=20
> > Fixes: 3a1a7b809ffa "drivers/char: mark DMA buffers as reserved for the=
 XHCI"
> > Signed-off-by: Marek Marczykowski-G=C3=B3recki 
> > ---
> > Alternative error handling could be a panic, but with this version I
> > think it can be avoided. And not panicing gives a better chance to
> > actually see the error message (from the hopefully started dom0),
> > especially as the affected driver is the console one.
> >=20
> > The reserve_e820_ram() is x86-specific. Is there some equivalent API for
> > ARM, or maybe even some abstract one? That said, I have no way to test
> > XHCI console on ARM, I don't know if such hardware even exists...
>=20
> These are normal PCI devices, so I don't see why they shouldn't be usable
> on non-x86 systems. But this is all okay as long as XHCI depends on X86
> in Kconfig.

That's why I'm asking for similar API for ARM. The x86-specific part
here is only about IOMMU, other parts should work just fine (but as I
said, I have no way to test).

Anyway, I'll leave it to whoever will need this driver on ARM (or other
arch).

--=20
Best Regards,
Marek Marczykowski-G=C3=B3recki
Invisible Things Lab

--O4P5yuvFpJTGEmtt
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYDhZEACgkQ24/THMrX
1yyJywf8Cbi1qMrPJACvxwJcW9u8fxCmlPduNELJIjiA72FnRtMeKdA9uDwZToam
R5gvHc3jgSbrvnBDE10ZYG6pjF4MfibNxTKO3tIDyhpUikMD3ZkINAPNKbBpRJad
CpbaZJc/00ou3BgCtujmYXkgsV6QziqbmxBGJvCLtPGHvJC59QnSVYkCRj7vqZ3F
dcaARbhm1uoQJvYWGNhLhCQmceRzc2whM/9TySliFGZ1oU6WeBqBrgTBgaakeys1
vKCyCu/jIPZSbFg8sUBDMBtrp4m0/mNZKzddXHgRb7vq4MKzvj0YpjFNYRvr2ogo
8PHwLY6cYmOgqUQGirYPnGQZF7o3Kw==
=Wquh
-----END PGP SIGNATURE-----

--O4P5yuvFpJTGEmtt--


From xen-devel-bounces@lists.xenproject.org Wed Mar 27 02:46:41 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 02:46:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698286.1089785 (Exim 4.92)
	(envelope-from )
	id 1rpJJE-00085m-Ma; Wed, 27 Mar 2024 02:46:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698286.1089785; Wed, 27 Mar 2024 02:46:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpJJE-00085f-K2; Wed, 27 Mar 2024 02:46:36 +0000
Received: by outflank-mailman (input) for mailman id 698286;
 Wed, 27 Mar 2024 02:46:35 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpJJD-00085G-63
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 02:46:35 +0000
Received: from fout3-smtp.messagingengine.com (fout3-smtp.messagingengine.com
 [103.168.172.146]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 38bfb2d0-ebe4-11ee-afe3-a90da7624cb6;
 Wed, 27 Mar 2024 03:46:34 +0100 (CET)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45])
 by mailfout.nyi.internal (Postfix) with ESMTP id CDFF6138016F;
 Tue, 26 Mar 2024 22:46:32 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163])
 by compute5.internal (MEProxy); Tue, 26 Mar 2024 22:46:32 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 26 Mar 2024 22:46:31 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 38bfb2d0-ebe4-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-type:content-type:date
	:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to; s=fm2; t=1711507592;
	 x=1711593992; bh=QO4nVzCmPjbcTyIF2cXjMY9yPrx3YHooLGijX9GaD4o=; b=
	NSFsCxFiesfAuDAa8+Ex7AxYY7aYP/RZluLJP5nIooI72VXd7LAaaCMrstUvDstF
	NYpNb8xl7mPSucmYQuY9QZgPKerJB7gE0kAyitNPO5p8xSv28Px3cSB6FNalC1k5
	9mli7urpbZHuBOFOcQvUTO6OX6aH2GErK/fIzWEVkxfrM2/UE4x5UJlomudIKM4k
	rqFAEq1I18AczQ0E6qUIqAfMiUVNBA+fT4nkLecBCeZpmMYq4HjDl4y9bhEbROMZ
	kaodw6jhk2IcR5dEPWc+uH9Q39tIDD4sYeJhIyRtYXV267pOk8g4vghg1xvZWlj4
	v3SCUq/3L/1j9A8N7ibNiw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-type:content-type:date:date
	:feedback-id:feedback-id:from:from:in-reply-to:in-reply-to
	:message-id:mime-version:references:reply-to:subject:subject:to
	:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=
	fm2; t=1711507592; x=1711593992; bh=QO4nVzCmPjbcTyIF2cXjMY9yPrx3
	YHooLGijX9GaD4o=; b=v7qXt4mFDL8u3AdC9XyX4+97DYduxi/7wPqriAAcVJbu
	9XO+zjjOzpgs2P3mYXJA0sIhY9bcT8ea/1aq0NY0U/19KSUbk4bAg4JhygwaA0Qp
	0kREma/cM/3KdNJ4CSv+rDyBlj8b8eQ4aAeUUNXAyukIkeOvbblb2W9OJ2tFQWBA
	RUfXsc7WIHg1+KstmvLVsun+AYOtjugTU4hGVfDP8EJzXmlQaNWvliQbJ1podFI1
	yeFNGzuQFlnsf71H9F2QIBTq4ifo1oyuLVStCl70+IleUxcJ3sIrJo5CBqt9Gqrh
	tHYgWfN9UajJEJFzXpOmMnO3Ucc1zU7ocIQTqxZC/w==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledruddugedghedvucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
    uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
    cujfgurhepfffhvfevuffkfhggtggujgesghdtreertddtjeenucfhrhhomhepofgrrhgv
    khcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinh
    hvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepgfdu
    leetfeevhfefheeiteeliefhjefhleduveetteekveettddvgeeuteefjedunecuvehluh
    hsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghk
    sehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Wed, 27 Mar 2024 03:46:28 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Roger Pau =?utf-8?B?TW9ubsOp?= 
Cc: Jan Beulich ,
	Andrew Cooper ,
	George Dunlap ,
	Julien Grall ,
	Stefano Stabellini , Wei Liu ,
	Paul Durrant , xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 1/2] IOMMU: store name for extra reserved device memory
Message-ID: 
References: <20240312162541.384793-1-marmarek@invisiblethingslab.com>
 <3ab49282-6b67-4ab0-bb65-f04c62bcadcb@suse.com>
 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="iDMBP8wO4N0lDexN"
Content-Disposition: inline
In-Reply-To: 


--iDMBP8wO4N0lDexN
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Wed, 27 Mar 2024 03:46:28 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Roger Pau =?utf-8?B?TW9ubsOp?= 
Cc: Jan Beulich ,
	Andrew Cooper ,
	George Dunlap ,
	Julien Grall ,
	Stefano Stabellini , Wei Liu ,
	Paul Durrant , xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 1/2] IOMMU: store name for extra reserved device memory

On Mon, Mar 18, 2024 at 04:52:42PM +0100, Roger Pau Monn=C3=A9 wrote:
> On Mon, Mar 18, 2024 at 02:40:21PM +0100, Jan Beulich wrote:
> > On 12.03.2024 17:25, Marek Marczykowski-G=C3=B3recki wrote:
> > > It will be useful for error reporting in a subsequent patch.
> > >=20
> > > Signed-off-by: Marek Marczykowski-G=C3=B3recki 
> >=20
> > In principle
> > Acked-by: Jan Beulich 
> > However, ...
> >=20
> > > --- a/xen/drivers/passthrough/iommu.c
> > > +++ b/xen/drivers/passthrough/iommu.c
> > > @@ -682,6 +682,7 @@ struct extra_reserved_range {
> > >      unsigned long start;
> > >      unsigned long nr;
> > >      pci_sbdf_t sbdf;
> > > +    const char *name;
> > >  };
> >=20
> > ... to me "descr" (or the longer "description") would seem more suitabl=
e.
> > Thoughts?
>=20
> I'm happy either way, but I don't find 'name' odd.

"descr" sounds a bit weird (even though it's clear what it means),
"name" is a full word. And also, quick grep suggest other places use
"name" for similar purpose (I haven't found a single "descr" nor
"description" struct field).

--=20
Best Regards,
Marek Marczykowski-G=C3=B3recki
Invisible Things Lab

--iDMBP8wO4N0lDexN
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYDiIUACgkQ24/THMrX
1yzE0QgAmH38pY87x6BmEU3hG502FHm6hsP4NHezxOk4SDFEXnqzwcXPEcBjKiNf
fjK0QKQiUDqd+lCD5hS9ixANlKTygZWsdmoll5VJsJXmVWvdR15C40nDn2dI8qyG
M+kX7Zk2T83Qk+T0znOwWaiZJs1E6itiJFE3c9RNbntd3+D+Eq8Tj656/N8r13ZF
9AfMHNIHxKCxUTGzFK9PcRFDT+Kz0QPg6mhmwhbmqCGBagET7+VFVIDwR4bZ/kFN
Wq6NYHjXuMGZm4FphwkesnMSpuneEjcErd6CblkP1zUGP7lf1rdU+11tj4/W/r0h
OHQkNaUPO6rDD471mFBZtCfGRms5Cw==
=sj0f
-----END PGP SIGNATURE-----

--iDMBP8wO4N0lDexN--


From xen-devel-bounces@lists.xenproject.org Wed Mar 27 02:55:25 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 02:55:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698290.1089803 (Exim 4.92)
	(envelope-from )
	id 1rpJRg-0001Xd-Qv; Wed, 27 Mar 2024 02:55:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698290.1089803; Wed, 27 Mar 2024 02:55:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpJRg-0001XF-Kl; Wed, 27 Mar 2024 02:55:20 +0000
Received: by outflank-mailman (input) for mailman id 698290;
 Wed, 27 Mar 2024 02:55:19 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpJRf-0001U3-AL
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 02:55:19 +0000
Received: from fout3-smtp.messagingengine.com (fout3-smtp.messagingengine.com
 [103.168.172.146]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 715e788f-ebe5-11ee-afe3-a90da7624cb6;
 Wed, 27 Mar 2024 03:55:18 +0100 (CET)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41])
 by mailfout.nyi.internal (Postfix) with ESMTP id 92C8A13800E8;
 Tue, 26 Mar 2024 22:55:17 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162])
 by compute1.internal (MEProxy); Tue, 26 Mar 2024 22:55:17 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 26 Mar 2024 22:55:16 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 715e788f-ebe5-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:from:from:in-reply-to
	:in-reply-to:message-id:mime-version:references:reply-to:subject
	:subject:to:to; s=fm2; t=1711508117; x=1711594517; bh=LiC4Z64sJk
	XXdBeM3YC2/qtZwTqDVcXAvB76UdMIB6E=; b=K2ftxsJJzomkCyFgiJgByLl/xK
	oKD4ATDU8MstCYvnAq/+OAhi9GiauT5CUorT5VY1UYVsi74KrYISb4yMtSMu/zFe
	2t8BmJi5lCiuaHnabxhy7EmagiJDfdKrbs2LjLY9Rg5WwdD2Idd4WmP6sxKgRS9u
	5uhA+KMe5Uf/6ziymZOzqXhDy/TIIeF8vaCkZjkIs0CEwggr1cjDLdxmNkIZq/rc
	3BuQIettA9/D3wVslDDv67/3i2zBHCFa9XI7kGXW1fVJjlwLqFvfxKLn8rtyVZM7
	hmgZFAjZtl8VhQYCIEfOvemexgS1L0X5hf4/9Y8Sd0fEEhVAbSdatBi7p0bg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:feedback-id:feedback-id
	:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy
	:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1711508117; x=
	1711594517; bh=LiC4Z64sJkXXdBeM3YC2/qtZwTqDVcXAvB76UdMIB6E=; b=e
	kk1ZYL/QpapogfJtBdhdVtL/HagSRkqIrd6DiwWMzoToiiPZB+sVx47IfcAktwTD
	nPVV+UDN7sL+c81SJsgBjaYw8Nkz4ZdtfRsSJGwUI7A3OZ2BCfeY9BzQ6TQhXXAW
	AzPJ5CLxrevGw8ohALkUlFyfxjsmdbs/+Rlm6ixO8ry2ozrd8UXWHcGmE+vsgY6H
	tg6VK5O78naj+d/Y50ImDJKCV1FZB0r0O2bf8OTSgsegW1CfvNFB7Xzy/NxMpq+e
	/FVGv0AgwvENiSE8HnJKA7v/eOoGGsoXXefdhmyjyiAL9Z8uliD48AjsojHg+y2M
	yc+CzAdlHmuuHDBQ09hWA==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledruddugedgheefucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
    uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
    cujfgurhephffvvefufffkofgjfhggtgfgsehtkeertdertdejnecuhfhrohhmpeforghr
    vghkucforghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesih
    hnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpefg
    ueduhefgvdefheehudejheefudevueeghfekhfehleegveduteeuiedugffgffenucevlh
    hushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgv
    khesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhm
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
To: xen-devel@lists.xenproject.org
Cc: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Jan Beulich ,
	Paul Durrant ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v3 2/2] drivers/char: mark extra reserved device memory in memory map
Date: Wed, 27 Mar 2024 03:53:11 +0100
Message-ID: <20240327025454.514521-2-marmarek@invisiblethingslab.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20240327025454.514521-1-marmarek@invisiblethingslab.com>
References: <20240327025454.514521-1-marmarek@invisiblethingslab.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The IOMMU driver checks if RMRR/IVMD are marked as reserved in memory
map. This should be true for addresses coming from the firmware, but
when extra pages used by Xen itself are included in the mapping, those
are taken from usable RAM used. Mark those pages as reserved too.

Not marking the pages as reserved didn't caused issues before due to
another a bug in IOMMU driver code, that was fixed in 83afa3135830
("amd-vi: fix IVMD memory type checks").

Failing to reserve memory will lead to panic in IOMMU setup code. And
not including the page in IOMMU mapping will lead to broken console (due
to IOMMU faults). The pages chosen by the XHCI console driver should
still be usable by the CPU though, and the console code already can deal
with too slow console by dropping characters (and console not printing
anything is a special case of "slow"). When reserving fails print an error
message showing which pages failed and who requested them. This should
be enough hint to find why XHCI console doesn't work.

Fixes: 3a1a7b809ffa "drivers/char: mark DMA buffers as reserved for the XHCI"
Signed-off-by: Marek Marczykowski-Górecki 
---
Alternative error handling could be a panic, but with this version I
think it can be avoided. And not panicing gives a better chance to
actually see the error message (from the hopefully started dom0),
especially as the affected driver is the console one.

The reserve_e820_ram() is x86-specific. Is there some equivalent API for
ARM, or maybe even some abstract one? That said, I have no way to test
XHCI console on ARM, I don't know if such hardware even exists...

Changes in v2:
- move reserving to iommu_get_extra_reserved_device_memory() to cover
  all users of iommu_add_extra_reserved_device_memory()
- change error handling to not panic, as in this code layout it can skip
  sending the pages to the IOMMU driver
Changes in v3:
- code style, typo
---
 xen/drivers/passthrough/iommu.c | 17 +++++++++++++++++
 xen/include/xen/iommu.h         |  5 ++++-
 2 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index 03587c0cd680..ba18136c461c 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -22,6 +22,10 @@
 #include 
 #include 
 
+#ifdef CONFIG_X86
+#include 
+#endif
+
 unsigned int __read_mostly iommu_dev_iotlb_timeout = 1000;
 integer_param("iommu_dev_iotlb_timeout", iommu_dev_iotlb_timeout);
 
@@ -715,6 +719,19 @@ int __init iommu_get_extra_reserved_device_memory(iommu_grdm_t *func,
 
     for ( idx = 0; idx < nr_extra_reserved_ranges; idx++ )
     {
+#ifdef CONFIG_X86
+        paddr_t start = pfn_to_paddr(extra_reserved_ranges[idx].start);
+        paddr_t end = pfn_to_paddr(extra_reserved_ranges[idx].start +
+                                   extra_reserved_ranges[idx].nr);
+
+        if ( !reserve_e820_ram(&e820, start, end) )
+        {
+            printk(XENLOG_ERR "Failed to reserve [%"PRIx64"-%"PRIx64") for %s, "
+                   "skipping IOMMU mapping for it, some functionality may be broken\n",
+                   start, end, extra_reserved_ranges[idx].name);
+            continue;
+        }
+#endif
         ret = func(extra_reserved_ranges[idx].start,
                    extra_reserved_ranges[idx].nr,
                    extra_reserved_ranges[idx].sbdf.sbdf,
diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
index b7829dff4588..1f56a6cf456a 100644
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -324,7 +324,8 @@ struct iommu_ops {
 };
 
 /*
- * To be called by Xen internally, to register extra RMRR/IVMD ranges.
+ * To be called by Xen internally, to register extra RMRR/IVMD ranges for RAM
+ * pages.
  * Needs to be called before IOMMU initialization.
  */
 extern int iommu_add_extra_reserved_device_memory(unsigned long start,
@@ -334,6 +335,8 @@ extern int iommu_add_extra_reserved_device_memory(unsigned long start,
 /*
  * To be called by specific IOMMU driver during initialization,
  * to fetch ranges registered with iommu_add_extra_reserved_device_memory().
+ * This has a side effect of marking requested ranges as "reserved" in the
+ * memory map.
  */
 extern int iommu_get_extra_reserved_device_memory(iommu_grdm_t *func,
                                                   void *ctxt);
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Wed Mar 27 02:55:25 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 02:55:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698289.1089795 (Exim 4.92)
	(envelope-from )
	id 1rpJRg-0001UN-Gm; Wed, 27 Mar 2024 02:55:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698289.1089795; Wed, 27 Mar 2024 02:55:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpJRg-0001UG-DW; Wed, 27 Mar 2024 02:55:20 +0000
Received: by outflank-mailman (input) for mailman id 698289;
 Wed, 27 Mar 2024 02:55:18 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpJRe-0001U3-LN
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 02:55:18 +0000
Received: from fout3-smtp.messagingengine.com (fout3-smtp.messagingengine.com
 [103.168.172.146]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 70a39b59-ebe5-11ee-afe3-a90da7624cb6;
 Wed, 27 Mar 2024 03:55:17 +0100 (CET)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41])
 by mailfout.nyi.internal (Postfix) with ESMTP id 2253013800D7;
 Tue, 26 Mar 2024 22:55:16 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162])
 by compute1.internal (MEProxy); Tue, 26 Mar 2024 22:55:16 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 26 Mar 2024 22:55:14 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 70a39b59-ebe5-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:from:from:in-reply-to
	:message-id:mime-version:reply-to:subject:subject:to:to; s=fm2;
	 t=1711508116; x=1711594516; bh=iR3RPwsjfqGgzxywcjM0OhjhFEhCgiiP
	JbMrbI5Zuwg=; b=VLK8ulKmr9ZkVPSIV9hmARgWOkK+fBJsr7vD61EeCQ2kwCbm
	NqAZoYDx0DgJO4poyZJp5A9nFIAONdpWTMYA4nUF3R27N60RwD1uvWtjZfeouM+m
	dBzHihoM8Ty1gueMNLhhlo/xplBmcrV1DDSPb1kR0N7a6NOwbyRFqX5Rlgw8bant
	di54PX0hWOwZCuNZi1CGbw20nrlMvDnXOCMEreORYwD0MaJYLsvIRPBm+kDguECu
	v5BAThKgxNwFE476yKw4wZDc/PZMoclvoyMU0FEUSm6PBXXE4hDo0T9t0zmITLBC
	DOUPuY+dNp77xClHXxTjQpvo786WmlYJcQ46uA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:feedback-id:feedback-id
	:from:from:in-reply-to:message-id:mime-version:reply-to:subject
	:subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender
	:x-sasl-enc; s=fm2; t=1711508116; x=1711594516; bh=iR3RPwsjfqGgz
	xywcjM0OhjhFEhCgiiPJbMrbI5Zuwg=; b=kVr9UoO3CmIwIJ+s7xK9rnEd//d4E
	whS9jCN3ZCwi7bBVGnqAoRCR9+v2mv+b+LSVkZH6QkRlsvxafqRcdn+rDhIm9Soe
	TASs9GfsvEkrhw4gxpO/F7itccFEMVQBVeLT5rPDVn97x+kDMtlhH52ymR8YyuLh
	bGCye4mW6FvFkWgcKXOWIRJ54YbLHxR19Dj26+IAbhSlFwl3cfLINLhbggWLHALT
	6tl1yQEe8DyOHrDfAvARowMAIwU9wKUpKp9Nhm+YBc7WiglLQV++oJoQoW1bOQwm
	/+tuMOCXiMF8oDJUHzaH+a67F84b8g5oMqN9blNqUc05NlcCEuspKix3A==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledruddugedgheefucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
    uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
    cujfgurhephffvvefufffkofggtgfgsehtkeertdertdejnecuhfhrohhmpeforghrvghk
    ucforghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvh
    hishhisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpeelkefh
    udelteelleelteetveeffeetffekteetjeehlefggeekleeghefhtdehvdenucevlhhush
    htvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhes
    ihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhm
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
To: xen-devel@lists.xenproject.org
Cc: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Jan Beulich ,
	Andrew Cooper ,
	George Dunlap ,
	Julien Grall ,
	Stefano Stabellini ,
	Wei Liu ,
	Paul Durrant ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v3 1/2] IOMMU: store name for extra reserved device memory
Date: Wed, 27 Mar 2024 03:53:10 +0100
Message-ID: <20240327025454.514521-1-marmarek@invisiblethingslab.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

It will be useful for error reporting in a subsequent patch.

Signed-off-by: Marek Marczykowski-Górecki 
Acked-by: Jan Beulich 
---
New in v2
---
 xen/drivers/char/xhci-dbc.c     | 3 ++-
 xen/drivers/passthrough/iommu.c | 5 ++++-
 xen/include/xen/iommu.h         | 3 ++-
 3 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/xen/drivers/char/xhci-dbc.c b/xen/drivers/char/xhci-dbc.c
index 3bf389be7d0b..8e2037f1a5f7 100644
--- a/xen/drivers/char/xhci-dbc.c
+++ b/xen/drivers/char/xhci-dbc.c
@@ -1421,7 +1421,8 @@ void __init xhci_dbc_uart_init(void)
         iommu_add_extra_reserved_device_memory(
                 PFN_DOWN(virt_to_maddr(&dbc_dma_bufs)),
                 PFN_UP(sizeof(dbc_dma_bufs)),
-                uart->dbc.sbdf);
+                uart->dbc.sbdf,
+                "XHCI console");
         serial_register_uart(SERHND_XHCI, &dbc_uart_driver, &dbc_uart);
     }
 }
diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index 996c31be1284..03587c0cd680 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -682,6 +682,7 @@ struct extra_reserved_range {
     unsigned long start;
     unsigned long nr;
     pci_sbdf_t sbdf;
+    const char *name;
 };
 static unsigned int __initdata nr_extra_reserved_ranges;
 static struct extra_reserved_range __initdata
@@ -689,7 +690,8 @@ static struct extra_reserved_range __initdata
 
 int __init iommu_add_extra_reserved_device_memory(unsigned long start,
                                                   unsigned long nr,
-                                                  pci_sbdf_t sbdf)
+                                                  pci_sbdf_t sbdf,
+                                                  const char *name)
 {
     unsigned int idx;
 
@@ -700,6 +702,7 @@ int __init iommu_add_extra_reserved_device_memory(unsigned long start,
     extra_reserved_ranges[idx].start = start;
     extra_reserved_ranges[idx].nr = nr;
     extra_reserved_ranges[idx].sbdf = sbdf;
+    extra_reserved_ranges[idx].name = name;
 
     return 0;
 }
diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
index 9621459c63ee..b7829dff4588 100644
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -329,7 +329,8 @@ struct iommu_ops {
  */
 extern int iommu_add_extra_reserved_device_memory(unsigned long start,
                                                   unsigned long nr,
-                                                  pci_sbdf_t sbdf);
+                                                  pci_sbdf_t sbdf,
+                                                  const char *name);
 /*
  * To be called by specific IOMMU driver during initialization,
  * to fetch ranges registered with iommu_add_extra_reserved_device_memory().
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Wed Mar 27 02:57:37 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 02:57:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698295.1089816 (Exim 4.92)
	(envelope-from )
	id 1rpJTr-0002a7-9N; Wed, 27 Mar 2024 02:57:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698295.1089816; Wed, 27 Mar 2024 02:57:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpJTr-0002a0-5W; Wed, 27 Mar 2024 02:57:35 +0000
Received: by outflank-mailman (input) for mailman id 698295;
 Wed, 27 Mar 2024 02:57:34 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpJTq-0002Zs-BR
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 02:57:34 +0000
Received: from fout3-smtp.messagingengine.com (fout3-smtp.messagingengine.com
 [103.168.172.146]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c1a81304-ebe5-11ee-afe3-a90da7624cb6;
 Wed, 27 Mar 2024 03:57:33 +0100 (CET)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.47])
 by mailfout.nyi.internal (Postfix) with ESMTP id 43DC413800E8;
 Tue, 26 Mar 2024 22:57:32 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162])
 by compute6.internal (MEProxy); Tue, 26 Mar 2024 22:57:32 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 26 Mar 2024 22:57:30 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c1a81304-ebe5-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-type:content-type:date
	:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to; s=fm2; t=1711508252;
	 x=1711594652; bh=wfnlGUJ0PBfBfvaHMqLjqgg0lOPYtgwaj/UjhR9komE=; b=
	hNR1e2rivoHaavJBjpZnQr/q7bYcGa7TShVAu2s7WpEQM66JRYgVW2K7QUSHzaJj
	hnItgtzrWyG8uzs3oTSlbKiXcvAj6C7CQpk2ksBYzxaj9JZX4W/UkFILxjXYcjMi
	6Fg3Ghc32lRZ81Yz43bf2+TWJizmJ/eDnVWE1k32pbfjoCnnMW2E4mvnrwU2uZAR
	MoeYt+UYVHX9oxOBX59lcuUpFTUHveFJQ3sFP1PKX7gUxzL3DBns3PU6dYR4oeye
	Lwf0nDe4aCO/FDpmTwSiknQP6c7MsZG7hYAtueBQ8XjNg4LzFqzIuAdIVK/7t9+a
	omSYhAoeXLGua7Po3ATbYQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-type:content-type:date:date
	:feedback-id:feedback-id:from:from:in-reply-to:in-reply-to
	:message-id:mime-version:references:reply-to:subject:subject:to
	:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=
	fm2; t=1711508252; x=1711594652; bh=wfnlGUJ0PBfBfvaHMqLjqgg0lOPY
	tgwaj/UjhR9komE=; b=P23ruSVJ2hYFxa/BAEzHxIGMGLLwD8lt9niTeI+EluQb
	CQiKKMPVo+FncBGhIc+UcJ3RO/XErZWHYOF0r7B9D8+Ivckc2o/reJMnsCos1BM6
	Mach0UKrdex1NBuACq8zZqpQoQnztEk9Be2klViEp7brElOl4QvTGIjSK/jcJTvt
	LrnFF0KMttjHdmn3fY5sIlV7J3uku9ti9q6FPLsuRHhAoBQ0MeiJixbbf3X8g1j5
	eICRXxwkSXslUJAtm3IzY8zv6vunVFuIVtuCCWIG4+rQxZd4HYCV6sH5VhDb4dUV
	PseZPhUSW96bIEOu8rCkz2Jv1VMw8K6eqAji+peirg==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledruddugedgheegucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
    uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
    cujfgurhepfffhvfevuffkfhggtggujgesghdtreertddtjeenucfhrhhomhepofgrrhgv
    khcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinh
    hvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepgfdu
    leetfeevhfefheeiteeliefhjefhleduveetteekveettddvgeeuteefjedunecuvehluh
    hsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghk
    sehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Wed, 27 Mar 2024 03:57:27 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: xen-devel@lists.xenproject.org
Cc: Jan Beulich ,
	Andrew Cooper ,
	George Dunlap ,
	Julien Grall ,
	Stefano Stabellini , Wei Liu ,
	Paul Durrant ,
	Roger Pau =?utf-8?B?TW9ubsOp?= 
Subject: Re: [PATCH v3 1/2] IOMMU: store name for extra reserved device memory
Message-ID: 
References: <20240327025454.514521-1-marmarek@invisiblethingslab.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="v8NolazHSRHhgtQS"
Content-Disposition: inline
In-Reply-To: <20240327025454.514521-1-marmarek@invisiblethingslab.com>


--v8NolazHSRHhgtQS
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Wed, 27 Mar 2024 03:57:27 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: xen-devel@lists.xenproject.org
Cc: Jan Beulich ,
	Andrew Cooper ,
	George Dunlap ,
	Julien Grall ,
	Stefano Stabellini , Wei Liu ,
	Paul Durrant ,
	Roger Pau =?utf-8?B?TW9ubsOp?= 
Subject: Re: [PATCH v3 1/2] IOMMU: store name for extra reserved device memory

On Wed, Mar 27, 2024 at 03:53:10AM +0100, Marek Marczykowski-G=C3=B3recki w=
rote:
> It will be useful for error reporting in a subsequent patch.
>=20
> Signed-off-by: Marek Marczykowski-G=C3=B3recki 
> Acked-by: Jan Beulich 

This one is already applied, sorry for re-send.

> ---
> New in v2
> ---
>  xen/drivers/char/xhci-dbc.c     | 3 ++-
>  xen/drivers/passthrough/iommu.c | 5 ++++-
>  xen/include/xen/iommu.h         | 3 ++-
>  3 files changed, 8 insertions(+), 3 deletions(-)
>=20
> diff --git a/xen/drivers/char/xhci-dbc.c b/xen/drivers/char/xhci-dbc.c
> index 3bf389be7d0b..8e2037f1a5f7 100644
> --- a/xen/drivers/char/xhci-dbc.c
> +++ b/xen/drivers/char/xhci-dbc.c
> @@ -1421,7 +1421,8 @@ void __init xhci_dbc_uart_init(void)
>          iommu_add_extra_reserved_device_memory(
>                  PFN_DOWN(virt_to_maddr(&dbc_dma_bufs)),
>                  PFN_UP(sizeof(dbc_dma_bufs)),
> -                uart->dbc.sbdf);
> +                uart->dbc.sbdf,
> +                "XHCI console");
>          serial_register_uart(SERHND_XHCI, &dbc_uart_driver, &dbc_uart);
>      }
>  }
> diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/io=
mmu.c
> index 996c31be1284..03587c0cd680 100644
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -682,6 +682,7 @@ struct extra_reserved_range {
>      unsigned long start;
>      unsigned long nr;
>      pci_sbdf_t sbdf;
> +    const char *name;
>  };
>  static unsigned int __initdata nr_extra_reserved_ranges;
>  static struct extra_reserved_range __initdata
> @@ -689,7 +690,8 @@ static struct extra_reserved_range __initdata
> =20
>  int __init iommu_add_extra_reserved_device_memory(unsigned long start,
>                                                    unsigned long nr,
> -                                                  pci_sbdf_t sbdf)
> +                                                  pci_sbdf_t sbdf,
> +                                                  const char *name)
>  {
>      unsigned int idx;
> =20
> @@ -700,6 +702,7 @@ int __init iommu_add_extra_reserved_device_memory(uns=
igned long start,
>      extra_reserved_ranges[idx].start =3D start;
>      extra_reserved_ranges[idx].nr =3D nr;
>      extra_reserved_ranges[idx].sbdf =3D sbdf;
> +    extra_reserved_ranges[idx].name =3D name;
> =20
>      return 0;
>  }
> diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
> index 9621459c63ee..b7829dff4588 100644
> --- a/xen/include/xen/iommu.h
> +++ b/xen/include/xen/iommu.h
> @@ -329,7 +329,8 @@ struct iommu_ops {
>   */
>  extern int iommu_add_extra_reserved_device_memory(unsigned long start,
>                                                    unsigned long nr,
> -                                                  pci_sbdf_t sbdf);
> +                                                  pci_sbdf_t sbdf,
> +                                                  const char *name);
>  /*
>   * To be called by specific IOMMU driver during initialization,
>   * to fetch ranges registered with iommu_add_extra_reserved_device_memor=
y().
> --=20
> 2.43.0
>=20

--=20
Best Regards,
Marek Marczykowski-G=C3=B3recki
Invisible Things Lab

--v8NolazHSRHhgtQS
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYDixgACgkQ24/THMrX
1yxn1ggAhHmSiOVbErVsjrtLSxL6YMCr/2cB9EV7ru/8UXSEi5ysQbo3ATvxCNdX
/p9mz64eMGXGXQTAxrqWTBK6V0kX9ssvsOihSAF4UbtVbF/ESskIN2ThRtj5tMyQ
OMc6nQPWfarPYaa4klwiAsmYC3IDeV1lza1mlwlkPvPhpasWzkkskim8hgTSbXPr
zB5nzQ8vK14nGjvaYTpGz016xF0/aO3d9+92l/XWnvGDSmDtuFv85mhRO/lFmA0X
1bGCnVMAeWbk8S8SuO/MSVlv8j8C/b420uiwL9JNKQYaFPW2aX0X7RszS3i82Zqq
bwpYSV7mIdLAW95zlXvm7ljQY3fdRw==
=1MrU
-----END PGP SIGNATURE-----

--v8NolazHSRHhgtQS--


From xen-devel-bounces@lists.xenproject.org Wed Mar 27 03:06:35 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 03:06:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698300.1089836 (Exim 4.92)
	(envelope-from )
	id 1rpJcX-0004rr-BE; Wed, 27 Mar 2024 03:06:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698300.1089836; Wed, 27 Mar 2024 03:06:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpJcX-0004rk-8e; Wed, 27 Mar 2024 03:06:33 +0000
Received: by outflank-mailman (input) for mailman id 698300;
 Wed, 27 Mar 2024 03:06:31 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpJcV-0004d3-7p
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 03:06:31 +0000
Received: from fout3-smtp.messagingengine.com (fout3-smtp.messagingengine.com
 [103.168.172.146]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0177300e-ebe7-11ee-a1ef-f123f15fe8a2;
 Wed, 27 Mar 2024 04:06:29 +0100 (CET)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.48])
 by mailfout.nyi.internal (Postfix) with ESMTP id C74C81380165;
 Tue, 26 Mar 2024 23:06:28 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163])
 by compute7.internal (MEProxy); Tue, 26 Mar 2024 23:06:28 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 26 Mar 2024 23:06:27 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0177300e-ebe7-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:from:from:in-reply-to
	:in-reply-to:message-id:mime-version:references:reply-to:subject
	:subject:to:to; s=fm2; t=1711508788; x=1711595188; bh=MbWNAocmC2
	tXBNyeSris83Z/pJQ9bxIJsFcp7jvH5XI=; b=B9XiLJ1Neg+S24LlG51xvdKE3F
	09Eso1tQ6eMCxdX8xfVx09URS4QDwDXRVh0fyn7FIxabsDhRjzljbNXrF0Lq2rTG
	cPi2Xo6LK3zo9eaBCWpFzZVIpvSTNQ65CN69nb8TfJXc/V9uJYnTOLjLWAk8iphm
	IHDf6Ep3ZzOWL+rwAKMeQBR0cDJ7QPw/Cg8axiXh7jb6cfLN1n3ZF0jrEKikMYCg
	Fgni1Mrx7OgrHfiOHwKcoi7z4gAbtX6pAsuCE3qlxdvXp1ew0m6HY6bmMEI6Mgj2
	nvJrKwskZcdUm0fhlo96QhwCPz09U0RvGj2+VF8ooZNuIOfg136ADQP87I6w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:feedback-id:feedback-id
	:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy
	:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1711508788; x=
	1711595188; bh=MbWNAocmC2tXBNyeSris83Z/pJQ9bxIJsFcp7jvH5XI=; b=x
	rn9Iqc7z00/ieKDGMeEHf1xO9LKYNU0XBssT6keiTb7RQ9Hws4K0T5mPmvSejNv/
	UXTuHacyb1TwViEI0fJ0LLH/7qJxA0aVOmxvN03bxmQgPWvAMIAYBcmmNtRC2d8s
	zksfLwnyJDoYRjl/5UeEpBCPuzYCS0FdYMTqZUOBd6gf5j9iAGQdwV0gYdqX+kVl
	L2yHAJJt4cyCM7XKkW4gATx7UOSnPXwNjjA6MVafYQUVfUQJd42VMB1GW4jS85wL
	awikQIvHhpI/gObFsUMzSqsvgopC+osgLzTtFcWNSPvWE0nzLQZVGTDhyvwAng7N
	xkQguMh4PqLAY/npi3PpA==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledruddugedgheeiucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
    uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
    cujfgurhephffvvefufffkofgjfhggtgfgsehtkeertdertdejnecuhfhrohhmpeforghr
    vghkucforghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesih
    hnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpefg
    ueduhefgvdefheehudejheefudevueeghfekhfehleegveduteeuiedugffgffenucevlh
    hushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgv
    khesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhm
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
To: qemu-devel@nongnu.org
Cc: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Stefano Stabellini ,
	Anthony Perard ,
	Paul Durrant ,
	xen-devel@lists.xenproject.org (open list:X86 Xen CPUs)
Subject: [PATCH v3 2/2] xen: fix stubdom PCI addr
Date: Wed, 27 Mar 2024 04:05:15 +0100
Message-ID: <35049e99da634a74578a1ff2cb3ae4cc436ede33.1711506237.git-series.marmarek@invisiblethingslab.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

When running in a stubdomain, the config space access via sysfs needs to
use BDF as seen inside stubdomain (connected via xen-pcifront), which is
different from the real BDF. For other purposes (hypercall parameters
etc), the real BDF needs to be used.
Get the in-stubdomain BDF by looking up relevant PV PCI xenstore
entries.

Signed-off-by: Marek Marczykowski-Górecki 
---
Changes in v3:
- reduce 'path' size
- add two missing error_setg() calls
- coding style
Changes in v2:
- use xs_node_scanf
- use %d instead of %u to read values written as %d
- add a comment from another iteration of this patch by Jason Andryuk
---
 hw/xen/xen-host-pci-device.c | 76 ++++++++++++++++++++++++++++++++++++-
 hw/xen/xen-host-pci-device.h |  6 +++-
 2 files changed, 81 insertions(+), 1 deletion(-)

diff --git a/hw/xen/xen-host-pci-device.c b/hw/xen/xen-host-pci-device.c
index 8c6e9a1..eaf32f2 100644
--- a/hw/xen/xen-host-pci-device.c
+++ b/hw/xen/xen-host-pci-device.c
@@ -9,6 +9,8 @@
 #include "qemu/osdep.h"
 #include "qapi/error.h"
 #include "qemu/cutils.h"
+#include "hw/xen/xen-legacy-backend.h"
+#include "hw/xen/xen-bus-helper.h"
 #include "xen-host-pci-device.h"
 
 #define XEN_HOST_PCI_MAX_EXT_CAP \
@@ -33,13 +35,73 @@
 #define IORESOURCE_PREFETCH     0x00001000      /* No side effects */
 #define IORESOURCE_MEM_64       0x00100000
 
+/*
+ * Non-passthrough (dom0) accesses are local PCI devices and use the given BDF
+ * Passthough (stubdom) accesses are through PV frontend PCI device.  Those
+ * either have a BDF identical to the backend's BDF (xen-backend.passthrough=1)
+ * or a local virtual BDF (xen-backend.passthrough=0)
+ *
+ * We are always given the backend's BDF and need to lookup the appropriate
+ * local BDF for sysfs access.
+ */
+static void xen_host_pci_fill_local_addr(XenHostPCIDevice *d, Error **errp)
+{
+    unsigned int num_devs, len, i;
+    unsigned int domain, bus, dev, func;
+    char *be_path = NULL;
+    char path[16];
+
+    be_path = qemu_xen_xs_read(xenstore, 0, "device/pci/0/backend", &len);
+    if (!be_path) {
+        error_setg(errp, "Failed to read device/pci/0/backend");
+        goto out;
+    }
+
+    if (xs_node_scanf(xenstore, 0, be_path, "num_devs", NULL,
+                      "%d", &num_devs) != 1) {
+        error_setg(errp, "Failed to read or parse %s/num_devs", be_path);
+        goto out;
+    }
+
+    for (i = 0; i < num_devs; i++) {
+        snprintf(path, sizeof(path), "dev-%d", i);
+        if (xs_node_scanf(xenstore, 0, be_path, path, NULL,
+                          "%x:%x:%x.%x", &domain, &bus, &dev, &func) != 4) {
+            error_setg(errp, "Failed to read or parse %s/%s", be_path, path);
+            goto out;
+        }
+        if (domain != d->domain ||
+                bus != d->bus ||
+                dev != d->dev ||
+                func != d->func)
+            continue;
+        snprintf(path, sizeof(path), "vdev-%d", i);
+        if (xs_node_scanf(xenstore, 0, be_path, path, NULL,
+                          "%x:%x:%x.%x", &domain, &bus, &dev, &func) != 4) {
+            error_setg(errp, "Failed to read or parse %s/%s", be_path, path);
+            goto out;
+        }
+        d->local_domain = domain;
+        d->local_bus = bus;
+        d->local_dev = dev;
+        d->local_func = func;
+        goto out;
+    }
+    error_setg(errp, "Failed to find PCI device %x:%x:%x.%x in xenstore",
+               d->domain, d->bus, d->dev, d->func);
+
+out:
+    free(be_path);
+}
+
 static void xen_host_pci_sysfs_path(const XenHostPCIDevice *d,
                                     const char *name, char *buf, ssize_t size)
 {
     int rc;
 
     rc = snprintf(buf, size, "/sys/bus/pci/devices/%04x:%02x:%02x.%d/%s",
-                  d->domain, d->bus, d->dev, d->func, name);
+                  d->local_domain, d->local_bus, d->local_dev, d->local_func,
+                  name);
     assert(rc >= 0 && rc < size);
 }
 
@@ -342,6 +404,18 @@ void xen_host_pci_device_get(XenHostPCIDevice *d, uint16_t domain,
     d->dev = dev;
     d->func = func;
 
+    if (xen_is_stubdomain) {
+        xen_host_pci_fill_local_addr(d, errp);
+        if (*errp) {
+            goto error;
+        }
+    } else {
+        d->local_domain = d->domain;
+        d->local_bus = d->bus;
+        d->local_dev = d->dev;
+        d->local_func = d->func;
+    }
+
     xen_host_pci_config_open(d, errp);
     if (*errp) {
         goto error;
diff --git a/hw/xen/xen-host-pci-device.h b/hw/xen/xen-host-pci-device.h
index 4d8d34e..270dcb2 100644
--- a/hw/xen/xen-host-pci-device.h
+++ b/hw/xen/xen-host-pci-device.h
@@ -23,6 +23,12 @@ typedef struct XenHostPCIDevice {
     uint8_t dev;
     uint8_t func;
 
+    /* different from the above in case of stubdomain */
+    uint16_t local_domain;
+    uint8_t local_bus;
+    uint8_t local_dev;
+    uint8_t local_func;
+
     uint16_t vendor_id;
     uint16_t device_id;
     uint32_t class_code;
-- 
git-series 0.9.1


From xen-devel-bounces@lists.xenproject.org Wed Mar 27 03:06:35 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 03:06:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698299.1089826 (Exim 4.92)
	(envelope-from )
	id 1rpJcV-0004dG-4e; Wed, 27 Mar 2024 03:06:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698299.1089826; Wed, 27 Mar 2024 03:06:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpJcV-0004d9-1L; Wed, 27 Mar 2024 03:06:31 +0000
Received: by outflank-mailman (input) for mailman id 698299;
 Wed, 27 Mar 2024 03:06:29 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpJcT-0004d3-G5
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 03:06:29 +0000
Received: from fout3-smtp.messagingengine.com (fout3-smtp.messagingengine.com
 [103.168.172.146]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 003d2dd1-ebe7-11ee-a1ef-f123f15fe8a2;
 Wed, 27 Mar 2024 04:06:27 +0100 (CET)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.46])
 by mailfout.nyi.internal (Postfix) with ESMTP id 73D7713800CD;
 Tue, 26 Mar 2024 23:06:26 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163])
 by compute2.internal (MEProxy); Tue, 26 Mar 2024 23:06:26 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 26 Mar 2024 23:06:24 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 003d2dd1-ebe7-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:from:from:in-reply-to
	:in-reply-to:message-id:mime-version:references:reply-to:subject
	:subject:to:to; s=fm2; t=1711508786; x=1711595186; bh=mH7qGKH3fb
	CivyC7O2Hbv2OPHkXyD7Im69azzuDMjbE=; b=ZOf9lyc6/HjY/wuJnLbLX2/GwE
	qfPsmb3WdAfan/JK7nNyrDQP5q6PnCDsFHyaLmzJ3zbXLXxnEqMa6lVrfZ3elMjg
	fekxlhfHdxlT7X5ik8oOmBMG702yFK3Fq0aa7MBaFxSgqxAYzqgHaDm25+HwTxON
	LwccVvhRoHocKX622oE87/9bINdRO8OuFUn0FuK4zp9OoTiLqUO2HmJbV7m560vF
	AArUt37PO3QVH6Ucixr34asDAOLv/rqPHDttCsN2O3lWl7aJ83/0Tl0DISGlSQ/G
	vfooRoNQn76qUTWFQSk95LWXcrU13DxyITj/i0ab7kUmZr0pKkAfe9X50T/g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:feedback-id:feedback-id
	:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy
	:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1711508786; x=
	1711595186; bh=mH7qGKH3fbCivyC7O2Hbv2OPHkXyD7Im69azzuDMjbE=; b=n
	e3hzTjafh0pQimzREXXjk4LxZqrkNunjuhCA9UwpwTfpDFt6BYsC7eRNo3Pm2gVU
	T9Gl6zemCY5luFdxvXaehc862Ik/eEflHH0VF4trhtAmDu16iW8zaCVGI6LCUVy8
	l0ViZKriTCHtgKx1b2JZP62y0jzuxadjgAdNViWY8g+CnInOYw3ZbCNZH9tSoUJI
	/b10Lx2SXEdFaC5JwU5VDXK5LcOIrTnmK8DI56mKTmjDcolnsQxl0QWoh+5N9sl5
	YevkOOcJsBXcZ08zIaGuFvFhKMuxHYxmsauyyA5a8N/UfbzwDqMr/FfKG8zwgQRX
	TKvapsNXH5GuDIZkhuy6A==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledruddugedgheeiucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
    uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
    cujfgurhephffvvefufffkofgjfhggtgfgsehtkeertdertdejnecuhfhrohhmpeforghr
    vghkucforghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesih
    hnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpefg
    ueduhefgvdefheehudejheefudevueeghfekhfehleegveduteeuiedugffgffenucevlh
    hushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgv
    khesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhm
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
To: qemu-devel@nongnu.org
Cc: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Stefano Stabellini ,
	Anthony Perard ,
	Paul Durrant ,
	Paolo Bonzini ,
	Richard Henderson ,
	Eduardo Habkost ,
	"Michael S. Tsirkin" ,
	Marcel Apfelbaum ,
	xen-devel@lists.xenproject.org (open list:X86 Xen CPUs)
Subject: [PATCH v3 1/2] hw/xen: detect when running inside stubdomain
Date: Wed, 27 Mar 2024 04:05:14 +0100
Message-ID: 
X-Mailer: git-send-email 2.43.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Introduce global xen_is_stubdomain variable when qemu is running inside
a stubdomain instead of dom0. This will be relevant for subsequent
patches, as few things like accessing PCI config space need to be done
differently.

Signed-off-by: Marek Marczykowski-Górecki 
---
Changes in v3:
- move to xen_hvm_init_pc()
- coding style
Changes in v2:
- use sigend int for domid to match xenstore_read_int() types
- fix code style
---
 hw/i386/xen/xen-hvm.c | 22 ++++++++++++++++++++++
 include/hw/xen/xen.h  |  1 +
 system/globals.c      |  1 +
 3 files changed, 24 insertions(+)

diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
index 7745cb3..3291c17 100644
--- a/hw/i386/xen/xen-hvm.c
+++ b/hw/i386/xen/xen-hvm.c
@@ -583,6 +583,26 @@ static void xen_wakeup_notifier(Notifier *notifier, void *data)
     xc_set_hvm_param(xen_xc, xen_domid, HVM_PARAM_ACPI_S_STATE, 0);
 }
 
+static bool xen_check_stubdomain(struct xs_handle *xsh)
+{
+    char *dm_path = g_strdup_printf(
+        "/local/domain/%d/image/device-model-domid", xen_domid);
+    char *val;
+    int32_t dm_domid;
+    bool is_stubdom = false;
+
+    val = xs_read(xsh, 0, dm_path, NULL);
+    if (val) {
+        if (sscanf(val, "%d", &dm_domid) == 1) {
+            is_stubdom = dm_domid != 0;
+        }
+        free(val);
+    }
+
+    g_free(dm_path);
+    return is_stubdom;
+}
+
 void xen_hvm_init_pc(PCMachineState *pcms, MemoryRegion **ram_memory)
 {
     MachineState *ms = MACHINE(pcms);
@@ -595,6 +615,8 @@ void xen_hvm_init_pc(PCMachineState *pcms, MemoryRegion **ram_memory)
 
     xen_register_ioreq(state, max_cpus, &xen_memory_listener);
 
+    xen_is_stubdomain = xen_check_stubdomain(state->xenstore);
+
     QLIST_INIT(&xen_physmap);
     xen_read_physmap(state);
 
diff --git a/include/hw/xen/xen.h b/include/hw/xen/xen.h
index 37ecc91..ecb89ec 100644
--- a/include/hw/xen/xen.h
+++ b/include/hw/xen/xen.h
@@ -36,6 +36,7 @@ enum xen_mode {
 extern uint32_t xen_domid;
 extern enum xen_mode xen_mode;
 extern bool xen_domid_restrict;
+extern bool xen_is_stubdomain;
 
 int xen_pci_slot_get_pirq(PCIDevice *pci_dev, int irq_num);
 int xen_set_pci_link_route(uint8_t link, uint8_t irq);
diff --git a/system/globals.c b/system/globals.c
index e353584..d602a04 100644
--- a/system/globals.c
+++ b/system/globals.c
@@ -60,6 +60,7 @@ bool qemu_uuid_set;
 uint32_t xen_domid;
 enum xen_mode xen_mode = XEN_DISABLED;
 bool xen_domid_restrict;
+bool xen_is_stubdomain;
 struct evtchn_backend_ops *xen_evtchn_ops;
 struct gnttab_backend_ops *xen_gnttab_ops;
 struct foreignmem_backend_ops *xen_foreignmem_ops;
-- 
git-series 0.9.1


From xen-devel-bounces@lists.xenproject.org Wed Mar 27 07:15:59 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 07:15:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698310.1089846 (Exim 4.92)
	(envelope-from )
	id 1rpNVX-0002o4-Na; Wed, 27 Mar 2024 07:15:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698310.1089846; Wed, 27 Mar 2024 07:15:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpNVX-0002nx-KM; Wed, 27 Mar 2024 07:15:35 +0000
Received: by outflank-mailman (input) for mailman id 698310;
 Wed, 27 Mar 2024 07:15:34 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpNVW-0002np-AX
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 07:15:34 +0000
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com
 [2a00:1450:4864:20::635])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id cb577774-ec09-11ee-a1ef-f123f15fe8a2;
 Wed, 27 Mar 2024 08:15:30 +0100 (CET)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-a46cd9e7fcaso763658466b.1
 for ; Wed, 27 Mar 2024 00:15:31 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 m22-20020a1709061ed600b00a46bef6f920sm5100486ejj.102.2024.03.27.00.15.29
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 27 Mar 2024 00:15:30 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: cb577774-ec09-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711523730; x=1712128530; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=us3vri0WL6DcRRT+Qz6GKdNEgSMy7Gk8UhBt4VZBaDQ=;
        b=AI8h6vPvWWheJoX2gDGm0v6GS3lXEf0ZHLeLwQKzLRtYLN2vaTUQd5bJpyyNEyERvE
         EB6SCk2L7gTxVDa5JfwcYbOOG3K3HQ/R6qHaF/8w5+Bt3N+UlLhwU2gdz45OkaVLp73C
         61wcFxYIs2HY5LY0x+hRzghvGYI9zw7NevwTaI0hTHjoTSbTssw8MT3x6GfYGVStUFAR
         w9oInpxFCAaVqCSSRwqyjSqiJ5hze3dKDVuOG7d5tkofZFPpZK1QNLSPCj3UdDsV35vy
         BmhBFt5fuQ4DgVWt+A7f822BTBPASva5dIMik07UeKY+nyBVeeIbIVHlyXM+keD37+AQ
         P1Ag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711523730; x=1712128530;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=us3vri0WL6DcRRT+Qz6GKdNEgSMy7Gk8UhBt4VZBaDQ=;
        b=uxOvF/X4Yfr6RkNvvnSkcakFYzHVLQbkI6kFkrGuNW8oYPg+yuWByWek9zmUj/jEUv
         6VJh/NtUMHYgm4INJ3JBETu+8/p799EpJS+X6N6HyZ6z2jenj0m+IFLQM2SvSReQMQW7
         AoQ9swJKAn6T5oIsBtBC7hfcx5pvzGvjoHFHMLWnA9E+Jg3nSo3PEMV8KYLUr1Skh4BD
         kMsZbB8DVCs21ra7tOcobs28kPZjhu7wTs5reUDqygQuxMvgvFRX4wruDslkAJlpVF9O
         APvp6XAIHsv4IdwmekGn0zOAxELzP0Gq6KBQzoOi/mj9b6xdfN650CqeIChHd2C90kIe
         Oa/Q==
X-Gm-Message-State: AOJu0Yxb0voaJUWL5060MRAMSaPj2+mL/weiy2mC/mv4ucxySYhWaTvD
	QZli/Tbl9cHwcwxmhYuMBi+mJS2Q6IiNngNi7+CDfXRhF++8SOsRvPYdm5AbZQ==
X-Google-Smtp-Source: AGHT+IHOO2TRxPsinQvFcUlHEbIjARG7G9DIoydtkKZCeqgGiLZjMyIHE9KQHCLQMqvzkRmXKoNmIw==
X-Received: by 2002:a17:906:5943:b0:a45:f352:73b0 with SMTP id g3-20020a170906594300b00a45f35273b0mr260881ejr.65.1711523730528;
        Wed, 27 Mar 2024 00:15:30 -0700 (PDT)
Message-ID: 
Date: Wed, 27 Mar 2024 08:15:29 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/vcpu: relax VCPUOP_initialise restriction for non-PV
 vCPUs
Content-Language: en-US
To: Julien Grall 
Cc: xen-devel@lists.xenproject.org, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , George Dunlap ,
 Stefano Stabellini , Wei Liu ,
 Andrew Cooper 
References: <20240320135720.68894-1-roger.pau@citrix.com>
 <1304a0d2-ff17-4823-9d31-c32eb7b79f30@citrix.com> 
 <815d5bd4-18af-4f5f-b6a5-6302a1d682a2@citrix.com>
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 26.03.2024 23:08, Julien Grall wrote:
> Hi Andrew,
> 
> On 20/03/2024 14:39, Andrew Cooper wrote:
>> On 20/03/2024 2:26 pm, Roger Pau Monné wrote:
>>> On Wed, Mar 20, 2024 at 02:06:27PM +0000, Andrew Cooper wrote:
>>>> On 20/03/2024 1:57 pm, Roger Pau Monne wrote:
>>>>> There's no reason to force HVM guests to have a valid vcpu_info area when
>>>>> initializing a vCPU, as the vCPU can also be brought online using the local
>>>>> APIC, and on that path there's no requirement for vcpu_info to be setup ahead
>>>>> of the bring up.  Note an HVM vCPU can operate normally without making use of
>>>>> vcpu_info.
>>>>>
>>>>> Restrict the check against dummy_vcpu_info to only apply to PV guests.
>>>>>
>>>>> Fixes: 192df6f9122d ('x86: allow HVM guests to use hypercalls to bring up vCPUs')
>>>>> Signed-off-by: Roger Pau Monné 
>>>> Thanks for looking into this.  But, do we actually need to force this on
>>>> PV either?
>>> Possibly, having now taken a look at the users it does seem they could
>>> cope with unpopulated vcpu_info_area.
>>>
>>> Part of my understanding was that this was some kind of courtesy to PV
>>> guests in order to prevent starting them without a vcpu_info, which
>>> strictly speaking is not mandatory, but otherwise the guest vCPU won't
>>> be able to receive interrupts, not even IPIs.
>>
>> That's more of a stick than a carrot... "you must set up the area of a
>> CPU before you can bring it online". Except as we've seen, HVM has been
>> fine all along without it.
>>>> The only interesting user of dummy_vcpu_info now is vcpu_info_populate()
>>>> which can cope with any arbitrary vCPU.
>>>>
>>>> I have a suspicion that we can (now) delete these two checks, delete the
>>>> dummy_vcpu_info object, and use a regular NULL pointer in
>>>> vcpu_info_{populate,reset}(), and in doing so, remove one of the bigger
>>>> pieces of PV-absurdity from Xen.
>>> I was expecting this to be something we can backport.  OTOH removing
>>> the check completely (or even getting rid of dummy_vcpu_info) is not
>>> something that we would want to backport.
>>>
>>> I would rather do the removal of dummy_vcpu_info as followup work.
>>
>> I was worried about ARM with your patch, because it's spelt HVM there,
>> rather than PV.
>>
>> However, I'd forgotten that ARM's do_vcpu_op() filters ops down to just
>> VCPUOP_register_{vcpu_info,runstate_memory_area} so VCPUOP_initialise
>> isn't reachable.
>>
>> Therefore, Reviewed-by: Andrew Cooper 
>>
>> It also means ARM can't use any of the PHYS registration yet...
> 
> Whoops. I don't think this was intended. Jan, I don't seem to find any 
> use in Linux. Do you have any patches you could share?

No, I don't. I did all development with hacked up XTF tests, and I was
expecting Linux folks to be looking into making use of the new subops.

Jan

> I would like to 
> give a try on Arm before sending a patch?
> 
> Cheers,
> 



From xen-devel-bounces@lists.xenproject.org Wed Mar 27 07:22:50 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 07:22:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698315.1089855 (Exim 4.92)
	(envelope-from )
	id 1rpNcU-0004Wz-Fc; Wed, 27 Mar 2024 07:22:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698315.1089855; Wed, 27 Mar 2024 07:22:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpNcU-0004Ws-D2; Wed, 27 Mar 2024 07:22:46 +0000
Received: by outflank-mailman (input) for mailman id 698315;
 Wed, 27 Mar 2024 07:22:44 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpNcS-0004Wm-Mo
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 07:22:44 +0000
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com
 [2a00:1450:4864:20::52a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id cd61d5dc-ec0a-11ee-afe3-a90da7624cb6;
 Wed, 27 Mar 2024 08:22:43 +0100 (CET)
Received: by mail-ed1-x52a.google.com with SMTP id
 4fb4d7f45d1cf-565c6cf4819so879799a12.1
 for ; Wed, 27 Mar 2024 00:22:43 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 gu3-20020a170906f28300b00a44ef54b6b6sm5051758ejb.58.2024.03.27.00.22.42
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 27 Mar 2024 00:22:42 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: cd61d5dc-ec0a-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711524163; x=1712128963; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=eLdo4Wz0xX2pl6liffVfYUwLzbfHut/9fMVcAutFxz4=;
        b=BVyM7TCJKZGvQhLJyAihhsJNfoker/LdDmjg3RA56x8A+czZxnuyCCRhiLMmQ52uG7
         V8PieurCpuI40PdofPKxzrUsaxsoorb4BM4uVZn0U+gh/OOsT7UECQX6r1HWxpW7RbQu
         orZtzMQ7lCT+wzFvJy7H212l+V0yRjOXqJTXmCljaQA6VYwIASYFKTUI9+M7XdDFbtWO
         l0Z1fhGjL/cSRDlXswGw+xj21nSOxRfM9BBUVrFwibVHhLR6UmkD6l/Alh+6QfBH2AWd
         6buqf1fA/3hTExLf3Z8WOhU4hXlJWKL5sHEhaKQhwcaFXesG+y+bigbGwMXc64Md+9VN
         +uyg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711524163; x=1712128963;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=eLdo4Wz0xX2pl6liffVfYUwLzbfHut/9fMVcAutFxz4=;
        b=SP9fWkb298s8jFlA3ky+XbNSeOvTA0agOjkG8l3aUImBg/lNiyvymo7ZS0u1l6L2DN
         ipSZfqt250YsZY6WKMN3UlswI6807ErRt56lGPU+WApyTSr0sLje2FqCvkvxXH59zVFI
         AZOV4ZLqoTpo9LxgoiCwxD0x6iu7ymZZ2hfv6YINcVmyG++q1WE71rIc0am8yFCf35ll
         IO36sBL9yJ0mjjVPPSlMDJOKxL5W6fVn4A3SQZRsEeDamv9QZ278L4XiY3KZKuyGCjbH
         XUK0lkxzDCM7JF77pdXXzKM1AKcv5IJy1ZxnH2XJsjWZWrzlydFjzUxUz/XC44U4Tu83
         DDHQ==
X-Forwarded-Encrypted: i=1; AJvYcCU4g2ZoEUWGBnAwUvLLhwESVV/wJkoTF+wsTN8h9WgwNsssrYwl/IZ5/4oKP6YSHsN4ppggzyYsUrIBefZIiia/tfsI1VRrC0yapwuNngI=
X-Gm-Message-State: AOJu0Yw/qNPiZQZxjev4w2oRVhpVRyxpJ5q9/UJi1m/88EgMwz44D9ic
	AGbWubnnim4P29FpALxQ2FBpOvsM0vDm7IloF5L4QkCSrzGNdeUB+1+/qTPoJpujJaCi23Z/VrQ
	=
X-Google-Smtp-Source: AGHT+IERnexuQrUL5gVTrlRV6mGWq4PryGqL7GfesAAWFqbCceAfz7el9vHcUYn+FSwNmEUnysHwug==
X-Received: by 2002:a17:906:1cd2:b0:a46:c11d:dd0a with SMTP id i18-20020a1709061cd200b00a46c11ddd0amr2865428ejh.31.1711524162881;
        Wed, 27 Mar 2024 00:22:42 -0700 (PDT)
Message-ID: 
Date: Wed, 27 Mar 2024 08:22:41 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 1/6] Revert "xen/x86: bzImage parse kernel_alignment"
Content-Language: en-US
To: Jason Andryuk ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: Andrew Cooper , xen-devel@lists.xenproject.org
References: <20240326213847.3944-1-jason.andryuk@amd.com>
 <20240326213847.3944-2-jason.andryuk@amd.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240326213847.3944-2-jason.andryuk@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 26.03.2024 22:38, Jason Andryuk wrote:
> A new ELF note will specify the alignment for a relocatable PVH kernel.
> ELF notes are suitable for vmlinux and other ELF files, so this
> Linux-specific bzImage parsing in unnecessary.
> 
> This reverts commit c44cac229067faeec8f49247d1cf281723ac2d40.
> 
> Signed-off-by: Jason Andryuk 

Since you keep re-sending this: In private discussion Roger has indicated
that, like me, he too would prefer falling back to the ELF data, before
falling back to the arch default (Roger, please correct me if I got it
wrong). That would make it necessary that the change you're proposing to
revert here is actually kept.

Or wait - what you're reverting is taking the alignment out of the
bzImage header. I don't expect the BSDs to use that protocol; aiui that's
entirely Linux-specific.

I further meanwhile realized that consulting the ELF phdrs may also be
ambiguous, as there may be more than one. I guess it would need to be the
maximum of all of them then.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Mar 27 07:24:36 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 07:24:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698317.1089866 (Exim 4.92)
	(envelope-from )
	id 1rpNeF-00053y-Pj; Wed, 27 Mar 2024 07:24:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698317.1089866; Wed, 27 Mar 2024 07:24:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpNeF-00053r-N8; Wed, 27 Mar 2024 07:24:35 +0000
Received: by outflank-mailman (input) for mailman id 698317;
 Wed, 27 Mar 2024 07:24:33 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpNeD-00053l-P2
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 07:24:33 +0000
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com
 [2a00:1450:4864:20::52c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0e8c1935-ec0b-11ee-afe3-a90da7624cb6;
 Wed, 27 Mar 2024 08:24:32 +0100 (CET)
Received: by mail-ed1-x52c.google.com with SMTP id
 4fb4d7f45d1cf-565c6cf4819so882012a12.1
 for ; Wed, 27 Mar 2024 00:24:32 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 c36-20020a509fa7000000b0056bdec673c3sm5168594edf.38.2024.03.27.00.24.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 27 Mar 2024 00:24:32 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0e8c1935-ec0b-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711524272; x=1712129072; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=bgk+4v2Dk2hXBC3aWBgG3RLvIadqLM5wfcRiQudpROU=;
        b=R50XraI39JasjePmSON6OxF7GlCSIX/0V9Syxfj121sCL0Xu9aaghc0Ym9Gm+2XNwF
         72UTpm8R3u+lWjllbGITOe0J56k6nko2LW5XYfqcGE5UTH3UZ4e26rgylvePG9fDNic7
         HI6LKsr9HSwFBOqROE5JnPhBfeAPYxz7qScQQ/+OeRIW47AHyibUjZn/iP/nRmpcmZVK
         EbS4tHsXHdq1LSaTHMnxnECwfg5w3HZOozjYHHTA7U2PnJwpN+d7vuCt7xGw4r+CIsR7
         HN1/WD27m0RFE2KbFpJhMU6ZeR6btoj8aDZppLKFKGII+KMxzrLaQDAUsfzwf5il3EeG
         UZ+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711524272; x=1712129072;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=bgk+4v2Dk2hXBC3aWBgG3RLvIadqLM5wfcRiQudpROU=;
        b=vPUm0a9NUEt+aeflQPrDWe9uzGrlRw4kxGU5TqWnEa4LqtQLajSk5srDnonrVsQUnl
         YGBbKTmMQkwGryFvXUZ79IKlUh3W2iaitvDVXmnfLmM7XRKG0c8kDWJNfMpJxuW6Yxzn
         346WdCADb3zKm4O7TIyBKqJR36xdAFubp36IabHbDnzS5itj55frApfCpqaKPm5ho2NA
         QQ64uhraEk4AgoB9aXSXV0mW0fqSqeOwc6hAhu6XhUioCPECzlJtCkCm/g1azMrTEpFm
         eglJWoI8D+g7y3mRNeAFs7f24C8u7N2Yo1djBi/zFxBaUq3Ve1scOeFqunEdx6x1PtiI
         rKiQ==
X-Forwarded-Encrypted: i=1; AJvYcCXq5jk79RkcxgPBAfxH9z6uHIBNpaACfEA0YAN+iigXULu5S9ZPEABgZShe8d7BNC76p0frMGKg9oy10GWeXWXbnDgwlaLJ7BZ6cmhXQiU=
X-Gm-Message-State: AOJu0YzNCrvs5Hfg9YwjxgN4p+2wB1aHAniyo3EwNiEoixdwHf5Fa09b
	ASGQ06ry7pO9X2S1W8M5FdElPoGkvSz73j1/o8xnFg3IYYzXv9gz9xLlS6cN0A==
X-Google-Smtp-Source: AGHT+IHYBHbOY+xO2iNf75TaJhKNA7zr0xcee7WRLG293hA0Xu30Gfbzvy15lXzJDcVRre536H1fBA==
X-Received: by 2002:a50:d506:0:b0:56b:e535:6b01 with SMTP id u6-20020a50d506000000b0056be5356b01mr3182051edi.4.1711524272460;
        Wed, 27 Mar 2024 00:24:32 -0700 (PDT)
Message-ID: 
Date: Wed, 27 Mar 2024 08:24:31 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 5/6] xen/elfnote: Specify ELF Notes are x86-specific
Content-Language: en-US
To: Jason Andryuk 
Cc: Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20240326213847.3944-1-jason.andryuk@amd.com>
 <20240326213847.3944-6-jason.andryuk@amd.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240326213847.3944-6-jason.andryuk@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 26.03.2024 22:38, Jason Andryuk wrote:
> The Xen ELF Notes are only used with x86.  libelf's elf_xen_note_check()
> exits early for ARM binaries with "ELF: Not bothering with notes on
> ARM".
> 
> Add a comment to the top of elfnote.h specifying that Notes are only used
> with x86 binaries.  This is to avoid adding disclaimers for individual
> notes.
> 
> Signed-off-by: Jason Andryuk 

Acked-by: Jan Beulich 




From xen-devel-bounces@lists.xenproject.org Wed Mar 27 07:27:21 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 07:27:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698321.1089875 (Exim 4.92)
	(envelope-from )
	id 1rpNgt-0005dH-84; Wed, 27 Mar 2024 07:27:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698321.1089875; Wed, 27 Mar 2024 07:27:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpNgt-0005dA-5L; Wed, 27 Mar 2024 07:27:19 +0000
Received: by outflank-mailman (input) for mailman id 698321;
 Wed, 27 Mar 2024 07:27:18 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpNgs-0005d4-EN
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 07:27:18 +0000
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com
 [2a00:1450:4864:20::62b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 709851c7-ec0b-11ee-afe3-a90da7624cb6;
 Wed, 27 Mar 2024 08:27:17 +0100 (CET)
Received: by mail-ej1-x62b.google.com with SMTP id
 a640c23a62f3a-a466fc8fcccso812652566b.1
 for ; Wed, 27 Mar 2024 00:27:17 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 la5-20020a170907780500b00a45621ded4bsm5137613ejc.146.2024.03.27.00.27.16
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 27 Mar 2024 00:27:16 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 709851c7-ec0b-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711524437; x=1712129237; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=EegPNsgq9Inh1Ns5GWaVBbwJz0FYVVfBErgh6ZZ7rWE=;
        b=I+TfbD8d4uERSRnrUNeOxDfwlyImL5oW7TkQG84qmTiS0UKF9e7/+lDpo/dArvqI/p
         l3EPdV+G4qAtN6zZUY/+cQ2OTUpoRidkxNhh/wYr1V5ol/og+CDai7XM4i830PNNCr1V
         fj+srSjJlBM0K7PQNeTwFYmcMcGH/kGmHoplrma4IgJYUMw8xSHxMZjz9BBIzT1D/YWy
         1fkuGpuYJp3FW7gmqrMq8AyT4OH+njsPqLsy9p8DmAjUxPNwgtjiww2itXSdgX/FMAxI
         Dk8PlCUImVYDJtOvwevKz9Wy8TOEJ93VV6N2JirWxl+3c3QEKhdBJHwEIeGR5Dedwcz0
         XMhQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711524437; x=1712129237;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=EegPNsgq9Inh1Ns5GWaVBbwJz0FYVVfBErgh6ZZ7rWE=;
        b=MMmfGdZdpwpkTj+5mHVmgoT2mm37nsYnE29V+qSizXKkAAoqgnIqgnvLir3hsuC+dc
         FAMbhfqMcP/8ojNX1e+ISqFk7aBiwTw6yNpLYIVvXnC7KAlsgpZiL2Z19d85+WNyaQaq
         91WOiKxL7NvX9zFK4TQUe2QSyZMYBsF/APZrmzVgE8Uk48mAK5ih22UOp40BhehXFIrO
         PT2GgNgn12d7dv8/WOd3EVgsJfsrijDDgGc2VMmFTSr++AbGjCIPRq+sn/0FqYhO9RRB
         XhRWQGWY8+o+LRVtopIyk4G+MIHN3z1Xeq2nuWpM9r8vhb8nbk4L7CSvUXlai3Em4TUJ
         R5+A==
X-Forwarded-Encrypted: i=1; AJvYcCXakMV9t+k1DyfaQNEZCnwMPgPVmXI2kxC2kWTCzVDeSnV9GyRfjj0rwJFl82AvvN8EDuCYrT5pueHP1LVifFrKszy2NpPdObaWl8w11s4=
X-Gm-Message-State: AOJu0Yw5HFfKktYVdPU2b1S9G0YImcUgvPgPUR/QszxQQBrgl/+38AhW
	WuRgeZ8j2rDo+L4J11y+bCNY0EgXC+ndLYLrNzi7RnL73pToU8jB9fWtxUAt7A==
X-Google-Smtp-Source: AGHT+IE3/kowIttJBjYObYBDpXYDXn6cHdQfpP9umz1tZDCLOSXhQcGF5Qw/Qi3OHuCeMU3da9VoLQ==
X-Received: by 2002:a17:906:2987:b0:a4a:3403:342e with SMTP id x7-20020a170906298700b00a4a3403342emr2172457eje.56.1711524436957;
        Wed, 27 Mar 2024 00:27:16 -0700 (PDT)
Message-ID: 
Date: Wed, 27 Mar 2024 08:27:15 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 4/6] libelf: Expand ELF note printing
Content-Language: en-US
To: Jason Andryuk 
Cc: Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20240326213847.3944-1-jason.andryuk@amd.com>
 <20240326213847.3944-5-jason.andryuk@amd.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240326213847.3944-5-jason.andryuk@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 26.03.2024 22:38, Jason Andryuk wrote:
> @@ -145,13 +150,20 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
>          elf_msg(elf, "ELF: note: %s = \"%s\"\n", note_desc[type].name, str);
>          parms->elf_notes[type].type = XEN_ENT_STR;
>          parms->elf_notes[type].data.str = str;
> -    }
> -    else
> -    {
> +        break;
> +
> +    case ELFNOTE_INT:
>          val = elf_note_numeric(elf, note);
>          elf_msg(elf, "ELF: note: %s = %#" PRIx64 "\n", note_desc[type].name, val);
>          parms->elf_notes[type].type = XEN_ENT_LONG;
>          parms->elf_notes[type].data.num = val;
> +        break;
> +
> +    case ELFNOTE_NAME:
> +        /* ELFNOTE_NAME has a newline printed at the end of the function to
> +         * optionally allow printing customized details. */
> +        elf_msg(elf, "ELF: note: %s", note_desc[type].name);
> +        break;

Well. I said "brief comment" for several reasons. One of them being that
it would best fit on a single line. Since now it doesn't, I have to point
out that this way comment style is violated.

/* NB: Newline emitted further down. */

?

Jan


From xen-devel-bounces@lists.xenproject.org Wed Mar 27 07:40:22 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 07:40:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698324.1089886 (Exim 4.92)
	(envelope-from )
	id 1rpNtQ-0000NV-Au; Wed, 27 Mar 2024 07:40:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698324.1089886; Wed, 27 Mar 2024 07:40:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpNtQ-0000NO-8C; Wed, 27 Mar 2024 07:40:16 +0000
Received: by outflank-mailman (input) for mailman id 698324;
 Wed, 27 Mar 2024 07:40:14 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpNtO-0000NG-On
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 07:40:14 +0000
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com
 [2a00:1450:4864:20::630])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3ea091fa-ec0d-11ee-a1ef-f123f15fe8a2;
 Wed, 27 Mar 2024 08:40:12 +0100 (CET)
Received: by mail-ej1-x630.google.com with SMTP id
 a640c23a62f3a-a44f2d894b7so779383466b.1
 for ; Wed, 27 Mar 2024 00:40:12 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 wn1-20020a170907068100b00a4dfd94fd40sm789681ejb.199.2024.03.27.00.40.10
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 27 Mar 2024 00:40:11 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3ea091fa-ec0d-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711525212; x=1712130012; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=9lP3rUv43mzNjT6fyW8vfw22i8hX3jzWZ1YZcyMJkr0=;
        b=fFOK7Nfp+PWXGUGKfEJB4HNXTnYZOmiEWnFhzdy8Cr2+SfJd0kDxPD2t680bpz0Cl8
         KHsKltiFxfe14VUiuoyJwaN9QWfGmtaZOLM1lPDgXHpHRVDrtWQ4de1lGGax/AykDEFO
         tz2zS+iKDhn04FWCU6k2JMvVtz/GSs+7TL2gdfsA3u6kCIv3nviuv2ff3slhlQWGbh4m
         bfabNl2DvJL+4LESLl5/2DPeNyqmoeL4LXQcRbbMzJFqJo+uqmgDbCgeB5or1+Q6rEgJ
         7knJdMbTau+mU3Z50f43JqB9ujW4PJIDx5zAFnEruYmh0qQ5wRZ3mjRy38sBzktp+feX
         wb+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711525212; x=1712130012;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=9lP3rUv43mzNjT6fyW8vfw22i8hX3jzWZ1YZcyMJkr0=;
        b=LNPq+1rUFJCTfOzQv1oXQGnTV79AoD98B6Ph54/KcJUW5M9JewP5UqFHGloKy/zU9H
         Rl9k9mGLPYPbhf45Cvz8FVdfidneHD6w7nLjgeoFCme9kyBMKkomKWuJpeS8H/Zh78lw
         6IwB7+kiAJg8Lv7FO2mKzgkFlcyiKPBNaTxRSkAS8sNXKd+uWQa/Tw1xgio12jW2ij3c
         I85fzsp3Qu4+RRpLq+FqD3wKgo/ataLyqfpFcq5pvU5FdxFkzjLkwibhKpoHhUpYF0KC
         sB6SbVWEvOEIJznHHX3r7N1+Ga/F8WECiLUm60UnDGr14+ONTF5ISFYDWEHph/88Yk/n
         cWiQ==
X-Forwarded-Encrypted: i=1; AJvYcCV8WgerMAAZkwAbvNELBJz/WSzFMvQsz3qjPYjlEKzwLfCAxNPNOmHaySOEL+6jQQHnVcDrx+0tGKIMWqekzCatFUWh9ACLY+v1nMWHbTg=
X-Gm-Message-State: AOJu0Yzt1+6kTvP0I7cdRg4CwBuLQzVjfF1Vh96NFJZGBvqT+ScHh1AU
	eELaOo+DZGILPIJhqZrwWGUseXvVMBuF8Yr6TMXFh6U5/fY4wZrHcRTvqiPnFg==
X-Google-Smtp-Source: AGHT+IH92B036ESIBZF8P1vl4I6jasxPuSqu0c0t7U6niijrLmjKyTUaFWqJhdDuYN1j3APriM9UHA==
X-Received: by 2002:a17:906:3b98:b0:a4a:ba53:27a6 with SMTP id u24-20020a1709063b9800b00a4aba5327a6mr3668626ejf.46.1711525211841;
        Wed, 27 Mar 2024 00:40:11 -0700 (PDT)
Message-ID: <2bac4852-b5f1-4424-ac1a-29e76563ab2b@suse.com>
Date: Wed, 27 Mar 2024 08:40:09 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 10/20] xen/riscv: introduce atomic.h
Content-Language: en-US
To: Oleksii 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 xen-devel@lists.xenproject.org
References: 
 <22ee9c8cc62c76cfb799fed800636e7c8bf25a17.1710517542.git.oleksii.kurochko@gmail.com>
 <78a86041-72e2-410f-b6a7-212656b0dba3@suse.com>
 
 <1a440fbf-f37c-41fe-b31c-0afe0fd77c8e@suse.com>
 <38de6dd8e9555fe4b573f9c2134a618a60c224df.camel@gmail.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <38de6dd8e9555fe4b573f9c2134a618a60c224df.camel@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 26.03.2024 20:02, Oleksii wrote:
> On Mon, 2024-03-25 at 09:18 +0100, Jan Beulich wrote:
>> On 22.03.2024 13:25, Oleksii wrote:
>>> On Thu, 2024-03-21 at 14:03 +0100, Jan Beulich wrote:
>>>> On 15.03.2024 19:06, Oleksii Kurochko wrote:
>>>>> + */
>>>>> +static always_inline void read_atomic_size(const volatile void
>>>>> *p,
>>>>> +                                           void *res,
>>>>> +                                           unsigned int size)
>>>>> +{
>>>>> +    switch ( size )
>>>>> +    {
>>>>> +    case 1: *(uint8_t *)res = readb(p); break;
>>>>> +    case 2: *(uint16_t *)res = readw(p); break;
>>>>> +    case 4: *(uint32_t *)res = readl(p); break;
>>>>> +    case 8: *(uint32_t *)res  = readq(p); break;
>>>>
>>>> Nit: Excess blank before =.
>>>>
>>>> Also - no #ifdef here to be RV32-ready?
>>> Because there is #ifdef RV32 in io.h for readq().
>>
>> There you'd run into __raw_readq()'s BUILD_BUG_ON(), afaict even for
>> 1-, 2-, or 4-byte accesses. That's not quite what we want here.
> Do you mean that if someone will redefine readq() in another way and
> not wrap it by #ifdef RV32? Except this I am not sure that there is an
> issue as it will be still a compilation error, so anyway it will be
> needed to provide an implementation for __raw_readq().

No. BUILD_BUG_ON() is a compile-time thing. The compiler will encounter
this construct. And hence it will necessarily fail. Which is why the
other approach (causing a linker error) is used elsewhere. And we're
still only in the course of considering to utilize DCE for something
like STATIC_ASSERT_UNREACHABLE(); iirc there was something getting in
the way there.

> One of the reason why I decided to wrap with #ifdef RV32 in io.h to not
> go over the source code and add wrapping. Also for some code it will be
> needed to rewrite it. For example, I am not sure that I can add #ifdef
> inside macros, f.e.:
>    #define write_atomic(p, x)                              \
>    ({                                                      \
>        typeof(*(p)) x__ = (x);                             \
>        switch ( sizeof(*(p)) )                             \
>        {                                                   \
>        case 1: writeb(x__, p); break;                      \
>        case 2: writew(x__, p); break;                      \
>        case 4: writel(x__, p); break;                      \
>        case 8: writeq(x__, p); break;                      \
>        default: __bad_atomic_size(); break;                \
>        }                                                   \
>        x__;                                                \
>    })

You can't add #ifdef there. Such needs abstracting differently.

But of course there's the option of simply not making any of these
constructs RV32-ready. Yet if so, that then will want doing
consistently.

>>>>> +/*
>>>>> + * First, the atomic ops that have no ordering constraints and
>>>>> therefor don't
>>>>> + * have the AQ or RL bits set.  These don't return anything,
>>>>> so
>>>>> there's only
>>>>> + * one version to worry about.
>>>>> + */
>>>>> +#define ATOMIC_OP(op, asm_op, I, asm_type, c_type, prefix)  \
>>>>> +static inline                                               \
>>>>> +void atomic##prefix##_##op(c_type i, atomic##prefix##_t *v) \
>>>>> +{                                                           \
>>>>> +    asm volatile (                                          \
>>>>> +        "   amo" #asm_op "." #asm_type " zero, %1, %0"      \
>>>>> +        : "+A" (v->counter)                                 \
>>>>> +        : "r" (I)                                           \
>>>>
>>>> Btw, I consider this pretty confusing. At the 1st and 2nd glance
>>>> this
>>>> looks like a mistake, i.e. as if i was meant. Imo ...
>>>>
>>>>> +        : "memory" );                                       \
>>>>> +}                                                           \
>>>>> +
>>>>> +/*
>>>>> + * Only CONFIG_GENERIC_ATOMIC64=y was ported to Xen that is
>>>>> the
>>>>> reason why
>>>>> + * last argument for ATOMIC_OP isn't used.
>>>>> + */
>>>>> +#define ATOMIC_OPS(op, asm_op, I)                           \
>>>>> +        ATOMIC_OP (op, asm_op, I, w, int,   )
>>>>> +
>>>>> +ATOMIC_OPS(add, add,  i)
>>>>> +ATOMIC_OPS(sub, add, -i)
>>>>> +ATOMIC_OPS(and, and,  i)
>>>>> +ATOMIC_OPS( or,  or,  i)
>>>>> +ATOMIC_OPS(xor, xor,  i)
>>>>
>>>> ... here you want to only pass the (unary) operator (and leaving
>>>> that
>>>> blank
>>>> is as fine as using +).
>>> I agree that a game with 'i' and 'I' looks confusing, but I am not
>>> really understand what is wrong with using ' i' here. It seems that
>>> preprocessed macros looks fine:
>>>    static inline void atomic_add(int i, atomic_t *v) { asm volatile
>>> ( "  
>>>    amo" "add" "." "w" " zero, %1, %0" : "+A" (v->counter) : "r" (i)
>>> :
>>>    "memory" ); }
>>>    
>>>    static inline void atomic_sub(int i, atomic_t *v) { asm volatile
>>> ( "  
>>>    amo" "add" "." "w" " zero, %1, %0" : "+A" (v->counter) : "r" (-
>>> i) :
>>>    "memory" ); }
>>
>> I didn't question the pre-processed result being correct. Instead I
>> said
>> that I consider the construct confusing to the reader, for looking as
>> if
>> there was a mistake (in the case of the letter i used). Note also in
>> particular how the macro invocations need to be in sync with the
>> macro
>> implementation, for lower case i being used both in the macro and in
>> its
>> invocations. Anything parameterized would better be fully so, at the
>> very least to avoid, as said, confusion. (Having macros depend on
>> context at their use sites _may_ be okay for local helper macros, but
>> here we're talking about a not even private header file.)
> I am not sure then I understand how mentioning '+i' will help
> significantly remove confusion.

I'm afraid I don't understand: What "mentioning '+i'" are you referring
to? I'm pretty sure I didn't suggest that. What I suggested was to pass
a bare operator (- or +) as macro argument.

>>>>> +/* This is required to provide a full barrier on success. */
>>>>> +static inline int atomic_add_unless(atomic_t *v, int a, int u)
>>>>> +{
>>>>> +       int prev, rc;
>>>>> +
>>>>> +    asm volatile (
>>>>> +        "0: lr.w     %[p],  %[c]\n"
>>>>> +        "   beq      %[p],  %[u], 1f\n"
>>>>> +        "   add      %[rc], %[p], %[a]\n"
>>>>> +        "   sc.w.rl  %[rc], %[rc], %[c]\n"
>>>>> +        "   bnez     %[rc], 0b\n"
>>>>> +        RISCV_FULL_BARRIER
>>>>
>>>> With this and no .aq on the load, why the .rl on the store?
>>> It is something that LKMM requires [1].
>>>
>>> This is not fully clear to me what is so specific in LKMM, but
>>> accoring
>>> to the spec:
>>>    Ordering Annotation Fence-based Equivalent
>>>    l{b|h|w|d|r}.aq     l{b|h|w|d|r}; fence r,rw
>>>    l{b|h|w|d|r}.aqrl   fence rw,rw; l{b|h|w|d|r}; fence r,rw
>>>    s{b|h|w|d|c}.rl     fence rw,w; s{b|h|w|d|c}
>>>    s{b|h|w|d|c}.aqrl   fence rw,w; s{b|h|w|d|c}
>>>    amo.aq          amo; fence r,rw
>>>    amo.rl          fence rw,w; amo
>>>    amo.aqrl        fence rw,rw; amo; fence rw,rw
>>>    Table 2.2: Mappings from .aq and/or .rl to fence-based
>>> equivalents.
>>>    An alternative mapping places a fence rw,rw after the existing 
>>>    s{b|h|w|d|c} mapping rather than at the front of the
>>>    l{b|h|w|d|r} mapping.
>>
>> I'm afraid I can't spot the specific case in this table. None of the
>> stores in the right column have a .rl suffix.
> Yes, it is expected.
> 
> I am reading this table as (f.e.) amo.rl is an equivalent of fence
> rw,w; amo. (without .rl) 

In which case: How does quoting the table answer my original question?

>>>    It is also safe to translate any .aq, .rl, or .aqrl annotation
>>> into
>>>    the fence-based snippets of
>>>    Table 2.2. These can also be used as a legal implementation of
>>>    l{b|h|w|d} or s{b|h|w|d} pseu-
>>>    doinstructions for as long as those instructions are not added
>>> to
>>>    the ISA.
>>>
>>> So according to the spec, it should be:
>>>  sc.w ...
>>>  RISCV_FULL_BARRIER.
>>>
>>> Considering [1] and how this code looks before, it seems to me that
>>> it
>>> is safe to use lr.w.aq/sc.w.rl here or an fence equivalent.
>>
>> Here you say "or". Then why dos the code use sc.?.rl _and_ a fence?
> I confused this line with amo.aqrl, so based on the table 2.2 above
> s{b|h|w|d|c}.aqrl is transformed to "fence rw,w; s{b|h|w|d|c}", but
> Linux kernel decided to strengthen it with full barrier:
>    -              "0:\n\t"
>    -              "lr.w.aqrl  %[p],  %[c]\n\t"
>    -              "beq        %[p],  %[u], 1f\n\t"
>    -              "add       %[rc],  %[p], %[a]\n\t"
>    -              "sc.w.aqrl %[rc], %[rc], %[c]\n\t"
>    -              "bnez      %[rc], 0b\n\t"
>    -              "1:"
>    +               "0:     lr.w     %[p],  %[c]\n"
>    +               "       beq      %[p],  %[u], 1f\n"
>    +               "       add      %[rc], %[p], %[a]\n"
>    +               "       sc.w.rl  %[rc], %[rc], %[c]\n"
>    +               "       bnez     %[rc], 0b\n"
>    +               "       fence    rw, rw\n"
>    +               "1:\n"
> As they have the following issue:
>    implementations of atomics such as atomic_cmpxchg() and
>    atomic_add_unless() rely on LR/SC pairs,
>    which do not give full-ordering with .aqrl; for example, current
>    implementations allow the "lr-sc-aqrl-pair-vs-full-barrier" test
>    below to end up with the state indicated in the "exists" clause.

Is that really "current implementations", not "the abstract model"?
If so, the use of an explicit fence would be more like a workaround
(and would hence want commenting to that effect).

In neither case can I see my original question answered: Why the .rl
on the store when there is a full fence later?

Jan


From xen-devel-bounces@lists.xenproject.org Wed Mar 27 08:18:58 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 08:18:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698337.1089896 (Exim 4.92)
	(envelope-from )
	id 1rpOUd-0005sG-SF; Wed, 27 Mar 2024 08:18:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698337.1089896; Wed, 27 Mar 2024 08:18:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpOUd-0005s9-OB; Wed, 27 Mar 2024 08:18:43 +0000
Received: by outflank-mailman (input) for mailman id 698337;
 Wed, 27 Mar 2024 08:18:42 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpOUc-0005s3-ST
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 08:18:42 +0000
Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com
 [2a00:1450:4864:20::636])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9efb5206-ec12-11ee-afe3-a90da7624cb6;
 Wed, 27 Mar 2024 09:18:41 +0100 (CET)
Received: by mail-ej1-x636.google.com with SMTP id
 a640c23a62f3a-a46a7208eedso870773866b.0
 for ; Wed, 27 Mar 2024 01:18:41 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 m5-20020a170906720500b00a4df01f4232sm1851904ejk.189.2024.03.27.01.18.40
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 27 Mar 2024 01:18:40 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9efb5206-ec12-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711527521; x=1712132321; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=g92gV5bK1TC6T/7m7x8stFN6RuCEj8I9N4+i0a1FKXw=;
        b=PYpu4l48c4NvrcYmZMwgQ4+li820a5P2BliutezOVQKnU6bXcaa4U1FOmlVwMU7WOT
         bz4RoKVo/iYrb1eFyChREo+rVCcuNd3J0CBWPS8sUOACUamd+wWrr4YV1V8SHuZDb+9k
         zNLj64RmNt9LzdL+5LTS//Bwgqtxb3QGmsF7b6G+5c1gffkds+MwvJrObXGiULtH4TGJ
         6hObtNFXj0FKtBsPnc8aZdZL78QL3V3gToD2LNT/6mqJ7Ju1WlBmFaEH+NOJOE+JdohU
         P2gJGCCT+QZjzj32LB9KHDFVpH4Lh5KmvjvMhi2SnQ2DDQlvbOs+Mvcepe/334WOjpSJ
         8afw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711527521; x=1712132321;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=g92gV5bK1TC6T/7m7x8stFN6RuCEj8I9N4+i0a1FKXw=;
        b=VgJ5ULTiQWPOw+6RcDyUWnREeC/daJdSbF6hSSI/PQISYuf8ovDxxYup9QIVmArssD
         ohHCZ8qA5WMKYTkPufIjE4R4vdVP2JyqhZ6gJcno+4/gCZm+gMsEItbbcCkecKvB3rWT
         hhGdJjUtBHpww/f17QFLQ8K0B05KsgCjpnMROiOJV7mxAu9Mvxe529/Tu9V5cyTK0lqa
         rH0aVDF1pWz9MxJNHBNAedjyYORunfLFm5G/LUOrW19+0lNHwWuLPt75/gYL7yYYlMvU
         T1YWQLYljGlgewsveXvZqqrVMgARFg9PZN/fAh3n9UX4Vb9vbdsxA3culqLEyGbQWPCo
         vbxQ==
X-Forwarded-Encrypted: i=1; AJvYcCXkMf2v82/E3kjzEWfWh+1TVmPrP42adcMAqWglvFU352TUuh7lHagJHN6n5kOO4BUFvbmSzliUk0xWAsQ2LeHyvxRYo9mzMA86P7wutmo=
X-Gm-Message-State: AOJu0YyIV/HkJyEFIYyER6a/VJ5YXqtjjbArZZqM8D6/MqatT2E51M4s
	qMb4f5+iiRy3hsAa5xAsG5Jz/9p9q3QUE5gUIp6DLIi2tOpd1gjy3lef2hD1Ew==
X-Google-Smtp-Source: AGHT+IHgeDP+HST5ioVm6VVAw+gxTJtMu96D/2cEFCBVpKdL0S30qLeBouBUW4miFov93Vyf7pyBag==
X-Received: by 2002:a17:906:8c3:b0:a47:3312:b32a with SMTP id o3-20020a17090608c300b00a473312b32amr2458089eje.58.1711527521160;
        Wed, 27 Mar 2024 01:18:41 -0700 (PDT)
Message-ID: <81af5825-cb82-4f91-b7ba-0fba995d24d1@suse.com>
Date: Wed, 27 Mar 2024 09:18:39 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 11/11] x86/public: hvm: address violations of MISRA C
 Rule 20.7
Content-Language: en-US
To: Nicola Vetrini 
Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com,
 ayan.kumar.halder@amd.com, consulting@bugseng.com,
 andrew.cooper3@citrix.com, roger.pau@citrix.com, bertrand.marquis@arm.com,
 julien@xen.org, xen-devel@lists.xenproject.org
References: 
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 22.03.2024 17:02, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be safe with respect to expansions that
> can possibly alter the semantics of the passed-in macro parameter.
> 
> No functional change.
> 
> Signed-off-by: Nicola Vetrini 

Btw, I've taken the liberty to drop the (secondary) hvm: prefix from the
subject; I can't ...

> --- a/xen/include/public/arch-x86/xen.h
> +++ b/xen/include/public/arch-x86/xen.h
> @@ -36,7 +36,7 @@
>  #define __XEN_GUEST_HANDLE(name)        __guest_handle_ ## name
>  #define XEN_GUEST_HANDLE(name)          __XEN_GUEST_HANDLE(name)
>  #define XEN_GUEST_HANDLE_PARAM(name)    XEN_GUEST_HANDLE(name)
> -#define set_xen_guest_handle_raw(hnd, val)  do { (hnd).p = val; } while (0)
> +#define set_xen_guest_handle_raw(hnd, val)  do { (hnd).p = (val); } while (0)
>  #define set_xen_guest_handle(hnd, val) set_xen_guest_handle_raw(hnd, val)

... spot anything HVM-specific in this change.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Mar 27 08:20:06 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 08:20:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698339.1089906 (Exim 4.92)
	(envelope-from )
	id 1rpOVx-0007Lm-5a; Wed, 27 Mar 2024 08:20:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698339.1089906; Wed, 27 Mar 2024 08:20:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpOVx-0007LC-2U; Wed, 27 Mar 2024 08:20:05 +0000
Received: by outflank-mailman (input) for mailman id 698339;
 Wed, 27 Mar 2024 08:20:04 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpOVw-0006xf-HP
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 08:20:04 +0000
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com
 [2a00:1450:4864:20::529])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ce8a0d81-ec12-11ee-a1ef-f123f15fe8a2;
 Wed, 27 Mar 2024 09:20:01 +0100 (CET)
Received: by mail-ed1-x529.google.com with SMTP id
 4fb4d7f45d1cf-56c4030a6easo241815a12.0
 for ; Wed, 27 Mar 2024 01:20:01 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 m5-20020a170906720500b00a4df01f4232sm1851904ejk.189.2024.03.27.01.20.00
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 27 Mar 2024 01:20:00 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ce8a0d81-ec12-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711527601; x=1712132401; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=dbdQ/uvnHSq8FwOCP2tDQ95vkaM+LDk1v7I85aR2ELw=;
        b=a7HNHjRgkKehB2LImz3Tt87MQQ5VLCWXMdX3GfXnPIch9fPIWQRLkbpYLw7p6adfRR
         8halG8qd1PSkMq4YdtMckz9FjEVN/0COR7g1eTnn2l/DDoM/yA1i+lpiJxLUmqgBJWPa
         A01iRvxUPDVXSnvZYm6Sb+ksAUuWYQxzmr239T9bneOwLuDeEP1YsJFJjKusdXfaXAS0
         E0LBLLKq6Eqpk3ZAG+LbhE6GNbjGPRcmE68RLV+9Ou8pFsWQ9YDJTlB8PN5FgTKxbh67
         PMol4OLzNNP8G7V1V7JgS0/BYAefXJPl+dSDAjrpD5Wh6Tg5/Ds/cVkYyCw/VLEHWxaG
         l9lg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711527601; x=1712132401;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=dbdQ/uvnHSq8FwOCP2tDQ95vkaM+LDk1v7I85aR2ELw=;
        b=g+GwqiZ7j+ePtQ+pexPDPAChbNkA3CxILCLCIZRXlX5lTdAq8Q/sh9WDMVYEatf1w9
         JRwCPh0y7+9J4PdhcLbDzEhrEzo+cBDGFJyzfjaW01jBZweI5Vzlq7/QwcrHVHVKVWr2
         Obf+3UbpaHiHe3eEvF6DBrwhB9/DH4IqSw619f1Ei+pltTZXmZ6VdWoyfSpoubvvbeen
         leWJAPjZY+s1HFDQiPuhCesD5BNL/dUsovy3a3zQIBWAHgkft2Bdy522ZPhpWbfL9nIX
         M4IYiIGmSVIuMGlh7SeHabWAFNHwt1cH63XnlN2wn6ih3vUKEFGoC/D0CPktxTbBYomj
         rELA==
X-Forwarded-Encrypted: i=1; AJvYcCX5dM3G29fL9eLp3W2/6JAZRuRmTZxHUSwAtZcOCy57d2ImUzA1jynuGNl6nwaThX7BZFZdOs6AgchxD3dgEEPjPUYw6f/BScJ4yu7Qov0=
X-Gm-Message-State: AOJu0Yytjn1/NjVvXbynp99UQXONILBbFWb+gIm/V8ryQRL0+Gk6psES
	+H9fY+MIj8ox+EMLJsrw527Hh5AtQfyY0ziGlazwiM8/Q2rRmhQjhN/4MEzCUA==
X-Google-Smtp-Source: AGHT+IFIpHkwPppZIaj9IblhQ1CjaPrqMxmg7azN1JlKqvIo35cVX0jiKmcqj239bcv3L4fnWPaZew==
X-Received: by 2002:a17:906:a255:b0:a46:7323:6ab3 with SMTP id bi21-20020a170906a25500b00a4673236ab3mr1297907ejb.49.1711527600834;
        Wed, 27 Mar 2024 01:20:00 -0700 (PDT)
Message-ID: <45c20ffd-f0c0-4521-8221-c3384cd5f7c5@suse.com>
Date: Wed, 27 Mar 2024 09:20:00 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5] RFC: x86/pvh: Make Xen PVH entrypoint PIC for x86-64
Content-Language: en-US
To: Jason Andryuk 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Andrew Cooper , Juergen Gross ,
 Boris Ostrovsky , xen-devel@lists.xenproject.org
References: <20240326213847.3944-1-jason.andryuk@amd.com>
 <20240326214701.7015-1-jason.andryuk@amd.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240326214701.7015-1-jason.andryuk@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 26.03.2024 22:47, Jason Andryuk wrote:
> --- a/include/xen/interface/elfnote.h
> +++ b/include/xen/interface/elfnote.h
> @@ -185,9 +185,25 @@
>   */
>  #define XEN_ELFNOTE_PHYS32_ENTRY 18
>  
> +/*
> + * Physical loading constraints for PVH kernels
> + *
> + * Used to place constraints on the guest physical loading addresses and
> + * alignment for a PVH kernel.
> + *
> + * The presence of this note indicates the kernel supports relocating itself.
> + *
> + * The note may include up to three 32bit values in the following order:
> + *  - a maximum address for the entire image to be loaded below (default
> + *      0xffffffff)
> + *  - a minimum address for the start of the image (default 0)
> + *  - a required start alignment (default 0x200000)

This looks to be stale now.

Jan



From xen-devel-bounces@lists.xenproject.org Wed Mar 27 08:27:22 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 08:27:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698354.1089956 (Exim 4.92)
	(envelope-from )
	id 1rpOcw-0000BK-9G; Wed, 27 Mar 2024 08:27:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698354.1089956; Wed, 27 Mar 2024 08:27:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpOcw-0000BD-6W; Wed, 27 Mar 2024 08:27:18 +0000
Received: by outflank-mailman (input) for mailman id 698354;
 Wed, 27 Mar 2024 08:27:16 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpOcu-0000B7-RT
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 08:27:16 +0000
Received: from NAM04-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam04on20601.outbound.protection.outlook.com
 [2a01:111:f403:240a::601])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id cfcd0a51-ec13-11ee-a1ef-f123f15fe8a2;
 Wed, 27 Mar 2024 09:27:14 +0100 (CET)
Received: from BN0PR07CA0017.namprd07.prod.outlook.com (2603:10b6:408:141::31)
 by PH7PR12MB7019.namprd12.prod.outlook.com (2603:10b6:510:1b9::9)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.33; Wed, 27 Mar
 2024 08:27:08 +0000
Received: from BN3PEPF0000B078.namprd04.prod.outlook.com
 (2603:10b6:408:141:cafe::70) by BN0PR07CA0017.outlook.office365.com
 (2603:10b6:408:141::31) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.13 via Frontend
 Transport; Wed, 27 Mar 2024 08:27:07 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN3PEPF0000B078.mail.protection.outlook.com (10.167.243.123) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Wed, 27 Mar 2024 08:27:07 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Wed, 27 Mar
 2024 03:27:04 -0500
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB05.amd.com
 (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Wed, 27 Mar
 2024 03:27:04 -0500
Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Wed, 27 Mar 2024 03:27:02 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: cfcd0a51-ec13-11ee-a1ef-f123f15fe8a2
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=Owl561qJuf4oC8K58KA/OwuxUdZyW/Wp22TThoY3g9+T858f+WJWOmPbnUz7+M741nAS5D9aQsaJBSYKny1vW1FOd9eZVUEYrVhH5Tpbb5UURDwWULEzk0OZb4ARKwp685RRhi+5uCmzKcTDCNTJX8YsY+nLbsEeIqZUwZ47asRa+PR+F9Tk+S5kEZdcMql05BzbjEwccH/DFcNn2bJajlyFSF8QjUce2CX+ZHZXbvf0Rh7i0u9fioKzKabv/utpbs4GEe4Guwk+28hVcPTV3S5ZafoNKSXmmEgAv8HTM5RwF4X2tOvHZP3zAOVzCin1MiBCnsn8AMw2QaoUPHE7Gg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=8hdwUDH+LOMuz2G4XNxJl8/mIOZLll89oCdGwJEamxk=;
 b=nzQx/moVUBUrbIoEy/f5PuyDclOsoa4wwU9EFwgwqQCNj7YQgsiEnyImNKWxqRnoECN8viWsUcRMzrapEGYYWNlHBqQRNhobR2WGX/Gbe1BLGS4+HRrL8+rtbjbwzSltbPwzy5hT34lxM/KhqbfNbmNAHKauezLZWyLLddCfC7gAA3SKhpGbdqYHE3Fh0SDRigOabAy5E7Gl9e7gGIyfFwteRo9xQq1HRvHmTJJkGggJi3YM3+jS+Xiadx/Ovh/ggNMEZYU8ZY9EX7bzUoyc8MajvDHjWXCZP7HgBq1ke2w6SRES5AD7H6mAD2hXx33h38jkoXLc7ehIdaLJuENZsw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=arm.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=8hdwUDH+LOMuz2G4XNxJl8/mIOZLll89oCdGwJEamxk=;
 b=rOP5BKv4ZX5sxV1uX8VN2ucmj+MOXzcIqnlP0aLVSo8OTmlQeq8RcX1VpLgn/iAfBoK5tZP7V29Ul0ty7TUsEhl6A7TbZM38QW5AY0pj9p6YnJcINZJySZmhVJKQV0Lue1DZGMFd8rU9fBJKX+CmE2adJoJxaPNFLEe+46+HERo=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Message-ID: <8108074a-f4a3-4134-bfcb-410fc73b371e@amd.com>
Date: Wed, 27 Mar 2024 09:27:01 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 11/11] xen/arm: List static shared memory regions as
 /memory nodes
To: Luca Fancellu 
CC: Xen-devel , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Volodymyr Babchuk 
References: <20240312130331.78418-1-luca.fancellu@arm.com>
 <20240312130331.78418-12-luca.fancellu@arm.com>
 <3a9e8323-9eb3-4c06-9ef1-e85c8bf2aefd@amd.com>
 
Content-Language: en-US
From: Michal Orzel 
In-Reply-To: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Received-SPF: None (SATLEXMB05.amd.com: michal.orzel@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN3PEPF0000B078:EE_|PH7PR12MB7019:EE_
X-MS-Office365-Filtering-Correlation-Id: 7aff7a80-81d8-45a7-1675-08dc4e37b0d6
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	FcaIhQC84sqIIRK8RxYNL1MENzVF26AuyfVJ5oPAen1s6MIhnV8SZmy2FwaAcI/bf29TW4GuDy03wPT+qE21qg7PpABqtSl0IA2sHheFTsvCoyilF/vK8uYYZ+czun0pBBrqRt1PD0BAz/yCqGCfzn2HnF/KhUV0tz6uDqIgJTy/agWQFkFvYNKpToXxRZ1aYOkKro2Sji/q/LmR6QUuq8JuEwwLg63gy5sBTCWCS3pEUfngn5tzYb1+o4cB3u5GtTgEL2SGHL8sVgZQ9DSPdiGUDWP4EKn9bvYxZYIlzlC/3CZBL+MEqvSoYl4pMHkxIThaoTwooO+iuCJr4s4jfqdLfcoixgx6t2Tv6HLWFBaXz8p/FbBIlp1HbRdXVVLnk0jzlg0XEqx9C4s3h5JIN248E/YDMLFfDz5QPSZNg+XNMA8gf1t8fxOwHgs33nsIVfJ8evI6K2JEtrXOcVawINlk+HDVNrfhC9NzENCDTp3CgJRkV2v7oWByaxwOIP0hmWCHKS5w5N6OlfPHs0D+9kt47LRfJjfAGFjtLRBhVgDSBZFFs52v2NzjJOkXvAbWFQi86fpYMHFp1CcF6sdVUByipKKaBScCdryvFC7ln2WnPoVwfU4zRZoqlYTtkaLKvpquVtMDEhzYE6GGqzCFQ9LXzLVcVaZUG1AgHT1/ZdTExFvpBugtxQEcIOTz9xEgeVdYQbBLMSu/wob4W/qKAkHxk+Hg5fgL28Dp3S7XjQdbEMAiZmlde+Vvc6BiFr63
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(1800799015)(376005)(36860700004)(82310400014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Mar 2024 08:27:07.6287
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 7aff7a80-81d8-45a7-1675-08dc4e37b0d6
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN3PEPF0000B078.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB7019

Hi Luca,

On 26/03/2024 15:19, Luca Fancellu wrote:
> 
> 
>> On 25 Mar 2024, at 08:58, Michal Orzel  wrote:
>>
>> Hi Luca,
>>
> 
> Hi Michal,
> 
>> On 12/03/2024 14:03, Luca Fancellu wrote:
>>>
>>>
>>> Currently Xen is not exporting the static shared memory regions
>>> to the device tree as /memory node, this commit is fixing this
>>> issue.
>> Looking at the implementation, you will always call make_shm_memory_node() twice. For the first
>> time, to create /memory node and for the second time to create entry under /reserved-memory. Also,
>> you will create a separate /memory node for every single shmem region instead of combining them
>> in a single /memory region like make_memory_node() would do. Can't we reuse this function for simplicity?
> 
> You mean using make_memory_node() to populate /reserved-memory and /memory? I feel they are very different
> In terms of properties to be created, so I don’t think we should create a make_memory_node() that does both.
> 
> Otherwise if you were suggesting to modify make_memory_node() only for what concerns the /memory nodes,
yes, this is what I meant

> it might be feasible, however there are some parts that need to be skipped with some flags (all the code accessing .type
> member), if I understand correctly you like this function because it doesn’t create one node for every bank, but it creates
> reg addresses instead, in that case I could modify the current make_shm_memory_node() to do the same.
My concern is that we will have 2 functions to create memory nodes instead of one that can be reused. I know the issue is with
.type member. If skipping results in a worse code, then I'm ok with make_shm_memory_node() used for 2 purposes (would it be possible
to create /memory and entry under /reserved in the same call to a function?).

> 
>>
>> Also, afaict it is not forbidden to specify shmem range (correct me if I'm wrong), where guest address will be
>> within with RAM allocated by Xen (e.g. GPA RAM range 0x40000000 - 0x60000000 and shmem is at 0x50000000). In this case,
>> you would create yet another /memory node that would result in overlap (i.e. more than one /memory node specifying the same range).
> 
> This is a good point I didn’t think about, yes currently the code is creating overlapping nodes in that case, wow so it means I
> need to compute the non overlapping regions and emit a /memory node then! :) ouch
> 
> Please let me know if I understood correctly your comments.
> 
> Cheers,
> Luca
> 
>>
>> ~Michal
> 

~Michal



From xen-devel-bounces@lists.xenproject.org Wed Mar 27 08:59:51 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 08:59:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698358.1089965 (Exim 4.92)
	(envelope-from )
	id 1rpP8L-0005NV-Mx; Wed, 27 Mar 2024 08:59:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698358.1089965; Wed, 27 Mar 2024 08:59:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpP8L-0005NO-K7; Wed, 27 Mar 2024 08:59:45 +0000
Received: by outflank-mailman (input) for mailman id 698358;
 Wed, 27 Mar 2024 08:59:44 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpP8K-0005NE-DF
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 08:59:44 +0000
Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com
 [2a00:1450:4864:20::336])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 599c9fc9-ec18-11ee-a1ef-f123f15fe8a2;
 Wed, 27 Mar 2024 09:59:42 +0100 (CET)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-41494c0405eso2033955e9.3
 for ; Wed, 27 Mar 2024 01:59:42 -0700 (PDT)
Received: from localhost ([85.31.135.62]) by smtp.gmail.com with ESMTPSA id
 r3-20020a05600c35c300b004147b824b08sm1491346wmq.7.2024.03.27.01.59.41
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 27 Mar 2024 01:59:41 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 599c9fc9-ec18-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1711529981; x=1712134781; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=F+bA0/25eIV49S9l0uuiMQg7gB/Ls5scBx+vVk8xCtQ=;
        b=CbCn75bBxcy4Mdc/vYacNv24FiHpuPSkvfqUdb7KJCux4FsS1dGqjtsC3x8YFYgT5a
         6CMNAc3fCyXvmnHxUVxZNU1VGpEGd9J5mxwMcn++Yc0bEDI6lYl8tv6UXUKLcPG6RBJn
         AfGHaYNL+d3sEkRueJO7r92PZ3AbtMjplwfw0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711529981; x=1712134781;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=F+bA0/25eIV49S9l0uuiMQg7gB/Ls5scBx+vVk8xCtQ=;
        b=fz6FNqILWr96IrMvbYMLfXUH4wVXSr/8RICDjWCMfzHcRl6qfTa/DRjSA+bgTWfm6T
         rkxj40RMx/xXWuH2ul48FielKIEYaCGJBKB04hHZStMUW0FKbzJNNlxrKdAjTrJHjGXN
         dB/Q7mXrXF1dXVQlv2MPxOhFFG2eplNYQxiQoOXQTQJgtHYBZKXVFFvq7z4wjEqT6KNv
         c37Y/H2IJtm0XuwcKgh+0SeT/N6wlTv5n1Fsf9eeBrctBmtXwNR+PMxAg1LuhjdTAIDx
         CQcA/HbnAq3fqoz127yTTplPjaLLnX+y/Z+k74tULXgoXz4AArY7x7Fa1ep9+hSMWgCz
         ifpw==
X-Forwarded-Encrypted: i=1; AJvYcCWASMfczliq0jgpFkNj0GxLo0kD9idPOYCGZRdbFub2Rx9w0yaIOTPG88SKFwDaNZbPl1ihkfNlmJqj7kd4QW46TbCMOi9pz5Gfhe0y9AE=
X-Gm-Message-State: AOJu0Yx5Bs7EX15S1Brv08ZQClHIWLaxMOvtUZDCaQjTXYkWP5db+12A
	34l/Bmhohfr7uGdhqMIIc/HsXYCkhUk8jKQ7NAfOGOH1UHmq2jwrv0BTO4FTTcU=
X-Google-Smtp-Source: AGHT+IEHPAopP+1Vft3DJ0tcDiGW9y8/DBB/1K00V9wUmdfLcN3YUHlSbdSM0eorHGm9uaBIgbi2QA==
X-Received: by 2002:a05:600c:4487:b0:414:729:1189 with SMTP id e7-20020a05600c448700b0041407291189mr3831476wmo.21.1711529981570;
        Wed, 27 Mar 2024 01:59:41 -0700 (PDT)
Date: Wed, 27 Mar 2024 09:59:40 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: Jason Andryuk ,
	Andrew Cooper ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v5 1/6] Revert "xen/x86: bzImage parse kernel_alignment"
Message-ID: 
References: <20240326213847.3944-1-jason.andryuk@amd.com>
 <20240326213847.3944-2-jason.andryuk@amd.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 

On Wed, Mar 27, 2024 at 08:22:41AM +0100, Jan Beulich wrote:
> On 26.03.2024 22:38, Jason Andryuk wrote:
> > A new ELF note will specify the alignment for a relocatable PVH kernel.
> > ELF notes are suitable for vmlinux and other ELF files, so this
> > Linux-specific bzImage parsing in unnecessary.
> > 
> > This reverts commit c44cac229067faeec8f49247d1cf281723ac2d40.
> > 
> > Signed-off-by: Jason Andryuk 
> 
> Since you keep re-sending this: In private discussion Roger has indicated
> that, like me, he too would prefer falling back to the ELF data, before
> falling back to the arch default (Roger, please correct me if I got it
> wrong). That would make it necessary that the change you're proposing to
> revert here is actually kept.

Sorry, was meaning to reply yesterday but Jason is very fast at
sending new version so I'm always one version behind.

IMO the order: ELF note, PHDR alignment, arch default should be the
preferred one.

> Or wait - what you're reverting is taking the alignment out of the
> bzImage header. I don't expect the BSDs to use that protocol; aiui that's
> entirely Linux-specific.

Yeah, I don't have strong opinions in keeping this, we already do
bzImage parsing, so we might as well attempt to fetch the alignment
from there if correct:

ELF note, bzImage kernel_alignment, ELF PHDR alignment, arch default

> I further meanwhile realized that consulting the ELF phdrs may also be
> ambiguous, as there may be more than one. I guess it would need to be the
> maximum of all of them then.

My suggestion (not sure if I mentioned this before) was to use the
alignment of the first LOAD PHDR, which is the one that defines the
value of the dest_base field used as the image load start address.

Using the maximum of all load PHDRs might be safer.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Mar 27 09:31:35 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 09:31:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698365.1089975 (Exim 4.92)
	(envelope-from )
	id 1rpPcy-0002MD-5q; Wed, 27 Mar 2024 09:31:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698365.1089975; Wed, 27 Mar 2024 09:31:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpPcy-0002M6-3D; Wed, 27 Mar 2024 09:31:24 +0000
Received: by outflank-mailman (input) for mailman id 698365;
 Wed, 27 Mar 2024 09:31:22 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpPcw-0002Ll-L2
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 09:31:22 +0000
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com
 [2a00:1450:4864:20::135])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c5577440-ec1c-11ee-a1ef-f123f15fe8a2;
 Wed, 27 Mar 2024 10:31:21 +0100 (CET)
Received: by mail-lf1-x135.google.com with SMTP id
 2adb3069b0e04-515a97846b5so3791908e87.2
 for ; Wed, 27 Mar 2024 02:31:20 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c5577440-ec1c-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1711531880; x=1712136680; darn=lists.xenproject.org;
        h=to:subject:message-id:date:from:mime-version:from:to:cc:subject
         :date:message-id:reply-to;
        bh=koxJKxoDPOt/Mr2zX1QIjQHPKfAETTJMiwi2l5XKzng=;
        b=eWO9xA1QPUsTTqKEqpx59ZCSxUXppRdX53TJBHbYcLM9Z9+bephPnS6vTajAN/MP7I
         P3ZC3VAFJYqdCCdnRezVguxz3Kps0D0iTdJPymULxbeMz1MXhAyw6VZHVgAsMtKnrIie
         t2zjgHLR66WBYjU2pD3ht164A2pYWIhfJn1RE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711531880; x=1712136680;
        h=to:subject:message-id:date:from:mime-version:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=koxJKxoDPOt/Mr2zX1QIjQHPKfAETTJMiwi2l5XKzng=;
        b=fVYlUMIxJYg8oanfOtJUrqqE+YqR9SKWFnbzX+QbSS3OjCqoJFJ9mQEuOZ4RKmfw4s
         DQAqcJ5Ko358byVgCC4hbTuHINcFKXcDP/igtvrEKNmlEMiH2m2T/QZaQMjiw8fo6P3/
         gU2j9zo0ShjLf1jaX+stdSwGX7jkiJvyIBzciF7ZlfLHhvRTYr+xEjI9+uiVGIHHpEpg
         oJC5pg72IapbBFHTsUPTzIHiKDf++2crZa0Lw+WXLESMPO4BSPhY261pHjlxoHtgdTX3
         1O/jR+arXZsisvPn+Kbt8Ie3VwDv7pl/7uFEDOKoDSrUL3tpnYHRe6V4y6A7xukZRFSz
         WfZw==
X-Gm-Message-State: AOJu0YwYbBngKljmF+x3ONPT8gP3GB/r4bExIgToa0SM/SyeB+Kv360n
	XeS+Iyhk3FvnKnGC/re5OVZksB8KeIKRNPXVlvDchWCExvhMEAj7WLxPLvAuOwu0/gFGgnoD625
	Nm6LwULNh42WT+L8WqJUILtiknndcD6TE58O1d35s1Awnj0B7uD9DSQ==
X-Google-Smtp-Source: AGHT+IGMTlNdvpN2NyBi2+ESVNeUV8/1H9Zc6V7OoCi5BOuPG3UHbaFFD3qNXWDbJfwqfZ2aiK1dJlA0bUiTdjj3bxA=
X-Received: by 2002:ac2:5b43:0:b0:513:c957:ea4d with SMTP id
 i3-20020ac25b43000000b00513c957ea4dmr459238lfp.43.1711531879990; Wed, 27 Mar
 2024 02:31:19 -0700 (PDT)
MIME-Version: 1.0
From: Kelly Choi 
Date: Wed, 27 Mar 2024 09:30:00 +0000
Message-ID: 
Subject: Xen Summit Early Bird Rates - Ends 31st March 2024!
To: xen-devel , xen-users@lists.xenproject.org, 
	xen-announce@lists.xenproject.org
Content-Type: multipart/alternative; boundary="000000000000bab4a00614a111d0"

--000000000000bab4a00614a111d0
Content-Type: text/plain; charset="UTF-8"

Hey everyone,

We've just announced our schedule for Xen Summit 2024 and can't wait to see
you all.

*Make sure to grab your early-rate tickets today, these end on 31st March
2024! *
Academics can also attend the event for free.

Tickets:
https://events.linuxfoundation.org/xen-project-summit/register/

Schedule:
https://events.linuxfoundation.org/xen-project-summit/program/schedule/

See you all there!

Many thanks,
Kelly Choi

Community Manager
Xen Project

--000000000000bab4a00614a111d0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hey everyone,

We've just anno=
unced our schedule for Xen Summit 2024 and can't wait to see you all.
Make sure to grab your early-rate tickets today=
,=C2=A0these end on 31st March 2024!=C2=A0
Academics can also=
 attend the event for free.=C2=A0



--000000000000bab4a00614a111d0--


From xen-devel-bounces@lists.xenproject.org Wed Mar 27 10:28:23 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 10:28:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698414.1090018 (Exim 4.92)
	(envelope-from )
	id 1rpQVv-0003VE-VY; Wed, 27 Mar 2024 10:28:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698414.1090018; Wed, 27 Mar 2024 10:28:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpQVv-0003V7-R8; Wed, 27 Mar 2024 10:28:11 +0000
Received: by outflank-mailman (input) for mailman id 698414;
 Wed, 27 Mar 2024 10:28:10 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpQVu-0003UG-MK
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 10:28:10 +0000
Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com
 [2a00:1450:4864:20::236])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b51c5643-ec24-11ee-afe3-a90da7624cb6;
 Wed, 27 Mar 2024 11:28:09 +0100 (CET)
Received: by mail-lj1-x236.google.com with SMTP id
 38308e7fff4ca-2d52e65d4a8so87187631fa.0
 for ; Wed, 27 Mar 2024 03:28:09 -0700 (PDT)
Received: from [192.168.206.239] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 y23-20020ac255b7000000b00513b3928e36sm1777010lfg.266.2024.03.27.03.28.07
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 27 Mar 2024 03:28:08 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b51c5643-ec24-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1711535289; x=1712140089; darn=lists.xenproject.org;
        h=mime-version:user-agent:content-transfer-encoding:references
         :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject
         :date:message-id:reply-to;
        bh=/n+opUoNJ9wZF7yNe9XfgYKWacCATGFVOU3SeuJLRPY=;
        b=Ji2gAxAMFaLNHevRTFn2FrL8hdrRlE0H9Urjoe9wDvtKnLiXyJRDfAeIBSGmB0YKk+
         ltsKs9yjrgkxrGmtmFBeka/IIQIpmwcmZtjZV4VB0IOMDllhCOZz7KFtP7TQqXVzoNf/
         7VeqhSf9oLU4LcPHlUtxlObX7CDqU0CQGbqjyC13eBGfI/zBgCiaFRDirD4VHIvR+CXE
         wdJY4EAImCsXx8sU9aJEGKWcrrY8e5WT2E4EQwMvELW4yw+OBjsEXSbrubKfx/u+cWGP
         /DlSgdSE4C3T6k2CeM/MjPuvPGYngnuUUM1EIT2XcX9h7uh9LtehIY2Pv6EFTJ3+gLLQ
         hI4g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711535289; x=1712140089;
        h=mime-version:user-agent:content-transfer-encoding:references
         :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=/n+opUoNJ9wZF7yNe9XfgYKWacCATGFVOU3SeuJLRPY=;
        b=XUT2ZJRbej4S2gc40wfVzcmg0hnIm4f8FPEPBlKB4+uL9WCs7rWZd7gB5pL3o6GPUH
         o2/BRz3ILMax2Kb33mNkB63dine+l/JWlZ6dX1sQiR+U/WkuP3ufmqyVX+iBh3hQCm+a
         wLQHi6o2klUcPww4cxEduyx2yReHi0pWU4KsxTXxYkvSeV9uCV1WZ0y3RkTK1gxfetra
         FI3kiHaRSAl+tP3bQB1X2nnCaZvwdZZPC45qPC+NpsD7xInPYqn1QYt0/kDdfJMurbmD
         SsGJJYHIQZiSHe0+Q+2Ge+ZU/qJshfnCu3roqlnX7NjONXTZMSv3mQo26aBW+2U8f7fD
         D1sA==
X-Forwarded-Encrypted: i=1; AJvYcCWkZBsiKFYkuFVDb+wgeb6uq30Ec/M1s+ZYlbn1G5fEbwk8PfFG7JyyjvLXU3l7pAabHu9PDzAfRSZ6nfpNnFE47EnGUwitDPPNPn6lXMU=
X-Gm-Message-State: AOJu0Yz5UWwrVPw+w8x/yU2XVSeanqIKTRsnxX8TpTdwxpp57fK1qXfS
	4Y6KTD7dPhlnnWXXdIVIERqk5rffYVt54B0RFpA0guvYw33qVePKimtl4cxzR0c=
X-Google-Smtp-Source: AGHT+IGKO7KCIyC8h7mBJ0zOngnpIfJZIs6YlC/x9l5kL+cginbq5I0dBl53iVrTNETYO1JQhA5ESQ==
X-Received: by 2002:a19:a40d:0:b0:513:cac8:743a with SMTP id q13-20020a19a40d000000b00513cac8743amr568521lfc.1.1711535288835;
        Wed, 27 Mar 2024 03:28:08 -0700 (PDT)
Message-ID: 
Subject: Re: [PATCH v6 10/20] xen/riscv: introduce atomic.h
From: Oleksii 
To: Jan Beulich 
Cc: Alistair Francis , Bob Eshleman
 , Connor Davis , Andrew
 Cooper , George Dunlap
 ,  Julien Grall , Stefano
 Stabellini , Wei Liu , 
 xen-devel@lists.xenproject.org
Date: Wed, 27 Mar 2024 11:28:07 +0100
In-Reply-To: <2bac4852-b5f1-4424-ac1a-29e76563ab2b@suse.com>
References: 
	 <22ee9c8cc62c76cfb799fed800636e7c8bf25a17.1710517542.git.oleksii.kurochko@gmail.com>
	 <78a86041-72e2-410f-b6a7-212656b0dba3@suse.com>
	 
	 <1a440fbf-f37c-41fe-b31c-0afe0fd77c8e@suse.com>
	 <38de6dd8e9555fe4b573f9c2134a618a60c224df.camel@gmail.com>
	 <2bac4852-b5f1-4424-ac1a-29e76563ab2b@suse.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.50.2 (3.50.2-1.fc39) 
MIME-Version: 1.0

On Wed, 2024-03-27 at 08:40 +0100, Jan Beulich wrote:
...

> > > > > > +/* This is required to provide a full barrier on success.
> > > > > > */
> > > > > > +static inline int atomic_add_unless(atomic_t *v, int a,
> > > > > > int u)
> > > > > > +{
> > > > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int prev, rc;
> > > > > > +
> > > > > > +=C2=A0=C2=A0=C2=A0 asm volatile (
> > > > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "0: lr.w=C2=A0=C2=
=A0=C2=A0=C2=A0 %[p],=C2=A0 %[c]\n"
> > > > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "=C2=A0=C2=A0 beq=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 %[p],=C2=A0 %[u], 1f\n"
> > > > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "=C2=A0=C2=A0 add=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 %[rc], %[p], %[a]\n"
> > > > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "=C2=A0=C2=A0 sc.w.=
rl=C2=A0 %[rc], %[rc], %[c]\n"
> > > > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "=C2=A0=C2=A0 bnez=
=C2=A0=C2=A0=C2=A0=C2=A0 %[rc], 0b\n"
> > > > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RISCV_FULL_BARRIER
> > > > >=20
> > > > > With this and no .aq on the load, why the .rl on the store?
> > > > It is something that LKMM requires [1].
> > > >=20
> > > > This is not fully clear to me what is so specific in LKMM, but
> > > > accoring
> > > > to the spec:
> > > > =C2=A0=C2=A0 Ordering Annotation Fence-based Equivalent
> > > > =C2=A0=C2=A0 l{b|h|w|d|r}.aq=C2=A0=C2=A0=C2=A0=C2=A0 l{b|h|w|d|r}; =
fence r,rw
> > > > =C2=A0=C2=A0 l{b|h|w|d|r}.aqrl=C2=A0=C2=A0 fence rw,rw; l{b|h|w|d|r=
}; fence r,rw
> > > > =C2=A0=C2=A0 s{b|h|w|d|c}.rl=C2=A0=C2=A0=C2=A0=C2=A0 fence rw,w; s{=
b|h|w|d|c}
> > > > =C2=A0=C2=A0 s{b|h|w|d|c}.aqrl=C2=A0=C2=A0 fence rw,w; s{b|h|w|d|c}
> > > > =C2=A0=C2=A0 amo.aq=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 amo; fence r,rw
> > > > =C2=A0=C2=A0 amo.rl=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 fence rw,w; amo
> > > > =C2=A0=C2=A0 amo.aqrl=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 fence rw,rw; amo; fence rw,rw
> > > > =C2=A0=C2=A0 Table 2.2: Mappings from .aq and/or .rl to fence-based
> > > > equivalents.
> > > > =C2=A0=C2=A0 An alternative mapping places a fence rw,rw after the
> > > > existing=20
> > > > =C2=A0=C2=A0 s{b|h|w|d|c} mapping rather than at the front of the
> > > > =C2=A0=C2=A0 l{b|h|w|d|r} mapping.
> > >=20
> > > I'm afraid I can't spot the specific case in this table. None of
> > > the
> > > stores in the right column have a .rl suffix.
> > Yes, it is expected.
> >=20
> > I am reading this table as (f.e.) amo.rl is an equivalent of
> > fence
> > rw,w; amo. (without .rl)=20
>=20
> In which case: How does quoting the table answer my original
> question?
Agree, it is starting to be confusing, so let me give an answer to your
question below.

>=20
> > > > =C2=A0=C2=A0 It is also safe to translate any .aq, .rl, or .aqrl
> > > > annotation
> > > > into
> > > > =C2=A0=C2=A0 the fence-based snippets of
> > > > =C2=A0=C2=A0 Table 2.2. These can also be used as a legal implement=
ation
> > > > of
> > > > =C2=A0=C2=A0 l{b|h|w|d} or s{b|h|w|d} pseu-
> > > > =C2=A0=C2=A0 doinstructions for as long as those instructions are n=
ot
> > > > added
> > > > to
> > > > =C2=A0=C2=A0 the ISA.
> > > >=20
> > > > So according to the spec, it should be:
> > > > =C2=A0sc.w ...
> > > > =C2=A0RISCV_FULL_BARRIER.
> > > >=20
> > > > Considering [1] and how this code looks before, it seems to me
> > > > that
> > > > it
> > > > is safe to use lr.w.aq/sc.w.rl here or an fence equivalent.
> > >=20
> > > Here you say "or". Then why dos the code use sc.?.rl _and_ a
> > > fence?
> > I confused this line with amo.aqrl, so based on the table 2.2
> > above
> > s{b|h|w|d|c}.aqrl is transformed to "fence rw,w; s{b|h|w|d|c}", but
> > Linux kernel decided to strengthen it with full barrier:
> > =C2=A0=C2=A0 -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 "0:\n\t"
> > =C2=A0=C2=A0 -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 "lr.w.aqrl=C2=A0 %[p],=C2=A0 %[c]\n\t"
> > =C2=A0=C2=A0 -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 "beq=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 %[p],=
=C2=A0 %[u], 1f\n\t"
> > =C2=A0=C2=A0 -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 "add=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 %[rc],=C2=A0=
 %[p], %[a]\n\t"
> > =C2=A0=C2=A0 -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 "sc.w.aqrl %[rc], %[rc], %[c]\n\t"
> > =C2=A0=C2=A0 -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 "bnez=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 %[rc], 0b\n\t"
> > =C2=A0=C2=A0 -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 "1:"
> > =C2=A0=C2=A0 +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 "0:=C2=A0=C2=A0=C2=A0=C2=A0 lr.w=C2=A0=C2=A0=C2=
=A0=C2=A0 %[p],=C2=A0 %[c]\n"
> > =C2=A0=C2=A0 +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 "=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 beq=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 %[p],=C2=A0 %[u], 1f\n"
> > =C2=A0=C2=A0 +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 "=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 add=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 %[rc], %[p], %[a]\n"
> > =C2=A0=C2=A0 +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 "=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sc.w.rl=
=C2=A0 %[rc], %[rc], %[c]\n"
> > =C2=A0=C2=A0 +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 "=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 bnez=C2=
=A0=C2=A0=C2=A0=C2=A0 %[rc], 0b\n"
> > =C2=A0=C2=A0 +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 "=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 fence=C2=
=A0=C2=A0=C2=A0 rw, rw\n"
> > =C2=A0=C2=A0 +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 "1:\n"
> > As they have the following issue:
> > =C2=A0=C2=A0 implementations of atomics such as atomic_cmpxchg() and
> > =C2=A0=C2=A0 atomic_add_unless() rely on LR/SC pairs,
> > =C2=A0=C2=A0 which do not give full-ordering with .aqrl; for example, c=
urrent
> > =C2=A0=C2=A0 implementations allow the "lr-sc-aqrl-pair-vs-full-barrier=
" test
> > =C2=A0=C2=A0 below to end up with the state indicated in the "exists" c=
lause.
>=20
> Is that really "current implementations", not "the abstract model"?
> If so, the use of an explicit fence would be more like a workaround
> (and would hence want commenting to that effect).
>=20
> In neither case can I see my original question answered: Why the .rl
> on the store when there is a full fence later?
The good explanation for that was provided in the commit addressing a
similar issue for ARM64 [
https://patchwork.kernel.org/project/linux-arm-kernel/patch/1391516953-1454=
1-1-git-send-email-will.deacon@arm.com/
].
The same holds true for RISC-V since ARM also employs WMO.

I would also like to mention another point, as I indicated in another
email thread
[=C2=A0https://lists.xen.org/archives/html/xen-devel/2024-03/msg01582.html =
]
, that now this fence can be omitted and .aqrl can be used instead.

This was confirmed by Dan (the author of the RVWMO spec)
[https://lore.kernel.org/linux-riscv/41e01514-74ca-84f2-f5cc-2645c444fd8e@n=
vidia.com/
]

I hope this addresses your original question. Does it?

~ Oleksii



From xen-devel-bounces@lists.xenproject.org Wed Mar 27 10:40:41 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 10:40:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698422.1090028 (Exim 4.92)
	(envelope-from )
	id 1rpQhr-0006wn-02; Wed, 27 Mar 2024 10:40:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698422.1090028; Wed, 27 Mar 2024 10:40:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpQhq-0006wg-T4; Wed, 27 Mar 2024 10:40:30 +0000
Received: by outflank-mailman (input) for mailman id 698422;
 Wed, 27 Mar 2024 10:40:29 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpQhp-0006wV-5e
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 10:40:29 +0000
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com
 [2a00:1450:4864:20::52c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6cb8313f-ec26-11ee-afe3-a90da7624cb6;
 Wed, 27 Mar 2024 11:40:27 +0100 (CET)
Received: by mail-ed1-x52c.google.com with SMTP id
 4fb4d7f45d1cf-56bf6591865so6273374a12.0
 for ; Wed, 27 Mar 2024 03:40:27 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ef7-20020a17090697c700b00a474df4cda5sm4242694ejb.167.2024.03.27.03.40.26
 for 
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 27 Mar 2024 03:40:26 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6cb8313f-ec26-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711536027; x=1712140827; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=if6iQd/kKBoB2STDWh3Tss0Hn/p9pyD81u4TyzonMO8=;
        b=NYdMjDQZHx397tvDPJfGVjUNvjmZYKPMEJZL8NxhCvk1sonHDtJfFpR71+auzdG8bV
         KnmMbMY64x0QxOn1T1pyO207lYlKVG8/e/NMLoMIKLdooCuLNWAHjB+69JToE5zUJyGU
         W5e1+j/YXT0UBNw1fMxLQ32GgPtRgLkoxEWIY+Ymb6jE6+UEOE2pd/2VUBI/WZ85EHTI
         5c+Qt5fjhP6+zZoiZQ5cFoJO/BWAyyh9Or0buqxNeurrvt/BgytobJ0VUKYVZ8l4eKkE
         11VQF3ed9MB1nds/hDbDj/Qaqw/MigLVib0gtq6+sOPXqCWayM3oKt69KkuVZ9o07rFo
         GmQg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711536027; x=1712140827;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=if6iQd/kKBoB2STDWh3Tss0Hn/p9pyD81u4TyzonMO8=;
        b=Yt6tWeG9Z6UINauyLYn6iHtvFXeYPoz2kS5t0GfYFJhxBMh1IijKkiXkajt49h2Nc1
         xA+R0/Yxqq2UbfODpsi7JPrSFDONN8gKxT+ZW3qQ2jWmxHOADLuyF9AhbMXQJ81fc7Uw
         IA5MCO13DzIALgANwjj066zxn718VAljnV+05uGJA/ltH+1LD0wiY4YK+nEwrB8VGLCa
         rY75AR3nE+tCCS7EJzBea4HJjjU42DZ4ctQtYvdi6YUsB+nrlyX0TcymeaFJDtpXjSPU
         WOkxPnOlpECpVl/aHGmEbXnXJ0i5B/DS92DRcYc+9bH6TKW7oG+EqrrSYPwd3t19r2nS
         YuQg==
X-Gm-Message-State: AOJu0Yw2M3TDJ7LXdPnvkDdiZgphf+SK32gZn9FXVjA4OYJVleHm5zCX
	4US8ZscfvMxEJpkYRds4xnOnumjirLGz+x5uH49KFLz3IO/TXxa2XrL8wjs4ye3Du3rHa4NlYLM
	=
X-Google-Smtp-Source: AGHT+IHoSJY5U0PsIBOpYk5UTmesCQXxL0URNDznJJdwPFEJMNpa0IA33NRLoMONSOp9j4sJ/VGjCg==
X-Received: by 2002:a17:906:5645:b0:a47:4a75:649 with SMTP id v5-20020a170906564500b00a474a750649mr2592490ejr.13.1711536026784;
        Wed, 27 Mar 2024 03:40:26 -0700 (PDT)
Message-ID: <24d80c55-1669-4eaa-a805-7e950205dc26@suse.com>
Date: Wed, 27 Mar 2024 11:40:25 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: xen | Failed pipeline for staging | e3883336
Content-Language: en-US
To: "xen-devel@lists.xenproject.org" 
References: <6603edcb4d254_2c5c1671823573e@gitlab-sidekiq-catchall-v2-995bd4ccb-hkbtp.mail>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <6603edcb4d254_2c5c1671823573e@gitlab-sidekiq-catchall-v2-995bd4ccb-hkbtp.mail>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 27.03.2024 10:58, GitLab wrote:
> 
> 
> Pipeline #1229415063 has failed!
> 
> Project: xen ( https://gitlab.com/xen-project/hardware/xen )
> Branch: staging ( https://gitlab.com/xen-project/hardware/xen/-/commits/staging )
> 
> Commit: e3883336 ( https://gitlab.com/xen-project/hardware/xen/-/commit/e3883336bb5abba2ec2231618f5b64f61b099b1e )
> Commit Message: xen/efi: efibind: address violations of MISRA C...
> Commit Author: Nicola Vetrini
> Committed by: Jan Beulich ( https://gitlab.com/jbeulich )
> 
> 
> Pipeline #1229415063 ( https://gitlab.com/xen-project/hardware/xen/-/pipelines/1229415063 ) triggered by Jan Beulich ( https://gitlab.com/jbeulich )
> had 1 failed job.
> 
> Job #6487283739 ( https://gitlab.com/xen-project/hardware/xen/-/jobs/6487283739/raw )
> 
> Stage: test
> Name: qemu-alpine-x86_64-gcc

qemu-system-x86_64: terminating on signal 15 from pid 52 (timeout)

I have to admit I have no idea what this is supposed to be telling me.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Mar 27 11:07:36 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 11:07:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698426.1090037 (Exim 4.92)
	(envelope-from )
	id 1rpR7z-0002b0-2p; Wed, 27 Mar 2024 11:07:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698426.1090037; Wed, 27 Mar 2024 11:07:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpR7z-0002at-0L; Wed, 27 Mar 2024 11:07:31 +0000
Received: by outflank-mailman (input) for mailman id 698426;
 Wed, 27 Mar 2024 11:07:29 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpR7x-0002al-El
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 11:07:29 +0000
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com
 [2a00:1450:4864:20::634])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 32c5c9b0-ec2a-11ee-afe3-a90da7624cb6;
 Wed, 27 Mar 2024 12:07:28 +0100 (CET)
Received: by mail-ej1-x634.google.com with SMTP id
 a640c23a62f3a-a46d0a8399aso126173266b.1
 for ; Wed, 27 Mar 2024 04:07:28 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a8-20020a170906670800b00a4710e7817esm5307365ejp.135.2024.03.27.04.07.26
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 27 Mar 2024 04:07:27 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 32c5c9b0-ec2a-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711537647; x=1712142447; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=zegOue7UV3ZNNNDbafI17QLirkPrTLHYo8D7OEQ1Rjo=;
        b=TjftFTi9q9UxiVOwrvOkPjnHNShjHakpgHvUqhVYOScoNvbfxlDBiILI7IQ2bX3eSx
         dZQSYgZc8WlfpGjXMS/MLjPmwCIpeHB2KNhxJY2AmbmSsxBS6L6HnIcuYOTjngz2ljMc
         aHWLDCBwIHBZqkQX2Zw+ZQ7HtZAuFnRX4bqc383vZWAUxEH6L0WVjHKJm9FecVm69hRY
         rhco4VHq4qb+hdX8qjrLGLuwxu2HP0PdV/JwuBVOEzazBygIZI+Sdd+nS9wemO2/o4f/
         0vd4SWTimY95P485SfxAuTXQE10W+Kte0HSidFpi2kY6Of9g1MJqLQIc411Bdb3ew4Yy
         ZNTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711537647; x=1712142447;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=zegOue7UV3ZNNNDbafI17QLirkPrTLHYo8D7OEQ1Rjo=;
        b=bumjVGJ3sR/xUwNiwV8TW9hyNkYziqHSLny6Q3CK0UdGbDkQzYFiZbMDB0X+LvKeKJ
         a8KhroQOthtQGU9ocFpECjK2fH1H+8n6T7CBx1kibDJ7e4RxMlFGgRkgRCbDQoFtTLqB
         BbM2WEijVXIeA0P5Jvl3HECXM51flXhoWuUgV0WN/jnLZ1MnsxJxsyd+Ucb95BCXTspw
         qEvV5HWnExo8+MAplVNU6b8NQRUpLlzs2dExLk6gfCIh5b7KRVRlii2c/YfY1VYhd9qV
         9rbvV65b4RmnOlHtprsKBp9vC+E0Nnsw6UlwVRmP0DXseJ/vcRnrzy10asS5AmUAvWMl
         0Y9A==
X-Forwarded-Encrypted: i=1; AJvYcCVulvC6B/nOoL6eLU8w9agVao18FwRRdqNNg+lXUiqticeJTR2aOnLhz4P3SFNACU1CJkiIEp202PZ0y182j8pT5fv5FU/ThU49bQMpYQg=
X-Gm-Message-State: AOJu0Yxz5XBtBtUUEZEaIHIvm/W+RGwGn8CSL/UDGJ6P8lhmwTtkTE9N
	PFvufv+EZPx96VyX6liziAh+uL3p2h6SujG+McUZItlJv+CQ85rcyS16P0g5xg==
X-Google-Smtp-Source: AGHT+IEd4cMFvWL6QBn5vugx47Qsa8iMGIOr3e6cBPvykYS98nkR+0xEekpXuZfZZmng6TQorwGuVw==
X-Received: by 2002:a17:906:b4a:b0:a4e:4d9:7ce4 with SMTP id v10-20020a1709060b4a00b00a4e04d97ce4mr1228500ejg.30.1711537647532;
        Wed, 27 Mar 2024 04:07:27 -0700 (PDT)
Message-ID: <49cc57f4-f246-4433-841e-b9d1c58da1f2@suse.com>
Date: Wed, 27 Mar 2024 12:07:26 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 10/20] xen/riscv: introduce atomic.h
Content-Language: en-US
To: Oleksii 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 xen-devel@lists.xenproject.org
References: 
 <22ee9c8cc62c76cfb799fed800636e7c8bf25a17.1710517542.git.oleksii.kurochko@gmail.com>
 <78a86041-72e2-410f-b6a7-212656b0dba3@suse.com>
 
 <1a440fbf-f37c-41fe-b31c-0afe0fd77c8e@suse.com>
 <38de6dd8e9555fe4b573f9c2134a618a60c224df.camel@gmail.com>
 <2bac4852-b5f1-4424-ac1a-29e76563ab2b@suse.com>
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 27.03.2024 11:28, Oleksii wrote:
> On Wed, 2024-03-27 at 08:40 +0100, Jan Beulich wrote:
> ...
> 
>>>>>>> +/* This is required to provide a full barrier on success.
>>>>>>> */
>>>>>>> +static inline int atomic_add_unless(atomic_t *v, int a,
>>>>>>> int u)
>>>>>>> +{
>>>>>>> +       int prev, rc;
>>>>>>> +
>>>>>>> +    asm volatile (
>>>>>>> +        "0: lr.w     %[p],  %[c]\n"
>>>>>>> +        "   beq      %[p],  %[u], 1f\n"
>>>>>>> +        "   add      %[rc], %[p], %[a]\n"
>>>>>>> +        "   sc.w.rl  %[rc], %[rc], %[c]\n"
>>>>>>> +        "   bnez     %[rc], 0b\n"
>>>>>>> +        RISCV_FULL_BARRIER
>>>>>>
>>>>>> With this and no .aq on the load, why the .rl on the store?
>>>>> It is something that LKMM requires [1].
>>>>>
>>>>> This is not fully clear to me what is so specific in LKMM, but
>>>>> accoring
>>>>> to the spec:
>>>>>    Ordering Annotation Fence-based Equivalent
>>>>>    l{b|h|w|d|r}.aq     l{b|h|w|d|r}; fence r,rw
>>>>>    l{b|h|w|d|r}.aqrl   fence rw,rw; l{b|h|w|d|r}; fence r,rw
>>>>>    s{b|h|w|d|c}.rl     fence rw,w; s{b|h|w|d|c}
>>>>>    s{b|h|w|d|c}.aqrl   fence rw,w; s{b|h|w|d|c}
>>>>>    amo.aq          amo; fence r,rw
>>>>>    amo.rl          fence rw,w; amo
>>>>>    amo.aqrl        fence rw,rw; amo; fence rw,rw
>>>>>    Table 2.2: Mappings from .aq and/or .rl to fence-based
>>>>> equivalents.
>>>>>    An alternative mapping places a fence rw,rw after the
>>>>> existing 
>>>>>    s{b|h|w|d|c} mapping rather than at the front of the
>>>>>    l{b|h|w|d|r} mapping.
>>>>
>>>> I'm afraid I can't spot the specific case in this table. None of
>>>> the
>>>> stores in the right column have a .rl suffix.
>>> Yes, it is expected.
>>>
>>> I am reading this table as (f.e.) amo.rl is an equivalent of
>>> fence
>>> rw,w; amo. (without .rl) 
>>
>> In which case: How does quoting the table answer my original
>> question?
> Agree, it is starting to be confusing, so let me give an answer to your
> question below.
> 
>>
>>>>>    It is also safe to translate any .aq, .rl, or .aqrl
>>>>> annotation
>>>>> into
>>>>>    the fence-based snippets of
>>>>>    Table 2.2. These can also be used as a legal implementation
>>>>> of
>>>>>    l{b|h|w|d} or s{b|h|w|d} pseu-
>>>>>    doinstructions for as long as those instructions are not
>>>>> added
>>>>> to
>>>>>    the ISA.
>>>>>
>>>>> So according to the spec, it should be:
>>>>>  sc.w ...
>>>>>  RISCV_FULL_BARRIER.
>>>>>
>>>>> Considering [1] and how this code looks before, it seems to me
>>>>> that
>>>>> it
>>>>> is safe to use lr.w.aq/sc.w.rl here or an fence equivalent.
>>>>
>>>> Here you say "or". Then why dos the code use sc.?.rl _and_ a
>>>> fence?
>>> I confused this line with amo.aqrl, so based on the table 2.2
>>> above
>>> s{b|h|w|d|c}.aqrl is transformed to "fence rw,w; s{b|h|w|d|c}", but
>>> Linux kernel decided to strengthen it with full barrier:
>>>    -              "0:\n\t"
>>>    -              "lr.w.aqrl  %[p],  %[c]\n\t"
>>>    -              "beq        %[p],  %[u], 1f\n\t"
>>>    -              "add       %[rc],  %[p], %[a]\n\t"
>>>    -              "sc.w.aqrl %[rc], %[rc], %[c]\n\t"
>>>    -              "bnez      %[rc], 0b\n\t"
>>>    -              "1:"
>>>    +               "0:     lr.w     %[p],  %[c]\n"
>>>    +               "       beq      %[p],  %[u], 1f\n"
>>>    +               "       add      %[rc], %[p], %[a]\n"
>>>    +               "       sc.w.rl  %[rc], %[rc], %[c]\n"
>>>    +               "       bnez     %[rc], 0b\n"
>>>    +               "       fence    rw, rw\n"
>>>    +               "1:\n"
>>> As they have the following issue:
>>>    implementations of atomics such as atomic_cmpxchg() and
>>>    atomic_add_unless() rely on LR/SC pairs,
>>>    which do not give full-ordering with .aqrl; for example, current
>>>    implementations allow the "lr-sc-aqrl-pair-vs-full-barrier" test
>>>    below to end up with the state indicated in the "exists" clause.
>>
>> Is that really "current implementations", not "the abstract model"?
>> If so, the use of an explicit fence would be more like a workaround
>> (and would hence want commenting to that effect).
>>
>> In neither case can I see my original question answered: Why the .rl
>> on the store when there is a full fence later?
> The good explanation for that was provided in the commit addressing a
> similar issue for ARM64 [
> https://patchwork.kernel.org/project/linux-arm-kernel/patch/1391516953-14541-1-git-send-email-will.deacon@arm.com/
> ].
> The same holds true for RISC-V since ARM also employs WMO.
> 
> I would also like to mention another point, as I indicated in another
> email thread
> [ https://lists.xen.org/archives/html/xen-devel/2024-03/msg01582.html ]
> , that now this fence can be omitted and .aqrl can be used instead.
> 
> This was confirmed by Dan (the author of the RVWMO spec)
> [https://lore.kernel.org/linux-riscv/41e01514-74ca-84f2-f5cc-2645c444fd8e@nvidia.com/
> ]
> 
> I hope this addresses your original question. Does it?

I think it does, thanks. Some of this will need putting in at least the
patch description, if not a code comment.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Mar 27 11:11:14 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 11:11:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698429.1090048 (Exim 4.92)
	(envelope-from )
	id 1rpRBZ-0004aX-N4; Wed, 27 Mar 2024 11:11:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698429.1090048; Wed, 27 Mar 2024 11:11:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpRBZ-0004aQ-KK; Wed, 27 Mar 2024 11:11:13 +0000
Received: by outflank-mailman (input) for mailman id 698429;
 Wed, 27 Mar 2024 11:11:12 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpRBY-0004aK-15
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 11:11:12 +0000
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com
 [2a00:1450:4864:20::52e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b78d5e94-ec2a-11ee-afe3-a90da7624cb6;
 Wed, 27 Mar 2024 12:11:10 +0100 (CET)
Received: by mail-ed1-x52e.google.com with SMTP id
 4fb4d7f45d1cf-56845954ffeso9343286a12.2
 for ; Wed, 27 Mar 2024 04:11:10 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b78d5e94-ec2a-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1711537870; x=1712142670; darn=lists.xenproject.org;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=tB1JBTc3Sa/3UHgZN/w40rgh8Kmgpaad1HGpMFu+FJs=;
        b=WlX6nwjBhaM5tGRaNQt30AhOnpnsDwPEdt+CufG3IW5HnzHYSiJuB4OxNzF8Yg7enN
         WaZG5RfTK21ufhjGBaVFXq806arK0kbQxbKWfvRtrogGbavHxwrOE1qUCSO0YWyX6HXt
         5kcVmkX2KS9JnIRcLuZP4s6vClnp1woEogPn8jA2NtWYY1H9Uvwocf7oPYRHN0HW7g5q
         qs7PQMvIBU9GScRBC6TWv/74Bf5NoQFFlewchVU2hr2PxIS3Ge+mlCeM7oAYHzWn5na4
         HwIp46zFL1AgIjbj3OEwxHS3ueNjByKDrIuQe72vWfP3/CfKBH8DSPcBS5btd4oc+/vy
         NrGw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711537870; x=1712142670;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=tB1JBTc3Sa/3UHgZN/w40rgh8Kmgpaad1HGpMFu+FJs=;
        b=a1CoWElDNs0xtDhDe3UZ6L5OJfBGJqJA73iX374fDDmN82f66fZGrzX7Nr4BvZtAMR
         D80f9GhEz4L8CcASWjW6J4BylhgK/BDyGao/xR1aWChYt62HQTLjzh4+wy8RotYU+uyV
         VzHffINfh0dZfZTWj1TQhXH0bm2FaQRzow0XnfP+1L6aqnUWoD4F7TbxU2jKbcHoiuJJ
         bYvDBJXkPXtG0cBJux3HB1uhUuvtAQR99dAZ3tW1V3H9RxxLQ7gPfH845zE/GaseiTBI
         0G5SZXXx71oxfWu+tLhBz+YbYSCZ/H1qci6Js6oJH/zgqQb4d0fkYaaJAjVsYCeZu686
         nKGg==
X-Forwarded-Encrypted: i=1; AJvYcCVZvA68d9oL2x4eaNzoByhpho4gnI0rlxqvo6LL1uchWOls3ykhjS+lwZwvzcs/mLEDmqgS1U7wKemGBFwcuugUyTzdcFwRmTWXTvf3Cd4=
X-Gm-Message-State: AOJu0YxohhoemS5mgBrM7hAG8Rle5mR22fL8xELJmt+65Lwk5R9PMcEQ
	ql1fCdt4EGaYKIjywlpZyMSh8aRZm4Ukc3WqZfTGW5xK7oIOrUvAFDnExsQ3TJSr1Q8R2fxtA12
	1JHHCeNqqgD6YqnGaX3e+wvLZSV2W/+r+nGELiA==
X-Google-Smtp-Source: AGHT+IHYXAz9RQpwNPdkU6z67nlRMkkEJWhlpnf/XShoq8md1Lljnx4UZkFFjzvOGjhnxdLRScB4t5n/Fmu5HLkkhwQ=
X-Received: by 2002:a17:906:338f:b0:a49:182d:f121 with SMTP id
 v15-20020a170906338f00b00a49182df121mr503555eja.74.1711537870391; Wed, 27 Mar
 2024 04:11:10 -0700 (PDT)
MIME-Version: 1.0
References: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
 <20240315105902.160047-9-carlo.nonato@minervasys.tech> <3f615066-a792-493f-ba33-7667a6557c23@xen.org>
 <9e0f7ff3-5457-41e4-a1e4-bf75804fb900@xen.org> <255be735-f9fe-4e39-a24e-2f6aff91acc5@suse.com>
 
 <3427132d-9458-4447-b667-d2ef3c1f0569@suse.com> 
  
In-Reply-To: 
From: Carlo Nonato 
Date: Wed, 27 Mar 2024 12:10:59 +0100
Message-ID: 
Subject: Re: [PATCH v7 08/14] xen/page_alloc: introduce preserved page flags macro
To: Julien Grall , Jan Beulich 
Cc: Andrew Cooper , George Dunlap , 
	Stefano Stabellini , Wei Liu , 
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
	xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"

Hi guys,

> Question is: How would you justify such a change? IOW I'm not convinced
> (yet) this wants doing there.

You mean in this series?

> Looking at the code, the flag is originally set in
> alloc_domheap_pages(). So I guess it would make sense to do it in
> free_domheap_pages().

We don't hold the heap_lock there. Is it safe to change count_info without it?

Thanks.

> For PGC_static, I don't think we can reach free_domheap_pages() with the
> flag set (the pages should live in a separate pool). So I believe there
> is nothing to do for them.
>
> Cheers,
>
> --
> Julien Grall


From xen-devel-bounces@lists.xenproject.org Wed Mar 27 11:15:25 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 11:15:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698431.1090058 (Exim 4.92)
	(envelope-from )
	id 1rpRFZ-0005Cf-5g; Wed, 27 Mar 2024 11:15:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698431.1090058; Wed, 27 Mar 2024 11:15:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpRFZ-0005CY-2i; Wed, 27 Mar 2024 11:15:21 +0000
Received: by outflank-mailman (input) for mailman id 698431;
 Wed, 27 Mar 2024 11:15:20 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpRFY-0005CS-8d
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 11:15:20 +0000
Received: from mail-oo1-xc2d.google.com (mail-oo1-xc2d.google.com
 [2607:f8b0:4864:20::c2d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4aabbce6-ec2b-11ee-a1ef-f123f15fe8a2;
 Wed, 27 Mar 2024 12:15:18 +0100 (CET)
Received: by mail-oo1-xc2d.google.com with SMTP id
 006d021491bc7-5a4f9f94e77so3735689eaf.3
 for ; Wed, 27 Mar 2024 04:15:18 -0700 (PDT)
Received: from [10.80.67.139] (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 g15-20020ac870cf000000b0042f0008b8b7sm4684413qtp.35.2024.03.27.04.15.15
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 27 Mar 2024 04:15:16 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4aabbce6-ec2b-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1711538117; x=1712142917; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:to:subject:user-agent:mime-version:date
         :message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Yy+MmpaP4f4rRok/rZVfnYWJYxNaoshHSELahBIh2/M=;
        b=f9kYouQivNToDRNBorhQLuSiAs0edVBrDfkB5zvmLa0M1zt/iy/blHOPEfdBVKAaV3
         s1MzkKB+AKv0eC+IUppfIEZHU5JoEpV8IjnL+p4lr/xwjfjquEXwXzQZhpTkg3Utb7Qa
         +I8IBYhUWVTAG/itUP6D+I3AXWUbGIZ3T1BoM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711538117; x=1712142917;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:to:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=Yy+MmpaP4f4rRok/rZVfnYWJYxNaoshHSELahBIh2/M=;
        b=LIs4bbzCJsv+Tqg5aE1U8++5B8rxpNOwIb9PgdHTX9oifl2qMgC8LJJLamLW0KRYYR
         AhFfDSeX63DZEOCSoJgRW7FpoKC+UDDIqOdknN/baGJYuYb53X2epIeuP22mGZ0e+mIC
         /jotMQ6TZL55K0uiMgOk9WEemaU9vc4dPk4GJ4ORXdE4uclgnlfQl/Pf8LBGRbFpNU8T
         I7j5QvysFYa74fmB1rWLk6CqGZpmVm0jvW968QnDI9+kaLEmM8Ey9QIdrOh4U1Ms9y8m
         CKiqppFAjeSfvCbXNir34W3LKZeHBFvB7B80lYUgzHZ/ilLWlSd80AGpCr3Qsjf5PmEB
         jxVw==
X-Forwarded-Encrypted: i=1; AJvYcCXbHlI5cSCYAjuKDiCi2qavpHQfHUP3Q9tCsYodr8CfOLS/6eBxtQEvD20noUQmES3kTGv4el/R25WxmvhCNktPBCMcgz5vt19JRV1wtw0=
X-Gm-Message-State: AOJu0YyDhDjMX8EvlGbjRcOMadQTgdU3YlPCcmAS+ZOgykL+DVkvgijD
	HEO6R4BEbHT57/zhvhrZBmCnuxFr8eA2KbSvrGj/6uQVQLXFQSS/IAIvS6xvwAo=
X-Google-Smtp-Source: AGHT+IGtkgIDwBjmaOnm0pNYIORBNIDg2UZHWZVxJjcWe68+QcgdeSCoydQGc2TGgtY0D1HRTkKuBA==
X-Received: by 2002:a4a:ee97:0:b0:5a5:25b9:dec5 with SMTP id dk23-20020a4aee97000000b005a525b9dec5mr780346oob.2.1711538117006;
        Wed, 27 Mar 2024 04:15:17 -0700 (PDT)
Message-ID: <83c124e5-50c9-4bbe-95d1-3d83b3b87ff2@citrix.com>
Date: Wed, 27 Mar 2024 11:15:14 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: xen | Failed pipeline for staging | e3883336
To: Jan Beulich ,
 "xen-devel@lists.xenproject.org" 
References: <6603edcb4d254_2c5c1671823573e@gitlab-sidekiq-catchall-v2-995bd4ccb-hkbtp.mail>
 <24d80c55-1669-4eaa-a805-7e950205dc26@suse.com>
Content-Language: en-GB
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <24d80c55-1669-4eaa-a805-7e950205dc26@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 27/03/2024 10:40 am, Jan Beulich wrote:
> On 27.03.2024 10:58, GitLab wrote:
>>
>> Pipeline #1229415063 has failed!
>>
>> Project: xen ( https://gitlab.com/xen-project/hardware/xen )
>> Branch: staging ( https://gitlab.com/xen-project/hardware/xen/-/commits/staging )
>>
>> Commit: e3883336 ( https://gitlab.com/xen-project/hardware/xen/-/commit/e3883336bb5abba2ec2231618f5b64f61b099b1e )
>> Commit Message: xen/efi: efibind: address violations of MISRA C...
>> Commit Author: Nicola Vetrini
>> Committed by: Jan Beulich ( https://gitlab.com/jbeulich )
>>
>>
>> Pipeline #1229415063 ( https://gitlab.com/xen-project/hardware/xen/-/pipelines/1229415063 ) triggered by Jan Beulich ( https://gitlab.com/jbeulich )
>> had 1 failed job.
>>
>> Job #6487283739 ( https://gitlab.com/xen-project/hardware/xen/-/jobs/6487283739/raw )
>>
>> Stage: test
>> Name: qemu-alpine-x86_64-gcc
> qemu-system-x86_64: terminating on signal 15 from pid 52 (timeout)
>
> I have to admit I have no idea what this is supposed to be telling me.

In these smoke test, Qemu is run with a timeout in case things hang/crash.

This is saying Qemu running Xen+Dom0 didn't appear to get to the login
prompt within the timeout that the test specifies.

As to why, that's less clear.  It appears that it was making progress,
just slowly.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Mar 27 11:27:58 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 11:27:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698436.1090067 (Exim 4.92)
	(envelope-from )
	id 1rpRRe-0007OG-6N; Wed, 27 Mar 2024 11:27:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698436.1090067; Wed, 27 Mar 2024 11:27:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpRRe-0007O9-3r; Wed, 27 Mar 2024 11:27:50 +0000
Received: by outflank-mailman (input) for mailman id 698436;
 Wed, 27 Mar 2024 11:27:49 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpRRc-0007O3-VB
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 11:27:48 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0931044f-ec2d-11ee-afe3-a90da7624cb6;
 Wed, 27 Mar 2024 12:27:47 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 4B20161511;
 Wed, 27 Mar 2024 11:27:46 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 350A4C433C7;
 Wed, 27 Mar 2024 11:27:44 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0931044f-ec2d-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1711538866;
	bh=oaApo/srU9FnnVLasNCPU6Vc3zmFm7lgY/ipcvsqNPY=;
	h=Date:Subject:To:Cc:References:From:In-Reply-To:From;
	b=H4E0GlH9HUEweYrzsTAO2HPHRXXGBEpZs6yN6KVA3hT8kwEw+Ubf+Ljq5UQJPX37Y
	 FlPwaJVTKU2NW1xFHlwVRbskKd5mGgy2icPiOAZ+1U1kUuUAh8ZSFYC9y4+pIC+dU1
	 Ym9Xukbk8XELkNE78cJicLOiYBCc5oZEBrhtmx8Iaswogyd2wMEnssPxjMEPzm5c/h
	 2dKu5vngwLbAW+CqR6W1XdjJjyZgqkGdVfIO4ASqGzzPWgivqliMmaBOg3yx9dNvR6
	 AhQY2/Sq3ce2spg/yt0GB8rlJPMlw3X6bkgHhhKYMkvr5hjZ1J+UMNYdwjbxbNhkdB
	 L7itUDvOgcGWw==
Message-ID: 
Date: Wed, 27 Mar 2024 12:27:42 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Xen NIC driver have page_pool memory leaks
To: paul@xen.org, Arthur Borsboom ,
 Ilias Apalodimas 
Cc: Netdev , Wei Liu ,
 "xen-devel@lists.xenproject.org" ,
 kda@linux-powerpc.org
References: 
 <1cde0059-d319-4a4f-a68d-3b3ffeb3da20@kernel.org>
 <857282f5-5df6-4ed7-b17e-92aae0cf484a@xen.org>
Content-Language: en-US
From: Jesper Dangaard Brouer 
In-Reply-To: <857282f5-5df6-4ed7-b17e-92aae0cf484a@xen.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit



On 25/03/2024 13.33, Paul Durrant wrote:
> On 25/03/2024 12:21, Jesper Dangaard Brouer wrote:
>> Hi Arthur,
>>
>> (Answer inlined below, which is custom on this mailing list)
>>
>> On 23/03/2024 14.23, Arthur Borsboom wrote:
>>> Hi Jesper,
>>>
>>> After a recent kernel upgrade 6.7.6 > 6.8.1 all my Xen guests on Arch
>>> Linux are dumping kernel traces.
>>> It seems to be indirectly caused by the page pool memory leak
>>> mechanism, which is probably a good thing.
>>>
>>> I have created a bug report, but there is no response.
>>>
>>> https://bugzilla.kernel.org/show_bug.cgi?id=218618
>>>
>>> I am uncertain where and to whom I need to report this page leak.
>>> Can you help me get this issue fixed?
>>
>> I'm the page_pool maintainer, but as you say yourself in comment 2 then
>> since dba1b8a7ab68 ("mm/page_pool: catch page_pool memory leaks") this
>> indicated there is a problem in the xen_netfront driver, which was
>> previously not visible.
>>
>> Cc'ing the "XEN NETWORK BACKEND DRIVER" maintainers, as this is a driver
>> bug.  What confuses me it that I cannot find any modules named
>> "xen_netfront" in the upstream tree.
>>
> 
> You should have tried '-' rather than '_' :-)
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/xen-netfront.c
> 

Looking at this driver, I think it is missing a call to 
skb_mark_for_recycle().

I'll will submit at patch for this, with details for stable maintainers.

As I think it dates back to v5.9 via commit 6c5aa6fc4def ("xen
networking: add basic XDP support for xen-netfront"). I think this
commit is missing a call to page_pool_release_page()
between v5.9 to v5.14, after which is should have used
skb_mark_for_recycle().

Since v6.6 the call page_pool_release_page() were removed (in
535b9c61bdef ("net: page_pool: hide page_pool_release_page()") and
remaining callers converted (in commit 6bfef2ec0172 ("Merge branch
'net-page_pool-remove-page_pool_release_page'")).

This leak became visible in v6.8 via commit dba1b8a7ab68 ("mm/page_pool:
catch page_pool memory leaks").

--Jesper


From xen-devel-bounces@lists.xenproject.org Wed Mar 27 11:30:44 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 11:30:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698443.1090077 (Exim 4.92)
	(envelope-from )
	id 1rpRUO-0000za-KG; Wed, 27 Mar 2024 11:30:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698443.1090077; Wed, 27 Mar 2024 11:30:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpRUO-0000zT-Hi; Wed, 27 Mar 2024 11:30:40 +0000
Received: by outflank-mailman (input) for mailman id 698443;
 Wed, 27 Mar 2024 11:30:39 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpRUN-0000zN-9u
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 11:30:39 +0000
Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com
 [2607:f8b0:4864:20::b2c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6f1285d2-ec2d-11ee-afe3-a90da7624cb6;
 Wed, 27 Mar 2024 12:30:38 +0100 (CET)
Received: by mail-yb1-xb2c.google.com with SMTP id
 3f1490d57ef6-dcbef31a9dbso4785286276.1
 for ; Wed, 27 Mar 2024 04:30:38 -0700 (PDT)
Received: from [10.80.67.139] (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 r15-20020a056214212f00b0069698528727sm2175211qvc.90.2024.03.27.04.30.34
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 27 Mar 2024 04:30:36 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6f1285d2-ec2d-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1711539037; x=1712143837; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=JwkWMoE6/Cnci5NscGLNDrRSmDoeYlNTnB0n/TZ3vvk=;
        b=HUgIWyphPPAYjDe423yDnHrVWTOigNjY8gSdRRQCGFC/reZIiDswSA9XVFhSbquY1L
         7ltgdt+v+OHQIvCfmOFhFwDsPoA5MBcQNKSlq4GaOEuC6ROitBJODZATQm2gF4wm2SYC
         YgDAWPAA9BGmqT/kgQGGkjfZ5sUz7dwUf+iIM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711539037; x=1712143837;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=JwkWMoE6/Cnci5NscGLNDrRSmDoeYlNTnB0n/TZ3vvk=;
        b=nyQoqSO5WCDRUQp2THvB2B32RjdzA+CkH/Oe75D74WaE4BE+93z74jn/ofvpV50upZ
         l9guRjuvLlSfdduRs8cQSDZixM8DD4xY39xCiviQi0gl2bAq+46G/cYFy6myin4U7rHN
         lTPf5H7SDQFwy1sR8xlHLjPF29OIT60RtNZk0HGwO42pAUwKgnBGLdsNjfcHjjSW+Upw
         v7VwFtZAddfqBAUjUJMxZVGjEWezXzdCRkypctKq1sl6ocnhcZt7WRCrpS5u3CsdZctA
         s+763JvMVRGn6dcZ70EZ5t3AJAmF1rwHtDdZjANlAEVhtcMkdrOaBZl6lBgPBfCyGJui
         kN2Q==
X-Forwarded-Encrypted: i=1; AJvYcCXtYyVvK/A/Oo8KYSObZS+o7mgCzcR/SmTY/sg+BTin3VMjySvGOEjkW0oy/W1qDnKhOaV3Vqs+Dbk8S6BpNqlYOTazXphB1GThnlsR0/0=
X-Gm-Message-State: AOJu0YxbF7r1/ZE9qUQHjqqQjngcRVn/eytDznVL2IQJgWqklY9UxJ7K
	Cdb2XrUmy876dwA9nWw0REtnQ90Z9kHHQPLpUUecGevcPTJKzeijJcJ90qMcbvw=
X-Google-Smtp-Source: AGHT+IHW1xP80WA4jBBNUeS1sdHJRAi/twm/YEYC2sGOn/0MA+8E2ktTda2jarA94MPUChe2JY843g==
X-Received: by 2002:a25:8009:0:b0:dcc:7b05:4cbb with SMTP id m9-20020a258009000000b00dcc7b054cbbmr674348ybk.31.1711539036992;
        Wed, 27 Mar 2024 04:30:36 -0700 (PDT)
Message-ID: <4df81c9b-fa7f-4585-a4a7-9f9189baa028@citrix.com>
Date: Wed, 27 Mar 2024 11:30:33 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Xen NIC driver have page_pool memory leaks
To: Jesper Dangaard Brouer , paul@xen.org,
 Arthur Borsboom ,
 Ilias Apalodimas 
Cc: Netdev , Wei Liu ,
 "xen-devel@lists.xenproject.org" ,
 kda@linux-powerpc.org, Xen Security 
References: 
 <1cde0059-d319-4a4f-a68d-3b3ffeb3da20@kernel.org>
 <857282f5-5df6-4ed7-b17e-92aae0cf484a@xen.org>
 
Content-Language: en-GB
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 27/03/2024 11:27 am, Jesper Dangaard Brouer wrote:
>
>
> On 25/03/2024 13.33, Paul Durrant wrote:
>> On 25/03/2024 12:21, Jesper Dangaard Brouer wrote:
>>> Hi Arthur,
>>>
>>> (Answer inlined below, which is custom on this mailing list)
>>>
>>> On 23/03/2024 14.23, Arthur Borsboom wrote:
>>>> Hi Jesper,
>>>>
>>>> After a recent kernel upgrade 6.7.6 > 6.8.1 all my Xen guests on Arch
>>>> Linux are dumping kernel traces.
>>>> It seems to be indirectly caused by the page pool memory leak
>>>> mechanism, which is probably a good thing.
>>>>
>>>> I have created a bug report, but there is no response.
>>>>
>>>> https://bugzilla.kernel.org/show_bug.cgi?id=218618
>>>>
>>>> I am uncertain where and to whom I need to report this page leak.
>>>> Can you help me get this issue fixed?
>>>
>>> I'm the page_pool maintainer, but as you say yourself in comment 2 then
>>> since dba1b8a7ab68 ("mm/page_pool: catch page_pool memory leaks") this
>>> indicated there is a problem in the xen_netfront driver, which was
>>> previously not visible.
>>>
>>> Cc'ing the "XEN NETWORK BACKEND DRIVER" maintainers, as this is a
>>> driver
>>> bug.  What confuses me it that I cannot find any modules named
>>> "xen_netfront" in the upstream tree.
>>>
>>
>> You should have tried '-' rather than '_' :-)
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/xen-netfront.c
>>
>>
>
> Looking at this driver, I think it is missing a call to
> skb_mark_for_recycle().
>
> I'll will submit at patch for this, with details for stable maintainers.
>
> As I think it dates back to v5.9 via commit 6c5aa6fc4def ("xen
> networking: add basic XDP support for xen-netfront"). I think this
> commit is missing a call to page_pool_release_page()
> between v5.9 to v5.14, after which is should have used
> skb_mark_for_recycle().
>
> Since v6.6 the call page_pool_release_page() were removed (in
> 535b9c61bdef ("net: page_pool: hide page_pool_release_page()") and
> remaining callers converted (in commit 6bfef2ec0172 ("Merge branch
> 'net-page_pool-remove-page_pool_release_page'")).
>
> This leak became visible in v6.8 via commit dba1b8a7ab68 ("mm/page_pool:
> catch page_pool memory leaks").

Thankyou very much for your help here.  Please CC
security@xenproject.org too, because we'll want to issue an XSA (Xen
Security Advisory) when this fix is ready.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Mar 27 11:35:00 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 11:35:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698454.1090120 (Exim 4.92)
	(envelope-from )
	id 1rpRYW-0001yA-FZ; Wed, 27 Mar 2024 11:34:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698454.1090120; Wed, 27 Mar 2024 11:34:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpRYW-0001y3-BA; Wed, 27 Mar 2024 11:34:56 +0000
Received: by outflank-mailman (input) for mailman id 698454;
 Wed, 27 Mar 2024 11:34:55 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpRYV-0001xx-2t
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 11:34:55 +0000
Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com
 [2a00:1450:4864:20::52f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 07951c3d-ec2e-11ee-afe3-a90da7624cb6;
 Wed, 27 Mar 2024 12:34:53 +0100 (CET)
Received: by mail-ed1-x52f.google.com with SMTP id
 4fb4d7f45d1cf-56c36c67deaso1234672a12.0
 for ; Wed, 27 Mar 2024 04:34:53 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ef4-20020a05640228c400b0056c498c9c92sm5368edb.31.2024.03.27.04.34.52
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 27 Mar 2024 04:34:52 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 07951c3d-ec2e-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711539293; x=1712144093; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:cc:references
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=ojLVLrJvL0DF+s1q9vHSVbghGXIXL8mZcVWJTiOzctA=;
        b=c7d82rEo2DNG5ejYHgK0ujjv/jKceYxJ5qH53eqeRPzzx6IWeRARKNoz0VPQB4XW6c
         RrJAHTVALc4UuMARorxHJTZJpNi0Wv+wg9RVTrD33pAEE0tWmgdhbx99uyBXv+TmZazD
         kIW/6ABR0IM//GC/HJ0AuYiYmdL0P+sqw8HYJ3B9n5Q5crEIDqPI+vIkdnX4P4PoJsCb
         QtmxBpSOF4LeItpTrRL0D4ZcgV9OLsG+EeN4oIb5EeeJDlGIKLaHj3f1y1kphJlWz3FW
         8zu0RcXO5HUTlN6g14MNtS5kP0w2zbfgMk0u8QUB1Ph0Q3Fx/dfcMvp9PMYlsxbguKX7
         HceQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711539293; x=1712144093;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:cc:references
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=ojLVLrJvL0DF+s1q9vHSVbghGXIXL8mZcVWJTiOzctA=;
        b=IcdeBoBkrZWsVHLbg4yPSvhvlT448yKVMEPwdsx5eWO0EqFjPB3m3L8rOZY+jZjoW7
         GnS9rrG9eDRhkSd4+WmB8hVXzfVInq7TJuiJVoe4y4m5p+EGp0dgWOjc5nLMhmIfL1Oe
         +JMUM8SEnsmUEHQekZM9/Eh9IoOgmlR8YlWJ+YmV//hKkQdgPR8ZGmX1KR4+3otp/G01
         vxKUekiLVdr7EafOh48TF/3/B/2IDuzf6lYipTch7tw1t4DGUkFDuATgqQGIyxrGvSpC
         9Ya5jMSoHQ9Z8TnN/PPfuGGbso+Tk4NE9xuqPmpOEwxVERfkojz37Mw8Op2am8aQ6JVU
         QZ5g==
X-Gm-Message-State: AOJu0YwrMdn1z1KULYtL0vSKxOtc802Nb6FP5yvzfVTW66ndHI1IZote
	YVbItjbHHvucT/fpSIp2v4Lcmo/HH6JBi9DfRQGYCLLurbtoHutkuiiVReELrA==
X-Google-Smtp-Source: AGHT+IFKtcMo1ylU4Vxluay9ykkwgXb0Rdk8YysDpsL8SZPPPBXmrViLIVOWywbFtfdeCv0pZrCDVQ==
X-Received: by 2002:a50:d497:0:b0:56c:189f:cf2f with SMTP id s23-20020a50d497000000b0056c189fcf2fmr585372edi.32.1711539293077;
        Wed, 27 Mar 2024 04:34:53 -0700 (PDT)
Message-ID: 
Date: Wed, 27 Mar 2024 12:34:52 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Backport request for 4.17
Content-Language: en-US
To: Anthony PERARD 
References: 
Cc: xen-devel@lists.xenproject.org
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 25.03.2024 18:02, Anthony PERARD wrote:
> Would it be possible to backport 18a36b4a9b08 ("tools: ipxe: update for
> fixing build with GCC12") to Xen 4.17 ?

Sure, now done.

Jan

> This would be to allow building Xen 4.17 on Debian Bookworm, and to allow
> osstest to test Xen 4.18 with Debian Bookworm. osstest always tries to
> migration from N-1 to N, so it would need to be able to build both 4.17
> and 4.18 to actually test 4.18. Otherwise, I can tell osstest to keep
> using Debian Buster to test 4.18.
> 
> For context:
>     https://lore.kernel.org/xen-devel/20240318165545.3898-36-anthony.perard@citrix.com/
> 
> That commit pulls a newer version of IPXE, I don't think there's be
> compatibility issue with Xen, and hopefully nothing breaks.
> 
> Thanks,
> 



From xen-devel-bounces@lists.xenproject.org Wed Mar 27 11:35:41 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 11:35:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698457.1090131 (Exim 4.92)
	(envelope-from )
	id 1rpRZE-0002Vm-SN; Wed, 27 Mar 2024 11:35:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698457.1090131; Wed, 27 Mar 2024 11:35:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpRZE-0002Vf-NP; Wed, 27 Mar 2024 11:35:40 +0000
Received: by outflank-mailman (input) for mailman id 698457;
 Wed, 27 Mar 2024 11:35:40 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpRZE-0002VP-0f; Wed, 27 Mar 2024 11:35:40 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpRZD-0004mV-WB; Wed, 27 Mar 2024 11:35:39 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpRZD-00045a-Lt; Wed, 27 Mar 2024 11:35:39 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rpRZD-00056q-L1; Wed, 27 Mar 2024 11:35:39 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=jdQoOAwsNYKchRovoQetPr795QBVK/oyWbkARILg88Y=; b=yyA+SF/rRlcOIW0OnXns7vWZqu
	aRUmP9e7+ZQrNoLmuVKqp+ss33sFL7V7n6neH5JC731s8wYXTGI0xLLSX07AMu+udTUhNpRCqI6DN
	KxKk9iAalu00AIwBSL1QQoXohIhhHwQ8h1MmndiOu0/8sefu8h11io32gshnk8TGq/Vg=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 185170: tolerable all pass - PUSHED
X-Osstest-Failures:
    xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    xen=e3883336bb5abba2ec2231618f5b64f61b099b1e
X-Osstest-Versions-That:
    xen=6f6de10ade5ade907f9e3f3c72b7b18f7852d9ff
From: osstest service owner 
Date: Wed, 27 Mar 2024 11:35:39 +0000

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          16 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  e3883336bb5abba2ec2231618f5b64f61b099b1e
baseline version:
 xen                  6f6de10ade5ade907f9e3f3c72b7b18f7852d9ff

Last test of basis   185157  2024-03-25 10:03:48 Z    2 days
Testing same since   185170  2024-03-27 09:03:56 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich 
  Jason Andryuk 
  Nicola Vetrini 

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-amd64                    pass    
 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
   6f6de10ade..e3883336bb  e3883336bb5abba2ec2231618f5b64f61b099b1e -> smoke


From xen-devel-bounces@lists.xenproject.org Wed Mar 27 11:39:28 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 11:39:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698464.1090139 (Exim 4.92)
	(envelope-from )
	id 1rpRcq-0003PO-8q; Wed, 27 Mar 2024 11:39:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698464.1090139; Wed, 27 Mar 2024 11:39:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpRcq-0003PH-6K; Wed, 27 Mar 2024 11:39:24 +0000
Received: by outflank-mailman (input) for mailman id 698464;
 Wed, 27 Mar 2024 11:39:22 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpRco-0003Np-PK
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 11:39:22 +0000
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com
 [2a00:1450:4864:20::632])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a75dc23c-ec2e-11ee-afe3-a90da7624cb6;
 Wed, 27 Mar 2024 12:39:21 +0100 (CET)
Received: by mail-ej1-x632.google.com with SMTP id
 a640c23a62f3a-a4dfe6564b6so119877366b.3
 for ; Wed, 27 Mar 2024 04:39:21 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a75dc23c-ec2e-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1711539561; x=1712144361; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=e7Cmj1xAT0bHcr5rAW0psYRi+vKEAs6qSS6NwGHjFIY=;
        b=s+QPq1AeviPuVxp4TJjHnkQb0PzxPLoBlc88oGS/alw4uKdx5F/sRYdN+8+jqhYaMi
         LnDL/MwQCXT70Q7iEaxK8UlOTyIjyNc0fTkqQwgt8TK1it7bY7/WF8PjxlwQSMWEIdpS
         r+t+Iz6PpQrRO4q3wEGOgYzoi/x1H3Hh+Nni1pcF8iqbB+MXtliqIWfkiXLWTzqsEV/D
         wGH4R68zZs0EP+VDRekVuKLOdoVaJGFYACLME2Q46b7RSkHDQUV3CM23tKjXgn1DXmIR
         ya3yuNO6NMmREkJrP5pOpqG/PtqB33qMhKeYmcFXjgVHVrlF6T00I4ghzN5o0+ui9436
         YV8A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711539561; x=1712144361;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=e7Cmj1xAT0bHcr5rAW0psYRi+vKEAs6qSS6NwGHjFIY=;
        b=WmZ5x0oMDzHPoDfJ6tiljVToDKCZQ0jZB/kQjn19CX1pTEtBP4JVDDmMZl/gLhLz5I
         JjVOD+40sliCgqVbif72EFI/6IrnVXdF39eD78DXuJlAsjblo9mg+mPqLRHVSzY0QnYq
         NcslT+hlI5AJ3LFcheN6BKSlEzRAbHnD6LCH4BgGUESleB51fAZLoKTFJVLNi738VkQa
         D4epkOWPKyJTjL9V/hhKDSG+UBha6H196njBEou/x7Ozb+jINVMlnBHSlgd4YnWA51/n
         leHRaoOVMLWhBZfXk3fCsEEB5F2kpDu6WGTQ3mJJSM6ilsZKxdXdSB/dDRr+UboCL6FF
         2srQ==
X-Forwarded-Encrypted: i=1; AJvYcCWurwrSRdtNZr6cwhrYYQcgdgEyy1I0ol0D+b8ngn8Sm7XTBU0iIpU8lbkXgFC+lwTNIBvyQx4gHncn4uGXlauDAtbavY9GmbeK2/9P6hU=
X-Gm-Message-State: AOJu0Yxh6DLbefmL2VprTqn/3JPIX4sGy9ovhIc2tVaP726AdgWZfL2u
	BrlD4ncOk8i+eXvuZva7wlAgh4QYDnn6dFkvldIzvee15FmWRmD+C+KxZYFQ82p3jiRLhaorIBg
	IR1G3PiAyvnmsr75+BdiJ3ze9JLSx24gHhH8dKw==
X-Google-Smtp-Source: AGHT+IGwcSyKX+BtPeQ0QrtY6dv4B9tAsaG+qOky17YragqNxKJd0u+dz6Iyx+l3e+tGd+I7iPoQEBTEimNFWFb5y+s=
X-Received: by 2002:a17:906:24d2:b0:a45:b1d8:200c with SMTP id
 f18-20020a17090624d200b00a45b1d8200cmr2756034ejb.14.1711539561168; Wed, 27
 Mar 2024 04:39:21 -0700 (PDT)
MIME-Version: 1.0
References: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
 <20240315105902.160047-5-carlo.nonato@minervasys.tech> 
 
 <3ff10fdd-5a85-43b3-853a-fe69c7388ca9@suse.com> 
 <22ab32bb-b0d0-4d68-8918-5fcb42cc0f88@suse.com>
In-Reply-To: <22ab32bb-b0d0-4d68-8918-5fcb42cc0f88@suse.com>
From: Carlo Nonato 
Date: Wed, 27 Mar 2024 12:39:10 +0100
Message-ID: 
Subject: Re: [PATCH v7 04/14] xen/arm: add Dom0 cache coloring support
To: Julien Grall , Bertrand Marquis , 
	Michal Orzel , Volodymyr Babchuk , 
	Stefano Stabellini 
Cc: Jan Beulich , Andrew Cooper , 
	George Dunlap , Wei Liu , 
	Marco Solieri , xen-devel@lists.xenproject.org, 
	Andrea Bastoni 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi guys,

On Fri, Mar 22, 2024 at 8:26=E2=80=AFAM Jan Beulich  wro=
te:
>
> On 21.03.2024 18:31, Carlo Nonato wrote:
> > On Thu, Mar 21, 2024 at 4:57=E2=80=AFPM Jan Beulich =
 wrote:
> >>
> >> On 21.03.2024 16:04, Carlo Nonato wrote:
> >>> On Tue, Mar 19, 2024 at 4:30=E2=80=AFPM Jan Beulich  wrote:
> >>>> On 15.03.2024 11:58, Carlo Nonato wrote:
> >>>>> --- a/docs/misc/xen-command-line.pandoc
> >>>>> +++ b/docs/misc/xen-command-line.pandoc
> >>>>> @@ -963,6 +963,15 @@ Controls for the dom0 IOMMU setup.
> >>>>>
> >>>>>  Specify a list of IO ports to be excluded from dom0 access.
> >>>>>
> >>>>> +### dom0-llc-colors
> >>>>> +> `=3D List of [  | - ]`
> >>>>> +
> >>>>> +> Default: `All available LLC colors`
> >>>>> +
> >>>>> +Specify dom0 LLC color configuration. This option is available onl=
y when
> >>>>> +`CONFIG_LLC_COLORING` is enabled. If the parameter is not set, all=
 available
> >>>>> +colors are used.
> >>>>
> >>>> My reservation towards this being a top-level option remains.
> >>>
> >>> How can I turn this into a lower-level option? Moving it into "dom0=
=3D" doesn't
> >>> seem possible to me. How can I express a list (llc-colors) inside ano=
ther list
> >>> (dom0)? dom0=3Dllc-colors=3D0-3,12-15,other-param=3D... How can I sto=
p parsing
> >>> before reaching other-param?
> >>
> >> For example by using a different separator:
> >>
> >> dom0=3Dllc-colors=3D0-3+12-15,other-param=3D...
> >
> > Ok, but that would mean to change the implementation of the parsing fun=
ction
> > and to adopt this syntax also in other places, something that I would'v=
e
> > preferred to avoid. Anyway I'll follow your suggestion.
>
> Well, this is all used by Arm only for now. You will want to make sure Ar=
m
> folks are actually okay with this alternative approach.
>
> Jan

Are you Arm maintainers ok with this?

Thanks.


From xen-devel-bounces@lists.xenproject.org Wed Mar 27 11:46:57 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 11:46:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698469.1090150 (Exim 4.92)
	(envelope-from )
	id 1rpRjz-0005PJ-16; Wed, 27 Mar 2024 11:46:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698469.1090150; Wed, 27 Mar 2024 11:46:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpRjy-0005PC-Tj; Wed, 27 Mar 2024 11:46:46 +0000
Received: by outflank-mailman (input) for mailman id 698469;
 Wed, 27 Mar 2024 11:46:45 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpRjx-0005P6-Si
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 11:46:45 +0000
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com
 [2a00:1450:4864:20::62e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id aee1259e-ec2f-11ee-a1ef-f123f15fe8a2;
 Wed, 27 Mar 2024 12:46:43 +0100 (CET)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-a46d0a8399aso132500866b.1
 for ; Wed, 27 Mar 2024 04:46:43 -0700 (PDT)
Received: from ?IPV6:2003:e5:873a:400:704b:6dbb:e7c0:786e?
 (p200300e5873a0400704b6dbbe7c0786e.dip0.t-ipconnect.de.
 [2003:e5:873a:400:704b:6dbb:e7c0:786e])
 by smtp.gmail.com with ESMTPSA id
 jz7-20020a17090775e700b00a4576dd5a8csm5298632ejc.201.2024.03.27.04.46.42
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 27 Mar 2024 04:46:42 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: aee1259e-ec2f-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711540003; x=1712144803; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:to:subject:user-agent:mime-version:date:message-id:from
         :to:cc:subject:date:message-id:reply-to;
        bh=nYJhOp1HdiZ30o0KUf7gZsyGPQk3iQ3CCRuFDUz34rc=;
        b=F9mKAP7ozOm1vInxxvwSoJVegwR2JqqRm8Gg+Ye8f8XgLfzrrj7rMWl7tGbiEZJrWI
         frOQfgfvf9kFN771Oqc0LkNUOH9cjuYsChL7Jr8q6qdLJ6Nyr0xSNzJllD/tp/VcStAj
         5ZyYJ86fSsnwQCewN+f2eVTMi/EK7e48YN4R6QC/C2cZLxbyS/Zd0kNaEt9oexbAGXhf
         9jA8WPrdPXr8D+yeaQrJ3DlsRTdYXROHKC7i+G3IN/wE9ieCoa9uLWRFTZj6eBn5ObzR
         lNkFnRSV2AKxnPDxS6gL0k8Ksa4LXk5sLGfAOd/3gxn9Ejs4rZqYQWAlWvJr2sOBDT/0
         ZksQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711540003; x=1712144803;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=nYJhOp1HdiZ30o0KUf7gZsyGPQk3iQ3CCRuFDUz34rc=;
        b=LLgW/QZNGlhA8rzlANXtlJ1+znSQdT+1cTYXpMIdcS5DCVnwd5lGElqnCILSLOzu6/
         IS+Lyc7z4woyo2zzTrGKLGLbkRbABxsFoqBpU/7XQa4NLt0KYGtz8DOqjPp3v6+HLRxC
         JVQ8c47eMh4s4XiOxGmbGCXf8Q+l3REoLnRyQV0nmpX16Md4ZkHZgoiJxOtxq7fKSoGq
         IvimAD5WELRsC1ky9uuWCduRlFaZZInxlWoWM5g3VKeahJox2bBd4fFooySaK1bg0+iQ
         to1M1AJ+oGrsF2SAOeYrY6m29oVtPyB0IZ8cVXr3Ttb04bYysTxsvAB5BeFfiTO9snXv
         jy6w==
X-Forwarded-Encrypted: i=1; AJvYcCWU21hWJLMvJPbUun4i+VXaQOhb0HxYk64ZhAhHeCCSQAeXMDIiECVW3KGEeKucoAP8mWqztMh/IrQFoFztPMae3jaBGfq86O1yT76t5Z0=
X-Gm-Message-State: AOJu0YwRETdsG6yTZmEYQMRwQgHMU8nm71Y8SL5fyae52/PBgm5HvNay
	KX8/oVBgCMFpxOKWTm4mnVpFxMLWjV0erIuwXpTiRwRV7n/OIlmPmC53eRUJlUeEl14W1D2YtC+
	c
X-Google-Smtp-Source: AGHT+IG9y/e3br/wLk0Rx0Yrc9YZCZ9ogzlw5ruUcIzUPkD+ipliq//08GYJYjaMMqKGEpkqTA8eNg==
X-Received: by 2002:a17:906:6a04:b0:a4a:306a:ab9b with SMTP id qw4-20020a1709066a0400b00a4a306aab9bmr4398557ejc.0.1711540003120;
        Wed, 27 Mar 2024 04:46:43 -0700 (PDT)
Message-ID: 
Date: Wed, 27 Mar 2024 12:46:42 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Linux Xen PV CPA W^X violation false-positives
To: Jason Andryuk , xen-devel@lists.xenproject.org
References: <20240124165401.35784-1-jandryuk@gmail.com>
Content-Language: en-US
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
In-Reply-To: <20240124165401.35784-1-jandryuk@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 24.01.24 17:54, Jason Andryuk wrote:
> Xen PV domains show CPA W^X violations like:
> 
> CPA detected W^X violation: 0000000000000064 -> 0000000000000067 range: 0xffff888000010000 - 0xffff888000010fff PFN 10
> WARNING: CPU: 0 PID: 30 at arch/x86/mm/pat/set_memory.c:613 __change_page_attr_set_clr+0x113a/0x11c0
> Modules linked in: xt_physdev xt_MASQUERADE iptable_nat nf_nat nf_conntrack libcrc32c nf_defrag_ipv4 ip_tables x_tables xen_argo(O)
> CPU: 0 PID: 30 Comm: kworker/0:2 Tainted: G           O       6.1.38 #1
> Workqueue: events bpf_prog_free_deferred
> RIP: e030:__change_page_attr_set_clr+0x113a/0x11c0
> Code: 4c 89 f1 4c 89 e2 4c 89 d6 4c 89 8d 70 ff ff ff 4d 8d 86 ff 0f 00 00 48 c7 c7 f0 3c da 81 c6 05 d0 0e 0e 01 01 e8 f6 71 00 00 <0f> 0b 4c 8b 8d 70 ff ff ff e9 2a fd ff ff 48 8b 85 60 ff ff ff 48
> RSP: e02b:ffffc90000367c48 EFLAGS: 00010282
> RAX: 0000000000000000 RBX: 000ffffffffef064 RCX: 0000000000000000
> RDX: 0000000000000003 RSI: 00000000fffff7ff RDI: 00000000ffffffff
> RBP: ffffc90000367d48 R08: 0000000000000000 R09: ffffc90000367aa0
> R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000067
> R13: 0000000000000001 R14: ffff888000010000 R15: ffffc90000367d60
> FS:  0000000000000000(0000) GS:ffff88800b800000(0000) knlGS:0000000000000000
> CS:  e030 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007fdbaeda01c0 CR3: 0000000004312000 CR4: 0000000000050660
> Call Trace:
>   
>   ? show_regs.cold+0x1a/0x1f
>   ? __change_page_attr_set_clr+0x113a/0x11c0
>   ? __warn+0x7b/0xc0
>   ? __change_page_attr_set_clr+0x113a/0x11c0
>   ? report_bug+0x111/0x1a0
>   ? handle_bug+0x4d/0xa0
>   ? exc_invalid_op+0x19/0x70
>   ? asm_exc_invalid_op+0x1b/0x20
>   ? __change_page_attr_set_clr+0x113a/0x11c0
>   ? __change_page_attr_set_clr+0x113a/0x11c0
>   ? debug_smp_processor_id+0x17/0x20
>   ? ___cache_free+0x2e/0x1e0
>   ? _raw_spin_unlock+0x1e/0x40
>   ? __purge_vmap_area_lazy+0x2ea/0x6b0
>   set_direct_map_default_noflush+0x7c/0xa0
>   __vunmap+0x1ac/0x280
>   __vfree+0x1d/0x60
>   vfree+0x27/0x40
>   __bpf_prog_free+0x44/0x50
>   bpf_prog_free_deferred+0x104/0x120
>   process_one_work+0x1ca/0x3d0
>   ? process_one_work+0x3d0/0x3d0
>   worker_thread+0x45/0x3c0
>   ? process_one_work+0x3d0/0x3d0
>   kthread+0xe2/0x110
>   ? kthread_complete_and_exit+0x20/0x20
>   ret_from_fork+0x1f/0x30
>   
> ---[ end trace 0000000000000000 ]---
> 
> Xen provides a set of page tables that the guest executes out of when it
> starts.  The L1 entries are shared between level2_ident_pgt and
> level2_kernel_pgt, and xen_setup_kernel_pagetable() sets the NX bit in
> the level2_ident_pgt entries.  verify_rwx() only checks the l1 entry and
> reports a false-positive violation.
> 
> Here is a dump of some kernel virtual addresses and the corresponding
> L1 and L2 entries:
> This is the start of the directmap (ident) and they have NX (bit 63) set
> in the PMD.
> ndvm-pv (1): [    0.466778] va=ffff888000000000 pte=0010000000000027 level: 1
> ndvm-pv (1): [    0.466788] va=ffff888000000000 pmd=800000000242c067 level: 2
> Directmap for kernel text:
> ndvm-pv (1): [    0.466795] va=ffff888001000000 pte=0010000001000065 level: 1
> ndvm-pv (1): [    0.466801] va=ffff888001000000 pmd=8000000002434067 level: 2
> ndvm-pv (1): [    0.466807] va=ffff888001010000 pte=0010000001010065 level: 1
> ndvm-pv (1): [    0.466814] va=ffff888001010000 pmd=8000000002434067 level: 2
> The start of the kernel text highmap is unmapped:
> ndvm-pv (1): [    0.466820] va=ffffffff80000000 pte=0000000000000000 level: 3
> ndvm-pv (1): [    0.466826] va=ffffffff80000000 pmd=0000000000000000 level: 3
> Kernel PMD for .text has NX bit clear
> ndvm-pv (1): [    0.466832] va=ffffffff81000000 pte=0010000001000065 level: 1
> ndvm-pv (1): [    0.466838] va=ffffffff81000000 pmd=0000000002434067 level: 2
> Kernel PTE for rodata_end has NX bit set
> ndvm-pv (1): [    0.466846] va=ffffffff81e62000 pte=8010000001e62025 level: 1
> ndvm-pv (1): [    0.466874] va=ffffffff81e62000 pmd=000000000243b067 level: 2
> Directmap of rodata_end
> ndvm-pv (1): [    0.466907] va=ffff888001e62000 pte=8010000001e62025 level: 1
> ndvm-pv (1): [    0.466913] va=ffff888001e62000 pmd=800000000243b067 level: 2
> Directmap of a low RAM address
> ndvm-pv (1): [    0.466920] va=ffff888000010000 pte=0010000000010027 level: 1
> ndvm-pv (1): [    0.466926] va=ffff888000010000 pmd=800000000242c067 level: 2
> Directmap of another RAM address close to but below kernel text
> ndvm-pv (1): [    0.466932] va=ffff88800096c000 pte=001000000096c027 level: 1
> ndvm-pv (1): [    0.466938] va=ffff88800096c000 pmd=8000000002430067 level: 2
> 
> Here are some L2 entries showing the differing NX bits for l2_ident vs.
> l2_kernel while they point at the same L1 addresses
> ndvm-pv (1): [    0.466944]  l2_ident[  0] pmd=800000000242c067
> ndvm-pv (1): [    0.466949]  l2_ident[  1] pmd=800000000242d067
> ndvm-pv (1): [    0.466955]  l2_ident[  8] pmd=8000000002434067
> ndvm-pv (1): [    0.466959]  l2_ident[  9] pmd=8000000002435067
> ndvm-pv (1): [    0.466964]  l2_ident[ 14] pmd=800000000243a067
> ndvm-pv (1): [    0.466969]  l2_ident[ 15] pmd=800000000243b067
> ndvm-pv (1): [    0.466974] l2_kernel[  8] pmd=0000000002434067
> ndvm-pv (1): [    0.466979] l2_kernel[  9] pmd=0000000002435067
> ndvm-pv (1): [    0.466984] l2_kernel[ 14] pmd=000000000243a067
> ndvm-pv (1): [    0.466989] l2_kernel[ 15] pmd=000000000243b067
> 
> One option is to add a fallback check for verify_rwx() to check the PMD
> permissions to silence the warning.  Something like below.  I think it's
> not readily generalizable as it hardcodes checking the PMD.  That works
> for Xen where L1 PTEs are always used, but wouldn't work for Non-Xen.

I don't think this would be a real issue, as it is only Xen PV code setting
the NX bit is PMD entries.

And in case it really becomes an issue, the higher level page tables could be
checked, too.

> The other option would be to duplicate L1 page tables.  Xen PV doesn't
> support large pages, so the kernel highmap can't use large pages.  The
> increased memory would add up though.

Indeed, so I don't think this would be a good idea.

> 
> Regards,
> Jason
> ---
>   arch/x86/mm/pat/set_memory.c | 14 ++++++++++++++
>   1 file changed, 14 insertions(+)
> 
> diff --git a/arch/x86/mm/pat/set_memory.c b/arch/x86/mm/pat/set_memory.c
> index e9b448d1b1b7..904129b411ee 100644
> --- a/arch/x86/mm/pat/set_memory.c
> +++ b/arch/x86/mm/pat/set_memory.c
> @@ -641,6 +641,20 @@ static inline pgprot_t verify_rwx(pgprot_t old, pgprot_t new, unsigned long star
>   	if ((pgprot_val(new) & (_PAGE_RW | _PAGE_NX)) != _PAGE_RW)
>   		return new;
>   
> +	if ((pgprot_val(new) & (_PAGE_RW | _PAGE_NX)) == _PAGE_RW) {

This if is a little bit strange, as the condition can't ever be false.

I'd rather test "if (npg == 1)" as this is the case where a PMD entry is really
existing, ...

> +		pmd_t *pmd = lookup_pmd_address(start);
> +
> +		if (pmd && pmd_val(*pmd) & _PAGE_NX) {

... removing the need to test for pmd to be not NULL.

> +			pr_debug_once("CPA PMD 0x%016lx NX prevents PTE W^X violation: %016llx -> %016llx range: 0x%016lx - 0x%016lx PFN %lx\n",
> +				      pmd_flags(*pmd),
> +				      (unsigned long long)pgprot_val(old),
> +				      (unsigned long long)pgprot_val(new),
> +				      start, end, pfn);

I'd scratch that pr_debug(), as it doesn't really help.

> +
> +			return new;
> +		}
> +	}
> +
>   	end = start + npg * PAGE_SIZE - 1;
>   	WARN_ONCE(1, "CPA detected W^X violation: %016llx -> %016llx range: 0x%016lx - 0x%016lx PFN %lx\n",
>   		  (unsigned long long)pgprot_val(old),

Jason, do you want to send a V2 with your Signed-off, or would you like me to
try upstreaming the patch?


Juergen


From xen-devel-bounces@lists.xenproject.org Wed Mar 27 11:50:28 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 11:50:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698471.1090159 (Exim 4.92)
	(envelope-from )
	id 1rpRnW-0007UL-Fi; Wed, 27 Mar 2024 11:50:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698471.1090159; Wed, 27 Mar 2024 11:50:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpRnW-0007UE-DB; Wed, 27 Mar 2024 11:50:26 +0000
Received: by outflank-mailman (input) for mailman id 698471;
 Wed, 27 Mar 2024 11:50:25 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpRnV-0007U8-1J
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 11:50:25 +0000
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com
 [2a00:1450:4864:20::62d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 32189df3-ec30-11ee-afe3-a90da7624cb6;
 Wed, 27 Mar 2024 12:50:23 +0100 (CET)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-a47385a4379so143188866b.0
 for ; Wed, 27 Mar 2024 04:50:23 -0700 (PDT)
Received: from perard.uk.xensource.com (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 u1-20020a1709063b8100b00a46fbff47a6sm5322360ejf.168.2024.03.27.04.50.22
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 27 Mar 2024 04:50:22 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 32189df3-ec30-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1711540223; x=1712145023; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=4FC6f2CiQL5W1YZBJ6SK7a0UwL0NwwFJDhTY6Z9yEh8=;
        b=Cy8mPMBHNgZGtKq/fDoOgQdcVM5rrAA9vFrEePUze5qwkUh8zyytvlxiz9rPk57pAh
         JrEL0q3HCzVWbC6lj1xzPO+npyyJrYibJ14JnjVE+AI00H4XZlNfFFH/V9+yEKTivxXq
         44/S3gSuFtJnN10Po/e+C9tQqkW5814jtUCz0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711540223; x=1712145023;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=4FC6f2CiQL5W1YZBJ6SK7a0UwL0NwwFJDhTY6Z9yEh8=;
        b=ABVCRIE0Iv+w6f9I75xQ4/5ULLxfGrKvtzoC732zRj/6hg5OTZqmdlwXk7Nw/kbtjl
         mGE1oN5GNq3HAHXai9ZnQ1f4cZtMyBUYTCY+V90VNm2I2gG/NxdZ9p1/B8TwM0EmRaE9
         qDnTk1Sorzj55ZRpfSCRghUmctxdnrgyn3u2nh5N23ftwiCsS/4fK5jX5lX3T34Q7+ij
         xelEf1LcJE3toUAZFT06keVgoLk5Qum/6Zo6fXY69gOjphgWnXsrWS58jU7JrLXbuHNQ
         q+NXpxTPqL6GrcfUiEzjbeWgsGrFu7Ioc1EX3yfBLdg/TmPUl9rKtHZYe6JIyapCcKXz
         7+ag==
X-Forwarded-Encrypted: i=1; AJvYcCWKngMPltAAVtyr0dxzqJ7t1SBwsOS1PIECUi0EhdRRTMAs+Lg8IORV/OHEFPvrzdkauOlMqQHocdl7Y+c/uQR7fi43ebapJe6RhVt59nI=
X-Gm-Message-State: AOJu0YxvLAWbW10d+KHpFtT6yqPV1gy0Z1fAOMyns0cXWKU9qh0CUspH
	tza6qUdBuK6DaAahzh/E0zbd8VduKHbZDSXTynDi40h1Lsryd1u3k81k3PI77rs=
X-Google-Smtp-Source: AGHT+IHjrlueyINri3BcwMN7nzklq3D6QJVA6wmS9ETMB5MPCffXe1tqgCTZZJIf53/O2Hw5bsVZmw==
X-Received: by 2002:a17:906:a890:b0:a47:134d:2fc8 with SMTP id ha16-20020a170906a89000b00a47134d2fc8mr3629567ejb.10.1711540223416;
        Wed, 27 Mar 2024 04:50:23 -0700 (PDT)
Date: Wed, 27 Mar 2024 11:50:21 +0000
From: Anthony PERARD 
To: Philippe =?iso-8859-1?Q?Mathieu-Daud=E9?= 
Cc: David Woodhouse , qemu-devel@nongnu.org,
	Alex =?iso-8859-1?Q?Benn=E9e?= ,
	Paul Durrant , qemu-arm@nongnu.org,
	Paolo Bonzini ,
	David Woodhouse ,
	Stefano Stabellini ,
	Richard Henderson ,
	xen-devel@lists.xenproject.org, qemu-block@nongnu.org,
	kvm@vger.kernel.org, Thomas Huth ,
	Gerd Hoffmann 
Subject: Re: [PATCH-for-9.0 v2 05/19] hw/display: Restrict
 xen_register_framebuffer() call to Xen
Message-ID: <7e08a2d5-7d90-4d48-85e5-4c7e39d59c11@perard>
References: <20231114143816.71079-1-philmd@linaro.org>
 <20231114143816.71079-6-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20231114143816.71079-6-philmd@linaro.org>

On Tue, Nov 14, 2023 at 03:38:01PM +0100, Philippe Mathieu-Daud wrote:
> Only call xen_register_framebuffer() when Xen is enabled.
> 
> Signed-off-by: Philippe Mathieu-Daud 

I don't think this patch is very useful but it's fine, so:
Reviewed-by: Anthony PERARD 

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Wed Mar 27 11:54:34 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 11:54:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698473.1090169 (Exim 4.92)
	(envelope-from )
	id 1rpRrR-0008GG-VO; Wed, 27 Mar 2024 11:54:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698473.1090169; Wed, 27 Mar 2024 11:54:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpRrR-0008G9-SO; Wed, 27 Mar 2024 11:54:29 +0000
Received: by outflank-mailman (input) for mailman id 698473;
 Wed, 27 Mar 2024 11:54:28 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpRrQ-0008G3-LW
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 11:54:28 +0000
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com
 [2a00:1450:4864:20::535])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c35b7d3e-ec30-11ee-afe3-a90da7624cb6;
 Wed, 27 Mar 2024 12:54:27 +0100 (CET)
Received: by mail-ed1-x535.google.com with SMTP id
 4fb4d7f45d1cf-56c2b4850d2so2084779a12.2
 for ; Wed, 27 Mar 2024 04:54:27 -0700 (PDT)
Received: from perard.uk.xensource.com (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 x20-20020a170906b09400b00a469e55767dsm5334791ejy.214.2024.03.27.04.54.26
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 27 Mar 2024 04:54:26 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c35b7d3e-ec30-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1711540467; x=1712145267; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=Xo2nfZBTCiRDB2jtZRoNWpjUBE4WiCL6rnHvacWUBJM=;
        b=AkAEbSXa1Tq3OvUEJzRiH30kpRdpXnwlN3gFTis2YZ0X+ozEYGLemev2TLfWXbDDeP
         18G6QMRPvYLdyQ9fg3oJAHTHdcRUsJ26BsdBQFRHbQ5znDhrDwloF5n06oc6VifH8T1v
         izjKsVvy0fqykgDE5Uq/AsPphl3vSTiX5pJEg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711540467; x=1712145267;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=Xo2nfZBTCiRDB2jtZRoNWpjUBE4WiCL6rnHvacWUBJM=;
        b=FlFY1283zE8CQSVFZX2AfjjQ/2rwh6eU3i4/8ic1zWrFMJWyi2BTda9QGv+GxxOloh
         zrtq0KTaE3v4oYrBK6fqHOC/4FNYxe5mmsCMPUc0fQw/2TgKdxqZCHjBAr+Ebdp02qoX
         NsmMjAXiZxrfcJ16OIph/3VoVGiDmdT0mJR6yjHr0jF5xBV/Bwj1J790rsR5ygJAEDVs
         r3lfj8YAQ+0gvVRb9sCrOxfbYAxR3lg0/RuWxRw71E2pSrypCZH5rUgln7y9ITAqjXGZ
         UMC8gkjlYdR8Nt6jSllY1IcNmny1TzntdOP9IpauicCiNcuALKJ+x3YL9Uf8nxW5p61H
         aU7Q==
X-Forwarded-Encrypted: i=1; AJvYcCWSZNti0sOZy3WuPe2rg07PTh6Po5eu7D8/OMxvYYBBLTzk913il6rgDmNd+FQvEajQEl6888yHC3nNRVyr2LKVVEdjoPIyGsOH+ZUMN04=
X-Gm-Message-State: AOJu0YyrzX84JUIVvy18S5Utv5xfrbenWSRWKm4oCmfuvNfsfq6aLHo2
	pHnkut9uYKxyScaNPN6zX90C3yCf2k+YdZZel6PXGeKFDUCmGOY/CqQ3VhKOpRc=
X-Google-Smtp-Source: AGHT+IG9GlCL2qsgWyuFSglCpOBIwZX7MMRogX3VsIf8avJI3j19EV0AuKmIO9P0kiOttKpgN9U6dQ==
X-Received: by 2002:a17:906:1911:b0:a4d:f2a3:9c37 with SMTP id a17-20020a170906191100b00a4df2a39c37mr3310934eje.4.1711540467139;
        Wed, 27 Mar 2024 04:54:27 -0700 (PDT)
Date: Wed, 27 Mar 2024 11:54:26 +0000
From: Anthony PERARD 
To: Philippe =?iso-8859-1?Q?Mathieu-Daud=E9?= 
Cc: David Woodhouse , qemu-devel@nongnu.org,
	Alex =?iso-8859-1?Q?Benn=E9e?= ,
	Paul Durrant , qemu-arm@nongnu.org,
	Paolo Bonzini ,
	David Woodhouse ,
	Stefano Stabellini ,
	Richard Henderson ,
	xen-devel@lists.xenproject.org, qemu-block@nongnu.org,
	kvm@vger.kernel.org, Thomas Huth 
Subject: Re: [PATCH-for-9.0 v2 08/19] hw/xen: Remove unused Xen stubs
Message-ID: <7af32170-a282-4f28-9db6-913087960acf@perard>
References: <20231114143816.71079-1-philmd@linaro.org>
 <20231114143816.71079-9-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20231114143816.71079-9-philmd@linaro.org>

On Tue, Nov 14, 2023 at 03:38:04PM +0100, Philippe Mathieu-Daud wrote:
> All these stubs are protected by a 'if (xen_enabled())' check.

Are you sure? There's still nothing that prevent a compiler from wanting
those, I don't think.

Sure, often compilers will remove dead code in `if(0){...}`, but there's
no guaranty, is there?

Cheers,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Wed Mar 27 11:56:38 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 11:56:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698479.1090188 (Exim 4.92)
	(envelope-from )
	id 1rpRtV-0000XH-HD; Wed, 27 Mar 2024 11:56:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698479.1090188; Wed, 27 Mar 2024 11:56:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpRtV-0000XA-ER; Wed, 27 Mar 2024 11:56:37 +0000
Received: by outflank-mailman (input) for mailman id 698479;
 Wed, 27 Mar 2024 11:56:36 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1rpRtU-0000X2-1L
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 11:56:36 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpRtO-00058n-S2; Wed, 27 Mar 2024 11:56:30 +0000
Received: from [15.248.2.236] (helo=[10.24.67.40])
 by xenbits.xenproject.org with esmtpsa
 (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92)
 (envelope-from )
 id 1rpRtO-0007yZ-Jm; Wed, 27 Mar 2024 11:56:30 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=pDtxU+5Q9VsdwX7QM3fmDb6ACdB0DtdjTXvQ/YcxOUM=; b=IJbbxea2cQtW08nT+srVKerDRn
	dfDWbBi4sJSLCLR0AO1sZdXrKuHTdQWgI2jMO9CtT5tSsBWb929lt41tgs2Dn6AdNENTFffB/L3v6
	etTDhlwa+xb9HIMRNwFWKbxxKnSBI3MVoJKg+K+JwWPpnaAo6xHQhb+pMh5hJeHd8lwQ=;
Message-ID: 
Date: Wed, 27 Mar 2024 11:56:28 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 04/14] xen/arm: add Dom0 cache coloring support
Content-Language: en-GB
To: Carlo Nonato ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Stefano Stabellini 
Cc: Jan Beulich , Andrew Cooper
 , George Dunlap ,
 Wei Liu , Marco Solieri ,
 xen-devel@lists.xenproject.org,
 Andrea Bastoni 
References: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
 <20240315105902.160047-5-carlo.nonato@minervasys.tech>
 
 
 <3ff10fdd-5a85-43b3-853a-fe69c7388ca9@suse.com>
 
 <22ab32bb-b0d0-4d68-8918-5fcb42cc0f88@suse.com>
 
From: Julien Grall 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi,

On 27/03/2024 11:39, Carlo Nonato wrote:
> On Fri, Mar 22, 2024 at 8:26 AM Jan Beulich  wrote:
>>
>> On 21.03.2024 18:31, Carlo Nonato wrote:
>>> On Thu, Mar 21, 2024 at 4:57 PM Jan Beulich  wrote:
>>>>
>>>> On 21.03.2024 16:04, Carlo Nonato wrote:
>>>>> On Tue, Mar 19, 2024 at 4:30 PM Jan Beulich  wrote:
>>>>>> On 15.03.2024 11:58, Carlo Nonato wrote:
>>>>>>> --- a/docs/misc/xen-command-line.pandoc
>>>>>>> +++ b/docs/misc/xen-command-line.pandoc
>>>>>>> @@ -963,6 +963,15 @@ Controls for the dom0 IOMMU setup.
>>>>>>>
>>>>>>>   Specify a list of IO ports to be excluded from dom0 access.
>>>>>>>
>>>>>>> +### dom0-llc-colors
>>>>>>> +> `= List of [  | - ]`
>>>>>>> +
>>>>>>> +> Default: `All available LLC colors`
>>>>>>> +
>>>>>>> +Specify dom0 LLC color configuration. This option is available only when
>>>>>>> +`CONFIG_LLC_COLORING` is enabled. If the parameter is not set, all available
>>>>>>> +colors are used.
>>>>>>
>>>>>> My reservation towards this being a top-level option remains.
>>>>>
>>>>> How can I turn this into a lower-level option? Moving it into "dom0=" doesn't
>>>>> seem possible to me. How can I express a list (llc-colors) inside another list
>>>>> (dom0)? dom0=llc-colors=0-3,12-15,other-param=... How can I stop parsing
>>>>> before reaching other-param?
>>>>
>>>> For example by using a different separator:
>>>>
>>>> dom0=llc-colors=0-3+12-15,other-param=...
>>>
>>> Ok, but that would mean to change the implementation of the parsing function
>>> and to adopt this syntax also in other places, something that I would've
>>> preferred to avoid. Anyway I'll follow your suggestion.
>>
>> Well, this is all used by Arm only for now. You will want to make sure Arm
>> folks are actually okay with this alternative approach.
>>
>> Jan
> 
> Are you Arm maintainers ok with this?

Unfortunately no. I find the use of + and "nested" = extremely confusing 
to read.

There might be other symbols to use (e.g. s/=/:/ s#+#/#), but I am not 
entirely sure the value of trying to cram all the options under a single 
top-level parameter. So I right now, I would prefrr if we stick with the 
existing approach (i.e. introducing dom0-llc-colors).

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Wed Mar 27 11:57:45 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 11:57:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698483.1090198 (Exim 4.92)
	(envelope-from )
	id 1rpRua-000146-Pi; Wed, 27 Mar 2024 11:57:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698483.1090198; Wed, 27 Mar 2024 11:57:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpRua-00013z-N0; Wed, 27 Mar 2024 11:57:44 +0000
Received: by outflank-mailman (input) for mailman id 698483;
 Wed, 27 Mar 2024 11:57:43 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpRuZ-00013p-JV
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 11:57:43 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on20600.outbound.protection.outlook.com
 [2a01:111:f403:2415::600])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3624c472-ec31-11ee-a1ef-f123f15fe8a2;
 Wed, 27 Mar 2024 12:57:41 +0100 (CET)
Received: from MW4PR03CA0092.namprd03.prod.outlook.com (2603:10b6:303:b7::7)
 by MN0PR12MB6317.namprd12.prod.outlook.com (2603:10b6:208:3c2::12) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.32; Wed, 27 Mar
 2024 11:57:37 +0000
Received: from MWH0EPF000971E3.namprd02.prod.outlook.com
 (2603:10b6:303:b7:cafe::5d) by MW4PR03CA0092.outlook.office365.com
 (2603:10b6:303:b7::7) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.13 via Frontend
 Transport; Wed, 27 Mar 2024 11:57:37 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 MWH0EPF000971E3.mail.protection.outlook.com (10.167.243.70) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Wed, 27 Mar 2024 11:57:37 +0000
Received: from SATLEXMB06.amd.com (10.181.40.147) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Wed, 27 Mar
 2024 06:57:35 -0500
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB06.amd.com
 (10.181.40.147) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Wed, 27 Mar
 2024 06:57:35 -0500
Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Wed, 27 Mar 2024 06:57:33 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3624c472-ec31-11ee-a1ef-f123f15fe8a2
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=AsILYJBxk0YUgwnLWZ7tQ7v5cAwt3uvC15Z0hcj5aTXqdhlLHcfATs0CxdveqDoddXD32GgiN5Xh9PWpewzOojlNafRFYNSGgAl1qL6vrnF9XpDk7pMNAuD87wG96DOv8T2vM0WCdlorC1CPTcRH2rV/O4kjhjyDxBqSsrvEvihHPvRgTRZa4LHnpyK3tU1VmD+FjdgbhSY4qIi3/xecRitR4pNOWgxtrk/nh50VJmRWujrrp3my8Lg6VaJ26Itg/AzU4YSUs/RvgC0r0uHKGV5DRdsYQ9vvMJO/z1ODwABzN8h0MfZ0YA6OylHPE0U7xOoEYJvG/dGLMRy9JuUPog==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=glkmBnGMe+O51lp+AmzEypqT5ZsbGA5Usg9YV4dFEks=;
 b=kSl1ts2Nj5HPmmQqEDSxJ9cRak8Ul2K1gWfR31aiCrg306MC14X+9wsSAJiVd8X4nnw3dohKRTBTXz1BoCXqixgkzsS5QYfPMhWjlCJI9opN3ozova47AdVT51MsvSNOoFP2pZeLPJlwFqDbrLY9SJqzVOBZrv4gmFxa88HwF1PkEToPIqUtLqxkOiUhdm2mYFcMUYC59wUh076dXnP7ubtE+Y/ybbc2mumuHqwGPfB8ekEZoIoTABRc7TOmPGLz+ze+D2c02rrii38RMM+NykKs+93NGqekmz3kuiRalmBvjaCj7oIb6NV1tiroF72x5k+nfutfQQARZ040U/UqEg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=minervasys.tech smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=glkmBnGMe+O51lp+AmzEypqT5ZsbGA5Usg9YV4dFEks=;
 b=mifdz35nn8vDrpTjdPdE6GcJZsgia41NynbWKCyJ+r3cc/Pj34HdxQuQhFwGBhpDXgdB0RqA9KjhS+eZPq06GNG5ikkMLMwR3ozeKjoDlCa6PuyOsFgWuiNgjJxyut93ASqB9px+WLnFNtARjnBP31QFTe2wx3I10rWCUTGlwA4=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Message-ID: <4cb543df-c763-48f7-b727-2af9a27bdca8@amd.com>
Date: Wed, 27 Mar 2024 12:57:32 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 04/14] xen/arm: add Dom0 cache coloring support
To: Carlo Nonato , Julien Grall
	, Bertrand Marquis , "Volodymyr
 Babchuk" , Stefano Stabellini
	
CC: Jan Beulich , Andrew Cooper
	, George Dunlap , "Wei
 Liu" , Marco Solieri ,
	, Andrea Bastoni
	
References: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
 <20240315105902.160047-5-carlo.nonato@minervasys.tech>
 
 
 <3ff10fdd-5a85-43b3-853a-fe69c7388ca9@suse.com>
 
 <22ab32bb-b0d0-4d68-8918-5fcb42cc0f88@suse.com>
 
Content-Language: en-US
From: Michal Orzel 
In-Reply-To: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: MWH0EPF000971E3:EE_|MN0PR12MB6317:EE_
X-MS-Office365-Filtering-Correlation-Id: d4a3bc01-04ce-4771-8175-08dc4e551899
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	V8scHIk6oGXywtYViKyLNzozj8hn1JiPhqLj5DLFE6yn7cIkixKCQ7+LNzi2mh95UUZ7iTeifz2cpA98s4fyNcSSE/d7Lp7IjLCvawGwWTI7lI4athY+HdDitqKGo2XPKaz11r45fimIn9s+T7q1FXuShfJQkAPrq8rsazLMOqsSken8R3sXBeb86jbs9i/JpzohPJzj8ymyWAdsYSx13hIC96AAoOv4MMO8nOM1trxCH8JQGaY+bKuW+F0bQypwC3XlIWqa7a2V8tQToiCkOKUB9qVvWi3RvoutlY2zr28G+rVtqvLYgQD73OP7VS75TGKA2Z9TAnmocAhouNOr2tXS75sE4Is1Qmr3slaITqkwl5l0NQJUvxo33Pmd+QtzM5pQn1cZ48TCB23qSFKw5rLypVwEDvtxWA+tqs3TcHjetmM+AcZyZEKnQS70tdGWttpqepRsKGcASrquZNbnthpo/Ef3ZukRCDX8ic921M/JXh0SvkBTTDKG8+ToE0+OmUV91IRMccCU452H14aGr1HbGzuSdk1jSwxN1DcIzHueALdlEn7galDPa675eQE9odvKKG5IenNE2V/RdKi73WAbP9vFry6Ri/TWMp62bzVazM7UVCuVisX/l3P/hLX/pLak5U+W/A/cwYfMvP23x6umuzeNSsFo77QG4Cxb2UOZbKyx3ePq9UaepobVLKqm9b+jmFaH/OCU8T0N/WWnAxVbbzZBGUysMThsf6rCWnsQTKs263RuDQJK/1DKDAd9
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(36860700004)(82310400014)(376005)(7416005)(1800799015);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Mar 2024 11:57:37.0105
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: d4a3bc01-04ce-4771-8175-08dc4e551899
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	MWH0EPF000971E3.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB6317



On 27/03/2024 12:39, Carlo Nonato wrote:
> 
> 
> Hi guys,
> 
> On Fri, Mar 22, 2024 at 8:26 AM Jan Beulich  wrote:
>>
>> On 21.03.2024 18:31, Carlo Nonato wrote:
>>> On Thu, Mar 21, 2024 at 4:57 PM Jan Beulich  wrote:
>>>>
>>>> On 21.03.2024 16:04, Carlo Nonato wrote:
>>>>> On Tue, Mar 19, 2024 at 4:30 PM Jan Beulich  wrote:
>>>>>> On 15.03.2024 11:58, Carlo Nonato wrote:
>>>>>>> --- a/docs/misc/xen-command-line.pandoc
>>>>>>> +++ b/docs/misc/xen-command-line.pandoc
>>>>>>> @@ -963,6 +963,15 @@ Controls for the dom0 IOMMU setup.
>>>>>>>
>>>>>>>  Specify a list of IO ports to be excluded from dom0 access.
>>>>>>>
>>>>>>> +### dom0-llc-colors
>>>>>>> +> `= List of [  | - ]`
>>>>>>> +
>>>>>>> +> Default: `All available LLC colors`
>>>>>>> +
>>>>>>> +Specify dom0 LLC color configuration. This option is available only when
>>>>>>> +`CONFIG_LLC_COLORING` is enabled. If the parameter is not set, all available
>>>>>>> +colors are used.
>>>>>>
>>>>>> My reservation towards this being a top-level option remains.
>>>>>
>>>>> How can I turn this into a lower-level option? Moving it into "dom0=" doesn't
>>>>> seem possible to me. How can I express a list (llc-colors) inside another list
>>>>> (dom0)? dom0=llc-colors=0-3,12-15,other-param=... How can I stop parsing
>>>>> before reaching other-param?
>>>>
>>>> For example by using a different separator:
>>>>
>>>> dom0=llc-colors=0-3+12-15,other-param=...
>>>
>>> Ok, but that would mean to change the implementation of the parsing function
>>> and to adopt this syntax also in other places, something that I would've
>>> preferred to avoid. Anyway I'll follow your suggestion.
>>
>> Well, this is all used by Arm only for now. You will want to make sure Arm
>> folks are actually okay with this alternative approach.
>>
>> Jan
> 
> Are you Arm maintainers ok with this?
I'm not a fan of this syntax and I find it more difficult to parse compared to the usual case, where
every option is clearly separated. That said, I won't oppose to it.

~Michal


From xen-devel-bounces@lists.xenproject.org Wed Mar 27 12:15:17 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 12:15:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698501.1090208 (Exim 4.92)
	(envelope-from )
	id 1rpSBQ-00064r-HD; Wed, 27 Mar 2024 12:15:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698501.1090208; Wed, 27 Mar 2024 12:15:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpSBQ-00064k-Dz; Wed, 27 Mar 2024 12:15:08 +0000
Received: by outflank-mailman (input) for mailman id 698501;
 Wed, 27 Mar 2024 12:15:07 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpSBP-00064c-Fe
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 12:15:07 +0000
Received: from sin.source.kernel.org (sin.source.kernel.org
 [2604:1380:40e1:4800::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a4a9fe4e-ec33-11ee-afe3-a90da7624cb6;
 Wed, 27 Mar 2024 13:15:06 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sin.source.kernel.org (Postfix) with ESMTP id 5EA1BCE178E;
 Wed, 27 Mar 2024 12:15:01 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1A77AC433F1;
 Wed, 27 Mar 2024 12:14:57 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a4a9fe4e-ec33-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1711541700;
	bh=TGBhXpvpwt3Sy3sv2afWOztmZwM+ykD/J2PKpMOqi3Y=;
	h=Subject:From:To:Cc:Date:From;
	b=PYfnWiDT6yaDffCHSBNbxd/CZkoZKj1v7nQKhcq6vzD0VwH0OXGv5VfOGgyBD8v90
	 qPS/mJPXlpPhOIP/niHhiwqrUUuy7iFAF5tDaoxYXOqlQAxob4/po+74o3HWUt8Y6q
	 rpZKtfaNZhR4jePfk7Z36DZq7ruT8yciszVfOSFQhudT+jKvdiIIMSBfGKWcx36tys
	 F4UQDnywU4BH0/TJqSXPpVoq+rnv68d7dUgRKXCngCUEWtKswYL9GWa96/O/mRhovJ
	 zLRenmEYeFHF+yPH1saJv1oWQ75ayKDq0vRsuPhfJKf4SaPo/YiVPGXhED/aVDoEYw
	 AfISea9uz1zRg==
Subject: [PATCH net] xen-netfront: Add missing skb_mark_for_recycle
From: Jesper Dangaard Brouer 
To: netdev@vger.kernel.org
Cc: Jesper Dangaard Brouer , arthurborsboom@gmail.com,
 Ilias Apalodimas , wei.liu@kernel.org,
 paul@xen.org, Jakub Kicinski , kirjanov@gmail.com,
 dkirjanov@suse.de, kernel-team@cloudflare.com, security@xenproject.org,
 andrew.cooper3@citrix.com, xen-devel@lists.xenproject.org
Date: Wed, 27 Mar 2024 13:14:56 +0100
Message-ID: <171154167446.2671062.9127105384591237363.stgit@firesoul>
User-Agent: StGit/1.5
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Notice that skb_mark_for_recycle() is introduced later than fixes tag in
6a5bcd84e886 ("page_pool: Allow drivers to hint on SKB recycling").

It is believed that fixes tag were missing a call to page_pool_release_page()
between v5.9 to v5.14, after which is should have used skb_mark_for_recycle().
Since v6.6 the call page_pool_release_page() were removed (in 535b9c61bdef
("net: page_pool: hide page_pool_release_page()") and remaining callers
converted (in commit 6bfef2ec0172 ("Merge branch
'net-page_pool-remove-page_pool_release_page'")).

This leak became visible in v6.8 via commit dba1b8a7ab68 ("mm/page_pool: catch
page_pool memory leaks").

Fixes: 6c5aa6fc4def ("xen networking: add basic XDP support for xen-netfront")
Reported-by: Arthur Borsboom 
Signed-off-by: Jesper Dangaard Brouer 
---
Compile tested only, can someone please test this

 drivers/net/xen-netfront.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index ad29f370034e..8d2aee88526c 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -285,6 +285,7 @@ static struct sk_buff *xennet_alloc_one_rx_buffer(struct netfront_queue *queue)
 		return NULL;
 	}
 	skb_add_rx_frag(skb, 0, page, 0, 0, PAGE_SIZE);
+	skb_mark_for_recycle(skb);
 
 	/* Align ip header to a 16 bytes boundary */
 	skb_reserve(skb, NET_IP_ALIGN);




From xen-devel-bounces@lists.xenproject.org Wed Mar 27 12:23:34 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 12:23:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698504.1090218 (Exim 4.92)
	(envelope-from )
	id 1rpSJW-0000Hw-9W; Wed, 27 Mar 2024 12:23:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698504.1090218; Wed, 27 Mar 2024 12:23:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpSJW-0000Hp-6t; Wed, 27 Mar 2024 12:23:30 +0000
Received: by outflank-mailman (input) for mailman id 698504;
 Wed, 27 Mar 2024 12:23:28 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpSJU-0000Hg-G4
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 12:23:28 +0000
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com
 [2a00:1450:4864:20::534])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d065724d-ec34-11ee-afe3-a90da7624cb6;
 Wed, 27 Mar 2024 13:23:27 +0100 (CET)
Received: by mail-ed1-x534.google.com with SMTP id
 4fb4d7f45d1cf-56bdf81706aso7072380a12.2
 for ; Wed, 27 Mar 2024 05:23:27 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 b4-20020a170906708400b00a46da83f7fdsm5402289ejk.145.2024.03.27.05.23.26
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 27 Mar 2024 05:23:26 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d065724d-ec34-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711542207; x=1712147007; darn=lists.xenproject.org;
        h=content-transfer-encoding:autocrypt:content-language:cc:to:subject
         :from:user-agent:mime-version:date:message-id:from:to:cc:subject
         :date:message-id:reply-to;
        bh=XbDiofXKsgUOJ3QRwntMggYbGvn7MzAkK+BbvwXgxQY=;
        b=IymYu4urze9FDdePyAAkVYwS1bEsQloHdj7+Z8F8mkwDNw2SSU23CA081vYCgWcb05
         GHCdQpkIzOhTWr9GXjhqmARfD8YKLGFchFwqG2qtaHP0zRLxX+0LOvQaYxMeG/CUdRNa
         ezLE6x8yc3hdx92OmQJ/kACal8A94F5FjHLD8YCko6F+ESDk6W4+xFgutMmxz2Bup/bt
         dwRqTbiQwtkHh5AZ7ooB804SAGtyzbz+a//Q0sayJKITlCuF59ZfxeFl7cLVhYccZOd5
         9TZmHN0shvm0dbuN+mL1a2J7hekU1ZrX4mVWRMEcPX+kLM/49IqEHZsf2+xU32bmkPcB
         QH+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711542207; x=1712147007;
        h=content-transfer-encoding:autocrypt:content-language:cc:to:subject
         :from:user-agent:mime-version:date:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=XbDiofXKsgUOJ3QRwntMggYbGvn7MzAkK+BbvwXgxQY=;
        b=VsMUDsJiPDKlHiVEbHx12YUl6dthuKtOeWWL7/zJSc1v7++7JGhQL5PB0wTMUwiAfG
         oPus4kGKTq1V1wViVaDw+nus/zGl8ad/QmIXDBBwEkP8vvQ22zE+0hbsp+vZtcrXdpOF
         R0q0EwFANKQ/XpcejlR2eIG65fSzDLwY5zUtavlZImuCEIJpdTnnXnrhJS25jQFyHmoz
         5sp61d1kIC+uD4wv1ULIRKvAPbjhLF8Rcgg2eRyF2+dOBbRf/oC5PwdmhExBh2vGhZ4s
         67Bq96oUlqb/O50naD8eOu6jxjKjdm5jdnycP589G/sJxw90VInxTG/ljfd9XMdnsLkO
         cyZA==
X-Gm-Message-State: AOJu0YzQ1pmCUQ2KWpZYMqZTdaSIxcGSSiP04hvZ295PVAj+ZdnnC4pi
	n5VKWSf6PxHbH+V7kICPtzCiGmYv2ll+Y5r7/1lVRWX1a9u56qfO3DFuGsHyyf7ejomMkQQqLAI
	=
X-Google-Smtp-Source: AGHT+IHiV1L9t+2F8KhjOtx7V2MPZxqy0FYpfaQoqHpw1PtiQd4p2gBVErG8JHo2cnfT5z1K5yNotg==
X-Received: by 2002:a17:906:5918:b0:a4d:f927:f747 with SMTP id h24-20020a170906591800b00a4df927f747mr2511928ejq.4.1711542206853;
        Wed, 27 Mar 2024 05:23:26 -0700 (PDT)
Message-ID: 
Date: Wed, 27 Mar 2024 13:23:25 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Jan Beulich 
Subject: preparations for 4.17.4
To: "xen-devel@lists.xenproject.org" 
Cc: Stefano Stabellini ,
 Anthony Perard , Julien Grall ,
 Kelly Choi 
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

All,

the release is due in two to three weeks. Please point out backports you find
missing from the respective staging branch, but which you consider relevant.

Note that this is going to be the last Xen Project coordinated ordinary stable
release from this branch; the branch will move into security-only support mode
afterwards.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Mar 27 12:33:52 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 12:33:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698507.1090228 (Exim 4.92)
	(envelope-from )
	id 1rpSTM-0002v5-5r; Wed, 27 Mar 2024 12:33:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698507.1090228; Wed, 27 Mar 2024 12:33:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpSTM-0002uy-2y; Wed, 27 Mar 2024 12:33:40 +0000
Received: by outflank-mailman (input) for mailman id 698507;
 Wed, 27 Mar 2024 12:33:38 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpSTK-0002us-Hw
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 12:33:38 +0000
Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com
 [2607:f8b0:4864:20::f35])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3b13288c-ec36-11ee-a1ef-f123f15fe8a2;
 Wed, 27 Mar 2024 13:33:36 +0100 (CET)
Received: by mail-qv1-xf35.google.com with SMTP id
 6a1803df08f44-690cf6ecd3cso38435146d6.2
 for ; Wed, 27 Mar 2024 05:33:36 -0700 (PDT)
Received: from [10.80.67.139] (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 13-20020a05621420cd00b00690c5ec348bsm6268848qve.119.2024.03.27.05.33.33
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 27 Mar 2024 05:33:34 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3b13288c-ec36-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1711542815; x=1712147615; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=JxczMfJ30z2VHDAbpCr4xN7ytkIAvD8zwwS4d1Qj5GE=;
        b=a95VkbSpeiskwmJDQ0QSVWti8hua+lMMKXWjmjMeWOE30xEWEvk2iPmibCNufYXJlY
         JAIe/sDzbbIToEGqvhm8pB3l80NTbKLEDAzd4nNlRqrKH8yKCIfL1r4OBIuqG41RHltk
         QnM+QvWZ5avBC9CyTAQxwQYQF1OZ9fW0kcE74=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711542815; x=1712147615;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=JxczMfJ30z2VHDAbpCr4xN7ytkIAvD8zwwS4d1Qj5GE=;
        b=DnseV+oI1YUSTOhM1Ah+FhY4wzRKYDAI41K9fPtvAmwI6P8Bv4XDVMhL2aBKoWizpl
         6wv094V1J0srSnmDYTB67653c0/bwymU2xWTMEbJI0zRdEmZcyVnWskQ7GFoaGJbSsUO
         +sV/KCiGQOCf2JUA5arvA1lMj23GAlWrMNJ8g8chKONkhoyyKpl8wDa/ffnlQVV/dD72
         780xi/HGJytik/ulJ8IzjIVI1iNLSiM7QnH/zHY7iAgqZsjNphZ5oS/b9DiIF5UB87Px
         IVX2505dGs5CkLQUbsPj6vX4XxIyR44ijmo1CwFeRMxaePYGGZI7pBZgeNC8z+m9c/DP
         cmbA==
X-Forwarded-Encrypted: i=1; AJvYcCXkttQdfQxZHuLG2GkLy0KiArpMehieKDtlAEiEpHfL+ONdByCqWbdrHTDA1rgD4X70/ZW6I0P+OeRJ+ba0+kR3jm8b1a9nhPSbC9VBleE=
X-Gm-Message-State: AOJu0YxwHMOTlqYocdUHo39pDuD5pHqZOWh9yN0YzoE7fLw0ErlvDsZw
	WXDfPkKzTYARUOENxwUGHcsHn0BsZ3/aCEJu5Ngs9zlKMgeJTiT80KLojqG1YEo=
X-Google-Smtp-Source: AGHT+IGFGB+nqrpXGfsZ0Lmeg62QLftDsGTFgXKRDHD6E/K1N0AO5OC3ZhbAJ8u5oetKQtzsFwHqgw==
X-Received: by 2002:a05:6214:186b:b0:696:ae51:3644 with SMTP id eh11-20020a056214186b00b00696ae513644mr1200512qvb.11.1711542815286;
        Wed, 27 Mar 2024 05:33:35 -0700 (PDT)
Message-ID: <6feb56fe-769d-4809-b16f-6fc4d5477747@citrix.com>
Date: Wed, 27 Mar 2024 12:33:32 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: preparations for 4.17.4
To: Jan Beulich ,
 "xen-devel@lists.xenproject.org" 
Cc: Stefano Stabellini ,
 Anthony Perard , Julien Grall ,
 Kelly Choi 
References: 
Content-Language: en-GB
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 27/03/2024 12:23 pm, Jan Beulich wrote:
> All,
>
> the release is due in two to three weeks. Please point out backports you find
> missing from the respective staging branch, but which you consider relevant.
>
> Note that this is going to be the last Xen Project coordinated ordinary stable
> release from this branch; the branch will move into security-only support mode
> afterwards.

1) livepatching of .rodata:

989556c6f8ca - xen/virtual-region: Rename the start/end fields
ef969144a425 - xen/virtual-region: Include rodata pointers
b083b1c393dc - x86/livepatch: Relax permissions on rodata too

And technically "x86/mm: fix detection of last L1 entry in
modify_xen_mappings_lite()" too but you've already backported this one.

Patching .rodata worked before Xen 4.17, and was broken (left as a TODO)
when I adjusted Xen to stop using CR0.WP=0 for patching.


2) Policy fixes:

e2d8a6522516 - x86/cpu-policy: Fix visibility of HTT/CMP_LEGACY in max
policies

This is a real bugfix for a real regression we found updating from Xen
4.13 -> 4.17.  It has a dependency on

5420aa165dfa - x86/cpu-policy: Hide x2APIC from PV guests

which I know you had more concern with.  FWIW, I'm certain its a good
fix, and should be backported.


3) Test fixes:

0263dc9069dd - tests/resource: Fix HVM guest in !SHADOW builds

It's minor, but does make a difference for those of us who run these
tests regularly.


4) Watchdog fixes:

9e18f339830c - x86/boot: Improve the boot watchdog determination of
stuck cpus
131892e0dcc1 - x86/boot: Support the watchdog on newer AMD systems

You took "x86/boot: Fix setup_apic_nmi_watchdog() to fail more cleanly"
and the first of the two patches is in the same category IMO.  The
second I also feel ok to take for the in-support releases, particularly
as all it is doing is dropping a family list.


5) Ucode scan stability  (For 4.18 only)

Xen 4.18 had "x86/ucode: Refresh raw CPU policy after microcode load" in
it's .0 release, so should also gain:

cf7fe8b72dea - x86/ucode: Fix stability of the raw CPU Policy rescan

I've only noticed because I've got them both backported to 4.17 in
XenServer, but I don't think upstream wants to take that route.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Mar 27 12:57:44 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 12:57:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698511.1090238 (Exim 4.92)
	(envelope-from )
	id 1rpSqU-0007TD-2Y; Wed, 27 Mar 2024 12:57:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698511.1090238; Wed, 27 Mar 2024 12:57:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpSqT-0007T6-Vk; Wed, 27 Mar 2024 12:57:33 +0000
Received: by outflank-mailman (input) for mailman id 698511;
 Wed, 27 Mar 2024 12:52:36 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpSlg-0007Oj-K3
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 12:52:36 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de
 [2a07:de40:b251:101:10:150:64:1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e1c6cd9d-ec38-11ee-afe3-a90da7624cb6;
 Wed, 27 Mar 2024 13:52:34 +0100 (CET)
Received: from imap2.dmz-prg2.suse.org (imap2.dmz-prg2.suse.org [10.150.64.98])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id 04C9B21C16;
 Wed, 27 Mar 2024 12:52:34 +0000 (UTC)
Received: from imap2.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap2.dmz-prg2.suse.org (Postfix) with ESMTPS id 6393713AB3;
 Wed, 27 Mar 2024 12:52:33 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap2.dmz-prg2.suse.org with ESMTPSA id vJfwFJEWBGZKOAAAn2gu4w
 (envelope-from ); Wed, 27 Mar 2024 12:52:33 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e1c6cd9d-ec38-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1711543954; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=4uTJ3ZkxHMF5Lg7sxSMlW6kd+Qw7Xng5HTdbxK7Wof4=;
	b=lRo4EXOIZ0PFCRxj97ASMDb/92D87kAW1uMhrsUyPi3Tb/JtWPRWjSK4rv+YvAJydIVWby
	S8TKicLKe3hgL5/cstTHth+vz1FCcvzJlOFLTmj8yj/X8bzEEXhdkfws9o7OQy75msj8Fu
	uIVfPY5JwPnfzfSy/oPCitnCP37uL4k=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1711543954;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=4uTJ3ZkxHMF5Lg7sxSMlW6kd+Qw7Xng5HTdbxK7Wof4=;
	b=BNhwN7gUTUyBZchNrbOCuZwfLkjsvj84qBA8S45AW8T3PMb+SrJI0oyxpwY2VjTPu/5xkr
	q/4tH6HdOHnKJqAA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1711543954; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=4uTJ3ZkxHMF5Lg7sxSMlW6kd+Qw7Xng5HTdbxK7Wof4=;
	b=lRo4EXOIZ0PFCRxj97ASMDb/92D87kAW1uMhrsUyPi3Tb/JtWPRWjSK4rv+YvAJydIVWby
	S8TKicLKe3hgL5/cstTHth+vz1FCcvzJlOFLTmj8yj/X8bzEEXhdkfws9o7OQy75msj8Fu
	uIVfPY5JwPnfzfSy/oPCitnCP37uL4k=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1711543954;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=4uTJ3ZkxHMF5Lg7sxSMlW6kd+Qw7Xng5HTdbxK7Wof4=;
	b=BNhwN7gUTUyBZchNrbOCuZwfLkjsvj84qBA8S45AW8T3PMb+SrJI0oyxpwY2VjTPu/5xkr
	q/4tH6HdOHnKJqAA==
Message-ID: 
Date: Wed, 27 Mar 2024 15:52:23 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Xen NIC driver have page_pool memory leaks
To: Jesper Dangaard Brouer , paul@xen.org,
 Arthur Borsboom ,
 Ilias Apalodimas 
Cc: Netdev , Wei Liu ,
 "xen-devel@lists.xenproject.org" ,
 kda@linux-powerpc.org
References: 
 <1cde0059-d319-4a4f-a68d-3b3ffeb3da20@kernel.org>
 <857282f5-5df6-4ed7-b17e-92aae0cf484a@xen.org>
 
Content-Language: en-US
From: Denis Kirjanov 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -1.29
X-Spamd-Result: default: False [-1.29 / 50.00];
	 ARC_NA(0.00)[];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 XM_UA_NO_VERSION(0.01)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_ENVRCPT(0.00)[gmail.com];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	 NEURAL_HAM_SHORT(-0.20)[-0.999];
	 RCPT_COUNT_SEVEN(0.00)[8];
	 FREEMAIL_TO(0.00)[kernel.org,xen.org,gmail.com,linaro.org];
	 FUZZY_BLOCKED(0.00)[rspamd.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 RCVD_TLS_ALL(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[]
X-Spam-Level: 
Authentication-Results: smtp-out1.suse.de;
	none
X-Spam-Flag: NO



On 3/27/24 14:27, Jesper Dangaard Brouer wrote:
> 
> 
> On 25/03/2024 13.33, Paul Durrant wrote:
>> On 25/03/2024 12:21, Jesper Dangaard Brouer wrote:
>>> Hi Arthur,
>>>
>>> (Answer inlined below, which is custom on this mailing list)
>>>
>>> On 23/03/2024 14.23, Arthur Borsboom wrote:
>>>> Hi Jesper,
>>>>
>>>> After a recent kernel upgrade 6.7.6 > 6.8.1 all my Xen guests on Arch
>>>> Linux are dumping kernel traces.
>>>> It seems to be indirectly caused by the page pool memory leak
>>>> mechanism, which is probably a good thing.
>>>>
>>>> I have created a bug report, but there is no response.
>>>>
>>>> https://bugzilla.kernel.org/show_bug.cgi?id=218618
>>>>
>>>> I am uncertain where and to whom I need to report this page leak.
>>>> Can you help me get this issue fixed?
>>>
>>> I'm the page_pool maintainer, but as you say yourself in comment 2 then
>>> since dba1b8a7ab68 ("mm/page_pool: catch page_pool memory leaks") this
>>> indicated there is a problem in the xen_netfront driver, which was
>>> previously not visible.
>>>
>>> Cc'ing the "XEN NETWORK BACKEND DRIVER" maintainers, as this is a driver
>>> bug.  What confuses me it that I cannot find any modules named
>>> "xen_netfront" in the upstream tree.
>>>
>>
>> You should have tried '-' rather than '_' :-)
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/xen-netfront.c
>>
> 
> Looking at this driver, I think it is missing a call to skb_mark_for_recycle().
> 
> I'll will submit at patch for this, with details for stable maintainers.

Please do

> 
> As I think it dates back to v5.9 via commit 6c5aa6fc4def ("xen
> networking: add basic XDP support for xen-netfront"). I think this
> commit is missing a call to page_pool_release_page()
> between v5.9 to v5.14, after which is should have used
> skb_mark_for_recycle().

Hmm, looks like I've missed it  
> 
> Since v6.6 the call page_pool_release_page() were removed (in
> 535b9c61bdef ("net: page_pool: hide page_pool_release_page()") and
> remaining callers converted (in commit 6bfef2ec0172 ("Merge branch
> 'net-page_pool-remove-page_pool_release_page'")).
> 
> This leak became visible in v6.8 via commit dba1b8a7ab68 ("mm/page_pool:
> catch page_pool memory leaks").
> 
> --Jesper
> 


From xen-devel-bounces@lists.xenproject.org Wed Mar 27 13:29:06 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 13:29:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698515.1090248 (Exim 4.92)
	(envelope-from )
	id 1rpTKu-0004sR-Ee; Wed, 27 Mar 2024 13:29:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698515.1090248; Wed, 27 Mar 2024 13:29:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpTKu-0004sK-C1; Wed, 27 Mar 2024 13:29:00 +0000
Received: by outflank-mailman (input) for mailman id 698515;
 Wed, 27 Mar 2024 13:28:59 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1rpTKt-0004sE-2d
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 13:28:59 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpTKq-0006l9-45; Wed, 27 Mar 2024 13:28:56 +0000
Received: from [15.248.2.236] (helo=[10.24.67.40])
 by xenbits.xenproject.org with esmtpsa
 (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92)
 (envelope-from )
 id 1rpTKp-0001YL-Om; Wed, 27 Mar 2024 13:28:55 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=nfipTNjtdIqZgnpKZlw06oTnjnR7wsrY45CKHb2kN0A=; b=aEQX10qpPqLsW46sRbcQHS6kjl
	XO0VqztlTO223BHYkpEfnctXSg6zha88ve6Fa4cm+QQTiUxiMbVuoU7DMBHltEzjxlfATsjcLTIJZ
	BNP7WWEighMq5k5tjlcmwSzbYK6xahoWiLIKObBVFSoS99jaWNNutrDuiIU7jsrGx7m4=;
Message-ID: <54156e94-3630-49b1-8a22-5cd4206d565f@xen.org>
Date: Wed, 27 Mar 2024 13:28:53 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 08/14] xen/page_alloc: introduce preserved page flags
 macro
Content-Language: en-GB
To: Carlo Nonato ,
 Jan Beulich 
Cc: Andrew Cooper ,
 George Dunlap ,
 Stefano Stabellini , Wei Liu ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
 <20240315105902.160047-9-carlo.nonato@minervasys.tech>
 <3f615066-a792-493f-ba33-7667a6557c23@xen.org>
 <9e0f7ff3-5457-41e4-a1e4-bf75804fb900@xen.org>
 <255be735-f9fe-4e39-a24e-2f6aff91acc5@suse.com>
 
 <3427132d-9458-4447-b667-d2ef3c1f0569@suse.com>
 
 
 
 
From: Julien Grall 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Carlo,

On 27/03/2024 11:10, Carlo Nonato wrote:
> Hi guys,
> 
>> Question is: How would you justify such a change? IOW I'm not convinced
>> (yet) this wants doing there.
> 
> You mean in this series?
> 
>> Looking at the code, the flag is originally set in
>> alloc_domheap_pages(). So I guess it would make sense to do it in
>> free_domheap_pages().
> 
> We don't hold the heap_lock there.
Regardless of the safety question (I will answer below), count_info is 
not meant to be protected by heap_lock. The lock is protecting the heap 
and ensure we are not corrupting them when there are concurrent call to 
free_heap_pages().

 > Is it safe to change count_info without it?

count_info is meant to be accessed locklessly. The flag PGC_extra cannot 
be set/clear concurrently because you can't allocate a page that has not 
yet been freed.

So it would be fine to use clear_bit(..., ...);

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Wed Mar 27 13:31:57 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 13:31:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698519.1090258 (Exim 4.92)
	(envelope-from )
	id 1rpTNk-0006nK-VX; Wed, 27 Mar 2024 13:31:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698519.1090258; Wed, 27 Mar 2024 13:31:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpTNk-0006nD-Rp; Wed, 27 Mar 2024 13:31:56 +0000
Received: by outflank-mailman (input) for mailman id 698519;
 Wed, 27 Mar 2024 13:31:55 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpTNj-0006fw-Ji
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 13:31:55 +0000
Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com
 [2a00:1450:4864:20::330])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 601a0796-ec3e-11ee-a1ef-f123f15fe8a2;
 Wed, 27 Mar 2024 14:31:54 +0100 (CET)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-414953ec671so3173415e9.1
 for ; Wed, 27 Mar 2024 06:31:54 -0700 (PDT)
Received: from perard.uk.xensource.com (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 j28-20020a05600c1c1c00b00414807ef8dfsm2209230wms.5.2024.03.27.06.31.52
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 27 Mar 2024 06:31:52 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 601a0796-ec3e-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1711546313; x=1712151113; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=ry50isKBz7xwB9eIS98LGGV6NnwE9fBPbss1bZmyVbc=;
        b=SFA/0T9aA1TvfXcJEhNKDiPqd7DpgKVqjIEAFSMdGF3o1rTz/NyRHLE+bGwM7eSYhm
         H7HUILFYZCSlkRXHwBzUbEhZ8jILuYPinQFu76pm/wOe/BSf5coYHkl9CWX+8EhrblPy
         9qquWRZfWW5BXtZqMSh12xtEiF039hL8gfKP4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711546313; x=1712151113;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=ry50isKBz7xwB9eIS98LGGV6NnwE9fBPbss1bZmyVbc=;
        b=YrITy1Ap6/qmi8FEmSl11p2n3pxwuhoNSywxtxkIVUtPlr+MmPkrZWb4ZtEf1CGe/x
         2jVqtan3O4HjaJq8iEMieCA/8Q3RY0obciFlXWTkXDMmFWofuT5V0/Tbcoh8liVJjKEh
         k9+Enl+S0/0e4FOmRST3vKnqdbz4VFh3w2SThlNBAG5WRAO+NUetuET9Jom6zvMkgW7+
         gAH0W5f5hnqA24wc/yu/fbiyl3sBmEseSkLInexZi+ThAT/OsQoyClAualRUa7Dacg5n
         vRZd/o58vByvlECxK9z208cBeFfTublMMN6PHFLVV18BwiEF8onmxo0QakGr7pS6dZ5G
         hNhg==
X-Forwarded-Encrypted: i=1; AJvYcCVT4uz9YF4svnLXD2HsbIqroGcz7r1/cYXayGtMN7IvEt48CosZvG3yuYyRCsGNtfMhrcZeJevzAyHN5tvW2LmttrAD7YPNZljfvlLXCXI=
X-Gm-Message-State: AOJu0YwZFhvbvLZjJWcsLrR1/GlgyiXe9hhXbqa1AJ+jCNN+tMatk2zq
	Ikhq8qzgBmsdxUodqbh/asaE4MTYXf6urR0Plal/wa5aPgnyJQm7UCh5Wzq29R0=
X-Google-Smtp-Source: AGHT+IFYIuYEr12t4v0Td8b3I1GnsgGQezqwN6hoZoxCPeltmyQmrmwtG5G0fLSfp8l9b6esrVdj4Q==
X-Received: by 2002:a05:600c:198a:b0:414:8d7:8292 with SMTP id t10-20020a05600c198a00b0041408d78292mr52993wmq.0.1711546313427;
        Wed, 27 Mar 2024 06:31:53 -0700 (PDT)
Date: Wed, 27 Mar 2024 13:31:52 +0000
From: Anthony PERARD 
To: Philippe =?iso-8859-1?Q?Mathieu-Daud=E9?= 
Cc: David Woodhouse , qemu-devel@nongnu.org,
	Alex =?iso-8859-1?Q?Benn=E9e?= ,
	Paul Durrant , qemu-arm@nongnu.org,
	Paolo Bonzini ,
	David Woodhouse ,
	Stefano Stabellini ,
	Richard Henderson ,
	xen-devel@lists.xenproject.org, qemu-block@nongnu.org,
	kvm@vger.kernel.org, Thomas Huth ,
	Kevin Wolf , Hanna Reitz 
Subject: Re: [RFC PATCH-for-9.0 v2 09/19] hw/block/xen_blkif: Align structs
 with QEMU_ALIGNED() instead of #pragma
Message-ID: <76ae46e6-c226-49d0-890e-c8fd64172569@perard>
References: <20231114143816.71079-1-philmd@linaro.org>
 <20231114143816.71079-10-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20231114143816.71079-10-philmd@linaro.org>

On Tue, Nov 14, 2023 at 03:38:05PM +0100, Philippe Mathieu-Daud wrote:
> Except imported source files, QEMU code base uses
> the QEMU_ALIGNED() macro to align its structures.

This patch only convert the alignment, but discard pack. We need both or
the struct is changed.

> ---
>  hw/block/xen_blkif.h | 8 +++-----
>  1 file changed, 3 insertions(+), 5 deletions(-)
> 
> diff --git a/hw/block/xen_blkif.h b/hw/block/xen_blkif.h
> index 99733529c1..c1d154d502 100644
> --- a/hw/block/xen_blkif.h
> +++ b/hw/block/xen_blkif.h
> @@ -18,7 +18,6 @@ struct blkif_common_response {
>  };
>  
>  /* i386 protocol version */
> -#pragma pack(push, 4)
>  struct blkif_x86_32_request {
>      uint8_t        operation;        /* BLKIF_OP_???                         */
>      uint8_t        nr_segments;      /* number of segments                   */
> @@ -26,7 +25,7 @@ struct blkif_x86_32_request {
>      uint64_t       id;               /* private guest value, echoed in resp  */
>      blkif_sector_t sector_number;    /* start sector idx on disk (r/w only)  */
>      struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> -};
> +} QEMU_ALIGNED(4);

E.g. for this one, I've compare the output of
`pahole --class_name=blkif_x86_32_request build/qemu-system-i386`:

--- before
+++ after
@@ -1,11 +1,15 @@
 struct blkif_x86_32_request {
 	uint8_t                    operation;            /*     0     1 */
 	uint8_t                    nr_segments;          /*     1     1 */
 	uint16_t                   handle;               /*     2     2 */
-	uint64_t                   id;                   /*     4     8 */
-	uint64_t                   sector_number;        /*    12     8 */
-	struct blkif_request_segment seg[11];            /*    20    88 */

-	/* size: 108, cachelines: 2, members: 6 */
-	/* last cacheline: 44 bytes */
-} __attribute__((__packed__));
+	/* XXX 4 bytes hole, try to pack */
+
+	uint64_t                   id;                   /*     8     8 */
+	uint64_t                   sector_number;        /*    16     8 */
+	struct blkif_request_segment seg[11];            /*    24    88 */
+
+	/* size: 112, cachelines: 2, members: 6 */
+	/* sum members: 108, holes: 1, sum holes: 4 */
+	/* last cacheline: 48 bytes */
+} __attribute__((__aligned__(8)));

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Wed Mar 27 13:32:05 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 13:32:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698520.1090268 (Exim 4.92)
	(envelope-from )
	id 1rpTNt-00075S-5u; Wed, 27 Mar 2024 13:32:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698520.1090268; Wed, 27 Mar 2024 13:32:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpTNt-00075L-2z; Wed, 27 Mar 2024 13:32:05 +0000
Received: by outflank-mailman (input) for mailman id 698520;
 Wed, 27 Mar 2024 13:32:03 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpTNr-00074Q-56
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 13:32:03 +0000
Received: from EUR04-DB3-obe.outbound.protection.outlook.com
 (mail-db3eur04on0630.outbound.protection.outlook.com
 [2a01:111:f400:fe0c::630])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 64f0afb8-ec3e-11ee-afe3-a90da7624cb6;
 Wed, 27 Mar 2024 14:32:02 +0100 (CET)
Received: from AS9PR06CA0655.eurprd06.prod.outlook.com (2603:10a6:20b:46f::23)
 by PAVPR08MB9860.eurprd08.prod.outlook.com (2603:10a6:102:2f4::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.31; Wed, 27 Mar
 2024 13:31:51 +0000
Received: from AMS0EPF00000198.eurprd05.prod.outlook.com
 (2603:10a6:20b:46f:cafe::14) by AS9PR06CA0655.outlook.office365.com
 (2603:10a6:20b:46f::23) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.13 via Frontend
 Transport; Wed, 27 Mar 2024 13:31:51 +0000
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by
 AMS0EPF00000198.mail.protection.outlook.com (10.167.16.244) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.7409.10 via Frontend Transport; Wed, 27 Mar 2024 13:31:50 +0000
Received: ("Tessian outbound 9b7417e2a8eb:v300");
 Wed, 27 Mar 2024 13:31:50 +0000
Received: from 5e7968fe18d6.1
 by 64aa7808-outbound-1.mta.getcheckrecipient.com id
 1E4575F4-CAA9-4E33-8CF4-C8ED2874F09E.1; 
 Wed, 27 Mar 2024 13:31:44 +0000
Received: from EUR03-DBA-obe.outbound.protection.outlook.com
 by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 5e7968fe18d6.1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384);
 Wed, 27 Mar 2024 13:31:44 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com (2603:10a6:10:25a::24)
 by DU0PR08MB10365.eurprd08.prod.outlook.com (2603:10a6:10:40b::7)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.31; Wed, 27 Mar
 2024 13:31:40 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::7fb0:6621:56b:22d5]) by DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::7fb0:6621:56b:22d5%3]) with mapi id 15.20.7409.031; Wed, 27 Mar 2024
 13:31:40 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 64f0afb8-ec3e-11ee-afe3-a90da7624cb6
ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass;
 b=GTfuLr0lcu2vCPSImIz7ux+2ecz40YVN/ogDKV/x6g9ZbfL9FTHyhRTCchZwUW1Olxg4gFDxkvFAk0byklAHkLx7O6XhngvMqN8YR9f6SrDz/xcf62V4l4t2udVcd9wXc4KgxW6BH1F9Ewkh4BQOFh58TM2WR9o2Q5rxSOeRPwDFtuL6aGbMxb9B1qgubCpP08RDbZhenT8l39/i95Z5aiRRd6Akd299ZqUYzkgnF7RXe9IoWrwnDcsULzCG1y6CQSc3iMjo2D9i8No6CPuD4+ZpA/iL1AgYhqsdUuyfZIZ9nzcTSK4IztIrBXekZZEowjM2FaBCABUnEIVwkPxE6A==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=27Wcir1lIebZdaz3UTVKwTNNDstzA0GpTo7Lw7N4n1g=;
 b=mnSuWqfjQ8D/z1dkckJeKsbuiHSDJmozDskSAhamEgWBYnEG7OCApkEShEwPBvHdgD+PlCQiOgQt7IO8EAe9kxBgpWGlk4DqOst7LzaUeHbJwtLuorEXiDrhfXc7nCiahdyZyT/anp//c6vzhY2+3kCN00rl/jXeWkpKSecuLp7zPqqiWuBpSS9pZX19P9HByWQetOk8MeaanxYBczZH2LkVoAY6NqO+MpDSXD7pRzRZ0Ok6clkpMIcx5duqIoT0J7I5R+Hfq6alf5kHBXlZvy+yzM1y/V93LoVTSup0BEJcmZVIxbdjAXziVZC/mzUAIDbQ+A3pjQo4lk/ql1NM0Q==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 63.35.35.123) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=arm.com;
 dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com;
 dkim=pass (signature was verified) header.d=armh.onmicrosoft.com; arc=pass (0
 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com]
 dmarc=[1,1,header.from=arm.com])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com;
 s=selector2-armh-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=27Wcir1lIebZdaz3UTVKwTNNDstzA0GpTo7Lw7N4n1g=;
 b=JfrTdPSN7e/topHC0mr8eyOBumLzp/2GqesQmBbJDAS1WdoZK9G27FK85gPu5VUdX1C9AUtK6YIXwacTHh5f4lmgwxJ5QoVgyOQb7LIB4a/GBnGpLfM5d4tnxrUA1/qwNGD2SlBLIyIz1S81oNjZpS5DHkkgaMVm6GcH+aQ1T7M=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=armh.onmicrosoft.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 63.35.35.123 as permitted sender) receiver=protection.outlook.com;
 client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
 pr=C
X-CheckRecipientChecked: true
X-CR-MTA-CID: 03977261528c8145
X-CR-MTA-TID: 64aa7808
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=JukT32kj0CHIr8J1t9Dg9yeQAroR96y6f8xNDQtklfj7xCJWOI9NUN1Fe89fxylxts6sxyFSZ88gCmvJSuPqi0eaW6hvR5dyiE6eH9lJpih8cgfeovqzLOkorqsRnj4SQV2YauZPxQ0ULn9p2FlRdP4kVINiPtAAqVXt0LmVBUpLCSPsKHotJsnssoroepfzJErC0xL6Vi9SjyRPkwIoS67+6fH/CyFt3OatxwSHfExR4zcCkrXKW9m2jGYnXJpjR2o+c8Vja1Ca3jKmQh6FlnJSeZCFI8fqB2wejyeprTxwYkzQcQLA+ZPbXicH5Wog4EkSW0Bivp4BBbgCcwKf2Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=27Wcir1lIebZdaz3UTVKwTNNDstzA0GpTo7Lw7N4n1g=;
 b=XEKekMJ5M5jHkM3H/G3tFEVZmVGZKjqPEenFrrGwAMXWH8WOAsCenPg3Z5ys3Zyhgvplzc3bCNCELAKbwEBIsqlXpJMvdl8pz3CAc7ioEx7iaOfTv1SqXHl94z+2CpcJwHkhlKrYIcubRqBAeW2slFldcTY1smGQIoEY4EsiwURzEQnN/SWqSGQRc/VAIf9+JxOjG3TgW2uV8/4YPBwoJibJl/eB8qx9YmwfRK0SG89B5SDv2m2ejQ80aN85JnvCZipVABBE1zqck0hgsfFhxRATJSKYCnd+c8VFWDtGGQ69fv6uaQ6jU37tzVNrDK8Ib7xbKdNWullLC5oUTPphmA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass
 header.d=arm.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com;
 s=selector2-armh-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=27Wcir1lIebZdaz3UTVKwTNNDstzA0GpTo7Lw7N4n1g=;
 b=JfrTdPSN7e/topHC0mr8eyOBumLzp/2GqesQmBbJDAS1WdoZK9G27FK85gPu5VUdX1C9AUtK6YIXwacTHh5f4lmgwxJ5QoVgyOQb7LIB4a/GBnGpLfM5d4tnxrUA1/qwNGD2SlBLIyIz1S81oNjZpS5DHkkgaMVm6GcH+aQ1T7M=
From: Bertrand Marquis 
To: Jens Wiklander 
CC: Xen-devel , "patches@linaro.org"
	, Volodymyr Babchuk , Stefano
 Stabellini , Julien Grall , Michal
 Orzel 
Subject: Re: [XEN PATCH 1/6] xen/arm: ffa: rename functions to use ffa_ prefix
Thread-Topic: [XEN PATCH 1/6] xen/arm: ffa: rename functions to use ffa_
 prefix
Thread-Index: AQHafphXKCJs/9w9PkiuEvBYvK9zqbFLmPWA
Date: Wed, 27 Mar 2024 13:31:40 +0000
Message-ID: 
References: <20240325093904.3466092-1-jens.wiklander@linaro.org>
 <20240325093904.3466092-2-jens.wiklander@linaro.org>
In-Reply-To: <20240325093904.3466092-2-jens.wiklander@linaro.org>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3774.200.91.1.1)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DB9PR08MB6588:EE_|DU0PR08MB10365:EE_|AMS0EPF00000198:EE_|PAVPR08MB9860:EE_
X-MS-Office365-Filtering-Correlation-Id: 4296d025-cf61-4649-8685-08dc4e624280
x-checkrecipientrouted: true
nodisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted: BCL:0;
X-Microsoft-Antispam-Message-Info-Original:
 EV9FAzzdm3zggf1Zh4zqGThZ37SCV6KcHsxR8iUTALKjQftx7JK1W7i6yEbQIovCgibmgbYfZzVHIIwcUqzfh0N6ZqWxnayo7xqb4Tw1/fdOGHuZqLCdjFmlBgdp1yhZOQroNhbbDTlok8y3kT7EFdKQtJRWwIInbZjs27cMHhT3zKhSpZ7kyBDKVZ3Ltv2zmvv9xJxbBMa7lx8mxcYb/Hso5C75pp8FfbPR1ya5iNJ5aCwo3empiOyJrrDphpRmiOKwd22rAmRYgcl22iaNQFZEtuvg3rn7eMWev8c6u7O8NxE1gdC8gC3//jm7QAXTXoPrGJK3uPI9Q8w7Hkp/iiL14N/CIvWCi/zYzC3pJ9Te/xVTe3/PTRKFoNNDfvNFZZYTW4nRl9kAQ3Zfn7ahNNHsEbLtNDzJFbgKrt33L/nS3tyRfEn3rYpJCLzes6Dx+N151CR0dXhK7WSzYYef9lytLUIBcZg9QYN6BMz+gPp4uu7z4ZkvF1nmw1RdNy1s3S46S59oCssPVbSoeKGUF46cBtrw1iQ4eVslo/fkFpqk8V9mj+h1edrE5RcZyE8GkEem5GbnRFtLjuK+2v6KcwDIMvtk0lL15bY+Oi6RYDrpojHhAcgcBOU1r26NnEGY4NOi0ECY013YUpeph6C/c5TsSj5nQGljZrKtrW2WwLPA+SelSx242M8po1SJ6TnE4q0R+nNopcNJ0krOMXvB5CtVffzuiLLUK4fO6byCqgs=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB9PR08MB6588.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(376005)(1800799015)(366007)(38070700009);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="us-ascii"
Content-ID: <496C4C137097BF49BE6480F28EC05E3C@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR08MB10365
Original-Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 AMS0EPF00000198.eurprd05.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	9a6109ef-7b7a-4429-a196-08dc4e623c20
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	NrEdx7O+HeHJQXn59psDfubvmDZ4gT0/LfGTrdN6IeAtuZvs3KxeHbkLaW+N3rOVi3+T3E16br8fRRlBCvCx7zXfXozWCg94w2UejIAl0PugLwm40Y+FkDmxCNzuPLzGsKYvp1dkJB+QP6i0H1tAal+pcaSjNi0q8OTKQjEG68xvomJSLox67UE5cV4FM+Q2IQ24ALYPg5nn8cqL1tP26SnfR3frSynYpuyorFxKoi8BaoHcRqV5pXKsuRji569M3isXv8eeGjoxDTeqlg19/58VfFuDYhSyGpRS541Go5fOjKUaSbs4qbulk1JegurpuAQ5nSGV4ENaeL3bwVCWxzJWHUZtg7yOz+pJt9M+ukXWacVvHUKO+xBYdcJMu47dHBdZpkmCnNSXUAB45KtI5De1x5XpEN3OLYeUAnv8glrxXctMM18kFPh2kzqB+NSr6BDscUE+O8ru3I6z2Y97wQfvjHEEupFuRZQPkfbzcyQTRFQzsL+SQ5SlWb5sHPaR6FNUHJtQpCXhOI+b1/iH+ShrlJiBIl+wZVNhrlYfVRkuPXzfHHMQe/u0yUGFTih6/VJbclZBL589qINbkr1gjjk11dKv4P1XwYK49TYmS/x8OS87R09TurO3HwdiDGgLTiaxOle8rC8k9IY494jpitZKHs7F2i/qe+UEckf4r9ojtEAgITt8YTkc+bYXzELR4ZRYv3ccpWLaj2ZmnrNbV6yJZ4QHvXj5zl0wMIZi4UVU8a3RTHxREhlBIaEibBvx
X-Forefront-Antispam-Report:
	CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com;CAT:NONE;SFS:(13230031)(376005)(82310400014)(36860700004)(1800799015);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Mar 2024 13:31:50.8467
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 4296d025-cf61-4649-8685-08dc4e624280
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-AuthSource:
	AMS0EPF00000198.eurprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAVPR08MB9860

Hi Jens,

> On 25 Mar 2024, at 10:38, Jens Wiklander  wrot=
e:
>=20
> Prepare to separate into modules by renaming functions that will need
> new names when becoming non-static in the following commit.
>=20
> Signed-off-by: Jens Wiklander 

Reviewed-by: Bertrand Marquis 

Cheers
Bertrand

> ---
> xen/arch/arm/tee/ffa.c | 125 +++++++++++++++++++++--------------------
> 1 file changed, 65 insertions(+), 60 deletions(-)
>=20
> diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
> index 9a05dcede17a..0344a0f17e72 100644
> --- a/xen/arch/arm/tee/ffa.c
> +++ b/xen/arch/arm/tee/ffa.c
> @@ -4,7 +4,7 @@
>  *
>  * Arm Firmware Framework for ARMv8-A (FF-A) mediator
>  *
> - * Copyright (C) 2023  Linaro Limited
> + * Copyright (C) 2023-2024  Linaro Limited
>  *
>  * References:
>  * FF-A-1.0-REL: FF-A specification version 1.0 available at
> @@ -473,7 +473,7 @@ static bool ffa_get_version(uint32_t *vers)
>     return true;
> }
>=20
> -static int32_t get_ffa_ret_code(const struct arm_smccc_1_2_regs *resp)
> +static int32_t ffa_get_ret_code(const struct arm_smccc_1_2_regs *resp)
> {
>     switch ( resp->a0 )
>     {
> @@ -504,7 +504,7 @@ static int32_t ffa_simple_call(uint32_t fid, register=
_t a1, register_t a2,
>=20
>     arm_smccc_1_2_smc(&arg, &resp);
>=20
> -    return get_ffa_ret_code(&resp);
> +    return ffa_get_ret_code(&resp);
> }
>=20
> static int32_t ffa_features(uint32_t id)
> @@ -546,7 +546,7 @@ static int32_t ffa_partition_info_get(uint32_t w1, ui=
nt32_t w2, uint32_t w3,
>=20
>     arm_smccc_1_2_smc(&arg, &resp);
>=20
> -    ret =3D get_ffa_ret_code(&resp);
> +    ret =3D ffa_get_ret_code(&resp);
>     if ( !ret )
>     {
>         *count =3D resp.a2;
> @@ -654,15 +654,16 @@ static int32_t ffa_direct_req_send_vm(uint16_t sp_i=
d, uint16_t vm_id,
>     return res;
> }
>=20
> -static uint16_t get_vm_id(const struct domain *d)
> +static uint16_t ffa_get_vm_id(const struct domain *d)
> {
>     /* +1 since 0 is reserved for the hypervisor in FF-A */
>     return d->domain_id + 1;
> }
>=20
> -static void set_regs(struct cpu_user_regs *regs, register_t v0, register=
_t v1,
> -                     register_t v2, register_t v3, register_t v4, regist=
er_t v5,
> -                     register_t v6, register_t v7)
> +static void ffa_set_regs(struct cpu_user_regs *regs, register_t v0,
> +                         register_t v1, register_t v2, register_t v3,
> +                         register_t v4, register_t v5, register_t v6,
> +                         register_t v7)
> {
>         set_user_reg(regs, 0, v0);
>         set_user_reg(regs, 1, v1);
> @@ -674,15 +675,15 @@ static void set_regs(struct cpu_user_regs *regs, re=
gister_t v0, register_t v1,
>         set_user_reg(regs, 7, v7);
> }
>=20
> -static void set_regs_error(struct cpu_user_regs *regs, uint32_t error_co=
de)
> +static void ffa_set_regs_error(struct cpu_user_regs *regs, uint32_t erro=
r_code)
> {
> -    set_regs(regs, FFA_ERROR, 0, error_code, 0, 0, 0, 0, 0);
> +    ffa_set_regs(regs, FFA_ERROR, 0, error_code, 0, 0, 0, 0, 0);
> }
>=20
> -static void set_regs_success(struct cpu_user_regs *regs, uint32_t w2,
> +static void ffa_set_regs_success(struct cpu_user_regs *regs, uint32_t w2=
,
>                              uint32_t w3)
> {
> -    set_regs(regs, FFA_SUCCESS_32, 0, w2, w3, 0, 0, 0, 0);
> +    ffa_set_regs(regs, FFA_SUCCESS_32, 0, w2, w3, 0, 0, 0, 0);
> }
>=20
> static void handle_version(struct cpu_user_regs *regs)
> @@ -697,11 +698,11 @@ static void handle_version(struct cpu_user_regs *re=
gs)
>         vers =3D FFA_VERSION_1_1;
>=20
>     ctx->guest_vers =3D vers;
> -    set_regs(regs, vers, 0, 0, 0, 0, 0, 0, 0);
> +    ffa_set_regs(regs, vers, 0, 0, 0, 0, 0, 0, 0);
> }
>=20
> -static uint32_t handle_rxtx_map(uint32_t fid, register_t tx_addr,
> -                                register_t rx_addr, uint32_t page_count)
> +static uint32_t ffa_handle_rxtx_map(uint32_t fid, register_t tx_addr,
> +    register_t rx_addr, uint32_t page_count)
> {
>     uint32_t ret =3D FFA_RET_INVALID_PARAMETERS;
>     struct domain *d =3D current->domain;
> @@ -789,7 +790,7 @@ static void rxtx_unmap(struct ffa_ctx *ctx)
>     ctx->rx_is_free =3D false;
> }
>=20
> -static uint32_t handle_rxtx_unmap(void)
> +static uint32_t ffa_handle_rxtx_unmap(void)
> {
>     struct domain *d =3D current->domain;
>     struct ffa_ctx *ctx =3D d->arch.tee;
> @@ -802,9 +803,10 @@ static uint32_t handle_rxtx_unmap(void)
>     return FFA_RET_OK;
> }
>=20
> -static int32_t handle_partition_info_get(uint32_t w1, uint32_t w2, uint3=
2_t w3,
> -                                         uint32_t w4, uint32_t w5,
> -                                         uint32_t *count, uint32_t *fpi_=
size)
> +static int32_t ffa_handle_partition_info_get(uint32_t w1, uint32_t w2,
> +                                             uint32_t w3, uint32_t w4,
> +                                             uint32_t w5, uint32_t *coun=
t,
> +                                             uint32_t *fpi_size)
> {
>     int32_t ret =3D FFA_RET_DENIED;
>     struct domain *d =3D current->domain;
> @@ -883,7 +885,7 @@ out:
>     return ret;
> }
>=20
> -static int32_t handle_rx_release(void)
> +static int32_t ffa_handle_rx_release(void)
> {
>     int32_t ret =3D FFA_RET_DENIED;
>     struct domain *d =3D current->domain;
> @@ -916,7 +918,7 @@ static void handle_msg_send_direct_req(struct cpu_use=
r_regs *regs, uint32_t fid)
>         mask =3D GENMASK_ULL(31, 0);
>=20
>     src_dst =3D get_user_reg(regs, 1);
> -    if ( (src_dst >> 16) !=3D get_vm_id(d) )
> +    if ( (src_dst >> 16) !=3D ffa_get_vm_id(d) )
>     {
>         resp.a0 =3D FFA_ERROR;
>         resp.a2 =3D FFA_RET_INVALID_PARAMETERS;
> @@ -949,8 +951,9 @@ static void handle_msg_send_direct_req(struct cpu_use=
r_regs *regs, uint32_t fid)
>     }
>=20
> out:
> -    set_regs(regs, resp.a0, resp.a1 & mask, resp.a2 & mask, resp.a3 & ma=
sk,
> -             resp.a4 & mask, resp.a5 & mask, resp.a6 & mask, resp.a7 & m=
ask);
> +    ffa_set_regs(regs, resp.a0, resp.a1 & mask, resp.a2 & mask, resp.a3 =
& mask,
> +                 resp.a4 & mask, resp.a5 & mask, resp.a6 & mask,
> +                 resp.a7 & mask);
> }
>=20
> /*
> @@ -1249,7 +1252,7 @@ static int read_mem_transaction(uint32_t ffa_vers, =
const void *buf, size_t blen,
>     return 0;
> }
>=20
> -static void handle_mem_share(struct cpu_user_regs *regs)
> +static void ffa_handle_mem_share(struct cpu_user_regs *regs)
> {
>     uint32_t tot_len =3D get_user_reg(regs, 1);
>     uint32_t frag_len =3D get_user_reg(regs, 2);
> @@ -1318,7 +1321,7 @@ static void handle_mem_share(struct cpu_user_regs *=
regs)
>         goto out_unlock;
>     }
>=20
> -    if ( trans.sender_id !=3D get_vm_id(d) )
> +    if ( trans.sender_id !=3D ffa_get_vm_id(d) )
>     {
>         ret =3D FFA_RET_INVALID_PARAMETERS;
>         goto out_unlock;
> @@ -1402,9 +1405,9 @@ out_unlock:
>=20
> out_set_ret:
>     if ( ret =3D=3D 0)
> -            set_regs_success(regs, handle_lo, handle_hi);
> +            ffa_set_regs_success(regs, handle_lo, handle_hi);
>     else
> -            set_regs_error(regs, ret);
> +            ffa_set_regs_error(regs, ret);
> }
>=20
> /* Must only be called with ctx->lock held */
> @@ -1419,7 +1422,7 @@ static struct ffa_shm_mem *find_shm_mem(struct ffa_=
ctx *ctx, uint64_t handle)
>     return NULL;
> }
>=20
> -static int handle_mem_reclaim(uint64_t handle, uint32_t flags)
> +static int ffa_handle_mem_reclaim(uint64_t handle, uint32_t flags)
> {
>     struct domain *d =3D current->domain;
>     struct ffa_ctx *ctx =3D d->arch.tee;
> @@ -1471,41 +1474,42 @@ static bool ffa_handle_call(struct cpu_user_regs =
*regs)
>         handle_version(regs);
>         return true;
>     case FFA_ID_GET:
> -        set_regs_success(regs, get_vm_id(d), 0);
> +        ffa_set_regs_success(regs, ffa_get_vm_id(d), 0);
>         return true;
>     case FFA_RXTX_MAP_32:
>     case FFA_RXTX_MAP_64:
> -        e =3D handle_rxtx_map(fid, get_user_reg(regs, 1), get_user_reg(r=
egs, 2),
> -                            get_user_reg(regs, 3));
> +        e =3D ffa_handle_rxtx_map(fid, get_user_reg(regs, 1),
> + get_user_reg(regs, 2), get_user_reg(regs, 3));
>         if ( e )
> -            set_regs_error(regs, e);
> +            ffa_set_regs_error(regs, e);
>         else
> -            set_regs_success(regs, 0, 0);
> +            ffa_set_regs_success(regs, 0, 0);
>         return true;
>     case FFA_RXTX_UNMAP:
> -        e =3D handle_rxtx_unmap();
> +        e =3D ffa_handle_rxtx_unmap();
>         if ( e )
> -            set_regs_error(regs, e);
> +            ffa_set_regs_error(regs, e);
>         else
> -            set_regs_success(regs, 0, 0);
> +            ffa_set_regs_success(regs, 0, 0);
>         return true;
>     case FFA_PARTITION_INFO_GET:
> -        e =3D handle_partition_info_get(get_user_reg(regs, 1),
> -                                      get_user_reg(regs, 2),
> -                                      get_user_reg(regs, 3),
> -                                      get_user_reg(regs, 4),
> -                                      get_user_reg(regs, 5), &count, &fp=
i_size);
> +        e =3D ffa_handle_partition_info_get(get_user_reg(regs, 1),
> +                                          get_user_reg(regs, 2),
> +                                          get_user_reg(regs, 3),
> +                                          get_user_reg(regs, 4),
> +                                          get_user_reg(regs, 5), &count,
> +                                          &fpi_size);
>         if ( e )
> -            set_regs_error(regs, e);
> +            ffa_set_regs_error(regs, e);
>         else
> -            set_regs_success(regs, count, fpi_size);
> +            ffa_set_regs_success(regs, count, fpi_size);
>         return true;
>     case FFA_RX_RELEASE:
> -        e =3D handle_rx_release();
> +        e =3D ffa_handle_rx_release();
>         if ( e )
> -            set_regs_error(regs, e);
> +            ffa_set_regs_error(regs, e);
>         else
> -            set_regs_success(regs, 0, 0);
> +            ffa_set_regs_success(regs, 0, 0);
>         return true;
>     case FFA_MSG_SEND_DIRECT_REQ_32:
>     case FFA_MSG_SEND_DIRECT_REQ_64:
> @@ -1513,21 +1517,21 @@ static bool ffa_handle_call(struct cpu_user_regs =
*regs)
>         return true;
>     case FFA_MEM_SHARE_32:
>     case FFA_MEM_SHARE_64:
> -        handle_mem_share(regs);
> +        ffa_handle_mem_share(regs);
>         return true;
>     case FFA_MEM_RECLAIM:
> -        e =3D handle_mem_reclaim(regpair_to_uint64(get_user_reg(regs, 2)=
,
> -                                                 get_user_reg(regs, 1)),
> -                               get_user_reg(regs, 3));
> +        e =3D ffa_handle_mem_reclaim(regpair_to_uint64(get_user_reg(regs=
, 2),
> +                                                     get_user_reg(regs, =
1)),
> +                                   get_user_reg(regs, 3));
>         if ( e )
> -            set_regs_error(regs, e);
> +            ffa_set_regs_error(regs, e);
>         else
> -            set_regs_success(regs, 0, 0);
> +            ffa_set_regs_success(regs, 0, 0);
>         return true;
>=20
>     default:
>         gprintk(XENLOG_ERR, "ffa: unhandled fid 0x%x\n", fid);
> -        set_regs_error(regs, FFA_RET_NOT_SUPPORTED);
> +        ffa_set_regs_error(regs, FFA_RET_NOT_SUPPORTED);
>         return true;
>     }
> }
> @@ -1593,12 +1597,12 @@ static int ffa_domain_init(struct domain *d)
>=20
>     for ( n =3D 0; n < subscr_vm_created_count; n++ )
>     {
> -        res =3D ffa_direct_req_send_vm(subscr_vm_created[n], get_vm_id(d=
),
> +        res =3D ffa_direct_req_send_vm(subscr_vm_created[n], ffa_get_vm_=
id(d),
>                                      FFA_MSG_SEND_VM_CREATED);
>         if ( res )
>         {
>             printk(XENLOG_ERR "ffa: Failed to report creation of vm_id %u=
 to  %u: res %d\n",
> -                   get_vm_id(d), subscr_vm_created[n], res);
> +                   ffa_get_vm_id(d), subscr_vm_created[n], res);
>             break;
>         }
>     }
> @@ -1620,13 +1624,13 @@ static void send_vm_destroyed(struct domain *d)
>         if ( !test_bit(n, ctx->vm_destroy_bitmap) )
>             continue;
>=20
> -        res =3D ffa_direct_req_send_vm(subscr_vm_destroyed[n], get_vm_id=
(d),
> +        res =3D ffa_direct_req_send_vm(subscr_vm_destroyed[n], ffa_get_v=
m_id(d),
>                                      FFA_MSG_SEND_VM_DESTROYED);
>=20
>         if ( res )
>         {
>             printk(XENLOG_ERR "%pd: ffa: Failed to report destruction of =
vm_id %u to %u: res %d\n",
> -                   d, get_vm_id(d), subscr_vm_destroyed[n], res);
> +                   d, ffa_get_vm_id(d), subscr_vm_destroyed[n], res);
>         }
>=20
>         /*
> @@ -1640,7 +1644,7 @@ static void send_vm_destroyed(struct domain *d)
>     }
> }
>=20
> -static void reclaim_shms(struct domain *d)
> +static void ffa_reclaim_shms(struct domain *d)
> {
>     struct ffa_ctx *ctx =3D d->arch.tee;
>     struct ffa_shm_mem *shm, *tmp;
> @@ -1699,7 +1703,7 @@ static void ffa_domain_teardown_continue(struct ffa=
_ctx *ctx, bool first_time)
>     struct ffa_ctx *next_ctx =3D NULL;
>=20
>     send_vm_destroyed(ctx->teardown_d);
> -    reclaim_shms(ctx->teardown_d);
> +    ffa_reclaim_shms(ctx->teardown_d);
>=20
>     if ( ctx->shm_count ||
>          !bitmap_empty(ctx->vm_destroy_bitmap, subscr_vm_destroyed_count)=
 )
> @@ -1719,7 +1723,8 @@ static void ffa_domain_teardown_continue(struct ffa=
_ctx *ctx, bool first_time)
>     {
>         /*
>          * domain_destroy() might have been called (via put_domain() in
> -         * reclaim_shms()), so we can't touch the domain structure anymo=
re.
> +         * ffa_reclaim_shms()), so we can't touch the domain structure
> +         * anymore.
>          */
>         xfree(ctx);
>=20
> --=20
> 2.34.1
>=20



From xen-devel-bounces@lists.xenproject.org Wed Mar 27 13:33:17 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 13:33:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698524.1090278 (Exim 4.92)
	(envelope-from )
	id 1rpTP2-0007uG-Ko; Wed, 27 Mar 2024 13:33:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698524.1090278; Wed, 27 Mar 2024 13:33:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpTP2-0007u9-Gy; Wed, 27 Mar 2024 13:33:16 +0000
Received: by outflank-mailman (input) for mailman id 698524;
 Wed, 27 Mar 2024 13:33:15 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpTP0-0007u3-Vw
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 13:33:15 +0000
Received: from EUR03-AM7-obe.outbound.protection.outlook.com
 (mail-am7eur03on20600.outbound.protection.outlook.com
 [2a01:111:f403:260e::600])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8e9bf39e-ec3e-11ee-a1ef-f123f15fe8a2;
 Wed, 27 Mar 2024 14:33:12 +0100 (CET)
Received: from DBBPR09CA0019.eurprd09.prod.outlook.com (2603:10a6:10:c0::31)
 by GVXPR08MB7750.eurprd08.prod.outlook.com (2603:10a6:150:68::13) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.31; Wed, 27 Mar
 2024 13:33:02 +0000
Received: from DU6PEPF0000B621.eurprd02.prod.outlook.com
 (2603:10a6:10:c0:cafe::25) by DBBPR09CA0019.outlook.office365.com
 (2603:10a6:10:c0::31) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.13 via Frontend
 Transport; Wed, 27 Mar 2024 13:33:00 +0000
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by
 DU6PEPF0000B621.mail.protection.outlook.com (10.167.8.138) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.7409.10 via Frontend Transport; Wed, 27 Mar 2024 13:33:00 +0000
Received: ("Tessian outbound ff4e98f65004:v300");
 Wed, 27 Mar 2024 13:33:00 +0000
Received: from a3f27a37e57e.1
 by 64aa7808-outbound-1.mta.getcheckrecipient.com id
 1086D728-43FA-40B9-A9A3-BC28DAC86611.1; 
 Wed, 27 Mar 2024 13:32:54 +0000
Received: from EUR03-DBA-obe.outbound.protection.outlook.com
 by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id a3f27a37e57e.1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384);
 Wed, 27 Mar 2024 13:32:54 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com (2603:10a6:10:25a::24)
 by DU0PR08MB10365.eurprd08.prod.outlook.com (2603:10a6:10:40b::7)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.31; Wed, 27 Mar
 2024 13:32:52 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::7fb0:6621:56b:22d5]) by DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::7fb0:6621:56b:22d5%3]) with mapi id 15.20.7409.031; Wed, 27 Mar 2024
 13:32:52 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8e9bf39e-ec3e-11ee-a1ef-f123f15fe8a2
ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass;
 b=ageVVESP/MbywS6tCK4s0UNXPd9NZPBTkkcemh/9j631Rkw4W31K0Kvq+3avXlnKKykT/sjnxFQq8BjadSrCiug3TAlBOiR5WvSYyEl6z5OC9Lgxr5kCTqZuX2d68ojY3t54TDJgOK0lU+aMceE1dlhWffBqTP7ZuuQ2RYuLL44iB4RKb8F5KMh2EhguQwMzn+LpBa4vfDrJVh/aRUvxjZUxLDs/1oL3Hkr2rO4NZMsGK/3nLpYpWOtXz4Wx1g9MZ64PmvDL7KjyW7SyIV12ZvVK0jpOJPa6fEXHbTpNOO9B3MqNhbJy/2jG/p0maesqNcoz1CWNgvvW6NKCXKWocQ==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=oWr9Ek+dp+cK4B/SkVhBoOst871GlXjdexVPP3QCl6A=;
 b=jd1g8igvaA9Xc9HydJIV1tR+HVS/Exdn+6v+r/M86xHoCtJejqFzdQXybFrNkztB0Ds+sawTGlAN4sVWFvchOldHMPRilv9oNHUH2CZohUC5GGOqJL7DT+PKFx5AYacoe9z9SsGPnhTUIlOanOmjV+1KTEvze2QSUjvrjPgnOJkDBVChoftgoFtiIcEgeZkv+Y8CaHRvbSiNzJMzuvlVMNuiYj99bDr+M7xSox4De2C1/nCaFzK0ocqbxJyMEvl1XyEm2HGQWO5vXMqjUteMS/0DS4oFotzJxnxUGP2P8m9uiMTwdv/8bKHST4JTodwlPfH9Ovt7yKLFkNyM/rfQtg==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 63.35.35.123) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=arm.com;
 dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com;
 dkim=pass (signature was verified) header.d=armh.onmicrosoft.com; arc=pass (0
 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com]
 dmarc=[1,1,header.from=arm.com])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com;
 s=selector2-armh-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=oWr9Ek+dp+cK4B/SkVhBoOst871GlXjdexVPP3QCl6A=;
 b=SUrUADUtGoc6E97Y9t9uXOFE2fnCb666xdUIbg8hPFHHOU7O6MVKjnlKPAfdRtqyJmKi7zIrxurNwDtYZSa2lL2wAz057wL8TmZS22Kzs8854A3IIUS9qdWHfzhaDgiwJwEhBhBzX3ALxg1dJiBlC/6Q4uE7K0wWIbF0uRR2AOU=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=armh.onmicrosoft.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 63.35.35.123 as permitted sender) receiver=protection.outlook.com;
 client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
 pr=C
X-CheckRecipientChecked: true
X-CR-MTA-CID: 563211b93ee5cd55
X-CR-MTA-TID: 64aa7808
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=BRhS6XK2xoWGo8IVDrZAm/rARzsfXJi0BVCm+Wbv5Q62xSzR+m7zc27SGD/qd/ikG+5rSKFw6zXOZhDyj9s6ac/n942H+yDTjZfzMEvaQEiPyGpWraLVEf5cjbwj/pO0GCky6I2BgMMMH20OUdcBQvpgQ6i4u49SPZ+BuB2R+b24kDdb/MsEdeYOKXvcS9IeMgmZwOAD+50kKLPuU6Xnye1bl3Lsx5CFnpKgtF2rC6aUHWpCFAMDgP22YSQ+MuUkxB8aYnuS4Ol/6oV1DFwlkfUwVVIP8Umo7He6qpuNk74ihQTyWarjJb29fSsot0zxhdB7GD9a1+rY+r/1xGd2QA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=oWr9Ek+dp+cK4B/SkVhBoOst871GlXjdexVPP3QCl6A=;
 b=KIPko24upQv9K2nMfTQxVPLKSuKY+3wQfiK+t+XAblAuc9H4P2djwIvw0ckfem0tQ9Spf9qfFQa3xG9QZeTaw37Owt7QnauXshNs7FVADP+UWip9Cv7mu6qqig7gOkjqGPSKcevU6QGksr81OhSGTpoNxglG/K5e8XOdNrOVdk1fk7YduD4cG6fJGrgIa6tslnB68KytJ/fnU5YVHG3ixbX52tW7S6YM/asqZ+LqzH40yM5SrZTUO03zhMdku2DLlb9z4V0UiAhQttE4CKwr4EPWv5HdayflUOdDUfPyN7159xML/U1F8skYA5IVp/kO9iuYu1h7di0NFQoq3oSsYw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass
 header.d=arm.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com;
 s=selector2-armh-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=oWr9Ek+dp+cK4B/SkVhBoOst871GlXjdexVPP3QCl6A=;
 b=SUrUADUtGoc6E97Y9t9uXOFE2fnCb666xdUIbg8hPFHHOU7O6MVKjnlKPAfdRtqyJmKi7zIrxurNwDtYZSa2lL2wAz057wL8TmZS22Kzs8854A3IIUS9qdWHfzhaDgiwJwEhBhBzX3ALxg1dJiBlC/6Q4uE7K0wWIbF0uRR2AOU=
From: Bertrand Marquis 
To: Jens Wiklander 
CC: Xen-devel , "patches@linaro.org"
	, Volodymyr Babchuk , Stefano
 Stabellini , Julien Grall , Michal
 Orzel 
Subject: Re: [XEN PATCH 2/6] xen/arm: ffa: move common things to ffa_private.h
Thread-Topic: [XEN PATCH 2/6] xen/arm: ffa: move common things to
 ffa_private.h
Thread-Index: AQHafphSE/5Uz86UYk6OOyk0wCz8a7FLmUwA
Date: Wed, 27 Mar 2024 13:32:52 +0000
Message-ID: <0F379C91-B3A8-4864-B8DD-9E08E8D92FFD@arm.com>
References: <20240325093904.3466092-1-jens.wiklander@linaro.org>
 <20240325093904.3466092-3-jens.wiklander@linaro.org>
In-Reply-To: <20240325093904.3466092-3-jens.wiklander@linaro.org>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3774.200.91.1.1)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DB9PR08MB6588:EE_|DU0PR08MB10365:EE_|DU6PEPF0000B621:EE_|GVXPR08MB7750:EE_
X-MS-Office365-Filtering-Correlation-Id: 97ce3869-69a9-45ac-6b60-08dc4e626bd8
x-checkrecipientrouted: true
nodisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted: BCL:0;
X-Microsoft-Antispam-Message-Info-Original:
 ynrNCJ0fNL/F5Gwo/W2Dgs2ME6nIBFl7hAL+HR+q6f5I7vimnwIZPcc5wuTe7g4fCQtCQCjTMskVFtdQFnKVMBwXTd2rdA7vhsxOM+vOXHQ2LdLgP314o1yOauEIvy0GIwSLC8nOWB33kiSeHE6mkWP33WijHIDboLEHApC16GXd2mxuP5ns6UL6KMRa7SpZsfQ+SDU19y7S4uPP3q/GEG+dpSngDe4p0BO700IkyLCiQISxgNEGDm2DgPo9Jq8JQiE3CMBvxw3f54zJyD+xLLThKAC2nJaXMYS1qAXMZ9IJNjMYYKeI/GB8R3In93eTcPGzC4gXZOsTTy+NoFJqSRAlUwVwKPI/moxXwM7Ty+7e8G7Nm22CDY16Sv45W0RGu/kv0kJLo9FjvuleVBiWx4p6DeViY1EVp8PA8mQcGl0rIZUgBip3NeJf1t1giZyzpXMq6+y4aDbS42rlTKwzd6/ozFHrBpUv43w9+PHdOKrbDZ2q/3vmgVlG1fNkWU0Bz1xnJbF07pP7Wi9u0YeNVvy7WA/q1/oMFea7ZrxQopvIhu/Ax30FT638x3sGbYbiQNDfQPI6TKWTzI+O5vSa6QebsJapFrBu4j+XSI8yNpcoTL+ab8HwpMD+KXfM+sVXIFvbXsipfGgvRZfFXaDBFFIhSrmnturii9boOwfd/G8hK13OcUdZ1O3Pe47//px5IoTJRaBoaWdp5BB0OnVP9A==
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB9PR08MB6588.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(376005)(1800799015)(366007)(38070700009);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="us-ascii"
Content-ID: <94227E48D5A72A42A29DD99A9A45BC0B@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR08MB10365
Original-Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 DU6PEPF0000B621.eurprd02.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	a58a8dec-c87a-4b31-4aff-08dc4e626715
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	uGnIgP0PVHA94R4kDx+g6OZH6ui4x0/5/fQIRWXbvtUfxPATjQrwP9GXxSXBXYvUGQlgD/4sfk29MLbXXRJmdib5fRfnfyqI6XBx+uDAua0Gx8VG1htVVxbNndqBKA4yMHT6+3f16+eCblvNedP4I9hvmx70WuRSlWjREyohyqqNiTOAW/13gUY8DMkW5YAFd3Ugf/RIkHVj7DeaS7Wg+bIgePZTrszAi9wLb7TMwi9yOm3BpSzJjA80BEdQ3i8mtAR+vH4IO/7kczeyBzhRswK8GFWeO6tBEWClWek9mRe1+7pe8MDIeh2LuPEo00qKxQ+ebKpiT/KjckcSqR8zrNVYr8ZMuWdAJksYq5cBQ9bI3MR8Yva4h5ITYs+cYbyBdsiyDntkR4v0Vq+VZxSfZ8v5yV6Q5BQwKzazyJhZf3PAowMAp77erGTtINQ7NUpfe1Y5t2zxMUWEF7TLm+PzZhA62RwnqZTW9iDkQ/DS7D6e5nwYqYEGKjBkvCgStiCgwi9sDOBAEPMvjXeI6opK28bWSbzAPQ4WgLPbCLqyRXcFRyq8tvPD8EpyNFqDPd9MIXzV5Cb5c1MpcxzMgT+2qMrOS+EUqjuW5Q4LJbDQvkTj3NidVCa5KfLS6VD4+WLAaPiZnweDu0lZzuqcINTlnWNiqm6s1kOKp7tB05fozStUh81kmREFsiLT9xdUKYh/uGsxdrHjYoYo5sIRJP4h4PQlxNxNZj+MY9EXpouY9ZWKWbxPdjISu1jbljYedhOG
X-Forefront-Antispam-Report:
	CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com;CAT:NONE;SFS:(13230031)(36860700004)(376005)(82310400014)(1800799015);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Mar 2024 13:33:00.2874
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 97ce3869-69a9-45ac-6b60-08dc4e626bd8
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DU6PEPF0000B621.eurprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GVXPR08MB7750

Hi Jens,

> On 25 Mar 2024, at 10:39, Jens Wiklander  wrot=
e:
>=20
> Prepare to separate ffa.c into modules by moving common things into the
> new internal header file ffa_private.h.
>=20
> Signed-off-by: Jens Wiklander 

Reviewed-by: Bertrand Marquis 

Cheers
Bertrand

> ---
> xen/arch/arm/tee/ffa.c         | 298 +-----------------------------
> xen/arch/arm/tee/ffa_private.h | 318 +++++++++++++++++++++++++++++++++
> 2 files changed, 319 insertions(+), 297 deletions(-)
> create mode 100644 xen/arch/arm/tee/ffa_private.h
>=20
> diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
> index 0344a0f17e72..259851f20bdb 100644
> --- a/xen/arch/arm/tee/ffa.c
> +++ b/xen/arch/arm/tee/ffa.c
> @@ -63,204 +63,7 @@
> #include 
> #include 
>=20
> -/* Error codes */
> -#define FFA_RET_OK                      0
> -#define FFA_RET_NOT_SUPPORTED           -1
> -#define FFA_RET_INVALID_PARAMETERS      -2
> -#define FFA_RET_NO_MEMORY               -3
> -#define FFA_RET_BUSY                    -4
> -#define FFA_RET_INTERRUPTED             -5
> -#define FFA_RET_DENIED                  -6
> -#define FFA_RET_RETRY                   -7
> -#define FFA_RET_ABORTED                 -8
> -
> -/* FFA_VERSION helpers */
> -#define FFA_VERSION_MAJOR_SHIFT         16U
> -#define FFA_VERSION_MAJOR_MASK          0x7FFFU
> -#define FFA_VERSION_MINOR_SHIFT         0U
> -#define FFA_VERSION_MINOR_MASK          0xFFFFU
> -#define MAKE_FFA_VERSION(major, minor)  \
> -        ((((major) & FFA_VERSION_MAJOR_MASK) << FFA_VERSION_MAJOR_SHIFT)=
 | \
> -         ((minor) & FFA_VERSION_MINOR_MASK))
> -
> -#define FFA_VERSION_1_0         MAKE_FFA_VERSION(1, 0)
> -#define FFA_VERSION_1_1         MAKE_FFA_VERSION(1, 1)
> -/* The minimal FF-A version of the SPMC that can be supported */
> -#define FFA_MIN_SPMC_VERSION    FFA_VERSION_1_1
> -
> -/*
> - * This is the version we want to use in communication with guests and S=
Ps.
> - * During negotiation with a guest or a SP we may need to lower it for
> - * that particular guest or SP.
> - */
> -#define FFA_MY_VERSION_MAJOR    1U
> -#define FFA_MY_VERSION_MINOR    1U
> -#define FFA_MY_VERSION          MAKE_FFA_VERSION(FFA_MY_VERSION_MAJOR, \
> -                                                 FFA_MY_VERSION_MINOR)
> -
> -/*
> - * The FF-A specification explicitly works with 4K pages as a measure of
> - * memory size, for example, FFA_RXTX_MAP takes one parameter "RX/TX pag=
e
> - * count" which is the number of contiguous 4K pages allocated. Xen may =
use
> - * a different page size depending on the configuration to avoid confusi=
on
> - * with PAGE_SIZE use a special define when it's a page size as in the F=
F-A
> - * specification.
> - */
> -#define FFA_PAGE_SIZE                   SZ_4K
> -
> -/*
> - * The number of pages used for each of the RX and TX buffers shared wit=
h
> - * the SPMC.
> - */
> -#define FFA_RXTX_PAGE_COUNT             1
> -
> -/*
> - * Limit the number of pages RX/TX buffers guests can map.
> - * TODO support a larger number.
> - */
> -#define FFA_MAX_RXTX_PAGE_COUNT         1
> -
> -/*
> - * Limit for shared buffer size. Please note that this define limits
> - * number of pages.
> - *
> - * FF-A doesn't have any direct requirements on GlobalPlatform or vice
> - * versa, but an implementation can very well use FF-A in order to provi=
de
> - * a GlobalPlatform interface on top.
> - *
> - * Global Platform specification for TEE requires that any TEE
> - * implementation should allow to share buffers with size of at least
> - * 512KB, defined in TEEC-1.0C page 24, Table 4-1,
> - * TEEC_CONFIG_SHAREDMEM_MAX_SIZE.
> - * Due to overhead which can be hard to predict exactly, double this num=
ber
> - * to give a safe margin.
> - */
> -#define FFA_MAX_SHM_PAGE_COUNT          (2 * SZ_512K / FFA_PAGE_SIZE)
> -
> -/*
> - * Limits the number of shared buffers that guest can have at once. This
> - * is to prevent case, when guests trick XEN into exhausting its own
> - * memory by allocating many small buffers. This value has been chosen
> - * arbitrarily.
> - */
> -#define FFA_MAX_SHM_COUNT               32
> -
> -/*
> - * The time we wait until trying to tear down a domain again if it was
> - * blocked initially.
> - */
> -#define FFA_CTX_TEARDOWN_DELAY          SECONDS(1)
> -
> -/* FF-A-1.1-REL0 section 10.9.2 Memory region handle, page 167 */
> -#define FFA_HANDLE_HYP_FLAG             BIT(63, ULL)
> -#define FFA_HANDLE_INVALID              0xffffffffffffffffULL
> -
> -/*
> - * Memory attributes: Normal memory, Write-Back cacheable, Inner shareab=
le
> - * Defined in FF-A-1.1-REL0 Table 10.18 at page 175.
> - */
> -#define FFA_NORMAL_MEM_REG_ATTR         0x2fU
> -/*
> - * Memory access permissions: Read-write
> - * Defined in FF-A-1.1-REL0 Table 10.15 at page 168.
> - */
> -#define FFA_MEM_ACC_RW                  0x2U
> -
> -/* FF-A-1.1-REL0 section 10.11.4 Flags usage, page 184-187 */
> -/* Clear memory before mapping in receiver */
> -#define FFA_MEMORY_REGION_FLAG_CLEAR            BIT(0, U)
> -/* Relayer may time slice this operation */
> -#define FFA_MEMORY_REGION_FLAG_TIME_SLICE       BIT(1, U)
> -/* Clear memory after receiver relinquishes it */
> -#define FFA_MEMORY_REGION_FLAG_CLEAR_RELINQUISH BIT(2, U)
> -/* Share memory transaction */
> -#define FFA_MEMORY_REGION_TRANSACTION_TYPE_SHARE (1U << 3)
> -
> -/*
> - * Flags and field values used for the MSG_SEND_DIRECT_REQ/RESP:
> - * BIT(31): Framework or partition message
> - * BIT(7-0): Message type for frameworks messages
> - */
> -#define FFA_MSG_FLAG_FRAMEWORK          BIT(31, U)
> -#define FFA_MSG_TYPE_MASK               0xFFU;
> -#define FFA_MSG_PSCI                    0x0U
> -#define FFA_MSG_SEND_VM_CREATED         0x4U
> -#define FFA_MSG_RESP_VM_CREATED         0x5U
> -#define FFA_MSG_SEND_VM_DESTROYED       0x6U
> -#define FFA_MSG_RESP_VM_DESTROYED       0x7U
> -
> -/*
> - * Flags to determine partition properties in FFA_PARTITION_INFO_GET ret=
urn
> - * message:
> - * BIT(0): Supports receipt of direct requests
> - * BIT(1): Can send direct requests
> - * BIT(2): Can send and receive indirect messages
> - * BIT(3): Supports receipt of notifications
> - * BIT(4-5): Partition ID is a PE endpoint ID
> - * BIT(6): Partition must be informed about each VM that is created by
> - *         the Hypervisor
> - * BIT(7): Partition must be informed about each VM that is destroyed by
> - *         the Hypervisor
> - * BIT(8): Partition runs in the AArch64 execution state else AArch32
> - *         execution state
> - */
> -#define FFA_PART_PROP_DIRECT_REQ_RECV   BIT(0, U)
> -#define FFA_PART_PROP_DIRECT_REQ_SEND   BIT(1, U)
> -#define FFA_PART_PROP_INDIRECT_MSGS     BIT(2, U)
> -#define FFA_PART_PROP_RECV_NOTIF        BIT(3, U)
> -#define FFA_PART_PROP_IS_TYPE_MASK      (3U << 4)
> -#define FFA_PART_PROP_IS_PE_ID          (0U << 4)
> -#define FFA_PART_PROP_IS_SEPID_INDEP    (1U << 4)
> -#define FFA_PART_PROP_IS_SEPID_DEP      (2U << 4)
> -#define FFA_PART_PROP_IS_AUX_ID         (3U << 4)
> -#define FFA_PART_PROP_NOTIF_CREATED     BIT(6, U)
> -#define FFA_PART_PROP_NOTIF_DESTROYED   BIT(7, U)
> -#define FFA_PART_PROP_AARCH64_STATE     BIT(8, U)
> -
> -/*
> - * Flag used as parameter to FFA_PARTITION_INFO_GET to return partition
> - * count only.
> - */
> -#define FFA_PARTITION_INFO_GET_COUNT_FLAG BIT(0, U)
> -
> -/* Function IDs */
> -#define FFA_ERROR                       0x84000060U
> -#define FFA_SUCCESS_32                  0x84000061U
> -#define FFA_SUCCESS_64                  0xC4000061U
> -#define FFA_INTERRUPT                   0x84000062U
> -#define FFA_VERSION                     0x84000063U
> -#define FFA_FEATURES                    0x84000064U
> -#define FFA_RX_ACQUIRE                  0x84000084U
> -#define FFA_RX_RELEASE                  0x84000065U
> -#define FFA_RXTX_MAP_32                 0x84000066U
> -#define FFA_RXTX_MAP_64                 0xC4000066U
> -#define FFA_RXTX_UNMAP                  0x84000067U
> -#define FFA_PARTITION_INFO_GET          0x84000068U
> -#define FFA_ID_GET                      0x84000069U
> -#define FFA_SPM_ID_GET                  0x84000085U
> -#define FFA_MSG_WAIT                    0x8400006BU
> -#define FFA_MSG_YIELD                   0x8400006CU
> -#define FFA_RUN                         0x8400006DU
> -#define FFA_MSG_SEND2                   0x84000086U
> -#define FFA_MSG_SEND_DIRECT_REQ_32      0x8400006FU
> -#define FFA_MSG_SEND_DIRECT_REQ_64      0xC400006FU
> -#define FFA_MSG_SEND_DIRECT_RESP_32     0x84000070U
> -#define FFA_MSG_SEND_DIRECT_RESP_64     0xC4000070U
> -#define FFA_MEM_DONATE_32               0x84000071U
> -#define FFA_MEM_DONATE_64               0xC4000071U
> -#define FFA_MEM_LEND_32                 0x84000072U
> -#define FFA_MEM_LEND_64                 0xC4000072U
> -#define FFA_MEM_SHARE_32                0x84000073U
> -#define FFA_MEM_SHARE_64                0xC4000073U
> -#define FFA_MEM_RETRIEVE_REQ_32         0x84000074U
> -#define FFA_MEM_RETRIEVE_REQ_64         0xC4000074U
> -#define FFA_MEM_RETRIEVE_RESP           0x84000075U
> -#define FFA_MEM_RELINQUISH              0x84000076U
> -#define FFA_MEM_RECLAIM                 0x84000077U
> -#define FFA_MEM_FRAG_RX                 0x8400007AU
> -#define FFA_MEM_FRAG_TX                 0x8400007BU
> -#define FFA_MSG_SEND                    0x8400006EU
> -#define FFA_MSG_POLL                    0x8400006AU
> +#include "ffa_private.h"
>=20
> /*
>  * Structs below ending with _1_0 are defined in FF-A-1.0-REL and
> @@ -382,39 +185,6 @@ struct ffa_endpoint_rxtx_descriptor_1_1 {
>     uint32_t tx_region_offs;
> };
>=20
> -struct ffa_ctx {
> -    void *rx;
> -    const void *tx;
> -    struct page_info *rx_pg;
> -    struct page_info *tx_pg;
> -    /* Number of 4kB pages in each of rx/rx_pg and tx/tx_pg */
> -    unsigned int page_count;
> -    /* FF-A version used by the guest */
> -    uint32_t guest_vers;
> -    bool rx_is_free;
> -    /* Used shared memory objects, struct ffa_shm_mem */
> -    struct list_head shm_list;
> -    /* Number of allocated shared memory object */
> -    unsigned int shm_count;
> -    /*
> -     * tx_lock is used to serialize access to tx
> -     * rx_lock is used to serialize access to rx
> -     * lock is used for the rest in this struct
> -     */
> -    spinlock_t tx_lock;
> -    spinlock_t rx_lock;
> -    spinlock_t lock;
> -    /* Used if domain can't be torn down immediately */
> -    struct domain *teardown_d;
> -    struct list_head teardown_list;
> -    s_time_t teardown_expire;
> -    /*
> -     * Used for ffa_domain_teardown() to keep track of which SPs should =
be
> -     * notified that this guest is being destroyed.
> -     */
> -    unsigned long vm_destroy_bitmap[];
> -};
> -
> struct ffa_shm_mem {
>     struct list_head list;
>     uint16_t sender_id;
> @@ -473,40 +243,6 @@ static bool ffa_get_version(uint32_t *vers)
>     return true;
> }
>=20
> -static int32_t ffa_get_ret_code(const struct arm_smccc_1_2_regs *resp)
> -{
> -    switch ( resp->a0 )
> -    {
> -    case FFA_ERROR:
> -        if ( resp->a2 )
> -            return resp->a2;
> -        else
> -            return FFA_RET_NOT_SUPPORTED;
> -    case FFA_SUCCESS_32:
> -    case FFA_SUCCESS_64:
> -        return FFA_RET_OK;
> -    default:
> -        return FFA_RET_NOT_SUPPORTED;
> -    }
> -}
> -
> -static int32_t ffa_simple_call(uint32_t fid, register_t a1, register_t a=
2,
> -                               register_t a3, register_t a4)
> -{
> -    const struct arm_smccc_1_2_regs arg =3D {
> -        .a0 =3D fid,
> -        .a1 =3D a1,
> -        .a2 =3D a2,
> -        .a3 =3D a3,
> -        .a4 =3D a4,
> -    };
> -    struct arm_smccc_1_2_regs resp;
> -
> -    arm_smccc_1_2_smc(&arg, &resp);
> -
> -    return ffa_get_ret_code(&resp);
> -}
> -
> static int32_t ffa_features(uint32_t id)
> {
>     return ffa_simple_call(FFA_FEATURES, id, 0, 0, 0);
> @@ -654,38 +390,6 @@ static int32_t ffa_direct_req_send_vm(uint16_t sp_id=
, uint16_t vm_id,
>     return res;
> }
>=20
> -static uint16_t ffa_get_vm_id(const struct domain *d)
> -{
> -    /* +1 since 0 is reserved for the hypervisor in FF-A */
> -    return d->domain_id + 1;
> -}
> -
> -static void ffa_set_regs(struct cpu_user_regs *regs, register_t v0,
> -                         register_t v1, register_t v2, register_t v3,
> -                         register_t v4, register_t v5, register_t v6,
> -                         register_t v7)
> -{
> -        set_user_reg(regs, 0, v0);
> -        set_user_reg(regs, 1, v1);
> -        set_user_reg(regs, 2, v2);
> -        set_user_reg(regs, 3, v3);
> -        set_user_reg(regs, 4, v4);
> -        set_user_reg(regs, 5, v5);
> -        set_user_reg(regs, 6, v6);
> -        set_user_reg(regs, 7, v7);
> -}
> -
> -static void ffa_set_regs_error(struct cpu_user_regs *regs, uint32_t erro=
r_code)
> -{
> -    ffa_set_regs(regs, FFA_ERROR, 0, error_code, 0, 0, 0, 0, 0);
> -}
> -
> -static void ffa_set_regs_success(struct cpu_user_regs *regs, uint32_t w2=
,
> -                             uint32_t w3)
> -{
> -    ffa_set_regs(regs, FFA_SUCCESS_32, 0, w2, w3, 0, 0, 0, 0);
> -}
> -
> static void handle_version(struct cpu_user_regs *regs)
> {
>     struct domain *d =3D current->domain;
> diff --git a/xen/arch/arm/tee/ffa_private.h b/xen/arch/arm/tee/ffa_privat=
e.h
> new file mode 100644
> index 000000000000..8352b6b55a9a
> --- /dev/null
> +++ b/xen/arch/arm/tee/ffa_private.h
> @@ -0,0 +1,318 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Copyright (C) 2023  Linaro Limited
> + */
> +
> +#ifndef __FFA_PRIVATE_H__
> +#define __FFA_PRIVATE_H__
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* Error codes */
> +#define FFA_RET_OK                      0
> +#define FFA_RET_NOT_SUPPORTED           -1
> +#define FFA_RET_INVALID_PARAMETERS      -2
> +#define FFA_RET_NO_MEMORY               -3
> +#define FFA_RET_BUSY                    -4
> +#define FFA_RET_INTERRUPTED             -5
> +#define FFA_RET_DENIED                  -6
> +#define FFA_RET_RETRY                   -7
> +#define FFA_RET_ABORTED                 -8
> +
> +/* FFA_VERSION helpers */
> +#define FFA_VERSION_MAJOR_SHIFT         16U
> +#define FFA_VERSION_MAJOR_MASK          0x7FFFU
> +#define FFA_VERSION_MINOR_SHIFT         0U
> +#define FFA_VERSION_MINOR_MASK          0xFFFFU
> +#define MAKE_FFA_VERSION(major, minor)  \
> +        ((((major) & FFA_VERSION_MAJOR_MASK) << FFA_VERSION_MAJOR_SHIFT)=
 | \
> +         ((minor) & FFA_VERSION_MINOR_MASK))
> +
> +#define FFA_VERSION_1_0         MAKE_FFA_VERSION(1, 0)
> +#define FFA_VERSION_1_1         MAKE_FFA_VERSION(1, 1)
> +/* The minimal FF-A version of the SPMC that can be supported */
> +#define FFA_MIN_SPMC_VERSION    FFA_VERSION_1_1
> +
> +/*
> + * This is the version we want to use in communication with guests and S=
Ps.
> + * During negotiation with a guest or a SP we may need to lower it for
> + * that particular guest or SP.
> + */
> +#define FFA_MY_VERSION_MAJOR    1U
> +#define FFA_MY_VERSION_MINOR    1U
> +#define FFA_MY_VERSION          MAKE_FFA_VERSION(FFA_MY_VERSION_MAJOR, \
> +                                                 FFA_MY_VERSION_MINOR)
> +
> +/*
> + * The FF-A specification explicitly works with 4K pages as a measure of
> + * memory size, for example, FFA_RXTX_MAP takes one parameter "RX/TX pag=
e
> + * count" which is the number of contiguous 4K pages allocated. Xen may =
use
> + * a different page size depending on the configuration to avoid confusi=
on
> + * with PAGE_SIZE use a special define when it's a page size as in the F=
F-A
> + * specification.
> + */
> +#define FFA_PAGE_SIZE                   SZ_4K
> +
> +/*
> + * The number of pages used for each of the RX and TX buffers shared wit=
h
> + * the SPMC.
> + */
> +#define FFA_RXTX_PAGE_COUNT             1
> +
> +/*
> + * Limit the number of pages RX/TX buffers guests can map.
> + * TODO support a larger number.
> + */
> +#define FFA_MAX_RXTX_PAGE_COUNT         1
> +
> +/*
> + * Limit for shared buffer size. Please note that this define limits
> + * number of pages.
> + *
> + * FF-A doesn't have any direct requirements on GlobalPlatform or vice
> + * versa, but an implementation can very well use FF-A in order to provi=
de
> + * a GlobalPlatform interface on top.
> + *
> + * Global Platform specification for TEE requires that any TEE
> + * implementation should allow to share buffers with size of at least
> + * 512KB, defined in TEEC-1.0C page 24, Table 4-1,
> + * TEEC_CONFIG_SHAREDMEM_MAX_SIZE.
> + * Due to overhead which can be hard to predict exactly, double this num=
ber
> + * to give a safe margin.
> + */
> +#define FFA_MAX_SHM_PAGE_COUNT          (2 * SZ_512K / FFA_PAGE_SIZE)
> +
> +/*
> + * Limits the number of shared buffers that guest can have at once. This
> + * is to prevent case, when guests trick XEN into exhausting its own
> + * memory by allocating many small buffers. This value has been chosen
> + * arbitrarily.
> + */
> +#define FFA_MAX_SHM_COUNT               32
> +
> +/*
> + * The time we wait until trying to tear down a domain again if it was
> + * blocked initially.
> + */
> +#define FFA_CTX_TEARDOWN_DELAY          SECONDS(1)
> +
> +/* FF-A-1.1-REL0 section 10.9.2 Memory region handle, page 167 */
> +#define FFA_HANDLE_HYP_FLAG             BIT(63, ULL)
> +#define FFA_HANDLE_INVALID              0xffffffffffffffffULL
> +
> +/*
> + * Memory attributes: Normal memory, Write-Back cacheable, Inner shareab=
le
> + * Defined in FF-A-1.1-REL0 Table 10.18 at page 175.
> + */
> +#define FFA_NORMAL_MEM_REG_ATTR         0x2fU
> +/*
> + * Memory access permissions: Read-write
> + * Defined in FF-A-1.1-REL0 Table 10.15 at page 168.
> + */
> +#define FFA_MEM_ACC_RW                  0x2U
> +
> +/* FF-A-1.1-REL0 section 10.11.4 Flags usage, page 184-187 */
> +/* Clear memory before mapping in receiver */
> +#define FFA_MEMORY_REGION_FLAG_CLEAR            BIT(0, U)
> +/* Relayer may time slice this operation */
> +#define FFA_MEMORY_REGION_FLAG_TIME_SLICE       BIT(1, U)
> +/* Clear memory after receiver relinquishes it */
> +#define FFA_MEMORY_REGION_FLAG_CLEAR_RELINQUISH BIT(2, U)
> +/* Share memory transaction */
> +#define FFA_MEMORY_REGION_TRANSACTION_TYPE_SHARE (1U << 3)
> +
> +/*
> + * Flags and field values used for the MSG_SEND_DIRECT_REQ/RESP:
> + * BIT(31): Framework or partition message
> + * BIT(7-0): Message type for frameworks messages
> + */
> +#define FFA_MSG_FLAG_FRAMEWORK          BIT(31, U)
> +#define FFA_MSG_TYPE_MASK               0xFFU;
> +#define FFA_MSG_PSCI                    0x0U
> +#define FFA_MSG_SEND_VM_CREATED         0x4U
> +#define FFA_MSG_RESP_VM_CREATED         0x5U
> +#define FFA_MSG_SEND_VM_DESTROYED       0x6U
> +#define FFA_MSG_RESP_VM_DESTROYED       0x7U
> +
> +/*
> + * Flags to determine partition properties in FFA_PARTITION_INFO_GET ret=
urn
> + * message:
> + * BIT(0): Supports receipt of direct requests
> + * BIT(1): Can send direct requests
> + * BIT(2): Can send and receive indirect messages
> + * BIT(3): Supports receipt of notifications
> + * BIT(4-5): Partition ID is a PE endpoint ID
> + * BIT(6): Partition must be informed about each VM that is created by
> + *         the Hypervisor
> + * BIT(7): Partition must be informed about each VM that is destroyed by
> + *         the Hypervisor
> + * BIT(8): Partition runs in the AArch64 execution state else AArch32
> + *         execution state
> + */
> +#define FFA_PART_PROP_DIRECT_REQ_RECV   BIT(0, U)
> +#define FFA_PART_PROP_DIRECT_REQ_SEND   BIT(1, U)
> +#define FFA_PART_PROP_INDIRECT_MSGS     BIT(2, U)
> +#define FFA_PART_PROP_RECV_NOTIF        BIT(3, U)
> +#define FFA_PART_PROP_IS_TYPE_MASK      (3U << 4)
> +#define FFA_PART_PROP_IS_PE_ID          (0U << 4)
> +#define FFA_PART_PROP_IS_SEPID_INDEP    (1U << 4)
> +#define FFA_PART_PROP_IS_SEPID_DEP      (2U << 4)
> +#define FFA_PART_PROP_IS_AUX_ID         (3U << 4)
> +#define FFA_PART_PROP_NOTIF_CREATED     BIT(6, U)
> +#define FFA_PART_PROP_NOTIF_DESTROYED   BIT(7, U)
> +#define FFA_PART_PROP_AARCH64_STATE     BIT(8, U)
> +
> +/*
> + * Flag used as parameter to FFA_PARTITION_INFO_GET to return partition
> + * count only.
> + */
> +#define FFA_PARTITION_INFO_GET_COUNT_FLAG BIT(0, U)
> +
> +/* Function IDs */
> +#define FFA_ERROR                       0x84000060U
> +#define FFA_SUCCESS_32                  0x84000061U
> +#define FFA_SUCCESS_64                  0xC4000061U
> +#define FFA_INTERRUPT                   0x84000062U
> +#define FFA_VERSION                     0x84000063U
> +#define FFA_FEATURES                    0x84000064U
> +#define FFA_RX_ACQUIRE                  0x84000084U
> +#define FFA_RX_RELEASE                  0x84000065U
> +#define FFA_RXTX_MAP_32                 0x84000066U
> +#define FFA_RXTX_MAP_64                 0xC4000066U
> +#define FFA_RXTX_UNMAP                  0x84000067U
> +#define FFA_PARTITION_INFO_GET          0x84000068U
> +#define FFA_ID_GET                      0x84000069U
> +#define FFA_SPM_ID_GET                  0x84000085U
> +#define FFA_MSG_WAIT                    0x8400006BU
> +#define FFA_MSG_YIELD                   0x8400006CU
> +#define FFA_RUN                         0x8400006DU
> +#define FFA_MSG_SEND2                   0x84000086U
> +#define FFA_MSG_SEND_DIRECT_REQ_32      0x8400006FU
> +#define FFA_MSG_SEND_DIRECT_REQ_64      0xC400006FU
> +#define FFA_MSG_SEND_DIRECT_RESP_32     0x84000070U
> +#define FFA_MSG_SEND_DIRECT_RESP_64     0xC4000070U
> +#define FFA_MEM_DONATE_32               0x84000071U
> +#define FFA_MEM_DONATE_64               0xC4000071U
> +#define FFA_MEM_LEND_32                 0x84000072U
> +#define FFA_MEM_LEND_64                 0xC4000072U
> +#define FFA_MEM_SHARE_32                0x84000073U
> +#define FFA_MEM_SHARE_64                0xC4000073U
> +#define FFA_MEM_RETRIEVE_REQ_32         0x84000074U
> +#define FFA_MEM_RETRIEVE_REQ_64         0xC4000074U
> +#define FFA_MEM_RETRIEVE_RESP           0x84000075U
> +#define FFA_MEM_RELINQUISH              0x84000076U
> +#define FFA_MEM_RECLAIM                 0x84000077U
> +#define FFA_MEM_FRAG_RX                 0x8400007AU
> +#define FFA_MEM_FRAG_TX                 0x8400007BU
> +#define FFA_MSG_SEND                    0x8400006EU
> +#define FFA_MSG_POLL                    0x8400006AU
> +
> +struct ffa_ctx {
> +    void *rx;
> +    const void *tx;
> +    struct page_info *rx_pg;
> +    struct page_info *tx_pg;
> +    /* Number of 4kB pages in each of rx/rx_pg and tx/tx_pg */
> +    unsigned int page_count;
> +    /* FF-A version used by the guest */
> +    uint32_t guest_vers;
> +    bool rx_is_free;
> +    /* Used shared memory objects, struct ffa_shm_mem */
> +    struct list_head shm_list;
> +    /* Number of allocated shared memory object */
> +    unsigned int shm_count;
> +    /*
> +     * tx_lock is used to serialize access to tx
> +     * rx_lock is used to serialize access to rx
> +     * lock is used for the rest in this struct
> +     */
> +    spinlock_t tx_lock;
> +    spinlock_t rx_lock;
> +    spinlock_t lock;
> +    /* Used if domain can't be torn down immediately */
> +    struct domain *teardown_d;
> +    struct list_head teardown_list;
> +    s_time_t teardown_expire;
> +    /*
> +     * Used for ffa_domain_teardown() to keep track of which SPs should =
be
> +     * notified that this guest is being destroyed.
> +     */
> +    unsigned long vm_destroy_bitmap[];
> +};
> +
> +static inline uint16_t ffa_get_vm_id(const struct domain *d)
> +{
> +    /* +1 since 0 is reserved for the hypervisor in FF-A */
> +    return d->domain_id + 1;
> +}
> +
> +static inline void ffa_set_regs(struct cpu_user_regs *regs, register_t v=
0,
> +                                register_t v1, register_t v2, register_t=
 v3,
> +                                register_t v4, register_t v5, register_t=
 v6,
> +                                register_t v7)
> +{
> +        set_user_reg(regs, 0, v0);
> +        set_user_reg(regs, 1, v1);
> +        set_user_reg(regs, 2, v2);
> +        set_user_reg(regs, 3, v3);
> +        set_user_reg(regs, 4, v4);
> +        set_user_reg(regs, 5, v5);
> +        set_user_reg(regs, 6, v6);
> +        set_user_reg(regs, 7, v7);
> +}
> +
> +static inline void ffa_set_regs_error(struct cpu_user_regs *regs,
> +                                      uint32_t error_code)
> +{
> +    ffa_set_regs(regs, FFA_ERROR, 0, error_code, 0, 0, 0, 0, 0);
> +}
> +
> +static inline void ffa_set_regs_success(struct cpu_user_regs *regs,
> +                                        uint32_t w2, uint32_t w3)
> +{
> +    ffa_set_regs(regs, FFA_SUCCESS_32, 0, w2, w3, 0, 0, 0, 0);
> +}
> +
> +static inline int32_t ffa_get_ret_code(const struct arm_smccc_1_2_regs *=
resp)
> +{
> +    switch ( resp->a0 )
> +    {
> +    case FFA_ERROR:
> +        if ( resp->a2 )
> +            return resp->a2;
> +        else
> +            return FFA_RET_NOT_SUPPORTED;
> +    case FFA_SUCCESS_32:
> +    case FFA_SUCCESS_64:
> +        return FFA_RET_OK;
> +    default:
> +        return FFA_RET_NOT_SUPPORTED;
> +    }
> +}
> +
> +static inline int32_t ffa_simple_call(uint32_t fid, register_t a1,
> +                                      register_t a2, register_t a3,
> +                                      register_t a4)
> +{
> +    const struct arm_smccc_1_2_regs arg =3D {
> +        .a0 =3D fid,
> +        .a1 =3D a1,
> +        .a2 =3D a2,
> +        .a3 =3D a3,
> +        .a4 =3D a4,
> +    };
> +    struct arm_smccc_1_2_regs resp;
> +
> +    arm_smccc_1_2_smc(&arg, &resp);
> +
> +    return ffa_get_ret_code(&resp);
> +}
> +
> +#endif /*__FFA_PRIVATE_H__*/
> --=20
> 2.34.1
>=20



From xen-devel-bounces@lists.xenproject.org Wed Mar 27 13:34:34 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 13:34:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698527.1090287 (Exim 4.92)
	(envelope-from )
	id 1rpTQB-0008Vj-W5; Wed, 27 Mar 2024 13:34:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698527.1090287; Wed, 27 Mar 2024 13:34:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpTQB-0008Vc-TX; Wed, 27 Mar 2024 13:34:27 +0000
Received: by outflank-mailman (input) for mailman id 698527;
 Wed, 27 Mar 2024 13:34:26 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpTQ9-0008VU-89
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 13:34:26 +0000
Received: from desiato.infradead.org (desiato.infradead.org
 [2001:8b0:10b:1:d65d:64ff:fe57:4e05])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b8f2390c-ec3e-11ee-afe3-a90da7624cb6;
 Wed, 27 Mar 2024 14:34:23 +0100 (CET)
Received: from [2a00:23ee:1868:3da7:4441:744d:10c:c781] (helo=[IPv6:::1])
 by desiato.infradead.org with esmtpsa (Exim 4.97.1 #2 (Red Hat Linux))
 id 1rpTQ2-00000000H0t-3z9v; Wed, 27 Mar 2024 13:34:19 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b8f2390c-ec3e-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=desiato.20200630; h=Content-Transfer-Encoding:Content-Type
	:MIME-Version:Message-ID:References:In-Reply-To:Subject:CC:To:From:Date:
	Sender:Reply-To:Content-ID:Content-Description;
	bh=a+mnVz+I2LBdh7f3Jeku0JCwAoJyIxFVfnocz+i6RMc=; b=q+v5/FPbwtAD6uQ9dCHGbJREjz
	H800nx781N9tH0ZcPPk9yn5Ape1VheAXWcyBkwRNqKh4v/J6DHpXEnVP9Qz74WQNMJbQVIsdax39L
	DlLF3RislEyl4kLLjeTkS7dO2SAN6YZChYNLRkkTF2vkDLvc9T3y0pW/3wF6+9ZO7wnocnQ00G53r
	KBhD2vc3Jo90OAxsDRunIY0TlD0Q9Lwepy7zWNB83EJpkEV4zhYDQ6il5F8K101e8mWUJhr+G9rSb
	4A+Q6ifEF4oA7e6058Z6Vrd6MQkld5/dNz/qhri2QxMR/MFmkWIOk/jAPxDKuKeFdMgjEPMoFD8rB
	Bv2BC0qg==;
Date: Wed, 27 Mar 2024 13:34:14 +0000
From: David Woodhouse 
To: Anthony PERARD ,
 =?ISO-8859-1?Q?Philippe_Mathieu-Daud=E9?= 
CC: David Woodhouse , qemu-devel@nongnu.org,
 =?ISO-8859-1?Q?Alex_Benn=E9e?= ,
 Paul Durrant , qemu-arm@nongnu.org,
 Paolo Bonzini ,
 Stefano Stabellini ,
 Richard Henderson ,
 xen-devel@lists.xenproject.org, qemu-block@nongnu.org, kvm@vger.kernel.org,
 Thomas Huth , Kevin Wolf ,
 Hanna Reitz 
Subject: =?US-ASCII?Q?Re=3A_=5BRFC_PATCH-for-9=2E0_v2_?=
 =?US-ASCII?Q?09/19=5D_hw/block/xen=5Fblkif=3A?=
 =?US-ASCII?Q?_Align_structs_with_QEMU=5FA?=
 =?US-ASCII?Q?LIGNED=28=29_instead_of_=23pragma?=
User-Agent: K-9 Mail for Android
In-Reply-To: <76ae46e6-c226-49d0-890e-c8fd64172569@perard>
References: <20231114143816.71079-1-philmd@linaro.org> <20231114143816.71079-10-philmd@linaro.org> <76ae46e6-c226-49d0-890e-c8fd64172569@perard>
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-SRS-Rewrite: SMTP reverse-path rewritten from  by desiato.infradead.org. See http://www.infradead.org/rpr.html

On 27 March 2024 13:31:52 GMT, Anthony PERARD  wrote:
>On Tue, Nov 14, 2023 at 03:38:05PM +0100, Philippe Mathieu-Daud=C3=A9 wro=
te:
>> Except imported source files, QEMU code base uses
>> the QEMU_ALIGNED() macro to align its structures=2E
>
>This patch only convert the alignment, but discard pack=2E We need both o=
r
>the struct is changed=2E

Which means we need some build-time asserts on struct size and field offse=
ts=2E That should never have passed a build test=2E



From xen-devel-bounces@lists.xenproject.org Wed Mar 27 13:37:38 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 13:37:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698533.1090297 (Exim 4.92)
	(envelope-from )
	id 1rpTTF-0000iB-DN; Wed, 27 Mar 2024 13:37:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698533.1090297; Wed, 27 Mar 2024 13:37:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpTTF-0000i4-Ar; Wed, 27 Mar 2024 13:37:37 +0000
Received: by outflank-mailman (input) for mailman id 698533;
 Wed, 27 Mar 2024 13:37:35 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpTTD-0000hx-E2
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 13:37:35 +0000
Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com
 [2a00:1450:4864:20::334])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2a790f1d-ec3f-11ee-a1ef-f123f15fe8a2;
 Wed, 27 Mar 2024 14:37:33 +0100 (CET)
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-4149521d76aso3569485e9.3
 for ; Wed, 27 Mar 2024 06:37:33 -0700 (PDT)
Received: from perard.uk.xensource.com (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 q18-20020a05600c46d200b0041488978873sm2166371wmo.44.2024.03.27.06.37.32
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 27 Mar 2024 06:37:32 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2a790f1d-ec3f-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1711546653; x=1712151453; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=smTZluOGn/fUn3D+QqeEnI8LdPKMkXjE5Ourcjod5Ew=;
        b=abBsX0zJ32pob8p877gEuF0SyJR7W3DQv0v7i+cH1O3FoPuONdRq5v9TI2Wgf54Wep
         VNKOa2szqwoBx6JG1gbLb11GNFOvSR1vCvc0aIUJvWZQS/O42/8Y9O+j1sLxxXs8evCg
         5LsCT5+swyjVJ3sVZC6A2P6RyAGa/lXewKnQU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711546653; x=1712151453;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=smTZluOGn/fUn3D+QqeEnI8LdPKMkXjE5Ourcjod5Ew=;
        b=k3LTL5qlwrcNP0GITpdU266fKVQCGzHoCwf/wghCDhxdW9FmbFk83E2UK8Zjf9MFnC
         +FEOsP9QUcn+Wo1tBzieg/uqv1ri8ClsTF1D+uzu7mPntZ/6owb6/SALd5Hm1cXiZB8B
         0xymtO7jCpPfy13Ug+e5b0cmD3CDDv/liBLJOR/G7EyJ5LYZN3lSoD+SjIYZOHVE5kj5
         Ty7ZVhFyZaoXGtnNL/BdPd03n+rt9t+Ud0toHucvUBHjMVMyU4pSJ0KqyKqSLfmQejtw
         IRm59AZX3Vof83CeOnYk5DMgWTOWG0tJUKl9/WUTmn2ONcfjXG0zxGrj7WNBN65/gInK
         uIcw==
X-Forwarded-Encrypted: i=1; AJvYcCUwHbzDQAOtqO0vXzWtpXtTJdWsW0ZIK4skoyUU/Q11YDxQMN5RR1XYY3GiKOodHuyQ7M7O7cNycj34H7r0AAD5oACz/I7QfjbYYIOrbNA=
X-Gm-Message-State: AOJu0YxqdG5Duw3PWBJ65Tk/EsM+BTV5qsR5AMGERHe5hGEm+8XcYV0O
	BIy+ZOsZ7/hzH/iIO+NZEGoyu0ZgPtCuaB1IUrVLcBUcK5rZI/8rTZkIPtlCtAw=
X-Google-Smtp-Source: AGHT+IHmCd6Z7pLRTa8judRkvI7RAqt4OfBOEutc0X/kcSqKXxmUpEJ5ND/lGGVRsxmC7KvW/3fTRQ==
X-Received: by 2002:a05:600c:1c8f:b0:414:669b:aa9 with SMTP id k15-20020a05600c1c8f00b00414669b0aa9mr9727wms.28.1711546653009;
        Wed, 27 Mar 2024 06:37:33 -0700 (PDT)
Date: Wed, 27 Mar 2024 13:37:31 +0000
From: Anthony PERARD 
To: Philippe =?iso-8859-1?Q?Mathieu-Daud=E9?= 
Cc: David Woodhouse , qemu-devel@nongnu.org,
	Alex =?iso-8859-1?Q?Benn=E9e?= ,
	Paul Durrant , qemu-arm@nongnu.org,
	Paolo Bonzini ,
	David Woodhouse ,
	Stefano Stabellini ,
	Richard Henderson ,
	xen-devel@lists.xenproject.org, qemu-block@nongnu.org,
	kvm@vger.kernel.org, Thomas Huth ,
	Peter Maydell ,
	"Michael S. Tsirkin" ,
	Marcel Apfelbaum ,
	Eduardo Habkost 
Subject: Re: [PATCH-for-9.0 v2 11/19] hw/xen/xen_arch_hvm: Rename prototypes
 using 'xen_arch_' prefix
Message-ID: <3c553c67-c54c-4156-8d69-bef3476b63a2@perard>
References: <20231114143816.71079-1-philmd@linaro.org>
 <20231114143816.71079-12-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20231114143816.71079-12-philmd@linaro.org>

On Tue, Nov 14, 2023 at 03:38:07PM +0100, Philippe Mathieu-Daud wrote:
> Use a common 'xen_arch_' prefix for architecture-specific functions.
> Rename xen_arch_set_memory() and xen_arch_handle_ioreq().
> 
> Signed-off-by: Philippe Mathieu-Daud 
> Reviewed-by: David Woodhouse 
> Reviewed-by: Richard Henderson 

Acked-by: Anthony PERARD 

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Wed Mar 27 13:38:49 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 13:38:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698535.1090308 (Exim 4.92)
	(envelope-from )
	id 1rpTUN-0001PG-Mw; Wed, 27 Mar 2024 13:38:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698535.1090308; Wed, 27 Mar 2024 13:38:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpTUN-0001P9-KA; Wed, 27 Mar 2024 13:38:47 +0000
Received: by outflank-mailman (input) for mailman id 698535;
 Wed, 27 Mar 2024 13:38:45 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpTUL-0001NX-Ox
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 13:38:45 +0000
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com
 [2a00:1450:4864:20::534])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 544539e4-ec3f-11ee-a1ef-f123f15fe8a2;
 Wed, 27 Mar 2024 14:38:43 +0100 (CET)
Received: by mail-ed1-x534.google.com with SMTP id
 4fb4d7f45d1cf-56c0a249bacso4465110a12.1
 for ; Wed, 27 Mar 2024 06:38:43 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 q16-20020a170906389000b00a46a643b6fbsm5541812ejd.15.2024.03.27.06.38.42
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 27 Mar 2024 06:38:42 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 544539e4-ec3f-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711546723; x=1712151523; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=uUmin0KeCmk79N0Qye7ojgvhlwlJRFIwI/Z9TBSx4QA=;
        b=Nt90FTvnxQpMqFawB1B0TllAb272njSNXFlbminWSUsD1hUDE9G044ilgFXM5U0TLC
         Z6JCHIBwg65E427Yg0dj6x2dnO2eO+hz+mkFgu0B5UmGCfZ6HebHPbc1xg7w8KxePpJg
         Ka9Q653MgIgxCbo1NN9LupTXNqacMOHnv6brG6OY6f3uu1HdCpoG+ZevRV6gftaLtQX6
         Ez+Fsk1h1m7lugECnSF0mcLO1TIcwrSqkL14C5l2ou+6SgLzBQUfnkKgDV+P2Niw9njy
         Vgf0xVBV3COLG2hTm0o2S9hpGgKr1SsAaIdDKog2021n+LcF1Vc6l2XjrHwtMPRf3NJM
         i0Hw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711546723; x=1712151523;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=uUmin0KeCmk79N0Qye7ojgvhlwlJRFIwI/Z9TBSx4QA=;
        b=qB/6+UY5VwCAqgU99jVQkApcavGgv7KoVD77HBbXsnRVT9g93ccxZe/uRbrc/lEE04
         ERS+4JAHEEw7nbGRpZ67gLgGsg1E1wYAfS1xlLPOd+2OMXSGT2DiAkIe1wNhL4dZgsxL
         e2dp/Yz8dGGCTz3ueXiehN7rOGjQvvIlEmo8zQn53CF8NSLgSoNplJuCVRENqmdZVMBA
         Ycbm29D1z8e1WMyrC61BhRdlHCU+4lLEhktL4qOfyg3y2LtL8FKvXZmZ5VjKwvwWS4kI
         Bz2aZNPx5C2qcmXgcc+WTTbSElxpdLWndu1w6JQFTesAfhpyEj45dNUsz9Zca6hf9PRe
         FG6w==
X-Forwarded-Encrypted: i=1; AJvYcCVqX0H4JxdVyCzX5QwV+5zFybdOxbt2InHZfvaWTTaguk0GB0FeMAJ2CSSyWXW0iHn40Y5cgZEUSrjM2RYOt8b4Dn1wdPsNqt4oXm41rAI=
X-Gm-Message-State: AOJu0YwgVX6U4g2O+QFRoK/Ap1DatV0m7/TjTAuaoJsstiCk9ORWO0kc
	2UuK2t+JgBMvE1axO63C2rx3XQIoEfSNIoSqiIgwDZta0182MpeyPuw3upHgHA==
X-Google-Smtp-Source: AGHT+IGe2fmggLZTVfGQtYqtvXX+zl3Pwthf2wm5kE+k5y5ORxQNWlhdmkw/G6OCcn5Y94yKy6CrOQ==
X-Received: by 2002:a17:906:16c5:b0:a47:3526:2e0f with SMTP id t5-20020a17090616c500b00a4735262e0fmr843890ejd.75.1711546723186;
        Wed, 27 Mar 2024 06:38:43 -0700 (PDT)
Message-ID: 
Date: Wed, 27 Mar 2024 14:38:41 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 08/14] xen/page_alloc: introduce preserved page flags
 macro
Content-Language: en-US
To: Julien Grall , Carlo Nonato 
Cc: Andrew Cooper ,
 George Dunlap ,
 Stefano Stabellini , Wei Liu ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
 <20240315105902.160047-9-carlo.nonato@minervasys.tech>
 <3f615066-a792-493f-ba33-7667a6557c23@xen.org>
 <9e0f7ff3-5457-41e4-a1e4-bf75804fb900@xen.org>
 <255be735-f9fe-4e39-a24e-2f6aff91acc5@suse.com>
 
 <3427132d-9458-4447-b667-d2ef3c1f0569@suse.com>
 
 
 
 
 <54156e94-3630-49b1-8a22-5cd4206d565f@xen.org>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <54156e94-3630-49b1-8a22-5cd4206d565f@xen.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 27.03.2024 14:28, Julien Grall wrote:
> Hi Carlo,
> 
> On 27/03/2024 11:10, Carlo Nonato wrote:
>> Hi guys,
>>
>>> Question is: How would you justify such a change? IOW I'm not convinced
>>> (yet) this wants doing there.
>>
>> You mean in this series?
>>
>>> Looking at the code, the flag is originally set in
>>> alloc_domheap_pages(). So I guess it would make sense to do it in
>>> free_domheap_pages().
>>
>> We don't hold the heap_lock there.
> Regardless of the safety question (I will answer below), count_info is 
> not meant to be protected by heap_lock. The lock is protecting the heap 
> and ensure we are not corrupting them when there are concurrent call to 
> free_heap_pages().
> 
>  > Is it safe to change count_info without it?
> 
> count_info is meant to be accessed locklessly. The flag PGC_extra cannot 
> be set/clear concurrently because you can't allocate a page that has not 
> yet been freed.
> 
> So it would be fine to use clear_bit(..., ...);

Actually we hardly ever use clear_bit() on count_info. Normally we use
ordinary C operators. Atomic (and otherwise lockless) updates are useful
only if done like this everywhere.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Mar 27 13:40:43 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 13:40:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698537.1090317 (Exim 4.92)
	(envelope-from )
	id 1rpTWB-0003KL-2W; Wed, 27 Mar 2024 13:40:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698537.1090317; Wed, 27 Mar 2024 13:40:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpTWA-0003K0-Vu; Wed, 27 Mar 2024 13:40:38 +0000
Received: by outflank-mailman (input) for mailman id 698537;
 Wed, 27 Mar 2024 13:40:38 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpTW9-0003Ig-TS
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 13:40:38 +0000
Received: from EUR05-AM6-obe.outbound.protection.outlook.com
 (mail-am6eur05on20600.outbound.protection.outlook.com
 [2a01:111:f403:2612::600])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 97e7df40-ec3f-11ee-afe3-a90da7624cb6;
 Wed, 27 Mar 2024 14:40:37 +0100 (CET)
Received: from DUZPR01CA0073.eurprd01.prod.exchangelabs.com
 (2603:10a6:10:3c2::11) by AM0PR08MB5491.eurprd08.prod.outlook.com
 (2603:10a6:208:189::9) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.32; Wed, 27 Mar
 2024 13:40:29 +0000
Received: from DB3PEPF0000885B.eurprd02.prod.outlook.com
 (2603:10a6:10:3c2:cafe::fc) by DUZPR01CA0073.outlook.office365.com
 (2603:10a6:10:3c2::11) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.13 via Frontend
 Transport; Wed, 27 Mar 2024 13:40:29 +0000
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by
 DB3PEPF0000885B.mail.protection.outlook.com (10.167.242.6) with
 Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.7409.10
 via Frontend Transport; Wed, 27 Mar 2024 13:40:28 +0000
Received: ("Tessian outbound 1b0f2681ce6f:v300");
 Wed, 27 Mar 2024 13:40:27 +0000
Received: from b8af7c59bde7.1
 by 64aa7808-outbound-1.mta.getcheckrecipient.com id
 61A58749-2530-403B-B921-2475FC7D38FC.1; 
 Wed, 27 Mar 2024 13:40:20 +0000
Received: from EUR05-AM6-obe.outbound.protection.outlook.com
 by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id b8af7c59bde7.1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384);
 Wed, 27 Mar 2024 13:40:20 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com (2603:10a6:10:25a::24)
 by VE1PR08MB5774.eurprd08.prod.outlook.com (2603:10a6:800:1a1::24)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.32; Wed, 27 Mar
 2024 13:40:17 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::7fb0:6621:56b:22d5]) by DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::7fb0:6621:56b:22d5%3]) with mapi id 15.20.7409.031; Wed, 27 Mar 2024
 13:40:17 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 97e7df40-ec3f-11ee-afe3-a90da7624cb6
ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass;
 b=cjc3vXaz1qM31DOFRPzanc8RgQd1E6YJEi9dUjnNtD9itBgg8YWwscbcv2L+6pIyu74/mBugeTt99ut0bi2uN5gTptcYIQ45IpBWSisDwWIpwFCYMDRZrhTzjgEF3K9vFOJAmUCOkWaqFWgx66pJ26OgZMCSRNePvx5sc2jdxpXYA8JNjCC1OONOMfZX1QXTkS5wupZK87SzlF7WeGusuReWDYEe2T0A++Ttv8QOgnVNpSb8jM8eyUBd5YAZFajB364QYnhXHDXtKNT9NF9Iwb23rnZopIyYR3NpKbYi+ao2OjmFLt+QCTHmkCj/a+e5Qz+qn89AZlxZAxj1eGH5HA==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Zlp0+JBb9KPu2aI6oYQpE41ABBNtmljZS78IpzsE68M=;
 b=dhaw+uXy8q6x9ymose39dN3xH7aUP5NnEzCdJ2oseiR6pj/zJah/qQn5jLYPhYObdFs4cmKCD25Ip1Xsc9xeTExBeMkB9LNYxJO8MC2sB0noVaHHTp3HNEdzE0O4ucPyF0Le4mZ3XR7/LltXj5dP9AYrJYpX4HaymmCwem47SMiCp8ta/0nc9+ISYzYitMHpt/VZ/xcXVW/O0/u9rmbymBsVtwFNqCpRgTvMQBFBhxf4CrpH0Dnec/KMfk+jniWgpQ7Go2aTXFruZdv47acH+UgFJhHd5Nm2VI7Km7CLFthg1hkCt7l1w8zlPQX1LGALd29s3k6QNtnq/ITvWZu4iA==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 63.35.35.123) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=arm.com;
 dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com;
 dkim=pass (signature was verified) header.d=armh.onmicrosoft.com; arc=pass (0
 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com]
 dmarc=[1,1,header.from=arm.com])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com;
 s=selector2-armh-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=Zlp0+JBb9KPu2aI6oYQpE41ABBNtmljZS78IpzsE68M=;
 b=srIk7TGcUG90UpTHMWmU2zoa9zQcpVRG5mm5qdr4DTEMq3BbkPlYZWE+lDM6d/cFQZ9NnCRHyifvDKjJJ10KM8XlV9hnkM90tqPzIZDNXxPS7VgSJsL9jCxdPUykDatsurYxiDXfAFILyuj01NhJEx5iHwGGwBvzWUpgM+xUzqs=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=armh.onmicrosoft.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 63.35.35.123 as permitted sender) receiver=protection.outlook.com;
 client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
 pr=C
X-CheckRecipientChecked: true
X-CR-MTA-CID: 25edfc42cf543d17
X-CR-MTA-TID: 64aa7808
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=MEbakngUw5l4wh4sgjtSQRYvQ8IhFRhhR2DYCbVkUb+MdtOSunhmCXPSe0jGaxiMO11vmhNc7eslPFs3RuBnF8ybUyH7Wi/K19eB/VyHsT/BZCsvfSkYpnTiTCLw/ktV4PkGCOv4EenkUA78NLtQOWdBNXpX6466j8hzgQWrkp77hjXLC+RvdtP+oX81Hjvk/kxGmC1V6w+VU4NboF1/SidKI8UiBHnxLhAQDn3esObR5ER8s7BvEfhks2qcy+6zrX0TmgVQirbHVLK/dyA8eqN6jxyDPuWOfB7CogOXrZu7OFoIqFpFdE6iBBNRRWegT838waW9vcFJCOfbsm+RaQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Zlp0+JBb9KPu2aI6oYQpE41ABBNtmljZS78IpzsE68M=;
 b=l17C+tiqiw57bB9xic8lf1E4htRPLb/UvqlktocJICvxnFjzqHr0lbEDI3F9lhX68LHdj+3hI397RsMkM7ATO55O3/dCPY5Pyd2Ig6JpA5LdWy8yzAz9RWsmiTndOUPainlbdzKXlmbGLFGqbhbOKE5to37zavSBmmp7ebA4aBWI2c3FEhsuj4l8XVhWoipJVOFfU5hdXacBUV+XFqc3GzBHS6yyyh1oxgsXO4mcrNihoiJOQ+2ErL/jmgTULG8UFZn1eQJHZ/eDCCw3MErjxRlukv8ECfeaQBXxwyqwW+3C8vGmhq9qIoE6LVUcxga+HkGOuCevX4aEMvLa3XR8Dw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass
 header.d=arm.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com;
 s=selector2-armh-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=Zlp0+JBb9KPu2aI6oYQpE41ABBNtmljZS78IpzsE68M=;
 b=srIk7TGcUG90UpTHMWmU2zoa9zQcpVRG5mm5qdr4DTEMq3BbkPlYZWE+lDM6d/cFQZ9NnCRHyifvDKjJJ10KM8XlV9hnkM90tqPzIZDNXxPS7VgSJsL9jCxdPUykDatsurYxiDXfAFILyuj01NhJEx5iHwGGwBvzWUpgM+xUzqs=
From: Bertrand Marquis 
To: Jens Wiklander 
CC: Xen-devel , "patches@linaro.org"
	, Volodymyr Babchuk , Stefano
 Stabellini , Julien Grall , Michal
 Orzel 
Subject: Re: [XEN PATCH 3/6] xen/arm: ffa: separate memory sharing routines
Thread-Topic: [XEN PATCH 3/6] xen/arm: ffa: separate memory sharing routines
Thread-Index: AQHafphXShQMyqELBEGnpkE0sEGolbFLm16A
Date: Wed, 27 Mar 2024 13:40:17 +0000
Message-ID: 
References: <20240325093904.3466092-1-jens.wiklander@linaro.org>
 <20240325093904.3466092-4-jens.wiklander@linaro.org>
In-Reply-To: <20240325093904.3466092-4-jens.wiklander@linaro.org>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3774.200.91.1.1)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DB9PR08MB6588:EE_|VE1PR08MB5774:EE_|DB3PEPF0000885B:EE_|AM0PR08MB5491:EE_
X-MS-Office365-Filtering-Correlation-Id: 2bdaf1c0-73f1-4bad-8dc4-08dc4e6376be
x-checkrecipientrouted: true
nodisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted: BCL:0;
X-Microsoft-Antispam-Message-Info-Original:
 reU4V4400pbZbGUWWba9dvwPDOcOlfVRlncLaruWE1r3ukEjDqWDtbvz2m98PRFHGxreYD2qQojC/VNBx+yzQgtNquXIe16BJSXzOY6F51+oRbnOQBemzfA/eumgTt5me8vwn9HcnoLj4w90/G7b+xrhknY9fWpD2SSASvaL+qV5B3tWCW/Gv0phgjeeuMpn6NezAzrRK+SwfUKK3rYl87XtQoHEy2atE0QIAzGbEDvEZfstMszL4baLi0nCqo0Vec+FMMFoaowa3Ikdl0WsmP+MiosgAm4lfW4T9zjBlpf8r/DZ3RGOQxf2r4utQwmOWrtmUUfI3XjYKFP9BhIDmy7+vH7EziZUISfjC11RKARHflkmL+NPDLblEQ1NreW+xN3nKrrf1h95+Izk5L5jI79qmy+6qG91uJAamoYJXUrblLM65mqARIGbhJrrd8wmY6vosweq0C/cMTy/3LuM/728AP31bU1HHWjPrm3FrunxZLghlVw99oaFV0vb7qD8WUSS6nFUzorfM5rflf3jc6g/zzNdeq5bW4zvrmID3w8YrH4SOIOW7jGdt77P+/N0KnonuMbrZUWmCvL0YMjii9nGoFyMJ/1vSwEiaLUFOt0hUd3Xqg16lpioWKsuGWDnn7i1aLkA8n2pdisP1aZfMLveRdQ5qZ+WBwhn085tGjz2mtypSlOGTky5mu+f0t7h2SZpIH0sJBkk8r7iwUr7LtmNOatjaR9ptyCUINils+o=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB9PR08MB6588.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(366007)(1800799015)(376005)(38070700009);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR08MB5774
Original-Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 DB3PEPF0000885B.eurprd02.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	aa87161b-c798-4e7e-6427-08dc4e6370af
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	un0vRAjYvIvlLQ+EZDG0gd3uyxqSHjwCcNlBg8Qg2Z+tkCoTq6tclP8o/C5NI495D4MPfiJMd3VvxV5s/Env7kBVMfbJqBI466QBOH6W1NbVro9MGoifrrKV1Yqm5xOJOZRgDlfjOYvpn5aLNvBnrG9wKQqvuUOPgX/Q6LdtsLBkI8M8jMmi1/rZxvHI7Q+a/P/LGPTXk9WAc017FxNaKtfNBG94yKuco765BdmFQyQ22FFhBYfr5JPk5g5voNoKM35F4wjaBtrHgdopLnvHcNMnP71mjVxwkpKD/vg2CMqHxN4K4pyl3zdm/V5X266e4xabiwDR64xPGzIvxzCmP5R+tsViJ6ryddXnevO6+YMK9lLtwTSYGuJMBBorKnNEsBX8x2sljmnjus+T4CeKukmmWrmjNHjzcvicGVyjmTR5Gt0bu/w9UQEbdmgxY15x88KVV0GnHN83gTeniCiMk4PlWjVkfwHUfrgrY/yjrRhO34kwL37hvGyPUIX1g/9iGPP/xG5P1iiZbIdHr8+lBgbUFQXsdnarnqM4Y+55pFbgIhpFP0Yyh2gM/3w4kB/Agnw/JxFELzIt5x5RDgVaI5USRzlR0OfZ1p5d9kh9HvRIf4kv+6TRUSTdpyfL7VC+lmeGfS6QUVLvEn82NF2pkNg1Llyab/Y61CiApTz0o1QKCnwcU5DbNJF+8d0GTtW7wJjhKQ5wQEmlk22EKjv+G1/1S44YphzQ0IG0CutCX4lpTzJelui5NB2W6DBxuyXw
X-Forefront-Antispam-Report:
	CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com;CAT:NONE;SFS:(13230031)(36860700004)(82310400014)(1800799015)(376005);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Mar 2024 13:40:28.0696
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 2bdaf1c0-73f1-4bad-8dc4-08dc4e6376be
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DB3PEPF0000885B.eurprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB5491

Hi Jens,

> On 25 Mar 2024, at 10:39, Jens Wiklander  wrot=
e:
>=20
> Move memory sharing routines into a separate file for easier navigation
> in the source code.
>=20
> Add ffa_shm_domain_destroy() to isolate the ffa_shm things in
> ffa_domain_teardown_continue().
>=20
> Signed-off-by: Jens Wiklander 

With the copyright date mentioned after fixed (which can be done on commit)=
:
Reviewed-by: Bertrand Marquis  ---
> xen/arch/arm/tee/Makefile      |   1 +
> xen/arch/arm/tee/ffa.c         | 708 +--------------------------------
> xen/arch/arm/tee/ffa_private.h |  10 +
> xen/arch/arm/tee/ffa_shm.c     | 708 +++++++++++++++++++++++++++++++++
> 4 files changed, 729 insertions(+), 698 deletions(-)
> create mode 100644 xen/arch/arm/tee/ffa_shm.c
>=20
> diff --git a/xen/arch/arm/tee/Makefile b/xen/arch/arm/tee/Makefile
> index 58a1015e40e0..0e683d23aa9d 100644
> --- a/xen/arch/arm/tee/Makefile
> +++ b/xen/arch/arm/tee/Makefile
> @@ -1,3 +1,4 @@
> obj-$(CONFIG_FFA) +=3D ffa.o
> +obj-$(CONFIG_FFA) +=3D ffa_shm.o
> obj-y +=3D tee.o
> obj-$(CONFIG_OPTEE) +=3D optee.o
> diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
> index 259851f20bdb..db36292dc52f 100644
> --- a/xen/arch/arm/tee/ffa.c
> +++ b/xen/arch/arm/tee/ffa.c
> @@ -84,92 +84,6 @@ struct ffa_partition_info_1_1 {
>     uint8_t uuid[16];
> };
>=20
> -/* Constituent memory region descriptor */
> -struct ffa_address_range {
> -    uint64_t address;
> -    uint32_t page_count;
> -    uint32_t reserved;
> -};
> -
> -/* Composite memory region descriptor */
> -struct ffa_mem_region {
> -    uint32_t total_page_count;
> -    uint32_t address_range_count;
> -    uint64_t reserved;
> -    struct ffa_address_range address_range_array[];
> -};
> -
> -/* Memory access permissions descriptor */
> -struct ffa_mem_access_perm {
> -    uint16_t endpoint_id;
> -    uint8_t perm;
> -    uint8_t flags;
> -};
> -
> -/* Endpoint memory access descriptor */
> -struct ffa_mem_access {
> -    struct ffa_mem_access_perm access_perm;
> -    uint32_t region_offs;
> -    uint64_t reserved;
> -};
> -
> -/* Lend, donate or share memory transaction descriptor */
> -struct ffa_mem_transaction_1_0 {
> -    uint16_t sender_id;
> -    uint8_t mem_reg_attr;
> -    uint8_t reserved0;
> -    uint32_t flags;
> -    uint64_t handle;
> -    uint64_t tag;
> -    uint32_t reserved1;
> -    uint32_t mem_access_count;
> -    struct ffa_mem_access mem_access_array[];
> -};
> -
> -struct ffa_mem_transaction_1_1 {
> -    uint16_t sender_id;
> -    uint16_t mem_reg_attr;
> -    uint32_t flags;
> -    uint64_t handle;
> -    uint64_t tag;
> -    uint32_t mem_access_size;
> -    uint32_t mem_access_count;
> -    uint32_t mem_access_offs;
> -    uint8_t reserved[12];
> -};
> -
> -/* Calculate offset of struct ffa_mem_access from start of buffer */
> -#define MEM_ACCESS_OFFSET(access_idx) \
> -    ( sizeof(struct ffa_mem_transaction_1_1) + \
> -      ( access_idx ) * sizeof(struct ffa_mem_access) )
> -
> -/* Calculate offset of struct ffa_mem_region from start of buffer */
> -#define REGION_OFFSET(access_count, region_idx) \
> -    ( MEM_ACCESS_OFFSET(access_count) + \
> -      ( region_idx ) * sizeof(struct ffa_mem_region) )
> -
> -/* Calculate offset of struct ffa_address_range from start of buffer */
> -#define ADDR_RANGE_OFFSET(access_count, region_count, range_idx) \
> -    ( REGION_OFFSET(access_count, region_count) + \
> -      ( range_idx ) * sizeof(struct ffa_address_range) )
> -
> -/*
> - * The parts needed from struct ffa_mem_transaction_1_0 or struct
> - * ffa_mem_transaction_1_1, used to provide an abstraction of difference=
 in
> - * data structures between version 1.0 and 1.1. This is just an internal
> - * interface and can be changed without changing any ABI.
> - */
> -struct ffa_mem_transaction_int {
> -    uint16_t sender_id;
> -    uint8_t mem_reg_attr;
> -    uint8_t flags;
> -    uint8_t mem_access_size;
> -    uint8_t mem_access_count;
> -    uint16_t mem_access_offs;
> -    uint64_t handle;
> -    uint64_t tag;
> -};
> -
> /* Endpoint RX/TX descriptor */
> struct ffa_endpoint_rxtx_descriptor_1_0 {
>     uint16_t sender_id;
> @@ -185,15 +99,6 @@ struct ffa_endpoint_rxtx_descriptor_1_1 {
>     uint32_t tx_region_offs;
> };
>=20
> -struct ffa_shm_mem {
> -    struct list_head list;
> -    uint16_t sender_id;
> -    uint16_t ep_id;     /* endpoint, the one lending */
> -    uint64_t handle;    /* FFA_HANDLE_INVALID if not set yet */
> -    unsigned int page_count;
> -    struct page_info *pages[];
> -};
> -
> /* Negotiated FF-A version to use with the SPMC */
> static uint32_t __ro_after_init ffa_version;
>=20
> @@ -212,10 +117,10 @@ static uint16_t subscr_vm_destroyed_count __read_mo=
stly;
>  * for calls which uses our RX buffer to deliver a result we must call
>  * ffa_rx_release() to let the SPMC know that we're done with the buffer.
>  */
> -static void *ffa_rx __read_mostly;
> -static void *ffa_tx __read_mostly;
> -static DEFINE_SPINLOCK(ffa_rx_buffer_lock);
> -static DEFINE_SPINLOCK(ffa_tx_buffer_lock);
> +void *ffa_rx __read_mostly;
> +void *ffa_tx __read_mostly;
> +DEFINE_SPINLOCK(ffa_rx_buffer_lock);
> +DEFINE_SPINLOCK(ffa_tx_buffer_lock);
>=20
>=20
> /* Used to track domains that could not be torn down immediately. */
> @@ -297,47 +202,6 @@ static int32_t ffa_rx_release(void)
>     return ffa_simple_call(FFA_RX_RELEASE, 0, 0, 0, 0);
> }
>=20
> -static int32_t ffa_mem_share(uint32_t tot_len, uint32_t frag_len,
> -                             register_t addr, uint32_t pg_count,
> -                             uint64_t *handle)
> -{
> -    struct arm_smccc_1_2_regs arg =3D {
> -        .a0 =3D FFA_MEM_SHARE_64,
> -        .a1 =3D tot_len,
> -        .a2 =3D frag_len,
> -        .a3 =3D addr,
> -        .a4 =3D pg_count,
> -    };
> -    struct arm_smccc_1_2_regs resp;
> -
> -    arm_smccc_1_2_smc(&arg, &resp);
> -
> -    switch ( resp.a0 )
> -    {
> -    case FFA_ERROR:
> -        if ( resp.a2 )
> -            return resp.a2;
> -        else
> -            return FFA_RET_NOT_SUPPORTED;
> -    case FFA_SUCCESS_32:
> -        *handle =3D regpair_to_uint64(resp.a3, resp.a2);
> -        return FFA_RET_OK;
> -    case FFA_MEM_FRAG_RX:
> -        *handle =3D regpair_to_uint64(resp.a2, resp.a1);
> -        if ( resp.a3 > INT32_MAX ) /* Impossible value */
> -            return FFA_RET_ABORTED;
> -        return resp.a3 & INT32_MAX;
> -    default:
> -        return FFA_RET_NOT_SUPPORTED;
> -    }
> -}
> -
> -static int32_t ffa_mem_reclaim(uint32_t handle_lo, uint32_t handle_hi,
> -                               uint32_t flags)
> -{
> -    return ffa_simple_call(FFA_MEM_RECLAIM, handle_lo, handle_hi, flags,=
 0);
> -}
> -
> static int32_t ffa_direct_req_send_vm(uint16_t sp_id, uint16_t vm_id,
>                                       uint8_t msg)
> {
> @@ -660,506 +524,6 @@ out:
>                  resp.a7 & mask);
> }
>=20
> -/*
> - * Gets all page and assigns them to the supplied shared memory object. =
If
> - * this function fails then the caller is still expected to call
> - * put_shm_pages() as a cleanup.
> - */
> -static int get_shm_pages(struct domain *d, struct ffa_shm_mem *shm,
> -                         const struct ffa_address_range *range,
> -                         uint32_t range_count, unsigned int start_page_i=
dx,
> -                         unsigned int *last_page_idx)
> -{
> -    unsigned int pg_idx =3D start_page_idx;
> -    gfn_t gfn;
> -    unsigned int n;
> -    unsigned int m;
> -    p2m_type_t t;
> -    uint64_t addr;
> -    uint64_t page_count;
> -
> -    for ( n =3D 0; n < range_count; n++ )
> -    {
> -        page_count =3D read_atomic(&range[n].page_count);
> -        addr =3D read_atomic(&range[n].address);
> -        for ( m =3D 0; m < page_count; m++ )
> -        {
> -            if ( pg_idx >=3D shm->page_count )
> -                return FFA_RET_INVALID_PARAMETERS;
> -
> -            gfn =3D gaddr_to_gfn(addr + m * FFA_PAGE_SIZE);
> -            shm->pages[pg_idx] =3D get_page_from_gfn(d, gfn_x(gfn), &t,
> -   P2M_ALLOC);
> -            if ( !shm->pages[pg_idx] )
> -                return FFA_RET_DENIED;
> -            /* Only normal RW RAM for now */
> -            if ( t !=3D p2m_ram_rw )
> -                return FFA_RET_DENIED;
> -            pg_idx++;
> -        }
> -    }
> -
> -    *last_page_idx =3D pg_idx;
> -
> -    return FFA_RET_OK;
> -}
> -
> -static void put_shm_pages(struct ffa_shm_mem *shm)
> -{
> -    unsigned int n;
> -
> -    for ( n =3D 0; n < shm->page_count && shm->pages[n]; n++ )
> -    {
> -        put_page(shm->pages[n]);
> -        shm->pages[n] =3D NULL;
> -    }
> -}
> -
> -static bool inc_ctx_shm_count(struct domain *d, struct ffa_ctx *ctx)
> -{
> -    bool ret =3D true;
> -
> -    spin_lock(&ctx->lock);
> -
> -    if ( ctx->shm_count >=3D FFA_MAX_SHM_COUNT )
> -    {
> -        ret =3D false;
> -    }
> -    else
> -    {
> -        /*
> -         * If this is the first shm added, increase the domain reference
> -         * counter as we need to keep domain around a bit longer to recl=
aim
> -         * the shared memory in the teardown path.
> -         */
> -        if ( !ctx->shm_count )
> -            get_knownalive_domain(d);
> -
> -        ctx->shm_count++;
> -    }
> -
> -    spin_unlock(&ctx->lock);
> -
> -    return ret;
> -}
> -
> -static void dec_ctx_shm_count(struct domain *d, struct ffa_ctx *ctx)
> -{
> -    bool drop_ref;
> -
> -    spin_lock(&ctx->lock);
> -
> -    ASSERT(ctx->shm_count > 0);
> -    ctx->shm_count--;
> -
> -    /*
> -     * If this was the last shm removed, let go of the domain reference =
we
> -     * took in inc_ctx_shm_count() above.
> -     */
> -    drop_ref =3D !ctx->shm_count;
> -
> -    spin_unlock(&ctx->lock);
> -
> -    if ( drop_ref )
> -        put_domain(d);
> -}
> -
> -static struct ffa_shm_mem *alloc_ffa_shm_mem(struct domain *d,
> -                                             unsigned int page_count)
> -{
> -    struct ffa_ctx *ctx =3D d->arch.tee;
> -    struct ffa_shm_mem *shm;
> -
> -    if ( page_count >=3D FFA_MAX_SHM_PAGE_COUNT )
> -        return NULL;
> -    if ( !inc_ctx_shm_count(d, ctx) )
> -        return NULL;
> -
> -    shm =3D xzalloc_flex_struct(struct ffa_shm_mem, pages, page_count);
> -    if ( shm )
> -        shm->page_count =3D page_count;
> -    else
> -        dec_ctx_shm_count(d, ctx);
> -
> -    return shm;
> -}
> -
> -static void free_ffa_shm_mem(struct domain *d, struct ffa_shm_mem *shm)
> -{
> -    struct ffa_ctx *ctx =3D d->arch.tee;
> -
> -    if ( !shm )
> -        return;
> -
> -    dec_ctx_shm_count(d, ctx);
> -    put_shm_pages(shm);
> -    xfree(shm);
> -}
> -
> -static void init_range(struct ffa_address_range *addr_range,
> -                       paddr_t pa)
> -{
> -    memset(addr_range, 0, sizeof(*addr_range));
> -    addr_range->address =3D pa;
> -    addr_range->page_count =3D 1;
> -}
> -
> -/*
> - * This function uses the ffa_tx buffer to transmit the memory transacti=
on
> - * descriptor. The function depends ffa_tx_buffer_lock to be used to gua=
rd
> - * the buffer from concurrent use.
> - */
> -static int share_shm(struct ffa_shm_mem *shm)
> -{
> -    const uint32_t max_frag_len =3D FFA_RXTX_PAGE_COUNT * FFA_PAGE_SIZE;
> -    struct ffa_mem_access *mem_access_array;
> -    struct ffa_mem_transaction_1_1 *descr;
> -    struct ffa_address_range *addr_range;
> -    struct ffa_mem_region *region_descr;
> -    const unsigned int region_count =3D 1;
> -    void *buf =3D ffa_tx;
> -    uint32_t frag_len;
> -    uint32_t tot_len;
> -    paddr_t last_pa;
> -    unsigned int n;
> -    paddr_t pa;
> -
> -    ASSERT(spin_is_locked(&ffa_tx_buffer_lock));
> -    ASSERT(shm->page_count);
> -
> -    descr =3D buf;
> -    memset(descr, 0, sizeof(*descr));
> -    descr->sender_id =3D shm->sender_id;
> -    descr->handle =3D shm->handle;
> -    descr->mem_reg_attr =3D FFA_NORMAL_MEM_REG_ATTR;
> -    descr->mem_access_count =3D 1;
> -    descr->mem_access_size =3D sizeof(*mem_access_array);
> -    descr->mem_access_offs =3D MEM_ACCESS_OFFSET(0);
> -
> -    mem_access_array =3D buf + descr->mem_access_offs;
> -    memset(mem_access_array, 0, sizeof(*mem_access_array));
> -    mem_access_array[0].access_perm.endpoint_id =3D shm->ep_id;
> -    mem_access_array[0].access_perm.perm =3D FFA_MEM_ACC_RW;
> -    mem_access_array[0].region_offs =3D REGION_OFFSET(descr->mem_access_=
count, 0);
> -
> -    region_descr =3D buf + mem_access_array[0].region_offs;
> -    memset(region_descr, 0, sizeof(*region_descr));
> -    region_descr->total_page_count =3D shm->page_count;
> -
> -    region_descr->address_range_count =3D 1;
> -    last_pa =3D page_to_maddr(shm->pages[0]);
> -    for ( n =3D 1; n < shm->page_count; last_pa =3D pa, n++ )
> -    {
> -        pa =3D page_to_maddr(shm->pages[n]);
> -        if ( last_pa + FFA_PAGE_SIZE =3D=3D pa )
> -            continue;
> -        region_descr->address_range_count++;
> -    }
> -
> -    tot_len =3D ADDR_RANGE_OFFSET(descr->mem_access_count, region_count,
> -                                region_descr->address_range_count);
> -    if ( tot_len > max_frag_len )
> -        return FFA_RET_NOT_SUPPORTED;
> -
> -    addr_range =3D region_descr->address_range_array;
> -    frag_len =3D ADDR_RANGE_OFFSET(descr->mem_access_count, region_count=
, 1);
> -    last_pa =3D page_to_maddr(shm->pages[0]);
> -    init_range(addr_range, last_pa);
> -    for ( n =3D 1; n < shm->page_count; last_pa =3D pa, n++ )
> -    {
> -        pa =3D page_to_maddr(shm->pages[n]);
> -        if ( last_pa + FFA_PAGE_SIZE =3D=3D pa )
> -        {
> -            addr_range->page_count++;
> -            continue;
> -        }
> -
> -        frag_len +=3D sizeof(*addr_range);
> -        addr_range++;
> -        init_range(addr_range, pa);
> -    }
> -
> -    return ffa_mem_share(tot_len, frag_len, 0, 0, &shm->handle);
> -}
> -
> -static int read_mem_transaction(uint32_t ffa_vers, const void *buf, size=
_t blen,
> -                                struct ffa_mem_transaction_int *trans)
> -{
> -    uint16_t mem_reg_attr;
> -    uint32_t flags;
> -    uint32_t count;
> -    uint32_t offs;
> -    uint32_t size;
> -
> -    if ( ffa_vers >=3D FFA_VERSION_1_1 )
> -    {
> -        const struct ffa_mem_transaction_1_1 *descr;
> -
> -        if ( blen < sizeof(*descr) )
> -            return FFA_RET_INVALID_PARAMETERS;
> -
> -        descr =3D buf;
> -        trans->sender_id =3D descr->sender_id;
> -        mem_reg_attr =3D descr->mem_reg_attr;
> -        flags =3D descr->flags;
> -        trans->handle =3D descr->handle;
> -        trans->tag =3D descr->tag;
> -
> -        count =3D descr->mem_access_count;
> -        size =3D descr->mem_access_size;
> -        offs =3D descr->mem_access_offs;
> -    }
> -    else
> -    {
> -        const struct ffa_mem_transaction_1_0 *descr;
> -
> -        if ( blen < sizeof(*descr) )
> -            return FFA_RET_INVALID_PARAMETERS;
> -
> -        descr =3D buf;
> -        trans->sender_id =3D descr->sender_id;
> -        mem_reg_attr =3D descr->mem_reg_attr;
> -        flags =3D descr->flags;
> -        trans->handle =3D descr->handle;
> -        trans->tag =3D descr->tag;
> -
> -        count =3D descr->mem_access_count;
> -        size =3D sizeof(struct ffa_mem_access);
> -        offs =3D offsetof(struct ffa_mem_transaction_1_0, mem_access_arr=
ay);
> -    }
> -    /*
> -     * Make sure that "descr" which is shared with the guest isn't acces=
sed
> -     * again after this point.
> -     */
> -    barrier();
> -
> -    /*
> -     * We're doing a rough check to see that no information is lost when
> -     * tranfering the values into a struct ffa_mem_transaction_int below=
.
> -     * The fields in struct ffa_mem_transaction_int are wide enough to h=
old
> -     * any valid value so being out of range means that something is wro=
ng.
> -     */
> -    if ( mem_reg_attr > UINT8_MAX || flags > UINT8_MAX || size > UINT8_M=
AX ||
> -        count > UINT8_MAX || offs > UINT16_MAX )
> -        return FFA_RET_INVALID_PARAMETERS;
> -
> -    /* Check that the endpoint memory access descriptor array fits */
> -    if ( size * count + offs > blen )
> -        return FFA_RET_INVALID_PARAMETERS;
> -
> -    trans->mem_reg_attr =3D mem_reg_attr;
> -    trans->flags =3D flags;
> -    trans->mem_access_size =3D size;
> -    trans->mem_access_count =3D count;
> -    trans->mem_access_offs =3D offs;
> -
> -    return 0;
> -}
> -
> -static void ffa_handle_mem_share(struct cpu_user_regs *regs)
> -{
> -    uint32_t tot_len =3D get_user_reg(regs, 1);
> -    uint32_t frag_len =3D get_user_reg(regs, 2);
> -    uint64_t addr =3D get_user_reg(regs, 3);
> -    uint32_t page_count =3D get_user_reg(regs, 4);
> -    const struct ffa_mem_region *region_descr;
> -    const struct ffa_mem_access *mem_access;
> -    struct ffa_mem_transaction_int trans;
> -    struct domain *d =3D current->domain;
> -    struct ffa_ctx *ctx =3D d->arch.tee;
> -    struct ffa_shm_mem *shm =3D NULL;
> -    unsigned int last_page_idx =3D 0;
> -    register_t handle_hi =3D 0;
> -    register_t handle_lo =3D 0;
> -    int ret =3D FFA_RET_DENIED;
> -    uint32_t range_count;
> -    uint32_t region_offs;
> -
> -    /*
> -     * We're only accepting memory transaction descriptors via the rx/tx
> -     * buffer.
> -     */
> -    if ( addr )
> -    {
> -        ret =3D FFA_RET_NOT_SUPPORTED;
> -        goto out_set_ret;
> -    }
> -
> -    /* Check that fragment length doesn't exceed total length */
> -    if ( frag_len > tot_len )
> -    {
> -        ret =3D FFA_RET_INVALID_PARAMETERS;
> -        goto out_set_ret;
> -    }
> -
> -    /* We currently only support a single fragment */
> -    if ( frag_len !=3D tot_len )
> -    {
> -        ret =3D FFA_RET_NOT_SUPPORTED;
> -        goto out_set_ret;
> -    }
> -
> -    if ( !spin_trylock(&ctx->tx_lock) )
> -    {
> -        ret =3D FFA_RET_BUSY;
> -        goto out_set_ret;
> -    }
> -
> -    if ( frag_len > ctx->page_count * FFA_PAGE_SIZE )
> -        goto out_unlock;
> -
> -    ret =3D read_mem_transaction(ctx->guest_vers, ctx->tx, frag_len, &tr=
ans);
> -    if ( ret )
> -        goto out_unlock;
> -
> -    if ( trans.mem_reg_attr !=3D FFA_NORMAL_MEM_REG_ATTR )
> -    {
> -        ret =3D FFA_RET_NOT_SUPPORTED;
> -        goto out_unlock;
> -    }
> -
> -    /* Only supports sharing it with one SP for now */
> -    if ( trans.mem_access_count !=3D 1 )
> -    {
> -        ret =3D FFA_RET_NOT_SUPPORTED;
> -        goto out_unlock;
> -    }
> -
> -    if ( trans.sender_id !=3D ffa_get_vm_id(d) )
> -    {
> -        ret =3D FFA_RET_INVALID_PARAMETERS;
> -        goto out_unlock;
> -    }
> -
> -    /* Check that it fits in the supplied data */
> -    if ( trans.mem_access_offs + trans.mem_access_size > frag_len )
> -        goto out_unlock;
> -
> -    mem_access =3D ctx->tx + trans.mem_access_offs;
> -    if ( read_atomic(&mem_access->access_perm.perm) !=3D FFA_MEM_ACC_RW =
)
> -    {
> -        ret =3D FFA_RET_NOT_SUPPORTED;
> -        goto out_unlock;
> -    }
> -
> -    region_offs =3D read_atomic(&mem_access->region_offs);
> -    if ( sizeof(*region_descr) + region_offs > frag_len )
> -    {
> -        ret =3D FFA_RET_NOT_SUPPORTED;
> -        goto out_unlock;
> -    }
> -
> -    region_descr =3D ctx->tx + region_offs;
> -    range_count =3D read_atomic(®ion_descr->address_range_count);
> -    page_count =3D read_atomic(®ion_descr->total_page_count);
> -
> -    if ( !page_count )
> -    {
> -        ret =3D FFA_RET_INVALID_PARAMETERS;
> -        goto out_unlock;
> -    }
> -
> -    shm =3D alloc_ffa_shm_mem(d, page_count);
> -    if ( !shm )
> -    {
> -        ret =3D FFA_RET_NO_MEMORY;
> -        goto out_unlock;
> -    }
> -    shm->sender_id =3D trans.sender_id;
> -    shm->ep_id =3D read_atomic(&mem_access->access_perm.endpoint_id);
> -
> -    /*
> -     * Check that the Composite memory region descriptor fits.
> -     */
> -    if ( sizeof(*region_descr) + region_offs +
> -         range_count * sizeof(struct ffa_address_range) > frag_len )
> -    {
> -        ret =3D FFA_RET_INVALID_PARAMETERS;
> -        goto out;
> -    }
> -
> -    ret =3D get_shm_pages(d, shm, region_descr->address_range_array, ran=
ge_count,
> -                        0, &last_page_idx);
> -    if ( ret )
> -        goto out;
> -    if ( last_page_idx !=3D shm->page_count )
> -    {
> -        ret =3D FFA_RET_INVALID_PARAMETERS;
> -        goto out;
> -    }
> -
> -    /* Note that share_shm() uses our tx buffer */
> -    spin_lock(&ffa_tx_buffer_lock);
> -    ret =3D share_shm(shm);
> -    spin_unlock(&ffa_tx_buffer_lock);
> -    if ( ret )
> -        goto out;
> -
> -    spin_lock(&ctx->lock);
> -    list_add_tail(&shm->list, &ctx->shm_list);
> -    spin_unlock(&ctx->lock);
> -
> -    uint64_to_regpair(&handle_hi, &handle_lo, shm->handle);
> -
> -out:
> -    if ( ret )
> -        free_ffa_shm_mem(d, shm);
> -out_unlock:
> -    spin_unlock(&ctx->tx_lock);
> -
> -out_set_ret:
> -    if ( ret =3D=3D 0)
> -            ffa_set_regs_success(regs, handle_lo, handle_hi);
> -    else
> -            ffa_set_regs_error(regs, ret);
> -}
> -
> -/* Must only be called with ctx->lock held */
> -static struct ffa_shm_mem *find_shm_mem(struct ffa_ctx *ctx, uint64_t ha=
ndle)
> -{
> -    struct ffa_shm_mem *shm;
> -
> -    list_for_each_entry(shm, &ctx->shm_list, list)
> -        if ( shm->handle =3D=3D handle )
> -            return shm;
> -
> -    return NULL;
> -}
> -
> -static int ffa_handle_mem_reclaim(uint64_t handle, uint32_t flags)
> -{
> -    struct domain *d =3D current->domain;
> -    struct ffa_ctx *ctx =3D d->arch.tee;
> -    struct ffa_shm_mem *shm;
> -    register_t handle_hi;
> -    register_t handle_lo;
> -    int ret;
> -
> -    spin_lock(&ctx->lock);
> -    shm =3D find_shm_mem(ctx, handle);
> -    if ( shm )
> -        list_del(&shm->list);
> -    spin_unlock(&ctx->lock);
> -    if ( !shm )
> -        return FFA_RET_INVALID_PARAMETERS;
> -
> -    uint64_to_regpair(&handle_hi, &handle_lo, handle);
> -    ret =3D ffa_mem_reclaim(handle_lo, handle_hi, flags);
> -
> -    if ( ret )
> -    {
> -        spin_lock(&ctx->lock);
> -        list_add_tail(&shm->list, &ctx->shm_list);
> -        spin_unlock(&ctx->lock);
> -    }
> -    else
> -    {
> -        free_ffa_shm_mem(d, shm);
> -    }
> -
> -    return ret;
> -}
> -
> static bool ffa_handle_call(struct cpu_user_regs *regs)
> {
>     uint32_t fid =3D get_user_reg(regs, 0);
> @@ -1284,8 +648,8 @@ static int ffa_domain_init(struct domain *d)
>     if ( !ffa_version )
>         return -ENODEV;
>      /*
> -      * We can't use that last possible domain ID or get_vm_id() would c=
ause
> -      * an overflow.
> +      * We can't use that last possible domain ID or ffa_get_vm_id() wou=
ld
> +      * cause an overflow.

Nit: this should have been in patch 1 but no need to change unless there is
a new version of the serie.

>       */
>     if ( d->domain_id >=3D UINT16_MAX)
>         return -ERANGE;
> @@ -1348,68 +712,16 @@ static void send_vm_destroyed(struct domain *d)
>     }
> }
>=20
> -static void ffa_reclaim_shms(struct domain *d)
> -{
> -    struct ffa_ctx *ctx =3D d->arch.tee;
> -    struct ffa_shm_mem *shm, *tmp;
> -    int32_t res;
> -
> -    list_for_each_entry_safe(shm, tmp, &ctx->shm_list, list)
> -    {
> -        register_t handle_hi;
> -        register_t handle_lo;
> -
> -        uint64_to_regpair(&handle_hi, &handle_lo, shm->handle);
> -        res =3D ffa_mem_reclaim(handle_lo, handle_hi, 0);
> -        switch ( res ) {
> -        case FFA_RET_OK:
> -            printk(XENLOG_G_DEBUG "%pd: ffa: Reclaimed handle %#lx\n",
> -                   d, shm->handle);
> -            list_del(&shm->list);
> -            free_ffa_shm_mem(d, shm);
> -            break;
> -        case FFA_RET_DENIED:
> -            /*
> -             * A temporary error that may get resolved a bit later, it's
> -             * worth retrying.
> -             */
> -            printk(XENLOG_G_INFO "%pd: ffa: Failed to reclaim handle %#l=
x : %d\n",
> -                   d, shm->handle, res);
> -            break; /* We will retry later */
> -        default:
> -            /*
> -             * The rest of the error codes are not expected and are assu=
med
> -             * to be of a permanent nature. It not in our control to han=
dle
> -             * the error properly so the object in this case is to try t=
o
> -             * minimize the damage.
> -             *
> -             * FFA_RET_NO_MEMORY might be a temporary error as it it cou=
ld
> -             * succeed if retried later, but treat it as permanent for n=
ow.
> -             */
> -            printk(XENLOG_G_INFO "%pd: ffa: Permanent failure to reclaim=
 handle %#lx : %d\n",
> -                   d, shm->handle, res);
> -
> -            /*
> -             * Remove the shm from the list and free it, but don't drop
> -             * references. This results in having the shared physical pa=
ges
> -             * permanently allocate and also keeps the domain as a zombi=
e
> -             * domain.
> -             */
> -            list_del(&shm->list);
> -            xfree(shm);
> -            break;
> -        }
> -    }
> -}
> -
> static void ffa_domain_teardown_continue(struct ffa_ctx *ctx, bool first_=
time)
> {
>     struct ffa_ctx *next_ctx =3D NULL;
> +    bool retry =3D false;
>=20
>     send_vm_destroyed(ctx->teardown_d);
> -    ffa_reclaim_shms(ctx->teardown_d);
> +    if ( !ffa_shm_domain_destroy(ctx->teardown_d) )
> +        retry =3D true;
>=20
> -    if ( ctx->shm_count ||
> +    if ( retry ||
>          !bitmap_empty(ctx->vm_destroy_bitmap, subscr_vm_destroyed_count)=
 )
>     {
>         printk(XENLOG_G_INFO "%pd: ffa: Remaining cleanup, retrying\n", c=
tx->teardown_d);
> diff --git a/xen/arch/arm/tee/ffa_private.h b/xen/arch/arm/tee/ffa_privat=
e.h
> index 8352b6b55a9a..f3e2f42e573e 100644
> --- a/xen/arch/arm/tee/ffa_private.h
> +++ b/xen/arch/arm/tee/ffa_private.h
> @@ -247,6 +247,16 @@ struct ffa_ctx {
>     unsigned long vm_destroy_bitmap[];
> };
>=20
> +extern void *ffa_rx;
> +extern void *ffa_tx;
> +extern spinlock_t ffa_rx_buffer_lock;
> +extern spinlock_t ffa_tx_buffer_lock;
> +
> +bool ffa_shm_domain_destroy(struct domain *d);
> +void ffa_handle_mem_share(struct cpu_user_regs *regs);
> +int ffa_handle_mem_reclaim(uint64_t handle, uint32_t flags);
> +
> +
> static inline uint16_t ffa_get_vm_id(const struct domain *d)
> {
>     /* +1 since 0 is reserved for the hypervisor in FF-A */
> diff --git a/xen/arch/arm/tee/ffa_shm.c b/xen/arch/arm/tee/ffa_shm.c
> new file mode 100644
> index 000000000000..13dc44683b45
> --- /dev/null
> +++ b/xen/arch/arm/tee/ffa_shm.c
> @@ -0,0 +1,708 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Copyright (C) 2023  Linaro Limited

Nit: The copyright has a wrong date.


Cheers
Bertrand

> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +#include "ffa_private.h"
> +
> +/* Constituent memory region descriptor */
> +struct ffa_address_range {
> +    uint64_t address;
> +    uint32_t page_count;
> +    uint32_t reserved;
> +};
> +
> +/* Composite memory region descriptor */
> +struct ffa_mem_region {
> +    uint32_t total_page_count;
> +    uint32_t address_range_count;
> +    uint64_t reserved;
> +    struct ffa_address_range address_range_array[];
> +};
> +
> +/* Memory access permissions descriptor */
> +struct ffa_mem_access_perm {
> +    uint16_t endpoint_id;
> +    uint8_t perm;
> +    uint8_t flags;
> +};
> +
> +/* Endpoint memory access descriptor */
> +struct ffa_mem_access {
> +    struct ffa_mem_access_perm access_perm;
> +    uint32_t region_offs;
> +    uint64_t reserved;
> +};
> +
> +/* Lend, donate or share memory transaction descriptor */
> +struct ffa_mem_transaction_1_0 {
> +    uint16_t sender_id;
> +    uint8_t mem_reg_attr;
> +    uint8_t reserved0;
> +    uint32_t flags;
> +    uint64_t handle;
> +    uint64_t tag;
> +    uint32_t reserved1;
> +    uint32_t mem_access_count;
> +    struct ffa_mem_access mem_access_array[];
> +};
> +
> +struct ffa_mem_transaction_1_1 {
> +    uint16_t sender_id;
> +    uint16_t mem_reg_attr;
> +    uint32_t flags;
> +    uint64_t handle;
> +    uint64_t tag;
> +    uint32_t mem_access_size;
> +    uint32_t mem_access_count;
> +    uint32_t mem_access_offs;
> +    uint8_t reserved[12];
> +};
> +
> +/* Calculate offset of struct ffa_mem_access from start of buffer */
> +#define MEM_ACCESS_OFFSET(access_idx) \
> +    ( sizeof(struct ffa_mem_transaction_1_1) + \
> +      ( access_idx ) * sizeof(struct ffa_mem_access) )
> +
> +/* Calculate offset of struct ffa_mem_region from start of buffer */
> +#define REGION_OFFSET(access_count, region_idx) \
> +    ( MEM_ACCESS_OFFSET(access_count) + \
> +      ( region_idx ) * sizeof(struct ffa_mem_region) )
> +
> +/* Calculate offset of struct ffa_address_range from start of buffer */
> +#define ADDR_RANGE_OFFSET(access_count, region_count, range_idx) \
> +    ( REGION_OFFSET(access_count, region_count) + \
> +      ( range_idx ) * sizeof(struct ffa_address_range) )
> +
> +/*
> + * The parts needed from struct ffa_mem_transaction_1_0 or struct
> + * ffa_mem_transaction_1_1, used to provide an abstraction of difference=
 in
> + * data structures between version 1.0 and 1.1. This is just an internal
> + * interface and can be changed without changing any ABI.
> + */
> +struct ffa_mem_transaction_int {
> +    uint16_t sender_id;
> +    uint8_t mem_reg_attr;
> +    uint8_t flags;
> +    uint8_t mem_access_size;
> +    uint8_t mem_access_count;
> +    uint16_t mem_access_offs;
> +    uint64_t handle;
> +    uint64_t tag;
> +};
> +
> +struct ffa_shm_mem {
> +    struct list_head list;
> +    uint16_t sender_id;
> +    uint16_t ep_id;     /* endpoint, the one lending */
> +    uint64_t handle;    /* FFA_HANDLE_INVALID if not set yet */
> +    unsigned int page_count;
> +    struct page_info *pages[];
> +};
> +
> +static int32_t ffa_mem_share(uint32_t tot_len, uint32_t frag_len,
> +                             register_t addr, uint32_t pg_count,
> +                             uint64_t *handle)
> +{
> +    struct arm_smccc_1_2_regs arg =3D {
> +        .a0 =3D FFA_MEM_SHARE_64,
> +        .a1 =3D tot_len,
> +        .a2 =3D frag_len,
> +        .a3 =3D addr,
> +        .a4 =3D pg_count,
> +    };
> +    struct arm_smccc_1_2_regs resp;
> +
> +    arm_smccc_1_2_smc(&arg, &resp);
> +
> +    switch ( resp.a0 )
> +    {
> +    case FFA_ERROR:
> +        if ( resp.a2 )
> +            return resp.a2;
> +        else
> +            return FFA_RET_NOT_SUPPORTED;
> +    case FFA_SUCCESS_32:
> +        *handle =3D regpair_to_uint64(resp.a3, resp.a2);
> +        return FFA_RET_OK;
> +    case FFA_MEM_FRAG_RX:
> +        *handle =3D regpair_to_uint64(resp.a2, resp.a1);
> +        if ( resp.a3 > INT32_MAX ) /* Impossible value */
> +            return FFA_RET_ABORTED;
> +        return resp.a3 & INT32_MAX;
> +    default:
> +        return FFA_RET_NOT_SUPPORTED;
> +    }
> +}
> +
> +static int32_t ffa_mem_reclaim(uint32_t handle_lo, uint32_t handle_hi,
> +                               uint32_t flags)
> +{
> +    return ffa_simple_call(FFA_MEM_RECLAIM, handle_lo, handle_hi, flags,=
 0);
> +}
> +
> +/*
> + * Gets all page and assigns them to the supplied shared memory object. =
If
> + * this function fails then the caller is still expected to call
> + * put_shm_pages() as a cleanup.
> + */
> +static int get_shm_pages(struct domain *d, struct ffa_shm_mem *shm,
> +                         const struct ffa_address_range *range,
> +                         uint32_t range_count, unsigned int start_page_i=
dx,
> +                         unsigned int *last_page_idx)
> +{
> +    unsigned int pg_idx =3D start_page_idx;
> +    gfn_t gfn;
> +    unsigned int n;
> +    unsigned int m;
> +    p2m_type_t t;
> +    uint64_t addr;
> +    uint64_t page_count;
> +
> +    for ( n =3D 0; n < range_count; n++ )
> +    {
> +        page_count =3D read_atomic(&range[n].page_count);
> +        addr =3D read_atomic(&range[n].address);
> +        for ( m =3D 0; m < page_count; m++ )
> +        {
> +            if ( pg_idx >=3D shm->page_count )
> +                return FFA_RET_INVALID_PARAMETERS;
> +
> +            gfn =3D gaddr_to_gfn(addr + m * FFA_PAGE_SIZE);
> +            shm->pages[pg_idx] =3D get_page_from_gfn(d, gfn_x(gfn), &t,
> +   P2M_ALLOC);
> +            if ( !shm->pages[pg_idx] )
> +                return FFA_RET_DENIED;
> +            /* Only normal RW RAM for now */
> +            if ( t !=3D p2m_ram_rw )
> +                return FFA_RET_DENIED;
> +            pg_idx++;
> +        }
> +    }
> +
> +    *last_page_idx =3D pg_idx;
> +
> +    return FFA_RET_OK;
> +}
> +
> +static void put_shm_pages(struct ffa_shm_mem *shm)
> +{
> +    unsigned int n;
> +
> +    for ( n =3D 0; n < shm->page_count && shm->pages[n]; n++ )
> +    {
> +        put_page(shm->pages[n]);
> +        shm->pages[n] =3D NULL;
> +    }
> +}
> +
> +static bool inc_ctx_shm_count(struct domain *d, struct ffa_ctx *ctx)
> +{
> +    bool ret =3D true;
> +
> +    spin_lock(&ctx->lock);
> +
> +    if ( ctx->shm_count >=3D FFA_MAX_SHM_COUNT )
> +    {
> +        ret =3D false;
> +    }
> +    else
> +    {
> +        /*
> +         * If this is the first shm added, increase the domain reference
> +         * counter as we need to keep domain around a bit longer to recl=
aim
> +         * the shared memory in the teardown path.
> +         */
> +        if ( !ctx->shm_count )
> +            get_knownalive_domain(d);
> +
> +        ctx->shm_count++;
> +    }
> +
> +    spin_unlock(&ctx->lock);
> +
> +    return ret;
> +}
> +
> +static void dec_ctx_shm_count(struct domain *d, struct ffa_ctx *ctx)
> +{
> +    bool drop_ref;
> +
> +    spin_lock(&ctx->lock);
> +
> +    ASSERT(ctx->shm_count > 0);
> +    ctx->shm_count--;
> +
> +    /*
> +     * If this was the last shm removed, let go of the domain reference =
we
> +     * took in inc_ctx_shm_count() above.
> +     */
> +    drop_ref =3D !ctx->shm_count;
> +
> +    spin_unlock(&ctx->lock);
> +
> +    if ( drop_ref )
> +        put_domain(d);
> +}
> +
> +static struct ffa_shm_mem *alloc_ffa_shm_mem(struct domain *d,
> +                                             unsigned int page_count)
> +{
> +    struct ffa_ctx *ctx =3D d->arch.tee;
> +    struct ffa_shm_mem *shm;
> +
> +    if ( page_count >=3D FFA_MAX_SHM_PAGE_COUNT )
> +        return NULL;
> +    if ( !inc_ctx_shm_count(d, ctx) )
> +        return NULL;
> +
> +    shm =3D xzalloc_flex_struct(struct ffa_shm_mem, pages, page_count);
> +    if ( shm )
> +        shm->page_count =3D page_count;
> +    else
> +        dec_ctx_shm_count(d, ctx);
> +
> +    return shm;
> +}
> +
> +static void free_ffa_shm_mem(struct domain *d, struct ffa_shm_mem *shm)
> +{
> +    struct ffa_ctx *ctx =3D d->arch.tee;
> +
> +    if ( !shm )
> +        return;
> +
> +    dec_ctx_shm_count(d, ctx);
> +    put_shm_pages(shm);
> +    xfree(shm);
> +}
> +
> +static void init_range(struct ffa_address_range *addr_range,
> +                       paddr_t pa)
> +{
> +    memset(addr_range, 0, sizeof(*addr_range));
> +    addr_range->address =3D pa;
> +    addr_range->page_count =3D 1;
> +}
> +
> +/*
> + * This function uses the ffa_tx buffer to transmit the memory transacti=
on
> + * descriptor. The function depends ffa_tx_buffer_lock to be used to gua=
rd
> + * the buffer from concurrent use.
> + */
> +static int share_shm(struct ffa_shm_mem *shm)
> +{
> +    const uint32_t max_frag_len =3D FFA_RXTX_PAGE_COUNT * FFA_PAGE_SIZE;
> +    struct ffa_mem_access *mem_access_array;
> +    struct ffa_mem_transaction_1_1 *descr;
> +    struct ffa_address_range *addr_range;
> +    struct ffa_mem_region *region_descr;
> +    const unsigned int region_count =3D 1;
> +    void *buf =3D ffa_tx;
> +    uint32_t frag_len;
> +    uint32_t tot_len;
> +    paddr_t last_pa;
> +    unsigned int n;
> +    paddr_t pa;
> +
> +    ASSERT(spin_is_locked(&ffa_tx_buffer_lock));
> +    ASSERT(shm->page_count);
> +
> +    descr =3D buf;
> +    memset(descr, 0, sizeof(*descr));
> +    descr->sender_id =3D shm->sender_id;
> +    descr->handle =3D shm->handle;
> +    descr->mem_reg_attr =3D FFA_NORMAL_MEM_REG_ATTR;
> +    descr->mem_access_count =3D 1;
> +    descr->mem_access_size =3D sizeof(*mem_access_array);
> +    descr->mem_access_offs =3D MEM_ACCESS_OFFSET(0);
> +
> +    mem_access_array =3D buf + descr->mem_access_offs;
> +    memset(mem_access_array, 0, sizeof(*mem_access_array));
> +    mem_access_array[0].access_perm.endpoint_id =3D shm->ep_id;
> +    mem_access_array[0].access_perm.perm =3D FFA_MEM_ACC_RW;
> +    mem_access_array[0].region_offs =3D REGION_OFFSET(descr->mem_access_=
count, 0);
> +
> +    region_descr =3D buf + mem_access_array[0].region_offs;
> +    memset(region_descr, 0, sizeof(*region_descr));
> +    region_descr->total_page_count =3D shm->page_count;
> +
> +    region_descr->address_range_count =3D 1;
> +    last_pa =3D page_to_maddr(shm->pages[0]);
> +    for ( n =3D 1; n < shm->page_count; last_pa =3D pa, n++ )
> +    {
> +        pa =3D page_to_maddr(shm->pages[n]);
> +        if ( last_pa + FFA_PAGE_SIZE =3D=3D pa )
> +            continue;
> +        region_descr->address_range_count++;
> +    }
> +
> +    tot_len =3D ADDR_RANGE_OFFSET(descr->mem_access_count, region_count,
> +                                region_descr->address_range_count);
> +    if ( tot_len > max_frag_len )
> +        return FFA_RET_NOT_SUPPORTED;
> +
> +    addr_range =3D region_descr->address_range_array;
> +    frag_len =3D ADDR_RANGE_OFFSET(descr->mem_access_count, region_count=
, 1);
> +    last_pa =3D page_to_maddr(shm->pages[0]);
> +    init_range(addr_range, last_pa);
> +    for ( n =3D 1; n < shm->page_count; last_pa =3D pa, n++ )
> +    {
> +        pa =3D page_to_maddr(shm->pages[n]);
> +        if ( last_pa + FFA_PAGE_SIZE =3D=3D pa )
> +        {
> +            addr_range->page_count++;
> +            continue;
> +        }
> +
> +        frag_len +=3D sizeof(*addr_range);
> +        addr_range++;
> +        init_range(addr_range, pa);
> +    }
> +
> +    return ffa_mem_share(tot_len, frag_len, 0, 0, &shm->handle);
> +}
> +
> +static int read_mem_transaction(uint32_t ffa_vers, const void *buf, size=
_t blen,
> +                                struct ffa_mem_transaction_int *trans)
> +{
> +    uint16_t mem_reg_attr;
> +    uint32_t flags;
> +    uint32_t count;
> +    uint32_t offs;
> +    uint32_t size;
> +
> +    if ( ffa_vers >=3D FFA_VERSION_1_1 )
> +    {
> +        const struct ffa_mem_transaction_1_1 *descr;
> +
> +        if ( blen < sizeof(*descr) )
> +            return FFA_RET_INVALID_PARAMETERS;
> +
> +        descr =3D buf;
> +        trans->sender_id =3D descr->sender_id;
> +        mem_reg_attr =3D descr->mem_reg_attr;
> +        flags =3D descr->flags;
> +        trans->handle =3D descr->handle;
> +        trans->tag =3D descr->tag;
> +
> +        count =3D descr->mem_access_count;
> +        size =3D descr->mem_access_size;
> +        offs =3D descr->mem_access_offs;
> +    }
> +    else
> +    {
> +        const struct ffa_mem_transaction_1_0 *descr;
> +
> +        if ( blen < sizeof(*descr) )
> +            return FFA_RET_INVALID_PARAMETERS;
> +
> +        descr =3D buf;
> +        trans->sender_id =3D descr->sender_id;
> +        mem_reg_attr =3D descr->mem_reg_attr;
> +        flags =3D descr->flags;
> +        trans->handle =3D descr->handle;
> +        trans->tag =3D descr->tag;
> +
> +        count =3D descr->mem_access_count;
> +        size =3D sizeof(struct ffa_mem_access);
> +        offs =3D offsetof(struct ffa_mem_transaction_1_0, mem_access_arr=
ay);
> +    }
> +    /*
> +     * Make sure that "descr" which is shared with the guest isn't acces=
sed
> +     * again after this point.
> +     */
> +    barrier();
> +
> +    /*
> +     * We're doing a rough check to see that no information is lost when
> +     * tranfering the values into a struct ffa_mem_transaction_int below=
.
> +     * The fields in struct ffa_mem_transaction_int are wide enough to h=
old
> +     * any valid value so being out of range means that something is wro=
ng.
> +     */
> +    if ( mem_reg_attr > UINT8_MAX || flags > UINT8_MAX || size > UINT8_M=
AX ||
> +        count > UINT8_MAX || offs > UINT16_MAX )
> +        return FFA_RET_INVALID_PARAMETERS;
> +
> +    /* Check that the endpoint memory access descriptor array fits */
> +    if ( size * count + offs > blen )
> +        return FFA_RET_INVALID_PARAMETERS;
> +
> +    trans->mem_reg_attr =3D mem_reg_attr;
> +    trans->flags =3D flags;
> +    trans->mem_access_size =3D size;
> +    trans->mem_access_count =3D count;
> +    trans->mem_access_offs =3D offs;
> +
> +    return 0;
> +}
> +
> +void ffa_handle_mem_share(struct cpu_user_regs *regs)
> +{
> +    uint32_t tot_len =3D get_user_reg(regs, 1);
> +    uint32_t frag_len =3D get_user_reg(regs, 2);
> +    uint64_t addr =3D get_user_reg(regs, 3);
> +    uint32_t page_count =3D get_user_reg(regs, 4);
> +    const struct ffa_mem_region *region_descr;
> +    const struct ffa_mem_access *mem_access;
> +    struct ffa_mem_transaction_int trans;
> +    struct domain *d =3D current->domain;
> +    struct ffa_ctx *ctx =3D d->arch.tee;
> +    struct ffa_shm_mem *shm =3D NULL;
> +    unsigned int last_page_idx =3D 0;
> +    register_t handle_hi =3D 0;
> +    register_t handle_lo =3D 0;
> +    int ret =3D FFA_RET_DENIED;
> +    uint32_t range_count;
> +    uint32_t region_offs;
> +
> +    /*
> +     * We're only accepting memory transaction descriptors via the rx/tx
> +     * buffer.
> +     */
> +    if ( addr )
> +    {
> +        ret =3D FFA_RET_NOT_SUPPORTED;
> +        goto out_set_ret;
> +    }
> +
> +    /* Check that fragment length doesn't exceed total length */
> +    if ( frag_len > tot_len )
> +    {
> +        ret =3D FFA_RET_INVALID_PARAMETERS;
> +        goto out_set_ret;
> +    }
> +
> +    /* We currently only support a single fragment */
> +    if ( frag_len !=3D tot_len )
> +    {
> +        ret =3D FFA_RET_NOT_SUPPORTED;
> +        goto out_set_ret;
> +    }
> +
> +    if ( !spin_trylock(&ctx->tx_lock) )
> +    {
> +        ret =3D FFA_RET_BUSY;
> +        goto out_set_ret;
> +    }
> +
> +    if ( frag_len > ctx->page_count * FFA_PAGE_SIZE )
> +        goto out_unlock;
> +
> +    ret =3D read_mem_transaction(ctx->guest_vers, ctx->tx, frag_len, &tr=
ans);
> +    if ( ret )
> +        goto out_unlock;
> +
> +    if ( trans.mem_reg_attr !=3D FFA_NORMAL_MEM_REG_ATTR )
> +    {
> +        ret =3D FFA_RET_NOT_SUPPORTED;
> +        goto out_unlock;
> +    }
> +
> +    /* Only supports sharing it with one SP for now */
> +    if ( trans.mem_access_count !=3D 1 )
> +    {
> +        ret =3D FFA_RET_NOT_SUPPORTED;
> +        goto out_unlock;
> +    }
> +
> +    if ( trans.sender_id !=3D ffa_get_vm_id(d) )
> +    {
> +        ret =3D FFA_RET_INVALID_PARAMETERS;
> +        goto out_unlock;
> +    }
> +
> +    /* Check that it fits in the supplied data */
> +    if ( trans.mem_access_offs + trans.mem_access_size > frag_len )
> +        goto out_unlock;
> +
> +    mem_access =3D ctx->tx + trans.mem_access_offs;
> +    if ( read_atomic(&mem_access->access_perm.perm) !=3D FFA_MEM_ACC_RW =
)
> +    {
> +        ret =3D FFA_RET_NOT_SUPPORTED;
> +        goto out_unlock;
> +    }
> +
> +    region_offs =3D read_atomic(&mem_access->region_offs);
> +    if ( sizeof(*region_descr) + region_offs > frag_len )
> +    {
> +        ret =3D FFA_RET_NOT_SUPPORTED;
> +        goto out_unlock;
> +    }
> +
> +    region_descr =3D ctx->tx + region_offs;
> +    range_count =3D read_atomic(®ion_descr->address_range_count);
> +    page_count =3D read_atomic(®ion_descr->total_page_count);
> +
> +    if ( !page_count )
> +    {
> +        ret =3D FFA_RET_INVALID_PARAMETERS;
> +        goto out_unlock;
> +    }
> +
> +    shm =3D alloc_ffa_shm_mem(d, page_count);
> +    if ( !shm )
> +    {
> +        ret =3D FFA_RET_NO_MEMORY;
> +        goto out_unlock;
> +    }
> +    shm->sender_id =3D trans.sender_id;
> +    shm->ep_id =3D read_atomic(&mem_access->access_perm.endpoint_id);
> +
> +    /*
> +     * Check that the Composite memory region descriptor fits.
> +     */
> +    if ( sizeof(*region_descr) + region_offs +
> +         range_count * sizeof(struct ffa_address_range) > frag_len )
> +    {
> +        ret =3D FFA_RET_INVALID_PARAMETERS;
> +        goto out;
> +    }
> +
> +    ret =3D get_shm_pages(d, shm, region_descr->address_range_array, ran=
ge_count,
> +                        0, &last_page_idx);
> +    if ( ret )
> +        goto out;
> +    if ( last_page_idx !=3D shm->page_count )
> +    {
> +        ret =3D FFA_RET_INVALID_PARAMETERS;
> +        goto out;
> +    }
> +
> +    /* Note that share_shm() uses our tx buffer */
> +    spin_lock(&ffa_tx_buffer_lock);
> +    ret =3D share_shm(shm);
> +    spin_unlock(&ffa_tx_buffer_lock);
> +    if ( ret )
> +        goto out;
> +
> +    spin_lock(&ctx->lock);
> +    list_add_tail(&shm->list, &ctx->shm_list);
> +    spin_unlock(&ctx->lock);
> +
> +    uint64_to_regpair(&handle_hi, &handle_lo, shm->handle);
> +
> +out:
> +    if ( ret )
> +        free_ffa_shm_mem(d, shm);
> +out_unlock:
> +    spin_unlock(&ctx->tx_lock);
> +
> +out_set_ret:
> +    if ( ret =3D=3D 0)
> +            ffa_set_regs_success(regs, handle_lo, handle_hi);
> +    else
> +            ffa_set_regs_error(regs, ret);
> +}
> +
> +/* Must only be called with ctx->lock held */
> +static struct ffa_shm_mem *find_shm_mem(struct ffa_ctx *ctx, uint64_t ha=
ndle)
> +{
> +    struct ffa_shm_mem *shm;
> +
> +    list_for_each_entry(shm, &ctx->shm_list, list)
> +        if ( shm->handle =3D=3D handle )
> +            return shm;
> +
> +    return NULL;
> +}
> +
> +int ffa_handle_mem_reclaim(uint64_t handle, uint32_t flags)
> +{
> +    struct domain *d =3D current->domain;
> +    struct ffa_ctx *ctx =3D d->arch.tee;
> +    struct ffa_shm_mem *shm;
> +    register_t handle_hi;
> +    register_t handle_lo;
> +    int ret;
> +
> +    spin_lock(&ctx->lock);
> +    shm =3D find_shm_mem(ctx, handle);
> +    if ( shm )
> +        list_del(&shm->list);
> +    spin_unlock(&ctx->lock);
> +    if ( !shm )
> +        return FFA_RET_INVALID_PARAMETERS;
> +
> +    uint64_to_regpair(&handle_hi, &handle_lo, handle);
> +    ret =3D ffa_mem_reclaim(handle_lo, handle_hi, flags);
> +
> +    if ( ret )
> +    {
> +        spin_lock(&ctx->lock);
> +        list_add_tail(&shm->list, &ctx->shm_list);
> +        spin_unlock(&ctx->lock);
> +    }
> +    else
> +    {
> +        free_ffa_shm_mem(d, shm);
> +    }
> +
> +    return ret;
> +}
> +
> +bool ffa_shm_domain_destroy(struct domain *d)
> +{
> +    struct ffa_ctx *ctx =3D d->arch.tee;
> +    struct ffa_shm_mem *shm, *tmp;
> +    int32_t res;
> +
> +    list_for_each_entry_safe(shm, tmp, &ctx->shm_list, list)
> +    {
> +        register_t handle_hi;
> +        register_t handle_lo;
> +
> +        uint64_to_regpair(&handle_hi, &handle_lo, shm->handle);
> +        res =3D ffa_mem_reclaim(handle_lo, handle_hi, 0);
> +        switch ( res ) {
> +        case FFA_RET_OK:
> +            printk(XENLOG_G_DEBUG "%pd: ffa: Reclaimed handle %#lx\n",
> +                   d, shm->handle);
> +            list_del(&shm->list);
> +            free_ffa_shm_mem(d, shm);
> +            break;
> +        case FFA_RET_DENIED:
> +            /*
> +             * A temporary error that may get resolved a bit later, it's
> +             * worth retrying.
> +             */
> +            printk(XENLOG_G_INFO "%pd: ffa: Failed to reclaim handle %#l=
x : %d\n",
> +                   d, shm->handle, res);
> +            break; /* We will retry later */
> +        default:
> +            /*
> +             * The rest of the error codes are not expected and are assu=
med
> +             * to be of a permanent nature. It not in our control to han=
dle
> +             * the error properly so the object in this case is to try t=
o
> +             * minimize the damage.
> +             *
> +             * FFA_RET_NO_MEMORY might be a temporary error as it it cou=
ld
> +             * succeed if retried later, but treat it as permanent for n=
ow.
> +             */
> +            printk(XENLOG_G_INFO "%pd: ffa: Permanent failure to reclaim=
 handle %#lx : %d\n",
> +                   d, shm->handle, res);
> +
> +            /*
> +             * Remove the shm from the list and free it, but don't drop
> +             * references. This results in having the shared physical pa=
ges
> +             * permanently allocate and also keeps the domain as a zombi=
e
> +             * domain.
> +             */
> +            list_del(&shm->list);
> +            xfree(shm);
> +            break;
> +        }
> +    }
> +
> +    return !ctx->shm_count;
> +}
> --=20
> 2.34.1
>=20



From xen-devel-bounces@lists.xenproject.org Wed Mar 27 13:42:38 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 13:42:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698542.1090328 (Exim 4.92)
	(envelope-from )
	id 1rpTY4-0004BH-Ij; Wed, 27 Mar 2024 13:42:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698542.1090328; Wed, 27 Mar 2024 13:42:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpTY4-0004BA-Eh; Wed, 27 Mar 2024 13:42:36 +0000
Received: by outflank-mailman (input) for mailman id 698542;
 Wed, 27 Mar 2024 13:42:35 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpTY3-0004B2-81
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 13:42:35 +0000
Received: from EUR05-AM6-obe.outbound.protection.outlook.com
 (mail-am6eur05on20600.outbound.protection.outlook.com
 [2a01:111:f403:2612::600])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ddabb156-ec3f-11ee-afe3-a90da7624cb6;
 Wed, 27 Mar 2024 14:42:34 +0100 (CET)
Received: from AS9PR04CA0168.eurprd04.prod.outlook.com (2603:10a6:20b:530::13)
 by AS4PR08MB7757.eurprd08.prod.outlook.com (2603:10a6:20b:514::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.32; Wed, 27 Mar
 2024 13:42:30 +0000
Received: from AMS0EPF0000019E.eurprd05.prod.outlook.com
 (2603:10a6:20b:530:cafe::a1) by AS9PR04CA0168.outlook.office365.com
 (2603:10a6:20b:530::13) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.13 via Frontend
 Transport; Wed, 27 Mar 2024 13:42:29 +0000
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by
 AMS0EPF0000019E.mail.protection.outlook.com (10.167.16.250) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.7409.10 via Frontend Transport; Wed, 27 Mar 2024 13:42:29 +0000
Received: ("Tessian outbound 9b7417e2a8eb:v300");
 Wed, 27 Mar 2024 13:42:29 +0000
Received: from e92aa6183366.1
 by 64aa7808-outbound-1.mta.getcheckrecipient.com id
 A4EDB33E-93C9-42B3-8EDE-D71E2B869A7B.1; 
 Wed, 27 Mar 2024 13:42:21 +0000
Received: from EUR04-DB3-obe.outbound.protection.outlook.com
 by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id e92aa6183366.1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384);
 Wed, 27 Mar 2024 13:42:21 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com (2603:10a6:10:25a::24)
 by PAXPR08MB7552.eurprd08.prod.outlook.com (2603:10a6:102:24f::7)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.32; Wed, 27 Mar
 2024 13:42:19 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::7fb0:6621:56b:22d5]) by DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::7fb0:6621:56b:22d5%3]) with mapi id 15.20.7409.031; Wed, 27 Mar 2024
 13:42:19 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ddabb156-ec3f-11ee-afe3-a90da7624cb6
ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass;
 b=XU5Rypcy8j0MfuutyqjdSDD5zjQCEFAIr2hcoooWBgTbPhDJeD/mCsPHvV5hQHGij3tVdUZZsTq+ONaY+wZxjrg6gOp+C+IrL8HW8a/RmszOPYZqAqCmwy8+8jqG4I+1mqQcrOFu9pdMYygfC7IU3Or11xL/jdsTnW0RoDXBprJ3n6T4weaQBjGw0bTwTdvECKq9MDP+YB7DCCdFrvumN/fkiofC9ZLs7rUU9D9AfatHQwI7ghpP95J3tsOxaaBXymGu6VaPEd5bsbzuqPAqjIdIGp+vujkBNT+CDPk0hE2jZIJGxnOrpjA22HLfyG5a4pFtJca9ZLVDf56brAOmjw==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=0pvrdkGgNjuEybFpXk2LfI42H3Yh77m/UGD06EenTKI=;
 b=gBSA2Vn4tSmhctQgwzcWKhzpFkDLDvEll94kAwpNQFf6dGoWmmqzDa8QVQ3xod34gQ+Wu7bdHGFx/ii1zXYD4v2y6NQi2+UDRhMs2kYtoAgFw7MUUmZq5vX+ifFj6dtMGpc8fZRkjpIjvh8/7VZynzvEsempMaj8OSO8V94hq3sRQ/Xe21JxuGgKZ4d8Ukvw+mTKnjY6rri2fFGXLXJy4D8QAzNmvpnzGGeLkbtduM3wJrweUwepgEqo1NAtdk7YkY1UUaltwCqCPz5NcnJGQuV0rSLDYzjFAyZmUjQ/m09HALeO7qy1zeTPb0nBI+Mo4z1BVIAEwiKGswO0ER9dFw==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 63.35.35.123) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=arm.com;
 dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com;
 dkim=pass (signature was verified) header.d=armh.onmicrosoft.com; arc=pass (0
 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com]
 dmarc=[1,1,header.from=arm.com])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com;
 s=selector2-armh-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=0pvrdkGgNjuEybFpXk2LfI42H3Yh77m/UGD06EenTKI=;
 b=0a4tehdtXELkaL3Y43qRRw5Z9qhBoXK3SNowdSOsFq6LO4QYpgqsDCF/afYCEwubBzL81hcEta5uiC+tsUE0fIcuVE39BhNR6iNZ60QIFl0XzsQnTx/fwn0JTEkRKP+Nq4th0CabRJ1wZuuihMtkahyaU5AOHlDll/bsmKs7eAs=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=armh.onmicrosoft.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 63.35.35.123 as permitted sender) receiver=protection.outlook.com;
 client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
 pr=C
X-CheckRecipientChecked: true
X-CR-MTA-CID: fac7bafb0d7892dd
X-CR-MTA-TID: 64aa7808
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=gcbSKUtHaGoQ7Vx9XuqqsnYlF3FI1blnEa9xSGl1a/cricGUT7E827ONF5z5t1EcWtF0igmFZYuqHXrDfXFWihEBA9YhQYtEUWvAhmSaydLUs/8u7Nu82/qjI2ezhwMZ2cipZBe8d5vZkQkf+tbNV64/xO2Sq22x4gVoBOigfG62KfRDYlWsQyr69LPSlu+05bCSN0K0J20Nw4LrW431MZDqNazJFSc+qQ7UGRSC+hYL5XAeMl3ahgYlRt3XRA0j8Aj9uhvMAAL8O5EquGmIrXVJ6G/XEhYQJhzQAl12HPdGTqBp6mhL6s4Ra5OkV7PJ4H4yXP4H5Yti2NgH/agppA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=0pvrdkGgNjuEybFpXk2LfI42H3Yh77m/UGD06EenTKI=;
 b=nZ3Kw+S21YsFINOips8YOQmMzZfwJuOYV6DA2dFqDzXqgoZTFHjxwDAJ2jwB8r3gfq6HERT9kP3ToHxwz7N5E6Q1nPoFYLEhpsts6lJgs8NsWviy0qJX/tO9DlDeA4eE+Ye67pZCFMWTSFqrDMby/41Q5zZXPeyyg+ROgZmO0AFRvRSS3ag8zIQ3E4PKwrm962CHfHXMtEjV4BXZFuSqRg2DFIZ6GRLlqIhLXISQNwNwKCanMkZ5dLFll9Ygx//lgvJ2pE3bYmKaHwtIWjxO8iKQdXNo3vOMp1yx7Fh9j0V84g2LdmR4jGN5lzIKO715beNrLOLHKbN4wT4ZWk4DSQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass
 header.d=arm.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com;
 s=selector2-armh-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=0pvrdkGgNjuEybFpXk2LfI42H3Yh77m/UGD06EenTKI=;
 b=0a4tehdtXELkaL3Y43qRRw5Z9qhBoXK3SNowdSOsFq6LO4QYpgqsDCF/afYCEwubBzL81hcEta5uiC+tsUE0fIcuVE39BhNR6iNZ60QIFl0XzsQnTx/fwn0JTEkRKP+Nq4th0CabRJ1wZuuihMtkahyaU5AOHlDll/bsmKs7eAs=
From: Bertrand Marquis 
To: Jens Wiklander 
CC: Xen-devel , "patches@linaro.org"
	, Volodymyr Babchuk , Stefano
 Stabellini , Julien Grall , Michal
 Orzel 
Subject: Re: [XEN PATCH 4/6] xen/arm: ffa: separate partition info get
 routines
Thread-Topic: [XEN PATCH 4/6] xen/arm: ffa: separate partition info get
 routines
Thread-Index: AQHafphSdluTj/kw9U66NBMqBbhqTrFLm/CA
Date: Wed, 27 Mar 2024 13:42:19 +0000
Message-ID: <7332DDE8-E340-45D0-9553-581E42122C29@arm.com>
References: <20240325093904.3466092-1-jens.wiklander@linaro.org>
 <20240325093904.3466092-5-jens.wiklander@linaro.org>
In-Reply-To: <20240325093904.3466092-5-jens.wiklander@linaro.org>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3774.200.91.1.1)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DB9PR08MB6588:EE_|PAXPR08MB7552:EE_|AMS0EPF0000019E:EE_|AS4PR08MB7757:EE_
X-MS-Office365-Filtering-Correlation-Id: 33c22511-5401-42d5-00f8-08dc4e63bf1d
x-checkrecipientrouted: true
nodisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted: BCL:0;
X-Microsoft-Antispam-Message-Info-Original:
 OWi2lHQ0QIpKFNLVFdchIi+v68Ks2+tt+fS4Uz+JNBrWzp2SRiDQVG8XIXMQuup/sB3WwJRJioZAbTzq43RDpdKpQOjZu7bKqx/1+P2aBRpTJXCSx8PrpO1fhcxWeUyJA+YtBM+UQ8eHEUJaQUo9OnoLZ/U2jRralkCFm5sw1FtvYVU/57XHpfoNoRUPJ8aqQH5k9l8Do3kGsY33b4d3nKvW+NJd8BuB8yUieeFW4LArsWCNDYowjQRui2KxItF7Rt0DKnGajl9aYu9nGuy/dBzTSam0jZrnbzpH4ddlDL3fppKPswzIfCi6WcqqpYzbl2XLbjQr8ALaNTGSDrAtBf5/6tBKXVmS+dopl3rH9nG1y2ODmnJx3Om0irrndj3JkTut+p/EaoJvkVyWGZsx1dPjK13xo3NHxay8il3eJkxsVOhNvFxgA8XwtCxu7ag0+vrvIQcHKS9SXssiSXPuigcaFBlWPk/JHOkHG0lAUN88cdirpj91Qf3iW0WIQnywmuts3Efb4fAt7Pif/C8BORiHNS2tc7pcMMvvJsCmhz+mkwHoGQ06y1xPwT2E9K6wNkzWAVIO2aC9P6RH3s/BCFMCSS3nfndEpJNXwEb8MwBR8TVqW0XDO+cjFrhsS2Ev1kpflraxic5trzaTvKsvWNabLvX16Srv8m+2UzlzAVTmot9TM3kOap6anEr8xS3UzK94KFgk/vdF/1fm5gkQpsNID3C1v1DnHUzAlG2HPIc=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB9PR08MB6588.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(366007)(376005)(1800799015)(38070700009);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="us-ascii"
Content-ID: <966371AA979AE44DBC71ECFC6BF358E3@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAXPR08MB7552
Original-Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 AMS0EPF0000019E.eurprd05.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	1281b78c-17c8-4ae5-4eab-08dc4e63b949
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	a4kvknBt+qktp3kTacdccThAlck1sRVp/FrA82sB2CICsVf9VbEf37OGsWWnk3nFT8x1dw/K+Atm40qKsoLqrVU/U4INiRiEZxEBuko/149m64osLvWho0U2hCg6EtTMxR9J8ALprztjZYBnuZOyANijrcOx2F52oS1c2Ilc4OMUY7NrH5ACcp92IBzhJ/cLMC9BzjgLw+Vlc0Tm0CFkSh8qf+RNCW76ZhSKedvNXqRYOuKU5WEG3OZsR8nqmoUP6r0AXd9NiEje640MytiB1nk0g/mE7HQNtEFGrO8GZdOAr53+OCRKzn085NWXPO2rwjk6z4s4mlOFSQ9zcXY5lf8s9BUmgMwC0HA71B00hrhiErpM40FkHXeuS36iEKlYbo9ugrWyzuS3E68w00nJnfPJ0CFUAVb0iP8zAZlrGGBkMB7HLtfBh9q+mQaKY/L30sKGLEscCdhGTkqnfcQ5jdwwG5mAjql+4foDoBqR9mElc/S5VP83DdTm73EQvkeBjI6RUZ1BAkMcSHHfmC3TTD/1BqEJD8r/YtK94oAKOcZdpUP66tlJFKxxQBjU2h+1lleJYXEqBpKx9nv4UaE3IRN6+O5b9fCspBfJ0TafezVCQVTcaY0sgW2+m2IepaW0xiGjsLmuI/gn3Y69d+5YbqWI94EpCimXEm69eWBSHIUOa61E5EfpN++NcmPx7gz6F5uLesDxa5/0v+IgKfcLjWYYO/09bC9KRhvj3L9cGQUVkp3+4REZyRpJE80OagME
X-Forefront-Antispam-Report:
	CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com;CAT:NONE;SFS:(13230031)(376005)(82310400014)(36860700004)(1800799015);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Mar 2024 13:42:29.4220
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 33c22511-5401-42d5-00f8-08dc4e63bf1d
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-AuthSource:
	AMS0EPF0000019E.eurprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS4PR08MB7757

Hi Jens,

> On 25 Mar 2024, at 10:39, Jens Wiklander  wrot=
e:
>=20
> Move partition info get routines into a separate file for easier
> navigation in the source code.
>=20
> Add ffa_partinfo_init(), ffa_partinfo_domain_init(), and
> ffa_partinfo_domain_destroy() to handle the ffa_partinfo internal things
> on initialization and teardown.
>=20
> Signed-off-by: Jens Wiklander 

Reviewed-by: Bertrand Marquis 

Cheers
Bertrand

> ---
> xen/arch/arm/tee/Makefile       |   1 +
> xen/arch/arm/tee/ffa.c          | 359 +-----------------------------
> xen/arch/arm/tee/ffa_partinfo.c | 373 ++++++++++++++++++++++++++++++++
> xen/arch/arm/tee/ffa_private.h  |  14 +-
> 4 files changed, 398 insertions(+), 349 deletions(-)
> create mode 100644 xen/arch/arm/tee/ffa_partinfo.c
>=20
> diff --git a/xen/arch/arm/tee/Makefile b/xen/arch/arm/tee/Makefile
> index 0e683d23aa9d..be644fba8055 100644
> --- a/xen/arch/arm/tee/Makefile
> +++ b/xen/arch/arm/tee/Makefile
> @@ -1,4 +1,5 @@
> obj-$(CONFIG_FFA) +=3D ffa.o
> obj-$(CONFIG_FFA) +=3D ffa_shm.o
> +obj-$(CONFIG_FFA) +=3D ffa_partinfo.o
> obj-y +=3D tee.o
> obj-$(CONFIG_OPTEE) +=3D optee.o
> diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
> index db36292dc52f..7a2803881420 100644
> --- a/xen/arch/arm/tee/ffa.c
> +++ b/xen/arch/arm/tee/ffa.c
> @@ -70,20 +70,6 @@
>  * structs ending with _1_1 are defined in FF-A-1.1-REL0.
>  */
>=20
> -/* Partition information descriptor */
> -struct ffa_partition_info_1_0 {
> -    uint16_t id;
> -    uint16_t execution_context;
> -    uint32_t partition_properties;
> -};
> -
> -struct ffa_partition_info_1_1 {
> -    uint16_t id;
> -    uint16_t execution_context;
> -    uint32_t partition_properties;
> -    uint8_t uuid[16];
> -};
> -
> /* Endpoint RX/TX descriptor */
> struct ffa_endpoint_rxtx_descriptor_1_0 {
>     uint16_t sender_id;
> @@ -102,11 +88,6 @@ struct ffa_endpoint_rxtx_descriptor_1_1 {
> /* Negotiated FF-A version to use with the SPMC */
> static uint32_t __ro_after_init ffa_version;
>=20
> -/* SPs subscribing to VM_CREATE and VM_DESTROYED events */
> -static uint16_t *subscr_vm_created __read_mostly;
> -static uint16_t subscr_vm_created_count __read_mostly;
> -static uint16_t *subscr_vm_destroyed __read_mostly;
> -static uint16_t subscr_vm_destroyed_count __read_mostly;
>=20
> /*
>  * Our rx/tx buffers shared with the SPMC. FFA_RXTX_PAGE_COUNT is the
> @@ -170,90 +151,6 @@ static int32_t ffa_rxtx_map(paddr_t tx_addr, paddr_t=
 rx_addr,
>     return ffa_simple_call(FFA_RXTX_MAP_64, tx_addr, rx_addr, page_count,=
 0);
> }
>=20
> -static int32_t ffa_partition_info_get(uint32_t w1, uint32_t w2, uint32_t=
 w3,
> -                                      uint32_t w4, uint32_t w5,
> -                                      uint32_t *count, uint32_t *fpi_siz=
e)
> -{
> -    const struct arm_smccc_1_2_regs arg =3D {
> -        .a0 =3D FFA_PARTITION_INFO_GET,
> -        .a1 =3D w1,
> -        .a2 =3D w2,
> -        .a3 =3D w3,
> -        .a4 =3D w4,
> -        .a5 =3D w5,
> -    };
> -    struct arm_smccc_1_2_regs resp;
> -    uint32_t ret;
> -
> -    arm_smccc_1_2_smc(&arg, &resp);
> -
> -    ret =3D ffa_get_ret_code(&resp);
> -    if ( !ret )
> -    {
> -        *count =3D resp.a2;
> -        *fpi_size =3D resp.a3;
> -    }
> -
> -    return ret;
> -}
> -
> -static int32_t ffa_rx_release(void)
> -{
> -    return ffa_simple_call(FFA_RX_RELEASE, 0, 0, 0, 0);
> -}
> -
> -static int32_t ffa_direct_req_send_vm(uint16_t sp_id, uint16_t vm_id,
> -                                      uint8_t msg)
> -{
> -    uint32_t exp_resp =3D FFA_MSG_FLAG_FRAMEWORK;
> -    unsigned int retry_count =3D 0;
> -    int32_t res;
> -
> -    if ( msg =3D=3D FFA_MSG_SEND_VM_CREATED )
> -        exp_resp |=3D FFA_MSG_RESP_VM_CREATED;
> -    else if ( msg =3D=3D FFA_MSG_SEND_VM_DESTROYED )
> -        exp_resp |=3D FFA_MSG_RESP_VM_DESTROYED;
> -    else
> -        return FFA_RET_INVALID_PARAMETERS;
> -
> -    do {
> -        const struct arm_smccc_1_2_regs arg =3D {
> -            .a0 =3D FFA_MSG_SEND_DIRECT_REQ_32,
> -            .a1 =3D sp_id,
> -            .a2 =3D FFA_MSG_FLAG_FRAMEWORK | msg,
> -            .a5 =3D vm_id,
> -        };
> -        struct arm_smccc_1_2_regs resp;
> -
> -        arm_smccc_1_2_smc(&arg, &resp);
> -        if ( resp.a0 !=3D FFA_MSG_SEND_DIRECT_RESP_32 || resp.a2 !=3D ex=
p_resp )
> -        {
> -            /*
> -             * This is an invalid response, likely due to some error in =
the
> -             * implementation of the ABI.
> -             */
> -            return FFA_RET_INVALID_PARAMETERS;
> -        }
> -        res =3D resp.a3;
> -        if ( ++retry_count > 10 )
> -        {
> -            /*
> -             * TODO
> -             * FFA_RET_INTERRUPTED means that the SPMC has a pending
> -             * non-secure interrupt, we need a way of delivering that
> -             * non-secure interrupt.
> -             * FFA_RET_RETRY is the SP telling us that it's temporarily
> -             * blocked from handling the direct request, we need a gener=
ic
> -             * way to deal with this.
> -             * For now in both cases, give up after a few retries.
> -             */
> -            return res;
> -        }
> -    } while ( res =3D=3D FFA_RET_INTERRUPTED || res =3D=3D FFA_RET_RETRY=
 );
> -
> -    return res;
> -}
> -
> static void handle_version(struct cpu_user_regs *regs)
> {
>     struct domain *d =3D current->domain;
> @@ -371,88 +268,6 @@ static uint32_t ffa_handle_rxtx_unmap(void)
>     return FFA_RET_OK;
> }
>=20
> -static int32_t ffa_handle_partition_info_get(uint32_t w1, uint32_t w2,
> -                                             uint32_t w3, uint32_t w4,
> -                                             uint32_t w5, uint32_t *coun=
t,
> -                                             uint32_t *fpi_size)
> -{
> -    int32_t ret =3D FFA_RET_DENIED;
> -    struct domain *d =3D current->domain;
> -    struct ffa_ctx *ctx =3D d->arch.tee;
> -
> -    /*
> -     * FF-A v1.0 has w5 MBZ while v1.1 allows
> -     * FFA_PARTITION_INFO_GET_COUNT_FLAG to be non-zero.
> -     *
> -     * FFA_PARTITION_INFO_GET_COUNT is only using registers and not the
> -     * rxtx buffer so do the partition_info_get directly.
> -     */
> -    if ( w5 =3D=3D FFA_PARTITION_INFO_GET_COUNT_FLAG &&
> -         ctx->guest_vers =3D=3D FFA_VERSION_1_1 )
> -        return ffa_partition_info_get(w1, w2, w3, w4, w5, count, fpi_siz=
e);
> -    if ( w5 )
> -        return FFA_RET_INVALID_PARAMETERS;
> -
> -    if ( !ffa_rx )
> -        return FFA_RET_DENIED;
> -
> -    if ( !spin_trylock(&ctx->rx_lock) )
> -        return FFA_RET_BUSY;
> -
> -    if ( !ctx->page_count || !ctx->rx_is_free )
> -        goto out;
> -    spin_lock(&ffa_rx_buffer_lock);
> -    ret =3D ffa_partition_info_get(w1, w2, w3, w4, w5, count, fpi_size);
> -    if ( ret )
> -        goto out_rx_buf_unlock;
> -    /*
> -     * ffa_partition_info_get() succeeded so we now own the RX buffer we
> -     * share with the SPMC. We must give it back using ffa_rx_release()
> -     * once we've copied the content.
> -     */
> -
> -    if ( ctx->guest_vers =3D=3D FFA_VERSION_1_0 )
> -    {
> -        size_t n;
> -        struct ffa_partition_info_1_1 *src =3D ffa_rx;
> -        struct ffa_partition_info_1_0 *dst =3D ctx->rx;
> -
> -        if ( ctx->page_count * FFA_PAGE_SIZE < *count * sizeof(*dst) )
> -        {
> -            ret =3D FFA_RET_NO_MEMORY;
> -            goto out_rx_release;
> -        }
> -
> -        for ( n =3D 0; n < *count; n++ )
> -        {
> -            dst[n].id =3D src[n].id;
> -            dst[n].execution_context =3D src[n].execution_context;
> -            dst[n].partition_properties =3D src[n].partition_properties;
> -        }
> -    }
> -    else
> -    {
> -        size_t sz =3D *count * *fpi_size;
> -
> -        if ( ctx->page_count * FFA_PAGE_SIZE < sz )
> -        {
> -            ret =3D FFA_RET_NO_MEMORY;
> -            goto out_rx_release;
> -        }
> -
> -        memcpy(ctx->rx, ffa_rx, sz);
> -    }
> -    ctx->rx_is_free =3D false;
> -out_rx_release:
> -    ffa_rx_release();
> -out_rx_buf_unlock:
> -    spin_unlock(&ffa_rx_buffer_lock);
> -out:
> -    spin_unlock(&ctx->rx_lock);
> -
> -    return ret;
> -}
> -
> static int32_t ffa_handle_rx_release(void)
> {
>     int32_t ret =3D FFA_RET_DENIED;
> @@ -604,46 +419,9 @@ static bool ffa_handle_call(struct cpu_user_regs *re=
gs)
>     }
> }
>=20
> -static bool is_in_subscr_list(const uint16_t *subscr, uint16_t start,
> -                              uint16_t end, uint16_t sp_id)
> -{
> -    unsigned int n;
> -
> -    for ( n =3D start; n < end; n++ )
> -    {
> -        if ( subscr[n] =3D=3D sp_id )
> -            return true;
> -    }
> -
> -    return false;
> -}
> -
> -static void vm_destroy_bitmap_init(struct ffa_ctx *ctx,
> -                                   unsigned int create_signal_count)
> -{
> -    unsigned int n;
> -
> -    for ( n =3D 0; n < subscr_vm_destroyed_count; n++ )
> -    {
> -        /*
> -         * Skip SPs subscribed to the VM created event that never was
> -         * notified of the VM creation due to an error during
> -         * ffa_domain_init().
> -         */
> -        if ( is_in_subscr_list(subscr_vm_created, create_signal_count,
> -                               subscr_vm_created_count,
> -                               subscr_vm_destroyed[n]) )
> -            continue;
> -
> -        set_bit(n, ctx->vm_destroy_bitmap);
> -    }
> -}
> -
> static int ffa_domain_init(struct domain *d)
> {
>     struct ffa_ctx *ctx;
> -    unsigned int n;
> -    int32_t res;
>=20
>     if ( !ffa_version )
>         return -ENODEV;
> @@ -654,8 +432,7 @@ static int ffa_domain_init(struct domain *d)
>     if ( d->domain_id >=3D UINT16_MAX)
>         return -ERANGE;
>=20
> -    ctx =3D xzalloc_flex_struct(struct ffa_ctx, vm_destroy_bitmap,
> -                              BITS_TO_LONGS(subscr_vm_destroyed_count));
> +    ctx =3D xzalloc(struct ffa_ctx);
>     if ( !ctx )
>         return -ENOMEM;
>=20
> @@ -663,66 +440,28 @@ static int ffa_domain_init(struct domain *d)
>     ctx->teardown_d =3D d;
>     INIT_LIST_HEAD(&ctx->shm_list);
>=20
> -    for ( n =3D 0; n < subscr_vm_created_count; n++ )
> -    {
> -        res =3D ffa_direct_req_send_vm(subscr_vm_created[n], ffa_get_vm_=
id(d),
> -                                     FFA_MSG_SEND_VM_CREATED);
> -        if ( res )
> -        {
> -            printk(XENLOG_ERR "ffa: Failed to report creation of vm_id %=
u to  %u: res %d\n",
> -                   ffa_get_vm_id(d), subscr_vm_created[n], res);
> -            break;
> -        }
> -    }
> -    vm_destroy_bitmap_init(ctx, n);
> -    if ( n !=3D subscr_vm_created_count )
> +    /*
> +     * ffa_domain_teardown() will be called if ffa_domain_init() returns=
 an
> +     * error, so no need for cleanup in this function.
> +     */
> +
> +    if ( !ffa_partinfo_domain_init(d) )
>         return -EIO;
>=20
>     return 0;
> }
>=20
> -static void send_vm_destroyed(struct domain *d)
> -{
> -    struct ffa_ctx *ctx =3D d->arch.tee;
> -    unsigned int n;
> -    int32_t res;
> -
> -    for ( n =3D 0; n < subscr_vm_destroyed_count; n++ )
> -    {
> -        if ( !test_bit(n, ctx->vm_destroy_bitmap) )
> -            continue;
> -
> -        res =3D ffa_direct_req_send_vm(subscr_vm_destroyed[n], ffa_get_v=
m_id(d),
> -                                     FFA_MSG_SEND_VM_DESTROYED);
> -
> -        if ( res )
> -        {
> -            printk(XENLOG_ERR "%pd: ffa: Failed to report destruction of=
 vm_id %u to %u: res %d\n",
> -                   d, ffa_get_vm_id(d), subscr_vm_destroyed[n], res);
> -        }
> -
> -        /*
> -         * For these two error codes the hypervisor is expected to resen=
d
> -         * the destruction message. For the rest it is expected that the
> -         * error is permanent and that is doesn't help to resend the
> -         * destruction message.
> -         */
> -        if ( res !=3D FFA_RET_INTERRUPTED && res !=3D FFA_RET_RETRY )
> -            clear_bit(n, ctx->vm_destroy_bitmap);
> -    }
> -}
> -
> static void ffa_domain_teardown_continue(struct ffa_ctx *ctx, bool first_=
time)
> {
>     struct ffa_ctx *next_ctx =3D NULL;
>     bool retry =3D false;
>=20
> -    send_vm_destroyed(ctx->teardown_d);
> +    if ( !ffa_partinfo_domain_destroy(ctx->teardown_d) )
> +        retry =3D true;
>     if ( !ffa_shm_domain_destroy(ctx->teardown_d) )
>         retry =3D true;
>=20
> -    if ( retry ||
> -         !bitmap_empty(ctx->vm_destroy_bitmap, subscr_vm_destroyed_count=
) )
> +    if ( retry )
>     {
>         printk(XENLOG_G_INFO "%pd: ffa: Remaining cleanup, retrying\n", c=
tx->teardown_d);
>=20
> @@ -796,82 +535,6 @@ static int ffa_relinquish_resources(struct domain *d=
)
>     return 0;
> }
>=20
> -static void uninit_subscribers(void)
> -{
> -        subscr_vm_created_count =3D 0;
> -        subscr_vm_destroyed_count =3D 0;
> -        XFREE(subscr_vm_created);
> -        XFREE(subscr_vm_destroyed);
> -}
> -
> -static bool init_subscribers(struct ffa_partition_info_1_1 *fpi, uint16_=
t count)
> -{
> -    uint16_t n;
> -    uint16_t c_pos;
> -    uint16_t d_pos;
> -
> -    subscr_vm_created_count =3D 0;
> -    subscr_vm_destroyed_count =3D 0;
> -    for ( n =3D 0; n < count; n++ )
> -    {
> -        if ( fpi[n].partition_properties & FFA_PART_PROP_NOTIF_CREATED )
> -            subscr_vm_created_count++;
> -        if ( fpi[n].partition_properties & FFA_PART_PROP_NOTIF_DESTROYED=
 )
> -            subscr_vm_destroyed_count++;
> -    }
> -
> -    if ( subscr_vm_created_count )
> -        subscr_vm_created =3D xzalloc_array(uint16_t, subscr_vm_created_=
count);
> -    if ( subscr_vm_destroyed_count )
> -        subscr_vm_destroyed =3D xzalloc_array(uint16_t,
> -                                            subscr_vm_destroyed_count);
> -    if ( (subscr_vm_created_count && !subscr_vm_created) ||
> -         (subscr_vm_destroyed_count && !subscr_vm_destroyed) )
> -    {
> -        printk(XENLOG_ERR "ffa: Failed to allocate subscription lists\n"=
);
> -        uninit_subscribers();
> -        return false;
> -    }
> -
> -    for ( c_pos =3D 0, d_pos =3D 0, n =3D 0; n < count; n++ )
> -    {
> -        if ( fpi[n].partition_properties & FFA_PART_PROP_NOTIF_CREATED )
> -            subscr_vm_created[c_pos++] =3D fpi[n].id;
> -        if ( fpi[n].partition_properties & FFA_PART_PROP_NOTIF_DESTROYED=
 )
> -            subscr_vm_destroyed[d_pos++] =3D fpi[n].id;
> -    }
> -
> -    return true;
> -}
> -
> -static bool init_sps(void)
> -{
> -    bool ret =3D false;
> -    uint32_t fpi_size;
> -    uint32_t count;
> -    int e;
> -
> -    e =3D ffa_partition_info_get(0, 0, 0, 0, 0, &count, &fpi_size);
> -    if ( e )
> -    {
> -        printk(XENLOG_ERR "ffa: Failed to get list of SPs: %d\n", e);
> -        goto out;
> -    }
> -
> -    if ( count >=3D UINT16_MAX )
> -    {
> -        printk(XENLOG_ERR "ffa: Impossible number of SPs: %u\n", count);
> -        goto out;
> -    }
> -
> -    ret =3D init_subscribers(ffa_rx, count);
> -
> -out:
> -    ffa_rx_release();
> -
> -    return ret;
> -}
> -
> static bool ffa_probe(void)
> {
>     uint32_t vers;
> @@ -949,7 +612,7 @@ static bool ffa_probe(void)
>     }
>     ffa_version =3D vers;
>=20
> -    if ( !init_sps() )
> +    if ( !ffa_partinfo_init() )
>         goto err_free_ffa_tx;
>=20
>     INIT_LIST_HEAD(&ffa_teardown_head);
> diff --git a/xen/arch/arm/tee/ffa_partinfo.c b/xen/arch/arm/tee/ffa_parti=
nfo.c
> new file mode 100644
> index 000000000000..dc1059584828
> --- /dev/null
> +++ b/xen/arch/arm/tee/ffa_partinfo.c
> @@ -0,0 +1,373 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Copyright (C) 2024  Linaro Limited
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +#include "ffa_private.h"
> +
> +/* Partition information descriptor defined in FF-A-1.0-REL */
> +struct ffa_partition_info_1_0 {
> +    uint16_t id;
> +    uint16_t execution_context;
> +    uint32_t partition_properties;
> +};
> +
> +/* Partition information descriptor defined in FF-A-1.1-REL0 */
> +struct ffa_partition_info_1_1 {
> +    uint16_t id;
> +    uint16_t execution_context;
> +    uint32_t partition_properties;
> +    uint8_t uuid[16];
> +};
> +
> +/* SPs subscribing to VM_CREATE and VM_DESTROYED events */
> +static uint16_t *subscr_vm_created __read_mostly;
> +static uint16_t subscr_vm_created_count __read_mostly;
> +static uint16_t *subscr_vm_destroyed __read_mostly;
> +static uint16_t subscr_vm_destroyed_count __read_mostly;
> +
> +static int32_t ffa_partition_info_get(uint32_t w1, uint32_t w2, uint32_t=
 w3,
> +                                      uint32_t w4, uint32_t w5, uint32_t=
 *count,
> +                                      uint32_t *fpi_size)
> +{
> +    const struct arm_smccc_1_2_regs arg =3D {
> +        .a0 =3D FFA_PARTITION_INFO_GET,
> +        .a1 =3D w1,
> +        .a2 =3D w2,
> +        .a3 =3D w3,
> +        .a4 =3D w4,
> +        .a5 =3D w5,
> +    };
> +    struct arm_smccc_1_2_regs resp;
> +    uint32_t ret;
> +
> +    arm_smccc_1_2_smc(&arg, &resp);
> +
> +    ret =3D ffa_get_ret_code(&resp);
> +    if ( !ret )
> +    {
> +        *count =3D resp.a2;
> +        *fpi_size =3D resp.a3;
> +    }
> +
> +    return ret;
> +}
> +
> +int32_t ffa_handle_partition_info_get(uint32_t w1, uint32_t w2, uint32_t=
 w3,
> +                                      uint32_t w4, uint32_t w5, uint32_t=
 *count,
> +                                      uint32_t *fpi_size)
> +{
> +    int32_t ret =3D FFA_RET_DENIED;
> +    struct domain *d =3D current->domain;
> +    struct ffa_ctx *ctx =3D d->arch.tee;
> +
> +    /*
> +     * FF-A v1.0 has w5 MBZ while v1.1 allows
> +     * FFA_PARTITION_INFO_GET_COUNT_FLAG to be non-zero.
> +     *
> +     * FFA_PARTITION_INFO_GET_COUNT is only using registers and not the
> +     * rxtx buffer so do the partition_info_get directly.
> +     */
> +    if ( w5 =3D=3D FFA_PARTITION_INFO_GET_COUNT_FLAG &&
> +         ctx->guest_vers =3D=3D FFA_VERSION_1_1 )
> +        return ffa_partition_info_get(w1, w2, w3, w4, w5, count, fpi_siz=
e);
> +    if ( w5 )
> +        return FFA_RET_INVALID_PARAMETERS;
> +
> +    if ( !ffa_rx )
> +        return FFA_RET_DENIED;
> +
> +    if ( !spin_trylock(&ctx->rx_lock) )
> +        return FFA_RET_BUSY;
> +
> +    if ( !ctx->page_count || !ctx->rx_is_free )
> +        goto out;
> +    spin_lock(&ffa_rx_buffer_lock);
> +    ret =3D ffa_partition_info_get(w1, w2, w3, w4, w5, count, fpi_size);
> +    if ( ret )
> +        goto out_rx_buf_unlock;
> +    /*
> +     * ffa_partition_info_get() succeeded so we now own the RX buffer we
> +     * share with the SPMC. We must give it back using ffa_rx_release()
> +     * once we've copied the content.
> +     */
> +
> +    if ( ctx->guest_vers =3D=3D FFA_VERSION_1_0 )
> +    {
> +        size_t n;
> +        struct ffa_partition_info_1_1 *src =3D ffa_rx;
> +        struct ffa_partition_info_1_0 *dst =3D ctx->rx;
> +
> +        if ( ctx->page_count * FFA_PAGE_SIZE < *count * sizeof(*dst) )
> +        {
> +            ret =3D FFA_RET_NO_MEMORY;
> +            goto out_rx_release;
> +        }
> +
> +        for ( n =3D 0; n < *count; n++ )
> +        {
> +            dst[n].id =3D src[n].id;
> +            dst[n].execution_context =3D src[n].execution_context;
> +            dst[n].partition_properties =3D src[n].partition_properties;
> +        }
> +    }
> +    else
> +    {
> +        size_t sz =3D *count * *fpi_size;
> +
> +        if ( ctx->page_count * FFA_PAGE_SIZE < sz )
> +        {
> +            ret =3D FFA_RET_NO_MEMORY;
> +            goto out_rx_release;
> +        }
> +
> +        memcpy(ctx->rx, ffa_rx, sz);
> +    }
> +    ctx->rx_is_free =3D false;
> +out_rx_release:
> +    ffa_rx_release();
> +out_rx_buf_unlock:
> +    spin_unlock(&ffa_rx_buffer_lock);
> +out:
> +    spin_unlock(&ctx->rx_lock);
> +
> +    return ret;
> +}
> +
> +static int32_t ffa_direct_req_send_vm(uint16_t sp_id, uint16_t vm_id,
> +                                      uint8_t msg)
> +{
> +    uint32_t exp_resp =3D FFA_MSG_FLAG_FRAMEWORK;
> +    unsigned int retry_count =3D 0;
> +    int32_t res;
> +
> +    if ( msg =3D=3D FFA_MSG_SEND_VM_CREATED )
> +        exp_resp |=3D FFA_MSG_RESP_VM_CREATED;
> +    else if ( msg =3D=3D FFA_MSG_SEND_VM_DESTROYED )
> +        exp_resp |=3D FFA_MSG_RESP_VM_DESTROYED;
> +    else
> +        return FFA_RET_INVALID_PARAMETERS;
> +
> +    do {
> +        const struct arm_smccc_1_2_regs arg =3D {
> +            .a0 =3D FFA_MSG_SEND_DIRECT_REQ_32,
> +            .a1 =3D sp_id,
> +            .a2 =3D FFA_MSG_FLAG_FRAMEWORK | msg,
> +            .a5 =3D vm_id,
> +        };
> +        struct arm_smccc_1_2_regs resp;
> +
> +        arm_smccc_1_2_smc(&arg, &resp);
> +        if ( resp.a0 !=3D FFA_MSG_SEND_DIRECT_RESP_32 || resp.a2 !=3D ex=
p_resp )
> +        {
> +            /*
> +             * This is an invalid response, likely due to some error in =
the
> +             * implementation of the ABI.
> +             */
> +            return FFA_RET_INVALID_PARAMETERS;
> +        }
> +        res =3D resp.a3;
> +        if ( ++retry_count > 10 )
> +        {
> +            /*
> +             * TODO
> +             * FFA_RET_INTERRUPTED means that the SPMC has a pending
> +             * non-secure interrupt, we need a way of delivering that
> +             * non-secure interrupt.
> +             * FFA_RET_RETRY is the SP telling us that it's temporarily
> +             * blocked from handling the direct request, we need a gener=
ic
> +             * way to deal with this.
> +             * For now in both cases, give up after a few retries.
> +             */
> +            return res;
> +        }
> +    } while ( res =3D=3D FFA_RET_INTERRUPTED || res =3D=3D FFA_RET_RETRY=
 );
> +
> +    return res;
> +}
> +
> +static void uninit_subscribers(void)
> +{
> +        subscr_vm_created_count =3D 0;
> +        subscr_vm_destroyed_count =3D 0;
> +        XFREE(subscr_vm_created);
> +        XFREE(subscr_vm_destroyed);
> +}
> +
> +static bool init_subscribers(struct ffa_partition_info_1_1 *fpi, uint16_=
t count)
> +{
> +    uint16_t n;
> +    uint16_t c_pos;
> +    uint16_t d_pos;
> +
> +    subscr_vm_created_count =3D 0;
> +    subscr_vm_destroyed_count =3D 0;
> +    for ( n =3D 0; n < count; n++ )
> +    {
> +        if ( fpi[n].partition_properties & FFA_PART_PROP_NOTIF_CREATED )
> +            subscr_vm_created_count++;
> +        if ( fpi[n].partition_properties & FFA_PART_PROP_NOTIF_DESTROYED=
 )
> +            subscr_vm_destroyed_count++;
> +    }
> +
> +    if ( subscr_vm_created_count )
> +        subscr_vm_created =3D xzalloc_array(uint16_t, subscr_vm_created_=
count);
> +    if ( subscr_vm_destroyed_count )
> +        subscr_vm_destroyed =3D xzalloc_array(uint16_t,
> +                                            subscr_vm_destroyed_count);
> +    if ( (subscr_vm_created_count && !subscr_vm_created) ||
> +         (subscr_vm_destroyed_count && !subscr_vm_destroyed) )
> +    {
> +        printk(XENLOG_ERR "ffa: Failed to allocate subscription lists\n"=
);
> +        uninit_subscribers();
> +        return false;
> +    }
> +
> +    for ( c_pos =3D 0, d_pos =3D 0, n =3D 0; n < count; n++ )
> +    {
> +        if ( fpi[n].partition_properties & FFA_PART_PROP_NOTIF_CREATED )
> +            subscr_vm_created[c_pos++] =3D fpi[n].id;
> +        if ( fpi[n].partition_properties & FFA_PART_PROP_NOTIF_DESTROYED=
 )
> +            subscr_vm_destroyed[d_pos++] =3D fpi[n].id;
> +    }
> +
> +    return true;
> +}
> +
> +
> +
> +bool ffa_partinfo_init(void)
> +{
> +    bool ret =3D false;
> +    uint32_t fpi_size;
> +    uint32_t count;
> +    int e;
> +
> +    e =3D ffa_partition_info_get(0, 0, 0, 0, 0, &count, &fpi_size);
> +    if ( e )
> +    {
> +        printk(XENLOG_ERR "ffa: Failed to get list of SPs: %d\n", e);
> +        goto out;
> +    }
> +
> +    if ( count >=3D UINT16_MAX )
> +    {
> +        printk(XENLOG_ERR "ffa: Impossible number of SPs: %u\n", count);
> +        goto out;
> +    }
> +
> +    ret =3D init_subscribers(ffa_rx, count);
> +
> +out:
> +    ffa_rx_release();
> +
> +    return ret;
> +}
> +
> +static bool is_in_subscr_list(const uint16_t *subscr, uint16_t start,
> +                              uint16_t end, uint16_t sp_id)
> +{
> +    unsigned int n;
> +
> +    for ( n =3D start; n < end; n++ )
> +    {
> +        if ( subscr[n] =3D=3D sp_id )
> +            return true;
> +    }
> +
> +    return false;
> +}
> +
> +static void vm_destroy_bitmap_init(struct ffa_ctx *ctx,
> +                                   unsigned int create_signal_count)
> +{
> +    unsigned int n;
> +
> +    for ( n =3D 0; n < subscr_vm_destroyed_count; n++ )
> +    {
> +        /*
> +         * Skip SPs subscribed to the VM created event that never was
> +         * notified of the VM creation due to an error during
> +         * ffa_domain_init().
> +         */
> +        if ( is_in_subscr_list(subscr_vm_created, create_signal_count,
> +                               subscr_vm_created_count,
> +                               subscr_vm_destroyed[n]) )
> +            continue;
> +
> +        set_bit(n, ctx->vm_destroy_bitmap);
> +    }
> +}
> +
> +bool ffa_partinfo_domain_init(struct domain *d)
> +{
> +    unsigned int count =3D BITS_TO_LONGS(subscr_vm_destroyed_count);
> +    struct ffa_ctx *ctx =3D d->arch.tee;
> +    unsigned int n;
> +    int32_t res;
> +
> +    ctx->vm_destroy_bitmap =3D xzalloc_array(unsigned long, count);
> +    if ( !ctx->vm_destroy_bitmap )
> +        return false;
> +
> +    for ( n =3D 0; n < subscr_vm_created_count; n++ )
> +    {
> +        res =3D ffa_direct_req_send_vm(subscr_vm_created[n], ffa_get_vm_=
id(d),
> +                                     FFA_MSG_SEND_VM_CREATED);
> +        if ( res )
> +        {
> +            printk(XENLOG_ERR "ffa: Failed to report creation of vm_id %=
u to  %u: res %d\n",
> +                   ffa_get_vm_id(d), subscr_vm_created[n], res);
> +            break;
> +        }
> +    }
> +    vm_destroy_bitmap_init(ctx, n);
> +
> +    return n =3D=3D subscr_vm_created_count;
> +}
> +
> +bool ffa_partinfo_domain_destroy(struct domain *d)
> +{
> +    struct ffa_ctx *ctx =3D d->arch.tee;
> +    unsigned int n;
> +    int32_t res;
> +
> +    if ( !ctx->vm_destroy_bitmap )
> +        return true;
> +
> +    for ( n =3D 0; n < subscr_vm_destroyed_count; n++ )
> +    {
> +        if ( !test_bit(n, ctx->vm_destroy_bitmap) )
> +            continue;
> +
> +        res =3D ffa_direct_req_send_vm(subscr_vm_destroyed[n], ffa_get_v=
m_id(d),
> +                                     FFA_MSG_SEND_VM_DESTROYED);
> +
> +        if ( res )
> +        {
> +            printk(XENLOG_ERR "%pd: ffa: Failed to report destruction of=
 vm_id %u to %u: res %d\n",
> +                   d, ffa_get_vm_id(d), subscr_vm_destroyed[n], res);
> +        }
> +
> +        /*
> +         * For these two error codes the hypervisor is expected to resen=
d
> +         * the destruction message. For the rest it is expected that the
> +         * error is permanent and that is doesn't help to resend the
> +         * destruction message.
> +         */
> +        if ( res !=3D FFA_RET_INTERRUPTED && res !=3D FFA_RET_RETRY )
> +            clear_bit(n, ctx->vm_destroy_bitmap);
> +    }
> +
> +    if ( bitmap_empty(ctx->vm_destroy_bitmap, subscr_vm_destroyed_count)=
 )
> +        XFREE(ctx->vm_destroy_bitmap);
> +
> +    return !ctx->vm_destroy_bitmap;
> +}
> diff --git a/xen/arch/arm/tee/ffa_private.h b/xen/arch/arm/tee/ffa_privat=
e.h
> index f3e2f42e573e..6b32b69cfe90 100644
> --- a/xen/arch/arm/tee/ffa_private.h
> +++ b/xen/arch/arm/tee/ffa_private.h
> @@ -244,7 +244,7 @@ struct ffa_ctx {
>      * Used for ffa_domain_teardown() to keep track of which SPs should b=
e
>      * notified that this guest is being destroyed.
>      */
> -    unsigned long vm_destroy_bitmap[];
> +    unsigned long *vm_destroy_bitmap;
> };
>=20
> extern void *ffa_rx;
> @@ -256,6 +256,13 @@ bool ffa_shm_domain_destroy(struct domain *d);
> void ffa_handle_mem_share(struct cpu_user_regs *regs);
> int ffa_handle_mem_reclaim(uint64_t handle, uint32_t flags);
>=20
> +bool ffa_partinfo_init(void);
> +bool ffa_partinfo_domain_init(struct domain *d);
> +bool ffa_partinfo_domain_destroy(struct domain *d);
> +int32_t ffa_handle_partition_info_get(uint32_t w1, uint32_t w2, uint32_t=
 w3,
> +                                      uint32_t w4, uint32_t w5, uint32_t=
 *count,
> +                                      uint32_t *fpi_size);
> +
>=20
> static inline uint16_t ffa_get_vm_id(const struct domain *d)
> {
> @@ -325,4 +332,9 @@ static inline int32_t ffa_simple_call(uint32_t fid, r=
egister_t a1,
>     return ffa_get_ret_code(&resp);
> }
>=20
> +static inline int32_t ffa_rx_release(void)
> +{
> +    return ffa_simple_call(FFA_RX_RELEASE, 0, 0, 0, 0);
> +}
> +
> #endif /*__FFA_PRIVATE_H__*/
> --=20
> 2.34.1
>=20



From xen-devel-bounces@lists.xenproject.org Wed Mar 27 13:44:06 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 13:44:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698545.1090338 (Exim 4.92)
	(envelope-from )
	id 1rpTZT-0004nm-WE; Wed, 27 Mar 2024 13:44:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698545.1090338; Wed, 27 Mar 2024 13:44:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpTZT-0004nf-TY; Wed, 27 Mar 2024 13:44:03 +0000
Received: by outflank-mailman (input) for mailman id 698545;
 Wed, 27 Mar 2024 13:44:02 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpTZS-0004nT-Dl
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 13:44:02 +0000
Received: from EUR02-AM0-obe.outbound.protection.outlook.com
 (mail-am0eur02on20600.outbound.protection.outlook.com
 [2a01:111:f403:2606::600])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 10ccb4f9-ec40-11ee-a1ef-f123f15fe8a2;
 Wed, 27 Mar 2024 14:44:00 +0100 (CET)
Received: from DU7P189CA0012.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:552::15)
 by DB8PR08MB5531.eurprd08.prod.outlook.com (2603:10a6:10:11e::18) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.32; Wed, 27 Mar
 2024 13:43:58 +0000
Received: from DB5PEPF00014B98.eurprd02.prod.outlook.com
 (2603:10a6:10:552:cafe::f1) by DU7P189CA0012.outlook.office365.com
 (2603:10a6:10:552::15) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.13 via Frontend
 Transport; Wed, 27 Mar 2024 13:43:58 +0000
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by
 DB5PEPF00014B98.mail.protection.outlook.com (10.167.8.165) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.7409.10 via Frontend Transport; Wed, 27 Mar 2024 13:43:57 +0000
Received: ("Tessian outbound 9b7417e2a8eb:v300");
 Wed, 27 Mar 2024 13:43:57 +0000
Received: from af7ed2f9c7d6.1
 by 64aa7808-outbound-1.mta.getcheckrecipient.com id
 AE009322-B104-4F91-9E99-1F160F15332F.1; 
 Wed, 27 Mar 2024 13:43:51 +0000
Received: from EUR05-AM6-obe.outbound.protection.outlook.com
 by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id af7ed2f9c7d6.1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384);
 Wed, 27 Mar 2024 13:43:51 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com (2603:10a6:10:25a::24)
 by PAXPR08MB7552.eurprd08.prod.outlook.com (2603:10a6:102:24f::7)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.32; Wed, 27 Mar
 2024 13:43:49 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::7fb0:6621:56b:22d5]) by DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::7fb0:6621:56b:22d5%3]) with mapi id 15.20.7409.031; Wed, 27 Mar 2024
 13:43:49 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 10ccb4f9-ec40-11ee-a1ef-f123f15fe8a2
ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass;
 b=AcpXWBemYBeIqeh6gsPkaIV0Y8RH18pgQVfW9P7fpPsuSm7JDsnajkB+yatO49wU7+6RjsEziwEU09wjZBVFLOWOWTZeebqHRmLddqyhpGpA9niuoyPN3n51tYqju+a5wh3hefZZo93LK/7VpPaChdgl7oOjEdgyWSg6CkB/O3BcnR2nFruA4bNx3eihCfTCUYcLOWZWF2bAx/dP8rVXT6QYfLeADrq62TbHUQjfo/OOsU0M7wzcgIyvEQB1LBVT9k+I503OCmEYSAHtOsnGcOAekH2iPCpMIbssUc9/mxDcWsHGVfM52D1BvBwkpVv0v4UucWnj410StF6ZU2rREg==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=QDLj7wRklPxfouvU5vbm09pKQSKxZhlgC9SFnOszY2E=;
 b=K7H6DmoL+mTIT369/nZQPZRgGiJj819w5DGJo/Mu568IgBqvTGtpkP5xCpnJIQW2J7dYoYwJEO5RrgX0Ojf5EcViU6SZJGP7wVBNLdRMHdEwtW+hxLsPDNk95uTuWADF6gmMl4s4EvIjSzKSEVWilJ8F4E5Je1tL6VgxB0i1QTcd7pEl3IL8T3bcOjzSWjBSb3IusXVeexZFjsHnBHtGarWAT1rEAKyrAfjUcXM0JQ5tRV6ZqGIsfrbhGnxGvMrSQHGbNI5WwHyKynmBc6bCcZqiP3PggPjkwEIiA08933Gc6+sMGmnJNWgJqBDzRJ1iR87XjVFMXq4Kkpvt2kS30w==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 63.35.35.123) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=arm.com;
 dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com;
 dkim=pass (signature was verified) header.d=armh.onmicrosoft.com; arc=pass (0
 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com]
 dmarc=[1,1,header.from=arm.com])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com;
 s=selector2-armh-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=QDLj7wRklPxfouvU5vbm09pKQSKxZhlgC9SFnOszY2E=;
 b=IwbShjZCEDChMaUTU5bP99wFET0akxJ8WzlYk/HNaqdPCPn8PCwPEs154UQobv1rmwUEVbnwHDDaMpB6VUYIEJSdo9Cwy2Wi9OkoqZoWOJqxHTmbNrMN4Je6l3ydvU4rbBwDgIV6pJ/YGqpHDCh/u77+WqwUqUL6hl5ABAxO/WI=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=armh.onmicrosoft.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 63.35.35.123 as permitted sender) receiver=protection.outlook.com;
 client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
 pr=C
X-CheckRecipientChecked: true
X-CR-MTA-CID: 0357f2a63b0b631e
X-CR-MTA-TID: 64aa7808
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=A4IA1yeDi9eTjC40ZQZ2bcsZyQAE0Jyp5pA0gY2SM+PLk08RDoLtnxZoKA6u1POEXKMt7eaol4Hww9eGbpAvJb6NtYgFWo4UD3tzAU+Cq3wBbToExKQxJN8icqgJvJ2vBNiznyEShVnYragL3iSWX0wZWKFK2cnFP/gSYr2txmVFbEyuw5x9QExRruil2BeiZmwmAAyW9qsXu4IXrfl0gsDBO0cWd7p8of5pMbjLCHWMmAQSIUU9bAHwkwnb2m0JES7QG1T8d/mK+I4LbhHprQugKQ7zPqdclvtS6gWCqdrdsm6k8AZi1eBhy9SZKKF71RpzecTtUqrzssTxRIeJyw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=QDLj7wRklPxfouvU5vbm09pKQSKxZhlgC9SFnOszY2E=;
 b=eqW2yi8EBEK0xFlLFOf1geN8RTd6tbg09d+wfT2ahEecrPGmahznDUjM19hRieskKmmcud8ugAF5GUrduQbvSBzqPIQtF0W3ITlRoD34OE8qZWiEGYPTXiRUSp1bT89UqVGl/tF52QiR5c0ok8ioBzjdQaIO+vY7jtF9Ak4lo7Z1bsKTxau/T/Z7j9I71aTt8Pu0Yi1Uhakmoz+bpAGJLKH+n5G8zP5qWAg2yFZOom+XMFWicFT7Zshsqz0KiTADHJk9MxWgOuFf5XTc/9O2oNhn8eiQza0U28DbkVjcNVfsDxIcYpe+aJnle0lM5CgU2/zLci6wpmow0utO+odCKw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass
 header.d=arm.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com;
 s=selector2-armh-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=QDLj7wRklPxfouvU5vbm09pKQSKxZhlgC9SFnOszY2E=;
 b=IwbShjZCEDChMaUTU5bP99wFET0akxJ8WzlYk/HNaqdPCPn8PCwPEs154UQobv1rmwUEVbnwHDDaMpB6VUYIEJSdo9Cwy2Wi9OkoqZoWOJqxHTmbNrMN4Je6l3ydvU4rbBwDgIV6pJ/YGqpHDCh/u77+WqwUqUL6hl5ABAxO/WI=
From: Bertrand Marquis 
To: Jens Wiklander 
CC: Xen-devel , "patches@linaro.org"
	, Volodymyr Babchuk , Stefano
 Stabellini , Julien Grall , Michal
 Orzel 
Subject: Re: [XEN PATCH 5/6] xen/arm: ffa: separate rxtx buffer routines
Thread-Topic: [XEN PATCH 5/6] xen/arm: ffa: separate rxtx buffer routines
Thread-Index: AQHafphRyx1suD/hEEaNU2WoRq6yHLFLnFoA
Date: Wed, 27 Mar 2024 13:43:49 +0000
Message-ID: <9C23C915-E25B-4BDF-B33D-68FF339BFE6B@arm.com>
References: <20240325093904.3466092-1-jens.wiklander@linaro.org>
 <20240325093904.3466092-6-jens.wiklander@linaro.org>
In-Reply-To: <20240325093904.3466092-6-jens.wiklander@linaro.org>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3774.200.91.1.1)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DB9PR08MB6588:EE_|PAXPR08MB7552:EE_|DB5PEPF00014B98:EE_|DB8PR08MB5531:EE_
X-MS-Office365-Filtering-Correlation-Id: d9775323-c623-477e-5f14-08dc4e63f3d0
x-checkrecipientrouted: true
nodisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted: BCL:0;
X-Microsoft-Antispam-Message-Info-Original:
 O43Zd/uA9EjBuGeBP1Zgdnxbqif5GeomzOGELkoSGb5Dcr87DNjobu7OvNYnEwY2N37kFSL9yKEJlWC9p/pFtwxlf3cJX24hBs2z+91GVhyYLWuNiNSBgBSZvigTfLIfi7boZRxlZ12lWVoaMf0JYmG8lURS3OCVJSO12SuaMiImP6cR+UrtoVkKje5PPFnfjLOUJy8wsuc+FEwa96sRbzmLUqiWUIQr9Q69UsG/RJijt3TLsxjg/sX6Ojeq/pSze/n6dkj2WcTeR9eTjzXzMUM+z3E0hU9dCvF2cGTZyyWJfpvHmRpcjLIojdIHWNG+XLF3RiugNbjRY4aHy4CTKt14MRiilccwyNXiacERGgDNCtqJ+qsrNdIXfjXlF7Ni3Cw4JaD40qsVsiMptqhbcp0wZb4kGO6Wld0CoW0nn81TlIdYyBj33JmVdlhBFSsXCTDnhuXIdmWwb4imnRWSHIi2h9Rv3zwhz8FXE/et4HFZ708xTiVQnEdKFGfmPgQVvWqLeP/wySP/Zs7HWhuAVWCwGJ92ztYjUztGPLXMv+KbmQByTvItI1gfZwAfQr1g2WOSVh8iwMRk25sbu69FHBIMpcGOF5DGSHlTxf+hHRRZ8R1X07h5Y9dsnZybcHZ1J3yBCC+U1xzZ8scRNHDCs4F5bIvUMtg9HrqvTFVt+uOKdKpl844eGBSmQvDK7t0rhrv15cOMQMFKpdVthU+EvBxo9jJHn01C89EyKTYsClA=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB9PR08MB6588.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(366007)(376005)(1800799015)(38070700009);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAXPR08MB7552
Original-Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 DB5PEPF00014B98.eurprd02.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	c46c027e-e59e-4dd9-503f-08dc4e63ee99
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	7pjTlzLs/nlSYyDWdIuxQkCdqwh3CoH8hVyMw1hcICW4GeZ0XkQRNpfoNFLfVScWJz4DRT/JQra2/APNov+V6bJvlcv+NMZP42rbeCoj2v35vBHy0XSCqWX1qYPM9M/SHLUqlvIHhesOwStiiPZS4yCJPLeONYnsNVCJtRf82yB0/XrCcTkA/3/XO+GfzyNVD5FloDYZVIdPoo3O+ijOg/DRgO6Gib7DN5V/fUAYJ7jNIO+4GQ9NB13J8BnPGYqvxsYxFAyHZN3Yj9ZVUlRQ3ZBw842gJXqZumCXZreggDnvDChzTUldVKSIW1HiBvBotLIvqUhlk0e6Qa+IbVPwTXLPiyjOf7WgSPJ6yxLXqGsAjrFgSqqbQuQYEKI9lXs1xEjKH4c+nbuv9EnS2YVKYzWGytKkupT5qleQkgdYgUvmz2MxmV/jzYKUd/ieFw/wrmiiuMC7slttbVbDG2AQ/LmgS8LdM4M7dlISTwTY9H2/tmiyYI7VxeoXuLjt27z/uKze1S/+EFp6V7qejNvy5ZmTDk8UWxGMJHWX89sySgxy0HyLRXP675sdsMyRQBsEIw3R2D7KzwuHB5AG9SFXomTm6C0Eh8eIvLFt4+5ibJqcnBt5x+vYLDptpIZ4FLHQD+ALr5zWauaC8KpIQDFLP0taGikZxp+9TVmecRgR/q/QfW39fE4JwEvpZE1wc537DrgKK77MhcCwBarhr1ovXwlblgRUcWXNdNZA/Py6lgJZK6R2buKQHo2kZcZFSZ1O
X-Forefront-Antispam-Report:
	CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com;CAT:NONE;SFS:(13230031)(82310400014)(36860700004)(1800799015)(376005);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Mar 2024 13:43:57.8859
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: d9775323-c623-477e-5f14-08dc4e63f3d0
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DB5PEPF00014B98.eurprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR08MB5531

Hi Jens,

> On 25 Mar 2024, at 10:39, Jens Wiklander  wrot=
e:
>=20
> Move rxtx buffer routines into a spearate file for easier navigation in
> the source code.
>=20
> Add ffa_rxtx_init(), ffa_rxtx_destroy(), and ffa_rxtx_domain_destroy() to
> handle the ffa_rxtx internal things on initialization and teardown.
>=20
> Signed-off-by: Jens Wiklander 

Reviewed-by: Bertrand Marquis 

Cheers
Bertrand

> ---
> xen/arch/arm/tee/Makefile      |   1 +
> xen/arch/arm/tee/ffa.c         | 174 +-------------------------
> xen/arch/arm/tee/ffa_private.h |   7 ++
> xen/arch/arm/tee/ffa_rxtx.c    | 216 +++++++++++++++++++++++++++++++++
> 4 files changed, 229 insertions(+), 169 deletions(-)
> create mode 100644 xen/arch/arm/tee/ffa_rxtx.c
>=20
> diff --git a/xen/arch/arm/tee/Makefile b/xen/arch/arm/tee/Makefile
> index be644fba8055..f0112a2f922d 100644
> --- a/xen/arch/arm/tee/Makefile
> +++ b/xen/arch/arm/tee/Makefile
> @@ -1,5 +1,6 @@
> obj-$(CONFIG_FFA) +=3D ffa.o
> obj-$(CONFIG_FFA) +=3D ffa_shm.o
> obj-$(CONFIG_FFA) +=3D ffa_partinfo.o
> +obj-$(CONFIG_FFA) +=3D ffa_rxtx.o
> obj-y +=3D tee.o
> obj-$(CONFIG_OPTEE) +=3D optee.o
> diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
> index 7a2803881420..4f7775b8c890 100644
> --- a/xen/arch/arm/tee/ffa.c
> +++ b/xen/arch/arm/tee/ffa.c
> @@ -65,26 +65,6 @@
>=20
> #include "ffa_private.h"
>=20
> -/*
> - * Structs below ending with _1_0 are defined in FF-A-1.0-REL and
> - * structs ending with _1_1 are defined in FF-A-1.1-REL0.
> - */
> -
> -/* Endpoint RX/TX descriptor */
> -struct ffa_endpoint_rxtx_descriptor_1_0 {
> -    uint16_t sender_id;
> -    uint16_t reserved;
> -    uint32_t rx_range_count;
> -    uint32_t tx_range_count;
> -};
> -
> -struct ffa_endpoint_rxtx_descriptor_1_1 {
> -    uint16_t sender_id;
> -    uint16_t reserved;
> -    uint32_t rx_region_offs;
> -    uint32_t tx_region_offs;
> -};
> -
> /* Negotiated FF-A version to use with the SPMC */
> static uint32_t __ro_after_init ffa_version;
>=20
> @@ -145,12 +125,6 @@ static bool check_mandatory_feature(uint32_t id)
>     return !ret;
> }
>=20
> -static int32_t ffa_rxtx_map(paddr_t tx_addr, paddr_t rx_addr,
> -                            uint32_t page_count)
> -{
> -    return ffa_simple_call(FFA_RXTX_MAP_64, tx_addr, rx_addr, page_count=
, 0);
> -}
> -
> static void handle_version(struct cpu_user_regs *regs)
> {
>     struct domain *d =3D current->domain;
> @@ -166,127 +140,6 @@ static void handle_version(struct cpu_user_regs *re=
gs)
>     ffa_set_regs(regs, vers, 0, 0, 0, 0, 0, 0, 0);
> }
>=20
> -static uint32_t ffa_handle_rxtx_map(uint32_t fid, register_t tx_addr,
> -    register_t rx_addr, uint32_t page_count)
> -{
> -    uint32_t ret =3D FFA_RET_INVALID_PARAMETERS;
> -    struct domain *d =3D current->domain;
> -    struct ffa_ctx *ctx =3D d->arch.tee;
> -    struct page_info *tx_pg;
> -    struct page_info *rx_pg;
> -    p2m_type_t t;
> -    void *rx;
> -    void *tx;
> -
> -    if ( !smccc_is_conv_64(fid) )
> -    {
> -        /*
> -         * Calls using the 32-bit calling convention must ignore the upp=
er
> -         * 32 bits in the argument registers.
> -         */
> -        tx_addr &=3D UINT32_MAX;
> -        rx_addr &=3D UINT32_MAX;
> -    }
> -
> -    if ( page_count > FFA_MAX_RXTX_PAGE_COUNT )
> -    {
> -        printk(XENLOG_ERR "ffa: RXTX_MAP: error: %u pages requested (lim=
it %u)\n",
> -               page_count, FFA_MAX_RXTX_PAGE_COUNT);
> -        return FFA_RET_INVALID_PARAMETERS;
> -    }
> -
> -    /* Already mapped */
> -    if ( ctx->rx )
> -        return FFA_RET_DENIED;
> -
> -    tx_pg =3D get_page_from_gfn(d, gfn_x(gaddr_to_gfn(tx_addr)), &t, P2M=
_ALLOC);
> -    if ( !tx_pg )
> -        return FFA_RET_INVALID_PARAMETERS;
> -
> -    /* Only normal RW RAM for now */
> -    if ( t !=3D p2m_ram_rw )
> -        goto err_put_tx_pg;
> -
> -    rx_pg =3D get_page_from_gfn(d, gfn_x(gaddr_to_gfn(rx_addr)), &t, P2M=
_ALLOC);
> -    if ( !tx_pg )
> -        goto err_put_tx_pg;
> -
> -    /* Only normal RW RAM for now */
> -    if ( t !=3D p2m_ram_rw )
> -        goto err_put_rx_pg;
> -
> -    tx =3D __map_domain_page_global(tx_pg);
> -    if ( !tx )
> -        goto err_put_rx_pg;
> -
> -    rx =3D __map_domain_page_global(rx_pg);
> -    if ( !rx )
> -        goto err_unmap_tx;
> -
> -    ctx->rx =3D rx;
> -    ctx->tx =3D tx;
> -    ctx->rx_pg =3D rx_pg;
> -    ctx->tx_pg =3D tx_pg;
> -    ctx->page_count =3D page_count;
> -    ctx->rx_is_free =3D true;
> -    return FFA_RET_OK;
> -
> -err_unmap_tx:
> -    unmap_domain_page_global(tx);
> -err_put_rx_pg:
> -    put_page(rx_pg);
> -err_put_tx_pg:
> -    put_page(tx_pg);
> -
> -    return ret;
> -}
> -
> -static void rxtx_unmap(struct ffa_ctx *ctx)
> -{
> -    unmap_domain_page_global(ctx->rx);
> -    unmap_domain_page_global(ctx->tx);
> -    put_page(ctx->rx_pg);
> -    put_page(ctx->tx_pg);
> -    ctx->rx =3D NULL;
> -    ctx->tx =3D NULL;
> -    ctx->rx_pg =3D NULL;
> -    ctx->tx_pg =3D NULL;
> -    ctx->page_count =3D 0;
> -    ctx->rx_is_free =3D false;
> -}
> -
> -static uint32_t ffa_handle_rxtx_unmap(void)
> -{
> -    struct domain *d =3D current->domain;
> -    struct ffa_ctx *ctx =3D d->arch.tee;
> -
> -    if ( !ctx->rx )
> -        return FFA_RET_INVALID_PARAMETERS;
> -
> -    rxtx_unmap(ctx);
> -
> -    return FFA_RET_OK;
> -}
> -
> -static int32_t ffa_handle_rx_release(void)
> -{
> -    int32_t ret =3D FFA_RET_DENIED;
> -    struct domain *d =3D current->domain;
> -    struct ffa_ctx *ctx =3D d->arch.tee;
> -
> -    if ( !spin_trylock(&ctx->rx_lock) )
> -        return FFA_RET_BUSY;
> -
> -    if ( !ctx->page_count || ctx->rx_is_free )
> -        goto out;
> -    ret =3D FFA_RET_OK;
> -    ctx->rx_is_free =3D true;
> -out:
> -    spin_unlock(&ctx->rx_lock);
> -
> -    return ret;
> -}
> -
> static void handle_msg_send_direct_req(struct cpu_user_regs *regs, uint32=
_t fid)
> {
>     struct arm_smccc_1_2_regs arg =3D { .a0 =3D fid, };
> @@ -522,8 +375,7 @@ static int ffa_domain_teardown(struct domain *d)
>     if ( !ctx )
>         return 0;
>=20
> -    if ( ctx->rx )
> -        rxtx_unmap(ctx);
> +    ffa_rxtx_domain_destroy(d);
>=20
>     ffa_domain_teardown_continue(ctx, true /* first_time */);
>=20
> @@ -538,7 +390,6 @@ static int ffa_relinquish_resources(struct domain *d)
> static bool ffa_probe(void)
> {
>     uint32_t vers;
> -    int e;
>     unsigned int major_vers;
>     unsigned int minor_vers;
>=20
> @@ -596,36 +447,21 @@ static bool ffa_probe(void)
>          !check_mandatory_feature(FFA_MSG_SEND_DIRECT_REQ_32) )
>         return false;
>=20
> -    ffa_rx =3D alloc_xenheap_pages(get_order_from_pages(FFA_RXTX_PAGE_CO=
UNT), 0);
> -    if ( !ffa_rx )
> +    if ( !ffa_rxtx_init() )
>         return false;
>=20
> -    ffa_tx =3D alloc_xenheap_pages(get_order_from_pages(FFA_RXTX_PAGE_CO=
UNT), 0);
> -    if ( !ffa_tx )
> -        goto err_free_ffa_rx;
> -
> -    e =3D ffa_rxtx_map(__pa(ffa_tx), __pa(ffa_rx), FFA_RXTX_PAGE_COUNT);
> -    if ( e )
> -    {
> -        printk(XENLOG_ERR "ffa: Failed to map rxtx: error %d\n", e);
> -        goto err_free_ffa_tx;
> -    }
>     ffa_version =3D vers;
>=20
>     if ( !ffa_partinfo_init() )
> -        goto err_free_ffa_tx;
> +        goto err_rxtx_destroy;
>=20
>     INIT_LIST_HEAD(&ffa_teardown_head);
>     init_timer(&ffa_teardown_timer, ffa_teardown_timer_callback, NULL, 0)=
;
>=20
>     return true;
>=20
> -err_free_ffa_tx:
> -    free_xenheap_pages(ffa_tx, 0);
> -    ffa_tx =3D NULL;
> -err_free_ffa_rx:
> -    free_xenheap_pages(ffa_rx, 0);
> -    ffa_rx =3D NULL;
> +err_rxtx_destroy:
> +    ffa_rxtx_destroy();
>     ffa_version =3D 0;
>=20
>     return false;
> diff --git a/xen/arch/arm/tee/ffa_private.h b/xen/arch/arm/tee/ffa_privat=
e.h
> index 6b32b69cfe90..98236cbf14a3 100644
> --- a/xen/arch/arm/tee/ffa_private.h
> +++ b/xen/arch/arm/tee/ffa_private.h
> @@ -263,6 +263,13 @@ int32_t ffa_handle_partition_info_get(uint32_t w1, u=
int32_t w2, uint32_t w3,
>                                       uint32_t w4, uint32_t w5, uint32_t =
*count,
>                                       uint32_t *fpi_size);
>=20
> +bool ffa_rxtx_init(void);
> +void ffa_rxtx_destroy(void);
> +void ffa_rxtx_domain_destroy(struct domain *d);
> +uint32_t ffa_handle_rxtx_map(uint32_t fid, register_t tx_addr,
> +     register_t rx_addr, uint32_t page_count);
> +uint32_t ffa_handle_rxtx_unmap(void);
> +int32_t ffa_handle_rx_release(void);
>=20
> static inline uint16_t ffa_get_vm_id(const struct domain *d)
> {
> diff --git a/xen/arch/arm/tee/ffa_rxtx.c b/xen/arch/arm/tee/ffa_rxtx.c
> new file mode 100644
> index 000000000000..661764052e67
> --- /dev/null
> +++ b/xen/arch/arm/tee/ffa_rxtx.c
> @@ -0,0 +1,216 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Copyright (C) 2024  Linaro Limited
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +#include "ffa_private.h"
> +
> +/* Endpoint RX/TX descriptor defined in FF-A-1.0-REL */
> +struct ffa_endpoint_rxtx_descriptor_1_0 {
> +    uint16_t sender_id;
> +    uint16_t reserved;
> +    uint32_t rx_range_count;
> +    uint32_t tx_range_count;
> +};
> +
> +/* Endpoint RX/TX descriptor defined in FF-A-1.1-REL0 */
> +struct ffa_endpoint_rxtx_descriptor_1_1 {
> +    uint16_t sender_id;
> +    uint16_t reserved;
> +    uint32_t rx_region_offs;
> +    uint32_t tx_region_offs;
> +};
> +
> +uint32_t ffa_handle_rxtx_map(uint32_t fid, register_t tx_addr,
> +     register_t rx_addr, uint32_t page_count)
> +{
> +    uint32_t ret =3D FFA_RET_INVALID_PARAMETERS;
> +    struct domain *d =3D current->domain;
> +    struct ffa_ctx *ctx =3D d->arch.tee;
> +    struct page_info *tx_pg;
> +    struct page_info *rx_pg;
> +    p2m_type_t t;
> +    void *rx;
> +    void *tx;
> +
> +    if ( !smccc_is_conv_64(fid) )
> +    {
> +        /*
> +         * Calls using the 32-bit calling convention must ignore the upp=
er
> +         * 32 bits in the argument registers.
> +         */
> +        tx_addr &=3D UINT32_MAX;
> +        rx_addr &=3D UINT32_MAX;
> +    }
> +
> +    if ( page_count > FFA_MAX_RXTX_PAGE_COUNT )
> +    {
> +        printk(XENLOG_ERR "ffa: RXTX_MAP: error: %u pages requested (lim=
it %u)\n",
> +               page_count, FFA_MAX_RXTX_PAGE_COUNT);
> +        return FFA_RET_INVALID_PARAMETERS;
> +    }
> +
> +    /* Already mapped */
> +    if ( ctx->rx )
> +        return FFA_RET_DENIED;
> +
> +    tx_pg =3D get_page_from_gfn(d, gfn_x(gaddr_to_gfn(tx_addr)), &t, P2M=
_ALLOC);
> +    if ( !tx_pg )
> +        return FFA_RET_INVALID_PARAMETERS;
> +
> +    /* Only normal RW RAM for now */
> +    if ( t !=3D p2m_ram_rw )
> +        goto err_put_tx_pg;
> +
> +    rx_pg =3D get_page_from_gfn(d, gfn_x(gaddr_to_gfn(rx_addr)), &t, P2M=
_ALLOC);
> +    if ( !tx_pg )
> +        goto err_put_tx_pg;
> +
> +    /* Only normal RW RAM for now */
> +    if ( t !=3D p2m_ram_rw )
> +        goto err_put_rx_pg;
> +
> +    tx =3D __map_domain_page_global(tx_pg);
> +    if ( !tx )
> +        goto err_put_rx_pg;
> +
> +    rx =3D __map_domain_page_global(rx_pg);
> +    if ( !rx )
> +        goto err_unmap_tx;
> +
> +    ctx->rx =3D rx;
> +    ctx->tx =3D tx;
> +    ctx->rx_pg =3D rx_pg;
> +    ctx->tx_pg =3D tx_pg;
> +    ctx->page_count =3D page_count;
> +    ctx->rx_is_free =3D true;
> +    return FFA_RET_OK;
> +
> +err_unmap_tx:
> +    unmap_domain_page_global(tx);
> +err_put_rx_pg:
> +    put_page(rx_pg);
> +err_put_tx_pg:
> +    put_page(tx_pg);
> +
> +    return ret;
> +}
> +
> +static void rxtx_unmap(struct ffa_ctx *ctx)
> +{
> +    unmap_domain_page_global(ctx->rx);
> +    unmap_domain_page_global(ctx->tx);
> +    put_page(ctx->rx_pg);
> +    put_page(ctx->tx_pg);
> +    ctx->rx =3D NULL;
> +    ctx->tx =3D NULL;
> +    ctx->rx_pg =3D NULL;
> +    ctx->tx_pg =3D NULL;
> +    ctx->page_count =3D 0;
> +    ctx->rx_is_free =3D false;
> +}
> +
> +uint32_t ffa_handle_rxtx_unmap(void)
> +{
> +    struct domain *d =3D current->domain;
> +    struct ffa_ctx *ctx =3D d->arch.tee;
> +
> +    if ( !ctx->rx )
> +        return FFA_RET_INVALID_PARAMETERS;
> +
> +    rxtx_unmap(ctx);
> +
> +    return FFA_RET_OK;
> +}
> +
> +int32_t ffa_handle_rx_release(void)
> +{
> +    int32_t ret =3D FFA_RET_DENIED;
> +    struct domain *d =3D current->domain;
> +    struct ffa_ctx *ctx =3D d->arch.tee;
> +
> +    if ( !spin_trylock(&ctx->rx_lock) )
> +        return FFA_RET_BUSY;
> +
> +    if ( !ctx->page_count || ctx->rx_is_free )
> +        goto out;
> +    ret =3D FFA_RET_OK;
> +    ctx->rx_is_free =3D true;
> +out:
> +    spin_unlock(&ctx->rx_lock);
> +
> +    return ret;
> +}
> +
> +static int32_t ffa_rxtx_map(paddr_t tx_addr, paddr_t rx_addr,
> +                            uint32_t page_count)
> +{
> +    return ffa_simple_call(FFA_RXTX_MAP_64, tx_addr, rx_addr, page_count=
, 0);
> +}
> +
> +static int32_t ffa_rxtx_unmap(void)
> +{
> +    return ffa_simple_call(FFA_RXTX_UNMAP, 0, 0, 0, 0);
> +}
> +
> +void ffa_rxtx_domain_destroy(struct domain *d)
> +{
> +    struct ffa_ctx *ctx =3D d->arch.tee;
> +
> +    if ( ctx->rx )
> +        rxtx_unmap(ctx);
> +}
> +
> +void ffa_rxtx_destroy(void)
> +{
> +    bool need_unmap =3D ffa_tx && ffa_rx;
> +
> +    if ( ffa_tx )
> +    {
> +        free_xenheap_pages(ffa_tx, 0);
> +        ffa_tx =3D NULL;
> +    }
> +    if ( ffa_rx )
> +    {
> +        free_xenheap_pages(ffa_rx, 0);
> +        ffa_rx =3D NULL;
> +    }
> +
> +    if ( need_unmap )
> +        ffa_rxtx_unmap();
> +}
> +
> +bool ffa_rxtx_init(void)
> +{
> +    int e;
> +
> +    ffa_rx =3D alloc_xenheap_pages(get_order_from_pages(FFA_RXTX_PAGE_CO=
UNT), 0);
> +    if ( !ffa_rx )
> +        return false;
> +
> +    ffa_tx =3D alloc_xenheap_pages(get_order_from_pages(FFA_RXTX_PAGE_CO=
UNT), 0);
> +    if ( !ffa_tx )
> +        goto err;
> +
> +    e =3D ffa_rxtx_map(__pa(ffa_tx), __pa(ffa_rx), FFA_RXTX_PAGE_COUNT);
> +    if ( e )
> +    {
> +        printk(XENLOG_ERR "ffa: Failed to map rxtx: error %d\n", e);
> +        goto err;
> +    }
> +    return true;
> +
> +err:
> +    ffa_rxtx_destroy();
> +
> +    return false;
> +}
> --=20
> 2.34.1
>=20



From xen-devel-bounces@lists.xenproject.org Wed Mar 27 13:46:13 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 13:46:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698547.1090348 (Exim 4.92)
	(envelope-from )
	id 1rpTbV-0005LO-CX; Wed, 27 Mar 2024 13:46:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698547.1090348; Wed, 27 Mar 2024 13:46:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpTbV-0005LH-8o; Wed, 27 Mar 2024 13:46:09 +0000
Received: by outflank-mailman (input) for mailman id 698547;
 Wed, 27 Mar 2024 13:46:08 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpTbU-0005LB-7K
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 13:46:08 +0000
Received: from EUR01-DB5-obe.outbound.protection.outlook.com
 (mail-db5eur01on0617.outbound.protection.outlook.com
 [2a01:111:f400:fe02::617])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5bf875ba-ec40-11ee-a1ef-f123f15fe8a2;
 Wed, 27 Mar 2024 14:46:06 +0100 (CET)
Received: from DU6P191CA0066.EURP191.PROD.OUTLOOK.COM (2603:10a6:10:53e::6) by
 DU0PR08MB9485.eurprd08.prod.outlook.com (2603:10a6:10:42e::20) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.7409.32; Wed, 27 Mar 2024 13:46:04 +0000
Received: from DB5PEPF00014B94.eurprd02.prod.outlook.com
 (2603:10a6:10:53e:cafe::db) by DU6P191CA0066.outlook.office365.com
 (2603:10a6:10:53e::6) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.13 via Frontend
 Transport; Wed, 27 Mar 2024 13:46:04 +0000
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by
 DB5PEPF00014B94.mail.protection.outlook.com (10.167.8.232) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.7409.10 via Frontend Transport; Wed, 27 Mar 2024 13:46:03 +0000
Received: ("Tessian outbound f0b355493f75:v300");
 Wed, 27 Mar 2024 13:46:03 +0000
Received: from 45719d047111.1
 by 64aa7808-outbound-1.mta.getcheckrecipient.com id
 E33D301F-E727-4F18-AD9A-9D2DF55F58C3.1; 
 Wed, 27 Mar 2024 13:45:57 +0000
Received: from EUR05-AM6-obe.outbound.protection.outlook.com
 by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 45719d047111.1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384);
 Wed, 27 Mar 2024 13:45:57 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com (2603:10a6:10:25a::24)
 by PAXPR08MB7552.eurprd08.prod.outlook.com (2603:10a6:102:24f::7)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.32; Wed, 27 Mar
 2024 13:45:55 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::7fb0:6621:56b:22d5]) by DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::7fb0:6621:56b:22d5%3]) with mapi id 15.20.7409.031; Wed, 27 Mar 2024
 13:45:55 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5bf875ba-ec40-11ee-a1ef-f123f15fe8a2
ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass;
 b=ifTCWZSTTBPd8sJAKpCzY8aMXYTX9MIW8o+OnYf6yRnrtI3YFausOmcgC0Tb5SrqN4P6xZxfasoK9VQvQ1DNRNrX+tuMAOhgfEidN+B7RG1Qa83O9BKNjE5UOnhyGNV5nEbiw2o78MCpHylhdAU9YqZRxzuTMGEzTdUKz0xvcraNQqI2oJas4nTVCsWJ1dPdK70qBp4DJdbRLCVHmxet+x0THZJCvw81VQ4iSJ32eRijz3AKHU5Z7fF0A3v4B/NRcYUTACJZqBHwGUEvApCdLBgEYLShmFxZBJa4/Y0uu6h8mT3ZpNDpfP15qLgp0btL+6oNlyhiixtdaUpFW3aiTw==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=NDG0K3cgENatIapr0eAsKQubWrXFg9yWBgRx6h7r57Q=;
 b=iSbXB/FB2Vzn2iwIEq5M5uIfDNMGR0q7rvHI337Kc39Ol+j3Qx0Q2LIa2FT51pOHFd8CnIKo2ayt+KDcrLUHXkGaaAQh9mV42LXQIkeVYh1eUnkh/msk3YpAd5LU4oDDgB9/1ESnbA6J3VUZKD50h5nxmMP3lVj/Q8hGbqFAI4QqgfxjoZ6NqQ/GedfbuvixtyyOvd+R8I2TNlSFzZVbkV+0qbcvt7DuSbPAubmclWSHEAS0PQQHiBGshAHU7JBZaUjboS7GmPZu9EZKlYycyQfxy715MIfiWw0PdNcKp7TkkuLoa8eHSGYk/LrhVW4w+Jc9HZMSlZ6nVfvgJg4seA==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 63.35.35.123) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=arm.com;
 dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com;
 dkim=pass (signature was verified) header.d=armh.onmicrosoft.com; arc=pass (0
 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com]
 dmarc=[1,1,header.from=arm.com])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com;
 s=selector2-armh-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=NDG0K3cgENatIapr0eAsKQubWrXFg9yWBgRx6h7r57Q=;
 b=gwDvUMb+TGR/+WE7yUfFxlaS+G8/1d4xk7vszQyGuu0EPpDfUOo1GmRFp1UDY3zCbaNI/gdJ6KsXXVY/lKxvn1z8ZK3ev7qg0dwhDa/LzHw37VL3wl/0IlpxVt+eFNcyth7uuZkA3PdKAckBv+064+rg3hXYEnX5XYSBoksU7u4=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=armh.onmicrosoft.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 63.35.35.123 as permitted sender) receiver=protection.outlook.com;
 client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
 pr=C
X-CheckRecipientChecked: true
X-CR-MTA-CID: 3b47475a917688b5
X-CR-MTA-TID: 64aa7808
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=C4RKJV3fqFh3nIU4NMcdxU0N1Jmwr4lDxNV2zN3r3tSl21VYpOuHA+J3YzC7J5c5MyYXLU5qHz3rPePKLQjTvElfhmM4MLLGMWAlFWFIcwu9hTOCyMc0JuM4YYQpP+U0wDch6Cz0GEnJhhWi68huTLIuFyG4FvQ5skuNgW69HkjL2epOaOv7wH0A6EMqYt2T0eGQH1Bz1IRpsGpyzW0eU7AS82r6pOtBecMLpoA7lXy/peI4JSLnemSQUNxoVJcawitgEO2+JTP7f5OQzMDFySGyqsE07XRzFPnZMG4APOji3LRHIhQA2CCeKZ+69DcPW5ndnF9O2rQZdY4BYyisPw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=NDG0K3cgENatIapr0eAsKQubWrXFg9yWBgRx6h7r57Q=;
 b=m6rYYnoO11DjR/qEPrx3/VTqHFKlobq/HVpLjiz2VAEgy6Ho8aFbuF4RQQD587ZCVmg2VBNPmRpSzwxMmXLWFd2JiV8Sh8OHfKKw8rNSlZP3TuO8M4T08g/Up9tg74HXjaSCy75DycWoF0BJeDqTN+IUUBjMq1OqWw3jlY73vXVmcUwd8EbDtRyqM10Y2q/bW6YTfkXvh6JyOPfIbE7uK+QTfsm0hto3qWBmDUXa248TTPJsiL29f3w9vYzWvujxfbMpwe5Kje7dlwRh22uaeWwFU77AuR0VgvVWpzXbMmml9qSDLg16d4d7LH5MWXtMsvJFPfTbq+oO85jcdjjGUQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass
 header.d=arm.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com;
 s=selector2-armh-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=NDG0K3cgENatIapr0eAsKQubWrXFg9yWBgRx6h7r57Q=;
 b=gwDvUMb+TGR/+WE7yUfFxlaS+G8/1d4xk7vszQyGuu0EPpDfUOo1GmRFp1UDY3zCbaNI/gdJ6KsXXVY/lKxvn1z8ZK3ev7qg0dwhDa/LzHw37VL3wl/0IlpxVt+eFNcyth7uuZkA3PdKAckBv+064+rg3hXYEnX5XYSBoksU7u4=
From: Bertrand Marquis 
To: Jens Wiklander 
CC: Xen-devel , "patches@linaro.org"
	, Volodymyr Babchuk , Stefano
 Stabellini , Julien Grall , Michal
 Orzel 
Subject: Re: [XEN PATCH 6/6] xen/arm: ffa: support FFA_FEATURES
Thread-Topic: [XEN PATCH 6/6] xen/arm: ffa: support FFA_FEATURES
Thread-Index: AQHafphUyax1RiAti0Sh0JOrQKKl8bFLnPGA
Date: Wed, 27 Mar 2024 13:45:55 +0000
Message-ID: <47DB3F44-79F5-4245-BC02-A33A5D3E229E@arm.com>
References: <20240325093904.3466092-1-jens.wiklander@linaro.org>
 <20240325093904.3466092-7-jens.wiklander@linaro.org>
In-Reply-To: <20240325093904.3466092-7-jens.wiklander@linaro.org>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3774.200.91.1.1)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DB9PR08MB6588:EE_|PAXPR08MB7552:EE_|DB5PEPF00014B94:EE_|DU0PR08MB9485:EE_
X-MS-Office365-Filtering-Correlation-Id: fe31d09e-10b8-49b5-6658-08dc4e643ede
x-checkrecipientrouted: true
nodisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted: BCL:0;
X-Microsoft-Antispam-Message-Info-Original:
 fBaHSBy6bzJBtZO/382hk3h3N2MPeNg7FKgqSIGN9LEtlXKT/EJdnTmq1rlc8NdfEOCAZxE4NI+Fj3LohNGRcPs1VcbW/NiqrZ7JOA5TFi2bmoYdRzXl2yNC3On7jtq6cB4j6flQOdXpzijYVDon47x4v2ALRQnBqOvyp+ZCbAd7BTsvNgT75okOcMFnWA0yOjQOHA6FUKbD1GXc6YaaEWzTe4M/oFDx2aHktVuk3vr7FglY1Lus81WcLAHddxeJIBBjgA3Yov5v1ykso1qMSCb3Y4Dxt4gY8gyb2CylaEjicZ+GsSoT42Iz0tzd6VMNotg+O7NldhbK5I6YX6/+SOwVwatxdGQLr5vzq1M5bn9dbZUQUSP8TWxtTZCMa3hJybPsQkaOYNny/VMM6JiQRebDtcGhBzyaa1N+2Ro03QYrQKW8nzBS031OMvPkWDu1Hqcf1as9MyfAhyA6etRFMCFKUFSzkGSkp9SmR2PuaAPBOUvmlHGkmheF5VRMF8u9SK9tmsyIalUn0D+miGVh7m/verS64TC855c+dsXxwzQpx/ZM9NUqHLrdE2UWtFN3paBHv0Wh/ki+s+1+par4hIktoV5HRvNBtfVf3PF6kIjJfX2oKWKOeu/Qe/xWHRfWjq3voyiGqbpP0PiX+5nOwfcd9XvPCP/dkg2dpxhVeSNAFsVXJ62/gAOfYKGWktw70xQTiNewDWKhC+ZkRu/Z7g==
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB9PR08MB6588.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(366007)(376005)(1800799015)(38070700009);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="us-ascii"
Content-ID: <5247E8DB33D2134DAFBFC601F60004D5@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAXPR08MB7552
Original-Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 DB5PEPF00014B94.eurprd02.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	f7213424-70a4-4a3f-b2de-08dc4e6439da
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	cgAUxIcsPqsHvFsV6Rh33VPXAQVp7zA5skNDotHWnL8WScx/4ZjXbnW/iwT4ilvfgd5PJo9sdVK/5/ad5iSCgT5fMzur/QOgewE2AlD9TVvcVzbinAeyTzWXMDvX0aKTVwFb64WlNRP/AMTCLZYPaT8B3KbVWswxMkt2syZyS+71ycIO2y06bEgA5YtHJ0rVK2orMB/hF8eyby4WoWJGZ1olVqfINK+4OX8Owu7BZ+WYnF91RlAay3styca2E9YANI8Nj1zrM5Jjd0rbn2vD0XdNnyr4vpHY7DAcmOSOnVIWsY6LBqP+zo5wNbYB9NsYN7lSrDpoqISTDmSy76ROW98zVgh0xtB/8RO19NXLd2xYAtiGYudiHnSkdJfdFPaAtuWbgR6IuQoBDBMMvFwblfA+jaeRraeYhCPCZCk/aGOZ2p7g8S1aRW6X5UiRmcvqItnA5gKlrbEXebsLy5vsNIv5YvVWYUyywMzd8eGnQknrAMxVKUgC3i2G8RQZJ/L7B7VQaZGi/iJJwOe8FatuzfLCoKtf8h7HeuBGbrYZRYW1zZX6+l62GW8tU4iRtwziBcs1KOqEvxZz6XL72KfEFMEZbpjA2fy6LI9kfrKfZ3ak2sx5+Peiwqyy+UQHv08VMR1tnTcDY2JawxrBCIcdFavaX6e9MxLnMRVTzhFf6N9AC4d/m9hsafTB3P5Z2LbDRcf5bRL8zXFlikILjwidP1sV1l0LmK/G4tt7UEboeFaLFMPieALsmzrqaFKh1H+b
X-Forefront-Antispam-Report:
	CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com;CAT:NONE;SFS:(13230031)(36860700004)(82310400014)(1800799015)(376005);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Mar 2024 13:46:03.8070
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: fe31d09e-10b8-49b5-6658-08dc4e643ede
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DB5PEPF00014B94.eurprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR08MB9485

Hi Jens,

> On 25 Mar 2024, at 10:39, Jens Wiklander  wrot=
e:
>=20
> Add support for the mandatory FF-A ABI function FFA_FEATURES.
>=20
> Signed-off-by: Jens Wiklander 

Reviewed-by: Bertrand Marquis 

Cheers
Bertrand

> ---
> xen/arch/arm/tee/ffa.c | 57 ++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 57 insertions(+)
>=20
> diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
> index 4f7775b8c890..8665201e34a9 100644
> --- a/xen/arch/arm/tee/ffa.c
> +++ b/xen/arch/arm/tee/ffa.c
> @@ -192,6 +192,60 @@ out:
>                  resp.a7 & mask);
> }
>=20
> +static void handle_features(struct cpu_user_regs *regs)
> +{
> +    uint32_t a1 =3D get_user_reg(regs, 1);
> +    unsigned int n;
> +
> +    for ( n =3D 2; n <=3D 7; n++ )
> +    {
> +        if ( get_user_reg(regs, n) )
> +        {
> +            ffa_set_regs_error(regs, FFA_RET_NOT_SUPPORTED);
> +            return;
> +        }
> +    }
> +
> +    switch ( a1 )
> +    {
> +    case FFA_ERROR:
> +    case FFA_VERSION:
> +    case FFA_SUCCESS_32:
> +    case FFA_SUCCESS_64:
> +    case FFA_FEATURES:
> +    case FFA_ID_GET:
> +    case FFA_RX_RELEASE:
> +    case FFA_RXTX_UNMAP:
> +    case FFA_MEM_RECLAIM:
> +    case FFA_PARTITION_INFO_GET:
> +    case FFA_MSG_SEND_DIRECT_REQ_32:
> +    case FFA_MSG_SEND_DIRECT_REQ_64:
> +        ffa_set_regs_success(regs, 0, 0);
> +        break;
> +    case FFA_MEM_SHARE_64:
> +    case FFA_MEM_SHARE_32:
> +        /*
> +         * We currently don't support dynamically allocated buffers. Rep=
ort
> +         * that with 0 in bit[0] of w2.
> +         */
> +        ffa_set_regs_success(regs, 0, 0);
> +        break;
> +    case FFA_RXTX_MAP_64:
> +    case FFA_RXTX_MAP_32:
> +        /*
> +         * We currently support 4k pages only, report that as 00 in
> +         * bit[0:1] in w0. This needs to be revised if Xen page size
> +         * differs from FFA_PAGE_SIZE (SZ_4K).
> +         */
> +        BUILD_BUG_ON(PAGE_SIZE !=3D FFA_PAGE_SIZE);
> +        ffa_set_regs_success(regs, 0, 0);
> +        break;
> +    default:
> +        ffa_set_regs_error(regs, FFA_RET_NOT_SUPPORTED);
> +        break;
> +    }
> +}
> +
> static bool ffa_handle_call(struct cpu_user_regs *regs)
> {
>     uint32_t fid =3D get_user_reg(regs, 0);
> @@ -212,6 +266,9 @@ static bool ffa_handle_call(struct cpu_user_regs *reg=
s)
>     case FFA_ID_GET:
>         ffa_set_regs_success(regs, ffa_get_vm_id(d), 0);
>         return true;
> +    case FFA_FEATURES:
> +        handle_features(regs);
> +        return true;
>     case FFA_RXTX_MAP_32:
>     case FFA_RXTX_MAP_64:
>         e =3D ffa_handle_rxtx_map(fid, get_user_reg(regs, 1),
> --=20
> 2.34.1
>=20



From xen-devel-bounces@lists.xenproject.org Wed Mar 27 13:47:41 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 13:47:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698554.1090357 (Exim 4.92)
	(envelope-from )
	id 1rpTcy-0005wm-P8; Wed, 27 Mar 2024 13:47:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698554.1090357; Wed, 27 Mar 2024 13:47:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpTcy-0005wf-Mb; Wed, 27 Mar 2024 13:47:40 +0000
Received: by outflank-mailman (input) for mailman id 698554;
 Wed, 27 Mar 2024 13:47:40 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpTcy-0005wS-9s
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 13:47:40 +0000
Received: from EUR03-AM7-obe.outbound.protection.outlook.com
 (mail-am7eur03on20600.outbound.protection.outlook.com
 [2a01:111:f403:260e::600])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9394afed-ec40-11ee-afe3-a90da7624cb6;
 Wed, 27 Mar 2024 14:47:39 +0100 (CET)
Received: from DU7P195CA0001.EURP195.PROD.OUTLOOK.COM (2603:10a6:10:54d::15)
 by GVXPR08MB7725.eurprd08.prod.outlook.com (2603:10a6:150:6d::15) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.32; Wed, 27 Mar
 2024 13:47:36 +0000
Received: from DU2PEPF00028D13.eurprd03.prod.outlook.com
 (2603:10a6:10:54d:cafe::34) by DU7P195CA0001.outlook.office365.com
 (2603:10a6:10:54d::15) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.27 via Frontend
 Transport; Wed, 27 Mar 2024 13:47:36 +0000
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by
 DU2PEPF00028D13.mail.protection.outlook.com (10.167.242.27) with
 Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.7409.10
 via Frontend Transport; Wed, 27 Mar 2024 13:47:36 +0000
Received: ("Tessian outbound 9b7417e2a8eb:v300");
 Wed, 27 Mar 2024 13:47:36 +0000
Received: from 86abe90d67b8.1
 by 64aa7808-outbound-1.mta.getcheckrecipient.com id
 B79EC32E-A84C-4C7D-87F3-7864D0B6C620.1; 
 Wed, 27 Mar 2024 13:47:29 +0000
Received: from EUR05-VI1-obe.outbound.protection.outlook.com
 by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 86abe90d67b8.1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384);
 Wed, 27 Mar 2024 13:47:29 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com (2603:10a6:10:25a::24)
 by VE1PR08MB5774.eurprd08.prod.outlook.com (2603:10a6:800:1a1::24)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.32; Wed, 27 Mar
 2024 13:47:25 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::7fb0:6621:56b:22d5]) by DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::7fb0:6621:56b:22d5%3]) with mapi id 15.20.7409.031; Wed, 27 Mar 2024
 13:47:25 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9394afed-ec40-11ee-afe3-a90da7624cb6
ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass;
 b=hgesG67AhA9nvYlCPDpjK3ctN6DXWj9iG8gBrZWZRoeNOdIYpkJGshUCsd8keMCeDbpKjSBbIpFqE4JNDpWgb+JfuK3JMbt3b3Ul+aSld9xWfqU+OsOIzdlXehz0svBeEB+yJtk8yBcs9Y69jDckWpGi0lFofcCPI0XwzuNH33sD2JYqRCljAzydS4SkODnqMgGOcRmXTs+9pzzt00B0T4ne0mcc/AdD98GHs6GeSqL/MkoMtrWxDX/hf2v71uYIlApPvl+IVrvn7AeJ9XgMfjp6OqAo5Nc+NW7kn9y9b5B7EXobDBgb3xcaC+MSZ8V+tg5z/YJuElJRr804koSjWQ==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=7sPyD76On2wtK5kXO/a8p9uUFw1C7V4kWUdpd8oNMNg=;
 b=gSuPw6uwwC9pkRWtm7UQiOCOlUCKBhSHZpsX9EgV3I26jCQnmE7/i14ilCgps4LnQB5J8ByXYWNZ3p6MneS/xXcXZph6ynIFJ4UZXOiX0zZoEy1PBXQjNmEYsp04GBxXhlguiIqAneC8SuWIyvYUmDYTfL82VRnBMZR7OZR3sVcb3ohqEsSS8vhzyrbIpFMGhjDiXa0o1KWESDhswK7RaV5XECCCLsbWQhmiK8YEiz27sTBrAOg/PFvpSqTpdsD0Sjf4Vwo70oueEvkRMRv8LoQG83GWiGFZyXYdWG+6LitwgQlKaBPjC610h/S5jCuEaAUIeBHrjA7BfBb+eFOWYw==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 63.35.35.123) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=arm.com;
 dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com;
 dkim=pass (signature was verified) header.d=armh.onmicrosoft.com; arc=pass (0
 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com]
 dmarc=[1,1,header.from=arm.com])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com;
 s=selector2-armh-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=7sPyD76On2wtK5kXO/a8p9uUFw1C7V4kWUdpd8oNMNg=;
 b=EQ/DVmVBCMR3JqhQMNh1bdSuE/XayjpJ1gPuQS9Cfj4PaC15d68EnQCOKatcbddD9IRwghMwqKK99PVdZrzUVeaacTJjkhox3/iLcsLWhHsIGJy56ABpJkC9QTx6FCiPp+1TeuxNI/j0WklFlTWYEQt99xsynL7XrNzuMHJLr18=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=armh.onmicrosoft.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 63.35.35.123 as permitted sender) receiver=protection.outlook.com;
 client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
 pr=C
X-CheckRecipientChecked: true
X-CR-MTA-CID: 5e89dacf81b8690b
X-CR-MTA-TID: 64aa7808
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=mP8c7LOzo58n9Y00ce5O01OMitAW6rCCSqpy4NSlkxLwCTXjZmJ4H2KCyP71E2uorHCBQf227DGYJpeJcS2q1TxWZYbAEsvQ5d5kkStcKLhuNY6OiAq68gJHoM0hV//d7H/equLxV0p0u8bmonRcQmiS2doh8XemKet8OrJNXjwfY16QLx+HWonB1lGoT0TNSI7StLb2YyY2ONu1Nn66EmfjzE4rgcEUylFEiwuICslBAuldUYSaWDCxswFVeQo9x/O7V7xV2UeuixCGOpqIuTjeVoe2iTU9B/R7Pk7y6eLkQx14UEFJL53ztZJOU2oe1IL32MsTm9QVuzkuqBTEzw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=7sPyD76On2wtK5kXO/a8p9uUFw1C7V4kWUdpd8oNMNg=;
 b=kch9+ukFcho2+bBWHvWJ4AvwfLbUoWXz5X60eA1pW7FVJMJYd4UrVOUxA0i8A0n7xBB24uffWm1NJNApQbQy2znSGGPyymHUeppmFE6EsJVIx+6M8OXwgUcj1qw4l3AQsPJ32jPamZGqdqCNdcrkOQEXyYDvUm0FJpAlVt4RR5feebeZWbHl3W/xuVzhLlXFRh37O/9J+nB3jihB5oP9Pp2Eh+yVO5NKa+uaJFXXiLpymWSHfuSaWWkjZDIxOdLRyOfohHPscb63JZYR+gaIdYii5vRSJbdynLCAtND6mqJbmXneOOVgTFY5QytxlEvOwrL03hZ3YYWcGbpXd5rBVQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass
 header.d=arm.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com;
 s=selector2-armh-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=7sPyD76On2wtK5kXO/a8p9uUFw1C7V4kWUdpd8oNMNg=;
 b=EQ/DVmVBCMR3JqhQMNh1bdSuE/XayjpJ1gPuQS9Cfj4PaC15d68EnQCOKatcbddD9IRwghMwqKK99PVdZrzUVeaacTJjkhox3/iLcsLWhHsIGJy56ABpJkC9QTx6FCiPp+1TeuxNI/j0WklFlTWYEQt99xsynL7XrNzuMHJLr18=
From: Bertrand Marquis 
To: Jens Wiklander 
CC: Xen-devel , "patches@linaro.org"
	, Volodymyr Babchuk , Stefano
 Stabellini , Julien Grall , Michal
 Orzel 
Subject: Re: [XEN PATCH 0/6] FF-A mediator reorganisation
Thread-Topic: [XEN PATCH 0/6] FF-A mediator reorganisation
Thread-Index: AQHafphPIHx/pr9gEUyxMEdwwKqovbFLnV2A
Date: Wed, 27 Mar 2024 13:47:25 +0000
Message-ID: <5189F757-8DCD-4C73-9455-8D524F138BA3@arm.com>
References: <20240325093904.3466092-1-jens.wiklander@linaro.org>
In-Reply-To: <20240325093904.3466092-1-jens.wiklander@linaro.org>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3774.200.91.1.1)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DB9PR08MB6588:EE_|VE1PR08MB5774:EE_|DU2PEPF00028D13:EE_|GVXPR08MB7725:EE_
X-MS-Office365-Filtering-Correlation-Id: 94565103-d7fe-4e09-cc4f-08dc4e647610
x-checkrecipientrouted: true
nodisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted: BCL:0;
X-Microsoft-Antispam-Message-Info-Original:
 RbRUbAI5H5jfDOFcUX/L8M2iWJq/0n2CKT0V9/1xUKGJj8qDdBeWHaF4BIHUNFziFS1rQYTyplI7J/r+g1wUARRg7SUMBskSIPNBS9htVvmqGXO/n/0CYv5gfgZLxoc/BwsTzgAu59+MDn0pDI4cVHiFM7odlEdYQAahu7vN84Nv7Fb3/yzI+/RZx3smhPOS/4lSOrHvUOKtoNJ0rJujfDTBJfpGtqRba+b2oFFrgP9k5+U64rB7ZNddZ9gog/1uUvqdvsTzFSrVT7FB+z83dkPfX+YcdRnmde8VrKynJKXe/mREtBnpSNaTd9sVowvj5ApNainf2oq4pJiZfUtOJvSvj78l10GUWybZatBVEn9U4Rszvt5BDt19gwrGL88LtVD7zuIo8rmlgNxfkXCyCdQqkcXOROHNNMUddo9kSThcikA8+aYnoKpqCGK2FWDVZE9gMkE4mRRlEBaNSjLKf0u0/VIoruscs8Xg77GXq3n0GjP2goBf2M74o8l1bgfsuZqIcgvxhF9E2c6inQBeO0ha3ly8UmMwiLX/ilz/+kHTMLCxZaQl/SdZWzZpcatE52rq85yf94Cr7e23D7Nt7SMbo5UvOSJq/RoZvPGPnPMc9F0hbUxiztUwNKb33hujrItHF2mPgaFXrt9dwSfNaNjgU59LdfuTmGlLJD0a4yULcTA6z6NgT7FWJGKknP1cYRTC6upe39EQCmNZP82fQ6AIb1J2AbHIBypgZR1ZCfc=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB9PR08MB6588.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(366007)(1800799015)(376005)(38070700009);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR08MB5774
Original-Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 DU2PEPF00028D13.eurprd03.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	49e54868-4b14-43df-dfa4-08dc4e646fc0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	MFVZ3+xJcgHchoO8ZJ++eF2mr26d9CbbEf8Obq9AeEtnwPEU1WbTF5XlfBzGInHh+4f8/oxTqaTQMYQlu8vmEraxKKZUsJyfDok40tw6uccgjjCuGY4IEHbCasnD/ZvxKrzdyvfKKXE7immZRk2s7S+t+S5LaprXFcRa87o2xbpLGVe+RIBqeax1bqEt0TZj/eIz1SdIMBXdMw1F2EghG932s1LBC8PY9e8bMBHlAKXnzmeQVTj833eyptLtGcl7pnMOvOrvU93QIIG7SCnWAClyJYj42QEuUwu1VVgxMHt9Bi9kv1aO83F3mNjLcDzQBGnDEMzctG+YbIKR1NuDBZzxGnF/5pZp60o1iPs/RAOZ7SsxzbZOIsUyJqS8GSWOMcFfpv2P1y0ej4QWF0O6KrVvyJ07pHdFIQ5MlqLys2WtEK6pnn0hgC/Q+tEDFITzxTFcfvMdIgVOgpBTzFdvn8NvrwMrf/3b3oq1yyuhZMxesL4IdlXt+QWRhKj3u1ptOsPW/W0Q8HH7BKN4n05BWsoomLus43KFAU8AS2iN4QzwFg0I0PRMa5hkHi6s6/iSECpmUzGOm7N6Zh69EOLgcEnqbdqytPUd73j1Ap8tgW2pMizWoH0KvO0jEJDEngcZSdhtSwl465AUHuaPCXQZnKWIzI+8VYaKEeGGt4TmtrfAXjlwpYmuYheWz10KCf4i8Zw6tWf1TOc7dFCfRR/oFlQckiiIsvXXLhGQJZ4yJuZTRQCV6WIPSSHN/aSQIxbL
X-Forefront-Antispam-Report:
	CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com;CAT:NONE;SFS:(13230031)(36860700004)(376005)(82310400014)(1800799015);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Mar 2024 13:47:36.4276
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 94565103-d7fe-4e09-cc4f-08dc4e647610
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DU2PEPF00028D13.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GVXPR08MB7725

Hi Jens,

> On 25 Mar 2024, at 10:38, Jens Wiklander  wrot=
e:
>=20
> Hi,
>=20
> The FF-A mediator is reorganized into modules for easier maintenance and =
to
> prepare for future changes. This patch set is not expected add any change=
d
> behaviour, except for the "xen/arm: ffa: support FFA_FEATURES" patch.

I reviewed the serie and there is only one tiny fix of copyright date that
can be done on commit.

Appart from that, I tested FF-A with the whole serie applied and I can
confirm it works on my side so for the whole serie:

Tested-by: Bertrand Marquis 

Cheers
Bertrand

>=20
> Thanks,
> Jens
>=20
> Jens Wiklander (6):
>  xen/arm: ffa: rename functions to use ffa_ prefix
>  xen/arm: ffa: move common things to ffa_private.h
>  xen/arm: ffa: separate memory sharing routines
>  xen/arm: ffa: separate partition info get routines
>  xen/arm: ffa: separate rxtx buffer routines
>  xen/arm: ffa: support FFA_FEATURES
>=20
> xen/arch/arm/tee/Makefile       |    3 +
> xen/arch/arm/tee/ffa.c          | 1629 ++-----------------------------
> xen/arch/arm/tee/ffa_partinfo.c |  373 +++++++
> xen/arch/arm/tee/ffa_private.h  |  347 +++++++
> xen/arch/arm/tee/ffa_rxtx.c     |  216 ++++
> xen/arch/arm/tee/ffa_shm.c      |  708 ++++++++++++++
> 6 files changed, 1750 insertions(+), 1526 deletions(-)
> create mode 100644 xen/arch/arm/tee/ffa_partinfo.c
> create mode 100644 xen/arch/arm/tee/ffa_private.h
> create mode 100644 xen/arch/arm/tee/ffa_rxtx.c
> create mode 100644 xen/arch/arm/tee/ffa_shm.c
>=20
> --=20
> 2.34.1
>=20



From xen-devel-bounces@lists.xenproject.org Wed Mar 27 13:48:38 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 13:48:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698556.1090368 (Exim 4.92)
	(envelope-from )
	id 1rpTdu-0006UH-4C; Wed, 27 Mar 2024 13:48:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698556.1090368; Wed, 27 Mar 2024 13:48:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpTdu-0006UA-0K; Wed, 27 Mar 2024 13:48:38 +0000
Received: by outflank-mailman (input) for mailman id 698556;
 Wed, 27 Mar 2024 13:48:37 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1rpTdt-0006U0-5B
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 13:48:37 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpTdq-000792-QG; Wed, 27 Mar 2024 13:48:34 +0000
Received: from [15.248.2.236] (helo=[10.24.67.40])
 by xenbits.xenproject.org with esmtpsa
 (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92)
 (envelope-from )
 id 1rpTdq-0002v2-KY; Wed, 27 Mar 2024 13:48:34 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=megaul14JSKhWrBzrhVIim2ZO+HBxbk+vEsvGwq28Yc=; b=glTCSP/je66+/cWNI+hbyoX9NU
	s8VNi9syLscN5ZAHOKcTORqNVFMTbpO1GikqevME4SlZnE2dXyYu4Fh9izJXWxpGyIRfqnj6LiU4s
	LZBfy/Wi9RzeHaMbRnZ9XXZJXFTa5yidw7U2MwVpSTlPupQ0IeZcxbJwwTUexI8XK230=;
Message-ID: 
Date: Wed, 27 Mar 2024 13:48:32 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 08/14] xen/page_alloc: introduce preserved page flags
 macro
Content-Language: en-GB
To: Jan Beulich ,
 Carlo Nonato 
Cc: Andrew Cooper ,
 George Dunlap ,
 Stefano Stabellini , Wei Liu ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
 <20240315105902.160047-9-carlo.nonato@minervasys.tech>
 <3f615066-a792-493f-ba33-7667a6557c23@xen.org>
 <9e0f7ff3-5457-41e4-a1e4-bf75804fb900@xen.org>
 <255be735-f9fe-4e39-a24e-2f6aff91acc5@suse.com>
 
 <3427132d-9458-4447-b667-d2ef3c1f0569@suse.com>
 
 
 
 
 <54156e94-3630-49b1-8a22-5cd4206d565f@xen.org>
 
From: Julien Grall 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit



On 27/03/2024 13:38, Jan Beulich wrote:
> On 27.03.2024 14:28, Julien Grall wrote:
>> Hi Carlo,
>>
>> On 27/03/2024 11:10, Carlo Nonato wrote:
>>> Hi guys,
>>>
>>>> Question is: How would you justify such a change? IOW I'm not convinced
>>>> (yet) this wants doing there.
>>>
>>> You mean in this series?
>>>
>>>> Looking at the code, the flag is originally set in
>>>> alloc_domheap_pages(). So I guess it would make sense to do it in
>>>> free_domheap_pages().
>>>
>>> We don't hold the heap_lock there.
>> Regardless of the safety question (I will answer below), count_info is
>> not meant to be protected by heap_lock. The lock is protecting the heap
>> and ensure we are not corrupting them when there are concurrent call to
>> free_heap_pages().
>>
>>   > Is it safe to change count_info without it?
>>
>> count_info is meant to be accessed locklessly. The flag PGC_extra cannot
>> be set/clear concurrently because you can't allocate a page that has not
>> yet been freed.
>>
>> So it would be fine to use clear_bit(..., ...);
> 
> Actually we hardly ever use clear_bit() on count_info. Normally we use
> ordinary C operators.

I knew you would say that. I am not convince it is safe to always using 
count_info without any atomic operations. But I never got around to 
check all them.

> Atomic (and otherwise lockless) updates are useful
> only if done like this everywhere.

You are right. But starting to use the bitops is not going to hurt 
anyone (other than maybe performance, but once we convert all of them, 
then this will become moot). In fact, it helps start to slowly move 
towards the aim to have count_info safe.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Wed Mar 27 14:01:24 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 14:01:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698564.1090388 (Exim 4.92)
	(envelope-from )
	id 1rpTqA-0002Wj-Km; Wed, 27 Mar 2024 14:01:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698564.1090388; Wed, 27 Mar 2024 14:01:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpTqA-0002Vt-GE; Wed, 27 Mar 2024 14:01:18 +0000
Received: by outflank-mailman (input) for mailman id 698564;
 Wed, 27 Mar 2024 14:01:17 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpTq9-0002VW-9O
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 14:01:17 +0000
Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com
 [2607:f8b0:4864:20::834])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 79dbded1-ec42-11ee-afe3-a90da7624cb6;
 Wed, 27 Mar 2024 15:01:16 +0100 (CET)
Received: by mail-qt1-x834.google.com with SMTP id
 d75a77b69052e-430a0d6c876so41699581cf.3
 for ; Wed, 27 Mar 2024 07:01:16 -0700 (PDT)
Received: from [10.80.67.139] (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 bt11-20020ac8690b000000b0043167d8c57dsm2171561qtb.56.2024.03.27.07.01.12
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 27 Mar 2024 07:01:13 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 79dbded1-ec42-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1711548074; x=1712152874; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=e4H7llacADefE2zKtkDfSO207C0vYCQ+E10P/nLTMyk=;
        b=hlTIUKqv+V66lRvrSxIg6soFmeABFRXeFn0QnSTkDLn7xLzl1/KNKEmCYGZWnz35BK
         W8rfI4F1lxsqQTSwGee4R5OEz3yH3HUYT/KjqHTVw/rRbqrXetxB8IDaukVyc+9aMDn2
         S/7m4n/Jd3iTX9pe6GkacOj58GlyC59SyxZgI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711548074; x=1712152874;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=e4H7llacADefE2zKtkDfSO207C0vYCQ+E10P/nLTMyk=;
        b=S33l7vRLuTcqSz8dRGLl/u7+sGZec1EGa6Qk0Ch3PltAipxdCa2+gk8USt0Jn5UJ+u
         QXnSMYHjGBZkUVVc/2XCZA8gG6YtgDancw/zwd0uy6bQwOJMBLRxaosGMK4Ob3a17We1
         myIc+tpT5Y2mPUJ1f7FXJuFqdIrMFyeyjyAmu50qiLSuv3nJTAc3qKT8srw9yq7CxVVv
         HXZfP4SmWp7wer27v/Cw1Ce/Un/V3LKkzG9KcBhPb/aXV0rctwJ1u6DYCcD1s+dONMN0
         NG4qYhJ8HfLCHpzPAXT7xOO//3wTK9DTDoNxH9iGeNy2tMncGURD9YHImf73IArtS3dl
         uJWg==
X-Forwarded-Encrypted: i=1; AJvYcCViPZ+QM00OzNIM61kKBchk0E9/3Mbe0PxF+rXj9oZgmPM9XIKGoRdm7dfKi3VB1rnVtVla0TvAQGe6oKVMcsRCK8QzG23Vit7vm8N+yuo=
X-Gm-Message-State: AOJu0Yw05lvtlpN55oVjxm7udQvg2V/ZatSmugtNG8mU86OZzUDrra17
	k8YHH4huTWIM1v7ezvql4O1KTKDr7sQmC8kDQVONzkh9Iq3RicnQaIpPNifytMU=
X-Google-Smtp-Source: AGHT+IEnFB00XGLz0I2FUSQ5RJBSDv/osm85kORxFnXRWjDcx6N5oyZ2lj5XFtQ+zeqZ3mhJLOUWzQ==
X-Received: by 2002:a05:622a:283:b0:431:3474:5327 with SMTP id z3-20020a05622a028300b0043134745327mr5031583qtw.19.1711548074267;
        Wed, 27 Mar 2024 07:01:14 -0700 (PDT)
Message-ID: <93172b11-c737-400e-9d2e-daafee8f1cbc@citrix.com>
Date: Wed, 27 Mar 2024 14:01:11 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: preparations for 4.17.4
From: Andrew Cooper 
To: Jan Beulich ,
 "xen-devel@lists.xenproject.org" 
Cc: Stefano Stabellini ,
 Anthony Perard , Julien Grall ,
 Kelly Choi 
References: 
 <6feb56fe-769d-4809-b16f-6fc4d5477747@citrix.com>
Content-Language: en-GB
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <6feb56fe-769d-4809-b16f-6fc4d5477747@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 27/03/2024 12:33 pm, Andrew Cooper wrote:
> On 27/03/2024 12:23 pm, Jan Beulich wrote:
>> All,
>>
>> the release is due in two to three weeks. Please point out backports you find
>> missing from the respective staging branch, but which you consider relevant.
>>
>> Note that this is going to be the last Xen Project coordinated ordinary stable
>> release from this branch; the branch will move into security-only support mode
>> afterwards.
> 1) livepatching of .rodata:
>
> 989556c6f8ca - xen/virtual-region: Rename the start/end fields
> ef969144a425 - xen/virtual-region: Include rodata pointers
> b083b1c393dc - x86/livepatch: Relax permissions on rodata too
>
> And technically "x86/mm: fix detection of last L1 entry in
> modify_xen_mappings_lite()" too but you've already backported this one.
>
> Patching .rodata worked before Xen 4.17, and was broken (left as a TODO)
> when I adjusted Xen to stop using CR0.WP=0 for patching.
>
>
> 2) Policy fixes:
>
> e2d8a6522516 - x86/cpu-policy: Fix visibility of HTT/CMP_LEGACY in max
> policies
>
> This is a real bugfix for a real regression we found updating from Xen
> 4.13 -> 4.17.  It has a dependency on
>
> 5420aa165dfa - x86/cpu-policy: Hide x2APIC from PV guests
>
> which I know you had more concern with.  FWIW, I'm certain its a good
> fix, and should be backported.
>
>
> 3) Test fixes:
>
> 0263dc9069dd - tests/resource: Fix HVM guest in !SHADOW builds
>
> It's minor, but does make a difference for those of us who run these
> tests regularly.
>
>
> 4) Watchdog fixes:
>
> 9e18f339830c - x86/boot: Improve the boot watchdog determination of
> stuck cpus
> 131892e0dcc1 - x86/boot: Support the watchdog on newer AMD systems
>
> You took "x86/boot: Fix setup_apic_nmi_watchdog() to fail more cleanly"
> and the first of the two patches is in the same category IMO.  The
> second I also feel ok to take for the in-support releases, particularly
> as all it is doing is dropping a family list.
>
>
> 5) Ucode scan stability  (For 4.18 only)
>
> Xen 4.18 had "x86/ucode: Refresh raw CPU policy after microcode load" in
> it's .0 release, so should also gain:
>
> cf7fe8b72dea - x86/ucode: Fix stability of the raw CPU Policy rescan
>
> I've only noticed because I've got them both backported to 4.17 in
> XenServer, but I don't think upstream wants to take that route.

It occurs to me that these want considering:

b6cf604207fd - tools/oxenstored: Use Map instead of Hashtbl for quotas
098d868e52ac - tools/oxenstored: Make Quota.t pure

while 4.17 is still in general support.  These came from a performance
regression we investigated.

I've done the backport to 4.17 and they're not entirely trivial (owing
to the major source reformat in 4.18) so can commit them if you'd prefer.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Mar 27 14:01:25 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 14:01:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698561.1090378 (Exim 4.92)
	(envelope-from )
	id 1rpTq7-0002Gw-5u; Wed, 27 Mar 2024 14:01:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698561.1090378; Wed, 27 Mar 2024 14:01:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpTq7-0002Gp-3N; Wed, 27 Mar 2024 14:01:15 +0000
Received: by outflank-mailman (input) for mailman id 698561;
 Wed, 27 Mar 2024 14:01:13 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpTq5-0002Gf-JM; Wed, 27 Mar 2024 14:01:13 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpTq5-0007Qp-8s; Wed, 27 Mar 2024 14:01:13 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpTq4-0008Hk-Ta; Wed, 27 Mar 2024 14:01:13 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rpTq4-0007L3-Oz; Wed, 27 Mar 2024 14:01:12 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=FBFFxitVoMugNKd2JckJcPqIBL55ahbnbE3FGScBOH4=; b=tAuDZAmhnrcvCdI4ry1MunHhH0
	W3p9uqstNRZYay1u+chvgJDEUsCUw5+QhmmoGfChT44zSfmVCLWTasxFcf7FDn9uLDACLivQ84L+A
	WtnmcL6MQv/pyQslkXyjwK71EXnOpG7bvgb2mfwnYbz7r7ZbjU6t2xwvWy5fI/q4zTMQ=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 185166: tolerable FAIL - PUSHED
X-Osstest-Failures:
    linux-linus:test-armhf-armhf-libvirt-vhd:xen-boot:fail:heisenbug
    linux-linus:test-armhf-armhf-libvirt-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-vhd:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-qcow2:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-qcow2:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-raw:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
X-Osstest-Versions-This:
    linux=7033999ecd7b8cf9ea59265035a0150961e023ee
X-Osstest-Versions-That:
    linux=928a87efa42302a23bb9554be081a28058495f22
From: osstest service owner 
Date: Wed, 27 Mar 2024 14:01:12 +0000

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt-vhd  8 xen-boot            fail pass in 185174-retest

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-vhd 14 migrate-support-check fail in 185174 never pass
 test-armhf-armhf-libvirt-vhd 15 saverestore-support-check fail in 185174 never pass
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop            fail like 185160
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop            fail like 185160
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop            fail like 185160
 test-armhf-armhf-libvirt     16 saverestore-support-check    fail  like 185160
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop            fail like 185160
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 185160
 test-arm64-arm64-xl-thunderx 15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      16 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-multivcpu 15 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit1  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          16 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qcow2 14 migrate-support-check        fail never pass
 test-amd64-amd64-libvirt-raw 14 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-raw 14 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-raw 15 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-vhd      14 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-vhd      15 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-qcow2    14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-qcow2    15 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass
 test-armhf-armhf-xl-raw      14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-raw      15 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     16 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     15 migrate-support-check        fail   never pass

version targeted for testing:
 linux                7033999ecd7b8cf9ea59265035a0150961e023ee
baseline version:
 linux                928a87efa42302a23bb9554be081a28058495f22

Last test of basis   185160  2024-03-25 18:44:17 Z    1 days
Testing same since   185166  2024-03-26 21:44:24 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  John Ogness 
  Linus Torvalds 
  Petr Mladek 
  Uwe Kleine-König 
  Zoltan HERPAI 

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-libvirt-qcow2                               pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-xl-qcow2                                    pass    
 test-amd64-amd64-libvirt-raw                                 pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-amd64-amd64-xl-raw                                      pass    
 test-armhf-armhf-xl-raw                                      pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-libvirt-vhd                                 fail    
 test-amd64-amd64-xl-vhd                                      pass    
 test-arm64-arm64-xl-vhd                                      pass    


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

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

Explanation of these 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 :

hint: The 'hooks/update' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
hint: The 'hooks/post-receive' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
hint: The 'hooks/post-update' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
To xenbits.xen.org:/home/xen/git/linux-pvops.git
   928a87efa423..7033999ecd7b  7033999ecd7b8cf9ea59265035a0150961e023ee -> tested/linux-linus


From xen-devel-bounces@lists.xenproject.org Wed Mar 27 14:06:39 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 14:06:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698569.1090397 (Exim 4.92)
	(envelope-from )
	id 1rpTvG-00040a-5J; Wed, 27 Mar 2024 14:06:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698569.1090397; Wed, 27 Mar 2024 14:06:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpTvG-00040T-2m; Wed, 27 Mar 2024 14:06:34 +0000
Received: by outflank-mailman (input) for mailman id 698569;
 Wed, 27 Mar 2024 14:06:32 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpTvE-00040I-7j
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 14:06:32 +0000
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com
 [2a00:1450:4864:20::62b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3666170d-ec43-11ee-afe3-a90da7624cb6;
 Wed, 27 Mar 2024 15:06:31 +0100 (CET)
Received: by mail-ej1-x62b.google.com with SMTP id
 a640c23a62f3a-a466e53f8c0so893652966b.1
 for ; Wed, 27 Mar 2024 07:06:31 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 l19-20020a17090612d300b00a46cffe6d06sm5474178ejb.42.2024.03.27.07.06.30
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 27 Mar 2024 07:06:30 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3666170d-ec43-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711548391; x=1712153191; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=f73oZlgdllswJBuQF5UqdDjTwnm18l+lGggS39yExJE=;
        b=YEuM4sZucV6/qo1Erodjb7I9koc1wpo2DfqFzVATHrt08bfvliD41X0XeHNz6yqWrR
         pPkw8k7+WjYqtXqE34BjKAaSQlNJNdg4TMXN4XbOTFbrtyPDNMhE9JTW0vr/mx0/ftlx
         mRRzIf7IWOJMPXH1x0F7Q/MEpEtgmbyk52j6BuYzv/BB6r939Ct3FDs54UU4NN7a1wfk
         Cp7VcbdqWO61GjbmgZxV6paL2F42LQoM3Yrm2Lv872TVGUuGCSlwJXgOF7HgY3wEAyDU
         Bd+l+M8Jng9+f6dZTaHtgawJH0EwZqiqckhYLJZZrMwgVnZM36hpj5vrSOE7H88sce9J
         Mu6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711548391; x=1712153191;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=f73oZlgdllswJBuQF5UqdDjTwnm18l+lGggS39yExJE=;
        b=RYTDfodAweXnG8CkzCtbkeJoAstt8/BvPYbEzM3KenohlXMT2dytmeXSsolexmvRWo
         0JBwsaD2X+qe11Mpn0jNZKiKJc5We3wR0HwJHdjfsWz4ZiShg95uC8JgzdAbLO/Dz+SO
         0x70/7a4/dtQmK7vPnjFoPpsQCpZthVl3R+aDzK/rH2U1NY2p3skuM3kBbmqpayMWKw1
         kNE1Vyj+OZf2gCO+kZjMDjQjiQuEL64LUsSY0rBHauw1GLmiT5m7QQ5wGBSab1Z1IBsu
         HxkcrD6Bv1Cr/IpsZBOVSbBawvXDfjeJbw+jr/Viu3nHJOndMNpX4K82dUeVpJMRev20
         7yHQ==
X-Forwarded-Encrypted: i=1; AJvYcCXqVuE93dj3x5LGptiVwm2k7HL1llZMRZKvhRpZgDt/e2xD2S14WbqrIRtTyIgfkR2nUK8ZSf2JESflpQWh2NPAzFr8eL1IF0ld7iddxUE=
X-Gm-Message-State: AOJu0Yyr9cL+r8w7uh/6p/dcFF1tAbpzZ4KfCuQTjymQ5QXFtz57op0J
	BveZJ1SbdqFYzS+QhKsr85Jd4z4qf/LhEC4sRjDq2X3iawtPX4uiVOSJ9uauVw==
X-Google-Smtp-Source: AGHT+IHwK41ZnSn+dxrbQAbP4J9PCKczpB3M4GgS9d0LK3jvUBvBeVs1M8v/VjKDfBmh2m6x+lnXJQ==
X-Received: by 2002:a17:906:f2c3:b0:a4a:850f:28fd with SMTP id gz3-20020a170906f2c300b00a4a850f28fdmr1093071ejb.29.1711548391036;
        Wed, 27 Mar 2024 07:06:31 -0700 (PDT)
Message-ID: 
Date: Wed, 27 Mar 2024 15:06:29 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: preparations for 4.17.4
Content-Language: en-US
To: Andrew Cooper 
Cc: Stefano Stabellini ,
 Anthony Perard , Julien Grall ,
 Kelly Choi ,
 "xen-devel@lists.xenproject.org" ,
 Christian Lindig , David Scott 
References: 
 <6feb56fe-769d-4809-b16f-6fc4d5477747@citrix.com>
 <93172b11-c737-400e-9d2e-daafee8f1cbc@citrix.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <93172b11-c737-400e-9d2e-daafee8f1cbc@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 27.03.2024 15:01, Andrew Cooper wrote:
> It occurs to me that these want considering:
> 
> b6cf604207fd - tools/oxenstored: Use Map instead of Hashtbl for quotas
> 098d868e52ac - tools/oxenstored: Make Quota.t pure
> 
> while 4.17 is still in general support.  These came from a performance
> regression we investigated.
> 
> I've done the backport to 4.17 and they're not entirely trivial (owing
> to the major source reformat in 4.18) so can commit them if you'd prefer.

Didn't you bring these up for 4.18.1 already, and I said that I'd leave
this for the maintainers to decide? Same here, in any event. Cc-ing them
both, just in case.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Mar 27 14:08:23 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 14:08:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698572.1090408 (Exim 4.92)
	(envelope-from )
	id 1rpTwz-0004Yx-GT; Wed, 27 Mar 2024 14:08:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698572.1090408; Wed, 27 Mar 2024 14:08:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpTwz-0004Yq-Dk; Wed, 27 Mar 2024 14:08:21 +0000
Received: by outflank-mailman (input) for mailman id 698572;
 Wed, 27 Mar 2024 14:08:19 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpTwx-0004Yj-Hx
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 14:08:19 +0000
Received: from NAM04-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam04on20600.outbound.protection.outlook.com
 [2a01:111:f403:2408::600])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 75068542-ec43-11ee-afe3-a90da7624cb6;
 Wed, 27 Mar 2024 15:08:18 +0100 (CET)
Received: from BL6PEPF00013E02.NAMP222.PROD.OUTLOOK.COM
 (2603:10b6:22e:400:0:1001:0:18) by IA0PR12MB8304.namprd12.prod.outlook.com
 (2603:10b6:208:3dc::13) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.33; Wed, 27 Mar
 2024 14:08:12 +0000
Received: from MN1PEPF0000ECD6.namprd02.prod.outlook.com
 (2a01:111:f403:f902::2) by BL6PEPF00013E02.outlook.office365.com
 (2603:1036:903:4::4) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.13 via Frontend
 Transport; Wed, 27 Mar 2024 14:08:12 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 MN1PEPF0000ECD6.mail.protection.outlook.com (10.167.242.135) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Wed, 27 Mar 2024 14:08:12 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Wed, 27 Mar
 2024 09:08:11 -0500
Received: from [172.31.131.34] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Wed, 27 Mar 2024 09:08:11 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 75068542-ec43-11ee-afe3-a90da7624cb6
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=CWjSL4I0p2peiPXd3ZsMCu86SXaIGNYg2yDqgzCBClmyEH0Bn9ga+ABALtaRklnw1/yUqLrLohid9SSilfR0F2eiBKqPA7U1AcNgpFp3szLGFFE9tpQi8a+W2GNtD5ybbR6EirCJiUv7tThj3b6MmE4hNZiDDcgUMGbmxQLOXwKJzGAfk+1jk2Yc82jcoMMMn0Snl6Ij0ZfX7xC3VzValKILDCurBeuZZQOOSGMQhfqKas98/nQEYjCvRA4TPxiiCKtlo59hs/T9Ah6UNSoPilMptLY8dW/84WuF44Yhtbj9Fv9Kr0Xq4vTkeRyxw6ef/pPmhAnrUBuYFWr591pV/Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=16qKNtbkc9g/1KJXvwrpzznQgGuIgTUzRb6eKhsvyCo=;
 b=Z7EqjUbinC05FOs/TF/UimUiu/Xd7IbqICwKkRIYsShTCf49a3LI3o5RpNByZXn6tHCRt8KuQHBgHUh/JfDlVuvp278+Qu2eh4HmGy8dthluaeBvdqVm3gNSrKi82aoxo6NDMSMk+HOggnDyNud4ucXPVMr3NoO+9ec5QwyS4dWHTdFwOZi8WwP33oH8n2HfBYGxtDIMi/hJd0lebMNADIZNLMOYXego33ObfiWeVPNW2J8hFnPSiD+mkXpHHlVNPx3tmcsqhEQ+4XZ8Ks4ENO3cUeASFieVnCMRsxroKztuMERs/vhEBi2seiDJU1Y+wrobvwwC9BR8fcvBpRVLyA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=citrix.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=16qKNtbkc9g/1KJXvwrpzznQgGuIgTUzRb6eKhsvyCo=;
 b=rTMMyLkJtmjYVVTgoKaCZemxfwsWOqpzAZA6a9BuzD4CqnttW+GZNAE6tQhKkRdHmHRBYTX+MWMYABtQI78QU1St8ixSQllDpUlQsljA5M1Hh9YynqCP+CkfQI8tvXEtv3gxAh4B3AECleWNNnyrURR4TcyWOVFhROnd82qtYyU=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Message-ID: <09c73d19-dda8-44a3-be4f-1644a2bd1a4c@amd.com>
Date: Wed, 27 Mar 2024 10:08:12 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 1/6] Revert "xen/x86: bzImage parse kernel_alignment"
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jan Beulich
	
CC: Andrew Cooper ,
	
References: <20240326213847.3944-1-jason.andryuk@amd.com>
 <20240326213847.3944-2-jason.andryuk@amd.com>
  
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: 
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
Received-SPF: None (SATLEXMB04.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: MN1PEPF0000ECD6:EE_|IA0PR12MB8304:EE_
X-MS-Office365-Filtering-Correlation-Id: 1dc2d716-3f1c-4232-e2f3-08dc4e6756d7
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	nxAvRMgRl5xT2p0eDWQXAoMOoCa5yFjlMD7sIvK1B93jruEWFxfcdOMprLG24hWojcwfUXWsvOVOYDIi7MiMiTUXQmtVFwFA1OSBJCCyLx5H3Qn5IEApml00NBX51XjPfBZNbypI4KzZtB2+ON3uRgkSbxpRL2uvxeztXc5WD3dUwD+O27Rh4xm4LasG6dvomtv9R0xuZDaskxW/IDFWXwGSoB9H0ATevyS/Jk7EqsqOBl9Il3wv1vHo4oodbgt0w6DY/hVBwEVRtuJARL3h5hqUVpjbQC1ZuO3ssxH+hfcocG9EgTLr/P7nnfr7ngOH5NG3ezL5j3W2YotZV8EKB7FcRgZb9tLgdscNp9hQFCVU6KmVxji5UaGQoY7MYGoZDZDLNYvNycT9EQ08Ufeq7sbIoTPNNStz62HdHMs2ykE+P4a5s0YMgbWH6UJgCCpB3DNIl2p8+odGX259pxVGI3GCZJAmqf2jOJ7ti4eNRtyeJzEr6Ie+Gyk2y27uJWHa6TrKTY06D8qmT4AKTeN+w22RJkfIjiriPJwS/WxnjXPeg3BFSHTSatEFBaWnVOTJVhaaobbae2N0Hcx7ciRrzOMAsCXUA/YUaBPLRnhQR5gv7xYzQ98bPMrf7Fr5x1frpdCna/nw00mk9xArRncKjtsquddkhY5YICLnjdbLsrWN8Lx/rNRxzphRvtY2iRA7W5N66MbU1P+RxP+2SlRuoFzM45i343reB4lz9TkJ48wwElcmBaYjSXBfSU9wLhGe
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(376005)(82310400014)(36860700004)(1800799015);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Mar 2024 14:08:12.4885
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 1dc2d716-3f1c-4232-e2f3-08dc4e6756d7
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	MN1PEPF0000ECD6.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR12MB8304

On 2024-03-27 04:59, Roger Pau Monné wrote:
> On Wed, Mar 27, 2024 at 08:22:41AM +0100, Jan Beulich wrote:
>> On 26.03.2024 22:38, Jason Andryuk wrote:
>>> A new ELF note will specify the alignment for a relocatable PVH kernel.
>>> ELF notes are suitable for vmlinux and other ELF files, so this
>>> Linux-specific bzImage parsing in unnecessary.
>>>
>>> This reverts commit c44cac229067faeec8f49247d1cf281723ac2d40.
>>>
>>> Signed-off-by: Jason Andryuk 
>>
>> Since you keep re-sending this: In private discussion Roger has indicated
>> that, like me, he too would prefer falling back to the ELF data, before
>> falling back to the arch default (Roger, please correct me if I got it
>> wrong). That would make it necessary that the change you're proposing to
>> revert here is actually kept.
> 
> Sorry, was meaning to reply yesterday but Jason is very fast at
> sending new version so I'm always one version behind.

:)

I was hoping to finish this up and get it in...

> IMO the order: ELF note, PHDR alignment, arch default should be the
> preferred one.
> 
>> Or wait - what you're reverting is taking the alignment out of the
>> bzImage header. I don't expect the BSDs to use that protocol; aiui that's
>> entirely Linux-specific.
> 
> Yeah, I don't have strong opinions in keeping this, we already do
> bzImage parsing, so we might as well attempt to fetch the alignment
> from there if correct:
> 
> ELF note, bzImage kernel_alignment, ELF PHDR alignment, arch default

I'm not sure how to handle ELF PHDR vs. arch default.  ELF PHDR will 
always be set, AFAIU.  Should that always be respected, which means we 
don't need an arch default?

To include arch default, it would be something like this:

     if ( parms->phys_align != UNSET_ADDR )
         align = parms->phys_align;
     else if ( bz_align )
         align = bz_align;
     else if ( elf->palign > PHYS32_RELOC_ALIGN_DEFAULT )
         align = elf->palign;
     else
         align = PHYS32_RELOC_ALIGN_DEFAULT;


>> I further meanwhile realized that consulting the ELF phdrs may also be
>> ambiguous, as there may be more than one. I guess it would need to be the
>> maximum of all of them then.
> 
> My suggestion (not sure if I mentioned this before) was to use the
> alignment of the first LOAD PHDR, which is the one that defines the
> value of the dest_base field used as the image load start address.
> 
> Using the maximum of all load PHDRs might be safer.

I'll find the maximum.

Thanks,
Jason


From xen-devel-bounces@lists.xenproject.org Wed Mar 27 14:15:45 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 14:15:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698574.1090417 (Exim 4.92)
	(envelope-from )
	id 1rpU44-0006eh-7N; Wed, 27 Mar 2024 14:15:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698574.1090417; Wed, 27 Mar 2024 14:15:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpU44-0006ea-4f; Wed, 27 Mar 2024 14:15:40 +0000
Received: by outflank-mailman (input) for mailman id 698574;
 Wed, 27 Mar 2024 14:15:39 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpU43-0006eU-BD
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 14:15:39 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on20600.outbound.protection.outlook.com
 [2a01:111:f403:2417::600])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7af123f7-ec44-11ee-a1ef-f123f15fe8a2;
 Wed, 27 Mar 2024 15:15:37 +0100 (CET)
Received: from MN2PR15CA0063.namprd15.prod.outlook.com (2603:10b6:208:237::32)
 by SN7PR12MB7835.namprd12.prod.outlook.com (2603:10b6:806:328::22)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.33; Wed, 27 Mar
 2024 14:15:33 +0000
Received: from BL02EPF0001A101.namprd05.prod.outlook.com
 (2603:10b6:208:237:cafe::b) by MN2PR15CA0063.outlook.office365.com
 (2603:10b6:208:237::32) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.13 via Frontend
 Transport; Wed, 27 Mar 2024 14:15:33 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 BL02EPF0001A101.mail.protection.outlook.com (10.167.241.132) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Wed, 27 Mar 2024 14:15:33 +0000
Received: from SATLEXMB08.amd.com (10.181.40.132) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Wed, 27 Mar
 2024 09:15:32 -0500
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB08.amd.com
 (10.181.40.132) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Wed, 27 Mar
 2024 07:15:32 -0700
Received: from [172.31.131.34] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Wed, 27 Mar 2024 09:15:32 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7af123f7-ec44-11ee-a1ef-f123f15fe8a2
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=N3hJKTK3tGj6cc5mFgSXtn5x8O7HgCpvIYr0wHnSDxIeDhHhBkHmDf5qFInAOtAAReLnpLJF2Ua8fMD1RZWNSTkydXpU8njFzpcQ/BKHAip2kotKYDV+xqW56jm4y+2c0EB0efqvmdgIMazR5CwpcphGzuWOzzTk9dPJa+TOJonR3Sj/Q9O7m5JV5Jiy+fl5MeWXFCn4AcVnDnOBxi9ykHEa9L6dj9l8hXb4TBVh1mE5H5bGB8EAk6aExuajFVnZbjykEEvDHnqgnWU7Z1RajdupQOuWvoK+KB6BaV+DQ5n8N1RMIxxzclk2p91yQ/8C1sZ1au3wqmnnMtbULCXj8g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=kNHdxsz/A+O0scydcjNzdJegkiK444ynTZTaIymkn3k=;
 b=Jmi1P5Hxs0cWCqkkrKCQx5W/NIZiZLvZaEXgP2u+KZJ8ni93Ga43SCemFRhRpppANANRT7F5/PkgUD5F6A8FDs85t4Dr25Qbw5aS4ht3m1adKawwsH6zWnu9Gi3ZEFE1gOLfPKaLDLfrAbTdWX+dkgdE0yLhhkBmUPYSRlYJfWyjHuY2YEDYnvUkXVGmKbbBAblj9l6YRo7Xlf98pICz+n9qrVdAKOdQKqe6TaOgNyjnkilfxTkN2DNCf8mrYktbcMk5kqOjIanlCDsvXfkXCUfJ4Q6yIXBjhqSr/4NHRkwsYH0mVIOf/GNbKWMohj3mNAwXcieDSzz29OvaBj6oqQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=kNHdxsz/A+O0scydcjNzdJegkiK444ynTZTaIymkn3k=;
 b=gmaL8anfJkKhLdS+foO4Ptfd5T9xkhmhNj1XoVghN+NIsU8FuiCu8/SXGWERfk06s4uOAlb++2g2tOe0cokGR575QFHmvZDBfXvn71ba8IS6AFhhu4P6VeXwA4rXIf6NjvT8VRNZ2KKfv+V98t3rSyO+tiDzWfnbWCi+eJ74sGY=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
Message-ID: <67cf20aa-a55a-496c-b3cc-bf5317ba98be@amd.com>
Date: Wed, 27 Mar 2024 10:15:30 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5] RFC: x86/pvh: Make Xen PVH entrypoint PIC for x86-64
To: Jan Beulich 
CC: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Andrew Cooper
	, Juergen Gross , Boris Ostrovsky
	, 
References: <20240326213847.3944-1-jason.andryuk@amd.com>
 <20240326214701.7015-1-jason.andryuk@amd.com>
 <45c20ffd-f0c0-4521-8221-c3384cd5f7c5@suse.com>
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: <45c20ffd-f0c0-4521-8221-c3384cd5f7c5@suse.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BL02EPF0001A101:EE_|SN7PR12MB7835:EE_
X-MS-Office365-Filtering-Correlation-Id: 65d70ed1-16ab-4054-45cb-08dc4e685d6e
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	hUXtLG5KV5a4ArveoAGN6eevzF3zc2OzBObBl4F83lcGVjU8OSF1freR046Hql/GPsKTty/yUIo17unnNgaXno/uF0YEPNcSZJToDERTPFREmQzr+tmSlhfm+KrqyXqSsbXqxFI1dUrZSKQa2k32KJEB3r8W7BjNdDPoIW4GlEfCTk9aRbbqOzZ4PwYSJtLFNHe25ODsRkA8O1u01UPiD9oyzik+wnf5OGI2pKxNYauJss5W/nwDjsp3i0Y58rNQDXIhXFuDaWF6qJj22gyr1OEPMnRW5ZMSiQB6GcnTjsTtOmqLBZcquE6S3ZmSsI+1kzqWAK2Zjt0Q9JQCwoXcE0IugwvFP9fVTUNLk9zFZ7xuB1jRN+dyZgO3mnLvb38iDSY3O5UU7SUbrn2T4Ga/PH4slg5U0/e7rF4bTPa2+8YZ+oZP1eQbnztQfZuemkWOQKrHfXiL1NM/+t+omySYpn9ZXeSV73zr9Eavh5uimtO2wjLRrZjMouGMz9U+uaAtLcXGZlRuAXbd5kPs7rdPZMw/nCKkOmNOwzuZjIy1knzr+e0zxV0Z35X9dzvb7YGmuU40hRVGtJUQvWOtWuCVZ+wd8DGTjTzIF0n9uT+iXpC/jeWYITKEE7XwdVXDyLn1KQYCtEgRzRJ30GkPmVK/PaJhwNdYlCn1GJ0l3LC7DzLEnmW3TioIDYoy+XuYixgc465K+ctxrp3zrkQWOwzE5JHy0nOL/zmWxY+FmDQwh55U9TeVSoDaf9lhtJrgTnnZ
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(1800799015)(36860700004)(82310400014)(376005);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Mar 2024 14:15:33.0372
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 65d70ed1-16ab-4054-45cb-08dc4e685d6e
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BL02EPF0001A101.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB7835

On 2024-03-27 04:20, Jan Beulich wrote:
> On 26.03.2024 22:47, Jason Andryuk wrote:
>> --- a/include/xen/interface/elfnote.h
>> +++ b/include/xen/interface/elfnote.h
>> @@ -185,9 +185,25 @@
>>    */
>>   #define XEN_ELFNOTE_PHYS32_ENTRY 18
>>   
>> +/*
>> + * Physical loading constraints for PVH kernels
>> + *
>> + * Used to place constraints on the guest physical loading addresses and
>> + * alignment for a PVH kernel.
>> + *
>> + * The presence of this note indicates the kernel supports relocating itself.
>> + *
>> + * The note may include up to three 32bit values in the following order:
>> + *  - a maximum address for the entire image to be loaded below (default
>> + *      0xffffffff)
>> + *  - a minimum address for the start of the image (default 0)
>> + *  - a required start alignment (default 0x200000)
> 
> This looks to be stale now.

Yes - I did not update this file.

The patch is functional as the ELF Note fields in 
arch/x86/platform/pvh/head.S were re-ordered to match the Xen side.

Regards,
Jason


From xen-devel-bounces@lists.xenproject.org Wed Mar 27 14:19:29 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 14:19:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698580.1090428 (Exim 4.92)
	(envelope-from )
	id 1rpU7i-0007rW-RB; Wed, 27 Mar 2024 14:19:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698580.1090428; Wed, 27 Mar 2024 14:19:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpU7i-0007rP-Mm; Wed, 27 Mar 2024 14:19:26 +0000
Received: by outflank-mailman (input) for mailman id 698580;
 Wed, 27 Mar 2024 14:19:25 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpU7h-0007rF-KG
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 14:19:25 +0000
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com
 [2a00:1450:4864:20::634])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 02894f77-ec45-11ee-a1ef-f123f15fe8a2;
 Wed, 27 Mar 2024 15:19:23 +0100 (CET)
Received: by mail-ej1-x634.google.com with SMTP id
 a640c23a62f3a-a46a7208eedso926208966b.0
 for ; Wed, 27 Mar 2024 07:19:23 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 w2-20020a1709067c8200b00a4720ce2e75sm5453491ejo.129.2024.03.27.07.19.22
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 27 Mar 2024 07:19:22 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 02894f77-ec45-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711549163; x=1712153963; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=IzySVz8jHI3rWBmAmd7slHPi22PNQrHAEXn3r2NXpDQ=;
        b=GB2BZyYQ7vfxrulcwrT3fQ9Ile8oK/iWRMElLTw423YlkJPw6DdgMsm09Rn/1sc7+t
         5MH/VSqqBeoOwk4SonORI4msNPqFSPbCQgvMsI021y70O4JDmpn/zSDDUud+XYUfL1BE
         VsiV/ki16onv2Ukakb95taIiXYOgnwdulmtkxSndRMrxHed2PBSPjkgA4+VKJG7QAIlW
         1jGaGkD4juoMZMUrVzEZgc9JteAfZ4CedpD99Su/7/fD7Nsp8nJYMRYq2FfkfFMIlRRg
         j+Zx3BJ7jZvCmx3e5bNh61UHazehtxL3Pq7TflXu0rEh71AbQJNMbhxQxJxKgN6BUeWV
         H0uw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711549163; x=1712153963;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=IzySVz8jHI3rWBmAmd7slHPi22PNQrHAEXn3r2NXpDQ=;
        b=Jtzq+9uEbelT0nACtCf0/myyHR4zY6NJWBPsr6vS2arOH69fHEaCYKDaPxWIyY/gfH
         uNfyk8xaxiTpdIHX8+1SLLCbMevu9rA211z1xcc6YEvBR/ykgCN1W27LAdVDZMS6d5qH
         J2MrwyVU5DJWFrEz+qAGuySi8UIpRgRFU5rg8DFBeP5NSaTcXs8SBvJT3ZcRGxJabG+t
         4ivxYbnRj2Dh7B/G6IhpXCLLnMBzcKpMSZqPG8Tu6gZsB3I/sJs4TRcv727bMIhoocxw
         Eo075MLRXa4bHUFN/a2s2dsnpFBeZxF+X8PjBNxaSKBocUi+0it9LdWzsphlUjkcsujr
         Ossg==
X-Forwarded-Encrypted: i=1; AJvYcCVDGmvEnrQZczrOOq1jYI4GuKyTNZychmEI7pXe3IU61O2XYVp5/QpRGEIvZK+FO6K03L88R9xvrmy8Cihh9gFphhlWGtT7A/91kdd3vD8=
X-Gm-Message-State: AOJu0YxMLczsStVNEhur6lg1GPYBQ4E0HcqWp3shSmRyKbxdOatWXPGi
	bP9nKkkrQWUaWU2kvsQlTM/+f13EsB0GQ7gExsleIjdCXrca8tRz3G3ETm2qnA==
X-Google-Smtp-Source: AGHT+IETV6LlyH64QTtctYTBAnJxPxxa0VhxGCRMOVDYxwqO88orE7/mQ7EeZmsP5brbItOGhkzGUQ==
X-Received: by 2002:a17:907:31ce:b0:a4d:fe8f:bb93 with SMTP id xf14-20020a17090731ce00b00a4dfe8fbb93mr2391989ejb.30.1711549163038;
        Wed, 27 Mar 2024 07:19:23 -0700 (PDT)
Message-ID: <92754a17-fe02-4050-9ca5-5a1ded3483dc@suse.com>
Date: Wed, 27 Mar 2024 15:19:21 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 1/6] Revert "xen/x86: bzImage parse kernel_alignment"
Content-Language: en-US
To: Jason Andryuk 
Cc: Andrew Cooper ,
 xen-devel@lists.xenproject.org, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 
References: <20240326213847.3944-1-jason.andryuk@amd.com>
 <20240326213847.3944-2-jason.andryuk@amd.com>
  
 <09c73d19-dda8-44a3-be4f-1644a2bd1a4c@amd.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <09c73d19-dda8-44a3-be4f-1644a2bd1a4c@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 27.03.2024 15:08, Jason Andryuk wrote:
> On 2024-03-27 04:59, Roger Pau Monné wrote:
>> On Wed, Mar 27, 2024 at 08:22:41AM +0100, Jan Beulich wrote:
>>> On 26.03.2024 22:38, Jason Andryuk wrote:
>>>> A new ELF note will specify the alignment for a relocatable PVH kernel.
>>>> ELF notes are suitable for vmlinux and other ELF files, so this
>>>> Linux-specific bzImage parsing in unnecessary.
>>>>
>>>> This reverts commit c44cac229067faeec8f49247d1cf281723ac2d40.
>>>>
>>>> Signed-off-by: Jason Andryuk 
>>>
>>> Since you keep re-sending this: In private discussion Roger has indicated
>>> that, like me, he too would prefer falling back to the ELF data, before
>>> falling back to the arch default (Roger, please correct me if I got it
>>> wrong). That would make it necessary that the change you're proposing to
>>> revert here is actually kept.
>>
>> Sorry, was meaning to reply yesterday but Jason is very fast at
>> sending new version so I'm always one version behind.
> 
> :)
> 
> I was hoping to finish this up and get it in...
> 
>> IMO the order: ELF note, PHDR alignment, arch default should be the
>> preferred one.
>>
>>> Or wait - what you're reverting is taking the alignment out of the
>>> bzImage header. I don't expect the BSDs to use that protocol; aiui that's
>>> entirely Linux-specific.
>>
>> Yeah, I don't have strong opinions in keeping this, we already do
>> bzImage parsing, so we might as well attempt to fetch the alignment
>> from there if correct:
>>
>> ELF note, bzImage kernel_alignment, ELF PHDR alignment, arch default
> 
> I'm not sure how to handle ELF PHDR vs. arch default.  ELF PHDR will 
> always be set, AFAIU.  Should that always be respected, which means we 
> don't need an arch default?

A value of 0 (and 1) is specifically permitted, to indicate no alignment.
We may take 0 to mean default, but what you suggest below is another
plausible approach. Yet another might be to take anything below PAGE_SIZE
as "use default".

> To include arch default, it would be something like this:
> 
>      if ( parms->phys_align != UNSET_ADDR )
>          align = parms->phys_align;
>      else if ( bz_align )
>          align = bz_align;

Why do you include bz again here? Didn't you previously indicate the
header field can't be relied upon? Which is also why, finally, I committed
this revert earlier today.

Jan

>      else if ( elf->palign > PHYS32_RELOC_ALIGN_DEFAULT )
>          align = elf->palign;
>      else
>          align = PHYS32_RELOC_ALIGN_DEFAULT;
> 
> 
>>> I further meanwhile realized that consulting the ELF phdrs may also be
>>> ambiguous, as there may be more than one. I guess it would need to be the
>>> maximum of all of them then.
>>
>> My suggestion (not sure if I mentioned this before) was to use the
>> alignment of the first LOAD PHDR, which is the one that defines the
>> value of the dest_base field used as the image load start address.
>>
>> Using the maximum of all load PHDRs might be safer.
> 
> I'll find the maximum.
> 
> Thanks,
> Jason



From xen-devel-bounces@lists.xenproject.org Wed Mar 27 14:27:50 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 14:27:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698584.1090437 (Exim 4.92)
	(envelope-from )
	id 1rpUFl-0001qG-IF; Wed, 27 Mar 2024 14:27:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698584.1090437; Wed, 27 Mar 2024 14:27:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpUFl-0001q9-Fk; Wed, 27 Mar 2024 14:27:45 +0000
Received: by outflank-mailman (input) for mailman id 698584;
 Wed, 27 Mar 2024 14:27:44 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpUFk-0001q3-Cp
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 14:27:44 +0000
Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com
 [2a00:1450:4864:20::12c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2c85596b-ec46-11ee-afe3-a90da7624cb6;
 Wed, 27 Mar 2024 15:27:43 +0100 (CET)
Received: by mail-lf1-x12c.google.com with SMTP id
 2adb3069b0e04-515c198e835so372854e87.3
 for ; Wed, 27 Mar 2024 07:27:43 -0700 (PDT)
Received: from perard.uk.xensource.com (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 jw24-20020a170906e95800b00a49856ae93asm3739062ejb.198.2024.03.27.07.27.41
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 27 Mar 2024 07:27:42 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2c85596b-ec46-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1711549663; x=1712154463; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=6s9TY9/Cn4vJqrwwNmvG7/hGbs5cbUMGy83r/DdqAYU=;
        b=dMOmXAYnPmBrgmiBOAQLeLAlJ5Cd0yfJ0k5yEkljdGMFGw5AtD1CykvVwMdmCVn+o0
         TDPlNmTXQWsz8rnyD6vAk4BTdnXP36abuZWRKfwfCx73MIcSfy59o80TB+ugbVNeRrFo
         txr5tHiKJ4ZPWY6xGDu+YfgSRKJYoXWPDfC4w=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711549663; x=1712154463;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=6s9TY9/Cn4vJqrwwNmvG7/hGbs5cbUMGy83r/DdqAYU=;
        b=QNFYymALNI332gH0b4zEtuN9D1LeRbujqo+KnUyDGFGka6CwBdRRTJzQHmuW6C9EXt
         eh20XIkvFP45ZNCnup9yg8dHFXY+pYCXdBePcvZ8AT4NG48+zDcpNkDFVxHQJY8acoYF
         sk25ejTGqGCUjx79b6tuJttiJTA1QQ9n3BVzVfVxIGfZzDvMRbILIgD7cj9kgqXA2Kv+
         xvk+7Ulv/eWRdejZNlv3hWN2Uc71wKXwRpU/idTqPsNX+p+RCLXkLAAmuOmGYTcwi33n
         GH51EdTa+MXK1amWswr3gTbr5OYDlW2Bny9+dBtCOTQxohhi7yCu/YDtNERogSjaazch
         9T3g==
X-Forwarded-Encrypted: i=1; AJvYcCUNlGM+d2HfJ7fC/oerzDv+eoAwtbsWXO6GzWJT1n42WCLXlLR1GKSUlV9EUYUo0B5/Lcob/GZWx72gMIeIrA33cVAaM9E2SDC9ALt0dec=
X-Gm-Message-State: AOJu0YwOzts0TXUbaPu8kI8x0JcerI6a2cXWOt5SCw0KIefaTpu/fbpS
	tQa7Ne2m+eEu2rZIIaIcduHFWDdWWJYXiyBOK+9cEbsuytvBU5DcUGVHaPk0m8Q=
X-Google-Smtp-Source: AGHT+IGfOGc5SfDKXbq/6cWQXWrbWdawL9QipNh4y7lGdJ/Uq0Y4kUnfad0T2fo+7kdSA94cBcA4PA==
X-Received: by 2002:a05:6512:6c3:b0:515:ba94:8929 with SMTP id u3-20020a05651206c300b00515ba948929mr4374913lff.32.1711549662886;
        Wed, 27 Mar 2024 07:27:42 -0700 (PDT)
Date: Wed, 27 Mar 2024 14:27:41 +0000
From: Anthony PERARD 
To: Philippe =?iso-8859-1?Q?Mathieu-Daud=E9?= 
Cc: David Woodhouse , qemu-devel@nongnu.org,
	Alex =?iso-8859-1?Q?Benn=E9e?= ,
	Paul Durrant , qemu-arm@nongnu.org,
	Paolo Bonzini ,
	David Woodhouse ,
	Stefano Stabellini ,
	Richard Henderson ,
	xen-devel@lists.xenproject.org, qemu-block@nongnu.org,
	kvm@vger.kernel.org, Thomas Huth ,
	Peter Maydell ,
	Eduardo Habkost ,
	"Michael S. Tsirkin" ,
	Marcel Apfelbaum 
Subject: Re: [PATCH-for-9.0 v2 12/19] hw/xen: Merge 'hw/xen/arch_hvm.h' in
 'hw/xen/xen-hvm-common.h'
Message-ID: <8829dd17-308b-45fe-8d48-a980470316e8@perard>
References: <20231114143816.71079-1-philmd@linaro.org>
 <20231114143816.71079-13-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20231114143816.71079-13-philmd@linaro.org>

On Tue, Nov 14, 2023 at 03:38:08PM +0100, Philippe Mathieu-Daud wrote:
> We don't need a target-specific header for common target-specific
> prototypes. Declare xen_arch_handle_ioreq() and xen_arch_set_memory()
> in "hw/xen/xen-hvm-common.h".
> 
> Signed-off-by: Philippe Mathieu-Daud 
> Reviewed-by: David Woodhouse 
> Reviewed-by: Richard Henderson 

Acked-by: Anthony PERARD 

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Wed Mar 27 14:42:42 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 14:42:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698587.1090448 (Exim 4.92)
	(envelope-from )
	id 1rpUU5-0006as-Oe; Wed, 27 Mar 2024 14:42:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698587.1090448; Wed, 27 Mar 2024 14:42:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpUU5-0006al-Lm; Wed, 27 Mar 2024 14:42:33 +0000
Received: by outflank-mailman (input) for mailman id 698587;
 Wed, 27 Mar 2024 14:42:32 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpUU4-0006ae-K3
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 14:42:32 +0000
Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com
 [2607:f8b0:4864:20::733])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3d70661c-ec48-11ee-afe3-a90da7624cb6;
 Wed, 27 Mar 2024 15:42:31 +0100 (CET)
Received: by mail-qk1-x733.google.com with SMTP id
 af79cd13be357-78a5580324eso194903885a.3
 for ; Wed, 27 Mar 2024 07:42:31 -0700 (PDT)
Received: from [10.80.67.139] (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 h26-20020a05620a13fa00b0078a292780c6sm3906124qkl.75.2024.03.27.07.42.28
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 27 Mar 2024 07:42:29 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3d70661c-ec48-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1711550550; x=1712155350; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=5EGsdBBBqo4WIBvqqR+snh+BhEcGGZ2YwYZ8VsJQZnQ=;
        b=jXKlnVrhvfVqRjCrW1y6bpLObpkxFzmWg4EyJIMnU1m2TWmWqksnVbJFkN8mU4FzbN
         vR1uBjuRXnr2BkeKzxtWJqXa4F/5iDYHQY4Tj2y3sPkLetAoSvU8OJq4HwwRDglle8Rq
         rTOzEqiMvBtnRmVkVdqLCh/EjIT+AoGWlsMm4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711550550; x=1712155350;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=5EGsdBBBqo4WIBvqqR+snh+BhEcGGZ2YwYZ8VsJQZnQ=;
        b=CLaecu6nv8cjYctwtjlOHCSj0lyHeLjrDlQGMM+VC2sZ0cmQVXF5ULtt0vEy0N3trv
         13WEYPjGojwlrs4/sXdCc9zpQGET74qll93MqCkhIn0UhaJTvoi6bv5GPYVysu0uaDDx
         AqrBX0PabzM616pt54jG+pQPH13kfqwMmycuT6l4KJtVlgJ4z6HvvKvkphtNCvSX/Ho0
         rVPOh4Xi2Up8cHFiiOZcqYppWP8l8lU8RLG/Pv4rOqY3HkIKJ/fHbTtrfmFFfZDRBApK
         POuG9eZ/rVjy3SFOfibgg0bWD+sHPthwLswqj6S6H5V2UJfGbOEYxzlNQ75ifOilCnrA
         R8jA==
X-Forwarded-Encrypted: i=1; AJvYcCXi9h3qiskuVgKZHLhj1EntujogGlUSavO2ise0HXllzW4flLjJzUOu08DEWdwiokxKGDNmNr6vzrmvgss7r5GtMxtHeQ1kdGth0ov4t6A=
X-Gm-Message-State: AOJu0YzXaQjVvbKHkvZ968XGDno5cdYrfG+WwFEDQiLf00gQ6rv8BIOU
	AB+t3YD4atl74kaIQ8aCOVXoI+91dX//CGeVOc8IFOTqec0S4bIZdr4aLS4QSh0=
X-Google-Smtp-Source: AGHT+IGtaXuoShfCIDYmL1J5mp4xw2LHubzR8vqOBE/a1j6DcfdiF8yQ/Kyw8I+8nzxEZ4cOZhCQdA==
X-Received: by 2002:a37:e10e:0:b0:78a:5fd1:f4e7 with SMTP id c14-20020a37e10e000000b0078a5fd1f4e7mr6091322qkm.53.1711550550306;
        Wed, 27 Mar 2024 07:42:30 -0700 (PDT)
Message-ID: <8fbb0ac1-e72b-4532-8d46-d79b751d8c96@citrix.com>
Date: Wed, 27 Mar 2024 14:42:27 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: preparations for 4.17.4
To: Jan Beulich 
Cc: Stefano Stabellini ,
 Anthony Perard , Julien Grall ,
 Kelly Choi ,
 "xen-devel@lists.xenproject.org" ,
 Christian Lindig , David Scott 
References: 
 <6feb56fe-769d-4809-b16f-6fc4d5477747@citrix.com>
 <93172b11-c737-400e-9d2e-daafee8f1cbc@citrix.com>
 
Content-Language: en-GB
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 27/03/2024 2:06 pm, Jan Beulich wrote:
> On 27.03.2024 15:01, Andrew Cooper wrote:
>> It occurs to me that these want considering:
>>
>> b6cf604207fd - tools/oxenstored: Use Map instead of Hashtbl for quotas
>> 098d868e52ac - tools/oxenstored: Make Quota.t pure
>>
>> while 4.17 is still in general support.  These came from a performance
>> regression we investigated.
>>
>> I've done the backport to 4.17 and they're not entirely trivial (owing
>> to the major source reformat in 4.18) so can commit them if you'd prefer.
> Didn't you bring these up for 4.18.1 already, and I said that I'd leave
> this for the maintainers to decide? Same here, in any event. Cc-ing them
> both, just in case.

I could have sworn that I remembered requested this before, but couldn't
remember where.

I'll see about poking people for an answer.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Mar 27 14:49:26 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 14:49:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698591.1090457 (Exim 4.92)
	(envelope-from )
	id 1rpUaf-0007Qk-Db; Wed, 27 Mar 2024 14:49:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698591.1090457; Wed, 27 Mar 2024 14:49:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpUaf-0007Qd-B1; Wed, 27 Mar 2024 14:49:21 +0000
Received: by outflank-mailman (input) for mailman id 698591;
 Wed, 27 Mar 2024 14:49:20 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpUae-0007PI-1F
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 14:49:20 +0000
Received: from NAM04-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam04on20601.outbound.protection.outlook.com
 [2a01:111:f403:240a::601])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2eedd0d3-ec49-11ee-a1ef-f123f15fe8a2;
 Wed, 27 Mar 2024 15:49:17 +0100 (CET)
Received: from SN4PR0501CA0117.namprd05.prod.outlook.com
 (2603:10b6:803:42::34) by SA0PR12MB4430.namprd12.prod.outlook.com
 (2603:10b6:806:70::20) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.32; Wed, 27 Mar
 2024 14:49:13 +0000
Received: from SN1PEPF0002BA4C.namprd03.prod.outlook.com
 (2603:10b6:803:42:cafe::3b) by SN4PR0501CA0117.outlook.office365.com
 (2603:10b6:803:42::34) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.12 via Frontend
 Transport; Wed, 27 Mar 2024 14:49:13 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SN1PEPF0002BA4C.mail.protection.outlook.com (10.167.242.69) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Wed, 27 Mar 2024 14:49:13 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Wed, 27 Mar
 2024 09:49:13 -0500
Received: from [172.31.131.34] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Wed, 27 Mar 2024 09:49:12 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2eedd0d3-ec49-11ee-a1ef-f123f15fe8a2
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=Cxcm2U7yMKvyD5NQ2xkcpDKE0Wi1mn/SgQ6z/+WVMUUURXM3lS5ehTnPldkf9gs8qNN/aChHZMm9YPnpBLbCccNYFKsb6YNF2fASyQmmNor2I8Wsvzc3/U5izeUXwfNj9lGBZhJjUxkUvIPW795c6fYhoZAmEpmhmk6f0EWvG1Fcn3RK+eJa+NUqMcht3601gsushdWWKd/NaQ6lGms2AFfctBp3l6i+7b/hOI+5WvBqu7/Kz2xOdO7OslGQoyhttQzlT0KTCnpkrA8pkCuGPDpUm+T+psedLJg1hlWxSMROwsf5ZWgYSNsyujTVhEgWEMDJH5lAJWCSIFsQt/2rGg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=O/wHybwKnqkOrPy2lrQ1gouZB8NQXFES5OR2FLFWALw=;
 b=npXxmG1vGBOBFHBIQRcRWGcRiDE1Y8QI/y+3vPbu04luyc02gzoR0okekGi723mbThNyI+eFlYa//w4d3kAA5P4HTbmKLLHzSWSFJpoK32Fm+3Q9UsOg6Yih9MgqPyyqVQdZehJ3MEucHV/fN4IouenT9GpQ0WFpRDQPa+gfaYKTWxTESqjSl4dmfQfFW6ZnQbg6x+cwHHp0t8TeyRqGjfJDn6ZIGbp34douTCTJmOTFFqLVMd/gwwjrRMvhcoAYOsgstlZAGzfZs1SOUEnySU4MXj0DWlssjykCo4jqwatFO70IhUY/Hj8Zesji/Uq77ZNquWwjBatCwCGQ+y0eeQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=O/wHybwKnqkOrPy2lrQ1gouZB8NQXFES5OR2FLFWALw=;
 b=FIsz+Q2r2hFWgepeWKXXgmX3ibpyMTY73Bbnhgqbg0rJ79niY8OP/7awrnWOD8kefPNmIrCJOGaPKF6jQWTnY6LXLT89K6NhhJFdR1B9GbYHnsSJrMaRsYh9kvOfEFgiXdEEJN4bT4+B3ZxAUNFvEVOnsrQ+1UrVxDxhwcHCmqQ=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Message-ID: <4dda0bc1-2ae0-462e-a8c2-aff74b9bbbf2@amd.com>
Date: Wed, 27 Mar 2024 10:49:13 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 1/6] Revert "xen/x86: bzImage parse kernel_alignment"
To: Jan Beulich 
CC: Andrew Cooper ,
	, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
	
References: <20240326213847.3944-1-jason.andryuk@amd.com>
 <20240326213847.3944-2-jason.andryuk@amd.com>
  
 <09c73d19-dda8-44a3-be4f-1644a2bd1a4c@amd.com>
 <92754a17-fe02-4050-9ca5-5a1ded3483dc@suse.com>
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: <92754a17-fe02-4050-9ca5-5a1ded3483dc@suse.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
Received-SPF: None (SATLEXMB04.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF0002BA4C:EE_|SA0PR12MB4430:EE_
X-MS-Office365-Filtering-Correlation-Id: 05b1323a-2575-447a-2830-08dc4e6d11c5
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	XwhsIeEILVhpu5Z8gMjFV+1XNUWGeeMnxi+OeoqLEFElljv7SHqTEBNz3hd854ivJU55GODN7yu9Km9CJzY7bR7j371q0NS2Jtv16kPKskgGfc6FrfiBv0KUmQbbpJjpjOwZJ3zzf+j/APzdsCpSV+spZ+oRJGWrSdM7RfZ1L1ggKV61TJDw0C6HTn+CF65y/Phdlghp4aqc4OIpwf286VElErPy0qGMAJ7Rk/OZnPcJQecAgPUSYgDhL4NJnbz5Nm5nqhiF6hnqFbTeMdM0mi3fZgdY4UiHMesE2EPUub0yyBkT5bijddFvcltoST7kG6/atCgocrPJaeVW3K745ltksxlTzi+f0G5tyVj/8HKzZYFBA2CipIwc6pbzwt18BcM5VlpWUBCS51zs8lquLXWK5H0JCxZm6aiFAIQPbfIaF5WzjzAU1NOERq5c9HJYmTYvDnLF6pSxaQa4Zn86PXTxS2exyPuHjD2uQchEstsoJIjJUh+ND/LZoJjT0AqXuE4V8iQTlAvZM0MnyLpsvc6CPKuHYSxAk2Pa+/a7uAdJOSZBkGEdcLNSorLXjfem4RefAVYI+ogCMWbb59TaJwqQcU1sZ19TTkNrDLRh8K5ekltY3JSR4Hzy2JKILeEFFonAiJTfMq9Kl/tD2+YYqW+R4yP3Tn0nPqhH+RV6RPAOhShDF4imlm9+jo8EvRnWEe6UuPo20Y7Gyc9FH7fdR70D6ul9+nw2qRVNMvbTYSqe/m7NdkL1GSAg74+aj47A
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(376005)(82310400014)(36860700004)(1800799015);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Mar 2024 14:49:13.5521
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 05b1323a-2575-447a-2830-08dc4e6d11c5
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF0002BA4C.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR12MB4430

On 2024-03-27 10:19, Jan Beulich wrote:
> On 27.03.2024 15:08, Jason Andryuk wrote:
>> On 2024-03-27 04:59, Roger Pau Monné wrote:
>>> On Wed, Mar 27, 2024 at 08:22:41AM +0100, Jan Beulich wrote:
>>>> On 26.03.2024 22:38, Jason Andryuk wrote:
>>>>> A new ELF note will specify the alignment for a relocatable PVH kernel.
>>>>> ELF notes are suitable for vmlinux and other ELF files, so this
>>>>> Linux-specific bzImage parsing in unnecessary.
>>>>>
>>>>> This reverts commit c44cac229067faeec8f49247d1cf281723ac2d40.
>>>>>
>>>>> Signed-off-by: Jason Andryuk 
>>>>
>>>> Since you keep re-sending this: In private discussion Roger has indicated
>>>> that, like me, he too would prefer falling back to the ELF data, before
>>>> falling back to the arch default (Roger, please correct me if I got it
>>>> wrong). That would make it necessary that the change you're proposing to
>>>> revert here is actually kept.
>>>
>>> Sorry, was meaning to reply yesterday but Jason is very fast at
>>> sending new version so I'm always one version behind.
>>
>> :)
>>
>> I was hoping to finish this up and get it in...
>>
>>> IMO the order: ELF note, PHDR alignment, arch default should be the
>>> preferred one.
>>>
>>>> Or wait - what you're reverting is taking the alignment out of the
>>>> bzImage header. I don't expect the BSDs to use that protocol; aiui that's
>>>> entirely Linux-specific.
>>>
>>> Yeah, I don't have strong opinions in keeping this, we already do
>>> bzImage parsing, so we might as well attempt to fetch the alignment
>>> from there if correct:
>>>
>>> ELF note, bzImage kernel_alignment, ELF PHDR alignment, arch default
>>
>> I'm not sure how to handle ELF PHDR vs. arch default.  ELF PHDR will
>> always be set, AFAIU.  Should that always be respected, which means we
>> don't need an arch default?
> 
> A value of 0 (and 1) is specifically permitted, to indicate no alignment.
> We may take 0 to mean default, but what you suggest below is another
> plausible approach. Yet another might be to take anything below PAGE_SIZE
> as "use default".
> 
>> To include arch default, it would be something like this:
>>
>>       if ( parms->phys_align != UNSET_ADDR )
>>           align = parms->phys_align;
>>       else if ( bz_align )
>>           align = bz_align;
> 
> Why do you include bz again here? Didn't you previously indicate the
> header field can't be relied upon? Which is also why, finally, I committed
> this revert earlier today.

Roger wanted to consult the bz value?  He mentioned it above.  Locally, 
I haven't synced with staging yet, and I dropped the revert to start 
re-working this...

If present, the bzImage header field is valid.  But being 
bzImage-specific, it isn't useful for other ELF files.  Xen will only 
move a kernel with the PHSY32_RELOC Note, so it can just specify an 
alignment if it needs to.

Personally, I think using the Note's value or a default is fine.  It 
seems like the PHDR aligment will just be 0x200000 anyway (for x86-64 at 
lease), which matches the default.  Specifying the PHYS32_RELOC Note, 
but relying on a search for the alignment, seems slightly questionable 
to me.

Still, it seemed like the path of least resistance is to just implement 
the fallback search like Roger requested.  Dropping the bzImage, I guess 
I'd go with your PAGE_SIZE suggestions for:

     if ( parms->phys_align != UNSET_ADDR )
         align = parms->phys_align;
     else if ( elf->palign > PAGE_SIZE )
         align = elf->palign;
     else
         align = PHYS32_RELOC_ALIGN_DEFAULT;

Thanks for your reviews.

Regards,
Jason


From xen-devel-bounces@lists.xenproject.org Wed Mar 27 15:11:41 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 15:11:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698596.1090468 (Exim 4.92)
	(envelope-from )
	id 1rpUw5-0004rC-BM; Wed, 27 Mar 2024 15:11:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698596.1090468; Wed, 27 Mar 2024 15:11:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpUw5-0004r5-7w; Wed, 27 Mar 2024 15:11:29 +0000
Received: by outflank-mailman (input) for mailman id 698596;
 Wed, 27 Mar 2024 15:11:28 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpUw3-0004pe-W9
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 15:11:28 +0000
Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com
 [2607:f8b0:4864:20::22d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 47378973-ec4c-11ee-a1ef-f123f15fe8a2;
 Wed, 27 Mar 2024 16:11:25 +0100 (CET)
Received: by mail-oi1-x22d.google.com with SMTP id
 5614622812f47-3bbbc6e51d0so4029052b6e.3
 for ; Wed, 27 Mar 2024 08:11:25 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 47378973-ec4c-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1711552284; x=1712157084; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=RYLFJKvrPbWM1nm93Sy2/N4e0Xdz2Sb0AN5azVWzbGo=;
        b=FBluUFs43cCEn91WdfkEhtzzmgVYvlDhfqDUyYtcFxIuCRQGqL2lpIhpoOWCbjP44i
         UGRNBdRk74X2JHdujia9TZJs1RT2PjgCa2nPHTCNO17R4zm6jTSoAz4EygDPCI1ecsvt
         N93wLL5ZOeAI5TKmB99NIYYRgdvfv9Q5tsQ1Y=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711552284; x=1712157084;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=RYLFJKvrPbWM1nm93Sy2/N4e0Xdz2Sb0AN5azVWzbGo=;
        b=brSDtDS8i/GRqx95krwLip46U7y+VD9f46sctm2HZmJ9QWXH+bJ+rATgkE6Kk0uvTg
         cyfoEz696s87HSeeYQvUG559iATntO+nDUfKPrJSyxNm36IK25hzwv9cqHzu2LZ7tFSG
         hvmWCIeNAsox3vXdlqk5W5S5grv7rKyVTJ9DU6nM8uyArtnqZNRwFn9Bgv328WuAnWbF
         veG5Y5QfQPIrL3BmL4eIiRVn4TCGuElOzTtuYuf5ZXtHQUvYXIwEly/3hWQBzhd76Faq
         9N0EYhSoLCyUGvxT3tdD4+kC55ydNA0rf3IjQqFgCQi8HDXKT4cMWd7iGLGchx96ocHc
         cJ4Q==
X-Gm-Message-State: AOJu0YzcrwSlgBIQKSxjMc7uD4uha4yYxXw2BROhet/A0tMltKPTOapl
	pZD1UU3smOJV33VjlfxKSniccpWvD3/5QirJcshojLHcrzfaw/sakiVIeEzPYi/TP0+pSCoZSIw
	0bXot6Z6Dr4PnG6tebqvcSzFelN5ECnPNg+GaNQ==
X-Google-Smtp-Source: AGHT+IHnu7QA6eocUrNTbEezhP4M0pi3STJtZqt74U8RTJx4uQZevElOOj9Lk2RcY65FOVCDKWT65d73Efki/NHVy5c=
X-Received: by 2002:a05:6808:13d0:b0:3c3:520b:d163 with SMTP id
 d16-20020a05680813d000b003c3520bd163mr221897oiw.49.1711552284669; Wed, 27 Mar
 2024 08:11:24 -0700 (PDT)
MIME-Version: 1.0
References: <20240226104829.1044479-1-andrew.cooper3@citrix.com>
In-Reply-To: <20240226104829.1044479-1-andrew.cooper3@citrix.com>
From: Edwin Torok 
Date: Wed, 27 Mar 2024 15:11:13 +0000
Message-ID: 
Subject: Re: [PATCH] tools/oxenstored: Re-format
To: Andrew Cooper 
Cc: Xen-devel , 
	Christian Lindig , Rob Hoes 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Feb 26, 2024 at 10:48=E2=80=AFAM Andrew Cooper
 wrote:
>
> Rerun make format.

Looks good, although not sure whether whitespace will be correctly
preserved in email, recommend using git to push the changes.
Reviewed-by: Edwin T=C3=B6r=C3=B6k 

>
> Signed-off-by: Andrew Cooper 
> ---
> CC: Christian Lindig 
> CC: Edwin T=C3=B6r=C3=B6k 
> CC: Rob Hoes 
> ---
>  tools/ocaml/xenstored/quota.ml | 16 ++++++++--------
>  1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/tools/ocaml/xenstored/quota.ml b/tools/ocaml/xenstored/quota=
.ml
> index 1f652040d898..082cd25f26fc 100644
> --- a/tools/ocaml/xenstored/quota.ml
> +++ b/tools/ocaml/xenstored/quota.ml
> @@ -55,13 +55,13 @@ let _check quota id size =3D
>      raise Data_too_big
>    );
>    if id > 0 then
> -  try
> -    let entry =3D DomidMap.find id quota.cur in
> -    if entry >=3D quota.maxent then (
> -      warn "domain %u cannot create entry: quota reached" id;
> -      raise Limit_reached
> -    )
> -  with Not_found -> ()
> +    try
> +      let entry =3D DomidMap.find id quota.cur in
> +      if entry >=3D quota.maxent then (
> +        warn "domain %u cannot create entry: quota reached" id;
> +        raise Limit_reached
> +      )
> +    with Not_found -> ()
>
>  let check quota id size =3D
>    if !activate then
> @@ -88,4 +88,4 @@ let merge orig_quota mod_quota dest_quota =3D
>      | diff -> update_entry dest id diff (* update with [x=3Dx+diff] *)
>    in
>    {dest_quota with cur =3D DomidMap.fold fold_merge mod_quota.cur dest_q=
uota.cur}
> -  (* dest_quota =3D dest_quota + (mod_quota - orig_quota) *)
> +(* dest_quota =3D dest_quota + (mod_quota - orig_quota) *)
>
> base-commit: 8de3afc0b402bc17f65093a53e5870862707a8c7
> --
> 2.30.2
>


From xen-devel-bounces@lists.xenproject.org Wed Mar 27 15:22:41 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 15:22:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698601.1090487 (Exim 4.92)
	(envelope-from )
	id 1rpV6v-0007gH-EE; Wed, 27 Mar 2024 15:22:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698601.1090487; Wed, 27 Mar 2024 15:22:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpV6v-0007gA-BP; Wed, 27 Mar 2024 15:22:41 +0000
Received: by outflank-mailman (input) for mailman id 698601;
 Wed, 27 Mar 2024 15:22:40 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpV6u-0007fn-EF
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 15:22:40 +0000
Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d84f055e-ec4d-11ee-a1ef-f123f15fe8a2;
 Wed, 27 Mar 2024 16:22:38 +0100 (CET)
Received: from imap2.dmz-prg2.suse.org (imap2.dmz-prg2.suse.org [10.150.64.98])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out2.suse.de (Postfix) with ESMTPS id CFEAA5FF5A;
 Wed, 27 Mar 2024 15:22:37 +0000 (UTC)
Received: from imap2.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap2.dmz-prg2.suse.org (Postfix) with ESMTPS id 53EBB13215;
 Wed, 27 Mar 2024 15:22:37 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap2.dmz-prg2.suse.org with ESMTPSA id enLTEr05BGZqfQAAn2gu4w
 (envelope-from ); Wed, 27 Mar 2024 15:22:37 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d84f055e-ec4d-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1711552957; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=HU+H+gC+IivP7v8BYwH4cbldKan0Qm9QDP70wtFCLOI=;
	b=MN9eZgY0qfMPhdRF/3BSZq9YkhkZG0013tMUplr8gu1JpUrBOvBmaGHCLJw/h3WsumyCJo
	DZGhOhlbKuzzRq98jkshXqFQramFzRda6bT67UfGuqUM9IdzkHEZoA1DFph2BwYSl3xKJK
	zQXPYE8kYC090+9hzeTantVavEd2kKs=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1711552957; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=HU+H+gC+IivP7v8BYwH4cbldKan0Qm9QDP70wtFCLOI=;
	b=MN9eZgY0qfMPhdRF/3BSZq9YkhkZG0013tMUplr8gu1JpUrBOvBmaGHCLJw/h3WsumyCJo
	DZGhOhlbKuzzRq98jkshXqFQramFzRda6bT67UfGuqUM9IdzkHEZoA1DFph2BwYSl3xKJK
	zQXPYE8kYC090+9hzeTantVavEd2kKs=
From: Juergen Gross 
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Tamas K Lengyel ,
	Lukasz Hawrylko ,
	"Daniel P. Smith" ,
	=?UTF-8?q?Mateusz=20M=C3=B3wka?= 
Subject: [PATCH v6 1/8] xen/spinlock: add explicit non-recursive locking functions
Date: Wed, 27 Mar 2024 16:22:22 +0100
Message-Id: <20240327152229.25847-2-jgross@suse.com>
X-Mailer: git-send-email 2.35.3
In-Reply-To: <20240327152229.25847-1-jgross@suse.com>
References: <20240327152229.25847-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Score: 8.80
X-Spamd-Result: default: False [8.80 / 50.00];
	 ARC_NA(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 BAYES_SPAM(5.10)[100.00%];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_MISSING_CHARSET(2.50)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 BROKEN_CONTENT_TYPE(1.50)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_SIGNED(0.00)[suse.com:s=susede1];
	 NEURAL_HAM_SHORT(-0.20)[-0.999];
	 RCPT_COUNT_TWELVE(0.00)[15];
	 MID_CONTAINS_FROM(1.00)[];
	 DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:email];
	 FUZZY_BLOCKED(0.00)[rspamd.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 RCVD_TLS_ALL(0.00)[]
X-Spam-Level: ********
Authentication-Results: smtp-out2.suse.de;
	none
X-Spam-Flag: NO

In order to prepare a type-safe recursive spinlock structure, add
explicitly non-recursive locking functions to be used for non-recursive
locking of spinlocks, which are used recursively, too.

Signed-off-by: Juergen Gross 
Acked-by: Jan Beulich 
---
V2:
- rename functions (Jan Beulich)
- get rid of !! in pcidevs_locked() (Jan Beulich)
V5:
- remove spurious change (Julien Grall)
- add nrspin_lock() description (Julien Grall)
---
 xen/arch/arm/mm.c             |  4 ++--
 xen/arch/x86/domain.c         | 12 ++++++------
 xen/arch/x86/mm.c             | 12 ++++++------
 xen/arch/x86/mm/mem_sharing.c |  8 ++++----
 xen/arch/x86/mm/p2m-pod.c     |  4 ++--
 xen/arch/x86/mm/p2m.c         |  4 ++--
 xen/arch/x86/tboot.c          |  4 ++--
 xen/common/domctl.c           |  4 ++--
 xen/common/grant_table.c      | 10 +++++-----
 xen/common/memory.c           |  4 ++--
 xen/common/numa.c             |  4 ++--
 xen/common/page_alloc.c       | 16 ++++++++--------
 xen/drivers/char/console.c    | 16 ++++++++--------
 xen/include/xen/spinlock.h    | 29 +++++++++++++++++++++++------
 14 files changed, 74 insertions(+), 57 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index b15a18a494..def939172c 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -105,7 +105,7 @@ void share_xen_page_with_guest(struct page_info *page, struct domain *d,
     if ( page_get_owner(page) == d )
         return;
 
-    spin_lock(&d->page_alloc_lock);
+    nrspin_lock(&d->page_alloc_lock);
 
     /*
      * The incremented type count pins as writable or read-only.
@@ -136,7 +136,7 @@ void share_xen_page_with_guest(struct page_info *page, struct domain *d,
         page_list_add_tail(page, &d->xenpage_list);
     }
 
-    spin_unlock(&d->page_alloc_lock);
+    nrspin_unlock(&d->page_alloc_lock);
 }
 
 int xenmem_add_to_physmap_one(
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index a11c55f921..33a2830d9d 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -212,7 +212,7 @@ void dump_pageframe_info(struct domain *d)
     {
         unsigned long total[MASK_EXTR(PGT_type_mask, PGT_type_mask) + 1] = {};
 
-        spin_lock(&d->page_alloc_lock);
+        nrspin_lock(&d->page_alloc_lock);
         page_list_for_each ( page, &d->page_list )
         {
             unsigned int index = MASK_EXTR(page->u.inuse.type_info,
@@ -231,13 +231,13 @@ void dump_pageframe_info(struct domain *d)
                    _p(mfn_x(page_to_mfn(page))),
                    page->count_info, page->u.inuse.type_info);
         }
-        spin_unlock(&d->page_alloc_lock);
+        nrspin_unlock(&d->page_alloc_lock);
     }
 
     if ( is_hvm_domain(d) )
         p2m_pod_dump_data(d);
 
-    spin_lock(&d->page_alloc_lock);
+    nrspin_lock(&d->page_alloc_lock);
 
     page_list_for_each ( page, &d->xenpage_list )
     {
@@ -253,7 +253,7 @@ void dump_pageframe_info(struct domain *d)
                page->count_info, page->u.inuse.type_info);
     }
 
-    spin_unlock(&d->page_alloc_lock);
+    nrspin_unlock(&d->page_alloc_lock);
 }
 
 void update_guest_memory_policy(struct vcpu *v,
@@ -2448,10 +2448,10 @@ int domain_relinquish_resources(struct domain *d)
             d->arch.auto_unmask = 0;
         }
 
-        spin_lock(&d->page_alloc_lock);
+        nrspin_lock(&d->page_alloc_lock);
         page_list_splice(&d->arch.relmem_list, &d->page_list);
         INIT_PAGE_LIST_HEAD(&d->arch.relmem_list);
-        spin_unlock(&d->page_alloc_lock);
+        nrspin_unlock(&d->page_alloc_lock);
 
     PROGRESS(xen):
 
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 62f5b811bb..b4d125db39 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -482,7 +482,7 @@ void share_xen_page_with_guest(struct page_info *page, struct domain *d,
 
     set_gpfn_from_mfn(mfn_x(page_to_mfn(page)), INVALID_M2P_ENTRY);
 
-    spin_lock(&d->page_alloc_lock);
+    nrspin_lock(&d->page_alloc_lock);
 
     /* The incremented type count pins as writable or read-only. */
     page->u.inuse.type_info =
@@ -502,7 +502,7 @@ void share_xen_page_with_guest(struct page_info *page, struct domain *d,
         page_list_add_tail(page, &d->xenpage_list);
     }
 
-    spin_unlock(&d->page_alloc_lock);
+    nrspin_unlock(&d->page_alloc_lock);
 }
 
 void make_cr3(struct vcpu *v, mfn_t mfn)
@@ -3597,11 +3597,11 @@ long do_mmuext_op(
             {
                 bool drop_ref;
 
-                spin_lock(&pg_owner->page_alloc_lock);
+                nrspin_lock(&pg_owner->page_alloc_lock);
                 drop_ref = (pg_owner->is_dying &&
                             test_and_clear_bit(_PGT_pinned,
                                                &page->u.inuse.type_info));
-                spin_unlock(&pg_owner->page_alloc_lock);
+                nrspin_unlock(&pg_owner->page_alloc_lock);
                 if ( drop_ref )
                 {
         pin_drop:
@@ -4424,7 +4424,7 @@ int steal_page(
      * that it might be upon return from alloc_domheap_pages with
      * MEMF_no_owner set.
      */
-    spin_lock(&d->page_alloc_lock);
+    nrspin_lock(&d->page_alloc_lock);
 
     BUG_ON(page->u.inuse.type_info & (PGT_count_mask | PGT_locked |
                                       PGT_pinned));
@@ -4436,7 +4436,7 @@ int steal_page(
     if ( !(memflags & MEMF_no_refcount) && !domain_adjust_tot_pages(d, -1) )
         drop_dom_ref = true;
 
-    spin_unlock(&d->page_alloc_lock);
+    nrspin_unlock(&d->page_alloc_lock);
 
     if ( unlikely(drop_dom_ref) )
         put_domain(d);
diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index f58576c702..da28266ef0 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -740,11 +740,11 @@ static int page_make_private(struct domain *d, struct page_info *page)
     if ( !get_page(page, dom_cow) )
         return -EINVAL;
 
-    spin_lock(&d->page_alloc_lock);
+    nrspin_lock(&d->page_alloc_lock);
 
     if ( d->is_dying )
     {
-        spin_unlock(&d->page_alloc_lock);
+        nrspin_unlock(&d->page_alloc_lock);
         put_page(page);
         return -EBUSY;
     }
@@ -752,7 +752,7 @@ static int page_make_private(struct domain *d, struct page_info *page)
     expected_type = (PGT_shared_page | PGT_validated | PGT_locked | 2);
     if ( page->u.inuse.type_info != expected_type )
     {
-        spin_unlock(&d->page_alloc_lock);
+        nrspin_unlock(&d->page_alloc_lock);
         put_page(page);
         return -EEXIST;
     }
@@ -769,7 +769,7 @@ static int page_make_private(struct domain *d, struct page_info *page)
     if ( domain_adjust_tot_pages(d, 1) == 1 )
         get_knownalive_domain(d);
     page_list_add_tail(page, &d->page_list);
-    spin_unlock(&d->page_alloc_lock);
+    nrspin_unlock(&d->page_alloc_lock);
 
     put_page(page);
 
diff --git a/xen/arch/x86/mm/p2m-pod.c b/xen/arch/x86/mm/p2m-pod.c
index 674f321cf6..c48ea169b7 100644
--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -27,7 +27,7 @@
 static always_inline void lock_page_alloc(struct p2m_domain *p2m)
 {
     page_alloc_mm_pre_lock(p2m->domain);
-    spin_lock(&(p2m->domain->page_alloc_lock));
+    nrspin_lock(&(p2m->domain->page_alloc_lock));
     page_alloc_mm_post_lock(p2m->domain,
                             p2m->domain->arch.page_alloc_unlock_level);
 }
@@ -35,7 +35,7 @@ static always_inline void lock_page_alloc(struct p2m_domain *p2m)
 static inline void unlock_page_alloc(struct p2m_domain *p2m)
 {
     page_alloc_mm_unlock(p2m->domain->arch.page_alloc_unlock_level);
-    spin_unlock(&(p2m->domain->page_alloc_lock));
+    nrspin_unlock(&(p2m->domain->page_alloc_lock));
 }
 
 /*
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 4c5a79eb53..ce742c12e0 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -2234,7 +2234,7 @@ void audit_p2m(struct domain *d,
 
     /* Audit part two: walk the domain's page allocation list, checking
      * the m2p entries. */
-    spin_lock(&d->page_alloc_lock);
+    nrspin_lock(&d->page_alloc_lock);
     page_list_for_each ( page, &d->page_list )
     {
         mfn = mfn_x(page_to_mfn(page));
@@ -2286,7 +2286,7 @@ void audit_p2m(struct domain *d,
         P2M_PRINTK("OK: mfn=%#lx, gfn=%#lx, p2mfn=%#lx\n",
                    mfn, gfn, mfn_x(p2mfn));
     }
-    spin_unlock(&d->page_alloc_lock);
+    nrspin_unlock(&d->page_alloc_lock);
 
     pod_unlock(p2m);
     p2m_unlock(p2m);
diff --git a/xen/arch/x86/tboot.c b/xen/arch/x86/tboot.c
index 4c254b4e34..ba0700d2d5 100644
--- a/xen/arch/x86/tboot.c
+++ b/xen/arch/x86/tboot.c
@@ -205,14 +205,14 @@ static void tboot_gen_domain_integrity(const uint8_t key[TB_KEY_SIZE],
             continue;
         printk("MACing Domain %u\n", d->domain_id);
 
-        spin_lock(&d->page_alloc_lock);
+        nrspin_lock(&d->page_alloc_lock);
         page_list_for_each(page, &d->page_list)
         {
             void *pg = __map_domain_page(page);
             vmac_update(pg, PAGE_SIZE, &ctx);
             unmap_domain_page(pg);
         }
-        spin_unlock(&d->page_alloc_lock);
+        nrspin_unlock(&d->page_alloc_lock);
 
         if ( is_iommu_enabled(d) && is_vtd )
         {
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index d94a9dae91..17d67651a7 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -621,14 +621,14 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
     {
         uint64_t new_max = op->u.max_mem.max_memkb >> (PAGE_SHIFT - 10);
 
-        spin_lock(&d->page_alloc_lock);
+        nrspin_lock(&d->page_alloc_lock);
         /*
          * NB. We removed a check that new_max >= current tot_pages; this means
          * that the domain will now be allowed to "ratchet" down to new_max. In
          * the meantime, while tot > max, all new allocations are disallowed.
          */
         d->max_pages = min(new_max, (uint64_t)(typeof(d->max_pages))-1);
-        spin_unlock(&d->page_alloc_lock);
+        nrspin_unlock(&d->page_alloc_lock);
         break;
     }
 
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 7708930882..e98e9da520 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -2376,7 +2376,7 @@ gnttab_transfer(
             mfn = page_to_mfn(page);
         }
 
-        spin_lock(&e->page_alloc_lock);
+        nrspin_lock(&e->page_alloc_lock);
 
         /*
          * Check that 'e' will accept the page and has reservation
@@ -2387,7 +2387,7 @@ gnttab_transfer(
              unlikely(domain_tot_pages(e) >= e->max_pages) ||
              unlikely(!(e->tot_pages + 1)) )
         {
-            spin_unlock(&e->page_alloc_lock);
+            nrspin_unlock(&e->page_alloc_lock);
 
             if ( e->is_dying )
                 gdprintk(XENLOG_INFO, "Transferee d%d is dying\n",
@@ -2411,7 +2411,7 @@ gnttab_transfer(
          * safely drop the lock and re-aquire it later to add page to the
          * pagelist.
          */
-        spin_unlock(&e->page_alloc_lock);
+        nrspin_unlock(&e->page_alloc_lock);
         okay = gnttab_prepare_for_transfer(e, d, gop.ref);
 
         /*
@@ -2427,9 +2427,9 @@ gnttab_transfer(
              * Need to grab this again to safely free our "reserved"
              * page in the page total
              */
-            spin_lock(&e->page_alloc_lock);
+            nrspin_lock(&e->page_alloc_lock);
             drop_dom_ref = !domain_adjust_tot_pages(e, -1);
-            spin_unlock(&e->page_alloc_lock);
+            nrspin_unlock(&e->page_alloc_lock);
 
             if ( okay /* i.e. e->is_dying due to the surrounding if() */ )
                 gdprintk(XENLOG_INFO, "Transferee d%d is now dying\n",
diff --git a/xen/common/memory.c b/xen/common/memory.c
index b3b05c2ec0..b4593f5f45 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -770,10 +770,10 @@ static long memory_exchange(XEN_GUEST_HANDLE_PARAM(xen_memory_exchange_t) arg)
                               (1UL << in_chunk_order)) -
                              (j * (1UL << exch.out.extent_order)));
 
-                spin_lock(&d->page_alloc_lock);
+                nrspin_lock(&d->page_alloc_lock);
                 drop_dom_ref = (dec_count &&
                                 !domain_adjust_tot_pages(d, -dec_count));
-                spin_unlock(&d->page_alloc_lock);
+                nrspin_unlock(&d->page_alloc_lock);
 
                 if ( drop_dom_ref )
                     put_domain(d);
diff --git a/xen/common/numa.c b/xen/common/numa.c
index 6374ba1721..28a09766fa 100644
--- a/xen/common/numa.c
+++ b/xen/common/numa.c
@@ -719,13 +719,13 @@ static void cf_check dump_numa(unsigned char key)
 
         memset(page_num_node, 0, sizeof(page_num_node));
 
-        spin_lock(&d->page_alloc_lock);
+        nrspin_lock(&d->page_alloc_lock);
         page_list_for_each ( page, &d->page_list )
         {
             i = page_to_nid(page);
             page_num_node[i]++;
         }
-        spin_unlock(&d->page_alloc_lock);
+        nrspin_unlock(&d->page_alloc_lock);
 
         for_each_online_node ( i )
             printk("    Node %u: %u\n", i, page_num_node[i]);
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index c94834d71b..4d6ce726e3 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -516,7 +516,7 @@ int domain_set_outstanding_pages(struct domain *d, unsigned long pages)
      * must always take the global heap_lock rather than only in the much
      * rarer case that d->outstanding_pages is non-zero
      */
-    spin_lock(&d->page_alloc_lock);
+    nrspin_lock(&d->page_alloc_lock);
     spin_lock(&heap_lock);
 
     /* pages==0 means "unset" the claim. */
@@ -562,7 +562,7 @@ int domain_set_outstanding_pages(struct domain *d, unsigned long pages)
 
 out:
     spin_unlock(&heap_lock);
-    spin_unlock(&d->page_alloc_lock);
+    nrspin_unlock(&d->page_alloc_lock);
     return ret;
 }
 
@@ -2348,7 +2348,7 @@ int assign_pages(
     int rc = 0;
     unsigned int i;
 
-    spin_lock(&d->page_alloc_lock);
+    nrspin_lock(&d->page_alloc_lock);
 
     if ( unlikely(d->is_dying) )
     {
@@ -2430,7 +2430,7 @@ int assign_pages(
     }
 
  out:
-    spin_unlock(&d->page_alloc_lock);
+    nrspin_unlock(&d->page_alloc_lock);
     return rc;
 }
 
@@ -2909,9 +2909,9 @@ mfn_t acquire_reserved_page(struct domain *d, unsigned int memflags)
     ASSERT_ALLOC_CONTEXT();
 
     /* Acquire a page from reserved page list(resv_page_list). */
-    spin_lock(&d->page_alloc_lock);
+    nrspin_lock(&d->page_alloc_lock);
     page = page_list_remove_head(&d->resv_page_list);
-    spin_unlock(&d->page_alloc_lock);
+    nrspin_unlock(&d->page_alloc_lock);
     if ( unlikely(!page) )
         return INVALID_MFN;
 
@@ -2930,9 +2930,9 @@ mfn_t acquire_reserved_page(struct domain *d, unsigned int memflags)
      */
     unprepare_staticmem_pages(page, 1, false);
  fail:
-    spin_lock(&d->page_alloc_lock);
+    nrspin_lock(&d->page_alloc_lock);
     page_list_add_tail(page, &d->resv_page_list);
-    spin_unlock(&d->page_alloc_lock);
+    nrspin_unlock(&d->page_alloc_lock);
     return INVALID_MFN;
 }
 #endif
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index ccd5f8cc14..22f50fc617 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -368,9 +368,9 @@ long read_console_ring(struct xen_sysctl_readconsole *op)
 
     if ( op->clear )
     {
-        spin_lock_irq(&console_lock);
+        nrspin_lock_irq(&console_lock);
         conringc = p - c > conring_size ? p - conring_size : c;
-        spin_unlock_irq(&console_lock);
+        nrspin_unlock_irq(&console_lock);
     }
 
     op->count = sofar;
@@ -638,7 +638,7 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer,
         if ( is_hardware_domain(cd) )
         {
             /* Use direct console output as it could be interactive */
-            spin_lock_irq(&console_lock);
+            nrspin_lock_irq(&console_lock);
 
             console_serial_puts(kbuf, kcount);
             video_puts(kbuf, kcount);
@@ -659,7 +659,7 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer,
                 tasklet_schedule(¬ify_dom0_con_ring_tasklet);
             }
 
-            spin_unlock_irq(&console_lock);
+            nrspin_unlock_irq(&console_lock);
         }
         else
         {
@@ -1026,9 +1026,9 @@ void __init console_init_preirq(void)
     pv_console_set_rx_handler(serial_rx);
 
     /* HELLO WORLD --- start-of-day banner text. */
-    spin_lock(&console_lock);
+    nrspin_lock(&console_lock);
     __putstr(xen_banner());
-    spin_unlock(&console_lock);
+    nrspin_unlock(&console_lock);
     printk("Xen version %d.%d%s (%s@%s) (%s) %s %s\n",
            xen_major_version(), xen_minor_version(), xen_extra_version(),
            xen_compile_by(), xen_compile_domain(), xen_compiler(),
@@ -1065,13 +1065,13 @@ void __init console_init_ring(void)
     }
     opt_conring_size = PAGE_SIZE << order;
 
-    spin_lock_irqsave(&console_lock, flags);
+    nrspin_lock_irqsave(&console_lock, flags);
     for ( i = conringc ; i != conringp; i++ )
         ring[i & (opt_conring_size - 1)] = conring[i & (conring_size - 1)];
     conring = ring;
     smp_wmb(); /* Allow users of console_force_unlock() to see larger buffer. */
     conring_size = opt_conring_size;
-    spin_unlock_irqrestore(&console_lock, flags);
+    nrspin_unlock_irqrestore(&console_lock, flags);
 
     printk("Allocated console ring of %u KiB.\n", opt_conring_size >> 10);
 }
diff --git a/xen/include/xen/spinlock.h b/xen/include/xen/spinlock.h
index 593cba640e..53a33653f9 100644
--- a/xen/include/xen/spinlock.h
+++ b/xen/include/xen/spinlock.h
@@ -102,6 +102,9 @@ struct lock_profile_qhead {
 };
 
 #define LOCK_PROFILE_(lockname) { .name = #lockname, .ptr.lock = &(lockname), }
+#define RLOCK_PROFILE_(lockname) { .name = #lockname,                         \
+                                   .ptr.rlock = &(lockname),                  \
+                                   .is_rlock = true, }
 #define LOCK_PROFILE_PTR_(name)                                               \
     static struct lock_profile * const lock_profile__##name                   \
     __used_section(".lockprofile.data") =                                     \
@@ -118,10 +121,10 @@ struct lock_profile_qhead {
     LOCK_PROFILE_PTR_(l)
 #define DEFINE_RSPINLOCK(l)                                                   \
     rspinlock_t l = SPIN_LOCK_UNLOCKED_(NULL);                                \
-    static struct lock_profile lock_profile_data__##l = LOCK_PROFILE_(l);     \
+    static struct lock_profile lock_profile_data__##l = RLOCK_PROFILE_(l);    \
     LOCK_PROFILE_PTR_(l)
 
-#define spin_lock_init_prof__(s, l, locktype)                                 \
+#define spin_lock_init_prof__(s, l, lockptr, locktype, isr)                   \
     do {                                                                      \
         struct lock_profile *prof;                                            \
         prof = xzalloc(struct lock_profile);                                  \
@@ -134,13 +137,16 @@ struct lock_profile_qhead {
             break;                                                            \
         }                                                                     \
         prof->name = #l;                                                      \
-        prof->ptr.lock = &(s)->l;                                             \
+        prof->ptr.lockptr = &(s)->l;                                          \
+        prof->is_rlock = isr;                                                 \
         prof->next = (s)->profile_head.elem_q;                                \
         (s)->profile_head.elem_q = prof;                                      \
     } while( 0 )
 
-#define spin_lock_init_prof(s, l) spin_lock_init_prof__(s, l, spinlock_t)
-#define rspin_lock_init_prof(s, l) spin_lock_init_prof__(s, l, rspinlock_t)
+#define spin_lock_init_prof(s, l)                                             \
+    spin_lock_init_prof__(s, l, lock, spinlock_t, false)
+#define rspin_lock_init_prof(s, l)                                            \
+    spin_lock_init_prof__(s, l, rlock, rspinlock_t, true)
 
 void _lock_profile_register_struct(
     int32_t type, struct lock_profile_qhead *qhead, int32_t idx);
@@ -274,7 +280,10 @@ static always_inline void spin_lock_if(bool condition, spinlock_t *l)
  * reentered recursively on the same CPU. All critical regions that may form
  * part of a recursively-nested set must be protected by these forms. If there
  * are any critical regions that cannot form part of such a set, they can use
- * standard spin_[un]lock().
+ * nrspin_[un]lock().
+ * The nrspin_[un]lock() forms act the same way as normal spin_[un]lock()
+ * calls, but operate on rspinlock_t locks. nrspin_lock() and rspin_lock()
+ * calls are blocking to each other for a specific lock even on the same cpu.
  */
 bool _rspin_trylock(rspinlock_t *lock);
 void _rspin_lock(rspinlock_t *lock);
@@ -298,4 +307,12 @@ static always_inline void rspin_lock(rspinlock_t *lock)
 #define rspin_unlock(l)               _rspin_unlock(l)
 #define rspin_unlock_irqrestore(l, f) _rspin_unlock_irqrestore(l, f)
 
+#define nrspin_trylock(l)    spin_trylock(l)
+#define nrspin_lock(l)       spin_lock(l)
+#define nrspin_unlock(l)     spin_unlock(l)
+#define nrspin_lock_irq(l)   spin_lock_irq(l)
+#define nrspin_unlock_irq(l) spin_unlock_irq(l)
+#define nrspin_lock_irqsave(l, f)      spin_lock_irqsave(l, f)
+#define nrspin_unlock_irqrestore(l, f) spin_unlock_irqrestore(l, f)
+
 #endif /* __SPINLOCK_H__ */
-- 
2.35.3



From xen-devel-bounces@lists.xenproject.org Wed Mar 27 15:22:42 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 15:22:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698600.1090477 (Exim 4.92)
	(envelope-from )
	id 1rpV6q-0007RC-7K; Wed, 27 Mar 2024 15:22:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698600.1090477; Wed, 27 Mar 2024 15:22:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpV6q-0007R5-4o; Wed, 27 Mar 2024 15:22:36 +0000
Received: by outflank-mailman (input) for mailman id 698600;
 Wed, 27 Mar 2024 15:22:34 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpV6o-0007Qx-MK
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 15:22:34 +0000
Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d51dba20-ec4d-11ee-afe3-a90da7624cb6;
 Wed, 27 Mar 2024 16:22:33 +0100 (CET)
Received: from imap2.dmz-prg2.suse.org (imap2.dmz-prg2.suse.org
 [IPv6:2a07:de40:b281:104:10:150:64:98])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out2.suse.de (Postfix) with ESMTPS id DF1E860602;
 Wed, 27 Mar 2024 15:22:31 +0000 (UTC)
Received: from imap2.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap2.dmz-prg2.suse.org (Postfix) with ESMTPS id 7015113215;
 Wed, 27 Mar 2024 15:22:31 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap2.dmz-prg2.suse.org with ESMTPSA id vpOxGbc5BGYvfQAAn2gu4w
 (envelope-from ); Wed, 27 Mar 2024 15:22:31 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d51dba20-ec4d-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1711552952; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:  content-transfer-encoding:content-transfer-encoding;
	bh=pifUM0kraadzecww9tuC3K3Y5gQQqgQ0xhazJDRrVmc=;
	b=BpBOZ4Tf30PC+J1hT33G3hyPiUjizHxIRME08mdubDmibNUoFYJDfoy9Hi1uzVyy8ZGox4
	JjdZjFWX2AFi3QIjI2IAgL13LNd01FvImctHQrXW0T65c+x7lSy+ETAZVt0ghollwQdq8w
	Z/xXeUWp4dlf/+xuTFtpHpgbP45RE2s=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1711552951; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:  content-transfer-encoding:content-transfer-encoding;
	bh=pifUM0kraadzecww9tuC3K3Y5gQQqgQ0xhazJDRrVmc=;
	b=rYyTdHb3kPtiG/tYPvYNaNJ9uVlUQqFNimUYZfKUcFcQEUSeABfXbdTDQFxuaofaBjQnD9
	ml6a1adBr9P92ZhzR3BnvW8UXw5Wms4xpmGgq2exWVTNQNZYbkxOCD72ddjdRSS1qv9IFF
	QOJcB5srAp2r4UuV6a2skJRu4t3Ah0c=
From: Juergen Gross 
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Tamas K Lengyel ,
	Lukasz Hawrylko ,
	"Daniel P. Smith" ,
	=?UTF-8?q?Mateusz=20M=C3=B3wka?= 
Subject: [PATCH v6 0/8] xen/spinlock: make recursive spinlocks a dedicated type
Date: Wed, 27 Mar 2024 16:22:21 +0100
Message-Id: <20240327152229.25847-1-jgross@suse.com>
X-Mailer: git-send-email 2.35.3
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Score: -1.51
X-Rspamd-Server: rspamd1.dmz-prg2.suse.org
X-Spam-Flag: NO
X-Spamd-Result: default: False [-1.51 / 50.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:106:10:150:64:167:received];
	 TO_DN_SOME(0.00)[];
	 R_MISSING_CHARSET(2.50)[];
	 BROKEN_CONTENT_TYPE(1.50)[];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_TRACE(0.00)[suse.com:+];
	 MX_GOOD(-0.01)[];
	 NEURAL_HAM_SHORT(-0.20)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 BAYES_HAM(-3.00)[100.00%];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[suse.com:s=susede1];
	 FROM_HAS_DN(0.00)[];
	 DWL_DNSWL_MED(-2.00)[suse.com:dkim];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 DKIM_SIGNED(0.00)[suse.com:s=susede1];
	 RCPT_COUNT_TWELVE(0.00)[15];
	 MID_CONTAINS_FROM(1.00)[];
	 DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:dkim];
	 FUZZY_BLOCKED(0.00)[rspamd.com];
	 RCVD_TLS_ALL(0.00)[];
	 RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:104:10:150:64:98:from]
X-Spam-Level: 
Authentication-Results: smtp-out2.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b=rYyTdHb3
X-Rspamd-Queue-Id: DF1E860602

Instead of being able to use normal spinlocks as recursive ones, too,
make recursive spinlocks a special lock type.

This will make the spinlock structure smaller in production builds and
add type-safety.

This allows to increase the maximum number of physical cpus from 4095
to 65535 without increasing the size of the lock structure in production
builds (the size of recursive spinlocks in debug builds will grow to
12 bytes due to that change).

Note that rwlock handling is still limiting the number of cpus to 4095,
this is being taken care off in patch 12, which raises the rwlock limit
to 16384 cpus.

Iommu code imposes a limit of 16383 cpus.

Changes in V2:
- addressed comments by Jan Beulich
- lots of additional cleanups
- reorganized complete series

Changes in V3:
- addressed comments by Jan Beulich

Changes in V4:
- former patch 1 has already been applied
- fixed a coding style issue in patch 1

Changes in V5:
- new patches 1 + 10 + 12 + 13
- due to the recent Ghost-race patches the macro layer for calling
  spinlock functions is kept
- addressed comments

Changes in V6:
- patches 1-5 of V5 have been committed already
- addressed comments

Juergen Gross (8):
  xen/spinlock: add explicit non-recursive locking functions
  xen/spinlock: add another function level
  xen/spinlock: add missing rspin_is_locked() and rspin_barrier()
  xen/spinlock: split recursive spinlocks from normal ones
  xen/spinlock: let all is_locked and trylock variants return bool
  xen/spinlock: support higher number of cpus
  xen/rwlock: raise the number of possible cpus
  xen: allow up to 16383 cpus

 xen/arch/Kconfig              |   2 +-
 xen/arch/arm/mm.c             |   4 +-
 xen/arch/x86/domain.c         |  12 +--
 xen/arch/x86/mm.c             |  12 +--
 xen/arch/x86/mm/mem_sharing.c |   8 +-
 xen/arch/x86/mm/p2m-pod.c     |   6 +-
 xen/arch/x86/mm/p2m.c         |   4 +-
 xen/arch/x86/tboot.c          |   4 +-
 xen/common/domain.c           |   2 +-
 xen/common/domctl.c           |   4 +-
 xen/common/grant_table.c      |  10 +-
 xen/common/memory.c           |   4 +-
 xen/common/numa.c             |   4 +-
 xen/common/page_alloc.c       |  18 ++--
 xen/common/spinlock.c         | 181 ++++++++++++++++++++++++++--------
 xen/drivers/char/console.c    |  20 ++--
 xen/drivers/passthrough/pci.c |   2 +-
 xen/include/xen/rwlock.h      |  23 +++--
 xen/include/xen/spinlock.h    | 110 ++++++++++++++++-----
 19 files changed, 297 insertions(+), 133 deletions(-)

-- 
2.35.3



From xen-devel-bounces@lists.xenproject.org Wed Mar 27 15:22:45 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 15:22:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698602.1090498 (Exim 4.92)
	(envelope-from )
	id 1rpV6z-0007yG-P8; Wed, 27 Mar 2024 15:22:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698602.1090498; Wed, 27 Mar 2024 15:22:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpV6z-0007y9-Ll; Wed, 27 Mar 2024 15:22:45 +0000
Received: by outflank-mailman (input) for mailman id 698602;
 Wed, 27 Mar 2024 15:22:44 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpV6y-0007Qx-KO
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 15:22:44 +0000
Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id dbacd412-ec4d-11ee-afe3-a90da7624cb6;
 Wed, 27 Mar 2024 16:22:44 +0100 (CET)
Received: from imap2.dmz-prg2.suse.org (imap2.dmz-prg2.suse.org
 [IPv6:2a07:de40:b281:104:10:150:64:98])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out2.suse.de (Postfix) with ESMTPS id 791595FF27;
 Wed, 27 Mar 2024 15:22:43 +0000 (UTC)
Received: from imap2.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap2.dmz-prg2.suse.org (Postfix) with ESMTPS id 3B6F213215;
 Wed, 27 Mar 2024 15:22:43 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap2.dmz-prg2.suse.org with ESMTPSA id 0sYKDcM5BGazfQAAn2gu4w
 (envelope-from ); Wed, 27 Mar 2024 15:22:43 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: dbacd412-ec4d-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1711552963; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=CNcfOxsm5v7RMnma3LjjKR0Cscie45Q1Vyko4FogwSU=;
	b=tmt8BiVpGRS9VE7HVpTowDPulIKHtD1qAhrexfIaueQDYMGV+UI8+ukvXI/sTkTj9Vuelv
	QKwYeqOTm0+aNmS+VNoi4LxOiI8FyZHC8xLVeMlVmGQNObWpZjl69z4fJ6l8xYplHy7ZZ7
	CEHnV8TBo75E1dJ2vxzf5lLDL303wqc=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1711552963; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=CNcfOxsm5v7RMnma3LjjKR0Cscie45Q1Vyko4FogwSU=;
	b=tmt8BiVpGRS9VE7HVpTowDPulIKHtD1qAhrexfIaueQDYMGV+UI8+ukvXI/sTkTj9Vuelv
	QKwYeqOTm0+aNmS+VNoi4LxOiI8FyZHC8xLVeMlVmGQNObWpZjl69z4fJ6l8xYplHy7ZZ7
	CEHnV8TBo75E1dJ2vxzf5lLDL303wqc=
From: Juergen Gross 
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini 
Subject: [PATCH v6 2/8] xen/spinlock: add another function level
Date: Wed, 27 Mar 2024 16:22:23 +0100
Message-Id: <20240327152229.25847-3-jgross@suse.com>
X-Mailer: git-send-email 2.35.3
In-Reply-To: <20240327152229.25847-1-jgross@suse.com>
References: <20240327152229.25847-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Score: -1.51
X-Rspamd-Server: rspamd1.dmz-prg2.suse.org
X-Spam-Flag: NO
X-Spamd-Result: default: False [-1.51 / 50.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:106:10:150:64:167:received];
	 TO_DN_SOME(0.00)[];
	 R_MISSING_CHARSET(2.50)[];
	 BROKEN_CONTENT_TYPE(1.50)[];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_TRACE(0.00)[suse.com:+];
	 MX_GOOD(-0.01)[];
	 RCPT_COUNT_SEVEN(0.00)[7];
	 NEURAL_HAM_SHORT(-0.20)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 BAYES_HAM(-3.00)[100.00%];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[suse.com:s=susede1];
	 FROM_HAS_DN(0.00)[];
	 DWL_DNSWL_MED(-2.00)[suse.com:dkim];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 DKIM_SIGNED(0.00)[suse.com:s=susede1];
	 MID_CONTAINS_FROM(1.00)[];
	 DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:dkim,suse.com:email];
	 FUZZY_BLOCKED(0.00)[rspamd.com];
	 RCVD_TLS_ALL(0.00)[];
	 RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:104:10:150:64:98:from]
X-Spam-Level: 
Authentication-Results: smtp-out2.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b=tmt8BiVp
X-Rspamd-Queue-Id: 791595FF27

Add another function level in spinlock.c hiding the spinlock_t layout
from the low level locking code.

This is done in preparation of introducing rspinlock_t for recursive
locks without having to duplicate all of the locking code.

Signed-off-by: Juergen Gross 
Reviewed-by: Jan Beulich 
---
V2:
- new patch
V5:
- don't regress spin_is_locked() for rspin-lock (Jan Beulich)
- use bool as return type of spin_is_locked_common() and
  spin_trylock_common() (Jan Beulich)
---
 xen/common/spinlock.c      | 103 ++++++++++++++++++++++++-------------
 xen/include/xen/spinlock.h |   1 +
 2 files changed, 68 insertions(+), 36 deletions(-)

diff --git a/xen/common/spinlock.c b/xen/common/spinlock.c
index 874ed762b4..648393d95f 100644
--- a/xen/common/spinlock.c
+++ b/xen/common/spinlock.c
@@ -261,29 +261,31 @@ void spin_debug_disable(void)
 
 #ifdef CONFIG_DEBUG_LOCK_PROFILE
 
+#define LOCK_PROFILE_PAR lock->profile
 #define LOCK_PROFILE_REL                                                     \
-    if ( lock->profile )                                                     \
+    if ( profile )                                                           \
     {                                                                        \
-        lock->profile->time_hold += NOW() - lock->profile->time_locked;      \
-        lock->profile->lock_cnt++;                                           \
+        profile->time_hold += NOW() - profile->time_locked;                  \
+        profile->lock_cnt++;                                                 \
     }
 #define LOCK_PROFILE_VAR(var, val)    s_time_t var = (val)
 #define LOCK_PROFILE_BLOCK(var)       var = var ? : NOW()
 #define LOCK_PROFILE_BLKACC(tst, val)                                        \
     if ( tst )                                                               \
     {                                                                        \
-        lock->profile->time_block += lock->profile->time_locked - (val);     \
-        lock->profile->block_cnt++;                                          \
+        profile->time_block += profile->time_locked - (val);                 \
+        profile->block_cnt++;                                                \
     }
 #define LOCK_PROFILE_GOT(val)                                                \
-    if ( lock->profile )                                                     \
+    if ( profile )                                                           \
     {                                                                        \
-        lock->profile->time_locked = NOW();                                  \
+        profile->time_locked = NOW();                                        \
         LOCK_PROFILE_BLKACC(val, val);                                       \
     }
 
 #else
 
+#define LOCK_PROFILE_PAR NULL
 #define LOCK_PROFILE_REL
 #define LOCK_PROFILE_VAR(var, val)
 #define LOCK_PROFILE_BLOCK(var)
@@ -307,17 +309,18 @@ static always_inline uint16_t observe_head(const spinlock_tickets_t *t)
     return read_atomic(&t->head);
 }
 
-static void always_inline spin_lock_common(spinlock_t *lock,
+static void always_inline spin_lock_common(spinlock_tickets_t *t,
+                                           union lock_debug *debug,
+                                           struct lock_profile *profile,
                                            void (*cb)(void *data), void *data)
 {
     spinlock_tickets_t tickets = SPINLOCK_TICKET_INC;
     LOCK_PROFILE_VAR(block, 0);
 
-    check_lock(&lock->debug, false);
+    check_lock(debug, false);
     preempt_disable();
-    tickets.head_tail = arch_fetch_and_add(&lock->tickets.head_tail,
-                                           tickets.head_tail);
-    while ( tickets.tail != observe_head(&lock->tickets) )
+    tickets.head_tail = arch_fetch_and_add(&t->head_tail, tickets.head_tail);
+    while ( tickets.tail != observe_head(t) )
     {
         LOCK_PROFILE_BLOCK(block);
         if ( cb )
@@ -325,18 +328,19 @@ static void always_inline spin_lock_common(spinlock_t *lock,
         arch_lock_relax();
     }
     arch_lock_acquire_barrier();
-    got_lock(&lock->debug);
+    got_lock(debug);
     LOCK_PROFILE_GOT(block);
 }
 
 void _spin_lock(spinlock_t *lock)
 {
-    spin_lock_common(lock, NULL, NULL);
+    spin_lock_common(&lock->tickets, &lock->debug, LOCK_PROFILE_PAR, NULL,
+                     NULL);
 }
 
 void _spin_lock_cb(spinlock_t *lock, void (*cb)(void *data), void *data)
 {
-    spin_lock_common(lock, cb, data);
+    spin_lock_common(&lock->tickets, &lock->debug, LOCK_PROFILE_PAR, cb, data);
 }
 
 void _spin_lock_irq(spinlock_t *lock)
@@ -355,16 +359,23 @@ unsigned long _spin_lock_irqsave(spinlock_t *lock)
     return flags;
 }
 
-void _spin_unlock(spinlock_t *lock)
+static void always_inline spin_unlock_common(spinlock_tickets_t *t,
+                                             union lock_debug *debug,
+                                             struct lock_profile *profile)
 {
     LOCK_PROFILE_REL;
-    rel_lock(&lock->debug);
+    rel_lock(debug);
     arch_lock_release_barrier();
-    add_sized(&lock->tickets.head, 1);
+    add_sized(&t->head, 1);
     arch_lock_signal();
     preempt_enable();
 }
 
+void _spin_unlock(spinlock_t *lock)
+{
+    spin_unlock_common(&lock->tickets, &lock->debug, LOCK_PROFILE_PAR);
+}
+
 void _spin_unlock_irq(spinlock_t *lock)
 {
     _spin_unlock(lock);
@@ -377,6 +388,11 @@ void _spin_unlock_irqrestore(spinlock_t *lock, unsigned long flags)
     local_irq_restore(flags);
 }
 
+static bool always_inline spin_is_locked_common(const spinlock_tickets_t *t)
+{
+    return t->head != t->tail;
+}
+
 int _spin_is_locked(const spinlock_t *lock)
 {
     /*
@@ -385,57 +401,70 @@ int _spin_is_locked(const spinlock_t *lock)
      * ASSERT()s and alike.
      */
     return lock->recurse_cpu == SPINLOCK_NO_CPU
-           ? lock->tickets.head != lock->tickets.tail
+           ? spin_is_locked_common(&lock->tickets)
            : lock->recurse_cpu == smp_processor_id();
 }
 
-int _spin_trylock(spinlock_t *lock)
+static bool always_inline spin_trylock_common(spinlock_tickets_t *t,
+                                              union lock_debug *debug,
+                                              struct lock_profile *profile)
 {
     spinlock_tickets_t old, new;
 
     preempt_disable();
-    check_lock(&lock->debug, true);
-    old = observe_lock(&lock->tickets);
+    check_lock(debug, true);
+    old = observe_lock(t);
     if ( old.head != old.tail )
     {
         preempt_enable();
-        return 0;
+        return false;
     }
     new = old;
     new.tail++;
-    if ( cmpxchg(&lock->tickets.head_tail,
-                 old.head_tail, new.head_tail) != old.head_tail )
+    if ( cmpxchg(&t->head_tail, old.head_tail, new.head_tail) != old.head_tail )
     {
         preempt_enable();
-        return 0;
+        return false;
     }
     /*
      * cmpxchg() is a full barrier so no need for an
      * arch_lock_acquire_barrier().
      */
-    got_lock(&lock->debug);
+    got_lock(debug);
     LOCK_PROFILE_GOT(0);
 
-    return 1;
+    return true;
 }
 
-void _spin_barrier(spinlock_t *lock)
+int _spin_trylock(spinlock_t *lock)
+{
+    return spin_trylock_common(&lock->tickets, &lock->debug, LOCK_PROFILE_PAR);
+}
+
+static void always_inline spin_barrier_common(spinlock_tickets_t *t,
+                                              union lock_debug *debug,
+                                              struct lock_profile *profile)
 {
     spinlock_tickets_t sample;
     LOCK_PROFILE_VAR(block, NOW());
 
-    check_barrier(&lock->debug);
+    check_barrier(debug);
     smp_mb();
-    sample = observe_lock(&lock->tickets);
+    sample = observe_lock(t);
     if ( sample.head != sample.tail )
     {
-        while ( observe_head(&lock->tickets) == sample.head )
+        while ( observe_head(t) == sample.head )
             arch_lock_relax();
-        LOCK_PROFILE_BLKACC(lock->profile, block);
+        LOCK_PROFILE_BLKACC(profile, block);
     }
     smp_mb();
 }
 
+void _spin_barrier(spinlock_t *lock)
+{
+    spin_barrier_common(&lock->tickets, &lock->debug, LOCK_PROFILE_PAR);
+}
+
 bool _rspin_trylock(rspinlock_t *lock)
 {
     unsigned int cpu = smp_processor_id();
@@ -448,7 +477,8 @@ bool _rspin_trylock(rspinlock_t *lock)
 
     if ( likely(lock->recurse_cpu != cpu) )
     {
-        if ( !_spin_trylock(lock) )
+        if ( !spin_trylock_common(&lock->tickets, &lock->debug,
+                                  LOCK_PROFILE_PAR) )
             return false;
         lock->recurse_cpu = cpu;
     }
@@ -466,7 +496,8 @@ void _rspin_lock(rspinlock_t *lock)
 
     if ( likely(lock->recurse_cpu != cpu) )
     {
-        _spin_lock(lock);
+        spin_lock_common(&lock->tickets, &lock->debug, LOCK_PROFILE_PAR, NULL,
+                         NULL);
         lock->recurse_cpu = cpu;
     }
 
@@ -490,7 +521,7 @@ void _rspin_unlock(rspinlock_t *lock)
     if ( likely(--lock->recurse_cnt == 0) )
     {
         lock->recurse_cpu = SPINLOCK_NO_CPU;
-        spin_unlock(lock);
+        spin_unlock_common(&lock->tickets, &lock->debug, LOCK_PROFILE_PAR);
     }
 }
 
diff --git a/xen/include/xen/spinlock.h b/xen/include/xen/spinlock.h
index 53a33653f9..8bc4652526 100644
--- a/xen/include/xen/spinlock.h
+++ b/xen/include/xen/spinlock.h
@@ -165,6 +165,7 @@ extern void cf_check spinlock_profile_reset(unsigned char key);
 #else
 
 struct lock_profile_qhead { };
+struct lock_profile { };
 
 #define SPIN_LOCK_UNLOCKED {                                                  \
     .recurse_cpu = SPINLOCK_NO_CPU,                                           \
-- 
2.35.3



From xen-devel-bounces@lists.xenproject.org Wed Mar 27 15:22:53 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 15:22:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698603.1090508 (Exim 4.92)
	(envelope-from )
	id 1rpV77-0008Kg-0T; Wed, 27 Mar 2024 15:22:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698603.1090508; Wed, 27 Mar 2024 15:22:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpV76-0008KX-TG; Wed, 27 Mar 2024 15:22:52 +0000
Received: by outflank-mailman (input) for mailman id 698603;
 Wed, 27 Mar 2024 15:22:51 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpV75-0007fn-A5
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 15:22:51 +0000
Received: from smtp-out2.suse.de (smtp-out2.suse.de
 [2a07:de40:b251:101:10:150:64:2])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id df0bfaac-ec4d-11ee-a1ef-f123f15fe8a2;
 Wed, 27 Mar 2024 16:22:49 +0100 (CET)
Received: from imap2.dmz-prg2.suse.org (imap2.dmz-prg2.suse.org
 [IPv6:2a07:de40:b281:104:10:150:64:98])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out2.suse.de (Postfix) with ESMTPS id 27D865FF27;
 Wed, 27 Mar 2024 15:22:49 +0000 (UTC)
Received: from imap2.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap2.dmz-prg2.suse.org (Postfix) with ESMTPS id DAD1213215;
 Wed, 27 Mar 2024 15:22:48 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap2.dmz-prg2.suse.org with ESMTPSA id Rwz7M8g5BGbofQAAn2gu4w
 (envelope-from ); Wed, 27 Mar 2024 15:22:48 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: df0bfaac-ec4d-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1711552969; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=vaZf67eZzfX4c/jDX5s3XwvN+K6C+pIsABHCTwjljXU=;
	b=TnOktoH4wn52MC1Ii+5fZ6E8ajjbpKEoiITkTzpwzcphi/z/bzdqYI/cGQJvNFpzCZI058
	TGCv8Bx5GMZukNx8pGJT/7SBGR0S3qlALerCXZPSW9vbRC+chUYPzFT5FlG9Wls2iiVu++
	QoAscnta7hBtmy65Hh+b7vU99XnQv9o=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1711552969; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=vaZf67eZzfX4c/jDX5s3XwvN+K6C+pIsABHCTwjljXU=;
	b=TnOktoH4wn52MC1Ii+5fZ6E8ajjbpKEoiITkTzpwzcphi/z/bzdqYI/cGQJvNFpzCZI058
	TGCv8Bx5GMZukNx8pGJT/7SBGR0S3qlALerCXZPSW9vbRC+chUYPzFT5FlG9Wls2iiVu++
	QoAscnta7hBtmy65Hh+b7vU99XnQv9o=
From: Juergen Gross 
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross ,
	Jan Beulich ,
	Andrew Cooper ,
	George Dunlap ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Julien Grall ,
	Stefano Stabellini 
Subject: [PATCH v6 3/8] xen/spinlock: add missing rspin_is_locked() and rspin_barrier()
Date: Wed, 27 Mar 2024 16:22:24 +0100
Message-Id: <20240327152229.25847-4-jgross@suse.com>
X-Mailer: git-send-email 2.35.3
In-Reply-To: <20240327152229.25847-1-jgross@suse.com>
References: <20240327152229.25847-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Level: 
Authentication-Results: smtp-out2.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b=TnOktoH4
X-Rspamd-Server: rspamd2.dmz-prg2.suse.org
X-Spamd-Result: default: False [-1.51 / 50.00];
	 ARC_NA(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 R_DKIM_ALLOW(-0.20)[suse.com:s=susede1];
	 SPAMHAUS_XBL(0.00)[2a07:de40:b281:104:10:150:64:98:from];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_MISSING_CHARSET(2.50)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 BROKEN_CONTENT_TYPE(1.50)[];
	 DWL_DNSWL_MED(-2.00)[suse.com:dkim];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_SIGNED(0.00)[suse.com:s=susede1];
	 DKIM_TRACE(0.00)[suse.com:+];
	 MX_GOOD(-0.01)[];
	 RCPT_COUNT_SEVEN(0.00)[8];
	 MID_CONTAINS_FROM(1.00)[];
	 DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:dkim,suse.com:email];
	 FUZZY_BLOCKED(0.00)[rspamd.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 NEURAL_HAM_SHORT(-0.20)[-1.000];
	 RCVD_TLS_ALL(0.00)[];
	 BAYES_HAM(-3.00)[100.00%]
X-Spam-Score: -1.51
X-Rspamd-Queue-Id: 27D865FF27
X-Spam-Flag: NO

Add rspin_is_locked() and rspin_barrier() in order to prepare differing
spinlock_t and rspinlock_t types.

Signed-off-by: Juergen Gross 
---
V2:
- partially carved out from V1 patch, partially new
V5:
- let rspin_is_locked() return bool (Jan Beulich)
V6:
- Re-add comment to _spin_is_locked() (Jan Beulich)
---
 xen/arch/x86/mm/p2m-pod.c     |  2 +-
 xen/common/domain.c           |  2 +-
 xen/common/page_alloc.c       |  2 +-
 xen/common/spinlock.c         | 26 ++++++++++++++++++++------
 xen/drivers/char/console.c    |  4 ++--
 xen/drivers/passthrough/pci.c |  2 +-
 xen/include/xen/spinlock.h    |  4 ++++
 7 files changed, 30 insertions(+), 12 deletions(-)

diff --git a/xen/arch/x86/mm/p2m-pod.c b/xen/arch/x86/mm/p2m-pod.c
index c48ea169b7..9750a3a21b 100644
--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -374,7 +374,7 @@ int p2m_pod_empty_cache(struct domain *d)
 
     /* After this barrier no new PoD activities can happen. */
     BUG_ON(!d->is_dying);
-    spin_barrier(&p2m->pod.lock.lock);
+    rspin_barrier(&p2m->pod.lock.lock);
 
     lock_page_alloc(p2m);
 
diff --git a/xen/common/domain.c b/xen/common/domain.c
index ceb44c8266..282c3ab623 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -991,7 +991,7 @@ int domain_kill(struct domain *d)
     case DOMDYING_alive:
         domain_pause(d);
         d->is_dying = DOMDYING_dying;
-        spin_barrier(&d->domain_lock);
+        rspin_barrier(&d->domain_lock);
         argo_destroy(d);
         vnuma_destroy(d->vnuma);
         domain_set_outstanding_pages(d, 0);
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 4d6ce726e3..7c1bdfc046 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -477,7 +477,7 @@ unsigned long domain_adjust_tot_pages(struct domain *d, long pages)
 {
     long dom_before, dom_after, dom_claimed, sys_before, sys_after;
 
-    ASSERT(spin_is_locked(&d->page_alloc_lock));
+    ASSERT(rspin_is_locked(&d->page_alloc_lock));
     d->tot_pages += pages;
 
     /*
diff --git a/xen/common/spinlock.c b/xen/common/spinlock.c
index 648393d95f..6572c76114 100644
--- a/xen/common/spinlock.c
+++ b/xen/common/spinlock.c
@@ -396,13 +396,10 @@ static bool always_inline spin_is_locked_common(const spinlock_tickets_t *t)
 int _spin_is_locked(const spinlock_t *lock)
 {
     /*
-     * Recursive locks may be locked by another CPU, yet we return
-     * "false" here, making this function suitable only for use in
-     * ASSERT()s and alike.
+     * This function is suitable only for use in ASSERT()s and alike, as it
+     * doesn't tell _who_ is holding the lock.
      */
-    return lock->recurse_cpu == SPINLOCK_NO_CPU
-           ? spin_is_locked_common(&lock->tickets)
-           : lock->recurse_cpu == smp_processor_id();
+    return spin_is_locked_common(&lock->tickets);
 }
 
 static bool always_inline spin_trylock_common(spinlock_tickets_t *t,
@@ -465,6 +462,23 @@ void _spin_barrier(spinlock_t *lock)
     spin_barrier_common(&lock->tickets, &lock->debug, LOCK_PROFILE_PAR);
 }
 
+bool _rspin_is_locked(const rspinlock_t *lock)
+{
+    /*
+     * Recursive locks may be locked by another CPU, yet we return
+     * "false" here, making this function suitable only for use in
+     * ASSERT()s and alike.
+     */
+    return lock->recurse_cpu == SPINLOCK_NO_CPU
+           ? spin_is_locked_common(&lock->tickets)
+           : lock->recurse_cpu == smp_processor_id();
+}
+
+void _rspin_barrier(rspinlock_t *lock)
+{
+    spin_barrier_common(&lock->tickets, &lock->debug, LOCK_PROFILE_PAR);
+}
+
 bool _rspin_trylock(rspinlock_t *lock)
 {
     unsigned int cpu = smp_processor_id();
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 22f50fc617..d5e6aacc27 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -327,7 +327,7 @@ static void cf_check do_dec_thresh(unsigned char key, bool unused)
 
 static void conring_puts(const char *str, size_t len)
 {
-    ASSERT(spin_is_locked(&console_lock));
+    ASSERT(rspin_is_locked(&console_lock));
 
     while ( len-- )
         conring[CONRING_IDX_MASK(conringp++)] = *str++;
@@ -765,7 +765,7 @@ static void __putstr(const char *str)
 {
     size_t len = strlen(str);
 
-    ASSERT(spin_is_locked(&console_lock));
+    ASSERT(rspin_is_locked(&console_lock));
 
     console_serial_puts(str, len);
     video_puts(str, len);
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 4fcc7e2cde..5a446d3dce 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -65,7 +65,7 @@ void pcidevs_unlock(void)
 
 bool pcidevs_locked(void)
 {
-    return !!spin_is_locked(&_pcidevs_lock);
+    return rspin_is_locked(&_pcidevs_lock);
 }
 
 static struct radix_tree_root pci_segments;
diff --git a/xen/include/xen/spinlock.h b/xen/include/xen/spinlock.h
index 8bc4652526..148be1e116 100644
--- a/xen/include/xen/spinlock.h
+++ b/xen/include/xen/spinlock.h
@@ -297,6 +297,8 @@ void _rspin_lock(rspinlock_t *lock);
 unsigned long _rspin_lock_irqsave(rspinlock_t *lock);
 void _rspin_unlock(rspinlock_t *lock);
 void _rspin_unlock_irqrestore(rspinlock_t *lock, unsigned long flags);
+bool _rspin_is_locked(const rspinlock_t *lock);
+void _rspin_barrier(rspinlock_t *lock);
 
 static always_inline void rspin_lock(rspinlock_t *lock)
 {
@@ -307,6 +309,8 @@ static always_inline void rspin_lock(rspinlock_t *lock)
 #define rspin_trylock(l)              lock_evaluate_nospec(_rspin_trylock(l))
 #define rspin_unlock(l)               _rspin_unlock(l)
 #define rspin_unlock_irqrestore(l, f) _rspin_unlock_irqrestore(l, f)
+#define rspin_barrier(l)              _rspin_barrier(l)
+#define rspin_is_locked(l)            _rspin_is_locked(l)
 
 #define nrspin_trylock(l)    spin_trylock(l)
 #define nrspin_lock(l)       spin_lock(l)
-- 
2.35.3



From xen-devel-bounces@lists.xenproject.org Wed Mar 27 15:22:57 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 15:22:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698604.1090518 (Exim 4.92)
	(envelope-from )
	id 1rpV7B-0000Id-Al; Wed, 27 Mar 2024 15:22:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698604.1090518; Wed, 27 Mar 2024 15:22:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpV7B-0000IU-74; Wed, 27 Mar 2024 15:22:57 +0000
Received: by outflank-mailman (input) for mailman id 698604;
 Wed, 27 Mar 2024 15:22:56 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpV7A-0007Qx-0p
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 15:22:56 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e26bc377-ec4d-11ee-afe3-a90da7624cb6;
 Wed, 27 Mar 2024 16:22:55 +0100 (CET)
Received: from imap2.dmz-prg2.suse.org (imap2.dmz-prg2.suse.org [10.150.64.98])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id C72AE38B5D;
 Wed, 27 Mar 2024 15:22:54 +0000 (UTC)
Received: from imap2.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap2.dmz-prg2.suse.org (Postfix) with ESMTPS id 892FB13215;
 Wed, 27 Mar 2024 15:22:54 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap2.dmz-prg2.suse.org with ESMTPSA id hSwEIM45BGYxfgAAn2gu4w
 (envelope-from ); Wed, 27 Mar 2024 15:22:54 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e26bc377-ec4d-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1711552974; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=SgUlnwwBECkoxNJznR++n3A26InW+paL4mR0WOpyZEc=;
	b=gwMCVjqS7PK6e7UcFJ+jujzCK+MptUD0Hp5A8HLzkvbVGsea0lam8JcEij1IPOlarwVpZn
	Z330MppBACterCCnPAPqJoxJA8F4BfzTXanFBYycFPh74nkmK+D5Eb59G0q6FdAV5LNKQv
	jFpCmLRFS6vk8vSMaxPuotNw2s7VGxk=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1711552974; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=SgUlnwwBECkoxNJznR++n3A26InW+paL4mR0WOpyZEc=;
	b=gwMCVjqS7PK6e7UcFJ+jujzCK+MptUD0Hp5A8HLzkvbVGsea0lam8JcEij1IPOlarwVpZn
	Z330MppBACterCCnPAPqJoxJA8F4BfzTXanFBYycFPh74nkmK+D5Eb59G0q6FdAV5LNKQv
	jFpCmLRFS6vk8vSMaxPuotNw2s7VGxk=
From: Juergen Gross 
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini 
Subject: [PATCH v6 4/8] xen/spinlock: split recursive spinlocks from normal ones
Date: Wed, 27 Mar 2024 16:22:25 +0100
Message-Id: <20240327152229.25847-5-jgross@suse.com>
X-Mailer: git-send-email 2.35.3
In-Reply-To: <20240327152229.25847-1-jgross@suse.com>
References: <20240327152229.25847-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.70
X-Spamd-Result: default: False [0.70 / 50.00];
	 ARC_NA(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_MISSING_CHARSET(2.50)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 BROKEN_CONTENT_TYPE(1.50)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_SIGNED(0.00)[suse.com:s=susede1];
	 NEURAL_HAM_SHORT(-0.20)[-1.000];
	 RCPT_COUNT_SEVEN(0.00)[7];
	 MID_CONTAINS_FROM(1.00)[];
	 DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:email];
	 FUZZY_BLOCKED(0.00)[rspamd.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 RCVD_TLS_ALL(0.00)[];
	 BAYES_HAM(-3.00)[100.00%]
X-Spam-Level: 
Authentication-Results: smtp-out1.suse.de;
	none
X-Spam-Flag: NO

Recursive and normal spinlocks are sharing the same data structure for
representation of the lock. This has two major disadvantages:

- it is not clear from the definition of a lock, whether it is intended
  to be used recursive or not, while a mixture of both usage variants
  needs to be

- in production builds (builds without CONFIG_DEBUG_LOCKS) the needed
  data size of an ordinary spinlock is 8 bytes instead of 4, due to the
  additional recursion data needed (associated with that the rwlock
  data is using 12 instead of only 8 bytes)

Fix that by introducing a struct spinlock_recursive for recursive
spinlocks only, and switch recursive spinlock functions to require
pointers to this new struct.

This allows to check the correct usage at build time.

Signed-off-by: Juergen Gross 
Reviewed-by: Jan Beulich 
---
V2:
- use shorter names (Jan Beulich)
- don't embed spinlock_t in rspinlock_t (Jan Beulich)
V5:
- some style fixes (Jan Beulich)
- bool instead of int (Jan Beulich)
---
 xen/common/spinlock.c      | 50 ++++++++++++++++++++++++++
 xen/include/xen/spinlock.h | 72 +++++++++++++++++++++++++++++---------
 2 files changed, 105 insertions(+), 17 deletions(-)

diff --git a/xen/common/spinlock.c b/xen/common/spinlock.c
index 6572c76114..5aaca49a61 100644
--- a/xen/common/spinlock.c
+++ b/xen/common/spinlock.c
@@ -545,6 +545,56 @@ void _rspin_unlock_irqrestore(rspinlock_t *lock, unsigned long flags)
     local_irq_restore(flags);
 }
 
+bool _nrspin_trylock(rspinlock_t *lock)
+{
+    check_lock(&lock->debug, true);
+
+    if ( unlikely(lock->recurse_cpu != SPINLOCK_NO_CPU) )
+        return false;
+
+    return spin_trylock_common(&lock->tickets, &lock->debug, LOCK_PROFILE_PAR);
+}
+
+void _nrspin_lock(rspinlock_t *lock)
+{
+    spin_lock_common(&lock->tickets, &lock->debug, LOCK_PROFILE_PAR, NULL,
+                     NULL);
+}
+
+void _nrspin_unlock(rspinlock_t *lock)
+{
+    spin_unlock_common(&lock->tickets, &lock->debug, LOCK_PROFILE_PAR);
+}
+
+void _nrspin_lock_irq(rspinlock_t *lock)
+{
+    ASSERT(local_irq_is_enabled());
+    local_irq_disable();
+    _nrspin_lock(lock);
+}
+
+void _nrspin_unlock_irq(rspinlock_t *lock)
+{
+    _nrspin_unlock(lock);
+    local_irq_enable();
+}
+
+unsigned long _nrspin_lock_irqsave(rspinlock_t *lock)
+{
+    unsigned long flags;
+
+    local_irq_save(flags);
+    _nrspin_lock(lock);
+
+    return flags;
+}
+
+void _nrspin_unlock_irqrestore(rspinlock_t *lock, unsigned long flags)
+{
+    _nrspin_unlock(lock);
+    local_irq_restore(flags);
+}
+
 #ifdef CONFIG_DEBUG_LOCK_PROFILE
 
 struct lock_profile_anc {
diff --git a/xen/include/xen/spinlock.h b/xen/include/xen/spinlock.h
index 148be1e116..f49ba928f0 100644
--- a/xen/include/xen/spinlock.h
+++ b/xen/include/xen/spinlock.h
@@ -77,8 +77,6 @@ union lock_debug { };
 */
 
 struct spinlock;
-/* Temporary hack until a dedicated struct rspinlock is existing. */
-#define rspinlock spinlock
 
 struct lock_profile {
     struct lock_profile *next;       /* forward link */
@@ -110,6 +108,10 @@ struct lock_profile_qhead {
     __used_section(".lockprofile.data") =                                     \
     &lock_profile_data__##name
 #define SPIN_LOCK_UNLOCKED_(x) {                                              \
+    .debug = LOCK_DEBUG_,                                                     \
+    .profile = x,                                                             \
+}
+#define RSPIN_LOCK_UNLOCKED_(x) {                                             \
     .recurse_cpu = SPINLOCK_NO_CPU,                                           \
     .debug = LOCK_DEBUG_,                                                     \
     .profile = x,                                                             \
@@ -119,8 +121,9 @@ struct lock_profile_qhead {
     spinlock_t l = SPIN_LOCK_UNLOCKED_(NULL);                                 \
     static struct lock_profile lock_profile_data__##l = LOCK_PROFILE_(l);     \
     LOCK_PROFILE_PTR_(l)
+#define RSPIN_LOCK_UNLOCKED RSPIN_LOCK_UNLOCKED_(NULL)
 #define DEFINE_RSPINLOCK(l)                                                   \
-    rspinlock_t l = SPIN_LOCK_UNLOCKED_(NULL);                                \
+    rspinlock_t l = RSPIN_LOCK_UNLOCKED_(NULL);                               \
     static struct lock_profile lock_profile_data__##l = RLOCK_PROFILE_(l);    \
     LOCK_PROFILE_PTR_(l)
 
@@ -145,8 +148,11 @@ struct lock_profile_qhead {
 
 #define spin_lock_init_prof(s, l)                                             \
     spin_lock_init_prof__(s, l, lock, spinlock_t, false)
-#define rspin_lock_init_prof(s, l)                                            \
-    spin_lock_init_prof__(s, l, rlock, rspinlock_t, true)
+#define rspin_lock_init_prof(s, l) do {                                       \
+        spin_lock_init_prof__(s, l, rlock, rspinlock_t, true);                \
+        (s)->l.recurse_cpu = SPINLOCK_NO_CPU;                                 \
+        (s)->l.recurse_cnt = 0;                                               \
+    } while (0)
 
 void _lock_profile_register_struct(
     int32_t type, struct lock_profile_qhead *qhead, int32_t idx);
@@ -168,11 +174,14 @@ struct lock_profile_qhead { };
 struct lock_profile { };
 
 #define SPIN_LOCK_UNLOCKED {                                                  \
+    .debug = LOCK_DEBUG_,                                                     \
+}
+#define RSPIN_LOCK_UNLOCKED {                                                 \
     .recurse_cpu = SPINLOCK_NO_CPU,                                           \
     .debug = LOCK_DEBUG_,                                                     \
 }
 #define DEFINE_SPINLOCK(l) spinlock_t l = SPIN_LOCK_UNLOCKED
-#define DEFINE_RSPINLOCK(l) rspinlock_t l = SPIN_LOCK_UNLOCKED
+#define DEFINE_RSPINLOCK(l) rspinlock_t l = RSPIN_LOCK_UNLOCKED
 
 #define spin_lock_init_prof(s, l) spin_lock_init(&((s)->l))
 #define rspin_lock_init_prof(s, l) rspin_lock_init(&((s)->l))
@@ -193,6 +202,14 @@ typedef union {
 #define SPINLOCK_TICKET_INC { .head_tail = 0x10000, }
 
 typedef struct spinlock {
+    spinlock_tickets_t tickets;
+    union lock_debug debug;
+#ifdef CONFIG_DEBUG_LOCK_PROFILE
+    struct lock_profile *profile;
+#endif
+} spinlock_t;
+
+typedef struct rspinlock {
     spinlock_tickets_t tickets;
     uint16_t recurse_cpu:SPINLOCK_CPU_BITS;
 #define SPINLOCK_NO_CPU        ((1u << SPINLOCK_CPU_BITS) - 1)
@@ -203,12 +220,10 @@ typedef struct spinlock {
 #ifdef CONFIG_DEBUG_LOCK_PROFILE
     struct lock_profile *profile;
 #endif
-} spinlock_t;
-
-typedef spinlock_t rspinlock_t;
+} rspinlock_t;
 
 #define spin_lock_init(l) (*(l) = (spinlock_t)SPIN_LOCK_UNLOCKED)
-#define rspin_lock_init(l) (*(l) = (rspinlock_t)SPIN_LOCK_UNLOCKED)
+#define rspin_lock_init(l) (*(l) = (rspinlock_t)RSPIN_LOCK_UNLOCKED)
 
 void _spin_lock(spinlock_t *lock);
 void _spin_lock_cb(spinlock_t *lock, void (*cb)(void *data), void *data);
@@ -312,12 +327,35 @@ static always_inline void rspin_lock(rspinlock_t *lock)
 #define rspin_barrier(l)              _rspin_barrier(l)
 #define rspin_is_locked(l)            _rspin_is_locked(l)
 
-#define nrspin_trylock(l)    spin_trylock(l)
-#define nrspin_lock(l)       spin_lock(l)
-#define nrspin_unlock(l)     spin_unlock(l)
-#define nrspin_lock_irq(l)   spin_lock_irq(l)
-#define nrspin_unlock_irq(l) spin_unlock_irq(l)
-#define nrspin_lock_irqsave(l, f)      spin_lock_irqsave(l, f)
-#define nrspin_unlock_irqrestore(l, f) spin_unlock_irqrestore(l, f)
+bool _nrspin_trylock(rspinlock_t *lock);
+void _nrspin_lock(rspinlock_t *lock);
+#define nrspin_lock_irqsave(l, f)                               \
+    ({                                                          \
+        BUILD_BUG_ON(sizeof(f) != sizeof(unsigned long));       \
+        (f) = _nrspin_lock_irqsave(l);                         \
+        block_lock_speculation();                               \
+    })
+unsigned long _nrspin_lock_irqsave(rspinlock_t *lock);
+void _nrspin_unlock(rspinlock_t *lock);
+void _nrspin_lock_irq(rspinlock_t *lock);
+void _nrspin_unlock_irq(rspinlock_t *lock);
+void _nrspin_unlock_irqrestore(rspinlock_t *lock, unsigned long flags);
+
+static always_inline void nrspin_lock(rspinlock_t *lock)
+{
+    _nrspin_lock(lock);
+    block_lock_speculation();
+}
+
+static always_inline void nrspin_lock_irq(rspinlock_t *l)
+{
+    _nrspin_lock_irq(l);
+    block_lock_speculation();
+}
+
+#define nrspin_trylock(l)              lock_evaluate_nospec(_nrspin_trylock(l))
+#define nrspin_unlock(l)               _nrspin_unlock(l)
+#define nrspin_unlock_irqrestore(l, f) _nrspin_unlock_irqrestore(l, f)
+#define nrspin_unlock_irq(l)           _nrspin_unlock_irq(l)
 
 #endif /* __SPINLOCK_H__ */
-- 
2.35.3



From xen-devel-bounces@lists.xenproject.org Wed Mar 27 15:23:03 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 15:23:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698606.1090528 (Exim 4.92)
	(envelope-from )
	id 1rpV7H-0000tg-Q2; Wed, 27 Mar 2024 15:23:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698606.1090528; Wed, 27 Mar 2024 15:23:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpV7H-0000s6-Jh; Wed, 27 Mar 2024 15:23:03 +0000
Received: by outflank-mailman (input) for mailman id 698606;
 Wed, 27 Mar 2024 15:23:02 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpV7G-0007fn-Br
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 15:23:02 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e5c9d67b-ec4d-11ee-a1ef-f123f15fe8a2;
 Wed, 27 Mar 2024 16:23:00 +0100 (CET)
Received: from imap2.dmz-prg2.suse.org (imap2.dmz-prg2.suse.org [10.150.64.98])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id 6AC1538B5C;
 Wed, 27 Mar 2024 15:23:00 +0000 (UTC)
Received: from imap2.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap2.dmz-prg2.suse.org (Postfix) with ESMTPS id 3075A13215;
 Wed, 27 Mar 2024 15:23:00 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap2.dmz-prg2.suse.org with ESMTPSA id 9IV1CtQ5BGZNfgAAn2gu4w
 (envelope-from ); Wed, 27 Mar 2024 15:23:00 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e5c9d67b-ec4d-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1711552980; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=c8cgLSy0wask2wusg5yB2CZKTJ/Nmqixk9O34STg5Eo=;
	b=SvsGD8lexVPB5vjcWzjfUkSBry2GtNCZ1NUCyiG7IJNtYS/JAMnu1TJqM/J/RaoEeEzwG6
	3LMuC+1MawWMZbEtFDRIIPSuRdi7olmjORl6ouQq8FAGT+S37E0mKJn4/nrI79oNOCiyaT
	8Q0BkBIRKMYtLrLV4NehG6dk9Rx5YaU=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1711552980; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=c8cgLSy0wask2wusg5yB2CZKTJ/Nmqixk9O34STg5Eo=;
	b=SvsGD8lexVPB5vjcWzjfUkSBry2GtNCZ1NUCyiG7IJNtYS/JAMnu1TJqM/J/RaoEeEzwG6
	3LMuC+1MawWMZbEtFDRIIPSuRdi7olmjORl6ouQq8FAGT+S37E0mKJn4/nrI79oNOCiyaT
	8Q0BkBIRKMYtLrLV4NehG6dk9Rx5YaU=
From: Juergen Gross 
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini 
Subject: [PATCH v6 5/8] xen/spinlock: let all is_locked and trylock variants return bool
Date: Wed, 27 Mar 2024 16:22:26 +0100
Message-Id: <20240327152229.25847-6-jgross@suse.com>
X-Mailer: git-send-email 2.35.3
In-Reply-To: <20240327152229.25847-1-jgross@suse.com>
References: <20240327152229.25847-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Authentication-Results: smtp-out1.suse.de;
	none
X-Spam-Level: ***
X-Spam-Score: 3.70
X-Spamd-Result: default: False [3.70 / 50.00];
	 ARC_NA(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_MISSING_CHARSET(2.50)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 BROKEN_CONTENT_TYPE(1.50)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_SIGNED(0.00)[suse.com:s=susede1];
	 NEURAL_HAM_SHORT(-0.20)[-1.000];
	 RCPT_COUNT_SEVEN(0.00)[7];
	 MID_CONTAINS_FROM(1.00)[];
	 DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:email];
	 FUZZY_BLOCKED(0.00)[rspamd.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 RCVD_TLS_ALL(0.00)[]
X-Spam-Flag: NO

Switch the remaining trylock and is_locked variants to return bool.

Signed-off-by: Juergen Gross 
Reviewed-by: Jan Beulich 
---
V5:
- new patch (Jan Beulich)
---
 xen/common/spinlock.c      | 4 ++--
 xen/include/xen/spinlock.h | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/xen/common/spinlock.c b/xen/common/spinlock.c
index 5aaca49a61..7ccb725171 100644
--- a/xen/common/spinlock.c
+++ b/xen/common/spinlock.c
@@ -393,7 +393,7 @@ static bool always_inline spin_is_locked_common(const spinlock_tickets_t *t)
     return t->head != t->tail;
 }
 
-int _spin_is_locked(const spinlock_t *lock)
+bool _spin_is_locked(const spinlock_t *lock)
 {
     /*
      * This function is suitable only for use in ASSERT()s and alike, as it
@@ -433,7 +433,7 @@ static bool always_inline spin_trylock_common(spinlock_tickets_t *t,
     return true;
 }
 
-int _spin_trylock(spinlock_t *lock)
+bool _spin_trylock(spinlock_t *lock)
 {
     return spin_trylock_common(&lock->tickets, &lock->debug, LOCK_PROFILE_PAR);
 }
diff --git a/xen/include/xen/spinlock.h b/xen/include/xen/spinlock.h
index f49ba928f0..3a4092626c 100644
--- a/xen/include/xen/spinlock.h
+++ b/xen/include/xen/spinlock.h
@@ -234,8 +234,8 @@ void _spin_unlock(spinlock_t *lock);
 void _spin_unlock_irq(spinlock_t *lock);
 void _spin_unlock_irqrestore(spinlock_t *lock, unsigned long flags);
 
-int _spin_is_locked(const spinlock_t *lock);
-int _spin_trylock(spinlock_t *lock);
+bool _spin_is_locked(const spinlock_t *lock);
+bool _spin_trylock(spinlock_t *lock);
 void _spin_barrier(spinlock_t *lock);
 
 static always_inline void spin_lock(spinlock_t *l)
-- 
2.35.3



From xen-devel-bounces@lists.xenproject.org Wed Mar 27 15:23:09 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 15:23:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698608.1090538 (Exim 4.92)
	(envelope-from )
	id 1rpV7N-0001ON-1p; Wed, 27 Mar 2024 15:23:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698608.1090538; Wed, 27 Mar 2024 15:23:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpV7M-0001OE-TK; Wed, 27 Mar 2024 15:23:08 +0000
Received: by outflank-mailman (input) for mailman id 698608;
 Wed, 27 Mar 2024 15:23:07 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpV7K-0007Qx-V9
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 15:23:06 +0000
Received: from smtp-out2.suse.de (smtp-out2.suse.de
 [2a07:de40:b251:101:10:150:64:2])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e9177cc7-ec4d-11ee-afe3-a90da7624cb6;
 Wed, 27 Mar 2024 16:23:06 +0100 (CET)
Received: from imap2.dmz-prg2.suse.org (imap2.dmz-prg2.suse.org [10.150.64.98])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out2.suse.de (Postfix) with ESMTPS id 0E8FD20CDD;
 Wed, 27 Mar 2024 15:23:06 +0000 (UTC)
Received: from imap2.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap2.dmz-prg2.suse.org (Postfix) with ESMTPS id C747A13215;
 Wed, 27 Mar 2024 15:23:05 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap2.dmz-prg2.suse.org with ESMTPSA id qHk9L9k5BGZafgAAn2gu4w
 (envelope-from ); Wed, 27 Mar 2024 15:23:05 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e9177cc7-ec4d-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1711552986; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=BqLZjhhBHT3mnXz0DltiWo9mb+SXQAswcBtFsIHNjqU=;
	b=eCXUM4ctFmRMh/J+LAGK+4e1y6KxkqEmjC1ysplW7YQaysPSYjXGtyhqKUD1gvSekLojS1
	0OBAg7wu6A+GkGTa26PDu6zJer/uDcsAX2adBHRNJGOXA1RrDK6pZ16WetQp//PapgewKy
	0O83/8aW6LWvhU/Wi0CV0c7dPXKkSJc=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1711552986; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=BqLZjhhBHT3mnXz0DltiWo9mb+SXQAswcBtFsIHNjqU=;
	b=eCXUM4ctFmRMh/J+LAGK+4e1y6KxkqEmjC1ysplW7YQaysPSYjXGtyhqKUD1gvSekLojS1
	0OBAg7wu6A+GkGTa26PDu6zJer/uDcsAX2adBHRNJGOXA1RrDK6pZ16WetQp//PapgewKy
	0O83/8aW6LWvhU/Wi0CV0c7dPXKkSJc=
From: Juergen Gross 
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini 
Subject: [PATCH v6 6/8] xen/spinlock: support higher number of cpus
Date: Wed, 27 Mar 2024 16:22:27 +0100
Message-Id: <20240327152229.25847-7-jgross@suse.com>
X-Mailer: git-send-email 2.35.3
In-Reply-To: <20240327152229.25847-1-jgross@suse.com>
References: <20240327152229.25847-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Score: 3.70
X-Spamd-Result: default: False [3.70 / 50.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_MISSING_CHARSET(2.50)[];
	 BROKEN_CONTENT_TYPE(1.50)[];
	 RCVD_COUNT_THREE(0.00)[3];
	 NEURAL_HAM_SHORT(-0.20)[-1.000];
	 RCPT_COUNT_SEVEN(0.00)[7];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ARC_NA(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 DKIM_SIGNED(0.00)[suse.com:s=susede1];
	 MID_CONTAINS_FROM(1.00)[];
	 DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:email];
	 FUZZY_BLOCKED(0.00)[rspamd.com];
	 RCVD_TLS_ALL(0.00)[]
X-Spam-Level: ***
Authentication-Results: smtp-out2.suse.de;
	none
X-Spam-Flag: NO

Allow 16 bits per cpu number, which is the limit imposed by
spinlock_tickets_t.

This will allow up to 65535 cpus, while increasing only the size of
recursive spinlocks in debug builds from 8 to 12 bytes.

The current Xen limit of 4095 cpus is imposed by SPINLOCK_CPU_BITS
being 12. There are machines available with more cpus than the current
Xen limit, so it makes sense to have the possibility to use more cpus.

Signed-off-by: Juergen Gross 
---
V5:
- keep previous recursion limit (Julien Grall)
V6:
- use unsigned int instead of uint32_t (Jan Beulich)
---
 xen/common/spinlock.c      |  2 ++
 xen/include/xen/spinlock.h | 20 ++++++++++----------
 2 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/xen/common/spinlock.c b/xen/common/spinlock.c
index 7ccb725171..5aa9ba6188 100644
--- a/xen/common/spinlock.c
+++ b/xen/common/spinlock.c
@@ -485,7 +485,9 @@ bool _rspin_trylock(rspinlock_t *lock)
 
     /* Don't allow overflow of recurse_cpu field. */
     BUILD_BUG_ON(NR_CPUS > SPINLOCK_NO_CPU);
+    BUILD_BUG_ON(SPINLOCK_CPU_BITS > sizeof(lock->recurse_cpu) * 8);
     BUILD_BUG_ON(SPINLOCK_RECURSE_BITS < 3);
+    BUILD_BUG_ON(SPINLOCK_MAX_RECURSE > ((1u << SPINLOCK_RECURSE_BITS) - 1));
 
     check_lock(&lock->debug, true);
 
diff --git a/xen/include/xen/spinlock.h b/xen/include/xen/spinlock.h
index 3a4092626c..db00a24646 100644
--- a/xen/include/xen/spinlock.h
+++ b/xen/include/xen/spinlock.h
@@ -8,16 +8,16 @@
 #include 
 #include 
 
-#define SPINLOCK_CPU_BITS  12
+#define SPINLOCK_CPU_BITS  16
 
 #ifdef CONFIG_DEBUG_LOCKS
 union lock_debug {
-    uint16_t val;
-#define LOCK_DEBUG_INITVAL 0xffff
+    uint32_t val;
+#define LOCK_DEBUG_INITVAL 0xffffffff
     struct {
-        uint16_t cpu:SPINLOCK_CPU_BITS;
-#define LOCK_DEBUG_PAD_BITS (14 - SPINLOCK_CPU_BITS)
-        uint16_t :LOCK_DEBUG_PAD_BITS;
+        unsigned int cpu:SPINLOCK_CPU_BITS;
+#define LOCK_DEBUG_PAD_BITS (30 - SPINLOCK_CPU_BITS)
+        unsigned int :LOCK_DEBUG_PAD_BITS;
         bool irq_safe:1;
         bool unseen:1;
     };
@@ -211,11 +211,11 @@ typedef struct spinlock {
 
 typedef struct rspinlock {
     spinlock_tickets_t tickets;
-    uint16_t recurse_cpu:SPINLOCK_CPU_BITS;
+    uint16_t recurse_cpu;
 #define SPINLOCK_NO_CPU        ((1u << SPINLOCK_CPU_BITS) - 1)
-#define SPINLOCK_RECURSE_BITS  (16 - SPINLOCK_CPU_BITS)
-    uint16_t recurse_cnt:SPINLOCK_RECURSE_BITS;
-#define SPINLOCK_MAX_RECURSE   ((1u << SPINLOCK_RECURSE_BITS) - 1)
+#define SPINLOCK_RECURSE_BITS  8
+    uint8_t recurse_cnt;
+#define SPINLOCK_MAX_RECURSE   15
     union lock_debug debug;
 #ifdef CONFIG_DEBUG_LOCK_PROFILE
     struct lock_profile *profile;
-- 
2.35.3



From xen-devel-bounces@lists.xenproject.org Wed Mar 27 15:23:13 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 15:23:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698613.1090548 (Exim 4.92)
	(envelope-from )
	id 1rpV7R-0001nr-8u; Wed, 27 Mar 2024 15:23:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698613.1090548; Wed, 27 Mar 2024 15:23:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpV7R-0001ng-5D; Wed, 27 Mar 2024 15:23:13 +0000
Received: by outflank-mailman (input) for mailman id 698613;
 Wed, 27 Mar 2024 15:23:12 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpV7Q-0007Qx-PB
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 15:23:12 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ec779207-ec4d-11ee-afe3-a90da7624cb6;
 Wed, 27 Mar 2024 16:23:12 +0100 (CET)
Received: from imap2.dmz-prg2.suse.org (imap2.dmz-prg2.suse.org
 [IPv6:2a07:de40:b281:104:10:150:64:98])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id A84AC38B63;
 Wed, 27 Mar 2024 15:23:11 +0000 (UTC)
Received: from imap2.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap2.dmz-prg2.suse.org (Postfix) with ESMTPS id 6FBC813215;
 Wed, 27 Mar 2024 15:23:11 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap2.dmz-prg2.suse.org with ESMTPSA id +KvmGd85BGaWfgAAn2gu4w
 (envelope-from ); Wed, 27 Mar 2024 15:23:11 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ec779207-ec4d-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1711552991; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=oXjtiiPFLzYFznlWn/C8ZCBcRUde7S7BFmz8pb92S3c=;
	b=YFINieC/XziGqNKvYCJxQsWesX9OVovupGp2FPfPA9gmhSpr5N84y4kzTsF4iZbAptFuUZ
	xtciKUEtp8KiqhKSYoUn+5m9GIXPXHJHy5ymQYP7rr5g4qPH1mOjC2UQu4MCS24jiPq5Ev
	HOHWXU2XLs9a1zTsQX62+JfG6jEJQ5c=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1711552991; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=oXjtiiPFLzYFznlWn/C8ZCBcRUde7S7BFmz8pb92S3c=;
	b=YFINieC/XziGqNKvYCJxQsWesX9OVovupGp2FPfPA9gmhSpr5N84y4kzTsF4iZbAptFuUZ
	xtciKUEtp8KiqhKSYoUn+5m9GIXPXHJHy5ymQYP7rr5g4qPH1mOjC2UQu4MCS24jiPq5Ev
	HOHWXU2XLs9a1zTsQX62+JfG6jEJQ5c=
From: Juergen Gross 
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini 
Subject: [PATCH v6 7/8] xen/rwlock: raise the number of possible cpus
Date: Wed, 27 Mar 2024 16:22:28 +0100
Message-Id: <20240327152229.25847-8-jgross@suse.com>
X-Mailer: git-send-email 2.35.3
In-Reply-To: <20240327152229.25847-1-jgross@suse.com>
References: <20240327152229.25847-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Score: 1.49
X-Spam-Flag: NO
X-Spamd-Bar: +
Authentication-Results: smtp-out1.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b="YFINieC/"
X-Spamd-Result: default: False [1.49 / 50.00];
	 ARC_NA(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 R_DKIM_ALLOW(-0.20)[suse.com:s=susede1];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_MISSING_CHARSET(2.50)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 BROKEN_CONTENT_TYPE(1.50)[];
	 DWL_DNSWL_MED(-2.00)[suse.com:dkim];
	 NEURAL_HAM_SHORT(-0.20)[-1.000];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_SIGNED(0.00)[suse.com:s=susede1];
	 DKIM_TRACE(0.00)[suse.com:+];
	 MX_GOOD(-0.01)[];
	 RCPT_COUNT_SEVEN(0.00)[7];
	 MID_CONTAINS_FROM(1.00)[];
	 DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:dkim,suse.com:email];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 FUZZY_BLOCKED(0.00)[rspamd.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:106:10:150:64:167:received];
	 RCVD_TLS_ALL(0.00)[];
	 RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:104:10:150:64:98:from]
X-Spam-Level: *
X-Rspamd-Server: rspamd1.dmz-prg2.suse.org
X-Rspamd-Queue-Id: A84AC38B63

The rwlock handling is limiting the number of cpus to 4095 today. The
main reason is the use of the atomic_t data type for the main lock
handling, which needs 2 bits for the locking state (writer waiting or
write locked), 12 bits for the id of a possible writer, and a 12 bit
counter for readers. The limit isn't 4096 due to an off by one sanity
check.

The atomic_t data type is 32 bits wide, so in theory 15 bits for the
writer's cpu id and 15 bits for the reader count seem to be fine, but
via read_trylock() more readers than cpus are possible.

This means that it is possible to raise the number of cpus to 16384
without changing the rwlock_t data structure. In order to avoid the
reader count wrapping to zero, don't let read_trylock() succeed in case
the highest bit of the reader's count is set already. This leaves enough
headroom for non-recursive readers to enter without risking a wrap.

While at it calculate _QW_CPUMASK and _QR_SHIFT from _QW_SHIFT and
add a sanity check for not overflowing the atomic_t data type.

Signed-off-by: Juergen Gross 
---
V5:
- new patch
V6:
- add comment to _can_read_lock() (Jan Beulich)
---
 xen/include/xen/rwlock.h | 23 +++++++++++++++--------
 1 file changed, 15 insertions(+), 8 deletions(-)

diff --git a/xen/include/xen/rwlock.h b/xen/include/xen/rwlock.h
index 65d88b0ef4..232782801d 100644
--- a/xen/include/xen/rwlock.h
+++ b/xen/include/xen/rwlock.h
@@ -23,12 +23,12 @@ typedef struct {
 #define rwlock_init(l) (*(l) = (rwlock_t)RW_LOCK_UNLOCKED)
 
 /* Writer states & reader shift and bias. */
-#define    _QW_CPUMASK  0xfffU             /* Writer CPU mask */
-#define    _QW_SHIFT    12                 /* Writer flags shift */
-#define    _QW_WAITING  (1U << _QW_SHIFT)  /* A writer is waiting */
-#define    _QW_LOCKED   (3U << _QW_SHIFT)  /* A writer holds the lock */
-#define    _QW_WMASK    (3U << _QW_SHIFT)  /* Writer mask */
-#define    _QR_SHIFT    14                 /* Reader count shift */
+#define    _QW_SHIFT    14                      /* Writer flags shift */
+#define    _QW_CPUMASK  ((1U << _QW_SHIFT) - 1) /* Writer CPU mask */
+#define    _QW_WAITING  (1U << _QW_SHIFT)       /* A writer is waiting */
+#define    _QW_LOCKED   (3U << _QW_SHIFT)       /* A writer holds the lock */
+#define    _QW_WMASK    (3U << _QW_SHIFT)       /* Writer mask */
+#define    _QR_SHIFT    (_QW_SHIFT + 2)         /* Reader count shift */
 #define    _QR_BIAS     (1U << _QR_SHIFT)
 
 void queue_read_lock_slowpath(rwlock_t *lock);
@@ -36,14 +36,21 @@ void queue_write_lock_slowpath(rwlock_t *lock);
 
 static inline bool _is_write_locked_by_me(unsigned int cnts)
 {
-    BUILD_BUG_ON(_QW_CPUMASK < NR_CPUS);
+    BUILD_BUG_ON((_QW_CPUMASK + 1) < NR_CPUS);
+    BUILD_BUG_ON(NR_CPUS * _QR_BIAS > INT_MAX);
     return (cnts & _QW_WMASK) == _QW_LOCKED &&
            (cnts & _QW_CPUMASK) == smp_processor_id();
 }
 
 static inline bool _can_read_lock(unsigned int cnts)
 {
-    return !(cnts & _QW_WMASK) || _is_write_locked_by_me(cnts);
+    /*
+     * If write locked by the caller, no other readers are possible.
+     * Not allowing the lock holder to read_lock() another 32768 times ought
+     * to be fine.
+     */
+    return cnts <= INT_MAX &&
+           (!(cnts & _QW_WMASK) || _is_write_locked_by_me(cnts));
 }
 
 /*
-- 
2.35.3



From xen-devel-bounces@lists.xenproject.org Wed Mar 27 15:23:20 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 15:23:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698614.1090558 (Exim 4.92)
	(envelope-from )
	id 1rpV7Y-0002RK-Gf; Wed, 27 Mar 2024 15:23:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698614.1090558; Wed, 27 Mar 2024 15:23:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpV7Y-0002R8-D0; Wed, 27 Mar 2024 15:23:20 +0000
Received: by outflank-mailman (input) for mailman id 698614;
 Wed, 27 Mar 2024 15:23:19 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpV7X-0007fn-3P
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 15:23:19 +0000
Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id efc82369-ec4d-11ee-a1ef-f123f15fe8a2;
 Wed, 27 Mar 2024 16:23:17 +0100 (CET)
Received: from imap2.dmz-prg2.suse.org (imap2.dmz-prg2.suse.org [10.150.64.98])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out2.suse.de (Postfix) with ESMTPS id 48BE320CE4;
 Wed, 27 Mar 2024 15:23:17 +0000 (UTC)
Received: from imap2.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap2.dmz-prg2.suse.org (Postfix) with ESMTPS id 0EAD313215;
 Wed, 27 Mar 2024 15:23:17 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap2.dmz-prg2.suse.org with ESMTPSA id wSkuAuU5BGbIfgAAn2gu4w
 (envelope-from ); Wed, 27 Mar 2024 15:23:17 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: efc82369-ec4d-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1711552997; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=svDhVGjKFzIPpcWjFYARn/2rWUfeidU+xfRiYlSjnX4=;
	b=hchFnFTpmvg2xILUuW8mlqB2nh83QyCO/EmARie/ZORSYtuJnBUo/zyJLY2HjVHqx09Elz
	aMaCJd0+9xLNObzCsolh41txPSQCTP0SXoMvzmysaK9xrz4NosL+/bITjscww81oqY4oMf
	9BN6qdzi0893vEzcaiyNbLNQnCouXuQ=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1711552997; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=svDhVGjKFzIPpcWjFYARn/2rWUfeidU+xfRiYlSjnX4=;
	b=hchFnFTpmvg2xILUuW8mlqB2nh83QyCO/EmARie/ZORSYtuJnBUo/zyJLY2HjVHqx09Elz
	aMaCJd0+9xLNObzCsolh41txPSQCTP0SXoMvzmysaK9xrz4NosL+/bITjscww81oqY4oMf
	9BN6qdzi0893vEzcaiyNbLNQnCouXuQ=
From: Juergen Gross 
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini 
Subject: [PATCH v6 8/8] xen: allow up to 16383 cpus
Date: Wed, 27 Mar 2024 16:22:29 +0100
Message-Id: <20240327152229.25847-9-jgross@suse.com>
X-Mailer: git-send-email 2.35.3
In-Reply-To: <20240327152229.25847-1-jgross@suse.com>
References: <20240327152229.25847-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Score: 3.70
X-Spamd-Result: default: False [3.70 / 50.00];
	 ARC_NA(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_MISSING_CHARSET(2.50)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 BROKEN_CONTENT_TYPE(1.50)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_SIGNED(0.00)[suse.com:s=susede1];
	 NEURAL_HAM_SHORT(-0.20)[-1.000];
	 RCPT_COUNT_SEVEN(0.00)[7];
	 MID_CONTAINS_FROM(1.00)[];
	 DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:email];
	 FUZZY_BLOCKED(0.00)[rspamd.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 RCVD_TLS_ALL(0.00)[]
X-Spam-Level: ***
Authentication-Results: smtp-out2.suse.de;
	none
X-Spam-Flag: NO

With lock handling now allowing up to 16384 cpus (spinlocks can handle
65535 cpus, rwlocks can handle 16384 cpus), raise the allowed limit for
the number of cpus to be configured to 16383.

The new limit is imposed by IOMMU_CMD_BUFFER_MAX_ENTRIES and
QINVAL_MAX_ENTRY_NR required to be larger than 2 * CONFIG_NR_CPUS.

Signed-off-by: Juergen Gross 
---
V5:
- new patch (Jan Beulich)
---
 xen/arch/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/Kconfig b/xen/arch/Kconfig
index 67ba38f32f..308ce129a8 100644
--- a/xen/arch/Kconfig
+++ b/xen/arch/Kconfig
@@ -6,7 +6,7 @@ config PHYS_ADDR_T_32
 
 config NR_CPUS
 	int "Maximum number of CPUs"
-	range 1 4095
+	range 1 16383
 	default "256" if X86
 	default "8" if ARM && RCAR3
 	default "4" if ARM && QEMU
-- 
2.35.3



From xen-devel-bounces@lists.xenproject.org Wed Mar 27 15:24:09 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 15:24:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698619.1090568 (Exim 4.92)
	(envelope-from )
	id 1rpV8J-0003er-QF; Wed, 27 Mar 2024 15:24:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698619.1090568; Wed, 27 Mar 2024 15:24:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpV8J-0003ek-NT; Wed, 27 Mar 2024 15:24:07 +0000
Received: by outflank-mailman (input) for mailman id 698619;
 Wed, 27 Mar 2024 15:24:06 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpV8I-0003eM-53
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 15:24:06 +0000
Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com
 [2607:f8b0:4864:20::833])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0bdb895d-ec4e-11ee-afe3-a90da7624cb6;
 Wed, 27 Mar 2024 16:24:05 +0100 (CET)
Received: by mail-qt1-x833.google.com with SMTP id
 d75a77b69052e-4317fbb669cso4404461cf.2
 for ; Wed, 27 Mar 2024 08:24:05 -0700 (PDT)
Received: from [10.80.67.139] (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 ci7-20020a05622a260700b00430d8e11bebsm4828495qtb.64.2024.03.27.08.24.02
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 27 Mar 2024 08:24:03 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0bdb895d-ec4e-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1711553044; x=1712157844; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=NSPFOYxauzNkJoM3JrPrvyYTOjlfuIGvvhyRlKI24pQ=;
        b=KNG7Y6aAKPXZos4SgWuYLvi9XtVBb1YmCwx0HmkCjzABQKIlgqpSquUB/Wm0H36IRt
         UxRpBZbbm8RT2eI2+wQpevHMaIrhMT7YbA6mL31ZyAGTKRIhPBInLNmQxJ+T9QF6RWCF
         ok14G7GhVUNXXcSHOnEkTgfxHW+rMOQd9UJy4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711553044; x=1712157844;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=NSPFOYxauzNkJoM3JrPrvyYTOjlfuIGvvhyRlKI24pQ=;
        b=JNCOZ0fIhBECTQjNpSs4Y07oZrMjwtVf+mGdCR0CXide/AKLmL5XaJf3V0Psz9PAlc
         NOTaM4At2ChNzCs4q0sPe8D29csFrxJ96Qa0dS9jVo7CJqpYkPOJU8f27Cn3rJP6BOPE
         7vBarqWzv4XKbHMs4LuKznggeBJ5d+0iQDTjWX3YsHsu+vmYxVinfJLf5VNdZRcUnAlX
         wsNq3bDmjGCT8+1IkuR8oX3lR9pPX2LC3ADPyh9H8vSN1oeZlot4eQL8ErtnDeHrTVc9
         uq2MItaaIOarJRSjev8xHMPq4aGB0LtUMdrVkNKU5w9tyK5QW8P80ciO8VrctwYFyBwI
         TwCQ==
X-Gm-Message-State: AOJu0YyTY/zOC+3YYbW6dZnDAtqbO5Ogbn/fohjE9iVqU75gNowZySaF
	jhG8IYbVMfvZ9XZunYwqEXODtW8OdPso6exrjjDAUJVPS1s72arLMNdb5IRpHS1g2ZRDY97QfMf
	OiG0=
X-Google-Smtp-Source: AGHT+IHNu0z2dJrl/U2WOT1ydfNygg/xrYmuJllvcxefz8AGN/rBoaZGMq9FSQJuTJ5qgKxfwLS/Jw==
X-Received: by 2002:a05:622a:387:b0:431:376a:1eb5 with SMTP id j7-20020a05622a038700b00431376a1eb5mr6896370qtx.31.1711553044132;
        Wed, 27 Mar 2024 08:24:04 -0700 (PDT)
Message-ID: 
Date: Wed, 27 Mar 2024 15:24:01 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] tools/oxenstored: Re-format
To: Edwin Torok 
Cc: Xen-devel ,
 Christian Lindig ,
 Rob Hoes 
References: <20240226104829.1044479-1-andrew.cooper3@citrix.com>
 
Content-Language: en-GB
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 27/03/2024 3:11 pm, Edwin Torok wrote:
> On Mon, Feb 26, 2024 at 10:48 AM Andrew Cooper
>  wrote:
>> Rerun make format.
> Looks good, although not sure whether whitespace will be correctly
> preserved in email, recommend using git to push the changes.
> Reviewed-by: Edwin Török 

Thanks.  Don't worry about the patch workflow.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Mar 27 15:29:37 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 15:29:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698631.1090578 (Exim 4.92)
	(envelope-from )
	id 1rpVDY-0004nH-FB; Wed, 27 Mar 2024 15:29:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698631.1090578; Wed, 27 Mar 2024 15:29:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpVDY-0004nA-CY; Wed, 27 Mar 2024 15:29:32 +0000
Received: by outflank-mailman (input) for mailman id 698631;
 Wed, 27 Mar 2024 15:29:31 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpVDX-0004n4-Af
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 15:29:31 +0000
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com
 [2a00:1450:4864:20::62c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ce096217-ec4e-11ee-afe3-a90da7624cb6;
 Wed, 27 Mar 2024 16:29:30 +0100 (CET)
Received: by mail-ej1-x62c.google.com with SMTP id
 a640c23a62f3a-a46f0da1b4fso880731066b.2
 for ; Wed, 27 Mar 2024 08:29:30 -0700 (PDT)
Received: from smtpclient.apple ([160.101.139.1])
 by smtp.gmail.com with ESMTPSA id
 j16-20020a170906411000b00a4655976025sm5546248ejk.82.2024.03.27.08.29.29
 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
 Wed, 27 Mar 2024 08:29:29 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ce096217-ec4e-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1711553370; x=1712158170; darn=lists.xenproject.org;
        h=to:references:message-id:content-transfer-encoding:cc:date
         :in-reply-to:from:subject:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=bDI/GjmcSQUKjpBzVonLr28hXzTP6U8GNPFMf2MZnuE=;
        b=CBmx227J7vZ0qIwDniK5qVjiBiPy9mKvnNMe28tJs6BojWmf4wA0zVglKs+w7f3TuA
         euNfO3FADd8iYd7jlhKJpUt5Va4O8ovXJ0BjkqcaEBiEhfwc2b0NoRVy992GkML5jX/3
         HxVuc1RbkJhoraEs62djymyazHAZHF3pewQIU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711553370; x=1712158170;
        h=to:references:message-id:content-transfer-encoding:cc:date
         :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=bDI/GjmcSQUKjpBzVonLr28hXzTP6U8GNPFMf2MZnuE=;
        b=JyXSPE1KZar/wZoH03z5twEkjC68MybeCg3YmyjXXAQeCFYky9Y7TANChI5X/9Scuf
         LFwLmePomM0kp44K+mCYabdWA3S4SUtT6NdQR3OOSoYKT0Au5B+Vyt77OZOnaOfVONrI
         PG37Cnsng02gBXqQYN+S3QT6vMQViLoF7cdaEKCcVg/nnLJYLq3dhT9ib5piJ7y9YM7R
         2nR2+PkrAmjrP1JnKEfZIY+WtfoA1fgtk3eH43keHJxLdssHYUQcYS1bpaQa74cufnmC
         HHZ5kIWSxX1e2o4TLHqDm4KZCrHTtShUKQaMWig8tD0CVzmv6uLuv33GyEIhdAZYosdE
         jbBA==
X-Forwarded-Encrypted: i=1; AJvYcCVbrBwFMvg4DD+or1kxqU1KRrAoLdThlKh+k/3NDpYurqo5bFqGQdFeeXYl/p2wO3J92EW0hoYpuiI5AQHS2K9nYw7gCwjSbPxsXUobo00=
X-Gm-Message-State: AOJu0YyVrNLCSRDK5hngyZjOMSdZr49Hvr7kY/Iy4pmrNKwX9yfLjOEV
	t74hlWLcO8QjqyAATgG3RaxpwYIRJUuMGegYwrE/IgdWT5IozqncyHHVdURAfbg=
X-Google-Smtp-Source: AGHT+IFs1t00YIQ9M+P5FFPZF5nJ+3cPn451JDwrv0ntl1Iho9b6LlmCt8qP0Qj7MgZ+/Yy/PfBDlA==
X-Received: by 2002:a17:906:3ad5:b0:a46:5d40:eb97 with SMTP id z21-20020a1709063ad500b00a465d40eb97mr2078171ejd.70.1711553369957;
        Wed, 27 Mar 2024 08:29:29 -0700 (PDT)
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.200.91.1.1\))
Subject: Re: preparations for 4.17.4
From: Christian Lindig 
In-Reply-To: <8fbb0ac1-e72b-4532-8d46-d79b751d8c96@citrix.com>
Date: Wed, 27 Mar 2024 15:29:18 +0000
Cc: Jan Beulich ,
 Stefano Stabellini ,
 Anthony Perard ,
 Julien Grall ,
 Kelly Choi ,
 "xen-devel@lists.xenproject.org" ,
 David Scott 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
 <6feb56fe-769d-4809-b16f-6fc4d5477747@citrix.com>
 <93172b11-c737-400e-9d2e-daafee8f1cbc@citrix.com>
 
 <8fbb0ac1-e72b-4532-8d46-d79b751d8c96@citrix.com>
To: Andrew Cooper 
X-Mailer: Apple Mail (2.3774.200.91.1.1)



> On 27 Mar 2024, at 14:42, Andrew Cooper  =
wrote:
>=20
> On 27/03/2024 2:06 pm, Jan Beulich wrote:
>> On 27.03.2024 15:01, Andrew Cooper wrote:
>>> It occurs to me that these want considering:
>>>=20
>>> b6cf604207fd - tools/oxenstored: Use Map instead of Hashtbl for =
quotas
>>> 098d868e52ac - tools/oxenstored: Make Quota.t pure
>>>=20
>>> while 4.17 is still in general support.  These came from a =
performance
>>> regression we investigated.
>>>=20
>>> I've done the backport to 4.17 and they're not entirely trivial =
(owing
>>> to the major source reformat in 4.18) so can commit them if you'd =
prefer.
>> Didn't you bring these up for 4.18.1 already, and I said that I'd =
leave
>> this for the maintainers to decide? Same here, in any event. Cc-ing =
them
>> both, just in case.
>=20
> I could have sworn that I remembered requested this before, but =
couldn't
> remember where.
>=20
> I'll see about poking people for an answer.
>=20
> ~Andrew

I understand we have backport; so I support upstreaming it.=20

=E2=80=94 C=


From xen-devel-bounces@lists.xenproject.org Wed Mar 27 16:27:28 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 16:27:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698645.1090599 (Exim 4.92)
	(envelope-from )
	id 1rpW7R-0000yO-Kk; Wed, 27 Mar 2024 16:27:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698645.1090599; Wed, 27 Mar 2024 16:27:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpW7R-0000yH-Hj; Wed, 27 Mar 2024 16:27:17 +0000
Received: by outflank-mailman (input) for mailman id 698645;
 Wed, 27 Mar 2024 16:27:16 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpW7Q-0000y5-1i; Wed, 27 Mar 2024 16:27:16 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpW7P-0002Wu-SD; Wed, 27 Mar 2024 16:27:15 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpW7P-0000Ak-Ec; Wed, 27 Mar 2024 16:27:15 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rpW7P-0000wQ-EE; Wed, 27 Mar 2024 16:27:15 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=nr/ybSeOwcu+yyQLrAwnhLfJwiUuEJH5ZrPUNj16tX8=; b=5p9zUtUuMH0S/jnQLDLrf+Uw4Z
	SNLFdAPjfkGLqPl3aidiPuBaEvd1Qp99swJuPWL3R2hrFY8em1Sp1mX3YKy9svqah5esrqBO68VY3
	HKtpkoDF+/or+4DCT3zqd6lkW7vjbEMWfge36+Je9qt20Qq3OflC3yuM/+++LeKxLUwo=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 185173: tolerable all pass - PUSHED
X-Osstest-Failures:
    xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    xen=0cd50753eb40ca5f00ea1ced9f80ce5f478e560c
X-Osstest-Versions-That:
    xen=e3883336bb5abba2ec2231618f5b64f61b099b1e
From: osstest service owner 
Date: Wed, 27 Mar 2024 16:27:15 +0000

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          16 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  0cd50753eb40ca5f00ea1ced9f80ce5f478e560c
baseline version:
 xen                  e3883336bb5abba2ec2231618f5b64f61b099b1e

Last test of basis   185170  2024-03-27 09:03:56 Z    0 days
Testing same since   185173  2024-03-27 12:02:02 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  George Dunlap 
  Jan Beulich 

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-amd64                    pass    
 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
   e3883336bb..0cd50753eb  0cd50753eb40ca5f00ea1ced9f80ce5f478e560c -> smoke


From xen-devel-bounces@lists.xenproject.org Wed Mar 27 16:30:27 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 16:30:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698649.1090609 (Exim 4.92)
	(envelope-from )
	id 1rpWAU-0002tj-2n; Wed, 27 Mar 2024 16:30:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698649.1090609; Wed, 27 Mar 2024 16:30:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpWAU-0002tc-0F; Wed, 27 Mar 2024 16:30:26 +0000
Received: by outflank-mailman (input) for mailman id 698649;
 Wed, 27 Mar 2024 16:30:24 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpWAS-0002s8-64
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 16:30:24 +0000
Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com
 [2607:f8b0:4864:20::836])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4dfdf1ee-ec57-11ee-a1ef-f123f15fe8a2;
 Wed, 27 Mar 2024 17:30:22 +0100 (CET)
Received: by mail-qt1-x836.google.com with SMTP id
 d75a77b69052e-430a0d6c876so42817471cf.3
 for ; Wed, 27 Mar 2024 09:30:21 -0700 (PDT)
Received: from fedora39.edvint-x-u ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 u5-20020a05622a17c500b004314f546017sm3652107qtk.79.2024.03.27.09.30.18
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 27 Mar 2024 09:30:19 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4dfdf1ee-ec57-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1711557020; x=1712161820; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:from:to:cc:subject:date:message-id:reply-to;
        bh=7lqlXT2RfS86kgsXk3lOacDlRJEjVNtBSA3x1E7m/D8=;
        b=PmRLYGh0pX6RBqEtLnFesnK9Ymok0DQ230l3SMRdbMiqvE5xegu9oELesw87Q3seJy
         kQ5n7/crxJJLTeC0nOuyFqGBQQMnSIyjfiaeD61qatUjKfq2JKrICGajp62b0N5Zc2c5
         Umd0R8GPGkA+qhQGLNPWdWKkxNaSqGxfa0meQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711557020; x=1712161820;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=7lqlXT2RfS86kgsXk3lOacDlRJEjVNtBSA3x1E7m/D8=;
        b=ZgLxTyNANeRwGHMwsLIxPCiz2iYpb2mPkIr5NeYhWv4I39PLkDe5oDSIY1aI/V6Mtr
         qJdMaC3PlU5jzRX5ByLKbXbQv7FMhqft9mM43WSofYP84f8Cf68eHA9K/a4cHJCqa0IT
         0BjcQ1qFMoc28OyVUkRU6Q/+bR1Fkvgw3otKipBRcehnmfGBkXCgxjiwSIX52ZxmThkf
         LID2OSe6KsPxJmw+KPoGO5/fwTwWGW2Vtmn75cbgd2ZyQ9LaPW7OA1CNKUr1/xOUztqn
         lows0i186x9F8VBqildx1vYqCQck0dYY5CIpx2tZf9XsuWn5I+a4jnUsNgQaOEcCJJ//
         xftQ==
X-Gm-Message-State: AOJu0YxWi7XsMl9kr0u8XtzLGX9nVX+9rK0N+5W33WpaGm+MTr98SFo3
	sKEX6QXL9xrAMLx77HUvtmH7V7DEJm99MFH0x3bu3wfK1+xHPHquRcWU3jT5jTC4OC9i59jtVji
	E2MI=
X-Google-Smtp-Source: AGHT+IFUO0nNdGQMmhSk9Rg6FVuw9n3DzXxdWyOGfwkDyrQBPwJsUZfHePu+XeRNbFgfiudytG9drQ==
X-Received: by 2002:a05:622a:3ca:b0:42e:d5a3:e03e with SMTP id k10-20020a05622a03ca00b0042ed5a3e03emr132214qtx.53.1711557019771;
        Wed, 27 Mar 2024 09:30:19 -0700 (PDT)
From: =?UTF-8?q?Edwin=20T=C3=B6r=C3=B6k?= 
To: xen-devel@lists.xenproject.org
Cc: =?UTF-8?q?Edwin=20T=C3=B6r=C3=B6k?= ,
	Christian Lindig ,
	David Scott ,
	Anthony PERARD 
Subject: [PATCH v1] tools/ocaml: fix warnings
Date: Wed, 27 Mar 2024 16:30:21 +0000
Message-ID: 
X-Mailer: git-send-email 2.44.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Do not rely on the string values of the `Failure` exception,
 but use the `_opt` functions instead.

Signed-off-by: Edwin Török 
---
 tools/ocaml/xenstored/config.ml | 20 +++++++++++---------
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/tools/ocaml/xenstored/config.ml b/tools/ocaml/xenstored/config.ml
index 95ef745a54..e0df236f73 100644
--- a/tools/ocaml/xenstored/config.ml
+++ b/tools/ocaml/xenstored/config.ml
@@ -83,25 +83,27 @@ let validate cf expected other =
   let err = ref [] in
   let append x = err := x :: !err in
   List.iter (fun (k, v) ->
+      let parse ~err_msg parser v f =
+        match parser v with
+        | None -> append (k, err_msg)
+        | Some r -> f r
+      in
       try
         if not (List.mem_assoc k expected) then
           other k v
         else let ty = List.assoc k expected in
           match ty with
           | Unit f       -> f ()
-          | Bool f       -> f (bool_of_string v)
+          | Bool f       -> parse ~err_msg:"expect bool arg" bool_of_string_opt v f
           | String f     -> f v
-          | Int f        -> f (int_of_string v)
-          | Float f      -> f (float_of_string v)
-          | Set_bool r   -> r := (bool_of_string v)
+          | Int f        -> parse ~err_msg:"expect int arg" int_of_string_opt v f
+          | Float f      -> parse ~err_msg:"expect float arg" float_of_string_opt v f
+          | Set_bool r   -> parse ~err_msg:"expect bool arg" bool_of_string_opt v (fun x -> r := x)
           | Set_string r -> r := v
-          | Set_int r    -> r := int_of_string v
-          | Set_float r  -> r := (float_of_string v)
+          | Set_int r    -> parse ~err_msg:"expect int arg" int_of_string_opt v (fun x -> r:= x)
+          | Set_float r  -> parse ~err_msg:"expect float arg" float_of_string_opt v (fun x -> r := x)
       with
       | Not_found                 -> append (k, "unknown key")
-      | Failure "int_of_string"   -> append (k, "expect int arg")
-      | Failure "bool_of_string"  -> append (k, "expect bool arg")
-      | Failure "float_of_string" -> append (k, "expect float arg")
       | exn                       -> append (k, Printexc.to_string exn)
     ) cf;
   if !err != [] then raise (Error !err)
-- 
2.44.0



From xen-devel-bounces@lists.xenproject.org Wed Mar 27 16:33:49 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 16:33:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698653.1090619 (Exim 4.92)
	(envelope-from )
	id 1rpWDh-0003ij-Hg; Wed, 27 Mar 2024 16:33:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698653.1090619; Wed, 27 Mar 2024 16:33:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpWDh-0003ic-F7; Wed, 27 Mar 2024 16:33:45 +0000
Received: by outflank-mailman (input) for mailman id 698653;
 Wed, 27 Mar 2024 16:33:43 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpWDf-0003iG-P3
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 16:33:43 +0000
Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com
 [2607:f8b0:4864:20::72c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c55a8530-ec57-11ee-a1ef-f123f15fe8a2;
 Wed, 27 Mar 2024 17:33:41 +0100 (CET)
Received: by mail-qk1-x72c.google.com with SMTP id
 af79cd13be357-789db18e169so519148985a.1
 for ; Wed, 27 Mar 2024 09:33:41 -0700 (PDT)
Received: from [10.80.67.139] (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 i9-20020ae9ee09000000b0078835bfddb8sm3987044qkg.84.2024.03.27.09.33.39
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 27 Mar 2024 09:33:40 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c55a8530-ec57-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1711557221; x=1712162021; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=JekyNzqDCw2jVjiiUkO/8dWtZVufWRLeqxN4jv/YZPk=;
        b=L0oKNkdzVxf38eME3HDgdVpMXGIkgMSPJTciwfS6l3Nix00Jo3ids7X9rUdOS6nVTJ
         Pl43H//KF1wiDv86BKTpCxY4T+fIMFUSRgiDI9+d5NiP/C0dnI9vWHUCgkHIcde8ZBtG
         IcvqEyXu3OJd2yXfZHbXhyud4QgIAZxCIqHsg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711557221; x=1712162021;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=JekyNzqDCw2jVjiiUkO/8dWtZVufWRLeqxN4jv/YZPk=;
        b=L5EgJn1YtHytc7aHGSrtdvqJK2l8GOI+xTsQ9/xulxxD0rHR5XOss9/6vdJ/md78Rl
         7PdRlT68nHXnBZgkBsBIU1B4opjA410R/1boulf2GifzXmaRMSh5le2SanpV+3bxuVsf
         d9FmJysWD984pcBItm8S+E0IYmVsY5PT5cjuqmMCWU1+Rz+pbD7jwlJMD5nMiVDIAzST
         gBl2cWv2LI864cswnIsnd9NnfO08ok1T8gBW56xXqECyz6lTXgNE2Suq9JWbGnX2O71k
         QdyeB1KHN6cpDUnS9EE6pA6SVAytoqcoUiOqBeWX33o2eS889HFoEsnZAwKSbjewgtVf
         aJXw==
X-Forwarded-Encrypted: i=1; AJvYcCUOXIjhfUv4qDyJ+K8IT3bAkazB5bjO4kG+Yk30ntAiImB6CI0NZy8R08LQcUtzDzeezpWy/UWbVnADxB4bzK34vZSw1roPI4RTtwlcsPY=
X-Gm-Message-State: AOJu0YyF8wNOIx4Sda8uqAH71jTIgXeBJ417IPW2Ce5ZdAycqArAgq2l
	DMI5Lp2/JuOPbfIIWr7MaI379CeAKQ8kOiKpQLTuUH2OEImkM9LmTqeI6Synea4=
X-Google-Smtp-Source: AGHT+IF4NFIzpxNduGrvaGluWbCWqtnP/3Q/4w0Z1YqhpET/5IhJwAEAPqFUjXa5UHVo5pJhNkTuVw==
X-Received: by 2002:a05:620a:1d81:b0:788:56c0:6006 with SMTP id pj1-20020a05620a1d8100b0078856c06006mr86058qkn.4.1711557220804;
        Wed, 27 Mar 2024 09:33:40 -0700 (PDT)
Message-ID: <53de7e8e-141a-464b-bc4e-89928cee9c75@citrix.com>
Date: Wed, 27 Mar 2024 16:33:38 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1] tools/ocaml: fix warnings
To: =?UTF-8?B?RWR3aW4gVMO2csO2aw==?= ,
 xen-devel@lists.xenproject.org
Cc: Christian Lindig ,
 David Scott , Anthony PERARD 
References: 
Content-Language: en-GB
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 27/03/2024 4:30 pm, Edwin Török wrote:
> Do not rely on the string values of the `Failure` exception,
>  but use the `_opt` functions instead.
>
> Signed-off-by: Edwin Török 

FWIW, Tested-by: Andrew Cooper 

But I think the subject wants to say "in config.ml" and the commit
message gain something like:

Fixes warnings such as:

  File "config.ml", line 102, characters 12-27:
  102 |         | Failure "int_of_string"   -> append (k, "expect int arg")
                    ^^^^^^^^^^^^^^^
  Warning 52: Code should not depend on the actual values of
  this constructor's arguments. They are only for information
  and may change in future versions. (See manual section 9.5)

I can adjust all on commit.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Mar 27 16:46:10 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 16:46:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698661.1090637 (Exim 4.92)
	(envelope-from )
	id 1rpWPZ-000601-NT; Wed, 27 Mar 2024 16:46:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698661.1090637; Wed, 27 Mar 2024 16:46:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpWPZ-0005zu-KZ; Wed, 27 Mar 2024 16:46:01 +0000
Received: by outflank-mailman (input) for mailman id 698661;
 Wed, 27 Mar 2024 16:46:00 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpWPY-0005zo-Bg
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 16:46:00 +0000
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com
 [2a00:1450:4864:20::42e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7ba72bb4-ec59-11ee-a1ef-f123f15fe8a2;
 Wed, 27 Mar 2024 17:45:56 +0100 (CET)
Received: by mail-wr1-x42e.google.com with SMTP id
 ffacd0b85a97d-3417a3151c5so4648361f8f.1
 for ; Wed, 27 Mar 2024 09:45:56 -0700 (PDT)
Received: from perard.uk.xensource.com (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 en7-20020a056000420700b0034174875850sm14015642wrb.70.2024.03.27.09.45.55
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 27 Mar 2024 09:45:55 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7ba72bb4-ec59-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1711557956; x=1712162756; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=zBErRmkltSguH2d0/UJYPB7aHlGXWYjo+/5oLZJOopI=;
        b=JsO0UDcHeUZoTtdSOQ7P1Jsq75JkCtoI0QXYxmgEFxrMfZvIIM3DScymX8uJEEno1K
         YsCa4s6hqAMm/QmmAGRDHMy590cRP9z/BE6r4uKau37qkJU+iYDNPgVWKaN63DeBJA3R
         VN2iW1QQRZjyUdE4m4TQ21LJHeRU82t03dMuA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711557956; x=1712162756;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=zBErRmkltSguH2d0/UJYPB7aHlGXWYjo+/5oLZJOopI=;
        b=EMv3hvRfHkSv06qx8Uv+6lXvfo5lsklkM2mt/wguPWFAG/Qd+wCgDwFdjxCejrUMMZ
         ozCL7mRYv8dfJU56V1kjkFmm6hw7ZXaKQtJrNGJOxjaV2/KJ/ymFXW3cFHL8lwWI6Cqt
         aco8cPqLoWbQB8hV8qJNRuPKWu9GC3fEKdFuz8EdtVqsv7N2oEp89G9XhXyTD4qoMvEP
         cSFAVAI1Rd5r3WXXi3BBh/hLbqj1kZEEBHK2WFqJ2beLHiSK4aDgOkxqZ8mn6D+I5mQS
         0ljau2E7EVGZnyZs9sGQqDaLrPdommpmtYD9ZWzIU7Ds1nOj1ftPBjfWVW9NKd021DfU
         PQfw==
X-Forwarded-Encrypted: i=1; AJvYcCWxJ8bJatZhqryHOqncAICstjuj5Y7Ug2tc81DicHlVEdqB0PoOiFZoiMgQUXMGKZwWj9kyhM7jtxC8M1AnAjq0vjg1T45d9x66KqbyZww=
X-Gm-Message-State: AOJu0YztGMX33EAU+vUD43zSdxc8QJhKe/Ex4qp70hUrGuXYS2ZIf6OD
	JJ8yN66iMhHsLgqHctdr97AxCcHkkp3oWuBLKdlcB4rjeG5EziIVazcwgXvvLoQ=
X-Google-Smtp-Source: AGHT+IGpIy3vGf4ZXnW5ibtGUcB1DXYHc9NeWjaOzQq8JTFfd0ipLrHkEfSGQkvsU8UA2GxqISwyxw==
X-Received: by 2002:a05:6000:92c:b0:342:86e9:b3c7 with SMTP id cx12-20020a056000092c00b0034286e9b3c7mr76883wrb.37.1711557956127;
        Wed, 27 Mar 2024 09:45:56 -0700 (PDT)
Date: Wed, 27 Mar 2024 16:45:54 +0000
From: Anthony PERARD 
To: Philippe =?iso-8859-1?Q?Mathieu-Daud=E9?= 
Cc: David Woodhouse , qemu-devel@nongnu.org,
	Alex =?iso-8859-1?Q?Benn=E9e?= ,
	Paul Durrant , qemu-arm@nongnu.org,
	Paolo Bonzini ,
	David Woodhouse ,
	Stefano Stabellini ,
	Richard Henderson ,
	xen-devel@lists.xenproject.org, qemu-block@nongnu.org,
	kvm@vger.kernel.org, Thomas Huth 
Subject: Re: [RFC PATCH-for-9.0 v2 13/19] hw/xen: Remove use of
 'target_ulong' in handle_ioreq()
Message-ID: <3a2da257-87f7-4d3f-9ef2-8450bc7b2742@perard>
References: <20231114143816.71079-1-philmd@linaro.org>
 <20231114143816.71079-14-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20231114143816.71079-14-philmd@linaro.org>

On Tue, Nov 14, 2023 at 03:38:09PM +0100, Philippe Mathieu-Daud wrote:
> Per commit f17068c1c7 ("xen-hvm: reorganize xen-hvm and move common
> function to xen-hvm-common"), handle_ioreq() is expected to be
> target-agnostic. However it uses 'target_ulong', which is a target
> specific definition.
> 
> Per xen/include/public/hvm/ioreq.h header:
> 
>   struct ioreq {
>     uint64_t addr;          /* physical address */
>     uint64_t data;          /* data (or paddr of data) */
>     uint32_t count;         /* for rep prefixes */
>     uint32_t size;          /* size in bytes */
>     uint32_t vp_eport;      /* evtchn for notifications to/from device model */
>     uint16_t _pad0;
>     uint8_t state:4;
>     uint8_t data_is_ptr:1;  /* if 1, data above is the guest paddr
>                              * of the real data to use. */
>     uint8_t dir:1;          /* 1=read, 0=write */
>     uint8_t df:1;
>     uint8_t _pad1:1;
>     uint8_t type;           /* I/O type */
>   };
>   typedef struct ioreq ioreq_t;
> 
> If 'data' is not a pointer, it is a u64.
> 
> - In PIO / VMWARE_PORT modes, only 32-bit are used.
> 
> - In MMIO COPY mode, memory is accessed by chunks of 64-bit

Looks like it could also be 8, 16, or 32 as well, depending on
req->size.

> - In PCI_CONFIG mode, access is u8 or u16 or u32.
> 
> - None of TIMEOFFSET / INVALIDATE use 'req'.
> 
> - Fallback is only used in x86 for VMWARE_PORT.
> 
> Masking the upper bits of 'data' to keep 'req->size' low bits
> is irrelevant of the target word size. Remove the word size
> check and always extract the relevant bits.

When building QEMU for Xen, we tend to build the target "i386-softmmu",
which looks like to have target_ulong == uint32_t. So the `data`
clamping would only apply to size 8 and 16. The clamping with
target_ulong was introduce long time ago, here:
https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=b4a663b87df3954557434a2d31bff7f6b2706ec1
and they were more IOREQ types.
So my guess is it isn't relevant anymore, but extending the clamping to
32-bits request should be fine, when using qemu-system-i386 that is, as
it is already be done if one use qemu-system-x86_64.

So I think the patch is fine, and the tests I've ran so far worked fine.

> Signed-off-by: Philippe Mathieu-Daud 

Reviewed-by: Anthony PERARD 

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Wed Mar 27 17:01:37 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 17:01:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698667.1090648 (Exim 4.92)
	(envelope-from )
	id 1rpWeZ-0001Eb-49; Wed, 27 Mar 2024 17:01:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698667.1090648; Wed, 27 Mar 2024 17:01:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpWeZ-0001EU-18; Wed, 27 Mar 2024 17:01:31 +0000
Received: by outflank-mailman (input) for mailman id 698667;
 Wed, 27 Mar 2024 17:01:29 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpWeX-0001EO-GN
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 17:01:29 +0000
Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com
 [2607:f8b0:4864:20::334])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a61b6126-ec5b-11ee-a1ef-f123f15fe8a2;
 Wed, 27 Mar 2024 18:01:27 +0100 (CET)
Received: by mail-ot1-x334.google.com with SMTP id
 46e09a7af769-6e6db4dfd7aso15210a34.2
 for ; Wed, 27 Mar 2024 10:01:27 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a61b6126-ec5b-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1711558886; x=1712163686; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=7/J8NnohPidyv2JMlXynv53vP943syT1DKaOVUdktVE=;
        b=ji5FbKwdw6J2xdll5ty59yCjlOSCbxzN6LHHD+leIJ5CC58qYrb5fayVJwKU/q272p
         NiyLiqEcc4G5SavSsAV6dyWNuv4WnpI61zsEOh68A+BjYQ8IghUx+JJ1HyDnQWM5rdUN
         tzmJmITJpYrC4vRXeICKa+Gm5/0klQXqJPERA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711558886; x=1712163686;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=7/J8NnohPidyv2JMlXynv53vP943syT1DKaOVUdktVE=;
        b=KXmipXm/3P9hhGvZfLvW1ZmatVeBeJBT/+Y/PnLyMEnzmGzJd9auXN08DcuEd/ZQKH
         PfSgC7WSQGpbDB/tPEDp/oX8eoLxT5FxPv48Lwlz6gQctCeAWXjfBimUQGm6C6LaYui7
         CyUIOqX7bgzeJKFZsCBNekoMNm8KO62azU2M6SWhZ87k/5PsIcOMrct20ai3P5mTNNfk
         Wa+p8fqyDkYJWhverDWPtIN3QWhLD3x9tVp9sgZkWKSywETU7tNKcshjqRWZQ5mP3uUc
         eSbzKHNCDbt+uVrFG1+2m9cXHX1W5rb9mt/xmaaORzsEc13F6gNKszeb4L1b83cjipR0
         Km/w==
X-Forwarded-Encrypted: i=1; AJvYcCXC42qM0QI2PEQ/VMyrqLhCH4LLEvcVtvkmdOZLjbQyDIEWm1lfWl2FLPzZGiS+Jbg4E0CQwXztLQ9iuDPkaIbSwfPvLstXy4oxPOtYz3M=
X-Gm-Message-State: AOJu0YwO4LauXk+2qVNVgbITsVXYTE0mf/uazR0VretfaN9vqj1BEoql
	09wAQ4ipqrPgb6C0nZ3iRqK5FAKw1SfQeYLMrsrB7LqUTj+qClXcLmCoyy5wLAVjs2o34PgjoiZ
	jK9Hnk6eql1HokbpbT01tcQFRfVTb1Y/ZdeBhiw==
X-Google-Smtp-Source: AGHT+IEFM/eVBZ9PId3adXdbFBM3MfZ63Wkb2nHIIlSI9DptAo8mvYDP9HtbTpONTe1WcQXTcwJXfpRNxCRAc7f2TxI=
X-Received: by 2002:a05:6871:608:b0:220:9eeb:b4a2 with SMTP id
 w8-20020a056871060800b002209eebb4a2mr269446oan.29.1711558886241; Wed, 27 Mar
 2024 10:01:26 -0700 (PDT)
MIME-Version: 1.0
References: <20240313122454.965566-1-george.dunlap@cloud.com>
 <20240313122454.965566-4-george.dunlap@cloud.com> <7a5b3ec3-c122-479a-b714-529e150bf4c0@suse.com>
In-Reply-To: <7a5b3ec3-c122-479a-b714-529e150bf4c0@suse.com>
From: George Dunlap 
Date: Wed, 27 Mar 2024 17:01:15 +0000
Message-ID: 
Subject: Re: [PATCH v2 3/3] svm/nestedsvm: Introduce nested capabilities bit
To: Jan Beulich 
Cc: Andrew Cooper , Julien Grall , 
	Stefano Stabellini , Wei Liu , 
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
	Jun Nakajima , Kevin Tian , 
	xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Mar 18, 2024 at 2:17=E2=80=AFPM Jan Beulich  wro=
te:
>
> On 13.03.2024 13:24, George Dunlap wrote:
> > In order to make implementation and testing tractable, we will require
> > specific host functionality.  Add a nested_virt bit to hvm_funcs.caps,
> > and return an error if a domain is created with nested virt and this
> > bit isn't set.  Create VMX and SVM callbacks to be executed from
> > start_nested_svm(), which is guaranteed to execute after all
>
> Nit: nestedhvm_setup() (or, with different wording, start_nested_{svm,vmx=
}()).

Oops, fixed.

> > --- a/xen/arch/x86/domain.c
> > +++ b/xen/arch/x86/domain.c
> > @@ -673,6 +673,12 @@ int arch_sanitise_domain_config(struct xen_domctl_=
createdomain *config)
> >           */
> >          config->flags |=3D XEN_DOMCTL_CDF_oos_off;
> >
> > +    if ( nested_virt && !hvm_nested_virt_supported() )
> > +    {
> > +        dprintk(XENLOG_INFO, "Nested virt requested but not available\=
n");
> > +        return -EINVAL;
> > +    }
> > +
> >      if ( nested_virt && !hap )
> >      {
> >          dprintk(XENLOG_INFO, "Nested virt not supported without HAP\n"=
);
>
> As mentioned in reply to v1, I think what both start_nested_{svm,vmx}() c=
heck
> is redundant with this latter check. I think that check isn't necessary t=
here
> (yet unlike suggested in reply to v1 I don't think anymore that the check=
 here
> can alternatively be dropped). And even if it was to be kept for some rea=
son,
> I'm having some difficulty seeing why vendor code needs to do that check,=
 when
> nestedhvm_setup() could do it for both of them.

I'm having a bit of trouble resolving the antecedents in this
paragraph (what "this" and "there" are referring to).

Are you saying that we should set hvm_funcs.caps.nested_virt to 'true'
even if the hardware doesn't support HAP, because we check that here?

That seems like a very strange way to go about things; hvm_funcs.caps
should reflect the actual capabilities of the hardware.  Suppose at
some point we want to expose nested virt capability to the toolstack
-- wouldn't it make more sense to be able to just read
`hvm_funcs.caps.nested_virt`, rather than having to remember to && it
with `hvm_funcs.caps.hap`?

And as you say, you can't get rid of the HAP check here, because we
also want to deny nested virt if the admin deliberately created a
guest in shadow mode on a system that has HAP available.  So it's not
redundant: one is checking the capabilities of the system, the other
is checking the requested guest configuration.

As to why to have each vendor independent code check for HAP -- there
are in fact two implementations of the code; it's nice to be able to
look in one place for each implementation to determine the
requirements.  Additionally, it would be possible, in the future, for
one of the nested virt implementations to enable shadow mode, while
the other one didn't.  The current arrangement makes that easy.

> > --- a/xen/arch/x86/hvm/nestedhvm.c
> > +++ b/xen/arch/x86/hvm/nestedhvm.c
> > @@ -150,6 +150,16 @@ static int __init cf_check nestedhvm_setup(void)
> >      __clear_bit(0x80, shadow_io_bitmap[0]);
> >      __clear_bit(0xed, shadow_io_bitmap[1]);
> >
> > +    /*
> > +     * NB this must be called after all command-line processing has be=
en
> > +     * done, so that if (for example) HAP is disabled, nested virt is
> > +     * disabled as well.
> > +     */
> > +    if ( cpu_has_vmx )
> > +        start_nested_vmx(&hvm_funcs);
> > +    else if ( cpu_has_svm )
> > +        start_nested_svm(&hvm_funcs);
>
> Instead of passing the pointer, couldn't you have the functions return
> bool, and then set hvm_funcs.caps.nested_virt from that? Passing that
> pointer looks somewhat odd to me.

For one, it makes start_nested_XXX symmetric to start_XXX, which also
has access to the full hvm_funcs structure (albeit in the former case
because it's creating the structure).  For two, both of them need to
read caps.hap.  For three, it's just more flexible -- there may be
future things that we want to modify in the start_nested_*()
functions.  If we did as you suggest, and then added (say)
caps.nested_virt_needs_hap, then we'd either need to add a second
function, or refactor it to look like this.

> Is there a reason to use direct calls here rather than a true hook
> (seeing that hvm_funcs must have been populated by the time we make it
> here)? I understand we're (remotely) considering to switch away from
> using hooks at some point, but right now this feels somewhat
> inconsistent if not further justified.

Again it mimics the calls to start_vmx/svm in hvm_enable.  But I could
look at adding a function pointer to see if it works.

 -George


From xen-devel-bounces@lists.xenproject.org Wed Mar 27 17:14:05 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 17:14:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698672.1090658 (Exim 4.92)
	(envelope-from )
	id 1rpWqe-0003Fi-79; Wed, 27 Mar 2024 17:14:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698672.1090658; Wed, 27 Mar 2024 17:14:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpWqe-0003Fb-3B; Wed, 27 Mar 2024 17:14:00 +0000
Received: by outflank-mailman (input) for mailman id 698672;
 Wed, 27 Mar 2024 17:13:58 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpWqc-0003FV-C4
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 17:13:58 +0000
Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com
 [2a00:1450:4864:20::32e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 656e8333-ec5d-11ee-afe3-a90da7624cb6;
 Wed, 27 Mar 2024 18:13:57 +0100 (CET)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-4149783d9b0so187365e9.2
 for ; Wed, 27 Mar 2024 10:13:57 -0700 (PDT)
Received: from perard.uk.xensource.com (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 w17-20020adfcd11000000b0033e786abf84sm15317168wrm.54.2024.03.27.10.13.55
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 27 Mar 2024 10:13:56 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 656e8333-ec5d-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1711559637; x=1712164437; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=vu7suNCUX1YMKGA4SET/IwU/8+fAPUob1HodKRWXOiw=;
        b=chLgupd1nl8e4CXFvhPxgVMUJ3Y72Gj2U8DQAxY6u/OA4l47+GuU9bYc7n8MQZpp+H
         k1fajfyPDHHRtsUuX7u4C3K2/W0F9tKpC73msqld3Kg0nMFmKc+Cv8MBkcmz/6axotJw
         beIDeiNwwKke4MFoZXiPeqFqYn1OLLIE2woHw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711559637; x=1712164437;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=vu7suNCUX1YMKGA4SET/IwU/8+fAPUob1HodKRWXOiw=;
        b=TafJZwg+FjnvAu3VreE11VymXcFz0jK0MNTZqFgFWdgTWuee2A2YpaWX+fS1Eij+so
         KtSWTjEzji0b7CmG2g93mNpuzb0R/kzyGI5Fn5UmAyR2NlqguxTn2GysO4YDYJQsvy0Y
         VB/NizjteVW0SpgCLlqeBkFXhmnu6mLBQQ5QB1mwRPSFujr7ETRa43bKc45WkguWV/Id
         JSggg3MFqPCJWAQSK+JJZ4YN4p0knbIWt1rHTvzsuF6jPjra8y1IY+3Zb23NqOrPrjuE
         8Zd9OXk90twxcjyhHaXNmOIw6ecUJ+i0C754VzDSk0M5PRi+gTEaCDz9wZBDNt8w+r+/
         1lyA==
X-Forwarded-Encrypted: i=1; AJvYcCUlXue41w1+v8J9cBt3KG8eoCO3LFMFFpLaZchbbpWMeh2umyEYQW5/fa+sPRatsujMTqfmm7aKUa69XC0aN7hpT7RONc9RJoh301XRwuk=
X-Gm-Message-State: AOJu0YxjLqAqxWeGLzhwrKLFhZY4MKkW71dzeQw8AJe8tWgZx3+K3ftI
	j1wfVGdE8ivHq5zIVMT+jl/93X7G+gypL6dTScDYSTpkhdnKSEJmWo3nLQuZ9Co=
X-Google-Smtp-Source: AGHT+IHuzwyfCe0U7WV3L9+qNX5m7LH+o76ieKYIT56YXzVsC6yBJ1zoRlezauX/mZrHEMHFIXhO1A==
X-Received: by 2002:a05:6000:ac3:b0:33e:64f3:65a5 with SMTP id di3-20020a0560000ac300b0033e64f365a5mr433896wrb.52.1711559636869;
        Wed, 27 Mar 2024 10:13:56 -0700 (PDT)
Date: Wed, 27 Mar 2024 17:13:55 +0000
From: Anthony PERARD 
To: Philippe =?iso-8859-1?Q?Mathieu-Daud=E9?= 
Cc: David Woodhouse , qemu-devel@nongnu.org,
	Alex =?iso-8859-1?Q?Benn=E9e?= ,
	Paul Durrant , qemu-arm@nongnu.org,
	Paolo Bonzini ,
	David Woodhouse ,
	Stefano Stabellini ,
	Richard Henderson ,
	xen-devel@lists.xenproject.org, qemu-block@nongnu.org,
	kvm@vger.kernel.org, Thomas Huth ,
	Peter Maydell ,
	Eduardo Habkost ,
	"Michael S. Tsirkin" ,
	Marcel Apfelbaum 
Subject: Re: [PATCH-for-9.0 v2 15/19] hw/xen: Reduce inclusion of 'cpu.h' to
 target-specific sources
Message-ID: <5cac8283-2e26-44dd-b113-d8499a0ef618@perard>
References: <20231114143816.71079-1-philmd@linaro.org>
 <20231114143816.71079-16-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20231114143816.71079-16-philmd@linaro.org>

On Tue, Nov 14, 2023 at 03:38:11PM +0100, Philippe Mathieu-Daud wrote:
> We rarely need to include "cpu.h" in headers. Including it
> 'taint' headers to be target-specific. Here only the i386/arm
> implementations requires "cpu.h", so include it there and
> remove from the "hw/xen/xen-hvm-common.h" *common* header.
> 
> Signed-off-by: Philippe Mathieu-Daud 
> Reviewed-by: Richard Henderson 
> Reviewed-by: David Woodhouse 

Acked-by: Anthony PERARD 

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Wed Mar 27 17:27:15 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 17:27:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698675.1090667 (Exim 4.92)
	(envelope-from )
	id 1rpX3N-0005Gb-9y; Wed, 27 Mar 2024 17:27:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698675.1090667; Wed, 27 Mar 2024 17:27:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpX3N-0005GU-77; Wed, 27 Mar 2024 17:27:09 +0000
Received: by outflank-mailman (input) for mailman id 698675;
 Wed, 27 Mar 2024 17:27:08 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpX3M-0005GM-1n
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 17:27:08 +0000
Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com
 [2a00:1450:4864:20::433])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3b7686ef-ec5f-11ee-a1ef-f123f15fe8a2;
 Wed, 27 Mar 2024 18:27:06 +0100 (CET)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-33ecb04e018so4966993f8f.1
 for ; Wed, 27 Mar 2024 10:27:06 -0700 (PDT)
Received: from perard.uk.xensource.com (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 fa7-20020a056000258700b00341c6b53358sm10953709wrb.66.2024.03.27.10.27.04
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 27 Mar 2024 10:27:05 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3b7686ef-ec5f-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1711560425; x=1712165225; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=LOeWq64vcMpyC+dfgqU4qcoJI/qjRuI1jSd1ZXO7Aa8=;
        b=Nffd0mviZlZzbUG0Gj33WOX2O+GBHtaI2dY2EIqp+m8IFTwcQdZ43rukG4E/pGIDrY
         1MKPTBDmOsUoTXGIeRfBhW6Gy7K2RklkiWdivwkndcTu02LOh9R2i/1LF7981dww0ulV
         QbABuP03pvBFVvIENC55OvksgkjIp6+W+jf3o=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711560425; x=1712165225;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=LOeWq64vcMpyC+dfgqU4qcoJI/qjRuI1jSd1ZXO7Aa8=;
        b=ki7saFEtxeGYOaJQJyI+vO6CMUUwe9tjjNSMWc0wze1Qs5+qkbxlI12TH4LN0yPK7P
         3A3rt9hNIB3gBxoE2cHQbu0RWqNlZ6bswgjrDjfttl6ev+V7fwcG51UIalzH6CwjZepv
         Xfb6uBm0JtYP4pRhkDPjcnSnh6j4rJ9iJfdJdwu/4RyKth7wiThYNXI91LDIOB4ErrVs
         dbIx8ihCkEbesQvP9uDrbKLgKJIF3IVvguIBX9wEZ9sk/wUwV8ExGxqF+Grc0P9GT/dw
         uS3jIHW8+FzJKqxSP9yJCGQxd53uvu6u8DVizYnGmyGQTUznItnm1pfxuY40dAGD1wf5
         H/yA==
X-Forwarded-Encrypted: i=1; AJvYcCWDvwliFgIc8QvdCNELAXiLzPPNokrq22Zt3mt229vQ172r8VPGTc+3ou9Pk+HeoLZXqD220XQg8q2bSO/e0fAHoWBIS3CCkbeF0hWF2z0=
X-Gm-Message-State: AOJu0YzGWkft1a+XpKoqGBe+xAG8/hQJFgs/IbodR77j1f6hJq+wzr3k
	DeTJFNI0k91GUnl2O3lKUSeo5ZG6K7MuPAsahK5vpSAecETYoEsVRqgA3UCkM7E=
X-Google-Smtp-Source: AGHT+IHr9JM+c5QDCOdkTDoDNItACvq5s9onzO3m1fxTIw9ef9+p/5BHroxQSnJUYc67vBX8mZewQg==
X-Received: by 2002:adf:eccc:0:b0:341:d64e:4966 with SMTP id s12-20020adfeccc000000b00341d64e4966mr424121wro.61.1711560425465;
        Wed, 27 Mar 2024 10:27:05 -0700 (PDT)
Date: Wed, 27 Mar 2024 17:27:04 +0000
From: Anthony PERARD 
To: Philippe =?iso-8859-1?Q?Mathieu-Daud=E9?= 
Cc: David Woodhouse , qemu-devel@nongnu.org,
	Alex =?iso-8859-1?Q?Benn=E9e?= ,
	Paul Durrant , qemu-arm@nongnu.org,
	Paolo Bonzini ,
	David Woodhouse ,
	Stefano Stabellini ,
	Richard Henderson ,
	xen-devel@lists.xenproject.org, qemu-block@nongnu.org,
	kvm@vger.kernel.org, Thomas Huth 
Subject: Re: [PATCH-for-9.0 v2 16/19] hw/xen/xen_pt: Add missing license
Message-ID: <71182998-214b-4e38-8420-79edb92ec09c@perard>
References: <20231114143816.71079-1-philmd@linaro.org>
 <20231114143816.71079-17-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20231114143816.71079-17-philmd@linaro.org>

On Tue, Nov 14, 2023 at 03:38:12PM +0100, Philippe Mathieu-Daud wrote:
> Commit eaab4d60d3 ("Introduce Xen PCI Passthrough, qdevice")
> introduced both xen_pt.[ch], but only added the license to
> xen_pt.c. Use the same license for xen_pt.h.
> 
> Suggested-by: David Woodhouse 
> Signed-off-by: Philippe Mathieu-Daud 

Fine by me. Looks like there was a license header before:
https://xenbits.xen.org/gitweb/?p=qemu-xen-unstable.git;a=blob;f=hw/pass-through.h;h=0b5822414e24d199a064abccc4d378dcaf569bd6;hb=HEAD
I don't know why I didn't copied it over here.

Acked-by: Anthony PERARD 

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Wed Mar 27 17:28:22 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 17:28:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698677.1090677 (Exim 4.92)
	(envelope-from )
	id 1rpX4S-0005n1-I7; Wed, 27 Mar 2024 17:28:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698677.1090677; Wed, 27 Mar 2024 17:28:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpX4S-0005mu-FU; Wed, 27 Mar 2024 17:28:16 +0000
Received: by outflank-mailman (input) for mailman id 698677;
 Wed, 27 Mar 2024 17:28:15 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpX4R-0005mo-1F
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 17:28:15 +0000
Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.4])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 621fe5ba-ec5f-11ee-a1ef-f123f15fe8a2;
 Wed, 27 Mar 2024 18:28:12 +0100 (CET)
Received: from m5p.com (mailhost.m5p.com [IPv6:2001:470:1f07:15ff:0:0:0:f7])
 by mailhost.m5p.com (8.17.1/8.15.2) with ESMTPS id 42RHRvsx080337
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
 Wed, 27 Mar 2024 13:28:03 -0400 (EDT) (envelope-from ehem@m5p.com)
Received: (from ehem@localhost)
 by m5p.com (8.17.1/8.15.2/Submit) id 42RHRvFj080336;
 Wed, 27 Mar 2024 10:27:57 -0700 (PDT) (envelope-from ehem)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 621fe5ba-ec5f-11ee-a1ef-f123f15fe8a2
Date: Wed, 27 Mar 2024 10:27:57 -0700
From: Elliott Mitchell 
To: Jan Beulich 
Cc: xen-devel@lists.xenproject.org, Andrew Cooper ,
        Roger Pau =?iso-8859-1?Q?Monn=E9?= ,
        Wei Liu , Kelly Choi 
Subject: Re: Serious AMD-Vi(?) issue
Message-ID: 
References: 
 
 
 
 
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-Spam-Status: No, score=0.0 required=10.0 tests=KHOP_HELO_FCRDNS
	autolearn=unavailable autolearn_force=no version=4.0.0
X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on mattapan.m5p.com

On Mon, Mar 25, 2024 at 02:43:44PM -0700, Elliott Mitchell wrote:
> On Mon, Mar 25, 2024 at 08:55:56AM +0100, Jan Beulich wrote:
> > On 22.03.2024 20:22, Elliott Mitchell wrote:
> > > On Fri, Mar 22, 2024 at 04:41:45PM +0000, Kelly Choi wrote:
> > >>
> > >> I can see you've recently engaged with our community with some issues you'd
> > >> like help with.
> > >> We love the fact you are participating in our project, however, our
> > >> developers aren't able to help if you do not provide the specific details.
> > > 
> > > Please point to specific details which have been omitted.  Fairly little
> > > data has been provided as fairly little data is available.  The primary
> > > observation is large numbers of:
> > > 
> > > (XEN) AMD-Vi: IO_PAGE_FAULT: DDDD:bb:dd.f d0 addr ffffff???????000 flags 0x8 I
> > > 
> > > Lines in Xen's ring buffer.
> > 
> > Yet this is (part of) the problem: By providing only the messages that appear
> > relevant to you, you imply that you know that no other message is in any way
> > relevant. That's judgement you'd better leave to people actually trying to
> > investigate. Unless of course you were proposing an actual code change, with
> > suitable justification.
> 
> Honestly, I forgot about the very small number of messages from the SATA
> subsystem.  The question of whether the current mitigation actions are
> effective right now was a bigger issue.  As such monitoring `xl dmesg`
> was a priority to looking at SATA messages which failed to reliably
> indicate status.
> 
> I *thought* I would be able to retrieve those via other slow means, but a
> different and possibly overlapping issue has shown up.  Unfortunately
> this means those are no longer retrievable.   :-(

With some persistence I was able to retrieve them.  There are other
pieces of software with worse UIs than Xen.

> > In fact when running into trouble, the usual course of action would be to
> > increase verbosity in both hypervisor and kernel, just to make sure no
> > potentially relevant message is missed.
> 
> More/better information might have been obtained if I'd been engaged
> earlier.

This is still true, things are in full mitigation mode and I'll be
quite unhappy to go back with experiments at this point.


I now see why I left those out.  The messages from the SATA subsystem
were from a kernel which a bad patch had leaked into a LTS branch.  Looks
like the SATA subsystem was significantly broken and I'm unsure whether
any useful information could be retrieved.  Notably there is quite a bit
of noise from SATA devices not effected by this issue.

Some of the messages /might/ be useful, but the amount of noise is quite
high.  Do messages from a broken kernel interest you?


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg@m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include  O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445




From xen-devel-bounces@lists.xenproject.org Wed Mar 27 18:14:49 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 18:14:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698686.1090692 (Exim 4.92)
	(envelope-from )
	id 1rpXnR-0004wk-FX; Wed, 27 Mar 2024 18:14:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698686.1090692; Wed, 27 Mar 2024 18:14:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpXnR-0004vn-BG; Wed, 27 Mar 2024 18:14:45 +0000
Received: by outflank-mailman (input) for mailman id 698686;
 Wed, 27 Mar 2024 18:14:13 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpXmv-0004pv-Ek
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 18:14:13 +0000
Received: from doppler.solinno.uk
 (8.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.9.a.d.0.6.f.d.1.0.b.8.0.1.0.0.2.ip6.arpa
 [2001:8b0:1df6:da9::18])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id cfe395f7-ec65-11ee-a1ef-f123f15fe8a2;
 Wed, 27 Mar 2024 19:14:12 +0100 (CET)
Received: from folly.solinno.co.uk (folly.dyn.solinno.co.uk [192.168.2.135])
 by doppler.solinno.uk (Postfix) with ESMTPSA id B0F4B8009F;
 Wed, 27 Mar 2024 18:14:11 +0000 (GMT)
Received: by folly.solinno.co.uk (Postfix, from userid 1000)
 id 86739202A8; Wed, 27 Mar 2024 18:14:11 +0000 (GMT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: cfe395f7-ec65-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=solinno.co.uk;
	s=mail; t=1711563251;
	bh=JDIuy3KhnVNygJWUuL86c9BvLnjCSC0gyIjiqhIaOR4=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=cwUuo4NJyABfEk6Zpckz7ZK35hiSzNFLUrnCwKZmyF6SYyGvbeQDYuJKy9/1jKrNg
	 UbljzUuah9nj65NmAqNlxA3UBGPBPx4ZMFNFGWdBQBEbDxYXcLMjV+uTp34AH1+Pfp
	 JDiHNMSniZw3roF9pEZJtJz2WZLZZ5FVq48wKz4M=
From: leigh@solinno.co.uk
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	anthony.perard@citrix.com,
	slack@rabbit.lu,
	Leigh Brown 
Subject: [PATCH 3/6] tools/misc: xenwatchdogd: make functions static
Date: Wed, 27 Mar 2024 18:13:50 +0000
Message-Id: <20240327181353.10951-4-leigh@solinno.co.uk>
X-Mailer: git-send-email 2.39.2
In-Reply-To: <20240327181353.10951-1-leigh@solinno.co.uk>
References: <55416d60-cae7-4e79-8bde-bc07ee9e3830@suse.com>
 <20240327181353.10951-1-leigh@solinno.co.uk>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Leigh Brown 

Make all functions except main() static in xenwatchdogd.c.
---
 tools/misc/xenwatchdogd.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/misc/xenwatchdogd.c b/tools/misc/xenwatchdogd.c
index d4da0ad0b6..224753e824 100644
--- a/tools/misc/xenwatchdogd.c
+++ b/tools/misc/xenwatchdogd.c
@@ -15,7 +15,7 @@ xc_interface *h;
 bool safeexit = false;
 bool done = false;
 
-void daemonize(void)
+static void daemonize(void)
 {
     switch (fork()) {
     case -1:
@@ -38,12 +38,12 @@ void daemonize(void)
         err(EXIT_FAILURE, "reopen stderr");
 }
 
-void catch_exit(int sig)
+static void catch_exit(int sig)
 {
     done = true;
 }
 
-void catch_usr1(int sig)
+static void catch_usr1(int sig)
 {
     safeexit = true;
     done = true;
-- 
2.39.2



From xen-devel-bounces@lists.xenproject.org Wed Mar 27 18:14:49 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 18:14:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698693.1090728 (Exim 4.92)
	(envelope-from )
	id 1rpXnT-0005Xh-7c; Wed, 27 Mar 2024 18:14:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698693.1090728; Wed, 27 Mar 2024 18:14:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpXnS-0005Wt-Sw; Wed, 27 Mar 2024 18:14:46 +0000
Received: by outflank-mailman (input) for mailman id 698693;
 Wed, 27 Mar 2024 18:14:16 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpXmy-0004q7-BT
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 18:14:16 +0000
Received: from doppler.solinno.uk (doppler.solinno.uk [81.2.106.178])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d0a6128d-ec65-11ee-afe3-a90da7624cb6;
 Wed, 27 Mar 2024 19:14:13 +0100 (CET)
Received: from folly.solinno.co.uk (folly.dyn.solinno.co.uk [192.168.2.135])
 by doppler.solinno.uk (Postfix) with ESMTPSA id D3E75800AD;
 Wed, 27 Mar 2024 18:14:11 +0000 (GMT)
Received: by folly.solinno.co.uk (Postfix, from userid 1000)
 id 8D260202AB; Wed, 27 Mar 2024 18:14:11 +0000 (GMT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d0a6128d-ec65-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=solinno.co.uk;
	s=mail; t=1711563251;
	bh=/l5XcylGh8QpFXW26aAq5ArxFrGUV6w08D0TT0l/waM=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=YQVXgIPNx1yNAVVZ0+hBNkgAh6nKA1yuxNbnj77qJTP6kpI2gEdvtD2Hc2/KrMCSn
	 xW7Hl6ZnZ6H+/x8fps40L1Q0di+SsyJHwYdLpoGCrDQ3RfBS3YFXejIcKv2+aJk24h
	 NBiH9vxDf8xfMpvccQ54vLaCavCtdiI8Eu90pp00=
From: leigh@solinno.co.uk
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	anthony.perard@citrix.com,
	slack@rabbit.lu,
	Leigh Brown 
Subject: [PATCH 6/6] docs/man: Add xenwatchdog manual page
Date: Wed, 27 Mar 2024 18:13:53 +0000
Message-Id: <20240327181353.10951-7-leigh@solinno.co.uk>
X-Mailer: git-send-email 2.39.2
In-Reply-To: <20240327181353.10951-1-leigh@solinno.co.uk>
References: <55416d60-cae7-4e79-8bde-bc07ee9e3830@suse.com>
 <20240327181353.10951-1-leigh@solinno.co.uk>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Leigh Brown 

Add a manual page for xenwatchdogd.
---
 docs/man/xenwatchdogd.8.pod | 54 +++++++++++++++++++++++++++++++++++++
 1 file changed, 54 insertions(+)
 create mode 100644 docs/man/xenwatchdogd.8.pod

diff --git a/docs/man/xenwatchdogd.8.pod b/docs/man/xenwatchdogd.8.pod
new file mode 100644
index 0000000000..2f6454f183
--- /dev/null
+++ b/docs/man/xenwatchdogd.8.pod
@@ -0,0 +1,54 @@
+=head1 NAME
+
+xenwatchdogd - Xen hypercall based watchdog daemon
+
+=head1 SYNOPSIS
+
+B [ I ] > [ > ]
+
+=head1 DESCRIPTION
+
+B arms the Xen watchdog timer to I every I
+seconds. If the xenwatchdogd process dies or is delayed for more than
+I seconds, then Xen will reboot the domain. If the domain being
+rebooted is domain 0, the whole system will reboot.
+
+=head1 OPTIONS
+
+=over 4
+
+=item B<-h>, B<--help>
+
+Display a help message.
+
+=item B<-F>, B<--foreground>
+
+Run in the foreground. The default behaviour is to daemonize.
+
+=item B<-x>, B<--safe-exit>
+
+Disable watchdog on orderly exit. The default behaviour is to arm the
+watchdog to 300 seconds to allow time for the domain to shutdown.  See 
+also the B section.
+
+=item B
+
+The number of seconds to arm the Xen watchdog timer. This must be set to
+a minimum of two.
+
+=item B
+
+The number of seconds to sleep in between calls to arm the Xen watchdog
+timer. This must be at least one second, and less than the I
+value. If not specified, it defaults to half the I value.
+
+=back
+
+=head1 SIGNALS
+
+B Will cause the program to disarm the watchdog timer and exit,
+regardless of whether the safe exit option was passed.
+
+=head1 AUTHOR
+
+Citrix Ltd and other contributors.
-- 
2.39.2



From xen-devel-bounces@lists.xenproject.org Wed Mar 27 18:14:49 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 18:14:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698688.1090706 (Exim 4.92)
	(envelope-from )
	id 1rpXnS-0005BO-4G; Wed, 27 Mar 2024 18:14:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698688.1090706; Wed, 27 Mar 2024 18:14:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpXnR-00059d-Tk; Wed, 27 Mar 2024 18:14:45 +0000
Received: by outflank-mailman (input) for mailman id 698688;
 Wed, 27 Mar 2024 18:14:13 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpXmv-0004q7-Mp
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 18:14:13 +0000
Received: from doppler.solinno.uk
 (8.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.9.a.d.0.6.f.d.1.0.b.8.0.1.0.0.2.ip6.arpa
 [2001:8b0:1df6:da9::18])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id cfe5eb1d-ec65-11ee-afe3-a90da7624cb6;
 Wed, 27 Mar 2024 19:14:12 +0100 (CET)
Received: from folly.solinno.co.uk (folly.dyn.solinno.co.uk [192.168.2.135])
 by doppler.solinno.uk (Postfix) with ESMTPSA id B2139800AB;
 Wed, 27 Mar 2024 18:14:11 +0000 (GMT)
Received: by folly.solinno.co.uk (Postfix, from userid 1000)
 id 88DF6202A9; Wed, 27 Mar 2024 18:14:11 +0000 (GMT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: cfe5eb1d-ec65-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=solinno.co.uk;
	s=mail; t=1711563251;
	bh=rQZPf46rdnhj9rP0ET/XSW2dcaf6Q8RXOc1FXyeFv8A=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=XUgZomaWSaC7XAON5YMh+zH32wgSPtqAYJD/l4Z3N7J58cAPaBap+XE6LUmFnTywm
	 NYgYgiG2hoMmPy/aVOWbaLQoLKkNWARuDQhll9vfW0xcFRo7SUiak9wwdiHMEgyyZg
	 oWomPnYl7ieMUi1lYhXPNlJ5rNJmDkV0zAGwuels=
From: leigh@solinno.co.uk
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	anthony.perard@citrix.com,
	slack@rabbit.lu,
	Leigh Brown 
Subject: [PATCH 4/6] tools/misc: xenwatchdogd: add parse_secs()
Date: Wed, 27 Mar 2024 18:13:51 +0000
Message-Id: <20240327181353.10951-5-leigh@solinno.co.uk>
X-Mailer: git-send-email 2.39.2
In-Reply-To: <20240327181353.10951-1-leigh@solinno.co.uk>
References: <55416d60-cae7-4e79-8bde-bc07ee9e3830@suse.com>
 <20240327181353.10951-1-leigh@solinno.co.uk>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Leigh Brown 

Create a new parse_secs() function to parse the timeout and sleep
parameters. This ensures that non-numeric parameters are not
accidentally treated as numbers.
---
 tools/misc/xenwatchdogd.c | 23 +++++++++++++++--------
 1 file changed, 15 insertions(+), 8 deletions(-)

diff --git a/tools/misc/xenwatchdogd.c b/tools/misc/xenwatchdogd.c
index 224753e824..26bfdef3db 100644
--- a/tools/misc/xenwatchdogd.c
+++ b/tools/misc/xenwatchdogd.c
@@ -49,6 +49,18 @@ static void catch_usr1(int sig)
     done = true;
 }
 
+static int parse_secs(const char *arg, const char *what)
+{
+    char *endptr;
+    unsigned long val;
+
+    val = strtoul(arg, &endptr, 0);
+    if (val > INT_MAX || *endptr != 0)
+	errx(EXIT_FAILURE, "invalid %s: '%s'", what, arg);
+
+    return val;
+}
+
 int main(int argc, char **argv)
 {
     int id;
@@ -64,16 +76,11 @@ int main(int argc, char **argv)
     if (h == NULL)
 	err(EXIT_FAILURE, "xc_interface_open");
 
-    t = strtoul(argv[1], NULL, 0);
-    if (t == ULONG_MAX)
-	err(EXIT_FAILURE, "strtoul");
+    t = parse_secs(argv[optind], "timeout");
 
     s = t / 2;
-    if (argc == 3) {
-	s = strtoul(argv[2], NULL, 0);
-	if (s == ULONG_MAX)
-	    err(EXIT_FAILURE, "strtoul");
-    }
+    if (argc == 3)
+	s = parse_secs(argv[optind], "sleep");
 
     if (signal(SIGHUP, &catch_exit) == SIG_ERR)
 	err(EXIT_FAILURE, "signal");
-- 
2.39.2



From xen-devel-bounces@lists.xenproject.org Wed Mar 27 18:14:49 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 18:14:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698690.1090715 (Exim 4.92)
	(envelope-from )
	id 1rpXnS-0005Fc-Dx; Wed, 27 Mar 2024 18:14:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698690.1090715; Wed, 27 Mar 2024 18:14:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpXnS-0005EH-5N; Wed, 27 Mar 2024 18:14:46 +0000
Received: by outflank-mailman (input) for mailman id 698690;
 Wed, 27 Mar 2024 18:14:14 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpXmw-0004q7-BP
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 18:14:14 +0000
Received: from doppler.solinno.uk
 (8.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.9.a.d.0.6.f.d.1.0.b.8.0.1.0.0.2.ip6.arpa
 [2001:8b0:1df6:da9::18])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id cfdbe840-ec65-11ee-afe3-a90da7624cb6;
 Wed, 27 Mar 2024 19:14:12 +0100 (CET)
Received: from folly.solinno.co.uk (folly.dyn.solinno.co.uk [192.168.2.135])
 by doppler.solinno.uk (Postfix) with ESMTPSA id ADF358009E;
 Wed, 27 Mar 2024 18:14:11 +0000 (GMT)
Received: by folly.solinno.co.uk (Postfix, from userid 1000)
 id 822C5202A6; Wed, 27 Mar 2024 18:14:11 +0000 (GMT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: cfdbe840-ec65-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=solinno.co.uk;
	s=mail; t=1711563251;
	bh=MMPqjL3hBPQ8fBBa6Taj4NhI2UexT0xGooHYTZT9+Zo=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=OD29/j6CgXPuqSW/8SMhaMdl//ep46BSk4GQ2rbKH8yxefhIuV+Z6BTmYaHYc3mLd
	 96BJiG0dRXZZZJTVG0alKblewuibIn4PTde+kWAmZA73MvEdt47rcKuVmiP/qmoPC3
	 CmNCLwxS75HZ3BAgxscgbH7RU89ROVQM1KqutUkk=
From: leigh@solinno.co.uk
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	anthony.perard@citrix.com,
	slack@rabbit.lu,
	Leigh Brown 
Subject: [PATCH 1/6] tools/misc: xenwatchdogd: use EXIT_* constants
Date: Wed, 27 Mar 2024 18:13:48 +0000
Message-Id: <20240327181353.10951-2-leigh@solinno.co.uk>
X-Mailer: git-send-email 2.39.2
In-Reply-To: <20240327181353.10951-1-leigh@solinno.co.uk>
References: <55416d60-cae7-4e79-8bde-bc07ee9e3830@suse.com>
 <20240327181353.10951-1-leigh@solinno.co.uk>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Leigh Brown 

Use EXIT_SUCCESS/EXIT_FAILURE constants instead of magic numbers.
---
 tools/misc/xenwatchdogd.c | 40 +++++++++++++++++++--------------------
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/tools/misc/xenwatchdogd.c b/tools/misc/xenwatchdogd.c
index 254117b554..2f7c822d61 100644
--- a/tools/misc/xenwatchdogd.c
+++ b/tools/misc/xenwatchdogd.c
@@ -17,37 +17,37 @@ void daemonize(void)
 {
     switch (fork()) {
     case -1:
-	err(1, "fork");
+	err(EXIT_FAILURE, "fork");
     case 0:
 	break;
     default:
-	exit(0);
+	exit(EXIT_SUCCESS);
     }
     umask(0);
     if (setsid() < 0)
-	err(1, "setsid");
+	err(EXIT_FAILURE, "setsid");
     if (chdir("/") < 0)
-	err(1, "chdir /");
+	err(EXIT_FAILURE, "chdir /");
     if (freopen("/dev/null", "r", stdin) == NULL)
-        err(1, "reopen stdin");
+        err(EXIT_FAILURE, "reopen stdin");
     if(freopen("/dev/null", "w", stdout) == NULL)
-        err(1, "reopen stdout");
+        err(EXIT_FAILURE, "reopen stdout");
     if(freopen("/dev/null", "w", stderr) == NULL)
-        err(1, "reopen stderr");
+        err(EXIT_FAILURE, "reopen stderr");
 }
 
 void catch_exit(int sig)
 {
     if (id)
         xc_watchdog(h, id, 300);
-    exit(0);
+    exit(EXIT_SUCCESS);
 }
 
 void catch_usr1(int sig)
 {
     if (id)
         xc_watchdog(h, id, 0);
-    exit(0);
+    exit(EXIT_SUCCESS);
 }
 
 int main(int argc, char **argv)
@@ -56,44 +56,44 @@ int main(int argc, char **argv)
     int ret;
 
     if (argc < 2)
-	errx(1, "usage: %s  ", argv[0]);
+	errx(EXIT_FAILURE, "usage: %s  ", argv[0]);
 
     daemonize();
 
     h = xc_interface_open(NULL, NULL, 0);
     if (h == NULL)
-	err(1, "xc_interface_open");
+	err(EXIT_FAILURE, "xc_interface_open");
 
     t = strtoul(argv[1], NULL, 0);
     if (t == ULONG_MAX)
-	err(1, "strtoul");
+	err(EXIT_FAILURE, "strtoul");
 
     s = t / 2;
     if (argc == 3) {
 	s = strtoul(argv[2], NULL, 0);
 	if (s == ULONG_MAX)
-	    err(1, "strtoul");
+	    err(EXIT_FAILURE, "strtoul");
     }
 
     if (signal(SIGHUP, &catch_exit) == SIG_ERR)
-	err(1, "signal");
+	err(EXIT_FAILURE, "signal");
     if (signal(SIGINT, &catch_exit) == SIG_ERR)
-	err(1, "signal");
+	err(EXIT_FAILURE, "signal");
     if (signal(SIGQUIT, &catch_exit) == SIG_ERR)
-	err(1, "signal");
+	err(EXIT_FAILURE, "signal");
     if (signal(SIGTERM, &catch_exit) == SIG_ERR)
-	err(1, "signal");
+	err(EXIT_FAILURE, "signal");
     if (signal(SIGUSR1, &catch_usr1) == SIG_ERR)
-	err(1, "signal");
+	err(EXIT_FAILURE, "signal");
 
     id = xc_watchdog(h, 0, t);
     if (id <= 0)
-        err(1, "xc_watchdog setup");
+        err(EXIT_FAILURE, "xc_watchdog setup");
 
     for (;;) {
         sleep(s);
         ret = xc_watchdog(h, id, t);
         if (ret != 0)
-            err(1, "xc_watchdog");
+            err(EXIT_FAILURE, "xc_watchdog");
     }
 }
-- 
2.39.2



From xen-devel-bounces@lists.xenproject.org Wed Mar 27 18:14:49 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 18:14:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698687.1090697 (Exim 4.92)
	(envelope-from )
	id 1rpXnR-00053a-O4; Wed, 27 Mar 2024 18:14:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698687.1090697; Wed, 27 Mar 2024 18:14:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpXnR-00050c-JP; Wed, 27 Mar 2024 18:14:45 +0000
Received: by outflank-mailman (input) for mailman id 698687;
 Wed, 27 Mar 2024 18:14:13 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpXmv-0004pv-LY
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 18:14:13 +0000
Received: from doppler.solinno.uk
 (8.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.9.a.d.0.6.f.d.1.0.b.8.0.1.0.0.2.ip6.arpa
 [2001:8b0:1df6:da9::18])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id cfeaa987-ec65-11ee-a1ef-f123f15fe8a2;
 Wed, 27 Mar 2024 19:14:12 +0100 (CET)
Received: from folly.solinno.co.uk (folly.dyn.solinno.co.uk [192.168.2.135])
 by doppler.solinno.uk (Postfix) with ESMTPSA id B4C7B800AC;
 Wed, 27 Mar 2024 18:14:11 +0000 (GMT)
Received: by folly.solinno.co.uk (Postfix, from userid 1000)
 id 8B12E202AA; Wed, 27 Mar 2024 18:14:11 +0000 (GMT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: cfeaa987-ec65-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=solinno.co.uk;
	s=mail; t=1711563251;
	bh=hpLEOTagI61CXps0+cy2rWLbakF8//wcNhtpIOFZpR0=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=nVV3jfw3vsYUmrK7E+spsBFdLLUgaDzBy+GT+8ynXbWE7QimLvAO8PKzckIesdlKb
	 I135XlGL475dZ0gU9XtPg6WrcxEuFMKpdjFYwOtpPat0i52OxGN9g2tlGaMk9kV4+F
	 UJu1R9mvkr+BEWn4WCP6xrYooEFtqLUlqOhGVMKk=
From: leigh@solinno.co.uk
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	anthony.perard@citrix.com,
	slack@rabbit.lu,
	Leigh Brown 
Subject: [PATCH 5/6] tools/misc: xenwatchdogd enhancements
Date: Wed, 27 Mar 2024 18:13:52 +0000
Message-Id: <20240327181353.10951-6-leigh@solinno.co.uk>
X-Mailer: git-send-email 2.39.2
In-Reply-To: <20240327181353.10951-1-leigh@solinno.co.uk>
References: <55416d60-cae7-4e79-8bde-bc07ee9e3830@suse.com>
 <20240327181353.10951-1-leigh@solinno.co.uk>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Leigh Brown 

Add enhanced parameter parsing and validation, making use of
getopt_long(). Adds usage() function, ability to run in the foreground,
and the ability to disarm the watchdog timer when exiting.  Now checks
the number of parameters are correct, that timeout is at least two
seconds (to allow a minimum sleep time of one second), and that the
sleep time is at least one and less than the watchdog timeout. After
these changes, the daemon will no longer instantly reboot the domain
if you enter a zero timeout (or non-numeric parameter), and prevent
the daemon consuming 100% of a CPU. Add a copyright message. This is
based on the previous commits which were from Citrix email addresses.
---
 tools/misc/xenwatchdogd.c | 111 ++++++++++++++++++++++++++++++++++----
 1 file changed, 101 insertions(+), 10 deletions(-)

diff --git a/tools/misc/xenwatchdogd.c b/tools/misc/xenwatchdogd.c
index 26bfdef3db..77638a4309 100644
--- a/tools/misc/xenwatchdogd.c
+++ b/tools/misc/xenwatchdogd.c
@@ -1,3 +1,20 @@
+/*
+ * xenwatchdogd.c
+ *
+ * Watchdog based on Xen hypercall watchdog interface
+ *
+ * Copyright 2010-2024 Citrix Ltd and other contributors
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
 
 #include 
 #include 
@@ -10,6 +27,11 @@
 #include 
 #include 
 #include 
+#include 
+
+#define WDOG_MIN_TIMEOUT 2
+#define WDOG_MIN_SLEEP 1
+#define WDOG_EXIT_TIMEOUT 300
 
 xc_interface *h;
 bool safeexit = false;
@@ -49,6 +71,26 @@ static void catch_usr1(int sig)
     done = true;
 }
 
+static void __attribute__((noreturn)) usage(int exit_code)
+{
+    FILE *out = exit_code ? stderr : stdout;
+
+    fprintf(out,
+	"Usage: xenwatchdog [OPTION]...  []\n"
+	"  -h, --help\t\tDisplay this help text and exit.\n"
+	"  -F, --foreground\tRun in foreground.\n"
+	"  -x, --safe-exit\tDisable watchdog on orderly exit.\n"
+	"\t\t\tNote: default is to set a %d second timeout on exit.\n\n"
+	"  timeout\t\tInteger seconds to arm the watchdog each time.\n"
+	"\t\t\tNote: minimum timeout is %d seconds.\n\n"
+	"  sleep\t\t\tInteger seconds to sleep between arming the watchdog.\n"
+	"\t\t\tNote: sleep must be at least %d and less than timeout.\n"
+	"\t\t\tIf not specified then set to half the timeout.\n",
+	WDOG_EXIT_TIMEOUT, WDOG_MIN_TIMEOUT, WDOG_MIN_SLEEP
+	);
+    exit(exit_code);
+}
+
 static int parse_secs(const char *arg, const char *what)
 {
     char *endptr;
@@ -66,21 +108,70 @@ int main(int argc, char **argv)
     int id;
     int t, s;
     int ret;
+    bool daemon = true;
+
+    for ( ;; )
+    {
+	int option_index = 0, c;
+	static const struct option long_options[] =
+	{
+	    { "help", no_argument, NULL, 'h' },
+	    { "foreground", no_argument, NULL, 'F' },
+	    { "safe-exit", no_argument, NULL, 'x' },
+	    { NULL, 0, NULL, 0 },
+	};
+
+	c = getopt_long(argc, argv, "hFxD", long_options, &option_index);
+	if (c == -1)
+	    break;
+
+	switch (c)
+	{
+	case 'h':
+	    usage(EXIT_SUCCESS);
+
+	case 'F':
+	    daemon = false;
+	    break;
+
+	case 'x':
+	    safeexit = true;
+	    break;
+
+	default:
+	    usage(EXIT_FAILURE);
+	}
+    }
 
-    if (argc < 2)
-	errx(EXIT_FAILURE, "usage: %s  ", argv[0]);
+    if (argc - optind < 1)
+	errx(EXIT_FAILURE, "timeout must be specified");
 
-    daemonize();
-
-    h = xc_interface_open(NULL, NULL, 0);
-    if (h == NULL)
-	err(EXIT_FAILURE, "xc_interface_open");
+    if (argc - optind > 2)
+	errx(EXIT_FAILURE, "too many arguments");
 
     t = parse_secs(argv[optind], "timeout");
+    if (t < WDOG_MIN_TIMEOUT)
+	errx(EXIT_FAILURE, "Error: timeout must be at least %d seconds",
+			   WDOG_MIN_TIMEOUT);
 
-    s = t / 2;
-    if (argc == 3)
+    ++optind;
+    if (optind < argc) {
 	s = parse_secs(argv[optind], "sleep");
+	if (s < WDOG_MIN_SLEEP)
+	    errx(EXIT_FAILURE, "Error: sleep must be no less than %d",
+			       WDOG_MIN_SLEEP);
+	if (s >= t)
+	    errx(EXIT_FAILURE, "Error: sleep must be less than timeout");
+    }
+    else
+	s = t / 2;
+
+    if (daemon)
+	daemonize();
+
+    h = xc_interface_open(NULL, NULL, 0);
+    if (h == NULL)
+	err(EXIT_FAILURE, "xc_interface_open");
 
     if (signal(SIGHUP, &catch_exit) == SIG_ERR)
 	err(EXIT_FAILURE, "signal");
@@ -105,6 +196,6 @@ int main(int argc, char **argv)
     }
 
     // Zero seconds timeout will disarm the watchdog timer
-    xc_watchdog(h, id, safeexit ? 0 : 300);
+    xc_watchdog(h, id, safeexit ? 0 : WDOG_EXIT_TIMEOUT);
     return 0;
 }
-- 
2.39.2



From xen-devel-bounces@lists.xenproject.org Wed Mar 27 18:14:49 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 18:14:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698684.1090687 (Exim 4.92)
	(envelope-from )
	id 1rpXnR-0004tw-7M; Wed, 27 Mar 2024 18:14:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698684.1090687; Wed, 27 Mar 2024 18:14:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpXnR-0004tp-4t; Wed, 27 Mar 2024 18:14:45 +0000
Received: by outflank-mailman (input) for mailman id 698684;
 Wed, 27 Mar 2024 18:14:12 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpXmt-0004pv-H7
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 18:14:12 +0000
Received: from doppler.solinno.uk
 (8.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.9.a.d.0.6.f.d.1.0.b.8.0.1.0.0.2.ip6.arpa
 [2001:8b0:1df6:da9::18])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ce06e62a-ec65-11ee-a1ef-f123f15fe8a2;
 Wed, 27 Mar 2024 19:14:09 +0100 (CET)
Received: from folly.solinno.co.uk (folly.dyn.solinno.co.uk [192.168.2.135])
 by doppler.solinno.uk (Postfix) with ESMTPSA id 4504980063;
 Wed, 27 Mar 2024 18:14:08 +0000 (GMT)
Received: by folly.solinno.co.uk (Postfix, from userid 1000)
 id 288FF202A6; Wed, 27 Mar 2024 18:14:08 +0000 (GMT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ce06e62a-ec65-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=solinno.co.uk;
	s=mail; t=1711563248;
	bh=4fghE0zaGdPSmd+dQTZotqH0mN2NPxM+aDrfDLB5zDI=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=bgVSiAo7QrXvqMD+HNnROJwQRG1lRZk+KaF42UTEvHgilEkaLOyEAW/HuB05hrVT/
	 mtdm0KB8HDc7CMLZzd+aIDXt1TyL033D+xp43OjC4OW2znac2B8bqg1aOR30fzlOc4
	 LkusIQ21M1TIkcaJMHZ9mLtzMEM9/W8eoXqVM5pU=
From: leigh@solinno.co.uk
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	anthony.perard@citrix.com,
	slack@rabbit.lu,
	Leigh Brown 
Subject: [PATCH 0/6] xenwatchdogd enhancements
Date: Wed, 27 Mar 2024 18:13:47 +0000
Message-Id: <20240327181353.10951-1-leigh@solinno.co.uk>
X-Mailer: git-send-email 2.39.2
In-Reply-To: <55416d60-cae7-4e79-8bde-bc07ee9e3830@suse.com>
References: <55416d60-cae7-4e79-8bde-bc07ee9e3830@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Leigh Brown 

Following up on Cyril's email. I had been independently looking at this,
mainly because xenwatchdogd is simple enough for me to understand. The
primary intention of this patch series is to replace the pathologically
bad behaviour of rebooting the domain if you run "xenwatchdogd -h". To
that end, I have implemented comprehensive argument validation. This
validation ensures you can't pass arguments that instantly reboot the
domain or cause it to spin loop running sleep(0) repeatedly. I added a
couple of enhancements whilst working on the changes as they were easy
enough.

Full list of changes:
- Use getopt_long() to add -h/--help with associated usage help.
- Add -F/--foreground parameter to run without daemonizing.
- Add -x/--save-exit parameter to disarm the watchdog when exiting.
- Validate timeout is numeric and is at least two seconds.
- Validate sleep is numeric and is at least one and less than timeout.
- Check for too many arguments.
- Use symbol constants instead of magic numbers where possible.
- Add a manual page for xenwatchdogd().

I am not an expert in git or sending patches so forgive me if things
don't look quite right.

Signed-off-by: Leigh Brown 

Leigh Brown (6):
  tools/misc: xenwatchdogd: use EXIT_* constants
  tools/misc: rework xenwatchdogd signal handling
  tools/misc: xenwatchdogd: make functions static
  tools/misc: xenwatchdogd: add parse_secs()
  tools/misc: xenwatchdogd enhancements
  docs/man: Add xenwatchdog manual page

 docs/man/xenwatchdogd.8.pod |  54 +++++++++++
 tools/misc/xenwatchdogd.c   | 180 ++++++++++++++++++++++++++++--------
 2 files changed, 195 insertions(+), 39 deletions(-)
 create mode 100644 docs/man/xenwatchdogd.8.pod

-- 
2.39.2



From xen-devel-bounces@lists.xenproject.org Wed Mar 27 18:14:50 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 18:14:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698692.1090719 (Exim 4.92)
	(envelope-from )
	id 1rpXnS-0005Oh-QK; Wed, 27 Mar 2024 18:14:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698692.1090719; Wed, 27 Mar 2024 18:14:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpXnS-0005Ju-Gj; Wed, 27 Mar 2024 18:14:46 +0000
Received: by outflank-mailman (input) for mailman id 698692;
 Wed, 27 Mar 2024 18:14:15 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpXmx-0004q7-BP
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 18:14:15 +0000
Received: from doppler.solinno.uk (doppler.solinno.uk [81.2.106.178])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id cfd4837f-ec65-11ee-afe3-a90da7624cb6;
 Wed, 27 Mar 2024 19:14:12 +0100 (CET)
Received: from folly.solinno.co.uk (folly.dyn.solinno.co.uk [192.168.2.135])
 by doppler.solinno.uk (Postfix) with ESMTPSA id A7AFC80063;
 Wed, 27 Mar 2024 18:14:11 +0000 (GMT)
Received: by folly.solinno.co.uk (Postfix, from userid 1000)
 id 84509202A7; Wed, 27 Mar 2024 18:14:11 +0000 (GMT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: cfd4837f-ec65-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=solinno.co.uk;
	s=mail; t=1711563251;
	bh=ay3hKImaotvpX5ABfW+1h5b91XRSJf6dwN7llSE5zkA=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=r6tUrtESc3+Vw4pNkGzCM1cWS7YHKPfPMGCxCvBt2Z2VmfN0FrapUAwBdBSjIaKpt
	 QZ1C3QAoQTQz52XERPlOnU8gVRlqJtAOdoJCyQPL90nE8cvFwqxPljyynvDpguRQ3c
	 k5jUJnPs1S1FHqneNpI1v7V7x0C8CYotjI0OxCPA=
From: leigh@solinno.co.uk
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	anthony.perard@citrix.com,
	slack@rabbit.lu,
	Leigh Brown 
Subject: [PATCH 2/6] tools/misc: rework xenwatchdogd signal handling
Date: Wed, 27 Mar 2024 18:13:49 +0000
Message-Id: <20240327181353.10951-3-leigh@solinno.co.uk>
X-Mailer: git-send-email 2.39.2
In-Reply-To: <20240327181353.10951-1-leigh@solinno.co.uk>
References: <55416d60-cae7-4e79-8bde-bc07ee9e3830@suse.com>
 <20240327181353.10951-1-leigh@solinno.co.uk>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Leigh Brown 

Rework xenwatchdogd signal handling to do the minimum in the signal
handler. This is a very minor enhancement.
---
 tools/misc/xenwatchdogd.c | 20 ++++++++++++--------
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/tools/misc/xenwatchdogd.c b/tools/misc/xenwatchdogd.c
index 2f7c822d61..d4da0ad0b6 100644
--- a/tools/misc/xenwatchdogd.c
+++ b/tools/misc/xenwatchdogd.c
@@ -9,9 +9,11 @@
 #include 
 #include 
 #include 
+#include 
 
 xc_interface *h;
-int id = 0;
+bool safeexit = false;
+bool done = false;
 
 void daemonize(void)
 {
@@ -38,20 +40,18 @@ void daemonize(void)
 
 void catch_exit(int sig)
 {
-    if (id)
-        xc_watchdog(h, id, 300);
-    exit(EXIT_SUCCESS);
+    done = true;
 }
 
 void catch_usr1(int sig)
 {
-    if (id)
-        xc_watchdog(h, id, 0);
-    exit(EXIT_SUCCESS);
+    safeexit = true;
+    done = true;
 }
 
 int main(int argc, char **argv)
 {
+    int id;
     int t, s;
     int ret;
 
@@ -90,10 +90,14 @@ int main(int argc, char **argv)
     if (id <= 0)
         err(EXIT_FAILURE, "xc_watchdog setup");
 
-    for (;;) {
+    while (!done) {
         sleep(s);
         ret = xc_watchdog(h, id, t);
         if (ret != 0)
             err(EXIT_FAILURE, "xc_watchdog");
     }
+
+    // Zero seconds timeout will disarm the watchdog timer
+    xc_watchdog(h, id, safeexit ? 0 : 300);
+    return 0;
 }
-- 
2.39.2



From xen-devel-bounces@lists.xenproject.org Wed Mar 27 19:55:36 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 19:55:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698716.1090758 (Exim 4.92)
	(envelope-from )
	id 1rpZMm-0001f0-CZ; Wed, 27 Mar 2024 19:55:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698716.1090758; Wed, 27 Mar 2024 19:55:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpZMm-0001et-7U; Wed, 27 Mar 2024 19:55:20 +0000
Received: by outflank-mailman (input) for mailman id 698716;
 Wed, 27 Mar 2024 19:55:19 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpZMl-0001ej-3l; Wed, 27 Mar 2024 19:55:19 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpZMk-0006LH-O5; Wed, 27 Mar 2024 19:55:18 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpZMk-0001mw-7m; Wed, 27 Mar 2024 19:55:18 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rpZMk-0006w1-73; Wed, 27 Mar 2024 19:55:18 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=92J3VsQuEPaCVfB7UFuP0vfSWmmEUIiy1zomlUEFiKk=; b=vabnJZUsR/4SLABY6RvdgNNfAT
	V1ihnoaxb7y8HY+WmGmRR+LBWBEimBRQngCkdErlGwca8AnD8tsxoahhROigIzBfcZkqn36w/hgsn
	MsWGEsCHzFL20lPMfM9saZskggz8q+E7d5+X5SbYx9MYYdpZhG9gm0MWabHv/qxyjHIw=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 185176: tolerable all pass - PUSHED
X-Osstest-Failures:
    xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    xen=8f85af65af76727692b9c2dea4f470f503432d2f
X-Osstest-Versions-That:
    xen=0cd50753eb40ca5f00ea1ced9f80ce5f478e560c
From: osstest service owner 
Date: Wed, 27 Mar 2024 19:55:18 +0000

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          16 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  8f85af65af76727692b9c2dea4f470f503432d2f
baseline version:
 xen                  0cd50753eb40ca5f00ea1ced9f80ce5f478e560c

Last test of basis   185173  2024-03-27 12:02:02 Z    0 days
Testing same since   185176  2024-03-27 17:02:08 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper 

jobs:
 build-arm64-xsm                                              pass    
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-amd64-libvirt                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 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
   0cd50753eb..8f85af65af  8f85af65af76727692b9c2dea4f470f503432d2f -> smoke


From xen-devel-bounces@lists.xenproject.org Wed Mar 27 21:55:19 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 21:55:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698733.1090801 (Exim 4.92)
	(envelope-from )
	id 1rpbEq-0002NS-BO; Wed, 27 Mar 2024 21:55:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698733.1090801; Wed, 27 Mar 2024 21:55:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpbEq-0002NK-6x; Wed, 27 Mar 2024 21:55:16 +0000
Received: by outflank-mailman (input) for mailman id 698733;
 Wed, 27 Mar 2024 21:55:15 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpbEp-0002MB-F5
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 21:55:15 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on20600.outbound.protection.outlook.com
 [2a01:111:f403:2416::600])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id af94aaf8-ec84-11ee-a1ef-f123f15fe8a2;
 Wed, 27 Mar 2024 22:55:13 +0100 (CET)
Received: from SJ0PR13CA0090.namprd13.prod.outlook.com (2603:10b6:a03:2c4::35)
 by DM6PR12MB4329.namprd12.prod.outlook.com (2603:10b6:5:211::9) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.32; Wed, 27 Mar
 2024 21:55:09 +0000
Received: from CY4PEPF0000EE37.namprd05.prod.outlook.com
 (2603:10b6:a03:2c4:cafe::b4) by SJ0PR13CA0090.outlook.office365.com
 (2603:10b6:a03:2c4::35) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.12 via Frontend
 Transport; Wed, 27 Mar 2024 21:55:09 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 CY4PEPF0000EE37.mail.protection.outlook.com (10.167.242.43) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Wed, 27 Mar 2024 21:55:08 +0000
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Wed, 27 Mar
 2024 16:55:07 -0500
Received: from fedora.mshome.net (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Wed, 27 Mar 2024 16:55:07 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: af94aaf8-ec84-11ee-a1ef-f123f15fe8a2
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=i1v4y8zPqYmpoxGgMlvyFZ7LJhvsNfHUFczFIJC7R7kcuaswSl/0pBProEuvBv59pTlqlYNHSOiCOPMazX9iEeKjEHkHLNhAM3m2kFmevr4y4nW4FHAOYm8sNg6u0XNWzgMs9j6DHmWr7zTgtW5M1nd1g4NMj+Mii4Y91QGoU/m5C5ByQ0q/N3BK2POrP2zgi1psljF28roSJeIttlVPeCxItWWTYUcMrvuanwAity422vCkHQZBQOxmMy7utMyQGD8fOADiYPNwzEdxqQy17wdKhrOUb/SwquqJP56WxPjLQAR4+DedXqUC7iwvtySaynevN7Ta8rwM1QbQYYCdjg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=NCUNHAud3RKnNZN44YqJ/JNK6UfzaIxSGxEmG+Yk0iE=;
 b=GKuitne/DQA2GsounsDhcMJyiaXCSth3u/eSivpsUgl1uWDF/BgcvkC5gs61t+vz5P8F17oYojUlo51rSFMKO/cFet4gqOOjps85266L2jzTJ09VZUPA+olC0/IwEEWTJFZSQM3BPHw+MeHJNoPsxHGd8w8nyMPGOSdRdfuRHCpFSChVGrbEg8a/E4hMwtuCqq1Xg3G1PaFKC2Ng6WWOGgnfXxUV+1NBnRwwNWsJPdhyPJWE1WHAQuQPYV03UCLw580hTe85sWVSB2efqVeO47PEEnkBvDISGv+6jxULfRKU2sSLCZ7x21LXw2c+g0Ygt+GB0neUHF+H+ViP7r+zvg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=NCUNHAud3RKnNZN44YqJ/JNK6UfzaIxSGxEmG+Yk0iE=;
 b=P4eKQU41W01UYzvBF5z3aKMTMU63QZbvhdx2b9bnvpvt1q0jdpeUmPcyjSjRXUu5iFThMEz+amrSie508zAttnfZTW/ks+NI6c029HMaZniQA11I8oXAGMW0r+3/W7HSOmfYqDgDxKUXJ+FhaTeRzMjYtVI8taGPehvO/JEI9Fw=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
From: Jason Andryuk 
To: 
CC: Jason Andryuk , Andrew Cooper
	, George Dunlap , "Jan
 Beulich" , Julien Grall , "Stefano
 Stabellini" 
Subject: [PATCH v6 3/4] libelf: Store maximum PHDR p_align
Date: Wed, 27 Mar 2024 17:51:01 -0400
Message-ID: <20240327215102.136001-4-jason.andryuk@amd.com>
X-Mailer: git-send-email 2.44.0
In-Reply-To: <20240327215102.136001-1-jason.andryuk@amd.com>
References: <20240327215102.136001-1-jason.andryuk@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB03.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CY4PEPF0000EE37:EE_|DM6PR12MB4329:EE_
X-MS-Office365-Filtering-Correlation-Id: db537cd5-42e1-425e-31b8-08dc4ea891d7
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	A53CxzDskgTzRsYz/UFZ3gpBXN3b7heHERXVv3ADATSbaQTS7SuCt0mdFPPKYdI1C7LpzOmvrquhQ7G+c05NmF4fyxkyJGkk6LHQ84/MZiTVgYDbAIaRpOJp1RD76WXw0nQoMpZ264pzKlEb36Hm3gDu+seN0AP0gEkPAKUxyuhlbp/pxGQxT+oyCiqf+NrdZ8M8TqRzM+FM0l6WIBxT/8UE6wTai71kxkh4Gn7OGhLigPiSymBt0jiphiIHVak0BSHLKXCsDo/pCM2g0rKN+APW+fvBlPi8KvcbCd/VGRcSk4PjABLFlzzsTJECaOFdcY6DYsQT3GICTX99n3kuH3r7Sl5AGEdMeYDh1WnSj43pw9hiHdI0uXuIiZE50WVUAo/vX+FoOvZRmWItHlD3glxyLdWnP1FFyUg99Uwtpx3evYCHkSUueadUdfzR0HFpfzUFE+0LUm81h+MFjBMTJnoBA0/vpOmXrxvDF9NZRC4ZdzrBXdV1maY9pAeYYqBaPKRwObEOlZ/BthIONxW5uyMd75QQWz83Qgst72a33uztntckX4C89LCiuDT9RrSllCVaMDFt9lNKc2WuMmPSanW+gTzhmtVgHMUWqW+Hw6eEPx39tKmdU4Z425zQSs5Z3CuX0IaTec10osPv5Lm1O3k5GOnF8CrL52ghkETigUhuvbWlFh9jfD6AeLO57mXqrv7e3blhtWGXjohMYXEliVHIakiB+GJrLYcKWSuIJzk11bUcYpV7/d6Uo9HFN+Y7
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(1800799015)(82310400014)(36860700004)(376005);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Mar 2024 21:55:08.6380
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: db537cd5-42e1-425e-31b8-08dc4ea891d7
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CY4PEPF0000EE37.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4329

While parsing the PHDRs, store the maximum p_align value.  This may be
consulted for moving a PVH image's load address.

Signed-off-by: Jason Andryuk 
---
v6:
New
---
 xen/common/libelf/libelf-loader.c | 15 +++++++++++----
 xen/include/xen/libelf.h          |  1 +
 2 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/xen/common/libelf/libelf-loader.c b/xen/common/libelf/libelf-loader.c
index 629cc0d3e6..a5f6389f82 100644
--- a/xen/common/libelf/libelf-loader.c
+++ b/xen/common/libelf/libelf-loader.c
@@ -468,6 +468,7 @@ void elf_parse_binary(struct elf_binary *elf)
 {
     ELF_HANDLE_DECL(elf_phdr) phdr;
     uint64_t low = -1, high = 0, paddr, memsz;
+    uint64_t max_align = 0, palign;
     unsigned i, count;
 
     count = elf_phdr_count(elf);
@@ -481,17 +482,23 @@ void elf_parse_binary(struct elf_binary *elf)
             continue;
         paddr = elf_uval(elf, phdr, p_paddr);
         memsz = elf_uval(elf, phdr, p_memsz);
-        elf_msg(elf, "ELF: phdr: paddr=%#" PRIx64 " memsz=%#" PRIx64 "\n",
-                paddr, memsz);
+        palign = elf_uval(elf, phdr, p_align);
+        elf_msg(elf,
+                "ELF: phdr: paddr=%#" PRIx64 " memsz=%#" PRIx64 " palign=%#" PRIx64 "\n",
+                paddr, memsz, palign);
         if ( low > paddr )
             low = paddr;
         if ( high < paddr + memsz )
             high = paddr + memsz;
+        if ( max_align < palign )
+            max_align = palign;
     }
     elf->pstart = low;
     elf->pend = high;
-    elf_msg(elf, "ELF: memory: %#" PRIx64 " -> %#" PRIx64 "\n",
-            elf->pstart, elf->pend);
+    elf->palign = max_align;
+    elf_msg(elf,
+            "ELF: memory: %#" PRIx64 " -> %#" PRIx64 " align:%#" PRIx64 "\n",
+            elf->pstart, elf->pend, elf->palign);
 }
 
 elf_errorstatus elf_load_binary(struct elf_binary *elf)
diff --git a/xen/include/xen/libelf.h b/xen/include/xen/libelf.h
index 1c77e3df31..2d971f958e 100644
--- a/xen/include/xen/libelf.h
+++ b/xen/include/xen/libelf.h
@@ -196,6 +196,7 @@ struct elf_binary {
     size_t dest_size;
     uint64_t pstart;
     uint64_t pend;
+    uint64_t palign;
     uint64_t reloc_offset;
 
     uint64_t bsd_symtab_pstart;
-- 
2.44.0



From xen-devel-bounces@lists.xenproject.org Wed Mar 27 21:55:19 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 21:55:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698732.1090790 (Exim 4.92)
	(envelope-from )
	id 1rpbEo-000273-1v; Wed, 27 Mar 2024 21:55:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698732.1090790; Wed, 27 Mar 2024 21:55:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpbEn-00026w-VJ; Wed, 27 Mar 2024 21:55:13 +0000
Received: by outflank-mailman (input) for mailman id 698732;
 Wed, 27 Mar 2024 21:55:11 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpbEl-0001dR-Sy
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 21:55:11 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on20601.outbound.protection.outlook.com
 [2a01:111:f403:2415::601])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ae74426e-ec84-11ee-afe3-a90da7624cb6;
 Wed, 27 Mar 2024 22:55:11 +0100 (CET)
Received: from BN8PR07CA0030.namprd07.prod.outlook.com (2603:10b6:408:ac::43)
 by PH0PR12MB7791.namprd12.prod.outlook.com (2603:10b6:510:280::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.33; Wed, 27 Mar
 2024 21:55:08 +0000
Received: from BN2PEPF000044A9.namprd04.prod.outlook.com
 (2603:10b6:408:ac:cafe::88) by BN8PR07CA0030.outlook.office365.com
 (2603:10b6:408:ac::43) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.13 via Frontend
 Transport; Wed, 27 Mar 2024 21:55:08 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN2PEPF000044A9.mail.protection.outlook.com (10.167.243.103) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Wed, 27 Mar 2024 21:55:07 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Wed, 27 Mar
 2024 16:55:07 -0500
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB05.amd.com
 (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Wed, 27 Mar
 2024 16:55:06 -0500
Received: from fedora.mshome.net (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Wed, 27 Mar 2024 16:55:06 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ae74426e-ec84-11ee-afe3-a90da7624cb6
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=bFrIqIwHnw4I1Jzv5wnCufSzxVPZesBIyEengZO1opcNOZCSmIlcpm9Uk/1zTXlwwrmDY+K2kA4EOl2SaoEGmOW8Cytd6XKhIThVav2DYQ6vdnQLa2Uq+kerU8k8uWv4KjxH8RHCUjw//zcZL/qaj2D/1TpTABFpit28ZmBHdo3yEf0jiwGupeg23uRYR+Xm8xBeOIpHks3/2MymiUd9Nt0eKYd/Tv056Cif4XxR01QlNYrPRdMKK96hAtLIksyp1cTU2rnQidaJFrcH3LhaqWJRpwRe5vxnC+W9Vtxf48fGwp+BjTXyCEWP+FWKRFjJZ0PNB8FDiYlXvUg56iy2uQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=sQPi9MnxIxYvNcw+aMSnS9BZzf8Q8kjV58jecRQgAtM=;
 b=F5YVg+HqXT3k+/iOOEqixe7IM1zw8/wy67AAzdDK5c/7oRWTXRl3+LfnqK86PRb6Xagg21oMGG/0A7+XoMhH4WjMSgPRx0u7/5eLZQ+CD7WKlZSZGLMt8PJxVIoD3rsbibQHtg00xYc8G7wDCvzSyX0VLF06WltKeKA2FV/5KzJWunCI8pgn8BaI7icMjhyDChI3UOpOnrQYYkSa0XtpZ3BjpJesEuBHqYg2h5NZ8LOAhbGrKuAeTp3qAwiknskYcaRZSQfkLZiv3ZhafBydMrGu4Ihpryla2UbieIIhpRRekfpMPHJ45o1879Z4hVwQkKtHiVcSQVPxzUrjgKGshA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=sQPi9MnxIxYvNcw+aMSnS9BZzf8Q8kjV58jecRQgAtM=;
 b=c0g7Xpa/ddR7UySF4vR/WTVzHo/5ZwcARZ0MEtPI1hTLCzJBDtuAPqSFicd1e6KHjiFW+meqZ57wBG60odKIjVXoMl9mi2k81UhmJaM8GVM1iDjvv97n8EqTn2bCUS6BcPgD0enuomaqRa1Sh2r+TVBEoxhuOj0qImnVLcqJmHs=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Jason Andryuk 
To: 
CC: Jason Andryuk , Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Anthony PERARD
	, Juergen Gross , Julien Grall
	
Subject: [PATCH v6 2/4] tools: Move MB/GB() to common-macros.h
Date: Wed, 27 Mar 2024 17:51:00 -0400
Message-ID: <20240327215102.136001-3-jason.andryuk@amd.com>
X-Mailer: git-send-email 2.44.0
In-Reply-To: <20240327215102.136001-1-jason.andryuk@amd.com>
References: <20240327215102.136001-1-jason.andryuk@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB05.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN2PEPF000044A9:EE_|PH0PR12MB7791:EE_
X-MS-Office365-Filtering-Correlation-Id: 1901e956-6295-45c7-4cfc-08dc4ea8912b
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	fVZm54szbFsZFEy+YWu/FNh5ByW1/E4WofAMqJ6e+ZtC3cocYazz/jqOtghItB9+BGorSGKPCbNpgwBVjFmXChZDjk+FXuplHrax2qO476ZX+3oCYd57qRg7xZ0uc8EHK1MtEfjK3IkOa5g9VxtJVNs6ybGDLR3E+kMG4I4bHC9pdkUIe9gIe316IId6NawTXUPRyppvwX/VqzW4Y+Jh2pwTtHB8OT4E5WDBH14Rt/lZLXwEADBeUwQGUdx8uNCB6vv8xUBtENsw5ZdN1orpN+l/e57NY6CsNYUsGJDSN7unxbaXEqzFarO+9HLNJO3nhhhezZolWQYjQi4fdY20mPRBSUANo0BYbetKZgjyDdruPPNqkb2s82Nq8IJPKjDrrQwlyBcIY7cT1nyooJOAWsC+mw9GmpKmr+O/UWuRyQytgLEkqULmigE68zaWrzklwzgl3gRAYykWkwxEo+FRa09e1PY6eivkthFD24foNBv9woArVBkzYXVQ0cWIl7nmm4cOLKAQUpXk38m9epPedYlNa1SbLnXPIcYZp9lIR1tWZJKmdqmpjS7jFVDHI59Km0p1v6j0u+V1UoZws+yEnFbhT5qeFiM8EPxc17nah/rVDSazcmrys828dmts80/gexumPRVpp25l+LTYURW+xzu29ZcPPSpxDlVVFHGxZd8eKo0jAw9eu4jsV/2ffSn3oVp28idrlUhPFAFX1Nk40rtoBms6zhSAmw3c+7sPDAW6HeDMogWG/CitkR0NBTLV
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(36860700004)(1800799015)(376005)(82310400014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Mar 2024 21:55:07.6305
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 1901e956-6295-45c7-4cfc-08dc4ea8912b
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN2PEPF000044A9.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR12MB7791

Consolidate to a single set of common macros for tools.

MB() will gain another use in libelf, so this movement makes it
available.

Requested-by: Jan Beulich 
Signed-off-by: Jason Andryuk 
Reviewed-by: Jan Beulich 
---
v4:
New

v5:
Add Jan's R-b & Req-b
---
 tools/firmware/hvmloader/util.h         | 3 ---
 tools/helpers/init-xenstore-domain.c    | 1 -
 tools/include/xen-tools/common-macros.h | 4 ++++
 tools/libs/light/libxl_internal.h       | 4 ----
 4 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/tools/firmware/hvmloader/util.h b/tools/firmware/hvmloader/util.h
index 87be213dec..14078bde1e 100644
--- a/tools/firmware/hvmloader/util.h
+++ b/tools/firmware/hvmloader/util.h
@@ -38,9 +38,6 @@ void __bug(const char *file, int line) __attribute__((noreturn));
 #define BUG() __bug(__FILE__, __LINE__)
 #define BUG_ON(p) do { if (p) BUG(); } while (0)
 
-#define MB(mb) (mb##ULL << 20)
-#define GB(gb) (gb##ULL << 30)
-
 static inline int test_bit(unsigned int b, const void *p)
 {
     return !!(((const uint8_t *)p)[b>>3] & (1u<<(b&7)));
diff --git a/tools/helpers/init-xenstore-domain.c b/tools/helpers/init-xenstore-domain.c
index 5405842dfe..f38ba8d6b5 100644
--- a/tools/helpers/init-xenstore-domain.c
+++ b/tools/helpers/init-xenstore-domain.c
@@ -20,7 +20,6 @@
 #include "init-dom-json.h"
 
 #define LAPIC_BASE_ADDRESS  0xfee00000UL
-#define GB(x)               ((uint64_t)x << 30)
 
 static uint32_t domid = ~0;
 static char *kernel;
diff --git a/tools/include/xen-tools/common-macros.h b/tools/include/xen-tools/common-macros.h
index 81fba2e9f5..07aed92684 100644
--- a/tools/include/xen-tools/common-macros.h
+++ b/tools/include/xen-tools/common-macros.h
@@ -91,6 +91,10 @@
 #define __AC(X, Y)   (X ## Y)
 #define _AC(X, Y)    __AC(X, Y)
 
+/* Size macros. */
+#define MB(_mb)     (_AC(_mb, ULL) << 20)
+#define GB(_gb)     (_AC(_gb, ULL) << 30)
+
 #define get_unaligned_t(type, ptr) ({                               \
     const struct { type x; } __packed *ptr_ = (typeof(ptr_))(ptr);  \
     ptr_->x;                                                        \
diff --git a/tools/libs/light/libxl_internal.h b/tools/libs/light/libxl_internal.h
index 094d0df9b1..803dbc1a03 100644
--- a/tools/libs/light/libxl_internal.h
+++ b/tools/libs/light/libxl_internal.h
@@ -126,10 +126,6 @@
 #define PVSHIM_BASENAME "xen-shim"
 #define PVSHIM_CMDLINE "pv-shim console=xen,pv"
 
-/* Size macros. */
-#define MB(_mb)     (_AC(_mb, ULL) << 20)
-#define GB(_gb)     (_AC(_gb, ULL) << 30)
-
 #define DIV_ROUNDUP(n, d) (((n) + (d) - 1) / (d))
 
 #define LIBXL__LOGGING_ENABLED
-- 
2.44.0



From xen-devel-bounces@lists.xenproject.org Wed Mar 27 21:55:19 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 21:55:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698731.1090781 (Exim 4.92)
	(envelope-from )
	id 1rpbEk-0001rw-R2; Wed, 27 Mar 2024 21:55:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698731.1090781; Wed, 27 Mar 2024 21:55:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpbEk-0001rp-Nd; Wed, 27 Mar 2024 21:55:10 +0000
Received: by outflank-mailman (input) for mailman id 698731;
 Wed, 27 Mar 2024 21:55:09 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpbEj-0001dR-BF
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 21:55:09 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on20600.outbound.protection.outlook.com
 [2a01:111:f403:2418::600])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ad0e9d23-ec84-11ee-afe3-a90da7624cb6;
 Wed, 27 Mar 2024 22:55:08 +0100 (CET)
Received: from CH2PR08CA0015.namprd08.prod.outlook.com (2603:10b6:610:5a::25)
 by CH3PR12MB9396.namprd12.prod.outlook.com (2603:10b6:610:1d0::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.32; Wed, 27 Mar
 2024 21:55:06 +0000
Received: from CY4PEPF0000EE32.namprd05.prod.outlook.com
 (2603:10b6:610:5a:cafe::20) by CH2PR08CA0015.outlook.office365.com
 (2603:10b6:610:5a::25) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.13 via Frontend
 Transport; Wed, 27 Mar 2024 21:55:06 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 CY4PEPF0000EE32.mail.protection.outlook.com (10.167.242.38) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Wed, 27 Mar 2024 21:55:05 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Wed, 27 Mar
 2024 16:55:04 -0500
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB05.amd.com
 (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Wed, 27 Mar
 2024 16:55:04 -0500
Received: from fedora.mshome.net (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Wed, 27 Mar 2024 16:55:04 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ad0e9d23-ec84-11ee-afe3-a90da7624cb6
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=GdbN+KDAMkJ62GBrKvkgdKlRnwmIuPg5t6b7rvE1ZshHB+eT4JeBBzUvnO22XAwKzdHGvAmK84YSr6jJJeaMh7W8NOtqYRp1hili94v6QRGfwSYV/L8p7LoZ4n1bPhQC6ERaXjVZNw2EVpD1toKWhfLRWOjemz1vCA0D4XeMabHQX9yuZYlileEkXcg0HuaO0JQNWq/m88zeTjRCHfliifXMNItjkyufli/6+5SyWB+CZX60QhNwDfpllcFiuFZyDYc0OURcIyhzvU6ubZutQN0eJWfA5t6WKtYm8TP3pcYoVZEg7+i/gIhlFByDtLo7d55WdeaZluAW/9j+FlWwRA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=kpYFdzJHkuO60SpR1aTtd436m2Cbip6KFJuG8vrlzio=;
 b=GtivoUZaizOp9bN0wYp/dsUIY+aoL5Mj17cirV9DXVWkIkJj82qTxrs7to7VLN+EE8P8HP3W5tQpcnmQ5Qm6LMePx+S0dokTJgLuG1TL3EfMdi8bsHCuyzgLoXjvNDR+wrU5oZmRfXgCmkPsxbW0TnIxbGTgj8uFFLZpyh1DlxY49HJ8Rmrb6huNupAYcgUHeljZG97MXmeWu1O4jsrZjo7cq4s1jMBGLTqwsFMjutFIKWdybP0T6FJaRyfguCVgmhLbrmtfmVbekQYyJ2aP3cdM10LEJl7LDUdv6/oyqY9PEHMeRbY21A4v8tY+vk7xAXTixVdaMUoa4+0ACdQXIg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=kpYFdzJHkuO60SpR1aTtd436m2Cbip6KFJuG8vrlzio=;
 b=4rEtW7lutcfQd4P9DP0d/vWgzEnQjcD6Qa+SvNpcLbCOFTFgY54dbLC7OY7GOXOx4hPlQA7dEbi3+SPo02NmUkMgerl9c/TAk4SO07APOnoa7mikLhfs+ksnuh58i61Yp5cRI1eajw9q1cq9U23UyrD2bpkoBus+SiNfpqtuLiE=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
From: Jason Andryuk 
To: 
CC: Jason Andryuk , Juergen Gross ,
	Julien Grall , Anthony PERARD 
Subject: [PATCH v6 1/4] tools/init-xenstore-domain: Replace variable MB() usage
Date: Wed, 27 Mar 2024 17:50:59 -0400
Message-ID: <20240327215102.136001-2-jason.andryuk@amd.com>
X-Mailer: git-send-email 2.44.0
In-Reply-To: <20240327215102.136001-1-jason.andryuk@amd.com>
References: <20240327215102.136001-1-jason.andryuk@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB05.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CY4PEPF0000EE32:EE_|CH3PR12MB9396:EE_
X-MS-Office365-Filtering-Correlation-Id: a2a330a1-2b12-4784-95a8-08dc4ea88fe8
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	acln6GSUv5TKr2UKAaiFuuljqix3fHDWx+AqVZfdKR6t2R20mSPfCaYEw5m1C7LoIpauVh/CYpKGb0JibrmV4EKzN8bODdvn+AKVLK6zJvhxoPEUNFc3p3oK1XtbSp/eyy0HPt9+4cm2cxw9aoElPzHeMe8+6rc5cf6gCWPyOZtyMUfRFxIAy3fI4iYrj6o5p3/y+V+QynA1JRi5n/nKrr2hpMfVOBqU/Iw+5lsfI899Ax5Jqa9Dsdj5IilS9Lk51bcBrWeCzeAVbp+9efPzMjRcVDv4D9hrxkjwkVYyciOJJHCEWMwXIRlzCZTkP14bb3MaCR2glAjv0E9c9G4XHmT9po0K9KMF++mgnvRXjnn67Ygj4iHeA+WTZ9sfCo0RtwdjC8rjnje7Dqx0kZY/2z7FH7n79wIekSmf+57FGkPqT6OtCK2mx5LpIo0S9KqMBRe6LNOrb6CxD/dwnfCTodKy1xOArFcP4I3/U7zP1pIRZbw+N8+shxHwl2qk1nVCVlMJRk/RvL9qAxL8RPYJl3FcKoLtf572yDNVZVo5tr1pJHQl/i2H3pANxLhvk0m7tXpqInPqDk18zGYo95wT1+Xefo7YTGbQEHCk0vMOo5G/xUqFaFD5QWDM8eUTdnzJv5j/nMbcpHFBuLcZCUATfkDlq2IxSdWB/LKdMpcudPx2ECUKpqYYpIZJPuklA0F39OXJ8ZG1utdbOBuceA/zZHoDFiaqW5Y0crNO4WnKn4HFwCjzHSzGPm0g0kWd9pb3
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(376005)(82310400014)(36860700004)(1800799015);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Mar 2024 21:55:05.4685
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: a2a330a1-2b12-4784-95a8-08dc4ea88fe8
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CY4PEPF0000EE32.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB9396

The local MB() & GB() macros will be replaced with a common
implementation, but those only work with constant values.  Introduce a
static inline mb_to_bytes() in place of the MB() macro to convert the
variable values.

Signed-off-by: Jason Andryuk 
---
v4:
New
---
 tools/helpers/init-xenstore-domain.c | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/tools/helpers/init-xenstore-domain.c b/tools/helpers/init-xenstore-domain.c
index 1683438c5c..5405842dfe 100644
--- a/tools/helpers/init-xenstore-domain.c
+++ b/tools/helpers/init-xenstore-domain.c
@@ -20,7 +20,6 @@
 #include "init-dom-json.h"
 
 #define LAPIC_BASE_ADDRESS  0xfee00000UL
-#define MB(x)               ((uint64_t)x << 20)
 #define GB(x)               ((uint64_t)x << 30)
 
 static uint32_t domid = ~0;
@@ -36,6 +35,11 @@ static xc_evtchn_port_or_error_t console_evtchn;
 static xentoollog_level minmsglevel = XTL_PROGRESS;
 static void *logger;
 
+static inline uint64_t mb_to_bytes(int mem)
+{
+	return (uint64_t)mem << 20;
+}
+
 static struct option options[] = {
     { "kernel", 1, NULL, 'k' },
     { "memory", 1, NULL, 'm' },
@@ -76,8 +80,8 @@ static int build(xc_interface *xch)
     int rv, xs_fd;
     struct xc_dom_image *dom = NULL;
     int limit_kb = (maxmem ? : memory) * 1024 + X86_HVM_NR_SPECIAL_PAGES * 4;
-    uint64_t mem_size = MB(memory);
-    uint64_t max_size = MB(maxmem ? : memory);
+    uint64_t mem_size = mb_to_bytes(memory);
+    uint64_t max_size = mb_to_bytes(maxmem ? : memory);
     struct e820entry e820[3];
     struct xen_domctl_createdomain config = {
         .ssidref = SECINITSID_DOMU,
-- 
2.44.0



From xen-devel-bounces@lists.xenproject.org Wed Mar 27 21:55:19 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 21:55:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698730.1090770 (Exim 4.92)
	(envelope-from )
	id 1rpbEj-0001dj-Jj; Wed, 27 Mar 2024 21:55:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698730.1090770; Wed, 27 Mar 2024 21:55:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpbEj-0001dc-Gw; Wed, 27 Mar 2024 21:55:09 +0000
Received: by outflank-mailman (input) for mailman id 698730;
 Wed, 27 Mar 2024 21:55:08 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpbEi-0001dR-LR
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 21:55:08 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on20600.outbound.protection.outlook.com
 [2a01:111:f403:2417::600])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ab82006f-ec84-11ee-afe3-a90da7624cb6;
 Wed, 27 Mar 2024 22:55:07 +0100 (CET)
Received: from BN8PR04CA0035.namprd04.prod.outlook.com (2603:10b6:408:70::48)
 by PH7PR12MB7453.namprd12.prod.outlook.com (2603:10b6:510:20a::10)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.30; Wed, 27 Mar
 2024 21:55:03 +0000
Received: from BN2PEPF000044AA.namprd04.prod.outlook.com
 (2603:10b6:408:70:cafe::52) by BN8PR04CA0035.outlook.office365.com
 (2603:10b6:408:70::48) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.13 via Frontend
 Transport; Wed, 27 Mar 2024 21:55:02 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN2PEPF000044AA.mail.protection.outlook.com (10.167.243.105) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Wed, 27 Mar 2024 21:55:02 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Wed, 27 Mar
 2024 16:55:02 -0500
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB05.amd.com
 (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Wed, 27 Mar
 2024 16:55:01 -0500
Received: from fedora.mshome.net (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Wed, 27 Mar 2024 16:55:00 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ab82006f-ec84-11ee-afe3-a90da7624cb6
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=DFloiD0pFAPMy1HkCthm5GyPGjFVubBQFmDYcKWsgfboQuTXvsxWkfexWzko7mcFZeTh9jb0CKKygnNQadZQ5PzCeIpfGZ6gRxoxMhlzcQfIxlhOH7V3YkO+g051prS3acGX5t8SYeXE85mauDMMaBbpnDc7cgHDHh+B51BYO3F85HyFeXDz/pY9RMHYx4Ruk93Dwh2SAeeospxMcKjihI5c1Gwr3+nyxocawT59zCNwRBjhew7GmBMcATqeqYEzlY3P6NbidBWbhgLRRpscdhOOOwGYF6HuEz+VS/mNpcirpBkmrQZm7Y4gtfU5/JW2EwgvPpN04ZV13NqhYwvk1Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=7JGDFLL2Mbk36fV41ml7871DsjzHeNM5Ecm0pDvDuaM=;
 b=E9A/+bOl5YE5Q8iEn86/S95OmJK5gM/IKtC6nXeNe8TaDIjctO6CDc0sPyZKd9G9845jr5+SIMV8gIU3N0fL0uvP2vwRdABXjPqj0U9lN54uOf71nMXaehB/dVzM5NtCqV45Y6yFybmJYIz6mhGycXTGfzY01P1QVsGt2WlCXQRwOOrEapIiJc45jtojZmZgwTod746k7ilm6tcnu6ec31qCj+94VEVno9IPhmeeiLUQI70PmlvUe86g1AoQsAmw+FTnAHCyZAVf4X+p5fg0+MACfau+JwJQb10p5i22nFF7Mkz4fzKVq94E637c98swF2+0UM8BRJeP/NqR3ubvaw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=7JGDFLL2Mbk36fV41ml7871DsjzHeNM5Ecm0pDvDuaM=;
 b=hdVu0LKQAuq7/g3aKCbAbvbjdefPBK3aCNr+8TUBbLxqDcP32HdjimqkAf1X34Mh/dI0AzvZyEN4rBMywO91HScJwUoQGtGgLh7Y7HXGGLqFU80XR3YeU7Hhgud+4W85cVGvseIBxJ+WOKIKmiZf/tmppG3KAFmZMlPdy8gz9bc=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Jason Andryuk 
To: 
CC: Jason Andryuk , Juergen Gross ,
	Julien Grall , Anthony PERARD ,
	Jan Beulich , Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , George Dunlap
	, Stefano Stabellini 
Subject: [PATCH v6 0/4] x86/pvh: Support relocating dom0 kernel
Date: Wed, 27 Mar 2024 17:50:58 -0400
Message-ID: <20240327215102.136001-1-jason.andryuk@amd.com>
X-Mailer: git-send-email 2.44.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB05.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN2PEPF000044AA:EE_|PH7PR12MB7453:EE_
X-MS-Office365-Filtering-Correlation-Id: 1c9bd374-7da5-4b47-c9c7-08dc4ea88e16
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	6wuKSjbm38MKPAWQeLjRrdhTrj61vXp+ifHTWw4f6WGngaEu9rk5nxXWU+iCBAUz/uevR3QybvAc7XFGWML8lCeqHDpJDVXo+eOq+rvtvZW/XGHCHQT9GiI3mV5kVyv2qSdbHOao+KO9cpc3M8sMEIh51YXovLA9FRM0jsKxE9xj06CqzrVBIyuimnteUPvuoBTlIjLx/Go9hajU/Ynr+pvcH3XfFXKqvNw29XhET03Fmf16HSvgh2LEHxyiVbs0LR7qfuEzhK7MPUE4RTzlDUWVaoeaRGosIHgdgbL4MilNRCzz7rsfZpjrqD2MSUawtld0oeEKgoFV6HjvHFse0a0ly5f9KZvk0Mzlf+ZKYO3FP0Y5QCh8mKG+OQJ/WqSg/B8Lw9/Ve9UIv/lyk3nn7PUvgMObVKkMRY7ZaxPzlV8xXc7+fbD64bd2E8XvBwaRrlt+Es/vd7Ts8rxIn+ElqEjobztfm85RBUupZQBPm3zUYJVdvcuZCAXEZoakD16RStYNL1Bo2rp5cjPya3J3nvEbJuSQtWufGhQoGiRXRi8vkuECB4BEZ8q7zOo2hiGZZXPF2+YwKMvy+I/a4JYarRjPaodbV9FdI9S6GclCtpH5tqOyZP8WiOu/n2ZlszqzTQfDhwMyar5sWRqA4jU82B4g9eFV7LeWkwAawRCpQCV5KXUyHVPkWM6gOxSsH01DxqmGWhGPOjC+1YzEaCKo50aLbmZURw0Uq/H8Vym8FgFHcLdCOIGp3Hs0bIO5AQDx
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(82310400014)(1800799015)(36860700004)(376005);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Mar 2024 21:55:02.4785
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 1c9bd374-7da5-4b47-c9c7-08dc4ea88e16
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN2PEPF000044AA.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB7453

Xen tries to load a PVH dom0 kernel at the fixed guest physical address
from the elf headers.  For Linux, this defaults to 0x1000000 (16MB), but
it can be configured.

Unfortunately there exist firmwares that have reserved regions at this
address, so Xen fails to load the dom0 kernel since it's not RAM.

The other issue is that the Linux PVH entry point is not
position-independent.  It expects to run at the compiled
CONFIG_PHYSICAL_ADDRESS.

This patch set expands the PVH dom0 builder to try to relocate the
kernel if needed and possible.  XEN_ELFNOTE_PHYS32_RELOC is added for
kernels to indicate they are relocatable and their acceptable address
range and alignment.

v6:
Choose the alignment from the Note if specified, or the Maximum PHDR
p_align value if greater than PAGE_SIZE.  Otherwise, it falls back to
the default 2MB.

Patches from v5 commited:
853c71dfbf xen/elfnote: Specify ELF Notes are x86-specific
7d8c9b4e8d libelf: Expand ELF note printing
8802230bfa Revert "xen/x86: bzImage parse kernel_alignment"

The first and second patches move MB/GB() to common-macros.h.

The third patch stores the maximum p_align value from the ELF PHDRs.

The fourth patch expands the pvh dom0 kernel placement code.

I'll post an additional patch showing the Linux changes to make PVH
relocatable.

Jason Andryuk (4):
  tools/init-xenstore-domain: Replace variable MB() usage
  tools: Move MB/GB() to common-macros.h
  libelf: Store maximum PHDR p_align
  x86/PVH: Support relocatable dom0 kernels

 tools/firmware/hvmloader/util.h         |   3 -
 tools/helpers/init-xenstore-domain.c    |  11 ++-
 tools/include/xen-tools/common-macros.h |   4 +
 tools/libs/light/libxl_internal.h       |   4 -
 xen/arch/x86/hvm/dom0_build.c           | 108 ++++++++++++++++++++++++
 xen/common/libelf/libelf-dominfo.c      |  35 ++++++++
 xen/common/libelf/libelf-loader.c       |  15 +++-
 xen/common/libelf/libelf-private.h      |   1 +
 xen/include/public/elfnote.h            |  16 +++-
 xen/include/xen/libelf.h                |   5 ++
 10 files changed, 186 insertions(+), 16 deletions(-)

-- 
2.44.0



From xen-devel-bounces@lists.xenproject.org Wed Mar 27 21:55:21 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 21:55:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698734.1090811 (Exim 4.92)
	(envelope-from )
	id 1rpbEv-0002jN-LT; Wed, 27 Mar 2024 21:55:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698734.1090811; Wed, 27 Mar 2024 21:55:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpbEv-0002j8-IW; Wed, 27 Mar 2024 21:55:21 +0000
Received: by outflank-mailman (input) for mailman id 698734;
 Wed, 27 Mar 2024 21:55:20 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpbEu-0002MB-5P
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 21:55:20 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on20601.outbound.protection.outlook.com
 [2a01:111:f403:200a::601])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b25f16bf-ec84-11ee-a1ef-f123f15fe8a2;
 Wed, 27 Mar 2024 22:55:18 +0100 (CET)
Received: from SA9PR13CA0137.namprd13.prod.outlook.com (2603:10b6:806:27::22)
 by DM4PR12MB6374.namprd12.prod.outlook.com (2603:10b6:8:a3::18) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.24; Wed, 27 Mar
 2024 21:55:13 +0000
Received: from SA2PEPF000015CD.namprd03.prod.outlook.com
 (2603:10b6:806:27:cafe::b8) by SA9PR13CA0137.outlook.office365.com
 (2603:10b6:806:27::22) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.12 via Frontend
 Transport; Wed, 27 Mar 2024 21:55:13 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 SA2PEPF000015CD.mail.protection.outlook.com (10.167.241.203) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Wed, 27 Mar 2024 21:55:12 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Wed, 27 Mar
 2024 16:55:09 -0500
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB05.amd.com
 (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Wed, 27 Mar
 2024 16:55:08 -0500
Received: from fedora.mshome.net (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Wed, 27 Mar 2024 16:55:07 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b25f16bf-ec84-11ee-a1ef-f123f15fe8a2
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=KBbCMWxeRRXGV8ZKEvgZeg7QOYPpX9a15aLN8jN95geBNAJVcV4Gqyligb7c5IsP2oGUba1Bh1uYktvULwd/QYpM+Xv/HvCrxLg/rIQ/GgYvO3yRrJVCTqQLdor+eY7TxRSgUJlwqP98DrPwmCY+nQGEXkz4QKlc4/ut29E4sBnghG+D+M+O0duRDpcucVoIJxlG9Uqc/2WLkbmwBOicoYQwhjd35YKKVWC6YQqXVIOFfrAR5BXvyZhKh4rDU/Ckj4cZh7qsXG92CrXGoatPf7nohNolmIBMgSzVtzU7pJDCv2Ex9feVQX8YCbxteVQwjZnfUuPrMIuJWyKJq9V/eA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=QjKlJSg9cT/vFlsYwh8UTOiO/XXv5HOBwoiNoPGXXHs=;
 b=TE3+CQVWuxwMqZQHH7TS2vU9zrb7/p+UVvIgZV8V0oXdk1Umn17c2A2j5edNTqJav7sgQOASnLYRXVpo4CWeuehI3RzYNA0mRa/BBOPz4zfvipGWFleTDnNvrtrsKuQM3bNk7oexOVs1O6BCza/vP9K0HyhCLMotty1V1c3IY3+G26pQ/gogrF0YIv7jBDrkxjWxfvdOlfq+dOvL0AiLbW+tcxlB3AGFiGFPkTPLF1daursQ0LO1CTW9LYo9AFYnvb8D1f6LS2qU45I4Uo2TdvlhlPRY6LWtx9H43dsrZr2Nf6CjMIUQynTaiOsSN3zE/RFj+KE4MvafmD6PK/ySGQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=QjKlJSg9cT/vFlsYwh8UTOiO/XXv5HOBwoiNoPGXXHs=;
 b=pHitPNXv/yzRAXIHK42gbMeSAQZ7NSvfsltQ7Ic6X/K5ZDw7wcfQdCxZNc7KCJohr8p5Rh3M9HQ9wk9ovrUy5oZxvRigypTfselUZ78ef+3fgvSiBw/tg9VRxhfXijxKgcF2M0EHQOc3at6hQQq8MEySdyfdCEK0J4fOM4+Uo5Y=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
From: Jason Andryuk 
To: 
CC: Jason Andryuk , Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , George Dunlap
	, Julien Grall , Stefano Stabellini
	
Subject: [PATCH v6 4/4] x86/PVH: Support relocatable dom0 kernels
Date: Wed, 27 Mar 2024 17:51:02 -0400
Message-ID: <20240327215102.136001-5-jason.andryuk@amd.com>
X-Mailer: git-send-email 2.44.0
In-Reply-To: <20240327215102.136001-1-jason.andryuk@amd.com>
References: <20240327215102.136001-1-jason.andryuk@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB05.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SA2PEPF000015CD:EE_|DM4PR12MB6374:EE_
X-MS-Office365-Filtering-Correlation-Id: 954a892c-737b-4c0c-99e0-08dc4ea8941d
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	EUd2vsDMTegDgLCUkY1YpnRGamNu3O0oUC2xGITCWvZVw/mhOB77/1vauVvCuipQSVyH7ndRT4z0y2gfrZGHePA9HPGEhfs0vRZ9vB8VvVo8evi1efrp+8uL66N5s1pnZoUaUeozejZ5LCW9SVdatJy0KvD7Veisl9qFuIHPJ9Z+W0tzZBS9AEiIlTX6rDStZPCU9ZLdGjlwzeewUtvb+ie2XDeypiC7GQdLfAF58BevisoqbRShHIopZvLNqSsJksgldPIclyFUyGep01sfjInxAd+lF7h0G1po3mxy2KhQqyrpjOFN0VSuINgbwKYhgqJ/XHguj/xH+gQJw7Bklk6qssfmuHih6WHC4kNGAyK8CFcN2LTOE0lkf1ZFxraOEBbUZYXb1AmwZqgtvVEDReZeuyQCpHNn7Tv7SNYITNV4uDwyRzmm8ukAM2oxwsitaSLwmULxUMpkPlObOWe4njUxg1mNhqljTrSB6ycXba6Lqj7E3jv07aKmDWQvLWc8DCiN5xYA3ndq0bR9kbm94aKc18bEO4dIvbyN9G+2fGIgrMaAY5wrkENJOZHMkpxCgCskQ2N5SSZXqS2xrHLyFazAJMj18cUUXfb+RCaz374J5lJ3ah8dPM6dgEolRtFIHaCUR+lpEMSv34fhWMln06IMDUXbMPA4mO41jwZuj5YberT3iaoGVQlCFgLJ47jI9h/WealIaMNG1MvB0VLFBbH4Wk5C03Dt+u2lG/uPDgvifbkTamgscS/L7GJe1DHO
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(1800799015)(376005)(82310400014)(36860700004);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Mar 2024 21:55:12.5582
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 954a892c-737b-4c0c-99e0-08dc4ea8941d
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SA2PEPF000015CD.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB6374

Xen tries to load a PVH dom0 kernel at the fixed guest physical address
from the elf headers.  For Linux, this defaults to 0x1000000 (16MB), but
it can be configured.

Unfortunately there exist firmwares that have reserved regions at this
address, so Xen fails to load the dom0 kernel since it's not RAM.

The PVH entry code is not relocatable - it loads from absolute
addresses, which fail when the kernel is loaded at a different address.
With a suitably modified kernel, a reloctable entry point is possible.

Add XEN_ELFNOTE_PHYS32_RELOC which specifies optional alignment,
minimum, and maximum addresses needed for the kernel.  The presence of
the NOTE indicates the kernel supports a relocatable entry path.

Change the loading to check for an acceptable load address.  If the
kernel is relocatable, support finding an alternate load address.

The primary motivation for an explicit align field is that Linux has a
configurable CONFIG_PHYSICAL_ALIGN field.  This value is present in the
bzImage setup header, but not the ELF program headers p_align, which
report 2MB even when CONFIG_PHYSICAL_ALIGN is greater.  Since a kernel
is only considered relocatable if the PHYS32_RELOC elf note is present,
the alignment contraints can just be specified within the note instead
of searching for an alignment value via a heuristic.

Load alignment uses the PHYS32_RELOC note value if specified.
Otherwise, the maxmum ELF PHDR p_align value is selected if greater than
or equal to PAGE_SIZE.  Finally, the fallback default is 2MB.

libelf-private.h includes common-macros.h to satisfy the fuzzer build.

Link: https://gitlab.com/xen-project/xen/-/issues/180
Signed-off-by: Jason Andryuk 
---
ELF Note printing looks like:
(XEN) ELF: note: PHYS32_RELOC align: 0x200000 min: 0x1000000 max: 0x3fffffff

v2:
Use elfnote for min, max & align - use 64bit values.
Print original and relocated memory addresses
Use check_and_adjust_load_address() name
Return relocated base instead of offset
Use PAGE_ALIGN
Don't load above max_phys (expected to be 4GB in kernel elf note)
Use single line comments
Exit check_load_address loop earlier
Add __init to find_kernel_memory()

v3:
Remove kernel_start/end page rounding
Change loop comment to rely on a sorted memory map.
Reorder E820_RAM check first
Use %p for dest_base
Use PRIpaddr
Use 32bit phys_min/max/align
Consolidate to if ( x || y ) continue
Use max_t
Add parms->phys_reloc
Use common "%pd kernel: " prefix for messages
Re-order phys_entry assignment
Print range ends inclusively
Remove extra "Unable to load kernel" message
s/PVH_RELOCATION/PHYS32_RELOC/
Make PHYS32_RELOC contents optional
Use 2MB default alignment
Update ELF Note comment
Update XEN_ELFNOTE_MAX

v4:
Cast dest_base to uintptr_t
Use local start variable
Mention e820 requiring adjacent entries merged
Remove extra whitespace
Re-word elfnote comment & mention x86
Use ELFNOTE_NAME
Return -ENOSPC
Use ! instead of == 0
Check kend - 1 to avoid off by one
libelf: Use MB/GB() to define the size.
Use ARCH_PHYS_* defines

v5:
Place kernel in higher memory addresses
Remove stray semicolons
ELFNOTE_NAME comment about newline
Make PHYS32_RELOC element order align, min, max
Re-word PHYS32_RELOC comment
Move phys_align next to other bool variables

v6:
Select alignment from, in order, Note, PHDRs, then default
---
 xen/arch/x86/hvm/dom0_build.c      | 108 +++++++++++++++++++++++++++++
 xen/common/libelf/libelf-dominfo.c |  35 ++++++++++
 xen/common/libelf/libelf-private.h |   1 +
 xen/include/public/elfnote.h       |  16 ++++-
 xen/include/xen/libelf.h           |   4 ++
 5 files changed, 163 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index 0ceda4140b..01f39d650e 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -537,6 +537,111 @@ static paddr_t __init find_memory(
     return INVALID_PADDR;
 }
 
+static bool __init check_load_address(
+    const struct domain *d, const struct elf_binary *elf)
+{
+    paddr_t kernel_start = (uintptr_t)elf->dest_base;
+    paddr_t kernel_end = kernel_start + elf->dest_size;
+    unsigned int i;
+
+    /* Relies on a sorted memory map with adjacent entries merged. */
+    for ( i = 0; i < d->arch.nr_e820; i++ )
+    {
+        paddr_t start = d->arch.e820[i].addr;
+        paddr_t end = start + d->arch.e820[i].size;
+
+        if ( start >= kernel_end )
+            return false;
+
+        if ( d->arch.e820[i].type == E820_RAM &&
+             start <= kernel_start &&
+             end >= kernel_end )
+            return true;
+    }
+
+    return false;
+}
+
+/* Find an e820 RAM region that fits the kernel at a suitable alignment. */
+static paddr_t __init find_kernel_memory(
+    const struct domain *d, struct elf_binary *elf,
+    const struct elf_dom_parms *parms)
+{
+    paddr_t kernel_size = elf->dest_size;
+    unsigned int align;
+    int i;
+
+    if ( parms->phys_align != UNSET_ADDR32 )
+        align = parms->phys_align;
+    else if ( elf->palign > PAGE_SIZE )
+        align = elf->palign;
+    else
+        align = MB(2);
+
+    /* Search backwards to find the highest address. */
+    for ( i = d->arch.nr_e820 - 1; i >= 0 ; i-- )
+    {
+        paddr_t start = d->arch.e820[i].addr;
+        paddr_t end = start + d->arch.e820[i].size;
+        paddr_t kstart, kend;
+
+        if ( d->arch.e820[i].type != E820_RAM ||
+             d->arch.e820[i].size < kernel_size )
+            continue;
+
+        if ( start > parms->phys_max )
+            continue;
+
+        if ( end - 1 > parms->phys_max )
+            end = parms->phys_max + 1;
+
+        kstart = (end - kernel_size) & ~(align - 1);
+        kend = kstart + kernel_size;
+
+        if ( kstart < parms->phys_min )
+            return 0;
+
+        if ( kstart >= start && kend <= end )
+            return kstart;
+    }
+
+    return 0;
+}
+
+/* Check the kernel load address, and adjust if necessary and possible. */
+static bool __init check_and_adjust_load_address(
+    const struct domain *d, struct elf_binary *elf, struct elf_dom_parms *parms)
+{
+    paddr_t reloc_base;
+
+    if ( check_load_address(d, elf) )
+        return true;
+
+    if ( !parms->phys_reloc )
+    {
+        printk("%pd kernel: Address conflict and not relocatable\n", d);
+        return false;
+    }
+
+    reloc_base = find_kernel_memory(d, elf, parms);
+    if ( !reloc_base )
+    {
+        printk("%pd kernel: Failed find a load address\n", d);
+        return false;
+    }
+
+    if ( opt_dom0_verbose )
+        printk("%pd kernel: Moving [%p, %p] -> [%"PRIpaddr", %"PRIpaddr"]\n", d,
+               elf->dest_base, elf->dest_base + elf->dest_size - 1,
+               reloc_base, reloc_base + elf->dest_size - 1);
+
+    parms->phys_entry = reloc_base +
+                            (parms->phys_entry - (uintptr_t)elf->dest_base);
+    elf->dest_base = (char *)reloc_base;
+
+    return true;
+}
+
 static int __init pvh_load_kernel(struct domain *d, const module_t *image,
                                   unsigned long image_headroom,
                                   module_t *initrd, void *image_base,
@@ -585,6 +690,9 @@ static int __init pvh_load_kernel(struct domain *d, const module_t *image,
     elf.dest_base = (void *)(parms.virt_kstart - parms.virt_base);
     elf.dest_size = parms.virt_kend - parms.virt_kstart;
 
+    if ( !check_and_adjust_load_address(d, &elf, &parms) )
+        return -ENOSPC;
+
     elf_set_vcpu(&elf, v);
     rc = elf_load_binary(&elf);
     if ( rc < 0 )
diff --git a/xen/common/libelf/libelf-dominfo.c b/xen/common/libelf/libelf-dominfo.c
index 0cdb419b8a..260294d0ed 100644
--- a/xen/common/libelf/libelf-dominfo.c
+++ b/xen/common/libelf/libelf-dominfo.c
@@ -17,6 +17,14 @@
 
 #include "libelf-private.h"
 
+#if defined(__i386__) || defined(__x86_64__)
+#define ARCH_PHYS_MIN_DEFAULT   0
+#define ARCH_PHYS_MAX_DEFAULT   (GB(4) - 1)
+#else
+#define ARCH_PHYS_MIN_DEFAULT   0
+#define ARCH_PHYS_MAX_DEFAULT   0
+#endif
+
 /* ------------------------------------------------------------------------ */
 /* xen features                                                             */
 
@@ -125,6 +133,7 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
         [XEN_ELFNOTE_SUSPEND_CANCEL] = { "SUSPEND_CANCEL", ELFNOTE_INT },
         [XEN_ELFNOTE_MOD_START_PFN] = { "MOD_START_PFN", ELFNOTE_INT },
         [XEN_ELFNOTE_PHYS32_ENTRY] = { "PHYS32_ENTRY", ELFNOTE_INT },
+        [XEN_ELFNOTE_PHYS32_RELOC] = { "PHYS32_RELOC", ELFNOTE_NAME },
     };
 /* *INDENT-ON* */
 
@@ -132,6 +141,7 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
     uint64_t val = 0;
     unsigned int i;
     unsigned type = elf_uval(elf, note, type);
+    unsigned descsz = elf_uval(elf, note, descsz);
 
     if ( (type >= sizeof(note_desc) / sizeof(note_desc[0])) ||
          (note_desc[type].name == NULL) )
@@ -228,6 +238,27 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
     case XEN_ELFNOTE_PHYS32_ENTRY:
         parms->phys_entry = val;
         break;
+
+    case XEN_ELFNOTE_PHYS32_RELOC:
+        parms->phys_reloc = true;
+
+        if ( descsz >= 4 )
+        {
+            parms->phys_align = elf_note_numeric_array(elf, note, 4, 0);
+            elf_msg(elf, " align: %#"PRIx32, parms->phys_align);
+        }
+        if ( descsz >= 8 )
+        {
+            parms->phys_min = elf_note_numeric_array(elf, note, 4, 1);
+            elf_msg(elf, " min: %#"PRIx32, parms->phys_min);
+        }
+        if ( descsz >= 12 )
+        {
+            parms->phys_max = elf_note_numeric_array(elf, note, 4, 2);
+            elf_msg(elf, " max: %#"PRIx32, parms->phys_max);
+        }
+
+        break;
     }
 
     if ( note_desc[type].type == ELFNOTE_NAME)
@@ -543,6 +574,10 @@ elf_errorstatus elf_xen_parse(struct elf_binary *elf,
     parms->p2m_base = UNSET_ADDR;
     parms->elf_paddr_offset = UNSET_ADDR;
     parms->phys_entry = UNSET_ADDR32;
+    parms->phys_align = UNSET_ADDR32;
+    parms->phys_min = ARCH_PHYS_MIN_DEFAULT;
+    parms->phys_max = ARCH_PHYS_MAX_DEFAULT;
+    parms->phys_reloc = false;
 
     /* Find and parse elf notes. */
     count = elf_phdr_count(elf);
diff --git a/xen/common/libelf/libelf-private.h b/xen/common/libelf/libelf-private.h
index 47db679966..98cac65bc5 100644
--- a/xen/common/libelf/libelf-private.h
+++ b/xen/common/libelf/libelf-private.h
@@ -71,6 +71,7 @@
 #endif
 #include 
 #include 
+#include 
 
 #ifndef FUZZ_NO_LIBXC
 #include "xenctrl.h"
diff --git a/xen/include/public/elfnote.h b/xen/include/public/elfnote.h
index 1d84b05f44..a2f89bdc40 100644
--- a/xen/include/public/elfnote.h
+++ b/xen/include/public/elfnote.h
@@ -196,10 +196,24 @@
  */
 #define XEN_ELFNOTE_PHYS32_ENTRY 18
 
+/*
+ * Physical loading constraints for PVH kernels
+ *
+ * The presence of this note indicates the kernel supports relocating itself.
+ *
+ * The note may include up to three 32bit values to place constraints on the
+ * guest physical loading addresses and alignment for a PVH kernel.  Values
+ * are read in the following order:
+ *  - a required start alignment (default 0x200000)
+ *  - a minimum address for the start of the image (default 0)
+ *  - a maximum address for the last byte of the image (default 0xffffffff)
+ */
+#define XEN_ELFNOTE_PHYS32_RELOC 19
+
 /*
  * The number of the highest elfnote defined.
  */
-#define XEN_ELFNOTE_MAX XEN_ELFNOTE_PHYS32_ENTRY
+#define XEN_ELFNOTE_MAX XEN_ELFNOTE_PHYS32_RELOC
 
 /*
  * System information exported through crash notes.
diff --git a/xen/include/xen/libelf.h b/xen/include/xen/libelf.h
index 2d971f958e..9ac530acc2 100644
--- a/xen/include/xen/libelf.h
+++ b/xen/include/xen/libelf.h
@@ -426,6 +426,7 @@ struct elf_dom_parms {
     enum xen_pae_type pae;
     bool bsd_symtab;
     bool unmapped_initrd;
+    bool phys_reloc;
     uint64_t virt_base;
     uint64_t virt_entry;
     uint64_t virt_hypercall;
@@ -435,6 +436,9 @@ struct elf_dom_parms {
     uint32_t f_supported[XENFEAT_NR_SUBMAPS];
     uint32_t f_required[XENFEAT_NR_SUBMAPS];
     uint32_t phys_entry;
+    uint32_t phys_align;
+    uint32_t phys_min;
+    uint32_t phys_max;
 
     /* calculated */
     uint64_t virt_kstart;
-- 
2.44.0



From xen-devel-bounces@lists.xenproject.org Wed Mar 27 21:59:55 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Mar 2024 21:59:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698747.1090821 (Exim 4.92)
	(envelope-from )
	id 1rpbJJ-0004OA-8M; Wed, 27 Mar 2024 21:59:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698747.1090821; Wed, 27 Mar 2024 21:59:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpbJJ-0004O3-5d; Wed, 27 Mar 2024 21:59:53 +0000
Received: by outflank-mailman (input) for mailman id 698747;
 Wed, 27 Mar 2024 21:59:51 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpbJH-0004Nw-CE
 for xen-devel@lists.xenproject.org; Wed, 27 Mar 2024 21:59:51 +0000
Received: from NAM04-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam04on20600.outbound.protection.outlook.com
 [2a01:111:f403:2408::600])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 541e483e-ec85-11ee-a1ef-f123f15fe8a2;
 Wed, 27 Mar 2024 22:59:49 +0100 (CET)
Received: from SN6PR05CA0003.namprd05.prod.outlook.com (2603:10b6:805:de::16)
 by PH8PR12MB7277.namprd12.prod.outlook.com (2603:10b6:510:223::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.32; Wed, 27 Mar
 2024 21:59:45 +0000
Received: from SN1PEPF000252A0.namprd05.prod.outlook.com
 (2603:10b6:805:de:cafe::2a) by SN6PR05CA0003.outlook.office365.com
 (2603:10b6:805:de::16) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.12 via Frontend
 Transport; Wed, 27 Mar 2024 21:59:45 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 SN1PEPF000252A0.mail.protection.outlook.com (10.167.242.7) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Wed, 27 Mar 2024 21:59:45 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Wed, 27 Mar
 2024 16:59:44 -0500
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB05.amd.com
 (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Wed, 27 Mar
 2024 16:59:44 -0500
Received: from fedora.mshome.net (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Wed, 27 Mar 2024 16:59:44 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 541e483e-ec85-11ee-a1ef-f123f15fe8a2
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=jmuYrceoDRywpToHs5bxVHyNWSMcM8jwLM5k28v/fHNOpc2NDOa0CtCNIC0G/NePrGX2EX391hBET64A60L9n5C9pGzo2FYR7KmyNjcHY+70Oaw6n60njeyRJC0OMBzBY0mTU9pHpCKxOJTdduoIU3POdhu9tWOCgZIS7t38O5PAm7Vw/qZ/A+a8DmkwBjq/Iab4VDWkFa0WO64ZGhYn2Ewb9CrPwY88zNdyzqBbI3u2xq1VFbphaomAZkJJNfiRuVtCmSMFE40Ig9Js3nboc61EHBxHUf5uy1zlhskXf/9teTFUShZ9ZHnwPmO+KObepYd2RqqQ/qPK4anOxZ+59Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Og9z5NS1Gp8l+VL85kWBQUlig+xL3ZRE2X5dLC40Fw4=;
 b=UwBq+f5xhN5ZP952P8n7e0/4XdU/awPY00AyYdccfxJddz7po96tveh2ld6j6KESHGClIwOD0n5dur5/FkV+0ybqH6BaNOs0JbkIBDNB/ngSj1kNJNL4ijS8ceoJnylASMBqN8rUdZN8RFUhrqKUtZcOaob95fgY4qhuOOFqAjPc02Acpt1QEBTMzL1a3wMsBnt1rBz4Tecwt26mW693mayooDuvbi6tFt4SxI6/u+C3xdDVtbdHWjNampesPfz7qi6qopTKzE55jFNgWU3LiLV0mQctZgfQE6aYKbg2ZrvvMuOcfPB+Nx1ek06cjTi0F/NUsP1k6hwNFhb2TIeGfg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=Og9z5NS1Gp8l+VL85kWBQUlig+xL3ZRE2X5dLC40Fw4=;
 b=pc5S1ZnNwQDP9ZrnPHv/+oe0eWC9ATWX6c5eRDyZjQKFdNC7aalXLGvACqzQBBnXwaON6nn7P2Y7D021EnCt2bRezPGdDXCn6j6FwE6fDt/UV8blxJ7YaYuBQqyBA+33x6OmDdrMabgDU+jowhisfCp8Bwa09wtqYwd4ikO1hXw=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
From: Jason Andryuk 
To: 
CC: Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, Andrew Cooper , "Juergen
 Gross" , Boris Ostrovsky , Jason
 Andryuk 
Subject: [PATCH v6] RFC: x86/pvh: Make Xen PVH entrypoint PIC for x86-64
Date: Wed, 27 Mar 2024 17:55:46 -0400
Message-ID: <20240327215546.138154-1-jason.andryuk@amd.com>
X-Mailer: git-send-email 2.44.0
In-Reply-To: <20240327215102.136001-1-jason.andryuk@amd.com>
References: <20240327215102.136001-1-jason.andryuk@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB05.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF000252A0:EE_|PH8PR12MB7277:EE_
X-MS-Office365-Filtering-Correlation-Id: 08fd688c-55fb-417a-bb87-08dc4ea936bc
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	7L97zRHuql9WLV3o5SnMF8ZWceCCMHrUffM7HHg+uGzaqHWjJxhHTUXynIGMeBRjRk1C+mtoAgtPMpEO8J3RhT8ykRyfFV3lZsGsSdD7GqY2Kz0xCN5IFb1Z3fLv8LvKUf6PdN+V/V4t/cm8bnpV9kLEOsiOleJqU3W3iAmZFDV+5OzsQk7wtfg8ALlyXU290tNuSXz+yvShRdpLUGwrufba1w0zrMqYyYbhYvrm5rCqx4QAYuKik0kZv/CxSTBPvRXTw9Jje77yIV3UO60faSJyCrOq0NXnW6aqpOKVdlNkCKcJIp9VAC0AINn4o9d4IKfMu+CGE5655Mr2OpK9UYJFWf45ArvgeHUAN2jKrJi9NLGO9j9/pwRMsH8Jbc0Sj4M7vaW1Zqi0omCtDLCx2emf9zCAtpRGhaAaEKAQX+EAua+Enh6B7nqecyRZujN0mM0GQGPhxCqBjqf0BOaGnsLQPExLsVXk7pRTo8dH/16QfP093f00qY2GemH51l/DHUWd9CzromXvcpzex3x/GGalVpIoLQH/XortxjeoqXFkJIieBFqX4TYlB7spP7NPwtY6kO3t+hyE1FBfNJ/C3Unmc15oRZPwGBNORmPl/vzhK0VQfwQk4oep095SMQ10P6lJqR2P+BXx7PH5MZaS3CZ1uZtZe7V9zRIyhJoliMRqWqZFyLhC3aEXu8t69XQY+Bw0JbPqBB6sgVszHqr/fsxCnFHgU9+QgxToaW1FuYeK3BRTB8Ao6imcAvPA38DF
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(36860700004)(376005)(82310400014)(1800799015);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Mar 2024 21:59:45.3920
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 08fd688c-55fb-417a-bb87-08dc4ea936bc
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF000252A0.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR12MB7277

The Xen PVH entrypoint is 32bit non-PIC code running at a default load
address of 0x1000000 (16MB) (CONFIG_PHYSICAL_START).  Xen loads the
kernel at that physical address inside the PVH container.

When running a PVH Dom0, the system reserved addresses are mapped 1-1
into the PVH container.  There exist system firmwares (Coreboot/EDK2)
with reserved memory at 16MB.  This creates a conflict where the PVH
kernel cannot be loaded at that address.

Modify the PVH entrypoint to be position-indepedent to allow flexibility
in load address.  Only the 64bit entry path is converted.  A 32bit
kernel is not PIC, so calling into other parts of the kernel, like
xen_prepare_pvh() and mk_pgtable_32(), don't work properly when
relocated.

Initial PVH entry runs at the physical addresses and then transitions to
the identity mapped address.  While executing xen_prepare_pvh() calls
through pv_ops function pointers transition to the high mapped
addresses.  Additionally, __va() is called on some hvm_start_info
physical addresses, we need the directmap address range is used.  So we
need to run page tables with all of those ranges mapped.

Modifying init_top_pgt tables ran into issue since
startup_64/__startup_64() will modify those page tables again.  Use a
dedicated set of page tables - pvh_init_top_pgt  - for the PVH entry to
avoid unwanted interactions.

In xen_pvh_init(), __pa() is called to find the physical address of the
hypercall page.  Set phys_base temporarily before calling into
xen_prepare_pvh(), which calls xen_pvh_init(), and clear it afterwards.
__startup_64() assumes phys_base is zero and adds load_delta to it.  If
phys_base is already set, the calculation results in an incorrect cr3.

TODO: Sync elfnote.h from xen.git commit xxxxxxxxxx when it is
commited.

Signed-off-by: Jason Andryuk 
---
Put this out as an example for the Xen modifications

Instead of setting and clearing phys_base, add a dedicated variable?
Clearing phys_base is a little weird, but it leaves the kernel more
consistent when running non-entry code.

Make __startup_64() exit if phys_base is already set to allow calling
multiple times, and use that and init_top_pgt instead of adding
additional page tables?  That won't work.  __startup_64 is 64bit code,
and pvh needs to create page tables in 32bit code before it can
transition to 64bit long mode.  Hence it can't be re-used to relocate
page tables.
---
 arch/x86/platform/pvh/head.S    | 182 +++++++++++++++++++++++++++++---
 include/xen/interface/elfnote.h |  16 ++-
 2 files changed, 185 insertions(+), 13 deletions(-)

diff --git a/arch/x86/platform/pvh/head.S b/arch/x86/platform/pvh/head.S
index f7235ef87bc3..ce2b201210e3 100644
--- a/arch/x86/platform/pvh/head.S
+++ b/arch/x86/platform/pvh/head.S
@@ -50,11 +50,32 @@
 #define PVH_CS_SEL		(PVH_GDT_ENTRY_CS * 8)
 #define PVH_DS_SEL		(PVH_GDT_ENTRY_DS * 8)
 
+#define rva(x) ((x) - pvh_start_xen)
+
 SYM_CODE_START_LOCAL(pvh_start_xen)
 	UNWIND_HINT_END_OF_STACK
 	cld
 
-	lgdt (_pa(gdt))
+	/*
+	 * See the comment for startup_32 for more details.  We need to
+	 * execute a call to get the execution address to be position
+	 * independent, but we don't have a stack.  Save and restore the
+	 * magic field of start_info in ebx, and use that as the stack.
+	 */
+	mov	(%ebx), %eax
+	leal	4(%ebx), %esp
+	ANNOTATE_INTRA_FUNCTION_CALL
+	call	1f
+1:	popl	%ebp
+	mov	%eax, (%ebx)
+	subl	$ rva(1b), %ebp
+	movl	$0, %esp
+
+	leal	rva(gdt)(%ebp), %eax
+	movl	%eax, %ecx
+	leal	rva(gdt_start)(%ebp), %ecx
+	movl	%ecx, 2(%eax)
+	lgdt	(%eax)
 
 	mov $PVH_DS_SEL,%eax
 	mov %eax,%ds
@@ -62,14 +83,14 @@ SYM_CODE_START_LOCAL(pvh_start_xen)
 	mov %eax,%ss
 
 	/* Stash hvm_start_info. */
-	mov $_pa(pvh_start_info), %edi
+	leal rva(pvh_start_info)(%ebp), %edi
 	mov %ebx, %esi
-	mov _pa(pvh_start_info_sz), %ecx
+	movl rva(pvh_start_info_sz)(%ebp), %ecx
 	shr $2,%ecx
 	rep
 	movsl
 
-	mov $_pa(early_stack_end), %esp
+	leal rva(early_stack_end)(%ebp), %esp
 
 	/* Enable PAE mode. */
 	mov %cr4, %eax
@@ -83,29 +104,81 @@ SYM_CODE_START_LOCAL(pvh_start_xen)
 	btsl $_EFER_LME, %eax
 	wrmsr
 
+	mov %ebp, %ebx
+	subl $LOAD_PHYSICAL_ADDR, %ebx /* offset */
+	jz .Lpagetable_done
+
+	/* Fixup page-tables for relocation. */
+	leal rva(pvh_init_top_pgt)(%ebp), %edi
+	movl $512, %ecx
+2:
+	testl $_PAGE_PRESENT, 0x00(%edi)
+	jz 1f
+	addl %ebx, 0x00(%edi)
+1:
+	addl $8, %edi
+	decl %ecx
+	jnz 2b
+
+	/* L3 ident has a single entry. */
+	leal rva(pvh_level3_ident_pgt)(%ebp), %edi
+	addl %ebx, 0x00(%edi)
+
+	leal rva(pvh_level3_kernel_pgt)(%ebp), %edi
+	addl %ebx, (4096 - 16)(%edi)
+	addl %ebx, (4096 - 8)(%edi)
+
+	/* pvh_level2_ident_pgt is fine - large pages */
+
+	/* pvh_level2_kernel_pgt needs adjustment - large pages */
+	leal rva(pvh_level2_kernel_pgt)(%ebp), %edi
+	movl $512, %ecx
+2:
+	testl $_PAGE_PRESENT, 0x00(%edi)
+	jz 1f
+	addl %ebx, 0x00(%edi)
+1:
+	addl $8, %edi
+	decl %ecx
+	jnz 2b
+
+.Lpagetable_done:
 	/* Enable pre-constructed page tables. */
-	mov $_pa(init_top_pgt), %eax
+	leal rva(pvh_init_top_pgt)(%ebp), %eax
 	mov %eax, %cr3
 	mov $(X86_CR0_PG | X86_CR0_PE), %eax
 	mov %eax, %cr0
 
 	/* Jump to 64-bit mode. */
-	ljmp $PVH_CS_SEL, $_pa(1f)
+	pushl $PVH_CS_SEL
+	leal  rva(1f)(%ebp), %eax
+	pushl %eax
+	lretl
 
 	/* 64-bit entry point. */
 	.code64
 1:
 	/* Set base address in stack canary descriptor. */
 	mov $MSR_GS_BASE,%ecx
-	mov $_pa(canary), %eax
+	leal rva(canary)(%ebp), %eax
 	xor %edx, %edx
 	wrmsr
 
+	/* Calculate load offset from LOAD_PHYSICAL_ADDR and store in
+	 * phys_base.  __pa() needs phys_base set to calculate the the
+	 * hypercall page in xen_pvh_init(). */
+	movq %rbp, %rbx
+	subq $LOAD_PHYSICAL_ADDR, %rbx
+	movq %rbx, phys_base(%rip)
 	call xen_prepare_pvh
+	/* Clear phys_base.  startup_64/__startup_64 will *add* to its value,
+	   so start from 0. */
+	xor  %rbx, %rbx
+	movq %rbx, phys_base(%rip)
 
 	/* startup_64 expects boot_params in %rsi. */
-	mov $_pa(pvh_bootparams), %rsi
-	mov $_pa(startup_64), %rax
+	lea rva(pvh_bootparams)(%ebp), %rsi
+	lea rva(startup_64)(%ebp), %rax
 	ANNOTATE_RETPOLINE_SAFE
 	jmp *%rax
 
@@ -137,13 +210,14 @@ SYM_CODE_START_LOCAL(pvh_start_xen)
 
 	ljmp $PVH_CS_SEL, $_pa(startup_32)
 #endif
+
 SYM_CODE_END(pvh_start_xen)
 
 	.section ".init.data","aw"
 	.balign 8
 SYM_DATA_START_LOCAL(gdt)
-	.word gdt_end - gdt_start
-	.long _pa(gdt_start)
+	.word gdt_end - gdt_start - 1
+	.long _pa(gdt_start) /* x86-64 will overwrite if relocated. */
 	.word 0
 SYM_DATA_END(gdt)
 SYM_DATA_START_LOCAL(gdt_start)
@@ -163,5 +237,89 @@ SYM_DATA_START_LOCAL(early_stack)
 	.fill BOOT_STACK_SIZE, 1, 0
 SYM_DATA_END_LABEL(early_stack, SYM_L_LOCAL, early_stack_end)
 
+#ifdef CONFIG_X86_64
+/*
+ * We are not able to switch in one step to the final KERNEL ADDRESS SPACE
+ * because we need identity-mapped pages.
+ */
+#define l4_index(x)     (((x) >> 39) & 511)
+#define pud_index(x)    (((x) >> PUD_SHIFT) & (PTRS_PER_PUD-1))
+
+L4_PAGE_OFFSET  = l4_index(__PAGE_OFFSET_BASE_L4)
+L4_START_KERNEL = l4_index(__START_KERNEL_map)
+L3_START_KERNEL = pud_index(__START_KERNEL_map)
+
+#define SYM_DATA_START_PAGE_ALIGNED(name)			\
+	SYM_START(name, SYM_L_GLOBAL, .balign PAGE_SIZE)
+
+/* Automate the creation of 1 to 1 mapping pmd entries */
+#define PMDS(START, PERM, COUNT)			\
+	i = 0 ;						\
+	.rept (COUNT) ;					\
+	.quad	(START) + (i << PMD_SHIFT) + (PERM) ;	\
+	i = i + 1 ;					\
+	.endr
+
+/*
+ * Xen PVH needs a set of identity mapped and kernel high mapping
+ * page tables.  pvh_start_xen starts running on the identity mapped
+ * page tables, but xen_prepare_pvh calls into the high mapping.
+ * These page tables need to be relocatable and are only used until
+ * startup_64 transitions to init_top_pgt.
+ */
+SYM_DATA_START_PAGE_ALIGNED(pvh_init_top_pgt)
+	.quad   pvh_level3_ident_pgt - __START_KERNEL_map + _KERNPG_TABLE_NOENC
+	.org    pvh_init_top_pgt + L4_PAGE_OFFSET*8, 0
+	.quad   pvh_level3_ident_pgt - __START_KERNEL_map + _KERNPG_TABLE_NOENC
+	.org    pvh_init_top_pgt + L4_START_KERNEL*8, 0
+	/* (2^48-(2*1024*1024*1024))/(2^39) = 511 */
+	.quad   pvh_level3_kernel_pgt - __START_KERNEL_map + _PAGE_TABLE_NOENC
+SYM_DATA_END(pvh_init_top_pgt)
+
+SYM_DATA_START_PAGE_ALIGNED(pvh_level3_ident_pgt)
+	.quad	pvh_level2_ident_pgt - __START_KERNEL_map + _KERNPG_TABLE_NOENC
+	.fill	511, 8, 0
+SYM_DATA_END(pvh_level3_ident_pgt)
+SYM_DATA_START_PAGE_ALIGNED(pvh_level2_ident_pgt)
+	/*
+	 * Since I easily can, map the first 1G.
+	 * Don't set NX because code runs from these pages.
+	 *
+	 * Note: This sets _PAGE_GLOBAL despite whether
+	 * the CPU supports it or it is enabled.  But,
+	 * the CPU should ignore the bit.
+	 */
+	PMDS(0, __PAGE_KERNEL_IDENT_LARGE_EXEC, PTRS_PER_PMD)
+SYM_DATA_END(pvh_level2_ident_pgt)
+SYM_DATA_START_PAGE_ALIGNED(pvh_level3_kernel_pgt)
+	.fill	L3_START_KERNEL,8,0
+	/* (2^48-(2*1024*1024*1024)-((2^39)*511))/(2^30) = 510 */
+	.quad	pvh_level2_kernel_pgt - __START_KERNEL_map + _KERNPG_TABLE_NOENC
+	.quad	0 /* no fixmap */
+SYM_DATA_END(pvh_level3_kernel_pgt)
+
+SYM_DATA_START_PAGE_ALIGNED(pvh_level2_kernel_pgt)
+	/*
+	 * Kernel high mapping.
+	 *
+	 * The kernel code+data+bss must be located below KERNEL_IMAGE_SIZE in
+	 * virtual address space, which is 1 GiB if RANDOMIZE_BASE is enabled,
+	 * 512 MiB otherwise.
+	 *
+	 * (NOTE: after that starts the module area, see MODULES_VADDR.)
+	 *
+	 * This table is eventually used by the kernel during normal runtime.
+	 * Care must be taken to clear out undesired bits later, like _PAGE_RW
+	 * or _PAGE_GLOBAL in some cases.
+	 */
+	PMDS(0, __PAGE_KERNEL_LARGE_EXEC, KERNEL_IMAGE_SIZE/PMD_SIZE)
+SYM_DATA_END(pvh_level2_kernel_pgt)
+
+	ELFNOTE(Xen, XEN_ELFNOTE_PHYS32_RELOC,
+		     .long CONFIG_PHYSICAL_ALIGN;
+		     .long LOAD_PHYSICAL_ADDR;
+		     .long KERNEL_IMAGE_SIZE - 1)
+#endif
+
 	ELFNOTE(Xen, XEN_ELFNOTE_PHYS32_ENTRY,
-	             _ASM_PTR (pvh_start_xen - __START_KERNEL_map))
+	             .long (pvh_start_xen - __START_KERNEL_map))
diff --git a/include/xen/interface/elfnote.h b/include/xen/interface/elfnote.h
index 38deb1214613..98b3099fe1a6 100644
--- a/include/xen/interface/elfnote.h
+++ b/include/xen/interface/elfnote.h
@@ -185,9 +185,23 @@
  */
 #define XEN_ELFNOTE_PHYS32_ENTRY 18
 
+/*
+ * Physical loading constraints for PVH kernels
+ *
+ * The presence of this note indicates the kernel supports relocating itself.
+ *
+ * The note may include up to three 32bit values to place constraints on the
+ * guest physical loading addresses and alignment for a PVH kernel.  Values
+ * are read in the following order:
+ *  - a required start alignment (default 0x200000)
+ *  - a minimum address for the start of the image (default 0)
+ *  - a maximum address for the last byte of the image (default 0xffffffff)
+ */
+#define XEN_ELFNOTE_PHYS32_RELOC 19
+
 /*
  * The number of the highest elfnote defined.
  */
-#define XEN_ELFNOTE_MAX XEN_ELFNOTE_PHYS32_ENTRY
+#define XEN_ELFNOTE_MAX XEN_ELFNOTE_PHYS32_RELOC
 
 #endif /* __XEN_PUBLIC_ELFNOTE_H__ */
-- 
2.44.0



From xen-devel-bounces@lists.xenproject.org Thu Mar 28 00:47:55 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 00:47:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698753.1090830 (Exim 4.92)
	(envelope-from )
	id 1rpdvf-0003Gh-Rg; Thu, 28 Mar 2024 00:47:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698753.1090830; Thu, 28 Mar 2024 00:47:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpdvf-0003Ga-Oj; Thu, 28 Mar 2024 00:47:39 +0000
Received: by outflank-mailman (input) for mailman id 698753;
 Thu, 28 Mar 2024 00:47:38 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpdve-0003GQ-DG; Thu, 28 Mar 2024 00:47:38 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpdve-0004AT-4d; Thu, 28 Mar 2024 00:47:38 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpdvd-0002xG-Qh; Thu, 28 Mar 2024 00:47:37 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rpdvd-0004lE-QD; Thu, 28 Mar 2024 00:47:37 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=MGDUJvcyX5JKqRo/QOBps26OGrLsavX4y1Rx/MAi2pI=; b=CUgi1vH4Vs5tLYPG5dYUGxgI7Z
	3HxebyB7A6L18+TmPsoFU78vQ44axE6/05TDdpP8PQiPy/Eo5zVIaVsEn/m+TzEY8m4w3wHVUEDqf
	RXgTlhB6P31VouF0E7hcvamHOhJ2G9FfsBiKbni5k1VGakYdg0pICDh38lRJXoiFS71w=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-6.1 test] 185167: tolerable FAIL - PUSHED
X-Osstest-Failures:
    linux-6.1:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    linux-6.1:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    linux-6.1:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    linux-6.1:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    linux-6.1:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    linux-6.1:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    linux-6.1:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    linux-6.1:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    linux-6.1:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    linux-6.1:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    linux-6.1:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-6.1:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    linux-6.1:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    linux-6.1:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    linux-6.1:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    linux-6.1:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-6.1:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-6.1:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    linux-6.1:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    linux-6.1:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-6.1:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    linux-6.1:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    linux-6.1:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    linux-6.1:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    linux-6.1:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    linux-6.1:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    linux-6.1:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    linux-6.1:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-6.1:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking
    linux-6.1:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    linux-6.1:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    linux-6.1:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    linux-6.1:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-6.1:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    linux-6.1:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
    linux-6.1:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    linux-6.1:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-6.1:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-6.1:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    linux-6.1:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    linux-6.1:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    linux-6.1:test-armhf-armhf-xl-qcow2:migrate-support-check:fail:nonblocking
    linux-6.1:test-armhf-armhf-xl-qcow2:saverestore-support-check:fail:nonblocking
    linux-6.1:test-armhf-armhf-libvirt-vhd:migrate-support-check:fail:nonblocking
    linux-6.1:test-armhf-armhf-libvirt-vhd:saverestore-support-check:fail:nonblocking
    linux-6.1:test-armhf-armhf-xl-raw:migrate-support-check:fail:nonblocking
    linux-6.1:test-armhf-armhf-xl-raw:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    linux=e5cd595e23c1a075359a337c0e5c3a4f2dc28dd1
X-Osstest-Versions-That:
    linux=d7543167affd372819a94879b8b1e8b9b12547d9
From: osstest service owner 
Date: Thu, 28 Mar 2024 00:47:37 +0000

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

Failures :-/ but no regressions.

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

version targeted for testing:
 linux                e5cd595e23c1a075359a337c0e5c3a4f2dc28dd1
baseline version:
 linux                d7543167affd372819a94879b8b1e8b9b12547d9

Last test of basis   185053  2024-03-15 19:18:14 Z   12 days
Testing same since   185167  2024-03-26 22:43:26 Z    1 days    1 attempts

------------------------------------------------------------
377 people touched revisions under test,
not listing them all

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-libvirt-qcow2                               pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-xl-qcow2                                    pass    
 test-amd64-amd64-libvirt-raw                                 pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-amd64-amd64-xl-raw                                      pass    
 test-armhf-armhf-xl-raw                                      pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-libvirt-vhd                                 pass    
 test-amd64-amd64-xl-vhd                                      pass    
 test-arm64-arm64-xl-vhd                                      pass    


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

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

Explanation of these 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 :

hint: The 'hooks/update' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
hint: The 'hooks/post-receive' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
hint: The 'hooks/post-update' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
To xenbits.xen.org:/home/xen/git/linux-pvops.git
   d7543167affd..e5cd595e23c1  e5cd595e23c1a075359a337c0e5c3a4f2dc28dd1 -> tested/linux-6.1


From xen-devel-bounces@lists.xenproject.org Thu Mar 28 01:24:41 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 01:24:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698759.1090841 (Exim 4.92)
	(envelope-from )
	id 1rpeVM-0006Xw-FV; Thu, 28 Mar 2024 01:24:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698759.1090841; Thu, 28 Mar 2024 01:24:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpeVM-0006Xp-By; Thu, 28 Mar 2024 01:24:32 +0000
Received: by outflank-mailman (input) for mailman id 698759;
 Thu, 28 Mar 2024 01:24:31 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpeVL-0006Xj-0S
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 01:24:31 +0000
Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com
 [2a00:1450:4864:20::435])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ebe59263-eca1-11ee-a1ef-f123f15fe8a2;
 Thu, 28 Mar 2024 02:24:28 +0100 (CET)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-33ff53528ceso244409f8f.0
 for ; Wed, 27 Mar 2024 18:24:28 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ebe59263-eca1-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1711589068; x=1712193868; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=wMXtwOiTpOApCjD9n1tSkh3mIVCmf75hXY5jgNK9zj4=;
        b=eObVBc5TVl6HSngqa9VN64j5EZO7uRBxzBF4VIN/h9MU0QR5GYDBP96jnA4nRHdAuU
         lJ9RWpPTKM0ZHiRdo3I14Df+7ablYNGi24EvOwss2hHceO68df5YqlnukDNxSRwIRKEP
         6ZVqmC9E3OR/49iTw5PCgBDlPYx2RYwodXoCgR9Bc2Cv+AdPXKlk+AJwmbtcnXPaAmTP
         x3XctJqoy1PejsXe+OTM0hq5y0UxyPwfPcxoZm/ssrzgbrH4Rig96dKD5iQp0Sv2TJzI
         t8EBQdbKklqEq4i0kC6PNH7jeGNj/lrRsa7BOKLx99sbyLf/C8EBFkLidd5G6V46Wxpu
         JV0Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711589068; x=1712193868;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=wMXtwOiTpOApCjD9n1tSkh3mIVCmf75hXY5jgNK9zj4=;
        b=mHv6bJS6gCrIld0l5gvqlptzgajfDtjb9vt0UQitoOdLGfqlSkyzDubzx4/ljz51pA
         xiZ+MUpRh41wfqre5ig96GCoUDXmT+OrBV59oIhXus/nn6dE3kpASRRkkkgRPGaZ87Kf
         5Z5ClVzJE3Z/mbxrEOuqEqKaUzxXPfMqTLjeeObu1+UBXCwmK4jew57pzMQ8ghK9RxwE
         XZ0+QrqQWf7pV5ygcv8J7sNwnoBqqQN5szj1caNvjr/qR3bLqPx5WmV/DnFMuxHD7K6i
         NqPikdQHN8Os2hkLPtumZ6TnvaPJxQF3iUlE01x03oKGb0hbnbxad9J1uHv99I5KMPyL
         mNcw==
X-Gm-Message-State: AOJu0YxNawHde9HNtxgErUBGbi/5+cns+l6rbbB7v5CM6ju7I5agW3zj
	c8ChN/r9j/lf7xrNLF4l/Huzs76Aj9kzyRv8QS2t8WgB4zKA8gAqMeDI4CIQAYK+HdIZUzAZK4o
	xwvKePdd4gl9z9mS2dA6unJU1vF0=
X-Google-Smtp-Source: AGHT+IH0WkDEkoB50gqDDf7Pqf+mPlwgwvE5z7UJjKbwZi8QN2iXXcuwQDjVXUuhoVZI5em2VTt9tvP3uV5wpPbqbk8=
X-Received: by 2002:a5d:6d8b:0:b0:341:deab:4313 with SMTP id
 l11-20020a5d6d8b000000b00341deab4313mr1371694wrs.1.1711589068005; Wed, 27 Mar
 2024 18:24:28 -0700 (PDT)
MIME-Version: 1.0
References: <20240124165401.35784-1-jandryuk@gmail.com> 
In-Reply-To: 
From: Jason Andryuk 
Date: Wed, 27 Mar 2024 21:24:16 -0400
Message-ID: 
Subject: Re: Linux Xen PV CPA W^X violation false-positives
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
Cc: xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Mar 27, 2024 at 7:46=E2=80=AFAM J=C3=BCrgen Gro=C3=9F  wrote:
>
> On 24.01.24 17:54, Jason Andryuk wrote:
> > +
> > +                     return new;
> > +             }
> > +     }
> > +
> >       end =3D start + npg * PAGE_SIZE - 1;
> >       WARN_ONCE(1, "CPA detected W^X violation: %016llx -> %016llx rang=
e: 0x%016lx - 0x%016lx PFN %lx\n",
> >                 (unsigned long long)pgprot_val(old),
>
> Jason, do you want to send a V2 with your Signed-off, or would you like m=
e to
> try upstreaming the patch?

Hi J=C3=BCrgen,

Yes, please upstream your approach.  I wasn't sure how to deal with
it, so it was more of a bug report.

Thanks,
Jason


From xen-devel-bounces@lists.xenproject.org Thu Mar 28 02:04:54 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 02:04:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698762.1090851 (Exim 4.92)
	(envelope-from )
	id 1rpf8E-0003lz-Af; Thu, 28 Mar 2024 02:04:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698762.1090851; Thu, 28 Mar 2024 02:04:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpf8E-0003ls-7x; Thu, 28 Mar 2024 02:04:42 +0000
Received: by outflank-mailman (input) for mailman id 698762;
 Thu, 28 Mar 2024 02:04:40 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpf8C-0003li-AT; Thu, 28 Mar 2024 02:04:40 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpf8C-0004gt-3Z; Thu, 28 Mar 2024 02:04:40 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpf8B-0004qZ-LA; Thu, 28 Mar 2024 02:04:39 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rpf8B-00039Y-Kh; Thu, 28 Mar 2024 02:04:39 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=zfW0ci/Lf8sN9MY+Ma1f8kMWNL3kjxtKs0YkH2pFF6g=; b=oiYv9Ncpk9VMRDYXV/c2FRVIQT
	skg0GF/wdxGXFA6hal8270lSNX73qze8jwOisMkvlypvHo6ulNkkeQhSw9Y0ydC4xBMsB8Bty4VVJ
	usOyCWc4Fri4QmySnN/VOKPkd5/dVQKHFK/5MgSAuwxl7RvGzjW37rLkxuZDFARoY0/o=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-5.4 test] 185168: tolerable FAIL - PUSHED
X-Osstest-Failures:
    linux-5.4:test-armhf-armhf-xl-credit1:guest-start:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-multivcpu:guest-start/debian.repeat:fail:nonblocking
    linux-5.4:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking
    linux-5.4:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-credit2:guest-start/debian.repeat:fail:nonblocking
    linux-5.4:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    linux-5.4:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    linux-5.4:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    linux-5.4:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    linux-5.4:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking
    linux-5.4:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking
    linux-5.4:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-5.4:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-5.4:test-amd64-i386-libvirt-qcow2:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    linux-5.4:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
    linux-5.4:test-amd64-i386-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-5.4:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-qcow2:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-qcow2:saverestore-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    linux-5.4:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-libvirt-vhd:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-libvirt-vhd:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-raw:migrate-support-check:fail:nonblocking
    linux-5.4:test-armhf-armhf-xl-raw:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    linux=24489321d0cd5339f9c2da01eb8bf2bccbac7956
X-Osstest-Versions-That:
    linux=84075826304f1a297838de6bcfd9bd84f566026e
From: osstest service owner 
Date: Thu, 28 Mar 2024 02:04:39 +0000

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-credit1  14 guest-start                  fail  like 185071
 test-armhf-armhf-xl-multivcpu 18 guest-start/debian.repeat    fail like 185080
 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop             fail like 185108
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop            fail like 185108
 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop             fail like 185108
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop            fail like 185108
 test-armhf-armhf-xl-rtds     18 guest-start/debian.repeat    fail  like 185108
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop            fail like 185108
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop            fail like 185108
 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop             fail like 185108
 test-armhf-armhf-libvirt     16 saverestore-support-check    fail  like 185108
 test-armhf-armhf-xl-credit2  18 guest-start/debian.repeat    fail  like 185108
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop             fail like 185108
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 185108
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass
 test-amd64-amd64-libvirt     15 migrate-support-check        fail   never pass
 test-amd64-i386-xl-pvshim    14 guest-start                  fail   never pass
 test-amd64-i386-libvirt      15 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  15 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-qcow2 14 migrate-support-check        fail  never pass
 test-arm64-arm64-xl          15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          16 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      16 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass
 test-armhf-armhf-xl-multivcpu 15 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-rtds     15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  16 saverestore-support-check    fail   never pass
 test-amd64-i386-libvirt-raw  14 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-raw 14 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-raw 15 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-qcow2    14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-qcow2    15 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-vhd      14 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-vhd      15 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-vhd 14 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-vhd 15 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-raw      14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-raw      15 saverestore-support-check    fail   never pass

version targeted for testing:
 linux                24489321d0cd5339f9c2da01eb8bf2bccbac7956
baseline version:
 linux                84075826304f1a297838de6bcfd9bd84f566026e

Last test of basis   185108  2024-03-20 07:24:30 Z    7 days
Testing same since   185168  2024-03-26 23:14:28 Z    1 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  "Jiri Slaby (SUSE)" 
  Adam Goldman 
  Alan Stern 
  Alban Boyé 
  Alex Bee 
  Alex Deucher 
  Alexander Gordeev 
  Alexander Stein 
  Alexandre Belloni 
  Alexei Starovoitov 
  Alexis Lothoré 
  Andreas Larsson 
  Andrii Nakryiko 
  Andrii Nakryiko 
  Andy Shevchenko 
  AngeloGioacchino Del Regno 
  Arend van Spriel 
  Armin Wolf 
  Arnd Bergmann 
  Arthur Kiyanovski 
  Baokun Li 
  Baruch Siach 
  Ben Wolsieffer 
  Bjorn Andersson 
  Bjorn Andersson 
  Bjorn Helgaas 
  Breno Leitao 
  Bryan O'Donoghue 
  Cai Huoqing 
  Caleb Connolly  # OnePlus 6
  Chen Ni 
  Christian Borntraeger 
  Christian Brauner 
  Christophe JAILLET 
  Chuck Lever 
  Chun-Kuang Hu 
  Chun-Yi Lee 
  Colin Ian King 
  Dan Carpenter 
  Daniel Borkmann 
  Daniel Thompson 
  Daniil Dulov 
  David Howells 
  David S. Miller 
  David Sterba 
  Dmitry Baryshkov 
  Dmitry Torokhov 
  Duoming Zhou 
  Edward Adam Davis 
  Eric Dumazet 
  Fedor Pchelkin 
  Fei Shao 
  Felix Maurer 
  Filipe Manana 
  Florian Fainelli 
  Gavrilov Ilia 
  Geert Uytterhoeven 
  Greg Joyce 
  Greg Kroah-Hartman 
  Guenter Roeck 
  Gurucharan G 
  Hans de Goede 
  Hans Verkuil 
  Harry Wentland 
  Heiko Carstens 
  Heiko Stuebner 
  Helge Deller 
  Helge Deller  # parisc STI console
  Herbert Xu 
  Hsin-Yi Wang 
  Hugo Villeneuve 
  Ian Rogers 
  Ilpo Järvinen 
  Jakub Kicinski 
  Jan Kara 
  Jason Gunthorpe 
  Jeff Johnson 
  Jens Axboe 
  Jerome Brunet 
  Jesper Dangaard Brouer 
  Jiaxun Yang 
  Jie Wang 
  Jijie Shao 
  Jinjie Ruan 
  Jiri Kosina 
  Jiri Olsa 
  Jiri Slaby (SUSE) 
  Joerg Roedel 
  Johan Carlsson 
  John Fastabend 
  John Stultz 
  Jonas Dreßler 
  Juergen Gross 
  Jörg Wedekind 
  Kajol Jain 
  Kalle Valo 
  Kalle Valo 
  Kalle Valo 
  Kamal Heib 
  Kees Cook 
  Konrad Dybcio 
  Kuniyuki Iwashima 
  Kunwu Chan 
  Laurent Pinchart 
  Lee Jones 
  Lena Wang 
  Leon Romanovsky 
  Linu Cherian 
  Linus Walleij 
  Linux Kernel Functional Testing 
  Luca Weiss 
  Lucas Stach 
  Luiz Augusto von Dentz 
  Manuel Fombuena 
  Marek Vasut 
  Mario Limonciello 
  Mark Brown 
  Martin K. Petersen 
  Martin KaFai Lau 
  Masahiro Yamada 
  Mauro Carvalho Chehab 
  Mauro Carvalho Chehab 
  Mauro Carvalho Chehab 
  Max Kellermann 
  Maxime Ripard 
  Melissa Wen 
  Mete Durlu 
  Michael Ellerman 
  Michael Klein 
  Michal Vokáč 
  Mike Snitzer 
  Mikulas Patocka 
  Ming Lei 
  Miquel Raynal 
  Namhyung Kim 
  Navid Emamdoost 
  Nikita Zhandarovich 
  Pablo Neira Ayuso 
  Paloma Arellano 
  Paolo Abeni 
  Paul E. McKenney 
  Peter Griffin 
  Peter Hilber 
  Peter Robinson 
  Pierre-Louis Bossart 
  Pucha Himasekhar Reddy  (A Contingent worker at Intel)
  Quentin Schulz 
  Rafael J. Wysocki 
  Rafał Miłecki 
  Rahul Rameshbabu 
  Randy Dunlap 
  Randy Dunlap  # build-tested
  Ranjan Kumar 
  Richard Cochran 
  Robert Foss 
  Robert Marko 
  Ruud Bos 
  Sakari Ailus 
  Sam Ravnborg 
  Sasha Levin 
  Saurav Girepunje 
  Shawn Guo 
  Shifeng Li 
  Shigeru Yoshida 
  Shiming Cheng 
  Sowjanya Komatineni 
  Srinivasan Shanmugam 
  Stephan Gerhold 
  Stephen Boyd 
  Stuart Henderson 
  Subbaraya Sundeep 
  Sunil Goutham 
  Takashi Iwai 
  Takashi Sakamoto 
  Tamar Mashiah 
  Thierry Reding 
  Thinh Tran 
  Thomas Bogendoerfer 
  Thomas Gleixner 
  Toke Høiland-Jørgensen 
  Tony Nguyen 
  Trond Myklebust 
  Tudor Ambarus 
  Ulf Hansson 
  Uwe Kleine-König 
  Vandana BN 
  Vinicius Costa Gomes 
  Vinod Koul 
  Wang Jianjian 
  Wim Van Sebroeck 
  Xingyuan Mo 
  Yan Zhai 
  Yang Jihong 
  Yewon Choi 
  Yishai Hadas 
  Yonghong Song 
  Yuxuan Hu <20373622@buaa.edu.cn>
  Zheng Yang 
  Zhipeng Lu 

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-coresched-i386-xl                                 pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm                  pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-qemuu-freebsd10-amd64                        pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-i386-xl-qemut-ws16-amd64                          fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-amd64-i386-xl-qemuu-ws16-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-i386-examine-bios                                 pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  fail    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  fail    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict         pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-i386-examine                                      pass    
 test-amd64-i386-qemuu-freebsd10-i386                         pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-i386-xl-pvshim                                    fail    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-i386-libvirt-qcow2                                pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-xl-qcow2                                    pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-amd64-i386-libvirt-raw                                  pass    
 test-amd64-amd64-xl-raw                                      pass    
 test-armhf-armhf-xl-raw                                      pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     fail    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow              pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-amd64-i386-xl-shadow                                    pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-i386-examine-uefi                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-libvirt-vhd                                 pass    
 test-arm64-arm64-xl-vhd                                      pass    
 test-amd64-i386-xl-vhd                                       pass    


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

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

Explanation of these 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 :

hint: The 'hooks/update' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
hint: The 'hooks/post-receive' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
hint: The 'hooks/post-update' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
To xenbits.xen.org:/home/xen/git/linux-pvops.git
   84075826304f..24489321d0cd  24489321d0cd5339f9c2da01eb8bf2bccbac7956 -> tested/linux-5.4


From xen-devel-bounces@lists.xenproject.org Thu Mar 28 04:48:00 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 04:48:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698769.1090861 (Exim 4.92)
	(envelope-from )
	id 1rphg1-0006Ic-CT; Thu, 28 Mar 2024 04:47:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698769.1090861; Thu, 28 Mar 2024 04:47:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rphg1-0006IV-9r; Thu, 28 Mar 2024 04:47:45 +0000
Received: by outflank-mailman (input) for mailman id 698769;
 Thu, 28 Mar 2024 04:47:44 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rphg0-0006IL-CF; Thu, 28 Mar 2024 04:47:44 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rphfz-0007mW-WE; Thu, 28 Mar 2024 04:47:44 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rphfz-0000Wu-Lk; Thu, 28 Mar 2024 04:47:43 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rphfz-00034M-LE; Thu, 28 Mar 2024 04:47:43 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=IqgoTJBaRYILOEJQeGAQQEEGxOindfky7dhJjC25SSY=; b=VkJ/aOFP0+/8rJ3zKUinSto9cd
	5m1/UbRMd+Vwuyd0FjwxoBaEdUmCfPcGi61XBKRKAuJtVwxEi9pahzahWopn/ia76LijnD/7t/dAT
	rcmqWSytEmaOr1jBNNOROkZoC07lx7aP9/LyUXaaFf3Hv3AnKPwEFTA/Y8dmBqZ4axWM=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 185169: regressions - FAIL
X-Osstest-Failures:
    xen-unstable:build-arm64-xsm:xen-build:fail:regression
    xen-unstable:test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict:xen-install:fail:heisenbug
    xen-unstable:test-amd64-amd64-xl-qemut-debianhvm-amd64:guest-start/debianhvm.repeat:fail:heisenbug
    xen-unstable:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking
    xen-unstable:test-arm64-arm64-xl-xsm:build-check(1):blocked:nonblocking
    xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-qcow2:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-qcow2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-vhd:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-raw:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    xen=6f6de10ade5ade907f9e3f3c72b7b18f7852d9ff
X-Osstest-Versions-That:
    xen=6f6de10ade5ade907f9e3f3c72b7b18f7852d9ff
From: osstest service owner 
Date: Thu, 28 Mar 2024 04:47:43 +0000

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-xsm               6 xen-build                fail REGR. vs. 185162

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-install fail in 185162 pass in 185169
 test-amd64-amd64-xl-qemut-debianhvm-amd64 20 guest-start/debianhvm.repeat fail pass in 185162

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)               blocked  n/a
 test-arm64-arm64-xl-xsm       1 build-check(1)               blocked  n/a
 test-arm64-arm64-xl-xsm     15 migrate-support-check fail in 185162 never pass
 test-arm64-arm64-xl-xsm 16 saverestore-support-check fail in 185162 never pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-check fail in 185162 never pass
 test-arm64-arm64-libvirt-xsm 16 saverestore-support-check fail in 185162 never pass
 test-armhf-armhf-libvirt     16 saverestore-support-check    fail  like 185162
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop            fail like 185162
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop            fail like 185162
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop            fail like 185162
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 185162
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop            fail like 185162
 test-amd64-amd64-libvirt     15 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass
 test-armhf-armhf-xl-rtds     15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     16 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 15 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-check    fail  never pass
 test-amd64-amd64-libvirt-raw 14 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-raw 14 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-raw 15 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-vhd      14 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-vhd      15 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qcow2 14 migrate-support-check        fail never pass
 test-armhf-armhf-xl-qcow2    14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-qcow2    15 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-vhd 14 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-vhd 15 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-raw      14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-raw      15 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  16 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  6f6de10ade5ade907f9e3f3c72b7b18f7852d9ff
baseline version:
 xen                  6f6de10ade5ade907f9e3f3c72b7b18f7852d9ff

Last test of basis   185169  2024-03-27 01:54:33 Z    1 days
Testing same since                          (not found)         0 attempts

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              fail    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 blocked 
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      blocked 
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    fail    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-libvirt-qcow2                               pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-xl-qcow2                                    pass    
 test-amd64-amd64-libvirt-raw                                 pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-amd64-amd64-xl-raw                                      pass    
 test-armhf-armhf-xl-raw                                      pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-libvirt-vhd                                 pass    
 test-amd64-amd64-xl-vhd                                      pass    
 test-arm64-arm64-xl-vhd                                      pass    


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

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

Explanation of these 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


Published tested tree is already up to date.



From xen-devel-bounces@lists.xenproject.org Thu Mar 28 06:08:23 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 06:08:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698776.1090874 (Exim 4.92)
	(envelope-from )
	id 1rpivt-0007oY-98; Thu, 28 Mar 2024 06:08:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698776.1090874; Thu, 28 Mar 2024 06:08:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpivt-0007oR-5T; Thu, 28 Mar 2024 06:08:13 +0000
Received: by outflank-mailman (input) for mailman id 698776;
 Thu, 28 Mar 2024 06:08:12 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpivs-0007nZ-9Y
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 06:08:12 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on20600.outbound.protection.outlook.com
 [2a01:111:f403:2009::600])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8d2493c6-ecc9-11ee-afe3-a90da7624cb6;
 Thu, 28 Mar 2024 07:08:10 +0100 (CET)
Received: from BN9PR03CA0388.namprd03.prod.outlook.com (2603:10b6:408:f7::33)
 by MW4PR12MB5604.namprd12.prod.outlook.com (2603:10b6:303:18d::17)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.32; Thu, 28 Mar
 2024 06:08:07 +0000
Received: from BN3PEPF0000B373.namprd21.prod.outlook.com
 (2603:10b6:408:f7:cafe::bc) by BN9PR03CA0388.outlook.office365.com
 (2603:10b6:408:f7::33) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.13 via Frontend
 Transport; Thu, 28 Mar 2024 06:08:07 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN3PEPF0000B373.mail.protection.outlook.com (10.167.243.170) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7452.0 via Frontend Transport; Thu, 28 Mar 2024 06:08:06 +0000
Received: from cjq-desktop.amd.com (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 28 Mar
 2024 01:08:04 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8d2493c6-ecc9-11ee-afe3-a90da7624cb6
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=Ri7yL3fkaXFtaJNM2/0Rvzgk4ir/pH2soA/kbhMaqqeJZhTGUmv62Yw8RuG+NUT9IkwxVOd5AgZxdDxUdaW2hSPLkqgFsY2ep+2fHYPbf41bgBUgBkI+K2urp+y2D5st+HMQ4TMEU7dj5nK34Yqmki2AFvCIWTCJWhQ19ziF4Tl61A7/Gm/NHh5D6fhGSHuRfHEbXgiYHxDqHFabTJV03L7HEa27l/GCK4zuIPYJHboVuHLT3xOsMRJopDcruXgxi/uwj4V1alDbO3lOaxOeAQdQgWg4RmGsmI0C1mCksWzXAklwWjd1bpucqjh8qVw//6CG4NCNmtzmWwRzb/b8pA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=0BVIA9BD2p8N+4kZSKhtmN3U4mw30lLtB421xQPF2gY=;
 b=N/Dm1ZpvhRX/t/knBN8EqtpyNxYfERkS7X9zK8WgQjgDUCiYBJHKwRXeqPCXbTzzPSpVLUoyNeq6FvK08YJUwxO4wyp6+8fC7Vk0eeyLmNT1FH+d2mD9+QwXdhMz/la56LIR/SoOaHiSUzkMS+OO0sPx7vvzpsr4yO8iRq2XQUXYJ48aXMBmDDFOnqL8TzPWKUOp4dFZAAbfYQXCY+c7VD6jLd68JEvunfAmbFa4l0RhPjGPLtQu2vNOCn0BwoN+jLE0LHTR4ErTkKaDYknZ4x9qz2vWf0NpOgouZ+KvZP87JC9ChMOIn7h3qtg5Gmg5N3trBhT1/5AfdOx9tOBzzg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=nongnu.org smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=0BVIA9BD2p8N+4kZSKhtmN3U4mw30lLtB421xQPF2gY=;
 b=zktDnjjK4babEFP2GuTcm8S894S7w3M5yOA1PG7HR2cQ7K7CEHdZDHK6v5Of02jIZuP1prbOAZK+GtSH2PL0m9zBX4lGHSrjf9ktBnQc4PoRDtsvqIK+zpJHq+tcQAIDPXgCVj1wtVoHJ6s4OL2w79FDmTRiPp0xskXE5qA1L2M=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Jiqian Chen 
To: 
CC: Stefano Stabellini , Anthony Perard
	, Paul Durrant ,
	, Huang Rui , Jiqian Chen
	
Subject: [QEMU PATCH v5 0/1] Support device passthrough when dom0 is PVH on Xen
Date: Thu, 28 Mar 2024 14:07:30 +0800
Message-ID: <20240328060731.354356-1-Jiqian.Chen@amd.com>
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN3PEPF0000B373:EE_|MW4PR12MB5604:EE_
X-MS-Office365-Filtering-Correlation-Id: 93f91fcf-7979-4d10-0e02-08dc4eed6fca
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	/ak8AN8NN6XSL8P1NXLbVfOOiJZ7CiHIB0nTU9k4g86Q+PUzOOwZvE8bmDscjty4iM1aN63q96gd7g3G7pQywCxK36yRKEvrKXVyCjYyBK0btGmcn5Rcx8G28VNmPIwi23gy3FZQKGmwH3zJ99d35QBiBxhQLVuHysJYBGLCcDz7TcKn3W6VtELqvV8S6NirO8GCdUbseK0FxEReRnmgW7Lp+uK/05uBoxJ7bSexTzo/KJap/oxWZv5XvbI3H1Fmghhk+KWIWhuSMVkW58omnEswsiUHBI2BHTI7amj8xX95oL3PTQuLVmFq7oV/LcfkiC6FIK9rWFoWBxCVWGrfZ5hGhxNmtWpoAm/Bh59K7Mm3xjRHR+giwO23vPp4TNPIcJSkFsfc7cXb8PVMQSZwSmafTuHgEDwgTcxsWAlpwgwA+eK3QsEett/67fY7jwR2NTgQVO8EXfKy7iTxfD5BMIJoI2+I7NGMXqqLQ7It2jFFyNGQTVOywH2ywnwPWdQ2GOQTtp69ib4yajXtUq1rCZU/q75KEv6lMpenKwuqFPPQwsEJEjdAGjen0XQb5VnNMo1IqI1oT1VubySecQ4OVNXK76ejJZZd5U02nSkSEwaE1Y0JZ9p1LKfqhcI4i2YzLWOMSaV2Emn6VYpCbvhQ3bh0uHuLRPG0+WItDFjGIU3BY4/+9krA/rguuECzg9Yy
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(82310400014)(1800799015)(36860700004)(376005);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Mar 2024 06:08:06.9183
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 93f91fcf-7979-4d10-0e02-08dc4eed6fca
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN3PEPF0000B373.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR12MB5604

Hi All,
This is v5 series to support passthrough on Xen when dom0 is PVH.
v4->v5 changes:
* Add review by Stefano

v3->v4 changes:
* Add gsi into struct XenHostPCIDevice and use gsi number that read from gsi sysfs
  if it exists, if there is no gsi sysfs, still use irq.

v2->v3 changes:
* Du to changes in the implementation of the second patch on kernel side(that adds
  a new sysfs for gsi instead of a new syscall), so read gsi number from the sysfs of gsi.

Below is the description of v2 cover letter:
This patch is the v2 of the implementation of passthrough when dom0 is PVH on Xen.
Issues we encountered:
1. failed to map pirq for gsi
Problem: qemu will call xc_physdev_map_pirq() to map a passthrough device’s gsi to pirq in
function xen_pt_realize(). But failed.

Reason: According to the implement of xc_physdev_map_pirq(), it needs gsi instead of irq,
but qemu pass irq to it and treat irq as gsi, it is got from file
/sys/bus/pci/devices/xxxx:xx:xx.x/irq in function xen_host_pci_device_get(). But actually
the gsi number is not equal with irq. On PVH dom0, when it allocates irq for a gsi in
function acpi_register_gsi_ioapic(), allocation is dynamic, and follow the principle of
applying first, distributing first. And if you debug the kernel codes
(see function __irq_alloc_descs), you will find the irq number is allocated from small to
large by order, but the applying gsi number is not, gsi 38 may come before gsi 28, that
causes gsi 38 get a smaller irq number than gsi 28, and then gsi != irq.

Solution: we can record the relation between gsi and irq, then when userspace(qemu) want
to use gsi, we can do a translation. The third patch of kernel(xen/privcmd: Add new syscall
to get gsi from irq) records all the relations in acpi_register_gsi_xen_pvh() when dom0
initialize pci devices, and provide a syscall for userspace to get the gsi from irq. The
third patch of xen(tools: Add new function to get gsi from irq) add a new function
xc_physdev_gsi_from_irq() to call the new syscall added on kernel side.
And then userspace can use that function to get gsi. Then xc_physdev_map_pirq() will success.

This v2 on qemu side is the same as the v1 
(qemu https://lore.kernel.org/xen-devel/20230312092244.451465-19-ray.huang@amd.com/), just call
xc_physdev_gsi_from_irq() to get gsi from irq.


Jiqian Chen (1):
  xen: Use gsi instead of irq for mapping pirq

 hw/xen/xen-host-pci-device.c | 7 +++++++
 hw/xen/xen-host-pci-device.h | 1 +
 hw/xen/xen_pt.c              | 6 +++++-
 3 files changed, 13 insertions(+), 1 deletion(-)

-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Thu Mar 28 06:08:23 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 06:08:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698777.1090884 (Exim 4.92)
	(envelope-from )
	id 1rpivv-00082o-FF; Thu, 28 Mar 2024 06:08:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698777.1090884; Thu, 28 Mar 2024 06:08:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpivv-00082h-Bv; Thu, 28 Mar 2024 06:08:15 +0000
Received: by outflank-mailman (input) for mailman id 698777;
 Thu, 28 Mar 2024 06:08:13 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpivt-0007nZ-S2
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 06:08:13 +0000
Received: from NAM04-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam04on20601.outbound.protection.outlook.com
 [2a01:111:f403:2408::601])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8eca7663-ecc9-11ee-afe3-a90da7624cb6;
 Thu, 28 Mar 2024 07:08:13 +0100 (CET)
Received: from BN9PR03CA0090.namprd03.prod.outlook.com (2603:10b6:408:fc::35)
 by CY5PR12MB6647.namprd12.prod.outlook.com (2603:10b6:930:40::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.33; Thu, 28 Mar
 2024 06:08:09 +0000
Received: from BN3PEPF0000B372.namprd21.prod.outlook.com
 (2603:10b6:408:fc:cafe::14) by BN9PR03CA0090.outlook.office365.com
 (2603:10b6:408:fc::35) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.13 via Frontend
 Transport; Thu, 28 Mar 2024 06:08:09 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN3PEPF0000B372.mail.protection.outlook.com (10.167.243.169) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7452.0 via Frontend Transport; Thu, 28 Mar 2024 06:08:09 +0000
Received: from cjq-desktop.amd.com (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 28 Mar
 2024 01:08:06 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8eca7663-ecc9-11ee-afe3-a90da7624cb6
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=jfFpvhBbYSSsw8jSb/rUy8/oVJBqbkA6EcvIVvG9hORSHDE2xVRNS2+PyEDzuOU4oEor1/S+tclOyqldd9hszwzU5k+cYTRm7T3tUziIycDemDj0GlctaG7i78oEby185/spwG2tGu1jgu6zI4qfq9ut5YjDK/7RC7n724hRy7plMTRGLf8xROSBa3NE2p92jY5rVshxWP0eBZMvV+WnMsOEb5jMr16Zoe4YQWn8sRC7C3Lo9TELUpYvv/bn7p7gUwK6/5EiJgrv0ueZYtBoNAYHhjA301TEKFIcEiBvKUMaexpPvQa3Hu0R+yJSpUpb2ivZETkkOSJ9siVi/yJKqg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=4iktjCp5GS/8M8W4VEJkInG7sWcP8HxuGqTncJkiWFM=;
 b=Vy5KyVRuMpQ7mZ+B/ZUm4or406eeIwh41yqLNgPKqsjOcAUJNkobRCZiSvwcnAhsROQRHX2jVZnSLJUDU0gs8LoTzUylMS12bZcEBF/kubzzHaOoSEQkSDvBqhvc4Ij/GOJlaJvhm1kgIvoQySVrFoR/4RxW0Q4ZypNtlHqWwfdZC54PwyZpFiEMOteVgrxojH+FJJrReV4Pmawvsmpk82KtQ1UTLqQaRIogEAkFSBs64P2gRMEofDNagH/JyHa2XbExPRVMFiVKzov0LCCqbVW22Ur8CTVhGbFe2jJNMIlAyfCfryO0aAapEooBWiYdgse0YdT50CP+DUgQLRzuBg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=nongnu.org smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=4iktjCp5GS/8M8W4VEJkInG7sWcP8HxuGqTncJkiWFM=;
 b=4r3TqM+FOytsD4MHl0NCx/DAukhZdRYXPl8XAPO7GWKm4JmLqDNqW9E9r0ZxtXjp3lDq2eGc7AcsW3mu9ciSS/QwrR6nAMHBoeVCJVL8TTx0JirELM8fT/7wczAX7kEzWiaNfWsaBhVE6OiL2JvgsPS4ZDavba0oBBddtbo7aAg=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Jiqian Chen 
To: 
CC: Stefano Stabellini , Anthony Perard
	, Paul Durrant ,
	, Huang Rui , Jiqian Chen
	, Huang Rui 
Subject: [RFC QEMU PATCH v5 1/1] xen: Use gsi instead of irq for mapping pirq
Date: Thu, 28 Mar 2024 14:07:31 +0800
Message-ID: <20240328060731.354356-2-Jiqian.Chen@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20240328060731.354356-1-Jiqian.Chen@amd.com>
References: <20240328060731.354356-1-Jiqian.Chen@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN3PEPF0000B372:EE_|CY5PR12MB6647:EE_
X-MS-Office365-Filtering-Correlation-Id: e2e18142-2616-4616-208e-08dc4eed7133
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	TFpXLZGHAOE+mjzrmlmfj1lN9OUY3e/hZZZfpRHim6s6Zfmbeo3B4CRE5GtGe0TV0j4TwcGRNIMXXPtWNXEvf0QCcqwGRg7acB0iyBxN1KrR/sfqNUzjjksp8Ov1/huq7dKW4IJLwuiZvq7NpbK2Y4KzIE85mnmgbsaz1KQzpg1cJj2QDACdWGSQsyv8yFdBu9ziL94v1tuK1rc5JG5Vnu+dE4WR8JKcvFAMC2jgGQvz8ybnyfVV3TIxcFdn5ha8CsqWMLohFufOcU55Qi4JXH0BBoVUaKp8TRNcDnbfr3AVywmx8v7i5zib4ffKOoymoYWlnsYdBqqNydNMU4wNKfU1x4xHIIYll5RfRI9Irw9PLDCFA9MJDU/St6Q1twhFBax4bKUHnthTFwRopkCJA2OZicaFzK9GaQRUmVRO33VRyLBJe/D+X0iW1qCTzZagG8ZuTp9cpERUbQRmwcLsEWoj8/LAyxtHIYx7W0OHfJKSBrML11JxzzWVYIrsTBlTWupy3oy+Jp23B9rC8JV+7F0CXlXDXIuxQYhkzTo3oZIjw2Qul/2kft1QzyQKeDO5TkOZarOz9FlYBdyEhrPM77TjL4GkRioK9ANOSfhhz76h8LBcuzUOr2ELQ7CDg6J4aKeue9WnnrQ7mDDp6M7uSKfFksYwlU24QAthE0kML8dLHnHIwbIUnjHoPVW1D8o8htirNQrEtaHNJbVZtbam8BxfUwQLpzN9vJf/4bBBd0oWbz+KcQoalHN79fYE2m4m
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(36860700004)(82310400014)(376005)(1800799015);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Mar 2024 06:08:09.2690
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: e2e18142-2616-4616-208e-08dc4eed7133
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN3PEPF0000B372.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY5PR12MB6647

In PVH dom0, it uses the linux local interrupt mechanism,
when it allocs irq for a gsi, it is dynamic, and follow
the principle of applying first, distributing first. And
the irq number is alloced from small to large, but the
applying gsi number is not, may gsi 38 comes before gsi
28, that causes the irq number is not equal with the gsi
number. And when passthrough a device, qemu wants to use
gsi to map pirq, xen_pt_realize->xc_physdev_map_pirq, but
the gsi number is got from file
/sys/bus/pci/devices//irq in current code, so it
will fail when mapping.

Add gsi into XenHostPCIDevice and use gsi number that
read from gsi sysfs if it exists.

Signed-off-by: Huang Rui 
Signed-off-by: Jiqian Chen 
Reviewed-by: Stefano Stabellini 

---
RFC: discussions ongoing on the Linux side where/how to expose the gsi

---
 hw/xen/xen-host-pci-device.c | 7 +++++++
 hw/xen/xen-host-pci-device.h | 1 +
 hw/xen/xen_pt.c              | 6 +++++-
 3 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/hw/xen/xen-host-pci-device.c b/hw/xen/xen-host-pci-device.c
index 8c6e9a1716a2..5be3279aa25b 100644
--- a/hw/xen/xen-host-pci-device.c
+++ b/hw/xen/xen-host-pci-device.c
@@ -370,6 +370,13 @@ void xen_host_pci_device_get(XenHostPCIDevice *d, uint16_t domain,
     }
     d->irq = v;
 
+    xen_host_pci_get_dec_value(d, "gsi", &v, errp);
+    if (*errp) {
+        d->gsi = -1;
+    } else {
+        d->gsi = v;
+    }
+
     xen_host_pci_get_hex_value(d, "class", &v, errp);
     if (*errp) {
         goto error;
diff --git a/hw/xen/xen-host-pci-device.h b/hw/xen/xen-host-pci-device.h
index 4d8d34ecb024..74c552bb5548 100644
--- a/hw/xen/xen-host-pci-device.h
+++ b/hw/xen/xen-host-pci-device.h
@@ -27,6 +27,7 @@ typedef struct XenHostPCIDevice {
     uint16_t device_id;
     uint32_t class_code;
     int irq;
+    int gsi;
 
     XenHostPCIIORegion io_regions[PCI_NUM_REGIONS - 1];
     XenHostPCIIORegion rom;
diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c
index 3635d1b39f79..d34a7a8764ab 100644
--- a/hw/xen/xen_pt.c
+++ b/hw/xen/xen_pt.c
@@ -840,7 +840,11 @@ static void xen_pt_realize(PCIDevice *d, Error **errp)
         goto out;
     }
 
-    machine_irq = s->real_device.irq;
+    if (s->real_device.gsi < 0) {
+        machine_irq = s->real_device.irq;
+    } else {
+        machine_irq = s->real_device.gsi;
+    }
     if (machine_irq == 0) {
         XEN_PT_LOG(d, "machine irq is 0\n");
         cmd |= PCI_COMMAND_INTX_DISABLE;
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Thu Mar 28 06:25:14 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 06:25:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698783.1090893 (Exim 4.92)
	(envelope-from )
	id 1rpjCF-0003AW-Sn; Thu, 28 Mar 2024 06:25:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698783.1090893; Thu, 28 Mar 2024 06:25:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpjCF-0003AP-Pv; Thu, 28 Mar 2024 06:25:07 +0000
Received: by outflank-mailman (input) for mailman id 698783;
 Thu, 28 Mar 2024 06:25:07 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpjCF-0003AI-Ef
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 06:25:07 +0000
Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com
 [2a00:1450:4864:20::433])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ea6350f0-eccb-11ee-a1ef-f123f15fe8a2;
 Thu, 28 Mar 2024 07:25:05 +0100 (CET)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-341e3682c78so280707f8f.0
 for ; Wed, 27 Mar 2024 23:25:05 -0700 (PDT)
Received: from ?IPV6:2003:ca:b738:601a:1073:a6:6f09:9d9a?
 (p200300cab738601a107300a66f099d9a.dip0.t-ipconnect.de.
 [2003:ca:b738:601a:1073:a6:6f09:9d9a])
 by smtp.gmail.com with ESMTPSA id
 l14-20020adfa38e000000b0033e93e00f68sm837764wrb.61.2024.03.27.23.25.04
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 27 Mar 2024 23:25:04 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ea6350f0-eccb-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711607104; x=1712211904; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=PVn77RP6DE4g6drhl0zx5cLmjDm/qQpN4xlwgp7Pt88=;
        b=YjMQbmQSgJCEVAgs3R2gLeXcxiT6V691kgvebnmU3V9yCfGaDqMIGfAf3+zvCmocOo
         UYFUR91i8uCvJu6uAzRAmARn4JssHGAt51ASeGDXJC0I4QucyVQ98t3xdfXooJbz4kjb
         po6aREH+fareIH8gNCfymIqVOtW14MPBxgrogl4OhljJxLFKjrUh9ftTzaFJbgVGIO8h
         5Zf+FiCLAV/OP/VpeKSLzsePf1Qr6O3jgXfUt/C9TmVOZK78qiteOa6X6OuB6SaZn4kB
         llgTfrdkCkfTmVX3CUqhoQ1Xr3WJiRJVENMkv2bg35jM7HQ5o16/+iFQbHTJLggiKEOU
         iDRA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711607104; x=1712211904;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=PVn77RP6DE4g6drhl0zx5cLmjDm/qQpN4xlwgp7Pt88=;
        b=N+Gk/i3enap/U0zJmj0La6WQO30bvOVWvTQVW9sFqQy2s6Q6POeG1c+VTjMdGH6icg
         w8nR2p9dpvFkXbY2fOcPWdK5kfNJSM18H74TigCTjrY9iPng2f6zMHVbAcp5EMw4dDMO
         u3BeneQQpjN1WD1hF/nUUqqrh72/G0DwJ9ncKiWNKnlmZjXJcSe+oXThFCweLiXxvl6l
         PPdIEzNTBidE0l+aH6L1H1kN2cmi8xKXSZ3QBWMiZRTF9nOHgzfa4hA1YgFz7vMmVhlX
         H62CaoTszEVaXLWBAaJibSdcj3iWnlEiq0r+ydW7B/yZsU64YpINUTgOW7kKefghfqLL
         60kA==
X-Gm-Message-State: AOJu0YybTuVkQSdDVsbfruUNNGihookdF30u98Vy3S5OlnysXP8tnZ3e
	vn2P1TlniiSMdlhggjN+++HB18/f6j1T2Kf+dM/u1E5tUJoDaOFmVGzY/VSRZA==
X-Google-Smtp-Source: AGHT+IFGv9SYg8LhaAMn2UxpygNhIPirTpgzJo/McI1bKyBy52k/3Lkq06sua9RTPPUzUm97l8iF0g==
X-Received: by 2002:a5d:6dc9:0:b0:342:cd1c:a6aa with SMTP id d9-20020a5d6dc9000000b00342cd1ca6aamr937305wrz.55.1711607104511;
        Wed, 27 Mar 2024 23:25:04 -0700 (PDT)
Message-ID: 
Date: Thu, 28 Mar 2024 07:25:02 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Serious AMD-Vi(?) issue
Content-Language: en-US
To: Elliott Mitchell 
Cc: xen-devel@lists.xenproject.org, Andrew Cooper
 , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Wei Liu ,
 Kelly Choi 
References: 
  
 
 
 
  
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 27.03.2024 18:27, Elliott Mitchell wrote:
> On Mon, Mar 25, 2024 at 02:43:44PM -0700, Elliott Mitchell wrote:
>> On Mon, Mar 25, 2024 at 08:55:56AM +0100, Jan Beulich wrote:
>>> On 22.03.2024 20:22, Elliott Mitchell wrote:
>>>> On Fri, Mar 22, 2024 at 04:41:45PM +0000, Kelly Choi wrote:
>>>>>
>>>>> I can see you've recently engaged with our community with some issues you'd
>>>>> like help with.
>>>>> We love the fact you are participating in our project, however, our
>>>>> developers aren't able to help if you do not provide the specific details.
>>>>
>>>> Please point to specific details which have been omitted.  Fairly little
>>>> data has been provided as fairly little data is available.  The primary
>>>> observation is large numbers of:
>>>>
>>>> (XEN) AMD-Vi: IO_PAGE_FAULT: DDDD:bb:dd.f d0 addr ffffff???????000 flags 0x8 I
>>>>
>>>> Lines in Xen's ring buffer.
>>>
>>> Yet this is (part of) the problem: By providing only the messages that appear
>>> relevant to you, you imply that you know that no other message is in any way
>>> relevant. That's judgement you'd better leave to people actually trying to
>>> investigate. Unless of course you were proposing an actual code change, with
>>> suitable justification.
>>
>> Honestly, I forgot about the very small number of messages from the SATA
>> subsystem.  The question of whether the current mitigation actions are
>> effective right now was a bigger issue.  As such monitoring `xl dmesg`
>> was a priority to looking at SATA messages which failed to reliably
>> indicate status.
>>
>> I *thought* I would be able to retrieve those via other slow means, but a
>> different and possibly overlapping issue has shown up.  Unfortunately
>> this means those are no longer retrievable.   :-(
> 
> With some persistence I was able to retrieve them.  There are other
> pieces of software with worse UIs than Xen.
> 
>>> In fact when running into trouble, the usual course of action would be to
>>> increase verbosity in both hypervisor and kernel, just to make sure no
>>> potentially relevant message is missed.
>>
>> More/better information might have been obtained if I'd been engaged
>> earlier.
> 
> This is still true, things are in full mitigation mode and I'll be
> quite unhappy to go back with experiments at this point.

Well, it very likely won't work without further experimenting by someone
able to observe the bad behavior. Recall we're on xen-devel here; it is
kind of expected that without clear (and practical) repro instructions
experimenting as well as info collection will remain with the reporter.

> I now see why I left those out.  The messages from the SATA subsystem
> were from a kernel which a bad patch had leaked into a LTS branch.  Looks
> like the SATA subsystem was significantly broken and I'm unsure whether
> any useful information could be retrieved.  Notably there is quite a bit
> of noise from SATA devices not effected by this issue.
> 
> Some of the messages /might/ be useful, but the amount of noise is quite
> high.  Do messages from a broken kernel interest you?

If this was a less vague (in terms of possible root causes) issue, I'd
probably have answered "yes". But in the case here I'm afraid such might
further confuse things rather than clarifying them.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Mar 28 06:34:32 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 06:34:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698786.1090903 (Exim 4.92)
	(envelope-from )
	id 1rpjLH-000517-N9; Thu, 28 Mar 2024 06:34:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698786.1090903; Thu, 28 Mar 2024 06:34:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpjLH-000510-KZ; Thu, 28 Mar 2024 06:34:27 +0000
Received: by outflank-mailman (input) for mailman id 698786;
 Thu, 28 Mar 2024 06:34:26 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpjLG-00050u-GH
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 06:34:26 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on20631.outbound.protection.outlook.com
 [2a01:111:f400:7e88::631])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 37865e79-eccd-11ee-afe3-a90da7624cb6;
 Thu, 28 Mar 2024 07:34:25 +0100 (CET)
Received: from CH0P223CA0006.NAMP223.PROD.OUTLOOK.COM (2603:10b6:610:116::24)
 by SJ0PR12MB6759.namprd12.prod.outlook.com (2603:10b6:a03:44b::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.33; Thu, 28 Mar
 2024 06:34:21 +0000
Received: from CH1PEPF0000A345.namprd04.prod.outlook.com
 (2603:10b6:610:116:cafe::1) by CH0P223CA0006.outlook.office365.com
 (2603:10b6:610:116::24) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.13 via Frontend
 Transport; Thu, 28 Mar 2024 06:34:21 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CH1PEPF0000A345.mail.protection.outlook.com (10.167.244.8) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Thu, 28 Mar 2024 06:34:20 +0000
Received: from cjq-desktop.amd.com (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 28 Mar
 2024 01:34:16 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 37865e79-eccd-11ee-afe3-a90da7624cb6
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=Obi6HYe6xYXEAyGS/bEm3dJqMMjQjoQMQong9WYW5t34LAiT2hlUMXnSNZwcxd5mPI9lP7HxWyTk1RC3qJxEkAbEGbabqaOf6s/G+bZOrPuHCL02KKKurgkb0dIBhTV8vDTF0yx2hQPYYx1PyEr3u6SNbleuUa8jDa4KDXn20dSXgZn+gkOjHtnf24WuyTzlzjw5Zc5ccLMXvjny5ng1fEdZCACALmRRBgcP2H6ByaeORqpzF/LQ43njr4euc9Vzc2h0ngxbV+eZsI3WI2kTZmdEV5I3tLchqiWtLni26akwkCrkm+scCrUGKFQFxR5YpgROHTM0LgS1HSdvqFO1sA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=NSM04TcpoTnGMGbyK//oTfjXT4lhbQc9K4dNvFxakco=;
 b=FTHDkHk37rPrPCpyS8MUOcPt6DSt6QUBGTJdaBBluH818G3IGL380cuIbgbKDmLahAkyIEfaam/WgnYQtagV0VTn+jGbaZ90jS3/vE1v9h/0QY0qmtyVQmlKAd7dUhEhWwveAFMEKTpN54LRw7vreEXumeoSOzR/TsAJmXigWNUi6NeN/c36CtR4nMNVf+mOgwFuTZLvw79oDXbd41aSXT5A7QCu49UVpBZynmyCxwT4giEpwZMieFezH1fSYrnqKfHu5I2UDbBn/ab3fRnx4O/dcv+gzDxoCpjLHrgaYfJvhQY9cxyGDwzL7FTxlh/cbKkqYxaMsE7XOK7qV89+6A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=NSM04TcpoTnGMGbyK//oTfjXT4lhbQc9K4dNvFxakco=;
 b=zUt6VUyrE/+e2hmv8M03r4lts4/esMEaVD6Itdx/fNzsiC6tPlZjBgPsuDaRiZjFV2Q6cldfiasOy3yp/ttcqNfjOok/fthOrWq5rDpldLaarC5mLkqjgH3+6sIHtljVmBpfb+q7M4jie/haeJ4YnEWEK8o/nAdARHlJKpMFHGw=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Jiqian Chen 
To: 
CC: Jan Beulich , Andrew Cooper
	, =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, Wei Liu , George Dunlap
	, Julien Grall , Stefano Stabellini
	, Anthony PERARD ,
	"Juergen Gross" , "Daniel P . Smith"
	, Stewart Hildebrand
	, Huang Rui , Jiqian Chen
	
Subject: [RFC XEN PATCH v6 0/5] Support device passthrough when dom0 is PVH on Xen
Date: Thu, 28 Mar 2024 14:33:57 +0800
Message-ID: <20240328063402.354496-1-Jiqian.Chen@amd.com>
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH1PEPF0000A345:EE_|SJ0PR12MB6759:EE_
X-MS-Office365-Filtering-Correlation-Id: 818e980f-39c8-403e-9cfc-08dc4ef119d6
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	t1n17FDPaarOyYe3kHLH2NhtgSjPybFQHhtlafcYFs68I3PHxjXyfkARuSJ/IbycBfUTDQUsviP4jRa+t8DAuL+NB1hcnDGCPIveiz2TGd93ni5+yQIoy/XRcVV5GE45+H7b9F0nhIg+52u0w7i+P9rjWKbLoxPFUqHh5vT6HAwlTYmFeO8jLx33gYUaj36scA/GEjbpHchEFKY2ukU3BbI6GvYTP+jnRja3uqdmExJqCepSlc7ez1bnVGVREjhjYG1Pv3L3u5dsIJt3vx2/GjORxj0hASng9oObwiSILS5oskGgB3SKhpHIAZp5Z/ytyJde4lBoOESkLXFKIHA5UDxY/O91hY23NObGh7jaeFcwTFVDOW+WgwKOUTDa7c9JM67rhU9/7LVyl4iketA5/0eJ8q88kqUuJ097AY5fUbRvkNP7QBsjemfNIYIJiK3g1dbMot3jla/nHzyuWajWr0mtL56G8LCgFRNuvFEP/Eo/UviQJi9NNUwp1Kj9UCOd+9mHDUkGutUD1srUdt3A30XQ9SPm58LRmsSOfJP9IoymV40Z4LWx0NUPZfPw+fnrqLUHXacAOXRn9lACevQ+ss0hQ3mHc4kA6PsOcore9Q3T9cK5pEOVxUAgkTb9YOz0Ipbc4uhZAIrIflJDWsreRHHY3mwmSoH4ZTM/DET0UvRBJxIjujBpN6rqfU1ODCXtmDzAexKZw5TZNwcMtWJ2tQ==
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(1800799015)(36860700004)(376005)(7416005)(82310400014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Mar 2024 06:34:20.6722
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 818e980f-39c8-403e-9cfc-08dc4ef119d6
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH1PEPF0000A345.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR12MB6759

Hi All,
This is v6 series to support passthrough when dom0 is PVH
v5->v6 changes:
* patch#1: Add Reviewed-by Stefano and Stewart. Rebase code and change old function vpci_remove_device, vpci_add_handlers to vpci_deassign_device, vpci_assign_device
* patch#2: Add Reviewed-by Stefano
* patch#3: Remove unnecessary "ASSERT(!has_pirq(currd));"
* patch#4: Fix some coding style issues below directory tools
* patch#5: Modified some variable names and code logic to make code easier to be understood, which to use gsi by default and be compatible with older kernel versions to continue to use irq

v4->v5 changes:
* patch#1: add pci_lock wrap function vpci_reset_device_state
* patch#2: move the check of self map_pirq to physdev.c, and change to check if the caller has PIRQ flag, and just break for PHYSDEVOP_(un)map_pirq in hvm_physdev_op
* patch#3: return -EOPNOTSUPP instead, and use ASSERT(!has_pirq(currd));
* patch#4: is the patch#5 in v4 because patch#5 in v5 has some dependency on it. And add the handling of errno and add the Reviewed-by Stefano
* patch#5: is the patch#4 in v4. New implementation to add new hypercall XEN_DOMCTL_gsi_permission to grant gsi


v3->v4 changes:
* patch#1: change the comment of PHYSDEVOP_pci_device_state_reset; move printings behind pcidevs_unlock
* patch#2: add check to prevent PVH self map
* patch#3: new patch, The implementation of adding PHYSDEVOP_setup_gsi for PVH is treated as a separate patch
* patch#4: new patch to solve the map_pirq problem of PVH dom0. use gsi to grant irq permission in XEN_DOMCTL_irq_permission.
* patch#5: to be compatible with previous kernel versions, when there is no gsi sysfs, still use irq
v4 link:
https://lore.kernel.org/xen-devel/20240105070920.350113-1-Jiqian.Chen@amd.com/T/#t

v2->v3 changes:
* patch#1: move the content out of pci_reset_device_state and delete pci_reset_device_state; add xsm_resource_setup_pci check for PHYSDEVOP_pci_device_state_reset; add description for PHYSDEVOP_pci_device_state_reset;
* patch#2: du to changes in the implementation of the second patch on kernel side(that it will do setup_gsi and map_pirq when assigning a device to passthrough), add PHYSDEVOP_setup_gsi for PVH dom0, and we need to support self mapping.
* patch#3: du to changes in the implementation of the second patch on kernel side(that adds a new sysfs for gsi instead of a new syscall), so read gsi number from the sysfs of gsi.
v3 link:
https://lore.kernel.org/xen-devel/20231210164009.1551147-1-Jiqian.Chen@amd.com/T/#t

v2 link:
https://lore.kernel.org/xen-devel/20231124104136.3263722-1-Jiqian.Chen@amd.com/T/#t
Below is the description of v2 cover letter:
This series of patches are the v2 of the implementation of passthrough when dom0 is PVH on Xen.
We sent the v1 to upstream before, but the v1 had so many problems and we got lots of suggestions.
I will introduce all issues that these patches try to fix and the differences between v1 and v2.

Issues we encountered:
1. pci_stub failed to write bar for a passthrough device.
Problem: when we run “sudo xl pci-assignable-add ” to assign a device, pci_stub will call “pcistub_init_device() -> pci_restore_state() -> pci_restore_config_space() ->
pci_restore_config_space_range() -> pci_restore_config_dword() -> pci_write_config_dword()”, the pci config write will trigger an io interrupt to bar_write() in the xen, but the
bar->enabled was set before, the write is not allowed now, and then when 
bar->Qemu config the
passthrough device in xen_pt_realize(), it gets invalid bar values.

Reason: the reason is that we don't tell vPCI that the device has been reset, so the current cached state in pdev->vpci is all out of date and is different from the real device state.

Solution: to solve this problem, the first patch of kernel(xen/pci: Add xen_reset_device_state
function) and the fist patch of xen(xen/vpci: Clear all vpci status of device) add a new hypercall to reset the state stored in vPCI when the state of real device has changed.
Thank Roger for the suggestion of this v2, and it is different from v1 (https://lore.kernel.org/xen-devel/20230312075455.450187-3-ray.huang@amd.com/), v1 simply allow domU to write pci bar, it does not comply with the design principles of vPCI.

2. failed to do PHYSDEVOP_map_pirq when dom0 is PVH
Problem: HVM domU will do PHYSDEVOP_map_pirq for a passthrough device by using gsi. See xen_pt_realize->xc_physdev_map_pirq and pci_add_dm_done->xc_physdev_map_pirq. Then xc_physdev_map_pirq will call into Xen, but in hvm_physdev_op(), PHYSDEVOP_map_pirq is not allowed.

Reason: In hvm_physdev_op(), the variable "currd" is PVH dom0 and PVH has no X86_EMU_USE_PIRQ flag, it will fail at has_pirq check.

Solution: I think we may need to allow PHYSDEVOP_map_pirq when "currd" is dom0 (at present dom0 is PVH). The second patch of xen(x86/pvh: Open PHYSDEVOP_map_pirq for PVH dom0) allow PVH dom0 do PHYSDEVOP_map_pirq. This v2 patch is better than v1, v1 simply remove the has_pirq check(xen https://lore.kernel.org/xen-devel/20230312075455.450187-4-ray.huang@amd.com/).

3. the gsi of a passthrough device doesn't be unmasked
 3.1 failed to check the permission of pirq
 3.2 the gsi of passthrough device was not registered in PVH dom0

Problem:
3.1 callback function pci_add_dm_done() will be called when qemu config a passthrough device for domU.
This function will call xc_domain_irq_permission()-> pirq_access_permitted() to check if the gsi has corresponding mappings in dom0. But it didn’t, so failed. See XEN_DOMCTL_irq_permission->pirq_access_permitted, "current" is PVH dom0 and it return irq is 0.
3.2 it's possible for a gsi (iow: vIO-APIC pin) to never get registered on PVH dom0, because the devices of PVH are using MSI(-X) interrupts. However, the IO-APIC pin must be configured for it to be able to be mapped into a domU.

Reason: After searching codes, I find "map_pirq" and "register_gsi" will be done in function vioapic_write_redirent->vioapic_hwdom_map_gsi when the gsi(aka ioapic's pin) is unmasked in PVH dom0.
So the two problems can be concluded to that the gsi of a passthrough device doesn't be unmasked.

Solution: to solve these problems, the second patch of kernel(xen/pvh: Unmask irq for passthrough device in PVH dom0) call the unmask_irq() when we assign a device to be passthrough. So that passthrough devices can have the mapping of gsi on PVH dom0 and gsi can be registered. This v2 patch is different from the v1( kernel https://lore.kernel.org/xen-devel/20230312120157.452859-5-ray.huang@amd.com/,
kernel https://lore.kernel.org/xen-devel/20230312120157.452859-5-ray.huang@amd.com/ and xen https://lore.kernel.org/xen-devel/20230312075455.450187-5-ray.huang@amd.com/),
v1 performed "map_pirq" and "register_gsi" on all pci devices on PVH dom0, which is unnecessary and may cause multiple registration.

4. failed to map pirq for gsi
Problem: qemu will call xc_physdev_map_pirq() to map a passthrough device’s gsi to pirq in function xen_pt_realize(). But failed.

Reason: According to the implement of xc_physdev_map_pirq(), it needs gsi instead of irq, but qemu pass irq to it and treat irq as gsi, it is got from file /sys/bus/pci/devices/xxxx:xx:xx.x/irq in function xen_host_pci_device_get(). But actually the gsi number is not equal with irq. On PVH dom0, when it allocates irq for a gsi in function acpi_register_gsi_ioapic(), allocation is dynamic, and follow the principle of applying first, distributing first. And if you debug the kernel codes(see function __irq_alloc_descs), you will find the irq number is allocated from small to large by order, but the applying gsi number is not, gsi 38 may come before gsi 28, that causes gsi 38 get a smaller irq number than gsi 28, and then gsi != irq.

Solution: we can record the relation between gsi and irq, then when userspace(qemu) want to use gsi, we can do a translation. The third patch of kernel(xen/privcmd: Add new syscall to get gsi from irq) records all the relations in acpi_register_gsi_xen_pvh() when dom0 initialize pci devices, and provide a syscall for userspace to get the gsi from irq. The third patch of xen(tools: Add new function to get gsi from irq) add a new function xc_physdev_gsi_from_irq() to call the new syscall added on kernel side.
And then userspace can use that function to get gsi. Then xc_physdev_map_pirq() will success. This v2 patch is the same as v1( kernel https://lore.kernel.org/xen-devel/20230312120157.452859-6-ray.huang@amd.com/ and xen https://lore.kernel.org/xen-devel/20230312075455.450187-6-ray.huang@amd.com/)

About the v2 patch of qemu, just change an included head file, other are similar to the v1 ( qemu https://lore.kernel.org/xen-devel/20230312092244.451465-19-ray.huang@amd.com/), just call
xc_physdev_gsi_from_irq() to get gsi from irq.


Jiqian Chen (5):
  xen/vpci: Clear all vpci status of device
  x86/pvh: Allow (un)map_pirq when dom0 is PVH
  x86/pvh: Add PHYSDEVOP_setup_gsi for PVH dom0
  libxl: Use gsi instead of irq for mapping pirq
  domctl: Add XEN_DOMCTL_gsi_permission to grant gsi

 tools/include/xenctrl.h      |  5 +++
 tools/libs/ctrl/xc_domain.c  | 15 ++++++++
 tools/libs/light/libxl_pci.c | 68 +++++++++++++++++++++++++++++-------
 xen/arch/x86/domctl.c        | 31 ++++++++++++++++
 xen/arch/x86/hvm/hypercall.c |  8 +++++
 xen/arch/x86/physdev.c       | 24 +++++++++++++
 xen/drivers/pci/physdev.c    | 36 +++++++++++++++++++
 xen/drivers/vpci/vpci.c      | 10 ++++++
 xen/include/public/domctl.h  |  9 +++++
 xen/include/public/physdev.h |  7 ++++
 xen/include/xen/vpci.h       |  6 ++++
 xen/xsm/flask/hooks.c        |  1 +
 12 files changed, 208 insertions(+), 12 deletions(-)

-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Thu Mar 28 06:34:32 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 06:34:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698787.1090914 (Exim 4.92)
	(envelope-from )
	id 1rpjLK-0005Fu-VV; Thu, 28 Mar 2024 06:34:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698787.1090914; Thu, 28 Mar 2024 06:34:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpjLK-0005Fn-ST; Thu, 28 Mar 2024 06:34:30 +0000
Received: by outflank-mailman (input) for mailman id 698787;
 Thu, 28 Mar 2024 06:34:30 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpjLK-00050u-1K
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 06:34:30 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on20600.outbound.protection.outlook.com
 [2a01:111:f403:2416::600])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 39cdb8f5-eccd-11ee-afe3-a90da7624cb6;
 Thu, 28 Mar 2024 07:34:29 +0100 (CET)
Received: from CH0PR03CA0100.namprd03.prod.outlook.com (2603:10b6:610:cd::15)
 by IA1PR12MB6260.namprd12.prod.outlook.com (2603:10b6:208:3e4::17)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.31; Thu, 28 Mar
 2024 06:34:25 +0000
Received: from CH1PEPF0000A34C.namprd04.prod.outlook.com
 (2603:10b6:610:cd:cafe::c0) by CH0PR03CA0100.outlook.office365.com
 (2603:10b6:610:cd::15) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.25 via Frontend
 Transport; Thu, 28 Mar 2024 06:34:25 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CH1PEPF0000A34C.mail.protection.outlook.com (10.167.244.6) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Thu, 28 Mar 2024 06:34:24 +0000
Received: from cjq-desktop.amd.com (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 28 Mar
 2024 01:34:20 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 39cdb8f5-eccd-11ee-afe3-a90da7624cb6
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=hgMdqZoIFyzvcLSnGCLx/7HONHgwmhpuc0sfUlgmurKsHfls3K5LgEjb4o6N3qdK6NZQW392diyllmkVuBDEZYH1OlrizMZiqM/ZU/+0gQR6c4Hf1YaVAOlbR6SAp9LGtNqmn0h313O/HNT2ATaQPT3HiDMXjeJMGjUS7n2957DV0AHiaL4lezKnnnMtQH74yD5yAub/j07wh/P8ZALWPD4AGlaunMDcxklvLaikXskBnZPe7RoZ4SxrY2yIwYdh+Fg49HpQeuEoDjEfW6uS30IstM4KkcX3ignGO7gQmM65Ju9LufHwyNNhv8xBXUr55ELpQYTaFnSpKfITdY/Yeg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=sGh6+DBUR12UnhAId2zcgyQdtB6rlh4Opu5QWVMJXa4=;
 b=TLhJQxsz2Xew5YykrCfJHyq7hBwrDuI624CTyRacovEnZp7jdE3sPXeSxIQCPO6BblErJzpIMBXyJxeDgF6/UhDBWfbnvmkZGEsRvmQk2vLVbVHaTKijNqy+ChiqsBZ23mlxL7HV14XhUqU8CFBGY52PuA2U3aKZiWvZif38xSGxj5iVJDwyv+jTAFCjMWtNeQZ07QnMovHFZ2OKLfNl5G5Q1IRoBFn52MVBJoo8aWi6RYrqtPotVgIP2VR9dk1O5movkm3ScZdSpuSJFTNtAKBaQ8O9fH7Wju9Xod+HoiuVAhMbQpNRl3QRQyWMJn0qecM+2fu10DordPSPUVb5vw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=sGh6+DBUR12UnhAId2zcgyQdtB6rlh4Opu5QWVMJXa4=;
 b=XWCFdmcuxhMUHonDFLCY2kEf877m2QJnCik/vkHVrLlJf+VTfl1nSuVUTa7qkuGd5LUTVTy7UEb2kNFbmsQENPBrIIbfIfhY4+tr3UNd9MDzNa1zvb4uyB4ZovyIpEnVfN48BuXZPeF3Js+rJxORBQ2wpUcincI1cFlhXRvnKfQ=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Jiqian Chen 
To: 
CC: Jan Beulich , Andrew Cooper
	, =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, Wei Liu , George Dunlap
	, Julien Grall , Stefano Stabellini
	, Anthony PERARD ,
	"Juergen Gross" , "Daniel P . Smith"
	, Stewart Hildebrand
	, Huang Rui , Jiqian Chen
	, Huang Rui , Stewart Hildebrand
	
Subject: [XEN PATCH v6 1/5] xen/vpci: Clear all vpci status of device
Date: Thu, 28 Mar 2024 14:33:58 +0800
Message-ID: <20240328063402.354496-2-Jiqian.Chen@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20240328063402.354496-1-Jiqian.Chen@amd.com>
References: <20240328063402.354496-1-Jiqian.Chen@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH1PEPF0000A34C:EE_|IA1PR12MB6260:EE_
X-MS-Office365-Filtering-Correlation-Id: 98df1f78-2d36-4327-2034-08dc4ef11c24
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	+mzOqEtOKuHfgxPtFet6T7OJsUrtO7mBJrJzBKaBv6EjZojLPB//IkWq5mm++PRbnvyOTZ8SLlR8DYCIJVPAnxu04lLE6Raix/4LgtWnW11rEMG1OtMmRTtMEGGljek5XFxxs9cdUBtVCOLumx6o33HJlwHIG9nZGwFIA2AmWZqnxlAYU0MwIdGQE830EFXk5Jbfu/6Z5umW434zQtvQtzA1g82T5TORUmWJd5X10e/APv046RUpu8RX4h5DLcGERdfSmV3QCLnBdgFxe4tRLUYwLIkxEz76bepxIlV8FAyT6YeyDCXMlfAO4wu+SE3JXXCnWfYu0HtJpIkIVgWpXHYolI0NMc2nJHOME8YqGm/UNWkaV6vA+I3sUFjrokueG3e8sTySW/GGfI+vaJWnSOOL0/g9jcuLkXIJcZ3CSHgpneKSpLEuivi0yRK4q8oeMIHbh/s6BsEmSC7awF+1lUFYZ7oHE/cea5ZVDFAw1hioRXmIUxj2yn1t9xEWxohDON3sMlXQSPTs883wYxuJHvAoL42ZVhywoEbZ4sNvtTdjVNjR+zxoJrDCuFXBdlmMP96LAxaIBksRHncvwAUPTlLPxIS9XPUiqRxwuqhv0YSamaaRS+mC8reKzHwwj1H51Cr+jtWVIYlIlD31S9N6GYrJjhKwg9vbGTMOnpa79v+FrFgypVEUbs9I37IBlDYjtCFO10xWifflrzqV5NPPRtFCjb7sTrQwKgXBuwJefwyLwCqqWIgX/rLMBPwJRET+
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(376005)(7416005)(82310400014)(36860700004)(1800799015);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Mar 2024 06:34:24.5357
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 98df1f78-2d36-4327-2034-08dc4ef11c24
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH1PEPF0000A34C.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB6260

When a device has been reset on dom0 side, the vpci on Xen
side won't get notification, so the cached state in vpci is
all out of date compare with the real device state.
To solve that problem, add a new hypercall to clear all vpci
device state. When the state of device is reset on dom0 side,
dom0 can call this hypercall to notify vpci.

Signed-off-by: Huang Rui 
Signed-off-by: Jiqian Chen 
Reviewed-by: Stewart Hildebrand 
Reviewed-by: Stefano Stabellini 
---
 xen/arch/x86/hvm/hypercall.c |  1 +
 xen/drivers/pci/physdev.c    | 36 ++++++++++++++++++++++++++++++++++++
 xen/drivers/vpci/vpci.c      | 10 ++++++++++
 xen/include/public/physdev.h |  7 +++++++
 xen/include/xen/vpci.h       |  6 ++++++
 5 files changed, 60 insertions(+)

diff --git a/xen/arch/x86/hvm/hypercall.c b/xen/arch/x86/hvm/hypercall.c
index eeb73e1aa5d0..6ad5b4d5f11f 100644
--- a/xen/arch/x86/hvm/hypercall.c
+++ b/xen/arch/x86/hvm/hypercall.c
@@ -84,6 +84,7 @@ long hvm_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
     case PHYSDEVOP_pci_mmcfg_reserved:
     case PHYSDEVOP_pci_device_add:
     case PHYSDEVOP_pci_device_remove:
+    case PHYSDEVOP_pci_device_state_reset:
     case PHYSDEVOP_dbgp_op:
         if ( !is_hardware_domain(currd) )
             return -ENOSYS;
diff --git a/xen/drivers/pci/physdev.c b/xen/drivers/pci/physdev.c
index 42db3e6d133c..73dc8f058b0e 100644
--- a/xen/drivers/pci/physdev.c
+++ b/xen/drivers/pci/physdev.c
@@ -2,6 +2,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifndef COMPAT
 typedef long ret_t;
@@ -67,6 +68,41 @@ ret_t pci_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
         break;
     }
 
+    case PHYSDEVOP_pci_device_state_reset: {
+        struct physdev_pci_device dev;
+        struct pci_dev *pdev;
+        pci_sbdf_t sbdf;
+
+        if ( !is_pci_passthrough_enabled() )
+            return -EOPNOTSUPP;
+
+        ret = -EFAULT;
+        if ( copy_from_guest(&dev, arg, 1) != 0 )
+            break;
+        sbdf = PCI_SBDF(dev.seg, dev.bus, dev.devfn);
+
+        ret = xsm_resource_setup_pci(XSM_PRIV, sbdf.sbdf);
+        if ( ret )
+            break;
+
+        pcidevs_lock();
+        pdev = pci_get_pdev(NULL, sbdf);
+        if ( !pdev )
+        {
+            pcidevs_unlock();
+            ret = -ENODEV;
+            break;
+        }
+
+        write_lock(&pdev->domain->pci_lock);
+        ret = vpci_reset_device_state(pdev);
+        write_unlock(&pdev->domain->pci_lock);
+        pcidevs_unlock();
+        if ( ret )
+            printk(XENLOG_ERR "%pp: failed to reset PCI device state\n", &sbdf);
+        break;
+    }
+
     default:
         ret = -ENOSYS;
         break;
diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c
index 260b72875ee1..310700c1e775 100644
--- a/xen/drivers/vpci/vpci.c
+++ b/xen/drivers/vpci/vpci.c
@@ -117,6 +117,16 @@ int vpci_assign_device(struct pci_dev *pdev)
 
     return rc;
 }
+
+int vpci_reset_device_state(struct pci_dev *pdev)
+{
+    ASSERT(pcidevs_locked());
+    ASSERT(rw_is_write_locked(&pdev->domain->pci_lock));
+
+    vpci_deassign_device(pdev);
+    return vpci_assign_device(pdev);
+}
+
 #endif /* __XEN__ */
 
 static int vpci_register_cmp(const struct vpci_register *r1,
diff --git a/xen/include/public/physdev.h b/xen/include/public/physdev.h
index f0c0d4727c0b..f5bab1f29779 100644
--- a/xen/include/public/physdev.h
+++ b/xen/include/public/physdev.h
@@ -296,6 +296,13 @@ DEFINE_XEN_GUEST_HANDLE(physdev_pci_device_add_t);
  */
 #define PHYSDEVOP_prepare_msix          30
 #define PHYSDEVOP_release_msix          31
+/*
+ * Notify the hypervisor that a PCI device has been reset, so that any
+ * internally cached state is regenerated.  Should be called after any
+ * device reset performed by the hardware domain.
+ */
+#define PHYSDEVOP_pci_device_state_reset     32
+
 struct physdev_pci_device {
     /* IN */
     uint16_t seg;
diff --git a/xen/include/xen/vpci.h b/xen/include/xen/vpci.h
index e89c571890b2..ea64d94e818b 100644
--- a/xen/include/xen/vpci.h
+++ b/xen/include/xen/vpci.h
@@ -30,6 +30,7 @@ int __must_check vpci_assign_device(struct pci_dev *pdev);
 
 /* Remove all handlers and free vpci related structures. */
 void vpci_deassign_device(struct pci_dev *pdev);
+int __must_check vpci_reset_device_state(struct pci_dev *pdev);
 
 /* Add/remove a register handler. */
 int __must_check vpci_add_register_mask(struct vpci *vpci,
@@ -266,6 +267,11 @@ static inline int vpci_assign_device(struct pci_dev *pdev)
 
 static inline void vpci_deassign_device(struct pci_dev *pdev) { }
 
+static inline int __must_check vpci_reset_device_state(struct pci_dev *pdev)
+{
+    return 0;
+}
+
 static inline void vpci_dump_msi(void) { }
 
 static inline uint32_t vpci_read(pci_sbdf_t sbdf, unsigned int reg,
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Thu Mar 28 06:34:34 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 06:34:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698788.1090924 (Exim 4.92)
	(envelope-from )
	id 1rpjLO-0005Wy-9W; Thu, 28 Mar 2024 06:34:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698788.1090924; Thu, 28 Mar 2024 06:34:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpjLO-0005Wj-6O; Thu, 28 Mar 2024 06:34:34 +0000
Received: by outflank-mailman (input) for mailman id 698788;
 Thu, 28 Mar 2024 06:34:32 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpjLM-00050u-E8
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 06:34:32 +0000
Received: from NAM02-DM3-obe.outbound.protection.outlook.com
 (mail-dm3nam02on20600.outbound.protection.outlook.com
 [2a01:111:f403:2405::600])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3b92d407-eccd-11ee-afe3-a90da7624cb6;
 Thu, 28 Mar 2024 07:34:31 +0100 (CET)
Received: from CH0P221CA0033.NAMP221.PROD.OUTLOOK.COM (2603:10b6:610:11d::16)
 by CH3PR12MB7643.namprd12.prod.outlook.com (2603:10b6:610:152::19)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.32; Thu, 28 Mar
 2024 06:34:28 +0000
Received: from CH1PEPF0000A34B.namprd04.prod.outlook.com
 (2603:10b6:610:11d:cafe::7a) by CH0P221CA0033.outlook.office365.com
 (2603:10b6:610:11d::16) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.13 via Frontend
 Transport; Thu, 28 Mar 2024 06:34:28 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CH1PEPF0000A34B.mail.protection.outlook.com (10.167.244.10) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Thu, 28 Mar 2024 06:34:28 +0000
Received: from cjq-desktop.amd.com (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 28 Mar
 2024 01:34:24 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3b92d407-eccd-11ee-afe3-a90da7624cb6
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=SDnsY0AKH6681xE1EPsFzdjCiSH06dzGs4PjsqGDcmzV85WOc5NAfMUgV/w/xyHhjOTWo4jy6MAM2xRNdAo/ZvXDWPec2xf96uRkf4o/tM0QwXkxMJMQEPQd4yndA3qu0KPgKCDGy3nWx6dFutWLyP+QNehlZ0XWrnZPAquMt5oOolLL3qd5sPI3qBhlFnFhTRrfK6nh31RB6+wXDs9QFAhnHyDP9vr5QUfVZp8G5/xDJM9E+OPc+TJZhvcaNWKXWiF28c1kwsTbwBeNHWKqJlwHm6XfyaSwt08+uoIcTOBeWzkx6j5aHvaXYNtzI3BajV13gfGtdIcjaGU8+1PGdg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=QTeOXa1ofsJQ5UT1Y6+HKhMws9Udhj7EK29Ce+m9250=;
 b=KaAwV+R0RXIilfP4Vh9JraPN1lqiiIQ2KcrX6sF0nIH4Wo4vw4SmtfUgL7DUT/bXJHi3QTubCaUybXkH9wKBlpgeWaQw829qGdyeriRw1doF6+zP+4XAtDKJKr3Yn+dwdYEEirV/Cz3O7yBzrs8UnHeXKUQMEBDfjbDVXCZ1Dfq0ebjnt8FfmKYtruV7EeCVCfxbhUyikzVEIhbFJ8XFhSXTkq3yHZo2G0AlnGPYoStQl9PNjXkLthsX6VyBah6q6ExYgiT/+6bbquB3IVh9VM2tERweKxconn+WO/AeTo5etoMhOgnigqyzWmen0S4SiQAaOsJSROBN/IqbNZA7UA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=QTeOXa1ofsJQ5UT1Y6+HKhMws9Udhj7EK29Ce+m9250=;
 b=yyPk4irt0W9Owz9a/FOQK8d4cBc0MYy6GUHTBrVTojEOwB7oAqXkgkjrEhjSCmIjHbldk6huK/BZC90K0m+AaVLfOLwdfSgAB2J1fsNELcSsdmtjCG3NKOJJF2GyeDU5C4oaH3dw7otCZ0kEbj3kp+BS04+WI0EjTMeCjH1XVko=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Jiqian Chen 
To: 
CC: Jan Beulich , Andrew Cooper
	, =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, Wei Liu , George Dunlap
	, Julien Grall , Stefano Stabellini
	, Anthony PERARD ,
	"Juergen Gross" , "Daniel P . Smith"
	, Stewart Hildebrand
	, Huang Rui , Jiqian Chen
	, Huang Rui 
Subject: [XEN PATCH v6 2/5] x86/pvh: Allow (un)map_pirq when dom0 is PVH
Date: Thu, 28 Mar 2024 14:33:59 +0800
Message-ID: <20240328063402.354496-3-Jiqian.Chen@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20240328063402.354496-1-Jiqian.Chen@amd.com>
References: <20240328063402.354496-1-Jiqian.Chen@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH1PEPF0000A34B:EE_|CH3PR12MB7643:EE_
X-MS-Office365-Filtering-Correlation-Id: 50a6572a-c32c-42ba-f968-08dc4ef11e6c
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	I4jGdZ8Ja8Pzf+GgJioj731p/MNNzzHTDgKIAn3rjmC/NjwEsAwbyGuwFnaWrsYfo36yDCh8HUaqlBScmMy3/T8E4hlMcaCo/xvcaQl5WFV6j6UPXpHqt/y7O/v5t+A62dLje1nVP4MAxc3IAc/rZ/MOc1Uw6lanvRc4eE5/HBhOAJBEfaXqjvviZzNAzTp1/aISfIHR26ee1WN0rmcqMcnsWEwvUJGFthYsD07Rhyg5BNC7jWVnuXMy+KcccDCXQHdnVpHvrEgWIm79xRn46NvhtTTG4CY7wJ/YmRevGHfnYb24+FKIVY2aNqGvUm3yJPgef1u4wk7smhK8dPzwXntOo5coSk1j1f4cvcX+68MR6HPUOBO6G0LqwANgoABuyTluceASkgbVlSdB9gutmyTWNwEwoI5d4j+7hkhGGZCCeOVbEsRWuNsmKqegD4zdZ98q0Ymt67dqNQg4yHlX44YCGh3JZPJ/fZgR6ucctA1FaDJpA/RV3M3ixd7Hy9mjdWOZW0AJk8MZiPHX70suNStHTsG7fd73Ea/IAP/GaZ/cDIRZBEq2E8hLmuEdulUsr3MpAOcPKFpFgGDYgEoFQ9kRRj9rH1MbqvVZy486TCRDl3WiUosy8Dy+fYKuLHxdFTzey1eLXqB0M2sOpsRYx/E3qgoo6F87Q1AXOAJsZOrfaO/WxHe4fpL3ZZUIWVixlHlJJpKDViSblFB0Bo6tlNDdCz4sWFzUbuQKOVmuB0O4MaOgjTMjJ3dXNe/qs4I7
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(82310400014)(376005)(1800799015)(7416005)(36860700004);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Mar 2024 06:34:28.3685
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 50a6572a-c32c-42ba-f968-08dc4ef11e6c
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH1PEPF0000A34B.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB7643

If run Xen with PVH dom0 and hvm domU, hvm will map a pirq for
a passthrough device by using gsi, see
xen_pt_realize->xc_physdev_map_pirq and
pci_add_dm_done->xc_physdev_map_pirq. Then xc_physdev_map_pirq
will call into Xen, but in hvm_physdev_op, PHYSDEVOP_map_pirq
is not allowed because currd is PVH dom0 and PVH has no
X86_EMU_USE_PIRQ flag, it will fail at has_pirq check.

So, allow PHYSDEVOP_map_pirq when dom0 is PVH and also allow
PHYSDEVOP_unmap_pirq for the failed path to unmap pirq. And
add a new check to prevent self map when caller has no PIRQ
flag.

Signed-off-by: Huang Rui 
Signed-off-by: Jiqian Chen 
Reviewed-by: Stefano Stabellini 
---
 xen/arch/x86/hvm/hypercall.c |  2 ++
 xen/arch/x86/physdev.c       | 24 ++++++++++++++++++++++++
 2 files changed, 26 insertions(+)

diff --git a/xen/arch/x86/hvm/hypercall.c b/xen/arch/x86/hvm/hypercall.c
index 6ad5b4d5f11f..493998b42ec5 100644
--- a/xen/arch/x86/hvm/hypercall.c
+++ b/xen/arch/x86/hvm/hypercall.c
@@ -74,6 +74,8 @@ long hvm_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
     {
     case PHYSDEVOP_map_pirq:
     case PHYSDEVOP_unmap_pirq:
+        break;
+
     case PHYSDEVOP_eoi:
     case PHYSDEVOP_irq_status_query:
     case PHYSDEVOP_get_free_pirq:
diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
index 7efa17cf4c1e..1367abc61e54 100644
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -305,11 +305,23 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
     case PHYSDEVOP_map_pirq: {
         physdev_map_pirq_t map;
         struct msi_info msi;
+        struct domain *d;
 
         ret = -EFAULT;
         if ( copy_from_guest(&map, arg, 1) != 0 )
             break;
 
+        d = rcu_lock_domain_by_any_id(map.domid);
+        if ( d == NULL )
+            return -ESRCH;
+        /* If it is an HVM guest, check if it has PIRQs */
+        if ( !is_pv_domain(d) && !has_pirq(d) )
+        {
+            rcu_unlock_domain(d);
+            return -EOPNOTSUPP;
+        }
+        rcu_unlock_domain(d);
+
         switch ( map.type )
         {
         case MAP_PIRQ_TYPE_MSI_SEG:
@@ -343,11 +355,23 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 
     case PHYSDEVOP_unmap_pirq: {
         struct physdev_unmap_pirq unmap;
+        struct domain *d;
 
         ret = -EFAULT;
         if ( copy_from_guest(&unmap, arg, 1) != 0 )
             break;
 
+        d = rcu_lock_domain_by_any_id(unmap.domid);
+        if ( d == NULL )
+            return -ESRCH;
+        /* If it is an HVM guest, check if it has PIRQs */
+        if ( !is_pv_domain(d) && !has_pirq(d) )
+        {
+            rcu_unlock_domain(d);
+            return -EOPNOTSUPP;
+        }
+        rcu_unlock_domain(d);
+
         ret = physdev_unmap_pirq(unmap.domid, unmap.pirq);
         break;
     }
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Thu Mar 28 06:34:39 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 06:34:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698789.1090934 (Exim 4.92)
	(envelope-from )
	id 1rpjLT-0005rd-G0; Thu, 28 Mar 2024 06:34:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698789.1090934; Thu, 28 Mar 2024 06:34:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpjLT-0005rU-D5; Thu, 28 Mar 2024 06:34:39 +0000
Received: by outflank-mailman (input) for mailman id 698789;
 Thu, 28 Mar 2024 06:34:37 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpjLR-0005pJ-S1
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 06:34:37 +0000
Received: from NAM02-BN1-obe.outbound.protection.outlook.com
 (mail-bn1nam02on20601.outbound.protection.outlook.com
 [2a01:111:f403:2407::601])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3e28000b-eccd-11ee-a1ef-f123f15fe8a2;
 Thu, 28 Mar 2024 07:34:36 +0100 (CET)
Received: from CH2PR04CA0011.namprd04.prod.outlook.com (2603:10b6:610:52::21)
 by DM6PR12MB4107.namprd12.prod.outlook.com (2603:10b6:5:218::7) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.38; Thu, 28 Mar
 2024 06:34:32 +0000
Received: from CH1PEPF0000A348.namprd04.prod.outlook.com
 (2603:10b6:610:52:cafe::ef) by CH2PR04CA0011.outlook.office365.com
 (2603:10b6:610:52::21) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.13 via Frontend
 Transport; Thu, 28 Mar 2024 06:34:32 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CH1PEPF0000A348.mail.protection.outlook.com (10.167.244.4) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Thu, 28 Mar 2024 06:34:32 +0000
Received: from cjq-desktop.amd.com (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 28 Mar
 2024 01:34:28 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3e28000b-eccd-11ee-a1ef-f123f15fe8a2
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=cRD5/CNo8tEudCDKDsIuQIcWFFaQUnVDVi/iXBdPM+NWzo65vVR57KqiFEzk9Cn+b+vSXOuoWjp0H/xw7BdWuRC1OMKeikZ8ffYTsl99a/iTCvJ/87vDIDF+E0gxSfhUfoeCjwWIyU27Vd1M9URAsJKf6JdXVP2yUd2yc5vP9ykJmbNS81mzSpw7IpbD+iyxY/M6CFsrE4YU9ZyaqXTeOMzaedAHDsrEPHXNIHC5zDz4UQZoExkfXYgRUJ1qOsP4R0XTMHx7r12FnCAEQakgp8zomuGE1uCUy/l7m+lhrxrSSeT2eKAJxskW9ehglO1Sg1KYnckKPWjDByG2aEDlcw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Be2hEGsTRGFzCRd5+cpODeHi2HnqaMir4kjvUmtAU34=;
 b=Ja3LQ4mG6J+ADzJ1/dZ3KQ3pmOxNBM5OjCVLdsRh83oKv5y6r6UmggAK+92a4rTu/PUD3jHWsdwTfaiZQBDAE7bHfD+nCr7hNgF9iz6bBsSQE6xUioaTYjNr1aLF5SS6mcn+K3G8GBilv6dF9D2SMXrkko1lJ0s5uQb8i3539fsAcrCEfBflvRrEo65dXZH7UkSwzyxy8Cj9R10BYANcverfoo1NdICAh+P+lvnmLN5HChhJxzGRkkXjKPWi4ZKux2lXp1CKv3X1hxJt1g4sTzRkZrQVEitWZ7e7LHnMbhhga5RLGX53l9ZopkS/5S3TtQ4I1gFIL3aJsv5IMrImNg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=Be2hEGsTRGFzCRd5+cpODeHi2HnqaMir4kjvUmtAU34=;
 b=C7KuzfIimxpNZgkJQp5NVOZvd5NeHzt6JGIJ5rpRRoO85cew8XMo4GR4ouXUiFLoSZefYMXu4rxCY1wnGJHzfBmNQ5Un7dfsDj4zpVJ9l1vMYevHorqRCXXtfNq3M+LENAt7yRR2KsRJ6qTn8MTuqQu5urweEpTHqgvAkSOdtwk=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Jiqian Chen 
To: 
CC: Jan Beulich , Andrew Cooper
	, =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, Wei Liu , George Dunlap
	, Julien Grall , Stefano Stabellini
	, Anthony PERARD ,
	"Juergen Gross" , "Daniel P . Smith"
	, Stewart Hildebrand
	, Huang Rui , Jiqian Chen
	, Huang Rui 
Subject: [RFC XEN PATCH v6 3/5] x86/pvh: Add PHYSDEVOP_setup_gsi for PVH dom0
Date: Thu, 28 Mar 2024 14:34:00 +0800
Message-ID: <20240328063402.354496-4-Jiqian.Chen@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20240328063402.354496-1-Jiqian.Chen@amd.com>
References: <20240328063402.354496-1-Jiqian.Chen@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH1PEPF0000A348:EE_|DM6PR12MB4107:EE_
X-MS-Office365-Filtering-Correlation-Id: 10bad40a-388b-4725-e293-08dc4ef120e1
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	e9AShgNFlrKvWWSwwtR+kmyhcjxD0+DxjV/YFBbvoiPMzCqTxxbbj77mVG1SFirgVB6ioJ0DYHtc9DBESATxWVpep8hCMna5onDYXH7cZ3KHjyXJ5DUKVpZscJUgPhb+DrOzDVQbh8V9Ay8ywwNDzm+WgORs0cbcudC7FmPnvJ/uBbS6FGh7cDXTTPIJ0Jt0BN9R3ILBXlgcfvLDcy3ywQdbL+myoo2LugJYd8kNGHi9BU6lCjE1gA4mszX95JnnguMHD8N4dtQIJK4Y5o/WtHNrerUknBYxvxNsJKWZa6lN6y1ybuR5w+krRaJB5myO7kWlDX5Bk80JDMLmy4sJTNSWRwrb+e6OCxl7GKTdDBPast9eR1+KsXd/PNviH0VXCxrSxX3xyd44geutveCkNbPNOqdiV/dz1+oWAlbyZ72kHPAKeCrG+ZxjrBrvrhoHyiROr0Xo+tO+v8gltxe12QomQ259BUVI/1uvJaBVyovzizMMssUdbr2Ww1/jiJvCIIDhCH1j5AugxkTFgtmT23mtIl4yVr5pfQ//ztwmhOpoZns7P3VxE999WZRbQNx87jLls3gin9uijdymkQttqiSYgEun43ppHfQRXtOLStzwER2XDzFqbl86krkGTAkGCj+3zfDWalnIy7JGbr1weH8ySn2gU5wgKyFyRMl958Ri+tVpK2fxAcEtmY8i0289q8Uwc5gC9Z98N77y2IZ9cqHY6JIhrSOuJGUluEGNoxFJyNGZB1+u6tJYu0nOQW4D
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(36860700004)(82310400014)(376005)(7416005)(1800799015);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Mar 2024 06:34:32.4902
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 10bad40a-388b-4725-e293-08dc4ef120e1
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH1PEPF0000A348.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4107

On PVH dom0, the gsis don't get registered, but
the gsi of a passthrough device must be configured for it to
be able to be mapped into a hvm domU.
On Linux kernel side, it calles PHYSDEVOP_setup_gsi for
passthrough devices to register gsi when dom0 is PVH.
So, add PHYSDEVOP_setup_gsi for above purpose.

Signed-off-by: Huang Rui 
Signed-off-by: Jiqian Chen 
---
 xen/arch/x86/hvm/hypercall.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/xen/arch/x86/hvm/hypercall.c b/xen/arch/x86/hvm/hypercall.c
index 493998b42ec5..7d4e41f66885 100644
--- a/xen/arch/x86/hvm/hypercall.c
+++ b/xen/arch/x86/hvm/hypercall.c
@@ -76,6 +76,11 @@ long hvm_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
     case PHYSDEVOP_unmap_pirq:
         break;
 
+    case PHYSDEVOP_setup_gsi:
+        if ( !is_hardware_domain(currd) )
+            return -EOPNOTSUPP;
+        break;
+
     case PHYSDEVOP_eoi:
     case PHYSDEVOP_irq_status_query:
     case PHYSDEVOP_get_free_pirq:
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Thu Mar 28 06:34:41 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 06:34:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698790.1090944 (Exim 4.92)
	(envelope-from )
	id 1rpjLV-0006Aj-O7; Thu, 28 Mar 2024 06:34:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698790.1090944; Thu, 28 Mar 2024 06:34:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpjLV-0006Ac-Kp; Thu, 28 Mar 2024 06:34:41 +0000
Received: by outflank-mailman (input) for mailman id 698790;
 Thu, 28 Mar 2024 06:34:39 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpjLT-00050u-MS
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 06:34:39 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on20600.outbound.protection.outlook.com
 [2a01:111:f403:2418::600])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3ffe7145-eccd-11ee-afe3-a90da7624cb6;
 Thu, 28 Mar 2024 07:34:39 +0100 (CET)
Received: from CH0P221CA0038.NAMP221.PROD.OUTLOOK.COM (2603:10b6:610:11d::24)
 by PH7PR12MB7164.namprd12.prod.outlook.com (2603:10b6:510:203::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.32; Thu, 28 Mar
 2024 06:34:36 +0000
Received: from CH1PEPF0000A34B.namprd04.prod.outlook.com
 (2603:10b6:610:11d:cafe::cf) by CH0P221CA0038.outlook.office365.com
 (2603:10b6:610:11d::24) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.13 via Frontend
 Transport; Thu, 28 Mar 2024 06:34:36 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CH1PEPF0000A34B.mail.protection.outlook.com (10.167.244.10) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Thu, 28 Mar 2024 06:34:36 +0000
Received: from cjq-desktop.amd.com (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 28 Mar
 2024 01:34:32 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3ffe7145-eccd-11ee-afe3-a90da7624cb6
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=kaVqPSsWHdUtxjhkqgN0WT+cqpQbtvozgcZ3W5daCUv5GeOyJBGT5+AF8paYADyKuxAvF7+QTIpjXF69tH5zahoM3NpQYFrm5jtzfV1v/VbP7Ngt3UAvDmHmj/eclpfNQQpPRXoMP29mqSVhr6rdwVbfn+eBHXIvb40O1aVzetg/da9VG37s2KENTL1brOWJpaQTeTA88vceMd/teqpFWYBNvC8BGu8ibI2uwMM5XlfN+65O0zr3FwuGRLkZwtHz8a8xQYc8cNLNb2e2B6+RfTx+ylGwAse7rK1FZLRRHFswfnlfGR867vCEaxKBc4UZIn+M+lckOkGEaXLqwAj3pQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=/ZL0xK3Pv/stc/fF301pIcUEWskFlD6vojcmINMIZc4=;
 b=FGKnYxp7PH1rOHJdgYPYt9Ua+vTMfVreIKvrWsRfXNZjjM5zuLZLd+lI6mMAJoys6uCB0b8lXepGmZt2ifaz7ySk/rYhFVoRagOXWU35ofjR6F0ttqBoQ5hZHfIu8Xdo1lSrlAqjabtj2IxR1Oro+Ehag+igLwdShWaJ0zBsTzMP5ZmnNOT6K1vGhY8cNle16AuZIBhRD1TZ3pTzT9QcCN7OfWCSph2vDKRGgUMCEiKiMy042bv0Db6Z7BZH8iOAC+1+BWsPPaktDPCxZzsJhvmnpMHe0ALI9ldGrBUPKTJjfUBWge9QYHJhh9JSWmQx49D5RxeIfgOpOpqtg1skPA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=/ZL0xK3Pv/stc/fF301pIcUEWskFlD6vojcmINMIZc4=;
 b=1QiEkZKnWr61YZ/sQ/EZ8mq1Kp2Hlj3yczVg5wEzkNAFDtzhGZ9FqwfszNI3KE48Ou7aIsXQRaxIEui58LiaN42QNMj+PWLAeMCccg9AKhNwZSY4ueUMnd+WKrF2kjkYeY9Vy3MkN/MSjLexd2hlfBdfKnmBN9ulegbx7aooK3U=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Jiqian Chen 
To: 
CC: Jan Beulich , Andrew Cooper
	, =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, Wei Liu , George Dunlap
	, Julien Grall , Stefano Stabellini
	, Anthony PERARD ,
	"Juergen Gross" , "Daniel P . Smith"
	, Stewart Hildebrand
	, Huang Rui , Jiqian Chen
	, Huang Rui 
Subject: [RFC XEN PATCH v6 4/5] libxl: Use gsi instead of irq for mapping pirq
Date: Thu, 28 Mar 2024 14:34:01 +0800
Message-ID: <20240328063402.354496-5-Jiqian.Chen@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20240328063402.354496-1-Jiqian.Chen@amd.com>
References: <20240328063402.354496-1-Jiqian.Chen@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH1PEPF0000A34B:EE_|PH7PR12MB7164:EE_
X-MS-Office365-Filtering-Correlation-Id: 8504107b-0e85-4fa5-d7e6-08dc4ef122fa
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	wTj2gMa6OPXvnTocvYNN8u+jeyJ6TJnFca7Y/DJfyHg3gBhLJ6HtqLoXX638ekSx4EmghOEElE8yJl8WNtMseWuZTr4dy/KqmAnVk5NkVzZdgZlNrp+KZPmd8fBo5mZHs3hWQp5pUcy57insiet0cuJbpH+ee8c8eT/P2hzt2lllhRv7eTYx/6HJftasRSRJ0OzWmKkejrCCXNoP545jr6zTyx1YsGq5KRXgwfRUOMvJ+2PVei8yrWknhO+khQj++hMmq5RGvHJ4YawNHEuI7jOEJNAUbZkLeJvUwW40RmGMlRK/VQjUwDFc9QSaNC0TF/UMqt+g8Ch9LBtSeHtXbJmbAg/tM3f0QSwH79f3ccnIwhsU0d2qZxY2xJ4mpkQX5FmWk9EZ0IBzsY68IkG1eg5KaDCzXzjG598fFXreObHfjY/8FRim4MY73KdmTvqFI3KSXS9wAXZpUOziBZHUIBZakAnsqE5H8ysqxWciIhzKE6/snyLz4yU6TacXeXDCZoF8UmSo/T+0UDO/pkhSvr8naaGd/OoaZo5q9cwMUWRb9iMk4NQUTGkS2fNMhJyvl6INQLWO5So9v1lisGJfAeJ404SYqbnl3yadvASL2KVTYlTHpLa9wbJkQSkC/+lDVZ6CbaxN657DvQNVNlJzsukeT2TtfXdX9VVPo5WrUYevPsBbPrgl/w/nDcyMXLWOGWderTulT+9pLZOyN+GTjcL/lR5OtpdkkIi7YDrXYlLtxAZ/rpiJeg52IV4sDlkl
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(1800799015)(36860700004)(82310400014)(7416005)(376005);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Mar 2024 06:34:36.0092
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 8504107b-0e85-4fa5-d7e6-08dc4ef122fa
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH1PEPF0000A34B.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB7164

In PVH dom0, it uses the linux local interrupt mechanism,
when it allocs irq for a gsi, it is dynamic, and follow
the principle of applying first, distributing first. And
the irq number is alloced from small to large, but the
applying gsi number is not, may gsi 38 comes before gsi
28, that causes the irq number is not equal with the gsi
number. And when passthrough a device, xl wants to use
gsi to map pirq, see pci_add_dm_done->xc_physdev_map_pirq,
but the gsi number is got from file
/sys/bus/pci/devices//irq in current code, so it
will fail when mapping.

So, use real gsi number read from gsi sysfs.

Signed-off-by: Huang Rui 
Signed-off-by: Jiqian Chen 
Reviewed-by: Stefano Stabellini 

---
RFC: discussions ongoing on the Linux side where/how to expose the gsi

---
 tools/libs/light/libxl_pci.c | 16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/tools/libs/light/libxl_pci.c b/tools/libs/light/libxl_pci.c
index 96cb4da0794e..2cec83e0b734 100644
--- a/tools/libs/light/libxl_pci.c
+++ b/tools/libs/light/libxl_pci.c
@@ -1478,8 +1478,14 @@ static void pci_add_dm_done(libxl__egc *egc,
     fclose(f);
     if (!pci_supp_legacy_irq())
         goto out_no_irq;
-    sysfs_path = GCSPRINTF(SYSFS_PCI_DEV"/"PCI_BDF"/irq", pci->domain,
+    sysfs_path = GCSPRINTF(SYSFS_PCI_DEV"/"PCI_BDF"/gsi", pci->domain,
                                 pci->bus, pci->dev, pci->func);
+    r = access(sysfs_path, F_OK);
+    if (r && errno == ENOENT) {
+        /* To compitable with old version of kernel, still need to use irq */
+        sysfs_path = GCSPRINTF(SYSFS_PCI_DEV"/"PCI_BDF"/irq", pci->domain,
+                               pci->bus, pci->dev, pci->func);
+    }
     f = fopen(sysfs_path, "r");
     if (f == NULL) {
         LOGED(ERROR, domainid, "Couldn't open %s", sysfs_path);
@@ -2229,9 +2235,15 @@ skip_bar:
     if (!pci_supp_legacy_irq())
         goto skip_legacy_irq;
 
-    sysfs_path = GCSPRINTF(SYSFS_PCI_DEV"/"PCI_BDF"/irq", pci->domain,
+    sysfs_path = GCSPRINTF(SYSFS_PCI_DEV"/"PCI_BDF"/gsi", pci->domain,
                            pci->bus, pci->dev, pci->func);
 
+    rc = access(sysfs_path, F_OK);
+    if (rc && errno == ENOENT) {
+        /* To compitable with old version of kernel, still need to use irq */
+        sysfs_path = GCSPRINTF(SYSFS_PCI_DEV"/"PCI_BDF"/irq", pci->domain,
+                               pci->bus, pci->dev, pci->func);
+    }
     f = fopen(sysfs_path, "r");
     if (f == NULL) {
         LOGED(ERROR, domid, "Couldn't open %s", sysfs_path);
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Thu Mar 28 06:34:45 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 06:34:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698791.1090954 (Exim 4.92)
	(envelope-from )
	id 1rpjLZ-0006ZA-0w; Thu, 28 Mar 2024 06:34:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698791.1090954; Thu, 28 Mar 2024 06:34:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpjLY-0006Z3-Th; Thu, 28 Mar 2024 06:34:44 +0000
Received: by outflank-mailman (input) for mailman id 698791;
 Thu, 28 Mar 2024 06:34:44 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpjLY-00050u-9n
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 06:34:44 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on20624.outbound.protection.outlook.com
 [2a01:111:f400:7e88::624])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 42a37dcb-eccd-11ee-afe3-a90da7624cb6;
 Thu, 28 Mar 2024 07:34:43 +0100 (CET)
Received: from CH2PR16CA0004.namprd16.prod.outlook.com (2603:10b6:610:50::14)
 by LV3PR12MB9188.namprd12.prod.outlook.com (2603:10b6:408:19b::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.33; Thu, 28 Mar
 2024 06:34:40 +0000
Received: from CH1PEPF0000A349.namprd04.prod.outlook.com
 (2603:10b6:610:50:cafe::cf) by CH2PR16CA0004.outlook.office365.com
 (2603:10b6:610:50::14) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.39 via Frontend
 Transport; Thu, 28 Mar 2024 06:34:40 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CH1PEPF0000A349.mail.protection.outlook.com (10.167.244.9) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Thu, 28 Mar 2024 06:34:39 +0000
Received: from cjq-desktop.amd.com (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 28 Mar
 2024 01:34:35 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 42a37dcb-eccd-11ee-afe3-a90da7624cb6
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=TeB0gOXfEDmfiUZVoLSTLEiLfXliEtDMvm+BI4TMzOgR2wz/OsUhIxO3IFn7eeKgd3o8JR2CHEJUAPBIT6tqiOmW2UICJTil+lFfldZw9izf0aj3XsmfJI838f8FrP7RWrQcA4oDlPjdsLDbPpQ0j2sO9uXKKYua8iRv6fiw/x4945JNTD8Fo1sjmpk9oFsH0jvDbDkqLhVa19JaNMT9q6frU8MAtjDf/VZYPkUealvVRB5TitKB1COMcrdUEcD09A1BQZnUJLFqPVmmsoCT8aHI5FGTQ0HNAgBanvZ87TDhnRhCQ3tW4BGt3zSm62mbVngwsN/yLVRee5351IQnew==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=AYVEVM14U5UZ2YEi1dg7K9xI2Fd7nuSqWrGJlbiocK8=;
 b=WNUpsOedxHeTLLGnGBop8pnvUc9PrYLtTdn5HHNeHBzqFIaw5ql/eEIb9FbSq03kj0wMZ5kbB0y+zogTFy56q9wjTgJQaqhQmmDgUTvyGN5US+fJwSmkJWReQVHPSYCEXQW8RHQB/36QQaLJ9NFm366tThGvJ5G6YT9KRNqP96/c9rsFths8hWi692z5awdAXOBvFfDKF87NkUHsJJL0gHUQ3b58lqx/9bqDzKvS1QRvkn1jDt/99jriXNawFFuu+OMUjUAiYMI91CFbJax5MI+RVnO6D+6LewHBGUfN/2925kafyn067codD45xb7cHgrqKzw3y9kUW6nE2IvTKaQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=AYVEVM14U5UZ2YEi1dg7K9xI2Fd7nuSqWrGJlbiocK8=;
 b=FM00paNZJ1UhckIbrDM0UTNDlVZ8U1YhkeRfqJL07ZVZZ3eLI2fFliXyGyH68X9JA2imW89yV4byb/EGWjdx1944Rs6GmnLuAvBcsS/bng9sXFyb/IHWWhBSz5FleSAfItZyix23+EDDdVUraZtcCCaARbznnosXMYOjd+eV3yk=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Jiqian Chen 
To: 
CC: Jan Beulich , Andrew Cooper
	, =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, Wei Liu , George Dunlap
	, Julien Grall , Stefano Stabellini
	, Anthony PERARD ,
	"Juergen Gross" , "Daniel P . Smith"
	, Stewart Hildebrand
	, Huang Rui , Jiqian Chen
	, Huang Rui 
Subject: [RFC XEN PATCH v6 5/5] domctl: Add XEN_DOMCTL_gsi_permission to grant gsi
Date: Thu, 28 Mar 2024 14:34:02 +0800
Message-ID: <20240328063402.354496-6-Jiqian.Chen@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20240328063402.354496-1-Jiqian.Chen@amd.com>
References: <20240328063402.354496-1-Jiqian.Chen@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH1PEPF0000A349:EE_|LV3PR12MB9188:EE_
X-MS-Office365-Filtering-Correlation-Id: b354861a-c49f-4c92-f056-08dc4ef1254a
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	IOAuaYrNBz1VtmJNNXerVNOzHHRK6fX1ObcRPA9SzfrWOH4dOf7/qqPF3r02OMa4QErozETSPhrCxNfYNJuH1lm214aX6zDqfL/Y1qpK8w+otb9eAd3DuT4cgNdTXdoSs70ov6kuwXR7XBo0bOqBA0Ka77W9636wqoV/3HM84LI0m/0ugjAz5Daz9pm4dgBm14onCR1S+fWpt7u+zPUK9ZOzS9Dhk9/bA5gsE7x82D9290yV3TqTDHkbwW9m0McfdeTgV+BryV0DEvhOMtBpAN1lGPLGnqf2wrFOHSlCjbOqviQ7emZxG2KV+2HPA4HlYMGq+S+/u1pawyKPTkY9eCcH51QVGLf31NgVaBqg3cc10YOVmpd/99AjR9TVlb+wQLs+Cc5K6t8LR0JC1/Bu71zCs6b5M7jY+JDbwLpxTkqbD4GNitiv7f8NAhgy/fxkqf2HZR4EHtgmWsW1l1y6yy1juj9jtRLQE0Xn25GOPLZW/MTLGk4UMt5NlJpzooe9bwx8zxK0sr1iQl3VX+KqbCOBlAZhgGthDKijxdkXIEQtKxIUOuB1YMVJWeX55TJsuldy3iaBjwo+xcRAE6QsD43seGdaZKqRLxght/yMfiFtUZn7jV/gloZMlqIfVJgk2xNDQV5Mq3FIoTKl4yRRwYHCU4Jw2WW1SFHQhcYQ3dGxf+mA1d9nHNrIuI7SORkf5lvHwogADtAN01BUSRKZQJNkIHNRU9caB4UHhaoXORqE3eY0nvXO6qrs4DZIXgbh
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(36860700004)(1800799015)(82310400014)(376005)(7416005);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Mar 2024 06:34:39.8895
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: b354861a-c49f-4c92-f056-08dc4ef1254a
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH1PEPF0000A349.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR12MB9188

Some type of domain don't have PIRQ, like PVH, when
passthrough a device to guest on PVH dom0, callstack
pci_add_dm_done->XEN_DOMCTL_irq_permission will failed
at domain_pirq_to_irq.

So, add a new hypercall to grant/revoke gsi permission
when dom0 is not PV or dom0 has not PIRQ flag.

Signed-off-by: Huang Rui 
Signed-off-by: Jiqian Chen 
---
 tools/include/xenctrl.h      |  5 ++++
 tools/libs/ctrl/xc_domain.c  | 15 +++++++++++
 tools/libs/light/libxl_pci.c | 52 +++++++++++++++++++++++++++++-------
 xen/arch/x86/domctl.c        | 31 +++++++++++++++++++++
 xen/include/public/domctl.h  |  9 +++++++
 xen/xsm/flask/hooks.c        |  1 +
 6 files changed, 103 insertions(+), 10 deletions(-)

diff --git a/tools/include/xenctrl.h b/tools/include/xenctrl.h
index 2ef8b4e05422..519c860a00d5 100644
--- a/tools/include/xenctrl.h
+++ b/tools/include/xenctrl.h
@@ -1382,6 +1382,11 @@ int xc_domain_irq_permission(xc_interface *xch,
                              uint32_t pirq,
                              bool allow_access);
 
+int xc_domain_gsi_permission(xc_interface *xch,
+                             uint32_t domid,
+                             uint32_t gsi,
+                             bool allow_access);
+
 int xc_domain_iomem_permission(xc_interface *xch,
                                uint32_t domid,
                                unsigned long first_mfn,
diff --git a/tools/libs/ctrl/xc_domain.c b/tools/libs/ctrl/xc_domain.c
index f2d9d14b4d9f..8540e84fda93 100644
--- a/tools/libs/ctrl/xc_domain.c
+++ b/tools/libs/ctrl/xc_domain.c
@@ -1394,6 +1394,21 @@ int xc_domain_irq_permission(xc_interface *xch,
     return do_domctl(xch, &domctl);
 }
 
+int xc_domain_gsi_permission(xc_interface *xch,
+                             uint32_t domid,
+                             uint32_t gsi,
+                             bool allow_access)
+{
+    struct xen_domctl domctl = {
+        .cmd = XEN_DOMCTL_gsi_permission,
+        .domain = domid,
+        .u.gsi_permission.gsi = gsi,
+        .u.gsi_permission.allow_access = allow_access,
+    };
+
+    return do_domctl(xch, &domctl);
+}
+
 int xc_domain_iomem_permission(xc_interface *xch,
                                uint32_t domid,
                                unsigned long first_mfn,
diff --git a/tools/libs/light/libxl_pci.c b/tools/libs/light/libxl_pci.c
index 2cec83e0b734..debf6ec6ddc7 100644
--- a/tools/libs/light/libxl_pci.c
+++ b/tools/libs/light/libxl_pci.c
@@ -1421,6 +1421,8 @@ static void pci_add_dm_done(libxl__egc *egc,
     uint32_t flag = XEN_DOMCTL_DEV_RDM_RELAXED;
     uint32_t domainid = domid;
     bool isstubdom = libxl_is_stubdom(ctx, domid, &domainid);
+    int gsi;
+    bool is_gsi = true;
 
     /* Convenience aliases */
     bool starting = pas->starting;
@@ -1485,6 +1487,7 @@ static void pci_add_dm_done(libxl__egc *egc,
         /* To compitable with old version of kernel, still need to use irq */
         sysfs_path = GCSPRINTF(SYSFS_PCI_DEV"/"PCI_BDF"/irq", pci->domain,
                                pci->bus, pci->dev, pci->func);
+        is_gsi = false;
     }
     f = fopen(sysfs_path, "r");
     if (f == NULL) {
@@ -1492,6 +1495,13 @@ static void pci_add_dm_done(libxl__egc *egc,
         goto out_no_irq;
     }
     if ((fscanf(f, "%u", &irq) == 1) && irq) {
+        /*
+         * If use gsi, save the value, because the value of irq
+         * will be changed by function xc_physdev_map_pirq
+         */
+        if (is_gsi) {
+            gsi = irq;
+        }
         r = xc_physdev_map_pirq(ctx->xch, domid, irq, &irq);
         if (r < 0) {
             LOGED(ERROR, domainid, "xc_physdev_map_pirq irq=%d (error=%d)",
@@ -1500,13 +1510,25 @@ static void pci_add_dm_done(libxl__egc *egc,
             rc = ERROR_FAIL;
             goto out;
         }
-        r = xc_domain_irq_permission(ctx->xch, domid, irq, 1);
-        if (r < 0) {
-            LOGED(ERROR, domainid,
-                  "xc_domain_irq_permission irq=%d (error=%d)", irq, r);
-            fclose(f);
-            rc = ERROR_FAIL;
-            goto out;
+        if (is_gsi) {
+            r = xc_domain_gsi_permission(ctx->xch, domid, gsi, 1);
+            if (r < 0 && r != -EOPNOTSUPP) {
+                LOGED(ERROR, domainid,
+                      "xc_domain_gsi_permission gsi=%d (error=%d)", gsi, r);
+                fclose(f);
+                rc = ERROR_FAIL;
+                goto out;
+            }
+        }
+        if (!is_gsi || r == -EOPNOTSUPP) {
+            r = xc_domain_irq_permission(ctx->xch, domid, irq, 1);
+            if (r < 0) {
+                LOGED(ERROR, domainid,
+                    "xc_domain_irq_permission irq=%d (error=%d)", irq, r);
+                fclose(f);
+                rc = ERROR_FAIL;
+                goto out;
+            }
         }
     }
     fclose(f);
@@ -2180,6 +2202,7 @@ static void pci_remove_detached(libxl__egc *egc,
     FILE *f;
     uint32_t domainid = prs->domid;
     bool isstubdom;
+    bool is_gsi = true;
 
     /* Convenience aliases */
     libxl_device_pci *const pci = &prs->pci;
@@ -2243,6 +2266,7 @@ skip_bar:
         /* To compitable with old version of kernel, still need to use irq */
         sysfs_path = GCSPRINTF(SYSFS_PCI_DEV"/"PCI_BDF"/irq", pci->domain,
                                pci->bus, pci->dev, pci->func);
+        is_gsi = false;
     }
     f = fopen(sysfs_path, "r");
     if (f == NULL) {
@@ -2261,9 +2285,17 @@ skip_bar:
              */
             LOGED(ERROR, domid, "xc_physdev_unmap_pirq irq=%d", irq);
         }
-        rc = xc_domain_irq_permission(ctx->xch, domid, irq, 0);
-        if (rc < 0) {
-            LOGED(ERROR, domid, "xc_domain_irq_permission irq=%d", irq);
+        if (is_gsi) {
+            rc = xc_domain_gsi_permission(ctx->xch, domid, irq, 0);
+            if (rc < 0 && rc != -EOPNOTSUPP) {
+                LOGED(ERROR, domid, "xc_domain_gsi_permission gsi=%d", irq);
+            }
+        }
+        if (!is_gsi || rc == -EOPNOTSUPP) {
+            rc = xc_domain_irq_permission(ctx->xch, domid, irq, 0);
+            if (rc < 0) {
+                LOGED(ERROR, domid, "xc_domain_irq_permission irq=%d", irq);
+            }
         }
     }
 
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 9a72d57333e9..9b8a08b2a81d 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -237,6 +237,37 @@ long arch_do_domctl(
         break;
     }
 
+    case XEN_DOMCTL_gsi_permission:
+    {
+        unsigned int gsi = domctl->u.gsi_permission.gsi;
+        int allow = domctl->u.gsi_permission.allow_access;
+
+        if ( is_pv_domain(current->domain) || has_pirq(current->domain) )
+        {
+            ret = -EOPNOTSUPP;
+            break;
+        }
+
+        if ( gsi >= nr_irqs_gsi )
+        {
+            ret = -EINVAL;
+            break;
+        }
+
+        if ( !irq_access_permitted(current->domain, gsi) ||
+             xsm_irq_permission(XSM_HOOK, d, gsi, allow) )
+        {
+            ret = -EPERM;
+            break;
+        }
+
+        if ( allow )
+            ret = irq_permit_access(d, gsi);
+        else
+            ret = irq_deny_access(d, gsi);
+        break;
+    }
+
     case XEN_DOMCTL_getpageframeinfo3:
     {
         unsigned int num = domctl->u.getpageframeinfo3.num;
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index a33f9ec32b08..47e95f9ee824 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -447,6 +447,13 @@ struct xen_domctl_irq_permission {
 };
 
 
+/* XEN_DOMCTL_gsi_permission */
+struct xen_domctl_gsi_permission {
+    uint32_t gsi;
+    uint8_t allow_access;    /* flag to specify enable/disable of x86 gsi access */
+};
+
+
 /* XEN_DOMCTL_iomem_permission */
 struct xen_domctl_iomem_permission {
     uint64_aligned_t first_mfn;/* first page (physical page number) in range */
@@ -1277,6 +1284,7 @@ struct xen_domctl {
 #define XEN_DOMCTL_vmtrace_op                    84
 #define XEN_DOMCTL_get_paging_mempool_size       85
 #define XEN_DOMCTL_set_paging_mempool_size       86
+#define XEN_DOMCTL_gsi_permission                87
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -1299,6 +1307,7 @@ struct xen_domctl {
         struct xen_domctl_setdomainhandle   setdomainhandle;
         struct xen_domctl_setdebugging      setdebugging;
         struct xen_domctl_irq_permission    irq_permission;
+        struct xen_domctl_gsi_permission    gsi_permission;
         struct xen_domctl_iomem_permission  iomem_permission;
         struct xen_domctl_ioport_permission ioport_permission;
         struct xen_domctl_hypercall_init    hypercall_init;
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 78225f68c15c..376076865198 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -685,6 +685,7 @@ static int cf_check flask_domctl(struct domain *d, int cmd)
     case XEN_DOMCTL_shadow_op:
     case XEN_DOMCTL_ioport_permission:
     case XEN_DOMCTL_ioport_mapping:
+    case XEN_DOMCTL_gsi_permission:
 #endif
 #ifdef CONFIG_HAS_PASSTHROUGH
     /*
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Thu Mar 28 06:44:20 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 06:44:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698806.1090963 (Exim 4.92)
	(envelope-from )
	id 1rpjUj-0001el-VB; Thu, 28 Mar 2024 06:44:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698806.1090963; Thu, 28 Mar 2024 06:44:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpjUj-0001ee-Sg; Thu, 28 Mar 2024 06:44:13 +0000
Received: by outflank-mailman (input) for mailman id 698806;
 Thu, 28 Mar 2024 06:44:12 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpjUi-0001eX-PI
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 06:44:12 +0000
Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com
 [2a00:1450:4864:20::433])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9516463d-ecce-11ee-a1ef-f123f15fe8a2;
 Thu, 28 Mar 2024 07:44:10 +0100 (CET)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-33eee0258abso308442f8f.3
 for ; Wed, 27 Mar 2024 23:44:10 -0700 (PDT)
Received: from ?IPV6:2003:ca:b738:601a:1073:a6:6f09:9d9a?
 (p200300cab738601a107300a66f099d9a.dip0.t-ipconnect.de.
 [2003:ca:b738:601a:1073:a6:6f09:9d9a])
 by smtp.gmail.com with ESMTPSA id
 o18-20020adfca12000000b0033ec81ec4aesm865204wrh.78.2024.03.27.23.44.09
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 27 Mar 2024 23:44:09 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9516463d-ecce-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711608250; x=1712213050; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=3+ngn8E3vs13LHuA7cDAEqxMP1Otz8IieGxNdDhDTH4=;
        b=IPFac2HzEIycZGTkj8rJvqR/FMgotuV7U7mBBGg4pEHqaoPAfWh/NsLXDYMias5/NO
         a3/OXiSKoRQE6dtIggYz5N+DtWwrM/XQN0OKEQlAGuVodru2KH3kRh/NyGKBWl1MtYVK
         j32AcpxpxSSeNp8ARKQqjyG6FWnkp8kX20ZAU4kgO0okK1TwpfTtg55K+Pi2t3EQt90C
         28ID80jZQiAIy4PZUXxGDZyrgI28oQk/t1p5HaRPxK2zp4FAa2c/KDJogls1iPoaVCKU
         cNJy0HjBWpE57No2iK+5yWcfs91TY/qIacsAh+DL9hOI5UyevJMBOEC7d9OfohLF7Jyq
         P6hw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711608250; x=1712213050;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=3+ngn8E3vs13LHuA7cDAEqxMP1Otz8IieGxNdDhDTH4=;
        b=YlYo+0ttcSKFadA0DDnT+GcGbhICk8+WyW5jtocPBmufboryUQMcN454oKNQSZ+fyZ
         V06u0mGzPfyuNv2gxb2PHjn8CPYLTyZmaDx2j0olwvhsIFuc1CJKxtfTrYs5gDx/hDM5
         rmF47Ngx3EHGNx0X59jlUvc0+g+idomDxL8MSdDUS/cwqsM9THuolQush8QUyDioOmhi
         y2+mLM/FAY5W/Bby+rThXZBHPj1KMJafdXqRdT2w3D2LYJUHjc5byCjYi5Ys3K+kreMH
         9HsJhdswKZE4fBLUreYWC2nlR1PppTnZTvyRMAdQ3OqZJnZuhqciCKMTiIZC35TR/FpE
         DGwQ==
X-Forwarded-Encrypted: i=1; AJvYcCXAvu1SQ1o4V6lLGAz1uWBIOPE5OJpTe4Kq5+P8sRQIVSFxYZoU1tr2eU7nFPc+JxPFcUkBo0mEg0wscI09VSDz5g3/KZGZCtofmGTX2RM=
X-Gm-Message-State: AOJu0YwfXHDEIDrokdvU+Plm7a4tDafh3aihxUdZ6Qa1DHBlODfM7ojH
	WxJvVbqutgqh8Qj3Z7LyVjgrsPiT5YIhaCvHJkIfJD4soM+LN6reKBL7CavwcQ==
X-Google-Smtp-Source: AGHT+IFqhcT2qtauiJS3uwVxW9fbZO7buKGqLYAeBcQprvw10Vf3qS56d5IsqdA6MLVMsGfqM9z1ng==
X-Received: by 2002:a5d:6e51:0:b0:33e:d244:9c62 with SMTP id j17-20020a5d6e51000000b0033ed2449c62mr1199980wrz.68.1711608249959;
        Wed, 27 Mar 2024 23:44:09 -0700 (PDT)
Message-ID: 
Date: Thu, 28 Mar 2024 07:44:08 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 3/3] svm/nestedsvm: Introduce nested capabilities bit
Content-Language: en-US
To: George Dunlap ,
 Andrew Cooper 
Cc: Julien Grall , Stefano Stabellini
 , Wei Liu ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Jun Nakajima , Kevin Tian ,
 xen-devel@lists.xenproject.org
References: <20240313122454.965566-1-george.dunlap@cloud.com>
 <20240313122454.965566-4-george.dunlap@cloud.com>
 <7a5b3ec3-c122-479a-b714-529e150bf4c0@suse.com>
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 27.03.2024 18:01, George Dunlap wrote:
> On Mon, Mar 18, 2024 at 2:17 PM Jan Beulich  wrote:
>> On 13.03.2024 13:24, George Dunlap wrote:
>>> --- a/xen/arch/x86/domain.c
>>> +++ b/xen/arch/x86/domain.c
>>> @@ -673,6 +673,12 @@ int arch_sanitise_domain_config(struct xen_domctl_createdomain *config)
>>>           */
>>>          config->flags |= XEN_DOMCTL_CDF_oos_off;
>>>
>>> +    if ( nested_virt && !hvm_nested_virt_supported() )
>>> +    {
>>> +        dprintk(XENLOG_INFO, "Nested virt requested but not available\n");
>>> +        return -EINVAL;
>>> +    }
>>> +
>>>      if ( nested_virt && !hap )
>>>      {
>>>          dprintk(XENLOG_INFO, "Nested virt not supported without HAP\n");
>>
>> As mentioned in reply to v1, I think what both start_nested_{svm,vmx}() check
>> is redundant with this latter check. I think that check isn't necessary there
>> (yet unlike suggested in reply to v1 I don't think anymore that the check here
>> can alternatively be dropped). And even if it was to be kept for some reason,
>> I'm having some difficulty seeing why vendor code needs to do that check, when
>> nestedhvm_setup() could do it for both of them.
> 
> I'm having a bit of trouble resolving the antecedents in this
> paragraph (what "this" and "there" are referring to).
> 
> Are you saying that we should set hvm_funcs.caps.nested_virt to 'true'
> even if the hardware doesn't support HAP, because we check that here?
> 
> That seems like a very strange way to go about things; hvm_funcs.caps
> should reflect the actual capabilities of the hardware.  Suppose at
> some point we want to expose nested virt capability to the toolstack
> -- wouldn't it make more sense to be able to just read
> `hvm_funcs.caps.nested_virt`, rather than having to remember to && it
> with `hvm_funcs.caps.hap`?
> 
> And as you say, you can't get rid of the HAP check here, because we
> also want to deny nested virt if the admin deliberately created a
> guest in shadow mode on a system that has HAP available.  So it's not
> redundant: one is checking the capabilities of the system, the other
> is checking the requested guest configuration.

Hmm, yes, you're right.

> As to why to have each vendor independent code check for HAP -- there
> are in fact two implementations of the code; it's nice to be able to
> look in one place for each implementation to determine the
> requirements.  Additionally, it would be possible, in the future, for
> one of the nested virt implementations to enable shadow mode, while
> the other one didn't.  The current arrangement makes that easy.

Well, first - how likely is this, when instead we've been considering
whether we could get rid of shadow mode? And then this is balancing
between ease of future changes vs avoiding redundancy where it can be
avoided. I'm not going to insist on centralizing the HAP check, but I
certainly wanted the option to be considered.

>>> --- a/xen/arch/x86/hvm/nestedhvm.c
>>> +++ b/xen/arch/x86/hvm/nestedhvm.c
>>> @@ -150,6 +150,16 @@ static int __init cf_check nestedhvm_setup(void)
>>>      __clear_bit(0x80, shadow_io_bitmap[0]);
>>>      __clear_bit(0xed, shadow_io_bitmap[1]);
>>>
>>> +    /*
>>> +     * NB this must be called after all command-line processing has been
>>> +     * done, so that if (for example) HAP is disabled, nested virt is
>>> +     * disabled as well.
>>> +     */
>>> +    if ( cpu_has_vmx )
>>> +        start_nested_vmx(&hvm_funcs);
>>> +    else if ( cpu_has_svm )
>>> +        start_nested_svm(&hvm_funcs);
>>
>> Instead of passing the pointer, couldn't you have the functions return
>> bool, and then set hvm_funcs.caps.nested_virt from that? Passing that
>> pointer looks somewhat odd to me.
> 
> For one, it makes start_nested_XXX symmetric to start_XXX, which also
> has access to the full hvm_funcs structure (albeit in the former case
> because it's creating the structure).

This last aspect is the crucial aspect: start{svm,vmx}() are indeed quite
special because of this. Everywhere else we have accessor helpers when
hvm_funcs needs consulting, e.g. ...

>  For two, both of them need to read caps.hap.

... caps _reads_ would want using (an) accessor(s), too.

>  For three, it's just more flexible -- there may be
> future things that we want to modify in the start_nested_*()
> functions.  If we did as you suggest, and then added (say)
> caps.nested_virt_needs_hap, then we'd either need to add a second
> function, or refactor it to look like this.

Right, I can see this as an argument when taking, as you do, speculation
on future needs into account. Albeit I'm then inclined to say that even
such modifications may better be done through accessor helpers.

>> Is there a reason to use direct calls here rather than a true hook
>> (seeing that hvm_funcs must have been populated by the time we make it
>> here)? I understand we're (remotely) considering to switch away from
>> using hooks at some point, but right now this feels somewhat
>> inconsistent if not further justified.
> 
> Again it mimics the calls to start_vmx/svm in hvm_enable.  But I could
> look at adding a function pointer to see if it works.

Andrew - do you have any input here towards those somewhat vague plans
of getting rid of the hook functions? I guess they're more relevant in
places where we can't easily use the altcall machinery (i.e. not here).

Jan


From xen-devel-bounces@lists.xenproject.org Thu Mar 28 06:57:25 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 06:57:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698810.1090974 (Exim 4.92)
	(envelope-from )
	id 1rpjhQ-000441-3F; Thu, 28 Mar 2024 06:57:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698810.1090974; Thu, 28 Mar 2024 06:57:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpjhQ-00043t-0U; Thu, 28 Mar 2024 06:57:20 +0000
Received: by outflank-mailman (input) for mailman id 698810;
 Thu, 28 Mar 2024 06:57:18 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpjhO-00043j-7w
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 06:57:18 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on20601.outbound.protection.outlook.com
 [2a01:111:f403:2418::601])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6886fe26-ecd0-11ee-a1ef-f123f15fe8a2;
 Thu, 28 Mar 2024 07:57:15 +0100 (CET)
Received: from BN7PR02CA0008.namprd02.prod.outlook.com (2603:10b6:408:20::21)
 by PH7PR12MB5925.namprd12.prod.outlook.com (2603:10b6:510:1d8::10)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.31; Thu, 28 Mar
 2024 06:57:11 +0000
Received: from BN2PEPF000044A5.namprd04.prod.outlook.com
 (2603:10b6:408:20:cafe::6e) by BN7PR02CA0008.outlook.office365.com
 (2603:10b6:408:20::21) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.13 via Frontend
 Transport; Thu, 28 Mar 2024 06:57:11 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN2PEPF000044A5.mail.protection.outlook.com (10.167.243.104) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Thu, 28 Mar 2024 06:57:10 +0000
Received: from cjq-desktop.amd.com (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 28 Mar
 2024 01:57:06 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6886fe26-ecd0-11ee-a1ef-f123f15fe8a2
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=AtZFt0IxYHgItse27FCHsFxRIIGThckNW7utmemJ4fqYk0FZHDrvEw6wADCXB+uPSp2zUKa6tbfDA5Rl25TF25UqhBePrNJrSnGuXATsHUKYr1vddifO7TBZciPwLrrQNCmv7rh1dKm7x/EI+CGZ9tfeSogFYzHNmFO/g8pTkF4JX+MvKUjVML+lOkGaf42mx4BwiU3b93im6mzzP5vum7D4gJigBfSMLGCJ3q6UatGHOyFDVc2ZsUTPlTJiIOjc2CFzmg7mX5IttXg5cjZXYBocIt0MMjao8UivulNSxQa85AEGiu0Do5hx/jvhKLjPPWa8D33pYhbKFtXUSFvMVw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=273GWbU6VWbGodhCopaUDbY7XBraT91TwLrR/sYxOpM=;
 b=by+oFFmFBxCjbiNn9GNW9vfLT4aJfncdRA0Q06x2wD1Eq7Nn8L0lANR+OW5/3KnsAQUxrUL+gPMiHVdxdIVUtctDfJX6flLtCshmgCDStdx+pbpMg8LcnMX2pwInJUazpyslT7fTAhW3Y4/r3VXQ086MDwIirQp8BU+J6y8JkfrO/TBDDqSzWbB6NpHu51IRpREC3XEd5rWhTVNrvhsES8J7jwMKLYwE0S66R3N1dPMEEzifn/5OuvCQfsxHwZiSMdVQMSxDWvg1K5mRxRVBd274NSGK5lY9V8R4fb+X9iYyKLK8isMvXpf0ughgpHfeE0BLofPc0coAUYiqI9T40A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=273GWbU6VWbGodhCopaUDbY7XBraT91TwLrR/sYxOpM=;
 b=D6i/RBwilg2pSxSu0PWifsO9uzeaf7yoLE+yyQDYENktQ9odPH+q7AvabJK9MAvTYfJUScbPgX2ajDfAXOlNp44eU2YbQHyKnIawVOzgRi52+W5+nfXVV1QH5hcKn/kg3cLEWHZrBshfGGxyrvvFDAWw176nv1mCXuFLxgvLTjg=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Jiqian Chen 
To: Juergen Gross , Stefano Stabellini
	, Oleksandr Tyshchenko
	, Boris Ostrovsky
	, Bjorn Helgaas , "Rafael J
 . Wysocki" , Len Brown ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
CC: , ,
	, , "Stewart
 Hildebrand" , Huang Rui ,
	Jiqian Chen 
Subject: [RFC KERNEL PATCH v5 0/3] Support device passthrough when dom0 is PVH on Xen
Date: Thu, 28 Mar 2024 14:56:43 +0800
Message-ID: <20240328065646.354782-1-Jiqian.Chen@amd.com>
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN2PEPF000044A5:EE_|PH7PR12MB5925:EE_
X-MS-Office365-Filtering-Correlation-Id: 888fe74a-700a-4cea-f84c-08dc4ef44a8e
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	HgZUZST/R0HcwDjruN1lqM/2ALz1RSyEfSbVrUG4q94FbgCaKgOgYgarzAb96wtPXa60MFiGi4/t359g2IUreSrwGiGAccvQA6H7R0lTnF1B2212+H28Av0u2rak3+I1i6R+giRhIzojQ/gXqWjHy79nH9pVRidm8rf1Mha9OFe2HvF1dXmGqGSfQt0wSxacttqLliIark3rzgdqXQoXEzYqtIHMoaio5PJwskd158M6tCfV4CtizLuGsrU/MKFPQ92+rQpfevnol6TPugLviFsPnjHg31fzJ5VrKmHKkp9Wj9yhOWLZPQNWt/bQx5yCot+WZsOu1fuw4mUqznDeYcIgvDPKDYLOD/Ab+ZBgpwVSv8KQTElltbxxOprtfQNSb1kMYGmU3rZ9uieEYjrytCOEy+daTydnrDazgDFaIu2P3gPOstrOyx/eyBFpls5UnD2HE8nyiyTSe8M3zyAdPZbrYggn8Blw6/flEtLWN0ZGdaT7jJUKtI8TKJC1ZkmD3ZvYsIHlLYycVixGW9FDt9lXQBcwkMyVCFzn1hE5UOzGaK1CkAG59wnf6oJH0OLTOgx7TPV3Z10U8hxm54E1pJBZTRAvVKypxEyIT2Mh4MoBYNxAFRi83DZrb8cV0lqTHGOqE3wxGRsaZW3CHQcJwWJFbcmuY3+oE+eK2r2MR7Omhm5B5j6+xYFF6PiUlu5s/DDyM37nHg58DF14Kss1Dg==
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(82310400014)(376005)(1800799015)(7416005)(36860700004);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Mar 2024 06:57:10.9169
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 888fe74a-700a-4cea-f84c-08dc4ef44a8e
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN2PEPF000044A5.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB5925

Hi All,
This is v5 series to support passthrough on Xen when dom0 is PVH.
patch#2 change function acpi_pci_irq_lookup from a static function to non-static, need ACPI Maintainer to give some comments.
patch#3 linux internal changes, need PCI and ACPI Maintainer to give more comments.
v4->v5 changes:
* patch#1: Add Reviewed-by Stefano
* patch#2: Add Reviewed-by Stefano
* patch#3: No changes

v3->v4 changes:
* patch#1: change the comment of PHYSDEVOP_pci_device_state_reset; use a new function pcistub_reset_device_state to wrap __pci_reset_function_locked and xen_reset_device_state, and call pcistub_reset_device_state in pci_stub.c
* patch#2: remove map_pirq from xen_pvh_passthrough_gsi

v3 link:
https://lore.kernel.org/lkml/20231210161519.1550860-1-Jiqian.Chen@amd.com/T/#t
v2->v3 changes:
* patch#1: add condition to limit do xen_reset_device_state for no-pv domain in pcistub_init_device.
* patch#2: Abandoning previous implementations that call unmask_irq. To setup gsi and map pirq for passthrough device in pcistub_init_device.
* patch#3: Abandoning previous implementations that adds new syscall to get gsi from irq. To add a new sysfs for gsi, then userspace can get gsi number from sysfs.


v2 link:
https://lore.kernel.org/lkml/20231124103123.3263471-1-Jiqian.Chen@amd.com/T/#t

Below is the description of v2 cover letter:
This series of patches are the v2 of the implementation of passthrough when dom0 is PVH on Xen.
We sent the v1 to upstream before, but the v1 had so many problems and we got lots of suggestions.
I will introduce all issues that these patches try to fix and the differences between v1 and v2.

Issues we encountered:
1. pci_stub failed to write bar for a passthrough device.
Problem: when we run “sudo xl pci-assignable-add ” to assign a device, pci_stub will call “pcistub_init_device() -> pci_restore_state() -> pci_restore_config_space() ->
pci_restore_config_space_range() -> pci_restore_config_dword() -> pci_write_config_dword()”, the pci config write will trigger an io interrupt to bar_write() in the xen, but the
bar->enabled was set before, the write is not allowed now, and then when 
bar->Qemu config the
passthrough device in xen_pt_realize(), it gets invalid bar values.

Reason: the reason is that we don't tell vPCI that the device has been reset, so the current cached state in pdev->vpci is all out of date and is different from the real device state.

Solution: to solve this problem, the first patch of kernel(xen/pci: Add xen_reset_device_state
function) and the fist patch of xen(xen/vpci: Clear all vpci status of device) add a new hypercall to reset the state stored in vPCI when the state of real device has changed.
Thank Roger for the suggestion of this v2, and it is different from v1 (https://lore.kernel.org/xen-devel/20230312075455.450187-3-ray.huang@amd.com/), v1 simply allow domU to write pci bar, it does not comply with the design principles of vPCI.

2. failed to do PHYSDEVOP_map_pirq when dom0 is PVH
Problem: HVM domU will do PHYSDEVOP_map_pirq for a passthrough device by using gsi. See xen_pt_realize->xc_physdev_map_pirq and pci_add_dm_done->xc_physdev_map_pirq. Then xc_physdev_map_pirq will call into Xen, but in hvm_physdev_op(), PHYSDEVOP_map_pirq is not allowed.

Reason: In hvm_physdev_op(), the variable "currd" is PVH dom0 and PVH has no X86_EMU_USE_PIRQ flag, it will fail at has_pirq check.

Solution: I think we may need to allow PHYSDEVOP_map_pirq when "currd" is dom0 (at present dom0 is PVH). The second patch of xen(x86/pvh: Open PHYSDEVOP_map_pirq for PVH dom0) allow PVH dom0 do PHYSDEVOP_map_pirq. This v2 patch is better than v1, v1 simply remove the has_pirq check(xen https://lore.kernel.org/xen-devel/20230312075455.450187-4-ray.huang@amd.com/).

3. the gsi of a passthrough device doesn't be unmasked
 3.1 failed to check the permission of pirq
 3.2 the gsi of passthrough device was not registered in PVH dom0

Problem:
3.1 callback function pci_add_dm_done() will be called when qemu config a passthrough device for domU.
This function will call xc_domain_irq_permission()-> pirq_access_permitted() to check if the gsi has corresponding mappings in dom0. But it didn’t, so failed. See XEN_DOMCTL_irq_permission->pirq_access_permitted, "current" is PVH dom0 and it return irq is 0.
3.2 it's possible for a gsi (iow: vIO-APIC pin) to never get registered on PVH dom0, because the devices of PVH are using MSI(-X) interrupts. However, the IO-APIC pin must be configured for it to be able to be mapped into a domU.

Reason: After searching codes, I find "map_pirq" and "register_gsi" will be done in function vioapic_write_redirent->vioapic_hwdom_map_gsi when the gsi(aka ioapic's pin) is unmasked in PVH dom0.
So the two problems can be concluded to that the gsi of a passthrough device doesn't be unmasked.

Solution: to solve these problems, the second patch of kernel(xen/pvh: Unmask irq for passthrough device in PVH dom0) call the unmask_irq() when we assign a device to be passthrough. So that passthrough devices can have the mapping of gsi on PVH dom0 and gsi can be registered. This v2 patch is different from the v1( kernel https://lore.kernel.org/xen-devel/20230312120157.452859-5-ray.huang@amd.com/,
kernel https://lore.kernel.org/xen-devel/20230312120157.452859-5-ray.huang@amd.com/ and xen https://lore.kernel.org/xen-devel/20230312075455.450187-5-ray.huang@amd.com/),
v1 performed "map_pirq" and "register_gsi" on all pci devices on PVH dom0, which is unnecessary and may cause multiple registration.

4. failed to map pirq for gsi
Problem: qemu will call xc_physdev_map_pirq() to map a passthrough device’s gsi to pirq in function xen_pt_realize(). But failed.

Reason: According to the implement of xc_physdev_map_pirq(), it needs gsi instead of irq, but qemu pass irq to it and treat irq as gsi, it is got from file /sys/bus/pci/devices/xxxx:xx:xx.x/irq in function xen_host_pci_device_get(). But actually the gsi number is not equal with irq. On PVH dom0, when it allocates irq for a gsi in function acpi_register_gsi_ioapic(), allocation is dynamic, and follow the principle of applying first, distributing first. And if you debug the kernel codes(see function __irq_alloc_descs), you will find the irq number is allocated from small to large by order, but the applying gsi number is not, gsi 38 may come before gsi 28, that causes gsi 38 get a smaller irq number than gsi 28, and then gsi != irq.

Solution: we can record the relation between gsi and irq, then when userspace(qemu) want to use gsi, we can do a translation. The third patch of kernel(xen/privcmd: Add new syscall to get gsi from irq) records all the relations in acpi_register_gsi_xen_pvh() when dom0 initialize pci devices, and provide a syscall for userspace to get the gsi from irq. The third patch of xen(tools: Add new function to get gsi from irq) add a new function xc_physdev_gsi_from_irq() to call the new syscall added on kernel side.
And then userspace can use that function to get gsi. Then xc_physdev_map_pirq() will success. This v2 patch is the same as v1( kernel https://lore.kernel.org/xen-devel/20230312120157.452859-6-ray.huang@amd.com/ and xen https://lore.kernel.org/xen-devel/20230312075455.450187-6-ray.huang@amd.com/)

About the v2 patch of qemu, just change an included head file, other are similar to the v1 ( qemu https://lore.kernel.org/xen-devel/20230312092244.451465-19-ray.huang@amd.com/), just call
xc_physdev_gsi_from_irq() to get gsi from irq.


Jiqian Chen (3):
  xen/pci: Add xen_reset_device_state function
  xen/pvh: Setup gsi for passthrough device
  PCI/sysfs: Add gsi sysfs for pci_dev

 arch/x86/xen/enlighten_pvh.c       | 92 ++++++++++++++++++++++++++++++
 drivers/acpi/pci_irq.c             |  3 +-
 drivers/pci/pci-sysfs.c            | 11 ++++
 drivers/xen/pci.c                  | 12 ++++
 drivers/xen/xen-pciback/pci_stub.c | 26 ++++++++-
 include/linux/acpi.h               |  1 +
 include/linux/pci.h                |  2 +
 include/xen/acpi.h                 |  6 ++
 include/xen/interface/physdev.h    |  7 +++
 include/xen/pci.h                  |  6 ++
 10 files changed, 162 insertions(+), 4 deletions(-)

-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Thu Mar 28 06:57:25 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 06:57:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698811.1090984 (Exim 4.92)
	(envelope-from )
	id 1rpjhR-0004IA-9R; Thu, 28 Mar 2024 06:57:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698811.1090984; Thu, 28 Mar 2024 06:57:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpjhR-0004I3-6j; Thu, 28 Mar 2024 06:57:21 +0000
Received: by outflank-mailman (input) for mailman id 698811;
 Thu, 28 Mar 2024 06:57:19 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpjhP-00043j-Rr
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 06:57:19 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on20601.outbound.protection.outlook.com
 [2a01:111:f403:2415::601])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 69fd1897-ecd0-11ee-a1ef-f123f15fe8a2;
 Thu, 28 Mar 2024 07:57:18 +0100 (CET)
Received: from BN7PR02CA0029.namprd02.prod.outlook.com (2603:10b6:408:20::42)
 by DM4PR12MB7669.namprd12.prod.outlook.com (2603:10b6:8:106::22) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.32; Thu, 28 Mar
 2024 06:57:15 +0000
Received: from BN2PEPF000044A5.namprd04.prod.outlook.com
 (2603:10b6:408:20:cafe::d0) by BN7PR02CA0029.outlook.office365.com
 (2603:10b6:408:20::42) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.13 via Frontend
 Transport; Thu, 28 Mar 2024 06:57:15 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN2PEPF000044A5.mail.protection.outlook.com (10.167.243.104) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Thu, 28 Mar 2024 06:57:14 +0000
Received: from cjq-desktop.amd.com (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 28 Mar
 2024 01:57:10 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 69fd1897-ecd0-11ee-a1ef-f123f15fe8a2
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=SZqJEF12YSGNPhPTdtsktEbcn0fCGumDIYf8qWCsFbk2lVZBoKG6P5Iq/sDs/S6auukivH0me0hSGjNOfFET+VRvIgAfQLNkYNIfRdAcKNGsjLDIeq2n+00Lkc/WfZVqJM9L6+RfFBvIXpllZVkGO78NIXPY5Qk7RYCDM6JFqF6G5nRWSVFaAKPoHts0Ol0bu/KXz4RlD4bdPoY8Tmfm+lGKqPZk3tAncdT0Xj4hj39oIpMd6RcoQ5rU+N/sg+kJrozSId5XxLqVGzSF1qGOrnST9o3KObmqrN3lIiwSsYoz5yBii//vZjDmUMCFosjxcxrpl64cqSFNYVFKb2eXYA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=fH+U2QOk6dVHLf7A7/6oScHHVZmq0WKT97i+j9mEzp4=;
 b=g4Yjko2Rei0ICo9pfrE6x2i8Xg9hRyDnbbAImO4bKfMq8jogKkACRYvBdrj5Kho0on26QEypar3wEpOaru6FdtPJJMp3WnmUi5uBfzw254pnjrgeGj8FyvqHN/Fr9K+RZ+Jl/IY5iPN8pcFt6UlryTSrtkqH5VGw+9HbXGQQhOS7IZFAudh8ArH8/VgPc/nW2X1KANPFSy1BWu3Gm/Jv7Rn9UfK35jUbD6/egKHpjBSEWw0Mxc7mQxiX39T/bw8TNuT/7MCcvBCp7gidvvD8TmYrBGrAEn7dUfhhL4RZzW3lKwipzWomsq3PjuEIEeCjRDpWRnxumlDx5p1rRk04gw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=fH+U2QOk6dVHLf7A7/6oScHHVZmq0WKT97i+j9mEzp4=;
 b=oILaf8YuJo+OBHLhRTY8c+P6HLOaVF+jMcuvcv8Jh47++VGLwOSBZRaDkKUSOd1GCaoBJxBjvi6WSw8ZRAwNEstorSbw04bLeZoYaFCVG7M9pFkNhtjbeAtvgtyKWGwcM21TmvMvmQSLLVM2MvRLeVkuC7HUW/dHMwmjNKCkkHE=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Jiqian Chen 
To: Juergen Gross , Stefano Stabellini
	, Oleksandr Tyshchenko
	, Boris Ostrovsky
	, Bjorn Helgaas , "Rafael J
 . Wysocki" , Len Brown ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
CC: , ,
	, , "Stewart
 Hildebrand" , Huang Rui ,
	Jiqian Chen , Huang Rui 
Subject: [KERNEL PATCH v5 1/3] xen/pci: Add xen_reset_device_state function
Date: Thu, 28 Mar 2024 14:56:44 +0800
Message-ID: <20240328065646.354782-2-Jiqian.Chen@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20240328065646.354782-1-Jiqian.Chen@amd.com>
References: <20240328065646.354782-1-Jiqian.Chen@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN2PEPF000044A5:EE_|DM4PR12MB7669:EE_
X-MS-Office365-Filtering-Correlation-Id: 88a12641-e429-4b26-b4ad-08dc4ef44cf3
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	kAynio0RnoN8y9TM1dNjbKS/YUPUAbJ5U1knNQq2Xc4qU50I2YKZQGIcC1fnzRDE+kNE4cJnW/27+K+iCyk8un8vS7VyWJ6BLLwlYIHTpr6W4AAU8nJJZmxqqPUOVFPi6V0M6WXljVulmlzfkU7tNElgUuiYN3a+fwchHdpf/Uz6UTVIe5ZqzUfu46qwXTFUSONkGgYlaYd1VkIWprLpdKNT9iRDDn4qXMW+kMLsnClNiQmmh601Dr195gCMN3ib8ZzNbE8bu0VVxjFpnZ86iwNnJR35p+3nR5bJfUgy+o8wM9W9poPRotAw7Iv0RNH6vVLhnPVdyTlwCPt+0WLJmy7CEMns+Bndtva37Jp+NC13d0rvVNBhPg35XW8AZOr8DSNVq1k7I++9DuK166lMIlKAYcq1JZBSdUl3aNyz6d8MrlzJwRiX77eDn3vXHnnOMLm7b6+8d1HbAftA4xs28dEQ7sWdxXvsPsBdifGG+Y1od5uXX/bQV/ZnWz3064UBXgh3y0yVqQnxWgFQEhc+HXHygp3naYUpWmG4KuNQdJauDLXYKrh7KIK2yu6ilYJMSoypPUXNAjYtBOsfOW7QFI1/Jb6HNKA9YyvLOkwhUFPUrd/dUymZ9qKnNwVWO+o93+J4kkM/5lhiKn/T0mRi2QUVKq3gzHY8aynTwrBkGu/Lgw+o/S9aiSBywxGjRKh4vH0V45bFbbUEj5MEkZ6mUGfdIC2b+QwpjWMeyS1W9khTKVpPhQZxiLGQ6yrmfRKW
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(1800799015)(7416005)(376005)(82310400014)(36860700004);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Mar 2024 06:57:14.9482
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 88a12641-e429-4b26-b4ad-08dc4ef44cf3
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN2PEPF000044A5.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB7669

When device on dom0 side has been reset, the vpci on Xen side
won't get notification, so that the cached state in vpci is
all out of date with the real device state.
To solve that problem, add a new function to clear all vpci
device state when device is reset on dom0 side.

And call that function in pcistub_init_device. Because when
using "pci-assignable-add" to assign a passthrough device in
Xen, it will reset passthrough device and the vpci state will
out of date, and then device will fail to restore bar state.

Co-developed-by: Huang Rui 
Signed-off-by: Jiqian Chen 
Reviewed-by: Stefano Stabellini 
---
 drivers/xen/pci.c                  | 12 ++++++++++++
 drivers/xen/xen-pciback/pci_stub.c | 18 +++++++++++++++---
 include/xen/interface/physdev.h    |  7 +++++++
 include/xen/pci.h                  |  6 ++++++
 4 files changed, 40 insertions(+), 3 deletions(-)

diff --git a/drivers/xen/pci.c b/drivers/xen/pci.c
index 72d4e3f193af..e9b30bc09139 100644
--- a/drivers/xen/pci.c
+++ b/drivers/xen/pci.c
@@ -177,6 +177,18 @@ static int xen_remove_device(struct device *dev)
 	return r;
 }
 
+int xen_reset_device_state(const struct pci_dev *dev)
+{
+	struct physdev_pci_device device = {
+		.seg = pci_domain_nr(dev->bus),
+		.bus = dev->bus->number,
+		.devfn = dev->devfn
+	};
+
+	return HYPERVISOR_physdev_op(PHYSDEVOP_pci_device_state_reset, &device);
+}
+EXPORT_SYMBOL_GPL(xen_reset_device_state);
+
 static int xen_pci_notifier(struct notifier_block *nb,
 			    unsigned long action, void *data)
 {
diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c
index e34b623e4b41..46c40ec8a18e 100644
--- a/drivers/xen/xen-pciback/pci_stub.c
+++ b/drivers/xen/xen-pciback/pci_stub.c
@@ -89,6 +89,16 @@ static struct pcistub_device *pcistub_device_alloc(struct pci_dev *dev)
 	return psdev;
 }
 
+static int pcistub_reset_device_state(struct pci_dev *dev)
+{
+	__pci_reset_function_locked(dev);
+
+	if (!xen_pv_domain())
+		return xen_reset_device_state(dev);
+	else
+		return 0;
+}
+
 /* Don't call this directly as it's called by pcistub_device_put */
 static void pcistub_device_release(struct kref *kref)
 {
@@ -107,7 +117,7 @@ static void pcistub_device_release(struct kref *kref)
 	/* Call the reset function which does not take lock as this
 	 * is called from "unbind" which takes a device_lock mutex.
 	 */
-	__pci_reset_function_locked(dev);
+	pcistub_reset_device_state(dev);
 	if (dev_data &&
 	    pci_load_and_free_saved_state(dev, &dev_data->pci_saved_state))
 		dev_info(&dev->dev, "Could not reload PCI state\n");
@@ -284,7 +294,7 @@ void pcistub_put_pci_dev(struct pci_dev *dev)
 	 * (so it's ready for the next domain)
 	 */
 	device_lock_assert(&dev->dev);
-	__pci_reset_function_locked(dev);
+	pcistub_reset_device_state(dev);
 
 	dev_data = pci_get_drvdata(dev);
 	ret = pci_load_saved_state(dev, dev_data->pci_saved_state);
@@ -420,7 +430,9 @@ static int pcistub_init_device(struct pci_dev *dev)
 		dev_err(&dev->dev, "Could not store PCI conf saved state!\n");
 	else {
 		dev_dbg(&dev->dev, "resetting (FLR, D3, etc) the device\n");
-		__pci_reset_function_locked(dev);
+		err = pcistub_reset_device_state(dev);
+		if (err)
+			goto config_release;
 		pci_restore_state(dev);
 	}
 	/* Now disable the device (this also ensures some private device
diff --git a/include/xen/interface/physdev.h b/include/xen/interface/physdev.h
index a237af867873..8609770e28f5 100644
--- a/include/xen/interface/physdev.h
+++ b/include/xen/interface/physdev.h
@@ -256,6 +256,13 @@ struct physdev_pci_device_add {
  */
 #define PHYSDEVOP_prepare_msix          30
 #define PHYSDEVOP_release_msix          31
+/*
+ * Notify the hypervisor that a PCI device has been reset, so that any
+ * internally cached state is regenerated.  Should be called after any
+ * device reset performed by the hardware domain.
+ */
+#define PHYSDEVOP_pci_device_state_reset     32
+
 struct physdev_pci_device {
     /* IN */
     uint16_t seg;
diff --git a/include/xen/pci.h b/include/xen/pci.h
index b8337cf85fd1..b2e2e856efd6 100644
--- a/include/xen/pci.h
+++ b/include/xen/pci.h
@@ -4,10 +4,16 @@
 #define __XEN_PCI_H__
 
 #if defined(CONFIG_XEN_DOM0)
+int xen_reset_device_state(const struct pci_dev *dev);
 int xen_find_device_domain_owner(struct pci_dev *dev);
 int xen_register_device_domain_owner(struct pci_dev *dev, uint16_t domain);
 int xen_unregister_device_domain_owner(struct pci_dev *dev);
 #else
+static inline int xen_reset_device_state(const struct pci_dev *dev)
+{
+	return -1;
+}
+
 static inline int xen_find_device_domain_owner(struct pci_dev *dev)
 {
 	return -1;
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Thu Mar 28 06:57:26 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 06:57:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698812.1090993 (Exim 4.92)
	(envelope-from )
	id 1rpjhW-0004Zl-KD; Thu, 28 Mar 2024 06:57:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698812.1090993; Thu, 28 Mar 2024 06:57:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpjhW-0004Za-HW; Thu, 28 Mar 2024 06:57:26 +0000
Received: by outflank-mailman (input) for mailman id 698812;
 Thu, 28 Mar 2024 06:57:26 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpjhW-0004Yt-5H
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 06:57:26 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on20609.outbound.protection.outlook.com
 [2a01:111:f400:7e88::609])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6deefd23-ecd0-11ee-afe3-a90da7624cb6;
 Thu, 28 Mar 2024 07:57:24 +0100 (CET)
Received: from BN0PR04CA0205.namprd04.prod.outlook.com (2603:10b6:408:e9::30)
 by MN0PR12MB6247.namprd12.prod.outlook.com (2603:10b6:208:3c1::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.32; Thu, 28 Mar
 2024 06:57:19 +0000
Received: from BN2PEPF000044A8.namprd04.prod.outlook.com
 (2603:10b6:408:e9:cafe::b1) by BN0PR04CA0205.outlook.office365.com
 (2603:10b6:408:e9::30) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.13 via Frontend
 Transport; Thu, 28 Mar 2024 06:57:19 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN2PEPF000044A8.mail.protection.outlook.com (10.167.243.102) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Thu, 28 Mar 2024 06:57:19 +0000
Received: from cjq-desktop.amd.com (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 28 Mar
 2024 01:57:14 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6deefd23-ecd0-11ee-afe3-a90da7624cb6
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=ax6Xo9lg4zxOhudV7/wVGW/5h34WRwlgwn2YuGYMWphY5aANHKAB2QUvVbuqdzPFat4fLqRjfa+32grrHZCu9MhLgD45wmQfVwsTY9V2jMNxr1GPLiJse1n3KqUvOga8ex5CEeHyanEKDdS0KBIxYfRBX5s7PJv0JkbPI4MMTeAbA1UsQSiibasyRd4KqqUarde5bD/uxUdJH0GK4cKATebIFFtSF//a+fiXBwLdKwYnW8Kpp4V85mVshQIVJJXUDQYIbdQ4B6wVhN4NDohTQemAxbwHqaNBxtzrERVDWBole5CudMhjDNZ9PSqKTrM1h0OC0gNBVYJVHxBID3PG/Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=aI6059EuBtnjnSbkyQUjuatDap0hc10owbqletZh68g=;
 b=ChUkXexTLQh27/sgEPpxPj24o2LDRQGXq7qlhKUgzVTmmgf4wyxKGHRjiIJNqaFkwKrEfBnmVo5UGj6Y2YB8qw4BnmF+2bKVIKON2+ve683FVKF36Ls2OHQlsMFP9H0D8/mV53PuBuzTB3xiwWg+umRelb57YhSvaz2OClQYfV1LMzyOXqrVPEgoIrTMJU5ozz0iG+mNM33oFUdL560WEjCkAswqcpkN9pn3pVp9HiadMG3vAcTmqEKBADq6qHMjMyJsaGpgsRbbAUmYGkkt4SYVSQcezWwZqLDNnVN3qT0BxyDSAS454k9PcTtHItqpTLi/d3mYX3TenxMPBbBVBg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=aI6059EuBtnjnSbkyQUjuatDap0hc10owbqletZh68g=;
 b=JSEKJaWxOrkJCQPMQIKTjVJWA813vQSkA3t4p6+Z6cJUuqCzPCi3HAkmFhobAQS744WoVWpQqQatsX8bI1WEwuwvzAMI/Bm3XsOxdENbSvHzup7/WbKY3uLihRMGz8INz8rReur9ZHy6Oy8Y8/dw+E+MKWIoO1JSQM1cqwIjUZ8=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Jiqian Chen 
To: Juergen Gross , Stefano Stabellini
	, Oleksandr Tyshchenko
	, Boris Ostrovsky
	, Bjorn Helgaas , "Rafael J
 . Wysocki" , Len Brown ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
CC: , ,
	, , "Stewart
 Hildebrand" , Huang Rui ,
	Jiqian Chen , Huang Rui 
Subject: [RFC KERNEL PATCH v5 2/3] xen/pvh: Setup gsi for passthrough device
Date: Thu, 28 Mar 2024 14:56:45 +0800
Message-ID: <20240328065646.354782-3-Jiqian.Chen@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20240328065646.354782-1-Jiqian.Chen@amd.com>
References: <20240328065646.354782-1-Jiqian.Chen@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN2PEPF000044A8:EE_|MN0PR12MB6247:EE_
X-MS-Office365-Filtering-Correlation-Id: c639cee9-d75b-4499-1224-08dc4ef44f98
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	adLYiY1ODi5YdjheWVf9BtXB1KUrMl3MOdMqHMgvCJImGi+5/vyJb4i3cqxn43mrabUdruT41nJ9sTSGkt8tykHUfGM/T2ob7s4hlfZcO+2tgYQHe7b9MAqED+P2rAsiAs9tFuFcdI0gP+mhawVksqCrQDxPCF061WXD/eJ5xykNvNAz2rVMCtxo6gwA2JGiF0ELk2Nuk8tINOdbikQJ7zK4GXWlxJkYO7euyEUWh+0ZY2C05jdgKZ4wuZde+9Sy8Wnbxi64rWgUjq1mXLnWTS5uuiiK9eXOLK6qNzf8CuuwYOFlMvGkzWm5ymsBh+sk8MpAZdymsL4KnDhm5Rc0QftT/kBD2rUtnzuPtj8EMJ4ErAi8zXZrJ7auSrRkEBb5hqoRE5NqLHsibAOhrsa+m1cZ07ZHCPVII7OjlV8kVU6p2eBo7EZ7jpxSB+yV49rBBQZjbyEuvaeE0X5yNNFvJkplvJAgIt8jPxLfNgdBb3I+a7l2eQXGvzdCxjXKB99qkXEGGFdbX0Xw1j01D3jkzu9ObTtgTcCrgE7FIzfHoh9adVN1yIinOB3xEC27gQVlZkfwsNcx4KjIX2jQb0pClI8kSxa+JzYtHe1Jz7uHAPZYzNvrbCzL5Hr4aOXSkhUyol5M9gT5MfKZ+p31wmSQA9HzuMSZb5SkGAjhodukNE8okLKeEeMJLXoMJDWY8taBBl1xZBHRM3aGVu/DE9VyyGMKzDUZG09vBp6lh2nc30HNqImiLqkp3MekvHvUeF36
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(1800799015)(376005)(82310400014)(7416005)(36860700004);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Mar 2024 06:57:19.3808
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c639cee9-d75b-4499-1224-08dc4ef44f98
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN2PEPF000044A8.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB6247

In PVH dom0, the gsis don't get registered, but the gsi of
a passthrough device must be configured for it to be able to be
mapped into a domU.

When assign a device to passthrough, proactively setup the gsi
of the device during that process.

Co-developed-by: Huang Rui 
Signed-off-by: Jiqian Chen 
Reviewed-by: Stefano Stabellini 
---
RFC: This patch change function acpi_pci_irq_lookup from a static function to non-static, need ACPI Maintainer to give some comments.

---
 arch/x86/xen/enlighten_pvh.c       | 92 ++++++++++++++++++++++++++++++
 drivers/acpi/pci_irq.c             |  2 +-
 drivers/xen/xen-pciback/pci_stub.c |  8 +++
 include/linux/acpi.h               |  1 +
 include/xen/acpi.h                 |  6 ++
 5 files changed, 108 insertions(+), 1 deletion(-)

diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c
index c28f073c1df5..12be665b27d8 100644
--- a/arch/x86/xen/enlighten_pvh.c
+++ b/arch/x86/xen/enlighten_pvh.c
@@ -2,6 +2,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -26,6 +27,97 @@
 bool __ro_after_init xen_pvh;
 EXPORT_SYMBOL_GPL(xen_pvh);
 
+typedef struct gsi_info {
+	int gsi;
+	int trigger;
+	int polarity;
+} gsi_info_t;
+
+struct acpi_prt_entry {
+	struct acpi_pci_id	id;
+	u8			pin;
+	acpi_handle		link;
+	u32			index;		/* GSI, or link _CRS index */
+};
+
+static int xen_pvh_get_gsi_info(struct pci_dev *dev,
+								gsi_info_t *gsi_info)
+{
+	int gsi;
+	u8 pin;
+	struct acpi_prt_entry *entry;
+	int trigger = ACPI_LEVEL_SENSITIVE;
+	int polarity = acpi_irq_model == ACPI_IRQ_MODEL_GIC ?
+				      ACPI_ACTIVE_HIGH : ACPI_ACTIVE_LOW;
+
+	if (!dev || !gsi_info)
+		return -EINVAL;
+
+	pin = dev->pin;
+	if (!pin)
+		return -EINVAL;
+
+	entry = acpi_pci_irq_lookup(dev, pin);
+	if (entry) {
+		if (entry->link)
+			gsi = acpi_pci_link_allocate_irq(entry->link,
+							 entry->index,
+							 &trigger, &polarity,
+							 NULL);
+		else
+			gsi = entry->index;
+	} else
+		gsi = -1;
+
+	if (gsi < 0)
+		return -EINVAL;
+
+	gsi_info->gsi = gsi;
+	gsi_info->trigger = trigger;
+	gsi_info->polarity = polarity;
+
+	return 0;
+}
+
+static int xen_pvh_setup_gsi(gsi_info_t *gsi_info)
+{
+	struct physdev_setup_gsi setup_gsi;
+
+	if (!gsi_info)
+		return -EINVAL;
+
+	setup_gsi.gsi = gsi_info->gsi;
+	setup_gsi.triggering = (gsi_info->trigger == ACPI_EDGE_SENSITIVE ? 0 : 1);
+	setup_gsi.polarity = (gsi_info->polarity == ACPI_ACTIVE_HIGH ? 0 : 1);
+
+	return HYPERVISOR_physdev_op(PHYSDEVOP_setup_gsi, &setup_gsi);
+}
+
+int xen_pvh_passthrough_gsi(struct pci_dev *dev)
+{
+	int ret;
+	gsi_info_t gsi_info;
+
+	if (!dev)
+		return -EINVAL;
+
+	ret = xen_pvh_get_gsi_info(dev, &gsi_info);
+	if (ret) {
+		xen_raw_printk("Fail to get gsi info!\n");
+		return ret;
+	}
+
+	ret = xen_pvh_setup_gsi(&gsi_info);
+	if (ret == -EEXIST) {
+		xen_raw_printk("Already setup the GSI :%d\n", gsi_info.gsi);
+		ret = 0;
+	} else if (ret)
+		xen_raw_printk("Fail to setup GSI (%d)!\n", gsi_info.gsi);
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(xen_pvh_passthrough_gsi);
+
 void __init xen_pvh_init(struct boot_params *boot_params)
 {
 	u32 msr;
diff --git a/drivers/acpi/pci_irq.c b/drivers/acpi/pci_irq.c
index ff30ceca2203..630fe0a34bc6 100644
--- a/drivers/acpi/pci_irq.c
+++ b/drivers/acpi/pci_irq.c
@@ -288,7 +288,7 @@ static int acpi_reroute_boot_interrupt(struct pci_dev *dev,
 }
 #endif /* CONFIG_X86_IO_APIC */
 
-static struct acpi_prt_entry *acpi_pci_irq_lookup(struct pci_dev *dev, int pin)
+struct acpi_prt_entry *acpi_pci_irq_lookup(struct pci_dev *dev, int pin)
 {
 	struct acpi_prt_entry *entry = NULL;
 	struct pci_dev *bridge;
diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c
index 46c40ec8a18e..22d4380d2b04 100644
--- a/drivers/xen/xen-pciback/pci_stub.c
+++ b/drivers/xen/xen-pciback/pci_stub.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -435,6 +436,13 @@ static int pcistub_init_device(struct pci_dev *dev)
 			goto config_release;
 		pci_restore_state(dev);
 	}
+
+	if (xen_initial_domain() && xen_pvh_domain()) {
+		err = xen_pvh_passthrough_gsi(dev);
+		if (err)
+			goto config_release;
+	}
+
 	/* Now disable the device (this also ensures some private device
 	 * data is setup before we export)
 	 */
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index b7165e52b3c6..08f1e316bf27 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -361,6 +361,7 @@ void acpi_unregister_gsi (u32 gsi);
 
 struct pci_dev;
 
+struct acpi_prt_entry *acpi_pci_irq_lookup(struct pci_dev *dev, int pin);
 int acpi_pci_irq_enable (struct pci_dev *dev);
 void acpi_penalize_isa_irq(int irq, int active);
 bool acpi_isa_irq_available(int irq);
diff --git a/include/xen/acpi.h b/include/xen/acpi.h
index b1e11863144d..17c4d37f1e60 100644
--- a/include/xen/acpi.h
+++ b/include/xen/acpi.h
@@ -67,10 +67,16 @@ static inline void xen_acpi_sleep_register(void)
 		acpi_suspend_lowlevel = xen_acpi_suspend_lowlevel;
 	}
 }
+int xen_pvh_passthrough_gsi(struct pci_dev *dev);
 #else
 static inline void xen_acpi_sleep_register(void)
 {
 }
+
+static inline int xen_pvh_passthrough_gsi(struct pci_dev *dev)
+{
+	return -1;
+}
 #endif
 
 #endif	/* _XEN_ACPI_H */
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Thu Mar 28 06:57:28 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 06:57:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698813.1091004 (Exim 4.92)
	(envelope-from )
	id 1rpjhY-0004qV-Rz; Thu, 28 Mar 2024 06:57:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698813.1091004; Thu, 28 Mar 2024 06:57:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpjhY-0004qM-PE; Thu, 28 Mar 2024 06:57:28 +0000
Received: by outflank-mailman (input) for mailman id 698813;
 Thu, 28 Mar 2024 06:57:27 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpjhX-0004Yt-Jj
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 06:57:27 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on20601.outbound.protection.outlook.com
 [2a01:111:f403:2417::601])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6f2f7652-ecd0-11ee-afe3-a90da7624cb6;
 Thu, 28 Mar 2024 07:57:26 +0100 (CET)
Received: from BN0PR04CA0209.namprd04.prod.outlook.com (2603:10b6:408:e9::34)
 by CY8PR12MB7491.namprd12.prod.outlook.com (2603:10b6:930:92::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.32; Thu, 28 Mar
 2024 06:57:23 +0000
Received: from BN2PEPF000044A8.namprd04.prod.outlook.com
 (2603:10b6:408:e9:cafe::89) by BN0PR04CA0209.outlook.office365.com
 (2603:10b6:408:e9::34) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.13 via Frontend
 Transport; Thu, 28 Mar 2024 06:57:23 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN2PEPF000044A8.mail.protection.outlook.com (10.167.243.102) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Thu, 28 Mar 2024 06:57:23 +0000
Received: from cjq-desktop.amd.com (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 28 Mar
 2024 01:57:19 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6f2f7652-ecd0-11ee-afe3-a90da7624cb6
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=T8ZwyuesJuJVxj7aTbKoozNC3lLg7uvihA4ORfeEgRun6YVEmCm3zTZ2/xTQBMkuKvoEBcjxBsK3dEDIZAJhsml4rWfsJQsW7MQFxK1bYgja+U4XmaVGciqCygTkr5vaUnwVp8nVgZEVa7W8zPabK/gDq3nHUIrmj7GM4euO2oE8UrsbKQ5vKkvYsz+KHFiBWI1aGEFaUfnJS18JQtMnKmZ0I75YtU2CR4ztD2xXQj38+2n/jAfDvQn4JwEaRrgfLdZMgc/j++tiLU+NgrcPyvm8L5jOkzcYDlif44w0ShQUKnRTYvgv6y46f8tSMy6A8PvbnW4ulm+gQH1to9Kpdw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Jf1xx5lV5VxtmOYsSVAPqZLI4ppEFbCrYV78JIY1Svg=;
 b=nRbk0dXJMw2/7C/g6NC8tvbDl8mcSd1/ijXJjLnAX09y/uhx3TK1/hTvkXXz4y/KEQi7s1SnFA5pvFPQGdTJ+P2VKIs2Jx3LPNdRXATkixJmCZt6XgvH3srHGe253ymFchwui3LVz5QngNP4K4XcyExA+Wv16NAd39dl1dXwETmBqEdn1blTiwP22Nl028Dobt71HRGz5NFgDr0cHEoA5OyvwKp47O72Aayr5S4dxuWIINMmFyt9B66/KbvezLTltrXAauabkfiH8N0XZ0uT33tnWAaCOghC+OLFswO5VQz5cHK+N32DwBPeDijD4SJb94jtUZw3MSVu5hLwuNoPwQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=Jf1xx5lV5VxtmOYsSVAPqZLI4ppEFbCrYV78JIY1Svg=;
 b=iwikHwlMNoNL9O5hYq9ycZC2a1D2nfU7zTXR+L7NIomMjp5arfI/e2wIShAPcRiviOZwsg0dUW+Rs7OHQvNIByOWywWQFVMnl5gvrZkreT3K5E0+ZfzHtWwl/FNbAa1lPRidayGWKaYdDgVhJUTyuvyC3q+giSRa3/4CT8KCRF4=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Jiqian Chen 
To: Juergen Gross , Stefano Stabellini
	, Oleksandr Tyshchenko
	, Boris Ostrovsky
	, Bjorn Helgaas , "Rafael J
 . Wysocki" , Len Brown ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
CC: , ,
	, , "Stewart
 Hildebrand" , Huang Rui ,
	Jiqian Chen , Huang Rui 
Subject: [RFC KERNEL PATCH v5 3/3] PCI/sysfs: Add gsi sysfs for pci_dev
Date: Thu, 28 Mar 2024 14:56:46 +0800
Message-ID: <20240328065646.354782-4-Jiqian.Chen@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20240328065646.354782-1-Jiqian.Chen@amd.com>
References: <20240328065646.354782-1-Jiqian.Chen@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN2PEPF000044A8:EE_|CY8PR12MB7491:EE_
X-MS-Office365-Filtering-Correlation-Id: c23643eb-95a2-491b-320b-08dc4ef451e0
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	ok86Jtt3hNQ0yDEtPHNYn17A7VRXH+3a0mn3RMz56+N6/DwEA3d0AHHZUgzLxuawYnjjaMzmcxaiZdNDIa3eT14qFvfdOtw+HPKhmcbQnG9IJJsNlUHYJz2G6UFU+6wTbqPH/Zoj31OZeZseSW3zKZ9Zk6aZF0eLxlIfR/Q5xnT92ozB9DS2VLsR92a59sx3rRYb86MKkZYPDs422YGJPcj6L4bbTQLLE6q9JGma8ja3DWkyYFZxx5vrvPg+f8sFnOPPk+K1wiTPa3O8MIALyvRovy0B4L5gPyUS9tEITawGOXE4lbMDOZbBLe7GFqbi+vhv5dHwVgYEcmnJLlQj/1Q78utkH+ZvYOvGZswp0O7LBCINDgtTG/mJNk6iVexnbNvybzFLeZ8dZubft42+qKSX3R1gJT6femgaa1sTFzMHo4jsjecBN7BaZL+AS9n/1lwuFoGSPsbddpFAwzh0pH3vL/GBcRdyVM2GA+xyBTRFS3SDbiz2CA7fPt2J79+vh1iucrrAIoCNY/5gSGamGZjSYyiwYlHaqTqWKL1Pi+PMM7E8bFmlHe3AiadIwQG05ii9WLkgttJHtFUU4yVAXDGOKkA1Yz/k3MGn+qJLmMLeRKa1k38Jla8WZCjPjRmbAM1rAwlbC20s5Uds+i3wqEihVFTbkCpis76qK1YWkkFzn3+uBoQyGMIkL3Ta5zZMYwEDA5UKT0Y89aWZ4BNLZhJHhcCVhes6eGOR2bSFesOxJIESgvbrH2D/WzM3vVry
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(7416005)(1800799015)(82310400014)(376005)(36860700004);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Mar 2024 06:57:23.1933
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c23643eb-95a2-491b-320b-08dc4ef451e0
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN2PEPF000044A8.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB7491

There is a need for some scenarios to use gsi sysfs.
For example, when xen passthrough a device to dumU, it will
use gsi to map pirq, but currently userspace can't get gsi
number.
So, add gsi sysfs for that and for other potential scenarios.

Co-developed-by: Huang Rui 
Signed-off-by: Jiqian Chen 
---
RFC: No feasible suggestions were obtained in the discussion of v4.
Discussions are still needed where/how to expose the gsi.
Looking forward to get more comments and suggestions from PCI/ACPI Maintainers.

---
 drivers/acpi/pci_irq.c  |  1 +
 drivers/pci/pci-sysfs.c | 11 +++++++++++
 include/linux/pci.h     |  2 ++
 3 files changed, 14 insertions(+)

diff --git a/drivers/acpi/pci_irq.c b/drivers/acpi/pci_irq.c
index 630fe0a34bc6..739a58755df2 100644
--- a/drivers/acpi/pci_irq.c
+++ b/drivers/acpi/pci_irq.c
@@ -449,6 +449,7 @@ int acpi_pci_irq_enable(struct pci_dev *dev)
 		kfree(entry);
 		return 0;
 	}
+	dev->gsi = gsi;
 
 	rc = acpi_register_gsi(&dev->dev, gsi, triggering, polarity);
 	if (rc < 0) {
diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index 2321fdfefd7d..c51df88d079e 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -71,6 +71,16 @@ static ssize_t irq_show(struct device *dev,
 }
 static DEVICE_ATTR_RO(irq);
 
+static ssize_t gsi_show(struct device *dev,
+			struct device_attribute *attr,
+			char *buf)
+{
+	struct pci_dev *pdev = to_pci_dev(dev);
+
+	return sysfs_emit(buf, "%u\n", pdev->gsi);
+}
+static DEVICE_ATTR_RO(gsi);
+
 static ssize_t broken_parity_status_show(struct device *dev,
 					 struct device_attribute *attr,
 					 char *buf)
@@ -596,6 +606,7 @@ static struct attribute *pci_dev_attrs[] = {
 	&dev_attr_revision.attr,
 	&dev_attr_class.attr,
 	&dev_attr_irq.attr,
+	&dev_attr_gsi.attr,
 	&dev_attr_local_cpus.attr,
 	&dev_attr_local_cpulist.attr,
 	&dev_attr_modalias.attr,
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 7ab0d13672da..457043cfdfce 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -529,6 +529,8 @@ struct pci_dev {
 
 	/* These methods index pci_reset_fn_methods[] */
 	u8 reset_methods[PCI_NUM_RESET_METHODS]; /* In priority order */
+
+	unsigned int	gsi;
 };
 
 static inline struct pci_dev *pci_physfn(struct pci_dev *dev)
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Thu Mar 28 09:31:38 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 09:31:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698847.1091014 (Exim 4.92)
	(envelope-from )
	id 1rpm6S-00054Y-Og; Thu, 28 Mar 2024 09:31:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698847.1091014; Thu, 28 Mar 2024 09:31:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpm6S-00054R-Lj; Thu, 28 Mar 2024 09:31:20 +0000
Received: by outflank-mailman (input) for mailman id 698847;
 Thu, 28 Mar 2024 09:31:19 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpm6R-00054K-Fu
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 09:31:19 +0000
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com
 [2a00:1450:4864:20::529])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ed8088fe-ece5-11ee-afe3-a90da7624cb6;
 Thu, 28 Mar 2024 10:31:17 +0100 (CET)
Received: by mail-ed1-x529.google.com with SMTP id
 4fb4d7f45d1cf-56bf6591865so1108604a12.0
 for ; Thu, 28 Mar 2024 02:31:17 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ef15-20020a05640228cf00b0056c1380a972sm601476edb.74.2024.03.28.02.31.16
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 28 Mar 2024 02:31:16 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ed8088fe-ece5-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711618277; x=1712223077; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=jq+PqoYN8UPKZoful/+v/XUaP4MGZA3H0thHS9iahjk=;
        b=RxFZBBWFc+3mINBVF86tchCwnLHSYUcI0nHqziPNMUOsNlyXZba9EgsTe/qgg1SIV2
         fupmre8xTTaPF8Sj+eYUxOFi3xK/eY+0UjajUicF0ouSEen7DZch8JL21casOegrj80o
         VOZmYBdu61M9tF9MbZTf6kyvJjaZrqjzXROOSsmbZBx+CwS95qx55/mZLKbCBJ7wliuD
         Kk0NUcM2laI9iBF6NuHWe7JJ3h01QAztQtN8LyGcDGK8imoHVYCSAYDD07kf+74XYQXP
         7iU7CL1YMWrJdMhk8o3yOIu5ZXJlEI/2kMqgrnJYH/kbzAa+Di04lYcp/pRcL60FG7c0
         lc4w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711618277; x=1712223077;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=jq+PqoYN8UPKZoful/+v/XUaP4MGZA3H0thHS9iahjk=;
        b=rfcKMO8ZM1psQ7fXuPeeAsbDwrEVbFM4yvstTev8k3DOZHJAuxb19bYOUSXHJAxIBG
         MVbfAndjyexsLbvt8o8PteOsqqstcIb2Yr39jcFTEMjRiFAMSsgUpq6T6QYKTGx0d8gj
         LO+By1eKjtKoEI9JlAgvBhIp85PZijn+QEZrglVsFKfynuuuQamAPuxR0Y1LYg14pWRb
         mg8YH0OrJ2pq7xOb93IwYMOzx3rjYBMtBtKeqaH/IBA+WhNbV6F11tNMNbS7gt0NjpQU
         7ZmI6UJd7tSX0HuHM35sG5Mwcwfm3EvT4nCSHmmYNb/BISxN1P+182bWVJ2HffelknA+
         7OqQ==
X-Forwarded-Encrypted: i=1; AJvYcCXkEdKx81s8GoKAAVnYewwQopGaDtaW9lfX7HIsyxgYq14cknzr/7ibrEGl30p5NiHKsj2KsxYpmOM+aVWsjYkNUI8gKi/AU7AXqHDgsfo=
X-Gm-Message-State: AOJu0YwejyqFbk1LQ+hB7vmy6iWJoNYeJlKr4hPdQDx2LMb2sOO1vLU3
	o5FaZ18bFiYCmGr0ep+R7EsZ4KZllArFjkV6l3PDqMp6iq19BJEdUAQdyCIb7g==
X-Google-Smtp-Source: AGHT+IGSjy1EWlI3uBlgjW001BPNTf0X0SvCS3RNB1Rgv9F7IcS6d+OZ++XEpXk+rD/LwNHRbmYvrw==
X-Received: by 2002:a50:9344:0:b0:56c:2785:ca34 with SMTP id n4-20020a509344000000b0056c2785ca34mr1664512eda.5.1711618276900;
        Thu, 28 Mar 2024 02:31:16 -0700 (PDT)
Message-ID: <21da34a4-d946-47d0-86a6-b184fd010c94@suse.com>
Date: Thu, 28 Mar 2024 10:31:15 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/6] tools/misc: rework xenwatchdogd signal handling
To: leigh@solinno.co.uk
Cc: andrew.cooper3@citrix.com, anthony.perard@citrix.com, slack@rabbit.lu,
 xen-devel@lists.xenproject.org
References: <55416d60-cae7-4e79-8bde-bc07ee9e3830@suse.com>
 <20240327181353.10951-1-leigh@solinno.co.uk>
 <20240327181353.10951-3-leigh@solinno.co.uk>
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240327181353.10951-3-leigh@solinno.co.uk>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 27.03.2024 19:13, leigh@solinno.co.uk wrote:
> From: Leigh Brown 
> 
> Rework xenwatchdogd signal handling to do the minimum in the signal
> handler. This is a very minor enhancement.
> ---
>  tools/misc/xenwatchdogd.c | 20 ++++++++++++--------
>  1 file changed, 12 insertions(+), 8 deletions(-)

Throughout the series Signed-off-by: are missing from both you and Leigh.
The latter you may of course add only in case of this either having been
provided earlier (and dropped for an unknown reason), or with respective
agreement.

> --- a/tools/misc/xenwatchdogd.c
> +++ b/tools/misc/xenwatchdogd.c
> @@ -9,9 +9,11 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  xc_interface *h;
> -int id = 0;
> +bool safeexit = false;
> +bool done = false;

Seeing the subsequent patch adding static, please don't introduce new
non-static items.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Mar 28 09:38:04 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 09:38:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698849.1091024 (Exim 4.92)
	(envelope-from )
	id 1rpmCt-0005hu-DA; Thu, 28 Mar 2024 09:37:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698849.1091024; Thu, 28 Mar 2024 09:37:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpmCt-0005hn-AQ; Thu, 28 Mar 2024 09:37:59 +0000
Received: by outflank-mailman (input) for mailman id 698849;
 Thu, 28 Mar 2024 09:37:58 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpmCr-0005hg-Vd
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 09:37:57 +0000
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com
 [2a00:1450:4864:20::62b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id dbab707d-ece6-11ee-afe3-a90da7624cb6;
 Thu, 28 Mar 2024 10:37:56 +0100 (CET)
Received: by mail-ej1-x62b.google.com with SMTP id
 a640c23a62f3a-a47385a4379so327688366b.0
 for ; Thu, 28 Mar 2024 02:37:57 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 bu6-20020a170907930600b00a4e26aec839sm175913ejc.197.2024.03.28.02.37.56
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 28 Mar 2024 02:37:56 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: dbab707d-ece6-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711618676; x=1712223476; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=EsPXaaPvNui/Hla/IOxxrif4btj9zIbXB9wYdj0XRII=;
        b=eWNCWEhP8s6sUwX9W0RwdvwPILrAMHeZadgMT215MPnJ22L/1X4VcGlbmbhaOBHiRw
         COofkJt30If5yJ/A6tJOeww3CBMmV0YYsDejXY/A22/gsS/rATpSze5nJKL91zcnYhOC
         9gwum1Cec1ImTAR6Ee0phdVr+zg+/Op9pbkNh7iSN5FIUZrFro2Qu6DwWqDPZeIU9hbT
         9J9Cnm5t+98REMFpbPlSdUD7NI0ZZASOFdDl315bVrkxrZTSna1k806t0tA4SnreyR43
         MnAOhs6S3y2MO+BbEE3ps4Ltu+Hcq0dfibPexGu+hNSG7S14UnJQvToegNWWAgcJ+xD1
         a6ig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711618676; x=1712223476;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=EsPXaaPvNui/Hla/IOxxrif4btj9zIbXB9wYdj0XRII=;
        b=VrqRGf+hvKOjt7obRBH57GnfjWCDPCaGwGz09paO7kdDXopgY5YiJIsQIhNc4N3P+H
         rw/XHOWPmOiCyJ84L4inP775uAz93TASlV7mWNZKDLRF3fPBYDa5DlZooXxAQstOs/e+
         dddsLJSHH6eyx7a2NFb9T05Zt+MoGApk0Fj0bYDStHFsyW6SfgVhDMdTa/Nevtmcm2fz
         pDEQZ+T+ZWStRFPC/w/ohMKZZkVUgJHdbcJ/PiMqN6eUHXayN4CVVBQpK8xQGRLMInFi
         OOa9bu8J5MXBzonMUTQrS0mTXVoShOQExYUgsqu2OJp28iEznBlbPpXvKgoXLrOv0K0r
         lQ8A==
X-Forwarded-Encrypted: i=1; AJvYcCVJhSOJtbsSjhLwWu23lfRLk1X7satu+HWUWiXTb4O7a4bjFfnvnzxDqsYQOaRnoUOJ0wgshgX228OxxKmY85XY2m1JewU4u1qFH/9O2AY=
X-Gm-Message-State: AOJu0Yx33n+S+Yzu5fgqM+H1f0GT4u+FINIY7idov1Fkyayso9fdKgkk
	KVikwl6KD/67MDo2RWzo9ssuzBRropyUsCOZpSBYOoekiVGpXNQqqbJyISgUWA==
X-Google-Smtp-Source: AGHT+IEyPiwZx5RdgDpOBoz1n4GWuuiw6Wx0omoRtVyJy6wghOVAOSyIfjVA/oJjCTEyw57OO62B9g==
X-Received: by 2002:a17:906:b1ce:b0:a4d:f681:c964 with SMTP id bv14-20020a170906b1ce00b00a4df681c964mr1557206ejb.28.1711618676485;
        Thu, 28 Mar 2024 02:37:56 -0700 (PDT)
Message-ID: 
Date: Thu, 28 Mar 2024 10:37:55 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 3/6] tools/misc: xenwatchdogd: make functions static
Content-Language: en-US
To: leigh@solinno.co.uk
Cc: andrew.cooper3@citrix.com, anthony.perard@citrix.com, slack@rabbit.lu,
 xen-devel@lists.xenproject.org
References: <55416d60-cae7-4e79-8bde-bc07ee9e3830@suse.com>
 <20240327181353.10951-1-leigh@solinno.co.uk>
 <20240327181353.10951-4-leigh@solinno.co.uk>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240327181353.10951-4-leigh@solinno.co.uk>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 27.03.2024 19:13, leigh@solinno.co.uk wrote:
> From: Leigh Brown 
> 
> Make all functions except main() static in xenwatchdogd.c.

And once at it data then too, please.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Mar 28 09:43:28 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 09:43:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698857.1091033 (Exim 4.92)
	(envelope-from )
	id 1rpmI8-0007aA-3u; Thu, 28 Mar 2024 09:43:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698857.1091033; Thu, 28 Mar 2024 09:43:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpmI8-0007a3-0v; Thu, 28 Mar 2024 09:43:24 +0000
Received: by outflank-mailman (input) for mailman id 698857;
 Thu, 28 Mar 2024 09:43:23 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpmI7-0007Zx-HZ
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 09:43:23 +0000
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com
 [2a00:1450:4864:20::62f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9894a8c7-ece7-11ee-a1ef-f123f15fe8a2;
 Thu, 28 Mar 2024 10:43:14 +0100 (CET)
Received: by mail-ej1-x62f.google.com with SMTP id
 a640c23a62f3a-a466e53f8c0so88201366b.1
 for ; Thu, 28 Mar 2024 02:43:21 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 lh23-20020a170906f8d700b00a46ab5aaffcsm542320ejb.178.2024.03.28.02.43.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 28 Mar 2024 02:43:20 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9894a8c7-ece7-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711619000; x=1712223800; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:references:cc:to
         :from:content-language:subject:user-agent:mime-version:date
         :message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=fTGIqDU1OcIE3IM7792eQ8mgZrEHRTl596q3shAwzsw=;
        b=SU1QwU9QE1ixd4Lho8otZ7zZ2qBTi9bbmGdawx3FYaebmo+pX3AorkuIZqHaMesvYP
         fQh3Ij4DleWc/EPoldEEF4zVnNLET7N/3xq4KlBgM6XRAMUHdK7eT/aKvTyuX07XoVjx
         iQLnbd9b6th6UvHtDa74iuBhcFLgVlNiKnyR+US9vWKaQM3uLXs/s4ULhEao/bgJWOwc
         crU3EB3oJCDbZM4CnTJAr1LoxqWpZfb1hGRu4qhxDNRZb/141JdFuIhlzTkbF+sLiSc+
         jtZNrKhPw3fUBJLFWaKgxqJDt+wPUNsCg/3+LI32V2OWtL40OUc7D5v4boS8hGoU3RFp
         9njQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711619000; x=1712223800;
        h=content-transfer-encoding:in-reply-to:autocrypt:references:cc:to
         :from:content-language:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=fTGIqDU1OcIE3IM7792eQ8mgZrEHRTl596q3shAwzsw=;
        b=Em+/U/sFdjEL9TwtOg5YRCgoL1Dp/2F0mtrg8xfpo5+i2IlIly26zFBVQd6nOGMry3
         ccrTORN0zNYrphNjOiQZ8CW3Jbo6qtO4hp2aKKphOAzqJf4eNU7d6IAjepGENJbjR1CD
         L4OEogrRs8VJHkPTlGq+I6Sv5otYwLsS+rDszKC62q/QYy6Xr5v4zWRUNMVxco4ylW2D
         m88xSprtZ5FiAWptb143eR80k5Hn8/7kg54S+EdX8mrJx7CBTmXCWS58aCNgw7QshbCM
         3PvdoJ3Zn3kB3uyz1PMOJtRX4gQ1dh+8+c7kJPxlFeyRnNJFO3bQlkuoHxn/JTow59+y
         EUkA==
X-Forwarded-Encrypted: i=1; AJvYcCVZVSMzXcXtAtc5tAGz3JK4q1Czht8DK03b+7GvtUSdRbC4Bu1gsVds5P3ravr7MVE3w0zIXQmJylt7lrmpDJX9i4mNCCkatdPJ14DxIOI=
X-Gm-Message-State: AOJu0YzliHOIxw6795Eh6Z48nleqyYhn7mkJY7qchSE+VOjKMraYDb0D
	RYQj0ku0G1JtBxOilBaJEhz2zIwxSUxBVv6b+Wk8gFHbGzdVf6fs3+IwyqMQ+g==
X-Google-Smtp-Source: AGHT+IF+DyI++XQt8QnHbSaPv8gYSf0zv4kJdPheyvsh69RPcTNuDLaTOJwSMIWlX7CsbWgIpbqmjQ==
X-Received: by 2002:a17:907:940a:b0:a4e:196c:bb8a with SMTP id dk10-20020a170907940a00b00a4e196cbb8amr1343930ejc.7.1711619000406;
        Thu, 28 Mar 2024 02:43:20 -0700 (PDT)
Message-ID: <72363f38-cd1b-4d7f-9b79-4d3be8e6fdf4@suse.com>
Date: Thu, 28 Mar 2024 10:43:19 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/6] tools/misc: rework xenwatchdogd signal handling
Content-Language: en-US
From: Jan Beulich 
To: leigh@solinno.co.uk
Cc: andrew.cooper3@citrix.com, anthony.perard@citrix.com, slack@rabbit.lu,
 xen-devel@lists.xenproject.org
References: <55416d60-cae7-4e79-8bde-bc07ee9e3830@suse.com>
 <20240327181353.10951-1-leigh@solinno.co.uk>
 <20240327181353.10951-3-leigh@solinno.co.uk>
 <21da34a4-d946-47d0-86a6-b184fd010c94@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <21da34a4-d946-47d0-86a6-b184fd010c94@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 28.03.2024 10:31, Jan Beulich wrote:
> On 27.03.2024 19:13, leigh@solinno.co.uk wrote:
>> From: Leigh Brown 
>>
>> Rework xenwatchdogd signal handling to do the minimum in the signal
>> handler. This is a very minor enhancement.
>> ---
>>  tools/misc/xenwatchdogd.c | 20 ++++++++++++--------
>>  1 file changed, 12 insertions(+), 8 deletions(-)
> 
> Throughout the series Signed-off-by: are missing from both you and Leigh.
> The latter you may of course add only in case of this either having been
> provided earlier (and dropped for an unknown reason), or with respective
> agreement.

Correction: I was misguided by the mention of someone else's name in the
cover letter. It's really you who is the author aiui. And it's just that
the S-o-b doesn't belong in the cover letter, but on every individual
patch.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Mar 28 09:44:11 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 09:44:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698859.1091043 (Exim 4.92)
	(envelope-from )
	id 1rpmIt-000840-DI; Thu, 28 Mar 2024 09:44:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698859.1091043; Thu, 28 Mar 2024 09:44:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpmIt-00083t-9x; Thu, 28 Mar 2024 09:44:11 +0000
Received: by outflank-mailman (input) for mailman id 698859;
 Thu, 28 Mar 2024 09:44:10 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpmIs-00083J-Ai
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 09:44:10 +0000
Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com
 [2607:f8b0:4864:20::72d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b4a037e0-ece7-11ee-a1ef-f123f15fe8a2;
 Thu, 28 Mar 2024 10:44:01 +0100 (CET)
Received: by mail-qk1-x72d.google.com with SMTP id
 af79cd13be357-781753f52afso39259385a.2
 for ; Thu, 28 Mar 2024 02:44:08 -0700 (PDT)
Received: from localhost ([85.31.135.62]) by smtp.gmail.com with ESMTPSA id
 po5-20020a05620a384500b0078a5e78f24fsm400584qkn.13.2024.03.28.02.44.05
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 28 Mar 2024 02:44:06 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b4a037e0-ece7-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1711619046; x=1712223846; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=mfP5TGclSZ1zfwo7OSFJkdtTlDlpu7pQ66cX8iHPz5E=;
        b=gZnFrH11QGH8pLdgsdbEHfl1bv/l0c/J2xFh18XP089Nn7bqAvkXYJ9pL7JH9lQ0oP
         NEYen6RcYOUc6AO6X+PcoPnY5zS5ax7Ubu9oEJaBborYfZAthxiTqBtjbyD3M/ax/tWJ
         CVUctqxKm02JmaaAlJYc6aXB31QenvybSfox0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711619046; x=1712223846;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=mfP5TGclSZ1zfwo7OSFJkdtTlDlpu7pQ66cX8iHPz5E=;
        b=ZapCaky9nOSWmtRURT4fNhgS/Ny4i+zGpNDCw2Jcta7f7oc1mydZt1PwgqPHVmzBVn
         MdWPIDaxHq7OL9BilUBsnDx+uP4880VFnMcTXGO73iLBJft+5Tx18RjzfkpKU4MoXfUm
         sDn5VzTNrZlBUL+wr5jo19ozBYBT49S05ReeLb7530j03upvKosEjG8mrl4zHOJNB0lu
         sF2IbEB5OY4bWHniaRPAl1E4tgnRZEBkAgGxOggCB8TjjavCnhGlsem+HtBnxEdqFS0i
         UyeTPHl96jxWGbfeEBdJn5QyfpwKveyYLooWvQbpu91HUizthw2R/jvRbEl8bdSIaiQ6
         W4sw==
X-Gm-Message-State: AOJu0YySBUgb3idADX2v6Vil9G7DW7yV/Pg1Pj03vOn3fSDnMpaLvL7h
	ddFgodfcrQQx2DERhTtHRWL+kJ/hp+syOqQB6ANXs8pSoJ/YB5x+C+BIiWizOtY7rTe/2CaoLgp
	C
X-Google-Smtp-Source: AGHT+IFfcqh+qPTj6+cGe5foXkQaVf7AY4+r/7lSxqzRCGqQ0dDUMIyUjN3pUlSxo+fjdbQs5vgk2A==
X-Received: by 2002:a05:620a:1aa4:b0:78a:439d:7665 with SMTP id bl36-20020a05620a1aa400b0078a439d7665mr2490546qkb.36.1711619046512;
        Thu, 28 Mar 2024 02:44:06 -0700 (PDT)
Date: Thu, 28 Mar 2024 10:44:04 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper ,
	George Dunlap ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini , Wei Liu 
Subject: Re: [PATCH v6 2/3] xen: use explicit function alignment if supported
 by compiler
Message-ID: 
References: <20240207145547.89689-1-roger.pau@citrix.com>
 <20240207145547.89689-3-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20240207145547.89689-3-roger.pau@citrix.com>

Ping?

On Wed, Feb 07, 2024 at 03:55:46PM +0100, Roger Pau Monne wrote:
> Introduce a new Kconfig check for whether the compiler supports
> -falign-functions and if supported use it to align functions to the per-arch
> selected value, just like it's done for assembly ENTRY() and FUNC() symbols.
> 
> Note that it's possible for the compiler to end up using a higher function
> alignment regardless of the passed value.  Different compilers handle the
> option differently, as clang will ignore -falign-functions value if it's
> smaller than the one that would be set by the optimization level, while gcc
> seems to always honor the function alignment passed in -falign-functions.
> 
> Signed-off-by: Roger Pau Monné 
> ---
> Changes since v5:
>  - New in this version.
> ---
>  xen/Kconfig  | 5 +++++
>  xen/Makefile | 1 +
>  2 files changed, 6 insertions(+)
> 
> diff --git a/xen/Kconfig b/xen/Kconfig
> index 1e1b041fd52f..040cba1b4b73 100644
> --- a/xen/Kconfig
> +++ b/xen/Kconfig
> @@ -41,6 +41,11 @@ config CC_SPLIT_SECTIONS
>  #
>  # Allow setting on a boolean basis, and then convert such selection to an
>  # integer for the build system and code to consume more easily.
> +#
> +# Requires clang >= 7.0.0
> +config CC_HAS_FUNCTION_ALIGNMENT
> +	def_bool $(cc-option,-falign-functions)
> +
>  config FUNCTION_ALIGNMENT_4B
>  	bool
>  config FUNCTION_ALIGNMENT_8B
> diff --git a/xen/Makefile b/xen/Makefile
> index 21832d640225..7c8249ab3a33 100644
> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -390,6 +390,7 @@ CFLAGS += -fomit-frame-pointer
>  endif
>  
>  CFLAGS-$(CONFIG_CC_SPLIT_SECTIONS) += -ffunction-sections -fdata-sections
> +CFLAGS-$(CONFIG_CC_HAS_FUNCTION_ALIGNMENT) += -falign-functions=$(CONFIG_FUNCTION_ALIGNMENT)
>  
>  CFLAGS += -nostdinc -fno-builtin -fno-common
>  CFLAGS += -Werror -Wredundant-decls -Wwrite-strings -Wno-pointer-arith
> -- 
> 2.43.0
> 


From xen-devel-bounces@lists.xenproject.org Thu Mar 28 10:25:25 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 10:25:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698867.1091054 (Exim 4.92)
	(envelope-from )
	id 1rpmwY-0005nu-At; Thu, 28 Mar 2024 10:25:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698867.1091054; Thu, 28 Mar 2024 10:25:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpmwY-0005nn-7P; Thu, 28 Mar 2024 10:25:10 +0000
Received: by outflank-mailman (input) for mailman id 698867;
 Thu, 28 Mar 2024 10:25:09 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpmwX-0005ng-5R
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 10:25:09 +0000
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com
 [2a00:1450:4864:20::634])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6e54ae1a-eced-11ee-a1ef-f123f15fe8a2;
 Thu, 28 Mar 2024 11:24:59 +0100 (CET)
Received: by mail-ej1-x634.google.com with SMTP id
 a640c23a62f3a-a46f0da1b4fso94771866b.2
 for ; Thu, 28 Mar 2024 03:25:07 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 z11-20020a170906240b00b00a46be5169f1sm579808eja.181.2024.03.28.03.25.05
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 28 Mar 2024 03:25:05 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6e54ae1a-eced-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711621506; x=1712226306; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:subject:from:user-agent:mime-version:date
         :message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=keu/BgzfN40koPXV0xhL2rcwYWv0vTaeY1B/CUGsKq0=;
        b=cNbu764rBl3eLKMUCc78Ju6LWdpmPyuEaTYM6SveohpC7vk9BQJji0tfY0toUQxf8W
         IILbg/meAanZWUfFXIh3hGdbxsxVQ/72ZmZ1lsRTueemGIEBywnwuFhDbs4SG1s37LEQ
         KO5wiZiUNMK7U9+ZH5m4lOxGO/DBEdtvAGaKOZDtj5/M/rknCBiUSiKp2xJb3xoFd+sA
         DeKTBgvmqbjNUu8MFaRdMy6kl+TJHm6jBsL5JFxGaKpyQ2bMaqyA14zYqL92Hd6IXZoM
         uuItQTBVccGRJ/8GVu3G+Ff/CaOML6dwXgUvfRqKKUnjQDoznXh30OBWSfbKQTR629a8
         yKSw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711621506; x=1712226306;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:subject:from:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=keu/BgzfN40koPXV0xhL2rcwYWv0vTaeY1B/CUGsKq0=;
        b=YVrnCaX9FjloFMIXRnsCr3UFicoCOdBhriCA7CflxRbJK1cgomcdHWcuRJLeOe+T/b
         6Zv/wnI6XBjkanNlcj3rj+LLQw+RRQXfqDPIvrHdwvgH8OhUShrKgH3KEjW6UEhNtISU
         6TYH9PMLRP7ob5YYFsWVg8DX7ntff+gMK+yVjXW9QkJmdSdJUe5mOgy2C9P9Pq+DVQv8
         K+eMAwmi3KCm+rmGCNyZlzLSUVyPCTdOu10eZsnJR0kH5+smRgDWEQxSZN0NdioQc3t7
         MYTyivNeV1AdHIc9NVTECE23kQaPxvlw0Ngfqt5WWV0ZW1KbTFKaJlKNesp9MkmTZgh7
         JCFA==
X-Gm-Message-State: AOJu0YyMM8msHmilC6Sd9AXxD9S5Db8Ze6JprYjR9iWYKXpxXppdFxHw
	lIl5d/gMAryCXF5xpUQFNSrfy/zTHuu7s0QBFpVhmYut3a1J0Z017tS6QfanC3LweXWC2KGGIM4
	=
X-Google-Smtp-Source: AGHT+IEcuSrquROV1yL7Xu7B63KfCf5l3e0wkSp7kizvf6Ja6hi7/wUkHuPbxQLT7tFaDmzZKYLjTg==
X-Received: by 2002:a17:906:692:b0:a46:a8ba:60b3 with SMTP id u18-20020a170906069200b00a46a8ba60b3mr1401008ejb.37.1711621505835;
        Thu, 28 Mar 2024 03:25:05 -0700 (PDT)
Message-ID: 
Date: Thu, 28 Mar 2024 11:25:04 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Jan Beulich 
Subject: Re: Violations of mandatory MISRA C:2012 Rule 19.1 in X86_64 build
To: Roberto Bagnara 
Cc: xen-devel@lists.xenproject.org
References: 
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 11.07.2023 18:40, Roberto Bagnara wrote:
> Mandatory Rule 19.1 (An object shall not be assigned or copied to an
> overlapping object) is directly targeted at two undefined behaviors,
> one of which is the subject of 6.5.16.1p3, namely:
> 
>    If the value being stored in an object is read from another object
>    that overlaps in any way the storage of the first object, then the
>    overlap shall be exact and the two objects shall have qualified or
>    unqualified versions of a compatible type; otherwise, the behavior
>    is undefined.

I'd like to come back to this, for two reasons:

1) In the description of -fstrict-aliasing, gcc 13.2 doc says "Even with
-fstrict-aliasing, type-punning is allowed, provided the memory is accessed
through the union type." We even build with -fno-strict-aliasing, yet
misra/rules.rst has no mention at all of type punning being permitted.

2) With us using -fno-strict-aliasing, I wonder in how far e.g. commit
7225f13aef03 ("x86: avoid Misra Rule 19.1 violations") wasn't pointless, as
imo the "compatible types" part of the C spec clause then can be treated as
irrelevant.

To me both simply mean we're relying on another compiler extension that's
not exactly spelled out as such.

Opinions?

Jan


From xen-devel-bounces@lists.xenproject.org Thu Mar 28 10:29:47 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 10:29:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698873.1091084 (Exim 4.92)
	(envelope-from )
	id 1rpn10-0007G7-5I; Thu, 28 Mar 2024 10:29:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698873.1091084; Thu, 28 Mar 2024 10:29:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpn10-0007G0-2L; Thu, 28 Mar 2024 10:29:46 +0000
Received: by outflank-mailman (input) for mailman id 698873;
 Thu, 28 Mar 2024 10:29:44 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpn0y-0006m1-Ge
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 10:29:44 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 11caa065-ecee-11ee-a1ef-f123f15fe8a2;
 Thu, 28 Mar 2024 11:29:34 +0100 (CET)
Received: from beta.bugseng.com (unknown [176.206.12.122])
 by support.bugseng.com (Postfix) with ESMTPSA id 73F9F4EE0744;
 Thu, 28 Mar 2024 11:29:40 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 11caa065-ecee-11ee-a1ef-f123f15fe8a2
From: Simone Ballarin 
To: xen-devel@lists.xenproject.org
Cc: consulting@bugseng.com,
	Simone Ballarin ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [XEN PATCH v3 2/2] MISRA C Rule 20.7 states: "The features of `' shall not be used"
Date: Thu, 28 Mar 2024 11:29:35 +0100
Message-Id: <97008d1b28eb922b3c0041830b09e827396aa0ec.1711621080.git.simone.ballarin@bugseng.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

The Xen community wants to avoid using variadic functions except for
specific circumstances where it feels appropriate by strict code review.

Functions hypercall_create_continuation and hypercall_xlat_continuation
are internal helper functions made to break long running hypercalls into
multiple calls. They take a variable number of arguments depending on the
original hypercall they are trying to continue.

Add SAF deviations for the aforementioned functions.

Signed-off-by: Simone Ballarin 

---
Changes in v3:
- rebase: change SAF-3-safe to SAF-4-safe.
Changes in v2:
- replaced "special hypercalls" with "internal helper functions".
---
 docs/misra/safe.json     | 8 ++++++++
 xen/arch/arm/domain.c    | 1 +
 xen/arch/x86/hypercall.c | 2 ++
 3 files changed, 11 insertions(+)

diff --git a/docs/misra/safe.json b/docs/misra/safe.json
index d361d0e65c..fe2bc18509 100644
--- a/docs/misra/safe.json
+++ b/docs/misra/safe.json
@@ -36,6 +36,14 @@
         },
         {
             "id": "SAF-4-safe",
+            "analyser": {
+                "eclair": "MC3R1.R17.1"
+            },
+            "name": "Rule 17.1: internal helper functions made to break long running hypercalls into multiple calls.",
+            "text": "They need to take a variable number of arguments depending on the original hypercall they are trying to continue."
+        },
+        {
+            "id": "SAF-5-safe",
             "analyser": {},
             "name": "Sentinel",
             "text": "Next ID to be used"
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index f38cb5e04c..34cbfe699a 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -382,6 +382,7 @@ unsigned long hypercall_create_continuation(
     const char *p = format;
     unsigned long arg, rc;
     unsigned int i;
+    /* SAF-4-safe allowed variadic function */
     va_list args;
 
     current->hcall_preempted = true;
diff --git a/xen/arch/x86/hypercall.c b/xen/arch/x86/hypercall.c
index 01cd73040d..133e9f221c 100644
--- a/xen/arch/x86/hypercall.c
+++ b/xen/arch/x86/hypercall.c
@@ -31,6 +31,7 @@ unsigned long hypercall_create_continuation(
     const char *p = format;
     unsigned long arg;
     unsigned int i;
+    /* SAF-4-safe allowed variadic function */
     va_list args;
 
     curr->hcall_preempted = true;
@@ -115,6 +116,7 @@ int hypercall_xlat_continuation(unsigned int *id, unsigned int nr,
     struct cpu_user_regs *regs;
     unsigned int i, cval = 0;
     unsigned long nval = 0;
+    /* SAF-4-safe allowed variadic function */
     va_list args;
 
     ASSERT(nr <= ARRAY_SIZE(mcs->call.args));
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Thu Mar 28 10:29:47 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 10:29:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698872.1091069 (Exim 4.92)
	(envelope-from )
	id 1rpn0y-0006oX-0R; Thu, 28 Mar 2024 10:29:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698872.1091069; Thu, 28 Mar 2024 10:29:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpn0x-0006nd-Sa; Thu, 28 Mar 2024 10:29:43 +0000
Received: by outflank-mailman (input) for mailman id 698872;
 Thu, 28 Mar 2024 10:29:42 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpn0w-0006lq-RE
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 10:29:42 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1599ba3e-ecee-11ee-afe3-a90da7624cb6;
 Thu, 28 Mar 2024 11:29:40 +0100 (CET)
Received: from beta.bugseng.com (unknown [176.206.12.122])
 by support.bugseng.com (Postfix) with ESMTPSA id A54C04EE0737;
 Thu, 28 Mar 2024 11:29:39 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1599ba3e-ecee-11ee-afe3-a90da7624cb6
From: Simone Ballarin 
To: xen-devel@lists.xenproject.org
Cc: consulting@bugseng.com,
	Simone Ballarin ,
	Doug Goldstein ,
	Stefano Stabellini ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [XEN PATCH v3 0/2] xen: address violations of MISRA C Rule 17.1
Date: Thu, 28 Mar 2024 11:29:33 +0100
Message-Id: 
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

MISRA C Rule 20.7 states: "The features of `' shall not be used".

The Xen community wants to avoid using variadic functions except for
specific circumstances where it feels appropriate by strict code review.

Functions hypercall_create_continuation and hypercall_xlat_continuation
are internal helpers made to break long running hypercalls into multiple
calls. They take a variable number of arguments depending on the original
hypercall they are trying to continue. Add SAF deviations for the aforementioned
functions.

Add deviation for printf()-like functions.

---
Changes in v3:
- use regexes to exempt all .*printk and .*printf functions, instead
  of manually listing them one by one;
- rebase: change SAF-3-safe in SAF-4-safe.
Changes in v2:
- replace "related to console output" with "printf()-like functions";
- replace "special hypercalls" with "internal helpers".

Simone Ballarin (2):
  MISRA C:2012 Rule 17.1 states: The features of `' shall not
    be used
  MISRA C Rule 20.7 states: "The features of `' shall not be
    used"

 automation/eclair_analysis/ECLAIR/deviations.ecl | 13 +++++++++++++
 docs/misra/deviations.rst                        |  5 +++++
 docs/misra/safe.json                             |  8 ++++++++
 xen/arch/arm/domain.c                            |  1 +
 xen/arch/x86/hypercall.c                         |  2 ++
 5 files changed, 29 insertions(+)

-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Thu Mar 28 10:29:47 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 10:29:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698871.1091063 (Exim 4.92)
	(envelope-from )
	id 1rpn0x-0006m9-Oj; Thu, 28 Mar 2024 10:29:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698871.1091063; Thu, 28 Mar 2024 10:29:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpn0x-0006m2-MA; Thu, 28 Mar 2024 10:29:43 +0000
Received: by outflank-mailman (input) for mailman id 698871;
 Thu, 28 Mar 2024 10:29:42 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpn0w-0006lq-5M
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 10:29:42 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 15acc906-ecee-11ee-afe3-a90da7624cb6;
 Thu, 28 Mar 2024 11:29:40 +0100 (CET)
Received: from beta.bugseng.com (unknown [176.206.12.122])
 by support.bugseng.com (Postfix) with ESMTPSA id 26E5B4EE073C;
 Thu, 28 Mar 2024 11:29:40 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 15acc906-ecee-11ee-afe3-a90da7624cb6
From: Simone Ballarin 
To: xen-devel@lists.xenproject.org
Cc: consulting@bugseng.com,
	Simone Ballarin ,
	Doug Goldstein ,
	Stefano Stabellini ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich ,
	Julien Grall 
Subject: [XEN PATCH v3 1/2] MISRA C:2012 Rule 17.1 states: The features of `' shall not be used
Date: Thu, 28 Mar 2024 11:29:34 +0100
Message-Id: 
X-Mailer: git-send-email 2.34.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

The Xen community wants to avoid using variadic functions except for
specific circumstances where it feels appropriate by strict code review.

Add deviation for printf()-like functions.

Signed-off-by: Simone Ballarin 

---
Changes in v3:
- use regex to exempt all .*printk and .*printf functions, instead
  of manually listing them one by one.
Changes in v2:
- replace "console output related" with "printf()-like".
---
 automation/eclair_analysis/ECLAIR/deviations.ecl | 13 +++++++++++++
 docs/misra/deviations.rst                        |  5 +++++
 2 files changed, 18 insertions(+)

diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
index de9ba723fb..936c738caf 100644
--- a/automation/eclair_analysis/ECLAIR/deviations.ecl
+++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
@@ -386,6 +386,19 @@ explicit comment indicating the fallthrough intention is present."
 -config=MC3R1.R16.6,switch_clauses+={deliberate, "default(0)"}
 -doc_end
 
+#
+# Series 17.
+#
+
+-doc_begin="printf()-like functions are allowed to use the variadic features provided by stdarg.h."
+-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(^.*printk\(.*\)$)))"}
+-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(^.*printf\(.*\)$)))"}
+-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(panic)&&kind(function))))"}
+-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(elf_call_log_callback)&&kind(function))))"}
+-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(vprintk_common)&&kind(function))))"}
+-config=MC3R1.R17.1,macros+={hide , "^va_(arg|start|copy|end)$"}
+-doc_end
+
 #
 # Series 18.
 #
diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
index eb5ef2bd9d..dd254a9640 100644
--- a/docs/misra/deviations.rst
+++ b/docs/misra/deviations.rst
@@ -334,6 +334,11 @@ Deviations related to MISRA C:2012 Rules:
        improve readability.
      - Tagged as `deliberate` for ECLAIR.
 
+   * - R17.1
+     - printf()-like functions  are allowed to use the variadic features provided
+       by `stdarg.h`.
+     - Tagged as `deliberate` for ECLAIR.
+
    * - R20.4
      - The override of the keyword \"inline\" in xen/compiler.h is present so
        that section contents checks pass when the compiler chooses not to
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Thu Mar 28 10:32:04 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 10:32:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698879.1091094 (Exim 4.92)
	(envelope-from )
	id 1rpn32-0000nc-NZ; Thu, 28 Mar 2024 10:31:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698879.1091094; Thu, 28 Mar 2024 10:31:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpn32-0000nV-JD; Thu, 28 Mar 2024 10:31:52 +0000
Received: by outflank-mailman (input) for mailman id 698879;
 Thu, 28 Mar 2024 10:31:51 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpn31-0000nN-OK
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 10:31:51 +0000
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com
 [2a00:1450:4864:20::633])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 62dbac19-ecee-11ee-afe3-a90da7624cb6;
 Thu, 28 Mar 2024 11:31:50 +0100 (CET)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-a2f22bfb4e6so104271366b.0
 for ; Thu, 28 Mar 2024 03:31:50 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ak1-20020a170906888100b00a465a012cf1sm598928ejc.18.2024.03.28.03.31.48
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 28 Mar 2024 03:31:49 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 62dbac19-ecee-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711621909; x=1712226709; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=LOW53gfE3J0/0vkEIoMTDRz8bYw/nTWL30X2lKEyJTc=;
        b=HFjXUW92Qp+Op6HCLCEr/dE4nwcyzPLDkkxI9ynAyXy1hCH64vVMpr18BW9GtfrMdS
         ZObeAVXXZJgzGJeazrTvF+hndbVavypZLx9eSCZ2M+QCfRUQxwCicdAm2qjjvNo3+07w
         X7BOk5CvKgBIaDxeJFinI/IWJQfEYK2CHKXDWNFJ/GOQnRYN5YpATS/RFsmFQ+ADP0YX
         fPUcOii/nfUweD41eZzQ7yLe7XRyH9rBQMLWi82Yi9n0v11yTvJOiRAxXzsHuAu0valR
         /JGAvdZnB6mB5PGtomlryGGkMSlTvfJ6Y7qLglAarDjw94uyb02GVZ8UKgGYnubL1RRm
         Vazw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711621909; x=1712226709;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=LOW53gfE3J0/0vkEIoMTDRz8bYw/nTWL30X2lKEyJTc=;
        b=GM1d+t9BLEfuKSmIlKGiZjuHXm21SVwMUsAq1n7O4mSsKd7sgv9JexthKQhMNVrDpK
         yzg0o1GIfi0Z1e4O1wd8OnDCO20zItjAc8yomBogI6phnfA4ez9TmKz5w/PCUjSIcLve
         d9FlrCbEy220VgxfYfeg9zWdv6OT34f1OIb7h23eKX9SGQ7R5DiGu4MJyIkNAGIla07m
         kkIQ5h2DKO8VwuaSuR70KumUTRd4S91sp2aCgggavN/bQR9XtNB2LQc2ib/Wgsvpabjk
         99oTbntyy+VJoJNUzR+rlseu0iDYyEd9hLlTGsoDc7k9V9j7jOfSbPF+aFxhhbRsOODb
         IWYg==
X-Forwarded-Encrypted: i=1; AJvYcCUxivaob0Rn8xd9drrylaecr3q7aFfMnQpfKStktJutV4S17T3OLAq19YtpUjlleln90n0JWgY2hv+rkQOcd/peit/oCYom16m6h1TmzUc=
X-Gm-Message-State: AOJu0Yy2UU6yxaKK1G3nL/KmOebHMzPxg9CrRWdGcDxbAV1oO4G2U1xm
	tG9X0j6QgnIJdAwL+bdWR/08ESrY0iLNF62aMKt269z70GiRrJwbHwkCSQ7cQQ==
X-Google-Smtp-Source: AGHT+IGoL7hzx3sDii5xVzrVhQfqMLBAtTIN778HUccwBr71cx85QRIiCo3iOEQTxjnSkvmx0KtZ/w==
X-Received: by 2002:a17:907:97c5:b0:a4d:f9af:a749 with SMTP id js5-20020a17090797c500b00a4df9afa749mr1664472ejc.34.1711621909545;
        Thu, 28 Mar 2024 03:31:49 -0700 (PDT)
Message-ID: 
Date: Thu, 28 Mar 2024 11:31:47 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH v3 2/2] MISRA C Rule 20.7 states: "The features of
 `' shall not be used"
Content-Language: en-US
To: Simone Ballarin 
Cc: consulting@bugseng.com, Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: 
 <97008d1b28eb922b3c0041830b09e827396aa0ec.1711621080.git.simone.ballarin@bugseng.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <97008d1b28eb922b3c0041830b09e827396aa0ec.1711621080.git.simone.ballarin@bugseng.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 28.03.2024 11:29, Simone Ballarin wrote:
> The Xen community wants to avoid using variadic functions except for
> specific circumstances where it feels appropriate by strict code review.

In the title, s/20.7/17.1/ I suppose?

Jan

> Functions hypercall_create_continuation and hypercall_xlat_continuation
> are internal helper functions made to break long running hypercalls into
> multiple calls. They take a variable number of arguments depending on the
> original hypercall they are trying to continue.
> 
> Add SAF deviations for the aforementioned functions.
> 
> Signed-off-by: Simone Ballarin 
> 
> ---
> Changes in v3:
> - rebase: change SAF-3-safe to SAF-4-safe.
> Changes in v2:
> - replaced "special hypercalls" with "internal helper functions".
> ---
>  docs/misra/safe.json     | 8 ++++++++
>  xen/arch/arm/domain.c    | 1 +
>  xen/arch/x86/hypercall.c | 2 ++
>  3 files changed, 11 insertions(+)
> 
> diff --git a/docs/misra/safe.json b/docs/misra/safe.json
> index d361d0e65c..fe2bc18509 100644
> --- a/docs/misra/safe.json
> +++ b/docs/misra/safe.json
> @@ -36,6 +36,14 @@
>          },
>          {
>              "id": "SAF-4-safe",
> +            "analyser": {
> +                "eclair": "MC3R1.R17.1"
> +            },
> +            "name": "Rule 17.1: internal helper functions made to break long running hypercalls into multiple calls.",
> +            "text": "They need to take a variable number of arguments depending on the original hypercall they are trying to continue."
> +        },
> +        {
> +            "id": "SAF-5-safe",
>              "analyser": {},
>              "name": "Sentinel",
>              "text": "Next ID to be used"
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index f38cb5e04c..34cbfe699a 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -382,6 +382,7 @@ unsigned long hypercall_create_continuation(
>      const char *p = format;
>      unsigned long arg, rc;
>      unsigned int i;
> +    /* SAF-4-safe allowed variadic function */
>      va_list args;
>  
>      current->hcall_preempted = true;
> diff --git a/xen/arch/x86/hypercall.c b/xen/arch/x86/hypercall.c
> index 01cd73040d..133e9f221c 100644
> --- a/xen/arch/x86/hypercall.c
> +++ b/xen/arch/x86/hypercall.c
> @@ -31,6 +31,7 @@ unsigned long hypercall_create_continuation(
>      const char *p = format;
>      unsigned long arg;
>      unsigned int i;
> +    /* SAF-4-safe allowed variadic function */
>      va_list args;
>  
>      curr->hcall_preempted = true;
> @@ -115,6 +116,7 @@ int hypercall_xlat_continuation(unsigned int *id, unsigned int nr,
>      struct cpu_user_regs *regs;
>      unsigned int i, cval = 0;
>      unsigned long nval = 0;
> +    /* SAF-4-safe allowed variadic function */
>      va_list args;
>  
>      ASSERT(nr <= ARRAY_SIZE(mcs->call.args));



From xen-devel-bounces@lists.xenproject.org Thu Mar 28 10:48:45 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 10:48:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698885.1091104 (Exim 4.92)
	(envelope-from )
	id 1rpnJI-000313-1P; Thu, 28 Mar 2024 10:48:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698885.1091104; Thu, 28 Mar 2024 10:48:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpnJH-00030w-US; Thu, 28 Mar 2024 10:48:39 +0000
Received: by outflank-mailman (input) for mailman id 698885;
 Thu, 28 Mar 2024 10:48:39 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpnJH-00030m-8v; Thu, 28 Mar 2024 10:48:39 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpnJH-0007RE-2j; Thu, 28 Mar 2024 10:48:39 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpnJG-0004tj-MM; Thu, 28 Mar 2024 10:48:38 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rpnJG-0005gV-Ln; Thu, 28 Mar 2024 10:48:38 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=2XqK1trzmG/HnSIURohlZWWO6jDPqqYkyVe8+C9J7Xo=; b=xGB5ff9g8q1SdNlkmlaKa+qQCG
	HT7f7Mk1MQbHJuFt5J2XCY5L8isqMTQmJy7MBYeuj59tfEPi0N4JPgGopZzCTc7GwArAHPCDBmhDb
	RJI6KLS+igDmffDQuDGbpk0XT104k9vsN1XdSHJhRlmyv+fFk4EEIz+3qGMBvurYolMo=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-4.17-testing test] 185171: tolerable FAIL - PUSHED
X-Osstest-Failures:
    xen-4.17-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    xen-4.17-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    xen-4.17-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    xen-4.17-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    xen-4.17-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    xen-4.17-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-xl-raw:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-xl-raw:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-xl-qcow2:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-xl-qcow2:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-libvirt-vhd:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-libvirt-vhd:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    xen=bfb69205376d94ff91b09a337c47fb665ee12da3
X-Osstest-Versions-That:
    xen=0ebd2e49bcd0f566ba6b9158555942aab8e41332
From: osstest service owner 
Date: Thu, 28 Mar 2024 10:48:38 +0000

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen                  bfb69205376d94ff91b09a337c47fb665ee12da3
baseline version:
 xen                  0ebd2e49bcd0f566ba6b9158555942aab8e41332

Last test of basis   185012  2024-03-13 00:10:35 Z   15 days
Testing same since   185171  2024-03-27 11:37:09 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Olaf Hering 

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-libvirt-qcow2                               pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-xl-qcow2                                    pass    
 test-amd64-amd64-libvirt-raw                                 pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-amd64-amd64-xl-raw                                      pass    
 test-armhf-armhf-xl-raw                                      pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-libvirt-vhd                                 pass    
 test-amd64-amd64-xl-vhd                                      pass    
 test-arm64-arm64-xl-vhd                                      pass    


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

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

Explanation of these 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
   0ebd2e49bc..bfb6920537  bfb69205376d94ff91b09a337c47fb665ee12da3 -> stable-4.17


From xen-devel-bounces@lists.xenproject.org Thu Mar 28 10:50:19 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 10:50:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698889.1091113 (Exim 4.92)
	(envelope-from )
	id 1rpnKs-0004eL-CK; Thu, 28 Mar 2024 10:50:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698889.1091113; Thu, 28 Mar 2024 10:50:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpnKs-0004eE-9h; Thu, 28 Mar 2024 10:50:18 +0000
Received: by outflank-mailman (input) for mailman id 698889;
 Thu, 28 Mar 2024 10:50:17 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpnKr-0004e8-Lz
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 10:50:17 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f66ca5dc-ecf0-11ee-afe3-a90da7624cb6;
 Thu, 28 Mar 2024 11:50:16 +0100 (CET)
Received: from [192.168.1.175] (unknown [176.206.12.122])
 by support.bugseng.com (Postfix) with ESMTPSA id EE84C4EE0737;
 Thu, 28 Mar 2024 11:50:15 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f66ca5dc-ecf0-11ee-afe3-a90da7624cb6
Message-ID: <175b2ffe-a75f-4ecd-82e6-8a130a4ec22d@bugseng.com>
Date: Thu, 28 Mar 2024 11:50:15 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH v3 2/2] MISRA C Rule 20.7 states: "The features of
 `' shall not be used"
Content-Language: en-US
To: Jan Beulich 
Cc: consulting@bugseng.com, Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: 
 <97008d1b28eb922b3c0041830b09e827396aa0ec.1711621080.git.simone.ballarin@bugseng.com>
 
From: Simone Ballarin 
Organization: BUGSENG
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 28/03/24 11:31, Jan Beulich wrote:
> On 28.03.2024 11:29, Simone Ballarin wrote:
>> The Xen community wants to avoid using variadic functions except for
>> specific circumstances where it feels appropriate by strict code review.
> 
> In the title, s/20.7/17.1/ I suppose?
> 
> Jan
> 
>> Functions hypercall_create_continuation and hypercall_xlat_continuation
>> are internal helper functions made to break long running hypercalls into
>> multiple calls. They take a variable number of arguments depending on the
>> original hypercall they are trying to continue.
>>
>> Add SAF deviations for the aforementioned functions.
>>
>> Signed-off-by: Simone Ballarin 
>>
>> ---
>> Changes in v3:
>> - rebase: change SAF-3-safe to SAF-4-safe.
>> Changes in v2:
>> - replaced "special hypercalls" with "internal helper functions".
>> ---
>>   docs/misra/safe.json     | 8 ++++++++
>>   xen/arch/arm/domain.c    | 1 +
>>   xen/arch/x86/hypercall.c | 2 ++
>>   3 files changed, 11 insertions(+)
>>
>> diff --git a/docs/misra/safe.json b/docs/misra/safe.json
>> index d361d0e65c..fe2bc18509 100644
>> --- a/docs/misra/safe.json
>> +++ b/docs/misra/safe.json
>> @@ -36,6 +36,14 @@
>>           },
>>           {
>>               "id": "SAF-4-safe",
>> +            "analyser": {
>> +                "eclair": "MC3R1.R17.1"
>> +            },
>> +            "name": "Rule 17.1: internal helper functions made to break long running hypercalls into multiple calls.",
>> +            "text": "They need to take a variable number of arguments depending on the original hypercall they are trying to continue."
>> +        },
>> +        {
>> +            "id": "SAF-5-safe",
>>               "analyser": {},
>>               "name": "Sentinel",
>>               "text": "Next ID to be used"
>> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
>> index f38cb5e04c..34cbfe699a 100644
>> --- a/xen/arch/arm/domain.c
>> +++ b/xen/arch/arm/domain.c
>> @@ -382,6 +382,7 @@ unsigned long hypercall_create_continuation(
>>       const char *p = format;
>>       unsigned long arg, rc;
>>       unsigned int i;
>> +    /* SAF-4-safe allowed variadic function */
>>       va_list args;
>>   
>>       current->hcall_preempted = true;
>> diff --git a/xen/arch/x86/hypercall.c b/xen/arch/x86/hypercall.c
>> index 01cd73040d..133e9f221c 100644
>> --- a/xen/arch/x86/hypercall.c
>> +++ b/xen/arch/x86/hypercall.c
>> @@ -31,6 +31,7 @@ unsigned long hypercall_create_continuation(
>>       const char *p = format;
>>       unsigned long arg;
>>       unsigned int i;
>> +    /* SAF-4-safe allowed variadic function */
>>       va_list args;
>>   
>>       curr->hcall_preempted = true;
>> @@ -115,6 +116,7 @@ int hypercall_xlat_continuation(unsigned int *id, unsigned int nr,
>>       struct cpu_user_regs *regs;
>>       unsigned int i, cval = 0;
>>       unsigned long nval = 0;
>> +    /* SAF-4-safe allowed variadic function */
>>       va_list args;
>>   
>>       ASSERT(nr <= ARRAY_SIZE(mcs->call.args));
> 
> 

Yes, sorry.

-- 
Simone Ballarin, M.Sc.

Field Application Engineer, BUGSENG (https://bugseng.com)



From xen-devel-bounces@lists.xenproject.org Thu Mar 28 10:57:50 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 10:57:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698898.1091139 (Exim 4.92)
	(envelope-from )
	id 1rpnS7-0005aM-CV; Thu, 28 Mar 2024 10:57:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698898.1091139; Thu, 28 Mar 2024 10:57:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpnS7-0005aF-9x; Thu, 28 Mar 2024 10:57:47 +0000
Received: by outflank-mailman (input) for mailman id 698898;
 Thu, 28 Mar 2024 10:57:45 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpnS5-0005a8-LI
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 10:57:45 +0000
Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com
 [2607:f8b0:4864:20::32a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 01128f8a-ecf2-11ee-afe3-a90da7624cb6;
 Thu, 28 Mar 2024 11:57:44 +0100 (CET)
Received: by mail-ot1-x32a.google.com with SMTP id
 46e09a7af769-6e6a9e2e2b6so424753a34.1
 for ; Thu, 28 Mar 2024 03:57:44 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 01128f8a-ecf2-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1711623463; x=1712228263; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=FhtDKIuK2M8Bo9W+lzZdZiI3O9xoxqV6+wkF/KfzFoA=;
        b=NgT8BKiUbQzKanHMu/+moj929ISUUE4D/NDMHUFH8rK0UxptkDeiV69Pm1h1wZBaut
         QtYSdz1ef+vA4Z1T13cHrjQVy3hCZAwfQmKl9YBLqZJHQhjZX32WTbJf04MkuIcEWH6i
         MZO6f+fmedqsHCt3pyiF1BPG4hEESBweTeHn8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711623463; x=1712228263;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=FhtDKIuK2M8Bo9W+lzZdZiI3O9xoxqV6+wkF/KfzFoA=;
        b=mlaqHW6xgnFm/3LJFgk83DTXxVj+0VbCsmKOjQ/8X0Te/fAYY4HFGIFqQh4Zs63vdq
         b0taUkuqqVsbrIPZuQTIaRWUFU5mm2YDLc6ZxlytG7gxoTj1J7qylNkNrJyx91IpBat8
         UPIjSnMS54z/XmL2Q5EDzGKns5j7Sj1zr5fqoPWcKttzGtYeAN6wy1WLgfuOEhjEWCGo
         3wqJow63nOyb0v4Gx/AHh+EyTJkXz7xnBIJZyHAONOmSOm+W//cszEsbUPmOc2D2ayw3
         uFs1bubTBtU23k2FKYKslE7XiciX+5I6GHNnOOUENJlJgGdHZ7KJG+GDCnxt1c6wZshS
         gaaQ==
X-Forwarded-Encrypted: i=1; AJvYcCUgJ7cwp3O5AlcwvbvOp3317ArMG61h6xr7Bjx7T+Bh084tfVEhh+xAnvGWNFarWJjshZpEb19dc1dKIpJMkzkAAng7uIUjrL0fZ4U0GAE=
X-Gm-Message-State: AOJu0Yzn0fRWiCOGdQkRpGr7eU6UY65MkC62bXz7KoPtgA5jWtgZ+ge2
	IiZBvPc21HEyX5hKCL4YJmhXngvIDMkDNXD9ccsxmPVjiTe5Dcf1S11ap3FDwLP9wohumQ7AcSW
	SiwMxjJG6AR0dXXePHp7Jnq+m+ylHJ+GcN8o1HA==
X-Google-Smtp-Source: AGHT+IFX2CPh4cCr3o9H1bDrJgbL6bJQAjkK76rczyRNo/qKvUZ7Oz2i82gtFGelIEHHFhv+sEpdNW628zrt/SJlTd8=
X-Received: by 2002:a05:6871:7813:b0:229:f31d:8c3 with SMTP id
 oy19-20020a056871781300b00229f31d08c3mr1524451oac.50.1711623463250; Thu, 28
 Mar 2024 03:57:43 -0700 (PDT)
MIME-Version: 1.0
References: <20240313122454.965566-1-george.dunlap@cloud.com>
 <20240313122454.965566-4-george.dunlap@cloud.com> <7a5b3ec3-c122-479a-b714-529e150bf4c0@suse.com>
  
In-Reply-To: 
From: George Dunlap 
Date: Thu, 28 Mar 2024 10:57:29 +0000
Message-ID: 
Subject: Re: [PATCH v2 3/3] svm/nestedsvm: Introduce nested capabilities bit
To: Jan Beulich 
Cc: Andrew Cooper , Julien Grall , 
	Stefano Stabellini , Wei Liu , 
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
	Jun Nakajima , Kevin Tian , 
	xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Mar 28, 2024 at 6:44=E2=80=AFAM Jan Beulich  wro=
te:
> > As to why to have each vendor independent code check for HAP -- there
> > are in fact two implementations of the code; it's nice to be able to
> > look in one place for each implementation to determine the
> > requirements.  Additionally, it would be possible, in the future, for
> > one of the nested virt implementations to enable shadow mode, while
> > the other one didn't.  The current arrangement makes that easy.
>
> Well, first - how likely is this, when instead we've been considering
> whether we could get rid of shadow mode? And then this is balancing
> between ease of future changes vs avoiding redundancy where it can be
> avoided. I'm not going to insist on centralizing the HAP check, but I
> certainly wanted the option to be considered.

I considered it before replying to you; so consider it considered. :-)

> >>> --- a/xen/arch/x86/hvm/nestedhvm.c
> >>> +++ b/xen/arch/x86/hvm/nestedhvm.c
> >>> @@ -150,6 +150,16 @@ static int __init cf_check nestedhvm_setup(void)
> >>>      __clear_bit(0x80, shadow_io_bitmap[0]);
> >>>      __clear_bit(0xed, shadow_io_bitmap[1]);
> >>>
> >>> +    /*
> >>> +     * NB this must be called after all command-line processing has =
been
> >>> +     * done, so that if (for example) HAP is disabled, nested virt i=
s
> >>> +     * disabled as well.
> >>> +     */
> >>> +    if ( cpu_has_vmx )
> >>> +        start_nested_vmx(&hvm_funcs);
> >>> +    else if ( cpu_has_svm )
> >>> +        start_nested_svm(&hvm_funcs);
> >>
> >> Instead of passing the pointer, couldn't you have the functions return
> >> bool, and then set hvm_funcs.caps.nested_virt from that? Passing that
> >> pointer looks somewhat odd to me.
> >
> > For one, it makes start_nested_XXX symmetric to start_XXX, which also
> > has access to the full hvm_funcs structure (albeit in the former case
> > because it's creating the structure).
>
> This last aspect is the crucial aspect: start{svm,vmx}() are indeed quite
> special because of this. Everywhere else we have accessor helpers when
> hvm_funcs needs consulting, e.g. ...
>
> >  For two, both of them need to read caps.hap.
>
> ... caps _reads_ would want using (an) accessor(s), too.
>
> >  For three, it's just more flexible -- there may be
> > future things that we want to modify in the start_nested_*()
> > functions.  If we did as you suggest, and then added (say)
> > caps.nested_virt_needs_hap, then we'd either need to add a second
> > function, or refactor it to look like this.
>
> Right, I can see this as an argument when taking, as you do, speculation
> on future needs into account. Albeit I'm then inclined to say that even
> such modifications may better be done through accessor helpers.

Why access it through accessor helpers?

I consider that it's the SVM and VMX "construction/setup" code
respectively which "own" hvm_funcs (as evidenced by the fact that they
create the structures and then return them); and I consider the
start_nested_{vmx/svm} to be a part of the same code; so I consider it
valid for them to have direct access to the structure.

> >> Is there a reason to use direct calls here rather than a true hook
> >> (seeing that hvm_funcs must have been populated by the time we make it
> >> here)? I understand we're (remotely) considering to switch away from
> >> using hooks at some point, but right now this feels somewhat
> >> inconsistent if not further justified.
> >
> > Again it mimics the calls to start_vmx/svm in hvm_enable.  But I could
> > look at adding a function pointer to see if it works.
>
> Andrew - do you have any input here towards those somewhat vague plans
> of getting rid of the hook functions? I guess they're more relevant in
> places where we can't easily use the altcall machinery (i.e. not here).

Rather than do all that work collecting information, why don't we just
check it in as it is?  Obviously if we're thinking about getting rid
of hook functions at some point anyway, it can't be all that bad.
There is an aesthetic justification for the lack of hook, in that it's
similar to the start_vmx/svm() functions.

So far I really don't think the remaining "open" changes we're
discussing are worth either of our efforts.  I don't plan to make any
of these changes unless another x86 maintainer seconds your request
(or you can convince me they're worth making).

(The other two changes -- correcting the function name in the commit
message, and removing the extra blank line -- I've already changed
locally, so could check in with your ack.)

 -George


From xen-devel-bounces@lists.xenproject.org Thu Mar 28 11:33:10 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 11:33:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698905.1091149 (Exim 4.92)
	(envelope-from )
	id 1rpo07-0002zh-Ub; Thu, 28 Mar 2024 11:32:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698905.1091149; Thu, 28 Mar 2024 11:32:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpo07-0002za-S3; Thu, 28 Mar 2024 11:32:55 +0000
Received: by outflank-mailman (input) for mailman id 698905;
 Thu, 28 Mar 2024 11:32:54 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpo06-0002zU-PO
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 11:32:54 +0000
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com
 [2a00:1450:4864:20::536])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e9033886-ecf6-11ee-a1ef-f123f15fe8a2;
 Thu, 28 Mar 2024 12:32:51 +0100 (CET)
Received: by mail-ed1-x536.google.com with SMTP id
 4fb4d7f45d1cf-56890b533aaso901253a12.3
 for ; Thu, 28 Mar 2024 04:32:51 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 l9-20020a1709060cc900b00a4e24d259edsm413099ejh.167.2024.03.28.04.32.50
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 28 Mar 2024 04:32:50 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e9033886-ecf6-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711625571; x=1712230371; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=Mc0h9f0K/2shyA9sWjQ3nCZxeX81aLSuNsQsMDqREjw=;
        b=cQNAFdIOckLiDA3XvmofMbQnL6pZjNDy830/Ud7PgVD3f0vx3WQUfB8zkHSN9xJ4k2
         DL3A+zhEDgmeJpsxBtaA4DPMQRCDSBehyfHRrSfGclnVuY5HkTc3TuAZzUJn0YBjJtwm
         1vCIwjTmVfcJJMVAXVKXn+xf0AJT1rdayjFflPOkrYScnPd0wG0ViJiMWK3swnKY/8fr
         pzFDR/66H+pBUkSO0LeCqjPGQeslGkecBNn6WY5j239aiF7VouI3i8VKFxts0xuivlsY
         bXTCPEheg0ynI01HEVwk6CXtYZodTaQo7vTcsGmAp8gZUnRnTpVBZwQedO7UtXTDjbGh
         mdug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711625571; x=1712230371;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=Mc0h9f0K/2shyA9sWjQ3nCZxeX81aLSuNsQsMDqREjw=;
        b=gJE2Uniy6uZy1vbgxzzgktfF+GHLmyD72t1KkQKeCwVbV2RhNvbimn4OqwWblyITCz
         fkcBvPNpr65X2/9TrmiI65z5GIPuskt3lYaOdzJX3X9jRIF2xQnVan9PnxX5Dts6c2tq
         wgU6qyGT8q6sqvXRvuBcAVhDBVHJmu6t7hVC6jqQZoj785aP8ZQmJZwTupbOFQHAiqca
         Z9dvdg3UkQMgie1Sdflph4eS2vqvj18wccNy1voS2Eehfd9Wfr1LfFtv3sSqMKAJ9E/6
         9liCvk7sHnbDN9Avd7807Q0O15+SrAuBPuf3laH6MOnqtqBFG5B1wPN2FjEx7C0KCy6y
         iu/g==
X-Forwarded-Encrypted: i=1; AJvYcCXa5FHBzEYAGwCMY1Y0D4Y/TR7oa3/5uMisCseFrxDJCXVuOxQX+9J3cUo8QaL1zKtG3JHKm/yuVdsr4oES5t/KNyTlgSddmzchqoru2Y0=
X-Gm-Message-State: AOJu0YwXbUpFDalhWkvcsrPzyv80wpJXUS0NWrjcWABIl/9H2L9E8I2d
	GT1KijJ34GJdWL8Rjyov4NWj3Evw0nxG9VOaL7Y1i0y0KLhyEV06lYdGaTIP8g==
X-Google-Smtp-Source: AGHT+IHS7XTsSs+vocQa08jv86unV24jngOn6ugiyRpDWpiD9t1RhyihTgS6EYRH+/ymozTQP22zhA==
X-Received: by 2002:a17:906:e255:b0:a4e:2269:bc21 with SMTP id gq21-20020a170906e25500b00a4e2269bc21mr953247ejb.1.1711625570622;
        Thu, 28 Mar 2024 04:32:50 -0700 (PDT)
Message-ID: 
Date: Thu, 28 Mar 2024 12:32:49 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 3/3] svm/nestedsvm: Introduce nested capabilities bit
Content-Language: en-US
To: George Dunlap 
Cc: Andrew Cooper , Julien Grall ,
 Stefano Stabellini , Wei Liu ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Jun Nakajima , Kevin Tian ,
 xen-devel@lists.xenproject.org
References: <20240313122454.965566-1-george.dunlap@cloud.com>
 <20240313122454.965566-4-george.dunlap@cloud.com>
 <7a5b3ec3-c122-479a-b714-529e150bf4c0@suse.com>
 
 
 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 28.03.2024 11:57, George Dunlap wrote:
> On Thu, Mar 28, 2024 at 6:44 AM Jan Beulich  wrote:
>>>>> --- a/xen/arch/x86/hvm/nestedhvm.c
>>>>> +++ b/xen/arch/x86/hvm/nestedhvm.c
>>>>> @@ -150,6 +150,16 @@ static int __init cf_check nestedhvm_setup(void)
>>>>>      __clear_bit(0x80, shadow_io_bitmap[0]);
>>>>>      __clear_bit(0xed, shadow_io_bitmap[1]);
>>>>>
>>>>> +    /*
>>>>> +     * NB this must be called after all command-line processing has been
>>>>> +     * done, so that if (for example) HAP is disabled, nested virt is
>>>>> +     * disabled as well.
>>>>> +     */
>>>>> +    if ( cpu_has_vmx )
>>>>> +        start_nested_vmx(&hvm_funcs);
>>>>> +    else if ( cpu_has_svm )
>>>>> +        start_nested_svm(&hvm_funcs);
>>>>
>>>> Instead of passing the pointer, couldn't you have the functions return
>>>> bool, and then set hvm_funcs.caps.nested_virt from that? Passing that
>>>> pointer looks somewhat odd to me.
>>>
>>> For one, it makes start_nested_XXX symmetric to start_XXX, which also
>>> has access to the full hvm_funcs structure (albeit in the former case
>>> because it's creating the structure).
>>
>> This last aspect is the crucial aspect: start{svm,vmx}() are indeed quite
>> special because of this. Everywhere else we have accessor helpers when
>> hvm_funcs needs consulting, e.g. ...
>>
>>>  For two, both of them need to read caps.hap.
>>
>> ... caps _reads_ would want using (an) accessor(s), too.
>>
>>>  For three, it's just more flexible -- there may be
>>> future things that we want to modify in the start_nested_*()
>>> functions.  If we did as you suggest, and then added (say)
>>> caps.nested_virt_needs_hap, then we'd either need to add a second
>>> function, or refactor it to look like this.
>>
>> Right, I can see this as an argument when taking, as you do, speculation
>> on future needs into account. Albeit I'm then inclined to say that even
>> such modifications may better be done through accessor helpers.
> 
> Why access it through accessor helpers?
> 
> I consider that it's the SVM and VMX "construction/setup" code
> respectively which "own" hvm_funcs (as evidenced by the fact that they
> create the structures and then return them); and I consider the
> start_nested_{vmx/svm} to be a part of the same code; so I consider it
> valid for them to have direct access to the structure.

That's one way of looking at it, yes. However, to me neither SVM nor VMX
code directly fiddle with hvm_funcs in the way you describe it. Instead
they return a pointer to their respective instances of struct
hvm_function_table. If the nested startup code would similarly alter
private struct instances of some sort, all would be fine.

May I suggest that you grep for hvm_funcs in what is there right now. You'll
find solely vmcs.c having a few uses of .caps, which likely are wrong (as in:
layering violations), too.

That said I can accept that the situation is slightly different here, when
generic code passes a pointer to the nested startup functions. To me at
least it still feels layering-violation-ish.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Mar 28 13:00:31 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 13:00:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698922.1091166 (Exim 4.92)
	(envelope-from )
	id 1rppMh-0006M5-Cr; Thu, 28 Mar 2024 13:00:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698922.1091166; Thu, 28 Mar 2024 13:00:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rppMh-0006Lx-AI; Thu, 28 Mar 2024 13:00:19 +0000
Received: by outflank-mailman (input) for mailman id 698922;
 Thu, 28 Mar 2024 13:00:18 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rppMg-0006Lr-0j
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 13:00:18 +0000
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com
 [2a00:1450:4864:20::529])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1f29aa58-ed03-11ee-afe3-a90da7624cb6;
 Thu, 28 Mar 2024 14:00:16 +0100 (CET)
Received: by mail-ed1-x529.google.com with SMTP id
 4fb4d7f45d1cf-56bf63af770so465681a12.3
 for ; Thu, 28 Mar 2024 06:00:16 -0700 (PDT)
Received: from ?IPV6:2003:e5:873a:400:704b:6dbb:e7c0:786e?
 (p200300e5873a0400704b6dbbe7c0786e.dip0.t-ipconnect.de.
 [2003:e5:873a:400:704b:6dbb:e7c0:786e])
 by smtp.gmail.com with ESMTPSA id
 et12-20020a056402378c00b0056c3e65caecsm803706edb.2.2024.03.28.06.00.14
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 28 Mar 2024 06:00:14 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1f29aa58-ed03-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711630815; x=1712235615; darn=lists.xenproject.org;
        h=in-reply-to:from:references:cc:to:content-language:subject
         :user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=6gVK2RuSKlDucKcDNQIJd3Zm6wPOqDxk/bwuvdV9VgU=;
        b=NvYLzASWliErha/EVeiVPA56isc0W203xYjC38Boc8qqWr15amstALymPY5bmhW8MX
         YZkZ8jq+lIJDhNExJcXuM4UCXTOyrFvVRXLQ0Wc7/h3KY20i4sEFAkO2ufscSwPaqo3X
         IaUCTcwp933ppUbc4ZCaFIjrqE/NABkN4nrRkJgYx4l2uGwjToKyK0ywRhvFCmN7tRIM
         7tArcWXyZkNQiVbQotfyUz5/L5N/aHLFkTclFNkVb/GQViUgaPDbO1woC5uVDAoljKQu
         CTVTnfWjI8T35m9QwBP1Vj5Ts59gsEG+CPFv4fYisCbEoxGmYkjf+uRpB1hzT+IBaZ3N
         EEhg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711630815; x=1712235615;
        h=in-reply-to:from:references:cc:to:content-language:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=6gVK2RuSKlDucKcDNQIJd3Zm6wPOqDxk/bwuvdV9VgU=;
        b=uJhN4GyZXZo9ywwnvLUF57uaddNdCQF1R49RttkEC0OKClb70YsLVQhFH9vt7ZnzHJ
         3cEvg5wAzTJomZCt5kNiBGR41Qo8V6v/nGqCcSiwpyMudCtQxFZO9delAHpCw/3Xu/QY
         UxRrHuVhm7ezxSwLRSsgxSsob3mQUyZZXN+KXOsY/lqduhj9xV7TvodvMR1KN+Ju5Nf2
         JpnIKlTJm03U+dIl8+TyH9OFhrjFxvADQW2XpDzbCWwqVYXsVSyc8wVH23SIni70QgPw
         AeffirrjYowBbIoJd3/MLNLYsGQRona6rSW2sOuC3ceAjveHgKUkdxhVVKgljEaqrUb0
         hNSA==
X-Gm-Message-State: AOJu0YynUCv2g2uXKz7MqxmukinZTEJtSiYn+lStFUx0BmkSjgv/ykHt
	AJ+NP8kTlyAE4MgbCwGB8nqPQpR7EyECWlzHnQdeh531HmTRHzIQZpV6mXCo80J/0WtTF8rQzGn
	X
X-Google-Smtp-Source: AGHT+IGP9AKI3/w0M64ViWiA7B0IBCCrMzTrFOGD2pzee1ocIHEvl+PBIFLPqZQ0IbbqPipPnYcu0w==
X-Received: by 2002:a50:d756:0:b0:568:32f7:6c55 with SMTP id i22-20020a50d756000000b0056832f76c55mr2729797edj.9.1711630815285;
        Thu, 28 Mar 2024 06:00:15 -0700 (PDT)
Content-Type: multipart/mixed; boundary="------------4F6hAD70j0NDeDktIIeZUMFE"
Message-ID: <9b5a105a-650c-4b33-9f4e-03612fb6701c@suse.com>
Date: Thu, 28 Mar 2024 14:00:14 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Linux Xen PV CPA W^X violation false-positives
Content-Language: en-US
To: Jason Andryuk 
Cc: xen-devel@lists.xenproject.org
References: <20240124165401.35784-1-jandryuk@gmail.com>
 
 
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
In-Reply-To: 

This is a multi-part message in MIME format.
--------------4F6hAD70j0NDeDktIIeZUMFE
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Jason,

On 28.03.24 02:24, Jason Andryuk wrote:
> On Wed, Mar 27, 2024 at 7:46 AM Jürgen Groß  wrote:
>>
>> On 24.01.24 17:54, Jason Andryuk wrote:
>>> +
>>> +                     return new;
>>> +             }
>>> +     }
>>> +
>>>        end = start + npg * PAGE_SIZE - 1;
>>>        WARN_ONCE(1, "CPA detected W^X violation: %016llx -> %016llx range: 0x%016lx - 0x%016lx PFN %lx\n",
>>>                  (unsigned long long)pgprot_val(old),
>>
>> Jason, do you want to send a V2 with your Signed-off, or would you like me to
>> try upstreaming the patch?
> 
> Hi Jürgen,
> 
> Yes, please upstream your approach.  I wasn't sure how to deal with
> it, so it was more of a bug report.

The final solution was a bit more complicated, as there are some
corner cases to be considered. OTOH it is now complete by looking
at all used translation entries.

Are you able to test the attached patch? I don't see the original
issue and can only verify the patch doesn't cause any regression.


Juergen

--------------4F6hAD70j0NDeDktIIeZUMFE
Content-Type: text/x-patch; charset=UTF-8;
 name="0001-x86-pat-fix-W-X-violation-false-positives-when-runni.patch"
Content-Disposition: attachment;
 filename*0="0001-x86-pat-fix-W-X-violation-false-positives-when-runni.pa";
 filename*1="tch"
Content-Transfer-Encoding: base64

RnJvbSBmZDI1YTY3ZDkyZTQ0YjYxZDA1ZDkyNjU4YjIzZDAyNjIwMmExNjU2IE1vbiBTZXAg
MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBKdWVyZ2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+
ClRvOiB4ODZAa2VybmVsLm9yZwpUbzogbGludXgta2VybmVsQHZnZXIua2VybmVsLm9yZwpU
bzogeGVuLWRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnCkNjOiBUaG9tYXMgR2xlaXhuZXIg
PHRnbHhAbGludXRyb25peC5kZT4KQ2M6IEluZ28gTW9sbmFyIDxtaW5nb0ByZWRoYXQuY29t
PgpDYzogQm9yaXNsYXYgUGV0a292IDxicEBhbGllbjguZGU+CkNjOiBEYXZlIEhhbnNlbiA8
ZGF2ZS5oYW5zZW5AbGludXguaW50ZWwuY29tPgpDYzogIkguIFBldGVyIEFudmluIiA8aHBh
QHp5dG9yLmNvbT4KQ2M6IEFuZHkgTHV0b21pcnNraSA8bHV0b0BrZXJuZWwub3JnPgpDYzog
UGV0ZXIgWmlqbHN0cmEgPHBldGVyekBpbmZyYWRlYWQub3JnPgpEYXRlOiBUaHUsIDI4IE1h
ciAyMDI0IDEyOjI0OjQ4ICswMTAwClN1YmplY3Q6IFtQQVRDSF0geDg2L3BhdDogZml4IFde
WCB2aW9sYXRpb24gZmFsc2UtcG9zaXRpdmVzIHdoZW4gcnVubmluZyBhcwogWGVuIFBWIGd1
ZXN0CgpXaGVuIHJ1bm5pbmcgYXMgWGVuIFBWIGd1ZXN0IGluIHNvbWUgY2FzZXMgV15YIHZp
b2xhdGlvbiBXQVJOKClzIGhhdmUKYmVlbiBvYnNlcnZlZC4gVGhvc2UgV0FSTigpcyBhcmUg
cHJvZHVjZWQgYnkgdmVyaWZ5X3J3eCgpLCB3aGljaCBsb29rcwppbnRvIHRoZSBQVEUgdG8g
dmVyaWZ5IHRoYXQgd3JpdGFibGUga2VybmVsIHBhZ2VzIGhhdmUgdGhlIE5YIGJpdCBzZXQK
aW4gb3JkZXIgdG8gYXZvaWQgY29kZSBtb2RpZmljYXRpb25zIG9mIHRoZSBrZXJuZWwgYnkg
cm9ndWUgY29kZS4KCkFzIHRoZSBOWCBiaXRzIG9mIGFsbCBsZXZlbHMgb2YgdHJhbnNsYXRp
b24gZW50cmllcyBhcmUgb3ItZWQgYW5kIHRoZQpSVyBiaXRzIG9mIGFsbCBsZXZlbHMgYXJl
IGFuZC1lZCwgbG9va2luZyBqdXN0IGludG8gdGhlIFBURSBpc24ndCBlbm91Z2gKZm9yIHRo
ZSBkZWNpc2lvbiB0aGF0IGEgd3JpdGFibGUgcGFnZSBpcyBleGVjdXRhYmxlLCB0b28uIFdo
ZW4gcnVubmluZwphcyBhIFhlbiBQViBndWVzdCwga2VybmVsIGluaXRpYWxpemF0aW9uIHdp
bGwgc2V0IHRoZSBOWCBiaXQgaW4gUE1ECmVudHJpZXMgb2YgdGhlIGluaXRpYWwgcGFnZSB0
YWJsZXMgY292ZXJpbmcgdGhlIC5kYXRhIHNlZ21lbnQuCgpXaGVuIGZpbmRpbmcgdGhlIFBU
RSB0byBoYXZlIHNldCB0aGUgUlcgYml0IGJ1dCBubyBOWCBiaXQsIGhpZ2hlciBsZXZlbApl
bnRyaWVzIG11c3QgYmUgbG9va2VkIGF0LiBPbmx5IHdoZW4gYWxsIGxldmVscyBoYXZlIHRo
ZSBSVyBiaXQgc2V0IGFuZApubyBOWCBiaXQgc2V0LCB0aGUgV15YIHZpb2xhdGlvbiBzaG91
bGQgYmUgZmxhZ2dlZC4KCkFkZGl0aW9uYWxseSBzaG93X2ZhdWx0X29vcHMoKSBoYXMgYSBz
aW1pbGFyIHByb2JsZW06IGl0IHdpbGwgaXNzdWUgdGhlCiJrZXJuZWwgdHJpZWQgdG8gZXhl
Y3V0ZSBOWC1wcm90ZWN0ZWQgcGFnZSIgbWVzc2FnZSBvbmx5IGlmIGl0IGZpbmRzCnRoZSBO
WCBiaXQgc2V0IGluIHRoZSBsZWFmIHRyYW5zbGF0aW9uIGVudHJ5LCB3aGlsZSBhbnkgTlgg
Yml0IGluCm5vbi1sZWFmIGVudHJpZXMgYXJlIGJlaW5nIGlnbm9yZWQgZm9yIGlzc3Vpbmcg
dGhlIG1lc3NhZ2UuCgpNb2RpZnkgbG9va3VwX2FkZHJlc3NfaW5fcGdkKCkgdG8gcmV0dXJu
IHRoZSBlZmZlY3RpdmUgTlggYW5kIFJXIGJpdAp2YWx1ZXMgb2YgdGhlIG5vbi1sZWFmIHRy
YW5zbGF0aW9uIGVudHJpZXMgYW5kIGV2YWx1YXRlIHRob3NlIGFzIHdlbGwKaW4gdmVyaWZ5
X3J3eCgpIGFuZCBzaG93X2ZhdWx0X29vcHMoKS4KCkZpeGVzOiA2NTJjNWJmMzgwYWQgKCJ4
ODYvbW06IFJlZnVzZSBXXlggdmlvbGF0aW9ucyIpClJlcG9ydGVkLWJ5OiBKYXNvbiBBbmRy
eXVrIDxqYW5kcnl1a0BnbWFpbC5jb20+ClNpZ25lZC1vZmYtYnk6IEp1ZXJnZW4gR3Jvc3Mg
PGpncm9zc0BzdXNlLmNvbT4KLS0tCiBhcmNoL3g4Ni9pbmNsdWRlL2FzbS9wZ3RhYmxlX3R5
cGVzLmggfCAgMiArLQogYXJjaC94ODYva2VybmVsL3Nldi5jICAgICAgICAgICAgICAgIHwg
IDMgKy0KIGFyY2gveDg2L21tL2ZhdWx0LmMgICAgICAgICAgICAgICAgICB8ICA3ICsrLS0K
IGFyY2gveDg2L21tL3BhdC9zZXRfbWVtb3J5LmMgICAgICAgICB8IDU2ICsrKysrKysrKysr
KysrKysrKysrKy0tLS0tLS0KIGFyY2gveDg2L3ZpcnQvc3ZtL3Nldi5jICAgICAgICAgICAg
ICB8ICAzICstCiA1IGZpbGVzIGNoYW5nZWQsIDUyIGluc2VydGlvbnMoKyksIDE5IGRlbGV0
aW9ucygtKQoKZGlmZiAtLWdpdCBhL2FyY2gveDg2L2luY2x1ZGUvYXNtL3BndGFibGVfdHlw
ZXMuaCBiL2FyY2gveDg2L2luY2x1ZGUvYXNtL3BndGFibGVfdHlwZXMuaAppbmRleCAwYjc0
OGVlMTZiM2QuLjkxYWI1MzhkMzg3MiAxMDA2NDQKLS0tIGEvYXJjaC94ODYvaW5jbHVkZS9h
c20vcGd0YWJsZV90eXBlcy5oCisrKyBiL2FyY2gveDg2L2luY2x1ZGUvYXNtL3BndGFibGVf
dHlwZXMuaApAQCAtNTY1LDcgKzU2NSw3IEBAIHN0YXRpYyBpbmxpbmUgdm9pZCB1cGRhdGVf
cGFnZV9jb3VudChpbnQgbGV2ZWwsIHVuc2lnbmVkIGxvbmcgcGFnZXMpIHsgfQogICovCiBl
eHRlcm4gcHRlX3QgKmxvb2t1cF9hZGRyZXNzKHVuc2lnbmVkIGxvbmcgYWRkcmVzcywgdW5z
aWduZWQgaW50ICpsZXZlbCk7CiBleHRlcm4gcHRlX3QgKmxvb2t1cF9hZGRyZXNzX2luX3Bn
ZChwZ2RfdCAqcGdkLCB1bnNpZ25lZCBsb25nIGFkZHJlc3MsCi0JCQkJICAgIHVuc2lnbmVk
IGludCAqbGV2ZWwpOworCQkJCSAgICB1bnNpZ25lZCBpbnQgKmxldmVsLCBib29sICpueCwg
Ym9vbCAqcncpOwogZXh0ZXJuIHBtZF90ICpsb29rdXBfcG1kX2FkZHJlc3ModW5zaWduZWQg
bG9uZyBhZGRyZXNzKTsKIGV4dGVybiBwaHlzX2FkZHJfdCBzbG93X3ZpcnRfdG9fcGh5cyh2
b2lkICpfX2FkZHJlc3MpOwogZXh0ZXJuIGludCBfX2luaXQga2VybmVsX21hcF9wYWdlc19p
bl9wZ2QocGdkX3QgKnBnZCwgdTY0IHBmbiwKZGlmZiAtLWdpdCBhL2FyY2gveDg2L2tlcm5l
bC9zZXYuYyBiL2FyY2gveDg2L2tlcm5lbC9zZXYuYwppbmRleCBiNTliMDljMmYyODQuLmU4
MzMxODNkMWFkYiAxMDA2NDQKLS0tIGEvYXJjaC94ODYva2VybmVsL3Nldi5jCisrKyBiL2Fy
Y2gveDg2L2tlcm5lbC9zZXYuYwpAQCAtNTE1LDEyICs1MTUsMTMgQEAgc3RhdGljIGVudW0g
ZXNfcmVzdWx0IHZjX3Nsb3dfdmlydF90b19waHlzKHN0cnVjdCBnaGNiICpnaGNiLCBzdHJ1
Y3QgZXNfZW1fY3R4dAogCXVuc2lnbmVkIGxvbmcgdmEgPSAodW5zaWduZWQgbG9uZyl2YWRk
cjsKIAl1bnNpZ25lZCBpbnQgbGV2ZWw7CiAJcGh5c19hZGRyX3QgcGE7CisJYm9vbCBueCwg
cnc7CiAJcGdkX3QgKnBnZDsKIAlwdGVfdCAqcHRlOwogCiAJcGdkID0gX192YShyZWFkX2Ny
M19wYSgpKTsKIAlwZ2QgPSAmcGdkW3BnZF9pbmRleCh2YSldOwotCXB0ZSA9IGxvb2t1cF9h
ZGRyZXNzX2luX3BnZChwZ2QsIHZhLCAmbGV2ZWwpOworCXB0ZSA9IGxvb2t1cF9hZGRyZXNz
X2luX3BnZChwZ2QsIHZhLCAmbGV2ZWwsICZueCwgJnJ3KTsKIAlpZiAoIXB0ZSkgewogCQlj
dHh0LT5maS52ZWN0b3IgICAgID0gWDg2X1RSQVBfUEY7CiAJCWN0eHQtPmZpLmNyMiAgICAg
ICAgPSB2YWRkcjsKZGlmZiAtLWdpdCBhL2FyY2gveDg2L21tL2ZhdWx0LmMgYi9hcmNoL3g4
Ni9tbS9mYXVsdC5jCmluZGV4IDYyMmQxMmVjN2YwOC4uZWI4ZTg5N2E1NjUzIDEwMDY0NAot
LS0gYS9hcmNoL3g4Ni9tbS9mYXVsdC5jCisrKyBiL2FyY2gveDg2L21tL2ZhdWx0LmMKQEAg
LTUxNCwxOCArNTE0LDE5IEBAIHNob3dfZmF1bHRfb29wcyhzdHJ1Y3QgcHRfcmVncyAqcmVn
cywgdW5zaWduZWQgbG9uZyBlcnJvcl9jb2RlLCB1bnNpZ25lZCBsb25nIGFkCiAKIAlpZiAo
ZXJyb3JfY29kZSAmIFg4Nl9QRl9JTlNUUikgewogCQl1bnNpZ25lZCBpbnQgbGV2ZWw7CisJ
CWJvb2wgbngsIHJ3OwogCQlwZ2RfdCAqcGdkOwogCQlwdGVfdCAqcHRlOwogCiAJCXBnZCA9
IF9fdmEocmVhZF9jcjNfcGEoKSk7CiAJCXBnZCArPSBwZ2RfaW5kZXgoYWRkcmVzcyk7CiAK
LQkJcHRlID0gbG9va3VwX2FkZHJlc3NfaW5fcGdkKHBnZCwgYWRkcmVzcywgJmxldmVsKTsK
KwkJcHRlID0gbG9va3VwX2FkZHJlc3NfaW5fcGdkKHBnZCwgYWRkcmVzcywgJmxldmVsLCAm
bngsICZydyk7CiAKLQkJaWYgKHB0ZSAmJiBwdGVfcHJlc2VudCgqcHRlKSAmJiAhcHRlX2V4
ZWMoKnB0ZSkpCisJCWlmIChwdGUgJiYgcHRlX3ByZXNlbnQoKnB0ZSkgJiYgKCFwdGVfZXhl
YygqcHRlKSB8fCBueCkpCiAJCQlwcl9jcml0KCJrZXJuZWwgdHJpZWQgdG8gZXhlY3V0ZSBO
WC1wcm90ZWN0ZWQgcGFnZSAtIGV4cGxvaXQgYXR0ZW1wdD8gKHVpZDogJWQpXG4iLAogCQkJ
CWZyb21fa3VpZCgmaW5pdF91c2VyX25zLCBjdXJyZW50X3VpZCgpKSk7Ci0JCWlmIChwdGUg
JiYgcHRlX3ByZXNlbnQoKnB0ZSkgJiYgcHRlX2V4ZWMoKnB0ZSkgJiYKKwkJaWYgKHB0ZSAm
JiBwdGVfcHJlc2VudCgqcHRlKSAmJiBwdGVfZXhlYygqcHRlKSAmJiAhbnggJiYKIAkJCQko
cGdkX2ZsYWdzKCpwZ2QpICYgX1BBR0VfVVNFUikgJiYKIAkJCQkoX19yZWFkX2NyNCgpICYg
WDg2X0NSNF9TTUVQKSkKIAkJCXByX2NyaXQoInVuYWJsZSB0byBleGVjdXRlIHVzZXJzcGFj
ZSBjb2RlIChTTUVQPykgKHVpZDogJWQpXG4iLApkaWZmIC0tZ2l0IGEvYXJjaC94ODYvbW0v
cGF0L3NldF9tZW1vcnkuYyBiL2FyY2gveDg2L21tL3BhdC9zZXRfbWVtb3J5LmMKaW5kZXgg
ODBjOTAzN2ZmYWRmLi5iYWE0ZGM0NzQ4ZTkgMTAwNjQ0Ci0tLSBhL2FyY2gveDg2L21tL3Bh
dC9zZXRfbWVtb3J5LmMKKysrIGIvYXJjaC94ODYvbW0vcGF0L3NldF9tZW1vcnkuYwpAQCAt
NjE5LDcgKzYxOSw4IEBAIHN0YXRpYyBpbmxpbmUgcGdwcm90X3Qgc3RhdGljX3Byb3RlY3Rp
b25zKHBncHJvdF90IHByb3QsIHVuc2lnbmVkIGxvbmcgc3RhcnQsCiAgKiBWYWxpZGF0ZSBz
dHJpY3QgV15YIHNlbWFudGljcy4KICAqLwogc3RhdGljIGlubGluZSBwZ3Byb3RfdCB2ZXJp
Znlfcnd4KHBncHJvdF90IG9sZCwgcGdwcm90X3QgbmV3LCB1bnNpZ25lZCBsb25nIHN0YXJ0
LAotCQkJCSAgdW5zaWduZWQgbG9uZyBwZm4sIHVuc2lnbmVkIGxvbmcgbnBnKQorCQkJCSAg
dW5zaWduZWQgbG9uZyBwZm4sIHVuc2lnbmVkIGxvbmcgbnBnLAorCQkJCSAgYm9vbCBueCwg
Ym9vbCBydykKIHsKIAl1bnNpZ25lZCBsb25nIGVuZDsKIApAQCAtNjQxLDYgKzY0MiwxMCBA
QCBzdGF0aWMgaW5saW5lIHBncHJvdF90IHZlcmlmeV9yd3gocGdwcm90X3Qgb2xkLCBwZ3By
b3RfdCBuZXcsIHVuc2lnbmVkIGxvbmcgc3RhcgogCWlmICgocGdwcm90X3ZhbChuZXcpICYg
KF9QQUdFX1JXIHwgX1BBR0VfTlgpKSAhPSBfUEFHRV9SVykKIAkJcmV0dXJuIG5ldzsKIAor
CS8qIE5vbi1sZWFmIHRyYW5zbGF0aW9uIGVudHJpZXMgY2FuIGRpc2FibGUgd3JpdGluZyBv
ciBleGVjdXRpb24uICovCisJaWYgKCFydyB8fCBueCkKKwkJcmV0dXJuIG5ldzsKKwogCWVu
ZCA9IHN0YXJ0ICsgbnBnICogUEFHRV9TSVpFIC0gMTsKIAlXQVJOX09OQ0UoMSwgIkNQQSBk
ZXRlY3RlZCBXXlggdmlvbGF0aW9uOiAlMDE2bGx4IC0+ICUwMTZsbHggcmFuZ2U6IDB4JTAx
Nmx4IC0gMHglMDE2bHggUEZOICVseFxuIiwKIAkJICAodW5zaWduZWQgbG9uZyBsb25nKXBn
cHJvdF92YWwob2xkKSwKQEAgLTY2MCwxNyArNjY1LDIyIEBAIHN0YXRpYyBpbmxpbmUgcGdw
cm90X3QgdmVyaWZ5X3J3eChwZ3Byb3RfdCBvbGQsIHBncHJvdF90IG5ldywgdW5zaWduZWQg
bG9uZyBzdGFyCiAgKiBSZXR1cm4gYSBwb2ludGVyIHRvIHRoZSBlbnRyeSBhbmQgdGhlIGxl
dmVsIG9mIHRoZSBtYXBwaW5nLgogICovCiBwdGVfdCAqbG9va3VwX2FkZHJlc3NfaW5fcGdk
KHBnZF90ICpwZ2QsIHVuc2lnbmVkIGxvbmcgYWRkcmVzcywKLQkJCSAgICAgdW5zaWduZWQg
aW50ICpsZXZlbCkKKwkJCSAgICAgdW5zaWduZWQgaW50ICpsZXZlbCwgYm9vbCAqbngsIGJv
b2wgKnJ3KQogewogCXA0ZF90ICpwNGQ7CiAJcHVkX3QgKnB1ZDsKIAlwbWRfdCAqcG1kOwog
CiAJKmxldmVsID0gUEdfTEVWRUxfTk9ORTsKKwkqbnggPSBmYWxzZTsKKwkqcncgPSB0cnVl
OwogCiAJaWYgKHBnZF9ub25lKCpwZ2QpKQogCQlyZXR1cm4gTlVMTDsKIAorCSpueCB8PSBw
Z2RfZmxhZ3MoKnBnZCkgJiBfUEFHRV9OWDsKKwkqcncgJj0gcGdkX2ZsYWdzKCpwZ2QpICYg
X1BBR0VfUlc7CisKIAlwNGQgPSBwNGRfb2Zmc2V0KHBnZCwgYWRkcmVzcyk7CiAJaWYgKHA0
ZF9ub25lKCpwNGQpKQogCQlyZXR1cm4gTlVMTDsKQEAgLTY3OSw2ICs2ODksOSBAQCBwdGVf
dCAqbG9va3VwX2FkZHJlc3NfaW5fcGdkKHBnZF90ICpwZ2QsIHVuc2lnbmVkIGxvbmcgYWRk
cmVzcywKIAlpZiAocDRkX2xlYWYoKnA0ZCkgfHwgIXA0ZF9wcmVzZW50KCpwNGQpKQogCQly
ZXR1cm4gKHB0ZV90ICopcDRkOwogCisJKm54IHw9IHA0ZF9mbGFncygqcDRkKSAmIF9QQUdF
X05YOworCSpydyAmPSBwNGRfZmxhZ3MoKnA0ZCkgJiBfUEFHRV9SVzsKKwogCXB1ZCA9IHB1
ZF9vZmZzZXQocDRkLCBhZGRyZXNzKTsKIAlpZiAocHVkX25vbmUoKnB1ZCkpCiAJCXJldHVy
biBOVUxMOwpAQCAtNjg3LDYgKzcwMCw5IEBAIHB0ZV90ICpsb29rdXBfYWRkcmVzc19pbl9w
Z2QocGdkX3QgKnBnZCwgdW5zaWduZWQgbG9uZyBhZGRyZXNzLAogCWlmIChwdWRfbGVhZigq
cHVkKSB8fCAhcHVkX3ByZXNlbnQoKnB1ZCkpCiAJCXJldHVybiAocHRlX3QgKilwdWQ7CiAK
KwkqbnggfD0gcHVkX2ZsYWdzKCpwdWQpICYgX1BBR0VfTlg7CisJKnJ3ICY9IHB1ZF9mbGFn
cygqcHVkKSAmIF9QQUdFX1JXOworCiAJcG1kID0gcG1kX29mZnNldChwdWQsIGFkZHJlc3Mp
OwogCWlmIChwbWRfbm9uZSgqcG1kKSkKIAkJcmV0dXJuIE5VTEw7CkBAIC02OTUsNiArNzEx
LDkgQEAgcHRlX3QgKmxvb2t1cF9hZGRyZXNzX2luX3BnZChwZ2RfdCAqcGdkLCB1bnNpZ25l
ZCBsb25nIGFkZHJlc3MsCiAJaWYgKHBtZF9sZWFmKCpwbWQpIHx8ICFwbWRfcHJlc2VudCgq
cG1kKSkKIAkJcmV0dXJuIChwdGVfdCAqKXBtZDsKIAorCSpueCB8PSBwbWRfZmxhZ3MoKnBt
ZCkgJiBfUEFHRV9OWDsKKwkqcncgJj0gcG1kX2ZsYWdzKCpwbWQpICYgX1BBR0VfUlc7CisK
IAkqbGV2ZWwgPSBQR19MRVZFTF80SzsKIAogCXJldHVybiBwdGVfb2Zmc2V0X2tlcm5lbChw
bWQsIGFkZHJlc3MpOwpAQCAtNzEwLDE4ICs3MjksMjQgQEAgcHRlX3QgKmxvb2t1cF9hZGRy
ZXNzX2luX3BnZChwZ2RfdCAqcGdkLCB1bnNpZ25lZCBsb25nIGFkZHJlc3MsCiAgKi8KIHB0
ZV90ICpsb29rdXBfYWRkcmVzcyh1bnNpZ25lZCBsb25nIGFkZHJlc3MsIHVuc2lnbmVkIGlu
dCAqbGV2ZWwpCiB7Ci0JcmV0dXJuIGxvb2t1cF9hZGRyZXNzX2luX3BnZChwZ2Rfb2Zmc2V0
X2soYWRkcmVzcyksIGFkZHJlc3MsIGxldmVsKTsKKwlib29sIG54LCBydzsKKworCXJldHVy
biBsb29rdXBfYWRkcmVzc19pbl9wZ2QocGdkX29mZnNldF9rKGFkZHJlc3MpLCBhZGRyZXNz
LCBsZXZlbCwKKwkJCQkgICAgICZueCwgJnJ3KTsKIH0KIEVYUE9SVF9TWU1CT0xfR1BMKGxv
b2t1cF9hZGRyZXNzKTsKIAogc3RhdGljIHB0ZV90ICpfbG9va3VwX2FkZHJlc3NfY3BhKHN0
cnVjdCBjcGFfZGF0YSAqY3BhLCB1bnNpZ25lZCBsb25nIGFkZHJlc3MsCi0JCQkJICB1bnNp
Z25lZCBpbnQgKmxldmVsKQorCQkJCSAgdW5zaWduZWQgaW50ICpsZXZlbCwgYm9vbCAqbngs
IGJvb2wgKnJ3KQogewotCWlmIChjcGEtPnBnZCkKLQkJcmV0dXJuIGxvb2t1cF9hZGRyZXNz
X2luX3BnZChjcGEtPnBnZCArIHBnZF9pbmRleChhZGRyZXNzKSwKLQkJCQkJICAgICAgIGFk
ZHJlc3MsIGxldmVsKTsKKwlwZ2RfdCAqcGdkOworCisJaWYgKCFjcGEtPnBnZCkKKwkJcGdk
ID0gcGdkX29mZnNldF9rKGFkZHJlc3MpOworCWVsc2UKKwkJcGdkID0gY3BhLT5wZ2QgKyBw
Z2RfaW5kZXgoYWRkcmVzcyk7CiAKLQlyZXR1cm4gbG9va3VwX2FkZHJlc3MoYWRkcmVzcywg
bGV2ZWwpOworCXJldHVybiBsb29rdXBfYWRkcmVzc19pbl9wZ2QocGdkLCBhZGRyZXNzLCBs
ZXZlbCwgbngsIHJ3KTsKIH0KIAogLyoKQEAgLTg0OSwxMiArODc0LDEzIEBAIHN0YXRpYyBp
bnQgX19zaG91bGRfc3BsaXRfbGFyZ2VfcGFnZShwdGVfdCAqa3B0ZSwgdW5zaWduZWQgbG9u
ZyBhZGRyZXNzLAogCXBncHJvdF90IG9sZF9wcm90LCBuZXdfcHJvdCwgcmVxX3Byb3QsIGNo
a19wcm90OwogCXB0ZV90IG5ld19wdGUsICp0bXA7CiAJZW51bSBwZ19sZXZlbCBsZXZlbDsK
Kwlib29sIG54LCBydzsKIAogCS8qCiAJICogQ2hlY2sgZm9yIHJhY2VzLCBhbm90aGVyIENQ
VSBtaWdodCBoYXZlIHNwbGl0IHRoaXMgcGFnZQogCSAqIHVwIGFscmVhZHk6CiAJICovCi0J
dG1wID0gX2xvb2t1cF9hZGRyZXNzX2NwYShjcGEsIGFkZHJlc3MsICZsZXZlbCk7CisJdG1w
ID0gX2xvb2t1cF9hZGRyZXNzX2NwYShjcGEsIGFkZHJlc3MsICZsZXZlbCwgJm54LCAmcncp
OwogCWlmICh0bXAgIT0ga3B0ZSkKIAkJcmV0dXJuIDE7CiAKQEAgLTk2NSw3ICs5OTEsOCBA
QCBzdGF0aWMgaW50IF9fc2hvdWxkX3NwbGl0X2xhcmdlX3BhZ2UocHRlX3QgKmtwdGUsIHVu
c2lnbmVkIGxvbmcgYWRkcmVzcywKIAluZXdfcHJvdCA9IHN0YXRpY19wcm90ZWN0aW9ucyhy
ZXFfcHJvdCwgbHBhZGRyLCBvbGRfcGZuLCBudW1wYWdlcywKIAkJCQkgICAgICBwc2l6ZSwg
Q1BBX0RFVEVDVCk7CiAKLQluZXdfcHJvdCA9IHZlcmlmeV9yd3gob2xkX3Byb3QsIG5ld19w
cm90LCBscGFkZHIsIG9sZF9wZm4sIG51bXBhZ2VzKTsKKwluZXdfcHJvdCA9IHZlcmlmeV9y
d3gob2xkX3Byb3QsIG5ld19wcm90LCBscGFkZHIsIG9sZF9wZm4sIG51bXBhZ2VzLAorCQkJ
ICAgICAgbngsIHJ3KTsKIAogCS8qCiAJICogSWYgdGhlcmUgaXMgYSBjb25mbGljdCwgc3Bs
aXQgdGhlIGxhcmdlIHBhZ2UuCkBAIC0xMDQ2LDYgKzEwNzMsNyBAQCBfX3NwbGl0X2xhcmdl
X3BhZ2Uoc3RydWN0IGNwYV9kYXRhICpjcGEsIHB0ZV90ICprcHRlLCB1bnNpZ25lZCBsb25n
IGFkZHJlc3MsCiAJcHRlX3QgKnBiYXNlID0gKHB0ZV90ICopcGFnZV9hZGRyZXNzKGJhc2Up
OwogCXVuc2lnbmVkIGludCBpLCBsZXZlbDsKIAlwZ3Byb3RfdCByZWZfcHJvdDsKKwlib29s
IG54LCBydzsKIAlwdGVfdCAqdG1wOwogCiAJc3Bpbl9sb2NrKCZwZ2RfbG9jayk7CkBAIC0x
MDUzLDcgKzEwODEsNyBAQCBfX3NwbGl0X2xhcmdlX3BhZ2Uoc3RydWN0IGNwYV9kYXRhICpj
cGEsIHB0ZV90ICprcHRlLCB1bnNpZ25lZCBsb25nIGFkZHJlc3MsCiAJICogQ2hlY2sgZm9y
IHJhY2VzLCBhbm90aGVyIENQVSBtaWdodCBoYXZlIHNwbGl0IHRoaXMgcGFnZQogCSAqIHVw
IGZvciB1cyBhbHJlYWR5OgogCSAqLwotCXRtcCA9IF9sb29rdXBfYWRkcmVzc19jcGEoY3Bh
LCBhZGRyZXNzLCAmbGV2ZWwpOworCXRtcCA9IF9sb29rdXBfYWRkcmVzc19jcGEoY3BhLCBh
ZGRyZXNzLCAmbGV2ZWwsICZueCwgJnJ3KTsKIAlpZiAodG1wICE9IGtwdGUpIHsKIAkJc3Bp
bl91bmxvY2soJnBnZF9sb2NrKTsKIAkJcmV0dXJuIDE7CkBAIC0xNTk0LDEwICsxNjIyLDEx
IEBAIHN0YXRpYyBpbnQgX19jaGFuZ2VfcGFnZV9hdHRyKHN0cnVjdCBjcGFfZGF0YSAqY3Bh
LCBpbnQgcHJpbWFyeSkKIAlpbnQgZG9fc3BsaXQsIGVycjsKIAl1bnNpZ25lZCBpbnQgbGV2
ZWw7CiAJcHRlX3QgKmtwdGUsIG9sZF9wdGU7CisJYm9vbCBueCwgcnc7CiAKIAlhZGRyZXNz
ID0gX19jcGFfYWRkcihjcGEsIGNwYS0+Y3VycGFnZSk7CiByZXBlYXQ6Ci0Ja3B0ZSA9IF9s
b29rdXBfYWRkcmVzc19jcGEoY3BhLCBhZGRyZXNzLCAmbGV2ZWwpOworCWtwdGUgPSBfbG9v
a3VwX2FkZHJlc3NfY3BhKGNwYSwgYWRkcmVzcywgJmxldmVsLCAmbngsICZydyk7CiAJaWYg
KCFrcHRlKQogCQlyZXR1cm4gX19jcGFfcHJvY2Vzc19mYXVsdChjcGEsIGFkZHJlc3MsIHBy
aW1hcnkpOwogCkBAIC0xNjE5LDcgKzE2NDgsOCBAQCBzdGF0aWMgaW50IF9fY2hhbmdlX3Bh
Z2VfYXR0cihzdHJ1Y3QgY3BhX2RhdGEgKmNwYSwgaW50IHByaW1hcnkpCiAJCW5ld19wcm90
ID0gc3RhdGljX3Byb3RlY3Rpb25zKG5ld19wcm90LCBhZGRyZXNzLCBwZm4sIDEsIDAsCiAJ
CQkJCSAgICAgIENQQV9QUk9URUNUKTsKIAotCQluZXdfcHJvdCA9IHZlcmlmeV9yd3gob2xk
X3Byb3QsIG5ld19wcm90LCBhZGRyZXNzLCBwZm4sIDEpOworCQluZXdfcHJvdCA9IHZlcmlm
eV9yd3gob2xkX3Byb3QsIG5ld19wcm90LCBhZGRyZXNzLCBwZm4sIDEsCisJCQkJICAgICAg
bngsIHJ3KTsKIAogCQluZXdfcHJvdCA9IHBncHJvdF9jbGVhcl9wcm90bm9uZV9iaXRzKG5l
d19wcm90KTsKIApkaWZmIC0tZ2l0IGEvYXJjaC94ODYvdmlydC9zdm0vc2V2LmMgYi9hcmNo
L3g4Ni92aXJ0L3N2bS9zZXYuYwppbmRleCBjZmZlMTE1N2E5MGEuLjkxMzFkODBjZmYzNiAx
MDA2NDQKLS0tIGEvYXJjaC94ODYvdmlydC9zdm0vc2V2LmMKKysrIGIvYXJjaC94ODYvdmly
dC9zdm0vc2V2LmMKQEAgLTMzOCwxMiArMzM4LDEzIEBAIHZvaWQgc25wX2R1bXBfaHZhX3Jt
cGVudHJ5KHVuc2lnbmVkIGxvbmcgaHZhKQogewogCXVuc2lnbmVkIGxvbmcgcGFkZHI7CiAJ
dW5zaWduZWQgaW50IGxldmVsOworCWJvb2wgbngsIHJ3OwogCXBnZF90ICpwZ2Q7CiAJcHRl
X3QgKnB0ZTsKIAogCXBnZCA9IF9fdmEocmVhZF9jcjNfcGEoKSk7CiAJcGdkICs9IHBnZF9p
bmRleChodmEpOwotCXB0ZSA9IGxvb2t1cF9hZGRyZXNzX2luX3BnZChwZ2QsIGh2YSwgJmxl
dmVsKTsKKwlwdGUgPSBsb29rdXBfYWRkcmVzc19pbl9wZ2QocGdkLCBodmEsICZsZXZlbCwg
Jm54LCAmcncpOwogCiAJaWYgKCFwdGUpIHsKIAkJcHJfZXJyKCJDYW4ndCBkdW1wIFJNUCBl
bnRyeSBmb3IgSFZBICVseDogbm8gUFRFL1BGTiBmb3VuZFxuIiwgaHZhKTsKLS0gCjIuMzUu
MwoK

--------------4F6hAD70j0NDeDktIIeZUMFE--


From xen-devel-bounces@lists.xenproject.org Thu Mar 28 13:14:26 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 13:14:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698926.1091176 (Exim 4.92)
	(envelope-from )
	id 1rppaH-00089B-JN; Thu, 28 Mar 2024 13:14:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698926.1091176; Thu, 28 Mar 2024 13:14:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rppaH-000894-Gk; Thu, 28 Mar 2024 13:14:21 +0000
Received: by outflank-mailman (input) for mailman id 698926;
 Thu, 28 Mar 2024 13:14:19 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rppaF-00088w-NM
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 13:14:19 +0000
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com
 [2a00:1450:4864:20::632])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1574b679-ed05-11ee-afe3-a90da7624cb6;
 Thu, 28 Mar 2024 14:14:18 +0100 (CET)
Received: by mail-ej1-x632.google.com with SMTP id
 a640c23a62f3a-a2f22bfb4e6so128689766b.0
 for ; Thu, 28 Mar 2024 06:14:18 -0700 (PDT)
Received: from andrewcoop.citrite.net (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 me17-20020a170906aed100b00a46647b6496sm737996ejb.155.2024.03.28.06.14.16
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 28 Mar 2024 06:14:16 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1574b679-ed05-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1711631657; x=1712236457; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:from:to:cc:subject:date:message-id:reply-to;
        bh=DMGPBplkiRRXX5wdqwy6Zf3RtmWugqW2pBxFxW/uVRM=;
        b=QyK0G9C1NlD4HGhuBHbLcua5NzUMvkqK0f4jdsKcYvvGY6gM8jf362nq73pIdPcepe
         C/WuEwQLEu5O3wVB9gpbhG4saKiGUefHmUBXBH/xRMRCjaCIQZs5SjTOuq8D7qr9eb2+
         GTLTPPxMzlnG6NHKlsdHYfRohB4MfhX1js7kw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711631657; x=1712236457;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=DMGPBplkiRRXX5wdqwy6Zf3RtmWugqW2pBxFxW/uVRM=;
        b=pLPC2QdgNrKZFOUuZ1yEGCwUTCSDiyy71YgaRXKcBm6Z/NtNpEF0ge4f3uZlS/ndi3
         Hu9+YNj83JT8Z2MqxaU2MPu4KpOwTQP+ZTlETLis7ygw+7o6krwi1CwdfKUuK++NUMlY
         V/ULqBcKl0vJZQdrVjAFJOFowdNxWcYof31dNdU9ZMylgceld48UpKuJW8Lili2orEKa
         2i96f48OahfAFHcQel25R62pPe9+bwm/SwXwCUlurqyAya1A0icpWfAt/KfhznoVPeUV
         q9xJHl1t6ADIfvAn8WMMhoGZYzzDl8aqhsn+kPMgcAKU7QLdZszTa2rQd0zNmyu0MC3O
         fEPA==
X-Gm-Message-State: AOJu0YxV/oT0k17SUXhbF5ri+3M8Co6bLRqEZYBEsgUzbH4Ci7W++dtI
	u3FxOs0AkwHlRRCETt+RZWJ/6htmCUNakzyUEpCuQWZjABRH04li0Ya3LFE8CHpt0kZfTK0+Vth
	9iYI=
X-Google-Smtp-Source: AGHT+IHey4juqVYw6x5bk9kv+U7qVNzw/VocNImchBSzp2EIByOqn3RvZMKO2fqSsmlIYe9G0qt7kg==
X-Received: by 2002:a17:906:da02:b0:a47:4c82:edb2 with SMTP id fi2-20020a170906da0200b00a474c82edb2mr1620090ejb.5.1711631657549;
        Thu, 28 Mar 2024 06:14:17 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH] x86/spec-ctrl: Move __read_mostly data into __ro_after_init
Date: Thu, 28 Mar 2024 13:14:15 +0000
Message-Id: <20240328131415.1734382-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.30.2
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

These variables predate the introduction of __ro_after_init, but all qualify.
Update them to be consistent with the rest of the file.

No functional change.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
---
 xen/arch/x86/spec_ctrl.c | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
index 0b670c3ca753..6a889db70c52 100644
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -49,18 +49,18 @@ bool __ro_after_init opt_ssbd;
 static int8_t __initdata opt_psfd = -1;
 
 int8_t __ro_after_init opt_ibpb_ctxt_switch = -1;
-int8_t __read_mostly opt_eager_fpu = -1;
-int8_t __read_mostly opt_l1d_flush = -1;
+int8_t __ro_after_init opt_eager_fpu = -1;
+int8_t __ro_after_init opt_l1d_flush = -1;
 static bool __initdata opt_branch_harden =
     IS_ENABLED(CONFIG_SPECULATIVE_HARDEN_BRANCH);
 static bool __initdata opt_lock_harden;
 
 bool __initdata bsp_delay_spec_ctrl;
-uint8_t __read_mostly default_xen_spec_ctrl;
-uint8_t __read_mostly default_spec_ctrl_flags;
+uint8_t __ro_after_init default_xen_spec_ctrl;
+uint8_t __ro_after_init default_spec_ctrl_flags;
 
-paddr_t __read_mostly l1tf_addr_mask, __read_mostly l1tf_safe_maddr;
-bool __read_mostly cpu_has_bug_l1tf;
+paddr_t __ro_after_init l1tf_addr_mask, __ro_after_init l1tf_safe_maddr;
+bool __ro_after_init cpu_has_bug_l1tf;
 static unsigned int __initdata l1d_maxphysaddr;
 
 static bool __initdata cpu_has_bug_msbds_only; /* => minimal HT impact. */
@@ -316,8 +316,8 @@ static int __init cf_check parse_spec_ctrl(const char *s)
 }
 custom_param("spec-ctrl", parse_spec_ctrl);
 
-int8_t __read_mostly opt_xpti_hwdom = -1;
-int8_t __read_mostly opt_xpti_domu = -1;
+int8_t __ro_after_init opt_xpti_hwdom = -1;
+int8_t __ro_after_init opt_xpti_domu = -1;
 
 static __init void xpti_init_default(void)
 {
@@ -381,8 +381,8 @@ static int __init cf_check parse_xpti(const char *s)
 }
 custom_param("xpti", parse_xpti);
 
-int8_t __read_mostly opt_pv_l1tf_hwdom = -1;
-int8_t __read_mostly opt_pv_l1tf_domu = -1;
+int8_t __ro_after_init opt_pv_l1tf_hwdom = -1;
+int8_t __ro_after_init opt_pv_l1tf_domu = -1;
 
 static int __init cf_check parse_pv_l1tf(const char *s)
 {

base-commit: 3c9e76cd875e12c88cfc8f0b2770c525da8d6894
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu Mar 28 13:22:31 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 13:22:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698929.1091187 (Exim 4.92)
	(envelope-from )
	id 1rppi5-0001T7-Di; Thu, 28 Mar 2024 13:22:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698929.1091187; Thu, 28 Mar 2024 13:22:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rppi5-0001T0-9O; Thu, 28 Mar 2024 13:22:25 +0000
Received: by outflank-mailman (input) for mailman id 698929;
 Thu, 28 Mar 2024 13:22:23 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rppi3-0001Su-B3
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 13:22:23 +0000
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com
 [2a00:1450:4864:20::530])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 34f5fb64-ed06-11ee-a1ef-f123f15fe8a2;
 Thu, 28 Mar 2024 14:22:21 +0100 (CET)
Received: by mail-ed1-x530.google.com with SMTP id
 4fb4d7f45d1cf-56c1364ff79so1123810a12.1
 for ; Thu, 28 Mar 2024 06:22:21 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d18-20020a170906305200b00a46a2779475sm747994ejd.101.2024.03.28.06.22.20
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 28 Mar 2024 06:22:20 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 34f5fb64-ed06-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711632141; x=1712236941; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=i3ES/YD6KLu7umQJrMk0Fjm4b3SlVOCp1O4DLrxkmg8=;
        b=ar090khskYyWgUgKgsPEWv+DnDffprLCtbGPlbUeF8aW/O4RhFa+ffuJHFIRoc1UyE
         22UsjI6ppE+9C9B1375fBTG6ExnflZEmxQeCoCtmuvYux2M4/ish4NbFhUF6gOEAlW5N
         ZS2fmERrfhnv9vwlgxVmytPN2+BPk6rXkTqsVFtu85ljMtUhCwnOhJT+okSKbcauqHxW
         j74c4RK+bTJfCiJe04Gzae3h44T9BafrtFbCEpVEAccWsnK48LglOf7zUXMemmqFwUA9
         aGLylwcNZ/F2cxBv8w6GRVM9ZkRSRBF+fiXlBD5A0rHB6ciNpOnpepIEKaVaTFyx16du
         TfoQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711632141; x=1712236941;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=i3ES/YD6KLu7umQJrMk0Fjm4b3SlVOCp1O4DLrxkmg8=;
        b=so+sS/H4/eMbPILXJOjCXLDh7VFCC6C6Fv/STjtmWIvVbmxI5pOT2mOOsF4xDm/JSQ
         iiiRTlQBkD8iwlKnhd9jgO5q5BrfHUcLAIX89s/SWSILOkL71YV3DZ/lguK+a4KFet+r
         aumA823pYA9JKcx+1ANaAgDPU8oKoHMhbJArAh5lho3WKPcQbypHA9HX1Rm573A/PGGm
         vyin85A8q2n3/xmheqGUn02Jha7kImOaczllnkASBokSHLc5/CaHA4NqoeSJh1zB7Pn4
         JoPfBP/XmJmMO/LEBZRHHXz7yzYFXeGVgTXQgjMrKG0A7fGGot/xcmL3A7ehWNoJWA7D
         p+6A==
X-Forwarded-Encrypted: i=1; AJvYcCWEDMgXcFj7FxtwDfjZEmp8snfAWJ5vowLLt5S7dSpBpqj0D2WF5LT9cKuYauFoR232qPq2btBDVrK1ODiZb8+douTpPHvXUsj4MrBT/YA=
X-Gm-Message-State: AOJu0Yw8mvh7QcWVsvk1dFgwZJ0meW5Dc3+lSUedVt2ALyOUIhvklV+x
	t4Hwkzec3Gwr5JvXYu3RoZ7kvzlg9xudxMM8+Scn3he0yVgBjpggcR2KAJdnPA==
X-Google-Smtp-Source: AGHT+IFgy7j1WeYiNlX02YTIgD1Ty+6Pt9Px0rua2wJG+dVUg4Yb5W+kuJVS1amhv3f8j8XpkHDAWQ==
X-Received: by 2002:a17:906:fcb6:b0:a4e:17c5:9944 with SMTP id qw22-20020a170906fcb600b00a4e17c59944mr1570792ejb.61.1711632140830;
        Thu, 28 Mar 2024 06:22:20 -0700 (PDT)
Message-ID: 
Date: Thu, 28 Mar 2024 14:22:19 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/spec-ctrl: Move __read_mostly data into
 __ro_after_init
Content-Language: en-US
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Xen-devel 
References: <20240328131415.1734382-1-andrew.cooper3@citrix.com>
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240328131415.1734382-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 28.03.2024 14:14, Andrew Cooper wrote:
> These variables predate the introduction of __ro_after_init, but all qualify.
> Update them to be consistent with the rest of the file.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 




From xen-devel-bounces@lists.xenproject.org Thu Mar 28 14:59:25 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 14:59:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698942.1091196 (Exim 4.92)
	(envelope-from )
	id 1rprDi-0005Rz-GP; Thu, 28 Mar 2024 14:59:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698942.1091196; Thu, 28 Mar 2024 14:59:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rprDi-0005Rs-Dh; Thu, 28 Mar 2024 14:59:10 +0000
Received: by outflank-mailman (input) for mailman id 698942;
 Thu, 28 Mar 2024 14:59:09 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rprDh-0005Rm-ID
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 14:59:09 +0000
Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com
 [2607:f8b0:4864:20::629])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b8183151-ed13-11ee-a1ef-f123f15fe8a2;
 Thu, 28 Mar 2024 15:59:05 +0100 (CET)
Received: by mail-pl1-x629.google.com with SMTP id
 d9443c01a7336-1e00d1e13acso7838955ad.0
 for ; Thu, 28 Mar 2024 07:59:05 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b8183151-ed13-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1711637944; x=1712242744; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=V/IW0LQiZfxjf4sT101EkPYTcYm9obKSnyKLDKEZzO8=;
        b=G9eOkciILbBoCTkx13KHRG94OoajEhePw4ctN9Vz9IWKwVh5m+HR/icH6UX7riYWAn
         yidZbBKPq3SqhcbhWgLeHdct1VjKRwZjgjHUCuERVktQWSes7gmvqlqhlqhOFN0brVRI
         bFlIZq/rP4L8tX7rUlCFkNf+sRBYsD6sDc76c=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711637944; x=1712242744;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=V/IW0LQiZfxjf4sT101EkPYTcYm9obKSnyKLDKEZzO8=;
        b=cphRtevNQJ/ZLMevljy5LmERsAYaLJdDREAENlVLADJnYtzlP1XgO/HewSTUwsiumz
         TWPbX7DPwhdW68hK3ACIjUU/RCYvaCEEmxLZkFb148hFBNSwkkRO0/aIEzxO2SDleq/6
         /fpi1lz1xHd6JKzmV1AddyHwhTM2O26GjhDWZKxQWjNoyczbpe0vWCD+9R4DLWgPlMCf
         alvDFlDhawxt7by9x3Ii80kFT9KwOG7iFw+PQZUvgNWxPYXCtEV2PfD1KiIWNKvO4fQl
         aQaZHJai0ewvLykowJ+dWUWT56iLWWNYR4/DwTRwb5Q/IRwgCPj281xQ1vnbBYDaNMBE
         u9Gg==
X-Forwarded-Encrypted: i=1; AJvYcCWWK8EXlCf5wKFsDMu1IpZV5G2o1sUn9v+9YkMLQNsAUuzuhOuTcEM4NBm/EIZDCsRDtYJe0ghENlnEBCctJfGzFwtdBq3BvMNTqKeFcHQ=
X-Gm-Message-State: AOJu0Yy1YctlyYwyvpHeQgsoDXq0yZyI01CP8Qgih8Q3vIfEPEl1r58+
	wEbFqaqyZWWAuonTLJuYaYlN42LOxPlQzibG4KXbEHiJZK+rLLoK4ShspbDCMN0irmbjzgGbYk8
	gFysSO7NQF8U+UgAi5pbv5+DJzAO3b+YcmiWA
X-Google-Smtp-Source: AGHT+IEJ6ndaNUOER4Bv0HLkvnP9DfaVgnvpn4S/wsFTnXs9e52eCFILA+X3h5WHn8RvvsD2k2PHJiP/FrnsiyhtFqM=
X-Received: by 2002:a17:902:d48d:b0:1e0:e2a4:1b1b with SMTP id
 c13-20020a170902d48d00b001e0e2a41b1bmr3561877plg.0.1711637943773; Thu, 28 Mar
 2024 07:59:03 -0700 (PDT)
MIME-Version: 1.0
References: <20240313150748.791236-1-ross.lagerwall@citrix.com>
 <20240313150748.791236-4-ross.lagerwall@citrix.com> 
In-Reply-To: 
From: Ross Lagerwall 
Date: Thu, 28 Mar 2024 14:58:52 +0000
Message-ID: 
Subject: Re: [PATCH 3/7] multiboot2: Add support for the load type header tag
To: "Vladimir 'phcoder' Serbinenko" 
Cc: The development of GNU GRUB , xen-devel , 
	Andrew Cooper , Daniel Kiper 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 15, 2024 at 7:31=E2=80=AFAM Vladimir 'phcoder' Serbinenko
 wrote:
>
> Not a full review. Just one blocking problem
>
>>
>>
>>      }
>> +  case MULTIBOOT_LOAD_TYPE_PE:
>> +      grub_fatal ("Unsupported load type: %u\n", mld.load_type);
>> +  default:
>> +    /* should be impossible */
>> +    grub_fatal ("Unknown load type: %u\n", mld.load_type);
>
> Don't use grub_fatal for this. grub_fatal is only when continue to execut=
e grub is unwise. Here you just have an unsupported file. This is definitel=
y a GRUB_ERR_BAD_OS
>

Noted... I'll fix that.

Thanks,
Ross


From xen-devel-bounces@lists.xenproject.org Thu Mar 28 15:06:08 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 15:06:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698944.1091208 (Exim 4.92)
	(envelope-from )
	id 1rprKO-0006ww-74; Thu, 28 Mar 2024 15:06:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698944.1091208; Thu, 28 Mar 2024 15:06:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rprKO-0006wp-2P; Thu, 28 Mar 2024 15:06:04 +0000
Received: by outflank-mailman (input) for mailman id 698944;
 Thu, 28 Mar 2024 15:06:02 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rprKM-0006wj-Ss
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 15:06:02 +0000
Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com
 [2607:f8b0:4864:20::634])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id afc8b6ea-ed14-11ee-a1ef-f123f15fe8a2;
 Thu, 28 Mar 2024 16:06:00 +0100 (CET)
Received: by mail-pl1-x634.google.com with SMTP id
 d9443c01a7336-1e21d1e8307so3614555ad.2
 for ; Thu, 28 Mar 2024 08:06:00 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: afc8b6ea-ed14-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1711638359; x=1712243159; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=/7REdIHOe+En6wvFNrerIGdNSVbHu6MdMdVBnIGdNlA=;
        b=qXLjWHuHvKWlFz7Lmj+ARpcpGFihcEnpSZFnM/2cJIdI3a9d1tGfb7dhWN92B6Lxp5
         kfkOaXH7sW98xHOMflmlMIDCjujdMB61Qi0E5TmJNVGSX7xERlFyO+j1p7A+Fo/1Tqi9
         GA3nST42etjESH5jPEdeVozaXUFQF2zqvc5hg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711638359; x=1712243159;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=/7REdIHOe+En6wvFNrerIGdNSVbHu6MdMdVBnIGdNlA=;
        b=IZRH7Liy57uFMOYS69IHZtDpcxJCc+yhyjeJ/rCVyanh14DFtu0bPK+8hCFoQOedMA
         nTg8Vlj+iHORUV9SQTnDJTvaQdwVJmbv/AiC4N33PyHbnn6rQKzAWuegkuz5yg4rc7Tg
         uWP6UZBFWpwrqsLfwx4cM4na/FSm6oggllPxcsgPjj13ZlgsuZ5poRhpBo7byj3wPUxm
         Yzpi2oSw8iePK0blxCkXpiDjqoMKdjAFAzRo3WiPjXo0zvpWejNF7ua2RlMiJpdIGxkL
         PRHG04TuYhErc/1pvcfE6nc3hlTqlBo5zUdrNnjO0XV6u2JVINzq465QlyxPnVxRK4r/
         9YSA==
X-Forwarded-Encrypted: i=1; AJvYcCU3stpngLV+S3XFYvJNAFg+rsNzaRcVusRXRcaFtiLvJbmaqLq6pxL7VxD6g0fugT2ZYuHvJYxuLLXuUXHxes5CFKckVpymBX9bsks8YRA=
X-Gm-Message-State: AOJu0YyT+pAfNbsHjHjiT6PRhF31hvCLiu/usk1iu5IrTqdr6g9f49Md
	08SMNp4vFp6cLDHGNMW0RDE6ImWR7p8sx2Scvl5ng+wOg1FqAkcA3DnQAcnxE9/DliuT+HBqQSK
	zxdmCtVtVLk9NxPlc49lXM8uHSUq3dHQr09ca
X-Google-Smtp-Source: AGHT+IGvI9UkOFFAsRmdvHTRKgZ0gtGVBFyuXu3T+Ew6jFYGp3QeudPmLyCv/+WaK33QtG8mGzefV5AK21bmWCq221c=
X-Received: by 2002:a17:903:11d1:b0:1e0:f51b:12e2 with SMTP id
 q17-20020a17090311d100b001e0f51b12e2mr3556311plh.2.1711638359254; Thu, 28 Mar
 2024 08:05:59 -0700 (PDT)
MIME-Version: 1.0
References: <20240313150748.791236-1-ross.lagerwall@citrix.com>
 <20240313150748.791236-3-ross.lagerwall@citrix.com> 
In-Reply-To: 
From: Ross Lagerwall 
Date: Thu, 28 Mar 2024 15:05:47 +0000
Message-ID: 
Subject: Re: [PATCH 2/7] multiboot2: Allow 64-bit entry tags
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: grub-devel@gnu.org, xen-devel@lists.xenproject.org, 
	Andrew Cooper , Daniel Kiper 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Mar 19, 2024 at 10:07=E2=80=AFAM Roger Pau Monn=C3=A9  wrote:
>
> On Wed, Mar 13, 2024 at 03:07:43PM +0000, Ross Lagerwall wrote:
> > Binaries may be built with entry points above 4G. While bootloaders may
> > relocate them below 4G, it should be possible for the binary to specify
> > those entry points. Therefore, extend the multiboot2 protocol such that
> > 64 bit addresses are allowed for entry points. The extension is done in
> > a backwards-compatible way.
> >
> > Signed-off-by: Ross Lagerwall 
> > ---
> >  doc/multiboot.texi | 32 +++++++++++++++++++-------------
> >  doc/multiboot2.h   |  6 +++++-
> >  2 files changed, 24 insertions(+), 14 deletions(-)
> >
> > diff --git a/doc/multiboot.texi b/doc/multiboot.texi
> > index d12719c744eb..049afab53c1f 100644
> > --- a/doc/multiboot.texi
> > +++ b/doc/multiboot.texi
> > @@ -522,12 +522,12 @@ header.
> >
> >  @example
> >  @group
> > -        +-------------------+
> > -u16     | type =3D 3          |
> > -u16     | flags             |
> > -u32     | size              |
> > -u32     | entry_addr        |
> > -        +-------------------+
> > +          +-------------------+
> > +u16       | type =3D 3          |
> > +u16       | flags             |
> > +u32       | size              |
> > +u32 / u64 | entry_addr        |
> > +          +-------------------+
>
> I might be confused, but this entry point is used in 32bit protected
> mode, and hence a 64bit value is simply impossible to use according to
> the protocol in "3.3 I386 machine state".
>
> Unless that section is expanded to describe other protocols that use
> the entry address in a way where 64bits could be meaningful it seems
> pointless to expand the field.

I changed this because the same binary is being used for both BIOS boot
and UEFI boot, therefore it may have a base address above 4 GiB.
Despite that, it is expected that GRUB would relocate the binary below
4 GiB so BIOS boot would still work.

However, on reflection this is kind of nasty. I've managed to build Xen
in such a way that this is no longer needed so I can drop this change
from the next version of this series.

Ross


From xen-devel-bounces@lists.xenproject.org Thu Mar 28 15:09:08 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 15:09:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698947.1091217 (Exim 4.92)
	(envelope-from )
	id 1rprNL-0007Wm-JA; Thu, 28 Mar 2024 15:09:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698947.1091217; Thu, 28 Mar 2024 15:09:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rprNL-0007Wf-FP; Thu, 28 Mar 2024 15:09:07 +0000
Received: by outflank-mailman (input) for mailman id 698947;
 Thu, 28 Mar 2024 15:09:06 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rprNK-0007WX-1s
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 15:09:06 +0000
Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com
 [2607:f8b0:4864:20::f35])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1cfad02c-ed15-11ee-a1ef-f123f15fe8a2;
 Thu, 28 Mar 2024 16:09:04 +0100 (CET)
Received: by mail-qv1-xf35.google.com with SMTP id
 6a1803df08f44-696499bd61eso7585436d6.0
 for ; Thu, 28 Mar 2024 08:09:04 -0700 (PDT)
Received: from rossla-lxenia.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 4-20020a0562140d0400b00690bfb6aac7sm722826qvh.51.2024.03.28.08.09.00
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 28 Mar 2024 08:09:01 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1cfad02c-ed15-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1711638542; x=1712243342; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:from:to:cc:subject:date:message-id:reply-to;
        bh=RTkiM6vXFtQFsCu0X4ejO2hYV6vHlc9WzpCQvZsNC4w=;
        b=g+tUxEqI5TjjyrOApQf4gwui4tvZ1wOyM8Ggj4KaOR6XvK5GANAUYx12k15WJ73WF3
         QQxVEqnzCmLJT3j/60X9cRpCuNyMCmvImU+roqIyHEFwtyXOmRAJyKtnLDuFPr9+QsDy
         H4z/if900NIyVXRFZYhBezKj6ZJ8GsZT+NQKk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711638542; x=1712243342;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=RTkiM6vXFtQFsCu0X4ejO2hYV6vHlc9WzpCQvZsNC4w=;
        b=kbn8aKqRjBfarQCzCBFkdQC09P0xAzTpogYeRm+LlQ81XnlMdPCU5ixrZ+O+SdrbiL
         y5dxM3Gk1xo7HHhdmzWzhchRqjOYlIAH74XP2sfN9s+M13iOAdO1fO/y60+B7miOme7V
         gmVr0JC8tGoSCRcd/KN7SrVSlRMshGr271W4hn3zCcy/BAfmZafLERT4RXRlCoN1XtZU
         me2IvJyHonTTHn2hIb1h8/7PueCskLa4bvi8gvA8NYM4jx9O9Sddj6m9kxhTI+77G8Lg
         ztmQyWCjFbFlXi3I4oA/o3yRmyq0CN+1QrlVj9fZpfClykuNqA7HwBQlTQhDiteh6xYU
         MtrQ==
X-Gm-Message-State: AOJu0YxHpdosvOaG6xJCxm5zK1S9DBoN87L76Xi2YxLbSzo8Ycyrj+Q/
	1HKwkonLiQzKeFAgwEZj8gAjcpMHWwxPl91qzLUGDcRwTKEnvBWERRYQZefI+OoXhpMjxm5dZO/
	TgQ==
X-Google-Smtp-Source: AGHT+IH53j3UHtxlBcXfIUmAiCXlmNL2FpfZKgl4bvEiYcHXmk9lQfHTKhaDbj7nh4q7fy+lPvzQ+Q==
X-Received: by 2002:a0c:e805:0:b0:696:8234:3ab with SMTP id y5-20020a0ce805000000b00696823403abmr2707085qvn.49.1711638541872;
        Thu, 28 Mar 2024 08:09:01 -0700 (PDT)
From: Ross Lagerwall 
To: xen-devel@lists.xenproject.org
Cc: Ross Lagerwall ,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	George Dunlap ,
	Julien Grall ,
	Stefano Stabellini 
Subject: [PATCH v2 0/2] x86: Multiboot PE support
Date: Thu, 28 Mar 2024 15:11:04 +0000
Message-ID: <20240328151106.1451104-1-ross.lagerwall@citrix.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Hi,

This patches series implements support for building a multiboot-capable
PE binary in addition to the existing xen.efi and xen.gz. The purpose of
this is to allow the same binary to be booted using BIOS, UEFI, and UEFI
with Secure Boot verification just like it can be done with a Linux
kernel. It also means that it is possible to enable Secure Boot while
still retaining the flexibility of a full bootloader like GRUB2 - not
currently possible when using xen.efi.

This requires a multiboot2 loader that supports loading PE binaries.
Changes to implement this in GRUB will be sent in a separate series.

Ross

Changed in v2:

* Adjusted for changes to the proposed multiboot2 spec changes. In
  particular, there are no new multiboot2 tags needed.
* Unconditionally build a new binary rather than adding a build option.
* Avoid compressing it since this makes verification more difficult.
* Build the new binary as a modification of xen.efi rather than
  relinking from scratch.

Ross Lagerwall (2):
  x86: Add support for building a multiboot2 PE binary
  x86: Call Shim Verify in the multiboot2 path

 .gitignore                        |  2 +
 xen/Makefile                      |  1 +
 xen/arch/x86/Makefile             | 16 ++++++-
 xen/arch/x86/boot/head.S          |  4 +-
 xen/arch/x86/efi/efi-boot.h       | 65 +++++++++++++++++++++++++-
 xen/arch/x86/efi/modify-mbi-exe.c | 77 +++++++++++++++++++++++++++++++
 6 files changed, 162 insertions(+), 3 deletions(-)
 create mode 100644 xen/arch/x86/efi/modify-mbi-exe.c

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Mar 28 15:09:11 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 15:09:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698948.1091227 (Exim 4.92)
	(envelope-from )
	id 1rprNP-0007mZ-Pp; Thu, 28 Mar 2024 15:09:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698948.1091227; Thu, 28 Mar 2024 15:09:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rprNP-0007mS-MT; Thu, 28 Mar 2024 15:09:11 +0000
Received: by outflank-mailman (input) for mailman id 698948;
 Thu, 28 Mar 2024 15:09:09 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rprNN-0007WX-NS
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 15:09:09 +0000
Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com
 [2607:f8b0:4864:20::f35])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1f6a6a98-ed15-11ee-a1ef-f123f15fe8a2;
 Thu, 28 Mar 2024 16:09:07 +0100 (CET)
Received: by mail-qv1-xf35.google.com with SMTP id
 6a1803df08f44-6969388c36fso5311286d6.1
 for ; Thu, 28 Mar 2024 08:09:07 -0700 (PDT)
Received: from rossla-lxenia.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 4-20020a0562140d0400b00690bfb6aac7sm722826qvh.51.2024.03.28.08.09.04
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 28 Mar 2024 08:09:05 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1f6a6a98-ed15-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1711638546; x=1712243346; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=DqdKROOU2Tlw2FDdDoeLuuSjku12CQCqlFzulfX+afo=;
        b=ZrVpU/BQshHpnUpgBn7Kv/mpBmSiTdinC1aVzL5BIUrvM3hWgtFudij8JmXK+Tj+9O
         g3/ZB9837th6Mf5BSh8BSSUFqT6bcqUd5/KPOSbMPkDf1T1/CyQjYo2H3Wve9P1qkrqt
         xxaEKEg80/+uKezrabJuQaUY3/opOBKRKxDhU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711638546; x=1712243346;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=DqdKROOU2Tlw2FDdDoeLuuSjku12CQCqlFzulfX+afo=;
        b=ma6+GuUqvQUyF0+ABwllHSRwT4Diteu2PvmkrUYvM+FzF/Q8WrGiDncByfAZihib96
         W7RJJdXpfGuTS9mhkcFSk3XeQAPlda9uD4pZ5aGfT8HSjRtcJYehCKX8PIj8MILPKcVX
         IYfg5wgzRY0dL3Gt7ElPLIRJEH8vBd4EbKT3spM2kLVBIawE2uOXVFOCQaBT2mXajRy+
         rw6SqOU0hsGu7T9oC4nsT2T2c1epPvcrIm+CkxWDu66wHJ6pAam3JS67mKRTp/HI0B4H
         QcoaukPbtk6ZlC8ChBYouB1J8/0LG5g5hqKueogzdD+HhCbTxyeLsK53rSQp19A8qZE4
         OeoQ==
X-Gm-Message-State: AOJu0Yx9rAxIi7WQfUIfmsbb6lEq9CXwtaEyOk6bEX83F03MNCTY/Cbo
	04TYPxmmKK4Nbiq0Ybzi9PWGl8fZtJtFDcGf6kr6rBNHJB+3Oz6saLvgwouYe8ntPgFGDrtjrja
	pSQ==
X-Google-Smtp-Source: AGHT+IFpeHGSFFVyn1zivBjiDehFXmszTc/WGV7pU0cGNLf/3VWGT+299hCsGHmLBOQrPDisuwMuWg==
X-Received: by 2002:a0c:e0c4:0:b0:696:8525:5c3b with SMTP id x4-20020a0ce0c4000000b0069685255c3bmr3094885qvk.40.1711638546301;
        Thu, 28 Mar 2024 08:09:06 -0700 (PDT)
From: Ross Lagerwall 
To: xen-devel@lists.xenproject.org
Cc: Ross Lagerwall ,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	George Dunlap ,
	Julien Grall ,
	Stefano Stabellini 
Subject: [PATCH v2 1/2] x86: Add support for building a multiboot2 PE binary
Date: Thu, 28 Mar 2024 15:11:05 +0000
Message-ID: <20240328151106.1451104-2-ross.lagerwall@citrix.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20240328151106.1451104-1-ross.lagerwall@citrix.com>
References: <20240328151106.1451104-1-ross.lagerwall@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

In addition to building xen.efi and xen.gz, build xen-mbi.exe. The
latter is a PE binary that can be used with a multiboot2 loader that
supports loading PE binaries.

Using this option allows the binary to be signed and verified by Shim.
This means the same xen-mbi.exe binary can then be used for BIOS boot,
UEFI Boot and UEFI boot with Secure Boot verification (all with the
convenience of GRUB2 as a bootloader).

The new binary is created by modifying xen.efi:
* Relocations are stripped since they are not needed.
* The image base address is set to 0 since it must necessarily be below
  4 GiB and the loader will relocate it anyway.
* The PE entry point is set to the multiboot2 entry point rather than
  the normal EFI entry point. This is only relevant for BIOS boot since
  for EFI boot the entry point is specified via a multiboot2 tag.

Signed-off-by: Ross Lagerwall 
---
 .gitignore                        |  2 +
 xen/Makefile                      |  1 +
 xen/arch/x86/Makefile             | 16 ++++++-
 xen/arch/x86/efi/modify-mbi-exe.c | 77 +++++++++++++++++++++++++++++++
 4 files changed, 95 insertions(+), 1 deletion(-)
 create mode 100644 xen/arch/x86/efi/modify-mbi-exe.c

diff --git a/.gitignore b/.gitignore
index d8b57e32f888..e61acd574b44 100644
--- a/.gitignore
+++ b/.gitignore
@@ -256,6 +256,7 @@ xen/arch/x86/boot/*.lnk
 xen/arch/x86/efi.lds
 xen/arch/x86/efi/check.efi
 xen/arch/x86/efi/mkreloc
+xen/arch/x86/efi/modify-mbi-exe
 xen/arch/x86/include/asm/asm-macros.h
 xen/arch/*/xen.lds
 xen/arch/*/efi/boot.c
@@ -304,6 +305,7 @@ xen/suppression-list.txt
 xen/xen-syms
 xen/xen-syms.map
 xen/xen.*
+xen/xen-mbi.*
 LibVNCServer*
 
 tools/qemu-xen-dir-remote
diff --git a/xen/Makefile b/xen/Makefile
index 21832d640225..1955e1d687df 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -581,6 +581,7 @@ _clean:
 		-o -name ".*.cmd" -o -name "lib.a" \) -exec rm -f {} \;
 	rm -f include/asm $(TARGET) $(TARGET).gz $(TARGET)-syms $(TARGET)-syms.map
 	rm -f $(TARGET).efi $(TARGET).efi.map $(TARGET).efi.elf $(TARGET).efi.stripped
+	rm -f $(TARGET)-mbi.exe
 	rm -f asm-offsets.s arch/*/include/asm/asm-offsets.h
 	rm -f .banner .allconfig.tmp include/xen/compile.h
 	rm -rf $(objtree)/arch/*/include/generated
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 26d87405297b..5b6b8911f1f8 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -86,6 +86,7 @@ extra-y += xen.lds
 
 hostprogs-y += boot/mkelf32
 hostprogs-y += efi/mkreloc
+hostprogs-y += efi/modify-mbi-exe
 
 # Allows usercopy.c to include itself
 $(obj)/usercopy.o: CFLAGS-y += -iquote .
@@ -96,7 +97,7 @@ endif
 
 efi-y := $(shell if [ ! -r $(objtree)/include/xen/compile.h -o \
                       -O $(objtree)/include/xen/compile.h ]; then \
-                         echo '$(TARGET).efi'; fi) \
+                         echo '$(TARGET).efi $(TARGET)-mbi.exe'; fi) \
          $(space)
 efi-$(CONFIG_PV_SHIM_EXCLUSIVE) :=
 
@@ -123,6 +124,19 @@ syms-warn-dup-$(CONFIG_ENFORCE_UNIQUE_SYMBOLS) := --error-dup
 
 orphan-handling-$(call ld-option,--orphan-handling=warn) += --orphan-handling=warn
 
+ifeq ($(XEN_BUILD_PE),y)
+$(TARGET)-mbi.exe: $(TARGET).efi $(obj)/efi/modify-mbi-exe
+	$(OBJCOPY) --remove-section=.reloc $< $@.tmp
+	$(obj)/efi/modify-mbi-exe $@.tmp
+	$(OBJCOPY) --set-start=0x$$($(NM) -pa $@.tmp | awk '/T start$$/{print $$1}') $@.tmp $@.tmp2
+	mv $@.tmp2 $@
+	rm -f $@.tmp
+else
+$(TARGET)-mb.exe: FORCE
+	rm -f $@
+	echo 'PE build not supported'
+endif
+
 $(TARGET): TMP = $(dot-target).elf32
 $(TARGET): $(TARGET)-syms $(efi-y) $(obj)/boot/mkelf32
 	$(obj)/boot/mkelf32 $(notes_phdrs) $(TARGET)-syms $(TMP) $(XEN_IMG_OFFSET) \
diff --git a/xen/arch/x86/efi/modify-mbi-exe.c b/xen/arch/x86/efi/modify-mbi-exe.c
new file mode 100644
index 000000000000..57af382cab4d
--- /dev/null
+++ b/xen/arch/x86/efi/modify-mbi-exe.c
@@ -0,0 +1,77 @@
+#include 
+#include 
+#include 
+#include 
+
+struct mz_hdr {
+    uint16_t signature;
+#define MZ_SIGNATURE 0x5a4d
+    uint16_t last_page_size;
+    uint16_t page_count;
+    uint16_t relocation_count;
+    uint16_t header_paras;
+    uint16_t min_paras;
+    uint16_t max_paras;
+    uint16_t entry_ss;
+    uint16_t entry_sp;
+    uint16_t checksum;
+    uint16_t entry_ip;
+    uint16_t entry_cs;
+    uint16_t relocations;
+    uint16_t overlay;
+    uint8_t reserved[32];
+    uint32_t extended_header_base;
+};
+
+struct coff_hdr {
+    uint32_t signature;
+    uint16_t cpu;
+    uint16_t section_count;
+    int32_t timestamp;
+    uint32_t symbols_file_offset;
+    uint32_t symbol_count;
+    uint16_t opt_hdr_size;
+    uint16_t flags;
+};
+
+#define IMAGE_BASE_OFFSET 48
+#define NEW_IMAGE_BASE 0x0
+
+int main(int argc, char **argv)
+{
+    int fd;
+    struct mz_hdr mz_hdr;
+    const uint64_t base_addr = NEW_IMAGE_BASE;
+
+    if ( argc != 2 )
+    {
+        fprintf(stderr, "usage: %s \n", argv[0]);
+        return 1;
+    }
+
+    fd = open(argv[1], O_RDWR);
+    if ( fd < 0 ||
+         read(fd, &mz_hdr, sizeof(mz_hdr)) != sizeof(mz_hdr) )
+    {
+        perror(argv[1]);
+        return 2;
+    }
+
+    if ( mz_hdr.signature != MZ_SIGNATURE ||
+         !mz_hdr.extended_header_base )
+    {
+        fprintf(stderr, "%s: Wrong DOS file format\n", argv[1]);
+        return 2;
+    }
+
+    if ( lseek(fd, mz_hdr.extended_header_base + IMAGE_BASE_OFFSET, SEEK_SET) < 0 ||
+         write(fd, &base_addr, sizeof(base_addr)) != sizeof(base_addr) )
+    {
+        perror(argv[1]);
+        return 3;
+    }
+
+    close(fd);
+
+    return 0;
+}
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Mar 28 15:09:14 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 15:09:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698949.1091237 (Exim 4.92)
	(envelope-from )
	id 1rprNS-00082Z-1E; Thu, 28 Mar 2024 15:09:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698949.1091237; Thu, 28 Mar 2024 15:09:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rprNR-00082Q-Ud; Thu, 28 Mar 2024 15:09:13 +0000
Received: by outflank-mailman (input) for mailman id 698949;
 Thu, 28 Mar 2024 15:09:12 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rprNQ-0007WX-Tg
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 15:09:12 +0000
Received: from mail-qv1-xf2c.google.com (mail-qv1-xf2c.google.com
 [2607:f8b0:4864:20::f2c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 21682a13-ed15-11ee-a1ef-f123f15fe8a2;
 Thu, 28 Mar 2024 16:09:11 +0100 (CET)
Received: by mail-qv1-xf2c.google.com with SMTP id
 6a1803df08f44-69682bdf1d5so6040366d6.2
 for ; Thu, 28 Mar 2024 08:09:11 -0700 (PDT)
Received: from rossla-lxenia.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 4-20020a0562140d0400b00690bfb6aac7sm722826qvh.51.2024.03.28.08.09.08
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 28 Mar 2024 08:09:08 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 21682a13-ed15-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1711638549; x=1712243349; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=ebxGpBAV+p8Oi5D0bNnjpfaR9Xudz8+PMZfjdeRGehs=;
        b=myWkc8sjKfN09qClXOYi0sqxXBvAUamVYYy04j1b/fXUUI7Xn/FOj40aZ5msGM9FuV
         6WpeeHf211a3qIj82gTgpTLH6dQMb7m9ReRB0p04Qt1c2efPRynGjbVkfIuhelvQDR9D
         1IczmUuYRDAEvcSyXP6S2xEVY4pEGrJ9ilz2s=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711638549; x=1712243349;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=ebxGpBAV+p8Oi5D0bNnjpfaR9Xudz8+PMZfjdeRGehs=;
        b=C0Gb1PK+bNpGglGgcBAwaYp1HrZNLCf5G8vmVpFfku1AA3xwHVbimqZdb+hIDYr8jk
         CBFzuwT8pI/alqwAmdhjwdT1knGRWp1RbC40Ouz4ItNwfRyQAj1dUL4U1lR4XxkxYt/w
         BhJ3SwOd/xpWSC6Q8eo/XAInAW0xYbTVyGCfS5VjLfHenzOjVaWbZtHtES2NSgeoSyXi
         aExnR9pXOeua9yKdO2qI8+onl53qqZCk4kpkvBiX/yxsqS/s/COng7jMlxnEr5UZsOXh
         WLaOrDprRyZP1QNfaLmCDSm8d9u3D49nIXRxRS8zCugBDQIP/eJvC8OXNh4CTp6hcRf9
         5jfQ==
X-Gm-Message-State: AOJu0YyMMuBd7qMOH3082Ml626NaLNGvt2ptvlX0jIUJtGlkEP8ON62X
	AkzFPUT9hh+0++Y1vUe7FaZgQ/OEfwi374q79K3vyQrFN7fw/sqk1EdBzm/27wXHWy8LShsecYu
	vjQ==
X-Google-Smtp-Source: AGHT+IFsKsWKm6RgDqOLDAdGtIAVfjpTZVutmQZOD+xZmcxgA51W/+HOXphe1ATF9EC5abAC08kong==
X-Received: by 2002:a05:6214:9c2:b0:696:b089:9d6c with SMTP id dp2-20020a05621409c200b00696b0899d6cmr2780590qvb.52.1711638549450;
        Thu, 28 Mar 2024 08:09:09 -0700 (PDT)
From: Ross Lagerwall 
To: xen-devel@lists.xenproject.org
Cc: Ross Lagerwall ,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v2 2/2] x86: Call Shim Verify in the multiboot2 path
Date: Thu, 28 Mar 2024 15:11:06 +0000
Message-ID: <20240328151106.1451104-3-ross.lagerwall@citrix.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20240328151106.1451104-1-ross.lagerwall@citrix.com>
References: <20240328151106.1451104-1-ross.lagerwall@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Now that the multiboot2 binary can be verified by Shim, ensure that the
dom0 kernel is verified when using the multiboot2 path. If the Shim
protocol is not available and the SecureBoot variable is not set to 0
(or the state cannot be determined), abort the boot.

Signed-off-by: Ross Lagerwall 
---
 xen/arch/x86/boot/head.S    |  4 ++-
 xen/arch/x86/efi/efi-boot.h | 65 ++++++++++++++++++++++++++++++++++++-
 2 files changed, 67 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index d8ac0f0494db..e03ae19bdafb 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -349,10 +349,12 @@ __efi64_mb2_start:
         /* Keep the stack aligned. Do not pop a single item off it. */
         mov     (%rsp),%rdi
 
+        mov     %rbx, %rcx
+
         /*
          * efi_multiboot2() is called according to System V AMD64 ABI:
          *   - IN:  %rdi - EFI ImageHandle, %rsi - EFI SystemTable,
-         *          %rdx - MB2 cmdline
+         *          %rdx - MB2 cmdline, %rcx - Multiboot information.
          */
         call    efi_multiboot2
 
diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h
index 8ea64e31cdc2..a9569e150e08 100644
--- a/xen/arch/x86/efi/efi-boot.h
+++ b/xen/arch/x86/efi/efi-boot.h
@@ -3,6 +3,7 @@
  * is intended to be included by common/efi/boot.c _only_, and
  * therefore can define arch specific global variables.
  */
+#include 
 #include 
 #include 
 #include 
@@ -808,9 +809,69 @@ static const char *__init get_option(const char *cmd, const char *opt)
     return o;
 }
 
+#define ALIGN_UP(arg, align) \
+                (((arg) + (align) - 1) & ~((typeof(arg))(align) - 1))
+
+static void __init efi_verify_dom0(uint64_t mbi_in)
+{
+    uint64_t ptr;
+    const multiboot2_tag_t *tag;
+    EFI_SHIM_LOCK_PROTOCOL *shim_lock;
+    EFI_STATUS status;
+    const multiboot2_tag_module_t *kernel = NULL;
+    const multiboot2_fixed_t *mbi_fix = _p(mbi_in);
+    static EFI_GUID __initdata shim_lock_guid = SHIM_LOCK_PROTOCOL_GUID;
+    static EFI_GUID __initdata global_variable_guid = EFI_GLOBAL_VARIABLE;
+
+    ptr = ALIGN_UP(mbi_in + sizeof(*mbi_fix), MULTIBOOT2_TAG_ALIGN);
+
+    for ( tag = _p(ptr); (uint64_t)tag - mbi_in < mbi_fix->total_size;
+          tag = _p(ALIGN_UP((uint64_t)tag + tag->size, MULTIBOOT2_TAG_ALIGN)) )
+    {
+        if ( tag->type == MULTIBOOT2_TAG_TYPE_MODULE )
+        {
+            kernel = (const multiboot2_tag_module_t *)tag;
+            break;
+        }
+        else if ( tag->type == MULTIBOOT2_TAG_TYPE_END )
+            break;
+    }
+
+    if ( !kernel )
+        return;
+
+    if ( (status = efi_bs->LocateProtocol(&shim_lock_guid, NULL,
+                                          (void **)&shim_lock)) != EFI_SUCCESS )
+    {
+        UINT32 attr;
+        UINT8 data;
+        UINTN size = sizeof(data);
+
+        status = efi_rs->GetVariable((CHAR16 *)L"SecureBoot", &global_variable_guid,
+                                     &attr, &size, &data);
+        if ( status == EFI_NOT_FOUND )
+            return;
+
+        if ( EFI_ERROR(status) )
+            PrintErrMesg(L"Could not get SecureBoot variable", status);
+
+        if ( attr != (EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_RUNTIME_ACCESS) )
+            PrintErrMesg(L"Unexpected SecureBoot attributes", attr);
+
+        if ( size == 1 && data == 0 )
+            return;
+
+        blexit(L"Could not locate shim but Secure Boot is enabled");
+    }
+
+    if ( (status = shim_lock->Verify(_p(kernel->mod_start),
+                                     kernel->mod_end - kernel->mod_start)) != EFI_SUCCESS )
+        PrintErrMesg(L"Dom0 kernel image could not be verified", status);
+}
+
 void asmlinkage __init efi_multiboot2(EFI_HANDLE ImageHandle,
                                       EFI_SYSTEM_TABLE *SystemTable,
-                                      const char *cmdline)
+                                      const char *cmdline, uint64_t mbi_in)
 {
     EFI_GRAPHICS_OUTPUT_PROTOCOL *gop;
     EFI_HANDLE gop_handle;
@@ -902,6 +963,8 @@ void asmlinkage __init efi_multiboot2(EFI_HANDLE ImageHandle,
 
     efi_relocate_esrt(SystemTable);
 
+    efi_verify_dom0(mbi_in);
+
     efi_exit_boot(ImageHandle, SystemTable);
 }
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Mar 28 15:10:57 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 15:10:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698954.1091247 (Exim 4.92)
	(envelope-from )
	id 1rprP5-0001Xz-G8; Thu, 28 Mar 2024 15:10:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698954.1091247; Thu, 28 Mar 2024 15:10:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rprP5-0001Xs-C0; Thu, 28 Mar 2024 15:10:55 +0000
Received: by outflank-mailman (input) for mailman id 698954;
 Thu, 28 Mar 2024 15:10:54 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rprP4-0001Xk-I8
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 15:10:54 +0000
Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com
 [2607:f8b0:4864:20::829])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5dda0f01-ed15-11ee-a1ef-f123f15fe8a2;
 Thu, 28 Mar 2024 16:10:52 +0100 (CET)
Received: by mail-qt1-x829.google.com with SMTP id
 d75a77b69052e-430acf667afso5448661cf.1
 for ; Thu, 28 Mar 2024 08:10:52 -0700 (PDT)
Received: from rossla-lxenia.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 cr7-20020a05622a428700b004313f54aaa9sm696300qtb.5.2024.03.28.08.10.49
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 28 Mar 2024 08:10:50 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5dda0f01-ed15-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1711638651; x=1712243451; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:from:to:cc:subject:date:message-id:reply-to;
        bh=D7ZTVrLp8nqWSOYziUzeIG369jCymeRAwqlJzMSZjtw=;
        b=eC+S9M3BYMJA/WkVDNzdc+/Rs2Pj5KrrPpNqGU6whYD6OHTUyad2oeERh3THOJjI/7
         Xs5+O8neCIJq0isvSjDqoCxrr0SgYFq3Ds8AGhZtwP1D41HsURF4T7s12dPa3iukq+Ea
         lV8p9b0wFs+2WVZe+2SEy3wfzUOP8GVsqJf+o=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711638651; x=1712243451;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=D7ZTVrLp8nqWSOYziUzeIG369jCymeRAwqlJzMSZjtw=;
        b=IzwMWs76Mamf85LZYZrJH2x8xbtyFKH8v9SVihecgisKMLcCIWEylPvjZ3OIBAAvfZ
         3g3nd155wxROXLfKjtZrWtWYqSvwjILUe66w8xilQtOyGMa0/uXqq068+q0EDtXo4UA7
         h2cncywKC5d09Nal+igKFRJS+wxh2zY70dlQeWvga2mN8ghvJlNmkZ/NDPBcIg2sc5E5
         FFP87tS4IBz/QYBV6M2Ev3elWVkeQtJZp+R+9lv17hGqThFxDK6N5NtranSsQmCZSE6s
         +CBhcZzhCtRUWK5y89uMMJd2LNevhLTXwofYdoLlPdZyWqvHFxvJh+pKszxPePA//BFh
         3uyQ==
X-Gm-Message-State: AOJu0Yxu7TePHI+LPKTLgrr7LYIKUClCIwDxv8q+G+QW4giKYsaxAvyL
	LhWk0POXws5hfaSKhRhEzdzhaNRxBqo5xs/bpM86r89c/VWGuKcApcIWwmTl2A==
X-Google-Smtp-Source: AGHT+IH+f8EDLf9KaL9c0bwJt6k3fppNPjsyLjLixhJayQ1QFvhFrKJAZcpweX+igkrDOrT/SdPcLw==
X-Received: by 2002:ac8:5ac2:0:b0:431:7f86:958f with SMTP id d2-20020ac85ac2000000b004317f86958fmr3650447qtd.8.1711638651543;
        Thu, 28 Mar 2024 08:10:51 -0700 (PDT)
From: Ross Lagerwall 
To: grub-devel@gnu.org
Cc: xen-devel@lists.xenproject.org,
	Ross Lagerwall ,
	Daniel Kiper ,
	Daniel Kiper ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Jan Beulich 
Subject: [PATCH v2 0/3] GRUB: Supporting Secure Boot of xen
Date: Thu, 28 Mar 2024 15:12:59 +0000
Message-ID: <20240328151302.1451158-1-ross.lagerwall@citrix.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

This patch series implements support for loading and verifying a signed
xen binary. This would allow the same xen binary to be used for BIOS
boot, UEFI boot, and UEFI boot with Secure Boot verification.
There is an accompanying Xen patch series.

The first patch updates the multiboot2 specification to allow PE
binaries.

Patch 2 implements the spec change.
Patch 3 allows loading multiboot modules without verification since the
multiboot kernel is expected to verify them if needed.

Ross

Changed in v2:

* Use magic numbers to determine whether to load as ELF or PE rather
  than introducing a load type tag.
* Drop the 64 bit entry address extensions to the protocol - this is no
  longer necessary after some Xen build changes.
* Dropped the patch to allow verification after compression since it is
  not critical to make this work.

Diff stat for patch 1 (to be applied to  the "multiboot2" branch):

Ross Lagerwall (1):
  multiboot2: Add support for the PE binary type

 doc/multiboot.texi | 19 +++++++++++--------
 1 file changed, 11 insertions(+), 8 deletions(-)

Diff stat for patch 2 and 3 (to be applied to the "master" branch):

Ross Lagerwall (2):
  multiboot2: Add PE load support
  efi: Allow loading multiboot modules without verification

 grub-core/Makefile.core.def       |   1 +
 grub-core/kern/efi/sb.c           |   1 +
 grub-core/loader/multiboot.c      |   7 +
 grub-core/loader/multiboot_mbi2.c |  11 +-
 grub-core/loader/multiboot_pe.c   | 702 ++++++++++++++++++++++++++++++
 include/grub/efi/pe32.h           |  64 +++
 include/grub/multiboot.h          |   3 +
 include/grub/multiboot2.h         |   9 +
 8 files changed, 797 insertions(+), 1 deletion(-)
 create mode 100644 grub-core/loader/multiboot_pe.c

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Mar 28 15:10:58 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 15:10:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698955.1091256 (Exim 4.92)
	(envelope-from )
	id 1rprP8-0001nW-MV; Thu, 28 Mar 2024 15:10:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698955.1091256; Thu, 28 Mar 2024 15:10:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rprP8-0001nP-JV; Thu, 28 Mar 2024 15:10:58 +0000
Received: by outflank-mailman (input) for mailman id 698955;
 Thu, 28 Mar 2024 15:10:56 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rprP6-0001mV-Tm
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 15:10:56 +0000
Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com
 [2607:f8b0:4864:20::82a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5fbebd18-ed15-11ee-afe3-a90da7624cb6;
 Thu, 28 Mar 2024 16:10:55 +0100 (CET)
Received: by mail-qt1-x82a.google.com with SMTP id
 d75a77b69052e-43182c2457bso5988011cf.1
 for ; Thu, 28 Mar 2024 08:10:55 -0700 (PDT)
Received: from rossla-lxenia.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 cr7-20020a05622a428700b004313f54aaa9sm696300qtb.5.2024.03.28.08.10.53
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 28 Mar 2024 08:10:54 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5fbebd18-ed15-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1711638654; x=1712243454; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=eq3AT7pXj0vQG5qtRB/nBOWtX8ZshbTnUcp8uTcSupQ=;
        b=hwGu4NMop3eNMtbtnLK9ILrbEElqX41Jnx2wkFsiWenb3v09KJEDiqbC6qpBXbPy+G
         GuMFTyrsIoXDoOmh2uGz1rbtW+gnvH3lXsuc3uTrXXxVi5VWm5W97VssreunDlY/Cw+4
         AKyWbheTlj7I5ZCKxdixf8bzobiMg3BP/PSy4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711638654; x=1712243454;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=eq3AT7pXj0vQG5qtRB/nBOWtX8ZshbTnUcp8uTcSupQ=;
        b=OhLs+FEGLHMRSP/0IwROqe6bmVhjFbCgvdM2NJD2Aken7/ky8IQbqyYiwWuC5EnLnn
         xnf83oFec+ZWPeK6M7Prfh+q8sdNbOnlYOltfjdHhOqPtxht3b/ud2xrWHTyv5rC3cs0
         mil15YW7ypmP5CmpHQ2udQogwIU5v/8ZYgmg91UVT5KSuc1wzx0fAwzEbd6a6WFyqyUX
         9BJ1YbOJe+mqJ6hQwuaPs+MzvGkCbDOkS8AnsZ/RHXuR0yUbZ0kRBfKbyoZHrnu0irBI
         5GYcZDsU6bygG+NJKJ9axvWLrCrv73A1rGtM0mP/KWE+d1Wu0zYSRFh7N2Y2aVe2yTcT
         jgQQ==
X-Gm-Message-State: AOJu0Yxzyb7+wEpwzuT4EfnZRmIeqia8R5ihNycDXaQodZx54NuJhdcf
	n+y/jdGDlENYS5oSfDOlGunIIOFzTMnkBhAKR/HWwOD96scAeLWgAvl/yhgB6w==
X-Google-Smtp-Source: AGHT+IFRiKrVvRemL8kfvC3qN4N8Lcc7JSK3BFibtolaMcbVYPlf+yQnlL6cYNo2NBNzseeKPq4+1w==
X-Received: by 2002:a05:622a:194:b0:432:b960:b10 with SMTP id s20-20020a05622a019400b00432b9600b10mr1205534qtw.60.1711638654610;
        Thu, 28 Mar 2024 08:10:54 -0700 (PDT)
From: Ross Lagerwall 
To: grub-devel@gnu.org
Cc: xen-devel@lists.xenproject.org,
	Ross Lagerwall ,
	Daniel Kiper ,
	Daniel Kiper ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Jan Beulich 
Subject: [PATCH v2 1/3] multiboot2: Add support for the PE binary type
Date: Thu, 28 Mar 2024 15:13:00 +0000
Message-ID: <20240328151302.1451158-2-ross.lagerwall@citrix.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20240328151302.1451158-1-ross.lagerwall@citrix.com>
References: <20240328151302.1451158-1-ross.lagerwall@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Currently, multiboot2-compatible bootloaders can load ELF binaries and
a.out binaries. The presence of the address header tag determines
how the bootloader tries to interpret the binary (a.out if the address
tag is present else ELF).

In addition to the existing address and ELF load types, specify that
boot loaders may optionally support PE binaries as well. This new type
is a useful addition since PE binaries can be signed and verified (i.e.
used with Secure Boot). Boot loaders can distinguish between ELF and PE
binaries using magic numbers since it is not possible for a binary to be
both an ELF and PE binary at the same time.

Signed-off-by: Ross Lagerwall 
---
 doc/multiboot.texi | 19 +++++++++++--------
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/doc/multiboot.texi b/doc/multiboot.texi
index df8a0d056e76..d26c35b54cd4 100644
--- a/doc/multiboot.texi
+++ b/doc/multiboot.texi
@@ -510,12 +510,15 @@ assumes that no bss segment is present.
 @end table
 
 Note: This information does not need to be provided if the kernel image
-is in @sc{elf} format, but it must be provided if the image is in a.out
-format or in some other format. When the address tag is present it must
-be used in order to load the image, regardless of whether an @sc{elf}
-header is also present. Compliant boot loaders must be able to load
-images that are either in @sc{elf} format or contain the address tag
-embedded in the Multiboot2 header.
+is in @sc{elf} or @sc{PE} format, but it must be provided if the image
+is in a.out format or in some other format. When the address tag is
+present it must be used in order to load the image, regardless of
+whether an @sc{elf} or @sc{PE} header is also present. Compliant boot
+loaders must be able to load images that are either in @sc{elf} format
+or contain the address tag embedded in the Multiboot2 header. Compliant
+boot loaders may optionally support loading images in @sc{PE} format.
+When the address tag is not present, the boot loader should use magic
+numbers to identify the type of the image to determine how to load it.
 
 @subsection The entry address tag of Multiboot2 header
 
@@ -565,7 +568,7 @@ start running EFI i386 compatible operating system code.
 
 This tag is taken into account only on EFI i386 platforms
 when Multiboot2 image header contains EFI boot services tag.
-Then entry point specified in ELF header and the entry address
+Then entry point specified in ELF or PE header and the entry address
 tag of Multiboot2 header are ignored.
 
 @subsection EFI amd64 entry address tag of Multiboot2 header
@@ -597,7 +600,7 @@ start running EFI amd64 compatible operating system code.
 
 This tag is taken into account only on EFI amd64 platforms
 when Multiboot2 image header contains EFI boot services tag.
-Then entry point specified in ELF header and the entry address
+Then entry point specified in ELF or PE header and the entry address
 tag of Multiboot2 header are ignored.
 
 @node Console header tags
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Mar 28 15:11:04 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 15:11:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698956.1091267 (Exim 4.92)
	(envelope-from )
	id 1rprPD-000263-Te; Thu, 28 Mar 2024 15:11:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698956.1091267; Thu, 28 Mar 2024 15:11:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rprPD-00025u-Qh; Thu, 28 Mar 2024 15:11:03 +0000
Received: by outflank-mailman (input) for mailman id 698956;
 Thu, 28 Mar 2024 15:11:01 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rprPB-0001mV-OV
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 15:11:01 +0000
Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com
 [2607:f8b0:4864:20::22c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 62123545-ed15-11ee-afe3-a90da7624cb6;
 Thu, 28 Mar 2024 16:10:59 +0100 (CET)
Received: by mail-oi1-x22c.google.com with SMTP id
 5614622812f47-3c3daebabe4so691997b6e.2
 for ; Thu, 28 Mar 2024 08:10:59 -0700 (PDT)
Received: from rossla-lxenia.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 cr7-20020a05622a428700b004313f54aaa9sm696300qtb.5.2024.03.28.08.10.56
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 28 Mar 2024 08:10:57 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 62123545-ed15-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1711638658; x=1712243458; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=G9324KJmT9LrWuNsOI70J8iDdayMGHOlIuajPPrTHQg=;
        b=QhTnawdBpwos6nJaeDRhoX3I0xR7YMKNoc7zAxtzOtOdLTu5j1LPm7NPUddxCtZOl8
         1jTYdYFw5WTJzvcLVqo8sQm1tRJFDzudK5MKE1RIzl1NaKiNxDR+gEHPxmkUsy2LXpdM
         wEUrymLrW46vcfwCNc8AMwOrAGxSdxm33+iMY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711638658; x=1712243458;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=G9324KJmT9LrWuNsOI70J8iDdayMGHOlIuajPPrTHQg=;
        b=t9xKdvbRXnpmN6oAd882vzrtJkqGTV7ZpmKeX3X40c++E2EPRnDthRPSgThubRQxB7
         Ip3XktrMUEBU6BGs0Gmj1JR0FxQDHdjyOpiCEiGDYS+xmOIGbveJ1qFmQJn6jDHEiKgz
         Qdu87uvT0EjVdodY0rYvqrhiOyasRSVE8o0Kk6UxDFxJAYGiGNO/oNPfAa39ilNcZahO
         NFlUzVCPPvk2hUfnezJkP0wFw0xcKvz0+XB0ReKnMogSHhF+vG2WsqLJE8LjszDCG3hR
         upDCKDakAtXpdu22zQE7unDe6JEogQMY+hSoBiTiOhgdGEZv+p00GWe6mn88bc0w0AQz
         oYhg==
X-Gm-Message-State: AOJu0YyL0Vf37gxjMOC9gUb09a1jxwLQI9bUz8NiZ0AWQ76T4vzSnpgT
	CnXPNYSO1uRQ+S//9stuO+1w+u8p+TyO1QwghUdzJxpbndTZD9GQriOgQt/8EA==
X-Google-Smtp-Source: AGHT+IH83M+cutSzSOy7EFKpOqpOFWmoSh7nMpOmiqpACnDM3dbkrJh6cxtOxpbi9ljRH2TasfwM6w==
X-Received: by 2002:a05:6808:291:b0:3c3:d497:b750 with SMTP id z17-20020a056808029100b003c3d497b750mr3064373oic.55.1711638658256;
        Thu, 28 Mar 2024 08:10:58 -0700 (PDT)
From: Ross Lagerwall 
To: grub-devel@gnu.org
Cc: xen-devel@lists.xenproject.org,
	Ross Lagerwall ,
	Daniel Kiper ,
	Daniel Kiper ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v2 2/3] multiboot2: Add PE load support
Date: Thu, 28 Mar 2024 15:13:01 +0000
Message-ID: <20240328151302.1451158-3-ross.lagerwall@citrix.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20240328151302.1451158-1-ross.lagerwall@citrix.com>
References: <20240328151302.1451158-1-ross.lagerwall@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Add the ability to load multiboot binaries in PE format. This allows the
binaries to be signed and verified.

Signed-off-by: Ross Lagerwall 
---
 grub-core/Makefile.core.def       |   1 +
 grub-core/loader/multiboot.c      |   7 +
 grub-core/loader/multiboot_mbi2.c |  11 +-
 grub-core/loader/multiboot_pe.c   | 702 ++++++++++++++++++++++++++++++
 include/grub/efi/pe32.h           |  64 +++
 include/grub/multiboot.h          |   3 +
 include/grub/multiboot2.h         |   9 +
 7 files changed, 796 insertions(+), 1 deletion(-)
 create mode 100644 grub-core/loader/multiboot_pe.c

diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
index 1571421d7e84..34697ba58171 100644
--- a/grub-core/Makefile.core.def
+++ b/grub-core/Makefile.core.def
@@ -1815,6 +1815,7 @@ module = {
 
   common = loader/multiboot.c;
   common = loader/multiboot_mbi2.c;
+  common = loader/multiboot_pe.c;
   enable = x86;
   enable = i386_xen_pvh;
   enable = mips;
diff --git a/grub-core/loader/multiboot.c b/grub-core/loader/multiboot.c
index 94be512c4d0c..8220a74e6f19 100644
--- a/grub-core/loader/multiboot.c
+++ b/grub-core/loader/multiboot.c
@@ -220,6 +220,13 @@ static grub_uint64_t highest_load;
 #include "multiboot_elfxx.c"
 #undef MULTIBOOT_LOAD_ELF32
 
+bool
+GRUB_MULTIBOOT (is_elf) (mbi_load_data_t *mld)
+{
+  return grub_multiboot_is_elf32 (mld->buffer) ||
+         grub_multiboot_is_elf64 (mld->buffer);
+}
+
 /* Load ELF32 or ELF64.  */
 grub_err_t
 GRUB_MULTIBOOT (load_elf) (mbi_load_data_t *mld)
diff --git a/grub-core/loader/multiboot_mbi2.c b/grub-core/loader/multiboot_mbi2.c
index 00a48413c013..601f38161e11 100644
--- a/grub-core/loader/multiboot_mbi2.c
+++ b/grub-core/loader/multiboot_mbi2.c
@@ -349,7 +349,16 @@ grub_multiboot2_load (grub_file_t file, const char *filename)
       mld.file = file;
       mld.filename = filename;
       mld.avoid_efi_boot_services = keep_bs;
-      err = grub_multiboot2_load_elf (&mld);
+      if (grub_multiboot2_is_pe (&mld))
+          err = grub_multiboot2_load_pe (&mld);
+      else if (grub_multiboot2_is_elf (&mld))
+          err = grub_multiboot2_load_elf (&mld);
+      else
+        {
+          grub_free (mld.buffer);
+          return grub_error (GRUB_ERR_UNKNOWN_OS,
+                             "Unknown image type and address tag not specified");
+        }
       if (err)
 	{
 	  grub_free (mld.buffer);
diff --git a/grub-core/loader/multiboot_pe.c b/grub-core/loader/multiboot_pe.c
new file mode 100644
index 000000000000..1c194f89b79c
--- /dev/null
+++ b/grub-core/loader/multiboot_pe.c
@@ -0,0 +1,702 @@
+/*
+ * Significant portions of this code are derived from the Fedora GRUB patch
+ * "0007-Add-secureboot-support-on-efi-chainloader.patch" which is in turn
+ * derived from the PE loading code in Shim. The license is reproduced below:
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ *
+ * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the
+ * distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
+ * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
+ * COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
+ * INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
+ * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
+ * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
+ * OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * Copyright Peter Jones 
+ *
+ * Modifications:
+ *
+ * Copyright (c) 2024. Cloud Software Group, Inc.
+ */
+
+#include 
+#include 
+#include 
+
+static int
+image_is_64_bit (grub_pe_header_t *pe_hdr)
+{
+  /* .Magic is the same offset in all cases */
+  return pe_hdr->pe32plus.optional_header.magic == GRUB_PE32_PE64_MAGIC;
+}
+
+static const grub_uint16_t machine_type __attribute__((__unused__)) =
+#if defined(__x86_64__)
+  GRUB_PE32_MACHINE_X86_64;
+#elif defined(__aarch64__)
+  GRUB_PE32_MACHINE_ARM64;
+#elif defined(__arm__)
+  GRUB_PE32_MACHINE_ARMTHUMB_MIXED;
+#elif defined(__i386__) || defined(__i486__) || defined(__i686__)
+  GRUB_PE32_MACHINE_I386;
+#elif defined(__ia64__)
+  GRUB_PE32_MACHINE_IA64;
+#elif defined(__riscv) && (__riscv_xlen == 32)
+  GRUB_PE32_MACHINE_RISCV32;
+#elif defined(__riscv) && (__riscv_xlen == 64)
+  GRUB_PE32_MACHINE_RISCV64;
+#else
+#error this architecture is not supported by grub2
+#endif
+
+static int
+image_is_loadable(grub_pe_header_t *pe_hdr)
+{
+  /*
+   * Check the machine type matches the binary and that we recognize
+   * the magic number.
+   */
+    return (pe_hdr->pe32.coff_header.machine == machine_type ||
+            (pe_hdr->pe32.coff_header.machine == GRUB_PE32_MACHINE_X86_64 &&
+             machine_type == GRUB_PE32_MACHINE_I386)) &&
+           (pe_hdr->pe32plus.optional_header.magic == GRUB_PE32_PE32_MAGIC ||
+            pe_hdr->pe32plus.optional_header.magic == GRUB_PE32_PE64_MAGIC);
+}
+
+/*
+ * Read the binary header and grab appropriate information from it
+ */
+static grub_err_t
+read_header(void *data, unsigned int datasize,
+            pe_coff_loader_image_context_t *context)
+{
+  grub_pe32_msdos_header_t *dos_hdr = data;
+  grub_pe_header_t *pe_hdr = data;
+  unsigned long header_without_data_dir, section_header_offset, opt_header_size;
+  unsigned long file_alignment = 0;
+
+  if (datasize < sizeof (pe_hdr->pe32))
+    {
+      grub_error (GRUB_ERR_OUT_OF_RANGE, "Invalid image");
+      return GRUB_ERR_OUT_OF_RANGE;
+    }
+
+  if (dos_hdr->e_magic == GRUB_PE32_MAGIC)
+    pe_hdr = (grub_pe_header_t *)((char *)data + dos_hdr->e_lfanew);
+
+  if (!image_is_loadable(pe_hdr))
+    {
+      grub_error (GRUB_ERR_NOT_IMPLEMENTED_YET, "Platform does not support this image");
+      return GRUB_ERR_NOT_IMPLEMENTED_YET;
+    }
+
+  if (image_is_64_bit(pe_hdr))
+    {
+      context->number_of_rva_and_sizes = pe_hdr->pe32plus.optional_header.num_data_directories;
+      context->size_of_headers = pe_hdr->pe32plus.optional_header.header_size;
+      context->image_size = pe_hdr->pe32plus.optional_header.image_size;
+      context->section_alignment = pe_hdr->pe32plus.optional_header.section_alignment;
+      file_alignment = pe_hdr->pe32plus.optional_header.file_alignment;
+      opt_header_size = sizeof(struct grub_pe64_optional_header);
+    }
+  else
+    {
+      context->number_of_rva_and_sizes = pe_hdr->pe32.optional_header.num_data_directories;
+      context->size_of_headers = pe_hdr->pe32.optional_header.header_size;
+      context->image_size = (grub_uint64_t)pe_hdr->pe32.optional_header.image_size;
+      context->section_alignment = pe_hdr->pe32.optional_header.section_alignment;
+      file_alignment = pe_hdr->pe32.optional_header.file_alignment;
+      opt_header_size = sizeof(struct grub_pe32_optional_header);
+    }
+
+  if (file_alignment % 2 != 0)
+    {
+      grub_error (GRUB_ERR_OUT_OF_RANGE, "File Alignment is invalid (%ld)", file_alignment);
+      return GRUB_ERR_OUT_OF_RANGE;
+    }
+  if (file_alignment == 0)
+    file_alignment = 0x200;
+  if (context->section_alignment == 0)
+    context->section_alignment = GRUB_EFI_PAGE_SIZE;
+  if (context->section_alignment < file_alignment)
+    context->section_alignment = file_alignment;
+
+  context->number_of_sections = pe_hdr->pe32.coff_header.num_sections;
+
+  if (EFI_IMAGE_NUMBER_OF_DIRECTORY_ENTRIES < context->number_of_rva_and_sizes)
+    {
+      grub_error (GRUB_ERR_OUT_OF_RANGE, "Image header too small");
+      return GRUB_ERR_OUT_OF_RANGE;
+    }
+
+  header_without_data_dir = opt_header_size
+                  - sizeof (struct grub_pe32_data_directory) * EFI_IMAGE_NUMBER_OF_DIRECTORY_ENTRIES;
+  if (((grub_uint32_t)pe_hdr->pe32.coff_header.optional_header_size - header_without_data_dir) !=
+                  context->number_of_rva_and_sizes * sizeof (struct grub_pe32_data_directory))
+    {
+      grub_error (GRUB_ERR_OUT_OF_RANGE, "Image header overflows data directory");
+      return GRUB_ERR_OUT_OF_RANGE;
+    }
+
+  section_header_offset = dos_hdr->e_lfanew
+                          + sizeof (grub_uint32_t)
+                          + sizeof (struct grub_pe32_coff_header)
+                          + pe_hdr->pe32.coff_header.optional_header_size;
+  if (((grub_uint32_t)context->image_size - section_header_offset) / sizeof(struct grub_pe32_section_table)
+                  <= context->number_of_sections)
+    {
+      grub_error (GRUB_ERR_OUT_OF_RANGE, "Image sections overflow image size");
+      return GRUB_ERR_OUT_OF_RANGE;
+    }
+
+  if ((context->size_of_headers - section_header_offset) / sizeof(struct grub_pe32_section_table)
+                  < (grub_uint32_t)context->number_of_sections)
+    {
+      grub_error (GRUB_ERR_OUT_OF_RANGE, "Image sections overflow section headers");
+      return GRUB_ERR_OUT_OF_RANGE;
+    }
+
+  if ((((grub_uint8_t *)pe_hdr - (grub_uint8_t *)data) + sizeof(grub_pe_header_t)) > datasize)
+    {
+      grub_error (GRUB_ERR_OUT_OF_RANGE, "Invalid image");
+      return GRUB_ERR_OUT_OF_RANGE;
+    }
+
+  if (pe_hdr->pe32.signature[0] != 'P' ||
+              pe_hdr->pe32.signature[1] != 'E' ||
+              pe_hdr->pe32.signature[2] != 0x00 ||
+              pe_hdr->pe32.signature[3] != 0x00)
+    {
+      grub_error (GRUB_ERR_NOT_IMPLEMENTED_YET, "Unsupported image type");
+      return GRUB_ERR_NOT_IMPLEMENTED_YET;
+    }
+
+  context->pe_hdr = pe_hdr;
+
+  if (image_is_64_bit(pe_hdr))
+    {
+      context->image_address = pe_hdr->pe32plus.optional_header.image_base;
+      context->entry_point = pe_hdr->pe32plus.optional_header.entry_addr;
+      context->reloc_dir = &pe_hdr->pe32plus.optional_header.base_relocation_table;
+      context->sec_dir = &pe_hdr->pe32plus.optional_header.certificate_table;
+    }
+  else
+    {
+      context->image_address = pe_hdr->pe32.optional_header.image_base;
+      context->entry_point = pe_hdr->pe32.optional_header.entry_addr;
+      context->reloc_dir = &pe_hdr->pe32.optional_header.base_relocation_table;
+      context->sec_dir = &pe_hdr->pe32.optional_header.certificate_table;
+    }
+
+  context->first_section = (struct grub_pe32_section_table *)((char *)pe_hdr +
+          pe_hdr->pe32.coff_header.optional_header_size +
+          sizeof(grub_uint32_t) + sizeof(struct grub_pe32_coff_header));
+
+  if (context->image_size < context->size_of_headers)
+    {
+      grub_error (GRUB_ERR_OUT_OF_RANGE, "Invalid image");
+      return GRUB_ERR_OUT_OF_RANGE;
+    }
+
+  if ((unsigned long)((grub_uint8_t *)context->sec_dir - (grub_uint8_t *)data) >
+      (datasize - sizeof(struct grub_pe32_data_directory)))
+    {
+      grub_error (GRUB_ERR_OUT_OF_RANGE, "Invalid image");
+      return GRUB_ERR_OUT_OF_RANGE;
+    }
+  return GRUB_ERR_NONE;
+}
+
+static grub_phys_addr_t
+image_address (grub_phys_addr_t image, grub_uint64_t sz, grub_uint64_t addr)
+{
+  if (addr > sz)
+    return 0;
+
+  return image + addr;
+}
+
+static grub_err_t
+relocate_coff (pe_coff_loader_image_context_t *context,
+               struct grub_pe32_section_table *section,
+               grub_phys_addr_t phys_addr, grub_uint8_t *virt_addr,
+               mbi_load_data_t *mld)
+{
+  struct grub_pe32_data_directory *reloc_base, *reloc_base_end;
+  grub_uint8_t *reloc_buffer;
+  grub_uint64_t adjust;
+  struct grub_pe32_fixup_block *reloc, *reloc_end;
+  grub_uint8_t *fixup, *fixup_base;
+  grub_uint16_t *fixup_16;
+  grub_uint32_t *fixup_32;
+  grub_uint64_t *fixup_64;
+  int n = 0;
+  grub_err_t ret = GRUB_ERR_NONE;
+
+  if (image_is_64_bit (context->pe_hdr))
+    context->pe_hdr->pe32plus.optional_header.image_base =
+      (grub_uint64_t)(unsigned long)phys_addr;
+  else
+    context->pe_hdr->pe32.optional_header.image_base =
+      (grub_uint32_t)(unsigned long)phys_addr;
+
+  /* Alright, so here's how this works:
+   *
+   * context->reloc_dir gives us two things:
+   * - the VA the table of base relocation blocks are (maybe) to be
+   *   mapped at (reloc_dir->rva)
+   * - the virtual size (reloc_dir->size)
+   *
+   * The .reloc section (section here) gives us some other things:
+   * - the name! kind of. (section->name)
+   * - the virtual size (section->virtual_size), which should be the same
+   *   as RelocDir->Size
+   * - the virtual address (section->virtual_address)
+   * - the file section size (section->raw_data_size), which is
+   *   a multiple of optional_header->file_alignment.  Only useful for image
+   *   validation, not really useful for iteration bounds.
+   * - the file address (section->raw_data_offset)
+   * - a bunch of stuff we don't use that's 0 in our binaries usually
+   * - Flags (section->characteristics)
+   *
+   * and then the thing that's actually at the file address is an array
+   * of struct grub_pe32_fixup_block structs with some values packed behind
+   * them.  The block_size field of this structure includes the
+   * structure itself, and adding it to that structure's address will
+   * yield the next entry in the array.
+   */
+
+  reloc_buffer = grub_malloc (section->virtual_size);
+  if (!reloc_buffer)
+      return grub_errno;
+
+  if (grub_file_seek (mld->file, section->raw_data_offset) == (grub_off_t) -1)
+    {
+      ret = grub_errno;
+      goto out;
+    }
+
+  if (grub_file_read (mld->file, reloc_buffer, section->virtual_size)
+      != (grub_ssize_t) section->virtual_size)
+    {
+      if (!grub_errno)
+        {
+          grub_error (GRUB_ERR_FILE_READ_ERROR, "premature end of file %s",
+                      mld->filename);
+          ret = GRUB_ERR_FILE_READ_ERROR;
+        }
+      else
+          ret = grub_errno;
+      goto out;
+    }
+
+  reloc_base = (struct grub_pe32_data_directory *)reloc_buffer;
+  reloc_base_end = (struct grub_pe32_data_directory *)(reloc_buffer + section->virtual_size);
+
+  grub_dprintf ("multiboot_loader", "relocate_coff(): reloc_base %p reloc_base_end %p\n",
+                reloc_base, reloc_base_end);
+
+  if (!reloc_base && !reloc_base_end)
+    return GRUB_ERR_NONE;
+
+  if (!reloc_base || !reloc_base_end)
+    {
+      grub_error (GRUB_ERR_BAD_ARGUMENT, "Reloc table overflows binary");
+      return GRUB_ERR_BAD_ARGUMENT;
+    }
+
+  adjust = (grub_uint64_t)(grub_efi_uintn_t)phys_addr - context->image_address;
+  if (adjust == 0)
+    return GRUB_ERR_NONE;
+
+  while (reloc_base < reloc_base_end)
+    {
+      grub_uint16_t *entry;
+      reloc = (struct grub_pe32_fixup_block *)((char*)reloc_base);
+
+      if ((reloc_base->size == 0) ||
+          (reloc_base->size > context->reloc_dir->size))
+        {
+          grub_error (GRUB_ERR_BAD_ARGUMENT,
+                      "Reloc %d block size %d is invalid\n", n,
+                      reloc_base->size);
+          ret = GRUB_ERR_BAD_ARGUMENT;
+          goto out;
+        }
+
+      entry = &reloc->entries[0];
+      reloc_end = (struct grub_pe32_fixup_block *)
+        ((char *)reloc_base + reloc_base->size);
+
+      if ((grub_uint8_t *)reloc_end < reloc_buffer ||
+          (grub_uint8_t *)reloc_end > (reloc_buffer + section->virtual_size))
+        {
+          grub_error (GRUB_ERR_BAD_ARGUMENT, "Reloc entry %d overflows binary",
+                      n);
+          return GRUB_ERR_BAD_ARGUMENT;
+        }
+
+      fixup_base = virt_addr + reloc_base->rva;
+      if (!fixup_base)
+        {
+          grub_error (GRUB_ERR_BAD_ARGUMENT, "Reloc %d Invalid fixupbase", n);
+          ret = GRUB_ERR_BAD_ARGUMENT;
+          goto out;
+        }
+
+      while ((void *)entry < (void *)reloc_end)
+        {
+          fixup = fixup_base + (*entry & 0xFFF);
+          switch ((*entry) >> 12)
+            {
+              case GRUB_PE32_REL_BASED_ABSOLUTE:
+                break;
+              case GRUB_PE32_REL_BASED_HIGH:
+                fixup_16 = (grub_uint16_t *)fixup;
+                *fixup_16 = (grub_uint16_t)
+                  (*fixup_16 + ((grub_uint16_t)((grub_uint32_t)adjust >> 16)));
+                break;
+              case GRUB_PE32_REL_BASED_LOW:
+                fixup_16 = (grub_uint16_t *)fixup;
+                *fixup_16 = (grub_uint16_t) (*fixup_16 + (grub_uint16_t)adjust);
+                break;
+              case GRUB_PE32_REL_BASED_HIGHLOW:
+                fixup_32 = (grub_uint32_t *)fixup;
+                *fixup_32 = *fixup_32 + (grub_uint32_t)adjust;
+                break;
+              case GRUB_PE32_REL_BASED_DIR64:
+                fixup_64 = (grub_uint64_t *)fixup;
+                *fixup_64 = *fixup_64 + (grub_uint64_t)adjust;
+                break;
+              default:
+                grub_error (GRUB_ERR_BAD_ARGUMENT,
+                            "Reloc %d unknown relocation type %d",
+                            n, (*entry) >> 12);
+                ret = GRUB_ERR_BAD_ARGUMENT;
+                goto out;
+            }
+          entry += 1;
+        }
+      reloc_base = (struct grub_pe32_data_directory *)reloc_end;
+      n++;
+    }
+
+out:
+  grub_free(reloc_buffer);
+
+  return ret;
+}
+
+grub_err_t
+grub_multiboot2_load_pe (mbi_load_data_t *mld)
+{
+  int i;
+  grub_uint8_t *virt_addr;
+  grub_phys_addr_t phys_addr, reloc_base, reloc_base_end, base, end;
+  struct grub_pe32_section_table *reloc_section = NULL, fake_reloc_section;
+  struct grub_pe32_section_table *section;
+  grub_relocator_chunk_t ch;
+  pe_coff_loader_image_context_t context;
+  grub_err_t ret = GRUB_ERR_NONE;
+  grub_uint32_t section_alignment;
+  int found_entry_point = 0;
+
+  ret = read_header(mld->buffer, MULTIBOOT_SEARCH, &context);
+  if (ret)
+      return ret;
+
+  /*
+   * The spec says, uselessly, of SectionAlignment:
+   * =====
+   * The alignment (in bytes) of sections when they are loaded into
+   * memory. It must be greater than or equal to FileAlignment. The
+   * default is the page size for the architecture.
+   * =====
+   * Which doesn't tell you whose responsibility it is to enforce the
+   * "default", or when.  It implies that the value in the field must
+   * be > FileAlignment (also poorly defined), but it appears visual
+   * studio will happily write 512 for FileAlignment (its default) and
+   * 0 for SectionAlignment, intending to imply PAGE_SIZE.
+   *
+   * We only support one page size, so if it's zero, nerf it to 4096.
+   */
+  section_alignment = context.section_alignment;
+  if (section_alignment == 0)
+    section_alignment = 4096;
+
+  section_alignment = grub_max(section_alignment, mld->align);
+
+  ret = grub_relocator_alloc_chunk_align_safe (grub_multiboot2_relocator, &ch,
+                                               mld->min_addr, mld->max_addr,
+                                               context.image_size, section_alignment,
+                                               mld->preference, mld->avoid_efi_boot_services);
+
+  if (ret)
+    {
+      grub_dprintf ("multiboot_loader", "Cannot allocate memory for OS image\n");
+      return ret;
+    }
+
+  virt_addr = get_virtual_current_address (ch);
+  phys_addr = get_physical_target_address (ch);
+
+  if (grub_file_seek (mld->file, 0) == (grub_off_t) -1) {
+      ret = grub_errno;
+      goto out;
+  }
+
+  if (grub_file_read (mld->file, virt_addr, context.size_of_headers)
+      != (grub_ssize_t) context.size_of_headers)
+    {
+      if (!grub_errno)
+        {
+          grub_error (GRUB_ERR_FILE_READ_ERROR, "premature end of file %s",
+                      mld->filename);
+          ret = GRUB_ERR_FILE_READ_ERROR;
+        }
+      else
+          ret = grub_errno;
+      goto out;
+    }
+
+  mld->load_base_addr = phys_addr;
+  mld->link_base_addr = context.image_address;
+
+  grub_dprintf ("multiboot_loader", "load_base_addr: 0x%08x link_base_addr 0x%08x\n",
+                mld->load_base_addr, mld->link_base_addr);
+
+  grub_multiboot2_payload_eip = context.entry_point;
+  grub_dprintf ("multiboot_loader", "entry_point: 0x%08x\n", grub_multiboot2_payload_eip);
+  if (!grub_multiboot2_payload_eip)
+    {
+      grub_error (GRUB_ERR_BAD_ARGUMENT, "invalid entry point");
+      ret = GRUB_ERR_BAD_ARGUMENT;
+      goto out;
+    }
+
+  grub_dprintf ("multiboot_loader", "reloc_dir: %p reloc_size: 0x%08x\n",
+                (void *)(unsigned long)context.reloc_dir->rva,
+                context.reloc_dir->size);
+  reloc_base = image_address (phys_addr, context.image_size,
+                              context.reloc_dir->rva);
+  /* RelocBaseEnd here is the address of the last byte of the table */
+  reloc_base_end = image_address (phys_addr, context.image_size,
+                                  context.reloc_dir->rva
+                                  + context.reloc_dir->size - 1);
+  grub_dprintf ("multiboot_loader", "reloc_base: 0x%016lx reloc_base_end: 0x%016lx\n",
+                reloc_base, reloc_base_end);
+
+  section = context.first_section;
+  for (i = 0; i < context.number_of_sections; i++, section++)
+    {
+      char name[9];
+
+      base = image_address (phys_addr, context.image_size,
+                            section->virtual_address);
+      end = image_address (phys_addr, context.image_size,
+                           section->virtual_address + section->virtual_size -1);
+
+      grub_strncpy(name, section->name, 9);
+      name[8] = '\0';
+      grub_dprintf ("multiboot_loader", "Section %d \"%s\" at 0x%016lx..0x%016lx\n", i,
+                   name, base, end);
+
+      if (end < base)
+        {
+          grub_dprintf ("multiboot_loader", " base is 0x%016lx but end is 0x%016lx... bad.\n",
+                       base, end);
+          grub_error (GRUB_ERR_BAD_ARGUMENT,
+                      "Image has invalid negative size");
+          ret = GRUB_ERR_BAD_ARGUMENT;
+          goto out;
+        }
+
+      if (section->virtual_address <= context.entry_point &&
+          (section->virtual_address + section->raw_data_size - 1)
+          > context.entry_point)
+        {
+          found_entry_point++;
+          grub_dprintf ("multiboot_loader", " section contains entry point\n");
+        }
+
+      /* We do want to process .reloc, but it's often marked
+       * discardable, so we don't want to memcpy it. */
+      if (grub_memcmp (section->name, ".reloc\0\0", 8) == 0)
+        {
+          if (reloc_section)
+            {
+              grub_error (GRUB_ERR_BAD_ARGUMENT,
+                          "Image has multiple relocation sections");
+              ret = GRUB_ERR_BAD_ARGUMENT;
+              goto out;
+            }
+
+          /* If it has nonzero sizes, and our bounds check
+           * made sense, and the VA and size match RelocDir's
+           * versions, then we believe in this section table. */
+          if (section->raw_data_size && section->virtual_size &&
+              base && end && reloc_base == base)
+            {
+              if (reloc_base_end == end)
+                {
+                  grub_dprintf ("multiboot_loader", " section is relocation section\n");
+                  reloc_section = section;
+                }
+              else if (reloc_base_end && reloc_base_end < end)
+                {
+                  /* Bogus virtual size in the reloc section -- RelocDir
+                   * reported a smaller Base Relocation Directory. Decrease
+                   * the section's virtual size so that it equal RelocDir's
+                   * idea, but only for the purposes of relocate_coff(). */
+                  grub_dprintf ("multiboot_loader",
+                                " section is (overlong) relocation section\n");
+                  grub_memcpy (&fake_reloc_section, section, sizeof *section);
+                  fake_reloc_section.virtual_size -= (end - reloc_base_end);
+                  reloc_section = &fake_reloc_section;
+                }
+            }
+
+          if (!reloc_section)
+            {
+              grub_dprintf ("multiboot_loader", " section is not reloc section?\n");
+              grub_dprintf ("multiboot_loader", " rds: 0x%08x, vs: %08x\n",
+                            section->raw_data_size, section->virtual_size);
+              grub_dprintf ("multiboot_loader", " base: 0x%016lx end: 0x%016lx\n", base, end);
+              grub_dprintf ("multiboot_loader", " reloc_base: 0x%016lx reloc_base_end: 0x%016lx\n",
+                            reloc_base, reloc_base_end);
+            }
+        }
+
+      grub_dprintf ("multiboot_loader", " Section characteristics are %08x\n",
+                   section->characteristics);
+      grub_dprintf ("multiboot_loader", " Section virtual size: %08x\n",
+                   section->virtual_size);
+      grub_dprintf ("multiboot_loader", " Section raw_data size: %08x\n",
+                   section->raw_data_size);
+      if (section->characteristics & GRUB_PE32_SCN_MEM_DISCARDABLE)
+        {
+          grub_dprintf ("multiboot_loader", " Discarding section\n");
+          continue;
+        }
+
+      if (!base || !end)
+        {
+          grub_dprintf ("multiboot_loader", " section is invalid\n");
+          grub_error (GRUB_ERR_BAD_ARGUMENT, "Invalid section size");
+          ret = GRUB_ERR_BAD_ARGUMENT;
+          goto out;
+        }
+
+      if (section->characteristics & GRUB_PE32_SCN_CNT_UNINITIALIZED_DATA)
+        {
+          if (section->raw_data_size != 0)
+            grub_dprintf ("multiboot_loader", " UNINITIALIZED_DATA section has data?\n");
+        }
+      else if (section->virtual_address < context.size_of_headers ||
+               section->raw_data_offset < context.size_of_headers)
+        {
+          grub_error (GRUB_ERR_BAD_ARGUMENT,
+                      "Section %d is inside image headers", i);
+          ret = GRUB_ERR_BAD_ARGUMENT;
+          goto out;
+        }
+
+      if (section->raw_data_size > 0)
+        {
+          grub_dprintf ("multiboot_loader", " copying 0x%08x bytes to 0x%016lx\n",
+                        section->raw_data_size, base);
+
+          if (grub_file_seek (mld->file, section->raw_data_offset) == (grub_off_t) -1)
+            {
+              ret = grub_errno;
+              goto out;
+            }
+
+          if (grub_file_read (mld->file, virt_addr + (base - phys_addr), section->raw_data_size)
+              != (grub_ssize_t) section->raw_data_size)
+            {
+              if (!grub_errno)
+                {
+                  grub_error (GRUB_ERR_FILE_READ_ERROR, "premature end of file %s",
+                              mld->filename);
+                  ret = GRUB_ERR_FILE_READ_ERROR;
+                }
+              else
+                  ret = grub_errno;
+              goto out;
+            }
+        }
+
+      if (section->raw_data_size < section->virtual_size)
+        {
+          grub_dprintf ("multiboot_loader", " padding with 0x%08x bytes at 0x%016lx\n",
+                        section->virtual_size - section->raw_data_size,
+                        base + section->raw_data_size);
+          grub_memset (virt_addr + (base - phys_addr) + section->raw_data_size, 0,
+                       section->virtual_size - section->raw_data_size);
+        }
+
+      grub_dprintf ("multiboot_loader", " finished section %s\n", name);
+    }
+
+  /* 5 == EFI_IMAGE_DIRECTORY_ENTRY_BASERELOC */
+  if (context.number_of_rva_and_sizes <= 5)
+    {
+      grub_error (GRUB_ERR_BAD_ARGUMENT, "image has no relocation entry\n");
+      ret = GRUB_ERR_BAD_ARGUMENT;
+      goto out;
+    }
+
+  if (context.reloc_dir->size && reloc_section)
+    {
+      /* run the relocation fixups */
+      ret = relocate_coff (&context, reloc_section, phys_addr, virt_addr, mld);
+
+      if (ret)
+        {
+          grub_error (GRUB_ERR_BAD_ARGUMENT, "relocation failed");
+          goto out;
+        }
+    }
+
+  if (!found_entry_point)
+    {
+      grub_error (GRUB_ERR_BAD_ARGUMENT, "entry point is not within sections");
+      ret = GRUB_ERR_BAD_ARGUMENT;
+      goto out;
+    }
+  if (found_entry_point > 1)
+    {
+      grub_error (GRUB_ERR_BAD_ARGUMENT, "%d sections contain entry point",
+                  found_entry_point);
+      ret = GRUB_ERR_BAD_ARGUMENT;
+      goto out;
+    }
+
+out:
+  return ret;
+}
+
+bool
+grub_multiboot2_is_pe (mbi_load_data_t *mld)
+{
+  grub_pe32_msdos_header_t *dos_hdr = mld->buffer;
+
+  return dos_hdr->e_magic == GRUB_PE32_MAGIC;
+}
diff --git a/include/grub/efi/pe32.h b/include/grub/efi/pe32.h
index 4e6e9d254bd3..2c8f7c3b85a5 100644
--- a/include/grub/efi/pe32.h
+++ b/include/grub/efi/pe32.h
@@ -20,6 +20,7 @@
 #define GRUB_EFI_PE32_HEADER	1
 
 #include 
+#include 
 #include 
 
 /* The MSDOS compatibility stub. This was copied from the output of
@@ -46,6 +47,28 @@
 
 #define GRUB_PE32_MSDOS_STUB_SIZE	0x80
 
+typedef struct {
+  grub_uint16_t  e_magic;    ///< Magic number.
+  grub_uint16_t  e_cblp;     ///< Bytes on last page of file.
+  grub_uint16_t  e_cp;       ///< Pages in file.
+  grub_uint16_t  e_crlc;     ///< Relocations.
+  grub_uint16_t  e_cparhdr;  ///< Size of header in paragraphs.
+  grub_uint16_t  e_minalloc; ///< Minimum extra paragraphs needed.
+  grub_uint16_t  e_maxalloc; ///< Maximum extra paragraphs needed.
+  grub_uint16_t  e_ss;       ///< Initial (relative) SS value.
+  grub_uint16_t  e_sp;       ///< Initial SP value.
+  grub_uint16_t  e_csum;     ///< Checksum.
+  grub_uint16_t  e_ip;       ///< Initial IP value.
+  grub_uint16_t  e_cs;       ///< Initial (relative) CS value.
+  grub_uint16_t  e_lfarlc;   ///< File address of relocation table.
+  grub_uint16_t  e_ovno;     ///< Overlay number.
+  grub_uint16_t  e_res[4];   ///< Reserved words.
+  grub_uint16_t  e_oemid;    ///< OEM identifier (for e_oeminfo).
+  grub_uint16_t  e_oeminfo;  ///< OEM information; e_oemid specific.
+  grub_uint16_t  e_res2[10]; ///< Reserved words.
+  grub_uint32_t  e_lfanew;   ///< File address of new exe header.
+} grub_pe32_msdos_header_t;
+
 #define GRUB_PE32_MAGIC			0x5a4d
 
 struct grub_msdos_image_header
@@ -249,6 +272,7 @@ struct grub_pe32_section_table
 
 #define GRUB_PE32_SCN_CNT_CODE			0x00000020
 #define GRUB_PE32_SCN_CNT_INITIALIZED_DATA	0x00000040
+#define GRUB_PE32_SCN_CNT_UNINITIALIZED_DATA	0x00000080
 #define GRUB_PE32_SCN_MEM_DISCARDABLE		0x02000000
 #define GRUB_PE32_SCN_MEM_EXECUTE		0x20000000
 #define GRUB_PE32_SCN_MEM_READ			0x40000000
@@ -349,4 +373,44 @@ struct grub_pe32_reloc
 #define GRUB_PE32_REL_I386_DIR32	0x6
 #define GRUB_PE32_REL_I386_REL32	0x14
 
+struct grub_pe32_header_32
+{
+  char signature[GRUB_PE32_SIGNATURE_SIZE];
+  struct grub_pe32_coff_header coff_header;
+  struct grub_pe32_optional_header optional_header;
+};
+
+struct grub_pe32_header_64
+{
+  char signature[GRUB_PE32_SIGNATURE_SIZE];
+  struct grub_pe32_coff_header coff_header;
+  struct grub_pe64_optional_header optional_header;
+};
+
+typedef union
+{
+  struct grub_pe32_header_32 pe32;
+  struct grub_pe32_header_64 pe32plus;
+} grub_pe_header_t;
+
+struct pe_coff_loader_image_context
+{
+  grub_efi_uint64_t image_address;
+  grub_efi_uint64_t image_size;
+  grub_efi_uint64_t entry_point;
+  grub_efi_uintn_t size_of_headers;
+  grub_efi_uint16_t image_type;
+  grub_efi_uint16_t number_of_sections;
+  grub_efi_uint32_t section_alignment;
+  struct grub_pe32_section_table *first_section;
+  struct grub_pe32_data_directory *reloc_dir;
+  struct grub_pe32_data_directory *sec_dir;
+  grub_efi_uint64_t number_of_rva_and_sizes;
+  grub_pe_header_t *pe_hdr;
+};
+
+typedef struct pe_coff_loader_image_context pe_coff_loader_image_context_t;
+
+#define EFI_IMAGE_NUMBER_OF_DIRECTORY_ENTRIES 16
+
 #endif /* ! GRUB_EFI_PE32_HEADER */
diff --git a/include/grub/multiboot.h b/include/grub/multiboot.h
index d8847f7531d3..c6af5c71b4e8 100644
--- a/include/grub/multiboot.h
+++ b/include/grub/multiboot.h
@@ -100,6 +100,9 @@ struct mbi_load_data
 };
 typedef struct mbi_load_data mbi_load_data_t;
 
+bool
+grub_multiboot_is_elf (mbi_load_data_t *mld);
+
 /* Load ELF32 or ELF64.  */
 grub_err_t
 grub_multiboot_load_elf (mbi_load_data_t *mld);
diff --git a/include/grub/multiboot2.h b/include/grub/multiboot2.h
index b90aa6989674..6169cb4472a7 100644
--- a/include/grub/multiboot2.h
+++ b/include/grub/multiboot2.h
@@ -92,10 +92,19 @@ struct mbi_load_data
 };
 typedef struct mbi_load_data mbi_load_data_t;
 
+bool
+grub_multiboot2_is_elf (mbi_load_data_t *mld);
+
 /* Load ELF32 or ELF64.  */
 grub_err_t
 grub_multiboot2_load_elf (mbi_load_data_t *mld);
 
+grub_err_t
+grub_multiboot2_load_pe (mbi_load_data_t *mld);
+
+bool
+grub_multiboot2_is_pe (mbi_load_data_t *mld);
+
 extern grub_size_t grub_multiboot2_pure_size;
 extern grub_size_t grub_multiboot2_alloc_mbi;
 extern grub_uint32_t grub_multiboot2_payload_eip;
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Mar 28 15:11:05 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 15:11:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698957.1091277 (Exim 4.92)
	(envelope-from )
	id 1rprPF-0002MB-Al; Thu, 28 Mar 2024 15:11:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698957.1091277; Thu, 28 Mar 2024 15:11:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rprPF-0002M0-7V; Thu, 28 Mar 2024 15:11:05 +0000
Received: by outflank-mailman (input) for mailman id 698957;
 Thu, 28 Mar 2024 15:11:03 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rprPD-0001mV-3O
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 15:11:03 +0000
Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com
 [2607:f8b0:4864:20::82f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 63cdc1a3-ed15-11ee-afe3-a90da7624cb6;
 Thu, 28 Mar 2024 16:11:02 +0100 (CET)
Received: by mail-qt1-x82f.google.com with SMTP id
 d75a77b69052e-43107ccd7b9so5577561cf.3
 for ; Thu, 28 Mar 2024 08:11:02 -0700 (PDT)
Received: from rossla-lxenia.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 cr7-20020a05622a428700b004313f54aaa9sm696300qtb.5.2024.03.28.08.11.00
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 28 Mar 2024 08:11:00 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 63cdc1a3-ed15-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1711638661; x=1712243461; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=U2qmXAF7kH+Xo7dcYPNWV07zKXcD5akVAYdTNUPm5Ak=;
        b=bNoRIdajri1wVAtu80pzggb6o6axyqxWdnp5Bsa62pAuNgE8SvMNaWbtgjX00lXnI5
         JcXm3jwPTPuJOdlxjmvFNw3H6JYkg9B1rAgNPISh5hKvZHUMa+0bO4x5GP+Us0RVmfXb
         a3tDWxrWiG55E38ofCUADCL9vBvt++XjBZBOY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711638661; x=1712243461;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=U2qmXAF7kH+Xo7dcYPNWV07zKXcD5akVAYdTNUPm5Ak=;
        b=WLq9Shx+wr41UPL8YlP+FSeMYrpbIu1ozKHIp1KSBpAyAFpyceuwLySs6SghtaXYua
         J3JC7CFne5wHVA6oNl4hTwowF3SvfEllllwpHSWbrXiu99gK67JXJbXlDb9Z7vafBaiE
         Lp04YlAyPnXk3AeAJVYudDMGYeKy/sUeqNlmcicIifWFnGqMqdGJeWWnuQnSB5nX2J+8
         sGhu1bSd5yIcGd1Cy31EpSmNRDKk9LrylF/YgIgzET5XZVMdvHWpo0tsE9GGBYQEd5N3
         aebN0+V/bMTE5stGVhPXJmboj7pHgRjR5+mFICtTkV0spwb622kz/2iftm8SG9KxJjMf
         bltQ==
X-Gm-Message-State: AOJu0YyepdaONKwYikXJMHD1REyWMuKQUmMi37BoVvCOU0J7Qh6I2boQ
	jxy1LP0otEu3WLki2zJ94JHlQW2aTYo2+d+mYvZbvrTReazfbJW4d21Qzu4IkQ==
X-Google-Smtp-Source: AGHT+IHRgh7LeGuGdwNldABcb1tIrGf4GrwtRM68IhGmhRZqpwgzTkw0Gpe38tSy6CDtLxe8+DQwvA==
X-Received: by 2002:ac8:5c8c:0:b0:430:e2cb:9a54 with SMTP id r12-20020ac85c8c000000b00430e2cb9a54mr3266954qta.12.1711638661506;
        Thu, 28 Mar 2024 08:11:01 -0700 (PDT)
From: Ross Lagerwall 
To: grub-devel@gnu.org
Cc: xen-devel@lists.xenproject.org,
	Ross Lagerwall ,
	Daniel Kiper ,
	Daniel Kiper ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v2 3/3] efi: Allow loading multiboot modules without verification
Date: Thu, 28 Mar 2024 15:13:02 +0000
Message-ID: <20240328151302.1451158-4-ross.lagerwall@citrix.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20240328151302.1451158-1-ross.lagerwall@citrix.com>
References: <20240328151302.1451158-1-ross.lagerwall@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

GRUB doesn't do anything with multiboot modules except loading them and
passing a pointer to the multiboot kernel. Therefore GRUB itself doesn't
need to verify the module. Multiboot modules may contain code that needs
to be verified. If this is the case, the expectation is that the
multiboot kernel verifies the modules. For example, with Xen, the first
multiboot module contains the dom0 kernel binary and Xen verifies it
before starting it.

Signed-off-by: Ross Lagerwall 
---
 grub-core/kern/efi/sb.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/grub-core/kern/efi/sb.c b/grub-core/kern/efi/sb.c
index 8d3e413608bb..f76290d65e9f 100644
--- a/grub-core/kern/efi/sb.c
+++ b/grub-core/kern/efi/sb.c
@@ -171,6 +171,7 @@ shim_lock_verifier_init (grub_file_t io __attribute__ ((unused)),
     case GRUB_FILE_TYPE_LOADENV:
     case GRUB_FILE_TYPE_SAVEENV:
     case GRUB_FILE_TYPE_VERIFY_SIGNATURE:
+    case GRUB_FILE_TYPE_MULTIBOOT_MODULE:
       *flags = GRUB_VERIFY_FLAGS_SKIP_VERIFICATION;
       return GRUB_ERR_NONE;
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Mar 28 15:14:06 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 15:14:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698964.1091286 (Exim 4.92)
	(envelope-from )
	id 1rprS5-000456-NB; Thu, 28 Mar 2024 15:14:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698964.1091286; Thu, 28 Mar 2024 15:14:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rprS5-00044z-KL; Thu, 28 Mar 2024 15:14:01 +0000
Received: by outflank-mailman (input) for mailman id 698964;
 Thu, 28 Mar 2024 15:14:01 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rprS4-00044r-S1
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 15:14:00 +0000
Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com
 [2a00:1450:4864:20::42c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id cd9c9e94-ed15-11ee-afe3-a90da7624cb6;
 Thu, 28 Mar 2024 16:13:59 +0100 (CET)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-33ec7e38b84so704405f8f.1
 for ; Thu, 28 Mar 2024 08:13:59 -0700 (PDT)
Received: from perard.uk.xensource.com (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 ea2-20020a0560000ec200b003432d79876esm1947746wrb.97.2024.03.28.08.13.51
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 28 Mar 2024 08:13:52 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: cd9c9e94-ed15-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1711638839; x=1712243639; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=Vutwe9uQNhqbkQuib/VJsrR0Y5T7DY7pGtessWbxb5I=;
        b=PXFNm+mdpPm+wcgd/2Pj9+1P2tkID0md+7edaUTcxPIsxNRzcBIO7joqFf1H5BA17Q
         SvY0vz9JlcleWqC6AtqP0Tjm0s7t/h4+JiE7WMbgA/CYVLDpBhUwi3BqbkIFC+209cab
         nalhVsm7U0cb+JPZ14uxr/rySo5JrJtudGSUE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711638839; x=1712243639;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=Vutwe9uQNhqbkQuib/VJsrR0Y5T7DY7pGtessWbxb5I=;
        b=eEqY4Xsh4Qyw3pFkAVUBon4/nXygvQCOq5kEspc5XlkCshZb0yFwwRlqAhB/v0sHIt
         osTVrF/vdLS2m/GaRjPEMGUhT0MVQmjJDVq2TV9wQD8JQwWNwUqR1AqVAmjHAgenGB13
         oc3IrGxzrCwDZ0mk8XK4cACNt5hzGp5kDehmAnwMIGchKACUcEvwTdXv+1oUL4DT0zNa
         EMW7EbdSp05iG8ncw2r2qkzjbWeZ8KJFMie0nS+MEBciGQgS7fJk+KSOf2nHsPHnbctd
         AC7FUvKNxjsbDi3yGwJ1eUqJsK5YPMcUDzLaLypRFtCbqrdwfCNCHRzKAmHBbiUP8kO6
         OeJg==
X-Forwarded-Encrypted: i=1; AJvYcCWWh+DTXPne/N+TjmgXI1m5uJGxHJFd2HUAObMTD97dcRoiO4yUBiDCKy4gUE7dcjYO5vbcawPA9NKLCa2IVHhh9OXeW05dk2XEApc8T50=
X-Gm-Message-State: AOJu0YzHTQPLbIEqtqWgfNBDeUntdvzBdW9ur8e7JH2t7UvhQIc7eFIt
	us80uc0xnUEdaZiUhrIM+TOURpQVCunD//DtcjSqJxW+x0yAwDF0I2Nb7erGbsI=
X-Google-Smtp-Source: AGHT+IGqAinQBfrXGU5/mTtpVN5DvsCj7MjTmxxo3BTpBz9VwcwzSMIjsSrbfaQrLhnH/z44soQEMQ==
X-Received: by 2002:adf:e9cf:0:b0:341:bf20:c840 with SMTP id l15-20020adfe9cf000000b00341bf20c840mr2502075wrn.11.1711638839070;
        Thu, 28 Mar 2024 08:13:59 -0700 (PDT)
Date: Thu, 28 Mar 2024 15:13:51 +0000
From: Anthony PERARD 
To: Philippe =?iso-8859-1?Q?Mathieu-Daud=E9?= 
Cc: David Woodhouse , qemu-devel@nongnu.org,
	Alex =?iso-8859-1?Q?Benn=E9e?= ,
	Paul Durrant , qemu-arm@nongnu.org,
	Paolo Bonzini ,
	David Woodhouse ,
	Stefano Stabellini ,
	Richard Henderson ,
	xen-devel@lists.xenproject.org, qemu-block@nongnu.org,
	kvm@vger.kernel.org, Thomas Huth ,
	Stefan Hajnoczi ,
	Kevin Wolf , Hanna Reitz 
Subject: Re: [PATCH-for-9.0 v2 19/19] hw/xen: Have most of Xen files become
 target-agnostic
Message-ID: <83ff9fec-2ac1-418f-ac76-2256d03e676e@perard>
References: <20231114143816.71079-1-philmd@linaro.org>
 <20231114143816.71079-20-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20231114143816.71079-20-philmd@linaro.org>

On Tue, Nov 14, 2023 at 03:38:15PM +0100, Philippe Mathieu-Daud wrote:
> Previous commits re-organized the target-specific bits
> from Xen files. We can now build the common files once
> instead of per-target.
> 
> Only 4 files call libxen API (thus its CPPFLAGS):
> - xen-hvm-common.c,
> - xen_pt.c, xen_pt_graphics.c, xen_pt_msi.c
> 
> Signed-off-by: Philippe Mathieu-Daud 
> ---
> Reworked since v1 so dropping David's R-b tag.
> ---
>  accel/xen/meson.build          |  2 +-
>  hw/block/dataplane/meson.build |  2 +-
>  hw/xen/meson.build             | 21 ++++++++++-----------
>  3 files changed, 12 insertions(+), 13 deletions(-)
> 
> diff --git a/accel/xen/meson.build b/accel/xen/meson.build
> index 002bdb03c6..455ad5d6be 100644
> --- a/accel/xen/meson.build
> +++ b/accel/xen/meson.build
> @@ -1 +1 @@
> -specific_ss.add(when: 'CONFIG_XEN', if_true: files('xen-all.c'))
> +system_ss.add(when: 'CONFIG_XEN', if_true: files('xen-all.c'))
> diff --git a/hw/block/dataplane/meson.build b/hw/block/dataplane/meson.build
> index 025b3b061b..4d8bcb0bb9 100644
> --- a/hw/block/dataplane/meson.build
> +++ b/hw/block/dataplane/meson.build
> @@ -1,2 +1,2 @@
>  system_ss.add(when: 'CONFIG_VIRTIO_BLK', if_true: files('virtio-blk.c'))
> -specific_ss.add(when: 'CONFIG_XEN_BUS', if_true: files('xen-block.c'))
> +system_ss.add(when: 'CONFIG_XEN_BUS', if_true: files('xen-block.c'))
> diff --git a/hw/xen/meson.build b/hw/xen/meson.build
> index d887fa9ba4..403cab49cf 100644
> --- a/hw/xen/meson.build
> +++ b/hw/xen/meson.build
> @@ -7,26 +7,25 @@ system_ss.add(when: ['CONFIG_XEN_BUS'], if_true: files(
>    'xen_pvdev.c',
>  ))
>  
> -system_ss.add(when: ['CONFIG_XEN', xen], if_true: files(
> +system_ss.add(when: ['CONFIG_XEN'], if_true: files(
>    'xen-operations.c',
> -))
> -
> -xen_specific_ss = ss.source_set()
> -xen_specific_ss.add(files(
>    'xen-mapcache.c',
> +))
> +system_ss.add(when: ['CONFIG_XEN', xen], if_true: files(
>    'xen-hvm-common.c',
>  ))
> +
>  if have_xen_pci_passthrough
> -  xen_specific_ss.add(files(
> +  system_ss.add(when: ['CONFIG_XEN'], if_true: files(
>      'xen-host-pci-device.c',
> -    'xen_pt.c',
>      'xen_pt_config_init.c',
> -    'xen_pt_graphics.c',
>      'xen_pt_load_rom.c',
> +  ))
> +  system_ss.add(when: ['CONFIG_XEN', xen], if_true: files(
> +    'xen_pt.c',
> +    'xen_pt_graphics.c',

How is it useful to separate those source files? In the commit
description, there's a talk about "CPPFLAGS", but having `when: [xen]`
doesn't change the flags used to build those objects, so the talk about
"CPPFLAGS" is confusing.
Second, if for some reason the dependency `xen` is false, but
`CONFIG_XEN` is true, then we wouldn't be able to build QEMU. Try
linking a binary with "xen_pt_config_init.o" but without "xen_pt.o",
that's not going to work. So even if that first source file doesn't
directly depend on the Xen libraries, it depends on "xen_pt.o" which
depends on the Xen libraries. So ultimately, I think all those source
files should have the same condition: ['CONFIG_XEN', xen].

I've only checked the xen_pt* source files, I don't know if the same
applies to "xen-operations.c" or "xen-mapcache.c".

Beside this, QEMU built with Xen support still seems to works fine, so
adding the objects to `system_ss` instead of `specific_ss` seems
alright.

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Thu Mar 28 15:22:56 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 15:22:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698976.1091296 (Exim 4.92)
	(envelope-from )
	id 1rprac-0006Qy-GX; Thu, 28 Mar 2024 15:22:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698976.1091296; Thu, 28 Mar 2024 15:22:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rprac-0006Qr-Dz; Thu, 28 Mar 2024 15:22:50 +0000
Received: by outflank-mailman (input) for mailman id 698976;
 Thu, 28 Mar 2024 15:22:49 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rprab-0006Ql-Cb
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 15:22:49 +0000
Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.4])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 06fd442f-ed17-11ee-a1ef-f123f15fe8a2;
 Thu, 28 Mar 2024 16:22:46 +0100 (CET)
Received: from m5p.com (mailhost.m5p.com [IPv6:2001:470:1f07:15ff:0:0:0:f7])
 by mailhost.m5p.com (8.17.1/8.15.2) with ESMTPS id 42SFMVTt088230
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
 Thu, 28 Mar 2024 11:22:37 -0400 (EDT) (envelope-from ehem@m5p.com)
Received: (from ehem@localhost)
 by m5p.com (8.17.1/8.15.2/Submit) id 42SFMVRw088229;
 Thu, 28 Mar 2024 08:22:31 -0700 (PDT) (envelope-from ehem)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 06fd442f-ed17-11ee-a1ef-f123f15fe8a2
Date: Thu, 28 Mar 2024 08:22:31 -0700
From: Elliott Mitchell 
To: Jan Beulich 
Cc: xen-devel@lists.xenproject.org, Andrew Cooper ,
        Roger Pau =?iso-8859-1?Q?Monn=E9?= ,
        Wei Liu , Kelly Choi 
Subject: Re: Serious AMD-Vi(?) issue
Message-ID: 
References: 
 
 
 
 
 
 
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-Spam-Status: No, score=0.0 required=10.0 tests=KHOP_HELO_FCRDNS
	autolearn=unavailable autolearn_force=no version=4.0.0
X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on mattapan.m5p.com

On Thu, Mar 28, 2024 at 07:25:02AM +0100, Jan Beulich wrote:
> On 27.03.2024 18:27, Elliott Mitchell wrote:
> > On Mon, Mar 25, 2024 at 02:43:44PM -0700, Elliott Mitchell wrote:
> >> On Mon, Mar 25, 2024 at 08:55:56AM +0100, Jan Beulich wrote:
> >>> On 22.03.2024 20:22, Elliott Mitchell wrote:
> >>>> On Fri, Mar 22, 2024 at 04:41:45PM +0000, Kelly Choi wrote:
> >>>>>
> >>>>> I can see you've recently engaged with our community with some issues you'd
> >>>>> like help with.
> >>>>> We love the fact you are participating in our project, however, our
> >>>>> developers aren't able to help if you do not provide the specific details.
> >>>>
> >>>> Please point to specific details which have been omitted.  Fairly little
> >>>> data has been provided as fairly little data is available.  The primary
> >>>> observation is large numbers of:
> >>>>
> >>>> (XEN) AMD-Vi: IO_PAGE_FAULT: DDDD:bb:dd.f d0 addr ffffff???????000 flags 0x8 I
> >>>>
> >>>> Lines in Xen's ring buffer.
> >>>
> >>> Yet this is (part of) the problem: By providing only the messages that appear
> >>> relevant to you, you imply that you know that no other message is in any way
> >>> relevant. That's judgement you'd better leave to people actually trying to
> >>> investigate. Unless of course you were proposing an actual code change, with
> >>> suitable justification.
> >>
> >> Honestly, I forgot about the very small number of messages from the SATA
> >> subsystem.  The question of whether the current mitigation actions are
> >> effective right now was a bigger issue.  As such monitoring `xl dmesg`
> >> was a priority to looking at SATA messages which failed to reliably
> >> indicate status.
> >>
> >> I *thought* I would be able to retrieve those via other slow means, but a
> >> different and possibly overlapping issue has shown up.  Unfortunately
> >> this means those are no longer retrievable.   :-(
> > 
> > With some persistence I was able to retrieve them.  There are other
> > pieces of software with worse UIs than Xen.
> > 
> >>> In fact when running into trouble, the usual course of action would be to
> >>> increase verbosity in both hypervisor and kernel, just to make sure no
> >>> potentially relevant message is missed.
> >>
> >> More/better information might have been obtained if I'd been engaged
> >> earlier.
> > 
> > This is still true, things are in full mitigation mode and I'll be
> > quite unhappy to go back with experiments at this point.
> 
> Well, it very likely won't work without further experimenting by someone
> able to observe the bad behavior. Recall we're on xen-devel here; it is
> kind of expected that without clear (and practical) repro instructions
> experimenting as well as info collection will remain with the reporter.

The first reporter: https://bugs.debian.org/988477 gave pretty specific
details about their setups.

While the exact border isn't very well defined, that seems enough to give
a pretty good start.  We don't know whether all Samsung SATA devices are
effected, but most of the recent ones (<5 years old) are.  This requires
a pair of devices in software RAID1.  Likely reproduces better with AMD
AM4/AM5 processors, but almost certainly needs a fully operational IOMMU.

(ASUS motherboards tend to have well setup IOMMUs)

I would be surprised if you don't have all of the hardware on-hand.  Only
issue would be finding an appropriate pair of SATA devices, since those
tend to remain in service.  I would look for older devices which were
removed from service due to being too small (128GB 840 PRO from the first
report), or were pulled from service due to having had too many writes.


> > I now see why I left those out.  The messages from the SATA subsystem
> > were from a kernel which a bad patch had leaked into a LTS branch.  Looks
> > like the SATA subsystem was significantly broken and I'm unsure whether
> > any useful information could be retrieved.  Notably there is quite a bit
> > of noise from SATA devices not effected by this issue.
> > 
> > Some of the messages /might/ be useful, but the amount of noise is quite
> > high.  Do messages from a broken kernel interest you?
> 
> If this was a less vague (in terms of possible root causes) issue, I'd
> probably have answered "yes". But in the case here I'm afraid such might
> further confuse things rather than clarifying them.

Okay.


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg@m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include  O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445




From xen-devel-bounces@lists.xenproject.org Thu Mar 28 15:35:36 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 15:35:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698985.1091307 (Exim 4.92)
	(envelope-from )
	id 1rprmt-0000P0-Jm; Thu, 28 Mar 2024 15:35:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698985.1091307; Thu, 28 Mar 2024 15:35:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rprmt-0000Ot-G6; Thu, 28 Mar 2024 15:35:31 +0000
Received: by outflank-mailman (input) for mailman id 698985;
 Thu, 28 Mar 2024 15:35:30 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rprms-0000On-Bp
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 15:35:30 +0000
Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com
 [2607:f8b0:4864:20::836])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ce0437cc-ed18-11ee-afe3-a90da7624cb6;
 Thu, 28 Mar 2024 16:35:29 +0100 (CET)
Received: by mail-qt1-x836.google.com with SMTP id
 d75a77b69052e-430c32c04c7so5307351cf.0
 for ; Thu, 28 Mar 2024 08:35:29 -0700 (PDT)
Received: from localhost ([85.31.135.62]) by smtp.gmail.com with ESMTPSA id
 cb9-20020a05622a1f8900b00430b907c234sm712604qtb.26.2024.03.28.08.35.26
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 28 Mar 2024 08:35:26 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ce0437cc-ed18-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1711640127; x=1712244927; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:from:to:cc:subject:date:message-id:reply-to;
        bh=8n7tN2Gb8zYsB5TxQEwfCgZyHBrjTC5mqLoPfYLQw3w=;
        b=e7XJX6Qm4P8d2+3yADnY+0yDoNZbmBunrDuCG2H3TjbROHmz4wkVWfvKgP9UbZ1fXA
         On/UIcBu/ECwln95cYTnWIDwIrvagrEM/b0RZqBA/ZtEKR40UJ8rpWgg2/4rzUD4Uosh
         viLkkJ/WS23UuVAdC/tC/nyB6qBilcRtj1VUE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711640127; x=1712244927;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=8n7tN2Gb8zYsB5TxQEwfCgZyHBrjTC5mqLoPfYLQw3w=;
        b=ilr2Dti0qPqcwBLB3JEf1lYv8QCWw73JdAqbiNOLo5KFnDakmkgbfslLGLO+QejRGY
         RPwomKueFL58eC0Up+rPcjN8TQGx1bjYbsDBorFDyKdz3HLmZV3YPnki0EdDqVwbqlbA
         y4uZUUpMJGCxeQavbLFLFNTK9KMSfGwDSHJbZ7aOnCgAa4X0bDvy6uDa2PWpsXoQj9ng
         sHF8jT4Sm3IYznADUkwGjtMibUugKoiTr6DwIw9Y393ERMm9bL6R1Ec+hMYBeNQ0TfA8
         Zz/FKqzl67Wh1eGelZsl2HresaMYAmABLK6zmdcKBg98KVMO7362eOorsaxwBMKI4W7q
         A4UQ==
X-Gm-Message-State: AOJu0Yz5+a1ux3vsJvorI9CCQM/dO2lZm/+agxEYsiNYXANi1FPz/Xny
	E534kAEmANGBMi1+/B6FOWgiHlewCPANlSrOqNLDA1PeqV9nwYOvQYHddX5CQHU36pl30kbq2k6
	6
X-Google-Smtp-Source: AGHT+IFb9hWkirb9yBvLaUlKOOeCEDFnZ88pETqLp7Kax20zcgYG+ZuZEJ80ukiC3ql4ubVZm7v5TQ==
X-Received: by 2002:ac8:57d5:0:b0:432:b30b:7fd8 with SMTP id w21-20020ac857d5000000b00432b30b7fd8mr2740651qta.16.1711640127334;
        Thu, 28 Mar 2024 08:35:27 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Jan Beulich ,
	Andrew Cooper 
Subject: [PATCH 0/2] x86/video: improve early video detection
Date: Thu, 28 Mar 2024 16:35:21 +0100
Message-ID: <20240328153523.4155-1-roger.pau@citrix.com>
X-Mailer: git-send-email 2.44.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Hello,

The current video logic reports wrong values when booted in PVH mode, as
that boot path explicitly skips real-mode logic, and thus avoids any VGA
video detection.

First patch is cleanup of the offset declarations in boot_video_info.
Second patch attempts to fix Xen in PVH mode reporting VGA support.

Roger Pau Monne (2):
  x86/video: add boot_video_info offset generation to asm-offsets
  x86/video: do not assume a video mode to be unconditionally present

 xen/arch/x86/boot/video.S         | 88 +++++++++++--------------------
 xen/arch/x86/x86_64/asm-offsets.c | 26 +++++++++
 2 files changed, 58 insertions(+), 56 deletions(-)

-- 
2.44.0



From xen-devel-bounces@lists.xenproject.org Thu Mar 28 15:35:36 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 15:35:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698986.1091317 (Exim 4.92)
	(envelope-from )
	id 1rprmv-0000dQ-PL; Thu, 28 Mar 2024 15:35:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698986.1091317; Thu, 28 Mar 2024 15:35:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rprmv-0000dJ-MO; Thu, 28 Mar 2024 15:35:33 +0000
Received: by outflank-mailman (input) for mailman id 698986;
 Thu, 28 Mar 2024 15:35:32 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rprmu-0000On-7E
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 15:35:32 +0000
Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com
 [2607:f8b0:4864:20::82c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id cf1f551d-ed18-11ee-afe3-a90da7624cb6;
 Thu, 28 Mar 2024 16:35:31 +0100 (CET)
Received: by mail-qt1-x82c.google.com with SMTP id
 d75a77b69052e-430a0d6c876so6204291cf.3
 for ; Thu, 28 Mar 2024 08:35:31 -0700 (PDT)
Received: from localhost ([85.31.135.62]) by smtp.gmail.com with ESMTPSA id
 kl15-20020a056214518f00b00690fd3f6e3esm725092qvb.104.2024.03.28.08.35.28
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 28 Mar 2024 08:35:29 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: cf1f551d-ed18-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1711640129; x=1712244929; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=yKPOV/4oK/MSuhjrxbS7bDzwnJlkzdVvIN0qtwV/7Fk=;
        b=ZMeI5ILwzrb83QBGpSDF7EIGuEcse0cEEJq3R/AQhXfeprzhyBa4qG6ZHk4YDQuk3P
         FLWYUAtCShuo+aKk0mMIa+OtVLW+dVl9ExyfbXtAYW4tFUezaY1Z4mFrPBCS0Mt0NM4z
         MBZ8Y6vi3JqxpsIPaJMB2Hq8qz/J4m1EMF024=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711640129; x=1712244929;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=yKPOV/4oK/MSuhjrxbS7bDzwnJlkzdVvIN0qtwV/7Fk=;
        b=f20wmM22cidZg+dyrQs+E4jIfdw83bdQGVhL8VKAB+r5S8tgoj+LrVi0C/HfMcV7sP
         vRneCLCA/6L0Ul9pw28xSAaIRH+KIpjqR+ZDcBLsLI3KAJ1seutxvYV4Rjk1G3PK8L4/
         Sx2P2o5q8a56dMsd4aE8YhKq+1gU/oylRcXuDoa3PO/z6PZe7RRFimnbr78x3AXVnrid
         DMtu784eETBtMMkV3bVtXE2rp7YLx7wJEh35ZaHXBK9SEZDgyarp6fKk0/F6JJMdJRF1
         V7ChRbXSMPhZB5zwfV8OruMxbSjbc30Xlkm64KRj+X7NBdpWyrwTj3gVIBtUFbATZqrI
         EBxg==
X-Gm-Message-State: AOJu0YyGCYrcn1g6+eCwKp7WxN/7Xo5cuB4PAOG1boDKO1jqbsFK4vNY
	fXyP5zy5oXXPNEIkaQR7rOa4RpYeTvmFUy47jV6xPX0GJlhoYChpqk5Yjj9lzbKpaSOyccEAw6W
	7
X-Google-Smtp-Source: AGHT+IEB1juBjb6HjN/ZNPWNhahscMM2B2FqISU7Ad+6HQmmVbvESi44aTfnJFC4wglaRkzZKjWt/A==
X-Received: by 2002:ad4:4baf:0:b0:696:82ce:a2ce with SMTP id i15-20020ad44baf000000b0069682cea2cemr3147563qvw.8.1711640129577;
        Thu, 28 Mar 2024 08:35:29 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Jan Beulich ,
	Andrew Cooper 
Subject: [PATCH 1/2] x86/video: add boot_video_info offset generation to asm-offsets
Date: Thu, 28 Mar 2024 16:35:22 +0100
Message-ID: <20240328153523.4155-2-roger.pau@citrix.com>
X-Mailer: git-send-email 2.44.0
In-Reply-To: <20240328153523.4155-1-roger.pau@citrix.com>
References: <20240328153523.4155-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Currently the offsets into the boot_video_info struct are manually encoded in
video.S, which is fragile.  Generate them in asm-offsets.c and switch the
current code to use those instead.

No functional change intended.

Signed-off-by: Roger Pau Monné 
---
 xen/arch/x86/boot/video.S         | 83 ++++++++++++-------------------
 xen/arch/x86/x86_64/asm-offsets.c | 26 ++++++++++
 2 files changed, 58 insertions(+), 51 deletions(-)

diff --git a/xen/arch/x86/boot/video.S b/xen/arch/x86/boot/video.S
index 0ae04f270f8c..a4b25a3b34d1 100644
--- a/xen/arch/x86/boot/video.S
+++ b/xen/arch/x86/boot/video.S
@@ -26,32 +26,13 @@
 /* Force 400 scan lines for standard modes (hack to fix bad BIOS behaviour */
 #undef CONFIG_VIDEO_400_HACK
 
-/* Positions of various video parameters passed to the kernel */
-/* (see also include/linux/tty.h) */
-#define PARAM_CURSOR_POS        0x00
-#define PARAM_VIDEO_MODE        0x02
-#define PARAM_VIDEO_COLS        0x03
-#define PARAM_VIDEO_LINES       0x04
-#define PARAM_HAVE_VGA          0x05
-#define PARAM_FONT_POINTS       0x06
-#define PARAM_CAPABILITIES      0x08
-#define PARAM_LFB_LINELENGTH    0x0c
-#define PARAM_LFB_WIDTH         0x0e
-#define PARAM_LFB_HEIGHT        0x10
-#define PARAM_LFB_DEPTH         0x12
-#define PARAM_LFB_BASE          0x14
-#define PARAM_LFB_SIZE          0x18
-#define PARAM_LFB_COLORS        0x1c
-#define PARAM_VESAPM_SEG        0x24
-#define PARAM_VESAPM_OFF        0x26
-#define PARAM_VESA_ATTRIB       0x28
 #define _param(param) bootsym(boot_vid_info)+(param)
 
 video:  xorw    %ax, %ax
         movw    %ax, %gs        # GS is zero
         cld
         call    basic_detect    # Basic adapter type testing (EGA/VGA/MDA/CGA)
-        cmpb    $0,_param(PARAM_HAVE_VGA)
+        cmpb    $0,_param(BVI_have_vga)
         je      1f                # Bail if there's no VGA
         movw    bootsym(boot_vid_mode), %ax     # User selected video mode
         cmpw    $ASK_VGA, %ax                   # Bring up the menu
@@ -69,7 +50,7 @@ vid1:   call    store_edid
 
 # Detect if we have CGA, MDA, EGA or VGA and pass it to the kernel.
 basic_detect:
-        movb    $0, _param(PARAM_HAVE_VGA)
+        movb    $0, _param(BVI_have_vga)
         movb    $0x12, %ah                      # Check EGA/VGA
         movb    $0x10, %bl
         int     $0x10
@@ -79,7 +60,7 @@ basic_detect:
         int     $0x10
         cmpb    $0x1a, %al                      # 1a means VGA...
         jne     basret                          # anything else is EGA.
-        incb    _param(PARAM_HAVE_VGA)          # We've detected a VGA
+        incb    _param(BVI_have_vga)            # We've detected a VGA
 basret: ret
 
 # Store the video mode parameters for later usage by the kernel.
@@ -92,57 +73,57 @@ mode_params:
         movb    $0x03, %ah                      # Read cursor position
         xorb    %bh, %bh
         int     $0x10
-        movw    %dx, _param(PARAM_CURSOR_POS)
+        movw    %dx, _param(BVI_cursor_pos)
         movb    $0x0f, %ah                      # Read page/mode/width
         int     $0x10
-        movw    %ax, _param(PARAM_VIDEO_MODE)   # Video mode and screen width
+        movw    %ax, _param(BVI_video_mode)     # Video mode and screen width
         movw    %gs:(0x485), %ax                # Font size
-        movw    %ax, _param(PARAM_FONT_POINTS)  # (valid only on EGA/VGA)
+        movw    %ax, _param(BVI_font_points)    # (valid only on EGA/VGA)
         movw    bootsym(force_size), %ax        # Forced size?
         orw     %ax, %ax
         jz      mopar1
 
-        movb    %ah, _param(PARAM_VIDEO_COLS)
-        movb    %al, _param(PARAM_VIDEO_LINES)
+        movb    %ah, _param(BVI_video_cols)
+        movb    %al, _param(BVI_video_lines)
         ret
 
 mopar1: movb    %gs:(0x484), %al                # On EGA/VGA, use the EGA+ BIOS
         incb    %al                             # location of max lines.
-mopar2: movb    %al, _param(PARAM_VIDEO_LINES)
+mopar2: movb    %al, _param(BVI_video_lines)
         ret
 
 # Fetching of VESA frame buffer parameters
 mopar_gr:
         movw    $vesa_mode_info, %di
-        movb    $0x23, _param(PARAM_HAVE_VGA)
+        movb    $0x23, _param(BVI_have_vga)
         movw    16(%di), %ax
-        movw    %ax, _param(PARAM_LFB_LINELENGTH)
+        movw    %ax, _param(BVI_lfb_linelength)
         movw    18(%di), %ax
-        movw    %ax, _param(PARAM_LFB_WIDTH)
+        movw    %ax, _param(BVI_lfb_width)
         movw    20(%di), %ax
-        movw    %ax, _param(PARAM_LFB_HEIGHT)
+        movw    %ax, _param(BVI_lfb_height)
         movzbw  25(%di), %ax
-        movw    %ax, _param(PARAM_LFB_DEPTH)
+        movw    %ax, _param(BVI_lfb_depth)
         movl    40(%di), %eax
-        movl    %eax, _param(PARAM_LFB_BASE)
+        movl    %eax, _param(BVI_lfb_base)
         movl    31(%di), %eax
-        movl    %eax, _param(PARAM_LFB_COLORS)
+        movl    %eax, _param(BVI_lfb_colors)
         movl    35(%di), %eax
-        movl    %eax, _param(PARAM_LFB_COLORS+4)
+        movl    %eax, _param(BVI_lfb_colors+4)
         movw    0(%di), %ax
-        movw    %ax, _param(PARAM_VESA_ATTRIB)
+        movw    %ax, _param(BVI_vesa_attrib)
 
 # get video mem size
         movw    $vesa_glob_info, %di
         movzwl  18(%di), %eax
-        movl    %eax, _param(PARAM_LFB_SIZE)
+        movl    %eax, _param(BVI_lfb_size)
 
 # store mode capabilities
         movl    10(%di), %eax
-        movl    %eax, _param(PARAM_CAPABILITIES)
+        movl    %eax, _param(BVI_capabilities)
 
 # switching the DAC to 8-bit is for <= 8 bpp only
-        cmpw    $8, _param(PARAM_LFB_DEPTH)
+        cmpw    $8, _param(BVI_lfb_depth)
         jg      dac_done
 
 # get DAC switching capability
@@ -160,16 +141,16 @@ mopar_gr:
 dac_set:
 # set color size to DAC size
         movzbw  bootsym(dac_size), %ax
-        movb    %al, _param(PARAM_LFB_COLORS+0)
-        movb    %al, _param(PARAM_LFB_COLORS+2)
-        movb    %al, _param(PARAM_LFB_COLORS+4)
-        movb    %al, _param(PARAM_LFB_COLORS+6)
+        movb    %al, _param(BVI_lfb_colors+0)
+        movb    %al, _param(BVI_lfb_colors+2)
+        movb    %al, _param(BVI_lfb_colors+4)
+        movb    %al, _param(BVI_lfb_colors+6)
 
 # set color offsets to 0
-        movb    %ah, _param(PARAM_LFB_COLORS+1)
-        movb    %ah, _param(PARAM_LFB_COLORS+3)
-        movb    %ah, _param(PARAM_LFB_COLORS+5)
-        movb    %ah, _param(PARAM_LFB_COLORS+7)
+        movb    %ah, _param(BVI_lfb_colors+1)
+        movb    %ah, _param(BVI_lfb_colors+3)
+        movb    %ah, _param(BVI_lfb_colors+5)
+        movb    %ah, _param(BVI_lfb_colors+7)
 
 dac_done:
 # get protected mode interface information
@@ -180,8 +161,8 @@ dac_done:
         cmp     $0x004f, %ax
         jnz     no_pm
 
-        movw    %es, _param(PARAM_VESAPM_SEG)
-        movw    %di, _param(PARAM_VESAPM_OFF)
+        movw    %es, _param(BVI_vesapm_seg)
+        movw    %di, _param(BVI_vesapm_off)
 
 no_pm:  pushw   %ds
         popw    %es
@@ -1018,7 +999,7 @@ GLOBAL(boot_vid_info)
         .byte   80, 25  /* 80x25          */
         .byte   1       /* isVGA          */
         .word   16      /* 8x16 font      */
-        .fill   0x28,1,0
+        .space  BVI_size - BVI_capabilities
 GLOBAL(boot_edid_info)
         .fill   128,1,0x13
 GLOBAL(boot_edid_caps)
diff --git a/xen/arch/x86/x86_64/asm-offsets.c b/xen/arch/x86/x86_64/asm-offsets.c
index d8903a3ce9c7..91da6b9d3885 100644
--- a/xen/arch/x86/x86_64/asm-offsets.c
+++ b/xen/arch/x86/x86_64/asm-offsets.c
@@ -16,6 +16,10 @@
 #include 
 #include 
 
+#ifdef CONFIG_VIDEO
+# include "../boot/video.h"
+#endif
+
 #define DEFINE(_sym, _val)                                                 \
     asm volatile ( "\n.ascii\"==>#define " #_sym " %0 /* " #_val " */<==\""\
                    :: "i" (_val) )
@@ -208,4 +212,26 @@ void __dummy__(void)
 
     OFFSET(DOMAIN_vm_assist, struct domain, vm_assist);
     BLANK();
+
+#ifdef CONFIG_VIDEO
+    DEFINE(BVI_size, sizeof(struct boot_video_info));
+    OFFSET(BVI_cursor_pos, struct boot_video_info, orig_x);
+    OFFSET(BVI_video_mode, struct boot_video_info, orig_video_mode);
+    OFFSET(BVI_video_cols, struct boot_video_info, orig_video_cols);
+    OFFSET(BVI_video_lines, struct boot_video_info, orig_video_lines);
+    OFFSET(BVI_have_vga, struct boot_video_info, orig_video_isVGA);
+    OFFSET(BVI_font_points, struct boot_video_info, orig_video_points);
+    OFFSET(BVI_capabilities, struct boot_video_info, capabilities);
+    OFFSET(BVI_lfb_linelength, struct boot_video_info, lfb_linelength);
+    OFFSET(BVI_lfb_width, struct boot_video_info, lfb_width);
+    OFFSET(BVI_lfb_height, struct boot_video_info, lfb_height);
+    OFFSET(BVI_lfb_depth, struct boot_video_info, lfb_depth);
+    OFFSET(BVI_lfb_base, struct boot_video_info, lfb_base);
+    OFFSET(BVI_lfb_size, struct boot_video_info, lfb_size);
+    OFFSET(BVI_lfb_colors, struct boot_video_info, colors);
+    OFFSET(BVI_vesapm_seg, struct boot_video_info, vesapm.seg);
+    OFFSET(BVI_vesapm_off, struct boot_video_info, vesapm.off);
+    OFFSET(BVI_vesa_attrib, struct boot_video_info, vesa_attrib);
+    BLANK();
+#endif /* CONFIG_VIDEO */
 }
-- 
2.44.0



From xen-devel-bounces@lists.xenproject.org Thu Mar 28 15:35:37 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 15:35:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698987.1091327 (Exim 4.92)
	(envelope-from )
	id 1rprmz-0000uB-6n; Thu, 28 Mar 2024 15:35:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698987.1091327; Thu, 28 Mar 2024 15:35:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rprmz-0000u4-42; Thu, 28 Mar 2024 15:35:37 +0000
Received: by outflank-mailman (input) for mailman id 698987;
 Thu, 28 Mar 2024 15:35:36 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rprmy-0000su-31
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 15:35:36 +0000
Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com
 [2607:f8b0:4864:20::32b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d0c6321a-ed18-11ee-a1ef-f123f15fe8a2;
 Thu, 28 Mar 2024 16:35:34 +0100 (CET)
Received: by mail-ot1-x32b.google.com with SMTP id
 46e09a7af769-6e6e0867be8so490371a34.2
 for ; Thu, 28 Mar 2024 08:35:34 -0700 (PDT)
Received: from localhost ([85.31.135.62]) by smtp.gmail.com with ESMTPSA id
 j3-20020a05620a410300b00789e92b525csm605779qko.81.2024.03.28.08.35.31
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 28 Mar 2024 08:35:31 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d0c6321a-ed18-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1711640132; x=1712244932; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Ok3adXAgDSAh339+9o5qHtGfoLHVal0xgIbEcVkBKgg=;
        b=ZXQ9+l5lK6yILz9qX7JR35nfo8+BombfAkM9f6jfASsANPM8kAHXsGIjoA8cb2tMAC
         6u4/oPNkQOAIZc9H39LJLGJSXmHYrdvAZsbvEW8xohHLBGXe+JPhkvFpiFDcHPxNTbfL
         KQfcpnNA9xegb5bLEVbo/L1rnmUZygbqhsmks=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711640132; x=1712244932;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=Ok3adXAgDSAh339+9o5qHtGfoLHVal0xgIbEcVkBKgg=;
        b=hmWJbaLUCApOnJoKF/nG27O9bmPlYk49vtIHjcHgqGDI8MsO3bO0cwmNsuxIJ+GhXU
         557aLemVI/DLPzJ3z0kGD0zMyfcZdIUHNpU/TOYpQ/ZwyUSYcQ5UNZCbb93wvZt6M0ky
         XDIIw86FvlYkMzb8Hhn2sd6JxQW0R2JLVFo5Q3E3QAYqN0eXuo6SaEHpgtohrAjk0K0m
         3z4hR+G62jLuXq9qK3Ek2M73GpVj/JuvEA4XhmF8/R8wtpmo/j/KQ7ZRErgtBWhPbIZa
         BaMfvJ6ofG7BJGh1j2wvltd9kjuhV0h07gSGmsj4DVGjiIiKuHPWWLq1CE0RKoPfoAzh
         rNPg==
X-Gm-Message-State: AOJu0Yyoc8Hkt34LN08okq57HhT4SFxzKq3ljaXW7551i2fu6Qk/NDwJ
	+GNPPhkxe0Zans3833Lk4U1J2lJlq2rDgEqcg2l6B+dC9JJLQ5tiglsPgB/BrvCyU+7ExphDuLd
	6
X-Google-Smtp-Source: AGHT+IE4mKt7qY733wceOwB9nBMrNCdpeHB4OqOhJh1ZxBn56HB+vEsBVGDeyl+SpLWUv9Rky/7FAA==
X-Received: by 2002:a05:6830:438b:b0:6e6:c217:3b28 with SMTP id s11-20020a056830438b00b006e6c2173b28mr4357228otv.20.1711640132053;
        Thu, 28 Mar 2024 08:35:32 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Jan Beulich ,
	Andrew Cooper 
Subject: [PATCH 2/2] x86/video: do not assume a video mode to be unconditionally present
Date: Thu, 28 Mar 2024 16:35:23 +0100
Message-ID: <20240328153523.4155-3-roger.pau@citrix.com>
X-Mailer: git-send-email 2.44.0
In-Reply-To: <20240328153523.4155-1-roger.pau@citrix.com>
References: <20240328153523.4155-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

There's no reason to assume VGA text mode 3 to be unconditionally available.
With the addition of booting Xen itself in PVH mode there's a boot path that
explicitly short-circuits all the real-mode logic, including the VGA detection.

Leave the default user selected mode as text mode 3 in boot_vid_mode, but do
not populate boot_vid_info with any default settings.  It will either be
populated by the real-mode video detection code, or left zeroed in case
real-mode code is skipped.

Note that only PVH skips the real-mode portion of the boot trampoline,
otherwise the only way to skip it is to set `no-real-mode` on the command line,
and the description for the option already notes that VGA would be disabled as
a result of skipping real-mode bootstrap.

This fixes Xen incorrectly reporting:

(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16

When booted as a PVH guest.

Reported-by: Andrew Cooper 
Signed-off-by: Roger Pau Monné 
---
 xen/arch/x86/boot/video.S | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/xen/arch/x86/boot/video.S b/xen/arch/x86/boot/video.S
index a4b25a3b34d1..a51de04a024e 100644
--- a/xen/arch/x86/boot/video.S
+++ b/xen/arch/x86/boot/video.S
@@ -994,12 +994,7 @@ name_bann:      .asciz  "Video adapter: "
 force_size:     .word   0       # Use this size instead of the one in BIOS vars
 
 GLOBAL(boot_vid_info)
-        .byte   0, 0    /* orig_x, orig_y */
-        .byte   3       /* text mode 3    */
-        .byte   80, 25  /* 80x25          */
-        .byte   1       /* isVGA          */
-        .word   16      /* 8x16 font      */
-        .space  BVI_size - BVI_capabilities
+        .space  BVI_size
 GLOBAL(boot_edid_info)
         .fill   128,1,0x13
 GLOBAL(boot_edid_caps)
-- 
2.44.0



From xen-devel-bounces@lists.xenproject.org Thu Mar 28 15:42:07 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 15:42:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698994.1091336 (Exim 4.92)
	(envelope-from )
	id 1rprtB-0003qC-U6; Thu, 28 Mar 2024 15:42:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698994.1091336; Thu, 28 Mar 2024 15:42:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rprtB-0003q5-Qy; Thu, 28 Mar 2024 15:42:01 +0000
Received: by outflank-mailman (input) for mailman id 698994;
 Thu, 28 Mar 2024 15:42:00 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rprtA-0003pY-LJ
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 15:42:00 +0000
Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com
 [2607:f8b0:4864:20::f2b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b6eb6144-ed19-11ee-afe3-a90da7624cb6;
 Thu, 28 Mar 2024 16:42:00 +0100 (CET)
Received: by mail-qv1-xf2b.google.com with SMTP id
 6a1803df08f44-690c1747c3cso8191736d6.0
 for ; Thu, 28 Mar 2024 08:42:00 -0700 (PDT)
Received: from localhost ([85.31.135.62]) by smtp.gmail.com with ESMTPSA id
 mw5-20020a05621433c500b00696abfe8e3csm736444qvb.63.2024.03.28.08.41.58
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 28 Mar 2024 08:41:58 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b6eb6144-ed19-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1711640519; x=1712245319; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=C/b9EW8sje77PTTNIGYtPc1axX0bFt5Eme1G5thvfvc=;
        b=moS+hFDAsOCb6MmaDF0RJbdH70wN+QRQpdEBwLxEor1SqpHP0wcG9tArWqG1I5ivQs
         RCGcg+5Kbqvg8SUm633eRSZmtFvLqi9Gd7aXKS7LRa8ot/Mf4dDtCtc32H26NTnkn0cK
         LJcmcG3i+3Fa7MLB8jOeTWWVu5KDETQVC70G8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711640519; x=1712245319;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=C/b9EW8sje77PTTNIGYtPc1axX0bFt5Eme1G5thvfvc=;
        b=f8/STLS+Mct0JsHcSkxd252Lll7DQXMPGyfD9iJz6pQ0Wv+9CRwbxPtsmGK+KjBO3k
         uqIyTq+504IsEE2WHyI7aolEbtBm3axGQ4RDBt5to8FYewyXwlwdUrT74P0SJP5JVH+Z
         hpjb4nG0rsLgg+x2XPvhs+X+7RZStbag+sgPs4iSlIbYlr6GmGXM8ARmnixStWKYVuXm
         1fjafEBHs8r/QRUV/jugChHAxnPWfbuhE5njC4be1PjtPXU3dbxVRcGPMxLZ83q/Mfg9
         JWTji2uK1HktOxScZQEhpzQG/KCjNrei+RHcgChwHRHigFn2qD0/fn6BOcYekT9t8HpC
         FgXw==
X-Forwarded-Encrypted: i=1; AJvYcCWZpNVyyWZABCqppteAiUHnWZv4f4++9BlchCyhWfI6Pp+Tu/CmtHLvRfF5aLVkIPeuUYv1Qyy+9xunUH6lJOuyFG9eJg8dYhHEQrVRSFk=
X-Gm-Message-State: AOJu0Yy90BDd7G4i1/eCeWTeVJhuDYcDB7GAjqnQpKtf+9EOChTpBjs0
	L61fGqnzXYdceomgcZaxiYzh9GOJpmwDU9HUfWLOsH3zqo+ZL+J7kWlmxDbLWZs=
X-Google-Smtp-Source: AGHT+IGoOhykmiav7iQ36Wyyjj+EkVpThIxLqz+L20QQI6eklHcF4NTteDPIG4hXB4pfvyH+RnqUqw==
X-Received: by 2002:a0c:eb87:0:b0:692:494f:f0aa with SMTP id x7-20020a0ceb87000000b00692494ff0aamr4344811qvo.9.1711640518870;
        Thu, 28 Mar 2024 08:41:58 -0700 (PDT)
Date: Thu, 28 Mar 2024 16:41:56 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Ross Lagerwall 
Cc: grub-devel@gnu.org, xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Daniel Kiper 
Subject: Re: [PATCH 2/7] multiboot2: Allow 64-bit entry tags
Message-ID: 
References: <20240313150748.791236-1-ross.lagerwall@citrix.com>
 <20240313150748.791236-3-ross.lagerwall@citrix.com>
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Thu, Mar 28, 2024 at 03:05:47PM +0000, Ross Lagerwall wrote:
> On Tue, Mar 19, 2024 at 10:07 AM Roger Pau Monné  wrote:
> >
> > On Wed, Mar 13, 2024 at 03:07:43PM +0000, Ross Lagerwall wrote:
> > > Binaries may be built with entry points above 4G. While bootloaders may
> > > relocate them below 4G, it should be possible for the binary to specify
> > > those entry points. Therefore, extend the multiboot2 protocol such that
> > > 64 bit addresses are allowed for entry points. The extension is done in
> > > a backwards-compatible way.
> > >
> > > Signed-off-by: Ross Lagerwall 
> > > ---
> > >  doc/multiboot.texi | 32 +++++++++++++++++++-------------
> > >  doc/multiboot2.h   |  6 +++++-
> > >  2 files changed, 24 insertions(+), 14 deletions(-)
> > >
> > > diff --git a/doc/multiboot.texi b/doc/multiboot.texi
> > > index d12719c744eb..049afab53c1f 100644
> > > --- a/doc/multiboot.texi
> > > +++ b/doc/multiboot.texi
> > > @@ -522,12 +522,12 @@ header.
> > >
> > >  @example
> > >  @group
> > > -        +-------------------+
> > > -u16     | type = 3          |
> > > -u16     | flags             |
> > > -u32     | size              |
> > > -u32     | entry_addr        |
> > > -        +-------------------+
> > > +          +-------------------+
> > > +u16       | type = 3          |
> > > +u16       | flags             |
> > > +u32       | size              |
> > > +u32 / u64 | entry_addr        |
> > > +          +-------------------+
> >
> > I might be confused, but this entry point is used in 32bit protected
> > mode, and hence a 64bit value is simply impossible to use according to
> > the protocol in "3.3 I386 machine state".
> >
> > Unless that section is expanded to describe other protocols that use
> > the entry address in a way where 64bits could be meaningful it seems
> > pointless to expand the field.
> 
> I changed this because the same binary is being used for both BIOS boot
> and UEFI boot, therefore it may have a base address above 4 GiB.
> Despite that, it is expected that GRUB would relocate the binary below
> 4 GiB so BIOS boot would still work.

Right, for UEFI boot it's possible to have entry addresses above 4GB,
because the entry point is called in long mode with identity page
tables (and hence you can put addresses in %rip past the 4GB
boundary).

However the multiboot entry point puts the CPU in 32bit protected
mode, and hence %eip can only hold a value below the 4GB boundary.

It's technically impossible to use an entry point above 4GB, unless
there's something that I'm missing that changes the initial CPU state
for the multiboot2 entry point.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Mar 28 15:44:24 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 15:44:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.698998.1091347 (Exim 4.92)
	(envelope-from )
	id 1rprvT-0004OI-9Z; Thu, 28 Mar 2024 15:44:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 698998.1091347; Thu, 28 Mar 2024 15:44:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rprvT-0004OB-6X; Thu, 28 Mar 2024 15:44:23 +0000
Received: by outflank-mailman (input) for mailman id 698998;
 Thu, 28 Mar 2024 15:44:22 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rprvS-0004O1-13; Thu, 28 Mar 2024 15:44:22 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rprvR-0005Et-Up; Thu, 28 Mar 2024 15:44:21 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rprvR-0007Lc-JW; Thu, 28 Mar 2024 15:44:21 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rprvR-0007iX-J1; Thu, 28 Mar 2024 15:44:21 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=Roz/JqM9pWGGgye4f+BoM7cIETnBDhOo7U8jKiZ1ieY=; b=jYr2RBSus2L5IC0AUuu8B+B8GW
	3wj6io36n3UM2w9UVD76QNAs6BSt1kErDTERfE7uuM5z2lVMI6jOsREYszOzh5FEM4bLHgi1AGfDd
	x5jrzPcnZWthpEftydciQvpbPG/uCJoL4k/s8UItpQBNx8PoOUn9/Sbk7Oq07G1bSb6g=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 185181: tolerable all pass - PUSHED
X-Osstest-Failures:
    xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    xen=3c9e76cd875e12c88cfc8f0b2770c525da8d6894
X-Osstest-Versions-That:
    xen=8f85af65af76727692b9c2dea4f470f503432d2f
From: osstest service owner 
Date: Thu, 28 Mar 2024 15:44:21 +0000

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          16 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  3c9e76cd875e12c88cfc8f0b2770c525da8d6894
baseline version:
 xen                  8f85af65af76727692b9c2dea4f470f503432d2f

Last test of basis   185176  2024-03-27 17:02:08 Z    0 days
Testing same since   185181  2024-03-28 12:00:24 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper 

jobs:
 build-arm64-xsm                                              pass    
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-amd64-libvirt                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 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
   8f85af65af..3c9e76cd87  3c9e76cd875e12c88cfc8f0b2770c525da8d6894 -> smoke


From xen-devel-bounces@lists.xenproject.org Thu Mar 28 15:54:49 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 15:54:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699004.1091356 (Exim 4.92)
	(envelope-from )
	id 1rps5V-0006mI-7A; Thu, 28 Mar 2024 15:54:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699004.1091356; Thu, 28 Mar 2024 15:54:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rps5V-0006mB-48; Thu, 28 Mar 2024 15:54:45 +0000
Received: by outflank-mailman (input) for mailman id 699004;
 Thu, 28 Mar 2024 15:54:44 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rps5U-0006m5-9t
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 15:54:44 +0000
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com
 [2a00:1450:4864:20::52a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7e1863c4-ed1b-11ee-afe3-a90da7624cb6;
 Thu, 28 Mar 2024 16:54:43 +0100 (CET)
Received: by mail-ed1-x52a.google.com with SMTP id
 4fb4d7f45d1cf-56c08d1e900so1331688a12.3
 for ; Thu, 28 Mar 2024 08:54:43 -0700 (PDT)
Received: from m1x-phil.lan (pas38-h02-176-184-5-52.dsl.sta.abo.bbox.fr.
 [176.184.5.52]) by smtp.gmail.com with ESMTPSA id
 f4-20020a056402194400b0056c4cdc987esm968928edz.8.2024.03.28.08.54.40
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Thu, 28 Mar 2024 08:54:42 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7e1863c4-ed1b-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1711641282; x=1712246082; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:from:to:cc:subject:date:message-id:reply-to;
        bh=9jGFJM87g0s+QJiSxyo+fFml0FCFfdp02zPTSZX+zrs=;
        b=IPfKbGGB6oISl05QkxKMgKjKA/rQehTGRooIeNAzefd5hUyyEFqOch7j7wnEKL399m
         p4F9MgAllghxKulDzn76UPGod4z11js/72ZOy5SYA1iD7xVpZWxJYVgKPvnOIV++zlbX
         JlSG/K+fxYZhTzgJa5/RD9knN5t1Y45aTknWwP76XKXqYY29937JGZkiUTqLU+MYlUfi
         p++qu+4XV4BpWB604tnq3xcJVuTdtTmtmhmdmMf3o5cUR6TV/hHgRkc+lTQELGEztqd6
         kNpABkUeZqONod6ogs4LyeuyDnnQ+IkKdc3EjlAa4V/s7+oOYHtpbCBV4zu50dkR8Dzq
         cs8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711641283; x=1712246083;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=9jGFJM87g0s+QJiSxyo+fFml0FCFfdp02zPTSZX+zrs=;
        b=IADmHnFsXEaCpHd1g399LQOrrrLglT5uXOc4mM245L1Q/uDiWL14Rqgr/tE7YhANdF
         5S8i1yGCisHL7SPqPbmzyPVW9qFtBqlZOz03vV+yqrkzrPGMWEBz3J2sVseZjbcciIdE
         iYDxkqvz/SOEjCMj2E8ooMGSpvYoZ2642iKnorx8OdLJwxg/pghQ46SvDV9J2Gv0p0yu
         dI5PgpENEEE+u/3UIzMJvraXgSEsx1yGds8aaHpiGntmXBAo9l1nDFXZarDf689Z72yc
         pvhiaPrm2qSV2mHsr4k3ZWiwRfNmfFcr/vcye2O40/Q27F14uaEC1QbLyI0NAlf0eGYA
         zZag==
X-Forwarded-Encrypted: i=1; AJvYcCWOpLdQHM3Gf44UN3eqPzCRmOdvKRAEfZ/+JnsxgFvJ5h4+1QiSKojlz9NMusbST0yg+KuxdixHDQwFn8aozG1XK+z2aJtcet8JUY8iEbI=
X-Gm-Message-State: AOJu0Yz4u15TWgNkbD/wpx3zD5kKazja+NNLeo1fU6xUq459OAKyaepq
	FrWz/XwvUsc3HrriiFTh8p6O+u6x5ZG1V7a+wJCIF8phdYg7UFCkHrsU4fGWErc=
X-Google-Smtp-Source: AGHT+IF49DaXGjHZW9HD9cL+HRM/1d+LDb7jwUvaelY4b9yVxDNea692GvPtisYDleFJnYb7JifYOA==
X-Received: by 2002:a50:99c2:0:b0:56c:2ef7:f3ed with SMTP id n2-20020a5099c2000000b0056c2ef7f3edmr2553704edb.35.1711641282639;
        Thu, 28 Mar 2024 08:54:42 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org
Cc: Richard Henderson ,
	Eduardo Habkost ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org,
	Bernhard Beschow ,
	Thomas Huth ,
	Marcel Apfelbaum ,
	"Michael S. Tsirkin" ,
	Paolo Bonzini ,
	Igor Mammedov ,
	Anthony Perard ,
	Ani Sinha ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
Subject: [RFC PATCH-for-9.1 00/29] hw/i386/pc: Decouple ISA vs PCI-based machines
Date: Thu, 28 Mar 2024 16:54:08 +0100
Message-ID: <20240328155439.58719-1-philmd@linaro.org>
X-Mailer: git-send-email 2.41.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

Hi Igor,

This is the first steps to decouple the isapc VS q35/i440fx
machines. A new TYPE_PC_PCI_MACHINE is introduced to help
differentiating. Fields unrelated to the legacy isapc are
moved to the new PcPciMachineState structure.

More work remain in hw/i386/pc_piix.c so we can build a
binary with only CONFIG_ISAPC enabled.

Based-on: <20240327095124.73639-1-philmd@linaro.org>
"hw/i386: Remove deprecated pc-i440fx-2.0 -> 2.3 machines"

Philippe Mathieu-Daudé (29):
  hw/i386/pc: Declare CPU QOM types using DEFINE_TYPES() macro
  hw/i386/pc: Extract pc_machine_is_pci_enabled() helper
  hw/i386/pc: Pass base machine type as argument to DEFINE_PC_MACHINE()
  hw/i386/pc: Introduce PC_PCI_MACHINE QOM type
  hw/i386/pc: Remove PCMachineClass::pci_enabled field
  hw/i386/pc: Move pci_root_uid field to PcPciMachineClass
  hw/i386/pc: Call fw_cfg_add_extra_pci_roots() in pc_pci_machine_done()
  hw/i386/pc: Move CXLState to PcPciMachineState
  hw/i386/pc: Pass PCMachineState argument to acpi_setup()
  hw/i386/pc: Remove PCMachineClass::has_acpi_build field
  hw/i386/pc: Move acpi_setup() call to pc_pci_machine_done()
  hw/i386/pc: Move acpi_build_enabled to PcPciMachineState
  hw/i386/pc: Remove non-PCI code from pc_system_firmware_init()
  hw/i386/pc: Move pc_system_flash_create() to pc_pci_machine_initfn()
  hw/i386/pc: Move FW/pflash related fields to PcPciMachineState
  hw/i386/pc: Move south-bridge related fields to PcPciMachine
  hw/i386/pc: Inline gigabyte_align()
  hw/i386/pc: Inline has_reserved_memory()
  hw/i386/pc: Pass PcPciMachineState argument to CXL helpers
  hw/i386/pc: Pass PcPciMachineState argument to pc_pci_hole64_start()
  hw/i386/fw_cfg: Include missing 'qapi-types-machine.h' header
  hw/i386/fw_cfg: Define fw_cfg_build_smbios() stub
  hw/i386/fw_cfg: Inline smbios_defaults()
  hw/i386/fw_cfg: Inline smbios_legacy_mode()
  hw/i386/fw_cfg: Replace smbios_defaults() by !smbios_legacy_mode()
  hw/i386/fw_cfg: Factor fw_cfg_build_smbios_legacy() out
  hw/i386/pc: Call fw_cfg_build_smbios_legacy() in pc_machine_done()
  hw/i386/pc: Rename pc_init1() -> pc_piix_init()
  hw/i386/pc: Move ISA-only PC machine to pc_isa.c

 MAINTAINERS                  |   1 +
 hw/i386/acpi-build.h         |   3 +-
 hw/i386/fw_cfg.h             |   2 +
 include/hw/i386/pc.h         |  78 +++++++-------
 hw/i386/acpi-build.c         |  34 ++++--
 hw/i386/fw_cfg-smbios-stub.c |  19 ++++
 hw/i386/fw_cfg.c             |  35 +++---
 hw/i386/pc.c                 | 199 ++++++++++++++++++++++-------------
 hw/i386/pc_isa.c             |  33 ++++++
 hw/i386/pc_piix.c            |  91 +++++++---------
 hw/i386/pc_q35.c             |  12 ++-
 hw/i386/pc_sysfw.c           |  68 +++++-------
 hw/i386/xen/xen-hvm.c        |   3 +-
 hw/isa/piix.c                |   2 +-
 hw/pci-host/i440fx.c         |   4 +-
 hw/pci-host/q35.c            |   2 +-
 hw/i386/meson.build          |   2 +
 17 files changed, 342 insertions(+), 246 deletions(-)
 create mode 100644 hw/i386/fw_cfg-smbios-stub.c
 create mode 100644 hw/i386/pc_isa.c

-- 
2.41.0



From xen-devel-bounces@lists.xenproject.org Thu Mar 28 15:54:52 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 15:54:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699005.1091367 (Exim 4.92)
	(envelope-from )
	id 1rps5c-00072p-EA; Thu, 28 Mar 2024 15:54:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699005.1091367; Thu, 28 Mar 2024 15:54:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rps5c-00072H-Ao; Thu, 28 Mar 2024 15:54:52 +0000
Received: by outflank-mailman (input) for mailman id 699005;
 Thu, 28 Mar 2024 15:54:51 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rps5b-00071m-A6
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 15:54:51 +0000
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com
 [2a00:1450:4864:20::62f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 81b0bf09-ed1b-11ee-a1ef-f123f15fe8a2;
 Thu, 28 Mar 2024 16:54:49 +0100 (CET)
Received: by mail-ej1-x62f.google.com with SMTP id
 a640c23a62f3a-a468226e135so141646566b.0
 for ; Thu, 28 Mar 2024 08:54:49 -0700 (PDT)
Received: from m1x-phil.lan (pas38-h02-176-184-5-52.dsl.sta.abo.bbox.fr.
 [176.184.5.52]) by smtp.gmail.com with ESMTPSA id
 f13-20020a1709062c4d00b00a4df82aa6a7sm882455ejh.219.2024.03.28.08.54.47
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Thu, 28 Mar 2024 08:54:48 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 81b0bf09-ed1b-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1711641289; x=1712246089; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=8xoyjiIw561YlGIaQRdLbxciG2dWfen0yY52crHbWn0=;
        b=zvuhEkeh0L+78tpAIgLDZI5zyApCsWNLjhpa8HgahhVcrSjd3yi1t1APPfZscnn1Ba
         6AVNjgIYYbxAP9HyGRau26VeodkgTpHY0DoihcFFxheZn8ry0Q4Y0og5toGSK0QBZBRJ
         AoqmPobglXRz/WBAwNYxvChm3i9DHMeFTNEsvHIoAdkoMpwvAIWUakmZG/IXJjKoh+8v
         jrKtmZinG4bXx/72lab40FPvUOtybeoMtvANIHlcQqRfxw+6lNGP8lnuG8Vq5i9XEOsB
         0ZWhfg8fkKkd/PE8ssHH5JvB4zlz8n1ab2z+zUBU2kcJzLcC/RBgypZJ8sjwdnKviqMO
         yJTw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711641289; x=1712246089;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=8xoyjiIw561YlGIaQRdLbxciG2dWfen0yY52crHbWn0=;
        b=sCbO5tkDckaLljRkDbTj2wVO3s2eTbT9MqoYlm5Wg29jNgHGdf4FqRAttfjs9npUwg
         38icl65Of2WcoruYQ7Duc5S9jSjerZji1iepAq+29sTNrKfP/IyZMbp3QClFNcqsoJ88
         GXKQeye6Q9tXyM/7x0e2FnN3Yj7EJyReBDAph6P77QRYjoP7+Hi+Cwckwwg4m2zrCAVX
         HjmP8doxAZuVEzR7AFTzAD+ZsRdhsbevRtfxImFyu7A2Pz4PTVcP1yU/nJrSSL5We5UX
         t7iogU0IENShjVweD/ZeOV4aXmqxdmLyXJmACfKP3DFKjdjKzRK6HNqlJjMBVAbDU3a9
         n8HQ==
X-Forwarded-Encrypted: i=1; AJvYcCVdIo2dn7PQ1zb3kV2i6xRPRWgbkJsbFYFW0by6UEKaz64FzZadBOcNQdr5ZPGyDE6NaTU2gY47cXZr2DmVrBrefX6d1+DHLguxmZvme0A=
X-Gm-Message-State: AOJu0YxBIccQnsS9r2qjDUY4vEI36R3UiN+Azth+3SyCGhTWkJGUtU32
	T7GxiqZ5T2UF0ktjCo07py1WSD/6Oa6w28QmEDg6StKD4mAbbE7dCSnuMA/xlxw=
X-Google-Smtp-Source: AGHT+IF5nPNNk6iWv9K9gmp+zF28jumHMVCID22KWO3BYQCYDbLztVinN6sDOrMp2q9Gec/eNpwGrA==
X-Received: by 2002:a17:906:4892:b0:a47:3664:1b98 with SMTP id v18-20020a170906489200b00a4736641b98mr2095599ejq.7.1711641288815;
        Thu, 28 Mar 2024 08:54:48 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org
Cc: Richard Henderson ,
	Eduardo Habkost ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org,
	Bernhard Beschow ,
	Thomas Huth ,
	Marcel Apfelbaum ,
	"Michael S. Tsirkin" ,
	Paolo Bonzini ,
	Igor Mammedov ,
	Anthony Perard ,
	Ani Sinha ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
Subject: [RFC PATCH-for-9.1 01/29] hw/i386/pc: Declare CPU QOM types using DEFINE_TYPES() macro
Date: Thu, 28 Mar 2024 16:54:09 +0100
Message-ID: <20240328155439.58719-2-philmd@linaro.org>
X-Mailer: git-send-email 2.41.0
In-Reply-To: <20240328155439.58719-1-philmd@linaro.org>
References: <20240328155439.58719-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

When multiple QOM types are registered in the same file,
it is simpler to use the the DEFINE_TYPES() macro. In
particular because type array declared with such macro
are easier to review.

In few commits we are going to add more types, so replace
the type_register_static() to ease further reviews.

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/i386/pc.c | 31 ++++++++++++++-----------------
 1 file changed, 14 insertions(+), 17 deletions(-)

diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 0be8f08c47..2c41b08478 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1810,23 +1810,20 @@ static void pc_machine_class_init(ObjectClass *oc, void *data)
         pc_machine_set_fd_bootchk);
 }
 
-static const TypeInfo pc_machine_info = {
-    .name = TYPE_PC_MACHINE,
-    .parent = TYPE_X86_MACHINE,
-    .abstract = true,
-    .instance_size = sizeof(PCMachineState),
-    .instance_init = pc_machine_initfn,
-    .class_size = sizeof(PCMachineClass),
-    .class_init = pc_machine_class_init,
-    .interfaces = (InterfaceInfo[]) {
-         { TYPE_HOTPLUG_HANDLER },
-         { }
+static const TypeInfo pc_machine_types[] = {
+    {
+        .name           = TYPE_PC_MACHINE,
+        .parent         = TYPE_X86_MACHINE,
+        .abstract       = true,
+        .instance_size  = sizeof(PCMachineState),
+        .instance_init  = pc_machine_initfn,
+        .class_size     = sizeof(PCMachineClass),
+        .class_init     = pc_machine_class_init,
+        .interfaces     = (InterfaceInfo[]) {
+             { TYPE_HOTPLUG_HANDLER },
+             { }
+        },
     },
 };
 
-static void pc_machine_register_types(void)
-{
-    type_register_static(&pc_machine_info);
-}
-
-type_init(pc_machine_register_types)
+DEFINE_TYPES(pc_machine_types)
-- 
2.41.0



From xen-devel-bounces@lists.xenproject.org Thu Mar 28 15:54:58 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 15:54:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699006.1091377 (Exim 4.92)
	(envelope-from )
	id 1rps5i-0007N2-Qc; Thu, 28 Mar 2024 15:54:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699006.1091377; Thu, 28 Mar 2024 15:54:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rps5i-0007Mt-Nc; Thu, 28 Mar 2024 15:54:58 +0000
Received: by outflank-mailman (input) for mailman id 699006;
 Thu, 28 Mar 2024 15:54:57 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rps5h-00071m-BB
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 15:54:57 +0000
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com
 [2a00:1450:4864:20::530])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 85787c7a-ed1b-11ee-a1ef-f123f15fe8a2;
 Thu, 28 Mar 2024 16:54:55 +0100 (CET)
Received: by mail-ed1-x530.google.com with SMTP id
 4fb4d7f45d1cf-568c714a9c7so1311102a12.2
 for ; Thu, 28 Mar 2024 08:54:55 -0700 (PDT)
Received: from m1x-phil.lan (pas38-h02-176-184-5-52.dsl.sta.abo.bbox.fr.
 [176.184.5.52]) by smtp.gmail.com with ESMTPSA id
 q4-20020aa7d444000000b00568d6a20717sm991251edr.52.2024.03.28.08.54.53
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Thu, 28 Mar 2024 08:54:54 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 85787c7a-ed1b-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1711641295; x=1712246095; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=djs4Th+kjoxzBDQIObaEvmf5VGdYfcKG9Is4pj2rcJA=;
        b=j+ae31P+QTOwkdt0sOkfiBijANSyo/hdbRqKY14Hj4HnYOsGvyhYKoiotr13ze918E
         hKSphsF6r7vX5FAs37JJ//FnDE0PzEDu2poMvN7tG+olcJTiFaODpdL5uD5FQr63+FRL
         rV/P2lk4OuyHxX7EhjN8z8iCIEN7BbldPlq2f5bqWGU5+oTOH7XnS95HAOhfu0I+zUan
         J2lkWBOYQbt2vW0Ta7fsmAPCrGsRPdN7mPj4/19oVNYi9P/XY3eRB5wUCjUZVYpKt+ZL
         3io5zq/6kpiefrcddRvildoinyQt7RcheY51hZnKBUBze41wH1XH22dUCNMPX8lQZbq+
         hTJw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711641295; x=1712246095;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=djs4Th+kjoxzBDQIObaEvmf5VGdYfcKG9Is4pj2rcJA=;
        b=K0wRrncQ9BHiz+Ph3lMjkX3piA0VavgmT19yL/b4wemUVQCXRca5ZgHi3Of8NKdrBE
         x+E78Gckfg944+KVAl5wbyWRbcYY8ZA5C2wKhiRFYZLHISZwqKMvQS3N/fhZNL3X0Zfv
         DGWldL5zoaoQzosLt98Me6gcfMKxtWJYPxXULsqmaJyU+8FeOYjwhqYCvRRkDn7VEl71
         jr4dSsYpgsA8QxGoYp3q2J3p7jCl30eI60rX/OAkUuex37JAIVh/ErB2yzO6TcOyaApW
         cgc6ujWx0r5Cf/fYSf5NtV4bpVI/YldxVRz29dup+Q0vX+HoxnF8OjCsfpR2+UVgezBm
         /FFA==
X-Forwarded-Encrypted: i=1; AJvYcCVgf/le8uPcEMgOGQtWjdJITcLLxXzHBd+5eKHYbjzNqCX/Xhe6BJZ4XIkVSW2EhE76T7Nh1gQY4rvKSQoV288n6HEYYdrJY+UTXebaA3o=
X-Gm-Message-State: AOJu0Yx+uNjm6c/Ne5eFf7S40PonvC31NfkTf58l98enUiryc94QV4u1
	EGmUbfn/BtHhI0dTcOR9icZb+ortz3dvWf8i+Z99W7olGUNAZWP/ZZDR4ID5Tf8=
X-Google-Smtp-Source: AGHT+IEDfKWv0Uve3VOXzzLi06hxTo6fvyAau83kjSqRi6VaUabzP1VqK7SGL6r5ov939b9QS2ny5A==
X-Received: by 2002:a50:d6d8:0:b0:568:ae7:bc0 with SMTP id l24-20020a50d6d8000000b005680ae70bc0mr2299951edj.34.1711641295199;
        Thu, 28 Mar 2024 08:54:55 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org
Cc: Richard Henderson ,
	Eduardo Habkost ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org,
	Bernhard Beschow ,
	Thomas Huth ,
	Marcel Apfelbaum ,
	"Michael S. Tsirkin" ,
	Paolo Bonzini ,
	Igor Mammedov ,
	Anthony Perard ,
	Ani Sinha ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
Subject: [RFC PATCH-for-9.1 02/29] hw/i386/pc: Extract pc_machine_is_pci_enabled() helper
Date: Thu, 28 Mar 2024 16:54:10 +0100
Message-ID: <20240328155439.58719-3-philmd@linaro.org>
X-Mailer: git-send-email 2.41.0
In-Reply-To: <20240328155439.58719-1-philmd@linaro.org>
References: <20240328155439.58719-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Introduce the pc_machine_is_pci_enabled() helper to be
able to alter PCMachineClass fields later.

Signed-off-by: Philippe Mathieu-Daudé 
---
 include/hw/i386/pc.h |  2 ++
 hw/i386/pc.c         | 11 +++++++++--
 hw/i386/pc_piix.c    | 11 ++++++-----
 hw/i386/pc_q35.c     |  2 +-
 hw/i386/pc_sysfw.c   | 11 ++++-------
 5 files changed, 22 insertions(+), 15 deletions(-)

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 0ad971782c..6b885424bb 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -129,6 +129,8 @@ struct PCMachineClass {
 #define TYPE_PC_MACHINE "generic-pc-machine"
 OBJECT_DECLARE_TYPE(PCMachineState, PCMachineClass, PC_MACHINE)
 
+bool pc_machine_is_pci_enabled(PCMachineState *pcms);
+
 /* ioapic.c */
 
 GSIState *pc_gsi_create(qemu_irq **irqs, bool pci_enabled);
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 2c41b08478..7065f11e97 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -814,6 +814,7 @@ void pc_memory_init(PCMachineState *pcms,
     hwaddr maxphysaddr, maxusedaddr;
     hwaddr cxl_base, cxl_resv_end = 0;
     X86CPU *cpu = X86_CPU(first_cpu);
+    bool pci_enabled = pc_machine_is_pci_enabled(pcms);
 
     assert(machine->ram_size == x86ms->below_4g_mem_size +
                                 x86ms->above_4g_mem_size);
@@ -949,7 +950,7 @@ void pc_memory_init(PCMachineState *pcms,
     option_rom_mr = g_malloc(sizeof(*option_rom_mr));
     memory_region_init_ram(option_rom_mr, NULL, "pc.rom", PC_ROM_SIZE,
                            &error_fatal);
-    if (pcmc->pci_enabled) {
+    if (pci_enabled) {
         memory_region_set_readonly(option_rom_mr, true);
     }
     memory_region_add_subregion_overlap(rom_memory,
@@ -1642,6 +1643,7 @@ static void pc_machine_initfn(Object *obj)
 {
     PCMachineState *pcms = PC_MACHINE(obj);
     PCMachineClass *pcmc = PC_MACHINE_GET_CLASS(pcms);
+    bool pci_enabled = pc_machine_is_pci_enabled(pcms);
 
 #ifdef CONFIG_VMPORT
     pcms->vmport = ON_OFF_AUTO_AUTO;
@@ -1668,7 +1670,7 @@ static void pc_machine_initfn(Object *obj)
     pcms->pcspk = isa_new(TYPE_PC_SPEAKER);
     object_property_add_alias(OBJECT(pcms), "pcspk-audiodev",
                               OBJECT(pcms->pcspk), "audiodev");
-    if (pcmc->pci_enabled) {
+    if (pci_enabled) {
         cxl_machine_init(obj, &pcms->cxl_devices_state);
     }
 
@@ -1810,6 +1812,11 @@ static void pc_machine_class_init(ObjectClass *oc, void *data)
         pc_machine_set_fd_bootchk);
 }
 
+bool pc_machine_is_pci_enabled(PCMachineState *pcms)
+{
+    return PC_MACHINE_GET_CLASS(pcms)->pci_enabled;
+}
+
 static const TypeInfo pc_machine_types[] = {
     {
         .name           = TYPE_PC_MACHINE,
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index c00d2a66a6..1be1e050c7 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -117,6 +117,7 @@ static void pc_init1(MachineState *machine, const char *pci_type)
     MemoryRegion *rom_memory = system_memory;
     ram_addr_t lowmem;
     uint64_t hole64_size = 0;
+    bool pci_enabled = pc_machine_is_pci_enabled(pcms);
 
     /*
      * Calculate ram split, for memory below and above 4G.  It's a bit
@@ -187,7 +188,7 @@ static void pc_init1(MachineState *machine, const char *pci_type)
         kvmclock_create(pcmc->kvmclock_create_always);
     }
 
-    if (pcmc->pci_enabled) {
+    if (pci_enabled) {
         pci_memory = g_new(MemoryRegion, 1);
         memory_region_init(pci_memory, NULL, "pci", UINT64_MAX);
         rom_memory = pci_memory;
@@ -234,9 +235,9 @@ static void pc_init1(MachineState *machine, const char *pci_type)
         }
     }
 
-    gsi_state = pc_gsi_create(&x86ms->gsi, pcmc->pci_enabled);
+    gsi_state = pc_gsi_create(&x86ms->gsi, pci_enabled);
 
-    if (pcmc->pci_enabled) {
+    if (pci_enabled) {
         PCIDevice *pci_dev;
         DeviceState *dev;
         size_t i;
@@ -308,7 +309,7 @@ static void pc_init1(MachineState *machine, const char *pci_type)
         x86_register_ferr_irq(x86ms->gsi[13]);
     }
 
-    pc_vga_init(isa_bus, pcmc->pci_enabled ? pcms->pcibus : NULL);
+    pc_vga_init(isa_bus, pci_enabled ? pcms->pcibus : NULL);
 
     assert(pcms->vmport != ON_OFF_AUTO__MAX);
     if (pcms->vmport == ON_OFF_AUTO_AUTO) {
@@ -322,7 +323,7 @@ static void pc_init1(MachineState *machine, const char *pci_type)
     pc_nic_init(pcmc, isa_bus, pcms->pcibus);
 
 #ifdef CONFIG_IDE_ISA
-    if (!pcmc->pci_enabled) {
+    if (!pci_enabled) {
         DriveInfo *hd[MAX_IDE_BUS * MAX_IDE_DEVS];
         int i;
 
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index b5922b44af..43ee1e595c 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -145,7 +145,7 @@ static void pc_q35_init(MachineState *machine)
     bool keep_pci_slot_hpc;
     uint64_t pci_hole64_size = 0;
 
-    assert(pcmc->pci_enabled);
+    assert(pc_machine_is_pci_enabled(pcms));
 
     /* Check whether RAM fits below 4G (leaving 1/2 GByte for IO memory
      * and 256 Mbytes for PCI Express Enhanced Configuration Access Mapping
diff --git a/hw/i386/pc_sysfw.c b/hw/i386/pc_sysfw.c
index 3efabbbab2..862a082b0a 100644
--- a/hw/i386/pc_sysfw.c
+++ b/hw/i386/pc_sysfw.c
@@ -93,9 +93,7 @@ static PFlashCFI01 *pc_pflash_create(PCMachineState *pcms,
 
 void pc_system_flash_create(PCMachineState *pcms)
 {
-    PCMachineClass *pcmc = PC_MACHINE_GET_CLASS(pcms);
-
-    if (pcmc->pci_enabled) {
+    if (pc_machine_is_pci_enabled(pcms)) {
         pcms->flash[0] = pc_pflash_create(pcms, "system.flash0",
                                           "pflash0");
         pcms->flash[1] = pc_pflash_create(pcms, "system.flash1",
@@ -108,7 +106,7 @@ void pc_system_flash_cleanup_unused(PCMachineState *pcms)
     char *prop_name;
     int i;
 
-    assert(PC_MACHINE_GET_CLASS(pcms)->pci_enabled);
+    assert(pc_machine_is_pci_enabled(pcms));
 
     for (i = 0; i < ARRAY_SIZE(pcms->flash); i++) {
         if (!qdev_is_realized(DEVICE(pcms->flash[i]))) {
@@ -146,7 +144,7 @@ static void pc_system_flash_map(PCMachineState *pcms,
     void *flash_ptr;
     int flash_size;
 
-    assert(PC_MACHINE_GET_CLASS(pcms)->pci_enabled);
+    assert(pc_machine_is_pci_enabled(pcms));
 
     for (i = 0; i < ARRAY_SIZE(pcms->flash); i++) {
         system_flash = pcms->flash[i];
@@ -201,11 +199,10 @@ static void pc_system_flash_map(PCMachineState *pcms,
 void pc_system_firmware_init(PCMachineState *pcms,
                              MemoryRegion *rom_memory)
 {
-    PCMachineClass *pcmc = PC_MACHINE_GET_CLASS(pcms);
     int i;
     BlockBackend *pflash_blk[ARRAY_SIZE(pcms->flash)];
 
-    if (!pcmc->pci_enabled) {
+    if (!pc_machine_is_pci_enabled(pcms)) {
         x86_bios_rom_init(MACHINE(pcms), "bios.bin", rom_memory, true);
         return;
     }
-- 
2.41.0



From xen-devel-bounces@lists.xenproject.org Thu Mar 28 15:55:05 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 15:55:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699008.1091387 (Exim 4.92)
	(envelope-from )
	id 1rps5p-0007kB-31; Thu, 28 Mar 2024 15:55:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699008.1091387; Thu, 28 Mar 2024 15:55:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rps5o-0007k4-Vx; Thu, 28 Mar 2024 15:55:04 +0000
Received: by outflank-mailman (input) for mailman id 699008;
 Thu, 28 Mar 2024 15:55:03 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rps5n-00071m-Oe
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 15:55:03 +0000
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com
 [2a00:1450:4864:20::52b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 894fca6a-ed1b-11ee-a1ef-f123f15fe8a2;
 Thu, 28 Mar 2024 16:55:02 +0100 (CET)
Received: by mail-ed1-x52b.google.com with SMTP id
 4fb4d7f45d1cf-56c441e66a5so1506470a12.0
 for ; Thu, 28 Mar 2024 08:55:02 -0700 (PDT)
Received: from m1x-phil.lan (pas38-h02-176-184-5-52.dsl.sta.abo.bbox.fr.
 [176.184.5.52]) by smtp.gmail.com with ESMTPSA id
 d15-20020a056402400f00b0056c5395e581sm753171eda.70.2024.03.28.08.54.59
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Thu, 28 Mar 2024 08:55:01 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 894fca6a-ed1b-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1711641301; x=1712246101; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=2NXhpW96pCgkEoWuYwRT5cvChay+RSkHkEuAn7B/Dd0=;
        b=bkqBL4bo2Svvjj7lEOuBvYoMO9KyQw1FlEWq8WhstjxaJe5bYOJ2lutvnT0lVF37El
         kXxDRSVgVXG7daUTsiz59Jp2hRR0LR/R5lciyFjSDRuWW6XXFMnjFJghzb9zjE8d4z2t
         1UZebdVecrURjkLyjcJfRJwl4AFfIaF7ou6VlZHT1mS2reFhFHe0ckoG3wRbDwJp4Csv
         zsOPYwWYnlWNCewDgG8qGJBFt7drYCaX1TQ9AraDv7m6Tj6N/fbq1GzntKUdXccX0MpH
         cOCYxrN278D0Y1UVqYvalm0SsVwkmUDmA7VlPJJyPTBZuBi9PLR9swsoHY2suSs8T6oa
         zBbg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711641301; x=1712246101;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=2NXhpW96pCgkEoWuYwRT5cvChay+RSkHkEuAn7B/Dd0=;
        b=XKDcOvqv2vMEWxzzryQdZrEVwUnqpVSq8Y1znEOTUCej69+L+eypyW0rphHZ1e4W0Y
         Wss0wAPuKnchKuWawBUtOqFylq8pVOuhqXq1Mn2HV6J2hJrhvOS3GEVBvvNAjbuO84rt
         rnHa7v1H1TxObKay/p8IKH4K6LOyNFioq0p7Hd3gCq2TbnpHRGjMrYAs4Q9PEAaH/Y85
         suyy5jxvJxsy/JaeKkkmgyFDQeBl/ufMghQ/NuZKKwL4rpMX2EILlOjnY5g5mE7X3xV6
         d0OX2A8hQ5OUGnjODpn54I8EE6lHAvCqTY89LV936SvYdWSh5fg2AIJt6Fx9Ev+g8+UD
         LBqA==
X-Forwarded-Encrypted: i=1; AJvYcCVilW8zfLRtF0jW1HiH7xiz76ZaJxmAAcsf7brJ+Rl96H9VaFE1MlvvQ2ui4o32tTR0dJCbWZpnsTv3z89KuAp9RKOUTM5EvON0Ef+9bcw=
X-Gm-Message-State: AOJu0YwSc+xZWf1UBoYox8q1pKFalShlMBZL+BP7rmH3yG71kjPHaTj4
	o5LNBGqa107fORaQO4tIQGs8JqFfnYT5qI04qByDoqSQrFSDxepUpeNjydEq8AY=
X-Google-Smtp-Source: AGHT+IF6f1YMBvOfsUocaggEtYJ9a+Kecpnx8/ab4gXfJ3RdBR3huqwiywmto+50jVUBk5TY6jKE5g==
X-Received: by 2002:a50:a412:0:b0:566:f81:41a1 with SMTP id u18-20020a50a412000000b005660f8141a1mr2402222edb.22.1711641301544;
        Thu, 28 Mar 2024 08:55:01 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org
Cc: Richard Henderson ,
	Eduardo Habkost ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org,
	Bernhard Beschow ,
	Thomas Huth ,
	Marcel Apfelbaum ,
	"Michael S. Tsirkin" ,
	Paolo Bonzini ,
	Igor Mammedov ,
	Anthony Perard ,
	Ani Sinha ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
Subject: [RFC PATCH-for-9.1 03/29] hw/i386/pc: Pass base machine type as argument to DEFINE_PC_MACHINE()
Date: Thu, 28 Mar 2024 16:54:11 +0100
Message-ID: <20240328155439.58719-4-philmd@linaro.org>
X-Mailer: git-send-email 2.41.0
In-Reply-To: <20240328155439.58719-1-philmd@linaro.org>
References: <20240328155439.58719-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Currently PC machines are based on TYPE_PC_MACHINE.
In preparation of being based on different types,
pass the current type as argument.

Signed-off-by: Philippe Mathieu-Daudé 
---
 include/hw/i386/pc.h | 4 ++--
 hw/i386/pc_piix.c    | 9 +++++----
 hw/i386/pc_q35.c     | 3 ++-
 3 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 6b885424bb..33023ebbbe 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -268,7 +268,7 @@ extern const size_t pc_compat_2_4_len;
 extern GlobalProperty pc_compat_2_3[];
 extern const size_t pc_compat_2_3_len;
 
-#define DEFINE_PC_MACHINE(suffix, namestr, initfn, optsfn) \
+#define DEFINE_PC_MACHINE(suffix, namestr, initfn, optsfn, parent_class) \
     static void pc_machine_##suffix##_class_init(ObjectClass *oc, void *data) \
     { \
         MachineClass *mc = MACHINE_CLASS(oc); \
@@ -277,7 +277,7 @@ extern const size_t pc_compat_2_3_len;
     } \
     static const TypeInfo pc_machine_type_##suffix = { \
         .name       = namestr TYPE_MACHINE_SUFFIX, \
-        .parent     = TYPE_PC_MACHINE, \
+        .parent     = parent_class, \
         .class_init = pc_machine_##suffix##_class_init, \
     }; \
     static void pc_machine_init_##suffix(void) \
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 1be1e050c7..b9f85148e3 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -462,7 +462,8 @@ static void pc_xen_hvm_init(MachineState *machine)
         } \
         pc_init1(machine, TYPE_I440FX_PCI_DEVICE); \
     } \
-    DEFINE_PC_MACHINE(suffix, name, pc_init_##suffix, optionfn)
+    DEFINE_PC_MACHINE(suffix, name, pc_init_##suffix, optionfn, \
+                      TYPE_PC_MACHINE)
 
 static void pc_i440fx_machine_options(MachineClass *m)
 {
@@ -824,7 +825,7 @@ static void isapc_machine_options(MachineClass *m)
 }
 
 DEFINE_PC_MACHINE(isapc, "isapc", pc_init_isa,
-                  isapc_machine_options);
+                  isapc_machine_options, TYPE_PC_MACHINE);
 #endif
 
 #ifdef CONFIG_XEN
@@ -837,7 +838,7 @@ static void xenfv_4_2_machine_options(MachineClass *m)
 }
 
 DEFINE_PC_MACHINE(xenfv_4_2, "xenfv-4.2", pc_xen_hvm_init,
-                  xenfv_4_2_machine_options);
+                  xenfv_4_2_machine_options, TYPE_PC_MACHINE);
 
 static void xenfv_3_1_machine_options(MachineClass *m)
 {
@@ -849,5 +850,5 @@ static void xenfv_3_1_machine_options(MachineClass *m)
 }
 
 DEFINE_PC_MACHINE(xenfv, "xenfv-3.1", pc_xen_hvm_init,
-                  xenfv_3_1_machine_options);
+                  xenfv_3_1_machine_options, TYPE_PC_MACHINE);
 #endif
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index 43ee1e595c..7dbee38f03 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -338,7 +338,8 @@ static void pc_q35_init(MachineState *machine)
         } \
         pc_q35_init(machine); \
     } \
-    DEFINE_PC_MACHINE(suffix, name, pc_init_##suffix, optionfn)
+    DEFINE_PC_MACHINE(suffix, name, pc_init_##suffix, optionfn, \
+                      TYPE_PC_MACHINE)
 
 
 static void pc_q35_machine_options(MachineClass *m)
-- 
2.41.0



From xen-devel-bounces@lists.xenproject.org Thu Mar 28 15:55:11 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 15:55:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699011.1091397 (Exim 4.92)
	(envelope-from )
	id 1rps5v-0008EZ-Ab; Thu, 28 Mar 2024 15:55:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699011.1091397; Thu, 28 Mar 2024 15:55:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rps5v-0008EP-72; Thu, 28 Mar 2024 15:55:11 +0000
Received: by outflank-mailman (input) for mailman id 699011;
 Thu, 28 Mar 2024 15:55:10 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rps5u-00071m-05
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 15:55:10 +0000
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com
 [2a00:1450:4864:20::629])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8d0c78df-ed1b-11ee-a1ef-f123f15fe8a2;
 Thu, 28 Mar 2024 16:55:08 +0100 (CET)
Received: by mail-ej1-x629.google.com with SMTP id
 a640c23a62f3a-a466a27d30aso140406066b.1
 for ; Thu, 28 Mar 2024 08:55:08 -0700 (PDT)
Received: from m1x-phil.lan (pas38-h02-176-184-5-52.dsl.sta.abo.bbox.fr.
 [176.184.5.52]) by smtp.gmail.com with ESMTPSA id
 x15-20020a170906710f00b00a46cc48ab13sm898792ejj.62.2024.03.28.08.55.06
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Thu, 28 Mar 2024 08:55:07 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8d0c78df-ed1b-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1711641308; x=1712246108; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=sfY93X5jZfIbOGpoyV/9aTUl+UEfpsvUbOU4aZU0Anc=;
        b=Vn9FOkK5rbxKDOcsJsoG4m3RzXE3u6iynMo0RBATJ5xt0gHnevApEuRZNjDuMbnkDc
         Ys6wttlZn3yWUAWSKvGfdxXBWAEaiEMyZTP1eeXTPq6GqZCaq5BPmFGGwFpUOcuYF++5
         1imB5tG5LuhMQ+tQeA0SkgmRmYzb3l+ylDWm9P4sIrRCDzCYDumxfUhsjYfJa4kMWYtD
         efcBFR7vCeq5ox2nLWt81pqX3zIHZVXhW+AhnaZzpzYPDrbGWqx7tRzwI5A6QsZ9aDl5
         rnSAWm2AuaJh/jMHLvfKXGE0w/sgMdKRgssyJJX0Xl1iqfNyn4txRhlUOXgxMQCxzpjT
         /aDA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711641308; x=1712246108;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=sfY93X5jZfIbOGpoyV/9aTUl+UEfpsvUbOU4aZU0Anc=;
        b=bU+ABrF1xDTQQMJWroU8JY6puiFoJyVm0yJT2Ldb4zq0AQuOzhK+ZgaC20uYZqi4FA
         4heJd91xr2LUg1LDGJuAF+BIdgbnIRElYl2OlMkPmmPr9n1/U8XfIt/0TjlaCdOCGaYC
         470D/6u3m2HoJpPn2J8AqFWsHtT8jegT4Ns3wfv9VFzOnPZHLmDpDL4mKlsUZAFm/P6M
         jX/KQ8eIDqMuftuEONF/KmNmtu2yn39D/jtpsxVGHPhtX0RO8OXZQgxj8m3iz9q9nqbu
         iG6FdublxQtXyxW8UpxvdV9hn7qUap1M9lMyF9qA+VPiQOc6rTEsrEcWFGoaF0ZKicz7
         HMgA==
X-Forwarded-Encrypted: i=1; AJvYcCWe2TJmIdHOlqOk5HnjS82gnR5YKxDXvff81NkhxxMNBdL4EqHpYhkrNSrMdwXnjNV5ZO1NXwF5vVUSCeXN1kpzO2M8CivQP4FE0LXXR6g=
X-Gm-Message-State: AOJu0Ywz4cwtl3HC44/a9t72nMt7Yjp7kFcpcZSVsItG179DK59vTga6
	tiza+8Y8V60SAnYEi0jS05hEzTI3a0d6a3FuIPkXL6B47fk6LMvLXo2xkKxqWC8=
X-Google-Smtp-Source: AGHT+IFlVuycGv39RKoJmMuDSzpYHIv5NkuYfdH5v63bTElq/w8DazJwyMi8sNCnbLq/4DH71CZp5g==
X-Received: by 2002:a17:906:2dce:b0:a4e:299f:7f4f with SMTP id h14-20020a1709062dce00b00a4e299f7f4fmr690299eji.48.1711641307840;
        Thu, 28 Mar 2024 08:55:07 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org
Cc: Richard Henderson ,
	Eduardo Habkost ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org,
	Bernhard Beschow ,
	Thomas Huth ,
	Marcel Apfelbaum ,
	"Michael S. Tsirkin" ,
	Paolo Bonzini ,
	Igor Mammedov ,
	Anthony Perard ,
	Ani Sinha ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
Subject: [RFC PATCH-for-9.1 04/29] hw/i386/pc: Introduce PC_PCI_MACHINE QOM type
Date: Thu, 28 Mar 2024 16:54:12 +0100
Message-ID: <20240328155439.58719-5-philmd@linaro.org>
X-Mailer: git-send-email 2.41.0
In-Reply-To: <20240328155439.58719-1-philmd@linaro.org>
References: <20240328155439.58719-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Introduce TYPE_PC_PCI_MACHINE for machines where PCI
is expected (as opposition to the ISA-only PC machine).

This type inherits from the well known TYPE_PC_MACHINE.

Convert I440FX/PIIX and Q35 machines to use it.

Signed-off-by: Philippe Mathieu-Daudé 
---
 include/hw/i386/pc.h | 25 ++++++++++++++++---------
 hw/i386/pc.c         | 25 +++++++++++++++++++++++++
 hw/i386/pc_piix.c    |  6 +++---
 hw/i386/pc_q35.c     |  2 +-
 4 files changed, 45 insertions(+), 13 deletions(-)

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 33023ebbbe..1a4a61148a 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -22,11 +22,8 @@
  * @boot_cpus: number of present VCPUs
  */
 typedef struct PCMachineState {
-    /*< private >*/
     X86MachineState parent_obj;
 
-    /*  */
-
     /* State for other subsystems/APIs: */
     Notifier machine_done;
 
@@ -60,6 +57,12 @@ typedef struct PCMachineState {
     CXLState cxl_devices_state;
 } PCMachineState;
 
+typedef struct PcPciMachineState {
+    PCMachineState parent_obj;
+
+    Notifier machine_done;
+} PcPciMachineState;
+
 #define PC_MACHINE_ACPI_DEVICE_PROP "acpi-device"
 #define PC_MACHINE_MAX_RAM_BELOW_4G "max-ram-below-4g"
 #define PC_MACHINE_VMPORT           "vmport"
@@ -80,12 +83,9 @@ typedef struct PCMachineState {
  *                  way we can use 1GByte pages in the host.
  *
  */
-struct PCMachineClass {
-    /*< private >*/
+typedef struct PCMachineClass {
     X86MachineClass parent_class;
 
-    /*< public >*/
-
     /* Device configuration: */
     bool pci_enabled;
     const char *default_south_bridge;
@@ -124,13 +124,20 @@ struct PCMachineClass {
      * check for memory.
      */
     bool broken_32bit_mem_addr_check;
-};
+} PCMachineClass;
 
-#define TYPE_PC_MACHINE "generic-pc-machine"
+typedef struct PcPciMachineClass {
+    PCMachineClass parent_class;
+} PcPciMachineClass;
+
+#define TYPE_PC_MACHINE "common-pc-machine"
 OBJECT_DECLARE_TYPE(PCMachineState, PCMachineClass, PC_MACHINE)
 
 bool pc_machine_is_pci_enabled(PCMachineState *pcms);
 
+#define TYPE_PC_PCI_MACHINE "pci-pc-machine"
+OBJECT_DECLARE_TYPE(PcPciMachineState, PcPciMachineClass, PC_PCI_MACHINE)
+
 /* ioapic.c */
 
 GSIState *pc_gsi_create(qemu_irq **irqs, bool pci_enabled);
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 7065f11e97..eafd521489 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -621,6 +621,10 @@ void pc_machine_done(Notifier *notifier, void *data)
     pc_cmos_init_late(pcms);
 }
 
+static void pc_pci_machine_done(Notifier *notifier, void *data)
+{
+}
+
 /* setup pci memory address space mapping into system address space */
 void pc_pci_as_mapping_init(MemoryRegion *system_memory,
                             MemoryRegion *pci_address_space)
@@ -1678,6 +1682,14 @@ static void pc_machine_initfn(Object *obj)
     qemu_add_machine_init_done_notifier(&pcms->machine_done);
 }
 
+static void pc_pci_machine_initfn(Object *obj)
+{
+    PcPciMachineState *ppms = PC_PCI_MACHINE(obj);
+
+    ppms->machine_done.notify = pc_pci_machine_done;
+    qemu_add_machine_init_done_notifier(&ppms->machine_done);
+}
+
 static void pc_machine_reset(MachineState *machine, ShutdownCause reason)
 {
     CPUState *cs;
@@ -1812,6 +1824,10 @@ static void pc_machine_class_init(ObjectClass *oc, void *data)
         pc_machine_set_fd_bootchk);
 }
 
+static void pc_pci_machine_class_init(ObjectClass *oc, void *data)
+{
+}
+
 bool pc_machine_is_pci_enabled(PCMachineState *pcms)
 {
     return PC_MACHINE_GET_CLASS(pcms)->pci_enabled;
@@ -1831,6 +1847,15 @@ static const TypeInfo pc_machine_types[] = {
              { }
         },
     },
+    {
+        .name           = TYPE_PC_PCI_MACHINE,
+        .parent         = TYPE_PC_MACHINE,
+        .abstract       = true,
+        .instance_size  = sizeof(PcPciMachineState),
+        .instance_init  = pc_pci_machine_initfn,
+        .class_size     = sizeof(PcPciMachineClass),
+        .class_init     = pc_pci_machine_class_init,
+    },
 };
 
 DEFINE_TYPES(pc_machine_types)
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index b9f85148e3..7ada452f91 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -463,7 +463,7 @@ static void pc_xen_hvm_init(MachineState *machine)
         pc_init1(machine, TYPE_I440FX_PCI_DEVICE); \
     } \
     DEFINE_PC_MACHINE(suffix, name, pc_init_##suffix, optionfn, \
-                      TYPE_PC_MACHINE)
+                      TYPE_PC_PCI_MACHINE)
 
 static void pc_i440fx_machine_options(MachineClass *m)
 {
@@ -838,7 +838,7 @@ static void xenfv_4_2_machine_options(MachineClass *m)
 }
 
 DEFINE_PC_MACHINE(xenfv_4_2, "xenfv-4.2", pc_xen_hvm_init,
-                  xenfv_4_2_machine_options, TYPE_PC_MACHINE);
+                  xenfv_4_2_machine_options, TYPE_PC_PCI_MACHINE);
 
 static void xenfv_3_1_machine_options(MachineClass *m)
 {
@@ -850,5 +850,5 @@ static void xenfv_3_1_machine_options(MachineClass *m)
 }
 
 DEFINE_PC_MACHINE(xenfv, "xenfv-3.1", pc_xen_hvm_init,
-                  xenfv_3_1_machine_options, TYPE_PC_MACHINE);
+                  xenfv_3_1_machine_options, TYPE_PC_PCI_MACHINE);
 #endif
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index 7dbee38f03..c3b0467ef3 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -339,7 +339,7 @@ static void pc_q35_init(MachineState *machine)
         pc_q35_init(machine); \
     } \
     DEFINE_PC_MACHINE(suffix, name, pc_init_##suffix, optionfn, \
-                      TYPE_PC_MACHINE)
+                      TYPE_PC_PCI_MACHINE)
 
 
 static void pc_q35_machine_options(MachineClass *m)
-- 
2.41.0



From xen-devel-bounces@lists.xenproject.org Thu Mar 28 15:55:17 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 15:55:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699012.1091407 (Exim 4.92)
	(envelope-from )
	id 1rps61-0000FK-IZ; Thu, 28 Mar 2024 15:55:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699012.1091407; Thu, 28 Mar 2024 15:55:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rps61-0000FB-F2; Thu, 28 Mar 2024 15:55:17 +0000
Received: by outflank-mailman (input) for mailman id 699012;
 Thu, 28 Mar 2024 15:55:16 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rps60-00071m-4Z
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 15:55:16 +0000
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com
 [2a00:1450:4864:20::52c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 90c7fdec-ed1b-11ee-a1ef-f123f15fe8a2;
 Thu, 28 Mar 2024 16:55:14 +0100 (CET)
Received: by mail-ed1-x52c.google.com with SMTP id
 4fb4d7f45d1cf-5688eaf1165so1559510a12.1
 for ; Thu, 28 Mar 2024 08:55:14 -0700 (PDT)
Received: from m1x-phil.lan (pas38-h02-176-184-5-52.dsl.sta.abo.bbox.fr.
 [176.184.5.52]) by smtp.gmail.com with ESMTPSA id
 ig3-20020a056402458300b0056c0a668316sm970627edb.3.2024.03.28.08.55.12
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Thu, 28 Mar 2024 08:55:13 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 90c7fdec-ed1b-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1711641314; x=1712246114; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=tfLLKG41I2ogYG1kIbKxMmfGPQoeoLD1UnfKcWEnm1Y=;
        b=ibZx7HWLcG19iRFa2+Ujih7qh7KsXlbb++txSWiCkWPBqXOaj8m2oatxYXwqBAueCy
         8Cx2Wp4h5UEbNhBMjIQlqxctepba6mCnjXD8meogi03FrMKgRzwxovwd16ELHg/h9npE
         oMTOG3docFRHgVpCU7STrYmIYOjwiFFtr6UZWiPWD6XfExqJiJ6BoCUcWDzgln9dYY8R
         vu+Me6RES7DFaS+hsIaM2tzmA7c479/11BPen/DWMyCk828hfNBD9mYA18UN3cJzs/2B
         Hl3+KRvBqxwqryiAFnMxnyGozgnVD5LCVdlhYuG1d05uC760iDMBUMK7dTDTie8a/t0Q
         7F7g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711641314; x=1712246114;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=tfLLKG41I2ogYG1kIbKxMmfGPQoeoLD1UnfKcWEnm1Y=;
        b=csJX5PrsFWJ+s0HFI39Vq1930eCbhU7u5tsDNPQb3D9GGQb9+f6X7qrKQkrRHQHL5T
         d54VbD5pipVqAGdedaUqqTlhf1TYTq+8n9NuRxliWd41e8LoUkGWJQoTKKxlbZJV0c5c
         NDtRpQSHpyVEUXILIHx8cvEP0ayCDImEZsmTCctlv5NZDZZ943wrbRqd3JdVpKkpG95h
         +61iXmq9CzKndct3KI0/1ZQDJmYgz8RMibORD2ii9YETLpPE0GocCNpeuAhA5CYqYVxI
         KNhMllEz+ksn4IOIrS+wpX/E/klviMc8DlupzLuEF/ovw2BOaOM4cBN1oTm3OXja1YfZ
         MOaQ==
X-Forwarded-Encrypted: i=1; AJvYcCUxowz0nQPigc6ALzELu5nWtmXu9/wT/jAA4/M5nGrvqWohT/oH9Vkp+ah+n4HktjdjHKk2YyEb1cIESw3xh3BmAl5CoAZeW1yiMrJf7mY=
X-Gm-Message-State: AOJu0YzSOkr3DIrZvEIEWnA/sVOq1fsxcSrhBb/PLzBOY/NTk362tD3/
	0D7Qc6TXX2ylCg9EZc07NTCeTVKibVAoSvXJrXhF7Rt8vhRH0zVtSnjlpqYXFNU=
X-Google-Smtp-Source: AGHT+IHgYPcqLucwrXXanAHQ1HQbxbpMZQm6yL1cnX0JqCYBkEci+AP5aBFgq++VGYS+wx15kRnpQw==
X-Received: by 2002:a50:ccd1:0:b0:56a:e8e4:9aef with SMTP id b17-20020a50ccd1000000b0056ae8e49aefmr2604908edj.7.1711641314036;
        Thu, 28 Mar 2024 08:55:14 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org
Cc: Richard Henderson ,
	Eduardo Habkost ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org,
	Bernhard Beschow ,
	Thomas Huth ,
	Marcel Apfelbaum ,
	"Michael S. Tsirkin" ,
	Paolo Bonzini ,
	Igor Mammedov ,
	Anthony Perard ,
	Ani Sinha ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
Subject: [RFC PATCH-for-9.1 05/29] hw/i386/pc: Remove PCMachineClass::pci_enabled field
Date: Thu, 28 Mar 2024 16:54:13 +0100
Message-ID: <20240328155439.58719-6-philmd@linaro.org>
X-Mailer: git-send-email 2.41.0
In-Reply-To: <20240328155439.58719-1-philmd@linaro.org>
References: <20240328155439.58719-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

All TYPE_PC_PCI_MACHINE-based machines have pci_enabled
set to %true. By checking a TYPE_PC_MACHINE inherits the
TYPE_PC_PCI_MACHINE base class, we don't need this field
anymore.

Signed-off-by: Philippe Mathieu-Daudé 
---
 include/hw/i386/pc.h | 1 -
 hw/i386/pc.c         | 3 +--
 hw/i386/pc_piix.c    | 1 -
 3 files changed, 1 insertion(+), 4 deletions(-)

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 1a4a61148a..0b23e5ec7b 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -87,7 +87,6 @@ typedef struct PCMachineClass {
     X86MachineClass parent_class;
 
     /* Device configuration: */
-    bool pci_enabled;
     const char *default_south_bridge;
 
     /* Compat options: */
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index eafd521489..a16bb1554c 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1740,7 +1740,6 @@ static void pc_machine_class_init(ObjectClass *oc, void *data)
     PCMachineClass *pcmc = PC_MACHINE_CLASS(oc);
     HotplugHandlerClass *hc = HOTPLUG_HANDLER_CLASS(oc);
 
-    pcmc->pci_enabled = true;
     pcmc->has_acpi_build = true;
     pcmc->smbios_defaults = true;
     pcmc->gigabyte_align = true;
@@ -1830,7 +1829,7 @@ static void pc_pci_machine_class_init(ObjectClass *oc, void *data)
 
 bool pc_machine_is_pci_enabled(PCMachineState *pcms)
 {
-    return PC_MACHINE_GET_CLASS(pcms)->pci_enabled;
+    return !!object_dynamic_cast(OBJECT(pcms), TYPE_PC_PCI_MACHINE);
 }
 
 static const TypeInfo pc_machine_types[] = {
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 7ada452f91..776d02db73 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -813,7 +813,6 @@ static void isapc_machine_options(MachineClass *m)
     m->max_cpus = 1;
     m->option_rom_has_mr = true;
     m->rom_file_has_mr = false;
-    pcmc->pci_enabled = false;
     pcmc->has_acpi_build = false;
     pcmc->smbios_defaults = false;
     pcmc->gigabyte_align = false;
-- 
2.41.0



From xen-devel-bounces@lists.xenproject.org Thu Mar 28 15:55:24 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 15:55:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699014.1091417 (Exim 4.92)
	(envelope-from )
	id 1rps68-0000ll-09; Thu, 28 Mar 2024 15:55:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699014.1091417; Thu, 28 Mar 2024 15:55:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rps67-0000kI-Sv; Thu, 28 Mar 2024 15:55:23 +0000
Received: by outflank-mailman (input) for mailman id 699014;
 Thu, 28 Mar 2024 15:55:22 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rps66-00071m-Fw
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 15:55:22 +0000
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com
 [2a00:1450:4864:20::62f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 948b9e10-ed1b-11ee-a1ef-f123f15fe8a2;
 Thu, 28 Mar 2024 16:55:20 +0100 (CET)
Received: by mail-ej1-x62f.google.com with SMTP id
 a640c23a62f3a-a466a1f9ea0so72974566b.1
 for ; Thu, 28 Mar 2024 08:55:20 -0700 (PDT)
Received: from m1x-phil.lan (pas38-h02-176-184-5-52.dsl.sta.abo.bbox.fr.
 [176.184.5.52]) by smtp.gmail.com with ESMTPSA id
 ef15-20020a05640228cf00b0056c1380a972sm963818edb.74.2024.03.28.08.55.18
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Thu, 28 Mar 2024 08:55:20 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 948b9e10-ed1b-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1711641320; x=1712246120; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Qqj3zRF0zkE64TiaxdKa2OyadNVq3wsX7i8167PhhDk=;
        b=GF1ky0xXBcM+9mqpMVIjN5ldUvzgeGYbPRszRQDdLHC2Tlz2nQyPvJqqhK4MJTGlh+
         9LR3PoFVcS0XO4QJ8mblVO6UCr/SweKxSVGI6mLpB/F6LpdkgOUt6bADna1HRNiPpOhW
         raqy1tgoR8T5t9Hxeoi+e6Fo/0nVMnfwXw0v3o2ZGm/3Pj9VpZ1nGkE+fAFqzk/5ZfpE
         6xMvW9We7ZpcyLd2WL6zmMy3h/odjvqTsOr9qLSs728DlQJHWZ4hOBKyue1Yyy/ssd+I
         nKkGzuoz213Qhy3omhJkUFPH3haU9juMZv1P8R3OUMBjpTXTzEy7+77n6Y6bLadMLhf5
         AUDA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711641320; x=1712246120;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=Qqj3zRF0zkE64TiaxdKa2OyadNVq3wsX7i8167PhhDk=;
        b=VkXLKiVxAVas+17HQHd3LvDNvFqib1WKp8P/q8eIZvE+2bZ0ZdvMaAVsRO65MIwjxE
         d/ECBKwh5XDlrl3K9eU5kuY2rmfuI6Nae6nEO7uYGa1yaNjy+MijuNMwl/5A/7TtOV2k
         O9085t7zIM5Au4caOxX5qAz98H2EjiXhy+wt3NS02hoPcJVnVvb4XpMaersyVZVSjH21
         YkdCcaLUH3iQ3jpnPTpBB9y1srD8Ws9Q/BO7C4oHl8JWfHogAVvuUKgHp0bz8yGJafyg
         0pTK7xoKgPpnuY5v//ggAyiB6oqfcETGGNURgvG3ZX/M2zGsOcQLTI32z73k093dDYNr
         Bq5w==
X-Forwarded-Encrypted: i=1; AJvYcCVW44NZU490/Dm8qiaW76SalifgMBpwBP168W8FBBqopft5aOQ5AhcIahQTZjg/lZuDPlkDnj5PETlvY9VABrmw/OrdumjgXyJnngW0FDo=
X-Gm-Message-State: AOJu0YxK3ZW4PpGQzLXvFODy5a9Y/Uj+MCKJ1WA3/3PMyZRd6JN/DE44
	JGD1XMOOSHqY5GH1tHb4RC1l+fSTZ/y8vWcMdDRBFqchmTNM4SPco9nINoCM2kk=
X-Google-Smtp-Source: AGHT+IHK7QxU7AgeWAocSeLH4R3SrP+9YZVhIuiOSStSg8CKPyXF7V4Tf4M9BXjp5dsE6yThozBjEA==
X-Received: by 2002:a50:8d08:0:b0:566:ecce:9d3c with SMTP id s8-20020a508d08000000b00566ecce9d3cmr2991678eds.26.1711641320462;
        Thu, 28 Mar 2024 08:55:20 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org
Cc: Richard Henderson ,
	Eduardo Habkost ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org,
	Bernhard Beschow ,
	Thomas Huth ,
	Marcel Apfelbaum ,
	"Michael S. Tsirkin" ,
	Paolo Bonzini ,
	Igor Mammedov ,
	Anthony Perard ,
	Ani Sinha ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
Subject: [RFC PATCH-for-9.1 06/29] hw/i386/pc: Move pci_root_uid field to PcPciMachineClass
Date: Thu, 28 Mar 2024 16:54:14 +0100
Message-ID: <20240328155439.58719-7-philmd@linaro.org>
X-Mailer: git-send-email 2.41.0
In-Reply-To: <20240328155439.58719-1-philmd@linaro.org>
References: <20240328155439.58719-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The 'pci_root_uid' field is irrelevant for non-PCI
machines, restrict it to the PcPciMachineClass.

Signed-off-by: Philippe Mathieu-Daudé 
---
 include/hw/i386/pc.h | 4 +++-
 hw/i386/acpi-build.c | 9 +++++++--
 hw/i386/pc_piix.c    | 7 +++++--
 hw/i386/pc_q35.c     | 7 +++++--
 4 files changed, 20 insertions(+), 7 deletions(-)

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 0b23e5ec7b..24c8e17e62 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -96,7 +96,6 @@ typedef struct PCMachineClass {
 
     /* ACPI compat: */
     bool has_acpi_build;
-    int pci_root_uid;
 
     /* SMBIOS compat: */
     bool smbios_defaults;
@@ -127,6 +126,9 @@ typedef struct PCMachineClass {
 
 typedef struct PcPciMachineClass {
     PCMachineClass parent_class;
+
+    /* ACPI compat: */
+    int pci_root_uid;
 } PcPciMachineClass;
 
 #define TYPE_PC_MACHINE "common-pc-machine"
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 6f9925d176..b9890886f6 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -1426,6 +1426,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
     CrsRangeSet crs_range_set;
     PCMachineState *pcms = PC_MACHINE(machine);
     PCMachineClass *pcmc = PC_MACHINE_GET_CLASS(machine);
+    PcPciMachineClass *ppmc;
     X86MachineState *x86ms = X86_MACHINE(machine);
     AcpiMcfgInfo mcfg;
     bool mcfg_valid = !!acpi_get_mcfg(&mcfg);
@@ -1448,10 +1449,12 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
 
     build_dbg_aml(dsdt);
     if (i440fx) {
+        ppmc = PC_PCI_MACHINE_GET_CLASS(machine);
+
         sb_scope = aml_scope("_SB");
         dev = aml_device("PCI0");
         aml_append(dev, aml_name_decl("_HID", aml_eisaid("PNP0A03")));
-        aml_append(dev, aml_name_decl("_UID", aml_int(pcmc->pci_root_uid)));
+        aml_append(dev, aml_name_decl("_UID", aml_int(ppmc->pci_root_uid)));
         aml_append(dev, aml_pci_edsm());
         aml_append(sb_scope, dev);
         aml_append(dsdt, sb_scope);
@@ -1461,11 +1464,13 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
         }
         build_piix4_pci0_int(dsdt);
     } else if (q35) {
+        ppmc = PC_PCI_MACHINE_GET_CLASS(machine);
+
         sb_scope = aml_scope("_SB");
         dev = aml_device("PCI0");
         aml_append(dev, aml_name_decl("_HID", aml_eisaid("PNP0A08")));
         aml_append(dev, aml_name_decl("_CID", aml_eisaid("PNP0A03")));
-        aml_append(dev, aml_name_decl("_UID", aml_int(pcmc->pci_root_uid)));
+        aml_append(dev, aml_name_decl("_UID", aml_int(ppmc->pci_root_uid)));
         aml_append(dev, build_q35_osc_method(!pm->pcihp_bridge_en));
         aml_append(dev, aml_pci_edsm());
         aml_append(sb_scope, dev);
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 776d02db73..c42dd46e59 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -468,9 +468,11 @@ static void pc_xen_hvm_init(MachineState *machine)
 static void pc_i440fx_machine_options(MachineClass *m)
 {
     PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
+    PcPciMachineClass *ppmc = PC_PCI_MACHINE_CLASS(m);
     ObjectClass *oc = OBJECT_CLASS(m);
+
     pcmc->default_south_bridge = TYPE_PIIX3_DEVICE;
-    pcmc->pci_root_uid = 0;
+    ppmc->pci_root_uid = 0;
     pcmc->default_cpu_version = 1;
 
     m->family = "pc_piix";
@@ -622,12 +624,13 @@ DEFINE_I440FX_MACHINE(v5_2, "pc-i440fx-5.2", NULL,
 static void pc_i440fx_5_1_machine_options(MachineClass *m)
 {
     PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
+    PcPciMachineClass *ppmc = PC_PCI_MACHINE_CLASS(m);
 
     pc_i440fx_5_2_machine_options(m);
     compat_props_add(m->compat_props, hw_compat_5_1, hw_compat_5_1_len);
     compat_props_add(m->compat_props, pc_compat_5_1, pc_compat_5_1_len);
     pcmc->kvmclock_create_always = false;
-    pcmc->pci_root_uid = 1;
+    ppmc->pci_root_uid = 1;
 }
 
 DEFINE_I440FX_MACHINE(v5_1, "pc-i440fx-5.1", NULL,
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index c3b0467ef3..dc0bf85464 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -345,7 +345,9 @@ static void pc_q35_init(MachineState *machine)
 static void pc_q35_machine_options(MachineClass *m)
 {
     PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
-    pcmc->pci_root_uid = 0;
+    PcPciMachineClass *ppmc = PC_PCI_MACHINE_CLASS(m);
+
+    ppmc->pci_root_uid = 0;
     pcmc->default_cpu_version = 1;
 
     m->family = "pc_q35";
@@ -495,12 +497,13 @@ DEFINE_Q35_MACHINE(v5_2, "pc-q35-5.2", NULL,
 static void pc_q35_5_1_machine_options(MachineClass *m)
 {
     PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
+    PcPciMachineClass *ppmc = PC_PCI_MACHINE_CLASS(m);
 
     pc_q35_5_2_machine_options(m);
     compat_props_add(m->compat_props, hw_compat_5_1, hw_compat_5_1_len);
     compat_props_add(m->compat_props, pc_compat_5_1, pc_compat_5_1_len);
     pcmc->kvmclock_create_always = false;
-    pcmc->pci_root_uid = 1;
+    ppmc->pci_root_uid = 1;
 }
 
 DEFINE_Q35_MACHINE(v5_1, "pc-q35-5.1", NULL,
-- 
2.41.0



From xen-devel-bounces@lists.xenproject.org Thu Mar 28 15:55:29 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 15:55:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699015.1091427 (Exim 4.92)
	(envelope-from )
	id 1rps6D-0001DT-AW; Thu, 28 Mar 2024 15:55:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699015.1091427; Thu, 28 Mar 2024 15:55:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rps6D-0001DM-6Y; Thu, 28 Mar 2024 15:55:29 +0000
Received: by outflank-mailman (input) for mailman id 699015;
 Thu, 28 Mar 2024 15:55:28 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rps6C-0001AK-4N
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 15:55:28 +0000
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com
 [2a00:1450:4864:20::533])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 985dd9cb-ed1b-11ee-afe3-a90da7624cb6;
 Thu, 28 Mar 2024 16:55:27 +0100 (CET)
Received: by mail-ed1-x533.google.com with SMTP id
 4fb4d7f45d1cf-566e869f631so1281270a12.0
 for ; Thu, 28 Mar 2024 08:55:27 -0700 (PDT)
Received: from m1x-phil.lan (pas38-h02-176-184-5-52.dsl.sta.abo.bbox.fr.
 [176.184.5.52]) by smtp.gmail.com with ESMTPSA id
 k7-20020aa7c047000000b0056c443ce781sm968470edo.85.2024.03.28.08.55.25
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Thu, 28 Mar 2024 08:55:26 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 985dd9cb-ed1b-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1711641327; x=1712246127; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=6t/11DBdsC4+Se7Vaykag7BJymn7PIzchj3B9U9dVz4=;
        b=txM9iJc0yr45dUdIagHwuyhJw6PO8Az7qlrWiOIpm7KCiEGFN345EUqXCuBKQfLMCC
         y9J2PNqJLpN5gBfQjErKIt81Pm7Nyt5bs/6qlx6X1XZ0sIdY2ulYv/kx5EyPydtbLci9
         mbXgIWVn/PWg2kOVT9BmxMSN5rC8Le7LIUZoj0iQcrXjf3HJT6A4hMko1QmsXBOkimZj
         1XFg2D622g94rc5GBi9sY0mII8xf9yJD1PEdYSqC7ViRxuT8LExyEjQoyqoX00frJ2M4
         T+Ke2x014b/rPS+y7cexWUXUi/0Vo+bDlvP3TzVkNgk0I+pRK0bGMPIbTiIm43X0zjqR
         VkNg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711641327; x=1712246127;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=6t/11DBdsC4+Se7Vaykag7BJymn7PIzchj3B9U9dVz4=;
        b=TYOrhTIa+VZu3BD2KddQryYMZc6Yj3oihAWWT+ggZumymoheuiCHCWXU8jTgvbt78C
         RZQ6+kvgys2ASkYnTKBSCjxYeVBb9YfArfCep81e4nR4d8DHSJjyayoRW7s8VkHR8F6G
         Q9CTmk+VcCl9H0dp86scJZ8y+pcKxkXvpy8yYmV3GcIVE6vwadaeDJx+z3/pnZUZpjMR
         rB59fMG4r6Cy3chhz++MhkKCTTb3KeHHGCTd60kAJrxypT68LkmBXmQEiwcM9c9xZ724
         uFzX0QmXX4T9Hz7G/L1jLKv10feKqZu1QKcGyeNI2Ux4pNSzkSDCHfjHhvjAOlUbjlVW
         zyow==
X-Forwarded-Encrypted: i=1; AJvYcCVFAy9kWZQiM1ECVu6F3kh9HJkfZ6s3aIOWqxnNHfmguJHdgzKrBAUeXw7p9TphhW++dJeZFaGyf9Q/GGRuJoG8mQrrO0g22M1nsEWF3Qo=
X-Gm-Message-State: AOJu0Yx2TjTN4Q8YocXR76VQIqjxkAn35ra6AQr2Y16JKvo24O8NRb5n
	tcql4a09i7ljUFRLFiNgB6sYlLHTxLsCIUPdBg1z7a8Ah8qMceMhCuO49CjYsu4=
X-Google-Smtp-Source: AGHT+IGa5cOf+IgzGIenKqeTpz5Pqe+oCRGklHarD29ZvICujPU9lddIF/mJjLz/l0UjTGpZalGbwQ==
X-Received: by 2002:a50:9e64:0:b0:56b:900b:a2e with SMTP id z91-20020a509e64000000b0056b900b0a2emr2672032ede.32.1711641326922;
        Thu, 28 Mar 2024 08:55:26 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org
Cc: Richard Henderson ,
	Eduardo Habkost ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org,
	Bernhard Beschow ,
	Thomas Huth ,
	Marcel Apfelbaum ,
	"Michael S. Tsirkin" ,
	Paolo Bonzini ,
	Igor Mammedov ,
	Anthony Perard ,
	Ani Sinha ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
Subject: [RFC PATCH-for-9.1 07/29] hw/i386/pc: Call fw_cfg_add_extra_pci_roots() in pc_pci_machine_done()
Date: Thu, 28 Mar 2024 16:54:15 +0100
Message-ID: <20240328155439.58719-8-philmd@linaro.org>
X-Mailer: git-send-email 2.41.0
In-Reply-To: <20240328155439.58719-1-philmd@linaro.org>
References: <20240328155439.58719-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

fw_cfg_add_extra_pci_roots() expects a PCI bus, which only
PCI-based machines have. No need to call it on the ISA-only
machine. Move it to the PCI-specific machine_done handler.

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/i386/pc.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index a16bb1554c..f9226f7115 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -608,8 +608,6 @@ void pc_machine_done(Notifier *notifier, void *data)
     /* set the number of CPUs */
     x86_rtc_set_cpus_count(x86ms->rtc, x86ms->boot_cpus);
 
-    fw_cfg_add_extra_pci_roots(pcms->pcibus, x86ms->fw_cfg);
-
     acpi_setup();
     if (x86ms->fw_cfg) {
         fw_cfg_build_smbios(pcms, x86ms->fw_cfg, pcms->smbios_entry_point_type);
@@ -623,6 +621,12 @@ void pc_machine_done(Notifier *notifier, void *data)
 
 static void pc_pci_machine_done(Notifier *notifier, void *data)
 {
+    PcPciMachineState *ppms = container_of(notifier,
+                                           PcPciMachineState, machine_done);
+    PCMachineState *pcms = PC_MACHINE(ppms);
+    X86MachineState *x86ms = X86_MACHINE(pcms);
+
+    fw_cfg_add_extra_pci_roots(pcms->pcibus, x86ms->fw_cfg);
 }
 
 /* setup pci memory address space mapping into system address space */
-- 
2.41.0



From xen-devel-bounces@lists.xenproject.org Thu Mar 28 15:55:35 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 15:55:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699018.1091437 (Exim 4.92)
	(envelope-from )
	id 1rps6J-0001kV-Ju; Thu, 28 Mar 2024 15:55:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699018.1091437; Thu, 28 Mar 2024 15:55:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rps6J-0001kO-Gm; Thu, 28 Mar 2024 15:55:35 +0000
Received: by outflank-mailman (input) for mailman id 699018;
 Thu, 28 Mar 2024 15:55:34 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rps6I-0001AK-G3
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 15:55:34 +0000
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com
 [2a00:1450:4864:20::62d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9c272e9b-ed1b-11ee-afe3-a90da7624cb6;
 Thu, 28 Mar 2024 16:55:33 +0100 (CET)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-a472f8c6a55so149503166b.0
 for ; Thu, 28 Mar 2024 08:55:33 -0700 (PDT)
Received: from m1x-phil.lan (pas38-h02-176-184-5-52.dsl.sta.abo.bbox.fr.
 [176.184.5.52]) by smtp.gmail.com with ESMTPSA id
 bj9-20020a17090736c900b00a4e28cacbddsm393913ejc.57.2024.03.28.08.55.31
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Thu, 28 Mar 2024 08:55:32 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9c272e9b-ed1b-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1711641333; x=1712246133; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=SSkLCR/UlhKFiQpvqkRVhG8wkTGDHk2a+aqlC/uZCjk=;
        b=HzD778V6aqrHB/+GMu32/EiAaNPHaS7LorEsj5Al4RuC3N8ykXJixllfj0nJeCh6eY
         JVUlyRwrXTJhgwMkcqEmH5mEzJBoEM6sB0o0O7CediUaiRq+3DeR5qF6t3wmvrJlgdD/
         QEynec4mwiiEX7NGzMOkjX+xlL3bHLlJXFJjU8UJ+EVk5qobw9z9g3Dogjzmq1D+oyGY
         7t3/814ZyenbFeN6aU2mcANxR/SM14O8IDCKjBw14ZXPtPQxXh8orzNgvNqvaB61i2m4
         1MZqUykDviEBB/uvcaaOWHv3IJuB+94M7PU0SpIvml+xEDv9OtRDL4M+Rnw2QNHqKaRe
         oIXw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711641333; x=1712246133;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=SSkLCR/UlhKFiQpvqkRVhG8wkTGDHk2a+aqlC/uZCjk=;
        b=CrfOBMbsR4JBEPYHLOoWzOCjGUF4Aa5hlcAKUkf2UnQXg+c70qkpvpeylml1RCCsqP
         m1lf5oFXEwFegACrqHdNyfCYwiKsp/skyV2IVEBDupvSdiYywTV4lbXn4TTKCn1mUVFB
         EjKHrFntNiBVQITh1UPKATWFQOHizvhD0ibwj49hGwzb5yghIzoxDBuSXM2kud32vHWU
         oGkoptdEqqPJuB64o1XRra9srU0ownM5bzlGfrzFqVGrUu4CbRlS8AGVpGL+TJiSWFfY
         ughb/oVbIs7uLWeRd3YRvxQkdrj058qUDcHqyhULq6Oih/6LO6jrtn5GOigkwFbQdWKV
         SpyQ==
X-Forwarded-Encrypted: i=1; AJvYcCXTvYXdBVcQF1hBtDygH3VXk2+KKQJBz8kCbqztTSXGgwHnInSVJc8oA2i4QNOk3QLVQnaPw6AweJvkuRuaJClqf3gXO7Y3cE2pEgUzzv4=
X-Gm-Message-State: AOJu0YxeiUh74vG0ygt5ih1K2YJa2Z3IFF7E0ZDxAMA+pX9G6L16PNVf
	ROwEi9yiUSnm0HmDOfx0EuXtXGxVHknDWBuA80fF7W9/7Ft0CGhmqniJbGQ7SvM=
X-Google-Smtp-Source: AGHT+IF/0mLdvRWo13tehO3NuCCV1getL+XsL801v0qQfgvFLMYq6AAaEiOV3hBAVWA55LBbGiFx8w==
X-Received: by 2002:a17:906:ef05:b0:a4e:207e:b71 with SMTP id f5-20020a170906ef0500b00a4e207e0b71mr2083747ejs.6.1711641333084;
        Thu, 28 Mar 2024 08:55:33 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org
Cc: Richard Henderson ,
	Eduardo Habkost ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org,
	Bernhard Beschow ,
	Thomas Huth ,
	Marcel Apfelbaum ,
	"Michael S. Tsirkin" ,
	Paolo Bonzini ,
	Igor Mammedov ,
	Anthony Perard ,
	Ani Sinha ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
Subject: [RFC PATCH-for-9.1 08/29] hw/i386/pc: Move CXLState to PcPciMachineState
Date: Thu, 28 Mar 2024 16:54:16 +0100
Message-ID: <20240328155439.58719-9-philmd@linaro.org>
X-Mailer: git-send-email 2.41.0
In-Reply-To: <20240328155439.58719-1-philmd@linaro.org>
References: <20240328155439.58719-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

CXL depends on PCIe, which isn't available on non-PCI
machines such the ISA-only PC one.
Move CXLState to PcPciMachineState, and move the CXL
specific calls to pc_pci_machine_initfn() and
pc_pci_machine_done().

Signed-off-by: Philippe Mathieu-Daudé 
---
 include/hw/i386/pc.h |  3 ++-
 hw/i386/acpi-build.c | 14 +++++++++++---
 hw/i386/pc.c         | 39 ++++++++++++++++++++-------------------
 3 files changed, 33 insertions(+), 23 deletions(-)

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 24c8e17e62..a97493d29d 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -54,13 +54,14 @@ typedef struct PCMachineState {
     hwaddr memhp_io_base;
 
     SGXEPCState sgx_epc;
-    CXLState cxl_devices_state;
 } PCMachineState;
 
 typedef struct PcPciMachineState {
     PCMachineState parent_obj;
 
     Notifier machine_done;
+
+    CXLState cxl_devices_state;
 } PcPciMachineState;
 
 #define PC_MACHINE_ACPI_DEVICE_PROP "acpi-device"
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index b9890886f6..6e8e32e5d2 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -1554,6 +1554,11 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
     crs_range_set_init(&crs_range_set);
     bus = PC_MACHINE(machine)->pcibus;
     if (bus) {
+        PcPciMachineState *ppms;
+
+        assert(pc_machine_is_pci_enabled(pcms));
+        ppms = PC_PCI_MACHINE(machine);
+
         QLIST_FOREACH(bus, &bus->child, sibling) {
             uint8_t bus_num = pci_bus_num(bus);
             uint8_t numa_node = pci_bus_numa_node(bus);
@@ -1607,7 +1612,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
 
             /* Handle the ranges for the PXB expanders */
             if (pci_bus_is_cxl(bus)) {
-                MemoryRegion *mr = &pcms->cxl_devices_state.host_mr;
+                MemoryRegion *mr = &ppms->cxl_devices_state.host_mr;
                 uint64_t base = mr->addr;
 
                 cxl_present = true;
@@ -2513,6 +2518,8 @@ void acpi_build(AcpiBuildTables *tables, MachineState *machine)
     Object *vmgenid_dev;
     char *oem_id;
     char *oem_table_id;
+    bool pci_enabled = pc_machine_is_pci_enabled(pcms);
+    PcPciMachineState *ppms = pci_enabled ? PC_PCI_MACHINE(pcms) : NULL;
 
     acpi_get_pm_info(machine, &pm);
     acpi_get_misc_info(&misc);
@@ -2640,9 +2647,10 @@ void acpi_build(AcpiBuildTables *tables, MachineState *machine)
                           machine->nvdimms_state, machine->ram_slots,
                           x86ms->oem_id, x86ms->oem_table_id);
     }
-    if (pcms->cxl_devices_state.is_enabled) {
+    if (ppms && ppms->cxl_devices_state.is_enabled) {
         cxl_build_cedt(table_offsets, tables_blob, tables->linker,
-                       x86ms->oem_id, x86ms->oem_table_id, &pcms->cxl_devices_state);
+                       x86ms->oem_id, x86ms->oem_table_id,
+                       &ppms->cxl_devices_state);
     }
 
     acpi_add_table(table_offsets, tables_blob);
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index f9226f7115..6d87d1d4c2 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -598,13 +598,6 @@ void pc_machine_done(Notifier *notifier, void *data)
                                         PCMachineState, machine_done);
     X86MachineState *x86ms = X86_MACHINE(pcms);
 
-    cxl_hook_up_pxb_registers(pcms->pcibus, &pcms->cxl_devices_state,
-                              &error_fatal);
-
-    if (pcms->cxl_devices_state.is_enabled) {
-        cxl_fmws_link_targets(&pcms->cxl_devices_state, &error_fatal);
-    }
-
     /* set the number of CPUs */
     x86_rtc_set_cpus_count(x86ms->rtc, x86ms->boot_cpus);
 
@@ -626,6 +619,13 @@ static void pc_pci_machine_done(Notifier *notifier, void *data)
     PCMachineState *pcms = PC_MACHINE(ppms);
     X86MachineState *x86ms = X86_MACHINE(pcms);
 
+    cxl_hook_up_pxb_registers(pcms->pcibus, &ppms->cxl_devices_state,
+                              &error_fatal);
+
+    if (ppms->cxl_devices_state.is_enabled) {
+        cxl_fmws_link_targets(&ppms->cxl_devices_state, &error_fatal);
+    }
+
     fw_cfg_add_extra_pci_roots(pcms->pcibus, x86ms->fw_cfg);
 }
 
@@ -719,13 +719,14 @@ static uint64_t pc_get_cxl_range_start(PCMachineState *pcms)
 
 static uint64_t pc_get_cxl_range_end(PCMachineState *pcms)
 {
+    PcPciMachineState *ppms = PC_PCI_MACHINE(pcms);
     uint64_t start = pc_get_cxl_range_start(pcms) + MiB;
 
-    if (pcms->cxl_devices_state.fixed_windows) {
+    if (ppms->cxl_devices_state.fixed_windows) {
         GList *it;
 
         start = ROUND_UP(start, 256 * MiB);
-        for (it = pcms->cxl_devices_state.fixed_windows; it; it = it->next) {
+        for (it = ppms->cxl_devices_state.fixed_windows; it; it = it->next) {
             CXLFixedWindow *fw = it->data;
             start += fw->size;
         }
@@ -823,6 +824,7 @@ void pc_memory_init(PCMachineState *pcms,
     hwaddr cxl_base, cxl_resv_end = 0;
     X86CPU *cpu = X86_CPU(first_cpu);
     bool pci_enabled = pc_machine_is_pci_enabled(pcms);
+    PcPciMachineState *ppms = pci_enabled ? PC_PCI_MACHINE(pcms) : NULL;
 
     assert(machine->ram_size == x86ms->below_4g_mem_size +
                                 x86ms->above_4g_mem_size);
@@ -926,20 +928,20 @@ void pc_memory_init(PCMachineState *pcms,
         machine_memory_devices_init(machine, device_mem_base, device_mem_size);
     }
 
-    if (pcms->cxl_devices_state.is_enabled) {
-        MemoryRegion *mr = &pcms->cxl_devices_state.host_mr;
+    if (ppms && ppms->cxl_devices_state.is_enabled) {
+        MemoryRegion *mr = &ppms->cxl_devices_state.host_mr;
         hwaddr cxl_size = MiB;
 
         cxl_base = pc_get_cxl_range_start(pcms);
         memory_region_init(mr, OBJECT(machine), "cxl_host_reg", cxl_size);
         memory_region_add_subregion(system_memory, cxl_base, mr);
         cxl_resv_end = cxl_base + cxl_size;
-        if (pcms->cxl_devices_state.fixed_windows) {
+        if (ppms->cxl_devices_state.fixed_windows) {
             hwaddr cxl_fmw_base;
             GList *it;
 
             cxl_fmw_base = ROUND_UP(cxl_base + cxl_size, 256 * MiB);
-            for (it = pcms->cxl_devices_state.fixed_windows; it; it = it->next) {
+            for (it = ppms->cxl_devices_state.fixed_windows; it; it = it->next) {
                 CXLFixedWindow *fw = it->data;
 
                 fw->base = cxl_fmw_base;
@@ -979,7 +981,7 @@ void pc_memory_init(PCMachineState *pcms,
             res_mem_end += memory_region_size(&machine->device_memory->mr);
         }
 
-        if (pcms->cxl_devices_state.is_enabled) {
+        if (ppms->cxl_devices_state.is_enabled) {
             res_mem_end = cxl_resv_end;
         }
         *val = cpu_to_le64(ROUND_UP(res_mem_end, 1 * GiB));
@@ -1010,11 +1012,12 @@ uint64_t pc_pci_hole64_start(void)
 {
     PCMachineState *pcms = PC_MACHINE(qdev_get_machine());
     PCMachineClass *pcmc = PC_MACHINE_GET_CLASS(pcms);
+    PcPciMachineState *ppms = PC_PCI_MACHINE(pcms);
     MachineState *ms = MACHINE(pcms);
     uint64_t hole64_start = 0;
     ram_addr_t size = 0;
 
-    if (pcms->cxl_devices_state.is_enabled) {
+    if (ppms->cxl_devices_state.is_enabled) {
         hole64_start = pc_get_cxl_range_end(pcms);
     } else if (pcmc->has_reserved_memory && (ms->ram_size < ms->maxram_size)) {
         pc_get_device_memory_range(pcms, &hole64_start, &size);
@@ -1651,7 +1654,6 @@ static void pc_machine_initfn(Object *obj)
 {
     PCMachineState *pcms = PC_MACHINE(obj);
     PCMachineClass *pcmc = PC_MACHINE_GET_CLASS(pcms);
-    bool pci_enabled = pc_machine_is_pci_enabled(pcms);
 
 #ifdef CONFIG_VMPORT
     pcms->vmport = ON_OFF_AUTO_AUTO;
@@ -1678,9 +1680,6 @@ static void pc_machine_initfn(Object *obj)
     pcms->pcspk = isa_new(TYPE_PC_SPEAKER);
     object_property_add_alias(OBJECT(pcms), "pcspk-audiodev",
                               OBJECT(pcms->pcspk), "audiodev");
-    if (pci_enabled) {
-        cxl_machine_init(obj, &pcms->cxl_devices_state);
-    }
 
     pcms->machine_done.notify = pc_machine_done;
     qemu_add_machine_init_done_notifier(&pcms->machine_done);
@@ -1690,6 +1689,8 @@ static void pc_pci_machine_initfn(Object *obj)
 {
     PcPciMachineState *ppms = PC_PCI_MACHINE(obj);
 
+    cxl_machine_init(obj, &ppms->cxl_devices_state);
+
     ppms->machine_done.notify = pc_pci_machine_done;
     qemu_add_machine_init_done_notifier(&ppms->machine_done);
 }
-- 
2.41.0



From xen-devel-bounces@lists.xenproject.org Thu Mar 28 15:55:48 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 15:55:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699019.1091447 (Exim 4.92)
	(envelope-from )
	id 1rps6V-0002V9-SR; Thu, 28 Mar 2024 15:55:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699019.1091447; Thu, 28 Mar 2024 15:55:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rps6V-0002V2-PD; Thu, 28 Mar 2024 15:55:47 +0000
Received: by outflank-mailman (input) for mailman id 699019;
 Thu, 28 Mar 2024 15:55:46 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rps6U-0001AK-IC
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 15:55:46 +0000
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com
 [2a00:1450:4864:20::536])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a38a74cb-ed1b-11ee-afe3-a90da7624cb6;
 Thu, 28 Mar 2024 16:55:46 +0100 (CET)
Received: by mail-ed1-x536.google.com with SMTP id
 4fb4d7f45d1cf-56c2b4850d2so1407108a12.2
 for ; Thu, 28 Mar 2024 08:55:46 -0700 (PDT)
Received: from m1x-phil.lan (pas38-h02-176-184-5-52.dsl.sta.abo.bbox.fr.
 [176.184.5.52]) by smtp.gmail.com with ESMTPSA id
 r18-20020a170906c29200b00a4e2a1146f8sm298044ejz.48.2024.03.28.08.55.43
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Thu, 28 Mar 2024 08:55:45 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a38a74cb-ed1b-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1711641345; x=1712246145; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=HtUfcj3aTDn2mvaMR/QsDVngwC1CAz/OBQXAMI7WNPQ=;
        b=lNJDLqZW9NEMGRWweBxLfSo2JFd3oApy7h8DgV7+lE5SXPKodKLsud3rIRxOjMlWp+
         m05b11yOqliLYv27I5t3UNG6cVVoe9sz3i3fXMQBnRm49073SeiFn+HS/4BgCJS/TPJe
         75j/Bwv1mG2c/RaNVbzAIBX9ObG2dTEHK7xgAcX/mR1XpbeSQ9EQJzWz7F7azME595WZ
         yJw28bdxxQiLPwyN7Y88Sl+rRqkM3q2ci9m0ftbGuHdrD6w4gIbgUZ/72ox7eo4ewZRu
         0M00pB+IQT2HZJJ2Mw3kry7u3U0iAQMpCQMurTBOrotP4SZk6f+X5bvR1S+FoLXlTIOG
         PmbQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711641345; x=1712246145;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=HtUfcj3aTDn2mvaMR/QsDVngwC1CAz/OBQXAMI7WNPQ=;
        b=CM5rSkowNVAlw6yj0lYxt2Zl6EyKN4VwLEk9FFyg1BBKI3ft06Dj7TSegIDt3KlWOi
         WyEwtaISw6wIdcvVgv+oDKL9a7ft6iPLzcZ+dqDfbwBbdr6mbHTcoLvajDEK8pjyZxbe
         PtykylIuDWse1HEgSHWKwDrEk/ulWhbkR4+xuNNMKJ2M4fwYVvZ2tPT4TVTwHqpVfdlC
         XtAoQBzNCpKawOiAG9eSH4EajGTLHg6/YjlgHaZhs5fUPTzgy4IK9+g7nOEtmLlVQ9B/
         cqL1nV/TcM53zrwM/H+YhJvO1qIEy5jAFEeHnfce5xhwOwhRChBZmSsTk8+hMx3tihMC
         mGdQ==
X-Forwarded-Encrypted: i=1; AJvYcCXUbnGbqxsGBYc//hP83u+MT3apaPJIJ4IF6Hmnf6h5dpYXr1EPjwsdG0pknlBzvF6U+NmxImjuHUwWMIrDUiU1gpxbGUQDWyXb8/27xCU=
X-Gm-Message-State: AOJu0YxN0FFLzLtLq8/lpP+uaB/NmE71rJVsFSqCHRRyTC1QTRzYpVMh
	dfYEzvBS0L0uBE74F3eVSQptQLt1zIc2x23wDOD+daxHyzdrNPw7YWOqcHn3s0c=
X-Google-Smtp-Source: AGHT+IE4H2j7DvpBr0ZgGTO3mYeCN1DwhGLVSa7xknb/dNXvpG290SVF6AQSzPcOp/lNCIhUZoP8Cw==
X-Received: by 2002:a17:906:4697:b0:a4e:ebd:254a with SMTP id a23-20020a170906469700b00a4e0ebd254amr2129554ejr.9.1711641345640;
        Thu, 28 Mar 2024 08:55:45 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org
Cc: Richard Henderson ,
	Eduardo Habkost ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org,
	Bernhard Beschow ,
	Thomas Huth ,
	Marcel Apfelbaum ,
	"Michael S. Tsirkin" ,
	Paolo Bonzini ,
	Igor Mammedov ,
	Anthony Perard ,
	Ani Sinha ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
Subject: [RFC PATCH-for-9.1 10/29] hw/i386/pc: Remove PCMachineClass::has_acpi_build field
Date: Thu, 28 Mar 2024 16:54:18 +0100
Message-ID: <20240328155439.58719-11-philmd@linaro.org>
X-Mailer: git-send-email 2.41.0
In-Reply-To: <20240328155439.58719-1-philmd@linaro.org>
References: <20240328155439.58719-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

PCMachineClass::has_acpi_build is always %true for PCI
based machines. Remove it, setting the 'acpi_build_enabled'
field once in pc_pci_machine_initfn().

Signed-off-by: Philippe Mathieu-Daudé 
---
 include/hw/i386/pc.h | 3 ---
 hw/i386/pc.c         | 6 +++---
 hw/i386/pc_piix.c    | 1 -
 3 files changed, 3 insertions(+), 7 deletions(-)

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index a97493d29d..dd5ee448ef 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -95,9 +95,6 @@ typedef struct PCMachineClass {
     /* Default CPU model version.  See x86_cpu_set_default_version(). */
     int default_cpu_version;
 
-    /* ACPI compat: */
-    bool has_acpi_build;
-
     /* SMBIOS compat: */
     bool smbios_defaults;
     bool smbios_legacy_mode;
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index dfc0247bb6..f0dc04e2fc 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1664,8 +1664,6 @@ static void pc_machine_initfn(Object *obj)
     pcms->smbios_entry_point_type = pcmc->default_smbios_ep_type;
     pcms->south_bridge = pcmc->default_south_bridge;
 
-    /* acpi build is enabled by default if machine supports it */
-    pcms->acpi_build_enabled = pcmc->has_acpi_build;
     pcms->smbus_enabled = true;
     pcms->sata_enabled = true;
     pcms->i8042_enabled = true;
@@ -1688,6 +1686,9 @@ static void pc_machine_initfn(Object *obj)
 static void pc_pci_machine_initfn(Object *obj)
 {
     PcPciMachineState *ppms = PC_PCI_MACHINE(obj);
+    PCMachineState *pcms = PC_MACHINE(obj);
+
+    pcms->acpi_build_enabled = true;
 
     cxl_machine_init(obj, &ppms->cxl_devices_state);
 
@@ -1745,7 +1746,6 @@ static void pc_machine_class_init(ObjectClass *oc, void *data)
     PCMachineClass *pcmc = PC_MACHINE_CLASS(oc);
     HotplugHandlerClass *hc = HOTPLUG_HANDLER_CLASS(oc);
 
-    pcmc->has_acpi_build = true;
     pcmc->smbios_defaults = true;
     pcmc->gigabyte_align = true;
     pcmc->has_reserved_memory = true;
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index c42dd46e59..7aa2598e10 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -816,7 +816,6 @@ static void isapc_machine_options(MachineClass *m)
     m->max_cpus = 1;
     m->option_rom_has_mr = true;
     m->rom_file_has_mr = false;
-    pcmc->has_acpi_build = false;
     pcmc->smbios_defaults = false;
     pcmc->gigabyte_align = false;
     pcmc->smbios_legacy_mode = true;
-- 
2.41.0



From xen-devel-bounces@lists.xenproject.org Thu Mar 28 15:55:56 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 15:55:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699022.1091457 (Exim 4.92)
	(envelope-from )
	id 1rps6d-00032b-7m; Thu, 28 Mar 2024 15:55:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699022.1091457; Thu, 28 Mar 2024 15:55:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rps6d-00032U-54; Thu, 28 Mar 2024 15:55:55 +0000
Received: by outflank-mailman (input) for mailman id 699022;
 Thu, 28 Mar 2024 15:55:53 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rps6b-0001AK-3D
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 15:55:53 +0000
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com
 [2a00:1450:4864:20::531])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a7723f0c-ed1b-11ee-afe3-a90da7624cb6;
 Thu, 28 Mar 2024 16:55:52 +0100 (CET)
Received: by mail-ed1-x531.google.com with SMTP id
 4fb4d7f45d1cf-568c714a9c7so1312485a12.2
 for ; Thu, 28 Mar 2024 08:55:52 -0700 (PDT)
Received: from m1x-phil.lan (pas38-h02-176-184-5-52.dsl.sta.abo.bbox.fr.
 [176.184.5.52]) by smtp.gmail.com with ESMTPSA id
 u23-20020aa7d897000000b0056ba017ca7fsm953482edq.87.2024.03.28.08.55.50
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Thu, 28 Mar 2024 08:55:51 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a7723f0c-ed1b-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1711641352; x=1712246152; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=ZJ3NIU3pO9930vwNFx0mYgma5e7GvztHkS/rmyU15RU=;
        b=BG/FPI3FZWPijrJvR/3GBAQnfxn8sdeqkyr7hR50D3lgiBXWShG1ghMVZ166fM/tcN
         5f7/TVUdmDpx4sYFkUyz4Scr4XziUsWn79NHVUGylQNBqHOqWebyawbemLf9lcRq61ri
         n26f5bpXO2+lKQjtL5zxY7gQCzp34sM56Vt6+2wjYJGi7fuKwMJDXG+Z9zcw+P502ei3
         b29ZTlAbwNQuREr0LvgqnmCYL7p3BsxEfo7nc2ACVJ7rMk1Yc5/2PrCemulqT9NgcMVI
         6jvu4gKt3Aon0tI10eehKstbT/UYj0+tdMIbWQd+DCGLiwPB6WxrX1YqxlJpAWnTdwvD
         DFdg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711641352; x=1712246152;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=ZJ3NIU3pO9930vwNFx0mYgma5e7GvztHkS/rmyU15RU=;
        b=ik4KjRkBzMXycBAxThV6Ba0BT+UNR0JBsYxKIceZILrvhj9s0xtlEs29hrESJ0pIM/
         rQdzYydtK9coHjch/VAEKgh4c7MGrPvAGsk5/xif9XMyUY6xNmff84CPoKoGYQ+VxR+h
         6EISkiD43xcs5/V7p2A0eEBVl+fQOphRw7TLXyHaL2sB02rEknsCRZxth9ajCU9LRqH9
         iwytAF/OF0o3evouBYd+jx2+2pcEyU1wi3phaDXCYZy6fb/qaz0SIRCd0F3cGF/Ce/eN
         2ZwPCBkEFwRle34zfugSvWzGrjJkLZzwvDhiHLpvQplI3gCKBb/6pzYZHgDRQ3ymVNxW
         rMHw==
X-Forwarded-Encrypted: i=1; AJvYcCX8JMWghPzm5yDKErBc9aoBPERzSilRTWf4693dAS776w43SRbBRHk6ZabEpAiurOF9NlbPe8vSLdzE3OPuRxR2U5HoY/V7Mgz4z1CFnLg=
X-Gm-Message-State: AOJu0YzdqVakuRaisnoixowfPjhufu6V8fgYQL3EgJr5UYgsVFSbEkzG
	wJ+a4OZOaWQgBYMnuuQg1whweLYtMCX7hGvkdLckqSZ8cqXkYk2nDQfHMX6/uss=
X-Google-Smtp-Source: AGHT+IH3/f3B+fppMfqmjp05mNuhqqUlRQgmruUJACUpH3wuIu7IVWjtNOwP7TTyrIw4MimWKbfy0Q==
X-Received: by 2002:a50:d6d8:0:b0:568:ae7:bc0 with SMTP id l24-20020a50d6d8000000b005680ae70bc0mr2301236edj.34.1711641351948;
        Thu, 28 Mar 2024 08:55:51 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org
Cc: Richard Henderson ,
	Eduardo Habkost ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org,
	Bernhard Beschow ,
	Thomas Huth ,
	Marcel Apfelbaum ,
	"Michael S. Tsirkin" ,
	Paolo Bonzini ,
	Igor Mammedov ,
	Anthony Perard ,
	Ani Sinha ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
Subject: [RFC PATCH-for-9.1 11/29] hw/i386/pc: Move acpi_setup() call to pc_pci_machine_done()
Date: Thu, 28 Mar 2024 16:54:19 +0100
Message-ID: <20240328155439.58719-12-philmd@linaro.org>
X-Mailer: git-send-email 2.41.0
In-Reply-To: <20240328155439.58719-1-philmd@linaro.org>
References: <20240328155439.58719-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

acpi_setup() returns early if acpi_build_enabled is not set:

  2752 void acpi_setup(PCMachineState *pcms)
  2753 {
   ...
  2768     if (!pcms->acpi_build_enabled) {
  2769         ACPI_BUILD_DPRINTF("ACPI build disabled. Bailing out.\n");
  2770         return;
  2771     }

acpi_build_enabled is only set on PCI-based machines, so it
is pointless to call acpi_setup() from non-PCI like the ISA-only
machine, move the call to pc_pci_machine_done().

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/i386/pc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index f0dc04e2fc..47fe3a7c02 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -601,7 +601,6 @@ void pc_machine_done(Notifier *notifier, void *data)
     /* set the number of CPUs */
     x86_rtc_set_cpus_count(x86ms->rtc, x86ms->boot_cpus);
 
-    acpi_setup(pcms);
     if (x86ms->fw_cfg) {
         fw_cfg_build_smbios(pcms, x86ms->fw_cfg, pcms->smbios_entry_point_type);
         fw_cfg_build_feature_control(MACHINE(pcms), x86ms->fw_cfg);
@@ -627,6 +626,8 @@ static void pc_pci_machine_done(Notifier *notifier, void *data)
     }
 
     fw_cfg_add_extra_pci_roots(pcms->pcibus, x86ms->fw_cfg);
+
+    acpi_setup(pcms);
 }
 
 /* setup pci memory address space mapping into system address space */
-- 
2.41.0



From xen-devel-bounces@lists.xenproject.org Thu Mar 28 15:56:00 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 15:56:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699023.1091467 (Exim 4.92)
	(envelope-from )
	id 1rps6i-0003Sp-He; Thu, 28 Mar 2024 15:56:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699023.1091467; Thu, 28 Mar 2024 15:56:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rps6i-0003Sd-En; Thu, 28 Mar 2024 15:56:00 +0000
Received: by outflank-mailman (input) for mailman id 699023;
 Thu, 28 Mar 2024 15:55:59 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rps6h-0001AK-A6
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 15:55:59 +0000
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com
 [2a00:1450:4864:20::536])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ab22719c-ed1b-11ee-afe3-a90da7624cb6;
 Thu, 28 Mar 2024 16:55:58 +0100 (CET)
Received: by mail-ed1-x536.google.com with SMTP id
 4fb4d7f45d1cf-56c12c73ed8so1456496a12.2
 for ; Thu, 28 Mar 2024 08:55:58 -0700 (PDT)
Received: from m1x-phil.lan (pas38-h02-176-184-5-52.dsl.sta.abo.bbox.fr.
 [176.184.5.52]) by smtp.gmail.com with ESMTPSA id
 g20-20020aa7c594000000b0056be0d1cd83sm954932edq.97.2024.03.28.08.55.56
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Thu, 28 Mar 2024 08:55:57 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ab22719c-ed1b-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1711641358; x=1712246158; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=jlOZmiJcfWhY/E5lc2Om2vdspo8I2MenAyugtnCqPJ8=;
        b=WthVM38weC/OsP93dMX7SOGT7bwOuSWVSP4NHAf7johrMLill/YrI8e5A0sIMaqL6p
         5+gu4IVdZIIYASaJ1Ax0v+ZWgTrn7q38ZN8DHmr24ASgpgoBnJ0HMNZmIjTRer7bkveW
         8AR157bx4BdrXdf/yd/FK3hCXMwiv9g0koGT3GoFZQmg9SBi+iFFtPB4O33JQn/b6TkT
         GIc1zcuYQkugkfPm1lLSY2FKYcdtYb8nhhS7nrvEH801Ji2TVyQRT+/Z0LtrbtXgVPdI
         tstHL02DwJnlsFGbGIiOYNrrTcxssCz1Imd4ufqp3z7yKBXFbeJKIjzhHw56chIlVhHp
         Af/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711641358; x=1712246158;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=jlOZmiJcfWhY/E5lc2Om2vdspo8I2MenAyugtnCqPJ8=;
        b=J5ehBKurT4lWW4lYxajsPGYaZYFoI0vFtZFuK3sccHDpNdAHi2TvDe/kFznYTDNeDy
         AFD2Wsl3A/22Sq7QGbVUJOh9otzQ9c6+zXgWhG41qq7ihMlkce0PcK2Bhalc7SmN1yc8
         o0UI2OW3csZ408Aie37JOM0yb9JoeZmiKemuzY00Z6HRFKJm4lTQz7BEekMTp77iTP8F
         jD0R/nSJvlZthGHTA61ntlYhcJMajTaXb7gKT88Z8qUWerRnSRw0qMHiTcSjvVyyJfIB
         /FuK5Nf9aEflM6amKZOGqZ4OrBbWaUmsgNyMyIQ9cpvhsoiboQVCkTSttAv9hJj1aw38
         9vEg==
X-Forwarded-Encrypted: i=1; AJvYcCXhAhqXL4AKxbxNo9vF2VogyFdgJ7vgvKfI50gqKJ8QsuwpMwJR3kBycqayh9Gsr+kycsTR4C4pchO4oN2RtPHTV4chCaQDBEgSVqCN5DA=
X-Gm-Message-State: AOJu0YxPE6wGHNImO1uRPQAGFPDyPe+G+T00OENsg6CxroC6g9u0QX9z
	Qb02hj92LsVCU1JifLN/bIrd0wYN//KLqcAbv9ISBA5ISGBLgsT/0Qmn+xFl+i8=
X-Google-Smtp-Source: AGHT+IEHlPzirbO0NxvTAiaCR1AzHmEf11L/n2EPgKkmIcgFqhAD5O/Yt/mmGevQB4ExiPCyjyrkcg==
X-Received: by 2002:a50:d650:0:b0:56b:cda3:6de6 with SMTP id c16-20020a50d650000000b0056bcda36de6mr2166952edj.42.1711641358386;
        Thu, 28 Mar 2024 08:55:58 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org
Cc: Richard Henderson ,
	Eduardo Habkost ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org,
	Bernhard Beschow ,
	Thomas Huth ,
	Marcel Apfelbaum ,
	"Michael S. Tsirkin" ,
	Paolo Bonzini ,
	Igor Mammedov ,
	Anthony Perard ,
	Ani Sinha ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Paul Durrant 
Subject: [RFC PATCH-for-9.1 12/29] hw/i386/pc: Move acpi_build_enabled to PcPciMachineState
Date: Thu, 28 Mar 2024 16:54:20 +0100
Message-ID: <20240328155439.58719-13-philmd@linaro.org>
X-Mailer: git-send-email 2.41.0
In-Reply-To: <20240328155439.58719-1-philmd@linaro.org>
References: <20240328155439.58719-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Since only PCI-based machines use the 'acpi_build_enabled',
move it to PcPciMachineState.

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/i386/acpi-build.h  | 2 +-
 include/hw/i386/pc.h  | 3 ++-
 hw/i386/acpi-build.c  | 8 ++++----
 hw/i386/pc.c          | 5 ++---
 hw/i386/xen/xen-hvm.c | 3 ++-
 5 files changed, 11 insertions(+), 10 deletions(-)

diff --git a/hw/i386/acpi-build.h b/hw/i386/acpi-build.h
index 31de5bddbd..4c1511c432 100644
--- a/hw/i386/acpi-build.h
+++ b/hw/i386/acpi-build.h
@@ -10,7 +10,7 @@ extern const struct AcpiGenericAddress x86_nvdimm_acpi_dsmio;
 #define ACPI_PCIHP_SEJ_BASE 0x8
 #define ACPI_PCIHP_BNMR_BASE 0x10
 
-void acpi_setup(PCMachineState *pcms);
+void acpi_setup(PcPciMachineState *ppms);
 Object *acpi_get_i386_pci_host(void);
 
 #endif
diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index dd5ee448ef..67f8f4730b 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -41,7 +41,6 @@ typedef struct PCMachineState {
     SmbiosEntryPointType smbios_entry_point_type;
     const char *south_bridge;
 
-    bool acpi_build_enabled;
     bool smbus_enabled;
     bool sata_enabled;
     bool hpet_enabled;
@@ -61,6 +60,8 @@ typedef struct PcPciMachineState {
 
     Notifier machine_done;
 
+    bool acpi_build_enabled;
+
     CXLState cxl_devices_state;
 } PcPciMachineState;
 
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index e702d5e9d2..ee0e99a2fa 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -2749,9 +2749,9 @@ static const VMStateDescription vmstate_acpi_build = {
     },
 };
 
-void acpi_setup(PCMachineState *pcms)
+void acpi_setup(PcPciMachineState *ppms)
 {
-    X86MachineState *x86ms = X86_MACHINE(pcms);
+    X86MachineState *x86ms = X86_MACHINE(ppms);
     AcpiBuildTables tables;
     AcpiBuildState *build_state;
     Object *vmgenid_dev;
@@ -2765,7 +2765,7 @@ void acpi_setup(PCMachineState *pcms)
         return;
     }
 
-    if (!pcms->acpi_build_enabled) {
+    if (!ppms->acpi_build_enabled) {
         ACPI_BUILD_DPRINTF("ACPI build disabled. Bailing out.\n");
         return;
     }
@@ -2778,7 +2778,7 @@ void acpi_setup(PCMachineState *pcms)
     build_state = g_malloc0(sizeof *build_state);
 
     acpi_build_tables_init(&tables);
-    acpi_build(&tables, MACHINE(pcms));
+    acpi_build(&tables, MACHINE(ppms));
 
     /* Now expose it all to Guest */
     build_state->table_mr = acpi_add_rom_blob(acpi_build_update,
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 47fe3a7c02..f184808e3e 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -627,7 +627,7 @@ static void pc_pci_machine_done(Notifier *notifier, void *data)
 
     fw_cfg_add_extra_pci_roots(pcms->pcibus, x86ms->fw_cfg);
 
-    acpi_setup(pcms);
+    acpi_setup(ppms);
 }
 
 /* setup pci memory address space mapping into system address space */
@@ -1687,9 +1687,8 @@ static void pc_machine_initfn(Object *obj)
 static void pc_pci_machine_initfn(Object *obj)
 {
     PcPciMachineState *ppms = PC_PCI_MACHINE(obj);
-    PCMachineState *pcms = PC_MACHINE(obj);
 
-    pcms->acpi_build_enabled = true;
+    ppms->acpi_build_enabled = true;
 
     cxl_machine_init(obj, &ppms->cxl_devices_state);
 
diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
index 7745cb3963..ce48d51842 100644
--- a/hw/i386/xen/xen-hvm.c
+++ b/hw/i386/xen/xen-hvm.c
@@ -586,6 +586,7 @@ static void xen_wakeup_notifier(Notifier *notifier, void *data)
 void xen_hvm_init_pc(PCMachineState *pcms, MemoryRegion **ram_memory)
 {
     MachineState *ms = MACHINE(pcms);
+    PcPciMachineState *ppms = PC_PCI_MACHINE(pcms);
     unsigned int max_cpus = ms->smp.max_cpus;
     int rc;
     xen_pfn_t ioreq_pfn;
@@ -624,7 +625,7 @@ void xen_hvm_init_pc(PCMachineState *pcms, MemoryRegion **ram_memory)
     xen_ram_init(pcms, ms->ram_size, ram_memory);
 
     /* Disable ACPI build because Xen handles it */
-    pcms->acpi_build_enabled = false;
+    ppms->acpi_build_enabled = false;
 
     return;
 
-- 
2.41.0



From xen-devel-bounces@lists.xenproject.org Thu Mar 28 15:56:06 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 15:56:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699024.1091477 (Exim 4.92)
	(envelope-from )
	id 1rps6o-0003yM-Qi; Thu, 28 Mar 2024 15:56:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699024.1091477; Thu, 28 Mar 2024 15:56:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rps6o-0003yE-N5; Thu, 28 Mar 2024 15:56:06 +0000
Received: by outflank-mailman (input) for mailman id 699024;
 Thu, 28 Mar 2024 15:56:05 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rps6n-0001AK-JL
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 15:56:05 +0000
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com
 [2a00:1450:4864:20::52b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id aee72dcc-ed1b-11ee-afe3-a90da7624cb6;
 Thu, 28 Mar 2024 16:56:05 +0100 (CET)
Received: by mail-ed1-x52b.google.com with SMTP id
 4fb4d7f45d1cf-56c0bd07e7bso1371652a12.1
 for ; Thu, 28 Mar 2024 08:56:05 -0700 (PDT)
Received: from m1x-phil.lan (pas38-h02-176-184-5-52.dsl.sta.abo.bbox.fr.
 [176.184.5.52]) by smtp.gmail.com with ESMTPSA id
 ev6-20020a056402540600b005682a0e915fsm970201edb.76.2024.03.28.08.56.02
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Thu, 28 Mar 2024 08:56:04 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: aee72dcc-ed1b-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1711641364; x=1712246164; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=fL5eL7xorZDz2tK167vrCTC41p6AHRY9fWJiDBIL8BM=;
        b=aVmKDe9ABwAldbxQonVT5xEa/QK8aqCNX6AoDt3lDter6xtemBMaSXkhkzBiWs5oMV
         AwtXujfk58Af8yKkeS3OOe3WG8Y96uNE5cf7XrRiHzQIJ3+nds51B1IC1MHUHdxRJ2iD
         lRlZtOT8WoYNbOnZZOle9XX7Ie1Up15kZqDaQ3bd17BQaaL9vshvpwB+0EPohVGXC3Q0
         /2KtgFq+3zUwMyujuv0WFKVWn9T9adcbA8kwLs2Y9KBxhkLjHR5lXIypXy/IzF++MWik
         Z6m40BeUDYp1I9uhtVF34ap3QQicU6CyXhcyhauFaYhHGh3JvBrF5ERv023O2jxQm7Kc
         H5KQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711641364; x=1712246164;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=fL5eL7xorZDz2tK167vrCTC41p6AHRY9fWJiDBIL8BM=;
        b=UVxnldlrSDcjr/9FE9WvyoaL+OpSuHASJCeowaaQlSOUzDvu3zi0BTs5EMvCZ+b9XH
         Ht5lMLqsMuRfgpm8AcZ5sWwOQZfQwIf3cllYgxmjWOTDJIJlyX4p5jUZTBaIzly1iKYJ
         VGwPncYwrtLbKYDY5Lxt69vfTEBckXDAZ7g2j5tsrO9COHWGHKVvhq41wBO+/Y3pRByp
         7t09rFkXJ8M/lORGehjGi1W+6ajjTEGAjeBGRWbyQfoiLs1ujgkfK4+edmUDTk8CgW04
         ofkwS3tnK1ejM7Npl11Xk4pIBLPJXMMNs9cFgxE78JxclM/ZOo61JN+7VeoykyTH5UiT
         tFBw==
X-Forwarded-Encrypted: i=1; AJvYcCXdlWxlxbuq5uu6kESF72wddImOAZGQNkO9FBtu4/Y7JDkqq1U5vttc1edSzA8VbRJIVXhKu33Guu5ZiVpFLg2yvJvu2MrXNa3qcO6Tro8=
X-Gm-Message-State: AOJu0YxYETn/Aps2X07+W9ZF3Q4dFJx4ZblirEa1Bf6rgc6JVbpbNfAH
	Us7sSPycysGhZ43mdi68scEqu/c3XRstEYLYVIhdmaRh6JLf2Q4dxFoBDdUhBio=
X-Google-Smtp-Source: AGHT+IGYMyA4RPPygj+1esA4Svl7bwqA35pfEh79go4U6GODzZLQBPhA8oiV4mBtfx3NK33wxcn4Rg==
X-Received: by 2002:a50:d7d5:0:b0:56c:24e6:ca7e with SMTP id m21-20020a50d7d5000000b0056c24e6ca7emr2463412edj.2.1711641364572;
        Thu, 28 Mar 2024 08:56:04 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org
Cc: Richard Henderson ,
	Eduardo Habkost ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org,
	Bernhard Beschow ,
	Thomas Huth ,
	Marcel Apfelbaum ,
	"Michael S. Tsirkin" ,
	Paolo Bonzini ,
	Igor Mammedov ,
	Anthony Perard ,
	Ani Sinha ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
Subject: [RFC PATCH-for-9.1 13/29] hw/i386/pc: Remove non-PCI code from pc_system_firmware_init()
Date: Thu, 28 Mar 2024 16:54:21 +0100
Message-ID: <20240328155439.58719-14-philmd@linaro.org>
X-Mailer: git-send-email 2.41.0
In-Reply-To: <20240328155439.58719-1-philmd@linaro.org>
References: <20240328155439.58719-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

x86_bios_rom_init() is the single non-PCI-machine call
from pc_system_firmware_init(). Extract it to the caller.

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/i386/pc.c       | 6 +++++-
 hw/i386/pc_sysfw.c | 5 +----
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index f184808e3e..5b96daa414 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -956,7 +956,11 @@ void pc_memory_init(PCMachineState *pcms,
     }
 
     /* Initialize PC system firmware */
-    pc_system_firmware_init(pcms, rom_memory);
+    if (pci_enabled) {
+        pc_system_firmware_init(pcms, rom_memory);
+    } else {
+        x86_bios_rom_init(machine, "bios.bin", rom_memory, true);
+    }
 
     option_rom_mr = g_malloc(sizeof(*option_rom_mr));
     memory_region_init_ram(option_rom_mr, NULL, "pc.rom", PC_ROM_SIZE,
diff --git a/hw/i386/pc_sysfw.c b/hw/i386/pc_sysfw.c
index 862a082b0a..541dcaef71 100644
--- a/hw/i386/pc_sysfw.c
+++ b/hw/i386/pc_sysfw.c
@@ -202,10 +202,7 @@ void pc_system_firmware_init(PCMachineState *pcms,
     int i;
     BlockBackend *pflash_blk[ARRAY_SIZE(pcms->flash)];
 
-    if (!pc_machine_is_pci_enabled(pcms)) {
-        x86_bios_rom_init(MACHINE(pcms), "bios.bin", rom_memory, true);
-        return;
-    }
+    assert(pc_machine_is_pci_enabled(pcms));
 
     /* Map legacy -drive if=pflash to machine properties */
     for (i = 0; i < ARRAY_SIZE(pcms->flash); i++) {
-- 
2.41.0



From xen-devel-bounces@lists.xenproject.org Thu Mar 28 15:58:34 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 15:58:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699025.1091487 (Exim 4.92)
	(envelope-from )
	id 1rps9B-0005NF-8A; Thu, 28 Mar 2024 15:58:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699025.1091487; Thu, 28 Mar 2024 15:58:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rps9B-0005N8-5X; Thu, 28 Mar 2024 15:58:33 +0000
Received: by outflank-mailman (input) for mailman id 699025;
 Thu, 28 Mar 2024 15:58:31 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rps81-00071m-3g
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 15:57:21 +0000
Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com
 [2a00:1450:4864:20::52f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id db4cd983-ed1b-11ee-a1ef-f123f15fe8a2;
 Thu, 28 Mar 2024 16:57:19 +0100 (CET)
Received: by mail-ed1-x52f.google.com with SMTP id
 4fb4d7f45d1cf-5688eaf1165so1563121a12.1
 for ; Thu, 28 Mar 2024 08:57:19 -0700 (PDT)
Received: from m1x-phil.lan (pas38-h02-176-184-5-52.dsl.sta.abo.bbox.fr.
 [176.184.5.52]) by smtp.gmail.com with ESMTPSA id
 eb16-20020a170907281000b00a4e0df9e793sm887845ejc.136.2024.03.28.08.57.17
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Thu, 28 Mar 2024 08:57:18 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: db4cd983-ed1b-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1711641439; x=1712246239; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=KZcClnRjP7+/0e8fY+P9N5bd75aoGZ6efgZZhKhlNAY=;
        b=urCTAc0pM2fSVMVe4942E6e03pP7UrNwM+65tC2gLhhpT89TRnUFjPCagACF9b9Haa
         N8pAl0FH4karCohbzNmdO86SKN6I8sP8IOab/99ULp/4VfKtOcrqjx1Cq8UI0+X1l6Sb
         OJxoMRABGW2qolkfB55gckFkIajVQYY/7x2hpYqnW25i0oGuYIlU8wqVEBvLiLAXTp0V
         VMnhGKT/gKdDsY7lhnod41uXOxMSgwOgeUcrwTeAmahbkLRGNVgyX1hoXz+7iE4IVJjM
         Zml0aKYLisScG3UbXeYBQ74wqEZ7hE4z0nizHC3DvNsprLWIeFbXgq7T9weywnqer6cF
         Ulcw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711641439; x=1712246239;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=KZcClnRjP7+/0e8fY+P9N5bd75aoGZ6efgZZhKhlNAY=;
        b=EzjWqr6KpZ1mjewm7ZHX5r0WZN7Y4sgAZpLVe4b/ysS6mP5YSV15PrXftTkdIV6m2T
         wS3KQraV40O5gvNT5443iJJsqjySeIveG0DT8sxJCGGYONOjGDwn4VVqmsRuJA7+ipAm
         ijERbN6dIZSu7T1xhkYFduxhOIQ9ICvO0r5Bsoie6G9jImcJsabe1y6q9KHIeeke5dyR
         aJFJcLvFqEbtJ1FO/hlcncPSqhPuLfUPawBzVA9iKvVI4yuSH9aAyoSl7Ihc5CAaUmsL
         68GEaUtaAPQjcWA2NVOOwlGjQSrwnYdy2vIwfv7fohOQ4qKihKngZDETZ6ozv9HkADHe
         1CEw==
X-Forwarded-Encrypted: i=1; AJvYcCXFV+NewaBYXYz9mALMU8oF9VxidU6PDvLydR7lndZupFnaLpNgJOF7lFwfcERK+jKR/U8ER0LjwcgL5cVVaJWYErBQzJNGcvtaEviZOvk=
X-Gm-Message-State: AOJu0Yy4OrAOA3ca4FSzyQn7M+/JIXRrFZ7YZX4KKGg+ixcSVuBEHlX8
	bhaHCkUxXYn4w/9uJFVjPySi967O90EAG/zsvfEIUlt63NcXsKQg4BljS6dpFeE=
X-Google-Smtp-Source: AGHT+IFt2sBCHTR2Jv1SbwhNWwKdKTxoa7hJqsQNpLxVlwdOrAYikOdlndg+94qQnyUkEffbEuTZKw==
X-Received: by 2002:a17:907:971c:b0:a46:a1d0:8451 with SMTP id jg28-20020a170907971c00b00a46a1d08451mr2602412ejc.16.1711641439232;
        Thu, 28 Mar 2024 08:57:19 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org
Cc: Richard Henderson ,
	Eduardo Habkost ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org,
	Bernhard Beschow ,
	Thomas Huth ,
	Marcel Apfelbaum ,
	"Michael S. Tsirkin" ,
	Paolo Bonzini ,
	Igor Mammedov ,
	Anthony Perard ,
	Ani Sinha ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
Subject: [RFC PATCH-for-9.1 25/29] hw/i386/fw_cfg: Replace smbios_defaults() by !smbios_legacy_mode()
Date: Thu, 28 Mar 2024 16:54:33 +0100
Message-ID: <20240328155439.58719-26-philmd@linaro.org>
X-Mailer: git-send-email 2.41.0
In-Reply-To: <20240328155439.58719-1-philmd@linaro.org>
References: <20240328155439.58719-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

smbios_defaults() and smbios_legacy_mode() are logical
opposite. Simplify using the latter.

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/i386/fw_cfg.c | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/hw/i386/fw_cfg.c b/hw/i386/fw_cfg.c
index ffa60a4a33..df05fe060c 100644
--- a/hw/i386/fw_cfg.c
+++ b/hw/i386/fw_cfg.c
@@ -49,11 +49,6 @@ const char *fw_cfg_arch_key_name(uint16_t key)
 }
 
 #ifdef CONFIG_SMBIOS
-static bool smbios_defaults(PCMachineState *pcms)
-{
-    return pc_machine_is_pci_enabled(pcms);
-}
-
 static bool smbios_legacy_mode(PCMachineState *pcms)
 {
     return !pc_machine_is_pci_enabled(pcms);
@@ -70,7 +65,7 @@ void fw_cfg_build_smbios(PCMachineState *pcms, FWCfgState *fw_cfg,
     MachineClass *mc = MACHINE_GET_CLASS(pcms);
     X86CPU *cpu = X86_CPU(ms->possible_cpus->cpus[0].cpu);
 
-    if (smbios_defaults(pcms)) {
+    if (!smbios_legacy_mode(pcms)) {
         /* These values are guest ABI, do not change */
         smbios_set_defaults("QEMU", mc->desc, mc->name);
     }
-- 
2.41.0



From xen-devel-bounces@lists.xenproject.org Thu Mar 28 15:58:34 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 15:58:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699026.1091493 (Exim 4.92)
	(envelope-from )
	id 1rps9B-0005QW-Ja; Thu, 28 Mar 2024 15:58:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699026.1091493; Thu, 28 Mar 2024 15:58:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rps9B-0005Pq-Cr; Thu, 28 Mar 2024 15:58:33 +0000
Received: by outflank-mailman (input) for mailman id 699026;
 Thu, 28 Mar 2024 15:58:31 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rps7V-0001AK-1u
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 15:56:49 +0000
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com
 [2a00:1450:4864:20::62e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c8c3fa24-ed1b-11ee-afe3-a90da7624cb6;
 Thu, 28 Mar 2024 16:56:48 +0100 (CET)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-a46ea03c2a5so216859666b.1
 for ; Thu, 28 Mar 2024 08:56:48 -0700 (PDT)
Received: from m1x-phil.lan (pas38-h02-176-184-5-52.dsl.sta.abo.bbox.fr.
 [176.184.5.52]) by smtp.gmail.com with ESMTPSA id
 u23-20020a170906125700b00a47522c193asm892212eja.196.2024.03.28.08.56.46
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Thu, 28 Mar 2024 08:56:47 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c8c3fa24-ed1b-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1711641408; x=1712246208; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=3Aa27ZqAQEFmCBsiqy9XwiiPf6EIjcNyjahGDi9IpJg=;
        b=THbj2G4pRSyqcX7zGCv8FZ3Kjw9z916Flj1ZcDQO8dyIO9fmrg8zrDl4HQ8ErAxQ5m
         Cm5xyqf8FsiXzq3+HbSV+Yni/NyHB827BgCRV00bvn2orEdmLsOdnKaEnFcgebPtcphh
         wqvHFsgZ5R4Tnu/BfPmUhHH4LKN3e7xOvk9Mv0XcDWDq4ocxokge6aWQQd0X0YsHmHmK
         riPxiT1gY9Yg6nz+k+cvQKpDwo+kUvWG11U8hAW0lg8wtDq1fr+JZ5W1UflF2FHcWu1F
         jtfGzlqcLdkUcvaF7GvDQ/ZHfV+lqBAbCajUXNYvLiNYBbUiLTbpAHTbJHOsKLlTpQqv
         pn9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711641408; x=1712246208;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=3Aa27ZqAQEFmCBsiqy9XwiiPf6EIjcNyjahGDi9IpJg=;
        b=GUTR01UyxXmykMSHJ/67r4FujSCOhkA3dgXhEf+I9r0zC3iaENeujIJT7zCHLvLpiV
         JnrNaqzrqKHMFkNOaTrr9+QGOwG/DfPiJ/+4nERQFOnBi93FaKpj7Y26vwYMGBONPsiP
         1d1hCY9K+nmLmofIGClfSspCGE2YSRNKl6OuAL6wmMk8nGWNpiiNlu0hDWPkzumhKlV4
         oZut4iKwGBEUMNMVJFbMBA11BR+Y7D2JTNlnjlhUZzw351iaozUxZElxUFoLeL9lA6B1
         NtOuWoDOhBXQ0UyCxtv4RZJzuEHB7hzhEnB2jsSNsK+Iy5l8NOp7z3tkA6EReNYaDNgl
         bOtA==
X-Forwarded-Encrypted: i=1; AJvYcCVSDbFAQIozLKArjDWcmV3yXtu2ORZi+cKpbP34bHFwaHQQnxCXdk3tVNfazMLuZgKpWZtW9wt3bYHm9TUXN/BNUglstWb6pR3O1idVd8o=
X-Gm-Message-State: AOJu0Yw6uIj/K1V92VfcbGQWBfwXxWQwbBAfcH1YpwBsEbc6niPwOKdG
	HgVBrH+aPR9U4zeZ2nmBHN0/OVIplkIFN1Okhgl3ju5I6Zl82CVkf0suo8XVeIw=
X-Google-Smtp-Source: AGHT+IGf+dMAnCAltiuzPzgchc+sbbW407Sj1dQczYyJgyomDKws4CVNCOW6jzbL55k6+JJbXoaF8w==
X-Received: by 2002:a17:906:ccc3:b0:a47:1f61:4d02 with SMTP id ot3-20020a170906ccc300b00a471f614d02mr2207346ejb.36.1711641408058;
        Thu, 28 Mar 2024 08:56:48 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org
Cc: Richard Henderson ,
	Eduardo Habkost ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org,
	Bernhard Beschow ,
	Thomas Huth ,
	Marcel Apfelbaum ,
	"Michael S. Tsirkin" ,
	Paolo Bonzini ,
	Igor Mammedov ,
	Anthony Perard ,
	Ani Sinha ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
Subject: [RFC PATCH-for-9.1 20/29] hw/i386/pc: Pass PcPciMachineState argument to pc_pci_hole64_start()
Date: Thu, 28 Mar 2024 16:54:28 +0100
Message-ID: <20240328155439.58719-21-philmd@linaro.org>
X-Mailer: git-send-email 2.41.0
In-Reply-To: <20240328155439.58719-1-philmd@linaro.org>
References: <20240328155439.58719-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

pc_pci_hole64_start() is only used by PCI-based
machines.  Pass it a PcPciMachineState argument,
removing a qdev_get_machine() call.

Signed-off-by: Philippe Mathieu-Daudé 
---
 include/hw/i386/pc.h | 2 +-
 hw/i386/pc.c         | 8 ++++----
 hw/pci-host/i440fx.c | 2 +-
 hw/pci-host/q35.c    | 2 +-
 4 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index df4c813854..7da0bc8aa4 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -157,7 +157,7 @@ void pc_memory_init(PCMachineState *pcms,
                     MemoryRegion *system_memory,
                     MemoryRegion *rom_memory,
                     uint64_t pci_hole64_size);
-uint64_t pc_pci_hole64_start(void);
+uint64_t pc_pci_hole64_start(PcPciMachineState *ppms);
 DeviceState *pc_vga_init(ISABus *isa_bus, PCIBus *pci_bus);
 void pc_basic_device_init(struct PCMachineState *pcms,
                           ISABus *isa_bus, qemu_irq *gsi,
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index d8e91d18b8..b83abee8e9 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -747,7 +747,8 @@ static hwaddr pc_max_used_gpa(PCMachineState *pcms, uint64_t pci_hole64_size)
 
     if (cpu->env.features[FEAT_8000_0001_EDX] & CPUID_EXT2_LM) {
         /* 64-bit systems */
-        return pc_pci_hole64_start() + pci_hole64_size - 1;
+        PcPciMachineState *ppms = PC_PCI_MACHINE(pcms);
+        return pc_pci_hole64_start(ppms) + pci_hole64_size - 1;
     }
 
     /* 32-bit systems */
@@ -1016,11 +1017,10 @@ void pc_memory_init(PCMachineState *pcms,
  * The 64bit pci hole starts after "above 4G RAM" and
  * potentially the space reserved for memory hotplug.
  */
-uint64_t pc_pci_hole64_start(void)
+uint64_t pc_pci_hole64_start(PcPciMachineState *ppms)
 {
-    PCMachineState *pcms = PC_MACHINE(qdev_get_machine());
+    PCMachineState *pcms = PC_MACHINE(ppms);
     PCMachineClass *pcmc = PC_MACHINE_GET_CLASS(pcms);
-    PcPciMachineState *ppms = PC_PCI_MACHINE(pcms);
     MachineState *ms = MACHINE(pcms);
     uint64_t hole64_start = 0;
     ram_addr_t size = 0;
diff --git a/hw/pci-host/i440fx.c b/hw/pci-host/i440fx.c
index 4f0a0438d7..add99e4f76 100644
--- a/hw/pci-host/i440fx.c
+++ b/hw/pci-host/i440fx.c
@@ -180,7 +180,7 @@ static uint64_t i440fx_pcihost_get_pci_hole64_start_value(Object *obj)
     pci_bus_get_w64_range(h->bus, &w64);
     value = range_is_empty(&w64) ? 0 : range_lob(&w64);
     if (!value && s->pci_hole64_fix) {
-        value = pc_pci_hole64_start();
+        value = pc_pci_hole64_start(PC_PCI_MACHINE(qdev_get_machine()));
     }
     return value;
 }
diff --git a/hw/pci-host/q35.c b/hw/pci-host/q35.c
index 0d7d4e3f08..baf55897b2 100644
--- a/hw/pci-host/q35.c
+++ b/hw/pci-host/q35.c
@@ -123,7 +123,7 @@ static uint64_t q35_host_get_pci_hole64_start_value(Object *obj)
     pci_bus_get_w64_range(h->bus, &w64);
     value = range_is_empty(&w64) ? 0 : range_lob(&w64);
     if (!value && s->pci_hole64_fix) {
-        value = pc_pci_hole64_start();
+        value = pc_pci_hole64_start(PC_PCI_MACHINE(qdev_get_machine()));
     }
     return value;
 }
-- 
2.41.0



From xen-devel-bounces@lists.xenproject.org Thu Mar 28 15:59:32 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 15:59:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699030.1091507 (Exim 4.92)
	(envelope-from )
	id 1rpsA0-0006YU-0V; Thu, 28 Mar 2024 15:59:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699030.1091507; Thu, 28 Mar 2024 15:59:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rps9z-0006YN-Tm; Thu, 28 Mar 2024 15:59:23 +0000
Received: by outflank-mailman (input) for mailman id 699030;
 Thu, 28 Mar 2024 15:59:23 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rps7I-0001AK-SM
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 15:56:36 +0000
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com
 [2a00:1450:4864:20::52c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c1831ad9-ed1b-11ee-afe3-a90da7624cb6;
 Thu, 28 Mar 2024 16:56:36 +0100 (CET)
Received: by mail-ed1-x52c.google.com with SMTP id
 4fb4d7f45d1cf-5684db9147dso1315122a12.2
 for ; Thu, 28 Mar 2024 08:56:36 -0700 (PDT)
Received: from m1x-phil.lan (pas38-h02-176-184-5-52.dsl.sta.abo.bbox.fr.
 [176.184.5.52]) by smtp.gmail.com with ESMTPSA id
 l13-20020a056402028d00b0056bfa6ad5eesm959518edv.91.2024.03.28.08.56.34
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Thu, 28 Mar 2024 08:56:35 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c1831ad9-ed1b-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1711641396; x=1712246196; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=mvS5b4mOvRgBMXReEbw8mHkHwY6O9r1j8WjPX6hg3zo=;
        b=gnpdPFgLW51sHyUyoXDwAOZDvI82FBpxhPc1kJVd0P9OD+7e9BhtZVFFO40jzchbss
         VkTI4CekE0NeVoVzrAAMMTZlO7irkRt417toCdVs0Vd/bsP0bMwgf9T0O5sc8zm9D62u
         qrgU5PVgvyyOkWhdTvcodVbGc1u2IKv1/J/l1pa4Db+oT20L3G9hUzbb6y+djmif+EPQ
         Vmw/yflu4lHS5lPkcqIgqElyt0VpedKVGk9VbTOk+vOjWPuFHrPNO/CnHFeXOd+eVUV9
         /2RhBmvOtqeWCF7ol7JeHxDXkovaoPgReWAHhYGLVPpOO0F3dSLOsZgF7MLn2H1Nb/EW
         DJlQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711641396; x=1712246196;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=mvS5b4mOvRgBMXReEbw8mHkHwY6O9r1j8WjPX6hg3zo=;
        b=shV4e98lHzsq7+CX3Itr+Kbug4Fk5fGKUZne70K11rMq0F8smHLE9ZsEXiui9cNhLA
         UfXKo8Nw8j4b428R0Wdmf8VXhnKSemzCfl6N1M0eOCtoeZxLV7jXrACdc7TRogD+9J2N
         XQn+RmjOTx9LeBFWjB6R4CYeUZW9POh2Tw1uEibBKpvUkZ7KXnK0TQ1PdLtEs1sLVBY1
         /I2w0ioZch9RhCO+/zC37LTngmtZjc244Qv2V5gqmtHsuQVex06kvI6/UU5ZeyNFYS5B
         LZ2uBvlgu3yUHENyvwEfFcNSpc29QIXLMX5E06jhQ6oZ3wYX5yRME4Ab+VHP6ipyhFKX
         glFw==
X-Forwarded-Encrypted: i=1; AJvYcCXaTin6EX8lHgqxMhVP4ars4fwYtjb0qhSlBsAdZg1ACdjn52ZiPyOPEO+/iFfJhw+reMN/aTHJ22JPW1lmccojQ3JYCyx46owPXSB2K2E=
X-Gm-Message-State: AOJu0Ywf63NaRPxaZc34WS2tG+Qy7tArtsPKxB15XqQIZIlBIfu++SMf
	w42N1fUwhYXuWk34+m7ObYI4QqZwaj2WQ9SVDIT4OQJYMQgSWM1WvKG3QoRfILs=
X-Google-Smtp-Source: AGHT+IHfWPHo1qaEN4DNEm3R8wOVj4A4iUDXGogGmGPb4Wx0aiRPAERFSIayiOeRYDhmlaAPcH41sw==
X-Received: by 2002:a50:d6d7:0:b0:568:a9f3:b3fb with SMTP id l23-20020a50d6d7000000b00568a9f3b3fbmr2267809edj.8.1711641395712;
        Thu, 28 Mar 2024 08:56:35 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org
Cc: Richard Henderson ,
	Eduardo Habkost ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org,
	Bernhard Beschow ,
	Thomas Huth ,
	Marcel Apfelbaum ,
	"Michael S. Tsirkin" ,
	Paolo Bonzini ,
	Igor Mammedov ,
	Anthony Perard ,
	Ani Sinha ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
Subject: [RFC PATCH-for-9.1 18/29] hw/i386/pc: Inline has_reserved_memory()
Date: Thu, 28 Mar 2024 16:54:26 +0100
Message-ID: <20240328155439.58719-19-philmd@linaro.org>
X-Mailer: git-send-email 2.41.0
In-Reply-To: <20240328155439.58719-1-philmd@linaro.org>
References: <20240328155439.58719-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

All PCI-based machines have the has_reserved_memory
field set to %true. Simplify by using an inlined helper
checking whether the machine is PCI-based or not.

Signed-off-by: Philippe Mathieu-Daudé 
---
 include/hw/i386/pc.h |  1 -
 hw/i386/pc.c         | 17 ++++++++++-------
 hw/i386/pc_piix.c    |  1 -
 3 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 758dd5f29b..df4c813854 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -91,7 +91,6 @@ typedef struct PCMachineClass {
     SmbiosEntryPointType default_smbios_ep_type;
 
     /* RAM / address space compat: */
-    bool has_reserved_memory;
     bool broken_reserved_end;
     bool enforce_amd_1tb_hole;
 
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 093a7c35f7..e36d76656b 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -671,6 +671,11 @@ void xen_load_linux(PCMachineState *pcms)
 #define PC_ROM_ALIGN       0x800
 #define PC_ROM_SIZE        (PC_ROM_MAX - PC_ROM_MIN_VGA)
 
+static bool has_reserved_memory(PCMachineState *pcms)
+{
+    return pc_machine_is_pci_enabled(pcms);
+}
+
 static hwaddr pc_above_4g_end(PCMachineState *pcms)
 {
     X86MachineState *x86ms = X86_MACHINE(pcms);
@@ -702,12 +707,11 @@ static void pc_get_device_memory_range(PCMachineState *pcms,
 
 static uint64_t pc_get_cxl_range_start(PCMachineState *pcms)
 {
-    PCMachineClass *pcmc = PC_MACHINE_GET_CLASS(pcms);
     MachineState *ms = MACHINE(pcms);
     hwaddr cxl_base;
     ram_addr_t size;
 
-    if (pcmc->has_reserved_memory &&
+    if (has_reserved_memory(pcms) &&
         (ms->ram_size < ms->maxram_size)) {
         pc_get_device_memory_range(pcms, &cxl_base, &size);
         cxl_base += size;
@@ -760,7 +764,7 @@ static hwaddr pc_max_used_gpa(PCMachineState *pcms, uint64_t pci_hole64_size)
      * calculating the highest possible GPA so that we can properly report
      * if someone configures them on a CPU that cannot possibly address them.
      */
-    if (pcmc->has_reserved_memory &&
+    if (has_reserved_memory(pcms) &&
         (ms->ram_size < ms->maxram_size)) {
         hwaddr devmem_start;
         ram_addr_t devmem_size;
@@ -891,7 +895,7 @@ void pc_memory_init(PCMachineState *pcms,
         e820_add_entry(pcms->sgx_epc.base, pcms->sgx_epc.size, E820_RESERVED);
     }
 
-    if (!pcmc->has_reserved_memory &&
+    if (!has_reserved_memory(pcms) &&
         (machine->ram_slots ||
          (machine->maxram_size > machine->ram_size))) {
 
@@ -901,7 +905,7 @@ void pc_memory_init(PCMachineState *pcms,
     }
 
     /* initialize device memory address space */
-    if (pcmc->has_reserved_memory &&
+    if (has_reserved_memory(pcms) &&
         (machine->ram_size < machine->maxram_size)) {
         ram_addr_t device_mem_size;
         hwaddr device_mem_base;
@@ -1024,7 +1028,7 @@ uint64_t pc_pci_hole64_start(void)
 
     if (ppms->cxl_devices_state.is_enabled) {
         hole64_start = pc_get_cxl_range_end(pcms);
-    } else if (pcmc->has_reserved_memory && (ms->ram_size < ms->maxram_size)) {
+    } else if (has_reserved_memory(pcms) && (ms->ram_size < ms->maxram_size)) {
         pc_get_device_memory_range(pcms, &hole64_start, &size);
         if (!pcmc->broken_reserved_end) {
             hole64_start += size;
@@ -1752,7 +1756,6 @@ static void pc_machine_class_init(ObjectClass *oc, void *data)
     HotplugHandlerClass *hc = HOTPLUG_HANDLER_CLASS(oc);
 
     pcmc->smbios_defaults = true;
-    pcmc->has_reserved_memory = true;
     pcmc->enforce_amd_1tb_hole = true;
     pcmc->pvh_enabled = true;
     pcmc->kvmclock_create_always = true;
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 0bc14da768..e6178f8653 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -830,7 +830,6 @@ static void isapc_machine_options(MachineClass *m)
     m->rom_file_has_mr = false;
     pcmc->smbios_defaults = false;
     pcmc->smbios_legacy_mode = true;
-    pcmc->has_reserved_memory = false;
     m->default_nic = "ne2k_isa";
     m->default_cpu_type = X86_CPU_TYPE_NAME("486");
     m->no_parallel = !module_object_class_by_name(TYPE_ISA_PARALLEL);
-- 
2.41.0



From xen-devel-bounces@lists.xenproject.org Thu Mar 28 16:01:19 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 16:01:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699036.1091532 (Exim 4.92)
	(envelope-from )
	id 1rpsBn-0000Tn-Ee; Thu, 28 Mar 2024 16:01:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699036.1091532; Thu, 28 Mar 2024 16:01:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpsBn-0000Tg-CA; Thu, 28 Mar 2024 16:01:15 +0000
Received: by outflank-mailman (input) for mailman id 699036;
 Thu, 28 Mar 2024 16:01:14 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rps87-00071m-Ey
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 15:57:27 +0000
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com
 [2a00:1450:4864:20::631])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id df0457be-ed1b-11ee-a1ef-f123f15fe8a2;
 Thu, 28 Mar 2024 16:57:25 +0100 (CET)
Received: by mail-ej1-x631.google.com with SMTP id
 a640c23a62f3a-a466fc8fcccso150254866b.1
 for ; Thu, 28 Mar 2024 08:57:25 -0700 (PDT)
Received: from m1x-phil.lan (pas38-h02-176-184-5-52.dsl.sta.abo.bbox.fr.
 [176.184.5.52]) by smtp.gmail.com with ESMTPSA id
 k13-20020a1709067acd00b00a47df55cf5esm914850ejo.13.2024.03.28.08.57.23
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Thu, 28 Mar 2024 08:57:24 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: df0457be-ed1b-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1711641445; x=1712246245; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=9JGjTd1WToEahvAfY8NVbIAQ8SXrGvIMBj7UnII/d+c=;
        b=PeVw7HqXQfyBYwOKtTmkKxh/q/3MsDf5dRffkzxN75mmNWLGDz7BfVnLg8UpfjkAg3
         wI/pk0M6bxXyA1jrgBCU4MlXe2KbpYWkhEIIj8qYMqyxOmVTJwXrS3PxFl8AvkrAq/tB
         LzFRv+slu77S3ImpIMoz+N+3s/hvDiXfv+bW3v3qaMp4bU4JROokgdUiVRDAuiQCaACB
         S8vQAGYW74BwUaU3x4GJh61cqkY1ic3HkOoGEKgosfwXanV3dd3OOK/yfU5bews5qTS3
         VuOQrXHCY+7AbLOWwXVZejkRUgOt3+vhm4UB55w7WOUQXhsH95ay8CvBzTJSXZ5LjQR8
         iuUw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711641445; x=1712246245;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=9JGjTd1WToEahvAfY8NVbIAQ8SXrGvIMBj7UnII/d+c=;
        b=dlrhL8wiWOdA7rTUMueHCGsk4xNsjpkbZ5VFF6zxtvytoeThwrQDdCgK6b/gpl1kcz
         TTGIkJbCsGnTp7JP6wsE6+rfNSnYrDQUJOKIPzWcFMl+/ovsILu5DvD+M7V8eJkdmFAQ
         /9p5/XN4zkizrlPhhHJnv/Y3fvWOyfMJ7Zcx8rNHtvQpAMvk6yTYWCoIRM/mGMifSlka
         l2MQFm62e0uCZOLseTVITG5R49GGwy+Jvj0fwNg3O2ioOqz85M3Dsi2dluBnc/lLfFYO
         Y7CQfYilYZ4QqaWeCPnz2pk7m6gPV7ahjRKyxhQOSTXBmpnmY5ylVI4O2dN9No+hjh18
         VEqg==
X-Forwarded-Encrypted: i=1; AJvYcCUrO0trlGvISPTKXfXOIHddDf1fUrfFKvy8LmIAjRjlNzg4nTRRyaRgmtfrWZq+o3e/d82U4vpdRTORdoknRlYppTwwy3tS4qvYIePOrhA=
X-Gm-Message-State: AOJu0YzL5a8Xd359Cf6IKwVi0ZqcS66vmowWNxA8il7Po88Ai78739gv
	oX06+aIEJQq4M65Mb/MnfLFCVT4+f/Ws6zWzcYCV5CUF5K9mS0WcAub66FRWxDU=
X-Google-Smtp-Source: AGHT+IEke0w2rGaQ9eaNpJe9RsSUrMNnkosA5ZqUCdCrrEsx8n7A8+12nHMQifWFPzkMKHDz/PJUtg==
X-Received: by 2002:a17:907:7d89:b0:a47:5265:9aac with SMTP id oz9-20020a1709077d8900b00a4752659aacmr2577836ejc.55.1711641445324;
        Thu, 28 Mar 2024 08:57:25 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org
Cc: Richard Henderson ,
	Eduardo Habkost ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org,
	Bernhard Beschow ,
	Thomas Huth ,
	Marcel Apfelbaum ,
	"Michael S. Tsirkin" ,
	Paolo Bonzini ,
	Igor Mammedov ,
	Anthony Perard ,
	Ani Sinha ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
Subject: [RFC PATCH-for-9.1 26/29] hw/i386/fw_cfg: Factor fw_cfg_build_smbios_legacy() out
Date: Thu, 28 Mar 2024 16:54:34 +0100
Message-ID: <20240328155439.58719-27-philmd@linaro.org>
X-Mailer: git-send-email 2.41.0
In-Reply-To: <20240328155439.58719-1-philmd@linaro.org>
References: <20240328155439.58719-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Factor fw_cfg_build_smbios_legacy() out of
fw_cfg_build_smbios().

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/i386/fw_cfg.h             |  1 +
 hw/i386/fw_cfg-smbios-stub.c |  4 ++++
 hw/i386/fw_cfg.c             | 33 ++++++++++++++++++++++-----------
 3 files changed, 27 insertions(+), 11 deletions(-)

diff --git a/hw/i386/fw_cfg.h b/hw/i386/fw_cfg.h
index 7a426119f8..25ce86ec1b 100644
--- a/hw/i386/fw_cfg.h
+++ b/hw/i386/fw_cfg.h
@@ -24,6 +24,7 @@
 FWCfgState *fw_cfg_arch_create(MachineState *ms,
                                uint16_t boot_cpus,
                                uint16_t apic_id_limit);
+void fw_cfg_build_smbios_legacy(PCMachineState *pcms, FWCfgState *fw_cfg);
 void fw_cfg_build_smbios(PCMachineState *pcms, FWCfgState *fw_cfg,
                          SmbiosEntryPointType ep_type);
 void fw_cfg_build_feature_control(MachineState *ms, FWCfgState *fw_cfg);
diff --git a/hw/i386/fw_cfg-smbios-stub.c b/hw/i386/fw_cfg-smbios-stub.c
index 37dbfdee7c..da00ffc9ae 100644
--- a/hw/i386/fw_cfg-smbios-stub.c
+++ b/hw/i386/fw_cfg-smbios-stub.c
@@ -13,3 +13,7 @@ void fw_cfg_build_smbios(PCMachineState *pcms, FWCfgState *fw_cfg,
                          SmbiosEntryPointType ep_type)
 {
 }
+
+void fw_cfg_build_smbios_legacy(PCMachineState *pcms, FWCfgState *fw_cfg)
+{
+}
diff --git a/hw/i386/fw_cfg.c b/hw/i386/fw_cfg.c
index df05fe060c..be37e28f46 100644
--- a/hw/i386/fw_cfg.c
+++ b/hw/i386/fw_cfg.c
@@ -54,6 +54,22 @@ static bool smbios_legacy_mode(PCMachineState *pcms)
     return !pc_machine_is_pci_enabled(pcms);
 }
 
+void fw_cfg_build_smbios_legacy(PCMachineState *pcms, FWCfgState *fw_cfg)
+{
+    uint8_t *smbios_tables;
+    size_t smbios_tables_len;
+    MachineState *ms = MACHINE(pcms);
+    X86CPU *cpu = X86_CPU(ms->possible_cpus->cpus[0].cpu);
+
+    /* tell smbios about cpuid version and features */
+    smbios_set_cpuid(cpu->env.cpuid_version, cpu->env.features[FEAT_1_EDX]);
+
+    smbios_tables = smbios_get_table_legacy(&smbios_tables_len,
+                                            &error_fatal);
+    fw_cfg_add_bytes(fw_cfg, FW_CFG_SMBIOS_ENTRIES,
+                     smbios_tables, smbios_tables_len);
+}
+
 void fw_cfg_build_smbios(PCMachineState *pcms, FWCfgState *fw_cfg,
                          SmbiosEntryPointType ep_type)
 {
@@ -65,22 +81,17 @@ void fw_cfg_build_smbios(PCMachineState *pcms, FWCfgState *fw_cfg,
     MachineClass *mc = MACHINE_GET_CLASS(pcms);
     X86CPU *cpu = X86_CPU(ms->possible_cpus->cpus[0].cpu);
 
-    if (!smbios_legacy_mode(pcms)) {
-        /* These values are guest ABI, do not change */
-        smbios_set_defaults("QEMU", mc->desc, mc->name);
+    if (smbios_legacy_mode(pcms)) {
+        fw_cfg_build_smbios_legacy(pcms, fw_cfg);
+        return;
     }
 
+    /* These values are guest ABI, do not change */
+    smbios_set_defaults("QEMU", mc->desc, mc->name);
+
     /* tell smbios about cpuid version and features */
     smbios_set_cpuid(cpu->env.cpuid_version, cpu->env.features[FEAT_1_EDX]);
 
-    if (smbios_legacy_mode(pcms)) {
-        smbios_tables = smbios_get_table_legacy(&smbios_tables_len,
-                                                &error_fatal);
-        fw_cfg_add_bytes(fw_cfg, FW_CFG_SMBIOS_ENTRIES,
-                         smbios_tables, smbios_tables_len);
-        return;
-    }
-
     /* build the array of physical mem area from e820 table */
     mem_array = g_malloc0(sizeof(*mem_array) * e820_get_num_entries());
     for (i = 0, array_count = 0; i < e820_get_num_entries(); i++) {
-- 
2.41.0



From xen-devel-bounces@lists.xenproject.org Thu Mar 28 16:01:31 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 16:01:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699037.1091543 (Exim 4.92)
	(envelope-from )
	id 1rpsC3-0000pb-O7; Thu, 28 Mar 2024 16:01:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699037.1091543; Thu, 28 Mar 2024 16:01:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpsC3-0000pS-Kh; Thu, 28 Mar 2024 16:01:31 +0000
Received: by outflank-mailman (input) for mailman id 699037;
 Thu, 28 Mar 2024 16:01:30 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rps7b-0001AK-C2
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 15:56:55 +0000
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com
 [2a00:1450:4864:20::630])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id cc8680f1-ed1b-11ee-afe3-a90da7624cb6;
 Thu, 28 Mar 2024 16:56:54 +0100 (CET)
Received: by mail-ej1-x630.google.com with SMTP id
 a640c23a62f3a-a2f22bfb4e6so155203766b.0
 for ; Thu, 28 Mar 2024 08:56:54 -0700 (PDT)
Received: from m1x-phil.lan (pas38-h02-176-184-5-52.dsl.sta.abo.bbox.fr.
 [176.184.5.52]) by smtp.gmail.com with ESMTPSA id
 x16-20020a170906135000b00a46ee3c31afsm884227ejb.154.2024.03.28.08.56.52
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Thu, 28 Mar 2024 08:56:54 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: cc8680f1-ed1b-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1711641414; x=1712246214; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=wAY/yw6dYKkUP/WFLvpvljjwD9mQwkPWyyzr0cq0w+A=;
        b=LziBG55fXFnBOAAR2+719XgGwzr5DV3/+fBODODb6hO9Eqwt59sGLE2eVqc9w1zjhL
         yHxQA5QZ93utZHTv/qoUa5Hh7DZEOGH5mN4ZYM7uRdoYL+i7vtLgUYKajhwA5uveDHLt
         RTaBq45tlyDnhc5daWAUKFQ0EDF9L0S060a4rEJch0joV9X0ko5slrAPj4ZiSAmr2kpU
         J0z5btOCOfdZCmSKwMK3zJHidw7nqq2xv2PtU0OqVyAkGqiPQKXC2sRWZpAkG3oY7+4k
         Tin+oVDeyRVHUg7CcR6YBPEE3hVTUCOLPYkIzglSWLsStg8Pikfl6A+oHagG0QZrIp+Z
         a0dQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711641414; x=1712246214;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=wAY/yw6dYKkUP/WFLvpvljjwD9mQwkPWyyzr0cq0w+A=;
        b=jCWfIN+DDrCKAxkbYAmq5pHwC7zlBl7mZuubXuozji4ynpdjhTEHHXQuS/T6KVsmIk
         IrFs7NXfigxaIv11kGPVlxOfMgYOmCxD3i5lXtTDx3bbiWBEvzXy8cBSh/zYpCAwg5A/
         KJYqdF5a8sP73JD+cSTWTwK7z3Qxh4ZWlGl+N6K9ZJXFGruX/Cks+uU/vVtibXEDWy+a
         eTfAuGlxlJfcJ3nNhFX7pw1rBtjDTQLuj73M35EQxfbkEB1XnsS94ahee0QilzmiCDLM
         +40jEuDbdbg6Z4NPS06mPVJu30va3nkVpEsGNtOH0lhwLp0Iw2Frq7CG9ASJBU3i7HVa
         Q47Q==
X-Forwarded-Encrypted: i=1; AJvYcCUIGXQ/h8JlvSSZbn31WP/cKSE8Ps6IfpkP3wbBI1yrgBv0wJrqYavHW7+Pc9cPgzyjtcJz7gkUy31dPzVDHYcTwYls8J4ND2DSqQ+U2rg=
X-Gm-Message-State: AOJu0Yy0xJGlM2KKXEPrGX4AxIXBlX2Zyx5lQiEv+NAfQ4TP7thzZxpL
	9dVcpvrVZKJewHuft/KoFYp9gf6AB0ItDg2guNbCq4nh8zUEoMRhe1sebQlbXfI=
X-Google-Smtp-Source: AGHT+IHHCjINc+B1WA7YTf9CDPOy43wJYCQL0voBiUNztEKWZkyjgtHiZiJjx/du9sQyScNWeJj6tg==
X-Received: by 2002:a17:906:35d0:b0:a47:11a9:9038 with SMTP id p16-20020a17090635d000b00a4711a99038mr2127429ejb.58.1711641414401;
        Thu, 28 Mar 2024 08:56:54 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org
Cc: Richard Henderson ,
	Eduardo Habkost ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org,
	Bernhard Beschow ,
	Thomas Huth ,
	Marcel Apfelbaum ,
	"Michael S. Tsirkin" ,
	Paolo Bonzini ,
	Igor Mammedov ,
	Anthony Perard ,
	Ani Sinha ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
Subject: [RFC PATCH-for-9.1 21/29] hw/i386/fw_cfg: Include missing 'qapi-types-machine.h' header
Date: Thu, 28 Mar 2024 16:54:29 +0100
Message-ID: <20240328155439.58719-22-philmd@linaro.org>
X-Mailer: git-send-email 2.41.0
In-Reply-To: <20240328155439.58719-1-philmd@linaro.org>
References: <20240328155439.58719-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

"fw_cfg.h" declares fw_cfg_build_smbios() which use
SmbiosEntryPointType, itself declared in "qapi-types-machine.h".

  void fw_cfg_build_smbios(PCMachineState *pcms, FWCfgState *fw_cfg,
                           SmbiosEntryPointType ep_type);
                           ^^^^^^^^^^^^^^^^^^^^

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/i386/fw_cfg.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/i386/fw_cfg.h b/hw/i386/fw_cfg.h
index 92e310f5fd..7a426119f8 100644
--- a/hw/i386/fw_cfg.h
+++ b/hw/i386/fw_cfg.h
@@ -12,6 +12,7 @@
 #include "hw/boards.h"
 #include "hw/i386/pc.h"
 #include "hw/nvram/fw_cfg.h"
+#include "qapi/qapi-types-machine.h"
 
 #define FW_CFG_IO_BASE     0x510
 
-- 
2.41.0



From xen-devel-bounces@lists.xenproject.org Thu Mar 28 16:01:35 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 16:01:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699038.1091553 (Exim 4.92)
	(envelope-from )
	id 1rpsC6-000182-VS; Thu, 28 Mar 2024 16:01:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699038.1091553; Thu, 28 Mar 2024 16:01:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpsC6-00017v-S5; Thu, 28 Mar 2024 16:01:34 +0000
Received: by outflank-mailman (input) for mailman id 699038;
 Thu, 28 Mar 2024 16:01:33 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rps7O-0001AK-Oe
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 15:56:42 +0000
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com
 [2a00:1450:4864:20::533])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c50d2a0f-ed1b-11ee-afe3-a90da7624cb6;
 Thu, 28 Mar 2024 16:56:42 +0100 (CET)
Received: by mail-ed1-x533.google.com with SMTP id
 4fb4d7f45d1cf-56c36f8f932so3857578a12.0
 for ; Thu, 28 Mar 2024 08:56:42 -0700 (PDT)
Received: from m1x-phil.lan (pas38-h02-176-184-5-52.dsl.sta.abo.bbox.fr.
 [176.184.5.52]) by smtp.gmail.com with ESMTPSA id
 dr3-20020a170907720300b00a4a38d10801sm896023ejc.35.2024.03.28.08.56.40
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Thu, 28 Mar 2024 08:56:41 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c50d2a0f-ed1b-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1711641402; x=1712246202; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=muQ9YYs1garpvhloVWRUiLPzA6iwq65Rr1SdS4smlFw=;
        b=RWcLFlwpxKOxRVTv6vZ42+0EO6VG+UqgRYg/Yo3diAdm7VfxfYajPuiS/IWOCVx9n4
         gnavJs7860POBYvxnh+h48KI8/oAOCLgxg0TTSdlKVlF/tBxBic+H4q277gRJo0Ttt/5
         tOlM632xJ5ggf6c3ohagfDn4o+Tz6uZ3eMVSVAkrCe7MVVtXjpsXnLAhTSvcin/6TK36
         5j8Kxl7K+FkF+FIbIShxCzT048BX4Gy2hwDeNN45OHLlzIrcqbsLJMFCXBDx6aj8Bn/O
         09/dy7b9LgaS+poSbdkLS+YB5MZ5M2UmayC4VA04XSbN30OqYG6oC16p7pBeRY7SdwPQ
         UaFQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711641402; x=1712246202;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=muQ9YYs1garpvhloVWRUiLPzA6iwq65Rr1SdS4smlFw=;
        b=L2Sokzu5ITWusGqpR5j2WJ8y0jLddOsJrDXnyfTaxX1Y36mW/XT4Q7SmPE8+kouH47
         sN4DFGt/JXON5fe28/TcM25sKvhPC5wakW2AKpTF95a4UBSM/CoQR7dsjpYIWrnJElye
         f85StrGViMWCN1LJPykCCRQ0Tp8RKCnrBUffMOMaSNLV4rf2r3dv+lJtNx3GYATuiLOL
         YDowCuRF0kk7gObdsRxo/snFtTgMAahQ7AIyCW+s48kGvdnvTO2Ki57fJ/80cQI6DOqy
         WajyDsF+M67g3tW7+QCs4sgyVJyq8N603hRJ3ZTeF6C2/WlUKZOTNZp5huOK5ONH8rtk
         B/AQ==
X-Forwarded-Encrypted: i=1; AJvYcCVZMbbauBFZmg6AxeTvF30z3sEOlK8XJESSEucBgYW3cUc/Nc6P/okyFi+ur6FBiirenzkquMWv20idlGjLx1O5jMuvOc8N6Oq/WcHG/Oc=
X-Gm-Message-State: AOJu0Yz8RUc58JbX1bPWWHAhSWMuHzSbAaa+XbVqMjDM/cGRFQOgBt6K
	riwPjbXyyIyDaQTYevkrZOXM6MIVFhceYi411fr8e6ibQwa+Y7E1r8ckVb5tH8o=
X-Google-Smtp-Source: AGHT+IFXbYhPHZn5NXBz7Ikr8yC8QHRf+1TONIhT4Hw3waF5CP4z/i4EhLM/5gQv8lw+8vgiP63smA==
X-Received: by 2002:a17:906:714a:b0:a4e:f91:4694 with SMTP id z10-20020a170906714a00b00a4e0f914694mr2568225ejj.27.1711641401851;
        Thu, 28 Mar 2024 08:56:41 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org
Cc: Richard Henderson ,
	Eduardo Habkost ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org,
	Bernhard Beschow ,
	Thomas Huth ,
	Marcel Apfelbaum ,
	"Michael S. Tsirkin" ,
	Paolo Bonzini ,
	Igor Mammedov ,
	Anthony Perard ,
	Ani Sinha ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
Subject: [RFC PATCH-for-9.1 19/29] hw/i386/pc: Pass PcPciMachineState argument to CXL helpers
Date: Thu, 28 Mar 2024 16:54:27 +0100
Message-ID: <20240328155439.58719-20-philmd@linaro.org>
X-Mailer: git-send-email 2.41.0
In-Reply-To: <20240328155439.58719-1-philmd@linaro.org>
References: <20240328155439.58719-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Since CXL helpers expect a PCI-based machine, we
can directly pass them a PcPciMachineState argument.

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/i386/pc.c | 15 +++++++--------
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index e36d76656b..d8e91d18b8 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -705,14 +705,14 @@ static void pc_get_device_memory_range(PCMachineState *pcms,
     *device_mem_size = size;
 }
 
-static uint64_t pc_get_cxl_range_start(PCMachineState *pcms)
+static uint64_t pc_get_cxl_range_start(PcPciMachineState *ppms)
 {
+    PCMachineState *pcms = PC_MACHINE(ppms);
     MachineState *ms = MACHINE(pcms);
     hwaddr cxl_base;
     ram_addr_t size;
 
-    if (has_reserved_memory(pcms) &&
-        (ms->ram_size < ms->maxram_size)) {
+    if ((ms->ram_size < ms->maxram_size)) {
         pc_get_device_memory_range(pcms, &cxl_base, &size);
         cxl_base += size;
     } else {
@@ -722,10 +722,9 @@ static uint64_t pc_get_cxl_range_start(PCMachineState *pcms)
     return cxl_base;
 }
 
-static uint64_t pc_get_cxl_range_end(PCMachineState *pcms)
+static uint64_t pc_get_cxl_range_end(PcPciMachineState *ppms)
 {
-    PcPciMachineState *ppms = PC_PCI_MACHINE(pcms);
-    uint64_t start = pc_get_cxl_range_start(pcms) + MiB;
+    uint64_t start = pc_get_cxl_range_start(ppms) + MiB;
 
     if (ppms->cxl_devices_state.fixed_windows) {
         GList *it;
@@ -937,7 +936,7 @@ void pc_memory_init(PCMachineState *pcms,
         MemoryRegion *mr = &ppms->cxl_devices_state.host_mr;
         hwaddr cxl_size = MiB;
 
-        cxl_base = pc_get_cxl_range_start(pcms);
+        cxl_base = pc_get_cxl_range_start(ppms);
         memory_region_init(mr, OBJECT(machine), "cxl_host_reg", cxl_size);
         memory_region_add_subregion(system_memory, cxl_base, mr);
         cxl_resv_end = cxl_base + cxl_size;
@@ -1027,7 +1026,7 @@ uint64_t pc_pci_hole64_start(void)
     ram_addr_t size = 0;
 
     if (ppms->cxl_devices_state.is_enabled) {
-        hole64_start = pc_get_cxl_range_end(pcms);
+        hole64_start = pc_get_cxl_range_end(ppms);
     } else if (has_reserved_memory(pcms) && (ms->ram_size < ms->maxram_size)) {
         pc_get_device_memory_range(pcms, &hole64_start, &size);
         if (!pcmc->broken_reserved_end) {
-- 
2.41.0



From xen-devel-bounces@lists.xenproject.org Thu Mar 28 16:01:35 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 16:01:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699039.1091557 (Exim 4.92)
	(envelope-from )
	id 1rpsC7-0001BC-7i; Thu, 28 Mar 2024 16:01:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699039.1091557; Thu, 28 Mar 2024 16:01:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpsC7-0001Ae-49; Thu, 28 Mar 2024 16:01:35 +0000
Received: by outflank-mailman (input) for mailman id 699039;
 Thu, 28 Mar 2024 16:01:33 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rps8K-00071m-47
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 15:57:40 +0000
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com
 [2a00:1450:4864:20::52c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e699f142-ed1b-11ee-a1ef-f123f15fe8a2;
 Thu, 28 Mar 2024 16:57:38 +0100 (CET)
Received: by mail-ed1-x52c.google.com with SMTP id
 4fb4d7f45d1cf-56c1922096cso1486560a12.0
 for ; Thu, 28 Mar 2024 08:57:38 -0700 (PDT)
Received: from m1x-phil.lan (pas38-h02-176-184-5-52.dsl.sta.abo.bbox.fr.
 [176.184.5.52]) by smtp.gmail.com with ESMTPSA id
 ek25-20020a056402371900b0056bdc4a5cd6sm959160edb.62.2024.03.28.08.57.35
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Thu, 28 Mar 2024 08:57:37 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e699f142-ed1b-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1711641458; x=1712246258; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=WrzkMtkcnF1yss3niHYQFeUj6lW7JvFYG513ZWQp60s=;
        b=GSd899zuFf6RMLrZBW9cClN548SHoJV4gzuiuGLbyr5ETcg/LtuoXsscBv5UZ4c0Lx
         Fq+P4k8U8pw2MCZ4I/Tn/KSw8wstTDYRpSu5kYobeQZwHySXya47Hxipi7NyqtoN8ciH
         FdyXkEd6faVR6grUZvTDzUN/xH2TuOJu79alVcwfS0PxN2AEqd7zRHptZV93C2w+OHJt
         E8q+eRCXM2LD/6bRhaxV4lDlbBNZQOwWLecUoTCJ6W/4fPGGyMVDGDBkOt1S9wOWDVHc
         gtGt/y2nUVkeQ1+PLQ4ANAyUlDAE9ehodw8uRJiF3zqjg/+XEUAwCmjBW1wm0YAO8hZa
         682A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711641458; x=1712246258;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=WrzkMtkcnF1yss3niHYQFeUj6lW7JvFYG513ZWQp60s=;
        b=sXoS9TbifQk2O7Oc5zlWN+fxX5Cbgx1rvPjCrItsZuJTNmVMh4ryaUzVcFmBZi+DWf
         lx70i0/na+jKAXVDR5XYhTBEEBgMwh6mmPY7TaE1z12W1KW1n1OAqAJYPJEUubsvQbwk
         QhpWGkLYGZeZkSi67Y7cHmzmB8xmyGF3bfGOXbZpsvBprb+6WdYE+F2bI4CWohVGYA0N
         2a5ZN+I172MG/KWsuPOS8Vinwj3fd/klED4I6dqJlM+tYipK1XeJc5zwdVu1TyfLgFWX
         G5g7+dbMTuBiH4GbCTPDXVkto9xhjNcizRpQXDg+ihHO+wzJbdioEFfCfajbfpZKpDG2
         n/aA==
X-Forwarded-Encrypted: i=1; AJvYcCXGg4OBvqyaYVqvzANdh/SLSmRmDKKYVrJ8iSYsL9mm6a7C7nvgAVwR8vjemcUOHVitmUaICQvN7oV/oPCCarQKZOVGeKEbVWV1m2DYBAo=
X-Gm-Message-State: AOJu0YzFAm5b2NKiMHKUFG0J8OUtu571lWH1zjijy8BlOLJcdQYMSYxq
	b6Z60Ys/YSQWy0OeqhDhoPmLf7uoRfVNXx+otV87VWGuvbQBOG6X92yjM+0Gasc=
X-Google-Smtp-Source: AGHT+IEc3JVavZ6Yb+b8wnDqhR3/uKAR+Oeu24avwh9VyWUhM3fQrZfwqOBt+dWLPG1vVVlO5yf/BQ==
X-Received: by 2002:a50:9b0b:0:b0:56b:dce0:c795 with SMTP id o11-20020a509b0b000000b0056bdce0c795mr2044180edi.4.1711641458009;
        Thu, 28 Mar 2024 08:57:38 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org
Cc: Richard Henderson ,
	Eduardo Habkost ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org,
	Bernhard Beschow ,
	Thomas Huth ,
	Marcel Apfelbaum ,
	"Michael S. Tsirkin" ,
	Paolo Bonzini ,
	Igor Mammedov ,
	Anthony Perard ,
	Ani Sinha ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Aurelien Jarno ,
	=?UTF-8?q?Herv=C3=A9=20Poussineau?= 
Subject: [RFC PATCH-for-9.1 28/29] hw/i386/pc: Rename pc_init1() -> pc_piix_init()
Date: Thu, 28 Mar 2024 16:54:36 +0100
Message-ID: <20240328155439.58719-29-philmd@linaro.org>
X-Mailer: git-send-email 2.41.0
In-Reply-To: <20240328155439.58719-1-philmd@linaro.org>
References: <20240328155439.58719-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

pc_init1() is specific to the isapc and i440fx/piix machines,
rename it as pc_piix_init(). Expose it in "hw/i386/pc.h" to
be able to call it externally (see next patch).

Signed-off-by: Philippe Mathieu-Daudé 
---
 include/hw/i386/pc.h | 1 +
 hw/i386/pc_piix.c    | 8 ++++----
 hw/isa/piix.c        | 2 +-
 hw/pci-host/i440fx.c | 2 +-
 4 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 6510914803..9a11835b7e 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -163,6 +163,7 @@ void pc_basic_device_init(struct PCMachineState *pcms,
                           bool create_fdctrl,
                           uint32_t hpet_irqs);
 void pc_nic_init(PCMachineClass *pcmc, ISABus *isa_bus, PCIBus *pci_bus);
+void pc_piix_init(MachineState *machine, const char *pci_type);
 
 void pc_i8259_create(ISABus *isa_bus, qemu_irq *i8259_irqs);
 
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 4f07476cfa..4a3ae72fe4 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -111,7 +111,7 @@ static bool gigabyte_align(PCMachineState *pcms)
 }
 
 /* PC hardware initialisation */
-static void pc_init1(MachineState *machine, const char *pci_type)
+void pc_piix_init(MachineState *machine, const char *pci_type)
 {
     PCMachineState *pcms = PC_MACHINE(machine);
     PCMachineClass *pcmc = PC_MACHINE_GET_CLASS(pcms);
@@ -437,7 +437,7 @@ static void pc_set_south_bridge(Object *obj, int value, Error **errp)
 #ifdef CONFIG_ISAPC
 static void pc_init_isa(MachineState *machine)
 {
-    pc_init1(machine, NULL);
+    pc_piix_init(machine, NULL);
 }
 #endif
 
@@ -447,7 +447,7 @@ static void pc_xen_hvm_init_pci(MachineState *machine)
     const char *pci_type = xen_igd_gfx_pt_enabled() ?
                 TYPE_IGD_PASSTHROUGH_I440FX_PCI_DEVICE : TYPE_I440FX_PCI_DEVICE;
 
-    pc_init1(machine, pci_type);
+    pc_piix_init(machine, pci_type);
 }
 
 static void pc_xen_hvm_init(MachineState *machine)
@@ -472,7 +472,7 @@ static void pc_xen_hvm_init(MachineState *machine)
         if (compat) { \
             compat(machine); \
         } \
-        pc_init1(machine, TYPE_I440FX_PCI_DEVICE); \
+        pc_piix_init(machine, TYPE_I440FX_PCI_DEVICE); \
     } \
     DEFINE_PC_MACHINE(suffix, name, pc_init_##suffix, optionfn, \
                       TYPE_PC_PCI_MACHINE)
diff --git a/hw/isa/piix.c b/hw/isa/piix.c
index 2d30711b17..14dc9e78be 100644
--- a/hw/isa/piix.c
+++ b/hw/isa/piix.c
@@ -432,7 +432,7 @@ static void pci_piix_class_init(ObjectClass *klass, void *data)
     k->class_id     = PCI_CLASS_BRIDGE_ISA;
     /*
      * Reason: part of PIIX southbridge, needs to be wired up by e.g.
-     * pc_piix.c's pc_init1()
+     * pc_piix.c's pc_piix_init()
      */
     dc->user_creatable = false;
     device_class_set_props(dc, pci_piix_props);
diff --git a/hw/pci-host/i440fx.c b/hw/pci-host/i440fx.c
index add99e4f76..9f47d5507a 100644
--- a/hw/pci-host/i440fx.c
+++ b/hw/pci-host/i440fx.c
@@ -374,7 +374,7 @@ static void i440fx_pcihost_class_init(ObjectClass *klass, void *data)
     dc->realize = i440fx_pcihost_realize;
     dc->fw_name = "pci";
     device_class_set_props(dc, i440fx_props);
-    /* Reason: needs to be wired up by pc_init1 */
+    /* Reason: needs to be wired up by pc_piix_init */
     dc->user_creatable = false;
 
     object_class_property_add(klass, PCI_HOST_PROP_PCI_HOLE_START, "uint32",
-- 
2.41.0



From xen-devel-bounces@lists.xenproject.org Thu Mar 28 16:01:44 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 16:01:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699041.1091573 (Exim 4.92)
	(envelope-from )
	id 1rpsCG-0001oJ-Nz; Thu, 28 Mar 2024 16:01:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699041.1091573; Thu, 28 Mar 2024 16:01:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpsCG-0001o9-Kg; Thu, 28 Mar 2024 16:01:44 +0000
Received: by outflank-mailman (input) for mailman id 699041;
 Thu, 28 Mar 2024 16:01:43 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpsCF-0001mY-3Q; Thu, 28 Mar 2024 16:01:43 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpsCF-00067Z-1m; Thu, 28 Mar 2024 16:01:43 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpsCE-0007pI-LF; Thu, 28 Mar 2024 16:01:42 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rpsCE-0005zz-Kj; Thu, 28 Mar 2024 16:01:42 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=F+gMR5dleVNU79Ejoj8lUu9+SESkbP5V2w/Z8S3Bqb0=; b=dr4rDy8WABgG3B9Zu4MvAFdg9I
	9ngpaWrWDnW4NcVBCVt+p++gTeNq8zno6aVfpe5jxfeukbODt0G1A/f8wZFtZkRg+H8BhO9/B7liQ
	/RwZqEEMowoVXL6oCyGi9U6aB6oQhckIPK8z4jO6Ek4tIGr3RzCehLY1wC7OEqfORWn0=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-4.18-testing test] 185172: tolerable FAIL - PUSHED
X-Osstest-Failures:
    xen-4.18-testing:test-amd64-amd64-libvirt-pair:guest-migrate/dst_host/src_host/debian.repeat:fail:heisenbug
    xen-4.18-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-qcow2:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-qcow2:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-libvirt-vhd:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-libvirt-vhd:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-raw:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-raw:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    xen=c9ea3b49a5d546a7c786dd0a0caec00c9c7f2633
X-Osstest-Versions-That:
    xen=ea82c8cdbfe5a6e3bb6071cb71433502e3e565cf
From: osstest service owner 
Date: Thu, 28 Mar 2024 16:01:42 +0000

flight 185172 xen-4.18-testing real [real]
flight 185182 xen-4.18-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/185172/
http://logs.test-lab.xenproject.org/osstest/logs/185182/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-libvirt-pair 28 guest-migrate/dst_host/src_host/debian.repeat fail pass in 185182-retest

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

version targeted for testing:
 xen                  c9ea3b49a5d546a7c786dd0a0caec00c9c7f2633
baseline version:
 xen                  ea82c8cdbfe5a6e3bb6071cb71433502e3e565cf

Last test of basis   185077  2024-03-18 08:37:32 Z   10 days
Testing same since   185172  2024-03-27 11:37:13 Z    1 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-amd64-libvirt-pair                                fail    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-libvirt-qcow2                               pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-xl-qcow2                                    pass    
 test-amd64-amd64-libvirt-raw                                 pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-amd64-amd64-xl-raw                                      pass    
 test-armhf-armhf-xl-raw                                      pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-libvirt-vhd                                 pass    
 test-amd64-amd64-xl-vhd                                      pass    
 test-arm64-arm64-xl-vhd                                      pass    


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

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

Explanation of these 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
   ea82c8cdbf..c9ea3b49a5  c9ea3b49a5d546a7c786dd0a0caec00c9c7f2633 -> stable-4.18


From xen-devel-bounces@lists.xenproject.org Thu Mar 28 16:04:04 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 16:04:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699055.1091583 (Exim 4.92)
	(envelope-from )
	id 1rpsEU-0003b9-6f; Thu, 28 Mar 2024 16:04:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699055.1091583; Thu, 28 Mar 2024 16:04:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpsEU-0003b2-2s; Thu, 28 Mar 2024 16:04:02 +0000
Received: by outflank-mailman (input) for mailman id 699055;
 Thu, 28 Mar 2024 16:04:00 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rps6t-0001AK-OU
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 15:56:11 +0000
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com
 [2a00:1450:4864:20::130])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b2a136c3-ed1b-11ee-afe3-a90da7624cb6;
 Thu, 28 Mar 2024 16:56:11 +0100 (CET)
Received: by mail-lf1-x130.google.com with SMTP id
 2adb3069b0e04-515a81928a1so1638126e87.3
 for ; Thu, 28 Mar 2024 08:56:11 -0700 (PDT)
Received: from m1x-phil.lan (pas38-h02-176-184-5-52.dsl.sta.abo.bbox.fr.
 [176.184.5.52]) by smtp.gmail.com with ESMTPSA id
 ds17-20020a170907725100b00a471b5b25b9sm887001ejc.127.2024.03.28.08.56.09
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Thu, 28 Mar 2024 08:56:10 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b2a136c3-ed1b-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1711641371; x=1712246171; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=tmBHuqnVEd7WMmkqyo1h18jdjcgOKQnVi/P8Phxm0vQ=;
        b=tuUaXOOk88LUv5Qe2yM9SzIt+C6InQHrAD9k2uyB19qrdPBE+Omgzs8YHMqlsDVHc1
         0B+dspuz2X0O4NV1Dz4Gi5prxyize7D96Z5E1fIo1b1ElVZ/78IsHHYxQ79oA7UwRoUy
         QuhgTPcaicgne8WwSKQuMB+4mKBA4/6Ppbfred6/rXrFCIQYtR0SygKmqxCpPCQkoukP
         JxKIqFWWXB8zGZ2c8I9GyzEpSGEEDEqpXSlDUocpcY6uKDXp8l5/09cl/xpGd93KI/gu
         sA9igr5jaWAXZqrmwCeJj6pP+mQuieAflJVsKZH3AhNE2a0e/DEgruWtm+rSdgaL9Zka
         sYWw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711641371; x=1712246171;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=tmBHuqnVEd7WMmkqyo1h18jdjcgOKQnVi/P8Phxm0vQ=;
        b=OW2EkDjna+Xn8HNs1tpValc8I9wQ10SGiG4M3yyff02sSKlSmfMVZbk9z65P9NZ01C
         6vph6W4u+46YBSiD90tnPvfmYhoL4iRamEtYWBokJz9e22iY7Os5rXlfcHCAH4ETj3pe
         EcRLLc0CBFxl843HbAcpd5htYYePhScOPcAudQmwAwTo7L6fUsRKeRMjUnxb7wDX6XWn
         oqpp+0T52FOs6OGTjrAJVkwoJ8kaFOVsRqVxDJv97mMExNil6H4QdWHftBr/aGQmyDne
         a8Et0rZtoP/a5e6mC29dpscJfiVIXZwg/sGuG8vdvNCvb6r5MZ6XYJ0dlb988RMzCahD
         A8jw==
X-Forwarded-Encrypted: i=1; AJvYcCVJBfzx/eScTqkFnqqa9FRIDKJtd6Frqj80T9ZMwvLFtx2/RitV43hqIDkAfqoP6kJOpU0chkViAs2N4+WIuQX+jy4dD+V04hwdBtpLv4g=
X-Gm-Message-State: AOJu0YwTeIyz4rPbK+DXJAtq6QXuEVk33S/2nDXqL7aVl6M/KF6jqj2o
	gqnpBssABOFfAzlfRazSD0GZreOXWClXpljHenDmQnAvZO/Z9Ad716Gdlhfg3PI=
X-Google-Smtp-Source: AGHT+IFUtefnyMETNOsHVcJ8GlW5rJsH0GdNooS/V5PGz6OttTSyM+Vcg71L2tN7ryhsnM23ZMka+w==
X-Received: by 2002:ac2:489c:0:b0:515:af1f:5bad with SMTP id x28-20020ac2489c000000b00515af1f5badmr2600673lfc.28.1711641370819;
        Thu, 28 Mar 2024 08:56:10 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org
Cc: Richard Henderson ,
	Eduardo Habkost ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org,
	Bernhard Beschow ,
	Thomas Huth ,
	Marcel Apfelbaum ,
	"Michael S. Tsirkin" ,
	Paolo Bonzini ,
	Igor Mammedov ,
	Anthony Perard ,
	Ani Sinha ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
Subject: [RFC PATCH-for-9.1 14/29] hw/i386/pc: Move pc_system_flash_create() to pc_pci_machine_initfn()
Date: Thu, 28 Mar 2024 16:54:22 +0100
Message-ID: <20240328155439.58719-15-philmd@linaro.org>
X-Mailer: git-send-email 2.41.0
In-Reply-To: <20240328155439.58719-1-philmd@linaro.org>
References: <20240328155439.58719-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

pc_system_flash_create() is only useful for PCI-based machines.
Move the call to the PCI-based init() handler.

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/i386/pc.c       |  2 +-
 hw/i386/pc_sysfw.c | 10 ++++------
 2 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 5b96daa414..33724791fd 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1679,7 +1679,6 @@ static void pc_machine_initfn(Object *obj)
     pcms->fd_bootchk = true;
     pcms->default_bus_bypass_iommu = false;
 
-    pc_system_flash_create(pcms);
     pcms->pcspk = isa_new(TYPE_PC_SPEAKER);
     object_property_add_alias(OBJECT(pcms), "pcspk-audiodev",
                               OBJECT(pcms->pcspk), "audiodev");
@@ -1694,6 +1693,7 @@ static void pc_pci_machine_initfn(Object *obj)
 
     ppms->acpi_build_enabled = true;
 
+    pc_system_flash_create(PC_MACHINE(obj));
     cxl_machine_init(obj, &ppms->cxl_devices_state);
 
     ppms->machine_done.notify = pc_pci_machine_done;
diff --git a/hw/i386/pc_sysfw.c b/hw/i386/pc_sysfw.c
index 541dcaef71..167ff24fcb 100644
--- a/hw/i386/pc_sysfw.c
+++ b/hw/i386/pc_sysfw.c
@@ -93,12 +93,10 @@ static PFlashCFI01 *pc_pflash_create(PCMachineState *pcms,
 
 void pc_system_flash_create(PCMachineState *pcms)
 {
-    if (pc_machine_is_pci_enabled(pcms)) {
-        pcms->flash[0] = pc_pflash_create(pcms, "system.flash0",
-                                          "pflash0");
-        pcms->flash[1] = pc_pflash_create(pcms, "system.flash1",
-                                          "pflash1");
-    }
+    assert(pc_machine_is_pci_enabled(pcms));
+
+    pcms->flash[0] = pc_pflash_create(pcms, "system.flash0", "pflash0");
+    pcms->flash[1] = pc_pflash_create(pcms, "system.flash1", "pflash1");
 }
 
 void pc_system_flash_cleanup_unused(PCMachineState *pcms)
-- 
2.41.0



From xen-devel-bounces@lists.xenproject.org Thu Mar 28 16:05:33 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 16:05:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699060.1091593 (Exim 4.92)
	(envelope-from )
	id 1rpsFv-0004Im-Fe; Thu, 28 Mar 2024 16:05:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699060.1091593; Thu, 28 Mar 2024 16:05:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpsFv-0004If-Cj; Thu, 28 Mar 2024 16:05:31 +0000
Received: by outflank-mailman (input) for mailman id 699060;
 Thu, 28 Mar 2024 16:05:30 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rps8C-0001AK-ED
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 15:57:32 +0000
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com
 [2a00:1450:4864:20::52b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e2aef80a-ed1b-11ee-afe3-a90da7624cb6;
 Thu, 28 Mar 2024 16:57:31 +0100 (CET)
Received: by mail-ed1-x52b.google.com with SMTP id
 4fb4d7f45d1cf-565c6cf4819so3746426a12.1
 for ; Thu, 28 Mar 2024 08:57:31 -0700 (PDT)
Received: from m1x-phil.lan (pas38-h02-176-184-5-52.dsl.sta.abo.bbox.fr.
 [176.184.5.52]) by smtp.gmail.com with ESMTPSA id
 o19-20020a17090637d300b00a46cc48ab07sm894776ejc.221.2024.03.28.08.57.29
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Thu, 28 Mar 2024 08:57:31 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e2aef80a-ed1b-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1711641451; x=1712246251; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=OhT6+kuDArhB7vl7wmlOYwb5F71/kFsimohZE69/WJ4=;
        b=n+5XDGcQYBjbYVDl0ASQF6LbHmjFNwot3DYVVLcUQ5AKH4cDVyVaq98Yz/D7DN0ry+
         dy+K5++IZbFg5sDgzdckSPlwhD26c5no5pk5+BZXgZIBIcZ72tqJj7tNfAyClCXkJmA5
         ckbxW5PD4Wqa8PCXW5oREgAHbLg5EAM3uhfcQ0Im51gzjWOje88fH3l60zP1F8zh/li2
         8TjUUpfQGcnauwyQpqg8DNL5vPAsWTmCgiIIWQOhN5cf3BguKBGRDeEXSIXOj8a+2b3H
         p3N+dgpr7fKCBLZEmAsyNBPOj3QUn/7ipsgF8u/GZj5uMmEJdJJoFENIdSwhz6tOSLii
         C3bg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711641451; x=1712246251;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=OhT6+kuDArhB7vl7wmlOYwb5F71/kFsimohZE69/WJ4=;
        b=FS1zMk4ydoi6Zcw3HPpoS7CaUoTPFLXC2qHkANTAC/j+LkOeGDyhHJlvNz7uqrrOLA
         l4F4U/G37r3p45erl07sHgzdhRcG0oudRvaMywiOfJwT32WFZReqm30IG/3CX2qQpK9Z
         MgE4cH8gYQXwPXm/bl6iT58Cvn/pKhKhaBvKMJB+SaRNIIxL0CSPuKreNlnJn6DfBD7S
         fdeFP0cYdFpKe+GS7pZ7Mg7duUpsGU5sRMpjOY9IRlSu0/fMPOb60EFbWksNZblfTUri
         ulh1clW+jqXrVgxgXeMfeRCAHphJv38DjG7wS+7O2D80ZjSvb8cmPP2mVlWK38z1rQDJ
         IaIw==
X-Forwarded-Encrypted: i=1; AJvYcCVX6DAji0F8XxKEIgFLovy8hAwsDoWkVCxXlUy6ftsDXA1r5uSu7Uzrnld8WYshqegrfAE/sSxVj93RRnvgxgcmkmEpoGlPJDV4IRc3Tgs=
X-Gm-Message-State: AOJu0YzZkHWc7e7052qNjX5msNvcgF3Bbz67JrCUUVsgYxjFmYXZ9Ck4
	AQnFCA88/huNqCI/Q6F0+MJu8K8ik36O2/OiR3LtV4ebyvsWvtLhLfWgTYTrgEo=
X-Google-Smtp-Source: AGHT+IE5iPw2wKGziuJIAfhXkqj1URHuVnsVTHRuhgnnHINXGtkc2NpEDzBwrK/9AluQ+8R3bvD5jA==
X-Received: by 2002:a17:906:48d7:b0:a45:ab98:aec with SMTP id d23-20020a17090648d700b00a45ab980aecmr2166613ejt.10.1711641451420;
        Thu, 28 Mar 2024 08:57:31 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org
Cc: Richard Henderson ,
	Eduardo Habkost ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org,
	Bernhard Beschow ,
	Thomas Huth ,
	Marcel Apfelbaum ,
	"Michael S. Tsirkin" ,
	Paolo Bonzini ,
	Igor Mammedov ,
	Anthony Perard ,
	Ani Sinha ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
Subject: [RFC PATCH-for-9.1 27/29] hw/i386/pc: Call fw_cfg_build_smbios_legacy() in pc_machine_done()
Date: Thu, 28 Mar 2024 16:54:35 +0100
Message-ID: <20240328155439.58719-28-philmd@linaro.org>
X-Mailer: git-send-email 2.41.0
In-Reply-To: <20240328155439.58719-1-philmd@linaro.org>
References: <20240328155439.58719-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Keep fw_cfg_build_smbios() for PCI-based machines, call
fw_cfg_build_smbios_legacy() directly from pc_machine_done().

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/i386/fw_cfg.c | 10 ----------
 hw/i386/pc.c     | 12 +++++++++++-
 2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/hw/i386/fw_cfg.c b/hw/i386/fw_cfg.c
index be37e28f46..92e058446f 100644
--- a/hw/i386/fw_cfg.c
+++ b/hw/i386/fw_cfg.c
@@ -49,11 +49,6 @@ const char *fw_cfg_arch_key_name(uint16_t key)
 }
 
 #ifdef CONFIG_SMBIOS
-static bool smbios_legacy_mode(PCMachineState *pcms)
-{
-    return !pc_machine_is_pci_enabled(pcms);
-}
-
 void fw_cfg_build_smbios_legacy(PCMachineState *pcms, FWCfgState *fw_cfg)
 {
     uint8_t *smbios_tables;
@@ -81,11 +76,6 @@ void fw_cfg_build_smbios(PCMachineState *pcms, FWCfgState *fw_cfg,
     MachineClass *mc = MACHINE_GET_CLASS(pcms);
     X86CPU *cpu = X86_CPU(ms->possible_cpus->cpus[0].cpu);
 
-    if (smbios_legacy_mode(pcms)) {
-        fw_cfg_build_smbios_legacy(pcms, fw_cfg);
-        return;
-    }
-
     /* These values are guest ABI, do not change */
     smbios_set_defaults("QEMU", mc->desc, mc->name);
 
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 7a758a2e84..7d06a088cf 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -591,6 +591,11 @@ void pc_acpi_smi_interrupt(void *opaque, int irq, int level)
     }
 }
 
+static bool smbios_legacy_mode(PCMachineState *pcms)
+{
+    return !pc_machine_is_pci_enabled(pcms);
+}
+
 static
 void pc_machine_done(Notifier *notifier, void *data)
 {
@@ -602,7 +607,12 @@ void pc_machine_done(Notifier *notifier, void *data)
     x86_rtc_set_cpus_count(x86ms->rtc, x86ms->boot_cpus);
 
     if (x86ms->fw_cfg) {
-        fw_cfg_build_smbios(pcms, x86ms->fw_cfg, pcms->smbios_entry_point_type);
+        if (smbios_legacy_mode(pcms)) {
+            fw_cfg_build_smbios_legacy(pcms, x86ms->fw_cfg);
+        } else {
+            fw_cfg_build_smbios(pcms, x86ms->fw_cfg,
+                                pcms->smbios_entry_point_type);
+        }
         fw_cfg_build_feature_control(MACHINE(pcms), x86ms->fw_cfg);
         /* update FW_CFG_NB_CPUS to account for -device added CPUs */
         fw_cfg_modify_i16(x86ms->fw_cfg, FW_CFG_NB_CPUS, x86ms->boot_cpus);
-- 
2.41.0



From xen-devel-bounces@lists.xenproject.org Thu Mar 28 16:09:00 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 16:09:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699078.1091603 (Exim 4.92)
	(envelope-from )
	id 1rpsJF-0005Gz-1C; Thu, 28 Mar 2024 16:08:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699078.1091603; Thu, 28 Mar 2024 16:08:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpsJE-0005Gs-Uw; Thu, 28 Mar 2024 16:08:56 +0000
Received: by outflank-mailman (input) for mailman id 699078;
 Thu, 28 Mar 2024 16:08:55 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rps7C-0001AK-O7
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 15:56:30 +0000
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com
 [2a00:1450:4864:20::530])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id bdd4fcca-ed1b-11ee-afe3-a90da7624cb6;
 Thu, 28 Mar 2024 16:56:30 +0100 (CET)
Received: by mail-ed1-x530.google.com with SMTP id
 4fb4d7f45d1cf-56c1922096cso1484891a12.0
 for ; Thu, 28 Mar 2024 08:56:30 -0700 (PDT)
Received: from m1x-phil.lan (pas38-h02-176-184-5-52.dsl.sta.abo.bbox.fr.
 [176.184.5.52]) by smtp.gmail.com with ESMTPSA id
 c12-20020a170906170c00b00a47464a6ee4sm907178eje.173.2024.03.28.08.56.27
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Thu, 28 Mar 2024 08:56:29 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: bdd4fcca-ed1b-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1711641389; x=1712246189; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=yelmGOzPahdn50NTFTioUrFj9NGQyALSAi158EJljHU=;
        b=NbVIhU0HE1DDNfS1gj4xjsrTs3iMwsqqeDqC+/QzzgpHEvZIvG8GZiMIIfIphkjnFm
         Rya2O+kOJx23kzvVCriif9OfG506w3YwgEXk5tYLz/KEdDbEyisQsWpxN3x2nDHAQ89B
         sMGCgmXGEb2INgCW8KsJpQWwT3p9vucnQkKcW265I/+INQ9dGsSyiV0q1SyqBq8D0Xgi
         cYnj2ocZNn72St6r0dTAnCTNtgtz5hmXqfVUIaNNMxqjAWIufL7vrYWUeY3aWik1HxcZ
         OJRo0xHnHdU+aC77irQRu3xFGuEfpbc85OSMBGqIeBoo7N/2uH8oOrh7NwnmLZ0bKe2q
         VMvQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711641389; x=1712246189;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=yelmGOzPahdn50NTFTioUrFj9NGQyALSAi158EJljHU=;
        b=L/RJeKm5GInCGI6XdJmsNzIkvCVDojscFigePSvlbJwmk3DSpXy2JRlWT+9EX+vBtj
         KWfeqHCZf8dg2r5FCBklLbE0WLOY28S584NGH7mGRs+pg6tnR9HSUpKITTqCxhvrc3Lg
         59Mv6/QjdEkH0LKaCYKtNfQtGPYTi5RS160SBXihVEKNC3ia1cOYqyX2uWrrQTR+KYZl
         8UAygpYJMU2IC3eiyqtIu9P+QdqIIdLqLoNC5YQEFExUG+x6RMylWmWlxW4DfSNzs0Kr
         hSUH8Mt1DNeUgHsjJGMQqdo9lvxYcKgADcc/mAM4BZ4sVjMLBQWYLjrFq1+I2LO/2c2+
         Q3Hg==
X-Forwarded-Encrypted: i=1; AJvYcCXfwtR/v1keepv9ELyldp4sbYgfe06c4VwLejAD0yqWfe6GbaWdMYfkYF02FoegioUAJkBxiYQY8OJ/U6CrJw9l6gpNQId2aA9+x0IMa/k=
X-Gm-Message-State: AOJu0YwSiyo9IzbLFK7NHb5p2xlNJm5aLmMCqRgZhKq6Tq0KR7XHdgo2
	ZTxlP9UbA1+/bnWWRxHMvQ2S1EoZoQTbUQP1EePrp4i/GZSvpT+qvAXm3QntrCbXjoWoW7wSO4A
	K
X-Google-Smtp-Source: AGHT+IGcQH5U/UKgHXGMsAIRXVS3RWDUx0CNeskq1nCdFHfYMz7G0o34lBWrByXcqIlMAc9p2yI9yQ==
X-Received: by 2002:a17:906:e24e:b0:a4d:fc83:70e1 with SMTP id gq14-20020a170906e24e00b00a4dfc8370e1mr2038052ejb.56.1711641389600;
        Thu, 28 Mar 2024 08:56:29 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org
Cc: Richard Henderson ,
	Eduardo Habkost ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org,
	Bernhard Beschow ,
	Thomas Huth ,
	Marcel Apfelbaum ,
	"Michael S. Tsirkin" ,
	Paolo Bonzini ,
	Igor Mammedov ,
	Anthony Perard ,
	Ani Sinha ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
Subject: [RFC PATCH-for-9.1 17/29] hw/i386/pc: Inline gigabyte_align()
Date: Thu, 28 Mar 2024 16:54:25 +0100
Message-ID: <20240328155439.58719-18-philmd@linaro.org>
X-Mailer: git-send-email 2.41.0
In-Reply-To: <20240328155439.58719-1-philmd@linaro.org>
References: <20240328155439.58719-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

All PCI-based machines have the gigabyte_align field
set to %true. Simplify by using an inlined helper
checking whether the machine is PCI-based or not.

Signed-off-by: Philippe Mathieu-Daudé 
---
 include/hw/i386/pc.h |  9 ---------
 hw/i386/pc.c         |  1 -
 hw/i386/pc_piix.c    | 16 +++++++++++++---
 3 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 2db2aa03d3..758dd5f29b 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -76,14 +76,6 @@ typedef struct PcPciMachineState {
 
 /**
  * PCMachineClass:
- *
- * Compat fields:
- *
- * @gigabyte_align: Make sure that guest addresses aligned at
- *                  1Gbyte boundaries get mapped to host
- *                  addresses aligned at 1Gbyte boundaries. This
- *                  way we can use 1GByte pages in the host.
- *
  */
 typedef struct PCMachineClass {
     X86MachineClass parent_class;
@@ -99,7 +91,6 @@ typedef struct PCMachineClass {
     SmbiosEntryPointType default_smbios_ep_type;
 
     /* RAM / address space compat: */
-    bool gigabyte_align;
     bool has_reserved_memory;
     bool broken_reserved_end;
     bool enforce_amd_1tb_hole;
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index dd44df0470..093a7c35f7 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1752,7 +1752,6 @@ static void pc_machine_class_init(ObjectClass *oc, void *data)
     HotplugHandlerClass *hc = HOTPLUG_HANDLER_CLASS(oc);
 
     pcmc->smbios_defaults = true;
-    pcmc->gigabyte_align = true;
     pcmc->has_reserved_memory = true;
     pcmc->enforce_amd_1tb_hole = true;
     pcmc->pvh_enabled = true;
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 2043a7022a..0bc14da768 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -99,6 +99,17 @@ static void piix_intx_routing_notifier_xen(PCIDevice *dev)
     }
 }
 
+/*
+ * gigabyte_align: Make sure that guest addresses aligned at
+ *                 1Gbyte boundaries get mapped to host
+ *                 addresses aligned at 1Gbyte boundaries.
+ *                 This way we can use 1GByte pages in the host.
+ */
+static bool gigabyte_align(PCMachineState *pcms)
+{
+    return pc_machine_is_pci_enabled(pcms);
+}
+
 /* PC hardware initialisation */
 static void pc_init1(MachineState *machine, const char *pci_type)
 {
@@ -130,7 +141,7 @@ static void pc_init1(MachineState *machine, const char *pci_type)
      *  - Then, to gigabyte align the memory, we move the split to 3G
      *    (lowmem = 0xc0000000).  But only in case we have to split in
      *    the first place, i.e. ram_size is larger than (traditional)
-     *    lowmem.  And for new machine types (gigabyte_align = true)
+     *    lowmem.  And for new machine types (gigabyte_align() = true)
      *    only, for live migration compatibility reasons.
      *
      *  - Next the max-ram-below-4g option was added, which allowed to
@@ -160,7 +171,7 @@ static void pc_init1(MachineState *machine, const char *pci_type)
         }
         lowmem = pcms->max_ram_below_4g;
         if (machine->ram_size >= pcms->max_ram_below_4g) {
-            if (pcmc->gigabyte_align) {
+            if (gigabyte_align(pcms)) {
                 if (lowmem > 0xc0000000) {
                     lowmem = 0xc0000000;
                 }
@@ -818,7 +829,6 @@ static void isapc_machine_options(MachineClass *m)
     m->option_rom_has_mr = true;
     m->rom_file_has_mr = false;
     pcmc->smbios_defaults = false;
-    pcmc->gigabyte_align = false;
     pcmc->smbios_legacy_mode = true;
     pcmc->has_reserved_memory = false;
     m->default_nic = "ne2k_isa";
-- 
2.41.0



From xen-devel-bounces@lists.xenproject.org Thu Mar 28 16:09:38 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 16:09:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699081.1091612 (Exim 4.92)
	(envelope-from )
	id 1rpsJu-0005qD-8u; Thu, 28 Mar 2024 16:09:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699081.1091612; Thu, 28 Mar 2024 16:09:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpsJu-0005q6-6J; Thu, 28 Mar 2024 16:09:38 +0000
Received: by outflank-mailman (input) for mailman id 699081;
 Thu, 28 Mar 2024 16:09:36 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rps7t-0001AK-RP
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 15:57:13 +0000
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com
 [2a00:1450:4864:20::229])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d79ff39e-ed1b-11ee-afe3-a90da7624cb6;
 Thu, 28 Mar 2024 16:57:13 +0100 (CET)
Received: by mail-lj1-x229.google.com with SMTP id
 38308e7fff4ca-2d485886545so17750501fa.2
 for ; Thu, 28 Mar 2024 08:57:13 -0700 (PDT)
Received: from m1x-phil.lan (pas38-h02-176-184-5-52.dsl.sta.abo.bbox.fr.
 [176.184.5.52]) by smtp.gmail.com with ESMTPSA id
 lh23-20020a170906f8d700b00a46ab5aaffcsm898765ejb.178.2024.03.28.08.57.11
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Thu, 28 Mar 2024 08:57:12 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d79ff39e-ed1b-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1711641433; x=1712246233; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Jd0AyxLTXxReg2ZsCl/5FvAkstq2JBvxx9RU6rO30AU=;
        b=OcRZeKwc5MAFrMjXvdeEeYyW5w79qP/SrZQlhZUXnYIuFhKrbRm1BkkR1TMsHtlqfL
         9clYB9IQxvJsHjcpBgRd26Cv5BPzgNbCjb48zDVZZcvix0wrRtWnH8XmEWSMgmmw/p3u
         TdVnPbrx+xJVDJHzuf79mYPxXboEDcSr/DYOgvCVPGsbihlgKwPuTi8308WYy1ptA358
         HLHeduXayJzVXlqcYIGfGwaz1XTdeOo1hKFWYdlTfqLqW5JYI1Wl1iNsygKHObIuijEG
         xjt2eof+n0Dxw3UayP6q5Pxb/VEy8mM7lukfy31RyuNQzaQrtcRzw7omLdGJfx4MAUcs
         nu6A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711641433; x=1712246233;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=Jd0AyxLTXxReg2ZsCl/5FvAkstq2JBvxx9RU6rO30AU=;
        b=cV+mnpKPhW3T2JQRoeQDvrew9UJ5Azol4xoX0DS+uXrrIsLAeZ/TJi5n2jUPNXTBBm
         Rrnv3dzhPXqrjUgS02b47RuZQFxPgubqQuGGgKsGsmj4Y1I6acNRTMfpbwfKkSiGLf7Y
         HEYUP2nWr5xmi6N4RGJgcvdQHI3aOA4RJSMOZxfgDxH3huR0IDCc980ygF2Psnt5AI/z
         fq0w/JKNiDA3l8smijA7TYL9b9t1TgVbd/19XgKHiICePyNArj0Kuzm99XAu6hqbZCRu
         OtTWGpNBqlzJGnd1NMKZnnCx0IKCzpxA9ym3+Zn1dn3YpO14k8D7FIRZi4rkhoc4hvVb
         DFDg==
X-Forwarded-Encrypted: i=1; AJvYcCXAOVhkwWZ+fhYE7fzPWKSvWOHFcuxFKQ+jLT3c+Sh5n6Mh/hVHb8OLQOvOC3+jj7nRQsRnc1Fd5OWdnibq8b5SmLcrXDsuxSS7YSxnWRg=
X-Gm-Message-State: AOJu0YwkLSp2tTyLgOX2pJy5dCjvijDMekg9bsncpjvASmDcC7DLWbvK
	wsY0pmJduB/0WZye9Q88s8BG3WCKqa/jpenkJ/2vgvqKi7Uphp6C+T8PINpbxVQ=
X-Google-Smtp-Source: AGHT+IFp7sCXvlR7d3Mf8BzIjVT/t0rldZPHgrIbP67RUd/bNvgi6xSgjnnhBTrJNCeF2G5tN//CLg==
X-Received: by 2002:a2e:a289:0:b0:2d3:5020:17e5 with SMTP id k9-20020a2ea289000000b002d3502017e5mr3152074lja.36.1711641432888;
        Thu, 28 Mar 2024 08:57:12 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org
Cc: Richard Henderson ,
	Eduardo Habkost ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org,
	Bernhard Beschow ,
	Thomas Huth ,
	Marcel Apfelbaum ,
	"Michael S. Tsirkin" ,
	Paolo Bonzini ,
	Igor Mammedov ,
	Anthony Perard ,
	Ani Sinha ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
Subject: [RFC PATCH-for-9.1 24/29] hw/i386/fw_cfg: Inline smbios_legacy_mode()
Date: Thu, 28 Mar 2024 16:54:32 +0100
Message-ID: <20240328155439.58719-25-philmd@linaro.org>
X-Mailer: git-send-email 2.41.0
In-Reply-To: <20240328155439.58719-1-philmd@linaro.org>
References: <20240328155439.58719-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

All PCI-based machines have the smbios_legacy_mode
field set to %false. Simplify by using an inlined
helper checking whether the machine is PCI-based or
not.

Signed-off-by: Philippe Mathieu-Daudé 
---
 include/hw/i386/pc.h | 1 -
 hw/i386/fw_cfg.c     | 8 ++++++--
 hw/i386/pc_piix.c    | 2 --
 3 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 6a6a8df005..6510914803 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -86,7 +86,6 @@ typedef struct PCMachineClass {
     int default_cpu_version;
 
     /* SMBIOS compat: */
-    bool smbios_legacy_mode;
     SmbiosEntryPointType default_smbios_ep_type;
 
     /* RAM / address space compat: */
diff --git a/hw/i386/fw_cfg.c b/hw/i386/fw_cfg.c
index f60390ed56..ffa60a4a33 100644
--- a/hw/i386/fw_cfg.c
+++ b/hw/i386/fw_cfg.c
@@ -54,6 +54,11 @@ static bool smbios_defaults(PCMachineState *pcms)
     return pc_machine_is_pci_enabled(pcms);
 }
 
+static bool smbios_legacy_mode(PCMachineState *pcms)
+{
+    return !pc_machine_is_pci_enabled(pcms);
+}
+
 void fw_cfg_build_smbios(PCMachineState *pcms, FWCfgState *fw_cfg,
                          SmbiosEntryPointType ep_type)
 {
@@ -62,7 +67,6 @@ void fw_cfg_build_smbios(PCMachineState *pcms, FWCfgState *fw_cfg,
     struct smbios_phys_mem_area *mem_array;
     unsigned i, array_count;
     MachineState *ms = MACHINE(pcms);
-    PCMachineClass *pcmc = PC_MACHINE_GET_CLASS(pcms);
     MachineClass *mc = MACHINE_GET_CLASS(pcms);
     X86CPU *cpu = X86_CPU(ms->possible_cpus->cpus[0].cpu);
 
@@ -74,7 +78,7 @@ void fw_cfg_build_smbios(PCMachineState *pcms, FWCfgState *fw_cfg,
     /* tell smbios about cpuid version and features */
     smbios_set_cpuid(cpu->env.cpuid_version, cpu->env.features[FEAT_1_EDX]);
 
-    if (pcmc->smbios_legacy_mode) {
+    if (smbios_legacy_mode(pcms)) {
         smbios_tables = smbios_get_table_legacy(&smbios_tables_len,
                                                 &error_fatal);
         fw_cfg_add_bytes(fw_cfg, FW_CFG_SMBIOS_ENTRIES,
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 70dc8686f9..4f07476cfa 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -823,12 +823,10 @@ DEFINE_I440FX_MACHINE(v2_4, "pc-i440fx-2.4", NULL,
 #ifdef CONFIG_ISAPC
 static void isapc_machine_options(MachineClass *m)
 {
-    PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
     m->desc = "ISA-only PC";
     m->max_cpus = 1;
     m->option_rom_has_mr = true;
     m->rom_file_has_mr = false;
-    pcmc->smbios_legacy_mode = true;
     m->default_nic = "ne2k_isa";
     m->default_cpu_type = X86_CPU_TYPE_NAME("486");
     m->no_parallel = !module_object_class_by_name(TYPE_ISA_PARALLEL);
-- 
2.41.0



From xen-devel-bounces@lists.xenproject.org Thu Mar 28 16:10:20 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 16:10:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699083.1091623 (Exim 4.92)
	(envelope-from )
	id 1rpsKY-0007HI-HB; Thu, 28 Mar 2024 16:10:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699083.1091623; Thu, 28 Mar 2024 16:10:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpsKY-0007HB-E2; Thu, 28 Mar 2024 16:10:18 +0000
Received: by outflank-mailman (input) for mailman id 699083;
 Thu, 28 Mar 2024 16:10:17 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rps70-0001AK-Ev
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 15:56:18 +0000
Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com
 [2a00:1450:4864:20::129])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b668fd9e-ed1b-11ee-afe3-a90da7624cb6;
 Thu, 28 Mar 2024 16:56:17 +0100 (CET)
Received: by mail-lf1-x129.google.com with SMTP id
 2adb3069b0e04-513ccc70a6dso1820969e87.1
 for ; Thu, 28 Mar 2024 08:56:17 -0700 (PDT)
Received: from m1x-phil.lan (pas38-h02-176-184-5-52.dsl.sta.abo.bbox.fr.
 [176.184.5.52]) by smtp.gmail.com with ESMTPSA id
 z1-20020a170906668100b00a474b7bbc76sm886773ejo.56.2024.03.28.08.56.15
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Thu, 28 Mar 2024 08:56:16 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b668fd9e-ed1b-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1711641377; x=1712246177; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=a1jNCFtYZSmUOBchzYP/5PRkNu6FHAH8wzcx932FlSY=;
        b=EnaYBR8QzWipKM3eSIDrpfuOaiM8XXi6t/yfp5CwmfQmz0eRBAb+c+F9aaZGDPChM3
         s+WJBI5fmM/UsErX487wD4t04BKZF2JriYLmcwEq6Qv8vvCsgjXp95GOvum9SFNp6HN+
         wHZh6sLN9cERnHueMgL/sVCwcRVGmMX1rP/KijDjjkz6ZzdzzYvLKgTC2DZAOL3ozqTE
         kXbuiVdGiOIjg+D7n8wUW4iSa8nfJvcsC8uq/KU3jeEa9WPSAl8eHoEw/DqQweplx/N6
         b5kANDtPnfczJq0Zwa5I+gjp3KuHCxqTB/QgX8pFdf9xIxHa7uHs9ubiELehG00L3TkJ
         aqug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711641377; x=1712246177;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=a1jNCFtYZSmUOBchzYP/5PRkNu6FHAH8wzcx932FlSY=;
        b=I+E8ZEd7ZwpVY92fHDRtTEvQkXgEPKTwoBeW3GsAMnoNMfpv5mDEySfP9b3rA8Rxco
         FLmF4MaA3zeUmERn/MeKyPDASMMq1hXZUcHWpfIawon6BKTaKTexpgsnXe4WihwIiFIi
         ZywW+p26XQgmb+jEih3Y6wJd1SAR3Flma128wZfTaz3dHzualQojpRfINUEtxmVouLGU
         Slx4Lq5Q057OtJsyCXMy0ZwOIXecKuB2FmeZTgCEhFfkDKe8HFzRMcax3Hw7POR4nOnL
         fuReGtRI+klbtRDvDVuZW9XddNQu7jUyPjsmiIX32wBFkVoKJJc3+kdxny3n0lprZZ6N
         YyFg==
X-Forwarded-Encrypted: i=1; AJvYcCUA3r2OnEEmUQB7bkym5uN2z0aLyC6uNUVbZxrHaouoTfhRoqEeWPitmGnJkFIeQEecfehagz56LJDiXeZtWFB6ClZrV5enV4uVrwHCm9M=
X-Gm-Message-State: AOJu0YxIfYNxrb1DsBADCZJl/llhPi71Fer28/g7SOhiZwOaFjWBMsEV
	cBj8/IWtezdhtvKDuheLc7r2boVCcmd2yz+Do2tM91Nf6MMeMBxqqWznA3i/zQk=
X-Google-Smtp-Source: AGHT+IHXj5Yz165xDmy5t4NF8sNvW6bTjTmkAtHF7KcewPKZsVQV788UJXIfXnYu/c9dgv0TxzoB4g==
X-Received: by 2002:a05:6512:110a:b0:515:c882:c44a with SMTP id l10-20020a056512110a00b00515c882c44amr2329607lfg.39.1711641377096;
        Thu, 28 Mar 2024 08:56:17 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org
Cc: Richard Henderson ,
	Eduardo Habkost ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org,
	Bernhard Beschow ,
	Thomas Huth ,
	Marcel Apfelbaum ,
	"Michael S. Tsirkin" ,
	Paolo Bonzini ,
	Igor Mammedov ,
	Anthony Perard ,
	Ani Sinha ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
Subject: [RFC PATCH-for-9.1 15/29] hw/i386/pc: Move FW/pflash related fields to PcPciMachineState
Date: Thu, 28 Mar 2024 16:54:23 +0100
Message-ID: <20240328155439.58719-16-philmd@linaro.org>
X-Mailer: git-send-email 2.41.0
In-Reply-To: <20240328155439.58719-1-philmd@linaro.org>
References: <20240328155439.58719-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Only PCI-based machines use the set of parallel flash devices.
Move the fields from PCMachineState to PcPciMachineState.
Directly pass a PcPciMachineState argument to the
pc_system_flash/fw methods.

Signed-off-by: Philippe Mathieu-Daudé 
---
 include/hw/i386/pc.h | 10 ++++----
 hw/i386/pc.c         | 25 +++++++++---------
 hw/i386/pc_piix.c    |  3 ++-
 hw/i386/pc_sysfw.c   | 60 +++++++++++++++++++-------------------------
 4 files changed, 45 insertions(+), 53 deletions(-)

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 67f8f4730b..668347c248 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -30,7 +30,6 @@ typedef struct PCMachineState {
     /* Pointers to devices and objects: */
     PCIBus *pcibus;
     I2CBus *smbus;
-    PFlashCFI01 *flash[2];
     ISADevice *pcspk;
     DeviceState *iommu;
     BusState *idebus[MAX_IDE_BUS];
@@ -47,7 +46,6 @@ typedef struct PCMachineState {
     bool i8042_enabled;
     bool default_bus_bypass_iommu;
     bool fd_bootchk;
-    uint64_t max_fw_size;
 
     /* ACPI Memory hotplug IO base address */
     hwaddr memhp_io_base;
@@ -61,7 +59,9 @@ typedef struct PcPciMachineState {
     Notifier machine_done;
 
     bool acpi_build_enabled;
+    uint64_t max_fw_size;
 
+    PFlashCFI01 *flash[2];
     CXLState cxl_devices_state;
 } PcPciMachineState;
 
@@ -184,9 +184,9 @@ void pc_i8259_create(ISABus *isa_bus, qemu_irq *i8259_irqs);
 #define TYPE_PORT92 "port92"
 
 /* pc_sysfw.c */
-void pc_system_flash_create(PCMachineState *pcms);
-void pc_system_flash_cleanup_unused(PCMachineState *pcms);
-void pc_system_firmware_init(PCMachineState *pcms, MemoryRegion *rom_memory);
+void pc_system_flash_create(PcPciMachineState *ppms);
+void pc_system_flash_cleanup_unused(PcPciMachineState *ppms);
+void pc_system_firmware_init(PcPciMachineState *ppms, MemoryRegion *rom_memory);
 bool pc_system_ovmf_table_find(const char *entry, uint8_t **data,
                                int *data_len);
 void pc_system_parse_ovmf_flash(uint8_t *flash_ptr, size_t flash_size);
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 33724791fd..5753a3ff0b 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -957,7 +957,7 @@ void pc_memory_init(PCMachineState *pcms,
 
     /* Initialize PC system firmware */
     if (pci_enabled) {
-        pc_system_firmware_init(pcms, rom_memory);
+        pc_system_firmware_init(ppms, rom_memory);
     } else {
         x86_bios_rom_init(machine, "bios.bin", rom_memory, true);
     }
@@ -1617,8 +1617,8 @@ static void pc_machine_get_max_fw_size(Object *obj, Visitor *v,
                                        const char *name, void *opaque,
                                        Error **errp)
 {
-    PCMachineState *pcms = PC_MACHINE(obj);
-    uint64_t value = pcms->max_fw_size;
+    PcPciMachineState *ppms = PC_PCI_MACHINE(obj);
+    uint64_t value = ppms->max_fw_size;
 
     visit_type_size(v, name, &value, errp);
 }
@@ -1627,7 +1627,7 @@ static void pc_machine_set_max_fw_size(Object *obj, Visitor *v,
                                        const char *name, void *opaque,
                                        Error **errp)
 {
-    PCMachineState *pcms = PC_MACHINE(obj);
+    PcPciMachineState *ppms = PC_PCI_MACHINE(obj);
     uint64_t value;
 
     if (!visit_type_size(v, name, &value, errp)) {
@@ -1651,7 +1651,7 @@ static void pc_machine_set_max_fw_size(Object *obj, Visitor *v,
         return;
     }
 
-    pcms->max_fw_size = value;
+    ppms->max_fw_size = value;
 }
 
 
@@ -1672,7 +1672,6 @@ static void pc_machine_initfn(Object *obj)
     pcms->smbus_enabled = true;
     pcms->sata_enabled = true;
     pcms->i8042_enabled = true;
-    pcms->max_fw_size = 8 * MiB;
 #ifdef CONFIG_HPET
     pcms->hpet_enabled = true;
 #endif
@@ -1692,8 +1691,9 @@ static void pc_pci_machine_initfn(Object *obj)
     PcPciMachineState *ppms = PC_PCI_MACHINE(obj);
 
     ppms->acpi_build_enabled = true;
+    ppms->max_fw_size = 8 * MiB;
 
-    pc_system_flash_create(PC_MACHINE(obj));
+    pc_system_flash_create(ppms);
     cxl_machine_init(obj, &ppms->cxl_devices_state);
 
     ppms->machine_done.notify = pc_pci_machine_done;
@@ -1815,12 +1815,6 @@ static void pc_machine_class_init(ObjectClass *oc, void *data)
         pc_machine_get_default_bus_bypass_iommu,
         pc_machine_set_default_bus_bypass_iommu);
 
-    object_class_property_add(oc, PC_MACHINE_MAX_FW_SIZE, "size",
-        pc_machine_get_max_fw_size, pc_machine_set_max_fw_size,
-        NULL, NULL);
-    object_class_property_set_description(oc, PC_MACHINE_MAX_FW_SIZE,
-        "Maximum combined firmware size");
-
     object_class_property_add(oc, PC_MACHINE_SMBIOS_EP, "str",
         pc_machine_get_smbios_ep, pc_machine_set_smbios_ep,
         NULL, NULL);
@@ -1834,6 +1828,11 @@ static void pc_machine_class_init(ObjectClass *oc, void *data)
 
 static void pc_pci_machine_class_init(ObjectClass *oc, void *data)
 {
+    object_class_property_add(oc, PC_MACHINE_MAX_FW_SIZE, "size",
+                              pc_machine_get_max_fw_size,
+                              pc_machine_set_max_fw_size, NULL, NULL);
+    object_class_property_set_description(oc, PC_MACHINE_MAX_FW_SIZE,
+                                          "Maximum combined firmware size");
 }
 
 bool pc_machine_is_pci_enabled(PCMachineState *pcms)
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 7aa2598e10..6b3403d0bd 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -118,6 +118,7 @@ static void pc_init1(MachineState *machine, const char *pci_type)
     ram_addr_t lowmem;
     uint64_t hole64_size = 0;
     bool pci_enabled = pc_machine_is_pci_enabled(pcms);
+    PcPciMachineState *ppms = pci_enabled ? PC_PCI_MACHINE(pcms) : NULL;
 
     /*
      * Calculate ram split, for memory below and above 4G.  It's a bit
@@ -228,7 +229,7 @@ static void pc_init1(MachineState *machine, const char *pci_type)
         assert(machine->ram_size == x86ms->below_4g_mem_size +
                                     x86ms->above_4g_mem_size);
 
-        pc_system_flash_cleanup_unused(pcms);
+        pc_system_flash_cleanup_unused(ppms);
         if (machine->kernel_filename != NULL) {
             /* For xen HVM direct kernel boot, load linux here */
             xen_load_linux(pcms);
diff --git a/hw/i386/pc_sysfw.c b/hw/i386/pc_sysfw.c
index 167ff24fcb..54d15afa49 100644
--- a/hw/i386/pc_sysfw.c
+++ b/hw/i386/pc_sysfw.c
@@ -71,7 +71,7 @@ static void pc_isa_bios_init(MemoryRegion *rom_memory,
     memory_region_set_readonly(isa_bios, true);
 }
 
-static PFlashCFI01 *pc_pflash_create(PCMachineState *pcms,
+static PFlashCFI01 *pc_pflash_create(PcPciMachineState *ppms,
                                      const char *name,
                                      const char *alias_prop_name)
 {
@@ -80,8 +80,8 @@ static PFlashCFI01 *pc_pflash_create(PCMachineState *pcms,
     qdev_prop_set_uint64(dev, "sector-length", FLASH_SECTOR_SIZE);
     qdev_prop_set_uint8(dev, "width", 1);
     qdev_prop_set_string(dev, "name", name);
-    object_property_add_child(OBJECT(pcms), name, OBJECT(dev));
-    object_property_add_alias(OBJECT(pcms), alias_prop_name,
+    object_property_add_child(OBJECT(ppms), name, OBJECT(dev));
+    object_property_add_alias(OBJECT(ppms), alias_prop_name,
                               OBJECT(dev), "drive");
     /*
      * The returned reference is tied to the child property and
@@ -91,28 +91,24 @@ static PFlashCFI01 *pc_pflash_create(PCMachineState *pcms,
     return PFLASH_CFI01(dev);
 }
 
-void pc_system_flash_create(PCMachineState *pcms)
+void pc_system_flash_create(PcPciMachineState *ppms)
 {
-    assert(pc_machine_is_pci_enabled(pcms));
-
-    pcms->flash[0] = pc_pflash_create(pcms, "system.flash0", "pflash0");
-    pcms->flash[1] = pc_pflash_create(pcms, "system.flash1", "pflash1");
+    ppms->flash[0] = pc_pflash_create(ppms, "system.flash0", "pflash0");
+    ppms->flash[1] = pc_pflash_create(ppms, "system.flash1", "pflash1");
 }
 
-void pc_system_flash_cleanup_unused(PCMachineState *pcms)
+void pc_system_flash_cleanup_unused(PcPciMachineState *ppms)
 {
     char *prop_name;
     int i;
 
-    assert(pc_machine_is_pci_enabled(pcms));
-
-    for (i = 0; i < ARRAY_SIZE(pcms->flash); i++) {
-        if (!qdev_is_realized(DEVICE(pcms->flash[i]))) {
+    for (i = 0; i < ARRAY_SIZE(ppms->flash); i++) {
+        if (!qdev_is_realized(DEVICE(ppms->flash[i]))) {
             prop_name = g_strdup_printf("pflash%d", i);
-            object_property_del(OBJECT(pcms), prop_name);
+            object_property_del(OBJECT(ppms), prop_name);
             g_free(prop_name);
-            object_unparent(OBJECT(pcms->flash[i]));
-            pcms->flash[i] = NULL;
+            object_unparent(OBJECT(ppms->flash[i]));
+            ppms->flash[i] = NULL;
         }
     }
 }
@@ -130,7 +126,7 @@ void pc_system_flash_cleanup_unused(PCMachineState *pcms)
  * pc_isa_bios_init().  Merging several flash devices for isa-bios is
  * not supported.
  */
-static void pc_system_flash_map(PCMachineState *pcms,
+static void pc_system_flash_map(PcPciMachineState *ppms,
                                 MemoryRegion *rom_memory)
 {
     hwaddr total_size = 0;
@@ -142,10 +138,8 @@ static void pc_system_flash_map(PCMachineState *pcms,
     void *flash_ptr;
     int flash_size;
 
-    assert(pc_machine_is_pci_enabled(pcms));
-
-    for (i = 0; i < ARRAY_SIZE(pcms->flash); i++) {
-        system_flash = pcms->flash[i];
+    for (i = 0; i < ARRAY_SIZE(ppms->flash); i++) {
+        system_flash = ppms->flash[i];
         blk = pflash_cfi01_get_blk(system_flash);
         if (!blk) {
             break;
@@ -166,10 +160,10 @@ static void pc_system_flash_map(PCMachineState *pcms,
         }
         if ((hwaddr)size != size
             || total_size > HWADDR_MAX - size
-            || total_size + size > pcms->max_fw_size) {
+            || total_size + size > ppms->max_fw_size) {
             error_report("combined size of system firmware exceeds "
                          "%" PRIu64 " bytes",
-                         pcms->max_fw_size);
+                         ppms->max_fw_size);
             exit(1);
         }
 
@@ -194,23 +188,21 @@ static void pc_system_flash_map(PCMachineState *pcms,
     }
 }
 
-void pc_system_firmware_init(PCMachineState *pcms,
+void pc_system_firmware_init(PcPciMachineState *ppms,
                              MemoryRegion *rom_memory)
 {
     int i;
-    BlockBackend *pflash_blk[ARRAY_SIZE(pcms->flash)];
-
-    assert(pc_machine_is_pci_enabled(pcms));
+    BlockBackend *pflash_blk[ARRAY_SIZE(ppms->flash)];
 
     /* Map legacy -drive if=pflash to machine properties */
-    for (i = 0; i < ARRAY_SIZE(pcms->flash); i++) {
-        pflash_cfi01_legacy_drive(pcms->flash[i],
+    for (i = 0; i < ARRAY_SIZE(ppms->flash); i++) {
+        pflash_cfi01_legacy_drive(ppms->flash[i],
                                   drive_get(IF_PFLASH, 0, i));
-        pflash_blk[i] = pflash_cfi01_get_blk(pcms->flash[i]);
+        pflash_blk[i] = pflash_cfi01_get_blk(ppms->flash[i]);
     }
 
     /* Reject gaps */
-    for (i = 1; i < ARRAY_SIZE(pcms->flash); i++) {
+    for (i = 1; i < ARRAY_SIZE(ppms->flash); i++) {
         if (pflash_blk[i] && !pflash_blk[i - 1]) {
             error_report("pflash%d requires pflash%d", i, i - 1);
             exit(1);
@@ -219,7 +211,7 @@ void pc_system_firmware_init(PCMachineState *pcms,
 
     if (!pflash_blk[0]) {
         /* Machine property pflash0 not set, use ROM mode */
-        x86_bios_rom_init(MACHINE(pcms), "bios.bin", rom_memory, false);
+        x86_bios_rom_init(MACHINE(ppms), "bios.bin", rom_memory, false);
     } else {
         if (kvm_enabled() && !kvm_readonly_mem_enabled()) {
             /*
@@ -231,10 +223,10 @@ void pc_system_firmware_init(PCMachineState *pcms,
             exit(1);
         }
 
-        pc_system_flash_map(pcms, rom_memory);
+        pc_system_flash_map(ppms, rom_memory);
     }
 
-    pc_system_flash_cleanup_unused(pcms);
+    pc_system_flash_cleanup_unused(ppms);
 }
 
 void x86_firmware_configure(void *ptr, int size)
-- 
2.41.0



From xen-devel-bounces@lists.xenproject.org Thu Mar 28 16:11:26 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 16:11:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699087.1091633 (Exim 4.92)
	(envelope-from )
	id 1rpsLb-00084Y-VI; Thu, 28 Mar 2024 16:11:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699087.1091633; Thu, 28 Mar 2024 16:11:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpsLb-00084R-Rd; Thu, 28 Mar 2024 16:11:23 +0000
Received: by outflank-mailman (input) for mailman id 699087;
 Thu, 28 Mar 2024 16:11:23 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rps7i-00071m-FZ
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 15:57:02 +0000
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com
 [2a00:1450:4864:20::630])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d0226048-ed1b-11ee-a1ef-f123f15fe8a2;
 Thu, 28 Mar 2024 16:57:00 +0100 (CET)
Received: by mail-ej1-x630.google.com with SMTP id
 a640c23a62f3a-a4a3a5e47baso151644966b.2
 for ; Thu, 28 Mar 2024 08:57:00 -0700 (PDT)
Received: from m1x-phil.lan (pas38-h02-176-184-5-52.dsl.sta.abo.bbox.fr.
 [176.184.5.52]) by smtp.gmail.com with ESMTPSA id
 c7-20020a170906340700b00a468bf8586bsm906768ejb.174.2024.03.28.08.56.58
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Thu, 28 Mar 2024 08:57:00 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d0226048-ed1b-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1711641420; x=1712246220; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=EBrGlAtp7IiqJxUt6Mnv7AOEnMWPJd0FVBqTzh3q09E=;
        b=fTbQNm9sC7hP8TvZo64yoh7W9+gUa+lbBeORV82mRt3yUz/o/duVFycfCZ1f6Wj6nB
         7V/Ald3tAKZudYvMf22AUcTS03diJ8pL17CEZ2rhr+Dy+mj6jtKToBHnj7ZXcn3T/M0x
         aftZNNVLh3h3fYF/YWvT4Hvd5UpefSfJMxvTDZIenokHCNpCbf+CSFgsWgqQnnstY7db
         OeqCQqucYsHxo1wJPnhliZ+bil3zOnf2OstRHXYQslpkF2ev4/RlHr8ziopGAgSuvUjo
         FllNj19qYKn+1jRDIqZr38fF/mlovjfWuGdf4DFfE0YJC+toLQWFeUPXYa5d1IZ1bztP
         +oAw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711641420; x=1712246220;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=EBrGlAtp7IiqJxUt6Mnv7AOEnMWPJd0FVBqTzh3q09E=;
        b=ubpx2/goAZ6eY9QA6RsZmdEQPTsORe97V3KDyAdIxSsboJ/91E8DCyk5UBQM2jl1dI
         kjHQpbGctMFIc4XuFHk5ftDmqZlh1GrTPlmYmdHNYHn13ZwgTfb3hS+IYwAx7BdpjKpe
         R9cmyCe1C2SDmYNlI4x1jXYnC13Z/KI05IognC2K0H+BePNIQjNrFRgp7+KolrZTeorI
         g7IbzjEH84r5by2aOtLeeBods1fVMLOIdP+y8CrvFjggt+wjZcpkLYJX48BjM7ZSrV6w
         swmz9UYlHEnYnygpF/pFJG9B8boU8lEj6TU7NfY40c8S1MsGQhY/T2gAsx0Uo7DGR9SK
         nj8A==
X-Forwarded-Encrypted: i=1; AJvYcCXweWtMCP5oXfAqCvJ1NyZ1+VRR3KaQOgUiQMHYtE8MIobwr4pAKmmNj3QRurUauIzT2QZeuA42Eee/sIcfInKNE2fUAYFK94SFAbcN6Jw=
X-Gm-Message-State: AOJu0Ywo58zhqzEHQzo3qzfUATk0e1L6vAFBgPlE+eDx932nrKjfqmq9
	kQapS+8moCHkejO+ulPK1rjs6hm4jSlbs3l6B4BD9aobRJwDSHpXZ8keLZg/eTw=
X-Google-Smtp-Source: AGHT+IEOvg34oYcu9GAIHQIWSpLYGC94raSmAj67zD4Gs/B4BPRdpoH1JkHeTSn1iij0r48HVMXasQ==
X-Received: by 2002:a17:906:3289:b0:a46:420f:8ecb with SMTP id 9-20020a170906328900b00a46420f8ecbmr1904346ejw.62.1711641420490;
        Thu, 28 Mar 2024 08:57:00 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org
Cc: Richard Henderson ,
	Eduardo Habkost ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org,
	Bernhard Beschow ,
	Thomas Huth ,
	Marcel Apfelbaum ,
	"Michael S. Tsirkin" ,
	Paolo Bonzini ,
	Igor Mammedov ,
	Anthony Perard ,
	Ani Sinha ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
Subject: [RFC PATCH-for-9.1 22/29] hw/i386/fw_cfg: Define fw_cfg_build_smbios() stub
Date: Thu, 28 Mar 2024 16:54:30 +0100
Message-ID: <20240328155439.58719-23-philmd@linaro.org>
X-Mailer: git-send-email 2.41.0
In-Reply-To: <20240328155439.58719-1-philmd@linaro.org>
References: <20240328155439.58719-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

We are going to refactor fw_cfg_build_smbios() in the
next patches. In order to avoid too much #ifdef'ry in
it, define a stub.

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/i386/fw_cfg-smbios-stub.c | 15 +++++++++++++++
 hw/i386/fw_cfg.c             |  4 ++--
 hw/i386/meson.build          |  1 +
 3 files changed, 18 insertions(+), 2 deletions(-)
 create mode 100644 hw/i386/fw_cfg-smbios-stub.c

diff --git a/hw/i386/fw_cfg-smbios-stub.c b/hw/i386/fw_cfg-smbios-stub.c
new file mode 100644
index 0000000000..37dbfdee7c
--- /dev/null
+++ b/hw/i386/fw_cfg-smbios-stub.c
@@ -0,0 +1,15 @@
+/*
+ * QEMU fw_cfg/SMBIOS stubs
+ *
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ * SPDX-FileCopyrightText: 2024 Linaro Ltd.
+ */
+
+#include "qemu/osdep.h"
+#include "hw/firmware/smbios.h"
+#include "fw_cfg.h"
+
+void fw_cfg_build_smbios(PCMachineState *pcms, FWCfgState *fw_cfg,
+                         SmbiosEntryPointType ep_type)
+{
+}
diff --git a/hw/i386/fw_cfg.c b/hw/i386/fw_cfg.c
index ecc4047a4b..14a7dfbdc9 100644
--- a/hw/i386/fw_cfg.c
+++ b/hw/i386/fw_cfg.c
@@ -48,10 +48,10 @@ const char *fw_cfg_arch_key_name(uint16_t key)
     return NULL;
 }
 
+#ifdef CONFIG_SMBIOS
 void fw_cfg_build_smbios(PCMachineState *pcms, FWCfgState *fw_cfg,
                          SmbiosEntryPointType ep_type)
 {
-#ifdef CONFIG_SMBIOS
     uint8_t *smbios_tables, *smbios_anchor;
     size_t smbios_tables_len, smbios_anchor_len;
     struct smbios_phys_mem_area *mem_array;
@@ -100,8 +100,8 @@ void fw_cfg_build_smbios(PCMachineState *pcms, FWCfgState *fw_cfg,
         fw_cfg_add_file(fw_cfg, "etc/smbios/smbios-anchor",
                         smbios_anchor, smbios_anchor_len);
     }
-#endif
 }
+#endif
 
 FWCfgState *fw_cfg_arch_create(MachineState *ms,
                                       uint16_t boot_cpus,
diff --git a/hw/i386/meson.build b/hw/i386/meson.build
index d8b70ef3e9..1a6e731196 100644
--- a/hw/i386/meson.build
+++ b/hw/i386/meson.build
@@ -6,6 +6,7 @@ i386_ss.add(files(
   'multiboot.c',
   'x86.c',
 ))
+i386_ss.add(when: 'CONFIG_SMBIOS', if_false: files('fw_cfg-smbios-stub.c'))
 
 i386_ss.add(when: 'CONFIG_X86_IOMMU', if_true: files('x86-iommu.c'),
                                       if_false: files('x86-iommu-stub.c'))
-- 
2.41.0



From xen-devel-bounces@lists.xenproject.org Thu Mar 28 16:12:16 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 16:12:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699090.1091642 (Exim 4.92)
	(envelope-from )
	id 1rpsMS-0000IR-6f; Thu, 28 Mar 2024 16:12:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699090.1091642; Thu, 28 Mar 2024 16:12:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpsMS-0000I6-4A; Thu, 28 Mar 2024 16:12:16 +0000
Received: by outflank-mailman (input) for mailman id 699090;
 Thu, 28 Mar 2024 16:12:14 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rps7n-0001AK-EE
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 15:57:07 +0000
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com
 [2a00:1450:4864:20::62e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d3c5034c-ed1b-11ee-afe3-a90da7624cb6;
 Thu, 28 Mar 2024 16:57:06 +0100 (CET)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-a466a27d30aso140700166b.1
 for ; Thu, 28 Mar 2024 08:57:06 -0700 (PDT)
Received: from m1x-phil.lan (pas38-h02-176-184-5-52.dsl.sta.abo.bbox.fr.
 [176.184.5.52]) by smtp.gmail.com with ESMTPSA id
 f8-20020a17090624c800b00a46fbff47a6sm891626ejb.168.2024.03.28.08.57.04
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Thu, 28 Mar 2024 08:57:06 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d3c5034c-ed1b-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1711641426; x=1712246226; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=4BSXB7GHW5TBQXIjnxuyxFyj9B1iDsM8cHi/htTyRxs=;
        b=H/TUrYVppdn7LmwRGsgx2j1wQU1h58w8/D/39uon7Jhk6b7slCRn97xbTg/LKyZoVY
         VJBJXV9OnD3YoJ3XiVC8kZxVxyNX/BZaTexO0SWUHL30WB0K8btFK3HGKLNjCq8ztgna
         vUnz/75nWBTquQnVecf1GUicG7lMFGgIuqkl0HYQFspy7CXJola8DESy+ff6OEqY1/Hk
         G26nvrb01XzF71lPtamFgGQum8MDO3xo4XW/cy62T1HEMhruqv3jF5vbEiJmJubnKesE
         RmmIFPNbVgBM55MOyFb8m6qqX4T6/8hCwqt2xi5hgXb92SfTNV9PtYsTciLDDy2gcHBK
         NnVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711641426; x=1712246226;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=4BSXB7GHW5TBQXIjnxuyxFyj9B1iDsM8cHi/htTyRxs=;
        b=lttiTexABxs/MZ1G9wVhWkn3X6mdCF/63J+2oCOb0SdU3eM4hxen8tIVBXc2bKYz8D
         c+IgbGvXXAVZoJhPci/GaXb7KaPfS1zoI5lOYpGkTIAyPZdeHlmYmL/iw5siZw7vEmz7
         02YJp3LP38zW/5TeRLnzD2ibieu4243U4q4He8W08qJdg6SW+2dazjuEZOBThProxg7e
         2qBl+1oxiCUKLS+fZYobgtVYvuB81xqDv+iyNlTMMvo30nQDGj0vqKO9sLX8w++BvpUn
         AXZzEVTUGrbJdILxL42P5u1jpz6B5QeppuIogR84h5wucdKLB0GPizkVtK0gHqoWkZch
         inww==
X-Forwarded-Encrypted: i=1; AJvYcCWdjweH8hCNV+vAtH7CnsX7fF0Ea6497PBY8wQGDvWS8rzMHqkFs4OkBxh9rtfVxn9mz6PofYakHxzHHDo6QNUGHNZnpXsFWlMGv/EeO8c=
X-Gm-Message-State: AOJu0Yy0JqKG5kgPIqm7Q+2R18VwWwABH/w+tWxO8OqlpsrGwi4PrYWk
	+fBqx38XNPRz22s+Gsc2a43dl0p8gkE4jwgjLYhnfBrKGsOLyUav6NC1HrayfiA=
X-Google-Smtp-Source: AGHT+IFF/skKWHNCTMPwJb+B2ckteIOxmThfN9+aMTRN8D0HIEaksr7NEcZ4nuV98VsFYsHsSKmB9w==
X-Received: by 2002:a17:906:b112:b0:a47:1fe8:9825 with SMTP id u18-20020a170906b11200b00a471fe89825mr2020350ejy.32.1711641426506;
        Thu, 28 Mar 2024 08:57:06 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org
Cc: Richard Henderson ,
	Eduardo Habkost ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org,
	Bernhard Beschow ,
	Thomas Huth ,
	Marcel Apfelbaum ,
	"Michael S. Tsirkin" ,
	Paolo Bonzini ,
	Igor Mammedov ,
	Anthony Perard ,
	Ani Sinha ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
Subject: [RFC PATCH-for-9.1 23/29] hw/i386/fw_cfg: Inline smbios_defaults()
Date: Thu, 28 Mar 2024 16:54:31 +0100
Message-ID: <20240328155439.58719-24-philmd@linaro.org>
X-Mailer: git-send-email 2.41.0
In-Reply-To: <20240328155439.58719-1-philmd@linaro.org>
References: <20240328155439.58719-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

All PCI-based machines have the smbios_defaults field
set to %true. Simplify by using an inlined helper
checking whether the machine is PCI-based or not.

Signed-off-by: Philippe Mathieu-Daudé 
---
 include/hw/i386/pc.h | 1 -
 hw/i386/fw_cfg.c     | 7 ++++++-
 hw/i386/pc.c         | 1 -
 hw/i386/pc_piix.c    | 1 -
 4 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 7da0bc8aa4..6a6a8df005 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -86,7 +86,6 @@ typedef struct PCMachineClass {
     int default_cpu_version;
 
     /* SMBIOS compat: */
-    bool smbios_defaults;
     bool smbios_legacy_mode;
     SmbiosEntryPointType default_smbios_ep_type;
 
diff --git a/hw/i386/fw_cfg.c b/hw/i386/fw_cfg.c
index 14a7dfbdc9..f60390ed56 100644
--- a/hw/i386/fw_cfg.c
+++ b/hw/i386/fw_cfg.c
@@ -49,6 +49,11 @@ const char *fw_cfg_arch_key_name(uint16_t key)
 }
 
 #ifdef CONFIG_SMBIOS
+static bool smbios_defaults(PCMachineState *pcms)
+{
+    return pc_machine_is_pci_enabled(pcms);
+}
+
 void fw_cfg_build_smbios(PCMachineState *pcms, FWCfgState *fw_cfg,
                          SmbiosEntryPointType ep_type)
 {
@@ -61,7 +66,7 @@ void fw_cfg_build_smbios(PCMachineState *pcms, FWCfgState *fw_cfg,
     MachineClass *mc = MACHINE_GET_CLASS(pcms);
     X86CPU *cpu = X86_CPU(ms->possible_cpus->cpus[0].cpu);
 
-    if (pcmc->smbios_defaults) {
+    if (smbios_defaults(pcms)) {
         /* These values are guest ABI, do not change */
         smbios_set_defaults("QEMU", mc->desc, mc->name);
     }
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index b83abee8e9..7a758a2e84 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1754,7 +1754,6 @@ static void pc_machine_class_init(ObjectClass *oc, void *data)
     PCMachineClass *pcmc = PC_MACHINE_CLASS(oc);
     HotplugHandlerClass *hc = HOTPLUG_HANDLER_CLASS(oc);
 
-    pcmc->smbios_defaults = true;
     pcmc->enforce_amd_1tb_hole = true;
     pcmc->pvh_enabled = true;
     pcmc->kvmclock_create_always = true;
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index e6178f8653..70dc8686f9 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -828,7 +828,6 @@ static void isapc_machine_options(MachineClass *m)
     m->max_cpus = 1;
     m->option_rom_has_mr = true;
     m->rom_file_has_mr = false;
-    pcmc->smbios_defaults = false;
     pcmc->smbios_legacy_mode = true;
     m->default_nic = "ne2k_isa";
     m->default_cpu_type = X86_CPU_TYPE_NAME("486");
-- 
2.41.0



From xen-devel-bounces@lists.xenproject.org Thu Mar 28 16:12:43 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 16:12:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699093.1091653 (Exim 4.92)
	(envelope-from )
	id 1rpsMs-0000pb-FU; Thu, 28 Mar 2024 16:12:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699093.1091653; Thu, 28 Mar 2024 16:12:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpsMs-0000pS-CH; Thu, 28 Mar 2024 16:12:42 +0000
Received: by outflank-mailman (input) for mailman id 699093;
 Thu, 28 Mar 2024 16:12:41 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rps77-00071m-G7
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 15:56:25 +0000
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com
 [2a00:1450:4864:20::12e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ba189f94-ed1b-11ee-a1ef-f123f15fe8a2;
 Thu, 28 Mar 2024 16:56:23 +0100 (CET)
Received: by mail-lf1-x12e.google.com with SMTP id
 2adb3069b0e04-513ccc70a6dso1821156e87.1
 for ; Thu, 28 Mar 2024 08:56:23 -0700 (PDT)
Received: from m1x-phil.lan (pas38-h02-176-184-5-52.dsl.sta.abo.bbox.fr.
 [176.184.5.52]) by smtp.gmail.com with ESMTPSA id
 i23-20020a170906265700b00a4749a1de50sm911948ejc.176.2024.03.28.08.56.21
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Thu, 28 Mar 2024 08:56:22 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ba189f94-ed1b-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1711641383; x=1712246183; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=YADozrynE6WAolQE0PpJsPO9+XRuTB0w7hXGd8JOVMk=;
        b=t+/1N04qiasqsLsW1lgmgpEzggXkQbmk+oQ1NJhOyjhH0YcvmjGTucJMeeT8eBUPFq
         IKeUNuKpBY1tycbKrGhB8bFrGRDwZSldhAImr+KZainvMB2DKkCwP2Huxkvzq6L3KvUf
         OmSyAf7lS307LtfbyDepTokbaVt3z3IUmC6VkYgSYzYuUDQrwDbP+0d9y9UMRVIqwVWX
         zcA3jxx0wh2Ux5QXvYzm1kciPjlNxM0t2H+zn9fMJ00MTFdnhLVGw39uEDZS4Jl/De5Y
         VzAsc4jyPlvNfw5nvj9rBt5xZjEB1PPFMrcYul712K/zGc66mvBzIo/6toieFCmTuIi5
         8ing==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711641383; x=1712246183;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=YADozrynE6WAolQE0PpJsPO9+XRuTB0w7hXGd8JOVMk=;
        b=aRnAOmSTY0S9nWMix/CY6m/mbmG/eZgdFvmLyczqTJNtH8tYWN8Y9VjMahrMudSR9j
         KFKQriAmQIngs4OHBkOUDNCXkLy0Vo9rRNe5EznpvWmPSXjbhO3QO9+/g+cCcuK5B6Pe
         RebLECxBlD8+hm7+UPg4EjWgkCXUe13NMGxUd5qsDWnB9BqR6yRVDU97J7TSZPrl29y/
         idRQ0rXhkNs6186kJ8A6lnMh6Xm30RVKGTTao4jCYhk5x9b0QbHvWVZCAaL2+QVAPHnQ
         g0wBdLpSsOcZ9B0DlMeeh50PJQ/rQyoiL2ibu7aMQ/bunh3h/EnOJDPg6e0/D9eIoyGp
         /0Hw==
X-Forwarded-Encrypted: i=1; AJvYcCX6L2J7bRd4C7QUV46BxOJFaZIGVRyeU28Ofq4oS/PfwEGEyz3kPPv/hW8pxMxaq00Y07pYr6+lM1doBvIBOuT6qts5jNOnjvbVwzcDJcA=
X-Gm-Message-State: AOJu0YxP05X8BH+CYOjCT9bK+3d1BzZZZzjbwrsoiP184pxD3vG4c2PZ
	D6iqMUSAIIDmXG36hvleZMBZ17Fjw9ub8fqMF4e/aGGalmQrxnBsT/O9ptjwR1E=
X-Google-Smtp-Source: AGHT+IFET2qLkxCYJlLAe5wqUF2LJxJCZxdIrO9Tbo3cYr9nsR7BCDgXHuGLT1xPB8OJyuTlfGMDhg==
X-Received: by 2002:a05:6512:78f:b0:513:e643:cd12 with SMTP id x15-20020a056512078f00b00513e643cd12mr2537328lfr.26.1711641383341;
        Thu, 28 Mar 2024 08:56:23 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org
Cc: Richard Henderson ,
	Eduardo Habkost ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org,
	Bernhard Beschow ,
	Thomas Huth ,
	Marcel Apfelbaum ,
	"Michael S. Tsirkin" ,
	Paolo Bonzini ,
	Igor Mammedov ,
	Anthony Perard ,
	Ani Sinha ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
Subject: [RFC PATCH-for-9.1 16/29] hw/i386/pc: Move south-bridge related fields to PcPciMachine
Date: Thu, 28 Mar 2024 16:54:24 +0100
Message-ID: <20240328155439.58719-17-philmd@linaro.org>
X-Mailer: git-send-email 2.41.0
In-Reply-To: <20240328155439.58719-1-philmd@linaro.org>
References: <20240328155439.58719-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

South bridge type is only relevant for the i440fx/piix
machine, which is PCI-based.

Signed-off-by: Philippe Mathieu-Daudé 
---
 include/hw/i386/pc.h |  8 ++++----
 hw/i386/pc.c         |  3 ++-
 hw/i386/pc_piix.c    | 12 ++++++------
 3 files changed, 12 insertions(+), 11 deletions(-)

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 668347c248..2db2aa03d3 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -38,7 +38,6 @@ typedef struct PCMachineState {
     uint64_t max_ram_below_4g;
     OnOffAuto vmport;
     SmbiosEntryPointType smbios_entry_point_type;
-    const char *south_bridge;
 
     bool smbus_enabled;
     bool sata_enabled;
@@ -59,6 +58,7 @@ typedef struct PcPciMachineState {
     Notifier machine_done;
 
     bool acpi_build_enabled;
+    const char *southbridge_typename;
     uint64_t max_fw_size;
 
     PFlashCFI01 *flash[2];
@@ -88,9 +88,6 @@ typedef struct PcPciMachineState {
 typedef struct PCMachineClass {
     X86MachineClass parent_class;
 
-    /* Device configuration: */
-    const char *default_south_bridge;
-
     /* Compat options: */
 
     /* Default CPU model version.  See x86_cpu_set_default_version(). */
@@ -126,6 +123,9 @@ typedef struct PCMachineClass {
 typedef struct PcPciMachineClass {
     PCMachineClass parent_class;
 
+    /* Device configuration: */
+    const char *default_southbridge_typename;
+
     /* ACPI compat: */
     int pci_root_uid;
 } PcPciMachineClass;
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 5753a3ff0b..dd44df0470 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1667,7 +1667,6 @@ static void pc_machine_initfn(Object *obj)
 #endif /* CONFIG_VMPORT */
     pcms->max_ram_below_4g = 0; /* use default */
     pcms->smbios_entry_point_type = pcmc->default_smbios_ep_type;
-    pcms->south_bridge = pcmc->default_south_bridge;
 
     pcms->smbus_enabled = true;
     pcms->sata_enabled = true;
@@ -1689,9 +1688,11 @@ static void pc_machine_initfn(Object *obj)
 static void pc_pci_machine_initfn(Object *obj)
 {
     PcPciMachineState *ppms = PC_PCI_MACHINE(obj);
+    PcPciMachineClass *ppmc = PC_PCI_MACHINE_GET_CLASS(ppms);
 
     ppms->acpi_build_enabled = true;
     ppms->max_fw_size = 8 * MiB;
+    ppms->southbridge_typename = ppmc->default_southbridge_typename;
 
     pc_system_flash_create(ppms);
     cxl_machine_init(obj, &ppms->cxl_devices_state);
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 6b3403d0bd..2043a7022a 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -243,7 +243,7 @@ static void pc_init1(MachineState *machine, const char *pci_type)
         DeviceState *dev;
         size_t i;
 
-        pci_dev = pci_new_multifunction(-1, pcms->south_bridge);
+        pci_dev = pci_new_multifunction(-1, ppms->southbridge_typename);
         object_property_set_bool(OBJECT(pci_dev), "has-usb",
                                  machine_usb(machine), &error_abort);
         object_property_set_bool(OBJECT(pci_dev), "has-acpi",
@@ -385,12 +385,12 @@ static const QEnumLookup PCSouthBridgeOption_lookup = {
 
 static int pc_get_south_bridge(Object *obj, Error **errp)
 {
-    PCMachineState *pcms = PC_MACHINE(obj);
+    PcPciMachineState *ppms = PC_PCI_MACHINE(obj);
     int i;
 
     for (i = 0; i < PCSouthBridgeOption_lookup.size; i++) {
         if (g_strcmp0(PCSouthBridgeOption_lookup.array[i],
-                      pcms->south_bridge) == 0) {
+                      ppms->southbridge_typename) == 0) {
             return i;
         }
     }
@@ -401,7 +401,7 @@ static int pc_get_south_bridge(Object *obj, Error **errp)
 
 static void pc_set_south_bridge(Object *obj, int value, Error **errp)
 {
-    PCMachineState *pcms = PC_MACHINE(obj);
+    PcPciMachineState *ppms = PC_PCI_MACHINE(obj);
 
     if (value < 0) {
         error_setg(errp, "Value can't be negative");
@@ -413,7 +413,7 @@ static void pc_set_south_bridge(Object *obj, int value, Error **errp)
         return;
     }
 
-    pcms->south_bridge = PCSouthBridgeOption_lookup.array[value];
+    ppms->southbridge_typename = PCSouthBridgeOption_lookup.array[value];
 }
 
 /* Looking for a pc_compat_2_4() function? It doesn't exist.
@@ -472,7 +472,7 @@ static void pc_i440fx_machine_options(MachineClass *m)
     PcPciMachineClass *ppmc = PC_PCI_MACHINE_CLASS(m);
     ObjectClass *oc = OBJECT_CLASS(m);
 
-    pcmc->default_south_bridge = TYPE_PIIX3_DEVICE;
+    ppmc->default_southbridge_typename = TYPE_PIIX3_DEVICE;
     ppmc->pci_root_uid = 0;
     pcmc->default_cpu_version = 1;
 
-- 
2.41.0



From xen-devel-bounces@lists.xenproject.org Thu Mar 28 16:13:52 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 16:13:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699096.1091662 (Exim 4.92)
	(envelope-from )
	id 1rpsNy-0001sv-Ns; Thu, 28 Mar 2024 16:13:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699096.1091662; Thu, 28 Mar 2024 16:13:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpsNy-0001so-LH; Thu, 28 Mar 2024 16:13:50 +0000
Received: by outflank-mailman (input) for mailman id 699096;
 Thu, 28 Mar 2024 16:13:48 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rps8Q-00071m-F1
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 15:57:46 +0000
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com
 [2a00:1450:4864:20::536])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ea569b5e-ed1b-11ee-a1ef-f123f15fe8a2;
 Thu, 28 Mar 2024 16:57:44 +0100 (CET)
Received: by mail-ed1-x536.google.com with SMTP id
 4fb4d7f45d1cf-56be32b9775so1376564a12.1
 for ; Thu, 28 Mar 2024 08:57:44 -0700 (PDT)
Received: from m1x-phil.lan (pas38-h02-176-184-5-52.dsl.sta.abo.bbox.fr.
 [176.184.5.52]) by smtp.gmail.com with ESMTPSA id
 p12-20020a50c94c000000b005689bfe2688sm980668edh.39.2024.03.28.08.57.42
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Thu, 28 Mar 2024 08:57:43 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ea569b5e-ed1b-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1711641464; x=1712246264; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=K6394pyfYpf5VBXUXIwRMOR2ZbX+o8CbfYrADQtuSgY=;
        b=WvI1SBUK4fKEIdNST5Oom0UvcTyjk0JKgtMjJVPOFxIkuyfji5tAKzA8hrnw9pnA8I
         /5HQNNqXTjLs2BO7m7XiL+hadBT8bd2VbQcEoHj+/MVFJF+GbejXSkPR6OFZuzF+/um6
         pr5ScokIigQD9i+T/sI51DWty9RLBKk5OgTGt/TnfDEbD1Rz5TVwtG4wuf8TDkZAqxnU
         CZ2kLvpSEg27Va7tcgGyA6mCDdRn0i5zppb79RwwNZSCPoFYhirLQItQsqj0DR3PhwkP
         F+jSx9UBdFeIgMOXRNvUkIe594IiksN6kf7LRuOoQRCATldF9nbHP23ZxRiaY2MKzKWB
         fNBA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711641464; x=1712246264;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=K6394pyfYpf5VBXUXIwRMOR2ZbX+o8CbfYrADQtuSgY=;
        b=H7HtCWa1lKWFwIlMV/Dwlb4Arm4vOaFOQIWq0p4Vi6EofMVjX/BBIleP9SxG1kGVxt
         9/Qnf5RH18+S07VW6RBYnJ8A9/oe/o2ufL5LwIG6N6bHgPKlAk/3IA8LfritCgKE8ten
         RO1uAr4ax4HRG5XbVLIHJxXsIca8qRW2s1BnIuwWsxGMsNpOKd7hALRvcmswSQr0sa1u
         1r+rXdrJDHVwypByhRLTU0TPWKHJu5eSjVoZb6IjgEAvhXi+uxsO7d24pUMyEuS9MHMY
         8iz/38Y3jrPKNj2mW8r1b4LFOHS1CubLBNf0N/f6l+EhgMFA4NmQNQ2OUMF3VST+ecGL
         hlfg==
X-Forwarded-Encrypted: i=1; AJvYcCUFN905sBQh/WmeaegqW4nyTHiuIGy3+xmQgOl13QXPB/ytj/5/X9Gz2AAgd7JsAlYon2D+5xQLcQ7Cnk90OF5kpEIxYfj5OcMV4BPEqBU=
X-Gm-Message-State: AOJu0YwfJIfcTlIdQwfd5+mma2MvRETMRpjuM0eBn9DsXs6xGobkM4gh
	1B0nbXL9uoR0JTW+wd3opzADDwtq57hq+Q9SU5Q7Cai+YV+v/AARMGqb+yKjjZk=
X-Google-Smtp-Source: AGHT+IHopSZ4mG4FmVwZwRyY4uEq7A+kY6caw0K60z5ZjV+GdO0roOAWBLEuOIrEv1csN4Rr2G6Jmg==
X-Received: by 2002:a50:d750:0:b0:565:e610:c358 with SMTP id i16-20020a50d750000000b00565e610c358mr2278668edj.38.1711641464364;
        Thu, 28 Mar 2024 08:57:44 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org
Cc: Richard Henderson ,
	Eduardo Habkost ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org,
	Bernhard Beschow ,
	Thomas Huth ,
	Marcel Apfelbaum ,
	"Michael S. Tsirkin" ,
	Paolo Bonzini ,
	Igor Mammedov ,
	Anthony Perard ,
	Ani Sinha ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
Subject: [RFC PATCH-for-9.1 29/29] hw/i386/pc: Move ISA-only PC machine to pc_isa.c
Date: Thu, 28 Mar 2024 16:54:37 +0100
Message-ID: <20240328155439.58719-30-philmd@linaro.org>
X-Mailer: git-send-email 2.41.0
In-Reply-To: <20240328155439.58719-1-philmd@linaro.org>
References: <20240328155439.58719-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Extract the ISA-only PC machine code from pc_piix.c
to a new file, pc_isa.c.

Signed-off-by: Philippe Mathieu-Daudé 
---
 MAINTAINERS         |  1 +
 hw/i386/pc_isa.c    | 33 +++++++++++++++++++++++++++++++++
 hw/i386/pc_piix.c   | 23 -----------------------
 hw/i386/meson.build |  1 +
 4 files changed, 35 insertions(+), 23 deletions(-)
 create mode 100644 hw/i386/pc_isa.c

diff --git a/MAINTAINERS b/MAINTAINERS
index a07af6b9d4..a68fa813b8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1812,6 +1812,7 @@ M: Marcel Apfelbaum 
 S: Supported
 F: include/hw/i386/
 F: hw/i386/
+X: hw/i386/pc_isa.c
 F: hw/pci-host/i440fx.c
 F: hw/pci-host/q35.c
 F: hw/pci-host/pam.c
diff --git a/hw/i386/pc_isa.c b/hw/i386/pc_isa.c
new file mode 100644
index 0000000000..a98c75f3ae
--- /dev/null
+++ b/hw/i386/pc_isa.c
@@ -0,0 +1,33 @@
+/*
+ * QEMU ISA PC System Emulator
+ *
+ * Copyright (c) 2003-2004 Fabrice Bellard
+ *
+ * SPDX-License-Identifier: MIT
+ */
+
+#include "qemu/osdep.h"
+#include "qom/object.h"
+#include "hw/boards.h"
+#include "hw/i386/pc.h"
+#include "hw/char/parallel-isa.h"
+#include "target/i386/cpu-qom.h"
+
+static void pc_init_isa(MachineState *machine)
+{
+    pc_piix_init(machine, NULL);
+}
+
+static void isapc_machine_options(MachineClass *m)
+{
+    m->desc = "ISA-only PC";
+    m->max_cpus = 1;
+    m->option_rom_has_mr = true;
+    m->rom_file_has_mr = false;
+    m->default_nic = "ne2k_isa";
+    m->default_cpu_type = X86_CPU_TYPE_NAME("486");
+    m->no_parallel = !module_object_class_by_name(TYPE_ISA_PARALLEL);
+}
+
+DEFINE_PC_MACHINE(isapc, "isapc", pc_init_isa,
+                  isapc_machine_options, TYPE_PC_MACHINE);
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 4a3ae72fe4..f94221ab92 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -434,13 +434,6 @@ static void pc_set_south_bridge(Object *obj, int value, Error **errp)
  * hw_compat_*, pc_compat_*, or * pc_*_machine_options().
  */
 
-#ifdef CONFIG_ISAPC
-static void pc_init_isa(MachineState *machine)
-{
-    pc_piix_init(machine, NULL);
-}
-#endif
-
 #ifdef CONFIG_XEN
 static void pc_xen_hvm_init_pci(MachineState *machine)
 {
@@ -820,22 +813,6 @@ static void pc_i440fx_2_4_machine_options(MachineClass *m)
 DEFINE_I440FX_MACHINE(v2_4, "pc-i440fx-2.4", NULL,
                       pc_i440fx_2_4_machine_options)
 
-#ifdef CONFIG_ISAPC
-static void isapc_machine_options(MachineClass *m)
-{
-    m->desc = "ISA-only PC";
-    m->max_cpus = 1;
-    m->option_rom_has_mr = true;
-    m->rom_file_has_mr = false;
-    m->default_nic = "ne2k_isa";
-    m->default_cpu_type = X86_CPU_TYPE_NAME("486");
-    m->no_parallel = !module_object_class_by_name(TYPE_ISA_PARALLEL);
-}
-
-DEFINE_PC_MACHINE(isapc, "isapc", pc_init_isa,
-                  isapc_machine_options, TYPE_PC_MACHINE);
-#endif
-
 #ifdef CONFIG_XEN
 static void xenfv_4_2_machine_options(MachineClass *m)
 {
diff --git a/hw/i386/meson.build b/hw/i386/meson.build
index 1a6e731196..0576fc6541 100644
--- a/hw/i386/meson.build
+++ b/hw/i386/meson.build
@@ -12,6 +12,7 @@ i386_ss.add(when: 'CONFIG_X86_IOMMU', if_true: files('x86-iommu.c'),
                                       if_false: files('x86-iommu-stub.c'))
 i386_ss.add(when: 'CONFIG_AMD_IOMMU', if_true: files('amd_iommu.c'),
                                       if_false: files('amd_iommu-stub.c'))
+i386_ss.add(when: 'CONFIG_ISAPC', if_true: files('pc_isa.c'))
 i386_ss.add(when: 'CONFIG_I440FX', if_true: files('pc_piix.c'))
 i386_ss.add(when: 'CONFIG_MICROVM', if_true: files('microvm.c', 'acpi-microvm.c', 'microvm-dt.c'))
 i386_ss.add(when: 'CONFIG_Q35', if_true: files('pc_q35.c'))
-- 
2.41.0



From xen-devel-bounces@lists.xenproject.org Thu Mar 28 16:13:52 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 16:13:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699097.1091667 (Exim 4.92)
	(envelope-from )
	id 1rpsNz-0001ve-0o; Thu, 28 Mar 2024 16:13:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699097.1091667; Thu, 28 Mar 2024 16:13:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpsNy-0001v9-TN; Thu, 28 Mar 2024 16:13:50 +0000
Received: by outflank-mailman (input) for mailman id 699097;
 Thu, 28 Mar 2024 16:13:48 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rps6P-00071m-6t
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 15:55:41 +0000
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com
 [2a00:1450:4864:20::635])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9fb6da5c-ed1b-11ee-a1ef-f123f15fe8a2;
 Thu, 28 Mar 2024 16:55:39 +0100 (CET)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-a2f22bfb4e6so154976866b.0
 for ; Thu, 28 Mar 2024 08:55:39 -0700 (PDT)
Received: from m1x-phil.lan (pas38-h02-176-184-5-52.dsl.sta.abo.bbox.fr.
 [176.184.5.52]) by smtp.gmail.com with ESMTPSA id
 j15-20020a170906254f00b00a473362062fsm894249ejb.220.2024.03.28.08.55.37
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Thu, 28 Mar 2024 08:55:38 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9fb6da5c-ed1b-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1711641339; x=1712246139; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=ckSqN94Ak/AVFv4C8DP1wel6lx7UDcBC5ZVn+IWQ+zI=;
        b=VLRlRVMtsCcUj8gm8+ZKYALS4tR+eUM/GC7Qv6j7tfYWLou6mzrFCzuVd4GkTnG2sQ
         yZGN0XSDC8NdF2c30bDI6lLdOvVI8Vf/6FVMLWfCOperFm78Ht4JtorXTNlldTzOrs+l
         VcTIsZhTzQmH3ev64qwpYr0Gi1DveK/5aJcBbYk7wZYdEsx9/s8X0WjPKuCsLrde9AT3
         27++mK8lms3TKLIHY5K5hhSeCTFz3p2yjbsms/gIOb3WrnOPRQu8Q2IWT1kHRIqSK2Tt
         vA77yEuiin9tLxl2bc2XWAH97fMoxda/Kf6v6Nuir2DxPeTpZKLVJHNYWLtd40sqOYYi
         Sg+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711641339; x=1712246139;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=ckSqN94Ak/AVFv4C8DP1wel6lx7UDcBC5ZVn+IWQ+zI=;
        b=Yo23aEZ2XT8NU/LqJ28+lAC7qJJlTHk3Ao3j7QtNQpfRHNbHEsEJx0R3iv2wp+2Yjt
         sKwd6BGjtiRL/CBYFwmrRYHgR/l7KhKYUzP1uComAQZDtOfJLdjaENPtWWVkjNLt2BVc
         WNktc9MQAVv6sQiqrlLB2NlB4k1j+uJ3mx3R/NaigeSL3DDFgoYXdfGhDUpJHmYygK+p
         70w819H7ECPrUN2koc80VkSZLHZhw4j0CfCJLRZLRXRsCSiDtb+5yqlfibIDOyuW3fDp
         TpsNSzFR+k1hkr7hsV9uJh7ye2vhx615TcLINUtdyGaBdNhkY1efvZ1fREH1QmrRUUMF
         3vXg==
X-Forwarded-Encrypted: i=1; AJvYcCVmogoDO5zf6jjyHtelA6BbNepygGlCJ8nX14oq4XoWBNHbXVguHuGQS7Yzu9R/thZpA+chOZj4i0pVbd+Vgrjt9+tQWqPKX5TRcUnu+a0=
X-Gm-Message-State: AOJu0YyqdpvbFGsXW9NKZpvU+aFg1Mw97w0/mGdUkmjRasOAFJ9kwb8Y
	99/C7UgoGFQOTcFnR+agWcHtUXH397HyffECR9wzx9FrSpaTbO2B4VS4Q2TRdtM=
X-Google-Smtp-Source: AGHT+IGwP6p/08zu3mCMRpeAkzfHcigXM/JR3t5dmiNwQCcEIbh+pOnBScYA897DxMkDTYP+GJc42Q==
X-Received: by 2002:a17:906:494f:b0:a47:4fed:514a with SMTP id f15-20020a170906494f00b00a474fed514amr1839620ejt.52.1711641339277;
        Thu, 28 Mar 2024 08:55:39 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org
Cc: Richard Henderson ,
	Eduardo Habkost ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org,
	Bernhard Beschow ,
	Thomas Huth ,
	Marcel Apfelbaum ,
	"Michael S. Tsirkin" ,
	Paolo Bonzini ,
	Igor Mammedov ,
	Anthony Perard ,
	Ani Sinha ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
Subject: [RFC PATCH-for-9.1 09/29] hw/i386/pc: Pass PCMachineState argument to acpi_setup()
Date: Thu, 28 Mar 2024 16:54:17 +0100
Message-ID: <20240328155439.58719-10-philmd@linaro.org>
X-Mailer: git-send-email 2.41.0
In-Reply-To: <20240328155439.58719-1-philmd@linaro.org>
References: <20240328155439.58719-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

acpi_setup() caller knows about the machine state, so pass
it as argument to avoid a qdev_get_machine() call.

We already resolved X86_MACHINE(pcms) as 'x86ms' so use the
latter.

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/i386/acpi-build.h | 3 ++-
 hw/i386/acpi-build.c | 5 ++---
 hw/i386/pc.c         | 2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/hw/i386/acpi-build.h b/hw/i386/acpi-build.h
index 0dce155c8c..31de5bddbd 100644
--- a/hw/i386/acpi-build.h
+++ b/hw/i386/acpi-build.h
@@ -2,6 +2,7 @@
 #ifndef HW_I386_ACPI_BUILD_H
 #define HW_I386_ACPI_BUILD_H
 #include "hw/acpi/acpi-defs.h"
+#include "hw/i386/pc.h"
 
 extern const struct AcpiGenericAddress x86_nvdimm_acpi_dsmio;
 
@@ -9,7 +10,7 @@ extern const struct AcpiGenericAddress x86_nvdimm_acpi_dsmio;
 #define ACPI_PCIHP_SEJ_BASE 0x8
 #define ACPI_PCIHP_BNMR_BASE 0x10
 
-void acpi_setup(void);
+void acpi_setup(PCMachineState *pcms);
 Object *acpi_get_i386_pci_host(void);
 
 #endif
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 6e8e32e5d2..e702d5e9d2 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -2749,9 +2749,8 @@ static const VMStateDescription vmstate_acpi_build = {
     },
 };
 
-void acpi_setup(void)
+void acpi_setup(PCMachineState *pcms)
 {
-    PCMachineState *pcms = PC_MACHINE(qdev_get_machine());
     X86MachineState *x86ms = X86_MACHINE(pcms);
     AcpiBuildTables tables;
     AcpiBuildState *build_state;
@@ -2771,7 +2770,7 @@ void acpi_setup(void)
         return;
     }
 
-    if (!x86_machine_is_acpi_enabled(X86_MACHINE(pcms))) {
+    if (!x86_machine_is_acpi_enabled(x86ms)) {
         ACPI_BUILD_DPRINTF("ACPI disabled. Bailing out.\n");
         return;
     }
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 6d87d1d4c2..dfc0247bb6 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -601,7 +601,7 @@ void pc_machine_done(Notifier *notifier, void *data)
     /* set the number of CPUs */
     x86_rtc_set_cpus_count(x86ms->rtc, x86ms->boot_cpus);
 
-    acpi_setup();
+    acpi_setup(pcms);
     if (x86ms->fw_cfg) {
         fw_cfg_build_smbios(pcms, x86ms->fw_cfg, pcms->smbios_entry_point_type);
         fw_cfg_build_feature_control(MACHINE(pcms), x86ms->fw_cfg);
-- 
2.41.0



From xen-devel-bounces@lists.xenproject.org Thu Mar 28 16:17:53 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 16:17:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699112.1091682 (Exim 4.92)
	(envelope-from )
	id 1rpsRo-000487-Jy; Thu, 28 Mar 2024 16:17:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699112.1091682; Thu, 28 Mar 2024 16:17:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpsRo-000480-Gp; Thu, 28 Mar 2024 16:17:48 +0000
Received: by outflank-mailman (input) for mailman id 699112;
 Thu, 28 Mar 2024 16:17:47 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpsRn-0003xV-DL
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 16:17:47 +0000
Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.4])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b5a95fb8-ed1e-11ee-a1ef-f123f15fe8a2;
 Thu, 28 Mar 2024 17:17:45 +0100 (CET)
Received: from m5p.com (mailhost.m5p.com [IPv6:2001:470:1f07:15ff:0:0:0:f7])
 by mailhost.m5p.com (8.17.1/8.15.2) with ESMTPS id 42SGHX9t088861
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
 Thu, 28 Mar 2024 12:17:39 -0400 (EDT) (envelope-from ehem@m5p.com)
Received: (from ehem@localhost)
 by m5p.com (8.17.1/8.15.2/Submit) id 42SGHXbn088860;
 Thu, 28 Mar 2024 09:17:33 -0700 (PDT) (envelope-from ehem)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b5a95fb8-ed1e-11ee-a1ef-f123f15fe8a2
Date: Thu, 28 Mar 2024 09:17:33 -0700
From: Elliott Mitchell 
To: Jan Beulich 
Cc: xen-devel@lists.xenproject.org, Andrew Cooper ,
        Roger Pau =?iso-8859-1?Q?Monn=E9?= ,
        Wei Liu , Kelly Choi 
Subject: Re: Serious AMD-Vi(?) issue
Message-ID: 
References: 
 
 
 
 
 
 
 
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-Spam-Status: No, score=0.0 required=10.0 tests=KHOP_HELO_FCRDNS
	autolearn=unavailable autolearn_force=no version=4.0.0
X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on mattapan.m5p.com

On Thu, Mar 28, 2024 at 08:22:31AM -0700, Elliott Mitchell wrote:
> On Thu, Mar 28, 2024 at 07:25:02AM +0100, Jan Beulich wrote:
> > On 27.03.2024 18:27, Elliott Mitchell wrote:
> > > On Mon, Mar 25, 2024 at 02:43:44PM -0700, Elliott Mitchell wrote:
> > >> On Mon, Mar 25, 2024 at 08:55:56AM +0100, Jan Beulich wrote:
> > >>>
> > >>> In fact when running into trouble, the usual course of action would be to
> > >>> increase verbosity in both hypervisor and kernel, just to make sure no
> > >>> potentially relevant message is missed.
> > >>
> > >> More/better information might have been obtained if I'd been engaged
> > >> earlier.
> > > 
> > > This is still true, things are in full mitigation mode and I'll be
> > > quite unhappy to go back with experiments at this point.
> > 
> > Well, it very likely won't work without further experimenting by someone
> > able to observe the bad behavior. Recall we're on xen-devel here; it is
> > kind of expected that without clear (and practical) repro instructions
> > experimenting as well as info collection will remain with the reporter.
> 
> The first reporter: https://bugs.debian.org/988477 gave pretty specific
> details about their setups.
> 
> While the exact border isn't very well defined, that seems enough to give
> a pretty good start.  We don't know whether all Samsung SATA devices are
> effected, but most of the recent ones (<5 years old) are.  This requires
> a pair of devices in software RAID1.  Likely reproduces better with AMD
> AM4/AM5 processors, but almost certainly needs a fully operational IOMMU.
> 
> (ASUS motherboards tend to have well setup IOMMUs)
> 
> I would be surprised if you don't have all of the hardware on-hand.  Only
> issue would be finding an appropriate pair of SATA devices, since those
> tend to remain in service.  I would look for older devices which were
> removed from service due to being too small (128GB 840 PRO from the first
> report), or were pulled from service due to having had too many writes.

Come to think of it, one more possible ingredient to this.  Similar to
the first report, when the problem occurred, the SATA device was plugged
into an on chipset SATA port, not the extra controller this motherboard
has.  I don't know whether the performance difference of an off-main
chip controller would influence this, but it might.


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg@m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include  O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445




From xen-devel-bounces@lists.xenproject.org Thu Mar 28 16:34:17 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 16:34:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699121.1091702 (Exim 4.92)
	(envelope-from )
	id 1rpshi-00057G-3D; Thu, 28 Mar 2024 16:34:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699121.1091702; Thu, 28 Mar 2024 16:34:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpshi-000579-0g; Thu, 28 Mar 2024 16:34:14 +0000
Received: by outflank-mailman (input) for mailman id 699121;
 Thu, 28 Mar 2024 16:34:12 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpshg-0004sj-DL
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 16:34:12 +0000
Received: from mail.actia.se (mail.actia.se [212.181.117.226])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0067d42d-ed21-11ee-a1ef-f123f15fe8a2;
 Thu, 28 Mar 2024 17:34:09 +0100 (CET)
Received: from S036ANL.actianordic.se (10.12.31.117) by S036ANL.actianordic.se
 (10.12.31.117) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.37; Thu, 28 Mar
 2024 17:34:08 +0100
Received: from S036ANL.actianordic.se ([fe80::e13e:1feb:4ea6:ec69]) by
 S036ANL.actianordic.se ([fe80::e13e:1feb:4ea6:ec69%4]) with mapi id
 15.01.2507.037; Thu, 28 Mar 2024 17:34:08 +0100
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0067d42d-ed21-11ee-a1ef-f123f15fe8a2
From: John Ernberg 
To: Julien Grall , Stefano Stabellini
	, Bertrand Marquis ,
	"Michal Orzel" , Volodymyr Babchuk
	
CC: Andrew Cooper , George Dunlap
	, Jan Beulich ,
	"xen-devel@lists.xenproject.org" , Peng Fan
	, Jonas Blixt , John Ernberg
	
Subject: [PATCH v3 1/3] xen/arm: Add imx8q{m,x} platform glue
Thread-Topic: [PATCH v3 1/3] xen/arm: Add imx8q{m,x} platform glue
Thread-Index: AQHagS3BrTI19ck4x0i8vHY8dyeSxw==
Date: Thu, 28 Mar 2024 16:34:08 +0000
Message-ID: <20240328163351.64808-2-john.ernberg@actia.se>
References: <20240328163351.64808-1-john.ernberg@actia.se>
In-Reply-To: <20240328163351.64808-1-john.ernberg@actia.se>
Accept-Language: en-US, sv-SE
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: git-send-email 2.44.0
x-originating-ip: [10.12.12.11]
x-esetresult: clean, is OK
x-esetid: 37303A2958D729556C7D66
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

When using Linux for dom0 there are a bunch of drivers that need to do SMC
SIP calls into the firmware to enable certain hardware bits like the
watchdog.

Provide a basic platform glue that implements the needed SMC forwarding.

The format of these calls are as follows:
 - reg 0: function ID
 - reg 1: subfunction ID (when there's a subfunction)
 remaining regs: args

For now we only allow Dom0 to make these calls as they are all managing
hardware. There is no specification for these SIP calls, the IDs and names
have been extracted from the upstream linux kernel and the vendor kernel.

Most of the SIP calls are only available for the iMX8M series of SoCs, so
they are easy to reject and they need to be revisited when iMX8M series
support is added.

>From the other calls we can reject CPUFREQ because Dom0 cannot make an
informed decision regarding CPU frequency scaling, WAKEUP_SRC is to wake
up from suspend, which Xen doesn't support at this time.

This leaves the TIME SIP, OTP SIPs, BUILDINFO SIP and TEMP ALARM SIP, which
for now are allowed to Dom0.

NOTE: This code is based on code found in NXP Xen tree located here:
https://github.com/nxp-imx/imx-xen/blob/lf-5.10.y_4.13/xen/arch/arm/platfor=
ms/imx8qm.c

Signed-off-by: Peng Fan 
[jernberg: Add SIP call filtering]
Signed-off-by: John Ernberg 

---

v3:
 - Adhere to style guidelines for line length and label indentation (Michal=
 Orzel)
 - Use smccc macros to build the SIP function identifier (Michal Orzel)
 - Adjust platform name to be specific to QM and QXP variants (Michal Orzel=
)
 - Pick up additional SIPs which may be used by other Linux versions - for =
review purposes
 - Changes to the commit message due to above

v2:
 - Reword the commit message to be a bit clearer
 - Include the link previously added as a context note to the commit messag=
e (Julien Grall)
 - Add Pengs signed off (Julien Grall, Peng Fan)
 - Add basic SIP call filter (Julien Grall)
 - Expand the commit message a whole bunch because of the changes to the co=
de
---
 xen/arch/arm/platforms/Makefile |   1 +
 xen/arch/arm/platforms/imx8qm.c | 168 ++++++++++++++++++++++++++++++++
 2 files changed, 169 insertions(+)
 create mode 100644 xen/arch/arm/platforms/imx8qm.c

diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makef=
ile
index 8632f4115f..bec6e55d1f 100644
--- a/xen/arch/arm/platforms/Makefile
+++ b/xen/arch/arm/platforms/Makefile
@@ -9,5 +9,6 @@ obj-$(CONFIG_ALL_PLAT)   +=3D sunxi.o
 obj-$(CONFIG_ALL64_PLAT) +=3D thunderx.o
 obj-$(CONFIG_ALL64_PLAT) +=3D xgene-storm.o
 obj-$(CONFIG_ALL64_PLAT) +=3D brcm-raspberry-pi.o
+obj-$(CONFIG_ALL64_PLAT) +=3D imx8qm.o
 obj-$(CONFIG_MPSOC_PLATFORM)  +=3D xilinx-zynqmp.o
 obj-$(CONFIG_MPSOC_PLATFORM)  +=3D xilinx-zynqmp-eemi.o
diff --git a/xen/arch/arm/platforms/imx8qm.c b/xen/arch/arm/platforms/imx8q=
m.c
new file mode 100644
index 0000000000..0992475474
--- /dev/null
+++ b/xen/arch/arm/platforms/imx8qm.c
@@ -0,0 +1,168 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * xen/arch/arm/platforms/imx8qm.c
+ *
+ * i.MX 8QM setup
+ *
+ * Copyright (c) 2016 Freescale Inc.
+ * Copyright 2018-2019 NXP
+ *
+ *
+ * Peng Fan 
+ */
+
+#include 
+#include 
+#include 
+
+static const char * const imx8qm_dt_compat[] __initconst =3D
+{
+    "fsl,imx8qm",
+    "fsl,imx8qxp",
+    NULL
+};
+
+#define IMX_SIP_FID(fid) \
+    ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+                       ARM_SMCCC_CONV_64, \
+                       ARM_SMCCC_OWNER_SIP, \
+                       fid)
+
+#define IMX_SIP_F_GPC            0x0000
+#define IMX_SIP_F_CPUFREQ        0x0001
+#define IMX_SIP_F_TIME           0x0002
+#define IMX_SIP_F_BUILDINFO      0x0003
+#define IMX_SIP_F_DDR_DVFS       0x0004
+#define IMX_SIP_F_SRC            0x0005
+#define IMX_SIP_F_GET_SOC_INFO   0x0006
+#define IMX_SIP_F_NOC            0x0008
+#define IMX_SIP_F_WAKEUP_SRC     0x0009
+#define IMX_SIP_F_OTP_READ       0x000A
+#define IMX_SIP_F_OTP_WRITE      0x000B
+#define IMX_SIP_F_SET_TEMP_ALARM 0x000C
+
+#define IMX_SIP_TIME_SF_RTC_SET_TIME     0x00
+#define IMX_SIP_TIME_SF_WDOG_START       0x01
+#define IMX_SIP_TIME_SF_WDOG_STOP        0x02
+#define IMX_SIP_TIME_SF_WDOG_SET_ACT     0x03
+#define IMX_SIP_TIME_SF_WDOG_PING        0x04
+#define IMX_SIP_TIME_SF_WDOG_SET_TIMEOUT 0x05
+#define IMX_SIP_TIME_SF_WDOG_GET_STAT    0x06
+#define IMX_SIP_TIME_SF_WDOG_SET_PRETIME 0x07
+
+static bool imx8qm_is_sip_time_call_ok(uint32_t subfunction_id)
+{
+    switch ( subfunction_id )
+    {
+    case IMX_SIP_TIME_SF_RTC_SET_TIME:
+        return true;
+    case IMX_SIP_TIME_SF_WDOG_START:
+    case IMX_SIP_TIME_SF_WDOG_STOP:
+    case IMX_SIP_TIME_SF_WDOG_SET_ACT:
+    case IMX_SIP_TIME_SF_WDOG_PING:
+    case IMX_SIP_TIME_SF_WDOG_SET_TIMEOUT:
+    case IMX_SIP_TIME_SF_WDOG_GET_STAT:
+    case IMX_SIP_TIME_SF_WDOG_SET_PRETIME:
+        return true;
+    default:
+        printk(XENLOG_WARNING "imx8qm: smc: time: Unknown subfunction id %=
x\n",
+               subfunction_id);
+        return false;
+    }
+}
+
+static bool imx8qm_smc(struct cpu_user_regs *regs)
+{
+    uint32_t function_id =3D get_user_reg(regs, 0);
+    uint32_t subfunction_id =3D get_user_reg(regs, 1);
+    struct arm_smccc_res res;
+
+    if ( !cpus_have_const_cap(ARM_SMCCC_1_1) )
+    {
+        printk_once(XENLOG_WARNING "no SMCCC 1.1 support. Disabling firmwa=
re calls\n");
+
+        return false;
+    }
+
+    /* Only hardware domain may use the SIP calls */
+    if ( !is_hardware_domain(current->domain) )
+    {
+        gprintk(XENLOG_WARNING, "imx8qm: smc: No access\n");
+        return false;
+    }
+
+    switch ( function_id )
+    {
+    /* Only available on imx8m series */
+    case IMX_SIP_FID(IMX_SIP_F_GPC):
+        return false;
+    case IMX_SIP_FID(IMX_SIP_F_CPUFREQ):
+        /* Hardware domain can't take any informed decision here */
+        return false;
+    case IMX_SIP_FID(IMX_SIP_F_BUILDINFO):
+        goto allow_call;
+    case IMX_SIP_FID(IMX_SIP_F_TIME):
+        if ( imx8qm_is_sip_time_call_ok(subfunction_id) )
+            goto allow_call;
+        return false;
+    /* Only available on imx8m series */
+    case IMX_SIP_FID(IMX_SIP_F_DDR_DVFS):
+        return false;
+    /* Only available on imx8m series */
+    case IMX_SIP_FID(IMX_SIP_F_SRC):
+        return false;
+    /* Only available on imx8m series */
+    case IMX_SIP_FID(IMX_SIP_F_GET_SOC_INFO):
+        return false;
+    /* Only available on imx8m series */
+    case IMX_SIP_FID(IMX_SIP_F_NOC):
+        return false;
+    /* Xen doesn't have suspend support */
+    case IMX_SIP_FID(IMX_SIP_F_WAKEUP_SRC):
+        return false;
+    case IMX_SIP_FID(IMX_SIP_F_OTP_READ):
+        /* subfunction_id is the fuse number, no sensible check possible *=
/
+        goto allow_call;
+    case IMX_SIP_FID(IMX_SIP_F_OTP_WRITE):
+        /* subfunction_id is the fuse number, no sensible check possible *=
/
+        goto allow_call;
+    case IMX_SIP_FID(IMX_SIP_F_SET_TEMP_ALARM):
+        goto allow_call;
+    default:
+        printk(XENLOG_WARNING "imx8qm: smc: Unknown function id %x\n",
+               function_id);
+        return false;
+    }
+
+ allow_call:
+    arm_smccc_1_1_smc(function_id,
+                      subfunction_id,
+                      get_user_reg(regs, 2),
+                      get_user_reg(regs, 3),
+                      get_user_reg(regs, 4),
+                      get_user_reg(regs, 5),
+                      get_user_reg(regs, 6),
+                      get_user_reg(regs, 7),
+                      &res);
+
+    set_user_reg(regs, 0, res.a0);
+    set_user_reg(regs, 1, res.a1);
+    set_user_reg(regs, 2, res.a2);
+    set_user_reg(regs, 3, res.a3);
+
+    return true;
+}
+
+PLATFORM_START(imx8qm, "i.MX 8Q{M,XP}")
+    .compatible =3D imx8qm_dt_compat,
+    .smc =3D imx8qm_smc,
+PLATFORM_END
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
--=20
2.44.0


From xen-devel-bounces@lists.xenproject.org Thu Mar 28 16:34:17 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 16:34:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699123.1091721 (Exim 4.92)
	(envelope-from )
	id 1rpshj-0005Te-Sr; Thu, 28 Mar 2024 16:34:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699123.1091721; Thu, 28 Mar 2024 16:34:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpshj-0005Sa-Km; Thu, 28 Mar 2024 16:34:15 +0000
Received: by outflank-mailman (input) for mailman id 699123;
 Thu, 28 Mar 2024 16:34:14 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpshi-0004sj-Dg
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 16:34:14 +0000
Received: from mail.actia.se (mail.actia.se [212.181.117.226])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 028a482f-ed21-11ee-a1ef-f123f15fe8a2;
 Thu, 28 Mar 2024 17:34:12 +0100 (CET)
Received: from S036ANL.actianordic.se (10.12.31.117) by S036ANL.actianordic.se
 (10.12.31.117) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.37; Thu, 28 Mar
 2024 17:34:09 +0100
Received: from S036ANL.actianordic.se ([fe80::e13e:1feb:4ea6:ec69]) by
 S036ANL.actianordic.se ([fe80::e13e:1feb:4ea6:ec69%4]) with mapi id
 15.01.2507.037; Thu, 28 Mar 2024 17:34:09 +0100
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 028a482f-ed21-11ee-a1ef-f123f15fe8a2
From: John Ernberg 
To: Julien Grall , Stefano Stabellini
	, Bertrand Marquis ,
	"Michal Orzel" , Volodymyr Babchuk
	
CC: Andrew Cooper , George Dunlap
	, Jan Beulich ,
	"xen-devel@lists.xenproject.org" , Peng Fan
	, Jonas Blixt , John Ernberg
	
Subject: [PATCH v3 3/3] MAINTAINERS: Become a reviewer of iMX8Q{M,XP} related
 patches
Thread-Topic: [PATCH v3 3/3] MAINTAINERS: Become a reviewer of iMX8Q{M,XP}
 related patches
Thread-Index: AQHagS3BovnjCFENDkmKWDvyUosLMw==
Date: Thu, 28 Mar 2024 16:34:08 +0000
Message-ID: <20240328163351.64808-4-john.ernberg@actia.se>
References: <20240328163351.64808-1-john.ernberg@actia.se>
In-Reply-To: <20240328163351.64808-1-john.ernberg@actia.se>
Accept-Language: en-US, sv-SE
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: git-send-email 2.44.0
x-originating-ip: [10.12.12.11]
x-esetresult: clean, is OK
x-esetid: 37303A2958D729556C7D66
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

I have experience with the IMX8QXP, and the supported parts of the IMX8QM
are identical.

Help review patches touching these areas.

---

v3:
 - New patch (Bertrand Marquis)
---
 MAINTAINERS | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 1bd22fd75f..09982241b3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -337,6 +337,11 @@ F:	tools/misc/xenhypfs.c
 F:	xen/common/hypfs.c
 F:	xen/include/xen/hypfs.h
=20
+IMX8QM/QXP SUPPORT
+R:	John Ernberg 
+F:	xen/arch/arm/platforms/imx8qm.c
+F:	xen/drivers/char/imx-lpuart.c
+
 INTEL(R) TRUSTED EXECUTION TECHNOLOGY (TXT)
 R:	Lukasz Hawrylko 
 R:	Daniel P. Smith 
--=20
2.44.0


From xen-devel-bounces@lists.xenproject.org Thu Mar 28 16:34:17 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 16:34:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699120.1091693 (Exim 4.92)
	(envelope-from )
	id 1rpshg-0004t1-Tc; Thu, 28 Mar 2024 16:34:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699120.1091693; Thu, 28 Mar 2024 16:34:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpshg-0004su-Qo; Thu, 28 Mar 2024 16:34:12 +0000
Received: by outflank-mailman (input) for mailman id 699120;
 Thu, 28 Mar 2024 16:34:11 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpshf-0004sj-OM
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 16:34:11 +0000
Received: from mail.actia.se (mail.actia.se [212.181.117.226])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0067e672-ed21-11ee-a1ef-f123f15fe8a2;
 Thu, 28 Mar 2024 17:34:09 +0100 (CET)
Received: from S036ANL.actianordic.se (10.12.31.117) by S035ANL.actianordic.se
 (10.12.31.116) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.37; Thu, 28 Mar
 2024 17:34:08 +0100
Received: from S036ANL.actianordic.se ([fe80::e13e:1feb:4ea6:ec69]) by
 S036ANL.actianordic.se ([fe80::e13e:1feb:4ea6:ec69%4]) with mapi id
 15.01.2507.037; Thu, 28 Mar 2024 17:34:08 +0100
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0067e672-ed21-11ee-a1ef-f123f15fe8a2
From: John Ernberg 
To: Julien Grall , Stefano Stabellini
	, Bertrand Marquis ,
	"Michal Orzel" , Volodymyr Babchuk
	
CC: Andrew Cooper , George Dunlap
	, Jan Beulich ,
	"xen-devel@lists.xenproject.org" , Peng Fan
	, Jonas Blixt , John Ernberg
	
Subject: [PATCH v3 0/2] Xen: ARM: Improved NXP iMX8 platform support
Thread-Topic: [PATCH v3 0/2] Xen: ARM: Improved NXP iMX8 platform support
Thread-Index: AQHagS3BYCNM31zad0Wcj7N7qYftsw==
Date: Thu, 28 Mar 2024 16:34:08 +0000
Message-ID: <20240328163351.64808-1-john.ernberg@actia.se>
Accept-Language: en-US, sv-SE
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: git-send-email 2.44.0
x-originating-ip: [10.12.12.11]
x-esetresult: clean, is OK
x-esetid: 37303A2921D729556C7D66
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

The iMX lpuart driver added at 44e17aa60d47 ("xen/arm: Add i.MX lpuart driv=
er")
is not enough to boot a Linux based dom0 when certain drivers, such as the
watchdog driver, are enabled.

We're also fixing compatibles in imx-lpuart to allow Xen to use the UART
on the QXP variant as well.

When it comes to the watchdog we're currently only implementing the support
for letting Dom0 manage it. There is also a desire for another approach
where Xen kicks the watchdog (dom0-less use-cases etc). This approach is
not covered by this patch set.

NOTE: There is still an open point about the iMX8M* related SIP calls in
the driver and the value of documenting them. There was also a few other
calls noted that weren't implemented because Linux today aren't using them.
I added these as they were part of the discussion if they should be
documented or not.


v3: (see individual patches for detailed changelog)
 - Added a few more SIP calls
 - Become a reviewer of IMX8Q{M,XP} related patches (Bertrand Marquis)

v2: https://lore.kernel.org/xen-devel/20240214160644.3418228-1-john.ernberg=
@actia.se/
 - Added SIP call filtering (Julien Grall)
 - Replace lpuart compatible instead (Julien Grall)

v1: https://lore.kernel.org/xen-devel/20240131114952.305805-1-john.ernberg@=
actia.se

John Ernberg (3):
  xen/arm: Add imx8q{m,x} platform glue
  xen/drivers: imx-lpuart: Replace iMX8QM compatible with iMX8QXP
  MAINTAINERS: Become a reviewer of iMX8Q{M,XP} related patches

 MAINTAINERS                     |   5 +
 xen/arch/arm/platforms/Makefile |   1 +
 xen/arch/arm/platforms/imx8qm.c | 168 ++++++++++++++++++++++++++++++++
 xen/drivers/char/imx-lpuart.c   |   2 +-
 4 files changed, 175 insertions(+), 1 deletion(-)
 create mode 100644 xen/arch/arm/platforms/imx8qm.c

--=20
2.44.0


From xen-devel-bounces@lists.xenproject.org Thu Mar 28 16:34:17 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 16:34:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699122.1091713 (Exim 4.92)
	(envelope-from )
	id 1rpshj-0005My-Ae; Thu, 28 Mar 2024 16:34:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699122.1091713; Thu, 28 Mar 2024 16:34:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpshj-0005Mp-7K; Thu, 28 Mar 2024 16:34:15 +0000
Received: by outflank-mailman (input) for mailman id 699122;
 Thu, 28 Mar 2024 16:34:13 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpshh-0004sj-Df
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 16:34:13 +0000
Received: from mail.actia.se (mail.actia.se [212.181.117.226])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 01c374dd-ed21-11ee-a1ef-f123f15fe8a2;
 Thu, 28 Mar 2024 17:34:11 +0100 (CET)
Received: from S036ANL.actianordic.se (10.12.31.117) by S036ANL.actianordic.se
 (10.12.31.117) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.37; Thu, 28 Mar
 2024 17:34:08 +0100
Received: from S036ANL.actianordic.se ([fe80::e13e:1feb:4ea6:ec69]) by
 S036ANL.actianordic.se ([fe80::e13e:1feb:4ea6:ec69%4]) with mapi id
 15.01.2507.037; Thu, 28 Mar 2024 17:34:08 +0100
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 01c374dd-ed21-11ee-a1ef-f123f15fe8a2
From: John Ernberg 
To: Julien Grall , Stefano Stabellini
	, Bertrand Marquis ,
	"Michal Orzel" , Volodymyr Babchuk
	
CC: Andrew Cooper , George Dunlap
	, Jan Beulich ,
	"xen-devel@lists.xenproject.org" , Peng Fan
	, Jonas Blixt , John Ernberg
	, Julien Grall 
Subject: [PATCH v3 2/3] xen/drivers: imx-lpuart: Replace iMX8QM compatible
 with iMX8QXP
Thread-Topic: [PATCH v3 2/3] xen/drivers: imx-lpuart: Replace iMX8QM
 compatible with iMX8QXP
Thread-Index: AQHagS3BJCg2KK7t2Uy8sRQfsSm0XQ==
Date: Thu, 28 Mar 2024 16:34:08 +0000
Message-ID: <20240328163351.64808-3-john.ernberg@actia.se>
References: <20240328163351.64808-1-john.ernberg@actia.se>
In-Reply-To: <20240328163351.64808-1-john.ernberg@actia.se>
Accept-Language: en-US, sv-SE
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: git-send-email 2.44.0
x-originating-ip: [10.12.12.11]
x-esetresult: clean, is OK
x-esetid: 37303A2958D729556C7D66
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Allow the uart to probe also with iMX8QXP. The ip-block is the same as in
the QM.

Since the fsl,imx8qm-lpuart compatible in Linux exists in name only and is
not used in the driver any iMX8QM device tree that can boot Linux must set
fsl,imx8qxp-lpuart compatible as well as the QM one.

Thus we replace the compatible rather than adding just another one.

Signed-off-by: John Ernberg 
Acked-by: Julien Grall 

---

v3:
 - no changes

v2:
 - Replace the compatible rather than adding to the list (Julien Grall)
 - Reword commit message to reflect the above.
 - Collect Julien's ack
---
 xen/drivers/char/imx-lpuart.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/drivers/char/imx-lpuart.c b/xen/drivers/char/imx-lpuart.c
index 522680a25c..9d0e0871f7 100644
--- a/xen/drivers/char/imx-lpuart.c
+++ b/xen/drivers/char/imx-lpuart.c
@@ -255,7 +255,7 @@ static int __init imx_lpuart_init(struct dt_device_node=
 *dev,
=20
 static const struct dt_device_match imx_lpuart_dt_compat[] __initconst =3D
 {
-    DT_MATCH_COMPATIBLE("fsl,imx8qm-lpuart"),
+    DT_MATCH_COMPATIBLE("fsl,imx8qxp-lpuart"),
     { /* sentinel */ },
 };
=20
--=20
2.44.0


From xen-devel-bounces@lists.xenproject.org Thu Mar 28 16:47:41 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 16:47:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699134.1091732 (Exim 4.92)
	(envelope-from )
	id 1rpsud-0003jP-SI; Thu, 28 Mar 2024 16:47:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699134.1091732; Thu, 28 Mar 2024 16:47:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpsud-0003jI-Ph; Thu, 28 Mar 2024 16:47:35 +0000
Received: by outflank-mailman (input) for mailman id 699134;
 Thu, 28 Mar 2024 16:47:34 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpsuc-0003j9-DC
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 16:47:34 +0000
Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com
 [2a00:1450:4864:20::12b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id def5b1af-ed22-11ee-a1ef-f123f15fe8a2;
 Thu, 28 Mar 2024 17:47:32 +0100 (CET)
Received: by mail-lf1-x12b.google.com with SMTP id
 2adb3069b0e04-515c198e835so1338355e87.3
 for ; Thu, 28 Mar 2024 09:47:32 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 g20-20020aa7c594000000b0056be0d1cd83sm1001487edq.97.2024.03.28.09.47.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 28 Mar 2024 09:47:31 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: def5b1af-ed22-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1711644451; x=1712249251; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=NUSGp53zXS39twOaD8q2rRDIA05UIMipu8a42ZE1VMM=;
        b=HNm4UZdABEBOiaG1sjqrxmt9qTI40fLf+uhUem8YARzE7KNnDruiBkP07wgmLBLR7f
         z5Jo7oV8TZCWomWYJdn/9Ww2HFbuK/CbGYAgkKKlQKEUrTi1oRygAmycLmTpXOxblKHM
         NFhqfqX7h7c6SXGH0do04pT97D2lOUZtZche5i3KVjVVYjTji61ewJclj4ouY5g0Gg+V
         WfkAue54ZhCKoUmUm1DVQ7tOQR13Ocvisc1MFlsddPGYnrc+BjCWJoSefrjG0ksbu3rh
         Q0ndTLK8WFzPBkqw1QhFJM7XrqNFnh07s6ttuv3Dfq8qz1uN4AhRO0XtKPWMxG56LNuc
         wWTQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711644451; x=1712249251;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=NUSGp53zXS39twOaD8q2rRDIA05UIMipu8a42ZE1VMM=;
        b=HHdM5KyHhZFNyRNkeRpNUNOW3j6OI6Yumms1QaplCCC8GwD83cNiHjQTLtWua6pLbZ
         G+IxxU+Jl8aXOtflLuZ0qPemg9fEMwbon4RnszIXc9+kk2fGp3V3a07HgwwX5FEimiUM
         VocfPiEON7ZHO/PvkWG865vaNvorz4oMT1G/jKcu2fpb/krvQ4j2rQ38jiBd2XBk1MaR
         9S4J3NFnjtIcfTsM2trd3kgD4TBcK++e03YG5Ae6yU1amPqY+CWqB5k1eIxoN4Kdkupl
         irazxV8chW7n67rfxLOJIPSYXZSBsJ7pilTqil90TJ9wB3Fu9FhkmkglkhqPQ9J8RsSh
         ytxA==
X-Forwarded-Encrypted: i=1; AJvYcCVWlZt/ZSEcEsWFs2CuQnsO0qjCod0g+hu/+ZnsSpwFC2lTU+6dENGl9CRLEiXEIkh7VC8pFIZg9/qzfJXwkipnNaN74WRdcEm4NyqPEvE=
X-Gm-Message-State: AOJu0Yzh0UGjodG6x9dkAqqKn2wiJfXxgPIxgliapIt/ztOo5c5l39Qu
	C2nljXaT8xxeydVkEl37BG/jxRGHWIPicsWX6U0xAowEihfMcy9UQaoKsJMWpQ==
X-Google-Smtp-Source: AGHT+IExHL+oouEiy81wXQ5PnTIbAhvsq/MsNh7tI21p2SS1p+Owbw6bCD21OJ2pn1jWrZ88i7ymlg==
X-Received: by 2002:a19:9117:0:b0:515:9abe:67c0 with SMTP id t23-20020a199117000000b005159abe67c0mr2212511lfd.58.1711644451634;
        Thu, 28 Mar 2024 09:47:31 -0700 (PDT)
Message-ID: 
Date: Thu, 28 Mar 2024 17:47:30 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 3/4] libelf: Store maximum PHDR p_align
To: Jason Andryuk 
Cc: Andrew Cooper ,
 George Dunlap , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20240327215102.136001-1-jason.andryuk@amd.com>
 <20240327215102.136001-4-jason.andryuk@amd.com>
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20240327215102.136001-4-jason.andryuk@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 27.03.2024 22:51, Jason Andryuk wrote:
> --- a/xen/common/libelf/libelf-loader.c
> +++ b/xen/common/libelf/libelf-loader.c
> @@ -468,6 +468,7 @@ void elf_parse_binary(struct elf_binary *elf)
>  {
>      ELF_HANDLE_DECL(elf_phdr) phdr;
>      uint64_t low = -1, high = 0, paddr, memsz;
> +    uint64_t max_align = 0, palign;
>      unsigned i, count;
>  
>      count = elf_phdr_count(elf);
> @@ -481,17 +482,23 @@ void elf_parse_binary(struct elf_binary *elf)
>              continue;
>          paddr = elf_uval(elf, phdr, p_paddr);
>          memsz = elf_uval(elf, phdr, p_memsz);
> -        elf_msg(elf, "ELF: phdr: paddr=%#" PRIx64 " memsz=%#" PRIx64 "\n",
> -                paddr, memsz);
> +        palign = elf_uval(elf, phdr, p_align);
> +        elf_msg(elf,
> +                "ELF: phdr: paddr=%#" PRIx64 " memsz=%#" PRIx64 " palign=%#" PRIx64 "\n",
> +                paddr, memsz, palign);
>          if ( low > paddr )
>              low = paddr;
>          if ( high < paddr + memsz )
>              high = paddr + memsz;
> +        if ( max_align < palign )
> +            max_align = palign;
>      }
>      elf->pstart = low;
>      elf->pend = high;
> -    elf_msg(elf, "ELF: memory: %#" PRIx64 " -> %#" PRIx64 "\n",
> -            elf->pstart, elf->pend);
> +    elf->palign = max_align;
> +    elf_msg(elf,
> +            "ELF: memory: %#" PRIx64 " -> %#" PRIx64 " align:%#" PRIx64 "\n",
> +            elf->pstart, elf->pend, elf->palign);
>  }

Hmm, it's just this final logging change which I'm a little concerned by:
Having looked at Linux'es phdr, I noticed that the addresses there aren't
necessarily matching the corresponding alignment. Therefore I'm a little
concerned that the output here might raise questions when people see
seemingly inconsistent values in the log. Could you/we at least make it
read like e.g. "align (max): ..."?

Jan


From xen-devel-bounces@lists.xenproject.org Thu Mar 28 17:32:36 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 17:32:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699140.1091742 (Exim 4.92)
	(envelope-from )
	id 1rptbz-000768-3n; Thu, 28 Mar 2024 17:32:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699140.1091742; Thu, 28 Mar 2024 17:32:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rptbz-000761-1H; Thu, 28 Mar 2024 17:32:23 +0000
Received: by outflank-mailman (input) for mailman id 699140;
 Thu, 28 Mar 2024 17:32:21 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rptbx-00075v-Bi
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 17:32:21 +0000
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com
 [2a00:1450:4864:20::534])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 208c8110-ed29-11ee-a1ef-f123f15fe8a2;
 Thu, 28 Mar 2024 18:32:19 +0100 (CET)
Received: by mail-ed1-x534.google.com with SMTP id
 4fb4d7f45d1cf-56890b533aaso1395400a12.3
 for ; Thu, 28 Mar 2024 10:32:19 -0700 (PDT)
Received: from perard.uk.xensource.com (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 dl5-20020a170907944500b00a4e28b2639asm490385ejc.209.2024.03.28.10.32.17
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 28 Mar 2024 10:32:18 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 208c8110-ed29-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1711647139; x=1712251939; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=Pdr6uR7LCJjvjFILccCpwKZPipHQau/u+1nfVS9NK3E=;
        b=j0kMfOxYB2wQ7oCUK7TbO1JtRRoZqGUBfkgAJiuabYM9FlXC4M5kh+jWT3v9qD1DC9
         ZcVZxzmoE/lTd8s2PNIHkhSODFPkwBQQLiFz/NYw4xX+i5rUxhvmo6sWJ6tj/x08qfIW
         TcX6CKTU4J90qFPShkBAmsrkrxQRneDZwI9sE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711647139; x=1712251939;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Pdr6uR7LCJjvjFILccCpwKZPipHQau/u+1nfVS9NK3E=;
        b=o6174CWfW44kvArRHKaMFpgULV6CVWbJDjsCdCWL7yr2fhVbPcQexsUpqfcnFiY+Dl
         8Us8qIH1NWol2FA5A/4C03HDI/Q2ToDUtYHmB22HbSExUPlYnNaGKE6Ey6ja/Z2H+K9G
         HaasJuJJc4YolQD2vFlIpJF49f47x88WBKutj34za3HLdMt+iqhcjrNv7XBisiQ2Q6ev
         EWYw0mPuAZi2KsTSknGDcWdoTslZt3egBNj0uY33agvfedCLXOlUFHKZzFwrDk7oV3qY
         7CxM6+5Q+fY1PCK+2tNixUujJRrVgX/WKW8mCouCdxL9sJsHp8iPbxi1G0YsNiPUf2vK
         K5uA==
X-Gm-Message-State: AOJu0YweEqkJaYCbr9/dECer/tbTB6Hzu+pqQcr1hqmcwIhZznRjlO6U
	naFMQxfm24WC3Sqm5zgH3O53YNwZnyyc9l4CTPoTTd6Ab+p1lD0axnk5CWkST+s=
X-Google-Smtp-Source: AGHT+IEMZYyEjAzpFjP3n8C915PTFs+IX5VRjRi2fjWqFlTHsgbB9hBweHiUxIkE1fO79jlV+/ccpg==
X-Received: by 2002:a17:906:e299:b0:a4e:233b:e470 with SMTP id gg25-20020a170906e29900b00a4e233be470mr1467475ejb.53.1711647138578;
        Thu, 28 Mar 2024 10:32:18 -0700 (PDT)
Date: Thu, 28 Mar 2024 17:32:17 +0000
From: Anthony PERARD 
To: Jiqian Chen 
Cc: xen-devel@lists.xenproject.org, Jan Beulich ,
	Andrew Cooper ,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= ,
	Wei Liu , George Dunlap ,
	Julien Grall ,
	Stefano Stabellini ,
	Juergen Gross ,
	"Daniel P . Smith" ,
	Stewart Hildebrand ,
	Huang Rui 
Subject: Re: [RFC XEN PATCH v6 4/5] libxl: Use gsi instead of irq for mapping
 pirq
Message-ID: <81c6e63f-b493-4bbd-a91a-ec0e04cc69e2@perard>
References: <20240328063402.354496-1-Jiqian.Chen@amd.com>
 <20240328063402.354496-5-Jiqian.Chen@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240328063402.354496-5-Jiqian.Chen@amd.com>

On Thu, Mar 28, 2024 at 02:34:01PM +0800, Jiqian Chen wrote:
> diff --git a/tools/libs/light/libxl_pci.c b/tools/libs/light/libxl_pci.c
> index 96cb4da0794e..2cec83e0b734 100644
> --- a/tools/libs/light/libxl_pci.c
> +++ b/tools/libs/light/libxl_pci.c
> @@ -1478,8 +1478,14 @@ static void pci_add_dm_done(libxl__egc *egc,
>      fclose(f);
>      if (!pci_supp_legacy_irq())
>          goto out_no_irq;
> -    sysfs_path = GCSPRINTF(SYSFS_PCI_DEV"/"PCI_BDF"/irq", pci->domain,
> +    sysfs_path = GCSPRINTF(SYSFS_PCI_DEV"/"PCI_BDF"/gsi", pci->domain,
>                                  pci->bus, pci->dev, pci->func);
> +    r = access(sysfs_path, F_OK);
> +    if (r && errno == ENOENT) {
> +        /* To compitable with old version of kernel, still need to use irq */

There's a typo, this would be "To be compatible ...". Also maybe
something like "Fallback to "/irq" for compatibility with old version of
the kernel." might sound better.

> +        sysfs_path = GCSPRINTF(SYSFS_PCI_DEV"/"PCI_BDF"/irq", pci->domain,
> +                               pci->bus, pci->dev, pci->func);
> +    }
>      f = fopen(sysfs_path, "r");
>      if (f == NULL) {
>          LOGED(ERROR, domainid, "Couldn't open %s", sysfs_path);
> @@ -2229,9 +2235,15 @@ skip_bar:
>      if (!pci_supp_legacy_irq())
>          goto skip_legacy_irq;
>  
> -    sysfs_path = GCSPRINTF(SYSFS_PCI_DEV"/"PCI_BDF"/irq", pci->domain,
> +    sysfs_path = GCSPRINTF(SYSFS_PCI_DEV"/"PCI_BDF"/gsi", pci->domain,
>                             pci->bus, pci->dev, pci->func);
>  
> +    rc = access(sysfs_path, F_OK);

Please, don't use the variable `rc` here, this one is reserved for libxl
error/return code in libxl. Introduce `int r` instead.

> +    if (rc && errno == ENOENT) {
> +        /* To compitable with old version of kernel, still need to use irq */
> +        sysfs_path = GCSPRINTF(SYSFS_PCI_DEV"/"PCI_BDF"/irq", pci->domain,
> +                               pci->bus, pci->dev, pci->func);
> +    }
>      f = fopen(sysfs_path, "r");
>      if (f == NULL) {
>          LOGED(ERROR, domid, "Couldn't open %s", sysfs_path);

With those two things fixed: Reviewed-by: Anthony PERARD 

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Thu Mar 28 17:54:16 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 17:54:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699143.1091753 (Exim 4.92)
	(envelope-from )
	id 1rptx3-0007OQ-R7; Thu, 28 Mar 2024 17:54:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699143.1091753; Thu, 28 Mar 2024 17:54:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rptx3-0007OJ-Oa; Thu, 28 Mar 2024 17:54:09 +0000
Received: by outflank-mailman (input) for mailman id 699143;
 Thu, 28 Mar 2024 17:54:08 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rptx2-0007OD-Os
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 17:54:08 +0000
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com
 [2a00:1450:4864:20::331])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2bcc8edd-ed2c-11ee-a1ef-f123f15fe8a2;
 Thu, 28 Mar 2024 18:54:06 +0100 (CET)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-414866f92beso8684385e9.3
 for ; Thu, 28 Mar 2024 10:54:06 -0700 (PDT)
Received: from perard.uk.xensource.com (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 h16-20020adff4d0000000b0033e72e104c5sm2285714wrp.34.2024.03.28.10.54.05
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 28 Mar 2024 10:54:05 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2bcc8edd-ed2c-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1711648446; x=1712253246; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=lvbGGP481GShGw2Ixv/G+6iddI9tX03SDqf7LmF6gpY=;
        b=MUUiBEs1MsmXqznprxvQ74MGRSnURDWT0AnjIzeK+dpjCPNrgvaDSFBmMVvi2fToJ/
         GAQHjO+ix3Z4vt/8CbqlfRCdGJdlLMiMqqld9yjIJSB4tpHLrl50ztF612OroXpX+MYd
         zT+6TfpDQKBWiqtOGUCoxu+GFUX2hqpMupwjc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711648446; x=1712253246;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=lvbGGP481GShGw2Ixv/G+6iddI9tX03SDqf7LmF6gpY=;
        b=O4k0ltlE38pyOOU+k6dunsuVSFZIecMSLCyqEKmwJI8o80/JP43gP3CyaCBmwLR79z
         5D1yXKSb49DFbg5TU0+zOzl5O18VNaLllK5fxOAqpl0VtCArETZtMY5efwxobngdhzzj
         Ag6W8X5BC2OpsnOjM9l0aIQ/1nRYF4O2BxPMSIKUZc+Q3X0INExxxev99hKIYlopRJyb
         5DLg2PQ6UmOOfkdSChI2X43C6SnNNq1d3zRaTBeprnLT0sLmBOCeHZDo9VY1NLvfMo7Y
         R1sfmLU5EtYILbnFdYCY1xJQPNcln5wzZ4OLgaO+w5IGDc0uC4XVKS1jhvBCr0MzmU7B
         hrXQ==
X-Gm-Message-State: AOJu0YwaxPIU3z7X262/Ggokeyfgr724NRNDiyXc+fpQjRmFSwZ678qH
	5PrK6W4aK4VziTP+NKwbZASIFvaVv/v2HoXRd4wdIwvk52kwHjWeJX9JtzcMxT7BB13x2dyfP10
	I
X-Google-Smtp-Source: AGHT+IFlupp7g84BElUQl+bJ8RjExf9x0KikAwip0H3Ekf+iWdz4UPk703nfkT3KCDtZUKDYVHSlJg==
X-Received: by 2002:a5d:4cc8:0:b0:33e:c0a9:79c with SMTP id c8-20020a5d4cc8000000b0033ec0a9079cmr2654116wrt.23.1711648445764;
        Thu, 28 Mar 2024 10:54:05 -0700 (PDT)
Date: Thu, 28 Mar 2024 17:54:04 +0000
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne 
Subject: Re: [OSSTEST PATCH 00/36] Switch to Debian Bookworm
Message-ID: <93b8a3e8-2866-42ca-9132-1527d82928e9@perard>
References: <20240318165545.3898-1-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240318165545.3898-1-anthony.perard@citrix.com>

On Mon, Mar 18, 2024 at 04:55:09PM +0000, Anthony PERARD wrote:
> I intend to push this series in two waves.
> 
> First, push up to commit "Temporally switch "qemu-mainline" branch to
> Bookworm". This is to test that osstest still works fine if we need to use
> "buster" for a branch. Also upstream QEMU doesn't build on buster anymore, so
> I've included a commit to use bookworm for it.
> 
> Second, push the remaning two patches, at least a week later, which will switch
> the default debian suite.
> 
> Anthony PERARD (36):
>   production-config: Add bookworm debian install media filename
>   ts-xen-build-prep: Only force git protocol v2 on buster
>   mgi-common: Fix fetch_debian_package error message
>   mg-debian-installer-update: Download non-free firmware from new repo.
>   ts-host-install: fix ntp.conf path on bookworm
>   ts-host-install: fix ntp server setting
>   ts-host-install: Restart ntp service
>   preseed_create: Use new "d-i grub-installer/update-nvram" for UEFI
>     installation
>   preseed_create: osstest-erase-other-disks: workaround creating
>     /dev/sdXD files
>   preseed_create: Workaround fail grub-install on arndale
>   ts-host-install,preseed_create: Do lvm vgextend at install time
>   di_installcmdline_core: Add link_wait_timeout to install cmdline
>   Disable persistent net generator on Bookworm
>   preseed_base, ts-host-install: Change NIC NamePolicy to "mac"
>   ts-xen-build-prep: Change package selection for Bookworm
>   bl_getmenu_open: Read grub.cfg as root
>   target_editfile: Use the same user to retrieve and send
>   ts-xen-install: remove "libc6-xen" package installation
>   overlay-bookworm: Import grub's 20_linux_xen from Debian Bookworm
>   overlay-bookworm: 20_linux_xen: Fix XSM entries generation
>   ts-xtf-install: Install python symlink
>   setupboot_grub2: Parse arm64 uefi grub verbes
>   bookworm: Extend ARM clock workaround
>   ts-nested-setup, setup l1 lvm volume groupe in guest
>   ts-leak-check: add new name for udevd workers
>   ts-debian-hvm-install: Allow udev failure in install media
>   ts-debian-fixup: Fix nic names for bookworm
>   ts-debian-install: keep avoiding to use pygrub
>   ts-debian-hvm-install: Increase min guest ram size
>   bookworm: Extend guest bootloader workaround
>   ts-debian-*-install: Replace dots in hostnames by dashs
>   ts-xen-install: Fix bridge setup, ask to copy MAC addr
>   make-flight: Keep using buster for L2 guest in nested tests

I've pushed up to here. I'll push the last two patches later.

>   Temporally switch "qemu-mainline" branch to Bookworm

And I'll drop this one.

>   Switch to Debian Bookworm as default suite
>   make-hosts-flight: default to bookworm


Cheers,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Thu Mar 28 17:58:22 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 17:58:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699146.1091763 (Exim 4.92)
	(envelope-from )
	id 1rpu17-0000GE-Bl; Thu, 28 Mar 2024 17:58:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699146.1091763; Thu, 28 Mar 2024 17:58:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpu17-0000G2-8Z; Thu, 28 Mar 2024 17:58:21 +0000
Received: by outflank-mailman (input) for mailman id 699146;
 Thu, 28 Mar 2024 17:58:20 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1rpu16-0000Fw-07
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 17:58:20 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpu15-0008WM-Bi; Thu, 28 Mar 2024 17:58:19 +0000
Received: from gw1.octic.net ([88.97.20.152] helo=[10.0.1.240])
 by xenbits.xenproject.org with esmtpsa
 (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92)
 (envelope-from )
 id 1rpu15-00033W-3f; Thu, 28 Mar 2024 17:58:19 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=0hm1AqLZSGL8zb0pM9llSwhKywcrruBNnAT3mJmXX78=; b=22KQHmmeumbzSFToS0LNwzlknK
	xysdFjSF/cpkngTr+G5Tsr1hiooZKrGR6a8IsnB0Y1PnO4/1YXjw2dR18fc+wM5oZBSNVjiL7deBZ
	0Ox4zq/6id/RTaFfGrN0qD+zQX27TtuTyODJ3NVnPz4haD0MomKcMJ/zbhvUVCFjaJCA=;
Message-ID: 
Date: Thu, 28 Mar 2024 17:58:17 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 3/6] xen/arm: ffa: separate memory sharing routines
Content-Language: en-GB
To: Bertrand Marquis ,
 Jens Wiklander 
Cc: Xen-devel ,
 "patches@linaro.org" ,
 Volodymyr Babchuk ,
 Stefano Stabellini ,
 Michal Orzel 
References: <20240325093904.3466092-1-jens.wiklander@linaro.org>
 <20240325093904.3466092-4-jens.wiklander@linaro.org>
 
From: Julien Grall 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Bertrand,

On 27/03/2024 13:40, Bertrand Marquis wrote:
> Hi Jens,
> 
>> On 25 Mar 2024, at 10:39, Jens Wiklander  wrote:
>>
>> Move memory sharing routines into a separate file for easier navigation
>> in the source code.
>>
>> Add ffa_shm_domain_destroy() to isolate the ffa_shm things in
>> ffa_domain_teardown_continue().
>>
>> Signed-off-by: Jens Wiklander 
> 
> With the copyright date mentioned after fixed (which can be done on commit):
> Reviewed-by: Bertrand Marquis 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 18:05:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699149.1091772 (Exim 4.92)
	(envelope-from )
	id 1rpu84-0004Ry-1x; Thu, 28 Mar 2024 18:05:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699149.1091772; Thu, 28 Mar 2024 18:05:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpu83-0004Rr-VL; Thu, 28 Mar 2024 18:05:31 +0000
Received: by outflank-mailman (input) for mailman id 699149;
 Thu, 28 Mar 2024 18:05:30 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpu82-0004Rj-8B
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 18:05:30 +0000
Received: from mail-il1-x135.google.com (mail-il1-x135.google.com
 [2607:f8b0:4864:20::135])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c0a7b677-ed2d-11ee-a1ef-f123f15fe8a2;
 Thu, 28 Mar 2024 19:05:26 +0100 (CET)
Received: by mail-il1-x135.google.com with SMTP id
 e9e14a558f8ab-36898a6f561so4843715ab.2
 for ; Thu, 28 Mar 2024 11:05:26 -0700 (PDT)
Received: from google.com ([2620:15c:9d:2:493e:82a3:49f9:d88])
 by smtp.gmail.com with ESMTPSA id
 a185-20020a6366c2000000b005dc88b232a5sm1593248pgc.26.2024.03.28.11.05.24
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 28 Mar 2024 11:05:24 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c0a7b677-ed2d-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1711649125; x=1712253925; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=K/sacnz72CwRH0otyTGzert8z0sn/i0tise2f/EaGiQ=;
        b=C6VWphScCxQrRz6/PuvBn93Rsf674RXp9HVRZ5n1UVYO/N/yk5q6wxt//+pfzztCNA
         H0tU9rBH+oihzcymaHXXZZcE0vP2gDXnpn8IGF6siz7po2Jov0Mpi9OcLahJa3t1hYcj
         D8fA+ovuv4WTa72XFqntDMazCGRnBBvqo+d5G5NS8fL+Ws2VeAVAcmB1YP2lZOGbKdh4
         7ifJBY80uo2CNgpnfsww9v72nSVoeF0kT5VPjfjaE4pIDr127hRxBG5GEywHuRQdXdHZ
         TyweCNTPFQuRw/VDjsRq+NGRUDbSO+xQ4R1cGTxQtjjVOFrbjT6yvRxrW8b3OQBI/1D8
         cZzg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711649125; x=1712253925;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=K/sacnz72CwRH0otyTGzert8z0sn/i0tise2f/EaGiQ=;
        b=Y1vkf6pS5kEJU6S+IIb+/aRDEYqgGwa+DmE759FZ89nWJxMnEPNHtimAzpCGFDwb7c
         nTxGJvcjsPpI+VoV0o60ok9O3HCHI35uDCDapv/fpDqyBpokZr1sxDgZ6S4oHRrikAVk
         be+MNdC6FHlAg5cj2ZmI0Q8YAvzdJVY42zzuXktdtDSBtO/9au7rxvIG6Axh3MAUMTRs
         MYTWPzF5TqVB2xVP5PgzBB/I3jYaGmoMZbFoSw++M/PfRqr2SQ3GBPQ1TL/y1rSL6MjA
         2P6oR79DJ4JJi7C4gjUnXnnS+DwkGn75T4vAvqez5413AbbqjWRPONnReNPMOpPEt0wj
         xO9A==
X-Forwarded-Encrypted: i=1; AJvYcCULcc2aDzf5E0vxWbeEqyN5DxvdWla4Iy7lNj7WCBJONyHKlAPDrDMjTzipt+MH9zg3DWaRCytzph8a/Czpg/hBwkI1TXm7XAhLAz72lO4=
X-Gm-Message-State: AOJu0YwKJMOEkmpYKOGmLIXbj7uobT5tZcqoOJR03E4v2M+i+VfTwgqh
	uTbxTg2IbopFob2HPddG8Lp/CQr14Vcn5thBUpctjUnbRbHsO4Io
X-Google-Smtp-Source: AGHT+IFxenVy3Vpe40qXySr/FIX8Cmzlhc9MA4Bak20UWKfT1c1La/2Q3sNRmDFpNQjvs7U7sVA40g==
X-Received: by 2002:a92:d486:0:b0:368:a474:4410 with SMTP id p6-20020a92d486000000b00368a4744410mr4494143ilg.2.1711649124902;
        Thu, 28 Mar 2024 11:05:24 -0700 (PDT)
Date: Thu, 28 Mar 2024 11:05:22 -0700
From: Dmitry Torokhov 
To: Jason Andryuk 
Cc: linux-kernel@vger.kernel.org, Phillip Susi ,
	stable@vger.kernel.org,
	Mattijs Korpershoek ,
	linux-input@vger.kernel.org,
	xen-devel ,
	Juergen Gross 
Subject: Re: [PATCH v3] Input: xen-kbdfront - drop keys to shrink modalias
Message-ID: 
References: <20231011193444.81254-1-jandryuk@gmail.com>
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 

Hi Jason,

On Wed, Mar 20, 2024 at 01:42:27PM -0400, Jason Andryuk wrote:
> Hi Dmitry,
> 
> Do you have any feedback, or can you pick up this patch?  It solves a
> real issue affecting udev, which crashes the Debian installer and
> breaks the mouse for Gnome.
> 
> Or would you be okay if this patch went in via the Xen tree?

I'd rather not. Could you please ping me in 2 weeks on this. I promise
we find a solution before the next release.

Thanks.

-- 
Dmitry


From xen-devel-bounces@lists.xenproject.org Thu Mar 28 18:21:15 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 18:21:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699153.1091782 (Exim 4.92)
	(envelope-from )
	id 1rpuNB-0003CQ-Bm; Thu, 28 Mar 2024 18:21:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699153.1091782; Thu, 28 Mar 2024 18:21:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpuNB-0003CJ-8o; Thu, 28 Mar 2024 18:21:09 +0000
Received: by outflank-mailman (input) for mailman id 699153;
 Thu, 28 Mar 2024 18:21:07 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1rpuN9-0003CB-GO
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 18:21:07 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpuN6-0000dJ-9o; Thu, 28 Mar 2024 18:21:04 +0000
Received: from gw1.octic.net ([88.97.20.152] helo=[10.0.1.240])
 by xenbits.xenproject.org with esmtpsa
 (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92)
 (envelope-from )
 id 1rpuN5-0004YG-VW; Thu, 28 Mar 2024 18:21:04 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
	References:Cc:To:From:Subject:MIME-Version:Date:Message-ID;
	bh=LVwuqNbWmNIdQGMsknjb9crp53/xlgANmbKy0dpt2+o=; b=GofVg9DJkdDTqenEzPzmTvglVJ
	IDAhhcL/oQEbB6+43dsBnQHwoMso6uDz+096ZVxX3xVp9I5CWRysH4Aj/54tPNjAcpiMYDcyU+9tD
	CuYZ9vp5QMb40wI1vX4LGYjuUtue2E8d3wLm9UjBVzaYBIeRmwoTVXQ/WYcRtlDFgidA=;
Message-ID: 
Date: Thu, 28 Mar 2024 18:21:02 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 08/14] xen/page_alloc: introduce preserved page flags
 macro
Content-Language: en-GB
From: Julien Grall 
To: Jan Beulich ,
 Carlo Nonato 
Cc: Andrew Cooper ,
 George Dunlap ,
 Stefano Stabellini , Wei Liu ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20240315105902.160047-1-carlo.nonato@minervasys.tech>
 <20240315105902.160047-9-carlo.nonato@minervasys.tech>
 <3f615066-a792-493f-ba33-7667a6557c23@xen.org>
 <9e0f7ff3-5457-41e4-a1e4-bf75804fb900@xen.org>
 <255be735-f9fe-4e39-a24e-2f6aff91acc5@suse.com>
 
 <3427132d-9458-4447-b667-d2ef3c1f0569@suse.com>
 
 
 
 
 <54156e94-3630-49b1-8a22-5cd4206d565f@xen.org>
 
 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi,

Replying to myself.

On 27/03/2024 13:48, Julien Grall wrote:
> On 27/03/2024 13:38, Jan Beulich wrote:
>> On 27.03.2024 14:28, Julien Grall wrote:
>>> Hi Carlo,
>>>
>>> On 27/03/2024 11:10, Carlo Nonato wrote:
>>>> Hi guys,
>>>>
>>>>> Question is: How would you justify such a change? IOW I'm not 
>>>>> convinced
>>>>> (yet) this wants doing there.
>>>>
>>>> You mean in this series?
>>>>
>>>>> Looking at the code, the flag is originally set in
>>>>> alloc_domheap_pages(). So I guess it would make sense to do it in
>>>>> free_domheap_pages().
>>>>
>>>> We don't hold the heap_lock there.
>>> Regardless of the safety question (I will answer below), count_info is
>>> not meant to be protected by heap_lock. The lock is protecting the heap
>>> and ensure we are not corrupting them when there are concurrent call to
>>> free_heap_pages().
>>>
>>>   > Is it safe to change count_info without it?
>>>
>>> count_info is meant to be accessed locklessly. The flag PGC_extra cannot
>>> be set/clear concurrently because you can't allocate a page that has not
>>> yet been freed.
>>>
>>> So it would be fine to use clear_bit(..., ...);
>>
>> Actually we hardly ever use clear_bit() on count_info. Normally we use
>> ordinary C operators.
> 
> I knew you would say that. I am not convince it is safe to always using 
> count_info without any atomic operations. But I never got around to 
> check all them.
> 
>> Atomic (and otherwise lockless) updates are useful
>> only if done like this everywhere.
> 
> You are right. But starting to use the bitops is not going to hurt 
> anyone (other than maybe performance, but once we convert all of them, 
> then this will become moot). In fact, it helps start to slowly move 
> towards the aim to have count_info safe.

I think I managed to convince myself that, count_info |= ... is fine in 
this case and no locking is necessary.

Cheers,

-- 
Julien Grall


From xen-devel-bounces@lists.xenproject.org Thu Mar 28 18:46:03 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 18:46:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699161.1091796 (Exim 4.92)
	(envelope-from )
	id 1rpul2-0003z6-8y; Thu, 28 Mar 2024 18:45:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699161.1091796; Thu, 28 Mar 2024 18:45:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpul2-0003yz-5q; Thu, 28 Mar 2024 18:45:48 +0000
Received: by outflank-mailman (input) for mailman id 699161;
 Thu, 28 Mar 2024 18:45:46 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpul0-0003xa-DF
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 18:45:46 +0000
Received: from zero.eik.bme.hu (zero.eik.bme.hu [152.66.115.2])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 61eff8e7-ed33-11ee-a1ef-f123f15fe8a2;
 Thu, 28 Mar 2024 19:45:44 +0100 (CET)
Received: from zero.eik.bme.hu (localhost [127.0.0.1])
 by zero.eik.bme.hu (Postfix) with ESMTP id E86084E6061;
 Thu, 28 Mar 2024 19:45:42 +0100 (CET)
Received: from zero.eik.bme.hu ([127.0.0.1])
 by zero.eik.bme.hu (zero.eik.bme.hu [127.0.0.1]) (amavisd-new, port 10028)
 with ESMTP id E4w3I916cRnf; Thu, 28 Mar 2024 19:45:40 +0100 (CET)
Received: by zero.eik.bme.hu (Postfix, from userid 432)
 id F0B8B4E605E; Thu, 28 Mar 2024 19:45:40 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
 by zero.eik.bme.hu (Postfix) with ESMTP id EE2307456B4;
 Thu, 28 Mar 2024 19:45:40 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 61eff8e7-ed33-11ee-a1ef-f123f15fe8a2
X-Virus-Scanned: amavisd-new at eik.bme.hu
Date: Thu, 28 Mar 2024 19:45:40 +0100 (CET)
From: BALATON Zoltan 
To: =?ISO-8859-15?Q?Philippe_Mathieu-Daud=E9?= 
cc: qemu-devel@nongnu.org, Richard Henderson , 
    Eduardo Habkost , 
    Stefano Stabellini , 
    xen-devel@lists.xenproject.org, Bernhard Beschow , 
    Thomas Huth , 
    Marcel Apfelbaum , 
    "Michael S. Tsirkin" , Paolo Bonzini , 
    Igor Mammedov , 
    Anthony Perard , 
    Ani Sinha 
Subject: Re: [RFC PATCH-for-9.1 09/29] hw/i386/pc: Pass PCMachineState argument
 to acpi_setup()
In-Reply-To: <20240328155439.58719-10-philmd@linaro.org>
Message-ID: <04b9fcde-31f1-dfa8-8c4e-a666d0d873d8@eik.bme.hu>
References: <20240328155439.58719-1-philmd@linaro.org> <20240328155439.58719-10-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="3866299591-534400419-1711651540=:36462"

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--3866299591-534400419-1711651540=:36462
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT

On Thu, 28 Mar 2024, Philippe Mathieu-Daudé wrote:
> acpi_setup() caller knows about the machine state, so pass
> it as argument to avoid a qdev_get_machine() call.
>
> We already resolved X86_MACHINE(pcms) as 'x86ms' so use the
> latter.
>
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
> hw/i386/acpi-build.h | 3 ++-
> hw/i386/acpi-build.c | 5 ++---
> hw/i386/pc.c         | 2 +-
> 3 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/hw/i386/acpi-build.h b/hw/i386/acpi-build.h
> index 0dce155c8c..31de5bddbd 100644
> --- a/hw/i386/acpi-build.h
> +++ b/hw/i386/acpi-build.h
> @@ -2,6 +2,7 @@
> #ifndef HW_I386_ACPI_BUILD_H
> #define HW_I386_ACPI_BUILD_H
> #include "hw/acpi/acpi-defs.h"
> +#include "hw/i386/pc.h"
>
> extern const struct AcpiGenericAddress x86_nvdimm_acpi_dsmio;
>
> @@ -9,7 +10,7 @@ extern const struct AcpiGenericAddress x86_nvdimm_acpi_dsmio;
> #define ACPI_PCIHP_SEJ_BASE 0x8
> #define ACPI_PCIHP_BNMR_BASE 0x10
>
> -void acpi_setup(void);
> +void acpi_setup(PCMachineState *pcms);

This is changed to PcPciMachineState * in a following patch so can't you 
already introduce it here to avoid some churn?

Regards,
BALATON Zoltan

> Object *acpi_get_i386_pci_host(void);
>
> #endif
> diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
> index 6e8e32e5d2..e702d5e9d2 100644
> --- a/hw/i386/acpi-build.c
> +++ b/hw/i386/acpi-build.c
> @@ -2749,9 +2749,8 @@ static const VMStateDescription vmstate_acpi_build = {
>     },
> };
>
> -void acpi_setup(void)
> +void acpi_setup(PCMachineState *pcms)
> {
> -    PCMachineState *pcms = PC_MACHINE(qdev_get_machine());
>     X86MachineState *x86ms = X86_MACHINE(pcms);
>     AcpiBuildTables tables;
>     AcpiBuildState *build_state;
> @@ -2771,7 +2770,7 @@ void acpi_setup(void)
>         return;
>     }
>
> -    if (!x86_machine_is_acpi_enabled(X86_MACHINE(pcms))) {
> +    if (!x86_machine_is_acpi_enabled(x86ms)) {
>         ACPI_BUILD_DPRINTF("ACPI disabled. Bailing out.\n");
>         return;
>     }
> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> index 6d87d1d4c2..dfc0247bb6 100644
> --- a/hw/i386/pc.c
> +++ b/hw/i386/pc.c
> @@ -601,7 +601,7 @@ void pc_machine_done(Notifier *notifier, void *data)
>     /* set the number of CPUs */
>     x86_rtc_set_cpus_count(x86ms->rtc, x86ms->boot_cpus);
>
> -    acpi_setup();
> +    acpi_setup(pcms);
>     if (x86ms->fw_cfg) {
>         fw_cfg_build_smbios(pcms, x86ms->fw_cfg, pcms->smbios_entry_point_type);
>         fw_cfg_build_feature_control(MACHINE(pcms), x86ms->fw_cfg);
>
--3866299591-534400419-1711651540=:36462--


From xen-devel-bounces@lists.xenproject.org Thu Mar 28 18:50:08 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 18:50:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699163.1091805 (Exim 4.92)
	(envelope-from )
	id 1rpupD-0006LX-OQ; Thu, 28 Mar 2024 18:50:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699163.1091805; Thu, 28 Mar 2024 18:50:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpupD-0006L1-Lu; Thu, 28 Mar 2024 18:50:07 +0000
Received: by outflank-mailman (input) for mailman id 699163;
 Thu, 28 Mar 2024 18:50:06 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpupC-0006Hy-LZ
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 18:50:06 +0000
Received: from zero.eik.bme.hu (zero.eik.bme.hu [2001:738:2001:2001::2001])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id fd163e97-ed33-11ee-a1ef-f123f15fe8a2;
 Thu, 28 Mar 2024 19:50:04 +0100 (CET)
Received: from zero.eik.bme.hu (localhost [127.0.0.1])
 by zero.eik.bme.hu (Postfix) with ESMTP id CE83F4E6060;
 Thu, 28 Mar 2024 19:50:03 +0100 (CET)
Received: from zero.eik.bme.hu ([127.0.0.1])
 by zero.eik.bme.hu (zero.eik.bme.hu [127.0.0.1]) (amavisd-new, port 10028)
 with ESMTP id 0upp1RZ_X_JD; Thu, 28 Mar 2024 19:50:01 +0100 (CET)
Received: by zero.eik.bme.hu (Postfix, from userid 432)
 id CC71F4E605E; Thu, 28 Mar 2024 19:50:01 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
 by zero.eik.bme.hu (Postfix) with ESMTP id C93987456B4;
 Thu, 28 Mar 2024 19:50:01 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: fd163e97-ed33-11ee-a1ef-f123f15fe8a2
X-Virus-Scanned: amavisd-new at eik.bme.hu
Date: Thu, 28 Mar 2024 19:50:01 +0100 (CET)
From: BALATON Zoltan 
To: =?ISO-8859-15?Q?Philippe_Mathieu-Daud=E9?= 
cc: qemu-devel@nongnu.org, Richard Henderson , 
    Eduardo Habkost , 
    Stefano Stabellini , 
    xen-devel@lists.xenproject.org, Bernhard Beschow , 
    Thomas Huth , 
    Marcel Apfelbaum , 
    "Michael S. Tsirkin" , Paolo Bonzini , 
    Igor Mammedov , 
    Anthony Perard , 
    Ani Sinha 
Subject: Re: [RFC PATCH-for-9.1 13/29] hw/i386/pc: Remove non-PCI code from
 pc_system_firmware_init()
In-Reply-To: <20240328155439.58719-14-philmd@linaro.org>
Message-ID: <1578f958-8464-f124-3a40-464f932161c4@eik.bme.hu>
References: <20240328155439.58719-1-philmd@linaro.org> <20240328155439.58719-14-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="3866299591-274745813-1711651801=:36462"

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--3866299591-274745813-1711651801=:36462
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT

On Thu, 28 Mar 2024, Philippe Mathieu-Daudé wrote:
> x86_bios_rom_init() is the single non-PCI-machine call
> from pc_system_firmware_init(). Extract it to the caller.
>
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
> hw/i386/pc.c       | 6 +++++-
> hw/i386/pc_sysfw.c | 5 +----
> 2 files changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> index f184808e3e..5b96daa414 100644
> --- a/hw/i386/pc.c
> +++ b/hw/i386/pc.c
> @@ -956,7 +956,11 @@ void pc_memory_init(PCMachineState *pcms,
>     }
>
>     /* Initialize PC system firmware */
> -    pc_system_firmware_init(pcms, rom_memory);
> +    if (pci_enabled) {
> +        pc_system_firmware_init(pcms, rom_memory);
> +    } else {
> +        x86_bios_rom_init(machine, "bios.bin", rom_memory, true);
> +    }
>
>     option_rom_mr = g_malloc(sizeof(*option_rom_mr));
>     memory_region_init_ram(option_rom_mr, NULL, "pc.rom", PC_ROM_SIZE,
> diff --git a/hw/i386/pc_sysfw.c b/hw/i386/pc_sysfw.c
> index 862a082b0a..541dcaef71 100644
> --- a/hw/i386/pc_sysfw.c
> +++ b/hw/i386/pc_sysfw.c
> @@ -202,10 +202,7 @@ void pc_system_firmware_init(PCMachineState *pcms,

Maybe also rename to pc_pci_firmware_init() to make  it clear this is only 
for PCI PC machine now?

Regards,
BALATON Zoltan

>     int i;
>     BlockBackend *pflash_blk[ARRAY_SIZE(pcms->flash)];
>
> -    if (!pc_machine_is_pci_enabled(pcms)) {
> -        x86_bios_rom_init(MACHINE(pcms), "bios.bin", rom_memory, true);
> -        return;
> -    }
> +    assert(pc_machine_is_pci_enabled(pcms));
>
>     /* Map legacy -drive if=pflash to machine properties */
>     for (i = 0; i < ARRAY_SIZE(pcms->flash); i++) {
>
--3866299591-274745813-1711651801=:36462--


From xen-devel-bounces@lists.xenproject.org Thu Mar 28 18:52:27 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 18:52:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699165.1091817 (Exim 4.92)
	(envelope-from )
	id 1rpurP-0007EU-6n; Thu, 28 Mar 2024 18:52:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699165.1091817; Thu, 28 Mar 2024 18:52:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpurP-0007EN-1D; Thu, 28 Mar 2024 18:52:23 +0000
Received: by outflank-mailman (input) for mailman id 699165;
 Thu, 28 Mar 2024 18:52:21 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpurN-0007Cq-OE
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 18:52:21 +0000
Received: from zero.eik.bme.hu (zero.eik.bme.hu [152.66.115.2])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4dec7b6b-ed34-11ee-a1ef-f123f15fe8a2;
 Thu, 28 Mar 2024 19:52:19 +0100 (CET)
Received: from zero.eik.bme.hu (localhost [127.0.0.1])
 by zero.eik.bme.hu (Postfix) with ESMTP id 134EF4E605E;
 Thu, 28 Mar 2024 19:52:19 +0100 (CET)
Received: from zero.eik.bme.hu ([127.0.0.1])
 by zero.eik.bme.hu (zero.eik.bme.hu [127.0.0.1]) (amavisd-new, port 10028)
 with ESMTP id wubAWF9IEmeT; Thu, 28 Mar 2024 19:52:17 +0100 (CET)
Received: by zero.eik.bme.hu (Postfix, from userid 432)
 id 1E0994E6061; Thu, 28 Mar 2024 19:52:17 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
 by zero.eik.bme.hu (Postfix) with ESMTP id 1C0297456B4;
 Thu, 28 Mar 2024 19:52:17 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4dec7b6b-ed34-11ee-a1ef-f123f15fe8a2
X-Virus-Scanned: amavisd-new at eik.bme.hu
Date: Thu, 28 Mar 2024 19:52:17 +0100 (CET)
From: BALATON Zoltan 
To: =?ISO-8859-15?Q?Philippe_Mathieu-Daud=E9?= 
cc: qemu-devel@nongnu.org, Richard Henderson , 
    Eduardo Habkost , 
    Stefano Stabellini , 
    xen-devel@lists.xenproject.org, Bernhard Beschow , 
    Thomas Huth , 
    Marcel Apfelbaum , 
    "Michael S. Tsirkin" , Paolo Bonzini , 
    Igor Mammedov , 
    Anthony Perard , 
    Ani Sinha 
Subject: Re: [RFC PATCH-for-9.1 14/29] hw/i386/pc: Move pc_system_flash_create()
 to pc_pci_machine_initfn()
In-Reply-To: <20240328155439.58719-15-philmd@linaro.org>
Message-ID: <2725fdba-465e-7f74-c354-57b88994a2ed@eik.bme.hu>
References: <20240328155439.58719-1-philmd@linaro.org> <20240328155439.58719-15-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="3866299591-671172952-1711651937=:36462"

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--3866299591-671172952-1711651937=:36462
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT

On Thu, 28 Mar 2024, Philippe Mathieu-Daudé wrote:
> pc_system_flash_create() is only useful for PCI-based machines.
> Move the call to the PCI-based init() handler.
>
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
> hw/i386/pc.c       |  2 +-
> hw/i386/pc_sysfw.c | 10 ++++------
> 2 files changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> index 5b96daa414..33724791fd 100644
> --- a/hw/i386/pc.c
> +++ b/hw/i386/pc.c
> @@ -1679,7 +1679,6 @@ static void pc_machine_initfn(Object *obj)
>     pcms->fd_bootchk = true;
>     pcms->default_bus_bypass_iommu = false;
>
> -    pc_system_flash_create(pcms);
>     pcms->pcspk = isa_new(TYPE_PC_SPEAKER);
>     object_property_add_alias(OBJECT(pcms), "pcspk-audiodev",
>                               OBJECT(pcms->pcspk), "audiodev");
> @@ -1694,6 +1693,7 @@ static void pc_pci_machine_initfn(Object *obj)
>
>     ppms->acpi_build_enabled = true;
>
> +    pc_system_flash_create(PC_MACHINE(obj));
>     cxl_machine_init(obj, &ppms->cxl_devices_state);
>
>     ppms->machine_done.notify = pc_pci_machine_done;
> diff --git a/hw/i386/pc_sysfw.c b/hw/i386/pc_sysfw.c
> index 541dcaef71..167ff24fcb 100644
> --- a/hw/i386/pc_sysfw.c
> +++ b/hw/i386/pc_sysfw.c
> @@ -93,12 +93,10 @@ static PFlashCFI01 *pc_pflash_create(PCMachineState *pcms,
>
> void pc_system_flash_create(PCMachineState *pcms)
> {
> -    if (pc_machine_is_pci_enabled(pcms)) {
> -        pcms->flash[0] = pc_pflash_create(pcms, "system.flash0",
> -                                          "pflash0");
> -        pcms->flash[1] = pc_pflash_create(pcms, "system.flash1",
> -                                          "pflash1");
> -    }
> +    assert(pc_machine_is_pci_enabled(pcms));
> +
> +    pcms->flash[0] = pc_pflash_create(pcms, "system.flash0", "pflash0");
> +    pcms->flash[1] = pc_pflash_create(pcms, "system.flash1", "pflash1");
> }

This could just be inlined as it's called once, then no need for assert 
and a separate function.

Regards,
BALATON Zoltan

>
> void pc_system_flash_cleanup_unused(PCMachineState *pcms)
>
--3866299591-671172952-1711651937=:36462--


From xen-devel-bounces@lists.xenproject.org Thu Mar 28 19:56:01 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 19:56:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699171.1091826 (Exim 4.92)
	(envelope-from )
	id 1rpvqk-0001AI-JF; Thu, 28 Mar 2024 19:55:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699171.1091826; Thu, 28 Mar 2024 19:55:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpvqk-0001AB-Fv; Thu, 28 Mar 2024 19:55:46 +0000
Received: by outflank-mailman (input) for mailman id 699171;
 Thu, 28 Mar 2024 19:55:45 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpvqj-0001A5-FS
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 19:55:45 +0000
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com
 [2a00:1450:4864:20::335])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2947a782-ed3d-11ee-afe3-a90da7624cb6;
 Thu, 28 Mar 2024 20:55:44 +0100 (CET)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-4154d24cc77so684525e9.3
 for ; Thu, 28 Mar 2024 12:55:43 -0700 (PDT)
Received: from [10.80.67.139] (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 bq21-20020a5d5a15000000b00341cb22a8d4sm2523839wrb.108.2024.03.28.12.55.41
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 28 Mar 2024 12:55:42 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2947a782-ed3d-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1711655743; x=1712260543; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=s/IDWIb0SW/9AwfUtyXDUxnhS3iY9i8OmmoOsMrW3rw=;
        b=Joh588nFHaMeMgr8moGYz63A16n8mOoAxiy3JCFmSTB4UxWKxJCCVNoCNq5CvwBDgU
         3VMwFMAiqPyvmSI3Z/GehAeRrjDaD4/n738NIjroh9S8ad/V01NAfehn4VaRwT3UBCQ3
         Md31up1SeRGk6P5VmMUQ1D/gxZo8M3sX/UVHk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711655743; x=1712260543;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=s/IDWIb0SW/9AwfUtyXDUxnhS3iY9i8OmmoOsMrW3rw=;
        b=KzDkVSSur7s/QnoONkiMCt0Q3Evu0vzXgjxpiSrakcurau5jVHsgNAM1jjnSsCrlse
         5SbnAsW2j1T8SwpKfsvDTEw/mzk00t3so6gIrJunuK4iAOEcQY8dI4mf+l0lP+bdnnXy
         FJrRPxYMhGvqkshKA3IdXKzRf/vuYGGTZ105fPYuCvqkpELpEofC9s+7zg8Ckl6GL1eW
         p/HCrGdwv9iLO7kzVTmQdHbXOGgZL1jEZ4YAGCdtawVhZErrmFHcKRYDZKeNQbRIXqVR
         Iuf7nhdOMBIZrl5dRUNpvJqXuT7SUR9nLjVcX2iTRBpagPGpHOaxwyF3sI0u+mjvCFve
         aQvQ==
X-Forwarded-Encrypted: i=1; AJvYcCX2tGSC+p1mGiPfHCmLINDmSpT6WtDDvn2rw49qZjkUW4tompuZBHZ9/P5+59ApSz9Z2KQzhfbnKglG3rHdN/keiLuDO2sKm+8AQJkrIO4=
X-Gm-Message-State: AOJu0YwTVsdx18DuqZG8wGz8raf4yWWLrK9FOzaHuWyvEx8JW0SUMBOM
	q05CDLyhIMFtw6xHYnrBUKc7bngV6rVtcxCLoRDPdJvimOaA75I7hqK7iry11UEUSVLKmrRlLry
	2Cbc=
X-Google-Smtp-Source: AGHT+IFzacOYI2OJoZDJ5c2kX9wF4hZCfGhQLSK6M5dF0WbDQ9QHurO7sRCJ7ryML1IGEVjOMtyrPw==
X-Received: by 2002:a5d:4d07:0:b0:341:cf9b:c8e with SMTP id z7-20020a5d4d07000000b00341cf9b0c8emr45383wrt.50.1711655743040;
        Thu, 28 Mar 2024 12:55:43 -0700 (PDT)
Message-ID: 
Date: Thu, 28 Mar 2024 19:55:41 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/2] x86/video: add boot_video_info offset generation to
 asm-offsets
To: Roger Pau Monne , xen-devel@lists.xenproject.org
Cc: Jan Beulich 
References: <20240328153523.4155-1-roger.pau@citrix.com>
 <20240328153523.4155-2-roger.pau@citrix.com>
Content-Language: en-GB
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <20240328153523.4155-2-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 28/03/2024 3:35 pm, Roger Pau Monne wrote:
> Currently the offsets into the boot_video_info struct are manually encoded in
> video.S, which is fragile.  Generate them in asm-offsets.c and switch the
> current code to use those instead.
>
> No functional change intended.
>
> Signed-off-by: Roger Pau Monné 

R-by: Andrew Cooper 

Thanks for looking at this.  As you're touching these lines, there are a
few style fixes.

> diff --git a/xen/arch/x86/boot/video.S b/xen/arch/x86/boot/video.S
> index 0ae04f270f8c..a4b25a3b34d1 100644
> --- a/xen/arch/x86/boot/video.S
> +++ b/xen/arch/x86/boot/video.S
> @@ -26,32 +26,13 @@
>  /* Force 400 scan lines for standard modes (hack to fix bad BIOS behaviour */
>  #undef CONFIG_VIDEO_400_HACK
>  
> -/* Positions of various video parameters passed to the kernel */
> -/* (see also include/linux/tty.h) */
> -#define PARAM_CURSOR_POS        0x00
> -#define PARAM_VIDEO_MODE        0x02
> -#define PARAM_VIDEO_COLS        0x03
> -#define PARAM_VIDEO_LINES       0x04
> -#define PARAM_HAVE_VGA          0x05
> -#define PARAM_FONT_POINTS       0x06
> -#define PARAM_CAPABILITIES      0x08
> -#define PARAM_LFB_LINELENGTH    0x0c
> -#define PARAM_LFB_WIDTH         0x0e
> -#define PARAM_LFB_HEIGHT        0x10
> -#define PARAM_LFB_DEPTH         0x12
> -#define PARAM_LFB_BASE          0x14
> -#define PARAM_LFB_SIZE          0x18
> -#define PARAM_LFB_COLORS        0x1c
> -#define PARAM_VESAPM_SEG        0x24
> -#define PARAM_VESAPM_OFF        0x26
> -#define PARAM_VESA_ATTRIB       0x28
>  #define _param(param) bootsym(boot_vid_info)+(param)
>  
>  video:  xorw    %ax, %ax
>          movw    %ax, %gs        # GS is zero
>          cld
>          call    basic_detect    # Basic adapter type testing (EGA/VGA/MDA/CGA)
> -        cmpb    $0,_param(PARAM_HAVE_VGA)
> +        cmpb    $0,_param(BVI_have_vga)

Space

> @@ -160,16 +141,16 @@ mopar_gr:
>  dac_set:
>  # set color size to DAC size
>          movzbw  bootsym(dac_size), %ax
> -        movb    %al, _param(PARAM_LFB_COLORS+0)
> -        movb    %al, _param(PARAM_LFB_COLORS+2)
> -        movb    %al, _param(PARAM_LFB_COLORS+4)
> -        movb    %al, _param(PARAM_LFB_COLORS+6)
> +        movb    %al, _param(BVI_lfb_colors+0)
> +        movb    %al, _param(BVI_lfb_colors+2)
> +        movb    %al, _param(BVI_lfb_colors+4)
> +        movb    %al, _param(BVI_lfb_colors+6)

Spaces

> diff --git a/xen/arch/x86/x86_64/asm-offsets.c b/xen/arch/x86/x86_64/asm-offsets.c
> index d8903a3ce9c7..91da6b9d3885 100644
> --- a/xen/arch/x86/x86_64/asm-offsets.c
> +++ b/xen/arch/x86/x86_64/asm-offsets.c
> @@ -16,6 +16,10 @@
>  #include 
>  #include 
>  
> +#ifdef CONFIG_VIDEO
> +# include "../boot/video.h"
> +#endif
> +
>  #define DEFINE(_sym, _val)                                                 \
>      asm volatile ( "\n.ascii\"==>#define " #_sym " %0 /* " #_val " */<==\""\
>                     :: "i" (_val) )
> @@ -208,4 +212,26 @@ void __dummy__(void)
>  
>      OFFSET(DOMAIN_vm_assist, struct domain, vm_assist);
>      BLANK();
> +
> +#ifdef CONFIG_VIDEO
> +    DEFINE(BVI_size, sizeof(struct boot_video_info));
> +    OFFSET(BVI_cursor_pos, struct boot_video_info, orig_x);
> +    OFFSET(BVI_video_mode, struct boot_video_info, orig_video_mode);
> +    OFFSET(BVI_video_cols, struct boot_video_info, orig_video_cols);
> +    OFFSET(BVI_video_lines, struct boot_video_info, orig_video_lines);
> +    OFFSET(BVI_have_vga, struct boot_video_info, orig_video_isVGA);
> +    OFFSET(BVI_font_points, struct boot_video_info, orig_video_points);
> +    OFFSET(BVI_capabilities, struct boot_video_info, capabilities);
> +    OFFSET(BVI_lfb_linelength, struct boot_video_info, lfb_linelength);
> +    OFFSET(BVI_lfb_width, struct boot_video_info, lfb_width);
> +    OFFSET(BVI_lfb_height, struct boot_video_info, lfb_height);
> +    OFFSET(BVI_lfb_depth, struct boot_video_info, lfb_depth);
> +    OFFSET(BVI_lfb_base, struct boot_video_info, lfb_base);
> +    OFFSET(BVI_lfb_size, struct boot_video_info, lfb_size);
> +    OFFSET(BVI_lfb_colors, struct boot_video_info, colors);
> +    OFFSET(BVI_vesapm_seg, struct boot_video_info, vesapm.seg);
> +    OFFSET(BVI_vesapm_off, struct boot_video_info, vesapm.off);
> +    OFFSET(BVI_vesa_attrib, struct boot_video_info, vesa_attrib);
> +    BLANK();
> +#endif /* CONFIG_VIDEO */

BVI_size traditionally goes last.  MB2 (which I guess you copied?) is a
little odd.

I'd like to start vertically aligning this for readability, like I
started with EFRAME_*.

Happy to fold of all of these tweaks on commit.

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu Mar 28 19:58:41 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 19:58:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699175.1091836 (Exim 4.92)
	(envelope-from )
	id 1rpvtY-0001pE-3y; Thu, 28 Mar 2024 19:58:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699175.1091836; Thu, 28 Mar 2024 19:58:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpvtY-0001p5-19; Thu, 28 Mar 2024 19:58:40 +0000
Received: by outflank-mailman (input) for mailman id 699175;
 Thu, 28 Mar 2024 19:58:38 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpvtW-0001ov-P3
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 19:58:38 +0000
Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com
 [2a00:1450:4864:20::329])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 91107bf7-ed3d-11ee-afe3-a90da7624cb6;
 Thu, 28 Mar 2024 20:58:37 +0100 (CET)
Received: by mail-wm1-x329.google.com with SMTP id
 5b1f17b1804b1-415482307b0so7170415e9.0
 for ; Thu, 28 Mar 2024 12:58:37 -0700 (PDT)
Received: from [10.80.67.139] (default-46-102-197-194.interdsl.co.uk.
 [46.102.197.194]) by smtp.gmail.com with ESMTPSA id
 je4-20020a05600c1f8400b0041496734318sm5163928wmb.24.2024.03.28.12.58.36
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 28 Mar 2024 12:58:36 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 91107bf7-ed3d-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1711655917; x=1712260717; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=CbSmQlQpQISY33MaUOcZK/Zi3//tWlvqA1u6OjUNI7A=;
        b=m0N7xOt+Cj7AsnoJ1XWpK41GVfI5YOPzwPAKCKYqJ4e2Ff2x2380fW77AuVX/r6EZg
         qjedz5QIhQWL/RiMsPhDd97KBJ6rn1JQLjfnUayx3bUI9mZLyApSSsAieM9eJcKv9HNc
         7wrOUAGCEJCTD+edA6DS2QMd+dL7UOe8lCa4c=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711655917; x=1712260717;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=CbSmQlQpQISY33MaUOcZK/Zi3//tWlvqA1u6OjUNI7A=;
        b=DJ8ESer3rSE6zr9wXy9pCMU/za/2EauE9ltkiwRBp6C3q/QSA9Z2h89APkqsa0jdKj
         bWjMfrQ2n5aSnJN4XNQU9bsgxOEDTgMBtO+QhRSUKenTZ+Qq5yPgQNujwwT7peMUeOXG
         0bhVG9msowj9cWmHI0bouu4rFmci5seKk5vLzqx0yaVCbvQMPRObRGQO72Ae+0CegneS
         tkfm+T6C/eu3HhP0yFCK5RzyF64Wc5GR8EBvd8EUdiPh1usXTZlz8Y963frtMtbQj+6z
         UmEaD3yqUzbTgSQDpJPZ5B3Y03DlPX/s0lJwRF7PmT1Dywy+kVPWlyH0NGIRC1//dU10
         zwGA==
X-Forwarded-Encrypted: i=1; AJvYcCUzDoFRxlCzTgq7VLWGLf5AN2cBhAJjuFDviNNUV+wcLX/XRkIcUXY3A7VuEUlfxWy32v/dg0OURlqiYicEVeoGa4X7fFijaOfMLwzusvo=
X-Gm-Message-State: AOJu0Yzr/0CEgIYPwxEiXM46vrmb3HXGNJPi6sLhc3ABhspdjRcZT26K
	gBcvw3JPNF8T6bIU3XKVa+SM9HzjIOmMyEovmXh4sFYefhIwgykv77b86HjPHL4=
X-Google-Smtp-Source: AGHT+IGojQGFJyCdnoBF3eHGUOHyvBjTmIjjYRw5p1GWr/B44TxyAhGZ/w4YgX5k6QCsXcFRyRCvHg==
X-Received: by 2002:a1c:790c:0:b0:415:4b4b:1e03 with SMTP id l12-20020a1c790c000000b004154b4b1e03mr337375wme.19.1711655917313;
        Thu, 28 Mar 2024 12:58:37 -0700 (PDT)
Message-ID: <9d8af8b5-2a14-44bc-89c6-b616e79cb259@citrix.com>
Date: Thu, 28 Mar 2024 19:58:36 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/2] x86/video: do not assume a video mode to be
 unconditionally present
To: Roger Pau Monne , xen-devel@lists.xenproject.org
Cc: Jan Beulich 
References: <20240328153523.4155-1-roger.pau@citrix.com>
 <20240328153523.4155-3-roger.pau@citrix.com>
Content-Language: en-GB
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <20240328153523.4155-3-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 28/03/2024 3:35 pm, Roger Pau Monne wrote:
> There's no reason to assume VGA text mode 3 to be unconditionally available.
> With the addition of booting Xen itself in PVH mode there's a boot path that
> explicitly short-circuits all the real-mode logic, including the VGA detection.
>
> Leave the default user selected mode as text mode 3 in boot_vid_mode, but do
> not populate boot_vid_info with any default settings.  It will either be
> populated by the real-mode video detection code, or left zeroed in case
> real-mode code is skipped.
>
> Note that only PVH skips the real-mode portion of the boot trampoline,
> otherwise the only way to skip it is to set `no-real-mode` on the command line,
> and the description for the option already notes that VGA would be disabled as
> a result of skipping real-mode bootstrap.

IIRC, Grub defaults to using no-real-mode for xen.efi.  It's definitely
a common option to find used in practice.

>
> This fixes Xen incorrectly reporting:
>
> (XEN) Video information:
> (XEN)  VGA is text mode 80x25, font 8x16
>
> When booted as a PVH guest.
>
> Reported-by: Andrew Cooper 
> Signed-off-by: Roger Pau Monné 

Reivewed-by: Andrew Cooper 
Tested-by: Andrew Cooper 


From xen-devel-bounces@lists.xenproject.org Thu Mar 28 20:20:28 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 20:20:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699179.1091850 (Exim 4.92)
	(envelope-from )
	id 1rpwEY-0000Xi-SU; Thu, 28 Mar 2024 20:20:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699179.1091850; Thu, 28 Mar 2024 20:20:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpwEY-0000Xb-Ny; Thu, 28 Mar 2024 20:20:22 +0000
Received: by outflank-mailman (input) for mailman id 699179;
 Thu, 28 Mar 2024 20:20:22 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpwEY-0000XR-4d; Thu, 28 Mar 2024 20:20:22 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpwEX-0003Kf-VT; Thu, 28 Mar 2024 20:20:22 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpwEX-0004Ib-IC; Thu, 28 Mar 2024 20:20:21 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rpwEX-0001Lw-GO; Thu, 28 Mar 2024 20:20:21 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=DKJjQ/0IuMxRJ1Gc8GXRaiQfmzBVQm4IVeVuVZqvJNU=; b=k2T/71OGbdQ6dnyxRfNadXTZ8w
	kprG2ThHeeSOCPGwcpvWiKuYU+X2YA1kS5JAprJNJKle+96+iewCz7wznEVCTrWmZyrtJ86eetCVL
	lscKO696o01Nd2oTnXp9sMBQc4jS1UISzm58SaTS0cHdDxZ1Wr+pAqeedEaECYwi/aNg=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-4.17-testing test] 185180: tolerable trouble: fail/pass/starved - PUSHED
X-Osstest-Failures:
    xen-4.17-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    xen-4.17-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    xen-4.17-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    xen-4.17-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    xen-4.17-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    xen-4.17-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-xl-raw:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-xl-raw:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-libvirt-vhd:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-libvirt-vhd:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-xl-qcow2:migrate-support-check:fail:nonblocking
    xen-4.17-testing:test-armhf-armhf-xl-qcow2:saverestore-support-check:fail:nonblocking
    xen-4.17-testing:test-arm64-arm64-libvirt-raw:build-check(1):starved:nonblocking
    xen-4.17-testing:test-arm64-arm64-libvirt-xsm:build-check(1):starved:nonblocking
    xen-4.17-testing:test-arm64-arm64-xl:build-check(1):starved:nonblocking
    xen-4.17-testing:test-arm64-arm64-xl-credit1:build-check(1):starved:nonblocking
    xen-4.17-testing:test-arm64-arm64-xl-credit2:build-check(1):starved:nonblocking
    xen-4.17-testing:test-arm64-arm64-xl-thunderx:build-check(1):starved:nonblocking
    xen-4.17-testing:test-arm64-arm64-xl-vhd:build-check(1):starved:nonblocking
    xen-4.17-testing:test-arm64-arm64-xl-xsm:build-check(1):starved:nonblocking
    xen-4.17-testing:build-arm64-pvops:hosts-allocate:starved:nonblocking
X-Osstest-Versions-This:
    xen=f38a815a54000ca51ff5165b2863d60b6bbea49c
X-Osstest-Versions-That:
    xen=bfb69205376d94ff91b09a337c47fb665ee12da3
From: osstest service owner 
Date: Thu, 28 Mar 2024 20:20:21 +0000

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt     16 saverestore-support-check    fail  like 185171
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop            fail like 185171
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop            fail like 185171
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop            fail like 185171
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 185171
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop            fail like 185171
 test-amd64-amd64-libvirt     15 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass
 test-armhf-armhf-xl-multivcpu 15 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-arndale  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     16 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          16 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qcow2 14 migrate-support-check        fail never pass
 test-armhf-armhf-xl-credit2  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     15 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-raw 14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-raw      14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-raw      15 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-vhd 14 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-vhd 15 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-qcow2    14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-qcow2    15 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-raw  1 build-check(1)               starved  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)               starved  n/a
 test-arm64-arm64-xl           1 build-check(1)               starved  n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)               starved  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)               starved  n/a
 test-arm64-arm64-xl-thunderx  1 build-check(1)               starved  n/a
 test-arm64-arm64-xl-vhd       1 build-check(1)               starved  n/a
 test-arm64-arm64-xl-xsm       1 build-check(1)               starved  n/a
 build-arm64-pvops             2 hosts-allocate               starved  n/a

version targeted for testing:
 xen                  f38a815a54000ca51ff5165b2863d60b6bbea49c
baseline version:
 xen                  bfb69205376d94ff91b09a337c47fb665ee12da3

Last test of basis   185171  2024-03-27 11:37:09 Z    1 days
Testing same since   185180  2024-03-28 10:52:41 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Christian Lindig 
  Edwin Török 

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            starved 
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          starved 
 test-armhf-armhf-xl                                          pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 starved 
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      starved 
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  starved 
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  starved 
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-libvirt-qcow2                               pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-xl-qcow2                                    pass    
 test-amd64-amd64-libvirt-raw                                 pass    
 test-arm64-arm64-libvirt-raw                                 starved 
 test-amd64-amd64-xl-raw                                      pass    
 test-armhf-armhf-xl-raw                                      pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-arm64-arm64-xl-thunderx                                 starved 
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-libvirt-vhd                                 pass    
 test-amd64-amd64-xl-vhd                                      pass    
 test-arm64-arm64-xl-vhd                                      starved 


------------------------------------------------------------
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
   bfb6920537..f38a815a54  f38a815a54000ca51ff5165b2863d60b6bbea49c -> stable-4.17


From xen-devel-bounces@lists.xenproject.org Thu Mar 28 22:32:11 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 22:32:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699197.1091870 (Exim 4.92)
	(envelope-from )
	id 1rpyHt-0005II-2n; Thu, 28 Mar 2024 22:31:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699197.1091870; Thu, 28 Mar 2024 22:31:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpyHt-0005IB-08; Thu, 28 Mar 2024 22:31:57 +0000
Received: by outflank-mailman (input) for mailman id 699197;
 Thu, 28 Mar 2024 22:31:56 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpyHs-0005I5-5D
 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2024 22:31:56 +0000
Received: from fout6-smtp.messagingengine.com (fout6-smtp.messagingengine.com
 [103.168.172.149]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f8d66568-ed52-11ee-afe3-a90da7624cb6;
 Thu, 28 Mar 2024 23:31:54 +0100 (CET)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44])
 by mailfout.nyi.internal (Postfix) with ESMTP id DA7AE1380083;
 Thu, 28 Mar 2024 18:31:50 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163])
 by compute4.internal (MEProxy); Thu, 28 Mar 2024 18:31:50 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu,
 28 Mar 2024 18:31:48 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f8d66568-ed52-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-type:content-type:date
	:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to; s=fm2; t=1711665110;
	 x=1711751510; bh=dLo89DPTrCGC35efpMRUHvoSCZ2cax35wNBelSetaeQ=; b=
	cKU0w9hZLOfmmit/VFaGp1VjaMGdTZ7OMnWPiZA2vqPiPoAnTeQqVutAHJKjS7D3
	VbMkP+yknqE8GkZtTaQwJaGaQVQ1Y8dHd+CVVjIv6NOLEzKKJxwzmrCTSQB/KEsC
	cdKjJaZQ95mbwp2JQXy2QuXlONjL4e1BiJ1BcSTJtHk04S84ehNDBdaobFdepMgR
	vr0jKqU3hVNh8Mf9zqtL3vnVtY2n9shDHVoXLRZB7ZPC/4vtElB9Ek/5QLcwLD0f
	bpgIZ5UdncaYif8zy7inij5weNLjYEfyQ7SFEXCpiHBeezPpsTEAYqYAV4sHXg1m
	lpSKjqncB24VKLHEglyeNg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-type:content-type:date:date
	:feedback-id:feedback-id:from:from:in-reply-to:in-reply-to
	:message-id:mime-version:references:reply-to:subject:subject:to
	:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=
	fm2; t=1711665110; x=1711751510; bh=dLo89DPTrCGC35efpMRUHvoSCZ2c
	ax35wNBelSetaeQ=; b=Jv7Ix0SAXN6UwKu03lNQuTZDsr+SerhPpBd7ZKSbDY2u
	5q5PCUFNnHZzaigTbGi2pT9QPSPzId8e5OeYDuCb+IUZFS5uBSW2jOFjD+MnE9b3
	ueSozJ2pzsjSXUXPyOL7wzqE8a0sQIfsutn6TUFBAjfbNGYsSHsNY7P7JseusRw8
	gYmZ3baEd1wsT5MG0MiPVPcZJJg4NRZ0lWPpitm46wTsPLWRS6fI+wJ38nosYOhP
	XVbbAUsD5343h5wRAuAJb6QFGPDuAj2+2vrhDkv1VG/rhUyls2CqfIWLMY5cy/bT
	DQ3Lok4Lna/82Ei1yqufMA78822bTXibhFGrUQXwEw==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrudduledgudeitdcutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh
    necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd
    enucfjughrpeffhffvvefukfhfgggtuggjsehgtderredttdejnecuhfhrohhmpeforghr
    vghkucforghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesih
    hnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpeeu
    keetteeggffgkeduheetgeeileejjeeiiefhjeegvefhtefggfetueetteeuteenucffoh
    hmrghinhepghhithhhuhgsrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghr
    rghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhngh
    hslhgrsgdrtghomh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Thu, 28 Mar 2024 23:31:45 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Jesper Dangaard Brouer 
Cc: netdev@vger.kernel.org, arthurborsboom@gmail.com,
	Ilias Apalodimas , wei.liu@kernel.org,
	paul@xen.org, Jakub Kicinski , kirjanov@gmail.com,
	dkirjanov@suse.de, kernel-team@cloudflare.com,
	security@xenproject.org, andrew.cooper3@citrix.com,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH net] xen-netfront: Add missing skb_mark_for_recycle
Message-ID: 
References: <171154167446.2671062.9127105384591237363.stgit@firesoul>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="u5NxXEymOds7Bg/x"
Content-Disposition: inline
In-Reply-To: <171154167446.2671062.9127105384591237363.stgit@firesoul>


--u5NxXEymOds7Bg/x
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Thu, 28 Mar 2024 23:31:45 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Jesper Dangaard Brouer 
Cc: netdev@vger.kernel.org, arthurborsboom@gmail.com,
	Ilias Apalodimas , wei.liu@kernel.org,
	paul@xen.org, Jakub Kicinski , kirjanov@gmail.com,
	dkirjanov@suse.de, kernel-team@cloudflare.com,
	security@xenproject.org, andrew.cooper3@citrix.com,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH net] xen-netfront: Add missing skb_mark_for_recycle

On Wed, Mar 27, 2024 at 01:14:56PM +0100, Jesper Dangaard Brouer wrote:
> Notice that skb_mark_for_recycle() is introduced later than fixes tag in
> 6a5bcd84e886 ("page_pool: Allow drivers to hint on SKB recycling").
>=20
> It is believed that fixes tag were missing a call to page_pool_release_pa=
ge()
> between v5.9 to v5.14, after which is should have used skb_mark_for_recyc=
le().
> Since v6.6 the call page_pool_release_page() were removed (in 535b9c61bdef
> ("net: page_pool: hide page_pool_release_page()") and remaining callers
> converted (in commit 6bfef2ec0172 ("Merge branch
> 'net-page_pool-remove-page_pool_release_page'")).
>=20
> This leak became visible in v6.8 via commit dba1b8a7ab68 ("mm/page_pool: =
catch
> page_pool memory leaks").
>=20
> Fixes: 6c5aa6fc4def ("xen networking: add basic XDP support for xen-netfr=
ont")
> Reported-by: Arthur Borsboom 
> Signed-off-by: Jesper Dangaard Brouer 
> ---
> Compile tested only, can someone please test this

I've got a confirmation it fixes the issue:
https://github.com/QubesOS/qubes-linux-kernel/pull/926#issuecomment-2026226=
944

>  drivers/net/xen-netfront.c |    1 +
>  1 file changed, 1 insertion(+)
>=20
> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> index ad29f370034e..8d2aee88526c 100644
> --- a/drivers/net/xen-netfront.c
> +++ b/drivers/net/xen-netfront.c
> @@ -285,6 +285,7 @@ static struct sk_buff *xennet_alloc_one_rx_buffer(str=
uct netfront_queue *queue)
>  		return NULL;
>  	}
>  	skb_add_rx_frag(skb, 0, page, 0, 0, PAGE_SIZE);
> +	skb_mark_for_recycle(skb);
> =20
>  	/* Align ip header to a 16 bytes boundary */
>  	skb_reserve(skb, NET_IP_ALIGN);
>=20
>=20
>=20

--=20
Best Regards,
Marek Marczykowski-G=C3=B3recki
Invisible Things Lab

--u5NxXEymOds7Bg/x
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYF79EACgkQ24/THMrX
1yxwlwf/XUrABq1kmtKxeomxnO1eXtzR3tys87jcg9Nshm8fQdTRVixVO+j3SEgt
sRlf7oPRMb8VLYJaLnUhIZyc8780bgklFn2MUUdrNvzIEFW8T+v0xtCT0LQF7Ln5
U2TYcjthpjMbCWG2qqefCq6whTZpFTRjQ7ayEY81C0n8yA/y8Ly5W5zVKeqIChn6
EXdr92h+0XfJiWjRY6SpvSFmFrNhXg6XDAXDMmWARBustYR87icJm92VtQDuEbCG
r9SEKz/pZbrsj7seqNfbsdkkkNWAhZoiDvsODrudAfR5vnaF6RxQ//3RD1Vsi8Tl
vQ1uNGNYZV2NXNKuFIC3N8OSPBWBvQ==
=IwCF
-----END PGP SIGNATURE-----

--u5NxXEymOds7Bg/x--


From xen-devel-bounces@lists.xenproject.org Thu Mar 28 23:53:54 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Mar 2024 23:53:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699202.1091881 (Exim 4.92)
	(envelope-from )
	id 1rpzYy-0007tt-Ug; Thu, 28 Mar 2024 23:53:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699202.1091881; Thu, 28 Mar 2024 23:53:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpzYy-0007tm-Rj; Thu, 28 Mar 2024 23:53:40 +0000
Received: by outflank-mailman (input) for mailman id 699202;
 Thu, 28 Mar 2024 23:53:40 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpzYy-0007tc-0C; Thu, 28 Mar 2024 23:53:40 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpzYx-00071W-Mt; Thu, 28 Mar 2024 23:53:39 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rpzYx-00084X-DG; Thu, 28 Mar 2024 23:53:39 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rpzYx-0001pE-CG; Thu, 28 Mar 2024 23:53:39 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=iMiQxsN9CLOWed26wHRMAmNZUIicrmBfPn7PfNpDXrE=; b=zWOk0EGV8e2uX0Av1bQ9TNy0XO
	jD9JG/E+sVakQSq4W2owuGI/zTQc8JRaJ6bd1XZBMVyrH1upnYAmGhbxmiNpkwYlcXVXi2AhcQSI2
	ay5nxfkTxFu0jNc+0ejrk3VQ5y7n+RR7V4v3yyy8WBgF7Wl0XoHKoWbYuaSl0zy5nFWA=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable-smoke test] 185196: tolerable all pass - PUSHED
X-Osstest-Failures:
    xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    xen=7a09966e7b2823b70f6d56d0cf66c11124f4a3c1
X-Osstest-Versions-That:
    xen=3c9e76cd875e12c88cfc8f0b2770c525da8d6894
From: osstest service owner 
Date: Thu, 28 Mar 2024 23:53:39 +0000

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          16 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  7a09966e7b2823b70f6d56d0cf66c11124f4a3c1
baseline version:
 xen                  3c9e76cd875e12c88cfc8f0b2770c525da8d6894

Last test of basis   185181  2024-03-28 12:00:24 Z    0 days
Testing same since   185196  2024-03-28 21:04:03 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper 

jobs:
 build-arm64-xsm                                              pass    
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-amd64-libvirt                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 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
   3c9e76cd87..7a09966e7b  7a09966e7b2823b70f6d56d0cf66c11124f4a3c1 -> smoke


From xen-devel-bounces@lists.xenproject.org Fri Mar 29 00:09:30 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Mar 2024 00:09:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699208.1091898 (Exim 4.92)
	(envelope-from )
	id 1rpzo5-0002DW-6P; Fri, 29 Mar 2024 00:09:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699208.1091898; Fri, 29 Mar 2024 00:09:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpzo4-0002CA-VN; Fri, 29 Mar 2024 00:09:16 +0000
Received: by outflank-mailman (input) for mailman id 699208;
 Fri, 29 Mar 2024 00:09:16 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpzo4-0002Ab-2s
 for xen-devel@lists.xenproject.org; Fri, 29 Mar 2024 00:09:16 +0000
Received: from mx0b-0039f301.pphosted.com (mx0b-0039f301.pphosted.com
 [148.163.137.242]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 929df10a-ed60-11ee-a1ef-f123f15fe8a2;
 Fri, 29 Mar 2024 01:09:13 +0100 (CET)
Received: from pps.filterd (m0174682.ppops.net [127.0.0.1])
 by mx0b-0039f301.pphosted.com (8.17.1.24/8.17.1.24) with ESMTP id
 42SN0uE0024084; Fri, 29 Mar 2024 00:09:05 GMT
Received: from eur05-vi1-obe.outbound.protection.outlook.com
 (mail-vi1eur05lp2168.outbound.protection.outlook.com [104.47.17.168])
 by mx0b-0039f301.pphosted.com (PPS) with ESMTPS id 3x5huq82q0-2
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Fri, 29 Mar 2024 00:09:05 +0000 (GMT)
Received: from GV1PR03MB10456.eurprd03.prod.outlook.com
 (2603:10a6:150:16a::21) by DBBPR03MB10269.eurprd03.prod.outlook.com
 (2603:10a6:10:536::7) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.31; Fri, 29 Mar
 2024 00:09:01 +0000
Received: from GV1PR03MB10456.eurprd03.prod.outlook.com
 ([fe80::74c9:2488:1dd7:b976]) by GV1PR03MB10456.eurprd03.prod.outlook.com
 ([fe80::74c9:2488:1dd7:b976%3]) with mapi id 15.20.7409.028; Fri, 29 Mar 2024
 00:09:01 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 929df10a-ed60-11ee-a1ef-f123f15fe8a2
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=epRbU8yemQ8r+UcDGhLuZxyJrkKrOZOTN4Dr+AL3E+Pi99W109UpPcl81JCHXaHXJbyAweQyb5Yv8A04gFRA0xmopsDAy2OiNaZDkkaJMoQUos2O/bNCSvaL++M/b5o8QK44fTF1vhfwt1tkKwZX/4XjC6tMWJ1KTyagSa1zv01INflDwU8/fT/tcJa6bH1usqMvLqQqpYCek0WFsksMm4YAkpNq8iQwMlerqDJgmDLC48gCRG6D3pRPS7oy5W2iKfbX4z34UbRftCxBIEFPi9GqWYm767T50oxrKGfoCiFgMZjGG24NONkRlItyJeBG6sxECH09HwI4W3iXaHjk2g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=xlWucAXwM4UZFrs5s6iqTywkhsmhUhvRMACIl434bj8=;
 b=kU/99/KDbitMKenbJHZza1uhx0ENEyuvHH3g39dj7CoDRBJu79y+ARyL2xoWiC6Wuq45IMLUF4QtpVn75DWjPEAsn9TtzuutzPLWdQFIeWmU6Me0DFIrkgwVCfmKIpbKL2iF6TtMKZ9HT3nelA5wiy9W3AeNGHFt3UJEg8cH8GK46pVXzRZiRYwhkEzvBYpc/MAvCFb3XZ1xwgGxj9u0Rk5zUEODhNCAKT25F6S0dg1jZLec6o3KMikzwSBF+rH7Wq49qqUeR9DiFGyk5E7hT/gAsSLh+oi/+LRSjCZkgjNW3clLZSwampFWhtIcOW/UNQ2CIdpzMFa/umfys6RT0g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector2;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=xlWucAXwM4UZFrs5s6iqTywkhsmhUhvRMACIl434bj8=;
 b=cAKHpjakJmApsYxCI+yyPhbPMVLm3aQ9yA09tIeBbsqHfJ+aqiFEdfQaYWZ4PsfHOo3xDnP1kzq6c6dZjA00FYoGbCaGfro9UwkDyIxiApsGUC7ZqHyYcadqb6/4WwYbbFtqSyNJf1BeEWDr0WcEYu8hdlXt0LcRsMQ0CYpgjxpKdb2KYYKviR7/q1IzzTSUGo3YlHaHhR1IrliT9OAeB+nzM7AAsxs33iabz0Z+MICd5qQPmeafEtAqyRtQS471qPRnWkRyPNrsyrVCthDbF6s3ZFhRKyNwKq/EwBPVDvr22OudiYG/BapjOQ0Q16VfCvxwnrCLqna1vwU5pq0Nkw==
From: Volodymyr Babchuk 
To: "xen-devel@lists.xenproject.org" 
CC: Volodymyr Babchuk ,
        Julien Grall
	, Rahul Singh ,
        Stefano Stabellini
	,
        Bertrand Marquis ,
        Michal
 Orzel ,
        Volodymyr Babchuk 
Subject: [PATCH 1/3] arm: smmu: allow SMMU to have more IRQs than context
 banks
Thread-Topic: [PATCH 1/3] arm: smmu: allow SMMU to have more IRQs than context
 banks
Thread-Index: AQHagW1LqEDvA9goAU2CqI9xrHsnFw==
Date: Fri, 29 Mar 2024 00:08:57 +0000
Message-ID: <20240329000822.3363568-2-volodymyr_babchuk@epam.com>
References: <20240329000822.3363568-1-volodymyr_babchuk@epam.com>
In-Reply-To: <20240329000822.3363568-1-volodymyr_babchuk@epam.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: git-send-email 2.43.0
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: GV1PR03MB10456:EE_|DBBPR03MB10269:EE_
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 
 riPSEmfKsqKfo9u5KxdcQ+pJBzeXx1zXzBGX+AW7oirXMqg3S0KGysRfR0tHft/NQNtDCSOR9g26PCoP7WPk+2KFMUPNiUeOxWgrkO1zSLY4Lm39nkduQsP5Myw7y/6gsEov78Eq3u4Sxmfp5CmQxUYYJueX0cR35zRGfuJVIm+KPI9ObKcybvwSp1bWXiz0UOJn5zLHG73JEB6eM9iPqhbMzNVshl0ibDNXPewShSsmHYkZEVnnpAkN3JQ5BXW3ehMys6AvPl+LQVDPckczo6WRm8aJxBx10WEhUwguxesESbRh6K+xGmOl8uAE+GHsT/AW81qO/qpAfGenleZvPr0578Yy/72fiicUeAEBl/2xH7Z+teOU+BmEc5zy/LzOr76kjmSTrrXDzaDGSlBUcmp0LMLzy+/70XplRqUs5NB1VXcbkJQGXEBbNqGmCbFlOkNzMTlMr+Lw3cYUFY2BNT+uVwCpDLMaixD3ASmNSd6hgYEgdaRLc+/Vbt71+YEpvK2MEsmn+hwGzbvFY+dmc15OkDrosFDAD9dNsMkJpydVLC3c74ABKcBLcZyBNDYgoq6MsU7MjTWbLujiwHarBIxaCvrAMNxBTC1jKluNy2r/W4/tAZxkFyJs8UM3WuiLqayadw5OgUcI/YL8ub4HKy5bt++1nRiP/lPaozVP4is=
x-forefront-antispam-report: 
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV1PR03MB10456.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(1800799015)(366007)(376005);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 
 =?iso-8859-1?Q?K4Y0LI6i1UQVDKuTbIa/8+ouS9lkpC9tUv0Px/e1JqIwjKQcGLKRYzwPrN?=
 =?iso-8859-1?Q?45k2BiLNz2h/yyYWq8lR8J8E7sjnorydHVkVuU3cweiKLDQWd9NuErT+EX?=
 =?iso-8859-1?Q?kDAB8PUO7TXzJMazsVhV4htQujv5/b0Oow7iXZHogOjcTEsHXzlq8SPFvP?=
 =?iso-8859-1?Q?6CBPYu6ShflfoDN5cc8YGrNgpVjhdqd/F5Rqo21XLznnCZvM7fr+DaEc3s?=
 =?iso-8859-1?Q?Y1+QhwovNRnS1glx1dqP4Z+UW8sE/fTzOEsfS9KISoFrDimM1ARPEyw9y9?=
 =?iso-8859-1?Q?h1BctH+ig2kbbIZQ3E6BChjgr+cF+PWixZVZt9ROFJ0KAAJ27Qzz8HZhMP?=
 =?iso-8859-1?Q?ZryG8dfSqnozMdtKyTTtwzmYxHZkO2kbWrxhRk05/xwdVMQLArW2rCB9PQ?=
 =?iso-8859-1?Q?1QXBJfjtPpFC3lfufeOZs8sujjVsio99xedkeDDG2NtY3GhqXT8bTyFd7+?=
 =?iso-8859-1?Q?BOZeY1MVWO9vAJco2+2SIRLWLojsGLZdug1wNUrw3lR7slnhL7yOaLSD0S?=
 =?iso-8859-1?Q?kA5cwzq3diC2keQ/9a72EquC9fP2QcmGMu45oacOYw1mwu2llUr9aXGMq0?=
 =?iso-8859-1?Q?YLBbSFtCU01j3a1Le3O4yY0nvBpbbrqeqqIgDSQ44eMAiCDHK3K/YG4pPi?=
 =?iso-8859-1?Q?k11v7IvENdYlS8dQFZWdgLcte82HPoBpEnOfIrviCMu1yPWxfqf0x58LBB?=
 =?iso-8859-1?Q?VavSydp5fyBgf7Y9rak+wtZIBwvQe5b6NmBoUtHoj6lhDUURJnBs9SEeLB?=
 =?iso-8859-1?Q?2Hofhk2DmHpDCCodl9Nvop87nU/noHGPJOesd8PuqDCg9+6Mt+c6wxngPg?=
 =?iso-8859-1?Q?3CLOsDx4+MdI9e/GpAGnC+2kWxze0VWTqu8NEzvurPvos4OjQ7Modpp6pi?=
 =?iso-8859-1?Q?oTyp5//8/FEajmSZCCybK9126FIJ2KV9A6irkf6ZTZsjRDbCMCXScYhOO4?=
 =?iso-8859-1?Q?79Ddnw207g1K/vuBfOe7i4nOU76njSiQ+Prd78Xel7+iu+ZjuwMb6FMz9J?=
 =?iso-8859-1?Q?MHb8pKCo+ZLt0TbKYPbN1uZa4T0RsVSDajz/I9WT/2vpo0625vcKE2JTaP?=
 =?iso-8859-1?Q?29mt7ChuzYnexgJERXzYbWeKwWtQugd7c5eYa3oGhmOeoBscC87GgQvJPq?=
 =?iso-8859-1?Q?ULEEDi6MpWNFBk2dhQAnV1gRZRdvh7cu5z5vEng9Eb4MzuPNAJ+z/MB8DE?=
 =?iso-8859-1?Q?Vd/QZZeHvpfquxCzdiDA6e+RQW33b7/NYlryKAiDYb7IkCd4xVHt55x9WY?=
 =?iso-8859-1?Q?Ouw1ru/K65X9ug3YV08Z61IKSWcCh04f0cbuBmrcirr6EA5kArndb85LeZ?=
 =?iso-8859-1?Q?5+jpi18ODtx9Uv+cWNOVc/ZiMXE1x3QgDwMArVA8WjdJWPj7/vfzpHNDpH?=
 =?iso-8859-1?Q?/p8t98JfoqxS7Gbo0GqbvzIsLay6iFZ9bRouiaktVM7z/y4OKGyKvG1KH5?=
 =?iso-8859-1?Q?sNliwtJKN0o9wmUgXL4m6pSoRi9h0s13OjJ4sztkHEpRu0u+cELPy4jE8D?=
 =?iso-8859-1?Q?qoN6LRegjMFznmlwPC4w95antxoho+F5gCkMSsluwnZ7VxFVN2jHIcH1B8?=
 =?iso-8859-1?Q?qT7oNAst0gOMYcY2wVeLmKMEsav0UPazuPu47Yaomten932nOrVJOd+BsH?=
 =?iso-8859-1?Q?UrIw7zg6XdNa46Oxf3/Bk5o17i/dfNT7hw+12p22RCynE2m80hrySfdA?=
 =?iso-8859-1?Q?=3D=3D?=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: GV1PR03MB10456.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 102089bb-6aac-403d-cdbc-08dc4f847030
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2024 00:08:57.2766
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: VKs5qExzsYUnNgS8n6uQ1dSxQdQEskQDJt9xz2RbOqo3lAd7WMTGACFrCAQ7qV3elpzr7YFgWfAbNxa6dD5/xR9nwaPzZbyEDFqBvhgrW4U=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR03MB10269
X-Proofpoint-ORIG-GUID: j_28EHeptQbZUYd5OiP8O5MfnE6eOnGP
X-Proofpoint-GUID: j_28EHeptQbZUYd5OiP8O5MfnE6eOnGP
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26
 definitions=2024-03-28_18,2024-03-28_01,2023-05-22_02
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 mlxscore=0
 phishscore=0 mlxlogscore=947 suspectscore=0 lowpriorityscore=0
 malwarescore=0 priorityscore=1501 spamscore=0 clxscore=1015 adultscore=0
 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.19.0-2403210001 definitions=main-2403280176

I encountered platform, namely Qualcomm SA8155P where SMMU-compatible
IO-MMU advertises more context IQRs than there are context banks. This
should not be an issue, we need to relax the check in the SMMU driver
to allow such configuration.

Signed-off-by: Volodymyr Babchuk 
---
 xen/drivers/passthrough/arm/smmu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/drivers/passthrough/arm/smmu.c b/xen/drivers/passthrough/a=
rm/smmu.c
index 32e2ff279b..2dd3688f3b 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -2550,7 +2550,7 @@ static int arm_smmu_device_dt_probe(struct platform_d=
evice *pdev)
 	parse_driver_options(smmu);
=20
 	if (smmu->version > ARM_SMMU_V1 &&
-	    smmu->num_context_banks !=3D smmu->num_context_irqs) {
+	    smmu->num_context_banks > smmu->num_context_irqs) {
 		dev_err(dev,
 			"found only %d context interrupt(s) but %d required\n",
 			smmu->num_context_irqs, smmu->num_context_banks);
--=20
2.43.0


From xen-devel-bounces@lists.xenproject.org Fri Mar 29 00:09:30 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Mar 2024 00:09:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699210.1091920 (Exim 4.92)
	(envelope-from )
	id 1rpzo7-0002sT-LB; Fri, 29 Mar 2024 00:09:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699210.1091920; Fri, 29 Mar 2024 00:09:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpzo7-0002sK-HL; Fri, 29 Mar 2024 00:09:19 +0000
Received: by outflank-mailman (input) for mailman id 699210;
 Fri, 29 Mar 2024 00:09:17 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpzo5-0002Ab-Pd
 for xen-devel@lists.xenproject.org; Fri, 29 Mar 2024 00:09:17 +0000
Received: from mx0b-0039f301.pphosted.com (mx0b-0039f301.pphosted.com
 [148.163.137.242]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 935585d9-ed60-11ee-a1ef-f123f15fe8a2;
 Fri, 29 Mar 2024 01:09:14 +0100 (CET)
Received: from pps.filterd (m0174682.ppops.net [127.0.0.1])
 by mx0b-0039f301.pphosted.com (8.17.1.24/8.17.1.24) with ESMTP id
 42SN0uE1024084; Fri, 29 Mar 2024 00:09:06 GMT
Received: from eur05-vi1-obe.outbound.protection.outlook.com
 (mail-vi1eur05lp2168.outbound.protection.outlook.com [104.47.17.168])
 by mx0b-0039f301.pphosted.com (PPS) with ESMTPS id 3x5huq82q0-3
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Fri, 29 Mar 2024 00:09:05 +0000 (GMT)
Received: from GV1PR03MB10456.eurprd03.prod.outlook.com
 (2603:10a6:150:16a::21) by DBBPR03MB10269.eurprd03.prod.outlook.com
 (2603:10a6:10:536::7) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.31; Fri, 29 Mar
 2024 00:09:02 +0000
Received: from GV1PR03MB10456.eurprd03.prod.outlook.com
 ([fe80::74c9:2488:1dd7:b976]) by GV1PR03MB10456.eurprd03.prod.outlook.com
 ([fe80::74c9:2488:1dd7:b976%3]) with mapi id 15.20.7409.028; Fri, 29 Mar 2024
 00:09:02 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 935585d9-ed60-11ee-a1ef-f123f15fe8a2
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=Np3SQsj2d+/ruyrD/CKSIbQIhqW9cd72UNQGcwY4efPfCB+fVfVumXDEEfDfsmiNKQ+cDGbD6sKXKcu54KVtgM0DRzOp+AVgeajsQ1tQYxFeOosPGYetjMnvKtr+9usm0eVAoGHkAW1ul+rbM9TXXKRj1XqxGCTqqPTRt8hAyetLjpIn7qAx9XgcdEyQeDwsbRflAZSuv7+Z+Wv5lWrC8XyGvUSYMSl+i81O32ob+CvsS1wWiNBJ1IrkeTn1migLVf7hbofbdYX8aDa+54eeRfmoxUPTU9Kcag0Uds9rUbS1POY/ZOC4xjthAnWqe31t1XASTV0uMN8KymJcrWys3Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=FENK0lL6QM9oXwz7y7lWBx5Y8WUk5Zaz3Nf7Qc0M+Gk=;
 b=kmHIVQ8cj3llW00z3Mx1zV+lc7FDvmeBzDmCskyTvYtPpX3L13Mau3y9YHZe1v/xJM6EfBfjDKjz6vkNgNf89FlfmizNYoCqGelOl6G4P+pogjatBZLYF4hyvR8T3wy+mRWNrsQ2KmnfPD74s3J01s8jr2m636sEUzoYG8ElwvD73VilCFPAsmqpycnhwwQo8DjIS/tnvk5vaxxT+WLzQ5sdXOuVNQSE7VOO13xWyDjzzRZx/QGYcG5m1xUX4mXULrqPAODOdw1KzEh8wXazmAVHG7QNjKgqPIw/5EIOdjHO4Wrg+fN/iEXXstdw+eUFvZ7lOY7Mr2hTeKyi/n3WQQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector2;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=FENK0lL6QM9oXwz7y7lWBx5Y8WUk5Zaz3Nf7Qc0M+Gk=;
 b=jNHeBCJ2saT2idY2tnz07J4dX1hXEwAPwZvHP/YFjiQdcb7jsbM/vNVqVIFReHdWPRmZ1KmsS7bct3RCUzdK1d5BhCUkzutC3ouZD2Vl7/S4lNDSgG4FlmLf10CVI97UwxmJBMYEV/Biq1Jwd5mG49ltW+FxzeVCt0QMmxmBbkvlrqkGLxcVuI4UgFoMqU8Rx5eaOEgFWOl+88hRJ1FAb12++k6J6SXmK9BQUh3WMx1WR4ML4hSpxZsw3qnnn4fMPxopR3p+xVZCgxTUa9U1xlx1E/OZUd9HDZ7/P5nK9EVTnH++v2/sg9lBv7lL9QB/e7jy7f8GkSp5HHaQ9QzxRQ==
From: Volodymyr Babchuk 
To: "xen-devel@lists.xenproject.org" 
CC: Volodymyr Babchuk ,
        Stefano Stabellini
	,
        Julien Grall ,
        Bertrand Marquis
	,
        Michal Orzel ,
        Volodymyr
 Babchuk ,
        Andrew Cooper
	,
        George Dunlap ,
        Jan
 Beulich , Wei Liu 
Subject: [PATCH 2/3] drivers: serial: add Qualcomm GENI-based serial driver
Thread-Topic: [PATCH 2/3] drivers: serial: add Qualcomm GENI-based serial
 driver
Thread-Index: AQHagW1LewNbiHn0V0mBfSyHgZWL5Q==
Date: Fri, 29 Mar 2024 00:08:57 +0000
Message-ID: <20240329000822.3363568-3-volodymyr_babchuk@epam.com>
References: <20240329000822.3363568-1-volodymyr_babchuk@epam.com>
In-Reply-To: <20240329000822.3363568-1-volodymyr_babchuk@epam.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: git-send-email 2.43.0
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: GV1PR03MB10456:EE_|DBBPR03MB10269:EE_
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 
 ffB77fAZj+gHQ+Mbcw3mpI4ATmuFYFQwoEoR5sGHCJ1qte+ig5tRscnoL/r2Y0Ane0AGwxjyvjuSOOOTC7zJQOH0GKsZJdNXUEhEaHXasBBndLSBekwkWlY9uOdr+3y26e1jfmtK5oNyb3uIWRHqNbo8z9ePblClGF065zAD/AGrzdMLx0tZDHalu4sKqZy4U4sAaf9bDOlmqB9NdiX1bxSDkl987DVhGKb6zC2opm9wiv3dNPbGGAdWoJQfiLxvHd7KWmLlgBtF/CkkCfCQbE9bVRmohQg+PZKzxIL2gt4XXIDlI8CqFCm7eZnqYD9vE7UEdit28XmO9E/3+qRbwzHzcqIOiyxto8wP699lVwUmpA9yShkup+adOlufzQ8Jh/8vrwcsNhuF4KWxxaGHYifd27V3Nv/+9gVfOftJ/HpSjluGr1mFIF6JOz+shph/ObI1jNhK10heZlD8xbIxPRSRsivxtaeYE7LkSzmcb0981Pnidstdoogb+QJ6kfssdoymCZbqJCu2PKEIReg3lLQu3ndHJUnV87SGp2Qg2zrcEMGN/tVgLkZoUYYlu8Pa/HIYIy+gSmU6D6FN+gB8RFE/z1OLrf/0AOuPZnYLrltXsYPONOQtE4K8uv1+shiiipOshio4/ANE7ozhCef36bfMGgJp7HGfF/tBpZiNnFw=
x-forefront-antispam-report: 
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV1PR03MB10456.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(1800799015)(366007)(376005);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 
 =?iso-8859-1?Q?bPGljbm3QjV1a3Xo+4IPN/Rb5aru8e48JGikPDzBPRPZcoG6URhVtqgph8?=
 =?iso-8859-1?Q?KcNulMDkrF56z+G5d9it2M/88eovMlYsqxlFhtH53VXjBkRdbTfTr5uyNf?=
 =?iso-8859-1?Q?02Jc2wBT+N7Nhlx8xUrtBw4WPCV1198KQ3rDX6fNStNK9Ej7Q1gBM1whbI?=
 =?iso-8859-1?Q?1T+26s9vkYNxEN/zrWooY8NTzHLVZo+Ew/1iWA7baG9BIIFoWTPBFCr8hS?=
 =?iso-8859-1?Q?5UuTFKy9089Ahu1kEMiO/cTylAYAqvZjE5EtvkAmuPh/wWwxT8OMLYOUST?=
 =?iso-8859-1?Q?B+VN3joXvfdGlx71XIrEm0PlWZOjqAhORYiRUs3Tzu4R80FEzRAqBB+6kl?=
 =?iso-8859-1?Q?wAwMENQclkJ3gYMWn65Vjs1lojxUSK2yF7W6ErH8WKk6RlonSJNtOOycD3?=
 =?iso-8859-1?Q?jh28+rsOxQgzOHJGnVT2SBHW5FZQv0pdGMSgxAccVVrcQEPaXPy3c5FbsS?=
 =?iso-8859-1?Q?9u8NB/gyK1QKE98kPt/O1YlwnoqfBogpY8yzewM2heb178JFcSAB3J0xTN?=
 =?iso-8859-1?Q?OO7yYovQ3qJHv0efBMIRS0ocbfx5JaC/YgDRQezjCkcpI95f/LG79Rgome?=
 =?iso-8859-1?Q?FFnc4VyIBj9MjejxnkHJFvA55n681bDAL8Z7UCYei2faK/JCaFLsJJDgU4?=
 =?iso-8859-1?Q?O7R71uJD3COTWMtpCdX3njQShWJpxbiCgHX7VbbHB1I7XQ2iWhL+UI19Ps?=
 =?iso-8859-1?Q?G8MuN7TCBUPAjEQUD6Bn8R0fdmYRzoiZaNPLAVLvKZ/Siicf5aEecBlBDw?=
 =?iso-8859-1?Q?lhMVYXdc29+TzwAsjQHcMD1fhQuwjC1sWuV8XXhZMgYGHsA9jW43795zHC?=
 =?iso-8859-1?Q?xtmYjjAvGjE8JT4PQScikbSdKBEq4xcv6dLK+WrKi1eGNDcejZ0ocQ5hhU?=
 =?iso-8859-1?Q?AlHQXxc+BMp2t79or9XRj693Lfw36wt5l4nwb5XZTsN2aKCnZWRQliH/1x?=
 =?iso-8859-1?Q?mNsxwUTq1Da1O2xxmynJN8OO5WR11NBbBzEXTT17ie9LHQY8HaAcfh9LfF?=
 =?iso-8859-1?Q?jac/jkg4ZznQ5/v+LZQSasBjNZcj01aIjhjoct5qHVXkZhPzUb2aOyD4LW?=
 =?iso-8859-1?Q?U9D9sjslNfp3smV0fxqasXsaBp+e4c0frQs5oKBfA/TVFMK2TT+NoFCjEP?=
 =?iso-8859-1?Q?p0QPGwqckAsHvKVCLNHHlEJnR9Nj1/+HpEPULXlhKf5F0e8f90C3QGg0iI?=
 =?iso-8859-1?Q?suIdxBoHDlD5QeGR7Q/5DEKmi2cFDUH8xNXbkyFTrrtsIkvUGiGldbhx9i?=
 =?iso-8859-1?Q?Oue9zTHZIbCvy632ZZL1QsKVktRd/ap6qCEgKS0b6IqKAZUo1PCOEqlQ7R?=
 =?iso-8859-1?Q?qOCfqYcH9GeKBgvub/abC8XXykCkSbHmqp0rte6YRyIrEPL53nZZwRUw0e?=
 =?iso-8859-1?Q?Hu7Igyt8WwbcZCgt+rkurBOhjIY4YJqCT/yQVT8EVvhmfos7C/0n3ocBkJ?=
 =?iso-8859-1?Q?iVgUyFhihe38ize/cVE+i1XlTRu5kY/T3HQ4azcgZ4p9rv36uDKgzFuD05?=
 =?iso-8859-1?Q?N7W7qkByHxBI9VjetiXeQLe02e4oAA4hpTg/RCltyw8eTfnhjZ/v+GFPSG?=
 =?iso-8859-1?Q?L6RPZoLY9tHuMPt2FjCgZQAOfrWqC8kSwHHG3VrRVQdROhRg92hu453Mb6?=
 =?iso-8859-1?Q?NEiE89KqktDOs53hhq1KUNNvUXWEZE6CG6rXz+h4/c6uH5CBkGo0hyMQ?=
 =?iso-8859-1?Q?=3D=3D?=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: GV1PR03MB10456.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1421be19-1e18-499a-e698-08dc4f847068
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2024 00:08:57.6067
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ew3iUbR34fOgaJyHxlYZ3m5GG+z8abJLbqZTdCcHTP1AFuyRua3e5FfcD/P9yGFz5kfaUSMPiL2ePe1+mwwNvR/1JqSxl9CgTDJ/435RZ1s=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR03MB10269
X-Proofpoint-ORIG-GUID: 66mp_c7MpvaZoTemczZkdSNP77_HTRty
X-Proofpoint-GUID: 66mp_c7MpvaZoTemczZkdSNP77_HTRty
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26
 definitions=2024-03-28_18,2024-03-28_01,2023-05-22_02
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 mlxscore=0
 phishscore=0 mlxlogscore=999 suspectscore=0 lowpriorityscore=0
 malwarescore=0 priorityscore=1501 spamscore=0 clxscore=1015 adultscore=0
 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.19.0-2403210001 definitions=main-2403280176

Generic Interface (GENI) is a newer interface for low speed interfaces
like UART, I2C or SPI. This patch adds the simple driver for the UART
instance of GENI. Code is based on similar drivers in U-Boot and Linux
kernel.

This driver implements only simple synchronous mode, because although
GENI supports FIFO mode, it needs to know number of
characters **before** starting TX transaction. This is a stark
contrast when compared to other UART peripherals, which allow adding
characters to a FIFO while TX operation is running.

The patch adds both normal UART driver and earlyprintk version.

Signed-off-by: Volodymyr Babchuk 
---
 xen/arch/arm/Kconfig.debug           |  19 +-
 xen/arch/arm/arm64/debug-qcom.inc    |  76 +++++++
 xen/arch/arm/include/asm/qcom-uart.h |  48 +++++
 xen/drivers/char/Kconfig             |   8 +
 xen/drivers/char/Makefile            |   1 +
 xen/drivers/char/qcom-uart.c         | 288 +++++++++++++++++++++++++++
 6 files changed, 439 insertions(+), 1 deletion(-)
 create mode 100644 xen/arch/arm/arm64/debug-qcom.inc
 create mode 100644 xen/arch/arm/include/asm/qcom-uart.h
 create mode 100644 xen/drivers/char/qcom-uart.c

diff --git a/xen/arch/arm/Kconfig.debug b/xen/arch/arm/Kconfig.debug
index eec860e88e..f6ab0bb30e 100644
--- a/xen/arch/arm/Kconfig.debug
+++ b/xen/arch/arm/Kconfig.debug
@@ -119,6 +119,19 @@ choice
 			selecting one of the platform specific options below if
 			you know the parameters for the port.
=20
+			This option is preferred over the platform specific
+			options; the platform specific options are deprecated
+			and will soon be removed.
+	config EARLY_UART_CHOICE_QCOM
+		select EARLY_UART_QCOM
+		bool "Early printk via Qualcomm debug UART"
+		help
+			Say Y here if you wish the early printk to direct their
+			output to a Qualcomm debug UART. You can use this option to
+			provide the parameters for the debug UART rather than
+			selecting one of the platform specific options below if
+			you know the parameters for the port.
+
 			This option is preferred over the platform specific
 			options; the platform specific options are deprecated
 			and will soon be removed.
@@ -211,6 +224,9 @@ config EARLY_UART_PL011
 config EARLY_UART_SCIF
 	select EARLY_PRINTK
 	bool
+config EARLY_UART_QCOM
+	select EARLY_PRINTK
+	bool
=20
 config EARLY_PRINTK
 	bool
@@ -261,7 +277,7 @@ config EARLY_UART_PL011_MMIO32
 	  will be done using 32-bit only accessors.
=20
 config EARLY_UART_INIT
-	depends on EARLY_UART_PL011 && EARLY_UART_PL011_BAUD_RATE !=3D 0
+	depends on (EARLY_UART_PL011 && EARLY_UART_PL011_BAUD_RATE !=3D 0) || EAR=
LY_UART_QCOM
 	def_bool y
=20
 config EARLY_UART_8250_REG_SHIFT
@@ -308,3 +324,4 @@ config EARLY_PRINTK_INC
 	default "debug-mvebu.inc" if EARLY_UART_MVEBU
 	default "debug-pl011.inc" if EARLY_UART_PL011
 	default "debug-scif.inc" if EARLY_UART_SCIF
+	default "debug-qcom.inc" if EARLY_UART_QCOM
diff --git a/xen/arch/arm/arm64/debug-qcom.inc b/xen/arch/arm/arm64/debug-q=
com.inc
new file mode 100644
index 0000000000..130d08d6e9
--- /dev/null
+++ b/xen/arch/arm/arm64/debug-qcom.inc
@@ -0,0 +1,76 @@
+/*
+ * xen/arch/arm/arm64/debug-qcom.inc
+ *
+ * Qualcomm debug UART specific debug code
+ *
+ * Volodymyr Babchuk 
+ * Copyright (C) 2024, EPAM Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+
+.macro early_uart_init xb c
+        mov   w\c, #M_GENI_CMD_ABORT
+        str   w\c, [\xb, #SE_GENI_M_CMD_CTRL_REG]
+1:
+        ldr   w\c, [\xb, #SE_GENI_M_IRQ_STATUS]   /* Load IRQ status */
+        tst   w\c, #M_CMD_ABORT_EN         /* Check TX_FIFI_WATERMARK_EN b=
it */
+        beq   1b                          /* Wait for the UART to be ready=
 */
+        mov   w\c, #M_CMD_ABORT_EN
+        orr   w\c, w\c, #M_CMD_DONE_EN
+        str   w\c, [\xb, #SE_GENI_M_IRQ_CLEAR]
+
+        mov   w\c, #1
+        str   w\c, [\xb, #SE_UART_TX_TRANS_LEN]         /* write len */
+
+        mov   w\c, #(UART_START_TX << M_OPCODE_SHFT)    /* Prepare cmd  */
+        str   w\c, [\xb, #SE_GENI_M_CMD0]               /* write cmd */
+.endm
+/*
+ * wait for UART to be ready to transmit
+ * xb: register which contains the UART base address
+ * c: scratch register
+ */
+.macro early_uart_ready xb c
+1:
+        ldr   w\c, [\xb, #SE_GENI_M_IRQ_STATUS] /* Load IRQ status */
+        tst   w\c, #M_TX_FIFO_WATERMARK_EN  /* Check TX_FIFI_WATERMARK_EN =
bit */
+        beq    1b                           /* Wait for the UART to be rea=
dy */
+.endm
+
+/*
+ * UART transmit character
+ * xb: register which contains the UART base address
+ * wt: register which contains the character to transmit
+ */
+.macro early_uart_transmit xb wt
+        str   \wt, [\xb, #SE_GENI_TX_FIFOn]             /* Put char to FIF=
O */
+        mov   \wt, #M_TX_FIFO_WATERMARK_EN              /* Prepare to FIFO=
 */
+        str   \wt, [\xb, #SE_GENI_M_IRQ_CLEAR]          /* Kick FIFO */
+95:
+        ldr   \wt, [\xb, #SE_GENI_M_IRQ_STATUS]         /* Load IRQ status=
 */
+        tst   \wt, #M_CMD_DONE_EN           /* Check TX_FIFO_WATERMARK_EN =
bit */
+        beq   95b                           /* Wait for the UART to be rea=
dy */
+        mov   \wt, #M_CMD_DONE_EN
+        str   \wt, [\xb, #SE_GENI_M_IRQ_CLEAR]
+
+        mov   \wt, #(UART_START_TX << M_OPCODE_SHFT)    /* Prepare next cm=
d */
+        str   \wt, [\xb, #SE_GENI_M_CMD0]               /* write cmd */
+.endm
+
+/*
+ * Local variables:
+ * mode: ASM
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/include/asm/qcom-uart.h b/xen/arch/arm/include/as=
m/qcom-uart.h
new file mode 100644
index 0000000000..dc9579374c
--- /dev/null
+++ b/xen/arch/arm/include/asm/qcom-uart.h
@@ -0,0 +1,48 @@
+/*
+ * xen/include/asm-arm/qcom-uart.h
+ *
+ * Common constant definition between early printk and the UART driver
+ * for the Qualcomm debug UART
+ *
+ * Volodymyr Babchuk 
+ * Copyright (C) 2024, EPAM Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __ASM_ARM_QCOM_UART_H
+#define __ASM_ARM_QCOM_UART_H
+
+#define SE_UART_TX_TRANS_LEN            0x270
+#define SE_GENI_M_CMD0                  0x600
+#define   UART_START_TX                 0x1
+#define   M_OPCODE_SHFT                 27
+
+#define SE_GENI_M_CMD_CTRL_REG          0x604
+#define   M_GENI_CMD_ABORT              BIT(1, U)
+#define SE_GENI_M_IRQ_STATUS            0x610
+#define   M_CMD_DONE_EN                 BIT(0, U)
+#define   M_CMD_ABORT_EN                BIT(5, U)
+#define   M_TX_FIFO_WATERMARK_EN        BIT(30, U)
+#define SE_GENI_M_IRQ_CLEAR             0x618
+#define SE_GENI_TX_FIFOn                0x700
+#define SE_GENI_TX_WATERMARK_REG        0x80c
+
+#endif /* __ASM_ARM_QCOM_UART_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
index e18ec3788c..52c3934d06 100644
--- a/xen/drivers/char/Kconfig
+++ b/xen/drivers/char/Kconfig
@@ -68,6 +68,14 @@ config HAS_SCIF
 	  This selects the SuperH SCI(F) UART. If you have a SuperH based board,
 	  or Renesas R-Car Gen 2/3 based board say Y.
=20
+config HAS_QCOM_UART
+	bool "Qualcomm GENI UART driver"
+	default y
+	depends on ARM
+	help
+	  This selects the Qualcomm GENI-based UART driver. If you
+	  have a Qualcomm-based board board say Y here.
+
 config HAS_EHCI
 	bool
 	depends on X86
diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile
index e7e374775d..698ad0578c 100644
--- a/xen/drivers/char/Makefile
+++ b/xen/drivers/char/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_HAS_MESON) +=3D meson-uart.o
 obj-$(CONFIG_HAS_MVEBU) +=3D mvebu-uart.o
 obj-$(CONFIG_HAS_OMAP) +=3D omap-uart.o
 obj-$(CONFIG_HAS_SCIF) +=3D scif-uart.o
+obj-$(CONFIG_HAS_QCOM_UART) +=3D qcom-uart.o
 obj-$(CONFIG_HAS_EHCI) +=3D ehci-dbgp.o
 obj-$(CONFIG_XHCI) +=3D xhci-dbc.o
 obj-$(CONFIG_HAS_IMX_LPUART) +=3D imx-lpuart.o
diff --git a/xen/drivers/char/qcom-uart.c b/xen/drivers/char/qcom-uart.c
new file mode 100644
index 0000000000..2614051ca0
--- /dev/null
+++ b/xen/drivers/char/qcom-uart.c
@@ -0,0 +1,288 @@
+/*
+ * xen/drivers/char/qcom-uart.c
+ *
+ * Driver for Qualcomm GENI-based UART interface
+ *
+ * Volodymyr Babchuk 
+ *
+ * Copyright (C) EPAM Systems 2024
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define GENI_FORCE_DEFAULT_REG          0x20
+#define   FORCE_DEFAULT                 BIT(0, U)
+#define   DEF_TX_WM                     2
+#define SE_GENI_TX_PACKING_CFG0         0x260
+#define SE_GENI_TX_PACKING_CFG1         0x264
+#define SE_GENI_RX_PACKING_CFG0         0x284
+#define SE_GENI_RX_PACKING_CFG1         0x288
+#define SE_GENI_M_IRQ_EN                0x614
+#define   M_SEC_IRQ_EN                  BIT(31, U)
+#define   M_RX_FIFO_WATERMARK_EN        BIT(26, U)
+#define   M_RX_FIFO_LAST_EN             BIT(27, U)
+#define SE_GENI_S_CMD0                  0x630
+#define   UART_START_READ               0x1
+#define   S_OPCODE_SHFT                 27
+#define SE_GENI_S_CMD_CTRL_REG          0x634
+#define   S_GENI_CMD_ABORT              BIT(1, U)
+#define SE_GENI_S_IRQ_STATUS            0x640
+#define SE_GENI_S_IRQ_EN                0x644
+#define   S_RX_FIFO_LAST_EN             BIT(27, U)
+#define   S_RX_FIFO_WATERMARK_EN        BIT(26, U)
+#define   S_CMD_ABORT_EN                BIT(5, U)
+#define   S_CMD_DONE_EN                 BIT(0, U)
+#define SE_GENI_S_IRQ_CLEAR             0x648
+#define SE_GENI_RX_FIFOn                0x780
+#define SE_GENI_TX_FIFO_STATUS          0x800
+#define   TX_FIFO_WC                    GENMASK(27, 0)
+#define SE_GENI_RX_FIFO_STATUS          0x804
+#define   RX_LAST                       BIT(31, U)
+#define   RX_LAST_BYTE_VALID_MSK        GENMASK(30, 28)
+#define   RX_LAST_BYTE_VALID_SHFT       28
+#define   RX_FIFO_WC_MSK                GENMASK(24, 0)
+#define SE_GENI_TX_WATERMARK_REG        0x80c
+
+static struct qcom_uart {
+    unsigned int irq;
+    char __iomem *regs;
+    struct irqaction irqaction;
+} qcom_com =3D {0};
+
+static bool qcom_uart_poll_bit(void *addr, uint32_t mask, bool set)
+{
+    unsigned long timeout_us =3D 20000;
+    uint32_t reg;
+
+    while ( timeout_us ) {
+        reg =3D readl(addr);
+        if ( (bool)(reg & mask) =3D=3D set )
+            return true;
+        udelay(10);
+        timeout_us -=3D 10;
+    }
+
+    return false;
+}
+
+static void __init qcom_uart_init_preirq(struct serial_port *port)
+{
+    struct qcom_uart *uart =3D port->uart;
+
+    /* Stop anything in TX that earlyprintk configured and clear all error=
s */
+    writel(M_GENI_CMD_ABORT, uart->regs + SE_GENI_M_CMD_CTRL_REG);
+    qcom_uart_poll_bit(uart->regs + SE_GENI_M_IRQ_STATUS, M_CMD_ABORT_EN,
+                       true);
+    writel(M_CMD_ABORT_EN, uart->regs + SE_GENI_M_IRQ_CLEAR);
+
+    /*
+     * Configure FIFO length: 1 byte per FIFO entry. This is terribly
+     * ineffective, as it is possible to cram 4 bytes per FIFO word,
+     * like Linux does. But using one byte per FIFO entry makes this
+     * driver much simpler.
+     */
+    writel(0xf, uart->regs + SE_GENI_TX_PACKING_CFG0);
+    writel(0x0, uart->regs + SE_GENI_TX_PACKING_CFG1);
+    writel(0xf, uart->regs + SE_GENI_RX_PACKING_CFG0);
+    writel(0x0, uart->regs + SE_GENI_RX_PACKING_CFG1);
+
+    /* Reset RX state machine */
+    writel(S_GENI_CMD_ABORT, uart->regs + SE_GENI_S_CMD_CTRL_REG);
+    qcom_uart_poll_bit(uart->regs + SE_GENI_S_CMD_CTRL_REG,
+                       S_GENI_CMD_ABORT, false);
+    writel(S_CMD_DONE_EN | S_CMD_ABORT_EN, uart->regs + SE_GENI_S_IRQ_CLEA=
R);
+    writel(FORCE_DEFAULT, uart->regs + GENI_FORCE_DEFAULT_REG);
+}
+
+static void qcom_uart_interrupt(int irq, void *data, struct cpu_user_regs =
*regs)
+{
+    struct serial_port *port =3D data;
+    struct qcom_uart *uart =3D port->uart;
+    uint32_t m_irq_status, s_irq_status;
+
+    m_irq_status =3D readl(uart->regs + SE_GENI_M_IRQ_STATUS);
+    s_irq_status =3D readl(uart->regs + SE_GENI_S_IRQ_STATUS);
+    writel(m_irq_status, uart->regs + SE_GENI_M_IRQ_CLEAR);
+    writel(s_irq_status, uart->regs + SE_GENI_S_IRQ_CLEAR);
+
+    if ( s_irq_status & (S_RX_FIFO_WATERMARK_EN | S_RX_FIFO_LAST_EN) )
+        serial_rx_interrupt(port, regs);
+}
+
+static void __init qcom_uart_init_postirq(struct serial_port *port)
+{
+    struct qcom_uart *uart =3D port->uart;
+    int rc;
+    uint32_t val;
+
+    uart->irqaction.handler =3D qcom_uart_interrupt;
+    uart->irqaction.name    =3D "qcom_uart";
+    uart->irqaction.dev_id  =3D port;
+
+    if ( (rc =3D setup_irq(uart->irq, 0, &uart->irqaction)) !=3D 0 )
+        dprintk(XENLOG_ERR, "Failed to allocated qcom_uart IRQ %d\n",
+                uart->irq);
+
+    /* Enable TX/RX and Error Interrupts  */
+    writel(S_GENI_CMD_ABORT, uart->regs + SE_GENI_S_CMD_CTRL_REG);
+    qcom_uart_poll_bit(uart->regs + SE_GENI_S_CMD_CTRL_REG,
+                       S_GENI_CMD_ABORT, false);
+    writel(S_CMD_DONE_EN | S_CMD_ABORT_EN, uart->regs + SE_GENI_S_IRQ_CLEA=
R);
+    writel(FORCE_DEFAULT, uart->regs + GENI_FORCE_DEFAULT_REG);
+
+    val =3D readl(uart->regs + SE_GENI_S_IRQ_EN);
+    val =3D S_RX_FIFO_WATERMARK_EN | S_RX_FIFO_LAST_EN;
+    writel(val, uart->regs + SE_GENI_S_IRQ_EN);
+
+    val =3D readl(uart->regs + SE_GENI_M_IRQ_EN);
+    val =3D M_RX_FIFO_WATERMARK_EN | M_RX_FIFO_LAST_EN;
+    writel(val, uart->regs + SE_GENI_M_IRQ_EN);
+
+    /* Send RX command */
+    writel(UART_START_READ << S_OPCODE_SHFT, uart->regs + SE_GENI_S_CMD0);
+    qcom_uart_poll_bit(uart->regs + SE_GENI_M_IRQ_STATUS, M_SEC_IRQ_EN,
+                       true);
+}
+
+static void qcom_uart_putc(struct serial_port *port, char c)
+{
+    struct qcom_uart *uart =3D port->uart;
+    uint32_t irq_clear =3D M_CMD_DONE_EN;
+    uint32_t m_cmd;
+    bool done;
+
+    /* Setup TX */
+    writel(1, uart->regs + SE_UART_TX_TRANS_LEN);
+
+    writel(DEF_TX_WM, uart->regs + SE_GENI_TX_WATERMARK_REG);
+
+    m_cmd =3D UART_START_TX << M_OPCODE_SHFT;
+    writel(m_cmd, uart->regs + SE_GENI_M_CMD0);
+
+    qcom_uart_poll_bit(uart->regs + SE_GENI_M_IRQ_STATUS,
+                       M_TX_FIFO_WATERMARK_EN, true);
+
+    writel(c, uart->regs + SE_GENI_TX_FIFOn);
+    writel(M_TX_FIFO_WATERMARK_EN, uart->regs + SE_GENI_M_IRQ_CLEAR);
+
+    /* Check for TX done */
+    done =3D qcom_uart_poll_bit(uart->regs + SE_GENI_M_IRQ_STATUS, M_CMD_D=
ONE_EN,
+                              true);
+    if ( !done )
+    {
+        writel(M_GENI_CMD_ABORT, uart->regs + SE_GENI_M_CMD_CTRL_REG);
+        irq_clear |=3D M_CMD_ABORT_EN;
+        qcom_uart_poll_bit(uart->regs + SE_GENI_M_IRQ_STATUS, M_CMD_ABORT_=
EN,
+                           true);
+
+    }
+    writel(irq_clear, uart->regs + SE_GENI_M_IRQ_CLEAR);
+}
+
+static int qcom_uart_getc(struct serial_port *port, char *pc)
+{
+    struct qcom_uart *uart =3D port->uart;
+
+    if ( !readl(uart->regs + SE_GENI_RX_FIFO_STATUS) )
+        return 0;
+
+    *pc =3D readl(uart->regs + SE_GENI_RX_FIFOn) & 0xFF;
+
+    writel(UART_START_READ << S_OPCODE_SHFT, uart->regs + SE_GENI_S_CMD0);
+    qcom_uart_poll_bit(uart->regs + SE_GENI_M_IRQ_STATUS, M_SEC_IRQ_EN,
+                       true);
+
+    return 1;
+
+}
+
+static struct uart_driver __read_mostly qcom_uart_driver =3D {
+    .init_preirq  =3D qcom_uart_init_preirq,
+    .init_postirq =3D qcom_uart_init_postirq,
+    .putc         =3D qcom_uart_putc,
+    .getc         =3D qcom_uart_getc,
+};
+
+static const struct dt_device_match qcom_uart_dt_match[] __initconst =3D
+{
+    { .compatible =3D "qcom,geni-debug-uart"},
+    { /* sentinel */ },
+};
+
+static int __init qcom_uart_init(struct dt_device_node *dev,
+                                 const void *data)
+{
+    const char *config =3D data;
+    struct qcom_uart *uart;
+    int res;
+    paddr_t addr, size;
+
+    if ( strcmp(config, "") )
+        printk("WARNING: UART configuration is not supported\n");
+
+    uart =3D &qcom_com;
+
+    res =3D dt_device_get_paddr(dev, 0, &addr, &size);
+    if ( res )
+    {
+        printk("qcom-uart: Unable to retrieve the base"
+               " address of the UART\n");
+        return res;
+    }
+
+    res =3D platform_get_irq(dev, 0);
+    if ( res < 0 )
+    {
+        printk("qcom-uart: Unable to retrieve the IRQ\n");
+        return res;
+    }
+    uart->irq =3D res;
+
+    uart->regs =3D ioremap_nocache(addr, size);
+    if ( !uart->regs )
+    {
+        printk("qcom-uart: Unable to map the UART memory\n");
+        return -ENOMEM;
+    }
+
+    /* Register with generic serial driver */
+    serial_register_uart(SERHND_DTUART, &qcom_uart_driver, uart);
+
+    dt_device_set_used_by(dev, DOMID_XEN);
+
+    return 0;
+}
+
+DT_DEVICE_START(qcom_uart, "QCOM UART", DEVICE_SERIAL)
+    .dt_match =3D qcom_uart_dt_match,
+    .init =3D qcom_uart_init,
+DT_DEVICE_END
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
--=20
2.43.0


From xen-devel-bounces@lists.xenproject.org Fri Mar 29 00:09:31 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Mar 2024 00:09:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699207.1091891 (Exim 4.92)
	(envelope-from )
	id 1rpzo4-0002Ao-Rp; Fri, 29 Mar 2024 00:09:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699207.1091891; Fri, 29 Mar 2024 00:09:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpzo4-0002Ah-Oq; Fri, 29 Mar 2024 00:09:16 +0000
Received: by outflank-mailman (input) for mailman id 699207;
 Fri, 29 Mar 2024 00:09:15 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpzo3-0002AV-9o
 for xen-devel@lists.xenproject.org; Fri, 29 Mar 2024 00:09:15 +0000
Received: from mx0b-0039f301.pphosted.com (mx0b-0039f301.pphosted.com
 [148.163.137.242]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9281a502-ed60-11ee-afe3-a90da7624cb6;
 Fri, 29 Mar 2024 01:09:13 +0100 (CET)
Received: from pps.filterd (m0174682.ppops.net [127.0.0.1])
 by mx0b-0039f301.pphosted.com (8.17.1.24/8.17.1.24) with ESMTP id
 42SN0uDx024084; Fri, 29 Mar 2024 00:09:04 GMT
Received: from eur05-vi1-obe.outbound.protection.outlook.com
 (mail-vi1eur05lp2168.outbound.protection.outlook.com [104.47.17.168])
 by mx0b-0039f301.pphosted.com (PPS) with ESMTPS id 3x5huq82q0-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Fri, 29 Mar 2024 00:09:04 +0000 (GMT)
Received: from GV1PR03MB10456.eurprd03.prod.outlook.com
 (2603:10a6:150:16a::21) by DBBPR03MB10269.eurprd03.prod.outlook.com
 (2603:10a6:10:536::7) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.31; Fri, 29 Mar
 2024 00:08:57 +0000
Received: from GV1PR03MB10456.eurprd03.prod.outlook.com
 ([fe80::74c9:2488:1dd7:b976]) by GV1PR03MB10456.eurprd03.prod.outlook.com
 ([fe80::74c9:2488:1dd7:b976%3]) with mapi id 15.20.7409.028; Fri, 29 Mar 2024
 00:08:57 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9281a502-ed60-11ee-afe3-a90da7624cb6
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=SA/jWBmZHc64EXnv8XLJd+QVP2pqKMTY1raKm+rmc0WU00FslGLKj83wXBqJU6y5UirxgW9f1Y1N9OxwVlcNFCq9k6ozPMwjjxJRv16UIJmQ82GLJoqhbtFuSKM/5ToS0s54fAFbv6HOj4HZi2cslrTUNpfYsdl89EFZ8jHXbrPdUxZmnUT45oRo9+8ei7Cz0NuqOnLFbCp+nyjrasPLDLmpuQPzR49zf1Y9QMMRaby56Il6fy3FiDobM76kgPjiYJ+4jc9ocao+6Nde2x74NFZGcf/5ZxysyXUM1yi5Xa+y+x8vjBFisgnNxrOJjk+4yQsl1CoCfOLmt73BLCaxVA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=aNwLL5EFtPErBpKqK/PepsfxNRpo4RG+OPLoy/Mv+t8=;
 b=n5K9sP6r//eKRJxD+VrFl7TBJtUED77goKgOrNf0ALY8yLyVXSHctNU/Lm3YlWu8sKnTEslKG8RLhrY6aFL5rmice+oi314q48g7hpWvZMmzltE53CuIU6oRO3aMBuS58O6iSl28aMa9obf53kma/SY3GF5KzRHpfqyv6m486xM1xUi0eNhkHeVMvwkGfF4FFHxJZnfwz7iIsH2DggaUsjafv41e15L3f3OclOUUVfQTi/v1RYe7a7UarF20G2nl3plPEssbNFRHJYH/zYZyj+OObWBKQRbZN/bnRgduqHRDLrqkr4aQVP92AET+7aC5G8upvrb3rQeMuQgg4BiZMg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector2;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=aNwLL5EFtPErBpKqK/PepsfxNRpo4RG+OPLoy/Mv+t8=;
 b=YQpgV3sMUynw2xAZIqaVjc6eYfqOe5+NcJd52SHY1yvJ/jpdPrv+88WWnFJYPCj0V7/ShKuwHWMZkDUya1IvL3uEv4ti1t6fUcMqESXjhIq/zaLDL9SJ8Jugi6RPD3sNn3chi46uMgEoIGcKrPAJuNLNdfEOM34bMckkk84QWj0p8HBD3SCgNrLwpbPGealvIUazimwgkb9S2Q3Mhkrzq8eJ3jjgeTOWSPGZBDIKpy9MFOc3G8k8+q/AJF10l850pZHKSTnH27KYhF5+cnvwgq1UlFtUwFl9vUvwTW8KIEY5zIHzBDyZFj9ZEZFx0g1F+iJOUlulk8m4TeRJFpFa6w==
From: Volodymyr Babchuk 
To: "xen-devel@lists.xenproject.org" 
CC: Volodymyr Babchuk ,
        Julien Grall
	, Rahul Singh ,
        Stefano Stabellini
	,
        Bertrand Marquis ,
        Michal
 Orzel ,
        Volodymyr Babchuk ,
        Andrew Cooper ,
        George Dunlap
	,
        Jan Beulich , Wei Liu
	
Subject: [PATCH 0/3] Add experimental support for Qualcomm SA8155P SoC
Thread-Topic: [PATCH 0/3] Add experimental support for Qualcomm SA8155P SoC
Thread-Index: AQHagW1KwAubBrJ/1UWKSSJWd4T4nA==
Date: Fri, 29 Mar 2024 00:08:56 +0000
Message-ID: <20240329000822.3363568-1-volodymyr_babchuk@epam.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: git-send-email 2.43.0
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: GV1PR03MB10456:EE_|DBBPR03MB10269:EE_
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 
 dJsUJl/endb+JG5VMeNBXAnO8XOFNIsY2JtyPWKaCXmREraIkSX3iLZKk3jqa34rpBfA7Bt8h2HFP1gAnHssO7EgLsRCS7f3gV5+TummA7jk3dToAS2tupI7HtMhhL/ib1Xgy7Nawbpk9ZSsrcmdtfGcWeRMTn3I0HdPqKd0A9UIDjOX9QgbAP73x1QQGdXiOXTYme9LNLvPbyU2vSh60Q9h9EI5akM2/2OwJ6B7/yeQbKIExQ3jmlG4ulPSMGATXPrvVr3QW4qCHwpQpiMGipdwN1jJWMyfn4jxCzf2zX7C1EjzxhvmQS7iE1HU/q3ZyP4N8v2QTTsACsdKqDV4mwbJhwCA0CCRAaWK9zYKZ0NbWLr5Fn658txpbwbknmoyfBLIpvpeacH0CQlSnDeq6WSSkvaDiWLLAs3X8YJQoh0m5db1my2TO/Rd6OGl03PeN5ddn7kbPwsAOxRNWU5PmWAtj45F8N8tmmU7sYQ9pxBMXWuK/naj1h5txOS3mOkt+1RG9WDw/NBfJOMh9n9jxADdwIYqCSJTHZAJKBjI8eYbqD6cWMCj33Ie1euTXtS8G6DQoCimJC/T/hgjhWQKqOz+ZhZE2PfwW4SG81GdzBlpY/1F2HnypLpWiw+jj3arMHKZBZtlKu+NTKoMzEM4gqp7WW7Zpy/ooEuXIwsdcF4=
x-forefront-antispam-report: 
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV1PR03MB10456.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(7416005)(1800799015)(366007)(376005);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 
 =?iso-8859-1?Q?oYzTQY32RXyAWB/AjKjzP+i7C8wtXpKBy9KEWqTUZgF6jnfTHn/YufuI8o?=
 =?iso-8859-1?Q?572P6YfFy+EGmd/tGeNf5H91pwT2dvgHfjQoBvFEPG3cjIfJOl/JmEfYqX?=
 =?iso-8859-1?Q?OWqh638y4rU32RXBDcuBxXD5rASZnlfl2c1DlnYrBDTFZ8LBzoxT2PtDyp?=
 =?iso-8859-1?Q?LRdes7gzGw8Znu4eK76n+x6uag06Ky7lU1AI3n6oTz7XU83JBd6OZ1tdxe?=
 =?iso-8859-1?Q?UHKOMdXDFpB61sstF73hvb/3D38zBdB/m0EkBIq9nW7fQUIYxcAiTHvMjU?=
 =?iso-8859-1?Q?N7LCxfuXLbUO86dsnXbUvv1Z0LuDup0amur/Cd5OIaRU6P97J5IS6jGR0y?=
 =?iso-8859-1?Q?1oRDBZsu8vdZ8blZF8PPmy+1hnUSLl5+X7xkbMtcTvBbJW+SvMpAke/yca?=
 =?iso-8859-1?Q?NG1buuPz6imFOEg8RRVqnsXjptq4pTP5C4tK5U8Cl3oTuFh31hp5B1nwGV?=
 =?iso-8859-1?Q?wMuq1ZDzUPge1Db3hbEctg84wB2xVhRIj4kiidQIxo4kTAlEnsJY6zv+QT?=
 =?iso-8859-1?Q?CrSA64AJlS192ZqcJyE2kI0PFDkJvd0LnzUKd3LTCXwPqFYKGB7wj/+xF7?=
 =?iso-8859-1?Q?aBE7xZZKmzC+OObvEUSiJ/PKvmcbFw49EYM+J97Ihw/xi98ALYVEF95bq/?=
 =?iso-8859-1?Q?prfuJpomUgE0wlSWd7Bj4QVGyavu/J6zek8qmGSgm7VlnTQEjUo24tEeTT?=
 =?iso-8859-1?Q?7tWDi0kR/4uUesGF3ZCdLzXy3tRtC9uXi6EZfM0nIMjszSwUGx4lwZbgKF?=
 =?iso-8859-1?Q?Ue2byEJEnCeI7L+H/HCLVjvhHGST7PeJOL78KOFJdDDaFBCcElBtsgwd3H?=
 =?iso-8859-1?Q?RME8npwLXLKQnJZyrXKvskoUnvu0EZfO8MZLoABwGRnINvGjlVk/tqqzR4?=
 =?iso-8859-1?Q?cPclkYCDYHcGi84UDseqYtmw35UmfKw+D9eOmnTZk5LkA2STCdbB+ZmzP2?=
 =?iso-8859-1?Q?h/SCuP/H8TavDY9zkgxmudtm+ZbKkRyvXhF/1CfRJUvsTd0QUA1Lv1DaYE?=
 =?iso-8859-1?Q?JRHKlpSiWTJmTtdvOOiByuvu2EZKv9+vaUC48fFT6q3g92ZJ+iEMHEb+qG?=
 =?iso-8859-1?Q?OZHa1X1gJrAqfEe8+erS1r75Q+NL6B6PByfQOPbI4AYDoJYOXiFFkP76jx?=
 =?iso-8859-1?Q?4aLzZylujOyDqdnCIN2J6nYVywzv2zh7OdM8IPc2W0NqqSUcdPb+fDlmcH?=
 =?iso-8859-1?Q?i///U6Oz+ZF2HRgwT048sQb9P7SUEilFhZI1aEjHZJSc5ul+m66XCO6JWl?=
 =?iso-8859-1?Q?eeBB81J/os2i0jsUuAgTfYvTvDHuFjTappPeAyPjVAG7Gm+bGwtuRRsQdz?=
 =?iso-8859-1?Q?At+BNfGs6r4O8sSXDDdTHBoz1At7b4P53ZEVvy0TMVLnZFhL678th+SWWj?=
 =?iso-8859-1?Q?6PnPrrVT/YyOUrE8xIychtzRutAVkW7MzkhjnrmX7btw40Y8pXyqXZ0Cmc?=
 =?iso-8859-1?Q?XmdIKbE9SZgvnBa22VhwJekodUg9cvmpKOugLz88qCiSufeZKsIJLzGg+N?=
 =?iso-8859-1?Q?LfqMHa51YO21utegmxyeyy99uP4e/rfp7x/U3m1VXFli/f6b3Vdrj9y6d2?=
 =?iso-8859-1?Q?rh+0QH02emFKiDEWfFpliyZ51fuatG2cEenFjnlACZ9eilby2BRhqy6TKj?=
 =?iso-8859-1?Q?dqp4RWQzO47Ct74VRiRiLLSH9xok14+MEStdbpzpxbTtW07C8PsHYstw?=
 =?iso-8859-1?Q?=3D=3D?=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: GV1PR03MB10456.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8947ea38-cfe1-4d2b-cbad-08dc4f846d6f
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2024 00:08:56.9659
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 4sP7qo9fFOV08c3hqivrQDFUmMcsOytlQeZOQ3KdByNrsVh6QKCdqcG3LY0prZa4NkteMV2lqeAd0Yu4qmJs8vmih4uxtj8Dmy4/2l3Hogo=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR03MB10269
X-Proofpoint-ORIG-GUID: 6lC2D0-zenb9ZxxizFSYELvLOOEFJOXL
X-Proofpoint-GUID: 6lC2D0-zenb9ZxxizFSYELvLOOEFJOXL
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26
 definitions=2024-03-28_18,2024-03-28_01,2023-05-22_02
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 mlxscore=0
 phishscore=0 mlxlogscore=657 suspectscore=0 lowpriorityscore=0
 malwarescore=0 priorityscore=1501 spamscore=0 clxscore=1011 adultscore=0
 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.19.0-2403210001 definitions=main-2403280176

Hello,

This three patches are all what is needed to run Xen on Qualcomm
SA8155P. At the time of writing, I have a working setup with
(almost) mainline Linux kernel in Dom0, where basic features like UFS
and networking are working fine, but more advanced things like GPU are
not supported yet.

Volodymyr Babchuk (3):
  arm: smmu: allow SMMU to have more IRQs than context banks
  drivers: serial: add Qualcomm GENI-based serial driver
  arm: platform: qcom: add basic support SA8155P SoC

 xen/arch/arm/Kconfig.debug           |  19 +-
 xen/arch/arm/arm64/debug-qcom.inc    |  76 +++++++
 xen/arch/arm/include/asm/qcom-uart.h |  48 +++++
 xen/arch/arm/platforms/Makefile      |   1 +
 xen/arch/arm/platforms/qcom.c        |  77 +++++++
 xen/drivers/char/Kconfig             |   8 +
 xen/drivers/char/Makefile            |   1 +
 xen/drivers/char/qcom-uart.c         | 288 +++++++++++++++++++++++++++
 xen/drivers/passthrough/arm/smmu.c   |   2 +-
 9 files changed, 518 insertions(+), 2 deletions(-)
 create mode 100644 xen/arch/arm/arm64/debug-qcom.inc
 create mode 100644 xen/arch/arm/include/asm/qcom-uart.h
 create mode 100644 xen/arch/arm/platforms/qcom.c
 create mode 100644 xen/drivers/char/qcom-uart.c

--=20
2.43.0


From xen-devel-bounces@lists.xenproject.org Fri Mar 29 00:09:31 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Mar 2024 00:09:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699209.1091911 (Exim 4.92)
	(envelope-from )
	id 1rpzo6-0002dM-AW; Fri, 29 Mar 2024 00:09:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699209.1091911; Fri, 29 Mar 2024 00:09:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rpzo6-0002dF-7J; Fri, 29 Mar 2024 00:09:18 +0000
Received: by outflank-mailman (input) for mailman id 699209;
 Fri, 29 Mar 2024 00:09:16 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rpzo4-0002Ab-PI
 for xen-devel@lists.xenproject.org; Fri, 29 Mar 2024 00:09:16 +0000
Received: from mx0b-0039f301.pphosted.com (mx0b-0039f301.pphosted.com
 [148.163.137.242]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9315c516-ed60-11ee-a1ef-f123f15fe8a2;
 Fri, 29 Mar 2024 01:09:14 +0100 (CET)
Received: from pps.filterd (m0174682.ppops.net [127.0.0.1])
 by mx0b-0039f301.pphosted.com (8.17.1.24/8.17.1.24) with ESMTP id
 42SN0uE2024084; Fri, 29 Mar 2024 00:09:07 GMT
Received: from eur05-vi1-obe.outbound.protection.outlook.com
 (mail-vi1eur05lp2168.outbound.protection.outlook.com [104.47.17.168])
 by mx0b-0039f301.pphosted.com (PPS) with ESMTPS id 3x5huq82q0-4
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Fri, 29 Mar 2024 00:09:06 +0000 (GMT)
Received: from GV1PR03MB10456.eurprd03.prod.outlook.com
 (2603:10a6:150:16a::21) by DBBPR03MB10269.eurprd03.prod.outlook.com
 (2603:10a6:10:536::7) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.31; Fri, 29 Mar
 2024 00:09:02 +0000
Received: from GV1PR03MB10456.eurprd03.prod.outlook.com
 ([fe80::74c9:2488:1dd7:b976]) by GV1PR03MB10456.eurprd03.prod.outlook.com
 ([fe80::74c9:2488:1dd7:b976%3]) with mapi id 15.20.7409.028; Fri, 29 Mar 2024
 00:09:02 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9315c516-ed60-11ee-a1ef-f123f15fe8a2
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=D97MIawLmQwsTLx66x1lIxjGCayzR1FGCIk9IFmaNQ48WCJfORvgC9p6h7SzJVFndTvsmzRkdnb8IqDZV4lZC2gfYyvQtB+V7SDtl75plLh1awRnNMWc/q/LNA4x+HzbjBtj8MJ7jwfZ+RHq6fc449wKnFJj0wkWwELIpqbBhCBkyxl4iT//typWK7AVwihIRV4uGA4lf0CuZvePk76YSJ32LUMKxUDsJYcCYl2l08Cq9hGF39YBt7Au9F/kjwsh9B4s0JjkrPAR58RZsDKQo/eA5V8OkWuethJZ0FOpNVCmfl9w6N09esHpdiImBD2W/YpvhDdzkT+RJzXUwoM1FA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=MH1butYk+sVQ3P+oDpW9nG8CNGBCKGfZjsvyXmRUE3A=;
 b=co+NxXayP95jU+gfpouspVixkc+2fQ9nHQ87swqs9PssV7+NK6bLhOtKevMtr63b+AyJRtX+2eDrK3l/8q+YzS01FNtARRZr0pF4kN+kxCTqQ9TOOxflitvARLb5kU56XtbFzilHZGyY9tU10E60VrTYVgKRaGB1YnpMklGaXlVPdr6jLHIapZrBiI0ehj1HVXmsfalUZji8sQTqOy7ym6/nQWqS5zTBTZGQ5p620PFkYftQStf5WASqA1zqA6tmtva0IUln/kOZYWkWJfA/Z3OE1+qzhwVRXn51PcRDTD190bcBnJtvAPcUTjwyEXUQJgPv+4GANetQYIWCFx3Xdw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector2;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=MH1butYk+sVQ3P+oDpW9nG8CNGBCKGfZjsvyXmRUE3A=;
 b=kopJppY+vRvxMYGbii77qInqB6MqZA+gBrr8lXP4kFkyIKXuLXDj+bM7w9pd/GnYuHoaQUDAvZGstqiZEKFUKeBYNfEAaa+vaZcgEC9sXiCn7Qi98ro06Ohk0Mnp5stfsaYVNwASYDvaF7Iy9vf9YPBeD5PHv+o0ShzKjYB/gXzN6mmj+fO4/8KpSXXg+7JtjR7dwivnrdb33U0Ap2wU1tNp1Vj/gnhfWvuccY7GxLx4WvwEVJTGmDZU1m+hKTGShCQyYsBsp+VB8d7C33wkMfR7x8GvJD10yN0CogjYfDWmwi+fuZ/o21WC/y0W60ZBGjPdPmTDtZg6USF38JdFXg==
From: Volodymyr Babchuk 
To: "xen-devel@lists.xenproject.org" 
CC: Volodymyr Babchuk ,
        Stefano Stabellini
	,
        Julien Grall ,
        Bertrand Marquis
	,
        Michal Orzel ,
        Volodymyr
 Babchuk 
Subject: [PATCH 3/3] arm: platform: qcom: add basic support SA8155P SoC
Thread-Topic: [PATCH 3/3] arm: platform: qcom: add basic support SA8155P SoC
Thread-Index: AQHagW1LlGLM/ZuGTEiUoHPlQw1VXw==
Date: Fri, 29 Mar 2024 00:08:57 +0000
Message-ID: <20240329000822.3363568-4-volodymyr_babchuk@epam.com>
References: <20240329000822.3363568-1-volodymyr_babchuk@epam.com>
In-Reply-To: <20240329000822.3363568-1-volodymyr_babchuk@epam.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: git-send-email 2.43.0
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: GV1PR03MB10456:EE_|DBBPR03MB10269:EE_
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 
 AeNgULbtw740pLR3Jqn4qCH5llW28Ludng8RNxywu3mE/Da5cyA9TA0covI3wgOyRK3DkvZIN56Gv6Rn4Bc3Ds4zAU6+MxawMLpaz3nchCK8kVBBVYtWsvBTh0T2YEKF96FekfJFjjgm9EiYDuEhqrU5f9W6TWfqmlxtiGMDY3/1+R7Q8ch6MEns2jM9vGQRGzAlMoiPvhxlJIpECl1CnTB9u5C3oEyqrYFYGvOcEcaOj7CU5/zw0LHHVd1ZS1uvdaaoqZjzkDgw9v+akUaPh0/wqa5/hNMDuU9hWOgLDNH0RR/dvBRa+l7e7qyB2mthDV1lJlJYpupBN+r0po6HHL7qOSF5Gft9Unl0EK90ICVWgNVJSqfY+g88sQCRMVYDP7f78C+/uQ/zZBLonGhw4KmN7mnQNxETJXCmywfYeA3IEX1JExeRfBDG8AbR+HTSUXQKTZT5e9Q9YwfOL4W/oLqq6nq+tz3zA4iiCbvCZ5rd7uEGUYLuV07ofDtBgni4dgMeB3YgdfJ/BddU+K2zENz9Iy+0P7lNqxHZqNYpqiCd6CbC9b9EVzI2XV/nCOcHdUfRRDhW9VcBuJqZxGFTbVtTkbddqiZ7/n9rPg9si0zg/URlURugPkF/992Q/tmWmkcFRP8dWVR7IN/J61fIu+OXH7YI7JaVTYjEz5dLJxs=
x-forefront-antispam-report: 
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV1PR03MB10456.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(1800799015)(366007)(376005);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 
 =?iso-8859-1?Q?vs+qj7UWal21jwjnarbSbPkggjT9XF3JFLo9hXp0MsHUkKUVRiqaZ+EjZi?=
 =?iso-8859-1?Q?TuBU9k2WH4HwlsYYXGkrch8D61lAT+/jj4UaoZDoLHeMUORJe2uLd9OhTQ?=
 =?iso-8859-1?Q?4KvNegL8Jmk7DPvi1AdL/1PZrXipL5C0a0U+egBwi0BSlyM+ABBHyVaP4R?=
 =?iso-8859-1?Q?9MQ+cAaN+YNlJXXQuzE5piuV35324jG6+idsFOTZIkcI3IEBQ03TqeJnsM?=
 =?iso-8859-1?Q?VZrasEZWkE7GgeO7xvVxuSROzUachJMLA/yNdYnarVTcLZgBM2DFbZjX+0?=
 =?iso-8859-1?Q?+nHi7t2z94mfdFCcuVysR2uImLXfAkaKov4wXwtPFZ2dFrDJjWr7z/LLbu?=
 =?iso-8859-1?Q?q/98itATlDgkivBRI4KnPEPKI8DgOUCRkZqVcBWZEfr21Kx39mmY/B+eRx?=
 =?iso-8859-1?Q?NRdGqLdCTXseKSUHqJGqQxt7ZC//MVO8YvyFWUuPjcy7hGEzh1X1NVafZL?=
 =?iso-8859-1?Q?GPC56OQ1cxhnmAwpdsiy168z2WRb8bZ8imHtMOLLOtOyWgXoA40mDTEdQR?=
 =?iso-8859-1?Q?GrGsiTi5i7GJhPviC2G5zxXs2DEgESmRVqX8o0+52pZol3C96PnCjv3i0B?=
 =?iso-8859-1?Q?dM+6JFTYeUs6EW1eO83S8v2bUbILCi31ad7YBASJd5hiy3pbWGQZOY22Rk?=
 =?iso-8859-1?Q?DXNExlzYcM3/ZnQrqIEZnMX9WwumfLs0d9Ia44nzR8tgo7XS9b6g+KjRqQ?=
 =?iso-8859-1?Q?hrOxepi+NfrRt/RQcQjNjm6goHZ/O1Le/bgw5NZNCPfFGEOzNOdIE1YG8S?=
 =?iso-8859-1?Q?9mF5hZ34Mp3fc5cZ8YWMVNHJrtco6qTkKJ+fIaHdZvmDBbTnrhqvSkWnio?=
 =?iso-8859-1?Q?IOBNKo4RgVcxj2ac65rV82B5EQZu4dMtJRYs38BD/zOgL07SzmcgVHFYxy?=
 =?iso-8859-1?Q?DTaAWVsc7p0S6ZLB4rwq2RGhIJTFBWH9lWmQdRmotgNaqu3KzYZxR4DI6N?=
 =?iso-8859-1?Q?vATTDdCTDBT2Hf++3DguNW3fCSuPvWdUcb+02+MauMoOkoblMkCtJxCzii?=
 =?iso-8859-1?Q?nz2yKixPE3S2OzjkuaQCRMmtLah11ejSyYGWGTJpj6kgh2SXntXas/kUM2?=
 =?iso-8859-1?Q?1ijGJBuyIYvMJyTVGMM1hRl8HsZaJikuVA5P13V0qOfkmueK8QdYZ5r4CM?=
 =?iso-8859-1?Q?GYvKj84MZBgkQFijObEKGR5BjqRZB/hCRcAyeD++wZxNJY6L+jP31Y4RF/?=
 =?iso-8859-1?Q?T0jAaPp4wTa2mkC4aL+JBVRTp/Xj1uessbU/zAxomhSuANgW69ahiAte3K?=
 =?iso-8859-1?Q?whj3Tl0b/9JQn7NpbFVMB50VZpWPQ2TFHhP3HssnKAUsSS9030dyzqdN65?=
 =?iso-8859-1?Q?mVz73hZuXxVwQE89zzYQcJlScC+bMRl9p+0X2oabqvdf/ZBbeDAVaGfxR3?=
 =?iso-8859-1?Q?plo6bcsFOA5AbF4BCNvO8PVxBKxvUjJ0GI2+D2hKQJMBok0An+4PPNUCPj?=
 =?iso-8859-1?Q?xnXQH4u5+PjEEFgKIEPJpbRxjnITZZvcakCyd3gYqefFn4KlZLn9hRAXE7?=
 =?iso-8859-1?Q?wnWiyTsmTFnFrbnraIhwq2bDlvr9Fkch6fELrORQ9zHeGJOhf8abQKA84T?=
 =?iso-8859-1?Q?w4VPKMrwgB+uJpj0LOBHr9MqhzHgy/1XCaMaxxnnhOZRu1HiKm7+m7hFZK?=
 =?iso-8859-1?Q?WZERDhbKTYPWz65v5NCuSVBr6V8rgyJL/COubC8m5glm+T1BGOEtumhw?=
 =?iso-8859-1?Q?=3D=3D?=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: GV1PR03MB10456.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 00ade332-51ff-4e28-7614-08dc4f8470a3
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2024 00:08:57.8670
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 46/wWUq9u3U3AY3/Led7oOhEkYiw9vQib9IIJtQXp0kjnpXrr9PUteyiux5DYYAD9uexlFZVnLQIBy/OVSbZ12pwB7Po+26rC2yZ+Cbo/qY=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR03MB10269
X-Proofpoint-ORIG-GUID: BlPPZwPXMa1lXMr60BeXXkkHGXwUdR_8
X-Proofpoint-GUID: BlPPZwPXMa1lXMr60BeXXkkHGXwUdR_8
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26
 definitions=2024-03-28_18,2024-03-28_01,2023-05-22_02
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 mlxscore=0
 phishscore=0 mlxlogscore=999 suspectscore=0 lowpriorityscore=0
 malwarescore=0 priorityscore=1501 spamscore=0 clxscore=1015 adultscore=0
 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.19.0-2403210001 definitions=main-2403280176

Qualcomm SA8155P is the automotive variant of SM8150 aka Snapdragon
855.

This patch adds very basic support for the platform. We need to handle
Qualcomm-specific SMC to workaround quirk in the QCOM SCM driver in
the Linux kernel. Basically the driver tries multiple different SMCs
to determine which calling convention is supported by a SoC. If all
calls fail it decides that the SoC uses "legacy SMC" and tries to
communicate with SCM by issuing SMC with funcid =3D 1. Problem is that
Xen has own understanding on how such SMC should be handled. It
interprets this SMC as legacy PSCI_cpu_off and happily turns of Linux
boot CPU.

To workaround this, we pretend that we support
QCOM_SCM_INFO_IS_CALL_AVAIL, this will make the driver use the latest
calling convention. All subsequent calls will fail anyways and the
driver will terminate self gracefully. This is not a big deal, because
right now (with Linux 6.8) even on baremetal setup the driver fails
anyways, because it does not know how to work with this SoC.

Signed-off-by: Volodymyr Babchuk 
---
 xen/arch/arm/platforms/Makefile |  1 +
 xen/arch/arm/platforms/qcom.c   | 77 +++++++++++++++++++++++++++++++++
 2 files changed, 78 insertions(+)
 create mode 100644 xen/arch/arm/platforms/qcom.c

diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makef=
ile
index 8632f4115f..6873735ef0 100644
--- a/xen/arch/arm/platforms/Makefile
+++ b/xen/arch/arm/platforms/Makefile
@@ -9,5 +9,6 @@ obj-$(CONFIG_ALL_PLAT)   +=3D sunxi.o
 obj-$(CONFIG_ALL64_PLAT) +=3D thunderx.o
 obj-$(CONFIG_ALL64_PLAT) +=3D xgene-storm.o
 obj-$(CONFIG_ALL64_PLAT) +=3D brcm-raspberry-pi.o
+obj-$(CONFIG_ALL64_PLAT) +=3D qcom.o
 obj-$(CONFIG_MPSOC_PLATFORM)  +=3D xilinx-zynqmp.o
 obj-$(CONFIG_MPSOC_PLATFORM)  +=3D xilinx-zynqmp-eemi.o
diff --git a/xen/arch/arm/platforms/qcom.c b/xen/arch/arm/platforms/qcom.c
new file mode 100644
index 0000000000..77e9c58649
--- /dev/null
+++ b/xen/arch/arm/platforms/qcom.c
@@ -0,0 +1,77 @@
+/*
+ * xen/arch/arm/platforms/qcom.c
+ *
+ * Qualcomm SoCs specific code
+ *
+ * Volodymyr Babchuk 
+ *
+ * Copyright (c) 2024 EPAM Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+
+#define SCM_SMC_FNID(s, c)	((((s) & 0xFF) << 8) | ((c) & 0xFF))
+#define QCOM_SCM_SVC_INFO		0x06
+#define QCOM_SCM_INFO_IS_CALL_AVAIL	0x01
+
+#define ARM_SMCCC_SIP_QCOM_SCM_IS_CALL_AVAIL                            \
+    ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL,                             \
+                       ARM_SMCCC_CONV_64,                               \
+                       ARM_SMCCC_OWNER_SIP,                             \
+                       SCM_SMC_FNID(QCOM_SCM_SVC_INFO,                  \
+                                    QCOM_SCM_INFO_IS_CALL_AVAIL))
+
+static const char * const sa8155p_dt_compat[] __initconst =3D
+{
+    "qcom,sa8155p",
+    NULL
+};
+
+static bool sa8155p_smc(struct cpu_user_regs *regs)
+{
+    uint32_t funcid =3D get_user_reg(regs, 0);
+
+    switch ( funcid ) {
+    case ARM_SMCCC_SIP_QCOM_SCM_IS_CALL_AVAIL:
+        /*
+         * We need to implement this specific call only to make Linux
+         * counterpart happy: QCOM SCM driver in Linux tries to
+         * determine calling convention by issuing this particular
+         * SMC. If it receives an error it assumes that platform uses
+         * legacy calling convention and tries to issue SMC with
+         * funcid =3D 1. Xen interprets this as PSCI_cpu_off and turns
+         * off Linux boot vCPU.
+         */
+        set_user_reg(regs, 0, ARM_SMCCC_SUCCESS);
+        set_user_reg(regs, 1, 1);
+        return true;
+    default:
+        return false;
+    }
+}
+
+PLATFORM_START(sa8155p, "Qualcomm SA8155P")
+    .compatible =3D sa8155p_dt_compat,
+    .smc =3D sa8155p_smc
+PLATFORM_END
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
--=20
2.43.0


From xen-devel-bounces@lists.xenproject.org Fri Mar 29 01:26:17 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Mar 2024 01:26:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699223.1091930 (Exim 4.92)
	(envelope-from )
	id 1rq10N-00054V-2F; Fri, 29 Mar 2024 01:26:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699223.1091930; Fri, 29 Mar 2024 01:26:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rq10M-00054O-Vt; Fri, 29 Mar 2024 01:26:02 +0000
Received: by outflank-mailman (input) for mailman id 699223;
 Fri, 29 Mar 2024 01:26:01 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rq10L-00054I-81
 for xen-devel@lists.xenproject.org; Fri, 29 Mar 2024 01:26:01 +0000
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com
 [2a00:1450:4864:20::535])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4c1a93b3-ed6b-11ee-a1ef-f123f15fe8a2;
 Fri, 29 Mar 2024 02:25:59 +0100 (CET)
Received: by mail-ed1-x535.google.com with SMTP id
 4fb4d7f45d1cf-56829f41f81so2212908a12.2
 for ; Thu, 28 Mar 2024 18:25:59 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4c1a93b3-ed6b-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1711675558; x=1712280358; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=NbXeEGBrLDr/vK47Zm+PMLx78MZW3W2r+enlXWtyjMQ=;
        b=gHznhC0VncXZr7LNRjXyzMuVwCCa3FcElo1zLdnBLS02o58x29jmckf5PfwjIpevlH
         bXlXn5kFAxQFtbklObVvDFWZTfVfcOd9jSB4TeimsYNbFIBheQ0YMvDvCYtb6BMDPv69
         G4rOAHSLbRUPQQrk/ijV5WI0/QxsL3+SDfrJ2w/RjN2aLbbpX7H5+hecXrev6ROWv0kT
         30AmwJ7fMWC58lIr7i1q8Yrl+Kb++o1zQGu1gRhUe+RrI+Dk9pMcV6NJ4/c4fCzY6e+E
         jjOUTy65dcdVnXzqYOK35H5YVUqCVQ7YESmkyyE86IQ6TYlBQTAr2dLqoV9PUkLn1vST
         q0VQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711675558; x=1712280358;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=NbXeEGBrLDr/vK47Zm+PMLx78MZW3W2r+enlXWtyjMQ=;
        b=VaPIyIoiCvcCAlGKbP6GbEgJ9yZIMOgVolZSNSzjil1CADdY+gedz68ZNVkXqOUlVh
         ERlKmBns5M0drNrkQCP+f9IFGXfb+a/BE3DFIAYK6TnRFzHb1i45n5ITyIdLf1dwiARR
         VeXSAkxQa+nO0RC/aBXwnvFKXrFqc3Y+QjyVTs2vF/XiifDzBbcD2jst6zH83eU26Y7Q
         bRF+/dtjKAJNCuswPGgkJEOG3t8mgl33bB39q0RYm5q5s39uGmgmsXP3te9vL3kz/+eY
         E9sB00cWHEL+JCOQWVfCqiojfmud605JC7rbARBxAjxivtCLJaVjrpX4vpZxz9roQaZk
         5vMA==
X-Gm-Message-State: AOJu0Yxy7DFGZlGqCa4guaLRGah5NCh1/FDHAt8AbfDnq9bO/Se/qGLe
	fJGCiOK+dspeGFptzn1Xg9hpZIn1Udo1vOkaz9x0H6YmpVRNI0S2NvD0ra6/Mil3TUoRWWR8VBt
	h+YA8tecmbaVsvg8A2MguR7xXJFiND/6o
X-Google-Smtp-Source: AGHT+IH88YaL6t3Nj4JFKNn0/wwoBUA5UztW00BsTIgojkwj25BzqaCRyhbAk3hrZUhUkJffbgvn0jA+3TNJ6CQRiak=
X-Received: by 2002:a50:aad5:0:b0:568:260b:e502 with SMTP id
 r21-20020a50aad5000000b00568260be502mr436366edc.13.1711675558320; Thu, 28 Mar
 2024 18:25:58 -0700 (PDT)
MIME-Version: 1.0
References: <20240124165401.35784-1-jandryuk@gmail.com> 
  <9b5a105a-650c-4b33-9f4e-03612fb6701c@suse.com>
In-Reply-To: <9b5a105a-650c-4b33-9f4e-03612fb6701c@suse.com>
From: Jason Andryuk 
Date: Thu, 28 Mar 2024 21:25:46 -0400
Message-ID: 
Subject: Re: Linux Xen PV CPA W^X violation false-positives
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
Cc: xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Mar 28, 2024 at 9:00=E2=80=AFAM J=C3=BCrgen Gro=C3=9F  wrote:
>
> Hi Jason,
>
> On 28.03.24 02:24, Jason Andryuk wrote:
> > On Wed, Mar 27, 2024 at 7:46=E2=80=AFAM J=C3=BCrgen Gro=C3=9F  wrote:
> >>
> >> On 24.01.24 17:54, Jason Andryuk wrote:
> >>> +
> >>> +                     return new;
> >>> +             }
> >>> +     }
> >>> +
> >>>        end =3D start + npg * PAGE_SIZE - 1;
> >>>        WARN_ONCE(1, "CPA detected W^X violation: %016llx -> %016llx r=
ange: 0x%016lx - 0x%016lx PFN %lx\n",
> >>>                  (unsigned long long)pgprot_val(old),
> >>
> >> Jason, do you want to send a V2 with your Signed-off, or would you lik=
e me to
> >> try upstreaming the patch?
> >
> > Hi J=C3=BCrgen,
> >
> > Yes, please upstream your approach.  I wasn't sure how to deal with
> > it, so it was more of a bug report.
>
> The final solution was a bit more complicated, as there are some
> corner cases to be considered. OTOH it is now complete by looking
> at all used translation entries.
>
> Are you able to test the attached patch? I don't see the original
> issue and can only verify the patch doesn't cause any regression.

I'm no longer involved with OpenXT, but I reached out to some of the
developers.  Hopefully they try this out and respond here.

The backtrace in this thread is from BPF - I don't know how that was
triggered.  The other case I saw was in dom0.  That looked like it was
from freeing a module's (nouveau) .init section.  I don't seem to be
able to reproduce that on a non-OpenXT box.

Thanks,
Jason


From xen-devel-bounces@lists.xenproject.org Fri Mar 29 01:30:38 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Mar 2024 01:30:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699226.1091941 (Exim 4.92)
	(envelope-from )
	id 1rq14n-0006tA-Oe; Fri, 29 Mar 2024 01:30:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699226.1091941; Fri, 29 Mar 2024 01:30:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rq14n-0006t3-LE; Fri, 29 Mar 2024 01:30:37 +0000
Received: by outflank-mailman (input) for mailman id 699226;
 Fri, 29 Mar 2024 01:30:37 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rq14m-0006sx-Uv
 for xen-devel@lists.xenproject.org; Fri, 29 Mar 2024 01:30:36 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f0075ad8-ed6b-11ee-a1ef-f123f15fe8a2;
 Fri, 29 Mar 2024 02:30:34 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 39E23618AC;
 Fri, 29 Mar 2024 01:30:33 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPS id 9EEAFC43330;
 Fri, 29 Mar 2024 01:30:32 +0000 (UTC)
Received: from aws-us-west-2-korg-oddjob-1.ci.codeaurora.org
 (localhost.localdomain [127.0.0.1])
 by aws-us-west-2-korg-oddjob-1.ci.codeaurora.org (Postfix) with ESMTP id
 87AF1D2D0EB; Fri, 29 Mar 2024 01:30:32 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f0075ad8-ed6b-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1711675832;
	bh=KqG1/6CNOZ3/zscWyJ6iaAoQm4UN8htqnkzRjpthG2k=;
	h=Subject:From:Date:References:In-Reply-To:To:Cc:From;
	b=cv7GnLgIPd8XQzjdw0hg2IgzshjoaT92/3mhtn1tBGRYV4HMClp5wHj2px59ROo5q
	 qKLJnmu19Tv6MVT5h5nY2y0dYeWuwRFDXi+1HiAV9qqgVzpArG9oH7I3b5LUsNNozx
	 9mhrY/jEWY80k2Gz9CajET2StFxfVYgDX7rsqB3vbWjUVxqdKChgf85bjpMlE34x1J
	 vQGuRut5qzv7RCkEeeVT0pNajpeQZ9Pilnkk9NklqWdy2sHW740LV93Lrlwy1mFtQR
	 Fm3ZjbtXf+u/jPdTVjYnVq7rHO8gZPnfPJYjwWXKpLsbKojOGbqyxtCYSitoC6Fg8R
	 7e4puL/RmxAGQ==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Subject: Re: [PATCH net] xen-netfront: Add missing skb_mark_for_recycle
From: patchwork-bot+netdevbpf@kernel.org
Message-Id: 
 <171167583255.32458.14379553283592807838.git-patchwork-notify@kernel.org>
Date: Fri, 29 Mar 2024 01:30:32 +0000
References: <171154167446.2671062.9127105384591237363.stgit@firesoul>
In-Reply-To: <171154167446.2671062.9127105384591237363.stgit@firesoul>
To: Jesper Dangaard Brouer 
Cc: netdev@vger.kernel.org, arthurborsboom@gmail.com,
 ilias.apalodimas@linaro.org, wei.liu@kernel.org, paul@xen.org,
 kuba@kernel.org, kirjanov@gmail.com, dkirjanov@suse.de,
 kernel-team@cloudflare.com, security@xenproject.org,
 andrew.cooper3@citrix.com, xen-devel@lists.xenproject.org

Hello:

This patch was applied to netdev/net.git (main)
by Jakub Kicinski :

On Wed, 27 Mar 2024 13:14:56 +0100 you wrote:
> Notice that skb_mark_for_recycle() is introduced later than fixes tag in
> 6a5bcd84e886 ("page_pool: Allow drivers to hint on SKB recycling").
> 
> It is believed that fixes tag were missing a call to page_pool_release_page()
> between v5.9 to v5.14, after which is should have used skb_mark_for_recycle().
> Since v6.6 the call page_pool_release_page() were removed (in 535b9c61bdef
> ("net: page_pool: hide page_pool_release_page()") and remaining callers
> converted (in commit 6bfef2ec0172 ("Merge branch
> 'net-page_pool-remove-page_pool_release_page'")).
> 
> [...]

Here is the summary with links:
  - [net] xen-netfront: Add missing skb_mark_for_recycle
    https://git.kernel.org/netdev/net/c/037965402a01

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html




From xen-devel-bounces@lists.xenproject.org Fri Mar 29 03:30:31 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Mar 2024 03:30:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699236.1091951 (Exim 4.92)
	(envelope-from )
	id 1rq2wc-0005tV-Ol; Fri, 29 Mar 2024 03:30:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699236.1091951; Fri, 29 Mar 2024 03:30:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rq2wc-0005tO-M0; Fri, 29 Mar 2024 03:30:18 +0000
Received: by outflank-mailman (input) for mailman id 699236;
 Fri, 29 Mar 2024 03:30:18 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rq2wb-0005tI-Sl
 for xen-devel@lists.xenproject.org; Fri, 29 Mar 2024 03:30:17 +0000
Received: from NAM02-BN1-obe.outbound.protection.outlook.com
 (mail-bn1nam02on20701.outbound.protection.outlook.com
 [2a01:111:f403:2407::701])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a6d0a752-ed7c-11ee-a1ef-f123f15fe8a2;
 Fri, 29 Mar 2024 04:30:13 +0100 (CET)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by CY8PR12MB7241.namprd12.prod.outlook.com (2603:10b6:930:5a::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.39; Fri, 29 Mar
 2024 03:30:09 +0000
Received: from BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::debf:178c:f5df:5efa]) by BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::debf:178c:f5df:5efa%6]) with mapi id 15.20.7409.031; Fri, 29 Mar 2024
 03:30:09 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a6d0a752-ed7c-11ee-a1ef-f123f15fe8a2
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=nXTF5y9Ba1JUFutFTZI0UvG3o6TC91tZB63qeKhPjdPYF1I+L98H7SZ8y1UJTBbg6wssPPWPcuGjdYbwUfr4xVWsPx21N0uWj63p3UbsPJMlybFJtf4XIe/NIF9quonhL/l5QEG30FsvUOgJe2Tal4XCPu1YQVQhulB+oWTWQD6qXz602KxFDMDZvB0qvRHQqzHgxF6uUoGzqC6OSIa2RDTJYhRTjYEtDEK/EiuP1d3Qal6wMwyw+SqSsMMAMIXOxXQsixqvGgrupejiNz+p/9kTXKX5IquAAb2Gt0UHS2S+LDS1Yld7nwXw8P/alaVmdFGEOzr1ns5v9jd4FRA5og==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=nwiNTHxaHbwZ4OFEbcYYoIQWloqK5FOrBoK86xtQ8m4=;
 b=SRcUncrmJf5I16xgvb5dqP3HWWVwkRkMlRMrbmG6jjSUbWO2nI4bnM9LFl8qiLwBMVytgDGD+okWYCB+8LmTgMYR/+7jOSzysMM2gP4ZvSqTQtg7e3FxjTuwY95xqHyRRf0/FYEblgP540f9jPdN9Ct7LdVSJMJySLKiHqR5YH6kKxDUFUg6nkC3B6liMpL2VSt9JQbyIjnFf9oChpEN24O6AgmmF2/8zVlkk2rFF8ZvASubuG0M4BF7lFnubkiAl7rFQ6aYgSHUaI3pl732zMJ6ylqugQrnxR2faZ2KDQ6GyuxSafx/unrovY0zjouPxHqIRGTYsxgSHvyn2hH8Aw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass
 header.d=amd.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=nwiNTHxaHbwZ4OFEbcYYoIQWloqK5FOrBoK86xtQ8m4=;
 b=CFllYnUXoe74JyAqHHifBnxGVA5KM2hyixfSYPY67wvb1MwloL9f3Zr+j9anQSxj1osdlRzkB6AbTdbCEv00k15S7tv6Ekm/vIuB/VcBXpcvNGyJxe512qPP10oj2R9xZLi4QNsD3NLHgsVzqPPNDUFIf9/YAfnx667pt3VTRB0=
From: "Chen, Jiqian" 
To: Anthony PERARD 
CC: "xen-devel@lists.xenproject.org" , Jan
 Beulich , Andrew Cooper ,
	=?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Wei Liu
	, George Dunlap , Julien Grall
	, Stefano Stabellini , Juergen Gross
	, "Daniel P . Smith" ,
	"Hildebrand, Stewart" , "Huang, Ray"
	, "Chen, Jiqian" 
Subject: Re: [RFC XEN PATCH v6 4/5] libxl: Use gsi instead of irq for mapping
 pirq
Thread-Topic: [RFC XEN PATCH v6 4/5] libxl: Use gsi instead of irq for mapping
 pirq
Thread-Index: AQHagNoDtKajNm2Sn02wRhj0zSTb0rFNag6AgAEsdoA=
Date: Fri, 29 Mar 2024 03:30:09 +0000
Message-ID:
 
References: <20240328063402.354496-1-Jiqian.Chen@amd.com>
 <20240328063402.354496-5-Jiqian.Chen@amd.com>
 <81c6e63f-b493-4bbd-a91a-ec0e04cc69e2@perard>
In-Reply-To: <81c6e63f-b493-4bbd-a91a-ec0e04cc69e2@perard>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-imapappendstamp: IA0PR12MB7674.namprd12.prod.outlook.com
 (15.20.7292.000)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BL1PR12MB5849:EE_|CY8PR12MB7241:EE_
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 ussHcZexw+0eqdKh/S4h/QOiwPJlrP+cffVtaYOFETHgNz1TFJmEmt4gLy9eyljg9XIaPt3jwMoHkYcfPFFHizHngwAzocRxenbH1K2mRHX8/7UGwM9YNiXe2ZDD0Odf2lfZ/v8Dt5V5wBdjXNbB6DLQsKb0HGWtrzsel5yI2L9cx0Lb/gogfq/zKOQ9SB7jdpNmdj6djePyC+dLcOLC6UxDnTBHNQ8ehnHNx1/CjCmO3ZiVQRue2YDWOXNHu/BQQ9ktjQ16XoeOCoQakEVxDMnA4hYTAxl7kdnhH3+v5+1EG8h2wzNC99+g9rh+lto8Hc7aqFjyYVgSJQIDgik/cnjpC1w294FIWfMNSzty0A7uhxx1k6LrO32Mz3DaTcWvyP0o5Evmc+bu9XylWPxtyJfGPhUJZmP8a05b7AQgextl5lvEqaQG1/PufnffCL7rP7BdZKp1/vJd5FHeZ8M4dAYFHXTNy/4YID5TZ5+HXi8JUC+anxbwidRmOz9Lb+MON+lnrpSaVX8gqO31iQ7nzxBlFfGMSdfWuuso1n8iPSfG7Zoax8LUOwffizCHUJKTmud7SWEjDXoMzrc/pwN9J907QdfiqMFUSpoIr2+LTRnMECikogZ52ZbFqmE5dAOS+FSgG0CvvmlEwZQWc4oIHL60xEKrpEuWfZZP0GFgDd4=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BL1PR12MB5849.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(366007)(376005)(7416005)(1800799015);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?VW44MU5ZTWREdnNnZk9EZStRQVErUStsS1ozZGhFdXI2Mys4RmhiR29VS3JY?=
 =?utf-8?B?clNPM3NmVXAwNDVMN0VjZlllNlJ2UXRlditqYnZqNktSaVNsdlNkMXBPUjRw?=
 =?utf-8?B?bDM3UzJhN0VHNWtGWGNCSVVlR213MFJpYno5OUFTdCtVd1BTa1RLRnlJRnUz?=
 =?utf-8?B?MnNlcXJTVXVlMWVyRFVYMFhCY1lvQTNzM2dUTFV0a3hncTRyZ0NzcldZS3dm?=
 =?utf-8?B?V0YzZVEyM1lUdDFFa2FKOG1JV3BpaW1jUXpzcmhoSkdCclNXRllxUlFFYzdW?=
 =?utf-8?B?SEJxL2ZjaVF0dC9zRFhDL3FoWi92dDcxNjBZVWtVRURBTGppL3RCaC9kbkE5?=
 =?utf-8?B?KysxRUxpd2JOLzlpdytuR0M0bVBwV0EvZnVUbGQ0VmttbzJpRGVkNngyNmlJ?=
 =?utf-8?B?dkV3cXFEbzlxc3AzSTJGT0NTZEU2N2c0VE1XY29BallhVjdjSEJIMFQ3MlVv?=
 =?utf-8?B?dGZ3UjUzdGo3QjB0aVRZdE5DY1EvTlNQbElRUm1DQkVBS3A4UWIrREV4NFo4?=
 =?utf-8?B?TmtJZHRvM0NIblNxZHE5MUE0WEZOa0VSTEUzWVg2bU5kTkhyMmNNenhIU25C?=
 =?utf-8?B?c3BuNElUU3dleFlrNXJQNkMzR2NNUkd6STlqZUUwemJ1aVgvUFpmZjNLREFQ?=
 =?utf-8?B?Q0lnYTlZVDg5ay9yR1hvZWFTNnc2SEIzeGI0YmxkdXNvUWU5VlBPTDY1THp1?=
 =?utf-8?B?ZzJ0QTdCcjBkRlk1MjVTRldBTEpiRDFBQzJDM3lFZE4wL0gzbUZBMWt5NE9V?=
 =?utf-8?B?K1VvVkZpOENWeUNqYjgrOXo2QkZoL3Z0YnU0OXZGWk45VlVpRjZ0amNVajBG?=
 =?utf-8?B?c3JyTWZkYWVTM2ZwUldqeERDcjJib0o2ckJqK0kwYi9yY1ZXYUZJYVdqb0RM?=
 =?utf-8?B?ZnRUSndTK2Qxc3YyWTBrVk05M25kYktOUFVEZ0FNaEtYQnA4Uk9GNHN0Rm9v?=
 =?utf-8?B?WUtiUUVCYXpkdkthZ25GRFFDaGVDVjhndllhR25hWGg4NTQ0YXUxanE1U1lW?=
 =?utf-8?B?bW9zWm5KaHdkcVJmK3cwZk91aVVOYzk0ek05ZDAxZndhNk53blY2ZnZqbVNT?=
 =?utf-8?B?N2FraFV5N094WEoyb0VkNGtnbUFRMUZFT0JmQlBZZHlYdCt2ZVRYeGpLK3Z0?=
 =?utf-8?B?bThJZ3F3U2ErRlI5RnVqcEs5R2VGR1FoYUR6Z1dEaFRaWTRiellYMGtMWjZK?=
 =?utf-8?B?R2ZQbDBrVVRQbXRYNGxLeklTKzdtdUVHUkExaDIyZkNzNC9ZVHE4ME9UZVlj?=
 =?utf-8?B?QXJPMjdhMG9nYTBQOUhvS3h3TlpUTmlHb2UyZGUvMjZtcXFUeFFaNWhPUUpt?=
 =?utf-8?B?Y0VBOElsUjVuQmdSNnRMbm90dFZIaUF4VFhwbFJkZmJ4aERXWFprRTROTlZK?=
 =?utf-8?B?a2hsekptNkV6dWtWbGNyWmJiT1RRQnJYdFk3VVhzWVAzVHhyUHB1Zk9EWVNo?=
 =?utf-8?B?VHJUcXVHRmxyQ1ozVUlmOEZKcDgxUFFidkoxS2hzcHhaenJqclo4cHlqWDI0?=
 =?utf-8?B?R3RHbWdLd2hKNFMvV1FFREFFN1B2eE5kSHZhVHBkSmlZcVQ5WW1Odm14c1lF?=
 =?utf-8?B?NldMWWhuTHNCVDUzdFVvMCtOa2lUM0phK0dDNVd4bUp5TnNFeU9EbFpta0Fa?=
 =?utf-8?B?N29VRnB1ZWpVOFZvZEllT0I5RFVrWFR3MnVkaUJkVS9RNnQrU1cyWCtCOUxN?=
 =?utf-8?B?RjBTbmd6cEtiVWVQMzRFZmp2Wk1uYWlnZ3RqTDRQZDdQQUpYOXg4QVlzREx1?=
 =?utf-8?B?OElsdVNpZ2orYWR2UU1kajlQVGNZZVU5M3N3Z21PRThJempacVlYd3dOR3N3?=
 =?utf-8?B?enFjWXdmcUpqZ0xoQkRPRzBDMGVRYmZSajFXRHJkSGpMdzJZMitweENsa1I4?=
 =?utf-8?B?NDJ6b2ZvU1pxd04xWExUZW5uaFBMcjgxOFRxV0dycDB0L05hZDcrU1lQMXlh?=
 =?utf-8?B?Qk5TZ0x3RnNFazM2L0F2T1NFQ2hYeFF6M0xCWDExdllHNXBIQUp5Lzhtc2kz?=
 =?utf-8?B?Z0NiNnROZWdDU3kvaGR0V0V5L1JNV3FMYUoyWHBhNEtETFdneE1icmdoVHBN?=
 =?utf-8?B?cWxabE1LR2oyTTBKY1BSRjE0L1lRZFU2ek5rMk1MdUVNbXpWNDBQSG4ra2o4?=
 =?utf-8?Q?+mvs=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <283BAC2A656A024B9BFB4E1A6DD37AC0@amdcloud.onmicrosoft.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL1PR12MB5849.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 47017b84-d131-42c3-202a-08dc4fa08926
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2024 03:30:09.3543
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: SWuO5Tq0hYwuYijYSG2fEWEKrbFu+vI49C1+mD0O8B9rT09Ipi0NkVB4DgY7ml1QdDyga66TcGd8j/HakVdpnA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB7241

DQpPbiAyMDI0LzMvMjkgMDE6MzIsIEFudGhvbnkgUEVSQVJEIHdyb3RlOg0KPiBPbiBUaHUsIE1h
ciAyOCwgMjAyNCBhdCAwMjozNDowMVBNICswODAwLCBKaXFpYW4gQ2hlbiB3cm90ZToNCj4+IGRp
ZmYgLS1naXQgYS90b29scy9saWJzL2xpZ2h0L2xpYnhsX3BjaS5jIGIvdG9vbHMvbGlicy9saWdo
dC9saWJ4bF9wY2kuYw0KPj4gaW5kZXggOTZjYjRkYTA3OTRlLi4yY2VjODNlMGI3MzQgMTAwNjQ0
DQo+PiAtLS0gYS90b29scy9saWJzL2xpZ2h0L2xpYnhsX3BjaS5jDQo+PiArKysgYi90b29scy9s
aWJzL2xpZ2h0L2xpYnhsX3BjaS5jDQo+PiBAQCAtMTQ3OCw4ICsxNDc4LDE0IEBAIHN0YXRpYyB2
b2lkIHBjaV9hZGRfZG1fZG9uZShsaWJ4bF9fZWdjICplZ2MsDQo+PiAgICAgIGZjbG9zZShmKTsN
Cj4+ICAgICAgaWYgKCFwY2lfc3VwcF9sZWdhY3lfaXJxKCkpDQo+PiAgICAgICAgICBnb3RvIG91
dF9ub19pcnE7DQo+PiAtICAgIHN5c2ZzX3BhdGggPSBHQ1NQUklOVEYoU1lTRlNfUENJX0RFViIv
IlBDSV9CREYiL2lycSIsIHBjaS0+ZG9tYWluLA0KPj4gKyAgICBzeXNmc19wYXRoID0gR0NTUFJJ
TlRGKFNZU0ZTX1BDSV9ERVYiLyJQQ0lfQkRGIi9nc2kiLCBwY2ktPmRvbWFpbiwNCj4+ICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHBjaS0+YnVzLCBwY2ktPmRldiwgcGNpLT5mdW5j
KTsNCj4+ICsgICAgciA9IGFjY2VzcyhzeXNmc19wYXRoLCBGX09LKTsNCj4+ICsgICAgaWYgKHIg
JiYgZXJybm8gPT0gRU5PRU5UKSB7DQo+PiArICAgICAgICAvKiBUbyBjb21waXRhYmxlIHdpdGgg
b2xkIHZlcnNpb24gb2Yga2VybmVsLCBzdGlsbCBuZWVkIHRvIHVzZSBpcnEgKi8NCj4gDQo+IFRo
ZXJlJ3MgYSB0eXBvLCB0aGlzIHdvdWxkIGJlICJUbyBiZSBjb21wYXRpYmxlIC4uLiIuIEFsc28g
bWF5YmUNCj4gc29tZXRoaW5nIGxpa2UgIkZhbGxiYWNrIHRvICIvaXJxIiBmb3IgY29tcGF0aWJp
bGl0eSB3aXRoIG9sZCB2ZXJzaW9uIG9mDQo+IHRoZSBrZXJuZWwuIiBtaWdodCBzb3VuZCBiZXR0
ZXIuDQo+IA0KPj4gKyAgICAgICAgc3lzZnNfcGF0aCA9IEdDU1BSSU5URihTWVNGU19QQ0lfREVW
Ii8iUENJX0JERiIvaXJxIiwgcGNpLT5kb21haW4sDQo+PiArICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIHBjaS0+YnVzLCBwY2ktPmRldiwgcGNpLT5mdW5jKTsNCj4+ICsgICAgfQ0KPj4g
ICAgICBmID0gZm9wZW4oc3lzZnNfcGF0aCwgInIiKTsNCj4+ICAgICAgaWYgKGYgPT0gTlVMTCkg
ew0KPj4gICAgICAgICAgTE9HRUQoRVJST1IsIGRvbWFpbmlkLCAiQ291bGRuJ3Qgb3BlbiAlcyIs
IHN5c2ZzX3BhdGgpOw0KPj4gQEAgLTIyMjksOSArMjIzNSwxNSBAQCBza2lwX2JhcjoNCj4+ICAg
ICAgaWYgKCFwY2lfc3VwcF9sZWdhY3lfaXJxKCkpDQo+PiAgICAgICAgICBnb3RvIHNraXBfbGVn
YWN5X2lycTsNCj4+ICANCj4+IC0gICAgc3lzZnNfcGF0aCA9IEdDU1BSSU5URihTWVNGU19QQ0lf
REVWIi8iUENJX0JERiIvaXJxIiwgcGNpLT5kb21haW4sDQo+PiArICAgIHN5c2ZzX3BhdGggPSBH
Q1NQUklOVEYoU1lTRlNfUENJX0RFViIvIlBDSV9CREYiL2dzaSIsIHBjaS0+ZG9tYWluLA0KPj4g
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHBjaS0+YnVzLCBwY2ktPmRldiwgcGNpLT5mdW5j
KTsNCj4+ICANCj4+ICsgICAgcmMgPSBhY2Nlc3Moc3lzZnNfcGF0aCwgRl9PSyk7DQo+IA0KPiBQ
bGVhc2UsIGRvbid0IHVzZSB0aGUgdmFyaWFibGUgYHJjYCBoZXJlLCB0aGlzIG9uZSBpcyByZXNl
cnZlZCBmb3IgbGlieGwNCj4gZXJyb3IvcmV0dXJuIGNvZGUgaW4gbGlieGwuIEludHJvZHVjZSBg
aW50IHJgIGluc3RlYWQuDQo+IA0KPj4gKyAgICBpZiAocmMgJiYgZXJybm8gPT0gRU5PRU5UKSB7
DQo+PiArICAgICAgICAvKiBUbyBjb21waXRhYmxlIHdpdGggb2xkIHZlcnNpb24gb2Yga2VybmVs
LCBzdGlsbCBuZWVkIHRvIHVzZSBpcnEgKi8NCj4+ICsgICAgICAgIHN5c2ZzX3BhdGggPSBHQ1NQ
UklOVEYoU1lTRlNfUENJX0RFViIvIlBDSV9CREYiL2lycSIsIHBjaS0+ZG9tYWluLA0KPj4gKyAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwY2ktPmJ1cywgcGNpLT5kZXYsIHBjaS0+ZnVu
Yyk7DQo+PiArICAgIH0NCj4+ICAgICAgZiA9IGZvcGVuKHN5c2ZzX3BhdGgsICJyIik7DQo+PiAg
ICAgIGlmIChmID09IE5VTEwpIHsNCj4+ICAgICAgICAgIExPR0VEKEVSUk9SLCBkb21pZCwgIkNv
dWxkbid0IG9wZW4gJXMiLCBzeXNmc19wYXRoKTsNCj4gDQo+IFdpdGggdGhvc2UgdHdvIHRoaW5n
cyBmaXhlZDogUmV2aWV3ZWQtYnk6IEFudGhvbnkgUEVSQVJEIDxhbnRob255LnBlcmFyZEBjaXRy
aXguY29tPg0KVGhhbmsgeW91IHZlcnkgbXVjaCENCkkgd2lsbCBmaXggdGhvc2UgdHdvIGluIG5l
eHQgdmVyc2lvbi4NCg0KPiANCj4gVGhhbmtzLA0KPiANCg0KLS0gDQpCZXN0IHJlZ2FyZHMsDQpK
aXFpYW4gQ2hlbi4NCg==


From xen-devel-bounces@lists.xenproject.org Fri Mar 29 05:12:01 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Mar 2024 05:12:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699239.1091960 (Exim 4.92)
	(envelope-from )
	id 1rq4Wp-0002h5-Hs; Fri, 29 Mar 2024 05:11:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699239.1091960; Fri, 29 Mar 2024 05:11:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rq4Wp-0002gy-FJ; Fri, 29 Mar 2024 05:11:47 +0000
Received: by outflank-mailman (input) for mailman id 699239;
 Fri, 29 Mar 2024 05:11:46 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rq4Wo-0002gs-09
 for xen-devel@lists.xenproject.org; Fri, 29 Mar 2024 05:11:46 +0000
Received: from NAM04-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam04on20601.outbound.protection.outlook.com
 [2a01:111:f403:2408::601])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d4904925-ed8a-11ee-afe3-a90da7624cb6;
 Fri, 29 Mar 2024 06:11:43 +0100 (CET)
Received: from DS7PR06CA0007.namprd06.prod.outlook.com (2603:10b6:8:2a::25) by
 SJ1PR12MB6026.namprd12.prod.outlook.com (2603:10b6:a03:48b::21) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.33; Fri, 29 Mar
 2024 05:11:39 +0000
Received: from CH1PEPF0000AD7C.namprd04.prod.outlook.com
 (2603:10b6:8:2a:cafe::5f) by DS7PR06CA0007.outlook.office365.com
 (2603:10b6:8:2a::25) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.40 via Frontend
 Transport; Fri, 29 Mar 2024 05:11:39 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 CH1PEPF0000AD7C.mail.protection.outlook.com (10.167.244.84) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Fri, 29 Mar 2024 05:11:39 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Fri, 29 Mar
 2024 00:11:38 -0500
Received: from [10.69.48.49] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Fri, 29 Mar 2024 00:11:36 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d4904925-ed8a-11ee-afe3-a90da7624cb6
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=BYOJoTKfmJEVvdXpIzRlr8oS675lSe6INAgk5mM4X54ltLXpA122OQ0/3m/uOtVjM7aczJsir9kYYWGqlDi0kpOAf3M+GH06lL9XiJsMgJGnykuGC7KzGvrADIsd+gUtql42gvHW0bweqrPablzwy2mQxBX2nWnFJrc7Kt1ezNYVZYC7tMU4XbUJQTguxn3kBnC0UmP+dfVSOZ1nM+KPrgjlSYPD8MOoNPrILUQQgLkE5nP06IJGuPmvxYg7ktWjEmpIbp+2A4jpG8W8cfhD9i3mLGN3CgakO/j7/P7sdZ7H8kD0kD9b7xv7A4lfIVMibp2Ks407urN31c8cHIM+ow==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=G7+PLlvFg7Nofnqolse5PAMGywO21EmhjtEznZSwR/k=;
 b=LdoBlqHx0v06WsDYLg9UIaHYXxQA0+Gx1xRTfmoYNTKRW4gxAwlTp/d7SSE2BOkbi0DRPp8O7jh1FvsDRicMII8FbpJnx499+GxBJhdWYm1xoDoNVuc+juN8mbKYlhkDzuLSnG1UHNyrdncBoq2qVYN6qQrStyHgKkYFD5trCekncPdhN+YdPKYmZE0NzegFmtI3I2cPaqTy4bb5V23/ho92jqm4SpMetfA1qYYdc1LhhWK6suksUdKLYj9RqTsf1Mezcd2QFH7YsJhJhG2ie2fIhfbT8FxtwoYlY1dQRSbrVo/86TJwV1tjyzcsTRtLoEqXWMnJhC3xGIerW4MsLA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=G7+PLlvFg7Nofnqolse5PAMGywO21EmhjtEznZSwR/k=;
 b=akWXY2t/xV//zjmHHuguKcDQ5kDNdg7N+lEiAeSyp8jkhcMky/4cV36oQOgogHM6p91+UfyMK8lyKruTv7nOQpB75OtZfPq1oA4I6WW2cbgLhM4+KhM6xHs1kGgli2tZp751DuReQa8nTl2jQnRSQfiN/GyI83qQrrUI8QLs648=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
Message-ID: 
Date: Fri, 29 Mar 2024 13:11:35 +0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 5/5] xen/memory, tools: Make init-dom0less consume
 XEN_DOMCTL_get_mem_map
To: Jan Beulich 
CC: Wei Liu , Anthony PERARD , Andrew
 Cooper , George Dunlap ,
	Julien Grall , Stefano Stabellini ,
	Alec Kwapis , 
References: <20240308015435.4044339-1-xin.wang2@amd.com>
 <20240308015435.4044339-6-xin.wang2@amd.com>
 <1cb8bca3-58b6-4a8d-ac46-8338ea5807e7@suse.com>
Content-Language: en-US
From: Henry Wang 
In-Reply-To: <1cb8bca3-58b6-4a8d-ac46-8338ea5807e7@suse.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB03.amd.com: xin.wang2@amd.com does not designate
 permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH1PEPF0000AD7C:EE_|SJ1PR12MB6026:EE_
X-MS-Office365-Filtering-Correlation-Id: f3896863-f3fa-4785-74aa-08dc4faeb744
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	9Nh55+o7ZpOuk+htNxWGX5YpEloMrP03KT2ig2dlDsdsUPWi37T2LO7bIoqqudPVvyhEDU5HNglJwdUznxNeGBpan9PY7GnXIbeScILXfJXEMhtcH1FChlTYjnlhZOwqFSKIDRCaEJv9CiNXUsYnJACZwi7YcjrpZywPGs5+IJbwTxzs4s919+64kEdiYSw8MQUTFl6YMq08js+tZUPZ0SWm8kFuIxeqk3vmXpqTjR4t/rcpHOSeHm7KSjOtL8cAbJouD4sfFRyMlqjKVhUyH4QCnK4TdQ4zNTvVgmlp+aPaFG2HJ5E9VXZuqhDsplMf2vf48QXj4iU0MhvKLz9XzegxIhv52Wsn62L9i/HYoIgPyx24gFvlbq5gGYAYEDWrh8d+rxMDCxhfofrrVxkXSB6RtPPDGc6ldJaEZ8IilHMbKbo0lb5gla/plh3P4Elzs91N9T/cQ8k5zgNlaaPRAkmLuGFJXsFgtwzvlPqdSTHMVfKv70bdoRTmTEPZZ/F+HlsxG045YgYyuhY38lXO3dXybf1hcrb7v5VjSAPMsElcsxQsgSyRd+RKOeXHZnsWbwcqgCrndKiM6NsNZF8OS7Ji4dtO9FdoV6e7JpAo0+AFO2iud8CUq5VVv32+Og68dQ9eM7GgFOlpt+UvIK8qS1OuM7sFOutPXZgLmp2DZA42oB5Lk/9yp9HVy6MVJo8D/jfbZCaNewm0pR6CTbwA/LS3em4YEsyELFu17gU1uwrpm5X85vpP1cgfE9yEOxuf
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(1800799015)(82310400014)(376005)(36860700004);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Mar 2024 05:11:39.6763
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: f3896863-f3fa-4785-74aa-08dc4faeb744
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH1PEPF0000AD7C.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ1PR12MB6026

Hi Jan,

On 3/12/2024 1:07 AM, Jan Beulich wrote:
>> +/*
>> + * Flag to force populate physmap to use pages from domheap instead of 1:1
>> + * or static allocation.
>> + */
>> +#define XENMEMF_force_heap_alloc  (1<<19)
>>   #endif
> If this is for populate_physmap only, then other sub-ops need to reject
> its use.
>
> I have to admit I'm a little wary of allocating another flag here and ...
>
>> --- a/xen/include/xen/mm.h
>> +++ b/xen/include/xen/mm.h
>> @@ -205,6 +205,8 @@ struct npfec {
>>   #define  MEMF_no_icache_flush (1U<<_MEMF_no_icache_flush)
>>   #define _MEMF_no_scrub    8
>>   #define  MEMF_no_scrub    (1U<<_MEMF_no_scrub)
>> +#define _MEMF_force_heap_alloc 9
>> +#define  MEMF_force_heap_alloc (1U<<_MEMF_force_heap_alloc)
>>   #define _MEMF_node        16
>>   #define  MEMF_node_mask   ((1U << (8 * sizeof(nodeid_t))) - 1)
>>   #define  MEMF_node(n)     ((((n) + 1) & MEMF_node_mask) << _MEMF_node)
> ... here - we don't have that many left. Since other sub-ops aren't
> intended to support this flag, did you consider adding another (perhaps
> even arch-specific) sub-op instead?

While revisiting this comment when trying to come up with a V3, I 
realized adding a sub-op here in the same level as 
XENMEM_populate_physmap will basically duplicate the function 
populate_physmap() with just the "else" (the non-1:1 allocation) part, 
also a similar xc_domain_populate_physmap_exact() & co will be needed 
from the toolstack side to call the new sub-op. So I am having the 
concern of the duplication of code and not sure if I understand you 
correctly. Would you please elaborate a bit more or clarify if I 
understand you correctly? Thanks!

Kind regards,
Henry

> Jan



From xen-devel-bounces@lists.xenproject.org Fri Mar 29 05:15:46 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Mar 2024 05:15:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699241.1091971 (Exim 4.92)
	(envelope-from )
	id 1rq4af-0003Fx-1y; Fri, 29 Mar 2024 05:15:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699241.1091971; Fri, 29 Mar 2024 05:15:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rq4ae-0003Fq-V8; Fri, 29 Mar 2024 05:15:44 +0000
Received: by outflank-mailman (input) for mailman id 699241;
 Fri, 29 Mar 2024 05:15:44 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rq4ae-0003Fe-Fn; Fri, 29 Mar 2024 05:15:44 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rq4ae-0004Jb-1P; Fri, 29 Mar 2024 05:15:44 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rq4ad-0005E5-NL; Fri, 29 Mar 2024 05:15:43 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rq4ad-00066g-Mt; Fri, 29 Mar 2024 05:15:43 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=f8l3hhpc3xRb/Pcj9+1/azqhdMWUgwd3cNqfpCXlNjI=; b=CT7/rarw9QowydEIp4fPt5Sm+o
	ohcwZOuqNxxdgG1xl5kFfUz97W7JAP3vNs0cKqshb5FypaYuQoVYzzUXCVaZeUeQFDEA24z/ozJL3
	lEfuFaLdHMTY2MI+8H4s2vEn4/mq2RqCQWmv9iXCv6lO1hCFTvpdWm6MnTjK4MefIVmo=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [ovmf test] 185198: all pass - PUSHED
X-Osstest-Versions-This:
    ovmf=7fde22823d64cb7b9f2a65bb87ffb7581f5ff84e
X-Osstest-Versions-That:
    ovmf=cf58f47623c40a66b160face4f04e08efb4c7f5b
From: osstest service owner 
Date: Fri, 29 Mar 2024 05:15:43 +0000

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf                 7fde22823d64cb7b9f2a65bb87ffb7581f5ff84e
baseline version:
 ovmf                 cf58f47623c40a66b160face4f04e08efb4c7f5b

Last test of basis   185156  2024-03-25 08:12:54 Z    3 days
Testing same since   185198  2024-03-29 03:14:32 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Wenxing Hou 

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-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   cf58f47623..7fde22823d  7fde22823d64cb7b9f2a65bb87ffb7581f5ff84e -> xen-tested-master


From xen-devel-bounces@lists.xenproject.org Fri Mar 29 09:11:53 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Mar 2024 09:11:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699281.1092016 (Exim 4.92)
	(envelope-from )
	id 1rq8H5-0001hj-Lj; Fri, 29 Mar 2024 09:11:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699281.1092016; Fri, 29 Mar 2024 09:11:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rq8H5-0001gK-Er; Fri, 29 Mar 2024 09:11:47 +0000
Received: by outflank-mailman (input) for mailman id 699281;
 Fri, 29 Mar 2024 09:11:46 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rq8H4-0000ww-5C
 for xen-devel@lists.xenproject.org; Fri, 29 Mar 2024 09:11:46 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5cfe1f74-edac-11ee-a1ef-f123f15fe8a2;
 Fri, 29 Mar 2024 10:11:44 +0100 (CET)
Received: from nico.bugseng.com (unknown [176.206.12.122])
 by support.bugseng.com (Postfix) with ESMTPSA id 0A5614EE0748;
 Fri, 29 Mar 2024 10:11:44 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5cfe1f74-edac-11ee-a1ef-f123f15fe8a2
From: Nicola Vetrini 
To: nicola.vetrini@bugseng.com,
	xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org,
	michal.orzel@amd.com,
	xenia.ragiadakou@amd.com,
	ayan.kumar.halder@amd.com,
	consulting@bugseng.com,
	bertrand.marquis@arm.com,
	julien@xen.org,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [XEN PATCH v3 4/7] x86/hvm: address violations of MISRA C Rule 20.7
Date: Fri, 29 Mar 2024 10:11:32 +0100
Message-Id: 
X-Mailer: git-send-email 2.34.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter the semantics of the passed-in macro parameter.

No functional change.

Signed-off-by: Nicola Vetrini 
---
 xen/arch/x86/hvm/domain.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/hvm/domain.c b/xen/arch/x86/hvm/domain.c
index 7f6e362a702e..b96cf93dd0ef 100644
--- a/xen/arch/x86/hvm/domain.c
+++ b/xen/arch/x86/hvm/domain.c
@@ -132,9 +132,9 @@ int arch_set_info_hvm_guest(struct vcpu *v, const struct vcpu_hvm_context *ctx)
     s = (struct segment_register)                                           \
         { 0, { (r)->s ## _ar }, (r)->s ## _limit, (r)->s ## _base };        \
     /* Set accessed / busy bit for present segments. */                     \
-    if ( s.p )                                                              \
-        s.type |= (x86_seg_##s != x86_seg_tr ? 1 : 2);                      \
-    check_segment(&s, x86_seg_ ## s); })
+    if ( (s).p )                                                            \
+        (s).type |= (x86_seg_##s != x86_seg_tr ? 1 : 2);                    \
+    check_segment(&(s), x86_seg_ ## s); })
 
         rc = SEG(cs, regs);
         rc |= SEG(ds, regs);
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Mar 29 09:11:53 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Mar 2024 09:11:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699283.1092028 (Exim 4.92)
	(envelope-from )
	id 1rq8H6-0001vf-Bk; Fri, 29 Mar 2024 09:11:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699283.1092028; Fri, 29 Mar 2024 09:11:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rq8H6-0001so-2z; Fri, 29 Mar 2024 09:11:48 +0000
Received: by outflank-mailman (input) for mailman id 699283;
 Fri, 29 Mar 2024 09:11:47 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rq8H5-0000ww-5Q
 for xen-devel@lists.xenproject.org; Fri, 29 Mar 2024 09:11:47 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5d5014f1-edac-11ee-a1ef-f123f15fe8a2;
 Fri, 29 Mar 2024 10:11:45 +0100 (CET)
Received: from nico.bugseng.com (unknown [176.206.12.122])
 by support.bugseng.com (Postfix) with ESMTPSA id 80D7F4EE0742;
 Fri, 29 Mar 2024 10:11:44 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5d5014f1-edac-11ee-a1ef-f123f15fe8a2
From: Nicola Vetrini 
To: nicola.vetrini@bugseng.com,
	xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org,
	michal.orzel@amd.com,
	xenia.ragiadakou@amd.com,
	ayan.kumar.halder@amd.com,
	consulting@bugseng.com,
	bertrand.marquis@arm.com,
	julien@xen.org,
	Simone Ballarin ,
	Doug Goldstein ,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich 
Subject: [XEN PATCH v3 5/7] automation/eclair: add deviations for Rule 20.7
Date: Fri, 29 Mar 2024 10:11:33 +0100
Message-Id: 
X-Mailer: git-send-email 2.34.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

These deviations deal with the following cases:
- macro arguments used directly as initializer list arguments;
- uses of the __config_enabled macro, that can't be brought
  into compliance without breaking its functionality;
- exclude files that are out of scope (efi headers and cpu_idle);
- uses of alternative_{call,vcall}[0-9] macros.

The existing configuration for R20.7 is reordered so that it matches the
cases listed in its documentation comment.

Signed-off-by: Nicola Vetrini 
---
 .../eclair_analysis/ECLAIR/deviations.ecl     | 25 +++++++++++++++++--
 docs/misra/deviations.rst                     | 14 ++++++++++-
 docs/misra/rules.rst                          |  2 +-
 3 files changed, 37 insertions(+), 4 deletions(-)

diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
index de9ba723fbc7..70756503f594 100644
--- a/automation/eclair_analysis/ECLAIR/deviations.ecl
+++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
@@ -401,12 +401,33 @@ unexpected result when the structure is given as argument to a sizeof() operator
 
 -doc_begin="Code violating Rule 20.7 is safe when macro parameters are used: (1)
 as function arguments; (2) as macro arguments; (3) as array indices; (4) as lhs
-in assignments."
+in assignments; (5) as initializers, possibly designated, in initalizer lists."
 -config=MC3R1.R20.7,expansion_context=
 {safe, "context(__call_expr_arg_contexts)"},
+{safe, "left_right(^[(,\\[]$,^[),\\]]$)"},
 {safe, "context(skip_to(__expr_non_syntactic_contexts, stmt_child(node(array_subscript_expr), subscript)))"},
 {safe, "context(skip_to(__expr_non_syntactic_contexts, stmt_child(operator(assign), lhs)))"},
-{safe, "left_right(^[(,\\[]$,^[),\\]]$)"}
+{safe, "context(skip_to(__expr_non_syntactic_contexts, stmt_child(node(init_list_expr||designated_init_expr), init)))"}
+-doc_end
+
+-doc_begin="Violations involving the __config_enabled macros cannot be fixed without
+breaking the macro's logic; futhermore, the macro is only ever used in the context
+of the IS_ENABLED or STATIC_IF/STATIC_IF_NOT macros, so it always receives a literal
+0 or 1 as input, posing no risk to safety."
+-config=MC3R1.R20.7,reports+={safe, "any_area(any_loc(any_exp(macro(^___config_enabled$))))"}
+-doc_end
+
+-doc_begin="Violations due to the use of macros defined in files that are
+not in scope for compliance are allowed, as that is imported code."
+-file_tag+={gnu_efi_include, "^xen/include/efi/.*$"}
+-file_tag+={acpi_cpu_idle, "^xen/arch/x86/acpi/cpu_idle\\.c$"}
+-config=MC3R1.R20.7,reports+={safe, "any_area(any_loc(file(gnu_efi_include)))"}
+-config=MC3R1.R20.7,reports+={safe, "any_area(any_loc(file(acpi_cpu_idle)))"}
+-doc_end
+
+-doc_begin="To avoid compromising readability, the macros alternative_(v)?call[0-9] are allowed
+not to parenthesize their arguments."
+-config=MC3R1.R20.7,reports+={safe, "any_area(any_loc(any_exp(macro(^alternative_(v)?call[0-9]$))))"}
 -doc_end
 
 -doc_begin="Uses of variadic macros that have one of their arguments defined as
diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
index eb5ef2bd9dd6..5fdacfd420a1 100644
--- a/docs/misra/deviations.rst
+++ b/docs/misra/deviations.rst
@@ -345,7 +345,19 @@ Deviations related to MISRA C:2012 Rules:
        (1) as function arguments;
        (2) as macro arguments;
        (3) as array indices;
-       (4) as lhs in assignments.
+       (4) as lhs in assignments;
+       (5) as initializers, possibly designated, in initalizer lists.
+     - Tagged as `safe` for ECLAIR.
+
+   * - R20.7
+     - Violations due to the use of macros defined in files that are not
+       in scope for compliance are allowed, as that is imported code.
+     - Tagged as `safe` for ECLAIR.
+
+   * - R20.7
+     - To avoid compromising readability, the macros `alternative_(v)?call[0-9]`
+       are allowed not to parenthesize their arguments, as there are already
+       sanity checks in place.
      - Tagged as `safe` for ECLAIR.
 
    * - R20.12
diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst
index 1e134ccebc48..3914af08495b 100644
--- a/docs/misra/rules.rst
+++ b/docs/misra/rules.rst
@@ -560,7 +560,7 @@ maintainers if you want to suggest a change.
        shall be enclosed in parentheses
      - Extra parentheses are not required when macro parameters are used
        as function arguments, as macro arguments, array indices, lhs in
-       assignments
+       assignments or as initializers in initalizer lists.
 
    * - `Rule 20.9 `_
      - Required
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Mar 29 09:11:53 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Mar 2024 09:11:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699282.1092024 (Exim 4.92)
	(envelope-from )
	id 1rq8H6-0001kE-22; Fri, 29 Mar 2024 09:11:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699282.1092024; Fri, 29 Mar 2024 09:11:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rq8H5-0001jE-Lp; Fri, 29 Mar 2024 09:11:47 +0000
Received: by outflank-mailman (input) for mailman id 699282;
 Fri, 29 Mar 2024 09:11:47 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rq8H5-0000x2-0u
 for xen-devel@lists.xenproject.org; Fri, 29 Mar 2024 09:11:47 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5d9a25db-edac-11ee-afe3-a90da7624cb6;
 Fri, 29 Mar 2024 10:11:45 +0100 (CET)
Received: from nico.bugseng.com (unknown [176.206.12.122])
 by support.bugseng.com (Postfix) with ESMTPSA id 1433F4EE0749;
 Fri, 29 Mar 2024 10:11:45 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5d9a25db-edac-11ee-afe3-a90da7624cb6
From: Nicola Vetrini 
To: nicola.vetrini@bugseng.com,
	xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org,
	michal.orzel@amd.com,
	xenia.ragiadakou@amd.com,
	ayan.kumar.halder@amd.com,
	consulting@bugseng.com,
	bertrand.marquis@arm.com,
	julien@xen.org,
	Andrew Cooper ,
	George Dunlap ,
	Jan Beulich 
Subject: [XEN PATCH v3 6/7] xen/mm: address violations of MISRA C Rule 20.7
Date: Fri, 29 Mar 2024 10:11:34 +0100
Message-Id: <9fade8c540f19876fe7928ab91398bd5e94594b4.1711700095.git.nicola.vetrini@bugseng.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter the semantics of the passed-in macro parameter.

No functional change.

Signed-off-by: Nicola Vetrini 
---
 xen/include/xen/mm.h | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h
index 3e84960a365f..7561297a7553 100644
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -415,15 +415,15 @@ page_list_splice(struct page_list_head *list, struct page_list_head *head)
 }
 
 #define page_list_for_each(pos, head) \
-    for ( pos = (head)->next; pos; pos = page_list_next(pos, head) )
+    for ( (pos) = (head)->next; (pos); (pos) = page_list_next(pos, head) )
 #define page_list_for_each_safe(pos, tmp, head) \
-    for ( pos = (head)->next; \
-          pos ? (tmp = page_list_next(pos, head), 1) : 0; \
-          pos = tmp )
+    for ( (pos) = (head)->next; \
+          (pos) ? ((tmp) = page_list_next(pos, head), 1) : 0; \
+          (pos) = (tmp) )
 #define page_list_for_each_safe_reverse(pos, tmp, head) \
-    for ( pos = (head)->tail; \
-          pos ? (tmp = page_list_prev(pos, head), 1) : 0; \
-          pos = tmp )
+    for ( (pos) = (head)->tail; \
+          (pos) ? ((tmp) = page_list_prev(pos, head), 1) : 0; \
+          (pos) = (tmp) )
 #else
 # define page_list_head                  list_head
 # define PAGE_LIST_HEAD_INIT             LIST_HEAD_INIT
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Mar 29 09:11:53 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Mar 2024 09:11:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699278.1091991 (Exim 4.92)
	(envelope-from )
	id 1rq8H3-0001BX-Qp; Fri, 29 Mar 2024 09:11:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699278.1091991; Fri, 29 Mar 2024 09:11:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rq8H3-0001BQ-OK; Fri, 29 Mar 2024 09:11:45 +0000
Received: by outflank-mailman (input) for mailman id 699278;
 Fri, 29 Mar 2024 09:11:44 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rq8H2-0000x2-By
 for xen-devel@lists.xenproject.org; Fri, 29 Mar 2024 09:11:44 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5b9a590e-edac-11ee-afe3-a90da7624cb6;
 Fri, 29 Mar 2024 10:11:42 +0100 (CET)
Received: from nico.bugseng.com (unknown [176.206.12.122])
 by support.bugseng.com (Postfix) with ESMTPSA id 2285D4EE0743;
 Fri, 29 Mar 2024 10:11:41 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5b9a590e-edac-11ee-afe3-a90da7624cb6
From: Nicola Vetrini 
To: nicola.vetrini@bugseng.com,
	xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org,
	michal.orzel@amd.com,
	xenia.ragiadakou@amd.com,
	ayan.kumar.halder@amd.com,
	consulting@bugseng.com,
	bertrand.marquis@arm.com,
	julien@xen.org,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [XEN PATCH v3 1/7] x86/msi: address violation of MISRA C Rule 20.7 and coding style
Date: Fri, 29 Mar 2024 10:11:29 +0100
Message-Id: <2f2c865f20d0296e623f1d65bed25c083f5dd497.1711700095.git.nicola.vetrini@bugseng.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter the semantics of the passed-in macro parameter.

While at it, the style of these macros has been somewhat uniformed.

No functional change.

Signed-off-by: Nicola Vetrini 
---
Changes in v2:
- Make the style change more consistent
---
 xen/arch/x86/include/asm/msi.h | 49 +++++++++++++++++-----------------
 1 file changed, 25 insertions(+), 24 deletions(-)

diff --git a/xen/arch/x86/include/asm/msi.h b/xen/arch/x86/include/asm/msi.h
index 997ccb87be0c..bd110c357ce4 100644
--- a/xen/arch/x86/include/asm/msi.h
+++ b/xen/arch/x86/include/asm/msi.h
@@ -147,33 +147,34 @@ int msi_free_irq(struct msi_desc *entry);
  */
 #define NR_HP_RESERVED_VECTORS 	20
 
-#define msi_control_reg(base)		(base + PCI_MSI_FLAGS)
-#define msi_lower_address_reg(base)	(base + PCI_MSI_ADDRESS_LO)
-#define msi_upper_address_reg(base)	(base + PCI_MSI_ADDRESS_HI)
-#define msi_data_reg(base, is64bit)	\
-	( (is64bit == 1) ? base+PCI_MSI_DATA_64 : base+PCI_MSI_DATA_32 )
-#define msi_mask_bits_reg(base, is64bit) \
-	( (is64bit == 1) ? base+PCI_MSI_MASK_BIT : base+PCI_MSI_MASK_BIT-4)
+#define msi_control_reg(base)        ((base) + PCI_MSI_FLAGS)
+#define msi_lower_address_reg(base)  ((base) + PCI_MSI_ADDRESS_LO)
+#define msi_upper_address_reg(base)  ((base) + PCI_MSI_ADDRESS_HI)
+#define msi_data_reg(base, is64bit) \
+    (((is64bit) == 1) ? (base) + PCI_MSI_DATA_64 : (base) + PCI_MSI_DATA_32)
+#define msi_mask_bits_reg(base, is64bit)                \
+    (((is64bit) == 1) ? (base) + PCI_MSI_MASK_BIT       \
+                      : (base) + PCI_MSI_MASK_BIT - 4)
 #define msi_pending_bits_reg(base, is64bit) \
-	((base) + PCI_MSI_MASK_BIT + ((is64bit) ? 4 : 0))
-#define msi_disable(control)		control &= ~PCI_MSI_FLAGS_ENABLE
+    ((base) + PCI_MSI_MASK_BIT + ((is64bit) ? 4 : 0))
+#define msi_disable(control)         ({ (control) &= ~PCI_MSI_FLAGS_ENABLE })
 #define multi_msi_capable(control) \
-	(1 << ((control & PCI_MSI_FLAGS_QMASK) >> 1))
+    (1 << (((control) & PCI_MSI_FLAGS_QMASK) >> 1))
 #define multi_msi_enable(control, num) \
-	control |= (((fls(num) - 1) << 4) & PCI_MSI_FLAGS_QSIZE);
-#define is_64bit_address(control)	(!!(control & PCI_MSI_FLAGS_64BIT))
-#define is_mask_bit_support(control)	(!!(control & PCI_MSI_FLAGS_MASKBIT))
-#define msi_enable(control, num) multi_msi_enable(control, num); \
-	control |= PCI_MSI_FLAGS_ENABLE
-
-#define msix_control_reg(base)		(base + PCI_MSIX_FLAGS)
-#define msix_table_offset_reg(base)	(base + PCI_MSIX_TABLE)
-#define msix_pba_offset_reg(base)	(base + PCI_MSIX_PBA)
-#define msix_enable(control)	 	control |= PCI_MSIX_FLAGS_ENABLE
-#define msix_disable(control)	 	control &= ~PCI_MSIX_FLAGS_ENABLE
-#define msix_table_size(control) 	((control & PCI_MSIX_FLAGS_QSIZE)+1)
-#define msix_unmask(address)	 	(address & ~PCI_MSIX_VECTOR_BITMASK)
-#define msix_mask(address)		(address | PCI_MSIX_VECTOR_BITMASK)
+    ({ (control) |= (((fls(num) - 1) << 4) & PCI_MSI_FLAGS_QSIZE) })
+#define is_64bit_address(control)    (!!((control) & PCI_MSI_FLAGS_64BIT))
+#define is_mask_bit_support(control) (!!((control) & PCI_MSI_FLAGS_MASKBIT))
+#define msi_enable(control, num)     ({ multi_msi_enable(control, num); \
+                                        (control) |= PCI_MSI_FLAGS_ENABLE })
+
+#define msix_control_reg(base)       ((base) + PCI_MSIX_FLAGS)
+#define msix_table_offset_reg(base)  ((base) + PCI_MSIX_TABLE)
+#define msix_pba_offset_reg(base)    ((base) + PCI_MSIX_PBA)
+#define msix_enable(control)         ({ (control) |= PCI_MSIX_FLAGS_ENABLE })
+#define msix_disable(control)        ({ (control) &= ~PCI_MSIX_FLAGS_ENABLE })
+#define msix_table_size(control)     (((control) & PCI_MSIX_FLAGS_QSIZE) + 1)
+#define msix_unmask(address)         ((address) & ~PCI_MSIX_VECTOR_BITMASK)
+#define msix_mask(address)           ((address) | PCI_MSIX_VECTOR_BITMASK)
 
 /*
  * MSI Defined Data Structures
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Mar 29 09:11:53 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Mar 2024 09:11:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699280.1092011 (Exim 4.92)
	(envelope-from )
	id 1rq8H5-0001em-Bm; Fri, 29 Mar 2024 09:11:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699280.1092011; Fri, 29 Mar 2024 09:11:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rq8H5-0001ef-7D; Fri, 29 Mar 2024 09:11:47 +0000
Received: by outflank-mailman (input) for mailman id 699280;
 Fri, 29 Mar 2024 09:11:46 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rq8H4-0000x2-0m
 for xen-devel@lists.xenproject.org; Fri, 29 Mar 2024 09:11:46 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5caf7aa1-edac-11ee-afe3-a90da7624cb6;
 Fri, 29 Mar 2024 10:11:44 +0100 (CET)
Received: from nico.bugseng.com (unknown [176.206.12.122])
 by support.bugseng.com (Postfix) with ESMTPSA id 026534EE0747;
 Fri, 29 Mar 2024 10:11:42 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5caf7aa1-edac-11ee-afe3-a90da7624cb6
From: Nicola Vetrini 
To: nicola.vetrini@bugseng.com,
	xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org,
	michal.orzel@amd.com,
	xenia.ragiadakou@amd.com,
	ayan.kumar.halder@amd.com,
	consulting@bugseng.com,
	bertrand.marquis@arm.com,
	julien@xen.org,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [XEN PATCH v3 3/7] x86/vPMU: address violations of MISRA C Rule 20.7
Date: Fri, 29 Mar 2024 10:11:31 +0100
Message-Id: 
X-Mailer: git-send-email 2.34.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter the semantics of the passed-in macro parameter.

No functional change.

Signed-off-by: Nicola Vetrini 
---
 xen/arch/x86/include/asm/vpmu.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/include/asm/vpmu.h b/xen/arch/x86/include/asm/vpmu.h
index f271f28e4a74..dae9b43dac6e 100644
--- a/xen/arch/x86/include/asm/vpmu.h
+++ b/xen/arch/x86/include/asm/vpmu.h
@@ -23,8 +23,8 @@
 #define MSR_TYPE_ARCH_CTRL          4
 
 /* Start of PMU register bank */
-#define vpmu_reg_pointer(ctxt, offset) ((void *)((uintptr_t)ctxt + \
-                                                 (uintptr_t)ctxt->offset))
+#define vpmu_reg_pointer(ctxt, offset) ((void *)((uintptr_t)(ctxt) + \
+                                                 (uintptr_t)(ctxt)->offset))
 
 /* Arch specific operations shared by all vpmus */
 struct arch_vpmu_ops {
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Mar 29 09:11:53 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Mar 2024 09:11:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699277.1091981 (Exim 4.92)
	(envelope-from )
	id 1rq8H2-0000xF-Kq; Fri, 29 Mar 2024 09:11:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699277.1091981; Fri, 29 Mar 2024 09:11:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rq8H2-0000x8-Hf; Fri, 29 Mar 2024 09:11:44 +0000
Received: by outflank-mailman (input) for mailman id 699277;
 Fri, 29 Mar 2024 09:11:43 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rq8H1-0000ww-Cc
 for xen-devel@lists.xenproject.org; Fri, 29 Mar 2024 09:11:43 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5aeb5857-edac-11ee-a1ef-f123f15fe8a2;
 Fri, 29 Mar 2024 10:11:41 +0100 (CET)
Received: from nico.bugseng.com (unknown [176.206.12.122])
 by support.bugseng.com (Postfix) with ESMTPSA id C1AE34EE073F;
 Fri, 29 Mar 2024 10:11:38 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5aeb5857-edac-11ee-a1ef-f123f15fe8a2
From: Nicola Vetrini 
To: nicola.vetrini@bugseng.com,
	xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org,
	michal.orzel@amd.com,
	xenia.ragiadakou@amd.com,
	ayan.kumar.halder@amd.com,
	consulting@bugseng.com,
	bertrand.marquis@arm.com,
	julien@xen.org,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Volodymyr Babchuk ,
	Simone Ballarin ,
	Doug Goldstein ,
	George Dunlap 
Subject: [XEN PATCH v3 0/7] address violations of MISRA C Rule 20.7 
Date: Fri, 29 Mar 2024 10:11:28 +0100
Message-Id: 
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Hi all,

this series aims to refactor some macros that cause violations of MISRA C Rule
20.7 ("Expressions resulting from the expansion of macro parameters shall be
enclosed in parentheses"). All the macros touched by these patches are in some
way involved in violations, and the strategy adopted to bring them into
compliance is to add parentheses around macro arguments where needed.

Deviations from the rule have been amended to encompass also direct use in
initializer lists of macro arguments.

Patch 1 is taken, with adjustments, from the earlier series (which was
incorrectly tagged as v1). All other patches are new in this series and are
pairwise indipendent.

Nicola Vetrini (7):
  x86/msi: address violation of MISRA C Rule 20.7 and coding style
  arm/public: address violations of MISRA C Rule 20.7
  x86/vPMU: address violations of MISRA C Rule 20.7
  x86/hvm: address violations of MISRA C Rule 20.7
  automation/eclair: add deviations for Rule 20.7
  xen/mm: address violations of MISRA C Rule 20.7
  x86/amd: address violations of MISRA C Rule 20.7

 .../eclair_analysis/ECLAIR/deviations.ecl     | 25 +++++++++-
 docs/misra/deviations.rst                     | 14 +++++-
 docs/misra/rules.rst                          |  2 +-
 xen/arch/x86/hvm/domain.c                     |  6 +--
 xen/arch/x86/include/asm/amd.h                |  3 +-
 xen/arch/x86/include/asm/msi.h                | 49 ++++++++++---------
 xen/arch/x86/include/asm/vpmu.h               |  4 +-
 xen/include/public/arch-arm.h                 |  2 +-
 xen/include/xen/mm.h                          | 14 +++---
 9 files changed, 77 insertions(+), 42 deletions(-)

-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Mar 29 09:11:53 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Mar 2024 09:11:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699284.1092050 (Exim 4.92)
	(envelope-from )
	id 1rq8H7-0002Y4-TC; Fri, 29 Mar 2024 09:11:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699284.1092050; Fri, 29 Mar 2024 09:11:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rq8H7-0002XR-Nf; Fri, 29 Mar 2024 09:11:49 +0000
Received: by outflank-mailman (input) for mailman id 699284;
 Fri, 29 Mar 2024 09:11:48 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rq8H6-0000ww-5X
 for xen-devel@lists.xenproject.org; Fri, 29 Mar 2024 09:11:48 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5de8bcc3-edac-11ee-a1ef-f123f15fe8a2;
 Fri, 29 Mar 2024 10:11:46 +0100 (CET)
Received: from nico.bugseng.com (unknown [176.206.12.122])
 by support.bugseng.com (Postfix) with ESMTPSA id 8F3F84EE0C8D;
 Fri, 29 Mar 2024 10:11:45 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5de8bcc3-edac-11ee-a1ef-f123f15fe8a2
From: Nicola Vetrini 
To: nicola.vetrini@bugseng.com,
	xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org,
	michal.orzel@amd.com,
	xenia.ragiadakou@amd.com,
	ayan.kumar.halder@amd.com,
	consulting@bugseng.com,
	bertrand.marquis@arm.com,
	julien@xen.org,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [XEN PATCH v3 7/7] x86/amd: address violations of MISRA C Rule 20.7
Date: Fri, 29 Mar 2024 10:11:35 +0100
Message-Id: 
X-Mailer: git-send-email 2.34.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter the semantics of the passed-in macro parameter.

No functional change.

Signed-off-by: Nicola Vetrini 
---
 xen/arch/x86/include/asm/amd.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/include/asm/amd.h b/xen/arch/x86/include/asm/amd.h
index 2cc0ce2e9fd2..fa4e0fc766aa 100644
--- a/xen/arch/x86/include/asm/amd.h
+++ b/xen/arch/x86/include/asm/amd.h
@@ -119,7 +119,8 @@
 #define AMD_LEGACY_ERRATUM(...)         -1 /* legacy */, __VA_ARGS__, 0
 #define AMD_OSVW_ERRATUM(osvw_id, ...)  osvw_id, __VA_ARGS__, 0
 #define AMD_MODEL_RANGE(f, m_start, s_start, m_end, s_end)              \
-    ((f << 24) | (m_start << 16) | (s_start << 12) | (m_end << 4) | (s_end))
+    (((f) << 24) | ((m_start) << 16) | ((s_start) << 12) | \
+     ((m_end) << 4) | (s_end))
 #define AMD_MODEL_RANGE_FAMILY(range)   (((range) >> 24) & 0xff)
 #define AMD_MODEL_RANGE_START(range)    (((range) >> 12) & 0xfff)
 #define AMD_MODEL_RANGE_END(range)      ((range) & 0xfff)
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Mar 29 09:11:54 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Mar 2024 09:11:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699279.1091997 (Exim 4.92)
	(envelope-from )
	id 1rq8H4-0001Dm-2a; Fri, 29 Mar 2024 09:11:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699279.1091997; Fri, 29 Mar 2024 09:11:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rq8H3-0001DO-U9; Fri, 29 Mar 2024 09:11:45 +0000
Received: by outflank-mailman (input) for mailman id 699279;
 Fri, 29 Mar 2024 09:11:45 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rq8H3-0000x2-0j
 for xen-devel@lists.xenproject.org; Fri, 29 Mar 2024 09:11:45 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5c11d5b4-edac-11ee-afe3-a90da7624cb6;
 Fri, 29 Mar 2024 10:11:43 +0100 (CET)
Received: from nico.bugseng.com (unknown [176.206.12.122])
 by support.bugseng.com (Postfix) with ESMTPSA id 4DB7C4EE0744;
 Fri, 29 Mar 2024 10:11:42 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5c11d5b4-edac-11ee-afe3-a90da7624cb6
From: Nicola Vetrini 
To: nicola.vetrini@bugseng.com,
	xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org,
	michal.orzel@amd.com,
	xenia.ragiadakou@amd.com,
	ayan.kumar.halder@amd.com,
	consulting@bugseng.com,
	bertrand.marquis@arm.com,
	julien@xen.org,
	Volodymyr Babchuk 
Subject: [XEN PATCH v3 2/7] arm/public: address violations of MISRA C Rule 20.7
Date: Fri, 29 Mar 2024 10:11:30 +0100
Message-Id: <142c27a41cea7402a68035dd466db0b47487fb06.1711700095.git.nicola.vetrini@bugseng.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter the semantics of the passed-in macro parameter.

No functional change.

Signed-off-by: Nicola Vetrini 
---
 xen/include/public/arch-arm.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index a25e87dbda3a..e167e14f8df9 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -209,7 +209,7 @@
     do {                                                    \
         __typeof__(&(hnd)) _sxghr_tmp = &(hnd);             \
         _sxghr_tmp->q = 0;                                  \
-        _sxghr_tmp->p = val;                                \
+        _sxghr_tmp->p = (val);                              \
     } while ( 0 )
 #define set_xen_guest_handle(hnd, val) set_xen_guest_handle_raw(hnd, val)
 
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Mar 29 09:48:09 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Mar 2024 09:48:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699308.1092060 (Exim 4.92)
	(envelope-from )
	id 1rq8q9-0000Sm-Ih; Fri, 29 Mar 2024 09:48:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699308.1092060; Fri, 29 Mar 2024 09:48:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rq8q9-0000Sf-FE; Fri, 29 Mar 2024 09:48:01 +0000
Received: by outflank-mailman (input) for mailman id 699308;
 Fri, 29 Mar 2024 09:48:00 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rq8q8-0000SZ-1Q
 for xen-devel@lists.xenproject.org; Fri, 29 Mar 2024 09:48:00 +0000
Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com
 [2607:f8b0:4864:20::102d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6b65c7dd-edb1-11ee-a1ef-f123f15fe8a2;
 Fri, 29 Mar 2024 10:47:57 +0100 (CET)
Received: by mail-pj1-x102d.google.com with SMTP id
 98e67ed59e1d1-29df3333d30so1373865a91.1
 for ; Fri, 29 Mar 2024 02:47:57 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6b65c7dd-edb1-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1711705675; x=1712310475; darn=lists.xenproject.org;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=Oh0leBodThLl+/WwZkKWIFfNI0+ZRn+gaWdkMtSiKdY=;
        b=UCWTwZkAfvzF2I6sOa/bMrIIsGL0Wh8zXvmVgCnMYF4qwy60f+AM3yBGdj8ApbrwT0
         RZDUEw1uYAiOm8flpP9Ek+RqA3FHzncW6YV/hvskaKJLJnDEmLA/O6wpDeXSo7EyKfIR
         y2PpQj/tZzJoLxqnzanLCNeEQ3q90Mft6d7wuCi+3K818TPqnR19fq2AS4Z5dPzZMcMv
         GJrWJkRyNOWkBm0btsqCI7QjFgdrmcQkWHkNnPj9adNxhL3/Hon+7BLY4GLRx6WnlaEQ
         xTulgOArNs8tC3Fhwj/YtxSrmhDmRw5GNB+gkIcd61MWH5FGdurmAm9gcLQIQAawuLAY
         JAHg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711705675; x=1712310475;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=Oh0leBodThLl+/WwZkKWIFfNI0+ZRn+gaWdkMtSiKdY=;
        b=CBpKEEnMHxVlhGVmLzbjyKlXJq6csdrT8jwyhC9IPqzze6xwOJ9rfgyYGi3A2iKCyo
         fFvrBBck4u7eW+YlagHAbW9XCWoOaxWjJAfwMiaGOatensIUvtAs/0o2aJRTcBASHwEm
         VaTgCy773Hpw42pK2cNsxbAbxvccD5jPg5Aq4RqANdF4EWsaeW2M8FWo3khUIQ9lHjLL
         qDvuk0tCNRR85/YVSDANL3a48PxbWUknturBwGY/qAK+d1WiVix2yTL4fzPEfgBnV1p4
         cZYIPGaY6r/VpS5LAQ2gsTRtGYQetWGeeObsGPr1FMBvyiW8++VAtXBnA9vmT9sqQMN/
         72xQ==
X-Forwarded-Encrypted: i=1; AJvYcCX5rrgdiRld+OUc4mGAjKma9v8MCoLncAcD/HLSVwFWuK1YYb8B+XFzCqy5HrigaccuEc520rsut4XKLq7K0Q2ouJWZM3tywq9fPtiFQIw=
X-Gm-Message-State: AOJu0Ywsg0S3xIGjCK9r9Bek6zKAuG8ZmntsbyotXQBZ9Os4cb1r5MVA
	mGLKy+gWmQtr4bTVLO/dhzaS+q2hvZDjmHBDuyK4U4CV/GDE1Yr+1hLEO7g6wOrAGH4HvYRGlUm
	OrcmxaH5jQk7nMKNq7loz0FLWXSY=
X-Google-Smtp-Source: AGHT+IHvdVFM6Yhn09w77HGK7jsfikHdUEX+kciFWiqwEiPVYac73i21jJYp0yxoHddRUojLc67TTiKVW5Q2aJI0SQo=
X-Received: by 2002:a17:90a:f3c6:b0:29f:f6c7:1ace with SMTP id
 ha6-20020a17090af3c600b0029ff6c71acemr1697823pjb.32.1711705675399; Fri, 29
 Mar 2024 02:47:55 -0700 (PDT)
MIME-Version: 1.0
References: <171154167446.2671062.9127105384591237363.stgit@firesoul>
In-Reply-To: <171154167446.2671062.9127105384591237363.stgit@firesoul>
From: Arthur Borsboom 
Date: Fri, 29 Mar 2024 10:47:39 +0100
Message-ID: 
Subject: Re: [PATCH net] xen-netfront: Add missing skb_mark_for_recycle
To: Jesper Dangaard Brouer 
Cc: netdev@vger.kernel.org, Ilias Apalodimas , wei.liu@kernel.org, 
	paul@xen.org, Jakub Kicinski , kirjanov@gmail.com, dkirjanov@suse.de, 
	kernel-team@cloudflare.com, security@xenproject.org, 
	andrew.cooper3@citrix.com, xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"

On Wed, 27 Mar 2024 at 13:15, Jesper Dangaard Brouer  wrote:
>
> Notice that skb_mark_for_recycle() is introduced later than fixes tag in
> 6a5bcd84e886 ("page_pool: Allow drivers to hint on SKB recycling").
>
> It is believed that fixes tag were missing a call to page_pool_release_page()
> between v5.9 to v5.14, after which is should have used skb_mark_for_recycle().
> Since v6.6 the call page_pool_release_page() were removed (in 535b9c61bdef
> ("net: page_pool: hide page_pool_release_page()") and remaining callers
> converted (in commit 6bfef2ec0172 ("Merge branch
> 'net-page_pool-remove-page_pool_release_page'")).
>
> This leak became visible in v6.8 via commit dba1b8a7ab68 ("mm/page_pool: catch
> page_pool memory leaks").
>
> Fixes: 6c5aa6fc4def ("xen networking: add basic XDP support for xen-netfront")
> Reported-by: Arthur Borsboom 
> Signed-off-by: Jesper Dangaard Brouer 
> ---
> Compile tested only, can someone please test this

I have tested this patch on Xen 4.18.1 with VM (Arch Linux) kernel 6.9.0-rc1.

Without the patch there are many trace traces and cloning the Linux
mainline git repository resulted in failures (same with kernel 6.8.1).
The patched kernel 6.9.0-rc1 performs as expected; cloning the git
repository was successful and no kernel traces observed.
Hereby my tested by:

Tested-by: Arthur Borsboom 



>  drivers/net/xen-netfront.c |    1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> index ad29f370034e..8d2aee88526c 100644
> --- a/drivers/net/xen-netfront.c
> +++ b/drivers/net/xen-netfront.c
> @@ -285,6 +285,7 @@ static struct sk_buff *xennet_alloc_one_rx_buffer(struct netfront_queue *queue)
>                 return NULL;
>         }
>         skb_add_rx_frag(skb, 0, page, 0, 0, PAGE_SIZE);
> +       skb_mark_for_recycle(skb);
>
>         /* Align ip header to a 16 bytes boundary */
>         skb_reserve(skb, NET_IP_ALIGN);
>
>


From xen-devel-bounces@lists.xenproject.org Fri Mar 29 10:19:48 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Mar 2024 10:19:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699320.1092070 (Exim 4.92)
	(envelope-from )
	id 1rq9Ke-000531-Rl; Fri, 29 Mar 2024 10:19:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699320.1092070; Fri, 29 Mar 2024 10:19:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rq9Ke-00052u-P8; Fri, 29 Mar 2024 10:19:32 +0000
Received: by outflank-mailman (input) for mailman id 699320;
 Fri, 29 Mar 2024 10:19:31 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rq9Kd-00052o-E1
 for xen-devel@lists.xenproject.org; Fri, 29 Mar 2024 10:19:31 +0000
Received: from sin.source.kernel.org (sin.source.kernel.org
 [2604:1380:40e1:4800::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d31a062b-edb5-11ee-afe3-a90da7624cb6;
 Fri, 29 Mar 2024 11:19:29 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sin.source.kernel.org (Postfix) with ESMTP id 5D74BCE28DA;
 Fri, 29 Mar 2024 10:19:24 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id EA8B3C433C7;
 Fri, 29 Mar 2024 10:19:22 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d31a062b-edb5-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org;
	s=korg; t=1711707563;
	bh=YKi4gOrn9DGeJgVs3gZWjPTkOjRhWQkQ0AhfqNFExlg=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=Z8R+Vk9AaVETwWhRaEMlScRY8lYNj5Vjj5HXh5+UfgzyDFzsNyncqajG1/O+QJ4+q
	 UiqGM7PveSSoOuk4zROteC9zZMoQ49sxqIGCp9U1CD7P/eNV24eFABJm2R3108fX0r
	 rkdpJuStXtuOyvOmJ0FwjFlEDS3fwfgoq6hRGTmE=
Date: Fri, 29 Mar 2024 11:19:15 +0100
From: Greg Kroah-Hartman 
To: Andrew Paniakin 
Cc: stable@vger.kernel.org, Benjamin Herrenschmidt ,
	Maximilian Heyne ,
	Boris Ostrovsky ,
	Juergen Gross ,
	Stefano Stabellini ,
	Sasha Levin , Julien Grall ,
	xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 5.4] xen/events: close evtchn after mapping cleanup
Message-ID: <2024032905-divisibly-unarmored-f080@gregkh>
References: <20240303044539.2673085-1-apanyaki@amazon.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240303044539.2673085-1-apanyaki@amazon.com>

On Sat, Mar 02, 2024 at 08:45:39PM -0800, Andrew Paniakin wrote:
> From: Andrew Panyakin 
> 
> From: Maximilian Heyne 
> 
> Commit fa765c4b4aed2d64266b694520ecb025c862c5a9 upstream
> 
> shutdown_pirq and startup_pirq are not taking the
> irq_mapping_update_lock because they can't due to lock inversion. Both
> are called with the irq_desc->lock being taking. The lock order,
> however, is first irq_mapping_update_lock and then irq_desc->lock.
> 
> This opens multiple races:
> - shutdown_pirq can be interrupted by a function that allocates an event
>   channel:
> 
>   CPU0                        CPU1
>   shutdown_pirq {
>     xen_evtchn_close(e)
>                               __startup_pirq {
>                                 EVTCHNOP_bind_pirq
>                                   -> returns just freed evtchn e
>                                 set_evtchn_to_irq(e, irq)
>                               }
>     xen_irq_info_cleanup() {
>       set_evtchn_to_irq(e, -1)
>     }
>   }
> 
>   Assume here event channel e refers here to the same event channel
>   number.
>   After this race the evtchn_to_irq mapping for e is invalid (-1).
> 
> - __startup_pirq races with __unbind_from_irq in a similar way. Because
>   __startup_pirq doesn't take irq_mapping_update_lock it can grab the
>   evtchn that __unbind_from_irq is currently freeing and cleaning up. In
>   this case even though the event channel is allocated, its mapping can
>   be unset in evtchn_to_irq.
> 
> The fix is to first cleanup the mappings and then close the event
> channel. In this way, when an event channel gets allocated it's
> potential previous evtchn_to_irq mappings are guaranteed to be unset already.
> This is also the reverse order of the allocation where first the event
> channel is allocated and then the mappings are setup.
> 
> On a 5.10 kernel prior to commit 3fcdaf3d7634 ("xen/events: modify internal
> [un]bind interfaces"), we hit a BUG like the following during probing of NVMe
> devices. The issue is that during nvme_setup_io_queues, pci_free_irq
> is called for every device which results in a call to shutdown_pirq.
> With many nvme devices it's therefore likely to hit this race during
> boot because there will be multiple calls to shutdown_pirq and
> startup_pirq are running potentially in parallel.
> 
>   ------------[ cut here ]------------
>   blkfront: xvda: barrier or flush: disabled; persistent grants: enabled; indirect descriptors: enabled; bounce buffer: enabled
>   kernel BUG at drivers/xen/events/events_base.c:499!
>   invalid opcode: 0000 [#1] SMP PTI
>   CPU: 44 PID: 375 Comm: kworker/u257:23 Not tainted 5.10.201-191.748.amzn2.x86_64 #1
>   Hardware name: Xen HVM domU, BIOS 4.11.amazon 08/24/2006
>   Workqueue: nvme-reset-wq nvme_reset_work
>   RIP: 0010:bind_evtchn_to_cpu+0xdf/0xf0
>   Code: 5d 41 5e c3 cc cc cc cc 44 89 f7 e8 2b 55 ad ff 49 89 c5 48 85 c0 0f 84 64 ff ff ff 4c 8b 68 30 41 83 fe ff 0f 85 60 ff ff ff <0f> 0b 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 0f 1f 44 00 00
>   RSP: 0000:ffffc9000d533b08 EFLAGS: 00010046
>   RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006
>   RDX: 0000000000000028 RSI: 00000000ffffffff RDI: 00000000ffffffff
>   RBP: ffff888107419680 R08: 0000000000000000 R09: ffffffff82d72b00
>   R10: 0000000000000000 R11: 0000000000000000 R12: 00000000000001ed
>   R13: 0000000000000000 R14: 00000000ffffffff R15: 0000000000000002
>   FS:  0000000000000000(0000) GS:ffff88bc8b500000(0000) knlGS:0000000000000000
>   CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>   CR2: 0000000000000000 CR3: 0000000002610001 CR4: 00000000001706e0
>   DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>   DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
>   Call Trace:
>    ? show_trace_log_lvl+0x1c1/0x2d9
>    ? show_trace_log_lvl+0x1c1/0x2d9
>    ? set_affinity_irq+0xdc/0x1c0
>    ? __die_body.cold+0x8/0xd
>    ? die+0x2b/0x50
>    ? do_trap+0x90/0x110
>    ? bind_evtchn_to_cpu+0xdf/0xf0
>    ? do_error_trap+0x65/0x80
>    ? bind_evtchn_to_cpu+0xdf/0xf0
>    ? exc_invalid_op+0x4e/0x70
>    ? bind_evtchn_to_cpu+0xdf/0xf0
>    ? asm_exc_invalid_op+0x12/0x20
>    ? bind_evtchn_to_cpu+0xdf/0xf0
>    ? bind_evtchn_to_cpu+0xc5/0xf0
>    set_affinity_irq+0xdc/0x1c0
>    irq_do_set_affinity+0x1d7/0x1f0
>    irq_setup_affinity+0xd6/0x1a0
>    irq_startup+0x8a/0xf0
>    __setup_irq+0x639/0x6d0
>    ? nvme_suspend+0x150/0x150
>    request_threaded_irq+0x10c/0x180
>    ? nvme_suspend+0x150/0x150
>    pci_request_irq+0xa8/0xf0
>    ? __blk_mq_free_request+0x74/0xa0
>    queue_request_irq+0x6f/0x80
>    nvme_create_queue+0x1af/0x200
>    nvme_create_io_queues+0xbd/0xf0
>    nvme_setup_io_queues+0x246/0x320
>    ? nvme_irq_check+0x30/0x30
>    nvme_reset_work+0x1c8/0x400
>    process_one_work+0x1b0/0x350
>    worker_thread+0x49/0x310
>    ? process_one_work+0x350/0x350
>    kthread+0x11b/0x140
>    ? __kthread_bind_mask+0x60/0x60
>    ret_from_fork+0x22/0x30
>   Modules linked in:
>   ---[ end trace a11715de1eee1873 ]---
> 
> Fixes: d46a78b05c0e ("xen: implement pirq type event channels")
> Co-debugged-by: Andrew Panyakin 
> Signed-off-by: Maximilian Heyne 
> [apanyaki: backport to v5.4-stable]
> Signed-off-by: Andrew Paniakin 
> ---
> Compare to upstream patch this one does not have close_evtchn flag
> because there is no need to handle static event channels.
> This feature was added only in 58f6259b7a08f ("xen/evtchn: Introduce new
> IOCTL to bind static evtchn")

All now qeued up, thanks.

greg k-h


From xen-devel-bounces@lists.xenproject.org Fri Mar 29 10:23:23 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Mar 2024 10:23:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699323.1092081 (Exim 4.92)
	(envelope-from )
	id 1rq9OM-0006Yo-Bf; Fri, 29 Mar 2024 10:23:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699323.1092081; Fri, 29 Mar 2024 10:23:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rq9OM-0006Yh-98; Fri, 29 Mar 2024 10:23:22 +0000
Received: by outflank-mailman (input) for mailman id 699323;
 Fri, 29 Mar 2024 10:23:20 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rq9OK-0006Yb-Fx
 for xen-devel@lists.xenproject.org; Fri, 29 Mar 2024 10:23:20 +0000
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com
 [2a00:1450:4864:20::52a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5cf6459a-edb6-11ee-afe3-a90da7624cb6;
 Fri, 29 Mar 2024 11:23:19 +0100 (CET)
Received: by mail-ed1-x52a.google.com with SMTP id
 4fb4d7f45d1cf-56bc5a3aeb9so2326064a12.3
 for ; Fri, 29 Mar 2024 03:23:19 -0700 (PDT)
Received: from [192.168.69.100] (uni14-h01-176-184-39-242.dsl.sta.abo.bbox.fr.
 [176.184.39.242]) by smtp.gmail.com with ESMTPSA id
 eb16-20020a170907281000b00a4e0df9e793sm1755345ejc.136.2024.03.29.03.23.16
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 29 Mar 2024 03:23:18 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5cf6459a-edb6-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1711707799; x=1712312599; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=QvRGWxIoYWPA4KC1nOtZccSOj22WfXQKUeWCwr9CcAM=;
        b=Hvu8QFtN0GVPpgh3tR6KZfIKfN4286SfwD8Y2TWzrY1bkB07rPqpvoOsnJj5hqE2I1
         wvZxTyLP7f1Tgc4TImOG3Ta+j6PYS1lsxxZDffDlGAMQj1lTJ+JIaWPYhXx29frG6vBB
         NfhY10oCX9xZRGRb0Wq7oB6CVEY8sogvsBPnvtu24fNhd4ULPmFkHwzgmlsgjnyNM0PJ
         z7d+ICQzNzO0NuSuqHSIX4suRdDGBIIYz/9kmCB2G/IY7MoBxfGEpUtlIKHwKHsxC4z5
         VvG4BMG1AQzidkL+uqa0KS4Y25ATSud6TD9orWMWkfYu9ZoJefUcKwERKByQT6Q0iPE5
         2pkg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711707799; x=1712312599;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=QvRGWxIoYWPA4KC1nOtZccSOj22WfXQKUeWCwr9CcAM=;
        b=OBiTPD+cj5lxJQFv1whBHBxWaWnUF61wS64XbCFD0G9S2qwV7U/QF0nNAwGqpbqSNT
         /8i2j7yA8gwb8HttW4Si5AN9fAhC90Tcx5gIcaTYKbsnT7pT7Ri6eeI47W8MKbUjE1vi
         P0EL4lB3pxprJj0cG4909r8ao/Fi2yAsO0B8hGnq+brydNVwaKdRMqDku/ewwQXpTvEd
         nWCXfNzyFslnEc7EEnzJ4mSLVdzfMNrJOh/dDWxJi+2UTqZ2cESBIru4VEm1efBc+wAf
         NoJBnoF2o+C1IgQo6xfCM450LXYPt8vhZdJn3dKyuPntFKgJwGWyTZf9cRsBemnXN/Hk
         BKyg==
X-Forwarded-Encrypted: i=1; AJvYcCXvdJZCrhPS+KHtyaW8NGwokV7uvvp91wqjko4vHwTreaSV1taQ/cD4x37GfNfuMdUWGRYJOqirurYKoA4uT/V/Qg3zkMVY3+R5yqezm68=
X-Gm-Message-State: AOJu0YxxV6JX2DNLIN8toHvHmMIy+5lWBTc3DUD8AA5wgJm0KM/EmLN7
	ASnxDDI4czPGur70UHF5vyg48d5iNtTJeNkUvRbgzyUZQR7Fe4TU5UqbxAilr2E=
X-Google-Smtp-Source: AGHT+IEKykYMFB4yOfD5Bb+oTfKqzLhkwLQOT38cufTeCOj/ARkv/rLphGMkH+ejBZNcAvqU5uV/CA==
X-Received: by 2002:a17:906:6981:b0:a4e:2570:ff56 with SMTP id i1-20020a170906698100b00a4e2570ff56mr1237049ejr.0.1711707798986;
        Fri, 29 Mar 2024 03:23:18 -0700 (PDT)
Message-ID: 
Date: Fri, 29 Mar 2024 11:23:15 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH-for-9.1 09/29] hw/i386/pc: Pass PCMachineState
 argument to acpi_setup()
To: BALATON Zoltan 
Cc: qemu-devel@nongnu.org, Richard Henderson ,
 Eduardo Habkost ,
 Stefano Stabellini , xen-devel@lists.xenproject.org,
 Bernhard Beschow , Thomas Huth ,
 Marcel Apfelbaum ,
 "Michael S. Tsirkin" , Paolo Bonzini ,
 Igor Mammedov ,
 Anthony Perard , Ani Sinha 
References: <20240328155439.58719-1-philmd@linaro.org>
 <20240328155439.58719-10-philmd@linaro.org>
 <04b9fcde-31f1-dfa8-8c4e-a666d0d873d8@eik.bme.hu>
Content-Language: en-US
From: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= 
In-Reply-To: <04b9fcde-31f1-dfa8-8c4e-a666d0d873d8@eik.bme.hu>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 28/3/24 19:45, BALATON Zoltan wrote:
> On Thu, 28 Mar 2024, Philippe Mathieu-Daudé wrote:
>> acpi_setup() caller knows about the machine state, so pass
>> it as argument to avoid a qdev_get_machine() call.
>>
>> We already resolved X86_MACHINE(pcms) as 'x86ms' so use the
>> latter.
>>
>> Signed-off-by: Philippe Mathieu-Daudé 
>> ---
>> hw/i386/acpi-build.h | 3 ++-
>> hw/i386/acpi-build.c | 5 ++---
>> hw/i386/pc.c         | 2 +-
>> 3 files changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/hw/i386/acpi-build.h b/hw/i386/acpi-build.h
>> index 0dce155c8c..31de5bddbd 100644
>> --- a/hw/i386/acpi-build.h
>> +++ b/hw/i386/acpi-build.h
>> @@ -2,6 +2,7 @@
>> #ifndef HW_I386_ACPI_BUILD_H
>> #define HW_I386_ACPI_BUILD_H
>> #include "hw/acpi/acpi-defs.h"
>> +#include "hw/i386/pc.h"
>>
>> extern const struct AcpiGenericAddress x86_nvdimm_acpi_dsmio;
>>
>> @@ -9,7 +10,7 @@ extern const struct AcpiGenericAddress 
>> x86_nvdimm_acpi_dsmio;
>> #define ACPI_PCIHP_SEJ_BASE 0x8
>> #define ACPI_PCIHP_BNMR_BASE 0x10
>>
>> -void acpi_setup(void);
>> +void acpi_setup(PCMachineState *pcms);
> 
> This is changed to PcPciMachineState * in a following patch so can't you 
> already introduce it here to avoid some churn?

Unfortunately not, because we'd need to use:

   PcPciMachineState *ppms = PC_PCI_MACHINE(pcms);

which would trigger an assertion at this point.

> 
> Regards,
> BALATON Zoltan



From xen-devel-bounces@lists.xenproject.org Fri Mar 29 10:30:24 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Mar 2024 10:30:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699327.1092091 (Exim 4.92)
	(envelope-from )
	id 1rq9Uu-0008Tm-1N; Fri, 29 Mar 2024 10:30:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699327.1092091; Fri, 29 Mar 2024 10:30:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rq9Ut-0008Tf-UQ; Fri, 29 Mar 2024 10:30:07 +0000
Received: by outflank-mailman (input) for mailman id 699327;
 Fri, 29 Mar 2024 10:30:06 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rq9Us-0008OT-HN; Fri, 29 Mar 2024 10:30:06 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rq9Us-00022Z-1K; Fri, 29 Mar 2024 10:30:06 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rq9Ur-0004fw-KU; Fri, 29 Mar 2024 10:30:05 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rq9Ur-000363-K2; Fri, 29 Mar 2024 10:30:05 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=gOPugBc4Ou7Us22MTyMx7NTfxTZF6uebW+derRDSQDo=; b=ijW0UE6X0I5bkovLjLsYRhXFDX
	ghoorhNU1OwEtBNrKCMXLX/6lslgwuH4BZOrkDx/29mqcPGqQHVeLs0ZOoNczPl3teiJFDVoeqR+g
	70S9YwfwdsdKmM0/SQA65yFQ5E42WbCwWhS4Htu28efv65alJHn/i2qCGg2CKGkgHPPY=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 185178: tolerable trouble: fail/pass/starved - PUSHED
X-Osstest-Failures:
    xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-qcow2:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-qcow2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-raw:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-vhd:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit2:hosts-allocate:starved:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-raw:hosts-allocate:starved:nonblocking
    xen-unstable:test-arm64-arm64-xl:hosts-allocate:starved:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit1:hosts-allocate:starved:nonblocking
    xen-unstable:test-arm64-arm64-xl-xsm:hosts-allocate:starved:nonblocking
    xen-unstable:test-arm64-arm64-xl-vhd:hosts-allocate:starved:nonblocking
    xen-unstable:test-arm64-arm64-xl-thunderx:hosts-allocate:starved:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-xsm:hosts-allocate:starved:nonblocking
X-Osstest-Versions-This:
    xen=8f85af65af76727692b9c2dea4f470f503432d2f
X-Osstest-Versions-That:
    xen=6f6de10ade5ade907f9e3f3c72b7b18f7852d9ff
From: osstest service owner 
Date: Fri, 29 Mar 2024 10:30:05 +0000

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt     16 saverestore-support-check    fail  like 185169
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop            fail like 185169
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop            fail like 185169
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop            fail like 185169
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 185169
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop            fail like 185169
 test-amd64-amd64-libvirt     15 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass
 test-armhf-armhf-xl-rtds     15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     16 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-multivcpu 15 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-check    fail  never pass
 test-amd64-amd64-libvirt-raw 14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  16 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-qcow2 14 migrate-support-check        fail never pass
 test-armhf-armhf-xl-qcow2    14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-qcow2    15 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-raw      14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-raw      15 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-vhd 14 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-vhd 15 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2   3 hosts-allocate               starved  n/a
 test-arm64-arm64-libvirt-raw  3 hosts-allocate               starved  n/a
 test-arm64-arm64-xl           3 hosts-allocate               starved  n/a
 test-arm64-arm64-xl-credit1   3 hosts-allocate               starved  n/a
 test-arm64-arm64-xl-xsm       3 hosts-allocate               starved  n/a
 test-arm64-arm64-xl-vhd       3 hosts-allocate               starved  n/a
 test-arm64-arm64-xl-thunderx  3 hosts-allocate               starved  n/a
 test-arm64-arm64-libvirt-xsm  3 hosts-allocate               starved  n/a

version targeted for testing:
 xen                  8f85af65af76727692b9c2dea4f470f503432d2f
baseline version:
 xen                  6f6de10ade5ade907f9e3f3c72b7b18f7852d9ff

Last test of basis   185169  2024-03-27 01:54:33 Z    2 days
Testing same since   185178  2024-03-28 04:52:04 Z    1 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper 
  George Dunlap 
  Jan Beulich 
  Jason Andryuk 
  Nicola Vetrini 

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          starved 
 test-armhf-armhf-xl                                          pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 starved 
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      starved 
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  starved 
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  starved 
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-libvirt-qcow2                               pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-xl-qcow2                                    pass    
 test-amd64-amd64-libvirt-raw                                 pass    
 test-arm64-arm64-libvirt-raw                                 starved 
 test-amd64-amd64-xl-raw                                      pass    
 test-armhf-armhf-xl-raw                                      pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-arm64-arm64-xl-thunderx                                 starved 
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-libvirt-vhd                                 pass    
 test-amd64-amd64-xl-vhd                                      pass    
 test-arm64-arm64-xl-vhd                                      starved 


------------------------------------------------------------
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
   6f6de10ade..8f85af65af  8f85af65af76727692b9c2dea4f470f503432d2f -> master


From xen-devel-bounces@lists.xenproject.org Fri Mar 29 11:11:30 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Mar 2024 11:11:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699359.1092195 (Exim 4.92)
	(envelope-from )
	id 1rqA8v-0007i2-85; Fri, 29 Mar 2024 11:11:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699359.1092195; Fri, 29 Mar 2024 11:11:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rqA8u-0007fq-W8; Fri, 29 Mar 2024 11:11:28 +0000
Received: by outflank-mailman (input) for mailman id 699359;
 Fri, 29 Mar 2024 11:11:27 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rqA8t-0006qu-Kd
 for xen-devel@lists.xenproject.org; Fri, 29 Mar 2024 11:11:27 +0000
Received: from doppler.solinno.uk (doppler.solinno.uk [81.2.106.178])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 14bca0d2-edbd-11ee-a1ef-f123f15fe8a2;
 Fri, 29 Mar 2024 12:11:24 +0100 (CET)
Received: from folly.solinno.co.uk (folly.dyn.solinno.co.uk [192.168.2.135])
 by doppler.solinno.uk (Postfix) with ESMTPSA id 2415A800AD;
 Fri, 29 Mar 2024 11:11:23 +0000 (GMT)
Received: by folly.solinno.co.uk (Postfix, from userid 1000)
 id C21C2202AC; Fri, 29 Mar 2024 11:11:22 +0000 (GMT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 14bca0d2-edbd-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=solinno.co.uk;
	s=mail; t=1711710683;
	bh=vvCdYJp3hmq98C5XpPhX29JIJPhg6FKX4zHYexemcSA=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=Na54nphOlyvcT6fmlR+2XS4n7fZOIZY6aNNyhFg131DLIZ3EO1CvFh9WxdPDl4/wS
	 4KnLfdc2ZsMcYc2U1qJyccrHyi/DEZYaDDdMaWrUgl4Ir71LV19mv4BOn/XDv0sA7m
	 5D8QfiW3LT0iNPduaQMyQgnTTnrw/QmK7xKKMS58=
From: leigh@solinno.co.uk
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	anthony.perard@citrix.com,
	slack@rabbit.lu,
	Leigh Brown 
Subject: [PATCH v2 6/6] docs/man: Add xenwatchdog manual page
Date: Fri, 29 Mar 2024 11:10:56 +0000
Message-Id: <20240329111056.6118-7-leigh@solinno.co.uk>
X-Mailer: git-send-email 2.39.2
In-Reply-To: <20240329111056.6118-1-leigh@solinno.co.uk>
References: <20240329111056.6118-1-leigh@solinno.co.uk>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Leigh Brown 

Add a manual page for xenwatchdogd.

Signed-off-by: Leigh Brown 
---
 docs/man/xenwatchdogd.8.pod | 54 +++++++++++++++++++++++++++++++++++++
 1 file changed, 54 insertions(+)
 create mode 100644 docs/man/xenwatchdogd.8.pod

diff --git a/docs/man/xenwatchdogd.8.pod b/docs/man/xenwatchdogd.8.pod
new file mode 100644
index 0000000000..2f6454f183
--- /dev/null
+++ b/docs/man/xenwatchdogd.8.pod
@@ -0,0 +1,54 @@
+=head1 NAME
+
+xenwatchdogd - Xen hypercall based watchdog daemon
+
+=head1 SYNOPSIS
+
+B [ I ] > [ > ]
+
+=head1 DESCRIPTION
+
+B arms the Xen watchdog timer to I every I
+seconds. If the xenwatchdogd process dies or is delayed for more than
+I seconds, then Xen will reboot the domain. If the domain being
+rebooted is domain 0, the whole system will reboot.
+
+=head1 OPTIONS
+
+=over 4
+
+=item B<-h>, B<--help>
+
+Display a help message.
+
+=item B<-F>, B<--foreground>
+
+Run in the foreground. The default behaviour is to daemonize.
+
+=item B<-x>, B<--safe-exit>
+
+Disable watchdog on orderly exit. The default behaviour is to arm the
+watchdog to 300 seconds to allow time for the domain to shutdown.  See 
+also the B section.
+
+=item B
+
+The number of seconds to arm the Xen watchdog timer. This must be set to
+a minimum of two.
+
+=item B
+
+The number of seconds to sleep in between calls to arm the Xen watchdog
+timer. This must be at least one second, and less than the I
+value. If not specified, it defaults to half the I value.
+
+=back
+
+=head1 SIGNALS
+
+B Will cause the program to disarm the watchdog timer and exit,
+regardless of whether the safe exit option was passed.
+
+=head1 AUTHOR
+
+Citrix Ltd and other contributors.
-- 
2.39.2



From xen-devel-bounces@lists.xenproject.org Fri Mar 29 11:11:30 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Mar 2024 11:11:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699354.1092153 (Exim 4.92)
	(envelope-from )
	id 1rqA8s-0006rD-Ma; Fri, 29 Mar 2024 11:11:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699354.1092153; Fri, 29 Mar 2024 11:11:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rqA8s-0006r6-Jc; Fri, 29 Mar 2024 11:11:26 +0000
Received: by outflank-mailman (input) for mailman id 699354;
 Fri, 29 Mar 2024 11:11:25 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rqA8r-0006qp-5b
 for xen-devel@lists.xenproject.org; Fri, 29 Mar 2024 11:11:25 +0000
Received: from doppler.solinno.uk (doppler.solinno.uk [81.2.106.178])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 13de8d71-edbd-11ee-afe3-a90da7624cb6;
 Fri, 29 Mar 2024 12:11:23 +0100 (CET)
Received: from folly.solinno.co.uk (folly.dyn.solinno.co.uk [192.168.2.135])
 by doppler.solinno.uk (Postfix) with ESMTPSA id F107A800AC;
 Fri, 29 Mar 2024 11:11:22 +0000 (GMT)
Received: by folly.solinno.co.uk (Postfix, from userid 1000)
 id BD8BC202AA; Fri, 29 Mar 2024 11:11:22 +0000 (GMT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 13de8d71-edbd-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=solinno.co.uk;
	s=mail; t=1711710682;
	bh=Q+rKJ2Q7LqFNdLGMkfelDfN5qg5la8JE5UlDaV5w0rc=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=pjf8roxX7fv1QHDjU6GvhVSOfwSdOioSDPeeUXSTkpiDomnS4uzgymF2clq2cTfpA
	 RMRHocYs8nY6hwM1K3Y4cg/8/lPEawRzHF2swPZf4QUWzdo2ugrcKpOusDd6rWfLFh
	 lar4vsFg/gmIOZOXqfi3AgxHJH9REx/ysia6S9tA=
From: leigh@solinno.co.uk
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	anthony.perard@citrix.com,
	slack@rabbit.lu,
	Leigh Brown 
Subject: [PATCH v2 4/6] tools/misc: xenwatchdogd: add parse_secs()
Date: Fri, 29 Mar 2024 11:10:54 +0000
Message-Id: <20240329111056.6118-5-leigh@solinno.co.uk>
X-Mailer: git-send-email 2.39.2
In-Reply-To: <20240329111056.6118-1-leigh@solinno.co.uk>
References: <20240329111056.6118-1-leigh@solinno.co.uk>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Leigh Brown 

Create a new parse_secs() function to parse the timeout and sleep
parameters. This ensures that non-numeric parameters are not
accidentally treated as numbers.

Signed-off-by: Leigh Brown 
---
 tools/misc/xenwatchdogd.c | 23 +++++++++++++++--------
 1 file changed, 15 insertions(+), 8 deletions(-)

diff --git a/tools/misc/xenwatchdogd.c b/tools/misc/xenwatchdogd.c
index 2e7f9f51c5..19ec4c5359 100644
--- a/tools/misc/xenwatchdogd.c
+++ b/tools/misc/xenwatchdogd.c
@@ -49,6 +49,18 @@ static void catch_usr1(int sig)
     done = true;
 }
 
+static int parse_secs(const char *arg, const char *what)
+{
+    char *endptr;
+    unsigned long val;
+
+    val = strtoul(arg, &endptr, 0);
+    if (val > INT_MAX || *endptr != 0)
+	errx(EXIT_FAILURE, "invalid %s: '%s'", what, arg);
+
+    return val;
+}
+
 int main(int argc, char **argv)
 {
     int id;
@@ -64,16 +76,11 @@ int main(int argc, char **argv)
     if (h == NULL)
 	err(EXIT_FAILURE, "xc_interface_open");
 
-    t = strtoul(argv[1], NULL, 0);
-    if (t == ULONG_MAX)
-	err(EXIT_FAILURE, "strtoul");
+    t = parse_secs(argv[optind], "timeout");
 
     s = t / 2;
-    if (argc == 3) {
-	s = strtoul(argv[2], NULL, 0);
-	if (s == ULONG_MAX)
-	    err(EXIT_FAILURE, "strtoul");
-    }
+    if (argc == 3)
+	s = parse_secs(argv[optind], "sleep");
 
     if (signal(SIGHUP, &catch_exit) == SIG_ERR)
 	err(EXIT_FAILURE, "signal");
-- 
2.39.2



From xen-devel-bounces@lists.xenproject.org Fri Mar 29 11:11:30 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Mar 2024 11:11:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699358.1092188 (Exim 4.92)
	(envelope-from )
	id 1rqA8u-0007bY-QS; Fri, 29 Mar 2024 11:11:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699358.1092188; Fri, 29 Mar 2024 11:11:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rqA8u-0007ar-L0; Fri, 29 Mar 2024 11:11:28 +0000
Received: by outflank-mailman (input) for mailman id 699358;
 Fri, 29 Mar 2024 11:11:26 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rqA8s-0006qp-RU
 for xen-devel@lists.xenproject.org; Fri, 29 Mar 2024 11:11:26 +0000
Received: from doppler.solinno.uk (doppler.solinno.uk [81.2.106.178])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 13de8d67-edbd-11ee-afe3-a90da7624cb6;
 Fri, 29 Mar 2024 12:11:23 +0100 (CET)
Received: from folly.solinno.co.uk (folly.dyn.solinno.co.uk [192.168.2.135])
 by doppler.solinno.uk (Postfix) with ESMTPSA id EE1E18009F;
 Fri, 29 Mar 2024 11:11:22 +0000 (GMT)
Received: by folly.solinno.co.uk (Postfix, from userid 1000)
 id B9288202A8; Fri, 29 Mar 2024 11:11:22 +0000 (GMT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 13de8d67-edbd-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=solinno.co.uk;
	s=mail; t=1711710682;
	bh=I1KRv77SpIHtiaVfa6jI9oqQE3FOnPOPsxPAoW9qC9A=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=MFz1C8QqkX4a00kAlbl931eb2FFXJ6Ibpk8EmslqrcQrxIzAMW8EJrabcoqrepG7X
	 Xe3XCgDyWezFivAs3sNPYJVaP6IjqFYvMcVfKS4ybDOkXPbfvXK3152rNsOdC0OrhC
	 Fgm2DFyUr9PW3AE+VnZuKTrW0YimWT0TPIkY6lkg=
From: leigh@solinno.co.uk
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	anthony.perard@citrix.com,
	slack@rabbit.lu,
	Leigh Brown 
Subject: [PATCH v2 2/6] tools/misc: rework xenwatchdogd signal handling
Date: Fri, 29 Mar 2024 11:10:52 +0000
Message-Id: <20240329111056.6118-3-leigh@solinno.co.uk>
X-Mailer: git-send-email 2.39.2
In-Reply-To: <20240329111056.6118-1-leigh@solinno.co.uk>
References: <20240329111056.6118-1-leigh@solinno.co.uk>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Leigh Brown 

Rework xenwatchdogd signal handling to do the minimum in the signal
handler. This is a very minor enhancement.

Signed-off-by: Leigh Brown 
---
 tools/misc/xenwatchdogd.c | 20 ++++++++++++--------
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/tools/misc/xenwatchdogd.c b/tools/misc/xenwatchdogd.c
index 2f7c822d61..35a0df655a 100644
--- a/tools/misc/xenwatchdogd.c
+++ b/tools/misc/xenwatchdogd.c
@@ -9,9 +9,11 @@
 #include 
 #include 
 #include 
+#include 
 
 xc_interface *h;
-int id = 0;
+static bool safeexit = false;
+static bool done = false;
 
 void daemonize(void)
 {
@@ -38,20 +40,18 @@ void daemonize(void)
 
 void catch_exit(int sig)
 {
-    if (id)
-        xc_watchdog(h, id, 300);
-    exit(EXIT_SUCCESS);
+    done = true;
 }
 
 void catch_usr1(int sig)
 {
-    if (id)
-        xc_watchdog(h, id, 0);
-    exit(EXIT_SUCCESS);
+    safeexit = true;
+    done = true;
 }
 
 int main(int argc, char **argv)
 {
+    int id;
     int t, s;
     int ret;
 
@@ -90,10 +90,14 @@ int main(int argc, char **argv)
     if (id <= 0)
         err(EXIT_FAILURE, "xc_watchdog setup");
 
-    for (;;) {
+    while (!done) {
         sleep(s);
         ret = xc_watchdog(h, id, t);
         if (ret != 0)
             err(EXIT_FAILURE, "xc_watchdog");
     }
+
+    // Zero seconds timeout will disarm the watchdog timer
+    xc_watchdog(h, id, safeexit ? 0 : 300);
+    return 0;
 }
-- 
2.39.2



From xen-devel-bounces@lists.xenproject.org Fri Mar 29 11:11:30 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Mar 2024 11:11:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699356.1092165 (Exim 4.92)
	(envelope-from )
	id 1rqA8t-0006zY-CK; Fri, 29 Mar 2024 11:11:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699356.1092165; Fri, 29 Mar 2024 11:11:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rqA8t-0006xT-3j; Fri, 29 Mar 2024 11:11:27 +0000
Received: by outflank-mailman (input) for mailman id 699356;
 Fri, 29 Mar 2024 11:11:26 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rqA8r-0006qu-VC
 for xen-devel@lists.xenproject.org; Fri, 29 Mar 2024 11:11:25 +0000
Received: from doppler.solinno.uk (doppler.solinno.uk [81.2.106.178])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 13deb0a4-edbd-11ee-a1ef-f123f15fe8a2;
 Fri, 29 Mar 2024 12:11:23 +0100 (CET)
Received: from folly.solinno.co.uk (folly.dyn.solinno.co.uk [192.168.2.135])
 by doppler.solinno.uk (Postfix) with ESMTPSA id E5CF58007C;
 Fri, 29 Mar 2024 11:11:22 +0000 (GMT)
Received: by folly.solinno.co.uk (Postfix, from userid 1000)
 id B5BBA202A6; Fri, 29 Mar 2024 11:11:22 +0000 (GMT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 13deb0a4-edbd-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=solinno.co.uk;
	s=mail; t=1711710682;
	bh=2sf3ZtOm0BxdBFc+SmNlslY2YAMo3EUI11FbwuJ5YCc=;
	h=From:To:Cc:Subject:Date:From;
	b=anY31tqlcHgrtCNxXdOGZDcJva5OXvCe/8YggAe8lXZTqpz7Lj2KLpMGpVtBMCMBr
	 Zm4OY4tbnW+3/76H1o0PwbmDUwXLq9+dneJH8P4iteN4Z6MoOtSgkZQche/CPBpBgI
	 Sjts+Y+7QDP5zZvfd9M3unI7n0c+jUTSnEwx9lCQ=
From: leigh@solinno.co.uk
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	anthony.perard@citrix.com,
	slack@rabbit.lu,
	Leigh Brown 
Subject: [PATCH v2 0/6] xenwatchdogd bugfixes and enhancements
Date: Fri, 29 Mar 2024 11:10:50 +0000
Message-Id: <20240329111056.6118-1-leigh@solinno.co.uk>
X-Mailer: git-send-email 2.39.2
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Leigh Brown 

The primary intention of this patch series is to replace the 
pathologically bad behaviour of rebooting the domain if you run 
"xenwatchdogd -h". To that end, I have implemented comprehensive 
argument validation. This validation ensures you can't pass 
arguments that instantly reboot the domain or cause it to spin 
loop running sleep(0) repeatedly.

I added a couple of enhancements whilst working on the changes as 
they were easy enough.  In particular, being able to run in the
foreground, disarming the watchdog on exit, help and a manpage.

Changes since v1:
- Add Signed-off-by on every patch.
- Make global variables static.

Full list of changes:
- Use getopt_long() to add -h/--help with associated usage help.
- Add -F/--foreground parameter to run without daemonizing.
- Add -x/--save-exit parameter to disarm the watchdog when exiting.
- Validate timeout is numeric and is at least two seconds.
- Validate sleep is numeric and is at least one and less than timeout.
- Check for too many arguments.
- Use symbol constants instead of magic numbers where possible.
- Make all functions except main() and global variables static.
- Add a manual page for xenwatchdogd().

Leigh Brown (6):
  tools/misc: xenwatchdogd: use EXIT_* constants
  tools/misc: rework xenwatchdogd signal handling
  tools/misc: xenwatchdogd: add static qualifier
  tools/misc: xenwatchdogd: add parse_secs()
  tools/misc: xenwatchdogd enhancements
  docs/man: Add xenwatchdog manual page

 docs/man/xenwatchdogd.8.pod |  54 +++++++++++
 tools/misc/xenwatchdogd.c   | 182 ++++++++++++++++++++++++++++--------
 2 files changed, 196 insertions(+), 40 deletions(-)
 create mode 100644 docs/man/xenwatchdogd.8.pod

-- 
2.39.2



From xen-devel-bounces@lists.xenproject.org Fri Mar 29 11:11:30 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Mar 2024 11:11:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699357.1092184 (Exim 4.92)
	(envelope-from )
	id 1rqA8u-0007Xt-I0; Fri, 29 Mar 2024 11:11:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699357.1092184; Fri, 29 Mar 2024 11:11:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rqA8u-0007WX-CT; Fri, 29 Mar 2024 11:11:28 +0000
Received: by outflank-mailman (input) for mailman id 699357;
 Fri, 29 Mar 2024 11:11:26 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rqA8s-0006qu-KZ
 for xen-devel@lists.xenproject.org; Fri, 29 Mar 2024 11:11:26 +0000
Received: from doppler.solinno.uk (doppler.solinno.uk [81.2.106.178])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 13de8de8-edbd-11ee-a1ef-f123f15fe8a2;
 Fri, 29 Mar 2024 12:11:23 +0100 (CET)
Received: from folly.solinno.co.uk (folly.dyn.solinno.co.uk [192.168.2.135])
 by doppler.solinno.uk (Postfix) with ESMTPSA id F080A800AB;
 Fri, 29 Mar 2024 11:11:22 +0000 (GMT)
Received: by folly.solinno.co.uk (Postfix, from userid 1000)
 id BB6D8202A9; Fri, 29 Mar 2024 11:11:22 +0000 (GMT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 13de8de8-edbd-11ee-a1ef-f123f15fe8a2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=solinno.co.uk;
	s=mail; t=1711710682;
	bh=gQdWCDqh5zFcK/ZMx9JSLjpUrWRQkvbUNQcXRiak9pQ=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=f4eP/5IlAfpJBFxFvkLT/sK9fXPQCirqm/Qd0hf0AdY30Pejr5275U/JC0zCluNY6
	 KhNSPODwnILmcRaPLLpCYe3wcUImIaffWXJupx2tLynnhohTvBMnnWBuW2qrVlNX1t
	 0JfgTNK2mBdsroKfAlPVyQ8jcGth7L44GP5xpkCk=
From: leigh@solinno.co.uk
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	anthony.perard@citrix.com,
	slack@rabbit.lu,
	Leigh Brown 
Subject: [PATCH v2 3/6] tools/misc: xenwatchdogd: add static qualifier
Date: Fri, 29 Mar 2024 11:10:53 +0000
Message-Id: <20240329111056.6118-4-leigh@solinno.co.uk>
X-Mailer: git-send-email 2.39.2
In-Reply-To: <20240329111056.6118-1-leigh@solinno.co.uk>
References: <20240329111056.6118-1-leigh@solinno.co.uk>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Leigh Brown 

Make all functions except main() static in xenwatchdogd.c. Also make
the remaining global variable static.

Signed-off-by: Leigh Brown 
---
 tools/misc/xenwatchdogd.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/misc/xenwatchdogd.c b/tools/misc/xenwatchdogd.c
index 35a0df655a..2e7f9f51c5 100644
--- a/tools/misc/xenwatchdogd.c
+++ b/tools/misc/xenwatchdogd.c
@@ -11,11 +11,11 @@
 #include 
 #include 
 
-xc_interface *h;
+static xc_interface *h;
 static bool safeexit = false;
 static bool done = false;
 
-void daemonize(void)
+static void daemonize(void)
 {
     switch (fork()) {
     case -1:
@@ -38,12 +38,12 @@ void daemonize(void)
         err(EXIT_FAILURE, "reopen stderr");
 }
 
-void catch_exit(int sig)
+static void catch_exit(int sig)
 {
     done = true;
 }
 
-void catch_usr1(int sig)
+static void catch_usr1(int sig)
 {
     safeexit = true;
     done = true;
-- 
2.39.2



From xen-devel-bounces@lists.xenproject.org Fri Mar 29 11:11:30 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Mar 2024 11:11:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699355.1092158 (Exim 4.92)
	(envelope-from )
	id 1rqA8s-0006tS-W6; Fri, 29 Mar 2024 11:11:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699355.1092158; Fri, 29 Mar 2024 11:11:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rqA8s-0006sl-R2; Fri, 29 Mar 2024 11:11:26 +0000
Received: by outflank-mailman (input) for mailman id 699355;
 Fri, 29 Mar 2024 11:11:25 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rqA8r-0006qp-RR
 for xen-devel@lists.xenproject.org; Fri, 29 Mar 2024 11:11:25 +0000
Received: from doppler.solinno.uk (doppler.solinno.uk [81.2.106.178])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 13de8cef-edbd-11ee-afe3-a90da7624cb6;
 Fri, 29 Mar 2024 12:11:23 +0100 (CET)
Received: from folly.solinno.co.uk (folly.dyn.solinno.co.uk [192.168.2.135])
 by doppler.solinno.uk (Postfix) with ESMTPSA id EBE878009E;
 Fri, 29 Mar 2024 11:11:22 +0000 (GMT)
Received: by folly.solinno.co.uk (Postfix, from userid 1000)
 id B714F20183; Fri, 29 Mar 2024 11:11:22 +0000 (GMT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 13de8cef-edbd-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=solinno.co.uk;
	s=mail; t=1711710682;
	bh=4RuAZZ2FiEx1YmWEem8TR0isA44tccZW5bEUQSzrF7E=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=cuKTzJmiwdHU1qAZR56fQjOc62NRLS9VTp6MXkfEJVBv+FZx3j7+KtNy5KBixreyp
	 r3iUm73I97pm+ZL1JJ9+dmEvvURfe3AVe3FYfCYnoue0U8ICQZPfAqhpFYH97rdlYi
	 pytqAYGc398Dqij8FFzGPPmloTZo9IL6Xq8WU+Mg=
From: leigh@solinno.co.uk
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	anthony.perard@citrix.com,
	slack@rabbit.lu,
	Leigh Brown 
Subject: [PATCH v2 1/6] tools/misc: xenwatchdogd: use EXIT_* constants
Date: Fri, 29 Mar 2024 11:10:51 +0000
Message-Id: <20240329111056.6118-2-leigh@solinno.co.uk>
X-Mailer: git-send-email 2.39.2
In-Reply-To: <20240329111056.6118-1-leigh@solinno.co.uk>
References: <20240329111056.6118-1-leigh@solinno.co.uk>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Leigh Brown 

Use EXIT_SUCCESS/EXIT_FAILURE constants instead of magic numbers.

Signed-off-by: Leigh Brown 
---
 tools/misc/xenwatchdogd.c | 40 +++++++++++++++++++--------------------
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/tools/misc/xenwatchdogd.c b/tools/misc/xenwatchdogd.c
index 254117b554..2f7c822d61 100644
--- a/tools/misc/xenwatchdogd.c
+++ b/tools/misc/xenwatchdogd.c
@@ -17,37 +17,37 @@ void daemonize(void)
 {
     switch (fork()) {
     case -1:
-	err(1, "fork");
+	err(EXIT_FAILURE, "fork");
     case 0:
 	break;
     default:
-	exit(0);
+	exit(EXIT_SUCCESS);
     }
     umask(0);
     if (setsid() < 0)
-	err(1, "setsid");
+	err(EXIT_FAILURE, "setsid");
     if (chdir("/") < 0)
-	err(1, "chdir /");
+	err(EXIT_FAILURE, "chdir /");
     if (freopen("/dev/null", "r", stdin) == NULL)
-        err(1, "reopen stdin");
+        err(EXIT_FAILURE, "reopen stdin");
     if(freopen("/dev/null", "w", stdout) == NULL)
-        err(1, "reopen stdout");
+        err(EXIT_FAILURE, "reopen stdout");
     if(freopen("/dev/null", "w", stderr) == NULL)
-        err(1, "reopen stderr");
+        err(EXIT_FAILURE, "reopen stderr");
 }
 
 void catch_exit(int sig)
 {
     if (id)
         xc_watchdog(h, id, 300);
-    exit(0);
+    exit(EXIT_SUCCESS);
 }
 
 void catch_usr1(int sig)
 {
     if (id)
         xc_watchdog(h, id, 0);
-    exit(0);
+    exit(EXIT_SUCCESS);
 }
 
 int main(int argc, char **argv)
@@ -56,44 +56,44 @@ int main(int argc, char **argv)
     int ret;
 
     if (argc < 2)
-	errx(1, "usage: %s  ", argv[0]);
+	errx(EXIT_FAILURE, "usage: %s  ", argv[0]);
 
     daemonize();
 
     h = xc_interface_open(NULL, NULL, 0);
     if (h == NULL)
-	err(1, "xc_interface_open");
+	err(EXIT_FAILURE, "xc_interface_open");
 
     t = strtoul(argv[1], NULL, 0);
     if (t == ULONG_MAX)
-	err(1, "strtoul");
+	err(EXIT_FAILURE, "strtoul");
 
     s = t / 2;
     if (argc == 3) {
 	s = strtoul(argv[2], NULL, 0);
 	if (s == ULONG_MAX)
-	    err(1, "strtoul");
+	    err(EXIT_FAILURE, "strtoul");
     }
 
     if (signal(SIGHUP, &catch_exit) == SIG_ERR)
-	err(1, "signal");
+	err(EXIT_FAILURE, "signal");
     if (signal(SIGINT, &catch_exit) == SIG_ERR)
-	err(1, "signal");
+	err(EXIT_FAILURE, "signal");
     if (signal(SIGQUIT, &catch_exit) == SIG_ERR)
-	err(1, "signal");
+	err(EXIT_FAILURE, "signal");
     if (signal(SIGTERM, &catch_exit) == SIG_ERR)
-	err(1, "signal");
+	err(EXIT_FAILURE, "signal");
     if (signal(SIGUSR1, &catch_usr1) == SIG_ERR)
-	err(1, "signal");
+	err(EXIT_FAILURE, "signal");
 
     id = xc_watchdog(h, 0, t);
     if (id <= 0)
-        err(1, "xc_watchdog setup");
+        err(EXIT_FAILURE, "xc_watchdog setup");
 
     for (;;) {
         sleep(s);
         ret = xc_watchdog(h, id, t);
         if (ret != 0)
-            err(1, "xc_watchdog");
+            err(EXIT_FAILURE, "xc_watchdog");
     }
 }
-- 
2.39.2



From xen-devel-bounces@lists.xenproject.org Fri Mar 29 11:11:31 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Mar 2024 11:11:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699360.1092201 (Exim 4.92)
	(envelope-from )
	id 1rqA8v-0007of-Jx; Fri, 29 Mar 2024 11:11:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699360.1092201; Fri, 29 Mar 2024 11:11:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rqA8v-0007mA-Ah; Fri, 29 Mar 2024 11:11:29 +0000
Received: by outflank-mailman (input) for mailman id 699360;
 Fri, 29 Mar 2024 11:11:27 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rqA8t-0006qp-RW
 for xen-devel@lists.xenproject.org; Fri, 29 Mar 2024 11:11:27 +0000
Received: from doppler.solinno.uk (doppler.solinno.uk [81.2.106.178])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 14bc7654-edbd-11ee-afe3-a90da7624cb6;
 Fri, 29 Mar 2024 12:11:25 +0100 (CET)
Received: from folly.solinno.co.uk (folly.dyn.solinno.co.uk [192.168.2.135])
 by doppler.solinno.uk (Postfix) with ESMTPSA id 25133800AE;
 Fri, 29 Mar 2024 11:11:23 +0000 (GMT)
Received: by folly.solinno.co.uk (Postfix, from userid 1000)
 id BFBD8202AB; Fri, 29 Mar 2024 11:11:22 +0000 (GMT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 14bc7654-edbd-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=solinno.co.uk;
	s=mail; t=1711710683;
	bh=FFT0JKZLTG2RafX6HaY0v4ymDYgP25/NOMi/BqeNaFo=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=IeYrDIc9gMTrE93pBdwcmZBGD+FsYwOd1s3dZPRCBY9TdX4FmqQ1uLyXQw9tfYPLf
	 Mm4QmRfG5rb2VefjPyyeP0nEF9NOawu6eeM4KEKcYZAr+tckKTHEKRwqNdpZyAmzgZ
	 TamkqEtwCFNOPPu35aIROD7sN30g6jaVLUeH/GJ0=
From: leigh@solinno.co.uk
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	anthony.perard@citrix.com,
	slack@rabbit.lu,
	Leigh Brown 
Subject: [PATCH v2 5/6] tools/misc: xenwatchdogd enhancements
Date: Fri, 29 Mar 2024 11:10:55 +0000
Message-Id: <20240329111056.6118-6-leigh@solinno.co.uk>
X-Mailer: git-send-email 2.39.2
In-Reply-To: <20240329111056.6118-1-leigh@solinno.co.uk>
References: <20240329111056.6118-1-leigh@solinno.co.uk>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Leigh Brown 

Add enhanced parameter parsing and validation, making use of
getopt_long(). Adds usage() function, ability to run in the foreground,
and the ability to disarm the watchdog timer when exiting.  Now checks
the number of parameters are correct, that timeout is at least two
seconds (to allow a minimum sleep time of one second), and that the
sleep time is at least one and less than the watchdog timeout. After
these changes, the daemon will no longer instantly reboot the domain
if you enter a zero timeout (or non-numeric parameter), and prevent
the daemon consuming 100% of a CPU. Add a copyright message. This is
based on the previous commits which were from Citrix email addresses.

Signed-off-by: Leigh Brown 
---
 tools/misc/xenwatchdogd.c | 111 ++++++++++++++++++++++++++++++++++----
 1 file changed, 101 insertions(+), 10 deletions(-)

diff --git a/tools/misc/xenwatchdogd.c b/tools/misc/xenwatchdogd.c
index 19ec4c5359..b78320f86d 100644
--- a/tools/misc/xenwatchdogd.c
+++ b/tools/misc/xenwatchdogd.c
@@ -1,3 +1,20 @@
+/*
+ * xenwatchdogd.c
+ *
+ * Watchdog based on Xen hypercall watchdog interface
+ *
+ * Copyright 2010-2024 Citrix Ltd and other contributors
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
 
 #include 
 #include 
@@ -10,6 +27,11 @@
 #include 
 #include 
 #include 
+#include 
+
+#define WDOG_MIN_TIMEOUT 2
+#define WDOG_MIN_SLEEP 1
+#define WDOG_EXIT_TIMEOUT 300
 
 static xc_interface *h;
 static bool safeexit = false;
@@ -49,6 +71,26 @@ static void catch_usr1(int sig)
     done = true;
 }
 
+static void __attribute__((noreturn)) usage(int exit_code)
+{
+    FILE *out = exit_code ? stderr : stdout;
+
+    fprintf(out,
+	"Usage: xenwatchdog [OPTION]...  []\n"
+	"  -h, --help\t\tDisplay this help text and exit.\n"
+	"  -F, --foreground\tRun in foreground.\n"
+	"  -x, --safe-exit\tDisable watchdog on orderly exit.\n"
+	"\t\t\tNote: default is to set a %d second timeout on exit.\n\n"
+	"  timeout\t\tInteger seconds to arm the watchdog each time.\n"
+	"\t\t\tNote: minimum timeout is %d seconds.\n\n"
+	"  sleep\t\t\tInteger seconds to sleep between arming the watchdog.\n"
+	"\t\t\tNote: sleep must be at least %d and less than timeout.\n"
+	"\t\t\tIf not specified then set to half the timeout.\n",
+	WDOG_EXIT_TIMEOUT, WDOG_MIN_TIMEOUT, WDOG_MIN_SLEEP
+	);
+    exit(exit_code);
+}
+
 static int parse_secs(const char *arg, const char *what)
 {
     char *endptr;
@@ -66,21 +108,70 @@ int main(int argc, char **argv)
     int id;
     int t, s;
     int ret;
+    bool daemon = true;
+
+    for ( ;; )
+    {
+	int option_index = 0, c;
+	static const struct option long_options[] =
+	{
+	    { "help", no_argument, NULL, 'h' },
+	    { "foreground", no_argument, NULL, 'F' },
+	    { "safe-exit", no_argument, NULL, 'x' },
+	    { NULL, 0, NULL, 0 },
+	};
+
+	c = getopt_long(argc, argv, "hFxD", long_options, &option_index);
+	if (c == -1)
+	    break;
+
+	switch (c)
+	{
+	case 'h':
+	    usage(EXIT_SUCCESS);
+
+	case 'F':
+	    daemon = false;
+	    break;
+
+	case 'x':
+	    safeexit = true;
+	    break;
+
+	default:
+	    usage(EXIT_FAILURE);
+	}
+    }
 
-    if (argc < 2)
-	errx(EXIT_FAILURE, "usage: %s  ", argv[0]);
+    if (argc - optind < 1)
+	errx(EXIT_FAILURE, "timeout must be specified");
 
-    daemonize();
-
-    h = xc_interface_open(NULL, NULL, 0);
-    if (h == NULL)
-	err(EXIT_FAILURE, "xc_interface_open");
+    if (argc - optind > 2)
+	errx(EXIT_FAILURE, "too many arguments");
 
     t = parse_secs(argv[optind], "timeout");
+    if (t < WDOG_MIN_TIMEOUT)
+	errx(EXIT_FAILURE, "Error: timeout must be at least %d seconds",
+			   WDOG_MIN_TIMEOUT);
 
-    s = t / 2;
-    if (argc == 3)
+    ++optind;
+    if (optind < argc) {
 	s = parse_secs(argv[optind], "sleep");
+	if (s < WDOG_MIN_SLEEP)
+	    errx(EXIT_FAILURE, "Error: sleep must be no less than %d",
+			       WDOG_MIN_SLEEP);
+	if (s >= t)
+	    errx(EXIT_FAILURE, "Error: sleep must be less than timeout");
+    }
+    else
+	s = t / 2;
+
+    if (daemon)
+	daemonize();
+
+    h = xc_interface_open(NULL, NULL, 0);
+    if (h == NULL)
+	err(EXIT_FAILURE, "xc_interface_open");
 
     if (signal(SIGHUP, &catch_exit) == SIG_ERR)
 	err(EXIT_FAILURE, "signal");
@@ -105,6 +196,6 @@ int main(int argc, char **argv)
     }
 
     // Zero seconds timeout will disarm the watchdog timer
-    xc_watchdog(h, id, safeexit ? 0 : 300);
+    xc_watchdog(h, id, safeexit ? 0 : WDOG_EXIT_TIMEOUT);
     return 0;
 }
-- 
2.39.2



From xen-devel-bounces@lists.xenproject.org Fri Mar 29 14:42:15 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Mar 2024 14:42:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699403.1092223 (Exim 4.92)
	(envelope-from )
	id 1rqDQe-0000jG-A8; Fri, 29 Mar 2024 14:42:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699403.1092223; Fri, 29 Mar 2024 14:42:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rqDQe-0000j9-6v; Fri, 29 Mar 2024 14:42:00 +0000
Received: by outflank-mailman (input) for mailman id 699403;
 Fri, 29 Mar 2024 14:41:59 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rqDQd-0000j3-0v
 for xen-devel@lists.xenproject.org; Fri, 29 Mar 2024 14:41:59 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on20600.outbound.protection.outlook.com
 [2a01:111:f403:2414::600])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7d2e9c00-edda-11ee-afe3-a90da7624cb6;
 Fri, 29 Mar 2024 15:41:56 +0100 (CET)
Received: from SJ0PR13CA0230.namprd13.prod.outlook.com (2603:10b6:a03:2c1::25)
 by CY8PR12MB8196.namprd12.prod.outlook.com (2603:10b6:930:78::17)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.40; Fri, 29 Mar
 2024 14:41:52 +0000
Received: from SJ1PEPF00001CDC.namprd05.prod.outlook.com
 (2603:10b6:a03:2c1:cafe::e) by SJ0PR13CA0230.outlook.office365.com
 (2603:10b6:a03:2c1::25) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.33 via Frontend
 Transport; Fri, 29 Mar 2024 14:41:52 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ1PEPF00001CDC.mail.protection.outlook.com (10.167.242.4) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.7409.10 via Frontend Transport; Fri, 29 Mar 2024 14:41:52 +0000
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Fri, 29 Mar
 2024 09:41:51 -0500
Received: from [172.30.141.24] (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.35 via Frontend
 Transport; Fri, 29 Mar 2024 09:41:50 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7d2e9c00-edda-11ee-afe3-a90da7624cb6
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=mfhOe+xJhcQnVG2rofqwxy+xfGL4llUJqxSZ3Tw9OpQuINpE2CMQ+nsZhHLmwCw3DKJU1015BltT1yTC318kFaDL4o1B87t49/NEglYL0SmdmbB6rQfdBR/X7Li+h847lmi8simtC0SWpLCgbbnLIG3PJQgt9Vxs6v0eqnWZP6FLkTa2AOmjkTJnyqVdsI960MZdW4XsfdXoxsy+EUnN0xhp30d/Uhsw/GF30uoK4IYPNc6aFZ1CosfbAuBWlCkTfRWL7iCChHwxKfyuiISLXs3BnHq86DsLtNOMuu06eyGN33scPu6GIQyfOJNM4V/GGkyQh0trjpuK2e2T5rMAaw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=vu6xrJyNtWjN2IpLDYgUlIrzINv61r/ruyOOPOcIvDM=;
 b=JlfGlhVRUlL9qDI+mD8yvmDUAXFV8nnqtEAmlWFlXxySP7raeVRTShL8Q6pfIjSMOUlLm8KmzugOqCF+LVll8VxGzh9O2s4ru+44Wx/PMQrKvZNzz4F62VTO/6xe5yt1f5+K0Wi3D622K0WcjA1+tJTpUuaCYc1VbUw1epQ6OILvtTQVrsBiLymRArS89XfrCnKjpAfQyWgp7yf7vsxqG31XuKfKWI+GbjgSLnY/sw5HjUinLms3p1HkaLsmMBAPpRAnZ/EzVsrvHx4RnlQSohT2FDspO38E1qhTmvQXWZel+ooiaJTz+YuFrNisTSV5YXFErUw4qTmgPBA94VUwHw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=vu6xrJyNtWjN2IpLDYgUlIrzINv61r/ruyOOPOcIvDM=;
 b=T2iWXgJzVqHUVG7F2DYFlJp/iTyEz41LVdBHYZR4Sp1DUqfb+kmzUVInOpAb6gwbB2J7nkfbEM4UIS+QTbVMx05A2zBAjEVa+Af9/UhTcNmKDNnp2u5yvnqSDcKFhrCEZdvlRWjIDSSM+9BByFLbFhSx2n85x7uCWHmwKiU3qcI=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Message-ID: 
Date: Fri, 29 Mar 2024 10:41:50 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 3/4] libelf: Store maximum PHDR p_align
To: Jan Beulich 
CC: Andrew Cooper , George Dunlap
	, Julien Grall , Stefano Stabellini
	, 
References: <20240327215102.136001-1-jason.andryuk@amd.com>
 <20240327215102.136001-4-jason.andryuk@amd.com>
 
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: 
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB04.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ1PEPF00001CDC:EE_|CY8PR12MB8196:EE_
X-MS-Office365-Filtering-Correlation-Id: a852b752-06a8-4c25-fb55-08dc4ffe5f82
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	AkcpgBUvtZnLMNDhrCGUBi7T3iBZu40YVOzAypPo7UbMpk7qveTgDOVUIZwwzHLbC/g3E49s36vQ1VrjAsedoNl4U3LOGhgpvDfd78sTQ2xYIPdpyaVtyeSgpHHh2IEdxj8MNCRUlhcmodsd0G3e1GaUINAKAsCTgyK3nFtJ4o3/i7QznU3i/ZHryK1bVojCKlwFLlx1/NLRBLx+7csWrygO4R22zrQVWazBprg/puRzmwxTaiDEH1GB1fizwGYDkfg0dQ2bOsJGIBgDJdSdlBjwyvnaaNKn2P49k6afsPKCYX+L0d4OheClK64Wk1GJD1tXIkGLGlGEU5PnpeiZeKZfnx5m6uqwvBgumeNZAxd8jH6y0k9sxUodoKzNzVBFNI+e4UYebd9TPOw61imMXxhoUIlF4St9orwRnzzzg71vaBlxz6+NTFuoL8lh71mSkTbjJNxYZpuoj8NcHfG0JJVS9wkTOkb4wv3DDrHoIsVUHKD08p6cBK5m/wKeHzUG39+1Lp3Xo8RzvPWJtKC5tE1JBqo+XvhhQ4yJ2VEzpjLTRTMamwqjahv2KfoC2+Ru+b2rb/7r8wBQEzX9hR9gbXrz20H0P5N+iBa9rpuriEc7iRPahTK7E3evIa/08s/KufO64Dpm1ICznRvaVyQ+0tfOAAFnaqU9l9VcXZH+yYyO+VITXimsPZg4+vZX6ukfILbFPtizcuBzvSIevQjwZ+joQdkocJd44DP0YxnqBMYA+VXGLWVY29pr8tX85iGE
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(1800799015)(376005)(36860700004)(82310400014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Mar 2024 14:41:52.1224
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: a852b752-06a8-4c25-fb55-08dc4ffe5f82
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ1PEPF00001CDC.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB8196

On 2024-03-28 12:47, Jan Beulich wrote:
> On 27.03.2024 22:51, Jason Andryuk wrote:
>> --- a/xen/common/libelf/libelf-loader.c
>> +++ b/xen/common/libelf/libelf-loader.c
>> @@ -468,6 +468,7 @@ void elf_parse_binary(struct elf_binary *elf)
>>   {
>>       ELF_HANDLE_DECL(elf_phdr) phdr;
>>       uint64_t low = -1, high = 0, paddr, memsz;
>> +    uint64_t max_align = 0, palign;
>>       unsigned i, count;
>>   
>>       count = elf_phdr_count(elf);
>> @@ -481,17 +482,23 @@ void elf_parse_binary(struct elf_binary *elf)
>>               continue;
>>           paddr = elf_uval(elf, phdr, p_paddr);
>>           memsz = elf_uval(elf, phdr, p_memsz);
>> -        elf_msg(elf, "ELF: phdr: paddr=%#" PRIx64 " memsz=%#" PRIx64 "\n",
>> -                paddr, memsz);
>> +        palign = elf_uval(elf, phdr, p_align);
>> +        elf_msg(elf,
>> +                "ELF: phdr: paddr=%#" PRIx64 " memsz=%#" PRIx64 " palign=%#" PRIx64 "\n",
>> +                paddr, memsz, palign);
>>           if ( low > paddr )
>>               low = paddr;
>>           if ( high < paddr + memsz )
>>               high = paddr + memsz;
>> +        if ( max_align < palign )
>> +            max_align = palign;
>>       }
>>       elf->pstart = low;
>>       elf->pend = high;
>> -    elf_msg(elf, "ELF: memory: %#" PRIx64 " -> %#" PRIx64 "\n",
>> -            elf->pstart, elf->pend);
>> +    elf->palign = max_align;
>> +    elf_msg(elf,
>> +            "ELF: memory: %#" PRIx64 " -> %#" PRIx64 " align:%#" PRIx64 "\n",
>> +            elf->pstart, elf->pend, elf->palign);
>>   }
> 
> Hmm, it's just this final logging change which I'm a little concerned by:
> Having looked at Linux'es phdr, I noticed that the addresses there aren't
> necessarily matching the corresponding alignment. Therefore I'm a little
> concerned that the output here might raise questions when people see
> seemingly inconsistent values in the log. Could you/we at least make it
> read like e.g. "align (max): ..."?

max_align?

Looking at my test vmlinux, it looks like PHDR 0 (.text) and PHDR 1 
(.data) are aligned.  It's the PHDR 2 (.init) that isn't aligned.  Is 
that what you see?

This line is already printing the min and max across all the PHDRs, so 
it would only look confusing if the start didn't match the align.

I'm not sure how useful it is to print the alignment, and I considered 
not printing it.  It's only used with PVH Dom0 right now, so it's not 
relevant in most cases.

Regards,
Jason


From xen-devel-bounces@lists.xenproject.org Fri Mar 29 15:52:04 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Mar 2024 15:52:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699427.1092233 (Exim 4.92)
	(envelope-from )
	id 1rqEWE-0001Uc-86; Fri, 29 Mar 2024 15:51:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699427.1092233; Fri, 29 Mar 2024 15:51:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rqEWE-0001UV-5V; Fri, 29 Mar 2024 15:51:50 +0000
Received: by outflank-mailman (input) for mailman id 699427;
 Fri, 29 Mar 2024 15:51:48 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rqEWC-0001UL-9W; Fri, 29 Mar 2024 15:51:48 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rqEWC-0008Ux-1v; Fri, 29 Mar 2024 15:51:48 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rqEWB-0007XG-KG; Fri, 29 Mar 2024 15:51:47 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rqEWB-0008TX-JZ; Fri, 29 Mar 2024 15:51:47 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=8M8D7S8yvGuzhs0ARlFd+TVb5bP+giF77Q4KEPIe44c=; b=k/6C/69aqnAGcVl9zUbcdxDVgc
	Uz1wWbEDAtUQDMaHE/r6pgI7L8eckkRlLOfVt3htIYt7aUhjtHFO2CBLDV/a5kyoVFZ5tkQTL5I4g
	RFnD8xJihlOyZTL7t3l771aOJCtO78uhB7wRfUe6qQ+/1SKNhVN6i7QbWoy/Hfyd3ncY=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 185177: tolerable trouble: fail/pass/starved - PUSHED
X-Osstest-Failures:
    linux-linus:test-armhf-armhf-xl-raw:debian-di-install:fail:heisenbug
    linux-linus:test-armhf-armhf-xl-arndale:xen-boot:fail:heisenbug
    linux-linus:test-armhf-armhf-xl-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-raw:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-qcow2:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-qcow2:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-vhd:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit1:hosts-allocate:starved:nonblocking
    linux-linus:test-arm64-arm64-xl-thunderx:hosts-allocate:starved:nonblocking
    linux-linus:test-arm64-arm64-xl:hosts-allocate:starved:nonblocking
    linux-linus:test-arm64-arm64-xl-xsm:hosts-allocate:starved:nonblocking
    linux-linus:test-arm64-arm64-xl-credit2:hosts-allocate:starved:nonblocking
    linux-linus:test-arm64-arm64-xl-vhd:hosts-allocate:starved:nonblocking
X-Osstest-Versions-This:
    linux=962490525cffee6270422206c9d5bdb12d472c2b
X-Osstest-Versions-That:
    linux=7033999ecd7b8cf9ea59265035a0150961e023ee
From: osstest service owner 
Date: Fri, 29 Mar 2024 15:51:47 +0000

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-raw      12 debian-di-install   fail pass in 185197-retest
 test-armhf-armhf-xl-arndale   8 xen-boot            fail pass in 185197-retest

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-raw     14 migrate-support-check fail in 185197 never pass
 test-armhf-armhf-xl-raw 15 saverestore-support-check fail in 185197 never pass
 test-armhf-armhf-xl-arndale 15 migrate-support-check fail in 185197 never pass
 test-armhf-armhf-xl-arndale 16 saverestore-support-check fail in 185197 never pass
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop            fail like 185166
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop            fail like 185166
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop            fail like 185166
 test-armhf-armhf-libvirt     16 saverestore-support-check    fail  like 185166
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop            fail like 185166
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 185166
 test-arm64-arm64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 16 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-multivcpu 15 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit1  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          16 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qcow2 14 migrate-support-check        fail never pass
 test-amd64-amd64-libvirt-raw 14 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-raw 14 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-raw 15 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-qcow2    14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-qcow2    15 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass
 test-armhf-armhf-xl-rtds     15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     16 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     15 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-vhd 14 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-vhd 15 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1   3 hosts-allocate               starved  n/a
 test-arm64-arm64-xl-thunderx  3 hosts-allocate               starved  n/a
 test-arm64-arm64-xl           3 hosts-allocate               starved  n/a
 test-arm64-arm64-xl-xsm       3 hosts-allocate               starved  n/a
 test-arm64-arm64-xl-credit2   3 hosts-allocate               starved  n/a
 test-arm64-arm64-xl-vhd       3 hosts-allocate               starved  n/a

version targeted for testing:
 linux                962490525cffee6270422206c9d5bdb12d472c2b
baseline version:
 linux                7033999ecd7b8cf9ea59265035a0150961e023ee

Last test of basis   185166  2024-03-26 21:44:24 Z    2 days
Testing same since   185177  2024-03-27 17:12:19 Z    1 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Justin Stitt 
  Kees Cook 
  Linus Torvalds 
  Linus Torvalds 
  Masami Hiramatsu (Google) 
  Max Filippov 
  Muhammad Usama Anjum 
  Oleg Nesterov 

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          starved 
 test-armhf-armhf-xl                                          pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      starved 
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-armhf-armhf-xl-arndale                                  fail    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  starved 
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  starved 
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-libvirt-qcow2                               pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-xl-qcow2                                    pass    
 test-amd64-amd64-libvirt-raw                                 pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-amd64-amd64-xl-raw                                      pass    
 test-armhf-armhf-xl-raw                                      fail    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-arm64-arm64-xl-thunderx                                 starved 
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-libvirt-vhd                                 pass    
 test-amd64-amd64-xl-vhd                                      pass    
 test-arm64-arm64-xl-vhd                                      starved 


------------------------------------------------------------
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 :

hint: The 'hooks/update' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
hint: The 'hooks/post-receive' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
hint: The 'hooks/post-update' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
To xenbits.xen.org:/home/xen/git/linux-pvops.git
   7033999ecd7b..962490525cff  962490525cffee6270422206c9d5bdb12d472c2b -> tested/linux-linus


From xen-devel-bounces@lists.xenproject.org Fri Mar 29 18:23:50 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Mar 2024 18:23:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699461.1092242 (Exim 4.92)
	(envelope-from )
	id 1rqGt6-0003pb-NG; Fri, 29 Mar 2024 18:23:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699461.1092242; Fri, 29 Mar 2024 18:23:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rqGt6-0003pU-Kg; Fri, 29 Mar 2024 18:23:36 +0000
Received: by outflank-mailman (input) for mailman id 699461;
 Fri, 29 Mar 2024 18:23:35 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1rqGt5-0003pO-Sr
 for xen-devel@lists.xenproject.org; Fri, 29 Mar 2024 18:23:35 +0000
Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com
 [2a00:1450:4864:20::230])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 73c17b6e-edf9-11ee-afe3-a90da7624cb6;
 Fri, 29 Mar 2024 19:23:34 +0100 (CET)
Received: by mail-lj1-x230.google.com with SMTP id
 38308e7fff4ca-2d6ee81bc87so20253961fa.1
 for ; Fri, 29 Mar 2024 11:23:34 -0700 (PDT)
Received: from [192.168.206.239] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 h2-20020a2e9ec2000000b002d689c6acddsm676845ljk.97.2024.03.29.11.23.32
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 29 Mar 2024 11:23:32 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 73c17b6e-edf9-11ee-afe3-a90da7624cb6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1711736613; x=1712341413; darn=lists.xenproject.org;
        h=mime-version:user-agent:content-transfer-encoding:references
         :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject
         :date:message-id:reply-to;
        bh=m86QU0qZlzhcMK38hfwO8kIIE0b0+pHTkuk0ZdiE9HY=;
        b=blXpe9J3NSQ7KCIQgp57U/QAmfwXLJjfGwxsYp4BQti/0qXYvxGzvJ81vXRSKqUiie
         Pg2h5tzkhFgFepQb+u2GSAmXW+1Pb56FJ+W6szAr9dDf0WI5tQlyY+68RRae5x9/E4mJ
         1mC1wnXyf5d5GcDHxrU/f+V0P09jSL1ORtNbFjqjlLBa7n/XDeIYmg9n4CO0KUkqjOSR
         7HGRGNStYSSOrdp8qPC+rj8zgz7rzfsnOaK6mcfQjWxQSodoEoycVu+XLmKxVIA3KRFG
         W5efNZwXBnzTTqR13cB6VBmqKz2RL6wBOY/+pfXvVK2JgzHQ69WNKrOQ8+nXsdHxhVd/
         N0Fw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711736613; x=1712341413;
        h=mime-version:user-agent:content-transfer-encoding:references
         :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=m86QU0qZlzhcMK38hfwO8kIIE0b0+pHTkuk0ZdiE9HY=;
        b=BbAlLd5rvvBgYufSaQrcdvCX+f8QXOntzNPeLyJbaQtRX7Fpd+gfBtXgSA3RDKHlLd
         aaiAcgSYrdor3n7Z7GRu3UsdNuuQIW+LAL/TW6uHDUO9zqV/AvkrtPIVHm/CDorJp3T5
         xwi1EZC/aRCPnOFEkubf6JoMwxDnb4hNcGT2g20o7H/HHxHwtq+QkCRN9C0EreuCxRLa
         YKkWdLB3ZFKJ8uqclIYltghMdDdGbLKEivoMKokIaUMgWLzhV3ZW1RFOh+Bvhtb+j/VT
         hNaeS7neeKluHkK2j7EgxRAlVmnzZDRynCC/LTxh0K7ywvu/HtolOW96yZAwWtT3U9vm
         4BZA==
X-Forwarded-Encrypted: i=1; AJvYcCV8GUWTGgeRkFVQWbqq02zCfB3As8n0sqVy1q9v2+ML6QasvSCmb5SxJTkxYJvt7qCmHq4fGkQkVGXSNec26kdhIIJq9xdy/8aChCq9ygE=
X-Gm-Message-State: AOJu0YyzFGlU+tfsUaQ6pnkZ9IruC5yHDsjH8gryHAgwADaQhHyjyu9L
	+zulzdlk2yEb0Io1iBpbUE2r5VRFEJjqNoNyhb+Y3kd8c3WUrKJR
X-Google-Smtp-Source: AGHT+IH4D0cO6yIUo4vod8MyARWg284IZopfX8yW2cDxgLSnStgTdQN6JmI1g2c78mWgMHOrw0tnig==
X-Received: by 2002:a2e:bc06:0:b0:2d7:ae9:b579 with SMTP id b6-20020a2ebc06000000b002d70ae9b579mr2149588ljf.33.1711736613184;
        Fri, 29 Mar 2024 11:23:33 -0700 (PDT)
Message-ID: <827d3d8ee11bd4a3c20dbee936132df231db1e73.camel@gmail.com>
Subject: Re: [PATCH v6 06/20] xen/bitops: put __ffs() and ffz() into linux
 compatible header
From: Oleksii 
To: Jan Beulich 
Cc: Stefano Stabellini , Julien Grall
 ,  Bertrand Marquis , Michal
 Orzel , Volodymyr Babchuk
 , Andrew Cooper , 
 George Dunlap , Wei Liu , Shawn
 Anastasio , Rahul Singh
 ,  xen-devel@lists.xenproject.org
Date: Fri, 29 Mar 2024 19:23:31 +0100
In-Reply-To: 
References: 
	 <8bc35da4a9fd44d2dcf9677dcc99334eb7142581.1710517542.git.oleksii.kurochko@gmail.com>
	 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.50.2 (3.50.2-1.fc39) 
MIME-Version: 1.0

On Wed, 2024-03-20 at 16:42 +0100, Jan Beulich wrote:
> On 15.03.2024 19:06, Oleksii Kurochko wrote:
> > --- a/xen/lib/find-next-bit.c
> > +++ b/xen/lib/find-next-bit.c
> > @@ -9,6 +9,7 @@
> > =C2=A0 * 2 of the License, or (at your option) any later version.
> > =C2=A0 */
> > =C2=A0#include 
> > +#include 
> > =C2=A0
> > =C2=A0#include 
>=20
> Hmm, no, a library source would better not include this header.
> Surely
> the ffz() can be taken care of locally here?
Except that __ffs() from xen/linux-compat.h is used in find-next-bit.c,
so it seems that it is still need to include the header.

~ Oleksii


From xen-devel-bounces@lists.xenproject.org Fri Mar 29 18:56:21 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Mar 2024 18:56:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699471.1092260 (Exim 4.92)
	(envelope-from )
	id 1rqHOi-0008GX-Az; Fri, 29 Mar 2024 18:56:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699471.1092260; Fri, 29 Mar 2024 18:56:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rqHOi-0008GQ-8F; Fri, 29 Mar 2024 18:56:16 +0000
Received: by outflank-mailman (input) for mailman id 699471;
 Fri, 29 Mar 2024 18:56:14 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rqHOg-0008GG-ED; Fri, 29 Mar 2024 18:56:14 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rqHOg-000472-CF; Fri, 29 Mar 2024 18:56:14 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rqHOg-00074A-1a; Fri, 29 Mar 2024 18:56:14 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rqHOg-00078k-1C; Fri, 29 Mar 2024 18:56:14 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=lwbFHN2TXaBt7OTcY1OguauNS5ePM5y4afp3WAm9Dzk=; b=4v2zEfFFAlmEMZoDIbvnDOMPLZ
	KiCfzQXNYt+kcCh9g0Dw/40jJOVJN1VwD/mAIzgV0NhW5cPt3JYZYIZIB9CR1taSYf0SAZ7vVC/VG
	PRnuvWqreQvyK2IDzjZm/snySpyAhFMPVW2hZ5C2d02m2AIoiVzqsu+/jJpLG7tCSRLk=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-4.18-testing test] 185183: tolerable FAIL - PUSHED
X-Osstest-Failures:
    xen-4.18-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-qcow2:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-qcow2:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-libvirt-vhd:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-libvirt-vhd:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-raw:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-raw:saverestore-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    xen-4.18-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    xen=0a8b92d0a47797ec4d70c7fd7b05abbc135b51dc
X-Osstest-Versions-That:
    xen=c9ea3b49a5d546a7c786dd0a0caec00c9c7f2633
From: osstest service owner 
Date: Fri, 29 Mar 2024 18:56:14 +0000

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen                  0a8b92d0a47797ec4d70c7fd7b05abbc135b51dc
baseline version:
 xen                  c9ea3b49a5d546a7c786dd0a0caec00c9c7f2633

Last test of basis   185172  2024-03-27 11:37:13 Z    2 days
Testing same since   185183  2024-03-28 16:05:48 Z    1 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper 
  Christian Lindig 
  Edwin Török 

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-libvirt-qcow2                               pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-xl-qcow2                                    pass    
 test-amd64-amd64-libvirt-raw                                 pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-amd64-amd64-xl-raw                                      pass    
 test-armhf-armhf-xl-raw                                      pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-libvirt-vhd                                 pass    
 test-amd64-amd64-xl-vhd                                      pass    
 test-arm64-arm64-xl-vhd                                      pass    


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

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

Explanation of these 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
   c9ea3b49a5..0a8b92d0a4  0a8b92d0a47797ec4d70c7fd7b05abbc135b51dc -> stable-4.18


From xen-devel-bounces@lists.xenproject.org Sat Mar 30 02:24:43 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 30 Mar 2024 02:24:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699501.1092274 (Exim 4.92)
	(envelope-from )
	id 1rqOOR-0001aW-LO; Sat, 30 Mar 2024 02:24:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699501.1092274; Sat, 30 Mar 2024 02:24:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rqOOR-0001aD-Ew; Sat, 30 Mar 2024 02:24:27 +0000
Received: by outflank-mailman (input) for mailman id 699501;
 Sat, 30 Mar 2024 02:24:26 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rqOOQ-0001a3-JQ; Sat, 30 Mar 2024 02:24:26 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rqOOQ-00032U-BH; Sat, 30 Mar 2024 02:24:26 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rqOOQ-0004bN-1u; Sat, 30 Mar 2024 02:24:26 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rqOOQ-0006m3-1E; Sat, 30 Mar 2024 02:24:26 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=TeHFxJOEuoybWTb507mMGADTD92JDaVw3IZXw4kY6Us=; b=UhQUTEh6+8Z4gsqwxgfzzFDTBU
	4O9pSe7fNIz/JzHWpzl23RE3N/GEi7wK5d0socv22NuXmbtCju9zYGoSNddDCfqm7YMJWBzmBlnK1
	ILImNBUENQdXDatiF/RNOQ+MUHkVe5k5rCsBcoZqkUbwv321BRbxGREViqlGLAy1kpec=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [ovmf test] 185202: all pass - PUSHED
X-Osstest-Versions-This:
    ovmf=37f63deeefa89b7ac28285bc59eca22a5c00eb92
X-Osstest-Versions-That:
    ovmf=7fde22823d64cb7b9f2a65bb87ffb7581f5ff84e
From: osstest service owner 
Date: Sat, 30 Mar 2024 02:24:26 +0000

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf                 37f63deeefa89b7ac28285bc59eca22a5c00eb92
baseline version:
 ovmf                 7fde22823d64cb7b9f2a65bb87ffb7581f5ff84e

Last test of basis   185198  2024-03-29 03:14:32 Z    0 days
Testing same since   185202  2024-03-30 00:11:17 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Michael D Kinney 
  Oliver Smith-Denny 

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-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    


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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   7fde22823d..37f63deeef  37f63deeefa89b7ac28285bc59eca22a5c00eb92 -> xen-tested-master


From xen-devel-bounces@lists.xenproject.org Sat Mar 30 04:49:10 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 30 Mar 2024 04:49:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699507.1092284 (Exim 4.92)
	(envelope-from )
	id 1rqQeH-0001tr-Cu; Sat, 30 Mar 2024 04:48:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699507.1092284; Sat, 30 Mar 2024 04:48:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rqQeH-0001tk-9f; Sat, 30 Mar 2024 04:48:57 +0000
Received: by outflank-mailman (input) for mailman id 699507;
 Sat, 30 Mar 2024 04:48:56 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rqQeG-0001tZ-Qj; Sat, 30 Mar 2024 04:48:56 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rqQeG-0005dx-9d; Sat, 30 Mar 2024 04:48:56 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rqQeF-0000Bh-UV; Sat, 30 Mar 2024 04:48:56 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rqQeF-00073W-U2; Sat, 30 Mar 2024 04:48:55 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=2vNF6U98CK8ItrziJTitWzBpPD5k1yr1ubsquONvXJ4=; b=K3iTwogXsj+S+roiY7Dvx9K80q
	Ir3KBv+ySS2kMXhhvHIGI556bCu86INBfIJhOLwmm+lFgvrTix46JSGUNzHC63JX2FjdsBwSwBOUh
	ZNSnHuxJTjOsZZS0sggLxfRXZcdJ0filqTQ2fRtGGGjplR/hh7nmNK+tGTOX5Ss1Y0SU=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 185199: trouble: broken/fail/pass
X-Osstest-Failures:
    xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64::broken:regression
    xen-unstable:test-amd64-amd64-pygrub::broken:regression
    xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm::broken:regression
    xen-unstable:test-amd64-amd64-pygrub:host-install(5):broken:regression
    xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:host-install(5):broken:regression
    xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:host-install(5):broken:regression
    xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-qcow2:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-qcow2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-raw:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-vhd:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    xen=7a09966e7b2823b70f6d56d0cf66c11124f4a3c1
X-Osstest-Versions-That:
    xen=8f85af65af76727692b9c2dea4f470f503432d2f
From: osstest service owner 
Date: Sat, 30 Mar 2024 04:48:55 +0000

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-win7-amd64                     broken
 test-amd64-amd64-pygrub                          broken
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm          broken
 test-amd64-amd64-pygrub       5 host-install(5)        broken REGR. vs. 185178
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 5 host-install(5) broken REGR. vs. 185178
 test-amd64-amd64-xl-qemuu-win7-amd64 5 host-install(5) broken REGR. vs. 185178

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt     16 saverestore-support-check    fail  like 185178
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop            fail like 185178
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop            fail like 185178
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop            fail like 185178
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 185178
 test-amd64-amd64-libvirt     15 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          16 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     16 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-multivcpu 15 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl          15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          16 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-raw 14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  16 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-raw 14 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-raw 15 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-vhd      14 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-vhd      15 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qcow2 14 migrate-support-check        fail never pass
 test-armhf-armhf-xl-qcow2    14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-qcow2    15 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-raw      14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-raw      15 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-vhd 14 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-vhd 15 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  7a09966e7b2823b70f6d56d0cf66c11124f4a3c1
baseline version:
 xen                  8f85af65af76727692b9c2dea4f470f503432d2f

Last test of basis   185178  2024-03-28 04:52:04 Z    1 days
Testing same since   185199  2024-03-29 10:34:07 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper 

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           broken  
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         broken  
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-amd64-pygrub                                      broken  
 test-amd64-amd64-libvirt-qcow2                               pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-xl-qcow2                                    pass    
 test-amd64-amd64-libvirt-raw                                 pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-amd64-amd64-xl-raw                                      pass    
 test-armhf-armhf-xl-raw                                      pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-libvirt-vhd                                 pass    
 test-amd64-amd64-xl-vhd                                      pass    
 test-arm64-arm64-xl-vhd                                      pass    


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

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

Explanation of these 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

broken-job test-amd64-amd64-xl-qemuu-win7-amd64 broken
broken-job test-amd64-amd64-pygrub broken
broken-job test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm broken
broken-step test-amd64-amd64-pygrub host-install(5)
broken-step test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm host-install(5)
broken-step test-amd64-amd64-xl-qemuu-win7-amd64 host-install(5)

Not pushing.

------------------------------------------------------------
commit 7a09966e7b2823b70f6d56d0cf66c11124f4a3c1
Author: Andrew Cooper 
Date:   Thu Mar 28 12:38:32 2024 +0000

    x86/spec-ctrl: Move __read_mostly data into __ro_after_init
    
    These variables predate the introduction of __ro_after_init, but all qualify.
    Update them to be consistent with the rest of the file.
    
    No functional change.
    
    Signed-off-by: Andrew Cooper 
    Reviewed-by: Jan Beulich 

commit 3c9e76cd875e12c88cfc8f0b2770c525da8d6894
Author: Andrew Cooper 
Date:   Tue Mar 19 19:38:48 2024 +0000

    x86/mm: Refine address alignment checks in modify_xen_mappings_lite()
    
    Require 's' to be superpage aligned if given over a superpage mapping.  This
    is expected to be the case in practice, and prevents v getting misaligned over
    superpages during the processing loop.
    
    Remove the requirement for 'e' to be page aligned.  All this is doing is
    forcing work for the caller just to satisfy an assertion.
    
    Reported-by: Jan Beulich 
    Signed-off-by: Andrew Cooper 
    Reviewed-by: Roger Pau Monné 
(qemu changes not included)


From xen-devel-bounces@lists.xenproject.org Sat Mar 30 09:06:14 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 30 Mar 2024 09:06:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699538.1092294 (Exim 4.92)
	(envelope-from )
	id 1rqUf2-0000tu-GH; Sat, 30 Mar 2024 09:06:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699538.1092294; Sat, 30 Mar 2024 09:06:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rqUf2-0000tn-Cm; Sat, 30 Mar 2024 09:06:00 +0000
Received: by outflank-mailman (input) for mailman id 699538;
 Sat, 30 Mar 2024 09:05:58 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rqUf0-0000td-Et; Sat, 30 Mar 2024 09:05:58 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rqUf0-0004C0-9Y; Sat, 30 Mar 2024 09:05:58 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rqUez-0001w5-Sb; Sat, 30 Mar 2024 09:05:57 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rqUez-0002p3-SD; Sat, 30 Mar 2024 09:05:57 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=MTliVVxKOTb/+gN4fSbd0W9tCY2TWEhiOiZTh4lnEVk=; b=WyBJJ2FOtvcJW223RqOZfK2VEo
	htouW32bHLLUDiB8wzb66j3fpb4xxsLTy4NexbMMIphIwLk0CvPltl3MtJ4rRviz0XB5znh+cjUc2
	SeOLghGR4Aa6mP+FB0MwfdIp7e/MMUDTudX59O/mB/ERP3EM66TNT98uK3a211SxjLVU=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 185200: tolerable FAIL - PUSHED
X-Osstest-Failures:
    linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-qcow2:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-qcow2:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-raw:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-vhd:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    linux=317c7bc0ef035d8ebfc3e55c5dde0566fd5fb171
X-Osstest-Versions-That:
    linux=962490525cffee6270422206c9d5bdb12d472c2b
From: osstest service owner 
Date: Sat, 30 Mar 2024 09:05:57 +0000

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

Failures :-/ but no regressions.

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

version targeted for testing:
 linux                317c7bc0ef035d8ebfc3e55c5dde0566fd5fb171
baseline version:
 linux                962490525cffee6270422206c9d5bdb12d472c2b

Last test of basis   185177  2024-03-27 17:12:19 Z    2 days
Testing same since   185200  2024-03-29 15:55:01 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Adrian Hunter 
  Al Viro 
  Alejandro Colomar 
  Alexandra Winter 
  Alexei Starovoitov 
  Anand Jain 
  Andrei Matei 
  Andrew Morton 
  Andrii Nakryiko 
  Arnaldo Carvalho de Melo 
  Arnaldo Carvalho de Melo 
  Arnd Bergmann 
  Artem Savkov 
  Arınç ÜNAL 
  Ayala Beker 
  Baoquan He 
  Barry Song 
  Barry Song 
  Benjamin Berg 
  Bjørn Mork 
  Breno Leitao 
  Brent Lu 
  Brian Norris 
  Carlos Maiolino 
  Carlos Maiolino 
  Chao Yu 
  Chris Li 
  Christian Marangi 
  Chuck Lever 
  Claus Hansen Ries 
  Colin Ian King 
  Cong Liu 
  Dai Ngo 
  Dan Carpenter 
  Daniel Borkmann 
  Daniele Salvatore Albano 
  David Hildenbrand 
  David S. Miller 
  David Sterba 
  David Thompson 
  Duoming Zhou 
  Edward Liaw 
  Emmanuel Grumbach 
  Eric Dumazet 
  Eric Van Hensbergen 
  Felix Fietkau 
  Filipe Manana 
  Florian Westphal 
  Francesco Dolcini 
  Francesco Dolcini 
  Gal Pressman 
  Gao Xiang 
  Gergo Koteles 
  Hangbin Liu 
  Hari Bathini 
  Hariprasad Kelam 
  Helge Deller   [parisc]
  Herve Codina 
  Ido Schimmel 
  Igor Artemiev 
  Ilan Peer 
  Ilya Leoshkevich 
  Jakub Kicinski 
  Jan Kara 
  Jason Gunthorpe 
  Jeff Johnson 
  Jesse Brandeburg 
  Jian Shen 
  Jie Wang 
  Jijie Shao 
  Jiri Olsa 
  Joerg Roedel 
  Joey Gouly 
  Johan Hovold 
  Johannes Berg 
  Johannes Thumshirn 
  Johannes Weiner 
  John Sperbeck 
  Josef Bacik 
  Justin Chen 
  Kalle Valo 
  KP Singh 
  Kuan-Wei Chiu 
  Kumar Kartikeya Dwivedi 
  Kuniyuki Iwashima 
  Kurt Kanzenbach 
  Leonard Crestez 
  Liming Sun 
  linke li 
  Linus Torvalds 
  Liviu Dudau 
  Lizhi Xu 
  Lokesh Gidra 
  Mark Brown 
  Matt Bobrowski 
  Matthew Wilcox (Oracle) 
  Michael Hofmann 
  Mikko Rapeli 
  Miri Korenblit 
  Mirsad Todorovac 
  Mostafa Saleh 
  Muhammad Usama Anjum 
  Naama Meir 
  Nathan Chancellor 
  Oscar Salvador 
  Pablo Neira Ayuso 
  Paolo Abeni 
  Peter Ujfalusi 
  Peter Xu 
  Ping-Ke Shih 
  Prasad Pandit 
  Przemek Kitszel 
  Pu Lehui 
  Pucha Himasekhar Reddy  (A Contingent worker at Intel)
  Puranjay Mohan 
  Quentin Monnet 
  Raju Lakkaraju 
  Ravi Gunasekaran 
  Richard Fitzgerald 
  Romain Naour 
  Ryosuke Yasuoka 
  Sabrina Dubroca 
  Sandeep Dhavale 
  Sergey Shtylyov 
  Shaul Triebitz 
  Simon Trimmer 
  Stanislav Fomichev 
  Steven Zou 
  Sujai Buvaneswaran 
  syzbot+adbc983a1588b7805de3@syzkaller.appspotmail.com
  Takashi Iwai 
  Tavian Barnes 
  Thorsten Winkler 
  Tony Nguyen 
  Ulf Hansson 
  Vinicius Costa Gomes 
  Vitaly Chikunov 
  Will Deacon 
  Xu Kuohai 
  Yonglong Liu 
  Yoshihiro Shimoda 
  Yosry Ahmed 
  Yujie Liu 
  Zev Weiss 
  Zhongkun He 

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-libvirt-qcow2                               pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-xl-qcow2                                    pass    
 test-amd64-amd64-libvirt-raw                                 pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-amd64-amd64-xl-raw                                      pass    
 test-armhf-armhf-xl-raw                                      pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-libvirt-vhd                                 pass    
 test-amd64-amd64-xl-vhd                                      pass    
 test-arm64-arm64-xl-vhd                                      pass    


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

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

Explanation of these 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 :

hint: The 'hooks/update' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
hint: The 'hooks/post-receive' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
hint: The 'hooks/post-update' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
To xenbits.xen.org:/home/xen/git/linux-pvops.git
   962490525cff..317c7bc0ef03  317c7bc0ef035d8ebfc3e55c5dde0566fd5fb171 -> tested/linux-linus


From xen-devel-bounces@lists.xenproject.org Sat Mar 30 19:00:18 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 30 Mar 2024 19:00:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699629.1092307 (Exim 4.92)
	(envelope-from )
	id 1rqdvj-0002kf-Th; Sat, 30 Mar 2024 18:59:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699629.1092307; Sat, 30 Mar 2024 18:59:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rqdvj-0002kY-Qf; Sat, 30 Mar 2024 18:59:51 +0000
Received: by outflank-mailman (input) for mailman id 699629;
 Sat, 30 Mar 2024 18:59:50 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rqdvi-0002kN-Bl; Sat, 30 Mar 2024 18:59:50 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rqdvi-0001PZ-5Y; Sat, 30 Mar 2024 18:59:50 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rqdvh-0003IQ-Nu; Sat, 30 Mar 2024 18:59:49 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rqdvh-0007gg-NO; Sat, 30 Mar 2024 18:59:49 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=4KD82s+73Jcv4u84nFLBo4xh5gooxqwy+C512lQKuFc=; b=5FNAwkJYqQaptLnmz18LAgkw32
	qWLd28OYU63eQSMiiW6+02Stkfc6Oe1m9CAP8EFmdabWmr3D/SRugtz1OS+vG5Q5GgJzwXjhMXJDQ
	GUGNpVIb+KHf+BLa4bEJ6aU/5ZUaMtjHyYa75eBhFbvAC+7DTLi1RSYyBphthso4dB8g=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 185203: tolerable FAIL - PUSHED
X-Osstest-Failures:
    xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-qcow2:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-qcow2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-raw:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-vhd:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    xen=7a09966e7b2823b70f6d56d0cf66c11124f4a3c1
X-Osstest-Versions-That:
    xen=8f85af65af76727692b9c2dea4f470f503432d2f
From: osstest service owner 
Date: Sat, 30 Mar 2024 18:59:49 +0000

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen                  7a09966e7b2823b70f6d56d0cf66c11124f4a3c1
baseline version:
 xen                  8f85af65af76727692b9c2dea4f470f503432d2f

Last test of basis   185178  2024-03-28 04:52:04 Z    2 days
Testing same since   185199  2024-03-29 10:34:07 Z    1 days    2 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper 

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-libvirt-qcow2                               pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-xl-qcow2                                    pass    
 test-amd64-amd64-libvirt-raw                                 pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-amd64-amd64-xl-raw                                      pass    
 test-armhf-armhf-xl-raw                                      pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-libvirt-vhd                                 pass    
 test-amd64-amd64-xl-vhd                                      pass    
 test-arm64-arm64-xl-vhd                                      pass    


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

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

Explanation of these 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
   8f85af65af..7a09966e7b  7a09966e7b2823b70f6d56d0cf66c11124f4a3c1 -> master


From xen-devel-bounces@lists.xenproject.org Sun Mar 31 00:26:10 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 31 Mar 2024 00:26:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699656.1092325 (Exim 4.92)
	(envelope-from )
	id 1rqj1I-00081a-64; Sun, 31 Mar 2024 00:25:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699656.1092325; Sun, 31 Mar 2024 00:25:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rqj1I-00081T-34; Sun, 31 Mar 2024 00:25:56 +0000
Received: by outflank-mailman (input) for mailman id 699656;
 Sun, 31 Mar 2024 00:25:54 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rqj1G-00081J-Kb; Sun, 31 Mar 2024 00:25:54 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rqj1G-0007q0-Fa; Sun, 31 Mar 2024 00:25:54 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rqj1G-0002GI-2e; Sun, 31 Mar 2024 00:25:54 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rqj1G-0000bM-2C; Sun, 31 Mar 2024 00:25:54 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=qs2npzsvpZG6bvWEWFxkY0rVv2sPsv5wUMhG0vawybc=; b=zb1K79BHT5OOvPWELfs8ep6sL1
	puzBopjc5UI8FbhbWkDrtMtdrMGNJcHFX1Gm6JTzHQqKWhSSf+MDMbo+yEfls1TQ1uLrIJy3gUT+Y
	NmRIJcCr9Ka1G10Atr8JuS3bwAZPTFvsm5mylMPoyEIhEBsxvRUwpPYBujMPNiT2O8no=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 185204: tolerable FAIL - PUSHED
X-Osstest-Failures:
    linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-qcow2:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-qcow2:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-raw:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-vhd:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    linux=486291a0e6246364936df1ecd64c90affef4b9c5
X-Osstest-Versions-That:
    linux=317c7bc0ef035d8ebfc3e55c5dde0566fd5fb171
From: osstest service owner 
Date: Sun, 31 Mar 2024 00:25:54 +0000

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

Failures :-/ but no regressions.

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

version targeted for testing:
 linux                486291a0e6246364936df1ecd64c90affef4b9c5
baseline version:
 linux                317c7bc0ef035d8ebfc3e55c5dde0566fd5fb171

Last test of basis   185200  2024-03-29 15:55:01 Z    1 days
Testing same since   185204  2024-03-30 09:17:33 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Alex Deucher 
  Alex Hung 
  Andi Shyti 
  Andy Shevchenko 
  Andy Yan 
  Ard Biesheuvel 
  Arnd Bergmann 
  Bartosz Golaszewski 
  Bhanuprakash Modem 
  Borislav Petkov (AMD) 
  Chris Bainbridge 
  Chris Park 
  Chris Wilson 
  Christian König 
  Christoph Hellwig 
  Clayton Craft 
  Damien Le Moal 
  Daniel Lezcano 
  Daniel Wheeler 
  Danilo Krummrich 
  Dave Airlie 
  David Gow 
  David Howells 
  Duoming Zhou 
  Eric Huang 
  Ferry Toth 
  George Shen 
  Guenter Roeck 
  Hamza Mahfooz 
  Hans de Goede 
  Harry Wentland 
  Heiko Stuebner 
  Himal Prasad Ghimiray 
  Imre Deak 
  Jani Nikula 
  Janusz Krzysztofik 
  Jens Axboe 
  Jesse Zhang 
  Jocelyn Falempe 
  Johannes Weiner 
  John Garry 
  Jonathan Kim 
  Jonathon Hall 
  Joonas Lahtinen 
  José Roberto de Souza 
  Juha-Pekka Heikkila 
  Ken Raeburn 
  Kuan-Wei Chiu 
  Lang Yu 
  lima1002 
  Linus Torvalds 
  Luca Weiss 
  Lucas De Marchi 
  Mario Limonciello 
  Mark Broadworth 
  Mark Brown 
  Mark Rutland 
  Masami Hiramatsu (Google) 
  Matthew Auld 
  Matthew Sakai 
  Maxime Ripard 
  Miguel Ojeda 
  Mike Snitzer 
  Muhammad Usama Anjum 
  Mukul Joshi 
  Natanel Roizenman 
  Neil Armstrong 
  Nikita Kiryushin 
  Nirmoy Das 
  Nícolas F. R. A. Prado 
  Pavel Sakharov 
  Peyton Lee 
  Rafael J. Wysocki 
  Rodrigo Vivi 
  Roman Li 
  Sascha Hauer 
  Shuah Khan 
  Steve French 
  Sung Joon Kim 
  Taimur Hassan 
  Tejas Upadhyay 
  Thomas Zimmermann 
  Tom Chung 
  Ville Syrjälä 
  Vitaly Prosyak 
  Wayne Lin 
  Wenjing Liu 
  Xi Liu 
  Ye Zhang 

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-libvirt-qcow2                               pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-xl-qcow2                                    pass    
 test-amd64-amd64-libvirt-raw                                 pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-amd64-amd64-xl-raw                                      pass    
 test-armhf-armhf-xl-raw                                      pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-libvirt-vhd                                 pass    
 test-amd64-amd64-xl-vhd                                      pass    
 test-arm64-arm64-xl-vhd                                      pass    


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

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

Explanation of these 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 :

hint: The 'hooks/update' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
hint: The 'hooks/post-receive' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
hint: The 'hooks/post-update' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
To xenbits.xen.org:/home/xen/git/linux-pvops.git
   317c7bc0ef03..486291a0e624  486291a0e6246364936df1ecd64c90affef4b9c5 -> tested/linux-linus


From xen-devel-bounces@lists.xenproject.org Sun Mar 31 09:19:02 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 31 Mar 2024 09:19:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699695.1092335 (Exim 4.92)
	(envelope-from )
	id 1rqrKw-0000h8-12; Sun, 31 Mar 2024 09:18:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699695.1092335; Sun, 31 Mar 2024 09:18:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rqrKv-0000h1-UU; Sun, 31 Mar 2024 09:18:45 +0000
Received: by outflank-mailman (input) for mailman id 699695;
 Sun, 31 Mar 2024 09:18:44 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rqrKu-0000gp-Ag; Sun, 31 Mar 2024 09:18:44 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rqrKt-0000lJ-WF; Sun, 31 Mar 2024 09:18:44 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rqrKt-0005cN-ME; Sun, 31 Mar 2024 09:18:43 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rqrKt-0002W9-LV; Sun, 31 Mar 2024 09:18:43 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=88j7K47SpjK0G5A1M83uehjoueDuPXYYBwUIEaTqEZU=; b=nIUBWySYYKSvGpRKitAzCyrDTD
	u5/tOMrrbXRD9e9Y6Jb+Ag/jFNlMna/G/DPR5MoevvErYAotPrr/Rc0ZnAzSYsfJFioQ5Mogprjhg
	2fC11L9ieN2kM7gfdAlNC1vr+l2VoLYfxk6AD4jcR0KmzErB+Ii2BcthKrZ50Di4FkTc=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [linux-linus test] 185205: tolerable FAIL - PUSHED
X-Osstest-Failures:
    linux-linus:test-armhf-armhf-libvirt:host-ping-check-xen:fail:heisenbug
    linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-arm64-arm64-xl-vhd:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-qcow2:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-qcow2:saverestore-support-check:fail:nonblocking
    linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-raw:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-raw:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-vhd:migrate-support-check:fail:nonblocking
    linux-linus:test-armhf-armhf-libvirt-vhd:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    linux=712e14250dd2907346617eba275c46f53db8fae7
X-Osstest-Versions-That:
    linux=486291a0e6246364936df1ecd64c90affef4b9c5
From: osstest service owner 
Date: Sun, 31 Mar 2024 09:18:43 +0000

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

Failures :-/ but no regressions.

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

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 16 saverestore-support-check fail in 185207 like 185204
 test-armhf-armhf-libvirt    15 migrate-support-check fail in 185207 never pass
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop            fail like 185204
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop            fail like 185204
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop            fail like 185204
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop            fail like 185204
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 185204
 test-arm64-arm64-xl-thunderx 15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit1  15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit1  16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl          15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl          16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-credit2  15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-check    fail   never pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-xsm 16 saverestore-support-check    fail   never pass
 test-arm64-arm64-xl-xsm      15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      16 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-multivcpu 15 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-credit1  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          16 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qcow2 14 migrate-support-check        fail never pass
 test-amd64-amd64-libvirt-raw 14 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-raw 14 migrate-support-check        fail   never pass
 test-arm64-arm64-libvirt-raw 15 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-vhd      14 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-vhd      15 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-qcow2    14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-qcow2    15 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass
 test-armhf-armhf-xl-raw      14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-raw      15 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-rtds     15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     16 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-vhd 14 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-vhd 15 saverestore-support-check    fail   never pass

version targeted for testing:
 linux                712e14250dd2907346617eba275c46f53db8fae7
baseline version:
 linux                486291a0e6246364936df1ecd64c90affef4b9c5

Last test of basis   185204  2024-03-30 09:17:33 Z    0 days
Testing same since   185205  2024-03-31 00:43:55 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Alan Stern 
  Alexander Stein 
  Alexander Wetzel 
  Andi Shyti 
  Arnd Bergmann 
  Bikash Hazarika 
  Chandan Babu R 
  Christian A. Ehrhardt 
  Colin Ian King 
  Damien Le Moal 
  Dan Carpenter 
  Dave Chinner 
  Dmitry Baryshkov 
  Greg Kroah-Hartman 
  Guilherme G. Piccoli 
  Guilherme G. Piccoli  # Steam Deck
  Heikki Krogerus 
  Jameson Thies 
  Justin Tee 
  Krishna Kurapati 
  Kyle Tso 
  Linus Torvalds 
  Martin K. Petersen 
  Maxim Levitsky 
  Minas Harutyunyan 
  Muhammad Usama Anjum 
  Neil Armstrong  # on SM8550-QRD
  Nilesh Javali 
  Oliver Neukum 
  Peter Wang 
  Quinn Tran 
  Ricardo B. Marliere 
  Rohit Ner 
  Sanath S 
  Saurav Kashyap 
  Shin'ichiro Kawasaki 
  Thinh Nguyen 
  Weitao Wang 
  Wolfram Sang 
  Xingui Yang 
  Xu Yang 
  Yongzhi Liu 
  yuan linyu 

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  pass    
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     pass    
 test-armhf-armhf-examine                                     pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-libvirt-qcow2                               pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-xl-qcow2                                    pass    
 test-amd64-amd64-libvirt-raw                                 pass    
 test-arm64-arm64-libvirt-raw                                 pass    
 test-amd64-amd64-xl-raw                                      pass    
 test-armhf-armhf-xl-raw                                      pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-arm64-arm64-xl-thunderx                                 pass    
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-libvirt-vhd                                 pass    
 test-amd64-amd64-xl-vhd                                      pass    
 test-arm64-arm64-xl-vhd                                      pass    


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

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

Explanation of these 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 :

hint: The 'hooks/update' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
hint: The 'hooks/post-receive' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
hint: The 'hooks/post-update' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
To xenbits.xen.org:/home/xen/git/linux-pvops.git
   486291a0e624..712e14250dd2  712e14250dd2907346617eba275c46f53db8fae7 -> tested/linux-linus


From xen-devel-bounces@lists.xenproject.org Sun Mar 31 10:32:15 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 31 Mar 2024 10:32:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.699703.1092346 (Exim 4.92)
	(envelope-from )
	id 1rqsTq-0001U3-SO; Sun, 31 Mar 2024 10:32:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 699703.1092346; Sun, 31 Mar 2024 10:32:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1rqsTq-0001Tw-NP; Sun, 31 Mar 2024 10:32:02 +0000
Received: by outflank-mailman (input) for mailman id 699703;
 Sun, 31 Mar 2024 10:32:02 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rqsTq-0001Tm-0b; Sun, 31 Mar 2024 10:32:02 +0000
Received: from host146.205.237.98.conversent.net ([205.237.98.146]
 helo=infra.test-lab.xenproject.org)
 by mail.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rqsTp-00020o-Sv; Sun, 31 Mar 2024 10:32:01 +0000
Received: from [172.16.148.1] (helo=osstest.test-lab.xenproject.org)
 by infra.test-lab.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1rqsTp-0007O1-CN; Sun, 31 Mar 2024 10:32:01 +0000
Received: from osstest by osstest.test-lab.xenproject.org with local (Exim
 4.92) (envelope-from )
 id 1rqsTp-0008AH-Bp; Sun, 31 Mar 2024 10:32:01 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version:
	Content-Transfer-Encoding:Content-Type:Message-ID:To;
	bh=SnS2M8EqtniNbDzppqqjUVDPXsI21lRx+Z3eWKKBMiI=; b=sOocdPXe+qc0y+e8/ysPyf+Fb9
	yJQn3smoOdXCucWEbmt4WBrDJySzjegrg/cHKq67yjvve/FdoioOmyurNnE1eMzERbBhQaquuaqlY
	sJP3WxKhAwBpIenL4Azsd9ZrwIfw7C8O2oisFUQ21hKqb98Fk3HR/JEmiqt0wQ+qBnv4=;
To: xen-devel@lists.xenproject.org
Message-ID: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Subject: [xen-unstable test] 185206: regressions - FAIL
X-Osstest-Failures:
    xen-unstable:build-arm64-pvops:kernel-build:fail:regression
    xen-unstable:test-arm64-arm64-examine:build-check(1):blocked:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-raw:build-check(1):blocked:nonblocking
    xen-unstable:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking
    xen-unstable:test-arm64-arm64-xl:build-check(1):blocked:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit1:build-check(1):blocked:nonblocking
    xen-unstable:test-arm64-arm64-xl-credit2:build-check(1):blocked:nonblocking
    xen-unstable:test-arm64-arm64-xl-thunderx:build-check(1):blocked:nonblocking
    xen-unstable:test-arm64-arm64-xl-vhd:build-check(1):blocked:nonblocking
    xen-unstable:test-arm64-arm64-xl-xsm:build-check(1):blocked:nonblocking
    xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking
    xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-amd64-amd64-libvirt-qcow2:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-qcow2:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-qcow2:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-raw:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-raw:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-vhd:migrate-support-check:fail:nonblocking
    xen-unstable:test-armhf-armhf-libvirt-vhd:saverestore-support-check:fail:nonblocking
X-Osstest-Versions-This:
    xen=7a09966e7b2823b70f6d56d0cf66c11124f4a3c1
X-Osstest-Versions-That:
    xen=7a09966e7b2823b70f6d56d0cf66c11124f4a3c1
From: osstest service owner 
Date: Sun, 31 Mar 2024 10:32:01 +0000

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-pvops             6 kernel-build             fail REGR. vs. 185203

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-examine      1 build-check(1)               blocked  n/a
 test-arm64-arm64-libvirt-raw  1 build-check(1)               blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)               blocked  n/a
 test-arm64-arm64-xl           1 build-check(1)               blocked  n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)               blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)               blocked  n/a
 test-arm64-arm64-xl-thunderx  1 build-check(1)               blocked  n/a
 test-arm64-arm64-xl-vhd       1 build-check(1)               blocked  n/a
 test-arm64-arm64-xl-xsm       1 build-check(1)               blocked  n/a
 test-armhf-armhf-libvirt     16 saverestore-support-check    fail  like 185203
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop            fail like 185203
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop            fail like 185203
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop            fail like 185203
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 185203
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop            fail like 185203
 test-amd64-amd64-libvirt     15 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass
 test-armhf-armhf-xl-rtds     15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     16 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt     15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-multivcpu 15 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl          15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  16 saverestore-support-check    fail   never pass
 test-amd64-amd64-libvirt-raw 14 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-qcow2 14 migrate-support-check        fail never pass
 test-armhf-armhf-xl-qcow2    14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-qcow2    15 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-raw      14 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-raw      15 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit1  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit1  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-arndale  15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  16 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-vhd 14 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-vhd 15 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  7a09966e7b2823b70f6d56d0cf66c11124f4a3c1
baseline version:
 xen                  7a09966e7b2823b70f6d56d0cf66c11124f4a3c1

Last test of basis   185206  2024-03-31 01:54:16 Z    0 days
Testing same since                          (not found)         0 attempts

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            fail    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-coresched-amd64-xl                                pass    
 test-arm64-arm64-xl                                          blocked 
 test-armhf-armhf-xl                                          pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm                 pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 blocked 
 test-amd64-amd64-xl-xsm                                      pass    
 test-arm64-arm64-xl-xsm                                      blocked 
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvhv2-amd                                pass    
 test-amd64-amd64-dom0pvh-xl-amd                              pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-qemuu-freebsd11-amd64                       pass    
 test-amd64-amd64-qemuu-freebsd12-amd64                       pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-qemut-ws16-amd64                         fail    
 test-amd64-amd64-xl-qemuu-ws16-amd64                         fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-examine-bios                                pass    
 test-amd64-amd64-xl-credit1                                  pass    
 test-arm64-arm64-xl-credit1                                  blocked 
 test-armhf-armhf-xl-credit1                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-arm64-arm64-xl-credit2                                  blocked 
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict        pass    
 test-amd64-amd64-examine                                     pass    
 test-arm64-arm64-examine                                     blocked 
 test-armhf-armhf-examine                                     pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvhv2-intel                              pass    
 test-amd64-amd64-dom0pvh-xl-intel                            pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-amd64-livepatch                                   pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-amd64-xl-pvshim                                   pass    
 test-amd64-amd64-pygrub                                      pass    
 test-amd64-amd64-libvirt-qcow2                               pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-xl-qcow2                                    pass    
 test-amd64-amd64-libvirt-raw                                 pass    
 test-arm64-arm64-libvirt-raw                                 blocked 
 test-amd64-amd64-xl-raw                                      pass    
 test-armhf-armhf-xl-raw                                      pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow             pass    
 test-amd64-amd64-xl-shadow                                   pass    
 test-arm64-arm64-xl-thunderx                                 blocked 
 test-amd64-amd64-examine-uefi                                pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-libvirt-vhd                                 pass    
 test-amd64-amd64-xl-vhd                                      pass    
 test-arm64-arm64-xl-vhd                                      blocked 


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

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

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    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


Published tested tree is already up to date.